واجهات عربية RTL تصمد أمام لوحات التحكم والفواتير

القرار الأعلى مردودًا على الإطلاق هو كتابة التخطيط بالخصائص المنطقية من اليوم الأول: ‎margin-inline-start بدل ‎margin-left، و‎padding-inline-end بدل ‎padding-right، ومحاذاة start/end بدل left/right. وفي Tailwind يعني ذلك أن تكون ‎ms-*‎ و‎me-*‎ و‎ps-*‎ و‎pe-*‎ و‎text-start ردود أفعال تلقائية، لا نظيراتها الفيزيائية أبدًا.

افعل ذلك و90% من دعم RTL لن يكلف شيئًا — ورقة الأنماط نفسها تخدم الاتجاهين. تجاهله وسيتحول كل خاصية فيزيائية إلى تصحيح ‎[dir="rtl"]‎ مستقبلي، ويصبح ملف التصحيحات مشروعًا قديمًا قائمًا بذاته. ورثتُ مشاريع في الحالتين؛ والفرق يُقاس بالأسابيع.

المشكلة الصعبة حقًا هي المحتوى مختلط الاتجاه. جملة عربية تحوي كود منتج أو رابطًا أو بريدًا إلكترونيًا أو اسم علامة أجنبية حقلُ ألغام: خوارزمية Unicode للاتجاه ستعيد ترتيب "ABC-123" بسرور، أو تقسم رقم هاتف عبر سطرين بطريقة تبدو للقارئ كأنها بيانات تالفة.

القواعد العملية: غلّف الجزر اللاتينية — الأكواد والروابط والبريد ومسارات الملفات — في عناصر ‎dir="ltr"‎ أو اعزلها بعزل الاتجاه (‎unicode-bidi: isolate، أو علامة ‎‎‎ حيث لا تتوفر الوسوم). وأبقِ أرقام الهواتف LTR دائمًا. واعرض نصوص المستخدمين بـ‎dir="auto"‎، لأن منصةً يكتب مستخدموها العربية والإنجليزية ستستقبل الاثنتين، وغالبًا في الحقل نفسه.

الواجهات المالية تفرض قرارات لا تواجهها الصفحات التسويقية أبدًا. أرقام غربية أم أرقام عربية مشرقية؟ خياري الافتراضي هو الأرقام الغربية لكل ما هو معاملات — المبالغ وأرقام الفواتير وأرقام IBAN — لأنها تطابق ما تعرضه البنوك والإيصالات والآلات الحاسبة، وتبقى الأرقام المشرقية تفضيلَ لغةٍ للنصوص السردية. وأيًا كان الخيار، يجب أن يكون خيارًا واحدًا مطبقًا في كل مكان؛ فخلط نظامي أرقام في مستند واحد يُقرأ كخطأ برمجي.

العملات والتواريخ تمر عبر ‎Intl.NumberFormat و‎Intl.DateTimeFormat بلغة صريحة، لا عبر لصق النصوص أبدًا — فموضع رمز العملة، وشكل فاصل الآلاف، وترتيب أجزاء التاريخ كلها قرارات لغوية تخطئها النصوص المبنية يدويًا. الفاتورة مستند قانوني؛ والتنسيق "الصحيح تقريبًا" خطأ.

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

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

الخط العربي يحتاج قرارًا خاصًا به، لا مصادفةَ سلسلةِ خطوطٍ احتياطية. فحروف العربية أعلى صعودًا وأعمق نزولًا من اللاتينية، وخط العناوين الذي يبدو رائعًا بالإنجليزية سيقصّ العربية ما لم تُضبط ‎line-height وأحجام ‎clamp لكل نظام كتابة على حدة — عنوان موقعي الشخصي نفسه يعمل بقواعد قياس مختلفة لكل لغة لهذا السبب تحديدًا. خطوط Cairo وIBM Plex Sans Arabic وعائلة Noto حملت كل مشاريعي بجدارة.

والمستندات المولّدة هي الاختبار الأخير: ملفات PDF والشهادات وقوالب البريد. خطوط أنابيب HTML-to-PDF وعملاء البريد لكلٍّ منها غرائبها مع ثنائية الاتجاه، وشهادةٌ باسم معكوس أو تاريخ مكسور تذكرةُ دعمٍ قادمة من أفخر لحظات صاحبها. كل قالب مستند يُعرض ويُفحص بالعين باللغتين قبل شحنه — لا طريق مختصر هنا.

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

قاعدتي في كل ميزة: ليست منتهية حتى تُرى بالعربية. لا تُترجم لاحقًا، ولا تُقلب لاحقًا — تُرى بالعربية قبل الدمج. فـRTL كفكرةٍ لاحقة هو الطريق الذي يحوّل منتجًا ثنائي الاتجاه إلى منتجين.