Internationalization

Diseñar capacidad de adaptación

Internationalization es aquí diseñar y desarrollar software para que pueda adaptarse a lenguas, scripts, regiones y convenciones culturales sin rediseñar su comportamiento central para cada locale. Es una definición de trabajo del Atlas, no un modelo de datos universal. La abreviatura habitual es i18n; localization suele abreviarse l10n. El nombre de una biblioteca no define ninguna de las dos.

W3C Internationalization distingue preparar capacidad de adaptación y producir una experiencia localizada para determinada audiencia. Traducción es una actividad de localization, junto con formatos, contenido, convenciones y presentación. Separar strings ayuda, pero no corrige automáticamente modelos de dirección, nombres, importes o fechas construidos sobre supuestos de un solo mercado.

El concern atraviesa requirements, diseño, contenido, APIs, interacción, pruebas y mantenimiento. No es una capa agregada antes de publicar ni significa soportar toda cultura o idioma imaginable. Delimitar audiencias y capacidades requeridas permite decisiones explícitas, sin tratar las restricciones iniciales como verdades universales del software.

Lengua, locale y selección de contexto

Una lengua no es un país y una región puede contener múltiples lenguas. Una bandera identifica un territorio, no inequívocamente un idioma. Locale suele incorporar lengua y convenciones relevantes de región, script o preferencias; no existe un único objeto Locale obligatorio. La lengua por sí sola no determina moneda de transacción, calendario o zona horaria.

Estas preguntas separan datos que pueden coincidir, sin obligarlos a hacerlo:

Dato	Pregunta propia
Lengua del contenido	¿En qué lengua está expresada esta información?
Locale de representación	¿Qué convenciones se utilizan para mostrarla?
Moneda del compromiso	¿Qué unidad monetaria tiene el importe de negocio?
Zona temporal	¿Qué reglas convierten un instante a tiempo local pertinente?

BCP 47 reúne RFC 5646 para identificar lenguas y RFC 4647 para matching. Tags ilustrativos: en, inglés; en-GB, inglés con subtag regional británico; es-AR, español con región Argentina; zh-Hant, chino en script tradicional. No usar country codes como sustituto de identificadores de lengua ni agregar precisión que no aporte información necesaria. Un tag tampoco garantiza comprensión entre toda pareja de hablantes.

Selección puede considerar preferencia explícita, perfil, browser/dispositivo, organización, URL y lengua del contenido, con precedencia decidida por producto. Accept-Language es una señal de preferencia lingüística, no evidencia de nacionalidad, ubicación o moneda deseada. GPS e IP tampoco explican automáticamente qué formato entiende o prefiere una persona; permitir revisar inferencias evita imponer una elección incorrecta.

client-state-management conserva selección y lifecycle de preferencias; persistir entre sesiones o dispositivos requiere contexto de identidad y reglas de producto. synchronization puede intercambiar esa preferencia sin volver autoridad comercial toda representación localizada. Preferencia de UI y contenido solicitado pueden diferir: abrir un documento en otra lengua no necesariamente cambia la configuración permanente de la cuenta.

Lenguaje declarado y dirección de texto

Para Web, declarar lenguaje en HTML ayuda a interpretar contenido y pronunciación; cambios de lengua dentro del documento pueden necesitar declaración propia. Lengua, audiencia de un recurso y configuración de formatting son datos relacionados, no intercambiables. Un header no sustituye indiscriminadamente metadata del contenido visible.

La dirección depende del script, no de la lengua en abstracto: algunas lenguas utilizan más de uno. lang identifica lenguaje; dir expresa dirección base en HTML. Declarar árabe no establece por sí solo dir="rtl". Esta distinción evita inferencias escondidas cuando scripts, recursos y contexto cambian durante navegación.

Texto bidireccional combina contenido RTL/LTR, números, URLs y códigos. El algoritmo Unicode y el contexto de markup influyen en el orden mostrado; orden lógico almacenado y presentación no son la misma cosa. No resolverlo invirtiendo strings o el DOM arbitrariamente. Tampoco RTL significa reflejar todo icono: interpretar finalidad y contexto de cada representación.

Diseño debe tolerar expansión, line breaks y distintas necesidades tipográficas. Probar una captura espejada no demuestra lectura, selección, navegación ni foco correctos. En este canonical se explican los problemas sin muestras de texto RTL ni markup especial: no se requiere extender el Portable Markdown Contract para documentarlos.

Texto Unicode y significado de comparación

Unicode define caracteres, code points y algoritmos/datos asociados; no es una fuente ni una lengua. UTF-8 es una codificación de code points Unicode, no sinónimo del estándar completo. W3C recomienda UTF-8 para contenido Web; declarar una codificación no transforma bytes guardados con otra. Fronteras cliente/servidor y persistencia necesitan conservar texto sin reinterpretaciones incompatibles.

