@intlayer/docs 9.5.0 → 9.5.2

package/docs/hi/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 में Next.js के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
 description: next-intl, next-i18next और Intlayer जैसे Next.js अंतर्राष्ट्रीयकरण (i18n) लाइब्रेरीज़ की तुलना करें। बंडल आकार, लीकेज और रिएक्टिविटी पर विस्तृत परफॉरमेंस रिपोर्ट।
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "बेंचमार्क परिणाम अपडेट किए गए"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub स्टार तुलना जोड़ें"
@@ -56,7 +59,7 @@ style="border:none;"
 
 जैसे-जैसे आपका ऐप बढ़ता है, बंडल का आकार तेजी से बढ़ सकता है, जो परफॉरमेंस को काफी नुकसान पहुँचा सकता है।
 
-उदाहरण के तौर पर, सबसे खराब मामलों में, अंतर्राष्ट्रीयकरण के बाद आपका पेज लगभग 4 गुना बड़ा हो सकता है।
+उदाहरण के तौर पर, सबसे खराब मामलों में, अंतर्राष्ट्रीयकरण के बाद आपका पेज लगभग 2 गुना बड़ा हो सकता है।
 
 i18n लाइब्रेरीज़ का एक अन्य प्रभाव धीमा विकास है। कंपोनेंट्स को विभिन्न भाषाओं में बहुभाषी सामग्री में बदलना समय लेने वाला काम है।
 
@@ -68,7 +71,7 @@ Intlayer इन सभी आयामों में अनुकूलन क
 
 - **Intlayer** और **next-translate**: Next.js परफॉरमेंस के लिए सर्वोत्तम विकल्प, जो सबसे छोटा फुटप्रिंट और बेहतरीन स्टेटिक रेंडरिंग सपोर्ट प्रदान करते हैं।
 - **next-intl**: वर्तमान में सबसे ट्रेंडी विकल्प, लेकिन बड़ेप्लिकेशन्स के लिए अनुकूलित करना भारी और जटिल है।
-- **next-i18next**: लोकप्रिय और प्लगइन्स से भरपूर, लेकिन बंडल का आकार काफी अधिक है (~3 गुना Intlayer)।
+- **next-i18next**: लोकप्रिय और प्लगइन्स से भरपूर, लेकिन बंडल का आकार काफी अधिक है (~3.5 गुना Intlayer)।
 - **इनसे बचें**: गंभीर परफॉरमेंस समस्याओं, वेंडर लॉक-इन और बिल्ड को रोकने वाले बग्स के कारण **gt-next** और **lingo.dev** से बचें।
 
 ## अपने ऐप का परीक्षण करें
@@ -109,19 +112,21 @@ Intlayer इन सभी आयामों में अनुकूलन क
 इस बेंचमार्क के लिए, हमने निम्नलिखित लाइब्रेरीज़ की तुलना की है:
 
 - `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-intlayer` (v9.5.1)
+- [`@intlayer/next-intl`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/compat/next-i18next.md) (v9.5.1)
+- `next-i18next` (v16.3.0)
+- `next-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
+- `next-translate` (v3.2.0)
 - `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)
+- `@tolgee/react` (v7.2.0)
+- `@lingo.dev/compiler` (v0.4.12)
+- `wuchale` (v0.26.6)
+- `gt-next` (v11.1.24)
 
-मैंने एप्र राउटर के साथ `Next.js` वर्जन `16.2.4` का उपयोग किया।
+मैंने एप्र राउटर के साथ `Next.js` वर्जन `16.3.4` का उपयोग किया।
 
 मैंने **10 पेजों** और **10 भाषाओं** के साथ एक बहुभाषी ऐप बनाया।
 
@@ -175,15 +180,15 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 सामना किए गए मुद्दे:
 
-**(General Translation)** (`gt-next@6.16.5`):
+**(General Translation)** (`gt-next@11.1.24`):
 
-- 110kb ऐप के लिए, `gt-next` 440kb से अधिक अतिरिक्त डेटा जोड़ता है।
+- 141kb ऐप के लिए, `gt-next` 50kb से अधिक अतिरिक्त डेटा जोड़ता है।
 - जनरल ट्रांसलेशन के साथ पहले ही बिल्ड पर `Quota Exceeded, please upgrade your plan` संदेश।
 - अनुवाद रेंडर नहीं होते हैं; मुझे एरर मिलता है `Error: <T> used on the client-side outside of <GTProvider>` , जो लाइब्रेरी में एक बग लगता है।
 - **gt-next** को लागू करने के दौरान, मुझे लाइब्रेरी के साथ एक [इश्यू](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`):
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.12`):
 
 - AI कोटा समाप्त हो गया, जिससे बिल्ड पूरी तरह से अवरुद्ध हो गया-इसलिए आप भुगतान किए बिना प्रोडक्शन में नहीं जा सकते।
 - कंपाइलर अनुवादित सामग्री के लगभग 40% को मिस कर रहा था। मुझे इसे काम कराने के लिए सभी `.map` को फ्लैट कंपोनेंट ब्लॉक्स में दोबारा लिखना पड़ा।
@@ -192,7 +197,7 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 ### 2 - प्रयोगात्मक समाधान
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 `Wuchale` के पीछे का विचार दिलचस्प है लेकिन अभी तक व्यवहार्य नहीं है। मुझे रिएक्टिविटी के मुद्दों का सामना करना पड़ा और ऐप को काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी। दस्तावेज़ीकरण भी काफी अस्पष्ट है, जिससे ऑनबोर्डिंग कठिन हो जाती है।
 
