País e idioma no son lo mismo: tres capas

País e idioma no son lo mismo, aunque en muchos formularios compartan un solo desplegable. El territorio decide qué convenciones se aplican al dato; el idioma decide en qué lengua se muestra el texto. Cuando se toma uno por el otro, el sistema acierta en el caso más común y falla exactamente en los casos que más importan. Esta guía descompone la localización en tres capas, explica por qué las etiquetas de idioma no sirven como interruptor de formato y propone una forma de muestrear los dos ejes sin emparejarlos uno a uno.

¿Por qué no se puede deducir el país a partir del idioma?

Porque la relación entre ambos es de muchos a muchos. Una misma lengua es oficial en territorios distintos, y un territorio puede tener varias lenguas oficiales. Cualquier intento de obtener uno desde el otro es una suposición que funciona por casualidad en los casos frecuentes.

La suposición se nota sobre todo al revés: alguien ve la lengua de la interfaz y decide con ella qué reglas de formato aplicar. El resultado es un sistema que trata igual a dos territorios que comparten lengua y distinto a dos usuarios del mismo territorio que usan lenguas diferentes.

El daño no es solo un mensaje mal traducido. Es un dato guardado, validado o mostrado con la convención equivocada, y eso suele llegar hasta informes y facturación antes de que alguien lo note.

Las tres capas de la localización

Las tres capas se pueden configurar por separado y en la práctica lo hacen. Un usuario puede leer la interfaz en su lengua, ver contenidos de un territorio y escribir una dirección con las convenciones de otro, porque la dirección es de otro sitio.

El error típico es fusionarlas en una sola preferencia y llamarla idioma. En cuanto se fusionan, cambiar de idioma altera el formato y cambiar de territorio traduce la interfaz, y ninguna de las dos cosas debería pasar.

La etiqueta de idioma y el código de región cumplen funciones distintas

Una etiqueta de idioma describe texto. Un código de región describe el territorio al que se refieren los datos. Son dos identificadores con dos propósitos, y confundirlos lleva a decisiones raras, como deducir la moneda a partir de la lengua de la interfaz.

Los dos se escriben con formas normalizadas que permiten combinarlos, y esa combinación es útil para elegir un formato de presentación cuando no hay más información. Lo que no es aceptable es usar esa combinación como sustituto del territorio real del dato.

La regla práctica es sencilla: si el dato va a guardarse o validarse, el territorio debe ser un campo propio y explícito. La preferencia de idioma se guarda aparte y nunca participa en la validación.

¿Qué se rompe cuando se adivina el formato por el idioma?

Se rompen casos que parecen de detalle y acaban en incidencias de datos. Los más frecuentes en pruebas son cuatro.

• Un usuario cuya lengua no coincide con el territorio recibe reglas de otro sitio y ve rechazado un dato correcto.
• Dos territorios que comparten lengua reciben las mismas reglas aunque sus modelos de datos difieran.
• El mismo usuario cambia de idioma y las validaciones cambian con él, algo que nadie espera y que es muy difícil de reproducir.
• Los informes agrupan por lengua y presentan como mercado lo que en realidad es una preferencia de lectura.

Ninguno de estos fallos aparece si la primera prueba se hace con una combinación deliberadamente incoherente. Por eso el muestreo del apartado siguiente es tan importante.

Cómo se muestrea una matriz de dos ejes

Se muestrea como una matriz y no como una lista de parejas. El eje de lengua sirve para comprobar el texto: longitudes, plurales, truncados, ordenación de cadenas. El eje de territorio sirve para comprobar el dato: aplicabilidad de campos, formatos y validaciones.

Una forma de construir la muestra es elegir unas pocas lenguas que cubran familias distintas y unos pocos territorios que cubran modelos de datos distintos, y después probar las combinaciones cruzadas en lugar de emparejarlos. La combinación incoherente es la que aporta información.

Para el eje de texto, este sitio ya tiene material en la guía sobre los datos de nombre por región, que trata las diferencias de forma del nombre según la lengua. Aquí el eje de texto solo se usa como fuente de casos; lo que se prueba en esta página es el cruce con el territorio.

Notas para quien programa

• Guarda el territorio del dato como campo explícito y no lo derives de la preferencia de idioma en ningún punto del flujo.
• Separa en la configuración la lengua de la interfaz, el contenido regional y las convenciones del dato.
• Haz que la validación lea el territorio del registro y nunca la configuración de la sesión.
• Formatea al mostrar y guarda en una forma neutra; así el cambio de lengua no altera el dato.
• Incluye al menos una combinación incoherente de lengua y territorio en la suite de pruebas.
• Revisa los informes que agrupan por lengua y decide si lo que quieren medir es mercado o idioma.
• No escribas la relación entre lengua y territorio como una tabla fija; si hace falta, que venga de datos mantenidos aparte.

Siguientes pasos

Elige un formulario de tu producto y comprueba si el territorio del dato se deduce del idioma en algún punto; casi siempre aparece en la capa de formato de fecha o de número. Si quieres ver cómo se agrupan los territorios antes de montar la matriz, el directorio de países y regiones los presenta por bloques geográficos y enlaza el detalle de cada uno. Y si el problema es que el agrupamiento cambia con el negocio, la guía sobre agrupaciones regionales y niveles de mercado separa esos dos usos.

Sobre los ejemplos: las parejas de lengua y territorio, los nombres de usuario y los valores de muestra que aparecen aquí están inventados para explicar el cruce de ejes. No representan la distribución real de usuarios de ningún servicio ni datos enviados por personas reales.