الاختبار اللغوي للترجمة التقنية: دليل المترجم العملي
كيف تتحقق من أن ترجمتك التقنية تعمل في بيئتها التفاعلية الفعلية — خطوات الاختبار اللغوي ومصادر الخطأ التي لا تكشفها المراجعة الورقية.
ورشة: التوطين لتطبيقات الويب ٣.٠ والذكاء الاصطناعي · المقالة الثالثة من أربع
في المقالة الأولى بنينا المسرد المصطلحي — الأساس الذي يضمن الاتساق قبل أن تبدأ ترجمةٌ واحدة. في المقالة الثانية تناولنا القيود الثلاثة لواجهة المستخدم: المساحة واتجاه التخطيط والنبرة الثقافية.
هاتان المرحلتان — البناء المصطلحي وترجمة الواجهة — تجريان على الورق أو في ملفاتٍ نصية. هذه المقالة تتناول المرحلة التي تتحول فيها الترجمة من ورقةٍ إلى تجربة: الاختبار اللغوي.
معظم مشاريع التوطين تتجاوز الاختبار اللغوي — أو تُدمجه بالمراجعة اللغوية كأنهما شيءٌ واحد، وهما ليسا كذلك. المراجعة اللغوية تسأل: «هل هذا النص صحيح؟» الاختبار اللغوي يسأل: «هل هذا النص يعمل في هذا السياق؟» الفارق ليس دلالياً — إنه الفارق بين ترجمةٍ ممتازةٍ على الورق وكارثةٍ في المنتج المُطلَق.
لماذا المراجعة وحدها لا تكفي
تخيَّل هذا السيناريو: مترجمٌ محترفٌ راجع كل نصٍّ في ملف الترجمة. وجد أن كل جملةٍ صحيحةٌ نحوياً، وكل مصطلحٍ متسقٌ مع المسرد، وكل اختيارٍ مبرَّرٍ تماماً. ثم يُرسَل الملف للمطوِّر، الذي يدمَج الملف في التطبيق، ويُطلَق المنتج.. ويكتشف أول مستخدمٍ عربي أن زر «التالي» يحمل نصاً يفيض خارج حدوده، وأن رسالة الخطأ الأكثر شيوعاً تظهر في وضعٍ يجعلها غير مقروءة، وأن اسم الصفحة في التبويب مقطوعٌ عند الحرف السابع.
لم يُخطئ المترجم، ولم يُخطئ المراجع، لكن أُهمل الاختبار.
الاختبار اللغوي ظاهرةٌ طبيعيةٌ في دورة تطوير البرمجيات: المطورون يختبرون الكود، ومصممو UX يختبرون التجربة، ومهندسو QA يختبرون الوظائف. لكن اختبار ما إذا كانت الترجمة تعمل في بيئتها الفعلية يقع في منطقةٍ رماديةٍ بين هذه الأدوار — وكثيراً ما لا يتولاه أحد!
الترجمة الصحيحة التي تظهر في السياق الخاطئ خطأٌ توطيني. اكتشافه بعد الإطلاق أكثر تكلفةً بعشرين مرةً من اكتشافه في مرحلة الاختبار.
خمسة أنواعٍ من أخطاء الاختبار اللغوي
الاختبار اللغوي يبحث عن فئاتٍ محددةٍ من الأخطاء لا تظهر في المراجعة النصية. إليك الخمسة الأكثر شيوعاً في مشاريع التوطين العربي:
١. الفيضان (Text Overflow): النص المُترجم أطول من الحاوية المصممة له. الزر الذي يحتوي «Submit» يحتاج أن يحتوي «إرسال» — وهذا مقبول. لكن حين يصبح «Continue to payment» جملةً كـ«المتابعة إلى صفحة الدفع» في زرٍّ صُمِّم لعشرة أحرف إنكليزية، فالمشكلة واضحةٌ في المنتج وغير موجودةٍ في الملف النصي.
٢. الاقتطاع (Truncation): النظام يقتطع النص عند حدٍّ معينٍ بنقاطٍ أو بدونها. «إعدادات الحساب الشخصي» تُصبح «إعدادات الحسا…» في شريط التنقل الضيق. والأسوء من الاقتطاع العشوائي هو الاقتطاعٌ الذي يُحيل النص إلى معنىً مختلف — وهذا يحدث في العربية بسبب أن الكلمة العربية مُتصلة الحروف وقطعها في المنتصف يُنتج شكلاً غير مقروء.
٣. المزج الاتجاهي (Bidi Rendering Issues): النص العربي يظهر بشكلٍ خاطئ حين يتداخل مع عناصر LTR كالأرقام والروابط والمصطلحات التقنية. جملةٌ كـ«رصيدك هو $٥٠٠ في حساب Premium» قد يُقلب ترتيبها البصري بصورةٍ مربكة إن لم يُعامَل كل عنصرٍ بخاصية الاتجاه الصحيحة. هذا ليس خطأ المترجم — لكن المترجم المُختبِر هو من يُبلِّغ عنه.
٤. أخطاء الحالة الديناميكية (Dynamic State Errors): النص الذي يبدو صحيحاً في حالته الافتراضية قد يُكسر في حالاتٍ أخرى. مثال: «مرحباً، [اسم المستخدم]» يعمل جيداً حين يكون الاسم قصيراً. لكن حين يكون اسم المستخدم طويلاً أو يحتوي على أحرفٍ لاتينية، قد ينكسر اتجاه النص كله. الاختبار اللغوي يمرُّ على الحالات الحدية لا على الحالة المثالية فقط.
٥. أخطاء الجمع والتصريف (Pluralization and Inflection): الإنكليزية لها حالتان: المفرد والجمع. العربية لها خمس حالاتٍ: المفرد، المثنى، جمع القلة (٣–١٠)، جمع الكثرة (١١ فما فوق)، والجمع غير المنصرف في بعض المواضع. نظامٌ مبني على «١ item / N items» سيُنتج «١ عنصر / ٢ عناصر / ٥ عناصر» — لكن «٢ عناصر» خاطئٌ في العربية (الصحيح: «عنصران»). هذا الخطأ لا يظهر إلا في الاختبار الديناميكي.
منهجية الاختبار اللغوي: أربع جولات
الاختبار اللغوي الاحترافي لا يحدث في جولةٍ واحدة. يمر على أربع جولاتٍ تتصاعد في عمقها:
الجولة الأولى — اختبار العرض الثابت (Static Display Test): يُراجع المختبِر كل شاشةٍ في حالتها الافتراضية. يبحث عن الفيضان والاقتطاع وأخطاء اتجاه النص في النصوص الثابتة. هذه الجولة تكشف ٦٠–٧٠٪ من المشكلات وهي الأسرع تنفيذاً.
الجولة الثانية — اختبار التفاعل (Interaction Test): يُنفِّذ المختبِر كل تدفقٍ تفاعليٍ رئيسي: التسجيل، تسجيل الدخول، إتمام عمليةٍ شرائية، تغيير الإعدادات، تلقي رسالة خطأ. في كل تدفقٍ يتتبع ظهور النصوص في سياقها الفعلي — ليس ما كُتب في الملف بل ما يظهر على الشاشة في كل خطوة.
الجولة الثالثة — اختبار الحالات الحدية (Edge Case Test): البيانات الاختبارية المُصمَّمة لكسر الافتراضات: أسماء مستخدمين طويلة، أرقامٌ كبيرة، محتوىً فارغ، محتوىً بالأحرف اللاتينية في حقولٍ عربية. هذه الجولة تكشف أخطاء التصريف والجمع وأخطاء الاتجاه الثانئي (Bidi Errors) الخفية.
الجولة الرابعة — اختبار السياق الكامل (Full User Journey Test): يُشغِّل المختبِر جلسةً كاملةً من منظور مستخدمٍ حقيقيٍ بدون توقفٍ تحليلي. الهدف هنا ليس إيجاد أخطاءٍ محددةٍ بل اكتشاف ما يبدو «غريباً» أو «غير طبيعي» حتى لو لم يكن خطأً تقنياً، وهذا الشعور هو ما تكشفه الجولة الرابعة دون سواها.
أدوات الاختبار اللغوي: ما تستخدمه فعلاً
الاختبار اللغوي لا يحتاج أدواتٍ متخصصةٍ مُكلفةٍ في معظم المشاريع. الأدوات الأكثر استخداماً:
قائمة التحقق اليدوية (Manual Checklist): وثيقةٌ تُدرج كل شاشةٍ وكل تدفقٍ تفاعليٍ وكل حالةٍ ديناميكيةٍ يجب اختبارها. يُخصَّص عمودٌ لكل نوعٍ من أنواع الأخطاء الخمسة السابقة. تملأها المختبِر شاشةً شاشة. وهي بسيطةٌ، وفعّالةٌ، وقابلة للتكرار.
الترجمة الوهمية (Pseudo-localization):هي عمليةٌ تقنية تُستخدم قبل اكتمال الترجمة، تستبدل النصوص الإنجليزية بنصوصٍ “زائفة” (مثل تحويل “Edit Profile” إلى [!!! Éďîţ Þŕôƒîļé !!!]) بحروفٍ موسَّعةٍ للكشف عن مشكلات المساحة وتداخل النصوص قبل إدراج الترجمة الحقيقية. أدواتٌ كـi18n-ally وGlobalese تُوفِّر هذه الوظيفة، وهي مفيدةٌ بشكلٍ خاصٍ لفريق التطوير في مرحلةٍ مبكرة “قبل البدء بالترجمة أصلاً”.
تسجيل الشاشة مع التعليق الصوتي: المختبِر يُسجِّل جلسة الاختبار ويُعلِّق شفهياً على ما يلاحظه. هذا التوثيق أسرع من كتابة تقريرٍ تفصيليٍ ويُمكِّن المطوِّر من رؤية المشكلة مباشرةً في سياقها.
بيانات اختبارٍ معيارية: مجموعةٌ من البيانات الاختبارية المُعَدَّة مسبقاً تُغطي الحالات الحدية: اسمٌ مكوَّن من حرفٍ واحد، اسمٌ مكوَّن من ثلاثين حرفاً، رصيدٌ بثلاثة أصفار، رصيدٌ صفري، تاريخٌ في نهاية القرن. استخدام البيانات ذاتها في كل مشروعٍ يوفِّر وقت الإعداد ويضمن تغطيةً ثابتة. رغم أن هذا الاختبار برمجيٌ وظيفيٌ لتركيزه على سلامة النظام ومنطق معالجة البيانات، إلا أنه ضروريُ للمترجم والمحلل، لأنه يكشف مشاكل التصميم “كاسم ألماني من 30 حرف” ومشاكل الصياغة “0 ريال، أم ريالات”.
التقرير اللغوي: كيف تُوثِّق ما وجدتَه
مشكلةٌ غير موثَّقة بدقةٍ هي مشكلةٌ لم تُحَلَّ بعد، حتى لو اكتشفتها. التقرير اللغوي الجيد يحتوي لكل مشكلةٍ على خمسة عناصر:
- الموقع: الشاشة/التدفق/المكوِّن بالضبط (مثلاً: «شاشة الدفع > زر التأكيد»)
- نوع المشكلة: من الفئات الخمس السابقة
- النص الحالي: ما يظهر على الشاشة فعلاً
- المشكلة: وصفٌ محدد (مثلاً: «النص يفيض ٨ أحرف خارج حدود الزر في العرض ٣٧٥ بكسل»)
- الحل المقترح: النص البديل أو التعديل التقني المطلوب
عمودٌ إضافي للأولوية (عالية/متوسطة/منخفضة) يُساعد فريق التطوير على ترتيب الإصلاحات. مشكلةٌ تمنع إتمام عمليةٍ أساسية أولويتها عالية. مشكلةٌ جمالية في شاشةٍ نادرة الظهور أو أخطاء الجمع والتصريف مثلاً فأولويتها منخفضة.
اختبار خاص بالعربية: ست نقاطٍ إضافية
إلى جانب الاختبار العام، ثمة نقاطٌ خاصة بالعربية يجب إضافتها إلى قائمة التحقق في كل مشروع:
١. اختبار الخطوط في الأوزان المختلفة: النص العربي في الوزن العادي (Regular) قد يبدو جيداً لكنه يُصبح غير مقروء في الوزن الخفيف (Light) على بعض الخطوط. تحقق من كل استخدامٍ للخط بأوزانه المختلفة.
٢. اختبار الحركات (Tashkeel) حين تظهر: بعض المنتجات تُدرج نصوصاً بالحركات في مواضع تعليمية. الحركات تزيد الارتفاع البصري للنص، وقد تفيض من حاوياتٍ لا تحتسب ذلك.
٣. اختبار الأرقام المختلطة: نصٌّ يحتوي على أرقام عربية هندية ورقمٍ غربي واحد (لأنه جاء من قاعدة بيانات بصيغةٍ مختلفة) يُنتج ارتباكاً بصرياً. تحقق من مصادر الأرقام الديناميكية لا فقط من النصوص الثابتة.
٤. اختبار الشكل بحجوم الشاشات المختلفة: ما يعمل في شاشة ٣٩٠ بكسل عرضاً قد ينكسر في ٣٢٠ بكسل (أجهزةٌ قديمة لا تزال شائعة في بعض الأسواق العربية). اختبر على المدى الكامل من الأجهزة المستهدفة.
٥. اختبار قارئات الشاشة (Screen Readers): VoiceOver على iOS وTalkBack على أندرويد يقرآن النصوص العربية — لكن النص البديل للصور (alt text) والتسميات التوضيحية (ARIA labels) قد لا تكون مُترجمةً بالكامل أو قد تحتوي على مصطلحاتٍ لا تُقرأ بشكلٍ مفهوم صوتياً.
٦. اختبار البحث والفلترة: بعض الواجهات تُتيح البحث في محتوىً عربي. تحقق من أن نتائج البحث تُعيد النتائج الصحيحة حين يبحث المستخدم بالتشكيل أو بدونه، وبالهمزة أو بدونها (أسامة / اسامة / أُسامة قد تُعطي نتائج مختلفة بحسب تكوين محرك البحث).
برومبت لتوليد قائمة اختبارٍ لغويٍ مخصصة
لكل مشروعٍ خصوصياته. استخدم هذا البرومبت للحصول على قائمة اختبارٍ لغويٍ مُخصَّصةٍ لمشروعك بسرعةٍ:
You are a senior Arabic localization QA specialist. Generate a linguistic testing checklist for the following product: Product type: [mobile app / web app / enterprise dashboard / e-commerce] Platform: [iOS / Android / Web / cross-platform] Key user flows: [list the 3–5 most important user journeys] Special content types: [e.g., prices, dates, user-generated content, legal text, error messages, notifications, onboarding screens] Target market: [Gulf / Levant / Egypt / North Africa / pan-Arab] Known risk areas: [e.g., long product names, dynamic content, mixed LTR/RTL strings] For each item in the checklist, specify: 1. What to test 2. Which screen or flow to test it in 3. What to look for (the failure mode) 4. What counts as a pass Organize by: Static Display Tests → Interaction Tests → Edge Case Tests → Full Journey Tests Flag any Arabic-specific risks based on the product type and market provided.
ملاحظة: البرومبت بالإنكليزية لأن النماذج اللغوية تُعطي نتائج أكثر اتساقاً في التعليمات الهيكلية التقنية حين تُصاغ بالإنكليزية. عدِّل القيم بين الأقواس المربعة لتعكس مشروعك وألصق البرومبت مباشرةً في أداة الذكاء الاصطناعي التي تستخدمها.
من يجري الاختبار اللغوي؟
في المشاريع الصغيرة يُجريه المترجم نفسه بعد تسليم الملفات ودمجها في البيئة الاختبارية. هذا مقبولٌ إن مُنح وقتاً كافياً ووصولاً فعلياً إلى البيئة، وليس عرضاً للشاشات المحيطة به في اجتماعٍ عبر الإنترنت.
في المشاريع المتوسطة والكبيرة، الاختبار اللغوي مهمةٌ منفصلةٌ يُنجزها مُختبِرٌ لغويٌ (Linguistic Tester) مختلفٌ عن المترجم والمراجع، لأن من ترجم النص أو راجعه يحمل ذاكرةً لما يجب أن يكون عليه النص، وهذا يُضعف قدرته على رؤية ما يظهر فعلاً.
توصيةٌ عملية: حتى لو كان المترجم هو من يختبر، اطلب منه الانتظار ٢٤ ساعةً على الأقل بعد التسليم قبل الشروع في الاختبار. المسافة الزمنية تُحدث فارقاً حقيقياً في ما يستطيع رؤيته.
ما الذي يلي في هذه السلسلة
المقالة الرابعة والأخيرة تُغلق الورشة بالبنية التحتية المصطلحية: كيف تبني مسارد مصطلحاتٍ تقنية تنمو مع منتجك وتُدار سحابياً ويصل إليها فريقك الموزَّع — لا مسرداً يُعَدُّ مرةً واحدة وينتهي به في درجٍ منسي. (راجع مقالتنا: بناء مسارد المصطلحات التقنية الحديثة وإدارتها سحابياً)
وللعودة إلى قيود واجهة المستخدم التي يكشفها الاختبار في الغالب: (راجع مقالتنا: فن ترجمة واجهات المستخدم: التعامل مع ضيق المساحة واتجاه النص)
مراجع
- Savourel, Y. (2001). XML Internationalization and Localization. Sams Publishing.
- GALA — Globalization and Localization Association (2023). Linguistic Testing Best Practices. gala-global.org
- W3C Internationalization Working Group (2024). Strings and Internationalization. w3.org
- Microsoft Globalization (2024). Localization Testing Guidelines. learn.microsoft.com
- Jiménez-Crespo, M. A. (2013). Translation and Web Localization. Routledge.
