Next.js i18n लाइब्रेरीज़ - 2026 बेंचमार्क रिपोर्ट

यह पेज Next.js पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।

विषय सूची

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

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

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

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

प्रस्तावना

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

जैसे-जैसे आपका ऐप बढ़ता है, बंडल का आकार तेजी से बढ़ सकता है, जो परफॉरमेंस को काफी नुकसान पहुँचा सकता है।

उदाहरण के तौर पर, सबसे खराब मामलों में, अंतर्राष्ट्रीयकरण के बाद आपका पेज लगभग 4 गुना बड़ा हो सकता है।

i18n लाइब्रेरीज़ का एक अन्य प्रभाव धीमा विकास है। कंपोनेंट्स को विभिन्न भाषाओं में बहुभाषी सामग्री में बदलना समय लेने वाला काम है।

चूंकि यह समस्या कठिन है, इसलिए कई समाधान मौजूद हैं-कुछ DX (डेवलपर अनुभव) पर केंद्रित हैं, अन्य परफॉरमेंस या स्केलेबिलिटी पर, और इसी तरह।

Intlayer इन सभी आयामों में अनुकूलन करने का प्रयास करता है।

TL;DR

• Intlayer और next-translate: Next.js परफॉरमेंस के लिए सर्वोत्तम विकल्प, जो सबसे छोटा फुटप्रिंट और बेहतरीन स्टेटिक रेंडरिंग सपोर्ट प्रदान करते हैं।
• next-intl: वर्तमान में सबसे ट्रेंडी विकल्प, लेकिन बड़ेप्लिकेशन्स के लिए अनुकूलित करना भारी और जटिल है।
• next-i18next: लोकप्रिय और प्लगइन्स से भरपूर, लेकिन बंडल का आकार काफी अधिक है (~3 गुना Intlayer)।
• इनसे बचें: गंभीर परफॉरमेंस समस्याओं, वेंडर लॉक-इन और बिल्ड को रोकने वाले बग्स के कारण gt-next और lingo.dev से बचें।

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

इन समस्याओं को उजागर करने के लिए, मैंने एक मुफ़्त स्कैनर बनाया है जिसे आप यहाँ आज़मा सकते हैं।

समस्या

मल्टीलिंगुअल ऐप के बंडल पर प्रभाव को सीमित करने के दो मुख्य तरीके हैं:

• अपने JSON (या सामग्री) को फ़ाइलों / वेरिएबल्स / नेमस्पेस में विभाजित करें ताकि बंडलर किसी दिए गए पेज के लिए अप्रयुक्त सामग्री को ट्री-शेक (tree-shake) कर सके।
• अपने पेज की सामग्री को केवल उपयोगकर्ता की भाषा में डायनेमिक रूप से लोड करें।

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

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

भले ही आप Webpack या Turbopack के साथ [locale]/page.tsx जैसे रूट घोषित करते हैं, और भले ही generateStaticParams परिभाषित हो, बंडलर locale को एक स्टेटिक कॉन्स्टेंट के रूप में नहीं मानता है। इसका मतलब है कि यह हर पेज में सभी भाषाओं की सामग्री खींच सकता है। इसे सीमित करने का मुख्य तरीका डायनेमिक इम्पोर्ट (उदा. import('./locales/${locale}.json')) के माध्यम से सामग्री लोड करना है।

बिल्ड समय पर जो होता है वह यह है कि Next.js प्रति लोकेल एक JS बंडल (उदा. ./locales_fr_12345.js) उत्सर्जित करता है। साइट क्लाइयंट को भेजे जाने के बाद, जब पेज चलता है, तो ब्राउज़र आवश्यक JS फ़ाइल (उदा. ./locales_fr_12345.js) के लिए एक अतिरिक्त HTTP अनुरोध करता है।

इसी समस्या को हल करने का एक अन्य तरीका JSON को डायनेमिक रूप से लोड करने के लिए fetch() का उपयोग करना है। जब JSON /public के अंतर्गत रहता है, तो Tolgee इसी तरह काम करता है, या next-translate, जो सामग्री लोड करने के लिए getStaticProps पर निर्भर करता है। प्रवाह समान है: ब्राउज़र एसेट लोड करने के लिए एक अतिरिक्त HTTP अनुरोध करता है।

कंटेंट स्प्लिटिंग (सामग्री विभाजन)

यदि आप const t = useTranslation() + t('my-object.my-sub-object.my-key') जैसी सिंटैक्स का उपयोग करते हैं, तो आमतौर पर पूरा JSON बंडल में होना चाहिए ताकि लाइब्रेरी उसे पार्स कर सके और की (key) को हल कर सके। उस सामग्री का बहुत सा हिस्सा तब भी भेजा जाता है जब वह पेज पर अप्रयुक्त होता है।

इसे कम करने के लिए, कुछ लाइब्रेरीज़ आपसे प्रति पेज नेमस्पेस घोषित करने के लिए कहती हैं जिन्हें लोड करना है-उदा. next-i18next, next-intl, lingui, next-translate, next-international ।

