مختبر تفاوض اللغة العربية في HTTP: مشاريع تخرج هندسة البرمجيات

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

اقرأ التفضيل كقائمة مرتبة

يحتوي Accept-Language على language-ranges وقد تحمل القيم معامل وزن q. على سبيل المثال، يفضل العميل ar-JO, ar;q=0.9, en;q=0.7 بالترتيب الموضح. يشرح RFC 9110 في قسم تفاوض اللغة أن هذه القائمة إشارة تفضيل، ويفصلها عن Content-Language الذي يصف محتوى الاستجابة. لا تحلل السلسلة بتقسيم بسيط يفترض أن كل عنصر لغة مفردة بلا وزن.

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

اكتب ترتيب الأولوية قبل الكود

قواعد نسخة أولية واضحة يمكن أن تكون: إذا اختار المستخدم لغة من الواجهة وخزنها، استخدم ذلك الاختيار؛ وإلا طابق Accept-Language مع اللغات المدعومة؛ وإذا لم يوجد تطابق، استخدم العربية الافتراضية وأخبر المستخدم بإمكانية التغيير. هذه سياسة التطبيق، وليست إلزاماً عاماً في RFC. سجل سبب الاختيار مثل user-choice أو header-match أو default، لكن لا تخزن سلسلة التفضيلات كاملة دون فائدة.

اختبر ar-JO مع توفر تمثيل ar فقط، ثم en-US,en;q=0.9,ar;q=0.5 مع توفر ar وen. يجب أن يعرض المختبر نتيجة قابلة للتفسير. إذا ظهر وزن غير صالح أو نطاق غير مدعوم، لا تكسر الاستجابة؛ طبّق قاعدة fallback موثقة. يمكنك مقارنة Basic Filtering أو مطابقة التطبيق المبسطة، لكن لا تخلط متطلبات لغة RFC بالقرار الخاص بمسارات التطبيق.

افصل اللغة عن نسخة cache

إذا اختار الخادم الاستجابة بحسب Accept-Language، فعليه أن يوضح ذلك للـcache باستخدام Vary: Accept-Language أو استراتيجية تخزين مناسبة. توضح إرشادات التفاوض في MDN كيف تشير Vary إلى الرؤوس المؤثرة في اختيار التمثيل. لا تضف Vary آلياً إلى كل مسار؛ وثق المتغير الذي يغير المحتوى فعلاً وافحص إعداد cache أمام الخادم.

في تجربة محلية، اطلب الصفحة أولاً بقبول العربية، ثم بقبول الإنجليزية، ثم كرر عبر cache اختباري يسجل مفتاحه. أضف تفضيلاً يدوياً يطغى على header وتأكد أن الرؤوس لا تسبب إعادة استخدام نسخة قديمة. Cache-Control وVary يعملان ضمن سلوك أوسع من مفتاح واحد؛ لذلك لا تعلن أن إضافة Vary وحدها تصلح كل proxy. وثّق ما الذي خزنه المختبر وكيف مسح الحالة بين التجارب.

جدول اختبار صغير

جهز حالات: ar-JO مع ar متاحة؛ en-US ثم en؛ تفضيل لغة غير مدعومة؛ رأس غائب؛ قيمة q غير صالحة؛ اختيار يدوي بالعربية مع header إنجليزي؛ واستجابة مخصصة دون تخزين مشترك. لكل طلب احفظ status code وContent-Language وVary وقرار التطبيق. هذه آثار مختبرية، ولا ينبغي نسخ بيانات زوار حقيقيين أو حفظ IP لمجرد اختبار التفاوض.

مثال: يصل طلب بلا اختيار سابق ويفضل en-US، لكن التطبيق لا يقدم إلا en وar. تختار السياسة en باعتبارها مطابقة أساسية، وترسل Content-Language: en. بعد أن يضغط المستخدم العربية، تصبح الزيارات اللاحقة عربية حتى لو بقيت تفضيلات المتصفح إنجليزية. يجب أن يشرح الجدول لماذا تغير القرار. إذا كان المسار نفسه يحتوي locale صريحاً مثل /ar/، فاختبر أي مصدر يفوز بدلاً من مزج الإشارات في سلوك غير معلن.

اختبر الخصوصية وfallback

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

تحقق أن HTML يعلن اللغة الفعلية بـlang وأن Content-Language يصف التمثيل حسب تصميم التطبيق. لا تخلط اللغة مع المنطقة الجغرافية أو العملة أو اتجاه الكتابة؛ العربية يمكن أن تكون ببلدان وأرقام وتفضيلات مختلفة. لا يكفي فحص الرؤوس إذا كانت الصفحة نفسها إنجليزية لكن وسم lang يقول ar. اختبار DOM ورؤوس الاستجابة يجب أن يسير معاً.

منتج أولي لا يدير الترجمات

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

يختلف هذا عن مقال مقارنة مصطلحات الواجهة العربية الذي يراجع اتساق النصوص بين إصدارات التطبيق؛ هنا القرار يجري عند طلب HTTP وتؤثر فيه الرؤوس والـcache. كما أنه لا يطبع العربية ولا يحلل تشكيلها. لخص حدود المطابقة والسلوك عند عدم الدعم، واعرض أمثلة يمكن لأي مراجع إعادة إرسالها عبر curl. معيار RFC 9110 يحدد دلالات الرؤوس، لكن سياسة اختيار الموقع وخيار المستخدم تبقى مسؤولية تصميم التطبيق.