Cómo elegir la librería de i18n adecuada para Vue

"Vue i18n" es tanto un término genérico como el nombre de la librería que casi todo el mundo instala. Esto es conveniente y engañoso al mismo tiempo: vue-i18n es un valor predeterminado aceptable, pero no es la única opción, y las preguntas que deberían guiar la elección (¿SSR o no?, ¿cuántas páginas?, ¿quién escribe las traducciones?) rara vez se hacen antes de ejecutar npm install.

Esta guía las plantea primero, y luego mapea las respuestas a las librerías que encajan, tanto para Vite + Vue puro como para Nuxt.

Tabla de contenidos

Seis preguntas a responder antes de comparar librerías

1. ¿Vite SPA o Nuxt? En una SPA, el coste del catálogo es un problema de bundle de JS. En Nuxt también es un problema de payload HTML, porque los mensajes se serializan en el estado de SSR y se hidratan. La mayoría de los reportes de "vue-i18n es lento" provienen de aplicaciones Nuxt por esta razón.
2. ¿Quién escribe las traducciones? Desarrolladores, un TMS, una agencia que entrega cadenas ICU o un pipeline de IA. vue-i18n utiliza su propia sintaxis de plural separada por barras verticales (|), no ICU. Esto importa si las cadenas provienen del exterior.
3. ¿Cuántos idiomas y páginas? Dos idiomas y cinco páginas pueden enviar todo de una vez. Diez idiomas y cuarenta rutas no pueden, y la estrategia de carga se convierte en el coste principal.
4. ¿Necesitas tipado en las claves? t("cart.totl") compila en vue-i18n a menos que pases un genérico de esquema de mensajes, y ese esquema entra en conflicto con catálogos cargados de forma perezosa (lazy loading).
5. ¿Qué contiene el contenido? Solo etiquetas de UI, o markdown, enlaces dentro de oraciones y bloques por idioma. El contenido enriquecido es donde t() devolviendo un string se vuelve incómodo.
6. ¿Es CSP una restricción? La build predeterminada de vue-i18n compila mensajes en el navegador con new Function. Las builds solo de runtime necesitan @intlify/unplugin-vue-i18n para precompilar en tiempo de build.

Apunta las respuestas. Todo lo siguiente hará referencia a ellas.

El panorama en una imagen

El ecosistema de Vue tiene menos librerías de i18n que React, y provienen de diferentes olas arquitectónicas.

El artículo sobre la historia de la i18n en JavaScript cubre cada ola en detalle.

La decisión más importante: dónde vive el contenido y cuándo se carga

Dos decisiones estructurales explican la mayor parte de la diferencia de bundle entre configuraciones:

• Contenido centralizado o por componente. Un único locales/en.json para toda la aplicación, o una declaración por componente.
• Importación estática o dinámica. Todo al inicio, o el idioma activo (e idealmente la ruta activa) cargado bajo demanda.

El gráfico estima el payload para una aplicación teórica de 1 a 10 páginas, traducida a entre 1 y 10 idiomas, con aproximadamente 30 KB de texto por página.

vue-i18n admite el eje dinámico: usar setLocaleMessage tras un import() evita enviar nueve idiomas que nadie lee. Lo que no ofrece es el eje por página. Un catálogo de idioma es un único objeto, y cargarlo carga los textos de todas las páginas. En una SPA nadie lo nota. En Nuxt, con @nuxtjs/i18n y más de diez páginas, cada ruta transporta las cadenas de todas las demás rutas, dos veces: en el chunk de JS y en el payload de SSR.

El benchmark de Vue mide esto como "fuga de otras rutas" y "fuga de otros idiomas". Si tu respuesta a la pregunta 3 fue "muchas páginas", esta sección pesa más que cualquier preferencia de API. El artículo sobre i18n por componente vs centralizada cubre el aspecto de mantenimiento de este mismo dilema.

Las candidatas

Los tamaños de las librerías provienen del benchmark de Vue: plugin más composable en un componente vacío, tras empaquetado, tree-shaking y minificación, en una aplicación de 10 páginas y 10 idiomas. El contenido se mide por separado.

Las cifras corresponden a una instantánea de las versiones del benchmark. Ejecútalo en tu propia aplicación antes de decidir solo por el tamaño.

El tamaño casi nulo de Paraglide es por diseño: el runtime se genera en tu repositorio, lo que implica un paso de regeneración antes de cada push y posibles conflictos de merge en archivos generados. Intlayer requiere vite-intlayer (o el módulo de Nuxt), por lo que no puede funcionar sin un paso de build.

Empareja tus respuestas con una librería

Dónde se queda corta cada librería