इसके विपरीत, Paraglide बिल्ड से पहले JSON को const en_my_var = () => 'my value' जैसे फ्लैट सिम्बल्स में बदलने के लिए एक अतिरिक्त चरण जोड़ता है। सिद्धांत रूप में यह पेज पर अप्रयुक्त सामग्री के ट्री-शेकिंग को सक्षम बनाता है। जैसा कि हम देखेंगे, इस पद्धति के अभी भी अपने ट्रेड-ऑफ़ हैं।

अंत में, Intlayer एक बिल्ड-टाइम ऑप्टिमाइज़ेशन लागू करता है ताकि useIntlayer('my-key') को सीधे संबंधित सामग्री से बदल दिया जाए।

कार्यप्रणाली

इस बेंचमार्क के लिए, हमने निम्नलिखित लाइब्रेरीज़ की तुलना की है:

• Base App (कोई i18n लाइब्रेरी नहीं)
• next-intlayer (v8.7.12)
• next-i18next (v16.0.5)
• next-intl (v4.9.1)
• @lingui/core (v5.3.0)
• next-translate (v3.1.2)
• next-international (v1.3.1)
• @inlang/paraglide-js (v2.15.1)
• @tolgee/react (v7.0.0)
• @lingo.dev/compiler (v0.4.0)
• wuchale (v0.22.11)
• gt-next (v6.16.5)

मैंने एप्र राउटर के साथ Next.js वर्जन 16.2.4 का उपयोग किया।

मैंने 10 पेजों और 10 भाषाओं के साथ एक बहुभाषी ऐप बनाया।

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

रणनीतियों का सारांश

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

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

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

• अंतर्राष्ट्रीयकरण लाइब्रेरी आकार: बंडलिंग, ट्री-शेकिंग और मिनीफिकेशन के बाद, i18n लाइब्रेरी का आकार एक खाली कंपोनेंट में प्रोवाइडर्स (उदा. NextIntlClientProvider) + हुक्स (उदा. useTranslations) कोड का आकार है। इसमें अनुवाद फ़ाइलों की लोडिंग शामिल नहीं है। यह जवाब देता है कि आपकी सामग्री आने से पहले लाइब्रेरी कितनी "महंगी" है।

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

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

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

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

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

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

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

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

GitHub सितारे

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

परिणाम विस्तार से

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

gt-next या lingo.dev जैसे कुछ समाधानों से स्पष्ट रूप से बचना बेहतर है। वे वेंडर लॉक-इन (vendor lock-in) को आपके कोडबेस को प्रदूषित करने के साथ जोड़ते हैं। उन्हें लागू करने की कोशिश में कई घंटे बिताने के बावजूद, मैंने उन्हें कभी ठीक से काम करते हुए नहीं पाया-न तो TanStack Start पर और न ही Next.js पर।

सामना किए गए मुद्दे:

(General Translation) ([email protected]):

• 110kb ऐप के लिए, gt-next 440kb से अधिक अतिरिक्त डेटा जोड़ता है।
• जनरल ट्रांसलेशन के साथ पहले ही बिल्ड पर Quota Exceeded, please upgrade your plan संदेश।
• अनुवाद रेंडर नहीं होते हैं; मुझे एरर मिलता है Error: <T> used on the client-side outside of <GTProvider> , जो लाइब्रेरी में एक बग लगता है।
• gt-next को लागू करने के दौरान, मुझे लाइब्रेरी के साथ एक इश्यू भी मिला: does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser एरर, जिससे एप्लिकेशन क्रैश हो रहा था। इस समस्या की रिपोर्ट करने के बाद, मेंटेनर ने इसे 24 घंटों के भीतर ठीक कर दिया।
• लाइब्रेरी Next.js पेजों के स्टेटिक रेंडरिंग को ब्लॉक करती है।

(Lingo.dev) (@lingo.dev/[email protected]):

• AI कोटा समाप्त हो गया, जिससे बिल्ड पूरी तरह से अवरुद्ध हो गया-इसलिए आप भुगतान किए बिना प्रोडक्शन में नहीं जा सकते।
• कंपाइलर अनुवादित सामग्री के लगभग 40% को मिस कर रहा था। मुझे इसे काम कराने के लिए सभी .map को फ्लैट कंपोनेंट ब्लॉक्स में दोबारा लिखना पड़ा।
• उनका CLI काफी बग्स वाला है और बिना किसी कारण के कॉन्फ़िगरेशन फ़ाइल को रीसेट कर देता था।
• बिल्ड के समय, नई सामग्री जोड़ने पर इसने जेनरेट किए गए JSON को पूरी तरह से मिटा दिया। परिणामस्वरूप, कुछ कीज़ (keys) 300 से अधिक मौजूदा कीज़ को मिटा सकती थीं।

2 - प्रयोगात्मक समाधान

(Wuchale) ([email protected]):

