@intlayer/docs 9.5.6 → 9.5.8

package/blog/hi/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next बनाम Intlayer: 2026 बेंचमार्क और विस्तृत तुलना"
 description: "Next.js और TanStack Start पर Intlayer के मुकाबले react-i18next और next-i18next का परीक्षण। बंडल साइज, कंटेंट लीकेज, भाषा बदलने की प्रतिक्रिया और डेवलपर अनुभव का विश्लेषण।"
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next बनाम Intlayer | React और Next.js अंतर्राष्ट्रीयकरण (i18n) बेंचमार्क
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next` जावास्क्रिप्ट इकोसिस्टम में सबसे व्यापक रूप से उपयोग किया जाने वाला i18n फ्रेमवर्क है। `react-i18next` और `next-i18next` के माध्यम से यह अनगिनत React और Next.js एप्लिकेशनों को संचालित करता है। Intlayer एक आधुनिक, कंपाइलर-आधारित और कंपोनेंट-स्कोप्ड विकल्प है।
 
 यह लेख केवल फीचर लिस्ट के बजाय वास्तविक मापों के आधार पर दोनों की तुलना करता है। सभी आंकड़े [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) से लिए गए हैं, जो एक ओपन-सोर्स बेंचमार्क सूट है जो प्रत्येक लाइब्रेरी के साथ समान एप्लिकेशन बनाता है और ब्राउज़र द्वारा वास्तव में डाउनलोड किए गए डेटा को रिकॉर्ड करता है।
@@ -99,6 +101,10 @@ Intlayer में कोई "scoped" संस्करण नहीं है:
 
 ### Next.js पर परिणाम (`next-i18next`)
 
+वे मेट्रिक्स और लाइब्रेरीज़ चुनें जो आपके लिए महत्वपूर्ण हैं:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | लाइब्रेरी                       | रणनीति         | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E प्रतिक्रिया | Hydration |
 | ------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | --------------: | --------: |
 | **base** (बिना i18n)            | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |         13.4 ms |   11.8 ms |
@@ -119,6 +125,15 @@ Intlayer में कोई "scoped" संस्करण नहीं है:
 - **कंपोनेंट आकार**: `useTranslation()` का उपयोग करने वाला कंपोनेंट 26-79 KB में कंपाइल होता है; वही कंपोनेंट `useIntlayer()` के साथ केवल 6.9 KB में कंपाइल होता है।
 - **हाइड्रेशन**: `dynamic` सेटअप में हाइड्रेशन 27.7 ms तक बढ़ जाता है क्योंकि React के हाइड्रेट होने से पहले i18next इंस्टेंस को क्लाइंट पर बैकएंड हल करना पड़ता है।
 
+<ClickToOpenIframe
+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;"
+/>
+
+> पूरी तालिका, प्रत्येक लाइब्रेरी और प्रत्येक रणनीति [Next.js बेंचमार्क रिपोर्ट](https://intlayer.org/hi/doc/benchmark/nextjs) में उपलब्ध है।
+
 ### TanStack Start पर परिणाम (`react-i18next`)
 
 Next.js की विशेषताओं को अलग करके TanStack Start पर शुद्ध `react-i18next` के साथ समान परीक्षण:
@@ -141,8 +156,19 @@ Next.js की विशेषताओं को अलग करके TanStac
 - Intlayer का `static` विकल्प पहले से ही **0% पेज लीकेज** देता है क्योंकि केवल वर्तमान पेज के कंपोनेंट्स द्वारा आयातित शब्दकोश ही बंडल होते हैं। `importMode: 'dynamic'` चालू करने से भाषा लीकेज भी पूरी तरह समाप्त हो जाती है।
 - **कंपोनेंट आकार**: `react-i18next` में प्रति कंपोनेंट 24-27 KB बनाम Intlayer में 6-8 KB।
 
+<ClickToOpenIframe
+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;"
+/>
+
+> पूरी तालिका [TanStack Start बेंचमार्क रिपोर्ट](https://intlayer.org/hi/doc/benchmark/tanstack) में उपलब्ध है।
+
 ## यह अंतर क्यों है? ग्लोबल इंस्टेंस बनाम कंपाइल किए गए शब्दकोश
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next` को 2012 में एक रनटाइम के रूप में डिजाइन किया गया था: एक ग्लोबल इंस्टेंस संसाधन भंडार रखता है, प्लगइन्स इसे विस्तारित करते हैं, और रेंडर समय पर `t()` कुंजियों को खोजता है। यह इसे अत्यधिक लचीला बनाता है लेकिन भारी भी बनाता है:
 
 ```bash
@@ -166,7 +192,13 @@ Next.js की विशेषताओं को अलग करके TanStac
                 └── page.tsx     # इसे जानना होगा कि इसे ["common", "about"] की आवश्यकता है
 ```
 
