@intlayer/docs 9.4.1 → 9.4.3

package/blog/fr/date_time_number_formatting_locales.md

@@ -0,0 +1,216 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Formater les dates et les nombres par locale avec Intl"
+description: Vous n'avez probablement pas besoin d'une bibliothèque de formatage. Comment Intl gère les dates, nombres, devises et listes par locale, le coût de mise en cache et le bug de fuseau horaire en production.
+keywords:
+  - formater date par locale
+  - Intl.DateTimeFormat
+  - Intl.NumberFormat
+  - toLocaleDateString
+  - format devise locale
+  - format temps relatif
+slugs:
+  - blog
+  - date-time-number-formatting-locales
+author: aymericzip
+---
+
+# Formater les dates et les nombres par locale avec Intl
+
+Traduire des chaînes n'est que la partie visible de l'i18n. La moitié qui génère des retours de bugs concerne le formatage : un utilisateur allemand qui voit `1,234.56` au lieu de `1.234,56`, un utilisateur japonais qui voit `08/02/2026` et le lit comme le mois d'août, ou une date qui s'affiche différemment entre le serveur et le client, cassant la page lors de l'hydratation.
+
+Rien de tout cela ne nécessite de bibliothèque externe. L'API `Intl` est disponible dans tous les runtimes modernes.
+
+## Table des matières
+
+<TOC/>
+
+## Commencez par supprimer vos helpers maison de date
+
+Presque chaque projet possède une fonction `formatDate` écrite avant même que quiconque ne songe aux locales. Elle fige un ordre arbitraire, un séparateur et le plus souvent des noms de mois en anglais.
+
+```ts
+// Le code à supprimer.
+const formatDate = (d: Date) =>
+  `${d.getMonth() + 1}/${d.getDate()}/${d.getFullYear()}`;
+```
+
+`Intl.DateTimeFormat` la remplace avantageusement et gère parfaitement chaque locale :
+
+```ts
+new Intl.DateTimeFormat("de-DE", { dateStyle: "long" }).format(date);
+// "2. August 2026"
+new Intl.DateTimeFormat("ja-JP", { dateStyle: "long" }).format(date);
+// "2026年8月2日"
+```
+
+Le même constat s'applique aux nombres. `toFixed(2)` produit `1234.56` partout, ce qui est erroné dans la majeure partie de l'Europe.
+
+## Ce que couvre `Intl`
+
+| API                       | Cas d'usage                                                 |
+| :------------------------ | :---------------------------------------------------------- |
+| `Intl.DateTimeFormat`     | Dates et heures, avec préréglages `dateStyle` / `timeStyle` |
+| `Intl.NumberFormat`       | Décimaux, devises, pourcentages, unités, notation compacte  |
+| `Intl.RelativeTimeFormat` | "il y a 3 jours", "dans 2 heures"                           |
+| `Intl.ListFormat`         | "a, b et c" contre "a, b, and c"                            |
+| `Intl.PluralRules`        | Catégorie plurielle dans laquelle se classe un nombre       |
+| `Intl.Collator`           | Tri linguistique correct des chaînes                        |
+
+`Intl.Collator` est celui que l'on oublie fréquemment. `array.sort()` sur des chaînes utilise l'ordre des points de code Unicode, ce qui place les caractères accentués après `z` et classe le `ö` suédois au mauvais endroit. Si vous triez des listes destinées aux utilisateurs, triez avec un collator.
+
+```ts
+["zebra", "édouard", "apple"].sort(new Intl.Collator("fr").compare);
+// ["apple", "édouard", "zebra"]
+```
+
+## Privilégiez les préréglages aux options manuelles
+
+`dateStyle` et `timeStyle` laissent la locale décider de l'ordre logique et des séparateurs. Spécifier individuellement `year`, `month` et `day` vous donne un contrôle rarement souhaitable, car l'ordre correct diffère selon la région et vous risquez d'écraser les données CLDR avec vos propres hypothèses.
+
+```ts
+// La locale décide de la structure.
+new Intl.DateTimeFormat(locale, { dateStyle: "medium" }).format(d);
+
+// Vous forcez la structure, et vous vous tromperez ailleurs.
+new Intl.DateTimeFormat(locale, {
+  year: "numeric",
+  month: "2-digit",
+  day: "2-digit",
+}).format(d);
+```
+
+N'utilisez des composants explicites que lorsque le design impose impérativement une largeur fixe, par exemple dans une colonne de tableau étroite.
+
+## Instancier les formateurs est coûteux
+
+C'est le détail de performance qui change tout. Construire une instance de `Intl.NumberFormat` charge des données de locale volumineuses, et cette étape coûte bien plus cher que l'appel ultérieur à `.format()`. Le faire dans une boucle de rendu sur un millier de lignes crée un goulet d'étranglement évident.
+
+```ts
+// Reconstruit le formateur à chaque ligne.
+rows.map((r) => new Intl.NumberFormat(locale).format(r.total));
+
+// Construit une seule fois, puis réutilisé.
+const nf = new Intl.NumberFormat(locale);
+rows.map((r) => nf.format(r.total));
+```
+
+`toLocaleDateString()` et `toLocaleString()` souffrent du même travers caché : chaque invocation instancie un formateur. C'est tout à fait tolérable pour une valeur isolée, mais inadapté pour une liste.
+
+Mettez-les en cache en combinant la locale et les options retenues :
+
+```ts
+const cache = new Map<string, Intl.NumberFormat>();
+
+const getNumberFormat = (
+  locale: string,
+  options: Intl.NumberFormatOptions = {}
+) => {
+  const key = `${locale}:${JSON.stringify(options)}`;
+  let formatter = cache.get(key);
+  if (!formatter) {
+    formatter = new Intl.NumberFormat(locale, options);
+    cache.set(key, formatter);
+  }
+  return formatter;
+};
+```
+
+## Le bug de fuseau horaire exclusif à la production
+
+Ce problème a déjà coûté des après-midis entiers à de nombreuses équipes. Un serveur rend une date en SSR, le navigateur tente de l'hydrater, et React déclenche une erreur d'hydration mismatch car les deux ont généré un texte différent.
+
+La cause est simple : `Intl.DateTimeFormat` se base sur le fuseau horaire ambiant de la machine lorsque vous n'en spécifiez aucun. Votre serveur de production tourne en UTC, alors que votre ordinateur portable de développement se trouve dans un autre fuseau horaire. L'anomalie est invisible en local et ne se produit qu'en production.
+
+```ts
+// Un serveur en UTC et un navigateur en UTC+9 sont en désaccord. Hydration mismatch.
+new Intl.DateTimeFormat(locale, { dateStyle: "short" }).format(d);
+
+// Tout le monde s'accorde.
+new Intl.DateTimeFormat(locale, { dateStyle: "short", timeZone: "UTC" }).format(
+  d
+);
+```
+
+Trois approches pragmatiques :
+
+- **Fixer un fuseau horaire** côté serveur et le transmettre explicitement. Déterministe et rigoureux, mais tout le monde voit l'heure UTC.
+- **Rendre côté client uniquement**, avec un placeholder stable lors de la passe serveur. Précis pour l'utilisateur, mais implique un léger saut visuel.
+- **Enregistrer le fuseau de l'utilisateur** et le transmettre des deux côtés. Le rendu idéal, mais demande plus de tuyauterie.
+
+Quelle que soit la solution retenue, spécifiez toujours `timeZone` explicitement pour toute date rendue à la fois côté serveur et côté client. Une date sans fuseau horaire explicite est une date à deux valeurs.
+
+## Une devise a besoin d'une devise, pas d'une locale
+
+La locale et la devise sont deux concepts orthogonaux. `fr-FR` ne signifie pas euro : un utilisateur français peut tout à fait consulter une facture en dollars américains.
+
+```ts
+new Intl.NumberFormat("fr-FR", { style: "currency", currency: "USD" }).format(
+  1234.5
+);
+// "1 234,50 $US"
+```
+
+La locale pilote les séparateurs, les regroupements de chiffres et l'emplacement du symbole. La devise provient de votre modèle de données. Déduire l'une de l'autre est une source d'erreurs comptables.
+
+Notez également l'utilité de `currencyDisplay`. Dans une interface où cohabitent plusieurs devises portant le symbole dollar, l'option `"code"` élimine toute ambiguïté entre dollars américains, canadiens et australiens.
+
+## Le temps relatif est plus naturel que le temps absolu
+
+Pour les événements récents, "il y a 2 heures" est bien plus lisible qu'un horodatage complet, et `Intl.RelativeTimeFormat` s'en charge nativement.
+
+```ts
+new Intl.RelativeTimeFormat("fr", { numeric: "auto" }).format(-1, "day");
+// "hier"
+```
+
+`numeric: "auto"` permet d'obtenir "hier" au lieu de "il y a 1 jour". Sans cette option, vous n'obtiendrez que la forme numérique stricte, qui sonne très mécanique.
+
+## Ce qu'Intlayer apporte en complément
+
+Intlayer englobe ces mécanismes dans des utilitaires pré-cachés afin que vous n'ayez pas à maintenir la Map de cache ci-dessus, et applique la locale active par défaut sans avoir à la transmettre à chaque appel.
+
+```ts
+import {
+  number,
+  currency,
+  date,
+  relativeTime,
+  units,
+  compact,
+  list,
+} from "intlayer";
+
+number(1234.5); // "1 234,5"
+currency(1234.5, { currency: "EUR" }); // "1 234,50 €"
+date(new Date(), "short");
+relativeTime(now, twoHoursAgo, { unit: "hour", numeric: "auto" }); // "il y a 2 heures"
+units(5, { unit: "kilometer", unitDisplay: "long" }); // "5 kilomètres"
+compact(1200); // "1,2 k"
+list(["pomme", "banane", "orange"]); // "pomme, banane et orange"
+```
+
+La fonction `date()` accepte également des préréglages (`"short"`, `"long"`, `"dateOnly"`, `"timeOnly"`, `"full"`), évitant d'avoir à manipuler un objet d'options pour les cas courants. Des équivalents React et Vue existent sous forme de hooks et de composables, résolvant la locale active directement depuis le contexte applicatif.
+
+Il s'agit essentiellement d'une couche de mise en cache et d'injection de locale par défaut au-dessus de l'API standard. Le comportement de formatage reste celui d'`Intl`. Retrouvez les signatures complètes dans la [documentation des formateurs](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/formatters.md).
+
+## Erreurs courantes
+
+- **`toLocaleDateString()` sans locale spécifiée.** Utilise la locale de la machine hôte, ce qui dépend entièrement de la configuration du conteneur sur un serveur.
+- **Formater dans une boucle sans cache.** L'instanciation du formateur absorbe l'essentiel du temps d'exécution.
+- **Oublier `timeZone` sur les dates isomorphes.** Erreur d'hydratation impossible à reproduire sur votre poste local.
+- **Déduire la devise depuis la locale.** `fr-FR` ne signifie pas automatiquement euros.
+- **`sort()` standard sur des textes affichés.** Utilisez toujours `Intl.Collator`.
+- **Coder les noms de mois ou de jours en dur.** Ils existent déjà dans le CLDR, pour chaque langue.
+- **Garder `numeric: "always"` pour le temps relatif.** Vous obtenez "il y a 1 jour" là où chaque langue possède un mot dédié pour hier.
+
+## Pour aller plus loin
+
+- [Formateurs et utilitaires de locale : `number`, `currency`, `date`, `relativeTime`, `list`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/formatters.md)
+- [Référence de configuration](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é react-intl](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/react-intl.md)
+- [Format de message ICU : pluriels, sélections et skeletons numériques](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/icu_message_format.md)
+- [Comment tester les traductions, formateurs et pluriels compris](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/i18n_testing_strategies.md)
+- [Ce que couvre réellement l'internationalisation](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/what_is_internationalization.md)

package/blog/fr/detecting_missing_translations.md

@@ -0,0 +1,202 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "Comment détecter les traductions manquantes avant vos utilisateurs"
+description: Les traductions manquantes échouent en silence. Pourquoi le fallback les dissimule, les quatre niveaux de détection efficaces et comment bloquer un build sur une clé non traduite.
+keywords:
+  - trouver traductions manquantes
+  - clés de traduction manquantes
+  - audit i18n
+  - chaînes non traduites
+  - couverture de traduction
+  - lint i18n
+slugs:
+  - blog
+  - detecting-missing-translations
+author: aymericzip
+---
+
+# Comment détecter les traductions manquantes avant vos utilisateurs
+
+Une traduction manquante ne déclenche presque jamais d'erreur explicite. Selon votre configuration, elle affiche la chaîne anglaise à un utilisateur japonais, ou imprime `checkout.summary.total` sur une page en production. Dans les deux cas, le code est livré, passe la revue sans encombre, et le problème est découvert par un client plutôt que par vous.
+
+## Table des matières
+
+<TOC/>
+
+## Cela s'applique quelle que soit votre bibliothèque
+
+Rien ici n'est spécifique à une stack particulière. Les niveaux de détection décrits ci-dessous fonctionnent de manière identique sur i18next, react-i18next, next-intl, react-intl, vue-i18n, next-translate ou Lingui, car ils résolvent tous les clés et échouent selon la même logique.
+
+L'outillage est tout aussi portable. Si vos messages sont aujourd'hui stockés dans des catalogues JSON, le [plugin Sync JSON](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/plugins/sync-json.md) connecte Intlayer à ces fichiers, vous permettant d'utiliser les commandes d'audit, de remplissage et de test sans déplacer vos contenus ni modifier un seul import :
+
+```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;
+```
+
+Si vous souhaitez également conserver votre API runtime inchangée, les [adaptateurs de compatibilité](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/compat/index.md) créent des alias pour `useTranslation`, `$t` et leurs équivalents au niveau du bundler. Quoi qu'il en soit, considérez les commandes ci-dessous comme une mise en œuvre concrète du principe, et non comme une obligation technique.
+
+## Pourquoi les manques sont invisibles
+
+Toutes les bibliothèques d'i18n résolvent une clé selon la même séquence : rechercher la locale active, se rabattre sur une locale par défaut, et si cela échoue, renvoyer la clé elle-même. C'est cette dernière étape qui pose problème. Il n'y a pas d'erreur, pas d'avertissement en production, et aucun test qui échoue, car rien dans le pipeline ne traite une clé manquante comme anormale.
+
+Le mécanisme de fallback aggrave la situation au lieu de l'arranger. Une page qui s'affiche silencieusement en anglais semble tout à fait correcte à un développeur anglophone et à tous vos tests automatisés. Le bug n'est visible que pour la personne qui ne comprend pas le résultat.
+
+La question n'est donc pas "comment gérer les traductions manquantes au runtime". Mais plutôt "comment rendre impossible le merge d'une traduction manquante".
+
+## Les quatre niveaux où vous pouvez les intercepter
+
+Chaque niveau intercepte des anomalies que les autres ne voient pas. Vous en voudrez plus d'un.
+
+| Niveau         | Intercepte                                    | Ignore                                          |
+| :------------- | :-------------------------------------------- | :---------------------------------------------- |
+| Types          | Clés qui n'existent pas du tout               | Clé existante mais non traduite en `ja`         |
+| Linter         | Chaînes brutes jamais envoyées en traduction  | Clés manquantes dans un catalogue               |
+| Audit          | Couverture de locales sur chaque clé déclarée | Textes qui n'ont jamais été rendus traduisibles |
+| Tests de rendu | Clés qui se résolvent mais s'affichent mal    | Tout ce qui n'est pas couvert par un test       |
+
+La faille la plus fréquente réside dans la troisième ligne : les équipes savent que leurs clés sont valides, mais rien ne vérifie que les dix-huit locales disposent réellement d'une valeur.
+
+## Niveau 1 : faire de la clé un type, pas une simple chaîne
+
+`t("checkout.summry.total")` est une faute de frappe qui compile parfaitement. Si vos clés sont de simples chaînes, chaque renommage devient un risque en production et chaque suppression laisse une clé orpheline.
+
+Les clés typées transforment cela en erreur de build. `react-i18next` le propose via le declaration merging, `next-intl` l'infère à partir de vos structures de messages, Lingui génère des identifiants à partir du texte source, et Intlayer génère des types stricts à partir des déclarations de contenu. Tous fonctionnent ; ce qui varie est l'effort de configuration nécessaire.
+
+Ce niveau est nécessaire mais insuffisant. Les types décrivent la forme de votre catalogue par défaut. Ils ne garantissent en rien que le coréen contienne une valeur pour cette clé.
+
+## Niveau 2 : linter les chaînes qui ne sont jamais devenues des clés
+
+La traduction introuvable est souvent celle qui n'a jamais été externalisée. Un libellé codé en dur dans un composant échappe à tout audit de catalogue, car pour l'outillage, il n'existe pas.
+
+Le plugin ESLint d'Intlayer résout cela avec `no-raw-text`, complété par `no-unused-content` pour le problème inverse : le contenu déclaré mais qui n'est plus appelé nulle part.
+
+```js fileName="eslint.config.mjs"
+import intlayer from "@intlayer/eslint-plugin";
+
+export default [
+  intlayer.configs.recommended,
+  {
+    rules: {
+      "@intlayer/no-raw-text": "error",
+      "@intlayer/no-unused-content": "warn",
+    },
+  },
+];
+```
+
+`no-unused-content` empêche les catalogues de grossir indéfiniment. Les clés mortes ne cassent pas le code, mais elles gonflent inutilement la facture de vos prestataires de traduction. Retrouvez la liste complète des règles dans la [documentation du plugin ESLint](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/eslint.md).
+
+## Niveau 3 : auditer la couverture des locales
+
+C'est ce niveau qui répond à la question fondamentale. Intlayer le fournit sous la forme d'une commande CLI :
+
+```bash packageManager="npm"
+npx intlayer content test
+```
+
+Elle inspecte vos locales configurées et vos dictionnaires déclarés, puis indique quelles clés manquent dans quelles locales, et dans quel fichier.
+
+Un détail important avant d'intégrer cette commande n'importe où : **la CLI affiche un rapport mais ne renvoie pas de code d'erreur différent de zéro.** Si vous l'ajoutez dans un pipeline en attendant qu'elle bloque le build, vous obtiendrez un build vert avec un pavé de texte que personne ne lira. Pour bloquer le build, utilisez l'API programmatique décrite ci-dessous.
+
+## Niveau 4 : tester par assertion dans la suite de tests
+
+`listMissingTranslations()` vous donne le même audit sous forme de données, ce qui correspond exactement à ce dont vous avez besoin pour un gate de build.
+
+```ts fileName="i18n.test.ts"
+/* @vitest-environment node */
+import { listMissingTranslations } from "intlayer/cli";
+import { describe, expect, it } from "vitest";
+
+describe("traductions", () => {
+  it("ne présente aucune locale requise manquante", async () => {
+    const result = await listMissingTranslations();
+
+    if (result.missingRequiredLocales.length > 0) {
+      console.log(result.missingTranslations);
+    }
+
+    expect(result.missingRequiredLocales).toHaveLength(0);
+  });
+});
+```
+
+Trois champs sont renvoyés, et la distinction est fondamentale :
+
+- `missingTranslations` : par clé, quelles locales manquent et dans quel fichier. C'est ce que vous affichez en console si le test échoue.
+- `missingLocales` : l'union de toutes les locales manquantes à travers l'ensemble des clés.
+- `missingRequiredLocales` : restreint aux `requiredLocales` de votre configuration, ou à toutes les locales si vous n'avez pas défini cette option.
+
+## Les locales obligatoires sont le levier indispensable
+
+Livrer dix-huit langues ne signifie pas qu'elles doivent toutes être complètes à 100% pour pouvoir déployer. La plupart des équipes distinguent un groupe qui bloque la release et un groupe fourni au fil de l'eau.
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [
+      Locales.ENGLISH,
+      Locales.FRENCH,
+      Locales.JAPANESE,
+      Locales.POLISH,
+    ],
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+    defaultLocale: Locales.ENGLISH,
+  },
+};
+
+export default config;
+```
+
+Sans `requiredLocales`, chaque locale déclarée est requise par défaut et votre build reste rouge jusqu'à ce que la dernière langue soit livrée. C'est la raison pour laquelle les équipes finissent par désactiver la vérification, ce qui est pire que de ne pas en avoir.
+
+## Dépister les manques déjà en production
+
+Les niveaux ci-dessus empêchent les nouveaux manques d'apparaître. Pour une application déjà en ligne, deux approches sont efficaces.
+
+**La pseudolocalisation.** Utilisez une fausse locale où chaque chaîne est modifiée, par exemple `[!!! Ĉĥéçķöũţ !!!]`. Tout ce qui s'affiche en anglais standard est écrit en dur. Elle permet de trouver en dix minutes ce qu'un audit de catalogue est structurellement incapable de voir, car elle teste le rendu réel et non les fichiers de données.
+
+**Crawler votre propre site.** Si vous utilisez des URL localisées, téléchargez un échantillon de pages par locale et cherchez dans le code HTML les chaînes de votre langue par défaut. Une page dans `/ja/` contenant "Add to cart" est soit une traduction manquante, soit un fallback inattendu.
+
+```bash
+curl -s https://example.com/ja/checkout | grep -c "Add to cart"
+```
+
+## Remplir les manques
+
+Une fois les manques identifiés, `intlayer fill` complète les entrées vides, et l'option `autoFill` peut générer les fichiers par locale au moment où le contenu est déclaré. Voir [autoFill](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/autoFill.md).
+
+Soyons lucides : les traductions complétées par machine transforment un manque _visible_ en un manque _invisible_. La clé a désormais une valeur, l'audit passe au vert, et personne n'a relu le résultat. Servez-vous-en pour débloquer une livraison, puis confiez la relecture à un humain pour tout ce qu'un utilisateur lit avant de prendre une décision. C'est un échafaudage, pas une fin en soi.
+
+## Erreurs courantes
+
+- **Considérer le fallback comme une fonctionnalité de sécurité.** C'est une stratégie de rendu de secours, pas un filet protecteur. Une page en anglais silencieuse est un bug que personne ne signale.
+- **Compter sur le rapport CLI pour bloquer la CI.** `intlayer content test` renvoie toujours un code zéro. Utilisez une assertion dans un test.
+- **Rendre toutes les locales obligatoires.** Le contrôle saute à la première livraison bloquée par une langue à moitié traduite.
+- **Auditer les catalogues mais jamais la page rendue.** Les chaînes en dur sont par définition invisibles dans un catalogue.
+- **Ne tester que la locale par défaut.** C'est la seule langue qui ne risque jamais d'être manquante.
+- **Laisser l'auto-complétion machine clore le processus.** Audit au vert mais textes jamais relus.
+
+## Pour aller plus loin
+
+- [Tester son contenu : audit CLI, API programmatique et assertions UI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/testing.md)
+- [Règles du plugin ESLint, dont `no-raw-text` et `no-unused-content`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/fr/eslint.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`, `defaultLocale`](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)
+- [Ce que couvre réellement l'internationalisation](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/what_is_internationalization.md)
+- [i18n par composant vs i18n centralisée](https://github.com/aymericzip/intlayer/blob/main/docs/blog/fr/per-component_vs_centralized_i18n.md)