الحجج المؤيدة والمعارضة للتدويل المعتمد على المترجم

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

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

ولكن كما هو الحال مع جميع التجريدات في هندسة البرمجيات، يأتي السحر بثمن.

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

لمحة تاريخية عن الترجمة

لفهم مكاننا الحالي، علينا أن ننظر إلى الوراء حيث بدأنا.

حوالي عامي 2011–2012، كان مشهد JavaScript مختلفًا تمامًا. لم تكن أدوات التجميع كما نعرفها اليوم (Webpack، Vite) موجودة أو كانت في مراحلها الأولى. كنا نلصق السكريبتات معًا في المتصفح. في هذه الحقبة، وُلدت مكتبات مثل i18next.

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

تقدم سريعًا إلى اليوم. لدينا مترجمات قوية (SWC، أدوات تجميع مبنية على Rust) يمكنها تحليل أشجار البنية المجردة (AST) في غضون مللي ثانية. هذه القوة ولدت فكرة جديدة: لماذا ندير المفاتيح يدويًا؟ لماذا لا يستطيع المترجم فقط رؤية النص "Hello World" واستبداله لنا؟

وهكذا وُلدت الترجمة المعتمدة على المترجم (Compiler-based i18n).

جاذبية المترجم (النهج "السحري")

هناك سبب يجعل هذا النهج الجديد شائعًا. بالنسبة للمطور، تكون التجربة مذهلة.

1. السرعة و"التدفق"

عندما تكون في حالة تركيز، التوقف للتفكير في اسم متغير (home_hero_title_v2) يكسر تدفقك. مع نهج المترجم، تكتب <p>Welcome back</p> وتتابع العمل. الاحتكاك معدوم.

2. مهمة إنقاذ التراث

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

3. عصر الذكاء الاصطناعي

هذه فائدة حديثة لا ينبغي أن نتجاهلها. مساعدو البرمجة بالذكاء الاصطناعي (مثل Copilot أو ChatGPT) يولدون بشكل طبيعي JSX/HTML قياسي. هم لا يعرفون مخطط مفاتيح الترجمة الخاص بك.

• إعلاني: عليك إعادة كتابة مخرجات الذكاء الاصطناعي لاستبدال النص بالمفاتيح.
• المترجم: تقوم بنسخ ولصق كود الذكاء الاصطناعي، ويعمل مباشرة.

فحص الواقع: لماذا "السحر" خطير

بينما يبدو "السحر" جذابًا، فإن التجريد يتسرب. الاعتماد على أداة بناء لفهم نية الإنسان يُدخل هشاشة معمارية.

1. هشاشة الاستدلال (لعبة التخمين)

يجب على المترجم أن يخمن ما هو المحتوى وما هو الكود.

• هل يتم ترجمة className="active"؟ إنها سلسلة نصية.
• هل يتم ترجمة status="pending"؟
• هل يتم ترجمة <MyComponent errorMessage="An error occurred" />؟
• هل يتم ترجمة معرف منتج مثل "AX-99"؟

في النهاية، ستجد نفسك "تقاتل" المترجم، مضيفًا تعليقات محددة (مثل // ignore-translation) لمنعه من كسر منطق تطبيقك.

2. الحد الصعب للبيانات الديناميكية

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

3. "انفجار القطع" وشلالات الشبكة

للسماح بعملية tree-shaking، غالبًا ما تقوم أدوات المترجم بتقسيم الترجمات حسب المكون.

• النتيجة: قد يؤدي عرض صفحة واحدة تحتوي على 50 مكونًا صغيرًا إلى تفعيل 50 طلب HTTP منفصل لقطع ترجمة صغيرة. حتى مع HTTP/2، يخلق هذا شلالًا في الشبكة يجعل تطبيقك يبدو بطيئًا مقارنة بتحميل حزمة لغة واحدة محسّنة.

4. العبء على أداء وقت التشغيل

لجعل الترجمات تفاعلية (حتى يتم تحديثها فورًا عند تبديل اللغات)، غالبًا ما يقوم المترجم بحقن خطافات إدارة الحالة في كل مكون.

• التكلفة: إذا قمت بعرض قائمة تحتوي على 5000 عنصر، فأنت تقوم بتهيئة 5000 من خطافات useState و useEffect فقط للنصوص. هذا يستهلك الذاكرة ودورات وحدة المعالجة المركزية التي توفرها المكتبات التصريحية (التي تستخدم عادة مزود Context واحد).

الفخ: التقييد بالبائع

هذا ربما يكون أخطر جانب في التدويل المعتمد على المترجم.

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

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

الجانب الآخر: مخاطر النهج التصريحي

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

1. جحيم المساحات الاسمية: غالبًا ما يتعين عليك إدارة ملفات JSON التي يجب تحميلها يدويًا (common.json، dashboard.json، footer.json). إذا نسيت واحدًا، سيرى المستخدم المفاتيح الخام.
2. التحميل الزائد: بدون تكوين دقيق، من السهل جدًا تحميل جميع مفاتيح الترجمة الخاصة بك لـ جميع الصفحات عند التحميل الأولي، مما يزيد من حجم الحزمة.
3. انحراف التزامن: من الشائع أن تبقى المفاتيح في ملف JSON لفترة طويلة بعد حذف المكون الذي يستخدمها. تنمو ملفات الترجمة الخاصة بك بلا حدود، مليئة بـ "مفاتيح الزومبي".

الحل الوسط مع Intlayer

هنا تحاول أدوات مثل Intlayer الابتكار. يفهم Intlayer أنه بينما المترجمات قوية، فإن السحر الضمني خطير.

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

هذا يمنحك أفضل ما في العالمين:

1. الدقة: تحتفظ بترجماتك قريبة من مكوناتك (محسنًا التجزئة وإزالة الشجر).
2. الأمان: تصبح الترجمة كودًا صريحًا، وليس سحرًا مخفيًا في وقت البناء.
3. عدم القفل: نظرًا لأن الكود يتم تحويله إلى هيكل إعلاني قياسي داخل مستودعك، فلن تخفي المنطق في إضافة webpack.

الخلاصة

فأي منهما يجب أن تختار؟

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

إذا كنت تبني تطبيقًا احترافيًا على مستوى المؤسسات: السحر عادةً ما يكون فكرة سيئة. تحتاج إلى السيطرة.

• تحتاج إلى التعامل مع البيانات الديناميكية من الخلفيات.
• تحتاج إلى ضمان الأداء على الأجهزة منخفضة المواصفات (تجنب انفجارات الـ hooks).
• تحتاج إلى التأكد من أنك لست مقيدًا بأداة بناء معينة إلى الأبد.

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