مواصلة النقاش حول مزايا Fluent على gettext المعتادة ، وأنا أنشر الموقف الرسمي لمبدعي Fluent في الترجمة.
Gettext هو نظام توطين له جذور عميقة في مشروع جنو والحلول المعمارية المرتبطة به. يرى
مشروع Fluent gettext مثالاً جيدًا على نظام بيئي كامل مستقل عن النظام الأساسي للمكتبات وأدوات لإدارة دورة إصدار المنتج الكامل مع ملفات الترجمة بتنسيق قابل للقراءة. في الوقت نفسه ، يقودنا نموذج Fluent إلى حلول معمارية أخرى في جوانب التوطين المهمة ، والتي بدورها تؤدي إلى واجهات برمجة التطبيقات ودورات حياة مختلفة تمامًا.
بمعنى آخر ، gettext هو مشروع رائع ، لكننا لا نشارك وجهات نظره حول طريقة التوطين.
فيما يلي الاختلافات الرئيسية بين gettext و Fluent:
اتفاقية
الفرق الأكثر أهمية بين gettext و Fluent هو معرف الرسالة. قررت Gettext استخدام السلسلة المصدر (عادة باللغة الإنجليزية) كمعرّف. يبدو هذا الخيار بسيطًا ، لكنه يفرض عليه لاحقًا العديد من القيود.
بادئ ذي بدء ، مع هذا النهج ، أي تغيير في السطر الأصلي يبطل جميع الترجمات المرتبطة به. يؤدي هذا إلى زيادة الحمل على المطورين بشكل خطير ، مما يضطرهم إلى عدم تغيير الرسائل الأصلية أبدًا ، حيث سيتطلب ذلك تحديث جميع الترجمات.
ثانياً ، يعقد إدخال عدة رسائل مع النص نفسه في اللغة المصدر ، والتي يجب ترجمتها بطرق مختلفة. على سبيل المثال ، يمكن ترجمة نص الزر "فتح" وعلامة "فتح" بطرق مختلفة ، لأن النص الأول هو أمر ، والثاني وصف. يحتوي Gettext على سطر سياق
msgctxt اختياري للتمييز بين الأسطر التي لها نفس مقطع المصدر. هذا النهج يضع مسؤولية الاعتراف بمثل هذه الحالات على المطورين ، وهو ما يتعارض مع مبدأ الفصل بين المصالح.
لا يجيد Fluent إعادة استخدام النصوص لهذا السبب بالتحديد. يعد فصل النص المصدر عن الترجمات الأخرى أمرًا مهمًا أيضًا لقدرتنا على إدخال الرسائل المركبة (التي تحتوي على أسطر متعددة لوحدة ترجمة واحدة ، مرفقة بواجهة مستخدم واحدة لواجهة المستخدم) وللروابط القائمة على المعرف للرسائل.
يجيد Fluent "اتفاقية" بين المطورين والمحليين. يقوم المطور بإدخال معرف فريد ومجموعة من المتغيرات (عدد الرسائل غير المقروءة ، واسم المستخدم ، وما إلى ذلك) ، ويقرر المترجم ، باستخدام بناء جملة Fluent ، كيفية إنشاء نص الرسالة لهذا المعرف.
يجب ألا يقلق المطور بشأن التطبيق التفصيلي لترجمات هذه الرسائل. كل ما يحتاجه المطور هو الحصول على سطر نص واحد مناسب لمكان محدد في واجهة المستخدم لطلب سلسلة من معرف محدد.
خيارات الرسالة
يدعم Gettext مجموعة صغيرة من وظائف التدويل ، وخاصةً لصيغ الجمع. لكن بناء جملة الجمع هذا يمثل حالة خاصة ، بالإضافة إلى بناء جملة gettext القياسي ، ويصعب قياس الحالات الأخرى التي تتطلب تقلبات.
يدعم Fluent المفهوم الأساسي لتباين السلسلة ، والذي يمكن استخدامه مع محددات. عادةً ما تكون قاعدة الجمع عبارة عن محدد ، ولكن بناءً على الميزات النحوية للغة ، قد يكون هناك آخرون ، مثل الجنس أو الانحراف أو حتى البيئة - على سبيل المثال ، وقت اليوم أو نظام التشغيل. يسمح بناء الجملة Fluent للمواقع بتحديد كل هذه الميزات وإنشاء نص يطابق الموقف تمامًا.
الحجج الخارجية
لا يدعم Gettext الوسائط الخارجية. بمعنى آخر ، لا يمكنك تحديد تنسيق المعلمات - الأرقام والتواريخ. لتنسيق المعلمات في gettext ، يوصى بإرجاع سلسلة ، والتي سيتم تمريرها إلى
printf أو تشغيل
String.prototype.replace على السلسلة الناتجة.
في Fluent ، يكون دعم الوسائط الخارجية في صميم بناء الجملة. لا يتم استكمال الوسائط الخارجية فقط ، بل تُستخدم أيضًا كمعلمات للتحديد ، ويمكن أيضًا نقلها إلى وظائف مضمنة. هذا يسمح للمواقع المحلية بإنشاء نصوص أكثر دقة لحالات محددة. علاوة على ذلك ، يضع Fluent علامات
FSI / PDI حول الكائنات لحماية عزل الاتجاهية في النص ثنائي الاتجاه ، ويحظر أي معالجة لسلاسل الأوراق ، مما يقلل العبء على المطورين.
عزل المسؤولية
بالإضافة إلى ذلك ، تتطلب الطريقة التي يتعامل بها gettext مع القواعد التعددية من مصمم النظام اختيار ما إذا كانت الرسالة ستكون رسالة متعددة المتغيرات أو سطرًا واحدًا. من وجهة نظر Fluent ، يجب ألا يتعامل المطور مع مثل هذه المشكلات. في كثير من الحالات ، عندما يكون أحد الخيارات كافياً باللغة الإنجليزية ، في لغات أخرى ، تحتاج إلى إضافة أنواع مختلفة من صيغ الجمع.
يفترض Fluent أن المطور لا ينبغي أن يكون لديه معرفة لغوية مماثلة عند تطوير البرامج مع العديد من اللغات ، ويجب أن تتمتع كل لغة بحرية معينة في العمل أثناء الترجمة.
نتيجة لذلك ، يخزن Fluent كل ترجمة على حدة ، دون "تسريب" متطلبات لغة إلى أخرى ، ويحتفظ بجميع الترجمات "غير شفافة" لمطور لا يحتاج إلى القلق بشأن الوظائف التي قد يحتاجها المترجمون لسطر معين.
إلغاء النقل
في دورة التطوير ، هناك ثلاثة مواقف يتم فيها "إلغاء" الترجمة (تصبح غير صالحة) فيما يتعلق بالنص الأصلي:
- تغيير بسيط: لا يؤثر على الترجمة (علامات الترقيم الصحيحة ، الأخطاء المطبعية).
- تغيير متوسط: يؤثر على تصميم الرسالة ، لكنه لا يلغي صحة الترجمة المرتبطة (على سبيل المثال ، إظهار كل الإشارات المرجعية -> إظهار مدير الإشارات المرجعية ).
- تغيير كبير: المعنى الجديد للجملة ( انقر للحفظ -> انقر لفتح ).
لأسباب معمارية ، يجمع gettext جميع المستويات الثلاثة في حالة واحدة تسمى
غامض . أي تغيير في السطر المصدر (على الأقل مكتمل ، على الأقل ضئيل) يؤدي إلى إلغاء الترجمات.
في Fluent ، يتيح لك استخدام المعرفات الفريدة إبقاء مستويين من هذين المستويين منفصلين عن المستوى الثالث: عند إجراء تغييرات
صغيرة على النص المصدر لخط وعندما تحفظ المعرف ، تظل الترجمات سارية. من ناحية أخرى ، إذا قام المطور بتغيير المعرف ، فسيتم إلغاء جميع الترجمات وسوف يتطلب التحديث.
نعتقد أن مثل هذا الحل المعماري أكثر فائدة لمعظم دورات الإصدار ، على الرغم من أننا ندرك أنه بالنسبة لتغيرات المستوى
المتوسط ، سيتعين على المطور الاختيار بين حفظ المعرف أو تغييره (أي بين تغيير
بسيط وتغيير
مهم ).
نحن ندرس أيضًا فكرة تعيين
إصدار الرسائل حتى يتمكن المطور من وضع علامة على الرسالة على أنها
محدّثة دون إبطال محتوياتها تمامًا. ستسمح لك هذه الحالة بالحفاظ على الترجمة صحيحة بناءً على النقطة التي تفيد بأن الإصدار القديم للترجمة لا يزال أفضل من السلسلة غير المترجمة ، وفي الوقت نفسه سوف تسمح للأدوات بإبلاغ المترجم بالحاجة إلى تحديث الترجمة.
تنسيق البيانات
يستخدم Gettext ثلاثة تنسيقات ملفات - * .po و * .pot و * .mo. يؤثر هذا على تنفيذ gettext في دورة الإنتاج عن طريق إضافة خطوات مثل استخراج الرسائل وتجميعها.
يستخدم Fluent تنسيق ملف * .ftl واحد ، مما يسهل التنفيذ ولا يتطلب خطوات إضافية قد تؤدي إلى تباينات في البيانات.
دعم يونيكود
يمكن ترميز Gettext في UTF-8. بشكل عام ، هذا هو حيث ينتهي دعم Unicode. ويستخدم مجموعة البيانات الخاصة به لصيغ الجمع ، لا يعرف كيفية تنسيق التواريخ والأرقام ، ولا يساعد في العمل مع النصوص ثنائية الاتجاه.
يستخدم Fluent بشكل مكثف المكتبات الموحدة وخوارزميات CLDR و ICU و ECMA402 ، ويجمع بدقة بين التعريب والتدويل.
استنتاج
نعتقد أن واجهة برمجة التطبيقات (API) Fluent والبناء يمثلان تحسنا ملحوظا في gettext ، ونحن نوصي باستخدامهما للبرامج الدولية.
المزيد عن بطلاقة