اختبار تعريب واجهات التطبيقات: صيغ الجمع والمتغيرات و RTL قبل الإطلاق

المصطلح الصحيح لا يعني واجهة عربية صحيحة

قد يراجع محرر قائمة المصطلحات ويوافق على ترجمة كلمة «ملف» أو «جلسة»، ثم تظهر للمستخدم عبارة «2 ملفات تم رفعها» أو ينقلب ترتيب عنوان بريد إلكتروني داخل رسالة عربية. هذه ليست مشكلة اختيار كلمة مفردة فقط؛ إنها مشكلة توليد النص بحسب العدد والسياق واتجاه الكتابة وطريقة إدخال المتغيرات. يركز هذا الدليل على ضمان جودة تعريب واجهة تطبيق تعمل بالفعل، لا على كتابة مقال تقني أو إنشاء معجم مصطلحات. سنختبر الرسائل الديناميكية والأرقام والأزرار ورسائل الأخطاء على حالات حقيقية قابلة للتكرار. ينبغي أن يشترك في الفحص محرر عربي ومطور ومختبر واجهات؛ لأن الخطأ قد ينشأ من النص أو القالب أو تنسيق البيانات أو CSS.

ابدأ بجرد الرسائل الديناميكية لا الشاشات فقط

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

صيغ الجمع العربية ليست استبدال حرف في النهاية

تدعم قواعد CLDR تصنيفات لغوية مثل zero و one و two و few و many و other، وتختلف طريقة اختيارها بحسب اللغة والقيمة. في العربية لا يكفي قالب إنجليزي يضيف حرفًا إلى الاسم عند العدد الأكبر من واحد. يجب أن تُترجم الجملة كاملة لكل صيغة مستخدمة، وأن يختبر النظام القيم الصفرية والمفرد والمثنى والمجموعات العددية والكسور حيث تظهر. لا تعتمد على قاعدة مكتوبة يدويًا من نوع if count > 1، ولا تفترض أن اسم التصنيف few يعني العدد الصغير نفسه في كل لغة. استخدم محرك تنسيق معتمدًا في التطبيق مثل ICU MessageFormat أو واجهة Intl.PluralRules مع بناء جمل مناسب، ثم اختبر المخرجات بصريًا ولغويًا.

اختبار القيم الحدية بدل فحص رقمين

جهز جدولًا يضم 0 و 1 و 2 و 3 و 5 و 10 و 11 و 20 و 99 و 100 و 101، وأضف القيم الكسرية إن كان المنتج يعرضها. ليس المطلوب أن تكون كل صيغة مختلفة لفظيًا، بل أن يُطبَّق اختيار القالب المناسب وأن يقرأ النص طبيعيًا. مثال توضيحي: رسالة رفع الملفات قد تحتاج «لا توجد ملفات»، «ملف واحد»، «ملفان»، و«ثلاثة ملفات» بحسب السياق، وقد تختلف الصياغة إذا كان العدد يتبع الاسم أو يسبقه. لا تختبر النص بمعزل عن وظيفته؛ فالعبارة المناسبة لعنوان بطاقة قد لا تصلح لإشعار نجاح طويل. احتفظ بناتج آلي لكل قيمة، ثم اطلب مراجعة لغوية للحالات التي تتطلب حكمًا بشريًا.

المتغيرات لا ينبغي أن تفسد النحو أو الاتجاه

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

التواريخ والأرقام والعملات ليست مجرد ترجمة أسماء

عندما يعرض التطبيق «01/11/2026» قد يقرأها مستخدم على أنها أول نوفمبر أو الحادي عشر من يناير وفق عادته المحلية. استخدم تنسيقًا مبنيًا على locale مع توضيح المنطقة الزمنية عندما تكون مؤثرة، ولا تخلط بين لغة الواجهة وموقع المستخدم الفعلي. اختبر الفواصل العشرية والآلاف وإشارة السالب والعملة والاتجاه حول رمزها، ولا تحوّل قيم التخزين الداخلية إلى نصوص محلية ثم تعيد تحليلها على الخادم. اجعل الحسابات بالأرقام الأصلية، والتنسيق عند العرض فقط. إذا استخدمت أرقامًا عربية هندية أو غربية، تحقق من الاتساق داخل الشاشة ومن إمكانية إدخال القيم ونسخها. لا تستنتج تفضيل جميع الناطقين بالعربية من عينة مستخدمين صغيرة.

رسائل الأخطاء تحتاج فعلًا واضحًا لا ترجمة حرفية

تظهر جودة التعريب عند حدوث مشكلة: هل يعرف المستخدم ما فشل، وما الذي بقي محفوظًا، وما الخطوة التالية؟ ترجمة «Something went wrong» إلى عبارة عامة قد تكون صحيحة لغويًا لكنها غير مفيدة. اختبر فشل الشبكة، وانتهاء الجلسة، ورفض الصلاحية، وتعارض التعديل، وحدود حجم الملف. لا تعد المستخدم بأن العملية أُلغيت إذا كانت قد نُفذت بالفعل؛ يجب أن يأتي معنى الرسالة من حالة النظام الحقيقية. اجعل الزر التالي متسقًا مع الفعل، مثل «إعادة المحاولة» أو «العودة للمسودة»، مع تجنب لغة لوم المستخدم. اختبر أيضًا قارئ الشاشة وترتيب التركيز عندما تظهر رسالة خطأ جديدة، ولا تعتمد على اللون وحده لتوضيح الحالة.

الاختبار البصري يجب أن يشمل أحجامًا غير مريحة

افحص الواجهة على هاتف ضيق، وعلى سطح مكتب، مع تكبير النص، وأسماء ملفات طويلة، وأزرار متعددة. لا يكفي أن يكون التصميم RTL؛ قد تنعكس أيقونة يجب ألا تنعكس، أو يقطع زر مهم لأن النص العربي أطول من الإنجليزي. استخدم CSS logical properties بدل تثبيت left و right حيث يناسب التصميم، لكن اختبر النتيجة في المتصفح المستهدف. افصل بين اتجاه ترتيب عناصر الواجهة واتجاه محتوى حقل تقني مثل رابط URL. عند تغيير اللغة أثناء الجلسة، تحقق من إعادة عرض الرسائل الموجودة دون فقد الحالة. وثّق أي انكسار بخطوات إعادة إنتاج وصورة لا تحتوي على بيانات شخصية.

اختبار النسخ والبحث والتصدير

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

مصفوفة مراجعة قبل الإطلاق

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

منهج إصلاح يحافظ على الإصدارات القديمة

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

المصادر وروابط إيجي تاج

راجع توثيق ICU MessageFormat للرسائل المعتمدة على المتغيرات وصيغ الجمع: https://unicode-org.github.io/icu/userguide/format_parse/messages/ ، وقواعد Unicode CLDR: https://cldr.unicode.org/index/cldr-spec/plural-rules . للمقارنة مع منهج توحيد المصطلحات في المقالات العربية، اقرأ إيجي تاج: https://egytag.com/ar/articles/الكتابة-العربية-عن-البرمجيات-توحيد-المصطلحات-التقنية . الهدف هنا فحص تعريب واجهة تفاعلية لا فرض قائمة ترجمة واحدة على كل سياق. قد تختلف المكتبات وإصدارات CLDR في بعض التفاصيل؛ تحقق من النسخة التي يستخدمها منتجك بدل نسخ مثال من بيئة أخرى دون اختبار.