Ist es eine gute Idee, den HTTP-Accept-Language-Header zu verwenden, um die Regionaleinstellungen des Nutzers zu bestimmen?
Aus völlig legitimen Gründen möchten einige Webanwendungen Regionaleinstellungen für jeden Nutzer vornehmen, der die Website besucht. Durch diese Einstellungen können Informationen im jeweiligen Format angegeben werden. Einige dieser Regionaleinstellungen für Informationen treten häufig in Software auf, z.B.:
In anderen Fällen können weitere Informationen aus den Regionaleinstellungen und zusätzlichem Hintergrundwissen gewonnen werden, z.B.:
Weil nichts davon im HTTP-Protokoll enthalten ist, benutzen viele Webentwickler den Accept-Language-Header, um auf Regionaleinstellungen des Nutzers zu schließen.
Der Accept-Language-Header enthält die Information über die vom Nutzer bevorzugten Sprachen, die per HTTP übermittelt wird, wenn ein Dokument angefordert wird.
Gängige Browser erlauben es dem Nutzer, seine bevorzugten Sprachen einzustellen. Der
Wert für diese Angabe wird definiert durch BCP 47, üblicherweise als ein zwei- oder dreibuchstabiger Sprachcode (z.B. fr für
Französisch), gefolgt von optionalen Kürzeln für Länder o.a. (z.B. fr-CA steht für
Französisch, wie es in Kanada gesprochen wird).
Die Frage ist, ob diese Information dazu geeignet ist, die Regionaleinstellungen des Nutzers zu bestimmen.
Der HTTP-Accept-Language-Header ist ursprünglich nur dafür gedacht, die Sprache des Nutzers anzugeben. Weil aber viele Anwendungen Regionaleinstellungen benötigen, ist es gängige Praxis, diese Information aus Accept-Language zu gewinnen. Es ist aber keine gute Idee, den Accept-Language-Header allein zu verwenden, um die Regionaleinstellungen des Nutzers zu bestimmen. Wenn man ausschließlich Accept-Language verwendet, drängt man dem Nutzer womöglich Einstellungen auf, die er nicht will.
Fürs erste mag Accept-Language ein guter Ausgangspunkt für Regionaleinstellungen sein. Man sollte dem Nutzer aber erlauben, die Sprache zu wechseln und seine Einstellungen bei Bedarf anzupassen. Für spätere Besuche der Webseite können die Daten in einer Datenbank oder einem Cookie gespeichert werden.
Mögliche Probleme sind u.a.:
de-DE, de-CH oder de-AT für Deutsch, wie es in Deutschland, der Schweiz bzw. Österreich gesprochen wird, sondern man könnte nur de erhalten, was Deutsch als bevorzugte Sprache angibt. Wenn man gedacht hatte, die Region zu nutzen um zu entscheiden, welche Währung man verwenden sollte, steckt man in der Klemme.
Die jeweiligen Umstände mögen es erlauben, solche Annahmen zu treffen wie: Deutschland hat 83 Millionen Einwohner, die Schweiz hat 7 Millionen,
von denen nur 63% deutsch sprechen, Österreich hat 8 Millionen, also verwendet dieser Nutzer wahrscheinlich den Euro. Dass dies nicht immer so ist, betrifft nur 4,6% unserer deutschsprachigen
Kunden bzw. nur knapp über 4 Millionen Menschen. Machen Sie solche Annahmen, wenn Sie das Risiko tragen können. Es ist weitaus einfacher, den Nutzer
nach weiteren Informationen zu fragen. Die Abschätzung wird auch schwieriger für bspw. Spanisch oder Englisch.Der Accept-Language-Header ist auch ein guter Ausgangspunkt, um die Sprache des Nutzers zu bestimmen, mehr noch als die Region. Aber auch dann muss man dessen Grenzen kennen und dem Nutzer die Möglichkeit geben, die getroffenen Annahmen zu ändern. Viele der oben angeführten möglichen Probleme treffen auch hier zu.
Auch wenn man nicht bewusst Annahmen zu Regionaleinstellungen des Nutzers macht, sollte man sich bewusst sein, dass die Softwareumgebung möglicherweise solche Annahmen trifft. Viele Webserver, serverseitige Scriptsprachen und Systemumgebungen befüllen ihre Regionaleinstellungs-Objekte anhand Accept-Language. .NET bspw. verwendet Accept-Language für die Grundeinstellung von CultureInfo, Java Servlet bietet das Methodenpaar getLocale() und getLocales(), die Accept-Language auswerten, usw. Diese Objekte sind sehr nützlich bei Ressourcen und anderen Materialien, bei denen Spracheinstellungen eine Rolle spielen. Sie sind, wie oben gesagt, weniger brauchbar zur Feinbestimmung vieler Nutzereinstellungen oder zur Bestimmung des Verhaltens einer internationalen Website. Wenn es-MX als bevorzugte Sprache eingestellt ist, heißt das nicht zwangsläufig, dass eine Postadresse als mexikanische Adresse formatiert oder geprüft werden soll. Der Nutzer kann dennoch in den USA (oder sonstwo) leben.