FreeToGenerate.com

Analiza la cabecera y ejecuta los dos algoritmos estándar. No se sube nada.

La petición y lo que tienes

Sepáralas con comas o espacios. Son tus propios archivos o traducciones: las etiquetas con las que responderías de verdad.

Qué responde cada algoritmo

Lookup: una sola etiqueta

en

Basic Filtering: un conjunto

fr

Los dos algoritmos discrepan con esta entrada.

No es un fallo de ninguno. El RFC 4647 define ambos y buscan en direcciones opuestas, así que el que use tu framework decide qué ve esta persona.

Lo que Lookup intentó

en-us → en

Lookup recorta el rango solicitado por la derecha hasta que algo coincide. Fíjate en que una subetiqueta de un solo carácter al final se elimina junto con la anterior, de modo que un paso como zh-Hant-CN-x nunca se prueba: esa regla sale del ejemplo resuelto que imprime la propia especificación.

La cabecera ya analizada

Rangoq
en-us1
fr0.8

Un valor de calidad de cero es un rechazo, no una preferencia baja. Una cabecera que nombra un idioma con q=0 te está pidiendo que no lo sirvas, así que aquí se excluye de ambas respuestas toda etiqueta que solo coincida con un rango rechazado. Los rangos sin q valen 1, y ante valores iguales se conserva el orden de la cabecera, porque la especificación no da ningún otro criterio de desempate.

Con qué frecuencia discrepan

combinaciones medidas
119
discrepancias
14
solo coincidió Lookup
8
solo coincidió Filtering
6

Medido sobre 7 conjuntos realistas de etiquetas disponibles frente a 17 rangos realistas: difieren en 14 de 119 combinaciones. Importa más la forma que la tasa. En 8 solo encontró algo Lookup, porque recorta la petición, así que en-US llega hasta tu en a secas. En 6 solo lo encontró Filtering, porque amplía la petición, así que en llega hasta tu en-GB. En ninguna coincidieron las dos y eligieron cosas distintas. Los dos esquemas cubren direcciones opuestas del desajuste, y ninguno cubre las dos.

Los dos algoritmos son del RFC 4647; las reglas de los valores de calidad, del RFC 9110. No se sube nada: la comparación ocurre en esta pestaña.

También disponible en: English · Português · Français · العربية

Analizador de la cabecera Accept-Language

Descubre qué idioma de los tuyos elige la cabecera Accept-Language de un navegador, y por qué los dos algoritmos estándar pueden elegir uno distinto.

Qué es la cabecera Accept-Language

Accept-Language es el campo que el navegador envía en cada petición para decir en qué idiomas preferiría leer quien lo usa. Contiene una lista de rangos de idioma, cada uno con un valor de calidad opcional entre 0 y 1, y ordenados de mayor a menor preferencia. Una cabecera típica es en-US,fr;q=0.8: esta persona quiere inglés estadounidense y aceptaría francés con menos ganas.

La cabecera es una petición, no una orden. Dice qué le gustaría al visitante, pero no puede saber qué tienes tú. Convertirla en una respuesta real significa comparar esos rangos con el conjunto de idiomas que de verdad puedes servir, y ahí está lo interesante, porque hay más de una forma estándar de hacerlo y no siempre coinciden.

Esta herramienta hace las dos mitades. Analiza la cabecera según las reglas de valores de calidad del RFC 9110 y después ejecuta los dos esquemas de comparación que define el RFC 4647 —Lookup y Basic Filtering— contra las etiquetas que declares, mostrando las dos respuestas una al lado de la otra.

Cómo se usa

  1. Pega la cabecera. Cópiala de los registros de tu servidor, de las herramientas de desarrollo del navegador o de la petición que estés depurando. Los rangos aparecen en una tabla, ordenados por valor de calidad y con el 1 por defecto ya rellenado donde la cabecera lo omite.
  2. Enumera los idiomas que puedes servir. Escribe las etiquetas de las que realmente tienes archivos o traducciones, separadas por comas o espacios: en, fr, de. Son las etiquetas con las que responderías, no las que pidió el visitante.
  3. Lee las dos respuestas. Lookup devuelve una etiqueta; Basic Filtering devuelve un conjunto. Cuando difieren, la página lo dice, y la cadena de recortes de debajo muestra cada paso que intentó Lookup hasta llegar a su respuesta.

