@intlayer/docs 8.12.5-canary.0 → 9.0.0-canary.10

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/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-06-17
 title: Revue de Document
 description: Apprenez comment revoir les fichiers de documentation pour la qualité, la cohérence et l'exhaustivité à travers différentes locales.
 keywords:
@@ -15,6 +15,10 @@ slugs:
   - concept
   - cli
   - doc-review
+history:
+  - version: 9.0.0
+    date: 2026-06-17
+    changes: "Ajout de l'option --log"
 author: aymericzip
 ---
 
@@ -55,8 +59,110 @@ Pour la plupart des cas d'utilisation,
 
 ## Arguments :
 
-La commande `doc review` accepte les mêmes arguments que `doc translate`, vous permettant de revoir des fichiers de documentation spécifiques et d'appliquer des contrôles de qualité.
+**Options de liste de fichiers :**
 
-Si vous avez activé l'une des options git, la commande ne passera en revue que la partie des fichiers qui est modifiée. Le script traitera le fichier par découpage en chunks et examinera chaque chunk. S'il n'y a pas de modifications dans le chunk, le script le sautera pour accélérer le processus de revue et limiter le coût de l'API du fournisseur d'IA.
+- **`--doc-pattern [docPattern...]`** : Motifs glob pour sélectionner les fichiers de documentation à revoir.
 