-ग्लोबल इंस्टेंस यह अनुमान नहीं लगा सकता कि कंपोनेंट को किन कुंजियों की आवश्यकता होगी, इसलिए यह उन सभी नेमस्पेस को बनाए रखता है जिन्हें लोड करने के लिए कहा गया है। अनुकूलन का अर्थ है कि **आप** फाइलों को विभाजित करें, **आप** प्रत्येक पेज के लिए आवश्यक नेमस्पेस सूचीबद्ध करें, और कंपोनेंट बदलने पर उस सूची को बनाए रखें। जैसा कि [बेंचमार्क रिपोर्ट](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) में कहा गया है: "टाइप सुरक्षा बनाए रखना और यह जानना कि किस पेज पर कौन सा नेमस्पेस चाहिए, एक दुःस्वप्न है।"
+ग्लोबल इंस्टेंस यह अनुमान नहीं लगा सकता कि कंपोनेंट को किन कुंजियों की आवश्यकता होगी, इसलिए यह उन सभी नेमस्पेस को बनाए रखता है जिन्हें लोड करने के लिए कहा गया है। अनुकूलन का अर्थ है कि **आप** फाइलों को विभाजित करें, **आप** प्रत्येक पेज के लिए आवश्यक नेमस्पेस सूचीबद्ध करें, और कंपोनेंट बदलने पर उस सूची को बनाए रखें।
+
+लागत एक साथ दो अक्षों पर बढ़ती है, पेज और भाषाएँ:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+जैसा कि [बेंचमार्क रिपोर्ट](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md) में कहा गया है: "टाइप सुरक्षा बनाए रखना और यह जानना कि किस पेज पर कौन सा नेमस्पेस चाहिए, एक दुःस्वप्न है।"
 
 Intlayer ग्लोबल इंस्टेंस को पूरी तरह समाप्त कर देता है। कंटेंट सीधे कंपोनेंट के बगल में घोषित होता है, और कंपाइलर बिल्ड समय पर निर्भरता ट्री को हल करता है:
 
