Autor:
    Aymeric PINEAU
    Creación:2026-09-16Última actualización:2026-09-16

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

    El modelo de reactividad de Solid cambia lo que una librería de i18n debe hacer. Los componentes se ejecutan una sola vez, por lo que una traducción almacenada en una const durante el setup es una cadena fija (frozen string), y una librería que entrega cadenas en lugar de accessors producirá una página que cambia de idioma en todas partes excepto en los tres componentes donde alguien hizo eso. Elegir una librería para Solid trata en parte sobre la API y en parte sobre cuál hace que ese error sea difícil de cometer.

    Esta guía enumera las preguntas que debes responder primero, y luego las relaciona con @solid-primitives/i18n, solid-i18next, Paraglide, @lingui/solid e Intlayer, tanto para Vite + Solid como para SolidStart.

    Ecosistema de librerías Solid i18n

    Tabla de contenidos

    Seis preguntas a responder antes de comparar librerías

    1. ¿Vite SPA o SolidStart? En una SPA, el locale puede residir en un signal y nada más. En SolidStart, el locale debe resolverse en el servidor a partir de la URL, y todo lo que un crawler deba ver sin JavaScript (<html lang>, hreflang) corresponde a entry-server.tsx.
    2. ¿Qué tan reactivo debe ser el cambio de locale? Una recarga completa de la página al cambiar de idioma es aceptable para algunas aplicaciones. Si no es así, los valores de la librería deben ser signals o accessors, y su lectura debe ser rastreada (tracked), no copiada.
    3. ¿Quién escribe las traducciones? Desarrolladores, un TMS, una agencia que entrega cadenas en formato ICU o un pipeline de IA. solid-i18next utiliza el formato de i18next. @solid-primitives/i18n utiliza el formato que tenga tu objeto de diccionario. Adáptate al proveedor.
    4. ¿Cuántos locales y páginas? Dos locales y cinco páginas pueden permitirse enviar todo. Diez locales y cuarenta rutas no pueden, y los catálogos lazy junto con el scoping se convierten en el coste principal.
    5. ¿Necesitas tipado en las claves? @solid-primitives/i18n los infiere del diccionario fuente. solid-i18next requiere una declaración manual. Las librerías en tiempo de compilación los generan.
    6. ¿Cuánta superficie de funcionalidades necesitas? Gestión de cookies, enrutamiento con prefijo de locale, redirecciones, formateadores. La opción más ligera no incluye nada de esto, y eso está bien hasta que deja de estarlo.

    Anota las respuestas. Todo lo que sigue hace referencia a ellas.

    El panorama en una imagen

    Solid es el ecosistema más joven aquí y cuenta con la menor cantidad de opciones, distribuidas en tres olas.

    Historia de las librerías de i18n en JavaScript

    i18next adaptado para Solid. Namespaces, backends, detectores y una década de plugins. La opción más pesada del conjunto, con los mismos costes de t("a.b") que en React.

    Un diccionario plano que tú controlas, un translator() que devuelve accessors y tipos inferidos del objeto fuente. Muy pequeño, sin scoping, sin enrutamiento ni formateadores. La opción por defecto de la comunidad.

    Paraglide genera una función por mensaje. Intlayer declara el contenido por componente en archivos .content.ts y devuelve nodos respaldados por signals. La integración de Lingui con Solid llegó en 2026 y aporta su extracción basada en macros.

    El post sobre la historia de la i18n en JavaScript cubre cada ola en detalle.

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

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

    • Contenido centralizado o con scoping. Un solo diccionario para la aplicación, o una declaración por componente.
    • Importación estática o dinámica. Todo al inicio, o el locale 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 1 a 10 locales, con unos 30 KB de texto por página.

    Fuga teórica de contenido por arquitectura

    @solid-primitives/i18n no hace nada respecto a ninguno de los dos ejes: utilizas createResource para cargar un diccionario por locale, lo que te da carga dinámica, y el resto corre por tu cuenta. solid-i18next cuenta con namespaces y backends lazy, pero nada impone el mapeo, por lo que un componente compartido que importa common lo convierte en una dependencia de cada ruta. Paraglide aborda el eje de las páginas mediante tree-shaking, aunque no tuvo efecto en la implementación del benchmark de Solid. Intlayer lo logra mediante declaraciones por componente.

    Si tu respuesta a la pregunta 4 fue "muchas páginas", dale más peso a esta sección que a cualquier preferencia de API. El artículo sobre i18n por componente vs centralizada cubre el aspecto de mantenimiento de este mismo compromiso.

    Las opciones candidatas

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

    LibreríaModelo de contenidoReactividad al cambiar de localeTipado en clavesScoping y carga lazyTamaño de la librería
    @solid-primitives/i18nDiccionario plano propioSignal, accessors retornados por translatorInferido del diccionario fuenteNinguno integradoMuy pequeño
    solid-i18nextCatálogos y namespaces de i18nextStore, re-render mediante providerDeclaración manualNamespaces, backends lazy~14.9 kB
    ParaglideProyecto inlang, funciones generadasLectura por llamada de cookie o storageGeneradoTree-shaking (no en bench)Casi cero
    @lingui/solidTexto fuente en código, catálogos compiladosBasado en signalsDesde el compiladorPor catálogoPequeño
    IntlayerUn .content.ts por componenteNodos con signals, sin re-render del componenteGenerado, activado por defectoSí, por componenteLínea base (Baseline)
    Las cifras son una instantánea en las versiones del benchmark. @lingui/solid no formaba parte del benchmark. Pruébalo en tu propia app antes de decidir solo por el tamaño.

    El tamaño de librería casi nulo de Paraglide es por diseño: el runtime se genera dentro de tu repositorio. Intlayer necesita vite-intlayer, por lo que no puede ejecutarse sin un paso de build.

    Relaciona tus respuestas con una librería

    @solid-primitives/i18n. Un diccionario plano, un translator() que devuelve accessors y tipos inferidos sin configuración extra. Es la respuesta adecuada para una app pequeña, y leer el código fuente toma diez minutos. Lo que tendrás que escribir tú mismo: persistencia del locale, enrutamiento, formateadores y división por rutas (route splitting). Si estas listas crecen, esa es la señal para cambiar.

    solid-i18next te permite reutilizar catálogos, namespaces, backends y detectores tal como están. Es la opción más pesada y conlleva los mismos costes que react-i18next: declaración manual de tipos, optimizaciones que son posibles pero requieren tiempo, y un t() que devuelve una cadena, por lo que el error de traducción congelada es fácil de cometer. Envuelve las lecturas en JSX o en un memo y nunca las almacenes durante el setup.

    El locale debe provenir de la URL en el servidor para que ambos lados coincidan; detectarlo en el cliente es demasiado tarde. @solid-primitives/i18n y solid-i18next dejan la ruta [[locale]], matchFilters, la redirección y las etiquetas de entry-server.tsx en tus manos. Paraglide cuenta con un plugin de Vite que gestiona el enrutamiento. Intlayer incluye middleware y helpers de ruta. Elijas la que elijas, coloca <html lang> y hreflang en entry-server.tsx; @solidjs/meta se aplica en el cliente tras la hidratación en SolidStart v2. El artículo sobre i18n en Solid detalla esa configuración.

    Elige una librería cuyos valores sean signals o accessors y cuyas lecturas sean rastreadas. Los accessors de @solid-primitives/i18n y los nodos de Intlayer solo actualizan los nodos del DOM que los leen, sin volver a ejecutar los componentes. solid-i18next vuelve a renderizar a través del provider. Paraglide lee el locale desde cookies o storage en cada llamada de mensaje en lugar de hacerlo desde un signal, lo cual funciona pero hace más trabajo por nodo del que debería.

    Contenido con scoping compilado en tiempo de build. Intlayer solo envía lo que una ruta renderiza. Paraglide debería lograrlo mediante tree-shaking; verifícalo en tu configuración, ya que no lo hizo en la del benchmark. Con solid-i18next, planifica la estrategia de namespaces y carga lazy desde el primer día y hazla cumplir en las revisiones de código.

    @solid-primitives/i18n te ofrece tipos inferidos de forma gratuita, lo cual es más de lo que ofrecen la mayoría de las librerías de React. Para tipos generados que sobrevivan a la carga lazy y a la división por rutas, Paraglide, @lingui/solid e Intlayer los producen a partir del contenido. El artículo sobre detección de traducciones faltantes compara lo que detecta cada una en tiempo de build.

    Entonces un diccionario centralizado ya no tiene ningún destinatario que lo justifique. El contenido coubicado junto con una CLI que rellene los locales faltantes es el camino más directo. El comando fill de Intlayer se ejecuta contra tu propia clave de API (OpenAI, Anthropic, Mistral, Gemini) y solo vuelve a traducir lo que ha cambiado.

    Dónde se queda corta cada librería

    • @solid-primitives/i18n: sin carga lazy ni scoping más allá de lo que construyas, sin enrutamiento, sin manejo de cookies ni formateadores. Excelente para apps pequeñas, rápidamente insuficiente para proyectos profesionales.
    • solid-i18next: la más pesada del grupo, tipos manuales, su propio formato de plurales y t() devuelve una cadena, por lo que las traducciones se congelan si se almacenan en el setup.
    • Paraglide: archivos generados commiteados en el repositorio y regenerados antes de cada push, el tree-shaking no tuvo efecto en el benchmark de Solid y el locale se lee del storage por llamada en lugar de un signal.
    • @lingui/solid: nueva en 2026, por lo que aún hay poco feedback de producción. Hereda el paso de build extract / compile de Lingui y sus múltiples sintaxis superpuestas.
    • Intlayer: plugin de build obligatorio, ecosistema más pequeño, soporte parcial de ICU y contenido distribuido por el codebase por diseño, por lo que exportar un único JSON para un traductor requiere herramientas.

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

    El mismo componente, un resumen de carrito con un título y un plural, escrito con cada candidata. Observa dónde se lee la traducción: en JSX se rastrea, en el cuerpo del setup es una cadena fija.

    src/i18n/index.ts
    import * as i18n from "@solid-primitives/i18n";