@@ -202,21 +207,21 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 व्यक्तिगत रूप से मुझे हर पुश से पहले JS फ़ाइलों को दोबारा उत्पन्न करना पसंद नहीं है, जो PR के माध्यम से लगातार मर्ज संघर्ष का जोखिम पैदा करता है। यह टूल Next.js की तुलना में Vite पर अधिक केंद्रित लगता है।
 अंत में, अन्य समाधानों की तुलना में, Paraglide सामग्री रेंडर करने के लिए वर्तमान लोकेल को पुनः प्राप्त करने के लिए स्टोर (उदा. React context) का उपयोग नहीं करता है। पार्स किए गए प्रत्येक नोड के लिए, यह localStorage / कुकी आदि से लोकेल का अनुरोध करेगा। यह अनावश्यक तर्क के निष्पादन की ओर ले जाता है जो कंपोनेंट रिएक्टिविटी को प्रभावित करता है।
 
-> Paraglide पर नोट: यह समाधान इम्पोर्ट के लिए आपके कोडबेस में कोड इंजेक्ट करता है, जिसके परिणामस्वरूप बेंचमार्क रिपोर्ट में 'लाइब्रेरी आकार' मीट्रिक लगभग 0 है। कोड जेनरेशन एक अच्छी चीज़ है, क्योंकि उपयोग किया जाने वाला फंक्शन केवल आवश्यक लॉजिक (सभी प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकीज़ बनाम स्टोरेज, आदि) शामिल करेगा। इसकी तुलना में, Intlayer बिल्ड में एनवायरनमेंट वेरिएबल इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है ताकि बंडलर को लॉजिक के आधार पर सामग्री को ट्री-शेक करने के लिए मजबूर किया जा सके। इसके कारण, paraglide और intlayer अंत में i18next या next-intl की तुलना में 6 से 10 गुना हल्के समाधान साबित होते हैं।
+> Paraglide पर नोट: यह समाधान इम्पोर्ट के लिए आपके कोडबेस में कोड इंजेक्ट करता है, जिसके परिणामस्वरूप बेंचमार्क रिपोर्ट में 'लाइब्रेरी आकार' मीट्रिक लगभग 0 है। कोड जेनरेशन एक अच्छी चीज़ है, क्योंकि उपयोग किया जाने वाला फंक्शन केवल आवश्यक लॉजिक (सभी प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकीज़ बनाम स्टोरेज, आदि) शामिल करेगा। इसकी तुलना में, Intlayer बिल्ड में एनवायरनमेंट वेरिएबल इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है ताकि बंडलर को लॉजिक के आधार पर सामग्री को ट्री-शेक करने के लिए मजबूर किया जा सके। इसके कारण, paraglide और intlayer अंत में i18next या next-intl की तुलना में 3 से 8 गुना हल्के समाधान साबित होते हैं।
 
 ### 3 - स्वीकार्य समाधान
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` पहले उल्लेखित कई मुद्दों को संबोधित करता है। मुझे लगा कि इसे अपनाना समान उपकरणों की तुलना में कठिन है। यह टाइप सेफ्टी (type safety) प्रदान नहीं करता है, जिससे कंपाइल समय पर गायब कीज़ को पकड़ना भी कठिन हो जाता है। गायब-की पहचान जोड़ने के लिए मुझे Tolgee के फंक्शन्स को अपने फंक्शन्स के साथ रैप करना पड़ा।
 
-**(Next Intl)** (`next-intl@4.9.1`):
+**(Next Intl)** (`next-intl@4.14.2`):
 
-`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-intl` वर्तमान में सबसे ट्रेंडी विकल्प है और जिसे AI एजेंट सबसे अधिक पुश करते हैं, लेकिन मेरी दृष्टि में गलत तरीके से। शुरुआत करना आसान है। व्यवहार में, लीकेज को सीमित करने के लिए अनुकूलन जटिल है। डायनेमिक लोडिंग + नेमस्पेसिंग + TypeScript टाइप्स को जोड़ना विकास को बहुत धीमा कर देता है। पैकेज भी काफी भारी है ( `NextIntlClientProvider` + `useTranslations` के लिए ~14.7kb, जो `next-intlayer` के 2.5 गुना से अधिक है)। **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)** (`next-i18next@16.3.0`):
 
-`next-i18next` शायद सबसे लोकप्रिय विकल्प है क्योंकि यह जावास्क्रिप्ट ऐप्स i18n समाधानों में सबसे पहले आया था। इसके कई कम्युनिटी प्लगइन्स हैं। इसमें `next-intl` जैसी ही प्रमुख कमियाँ हैं। पैकेज विशेष रूप से भारी है ( `I18nProvider` + `useTranslation` के लिए ~18kb, `next-intlayer` के लगभग 3 गुना)।
+`next-i18next` शायद सबसे लोकप्रिय विकल्प है क्योंकि यह जावास्क्रिप्ट ऐप्स i18n समाधानों में सबसे पहले आया था। इसके कई कम्युनिटी प्लगइन्स हैं। इसमें `next-intl` जैसी ही प्रमुख कमियाँ हैं। पैकेज विशेष रूप से भारी है ( `I18nProvider` + `useTranslation` के लिए ~19.7kb, `next-intlayer` के लगभग 3.5 गुना)।
 
 मैसेज फॉर्मेट्स भी भिन्न हैं: `next-intl` ICU MessageFormat का उपयोग करता है, जबकि `i18next` अपने स्वयं के फॉर्मेट का उपयोग करता है।
 
@@ -224,17 +229,17 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 `next-international` भी ऊपर उल्लेखित मुद्दों को हल करता है लेकिन `next-intl` या `next-i18next` से बहुत अलग नहीं है। इसमें नेमस्पेस-विशिष्ट अनुवादों के लिए `scopedT()` शामिल है, लेकिन इसका उपयोग करने का बंडल आकार पर लगभग कोई प्रभाव नहीं पड़ता है।
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` की अक्सर प्रशंसा की जाती है। व्यक्तिगत रूप से मुझे `lingui extract` / `lingui compile` वर्कफ़्लो विकल्पों की तुलना में अधिक जटिल लगा, बिना किसी स्पष्ट लाभ के। मैंने असंगत सिंटैक्स भी देखे जो AI को भ्रमित करते हैं (उदा. `t()`, `t''`, `i18n.t()`, `<Trans>`) ।
 
 ### 4 - सिफारिशें
 
