سير عمل التعريب للواجهات الويب والأصلية الذي يصمد

ما الذي يذهب خطأ عندما يكون التعريب دون إدارة

عادةً ما يتعثر التعريب غير المُدار بأخطاء صغيرة مزعجة أولاً، ثم بأخطاء مكلفة لاحقًا. تسمية كانت مناسبة البارحة تصبح اليوم مُتجاوزة. مفتاح مفقود يظهر كمُعرّف خام. صيغة جمع تبدو سليمة بالإنجليزية تصبح خاطئة أو حتى غير لائقة بلغة أخرى.

تُصلح الفرق نفسها معظم المشكلات تحت الضغط:

• أزرار مقصوصة، عناوين مقطوعة، أو نص يتداخل مع الأيقونات
• مفاتيح مفقودة تُرجع إلى الإنجليزية أو تعرض اسم المفتاح
• صيغ جمع خاطئة (مثل "1 items") وقواعد نحوية مكسورة في لغات مُميّزة بالجنس
• صياغة غير متسقة لنفس المفهوم عبر الشاشات
• تعديلات سريعة في اللحظة الأخيرة لأن شاشة شُحنت بدون ترجمات

تفشل شاشات الويب والنسخة الأصلية بطرق مختلفة أحيانًا. على الويب، التصاميم المرنة قد تُخفي المشاكل حتى يظهرها عرض محدد أو متصفح معين. يمكن أن يلتف النص غير متوقع، يدفع الأزرار للأسفل، أو يكسر شبكة التخطيط. في التطبيقات الأصلية، المسافات أكثر صرامة. ترجمة طويلة قد تدفع عناصر مهمة خارج الشاشة، تتصادم مع أحجام الخط للمساعدة، أو تُقص لأن المكوّن لا يعيد التحجيم تلقائياً.

سير عمل تعريب قوي يمنع معظم هذا بجعل المفاتيح ثابتة، والترجمات قابلة للمراجعة، وفحوصات الواجهة روتينية. يساعدك على شحن التحديثات مع مفاجآت أقل. ما لا يستطيع إصلاحه هو نص المصدر الغامض. إذا كان النص الأصلي غامضًا (مثل "Open" أو "Apply" بدون سياق)، فستبقى الترجمة تخمينًا.

تعريف بسيط للنجاح ليس "كل شيء مترجم." بل هو:

• تظل الواجهة قابلة للقراءة عبر شاشات الويب والنسخة الأصلية
• التحديثات سريعة لأن المفاتيح لا تتغير باستمرار
• تكتشف QA المشكلات قبل المستخدمين

مثال: إذا أظهرت شاشة السلة "{count} item(s)", فإن السلاسل غير المُدارة تؤدي إلى صيغ جمع محرجة ومساحات مكسورة. النهج المُدار يجبرك على قواعد جمع صحيحة ويكشف الزر الذي يكبر بنسبة 30% بالألمانية قبل الإصدار.

قرّر التملك ومصدر الحقيقة الواحد

ينهار سير عمل التعريب أسرع ما يكون عندما لا يستطيع أحد الإجابة على سؤال واحد: "ما النص الحقيقي؟" اختر مصدر حقيقة واحد للسلاسل واجعله واضحًا بشكل ممل. قد يكون هذا المصدر ملفًا في الريبو، منصة ترجمة، أو جدولًا داخليًا، لكنه يجب أن يكون مكانًا واحدًا يفوز في كل نزاع.

عرّف الأدوار بحسب القرارات لا بحسب المسميات الوظيفية. يحتاج أحدهم للموافقة على المعنى والنبرة (غالبًا المنتج أو التسويق). يحتاج أحدهم للحفاظ على ثبات المفاتيح وقابليتها للاستخدام في الشيفرة (غالبًا الهندسة). يحتاج أحدهم لحماية قيود الواجهة (غالبًا التصميم)، وخصوصًا عندما تتصرف شاشات الويب والنسخة الأصلية بشكل مختلف.

تقسيم واحد يتجنّب معظم الصراعات:

• منشئ المفتاح: الشخص الذي يشحن الشاشة يُنشئ مفاتيح جديدة عندما تحتاج الواجهة لنص جديد.
• الموافق على الصياغة: مدير المنتج أو مالك النص يوافق على النص في لغة الأساس.
• محرر الترجمة: المترجمون يمكنهم تعديل الترجمات، لكن لا يمكنهم إعادة تسمية المفاتيح.
• تغييرات المفاتيح: فقط مالك المفتاح يمكنه إهماد أو دمج المفاتيح، مع ملاحظة تشرح السبب.

حدّد توقّعات زمن الاستجابة حتى لا تتوقف الإصدارات. على سبيل المثال: طلبات مفاتيح جديدة يتم الإقرار بها خلال يوم عمل واحد، الموافقة على صياغة المصدر خلال يومين، والإصلاحات الحرجة (واجهة مكسورة، نص قانوني خاطئ) خلال ساعات.

مثال ملموس: يبني فريقك تدفّق "إعادة تعيين كلمة المرور" جديدًا لكل من الويب والنسخة الأصلية. يضيف المطوّر المفاتيح، يوافق مدير المنتج على النص الإنجليزي النهائي، ويملأ المترجمون اللغات الأخرى. إذا لاحظ مترجم أنّ "Reset" يجب أن تكون "Change"، فإنه يعدّل الترجمات، لكن المفتاح يبقى كما هو. إذا أراد مدير المنتج إعادة استخدام نص عبر الشاشات، فقط مالك المفتاح يجري التغيير الهيكلي حتى لا يخرّب شيء بصمت.

استراتيجية المفاتيح: إعادة الاستخدام، الثبات، وحدود الشاشة

يبدأ سير عمل تعريب جيد بقاعدة واحدة: المفاتيح مُعرّفات، ليست جملًا إنجليزية. عاملها كأرقام قطع. إذا غيرت الصياغة لاحقًا، يجب عادةً أن يبقى المفتاح نفسه.

انشئ مفتاحًا جديدًا عندما يكون المعنى مختلفًا. أعد استخدام مفتاح عندما يكون المعنى نفسه، حتى لو اختلفت الشاشة. "حفظ" في شاشة الملف الشخصي و"حفظ" في شاشة الإعدادات يمكن أن يشتركا في مفتاح إذا كانا يقصدان "تخزين التغييرات". لكن "حفظ" بمعنى "إشارة مرجعية" يجب أن يكون مفتاحًا مختلفًا لأن المترجمين قد يحتاجون فعلًا مختلفًا.

افصل تسميات الواجهة القصيرة عن المحتوى الأطول. تسمية زر، تلميح مساعد، ورسالة خطأ غالبًا ما تُترجم بشكل مختلف ولها حدود طول مختلفة. الحفاظ عليها كمفاتيح منفصلة يسهل ضبط النبرة والترقيم دون كسر شاشات أخرى.

حدود الشاشة دون فرض صياغة موحّدة

اسعَ لإعادة الاستخدام عبر الويب والنسخة الأصلية، لكن لا تُجبر ذلك عندما تحتاج المنصات إلى لغة مختلفة. طلب إذن أصلي غالبًا ما يحتاج نصًا أوضح وأكثر رسمية من تلميح ويب. في هذه الحالة، احتفظ بنفس المفهوم لكن استخدم مفاتيح مخصّصة للمنصة حتى تقرأ كل واجهة بطبيعتها.

نمط عملي هو تجميع المفاتيح حسب الميزة ونوع الواجهة، ثم إعادة الاستخدام ضمن هذه الحدود:

• إعادة الاستخدام داخل نفس الميزة عندما يكون المعنى متماثلًا
• فصل المفاتيح حسب نوع الواجهة (تسمية vs مساعدة vs خطأ vs مطالبة نظام)
• استخدم متغيرات المنصة فقط عندما يجب أن تختلف الصياغة
• حافظ على ثبات المفاتيح وغيّر النص الظاهر فقط
• أضف ملاحظات سياقية (مكان الظهور، حدود الأحرف)

على سبيل المثال، قد يوجد إجراء "حذف عميل" نفسه في لوحة إدارة الويب وتطبيق ميداني أصلي. قد تُعيد استخدام تسمية الإجراء الأساسية، لكن تحتفظ بمفتاح منفصل لنص التأكيد في الأصلية إذا احتاج تحذيرات أقوى أو أسطر أقصر.

