Internacionalización (i18n): diseñar para varios idiomas desde el inicio
La internacionalización (i18n) prepara un producto para varios idiomas, formatos y direcciones de texto antes de traducirlo. Aprende qué incluye y qué evitar.
¿Qué es la internacionalización?
El W3C la define en la práctica como diseñar y desarrollar el producto para que la localización sea fácil. La localización, en cambio, es la adaptación al idioma, la cultura y los requisitos de un mercado concreto. Si la internacionalización se omite, cada mercado nuevo se convierte en un proyecto de reconstrucción.
Apple lo describe en términos parecidos: separar el código de la interfaz y del texto, para que las traducciones no requieran cambiar la lógica de la app.
¿Por qué le importa a un diseñador?
Porque la mayoría de los problemas de internacionalización son visuales y aparecen en el diseño. Un botón que mide 120 píxeles con “Guardar” puede romperse con su equivalente más largo. Un diseño que alinea todo a la izquierda se ve raro en árabe o hebreo. Una fecha escrita como “03/04” significa cosas distintas según el país.
Además, la internacionalización exige que el diseño tenga una lógica que no dependa del idioma de origen. Eso es un buen ejercicio para cualquier diseñador, aunque la app nunca salga de un solo país.
¿Qué incluye?
La internacionalización se suele agrupar en cinco áreas:
| Área | Qué significa | Ejemplo |
|---|---|---|
| Texto | Separar las cadenas del código y usar codificación Unicode (UTF-8 salvo razón fuerte) | Un archivo de traducciones por idioma |
| Formatos | Mostrar fechas, horas, números y monedas según la convención del idioma | “1.234,56” frente a “1,234.56” |
| Dirección | Soportar idiomas de derecha a izquierda y declarar el idioma y la dirección | Un menú que se invierte en árabe |
| Expansión | Dejar espacio para textos más largos | Un botón que crece al traducirse |
| Cultura | Revisar iconos, colores, símbolos y referencias | Un gesto o una imagen con otro sentido |
El W3C incluye en su lista de revisión la ordenación localmente relevante, la normalización de texto y la captura de idioma y dirección en los formularios.
¿Cómo se diseña para la dirección del texto?
Una de las decisiones más útiles es usar propiedades lógicas en lugar de propiedades fijas. MDN explica que las propiedades lógicas usan los ejes de bloque (block) y de línea (inline) en lugar de izquierda y derecha. Así, un margen definido como inicio de línea se adapta solo cuando el texto se escribe de derecha a izquierda.
MDN añade que así el contenido traducido a idiomas con otros modos de escritura se muestra como se pretendía.
Para diseñadores, la idea se traduce a pensar en “inicio” y “final” en vez de “izquierda” y “derecha”. Un icono de flecha que apunta hacia adelante debe invertirse en un idioma de derecha a izquierda, pero una flecha de reloj o de play no suele hacerlo. Esa distinción debe estar documentada.
¿Qué conviene acordar con ingeniería?
Antes de diseñar pantallas, acuerda cuatro puntos:
- Dónde viven los textos. Apple describe separar el texto visible del código ejecutable, de modo que exportar traducciones no obligue a modificar el código fuente.
- Quién da formato a fechas, números y monedas. Apple pide expresar correctamente por idioma fechas, longitudes, pesos, precios y símbolos de moneda; usa las utilidades de la plataforma en vez de formatear a mano.
- Cómo se declaran el idioma y la dirección. El listado del W3C pide metadatos y soporte para ambos.
- Cómo se prueba. Apple recomienda planes de prueba que detecten recortes, truncamientos, superposiciones y errores en idiomas de derecha a izquierda.
¿Cuándo empezar?
Desde el diseño. El W3C indica que la internacionalización debe ser un paso fundamental desde el diseño, y que adaptarla después suele ser mucho más difícil y lento. Si tu producto ya existe, empieza por lo que más duele: textos fijos en imágenes, fechas con formato propio y layouts con alturas fijas.
¿Cuándo NO hace falta?
Si el producto es una herramienta interna para un solo país y un solo idioma, no vale la pena construir un sistema complejo de i18n. Lo sensato es mantener la separación básica del texto y los formatos, que cuesta poco, y dejar el resto para cuando haya un mercado real.
Ejemplo
Ejemplo ilustrativo: una app de pedidos muestra el total con el símbolo de moneda y el formato escrito a mano en cada pantalla: “$ 1234.5”. Al entrar en Colombia, el equipo descubre que el formato no respeta separadores ni decimales de la moneda local. La solución no es traducir cada pantalla; es centralizar el formato de números y moneda en una sola función que use la convención del idioma. Desde ese día, cada pantalla nueva hereda el formato correcto.
Errores comunes
- Escribir textos dentro de los componentes, que obliga a tocar el código en cada idioma.
- Diseñar con alturas y anchos fijos que no toleran textos más largos.
- Concatenar frases a partir de fragmentos, porque el orden de las palabras cambia entre idiomas.
- Escribir fechas y monedas a mano en lugar de usar el formato del idioma.
- Usar flechas y posiciones fijas sin pensar en la dirección del texto.
- Dejar la internacionalización para “después”, cuando el diseño ya está cerrado.
Si quieres seguir el camino completo, la estrategia de localización de producto muestra qué decidir antes de traducir, y RTL y localización de la UI profundiza en los idiomas de derecha a izquierda. Para el sistema que sostiene estas decisiones, el sistema de diseño es el lugar donde conviene documentarlas.