-**(Next Translate)** (`next-translate@3.1.2`):
+**(Next Translate)** (`next-translate@3.2.0`):
 
-यदि आप `t()` स्टाइल की API पसंद करते हैं, तो `next-translate` मेरी मुख्य सिफारिश है। यह `next-translate-plugin` के माध्यम से सुंदर ढंग से काम करता है, जो Webpack / Turbopack लोडर के माध्यम से `getStaticProps` में नेमस्पेस लोड करता है। यह यहाँ सबसे हल्का विकल्प भी है (~2.5kb)। नेमस्पेसिंग के पार, कॉन्फ़िगरेशन में प्रति पेज या रूट नेमस्पेस परिभाषित करना अच्छी तरह से सोचा गया है और **next-intl** या **next-i18next** जैसे मुख्य विकल्पों की तुलना में बनाए रखना आसान है। वर्जन `3.1.2` में, मैंने पाया कि स्टेटिक रेंडरिंग काम नहीं करती थी; Next.js डायनेमिक रेंडरिंग पर वापस चला गया।
+यदि आप `t()` स्टाइल की API पसंद करते हैं, तो `next-translate` मेरी मुख्य सिफारिश है। यह `next-translate-plugin` के माध्यम से सुंदर ढंग से काम करता है, जो Webpack / Turbopack लोडर के माध्यम से `getStaticProps` में नेमस्पेस लोड करता है। यह यहाँ के सबसे हल्के विकल्पों में से एक भी है (~3.5kb)। नेमस्पेसिंग के पार, कॉन्फ़िगरेशन में प्रति पेज या रूट नेमस्पेस परिभाषित करना अच्छी तरह से सोचा गया है और **next-intl** या **next-i18next** जैसे मुख्य विकल्पों की तुलना में बनाए रखना आसान है। वर्जन `3.1.2` में, मैंने पाया कि स्टेटिक रेंडरिंग काम नहीं करती थी; Next.js डायनेमिक रेंडरिंग पर वापस चला गया।
 
-**(Intlayer)** (`next-intlayer@8.7.12`):
+**(Intlayer)** (`next-intlayer@9.5.1`):
 
 निष्पक्षता के लिए मैं व्यक्तिगत रूप से मेरे स्वयं के समाधान `next-intlayer` पर निर्णय नहीं दूँगा।
 

