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

معظم التطبيقات المبنية في المنطقة تُبنى بالإنجليزية ثم تُترجم. وهو الافتراض لأنه طريقة عمل الفريق، وأدوات التصميم تفترض ذلك، والعربية تبدو شيئًا يُضاف في النهاية.
ولا يمكن ذلك، والسبب ليس لغويًا. الاتجاه من اليمين إلى اليسار خاصية في نظام التخطيط لا في النصّ داخله. ومع اكتمال التطبيق تكون تلك الخاصية قد افتُرضت مئات المرات، وعكسها يعني إعادة زيارة كل شاشة.
الإجابة المباشرة
الترجمة مهمة محتوى. والتوطين قرار معماري. والفرق يهم لأن الأولى يمكن أن تحدث في أي وقت والثانية لا.
إن كانت حصة معتبرة من مستخدميك يقرأون العربية أولًا، فصمّم وابنِ من اليمين إلى اليسار من البداية. ليس لأنه أكثر احترامًا — وإن كان — بل لأن تركيبه لاحقًا يكلّف روتينيًا أكثر من بناء الواجهة الأصلي كلّه، وتبقى النتيجة تُحسّ ترجمة.
حين بنينا Halaly، وهو سوق عربي أولًا للمنتجات والخدمات الزراعية، كان من اليمين إلى اليسار من البنية. ولهذا يُقرأ كمنتج عربي أصيل لا كإنجليزي يرتدي العربية.
والنسخة الويب من هذه الحجّة في تصميم المواقع العربية في دبي. وهذا عن الجوال، حيث القيود مختلفة وأقل تسامحًا.
ما يُعكس وما يجب ألا يُعكس
هنا يفضح معظم التطبيقات المركّبة لاحقًا نفسه.
يُعكس: محور التخطيط، واتجاه التنقّل، وإيماءات الرجوع، وموضع القائمة الجانبية، ومؤشرات التقدّم، ومحاذاة عناصر القوائم، والأيقونات الاتجاهية.
لا يُعكس: الشعارات، وأزرار تشغيل الوسائط، ووجوه الساعات، وصور الأجسام الواقعية ذات الاتجاه الثابت.
الأرقام قرار قائم بذاته. مستخدمو العربية في الإمارات يقرأون بأغلبية ساحقة الأرقام الغربية (1، 2، 3) لا المشرقية. والافتراض بالمشرقية لأنها تبدو أكثر عروبةً خطأ شائع يجعل التطبيق أصعب.
النص مختلط الاتجاه هو الحالة الصعبة. جملة عربية تحوي اسم علامة إنجليزية أو رابطًا أو رقمًا تحتاج معالجة ثنائية الاتجاه. والخطأ فيها يضع علامات الترقيم في الجهة الخطأ — خطأ صغير يراه القارئ العربي فورًا ولا يراه فريق لا يقرأ العربية.
الخطوط ليست تبديل خطّ
للعربية مقاييس تختلف عن اللاتينية، ومعاملة الخط كمتغيّر مع تثبيت كل شيء آخر ينتج نصًا صحيحًا تقنيًا ومزعجًا بصريًا.
العربية تحتاج ارتفاع أسطر أكبر. للخط صاعدات ونازلات تتصادم عند تباعد الأسطر اللاتيني.
وتحتاج عمومًا حجمًا أكبر. أشكال الحروف العربية تحمل تفصيلًا أكثر عند الأحجام الصغيرة.
الأوزان لا تتطابق. قارِنها بالعين لا بالاسم.
التباعد بين الحروف لا ينطبق. العربية خط متصل؛ والتباعد الذي يحسّن عنوانًا لاتينيًا يفكّك الكلمات العربية.
وعمليًا يعني ذلك أن مقياس الخط زوج من المقاييس، وأن نظام التصميم يحتاج طبقة واعية باللغة.
بناؤه داخل النظام
المبدأ الهندسي بسيط: لا تضمّن الاتجاه في الكود أبدًا.
استخدم الخصائص المنطقية — start وend لا left وright. ويدعم ذلك كل من React Native وFlutter، وقاعدة كود مكتوبة بها من اليوم الأول تنقلب مجانًا تقريبًا.
وموضعان ينكسران حتى مع ذلك:
الحركات والإيماءات المخصّصة. سحب للحذف مبني على افتراض يساري سيكون معكوسًا.
العناصر ذات الموضع المطلق. ما يُوضع بالإحداثيات لا ينقلب.
اختبر الاتجاهين باستمرار. لا في جولة مراجعة أخيرة. خطأ RTL يُكتشف قبل الإطلاق بأسبوع خطأ اُكتشف متأخرًا.
المحتوى لا الواجهة فقط
الواجهة هي النصف السهل.
النبرة والمستوى. العربية الفصحى صحيحة وقد تُقرأ جامدة في تطبيق استهلاكي؛ واللهجة أدفأ وأقل قابلية للتنقّل عبر الخليج. ومعظم المنتجات تستقرّ على فصحى مبسّطة.
الترجمة الآلية مرئية. القرّاء العرب يرونها فورًا.
محتوى المستخدمين مختلط. الإعلانات والتقييمات ستصل باللغتين مهما كان إعداد الواجهة.
توطين متجري التطبيقات عمل منفصل يُنسى غالبًا، وهو حيث يحدث الاكتشاف فعلًا.
التكلفة
البناء بالعربية أولًا يضيف نحو 15–25% إلى وقت التصميم والاختبار وقليلًا جدًا إلى الهندسة، شريطة استخدام الخصائص المنطقية من اليوم الأول.
وتركيبه في تطبيق مكتمل يكلّف روتينيًا أكثر من بناء الواجهة الأصلي. والفرق بين الرقمين هو الحجّة كلّها.
راجع تطوير تطبيقات الجوال في دبي، والسيو العربي في الإمارات للنصف الآخر.
الأسئلة الشائعة
هل نضيف العربية لاحقًا؟ تقنيًا نعم، لكن بتكلفة مرتفعة. الإضافة اللاحقة تعني مراجعة كل شاشة بحثًا عن اتجاهات ثابتة، وإعادة بناء نظام الخطوط، وإصلاح الحركات، ثم إعادة الاختبار. وقد تتجاوز كلفتها بناء الواجهة الأصلي. إن كانت العربية ضمن الخطة، فاستخدم الخصائص المنطقية من البداية حتى لو أطلقت الإنجليزية أولًا.
هل يضاعف RTL عمل التصميم؟ لا. عند التخطيط له من البداية يضيف عادةً نحو 15–25% إلى وقت التصميم وضمان الجودة. تنعكس معظم الشاشات تلقائيًا عندما يستخدم التخطيط الخصائص المنطقية؛ ويتركز الجهد الإضافي في الخطوط، والنص المختلط، والمكوّنات القليلة التي تحتاج معالجة صريحة.
أرقام مشرقية أم غربية؟ الأرقام الغربية (1، 2، 3) أنسب للإمارات ومعظم جمهور الخليج. قد تبدو الأرقام المشرقية أكثر عربية، لكنها أبطأ في القراءة العملية لدى كثير من المستخدمين، خصوصًا في الأسعار وأرقام الهواتف.
أي خطوط عربية تصلح للجوال؟ اختر خطًا مصممًا للشاشات وله مدى أوزان يقابل الخط اللاتيني، ثم قارنهما بصريًا بدل الاعتماد على الاسم. توقّع زيادة حجم الخط وارتفاع السطر قليلًا مقارنة بإعدادات النص اللاتيني.
هل نحتاج قوائم متجر منفصلة؟ لا تحتاج تطبيقًا منفصلًا، بل بيانات متجر موطّنة داخل القائمة نفسها: العنوان والوصف والكلمات المفتاحية ولقطات الشاشة بالعربية. المتجر مصدر مهم للاكتشاف العضوي، ومع ذلك تُهمَل ترجمته كثيرًا.
كيف نختبر RTL كما ينبغي؟ باستمرار لا في نهاية المشروع. راجع كل إصدار بالاتجاهين، وليكن في الفريق شخص واحد على الأقل يقرأ العربية. أخطاء علامات الترقيم ثنائية الاتجاه قد لا يراها غير القارئ، لكنها واضحة فورًا للمستخدم العربي.
وماذا عن المحتوى المختلط؟ خطّط له لأن المستخدمين سينتجونه. يجب أن يدعم البحث الخطين، وأن يعرض التخطيط عنصرًا عربيًا داخل واجهة إنجليزية بصورة سليمة، وأن يتعامل مع اتجاه النص بدقة لا بالتقريب.
فصحى أم لهجة؟ استخدم فصحى مبسطة لمعظم المنتجات الاستهلاكية: طبيعية وقابلة للاستخدام في دول الخليج. اللهجة أدفأ لكنها تضيق السوق. والأفضل أن يكتب النص شخص يكتب العربية فعلًا، لا مترجم يراجعها فقط.
الخلاصة
العربية أولًا ليست ميزة ولا مجاملة. إنها قرار عمّا يفترضه نظام تخطيطك، وهو من القرارات القليلة التي يصعب عكسها فعلًا.
إن كنت تحدّد نطاق منتج لجمهور عربي، تواصل معنا. وجانب البناء تحت تطوير تطبيقات الجوال.