@intlayer/docs 9.0.0-canary.4 → 9.0.0-canary.6

package/docs/fr/releases/v7.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 Bienvenue dans Intlayer v7 ! Cette version majeure introduit des améliorations significatives en termes de performance, de sécurité des types et d'expérience développeur. Voici les points forts, avec des notes de migration et des exemples pratiques.
 
+## Table of contents
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## Points forts
 
 - Stratégie de mise en cache pour des builds plus rapides
@@ -261,6 +265,126 @@ Cela se traduit par des temps de téléchargement plus rapides et une meilleure
 
 ---
 
+## Formatage automatique du code : configuration de formatCommand
+
+v7 introduit l'option `formatCommand` dans la configuration de l'éditeur, vous permettant de formater automatiquement les fichiers de contenu lorsqu'ils sont écrits par Intlayer. Cela garantit un style de code et un formatage cohérents dans vos fichiers de déclaration de contenu.
+
+S'il n'est pas défini, Intlayer essaiera de détecter automatiquement la commande de formatage. En essayant de résoudre les commandes suivantes : prettier, biome, eslint.
+
+### Configuration
+
+L'option `formatCommand` accepte un modèle de chaîne où `{{file}}` sera remplacé par le chemin de fichier réel :
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    formatCommand: 'bun x biome format "{{file}}" --write --log-level none',
+  },
+};
+```
+
+### Formatters supportés
+
+Vous pouvez utiliser n'importe quel formateur de code qui accepte les chemins de fichiers comme arguments :
+
+**Utilisation de Biome :**
+
+```typescript
+formatCommand: 'bun x biome format "{{file}}" --write --log-level none';
+```
+
+**Utilisation de Prettier :**
+
+```typescript
+formatCommand: 'npx prettier --write "{{file}}" --log-level silent';
+```
+
+**Utilisation d'ESLint :**
+
+```typescript
+formatCommand: 'npx eslint --fix "{{file}}" --quiet';
+```
+
+**Utilisation du formateur intégré de Bun :**
+
+```typescript
+formatCommand: 'bun format "{{file}}"';
+```
+
+### Avantages
+
+- **Formatage cohérent** : Tous les fichiers de contenu sont automatiquement formatés selon les directives de style de votre projet
+- **Expérience développeur** : Pas besoin de formater manuellement les fichiers après qu'Intlayer les ait écrits
+- **Cohérence d'équipe** : Assure que tous les membres de l'équipe ont le même formatage appliqué aux fichiers de contenu
+- **Intégration CI/CD** : Les fichiers de contenu maintiennent un formatage cohérent dans les workflows automatisés
+
+### Fonctionnement
+
+Lorsqu'Intlayer écrit ou met à jour un fichier de déclaration de contenu (`.content.ts`, `.content.js`, etc.), il exécute automatiquement la commande de format spécifiée sur le fichier. L'espace réservé `{{file}}` est remplacé par le chemin d'accès réel du fichier, et la commande est exécutée dans le répertoire de base du projet.
+
+---
+
+## Configuration du dictionnaire : Meilleure organisation et structure
+
+v7 introduit une nouvelle section de configuration `dictionary` dédiée qui offre une meilleure organisation des paramètres liés au dictionnaire et une gestion de contenu améliorée.
+
+### Nouvelle structure de configuration du dictionnaire
+
+La propriété `fill` a été déplacée de la section `content` vers une nouvelle section `dictionary`, offrant une séparation des responsabilités plus claire :
+
+**Configuration v6 :**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    autoFill: "./{{fileName}}.content.json",
+    contentDir: ["src"],
+  },
+};
+```
+
+**Configuration v7 :**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    contentDir: ["src"],
+  },
+  dictionary: {
+    fill: "./{{fileName}}.content.json",
+  },
+};
+```
+
+### Avantages de la nouvelle structure
+
+- **Organisation plus claire** : Les paramètres spécifiques au dictionnaire sont maintenant regroupés
+- **Meilleure séparation des préoccupations** : La découverte de contenu et les opérations de dictionnaire sont clairement séparées
+- **Maintenabilité améliorée** : Plus facile à comprendre et à modifier les configurations liées au dictionnaire
+- **Extensibilité future** : La section dictionnaire peut accueillir des paramètres supplémentaires spécifiques au dictionnaire
+- **Gestion complète du dictionnaire** : Inclut des propriétés comme `title`, `live`, `priority`, `tags`, `version`, et `description` pour créer et gérer de nouveaux dictionnaires
+
+### Utilisation de la configuration
+
+La configuration du dictionnaire sert deux objectifs principaux :
+
+1. **Valeurs par défaut** : Définir les valeurs par défaut lors de la création de fichiers de déclaration de contenu
+2. **Comportement de secours** : Fournir des valeurs de secours lorsque des champs spécifiques ne sont pas définis, vous permettant de définir le comportement du dictionnaire globalement
+
+La section dictionnaire inclut des propriétés complètes pour la gestion du dictionnaire :
+
+- **`fill`** : Comportement de remplissage automatique pour la génération de contenu
+- **`title`** : Titre par défaut pour les nouveaux dictionnaires
+- **`live`** : Configuration de synchronisation en direct pour les mises à jour en temps réel
+- **`priority`** : Paramètres de priorité pour la résolution du dictionnaire
+- **`tags`** : Tags par défaut pour l'organisation du contenu
+- **`version`** : Gestion des versions pour les mises à jour du dictionnaire
+- **`description`** : Description par défaut pour le nouveau contenu
+
+Pour plus d'informations sur les fichiers de déclaration de contenu et la façon dont les valeurs de configuration sont appliquées, consultez la [Documentation du fichier de contenu](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/dictionary/content_file.md).
+
+---
+
 ## Commande fill : comportement mis à jour pour une meilleure gestion du contenu
 
 La version 7 introduit un comportement amélioré pour la commande `fill`, offrant une gestion du contenu plus prévisible et flexible :
@@ -408,6 +532,10 @@ Le système effectue automatiquement :
 - **`middleware.prefixDefault`** : Remplacé par `routing.mode`
 - **`middleware.noPrefix`** : Remplacé par `routing.mode`
 
+### Nouvelles configurations
+
+- **`editor.formatCommand`**: Nouvelle option pour le formatage automatique du code des fichiers de contenu
+
 ### Correspondance de migration
 
 #### Correspondance de configuration

package/docs/fr/releases/v9.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-06-14
-updatedAt: 2026-06-14
+updatedAt: 2026-06-23
 title: Nouvel Intlayer v9 - Quoi de neuf ?
 description: Découvrez les nouveautés d'Intlayer v9. Présentation des packages de compatibilité prêts à l'emploi pour les bibliothèques i18n populaires et prise en charge des Collections, Variants et Dynamic Records.
 keywords:
@@ -204,6 +204,42 @@ Au moment de la compilation, `@intlayer/swc` et `@intlayer/babel` analysent vos
 
 ---
 
+## Plugin Vite : Compilateur Bundled & Proxy
+
+Le plugin Vite `intlayer()` regroupe maintenant le **compilateur** et le **proxy de routage de locale** directement, donc la plupart des projets n'ont besoin que d'un seul plugin dans `vite.config.ts` :
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [intlayer()],
+});
+```
+
+- **Compilateur** : S'active automatiquement lorsque `compiler.enabled` est défini et qu'un chemin `compiler.output` est configuré. Vous n'avez plus besoin d'enregistrer `intlayerCompiler()` séparément.
+- **Proxy** : S'active automatiquement en fonction de la nouvelle option `routing.enableProxy` (`true` par défaut). Il connecte le middleware de détection de locale / redirection / réécriture en développement, en aperçu et en SSR de production. Vous n'avez plus besoin d'enregistrer `intlayerProxy()` séparément.
+
+### Option `routing.enableProxy`
+
+Une nouvelle option `routing.enableProxy` contrôle si le proxy de routage des locales est activé. Par défaut, elle est définie à `true`. Désactivez-la si vous souhaitez gérer le routage des locales vous-même :
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  routing: {
+    enableProxy: false, // Par défaut: true
+  },
+};
+
+export default config;
+```
+
+Les plugins autonomes `intlayerCompiler()` et `intlayerProxy()` restent exportés pour les configurations avancées. Les enregistrer aux côtés de `intlayer()` est sûr — chaque plugin se déduplique et s'exécute une seule fois.
+
+---
+
 ## Notes de migration depuis la v8
 
 Si vous effectuez une mise à niveau depuis la v8, notez que la v9 n'inclut pas de changements majeurs (breaking changes). Voici cependant les changements clés :

package/docs/fr/roadmap.md

@@ -29,6 +29,12 @@ Intlayer est une solution de gestion de contenu et d'internationalisation conçu
 
 ---
 
+## Table des matières
+
+<TOC/>
+
+---
+
 ## Fonctionnalités actuelles
 
 ### 1. Déclaration de contenu

package/docs/hi/CI_CD.md

@@ -26,6 +26,10 @@ author: aymericzip
 
 Intlayer आपके सामग्री घोषणा फ़ाइलों के लिए अनुवादों का स्वचालित उत्पादन करने की अनुमति देता है। आपके कार्यप्रवाह के आधार पर इसे प्राप्त करने के कई तरीके हैं।
 
+## विषय सूची
+
+<TOC/>
+
 ## CMS का उपयोग करना
 
 Intlayer के साथ, आप एक ऐसा कार्यप्रवाह अपना सकते हैं जहाँ केवल एक ही स्थानीय भाषा स्थानीय रूप से घोषित की जाती है, जबकि सभी अनुवाद CMS के माध्यम से दूरस्थ रूप से प्रबंधित किए जाते हैं। यह सामग्री और अनुवादों को कोडबेस से पूरी तरह से अलग करने की अनुमति देता है, जिससे सामग्री संपादकों के लिए अधिक लचीलापन मिलता है और हॉट कंटेंट रीलोडिंग सक्षम होती है (परिवर्तन लागू करने के लिए एप्लिकेशन को पुनः निर्माण करने की आवश्यकता नहीं होती)।

package/docs/hi/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# कंटेंट डिक्लेरेशन फ़ाइल अनुवाद भरें
+
+**अपने CI में कंटेंट डिक्लेरेशन फ़ाइलों को ऑटोफिल करना** आपके विकास वर्कफ़्लो को तेज़ करने का एक तरीका है।
+
+## व्यवहार को समझना
+
+`fill` कमांड में दो मोड शामिल हैं:
+
+- **Complete**: प्रत्येक locale के लिए सभी missing content को स्वचालित रूप से भरें और वर्तमान फ़ाइल को संपादित करें, या यदि निर्दिष्ट हो तो दूसरी फ़ाइल को संपादित करें। यानी, complete मोड पहले से से अनुवादित मौजूदा content को छोड़ देगा।
+- **Review**: प्रत्येक locale के लिए **सभी** content को स्वचालित रूप से भरें और एक विशिष्ट फ़ाइल के लिए generate करें, या यदि निर्दिष्ट हो तो दूसरी फ़ाइल के लिए generate करें।
+
+`fill` कमांड आपकी सभी locale content declaration files को process करेगा। यानी, यह CMS से आपकी remote content को process नहीं करेगा। CMS के पास अपना स्वयं का translations management है।
+यदि आप `@intlayer/sync-json-plugin` जैसे plugins का उपयोग करते हैं, तो Intlayer JSON files को locale content declaration files में transform करेगा। यानी, वे `fill` कमांड द्वारा process किए जाएंगे।
+
+नई generated files में एक `filled` instruction को dictionary metadata के रूप में शामिल है। यह instruction Intlayer को यह जानने के लिए उपयोग किया जाएगा कि फ़ाइल को autofilled किया गया है या नहीं, और यदि मौजूद है तो इस फ़ाइल को फिर से translate किए जाने से छोड़ दें।
+
+Intlayer autofill के लिए निम्नलिखित instruction पर भी विचार करेगा:
+
+- आपकी `.content.{ts|js|json}` → `fill` instruction से
+- आपकी configuration file `.intlayer.config.ts` → `dictionary.fill` instruction से
+- अन्यथा `true` पर set किया जाएगा
+
+Per-locale content declaration files के लिए, `true` instruction को `./{{fileName}}.fill.content.json` से replace किया जाएगा। यह इसलिए है क्योंकि एक per-locale content declaration file अतिरिक्त localized content प्राप्त नहीं कर सकता है। इसलिए यह मौजूदा फ़ाइल को overwrite न करने के लिए एक नई फ़ाइल generate करेगा।
+
+## डिफ़ॉल्ट व्यवहार
+
+डिफ़ॉल्ट रूप से, `fill` को globally `true` पर सेट किया गया है, जिसका अर्थ है कि Intlayer automatically सभी content files को fill करेगा और फ़ाइल को स्वयं edit करेगा। इस व्यवहार को कई तरीकों से customize किया जा सकता है:
+
+### वैश्विक कॉन्फ़िगरेशन विकल्प
+
+1. **`fill: true` (डिफ़ॉल्ट)** - सभी locales को स्वचालित रूप से भरें और वर्तमान फ़ाइल को संपादित करें
+2. **`fill: false`** - इस सामग्री फ़ाइल के लिए स्वचालित भरण अक्षम करें
+3. **`fill: "./relative/path/to/file"`** - वर्तमान फ़ाइल को संपादित किए बिना निर्दिष्ट फ़ाइल को बनाएं/अपडेट करें, वर्तमान फ़ाइल के स्थान के आधार पर हल किए गए सापेक्ष पथ की ओर इशारा करके
+4. **`fill: "/absolute/path/to/file"`** - वर्तमान फ़ाइल को संपादित किए बिना निर्दिष्ट फ़ाइल को बनाएं/अपडेट करें, कॉन्फ़िगरेशन फ़ाइल `.intlayer.config.ts` में बेस डायरेक्टरी (फ़ील्ड `baseDir`) के आधार पर हल किए गए सापेक्ष पथ की ओर इशारा करके
+5. **`fill: "C:\\absolute\path\to\file"`** - वर्तमान फ़ाइल को संपादित किए बिना निर्दिष्ट फ़ाइल को बनाएं/अपडेट करें, आपके ऑपरेटिंग सिस्टम के आधार पर हल किए गए निरपेक्ष पथ की ओर इशारा करके
+6. **`fill: { [key in Locales]?: string }`** - प्रत्येक locale के लिए निर्दिष्ट फ़ाइल को बनाएं/अपडेट करें
+
+### v7 व्यवहार परिवर्तन
+
+v7 में, `fill` कमांड का व्यवहार अपडेट किया गया है:
+
+- **`fill: true`** - वर्तमान फ़ाइल को सभी locales के लिए भरी गई सामग्री के साथ फिर से लिखता है
+- **`fill: "path/to/file"`** - निर्दिष्ट फ़ाइल को भरता है बिना वर्तमान फ़ाइल को संशोधित किए
+- **`fill: false`** - auto-fill को पूरी तरह अक्षम करता है
+
+जब किसी दूसरी फ़ाइल में लिखने के लिए path विकल्प का उपयोग करते हैं, तो fill तंत्र सामग्री घोषणा फ़ाइलों के बीच एक _master-slave_ संबंध के माध्यम से काम करता है। मुख्य (master) फ़ाइल सत्य का स्रोत है, और जब इसे अपडेट किया जाता है, तो Intlayer स्वचालित रूप से उन परिवर्तनों को path द्वारा निर्दिष्ट व्युत्पन्न (भरी गई) घोषणा फ़ाइलों पर लागू करता है।
+
 # ऑटोफिल सामग्री घोषणा फ़ाइल अनुवाद
 
 **ऑटोफिल सामग्री घोषणा फ़ाइलें** आपके विकास कार्यप्रवाह को तेज़ करने का एक तरीका हैं।
@@ -88,6 +135,40 @@ Intlayer स्वचालित रूप से व्युत्पन्
 
 इसके बाद, दोनों घोषणा फ़ाइलों को एकल शब्दकोश में मर्ज किया जाएगा, जिसे मानक `useIntlayer("example")` हुक (react) / कॉम्पोज़ेबल (vue) का उपयोग करके एक्सेस किया जा सकता है।
 
+## Global Configuration
+
+आप `intlayer.config.ts` फ़ाइल में global auto fill configuration को कॉन्फ़िगर कर सकते हैं।
+
+```ts fileName="intlayer.config.ts"
+import { type IntlayerConfig, Locales } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+  },
+  dictionary: {
+    // सभी dictionaries के लिए लापता translations को auto-generate करें
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // सभी dictionaries के लिए लापता translations को auto-generate करें जैसे "./{{fileName}}.content.json" का उपयोग करना
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+आप content files में `fill` field का उपयोग करके प्रति dictionary को fine-tune कर सकते हैं। Intlayer पहले per dictionary configuration पर विचार करेगा और फिर global configuration पर fallback करेगा।
+
 ## ऑटोफिल की गई फ़ाइल प्रारूप
 
 सिफारिश की गई स्वरूप ऑटोफिल की गई घोषणा फ़ाइलों के लिए **JSON** है, जो स्वरूपण प्रतिबंधों से बचने में मदद करता है। हालांकि, Intlayer `.ts`, `.js`, `.mjs`, `.cjs`, और अन्य स्वरूपों का भी समर्थन करता है।

package/docs/hi/benchmark/solid.md

@@ -118,6 +118,28 @@ i18n लीकेज समस्याओं को तुरंत पहच
 - **Scoped static**: जटिल अतिरिक्त नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित रखता है (तार्किक पृथक्करण)।
 - **Scoped dynamic**: _कोड स्प्लिटिंग_ और प्रदर्शन के लिए सर्वोत्तम दृष्टिकोण। केवल वर्तमान दृश्य और सक्रिय लोकेल के लिए आवश्यक सामग्री लोड करके मेमोरी को कम करता है।
 
+### मैंने क्या मापा:
+
+मैंने हर स्टैक के लिए एक वास्तविक ब्राउज़र में एक ही बहुभाषी ऐप चलाया, फिर लिखा कि वास्तव में क्या तार पर दिखाई दिया और कितने समय लगे। आकार सामान्य वेब संपीड़न के **बाद** रिपोर्ट किए जाते हैं, क्योंकि यह कच्चे स्रोत गणना की तुलना में लोग जो डाउनलोड करते हैं उसके करीब है।
+
+- **Internationalization लाइब्रेरी आकार**: बंडलिंग, ट्री-शेकिंग और मिनिफिकेशन के बाद, i18n लाइब्रेरी का आकार providers + hooks/primitives कोड एक खाली कंपोनेंट में है। इसमें ट्रांसलेशन फाइलों को लोड करना शामिल नहीं है। यह जवाब देता है कि लाइब्रेरी आपकी सामग्री तस्वीर में आने से पहले कितनी महंगी है।
+
+- **प्रति पृष्ठ JavaScript**: प्रत्येक बेंचमार्क रूट के लिए, ब्राउज़र उस विज़िट के लिए कितनी स्क्रिप्ट खींचता है, सूट में पृष्ठों में औसत (और locales में जहां रिपोर्ट उन्हें रोल करती है)। भारी पृष्ठ धीमे पृष्ठ हैं।
+
+- **अन्य locales से रिसाव**: यह एक ही पृष्ठ की सामग्री है लेकिन एक अन्य भाषा में जो ऑडिट किए गए पृष्ठ में गलती से लोड हो सकती है। यह सामग्री अनावश्यक है और इससे बचा जाना चाहिए। (उदाहरण के लिए `/fr/about` पृष्ठ की सामग्री `/en/about` पृष्ठ बंडल में)
+
+- **अन्य routes से रिसाव**: **अन्य स्क्रीन** के लिए भी यही विचार: कि क्या उनकी कॉपी तब चल रही है जब आपने केवल एक पृष्ठ खोला है। (उदाहरण के लिए `/en/about` पृष्ठ की सामग्री `/en/contact` पृष्ठ बंडल में)। उच्च स्कोर कमजोर splitting या over-broad बंडल का संकेत देता है।
+
+- **औसत कंपोनेंट बंडल आकार**: सामान्य UI टुकड़ों को **एक समय में एक** मापा जाता है एक विशाल ऐप नंबर के अंदर छिपने के बजाय। यह दिखाता है कि क्या internationalization चुपचाप रोज़मर्रा के कंपोनेंट को बढ़ाता है। उदाहरण के लिए, यदि आपका कंपोनेंट पुनः रेंडर करता है, तो यह मेमोरी से सभी डेटा लोड करेगा। किसी कंपोनेंट से एक विशाल JSON को जोड़ना अप्रयुक्त डेटा के एक बड़े स्टोर को जोड़ने जैसा है जो आपके कंपोनेंट के प्रदर्शन को धीमा कर देगा।
+
+- **भाषा स्विच प्रतिक्रिया**: मैं ऐप के अपने नियंत्रण का उपयोग करके भाषा को फ्लिप करता हूं और समय करता हूं कि पृष्ठ स्पष्ट रूप से स्विच होने तक कितना समय लगता है, एक आगंतुक को क्या ध्यान देगा, lab micro-step नहीं।
+
+- **भाषा परिवर्तन के बाद रेंडरिंग कार्य**: एक संकीर्ण अनुवर्ती: एक बार स्विच उड़ान में आने के बाद नई भाषा के लिए इंटरफेस को पुनः पेंट करने में कितना प्रयास लगा। उपयोगी जब "महसूस" किया गया समय और framework cost भिन्न हों।
+
+- **प्रारंभिक पृष्ठ लोड समय**: navigation से ब्राउज़र तक उन परिदृश्यों के लिए पृष्ठ को पूरी तरह से लोड माना जाता है जिनका मैंने परीक्षण किया। cold starts की तुलना के लिए अच्छा।
+
+- **Hydration समय**: जब ऐप इसे उजागर करता है, तो क्लाइंट कितने समय तक server HTML को उन चीजों में बदलने में खर्च करता है जिन पर आप वास्तव में क्लिक कर सकते हैं। तालिकाओं में एक dash का मतलब है कि इस बेंचमार्क में कार्यान्वयन ने एक विश्वसनीय hydration आंकड़ा प्रदान नहीं किया।
+
 ## GitHub सितारे
 
 GitHub सितारे किसी प्रोजेक्ट की लोकप्रियता, सामुदायिक विश्वास और दीर्घकालिक प्रासंगिकता का एक मजबूत संकेतक हैं। हालांकि यह तकनीकी गुणवत्ता का प्रत्यक्ष माप नहीं है, वे दर्शाते हैं कि कितने डेवलपर्स प्रोजेक्ट को उपयोगी पाते हैं, इसकी प्रगति का पालन करते हैं, और इसे अपनाने की संभावना रखते हैं। किसी प्रोजेक्ट के मूल्य का अनुमान लगाने के लिए, सितारे विकल्पों के बीच कर्षण की तुलना करने में मदद करते हैं और पारिस्थितिकी तंत्र के विकास में अंतर्दृष्टि प्रदान करते हैं।

package/docs/hi/benchmark/svelte.md

@@ -116,6 +116,28 @@ i18n लीकेज समस्याओं को तुरंत पहच
 - **Scoped static**: जटिल अतिरिक्त नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित रखता है (तार्किक पृथक्करण)।
 - **Scoped dynamic**: _कोड स्प्लिटिंग_ और प्रदर्शन के लिए सर्वोत्तम दृष्टिकोण। केवल वर्तमान दृश्य और सक्रिय लोकेल के लिए आवश्यक सामग्री लोड करके मेमोरी को कम करता है।
 
+### मैंने क्या मापा:
+
+मैंने प्रत्येक stack के लिए एक ही बहुभाषी ऐप्लिकेशन को एक वास्तविक ब्राउज़र में चलाया, फिर नोट किया कि वास्तव में तार पर क्या दिखाई दिया और चीजें कितनी देर लीं। आकार **सामान्य वेब संपीड़न के बाद** रिपोर्ट किए जाते हैं, क्योंकि यह कच्चे स्रोत गणना की तुलना में लोगों द्वारा डाउनलोड किए जाने वाले से करीब है।
+
+- **Internationalization library size**: bundling, tree-shaking और minification के बाद, i18n library का आकार providers + stores code का आकार एक खाली component में है। इसमें translation files को लोड करना शामिल नहीं है। यह इस बात का उत्तर देता है कि आपकी content से पहले library कितनी महंगी है।
+
+- **JavaScript per page**: प्रत्येक benchmark route के लिए, browser उस visit के लिए कितनी script खींचता है, suite में pages के औसत पर (और locales के पार जहां report उन्हें roll करता है)। Heavy pages slow pages हैं।
+
+- **Leakage from other locales**: यह एक ही page की content है लेकिन दूसरी language में जो audited page में गलती से load हो जाती है। यह content अनावश्यक है और इससे बचा जाना चाहिए। (उदाहरण के लिए `/fr/about` page content `/en/about` page bundle में)
+
+- **Leakage from other routes**: **अन्य screens** के लिए भी यही विचार: क्या उनकी copy तब भी साथ आती है जब आपने केवल एक page खोला हो। (उदाहरण के लिए `/en/about` page content `/en/contact` page bundle में)। एक high score weak splitting या over-broad bundles का संकेत देता है।
+
+- **Average component bundle size**: Common UI pieces को **एक बार में** measure किया जाता है बजाय एक giant app number के अंदर छिपने के। यह दिखाता है कि internationalization आम components को quietly inflate करता है या नहीं। उदाहरण के लिए, यदि आपका component rerender करता है, तो यह memory से सभी उस data को load करेगा। किसी भी component के साथ एक giant JSON को attach करना एक बड़े unused data store को जोड़ने जैसा है जो आपके components के performance को slow down करेगा।
+
+- **Language switch responsiveness**: मैं ऐप के अपने control का उपयोग करके language को flip करता हूं और time करता हूं कि page clearly switch होने में कितना समय लगता है, जो एक visitor को notice होगा, न कि एक lab micro-step।
+
+- **Rendering work after a language change**: एक narrower follow-up: interface को नई language के लिए repaint करने में कितनी effort लगी एक बार switch in flight हो। उपयोगी जब "felt" समय और framework cost में divergence हो।
+
+- **Initial page load time**: navigation से browser तक जब page को उन scenarios के लिए fully loaded माना जाए जिन्हें मैंने test किया। Cold starts की तुलना के लिए अच्छा।
+
+- **Hydration time**: जब app इसे expose करता है, तो client कितना समय server HTML को कुछ ऐसे में बदलने में खर्च करता है जिसे आप actually click कर सकते हैं। Tables में एक dash का मतलब है कि implementation ने इस benchmark में एक reliable hydration figure provide नहीं किया।
+
 ## GitHub सितारे
 
 GitHub सितारे किसी प्रोजेक्ट की लोकप्रियता, सामुदायिक विश्वास और दीर्घकालिक प्रासंगिकता का एक मजबूत संकेतक हैं। हालांकि यह तकनीकी गुणवत्ता का प्रत्यक्ष माप नहीं है, वे दर्शाते हैं कि कितने डेवलपर्स प्रोजेक्ट को उपयोगी पाते हैं, इसकी प्रगति का पालन करते हैं, और इसे अपनाने की संभावना रखते हैं। किसी प्रोजेक्ट के मूल्य का अनुमान लगाने के लिए, सितारे विकल्पों के बीच कर्षण की तुलना करने में मदद करते हैं और पारिस्थितिकी तंत्र के विकास में अंतर्दृष्टि प्रदान करते हैं।

package/docs/hi/benchmark/tanstack.md

@@ -124,6 +124,28 @@ i18n लीकेज के मुद्दों को तेज़ी से
 - **Scoped static**: अतिरिक्त जटिल नेटवर्क अनुरोधों के बिना कोड को व्यवस्थित (लॉजिकल सेपरेशन) रखता है।
 - **Scoped dynamic**: कोड स्प्लिटिंग और परफॉरमेंस के लिए सबसे अच्छा दृष्टिकोण। वर्तमान व्यू और सक्रिय लोकेल की आवश्यकता वाली चीज़ों को लोड करके मेमोरी को कम करता है।
 
+### मैंने क्या मापा:
+
+मैंने हर स्टैक के लिए एक वास्तविक ब्राउज़र में एक ही बहुभाषी ऐप चलाया, फिर लिखा कि वास्तव में तार पर क्या दिखाई दिया और चीजों में कितना समय लगा। आकार **सामान्य वेब कंप्रेशन के बाद** रिपोर्ट किए जाते हैं, क्योंकि यह कच्चे स्रोत गणना की तुलना में लोग जो डाउनलोड करते हैं उसके करीब है।
+
+- **Internationalization लाइब्रेरी का आकार**: bundling, tree-shaking और minification के बाद, i18n लाइब्रेरी का आकार providers (जैसे `NextIntlClientProvider`) + hooks (जैसे `useTranslations`) कोड का आकार एक खाली component में है। इसमें translation फाइलों का लोडिंग शामिल नहीं है। यह इस बात का उत्तर देता है कि आपकी content के picture में आने से पहले लाइब्रेरी कितनी महंगी है।
+
+- **प्रति पृष्ठ JavaScript**: प्रत्येक benchmark route के लिए, ब्राउज़र उस visit के लिए कितनी script खींचता है, suite के pages में averaged (और locales में जहां report उन्हें roll करता है)। भारी pages धीमे pages हैं।
+
+- **अन्य locales से Leakage**: यह एक ही page की content है लेकिन एक अलग language में जो audited page में गलती से लोड हो सकती है। यह content अनावश्यक है और इसे avoid किया जाना चाहिए। (उदाहरण के लिए `/fr/about` page content `/en/about` page bundle में)
+
+- **अन्य routes से Leakage**: **अन्य screens** के लिए भी यही विचार है: क्या जब आप केवल एक page खोलते हैं तो उनकी copy साथ चल रही है। (उदाहरण के लिए `/en/about` page content `/en/contact` page bundle में)। एक high score कमजोर splitting या over-broad bundles का संकेत देता है।
+
+- **औसत component bundle का आकार**: Common UI pieces को **एक बार में एक** मापा जाता है, एक विशाल app संख्या के अंदर छिपने के बजाय। यह दिखाता है कि क्या internationalization quietly रोज़मर्रा के components को inflate करती है। उदाहरण के लिए, यदि आपका component rerenders, तो यह memory से सभी data को load करेगा। किसी component को एक विशाल JSON को attach करना अप्रयुक्त data के एक बड़े store को जोड़ने जैसा है जो आपके components के performance को धीमा कर देगा।
+
+- **Language switch responsiveness**: मैं ऐप के अपने control का उपयोग करके language को flip करता हूं और time करता हूं कि page clearly switch होने में कितना समय लगता है, जो एक visitor को notice होगा, एक lab micro-step नहीं।
+
+- **Language change के बाद Rendering work**: एक narrower follow-up: interface को repaint करने में कितना effort लगा नई language के लिए एक बार switch flight में है। उपयोगी जब "felt" time और framework cost diverge हों।
+
+- **Initial page load time**: Navigation से browser तक यह मानते हुए कि मैंने जिन scenarios को test किया उनके लिए page पूरी तरह से loaded है। Cold starts की तुलना करने के लिए अच्छा है।
+
+- **Hydration time**: जब ऐप इसे expose करता है, तो client कितना समय server HTML को ऐसी चीज़ में बदलने में खर्च करता है जिस पर आप actually क्लिक कर सकते हैं। Tables में एक dash का मतलब है कि implementation ने इस benchmark में एक reliable hydration figure प्रदान नहीं किया।
+
 ## GitHub सितारे
 
 GitHub सितारे किसी प्रोजेक्ट की लोकप्रियता, सामुदायिक विश्वास और दीर्घकालिक प्रासंगिकता का एक मजबूत संकेतक हैं। हालांकि यह तकनीकी गुणवत्ता का प्रत्यक्ष माप नहीं है, वे दर्शाते हैं कि कितने डेवलपर्स प्रोजेक्ट को उपयोगी पाते हैं, इसकी प्रगति का पालन करते हैं, और इसे अपनाने की संभावना रखते हैं। किसी प्रोजेक्ट के मूल्य का अनुमान लगाने के लिए, सितारे विकल्पों के बीच कर्षण की तुलना करने में मदद करते हैं और पारिस्थितिकी तंत्र के विकास में अंतर्दृष्टि प्रदान करते हैं।

package/docs/hi/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## Scaffolded GitHub Actions
+
+जब आप `intlayer init` चलाते हैं, तो Intlayer आपके package manager (npm, yarn, pnpm, या bun) को detect करता है और `.github/workflows/` के अंतर्गत दो GitHub Actions workflows को scaffold करता है, जिनमें उस package manager से मेल खाने वाली commands होती हैं:
+
+- **`intlayer-fill.yml`** — हर pull request पर, dictionaries को build करता है और `intlayer fill --git-diff --mode complete` चलाता है ताकि बदली हुई dictionaries के लिए missing translations generate हो सकें, फिर परिणाम को PR branch में commit करता है।
+- **`intlayer-test.yml`** — हर pull request पर, dictionaries को build करता है और `intlayer test` चलाता है, जब required locales में translations missing हों तो check को fail करता है।
+
+Existing workflow files को कभी overwrite नहीं किया जाता है। Scaffolding को पूरी तरह skip करने के लिए, यह चलाएँ:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Fill workflow को AI access प्रदान करना
+
+Scaffolded `intlayer-fill.yml` को AI access की आवश्यकता है। दो विकल्प उपलब्ध हैं (workflow के `env` block में कॉन्फ़िगर किए गए):
+
+1. **आपकी अपनी AI provider key** — अपनी repository settings में एक `AI_API_KEY` secret जोड़ें (Settings → Secrets and variables → Actions)। Workflow इसे `--provider`, `--model`, और `--api-key` के माध्यम से forward करता है।
+2. **Intlayer CMS access keys** — `INTLAYER_CLIENT_ID` और `INTLAYER_CLIENT_SECRET` secrets जोड़ें और उन्हें अपने `intlayer.config` `editor` section में wire करें। CMS access keys Intlayer backend के माध्यम से AI access प्रदान करती हैं।
+
+`intlayer-test.yml` workflow को किसी भी AI access की आवश्यकता नहीं है।
+
 ## Error Handling
 
 - यदि `INTLAYER_PROJECT_CREDENTIALS` सेट नहीं है, तो कमांड error के साथ exit होगा।

package/docs/hi/cli/fill.md

@@ -47,6 +47,14 @@ bun x intlayer fill
 - मौजूदा अनुवादों को अधिलेखित न करके उन्हें संरक्षित करता है।
 - गति बढ़ाने के लिए कतार प्रणाली का उपयोग करके फ़ाइलों, चंक्स और लोकेल्स को समानांतर में संसाधित करता है।
 
+## मुख्य बिंदु:
+
+- बड़ी JSON फ़ाइलों को chunks में विभाजित करता है ताकि AI मॉडल के context window की सीमा के भीतर रहा जा सके।
+- यदि आउटपुट format गलत है तो translation को retry करता है।
+- बेहतर translation accuracy के लिए application और file-specific context को शामिल करता है।
+- मौजूदा translations को preserve करता है और उन्हें overwrite नहीं करता है।
+- Speed बढ़ाने के लिए queue system का उपयोग करके files, chunks, और locales को parallel में process करता है।
+
 ## उपनाम:
 
 - `npx intlayer dictionaries fill`

package/docs/hi/cli/login.md

@@ -88,42 +88,6 @@ bun x intlayer login --cms-url https://intlayer.org
 
 ## यह कैसे काम करता है
 
-1. **लोकल सर्वर शुरू करना**: यह कमांड CMS से क्रेडेंशियल प्राप्त करने के लिए एक रैंडम पोर्ट पर लोकल HTTP सर्वर शुरू करता है
-
-प्रमाणीकरण के लिए कनेक्ट करने हेतु Intlayer CMS का URL निर्दिष्ट करें।
-
-- **प्रकार**: `string`
-- **डिफ़ॉल्ट**: `intlayer.config.*` में कॉन्फ़िगर किया गया मान या `https://intlayer.org`
-- **उदाहरण**:
-
-```bash packageManager="npm"
-npx intlayer login --cms-url https://intlayer.org
-```
-
-```bash packageManager="yarn"
-yarn intlayer login --cms-url https://intlayer.org
-```
-
-```bash packageManager="pnpm"
-pnpm intlayer login --cms-url https://intlayer.org
-```
-
-```bash packageManager="bun"
-bun x intlayer login --cms-url https://intlayer.org
-```
-
-### कॉन्फ़िगरेशन विकल्प
-
-आप सामान्य कॉन्फ़िगरेशन विकल्प भी उपयोग कर सकते हैं:
-
-- `--env-file <path>`: एनवायरनमेंट फ़ाइल का पथ
-- `-e, --env <env>`: निष्पादन वातावरण
-- `--base-dir <dir>`: प्रोजेक्ट की मूल निर्देशिका
-- `--verbose`: विस्तृत आउटपुट सक्षम करें (डिफ़ॉल्ट: true)
-- `--prefix <prefix>`: लॉग्स के लिए प्रीफ़िक्स
-
-## यह कैसे काम करता है
-
 1. **स्थानीय सर्वर शुरू**: कमांड CMS से क्रेडेंशियल प्राप्त करने के लिए एक रैंडम पोर्ट पर स्थानीय HTTP सर्वर शुरू करता है
 2. **ब्राउज़र खोलना**: यह कमांड स्वचालित रूप से आपका डिफ़ॉल्ट ब्राउज़र CMS लॉगिन URL में खोलता है
 3. **प्रमाणीकरण**: ब्राउज़र में अपने Intlayer खाते का उपयोग करके प्रमाणीकरण पूरा करें

package/docs/hi/compat/i18n-js.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "i18n-js से Intlayer में माइग्रेट करें"
+description: "compat adapter का उपयोग करके अपने application को i18n-js से Intlayer में माइग्रेट करने का तरीका जानें।"
+keywords:
+  - i18n-js
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18n-js
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# i18n-js से Intlayer में माइग्रेट करें
+
+`i18n-js` लाइब्रेरी से Intlayer में ट्रांज़िशन एक अत्यधिक अनुकूलित माइग्रेशन है जो बड़े अनुवाद कॉन्फ़िगरेशन को Intlayer की संरचित फ़ाइल resolution प्रणाली में स्थानांतरित करने के लिए डिज़ाइन किया गया है।
+
+## क्या करना है
+
+अपने repository में निम्नलिखित setup command को execute करें:
+
+```bash
+npx intlayer init
+```
+
+`intlayer.config.ts` तैयार होने के बाद, आप अपने bundler configuration में Intlayer's alias को जोड़ सकते हैं ताकि `i18n-js` के किसी भी imports को compat package `@intlayer/i18n-js` को target करें।
+
+## यह पर्दे के पीछे क्या करता है
+
+`i18n-js` `i18n.t('scope.key', {name})` जैसी expressions के माध्यम से namespaces तक पहुंचता है साथ ही locale fallbacks और विशिष्ट plural mappings के साथ।
+
+पर्दे के पीछे:
+
+- **Interpolation:** compat adapter आसानी से `%{name}` mappings को आपके लक्षित runtime dictionary value में parse करता है।
+- **Pluralization:** `one/other` subkeys को replace करता है और उन्हें Intlayer के शक्तिशाली अंतर्निहित plural mechanisms (`Intl.PluralRules`) के विरुद्ध map करता है, जो manual mappings को abstract करता है।
+- **Locales:** bootstrap पर monolithic language payloads को load करने के बजाय, dictionaries को वर्तमान context setup के आधार पर native Intlayer configuration के माध्यम से optimally serve किया जाता है।