package/docs/hi/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 में Solid के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
 description: solid-primitives, solid-i18next, और Intlayer जैसे Solid अंतर्राष्ट्रीयकरण (i18n) पुस्तकालयों की तुलना करें। बंडल आकार, लीकेज और प्रतिक्रियाशीलता पर विस्तृत प्रदर्शन रिपोर्ट।
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "बेंचमार्क परिणाम अपडेट किए गए"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub स्टार तुलना जोड़ें"
@@ -62,9 +65,9 @@ Solid ऐप में अंतर्राष्ट्रीयकरण (Inte
 
 ## TL;DR
 
-- **Intlayer**: उन्नत सुविधाओं और अनुकूलन की आवश्यकता वाले पेशेवर Solid अनुप्रयोगों के लिए अनुशंसित विकल्प (v8.7.12)।
+- **Intlayer**: उन्नत सुविधाओं और अनुकूलन की आवश्यकता वाले पेशेवर Solid अनुप्रयोगों के लिए अनुशंसित विकल्प (v9.5.0)।
 - **@solid-primitives/i18n**: सरल परियोजनाओं के लिए उत्कृष्ट हल्का विकल्प, हालांकि इसमें लेज़ी लोडिंग (lazy loading) जैसी उन्नत सुविधाओं का अभाव है।
-- **solid-i18next**: मानक लेकिन भारी विकल्प (~4.7x Intlayer) जिसमें React i18next वाले ही नकारात्मक पक्ष हैं।
+- **solid-i18next**: मानक लेकिन भारी विकल्प (~3.5x Intlayer) जिसमें React i18next वाले ही नकारात्मक पक्ष हैं।
 - **Paraglide**: अभिनव दृष्टिकोण लेकिन जटिल DX और कुछ सेटअपों में ट्री-शेकिंग (tree-shaking) के मुद्दे।
 
 ## अपने ऐप का परीक्षण करें
@@ -97,10 +100,10 @@ i18n लीकेज समस्याओं को तुरंत पहच
 इस बेंचमार्क के लिए, हमने निम्नलिखित पुस्तकालयों की तुलना की:
 
 - `Base App` (कोई i18n पुस्तकालय नहीं)
-- `solid-intlayer` (v8.7.12)
+- `solid-intlayer` (v9.5.0)
 - `@solid-primitives/i18n` (v2.2.1)
-- `solid-i18next` (v17.0.2)
-- `@inlang/paraglide-js` (v2.17.0)
+- `i18next` (v26.0.8) + `@mbarzda/solid-i18next` (v1.4.1)
+- `@inlang/paraglide-js` (v2.25.1)
 
 फ्रेमवर्क `Solid` है जिसमें **10 पृष्ठों** और **10 भाषाओं** का एक बहुभाषी ऐप है।
 
@@ -154,11 +157,11 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 ### 2 - स्वीकार्य समाधान
 
-**(solid-i18next)** (`solid-i18next@17.0.2`):
+**(solid-i18next)** (`i18next@26.0.8`):
 
 `solid-i18next` शायद सबसे लोकप्रिय विकल्प है क्योंकि यह JavaScript ऐप i18n जरूरतों को पूरा करने वाले पहले समाधानों में से एक था। इसमें विशिष्ट समस्याओं के लिए सामुदायिक प्लगइन्स का एक विस्तृत सेट भी है।
 
-पैकेज भारी है (~14.6kb, जो `solid-intlayer` से लगभग 4.7 गुना है)।
+पैकेज भारी है (~14.9kb, जो `solid-intlayer` से लगभग 3.5 गुना है)।
 
 फिर भी, यह `t('a.b.c')` पर बने स्टैक्स के समान ही प्रमुख नकारात्मक पक्ष साझा करता है: अनुकूलन संभव है लेकिन बहुत समय लेने वाला है, और बड़ी परियोजनाओं में खराब प्रथाओं (नेमस्पेस + डायनेमिक लोडिंग + प्रकार) का जोखिम होता है।
 
@@ -167,7 +170,7 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 Solid primitive बेहद हल्का और कुशल है। मैं उन परियोजनाओं के लिए इस समाधान की अनुशंसा करता हूं जो बहुत हल्की हैं, लेकिन इसमें पेशेवर समाधानों के लिए सुविधाओं की जल्दी कमी हो सकती है जिसमें कुकी प्रबंधन, प्रॉक्सी पुनर्निर्देशन, फ़ॉर्मेटर्स आदि शामिल हैं।
 इसमें पृष्ठ आकार अनुकूलन के लिए लेज़ी लोडिंग और स्कोपिंग नेमस्पेस की भी कमी है।
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` एक अभिनव, सुविचारित दृष्टिकोण प्रदान करता है। फिर भी, इस बेंचमार्क में उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग मेरे कार्यान्वयन के लिए काम नहीं कर पाई। वर्कफ़्लो और DX भी अन्य विकल्पों की तुलना में अधिक जटिल हैं।
 व्यक्तिगत रूप से मैं हर पुश से पहले JS फ़ाइलों को पुनर्जीवित करना पसंद नहीं करता, जो PR के माध्यम से निरंतर मर्ज संघर्ष जोखिम पैदा करता है।
@@ -175,7 +178,7 @@ Solid primitive बेहद हल्का और कुशल है। म
 
 ### 3 - सिफारिशें
 
-**(Intlayer)** (`solid-intlayer@8.7.12`):
+**(Intlayer)** (`solid-intlayer@9.5.0`):
 
 मैं निष्पक्षता के लिए व्यक्तिगत रूप से `solid-intlayer` का न्याय नहीं करूँगा, क्योंकि यह मेरा अपना समाधान है।
 

package/docs/hi/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 में Svelte के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
 description: svelte-i18n, Paraglide, और Intlayer जैसे Svelte अंतर्राष्ट्रीयकरण (i18n) पुस्तकालयों की तुलना करें। बंडल आकार, लीकेज और प्रतिक्रियाशीलता पर विस्तृत प्रदर्शन रिपोर्ट।
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "बेंचमार्क परिणाम अपडेट किए गए"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub स्टार तुलना जोड़ें"
@@ -62,9 +65,9 @@ Svelte ऐप में अंतर्राष्ट्रीयकरण (Int
 
 ## TL;DR
 
-- **Intlayer**: सबसे छोटे पदचिह्न (footprint) के साथ सबसे प्रदर्शन-कुशल विकल्प (v8.7.12)।
+- **Intlayer**: सबसे छोटे पदचिह्न (footprint) के साथ सबसे प्रदर्शन-कुशल विकल्प (v9.5.0)।
 - **Paraglide**: ट्री-शेकिंग (tree-shaking) के लिए मजबूत दावेदार लेकिन इसमें अधिक जटिल डेवलपर अनुभव और प्रतिक्रियाशीलता ओवरहेड है।
-- **svelte-i18n**: Svelte के लिए व्यापक और मानक, लेकिन बहुत बड़े बंडल वजन (~7x Intlayer) के साथ आता है।
+- **svelte-i18n**: Svelte के लिए व्यापक और मानक, लेकिन बहुत बड़े बंडल वजन (~4.5x Intlayer) के साथ आता है।
 
 ## अपने ऐप का परीक्षण करें
 
@@ -96,9 +99,9 @@ i18n लीकेज समस्याओं को तुरंत पहच
 इस बेंचमार्क के लिए, हमने निम्नलिखित पुस्तकालयों की तुलना की:
 
 - `Base App` (कोई i18n पुस्तकालय नहीं)
-- `svelte-intlayer` (v8.7.12)
+- `svelte-intlayer` (v9.5.0)
 - `svelte-i18n` (v4.0.1)
-- `@inlang/paraglide-js` (v2.17.0)
+- `@inlang/paraglide-js` (v2.25.1)
 
 फ्रेमवर्क `Svelte` है जिसमें **10 पृष्ठों** और **10 भाषाओं** का एक बहुभाषी ऐप है।
 
@@ -152,7 +155,7 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 ### 2 - स्वीकार्य समाधान
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` एक अभिनव, सुविचारित दृष्टिकोण प्रदान करता है। Vite + Svelte ऐप के संदर्भ में, उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग अपेक्षा के अनुरूप काम करती है, जो बहुत अच्छी बात है।
 लेकिन React + TanStack Start के मामले में, ट्री-शेकिंग ने अपेक्षा के अनुरूप काम नहीं किया, Next.js के लिए भी यही स्थिति रही। उस ने कहा, Svelte और TanStack Start प्रोजेक्ट में Paraglide के उपयोग की दोबारा जांच करना सार्थक होगा।
@@ -162,13 +165,13 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 > Paraglide पर ध्यान दें: समाधान आयात के लिए आपके कोडबेस में कोड इंजेक्ट करता है; परिणामस्वरूप, बेंचमार्क रिपोर्ट में 'lib size' मीट्रिक लगभग 0 है। कोड जेनरेशन एक अच्छी बात है, क्योंकि उपयोग किए गए फ़ंक्शन में केवल आवश्यक तर्क शामिल होंगे (हर जगह प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकी बनाम स्टोरेज आदि)। तुलनात्मक रूप से, Intlayer तर्क के आधार पर सामग्री को ट्री-शेक करने के लिए बंडलर को मजबूर करने के लिए बिल्ड में पर्यावरण चर इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है। इसके कारण, paraglide और intlayer i18next या next-intl की तुलना में 6 से 10 गुना हल्के समाधान साबित होते हैं।
 
-**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+**(svelte-i18n)** (`svelte-i18n@4.0.1`):
 
-यह समाधान Svelte प्रोजेक्ट में सभी i18n आवश्यकताओं को पूरा करता है। लेकिन जैसा कि i18next या अन्य प्रमुख i18n समाधानों के मामले में होता है, यह थोड़ा भारी है (~15.9kb, जो `svelte-intlayer` से लगभग 7 गुना है)।
+यह समाधान Svelte प्रोजेक्ट में सभी i18n आवश्यकताओं को पूरा करता है। लेकिन जैसा कि i18next या अन्य प्रमुख i18n समाधानों के मामले में होता है, यह थोड़ा भारी है (~16.6kb, जो `svelte-intlayer` से लगभग 4.5 गुना है)।
 
 ### 3 - सिफारिशें
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`):
+**(Intlayer)** (`svelte-intlayer@9.5.0`):
 
 मैं निष्पक्षता के लिए व्यक्तिगत रूप से `svelte-intlayer` का न्याय नहीं करूँगा, क्योंकि यह मेरा अपना समाधान है।
 

package/docs/hi/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 में TanStack Start के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
 description: react-i18next, use-intl और Intlayer जैसे TanStack Start अंतर्राष्ट्रीयकरण लाइब्रेरीज़ की तुलना करें। बंडल आकार, लीकेज और रिएक्टिविटी पर विस्तृत परफॉरमेंस रिपोर्ट।
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "बेंचमार्क परिणाम अपडेट किए गए"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub स्टार तुलना जोड़ें"
@@ -62,7 +65,7 @@ history:
 
 ## TL;DR
 
-- **Intlayer**: TanStack Start के लिए सर्वश्रेष्ठ प्रदर्शन और सबसे छोटा बंडल आकार (v8.7.12) प्रदान करता है।
+- **Intlayer**: TanStack Start के लिए सर्वश्रेष्ठ प्रदर्शन और सबसे छोटा बंडल आकार (v9.5.1) प्रदान करता है।
 - **react-i18next** और **use-intl**: बड़े ईकोसिस्टम वाले परिपक्व विकल्प, लेकिन अनुकूलन के लिए काफी भारी और अधिक जटिल।
 - **Paraglide**: अभिनव ट्री-शेकिंग विचार जो व्यवहार में काम नहीं करता है। TanStack Start में जटिल DX और रिएक्टिविटी ओवरहेड।
 - **बचें**: **General Translation (GT)** और **Lingo.dev** गंभीर प्रदर्शन समस्याओं, AI कोटा सीमाओं और वेंडर लॉक-इन (vendor lock-in) के कारण।
@@ -97,16 +100,18 @@ i18n लीकेज के मुद्दों को तेज़ी से
 इस बेंचमार्क के लिए, हमने निम्नलिखित लाइब्रेरीज़ की तुलना की है:
 
 - `Base App` (कोई i18n लाइब्रेरी नहीं)
-- `react-intlayer` (v8.7.12)
-- `react-i18next` (v17.0.2)
-- `use-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
+- `react-intlayer` (v9.5.1)
+- `@intlayer/use-intl` (v9.5.1)
+- [`@intlayer/lingui`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/compat/lingui.md) (v9.5.1)
+- `react-i18next` (v17.0.13)
+- `use-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `react-intl` (v10.1.1)
-- `wuchale` (v0.22.11)
-- `gt-react` (vlatest)
-- `lingo.dev` (v0.133.9)
+- `@tolgee/react` (v7.2.0)
+- `react-intl` (v10.1.26)
+- `wuchale` (v0.26.6)
+- `gt-react` (v10.18.3)
+- `lingo.dev` (v0.138.7)
 
 फ़्रेमवर्क **10 पेजों** और **10 भाषाओं** के मल्टीलिंगुअल ऐप के साथ `TanStack Start` है।
 
@@ -160,15 +165,15 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 सामना किए गए मुद्दे:
 
-**(General Translation)** (`gt-react@latest`):
+**(General Translation)** (`gt-react@10.18.3`):
 
-- लगभग 110kb के ऐप के लिए, `gt-react` 440kb से अधिक अतिरिक्त डेटा जोड़ सकता है (इसी बेंचमार्क में Next.js कार्यान्वयन पर देखा गया परिमाण)।
+- लगभग 111kb के ऐप के लिए, `gt-react` 170kb से अधिक अतिरिक्त डेटा जोड़ सकता है (इसी बेंचमार्क में 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`):
+**(Lingo.dev)** (`lingo.dev@0.138.7`):
 
 - AI कोटा समाप्त हो गया (या सर्वर निर्भरता को अवरुद्ध करना), जिससे भुगतान के बिना बिल्ड / प्रोडक्शन जोखिम भरा हो गया।
 - कंपाइलर अनुवादित सामग्री के लगभग 40% को मिस कर रहा था। मुझे इसे काम कराने के लिए सभी `.map` को फ्लैट कंपोनेंट ब्लॉक्स में दोबारा लिखना पड़ा।
