La négociation Accept-Language et ses limites

Ce que c'est

La RFC 9110 définit Accept-Language comme une liste de plages de langues assorties de valeurs de qualité optionnelles : da, en-gb;q=0.8, en;q=0.7 signifie « je préfère le danois, mais j'accepte l'anglais britannique et les autres types d'anglais ». L'ordre entre poids égaux ne peut pas être considéré comme fiable. La correspondance est déléguée à la RFC 4647 : le filtrage de base traite une plage comme un préfixe (de correspond à de-CH), la recherche (lookup) trouve la meilleure étiquette unique en tronquant la plage par la droite (de-CH-1996, puis de-CH, puis de). Un en-tête absent n'exprime aucune préférence et laisse le choix au serveur. Un agent utilisateur qui n'offre aucun contrôle de la préférence par l'utilisateur NE DOIT PAS envoyer l'en-tête, et la RFC souligne le coût pour la vie privée d'envoyer des préférences complètes à chaque requête. La réponse nomme sa langue dans Content-Language et, parce qu'elle varie selon un en-tête de requête, a besoin de Vary: Accept-Language pour les caches.

Pourquoi c'est important

L'en-tête décrit la configuration d'un appareil ou d'un navigateur, pas nécessairement le lecteur : ordinateurs partagés, images d'entreprise et voyageurs envoient tous une indication erronée. La documentation de Google indique que son robot d'indexation envoie des requêtes sans Accept-Language, avertit qu'il pourrait ne pas explorer, indexer ou classer tout le contenu pour les différentes locales, et recommande des URL distinctes par locale avec des annotations hreflang ; un contenu choisi uniquement par l'en-tête peut donc rester invisible dans certaines langues. Les scripts et les agents n'envoient généralement rien. Un cache qui ignore Vary sert à tout le monde la première langue qu'il a stockée.

Comment l'appliquer

• Donner à chaque langue sa propre URL (/de/, /en/) avec des alternatives hreflang ; n'utiliser l'en-tête que pour choisir où envoyer un visiteur arrivant sur la racine neutre en langue, avec une redirection temporaire et Vary: Accept-Language, jamais une redirection permanente mise en cache.
• Mettre en œuvre la recherche (lookup) : étiquette exacte, puis langue principale, puis valeur par défaut du site ; traiter * et l'en-tête absent comme la valeur par défaut.
• Stocker un choix explicite (cookie ou profil) et le laisser prévaloir sur l'en-tête à chaque visite ultérieure.
• Pour les API, accepter un paramètre lang documenté qui prévaut sur l'en-tête, et toujours renvoyer Content-Language.
• Ne pas déduire la langue de l'adresse IP ; les pays sont multilingues.

Pièges

Une requête pour en-GB sur un site qui ne propose que en échoue avec le filtrage de base, car l'étiquette est plus courte que la plage ; la recherche (lookup) la gère, et la RFC 9110 note que les agents utilisateurs devraient suggérer d'ajouter en à une telle liste. Des valeurs de qualité égales avec un ordre implicite diffèrent selon les clients. La négociation de langue ne dit rien des formats propres à une région ; traiter séparément la locale pour les dates et les nombres.