مكتبات i18n لـ Vue - تقرير التقييم القياسي 2026

هذه الصفحة هي تقرير تقييم قياسي لحلول i18n على Vue.

جدول المحتويات

التقييم القياسي التفاعلي

مرجع النتائج:

مقدمة

تعد حلول التدويل من بين أثقل الاعتمادات في تطبيق Vue. الخطر الرئيسي هو شحن محتوى غير ضروري: ترجمات لصفحات أخرى ولغات أخرى في حزمة مسار واحد.

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

في الممارسة العملية، بالنسبة للتطبيقات الأقل تحسينًا، يمكن أن ينتهي الأمر بصفحة مدولة لتكون أثقل بعدة مرات من النسخة بدون i18n.

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

لفهم أصل هذه المكتبات، اقرأ تاريخ i18n في JavaScript.

TL;DR

• Intlayer: الحل الأخف وزنًا (v9.5.10) مع ميزة النطاق (scoping) والتحميل الديناميكي المدمجة.
• Tolgee: تحميل ديناميكي فعال بدون أي تسريب في الوضع الديناميكي، ولكنه أثقل (~3.0× Intlayer) ويفتقر إلى أمان الأنواع المدمج في وقت التحويل البرمجي.
• vue-i18n: المعيار الصناعي مع نظام بيئي غني، ولكنه قد يصبح أثقل بكثير ويصعب تحسينه لتقسيم الكود في التطبيقات الكبيرة.
• fluent-vue: تنظيم مبتكر للرسائل ولكنه يفتقر إلى سلامة النوع (type-safety) ويعد حلاً ثقيلًا للغاية.

اختبر تطبيقك

لتحديد مشكلات تسرب i18n بسرعة، يمكنك تجربة الماسح الضوئي لـ i18n SEO المجاني.

المشكلة

هناك ركيزتان أساسيتان للحد من تكلفة تطبيق متعدد اللغات:

• تقسيم المحتوى حسب الصفحة / فضاء الأسماء حتى لا يتم تحميل قواميس كاملة عندما لا تحتاج إليها.
• تحميل اللغة الصحيحة ديناميكيًا، فقط عند الحاجة إليها.

فهم القيود التقنية لهذه الأساليب:

التحميل الديناميكي

بدون التحميل الديناميكي، تحتفظ معظم الحلول بالرسائل في الذاكرة منذ الريندر الأول، مما يضيف عبئًا كبيرًا للتطبيقات التي تحتوي على العديد من المسارات واللغات.

مع التحميل الديناميكي، فإنك تقبل بمقايضة: ملفات JS أولية أقل، ولكن أحيانًا طلب إضافي عند تبديل اللغة.

تقسيم المحتوى (Splitting)

تعتبر الصيغ المبنية حول const { t } = useI18n() + t('a.b.c') مريحة للغاية ولكنها غالبًا ما تشجع على الاحتفاظ بكائنات JSON كبيرة أثناء التشغيل. هذا النموذج يجعل التخلص من الكود غير المستخدم (tree-shaking) صعبًا ما لم توفر المكتبة استراتيجية حقيقية لتقسيم المحتوى لكل صفحة.

منهجية البحث

في هذا التقييم القياسي، قارنا المكتبات التالية:

• Base App (بدون مكتبة i18n)
• vue-intlayer (v9.5.10)
• @intlayer/vue-i18n (v9.5.10)
• vue-i18n (v11.4.0)
• fluent-vue (v3.8.2)
• @tolgee/vue (v7.2.0)

الإطار هو Vue مع تطبيق متعدد اللغات يتكون من 10 صفحات و 10 لغات.

قارنا بين أربع استراتيجيات تحميل:

ملخص الاستراتيجيات

• ثابت (Static): بسيط؛ لا يوجد تأخير في الشبكة بعد التحميل الأولي. الجانب السلبي: حجم حزمة كبير.
• ديناميكي (Dynamic): يقلل الوزن الأولي (تحميل كسول). مثالي عندما يكون لديك العديد من اللغات.
• ثابت بنطاق (Scoped static): يحافظ على تنظيم الكود (فصل منطقي) بدون طلبات شبكة إضافية معقدة.
• ديناميكي بنطاق (Scoped dynamic): أفضل نهج لتقسيم الكود والأداء. يقلل من استخدام الذاكرة عن طريق تحميل ما تحتاجه الرؤية الحالية واللغة النشطة فقط.

ما قمت بقياسه:

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

• حجم مكتبة التدويل: بعد التجميع والتخلص من الكود غير المستخدم والتصغير، يكون حجم مكتبة i18n هو حجم كود المزودين (providers) والمكونات البرمجية (composables) في مكون فارغ. لا يشمل ذلك تحميل ملفات الترجمة. إنه يوضح مدى "تكلفة" المكتبة قبل دخول المحتوى الخاص بك.

• JavaScript لكل صفحة: لكل مسار في التقييم، مقدار البرامج النصية التي يسحبها المتصفح لتلك الزيارة، بمتوسط عبر الصفحات في المجموعة (وعبر اللغات). الصفحات الثقيلة هي صفحات بطيئة.

• التسرب من اللغات الأخرى (Leakage): هو محتوى نفس الصفحة ولكن بلغة أخرى يتم تحميله بالخطأ في الصفحة التي يتم فحصها. هذا المحتوى غير ضروري ويجب تجنبه (مثلاً: محتوى صفحة /fr/about في حزمة صفحة /en/about).

