Comment choisir la bonne bibliothèque i18n pour Vue

"Vue i18n" est à la fois un terme générique et le nom de la bibliothèque que presque tout le monde installe. C'est à la fois pratique et trompeur : vue-i18n est un choix par défaut tout à fait convenable, mais ce n'est pas la seule option, et les questions qui devraient guider votre choix (SSR ou non, nombre de pages, qui rédige les traductions) sont rarement posées avant d'exécuter npm install.

Ce guide pose d'abord ces questions, puis fait correspondre les réponses aux bibliothèques adaptées, pour Vite + Vue standard et pour Nuxt.

Table des matières

Six questions à se poser avant de comparer les bibliothèques

1. Vite SPA ou Nuxt ? Dans une SPA, le coût du catalogue est un problème de bundle JS. Dans Nuxt, c'est aussi un problème de payload HTML, car les messages sont sérialisés dans l'état SSR puis hydratés. La plupart des retours disant que "vue-i18n est lent" proviennent d'applications Nuxt pour cette raison.
2. Qui rédige les traductions ? Des développeurs, un TMS, une agence fournissant des chaînes ICU, ou un pipeline IA. vue-i18n utilise sa propre syntaxe de pluriel séparée par des barres verticales (|), et non ICU. Cela a son importance si les chaînes proviennent de l'extérieur.
3. Combien de locales et de pages ? Deux locales et cinq pages peuvent tout embarquer d'un coup. Dix locales et quarante routes ne le peuvent pas, et la stratégie de chargement devient le coût principal.
4. Avez-vous besoin du typage sur les clés ? t("cart.totl") compile dans vue-i18n à moins de passer un generic de schéma de message, et ce schéma entre en conflit avec les catalogues chargés en lazy loading.
5. Que contient votre contenu ? Uniquement des libellés d'interface utilisateur, ou du markdown, des liens au milieu des phrases et des blocs spécifiques à chaque locale ? C'est avec le contenu riche que le retour sous forme de chaîne de caractères de t() devient fastidieux.
6. Le CSP est-il une contrainte ? Le build par défaut de vue-i18n compile les messages dans le navigateur avec new Function. Les builds runtime-only nécessitent @intlify/unplugin-vue-i18n pour précompiler au moment du build.

Notez vos réponses. Tout ce qui suit y fait référence.

Le paysage en une image

L'écosystème Vue compte moins de bibliothèques i18n que React, et elles sont issues de différentes vagues architecturales.

L'histoire de l'i18n JavaScript détaille chaque vague en profondeur.

La décision la plus importante : où vit le contenu et quand se charge-t-il

Deux choix structurels expliquent la majeure partie des différences de taille de bundle entre les configurations :

• Contenu centralisé ou scopé. Un seul locales/fr.json pour toute l'application, ou une déclaration par composant.
• Import statique ou dynamique. Tout charger au démarrage, ou récupérer la locale active (et idéalement la route active) à la demande.

Le graphique estime le payload pour une application théorique de 1 à 10 pages, traduite en 1 à 10 locales, avec environ 30 Ko de texte par page.

vue-i18n prend en charge l'axe dynamique : appeler setLocaleMessage après un import() vous évite d'expédier neuf locales que personne ne lit. Ce qu'il ne permet pas, c'est l'axe de la page. Un catalogue de locale est un objet unique, et le charger charge les textes de chaque page. Dans une SPA, personne ne s'en aperçoit. Dans Nuxt, avec @nuxtjs/i18n et plus de dix pages, chaque route transporte les chaînes de toutes les autres routes, en double : dans le chunk JS et dans le payload SSR.

Le benchmark Vue mesure cela sous forme de "fuite des autres routes" et "fuite des autres locales". Si votre réponse à la question 3 était "beaucoup de pages", cette section l'emporte sur toute préférence d'API. L'article sur l'i18n par composant vs centralisée aborde la maintenance de ce même compromis.