تسمية وتنظيم مفاتيح الترجمة

نظام تسمية جيد يجعل التعريب مملاً بأفضل معنى. يستطيع الناس العثور على السلاسل بسرعة، يحصل المترجمون على السياق، وتبقى المفاتيح ثابتة حتى عندما يتغير النص.

استخدم اتفاق تسمية قابل للقراءة يُجيب عن أربعة أسئلة: أين هو، ما هو، لأي غرض، وهل هو متغير. نمط بسيط يعمل عبر الويب والنسخة الأصلية هو:

<product_or_domain>.<screen_or_flow>.<component>.<purpose>[.<variant>]

على سبيل المثال، في بوابة العملاء: portal.login.button.submit أو portal.orders.empty_state.title. هذا يُبقي المفاتيح مجمعة حسب الشاشة أو التدفق مع سهولة البحث حسب المكوّن.

المفاتيح السيّئة إما غامضة جدًا أو مرتبطة بالنص الإنجليزي الحالي:

• جيد: portal.profile.field.email.label
• سيّئ: emailText (لا نطاق، لا نية)
• سيّئ: please_enter_your_email (ينهار عندما يتغير النص)
• جيد: portal.checkout.error.payment_failed
• سيّئ: error_12

يجب أن تكون المتغيرات صريحة، لا مُختلطة بعلامات ترقيم أو حالة أحرف. إذا احتجت تسمية أقصر لعناوين موبايل ضيقة، أضف لاحقة متغير: ...title.short مقابل ...title.long. إذا احتجت اختلاف حالة الحروف، فضّل مفاتيح منفصلة مثل ...button.save و ...button.save_titlecase فقط عندما لا تستطيع المنصة تحويل النص بأمان.

المُتغيرات النائبة تحتاج قواعد حتى لا يخمن المترجمون.

• استخدم عناصر نائبة مسمّاة: {user_name}, {count}, {date}
• لا تُجمّع أبدًا: لا تبنِ سلاسل مثل "Hello " + name
• احتفظ بالوحدات ضمن السلسلة عندما تعتمد على اللغة: {count} items وليس {count} + " items"
• عرّف الصيغ المسموح بها: تواريخ ISO، عملات، أو تنسيقات تواريخ خاصة بالمنصة
• أضف ملاحظة قصيرة للسلاسل المعقدة (مثلما إذا كان {count} يمكن أن يكون صفرًا)

قواعد الجمع والنحو التي توفر إعادة عمل

الجمع هو مكان تحطّم سير العمل عادةً أولًا. تفترض فرق كثيرة أن كل لغة لها "واحد" و"كثير" فقط، ثم تكتشف أن الواجهة تبدو خاطئة أو تحتاج إصلاحات في اللحظة الأخيرة.

يمكن للغات أن تحتوي على عدة فئات للجمع. الإنجليزية تستخدم غالبًا one و other، لكن لغات مثل الروسية، البولندية، العربية، والتشيكية قد تستخدم صيغًا مثل few أو many أو zero. إذا برمجت نمطًا واحدًا مبكرًا، ستجد نفسك تعيد كتابة السلاسل عبر الويب والأصلية لاحقًا.

اختر معيارًا واحدًا لسلاسل الجمع والتزم به في كل مكان (الويب، iOS، Android، نصوص مُولدة من الخادم). نهج عملي هو تخزين مفتاح واحد مع صيغ الجمع بدلًا من مفاتيح منفصلة لكل صيغة. استند إلى فئات CLDR حتى تطابق قواعد اللغة الحقيقية.

قاعدة تمنع إعادة العمل: لا تبنِ جمل الواجهة من قطع مثل "You have " + count + " messages". ترتيب الكلمات قد يتغير، وبعض اللغات تحتاج نهايات أو حالات مختلفة بناءً على العدد.

نمط مفتاح عملي

لعداد الرسائل، عرّف مفتاحًا ثابتًا واحدًا وضع الرقم كمعامل. ثم قدّم الصيغ التي يحتاجها المترجمون لكل لغة.