-Pour une liste complète des arguments, consultez la documentation de la commande [Translate Document](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/cli/doc-translate.md).
+  > Exemple : `npx intlayer doc review --doc-pattern "docs/**/*.md" "src/**/*.mdx"`
+
+- **`--excluded-glob-pattern [excludedGlobPattern...]`** : Motifs glob à exclure de la revue.
+
+  > Exemple : `npx intlayer doc review --excluded-glob-pattern "docs/internal/**"`
+
+- **`--skip-if-modified-before [skipIfModifiedBefore]`** : Ignorer le fichier s'il a été modifié avant l'heure donnée.
+  - Peut être une heure absolue comme "2025-12-05" (string ou Date)
+  - Peut être un temps relatif en ms `1 * 60 * 60 * 1000` (1 heure)
+  - Cette option vérifie la date de mise à jour du fichier en utilisant la méthode `fs.stat`. Elle peut donc être impactée par Git ou d'autres outils qui modifient le fichier.
+
+  > Exemple : `npx intlayer doc review --skip-if-modified-before "2025-12-05"`
+
+- **`--skip-if-modified-after [skipIfModifiedAfter]`** : Ignorer le fichier s'il a été modifié dans le délai donné.
+  - Peut être une heure absolue comme "2025-12-05" (string ou Date)
+  - Peut être un temps relatif en ms `1 * 60 * 60 * 1000` (1 heure)
+  - Cette option vérifie la date de mise à jour du fichier en utilisant la méthode `fs.stat`. Elle peut donc être impactée par Git ou d'autres outils qui modifient le fichier.
+
+  > Exemple : `npx intlayer doc review --skip-if-modified-after "2025-12-05"`
+
+- **`--skip-if-exists`** : Ignorer le fichier s'il existe déjà.
+
+  > Exemple : `npx intlayer doc review --skip-if-exists`
+
+**Options de mode de revue :**
+
+- **`--log`** : Mode journalisation uniquement. Ne traduit pas avec l'IA ; à la place, journalise les blocs qui nécessitent une attention (avec les numéros de ligne et le contenu) pour les locales de base et cibles, afin d'aider un autre agent à générer les traductions.
+
+  > Exemple : `npx intlayer doc review --log`
+
+**Options de sortie des entrées :**
+
+- **`--locales [locales...]`** : Locales cibles pour lesquelles revoir la documentation.
+
+  > Exemple : `npx intlayer doc review --locales fr es de`
+
+- **`--base-locale [baseLocale]`** : Locale source (document de base) à comparer.
+
+  > Exemple : `npx intlayer doc review --base-locale en`
+
+**Options de traitement des fichiers :**
+
+- **`--nb-simultaneous-file-processed [nbSimultaneousFileProcessed]`** : Nombre de fichiers à traiter simultanément pour la revue.
+
+  > Exemple : `npx intlayer doc review --nb-simultaneous-file-processed 5`
+
+**Options AI :**
+
+- **`--model [model]`** : Modèle d'IA à utiliser pour la revue (par exemple, `gpt-3.5-turbo`).
+- **`--provider [provider]`** : Fournisseur d'IA à utiliser pour la revue.
+- **`--temperature [temperature]`** : Paramètre de température pour le modèle d'IA.
+- **`--api-key [apiKey]`** : Fournir votre propre clé API pour le service d'IA.
+- **`--application-context [applicationContext]`** : Fournir un contexte supplémentaire pour la revue par IA.
+- **`--data-serialization [dataSerialization]`** : Le format de sérialisation des données à utiliser pour les fonctionnalités d'IA d'Intlayer. Options : `json` (standard, fiable), `toon` (moins de tokens, moins cohérent).
+- **`--custom-prompt [prompt]`** : Personnalisez le prompt de base utilisé pour la revue. (Remarque : Pour la plupart des cas d'utilisation, l'option `--custom-instructions` est recommandée car elle offre un meilleur contrôle.)
+
+  > Exemple : `npx intlayer doc review --model deepseek-chat --provider deepseek --temperature 0.5 --api-key sk-1234567890 --application-context "Mon application est une boutique de chats"`
+
+**Options des variables d'environnement :**
+
+- **`--env`** : Spécifiez l'environnement (par exemple, `development`, `production`).
+- **`--env-file [envFile]`** : Fournissez un fichier d'environnement personnalisé pour charger les variables.
+- **`--base-dir`** : Spécifiez le répertoire de base du projet.
+- **`--no-cache`** : Désactive le cache.
+
+  > Exemple : `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
+
+**Options de journalisation :**
+
+- **`--verbose`** : Active la journalisation détaillée pour le débogage. (par défaut à true en utilisant la CLI)
+
+  > Exemple : `npx intlayer doc review --verbose`
+
+**Options d'instructions personnalisées :**
+
+- **`--custom-instructions [customInstructions]`** : Instructions personnalisées ajoutées au prompt. Utile pour appliquer des règles spécifiques concernant le formatage, la traduction des URLs, etc.
+
+  > Exemple : `npx intlayer doc review --custom-instructions "Évitez de traduire les URLs et conservez le format markdown"`
+
+  > Exemple : `npx intlayer doc review --custom-instructions "$(cat ./instructions.md)"`
+
+**Options Git :**
+
+- **`--git-diff`** : Ne s'exécute que sur les fichiers qui incluent des modifications depuis la base (par défaut `origin/main`) vers la branche courante (par défaut : `HEAD`).
+- **`--git-diff-base`** : Spécifie la référence de base pour le git diff (par défaut `origin/main`).
+- **`--git-diff-current`** : Spécifie la référence courante pour le git diff (par défaut : `HEAD`).
+- **`--uncommitted`** : Inclut les modifications non commises.
+- **`--unpushed`** : Inclut les modifications non poussées.
+- **`--untracked`** : Inclut les fichiers non suivis.
+
+  > Exemple : `npx intlayer doc review --git-diff --git-diff-base origin/main --git-diff-current HEAD`
+
+  > Exemple : `npx intlayer doc review --uncommitted --unpushed --untracked`
+
+> Notez que le chemin du fichier de sortie sera déterminé en remplaçant les motifs suivants :
+>
+> - `/{{baseLocale}}/` par `/{{locale}}/` (Unix)
+> - `\{{baseLocale}}\` par `\{{locale}}\` (Windows)
+> - `_{{baseLocale}}.` par `_{{locale}}.`
+> - `{{baseLocale}}_` par `{{locale}}_`
+> - `.{{baseLocaleName}}.` par `.{{localeName}}.`
+>
+> Si le motif n'est pas trouvé, le fichier de sortie ajoutera `.{{locale}}` à l'extension du fichier. Par exemple, `./my/file.md` sera revu et mis à jour en `./my/file.fr.md` pour la locale française.

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/index.md

@@ -17,7 +17,7 @@ slugs:
   - concept
   - cli
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "Ajout de la commande scan"
   - version: 8.6.4

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/cli/scan.md

@@ -18,7 +18,7 @@ slugs:
   - cli
   - scan
 history:
-  - version: 8.13.0
+  - version: 9.0.0
     date: 2026-06-11
     changes: "Ajout de la commande scan"
 author: aymericzip

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.