Les candidats

Les tailles des bibliothèques sont issues du benchmark Vue : plugin plus composable dans un composant vide, après bundling, tree-shaking et minification, sur une application de 10 pages et 10 locales. Le contenu est mesuré séparément.

Les chiffres représentent un instantané basé sur les versions du benchmark. Exécutez-le sur votre propre application avant de décider uniquement sur la taille.

La taille quasi nulle de la bibliothèque Paraglide découle de sa conception : le runtime est généré dans votre repository, ce qui implique une étape de regénération avant chaque push et des conflits de fusion sur les fichiers générés. Intlayer nécessite vite-intlayer (ou le module Nuxt), il ne peut donc pas fonctionner sans étape de build.

Associez vos réponses à une bibliothèque

Les limites de chaque bibliothèque

• vue-i18n : la plus lourde du groupe, format de pluriel propriétaire, types optionnels et fragiles avec le lazy loading, pas de découpage par route, accumulation silencieuse de clés mortes. Laisser legacy: true dans une application Vue 3 conserve la couche de compatibilité Vue 2 et fait perdre le typage de useI18n().
• @nuxtjs/i18n : hérite de tous les points ci-dessus, et le payload SSR transporte les chaînes de chaque page dès qu'on dépasse une douzaine de routes.
• fluent-vue : syntaxe de message agréable, pas de typage sur les clés, et le plugin Vite charge tout le contenu dans toutes les langues sur chaque page. La plus lourde du benchmark.
• Paraglide : fichiers générés commités dans le repo, regénération avant chaque push, et la locale est lue depuis un cookie ou le storage à chaque appel de message plutôt que depuis un store réactif, ce qui entraîne un surcoût lors des changements de locale.
• Intlayer : plugin de build obligatoire, écosystème plus restreint, support partiel d'ICU, et contenu réparti dans toute la codebase par conception, ce qui nécessite des outils pour exporter un JSON unique destiné à un traducteur.

Ce que chaque option donne en code

Le même composant, un récapitulatif de panier avec un titre et un pluriel, écrit avec chaque candidat. La partie intéressante n'est pas le template, mais l'endroit où réside le contenu et ce que vue-tsc en sait.

{
  "cart": {
    "title": "Your cart",
    "items": "no item | one item | {count} items"
  }
}

<script setup lang="ts">
import { useI18n } from "vue-i18n";

const props = defineProps<{ count: number }>();
const { t } = useI18n();
</script>

<template>
  <section>
    <h2>{{ t("cart.title") }}</h2>
    <p>{{ t("cart.items", { count: props.count }, props.count) }}</p>
  </section>
</template>

cart-title = Your cart
cart-items = { $count ->
    [one] { $count } item
   *[other] { $count } items
}

<script setup lang="ts">
import { useFluent } from "fluent-vue";

const props = defineProps<{ count: number }>();
const { $t } = useFluent();
</script>

<template>
  <section>
    <h2>{{ $t("cart-title") }}</h2>
    <p>{{ $t("cart-items", { count: props.count }) }}</p>
  </section>
</template>

{
  "cart_title": "Your cart",
  "cart_items": "{count} items"
}

<script setup lang="ts">
import { m } from "../paraglide/messages.js";

const props = defineProps<{ count: number }>();
</script>

<template>
  <section>
    <h2>{{ m.cart_title() }}</h2>
    <p>{{ m.cart_items({ count: props.count }) }}</p>
  </section>
</template>

import { plural, t, type Dictionary } from "intlayer";

const cartSummaryContent = {
  key: "cart-summary",
  content: {
    title: t({ fr: "Votre panier", en: "Your cart", es: "Tu carrito" }),
    items: t({
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
    }),
  },
} satisfies Dictionary;

export default cartSummaryContent;

<script setup lang="ts">
import { useIntlayer } from "vue-intlayer";

const props = defineProps<{ count: number }>();
const { title, items } = useIntlayer("cart-summary");
</script>

