@intlayer/docs 5.7.8 → 5.8.0

package/blog/fr/react-i18next_vs_react-intl_vs_intlayer.md

@@ -1,8 +1,8 @@
 ---
 createdAt: 2025-01-02
 updatedAt: 2025-06-29
-title: react-i18n vs react-intl vs Intlayer
-description: Intègre react-i18next avec next-intl et Intlayer pour l'internationalisation (i18n) d'une application React
+title: react-i18next vs react-intl vs Intlayer
+description: Intégrer react-i18next avec next-intl et Intlayer pour l'internationalisation (i18n) d'une application React
 keywords:
   - next-intl
   - react-i18next
@@ -17,178 +17,137 @@ slugs:
   - react-i18next-vs-react-intl-vs-intlayer
 ---
 
-# React-Intl VS React-i18next VS Intlayer | Internationalisation (i18n) avec React
+# react-Intl VS react-i18next VS intlayer | Internationalisation React (i18n)
 
-Voici une comparaison concise de trois bibliothèques i18n (internationalisation) populaires pour React : **React-Intl**, **React-i18next** et **Intlayer**. Chaque bibliothèque offre des fonctionnalités et des workflows uniques pour intégrer le support multilingue dans votre application React. Après avoir lu ceci, vous devriez être en mesure de décider quelle solution correspond le mieux à vos besoins.
+Ce guide compare trois options i18n établies pour **React** : **react-intl** (FormatJS), **react-i18next** (i18next), et **Intlayer**.
+Nous nous concentrons sur les applications **React pures** (par exemple, Vite, CRA, SPA). Si vous utilisez Next.js, consultez notre comparaison dédiée à Next.js.
 
----
-
-## 1. Introduction
-
-L'internationalisation (i18n) dans les applications React peut être réalisée de plusieurs manières. Les trois bibliothèques présentées ici ont différentes philosophies de conception, ensembles de fonctionnalités et support communautaire :
+Nous évaluons :
 
-1. **React-Intl**
-2. **React-i18next**
-3. **Intlayer**
+- Architecture et organisation du contenu
+- TypeScript et sécurité
+- Gestion des traductions manquantes
+- Contenu riche et capacités de formatage
+- Performance et comportement de chargement
+- Expérience développeur (DX), outils et maintenance
+- SEO/routage (dépendant du framework)
 
-Vous trouverez ci-dessous un aperçu de chaque solution, suivi d'une comparaison des fonctionnalités, des avantages et inconvénients, et des cas d'utilisation exemplaires.
+> **En résumé** : Les trois solutions peuvent localiser une application React. Si vous souhaitez un **contenu scoped par composant**, des **types TypeScript stricts**, des **vérifications des clés manquantes à la compilation**, des **dictionnaires optimisés par tree-shaking**, ainsi qu’un outil éditorial intégré (Éditeur Visuel/CMS + traduction IA optionnelle), **Intlayer** est le choix le plus complet pour des bases de code React modulaires.
 
 ---
 
