Accept-Language-Aushandlung und ihre Grenzen

Worum es geht

RFC 9110 definiert Accept-Language als eine Liste von Sprachbereichen mit optionalen Qualitätswerten: da, en-gb;q=0.8, en;q=0.7 bedeutet "ich bevorzuge Dänisch, akzeptiere aber britisches Englisch und andere Varianten von Englisch". Auf die Reihenfolge gleich gewichteter Einträge ist kein Verlass. Der Abgleich wird an RFC 4647 delegiert: Basic Filtering behandelt einen Bereich als Präfix (de passt auf de-CH), Lookup findet das eine beste Tag, indem der Bereich von rechts her gekürzt wird (de-CH-1996, dann de-CH, dann de). Ein fehlender Header drückt keine Präferenz aus und überlässt die Wahl dem Server. Ein User Agent, der keine Nutzerkontrolle über die Präferenz bietet, DARF den Header NICHT senden, und der RFC weist auf die Datenschutzkosten hin, wenn bei jeder Anfrage vollständige Präferenzen mitgeschickt werden. Die Antwort nennt ihre Sprache in Content-Language und braucht, weil sie je nach Anfrage-Header variiert, Vary: Accept-Language für Caches.

Warum es wichtig ist

Der Header beschreibt eine Geräte- oder Browserkonfiguration, nicht zwingend die lesende Person: gemeinsam genutzte Rechner, Unternehmens-Images und Reisende senden allesamt das Falsche. Googles Dokumentation hält fest, dass ihr Crawler Anfragen ohne Accept-Language sendet, warnt, dass er möglicherweise nicht allen Inhalt für verschiedene Locales crawlt, indexiert oder rankt, und empfiehlt separate URLs je Locale mit hreflang-Angaben; nur über den Header ausgewählter Inhalt kann deshalb in manchen Sprachen unentdeckt bleiben. Skripte und Agenten senden meist nichts. Ein Cache, der Vary ignoriert, liefert allen die zuerst gespeicherte Sprache aus.

So wird es angewendet

• Jeder Sprache eine eigene URL geben (/de/, /en/) mit hreflang-Alternativen; den Header nur nutzen, um zu bestimmen, wohin ein Besuch der sprachneutralen Wurzel geleitet wird, mit einer temporären Weiterleitung und Vary: Accept-Language, nie mit einer dauerhaft gecachten.
• Lookup implementieren: exaktes Tag, dann primäre Sprache, dann der Standard der Website; * und einen fehlenden Header als Standard behandeln.
• Eine explizite Wahl speichern (Cookie oder Profil) und sie bei jedem späteren Besuch den Header überschreiben lassen.
• Bei APIs einen dokumentierten lang-Parameter akzeptieren, der den Header überschreibt, und stets Content-Language zurückgeben.
• Die Sprache nicht aus der IP-Adresse ableiten; Länder sind mehrsprachig.

Stolpersteine

Eine Anfrage nach en-GB gegen eine Website, die nur en hat, scheitert bei Basic Filtering, weil das Tag kürzer ist als der Bereich; Lookup behandelt diesen Fall, und RFC 9110 merkt an, dass User Agents einer solchen Liste eigentlich en hinzufügen sollten. Gleich gewichtete Qualitätswerte mit stillschweigender Reihenfolge unterscheiden sich zwischen Clients. Die Sprachaushandlung sagt nichts über regionsspezifische Formate aus; die Locale für Datums- und Zahlenformate getrennt behandeln.