¿Qué es ICU MessageFormat, y por qué sigue siendo tan difícil de traducir?

ICU MessageFormat es un estándar Unicode para escribir una única cadena traducible que se adapta según el número, el género y otras variables, y sigue siendo difícil de traducir porque su sintaxis se diseñó para el código, no para las personas que lo localizan. La especificación lleva más de una década existiendo, y quienes más tropiezan con ella son traductores sin perfil técnico enfrentándose a llaves anidadas. globalize.now es infraestructura de localización impulsada por IA que se sitúa una capa por debajo de este problema: extrae las cadenas y genera los archivos de traducción donde viven estos patrones ICU, y luego los mantiene sincronizados en cada push a Git.

¿Qué es ICU MessageFormat?

ICU MessageFormat es una sintaxis para expresar un mensaje cuyo redactado final depende de datos en tiempo de ejecución. En lugar de concatenar fragmentos en el código, escribes un único patrón y dejas que el formateador elija la rama correcta según el idioma.

El uso más habitual es la pluralización:

{count, plural,
  one {You have # message}
  other {You have # messages}
}

El # se reemplaza por el número, y las ramas one / other se corresponden con las categorías de plural de cada idioma. El inglés tiene dos; el polaco, el ruso y el árabe tienen más. ICU también gestiona el género y otras opciones mediante select:

{gender, select,
  male {He liked your post}
  female {She liked your post}
  other {They liked your post}
}

Por eso ICU se convirtió en el estándar de facto para la pluralización: traslada la complejidad gramatical a datos que pueden variar según el idioma, en lugar de meterla en lógica condicional que solo funciona para el idioma en el que se escribió. Bibliotecas en tiempo de ejecución como FormatJS, i18next y next-intl la entienden todas.

¿Por qué es tan difícil de traducir ICU MessageFormat?

Es difícil de traducir porque su sintaxis se construyó para desarrolladores, y quienes realmente traducen las cadenas normalmente no lo son.

Un traductor que abre un archivo de traducción no ve «Tienes 3 mensajes.» Ve llaves, las palabras clave plural y select, categorías de plural que quizá no reconozca, y un marcador de posición # que parece un error tipográfico. Basta con borrar una llave o renombrar una categoría para que la cadena lance un error en tiempo de ejecución en lugar de renderizarse. La estructura que hace potente a ICU para los ingenieros es la misma que lo hace frágil en manos de un lingüista.

Esta es la brecha con la que la industria de la localización ha convivido en silencio durante años. La mayoría de las herramientas la gestionan mostrando el patrón en bruto y esperando que el traductor no toque el carácter equivocado, o escondiendo las formas de plural detrás de un editor separado que igualmente exige que el traductor entienda las categorías de plural. Ningún proveedor ha cerrado del todo la distancia entre la complejidad de la especificación y el modelo mental de un traductor sin perfil técnico.

¿Qué cambió con MessageFormat 2.0?

MessageFormat 2.0 es un rediseño completo de la sintaxis, y en 2025 pasó de ser un borrador a convertirse en un estándar estable.

MF2 alcanzó el estado de Final Candidate en marzo de 2025 y ahora forma parte estable de CLDR, publicado dentro del estándar técnico Unicode LDML y refinado a través de las versiones LDML 47 y 48. La implementación de referencia sigue la especificación a partir de la versión LDML 48.2, publicada a comienzos de 2026. La nueva sintaxis separa las entradas de la lógica de coincidencia y admite funciones de formato con nombre, lo que hace que los mensajes complejos sean más legibles:

.input {$count :number}
.match $count
one {{You have {$count} message}}
*   {{You have {$count} messages}}

La intención es lograr un patrón más fácil de extender y algo menos hostil de leer que las llaves anidadas originales.

¿MessageFormat 2.0 soluciona el problema del traductor?

Todavía no, por dos razones.

En primer lugar, MF2 mejora la ergonomía de la sintaxis, pero sigue siendo sintaxis. Un traductor sigue encontrándose con .match, claves de plural y llaves. La carga cognitiva es menor que en MF1, pero no ha desaparecido, y un traductor sin perfil técnico todavía puede romper un mensaje editando el token equivocado.

En segundo lugar, casi nadie lo está usando en producción. La adopción sigue siendo limitada bien entrado 2026: el proceso de TC39 para el lado de JavaScript quiere ver alrededor de una docena de organizaciones usando MF2 en producción antes de avanzar más, y ese umbral todavía no se ha alcanzado. En la práctica, la mayoría de las apps que lanzas hoy siguen funcionando sobre el ICU MessageFormat original a través de bibliotecas como FormatJS e i18next. Así que el problema de cara al traductor no lo resuelve una especificación; lo resuelve el lugar donde se genera y mantiene la sintaxis.

¿Dónde falla ICU MessageFormat en las apps generadas por IA?

Falla pronto, porque las herramientas de IA para programar rara vez generan ICU correcto de entrada.

Cuando construyes con Cursor, Claude Code o Lovable, el código generado tiende a gestionar los conteos de la forma ingenua:

// What an AI coding tool often generates
const label = count + " " + (count === 1 ? "message" : "messages");

Esa lógica es correcta para el inglés e incorrecta para la mayoría de los demás idiomas, porque asume exactamente dos formas de plural. También incrusta la frase directamente en el código de la aplicación, así que no queda ningún patrón ICU en un archivo de traducción que un traductor pueda localizar. La cadena es invisible para la capa de localización hasta que alguien nota la gramática incorrecta en producción. Las herramientas de IA también duplican claves y dispersan texto codificado por los componentes, así que incluso los equipos que quieren usar ICU acaban con cadenas que nunca llegaron a un archivo traducible. La visión general para desarrolladores de globalize.now está construida precisamente para detectar este tipo de cadena antes de que se lance.

¿Cómo deberían gestionar los desarrolladores ICU MessageFormat en 2026?

Trata ICU como infraestructura generada, no como contenido escrito a mano.

La regla práctica: los desarrolladores y las herramientas de IA no deberían escribir concatenación de plurales en el código, y los traductores no deberían editar a mano las llaves de ICU en bruto. El patrón ICU pertenece a un archivo de traducción que se genera y se mantiene actualizado automáticamente, y que luego se renderiza en tiempo de ejecución mediante una biblioteca como FormatJS, i18next o next-intl. Eso mantiene la sintaxis correcta en el momento en que se crea y consistente en todos los idiomas a medida que la app cambia. Si estás valorando cómo encaja ICU frente a tu capa de runtime, la comparativa de globalize.now frente a i18next explica cómo se reparten el trabajo la infraestructura y el runtime.

Esta es la capa en la que opera globalize.now. Extrae las cadenas codificadas de tu codebase, genera las claves y los archivos de traducción donde viven los patrones ICU, y los resincroniza en cada push a Git, de modo que la estructura se mantiene correcta sin ningún paso de exportación manual. No pretende ser el editor del traductor ni sustituir tu biblioteca de runtime; se asegura de que los archivos con forma ICU de los que dependen esas herramientas existan realmente y se mantengan sincronizados. La guía para vibe coders recorre la misma configuración para apps creadas con Lovable, Bolt y Replit, y el flujo de trabajo completo está en la página de inicio de globalize.now.