@intlayer/docs 9.5.6 → 9.5.7

package/blog/fr/vue-i18n_vs_intlayer-vue-i18n.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "vue-i18n vs @intlayer/vue-i18n: Même API, Bundle différent"
 description: Ce qui change quand une application Vue 3 garde ses appels vue-i18n mais les exécute via l'adaptateur de compatibilité @intlayer/vue-i18n. JavaScript par page, taille d'exécution, taille de composant et fuites mesurées sur le même code Vite + Vue, plus ce que l'adaptateur conserve, ignore et ne peut pas remplacer.
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # vue-i18n VS @intlayer/vue-i18n | Même API, Bundle différent
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 `@intlayer/vue-i18n` est un adaptateur de compatibilité : il expose l'API `vue-i18n` (`createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t`, `v-t`, `i18n.global.locale`...) et la sert à partir des dictionnaires compilés par Intlayer. Vos fichiers `.vue` ne changent pas. Ce à quoi `t("footer.github")` est lié, si.
 
 Cet article mesure ce changement sur la même application Vite + Vue 3, compilée une fois avec `vue-i18n` et une fois avec l'adaptateur. Les chiffres proviennent de [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Pour `vue-i18n` et Intlayer comparés en tant que bibliothèques, lisez [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) et le [benchmark vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark). Celui-ci porte sur ce que l'adaptateur change lorsque vous conservez vos composants tels qu'ils sont.
@@ -105,6 +107,10 @@ Pour chaque build, la suite enregistre :
 
 ### Résultats sur Vite + Vue 3
 
+Sélectionnez les métriques et les bibliothèques qui vous intéressent :
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
 | Configuration            | Stratégie | Taille Lib (gz) | Taille Lib (min) | Moyenne Page JS (gz) | Fuite de locale | Fuite de page | Moyenne Component (gz) | Réactivité E2E | Chargement de page |
 | ------------------------ | --------- | --------------: | ---------------: | -------------------: | --------------: | ------------: | ---------------------: | -------------: | -----------------: |
 | **base** (no i18n)       | -         |          0.0 KB |           0.0 KB |              41.3 KB |            0.0% |             - |                 1.1 KB |         1.8 ms |            10.8 ms |
