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

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

विषय सूची

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

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

परिचय

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

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

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

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

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

TL;DR

• Intlayer: सबसे छोटे पदचिह्न (footprint) के साथ सबसे प्रदर्शन-कुशल विकल्प (v9.5.10)।
• Paraglide: ट्री-शेकिंग (tree-shaking) के लिए मजबूत दावेदार लेकिन इसमें अधिक जटिल डेवलपर अनुभव और प्रतिक्रियाशीलता ओवरहेड है।
• Tolgee: इन-कॉन्टेक्स्ट एडिटिंग के साथ सुविधाओं से भरपूर अनुवाद प्लेटफ़ॉर्म, लेकिन काफी भारी (~13.0kb, Intlayer से लगभग 3.6 गुना), और स्टैटिक सेटअप में पेजों के बीच महत्वपूर्ण अनुवाद रिसाव होता है (90% पेज रिसाव)।
• svelte-i18n: Svelte के लिए व्यापक और मानक, लेकिन बहुत बड़े बंडल वजन (~4.6x Intlayer) के साथ आता है।

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

i18n लीकेज समस्याओं को तुरंत पहचानने के लिए, आप निःशुल्क i18n SEO स्कैनर आज़मा सकते हैं।

समस्या

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

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

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

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

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

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

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

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

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

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

• Base App (कोई i18n पुस्तकालय नहीं)
• svelte-intlayer (v9.5.10)
• svelte-i18n (v4.0.1)
• @tolgee/svelte (v7.2.1)
• @inlang/paraglide-js (v2.25.1)

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

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

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

• Static: सरल; प्रारंभिक लोड के बाद कोई नेटवर्क विलंबता नहीं। नकारात्मक पक्ष: बड़ा बंडल आकार।
• Dynamic: प्रारंभिक वजन कम करता है (लेज़ी-लोडिंग)। आदर्श जब आपके पास कई लोकेल्स हों।
• Scoped static: जटिल अतिरिक्त नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित रखता है (तार्किक पृथक्करण)।
• Scoped dynamic: कोड स्प्लिटिंग और प्रदर्शन के लिए सर्वोत्तम दृष्टिकोण। केवल वर्तमान दृश्य और सक्रिय लोकेल के लिए आवश्यक सामग्री लोड करके मेमोरी को कम करता है।

मैंने क्या मापा:

मैंने प्रत्येक stack के लिए एक ही बहुभाषी ऐप्लिकेशन को एक वास्तविक ब्राउज़र में चलाया, फिर नोट किया कि वास्तव में तार पर क्या दिखाई दिया और चीजें कितनी देर लीं। आकार सामान्य वेब संपीड़न के बाद रिपोर्ट किए जाते हैं, क्योंकि यह कच्चे स्रोत गणना की तुलना में लोगों द्वारा डाउनलोड किए जाने वाले से करीब है।

• Internationalization library size: bundling, tree-shaking और minification के बाद, i18n library का आकार providers + stores code का आकार एक खाली component में है। इसमें translation files को लोड करना शामिल नहीं है। यह इस बात का उत्तर देता है कि आपकी content से पहले library कितनी महंगी है।

• JavaScript per page: प्रत्येक benchmark route के लिए, browser उस visit के लिए कितनी script खींचता है, suite में pages के औसत पर (और locales के पार जहां report उन्हें roll करता है)। Heavy pages slow pages हैं।

• Leakage from other locales: यह एक ही page की content है लेकिन दूसरी language में जो audited page में गलती से load हो जाती है। यह content अनावश्यक है और इससे बचा जाना चाहिए। (उदाहरण के लिए /fr/about page content /en/about page bundle में)

• Leakage from other routes: अन्य screens के लिए भी यही विचार: क्या उनकी copy तब भी साथ आती है जब आपने केवल एक page खोला हो। (उदाहरण के लिए /en/about page content /en/contact page bundle में)। एक high score weak splitting या over-broad bundles का संकेत देता है।

• Average component bundle size: Common UI pieces को एक बार में measure किया जाता है बजाय एक giant app number के अंदर छिपने के। यह दिखाता है कि internationalization आम components को quietly inflate करता है या नहीं। उदाहरण के लिए, यदि आपका component rerender करता है, तो यह memory से सभी उस data को load करेगा। किसी भी component के साथ एक giant JSON को attach करना एक बड़े unused data store को जोड़ने जैसा है जो आपके components के performance को slow down करेगा।

• Language switch responsiveness: मैं ऐप के अपने control का उपयोग करके language को flip करता हूं और time करता हूं कि page clearly switch होने में कितना समय लगता है, जो एक visitor को notice होगा, न कि एक lab micro-step।

• Rendering work after a language change: एक narrower follow-up: interface को नई language के लिए repaint करने में कितनी effort लगी एक बार switch in flight हो। उपयोगी जब "felt" समय और framework cost में divergence हो।

• Initial page load time: navigation से browser तक जब page को उन scenarios के लिए fully loaded माना जाए जिन्हें मैंने test किया। Cold starts की तुलना के लिए अच्छा।

• Hydration time: जब app इसे expose करता है, तो client कितना समय server HTML को कुछ ऐसे में बदलने में खर्च करता है जिसे आप actually click कर सकते हैं। Tables में एक dash का मतलब है कि implementation ने इस benchmark में एक reliable hydration figure provide नहीं किया।