• استخدم مفتاحًا واحدًا لكل مفهوم (مثال: inbox.message_count)
• دعم صيغ CLDR (zero, one, two, few, many, other)
• دائمًا استخدم عناصر نائبة (مثال: {count}) داخل الجملة الكاملة
• أضف ملاحظات للمترجم عندما يكون المعنى غير واضح (هل هو "رسائل" أم "رسائل غير مقروءة"؟)

الجنس والحالات النحوية

أحيانًا صيغ الجمع لا تكفي. إذا كانت الواجهة تُخاطب شخصًا ("Welcome, Alex") أو تشير إلى أدوار ("assigned to him/her"), بعض اللغات تحتاج كلمات مختلفة حسب الجنس. لغات أخرى تغيّر النهايات طبقًا للحالة النحوية بعد حروف جر معينة.

عند حدوث ذلك، اصنع سلاسل منفصلة للقواعد النحوية المختلفة فعلًا، لا لمجرد أسلوب. الهدف هو عدد أقل من المفاتيح، لكن أيضًا مفاجآت أقل أثناء QA عندما تكون الترجمة "صحيحة" لكنها تقرأ بشكل خاطئ في السياق.

تنسيقات وقيود التخطيط عبر المنصات

قد تكون الترجمة صحيحة وتكسر الواجهة في الوقت نفسه. تُعرض النصوص على الويب والأصلية بطرق مختلفة، لذا يجب أن يتضمن سير العمل قواعد تنسيق وفحوصات تخطيط، ليس تحويلاً للنصوص فقط.

وحدّث كيفية عرض الأرقام، النقود، والتواريخ. تجنّب بناءها بالتجميع مثل "$" + amount أو تشفير نمط تاريخ داخل تسمية. استخدم تنسيقات محلية حتى تتطابق الفواصل والترتيب (1,000.50 مقابل 1 000,50؛ يوم-شهر-سنة مقابل شهر-يوم-سنة). مناطق التوقيت فخ شائع: خزّن الطوابع الزمنية UTC، ونسّقها بمنطقة المستخدم، وبيّن متى يكون الوقت في منطقة محددة.

اتجاه النص ككسر صامت آخر. إذا دعمت لغات من اليمين إلى اليسار، خطّط لتصاميم مرآت وعلامات ترقيم قد "تتحرّك". أيقونات التي تشير للاتجاه (أسهم، زر رجوع، خطوات تقدم) غالبًا ما تحتاج الانعكاس. اجعل تمريرة RTL سريعة جزءًا من المراجعة حتى لو لم تدعم RTL بالكامل بعد.

على الموبايل، الخطوط والمسافات قد تتغير أكثر من الويب. سلسلة تناسب الويب قد تنثني بشكل محرج في SwiftUI أو Kotlin. حدّد حجم خط آمن أدنى، اسمح للتسميات بالالتفاف حيث يناسب، وعرّف خطوطًا احتياطية للكتابات التي لا يغطيها خطك الافتراضي.

احتياجات الوصول تتطلّب فحوصًا معرّبة أيضًا. يقرأ قارئ الشاشة الأرقام والاختصارات والنصوص متعددة اللغات بطرق مفاجئة.

قواعد حماية تخطيط تمنع معظم المشكلات:

• صمّم لتوسع النص (30-50%) وتجنّب الأزرار بعرض ثابت.
• احتفظ بالقيم الديناميكية (العدادات، الأسعار، التواريخ) كرموز مُهيَّأة منفصلة.
• استخدم محوّلات التواريخ والأرقام الخاصة بالنظام، لا أنماط مخصّصة.
• اختبر لغة RTL واحدة ولغة "طويلة النص" واحدة قبل الإصدار.
• نفّذ فحوصات قارئ الشاشة على التدفقات الأساسية (تسجيل الدخول، سلة الشراء، الإعدادات).

مثال: تسمية "إجمالي: $1,234.50" قد تحتاج أن تصبح "1 234,50 €" مع الرمز بعد القيمة، تباعد مختلف، ووقفة مناسبة لقارئ الشاشة بين "إجمالي" والمبلغ.

خطوة بخطوة من الشاشة الجديدة إلى الإصدار

