التدويل والتعريب للمواقع الثابتة

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

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

التدويل (i18n) والتوطين (l10n) وجهان لعملة واحدة. يتعلق التدويل بكيفية تصميم البرامج ، في حالتنا ، بحيث يمكن تكييفها مع لغات ومناطق متعددة دون الحاجة إلى تغييرات هندسية. من ناحية أخرى ، فإن التوطين يتعلق فعليًا بتكييف البرنامج مع تلك اللغات والمناطق. يمكن أن يحدث التدويل عبر مكدس موقع الويب بالكامل ؛ بدءًا من HTML و CSS و JS إلى اعتبارات التصميم وبناء الأنظمة. يحدث التعريب في الغالب في إنشاء المحتوى (كل من النسخ الطويل والنسخ المصغر) وإدارته.

ملاحظة : بالنسبة لأولئك الفضوليين ، تعد i18n و l10n أنواعًا من الاختصارات المعروفة باسم الأسماء الرقمية. A11y ، لإمكانية الوصول ، هو اسم رقمي شائع آخر في تطوير الويب.

التدويل (i18n)

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

تحديد لغة المستخدم والمنطقة

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

بشكل عام ، هناك ثلاث طرق عالية المستوى لتحديد الأقلمة التي يجب تقديمها للمستخدمين:

1. الموقع من عنوان IP ؛
2. Accept-Language العنوان أو navigator.languages ​​؛
3. المعرف في URL.

ينتهي الأمر بالعديد من الأنظمة إلى الجمع بين واحد أو اثنين أو الثلاثة جميعًا ، عند تحديد التوطين الذي يجب تقديمه. أثناء التحقيق ، وجدنا مشكلات في استخدام عناوين IP ورؤوس Accept-Language التي اعتقدنا أنها مهمة بما يكفي لإزالتها من الاعتبار بالنسبة لنا:

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

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

هناك ثلاثة أنماط شائعة لبناء المعرفات في عناوين URL:

