أخطاء RTL التي تخفيها اللقطات: اختبار CSS Logical Properties و DOM بالعربية

لماذا لا تكفي لقطة شاشة عربية جميلة؟

قد تبدو الصفحة العربية سليمة في لقطة شاشة واحدة، بينما يفشل ترتيب التنقل بلوحة المفاتيح، أو تظهر رسالة خطأ خارج حقل الإدخال، أو يتبدل موضع زر الإغلاق عند تكبير الخط. والسبب أن الترجمة وحدها لا تغير منطق الواجهة. هذا الدليل ليس قائمة عامة لفحص اتجاه RTL، بل خطة اختبار للمكونات التي تستخدم خصائص CSS الفيزيائية مثل left و right، ولمواضع DOM وترتيب القراءة، وللنص المختلط بالعربية والإنجليزية. سنبني حالات قابلة للتشغيل الآلي تكشف الانحرافات الوظيفية التي لا ترصدها مقارنة الصور وحدها.

فرق مهم بين اللغة والاتجاه وترتيب DOM

تحدد lang لغة المحتوى، بينما تحدد dir الاتجاه الأساسي لعرض النص، ولا يعني ضبط lang=ar تلقائيًا أن الاتجاه صار RTL. أما DOM فيمثل ترتيب العناصر المنطقي الذي قد يتبعه قارئ الشاشة وتسلسل التركيز. إذا عكست صفًا بصريًا عبر flex-direction: row-reverse فقد يبدو صحيحًا، لكن ترتيب القراءة أو التركيز لا يتغير بالضرورة بالطريقة المتوقعة. اختبر كل طبقة على حدة: قيمة lang، و dir، والترتيب المنطقي للعناصر، والتموضع المرئي. لا تعالج خللًا في ترتيب DOM بتبديل لون أو هامش، لأن ذلك يترك المشكلة الأصلية للمستخدمين الذين لا يعتمدون على الرؤية.

CSS الفيزيائي مصدر أخطاء متكررة

عندما تستخدم margin-left أو padding-right أو border-left في مكون عالمي، فإنك تربط المسافة بجهة مادية من الشاشة. عند الانتقال إلى RTL قد يصبح المقصود هو بداية السطر لا اليسار. توفر CSS Logical Properties بدائل مثل margin-inline-start و padding-inline-end و border-inline-start، إضافة إلى inset-inline-start و inline-size. لا تستبدل كل left بصورة آلية؛ فبعض المواقع مثل أزرار التحكم في مشغل فيديو أو مخطط جغرافي لها اتجاه فيزيائي مقصود. صنف كل خاصية بحسب وظيفتها قبل التعديل، واختبرها في اللغتين ضمن المكون نفسه.

مصفوفة اتجاهات للمكونات القابلة لإعادة الاستخدام

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

النص المختلط يحتاج عزلًا لا قلبًا كاملًا

في جملة عربية تتضمن بريدًا إلكترونيًا أو رقم طلب أو رابطًا، قد يعيد خوارزم الاتجاه الثنائي ترتيب الرموز بصريًا بطريقة مربكة. استخدم bdi لعزل محتوى مجهول الاتجاه، و dir=auto عندما يكون اتجاه النص يعتمد على المدخلات، و bdo فقط عند الحاجة إلى فرض اتجاه صريح. لا تضع direction:ltr على الصفحة كلها لإصلاح بريد واحد. اختبر أسماء مستخدمين عربية وإنجليزية، وأرقامًا تحتوي شرطات، وتواريخ، وروابط URL، ورموز عملات. راجع النتيجة بعين القارئ وبقارئ الشاشة، لأن صحة الشكل البصري لا تعني أن ترتيب النطق أو النسخ صحيح.

ترتيب التركيز أهم من ترتيب البطاقات

اختبر الانتقال بزر Tab من أول عنصر تفاعلي إلى آخره، ثم Shift+Tab للعودة. قارن التسلسل بما يتوقعه المستخدم من المعنى المنطقي للواجهة، لا بمجرد الإحداثيات على الشاشة. إذا استخدمت CSS order لإعادة ترتيب بطاقات، فقد يختلف ترتيب التركيز عن العرض؛ أعد تصميم DOM عند الضرورة بدل إضافة tabindex موجب عشوائي. افحص ظهور إطار التركيز وعدم اختفائه خلف طبقة ثابتة. وفي النوافذ المنبثقة تأكد من انتقال التركيز إليها ثم عودته إلى العنصر الذي فتحها. هذه اختبارات وظيفية لا تكشفها لقطة شاشة ثابتة.

