10 أخطاء i18n شائعة وكيف تتجنبها
تعرف على أكثر أخطاء التدويل شيوعاً التي يرتكبها المطورون، وكيفية إصلاحها. حسن جودة التوطين لتطبيقك باستخدام هذه الممارسات الفضلى.
الاستنساخ الدولي (i18n) يبدو بسيطاً — حتى تدرك أن المستخدمين الألمان لديك يشاهدون أزرار مقطوعة، وأن المستخدمين اليابانيين لديك يحصلون على أجزاء جملة غير مكتملة، وأن المستخدمين الناطقين بالعربية يواجهون تخطيطات مكسورة تماماً. هذه ليست حالات هامشية. إنها النتائج المتوقعة من الأخطاء الشائعة التي ترتكبها معظم فرق التطوير عند التعامل مع التوطين لأول مرة. في هذا الدليل، سنقوم بمراجعة 10 أخطاء i18n الأكثر شيوعاً، ونشرح بالضبط لماذا تحدث، ونوضح خطوة بخطوة كيفية إصلاح كل واحد منها. سواء كنت تبني تطبيقاً جديداً أم ترقي تطبيق قائم — تجنب هذه الأخطاء سيوفر لك أسابيع من التصحيح ويقدم تجربة مصقولة للمستخدمين حول العالم.
الخطأ رقم 1: سلاسل مُضمَّنة بشكل ثابت
وصف: كتابة النصوص مباشرة في الشفرة هي أخطر أخطاء i18n. يحدث ذلك عندما يركز المطورون أولاً على جعل الميزات تعمل، ويخططون لتنظيفها فيما بعد. لكن لاحقاً لا يأتي، وفجأة تجد آلاف السلاسل موزعة عبر مئات الملفات.
['قم بإعداد إطار i18n قبل كتابة سطر UI الأول', 'استخدم إضافة فحص (linter) لاكتشاف السلاسل النصية الصريحة في القوالب والمكوّنات', 'اجعل مفاتيح الترجمة وصفية ومنظمة حسب الميزة أو الصفحة']
قم بإعداد إطار i18n الخاص بك قبل كتابة سطر واجهة المستخدم الأول.
استخدم إضافة فاحص لاكتشاف السلاسل الثابتة في القوالب والمكوّنات.
اجعل مفاتيح الترجمة وصفية ومنظمة حسب الميزة أو الصفحة.
سيناريو نموذجي
مطور يكتب تسمية زر مباشرة في JSX: <button>Submit Order</button>.
يتم إصدار التطبيق بالإنجليزية ويعمل بشكل صحيح. بعد ستة أشهر، تتوسع الشركة إلى ألمانيا.
فريق التوطين يكتشف أكثر من 2000 سلسلة مُضمنة بشكل صلب. يستغرق ترميمها 3 أسابيع ويسبب 47 عيباً.
لماذا هذا مشكلة
في قاعدة كود متطورة يمكن أن تكون السلاسل المُضمّنة الآلاف. سحبها لاحقاً يتطلب لمس كل ملف وإعادة اختبار كل مكوّن وخاطر حدوث نسخ متماثلة في كل مكان.
النصوص المثبتة داخل الشفرة هي نصوص مُضمّنة مباشرة في الشفرة المصدرية، القوالب أو المكونات. لا يمكن استخلاصها أو ترجمتها أو استبدالها أثناء التشغيل دون تعديل الكود نفسه.
المستخدمون في اللغات غير الإنجليزية يشاهدون عناصر واجهة مستخدم غير مترجمة ممزوجة بمحتوى مترجم — انطباع فوضوي وغير مهني.
كيف تحله
انقل جميع السلاسل القابلة للت use في ملفات الموارد من البداية.
قم بإعداد إطار ترجمة قبل كتابة أول مكوّن (مثلاً next-intl، react-i18next، vue-i18n).
إنشئ بنية ملفات الموارد (مثلاً messages/de.json) وارجع إلى كل سلسلة باستخدام مفتاح ترجمة مثل t('checkout.submitButton').
أضف قاعدة تدقيق فحص ترميز (linting) أو hook قبل الالتزام يعلِم السلاسل النصية المباشرة.
خطأ #10: ترجمة كل شيء حرفيًا
لا يجب ترجمة كل المحتوى. يجب أن تبقى أسماء العلامات التجارية، وأسماء الكيانات القانونية، والمصطلحات الفنية وبعض أسماء المنتجات بلغتها الأصلية. يمكن أن تسبب الترجمة المفرطة مشاكل قانونية وتعارض العلامة وتشتت المستخدم.
["احفظ قاموس 'لا تُترجم' وشاركه مع جميع المترجمين", "استخدم مقاطع مقفلة أو مساحات أسماء منفصلة للمصطلحات التجارية والقانونية", "قدّم دائماً ملاحظات سياقية للنصوص ذات المعاني المزدوجة لتجنّب الترجمات الخاطئة"]
احرص على صيانة قاموس 'لا تُترجم' ومشاركته مع جميع المترجمين.
استخدم مقاطع مقفلة أو مساحات أسماء منفصلة للمصطلحات المتعلقة بالعلامة التجارية والحقوق.
قدّم دائماً ملاحظات سياقية للسلاسل متعددة المعاني لمنع الترجمات الخاطئة.
سيناريو نموذجي
يحتوي ملف الترجمة على اسم الشركة 'CloudForge Inc.' والمصطلح التقني 'OAuth 2.0 Token' كعبارات قابلة للترجمة.
المترجم الإسباني يترجم 'CloudForge' إلى 'ForjaNube' و 'OAuth 2.0 Token' إلى 'ficha OAuth 2.0'.
النتيجة: لا يجد المستخدمون الشركة تحت اسمها الحقيقي، والمطورون الذين يقرؤون التوثيق الإسباني يبدون حيرة بسبب المصطلحات الفنية المترجمة بشكل غير مألوف.
لماذا هذه مشكلة
اسم تجاري مُترجم بشكل خاطئ في وثيقة قانونية قد يجعل العقود باطلة. مراجعة وتدقيق كل سلاسل النصوص في كل لغة قد يستغرق أسابيع.
عندما تُرسل السلاسل النصية بدون سياق إلى الترجمة، قد يترجم المترجمون أسماء العلامات التجارية ('Apple' → 'Apfel')، أو المصطلحات القانونية ('GmbH' → 'LLC')، أو المسميات التقنية التي يجب أن تبقى باللغة الإنجليزية.
المستخدمون لا يجدون المنتجات تحت العلامة التجارية المعروفة لديهم، مستندات قانونية تشير إلى كيان خاطئ، والوثائق الفنية تصبح غير مفهومة عند ترجمة مصطلحات مثل 'API Endpoint'.
كيفية إصلاحه
تمييز المحتوى غير القابل للترجمة بوضوح وتوفير ملاحظات سياقية للمترجمين.
إنشاء قاموس 'لا تُترجم' يضم جميع أسماء العلامات التجارية وأسماء المنتجات والشخصيات القانونية والمصطلحات التقنية التي يجب أن تبقى كما هي.
استخدم مساحة أسماء منفصلة أو مفاتيح خاصة للمحتوى غير القابل للترجمة. العديد من أدوات i18n تدعم مقاطع 'مقفلة' لا يمكن للمترجمين تعديلها.
أضف تعليقات/وصف للمترجمين إلى ملفات الترجمات تشرح السياق: 'هذا اسم علامة تجارية — لا تُترجم' أو 'مصطلح — اتركه بالإنجليزية'.
الخطأ رقم 2: ربط السلاسل النصية
الجمل المجمعة من أجزاء تبدو منطقية باللغة الإنجليزية، لكنها لا تعمل في لغات أخرى. ترتيب الكلمات والقواعد وبنية الجملة تختلف بشكل كبير بين اللغات، مما يجعل السلاسل المتّصلة غير قابلة للترجمة.
['لا تبني جملًا عن طريق ربط أجزاء مترجمة معًا', 'استخدم عناصر نائبة مسماة ('{name}') بدلاً من المواضع ({0}) للوضوح', 'قدم تعليقات سياقية للمترجمين تشرح ما يحتويه كل عنصر نائب']
لا تبنِ جملًا من خلال ربط مقاطع ترجمة منفصلة.
استخدم عناصر نائبة مسماة ('{name}') بدلاً من المواضع ({0}) للوضوح
زوّد المترجمين بتعليقات سياقية تشرح ما يحتويه كل عنصر نائب.
سيناريو نموذجي
المطور يكتب: 'You have ' + count + ' items in your ' + cartType + ' cart' — يعمل بشكل مثالي باللغة الإنجليزية.
المترجم الألماني يتلقى ثلاث مقاطع منفصلة ولا يستطيع تكوين جملة نحوية صحيحة لأن ترتيب الكلمات يجب أن يتغيّر.
النتيجة: المستخدمون الألمان يرون 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — غير سلس وغير مهني.
لماذا هذا مشكلة
كل سلسلة نصية مرتبطة هي قنبلة زمنية قابلة للانفجار. عند وجود 20 لغة و50 سلسلة مرتبطة، لديك 1,000 خطأ نحوي محتمل يجب إصلاحه يدويًا.
ربط السلاسل مثل 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' يتطلب ترتيب كلمات محدد. يَتلقّى المترجمون أجزاء غير مرتبطة بلا سياق لا يمكنهم إعادة ترتيبها.
المستخدمون يرون جُملاً نحوية غير صحيحة. في الألمانية غالبًا ما يكون الفعل في نهاية الجملة. في العربية تكون البنية كلها مقلوبة. النتيجة تقرأ كأنها هراء.
كيف تصلحه
استخدم رسائل قابلة للمعاملات مع معاملات مسماة، حتى يتمكن المترجمون من إعادة ترتيب الجملة بالكامل.
استبدل الربط بمفتاح رسالة واحد مع عناصر نائبة: 'cart.summary': 'لديك {count} عنصر في سلة '{cartType}''.
مرر المتغيرات كمعاملات إلى دالة الترجمة لديك: t('cart.summary', { count: 5, cartType: 'Premium' }).
يمكن للمترجمين الآن التبديل بحرية: 'يوجد {count} عنصر في سلة '{cartType}'' — باللغة الألمانية الصحيحة نحويًا.
الخطأ رقم 3: تجاهل التصريف الجمعي
الإنجليزية لديها شكلان للجمع: المفرد والجمع. غالبًا ما يفترض المطورون أن جميع اللغات تعمل بنفس الشكل. لا تفعل. البولندية لديها 4 أشكال، العربية لديها 6، وحتى لغات مثل الفرنسية تعالج الصفر بشكل مختلف عن الإنجليزية.
['استخدم دائماً ICU MessageFormat أو مكتبة مكافئة للمحتويات القابلة للعد', 'لا تكتب منطق الجمع الخاص بك — اعتمد على قواعد CLDR', 'اختبر الجمع باستخدام قيم مثل 0، 1، 2، 5، 21 و100 لتغطية جميع الفئات']
لا تكتب أبداً منطق الجمع الخاص بك — اعتمد على قواعد CLDR.
اختبر التصريفات بمقادير مثل 0 و1 و2 و5 و21 و100 لتغطية جميع الفئات.
لا تكتب أبداً منطق الجمع الخاص بك — اعتمد على قواعد CLDR.
سيناريو نموذجي
المطور يكتب: count + (count === 1 ? ' ملف' : ' ملفات') — يعالج الألمانية بشكل صحيح.
المترجم البولندي يحتاج إلى 4 أشكال: 1 plik، 2-4 pliki، 5-21 plików، 22-24 pliki. الشرطي الثلاثي البسيط لا يستطيع التعبير عن ذلك.
النتيجة: المستخدمون البولنديون يرون '5 pliki' (شكل خاطئ) بدلاً من '5 plików' (شكل صحيح)، والتطبيق يبدو معطلاً.
لماذا المشكلة؟
كل اسم عددي يحتاج في تطبيقك إلى معالجة الجمع. عند وجود 50 سلسلة من هذا النوع و20 لغة، توجد 1,000 قاعدة جمع محتملة يجب إدارتها يدويًا.
فحوصات شرطية بسيطة باستخدام if/else (count === 1 ? 'ملف' : 'ملفات') لا تعالج سوى الألمانية والإنجليزية. تعرف CLDR حتى 6 فئات الجمع: صفر، واحد، اثنان، few، many، وother. كل لغة تستخدم مجموعة فرعية مختلفة.
المستخدمون يرون نصوصًا نحوية خاطئة مثل '1 رسالة' أو أشكال جمع خاطئة تمامًا. في سياقات رسمية، هذا يقوّض المصداقية.
كيف تحله
استخدم صيغة ICU للرسائل، التي تدعم جميع قواعد الجمع وفق CLDR من العلبة.
حدد رسائل باستخدام صيغة ICU: 'fileCount': '{count, plural, one {# ملف} other {# ملفات}}'.
يقدم المترجمون جميع أشكال الجمع اللازمة بلغتهم. البولندية: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
مكتبة i18n الخاصة بك تختار تلقائياً أثناء التشغيل الشكل الصحيح بناءً على قواعد CLDR الخاصة باللغة النشطة.
الخطأ رقم 4: أحجام عناصر واجهة المستخدم الثابتة
وصف: المصمّمون يخلقون تخطيطات بالبكسل بدقة باللغة الإنجليزية، ويُنفِّذها المطورون بعروض ثابتة. لكن النص المترجم قد يكون أطول أو أقصر بشكل كبير. عادةً النص الألماني أطول بنحو 30% من الإنجليزية، بينما يمكن أن يكون النص الصيني أقصر بنسبة 50%.
['لا تستخدم أبعاد بكسلية ثابتة لعناصر تحتوي نصاً قابلاً للترجمة', 'خطط لزيادة النص بنسبة 40% كمعيار أساسي — بعض اللغات تتمدد أكثر', 'استخدم CSS Flexbox أو Grid لتخطيطات تتكيف مع أحجام المحتوى المتغيرة']
لا تستخدم أبدًا أبعاد بكسل ثابتة في العناصر التي تحتوي نصاً قابلاً للترجمة.
خطّط لزيادة النص بنسبة 40% كخط أساس — بعض اللغات تتمدد أكثر.
استخدم CSS Flexbox أو Grid لتخطيطات تتكيف مع أحجام المحتوى المتغيرة.
سيناريو نموذجي
المصمم ينشئ شريط تنقّل يحتوي على 5 أزرار، كل زر بعرض 100 بكسل بالضبط — يبدو رائعاً باللغة الإنجليزية.
الترجمة: 'Settings' ستصبح 'الإعدادات' (13 مقابل 8 حروف)، و 'Submit' ستصبح 'إرسال' (8 مقابل 6). شريط التنقل يتجاوز.
النتيجة: على الأجهزة المحمولة تتكدّس الأزرار فوق بعضها البعض أو يتم قطع النص، مما يجعل التنقل للمستخدمين الألمان غير قابل للاستخدام.
لماذا هذا مشكلة
كل عنصر بعرض ثابت هو نقطة فشل محتملة. تطبيق نموذجي يحتوي على مئات الأزرار واللافتات والبطاقات، ويجب أن تتحمّل جميعها زيادة النص.
الحاوية ذات عرض ثابت (width: 120px) وأزرار بحجم ثابت تقطع أو تتجاوز عندما يمتد النص. overflow: hidden يخفي المحتوى بهدوء، في حين overflow: visible يدمر التخطيط.
المستخدمون يرون التسميات مقطوعة مثل 'الإعداد...' بدلاً من 'الإعدادات'، أو أزرار تتداخل مع عناصر مجاورة. الإجراءات الحاسمة تصبح غير مقروءة أو غير قابلة للنقر.
كيف تصلحه
صمم ونفّذ تخطيطاً مرناً يتكيف مع طول المحتوى في جميع اللغات.
استبدل القيم الثابتة للعروض بحدود min-width و max-width وباستخدام Flexbox أو Grid. ضع المساحة بشكل دينامكي.
ضبط حاويات النص على كسر الأسطر: استخدم overflow-wrap: break-word وتجنب white-space: nowrap عند المحتوى المترجم.
اختبر واجهتك باستخدام التوطين الكاذب الذي يطيل كل النص بنسبة 40% لمحاكاة أقصى حالة — قبل إرسال السلاسل إلى المترجمين.
الخطأ رقم 5: تنسيق التاريخ والأعداد
تنسيق التواريخ والأعداد يؤثر على كل عرض للبيانات في تطبيقك: الجداول، المخططات، النماذج، الفواتير، التقارير. حل عالمي يغطي المئات من الحالات.
['لا تقم بتنسيق البيانات أو الأعداد يدويًا باستخدام قوالب السلاسل — استخدم دائمًا واجهات Intl', 'احفظ جميع البيانات بتنسيق ISO 8601 والعملات في أصغر وحدة داخليًا (السنت)', 'اختбр مع لغات محلية تستخدم فواصل عشرية مختلفة وترتيبات تواريخ وأنظمة تقويم مختلفة']
لا تغيّر صياغة البيانات أو الأعداد يدوياً باستخدام قوالب السلاسل — استخدم دائماً واجهات Intl-API.
احفظ جميع البيانات بتنسيق ISO 8601 والعملات في الوحدة الأصغر (سنت) داخلياً.
اختبر مع إعدادات Locale التي تستخدم فواصل عشرية مختلفة وترتيبات تواريخ وأنظمة تقويم مختلفة.
سيناريو نموذجي
المطورون يقومون بتنسيق تاريخ كـ MM/DD/YYYY وسعر كـ $1,234.50 — صحيح للمستخدمين الأميركيين.
يرى المستخدم الألماني التاريخ 03/04/2025 ويفسّره على أنه 3 أبريل (قاعدة DD/MM/YYYY). يبدو أن السعر $1,234.50 يجب أن يكون 1.234,50.
النتيجة: يحجز المستخدم رحلة في التاريخ الخاطئ ويستفسر عن تنسيق السعر. تزداد تذاكر الدعم في السوق الألماني بنسبة 15٪.
لماذا هذا مشكلة
تنسيق التواريخ والأعداد يؤثر على كل عرض للبيانات في تطبيقك: الجداول، المخططات، النماذج، الفواتير، التقارير. حل عالمي يغطي المئات من الحالات.
سلاسل التنسيق المضمنة مثل toLocaleDateString('en-US') أو التنسيق اليدوي باستخدام Template-Literals تتجاهل اللغة الفعلية للمستخدم. حتى لو كانت اللغة الصحيحة، فإن التقويم قد يكون خاطئًا (غريغوري مقابل هجري) يسبب مشاكل.
المستخدمون يقرؤون البيانات بشكل خاطئ ويدخلونها بالتنسيق الخاطئ. مستخدم أوروبي يرى 03/04/2025 قد يفسرها على أنها 3 أبريل بدلاً من 4 مارس — مواعيد مفقودة أو حجوزات خاطئة.
هكذا تصلحه
استخدم واجهة Intl المدمجة أو مكتبة تنسيق محلية لجميع البيانات والأوقات والأعداد والعملات.
استبدل التنسيق اليدوي بـ Intl.DateTimeFormat(locale) للبيانات و Intl.NumberFormat(locale, { style: 'currency', currency }) للأسعار.
احفظ البيانات داخليًا بتنسيق ISO 8601 (YYYY-MM-DD) وصمِّمها للعرض فقط باستخدام locale المستخدم.
اختبر عروض التواريخ/الأعداد الحرجة مع ما لا يقل عن 5 إعدادات لغوية مختلفة: en-US، de-DE، ja-JP، ar-SA و zh-CN، لتغطية أهم أساليب التنسيق.
الخطأ رقم 6: RTL-tale word vergeet
تُستخدم لغات من اليمين إلى اليسار مثل العربية والعبرية والفارسية من أكثر من 500 مليون شخص. ومع ذلك، يتم تصميم أغلب التطبيقات فقط لتخطيط من اليمين إلى اليسار. دعم RTL ليس مجرد قلب النص — يجب عكس واجهة المستخدم كلياً.
['استخدم منذ اليوم الأول خصائص CSS المنطقية حصريًا (inline-start/end، block-start/end)', 'اختبر تطبيقك مع dir='rtl' على عنصر HTML في كل اجتماع Sprint', 'أنشئ قائمة فحص RTL للاختبار على التنقل، الأيقونات، النماذج ومؤشرات التقدم']
استخدم اعتباراً من اليوم الأول خصائص CSS منطقية حصراً (inline-start/end، block-start/end).
اختبر تطبيقك مع dir='rtl' على عنصر HTML في كل مراجعة سبرينت.
إنشئ قائمة فحص RTL للاختبار التنقل والرموز والنماذج ومؤشرات التقدم.
سيناريو نموذجي
المطور يستخدم margin-left: 16px و text-align: left عبر التطبيق بالكامل — ممارسة LTR القياسية.
التطبيق يبدأ في المملكة العربية السعودية. أزرار الرجوع تشير للأمام، وتظهر القوائم الجانبية على الجانب الخاطئ، وتكون البيانات الرقمية محاذاتها غير صحيحة.
النتيجة: المستخدمون العرب يغادرون التطبيق خلال 30 ثانية. الفريق يحتاج إلى 4 أسابيع لإعادة هيكلة CSS الطارئة لحل المشكلة.
لماذا هذا مشكلة
دعم RTL يؤثر على كل مكوّن في تطبيقك. إدخاله لاحقاً عادةً ما يتطلب إعادة كتابة 30-50% من جميع قواعد CSS وفحص كل أيقونة وتخطيط.
خصائص CSS مثل margin-left، padding-right، text-align: left و float: left تقيد الاتجاه. الأيقونات ذات معنى اتجاهي (أسهم، مؤشرات التقدم) تشير في الاتجاه الخاطئ. حتى قيم border-radius يجب عكسها.
المستخدمون العرب يرون التنقل في الزاوية الخاطئة، شريط التقدم يسير إلى الوراء، والنص يتعارض مع عناصر واجهة المستخدم. التطبيق يبدو غريباً وغير قابل للاستخدام.
هكذا تصلحه
استخدم خصائص CSS المنطقية واختبر التخطيط RTL منذ البداية.
استبدل جميع خصائص CSS الفيزيائية بنظائرها المنطقية: margin-left → margin-inline-start، padding-right → padding-inline-end، text-align: left → text-align: start.
ضبط سمة dir على عنصر HTML الجذر بناءً على locale النشط. استخدم CSS :dir(rtl) لتجاوزات RTL.
افحص جميع الأيقونات من حيث معنى الاتجاه. استبدل الأيقونات ذات الاتجاه بنسخ معكوسة أو استخدم CSS transform: scaleX(-1) للسياقات RTL.
الخطأ رقم 7: Beelde met teks
وضع النص داخل الصور — سواء في بانرات رئيسية، أزرار، رسوم بيانية أو لقطات شاشة — هو كابوس ترجمة. كل صورة تحتوي على نص يجب إعدادها بلغات كل مرة، مما يزيد من تكاليف التصميم ويؤخر الإصدارات.
['ضع النص القابل للترجمة دائماً فوق الصور باستخدام طبقة CSS Overlay، وتجنب إدراج نص مترجم داخل الصور المربعة (PNG, JPG).', 'استخدم طبقات نص CSS overlays على الخلفيات لبنرات البطل و CTAs', 'أتمتة توليد لقطات الشاشة لقوائم App Store وصفحات التسويق']
لا تضِف النص المترجم مباشرةً في الصور النقطية (PNG، JPG).
استخدم طبقة Overlay للنص على خلفيات الصور لبانرات البطل وعبارات CTAs.
أوتوماتيّاً توليد لقطات الشاشة لقوائم متجر التطبيقات وصفحات التسويق.
سيناريو نموذجي
يقوم مصمم بإنشاء بانر ترويجي يحتوي على النص 'ابدأ تجربتك المجانية' مدمج مباشرة في الصورة.
فريق التوطين يترجم جميع نصوص واجهة المستخدم، لكن اللافتة في الصفحة الألمانية لا تزال تعرض نصاً إنجليزياً.
النتيجة: صفحة الهبوط الألمانية فيها بانر إنجليزي مُربك. إنشاء بانرات محلية لـ 15 لغة يستغرق 3 أيام من عمل التصميم ويؤخر الإطلاق.
لماذا هذه مشكلة
عادةً تحتوي صفحة التسويق النموذجية على 5-10 صور مع نص. عند وجود 15 لغة، سيكون هناك 75-150 صورة بنسخ مختلفة، يتم إنشاؤها وصيانتها وتحديثها مع كل تغيير في التصميم.
النص المضمن في الصور لا يمكن استخراجه من أدوات الترجمة. كل إصدار محلي يحتاج إلى من المصمم تعديل الملف المصدر يدويًا، ثم تصديره وتحميله.
المستخدمون يرون صوراً فيها نص بلغة أجنبية، أو الأسوأ مزيج من واجهة مستخدم مترجمة وصور لم تُترجم بعد. يبدو ذلك غير متسق ويقوّض ثقة العلامة التجارية.
كيف تصلحها
افصل النص عن الصور باستخدام طبقات Overlay في CSS، وSVGs بعناصر نص قابلة للترجمة، أو توليد الصور بشكل ديناميكي.
استخدم CSS لوضع نص قابل للترجمة فوق خلفيات الصور: ضع طبقة النص باستخدام التمركز المطلق فوق حاوية الصورة.
بالنسبة للرسوم المعلوماتية أو المخططات، استخدم SVGs مع عناصر <text> التي تشير إلى مفاتيح الترجمة بدلاً من إدراج سلاسل نصية خام.
بالنسبة لقطات شاشة التطبيق في مواد التسويق، أوتوماتيكية توليد لقطات الشاشة باستخدام أدوات مثل Fastlane (Mobile) أو Playwright (Web)، والتي تلتقط لقطات الشاشة في كل Locale.
الخطأ #8: عدم معالجة الترجمات الناقصة
الترجمات غالباً ما تكون غير مكتملة أثناء التطوير. تضيف الميزات الجديدة سلاسل نصية أسرع مما يمكن للمترجمين ترجمتها. بدون آلية فallback صحيحة، تتسبب الترجمات الناقصة في تعطل التطبيق، عناصر واجهة مستخدم فارغة، أو مفاتيح ترجمة خام تُعرض للمستخدمين.
['قم دائمًا بتكوين لغة احتياطية واحدة على الأقل في إعداد i18n الخاص بك', 'سجّل مفاتيح الترجمات الناقصة في نظام الرصد لديك للمراجعة', 'حدد حدّاً أدنى لتغطية الترجمات قبل أن تصبح Locale جاهزة للإطلاق']
قم دائمًا بتكوين لغة احتياطية على الأقل في إعدادات i18n.
سجّل المفاتيح المفقودة للترجمة في نظام المراقبة لديك لمتابعتها.
حدّد حدًا أدنى لتغطية الترجمات قبل أن تصبح Locale مفعلة.
سيناريو نموذجي
يقوم المطورون بإضافة قسم 'Premium Features' الجديد مع 15 مفتاح ترجمة جديد. يتم إصدار النسخة الإنجليزية فوراً.
الترجمات الفرنسية ليست جاهزة بعد. الصفحة الفرنسية تعرض مفاتيح خامة مثل: 'premium.feature1.title', 'premium.feature1.description'.
النتيجة: المستخدمون الفرنسيون يرون صفحة معطلة مليئة بمفاتيح المطور. يتلقى فريق الدعم العشرات من تقارير العطل.
لماذا هذه مشكلة
كلما كبرت تطبيقك، زاد الفجوة بين سلاسل النص الإنجليزية والترجمات بلغات أخرى. تطبيق يحتوي على 100 لغة و2000 سلسلة قد يحتوي في أي لحظة على 10,000 ترجمة ناقصة.
بدون آلية فallback، تُعيد مفتاح الترجمة المفقود undefined أو null أو السلسلة الخام (مثلاً 'checkout.confirmButton'). محركات القوالب قد تُصدر أخطاء، وتُعطّل الصفحة، أو لا تُعرض أي شيء.
المستخدمون يرون واجهة مستخدم معطلة: أزرار فارغة، علامات مفقودة، أو سلاسل نص غامضة مثل 'nav.settings.title' بدلاً من نص فعلي. هذا مربك وغير مهني.
كيف تصلحها
قم بتكوين سلسلة فallback قوية ومراقبة التغطية الترجمية عبر كل اللغات.
اعدد سلسلة لغوية فallback في إعدادات i18n الخاصة بك: تُ transparently ترجمة المفتاحية الفرنسية المفقودة تلقائياً إلى الإنجليزية (en).
أضف مُعالج مفتاح مفقود يسجل المفاتيح غير المترجمة إلى نظام الرصد لديك (مثلاً Sentry, Datadog) دون تعطيل تجربة المستخدم.
أنشئ لوحة تغطية الترجمات التي تتعقب نسبة الإنجاز لكل Locale وتوقف الإصدارات عندما تكون التغطية أقل من عتبة محددة (مثلاً 95%).
خطأ #9: مشاكل ترميز الأحرف
مشاكل ترميز هي القاتل الصامت للمحلية. كل شيء يبدو جيداً باللغة الإنجليزية وباللغات الأوروبية، ولكن عند إضافة الصينية واليابانية والكورية والعربية أو الرموز التعبيرية، تظهر أحرف مشوهة (Mojibake). هذه الأخطاء صعبة التتبع.
['استخدم ترميز UTF-8 في كل مكان — نصوص المصدر، قاعدة البيانات، استجابات API ووسوم HTML', 'استخدم utf8mb4 في MySQL (ليس utf8 فقط)، لدعم جميع نطاق Unicode بما في ذلك الرموز التعبيرية', 'اختبر المحتوى الحقيقي في CJK والعربية والرموز التعبيرية للكشف عن مشاكل الترميز مبكراً']
استخدم ترميز UTF-8 في كل مكان — ملفات المصدر، قاعدة البيانات، استجابات API وعلامات HTML الميتا.
استخدم utf8mb4 في MySQL (لا utf8) لدعم كامل نطاق Unicode بما فيها الإيموجي.
اختبر بمحتوى حقيقي باللغات CJK والعربية والرموز التعبيرية مبكراً لكشف مشاكل الترميز.
سيناريو نموذجي
يقوم المطورون بإعداد قاعدة بيانات MySQL باتنسيق latin1 كإعداد افتراضي قديم. شفرة التطبيق المصدرية تستخدم UTF-8.
يقوم المستخدمون اليابانيون بتسجيل أسمائهم الحقيقية. قاعدة البيانات تُخزن '田中太郎' كبايتات تالفة.
النتيجة: يعرض ملف تعريف المستخدم نصاً مشوّهاً. الأسوأ من ذلك: البحث والترتيب يتعطّلان لجميع أسماء CJK، وهذا يؤثر على آلاف المستخدمين.
لماذا هذه مشكلة
مشاكل الترميز تنتشر عبر كامل النظام. قد تدمر الحروف متعددة البايت بسبب تعيين قاعدة البيانات بشكل غير صحيح — الإصلاح يتطلب ترحيل بيانات مكلف.
عدم الاتساق في الترميز عبر التكديس — UTF-8 في ملفات المصدر، Latin-1 في قاعدة البيانات و Windows-1252 في استجابة API — يدمر الأحرف متعددة البايت. طبقة خاطئة الإعداد واحدة يمكن أن تحول '日本語' إلى '????' أو '日本èª'.
المستخدمون يرون نصوصاً مشوّهة، علامات استفهام أو مربعات فارغة حيث يجب أن تكون لغتهم. في أسوأ الحالات، يمكن أن تتلف مدخلات النماذج في قاعدة البيانات بشكل دائم.
كيف تحله
فرض ترميز UTF-8 بشكل موحّد عبر كل طبقة من طبقات التطبيق لديك.
اضبط جميع ملفات المصدر لديك على UTF-8 (عيّن المحرر الخاص بك و .editorconfig). أضف <meta charset='UTF-8'> إلى HTML الخاص بك و 'Content-Type: application/json; charset=utf-8' في استجابات API.
قم بتكوين قاعدة البيانات الخاصة بك على utf8mb4 (ليس utf8 فقط، وهو مجموعة بايت ثلاثية في MySQL). اضبط ترتيب الاتصال على utf8mb4_unicode_ci.
اختر خطوط تغطي أنظمة الحروف المستهدفة: لاتيني، سيريلك، CJK، عربي، وديفاناغاري. استخدم مجموعات خطوط النظام أو Google Fonts مع تجميعات اللغة للتحميل الأمثل.
اختبار تنفيذ i18n الخاص بك.
اختبار تمديد الطول
قم بزيادة طول جميع السلاسل المترجمة بنسبة 30-40% لمحاكاة اتساع النص في لغات طويلة مثل الألمانية والفنلندية واليونانية. يساعد ذلك في التعامل مع نوافذ بعرض ثابت وعناوين قصيرة وأزرار تتجاوز المساحة قبل البدء بالترجمة.
"إرسال" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
التوطين الوهمي
التوطين الوهمي يحلّ كل حرف بمكافئ مُزخرف (مثلاً 'a' → 'á') ويحيط السلاسل بعلامات مثل [!! و !!]. بذلك يظهر فوراً أي السلاسل مضمنة في الشفرة وأيها تأتي من نظام الترجمة. نفّذ التوطين الوهمي كجزء من خط أنابيب CI لديك لاكتشاف الانحدارات تلقائياً.
كل نص على الشاشة ليس داخل علامات [!! !!] فهو مُدْمج داخلياً ويجب استبعاده من نظام الترجمة. يلتقط هذا الاختبار 95% من السلاسل غير المترجمة خلال دقيقة واحدة.
"إرسال رسالة" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
اختبار RTL-t تخطيط
حتى بدون ترجمات عربية أو عبرية، يمكنك اختبار تخطيط RTL بإضافة dir='rtl' إلى جذر عنصر HTML لديك. هذا يكشف فوراً عن عيوب CSS الاتجاهية: أيقونات غير محاذاة بشكل صحيح، الهوامش على الجانب الخاطئ، التنقل المعطّل وعناصر Flex غير مرتبة بشكل صحيح. اجعله فحصاً قياسياً في كل مراجعة Sprint — يستغرق 10 ثوانٍ للتحويل ويكشف عن مشاكل قد تستغرق أسابيع لإصلاحها في الإنتاج.
قائمة تدقيق i18n
['جميع السلاسل القابلة للمستخدم في ملفات الموارد منفصلة', 'لا تستخدم ربط السلاسل لتكوين جمل', 'تم تنفيذ قواعد الجمع باستخدام ICU MessageFormat أو ما يعادلها', 'استخدام واجهات برمجة تعتمد على locale لتنسيق التواريخ والأوقات والأعداد', 'تم اختبار التخطيط من اليمين إلى اليسار مع محتوى عربي أو عبري', 'واجهة مستخدم مرنة بدون عروض ثابتة للنصوص', 'تم إعداد لغة احتياطية واختبارها عند وجود مفاتيح مفقودة', 'ترميز UTF-8 موحد عبر جميع الملفات وقواعد البيانات', 'تم تخصيص بيانات App Store و Play Store لكل سوق محلياً', 'تم تحديث لقطات الشاشة والمواد التسويقية لكل لغة']