الاختبار البصري للمواقع متعددة اللغات: اكتشاف انحدارات i18n التي لا يتحقق منها أحد
الاختبار البصري متعدد اللغات: عملية تحقّق آلية من السّلامة البصرية لموقع إلكتروني أو تطبيق عبر جميع نسخه اللغوية، تكتشف الانحدارات المرتبطة بالتدويل — تجاوزات النصوص، انكسارات تخطيطات RTL، مشكلات التباعد الطباعي، عمليات الاقتطاع، والتناقضات البصرية بين اللغات.
نُدير موقعًا متاحًا بـ 9 لغات. وهذا ليس ادّعاءً تسويقيًا مبالغًا فيه — بل هو واقع تشغيلي يوميّ نعيشه ونديره، علّمنا ما تكتشفه أغلب فرق التطوير متأخّرًا جدًّا: كل لغة تُكسر واجهتك بطريقتها الخاصة.
يُعدّ التدويل (i18n) مشكلةً تقنيةً موثّقةً جيّدًا على صعيد التطوير. فالأُطر الحديثة تتولّى ملفات الترجمة، والمسارات القائمة على اللغة، وتنسيقات التواريخ والأرقام على نحوٍ سليم. أمّا ما لم يُوثَّق جيّدًا — بل ويُختبر أقلّ من غيره — فهو الأثر البصري لكل لغة على التخطيط.
وفقًا لفريق عمل تدويل W3C، قد يتفاوت طول النص بين 50% و300% من لغةٍ إلى أخرى لنفس المحتوى. فزرّ يحمل عبارة "Submit" بالإنجليزية يُصبح "Absenden" بالألمانية و"Envoyer" بالفرنسية. الزرّ له نفس أنماط CSS، لكن النص ليس له نفس العرض. وهنا تبدأ المشاكل.
لماذا تُعدّ المواقع متعددة اللغات كابوسًا بصريًا
تُصمّم معظم فرق التطوير وتختبر واجهتها بلغة واحدة — عادةً الإنجليزية. فالتصميم يُتحقّق منه بالإنجليزية، والاختبارات الوظيفية تُنفَّذ بالإنجليزية، والعرض التوضيحي للعميل يتمّ بالإنجليزية. وعندما تصل الترجمات، تُحقن في الواجهة دون تحقّق بصريٍّ منهجي.
هذا أشبه ببناء منزل بأثاثٍ بأحجامٍ محدّدة دقيقة، ثم استبدال هذا الأثاث بقطعٍ ذات أحجام مختلفة تمامًا دون التحقّق من أنها ستمرّ عبر الأبواب أم لا — وهو ما يؤدي حتمًا إلى نتائج كارثية على مستوى التخطيط.
مشكلة طول النص
تُمثّل اللغة الألمانية كابوسَ مصمّمي الواجهات. فالكلمة الإنجليزية "settings" تصبح "Einstellungen" بالألمانية — أي أطول بـ 60%. و"User management" تصبح "Benutzerverwaltung"، و"Download now" تصبح "Jetzt herunterladen."
هذا ليس مجرّد شأنٍ نقدي. فوفقًا لبيانات W3C، يبلغ متوسّط توسّع النص من الإنجليزية إلى الألمانية 30% على مستوى الجمل، وقد يتجاوز 200% للكلمات المعزولة (مثل تسميات الأزرار وعناصر التنقّل). وتُظهر الفنلندية والهولندية واليونانية توسّعًا مماثلًا.
النتيجة الملموسة على أرض الواقع: أزرار ينثني نصّها إلى سطرين ويُكسر التخطيط بأكمله، وقوائم تنقّل تتداخل عناصرها بشكل فوضوي، وعناوين تُقتطع بعلامات الحذف بينما تظهر النسخة الإنجليزية كاملةً ومقروءة. وبطاقات منتجات بارتفاعات متفاوتة من لغة إلى أخرى، ممّا يُنشئ شبكات غير محاذاة.
مشكلة لغات RTL
تُكتب العربية والعبرية والفارسية والأردوية من اليمين إلى اليسار (RTL — Right To Left). وهذا ليس مجرّد نصٍّ معكوس — بل تخطيطٌ بأكمله يجب أن يُعكَس. فالقائمة الرئيسية على اليمين، وشريط البحث على اليسار، وقوائم النقاط تبدأ من اليمين، والأيقونات الاتجاهية (الأسهم، إشارات الشيفرون) يجب أن تُقلَب.
حقّق CSS تقدّمًا ملحوظًا بفضل الخصائص المنطقية (margin-inline-start بدلًا من margin-left، وpadding-inline-end بدلًا من padding-right). لكن في الممارسة العملية، لا تزال العديد من المواقع تستخدم خصائص فيزيائية لا تنعكس تلقائيًا في RTL. وحتى مع الخصائص المنطقية، تتطلّب بعض العناصر معالجةً خاصة — مثل الظلال المسقطة، والتدرّجات الاتجاهية، وأنصاف أقطار الحدود غير المتماثلة.
تشمل أعطال RTL النموذجية: نصًا يبدأ من الحافة الخاطئة لحاويته، وعناصر تتداخل بسبب هوامش في الاتجاه الخاطئ، وأيقونات اتجاهية تُشير عكسيًا، وتسميات نماذج وحقول غير محاذاة، ومحتوى مختلط (نصّ عربي مع مصطلحات تقنية إنجليزية) يُنتج نتائج عرضٍ غير متوقّعة.
مشكلة أنظمة الكتابة CJK
تُطرح اللغات الصينية واليابانية والكورية (CJK) تحدّياتٍ طباعية فريدة. فحروف CJK أحادية العرض (كل حرف يُشغل مربّعًا بعرضٍ متساوٍ)، ممّا يُنتج تباعدًا بصريًا مختلفًا عن النصّ اللاتيني. وقواعد كسر الأسطر مختلفة أيضًا — فالصينية يمكن أن يُكسر سطرها بين أي حرفين، بينما اليابانية تملك قواعد معقّدة تتعلّق بعلامات الترقيم في بدايات الأسطر ونهاياتها.
تكون عملية عرض خطوط CJK أكثر تعقيدًا. فملفات الخطوط أثقل بكثير (خطّ صيني كامل يغطّي آلاف الحروف)، ممّا قد يؤثّر على أوقات التحميل ويُنتج وميض نصٍّ غير مرئي (FOIT) أو وميض نصٍّ غير منسّق (FOUT) — وهو ما لا يحدث مع اللغات اللاتينية.
ومن الآثار الجانبية التي يُهملها الكثيرون: حروف CJK لها ارتفاع سطر مختلف طبيعيًا عن الحروف اللاتينية. فقيمة line-height: 1.5 قد تُنتج نصًا هوائيًا ومقروءًا بالإنجليزية، لكنها قد تبدو ضيّقةً جدًّا أو فضفاضةً جدًّا بالصينية. ويُمكن ضبط ارتفاع السطر خصيصًا لكل لغة، لكن ذلك نادرًا ما يحدث.
مشكلة أنظمة الكتابة المعقّدة
تستخدم التايلندية والهندية (ديفاناغاري) والبنغالية ولغات أخرى أنظمة كتابة معقّدة تتجمع فيها الحروف وتتكدّس رأسيًا أو تُغيّر شكلها بحسب موقعها في الكلمة. ويعتمد عرض هذه الأنظمة بشكل كبير على محرّك العرض في المتصفّح والخطّ المُستخدم.
قد يتطلّب النصّ الهندي بالحروف المجمّعة ارتفاع سطر أكبر من المتوقّع. أمّا النصّ التايلندي، الذي لا يفصل بين الكلمات بمسافات، فقد يُنتج كسور أسطر غير متوقّعة. وهذه المشاكل غير مرئية إن لم يكن أعضاء فريقك يقرؤون هذه اللغات — وهذا غالبًا ما هو الحال.
لماذا يُعدّ الاختبار البصري الحلّ الوحيد القابل للتوسيع
في مواجهة هذه التحديات، تفشل الأساليب التقليدية.
الاختبار اليدوي بواسطة متحدّثين أصليين هو النهج الأكثر بديهية والأقلّ قابليةً للتوسيع. فالعثور على مختبر أصلي لكل لغة من لغاتك، وتدريبه على التحقّق المنهجي من كل صفحة، وتكرار ذلك مع كل إصدار — هذا رفاهية لا تستطيع أغلب الفرق تحمّلها. وحتى مع وجود مختبرين أصليين، فإن التحقّق اليدوي يُفوّت انحدارات دقيقة (تغيّر في التباعد بمقدار 4 بكسلات غير مرئي بالعين المجردة في مراجعة واحدة).
الاختبارات الوظيفية الآلية تتحقّق من أن المحتوى المترجم يظهر، لكنها لا تتحقّق من كيفية ظهوره. فاختبار Playwright يتأكّد مما إذا كان page.locator('.hero-title').textContent() يحتوي على نصٍّ غير فارغ — وسينجح الاختبار حتى لو تجاوز النصّ حاويته وغطّى زرّ الدعوة إلى الإجراء (CTA) أسفله.
مراجعة التصميم بلقطات الشاشة ممارسة شائعة لكنها غير منهجية. يلتقط شخص ما لقطات شاشة للنسخة الألمانية، ويُرسلها في قناة Slack، ويُلقي مصمّم نظرةً سريعة بين الاجتماعات. هذا أفضل من لا شيء، لكنه بعيدٌ كل البعد عن الكفاية.
يحلّ الاختبار البصري الآلي المشكلة على نطاق واسع لأنه يفعل بالضبط ما لا تقوم به أي طريقة أخرى بشكل موثوق: يقارن منهجيًا العرض البصري لكل صفحة، في كل لغة، مع كل إصدار. فالنصّ الألماني المتجاوز يُكتشف، وتخطيط RTL المكسور يُكتشف، والتباعد الصيني المتغيّر يُكتشف — وكل ذلك دون تدخّل بشري، ودون متحدّثين أصليين، ودون مراجعة يدوية.
ما يكتشفه الاختبار البصري متعدد اللغات على أرض الواقع
إليك فئات الانحدارات التي يلتقطها الاختبار البصري منهجيًا في المواقع متعددة اللغات.
تجاوزات النصوص
هذا السيناريو الأكثر تكرارًا. فحاوية CSS بعرض ثابت أو max-width تعمل للإنجليزية لكنها لا تعمل للألمانية أو الفنلندية. فيتجاوز النصّ حاويته، أو يتداخل مع عناصر أخرى، أو يُقتطع دون قصد.
يكتشف الاختبار البصري ذلك لأن التجاوز يُغيّر موضع العناصر أو رؤيتها في الصفحة. إنه فرقٌ قابل للقياس بين الخطّ الأساسي (حيث لم يكن النصّ يتجاوز) واللقطة الحالية (حيث يتجاوز).
انكسارات تخطيطات RTL
مكوّن يعرض بشكل صحيح في LTR لكن تخطيطه مكسور في RTL. أو flexbox لا يعكس اتجاهه. أو position: absolute; right: 10px الذي ينبغي أن يكون left: 10px في RTL لكنه ليس كذلك. أو حشوة غير متماثلة تُنشئ فراغًا في المكان الخاطئ.
هذه الأخطاء مضلّلة بشكل خاص لأن فريق التطوير — الذي يعمل عادةً في LTR — لا يراها أبدًا في سير عمله اليومي. ويجعلها الاختبار البصري مرئيةً دون أن يحتاج أحد إلى تبديل لغة عمله.
عدم تناسق ارتفاعات المكونات
في شبكة بطاقات، إذا كانت إحدى البطاقات تحمل عنوانًا أطول بالألمانية منه بالإنجليزية، يزيد ارتفاعها — ممّا يُزيح الشبكة بأكملها عن المحاذاة. وتحدث نفس المشكلة مع الأزرار وعناصر التنقّل وصفوف الجداول وعناصر القوائم.
يلتقط الاختبار البصري هذه التناقضات لأنه يقارن البنية البصرية للصفحة الكاملة، وليس العناصر المعزولة. فالشبكة غير المحاذاة فرقٌ قابلٌ للاكتشاف.
خطوط مفقودة أو معروضة بشكل سيء
يستخدم موقعك خطًّا ويب يغطّي الحروف اللاتينية لكنه لا يغطّي العربية أو الصينية. فيعود المتصفّح إلى خطّ النظام، ممّا يُغيّر المظهر العام للصفحة في تلك اللغات. أو الأسوأ: تُعرض بعض الحروف كمستطيلات فارغة (ما يُعرف بـ "التوفو").
يكتشف الاختبار البصري هذه التغيّرات في عرض الخطوط لأن الخطّ الأساسي الإنجليزي يستخدم الخطّ الصحيح، وإذا كان خطّ البديل يُنتج نتيجة مختلفة بصريًا في لغة أخرى، فإن المقارنة تُنبّه إليها.
مشاكل الصور والأيقونات المترجَمة
بعض المواقع تُترجِم صورها — لقطات شاشة للمنتج باللغة المحلية، ولافتات تسويقية مترجمة، وأيقونات مكيّفة للسوق. وإذا كانت الصورة المترجمة بأبعاد خاطئة أو نسبة خاطئة أو نصٍّ مقتطع، يكتشفها الاختبار البصري كما يكتشف أي تغيّر بصري آخر.
تجربتنا مع 9 لغات
نُدير موقع delta-qa.com بـ 9 لغات. ليس تباهيًا، بل لأن سوقنا دولي ونؤمن بأن كل مستخدم يستحقّ تجربة بلغته.
علّمتنا هذه التجربة دروسًا تمنّينا لو تعلّمناها بطريقة أخرى.
كل إضافة لغة تكشف أخطاءً في اللغات الموجودة. عندما أضفنا النسخة العربية (RTL)، اكتشفنا أن بعض المكونات كانت تحمل هوامش ثابتة (margin-left: 16px بدلًا من margin-inline-start: 16px) لم تُسبّب أي مشاكل في LTR لكنها كسرت التخطيط في RTL. وأدّى إصلاح هذه المكونات إلى تحسين جودة الكود لجميع اللغات.
الترجمات تصل باستمرار، وليست دفعة واحدة. فالموقع متعدد اللغات لا يكون "منتهيًا" أبدًا. كل محتوى جديد، وكل تعديل نصي، وكل تحديث للوثائق يجب أن يُترجَم. وكل ترجمة هي انحدار بصري محتمل — نصّ أطول يتجاوز، أو ترجمة مفقودة تعرض مفتاحًا تقنيًا، أو تنسيق يضيع.
التحقّق اليدوي من 9 لغات ضربٌ من الخيال. فالتحقّق بصريًا من كل صفحة بـ 9 لغات بعد كل نشر يمثل عبئًا مرهقًا. إذا كان موقعك يضمّ 30 صفحة، فهذا 270 تحقّقًا لكل عملية نشر، دون احتساب منافذ الجوال والأجهزة اللوحية. والاختبار البصري الآلي هو النهج الوحيد الواقعي.
أخطاء اللغات المتعددة هي الأخيرة في الإصلاح. ففي سُلّم الأولويات، يُنقل خطأٌ يؤثّر فقط على النسخة الفنلندية أو اليابانية منهجيًا إلى أسفل القائمة. ويُجبر الاختبار البصري الآلي على رؤية هذه الأخطاء باكتشافها والإبلاغ عنها على نفس مستوى أخطاء النسخة الإنجليزية.
كيف تُهيكل الاختبار البصري متعدد اللغات
إذا كنت تُدير موقعًا متعدد اللغات وتريد دمج الاختبار البصري، فإليك النهج الذي نوصي به.
حدّد مصفوفة التغطية
على الأرجح لا تحتاج إلى اختبار كل صفحة في كل لغة مع كل إصدار. حدّد التوليفات الحرجة.
اللغات عالية المخاطر: اللغات ذات أكبر توسّع نصي (الألمانية، الفنلندية)، ولغات RTL (العربية، العبرية)، ولغات CJK (الصينية، اليابانية، الكورية). هذه اللغات تُنتج أكثر الانحدارات تكرارًا ووضوحًا.
الصفحات عالية المخاطر: الصفحات ذات النصوص القصيرة الكثيرة في حاويات مقيّدة (التنقّل، الأزرار، النماذج، بطاقات المنتجات). أمّا الصفحات ذات المحتوى الطويل (المقالات، الوثائق) فأقلّ خطورة لأن النصّ يتدفّق بشكل طبيعي.
مصفوفة الأولوية هي تقاطع الاثنين: اختبر صفحاتك عالية المخاطر بلغاتك عالية المخاطر. هناك ستجد 80% من الانحدارات.
التقط خطوطًا أساسية لكل لغة
لكل لغة خطّها الأساسي الخاص. فالنسخة الألمانية لصفحتك الرئيسية خطّ أساسي منفصل عن النسخة الإنجليزية. وعند المقارنة، تقارن النسخة الألمانية الحالية مع النسخة الألمانية من آخر إصدار — وليس مع النسخة الإنجليزية.
هذا تمييز مهمّ. فالاختبار البصري متعدد اللغات لا يقارن اللغات ببعضها البعض (من المفترض أنها مختلفة)، بل يقارن كل لغة مع نفسها عبر الزمن لاكتشاف الانحدارات.
أتمت تبديل اللغات
لالتقاط نسخ لغات مختلفة بكفاءة، يجب أن تكون أداة الاختبار قادرة على التنقّل إلى كل نسخة. مع أداة بدون كود مثل Delta-QA، تنقّل ببساطة إلى رابط URL لكل نسخة لغوية (مثل /de/ و/ar/ و/zh/) وتلتقط الأداة العرض المناسب.
تعامَل مع المحتوى الديناميكي المترجم
بعض المحتوى يتغيّر بشكل مشروع بين اللقطات — التواريخ، الأسعار، العروض الترويجية. اضبط أداتك على استبعاد هذه المناطق الديناميكية من المقارنة، وإلا فإن كل لقطة ستُطلق إنذارات كاذبة على محتوى يتغيّر بشكل طبيعي.
ادمج الاختبار البصري في سير عمل الترجمة
اللحظة الأخطر للموقع متعدد اللغات ليست نشر الكود — بل تحديث الترجمة. فملف ترجمة جديد بنصوص أطول أو تنسيق مختلف أو مفاتيح مفقودة قد يُكسر الواجهة. شغّل الاختبار البصري بعد كل تحديث للترجمة، وليس فقط بعد عمليات نشر الكود.
الأدوات المتاحة
يعتمد اختيار أداة الاختبار البصري للموقع متعدد اللغات على سياقك التقني وحجم لغاتك.
Delta-QA مناسب بشكل خاص لأن نهج بدون كود يتيح التقاط أي نسخة لغوية بمجرّد التنقّل إليها. والخوارزمية البنائية غير حسّاسة لاختلافات عرض الخطوط بين اللغات — فهي تقارن خصائص CSS وليس البكسلات. وهذا ميزة رئيسية عند اختبار لغات بأنظمة كتابة مختلفة، حيث يتفاوت العرض الطباعي بشكل كبير.
Playwright يوفّر إمكانيات اختبار بلقطات الشاشة يمكن برمجتها حسب اللغة، لكن كل تأكيد بصري يجب كتابته يدويًا، وتصبح إدارة الخطوط الأساسية لكل لغة في مستودع Git معقّدة بسرعة مع تزايد عدد توليفات اللغة/الصفحة/المنفذ.
Percy وApplitools يتولّيان تعدّد اللغات عبر سحابتهما مع إمكانيات التجميع حسب اللغة. ونموذج تسعيرتهما لكل لقطة قد يصبح مكلفًا عندما يُضاعف عدد توليفات اللغة/الصفحة/المنفذ عدد اللقطات المطلوبة.
الأسئلة الشائعة
كيف تتعامل مع النصوص التي تتجاوز في بعض اللغات؟
يكتشف الاختبار البصري التجاوز، لكن الإصلاح مهمّة تصميم وتطوير. تشمل الحلول التقنية استخدام حاويات مرنة (min-width بدلًا من width ثابت)، وoverflow-wrap: break-word للكلمات الطويلة جدًا، وفئات CSS شرطية لكل لغة لضبط أحجام الخطوط أو التباعد عند الضرورة. والنهج الأكثر متانة هو التصميم للغة الأطول منذ البداية — فإذا صمد التصميم بالألمانية، فسيصمد في كل مكان.
هل يجب اختبار جميع اللغات مع كل إصدار؟
لا، إذا كان لديك لغات كثيرة. ركّز على اختبار اللغات عالية المخاطر (الألمانية، العربية، الصينية) والصفحات عالية المخاطر (التنقّل، النماذج، البطاقات) بشكل منهجي. وشغّل اختبارًا كاملًا لجميع اللغات على جميع الصفحات بشكل دوري — مثلًا مرة واحدة شهريًا — ومع كل تحديث رئيسي للترجمة.
كيف تختبر لغات RTL عندما لا أحد في الفريق يقرأ العربية؟
هذا بالضبط قوّة الاختبار البصري الآلي: لا تحتاج إلى قراءة اللغة لاكتشاف الانحدارات. فالأداة تقارن النسخة RTL الحالية مع الخطّ الأساسي RTL السابق. وإذا تغيّر التخطيط، أو تحرّك عنصر، أو تجاوز نصّ — يُكتشف ذلك بغضّ النظر عن اللغة. فلا تحتاج إلى قراءة العربية لتنتبه إلى أن كتلة نصّ تجاوزت حاويته.
كيف تُميّز بين خطأ i18n وتغيّر ترجمة متعمّد؟
باتباع سير عمل التحقّق القياسي: عندما يُشير الاختبار البصري إلى فرق، افحص السبب. وإذا كان الفرق يتوافق مع تحديث ترجمة مُوثَّق، فحدّث الخطّ الأساسي. أمّا إذا ظهر دون تغيّر ترجمة مُخطَّط له، فهو انحدار — إمّا تغيّر في CSS أثّر على لغة معيّنة، أو مفتاح ترجمة مفقود يعرض قيمة افتراضية.
ما أثر ذلك على تحسين محركات البحث (SEO) لموقع متعدد اللغات مكسور بصريًا؟
الأثر كبير. فشركة Google تُقيّم تجربة المستخدم لكل لغة على حدة عبر مؤشّرات Core Web Vitals وإشارات جودة الصفحة. وتخطيط مكسور بالألمانية بنصٍّ متجاوز وعناصر متداخلة يُضعّف إشارات الجودة للنسخة الألمانية، بغضّ النظر عن جودة النسخة الإنجليزية. فكل نسخة لغوية تُقيَّم بشكل مستقل. والاختبار البصري المنهجي يضمن أن الجودة متسقة عبر جميع النسخ.
هل يتولّى Delta-QA خطوط CJK وأنظمة الكتابة المعقّدة؟
يُقارن Delta-QA خصائص CSS المحسوبة بدلًا من البكسلات، ممّا يجعله غير حسّاس لاختلافات العرض الطباعي بين اللغات. سواء كانت صفحتك تستخدم حروفًا لاتينية أو صينية أو عربية أو ديفاناغارية، فإن الخوارزمية البنائية تُحلّل نفس الخصائص — الأبعاد، المواقع، الألوان، التباعدات. فإذا غيّر حرف صيني ارتفاع عنصر، أو تجاوزت كلمة عربية حاويتها، يُكتشف التغيّر عبر الخصائص البنائية، وليس عبر مقارنة البكسلات.
الخاتمة
الموقع متعدد اللغات ليس موقعًا مُترجَمًا فحسب. إنه منتج مختلف بكل لغة — بقيود بصرية وطباعية وتخطيطية تتفاوت جذريًا. فاختبار النسخة الإنجليزية فقط والاعتماد على أن اللغات الأخرى ستتبع هو تجاهل لوقائع التدويل.
الاختبار البصري الآلي هو الوسيلة الوحيدة القابلة للتوسيع للمحافظة على الجودة البصرية عبر جميع نسخك اللغوية. فهو يكتشف ما لا يتحقّق منه أحد — تجاوزات ألمانية، وانكسارات RTL عربية، وتناقضات CJK — ويقوم بذلك مع كل إصدار، دون متحدّثين أصليين، ودون مراجعة يدوية، ودون أي تنازل.
كل مستخدم من مستخدميك، بغضّ النظر عن لغته أو موقعه الجغرافي، يستحقّ واجهة تعمل بصريًا على نحوٍ سليم واحترافي. والاختبار البصري متعدد اللغات هو السبيل الأمثل والوحيد لضمان ذلك على نطاق واسع.