1. توفير نطاقات مختلفة (عادةً نطاقات TLD أو نطاقات فرعية لمناطق ولغات مختلفة (مثل example.com و example.de و en.example.org و de.example.org ) ؛
2. لديك أدلة فرعية مترجمة للمحتوى (على سبيل المثال ، example.com/en و example.com/de ) ؛
3. اعرض المحتوى المترجم بناءً على معلمات URL (على سبيل المثال ، example.com?loc=en و example.com?loc=de ).

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

قررنا استخدام الدلائل الفرعية ، والتي منحتنا ميزة إضافية لقدرتنا على الترجمة إلى اللغة فقط ( example.com/en ) أو اللغة والمنطقة ( example.com/en-US و example.com/en-GB ) حسب الحاجة أثناء الحفاظ على PWA واحد. قررنا أيضًا أن كل توطين لموقعنا سيعيش في دليل فرعي بحيث لا يتم رفع لغة واحدة عن لغة أخرى ، وأن تكون جميع عناوين URL ، باستثناء الدليل الفرعي ، متطابقة عبر الترجمة استنادًا إلى لغة التأليف ، مما يسمح للمستخدمين بتغييرها بسهولة تعريب دون الحاجة إلى ترجمة عناوين المواقع.

تقديم المحتوى المترجم

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

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

قمنا بتجميع الحل الخاص بنا في البرنامج الإضافي Workbox ، إعادة توجيه تدويل عامل الخدمة. يمكن دمج المكون الإضافي ، جنبًا إلى جنب مع الوحدة الفرعية للتفضيلات الخاصة به ، لتعيين تفضيل لغة المستخدم والحصول عليه وإدارة إعادة التوجيه عند دمجه مع طريقة registerRoute الخاصة بـ Workbox وطلبات التصفية عند request.mode === 'navigate' .

مثال كامل مبسط يبدو كالتالي:

رمز العميل

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

كود عامل الخدمة

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

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

تكييف واجهة مستخدم الموقع

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

اقتباسات Blockquote

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

تنسيق التاريخ والأرقام

كل من التواريخ والأرقام لها طريقة ، .toLocaleString للسماح بالتنسيق بناءً على الترجمة (اللغة و / أو المنطقة). يتم شحن المتصفحات التي تدعم هذه التطبيقات مع جميع الترجمات المتاحة ، مما يجعلها قابلة للاستخدام بسهولة هناك ، ولكن Node.js ليس كذلك. لحسن الحظ ، تسمح لك وحدة icu الكاملة لـ Node باستخدام جميع بيانات الترجمة المتاحة. للقيام بذلك ، بعد تثبيت الوحدة ، قم بتشغيل الكود الخاص بك باستخدام متغير البيئة NODE_ICU_DATA مضبوطًا على المسار إلى الوحدة النمطية ، على سبيل المثال NODE_ICU_DATA=node_modules/full-icu .

معلومات HTML الوصفية

هناك ثلاث مناطق في علامة HTML والعناوين التي يجب تحديثها مع كل ترجمة:

• لغة الصفحة ،
• اتجاه الكتابة ،
• اللغات البديلة متوفرة في الصفحة.

أول من انتقل إلى عنصر html بخصائص dir و lang على التوالي ، على سبيل المثال <html lang="en" dir-"ltr"> للغة الإنجليزية الأمريكية. سيضمن الإعداد الصحيح لهذه العناصر تدفق المحتوى في الاتجاه الصحيح ويمكن أن يسمح للمتصفحات بفهم لغة الصفحة ، مما يسمح بميزات إضافية مثل ترجمة المحتوى. يجب عليك أيضًا تضمين روابط rel="alternate" للسماح لمحركات البحث بمعرفة أن الصفحة قد تمت ترجمتها بالكامل ، لذا فإن تضمين <link href="/es" rel="alternate" hreflang="es"> في صفحتنا المقصودة باللغة الإنجليزية سيؤدي إلى دع محركات البحث تعرف أن هذا له ترجمة يجب أن تبحث عنها.

التصميم الجوهري

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

يوجد عدد من وحدات CSS المصممة خصيصًا للعمل مع المحتوى. هناك وحدتا em و rem تمثلان حجم الخط المحسوب وحجم خط الجذر على التوالي. يمكن أن يؤدي تبديل قيم px ذات الحجم الثابت لهذه الوحدات إلى قطع شوط طويل في جعل الموقع أكثر استجابة لمحتواه. ثم هناك وحدة ch ، التي تمثل الحجم الداخلي للحرف 0 (صفر) في الخط. يتيح لك هذا ربط أشياء مثل width ، على سبيل المثال ، مباشرة بالمحتوى الذي يحتوي عليه.

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

التعريب (l10n)

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

استراتيجية المحتوى

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

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

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

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

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

توطين القيم وليس المفاتيح

عادةً ما تولد نماذج المحتوى والنسخ المصغّر هياكل شبيهة بالكائنات الموجودة في قاعدة الرموز ؛ سواء كانت إدخالات قاعدة بيانات أو كائن JSON أو YAML أو Front Matter. لا توضع مفاتيح الكائنات! إذا كان لديك صورة microcopie.chercher.texte لنص البحث موجودة في كائن microcopy ، فلا تضعه في كائن microcopy.search.text في microcopie . يجب التعامل مع المفاتيح الموجودة في الوحدات النمطية كمعرفات غير محددة للترجمة بحيث يمكن استخدامها بشكل موثوق في القوالب القابلة لإعادة الاستخدام والاعتماد عليها في جميع أنحاء قاعدة التعليمات البرمجية. هذا يعني أيضًا أنه لا ينبغي عرض مفاتيح الكائنات للمستخدمين النهائيين كمحتوى أو صورة مصغرة.

إعداد الموقع الثابت

بالنسبة إلى chromeOS.dev ، استخدمنا Eleventy (11ty) مع Nunjucks كمولد موقع ثابت لدينا ، ولكن هذه التوصيات الخاصة بإعداد مولد موقع ثابت يجب أن تكون قابلة للتطبيق على معظم مولدات المواقع الثابتة. عندما يكون هناك شيء محدد 11 عامًا ، فسيتم استدعاؤه.

هيكل المجلد

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

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

في المستوى الأعلى ، يوجد دليل يحتوي على صفحات موقع ، تسمى هنا pages . متداخلاً بالداخل ، يوجد مجلد _data يحتوي على ملفات بيانات عامة. هذا المجلد مهم عند الحديث عن المساعدين بعد ذلك. بعد ذلك ، يوجد مجلد _generated . لدينا عدد من الصفحات التي ، بدلاً من أن يكون لها محتواها الخاص ، يتم إنشاؤها من محتوى موجود أو كميات صغيرة من النسخ المصغرة أو مزيج من الاثنين معًا. فكر في الصفحة الرئيسية بصفحة رئيسية أو صفحة بحث أو صفحة مقصودة لقسم مدونة. نظرًا لأن هذه الصفحات ذات قوالب عالية ، فإننا نخزن القوالب في المجلد _generated من هناك بدلاً من وجود ملفات HTML أو Markdown فردية لكل منها. تكون هذه المجلدات مسبوقة بشرطة سفلية للإشارة إلى أنها لا تُخرج صفحات أسفلها مباشرةً ، ولكنها تُستخدم لإنشاء صفحات في مكان آخر.

التالي ، الدلائل الفرعية l10n! يجب تسمية كل دليل باسم علامة اللغة BCP47 (الأكثر شيوعًا ، رمز المنطقة المحلية) للترجمة التي يحتوي عليها: على سبيل المثال ، en للغة الإنجليزية ، أو en-US للغة الإنجليزية الأمريكية. في قاعدة بيانات chromeOS.dev ، غالبًا ما نشير إليها على أنها لغات أيضًا. ستصبح هذه المجلدات بمثابة أدلة فرعية للترجمة ، وتقسيم المحتوى إلى ترجمة. تسمح سلسلة بيانات 11ty بأن تكون البيانات متاحة لكل ملف في دليل وأبنائه إذا كان الملف موجودًا في جذر الدليل وتم تسميته بنفس اسم الدليل (يسمى ملفات بيانات الدليل). يستخدم 11ty كائنًا تم إرجاعه من هذا الملف ، أو دالة تقوم بإرجاع كائن ، وتضخه في المتغيرات المتاحة للقالب ، لذلك يمكننا الوصول إلى البيانات هنا لجميع محتويات هذا التوطين.

للمساعدة في الحفاظ على هذه الملفات ، كتبنا مساعدًا يسمى l10n-data ، وهو جزء من سقالات الموقع الثابت لدينا ، والذي يستفيد من بنية المجلد هذه لبناء سلسلة من البيانات المترجمة ، مما يسمح بترجمة البيانات على أجزاء. يقوم بذلك عن طريق تخزين البيانات في دليل بيانات خاص بالإعدادات المحلية ، دليل _data فيه (يتم تحميله في ملف بيانات الدليل). إذا نظرت في دليل بيانات اللغة الإنجليزية لدينا ، على سبيل المثال ، فسترى نماذج مصغرة مثل locale.json التي تحدد رمز اللغة واتجاه الكتابة الذي سيتم عرضه بعد ذلك في HTML ، newsletter.yml الذي يحدد النسخ المصغرة اللازمة لدينا الاشتراك في النشرة الإخبارية وملف microcopy.yml الذي يتضمن صورة مصغرة عامة مستخدمة في أماكن متعددة في جميع أنحاء الموقع والتي لا تتناسب مع ملف أكثر تحديدًا. في كل مكان يتم فيه استخدام أي من هذا النسخ المصغر ، نقوم بسحبه من هذه البيانات المتاحة من خلال 11 متغيرًا من متغيرات الحقن في قوالبنا لاستخدامها.

يميل Microcopy إلى أن يكون هو الأصعب في الإدارة ، بينما يكون باقي المحتوى في الغالب للأمام بشكل مباشر. ضع المحتوى الخاص بك ، غالبًا ملفات Markdown أو HTML ، في المجلد الفرعي المترجم. بالنسبة لمولدات المواقع الثابتة التي تعمل على بنية المجلد ، سيعين اسم الملف وهيكل المجلد للمحتوى عادةً 1: 1 إلى عنوان URL النهائي لهذا المحتوى ، لذلك فإن ملف Markdown في en/web/pwas.md سينتج إلى عنوان URL en/web/pwa . باتباع مبدأ "القيم وليس المفاتيح" الخاص بنا في الترجمة ، قررنا عدم تعريب أسماء ملفات المحتوى (وبالتالي المسارات) ، مما يسهل علينا تتبع حالة توطين الملف نفسه عبر المناطق المحلية ومعرفة المستخدمين إنهم في الصفحة الصحيحة بين مناطق مختلفة.

مساعدين I18n

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

الأول هو مرشح التاريخ. لقد قمنا بتوحيد جميع التواريخ عبر المحتوى الخاص بنا المكتوبة كقيمة تاريخ YAML لأننا نكتبها في الغالب في YAML وتصبح متاحة في قوالبنا كطابع زمني UTC كامل. عند استخدام الوحدة النمطية full-icu والتكوين ، يمكن تمرير سلسلة التاريخ (المحتوى الذي يتم تغييره) ، جنبًا إلى جنب مع رمز المنطقة للمحتوى الذي يتم عرضه ، مباشرةً إلى Date.toLocaleString (مع خيارات التنسيق الاختيارية) لتقديم تاريخ مترجم. يمكن استخدام Date.toLocaleDateString اختياريًا بدلاً من ذلك إذا كنت تريد فقط جزء التاريخ عندما لا يتم تمرير أي خيارات تنسيق ، بدلاً من التاريخ والوقت المترجمين بالكامل.

المرشح الثاني هو ما نسميه localURL . يأخذ هذا عنوان URL محلي (يتم تغيير المحتوى) والإعدادات المحلية التي يجب أن يكون بها عنوان URL ، ويقوم بتبديلها. يتغير ، على سبيل المثال ، /en/linux إلى /es/linux .

تتعلق المرشحات الأخيرتان باسترداد المعلومات المحلية من التعليمات البرمجية المحلية وحدها. الثالث يستفيد من الوحدة النمطية iso-639-10 لتحويل كود المنطقة إلى اسم لغة في اللغة الأم. نستخدم هذا بشكل أساسي لمُحدد اللغة الخاص بنا. الرابع يستخدم وحدة iso-i18n-countries لاسترداد قائمة البلدان بهذه اللغة. نستخدم هذا بشكل أساسي لبناء النماذج مع قوائم الدول.

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

كان مساعدنا الأخير والأكثر أهمية هو البيانات العالمية لموقعنا. بالاعتماد على بنية الدليل الفرعي القائمة على التعليمات البرمجية المحلية ، تحدد هذه الوظيفة ديناميكيًا ما يدعمه الموقع. يقوم ببناء متغير عالمي ، site ، يتضمن الخاصية l10n ، يحتوي على كل المحتوى المصغر والمحتوى الخاص بالترجمة من {{locale-code}}.11tydata.js . يحتوي أيضًا على خاصية languages تسرد جميع اللغات المتوفرة كمصفوفة. أخيرًا ، تقوم الوظيفة بإخراج ملف جافا سكريبت يوضح بالتفصيل اللغات التي يدعمها الموقع والملفات الفردية لكل إدخال في {{locale-code}}.11tydata.js ، مفتاح لكل ترجمة ، كلها مصممة ليتم استيرادها بواسطة البرامج النصية للمتصفح. يربط الرفع الثقيل لهذا الملف موقعنا الثابت بجافا سكريبت للواجهة الأمامية مع المصدر الوحيد للحقيقة وهو معلومات الترجمة التي نحتاجها بالفعل. كما أنه يسمح لنا بإنشاء صفحات برمجيًا بناءً على ترجماتنا عن طريق تكرار حلقات site.l10n . هذا ، جنبًا إلى جنب مع مجموعاتنا الخاصة بالترجمة ، دعنا نستخدم ترقيم الصفحات 11ty لإنشاء صفحات هبوط رئيسية وأخبار مترجمة دون الاحتفاظ بصفحات HTML منفصلة لكل منها.

خاتمة

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