@intlayer/docs 8.7.4 → 8.7.5

package/docs/hi/benchmark/nextjs.md

@@ -0,0 +1,227 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 में Next.js के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
+description: next-intl, next-i18next और Intlayer जैसे Next.js अंतर्राष्ट्रीयकरण (i18n) लाइब्रेरीज़ की तुलना करें। बंडल आकार, लीकेज और रिएक्टिविटी पर विस्तृत परफॉरमेंस रिपोर्ट।
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - nextjs
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - nextjs
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "बेंचमार्क इनिशियलाइज़ेशन"
+---
+
+# Next.js i18n लाइब्रेरीज़ — 2026 बेंचमार्क रिपोर्ट
+
+यह पेज Next.js पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।
+
+## विषय सूची
+
+<Toc/>
+
+## इंटरैक्टिव बेंचमार्क
+
+<I18nBenchmark framework="nextjs" vertical/>
+
+## परिणाम संदर्भ:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md
+
+पूरा बेंचमार्क रिपॉजिटरी [यहाँ](https://github.com/intlayer-org/benchmark-i18n) देखें।
+
+## प्रस्तावना
+
+अंतर्राष्ट्रीयकरण लाइब्रेरीज़ का आपके एप्लिकेशन पर गहरा प्रभाव पड़ता है। मुख्य जोखिम यह है कि जब उपयोगकर्ता केवल एक पेज पर जाता है, तो हर पेज और हर भाषा के लिए सामग्री लोड हो जाती है।
+
+जैसे-जैसे आपका ऐप बढ़ता है, बंडल का आकार तेजी से बढ़ सकता है, जो परफॉरमेंस को काफी नुकसान पहुँचा सकता है।
+
+उदाहरण के तौर पर, सबसे खराब मामलों में, अंतर्राष्ट्रीयकरण के बाद आपका पेज लगभग 4 गुना बड़ा हो सकता है।
+
+i18n लाइब्रेरीज़ का एक अन्य प्रभाव धीमा विकास है। कंपोनेंट्स को विभिन्न भाषाओं में बहुभाषी सामग्री में बदलना समय लेने वाला काम है।
+
+चूंकि यह समस्या कठिन है, इसलिए कई समाधान मौजूद हैं—कुछ DX (डेवलपर अनुभव) पर केंद्रित हैं, अन्य परफॉरमेंस या स्केलेबिलिटी पर, और इसी तरह।
+
+Intlayer इन सभी आयामों में अनुकूलन करने का प्रयास करता है।
+
+## अपने ऐप का परीक्षण करें
+
+इन समस्याओं को उजागर करने के लिए, मैंने एक मुफ़्त स्कैनर बनाया है जिसे आप [यहाँ](https://intlayer.org/i18n-seo-scanner) आज़मा सकते हैं।
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## समस्या
+
+मल्टीलिंगुअल ऐप के बंडल पर प्रभाव को सीमित करने के दो मुख्य तरीके हैं:
+
+- अपने 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.5)
+- `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` (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**: स्टार्टअप पर सब कुछ मेमोरी में। | **Scoped static**: नेमस्पेस द्वारा विभाजित; स्टार्टअप पर सब कुछ लोड। |
+| **डायनेमिक लोडिंग** | **Dynamic**: प्रति लोकेल ऑन-डिमांड लोडिंग।  | **Scoped dynamic**: नेमस्पेस और लोकेल के अनुसार दानेदार लोडिंग।      |
+
+## रणनीतियों का सारांश
+
+- **Static**: सरल; शुरुआती लोड के बाद कोई नेटवर्क लेटेंसी नहीं। नुकसान: बंडल का बड़ा आकार।
+- **Dynamic**: शुरुआती वज़न कम करता है (लेज़ी-लोडिंग)। जब आपके पास कई लोकेल्स हों तो आदर्श है।
+- **Scoped static**: अतिरिक्त जटिल नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित (लॉजिकल सेपरेशन) रखता है।
+- **Scoped dynamic**: कोड स्प्लिटिंग और परफॉरमेंस के लिए सबसे अच्छा दृष्टिकोण। वर्तमान व्यू और सक्रिय लोकेल की आवश्यकता वाली चीज़ों को लोड करके मेमोरी को कम करता है।
+
+### मैंने क्या मापा:
+
+मैंने हर स्टैक के लिए एक वास्तविक ब्राउज़र में एक ही बहुभाषी ऐप चलाया, फिर लिखा कि वास्तव में नेटवर्क पर क्या आया और चीज़ों में कितना समय लगा। आकार **सामान्य वेब कम्प्रेशन के बाद** रिपोर्ट किए गए हैं, क्योंकि यह लोगों द्वारा वास्तव में डाउनलोड की जाने वाली चीज़ों के कच्चे सोर्स काउंट्स से अधिक करीब है।
+
+- **अंतर्राष्ट्रीयकरण लाइब्रेरी आकार**: बंडलिंग, ट्री-शेकिंग और मिनीफिकेशन के बाद, i18n लाइब्रेरी का आकार एक खाली कंपोनेंट में प्रोवाइडर्स (उदा. `NextIntlClientProvider`) + हुक्स (उदा. `useTranslations`) कोड का आकार है। इसमें अनुवाद फ़ाइलों की लोडिंग शामिल नहीं है। यह जवाब देता है कि आपकी सामग्री आने से पहले लाइब्रेरी कितनी "महंगी" है।
+
+- **प्रति पेज जावास्क्रिप्ट**: प्रत्येक बेंचमार्क रूट के लिए, ब्राउज़र उस विजिट के लिए कितना स्क्रिप्ट खींचता है, जिसे सुइट के पेजों (और लोकेल्स के पार जहाँ रिपोर्ट उन्हें रोल करती है) के औसत के रूप में मापा गया है। भारी पेज धीमे पेज होते हैं।
+
+- **अन्य लोकेल्स से लीकेज**: यह उसी पेज की सामग्री है लेकिन किसी अन्य भाषा में जो ऑडिट किए गए पेज में गलती से लोड हो जाती है। यह सामग्री अनावश्यक है और इससे बचा जाना चाहिए (उदा. `/en/about` पेज बंडल में `/fr/about` पेज की सामग्री)।
+
+- **अन्य रूट्स से लीकेज**: ऐप में **अन्य स्क्रीन्स** के लिए वही विचार: क्या उनकी कॉपी तब भी साथ आ रही है जब आपने केवल एक पेज खोला है (उदा. `/en/contact` पेज बंडल में `/en/about` पेज की सामग्री)। उच्च स्कोर खराब स्प्लिटिंग या अत्यधिक व्यापक बंडल्स का संकेत देता है।
+
+- **औसत कंपोनेंट बंडल आकार**: सामान्य यूआई (UI) पीस को एक विशाल ऐप नंबर के अंदर छिपाने के बजाय **एक-एक करके** मापा जाता है। यह दिखाता है कि क्या अंतर्राष्ट्रीयकरण चुपचाप रोज़मर्रा के कंपोनेंट्स को फुला देता है। उदाहरण के तौर पर, यदि आपका कंपोनेंट री-रेंडर होता है, तो वह मेमोरी से उस पूरे डेटा को लोड करेगा। किसी भी कंपोनेंट में एक विशाल JSON जोड़ना, अप्रयुक्त डेटा के एक बड़े स्टोर को जोड़ने जैसा है जो आपके कंपोनेंट्स के परफॉरमेंस को धीमा कर देगा।
+
+- **भाषा स्विच रिस्पॉन्सिवनेस**: मैंने ऐप के अपने कंट्रोल का उपयोग करके भाषा बदल दी और समय मापा कि जब तक पेज स्पष्ट रूप से स्विच नहीं हो गया—जो एक विजिटर नोटिस करेगा, न कि एक लैब माइक्रो-स्टेप।
+
+- **भाषा परिवर्तन के बाद रेंडरिंग कार्य**: एक संकीर्ण अनुवर्ती: स्विच चालू होने के बाद नई भाषा के लिए इंटरफ़ेस को दोबारा पेंट करने में कितना प्रयास लगा। उपयोगी तब होता है जब "महसूस किया गया" समय और फ़्रेमवर्क लागत भिन्न होती है।
+
+- **प्रारंभिक पेज लोड समय**: नेविगेशन से लेकर ब्राउज़र द्वारा परीक्षण किए गए परिदृश्यों के लिए पेज को पूरी तरह से लोड माने जाने तक का समय। कोल्ड स्टार्ट्स (cold starts) की तुलना करने के लिए अच्छा है।
+
+- **हाइड्रेशन समय**: जब ऐप इसे उजागर करता है, तो क्लाइयंट सर्वर HTML को किसी ऐसी चीज़ में बदलने में कितना समय बिताता है जिस पर आप वास्तव में क्लिक कर सकें। तालिकाओं में एक डैश (-) का अर्थ है कि उस कार्यान्वयन ने इस बेंचमार्क में एक विश्वसनीय हाइड्रेशन आंकड़ा प्रदान नहीं किया।
+
+## परिणाम विस्तार से
+
+### 1 — बचने के लिए समाधान
+
+`gt-next` या `lingo.dev` जैसे कुछ समाधानों से स्पष्ट रूप से बचना बेहतर है। वे वेंडर लॉक-इन (vendor lock-in) को आपके कोडबेस को प्रदूषित करने के साथ जोड़ते हैं। उन्हें लागू करने की कोशिश में कई घंटे बिताने के बावजूद, मैंने उन्हें कभी ठीक से काम करते हुए नहीं पाया—न तो TanStack Start पर और न ही Next.js पर।
+
+सामना किए गए मुद्दे:
+
+**(General Translation)** (`gt-next@6.16.5`):
+
+- 110kb ऐप के लिए, `gt-react` 440kb से अधिक अतिरिक्त डेटा जोड़ता है।
+- जनरल ट्रांसलेशन के साथ पहले ही बिल्ड पर `Quota Exceeded, please upgrade your plan` संदेश।
+- अनुवाद रेंडर नहीं होते हैं; मुझे एरर मिलता है `Error: <T> used on the client-side outside of <GTProvider>` , जो लाइब्रेरी में एक बग लगता है।
+- **gt-tanstack-start-react** को लागू करने के दौरान, मुझे लाइब्रेरी के साथ एक [इश्यू](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) भी मिला: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser` एरर, जिससे एप्लिकेशन क्रैश हो रहा था। इस समस्या की रिपोर्ट करने के बाद, मेंटेनर ने इसे 24 घंटों के भीतर ठीक कर दिया।
+- लाइब्रेरी Next.js पेजों के स्टेटिक रेंडरिंग को ब्लॉक करती है।
+
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
+
+- AI कोटा समाप्त हो गया, जिससे बिल्ड पूरी तरह से अवरुद्ध हो गया—इसलिए आप भुगतान किए बिना प्रोडक्शन में नहीं जा सकते।
+- कंपाइलर अनुवादित सामग्री के लगभग 40% को मिस कर रहा था। मुझे इसे काम कराने के लिए सभी `.map` को फ्लैट कंपोनेंट ब्लॉक्स में दोबारा लिखना पड़ा।
+- उनका CLI काफी बग्स वाला है और बिना किसी कारण के कॉन्फ़िगरेशन फ़ाइल को रीसेट कर देता था।
+- बिल्ड के समय, नई सामग्री जोड़ने पर इसने जेनरेट किए गए JSON को पूरी तरह से मिटा दिया। परिणामस्वरूप, कुछ कीज़ (keys) 300 से अधिक मौजूदा कीज़ को मिटा सकती थीं।
+
+### 2 — प्रयोगात्मक समाधान
+
+**(Wuchale)** (`wuchale@0.22.11`):
+
+`Wuchale` के पीछे का विचार दिलचस्प है लेकिन अभी तक व्यवहार्य नहीं है। मुझे रिएक्टिविटी के मुद्दों का सामना करना पड़ा और ऐप को काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी। दस्तावेज़ीकरण भी काफी अस्पष्ट है, जिससे ऑनबोर्डिंग कठिन हो जाती है।
+
+**(Paraglide)** (`@inlang/paraglide-js@2.15.1`):
+
+`Paraglide` एक अभिनव, अच्छी तरह से सोचा गया दृष्टिकोण प्रदान करता है। फिर भी, इस बेंचमार्क में विज्ञापित ट्री-शेकिंग मेरे Next.js या TanStack Start सेटअप के लिए काम नहीं कर पाया। वर्कफ़्लो और DX अन्य विकल्पों की तुलना में अधिक जटिल हैं।
+व्यक्तिगत रूप से मुझे हर पुश से पहले JS फ़ाइलों को दोबारा उत्पन्न करना पसंद नहीं है, जो PR के माध्यम से लगातार मर्ज संघर्ष का जोखिम पैदा करता है। यह टूल Next.js की तुलना में Vite पर अधिक केंद्रित लगता है।
+अंत में, अन्य समाधानों की तुलना में, Paraglide सामग्री रेंडर करने के लिए वर्तमान लोकेल को पुनः प्राप्त करने के लिए स्टोर (उदा. React context) का उपयोग नहीं करता है। पार्स किए गए प्रत्येक नोड के लिए, यह localStorage / कुकी आदि से लोकेल का अनुरोध करेगा। यह अनावश्यक तर्क के निष्पादन की ओर ले जाता है जो कंपोनेंट रिएक्टिविटी को प्रभावित करता है।
+
+### 3 — स्वीकार्य समाधान
+
+**(Tolgee)** (`tolgee@7.0.0`):
+
+`Tolgee` पहले उल्लेखित कई मुद्दों को संबोधित करता है। मुझे लगा कि इसे अपनाना समान उपकरणों की तुलना में कठिन है। यह टाइप सेफ्टी (type safety) प्रदान नहीं करता है, जिससे कंपाइल समय पर गायब कीज़ को पकड़ना भी कठिन हो जाता है। गायब-की पहचान जोड़ने के लिए मुझे Tolgee के फंक्शन्स को अपने फंक्शन्स के साथ रैप करना पड़ा।
+
+**(Next Intl)** (`next-intl@4.9.1`):
+
+`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)** (`next-i18next@16.0.5`):
+
+`next-i18next` शायद सबसे लोकप्रिय विकल्प है क्योंकि यह जावास्क्रिप्ट ऐप्स i18n समाधानों में सबसे पहले आया था। इसके कई कम्युनिटी प्लगइन्स हैं। इसमें `next-intl` जैसी ही प्रमुख कमियाँ हैं। पैकेज विशेष रूप से भारी है ( `I18nProvider` + `useTranslation` के लिए ~18kb, `next-intlayer` के लगभग 3 गुना)।
+
+मैसेज फॉर्मेट्स भी भिन्न हैं: `next-intl` ICU MessageFormat का उपयोग करता है, जबकि `i18next` अपने स्वयं के फॉर्मेट का उपयोग करता है।
+
+**(Next International)** (`next-international@1.3.1`):
+
+`next-international` भी ऊपर उल्लेखित मुद्दों को हल करता है लेकिन `next-intl` या `next-i18next` से बहुत अलग नहीं है। इसमें नेमस्पेस-विशिष्ट अनुवादों के लिए `scopedT()` शामिल है, लेकिन इसका उपयोग करने का बंडल आकार पर लगभग कोई प्रभाव नहीं पड़ता है।
+
+**(Lingui)** (`@lingui/core@5.3.0`):
+
+`Lingui` की अक्सर प्रशंसा की जाती है। व्यक्तिगत रूप से मुझे `lingui extract` / `lingui compile` वर्कफ़्लो विकल्पों की तुलना में अधिक जटिल लगा, बिना किसी स्पष्ट लाभ के। मैंने असंगत सिंटैक्स भी देखे जो AI को भ्रमित करते हैं (उदा. `t()`, `t''`, `i18n.t()`, `<Trans>`) ।
+
+### 4 — सिफारिशें
+
+**(Next Translate)** (`next-translate@3.1.2`):
+
+यदि आप `t()` स्टाइल की API पसंद करते हैं, तो `next-translate` मेरी मुख्य सिफारिश है। यह `next-translate-plugin` के माध्यम से सुंदर ढंग से काम करता है, जो Webpack / Turbopack लोडर के माध्यम से `getStaticProps` में नेमस्पेस लोड करता है। यह यहाँ सबसे हल्का विकल्प भी है (~2.5kb)। नेमस्पेसिंग के पार, कॉन्फ़िगरेशन में प्रति पेज या रूट नेमस्पेस परिभाषित करना अच्छी तरह से सोचा गया है और **next-intl** या **next-i18next** जैसे मुख्य विकल्पों की तुलना में बनाए रखना आसान है। वर्जन `3.1.2` में, मैंने पाया कि स्टेटिक रेंडरिंग काम नहीं करती थी; Next.js डायनेमिक रेंडरिंग पर वापस चला गया।
+
+**(Intlayer)** (`next-intlayer@8.7.5`):
+
+निष्पक्षता के लिए मैं व्यक्तिगत रूप से मेरे स्वयं के समाधान `next-intlayer` पर निर्णय नहीं दूँगा।
+
+### व्यक्तिगत राय
+
+यह राय व्यक्तिगत है और बेंचमार्क परिणामों को प्रभावित नहीं करती है। i18n की दुनिया में, अक्सर अनुवादित सामग्री के लिए `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` जैसे पैटर्न के आसपास सहमति दिखती है।
+
+React ऐप्स में, किसी फ़ंक्शन को `ReactNode` के रूप में इंजेक्ट करना, मेरी राय में, एक एंटी-पैटर्न है। यह टाली जा सकने वाली जटिलता और जावास्क्रिप्ट निष्पादन ओवरहेड (भले ही मुश्किल से ध्यान देने योग्य हो) को भी जोड़ता है।

package/docs/hi/benchmark/tanstack.md

@@ -0,0 +1,193 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 में TanStack Start के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
+description: react-i18next, use-intl और Intlayer जैसे TanStack Start अंतर्राष्ट्रीयकरण लाइब्रेरीज़ की तुलना करें। बंडल आकार, लीकेज और रिएक्टिविटी पर विस्तृत परफॉरमेंस रिपोर्ट।
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - tanstack
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - tanstack
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "बेंचमार्क इनिशियलाइज़ेशन"
+---
+
+# TanStack Start i18n लाइब्रेरीज़ — 2026 बेंचमार्क रिपोर्ट
+
+यह पेज TanStack Start पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।
+
+## विषय सूची
+
+<Toc/>
+
+## इंटरैक्टिव बेंचमार्क
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+## परिणाम संदर्भ:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md" 
+  width="100%" 
+  height="600px"
+  style="border:none;">
+</iframe>
+
+> https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md
+
+पूरा बेंचमार्क रिपॉजिटरी [यहाँ](https://github.com/intlayer-org/benchmark-i18n/tree/main) देखें।
+
+## प्रस्तावना
+
+अंतर्राष्ट्रीयकरण समाधान React ऐप में सबसे भारी निर्भरताओं में से एक हैं। TanStack Start पर मुख्य जोखिम अनावश्यक सामग्री को शिप करना है: एक ही रूट के बंडल में अन्य पेजों और अन्य लोकेल्स के अनुवाद शामिल होना।
+
+जैसे-जैसे आपका ऐप बढ़ता है, वह समस्या क्लाइयंट को भेजे जाने वाले जावास्क्रिप्ट को तेज़ी से बढ़ा सकती है और नेविगेशन को धीमा कर सकती है।
+
+व्यवहार में, कम से कम अनुकूलित कार्यान्वयनों के लिए, अंतर्राष्ट्रीयकृत पेज बिना i18n वाले वर्जन की तुलना में कई गुना भारी हो सकता है।
+
+दूसरा प्रभाव डेवलपर अनुभव (DX) पर पड़ता है: आप सामग्री को कैसे घोषित करते हैं, टाइप्स, नेमस्पेस संगठन, डायनेमिक लोडिंग, और लोकेल बदलने पर रिएक्टिविटी।
+
+## अपने ऐप का परीक्षण करें
+
+i18n लीकेज के मुद्दों को तेज़ी से पहचानने के लिए, मैंने एक मुफ़्त स्कैनर सेट किया है जो [यहाँ](https://intlayer.org/i18n-seo-scanner) उपलब्ध है।
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## समस्या
+
+मल्टीलिंगुअल ऐप की लागत को सीमित करने के लिए दो लीवर आवश्यक हैं:
+
+- सामग्री को पेज / नेमस्पेस द्वारा विभाजित करें ताकि जब आपकी आवश्यकता न हो तो पूरे शब्दकोश लोड न हों।
+- सही लोकेल को केवल आवश्यकता होने पर डायनेमिक रूप से लोड करें।
+
+इन दृष्टिकोणों की तकनीकी सीमाओं को समझना:
+
+**डायनेमिक लोडिंग**
+
+डायनेमिक लोडिंग के बिना, अधिकांश समाधान पहले रेंडर से संदेशों को मेमोरी में रखते हैं, जो कई रूट्स और लोकेल्स वाले ऐप्स के लिए महत्वपूर्ण ओवरहेड जोड़ता है।
+
+डायनेमिक लोडिंग के साथ, आप एक ट्रेड-ऑफ़ स्वीकार करते हैं: कम शुरुआती JS, लेकिन कभी-कभी भाषा बदलते समय एक अतिरिक्त अनुरोध।
+
+**कंटेंट स्प्लिटिंग (सामग्री विभाजन)**
+
+`const t = useTranslation()` + `t('a.b.c')` के इर्द-गिर्द बनी सिंटैक्स बहुत सुविधाजनक हैं लेकिन अक्सर रनटाइम पर बड़े JSON ऑब्जेक्ट रखने के लिए प्रोत्साहित करती हैं। वह मॉडल ट्री-शेकिंग को कठिन बना देता है जब तक कि लाइब्रेरी वास्तविक प्रति-पेज स्प्लिट रणनीति प्रदान न करे।
+
+## कार्यप्रणाली
+
+इस बेंचमार्क के लिए, हमने निम्नलिखित लाइब्रेरीज़ की तुलना की है:
+
+- `Base App` (कोई i18n लाइब्रेरी नहीं)
+- `react-intlayer` (v8.7.5-canary.0)
+- `react-i18next` (v17.0.2)
+- `use-intl` (v4.9.1)
+- `@lingui/core` (v5.3.0)
+- `@inlang/paraglide-js` (v2.15.1)
+- `tolgee` (v7.0.0)
+- `react-intl` (v10.1.1)
+- `wuchale` (v0.22.11)
+- `gt-react` (vlatest)
+- `lingo.dev` (v0.133.9)
+
+फ़्रेमवर्क **10 पेजों** और **10 भाषाओं** के मल्टीलिंगुअल ऐप के साथ `TanStack Start` है।
+
+हमने **चार लोडिंग रणनीतियों** की तुलना की:
+
+| रणनीति              | कोई नेमस्पेस नहीं (ग्लोबल)                  | नेमस्पेस के साथ (स्कॉप्ड)                                            |
+| :------------------ | :------------------------------------------ | :------------------------------------------------------------------- |
+| **स्टेटिक लोडिंग**  | **Static**: स्टार्टअप पर सब कुछ मेमोरी में। | **Scoped static**: नेमस्पेस द्वारा विभाजित; स्टार्टअप पर सब कुछ लोड। |
+| **डायनेमिक लोडिंग** | **Dynamic**: प्रति लोकेल ऑन-डिमांड लोडिंग।  | **Scoped dynamic**: नेमस्पेस और लोकेल के अनुसार दानेदार लोडिंग।      |
+
+## रणनीतियों का सारांश
+
+- **Static**: सरल; शुरुआती लोड के बाद कोई नेटवर्क लेटेंसी नहीं। नुकसान: बंडल का बड़ा आकार।
+- **Dynamic**: शुरुआती वज़न कम करता है (लेज़ी-लोडिंग)। जब आपके पास कई लोकेल्स हों तो आदर्श है।
+- **Scoped static**: अतिरिक्त जटिल नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित (लॉजिकल सेपरेशन) रखता है।
+- **Scoped dynamic**: कोड स्प्लिटिंग और परफॉरमेंस के लिए सबसे अच्छा दृष्टिकोण। वर्तमान व्यू और सक्रिय लोकेल की आवश्यकता वाली चीज़ों को लोड करके मेमोरी को कम करता है।
+
+## परिणाम विस्तार से
+
+### 1 — बचने के लिए समाधान
+
+`gt-react` या `lingo.dev` जैसे कुछ समाधान स्पष्ट रूप से ऐसे हैं जिनसे दूर रहना चाहिए। वे वेंडर लॉक-इन को आपके कोडबेस को प्रदूषित करने के साथ जोड़ते हैं। इससे भी बदतर: उन्हें लागू करने की कोशिश में कई घंटे बिताने के बावजूद, मैंने उन्हें TanStack Start पर कभी ठीक से काम करते हुए नहीं पाया (Next.js पर `gt-next` के समान) ।
+
+सामना किए गए मुद्दे:
+
+**(General Translation)** (`gt-react@latest`):
+
+- लगभग 110kb के ऐप के लिए, `gt-react` 440kb से अधिक अतिरिक्त डेटा जोड़ सकता है (इसी बेंचमार्क में Next.js कार्यान्वयन पर देखा गया परिमाण)।
+- जनरल ट्रांसलेशन के साथ पहले ही बिल्ड पर `Quota Exceeded, please upgrade your plan` संदेश।
+- अनुवाद रेंडर नहीं होते हैं; मुझे एरर मिलता है `Error: <T> used on the client-side outside of <GTProvider>` , जो लाइब्रेरी में एक बग लगता है।
+- **gt-tanstack-start-react** को लागू करने के दौरान, मुझे लाइब्रेरी के साथ एक [इश्यू](https://github.com/generaltranslation/gt/issues/1210#event-24510646961) भी मिला: `does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser` एरर, जिससे एप्लिकेशन क्रैश हो रहा था। रिपोर्ट करने के बाद, मेंटेनर ने इसे 24 घंटों के भीतर ठीक कर दिया।
+- ये लाइब्रेरीज़ `initializeGT()` फ़ंक्शन के माध्यम से एक एंटी-पैटर्न का उपयोग करती हैं, जिससे बंडल को साफ़-सुथरे ढंग से ट्री-शेकिंग करने से रोका जाता है।
+
+**(Lingo.dev)** (`lingo.dev@0.133.9`):
+
+- AI कोटा समाप्त हो गया (या सर्वर निर्भरता को अवरुद्ध करना), जिससे भुगतान के बिना बिल्ड / प्रोडक्शन जोखिम भरा हो गया।
+- कंपाइलर अनुवादित सामग्री के लगभग 40% को मिस कर रहा था। मुझे इसे काम कराने के लिए सभी `.map` को फ्लैट कंपोनेंट ब्लॉक्स में दोबारा लिखना पड़ा।
+- उनका CLI काफी बग्स वाला है और बिना किसी कारण के कॉन्फ़िगरेशन फ़ाइल को रीसेट कर देता था।
+- बिल्ड के समय, नई सामग्री जोड़ने पर इसने जेनरेट किए गए JSON को पूरी तरह से मिटा दिया। परिणामस्वरूप, आप समाप्त कर सकते हैं कि केवल कुछ कीज़ सैकड़ों मौजूदा कीज़ को मिटा रही हैं।
+- मुझे TanStack Start पर लाइब्रेरी के साथ रिएक्टिविटी के मुद्दों का सामना करना पड़ा: लोकेल बदलने पर मुझे इसे काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी।
+
+### 2 — प्रयोगात्मक समाधान
+
+**(Wuchale)** (`wuchale@0.22.11`):
+
+`Wuchale` के पीछे का विचार दिलचस्प है लेकिन अभी तक व्यवहार्य समाधान नहीं है। मुझे लाइब्रेरी के साथ रिएक्टिविटी के मुद्दों का सामना करना पड़ा और TanStack Start पर ऐप को काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी। दस्तावेज़ीकरण भी काफी अस्पष्ट है, जिससे ऑनबोर्डिंग कठिन हो जाती है।
+
+### 3 — स्वीकार्य समाधान
+
+**(Paraglide)** (`@inlang/paraglide-js@2.15.1`):
+
+`Paraglide` एक अभिनव, अच्छी तरह से सोचा गया दृष्टिकोण प्रदान करता है। फिर भी, इस बेंचमार्क में उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग मेरे Next.js कार्यान्वयन या TanStack Start के लिए काम नहीं कर पाया। वर्कफ़्लो और DX अन्य विकल्पों की तुलना में अधिक जटिल हैं। व्यक्तिगत रूप से मैं हर पुश से पहले JS फ़ाइलों को दोबारा उत्पन्न करने का प्रशंसक नहीं हूँ, जो PR के माध्यम से डेवलपर्स के लिए लगातार मर्ज संघर्ष का जोखिम पैदा करता है।
+
+**(Tolgee)** (`tolgee@7.0.0`):
+
+`Tolgee` पहले उल्लेखित कई मुद्दों को संबोधित करता है। मुझे लगा कि इसे शुरू करना समान दृष्टिकोण वाले अन्य उपकरणों की तुलना में कठिन है। यह टाइप सेफ्टी प्रदान नहीं करता है, जिससे कंपाइल समय पर गायब कीज़ को पकड़ना भी बहुत कठिन हो जाता है। गायब-की पहचान जोड़ने के लिए मुझे Tolgee की APIs को अपनी APIs के साथ रैप करना पड़ा।
+
+TanStack Start पर मुझे रिएक्टिविटी की समस्याएं भी थीं: लोकेल बदलने पर, मुझे प्रोवाइडर को री-रेंडर करने के लिए मजबूर करना पड़ा और लोकेल-चेंज इवेंट्स को सब्सक्राइब करना पड़ा ताकि दूसरी भाषा में लोडिंग सही ढंग से व्यवहार करे।
+
+**(use-intl)** (`use-intl@4.9.1`):
+
+`use-intl` वर्तमान में React ईकोसिस्टम में सबसे ट्रेंडी "intl" पीस है ( `next-intl` के समान परिवार) और इसे अक्सर AI एजेंटों द्वारा पुश किया जाता है, लेकिन मेरी दृष्टि में परफॉरमेंस-फ़र्स्ट सेटिंग में गलत तरीके से। शुरुआत करना काफी सरल है। व्यवहार में, लीकेज को अनुकूलित और सीमित करने की प्रक्रिया काफी जटिल है। इसी प्रकार, डायनेमिक लोडिंग + नेमस्पेसिंग + TypeScript टाइप्स को जोड़ना विकास को बहुत धीमा कर देता है।
+
+TanStack Start पर आप Next.js-विशिष्ट जाल ( `setRequestLocale`, स्टेटिक रेंडरिंग) से बचते हैं, लेकिन मुख्य मुद्दा वही है: सख्त अनुशासन के बिना, बंडल जल्दी से बहुत अधिक संदेशों को ढोता है और प्रति-रूट नेमस्पेस रखरखाव कष्टदायक हो जाता है।
+
+**(react-i18next)** (`react-i18next@17.0.2`):
+
+`react-i18next` शायद सबसे लोकप्रिय विकल्प है क्योंकि यह जावास्क्रिप्ट ऐप i18n आवश्यकताओं को पूरा करने वाले शुरुआती समाधानों में से एक था। इसमें विशिष्ट मुद्दों के लिए कम्युनिटी प्लगइन्स का एक विस्तृत सेट भी है।
+
+फिर भी, यह `t('a.b.c')` पर बने स्टैक्स जैसी ही प्रमुख कमियाँ साझा करता है: अनुकूलन संभव है लेकिन बहुत समय लेने वाला है, और बड़ी परियोजनाओं में खराब प्रथाओं (नेमस्पेस + डायनेमिक लोडिंग + टाइप्स) में गिरने का जोखिम होता है।
+
+मैसेज फॉर्मेट्स भी भिन्न हैं: `use-intl` ICU MessageFormat का उपयोग करता है, जबकि `i18next` अपने स्वयं के फॉर्मेट का उपयोग करता है—जो टूल्स या माइग्रेशन को जटिल बनाता है यदि आप उन्हें मिलाते हैं।
+
+**(Lingui)** (`@lingui/core@5.3.0`):
+
+`Lingui` की अक्सर प्रशंसा की जाती है। व्यक्तिगत रूप से मुझे `lingui extract` / `lingui compile` वर्कफ़्लो अन्य दृष्टिकोणों की तुलना में अधिक जटिल लगा, इस TanStack Start बेंचमार्क में किसी स्पष्ट लाभ के बिना। मैंने असंगत सिंटैक्स भी देखे जो AI को भ्रमित करते हैं (उदा. `t()`, `t''`, `i18n.t()`, `<Trans>`) ।
+
+**(react-intl)** (`react-intl@10.1.1`):
+
+`react-intl` Format.js टीम का एक परफॉरमेंट कार्यान्वयन है। DX वर्बोस (verbose) रहता है: `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` जटिलता, अतिरिक्त जावास्क्रिप्ट कार्य जोड़ता है और ग्लोबल i18n इंस्टेंस को React ट्री के कई नोड्स से जोड़ता है।
+
+### 4 — सिफारिशें
+
+इस TanStack Start बेंचमार्क का `next-translate` (Next.js प्लगइन + `getStaticProps`) के बराबर कोई सीधा विकल्प नहीं है। उन टीमों के लिए जो वास्तव में परिपक्व ईकोसिस्टम वाली `t()` API चाहती हैं, `react-i18next` और `use-intl` "उचित" विकल्प बने हुए हैं, लेकिन लीकेज से बचने के लिए अनुकूलन में बहुत समय निवेश करने के लिए तैयार रहें।
+
+**(Intlayer)** (`react-intlayer@8.7.5-canary.0`):
+
+निष्पक्षता के लिए मैं व्यक्तिगत रूप से मेरे स्वयं के समाधान `react-intlayer` पर निर्णय नहीं दूँगा।
+
+### व्यक्तिगत राय
+
+यह राय व्यक्तिगत है और बेंचमार्क परिणामों को प्रभावित नहीं करती है। फिर भी, i18n की दुनिया में, अक्सर अनुवादित सामग्री के लिए `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` जैसे पैटर्न के आसपास सहमति दिखती है।
+
+React ऐप्स में, किसी फ़ंक्शन को `ReactNode` के रूप में इंजेक्ट करना, मेरी राय में, एक एंटी-पैटर्न है। यह टाली जा सकने वाली जटिलता और जावास्क्रिप्ट निष्पादन ओवरहेड (भले ही वह मुश्किल से ध्यान देने योग्य हो) को भी जोड़ता है।

package/docs/id/benchmark/index.md

@@ -0,0 +1,29 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-20
+title: Benchmark library i18n
+description: Pelajari perbandingan Intlayer dengan library i18n lainnya dalam hal performa dan ukuran bundle.
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - nextjs
+  - tanstack
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+history:
+  - version: 8.7.5
+    date: 2026-01-06
+    changes: "Inisialisasi benchmark"
+---
+
+# Benchmark - Laporan
+
+Benchmark Bloom adalah rangkaian benchmarking performa yang mengukur dampak nyata library i18n (internasionalisasi) di berbagai framework React dan strategi pemuatan.
+
+Laporan terperinci dan dokumentasi teknis untuk setiap framework tersedia di bawah ini:
+
+- [**Laporan benchmark Next.js**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/id/benchmark/nextjs.md)
+- [**Laporan benchmark TanStack Start**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/id/benchmark/tanstack.md)