Intlayer

--- 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.