يجب أن يبدأ سير عمل التعريب أبكر مما يتوقّع معظم الفرق: أثناء تصميم الشاشة نفسها. إذا انتظرت حتى تكون الواجهة "منتهية"، ستنتهي بتسريع الترجمات، شحن نصوص مقصوصة، أو تشفير سلاسل "مؤقتًا".

ابدأ بإضافة مفتاح ترجمة أثناء تصميم كل تسمية، زر، ورسالة. اكتب النص الافتراضي بلغة الأساس، وأرفق سياقًا سريعًا مثل مكان ظهوره وماذا يفعل الإجراء. مفتاح مثل checkout.pay_button مفيد فقط إذا عرف المترجمون ما إذا كان فعلاً فعلًا ("ادفع") أم تسمية لقسم ("الدفع").

نفّذ الواجهة باستخدام عناصر نائبة والنص الافتراضي كتحوّط. اجعل المتغيّرات صريحة (مثل {name} أو {count}) وتجنّب خياطة الجمل معًا. هذه إحدى أسرع الطرق لكسر النحو عبر اللغات.

عند إرسال النصوص للترجمة، أرفق ما يحتاجه المترجمون للدقة: لقطة شاشة لكل شاشة (أو فيديو قصير إذا تغيّر النص)، حدود الأحرف للأماكن الضيقة (ألسنة، أزرار، شارات)، ملاحظات عن النبرة والمصطلحات، وقائمة العناصر النائبة الديناميكية وما تعنيه.

بعد عودة الترجمات، ادمجها مبكرًا وابنِ نسخ الويب والأصلية. قم بفحوص واجهة سريعة على الشاشات ذات المخاطر العالية: تسجيل الدخول، البدء، سلة الشراء، والإعدادات. ابحث عن نص مقصوص، عناصر متداخلة، مفاتيح مفقودة، وصيغ جمع خاطئة.

أخيرًا، أطلق وراقب. تعقّب المفاتيح المفقودة، أحداث الرجوع إلى النص الافتراضي، والشاشات التي ينسكب فيها النص كثيرًا.

زوّد المترجمين بما يحتاجونه للدقة

الترجمات الدقيقة تبدأ قبل ترجمة كلمة واحدة. إذا رأى المترجمون مفتاحًا وعبارة إنجليزية فقط، فهم يخمنون. هكذا تحصل على الكلمات الصحيحة في المكان الخطأ وواجهة تبدو غريبة أو غير لائقة.

"حزمة سياق" بسيطة تزيل معظم التخمين. لكل سلسلة، أضف مكان الظهور (الشاشة والمكوّن)، ما يحاول المستخدم فعله، والنبرة (ودية، رسمية، عاجلة). كما ذكر ما إذا كانت تسمية زر، رسالة خطأ، عنصر قائمة، أو نص مساعد—فئات تُترجم بطرق مختلفة.

عند ضيق المساحة، اذكر ذلك مقدمًا. شاشات الويب والنسخة الأصلية تنهار بطرق مختلفة، لذا حدّد الحدود عندما تكون مهمة: تسميات الأزرار القصيرة، عناوين التبويب، رسائل التنبيه الصغيرة، وأي شيء داخل بطاقة عرض ثابتة. إذا يجب أن يبقى النص في سطر واحد، اذكر ذلك. إذا كانت فواصل الأسطر مقبولة، اذكر الأماكن الآمنة للانقسام.

علّم الأجزاء "غير قابلة للترجمة" بوضوح. أسماء المنتجات، خطط التسعير، أكواد القسائم، حقول API، وعناصر نائبة مثل {name} يجب أن تبقى كما هي. بدون توجيه، قد يترجمها المترجمون ويتوقف التطبيق عن الاتساق.

حزمة عملية لكل سلسلة:

• لقطة شاشة أو اسم الشاشة (مثال: "Checkout - Payment method")
• النوع والهدف (زر يؤكد الدفع)
• ملاحظة النبرة (هادئة، مطمئنة)
• قيود (حد أقصى 18 حرفًا، سطر واحد)
• الرموز المحمية (أسماء المنتجات، التكاملات، {amount})

