Datos de región de Intl y formato web portátil

La API JavaScript Intl ayuda a una aplicación a presentar fechas, números, monedas y otra información lingüística en formas familiares. No decide qué quiso decir una persona, a qué país pertenece ni en qué zona horaria ocurrió un evento. Un formato portátil parte de datos claros de la aplicación y de una elección explícita de presentación. El navegador puede convertir un valor en una cadena localizada sin que la aplicación tenga que mantener cada convención de puntuación y orden.

La aplicación debe mantener el valor subyacente separado del texto mostrado. Un número sigue siendo el mismo aunque una región agrupe sus dígitos de otra manera. Una marca de tiempo sigue representando el mismo instante aunque dos personas vean horas locales distintas. El texto formateado es para las personas: no es un formato estable de almacenamiento, una entrada fiable para analizar ni una prueba de identidad. Esta distinción evita errores que suelen aparecer cuando el producto llega a otro idioma o región.

Los datos regionales del navegador pueden cambiar con las actualizaciones del entorno y algunos detalles de presentación pueden variar. El objetivo de compatibilidad no es que la puntuación sea idéntica en todas partes. Es que la persona entienda el valor, pueda elegir el idioma o región adecuados y complete la tarea. Para el tema distinto de mantener coherentes el idioma y la zona horaria del navegador, consulta la guía sobre zonas horarias, región e idioma. Aquí se trata la salida de la aplicación, no la identidad del navegador.

Deja que la persona elija el idioma de presentación

El navegador puede indicar una preferencia lingüística, pero la aplicación no debe convertir esa señal en una decisión irreversible. Las personas comparten dispositivos, viajan, trabajan en varios idiomas o prefieren idiomas distintos para tareas diferentes. El idioma de la cuenta también puede ser más útil que la preferencia actual del navegador. Elige una presentación inicial con la información disponible y ofrece una forma visible de cambiarla cuando el idioma importe.

Separa el idioma de la interfaz de la región de formato cuando el producto necesite esa distinción. Alguien puede leer instrucciones en inglés y esperar fechas y precios con formato regional. Otra persona puede elegir el idioma del contenido sin querer cambiar la moneda de facturación de la cuenta. La aplicación debe nombrar claramente la opción que ofrece. Un control llamado «Idioma» no debe cambiar en silencio la moneda de un importe ni la zona horaria subyacente de un evento.

La elección explícita de la persona debe prevalecer sobre un valor predeterminado inferido. Si selecciona un idioma admitido, mantén la interfaz coherente entre páginas y visitas posteriores según el comportamiento de preferencias declarado por el producto. Permite cambiar la elección de nuevo. Si se guarda en una cuenta o en el navegador, explica dónde se aplica. Una preferencia de un espacio de trabajo no debe controlar inesperadamente otra cuenta.

La alternativa también debe ser predecible. La aplicación quizá no haya traducido el idioma solicitado o no disponga de una variante regional concreta. Elige una alternativa documentada, mantén visible el idioma elegido y evita mezclar idiomas sin relación dentro de una tarea. La alternativa puede conservar el acceso al servicio, pero no debe fingir que existe una traducción completa cuando solo se ha localizado parte de la interfaz.

Las etiquetas de idioma identifican una lengua y pueden incluir subtags de escritura o región. ECMA-402 define cómo los servicios de formato gestionan los identificadores regionales. La aplicación sigue siendo responsable de decidir qué idiomas admite y cómo relaciona una preferencia con el contenido disponible. Pasar un identificador regional a Intl no traduce etiquetas, instrucciones, textos legales ni contenido creado por usuarios.

Cuando sea posible, alinea el idioma del contenido y el formato, pero no obligues a que un solo valor sirva para todo. Un mensaje escrito en español puede incluir un importe con formato de la región de facturación y una reunión en la zona horaria elegida por quien lo ve. Indica qué elección rige cada valor. Es más claro que tratar la preferencia de idioma del navegador como un perfil completo de la persona.

La región elegida también afecta a la accesibilidad. Los metadatos lingüísticos correctos ayudan a la tecnología de asistencia a pronunciar el texto adecuadamente. Los controles para cambiar el idioma necesitan nombres que la persona reconozca incluso después de un cambio accidental. La página debe conservar el foco y la tarea actual al cambiar el idioma de la interfaz. Exigir un reinicio completo o descartar los datos de un formulario puede convertir una preferencia útil en una barrera.

