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

package/docs/es/roadmap.md

@@ -29,6 +29,12 @@ Intlayer es una solución de gestión de contenido e internacionalización dise
 
 ---
 
+## Tabla de contenidos
+
+<TOC/>
+
+---
+
 ## Funcionalidades Actuales
 
 ### 1. Declaración de Contenido

package/docs/fr/CI_CD.md

@@ -26,6 +26,10 @@ author: aymericzip
 
 Intlayer permet la génération automatique des traductions pour vos fichiers de déclaration de contenu. Plusieurs méthodes existent selon votre flux de travail.
 
+## Table des matières
+
+<TOC/>
+
 ## Utilisation du CMS
 
 Avec Intlayer, vous pouvez adopter un flux de travail où une seule locale est déclarée localement, tandis que toutes les traductions sont gérées à distance via le CMS. Cela permet de détacher complètement le contenu et les traductions de la base de code, offrant plus de flexibilité aux éditeurs de contenu et permettant le rechargement dynamique du contenu (pas besoin de reconstruire l'application pour appliquer les modifications).

package/docs/fr/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# Remplir les fichiers de déclaration de contenu traduits
+
+**L'autofill des fichiers de déclaration de contenu** dans votre CI est un moyen d'accélérer votre flux de développement.
+
+## Comprendre le comportement
+
+La commande `fill` inclut deux modes :
+
+- **Complete** : Remplit automatiquement tout le contenu manquant pour chaque locale et modifie le fichier actuel, ou un autre fichier s'il est spécifié. C'est-à-dire que le mode complete ignorera la traduction du contenu existant, s'il est déjà traduit.
+- **Review** : Remplit automatiquement **tout** le contenu pour chaque locale et génère pour un fichier spécifique, ou un autre fichier s'il est spécifié.
+
+La commande will traitera tous vos fichiers de déclaration de contenu locale. C'est-à-dire qu'elle ne traitera pas votre contenu distant du CMS. Le CMS inclut sa propre gestion des traductions.
+Si vous utilisez des plugins comme `@intlayer/sync-json-plugin`, Intlayer transformera les fichiers JSON en fichiers de déclaration de contenu locale. C'est-à-dire qu'ils seront traités par la commande `fill`.
+
+Les fichiers nouvellement générés incluent une instruction `filled` comme métadonnées de dictionnaire. Cette instruction sera utilisée par Intlayer pour savoir si le fichier a été rempli automatiquement ou non, et ignorer ce fichier d'une traduction supplémentaire s'il est présent.
+
+Intlayer considérera également l'instruction suivante pour le remplissage automatique :
+
+- De votre `.content.{ts|js|json}` → instruction `fill`
+- De votre fichier de configuration `.intlayer.config.ts` → instruction `dictionary.fill`
+- Sera défini à `true` par défaut autrement
+
+Pour les fichiers de déclaration de contenu par locale, l'instruction `true` sera remplacée par `./{{fileName}}.fill.content.json`. C'est parce qu'un fichier de déclaration de contenu par locale ne peut pas recevoir de contenu localisé supplémentaire. Donc il générera un nouveau fichier pour ne pas écraser le fichier existant.
+
+## Comportement par défaut
+
+Par défaut, `fill` est défini sur `true` globalement, ce qui signifie qu'Intlayer remplira automatiquement tous les fichiers de contenu et modifiera le fichier lui-même. Ce comportement peut être personnalisé de plusieurs façons :
+
+### Options de Configuration Globale
+
+1. **`fill: true` (par défaut)** - Remplir automatiquement toutes les locales et éditer le fichier courant
+2. **`fill: false`** - Désactiver le remplissage automatique pour ce fichier de contenu
+3. **`fill: "./relative/path/to/file"`** - Créer/mettre à jour le fichier spécifié sans éditer le fichier courant en pointant vers un chemin relatif résolu en fonction de l'emplacement du fichier courant
+4. **`fill: "/absolute/path/to/file"`** - Créer/mettre à jour le fichier spécifié sans éditer le fichier courant en pointant vers un chemin relatif résolu en fonction de l'emplacement du répertoire de base (champ `baseDir` dans le fichier de configuration `.intlayer.config.ts`)
+5. **`fill: "C:\\absolute\path\to\file"`** - Créer/mettre à jour le fichier spécifié sans éditer le fichier courant en pointant vers un chemin absolu résolu en fonction de votre système d'exploitation
+6. **`fill: { [key in Locales]?: string }`** - Créer/mettre à jour le fichier spécifié pour chaque locale
+
+### Changements de comportement v7
+
+Dans v7, le comportement de la commande `fill` a été mis à jour :
+
+- **`fill: true`** - Réécrit le fichier courant avec le contenu rempli pour toutes les locales
+- **`fill: "path/to/file"`** - Remplit le fichier spécifié sans modifier le fichier courant
+- **`fill: false`** - Désactive complètement le remplissage automatique
+
+Lors de l'utilisation d'une option de chemin pour écrire dans un autre fichier, le mécanisme de remplissage fonctionne via une relation _maître-esclave_ entre les fichiers de déclaration de contenu. Le fichier principal (maître) sert de source de vérité, et lorsqu'il est mis à jour, Intlayer applique automatiquement ces modifications aux fichiers de déclaration dérivés (remplis) spécifiés par le chemin.
+
 # Traductions des fichiers de déclaration de contenu avec remplissage automatique
 
 **Les fichiers de déclaration de contenu avec remplissage automatique** sont un moyen d'accélérer votre flux de travail de développement.
@@ -88,6 +135,40 @@ Intlayer générera automatiquement le fichier de déclaration dérivé à `src/
 
 Ensuite, les deux fichiers de déclaration seront fusionnés en un seul dictionnaire, accessible via le hook standard `useIntlayer("example")` (react) / composable (vue).
 
+## Configuration globale
+
+Vous pouvez configurer la configuration de remplissage automatique globale dans le fichier `intlayer.config.ts`.
+
+```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: {
+    // Générer automatiquement les traductions manquantes pour tous les dictionnaires
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // générer automatiquement les traductions manquantes pour tous les dictionnaires comme en utilisant "./{{fileName}}.content.json"
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+Vous pouvez toujours affiner par dictionnaire en utilisant le champ `fill` dans les fichiers de contenu. Intlayer considérera d'abord la configuration par dictionnaire et reviendra ensuite à la configuration globale.
+
 ## Format du fichier rempli automatiquement
 
 Le format recommandé pour les fichiers de déclaration remplis automatiquement est **JSON**, ce qui permet d'éviter les contraintes de formatage. Cependant, Intlayer prend également en charge les formats `.ts`, `.js`, `.mjs`, `.cjs` et d'autres.

package/docs/fr/benchmark/solid.md

@@ -118,6 +118,28 @@ Nous avons comparé **quatre stratégies de chargement** :
 - **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
 - **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
 
+### Ce que j'ai mesuré :
+
+J'ai exécuté la même application multilingue dans un vrai navigateur pour chaque stack, puis j'ai noté ce qui s'est réellement affiché sur le fil et le temps que cela a pris. Les tailles sont rapportées **après une compression web normale**, car c'est plus proche de ce que les gens téléchargent que les comptages de sources brutes.
+
+- **Taille de la bibliothèque d'internationalization** : Après bundling, tree-shaking et minification, la taille de la bibliothèque i18n est la taille du code des providers + hooks/primitives dans un composant vide. Elle n'inclut pas le chargement des fichiers de traduction. Elle répond à la question : à quel point la bibliothèque est-elle coûteuse avant que votre contenu ne soit pris en compte.
+
+- **JavaScript par page** : Pour chaque route de benchmark, combien de script le navigateur récupère lors de cette visite, moyenné sur les pages de la suite (et sur les locales où le rapport les agrège). Les pages lourdes sont des pages lentes.
+
+- **Fuite d'autres locales** : C'est le contenu de la même page mais dans une autre langue qui serait chargé par erreur dans la page auditée. Ce contenu est inutile et devrait être évité. (par exemple, le contenu de la page `/fr/about` dans le bundle de la page `/en/about`)
+
+- **Fuite d'autres routes** : La même idée pour les **autres écrans** de l'application : si leur contenu se charge quand vous n'avez ouvert qu'une seule page. (par exemple, le contenu de la page `/en/about` dans le bundle de la page `/en/contact`). Un score élevé indique un découpage faible ou des bundles trop larges.
+
+- **Taille moyenne du bundle du composant** : Les éléments d'interface communs sont mesurés **un à la fois** au lieu de se cacher dans un gigantesque numéro d'application. Cela montre si l'internationalization gonfle silencieusement les composants courants. Par exemple, si votre composant se rerender, il chargera toutes ces données de la mémoire. Attacher un énorme JSON à n'importe quel composant, c'est comme connecter un grand magasin de données inutilisées qui ralentira les performances de vos composants.
+
+- **Réactivité du changement de langue** : Je bascule la langue en utilisant le contrôle propre de l'application et je chronométre le temps qu'il faut jusqu'à ce que la page se soit clairement changée, ce qu'un visiteur remarquerait, et non une micro-étape de laboratoire.
+
+- **Travail de rendu après un changement de langue** : Un suivi plus étroit : combien d'effort l'interface a dû faire pour se repeindre pour la nouvelle langue une fois le changement en cours. Utile quand le temps « ressenti » et le coût du framework divergent.
+
+- **Temps de chargement initial de la page** : De la navigation à la considération par le navigateur que la page est complètement chargée pour les scénarios que j'ai testés. Bon pour comparer les démarrages à froid.
+
+- **Temps d'hydratation** : Quand l'application l'expose, le temps que le client passe à transformer le HTML du serveur en quelque chose que vous pouvez réellement cliquer. Un tiret dans les tableaux signifie que cette implémentation n'a pas fourni de chiffre d'hydratation fiable dans ce benchmark.
+
 ## Étoiles GitHub
 
 Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu'elles ne soient pas une mesure directe de la qualité technique, elles reflètent le nombre de développeurs qui trouvent le projet utile, suivent ses progrès et sont susceptibles de l'adopter. Pour estimer la valeur d'un projet, les étoiles aident à comparer l'attraction entre les alternatives et fournissent des informations sur la croissance de l'écosystème.

package/docs/fr/benchmark/svelte.md

@@ -116,6 +116,28 @@ Nous avons comparé **quatre stratégies de chargement** :
 - **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
 - **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
 
+### Ce que j'ai mesuré :
+
+J'ai exécuté la même application multilingue dans un vrai navigateur pour chaque stack, puis j'ai noté ce qui s'est réellement affiché sur le réseau et combien de temps cela a pris. Les tailles sont rapportées **après la compression web normale**, car c'est plus proche de ce que les gens téléchargent que les nombres de sources brutes.
+
+- **Taille de la bibliothèque d'internationalisation** : Après bundling, tree-shaking et minification, la taille de la bibliothèque i18n est la taille du code des providers + stores dans un composant vide. Elle n'inclut pas le chargement des fichiers de traduction. Elle répond à la question de savoir à quel point la bibliothèque est coûteuse avant que votre contenu n'entre en jeu.
+
+- **JavaScript par page** : Pour chaque route benchmark, la quantité de script que le navigateur récupère lors de cette visite, en moyenne sur les pages de la suite (et sur les locales lorsque le rapport les agrège). Les pages lourdes sont des pages lentes.
+
+- **Fuite d'autres locales** : C'est le contenu de la même page mais dans une autre langue qui serait chargé par erreur dans la page auditée. Ce contenu est inutile et devrait être évité. (par ex. le contenu de la page `/fr/about` dans le bundle de la page `/en/about`)
+
+- **Fuite d'autres routes** : La même idée pour **autres écrans** dans l'application : que leur contenu soit chargé quand vous n'avez ouvert qu'une seule page. (par ex. le contenu de la page `/en/about` dans le bundle de la page `/en/contact`). Un score élevé indique un splitting faible ou des bundles trop larges.
+
+- **Taille moyenne du bundle de composant** : Les éléments UI courants sont mesurés **un par un** au lieu de se cacher dans un énorme nombre d'applications. Elle montre si l'internationalisation gonfle silencieusement les composants quotidiens. Par exemple, si votre composant effectue un re-render, il chargera toutes ces données de la mémoire. Attacher un énorme JSON à n'importe quel composant, c'est comme connecter un grand magasin de données inutilisées qui ralentira les performances de vos composants.
+
+- **Réactivité du changement de langue** : Je bascule la langue en utilisant le contrôle propre de l'application et je mesure le temps qu'il faut jusqu'à ce que la page ait clairement basculé, ce qu'un visiteur remarquerait, pas une micro-étape de lab.
+
+- **Travail de rendu après un changement de langue** : Un suivi plus étroit : combien d'effort l'interface a pris pour se repeindre pour la nouvelle langue une fois le changement en cours. Utile quand le temps « ressenti » et le coût du framework divergent.
+
+- **Temps de chargement initial de la page** : De la navigation au navigateur considérant la page entièrement chargée pour les scénarios que j'ai testés. Bon pour comparer les démarrages à froid.
+
+- **Temps d'hydratation** : Lorsque l'application l'expose, combien de temps le client passe à transformer le HTML du serveur en quelque chose que vous pouvez réellement cliquer. Un tiret dans les tableaux signifie que cette implémentation n'a pas fourni de chiffre d'hydratation fiable dans ce benchmark.
+
 ## Étoiles GitHub
 
 Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu'elles ne soient pas une mesure directe de la qualité technique, elles reflètent le nombre de développeurs qui trouvent le projet utile, suivent ses progrès et sont susceptibles de l'adopter. Pour estimer la valeur d'un projet, les étoiles aident à comparer l'attraction entre les alternatives et fournissent des informations sur la croissance de l'écosystème.

package/docs/fr/benchmark/tanstack.md

@@ -124,6 +124,28 @@ Nous avons comparé **quatre stratégies de chargement** :
 - **Scoped static** : Organise bien le code (séparation logique) sans requêtes réseau supplémentaires complexes.
 - **Scoped dynamic** : Meilleure approche pour le _code splitting_ et la performance. Minimise la mémoire en ne chargeant que ce dont la vue actuelle et la locale active ont besoin.
 
+### Ce que j'ai mesuré :
+
+J'ai exécuté la même application multilingue dans un vrai navigateur pour chaque stack, puis j'ai noté ce qui s'est réellement affiché sur le réseau et combien de temps cela a pris. Les tailles sont rapportées **après une compression web normale**, car cela se rapproche davantage de ce que les gens téléchargent que des nombres de sources brutes.
+
+- **Taille de la bibliothèque d'internationalisation** : Après bundling, tree-shaking et minification, la taille de la bibliothèque i18n est la taille des providers (par ex. `NextIntlClientProvider`) + hooks (par ex. `useTranslations`) code dans un composant vide. Cela n'inclut pas le chargement des fichiers de traduction. Cela répond à la question de savoir combien coûte la bibliothèque avant que votre contenu n'entre en jeu.
+
+- **JavaScript par page** : Pour chaque route de benchmark, combien de script le navigateur télécharge lors de cette visite, en moyenne sur les pages de la suite (et sur les locales où le rapport les agrège). Les pages lourdes sont des pages lentes.
+
+- **Fuite d'autres locales** : C'est le contenu de la même page mais dans une autre langue qui serait chargé par erreur dans la page auditée. Ce contenu est inutile et doit être évité. (par ex. contenu de la page `/fr/about` dans le bundle de la page `/en/about`)
+
+- **Fuite d'autres routes** : La même idée pour **les autres écrans** de l'application : si leur copie est chargée lorsque vous n'avez ouvert qu'une seule page. (par ex. contenu de la page `/en/about` dans le bundle de la page `/en/contact`). Un score élevé suggère un fractionnement faible ou des bundles trop larges.
+
+- **Taille moyenne du bundle de composant** : Les éléments d'interface utilisateur courants sont mesurés **un à la fois** au lieu de se cacher dans un énorme nombre d'applications. Cela montre si l'internationalisation augmente discrètement les composants ordinaires. Par exemple, si votre composant se re-render, il chargera toutes ces données depuis la mémoire. Attacher un énorme JSON à n'importe quel composant, c'est comme connecter un grand magasin de données inutilisées qui ralentira les performances de vos composants.
+
+- **Réactivité du changement de langue** : Je bascule la langue en utilisant le contrôle de l'application et je mesure le temps qu'il faut jusqu'à ce que la page ait clairement basculé, ce qu'un visiteur remarquerait, pas une micro-étape de laboratoire.
+
+- **Travail de rendu après un changement de langue** : Un suivi plus étroit : combien d'effort l'interface a dû fournir pour se redessiner dans la nouvelle langue une fois le changement en vol. Utile lorsque le temps « ressenti » et le coût du framework divergent.
+
+- **Temps de chargement initial de la page** : De la navigation à la considération par le navigateur de la page comme entièrement chargée pour les scénarios que j'ai testés. Bon pour comparer les démarrages à froid.
+
+- **Temps d'hydratation** : Quand l'application l'expose, combien de temps le client passe à transformer du HTML serveur en quelque chose sur lequel vous pouvez réellement cliquer. Un tiret dans les tableaux signifie que cette implémentation n'a pas fourni de chiffre d'hydratation fiable dans ce benchmark.
+
 ## Étoiles GitHub
 
 Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu'elles ne soient pas une mesure directe de la qualité technique, elles reflètent le nombre de développeurs qui trouvent le projet utile, suivent ses progrès et sont susceptibles de l'adopter. Pour estimer la valeur d'un projet, les étoiles aident à comparer l'attraction entre les alternatives et fournissent des informations sur la croissance de l'écosystème.

package/docs/fr/cli/ci.md

@@ -140,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## GitHub Actions générés automatiquement
+
+Lorsque vous exécutez `intlayer init`, Intlayer détecte votre gestionnaire de paquets (npm, yarn, pnpm, ou bun) et génère automatiquement deux workflows GitHub Actions sous `.github/workflows/`, avec des commandes correspondant à ce gestionnaire de paquets :
+
+- **`intlayer-fill.yml`** — Sur chaque pull request, construit les dictionnaires et exécute `intlayer fill --git-diff --mode complete` pour générer les traductions manquantes pour les dictionnaires modifiés, puis valide le résultat sur la branche PR.
+- **`intlayer-test.yml`** — Sur chaque pull request, construit les dictionnaires et exécute `intlayer test`, échouant la vérification si les locales requises ont des traductions manquantes.
+
+Les fichiers de workflow existants ne sont jamais écrasés. Pour ignorer complètement la génération automatique, exécutez :
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Fournir un accès IA au workflow de remplissage
+
+Le fichier `intlayer-fill.yml` généré nécessite un accès IA. Deux options sont disponibles (configurées dans le bloc `env` du workflow) :
+
+1. **Votre propre clé de fournisseur IA** — Ajoutez un secret `AI_API_KEY` dans les paramètres de votre référentiel (Settings → Secrets and variables → Actions). Le workflow le transmet via `--provider`, `--model` et `--api-key`.
+2. **Clés d'accès Intlayer CMS** — Ajoutez les secrets `INTLAYER_CLIENT_ID` et `INTLAYER_CLIENT_SECRET` et intégrez-les dans la section `editor` de votre `intlayer.config`. Les clés d'accès CMS accordent l'accès IA via le backend Intlayer.
+
+Le workflow `intlayer-test.yml` ne nécessite aucun accès IA.
+
 ## Gestion des erreurs
 
 - Si `INTLAYER_PROJECT_CREDENTIALS` n'est pas définie, la commande se terminera avec une erreur.

package/docs/fr/cli/fill.md

@@ -47,6 +47,14 @@ Points clés :
 - Préserve les traductions existantes en ne les écrasant pas.
 - Traite les fichiers, les morceaux et les locales en parallèle à l'aide d'un système de file d'attente pour augmenter la vitesse.
 
+## Points clés :
+
+- Divise les fichiers JSON volumineux en chunks pour rester dans les limites de la fenêtre contextuelle du modèle d'IA.
+- Réessaye la traduction si le format de sortie est incorrect.
+- Intègre le contexte spécifique à l'application et au fichier pour améliorer la précision de la traduction.
+- Préserve les traductions existantes en ne les remplaçant pas.
+- Traite les fichiers, chunks et locales en parallèle en utilisant un système de file d'attente pour augmenter la vitesse.
+
 ## Alias :
 
 - `npx intlayer dictionaries fill`

package/docs/fr/cli/login.md

@@ -78,42 +78,6 @@ bun x intlayer login --cms-url https://intlayer.org
 
 ### Options de configuration
 
-Vous pouvez également utiliser les options de configuration communes :
-
-- `--env-file <path>` : Chemin vers le fichier d'environnement
-- `-e, --env <env>` : Environnement d'exécution
-- `--base-dir <dir>` : Répertoire de base du projet
-- `--verbose` : Active la sortie détaillée (par défaut : true)
-- `--prefix <prefix>` : Préfixe pour les logs
-
-## Fonctionnement
-
-1. **Démarrage d'un serveur local** : La commande démarre un serveur HTTP local sur un port aléatoire pour recevoir les identifiants depuis le CMS
-
-Spécifiez l'URL du CMS Intlayer auquel se connecter pour l'authentification.
-
-- **Type**: `string`
-- **Par défaut**: La valeur configurée dans `intlayer.config.*` ou `https://intlayer.org`
-- **Exemple**:
-
-```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
-```
-
-### Options de configuration
-
 Vous pouvez également utiliser les options de configuration courantes :
 
 - `--env-file <path>` : Chemin vers le fichier d'environnement

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

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrer de i18n-js vers Intlayer"
+description: "Apprenez comment migrer votre application de i18n-js vers Intlayer en utilisant l'adaptateur de compatibilité."
+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
+---
+
+# Migrer de i18n-js vers Intlayer
+
+La transition de la bibliothèque `i18n-js` vers Intlayer est une migration hautement optimisée conçue pour décharger les grandes configurations de traductions dans le système de résolution de fichiers structuré d'Intlayer.
+
+## Ce qu'il faut faire
+
+Exécutez la commande de configuration suivante dans votre référentiel :
+
+```bash
+npx intlayer init
+```
+
+Avec `intlayer.config.ts` préparé, vous pouvez ajouter l'alias d'Intlayer à la configuration de votre bundler afin que tous les imports de `i18n-js` ciblent le package de compatibilité `@intlayer/i18n-js`.
+
+## Ce qu'il fait sous le capot
+
+`i18n-js` accède aux namespaces par le biais d'expressions comme `i18n.t('scope.key', {name})` ainsi que des fallbacks de locale et des mappings pluriels spécifiques.
+
+Sous le capot :
+
+- **Interpolation :** L'adaptateur de compatibilité analyse facilement les mappings `%{name}` dans la valeur de dictionnaire runtime ciblée.
+- **Pluralisation :** Remplace les sous-clés `one/other` et les mappe par rapport aux puissants mécanismes pluriels sous-jacents d'Intlayer (`Intl.PluralRules`), en abstrayant les mappings manuels.
+- **Locales :** Au lieu de charger des payloads monolithiques de langage au bootstrap, les dictionnaires sont servis de manière optimale en fonction de la configuration de contexte actuelle via la configuration Intlayer native.

package/docs/fr/compat/i18next.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrer de i18next vers Intlayer"
+description: "Apprenez comment migrer votre application Vanilla JS/TS de i18next vers Intlayer en utilisant l'adaptateur de compatibilité."
+keywords:
+  - i18next
+  - vanilla
+  - javascript
+  - typescript
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrer de i18next vers Intlayer
+
+Pour un tutoriel détaillé étape par étape, veuillez consulter notre guide complet de [migration i18next](../migration_from_i18next_to_intlayer.md).
+
+Intlayer réplique parfaitement les caractéristiques d'exécution fondamentales de `i18next`. En utilisant le package compat, vos applications Vanilla ou modules internes peuvent continuer à exploiter la syntaxe familière.
+
+## Que faire
+
+Pour commencer, initialisez Intlayer dans votre projet :
+
+```bash
+npx intlayer init
+```
+
+Si vous utilisez Vite, incluez le plugin Intlayer pour router les imports vers `@intlayer/i18next` :
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { i18nextVitePlugin } from "@intlayer/i18next/plugin";
+
+export default defineConfig({
+  plugins: [i18nextVitePlugin()],
+});
+```
+
+## Ce qu'il fait sous le capot
+
+Le `i18nextVitePlugin` redirige les imports `i18next` vers `@intlayer/i18next`, évitant ainsi le gonflement du bundle causé par l'inclusion de fichiers JSON.
+
+Sous le capot :
+
+- **Configuration d'instance :** `createInstance` analyse correctement et applique les fallbacks de namespace tout en tirant parti du pipeline de compilation d'Intlayer pour la récupération des dictionnaires.
+- **Interpolation :** Support natif des remplacements `{{name}}` et imbrication `$t(key)` récursive.
+- **Contexte & Pluriels :** Identifie et résout les formats de suffixe comme `key_male` et `key_one`/`key_other` en évaluant par rapport à `Intl.PluralRules` standard.
+- **Retour d'objets :** Le mode `returnObjects: true` extrait de manière sécurisée les arbres des dictionnaires Intlayer.

package/docs/fr/compat/index.md

@@ -0,0 +1,51 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Adaptateurs de Compatibilité Intlayer"
+description: "Migrez votre solution i18n existante vers Intlayer sans friction en utilisant des adaptateurs de compatibilité."
+keywords:
+  - compat
+  - migration
+  - internationalization
+  - i18n
+  - Intlayer
+slugs:
+  - doc
+  - compatibility
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Adaptateurs Intlayer Compat
+
+Migrer une grande application vers une nouvelle bibliothèque d'internationalisation peut être intimidant. Pour faciliter cette transition, Intlayer fournit des **adaptateurs de compatibilité** pour les bibliothèques i18n les plus populaires de l'écosystème.
+
+Ces packages d'adaptateurs exposent la **même API publique exacte** que vos bibliothèques i18n existantes, mais délèguent tout le travail de traduction à Intlayer lors de l'exécution.
+
+## Fonctionnement
+
+Lorsque vous utilisez un adaptateur de compatibilité, vous n'avez pas besoin de réécrire les imports de votre application ou de modifier la façon dont vous utilisez vos hooks et composants de traduction. À la place, les plugins bundler d'Intlayer aliasent automatiquement vos imports existants vers les packages de compatibilité Intlayer.
+
+Par exemple, un développeur remplace `import { useTranslation } from 'react-i18next'` par `import { useTranslation } from '@intlayer/react-i18next'` (fait automatiquement via le plugin bundler), et l'application continue de fonctionner avec les traductions servies par les dictionnaires Intlayer. Les clés sont également typées par rapport à vos dictionnaires Intlayer !
+
+## Adaptateurs de compatibilité disponibles
+
+Choisissez votre librairie existante ci-dessous pour voir comment migrer sans friction :
+
+- [Vue I18n](./vue-i18n.md)
+- [Transloco](./transloco.md)
+- [React Intl](./react-intl.md)
+- [Svelte I18n](./svelte-i18n.md)
+- [React i18next](./react-i18next.md)
+- [Polyglot.js](./polyglot.md)
+- [NuxtJS I18n](./nuxtjs-i18n.md)
+- [NGX Translate](./ngx-translate.md)
+- [Next Translate](./next-translate.md)
+- [Next Intl](./next-intl.md)
+- [Next i18next](./next-i18next.md)
+- [i18next](./i18next.md)
+- [Lingui](./lingui.md)
+- [I18n-js](./i18n-js.md)

package/docs/fr/compat/lingui.md

@@ -0,0 +1,44 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrer de Lingui vers Intlayer"
+description: "Apprenez à migrer votre application de Lingui vers Intlayer en utilisant l'adaptateur de compatibilité."
+keywords:
+  - lingui
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - lingui
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrer de Lingui à Intlayer
+
+Si votre projet s'appuie actuellement sur la compilation basée sur les macros de Lingui, la transition vers Intlayer vous permet de maintenir vos puissants flux de travail avec macros tout en les soutenant nativement avec la stratégie de compilation JSON d'Intlayer.
+
+## À faire
+
+Pour commencer, initialisez Intlayer dans votre projet :
+
+```bash
+npx intlayer init
+```
+
+Cela crée votre `intlayer.config.ts`. Assurez-vous de conserver `@lingui/babel-plugin-lingui-macro` / `@lingui/swc-plugin` dans votre étape de build pour s'exécuter _avant_ le compilateur Intlayer. Ensuite, utilisez l'alias du plugin bundler pour router `@lingui/core` et `@lingui/react` vers `@intlayer/lingui`.
+
+## Ce qu'il fait sous le capot
+
+Lingui utilise des macros (comme `` t`Hello ${name}` `` et `<Trans>`) qui sont compilées en appels runtime comme `i18n._(id, values)`.
+
+Sous le capot :
+
+- **Macros :** Elles se compilent exactement comme avant, garantissant aucune perturbation dans votre syntaxe source.
+- **Runtime translation :** L'alias `i18n._()` utilise les dictionnaires Intlayer. Les IDs explicitement nommés et les IDs hachés sont entièrement mappés en utilisant les plugins de synchronisation `.po` d'Intlayer pour agréger et élaguer les clés de manière sécurisée.
+- **Capacités ICU :** Le support pour la pluralisation, la sélection et les variantes ICU reste robuste grâce au parser ICU unifié d'Intlayer, garantissant des résultats de rendu identiques.

package/docs/fr/compat/next-i18next.md

@@ -0,0 +1,57 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrer de next-i18next vers Intlayer"
+description: "Apprenez à migrer votre application Next.js de next-i18next vers Intlayer en utilisant l'adaptateur de compatibilité."
+keywords:
+  - next-i18next
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-i18next
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrer de next-i18next vers Intlayer
+
+Pour un tutoriel complet et détaillé étape par étape, veuillez consulter notre [Guide de migration next-i18next](../migration_from_next-i18next_to_intlayer.md).
+
+Intlayer gère toutes les implémentations Next.js Pages Router et App Router de manière transparente. L'utilisation de l'adaptateur vous permet de migrer votre implémentation `next-i18next` sans réécriture de code.
+
+## À faire
+
+Pour commencer, exécutez :
+
+```bash
+npx intlayer init
+```
+
+Cela crée le fichier de configuration Intlayer requis. Pour intégrer Intlayer en arrière-plan, mettez à jour votre `next.config.ts` :
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";
+
+const withIntlayer = createNextI18nPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## Ce qu'il fait sous le capot
+
+Le `createNextI18nPlugin` compose le comportement natif de Next.js aux côtés du plugin core `next-intlayer`, en injectant tous les aliases Webpack/Turbopack requis pour `next-i18next`, `react-i18next`, et `i18next`.
+
+Sous le capot :
+
+- **`serverSideTranslations` & `appWithTranslation` :** Ils fonctionnent désormais comme des wrappers pour les loaders internes d'Intlayer, contournant l'injection statique JSON volumineux.
+- **Client hooks :** Délègue immédiatement à `@intlayer/react-i18next` en conservant toutes les fonctionnalités de formatage, pluriels et espaces de noms imbriqués.

package/docs/fr/compat/next-intl.md

@@ -0,0 +1,59 @@
+---
+createdAt: 2026-06-13
+updatedAt: 2026-06-13
+title: "Migrer de next-intl vers Intlayer"
+description: "Apprenez comment migrer votre application Next.js de next-intl vers Intlayer en utilisant l'adaptateur de compatibilité."
+keywords:
+  - next-intl
+  - nextjs
+  - intlayer
+  - migration
+  - compat
+slugs:
+  - doc
+  - compatibility
+  - next-intl
+history:
+  - version: 9.0.0
+    date: 2026-06-13
+    changes: "Init history"
+author: aymericzip
+---
+
+# Migrer de next-intl vers Intlayer
+
+Pour un tutoriel complet et détaillé étape par étape, consultez notre [Guide de migration next-intl](../migration_from_next-intl_to_intlayer.md).
+
+Migrer de `next-intl` vers Intlayer vous permet de maintenir votre routage d'application et votre syntaxe complètement inchangés.
+
+## Ce qu'il faut faire
+
+Exécutez la commande suivante dans votre repository :
+
+```bash
+npx intlayer init
+```
+
+Cela créera un fichier `intlayer.config.ts`. Dans votre `next.config.ts`, utilisez le wrapper du plugin pour injecter de manière transparente les aliases `next-intl` vers `@intlayer/next-intl`.
+
+```typescript fileName="next.config.ts"
+import type { NextConfig } from "next";
+import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";
+
+const withIntlayer = createNextIntlPlugin();
+
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+## Ce qu'il fait sous le capot
+
+Le wrapper bundler remplace les traductions, mais **laisse les fonctionnalités de `next-intl/navigation` intactes** (par exemple `Link`, `redirect`, `usePathname`).
+
+Sous le capot :
+
+- **ICU runtime :** Les pluriels (`=0`, `one`, `other`), select/selectordinal, les arguments `#`, et les args formatés (`{ts, date, long}`) fonctionnent correctement en utilisant le resolver partagé `resolveMessage(..., 'icu')`.
+- **`useTranslations()` & `getTranslations()` :** Les appels de scope nu extraient le premier segment de clé comme l'identifiant de dictionnaire correct. Les namespaces imbriqués se divisent gracieusement en chemins de dictionnaire et préfixes.
+- **Rich formatting :** Both `t.rich()` et `t.markup()` sont entièrement implémentés nativement, convertissant les nœuds de type HTML en chunks React rendus.
+- **`useFormatter` :** `relativeTime`, `list`, `dateTimeRange`, et les formats nommés de la configuration se connectent aux formatters natifs `Intl` du cœur.