@intlayer/docs 9.4.2 → 9.4.4

package/blog/fr/i18n_in_ci_cd_pipelines.md

@@ -0,0 +1,247 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Automatiser les traductions dans la CI/CD sans livrer de mauvais textes"
+description: Trois points d'automatisation i18n, pre-push, pull request et runtime. Comment bloquer un build sur la couverture, auto-compléter en sécurité et éviter la boucle infinie de commits.
+keywords:
+  - automatiser traductions ci
+  - i18n ci cd
+  - github actions traductions
+  - husky pre-push
+  - localisation continue
+  - pipeline de traduction
+slugs:
+  - blog
+  - i18n-in-ci-cd-pipelines
+author: aymericzip
+---
+
+# Automatiser les traductions dans la CI/CD sans livrer de mauvais textes
+
+La traduction manuelle ne résiste pas au rythme des déploiements modernes. Un développeur ajoute une chaîne le vendredi, l'export n'a lieu qu'au sprint suivant, et trois autres langues accumulent déjà du retard. L'automatiser est facile. L'automatiser sans publier silencieusement du contenu brut généré par machine auprès de vos utilisateurs est la vraie question à résoudre.
+
+## Table des matières
+
+<TOC/>
+
+## Nul besoin de migrer pour automatiser
+
+Les pipelines décrits ci-dessous sont indépendants de la bibliothèque utilisée, tout comme l'outillage. Si vos textes sont des catalogues JSON pour i18next, next-intl, react-intl, vue-i18n ou next-translate, le [plugin Sync JSON](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/plugins/sync-json.md) lit et écrit ces fichiers directement sur place :
+
+```ts fileName="intlayer.config.ts"
+import { syncJSON } from "@intlayer/sync-json-plugin";
+
+const config = {
+  plugins: [
+    syncJSON({
+      source: ({ key, locale }) => `./locales/${locale}/${key}.json`,
+      format: "i18next", // ou "icu" pour next-intl / react-intl
+    }),
+  ],
+};
+
+export default config;
+```
+
+Votre application continue d'importer ce qu'elle importe déjà. Les jobs CI complètent et valident alors vos catalogues existants, et le diff affiché au relecteur est simplement une mise à jour de `locales/fr/checkout.json`, et non une migration d'architecture. Il existe aussi un [plugin Sync PO](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/plugins/sync-po.md) pour les flux gettext, ainsi que des [adaptateurs de compatibilité](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/index.md) pour conserver votre API runtime actuelle.
+
+## Séparer le contrôle de garde (gate) du remplissage (fill)
+
+Deux rôles différents sont trop souvent confondus.
+
+Un **gate** est une vérification bloquante. Il décrète qu'une version ne doit pas être livrée car des locales obligatoires sont incomplètes. Il n'écrit aucun fichier.
+
+Un **fill** est une opération de mutation. Il génère les traductions manquantes et les commite. Il ne fait jamais échouer un build.
+
+Ne faire qu'un fill signifie que rien ne bloque jamais, et que des traductions automatiques non vérifiées partent directement en production. Ne faire qu'un gate signifie que le build devient rouge et qu'un humain doit intervenir pour débloquer la situation à chaque fois. La plupart des équipes souhaitent les deux, associés à des déclencheurs distincts : fill sur une pull request, gate lors du merge sur la branche de release.
+
+## Où positionner l'automatisation
+
+| Étape          | Déclencheur | Idéal pour                                 | Coût                                          |
+| :------------- | :---------- | :----------------------------------------- | :-------------------------------------------- |
+| Hook pre-push  | Git local   | Retour rapide, aucune minute CI consommée  | S'exécute sur la machine et la clé API du dév |
+| Pull request   | Job CI      | Relecture avant merge, centralisation clés | Minutes CI plus appels de modèle par PR       |
+| Release branch | Job CI      | Blocage strict sur la couverture           | Économique, aucun appel de modèle             |
+| Runtime        | CMS         | Modifications de contenu sans rebuild      | Dépendance hébergée                           |
+
+## Pre-push : la boucle la plus rapide
+
+Husky exécute le remplissage avant que le code ne quitte la machine, afin que les traductions arrivent dans le même push que les chaînes nouvellement introduites.
+
+```bash fileName=".husky/pre-push"
+npx intlayer build
+npx intlayer fill --unpushed --mode complete
+```
+
+`--unpushed` restreint le traitement au contenu non encore poussé, évitant que la commande ne prenne une minute à chaque envoi. `--mode complete` remplit uniquement ce qui manque sans réécrire les entrées qui ont déjà une valeur, garantissant qu'une traduction relue ne soit jamais écrasée.
+
+Dans un monorepo, ciblez chaque application :
+
+```bash fileName=".husky/pre-push"
+npx intlayer build --base-dir ./app1
+npx intlayer fill --base-dir ./app1 --unpushed --mode complete
+npx intlayer build --base-dir ./app2
+npx intlayer fill --base-dir ./app2 --unpushed --mode complete
+```
+
+L'inconvénient est réel : chaque développeur a besoin d'une clé API, et le coût incombe à celui qui push. C'est pourquoi la plupart des équipes déplacent cette étape dans la CI dès qu'elles grandissent.
+
+## Pull request : générer là où se fait la relecture
+
+Le même processus dans GitHub Actions, ciblé sur le diff :
+
+```yaml fileName=".github/workflows/intlayer-translate.yml"
+name: Intlayer Auto-Fill
+on:
+  pull_request:
+    branches: ["main"]
+
+permissions:
+  contents: write
+  pull-requests: write
+
+concurrency:
+  group: "autofill-${{ github.ref }}"
+  cancel-in-progress: true
+
+jobs:
+  autofill:
+    runs-on: ubuntu-latest
+    env:
+      AI_PROVIDER: openai
+      AI_MODEL: gpt-5-mini
+      AI_API_KEY: ${{ secrets.AI_API_KEY }}
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: true
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - run: npm install
+      - run: npx intlayer build
+      - run: npx intlayer fill --git-diff --mode complete --provider $AI_PROVIDER --model $AI_MODEL --api-key $AI_API_KEY
+      - name: Commit
+        run: |
+          if [ -n "$(git status --porcelain)" ]; then
+            git config --local user.email "action@github.com"
+            git config --local user.name "GitHub Action"
+            git add .
+            git commit -m "chore: auto-fill missing translations [skip ci]"
+            git push origin HEAD:${{ github.head_ref }}
+          fi
+```
+
+Quatre points clés sont déterminants ici :
+
+- **`fetch-depth: 0`** est indispensable pour que `--git-diff` fonctionne. Un clone superficiel ne dispose pas de base pour calculer le diff, et le remplissage ne traite silencieusement rien.
+- **`[skip ci]` dans le message de commit** empêche le workflow de se redéclencher indéfiniment. Sans cela, le commit lance une exécution qui commite à nouveau, la manière la plus rapide de brûler son forfait CI en une nuit.
+- **`concurrency` avec `cancel-in-progress`** évite que deux push concurrents n'écrivent dans les mêmes fichiers en même temps.
+- **`--git-diff`** restreint la génération aux modifications de la PR. Omettez-le et vous retraduirez tout le catalogue à chaque passage.
+
+Les traductions sont ajoutées sous forme de commit sur la branche de la PR, ce qui permet au relecteur de voir le diff. C'est l'intérêt majeur de le faire ici plutôt qu'après le merge.
+
+## Branche de release : le contrôle bloquant (gate)
+
+Le gate n'a besoin d'aucun modèle et doit être rapide.
+
+```yaml fileName=".github/workflows/ci.yml"
+- run: npm run test:i18n
+```
+
+Appuyé par un test qui valide la couverture par assertion plutôt que par un simple rapport en console :
+
+```ts fileName="i18n.test.ts"
+import { listMissingTranslations } from "intlayer/cli";
+
+test("n'a aucune locale obligatoire manquante", async () => {
+  const result = await listMissingTranslations();
+  if (result.missingRequiredLocales.length > 0) {
+    console.log(result.missingTranslations);
+  }
+  expect(result.missingRequiredLocales).toHaveLength(0);
+});
+```
+
+`npx intlayer content test` affiche un rapport mais se termine avec un code de retour 0, ce qui informe sans bloquer. Utilisez-le en local ; utilisez l'assertion en CI. Plus de précisions dans [détecter les traductions manquantes](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/detecting_missing_translations.md).
+
+## `requiredLocales` rend le gate viable au quotidien
+
+Un contrôle exigeant les dix-huit langues complètes bloque chaque release jusqu'à l'arrivée de la dernière traduction, et finit par être désactivé en moins d'un mois.
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    requiredLocales: [Locales.ENGLISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+};
+
+export default config;
+```
+
+Déclarez les langues que vous servez, et n'exigez en bloquant que celles indispensables à la release. Le reste se complète de façon asynchrone sans jamais freiner les déploiements.
+
+## Déporter les traductions hors du dépôt
+
+L'autre stratégie consiste à déclarer une locale dans le code et à gérer le reste à distance via le CMS avec Live Sync. Les modifications de contenu ne requièrent plus aucun rebuild, séparant le rythme éditorial du cycle de déploiement technique.
+
+```ts fileName="intlayer.config.ts"
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.SPANISH, Locales.FRENCH],
+    requiredLocales: [Locales.ENGLISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  editor: {
+    clientId: process.env.INTLAYER_CLIENT_ID,
+    clientSecret: process.env.INTLAYER_CLIENT_SECRET,
+    liveSync: true,
+  },
+};
+
+export default config;
+```
+
+Ce mode convient particulièrement aux équipes où des contributeurs non-techniques gèrent les textes. Il s'agit d'un compromis : vous gagnez en autonomie éditoriale et perdez la propriété où un checkout Git reflète à lui seul l'état exact de l'application. Consultez la [documentation du CMS](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/intlayer_CMS.md).
+
+Notez que `clientSecret` est un identifiant sensible côté serveur. Il doit rester dans les secrets CI et vos variables d'environnement de serveur, jamais dans un bundle client.
+
+## Les limites réelles
+
+Tout ce qui précède automatise la _couverture_, pas la _qualité_. Une génération automatique transforme une absence visible en un texte présent mais non relu : l'audit devient vert et personne n'a validé le sens.
+
+C'est acceptable pour un outil interne, un changelog ou une locale en bêta. Cela ne l'est pas pour une page de tarification, des mentions légales ou des messages d'erreur de paiement. Pour ces éléments critiques, passez par une relecture humaine et utilisez `--mode complete` afin d'éviter qu'une chaîne validée ne soit écrasée par la suite.
+
+Fournissez du contexte au modèle pour assurer une cohérence :
+
+```ts
+ai: {
+  applicationContext: "Application de facturation B2B. Ton professionnel. Ne jamais traduire le nom du produit.",
+}
+```
+
+## Erreurs courantes
+
+- **Oublier `[skip ci]` sur l'auto-commit.** Le job boucle indéfiniment sur lui-même.
+- **Clone superficiel avec `--git-diff`.** Pas de base pour comparer, rien n'est rempli sans qu'aucune alerte n'apparaisse.
+- **Remplir tout le catalogue à chaque run.** Spécifiez `--git-diff` ou `--unpushed` pour maîtriser les coûts.
+- **Utiliser le rapport CLI comme gate.** Le code de retour est 0.
+- **Rendre chaque locale obligatoire.** Le check est désactivé dès la première livraison bloquée.
+- **Un job de fill sans aucun gate.** Rien n'échoue jamais, et des textes non révisés partent en production.
+- **Mettre des clés API de modèle dans le repo.** Elles doivent résider dans les secrets CI, comme `clientSecret`.
+
+## Pour aller plus loin
+
+- [CI/CD : auto-génération de traductions avec Husky, GitHub Actions et le CMS](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/CI_CD.md)
+- [Tester son contenu et bloquer un build sur la couverture](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/testing.md)
+- [autoFill : génération de fichiers de déclaration par locale](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/autoFill.md)
+- [Référence de configuration : `locales`, `requiredLocales`, `editor`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/configuration.md)
+- [Rapports de benchmark entre frameworks](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/benchmark/index.md)
+- [Adaptateur de compatibilité i18next](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/i18next.md)
+- [Comment détecter les traductions manquantes](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/detecting_missing_translations.md)
+- [Comment tester les traductions sans tests fragiles](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/i18n_testing_strategies.md)

package/blog/fr/i18n_meaning.md

@@ -19,8 +19,6 @@ author: aymericzip
 
 # Signification de i18n : Qu'est-ce que l'internationalisation et pourquoi est-ce important ?
 
-![i18n illustration](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18n.webp)
-
 ## Comprendre la signification de l'« i18n »
 
 Si vous travaillez dans le développement logiciel, le design web ou le marketing numérique, vous avez probablement rencontré le terme **i18n**. La véritable signification de l'**i18n** est simplement un numéronymе pour **internationalization** (internationalisation).

package/blog/fr/i18n_testing_strategies.md

@@ -0,0 +1,179 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Comment tester les traductions sans écrire de tests fragiles"
+description: Ce qui vaut la peine d'être testé dans une application i18n et ce qui ne l'est pas. Tests de rendu avec provider, pseudolocalisation, couverture RTL et pluriels, et le piège des snapshots.
+keywords:
+  - tester traductions
+  - tests i18n
+  - testing library i18n
+  - pseudolocalisation
+  - test provider locale
+  - snapshot test i18n
+slugs:
+  - blog
+  - i18n-testing-strategies
+author: aymericzip
+---
+
+# Comment tester les traductions sans écrire de tests fragiles
+
+La plupart des suites de tests i18n échouent de deux manières. Soit elles vérifient le texte littéral, de sorte que chaque modification de formulation casse cinquante tests et pousse l'équipe à les supprimer. Soit elles effectuent le rendu uniquement dans la locale par défaut, ne prouvant rien sur les dix-sept autres. Les deux mènent au même résultat, une suite en laquelle personne n'a confiance.
+
+## Table des matières
+
+<TOC/>
+
+## Les patterns sont indépendants de la bibliothèque
+
+Chaque pattern ci-dessous fonctionne sur n'importe quelle stack i18n. Remplacez le provider par `I18nextProvider`, `NextIntlClientProvider` ou `IntlProvider` et les tests restent identiques, car ils valident la sortie rendue plutôt qu'une API spécifique.
+
+L'outillage de couverture s'adapte également : avec le [plugin Sync JSON](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/plugins/sync-json.md) branché sur vos catalogues existants, ou un [adaptateur de compatibilité](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/index.md) créant un alias sur vos imports actuels, la vérification de couverture s'exécute sur le JSON déjà en place.
+
+## Déterminer ce que vous testez réellement
+
+La qualité d'une traduction ne se teste pas par assertion. Aucune assertion ne vous dira si l'allemand est idiomatique, et prétendre le contraire produit une suite encombrée de chaînes écrites en dur.
+
+Ce qui mérite d'être testé est mécanique :
+
+| Vaut la peine d'être testé                | Ne vaut pas la peine d'être testé |
+| :---------------------------------------- | :-------------------------------- |
+| Chaque locale requise possède une valeur  | La formulation est-elle élégante  |
+| La bonne locale parvient au composant     | Le libellé exact de chaque texte  |
+| Les pluriels fonctionnent pour chaque cas | Le traducteur a bien fait son job |
+| Les locales RTL appliquent sens et miroir | Chaque chaîne dans chaque locale  |
+| Les dates et nombres respectent la locale | L'exactitude interne d'`Intl`     |
+
+La couverture relève d'un seul test automatisé orienté données, et non de vos tests de composants. Ce sujet est abordé dans [détecter les traductions manquantes](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/detecting_missing_translations.md) ; cet article traite du reste.
+
+## Effectuer le rendu dans un provider et cibler par rôle
+
+Le pattern central consiste à monter le composant au sein d'un provider de locale et à interroger par rôle ou identifiant de test plutôt que par le texte.
+
+```tsx fileName="CartSummary.test.tsx"
+import { render, screen } from "@testing-library/react";
+import { IntlayerProvider } from "react-intlayer/client";
+import { CartSummary } from "./CartSummary";
+
+test("affiche le titre du récapitulatif en français", () => {
+  render(
+    <IntlayerProvider locale="fr-FR">
+      <CartSummary />
+    </IntlayerProvider>
+  );
+
+  expect(screen.getByRole("heading")).toBeInTheDocument();
+});
+```
+
+Interroger `getByRole("heading")` résiste aux changements de texte. `getByText("Récapitulatif")` échoue au moindre ajustement. N'utilisez le texte exact que lorsque la chaîne elle-même constitue l'élément testé, ce qui reste rare.
+
+Pour les attributs comme `aria-label`, vous avez besoin de la chaîne brute plutôt que d'un nœud affichable. Dans React, les entrées `useIntlayer` exposent un champ `.value` pour cela.
+
+## Paramétrer les tests à travers les locales
+
+Un seul corps de test exécuté sur chaque locale apporte bien plus de valeur qu'un test distinct par locale.
+
+```tsx fileName="direction.test.tsx"
+import { getHTMLTextDir } from "intlayer";
+import { render } from "@testing-library/react";
+import { IntlayerProvider } from "react-intlayer/client";
+
+describe.each(["en", "fr", "ja", "ar"])("locale %s", (locale) => {
+  it("s'affiche sans revenir à la clé brute", () => {
+    const { container } = render(
+      <IntlayerProvider locale={locale}>
+        <CartSummary />
+      </IntlayerProvider>
+    );
+
+    // Une clé affichée signifie que la résolution a échoué.
+    expect(container.textContent).not.toMatch(/^[a-z]+(\.[a-z]+)+$/);
+  });
+
+  it("définit la bonne direction de texte", () => {
+    expect(getHTMLTextDir(locale)).toBe(locale === "ar" ? "rtl" : "ltr");
+  });
+});
+```
+
+La première assertion constitue un gain générique appréciable : si une clé échoue et que votre bibliothèque affiche la clé, le DOM contient une structure du type `cart.summary.title`. Cela détecte toute une classe de bugs sans citer une seule phrase.
+
+## La pseudolocalisation révèle ce que les catalogues ne voient pas
+
+Ajoutez une fausse locale qui transforme chaque chaîne, par exemple en remplaçant `Checkout` par `[!!! Çĥéçķöũţ !!!]`. Affichez ensuite la page dans cette langue.
+
+Tout ce qui apparaît encore en anglais standard est écrit en dur dans le code. Aucun contrôle basé sur un catalogue ne peut l'identifier, car du point de vue des outils, la chaîne n'existe pas. Les crochets jouent un second rôle : ils allongent le texte d'environ 30 pour cent, révélant les ruptures de mise en page avant même de tester l'allemand.
+
+Ce contrôle s'exécute idéalement lors d'une passe visuelle ou end-to-end plutôt qu'en test unitaire, car l'erreur saute directement aux yeux.
+
+## Les pluriels exigent un test par catégorie, pas par langue
+
+Les anomalies de pluriel passent inaperçues car l'anglais n'utilise que deux formes, sur lesquelles la majorité des développeurs se concentrent. Le polonais en compte quatre, l'arabe six.
+
+```ts fileName="plural.test.ts"
+// L'arabe couvre zero, one, two, few, many, other.
+describe.each([0, 1, 2, 3, 11, 100])("quantité %i", (count) => {
+  it("produit une chaîne non vide en arabe", () => {
+    expect(formatItems(count, "ar")).not.toBe("");
+  });
+});
+```
+
+Choisissez des nombres ciblant chaque catégorie CLDR pour votre langue la plus complexe, plutôt que de vous limiter à 1 et 2 partout. `Intl.PluralRules` indique la catégorie attribuée à un nombre, ce qui permet de déduire vos jeux de test sans tâtonner. Retrouvez plus de précisions sur les catégories dans [l'article sur le format de message ICU](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/icu_message_format.md).
+
+## Le piège des tests par instantané (snapshots)
+
+Les snapshots et l'internationalisation font mauvais ménage. Le snapshot d'un composant localisé fige chaque chaîne. Dès qu'un traducteur corrige une faute en portugais, une suite verte devient rouge, sur un fichier qu'aucun relecteur ne comprend vraiment. Au bout de quelques alertes, quelqu'un relance `-u` sans lire le diff, et les snapshots perdent toute valeur.
+
+Si vous tenez aux snapshots, prenez-les dans une seule locale et traitez-les comme un contrôle structurel plutôt que textuel. Tout ce qui dépend d'une locale spécifique doit faire l'objet d'assertions ciblées.
+
+## Tester la négociation de la locale, pas seulement le rendu
+
+Le bug i18n le plus fréquent en production n'est pas une chaîne manquante. C'est le choix d'une mauvaise locale : une URL indique `/fr/`, le client lit `navigator.language`, et les deux entrent en conflit.
+
+Testez la logique de résolution directement, sous forme de fonction pure, indépendamment de tout composant :
+
+```ts fileName="locale-resolution.test.ts"
+it("privilégie l'URL par rapport à la préférence enregistrée", () => {
+  expect(resolveLocale({ url: "/fr/about", stored: "de", header: "ja" })).toBe(
+    "fr"
+  );
+});
+
+it("utilise l'en-tête lorsque l'URL ne comporte pas de préfixe", () => {
+  expect(resolveLocale({ url: "/about", stored: null, header: "ja" })).toBe(
+    "ja"
+  );
+});
+```
+
+C'est le test d'internationalisation ayant la plus forte valeur ajoutée qui manque dans la plupart des projets, et il ne requiert aucun DOM.
+
+## Que lancer et à quel moment
+
+- **Unitaire** : négociation de locale, formateurs, catégories de pluriels. Rapide, sans DOM.
+- **Composant** : un rendu avec provider par locale, validant les rôles et l'absence de clés brutes.
+- **Couverture** : un test orienté données garantissant l'absence de clés manquantes sur les locales requises.
+- **Visuel ou end-to-end** : passage en pseudolocalisation et une page RTL, car ces défauts sont purement visuels.
+
+Conservez les trois premiers dans la CI à chaque commit. Le dernier reste idéal lors d'exécutions nocturnes, étant plus coûteux à chaque push.
+
+## Erreurs courantes
+
+- **Valider le texte exact partout.** Condamne la suite de tests à l'abandon d'ici quelques mois.
+- **Prendre des snapshots de composants localisés.** Les traducteurs cassent le build et les relecteurs valident à l'aveugle.
+- **Tester uniquement la locale par défaut.** La seule locale qui ne peut jamais manquer.
+- **Tester uniquement 1 et 2 pour les pluriels.** Ignore toutes les catégories absentes de l'anglais.
+- **Mocker la bibliothèque i18n.** Vous testez alors uniquement que votre mock renvoie des chaînes.
+- **Omettre de tester la négociation.** L'erreur la plus fréquente en production, pourtant la plus simple à vérifier.
+
+## Pour aller plus loin
+
+- [Tester votre contenu : audit CLI, API programmatique et assertions UI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/testing.md)
+- [Plugin ESLint : détecter les chaînes en dur et le contenu inutilisé](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/eslint.md)
+- [Formateurs et utilitaires de locale, dont `getHTMLTextDir`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/formatters.md)
+- [Rapports de benchmark à travers différents frameworks](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/benchmark/index.md)
+- [Adaptateur de compatibilité react-i18next](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/react-i18next.md)
+- [Comment détecter les traductions manquantes](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/detecting_missing_translations.md)
+- [Format de message ICU : pluriels, select et formats squelettes](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/icu_message_format.md)

package/blog/fr/intlayer_with_i18next.md

@@ -78,15 +78,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > l'indicateur `--interactive` est facultatif. Utilisez `intlayer-cli init` si vous êtes un agent IA.

package/blog/fr/intlayer_with_next-i18next.md

@@ -67,15 +67,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > l'indicateur `--interactive` est facultatif. Utilisez `intlayer-cli init` si vous êtes un agent IA.

package/blog/fr/intlayer_with_next-intl.md

@@ -68,15 +68,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > l'indicateur `--interactive` est facultatif. Utilisez `intlayer-cli init` si vous êtes un agent IA.

package/blog/fr/intlayer_with_react-i18next.md

@@ -68,15 +68,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > l'indicateur `--interactive` est facultatif. Utilisez `intlayer-cli init` si vous êtes un agent IA.

package/blog/fr/intlayer_with_react-intl.md

@@ -66,15 +66,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > l'indicateur `--interactive` est facultatif. Utilisez `intlayer-cli init` si vous êtes un agent IA.

package/blog/fr/intlayer_with_vue-i18n.md

@@ -68,15 +68,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > l'indicateur `--interactive` est facultatif. Utilisez `intlayer-cli init` si vous êtes un agent IA.