blog de 18ways

i18n está roto: deja de escribir claves de traducción

Una forma nativa de IA de hacer i18n en Next.js, sin romper el SEO.

La internacionalización (a menudo abreviada como i18n), la localización (l10n) y el soporte multilingüe describen la misma idea: adaptar tu producto para que las personas puedan usarlo en su propio idioma.

i18n sigue estando construido como si fuera de 2005

Toda empresa acaba por darse cuenta de que necesita admitir varios idiomas. En ese momento, el equipo de producto se echa hacia atrás como un mecánico, aspira aire entre los dientes y dice: «¿De cuántas páginas estamos hablando? Eso son, como mínimo, cuatro sprints».

Una reacción de tipo mecánico al coste y al esfuerzo del trabajo tradicional de i18n

La forma subyacente en que implementamos i18n no ha cambiado en 20 años. La mayoría de las «mejores prácticas» de i18n se formaron mucho antes de las arquitecturas web modernas, y todo lo demás desde entonces no ha hecho más que construirse encima de ellas.

La i18n es la única parte del desarrollo web moderno que todavía implica exportar archivos y enviárselos a alguien. Se considera una configuración moderna si, en lugar de enviarlos por correo electrónico, los subes mediante una API.

En un mundo de pipelines de CI y despliegues medidos en minutos en lugar de días, probablemente deberíamos darnos por afortunados de no tener que enviar nada por fax.

Por qué i18n parece estar roto

El desarrollo web moderno ha avanzado increíblemente rápido.

Tenemos:

Aun así, los flujos de trabajo de internacionalización siguen pareciendo de otra época.

Incluso las aplicaciones relativamente pequeñas acaban enseguida haciendo malabares con:

Los desarrolladores no se ponen a construir sistemas así. Acaban tropezando con ellos, cuando los obstáculos habituales de la i18n hacen caer a quienes no están familiarizados con cómo lenguas distintas estructuran las oraciones de forma completamente diferente… y aceptan a regañadientes el statu quo establecido hace 20 años.

Con el tiempo, la internacionalización se convierte en una de las partes más complejas del stack.

La UI moderna no cabe dentro de las cadenas de traducción

Considera una interfaz de usuario sencilla:

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

Esto es fácil de entender. Es simple.

En algún momento decidimos internacionalizarlo. Así que extraemos el texto a un archivo de traducción:

json
{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

Y lo referenciamos en nuestro código:

jsx
<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

Pero espera, ¿ahora tenemos texto en inglés tanto en nuestro código como en nuestro archivo de traducción? Sí. Distintas bibliotecas de i18n le ponen distinto color, pero intentar traducir texto que está parcialmente formateado extrayéndolo a un archivo JSON legible por humanos es una batalla perdida.

La interfaz moderna está estructurada, pero los sistemas de traducción se construyen sobre la base de cadenas planas.

En cuanto entran en juego el marcado, las variables y el contenido dinámico, la abstracción empieza a tener fugas.

El contenido dinámico y generado por el usuario rompen la i18n tradicional

Las cosas se complican aún más cuando el contenido no es estático.

Tomemos este ejemplo de nuevo:

jsx
<b>{serverResponse.productDescription}</b>

Esa cadena viene de una API. ¿Cómo la convertimos en una clave de traducción?

Sorpresa: no lo haces. Ahora tu backend también necesita admitir la internacionalización.

Tu backend ahora debe gestionar:

De repente, los traductores también necesitan acceso a los sistemas de backend.

Y el problema solo crece cuando entra en escena el contenido generado por el usuario.

Reseñas. Comentarios. Anuncios del marketplace. Foros.

Los flujos tradicionales de i18n dan por hecho que los desarrolladores controlan todo el texto. Cada vez más, eso simplemente no es cierto.

El hecho de que empresas como Amazon hayan empezado a experimentar con reseñas de usuarios traducidas en 2026 dice mucho sobre lo despacio que ha evolucionado el ecosistema de i18n.

La detección de la configuración regional sigue siendo un desastre

Incluso determinar qué idioma quiere un usuario resulta sorprendentemente complicado.

Los navegadores envían las preferencias de idioma mediante la cabecera Accept-Language:

text
Accept-Language: en-GB,en;q=0.9,fr;q=0.8

Esto le dice al servidor:

  1. Preferir el inglés británico
  2. Luego cualquier forma de inglés
  3. Entonces cualquier forma de francés

En la práctica, implementarlo correctamente implica:

Muchos frameworks dejan la mayor parte de esta lógica en manos de los desarrolladores.

Incluso la detección básica de la configuración regional a menudo acaba convirtiéndose en código personalizado de la aplicación.

Cambiar de idioma es una idea tardía

La infraestructura de traducción es solo la mitad del problema.

Los usuarios siguen necesitando una forma de cambiar de idioma.

La mayoría de las bibliotecas de i18n proporcionan la capa de traducción, pero dejan el resto del problema en manos del desarrollador:

Estos detalles suenan pequeños, pero pronto se convierten en una cantidad considerable de trabajo interno de la aplicación, sobre todo si no estás familiarizado con todos los entresijos de la i18n. La mayoría de las empresas y desarrolladores no lo están.

El atajo: traducción automática de sitios web

Dada toda esta complejidad, algunos equipos recurren a herramientas automáticas de traducción de sitios web. Estas plataformas prometen traducir tu sitio automáticamente con un esfuerzo mínimo.

Varias empresas están construyendo versiones cada vez más sofisticadas de esta idea. Por desgracia, introducen otro conjunto de problemas:

El resultado suele ser un sitio que, técnicamente, admite varios idiomas, pero ofrece una experiencia notablemente peor y es una caja negra para los desarrolladores.

Cómo llegamos hasta aquí

Empezamos con algo maravillosamente simple:

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

Y acabó con claves de traducción, diccionarios JSON, pipelines fragmentados, capas de localización de backend y frontend separadas, y herramientas de traducción externas.

Las aplicaciones web modernas son sistemas increíblemente sofisticados. Sin embargo, las herramientas de i18n esperan flujos de trabajo diseñados para otra época, como un Ferrari al que hay que dar arranque con una manivela.

Replantearse el modelo

¿Y si la internacionalización se pareciera más a esto?

jsx
<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

Sin claves de traducción.

Sin diccionarios JSON.

Sin flujos manuales.

Solo texto.

Un enfoque diferente

Esta idea es la base de 18ways.

18ways trata la traducción como una cuestión de ejecución optimizada. Extraer claves de traducción y gestionar archivos de traducción es un problema para las máquinas, no para las personas.

Los desarrolladores simplemente marcan el texto que quieren traducir.

Entre bastidores, 18ways:

Todo sigue siendo compatible con SSR y seguro para SEO.

Traducciones sensibles al contexto

Los sistemas tradicionales de i18n pierden el contexto.

Un traductor podría ver algo como esto:

text
home

Pero, ¿qué significa eso?

En alemán, estos significados requieren palabras completamente distintas:

Si tuvieras que traducir «home» al alemán, ¿qué preferirías ver? ¿Una cadena aislada o la página en la que realmente aparece?

Comparación entre traducir una cadena JSON aislada y traducirla dentro del contexto completo del sitio web

Los sistemas de traducción que solo ven cadenas aisladas tienen dificultades con estas distinciones.

18ways analiza las traducciones en el contexto de la UI real.

Nuestros agentes de backend revisan las traducciones tal como aparecen en páginas reales y optimizan para:

Para quien esté familiarizado con los sustantivos compuestos alemanes, no os preocupéis: la detección de desbordamiento también está incluida.

Dando poder a los traductores humanos

Todo lo que ayuda a la IA a producir mejores traducciones también ayuda a los traductores humanos.

18ways ofrece a los traductores el mismo entorno con contexto que usan nuestros agentes de IA.

En lugar de editar archivos JSON, los traductores revisan el texto directamente frente a la UI en la que aparece.

Esto mejora de forma espectacular la precisión de las traducciones y la eficiencia del flujo de trabajo.

Cómo es una mejor i18n

La internacionalización no necesita otra capa de claves de traducción, archivos de cadenas ni pegamento de pipeline.

Las aplicaciones modernas ya tienen la estructura, el contexto y la información en tiempo de ejecución que necesitamos para hacerlo mejor.

La siguiente generación de i18n debería estar pensada para aplicaciones renderizadas en servidor, contenido dinámico, flujos de trabajo nativos de IA y traductores humanos trabajando codo con codo.

Esa es la dirección que está tomando 18ways.

Cambiando idioma