-## 2. React-Intl
-
-### Vue d'ensemble
-
-[**React-Intl**](https://formatjs.io/docs/react-intl/) fait partie de la suite [FormatJS](https://formatjs.io/). Elle fournit un ensemble puissant d'**APIs et de composants** pour gérer le formatage des messages, la pluralisation, le formatage de la date/heure et des nombres. React-Intl est largement utilisé dans les applications d'entreprise, principalement parce qu'il fait partie d'un écosystème qui standardise la syntaxe des messages et leur formatage.
-
-### Fonctionnalités clés
-
-- **Syntaxe de message ICU** : Offre une syntaxe complète pour l'interpolation des messages, la pluralisation, et plus encore.
-- **Formatage localisé** : Utilitaires intégrés pour formater les dates, les heures, les nombres et les temps relatifs en fonction de la locale.
-- **Composants déclaratifs** : Expose `<FormattedMessage>`, `<FormattedNumber>`, `<FormattedDate>`, etc., pour une utilisation transparente dans JSX.
-- **Écosystème riche** : S'intègre bien avec les outils de FormatJS (par exemple, [babel-plugin-react-intl](https://formatjs.io/docs/tooling/babel-plugin/)) pour extraire, gérer et compiler les messages.
-
-### Flux de travail typique
-
-1. **Définir les catalogues de messages** (généralement des fichiers JSON par locale).
-2. **Enveloppez votre application** dans `<IntlProvider locale="fr" messages={messages}>`.
-3. **Utilisez** `<FormattedMessage id="myMessage" defaultMessage="Bonjour le monde" />` ou le hook `useIntl()` pour accéder aux chaînes de traduction.
-
-### Avantages
-
-- Bien établi et utilisé dans de nombreux environnements de production.
-- Formatage de message avancé, y compris la pluralisation, le genre, les fuseaux horaires, et plus encore.
-- Support d'outils fort pour l'extraction et la compilation des messages.
-
-### Inconvénients
+## Positionnement général
 
-- Nécessite une familiarité avec le **format de message ICU**, qui peut être verbeux.
-- Pas aussi simple de gérer des traductions dynamiques ou complexes qui vont au-delà des simples chaînes.
+- **react-intl** - Formatage priorisant ICU, conforme aux standards (dates/nombres/pluriels) avec une API mature. Les catalogues sont généralement centralisés ; la sécurité des clés et la validation à la compilation dépendent en grande partie de vous.
+- **react-i18next** - Extrêmement populaire et flexible ; namespaces, détecteurs, et de nombreux plugins (ICU, backends). Puissant, mais la configuration peut devenir complexe à mesure que les projets grandissent.
+- **Intlayer** - Modèle de contenu centré sur les composants pour React, **typage TS strict**, **vérifications à la compilation**, **tree-shaking**, plus **éditeur visuel/CMS** et **traductions assistées par IA**. Fonctionne avec React Router, Vite, CRA, etc.
 
 ---
 
-## 3. React-i18next
+## Matrice des fonctionnalités (focus React)
+
+| Fonctionnalité                                              | `react-intlayer` (Intlayer)                                                                                                                                         | `react-i18next` (i18next)                                                                                                                       | `react-intl` (FormatJS)                                                                                                    |
+| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
+| **Traductions Près des Composants**                         | ✅ Oui, contenu collé avec chaque composant                                                                                                                         | ❌ Non                                                                                                                                          | ❌ Non                                                                                                                     |
+| **Intégration TypeScript**                                  | ✅ Avancée, types stricts auto-générés                                                                                                                              | ⚠️ Basique ; configuration supplémentaire pour la sécurité                                                                                      | ✅ Bonne, mais moins stricte                                                                                               |
+| **Détection des Traductions Manquantes**                    | ✅ Mise en évidence des erreurs TypeScript et erreur/avertissement à la compilation                                                                                 | ⚠️ Principalement des chaînes de secours à l'exécution                                                                                          | ⚠️ Chaînes de secours                                                                                                      |
+| **Contenu Riche (JSX/Markdown/composants)**                 | ✅ Support direct                                                                                                                                                   | ⚠️ Limité / interpolation uniquement                                                                                                            | ⚠️ Syntaxe ICU, pas de vrai JSX                                                                                            |
+| **Traduction alimentée par IA**                             | ✅ Oui, prend en charge plusieurs fournisseurs d'IA. Utilisable avec vos propres clés API. Prend en compte le contexte de votre application et la portée du contenu | ❌ Non                                                                                                                                          | ❌ Non                                                                                                                     |
+| **Éditeur Visuel**                                          | ✅ Oui, éditeur visuel local + CMS optionnel ; peut externaliser le contenu de la base de code ; intégrable                                                         | ❌ Non / disponible via des plateformes de localisation externes                                                                                | ❌ Non / disponible via des plateformes de localisation externes                                                           |
+| **Routage localisé**                                        | ✅ Oui, prend en charge les chemins localisés nativement (fonctionne avec Next.js & Vite)                                                                           | ⚠️ Pas intégré, nécessite des plugins (ex. `next-i18next`) ou une configuration personnalisée du routeur                                        | ❌ Non, uniquement le formatage des messages, le routage doit être manuel                                                  |
+| **Génération dynamique de routes**                          | ✅ Oui                                                                                                                                                              | ⚠️ Plugin/écosystème ou configuration manuelle                                                                                                  | ❌ Non fourni                                                                                                              |
+| **Pluriel**                                                 | ✅ Modèles basés sur des énumérations                                                                                                                               | ✅ Configurable (plugins comme i18next-icu)                                                                                                     | ✅ (ICU)                                                                                                                   |
+| **Formatage (dates, nombres, devises)**                     | ✅ Formateurs optimisés (Intl en interne)                                                                                                                           | ⚠️ Via des plugins ou usage personnalisé d’Intl                                                                                                 | ✅ Formateurs ICU                                                                                                          |
+| **Format de contenu**                                       | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml en cours de développement)                                                                                              | ⚠️ .json                                                                                                                                        | ✅ .json, .js                                                                                                              |
+| **Support ICU**                                             | ⚠️ En cours de développement                                                                                                                                        | ⚠️ Via plugin (i18next-icu)                                                                                                                     | ✅ Oui                                                                                                                     |
+| **Aides SEO (hreflang, sitemap)**                           | ✅ Outils intégrés : aides pour sitemap, robots.txt, métadonnées                                                                                                    | ⚠️ Plugins communautaires / manuel                                                                                                              | ❌ Pas dans le cœur                                                                                                        |
+| **Écosystème / Communauté**                                 | ⚠️ Plus petit mais en croissance rapide et réactif                                                                                                                  | ✅ Le plus grand et mature                                                                                                                      | ✅ Important                                                                                                               |
+| **Rendu côté serveur & Composants Serveur**                 | ✅ Oui, optimisé pour SSR / Composants Serveur React                                                                                                                | ⚠️ Pris en charge au niveau de la page mais nécessite de passer les fonctions t dans l'arbre des composants pour les composants serveur enfants | ❌ Non pris en charge, nécessite de passer les fonctions t dans l'arbre des composants pour les composants serveur enfants |
+| **Tree-shaking (chargement uniquement du contenu utilisé)** | ✅ Oui, par composant au moment de la compilation via les plugins Babel/SWC                                                                                         | ⚠️ Charge généralement tout (peut être amélioré avec des namespaces / découpage du code)                                                        | ⚠️ Charge généralement tout                                                                                                |
+| **Chargement paresseux**                                    | ✅ Oui, par locale / par dictionnaire                                                                                                                               | ✅ Oui (par exemple, backends/namespaces à la demande)                                                                                          | ✅ Oui (bundles de locale séparés)                                                                                         |
+| **Purge du contenu inutilisé**                              | ✅ Oui, par dictionnaire au moment de la compilation                                                                                                                | ❌ Non, uniquement via une segmentation manuelle des namespaces                                                                                 | ❌ Non, tous les messages déclarés sont inclus dans le bundle                                                              |
+| **Gestion des grands projets**                              | ✅ Encourage la modularité, adapté aux design-systems                                                                                                               | ⚠️ Nécessite une bonne discipline des fichiers                                                                                                  | ⚠️ Les catalogues centraux peuvent devenir volumineux                                                                      |
 