UAX #29 explica grapheme clusters, aproximaciones a caracteres percibidos por usuarios. Un emoji compuesto o una letra con marca combinante puede ocupar varios code points; longitud en code units tampoco equivale necesariamente a ese conteo. Límites de formularios, cursor y truncamiento necesitan semántica definida, sin suponer ancho fijo ni «un carácter = un code point».

Normalización Unicode trata representaciones equivalentes mediante secuencias diferentes. Puede importar para comparación o búsqueda, pero no prescribe una transformación idéntica para cualquier dato. Conservar representación original puede ser necesario; identificar qué equivalencia necesita el dominio antes de modificar información recibida evita pérdida o colisiones inesperadas.

Case mappings tienen matices lingüísticos y contextuales. No generalizar reglas ASCII a nombres y texto humano. Collation organiza comparación y ordenación; orden binario/code-point puede diferir de expectativas lingüísticas. Search añade decisiones sobre acentos, case, script o transliteración: collation no es toda la semántica de búsqueda.

Identificadores técnicos necesitan sus propias reglas de igualdad, case y Unicode. No aplicar conversión dependiente del locale de pantalla a un product code o username sin contrato pertinente. La igualdad lingüística que ayuda a buscar nombres puede ser incorrecta para unicidad de identificadores. Backend y cliente deben acordar comparación y orden cuando afectan paginación o resultados, sin asumir «ordenar todo en cliente».

Datos mantenidos, formatos y mensajes

CLDR / UTS #35 proporciona datos y reglas de locales: lenguas, formatos, calendarios, unidades, collation y nombres, entre otros. Es infraestructura de datos/especificación, no arquitectura completa de aplicación. Utilizar datos mantenidos evita reconstruir supuestos culturales; elegir una biblioteca no decide ownership, fallback ni qué variante requiere el producto.

Los formatos numéricos y monetarios pueden cambiar separadores, agrupación y sistema de numeración. Parsing de entrada no debe depender de reemplazos arbitrarios de puntos/comas. Moneda e importe son datos de negocio: formatting decide representación, no convierte divisas ni define automáticamente reglas comerciales de redondeo. Locale puede orientar presentación sin determinar moneda de la orden.

Fechas, horas y calendarios requieren primero significado. Cumpleaños puede ser fecha de calendario sin timezone; timestamp de pago, un instante; cita, fecha/hora local y zona. 10/11/2026 no expresa un significado universal. La base IANA mantiene reglas históricas y cambios políticos: un offset UTC no es una zona horaria ni predice todos sus offsets futuros.

Calendario gregoriano y sistema de unidades usado por un equipo no representan a todos los usuarios. Elegir calendarios y unidades visibles según requisitos, sin exigir todas las opciones. Representación interna puede diferir de display; cambiar kilómetros por millas en UI no autoriza cambiar silenciosamente el significado almacenado ni el contrato de una API.

Las reglas de plural CLDR no se reducen a singular para uno y plural para lo demás. Mensajes estructurados permiten seleccionar e interpolar según cantidad y contexto; concatenar fragmentos de gramática inglesa impide reordenamiento natural. Eso no exige una biblioteca específica ni que una propuesta reciente de MessageFormat esté implementada en toda plataforma.

Los nombres de personas no encajan universalmente en firstName/lastName. Direcciones varían en campos, orden, códigos postales y divisiones administrativas. Requisitos legales o de entrega pueden exigir datos concretos sin volverlos un formulario global válido para todo contexto. Separar captura, validación, representación y dato autoritativo permite adaptar sin perder significado.

Representación, recursos y fronteras

rendering-strategies sitúa decisiones de locale antes de SSR, durante generación de variantes estáticas o en cambio dinámico cliente. SSR puede necesitar contexto de URL/perfil/request; generación previa aumenta variantes, build e invalidación; cambiar locale runtime puede recargar mensajes, reformatar y cambiar dirección. Ninguna ubicación es universalmente correcta.

Si servidor y cliente representan el mismo dato con locale, zona o datos de formatting distintos, pueden aparecer resultados inconsistentes al activar UI. Definir qué contexto se conserva y qué cambia evita atribuir todo desacuerdo al framework. backend-for-frontend puede adaptar contenido o transportar datos crudos; no adquiere por definición ownership de toda localization. data-ownership mantiene autoridad de importe, moneda y estado comercial.

web-performance incorpora fuentes, language packs, imágenes localizadas y fragmentación de cache. Variación debe reflejar dimensiones semánticas de la respuesta: reusar una variante equivocada puede ser rápido y erróneo. No colapsar lenguas para mejorar un hit ratio ni descargar todas las variantes por defecto. Balancear experiencia correcta, recursos y reutilización con evidencia.

