الاختبار البصري ولغات RTL: الطريقة الوحيدة الموثوقة للتحقق من عرض العربية والعبرية
يتكون الاختبار البصري للغات RTL من التقاط لقطات شاشة آلية لكل صفحة ولكل مكوّن من مكوّنات الواجهة في وضع العرض من اليمين إلى اليسار، ثم مقارنة هذه اللقطات الملتقطة بخط أساس معتمَد ومُراجَع بهدف اكتشاف أي شذوذ أو خلل في الانعكاس أو الاتجاه أو التموضع أو ثنائية الاتجاه — وهي أنواع من المشاكل لا تستطيع الاختبارات الوظيفية التقليدية ولا مُحققات HTML اكتشافها أو تحديدها.
موقعك يعمل بشكل مثالي ومثالي باللغة الفرنسية. وباللغة الإنجليزية أيضاً. تُضيف دعم اللغة العربية أو اللغة العبرية، تفعّل الخاصية dir="rtl" في ملف HTML الخاص بك، وفجأة وعلى نحو مفاجئ تماماً تتحول واجهتك بأكملها إلى أحجية مكسورة ومُربكة. القائمة الرئيسية في المكان الخاطئ. أيقونات الأسهم تشير في الاتجاه المعاكس. الأرقام المضمنة في النصوص تختلط بالحروف بشكل فوضوي. فقرة كاملة بأكملها تعرض أسطرها بترتيب لا يحمل أي معنى منطقي أو لغوي.
هذا ليس خللاً نادراً أو غريباً بأي حال. إنه الواقع اليومي والمتكرر لتدويل الواجهات نحو لغات RTL. وهو مشكلة لا يحلّها بشكل موثوق سوى الاختبار البصري وحده.
لماذا يُعدّ RTL تحدياً مختلفاً جوهرياً
عندما تترجم موقعك من اللغة الفرنسية إلى اللغة الإنجليزية، فإن التحدي يبقى لغوياً بحتاً. الكلمات تتغير، والجمل قد تطول أو تقصر، لكن التخطيط البصري يبقى متطابقاً ومتماثلاً. النص يتدفق بشكل طبيعي من اليسار إلى اليمين. القائمة الرئيسية موجودة على الجانب الأيسر. زر الإجراء الرئيسي موجود على الجانب الأيمن. كل شيء يبقى في مكانه المعتاد والطبيعي.
أما عندما تنتقل إلى لغات RTL — مثل العربية، والعبرية، والفارسية، والأردية — فإن كل شيء ينعكس بشكل كامل. القائمة الرئيسية تنتقل من الجانب الأيسر إلى الجانب الأيمن، والأشرطة الجانبية تنقلب مواقعها، والأيقونات ذات الدلالة الاتجاهية يجب أن تشير في الاتجاه المعاكس، والهوامش غير المتماثلة تنعكس أوضاعها. إنه انعكاس شامل وكامل، ويجب أن يكون مثالياً ودقيقاً في كل تفاصيله.
وفقاً لقاعدة بيانات Ethnologue، يستخدم أكثر من 750 مليون شخص لغات RTL يومياً في حياتهم الرقمية. هذا ليس سوقاً متخصصاً أو ثانوياً بأي حال. إنها قارة بأكملها من المستخدمين تُقدِّم لهم خدمة سيئة وغير مقبولة إذا كان نظام RTL لديك معطوباً أو غير مكتمل.
الفئات الخمس لأخطاء RTL التي لا يختبرها أحد
1. الانعكاس غير الكامل للتخطيط
أكثر أخطاء RTL شيوعاً وانتشاراً هو الانعكاس الجزئي غير المكتمل. جزء من الصفحة يكون منعكساً بشكل صحيح، بينما جزء آخر يبقى كما هو دون تغيير. الترويسة مثلاً تكون بوضع RTL، لكن التذييل يبقى عالقاً في وضع LTR. الشريط الجانبي انتقل فعلاً إلى الجانب الأيمن، لكن المحتوى الداخلي داخله لا يزال محاذاً إلى الجانب الأيسر.
يحدث هذا الانعكاس غير الكامل عندما تستخدم أنماط CSS الخصائص الاتجاهية الفيزيائية المباشرة مثل left وright وmargin-left وpadding-right بدلاً من الخصائص المنطقية المناسبة مثل inset-inline-start وmargin-inline-end. الخصائص الفيزيائية لا تستجيب ولا تتفاعل مع تغيير اتجاه الوثيقة. تبقى ثابتة ومطلقة بصرف النظر عن اتجاه القراءة المعتمد.
الاختبار الوظيفي لن يكتشف هذه المشكلة أبداً. العنصر موجود فعلاً في شجرة DOM، وهو قابل للنقر، ويحتوي على النص الصحيح. لكنه موجود في المكان الخاطئ بصرياً. اختبار بصري وحده يقارن العرض الفعلي لـ RTL بخط أساس RTL معتمَد يمكنه رصد هذا الخلل وتحديده.
2. أيقونات لا تنقلب أو تنقلب بالخطأ
ليست كل الأيقونات يجب أن تُقلب عند الانتقال إلى وضع RTL. وهذا بالضبط ما يجعل المشكلة أكثر تعقيداً وأصعب في التحكم.
الأيقونات ذات الدلالة الاتجاهية يجب أن تنقلب بالتأكيد: أسهم التنقل بين الصفحات، وشيفرونات الرجوع، وأيقونات التشغيل والتقديم. إذا كان السهم يشير إلى اليمين ليعني "التالي" في وضع LTR، فيجب أن يشير إلى اليسار ليعني نفس الشيء في وضع RTL.
الأيقونات غير الاتجاهية يجب ألا تنقلب إطلاقاً: علامة الصح، وسلة المهملات، ورمز القلب، ورمز الترس أو الإعدادات. هذه الأيقونات لا تحمل أي معنى اتجاهي. قلبها سيكون خطأً واضحاً ومُشتِّتاً للمستخدم.
الأيقونات ذات الدلالة الغامضة تتطلب حكماً دقيقاً: أيقونة قلم الرصاص (معظم الناس يكتبون بيدهم اليمنى، لكن الأيقونة في النهاية رمزية بحتة)، وعدسة المكبّرة (هل اتجاه المقبض يحمل دلالة اتجاهية؟)، وأيقونة الهاتف (هل توجّه سماعة الهاتف له معنى اتجاهي محدد؟).
تنشر Google دليلاً مفصلاً ضمن إرشادات Material Design يوضح بالتفصيل قواعد قلب أيقونات RTL. القائمة طويلة والاستثناءات المذكورة فيها عديدة ومتعددة. أتمتة التحقق من صحة تطبيق هذه القواعد بالاختبارات الوظيفية أمر ممكن نظرياً لكنه غير قابل للتطبيق عملياً على الإطلاق. الاختبار البصري يجعل عملية التحقق هذه بسيطة وسريعة: إذا كانت أيقونة ما منقلبة بينما لا ينبغي أن تكون كذلك (أو العكس تماماً)، تُظهر المقارنة البصرية ذلك فوراً وبشكل واضح.
3. النص ثنائي الاتجاه (Bidi) يخرج عن السيطرة تماماً
الكابوس الحقيقي والأكثر إزعاجاً للغات RTL ليس انعكاس التخطيط البصري. إنه التعامل مع النص ثنائي الاتجاه.
في اللغة العربية أو العبرية، يسير النص الرئيسي من اليمين إلى اليسار. لكن الأرقام، وعناوين البريد الإلكتروني، وعناوين URL، وأسماء العلامات التجارية المكتوبة بالحروف اللاتينية — كل هذه العناصر تسير من اليسار إلى اليمين، حتى عندما تكون مُضمَّنة في وسط نص RTL. يُسمَّى هذا النوع من النصوص "النص ثنائي الاتجاه"، أو اختصاراً "bidi".
تتعامل خوارزمية Unicode ثنائية الاتجاه (UBA) مع معظم الحالات تلقائياً وبشكل صحيح. لكن "معظم" لا تعني "كل". عندما يكون مقطع نصي LTR مجاوراً لمقطع RTL دون سياق كافٍ لتحديد الاتجاه، يمكن للخوارزمية أن تتخذ القرار الخاطئ. النتيجة: كلمات تظهر بترتيب معكوس، وأقواس تُعرض بشكل مقلوب، وأرقام هاتف تصبح غير قابلة للقراءة.
النتيجة الملموسة على الشاشة: قوس إغلاق ينتهي قبل قوس الفتح، ورقم هاتف يتحول إلى تسلسل أرقام لا معنى له. هذا النوع من الأخطاء يظل غير مرئي تماماً للاختبارات الوظيفية — النص موجود فعلاً، والحروف صحيحة إملائياً، لكن الترتيب البصري خاطئ تماماً. الاختبار البصري وحده يمكنه اكتشاف هذه المشكلة على نطاق واسع وشامل.
4. النماذج والنماذج المنعكسة
تُعدّ النماذج إشكالية بشكل خاص في بيئة RTL. تسميات الحقول يجب أن تكون موضعّة على الجانب الأيمن من الحقل. رسائل الخطأ والتنبيهات يجب أن تظهر على الجانب الأيمن. الأيقونات الموجودة داخل الحقول (مثل عدسة المكبّرة في حقل البحث، أو أيقونة العين في حقل كلمة المرور) يجب أن تُعاد تموضعها وفق الاتجاه الجديد.
لكن سلوك إدخال النص يبقى بوضع LTR لأنواع معينة من الحقول. حقل البريد الإلكتروني يجب أن يبقى بوضع LTR حتى عندما يكون داخل نموذج RTL كامل، لأن عناوين البريد الإلكتروني تُكتب دائماً بالاتجاه LTR. حقل رقم الهاتف قد يكون LTR أو RTL حسب الصيغة المُتَّبعة في الدولة المستهدفة. حقل النص الحر يجب أن يتكيّف تلقائياً مع لغة النص الذي يكتبه المستخدم.
التركيبة بين نموذج RTL بالكامل مع حقول فردية تبقى بوضع LTR تخلق مواقف معقدة بصرياً. مؤشر الكتابة يقفز بشكل غير متوقع من اتجاه لآخر. النص النائب (placeholder) قد يكون مكتوباً بالعربية (RTL) بينما الإدخال الفعلي سيكون بالحروف اللاتينية (LTR). رسائل التحقق المضمنة يجب أن تظهر على الجانب الصحيح من الحقل الصحيح دون أي التباس.
اختبار كل ذلك من الناحية الوظيفية يعني التحقق من أن كل حقل يقبل إدخال البيانات وأن عملية الإرسال تعمل بشكل صحيح. اختبار كل ذلك من الناحية البصرية يعني التحقق من أن المستخدم يفهم ما يراه فعلاً أمام عينيه. الفرق بين النهجين هائل وجوهري.
5. المكونات التفاعلية المُربكة والمُشتتة
المكونات التفاعلية — مثل القوائم المنسدلة، والتلميحات المنبثقة، والنوافذ المنبثقة (modals)، وعروض carousels — تمتلك معنى اتجاهياً ضمنياً. القائمة المنسدلة تتموضع على الجانب الأيسر في وضع LTR، لكن يجب أن تتموضع على الجانب الأيمن في وضع RTL. الـ carousel يتقدم نحو اليمين في وضع LTR، لكن يجب أن يتقدم نحو اليسار في وضع RTL.
حتى عندما تتعامل المكتبات الحديثة مثل Radix UI وHeadless UI مع هذه الحالات بشكل صحيح، فإن تخصيصات CSS التي يُجريها فريق التطوير الخاص بك يمكن أن تُلغي سلوك RTL الصحيح. اختبار بصري يلتقط هذه المكونات في حالتها المفتوحة ويتحقق من أن عرضها في وضع RTL مطابق وصحيح.
لماذا تفشل الاختبارات الموجودة على RTL
اختبارات الوحدة لا ترى العرض البصري
اختبار الوحدة يتحقق من أن المكوّن يستقبل الخصائص (props) الصحيحة ويعيد ترميز HTML (markup) الصحيح. لا يعرف ولا يمكنه أن يدرك أن margin-left: 16px يجب أن تصبح margin-right: 16px في وضع RTL. لا يعرف أن ملف SVG الخاص بأيقونة السهم يجب أن يُقلب. لا يعرف أن النص ثنائي الاتجاه يُعرض بالترتيب الخاطئ على الشاشة.
الاختبارات الوظيفية لا ترى الاتجاه البصري
اختبار Cypress الذي ينقر على زر "التالي" ويتحقق من التنقل إلى الصفحة التالية سيمر بنجاح في وضع RTL. الزر يعمل وظيفياً. التنقل يعمل كما هو متوقع. لكن حقيقة أن الزر موجود بصرياً في المكان الخاطئ، وأن أيقونة السهم تشير في الاتجاه المعاكس، وأن التسمية النصية مقطوعة لأن النص العربي أطول من النص الفرنسي — كل هذه الحقائق تفلت تماماً من الاختبار الوظيفي.
مُحققات CSS لا تتحقق من المنطق الاتجاهي
تتوفر مُحققات CSS تحذرك عند استخدام خصائص فيزيائية مثل margin-left بدلاً من الخصائص المنطقية مثل margin-inline-start. هذا مفيد بالتأكيد. لكنه غير كامل. المُحقق لا يعرف ما إذا كان استخدامك لـ margin-left مقصوداً ومتعمداً (لحالة محددة لا ينبغي أن تتغير عند التبديل إلى RTL) أم أنه ناتج عن خطأ أو إهمال. كما أنه لا يتحقق من العرض النهائي الفعلي على الشاشة — بل يتحقق فقط من الصياغة النحوية للكود.
الاختبار البصري وحده يتحقق من النتيجة النهائية
الاختبار البصري لا يهتم ولا يكترث بكيفية تنفيذ نظام RTL في كودك. ينظر مباشرة إلى النتيجة النهائية: الصفحة كما يراها المستخدم الفعلي. انعكاس غير مكتمل، أيقونة مقلوبة بشكل خاطئ، نص bidi بترتيب معكوس، نموذج غير متسق — كل شيء يظهر بشكل واضح في تقرير الفرق البصري. هذه الشمولية هي ما يجعل الاختبار البصري الأداة التي لا غنى عنها لأي استراتيجية تدويل جادة تجاه لغات RTL.
إعداد اختبار بصري لـ RTL بأداة بدون كود
إعداد اختبار بصري شامل للغات RTL لا يتطلب أي خبرة تقنية متخصصة في ثنائية الاتجاه أو في معايير Unicode. مع أداة بدون كود مثل Delta-QA، العملية بسيطة ومباشرة.
إنشاء خطوط أساس RTL معتمَدة ومُراجَعة
الخطوة الأولى هي إنشاء خطوط أساس مرجعية لجميع صفحاتك في وضع RTL. تصفّح موقعك باستخدام معامل اللغة العربية أو العبرية، والتقط لقطات شاشة لكل صفحة رئيسية ومكوّن حرج. اعرض هذه اللقطات على متحدث أصلي باللغة المستهدفة أو على مصمم مطلع على أعراف وتقاليد RTL لاعتمادها والموافقة عليها. بمجرد اعتمادها، تصبح هذه اللقطات خط الأساس المرجعي لجميع المقارنات المستقبلية.
قارن بعد كل تغيير ومع كل عملية نشر
مع كل عملية نشر جديدة، أعد تشغيل عملية التقاط RTL وقارن النتائج بخط الأساس المعتمد. أي تعديل على ملفات CSS، أو المكونات، أو تبعيات الواجهة الأمامية يمكن أن يؤثر على عرض RTL حتى لو بدا التغيير في الظاهر أنه يخص فقط النسخة LTR من الموقع.
هذه نقطة حاسمة يجب فهمها جيداً: تغيير بسيط في CSS يخص فقط النسخة الفرنسية من موقعك يمكن أن يُكسر النسخة العربية بشكل كامل. خاصية margin-left مضافة لإجراء تعديل تجميلي طفيف في وضع LTR ستُزيح العنصر المقابل عن موضعه الصحيح في وضع RTL. الاختبار البصري في كلا الاتجاهين معاً هو الطريقة الوحيدة لضمان أن تغييراتك محايدة اتجاهياً ولا تُلحق ضرراً بأي نسخة لغوية.
اختبر نقاط التوقف الحرجة والأساسية
أخطاء RTL غالباً ما تكون خاصة بنقاط توقف معينة وحسب. تخطيط ينعكس بشكل صحيح على شاشات سطح المكتب يمكن أن يكون مكسوراً تماماً على الأجهزة الجوّالة، لأن استعلامات الوسائط (media queries) تستخدم خصائص فيزيائية مختلفة أو لأن تخطيط الجوّال مبني بمنطق مستقل ومتميز.
التقط صفحات RTL على ثلاث نقاط توقف على الأقل: الجوّال بعرض 375px، والجهاز اللوحي بعرض 768px، وسطح المكتب بعرض 1440px. الأخطاء الأكثر تكراراً وخطورة تظهر على الأجهزة الجوّالة، حيث المساحة المحدودة تُضخِّم المشاكل الاتجاهية وتجعلها أكثر وضوحاً.
تكلفة تجاهل RTL وتأثيرها الفعلي
تجاهل جودة نظام RTL في واجهتك له عواقب حقيقية وقابلة للقياس.
أولاً، معدل الارتداد المرتفع. واجهة RTL سيئة العرض يمكن تحديدها فوراً من قِبَل أي متحدث أصلي باللغة المستهدفة. ليست مشكلة دقيقة أو خفية — إنها تشبه محاولة قراءة كتاب صفحاته بترتيب خاطئ تماماً. المستخدم لن يحاول فهم المشكلة أو التكيف معها. سيغادر فوراً إلى منافس آخر.
ثانياً، فقدان المصداقية. إذا كنت تستهدف سوق الشرق الأوسط أو شمال أفريقيا (منطقة يزيد عدد سكانها عن 400 مليون نسمة مع سوق تجارة إلكترونية سريع النمو وفقاً لتقارير Statista)، فإن واجهة RTL مكسورة تشير بوضوح إلى عدم الاحترام لجمهورك المستهدف. إنها تُعادل تلقّي رسالة بريد إلكتروني عمل باللغة الفرنسية مليئة بالأخطاء الإملائية في كل جملة: مفهومة تقنياً ربما، لكنها مُسقِطة ومُرفوضة عملياً.
ثالثاً، المخاطر التنظيمية والتعاقدية. بعض الأسواق (مثل إسرائيل، والإمارات العربية المتحدة، والمملكة العربية السعودية) تفرض توقعات تنظيمية أو تعاقدية محددة بشأن جودة الواجهات الرقمية باللغة المحلية. واجهة RTL فاشلة أو غير مكتملة يمكن أن تُشكّل عائقاً حقيقياً أمام دخول هذه الأسواق أو استمرار العمل فيها.
لغات RTL ليست كلها متشابهة
نقطة مهمة يغفل عنها كثير من فرق التطوير: اللغة العربية واللغة العبرية لا تطرحان التحديات البصرية نفسها بالضبط.
اللغة العربية تستخدم حروفاً متصلة (نظام الكتابة المتصلة أو cursive). عرض الكلمة الواحدة يتغير بشكل ديناميكي حسب الحروف المجاورة لها. التشكيل (الحركات أو harakat) يضيف علامات إضافية فوق وتحت الحروف، مما يؤثر مباشرة على ارتفاع السطر وتباعد الأسطر. خطوط العربية عموماً تتطلب حجماً أساسياً أكبر من الخطوط اللاتينية لتبقى مقروءة ومريحة بصرياً.
اللغة العبرية تستخدم حروفاً منفصلة (غير متصلة). مشاكل العرض المتعلقة بعرض الكلمات أقل وضوحاً، لكن العلامات الصوتية (niqqud) تطرح تحديات مشابهة لتشكيل الحروف في اللغة العربية.
اللغة الفارسية تستخدم الأبجدية العربية مع إضافة حروف إضافية غير موجودة في العربية وأرقام مختلفة تماماً. الصفحة الواحدة قد تحتاج إلى التعامل مع ثلاثة أنظمة أرقام مختلفة في آن واحد.
الاختبار البصري يتعامل مع هذا التنوع اللغوي بشكل طبيعي ومباشر — لأنه يقارن البكسلات النهائية على الشاشة. سواء كانت حروفك متصلة أو منفصلة، مع تشكيل أو بدونه، الاختبار البصري يرى ويدرك ما يراه المستخدم الفعلي.
لماذا يجب أن يكون اختبار RTL البصري ضمن خط أنابيب CI/CD لديك
نظام RTL ليس مشروعاً يُنجَز مرة واحدة. لا يمكنك "تنفيذ RTL" ثم نسيان الأمر والمضي قدماً. كل تعديل تُدخله على واجهتك يجب التحقق منه في وضع RTL، لأن كل تعديل مهما كان صغيراً يمكن أن يُكسر نظام RTL بأكمله.
دمج اختبار RTL البصري ضمن خط أنابيب CI/CD يعني أن كل طلب سحب (pull request) يُتحقق منه تلقائياً وبشكل شامل في كلا الاتجاهين. المطور الذي يُضيف مكوّناً جديداً يعمل بوضع LTR يرى فوراً ما إذا كان مكوّنه يُعرض بشكل صحيح في وضع RTL أيضاً. المصمم الذي يُعدّل التباعد بين العناصر يرى فوراً ما إذا كان التعديل يعمل بشكل متسق في كلا الاتجاهين.
هذا هو النهج الوحيد القادر على التوسع بشكل مستدام. البديل — إجراء التحقق يدوياً من نظام RTL قبل كل إصدار — عملية بطيئة ومكلفة وعرضة للخطأ البشري بشكل كبير.
الأسئلة الشائعة
هل يجب اختبار RTL حتى لو كانت حركة الزيارات باللغة العربية منخفضة حالياً؟
نعم، خاصة إذا كنت تنوي تنمية وتطوير هذا السوق في المستقبل. نظام RTL المعطوب يُعيق النمو بشكل مباشر. المستخدمون العرب الذين يصلون إلى موقعك ويرون واجهة سيئة العرض لن يعودوا أبداً. لن تعرف أبداً كم من العملاء المحتملين فقدتهم لأنهم حكموا على منتجك بأنه غير احترافي خلال 3 ثوان فقط. اختبار RTL البصري هو استثمار في النمو المستقبلي، وليس مصروفاً لحركة الزيارات الحالية فقط.
هل يكتشف الاختبار البصري مشاكل النص ثنائي الاتجاه؟
نعم، وهذه إحدى أهم مزاياه الفريدة. مشاكل النص ثنائي الاتجاه — مثل الكلمات بترتيب خاطئ، والأقواس المقلوبة، والأرقام الموضوعة في غير محلها — جميعها مرئية وواضحة في لقطات الشاشة الملتقطة بالاختبار البصري. إذا ظهر مقطع نصي بترتيب غير صحيح، فإن المقارنة بكسل ببكسل مع خط الأساس المعتمد تُشير إليه تلقائياً وبشكل فوري.
هل يمكنك استخدام نفس خط الأساس للعربية والعبرية؟
لا، هذا خطأ شائع يجب تجنبه. اللغة العربية واللغة العبرية تتطلبان خطي أساس منفصلين ومستقلين. رغم أن كليهما لغات RTL، إلا أن الحروف، والطباعة، وأعراف التخطيط البصري، وأنظمة الأرقام تختلف بينهما بشكل كبير. خط أساس عربي لا يمكنه التحقق من صحة عرض العبرية، والعكس صحيح تماماً. أنشئ خط أساس منفصل لكل لغة مدعومة على حدة.
هل يعمل اختبار RTL البصري مع أطر CSS الحديثة؟
نعم، بدون أي مشكلة. سواء كنت تستخدم Tailwind CSS أو Bootstrap أو Material UI أو CSS مخصصاً، فإن الاختبار البصري يلتقط العرض النهائي على الشاشة بصرف النظر عن الإطار المستخدم. بل إن الاختبار البصري يصبح أكثر فائدة وقيمة عند استخدامه مع أطر CSS، لأن هذه الأطر تُضيف طبقة تجريد قد تخفي مشاكل اتجاهية موجودة في كود المصدر.
كم من الوقت يضيف اختبار RTL البصري إلى دورة النشر؟
مع أداة مثل Delta-QA، لا يستغرق التقاط RTL والمقارنة سوى بضع دقائق إضافية تُضاف إلى الدورة. هذا وقت ضئيل للغاية مقارنة بالوقت والجهد الذين ستقضيهما في تشخيص وإصلاح خلل RTL يُكتَشَف بعد الانتشار إلى بيئة الإنتاج. الاستثمار الزمني ضئيل، لكن الخطر المُتجنَّب كبير وكبير جداً.
هل يستبدل اختبار RTL البصري مراجعة التوطين التي يجريها متحدث أصلي؟
لا، ولا ينبغي له أن يحاول ذلك. مراجعة المتحدث الأصلي تركز على الجودة اللغوية — الترجمة، والنبرة المناسبة، والأعراف الثقافية. الاختبار البصري يركز على جودة العرض البصري — التخطيط، والاتجاه، والتموضع، وقابلية القراءة. كلا المراجعتين ضروريتان ولا غنى عن أي منهما. الاختبار البصري يكتشف الانحدارات بين الإصدارات المختلفة، بينما المتحدث الأصلي يعتمد ويُوثّق أن النسخة الأولية صحيحة ومتكاملة.
هل يدعم موقعك لغات RTL؟ تحقق من أن العرض البصري بنفس جودة الترجمة اللغوية.