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

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

विषय सूची

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

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

परिचय

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

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

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

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

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

TL;DR

• Intlayer: उन्नत सुविधाओं और अनुकूलन की आवश्यकता वाले पेशेवर Solid अनुप्रयोगों के लिए अनुशंसित विकल्प (v9.5.10)।
• @solid-primitives/i18n: सरल परियोजनाओं के लिए उत्कृष्ट हल्का विकल्प, हालांकि इसमें लेज़ी लोडिंग (lazy loading) जैसी उन्नत सुविधाओं का अभाव है।
• solid-i18next: मानक लेकिन भारी विकल्प (~3.5x Intlayer) जिसमें React i18next वाले ही नकारात्मक पक्ष हैं।
• Tolgee: सुविधाओं से भरपूर अनुवाद प्लेटफ़ॉर्म, लेकिन काफी भारी (~12.7kb, Intlayer से लगभग 3.0 गुना), इसमें समर्पित Solid प्रिमिटिव की कमी है (@tolgee/web पर निर्भर करता है), और स्टैटिक सेटअप में पेजों के बीच महत्वपूर्ण अनुवाद रिसाव होता है (90% पेज रिसाव)।
• Paraglide: अभिनव दृष्टिकोण लेकिन जटिल DX और कुछ सेटअपों में ट्री-शेकिंग (tree-shaking) के मुद्दे।

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

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

समस्या

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

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

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

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

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

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

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

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

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

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

• Base App (कोई i18n पुस्तकालय नहीं)
• solid-intlayer (v9.5.10)
• @solid-primitives/i18n (v2.2.1)
• i18next (v26.0.8) + @mbarzda/solid-i18next (v1.4.1)
• @tolgee/web (v7.2.0)
• @inlang/paraglide-js (v2.25.1)

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

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

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

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

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

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

• Internationalization लाइब्रेरी आकार: बंडलिंग, ट्री-शेकिंग और मिनिफिकेशन के बाद, i18n लाइब्रेरी का आकार providers + hooks/primitives कोड एक खाली कंपोनेंट में है। इसमें ट्रांसलेशन फाइलों को लोड करना शामिल नहीं है। यह जवाब देता है कि लाइब्रेरी आपकी सामग्री तस्वीर में आने से पहले कितनी महंगी है।

• प्रति पृष्ठ JavaScript: प्रत्येक बेंचमार्क रूट के लिए, ब्राउज़र उस विज़िट के लिए कितनी स्क्रिप्ट खींचता है, सूट में पृष्ठों में औसत (और locales में जहां रिपोर्ट उन्हें रोल करती है)। भारी पृष्ठ धीमे पृष्ठ हैं।

• अन्य locales से रिसाव: यह एक ही पृष्ठ की सामग्री है लेकिन एक अन्य भाषा में जो ऑडिट किए गए पृष्ठ में गलती से लोड हो सकती है। यह सामग्री अनावश्यक है और इससे बचा जाना चाहिए। (उदाहरण के लिए /fr/about पृष्ठ की सामग्री /en/about पृष्ठ बंडल में)

• अन्य routes से रिसाव: अन्य स्क्रीन के लिए भी यही विचार: कि क्या उनकी कॉपी तब चल रही है जब आपने केवल एक पृष्ठ खोला है। (उदाहरण के लिए /en/about पृष्ठ की सामग्री /en/contact पृष्ठ बंडल में)। उच्च स्कोर कमजोर splitting या over-broad बंडल का संकेत देता है।

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

• भाषा स्विच प्रतिक्रिया: मैं ऐप के अपने नियंत्रण का उपयोग करके भाषा को फ्लिप करता हूं और समय करता हूं कि पृष्ठ स्पष्ट रूप से स्विच होने तक कितना समय लगता है, एक आगंतुक को क्या ध्यान देगा, lab micro-step नहीं।

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

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

• Hydration समय: जब ऐप इसे उजागर करता है, तो क्लाइंट कितने समय तक server HTML को उन चीजों में बदलने में खर्च करता है जिन पर आप वास्तव में क्लिक कर सकते हैं। तालिकाओं में एक dash का मतलब है कि इस बेंचमार्क में कार्यान्वयन ने एक विश्वसनीय hydration आंकड़ा प्रदान नहीं किया।

GitHub सितारे

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

कमिट गतिविधि

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

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

npm डाउनलोड

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

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

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

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

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

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

(solid-i18next) (i18next@26.0.8):

solid-i18next शायद सबसे लोकप्रिय विकल्प है क्योंकि यह JavaScript ऐप i18n जरूरतों को पूरा करने वाले पहले समाधानों में से एक था। इसमें विशिष्ट समस्याओं के लिए सामुदायिक प्लगइन्स का एक विस्तृत सेट भी है।

पैकेज भारी है (~14.9kb, जो solid-intlayer से लगभग 3.5 गुना है)।

फिर भी, यह t('a.b.c') पर बने स्टैक्स के समान ही प्रमुख नकारात्मक पक्ष साझा करता है: अनुकूलन संभव है लेकिन बहुत समय लेने वाला है, और बड़ी परियोजनाओं में खराब प्रथाओं (नेमस्पेस + डायनेमिक लोडिंग + प्रकार) का जोखिम होता है।

(@solid-primitives/i18n) (@solid-primitives/i18n@2.2.1):

Solid primitive बेहद हल्का और कुशल है। मैं उन परियोजनाओं के लिए इस समाधान की अनुशंसा करता हूं जो बहुत हल्की हैं, लेकिन इसमें पेशेवर समाधानों के लिए सुविधाओं की जल्दी कमी हो सकती है जिसमें कुकी प्रबंधन, प्रॉक्सी पुनर्निर्देशन, फ़ॉर्मेटर्स आदि शामिल हैं। इसमें पृष्ठ आकार अनुकूलन के लिए लेज़ी लोडिंग और स्कोपिंग नेमस्पेस की भी कमी है।

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

Tolgee इन-कॉन्टेक्स्ट एडिटिंग सुविधाओं के साथ एक व्यापक अनुवाद प्रबंधन प्लेटफ़ॉर्म प्रदान करता है।

Solid पर वर्तमान में कोई आधिकारिक नेटिव एडेप्टर (@tolgee/solid जैसा) नहीं है, जिसके कारण डेवलपर्स को कस्टम सिग्नल्स के साथ @tolgee/web के माध्यम से एकीकृत करना पड़ता है।

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

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

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

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

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

3 - सिफारिशें

(Intlayer) (solid-intlayer@9.5.10):

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

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

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

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