استخدم مساعدك المفضل للملخص واستخدم هذه الصفحة والموفر AI الذي تريده
تاريخ الإصدارات
- "إضافة مقارنة نجوم GitHub"v8.9.818/5/2026
- "بدء التقييم القياسي"v8.7.126/1/2026
تمت ترجمة محتوى هذه الصفحة باستخدام الذكاء الاصطناعي.
اعرض آخر نسخة المحتوى الأصلي باللغة الإنكليزيةإذا كان لديك فكرة لتحسين هذه الوثيقة، فلا تتردد في المساهمة من خلال تقديم طلب سحب على GitHub.
رابط GitHub للتوثيقنسخ الـ Markdown من المستند إلى الحافظة
مكتبات i18n لـ Svelte - تقرير التقييم القياسي 2026
هذه الصفحة هي تقرير تقييم قياسي لحلول i18n على Svelte.
جدول المحتويات
التقييم القياسي التفاعلي
مرجع النتائج:
شاهد بيانات المقارنة الكاملة
راجع مستودع التقييم القياسي الكامل هنا.
مقدمة
تعد حلول التدويل من بين أثقل الاعتمادات في تطبيق Svelte. الخطر الرئيسي هو شحن محتوى غير ضروري: ترجمات لصفحات أخرى ولغات أخرى في حزمة مسار واحد.
مع نمو تطبيقك، يمكن أن تؤدي هذه المشكلة بسرعة إلى تضخم ملفات JavaScript المرسلة إلى العميل وإبطاء التنقل.
في الممارسة العملية، بالنسبة للتطبيقات الأقل تحسينًا، يمكن أن ينتهي الأمر بصفحة مدولة لتكون أثقل بعدة مرات من النسخة بدون i18n.
التأثير الآخر هو على تجربة المطور (DX): كيفية التصريح عن المحتوى، والأنواع، وتنظيم فضاء الأسماء، والتحميل الديناميكي، والتفاعل عند تغيير اللغة.
TL;DR
- Intlayer: الخيار الأكثر كفاءة في الأداء (v8.7.12) مع أصغر بصمة (footprint).
- Paraglide: منافس قوي للتخلص من الكود غير المستخدم (tree-shaking) ولكنه يمتلك تجربة مطور أكثر تعقيدًا وعبئًا في التفاعل.
- svelte-i18n: كامل ومعياري لـ Svelte، ولكنه يحمل وزن حزمة أكبر بكثير (~7 أضعاف Intlayer).
اختبر تطبيقك
لتحديد مشكلات تسرب i18n بسرعة، قمت بإعداد ماسح ضوئي مجاني متاح هنا.
المشكلة
هناك ركيزتان أساسيتان للحد من تكلفة تطبيق متعدد اللغات:
- تقسيم المحتوى حسب الصفحة / فضاء الأسماء حتى لا يتم تحميل قواميس كاملة عندما لا تحتاج إليها.
- تحميل اللغة الصحيحة ديناميكيًا، فقط عند الحاجة إليها.
فهم القيود التقنية لهذه الأساليب:
التحميل الديناميكي
بدون التحميل الديناميكي، تحتفظ معظم الحلول بالرسائل في الذاكرة منذ الريندر الأول، مما يضيف عبئًا كبيرًا للتطبيقات التي تحتوي على العديد من المسارات واللغات.
مع التحميل الديناميكي، فإنك تقبل بمقايضة: ملفات JS أولية أقل، ولكن أحيانًا طلب إضافي عند تبديل اللغة.
تقسيم المحتوى (Splitting)
تعتبر الصيغ المبنية حول t('a.b.c') مريحة للغاية ولكنها غالبًا ما تشجع على الاحتفاظ بكائنات JSON كبيرة أثناء التشغيل. هذا النموذج يجعل التخلص من الكود غير المستخدم (tree-shaking) صعبًا ما لم توفر المكتبة استراتيجية حقيقية لتقسية المحتوى لكل صفحة.
منهجية البحث
في هذا التقييم القياسي، قارنا المكتبات التالية:
Base App(بدون مكتبة i18n)svelte-intlayer(v8.7.12)svelte-i18n(v4.0.1)@inlang/paraglide-js(v2.17.0)
الإطار هو Svelte مع تطبيق متعدد اللغات يتكون من 10 صفحات و 10 لغات.
قارنا بين أربع استراتيجيات تحميل:
افتح الجدول في نافذة منبثقة لعرض جميع محتويات البيانات بوضوح
| الاستراتيجية | بدون فضاء أسماء (عام) | مع فضاء أسماء (محدد/scoped) |
|---|---|---|
| التحميل الثابت | Static: كل شيء في الذاكرة عند بدء التشغيل. | Scoped static: مقسم حسب فضاء الأسماء؛ يتم تحميل كل شيء عند البدء. |
| التحميل الديناميكي | Dynamic: تحميل عند الطلب حسب اللغة. | Scoped dynamic: تحميل دقيق حسب فضاء الأسماء واللغة. |
ملخص الاستراتيجيات
- ثابت (Static): بسيط؛ لا يوجد تأخير في الشبكة بعد التحميل الأولي. الجانب السلبي: حجم حزمة كبير.
- ديناميكي (Dynamic): يقلل الوزن الأولي (تحميل كسول). مثالي عندما يكون لديك العديد من اللغات.
- ثابت بنطاق (Scoped static): يحافظ على تنظيم الكود (فصل منطقي) بدون طلبات شبكة إضافية معقدة.
- ديناميكي بنطاق (Scoped dynamic): أفضل نهج لتقسيم الكود والأداء. يقلل من استخدام الذاكرة عن طريق تحميل ما تحتاجه الرؤية الحالية واللغة النشطة فقط.
نجوم GitHub
تعد نجوم GitHub مؤشرًا قويًا على شعبية المشروع وثقة المجتمع وأهميته على المدى الطويل. على الرغم من أنها ليست مقياسًا مباشرًا للجودة التقنية، إلا أنها تعكس عدد المطورين الذين يجدون المشروع مفيدًا ويتابعون تقدمه ومن المحتمل أن يتبنوه. لتقدير قيمة المشروع، تساعد النجوم في مقارنة الجاذبية عبر البدائل وتوفر رؤى حول نمو النظام البيئي.
النتائج بالتفصيل
1 - حلول يجب تجنبها
لا يوجد حل واضح يجب تجنبه في نظام Svelte البيئي.
2 - حلول مقبولة
(Paraglide) (@inlang/[email protected]):
يقدم Paraglide نهجًا مبتكرًا ومدروسًا جيدًا. في سياق تطبيق Vite + Svelte، يعمل التخلص من الكود غير المستخدم (tree-shaking) الذي تعلن عنه شركتهم كما هو متوقع، وهو أمر رائع.
ولكن في حالة React + TanStack Start، لم يعمل tree-shaking كما هو متوقع، والأمر نفسه بالنسبة لـ Next.js. ومع ذلك، فإن استخدام Paraglide في مشروع Svelte و TanStack Start يستحق التدقيق.
سير العمل و DX أيضًا أكثر تعقيدًا من الخيارات الأخرى.
شخصيًا، لا أحب الاضطرار إلى إعادة إنشاء ملفات JS قبل كل عملية push، مما يخلق خطرًا مستمرًا لتعارض الدمج عبر طلبات السحب (PRs). يبدو أن الأداة تركز أيضًا على Vite أكثر من Next.js.
أخيرًا، مقارنة بالحلول الأخرى، لا يستخدم Paraglide مخزنًا (مثل Svelte store) لاسترداد اللغة الحالية لريندر المحتوى. لكل عقدة يتم تحليلها، سيطلب اللغة من localStorage / cookie وما إلى ذلك. يؤدي هذا إلى تنفيذ منطق غير ضروري يؤثر على تفاعل المكونات.
ملاحظة حول paraglide: يقوم الحل بحقن الكود في قاعدة الكود الخاصة بك للاستيراد؛ ونتيجة لذلك، فإن مقياس "حجم المكتبة" في تقرير التقييم القياسي هو 0 تقريبًا. يعد إنشاء الكود (Code generation) أمرًا جيدًا، لأن الوظيفة المستخدمة ستتضمن فقط المنطق الضروري (بادئة في كل مكان مقابل لا بادئة، ملف تعريف ارتباط مقابل تخزين، إلخ). بالمقارنة، تقوم Intlayer بإجراء هذا التصفية عبر حقن متغيرات البيئة أثناء البناء لإجبار أداة التجميع على التخلص من الكود غير المستخدم للمحتوى اعتمادًا على المنطق. بفضل هذا، ينتهي الأمر بـ paraglide و intlayer كحلول أخف بـ 6 إلى 10 مرات من i18next أو next-intl.
(svelte-i18n) ([email protected]):
يلبي هذا الحل جميع احتياجات i18n في مشروع Svelte. ولكن كما هو الحال مع i18next أو غيرها من حلول i18n الرئيسية، فهي ثقيلة بعض الشيء (~15.9kb، أي حوالي 7 أضعاف svelte-intlayer).
3 - التوصيات
(Intlayer) ([email protected]):
لن أحكم شخصيًا على svelte-intlayer من أجل الموضوعية، لأنه الحل الخاص بي.
ملاحظة شخصية
هذه الملاحظة شخصية ولا تؤثر على نتائج التقييم القياسي. ومع ذلك، في عالم i18n غالبًا ما ترى إجماعًا حول نمط مثل const t = useTranslation('xx') + <>{t('xx.xx')}</> للمحتوى المترجم.
في تطبيقات Svelte، يعد حقن وظيفة كـ Slot في نظري نمطًا مضادًا (anti-pattern). كما أنه يضيف تعقيدًا يمكن تجنبه وعبئًا في تنفيذ JavaScript (حتى لو كان بالكاد يلاحظ).