@@ -178,7 +183,7 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 ### 2 - प्रयोगात्मक समाधान
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 `Wuchale` के पीछे का विचार दिलचस्प है लेकिन अभी तक व्यवहार्य समाधान नहीं है। मुझे लाइब्रेरी के साथ रिएक्टिविटी के मुद्दों का सामना करना पड़ा और TanStack Start पर ऐप को काम कराने के लिए प्रोवाइडर के फोर्स री-रेंडर की आवश्यकता थी। दस्तावेज़ीकरण भी काफी अस्पष्ट है, जिससे ऑनबोर्डिंग कठिन हो जाती है।
 
@@ -188,9 +193,9 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 `Paraglide` एक अभिनव, अच्छी तरह से सोचा गया दृष्टिकोण प्रदान करता है। फिर भी, इस बेंचमार्क में उनकी कंपनी द्वारा विज्ञापित ट्री-शेकिंग मेरे Next.js कार्यान्वयन या TanStack Start के लिए काम नहीं कर पाया। वर्कफ़्लो और DX अन्य विकल्पों की तुलना में अधिक जटिल हैं। व्यक्तिगत रूप से मैं हर पुश से पहले JS फ़ाइलों को दोबारा उत्पन्न करने का प्रशंसक नहीं हूँ, जो PR के माध्यम से डेवलपर्स के लिए लगातार मर्ज संघर्ष का जोखिम पैदा करता है।
 