Prueba el idioma predeterminado en la primera visita, un cambio explícito, una preferencia guardada, una variante no admitida y el regreso al idioma anterior. Comprueba juntos el texto de la interfaz y los valores formateados. Una fecha puede ser correcta mientras su etiqueta está en otro idioma, o una etiqueta traducida puede rodear un número cuyo formato sigue codificado.

Para una explicación más amplia de cómo interactúan las elecciones del navegador, la cuenta, el sitio y la red, consulta la guía de privacidad de superficies del navegador. Una preferencia lingüística es un dato de presentación; combinarla con señales ajenas para clasificar usuarios es otro uso de datos, fuera del formato habitual.

Usa Intl para presentar, no como fuente de verdad

Intl ofrece formateadores y otros servicios lingüísticos a las aplicaciones JavaScript. ECMA-402 especifica su comportamiento y el modelo de operaciones regionales. MDN documenta las interfaces de formato habituales y su uso en aplicaciones. El navegador proporciona la implementación y los datos regionales. La aplicación aporta el valor, las opciones pertinentes y el contexto donde se mostrará el resultado.

Guarda los datos canónicos en tipos y campos que expresen su significado. Un importe necesita un valor numérico y un código de moneda separado. Un evento programado necesita un instante o una regla clara de hora local y su zona horaria. Una medida necesita un valor y una unidad. Una cadena formateada no puede devolver de forma fiable todos esos campos al almacenamiento porque la puntuación, los símbolos, el orden y el idioma pueden variar.

El formato suele ser el último paso antes de mostrar. Un servicio de datos puede devolver valores estructurados y la página aplicar las opciones de presentación de quien la consulta. Así se puede cambiar el idioma de la interfaz sin reescribir el registro guardado. También quedan claras las reglas de exportación: una exportación legible por máquinas conserva valores estructurados y un informe para personas puede incluir etiquetas y formatos localizados.

No analices una cadena localizada para recuperar el valor original. En una convención, una coma separa grupos; en otra, indica la fracción decimal. Un símbolo monetario puede corresponder a varias monedas. Una fecha con solo números puede ser ambigua si cambia el orden del día y el mes. Si el producto acepta entradas, define por separado el formato y la validación y muestra el formato admitido junto al campo.

Elige las opciones según el ámbito. Un recibo puede necesitar la moneda y la regla de redondeo de su flujo financiero. Una presentación científica puede necesitar una unidad y una precisión que conserven información útil. Una etiqueta de tiempo relativo puede orientar, pero no debe sustituir una marca de tiempo exacta cuando haya que comparar registros. Intl expresa la presentación elegida; no decide reglas legales, contables, científicas o de programación.

Mantén separados los protocolos de máquina y la presentación para personas. Las API, bases de datos, registros y firmas necesitan contratos de datos estables. El formato localizado pertenece al límite visible para las personas, salvo que un protocolo lo defina expresamente. Un valor copiado de una página localizada debe conservar suficiente contexto para entenderse en otro sitio, sobre todo si se pega en un mensaje, hoja de cálculo o solicitud de soporte.

La salida del formateador tampoco es un identificador de usuario persistente adecuado. Su apariencia exacta puede cambiar cuando varían los datos regionales, las opciones o la versión del entorno. Si la aplicación necesita recordar una preferencia, guarda la preferencia, como el idioma o la zona horaria elegidos, no el último resultado formateado. No conviertas diferencias de presentación en un perfil del dispositivo.

Esta separación facilita las pruebas. Primero se pueden validar el valor subyacente y las opciones elegidas; después, que la salida comunique el significado previsto. No hace falta exigir espacios, abreviaturas o puntuación idénticos en todos los entornos válidos. Las comparaciones exactas de texto son apropiadas cuando el producto controla expresamente una etiqueta fija o una presentación regulada.

Formatea números, dinero y fechas según su contexto

Los números necesitan más contexto que una etiqueta regional. Un recuento, porcentaje, distancia, temperatura, precio e identificador pueden contener cifras, pero las personas los interpretan de manera distinta. Indica al formateador qué tipo de valor presenta la interfaz y coloca una etiqueta clara junto a él. Un número sin unidad o función puede seguir siendo ambiguo aunque se vea pulido.

