ترجمة واجهات المستخدم العربية: المساحة والـ RTL والثقافة

ورشة: التوطين لتطبيقات الويب ٣.٠ والذكاء الاصطناعي · المقالة الثانية من أربع

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

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

المشكلة الأولى: العربية تحتاج مساحةً أكبر — عادةً

القاعدة العامة في توطين البرمجيات هي أن النصوص تتمدد حين تُترجم عن الإنكليزية. الإسبانية تتمدد بنسبة ٢٠–٣٠٪، والألمانية أكثر. العربية تُخالف هذه القاعدة أحياناً وتُوافقها أحياناً أخرى — بطريقةٍ غير متوقعة تُضلِّل من لا يعرف الخصوصيات.

العربية لغةٌ اشتقاقية تُبنى فيها كلماتٌ طويلة من جذورٍ قصيرة. «Settings» كلمةٌ من ثمانية أحرف — مقابلها العربي «الإعدادات» عشرة أحرف. لكن «Authentication» ستة عشر حرفاً — ومقابلها «المصادقة» سبعة أحرف فقط. «Decentralized» اثنا عشر حرفاً — «اللامركزية» أحد عشر. العربية تكسب أحياناً وتخسر أحياناً، وهذا التفاوت هو ما يجعل الاختبار اليدوي لا بديل عنه.

لكن التحدي الأعمق ليس عدد الأحرف — بل نظام الخط نفسه. العربية المتصلة تحتاج إلى مساحةٍ بصرية أوسع بين الكلمات لتبقى مقروءة. العنوان الذي يتسع له خط لاتيني بحجم ١٤ يحتاج حجم ١٢ بالعربية للبقاء ضمن المساحة ذاتها — وتصغير الخط يضر بالقراءة. هذه معضلةٌ حقيقية لا حلَّ نظرياً لها: تحلُّها باختصار النص لا بتصغير الخط.

ثم أن هذا يتعلق بشيءٍ آخرٍ مهم بصرياً وجمالياً وهو نوع الخط المستخدم، هنا في منصتنا نستخدم في متن المقالات خط (Amiri) بحجم 22، وهو ما يوحي بأنه ضخم خاصة وأنه يصنف من خط النسخ، لكن له دلالة قديمة تراثية اذ استخدمته أوائل المطابع العربية القديمة “الأميرية بولاق بالقاهرة”، وهو أشبه بالكوفي من النسخ المعاصر.. سترى أنه يجعل الكلمات أصغر مساحةً لو كانت الكلمة مفردةً، لكنه يترك مسافات أكبر بين الكلمات.

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

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

استراتيجيات الاختصار: ست أدواتٍ عملية

حين تضيق المساحة، ثمة ست استراتيجياتٍ مرتَّبة من الأكثر أماناً إلى الأكثر جرأةً:

١. حذف الأدوات والضمائر الزائدة: «اضغط على هذا الزر لتأكيد طلبك» يمكن اختصارها إلى «اضغط لتأكيد الطلب» — المعنى كاملٌ والمساحة انخفضت بنسبة ٣٠٪. الواجهات لا تحتاج أسلوب الكتابة المقالية.

٢. تفضيل الفعل على المصدر: «قم بتنزيل الملف» ← «نزِّل الملف». «قم بتفعيل الخيار» ← «فعِّل». الفعل المباشر أقصر وأوضح وأكثر ملاءمةً لنبرة الواجهات.

٣. استخدام الاسم المختصر بدلاً من الجملة الوصفية: «صفحة إعدادات الحساب الشخصي» ← «إعدادات الحساب». الواجهات تعمل بالتسميات لا بالجمل.

٤. تبني المصطلح التقني المتعارف عليه بدلاً من شرحه: إن كان المستخدم العربي يعرف «ملف تعريف الارتباط (كوكيز)» فاكتب «ملفات تعريف الارتباط» لا «البيانات المخزَّنة مؤقتاً في متصفحك لتذكُّر تفضيلاتك».

٥. قبول الاختصار المنطقي في سياقٍ واضح: زر «تأكيد» يكفي في سياقٍ واضح دون «تأكيد العملية». «إلغاء» أفضل من «إلغاء الإجراء والعودة».

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

المشكلة الثانية: عكس التخطيط — ما هو بصري لا ما هو لغوي

الخطأ الأكثر شيوعاً في مشاريع توطين الواجهات العربية هو الخلط بين مشكلتَين مستقلتَين: اتجاه النص واتجاه التخطيط. هما مترابطتان لكنهما ليستا الشيء ذاته — والخلط بينهما يُنتج واجهاتٍ مشوَّهة حتى لو كان النص العربي صحيحاً.