-### Vue d'ensemble
-
-[**React-i18next**](https://react.i18next.com/) est une extension de React de [i18next](https://www.i18next.com/), l'un des frameworks JavaScript i18n les plus populaires. Il offre des **fonctionnalités étendues** pour les traductions en temps réel, le chargement paresseux, et la détection de langue, ce qui le rend extrêmement flexible pour une grande variété de cas d'utilisation.
-
-### Fonctionnalités clés
-
-- **Structure de traduction flexible** : Non lié à un format unique comme l'ICU. Vous pouvez stocker des traductions en JSON, utiliser l'interpolation, la pluralisation, etc.
-- **Changement de langue dynamique** : Plugins de détection de langue intégrés et mises à jour en temps réel.
-- **Traductions imbriquées et structurées** : Vous pouvez imbriquer facilement les traductions au sein du JSON.
-- **Écosystème de plugins étendu** : Pour la détection (navigateur, chemin, sous-domaine, etc.), le chargement des ressources, la mise en cache, et plus encore.
-
-### Flux de travail typique
-
-1. **Installez `i18next` & `react-i18next`.**
-2. **Configurez i18n** pour charger les traductions (JSON) et mettre en place la détection de langue ou les fallback.
-3. **Enveloppez votre application** dans `I18nextProvider`.
-4. **Utilisez le hook `useTranslation()`** ou le composant `<Trans>` pour afficher les traductions.
+---
 
-### Avantages
+## Comparaison approfondie
 
-- Très **flexible** et riche en fonctionnalités.
-- Communauté très active et grand écosystème de plugins.
-- Facilité de **chargement dynamique** des traductions (par exemple, depuis un serveur, à la demande).
+### 1) Architecture et évolutivité
 
-### Inconvénients
+- **react-intl / react-i18next** : La plupart des configurations maintiennent des **dossiers de locale centralisés** par langue, parfois divisés par **espaces de noms** (namespaces) (i18next). Cela fonctionne bien au début mais devient une surface partagée à mesure que les applications grandissent.
+- **Intlayer** : Favorise les **dictionnaires par composant (ou par fonctionnalité)** **co-localisés** avec l’interface utilisateur qu’ils servent. Cela maintient une propriété claire, facilite la duplication/migration des composants, et réduit les changements de clés entre équipes. Le contenu inutilisé est plus facile à identifier et à supprimer.
 
-- **La configuration peut être verbeuse**, surtout si vous avez des besoins plus avancés.
-- Si vous préférez des traductions fortement typées, vous aurez peut-être besoin de configurations TypeScript supplémentaires.
+**Pourquoi c’est important :** Le contenu modulaire reflète une interface modulaire. Les grandes bases de code React restent plus propres lorsque les traductions vivent avec les composants auxquels elles appartiennent.
 
 ---
 
-## 4. Intlayer
+### 2) TypeScript & sécurité
 
-### Vue d'ensemble
+- **react-intl** : Typages solides, mais **pas de typage automatique des clés** ; vous devez appliquer vous-même les bonnes pratiques de sécurité.
+- **react-i18next** : Typages forts pour les hooks ; un **typage strict des clés** nécessite généralement une configuration supplémentaire ou des générateurs.
+- **Intlayer** : **Génère automatiquement des types stricts** à partir de votre contenu. L’autocomplétion de l’IDE et les **erreurs à la compilation** détectent les fautes de frappe et les clés manquantes avant l’exécution.
 
-[**Intlayer**](https://github.com/aymericzip/intlayer) est une bibliothèque i18n open-source plus récente axée sur les **déclarations de contenu au niveau des composants**, la sécurité des types et le **routage dynamique**. Elle est conçue pour les workflows modernes de React, prenant en charge à la fois **Create React App** et les configurations **Vite**. Elle inclut également des fonctionnalités avancées telles que le **routage basé sur la locale** et des **types TypeScript auto-générés** pour les traductions.
+**Pourquoi c’est important :** Déplacer les erreurs **en amont** (vers la compilation/CI) réduit les problèmes en production et accélère les boucles de retour pour les développeurs.
 
-### Fonctionnalités clés
+---
 
-- **Fichiers de contenu déclaratifs** : Chaque composant ou module peut déclarer ses traductions dans des fichiers dédiés `.content.tsx` ou `.content.json`, gardant le contenu proche de son utilisation.
-- **Routage & middleware intégrés** : Modules optionnels pour le routage localisé (par exemple, `/fr/about`, `/en/about`) et middleware serveur pour détecter la locale de l'utilisateur.
-- **Types TypeScript auto-générés** : Assure la sécurité des types avec des fonctionnalités telles que l'autocomplétion et la détection d'erreurs à la compilation.
-- **Traductions dynamiques et riches** : Peut inclure JSX/TSX dans les traductions pour des cas d'utilisation plus complexes (par exemple, liens, texte en gras, icônes dans les traductions).
+### 3) Gestion des traductions manquantes
 
-### Flux de travail typique
+- **react-intl / react-i18next** : Par défaut, recours aux **solutions de repli à l’exécution** (répétition de la clé ou locale par défaut). Vous pouvez ajouter du linting/plugins, mais ce n’est pas garanti à la compilation.
+- **Intlayer** : **Détection à la compilation** avec avertissements ou erreurs lorsque des locales/clés requises sont manquantes.
 
-1. **Installez `intlayer` et `react-intlayer`.**
-2. **Créez `intlayer.config.ts`** pour définir les locales disponibles et la locale par défaut.
-3. **Utilisez l'CLI Intlayer** ou le plugin pour **transpiler** les déclarations de contenu.
-4. **Enveloppez votre application** dans `<IntlayerProvider>` et récupérez le contenu avec `useIntlayer("keyName")`.
+**Pourquoi c’est important :** Un CI qui échoue sur les chaînes manquantes empêche la fuite d’« anglais mystère » dans les interfaces non anglophones.
 
-### Avantages
+---
 
-- **Compatible TypeScript** avec génération de types intégrée et vérification d'erreurs.
-- Contenu **riche** possible (par exemple, passer des nœuds React comme traductions).
-- **Routage localisé** prêt à l'emploi.
-- Intégré aux outils de build populaires (CRA, Vite) pour une configuration facile.
+### 4) Contenu riche & formatage
 
-### Inconvénients
+- **react-intl** : Excellente prise en charge de **ICU** pour les pluriels, sélections, dates/nombres et composition de messages. JSX peut être utilisé, mais le modèle mental reste centré sur le message.
+- **react-i18next** : Interpolation flexible et **`<Trans>`** pour intégrer des éléments/composants ; ICU disponible via un plugin.
+- **Intlayer** : Les fichiers de contenu peuvent inclure des **nœuds riches** (JSX/Markdown/composants) et des **métadonnées**. Le formatage utilise Intl en interne ; les modèles de pluriels sont ergonomiques.
 
-- Encore **relativement nouveau** par rapport à React-Intl ou React-i18next.
-- Accent plus fort sur une approche de "déclaration de contenu au niveau des composants" - peut être un changement par rapport aux catalogues .json typiques.
-- Écosystème et communauté plus petits par rapport aux bibliothèques plus établies.
+**Pourquoi c’est important :** Les textes UI complexes (liens, parties en gras, composants en ligne) sont plus faciles à gérer lorsque la bibliothèque intègre proprement les nœuds React.
 
 ---
 
-## 5. Comparaison des fonctionnalités
+### 5) Performance et comportement de chargement
+
+- **react-intl / react-i18next** : Vous gérez généralement la **division des catalogues** et le **chargement paresseux** manuellement (espaces de noms/importations dynamiques). Efficace mais demande de la rigueur.
+- **Intlayer** : Effectue un **tree-shaking** des dictionnaires inutilisés et prend en charge le **chargement paresseux par dictionnaire/par langue** prêt à l'emploi.
 
-| **Fonctionnalité**              | **React-Intl**                                                                       | **React-i18next**                                                                                                                   | **Intlayer**                                                                                                                                          |
-| ------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Cas d'utilisation principal** | Traductions basées sur des chaînes, formatage de date/nombre, syntaxe de message ICU | i18n complet avec changement dynamique facile, imbrication, écosystème de plugins                                                   | Traductions type-safe avec un accent sur le contenu déclaratif, routage localisé & middleware serveur optionnel                                       |
-| **Approche**                    | Utilisez `<IntlProvider>` et les composants de message FormatJS                      | Utilisez `I18nextProvider` et le hook `useTranslation()`                                                                            | Utilisez `<IntlayerProvider>` et le hook `useIntlayer()` avec des déclarations de contenu                                                             |
-| **Format de localisation**      | Chaînes basées sur ICU (catalogues JSON ou JavaScript)                               | Fichiers de ressources JSON (ou chargeurs personnalisés). Le format ICU est optionnel via i18next plugin                            | Déclarations `.content.[ts/js/tsx]` ou JSON ; peut contenir des chaînes ou des composants React                                                       |
-| **Routage**                     | Géré à l'extérieur (pas de routage localisé intégré)                                 | Géré à l'extérieur avec des plugins i18next (détection de chemin, sous-domaine, etc.)                                               | Support de routage localisé intégré (par exemple, `/fr/about`, `/en/about`), plus un middleware serveur optionnel (pour SSR/Vite)                     |
-| **Support TypeScript**          | Bon (typages pour les packages officiels)                                            | Bon mais configuration supplémentaire pour les traductions typées si vous voulez un contrôle strict                                 | Excellent (définitions de type auto-générées pour les clés et traductions de contenu)                                                                 |
-| **Pluralisation & Formatage**   | Avancé : Formatage intégré de date/heure/nombre, support de plural/gendre            | Pluralisation configurable. Le formatage de date/heure est généralement réalisé via des bibliothèques externes ou le plugin i18next | Peut s'appuyer sur JavaScript Intl standard ou intégrer la logique dans le contenu. Ne pas aussi spécialisé que FormatJS, mais gère les cas typiques. |
-| **Communauté & Écosystème**     | Grand, partie de l'écosystème FormatJS                                               | Très grand, très actif, beaucoup de plugins (détection, mise en cache, frameworks)                                                  | Plus petit mais en croissance ; approche moderne et open-source                                                                                       |
-| **Courbe d'apprentissage**      | Modérée (apprentissage de la syntaxe de message ICU, conventions FormatJS)           | Faible à modérée (utilisation simple, mais la configuration avancée peut devenir verbeuse)                                          | Modérée (concept de déclarations de contenu et étapes de construction spécialisées)                                                                   |
+**Pourquoi c'est important :** Des bundles plus petits et moins de chaînes inutilisées améliorent les performances au démarrage et lors de la navigation.
 
 ---
 
-## 6. Quand choisir chacun
+### 6) DX, outils & maintenance
 
-1. **React-Intl**
+- **react-intl / react-i18next** : Large écosystème communautaire ; pour les flux éditoriaux, vous adoptez généralement des plateformes de localisation externes.
+- **Intlayer** : Propose un **éditeur visuel gratuit** et un **CMS optionnel** (conservez le contenu dans Git ou externalisez-le). Offre également une **extension VSCode** pour la rédaction de contenu et une **traduction assistée par IA** utilisant vos propres clés de fournisseur.
 
-   - Vous avez besoin de **formatage puissant** pour les dates/heures/nombres et d'une **syntaxe de message ICU** solide.
-   - Vous préférez une approche plus **basée sur les standards** pour les traductions.
-   - Vous n'avez pas besoin de routage localisé ou de clés de traduction fortement typées.
+**Pourquoi c’est important :** Les outils intégrés raccourcissent la boucle entre les développeurs et les auteurs de contenu - moins de code de liaison, moins de dépendances externes.
 
-2. **React-i18next**
+---
 
-   - Vous avez besoin d'une solution **flexible, établie** avec un chargement de traduction **dynamique** et **à la demande**.
-   - Vous souhaitez une détection de langage **basée sur des plugins** (par exemple, à partir de l'URL, des cookies, du stockage local) ou un cache avancé.
-   - Vous avez besoin du plus grand écosystème, avec de nombreuses intégrations existantes pour divers frameworks (Next.js, React Native, etc.).
+## Quand choisir lequel ?
 
-3. **Intlayer**
-   - Vous souhaitez une forte intégration TypeScript avec des _types auto-générés_, garantissant que vous ne manquiez que rarement une clé de traduction.
-   - Vous préférez un contenu **déclaratif** proche du composant, pouvant inclure des nœuds React ou une logique avancée dans les traductions.
-   - Vous exigez un **routage localisé intégré** ou vous souhaitez l'incorporer facilement dans votre configuration SSR ou Vite.
-   - Vous souhaitez une approche moderne ou voulez simplement une seule bibliothèque qui couvre à la fois la **gestion de contenu** (i18n) et le **routage** de manière sécurisée en termes de types.
+- **Choisissez react-intl** si vous souhaitez un formatage de messages **priorisant ICU** avec une API simple et conforme aux standards, et que votre équipe est à l’aise pour maintenir manuellement les catalogues et les vérifications de sécurité.
+- **Choisissez react-i18next** si vous avez besoin de **l’écosystème étendu d’i18next** (détecteurs, backends, plugin ICU, intégrations) et acceptez plus de configuration pour gagner en flexibilité.
+- **Choisissez Intlayer** si vous valorisez le **contenu scoped par composant**, le **TypeScript strict**, les **garanties à la compilation**, le **tree-shaking**, et les outils éditoriaux **tout-en-un** - particulièrement pour les applications React **grandes et modulaires**.
 
 ---
 
-## 7. Conclusion
-
-Chaque bibliothèque offre une solution robuste pour internationaliser une application React :
-
-- **React-Intl** excelle dans le formatage des messages et est un choix populaire pour les solutions d'entreprise axées sur la syntaxe des messages ICU.
-- **React-i18next** fournit un environnement hautement flexible et piloté par des plugins pour des besoins i18n avancés ou dynamiques.
-- **Intlayer** offre une approche **moderne et fortement typée** qui fusionne les déclarations de contenu, le routage localisé avancé et l'intégration pilotée par des plugins (CRA, Vite).
+## Notes pratiques de migration (react-intl / react-i18next → Intlayer)
 
-Votre choix dépend largement des exigences du projet, de l'expérience souhaitée des développeurs (DX) et de l'importance que vous accordez à des traductions typées ou à un routage avancé. Si vous valorisez un routage localisé intégré et l'intégration TypeScript, **Intlayer** pourrait être le plus attrayant. Si vous souhaitez une solution éprouvée, riche en écosystème, **React-i18next** est un excellent choix. Pour des besoins de formatage basés sur ICU simples, **React-Intl** est une option fiable.
+- **Migrez de manière incrémentale** : Commencez par une fonctionnalité ou une route ; conservez les catalogues hérités en parallèle pendant la transition.
+- **Adoptez des dictionnaires par composant** : Placez le contenu au même endroit que les composants pour réduire le couplage.
+- **Activez les vérifications strictes** : Laissez les erreurs à la compilation révéler tôt les clés/locales manquantes dans l’intégration continue.
+- **Mesurez les bundles** : Attendez-vous à des réductions à mesure que les chaînes inutilisées sont éliminées.
 
 ---
 
-### Lecture supplémentaire
+## Conclusion
 
-- [Documentation de React-Intl](https://formatjs.io/docs/react-intl/)
-- [Documentation de React-i18next](https://react.i18next.com/)
-- [Guide de démarrage Intlayer + CRA](/#) (de votre doc)
-- [Guide de démarrage Intlayer + Vite & React](/#) (de votre doc)
+Les trois bibliothèques permettent de localiser React efficacement. Ce qui fait la différence, c’est la quantité d’**infrastructure** que vous devez construire pour atteindre une configuration **sûre et évolutive** :
 
-N'hésitez pas à combiner et assortir des approches pour répondre à vos exigences, il n'y a pas de solution unique, et chaque bibliothèque continue d'évoluer pour répondre à de nouveaux cas d'utilisation dans l'écosystème React.
+- Avec **Intlayer**, le **contenu modulaire**, la **typage strict en TS**, la **sécurité à la compilation**, les **bundles optimisés par tree-shaking** et les **outils éditoriaux** sont des standards - pas des corvées.
+- Si votre équipe valorise la **maintenabilité et la rapidité** dans des applications React multi-langues et pilotées par composants, Intlayer offre aujourd’hui le flux de travail développeur et contenu le **plus complet**.

package/blog/fr/vue-i18n_vs_intlayer.md

@@ -0,0 +1,269 @@
+---
+createdAt: 2024-08-11
+updatedAt: 2025-08-23
+title: vue-i18n vs Intlayer
+description: Comparaison de vue-i18n avec Intlayer pour l'internationalisation (i18n) dans les applications Vue/Nuxt
+keywords:
+  - vue-i18n
+  - Intlayer
+  - Internationalisation
+  - i18n
+  - Blog
+  - Vue
+  - Nuxt
+  - JavaScript
+slugs:
+  - blog
+  - vue-i18n-vs-intlayer
+---
+
+# vue-i18n VS Intlayer | Internationalisation Vue (i18n)
+
+Ce guide compare deux options i18n populaires pour **Vue 3** (et **Nuxt**) : **vue-i18n** et **Intlayer**.
+Nous nous concentrons sur les outils modernes de Vue (Vite, Composition API) et évaluons :
+
+1. **Architecture & organisation du contenu**
+2. **TypeScript & sécurité**
+3. **Gestion des traductions manquantes**
+4. **Stratégie de routage & URL**
+5. **Performance & comportement de chargement**
+6. **Expérience développeur (DX), outils & maintenance**
+7. **SEO & évolutivité pour les grands projets**
+
+> **en résumé** : Les deux peuvent localiser des applications Vue. Si vous souhaitez un **contenu scoped par composant**, des **types TypeScript stricts**, des **vérifications des clés manquantes à la compilation**, des **dictionnaires optimisés par tree-shaking**, ainsi que des **helpers intégrés pour le routeur/SEO** et en plus un **éditeur visuel & des traductions assistées par IA**, **Intlayer** est le choix le plus complet et moderne.
+
+---
+
+## Positionnement général
+
+- **vue-i18n** - La bibliothèque i18n de référence pour Vue. Formatage flexible des messages (style ICU), blocs SFC `<i18n>` pour les messages locaux, et un large écosystème. La sécurité et la maintenance à grande échelle dépendent principalement de vous.
+- **Intlayer** - Modèle de contenu centré sur les composants pour Vue/Vite/Nuxt avec **typage TS strict**, **vérifications à la compilation**, **tree-shaking**, **helpers pour le routeur & SEO**, **éditeur visuel/CMS** optionnel, et **traductions assistées par IA**.
+
+---
+
+## Comparaison des fonctionnalités côte à côte (axée sur Vue)
+
+| Fonctionnalité                                          | **Intlayer**                                                                                    | **vue-i18n**                                                                                           |
+| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
+| **Traductions proches des composants**                  | ✅ Oui, contenu collé par composant (ex. `MyComp.content.ts`)                                   | ✅ Oui, via les blocs SFC `<i18n>` (optionnel)                                                         |
+| **Intégration TypeScript**                              | ✅ Avancée, types **stricts** auto-générés & autocomplétion des clés                            | ✅ Bon typage ; **la sécurité stricte des clés nécessite une configuration/discipline supplémentaire** |
+| **Détection des traductions manquantes**                | ✅ Avertissements/erreurs **à la compilation** et remontée dans TS                              | ⚠️ Repli/exceptions à l'exécution                                                                      |
+| **Contenu enrichi (composants/Markdown)**               | ✅ Support direct pour les nœuds enrichis et les fichiers de contenu Markdown                   | ⚠️ Limité (composants via `<i18n-t>`, Markdown via des plugins externes)                               |
+| **Traduction assistée par IA**                          | ✅ Flux de travail intégrés utilisant vos propres clés de fournisseur IA                        | ❌ Non intégré                                                                                         |
+| **Éditeur visuel / CMS**                                | ✅ Éditeur visuel gratuit & CMS optionnel                                                       | ❌ Non intégré (utilisez des plateformes externes)                                                     |
+| **Routage localisé**                                    | ✅ Aides pour Vue Router/Nuxt afin de générer des chemins localisés, des URLs et des `hreflang` | ⚠️ Pas natif (utiliser Nuxt i18n ou une configuration personnalisée de Vue Router)                     |
+| **Génération dynamique de routes**                      | ✅ Oui                                                                                          | ❌ Non fourni (fourni par Nuxt i18n)                                                                   |
+| **Pluriels et formatage**                               | ✅ Modèles d'énumération ; formatteurs basés sur Intl                                           | ✅ Messages au format ICU ; formatteurs Intl                                                           |
+| **Formats de contenu**                                  | ✅ `.ts`, `.js`, `.json`, `.md`, `.txt` (YAML en cours de développement)                        | ✅ `.json`, `.js` (plus blocs SFC `<i18n>`)                                                            |
+| **Support ICU**                                         | ⚠️ En cours de développement                                                                    | ✅ Oui                                                                                                 |
+| **Aides SEO (sitemap, robots, métadonnées)**            | ✅ Aides intégrées (indépendantes du framework)                                                 | ❌ Pas natif (Nuxt i18n/communauté)                                                                    |
+| **SSR/SSG**                                             | ✅ Fonctionne avec Vue SSR et Nuxt ; ne bloque pas le rendu statique                            | ✅ Fonctionne avec Vue SSR/Nuxt                                                                        |
+| **Tree-shaking (livrer uniquement le contenu utilisé)** | ✅ Par composant au moment de la compilation                                                    | ⚠️ Partiel ; nécessite un découpage manuel du code/messages asynchrones                                |
+| **Chargement paresseux**                                | ✅ Par locale / par dictionnaire                                                                | ✅ Messages de locale asynchrones supportés                                                            |
+| **Purge du contenu inutilisé**                          | ✅ Oui (au moment de la compilation)                                                            | ❌ Non intégré                                                                                         |
+| **Maintenabilité des grands projets**                   | ✅ Encourage une structure modulaire, adaptée aux design systems                                | ✅ Possible, mais nécessite une discipline stricte des fichiers/namespaces                             |
+| **Écosystème / communauté**                             | ⚠️ Plus petite mais en forte croissance                                                         | ✅ Large et mature dans l'écosystème Vue                                                               |
+
+---
+
+## Comparaison approfondie
+
+### 1) Architecture et évolutivité
+
+- **vue-i18n** : Les configurations courantes utilisent des **catalogues centralisés** par locale (optionnellement divisés en fichiers/namespaces). Les blocs SFC `<i18n>` permettent des messages locaux, mais les équipes reviennent souvent à des catalogues partagés à mesure que les projets grandissent.
+- **Intlayer** : Favorise des **dictionnaires par composant** stockés à côté du composant qu'ils servent. Cela réduit les conflits entre équipes, maintient le contenu facilement accessible et limite naturellement la dérive/les clés inutilisées.
+
+**Pourquoi c'est important :** Dans les grandes applications Vue ou les design systems, le **contenu modulaire** évolue mieux que les catalogues monolithiques.
+
+---
+
+### 2) TypeScript & sécurité
+
+- **vue-i18n** : Bon support TS ; la **typage strict des clés** nécessite généralement des schémas/génériques personnalisés et des conventions rigoureuses.
+- **Intlayer** : **Génère des types stricts** à partir de votre contenu, offrant **l’autocomplétion dans l’IDE** et des **erreurs à la compilation** pour les fautes de frappe ou les clés manquantes.
+
+**Pourquoi c’est important :** Le typage fort détecte les problèmes **avant** l’exécution.
+
+---
+
+### 3) Gestion des traductions manquantes
+
+- **vue-i18n** : Avertissements/repli **à l’exécution** (par exemple, locale ou clé de repli).
+- **Intlayer** : Détection **à la compilation** avec avertissements/erreurs sur les locales et les clés.
+
+**Pourquoi c’est important :** L’application à la compilation garantit une interface utilisateur propre et cohérente en production.
+
+---
+
+### 4) Stratégie de routage et d’URL (Vue Router/Nuxt)
+
+- **Les deux** peuvent fonctionner avec des routes localisées.
+- **Intlayer** fournit des helpers pour **générer des chemins localisés**, **gérer les préfixes de locale**, et émettre des **`<link rel="alternate" hreflang>`** pour le SEO. Avec Nuxt, il complète le routage du framework.
+
+**Pourquoi c’est important :** Moins de couches personnalisées et un **SEO plus propre** à travers les locales.
+
+---
+
+### 5) Performance et comportement de chargement
+
+- **vue-i18n** : Supporte les messages de locale asynchrones ; éviter le sur-emballage dépend de vous (divisez les catalogues avec soin).
+- **Intlayer** : **Élimine le code mort** à la compilation et **charge paresseusement par dictionnaire/locale**. Le contenu inutilisé n’est pas embarqué.
+
+**Pourquoi c’est important :** Des bundles plus petits et un démarrage plus rapide pour les applications Vue multi-locales.
+
+---
+
+### 6) Expérience développeur et outils
+
+- **vue-i18n** : Documentation et communauté matures ; vous vous appuierez généralement sur des **plateformes de localisation externes** pour les flux éditoriaux.
+- **Intlayer** : Propose un **éditeur visuel gratuit**, un **CMS** optionnel (compatible Git ou externalisé), une **extension VSCode**, des utilitaires **CLI/CI**, et des **traductions assistées par IA** utilisant vos propres clés de fournisseur.
+
+**Pourquoi c’est important :** Réduction des coûts opérationnels et boucle dev–contenu plus courte.
+
+---
+
+### 7) SEO, SSR & SSG
+
+- **Les deux** fonctionnent avec Vue SSR et Nuxt.
+- **Intlayer** : Ajoute des **aides SEO** (sitemaps/métadonnées/`hreflang`) indépendantes du framework et compatibles avec les builds Vue/Nuxt.
+
+**Pourquoi c’est important :** SEO international sans câblage personnalisé.
+
+---
+
+## Pourquoi Intlayer ? (Problème & approche)
+
+La plupart des stacks i18n (y compris **vue-i18n**) partent de **catalogues centralisés** :
+
+```bash
+.
+├── locales
+│   ├── en.json
+│   ├── es.json
+│   └── fr.json
+└── src
+    └── components
+        └── MyComponent.vue
+```
+
+Ou avec des dossiers par langue :
+
+```bash
+.
+├── locales
+│   ├── en
+│   │  ├── footer.json
+│   │  └── navbar.json
+│   ├── fr
+│   │  ├── footer.json
+│   │  └── navbar.json
+│   └── es
+│      ├── footer.json
+│      └── navbar.json
+└── src
+    └── components
+        └── MyComponent.vue
+```
+
+Cela ralentit souvent le développement à mesure que les applications grandissent :
+
+1. **Pour un nouveau composant**, vous créez/modifiez des catalogues distants, configurez les espaces de noms, et traduisez (souvent via un copier/coller manuel depuis des outils d’IA).
+2. **Lors de modifications de composants**, vous recherchez les clés partagées, traduisez, maintenez les locales synchronisées, supprimez les clés obsolètes, et alignez les structures JSON.
+
+**Intlayer** scope le contenu **par composant** et le garde **à côté du code**, comme nous le faisons déjà avec le CSS, les stories, les tests et la documentation :
+
+```bash
+.
+└── components
+    └── MyComponent
+        ├── MyComponent.content.ts
+        └── MyComponent.vue
+```
+
+**Déclaration du contenu** (par composant) :
+
+```ts fileName="./components/MyComponent/MyComponent.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+// Contenu d'exemple pour le composant
+const componentExampleContent = {
+  key: "component-example",
+  content: {
+    greeting: t({
+      en: "Hello World",
+      es: "Hola Mundo",
+      fr: "Bonjour le monde",
+    }),
+  },
+} satisfies Dictionary;
+
+export default componentExampleContent;
+```
+
+**Utilisation dans Vue** (Composition API) :
+
+```vue fileName="./components/MyComponent/MyComponent.vue"
+<script setup lang="ts">
+import { useIntlayer } from "vue-intlayer"; // Intégration Vue
+const { greeting } = useIntlayer("component-example");
+</script>
+
+<template>
+  <span>{{ greeting }}</span>
+</template>
+```
+
+Cette approche :
+
+- **Accélère le développement** (déclarez une fois ; autocomplétion IDE/IA).
+- **Nettoie la base de code** (1 composant = 1 dictionnaire).
+- **Facilite la duplication/migration** (copiez un composant et son contenu ensemble).
+- **Évite les clés mortes** (les composants inutilisés n’importent pas de contenu).
+- **Optimise le chargement** (les composants chargés à la demande apportent leur contenu avec eux).
+
+---
+
+## Fonctionnalités supplémentaires d’Intlayer (pertinentes pour Vue)
+
+- **Support multi-framework** : Fonctionne avec Vue, Nuxt, Vite, React, Express, et plus encore.
+- **Gestion de contenu pilotée par JavaScript** : Déclarez dans le code avec une flexibilité totale.
+- **Fichier de déclaration par locale** : Initialisez toutes les locales et laissez les outils générer le reste.
+- **Environnement typé sécurisé** : Configuration TS robuste avec autocomplétion.
+- **Récupération de contenu simplifiée** : Un seul hook/composable pour récupérer tout le contenu d’un dictionnaire.
+- **Codebase organisée** : 1 composant = 1 dictionnaire dans le même dossier.
+- **Routage amélioré** : Helpers pour les chemins localisés et métadonnées de **Vue Router/Nuxt**.
+- **Support Markdown** : Importez du Markdown distant/local par locale ; exposez le frontmatter au code.
+- **Éditeur visuel gratuit & CMS optionnel** : Création de contenu sans plateforme de localisation payante ; synchronisation compatible Git.
+- **Contenu tree-shakable** : Ne livre que ce qui est utilisé ; supporte le chargement paresseux.
+- **Compatible rendu statique** : Ne bloque pas le SSG.
+- **Traductions assistées par IA** : Traduisez en 231 langues en utilisant votre propre fournisseur IA/clé API.
+- **Serveur MCP & extension VSCode** : Automatisez les workflows i18n et la rédaction directement dans votre IDE.
+- **Interopérabilité** : Ponts avec **vue-i18n**, **react-i18next** et **react-intl** selon les besoins.
+
+---
+
+## Quand choisir quoi ?
+
+- **Choisissez vue-i18n** si vous souhaitez l’**approche standard Vue**, que vous êtes à l’aise pour gérer vous-même les catalogues/namespaces, et que votre application est de taille **petite à moyenne** (ou si vous utilisez déjà Nuxt i18n).
+- **Choisissez Intlayer** si vous valorisez le **contenu scoped par composant**, un **TypeScript strict**, des **garanties à la compilation**, le **tree-shaking**, et des outils intégrés pour le routage/SEO/éditeur - particulièrement pour des bases de code **Vue/Nuxt larges et modulaires**.
+
+---
+
+## Notes pratiques de migration (vue-i18n → Intlayer)
+
+- **Commencez par fonctionnalité** : Déplacez une route/vue/composant à la fois vers les dictionnaires locaux d’Intlayer.
+- **Pont pendant la migration** : Gardez les catalogues vue-i18n en parallèle ; remplacez progressivement les recherches.
+- **Activez les vérifications strictes** : Laissez la détection à la compilation révéler tôt les clés/locales manquantes.
+- **Adoptez les helpers routeur/SEO** : Standardisez la détection de la locale et les balises `hreflang`.
+- **Mesurez les bundles** : Attendez-vous à des **réductions de taille de bundle** à mesure que le contenu inutilisé est exclu.
+
+---
+
+## Conclusion
+
+Les deux, **vue-i18n** et **Intlayer**, localisent bien les applications Vue. La différence réside dans **la quantité de travail que vous devez faire vous-même** pour obtenir une configuration robuste et évolutive :
+
+- Avec **Intlayer**, le **contenu modulaire**, **TS strict**, la **sécurité à la compilation**, les **bundles optimisés par tree-shaking**, ainsi que les **outils pour le routeur/SEO/éditeur** sont disponibles **nativement**.
+- Si votre équipe privilégie la **maintenabilité et la rapidité** dans une application Vue/Nuxt multi-locale et pilotée par composants, Intlayer offre aujourd’hui l’expérience la **plus complète**.
+
+Consultez la documentation ['Pourquoi Intlayer ?'](https://intlayer.org/doc/why) pour plus de détails.

package/blog/hi/intlayer_with_next-i18next.md

@@ -1,6 +1,6 @@
 ---
-createdAt: 2024-08-11
-updatedAt: 2025-06-29
+createdAt: 2025-08-23
+updatedAt: 2025-08-23
 title: Intlayer और next-i18next
 description: Next.js एप्लिकेशन के लिए next-i18next को एक्सटेंशन करें
 keywords:
@@ -24,7 +24,6 @@ next-i18next और Intlayer दोनों ओपन-सोर्स अंत
 दोनों समाधानों में तीन मुख्य अवधारणाएँ शामिल हैं:
 
 1. **सामग्री घोषणा**: आपके अनुप्रयोग की अनुवाद योग्य सामग्री को परिभाषित करने की विधि।
-
    - `i18next` के मामले में `resource` के नाम से जाना जाता है, सामग्री घोषणा एक संरचित JSON ऑब्जेक्ट है जिसमें एक या अधिक भाषाओं में अनुवाद के लिए कुंजी-मूल्य जोड़ होते हैं। अधिक जानकारी के लिए [i18next डॉक्यूमेंटेशन](https://www.i18next.com/translation-function/essentials) देखें।
    - `Intlayer` के मामले में `content declaration file` के नाम से जाना जाता है, सामग्री घोषणा एक JSON, JS, या TS फ़ाइल हो सकती है जो संरचित डेटा को निर्यात करती है। अधिक जानकारी के लिए [Intlayer डॉक्यूमेंटेशन](https://intlayer.org/fr/doc/concept/content) देखें।
 
@@ -213,8 +212,8 @@ const content = {
   content: {
     myTranslatedContent: t({
       en: "Hello World",
-      fr: "Bonjour le monde",
       es: "Hola Mundo",
+      fr: "Bonjour le monde",
     }),
   },
 } satisfies Dictionary;
@@ -231,8 +230,8 @@ const content = {
   content: {
     myTranslatedContent: t({
       en: "Hello World",
-      fr: "Bonjour le monde",
       es: "Hola Mundo",
+      fr: "Bonjour le monde",
     }),
   },
 };
@@ -246,8 +245,8 @@ module.exports = {
   content: {
     myTranslatedContent: t({
       en: "Hello World",
-      fr: "Bonjour le monde",
       es: "Hola Mundo",
+      fr: "Bonjour le monde",
     }),
   },
 };