أيقونات الاتجاه ليست جميعها قابلة للقلب

سهم الانتقال إلى الصفحة التالية في واجهة عربية قد يحتاج اتجاهًا معاكسًا، لكن رمز التشغيل Play أو شعار علامة تجارية لا ينبغي قلبه لمجرد تغيير اتجاه الصفحة. ضع سياسة للأيقونات الدلالية مقابل الرموز ذات الشكل الثابت. اختبر أيقونة الرجوع، واتجاه المسار Breadcrumb، وأزرار التنقل بين الصفحات، ومؤشر التقدم، وسهم توسيع القائمة. تجنب تطبيق transform: scaleX(-1) على حاوية كاملة؛ فقد يقلب النص والصور والرموز التي لا ينبغي قلبها. الأفضل اختيار اتجاه الأيقونة بحسب معناها وتوثيق سلوكها في مكتبة المكونات.

DOM والرسائل الديناميكية

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

كيف تبني اختبارًا آليًا غير هش؟

استخدم محددات مستقرة مرتبطة بدور العنصر أو اسم وصوله بدل الإحداثيات الثابتة. اختبر وجود dir الصحيح و Computed Style للخصائص المنطقية عندما تكون ذات صلة، ثم نفذ مسار Tab وتحقق من العنصر النشط. لا تجعل الاختبار ينجح فقط لأن الزر موجود؛ اضغطه وتحقق من الأثر النهائي. في المقارنة البصرية ثبّت الخطوط والبيانات والعرض قبل التقاط الصورة، واسمح باختلافات طفيفة في تنعيم الخط دون تجاهل انقلاب مكون كامل. سجل نسخة المتصفح والخط ونظام التشغيل، لأن اختلافات الرسم قد تؤثر على النتيجة.

التجربة اليدوية تكمل الاختبار الآلي

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

جدول أسباب شائعة وتصحيحها

عندما تظهر مسافة على الجهة الخاطئة، افحص استخدام margin-left مقابل margin-inline-start. وعندما يتغير شكل ترتيب البطاقات لكن يبقى Tab غير منطقي، افحص DOM و CSS order. وعندما ينقلب رمز لا ينبغي قلبه، افحص transform على الحاوية. وعندما تتبدل علامات الترقيم قرب رابط، افحص dir و bdi. لا تفترض أن أي عرض له سبب وحيد؛ قد تتداخل مكتبة مكونات مع CSS مخصص أو إعدادات نظام. ابدأ بتجربة صغيرة معزولة ثم أعد دمج الإصلاح واختبر الصفحة كاملة في الاتجاهين.

قائمة قبول للمكون العربي

اكتب معيار قبول يتضمن: lang و dir صحيحين، وخصائص منطقية حيث يناسبها الاستخدام، وترتيب DOM متوافقًا مع المعنى، ومسار تركيز مفهومًا، ونصوصًا مختلطة معزولة، وأيقونات غير مقلوبة خطأ، ورسائل ديناميكية قابلة للوصول. نفذ الاختبار عند 320 و 768 و 1440 بكسل بوصفها أمثلة لأحجام شاشات، لا حدودًا إلزامية لكل منتج. اختبر إعادة تحميل الصفحة وتغيير اللغة داخل الجلسة، ثم راجع أي تعارض بين إعداد المستخدم واتجاه المكون. لا تعتمد المكون قبل توثيق الاستثناءات التي بقيت ولماذا.

أين تضيف هذه الاختبارات إلى خط التطوير؟

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

المراجع والقراءة المرتبطة

تشرح MDN خصائص CSS المنطقية: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Logical_properties_and_values ، وتشرح خاصية dir: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/dir . وللاختبارات العامة للواجهات العربية على إيجي تاج راجع: https://egytag.com/ar/articles/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D9%88%D8%A7%D8%AC%D9%87%D8%A7%D8%AA-rtl-%D8%A7%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9-%D8%A3%D8%AE%D8%B7%D8%A7%D8%A1-%D9%84%D8%A7-%D8%AA%D9%83%D8%B4%D9%81%D9%87%D8%A7-%D8%A7%D9%84%D8%AA%D8%B1%D8%AC%D9%85%D8%A9-%D9%88%D8%AD%D8%AF%D9%87%D8%A7 . هذه المراجع تشرح السلوك المتوقع؛ تحقق من توافق إصدار المتصفح ومكتبة الواجهة في مشروعك قبل اعتماد أي إصلاح.