URL, perfil, cookie y negociación por headers son opciones de selección, sin jerarquía universal. Locale en URL cambia routing, compartición, cache y canonicalización de direcciones. Fallback necesita política explícita cuando falta contenido: es-AR no obliga a caer en es-ES. Elegir recurso alternativo, fuente original o indisponibilidad según significado; mostrar una key interna accidentalmente no constituye una política útil.

Fallback de mensaje, formato y contenido completo pueden necesitar decisiones diferentes. Una etiqueta breve alternativa quizá conserva utilidad donde instrucciones contractuales en otra lengua no lo hacen. Registrar qué recursos están soportados y cómo reconocer una degradación permite tratar ausencia como condición conocida. Eso no autoriza inferir preferencia de una persona solo porque su variante exacta no esté disponible.

interfaces y deployment importan cuando versiones de UI, mensajes y contratos coexisten: keys ausentes o significado cambiado pueden romper una interacción. Identificar compatibilidad y responsables del contenido, sin construir aquí un translation pipeline. mobile-architecture añade recursos empaquetados/descargados y versiones instaladas; locale del dispositivo sigue siendo señal, no autoridad final.

offline-first exige disponer de los recursos localizados necesarios para las capacidades prometidas sin conexión; no implica preinstalar todas las lenguas. Elegir qué conservar, descargar y reemplazar requiere lifecycle y preferencias. Un fallback posterior puede modificar instrucciones críticas: la disponibilidad del recurso no elimina necesidad de claridad ni confirma que la operación remota haya terminado.

Probar adaptación y experiencia conjunta

accessibility pregunta si la experiencia puede percibirse y operarse; i18n pregunta si puede adaptarse correctamente. Lenguaje declarado afecta pronunciación; traducción puede desalinear etiqueta visible y nombre accesible. Labels/descripciones ARIA con texto también requieren localization cuando corresponde, sin duplicar innecesariamente strings ocultos. Orden lógico, lectura y foco deben seguir siendo comprensibles al cambiar layout o dirección.

La evaluación combina formatos, Unicode, expansión, recursos faltantes, localidades representativas, RTL y revisión lingüística humana. Pseudolocalization ayuda a descubrir strings hardcoded, clipping, concatenación y supuestos de tamaño; no demuestra calidad de traducción. Una matriz por riesgo es más útil que un producto cartesiano inabarcable de todos los browsers, locales y dispositivos. testability permite preparar escenarios verificables sin imponer una lista mundial fija.

Probar display sin probar input deja fuera números interpretados con otro separador o nombres rechazados antes de guardar. Una traducción correcta aislada puede perder contexto al componerse con variables o con otra aplicación. Elegir recorridos con cambios de preferencia, refresh y recursos de versiones distintas permite observar coherencia del sistema, además de corrección lingüística. Los resultados requieren revisión humana donde el sentido no pueda inferirse automáticamente.

Commerce: dominio estable, representación situada

Ejemplo propio: una orden de 100 USD para usuario con locale es-AR puede mostrarse con convenciones elegidas por producto. Cambiar idioma o locale no transforma USD en ARS: conversión monetaria es funcionalidad de negocio. Registrar qué moneda significa el precio evita que la misma cifra formateada parezca otro compromiso comercial.

El timestamp de la orden representa un instante; mostrarlo según zona y locale no cambia cuándo ocurrió. Una storefront localizada al árabe puede necesitar dirección RTL, mientras product codes, precios y marcas mezclan direcciones. Mensajes de cantidad del cart necesitan reglas de plural de la lengua, sin inventar aquí categorías o ejemplos numéricos universales.

En Checkout localizado, conservar lenguaje, dirección, etiquetas, nombres accesibles y errores asociados, además de teclado/foco. Una traducción larga que oculte Pay o separe error de control rompe el recorrido aunque cada string exista. Cache de producto debe distinguir variantes para no servir contenido inglés como si fuese la versión árabe requerida.

micro-frontends puede componer Browse, Checkout y Account con versiones y recursos diferentes: necesitan contexto de locale/dirección y expectativas de fallback compatibles. Autonomía no justifica mezclar instrucciones contradictorias. frontend-and-client-architecture conserva este recorrido junto a accessibility, rendering y estado, sin colapsarlos en traducción.

Fuentes revisadas 2026-10-24: Unicode anuncia 18.0; UTS #35 estable para CLDR 49 está fechado 2026-10-21, mientras Downloads registra la release 49 el 2026-10-22. Son contexto de fuentes, no versiones obligatorias del Atlas. W3C aporta guía Web; BCP 47 identifica/matchea lenguas; Unicode modela texto; CLDR aporta datos/reglas. Los ejemplos y decisiones de fronteras son síntesis Atlas, sin requisitos de una edición futura de ECMA-402.