Los dos algoritmos fallan en direcciones opuestas

El RFC 4647 define los dos esquemas sobre la misma cabecera, y la diferencia no es cuestión de ser más o menos estricto. Lookup recorta la petición por la derecha hasta que algo coincide, así que a quien pide en-US le sirves tu en a secas. Basic Filtering va al revés: un rango coincide con cualquier etiqueta de la que sea prefijo en un límite de subetiqueta, así que a quien pide en le sirves tu en-GB.

Medido sobre 7 conjuntos realistas de etiquetas disponibles frente a 17 rangos realistas —119 combinaciones—, los dos discrepan en 14, es decir un 11,8 %. La tasa importa menos que la forma. En 8 de esas 14 solo Lookup encontró algo, y en 6 solo lo encontró Filtering. No hubo ni un solo caso en que ambos coincidieran y eligieran etiquetas distintas.

Los dos esquemas, por tanto, no compiten por las mismas respuestas. Cada uno cubre una dirección del desajuste que el otro no ve, y ninguno cubre las dos. Si tu framework usa Lookup, fallarás en silencio con los visitantes cuya petición es menos específica que tus archivos; si usa Filtering, fallarás con aquellos cuya petición es más específica. Saber cuál estás ejecutando es justo lo que importa, y la mayoría de los entornos no te lo dicen.

La regla de recorte también tiene una trampa, y la especificación la imprime. Reducir zh-Hant-CN-x-private1-private2 da zh-Hant-CN-x-private1 y después directamente zh-Hant-CN, nunca zh-Hant-CN-x, porque una subetiqueta de un solo carácter al final se elimina junto con la anterior. La cadena de esta página reproduce ese ejemplo resuelto paso a paso.

Lo que la cabecera no puede decirte

Un valor de calidad de cero es un rechazo, no una preferencia baja. Una cabecera que nombra un idioma con q=0 te pide que no lo sirvas, lo cual no es lo mismo que omitirlo. Esta herramienta excluye de las dos respuestas cualquier etiqueta que solo coincida con un rango rechazado; un comparador que trate q=0 como la puntuación más baja servirá alegremente el único idioma que el visitante descartó de forma explícita.

Los valores de calidad iguales no tienen criterio de desempate en la especificación, así que el orden de la propia cabecera es la única señal que queda y es la que usa esta página. Conviene saber que es una convención y no una regla, y que otra implementación puede ordenarlos de otro modo con toda la razón.

En general, la cabecera describe una preferencia y no un hecho. Suele ser la lista de idiomas del sistema operativo más que una decisión meditada, no dice nada sobre el idioma del contenido que el visitante venía buscando y es trivial de falsificar. Sirve como valor por defecto y no como anulación: si alguien ha pulsado un selector de idioma, ese clic debe ganar y debe recordarse en algún sitio más firme que una suposición sobre su navegador.

Algo que esta página no hace es compararse con una implementación de referencia, y merece la pena explicarlo. La API Intl ejecuta Lookup con localeMatcher en lookup, pero contra los idiomas disponibles del propio entorno de ejecución y no contra un conjunto que le pases, de modo que responde a otra pregunta. En su lugar, el vector de prueba es el ejemplo resuelto que imprime la especificación.

¿Por qué es gratis?

Todo funciona en tu navegador. Analizar una cabecera y comparar cadenas no cuesta nada si lo hace tu propia máquina, así que no hay servidor que pagar ni motivo para pedirte nada.

Nada de lo que escribes se sube, se guarda ni se registra: las cabeceras sacadas de registros de producción pueden identificar a una persona, y la forma segura de tratarlas es no recibirlas. No hay cuenta, ni registro, ni límite de cuántas compruebes.