توافق إضافة ووردبريس في موقع متعدد اللغات: ما الذي يحتاج فعلاً إلى اختبار؟

ابدأ بفصل ما يراه المستخدمون عما يضبطه المسؤولون

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

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

اختبر واجهات المحتوى التي تتغير فعلاً حسب اللغة

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

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

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

تحقق من المخرجات الديناميكية، لا المحتوى المخزن فقط

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

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

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

تحتاج النماذج إلى تحقق وتسميات ومعالجة إرسال واعية باللغة

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

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

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

يضيف WooCommerce اعتمادات على المنتج والسلة والدفع

يمتد توافق WooCommerce في المواقع متعددة اللغات إلى ما هو أبعد من أوصاف المنتجات. يمكن أن تكون عناوين المنتجات والمتغيرات والسمات والفئات والأصول المرتبطة كلها واعية باللغة، ويجب أن تحافظ الإضافة على العلاقة بين المنتج المترجم وبيانات التجارة الأساسية. إذا كانت الإضافة تتعامل مع صفحات المنتجات، فيجب اختبارها مقابل عرض المنتج المترجم، لا إدخال الكتالوج باللغة الافتراضية فقط.

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

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

تعامل مع التوجيه والروابط الدائمة وإشارات canonical كجزء من التوافق

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

تعد إشارات canonical مهمة لأنها تؤثر في كيفية تفسير الصفحات المترجمة على أنها محتوى مرتبط أو مكرر. يمكن لإضافة تغيّر مخرجات الصفحة أو تحقن روابط بديلة أو تعيد كتابة عناوين URL أن تتداخل مع علاقات اللغة في الموقع إذا لم تحترم البنية متعددة اللغات. سؤال التوافق هنا ليس ما إذا كانت الصفحة تُحمّل، بل ما إذا كانت الصفحة تُحل بشكل متسق ضمن نموذج اللغة في الموقع.

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

استخدم مصفوفة اختبار تتبع البيانات والعرض والحالة

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

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

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