i18n: La guía esencial para la internacionalización del software

Resume este post con: 9 minutos de lectura

ChatGPT Perplejidad Grok Inteligencia artificial de Google

La internacionalización (i18n) es el trabajo que se realiza en código para que un producto pueda adaptarse a cualquier idioma o región sin ser rediseñado. El W3C lo define como “el diseño y desarrollo de un producto, aplicación o contenido de documento que permita una fácil localización para audiencias objetivo que varían en cultura, región o idioma” (W3C). En la práctica, eso significa Unicode en todas partes, sin cadenas codificadas orientadas al usuario, formato de fechas, números y plurales que tenga en cuenta la configuración regional y diseños que sobrevivan a textos más largos y scripts de derecha a izquierda.

Conclusiones clave

• i18n es ingeniería; la localización (l10n) es la adaptación a un mercado que i18n hace posible. El “18” y el “10” cuentan las letras entre la primera y la última letra de cada palabra.
• Los cinco hábitos que previenen la mayoría de los errores de i18n: UTF-8 de extremo a extremo, cadenas externalizadas, manejo de variables y plurales estilo ICU, API de formato local de la plataforma y diseños flexibles.
• Nunca construyas oraciones concatenando fragmentos. El orden de las palabras y las reglas plurales difieren demasiado entre idiomas.
• Pruebe con pseudolocalización antes de que un traductor vea las cadenas.
• Un sitio web que ya está activo y no fue creado para i18n aún se puede hacer multilingüe en la capa de renderizado, sin refactorizar el código base.

i18n, l10n y g11n: la diferencia

El W3C enumera lo que la internacionalización normalmente incluye: eliminar barreras a la localización (Unicode y codificación de caracteres), admitir funciones como texto bidireccional, admitir convenciones locales para fechas, calendarios, números y nombres, y “separar elementos localizables del código fuente” para que se cargue la versión correcta para cada usuario (W3C).

A continuación se muestra una prueba sencilla para determinar si el trabajo de i18n está realizado: para agregar un nuevo idioma se necesitan traductores y alguna configuración. Si necesita un desarrollador, se pasó por alto algo.

1. Utilice Unicode (UTF-8) de extremo a extremo

UTF-8 es el valor predeterminado para la web, utilizado por el 99,1% de los sitios web cuya codificación de caracteres es conocida (W3Techs, 28 de septiembre de 2026). Hoy en día los errores rara vez aparecen en el HTML. Suceden en las capas que lo rodean:

• Columnas de base de datos y conexiones que no están configuradas en UTF-8 completo. În MySQL, utf8 es un subconjunto de 3 bytes; usar utf8mb4 o se perderán emoji y algunos personajes de CJK.
• Funciones de cadena que cuentan bytes en lugar de caracteres, lo que trunca “Zürich” o “東京” en medio de un carácter.
• Exportaciones CSV abiertas en software de hoja de cálculo con codificación incorrecta.
• Ordenar con orden de bytes en lugar de intercalación local, lo que coloca “Äpfel” después de “Zebra”.

Declarar la codificación una vez (<meta charset="utf-8">), configúrelo en cada conexión y utilice una comparación que tenga en cuenta la configuración regional, como Intl.Collator en JavaScript.

2. Externalizar cada cadena orientada al usuario

Las cadenas que ven los usuarios pertenecen a archivos de recursos, codificados por un identificador. Mantenlos fuera de plantillas y códigos:

{
  "cart.title": "Your cart",
  "cart.empty": "Your cart is empty",
  "cart.checkout": "Go to checkout"
}

Cada configuración regional obtiene su propio archivo y el código lo solicita cart.title. Los marcos siguen el mismo patrón: en Vue, la biblioteca vue-i18n expone $t para “traducción de mensajes locales” y $i18n para la instancia global que administra locales y mensajes (documentos vue-i18n). React (react-intl, i18next), Angular (@angular/localize), Django, Rails y Laravel envían un equivalente.

Algunas reglas que ahorran dolor más adelante:

• Dar contexto a los traductores. “Abrir” puede ser un verbo (abrir el archivo) o un adjetivo (la tienda está abierta). Añade una descripción a cada clave.
• No reutilice una clave sólo porque el texto en inglés coincida. “Guardar” en un botón y “Guardar 20%” en un banner son mensajes diferentes en la mayoría de los idiomas.
• Mantenga el marcado fuera de las cadenas donde pueda, o use marcadores de posición para ello, para que los traductores no puedan romper su HTML.

3. Nunca concatene oraciones; utilice marcadores de posición y reglas plurales

Esto parece inofensivo:

'You have ' + count + ' new messages';

Se rompe de dos maneras. El orden de las palabras cambia entre idiomas y las reglas plurales no lo son “1 frente a todo lo demás”. Las reglas plurales Unicode CLDR dan al inglés dos categorías cardinales (una, otra), al japonés una, al ruso y al polaco cuatro (una, pocos, muchos, otra) y al árabe seis (cero, uno, dos, pocos, muchos, otro) (CLDR Unicode).

Utilice un formato de mensaje que conozca esas reglas, como ICU MessageFormat:

{count, plural,
  =0 {You have no new messages}
  one {You have # new message}
  other {You have # new messages}}

Un traductor ruso puede entonces añadir el few y many formularios sin ningún cambio en su código. Lo mismo se aplica al género, a los números ordinales (“1o, 2o”) y a las listas (“A, B y C”).

4. Deje que la plataforma formatee fechas, números y moneda

03/04/2026 es el 4 de marzo en Estados Unidos y el 3 de abril en la mayor parte de Europa. 1,234.5 en inglés se escribe 1.234,5 en alemán y 1 234,5 en francés. No escribas tu propio formato. Cada plataforma moderna tiene datos locales integrados y en JavaScript es el Intl API (MDN):

new Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(1234.5);
// "1.234,50 €"

new Intl.DateTimeFormat('fr-FR', { dateStyle: 'long' }).format(new Date('2026-09-27'));
// "27 septembre 2026"

Vale la pena tomar algunas decisiones relacionadas con anticipación:

• Almacene la hora en UTC y conviértala a la zona horaria del usuario para su visualización.
• Mantenga la moneda separada de la local. Un visitante francófono en Canadá paga en CAD, no en EUR. Formatear un número como moneda es i18n; decidir el precio es una decisión comercial.
• No asumas cómo se forman los nombres y las direcciones. Muchas personas no tienen “nombre” y “apellido” en el sentido occidental y los códigos postales no siempre son numéricos.

5. Diseñe diseños que se estiren y volteen

El texto traducido suele ser más largo que el inglés y las cadenas cortas son las que más crecen. El W3C resume las cifras orientativas de IBM: las cadenas de hasta 10 caracteres pueden crecer entre un 200 y un 300% en los idiomas europeos, mientras que el texto de más de 70 caracteres crece hasta aproximadamente un 130% (W3C, Tamaño del texto en la traducción). Su ejemplo es el italiano que convierte “vistas” en “visualizzazioni”.

Para el trabajo de interfaz de usuario, eso significa:

• No hay botones ni pestañas de ancho fijo dimensionados para etiquetas en inglés.
• No hay texto integrado en las imágenes. No se puede traducir sin volver a dibujar la imagen.
• Soporte escrituras de derecha a izquierda (árabe, hebreo, persa, urdu) con dir="rtl" en el <html> elemento y propiedades lógicas CSS (margin-inline-start en lugar de margin-left), por lo que el diseño se refleja a sí mismo.
• Elija fuentes que cubran los scripts que planea admitir o defina alternativas.

6. Manejar deliberadamente la detección de configuración regional y las URL

Decidir cómo se elige la configuración regional de un usuario y cómo se recuerda:

1. Una elección explícita (un selector de idioma) siempre gana.
2. De lo contrario, utilice el navegador Accept-Language encabezado como sugerencia, no como redirección forzada.
3. Coloque la configuración regional en la URL (/de/, de.example.com) para cualquier página pública, de modo que los motores de búsqueda puedan compartir, almacenar en caché e indexar cada versión de idioma. Las cookies por sí solas hacen que las páginas traducidas sean invisibles para Google.

Si el producto tiene páginas públicas, las URL de esos idiomas también necesitan anotaciones hreflang; consulte el guía hreflang.

7. Prueba con pseudolocalización

La pseudolocalización reemplaza sus cadenas de origen con una versión alterada antes de que exista cualquier traducción real, por ejemplo [Ýöûŕ çåŕţ îš éɱþţý !!!!]. Los acentos detectan problemas de codificación, el relleno detecta diseños que se rompen debajo de texto más largo y los corchetes revelan truncamiento y cualquier cadena codificada que no haya cambiado. Muchas bibliotecas y herramientas de compilación de i18n pueden generar una pseudolocal; ejecute su conjunto de pruebas de interfaz de usuario en cada versión.

Agregue estos a su lista de verificación también:

• Cambie a una configuración regional RTL y verifique la navegación, los íconos con dirección (flechas, barras de progreso) y la alineación del formulario.
• Pruebe la clasificación y la búsqueda con caracteres acentuados.
• Revise correos electrónicos, archivos PDF, mensajes de error y notificaciones push, que a menudo se olvidan.

Una lista de verificación i18n para nuevos proyectos

• UTF-8 (utf8mb4 en MySQL) en archivos, bases de datos, conexiones y API
• Todas las cadenas orientadas al usuario en archivos de recursos, con contexto para traductores
• ICU MessageFormat (o equivalente) para plurales, género y variables
• Intl o las API locales de la plataforma para fechas, números, moneda, listas y clasificación
• Almacenamiento UTC y visualización de zona horaria por usuario
• Diseños flexibles, propiedades lógicas CSS, dir soporte de atributos
• Localizar en la URL de páginas públicas, hreflang para motores de búsqueda
• Pseudolocalización en IC

Cuando el sitio web ya existe

Todo lo anterior se aplica a una aplicación que estás creando. Para un sitio de marketing, una tienda o un CMS que ya está activo, significa una gran refactorización y el equipo propietario del contenido generalmente no es el equipo propietario del código.

En ese caso, la traducción puede realizarse en la capa de renderizado. ConveyThis lee el texto que su sitio ya genera, lo traduce a cualquiera de los 210 idiomas y sirve a cada idioma en su propia URL (subcarpeta o subdominio en el plan de negocios y superior, o a ?lang parámetro) con hreflang agregado automáticamente. Los idiomas de derecha a izquierda cambian la dirección del texto, las imágenes se pueden reemplazar por idioma y a Glosario y memoria de traducción mantener consistentes los nombres y términos de los productos. Se instala como Complemento de WordPress, una aplicación Shopify o un solo script en cualquier otra pila, para que el trabajo de i18n en su base de código pueda continuar según su propio cronograma. Para conocer el aspecto comercial de adaptar el contenido a cada mercado, lea nuestra guía sobre qué implica la localización de contenidos.

Preguntas frecuentes

¿Por qué la internacionalización se abrevia i18n? Hay 18 letras entre la primera “i” y la última “n” en “internacionalización”. La localización (l10n) sigue el mismo patrón.

¿i18n es lo mismo que traducción? No. La traducción es una parte de la localización. i18n es la ingeniería que permite que la traducción y cualquier otra adaptación local se realicen sin cambios de código.

¿Cuándo debe iniciarse un proyecto i18n? Al principio. Externalizar cadenas y utilizar API locales cuesta poco el primer día y mucho cuando se adapta a una base de código madura.

Qué es $i18n ¿en Vue? En vue-i18n, $i18n es la instancia global que gestiona locales y mensajes, y $t es la función que devuelve un mensaje traducido para una clave (vue-i18n).

Siguiente paso

Si necesita un sitio web en vivo en varios idiomas antes de que el código base esté completamente internacionalizado, crear una cuenta ConveyThis y publica tu primer idioma, luego compara planes cuando agregues más.