مكتبات i18n لـ TanStack Start - تقرير مقارنة 2026

هذه الصفحة عبارة عن تقرير مقارنة لحلول i18n على TanStack Start.

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

مقارنة تفاعلية

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

شاهد بيانات المقارنة الكاملة

شاهد مستودع المقارنة الكامل هنا.

مقدمة

تعد حلول التدويل من بين أثقل الاعتمادات (dependencies) في تطبيق React. في TanStack Start، يتمثل الخطر الرئيسي في شحن محتوى غير ضروري: ترجمات لصفحات أخرى ولغات أخرى في حزمة مسار واحد.

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

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

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

TL;DR

• Intlayer: يوفر أفضل أداء وأصغر حجم للحزمة (v8.7.12) لـ TanStack Start.
• react-i18next و use-intl: بدائل ناضجة مع أنظمة بيئية كبيرة، ولكنها أثقل بكثير وأكثر تعقيدًا في التحسين.
• Paraglide: فكرة مبتكرة لـ tree-shaking لكنها لا تعمل في الممارسة العملية. تجربة مطور (DX) معقدة وعبء تفاعلي في TanStack Start.
• تجنب: General Translation (GT) و Lingo.dev بسبب مشكلات الأداء الخطيرة، وقيود حصة الذكاء الاصطناعي، والارتباط بالبائع (vendor lock-in).

اختبر تطبيقك

لاكتشاف مشكلات تسرب i18n بسرعة، قمت بإعداد ماسح ضوئي مجاني متاح هنا.

المشكلة

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

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

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

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

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

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

تقسيم المحتوى

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

المنهجية

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

• Base App (بدون مكتبة i18n)
• react-intlayer (v8.7.12)
• react-i18next (v17.0.2)
• use-intl (v4.9.1)
• @lingui/core (v5.3.0)
• @inlang/paraglide-js (v2.15.1)
• @tolgee/react (v7.0.0)
• react-intl (v10.1.1)
• wuchale (v0.22.11)
• gt-react (vlatest)
• lingo.dev (v0.133.9)

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

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

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

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

نجوم GitHub

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

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

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

من الواضح أن بعض الحلول، مثل gt-react أو lingo.dev ، يجب الابتعاد عنها. فهي تجمع بين الارتباط بالبائع وتشويه الكود الخاص بك. والأسوأ من ذلك: رغم قضاء ساعات عديدة في محاولة تنفيذها، إلا أنني لم أتمكن من جعلها تعمل بشكل صحيح على TanStack Start (على غرار Next.js مع gt-next).

المشكلات التي تمت مواجهتها:

(General Translation) (gt-react@latest):

• بالنسبة لتطبيق بحجم حوالي 110 كيلوبايت، يمكن لـ gt-react إضافة أكثر من 440 كيلوبايت إضافية (القدر المشاهد في تنفيذ Next.js في نفس المقارنة).
• Quota Exceeded, please upgrade your plan في أول بناء للمشروع.
• لا يتم رندرة الترجمات؛ أحصل على خطأ Error: <T> used on the client-side outside of <GTProvider> ، والذي يبدو أنه خلل في المكتبة.
• أثناء تنفيذ gt-tanstack-start-react ، صادفت أيضًا مشكلة في المكتبة: does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser ، والتي أدت إلى تعطل التطبيق. بعد الإبلاغ عن هذه المشكلة، قام المطور بإصلاحها في غضون 24 ساعة.
• تستخدم هذه المكتبات نمطًا مضادًا من خلال دالة initializeGT() ، مما يمنع الحزمة من أن يتم مسحها برمجياً بشكل نظيف.

(Lingo.dev) ([email protected]):

• تجاوز حصة الذكاء الاصطناعي (أو حظر الاعتماد على الخادم)، مما يجعل البناء / الإنتاج محفوفًا بالمخاطر دون دفع مبالغ مالية.
• كان المترجم يفتقد إلى ما يقرب من 40% من المحتوى المترجم. اضطررت لإعادة كتابة جميع .map إلى كتل مكونات مسطحة لجعلها تعمل.
• واجهة السطر البرمجي (CLI) مليئة بالأخطاء وكانت تعيد ضبط ملف الإعدادات بدون سبب.
• عند البناء، قامت بمسح ملفات JSON التي تم إنشاؤها تمامًا عندما كان هناك محتوى جديد مضاف. ونتيجة لذلك، يمكن لعدد قليل من المفاتيح مسح المئات من المفاتيح الموجودة.
• واجهت مشكلات في التفاعلية مع المكتبة على TanStack Start: عند تغيير اللغة، كان علي فرض إعادة رندرة المزود لجعلها تعمل.

2 - حلول تجريبية

(Wuchale) ([email protected]):

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

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

(Paraglide) (@inlang/[email protected]):

يقدم Paraglide نهجًا مبتكرًا ومدروسًا جيدًا. ومع ذلك، في هذه المقارنة، لم تعمل ميزة Tree-shaking التي تروج لها شركتهم في تنفيذ Next.js أو TanStack Start. كما أن سير العمل وتجربة المطور أكثر تعقيدًا من الخيارات الأخرى. أنا شخصياً لست معجباً بضرورة إعادة إنشاء ملفات JS قبل كل رفع للكود، مما يخلق خطراً دائماً لتضارب الدمج بين المطورين.