• التسرب من المسارات الأخرى: نفس الفكرة لـ الشاشات الأخرى في التطبيق: ما إذا كانت نصوصها مرافقة عندما تفتح صفحة واحدة فقط. (مثلاً: محتوى صفحة /en/about في حزمة صفحة /en/contact). تشير النتيجة العالية إلى ضعف التقسيم أو الحزم الواسعة جدًا.

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

• استجابة تبديل اللغة: أقوم بتبديل اللغة باستخدام أداة التحكم الخاصة بالتطبيق وأحسب الوقت المستغرق حتى تتحول الصفحة بوضوح، وهو ما سيلاحظه الزائر.

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

• وقت تحميل الصفحة الأولي: من التنقل حتى يعتبر المتصفح الصفحة محملة بالكامل للسيناريوهات التي اختبرتها. جيد لمقارنة البدايات الباردة.

• وقت الهيدرة (Hydration): الوقت الذي يقضيه العميل في تحويل HTML الخادم إلى واجهة تفاعلية. تعني الشرطة في الجداول أن هذا التنفيذ لم يوفر رقم هيدرة موثوقًا به في هذا التقييم.

نجوم GitHub

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

نشاط الالتزامات (commits)

تعكس النجوم الشعبية، بينما تعكس الالتزامات حجم العمل المبذول في المشروع. عند كتابة هذا المقال، يضم Intlayer نحو 7,500 التزام، أي أكثر من معظم المكتبات المقارنة هنا، ونحو 5 أضعاف next-intl أو next-i18next.

Intlayer مستودع أحادي (monorepo)، لذا يشمل هذا العدد كل حزم أطر العمل وأداة CLI والتوثيق. اقرأ الالتزامات كمؤشر على النشاط، لا على الجودة.

تنزيلات npm

تكافئ أعداد التنزيل الحلول الأقدم، لا الأفضل. فالمكتبة التي صدرت قبل سنوات لا تزال تُثبَّت في كل مشروع اختارها آنذاك، وفي كل تشغيل لـ CI، وفي كل حزمة تعتمد عليها. هذا الرقم يقيس الجمود أكثر مما يقيس اختيارًا جديدًا.

تضخّم مساعدات الذكاء الاصطناعي هذا الأثر. فـ next-intl وi18next وvue-i18n منتشرة في الشيفرة التي تدربت عليها، لذا تقترحها افتراضيًا دون مقارنة البدائل. كل اقتراح يضيف تنزيلات، تغذي بدورها الاقتراح التالي. قارن بناءً على الاختبار المعياري لا على عدد التنزيلات.

النتائج بالتفصيل

1 - حلول يجب تجنبها

لا يوجد حل واضح يجب تجنبه في نظام Vue البيئي.

2 - حلول مقبولة

(Tolgee) (@tolgee/vue@7.2.0):

يعالج Tolgee العديد من المشاكل المذكورة سابقاً، حيث يقدم تحميلاً ديناميكياً يقضي بنجاح على تسريب اللغات والصفحات (مما يقلل حجم JS للصفحة إلى حوالي 58.8 كيلوبايت). ومع ذلك، فإنه لا يوفر أمان الأنواع المدمج في وقت التحويل البرمجي للمفاتيح، مما يزيد من صعوبة اكتشاف المفاتيح المفقودة. بالإضافة إلى ذلك، فإن حجم المكتبة ثقيل نسبياً (~13.8 كيلوبايت، أي حوالي 3.7 أضعاف vue-intlayer).

(vue-i18n) (vue-i18n@11.4.0):

• vue-i18n هي بدون منازع مكتبة i18n الأكثر استخدامًا لـ Vue، فهي تحتوي على الكثير من الميزات ونظام بيئي ضخم. ولكن تحت الغطاء، الحل ثقيل نوعًا ما. حتى لو قامت vue-i18n بدمج التحميل الكسول للرسائل، فإنها تفتقر إلى ميزة النطاق (scoping). في حالة تطبيق Vue SPA كلاسيكي، لا توجد مشكلة، ولكن بالنسبة لتطبيق Nuxt، باستخدام @nuxt/i18n، فإنه يؤدي إلى تضمين الرسائل من جميع الصفحات في صفحة واحدة. بالنسبة لتطبيق Nuxt كبير يضم أكثر من 10 صفحات، يمكن أن يصبح الأمر إشكاليًا حقًا.

الحزمة ثقيلة جدًا (~24.1 kb، أي حوالي 6.5 أضعاف vue-intlayer).

(fluent-vue) (fluent-vue@3.8.2):

• fluent-vue يقدم محاولة ابتكار من خلال تنسيق .ftl. تنظيم الرسائل رائع، وأسهل في البدء. ولكن في الممارسة العملية، يؤدي نقص سلامة النوع إلى زيادة خطر الخطأ ويمكن أن يصبح استهلاك الوقت في تصحيح الأخطاء سريعًا. علاوة على ذلك، يقوم هذا الحل بتحميل الرسائل باستخدام مكون vite الإضافي الذي يفرض تحميل كل المحتوى بجميع اللغات في كل صفحة. بالإضافة إلى ذلك، هذا حل ثقيل للغاية (~92.7kb، أي حوالي 7.5 ضعف vue-intlayer).

3 - التوصيات

(Intlayer) (vue-intlayer@9.5.10):

لن أحكم شخصيًا على vue-intlayer من أجل الموضوعية، لأنه الحل الخاص بي.