Wuchale के पीछे का विचार दिलचस्प है लेकिन अभी तक व्यवहार्य नहीं है। मुझे रिएक्टिविटी के मुद्दों का सामना करना पड़ा और ऐप को काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी। दस्तावेज़ीकरण भी काफी अस्पष्ट है, जिससे ऑनबोर्डिंग कठिन हो जाती है।

(Paraglide) (@inlang/[email protected]):

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

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

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

(Tolgee) (@tolgee/[email protected]):

Tolgee पहले उल्लेखित कई मुद्दों को संबोधित करता है। मुझे लगा कि इसे अपनाना समान उपकरणों की तुलना में कठिन है। यह टाइप सेफ्टी (type safety) प्रदान नहीं करता है, जिससे कंपाइल समय पर गायब कीज़ को पकड़ना भी कठिन हो जाता है। गायब-की पहचान जोड़ने के लिए मुझे Tolgee के फंक्शन्स को अपने फंक्शन्स के साथ रैप करना पड़ा।

(Next Intl) ([email protected]):

next-intl वर्तमान में सबसे ट्रेंडी विकल्प है और जिसे AI एजेंट सबसे अधिक पुश करते हैं, लेकिन मेरी दृष्टि में गलत तरीके से। शुरुआत करना आसान है। व्यवहार में, लीकेज को सीमित करने के लिए अनुकूलन जटिल है। डायनेमिक लोडिंग + नेमस्पेसिंग + TypeScript टाइप्स को जोड़ना विकास को बहुत धीमा कर देता है। पैकेज भी काफी भारी है ( NextIntlClientProvider + useTranslations के लिए ~13kb, जो next-intlayer के 2 गुना से अधिक है)। next-intl पहले Next.js पेजों के स्टेटिक रेंडरिंग को ब्लॉक करता था। यह setRequestLocale() नाम का एक हेल्पर प्रदान करता है। en.json / fr.json जैसी केंद्रित फ़ाइलों के लिए इसे आंशिक रूप से संबोधित किया गया लगता है, लेकिन सामग्री के en/shared.json / fr/shared.json / es/shared.json जैसे नेमस्पेस में विभाजित होने पर स्टेटिक रेंडरिंग अभी भी टूट जाती है।

(Next I18next) ([email protected]):

next-i18next शायद सबसे लोकप्रिय विकल्प है क्योंकि यह जावास्क्रिप्ट ऐप्स i18n समाधानों में सबसे पहले आया था। इसके कई कम्युनिटी प्लगइन्स हैं। इसमें next-intl जैसी ही प्रमुख कमियाँ हैं। पैकेज विशेष रूप से भारी है ( I18nProvider + useTranslation के लिए ~18kb, next-intlayer के लगभग 3 गुना)।

मैसेज फॉर्मेट्स भी भिन्न हैं: next-intl ICU MessageFormat का उपयोग करता है, जबकि i18next अपने स्वयं के फॉर्मेट का उपयोग करता है।

(Next International) ([email protected]):

next-international भी ऊपर उल्लेखित मुद्दों को हल करता है लेकिन next-intl या next-i18next से बहुत अलग नहीं है। इसमें नेमस्पेस-विशिष्ट अनुवादों के लिए scopedT() शामिल है, लेकिन इसका उपयोग करने का बंडल आकार पर लगभग कोई प्रभाव नहीं पड़ता है।

(Lingui) (@lingui/[email protected]):

Lingui की अक्सर प्रशंसा की जाती है। व्यक्तिगत रूप से मुझे lingui extract / lingui compile वर्कफ़्लो विकल्पों की तुलना में अधिक जटिल लगा, बिना किसी स्पष्ट लाभ के। मैंने असंगत सिंटैक्स भी देखे जो AI को भ्रमित करते हैं (उदा. t(), t'', i18n.t(), <Trans>) ।

4 - सिफारिशें

(Next Translate) ([email protected]):

यदि आप t() स्टाइल की API पसंद करते हैं, तो next-translate मेरी मुख्य सिफारिश है। यह next-translate-plugin के माध्यम से सुंदर ढंग से काम करता है, जो Webpack / Turbopack लोडर के माध्यम से getStaticProps में नेमस्पेस लोड करता है। यह यहाँ सबसे हल्का विकल्प भी है (~2.5kb)। नेमस्पेसिंग के पार, कॉन्फ़िगरेशन में प्रति पेज या रूट नेमस्पेस परिभाषित करना अच्छी तरह से सोचा गया है और next-intl या next-i18next जैसे मुख्य विकल्पों की तुलना में बनाए रखना आसान है। वर्जन 3.1.2 में, मैंने पाया कि स्टेटिक रेंडरिंग काम नहीं करती थी; Next.js डायनेमिक रेंडरिंग पर वापस चला गया।

(Intlayer) ([email protected]):

निष्पक्षता के लिए मैं व्यक्तिगत रूप से मेरे स्वयं के समाधान next-intlayer पर निर्णय नहीं दूँगा।

व्यक्तिगत राय

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

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