export const en = {
  cart: { title: "Your cart", items: "{{ count }} items" },
};

export const dictionary = () => i18n.flatten(en);
export const t = i18n.translator(dictionary, i18n.resolveTemplate);
    src/components/CartSummary.tsx
    import type { Component } from "solid-js";
import { t } from "../i18n";

export const CartSummary: Component<{ count: number }> = (props) => (
  <section>
    <h2>{t("cart.title")}</h2>
    <p>{t("cart.items", { count: props.count })}</p>
  </section>
);

    Las claves se tipan a partir del objeto en inglés sin generación de código. No hay regla de plurales, ni carga lazy ni enrutamiento; cada uno corre por tu cuenta añadirlos.

    public/locales/en/cart.json
    {
  "title": "Your cart",
  "items_one": "{{count}} item",
  "items_other": "{{count}} items"
}
    src/components/CartSummary.tsx
    import { useTransContext } from "@mbarzda/solid-i18next";
import type { Component } from "solid-js";

export const CartSummary: Component<{ count: number }> = (props) => {
  const [t] = useTransContext();

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

    Catálogos, namespaces y plugins de i18next tal como son. t devuelve una cadena, por lo que const title = t("cart:title") en el setup la congela; mantén la llamada dentro de JSX.

    messages/en.json
    {
  "cart_title": "Your cart",
  "cart_items": "{count} items"
}
    src/components/CartSummary.tsx
    import type { Component } from "solid-js";
import { m } from "../paraglide/messages.js";

export const CartSummary: Component<{ count: number }> = (props) => (
  <section>
    <h2>{m.cart_title()}</h2>
    <p>{m.cart_items({ count: props.count })}</p>
  </section>
);

    Cada mensaje es una función generada y tipada. El locale se lee de la cookie o storage en cada llamada en lugar de un signal, por lo que la reactividad al cambiar de idioma queda a tu cargo.

    src/components/cartSummary.content.ts
    import { type Dictionary, plural, t } from "intlayer";

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

export default cartSummaryContent;
    src/components/CartSummary.tsx
    import { useIntlayer } from "solid-intlayer";
import type { Component } from "solid-js";

export const CartSummary: Component<{ count: number }> = (props) => {
  const content = useIntlayer("cart-summary");

  return (
    <section>
      <h2>{content.title}</h2>
      <p>{content.items(props.count)}</p>
    </section>
  );
};

    Todos los locales en un solo archivo junto al componente. useIntlayer devuelve nodos respaldados por signals, por lo que un cambio de locale solo actualiza los nodos del DOM que los leen. {content.title} en JSX se rastrea; content.title.value en el cuerpo del setup no.

    En una base de código i18next existente, el adaptador de compatibilidad de i18next crea un alias del paquete a nivel de bundler para que los catálogos y t() sigan funcionando mientras Intlayer sirve el contenido, y la guía de migración cubre el resto.

    Antes de comprometerte

    Una tabla de características te dice lo que una librería hace hoy. Estos puntos te dicen cómo será convivir con ella.

    Revisa la actividad del repositorio.

    Commits, tiempo de respuesta a issues y si la última versión menor fue este año. Un diseño sólido sin mantenedor es una migración en espera.

    No elijas por descargas de npm.

    La librería más instalada es la que se lanzó primero, no la que encaja en un codebase de Solid en 2026. Las descargas miden la historia, no el ajuste.

    Clasificación de librerías de i18n en JavaScript

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

    i18next (detrás de solid-i18next) está respaldada por Locize. next-intl, vue-i18n, svelte-i18n y Lingui están respaldadas por Crowdin. Tolgee, Paraglide (inlang) e Intlayer operan cada una su propia plataforma. Un proveedor cuyos ingresos provienen del alojamiento de traducciones tiene pocos incentivos para hacer que la traducción sea gratuita dentro de tu toolchain. Intlayer es la única del grupo que incluye traducción por IA mediante CLI con tu propia clave de API y un CMS que puedes autoalojar.

    ¿Está preparada para agentes de IA?

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

    Seguridad de tipos lista para usar.

    No "puede tiparse 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 locale al que le falta una traducción.

    Detección de contenido no utilizado.

    Los catálogos solo crecen. El build de Intlayer purga los campos no utilizados y los registra (build.purge). Paraglide lo logra por arquitectura, ya que una función de mensaje no invocada se elimina mediante tree-shaking. Todas las demás te dejan la limpieza a ti.

    Experiencia de desarrollo (Developer Experience).

    Tiempo de configuración hasta la primera cadena traducida, un LSP o extensión de VS Code que muestra la traducción al pasar el cursor y salta a la declaración, una CLI para rellenar, probar y hacer push, y una forma para que los no desarrolladores editen contenido (editor visual o CMS) sin necesidad de un pull request.

    Preguntas frecuentes

    Para una pequeña, sí, y es la opción más ligera disponible. Deja de ser suficiente cuando necesitas catálogos lazy por ruta, enrutamiento por locale en SolidStart, persistencia en cookies o formateadores, ya que todo eso tendrás que construirlo tú.

    Porque los componentes de Solid se ejecutan una sola vez. Una traducción leída en una const durante el setup es una cadena plana, no una suscripción. Léela dentro de JSX, un effect o un memo, o elige una librería cuyos valores sean accessors para que la versión incorrecta sea más difícil de escribir.

    Solo si el tamaño del bundle, los tipos generados o las comprobaciones de claves faltantes en tiempo de build son requisitos reales. El artículo sobre i18n por compilador vs declarativa explica lo que te aportan los compiladores y dónde pueden fallar.

    Indirectamente. A los crawlers les importa el enrutamiento, hreflang, <html lang> y si el texto está en el HTML renderizado por el servidor, lo que en SolidStart significa entry-server.tsx. Consulta la guía de hreflang.

    Para ir más lejos

    Elegir bibliotecas i18n para SvelteNext.js

    Comentarios

    Aún no hay comentarios. Sé el primero en compartir tus pensamientos.

    Artículos relacionados

    Significado de i18n: ¿Qué es la internacionalización y por qué es importante?

    Descubre el verdadero significado de i18n en el desarrollo de software. Aprende qué es la internacionalización, por qué se abrevia como i18n y cómo impacta en el alcance global.

    Aymeric PINEAU

    i18next vs Intlayer: Benchmark y comparativa 2026

    react-i18next y next-i18next evaluados frente a Intlayer en Next.js y TanStack Start. Tamaño del bundle, fuga de contenido, reactividad al cambiar de idioma y experiencia de desarrollo.

    Aymeric PINEAU

    React Router i18n - locale routes that get indexed

    How to add locale-prefixed routes in React Router v7, why the answer differs between framework mode and SPA mode, and how to avoid hydration mismatches.

    Aymeric PINEAU

    Plataforma L10n alternativa a Phrase

    Encuentra la mejor plataforma L10n alternativa a Phrase para tus necesidades

    Aymeric PINEAU

    Últimos artículos

    Cómo elegir la librería de i18n adecuada para React en 2026

    Una guía de decisión para la internacionalización en React. Qué preguntas responder antes de comparar react-i18next, react-intl, Lingui, use-intl, Paraglide e Intlayer, y qué cuesta cada opción en tamaño de bundle, tipado y mantenimiento.

    Aymeric PINEAU

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

    Una guía de decisión para la internacionalización en Vue y Nuxt. Qué preguntas responder antes de comparar vue-i18n, @nuxtjs/i18n, fluent-vue, Paraglide e Intlayer, y qué cuesta cada opción en bundle size, tipado y SSR payload.

    Aymeric PINEAU

    Cómo elegir la librería de i18n adecuada para Svelte en 2026

    Una guía de decisión para la internacionalización en Svelte y SvelteKit. Qué preguntas responder antes de comparar svelte-i18n, Paraglide, typesafe-i18n, wuchale e Intlayer, y qué cuesta cada opción en tamaño de bundle, tipado y seguridad en SSR.

    Aymeric PINEAU

    next-intl vs Intlayer: Benchmark y Comparación 2026

    Tamaño del bundle, fuga de contenido, reactividad del cambio de idioma y experiencia del desarrollador medidos en Next.js y TanStack Start. ¿Qué librería i18n deberías elegir en 2026?

    Aymeric PINEAU