Analyseur de l'en-tête Accept-Language

Qu'est-ce que l'en-tête Accept-Language ?

Accept-Language est le champ que le navigateur envoie à chaque requête pour indiquer dans quelles langues son utilisateur préférerait lire. Il transporte une liste de plages de langues, chacune éventuellement pondérée par une valeur de qualité comprise entre 0 et 1, de la plus souhaitée à la moins souhaitée. Un en-tête courant ressemble à en-US,fr;q=0.8 : ce lecteur veut de l'anglais américain et acceptera le français avec moins d'enthousiasme.

L'en-tête est une demande, pas une consigne. Il dit ce que le visiteur souhaiterait, mais il ignore ce dont vous disposez. Le transformer en réponse réelle suppose de confronter ces plages à l'ensemble des langues que vous pouvez vraiment servir, et c'est là que tout se joue, car il existe plusieurs façons normalisées de le faire et elles ne s'accordent pas toujours.

Cet outil couvre les deux moitiés. Il analyse l'en-tête selon les règles de valeurs de qualité de la RFC 9110, puis exécute les deux schémas de correspondance définis par la RFC 4647, Lookup et Basic Filtering, face aux étiquettes que vous déclarez, et affiche les deux réponses côte à côte.

Comment l'utiliser

1. Collez l'en-tête. Récupérez la valeur dans les journaux de votre serveur, dans les outils de développement du navigateur ou dans la requête que vous déboguez. Les plages apparaissent dans un tableau, triées par valeur de qualité, avec la valeur par défaut de 1 déjà renseignée là où l'en-tête l'omet.
2. Listez les langues que vous pouvez servir. Saisissez les étiquettes pour lesquelles vous avez réellement des fichiers ou des traductions, séparées par des virgules ou des espaces : en, fr, de. Ce sont les étiquettes avec lesquelles vous répondriez, non celles que le visiteur a demandées.
3. Lisez les deux réponses. Lookup renvoie une étiquette, Basic Filtering renvoie un ensemble. Lorsqu'elles diffèrent, la page le signale, et la chaîne de repli affichée en dessous montre chaque étape que Lookup a tentée avant d'aboutir.

Les deux algorithmes échouent dans des directions opposées

La RFC 4647 définit les deux schémas sur le même en-tête, et l'écart n'est pas une affaire de sévérité. Lookup raccourcit la demande par la droite jusqu'à trouver une correspondance : celui qui demande en-US se verra donc servir votre en tout court. Basic Filtering procède à l'inverse, une plage correspondant à toute étiquette dont elle est le préfixe à une frontière de sous-étiquette : celui qui demande en se verra servir votre en-GB.

Mesuré sur 7 ensembles réalistes d'étiquettes disponibles face à 17 plages réalistes, soit 119 combinaisons, les deux divergent sur 14 d'entre elles, c'est-à-dire 11,8 %. Le taux importe moins que la forme. Dans 8 de ces 14 cas, seul Lookup a trouvé quelque chose ; dans 6, seul Filtering y est parvenu. Il n'y a pas eu un seul cas où les deux trouvaient une correspondance et choisissaient des étiquettes différentes.

Les deux schémas ne se disputent donc pas les mêmes réponses. Chacun couvre une direction du décalage que l'autre ne voit pas, et aucun ne couvre les deux. Si votre framework utilise Lookup, vous échouerez silencieusement auprès des visiteurs dont la demande est moins précise que vos fichiers ; s'il utilise Filtering, vous échouerez auprès de ceux dont la demande est plus précise. Savoir lequel tourne chez vous est tout l'enjeu, et la plupart des piles logicielles ne le disent pas.

La règle de troncature comporte elle aussi un piège, que la spécification imprime. Réduire zh-Hant-CN-x-private1-private2 donne zh-Hant-CN-x-private1, puis directement zh-Hant-CN, jamais zh-Hant-CN-x, car une sous-étiquette d'un seul caractère en fin de chaîne est supprimée avec celle qui la précède. La chaîne affichée ici reproduit cet exemple résolu étape par étape.

Ce que l'en-tête ne peut pas vous dire

Une valeur de qualité nulle est un refus, et non une préférence faible. Un en-tête qui nomme une langue avec q=0 vous demande de ne pas la servir du tout, ce qui n'est pas la même chose que de l'omettre. Cet outil exclut des deux réponses toute étiquette qui ne correspond qu'à une plage refusée ; un comparateur qui traite q=0 comme le plus mauvais score servira allègrement la seule langue que le visiteur avait explicitement écartée.

Les valeurs de qualité égales n'ont aucun départage dans la spécification : l'ordre de l'en-tête est alors le seul signal disponible, et c'est celui que cette page retient. Sachez toutefois qu'il s'agit d'une convention et non d'une règle, et qu'une autre implémentation peut légitimement les ordonner autrement.

Plus largement, l'en-tête décrit une préférence et non un fait. Il reflète le plus souvent la liste de langues du système d'exploitation plutôt qu'un choix délibéré, il ne dit rien de la langue du contenu que le visiteur venait chercher, et il se falsifie sans effort. C'est une bonne valeur par défaut et une mauvaise valeur prioritaire : si quelqu'un a cliqué sur un sélecteur de langue, ce clic doit l'emporter et être mémorisé ailleurs que dans une supposition sur son navigateur.

Une chose que cette page ne fait pas, c'est se comparer à une implémentation de référence, et la raison mérite d'être dite. L'API Intl exécute Lookup avec localeMatcher réglé sur lookup, mais face aux langues disponibles de l'environnement d'exécution lui-même et non face à un ensemble que vous fournissez : elle répond donc à une autre question. C'est l'exemple résolu imprimé par la spécification qui sert de vecteur de test.

Pourquoi est-ce gratuit ?

Tout fonctionne dans votre navigateur. Analyser un en-tête et comparer des chaînes ne coûte rien lorsque c'est votre propre machine qui s'en charge : il n'y a donc aucun serveur à financer, ni aucune raison de vous demander quoi que ce soit.

Rien de ce que vous saisissez n'est envoyé, conservé ni journalisé. Un en-tête tiré de journaux de production peut identifier une personne, et la manière sûre de traiter cela est de ne pas le recevoir. Pas de compte, pas d'inscription, aucune limite au nombre de vérifications.