اتجاه النص (Text Direction): العربية تُكتب من اليمين إلى اليسار. هذا يعني أن بداية الجملة على اليمين ونهايتها على اليسار. معظم المتصفحات وأنظمة التشغيل الحديثة تتعامل مع هذا تلقائياً حين يُضبط خاصية `dir=”rtl”` أو `lang=”ar”` بشكلٍ صحيح.

اتجاه التخطيط (Layout Mirroring): مسألةٌ مختلفة. في الواجهة العربية لا يكفي عكس اتجاه النص — يجب عكس التخطيط كله. القائمة الجانبية تنتقل من اليسار إلى اليمين. الأيقونة التي تسبق النص في الواجهة الإنكليزية تلحقه في العربية. السهم الذي يشير إلى «التالي» يشير يساراً في الإنكليزية ويميناً في العربية. شريط التقدم يمتلئ من اليمين إلى اليسار.

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

• موضع القائمة الجانبية (Navigation Drawer/Sidebar)
• اتجاه الأسهم في أزرار التنقل والتقدم
• اتجاه امتلاء أشرطة التقدم (Progress Bars)
• موضع الأيقونات نسبةً إلى النص في الأزرار
• اتجاه خطوط الجداول والبطاقات (محاذاة اليمين للعناوين)
• الرسوم البيانية التي تعرض تسلسلاً زمنياً (من اليمين إلى اليسار)
• مكان ظهور الرسائل المنبثقة (Toasts/Notifications)

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

المشكلة الثالثة: الأرقام — أيٌّ منهما وفي أي سياق؟

سؤالٌ يطرحه كل مترجمٍ جديد على توطين الواجهات: هل أستخدم الأرقام العربية الهندية (١٢٣) أم الأرقام الغربية العربية (123)؟

الإجابة ليست «أيٌّ منهما صحيح» بل «أيٌّ منهما يخدم هذا المستخدم في هذا السياق». الاعتبارات:

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

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

التوافق التقني: بعض واجهات البرمجة (APIs) وقواعد البيانات لا تتعامل جيداً مع الأرقام الهندية في حقول البيانات. تأكد من أن خيارك متوافقٌ مع الطبقة التقنية لا مجرد جمالٍ بصري.

القاعدة العملية: وثِّق الخيار في مسرد المشروع واسأل العميل عنه صراحةً في مرحلة الإحاطة — لا تفترض.

المشكلة الرابعة: النبرة والثقافة — حيث تفشل الترجمة الصحيحة

واجهةٌ ترجمتها صحيحةٌ نحوياً وفاشلةٌ ثقافياً ظاهرةٌ شائعة في مشاريع توطين اقتصرت على اللغة دون الثقافة. بعض الأمثلة:

المخاطبة والتعظيم: الإنكليزية ليس فيها تمييزٌ رسمي/غير رسمي في ضمير المخاطب — «you» لجميع المواقف. العربية فيها «أنت» الحميمة و«أنتم» التعظيمية. الواجهات التجارية العربية تُفضِّل «أنت» للمخاطبة المباشرة حتى في السياقات الرسمية نسبياً — لأن ذلك يُشعر المستخدم بأن المنتج يُخاطبه شخصياً. لكن مؤسساتٍ كالبنوك والجهات الحكومية قد تفضِّل «أنتم» أو صياغاتٍ تتجنب الضمائر كلياً.

رسائل الخطأ — المشكلة الأكثر إهمالاً: رسالة الخطأ بالإنكليزية تكون مباشرة: «Invalid email address». الترجمة الحرفية «عنوان البريد الإلكتروني غير صالح» تقنياً صحيحة لكنها باردةٌ في ثقافةٍ تُفضِّل اللطف حتى في التصحيح. «يبدو أن عنوان بريدك الإلكتروني غير مكتمل، تأكد منه وأعد المحاولة» — أطول لكن أكثر توافقاً مع التوقع الثقافي. هذا تقنياً قرار المنتج لا المترجم — لكن المترجم المحترف يُنبِّه عليه.

المصطلحات الحساسة ثقافياً: «Casino» في تطبيقٍ لألعاب الفيديو يُترجم «كازينو» بدون تفكير في السياقات الغربية. في السوق العربية التي تشمل جمهوراً مسلماً واسعاً، القرار يحتاج تشاوراً مع العميل — هل يُبقي المصطلح أم يُعيد تأطير اللعبة بمصطلحاتٍ محايدة؟ هذا ليس تديُّناً إنه تسويق ذكي، ثم أن هنالك كلمات عربية كثيرة قد تعوض التسمية من دون ايحاء ذو حساسية دينية “لعبة الحظ، لعبة نرد، الخ..”

