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

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

विषय सूची

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

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

पूर्ण बेंचमार्क डेटा देखें

संपूर्ण बेंचमार्क रिपॉजिटरी यहाँ देखें।

परिचय

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

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

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

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

TL;DR

• Intlayer: सबसे छोटे पदचिह्न (footprint) के साथ सबसे प्रदर्शन-कुशल विकल्प (v8.7.12)।
• Paraglide: ट्री-शेकिंग (tree-shaking) के लिए मजबूत दावेदार लेकिन इसमें अधिक जटिल डेवलपर अनुभव और प्रतिक्रियाशीलता ओवरहेड है।
• svelte-i18n: Svelte के लिए व्यापक और मानक, लेकिन बहुत बड़े बंडल वजन (~7x 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 भाषाओं का एक बहुभाषी ऐप है।

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

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

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

GitHub सितारे

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

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

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

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

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

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

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 गुना हल्के समाधान साबित होते हैं।

(svelte-i18n) (svelte-i18n@3.4.0):

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

3 - सिफारिशें

(Intlayer) (svelte-intlayer@8.7.12):

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

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

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

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