عامِل النصوص القانونية ومحتوى الدعم كقنوات منفصلة. النص القانوني غالبًا ما يحتاج موافقات ووقت تحديث أبطأ، فاحتفظ به منفصلًا ونسّق إصداراته بعناية. مقالات الدعم عادة تحتاج ترجمة أطول وقد تعيش في نظام أو مجموعة ملفات مختلفة.

مثال: زر "متابعة" على الجوال قد يحتاج حدًا أكثر صرامة من الويب. إذا عرف المترجمون ذلك، يمكنهم اختيار فعل أقصر في اللغات التي تتمدد بدلًا من فرض إعادة تصميم الواجهة في اللحظة الأخيرة.

حلقة QA والمراجعة التي تمنع واجهة مكسورة

مشكلات واجهة بسبب التعريب نادرًا ما تظهر كبَغ في البداية. تبدو كمفتاح مفقود، زِر يلتف إلى سطرين، أو عنصر نائِب يظهر القيمة الخاطئة. يشمل سير العمل الجيد خطوات QA تُظهر هذه المشكلات قبل المستخدمين.

ابدأ بمحاكاة التعريب في نسخ التطوير. استبدل السلاسل الحقيقية بنسخ أطول ومزخرفة (مثل "[!!! Šéttïñĝš !!!]") وزد الطول بنسبة 30-50%. هذا يكشِف بسرعة الاقتطاع، التداخل، والنصوص المشفّرة على الويب والأصلية.

أضف فحوصات آلية على كل بناء. تلتقط الأخطاء المملة التي قد يفوتها البشر عند مراجعة مئات السطور:

• المفاتيح المفقودة في أي لغة (الرجوع يخبئ المشاكل حتى وقت لاحق)
• المفاتيح غير المستخدمة (علامة على تراكم نص ميت)
• عدم تطابق العناصر النائبة ("Hello, {name}" vs "Hello, {username}")
• صيغ جمع غير صالحة للغة (zero, one, few, many)
• أنماط ممنوعة مثل HTML خام في نصوص الموبايل

ثم استخدم حلقة توقيع يدوي واضحة. المنتج يتحقق من المعنى والنبرة للشاشات الرئيسية، بينما يراجع QA التخطيط والتفاعل.

حافظ على مصفوفة الاختبار صغيرة لكن صارمة. لا تختبر كل شيء. اختبر ما ينهار أولاً: تسجيل الدخول/التسجيل، إعادة تعيين كلمة المرور، الدفع أو تأكيد الشراء، الإعدادات وتعديل الملف الشخصي، الإخطارات وحالات الفراغ، وأي شاشة بها جداول، شارات، أو أزرار ضيقة.

عند الإبلاغ عن مشكلات، اجعل الإصلاح سهلًا بكونك محددًا. أضف اللغة، الجهاز وإصدار النظام (أو المتصفح والعرض)، النص المتوقع، النص الفعلي، ولقطة شاشة تُظهر المنطقة المقطوعة. إذا كان الأمر يتعلق بصيغ الجمع أو العناصر النائبة، الصق المفتاح الدقيق والسلسلة المولّدة.

أخطاء شائعة وكيفية تجنبها

معظم أخطاء التعريب ليست "مشكلة ترجمة" بقدر ما هي مشكلة سير عمل تظهر على شكل واجهة مكسورة، نص مفقود، أو رسائل مربكة.

فخ شائع هو إعادة تسمية المفاتيح عندما تريد فقط تغيير الصياغة. يجب أن تبقى المفاتيح معرّفات ثابتة، لا النص نفسه. إذا غيّرت checkout.button.pay إلى checkout.button.pay_now، تصبح كل الترجمات القديمة "مفقودة" وتفقد التاريخ. احتفظ بالمفتاح، حدّث النص في لغة الأساس، وأضف سياقًا إذا تغيّر المعنى.

مشكلة متكررة أخرى هي تشفير النص على منصة واحدة. فريق الويب يستخدم مفاتيح، لكن فريق الموبايل يضع نصًا حرفيًا لحل سريع. بعد شهر، يرى المستخدمون تنبيهات باللغة الإنجليزية فقط على iOS. اجعل قاعدة "لا نصوص ثابتة للمستخدم" قاعدة مشتركة للويب والأصلية.

