La negociación de Accept-Language y sus límites

Qué es

La RFC 9110 define Accept-Language como una lista de rangos de idioma con valores de calidad opcionales: da, en-gb;q=0.8, en;q=0.7 significa «prefiero el danés, pero aceptaré el inglés británico y otros tipos de inglés». No se puede confiar en el orden entre pesos iguales. La correspondencia se delega en la RFC 4647: el filtrado básico trata un rango como un prefijo (de coincide con de-CH); la búsqueda (lookup) encuentra la única etiqueta óptima truncando el rango por la derecha (de-CH-1996, luego de-CH, luego de). Una cabecera ausente no expresa ninguna preferencia y deja la elección al servidor. Un agente de usuario que no ofrece al usuario control sobre la preferencia NO DEBE enviar la cabecera, y la RFC señala el costo de privacidad de enviar preferencias completas en cada solicitud. La respuesta nombra su idioma en Content-Language y, como varía según la cabecera de la solicitud, necesita Vary: Accept-Language para las cachés.

Por qué importa

La cabecera describe la configuración de un dispositivo o navegador, no necesariamente al lector: los ordenadores compartidos, las imágenes corporativas y los viajeros envían todos algo incorrecto. La documentación de Google indica que su rastreador envía solicitudes sin Accept-Language, advierte de que podría no rastrear, indexar ni clasificar todo el contenido para las distintas configuraciones regionales, y recomienda URL separadas por configuración regional con anotaciones hreflang; por eso, el contenido elegido solo mediante la cabecera puede quedar invisible en algunos idiomas. Los scripts y los agentes por lo general no envían nada. Una caché que ignora Vary sirve a todos el primer idioma que almacenó.

Cómo aplicarlo

• Dar a cada idioma su propia URL (/de/, /en/) con alternativas hreflang; usar la cabecera solo para elegir adónde va un visitante que llega a la raíz neutra en cuanto a idioma, con una redirección temporal y Vary: Accept-Language, nunca una permanente cacheada.
• Implementar la búsqueda (lookup): etiqueta exacta, luego idioma principal, luego el valor por defecto del sitio; tratar * y una cabecera ausente como el valor por defecto.
• Almacenar una elección explícita (cookie o perfil) y dejar que anule la cabecera en cada visita posterior.
• Para las API, aceptar un parámetro lang documentado que anule la cabecera, y devolver siempre Content-Language.
• No inferir el idioma a partir de la dirección IP; los países son multilingües.

Trampas

Una solicitud de en-GB contra un sitio que solo tiene en falla con el filtrado básico, porque la etiqueta es más corta que el rango; la búsqueda (lookup) sí lo gestiona, y la RFC 9110 señala que los agentes de usuario deberían sugerir añadir en a tal lista. Los valores de calidad iguales con un orden implícito difieren entre clientes. La negociación de idioma no dice nada sobre los formatos específicos de una región; tratar por separado la configuración regional para las fechas y los números.