Con los porcentajes, distingue el valor almacenado de la convención mostrada. Si el producto guarda una fracción, debe formatearla según el modelo de entrada esperado. Si guarda puntos porcentuales, la conversión será diferente. La aplicación debe definir el significado; una región no corrige una discrepancia entre cantidad y etiqueta.

Conserva el código de moneda junto al importe. La región puede cambiar el orden del símbolo, los espacios y la agrupación de dígitos, pero no determina la moneda de una transacción. Cambiar el idioma de quien consulta no debe convertir el importe ni cambiarle la moneda en silencio. Si se ofrece conversión, es una operación separada cuyo origen del tipo de cambio y fecha efectiva debe explicar el producto.

El redondeo es otra regla del producto. El formateador puede mostrar una cantidad elegida de dígitos, pero no debe ser el único lugar donde viva una política de redondeo financiero o científico. Los valores almacenados, comparados o sumados necesitan un proceso de cálculo definido. Un valor redondeado para facilitar la lectura no debe confundirse con el valor exacto de una transacción o análisis.

Las fechas requieren tanto el valor como la decisión sobre la zona horaria. Un instante registrado en un sistema puede mostrarse en la zona de quien lo consulta, la del lugar del evento o una zona fija de informes. Son significados distintos. La etiqueta lingüística cambia el texto y el orden de las partes de la fecha, pero no elige por sí sola la zona de una cita o un plazo legal.

Las fechas de calendario locales también requieren cuidado. Un cumpleaños, la fecha de entrada en un hotel y un período de informe diario pueden representar un día del calendario, no un instante universal. Convertir ese valor mediante una zona arbitraria puede desplazarlo al día anterior o posterior. Define el tipo del dominio antes de formatear y muestra la zona aplicable cuando un evento horario pueda prestarse a confusión.

Los cambios de horario de verano hacen especialmente frágiles las suposiciones informales. Una hora local puede repetirse o no existir en el día del cambio. La aplicación que programa eventos debe resolverlo según una regla documentada; dar formato a una marca de tiempo es solo la presentación. En la vista habitual, incluye el nombre o desplazamiento de la zona cuando haya que comparar lugares. No hagas que la persona la deduzca por el idioma o la ubicación.

El límite de las API es específico: Intl.Locale gestiona identificadores regionales, Intl.NumberFormat presenta números y monedas, y Intl.DateTimeFormat presenta valores de fecha y hora. Estas API no eligen la moneda de una transacción, no definen un día de calendario ni resuelven la regla de programación de una aplicación.

La corrección de zonas horarias merece pruebas específicas de la aplicación, en especial para viajes, eventos recurrentes y cambios de horario. Mantén esa lógica de dominio separada de la capa general de formato. El artículo de consistencia de JavaScript Math trata el cálculo numérico y la portabilidad, pero no sustituye decidir qué significa una fecha, moneda o unidad antes de mostrarla.

Durante la revisión, usa ejemplos de tareas reales. Un recibo debe mostrar el importe y la moneda correctos; un calendario, el día del evento en la zona elegida; una medida, su unidad; y un recuento debe seguir siendo legible con valores grandes. Estas comprobaciones detectan errores de significado que una captura genérica de puntuación formateada no revela.

Ten en cuenta los datos regionales y las diferencias del entorno

El comportamiento de Intl depende del contrato ECMA-402 y de los datos regionales disponibles en el entorno. La especificación define algoritmos y comportamientos requeridos, pero no fija para siempre cada palabra, abreviatura o detalle tipográfico de todos los idiomas en futuras versiones. Las convenciones cambian. Una actualización del navegador o del sistema operativo puede traer datos nuevos aunque el código de la aplicación no cambie.

Trata la compatibilidad regional como un requisito del producto con resultados observables. Enumera los idiomas y variantes regionales prometidos, las funciones de formato utilizadas y la alternativa ofrecida cuando falte soporte. Prueba esas promesas en los navegadores admitidos por el producto. No deduzcas compatibilidad solo de un número de versión o de un formato que funcionó en otra región.

