@intlayer/docs 8.9.4 → 8.9.6-canary.0

package/docs/hi/benchmark/solid.md

@@ -0,0 +1,155 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 में Solid के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
+description: solid-primitives, solid-i18next, और Intlayer जैसे Solid अंतर्राष्ट्रीयकरण (i18n) पुस्तकालयों की तुलना करें। बंडल आकार, लीकेज और प्रतिक्रियाशीलता पर विस्तृत प्रदर्शन रिपोर्ट।
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - solid
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - solid
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "बेंचमार्क प्रारंभ"
+---
+
+# Solid i18n पुस्तकालय — 2026 बेंचमार्क रिपोर्ट
+
+यह पृष्ठ Solid पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।
+
+## विषय सूची
+
+<Toc/>
+
+## इंटरैक्टिव बेंचमार्क
+
+<I18nBenchmark framework="vite-solid" vertical/>
+
+## परिणाम संदर्भ:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.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-vite_solid.md
+
+संपूर्ण बेंचमार्क रिपॉजिटरी [यहाँ](https://github.com/intlayer-org/benchmark-i18n/tree/main) देखें।
+
+## परिचय
+
+Solid ऐप में अंतर्राष्ट्रीयकरण (Internationalisation) समाधान सबसे भारी निर्भरताओं में से हैं। मुख्य जोखिम अनावश्यक सामग्री भेजने का है: एक ही रूट के बंडल में अन्य पृष्ठों और अन्य लोकेल्स के अनुवाद शामिल करना।
+
+जैसे-जैसे आपका ऐप बढ़ता है, यह समस्या क्लाइंट को भेजे जाने वाले JavaScript को तेज़ी से बढ़ा सकती है और नेविगेशन को धीमा कर सकती है।
+
+व्यवहार में, कम से कम अनुकूलित कार्यान्वयन के लिए, एक अंतर्राष्ट्रीयकृत पृष्ठ बिना i18n वाले संस्करण की तुलना में कई गुना भारी हो सकता है।
+
+दूसरा प्रभाव डेवलपर अनुभव (DX) पर पड़ता है: आप सामग्री, प्रकार (types), नेमस्पेस संगठन, डायनेमिक लोडिंग और लोकेल बदलने पर प्रतिक्रियाशीलता को कैसे घोषित करते हैं।
+
+## TL;DR
+
+- **Intlayer**: उन्नत सुविधाओं और अनुकूलन की आवश्यकता वाले पेशेवर Solid अनुप्रयोगों के लिए अनुशंसित विकल्प (v8.7.12)।
+- **@solid-primitives/i18n**: सरल परियोजनाओं के लिए उत्कृष्ट हल्का विकल्प, हालांकि इसमें लेज़ी लोडिंग (lazy loading) जैसी उन्नत सुविधाओं का अभाव है।
+- **solid-i18next**: मानक लेकिन भारी विकल्प (~4.7x Intlayer) जिसमें React i18next वाले ही नकारात्मक पक्ष हैं।
+- **Paraglide**: अभिनव दृष्टिकोण लेकिन जटिल DX और कुछ सेटअपों में ट्री-शेकिंग (tree-shaking) के मुद्दे।
+
+## अपने ऐप का परीक्षण करें
+
+i18n लीकेज समस्याओं को तुरंत पहचानने के लिए, मैंने एक निःशुल्क स्कैनर सेट किया है जो [यहाँ](https://intlayer.org/i18n-seo-scanner) उपलब्ध है।
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## समस्या
+
+बहुभाषी ऐप की लागत को सीमित करने के लिए दो लीवर आवश्यक हैं:
+
+- सामग्री को पृष्ठ / नेमस्पेस द्वारा विभाजित करें ताकि जरूरत न होने पर आप संपूर्ण शब्दकोश लोड न करें।
+- सही लोकेल को डायनेमिक रूप से लोड करें, केवल तभी जब आवश्यक हो।
+
+इन दृष्टिकोणों की तकनीकी सीमाओं को समझना:
+
+**डायनेमिक लोडिंग**
+
+डायनेमिक लोडिंग के बिना, अधिकांश समाधान पहले रेंडर से संदेशों को मेमोरी में रखते हैं, जो कई रूट्स और लोकेल्स वाले ऐप्स के लिए महत्वपूर्ण ओवरहेड जोड़ता है।
+
+डायनेमिक लोडिंग के साथ, आप एक समझौता स्वीकार करते हैं: कम प्रारंभिक JS, लेकिन भाषा स्विच करते समय कभी-कभी एक अतिरिक्त अनुरोध।
+
+**सामग्री विभाजन (Splitting)**
+
+`t('a.b.c')` के इर्द-गिर्द निर्मित सिंटैक्स बहुत सुविधाजनक हैं लेकिन अक्सर रनटाइम पर बड़ी JSON वस्तुओं को रखने के लिए प्रोत्साहित करते हैं। वह मॉडल ट्री-शेकिंग (tree-shaking) को कठिन बनाता है जब तक कि पुस्तकालय वास्तविक प्रति-पृष्ठ विभाजन रणनीति प्रदान नहीं करता।
+
+## अनुसंधान पद्धति
+
+इस बेंचमार्क के लिए, हमने निम्नलिखित पुस्तकालयों की तुलना की:
+
+- `Base App` (कोई i18n पुस्तकालय नहीं)
+- `solid-intlayer` (v8.7.12)
+- `@solid-primitives/i18n` (v2.2.1)
+- `solid-i18next` (v17.0.2)
+- `@inlang/paraglide-js` (v2.17.0)
+
+फ्रेमवर्क `Solid` है जिसमें **10 पृष्ठों** और **10 भाषाओं** का एक बहुभाषी ऐप है।
+
+हमने **चार लोडिंग रणनीतियों** की तुलना की:
+
+| रणनीति              | कोई नेमस्पेस नहीं (वैश्विक)                 | नेमस्पेस के साथ (स्कोपयुक्त/scoped)                                  |
+| :------------------ | :------------------------------------------ | :------------------------------------------------------------------- |
+| **स्टेटिक लोडिंग**  | **Static**: स्टार्टअप पर मेमोरी में सब कुछ। | **Scoped static**: नेमस्पेस द्वारा विभाजित; स्टार्टअप पर सब कुछ लोड। |
+| **डायनेमिक लोडिंग** | **Dynamic**: लोकेल प्रति मांग पर लोडिंग।    | **Scoped dynamic**: नेमस्पेस और लोकेल प्रति सूक्ष्म लोडिंग।          |
+
+## रणनीति सारांश
+
+- **Static**: सरल; प्रारंभिक लोड के बाद कोई नेटवर्क विलंबता नहीं। नकारात्मक पक्ष: बड़ा बंडल आकार।
+- **Dynamic**: प्रारंभिक वजन कम करता है (लेज़ी-लोडिंग)। आदर्श जब आपके पास कई लोकेल्स हों।
+- **Scoped static**: जटिल अतिरिक्त नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित रखता है (तार्किक पृथक्करण)।
+- **Scoped dynamic**: _कोड स्प्लिटिंग_ और प्रदर्शन के लिए सर्वोत्तम दृष्टिकोण। केवल वर्तमान दृश्य और सक्रिय लोकेल के लिए आवश्यक सामग्री लोड करके मेमोरी को कम करता है।
+
+## विवरण में परिणाम
+
+### 1 — बचने के लिए समाधान
+
+> Solid पारिस्थितिकी तंत्र में बचने के लिए कोई स्पष्ट समाधान नहीं है।
+
+### 2 — स्वीकार्य समाधान
+
+**(solid-i18next)** (`solid-i18next@17.0.2`):
+
+`solid-i18next` शायद सबसे लोकप्रिय विकल्प है क्योंकि यह JavaScript ऐप i18n जरूरतों को पूरा करने वाले पहले समाधानों में से एक था। इसमें विशिष्ट समस्याओं के लिए सामुदायिक प्लगइन्स का एक विस्तृत सेट भी है।
+
+पैकेज भारी है (~14.6kb, जो `solid-intlayer` से लगभग 4.7 गुना है)।
+
+फिर भी, यह `t('a.b.c')` पर बने स्टैक्स के समान ही प्रमुख नकारात्मक पक्ष साझा करता है: अनुकूलन संभव है लेकिन बहुत समय लेने वाला है, और बड़ी परियोजनाओं में खराब प्रथाओं (नेमस्पेस + डायनेमिक लोडिंग + प्रकार) का जोखिम होता है।
+
+**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):
+
+Solid primitive बेहद हल्का और कुशल है। मैं उन परियोजनाओं के लिए इस समाधान की अनुशंसा करता हूं जो बहुत हल्की हैं, लेकिन इसमें पेशेवर समाधानों के लिए सुविधाओं की जल्दी कमी हो सकती है जिसमें कुकी प्रबंधन, प्रॉक्सी पुनर्निर्देशन, फ़ॉर्मेटर्स आदि शामिल हैं।
+इसमें पृष्ठ आकार अनुकूलन के लिए लेज़ी लोडिंग और स्कोपिंग नेमस्पेस की भी कमी है।
+
+**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+
+`Paraglide` एक अभिनव, सुविचारित दृष्टिकोण प्रदान करता है। फिर भी, इस बेंचमार्क में उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग मेरे कार्यान्वयन के लिए काम नहीं कर पाई। वर्कफ़्लो और DX भी अन्य विकल्पों की तुलना में अधिक जटिल हैं।
+व्यक्तिगत रूप से मैं हर पुश से पहले JS फ़ाइलों को पुनर्जीवित करना पसंद नहीं करता, जो PR के माध्यम से निरंतर मर्ज संघर्ष जोखिम पैदा करता है।
+अंत में, अन्य समाधानों की तुलना में, Paraglide सामग्री रेंडर करने के लिए वर्तमान लोकेल को पुनः प्राप्त करने के लिए स्टोर (उदा. Solid signal) का उपयोग नहीं करता है। पार्स किए गए प्रत्येक नोड के लिए, यह localStorage / cookie आदि से लोकेल का अनुरोध करेगा। यह अनावश्यक तर्क के निष्पादन की ओर ले जाता है जो घटक प्रतिक्रियाशीलता को प्रभावित करता है।
+
+### 3 — सिफारिशें
+
+**(Intlayer)** (`solid-intlayer@8.7.12`):
+
+मैं निष्पक्षता के लिए व्यक्तिगत रूप से `solid-intlayer` का न्याय नहीं करूँगा, क्योंकि यह मेरा अपना समाधान है।
+
+### व्यक्तिगत नोट
+
+यह नोट व्यक्तिगत है और बेंचमार्क परिणामों को प्रभावित नहीं करता है। फिर भी, i18n दुनिया में आप अक्सर अनुवादित सामग्री के लिए `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` जैसे पैटर्न के आसपास आम सहमति देखते हैं।
+
+Solid ऐप्स में, एक फ़ंक्शन को `JSX.Element` के रूप में इंजेक्ट करना, मेरी नज़र में, एक एंटी-पैटर्न है। यह परिहार्य जटिलता और JavaScript निष्पादन ओवरहेड भी जोड़ता है (भले ही यह मुश्किल से ध्यान देने योग्य हो)।

package/docs/hi/benchmark/svelte.md

@@ -0,0 +1,148 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 में Svelte के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
+description: svelte-i18n, Paraglide, और Intlayer जैसे Svelte अंतर्राष्ट्रीयकरण (i18n) पुस्तकालयों की तुलना करें। बंडल आकार, लीकेज और प्रतिक्रियाशीलता पर विस्तृत प्रदर्शन रिपोर्ट।
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - svelte
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - svelte
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "बेंचमार्क प्रारंभ"
+---
+
+# Svelte i18n पुस्तकालय — 2026 बेंचमार्क रिपोर्ट
+
+यह पृष्ठ Svelte पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।
+
+## विषय सूची
+
+<Toc/>
+
+## इंटरैक्टिव बेंचमार्क
+
+<I18nBenchmark framework="vite-svelte" vertical/>
+
+## परिणाम संदर्भ:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_svelte.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-vite_svelte.md
+
+संपूर्ण बेंचमार्क रिपॉजिटरी [यहाँ](https://github.com/intlayer-org/benchmark-i18n/tree/main) देखें।
+
+## परिचय
+
+Svelte ऐप में अंतर्राष्ट्रीयकरण (Internationalisation) समाधान सबसे भारी निर्भरताओं में से हैं। मुख्य जोखिम अनावश्यक सामग्री भेजने का है: एक ही रूट के बंडल में अन्य पृष्ठों और अन्य लोकेल्स के अनुवाद शामिल करना।
+
+जैसे-जैसे आपका ऐप बढ़ता है, यह समस्या क्लाइंट को भेजे जाने वाले JavaScript को तेज़ी से बढ़ा सकती है और नेविगेशन को धीमा कर सकती है।
+
+व्यवहार में, कम से कम अनुकूलित कार्यान्वयन के लिए, एक अंतर्राष्ट्रीयकृत पृष्ठ बिना i18n वाले संस्करण की तुलना में कई गुना भारी हो सकता है।
+
+दूसरा प्रभाव डेवलपर अनुभव (DX) पर पड़ता है: आप सामग्री, प्रकार (types), नेमस्पेस संगठन, डायनेमिक लोडिंग और लोकेल बदलने पर प्रतिक्रियाशीलता को कैसे घोषित करते हैं।
+
+## TL;DR
+
+- **Intlayer**: सबसे छोटे पदचिह्न (footprint) के साथ सबसे प्रदर्शन-कुशल विकल्प (v8.7.12)।
+- **Paraglide**: ट्री-शेकिंग (tree-shaking) के लिए मजबूत दावेदार लेकिन इसमें अधिक जटिल डेवलपर अनुभव और प्रतिक्रियाशीलता ओवरहेड है।
+- **svelte-i18n**: Svelte के लिए व्यापक और मानक, लेकिन बहुत बड़े बंडल वजन (~7x Intlayer) के साथ आता है।
+
+## अपने ऐप का परीक्षण करें
+
+i18n लीकेज समस्याओं को तुरंत पहचानने के लिए, मैंने एक निःशुल्क स्कैनर सेट किया है जो [यहाँ](https://intlayer.org/i18n-seo-scanner) उपलब्ध है।
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## समस्या
+
+बहुभाषी ऐप की लागत को सीमित करने के लिए दो लीवर आवश्यक हैं:
+
+- सामग्री को पृष्ठ / नेमस्पेस द्वारा विभाजित करें ताकि जरूरत न होने पर आप संपूर्ण शब्दकोश लोड न करें।
+- सही लोकेल को डायनेमिक रूप से लोड करें, केवल तभी जब आवश्यक हो।
+
+इन दृष्टिकोणों की तकनीकी सीमाओं को समझना:
+
+**डायनेमिक लोडिंग**
+
+डायनेमिक लोडिंग के बिना, अधिकांश समाधान पहले रेंडर से संदेशों को मेमोरी में रखते हैं, जो कई रूट्स और लोकेल्स वाले ऐप्स के लिए महत्वपूर्ण ओवरहेड जोड़ता है।
+
+डायनेमिक लोडिंग के साथ, आप एक समझौता स्वीकार करते हैं: कम प्रारंभिक 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 भाषाओं** का एक बहुभाषी ऐप है।
+
+हमने **चार लोडिंग रणनीतियों** की तुलना की:
+
+| रणनीति              | कोई नेमस्पेस नहीं (वैश्विक)                 | नेमस्पेस के साथ (स्कोपयुक्त/scoped)                                  |
+| :------------------ | :------------------------------------------ | :------------------------------------------------------------------- |
+| **स्टेटिक लोडिंग**  | **Static**: स्टार्टअप पर मेमोरी में सब कुछ। | **Scoped static**: नेमस्पेस द्वारा विभाजित; स्टार्टअप पर सब कुछ लोड। |
+| **डायनेमिक लोडिंग** | **Dynamic**: लोकेल प्रति मांग पर लोडिंग।    | **Scoped dynamic**: नेमस्पेस और लोकेल प्रति सूक्ष्म लोडिंग।          |
+
+## रणनीति सारांश
+
+- **Static**: सरल; प्रारंभिक लोड के बाद कोई नेटवर्क विलंबता नहीं। नकारात्मक पक्ष: बड़ा बंडल आकार।
+- **Dynamic**: प्रारंभिक वजन कम करता है (लेज़ी-लोडिंग)। आदर्श जब आपके पास कई लोकेल्स हों।
+- **Scoped static**: जटिल अतिरिक्त नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित रखता है (तार्किक पृथक्करण)।
+- **Scoped dynamic**: _कोड स्प्लिटिंग_ और प्रदर्शन के लिए सर्वोत्तम दृष्टिकोण। केवल वर्तमान दृश्य और सक्रिय लोकेल के लिए आवश्यक सामग्री लोड करके मेमोरी को कम करता है।
+
+## विवरण में परिणाम
+
+### 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 निष्पादन ओवरहेड भी जोड़ता है (भले ही यह मुश्किल से ध्यान देने योग्य हो)।

package/docs/hi/benchmark/tanstack.md

@@ -57,6 +57,13 @@ history:
 
 दूसरा प्रभाव डेवलपर अनुभव (DX) पर पड़ता है: आप सामग्री को कैसे घोषित करते हैं, टाइप्स, नेमस्पेस संगठन, डायनेमिक लोडिंग, और लोकेल बदलने पर रिएक्टिविटी।
 
+## TL;DR
+
+- **Intlayer**: TanStack Start के लिए सर्वश्रेष्ठ प्रदर्शन और सबसे छोटा बंडल आकार (v8.7.12) प्रदान करता है।
+- **react-i18next** और **use-intl**: बड़े ईकोसिस्टम वाले परिपक्व विकल्प, लेकिन अनुकूलन के लिए काफी भारी और अधिक जटिल।
+- **Paraglide**: अभिनव ट्री-शेकिंग विचार जो व्यवहार में काम नहीं करता है। TanStack Start में जटिल DX और रिएक्टिविटी ओवरहेड।
+- **बचें**: **General Translation (GT)** और **Lingo.dev** गंभीर प्रदर्शन समस्याओं, AI कोटा सीमाओं और वेंडर लॉक-इन (vendor lock-in) के कारण।
+
 ## अपने ऐप का परीक्षण करें
 
 i18n लीकेज के मुद्दों को तेज़ी से पहचानने के लिए, मैंने एक मुफ़्त स्कैनर सेट किया है जो [यहाँ](https://intlayer.org/i18n-seo-scanner) उपलब्ध है।
@@ -87,12 +94,12 @@ i18n लीकेज के मुद्दों को तेज़ी से
 इस बेंचमार्क के लिए, हमने निम्नलिखित लाइब्रेरीज़ की तुलना की है:
 
 - `Base App` (कोई i18n लाइब्रेरी नहीं)
-- `react-intlayer` (v8.7.5-canary.0)
+- `react-intlayer` (v8.7.12)
 - `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)
+- `@tolgee/react` (v7.0.0)
 - `react-intl` (v10.1.1)
 - `wuchale` (v0.22.11)
 - `gt-react` (vlatest)
@@ -150,7 +157,9 @@ i18n लीकेज के मुद्दों को तेज़ी से
 
 `Paraglide` एक अभिनव, अच्छी तरह से सोचा गया दृष्टिकोण प्रदान करता है। फिर भी, इस बेंचमार्क में उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग मेरे Next.js कार्यान्वयन या TanStack Start के लिए काम नहीं कर पाया। वर्कफ़्लो और DX अन्य विकल्पों की तुलना में अधिक जटिल हैं। व्यक्तिगत रूप से मैं हर पुश से पहले JS फ़ाइलों को दोबारा उत्पन्न करने का प्रशंसक नहीं हूँ, जो PR के माध्यम से डेवलपर्स के लिए लगातार मर्ज संघर्ष का जोखिम पैदा करता है।
 
-**(Tolgee)** (`tolgee@7.0.0`):
+> paraglide पर नोट: यह समाधान आयात के लिए आपके कोडबेस में कोड इंजेक्ट करता है, जिसके परिणामस्वरूप बेंचमार्क रिपोर्ट में 'lib size' मीट्रिक लगभग 0 है। कोड जनरेशन एक अच्छी चीज़ है, क्योंकि उपयोग किया गया फ़ंक्शन केवल आवश्यक लॉजिक (हर जगह प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकी बनाम स्टोरेज, आदि) शामिल करेगा। इसके विपरीत, Intlayer बिल्ड में एनवायरनमेंट वेरिएबल इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है ताकि बंडलर को लॉजिक के आधार पर सामग्री को ट्री-शेक करने के लिए मजबूर किया जा सके। इसके लिए धन्यवाद, paraglide और intlayer अंत में i18next या next-intl की तुलना में 6 से 10 गुना हल्के समाधान बन जाते हैं।
+
+**(Tolgee)** (`@tolgee/react@7.0.0`):
 
 `Tolgee` पहले उल्लेखित कई मुद्दों को संबोधित करता है। मुझे लगा कि इसे शुरू करना समान दृष्टिकोण वाले अन्य उपकरणों की तुलना में कठिन है। यह टाइप सेफ्टी प्रदान नहीं करता है, जिससे कंपाइल समय पर गायब कीज़ को पकड़ना भी बहुत कठिन हो जाता है। गायब-की पहचान जोड़ने के लिए मुझे Tolgee की APIs को अपनी APIs के साथ रैप करना पड़ा।
 

package/docs/hi/benchmark/vue.md

@@ -0,0 +1,160 @@
+---
+createdAt: 2026-04-20
+updatedAt: 2026-04-21
+title: 2026 में Vue के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
+description: vue-i18n, fluent-vue, और Intlayer जैसे Vue अंतर्राष्ट्रीयकरण (i18n) पुस्तकालयों की तुलना करें। बंडल आकार, लीकेज और प्रतिक्रियाशीलता पर विस्तृत प्रदर्शन रिपोर्ट।
+keywords:
+  - benchmark
+  - i18n
+  - intl
+  - vue
+  - performance
+  - intlayer
+slugs:
+  - doc
+  - benchmark
+  - vue
+author: Aymeric PINEAU
+applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
+history:
+  - version: 8.7.12
+    date: 2026-01-06
+    changes: "बेंचमार्क प्रारंभ"
+---
+
+# Vue i18n पुस्तकालय — 2026 बेंचमार्क रिपोर्ट
+
+यह पृष्ठ Vue पर i18n समाधानों के लिए एक बेंचमार्क रिपोर्ट है।
+
+## विषय सूची
+
+<Toc/>
+
+## इंटरैक्टिव बेंचमार्क
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+## परिणाम संदर्भ:
+
+<iframe 
+  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.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-vite_vue.md
+
+संपूर्ण बेंचमार्क रिपॉजिटरी [यहाँ](https://github.com/intlayer-org/benchmark-i18n/tree/main) देखें।
+
+## परिचय
+
+Vue ऐप में अंतर्राष्ट्रीयकरण (Internationalisation) समाधान सबसे भारी निर्भरताओं में से हैं। मुख्य जोखिम अनावश्यक सामग्री भेजने का है: एक ही रूट के बंडल में अन्य पृष्ठों और अन्य लोकेल्स के अनुवाद शामिल करना।
+
+जैसे-जैसे आपका ऐप बढ़ता है, यह समस्या क्लाइंट को भेजे जाने वाले JavaScript को तेज़ी से बढ़ा सकती है और नेविगेशन को धीमा कर सकती है।
+
+व्यवहार में, कम से कम अनुकूलित कार्यान्वयन के लिए, एक अंतर्राष्ट्रीयकृत पृष्ठ बिना i18n वाले संस्करण की तुलना में कई गुना भारी हो सकता है।
+
+दूसरा प्रभाव डेवलपर अनुभव (DX) पर पड़ता है: आप सामग्री, प्रकार (types), नेमस्पेस संगठन, डायनेमिक लोडिंग और लोकेल बदलने पर प्रतिक्रियाशीलता को कैसे घोषित करते हैं।
+
+## TL;DR
+
+- **Intlayer**: मूल स्कोपिंग (scoping) और डायनेमिक लोडिंग के साथ सबसे हल्का समाधान (v8.7.12)।
+- **vue-i18n**: एक समृद्ध पारिस्थितिकी तंत्र के साथ उद्योग मानक, लेकिन बड़े अनुप्रयोगों में महत्वपूर्ण रूप से भारी हो सकता है और कोड-स्प्लिटिंग के लिए अनुकूलित करना कठिन हो सकता है।
+- **fluent-vue**: अभिनव संदेश संगठन लेकिन इसमें टाइप-सेफ्टी की कमी है और यह एक अत्यंत भारी समाधान साबित होता है।
+
+## अपने ऐप का परीक्षण करें
+
+i18n लीकेज समस्याओं को तुरंत पहचानने के लिए, मैंने एक निःशुल्क स्कैनर सेट किया है जो [यहाँ](https://intlayer.org/i18n-seo-scanner) उपलब्ध है।
+
+<iframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+## समस्या
+
+बहुभाषी ऐप की लागत को सीमित करने के लिए दो लीवर आवश्यक हैं:
+
+- सामग्री को पृष्ठ / नेमस्पेस द्वारा विभाजित करें ताकि जरूरत न होने पर आप संपूर्ण शब्दकोश लोड न करें।
+- सही लोकेल को डायनेमिक रूप से लोड करें, केवल तभी जब आवश्यक हो।
+
+इन दृष्टिकोणों की तकनीकी सीमाओं को समझना:
+
+**डायनेमिक लोडिंग**
+
+डायनेमिक लोडिंग के बिना, अधिकांश समाधान पहले रेंडर से संदेशों को मेमोरी में रखते हैं, जो कई रूट्स और लोकेल्स वाले ऐप्स के लिए महत्वपूर्ण ओवरहेड जोड़ता है।
+
+डायनेमिक लोडिंग के साथ, आप एक समझौता स्वीकार करते हैं: कम प्रारंभिक JS, लेकिन भाषा स्विच करते समय कभी-कभी एक अतिरिक्त अनुरोध।
+
+**सामग्री विभाजन (Splitting)**
+
+`const { t } = useI18n()` + `t('a.b.c')` के इर्द-गिर्द निर्मित सिंटैक्स बहुत सुविधाजनक हैं लेकिन अक्सर रनटाइम पर बड़ी JSON वस्तुओं को रखने के लिए प्रोत्साहित करते हैं। वह मॉडल ट्री-शेकिंग (tree-shaking) को कठिन बनाता है जब तक कि पुस्तकालय वास्तविक प्रति-पृष्ठ विभाजन रणनीति प्रदान नहीं करता।
+
+## अनुसंधान पद्धति
+
+इस बेंचमार्क के लिए, हमने निम्नलिखित पुस्तकालयों की तुलना की:
+
+- `Base App` (कोई i18n पुस्तकालय नहीं)
+- `vue-intlayer` (v8.7.12)
+- `vue-i18n` (v11.4.0)
+- `fluent-vue` (v3.8.2)
+
+फ्रेमवर्क `Vue` है जिसमें **10 पृष्ठों** और **10 भाषाओं** का एक बहुभाषी ऐप है।
+
+हमने **चार लोडिंग रणनीतियों** की तुलना की:
+
+| रणनीति              | कोई नेमस्पेस नहीं (वैश्विक)                 | नेमस्पेस के साथ (स्कोपयुक्त/scoped)                                  |
+| :------------------ | :------------------------------------------ | :------------------------------------------------------------------- |
+| **स्टेटिक लोडिंग**  | **Static**: स्टार्टअप पर मेमोरी में सब कुछ। | **Scoped static**: नेमस्पेस द्वारा विभाजित; स्टार्टअप पर सब कुछ लोड। |
+| **डायनेमिक लोडिंग** | **Dynamic**: लोकेल प्रति मांग पर लोडिंग।    | **Scoped dynamic**: नेमस्पेस और लोकेल प्रति सूक्ष्म लोडिंग।          |
+
+## रणनीति सारांश
+
+- **Static**: सरल; प्रारंभिक लोड के बाद कोई नेटवर्क विलंबता नहीं। नकारात्मक पक्ष: बड़ा बंडल आकार।
+- **Dynamic**: प्रारंभिक वजन कम करता है (लेज़ी-लोडिंग)। आदर्श जब आपके पास कई लोकेल्स हों।
+- **Scoped static**: जटिल अतिरिक्त नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित रखता है (तार्किक पृथक्करण)।
+- **Scoped dynamic**: _कोड स्प्लिटिंग_ और प्रदर्शन के लिए सर्वोत्तम दृष्टिकोण। केवल वर्तमान दृश्य और सक्रिय लोकेल के लिए आवश्यक सामग्री लोड करके मेमोरी को कम करता है।
+
+### मैंने क्या मापा:
+
+मैंने प्रत्येक स्टैक के लिए एक वास्तविक ब्राउज़र में एक ही बहुभाषी ऐप चलाया, फिर लिखा कि वास्तव में नेटवर्क पर क्या दिखाई दिया और चीजों में कितना समय लगा। आकार **सामान्य वेब संपीड़न के बाद** रिपोर्ट किए गए हैं, क्योंकि यह कच्चे स्रोत गणनाओं की तुलना में लोगों द्वारा वास्तव में डाउनलोड की जाने वाली सामग्री के करीब है।
+
+- **अंतर्राष्ट्रीयकरण पुस्तकालय आकार**: बंडलिंग, ट्री-शेकिंग और मिनिफिकेशन के बाद, i18n पुस्तकालय का आकार एक खाली घटक में प्रदाताओं (providers) + कंपोजेबल्स (composables) कोड का आकार है। इसमें अनुवाद फ़ाइलों की लोडिंग शामिल नहीं है। यह उत्तर देता है कि आपकी सामग्री चित्र में आने से पहले पुस्तकालय कितना "महंगा" है।
+
+- **प्रति पृष्ठ JavaScript**: प्रत्येक बेंचमार्क रूट के लिए, ब्राउज़र उस विज़िट के लिए कितना स्क्रिप्ट खींचता है, सूट के पृष्ठों (और लोकेल्स में) में औसत। भारी पृष्ठ धीमे पृष्ठ होते हैं।
+
+- **अन्य लोकेल्स से लीकेज (Leakage)**: यह उसी पृष्ठ की सामग्री है लेकिन दूसरी भाषा में जो ऑडिट किए गए पृष्ठ में गलती से लोड हो जाएगी। यह सामग्री अनावश्यक है और इससे बचा जाना चाहिए (उदा: `/en/about` पृष्ठ बंडल में `/fr/about` पृष्ठ सामग्री)।
+
+- **अन्य रूट्स से लीकेज**: ऐप में **अन्य स्क्रीन** के लिए भी यही विचार: क्या उनकी प्रतिलिपि तब आ रही है जब आपने केवल एक पृष्ठ खोला है (उदा: `/en/contact` पृष्ठ बंडल में `/en/about` पृष्ठ सामग्री)। एक उच्च स्कोर कमजोर विभाजन या अत्यधिक व्यापक बंडलों का संकेत देता है।
+
+- **औसत घटक बंडल आकार**: सामान्य UI टुकड़ों को एक विशाल ऐप नंबर के अंदर छिपाने के बजाय **एक बार में एक** मापा जाता है। यह दिखाता है कि क्या अंतर्राष्ट्रीयकरण चुपचाप रोजमर्रा के घटकों को फुलाता है। उदाहरण के लिए, यदि आपका घटक फिर से रेंडर होता है, तो यह मेमोरी से वह सारा डेटा लोड करेगा। किसी भी घटक के साथ एक विशाल JSON संलग्न करना अप्रयुक्त डेटा के एक बड़े स्टोर को जोड़ने जैसा है जो आपके घटकों के प्रदर्शन को धीमा कर देगा।
+
+- **भाषा स्विच प्रतिक्रियाशीलता**: मैं ऐप के अपने नियंत्रण का उपयोग करके भाषा बदलता हूं और समय मापता हूं जब तक कि पृष्ठ स्पष्ट रूप से स्विच नहीं हो जाता, जो एक विज़िटर नोटिस करेगा।
+
+- **भाषा परिवर्तन के बाद रेंडरिंग कार्य**: एक सूक्ष्म अनुवर्ती: स्विच होने के बाद इंटरफ़ेस ने नई भाषा के लिए फिर से पेंट करने के लिए कितना प्रयास किया। उपयोगी है जब "महसूस किया गया" समय और फ्रेमवर्क लागत अलग-अलग होती है।
+
+- **प्रारंभिक पृष्ठ लोड समय**: नेविगेशन से ब्राउज़र द्वारा मेरे द्वारा परीक्षण किए गए परिदृश्यों के लिए पृष्ठ को पूरी तरह से लोड मानने तक। कोल्ड स्टार्ट की तुलना करने के लिए अच्छा है।
+
+- **हाइड्रेशन समय (Hydration)**: ग्राहक सर्वर HTML को एक इंटरैक्टिव इंटरफ़ेस में बदलने में कितना समय बिताता है। तालिकाओं में एक डैश का अर्थ है कि उस कार्यान्वयन ने इस बेंचमार्क में एक विश्वसनीय हाइड्रेशन आंकड़ा प्रदान नहीं किया।
+
+## विवरण में परिणाम
+
+### 1 — बचने के लिए समाधान
+
+> Vue पारिस्थितिकी तंत्र में बचने के लिए कोई स्पष्ट समाधान नहीं है।
+
+### 2 — स्वीकार्य समाधान
+
+**(vue-i18n)** (`vue-i18n@11.4.0`):
+
+- **vue-i18n** निस्संदेह Vue के लिए सबसे अधिक उपयोग किया जाने वाला i18n पुस्तकालय है, इसमें बहुत सारी विशेषताएं और एक विशाल पारिस्थितिकी तंत्र है। लेकिन हुड के तहत समाधान काफी भारी है। भले ही vue-i18n संदेशों के लिए लेज़ी लोडिंग को एकीकृत करता है, लेकिन इसमें स्कोपिंग सुविधा की कमी है। एक क्लासिक Vue SPA ऐप के मामले में कोई समस्या नहीं है, लेकिन @nuxt/i18n का उपयोग करने वाले nuxt ऐप के लिए, यह सभी पृष्ठों के संदेशों को एक ही पृष्ठ में शामिल करने की ओर ले जाता है। 10 से अधिक पृष्ठों वाले बड़े nuxt ऐप के लिए, यह वास्तव में समस्याग्रस्त हो सकता है।
+
+पैकेज बहुत भारी है (~24.3kb, जो `vue-intlayer` से लगभग 9 गुना है)।
+
+**(fluent-vue)** (`fluent-vue@0.5.0`):
+
+- **fluent-vue** .ftl प्रारूप के माध्यम से एक अभिनव प्रयास प्रदान करता है। संदेश संगठन महान है, शुरू करना आसान है। लेकिन व्यवहार में, टाइप-सेफ्टी की कमी त्रुटि के जोखिम को बढ़ाती है और डिबग करने में जल्दी से समय लग सकता है। इसके अलावा, वह समाधान एक vite प्लगइन का उपयोग करके संदेशों को लोड करता है जो प्रत्येक पृष्ठ में सभी भाषाओं में सभी सामग्री को लोड करने के लिए मजबूर करता है। इसके अतिरिक्त यह एक अत्यंत भारी समाधान है (~92.7kb, जो `vue-intlayer` से लगभग 34 गुना है)।
+
+### 3 — सिफारिशें
+
+**(Intlayer)** (`vue-intlayer@8.7.12`):
+
+मैं निष्पक्षता के लिए व्यक्तिगत रूप से `vue-intlayer` का न्याय नहीं करूँगा, क्योंकि यह मेरा अपना समाधान है।