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

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

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

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

TL;DR

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

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

i18n लीकेज समस्याओं को तुरंत पहचानने के लिए, मैंने एक निःशुल्क स्कैनर सेट किया है जो यहाँ उपलब्ध है।

intlayer.org

समस्या

बहुभाषी ऐप की लागत को सीमित करने के लिए दो लीवर आवश्यक हैं:

सामग्री को पृष्ठ / नेमस्पेस द्वारा विभाजित करें ताकि जरूरत न होने पर आप संपूर्ण शब्दकोश लोड न करें।
सही लोकेल को डायनेमिक रूप से लोड करें, केवल तभी जब आवश्यक हो।

इन दृष्टिकोणों की तकनीकी सीमाओं को समझना:

डायनेमिक लोडिंग

डायनेमिक लोडिंग के बिना, अधिकांश समाधान पहले रेंडर से संदेशों को मेमोरी में रखते हैं, जो कई रूट्स और लोकेल्स वाले ऐप्स के लिए महत्वपूर्ण ओवरहेड जोड़ता है।

डायनेमिक लोडिंग के साथ, आप एक समझौता स्वीकार करते हैं: कम प्रारंभिक JS, लेकिन भाषा स्विच करते समय कभी-कभी एक अतिरिक्त अनुरोध।

सामग्री विभाजन (Splitting)

const { t } = useI18n() + t('a.b.c') के इर्द-गिर्द निर्मित सिंटैक्स बहुत सुविधाजनक हैं लेकिन अक्सर रनटाइम पर बड़ी JSON वस्तुओं को रखने के लिए प्रोत्साहित करते हैं। वह मॉडल ट्री-शेकिंग (tree-shaking) को कठिन बनाता है जब तक कि पुस्तकालय वास्तविक प्रति-पृष्ठ विभाजन रणनीति प्रदान नहीं करता।

अनुसंधान पद्धति

इस बेंचमार्क के लिए, हमने निम्नलिखित पुस्तकालयों की तुलना की:

Base App (कोई i18n पुस्तकालय नहीं)
vue-intlayer (v8.7.12)
vue-i18n (v11.4.0)
fluent-vue (v3.8.2)

फ्रेमवर्क Vue है जिसमें 10 पृष्ठों और 10 भाषाओं का एक बहुभाषी ऐप है।

हमने चार लोडिंग रणनीतियों की तुलना की:

सभी तालिका सामग्री दिखाएं

सभी डेटा सामग्री को स्पष्ट रूप से देखने के लिए तालिका को मोडल में खोलें

रणनीति	कोई नेमस्पेस नहीं (वैश्विक)	नेमस्पेस के साथ (स्कोपयुक्त/scoped)
स्टेटिक लोडिंग	Static: स्टार्टअप पर मेमोरी में सब कुछ।	Scoped static: नेमस्पेस द्वारा विभाजित; स्टार्टअप पर सब कुछ लोड।
डायनेमिक लोडिंग	Dynamic: लोकेल प्रति मांग पर लोडिंग।	Scoped dynamic: नेमस्पेस और लोकेल प्रति सूक्ष्म लोडिंग।

रणनीति सारांश

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

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

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

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

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

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

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

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

(fluent-vue) (fluent-vue@0.5.0):

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

3 - सिफारिशें

(Intlayer) (vue-intlayer@8.7.12):

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

TanStack

Solid