• vue-i18n: la más pesada del grupo, formato de plural propio, los tipos son opcionales y frágiles con lazy loading, sin división por ruta automática, las claves huérfanas se acumulan silenciosamente. Dejar legacy: true en una aplicación de Vue 3 mantiene la capa de compatibilidad con Vue 2 y pierde el tipado de useI18n().
• @nuxtjs/i18n: hereda todo lo anterior, y el payload de SSR transporta las cadenas de todas las páginas en cuanto se superan una docena de rutas.
• fluent-vue: buena sintaxis de mensajes, sin tipado de claves, y el plugin de Vite carga todo el contenido en todos los idiomas en cada página. La más pesada en el benchmark.
• Paraglide: archivos generados commiteados en el repositorio, regeneración antes de cada push, y el idioma se lee de cookies o almacenamiento en cada llamada de mensaje en lugar de un store reactivo, lo que añade trabajo en el cambio de idioma.
• Intlayer: plugin de build obligatorio, ecosistema más reducido, soporte parcial de ICU y contenido distribuido por la codebase por diseño, por lo que exportar un único JSON para un traductor requiere herramientas adicionales.

Cómo se ve cada opción en código

El mismo componente, un resumen del carrito con un título y un plural, escrito con cada candidata. La parte interesante no es la plantilla, sino dónde reside el contenido y qué sabe vue-tsc sobre él.

{
  "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({ es: "Tu carrito", en: "Your cart", fr: "Votre panier" }),
    items: t({
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
    }),
  },
} 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>

¿Ya usas vue-i18n? El adaptador de compatibilidad @intlayer/vue-i18n crea un alias del paquete a nivel de empaquetador, de modo que useI18n(), $t, los plurales con barras y v-t siguen funcionando mientras Intlayer sirve el contenido. La guía de migración explica cómo dejar de usar el adaptador más adelante, y también hay una específica para Nuxt.

Antes de comprometerte

Una tabla de características te dice qué hace una librería hoy. Estos puntos te dicen cómo será convivir con ella en el día a día.

Revisa la actividad del repositorio.

Commits, tiempo de respuesta a issues y si la última versión menor fue lanzada este año. Un buen diseño sin mantenedor es una futura migración asegurada.

No elijas solo por las descargas de npm.

La librería más instalada es la que se lanzó primero, no necesariamente la que mejor se adapta a una codebase de Vue en 2026. Las descargas miden la historia, no el ajuste a tus necesidades.

Pregunta quién financia al mantenedor y qué venden.

vue-i18n está respaldada por Crowdin, al igual que next-intl y svelte-i18n. i18next está respaldada por Locize. Tolgee, Paraglide (inlang) e Intlayer operan cada una su propia plataforma. Un proveedor cuyos ingresos dependen de la traducción alojada tiene pocos incentivos para que la traducción sea gratuita dentro de tu cadena de herramientas. Intlayer es la única del grupo que ofrece traducción mediante IA a través de la CLI con tu propia API key, y un CMS que puedes auto-hospedar.

¿Está preparada para agentes de IA?

Los agentes todavía tienen dificultades con la i18n: olvidan idiomas, inventan claves y mezclan sintaxis de mensajes. ¿La librería incluye Agent Skills o un servidor MCP para que el agente pueda listar, completar y probar contenido? ¿Y la carga de contenido está optimizada por defecto, o alguien tiene que revisar namespaces e imports diferidos cada trimestre?

Tipado estricto listo para usar.

No "se puede tipar con configuración adicional", sino "una clave incorrecta hace fallar tsc en una instalación limpia". Comprueba qué sucede con una clave que no existe y con un idioma al que le falta una traducción.

Detección de contenido no utilizado.

Los catálogos solo crecen. La build de Intlayer purga campos no utilizados y los registra (build.purge). Paraglide lo consigue por arquitectura, ya que una función de mensaje no invocada se elimina mediante tree-shaking. Las demás dejan la limpieza en tus manos.

Experiencia de desarrollo (DX).

Tiempo de configuración hasta la primera cadena traducida, un LSP o extensión de VS Code que muestre la traducción al pasar el cursor y salte a la declaración, una CLI para completar, probar y subir traducciones, y una forma para que personas no técnicas editen contenido (editor visual o CMS) sin necesidad de abrir un pull request.

Preguntas Frecuentes

Para profundizar

• Benchmark de Vue i18n: tamaño del bundle, fugas y tiempos de cambio de idioma
• Vue i18n: cómo funciona vue-i18n y dónde se queda corta y el artículo sobre Nuxt i18n
• vue-i18n vs Intlayer, característica por característica y el benchmark de vue-i18n vs Intlayer
• ¿Está desactualizado vue-i18n?
• La historia de la i18n en JavaScript
• i18n basada en compilador vs declarativa
• i18n por componente vs centralizada
• Configurar i18n en una aplicación Vite + Vue y en una aplicación Nuxt
• Misma guía para React, Svelte y Solid