تتعامل معظم فرق تطوير البرمجيات مع دعم اللغة العربية كفكرة لاحقة—ترجمة النصوص، عكس اتجاه التخطيط، ثم الإطلاق. في الواقع، ينتج عن هذا تطبيقات هاتف تبدو غريبة للمتحدثين بالعربية، مع مسافات محرجة وعناصر تحكم غير متوازنة وأنماط تنقل تخالف توقعات المستخدم. يتطلب بناء تجارب هاتف عربية حقيقية نهجاً مختلفاً تماماً في التصميم والهندسة، حيث يكون الاتجاه من اليمين إلى اليسار هو السياق الأساسي وليس متغيراً مضافاً لاحقاً.
يهم هذا التمييز تجارياً في قطر ومنطقة الخليج الأوسع. عندما يتنقل المستخدمون المستهدفون يومياً في البوابات الحكومية وتطبيقات البنوك ومنصات التجارة باللغة العربية، يطورون توقعات دقيقة حول كيفية تصرف الواجهات الرقمية. التطبيق الذي يعامل العربية كلغة ثانوية يخلق احتكاكاً في كل تفاعل، من التسجيل إلى الدفع. يترجم هذا الاحتكاك مباشرة إلى هجر التطبيق ومراجعات سيئة وعبء دعم فني. بالنسبة للشركات التي تستثمر في تطوير تطبيقات الهاتف المخصصة، فهم هذه الأنماط ليس اختيارياً.
يؤثر التخطيط من اليمين إلى اليسار على أكثر بكثير من اتجاه النص. في تطبيقات الهاتف التي تعتمد تصميم واجهات مستخدم تدعم العربية بالكامل، ينعكس النموذج المكاني بأكمله. تنزلق أدراج التنقل من الحافة اليمنى. تظهر أزرار الرجوع في الزاوية العلوية اليمنى. تعكس دوارات العرض والتمرير الأفقي اتجاهها. تتغير دلالات الأيقونات—السهم الأمامي الآن يشير إلى اليسار.
توفر الأطر الحديثة مثل Flutter و React Native و SwiftUI دعماً للـ RTL على مستوى الإطار، لكنها لا تستطيع اتخاذ قرارات التصميم نيابة عنك. يمكن للمطور تعيين TextDirection.rtl ومشاهدة التخطيط ينعكس تلقائياً، ومع ذلك ينتج واجهة تبدو معكوسة ميكانيكياً بدلاً من مصممة بقصد. يتعامل الإطار مع التخطيط الدقيق—محاذاة النص داخل حاوية، اتجاه flex، ترتيب الحشو—لكن القرارات الكلية حول التسلسل البصري وكثافة المعلومات وتدفق التنقل تبقى مسؤوليات بشرية.
لنأخذ نمطاً شائعاً: التنقل بعلامات التبويب في أسفل الشاشة. في سياقات LTR، يمسح المستخدمون علامات التبويب من اليسار إلى اليمين، مع وضع الإجراءات الأساسية على اليسار. في الواجهات العربية، ينعكس ترتيب القراءة هذا، لكن الوزن الدلالي لكل موضع يتغير أيضاً. علامة التبويب الأكثر يميناً تحصل الآن على انتباه المستخدم أولاً. إذا قمت ببساطة بعكس التصميم الإنجليزي، قد يحتل إجراؤك الأساسي الآن الموضع الأقل بروزاً.
تضيف الطباعة تعقيدات لهذه التحديات. الخط العربي متصل، مع أشكال حروف مترابطة تتوسع وتنكمش بناءً على السياق. نفس النص بالعربية يكون عادة أطول بعشرين إلى ثلاثين بالمائة من مكافئه الإنجليزي، وأحياناً أكثر. حقول الإدخال والأزرار والتسميات المصممة للنص الإنجليزي ستقطع أو تلتف النص العربي بشكل محرج. متطلبات ارتفاع السطر تختلف بسبب العلامات التشكيلية فوق وتحت خط الأساس. المسافات بين الحروف تتصرف بشكل مختلف—إضافة مسافة بين الأحرف العربية تكسر الاتصال البصري الذي يجعل الخط قابلاً للقراءة.
اختيار الخط نفسه محدود. بينما تعد خطوط اللاتينية بالآلاف مع عرض مختبر جيداً على الويب والهاتف، تبقى الخطوط العربية عالية الجودة المناسبة لعمل واجهة المستخدم نادرة نسبياً. العديد من خطوط النظام الافتراضية تعرض العربية بشكل مناسب لنص الجسم لكنها تفتقر إلى تنوعات الوزن وميزات OpenType اللازمة للتسلسل الهرمي الفعال.
تجربة هاتف عربية حقيقية تأخذ في الاعتبار السياق الثقافي والوظيفي، وليس فقط الترجمة اللغوية. تختلف تنسيقات التاريخ والوقت—يبقى التقويم الهجري ذا صلة بالمناسبات الدينية وبعض الوظائف الحكومية. يختلف عرض الأرقام؛ بينما الأرقام العربية الشرقية (٠١٢٣) قياسية في بعض المناطق، تستخدم قطر ومعظم الخليج عادة الأرقام الغربية (0123) حتى في النص العربي. يجب على تطبيقك التعامل مع الاثنين، ومن الأفضل احترام تفضيلات المستخدم أو النظام.
يتبع تنسيق العملة اتفاقيات مختلفة. في الإنجليزية، "QAR 1,500.00" قياسي؛ بالعربية، قد يظهر رمز العملة بعد الرقم، وقد يختلف استخدام الفاصلة/العلامة العشرية حسب اللغة. يجب أن تستوعب تدفقات الدفع الطرق المحلية—QPay، المحافظ الرقمية المختلفة لـ QNB، والتكامل مع أنظمة رواتب WPS لتطبيقات B2B. هذه ليست مجرد تكاملات تقنية؛ إنها تشير إلى ما إذا كان تطبيقك يفهم بيئة الأعمال المحلية.
يتطلب تصميم النماذج إعادة التفكير في التحقق وأنماط الإدخال. الأسماء العربية لا تتبع هياكل الاسم الأول/اللقب الغربية بشكل موثوق. تختلف تنسيقات أرقام الهواتف، ويحتفظ العديد من المستخدمين القطريين بأرقام متعددة. تعتمد أنظمة العناوين في الدوحة بشكل كبير على أرقام المناطق والمعالم بدلاً من عناوين الشوارع، وهو نمط يكسر مكونات إدخال العنوان النموذجية. التصميم العربي الأول يتوقع هذه الأنماط بدلاً من إجبار المستخدمين على نماذج بيانات أجنبية.
نقاط التكامل الحكومية—التحقق من الهوية عبر توثيق، متراش2 للخدمات القانونية، الوصول إلى بوابة حكومي—تتوقع العربية كلغة واجهة أساسية. إذا كان تطبيق الهاتف المؤسسي الخاص بك بحاجة إلى التشغيل البيني مع هذه الأنظمة، فإن النموذج الذهني للمستخدم هو بالفعل عربي أولاً. التبديل المفاجئ إلى الإنجليزية لسير العمل الرئيسية يخلق عبئاً معرفياً ويقوض الثقة.
النهج الأكثر استدامة يعامل الاتجاهين كمتطلب أساسي أثناء الاكتشاف والتصميم، وليس كمهمة ترجمة بعد الإطلاق. يعني هذا تصميم الشاشات في كلا الاتجاهين في وقت واحد، واتخاذ مقايضات تعمل في كلا السياقين، والاختبار بمحتوى عربي من النماذج الأولية الأولى.
يجب أن يأخذ اختيار الأيقونة في الاعتبار الدلالات الاتجاهية. الشيفرون أو السهم الذي يشير إلى اليمين يعني "للأمام" في سياقات LTR لكن "للخلف" في RTL. بعض الأيقونات—تروس الإعدادات، عدسات البحث المكبرة، علامات الجمع—محايدة اتجاهياً. أخرى—عربات التسوق، محاذاة القوائم، عناصر تحكم الوسائط—تحمل معنى اتجاهياً يتطلب الانعكاس. بعض الأيقونات لا يجب أن تنعكس أبداً: الساعات تدور دائماً في اتجاه عقارب الساعة، النوتات الموسيقية لها سيقان ثابتة، والشعارات تبقى دون تغيير.
يجب أن تستخدم شبكات التخطيط وأنظمة المسافات خصائص منطقية بدلاً من مادية. بدلاً من margin-left، استخدم margin-inline-start؛ استبدل padding-right بـ padding-inline-end. يسمح هذا النهج الدلالي لأوراق الأنماط بالتكيف تلقائياً مع اتجاه النص دون تجاوزات هشة.
يجب أن تخطط استراتيجية المحتوى لطول النص المتغير. نسخة واجهة المستخدم الإنجليزية موجزة بشهرة؛ المكافئات العربية تتوسع. تحتاج الأزرار وتسميات التنقل إلى مساحة للتنفس. التخطيطات ذات العرض الثابت تنكسر. يجب أن تحدد أنظمة التصميم أهداف اللمس الدنيا وأطوال التسمية القصوى بكلتا اللغتين، ثم فرضها أثناء التطوير.
يتطلب الاختبار متحدثين أصليين بالعربية يراجعون التدفقات في السياق، وليس فقط مهندسي ضمان الجودة يتحققون من عرض النص. يكتشف القراء الطلقون على الفور الصياغة غير الطبيعية ومستويات الرسمية غير المناسبة والأخطاء الثقافية التي تمر دون أن يلاحظها أحد في المراجعة التقنية.
يحمل عرض النص العربي تداعيات الأداء. تشكيل النص المعقد—عملية تحويل نقاط كود Unicode إلى حروف مطبوعة موضعية—أكثر تكلفة للعربية من النص اللاتيني بسبب أشكال الحروف السياقية والحروف المركبة. على أجهزة Android الأقل قوة التي لا تزال شائعة في بعض شرائح المستخدمين، يمكن للشاشات الثقيلة بالنص أن تظهر jank ملحوظاً في التخطيط إذا لم يتم تحسينها.
يهم حجم ملف الخط لحجم تنزيل التطبيق الأولي وأوقات تحميل تطبيق الويب. تتطلب الخطوط العربية حروفاً أكثر من اللاتينية الأساسية، مما ينتج ملفات أكبر. الاستفادة من الخطوط من البنية التحتية المحلية لـ CDN في قطر يقلل الكمون مقارنة بالجلب من CDNs العالمية.
تنطبق لوائح إقامة البيانات والخصوصية بموجب قانون حماية خصوصية البيانات الشخصية القطري (PDPPL) بالتساوي على المحتوى العربي والإنجليزي، لكن المحتوى العربي غالباً يكشف أكثر عن هوية المستخدم والممارسة الدينية. إذا كان تطبيقك يتعامل مع أوقات الصلاة أو المحتوى القرآني أو أحداث التقويم الهجري، فقد تكون هذه البيانات أكثر حساسية من المحتوى العلماني المكافئ بالإنجليزية.
في جري داتا، نبدأ كل مشروع هاتف بافتراض أن العربية ليست هدف ترجمة بل لغة واجهة أساسية. تتضمن عملية الورشة الخاصة بنا مراجعات تصميم واجهة المستخدم العربية من الرسومات الأولى، مما يضمن أن أنماط التنقل وهندسة المعلومات والتسلسل البصري يعملان بشكل ثنائي الاتجاه. نضع نماذج أولية بكلتا اللغتين في وقت واحد، لاكتشاف فواصل التخطيط وتجاوز المحتوى قبل أن تصل إلى التنفيذ.
تفرض ممارساتنا الهندسية خصائص التخطيط المنطقية، والاختبار ثنائي الاتجاه في خطوط CI، ومعايير إمكانية الوصول التي تأخذ في الاعتبار سلوك قارئ الشاشة العربي. نعمل مع الشركات القطرية يومياً—التكامل مع معالجات الدفع المحلية، أنظمة رواتب WPS، واجهات برمجة التطبيقات الحكومية، ومنصات ERP العربية—لذلك نفهم المتطلبات الوظيفية بخلاف دعم اللغة الصرف. عندما نبني تطبيقات الهاتف المخصصة أو حلول متعددة المنصات للمؤسسات، يكون تصميم واجهات المستخدم التي تدعم العربية مدمجاً في تقديم خدماتنا، وليس مضافاً بعد ذلك. النتيجة هي برامج هاتف تبدو أصلية للمستخدمين العرب لأنها صممت لهم من البداية.