@@ -193,7 +225,8 @@ Intlayer ग्लोबल इंस्टेंस को पूरी तर
 
 ### सेटअप
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -228,7 +261,8 @@ export const initI18next = async (
 
 इसके अलावा क्लाइंट-साइड `I18nProvider`, `generateStaticParams`, और हर पेज पर `namespaces` सूची को बनाए रखना पड़ता है।
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -264,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### क्लाइंट कंपोनेंट
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -304,7 +342,8 @@ export const Counter = () => {
 
 > इस कंपोनेंट को रेंडर करने वाले पेज को `about` नेमस्पेस लोड करना होगा, और `CustomTypeOptions` का विस्तार किए बिना `t("counter.label")` केवल एक सामान्य स्ट्रिंग है।
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -345,9 +384,13 @@ export const Counter = () => {
 
 `label` और `increment` पूरी तरह से टाइप-सुरक्षित हैं; वर्तनी की गलती TypeScript त्रुटि देती है और फ्रेंच अनुवाद गायब होने पर बिल्ड रुक जाता है।
 
+</Tab>
+</Tabs>
+
 ### सिंक्रोनस सर्वर कंपोनेंट
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -366,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 पेज को `i18n.getFixedT(locale, "about")` कॉल करके `t` और `locale` को Props के रूप में नीचे भेजना पड़ता है।
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -385,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## i18next API बनाए रखें, Intlayer का बेहतर प्रदर्शन पाएं
 
 बेंचमार्क परिणामों का लाभ उठाने के लिए आपको अपने कंपोनेंट्स को फिर से लिखने की आवश्यकता नहीं है। `@intlayer/i18next`, `@intlayer/react-i18next`, और `@intlayer/next-i18next` ड्रॉप-इन एडेप्टर हैं: `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, बहुवचन और संदर्भ प्रत्यय बिना किसी बदलाव के काम करते रहते हैं।
@@ -415,18 +462,85 @@ export default defineConfig({
 
 ## कब किसका चयन करें?
 
-- **i18next चुनें**: यदि आपको इसके विशाल प्लगइन इकोसिस्टम की आवश्यकता है, आप React के बाहर भी स्थानीयकरण करते हैं (Node सेवाएँ, Vanilla JS, अन्य फ्रेमवर्क), आपकी टीम पहले से इसमें कुशल है, या कोई अनुवाद प्लेटफ़ॉर्म `locales/{lng}/{ns}.json` फ़ाइलों की अपेक्षा करता है। प्रदर्शन महत्वपूर्ण होने पर नेमस्पेस विभाजन और पेज मैपिंग के लिए समय निकालें।
-- **Intlayer चुनें**: यदि आप **कंपोनेंट-स्तरीय कंटेंट**, **सख्त TypeScript सुरक्षा**, **बिल्ड-समय पर अनुवाद सत्यापन**, **शून्य-प्रयास ट्री-शेकिंग और लेज़ी लोडिंग**, त्वरित भाषा स्विचिंग, सिंक्रोनस सर्वर कंपोनेंट्स और अंतर्निहित संपादन उपकरण (विजुअल एडिटर, CMS, AI अनुवाद, MCP सर्वर) चाहते हैं। मॉड्यूलर कोडबेस और डिज़ाइन सिस्टम के लिए यह सर्वोत्तम है।
-- **`@intlayer/*-i18next` एडेप्टर चुनें**: यदि आप पहले से ही i18next का उपयोग कर रहे हैं और कोड को फिर से लिखे बिना बंडल साइज और प्रतिक्रिया गति में सुधार चाहते हैं।
+<AccordionGroup>
+<Accordion header="i18next चुनें">
+
+यदि आपको इसके विशाल प्लगइन इकोसिस्टम की आवश्यकता है, आप React के बाहर भी स्थानीयकरण करते हैं (Node सेवाएँ, Vanilla JS, अन्य फ्रेमवर्क), आपकी टीम पहले से इसमें कुशल है, या कोई अनुवाद प्लेटफ़ॉर्म `locales/{lng}/{ns}.json` फ़ाइलों की अपेक्षा करता है। प्रदर्शन महत्वपूर्ण होने पर नेमस्पेस विभाजन और पेज मैपिंग के लिए समय निकालें।
+
+</Accordion>
+<Accordion header="Intlayer चुनें">
+
+आप **कंपोनेंट-स्कोप सामग्री**, **सख्त TypeScript**, **बिल्ड-टाइम छूटी हुई कुंजियों पर त्रुटियाँ**, **शून्य-प्रयास ट्री-शेकिंग और लेज़ी लोडिंग**, त्वरित भाषा स्विचिंग, सिंक्रोनस सर्वर कंपोनेंट और अंतर्निहित संपादन उपकरण ([विज़ुअल एडिटर](https://intlayer.org/hi/doc/concept/editor), [CMS](https://intlayer.org/hi/doc/concept/cms), [AI अनुवाद](https://intlayer.org/hi/doc/concept/auto-fill), [MCP सर्वर](https://intlayer.org/hi/doc/mcp-server)) चाहते हैं। विशेष रूप से बड़े, मॉड्यूलर कोडबेस और डिज़ाइन सिस्टम के लिए उपयुक्त।
+
+</Accordion>
+<Accordion header="@intlayer/*-i18next एडेप्टर चुनें">
+
+आप पहले से ही i18next पर हैं और कंपोनेंट्स को दोबारा लिखे बिना बंडल और प्रतिक्रियाशीलता का लाभ चाहते हैं। आपकी `locales/{lng}/{ns}.json` फ़ाइलें सच्चाई का स्रोत बनी रहती हैं। [i18next vs @intlayer/i18next](https://intlayer.org/hi/blog/i18next-vs-intlayer-i18next) में एक साथ मापा गया।
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ (अक्सर पूछे जाने वाले प्रश्न)
+
+<FAQ>
+
+<Question title="i18next अन्य लाइब्रेरीज़ की तुलना में इतनी भारी क्यों है?">
+
+इसे फ्रेमवर्क-अज्ञेय रनटाइम के रूप में डिज़ाइन किया गया था: एक वैश्विक इंस्टेंस, एक प्लगइन पाइपलाइन, एक संसाधन स्टोर, एक कुंजी समाधानकर्ता। यह लचीलापन प्रत्येक बंडल में संकलित होता है। एक खाली कंपोनेंट जो केवल लाइब्रेरी को आयात करता है, `next-i18next` के साथ **19.7 KB gzip** और `next-intlayer` के साथ **5.5 KB** खर्च करता है, और यह लागत प्रत्येक पेज पर चुकानी पड़ती है चाहे आपकी सामग्री का वजन कुछ भी हो।
+
+</Question>
+
+<Question title="क्या बैकएंड के साथ लेज़ी लोडिंग इसे ठीक कर देती है?">
+
+यह बाइट्स को ठीक करता है, लेटेंसी को नहीं। `i18next-resources-to-backend` पर जाने से प्रति पेज ~49 KB की बचत होती है लेकिन भाषा स्विच पर नेटवर्क राउंड-ट्रिप जुड़ जाता है: `dynamic` सेटअप में **123 ms** और `scoped-static` में **185 ms**, जबकि Intlayer के साथ **3-4 ms**। हाइड्रेशन भी 27.7 ms तक बढ़ जाता है क्योंकि React के हाइड्रेट होने से पहले इंस्टेंस अपने बैकएंड को हल करता है।
+
+</Question>
+
+<Question title="क्या मैं i18next के साथ 0% लीकेज तक पहुँच सकता हूँ?">
+
+हाँ, `scoped-dynamic` के साथ: प्रति रूट एक नेमस्पेस, एक संसाधन बैकएंड और हाथ से बनाए रखा जाने वाला पेज-टू-नेमस्पेस मैप। यह Next.js पर प्रति पेज 163.4 KB पर पहुँचता है, जो अभी भी Intlayer के 141.3 KB से **+22 KB** अधिक है, जिसके लिए किसी कॉन्फ़िगरेशन की आवश्यकता नहीं थी। देखें [बंडल अनुकूलन](https://intlayer.org/hi/doc/concept/bundle-optimization)।
+
+</Question>
+
+<Question title="क्या मुझे माइग्रेट करने के लिए अपने कंपोनेंट्स को दोबारा लिखना होगा?">
+
+नहीं। `@intlayer/i18next`, `@intlayer/react-i18next` और `@intlayer/next-i18next` `useTranslation`, `t()`, `<Trans>`, `{{interpolation}}`, `_one` / `_other` बहुवचन, संदर्भ प्रत्यय और `returnObjects` को बनाए रखते हैं। `next.config.ts` या `vite.config.ts` में केवल एक प्लगइन लाइन। [next-i18next माइग्रेशन गाइड](https://intlayer.org/hi/doc/migration/next-i18next) में चरण-दर-चरण।
+
+</Question>
+
+<Question title="मेरे i18next प्लगइन्स का क्या होता है?">
+
+बैकएंड और भाषा डिटेक्टर स्वीकार किए जाते हैं लेकिन निष्क्रिय रहते हैं: रनटाइम पर लोड या पता लगाने के लिए कुछ नहीं बचता है। भाषा का पता लगाना Intlayer का रूटिंग कॉन्फ़िगरेशन (URL उपसर्ग, कुकी, हेडर) बन जाता है। यदि आपका ऐप अनुरोध के समय CMS से अनुवाद प्राप्त करता है, तो इसके बजाय [Intlayer CMS](https://intlayer.org/hi/doc/concept/cms) या `intlayer pull` / `push` का उपयोग करें।
+
+</Question>
+
+</FAQ>
 
 ## संबंधित तुलनात्मक लेख
 
-- [next-intl बनाम Intlayer](https://intlayer.org/hi/blog/next-intl-vs-intlayer) (समान बेंचमार्क)
-- [Lingui बनाम Intlayer](https://intlayer.org/hi/blog/lingui-vs-intlayer) (समान बेंचमार्क)
-- [vue-i18n बनाम Intlayer बेंचमार्क](https://intlayer.org/hi/blog/vue-i18n-vs-intlayer-benchmark) (समान बेंचमार्क)
-- [next-i18next बनाम next-intl बनाम Intlayer](https://intlayer.org/hi/blog/next-i18next-vs-next-intl-vs-intlayer)
-- [react-i18next बनाम react-intl बनाम Intlayer](https://intlayer.org/hi/blog/react-i18next-vs-react-intl-vs-intlayer)
+वही बेंचमार्क, अन्य लाइब्रेरीज़:
+
+- [next-intl vs Intlayer](https://intlayer.org/hi/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/hi/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/hi/blog/vue-i18n-vs-intlayer-benchmark)
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/hi/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/hi/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+i18next पर और आगे जानें:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/hi/blog/i18next-vs-intlayer-i18next), उसी ऐप पर मापे गए एडेप्टर
 - [क्या i18next पुराना हो चुका है?](https://intlayer.org/hi/blog/is-i18next-outdated)
+- [i18next के साथ Intlayer का उपयोग करना](https://intlayer.org/hi/blog/intlayer-with-i18next) और [react-i18next के साथ](https://intlayer.org/hi/blog/intlayer-with-react-i18next)
+- [next-i18next के साथ Next.js ऐप का अंतर्राष्ट्रीयकरण कैसे करें](https://intlayer.org/hi/blog/nextjs-internationalization-using-next-i18next)
+
+संदर्भ दस्तावेज़:
+
+- [Next.js बेंचमार्क रिपोर्ट](https://intlayer.org/hi/doc/benchmark/nextjs) और [TanStack Start बेंचमार्क रिपोर्ट](https://intlayer.org/hi/doc/benchmark/tanstack)
+- संगतता एडेप्टर: [i18next](https://intlayer.org/hi/doc/compatibility/i18next), [react-i18next](https://intlayer.org/hi/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/hi/doc/compatibility/next-i18next)
+- माइग्रेशन गाइड: [i18next](https://intlayer.org/hi/doc/migration/i18next), [react-i18next](https://intlayer.org/hi/doc/migration/react-i18next), [next-i18next](https://intlayer.org/hi/doc/migration/next-i18next)
+- [बंडल अनुकूलन](https://intlayer.org/hi/doc/concept/bundle-optimization) और [Intlayer कंपाइलर](https://intlayer.org/hi/doc/compiler)
+- [प्रति-कंपोनेंट बनाम केंद्रीकृत i18n](https://intlayer.org/hi/blog/per-component-vs-centralized-i18n)
+- [कंपाइलर-संचालित बनाम घोषणात्मक i18n](https://intlayer.org/hi/blog/compiler-vs-declarative-i18n)
 
 ## GitHub स्टार्स
 

package/blog/hi/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: क्या Intlayer, Paraglide से हल्का है?
+description: Paraglide i18n बेंचमार्क में लगभग शून्य भार वाला प्रतीत होता है क्योंकि इसका कोड सीधे आपके रिपॉजिटरी में जेनरेट होता है। जानिए यह वजन वास्तव में कहाँ जाता है, प्रति-नोड लोकेल पढ़ना प्रदर्शन को कैसे प्रभावित करता है, और Intlayer का डायनामिक लोडिंग सभी के बजाय केवल एक लोकेल कैसे लोड करता है।
+keywords:
+  - Paraglide
+  - Intlayer
+  - अंतर्राष्ट्रीयकरण
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# क्या Intlayer, Paraglide से हल्का है?
+
+हाँ।
+
+`Paraglide` सबसे हल्के i18n समाधान के रूप में जाना जाता है, और पहली नज़र में [बेंचमार्क](https://intlayer.org/hi/doc/benchmark/tanstack) भी इससे सहमत दिखता है: इसका लाइब्रेरी साइज शून्य के करीब है। लेकिन शून्य लाइब्रेरी साइज का मतलब यह नहीं है कि ब्राउज़र को शून्य बाइट भेजे गए हैं। इसका सीधा सा मतलब है कि बाइट्स ऐसी जगह मौजूद हैं जहाँ यह मेट्रिक ध्यान नहीं देती।
+
+<TOC/>
+
+## मुख्य निष्कर्ष
+
+**लाइब्रेरी का आकार छिपा हुआ है, समाप्त नहीं हुआ:**
+
+Paraglide अपने रनटाइम और मैसेज फ़ंक्शंस को सीधे आपके कोडबेस में जेनरेट करता है। वह कोड ब्राउज़र में भेजा जाता है, लेकिन उसे लाइब्रेरी के कोड के बजाय _आपके_ कोड के रूप में गिना जाता है।
+
+**बिना प्रोवाइडर के होना मुफ्त का लाभ नहीं है:**
+
+प्रत्येक `m.my_key()` कॉल लोकेल को अपने दम पर हल करता है, संदर्भ (context) से एक बार पढ़ने के बजाय रेंडर किए गए प्रत्येक नोड के लिए कुकी या स्टोरेज को पढ़ता है।
+
+**कोई डायनामिक लोडिंग नहीं:**
+
+Paraglide किसी मैसेज के सभी लोकेल्स को आपके क्लाइंट बंडल में इम्पोर्ट करता है। जबकि Intlayer `importMode: 'dynamic'` या `'fetch'` के साथ केवल उसी लोकेल को लोड करता है जो रेंडर हो रहा है।
+
+**Tree shaking की गारंटी नहीं है:**
+
+हमारे कुछ बेंचमार्क में, Paraglide का विज्ञापित Tree shaking काम नहीं कर सका। अपने स्वयं के बंडल की जाँच अवश्य करें।
+
+## Paraglide का वजन वास्तव में कहाँ जाता है?
+
+बेंचमार्क रिपोर्ट में, "लाइब्रेरी साइज" मेट्रिक किसी भी सामग्री को जोड़ने से पहले, खाली कंपोनेंट में प्रत्येक i18n लाइब्रेरी के प्रोवाइडर और हुक्स को मापती है।
+
+| लाइब्रेरी (TanStack Start)    | लाइब्रेरी साइज (gz) | लाइब्रेरी साइज (min) |
+| ----------------------------- | ------------------- | -------------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB              | 4.5 KB               |
+| `react-intlayer@9.5.1`        | 5.0 KB              | 15.2 KB              |
+
+अलग से देखने पर Paraglide जीतता हुआ दिखता है। लेकिन Paraglide एक कंपाइलर है: यह आपकी `messages/*.json` फ़ाइलों को पढ़ता है और आपके रिपॉजिटरी में एक `paraglide/` फ़ोल्डर लिखता है, जिसमें एक `runtime.js` (लोकेल डिटेक्शन, कुकी और स्टोरेज रणनीतियाँ, URL स्थानीयकरण) और प्रति मैसेज एक जावास्क्रिप्ट फ़ंक्शन शामिल होता है।
+
+```bash
+src/paraglide/
+├── runtime.js      # लोकेल डिटेक्शन, रणनीतियाँ, URL हेल्पर्स
+├── server.js
+├── messages.js     # सभी संदेशों को पुनः निर्यात करता है
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+चूँकि यह कोड आपके `src/` फ़ोल्डर में रहता है और आप इसे रिलेटिव पाथ से इम्पोर्ट करते हैं, इसलिए बंडलर इसे `node_modules` पैकेज के बजाय आपके एप्लिकेशन का हिस्सा मानता है। लाइब्रेरी साइज कॉलम में लगभग कुछ भी दिखाई नहीं देता, जबकि वही लॉजिक आपके पेज बंडल में भेजा जाता है।
+
+कोड जेनरेट करना अपने आप में कोई बुरा विचार नहीं है: जेनरेट किया गया रनटाइम केवल वही लॉजिक शामिल करता है जिसकी आपके कॉन्फ़िगरेशन को आवश्यकता होती है (प्रीफ़िक्स रणनीति, कुकी बनाम लोकल स्टोरेज, आदि)। Intlayer बिल्ड समय पर एनवायरनमेंट वेरिएबल्स इंजेक्ट करके अलग तरीके से यही परिणाम प्राप्त करता है, जिससे बंडलर उन शाखाओं को हटा देता है जिनका आपका कॉन्फ़िगरेशन उपयोग नहीं करता है। दोनों ही दृष्टिकोण `i18next` या `next-intl` की तुलना में 3 से 10 गुना हल्के साबित होते हैं।
+
+इसलिए निष्पक्ष तुलना लाइब्रेरी साइज की नहीं है। यह **प्रति पेज वास्तव में भेजे गए जावास्क्रिप्ट** की है।
+
+## मापा गया पेज वजन
+
+TanStack Start ऐप, 10 पेज, `en` और `fr` रूट्स पर मापा गया, gzip संपीड़न:
+
+| सेटअप                              | पेज JS औसत (gz) | बेस से अधिक | लोकेल लीकेज | अन्य पेज लीकेज |
+| ---------------------------------- | --------------- | ----------- | ----------- | -------------- |
+| बेस (कोई i18n नहीं)                | 111.0 KB        | -           | 0.0%        | 0.0%           |
+| `paraglide` (कोई भी रणनीति)        | 125.1 KB        | +14.1 KB    | 49.7%       | 0.0%           |
+| `intlayer` (`importMode: static`)  | 125.8 KB        | +14.8 KB    | 50.0%       | 0.0%           |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**    | **+7.6 KB** | **0.0%**    | **0.0%**       |
+
+Next.js 16 App Router, समान ऐप:
+
+| सेटअप               | पेज JS औसत (gz) | बेस से अधिक |
+| ------------------- | --------------- | ----------- |
+| बेस (कोई i18n नहीं) | 141.0 KB        | -           |
+| `paraglide-next`    | 155.3 KB        | +14.3 KB    |
+| `next-intlayer`     | **141.3 KB**    | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> संपूर्ण डेटा [TanStack Start बेंचमार्क रिपोर्ट](https://intlayer.org/hi/doc/benchmark/tanstack) और [Next.js बेंचमार्क रिपोर्ट](https://intlayer.org/hi/doc/benchmark/nextjs) में उपलब्ध है। प्रत्येक बंडल का निरीक्षण [बेंचमार्क रिपॉजिटरी](https://github.com/intlayer-org/benchmark-i18n) में किया जा सकता है।
+
+दो बातें स्पष्ट रूप से सामने आती हैं:
+
+- `static` मोड में, Intlayer व्यावहारिक रूप से Paraglide के समान ही सामग्री भेजता है (125.8 KB बनाम 125.1 KB)। यह अपेक्षित है: दोनों में उस पेज द्वारा उपयोग किए जाने वाले संदेशों के सभी लोकेल शामिल होते हैं।
+- Paraglide किसी भी रणनीति में 125.1 KB पर बना रहता है, क्योंकि इसमें कोई डायनामिक मोड नहीं है। ऊपर दी गई तालिका की प्रत्येक पंक्ति इसके स्थिर मोड का प्रतिनिधित्व करती है।
+
+## कोई प्रोवाइडर नहीं: एक विचार जो अच्छा दिखता है पर है नहीं
+
+Paraglide को किसी प्रोवाइडर की आवश्यकता नहीं होती। आप सीधे मैसेज इम्पोर्ट करते हैं और कॉल करते हैं:
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+कोई संदर्भ नहीं, कोई रैपर नहीं, कोई हुक नहीं। यह सरल दिखता है। लेकिन लोकेल की जानकारी कहीं से तो आनी ही चाहिए। प्रत्येक जेनरेट किया गया मैसेज फ़ंक्शन लगभग ऐसा दिखता है (सरलीकृत):
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // प्रत्येक कॉल पर हल किया जाता है
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...प्रत्येक लोकेल के लिए एक ब्रांच
+};
+```
+
+और `getLocale()` वर्तमान लोकेल खोजने के लिए कॉन्फ़िगर की गई रणनीतियों (कुकी, लोकल स्टोरेज, URL, बेस लोकेल) को स्कैन करता है। इसलिए आपके द्वारा रेंडर किया जाने वाला प्रत्येक टेक्स्ट नोड (`<>{m.my_key()}</>`) अपना स्वयं का लोकेल रिज़ॉल्यूशन चलाता है, जिसमें ब्राउज़र में `document.cookie` पढ़ना भी शामिल है। 200 अनुवादित स्ट्रिंग्स वाला एक पेज प्रति रेंडर 200 बार लोकेल हल करता है, और प्रत्येक री-रेंडर पर इसे दोहराता है।
+
+एक प्रोवाइडर-आधारित लाइब्रेरी लोकेल को **केवल एक बार** पढ़ती है, इसे एक संदर्भ (या सिग्नल, या स्टोर) में संग्रहीत करती है, और प्रत्येक नोड मेमोरी में पहले से मौजूद मान को पढ़ता है। प्रोवाइडर का आकार कुछ सौ बाइट्स का होता है। इसे छोड़ने पर प्रत्येक रेंडर में सीपीयू की खपत होती है, जो बेंचमार्क में स्पष्ट दिखाई देता है: TanStack Start पर Paraglide का पेज लोड और भाषा बदलने का समय Intlayer से लगातार पीछे रहता है (पेज लोड में 22.1 ms बनाम 14.6 ms, E2E प्रतिक्रिया में 4.3 ms बनाम 3.2 ms)।
+
+## डेवलपर अनुभव (DX)
+
+Paraglide का सोर्स ऑफ ट्रुथ JSON है, लेकिन आप सीधे JSON को कभी इम्पोर्ट नहीं करते हैं। आप कंपाइलर द्वारा जेनरेट की गई `.js` फ़ाइल को इम्पोर्ट करते हैं:
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/hi.json"
+{
+  "hero_title": "अपने ऐप को हर भाषा में प्रकाशित करें"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// कंपाइलर द्वारा JSON से पुनः उत्पन्न किए जाने के बाद ही मौजूद होता है
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      hi: "अपने ऐप को हर भाषा में प्रकाशित करें",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+इस कार्यप्रणाली की अपनी कमियां हैं:
+
+- JSON फ़ाइल में प्रत्येक परिवर्तन के लिए इम्पोर्ट के रिज़ॉल्व होने या प्रकारों के अपडेट होने से पहले पुनः जेनरेशन की आवश्यकता होती है।
+- जेनरेट किया गया `paraglide/` फ़ोल्डर या तो गिट में कमिट किया जाना चाहिए (जिससे टेक्स्ट बदलने वाले प्रत्येक पीआर में जेनरेट की गई फ़ाइलों पर मर्ज टकराव होता है), या इसे अनदेखा किया जाना चाहिए (जिसके लिए प्रत्येक टाइप चेक, टेस्ट और सीआई जॉब से पहले एक जेनरेशन चरण की आवश्यकता होती है)।
+- प्रत्येक स्ट्रिंग एक फ़ंक्शन कॉल बन जाती है। स्थिरांक हर जगह `m.key()` में बदल जाते हैं, यहाँ तक कि उन स्थानों पर भी जहाँ एक साधारण स्ट्रिंग मान पर्याप्त होता।
+
+## Tree Shaking: अपना बंडल जांचें
+
+Paraglide का मुख्य वादा यह है कि अप्रयुक्त संदेशों को Tree shaking द्वारा हटा दिया जाता है, क्योंकि प्रत्येक संदेश अपना स्वयं का निर्यात होता है। Svelte + Vite बेंचमार्क में, यह विज्ञापनों के अनुसार काम करता है।
+
+अन्य सेटअपों में ऐसा नहीं हुआ। हमारे [Next.js](https://intlayer.org/hi/doc/benchmark/nextjs) परीक्षण में, Paraglide के पेज बेस ऐप से 14 KB अधिक भारी थे, जबकि `next-intlayer` ने केवल 0.3 KB जोड़ा। TanStack Start पर पहले के परीक्षणों से यह भी पता चला कि अन्य पेजों के संदेश भी वर्तमान रूट बंडल में शामिल हो रहे थे।
+
+Tree shaking आपके बंडलर (Turbopack, Rolldown, Rollup), संदेशों को आयात करने के तरीके (`import { m }` बनाम `import * as m`) और साइड-इफेक्ट विश्लेषण पर निर्भर करता है। यदि आप इसके आकार के कारण Paraglide चुनते हैं, तो अपने बंडल विज़ुअलाइज़र को खोलें और सत्यापित करें कि यह आपके ऐप में सही काम कर रहा है या नहीं।
+
+## कोई डायनामिक लोडिंग नहीं
+
+यह संरचनात्मक सीमा है। Paraglide के पास एक समय में एक लोकेल लोड करने का कोई साधन नहीं है: प्रत्येक संदेश फ़ंक्शन प्रत्येक भाषा के कार्यान्वयन को स्थैतिक रूप से आयात करता है, इसलिए सभी भाषाएं आपके क्लाइंट बंडल में समाप्त हो जाती हैं।
+
+2 भाषाओं के साथ, आपका आधा अनुवाद पेलोड बर्बाद हो जाता है, जो ऊपर मापे गए ~50% लोकेल रिसाव से मेल खाता है। 10 भाषाओं के साथ, 90% पेलोड बर्बाद होता है। 30 भाषाओं के साथ, 97%।
+
+डायनामिक लोडिंग पर स्विच करने से भी इसका समाधान नहीं होगा: प्रति संदेश एक फ़ंक्शन होने के कारण, प्रत्येक फ़ंक्शन को लेज़ी-लोड करने का अर्थ हजारों नेटवर्क अनुरोध होगा।
+
+Intlayer आपको विश्व स्तर पर या प्रति डिक्शनरी चुनने की सुविधा देता है:
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | क्लाइंट को क्या भेजा जाता है                           | Paraglide की तुलना में             |
+| ------------ | ------------------------------------------------------ | ---------------------------------- |
+| `static`     | पेज द्वारा उपयोग की जाने वाली डिक्शनरी के सभी लोकेल्स  | सैद्धांतिक रूप से समान सामग्री     |
+| `dynamic`    | केवल वर्तमान लोकेल, प्रति डिक्शनरी लेज़ी-लोड किया गया  | N भाषाओं में **N गुना अधिक हल्का** |
+| `fetch`      | केवल वर्तमान लोकेल, Live Sync API के माध्यम से प्राप्त | N भाषाओं में **N गुना अधिक हल्का** |
+
+[बिल्ड ट्रांसफ़ॉर्मेशन](https://intlayer.org/hi/doc/concept/bundle-optimization) और `importMode: 'static'` के साथ, Intlayer सैद्धांतिक रूप से Paraglide के समान ही सामग्री लोड करता है। `'dynamic'` या `'fetch'` के साथ, यह केवल वही लोड करता है जिसकी वर्तमान लोकेल को आवश्यकता होती है: N भाषाओं वाले ऐप के लिए, अनुवाद पेलोड Paraglide की तुलना में N गुना छोटा होता है।
+
+## Paraglide कहाँ अभी भी उपयुक्त है
+
+<AccordionGroup>
+<Accordion header="कम भाषाओं के साथ Svelte + Vite">
+
+यदि आपका स्टैक Vite के साथ Svelte है और आप दो या तीन भाषाओं का समर्थन करते हैं, तो Tree shaking विज्ञापनों के अनुसार काम करता है और लोकेल का ओवरहेड छोटा रहता है।
+
+</Accordion>
+<Accordion header="मौजूदा inlang वर्कफ़्लो">
+
+यदि आपकी टीम पहले से ही inlang पारिस्थितिकी तंत्र (Fink, Sherlock, मैसेज फॉर्मेट प्लगइन्स) का उपयोग करती है, तो Paraglide इसके साथ मूल रूप से एकीकृत होता है।
+
+</Accordion>
+</AccordionGroup>
+
+## अपने ऐप पर इसे आज़माएं
+
+मुफ़्त [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) के साथ अपने लाइव एप्लिकेशन के पेलोड और लोकेल लीकेज की जाँच करें:
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Intlayer सेट अप करने के लिए:
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## अतिरिक्त संदर्भ
+
+- [TanStack Start i18n बेंचमार्क](https://intlayer.org/hi/doc/benchmark/tanstack)
+- [Next.js i18n बेंचमार्क](https://intlayer.org/hi/doc/benchmark/nextjs)
+- [बंडल अनुकूलन और `importMode`](https://intlayer.org/hi/doc/concept/bundle-optimization)
+- [React i18n लाइब्रेरी कैसे चुनें](https://intlayer.org/hi/blog/how-to-pick-react-i18n-library)
+- [कंपाइलर-संचालित अंतर्राष्ट्रीयकरण के पक्ष और विपक्ष](https://intlayer.org/hi/blog/compiler-vs-declarative-i18n)