@@ -124,11 +130,24 @@ Pour chaque build, la suite enregistre :
 - **Réactivité et chargement de page.** Le changement de locale est peu coûteux pour les deux (1,5-2,8 ms) ; le système de réactivité de Vue le rend possible une fois que les messages sont en mémoire. Le chargement de page passe de 13,6 ms à **9,3 ms**, en ligne avec 88 KB de JavaScript en moins à analyser.
 - **À propos des lignes natives.** `vue-intlayer` dans cette exécution a regroupé chaque locale en mode `static` et a atteint 57,1 KB avec un runtime de 3,9 KB ; les dictionnaires synchronisés de l'adaptateur contenaient moins de chaînes de locale étrangère, d'où la figure inférieure par page. Le runtime natif reste le plus léger des trois, et son modèle `.content.ts` est l'équivalent des blocs SFC `<i18n>`.
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tableau complet, chaque bibliothèque et chaque stratégie, dans le [rapport de benchmark Vue](https://intlayer.org/fr/doc/benchmark/vue).
+
 ## Pourquoi les chiffres changent
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 Rien dans `src/components/` n'a changé, donc les gains proviennent de ce à quoi `useI18n` est lié.
 
-**Avec `vue-i18n`**, la liaison est l'instance globale. `createI18n({ messages: { en, fr, ... } })` est une seule importation qui contient tout ; chaque composant qui appelle `useI18n()` peut y accéder en entier, donc le bundler ne peut pas diviser en dessous de l'instance. L'optimisation signifie que _vous_ divisez `en.json` par route, appelez `setLocaleMessage()` dans un garde de routeur, et gardez la carte route-vers-fichier correcte au fur et à mesure que les composants se déplacent.
+**Avec `vue-i18n`**, la liaison est l'instance globale. `createI18n({ messages: { en, fr, ... } })` est une seule importation qui contient tout ; chaque composant qui appelle `useI18n()` peut y accéder en entier, donc le bundler ne peut pas diviser en dessous de l'instance. L'optimisation signifie que _vous_ divisez `en.json` par route, appelez `setLocaleMessage()` dans un garde de routeur, et gardez la carte route-vers-fichier correcte au fur et à mesure que les composants se déplacent. Le gaspillage augmente sur deux axes à la fois, les pages et les locales :
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -238,6 +257,7 @@ export const i18n = createI18n({ locale: "en" });
 `vueI18nVitePlugin()` enveloppe `vite-intlayer` (surveillance du contenu, compilation du dictionnaire, l'étape d'optimisation) et crée un alias de `vue-i18n` vers l'adaptateur. La suppression de l'importation `messages` est ce qui réduit les 88 KB ; la laisser conserve le fonctionnement de l'application mais expédie les deux.
 
 </Step>
+</Steps>
 
 ### Ce que vous pouvez supprimer par la suite
 
@@ -257,26 +277,107 @@ export const i18n = createI18n({ locale: "en" });
 
 ## Limitations à connaître avant de commencer
 
-- **Les blocs SFC `<i18n>` ne sont pas lus.** Si vos messages se trouvent à l'intérieur des composants, ils doivent être déplacés vers les fichiers de locale (ou vers `.content.ts`, qui est la même idée avec les types).
-- **Le chargement des messages à l'exécution a disparu.** `setLocaleMessage()` et `mergeLocaleMessage()` avertissent et retournent. Les traductions récupérées d'un CMS à l'exécution nécessitent le CMS d'Intlayer, ou les commandes `intlayer pull` / `push`.
-- **`messages` est un fallback, pas gratuit.** Garder les imports JSON dans `createI18n()` maintient les 75 KB dans le bundle. Supprimez-les une fois que `intlayer test` passe.
-- **L'adaptateur n'est pas le runtime natif.** 7.9 KB contre 3.9 KB pour `vue-intlayer`. Une fois que chaque composant a migré vers `useIntlayer`, supprimez-le.
+<AccordionGroup>
+<Accordion header="Les blocs SFC <i18n> ne sont pas lus">
+
+Si vos messages se trouvent dans des composants, ils doivent être déplacés vers les fichiers de locale, ou vers un fichier `.content.ts`, ce qui est la même idée avec des types générés.
+
+</Accordion>
+<Accordion header="Le chargement de messages au runtime a disparu">
+
+`setLocaleMessage()` et `mergeLocaleMessage()` affichent un avertissement et retournent. Les traductions récupérées depuis un CMS au runtime nécessitent le [CMS d'Intlayer](https://intlayer.org/fr/doc/concept/cms), ou les commandes `intlayer pull` / `push`.
+
+</Accordion>
+<Accordion header="messages est une solution de repli, pas gratuite">
+
+Garder les imports JSON dans `createI18n()` conserve les 75 KB dans le bundle. Supprimez-les une fois que `intlayer test` réussit.
+
+</Accordion>
+<Accordion header="L'adaptateur n'est pas le runtime natif">
+
+7.9 KB contre 3.9 KB pour `vue-intlayer`. Une fois que chaque composant est passé à `useIntlayer`, supprimez-le.
+
+</Accordion>
+</AccordionGroup>
 
 ## Quand utiliser quoi ?
 
-- **Restez sur `vue-i18n`** si votre app dépend des blocs SFC `<i18n>`, des flux runtime `setLocaleMessage()`, ou si 90 KB par page n'est pas une préoccupation pour votre audience.
-- **Utilisez `@intlayer/vue-i18n`** si vous êtes sur `vue-i18n` et souhaitez les 88 KB économisés, les composants 23x plus petits, 0% de fuite de page, les clés typées et les vérifications CI sans éditer un fichier `.vue`. C'est le point d'entrée pour une codebase `vue-i18n` existante.
-- **Allez au natif (`vue-intlayer`)** pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. Il dispose du runtime le plus léger (3.9 KB) et du modèle `.content.ts` par composant qui remplace les blocs `<i18n>` par du contenu typé.
+<AccordionGroup>
+<Accordion header="Rester sur vue-i18n">
+
+Votre application dépend des blocs SFC `<i18n>`, des flux `setLocaleMessage()` au runtime, ou 90 KB par page n'est pas une préoccupation pour votre public.
+
+</Accordion>
+<Accordion header="Utiliser @intlayer/vue-i18n">
+
+Vous utilisez `vue-i18n` et souhaitez économiser 88 KB, avoir des composants 23x plus petits, 0% de fuite de page, des clés typées et des vérifications CI sans modifier un seul fichier `.vue`. C'est le point d'entrée pour une codebase `vue-i18n` existante.
+
+</Accordion>
+<Accordion header="Passer en natif (vue-intlayer)">
+
+Pour les nouveaux projets, ou une fois que l'adaptateur a fait son travail. Il possède le runtime le plus léger (3.9 KB) et le modèle `.content.ts` par composant qui remplace les blocs `<i18n>` par du contenu typé. Commencez avec [Intlayer avec Vue](https://intlayer.org/fr/doc/environment/vite-and-vue) ou [avec Nuxt](https://intlayer.org/fr/doc/environment/nuxt-and-vue).
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Dois-je modifier mes fichiers .vue ?">
+
+Non. Le build de benchmark n'a modifié que `vite.config.ts`, `intlayer.config.ts` et une ligne dans `src/i18n.ts`, l'import de `messages`. Chaque appel à `useI18n()`, `$t`, `v-t` et l'Options API reste tel quel.
+
+</Question>
+
+<Question title="Pourquoi la taille des composants est-elle 23x plus petite ?">
+
+Parce que `useI18n()` ne fait plus référence à l'instance globale. `createI18n({ messages })` contient tous les messages de chaque locale, donc un composant compilé isolément embarque 196 KB. Avec l'adaptateur, il n'accède qu'à son propre dictionnaire : 8.4 KB.
+
+</Question>
+
+<Question title="Qu'en est-il du formatage avec d() et n() ?">
+
+Conservé. Les configurations `datetimeFormats` et `numberFormats` passées à `createI18n()` sont respectées, prises en charge par l'API native `Intl`. Consultez [formatage de dates, heures et nombres](https://intlayer.org/fr/blog/date-time-number-formatting-locales).
+
+</Question>
+
+<Question title="Fonctionne-t-il avec Nuxt ?">
+
+`@intlayer/vue-i18n` cible Vite + Vue. Pour `@nuxtjs/i18n`, utilisez l'[adaptateur de compatibilité Nuxt i18n](https://intlayer.org/fr/doc/compatibility/nuxtjs-i18n), et consultez [Intlayer avec Nuxt](https://intlayer.org/fr/doc/environment/nuxt-and-vue) pour l'installation native.
+
+</Question>
+
+<Question title="Puis-je migrer composant par composant ?">
+
+Oui. N'importe quel composant peut passer de `useI18n()` à `useIntlayer("footer")` avec un fichier de contenu colocalisé. Les dictionnaires JSON et `.content.ts` coexistent et fusionnent.
+
+</Question>
+
+</FAQ>
 
 ## Comparaisons associées
 
-- [vue-i18n vs Intlayer](https://intlayer.org/blog/vue-i18n-vs-intlayer) (features et DX)
-- [vue-i18n vs Intlayer benchmark](https://intlayer.org/blog/vue-i18n-vs-intlayer-benchmark) (les libraries, même benchmark)
-- [next-intl vs @intlayer/next-intl](https://intlayer.org/blog/next-intl-vs-intlayer-next-intl) (même série d'adapter)
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) (même série d'adapter)
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (même série d'adapter)
-- [Guide de migration : vue-i18n vers Intlayer](https://intlayer.org/doc/migration/vue-i18n)
-- [Référence de l'adaptateur de compatibilité : vue-i18n](https://intlayer.org/doc/compatibility/vue-i18n), [Nuxt i18n](https://intlayer.org/doc/compatibility/nuxtjs-i18n)
+Même série d'adaptateurs :
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/fr/blog/next-intl-vs-intlayer-next-intl)
+- [i18next vs @intlayer/i18next](https://intlayer.org/fr/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/fr/blog/lingui-vs-intlayer-lingui)
+
+Les bibliothèques comparées directement :
+
+- [vue-i18n vs Intlayer](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer), features et DX
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-benchmark)
+- [Is vue-i18n outdated?](https://intlayer.org/fr/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/fr/blog/how-to-pick-vue-i18n-library)
+
+Documentation de référence :
+
+- [Compat adapter: vue-i18n](https://intlayer.org/fr/doc/compatibility/vue-i18n) and [Nuxt i18n](https://intlayer.org/fr/doc/compatibility/nuxtjs-i18n)
+- [Guide de migration : vue-i18n vers Intlayer](https://intlayer.org/fr/doc/migration/vue-i18n)
+- [Rapport de benchmark Vue](https://intlayer.org/fr/doc/benchmark/vue)
+- [Optimisation du bundle](https://intlayer.org/fr/doc/concept/bundle-optimization) et [le compilateur Intlayer](https://intlayer.org/fr/doc/compiler)
+- [Visual Editor](https://intlayer.org/fr/doc/concept/editor), [CMS](https://intlayer.org/fr/doc/concept/cms) et [traduction par IA](https://intlayer.org/fr/doc/concept/auto-fill)
 
 ## Conclusion
 
@@ -284,4 +385,4 @@ export const i18n = createI18n({ locale: "en" });
 
 Toutes les données brutes, les applications de test et les scripts se trouvent dans le [référentiel Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom). Exécutez-le vous-même.
 
-Reportez-vous à la [documentation 'Pourquoi Intlayer ?'](https://intlayer.org/doc/why) pour plus de détails.
+Reportez-vous à la [documentation 'Pourquoi Intlayer ?'](https://intlayer.org/fr/doc/why) pour plus de détails.

package/blog/fr/vue-i18n_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-08-23
+updatedAt: 2026-09-22
 title: vue-i18n vs Intlayer
 description: Comparaison de vue-i18n avec Intlayer pour l'internationalisation (i18n) dans les applications Vue/Nuxt
 keywords:
@@ -20,6 +20,8 @@ author: aymericzip
 
 # vue-i18n VS Intlayer | Internationalisation Vue (i18n)
 
+![Vue i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 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 :
 
@@ -31,6 +33,8 @@ Nous nous concentrons sur les outils modernes de Vue (Vite, Composition API) et
 6. **Expérience développeur (DX), outils & maintenance**
 7. **SEO & évolutivité pour les grands projets**
 
+<TOC/>
+
 > **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
@@ -38,6 +42,30 @@ Nous nous concentrons sur les outils modernes de Vue (Vite, Composition API) et
 - **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**.
 
+## Ce que cela coûte au moment de la compilation
+
+Avant les tableaux de fonctionnalités, la partie mesurée. [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) construit la même application Vite + Vue 3 (10 pages, 10 locales) avec chaque bibliothèque et enregistre ce que le navigateur télécharge :
+
+<I18nBenchmark framework="vite-vue" vertical/>
+
+| Setup                | Lib size (gz) | Page JS avg (gz) | Page leak | Component avg (gz) |
+| -------------------- | ------------: | ---------------: | --------: | -----------------: |
+| **base** (no i18n)   |        0.0 KB |          41.3 KB |         - |             1.1 KB |
+| `vue-i18n`           |       24.3 KB |         134.9 KB |     90.0% |           196.0 KB |
+| `@intlayer/vue-i18n` |        7.9 KB |          47.0 KB |      0.0% |             8.4 KB |
+| **`vue-intlayer`**   |    **3.9 KB** |      **57.1 KB** |  **0.0%** |         **7.7 KB** |
+
+Le runtime de `vue-i18n` pèse à lui seul **6x** celui d'Intlayer, chaque page transporte **90% de chaînes de pages étrangères**, et un composant compilé isolément pèse **196 KB** car `useI18n()` le lie à l'arborescence globale des messages. L'exécution complète, avec les temps de réactivité et de chargement de page, se trouve dans le [benchmark vue-i18n vs Intlayer](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-benchmark).
+
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_vue.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> Tableau complet dans le [rapport de benchmark Vue](https://intlayer.org/fr/doc/benchmark/vue).
+
 ## Comparaison des fonctionnalités côte à côte (axée sur Vue)
 
 | Fonctionnalité                                          | **Intlayer**                                                                                    | **vue-i18n**                                                                                           |
@@ -63,59 +91,74 @@ Nous nous concentrons sur les outils modernes de Vue (Vite, Composition API) et
 
 ## Comparaison approfondie
 
-### 1) Architecture et évolutivité
+<AccordionGroup>
+<Accordion header="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.
+- **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. Voir [i18n par composant vs centralisée](https://intlayer.org/fr/blog/per-component-vs-centralized-i18n).
 - **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é
+</Accordion>
+<Accordion header="2) TypeScript et 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
+</Accordion>
+<Accordion header="3) Gestion des traductions manquantes">
 
-- **vue-i18n** : Avertissements/repli **à l’exécution** (par exemple, locale ou clé de repli).
+- **vue-i18n** : Avertissements/repli **à l’exécution** (par exemple, locale ou clé de repli). Voir [détection des traductions manquantes](https://intlayer.org/fr/blog/detecting-missing-translations).
 - **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)
+</Accordion>
+<Accordion header="4) Stratégie de routage et d'URL (Vue Router/Nuxt)">
 
-- **Les deux** peuvent fonctionner avec des routes localisées.
+- **Les deux** peuvent fonctionner avec des routes localisées. Voir le [guide hreflang](https://intlayer.org/fr/blog/hreflang-guide-multilingual-seo).
 - **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
+</Accordion>
+<Accordion header="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).
+- **vue-i18n** : Supporte les messages de locale asynchrones ; éviter le sur-emballage dépend de vous (divisez les catalogues avec soin). Le benchmark ci-dessus illustre ces chiffres : 134.9 KB contre 57.1 KB par page.
 - **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
+</Accordion>
+<Accordion header="6) Expérience développeur et outillage">
 
 - **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.
+- **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., un **serveur MCP**
 
 **Pourquoi c’est important :** Réduction des coûts opérationnels et boucle dev–contenu plus courte.
 
-### 7) SEO, SSR & SSG
+</Accordion>
+<Accordion header="7) SEO, SSR et SSG">
 
-- **Les deux** fonctionnent avec Vue SSR et Nuxt.
+- **Les deux** fonctionnent avec Vue SSR et Nuxt. Voir [internationalisation et SEO](https://intlayer.org/fr/blog/SEO-and-i18n).
 - **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é.
 
+</Accordion>
+</AccordionGroup>
+
 ## Pourquoi Intlayer ? (Problème & approche)
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 La plupart des stacks i18n (y compris **vue-i18n**) partent de **catalogues centralisés** :
 
+<Tabs defaultTab="per-locale" group="catalog">
+<Tab label="Un fichier par locale" value="per-locale">
+
 ```bash
 .
 ├── locales
@@ -127,7 +170,8 @@ La plupart des stacks i18n (y compris **vue-i18n**) partent de **catalogues cent
         └── MyComponent.vue
 ```
 
-Ou avec des dossiers par langue :
+</Tab>
+<Tab label="Un dossier par locale" value="per-folder">
 
 ```bash
 .
@@ -146,6 +190,34 @@ Ou avec des dossiers par langue :
         └── MyComponent.vue
 ```
 
+</Tab>
+</Tabs>
+
+Ce dossier ne cesse de croître, un namespace par fonctionnalité, dans chaque locale :
+
+```txt
+locales
+├── EN
+│   ├── blog.json
+│   ├── about.json
+│   ├── auth.json
+│   ├── blog.json
+│   ├── cart.json
+│   ├── categories.json
+│   ├── contact.json
+│   ├── dashboard.json
+│   ├── errors.json
+│   ├── faq.json
+│   ├── footer.json
+│   ├── form.json
+│   ├── home.json
+│   ├── language.json
+│   ├── navbar.json
+│   ├── ... 65 files
+│   └── validation.json
+└── ES
+```
+
 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).
@@ -161,19 +233,44 @@ Cela ralentit souvent le développement à mesure que les applications grandisse
         └── MyComponent.vue
 ```
 
-**Déclaration du contenu** (par composant) :
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="vue-i18n" value="vue-i18n">
+
+```json fileName="./locales/en.json"
+{
+  "componentExample": {
+    "greeting": "Hello World"
+  }
+}
+```
+
+```vue fileName="./components/MyComponent.vue"
+<script setup lang="ts">
+import { useI18n } from "vue-i18n";
+
+const { t } = useI18n();
+</script>
+
+<template>
+  <span>{{ t("componentExample.greeting") }}</span>
+</template>
+```
+
+Chaque fichier de locale doit être modifié à la main, et la clé est une simple chaîne de caractères : une faute de frappe s'affiche sous la forme `componentExample.greting` en production.
+
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```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",
+      es: "Hola Mundo",
     }),
   },
 } satisfies Dictionary;
@@ -181,11 +278,10 @@ const componentExampleContent = {
 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
+import { useIntlayer } from "vue-intlayer"; // Vue integration
+
 const { greeting } = useIntlayer("component-example");
 </script>
 
@@ -194,6 +290,11 @@ const { greeting } = useIntlayer("component-example");
 </template>
 ```
 
+Toutes les locales se trouvent dans un seul fichier typé à côté du composant.
+
+</Tab>
+</Tabs>
+
 Cette approche :
 
 - **Accélère le développement** (déclarez une fois ; autocomplétion IDE/IA).
@@ -221,22 +322,71 @@ Cette approche :
 
 ## 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**.
+<AccordionGroup>
+<Accordion header="Choisir vue-i18n">
+
+Vous souhaitez **l'approche standard de Vue**, vous êtes à l'aise pour gérer vous-même les catalogues et les namespaces, et votre application est de **taille petite à moyenne** (ou vous vous appuyez déjà sur Nuxt i18n). Les blocs SFC `<i18n>` et le chargement `setLocaleMessage()` au runtime sont des fonctionnalités qu'Intlayer ne reproduit délibérément pas.
+
+</Accordion>
+<Accordion header="Choisir Intlayer">
+
+Vous privilégiez le **contenu par composant**, un **TypeScript strict**, des **garanties à la compilation**, le **tree-shaking** et des outils intégrés de routage, SEO et d'édition, en particulier pour les **grandes bases de code modulaires Vue/Nuxt** et les design systems. Commencez avec [Intlayer avec Vue](https://intlayer.org/fr/doc/environment/vite-and-vue) ou [avec Nuxt](https://intlayer.org/fr/doc/environment/nuxt-and-vue).
+
+</Accordion>
+<Accordion header="Choisir @intlayer/vue-i18n">
+
+Vous utilisez `vue-i18n` aujourd'hui et souhaitez bénéficier des gains de bundle sans modifier de fichier `.vue`. L'[adaptateur de compatibilité](https://intlayer.org/fr/doc/compatibility/vue-i18n) conserve `createI18n`, `useI18n`, `t()`, `d()`, `n()`, `$t` et `v-t`, et les sert à partir de dictionnaires compilés. Mesuré côte à côte dans [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-vue-i18n).
+
+</Accordion>
+</AccordionGroup>
 
 ## Interopérabilité avec vue-i18n
 
 `intlayer` peut aussi vous aider à gérer vos namespaces `vue-i18n`.
 
-En utilisant `intlayer`, vous pouvez déclarer votre contenu dans le format de votre bibliothèque i18n préférée, et intlayer générera vos namespaces à l'emplacement de votre choix (exemple : `/messages/{{locale}}/{{namespace}}.json`).
+En utilisant `intlayer`, vous pouvez déclarer votre contenu dans le format de votre bibliothèque i18n préférée, et intlayer générera vos namespaces à l'emplacement de votre choix (exemple : `/messages/{{locale}}/{{namespace}}.json`). Voir la [documentation de compatibilité vue-i18n](https://intlayer.org/fr/doc/compatibility/vue-i18n) et l'[adaptateur Nuxt i18n](https://intlayer.org/fr/doc/compatibility/nuxtjs-i18n).
+
+## FAQ
+
+<FAQ>
+
+<Question title="Intlayer est-il un remplaçant pour vue-i18n ou une couche par-dessus ?">
+
+Les deux, selon la façon dont vous l'adoptez. `vue-intlayer` est un runtime natif avec son propre composable `useIntlayer()`. `@intlayer/vue-i18n` est un adaptateur de compatibilité qui conserve l'API `vue-i18n` et remplace ce à quoi elle est liée, afin que vous puissiez migrer sans toucher aux composants et progresser fichier par fichier ensuite.
+
+</Question>
+
+<Question title="Qu'advient-il de mes blocs SFC <i18n> ?">
+
+L'adaptateur ne les lit pas. Déplacez ces messages dans votre JSON de locale, ou dans un `.content.ts` à côté du composant, ce qui est la même idée avec des types générés. C'est la seule fonctionnalité de `vue-i18n` qui n'est pas reportée.
 
-## Notes pratiques de migration (vue-i18n → Intlayer)
+</Question>
 
-- **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.
+<Question title="Intlayer fonctionne-t-il avec Nuxt ?">
+
+Oui. [Intlayer avec Nuxt](https://intlayer.org/fr/doc/environment/nuxt-and-vue) prend en charge le routage multilingue, le middleware de détection de locale et la génération de sitemaps. Si vous utilisez `@nuxtjs/i18n`, l'[adaptateur de compatibilité Nuxt i18n](https://intlayer.org/fr/doc/compatibility/nuxtjs-i18n) constitue la voie de migration.
+
+</Question>
+
+<Question title="Puis-je conserver mes locales/{locale}.json comme source de vérité ?">
+
+Oui. Le [plugin de synchronisation JSON](https://intlayer.org/fr/doc/compatibility/vue-i18n) les lit avec le dialecte `vue-i18n` (`{name}`, `{0}`, les pluriels en pipe `"car | cars"`) et réécrit les traductions lorsque la CLI ou le CMS les met à jour.
+
+</Question>
+
+<Question title="ICU fonctionne-t-il avec Intlayer sur Vue ?">
+
+Le support natif d'ICU est en cours de développement. L'adaptateur `@intlayer/vue-i18n` gère la syntaxe propre à `vue-i18n`, y compris les pluriels et l'interpolation de listes et de variables nommées. Pour le modèle de pluralisation d'Intlayer, consultez le [contenu d'énumération](https://intlayer.org/fr/doc/concept/content/enumeration).
+
+</Question>
+
+</FAQ>
+
+## GitHub STARs
+
+Les étoiles GitHub sont un indicateur fort de la popularité d'un projet, de la confiance de la communauté et de sa pertinence à long terme. Bien qu'elles ne constituent pas une mesure directe de la qualité technique, elles reflètent le nombre de développeurs qui trouvent le projet utile, suivent ses progrès et sont susceptibles de l'adopter. Pour estimer la valeur d'un projet, les étoiles aident à comparer l'attraction entre les alternatives et donnent un aperçu de la croissance de l'écosystème.
+
+[![Star History Chart](https://api.star-history.com/chart?repos=intlify%2Fvue-i18n%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
 ## Conclusion
 
@@ -245,4 +395,15 @@ Les deux, **vue-i18n** et **Intlayer**, localisent bien les applications Vue. La
 - 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.
+## Lectures complémentaires
+
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-benchmark), l’exécution mesurée derrière le tableau ci-dessus
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/fr/blog/vue-i18n-vs-intlayer-vue-i18n), l’adaptateur sur la même application
+- [Is vue-i18n outdated?](https://intlayer.org/fr/blog/is-vue-i18n-outdated)
+- [How to pick a Vue i18n library](https://intlayer.org/fr/blog/how-to-pick-vue-i18n-library)
+- [Using Intlayer with vue-i18n](https://intlayer.org/fr/blog/intlayer-with-vue-i18n)
+- [Vue benchmark report](https://intlayer.org/fr/doc/benchmark/vue)
+- [Migration guide: vue-i18n to Intlayer](https://intlayer.org/fr/doc/migration/vue-i18n)
+- [Bundle optimization](https://intlayer.org/fr/doc/concept/bundle-optimization) and [the Intlayer compiler](https://intlayer.org/fr/doc/compiler)
+
+Refer to ['Why Intlayer?' doc](https://intlayer.org/fr/doc/why) for more details.