اختبار الترجمة والمراجعة اللغوية
اختبار الترجمة (Translation Testing) يفحص النص المترجم في المنتج كما سيراه المستخدم: على الشاشة الحقيقية، وفي التخطيط الحقيقي، وببيانات واقعية. وهو يسأل: هل يقول كل نص ما قصده المصدر؟ وهل يتسع له مكانه؟ وهل يحتفظ بعناصره النائبة؟ وهل يختار صيغة الجمع الصحيحة؟ وهل يُقرأ صحيحاً حين تشترك العربية والإنجليزية، أو الهندية والإنجليزية، في جملة واحدة؟ فالمنتج الذي تعرض شارة سلته بالعربية «2 منتج» (بالمفرد) بدلاً من «منتجان» قد ينجح في كل اختبار وظيفي، ومع ذلك يصدر وفيه عيب ترجمة.
ولهذا الاختبار نصفان يقوم بهما شخصان مختلفان. المراجعة اللغوية (Linguistic Review) يجريها متحدث أصلي مؤهل ويحكم فيها على المعنى والنحو والمصطلحات والأسلوب. واختبار التوطين الوظيفي (Functional Localization Testing) يجريه مختبِر بأي مستوى لغوي ويتحقق فيه من أن البناء المترجم (Build) يعمل: لا نص غير مترجم، ولا نص مقتطع، ولا رسالة أفسدها عنصر نائب، والرسالة الصحيحة لكل عدد.
لماذا يهم
يعمل المترجمون عادةً من جدول بيانات أو نظام لإدارة الترجمة دون أن يروا الشاشة، لذلك تشيع الترجمة الصحيحة للمعنى الخاطئ: فكلمة «Open» الإنجليزية حالة وأمر معاً، و«Save» تعني حفظ البيانات في شاشة والتوفير في السعر في شاشة أخرى. والمطورون نادراً ما يقرؤون اللغة الهدف، فيمرّ العنصر النائب المترجَم وفئة الجمع الناقصة والجملة العربية التي انعكس فيها رقم الطلب من مراجعة الشيفرة. وأول من يرى العيب غالباً هو المستخدم.
وبالنسبة إلى المنتج، تكلّف هذه العيوب الثقة لا الانهيارات: فالمتجر الذي لا يستطيع عدّ منتجاته بالعربية، أو البنك الذي تُقتطع رسالة تأكيده الهندية في منتصف الكلمة، يبدو مهملاً في السوق التي يحاول الفوز بها. وبالنسبة إلى المختبِر، اختبار الترجمة فرصة لإضافة قيمة بالمنهجية: قائمة إعدادات محلية، وجدول أعداد، ومجموعة نصوص مختلطة الاتجاه، ولقطة شاشة لكل مفتاح نص تكشف معظم هذه العيوب دون أن يتكلم اللغة.
المراجعة اللغوية واختبار التوطين الوظيفي مهمتان مختلفتان
المراجعة اللغوية (تسميها بعض الفرق ضمان الجودة اللغوي أو المراجعة في السياق) يجريها متحدث أصلي مؤهل، ويُفضَّل ألا يكون هو من ترجم النص، بالاستناد إلى المسرد (Glossary) ودليل الأسلوب. وتحكم على الدقة (هل تعني العربية ما عنته الإنجليزية؟) والسلاسة والمصطلحات والنحو والإملاء وأسلوب الخطاب (كيف يخاطب المنتج مستخدمه) والملاءمة الثقافية. ومخرجها قائمة تصحيحات لكل مفتاح نص (String Key)، لا تقرير خطأ.
أما اختبار التوطين الوظيفي فيجريه مختبِر بالبناء المترجم وبيانات اختبار وقائمة تحقق، ولا يحتاج إلى الطلاقة. وهو يتحقق من أن الترجمة محمّلة وكاملة، وأن التخطيط والعناصر النائبة وصيغ الجمع والترتيب والبحث والإدخال تعمل في الإعداد المحلي، وأن الميزات تتصرف كما تتصرف في لغة المصدر. ومخرجه عيوب. وتلتقي المهمتان في ناتج واحد: لقطات شاشة لكل نص في سياقه، تمنح المراجع السياق الذي لم يملكه المترجم، وتمنح المطور المفتاح الذي يصلحه.
- تحتاج المراجعة اللغوية إلى: المسرد ودليل الأسلوب والنص المصدري ولقطات الشاشة؛ وتسجّل مفتاح النص والنص الحالي والنص المقترح والسبب.
- يحتاج الاختبار الوظيفي إلى: البناء بكل إعداد محلي، وبيانات اختبار موطّنة واقعية، وجدول أعداد للجمع، ومجموعة نصوص مختلطة الاتجاه؛ ويسجّل مفتاح النص والإعداد المحلي والشاشة والنتيجة المتوقعة والفعلية.
- الترتيب: شغّل التوطين الزائف والاختبار الوظيفي أولاً حتى لا تعيق النصوص المفقودة المراجع؛ وأجرِ المراجعة اللغوية حين تستقر النصوص؛ وأعد الاختبار (اختبار التأكيد) بعد وصول التصحيحات.
ما الذي يتعطّل في النصوص المترجمة: المعنى والعناصر النائبة والجمع والطول
عيوب السياق تأتي من نصوص تُرجمت دون رؤية موضعها. والنصوص القصيرة أخطرها: فلكل من «Open» و«Close» و«Post» و«Clear» و«None» و«Home» معانٍ عدة، والمفتاح الواحد المستعمل في شاشتين بمعنيين مختلفين لا يمكن أن يصحّ فيهما معاً. اطلب مفتاحاً لكل سياق، وافحص كل نص قصير على شاشته.
العناصر النائبة (Placeholders) هي أجزاء الرسالة التي تملؤها الشيفرة: {name} و{{count}} و%s و%1$s و{0}. وقد يترجم المترجم أحدها أو يحذفه. أما العناصر البسيطة %s فتُملأ بالقيم بترتيبها دائماً، فإن قدّمت الجملة الهدف المدينة على التاريخ وقع التاريخ في موضع المدينة؛ ولهذا وُجدت العناصر المرقّمة مثل %1$s و%2$s، فهي تسمح للترجمة بتغيير ترتيبها. اختبر كل رسالة فيها عنصر نائب بقيمة حقيقية في كل إعداد محلي، واقرأ ملفات الموارد جنباً إلى جنب: يجب أن تساوي مجموعة العناصر النائبة في الترجمة مجموعتها في المصدر.
صيغ الجمع تتبع الإعداد المحلي لا الإنجليزية. وقد شرح دليل اختبار التوطين ودرس «التدويل» فئات الجمع في CLDR (فئتان للإنجليزية والهندية، وست فئات للعربية)، وسبب خطأ الشيفرة التي تختار الصيغة بالشرط count === 1 في العربية. أما نصيب اختبار الترجمة فهو جدول الأعداد: قيمة من كل فئة في الإعداد المحلي، وهي للعربية 0 و1 و2 و3 و11 و100، يُشغَّل على كل رسالة معدودة على الشاشة للتأكد من أن كل ترجمة مسلَّمة تحمل كل الفئات التي يحتاجها إعدادها المحلي.
الطول والاقتطاع (Truncation): النص المترجم أطول من المصدر الإنجليزي في الغالب، والديفاناغاري تحتاج إلى ارتفاع أكبر للعلامات فوق السطر وتحته. وتظهر المشكلة في الأزرار ذات العرض الثابت وعلامات التبويب ورؤوس الجداول والشارات وعناوين الإشعارات والرسائل النصية. والقطع داخل كلمة عربية يمنح آخر حرف باقٍ شكله النهائي، فقد يُقرأ الجزء الباقي كلمةً أخرى؛ والقطع داخل مقطع هندي قد يترك حرفاً صامتاً مبتوراً تظهر تحته علامة السكون (virama)، والرسالة المقسومة قد يبدأ جزؤها التالي بعلامة حركة ترسمها خطوط كثيرة على دائرة منقطة. وحيث يوجد حدّ صارم، مثل عنوان إشعار أو مقطع رسالة نصية، قِس النص المترجم مقابل الحدّ بالوحدة التي يعدّها النظام.
- النصوص غير المترجمة (إنجليزية متروكة في الواجهة العربية أو الهندية، انظر دليل اختبار التوطين): قارن مجموعتي المفاتيح في ملفي الموارد المصدري والهدف لتجدها قبل فتح التطبيق.
- الدمج (Concatenation)، انظر درس «التدويل»: الجملة المركّبة من أجزاء في الشيفرة لا يمكن ترجمتها بترتيب الكلمات الصحيح؛ والإصلاح رسالة واحدة بمعاملات، ويجريه المطور.
- التذكير والتأنيث وأسلوب الخطاب، انظر دليل اختبار التوطين: تتحقق المراجعة اللغوية من أن المنتج يطبّق في كل نص قراره في مخاطبة المستخدم، بالمذكر أو بصياغة محايدة أو بحسب الملف الشخصي.
النص المختلط الاتجاه داخل النص المترجم
يشرح دليل اختبار واجهات اليمين إلى اليسار خوارزمية يونيكود ثنائية الاتجاه (UAX #9) ومجموعة اختبار النص ثنائي الاتجاه؛ ويضيف اختبار الترجمة إليهما سؤالاً واحداً. فالمترجم هو من يقرر موضع كل عنصر نائب في الجملة الهدف، والقيم التي تملأ العناصر النائبة كثيراً ما تُكتب من اليسار إلى اليمين: أسماء العلامات التجارية وأرقام الطلبات وعناوين البريد والروابط وأسماء الملفات وكل ما كتبه المستخدم بالإنجليزية. والنص المترجم الذي يُقرأ صحيحاً بقيمة عربية قد ينكسر بقيمة لاتينية، لذا يحتاج كل عنصر نائب إلى الاثنتين.
وتتكرر ثلاث حالات. الأولى: القيمة التي تلي أرقامَها شَرطةٌ وحروف لاتينية يُعاد ترتيبها داخل الجملة العربية، فرقم الطلب 1042-A يُعرض A-1042، أما A-1042 التي تبدأ بحرف فتحتفظ بترتيبها لأن أرقامها تأخذ اتجاه الحرف الذي قبلها. الثانية: الأرقام الغربية التي تلي قيمة لاتينية ولا يفصلها عنها إلا مسافات أو علامات ترقيم تنضم إلى مقطعها الممتد من اليسار إلى اليمين، ففي تقييم {user}: {score} مع المستخدم «Sara» تُعرض الدرجة بجوار «تقييم» قبل الاسم. الثالثة: ترجمة تبدأ بعنصر نائب، فالنص العادي المعروض دون اتجاه محدد يأخذ اتجاه فقرته من أول حرف قوي (القاعدتان P2 وP3 في UAX #9)، وdir="auto" تفعل الشيء نفسه، لذا تصبح {app} يذكّرك بموعدك غداً. مع اسم تطبيق لاتيني فقرةً من اليسار إلى اليمين، محاذاةً إلى اليسار، ونقطتها في الجانب الخطأ.
- لكل رسالة فيها عنصر نائب، دوّن موضعه في كل ترجمة (البداية أو الوسط أو النهاية) واختبره مرتين: بقيمة عربية، وبقيمة لاتينية مثل علامة تجارية أو بريد إلكتروني أو معرّف فيه شَرطة.
- اسأل كيف تُعزل القيمة:
<bdi>أوdir="auto"على العنصر الذي يحملها في HTML، أو FSI (U+2068) وPDI (U+2069) حولها في النص العادي. والعزل يصلح الحالات الثلاث: فالقيمة تُرتَّب وحدها، وUAX #9 تتجاوز النص المعزول حين تبحث عن أول حرف قوي. أما علامات الاتجاه (U+200E وU+200F) المكتوبة أو الملصوقة في ملف الترجمة فلا تُرى في المراجعة ولا تصلح إلا القيمة التي اختُبرت بها؛ حوّل النص المشبوه إلى نقاط ترميز لتراها. - افحص النص نفسه في الإعداد الهندي أيضاً: فالهندية تُكتب من اليسار إلى اليمين، لذا العيب الذي يظهر في العربية وحدها يشير إلى معالجة الاتجاه، والعيب الذي يظهر في اللغتين يشير إلى العنصر النائب نفسه.
| العيب | العَرَض على الشاشة | السبب المعتاد | كيف تكشفه |
|---|---|---|---|
| معنى خاطئ (السياق) | حالة الطلب «Open» تظهر بصيغة الأمر «افتح» | نص تُرجم دون رؤية الشاشة؛ مفتاح واحد مستعمل في سياقين | اقرأ كل نص قصير على شاشته؛ مراجعة لغوية بلقطات الشاشة |
| نص غير مترجم | «Field is required» بالإنجليزية في النموذج العربي | المفتاح مفقود من الملف الهدف؛ نص أُضيف في آخر السبرنت | قارن مجموعتي المفاتيح في الملفين المصدري والهدف؛ بدّل الإعداد المحلي وافحص الأخطاء والبريد |
| عنصر نائب معطوب | أقواس خام «{رقم الطلب}» تُطبع في رسالة الشحن | المترجم ترجم العنصر النائب أو حذفه أو بدّل ترتيبه | قارن مجموعتي العناصر النائبة لكل مفتاح؛ املأ كل عنصر نائب بقيمة حقيقية في كل إعداد محلي |
| صيغة جمع خاطئة | شارة السلة «2 منتج» بدلاً من «منتجان» | الصيغة مختارة بالشرط count === 1؛ رسالة بلا فئات CLDR | جدول أعداد لكل إعداد محلي: 0 و1 و2 و3 و11 و100 للعربية؛ 0 و1 و2 للهندية |
| اقتطاع أو فيض | اسم منتج هندي مقطوع داخل مقطع، يبقى منه حرف صامت مبتور تظهر تحته علامة السكون (virama) | عنصر بعرض ثابت؛ ترجمة أطول؛ حدّ يُعدّ بالبايتات | أسماء طويلة واقعية في كل إعداد محلي؛ قِس مقابل الحدود الصارمة بالوحدة التي يعدّها النظام |
| ترتيب مختلط الاتجاه | رقم الطلب 1042-A يظهر A-1042 داخل جملة عربية | قيمة العنصر النائب غير معزولة عن العربية المحيطة بها، فتُرتَّب أرقامها وحرفها اللاتيني مقطعين منفصلين | املأ كل عنصر نائب بقيمة عربية وأخرى لاتينية؛ حوّل النصوص إلى نقاط ترميز لرؤية العلامات الخفية |
جرّبها: مولّد بيانات اختبار متعددة اللغات جرّبها: مرمّز Unicode
مثال تطبيقي: نصوص صفحة الدفع بالعربية والهندية
يفصل متجر نصوص صفحة الدفع في ملف JSON واحد لكل إعداد محلي. يصل الملفان العربي والهندي من مورّد الترجمة؛ فيقرأهما المختبِر جنباً إلى جنب مع المصدر الإنجليزي قبل فتح التطبيق، ثم يتحقق على الشاشة بالأعداد 0 و1 و2 و3 و11 و100 وبرقم الطلب 1042-A.
cart.items: أسقطت العربية بنية الجمع؛ فالعدد 2 يعرض «2 منتج» بدلاً من «منتجان»، والعدد 3 يجب أن يُقرأ «3 منتجات» و11 «11 منتجاً». عيب وظيفي كُشف بجدول الأعداد؛ والإصلاح رسالة بفئات CLDR الست.order.shipped: تُرجم العنصر النائب{orderId}إلى{رقم الطلب}، فتطبع أداة التنسيق الأقواس خاماً. عيب وظيفي كُشف بمقارنة مجموعتي العناصر النائبة في الملفين.order.shippedعلى الشاشة بالقيمة1042-Aبعد إصلاح العنصر النائب: يُعرض المعرّفA-1042داخل الجملة العربية حتى تُعزل القيمة بـ<bdi>. عيب وظيفي كُشف بملء العنصر النائب بقيمة لاتينية.status.open: «افتح» أمر بمعنى «قم بفتحه»؛ والمفتاح حالة طلب ويجب أن يُقرأ «مفتوح». عيب لغوي لا يظهر إلا في السياق، ويُبلَّغ عنه بلقطة شاشة لجدول الطلبات.- الملف الهندي:
cart.itemsبصيغة «{count} आइटम» مقبول لأن للهندية فئتين والكلمة المستعارة لا تتغير، لكن المراجع يعلّم «सेव करें» في هذه الشاشة و«सहेजें» في شاشة الإعدادات على أنه تضارب في المصطلحات مخالف للمسرد.
en.json
"cart.items": "{count, plural, one {# item} other {# items}}"
"order.shipped": "Order {orderId} shipped to {city}"
"status.open": "Open"
"button.save": "Save"
ar.json (as delivered)
"cart.items": "{count} منتج"
"order.shipped": "تم شحن الطلب {رقم الطلب} إلى {city}"
"status.open": "افتح"
"button.save": "حفظ"
hi.json (as delivered)
"cart.items": "{count} आइटम"
"order.shipped": "ऑर्डर {orderId} {city} को भेज दिया गया"
"status.open": "खुला"
"button.save": "सेव करें"جرّبها: مولّد بيانات الاختبار العربية جرّبها: مولّد بيانات الاختبار الهندية
أخطاء شائعة
- مراجعة الترجمة في جدول البيانات أو أداة الترجمة فقط، دون رؤيتها أبداً على الشاشة التي يظهر فيها النص.
- اعتبار المراجعة اللغوية هي كل اختبار التوطين، أو تجاوزها بحجة أن «المختبِر فحص العربية».
- اختبار الجمع بالعددين 1 و2 فقط؛ فالعربية تحتاج إلى قيمة من كل فئة من فئاتها الست، مثل 0 و1 و2 و3 و11 و100.
- قبول ملف موارد دون مقارنة مفاتيحه وعناصره النائبة بالمصدر، ثم اكتشاف الأقواس الخام في بيئة الإنتاج.
- الإبلاغ بأن «العربية تبدو خاطئة» دون مفتاح النص والإعداد المحلي والشاشة ولقطة الشاشة؛ فلا يمكن تحديد موضع الإصلاح.
- الاختبار ببيانات قصيرة مثل «Test» بدلاً من أسماء وعناوين واقعية طويلة وقيم مختلطة الكتابة، فلا تظهر عيوب الاقتطاع والاتجاه أبداً.
من منظور ضمان الجودة
في الفريق الحقيقي يبدأ اختبار الترجمة قبل أن توجد الترجمة. فعند تجميد النصوص (String Freeze)، أي حين يتوقف تغيّر النص المصدري ويُرسَل إلى الترجمة، يصدّر المختبِر ملف الموارد المصدري، ويحصي كل عنصر نائب وكل رسالة معدودة، ويطرح ثلاثة أسئلة: هل يوجد مسرد ودليل أسلوب؟ وأي مكتبة تنسّق صيغ الجمع؟ وهل يوجد بناء بإعداد محلي زائف؟ وحين تصل الملفات المترجمة، تستغرق مقارنة الملفات (المفاتيح والعناصر النائبة) دقائق وتكشف أرخص العيوب أولاً؛ ثم تأتي الجولة على الشاشة بجدول الأعداد ومجموعة النصوص المختلطة الاتجاه في كل إعداد محلي.
سجّل كل نتيجة بمفتاح النص والإعداد المحلي والشاشة والنتيجة المتوقعة والفعلية ولقطة شاشة، وصنّفها وظيفية أو لغوية. فالنتيجة اللغوية تذهب إلى المراجع أو المورّد. أما النتيجة الوظيفية فتذهب إلى صاحب الطبقة التي وقع فيها الخطأ، وهو التقسيم نفسه بين التدويل (i18n) والتوطين (l10n) كما في درس «التدويل»: إلى المطور حين يكون الخطأ في الشيفرة (نص مكتوب مباشرة في الشيفرة أو مركّب من أجزاء، أو صيغة جمع تُختار بالشرط count === 1، أو قيمة تُعرض دون عزل)، وتعود إلى المترجم أو المورّد حين يكون الخطأ في ملف الموارد المسلَّم (عنصر نائب مترجَم، أو فئات جمع ناقصة، أو مفتاح مفقود). واحتفظ بلقطات الشاشة: فهي السياق الذي يحتاجه المراجع اللغوي، والدليل عند إعادة الاختبار بعد استيراد الملفات المصحّحة.
تمرين عملي
راجع ملف موارد شاشة الإشعارات
لشاشة الإشعارات أربعة نصوص مصدرية مع ترجمتيها العربية والهندية أدناه. دون تشغيل التطبيق، اعثر على كل عيب تستطيع اكتشافه من الملفات وحدها، ثم اذكر ما ستظل بحاجة إلى التحقق منه على الشاشة. صنّف كل نتيجة وظيفية أو لغوية، واكتبها عنوان تقرير خطأ مع مفتاح النص.
وللمفتاح notif.unread اكتفِ بالتحقق من أن كل ترجمة تحمل فئات الجمع التي يحتاجها إعدادها المحلي. واصرف بقية الوقت على السياق والاتجاه: ماذا ستسأل عن موضع ظهور notif.clear وnotif.none، وما القيم التي ستملأ بها notif.from وما الذي تتوقع أن تراه.
en.json
"notif.unread": "{count, plural, one {# unread message} other {# unread messages}}"
"notif.from": "From {sender} · {time}"
"notif.clear": "Clear"
"notif.none": "None"
ar.json
"notif.unread": "{count} رسالة غير مقروءة"
"notif.from": "من {المرسل} · {time}"
"notif.clear": "واضح"
"notif.none": "لا شيء"
hi.json
"notif.unread": "{count} अपठित संदेश"
"notif.from": "{sender} से · {time}"
"notif.clear": "साफ़ करें"
"notif.none": "कोई नहीं"- قارن مجموعة العناصر النائبة في كل ترجمة بنصها المصدري.
- افحص كل رسالة معدودة بحثاً عن فئات الجمع التي يحتاجها إعدادها المحلي.
- اقرأ كل نص قصير واسأل أي معنى يحتاجه المفتاح على هذه الشاشة.
- اذكر القيم الواقعية التي ستملأ بها العناصر النائبة لاختبار العرض المختلط الاتجاه.
إظهار الإجابة النموذجية
notif.unread (وظيفي، في ar.json، فيعود إلى المورّد): العربية بلا بنية جمع، فالعدد 2 سيُقرأ «2 رسالة غير مقروءة» بدلاً من «رسالتان غير مقروءتين»؛ وتحتاج الرسالة إلى فئات العربية الست (zero وone وtwo وfew وmany وother)، ويؤكدها جدول الأعداد على الشاشة بعد وصول الملف المصحّح. ولا تحتاج الجملة الهندية إلى بنية جمع، لأن «अपठित संदेश» لا تتغير بين فئتي الهندية.
notif.from (وظيفي، في ar.json، للمورّد): ترجمت العربية العنصر النائب {sender} إلى {المرسل}، فستطبع أداة التنسيق الأقواس خاماً أو تفشل. أما الهندية فأبقت العنصرين ووضعت {sender} قبل «से»، وهو الترتيب الصحيح في الهندية لأن أداة الربط فيها تأتي بعد الاسم (postposition)؛ وهذا ممكن لأن السطر رسالة واحدة بعناصر نائبة مسمّاة، لا كلمة «From» تُلصق بالاسم في الشيفرة.
notif.clear (لغوي): «واضح» تعني «clear» بمعنى «جليّ»؛ وعلى زر يفرغ القائمة يحتاج المفتاح إلى تسمية الإجراء «مسح». والهندية «साफ़ करें» أمر وهي صحيحة.
notif.none (لغوي، يحتاج إلى سياق): «لا شيء» و«कोई नहीं» ترجمتان حرفيتان؛ فإن كان المفتاح يصف قائمة فارغة، فعبارتا «لا توجد إشعارات» و«कोई सूचना नहीं» أطبع، وعلى المراجع أن يسأل مالك المنتج أين يظهر المفتاح.
ما يبقى للتحقق على الشاشة: notif.from بعد إصلاح عنصره النائب، مع مرسل عربي ومع مرسل لاتيني مثل «Acme-2» أو «support@example.com». فإن كُتب {time} بالأرقام الغربية، فأرقامه تلي الاسم اللاتيني ولا يفصلها عنه إلا الفاصل «·»، فتنضم إلى مقطعه الممتد من اليسار إلى اليمين، وقد يظهر الوقت بجوار «من» قبل اسم المرسل؛ وتوقّع هذا العيب ما لم يُعزل {sender}. وتحقق أيضاً هل يقتطع اسم مرسل طويل الوقت، وهل تتسع صفوف الإشعارات لارتفاع النصوص الهندية.
أسئلة شائعة
هل أحتاج إلى إتقان العربية أو الهندية لاختبار الترجمة؟
ليس لاختبار التوطين الوظيفي: فالاكتمال والعناصر النائبة وصيغ الجمع والاقتطاع والعرض المختلط الاتجاه تُفحص بملفات الموارد وبيانات الاختبار وقائمة تحقق. أما المراجعة اللغوية للمعنى والنحو والمصطلحات والأسلوب فتحتاج إلى متحدث أصلي مؤهل، ويُفضَّل ألا يكون المترجم الذي أنتج النص.
ما الفرق بين اختبار الترجمة واختبار التوطين؟
اختبار التوطين يغطي كل ما يتغيّر مع الإعداد المحلي: الصيغ والتقاويم والعملة واتجاه التخطيط والترميز واللغة. واختبار الترجمة والمراجعة اللغوية هو الجزء اللغوي منه: النصوص نفسها، في سياقها، على الشاشة.
كم عدداً أحتاج لاختبار رسالة جمع؟
قيمة واحدة لكل فئة جمع في الإعداد المحلي بحسب قواعد CLDR: للإنجليزية 1 و2؛ وللهندية 0 و1 و2؛ وللعربية 0 و1 و2 و3 و11 و100. وأضف 0 في كل إعداد محلي، فكثير من المنتجات له رسالة خاصة «لا عناصر» هي نص منفصل.
هل تحلّ الترجمة الآلية محل المراجعة اللغوية؟
لا. يمكن أن يكون ناتج الآلة مسودة أولى، لكن له نقطة عمياء المترجم بلا سياق وأكثر: فهو لا يستطيع أن يعرف أن «Open» حالة في هذه الشاشة. اختبر النصوص المترجمة آلياً كما تختبر الترجمة البشرية تماماً، وأبقِ مراجعة المتحدث الأصلي لكل ما يراه المستخدم.
المراجع
- Unicode CLDR Projectمستودع بيانات اللغات والمناطق المشترك: بيانات صيغ التاريخ والوقت والأرقام والعملات وقواعد الجمع التي تعتمدها معظم المنصات.
- Unicode Standard Annex #9: Unicode Bidirectional Algorithmالخوارزمية التي تحدد ترتيب عرض النص المختلط من اليمين إلى اليسار ومن اليسار إلى اليمين — مصدر معظم أخطاء النص ثنائي الاتجاه.
- Inline markup and bidirectional text in HTMLكيف تعامل الخوارزمية ثنائية الاتجاه المقاطع المضمّنة — الأرقام والأسماء والروابط داخل النص العربي — والوسوم (bdi وdir) التي تعزلها.
- The Unicode Standardمجموعة المحارف العالمية وأشكال ترميزها (UTF-8 وUTF-16 وUTF-32) والتطبيع وخصائص كل نقطة ترميز.
تدرّب بأدوات متقن
ولّد السجلات نفسها بلغات متعددة (الإنجليزية والعربية والهندية وغيرها) لاختبار التدويل (i18n) واختلاط RTL/LTR.
ولّد أسماء وعناوين وجملاً وأرقاماً عربية (بالأرقام العربية-الهندية) وحالات حدّية للكتابة من اليمين إلى اليسار لاختبار التوطين.
ولّد أسماء وعناوين وجملاً وأرقاماً هندية (بالخط الديفاناغاري) لاختبار التوطين.
مقارنة مستندي JSON دلالياً وإبراز القيم المضافة والمحذوفة والمتغيرة.
قِس طول السلسلة النصية بالأحرف ونقاط الترميز (code points) وبايتات UTF-8 ووحدات UTF-16.
تحويل النص إلى تسلسلات تهريب Unicode (\u0041) أو نقاط الترميز (U+0041) أو كيانات HTML الرقمية.
للتعمّق أكثر
- اختبار التوطين والتدويلجودة اللغة والترجمة
- اختبار التوطين والتدويلالتوطين الزائف: اكتشف عيوب التدويل قبل الترجمة
- اختبار الواجهات من اليمين إلى اليسارالنص ثنائي الاتجاه وخوارزمية يونيكود ثنائية الاتجاه
- كيف تكتب تقرير خطأ (Bug Report)كيف تكتب تقرير خطأ يستطيع المطورون التصرف بناءً عليه: الحقول المهمة، ونموذج جاهز للنسخ، ومثال كامل، والفرق بين الخطورة والأولوية، والأخطاء الواجب تجنبها.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.