العربية ليست طبقة ترجمة

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

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

المنهج الأفضل أن تتعامل مع اللغتين بوصفهما متطلبًا أساسيًا للمنتج منذ اليوم الأول.

لغتان تعنيان واجهتين

يمكن للعربية والإنجليزية أن تتشاركا نموذج منتج واحدًا، ونظام مكوّنات واحدًا، وقاعدة كود واحدة. لكن لا ينبغي أن تتوقع منهما شاشات متطابقة.

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

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

ابدأ من مسارات الاستخدام، لا من ملفات الترجمة

غالبًا ما يبدأ التعريب بجدول من النصوص. هذه خطوة ضرورية، لكنها متأخرة جدًا لاكتشاف ما إذا كانت التجربة نفسها تعمل باللغتين. ابدأ من مسارات المنتج بدلًا من ذلك:

• كيف يصل المستخدم إلى الخدمة التي يحتاجها؟
• ما المعلومات التي يجب أن يفهمها قبل أن يكمل؟
• أين يُدخل الأسماء وأرقام الهواتف والأسعار والعناوين؟
• أي المحتوى قد يجمع بين العربية والإنجليزية معًا؟
• ماذا يحدث حين يفشل التحقق من البيانات؟
• أي رسالة تأكيد تمنح المستخدم ثقة بأن الإجراء تم بنجاح؟

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

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

اجعل الاتجاه مسؤولية النظام لا الصفحة

يجب ضبط الاتجاه على مستوى المستند نفسه بقيم lang وdir الصحيحة، ثم ترث المكوّنات هذا السياق كلما أمكن. وخصائص CSS المنطقية تساعد الواجهة على الاستجابة بشكل طبيعي:

• margin-inline بدلًا من الهوامش اليمنى واليسرى
• padding-inline للمسافات الأفقية داخل المكوّنات
• inset-inline-start للعناصر ذات المواضع المحددة
• text-align: start بدلًا من محاذاة يسارية ثابتة
• عناصر تخطيط واعية بالاتجاه بدلًا من استثناءات فردية متفرقة

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

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

صمّم المكوّنات لمحتوى حقيقي

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

أفضّل مكوّنات تحتمل التمدّد:

• ارتفاع يحدده المحتوى
• أحجام دنيا واضحة لعناصر التحكم التفاعلية
• مسافات مرنة والتفاف نص يمكن توقّعه
• اقتطاع النص فقط حين تكون القيمة الكاملة متاحة في مكان آخر
• تغيير التخطيط عند نقاط انكسار مفيدة، لا مجرد تصغير حجم الخط

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

النماذج والجداول والتنقّل تحتاج عناية مضاعفة

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

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

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

امنح النص العربي مراجعة تحريرية

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

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

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

اختبر مسارات كاملة في الاتجاهين

الواجهة ثنائية اللغة لا تصبح جاهزة لمجرد أن الصفحة الرئيسية تبدو صحيحة باللغتين. اختبر مهام كاملة:

1. ادخل من مسار مُعرَّب.
2. تنقّل عبر القوائم وعناصر التنقّل.
3. أكمل نموذجًا ببيانات صحيحة وأخرى خاطئة.
4. افتح نافذة منبثقة أو لوحة جانبية.
5. اقرأ حالات التحميل والفراغ والخطأ والنجاح.
6. اعرض مخرجًا مولَّدًا مثل فاتورة أو رسالة تأكيد.
7. بدّل اللغة عند نقطة واقعية في منتصف المسار.
8. كرّر المسار كله على شاشة ضيقة وباستخدام لوحة المفاتيح.

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

قائمة تحقق عملية قبل الإطلاق

قبل الإطلاق، أريد إجابات واضحة عن هذه الأسئلة:

• هل تغطي اللغتان المسارات المهمة نفسها؟
• هل قيم lang وdir صحيحة في كل مسار مُعرَّب؟
• هل الخطوط والمسافات مناسبة في نظامَي الكتابة معًا؟
• هل يحترم التنقّل والأيقونات واللوحات الجانبية والانتقالات اتجاه القراءة؟
• هل تتعامل النماذج مع القيم العربية والإنجليزية والمختلطة الاتجاه؟
• هل رسائل التحقق ورسائل النظام مُعرَّبة؟
• هل تبقى الجداول ولوحات التحكم قابلة للاستخدام على الهاتف؟
• هل رُوجعت حالات التحميل والفراغ والخطأ والنجاح؟
• هل اختبر المنتجَ مراجعٌ يتقن العربية داخل سياق الاستخدام؟
• هل يستطيع الفريق تحديث الترجمات دون تعديل كود التخطيط؟

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