Come scegliere la giusta libreria i18n per Vue

"Vue i18n" è sia un termine generico sia il nome della libreria che quasi tutti installano. Questo è conveniente e fuorviante allo stesso tempo: vue-i18n è un'ottima scelta predefinita, ma non è l'unica opzione, e le domande che dovrebbero guidare la scelta (SSR o no, quante pagine, chi scrive le traduzioni) vengono poste raramente prima di eseguire npm install.

Questa guida le pone per prima, per poi mappare le risposte sulle librerie più adatte, sia per Vite + Vue puro sia per Nuxt.

Indice

Sei domande a cui rispondere prima di confrontare le librerie

1. Vite SPA o Nuxt? In una SPA il costo del catalogo è un problema di bundle JS. In Nuxt è anche un problema di payload HTML, poiché i messaggi vengono serializzati nello stato SSR e idratati. La maggior parte delle segnalazioni del tipo "vue-i18n è lento" proviene da applicazioni Nuxt per questa ragione.
2. Chi scrive le traduzioni? Sviluppatori, un TMS, un'agenzia che fornisce stringhe ICU o una pipeline AI. vue-i18n utilizza una propria sintassi per i plurali separata da pipe, non ICU. Questo è importante se le stringhe provengono dall'esterno.
3. Quante lingue (locales) e quante pagine? Due lingue e cinque pagine possono includere tutto nel bundle. Dieci lingue e quaranta route no, e la strategia di caricamento diventa il costo principale.
4. Avete bisogno di types sulle chiavi? t("cart.totl") compila senza errori in vue-i18n a meno che non si passi un generico per lo schema dei messaggi, e tale schema entra in conflitto con i cataloghi caricati in modo lazy.
5. Cosa contiene il contenuto? Solo etichette UI, o markdown, link all'interno delle frasi e blocchi specifici per lingua. I contenuti complessi (rich content) sono il punto in cui t() che restituisce una stringa diventa scomodo.
6. La CSP è un vincolo? La build predefinita di vue-i18n compila i messaggi nel browser con new Function. Le build runtime-only richiedono @intlify/unplugin-vue-i18n per precompilare a build time.

Scrivete le risposte. Tutto ciò che segue fa riferimento ad esse.

Il panorama in un'unica panoramica

L'ecosistema Vue conta meno librerie i18n rispetto a React, e provengono da ondate architetturali differenti.

La storia dell'i18n in JavaScript tratta ogni ondata nel dettaglio.

La decisione più importante: dove risiedono i contenuti e quando vengono caricati

Due scelte strutturali spiegano la maggior parte delle differenze di bundle tra i vari setup:

• Contenuto centralizzato o scoped. Un unico locales/en.json per l'applicazione, oppure una dichiarazione per componente.
• Import statico o dinamico. Tutto all'avvio, oppure la lingua attiva (e idealmente la route attiva) caricata on-demand.

Il grafico stima il payload per un'applicazione teorica da 1 a 10 pagine, tradotta in 1-10 lingue, con circa 30 KB di testo per pagina.

vue-i18n supporta l'asse dinamico: setLocaleMessage dopo un import() permette di evitare di distribuire nove lingue che nessuno legge. Ciò che non offre è l'asse delle pagine. Un catalogo per lingua è un unico oggetto, e caricarlo comporta il caricamento dei testi di ogni pagina. In una SPA nessuno se ne accorge. In Nuxt, con @nuxtjs/i18n e più di dieci pagine, ogni route trasporta le stringhe di ogni altra route, due volte: nel chunk JS e nel payload SSR.

Il benchmark Vue misura questo aspetto come "leakage da altre route" e "leakage da altre lingue". Se la vostra risposta alla domanda 3 era "molte pagine", questa sezione supera qualsiasi preferenza di API. L'articolo i18n per componente vs centralizzato analizza il lato manutenzione dello stesso compromesso.

I candidati

Le dimensioni delle librerie provengono dal benchmark Vue: plugin più composable in un componente vuoto, dopo bundling, tree-shaking e minificazione, su un'app di 10 pagine e 10 lingue. Il contenuto è misurato separatamente.

I numeri sono un'istantanea alle versioni del benchmark. Eseguitelo sulla vostra applicazione prima di decidere unicamente in base alle dimensioni.

La dimensione quasi nulla della libreria Paraglide è dovuta alla sua architettura: il runtime viene generato direttamente nel repository, il che comporta un passaggio di rigenerazione prima di ogni push e conflitti di merge sui file generati. Intlayer necessita di vite-intlayer (o del modulo Nuxt), quindi non può funzionare senza una fase di build.

Mappare le risposte a una libreria

Dove ogni libreria mostra i suoi limiti

