Guia tecnica para implementar i18n y l10n en aplicaciones web modernas
Un repaso a las trampas comunes en la internacionalizacion: desbordamiento de memoria con traducciones, formateo de monedas y manejo de plurales condicionales.
La internacionalizacion (i18n) y la localizacion (l10n) siguen siendo uno de los puntos de fallo mas frecuentes cuando un producto software escala a mercados globales. Un error en la presentacion de datos, como mostrar un formato de fecha equivocado o una moneda incorrecta, no es solo un problema estetico: es la forma mas rapida de perder la confianza del usuario y, por extension, del negocio.
El autor del articulo en Lobsters discucion parte de un caso hipotetico desastroso: un usuario estadounidense reservando un hotel en la India ve un precio de "1.12.107,43" (formato indio de lakh/crore) en lugar de un equivalente en dolares canadienses, junto con texto en hindi que no entiende. La solucion no es solo traducir, sino adaptar el contexto: moneda, idioma de interfaz y formatos de fecha.
A nivel de arquitectura, la regla de oro es simple: nunca codificar cadenas visibles para el usuario en el codigo base. Todo debe pasar por una funcion de localizacion. Un error comun es cargar todos los archivos JSON de traducciones en la memoria al inicio. A medida que la app crece, ese "bundle" de idiomas se infla descontroladamente. La recomendacion es cargar los diccionarios bajo demanda o usar estrategias de tree-shaking para importar solo los locales necesarios.
La complejidad escala rapidamente con los plurales y las condiciones. Poner un "if" en el markup para añadir una "s" al final de una palabra es una mala practica que ensucia el codigo. Lo correcto es delegar esa logica a la capa de traducciones, usando claves que acepten parametros numericos y devuelvan la estructura gramatical correcta segun el idioma objetivo. Cada lengua tiene sus propias reglas de pluralizacion que van mucho mas alla de singular y plural.
El diseno de la interfaz también debe ser flexible. El japones o el coreano pueden ocupar mucho mas espacio visual que el ingles para la misma frase. Usar anchos fijos en los componentes garantiza que el texto se corte o se desborde en algunos locales. Es mejor usar sistemas de layout que expandan el contenedor con los margenes adecuados y permitan que el texto envuelva a la siguiente linea si es necesario.
El formateo de numeros es otra fuente de bugs silenciosos. Los separadores decimales y de miles varian drasticamente: mientras en Estados Unidos el punto separa miles y la coma decimales, en la Union Europea ocurre a la inversa. En la India se usa un sistema de dos comas para los primeros grupos de tres y luego de dos digitos (lakh y crore). El codigo debe normalizar los valores en el backend (por ejemplo, siempre en USD y formato float estandar) y dejar que la capa de presentacion aplique el formato segun las preferencias del usuario.
Finalmente, el manejo de fechas y zonas horarias requiere precision. Mostrar una hora de check-in sin especificar la zona horaria (UTC, IST, local del usuario) genera ambiguedad operativa. El sistema debe permitir al usuario elegir su moneda y formato de fecha independientemente de su geolocalizacion, respetando la privacidad y las preferencias explicitas, ya que un usuario en Japon puede preferir leer en ingles.