La aplicación debe resistir cuando el idioma o la opción preferidos no producen la presentación solicitada. La alternativa debe conservar el valor y hacerlo comprensible. La falta de una convención regional no debe convertir un importe en una cifra sin etiqueta ni un plazo en una fecha sin zona. En flujos de alto impacto, explica la alternativa y permite consultar el contexto subyacente.

Acepta las variaciones tipográficas inocuas. El espaciado, los separadores, la puntuación y las abreviaturas pueden cambiar entre implementaciones válidas. Algunos espacios que parecen iguales tienen distinta representación. La igualdad exacta de cadenas puede volver frágil una prueba aunque el significado visible sea correcto. Compara valores estructurados y resultados del producto cuando sea posible, y reserva la coincidencia exacta para texto que el producto controla.

Los datos regionales no determinan la identidad. Que un entorno elija una abreviatura concreta no demuestra dónde vive una persona ni qué idioma habla. La aplicación no debe clasificar usuarios a partir de la salida del formateador. Usa preferencias explícitas y datos de la tarea para decidir la presentación y limita los diagnósticos de compatibilidad al resultado pertinente.

Revisa tipografía y disposición con textos localizados reales. Las fechas y precios pueden ocupar más que los ejemplos ingleses del diseño. Un símbolo monetario quizá necesite una fuente alternativa; una etiqueta de fecha puede saltar de línea; un idioma escrito de derecha a izquierda puede cambiar el diseño cercano. El formateador no resuelve estos asuntos de interfaz. Reserva espacio, permite saltos de línea y comprueba el orden de lectura de los idiomas admitidos.

Ten en cuenta el contenido copiado y exportado. Un número claro en una tabla etiquetada puede resultar ambiguo al pegarlo sin el encabezado. Incluye unidad, moneda, zona de la fecha u otro contexto necesario en las exportaciones y acciones para compartir. Las exportaciones legibles por máquinas deben usar un esquema explícito y dejar la localización a la interfaz receptora, en vez de exportar solo texto de presentación.

Si una actualización cambia la salida del navegador, investiga primero la consecuencia para el usuario antes de llamarlo regresión. ¿Cambió el significado del importe, dejó de leerse una etiqueta o solo cambió el espaciado? ¿La aplicación dependía de una cadena fija que la plataforma nunca prometió? Un conjunto limitado de ejemplos ligado a tareas reales aclara esto mejor que recopilar todas las variaciones.

Registra la versión de la aplicación, el navegador, la región seleccionada y el valor de entrada que produjo un problema de presentación. Estos datos pueden ayudar a reproducirlo sin recopilar características ajenas del navegador. Conserva los diagnósticos de soporte solo mientras sean necesarios y no conviertas una queja de formato en un inventario general del entorno.

Haz que el formato sea comprensible y accesible

Una cadena localizada debe entenderse en contexto. Una fecha corta con solo cifras puede ser compacta pero ambigua. Un número con separadores de grupos y decimales sigue necesitando una etiqueta. La moneda, unidad y zona horaria deben estar visibles cuando la persona decide, no escondidas en una ayuda que la tecnología de asistencia quizá no alcance.

Usa elementos semánticos de página para el texto que rodea un valor formateado. El encabezado de una tabla puede nombrar un importe o una fecha; una etiqueta de formulario puede indicar el formato de entrada aceptado; un mensaje de estado puede explicar un cambio de preferencia. Esta estructura ayuda a lectores de pantalla y otras herramientas a relacionar el valor con su significado. El formato no puede aportar relaciones que falten en el marcado.

El idioma del documento debe reflejar el idioma real de su texto. Si la página incluye un pasaje en otra lengua, márcalo adecuadamente para que la tecnología de asistencia lo pronuncie bien. El selector de idioma debe seguir siendo localizable aunque la elección actual resulte desconocida. No uses solo banderas para representar idiomas: una lengua puede usarse en varios países y un país puede contener muchas lenguas.

Da control a la persona cuando el valor predeterminado automático sea incorrecto. Una opción visible de idioma o formato regional es especialmente importante en dispositivos compartidos, viajes y flujos multilingües. Mantenla separada del permiso de ubicación y de datos de cuenta no relacionados. Nadie debe revelar una ubicación precisa solo para leer una fecha o importe con un formato familiar.