GitHub सितारे

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

कमिट गतिविधि

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

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

npm डाउनलोड

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

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

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

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

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

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

(Paraglide) (@inlang/paraglide-js@2.25.1):

Paraglide एक अभिनव, सुविचारित दृष्टिकोण प्रदान करता है। Vite + Svelte ऐप के संदर्भ में, उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग अपेक्षा के अनुरूप काम करती है, जो बहुत अच्छी बात है। लेकिन React + TanStack Start के मामले में, ट्री-शेकिंग ने अपेक्षा के अनुरूप काम नहीं किया, Next.js के लिए भी यही स्थिति रही। उस ने कहा, Svelte और TanStack Start प्रोजेक्ट में Paraglide के उपयोग की दोबारा जांच करना सार्थक होगा। वर्कफ़्लो और DX भी अन्य विकल्पों की तुलना में अधिक जटिल हैं। व्यक्तिगत रूप से मैं हर पुश से पहले JS फ़ाइलों को पुनर्जीवित करने का प्रशंसक नहीं हूं, जो PR के माध्यम से निरंतर मर्ज संघर्ष जोखिम पैदा करता है। यह टूल Next.js की तुलना में Vite पर अधिक केंद्रित लगता है। अंत में, अन्य समाधानों की तुलना में, Paraglide सामग्री रेंडर करने के लिए वर्तमान लोकेल को पुनः प्राप्त करने के लिए स्टोर (उदा. Svelte store) का उपयोग नहीं करता है। पार्स किए गए प्रत्येक नोड के लिए, यह localStorage / cookie आदि से लोकेल का अनुरोध करेगा। यह अनावश्यक तर्क के निष्पादन की ओर ले जाता है जो घटक प्रतिक्रियाशीलता को प्रभावित करता है।

Paraglide पर ध्यान दें: समाधान आयात के लिए आपके कोडबेस में कोड इंजेक्ट करता है; परिणामस्वरूप, बेंचमार्क रिपोर्ट में 'lib size' मीट्रिक लगभग 0 है। कोड जेनरेशन एक अच्छी बात है, क्योंकि उपयोग किए गए फ़ंक्शन में केवल आवश्यक तर्क शामिल होंगे (हर जगह प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकी बनाम स्टोरेज आदि)। तुलनात्मक रूप से, Intlayer तर्क के आधार पर सामग्री को ट्री-शेक करने के लिए बंडलर को मजबूर करने के लिए बिल्ड में पर्यावरण चर इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है। इसके कारण, paraglide और intlayer i18next या next-intl की तुलना में 6 से 10 गुना हल्के समाधान साबित होते हैं।

(Tolgee) (@tolgee/svelte@7.2.1):

Tolgee इन-कॉन्टेक्स्ट एडिटिंग और @tolgee/svelte के माध्यम से आधिकारिक Svelte एकीकरण के साथ एक ऑल-इन-वन स्थानीयकरण प्लेटफ़ॉर्म प्रदान करता है।

यह पैकेज अपेक्षाकृत भारी है (~13.0kb, जो svelte-intlayer से लगभग 3.6 गुना अधिक है)।

Svelte में प्रति-पेज विभाजन तंत्र के बिना, स्टैटिक सेटअप में सभी अनुवाद शुरुआत में ही मेमोरी में लोड हो जाते हैं। इससे भारी बंडल रिसाव (50.0% लोकेल रिसाव, 90.0% पेज रिसाव) होता है और औसत पेज बंडल आकार ~100.7kb तक पहुंच जाता है (Intlayer के ~59.0kb की तुलना में)।

भाषा बदलने की प्रतिक्रियाशीलता बहुत तेज़ है (0.5ms), जो Svelte के प्रतिक्रियाशील स्टोर्स से लाभान्वित होती है, हालांकि हाइड्रेशन ओवरहेड थोड़ा अधिक है (Intlayer के ~4.1ms की तुलना में ~6.2ms)।

(svelte-i18n) (svelte-i18n@4.0.1):

यह समाधान Svelte प्रोजेक्ट में सभी i18n आवश्यकताओं को पूरा करता है। लेकिन जैसा कि i18next या अन्य प्रमुख i18n समाधानों के मामले में होता है, यह थोड़ा भारी है (~16.6kb, जो svelte-intlayer से लगभग 4.5 गुना है)।

3 - सिफारिशें

(Intlayer) (svelte-intlayer@9.5.10):

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

व्यक्तिगत नोट

यह नोट व्यक्तिगत है और बेंचमार्क परिणामों को प्रभावित नहीं करता है। फिर भी, i18n दुनिया में आप अक्सर अनुवादित सामग्री के लिए const t = useTranslation('xx') + <>{t('xx.xx')}</> जैसे पैटर्न के आसपास आम सहमति देखते हैं।

Svelte ऐप्स में, एक फ़ंक्शन को Slot के रूप में इंजेक्ट करना, मेरी नज़र में, एक एंटी-पैटर्न है। यह परिहार्य जटिलता और JavaScript निष्पादन ओवरहेड भी जोड़ता है (भले ही यह मुश्किल से ध्यान देने योग्य हो)।