المحتوى الديناميكي هو المكان الذي تصبح فيه ترجمة ووردبريس صعبة

لماذا تتوقف ترجمة المقالات العادية عند حدود المحرر

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

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

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

ما الواجهات في ووردبريس التي تحتاج عادةً إلى معالجة توافق صريحة

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

يمكن أن تكون الاختصارات البرمجية صعبة بشكل خاص لأن المخرجات المرئية تُنشأ من السمات، أو الخيارات المخزنة، أو بيانات الإضافة التي قد لا تكون ممثلة كنص صفحة قابل للتحرير.

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

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

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

المشكلة الهندسية الأساسية: الترجمة تحتاج إلى بيانات ثابتة، لا مجرد نص مرئي

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

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

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

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

كيف يغيّر العرض وقت التشغيل سير عمل الترجمة

يعني العرض الديناميكي أن HTML النهائي لا يتحدد بالكامل عند حفظ المقال. وبدلًا من ذلك، قد تُجمَّع الصفحة لاحقًا من القوالب، أو منطق عرض الكتل، أو إعدادات الإضافة، أو سياق الطلب.

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

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

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

أنماط الفشل الشائعة في مواقع ووردبريس متعددة اللغات

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

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

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

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

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

ما الذي يجب أن تغطيه معالجة التوافق عادةً

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

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

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

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

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