RTL ليس ميزة، بل موقف

أغلب 'دعم RTL' الذي أراه في الإنتاج هو قاعدة CSS direction: rtl ودعاء. ينقلب التخطيط، تتحرك الأيقونات، ويضع الفريق علامة. ثم يصل المستخدمون العرب، والتجربة خاطئة بشكل خفي: الأرقام تُقرأ backwards، صيغ الوقت تتجاهل اللغة، الأنيميشن تنزلق بالاتجاه الخطأ، والطباعة — حتى بالخط الصحيح — تبدو ترجمة لا صوتًا أصيلًا.

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

ثم الأرقام. الناطقون بالعربية يستخدمون الأرقام الغربية (1, 2, 3) في أغلب السياقات، والشرقية (١, ٢, ٣) في أخرى. الاختيار الصحيح يعتمد على اللهجة والرسمية والجمهور. تثبيت أيهما خطأ. استخدم Intl.NumberFormat باللغة الصحيحة ودع المنصة تقرر.

التواريخ والأوقات أسوأ. أغلب التطبيقات ت افتراضيًا صيغًا أمريكية (MM/DD/YYYY، ساعة ١٢) بغض النظر عن اللغة. المستخدمون العرب في مصر يتوقعون DD/MM/YYYY وساعة ٢٤. في السعودية قد يتوقعون تواريخ هجرية بجانب الميلادية. Intl API يتعامل مع كل هذا — استخدمه.

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