Los cambios de presentación no deben modificar el registro subyacente. Si la persona cambia el idioma al editar un formulario, conserva el valor introducido y explica cualquier cambio en su presentación. Si un evento programado aparece en otra zona horaria, conserva su identidad y muestra la zona de la nueva presentación. Estas transiciones deben poder revertirse y no confirmar en silencio una transacción o cita nueva.

Prueba con tecnología de asistencia y con los tamaños de texto que use el público. Comprueba que los valores localizados largos se ajusten sin ocultar controles cercanos, que el orden de lectura tenga sentido y que el valor copiado incluya contexto fuera de la página. Si un valor se abrevia visualmente, ofrece una forma completa accesible cuando aporte claridad. Evita anuncios duplicados que vuelvan ruidosa la página.

Los mensajes de error también necesitan localización y contexto. Si la aplicación rechaza un número o una fecha, indica qué formato acepta y muestra un ejemplo adecuado al idioma elegido. No devuelvas la entrada en otro formato y la declares inválida. Distingue un error de análisis de un valor válido que supera un límite del dominio.

La mejor prueba de aceptación es una tarea real. ¿Puede la persona entender el importe y la moneda antes de confirmar el pago? ¿Puede saber cuándo empieza un evento y qué zona horaria se aplica? ¿Puede cambiar el idioma sin perder trabajo? Estos resultados importan más que reproducir cada carácter de un entorno concreto.

Revisa el formato como contrato del producto

Define qué valores formatea el navegador, cuáles devuelve un servicio ya localizados y cuáles deben seguir siendo legibles por máquinas. Repetir el formato en varios lugares puede mezclar idiomas o convertir dos veces. Un límite claro permite cambiar la presentación sin alterar los datos subyacentes y mantiene estables los contratos del servicio.

Mantén pocos casos de prueba representativos para cada flujo admitido. Incluye al menos una fecha normal, una hora cercana a un cambio de zona cuando el horario importe, un número grande o fraccionario y una moneda con código explícito si el producto maneja dinero. Cada caso debe validar un resultado concreto para la persona. Añade otro cuando un fallo real revele un riesgo nuevo; evita crear un catálogo de cadenas regionales arbitrarias sin una decisión de producto.

En un caso de prueba sintético de dinero, formatea el valor 1234.5 como EUR con la presentación en-GB, un código de moneda explícito y dos decimales. La persona debe leer un importe equivalente a 1234.50 euros e identificar EUR; los cambios de espaciado debidos a los datos regionales no hacen fallar la prueba, pero sí un importe distinto o la falta de etiqueta de moneda. Si la aplicación solo admite inglés y francés y recibe una preferencia en español, la alternativa declarada en inglés debe mostrar el mismo importe y moneda, e indicar el idioma actual.

En un caso de prueba de agenda, mantén fijo el instante 2026-01-01T01:30:00Z: la presentación UTC representa el 1 de enero de 2026 a las 01:30, mientras que America/New_York representa el 31 de diciembre de 2025 a las 20:30. Ambas vistas deben identificar su zona horaria y referirse al mismo instante guardado; la puntuación puede variar, pero un instante distinto o un cambio de fecha sin explicación incumple el caso.

Revisa la alternativa con el mismo cuidado que la opción preferida. Una región solicitada no admitida, una traducción ausente o un fallo del formateador todavía deben dejar comprensible el valor y la tarea. La interfaz debe indicar qué idioma o formato usa, sin mezclar variantes en silencio, y conservar la posibilidad de volver a una opción admitida.

Al añadir herramientas de localización o componentes externos, comprueba el flujo de datos y la privacidad. Un formateador que funciona en el navegador no obliga a enviar a otro servicio un inventario detallado del navegador. Si un servicio recibe preferencias lingüísticas o regionales por una tarea legítima, documenta por qué las necesita y cuánto tiempo las conserva. No reutilices preferencias de presentación como una señal oculta de segmentación.

La internacionalización es una responsabilidad continua de la aplicación. Intl evita implementar a mano muchas reglas de formato específicas de cada idioma, pero no traduce el contenido del producto, define el significado de los valores guardados, elige la identidad de una persona ni garantiza cadenas idénticas en todos los entornos. Trata los valores, las preferencias de presentación y la salida formateada como capas separadas. Así las personas leen un texto familiar sin perder el control de la tarea subyacente.

Fuentes públicas

• API de internacionalización ECMA-402
• MDN: Intl