العناصر النائبة تسبب أخطاء دقيقة عندما تفترض ترتيب كلمات. الإنجليزية تعمل مع "{count} items"، لكن لغات أخرى قد تحتاج ترتيبًا مختلفًا أو كلمات إضافية. استخدم عناصر نائبة مسمّاة (ليست رقمية) واحتفظ بتناسقها عبر المنصات.

أخطاء جديرة بالقبض عليها مبكراً:

• معاملة المفاتيح كنسخ نصية وتكسير الترجمات. اجعل المفاتيح ثابتة.
• إعادة استخدام مفتاح لمعنيين. افصل المفاتيح عندما يختلف الغرض.
• خلط أنماط العناصر النائبة (بعضها مسمّى، وبعضها مرقم). اعتمد نمطًا واحدًا.
• الاختبار بالإنجليزية فقط. داوم على اختبار لغة طويلة ولغة مدمجة.
• الشحن بدون خطة بديلة. عرّف ما يحدث عند فقدان مفتاح.

اختبار لغة طويلة واحدة لا يكفي. الألمانية غالبًا ما تتمدد، بينما الصينية قد تخفي مشكلات الفراغ. قم بمرور سريع على كلتا الحالتين، واختبر حالات جمع حواف مثل 0، 1، و2.

اتفق على سلوك الرجوع قبل الإصدار. مثال: إذا كانت الفرنسية مفقودة، اعتمد الرجوع إلى الإنجليزية، سجّل المفاتيح المفقودة، وعرّض الإصدار فقط إذا كانت الشاشات الحرجة بها ثغرات.

قائمة تحقق سريعة وخطوات عملية لاحقة

يبقى سير عمل التعريب صحيًا عندما تكون الفحوص صغيرة ومتكررة. الهدف واضح: سلاسل أقل مفاجئة، تصميمات أقل تكسُّرًا، وضغط ترجمة أقل في اللحظة الأخيرة.

قبل دمج تغيير واجهة، قم بمرور سريع على الأخطاء الشائعة:

• المفاتيح الجديدة تتبع قواعد التسمية وتقع في النطاق الصحيح (الشاشة أو الميزة).
• العناصر النائبة تتطابق تمامًا عبر اللغات (نفس المتغيرات، نفس المعنى).
• صيغ الجمع مكتملة للغات التي تدعمها (ليس مجرد مفرد/جمع بالإنجليزية).
• لا نص مشفّر يبقى في الواجهة (بما في ذلك حالات الخطأ وحالات الفراغ).
• النص الجديد أو المتغيّر يحتوي على سياق أساسي (لقطة شاشة أو ملاحظة واضحة).

قبل الشحن، قم بجولة QA قصيرة تركز على الأماكن التي ينهار فيها التعريب أولاً. اجعلها محددة بالزمن لكن متسقة: أهم التدفقات على كل منصة تشحنها، فحص RTL واحد، شاشات النص الطويل (الإعدادات، النصوص القانونية، البدء، الجداول، الأزرار الضيقة)، وتنسيق التاريخ/الرقم/العملة في بعض اللغات.

حدّد وتيرة تتوافق مع فريقك. كثير من الفرق تحدّث الترجمات أسبوعيًا، ثم تجمّد السلاسل قبل الإصدار بيوم إلى يومين. الفكرة تجنّب خلط تعديلات النص اللحظية مع QA النهائي.

خطوات سريعة تُؤتي ثمارًا: وثّق اتفاقياتك (تسمية المفاتيح، العناصر النائبة، قواعد الجمع، التملك)، ثم نفّذ شاشة تجريبية واحدة من البداية للنهاية وعدِّل بناءً على ما انهار.

إذا كنت تبني عبر الخادم، واجهة الويب، والموبايل في منصة واحدة مثل AppMaster، فسيكون أسهل للحفاظ على المفاتيح والعناصر النائبة متسقة لأن نفس الشاشات والمنطق يمكن أن يشارك اتفاقًا واحدًا. الحفاظ على ذلك ثابتًا هو ما يجعل التعريب يشعر روتينيًا بدلًا من هش.