<template>
  <section>
    <h2><title /></h2>
    <p>{{ items(props.count) }}</p>
  </section>
</template>

Vous utilisez déjà vue-i18n ? L'adaptateur de compatibilité @intlayer/vue-i18n crée un alias du package au niveau du bundler, de sorte que useI18n(), $t, les pluriels pipe et v-t continuent de fonctionner pendant qu'Intlayer sert le contenu. Le guide de migration explique comment se détacher de l'adaptateur par la suite, et il existe un guide spécifique à Nuxt.

Avant de vous engager

Un tableau de fonctionnalités indique ce qu'une bibliothèque fait aujourd'hui. Les points suivants expliquent à quoi ressemblera votre quotidien avec elle.

Vérifiez l'activité du repository.

Commits, temps de réponse sur les issues, et si la dernière release mineure date de cette année. Une conception solide sans mainteneur est une future migration forcée.

Ne choisissez pas en fonction des téléchargements npm.

La bibliothèque la plus installée est celle qui est sortie en premier, pas nécessairement celle qui convient à une codebase Vue en 2026. Les téléchargements mesurent l'ancienneté, pas l'adéquation.

Renseignez-vous sur qui finance le mainteneur et ce qu'il vend.

vue-i18n est soutenu par Crowdin, tout comme next-intl et svelte-i18n. i18next est soutenu par Locize. Tolgee, Paraglide (inlang) et Intlayer gèrent chacun leur propre plateforme. Un fournisseur dont les revenus reposent sur l'hébergement des traductions a peu d'intérêt à rendre la traduction gratuite au sein de votre toolchain. Intlayer est le seul de la liste à intégrer la traduction par IA via la CLI avec votre propre clé API, ainsi qu'un CMS que vous pouvez auto-héberger.

Est-il prêt pour les agents IA ?

Les agents rencontrent encore des difficultés avec l'i18n : ils oublient des locales, inventent des clés et mélangent les syntaxes de messages. La bibliothèque fournit-elle des Agent Skills ou un serveur MCP pour permettre à l'agent de lister, compléter et tester le contenu ? Et le chargement du contenu est-il optimisé par défaut, ou quelqu'un doit-il auditer les namespaces et les imports lazy chaque trimestre ?

Typage strict dès l'installation.

Pas un simple "peut être typé avec de la configuration supplémentaire", mais "une mauvaise clé fait échouer tsc sur une installation neuve". Regardez ce qui se produit avec une clé inexistante, ainsi qu'avec une locale à laquelle il manque une traduction.

Détection du contenu inutilisé.

Les catalogues ne font que grossir. Le build d'Intlayer purge les champs inutilisés et les consigne (build.purge). Paraglide y parvient par architecture, puisqu'une fonction de message non appelée est éliminée via tree-shaking. Tout le reste vous laisse le soin de faire le ménage.

Expérience développeur.

Le temps de configuration jusqu'à la première chaîne traduite, un LSP ou une extension VS Code qui affiche la traduction au survol et renvoie vers la déclaration, une CLI pour compléter, tester et synchroniser (push), et un moyen pour les non-développeurs d'éditer le contenu (éditeur visuel ou CMS) sans pull request.

Foire Aux Questions

Pour aller plus loin

• Benchmark Vue i18n : taille de bundle, fuites et temps de changement de locale
• Vue i18n : comment fonctionne vue-i18n et ses points faibles et l'article sur Nuxt i18n
• vue-i18n vs Intlayer, fonctionnalité par fonctionnalité et le benchmark vue-i18n vs Intlayer
• vue-i18n est-il obsolète ?
• L'histoire de l'i18n JavaScript
• i18n basée sur compilateur vs déclarative
• i18n par composant vs centralisée
• Configurer l'i18n dans une application Vite + Vue et dans une application Nuxt
• Le même guide pour React, Svelte et Solid