Accesskey n springt zur Seitennavigation. Springe zum Inhalt.

Dieses Dokument ist eine Übersetzung. Im Falle von Abweichungen oder Fehlern sollte das aktuelle englische Original als maßgeblich angenommen werden. Das W3C besitzt das Copyright am Original, wie unten beschrieben.

Übersetzer: Gunnar Bittersmann

s_gotoW3cHome Internationalisierung
 

Accept-Language für Regionaleinstellungen verwenden

Zielgruppe: Script-Entwickler (PHP, JSP u.a.), Webprojekt-Manager und alle, die Informationen über Regionaleinstellungen verwenden möchten

Frage

Ist es eine gute Idee, den HTTP-Accept-Language-Header zu verwenden, um die Regionaleinstellungen des Nutzers zu bestimmen?

Hintergrund

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 Hintergrund­wissen 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.

Antwort

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.:

Übrigens

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.

Sagen Sie uns, was Sie denken (auf Englisch).

Abonnieren Sie unseren RSS-Feed.

Neue Ressourcen

News auf der Startseite

Twitter (News auf der Startseite)

‎@webi18n

Literaturhinweise

Autor: Lloyd Honomichl, Lionbridge. Übersetzer: Gunnar Bittersmann.

Valides XHTML 1.0!
Valides CSS!
Kodiert in UTF-8!

Übersetzung der englischen Version vom 2003-09-17. Letzte Änderung der übersetzten Version am 2011-06-03 17:30 UTC.

Suchen Sie nach qa-accept-lang-locales im i18n-Blog, um alle Dokumentänderungen nachzuvollziehen.