La internacionalización (i18n) es la arquitectura del código que permite adaptar un producto a distintos mercados, mientras que la localización (l10n) es lo que el usuario final percibe: idioma, formatos de fecha, moneda, números y convenciones culturales. Un sitio de reservas que muestra precios, fechas y cancelaciones en el formato equivocado puede hacer que el cliente abandone la compra, como ilustra el ejemplo de un turista estadounidense en Canadá intentando reservar un hotel en Jaipur: malinterpretar el sistema numérico indio (lakh y crore), no reconocer la moneda en dólares canadienses o confundir DD/MM con MM/DD son errores que cuestan conversiones.
El artículo repasa las decisiones técnicas fundamentales para soportar l10n: no hardcodear textos visibles, organizarlos en archivos JSON por claves e idiomas, evitar cargarlos todos en memoria, y permitir siempre que el usuario cambie manualmente el idioma de la interfaz. Explica también cómo gestionar plurales y gramática mediante condiciones dentro de las propias traducciones, dejar que los componentes crezcan con el texto en lugar de fijar anchos rígidos, y tratar el texto RTL (árabe, hebreo) y CJK (japonés, chino, coreano) con sus particularidades, incluida la validación cuando un usuario CJK escribe en mitad de un campo en inglés.
Dedica una sección amplia a números y monedas: los separadores de miles y decimales varían (coma, punto, espacio, sistema lakh-crore), la posición del símbolo de moneda cambia y algunas divisas tienen un símbolo local distinto del internacional, como el yen. Subraya la importancia de formatear siempre cantidades mediante una función y de permitir al usuario elegir la moneda. Cierra con formatos de fecha y hora (DD/MM frente a MM/DD, 12h frente a 24h, husos horarios explícitos), el primer día de la semana, el orden del nombre (apellido-nombre en Japón y China) y las direcciones, con sus códigos postales y equivalentes administrativos (estado, provincia, prefectura, óblast, emirato).