Vue i18n पुस्तकालय - 2026 बेंचमार्क रिपोर्ट

यह पृष्ठ Vue पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।

विषय सूची

इंटरैक्टिव बेंचमार्क

परिणाम संदर्भ:

परिचय

Vue ऐप में अंतर्राष्ट्रीयकरण (Internationalisation) समाधान सबसे भारी निर्भरताओं में से हैं। मुख्य जोखिम अनावश्यक सामग्री भेजने का है: एक ही रूट के बंडल में अन्य पृष्ठों और अन्य लोकेल्स के अनुवाद शामिल करना।

जैसे-जैसे आपका ऐप बढ़ता है, यह समस्या क्लाइंट को भेजे जाने वाले JavaScript को तेज़ी से बढ़ा सकती है और नेविगेशन को धीमा कर सकती है।

व्यवहार में, कम से कम अनुकूलित कार्यान्वयन के लिए, एक अंतर्राष्ट्रीयकृत पृष्ठ बिना i18n वाले संस्करण की तुलना में कई गुना भारी हो सकता है।

दूसरा प्रभाव डेवलपर अनुभव (DX) पर पड़ता है: आप सामग्री, प्रकार (types), नेमस्पेस संगठन, डायनेमिक लोडिंग और लोकेल बदलने पर प्रतिक्रियाशीलता को कैसे घोषित करते हैं।

ये लाइब्रेरी कहाँ से आईं, यह समझने के लिए JavaScript i18n का इतिहास पढ़ें।

TL;DR

• Intlayer: मूल स्कोपिंग (scoping) और डायनेमिक लोडिंग के साथ सबसे हल्का समाधान (v9.5.10)।
• Tolgee: डायनामिक मोड में शून्य लीकेज के साथ प्रभावी डायनामिक लोडिंग, लेकिन भारी (~3.0× Intlayer) और कंपाइल-टाइम टाइप सेफ्टी का अभाव है।
• vue-i18n: एक समृद्ध पारिस्थितिकी तंत्र के साथ उद्योग मानक, लेकिन बड़े अनुप्रयोगों में महत्वपूर्ण रूप से भारी हो सकता है और कोड-स्प्लिटिंग के लिए अनुकूलित करना कठिन हो सकता है।
• fluent-vue: अभिनव संदेश संगठन लेकिन इसमें टाइप-सेफ्टी की कमी है और यह एक अत्यंत भारी समाधान साबित होता है।

अपने ऐप का परीक्षण करें

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): यह उसी पृष्ठ की सामग्री है लेकिन दूसरी भाषा में जो ऑडिट किए गए पृष्ठ में गलती से लोड हो जाएगी। यह सामग्री अनावश्यक है और इससे बचा जाना चाहिए (उदा: /en/about पृष्ठ बंडल में /fr/about पृष्ठ सामग्री)।

• अन्य रूट्स से लीकेज: ऐप में अन्य स्क्रीन के लिए भी यही विचार: क्या उनकी प्रतिलिपि तब आ रही है जब आपने केवल एक पृष्ठ खोला है (उदा: /en/contact पृष्ठ बंडल में /en/about पृष्ठ सामग्री)। एक उच्च स्कोर कमजोर विभाजन या अत्यधिक व्यापक बंडलों का संकेत देता है।

• औसत घटक बंडल आकार: सामान्य UI टुकड़ों को एक विशाल ऐप नंबर के अंदर छिपाने के बजाय एक बार में एक मापा जाता है। यह दिखाता है कि क्या अंतर्राष्ट्रीयकरण चुपचाप रोजमर्रा के घटकों को फुलाता है। उदाहरण के लिए, यदि आपका घटक फिर से रेंडर होता है, तो यह मेमोरी से वह सारा डेटा लोड करेगा। किसी भी घटक के साथ एक विशाल JSON संलग्न करना अप्रयुक्त डेटा के एक बड़े स्टोर को जोड़ने जैसा है जो आपके घटकों के प्रदर्शन को धीमा कर देगा।

• भाषा स्विच प्रतिक्रियाशीलता: मैं ऐप के अपने नियंत्रण का उपयोग करके भाषा बदलता हूं और समय मापता हूं जब तक कि पृष्ठ स्पष्ट रूप से स्विच नहीं हो जाता, जो एक विज़िटर नोटिस करेगा।

• भाषा परिवर्तन के बाद रेंडरिंग कार्य: एक सूक्ष्म अनुवर्ती: स्विच होने के बाद इंटरफ़ेस ने नई भाषा के लिए फिर से पेंट करने के लिए कितना प्रयास किया। उपयोगी है जब "महसूस किया गया" समय और फ्रेमवर्क लागत अलग-अलग होती है।

• प्रारंभिक पृष्ठ लोड समय: नेविगेशन से ब्राउज़र द्वारा मेरे द्वारा परीक्षण किए गए परिदृश्यों के लिए पृष्ठ को पूरी तरह से लोड मानने तक। कोल्ड स्टार्ट की तुलना करने के लिए अच्छा है।

• हाइड्रेशन समय (Hydration): ग्राहक सर्वर HTML को एक इंटरैक्टिव इंटरफ़ेस में बदलने में कितना समय बिताता है। तालिकाओं में एक डैश का अर्थ है कि उस कार्यान्वयन ने इस बेंचमार्क में एक विश्वसनीय हाइड्रेशन आंकड़ा प्रदान नहीं किया।

GitHub सितारे

