كان وسم اللغة رمزاً واحداً لا خريطة تنقل: RFC 1766

الخلاصة

• أظهر RFC 1766 أجزاء الوسم للقراءة، لكنه طلب من التطبيق معالجة الوسم كله كرمز واحد؛ فالوسوم الفرعية تنظّم التسجيل ولا تصنع قائمة تنقل.
• شغلت رموز ISO والتسجيلات لدى IANA ومساحة الاستخدام الخاص مواضع مختلفة في البنية. أما العلاقة بين الوسم وموضوع المعلومات فتحددها المواصفة التي تستخدمه.
• أضافت المواصفات اللاحقة عمليات مطابقة محددة. ولم تجعل كل شرطة في صياغة 1995 مساراً عاماً للتنقل.

بدت الشرطة كأنها مسار إرشادي

في مارس 1995، قدّم RFC 1766 طريقة موجزة لتحديد اللغة المستخدمة في موضوع معلوماتي. وقد يوحي شكله بشجرة: وسم أساسي ثم أجزاء اختيارية تفصل بينها شرطات. بدا en-US مألوفاً، كما بدأ az-arabic وaz-cyrillic بالمقطع نفسه. لكن الوثيقة رسمت حداً واضحاً لهذا الفهم: ينبغي للتطبيقات أن تعامل وسم اللغة كاملاً كرمز واحد. كان تقسيمه إلى وسم أساسي ووسوم فرعية آلية إدارية، لا وسيلة للتنقل.

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

كانت لمساحة الأسماء حدود محددة. اتبعت الوسوم الأساسية ذات الحرفين ISO 639. وحُجزت i للتسجيلات التي تحددها IANA، بينما خصصت x للاستخدام الخاص الذي لا تسجل IANA وسومه الفرعية. أما القيم الأساسية الأخرى فظلت غير متاحة حتى مراجعة المواصفة. وفي أول وسم فرعي، اتبعت الرموز ذات الحرفين ISO 3166 alpha-2، وكان من الممكن تسجيل القيم التي تتراوح بين ثلاثة وثمانية أحرف لدى IANA. كما أمكن تسجيل الوسوم الفرعية اللاحقة.

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

جعل التسجيل القيم قابلة للتحقق علناً

تضمنت أمثلة RFC 1766 تعريف البلد (en-US)، واللهجة أو المتغير (no-nynorsk وen-cockney)، ولغة مسجلة لدى IANA (i-cherokee)، واختلافات الكتابة (az-arabic وaz-cyrillic). وأضافت الوثيقة تنبيهاً مهماً: لم يكن أي من الوسوم الفرعية المعروضة قد خُصص فعلياً. كانت الأمثلة توضيحاً للصياغة، لا قائمة بالقيم المتاحة.

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

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

يمكن للرأس أن يسرد لغات من دون أن يحدد أداة الاختيار

عرّف RFC 1766 أيضاً Content-Language، الذي يستطيع سرد عدة وسوم كاملة. وبالنسبة إلى multipart/alternative في MIME، أضاف معاملاً اسمه Differences لبيان أن الأجزاء البديلة تختلف في لغة المحتوى. شرح المستند سبب استخدام قارئ لهذه المعلومة، لكنه ترك آلية اختيار الجزء الذي سيُعرض خارج نطاقه.

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

وتوضح المراجعات اللاحقة هذا الفصل. سمح RFC 3066 الصادر عام 2001 بظهور الأرقام في الوسوم الفرعية، وأدخل مطابقة language-range. ويمكن للنطاق أن يطابق الوسم الكامل أو بادئة تنتهي عند حد الشرطة. كانت هذه عملية مطابقة محددة. ثم وضع RFC 3282 قواعد رأسي Content-Language وAccept-Language، بما في ذلك نطاقات التفضيل وقيم الجودة الاختيارية. أضافت هذه التطورات سلوكاً بروتوكولياً صريحاً حول الوسوم، لكنها لم تحول شرطة 1995 إلى مسار عام.

واصل RFC 4646 الصادر عام 2006 وRFC 5646 الصادر عام 2009 مراجعة BCP 47. وتثبت هذه السلسلة أن قواعد الصياغة والتسجيل تطورت، لكنها لا تثبت أن كل عميل عالج كل قيمة على نحو صحيح، أو أن الوسم اختار تلقائياً صفحة أو ترجمة أو طريقة عرض. الدلالة التاريخية لـRFC 1766 أضيق وأكثر تحديداً: يمكن لمعرّف ذي بنية داخلية أن يبقى قيمة واحدة غير قابلة للتجزئة لدى التطبيق، فيما تخدم أجزاؤه أعراف الإدارة.

المصادر وحدود الاستدلال

المواصفة الأساسية هي RFC 1766. وترد المراجعات اللاحقة في RFC 3066 وRFC 3282 وRFC 4646 وRFC 5646. تثبت هذه الوثائق الصياغة والتسجيل والتغييرات البروتوكولية اللاحقة، ولا تثبت التنفيذ أو الانتشار الشامل.