تصميم مواقع RTL يعني بناء الموقع بحيث يعمل بشكل صحيح عندما يُقرأ من اليمين إلى اليسار — كما تُقرأ العربية والعبرية — لا مجرد قلب اتجاهه ليبدو كذلك. معظم المواقع التي تخدم جمهوراً عربياً تبدأ كتصميم من اليسار إلى اليمين ثم "تُترجم"، والترجمة وحدها لا تلمس البنية الأساسية: الأيقونات تبقى تشير للاتجاه الخطأ، والتخطيط لا ينعكس بشكل متسق بين الأقسام، والتواريخ وأرقام الهواتف تنكسر في منتصف الجملة، والخط لم يُصمَّم أصلاً للغة التي يعرضها. حين يُنفَّذ بشكل صحيح، يكون RTL قراراً في البنية لا في المحتوى — وهو الفارق بين موقع يشعر الزائر العربي أنه "له"، وموقع يبدو وكأنه أُضيف كفكرة لاحقة.
لماذا لا تكفي "الترجمة" وحدها
عندما تستبدل النص الإنجليزي بالعربي وتُبقي نفس ملف الـCSS، تحصل على موقع يُقرأ من اليمين إلى اليسار لكنه ما زال يتصرف من الداخل كأنه من اليسار إلى اليمين. الصناديق تبقى عائمة نحو الجهة الأصلية، والمسافات المكتوبة بشكل ثابت كـmargin-left أو padding-right تبقى في مكانها تماماً، والعناصر التفاعلية — أزرار الرجوع، حقول النماذج، مسار التنقل، الأشرطة الجانبية — تبقى مثبتة في موضعها الأصلي بينما ينعكس النص المحيط بها. النتيجة صفحة دفع يشير فيها زر "متابعة" بصرياً للخلف، وحقل بحث توجد أيقونته في الطرف الخطأ، ومسار تنقل يُقرأ بترتيب لا يتوقعه أي قارئ عربي. هذه ليست مشكلة ترجمة، بل مشكلة تخطيط لا تلمسها الترجمة إطلاقاً.
الأيقونات والأسهم والحركات: عندما تشير للاتجاه الخطأ
أي أيقونة تحمل معنى اتجاهياً يجب أن تنعكس مع النص: أسهم الرجوع والتقدم، أسهم التصفح بين الصفحات، أزرار "التالي" في نماذج التسجيل، وحركات القوائم والسلايدر المنزلقة. سهم رجوع ما زال يشير لليسار في واجهة عربية يُخبر القارئ بالاتجاه الخطأ. لكن ليس كل شيء يجب أن ينعكس — الأيقونات التي تمثل أشياء لها اتجاه ثابت في الواقع (ساعة، كاميرا، زر تشغيل، معظم الشعارات) يجب أن تبقى كما هي؛ عكسها يبدو كخطأ لا كتصحيح. ضبط هذا الفارق يتطلب مراجعة متعمدة لكل أيقونة وحركة انتقال في المنتج، لا مجرد قلب عام على مستوى الـCSS.
- ما يجب أن ينعكس: أسهم الرجوع/التقدم، مسار التنقل، أشرطة التقدم، حركات القوائم والسلايدر، ذيل فقاعة الدردشة.
- ما لا يجب أن ينعكس: الساعات، الكاميرات، أزرار التشغيل/الإيقاف، معظم الشعارات التجارية، أيقونات الأشياء الواقعية.
الأرقام والتواريخ والنصوص ثنائية الاتجاه
عادة ما تُعرض الأرقام في النصوص العربية من اليسار إلى اليمين حتى داخل جملة تُقرأ من اليمين لليسار، وهذا يعني أن رقم هاتف أو سعراً أو تاريخاً مدمجاً داخل فقرة يمكن أن يتشوّش بصرياً إن لم يُخبَر المتصفح كيف يعزله عن الاتجاه المحيط به. كذلك يجب أن تتبع التواريخ ترتيب القراءة وقواعد الصياغة الخاصة باللغة، لا أن يُكتفى بعكس أرقامها فقط. وأي محتوى يخلط بين نصين مختلفي الاتجاه — اسم علامة تجارية إنجليزية داخل جملة عربية، عنوان بريد إلكتروني، رمز منتج — يحتاج إلى معالجة اتجاه صريحة (عزل ثنائي الاتجاه بمعايير يونيكود أو خاصية unicode-bidi في CSS)، وإلا انتهى الأمر بعلامات الترقيم والأرقام في ترتيب خاطئ على الشاشة رغم أن النص الأصلي صحيح.
الخط: لماذا لا يصلح كل خط للعربية
استخدام نفس الخط اللاتيني بوزن "متوافق" هو الاختصار الأكثر شيوعاً، وهو غالباً الخطأ الأكثر وضوحاً بصرياً. العربية خط متصل وسياقي — يتغير شكل كل حرف حسب موقعه داخل الكلمة — ومعظم الخطوط المصمَّمة أساساً للاتينية إما لا تدعم العربية إطلاقاً أو تعرضها بتباعد ضيق، ودعم ضعيف للتشكيل، ووزن لا يتناسب بصرياً مع الحرف اللاتيني المجاور له. حتى اختيار خط عربي عشوائي لا يكفي؛ الفارق يظهر في التفاصيل: تباعد الأسطر الطبيعي للعربية مختلف، وارتفاع الحروف وسماكتها يجب أن يتوازنا مع النص الإنجليزي المرافق. اختيار خطوط مصمَّمة فعلياً للعربية — بدعم OpenType حقيقي وأوزان متعددة متوازنة — يغيّر إحساس الصفحة أكثر من أي تعديل في التخطيط.
الحل الذي يصمد: خصائص CSS منطقية بدل اليمين واليسار الثابتين
الحل الدائم ليس ملف تنسيق RTL موازياً يُصان يدوياً — هذا النهج يتعطل في اللحظة التي يُطلق فيها مكوّن جديد وينسى أحدهم عكسه. الحل هو كتابة التخطيط بخصائص CSS منطقية من البداية: margin-inline-start بدل margin-left، وpadding-inline-end بدل padding-right، وtext-align: start بدل text-align: left. بهذه الطريقة يعكس المتصفح التخطيط تلقائياً بمجرد ضبط dir="rtl" على الصفحة، ويرث كل مكوّن جديد السلوك الصحيح افتراضياً دون الحاجة إلى مراجعة يدوية لكل جزء.
عادة واحدة توفر عليك كثيراً
امنع استخدام left/right الثابتة في أي CSS جديد، وفرض خصائص منطقية في مراجعة الكود. هذا لا يكلّف شيئاً في منتج يعمل باللغة الإنجليزية فقط، ويوفر عليك إعادة بناء كاملة في اليوم الذي تضيف فيه العربية أو العبرية.
لماذا يهم هذا تجارياً في سوق ثنائي أو ثلاثي اللغة
في سوق يقرأ فيه جمهورك العربية أو العبرية إلى جانب الإنجليزية، يلاحظ الناس خلال ثوانٍ إن كان الموقع مبنياً من أجلهم أم مجرد مُترجم إليهم. أيقونة معكوسة بشكل خاطئ، تاريخ مشوّش، أو خط يبدو مضغوطاً وغريباً، كل ذلك يُقرأ كعدم احترافية — حتى لدى مستخدمين ثنائيي اللغة يمكنهم ببساطة التبديل إلى الإنجليزية بدلاً من ذلك. في التجارة الإلكترونية ينعكس هذا مباشرة على معدل إتمام الشراء؛ وفي أعمال B2B ينعكس على مدى جدية العميل المحتمل تجاه منتجك. دعم RTL الحقيقي ليس رفاهية في إمكانية الوصول — إنه إشارة واضحة على مقدار استثمار الشركة الفعلي في خدمة ذلك السوق، ومعظم المنافسين لم يفعلوا ذلك بالشكل الصحيح بعد.
أسئلة شائعة
هل تصميم RTL هو مجرد قلب التخطيط؟
لا. اتجاه النص هو الجزء الظاهر فقط. RTL الحقيقي يشمل أيضاً اتجاه الأيقونات، اتجاه الحركات، تنسيق الأرقام والتواريخ، واختيار الخط. قلب التخطيط وحده دون هذه التعديلات ما زال يبدو مكسوراً لقارئ عربي أصلي.
هل تحتاج العربية والعبرية نفس المعاملة في RTL؟
كلتاهما تُقرآن من اليمين لليسار، لكنهما نصان مختلفان باحتياجات طباعية مختلفة — العربية خط متصل وسياقي يحتاج خطوطاً مخصصة له وتباعداً خاصاً، بينما العبرية خط منفصل الحروف له قياسات مختلفة تماماً. الموقع الذي يخدم الجمهورين يحتاج اختباراً منفصلاً لكل منهما، لا "وضع RTL" واحد يناسب الاثنين.
ما أكبر خطأ ترتكبه الشركات في RTL؟
كتابة left/right بشكل ثابت في CSS بدل الخصائص المنطقية. الأمر يعمل في النسخة الأولى، ثم يتعطل بصمت في كل مرة يُطلق فيها مكوّن أو صفحة جديدة دون أن يتذكر أحد عكسها يدوياً.
كيف أعرف إن كان موقعي جاهزاً فعلاً لـRTL؟
بدّل الموقع إلى العربية أو العبرية وتحقق من خمسة أمور: هل تشير الأيقونات والأسهم للاتجاه الصحيح، هل تُقرأ الأرقام والتواريخ بشكل سليم داخل الجملة، هل ينعكس التخطيط بشكل متسق في كل الصفحات لا الرئيسية فقط، هل الخط واضح ويبدو طبيعياً، وهل يفيض أو يُقطَع أي نص عندما يختلف طوله المتوسط عن الإنجليزية.