إرشادات المستخدم والتعليمات: الإنكليزية تستخدم الأمر الصريح: «Click here», «Enter your name». العربية في الواجهات تستخدم الأمر كذلك لكن مع انتباهٍ للإيقاع — «اكتب اسمك» أوضح من «أدخل اسمك» رغم أن كلتيهما صحيحتان. «أدخل» أكثر رسميةً و«اكتب» أكثر تلقائية. السياق يحكم.

ما لا تُعوِّضه الأدوات: الحكم البشري في خمس لحظات

أدوات الترجمة الآلية وأدوات التوطين المدعومة بالذكاء الاصطناعي ستُعطيك مقترحاتٍ سريعة لواجهات المستخدم. لكن ثمة خمس لحظاتٍ يجب أن يتدخل فيها الحكم البشري المحترف:

١. حين تتعارض الدقة مع المساحة: الأداة لن تُخبرك أن ترجمتها تفيض من الزر بخمسة أحرف — ستعطيك الترجمة الصحيحة وتترك المشكلة البصرية لك.

٢. حين يكون المصطلح غير مستقر: رأينا في المقالة الأولى أن «البرومبت» و«البروميت» كلتيهما تتداولان. الأداة ستختار واحدةً — لكن المترجم المحترف يُوثِّق الخيار ويُبلِّغ مدير المشروع.

٣. حين تكون رسالة الخطأ في منطقةٍ ثقافياً حساسة: «حسابك محظور» مقابل «لا يمكن الوصول إلى حسابك حالياً» — الفارق ثقافيٌّ لا لغوي.

٤. حين يكون العنصر البصري بحاجةٍ إلى عكسٍ لم يُذكر في المواصفات: المترجم الذي يلاحظ أن سهم «التالي» يشير يساراً ولا يُبلِّغ عنه يُهمل جزءاً من عمله.

٥. حين تُخالف الترجمة الصحيحة نظام التصميم: مكتبة مكوِّناتٍ مثل Ant Design أو Material UI تحتوي على نصوصٍ افتراضية. المترجم يُترجمها — لكن التحقق من أن النص المُترجم يتناسب مع قواعد التصميم في النظام يحتاج تعاوناً مع فريق التطوير.

 

برومبت لمراجعة ترجمة الواجهات

حين تُنهي ترجمة مجموعة من نصوص الواجهة وتريد مراجعةً سريعة قبل التسليم، استخدم هذا البرومبت للكشف عن المشكلات الشائعة:

You are a senior Arabic UI/UX localization reviewer.

Review the following Arabic UI strings translated from English.
Flag any string that has one or more of these problems:

1. LENGTH: Arabic translation is significantly longer than the English source
   (estimate if it exceeds the character limit by more than 20%)
2. REGISTER: Translation uses formal MSA when the product targets young/casual
   users, or vice versa
3. DIRECTNESS: Translation adds unnecessary words not in the source
   (e.g., "قم بـ" constructions where a direct verb suffices)
4. TERMINOLOGY: A term appears inconsistently across strings
   (flag if you see the same English term rendered two different ways)
5. CULTURAL TONE: Error messages or warnings that may read as harsh or
   impolite for Arabic-speaking audiences
6. NUMBERS: Mixed use of Arabic-Indic (١٢٣) and Western-Arabic (123) numerals
   without apparent reason

For each flagged string, state: the problem type, the original string,
the current translation, and a suggested correction.

Source language: English
Target language: Arabic (Modern Standard Arabic / [specify dialect if relevant])
Product type: [mobile app / web app / enterprise software]
Target market: [Gulf / Levant / Egypt / North Africa / pan-Arab]

Strings to review:
[paste your string table here as: English | Arabic]

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

ما الذي يلي في هذه السلسلة

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

وللعودة إلى أساسيات بناء المسرد المصطلحي الذي يجعل ترجمة الواجهات متسقةً من البداية: (راجع مقالتنا: مدخل إلى مصطلحات الميتافيرس والبلوكشين والوكلاء الذكيين بالعربية)

---

مراجع

1. Esselink, B. (2000). A Practical Guide to Localization. John Benjamins Publishing.
2. W3C Internationalization Working Group (2023). Arabic & Hebrew Layout Requirements. w3.org/TR/alreq
3. Apple Human Interface Guidelines (2024). Right to Left. developer.apple.com
4. Google Material Design (2024). Bidirectionality. m3.material.io
5. Nielsen, J. & Pernice, K. (2010). Eyetracking Web Usability. New Riders.