ملاحظة حول paraglide: يقوم هذا الحل بحقن الكود في قاعدة الكود الخاصة بك لعمليات الاستيراد، ونتيجة لذلك فإن مقياس 'lib size' في تقرير المقارنة هو 0 تقريبًا. توليد الكود (Code generation) أمر جيد، لأن الدالة المستخدمة ستشمل فقط المنطق الضروري (البادئة للكل مقابل عدم وجود بادئة، الكوكيز مقابل التخزين، إلخ). في المقابل، يقوم Intlayer بمعالجة هذا الفلترة باستخدام حقن متغيرات البيئة في البناء لإجبار أداة التجميع (bundler) على عمل tree-shake للمحتوى اعتمادًا على المنطق. بفضل هذا، ينتهي الأمر بـ paraglide و intlayer بكونهما حلولًا أخف بـ 6 إلى 10 مرات من i18next أو next-intl.

(Tolgee) (@tolgee/[email protected]):

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

في TanStack Start، واجهت أيضًا مشكلات في التفاعلية: عند تغيير اللغة، كان علي فرض إعادة رندرة المزود والاشتراك في أحداث تغيير اللغة حتى يعمل التحميل بلغة أخرى بشكل صحيح.

(use-intl) ([email protected]):

يعد use-intl الجزء الأكثر رواجاً في نظام React (من نفس عائلة next-intl) وغالباً ما تدعمه أنظمة الذكاء الاصطناعي، ولكن في نظري بشكل خاطئ في بيئة تعطي الأولوية للأداء. البدء بسيط إلى حد ما، ولكن في الممارسة العملية، فإن عملية التحسين والحد من التسرب معقدة للغاية. وبالمثل، فإن الجمع بين التحميل الديناميكي + مساحات الأسماء + أنواع TypeScript يبطئ التطوير كثيراً.

في TanStack Start، تتجنب الفخاخ الخاصة بـ Next.js (setRequestLocale ، الرندرة الستاتيكية) ، لكن المشكلة الأساسية هي نفسها: بدون انضباط صارم، تحمل الحزمة بسرعة كبيرة العديد من الرسائل وتصبح صيانة مساحة الأسماء لكل مسار مؤلمة.

(react-i18next) ([email protected]):

ربما يكون react-i18next هو الخيار الأكثر شعبية لأنه كان من أوائل الذين خدموا احتياجات i18n لتطبيقات JavaScript. كما يحتوي على مجموعة واسعة من إضافات المجتمع لمشكلات محددة.

ومع ذلك، فإنه يشارك نفس السلبيات الرئيسية مثل الواجهات المبنية على t('a.b.c') : التحسينات ممكنة ولكنها تستهلك وقتاً طويلاً جداً، والمشاريع الكبيرة تخاطر بممارسات سيئة (مساحات أسماء + تحميل ديناميكي + أنواع).

تختلف تنسيقات الرسائل أيضاً: يستخدم use-intl تنسيق ICU MessageFormat، بينما يستخدم i18next تنسيقه الخاص - مما يعقد الأدوات أو عمليات النقل إذا قمت بخلطهما.

(Lingui) (@lingui/[email protected]):

غالبًا ما يتم الإشادة بـ Lingui. أنا شخصيًا وجدت سير العمل حول lingui extract / lingui compile أكثر تعقيدًا من المناهج الأخرى، دون ميزة واضحة في اختبار TanStack Start هذا. لاحظت أيضًا صياغات غير متسقة تربك الذكاء الاصطناعي (مثل t() و t'' و i18n.t() و <Trans>).

(react-intl) ([email protected]):

يعد react-intl تنفيذاً عالي الأداء من فريق Format.js. تظل تجربة المطور مطولة: const intl = useIntl() + intl.formatMessage({ id: "xx.xx" }) يضيف تعقيداً وعملاً إضافياً على JavaScript ويربط مثيل i18n العالمي بالعديد من العقد في شجرة React.

4 - التوصيات

لا يوجد لهذا الاختبار في TanStack Start مكافئ مباشر لـ next-translate (إضافة Next.js + getStaticProps). بالنسبة للفرق التي تريد حقاً واجهة برمجة تطبيقات بأسلوب t() مع نظام ناضج، يظل react-i18next و use-intl خيارات "معقولة"، ولكن توقع استثمار الكثير من الوقت في التحسين لتجنب التسرب.

(Intlayer) ([email protected]):

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

ملاحظة شخصية

هذه الملاحظة شخصية ولا تؤثر على نتائج المقارنة. ومع ذلك، في عالم i18n، غالبًا ما ترى إجماعًا حول نمط مثل const t = useTranslation('xx') + <>{t('xx.xx')}</> للمحتوى المترجم.

في تطبيقات React، يعد حقن دالة كـ ReactNode ، في نظري، نمطًا مضادًا. كما أنه يضيف تعقيدًا يمكن تجنبه وعبئًا على تنفيذ JavaScript (حتى لو كان غير ملحوظ تقريبًا).