-> paraglide पर नोट: यह समाधान आयात के लिए आपके कोडबेस में कोड इंजेक्ट करता है, जिसके परिणामस्वरूप बेंचमार्क रिपोर्ट में 'lib size' मीट्रिक लगभग 0 है। कोड जनरेशन एक अच्छी चीज़ है, क्योंकि उपयोग किया गया फ़ंक्शन केवल आवश्यक लॉजिक (हर जगह प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकी बनाम स्टोरेज, आदि) शामिल करेगा। इसके विपरीत, Intlayer बिल्ड में एनवायरनमेंट वेरिएबल इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है ताकि बंडलर को लॉजिक के आधार पर सामग्री को ट्री-शेक करने के लिए मजबूर किया जा सके। इसके लिए धन्यवाद, paraglide और intlayer अंत में i18next या next-intl की तुलना में 6 से 10 गुना हल्के समाधान बन जाते हैं।
+> paraglide पर नोट: यह समाधान आयात के लिए आपके कोडबेस में कोड इंजेक्ट करता है, जिसके परिणामस्वरूप बेंचमार्क रिपोर्ट में 'lib size' मीट्रिक लगभग 0 है। कोड जनरेशन एक अच्छी चीज़ है, क्योंकि उपयोग किया गया फ़ंक्शन केवल आवश्यक लॉजिक (हर जगह प्रीफ़िक्स बनाम कोई प्रीफ़िक्स नहीं, कुकी बनाम स्टोरेज, आदि) शामिल करेगा। इसके विपरीत, Intlayer बिल्ड में एनवायरनमेंट वेरिएबल इंजेक्शन के माध्यम से यह फ़िल्टरिंग करता है ताकि बंडलर को लॉजिक के आधार पर सामग्री को ट्री-शेक करने के लिए मजबूर किया जा सके। इसके लिए धन्यवाद, paraglide और intlayer अंत में i18next या next-intl की तुलना में 3 से 10 गुना हल्के समाधान बन जाते हैं।
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee` पहले उल्लेखित कई मुद्दों को संबोधित करता है। मुझे लगा कि इसे शुरू करना समान दृष्टिकोण वाले अन्य उपकरणों की तुलना में कठिन है। यह टाइप सेफ्टी प्रदान नहीं करता है, जिससे कंपाइल समय पर गायब कीज़ को पकड़ना भी बहुत कठिन हो जाता है। गायब-की पहचान जोड़ने के लिए मुझे Tolgee की APIs को अपनी APIs के साथ रैप करना पड़ा।
 
@@ -198,37 +203,37 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 TanStack Start पर मुझे रिएक्टिविटी की समस्याएं भी थीं: लोकेल बदलने पर, मुझे प्रोवाइडर को री-रेंडर करने के लिए मजबूर करना पड़ा और लोकेल-चेंज इवेंट्स को सब्सक्राइब करना पड़ा ताकि दूसरी भाषा में लोडिंग सही ढंग से व्यवहार करे।
 
-**(use-intl)** (`use-intl@4.9.1`):
+**(use-intl)** (`use-intl@4.14.2`):
 
 `use-intl` वर्तमान में React ईकोसिस्टम में सबसे ट्रेंडी "intl" पीस है ( `next-intl` के समान परिवार) और इसे अक्सर AI एजेंटों द्वारा पुश किया जाता है, लेकिन मेरी दृष्टि में परफॉरमेंस-फ़र्स्ट सेटिंग में गलत तरीके से। शुरुआत करना काफी सरल है। व्यवहार में, लीकेज को अनुकूलित और सीमित करने की प्रक्रिया काफी जटिल है। इसी प्रकार, डायनेमिक लोडिंग + नेमस्पेसिंग + TypeScript टाइप्स को जोड़ना विकास को बहुत धीमा कर देता है।
 
 TanStack Start पर आप Next.js-विशिष्ट जाल ( `setRequestLocale`, स्टेटिक रेंडरिंग) से बचते हैं, लेकिन मुख्य मुद्दा वही है: सख्त अनुशासन के बिना, बंडल जल्दी से बहुत अधिक संदेशों को ढोता है और प्रति-रूट नेमस्पेस रखरखाव कष्टदायक हो जाता है।
 
-**(react-i18next)** (`react-i18next@17.0.2`):
+**(react-i18next)** (`react-i18next@17.0.13`):
 
 `react-i18next` शायद सबसे लोकप्रिय विकल्प है क्योंकि यह जावास्क्रिप्ट ऐप i18n आवश्यकताओं को पूरा करने वाले शुरुआती समाधानों में से एक था। इसमें विशिष्ट मुद्दों के लिए कम्युनिटी प्लगइन्स का एक विस्तृत सेट भी है।
 
 फिर भी, यह `t('a.b.c')` पर बने स्टैक्स जैसी ही प्रमुख कमियाँ साझा करता है: अनुकूलन संभव है लेकिन बहुत समय लेने वाला है, और बड़ी परियोजनाओं में खराब प्रथाओं (नेमस्पेस + डायनेमिक लोडिंग + टाइप्स) में गिरने का जोखिम होता है।
 
-पैकेज विशेष रूप से भारी है (~17.3kb, जो `react-intlayer` का लगभग 3.5× है)।
+पैकेज विशेष रूप से भारी है (~18.4kb, जो `react-intlayer` का लगभग 3.5× है)।
 
 मैसेज फॉर्मेट्स भी भिन्न हैं: `use-intl` ICU MessageFormat का उपयोग करता है, जबकि `i18next` अपने स्वयं के फॉर्मेट का उपयोग करता है-जो टूल्स या माइग्रेशन को जटिल बनाता है यदि आप उन्हें मिलाते हैं।
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui` की अक्सर प्रशंसा की जाती है। व्यक्तिगत रूप से मुझे `lingui extract` / `lingui compile` वर्कफ़्लो अन्य दृष्टिकोणों की तुलना में अधिक जटिल लगा, इस TanStack Start बेंचमार्क में किसी स्पष्ट लाभ के बिना। मैंने असंगत सिंटैक्स भी देखे जो AI को भ्रमित करते हैं (उदा. `t()`, `t''`, `i18n.t()`, `<Trans>`) ।
 