GitHub सितारे किसी प्रोजेक्ट की लोकप्रियता, सामुदायिक विश्वास और दीर्घकालिक प्रासंगिकता का एक मजबूत संकेतक हैं। हालांकि यह तकनीकी गुणवत्ता का प्रत्यक्ष माप नहीं है, वे दर्शाते हैं कि कितने डेवलपर्स प्रोजेक्ट को उपयोगी पाते हैं, इसकी प्रगति का पालन करते हैं, और इसे अपनाने की संभावना रखते हैं। किसी प्रोजेक्ट के मूल्य का अनुमान लगाने के लिए, सितारे विकल्पों के बीच कर्षण की तुलना करने में मदद करते हैं और पारिस्थितिकी तंत्र के विकास में अंतर्दृष्टि प्रदान करते हैं।

कमिट गतिविधि

स्टार लोकप्रियता दिखाते हैं। कमिट दिखाते हैं कि किसी प्रोजेक्ट में कितना काम लगा है। लिखते समय Intlayer में लगभग 7,500 कमिट हैं, जो यहाँ तुलना की गई अधिकांश लाइब्रेरी से ज़्यादा हैं और next-intl या next-i18next से लगभग 5 गुना।

Intlayer एक मोनोरेपो है, इसलिए इस संख्या में हर फ़्रेमवर्क पैकेज, CLI और डॉक्स शामिल हैं। कमिट को गुणवत्ता नहीं, गतिविधि का संकेत मानें।

npm डाउनलोड

डाउनलोड सबसे पुराने समाधानों को पुरस्कृत करते हैं, सबसे अच्छे को नहीं। वर्षों पहले जारी हुई लाइब्रेरी आज भी हर उस प्रोजेक्ट में इंस्टॉल होती है जिसने उसे तब चुना था, हर CI रन में और हर उस पैकेज में जो उस पर निर्भर है। यह संख्या नए चुनाव से ज़्यादा जड़ता को मापती है।

AI असिस्टेंट इस प्रभाव को और बढ़ाते हैं। next-intl, i18next और vue-i18n उस कोड में हर जगह हैं जिस पर वे प्रशिक्षित हुए, इसलिए वे विकल्पों की तुलना किए बिना इन्हें डिफ़ॉल्ट रूप से सुझाते हैं। हर सुझाव डाउनलोड बढ़ाता है, जो अगले सुझाव को बढ़ावा देता है। डाउनलोड की संख्या नहीं, बेंचमार्क के आधार पर तुलना करें।

विवरण में परिणाम

1 - बचने के लिए समाधान

Vue पारिस्थितिकी तंत्र में बचने के लिए कोई स्पष्ट समाधान नहीं है।

2 - स्वीकार्य समाधान

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

Tolgee पहले उल्लेखित कई मुद्दों को संबोधित करता है, डायनामिक लोडिंग की पेशकश करता है जो लोकेल और पेज लीकेज को सफलतापूर्वक समाप्त करता है (पेज JS को घटाकर लगभग 58.8kb करता है)। हालांकि, यह कीज़ के लिए कंपाइल-टाइम टाइप सेफ्टी प्रदान नहीं करता है, जिससे गायब कीज़ को पकड़ना कठिन हो जाता है। इसके अलावा, लाइब्रेरी का आकार अपेक्षाकृत भारी है (~13.8kb, जो कि vue-intlayer से लगभग 3.7 गुना है)।

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

• vue-i18n निस्संदेह Vue के लिए सबसे अधिक उपयोग किया जाने वाला i18n पुस्तकालय है, इसमें बहुत सारी विशेषताएं और एक विशाल पारिस्थितिकी तंत्र है। लेकिन हुड के तहत समाधान काफी भारी है। भले ही vue-i18n संदेशों के लिए लेज़ी लोडिंग को एकीकृत करता है, लेकिन इसमें स्कोपिंग सुविधा की कमी है। एक क्लासिक Vue SPA ऐप के मामले में कोई समस्या नहीं है, लेकिन @nuxt/i18n का उपयोग करने वाले nuxt ऐप के लिए, यह सभी पृष्ठों के संदेशों को एक ही पृष्ठ में शामिल करने की ओर ले जाता है। 10 से अधिक पृष्ठों वाले बड़े nuxt ऐप के लिए, यह वास्तव में समस्याग्रस्त हो सकता है।

पैकेज बहुत भारी है (~24.1 kb, जो vue-intlayer से लगभग 6.5 गुना है)।

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

• fluent-vue .ftl प्रारूप के माध्यम से एक अभिनव प्रयास प्रदान करता है। संदेश संगठन महान है, शुरू करना आसान है। लेकिन व्यवहार में, टाइप-सेफ्टी की कमी त्रुटि के जोखिम को बढ़ाती है और डिबग करने में जल्दी से समय लग सकता है। इसके अलावा, वह समाधान एक vite प्लगइन का उपयोग करके संदेशों को लोड करता है जो प्रत्येक पृष्ठ में सभी भाषाओं में सभी सामग्री को लोड करने के लिए मजबूर करता है। इसके अतिरिक्त यह एक अत्यंत भारी समाधान है (~92.7kb, जो vue-intlayer से लगभग 8 गुना है)।

3 - सिफारिशें

(Intlayer) (vue-intlayer@9.5.10):

मैं निष्पक्षता के लिए व्यक्तिगत रूप से vue-intlayer का न्याय नहीं करूँगा, क्योंकि यह मेरा अपना समाधान है।