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 afectar el SEO.

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

i18n todavía está construida como si fuera 2005

Toda empresa acaba por darse cuenta de que necesita dar soporte a varios idiomas. En ese punto, el equipo de producto se recarga como un mecánico, chupa aire entre los dientes y dice: “¿Cuántas páginas estamos hablando? Eso son por lo menos cuatro sprints.”

Una reacción, al estilo mecánico, ante el costo y el esfuerzo del trabajo tradicional de i18n

La forma fundamental 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 que ha venido después simplemente se ha ido sumando encima de ellas.

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 mandarlos por correo, los subes a través de 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 mandar nada por fax.

Por qué la i18n se siente rota

El desarrollo web moderno ha avanzado de forma increíblemente rápida.

Tenemos:

Sin embargo, los flujos de trabajo de internacionalización todavía parecen pertenecer a otra era.

Incluso las aplicaciones relativamente pequeñas acaban rápidamente haciendo malabares con:

Los desarrolladores no se proponen construir sistemas así. Se tropiezan con ellos, mientras los obstáculos comunes de i18n hacen tropezar a desarrolladores que no están familiarizados con cómo distintos idiomas estructuran las oraciones de maneras completamente diferentes... 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 de la pila.

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

Considera una interfaz de usuario simple:

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 distintos adornos, pero intentar traducir texto que está parcialmente formateado sacándolo a un archivo JSON legible para humanos es una batalla perdida.

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

Una vez que el marcado, las variables y el contenido dinámico entran en juego, la abstracción empieza a hacer agua.

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

Las cosas se ponen aún más difíciles cuando el contenido no es estático.

Tomemos este ejemplo otra vez:

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

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

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

Tu backend ahora debe gestionar:

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

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

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

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

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

La detección de configuraciones regionales sigue siendo un desastre

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

Los navegadores envían las preferencias de idioma a través del encabezado Accept-Language:

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

Esto le dice al servidor:

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

En la práctica, implementar esto correctamente implica:

Muchos marcos dejan gran parte de esta lógica en manos de los desarrolladores.

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

El cambio de idioma es algo secundario

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 al desarrollador:

Estos detalles parecen pequeños, pero rápidamente se convierten en una cantidad significativa de la fontanería de la aplicación, especialmente si no estás familiarizado con todas las complejidades de 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 da soporte a varios idiomas, pero ofrece una experiencia notablemente peor y es una caja negra con la que los desarrolladores tienen que trabajar.

Cómo acabamos aquí

Empezamos con algo bellamente simple:

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

Y terminó con claves de traducción, diccionarios JSON, flujos de trabajo fracturados, capas de localización separadas para backend y frontend, y herramientas externas de traducción.

Las apps 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 con una manivela para arrancar el motor.

Repensar el modelo

¿Y si la internacionalización se viera más así?

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

No hay claves de traducción.

No diccionarios JSON.

Sin canalizaciones manuales.

Solo texto.

Un enfoque diferente

Esta idea es la base detrás de 18ways.

18ways trata la traducción como una preocupación de tiempo de ejecución optimizada. Extraer claves de traducción y administrar archivos de traducción es un problema para las máquinas, no para los humanos.

Los desarrolladores simplemente marcan el texto que quieren traducir.

Detrás de escena, 18ways:

Todo sigue siendo compatible con SSR y seguro para SEO.

Traducciones con contexto

Los sistemas tradicionales de i18n pierden el contexto.

Un traductor podría ver algo así:

text
home

Pero, ¿qué significa eso?

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

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 traducir 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 interfaz de usuario real.

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

Para cualquiera que esté familiarizado con los sustantivos compuestos alemanes, no se preocupe, la detección de desbordamiento también está incluida.

Potenciando a los traductores humanos

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

18ways proporciona a los traductores el mismo entorno contextual que usan nuestros agentes de IA.

En lugar de editar archivos JSON, los traductores revisan el texto directamente en la interfaz de usuario donde aparece.

Esto mejora de forma drástica la precisión de la traducción y la eficiencia del flujo de trabajo.

Cómo se ve una mejor internacionalización

La internacionalización no necesita otra capa de claves de traducción, archivos de cadenas y pegamento de la canalización.

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

La próxima generación de i18n debería estar hecha para apps renderizadas en servidor, contenido dinámico, flujos de trabajo nativos de IA y traductores humanos trabajando codo a codo.

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

Cambiando idioma
i18n está roto: Deja de escribir claves de traducción | Blog de 18ways