• vue-i18n: la più pesante del gruppo, formato proprietario per i plurali, types opzionali e fragili con il lazy loading, nessuna suddivisione per route, le chiavi obsolete si accumulano silenziosamente. Lasciare legacy: true in un'app Vue 3 mantiene il layer di compatibilità con Vue 2 e perde la tipizzazione di useI18n().
• @nuxtjs/i18n: eredita tutti i punti sopra, e il payload SSR trasporta le stringhe di ogni pagina non appena si supera una dozzina di route.
• fluent-vue: ottima sintassi dei messaggi, nessun type per le chiavi, e il plugin Vite carica tutti i contenuti in tutte le lingue in ogni pagina. La più pesante nel benchmark.
• Paraglide: file generati salvati nel repository, rigenerazione prima di ogni push, e la lingua viene letta da cookie o storage a ogni chiamata del messaggio invece che da uno store reattivo, con un costo computazionale al cambio lingua.
• Intlayer: plugin di build obbligatorio, ecosistema più piccolo, supporto ICU parziale e contenuti distribuiti nel codebase per progettazione, quindi esportare un unico JSON per un traduttore richiede strumenti appositi.

Come si presenta ogni opzione nel codice

Lo stesso componente, un riepilogo del carrello con un titolo e un plurale, scritto con ciascun candidato. La parte interessante non è il template, ma dove risiede il contenuto e cosa vue-tsc sa a riguardo.

{
  "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({
      it: "Il tuo carrello",
      en: "Your cart",
      fr: "Votre panier",
      es: "Tu carrito",
    }),
    items: t({
      it: plural({ one: "{{count}} articolo", other: "{{count}} articoli" }),
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      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>

Utilizzate già vue-i18n? L'adapter di compatibilità @intlayer/vue-i18n crea un alias per il pacchetto a livello di bundler, consentendo a useI18n(), $t, plurali con pipe e v-t di continuare a funzionare mentre Intlayer gestisce i contenuti. La guida alla migrazione illustra come abbandonare l'adapter successivamente, ed è disponibile anche una guida specifica per Nuxt.

Prima di effettuare la scelta definitiva

Una tabella delle funzionalità indica cosa fa una libreria oggi. Questi punti descrivono come sarà l'utilizzo quotidiano.

Verificate l'attività del repository.

Commit, tempi di risposta alle issue e se l'ultima minor release risale a quest'anno. Un'ottima architettura senza manutentori equivale a una migrazione futura annunciata.

Non basate la scelta sui download npm.

La libreria più installata è quella rilasciata per prima, non necessariamente quella più adatta a un codebase Vue nel 2026. I download misurano la storia, non l'idoneità.

Chiedetevi chi finanzia il manutentore e cosa vende.

vue-i18n è supportato da Crowdin, come next-intl e svelte-i18n. i18next è supportato da Locize. Tolgee, Paraglide (inlang) e Intlayer gestiscono ciascuno la propria piattaforma. Un fornitore le cui entrate dipendono dalla traduzione ospitata (hosted translation) ha pochi incentivi a rendere la traduzione gratuita all'interno della vostra toolchain. Intlayer è l'unica del gruppo a offrire la traduzione tramite AI direttamente da CLI con la vostra chiave API e un CMS con supporto self-hosting.

È pronta per gli agenti AI?

Gli agenti incontrano ancora difficoltà con l'i18n: dimenticano lingue, inventano chiavi e confondono le sintassi dei messaggi. La libreria include Agent Skills o un server MCP affinché l'agente possa elencare, compilare e testare i contenuti? E il caricamento dei contenuti è ottimizzato di default, o qualcuno deve revisionare namespace e import lazy ogni trimestre?

Type safety out of the box.

Non "può essere tipizzata con configurazioni extra", ma "una chiave errata blocca tsc su un'installazione pulita". Verificate cosa accade con una chiave non esistente e con una lingua a cui manca una traduzione.

Rilevamento dei contenuti inutilizzati.

I cataloghi tendono solo a crescere. La build di Intlayer elimina i campi inutilizzati e li segnala nei log (build.purge). Paraglide ottiene questo risultato a livello architetturale, poiché una funzione di messaggio non richiamata viene rimossa tramite tree-shaking. Tutte le altre soluzioni lasciano la pulizia a vostro carico.

Developer experience.

Tempo di configurazione fino alla prima stringa tradotta, un LSP o un'estensione VS Code che mostri la traduzione al passaggio del mouse (hover) e rimandi alla dichiarazione, una CLI per compilazione (fill), test e push, e una soluzione che permetta a chi non è sviluppatore di modificare i contenuti (editor visuale o CMS) senza aprire una pull request.

Domande frequenti

Per approfondire

• Benchmark Vue i18n: bundle size, leakage e tempi di cambio lingua
• Vue i18n: come funziona vue-i18n e dove mostra i suoi limiti e l'articolo su Nuxt i18n
• vue-i18n vs Intlayer, funzionalità per funzionalità e il benchmark vue-i18n vs Intlayer
• vue-i18n è superato?
• La storia dell'i18n in JavaScript
• Compilatore vs i18n dichiarativo
• i18n per componente vs centralizzato
• Configurare l'i18n in un'app Vite + Vue e in un'app Nuxt
• La stessa guida per React, Svelte e Solid