-**(react-intl)** (`react-intl@10.1.1`):
+**(react-intl)** (`react-intl@10.1.26`):
 
 `react-intl` Format.js टीम का एक परफॉरमेंट कार्यान्वयन है। DX वर्बोस (verbose) रहता है: `const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })` जटिलता, अतिरिक्त जावास्क्रिप्ट कार्य जोड़ता है और ग्लोबल i18n इंस्टेंस को React ट्री के कई नोड्स से जोड़ता है।
 
-पैकेज भी भारी है (~14.4kb, जो `react-intlayer` का लगभग 3× है)।
+पैकेज भी भारी है (~15.3kb, जो `react-intlayer` का लगभग 3× है)।
 
 ### 4 - सिफारिशें
 
 इस TanStack Start बेंचमार्क का `next-translate` (Next.js प्लगइन + `getStaticProps`) के बराबर कोई सीधा विकल्प नहीं है। उन टीमों के लिए जो वास्तव में परिपक्व ईकोसिस्टम वाली `t()` API चाहती हैं, `react-i18next` और `use-intl` "उचित" विकल्प बने हुए हैं, लेकिन लीकेज से बचने के लिए अनुकूलन में बहुत समय निवेश करने के लिए तैयार रहें।
 
-**(Intlayer)** (`react-intlayer@8.7.12`):
+**(Intlayer)** (`react-intlayer@9.5.1`):
 
 निष्पक्षता के लिए मैं व्यक्तिगत रूप से मेरे स्वयं के समाधान `react-intlayer` पर निर्णय नहीं दूँगा।
 

package/docs/hi/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026 में Vue के लिए सर्वश्रेष्ठ i18n समाधान - बेंचमार्क रिपोर्ट
 description: vue-i18n, fluent-vue, और Intlayer जैसे Vue अंतर्राष्ट्रीयकरण (i18n) पुस्तकालयों की तुलना करें। बंडल आकार, लीकेज और प्रतिक्रियाशीलता पर विस्तृत प्रदर्शन रिपोर्ट।
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "बेंचमार्क परिणाम अपडेट किए गए"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub स्टार तुलना जोड़ें"
@@ -62,7 +65,7 @@ Vue ऐप में अंतर्राष्ट्रीयकरण (Intern
 
 ## TL;DR
 
-- **Intlayer**: मूल स्कोपिंग (scoping) और डायनेमिक लोडिंग के साथ सबसे हल्का समाधान (v8.7.12)।
+- **Intlayer**: मूल स्कोपिंग (scoping) और डायनेमिक लोडिंग के साथ सबसे हल्का समाधान (v9.5.0)।
 - **vue-i18n**: एक समृद्ध पारिस्थितिकी तंत्र के साथ उद्योग मानक, लेकिन बड़े अनुप्रयोगों में महत्वपूर्ण रूप से भारी हो सकता है और कोड-स्प्लिटिंग के लिए अनुकूलित करना कठिन हो सकता है।
 - **fluent-vue**: अभिनव संदेश संगठन लेकिन इसमें टाइप-सेफ्टी की कमी है और यह एक अत्यंत भारी समाधान साबित होता है।
 
@@ -96,7 +99,8 @@ i18n लीकेज समस्याओं को तुरंत पहच
 इस बेंचमार्क के लिए, हमने निम्नलिखित पुस्तकालयों की तुलना की:
 
 - `Base App` (कोई i18n पुस्तकालय नहीं)
-- `vue-intlayer` (v8.7.12)
+- `vue-intlayer` (v9.5.0)
+- [`@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/hi/compat/vue-i18n.md) (v9.5.1)
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
@@ -156,14 +160,14 @@ GitHub सितारे किसी प्रोजेक्ट की लो
 
 - **vue-i18n** निस्संदेह Vue के लिए सबसे अधिक उपयोग किया जाने वाला i18n पुस्तकालय है, इसमें बहुत सारी विशेषताएं और एक विशाल पारिस्थितिकी तंत्र है। लेकिन हुड के तहत समाधान काफी भारी है। भले ही vue-i18n संदेशों के लिए लेज़ी लोडिंग को एकीकृत करता है, लेकिन इसमें स्कोपिंग सुविधा की कमी है। एक क्लासिक Vue SPA ऐप के मामले में कोई समस्या नहीं है, लेकिन @nuxt/i18n का उपयोग करने वाले nuxt ऐप के लिए, यह सभी पृष्ठों के संदेशों को एक ही पृष्ठ में शामिल करने की ओर ले जाता है। 10 से अधिक पृष्ठों वाले बड़े nuxt ऐप के लिए, यह वास्तव में समस्याग्रस्त हो सकता है।
 
-पैकेज बहुत भारी है (~24.3kb, जो `vue-intlayer` से लगभग 9 गुना है)।
+पैकेज बहुत भारी है (~24.3kb, जो `vue-intlayer` से लगभग 6 गुना है)।
 
-**(fluent-vue)** (`fluent-vue@0.5.0`):
+**(fluent-vue)** (`fluent-vue@3.8.2`):
 
-- **fluent-vue** .ftl प्रारूप के माध्यम से एक अभिनव प्रयास प्रदान करता है। संदेश संगठन महान है, शुरू करना आसान है। लेकिन व्यवहार में, टाइप-सेफ्टी की कमी त्रुटि के जोखिम को बढ़ाती है और डिबग करने में जल्दी से समय लग सकता है। इसके अलावा, वह समाधान एक vite प्लगइन का उपयोग करके संदेशों को लोड करता है जो प्रत्येक पृष्ठ में सभी भाषाओं में सभी सामग्री को लोड करने के लिए मजबूर करता है। इसके अतिरिक्त यह एक अत्यंत भारी समाधान है (~92.7kb, जो `vue-intlayer` से लगभग 34 गुना है)।
+- **fluent-vue** .ftl प्रारूप के माध्यम से एक अभिनव प्रयास प्रदान करता है। संदेश संगठन महान है, शुरू करना आसान है। लेकिन व्यवहार में, टाइप-सेफ्टी की कमी त्रुटि के जोखिम को बढ़ाती है और डिबग करने में जल्दी से समय लग सकता है। इसके अलावा, वह समाधान एक vite प्लगइन का उपयोग करके संदेशों को लोड करता है जो प्रत्येक पृष्ठ में सभी भाषाओं में सभी सामग्री को लोड करने के लिए मजबूर करता है। इसके अतिरिक्त यह एक अत्यंत भारी समाधान है (~29.7kb, जो `vue-intlayer` से लगभग 7.5 गुना है)।
 
 ### 3 - सिफारिशें
 
-**(Intlayer)** (`vue-intlayer@8.7.12`):
+**(Intlayer)** (`vue-intlayer@9.5.0`):
 
 मैं निष्पक्षता के लिए व्यक्तिगत रूप से `vue-intlayer` का न्याय नहीं करूँगा, क्योंकि यह मेरा अपना समाधान है।

package/docs/hi/cli/build.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: शब्दकोश बनाएं
 description: कंटेंट घोषणा फ़ाइलों से अपने Intlayer शब्दकोश बनाने का तरीका सीखें।
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - cli
   - build
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "`--ci` फ़्लैग जोड़ा गया"
   - version: 8.1.5
     date: 2026-02-23
     changes: "checkTypes विकल्प जोड़ें"
@@ -92,6 +95,10 @@ bun x intlayer build --watch
 
   > उदाहरण: `npx intlayer build --no-cache`
 
+- **`--ci`**: मोनोरेपो के हर Intlayer प्रोजेक्ट में कमांड चलाता है (प्रोजेक्ट डायरेक्टरी से चलाने पर केवल वर्तमान प्रोजेक्ट में)। प्रति-प्रोजेक्ट क्रेडेंशियल `INTLAYER_PROJECT_CREDENTIALS` के माध्यम से इंजेक्ट किए जा सकते हैं, जो प्रोजेक्ट पाथ को `{ "clientId", "clientSecret" }` से मैप करने वाला JSON ऑब्जेक्ट है।
+
+  > उदाहरण: `npx intlayer build --ci`
+
 - **`--check-types`**: सामग्री घोषणा फ़ाइलों के प्रकारों की जाँच करें।
 
   > उदाहरण: `npx intlayer build --check-types`

package/docs/hi/cli/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: कॉन्फ़िगरेशन प्रबंधित करें
 description: जानें कि अपनी Intlayer कॉन्फ़िगरेशन को CMS में कैसे प्राप्त और पुश करें।
 keywords:
@@ -51,6 +51,7 @@ bun x intlayer configuration get
 - **`--base-dir`**: परियोजना के लिए बेस डायरेक्टरी निर्दिष्ट करें।
 - **`--verbose`**: डिबगिंग के लिए विस्तृत लॉगिंग सक्षम करें। (CLI का उपयोग करते समय डिफ़ॉल्ट रूप से true)
 - **`--no-cache`**: कैश को अक्षम करें।
+- **`--ci`**: मोनोरेपो के हर Intlayer प्रोजेक्ट में कमांड चलाता है (प्रोजेक्ट डायरेक्टरी से चलाने पर केवल वर्तमान प्रोजेक्ट में)। प्रति-प्रोजेक्ट क्रेडेंशियल `INTLAYER_PROJECT_CREDENTIALS` के माध्यम से इंजेक्ट किए जा सकते हैं, जो प्रोजेक्ट पाथ को `{ "clientId", "clientSecret" }` से मैप करने वाला JSON ऑब्जेक्ट है।
 
 ## कॉन्फ़िगरेशन पुश करें
 
@@ -84,5 +85,6 @@ bun x intlayer configuration push
 - **`--base-dir`**: परियोजना के लिए बेस डायरेक्टरी निर्दिष्ट करें।
 - **`--verbose`**: डिबगिंग के लिए विस्तृत लॉगिंग सक्षम करें। (CLI का उपयोग करते समय डिफ़ॉल्ट रूप से true)
 - **`--no-cache`**: कैश को अक्षम करें।
+- **`--ci`**: मोनोरेपो के हर Intlayer प्रोजेक्ट में कमांड चलाता है (प्रोजेक्ट डायरेक्टरी से चलाने पर केवल वर्तमान प्रोजेक्ट में)। प्रति-प्रोजेक्ट क्रेडेंशियल `INTLAYER_PROJECT_CREDENTIALS` के माध्यम से इंजेक्ट किए जा सकते हैं, जो प्रोजेक्ट पाथ को `{ "clientId", "clientSecret" }` से मैप करने वाला JSON ऑब्जेक्ट है।
 
 कॉन्फ़िगरेशन को पुश करने से, आपकी परियोजना पूरी तरह से Intlayer CMS के साथ एकीकृत हो जाती है, जिससे टीमों के बीच निर्बाध शब्दकोश प्रबंधन सक्षम होता है।