Die meisten Aufgabenstellungen im Zusammenhang mit Globalen Websites handeln davon, wie die Darstellung von Webauftritten an Standort und/oder Sprache des jeweiligen Benutzers angepasst wird. Diese Anpassung ist jedoch nicht möglich, ohne ebendiese (Standort bzw. Sprache) zu kennen. Deshalb wollen wir uns hier zunächst mit den Grundlagen von Sprach- und Standort-Erkennung beschäftigen.

Führen wir uns zum Einstieg die Ausgangslage vor Augen, indem wir uns in die Rolle des Webservers versetzen (so merkwürdig dies klingen mag ;) und die Anfrage eines Clients – sprich: Browsers – betrachten. Auf dieser Basis sollen wir nun herausfinden, wo sich der Benutzer befinden. Und/oder welche Sprache er bevorzugt. Wobei der Spielraum für Ideen noch dazu eher begrenzt ist, denn verwenden können wir nur die Informationen, die der Browser mitteilt. Technisch gesagt: Uns stehen nur IP-Adresse und HTTP-Header zur Verfügung. (Die einzige andere Möglichkeit wäre, nach mehr Informationen zu fragen – und auf Auskunft zu hoffen.)

Somit sind die wichtigsten Ansätze, die in diesem Artikel erklärt und diskutiert werden sollen:

• Ermittlung anhand der IP-Adresse des Clients
• Ermittlung anhand des HTTP-Headers
• Durch den Browser übermittelter Standort („HTML5 Geolocation“)
• Manuelle Auswahl durch den Benutzer
• Regional unterschiedliche Website-Domains

Wie so oft gibt es hier keine Patentlösung, sondern jeder Ansatz hat seine Vor- und Nachteile. Schauen wir also zunächst, was jeder dieser Ansätze wirklich bedeutet und welche Einsatzvarianten es gibt. Die Erkenntnisse werden wir dann zu einer Best Practices – Liste zusammenfassen.

Ermittlung anhand der IP-Adresse des Clients

Es ist allgemein bekannt, dass es große Datenbanken gibt, die IP-Adressbereiche zu Standorten zuordnen (sprich: zu Breiten- und Längengrad, teilweise auch gleich mit Stadt und Land dieses Standorts). Und natürlich werden solche Datenbanken dazu genutzt, den Standort eines Browsers zu bestimmen. Wer das noch nicht selbst probiert hat, kann z.B. ip2location.com verwenden, eine von unzähligen Webseiten, die IP-Standortbestimmung als Service anbieten.

Diese Grundidee wird auch Geotargeting genannt, und wird in vielen Bereichen auch außerhalb unseres Themas, der Optimierung von Globalen Webseiten, verwendet. Beispiele hierfür sind: Wiedergabebegrenzungen für Bild und Ton, Schutz vor Phishing, oder auch gezielte Anzeigenschaltung. (Weitere Informationen zu diesem Thema finden sich im Wikipedia-Artikel zu Geotargeting.)

Wenn wir dies nun auf dem Webserver implementieren, sähe der Ablauf so aus:

„Nimm die IP-Adresse des Absenders der HTTP-Anfrage, und schlage sie in der Datenbank nach, um herauszufinden woher der Nutzer kommt“

Implikationen:

• Ein Stück Software muss auf dem Webserver installiert sein, um diese Logik abzubilden.
• Diese Software muss (direkt oder mittels eines Online-Dienstes) auf eine Geo-Lokations-Datenbank zugreifen.
• Die herausgefundenen Standorte können sehr präzise sein, bis hin zu Gebieten innerhalb von Städten.
• Allerdings kann die Datenbank auch falsche oder veraltete Einträge enthalten, was zu falschen Ergebnissen führen würde.
• (Die verfügbaren Datenbanken sind von unterschiedlicher Qualität; i.d.R. kann von kommerziellen Datenbanken bessere Genauigkeit erwartet werden als von kostenfreien.)
• Die tatsächliche IP-Adresse des Browsers kann durch ein Gateway verborgensein. Wenn der Zugang z.B. durch eine Firewall, NAT Router, Proxy Server, VPN oder ähnliches erfolgt, dann wird die Adresse ebendieses Gateways ermittelt werden, und nicht die IP des Browsers.

(Tipp: In einigen Fällen können spezielle HTTP-Header wie z.B. „X-Forwarded-For“ genutzt werden, um dieses Problem zu umgehen).

1. Auch wenn dieses Ermittlungsverfahren sich auf den Standort bezieht, lassen sich daraus natürlich auch gute Schlüsse über mögliche Sprachen ziehen.

Um ganz exakt zu sein: Alles oben Genannte muss nicht auf dem Webserver selbst installiert sein – es könnte genauso gut auf einem Load Balancer platziert sein, der vor den eigentlichen Server geschaltet ist. Was allerdings eher die Ausnahme wäre.

Und wenn wir schon gerade von Load Balancern sprechen: Es gibt eine weitere Variation des gleichen Grundprinzips, nämlich der Verwendung der IP-Adresse des Clients, ist das Global Server Load Balancing (GSLB). Im Unterschied zum bisher Beschriebenen wird hier nicht die eigentliche HTTP-Anfrage zur Standortermittlung genutzt, sondern die DNS-Auflösung, welche der HTTP-Anfrage vorausgeht. Und das funktioniert wie folgt:

„Wenn eine neue URL in den Browser eingegeben wird, wird der Browser zunächst den Hostnamen mittels des DNS Protokolls die zugehörige IP-Adresse herausfinden. Im Fall von GSLB wird der angefragte DNS-Server aber nicht bei jeder Anfrage dieselbe IP-Adresse zurücksenden. Vielmehr wird er zunächst den Standort des Computers ermitteln, von welcher die DNS Anfrage ausgeht. Hierzu wird die passende IP Adresse ermittelt und als Antwort an den Browser gesendet. Von hier an kontaktiert der betreffende Browser nun somit einen speziell ausgesuchten Webserver, statt dass alle Benutzer zum gleichen Webserver geschickt werden.“

Implikationen sind hier:

• GSLB kann mittels eigener, nicht übermäßig teurer, Infrastruktur implementiert werden, oder als Service genutzt werden.
• Clients können an die jeweils geographisch nächstgelegenen Server weitergeleitet werden. Dieser Aspekt wird vor allem zur Verbesserung der Antwortzeiten genutzt. So arbeiten übrigens auch Content Distribution Networks (CDNs).
• Verborgene Adressen sind auch hier ein Thema: Wenn der Browser einen statischen DNS Server nutzt, wird es dessen IP sein, nach welcher der GSLB den passenden Server auswählen wird – und nicht die des Browsers. Wenn der Standort dieser DNS sich also signifikant vom Standort des Browsers unterscheidet, wird es zu verzerrten Ergebnissen kommen: Zum Beispiel könnte ein Computer in Europa einen öffentlichen DNS in den USA nutzen.

(Auch hier wird an Lösungen gearbeitet, die das Problem umgehen sollen – siehe den „EDNS-Client-Subnet“ Entwurf. Welcher bereits testweise implementiert wird, aber eben noch nicht vollständig Realität ist.)

Ermittlung anhand des HTTP-Headers

Wie schon erwähnt: Ein anderer Ansatz ist es, die Daten zu nutzen, welche der Browser in seiner HTTP-Anfrage (genauer: im HTTP-Header) mitgibt.
Heutzutage bedeutet das in der Praxis: Die Sprachpräferenz, die vom Benutzer als Standard im Browser eingestellt ist. Mein Chrome-Browser z.B. übermittelt folgenden HTTP-Header-Eintrag:

Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3

(In älteren Browserversionen gab es noch andere Sprach-Indikatoren, allerdings sind diese mittlerweile irrelevant. Netter Text dazu von Nichalos C. Zakas: „History of the user-agent string“.)

Wie dem auch sei: Informationen zur Standard-Sprache sind in den allermeisten Fällen verfügbar und können leicht durch die Web-Anwendung ermittelt werden, z.B. in PHP per $_SERVER[HTTP_ACCEPT_LANUAGE“].

Die Implikationen dieses Ansatzes sind:

• Die bevorzugte Sprache des Benutzers sagt nichts über seinen tatsächlichen Standort aus. Ein Nutzer, der z.B. „Englisch“ eingestellt hat, könnte auch in Indien oder Irland leben; ein Nutzer mit „Spanisch“ könnte sich in Uruguay oder in den USA befinden.
• Außerdem ist es ist wichtig zu beachten, dass die Spracheinstellungen der Nutzer nicht immer wirklich sinnvoll gesetzt sind, besonders in kleineren Länder – sprich: Ein Nutzer könnte hier „Englisch“ eingestellt haben, obwohl es sich dabei in Wirklichkeit nur um seine „zweite Wahl“ handelt.

Durch den Browser übermittelter Standort („HTML5 Geolocation“)

Mit der JavaScript-Methode „getCurrentPosition()“ kann der Browser aufgefordert werden, dem Server seinen Standort mitzuteilen. Dieses Verfahren wird als HTML5 Geolocation bezeichnet.

Doch woher kennt der Browser seinen eigenen Standort überhaupt? Die Geo API Spezifikationen beschreiben dies anschaulich:

„Die API selbst kümmert sich nicht um die Quellen der Standortinformation. Übliche Quellen sind GPS sowie die Ortszuordnung von Netzwerk-Signalen wie der IP-Adresse, RFID, WLAN und Bluetooth MAC Adressen, Mobilfunk-IDs, sowie manuelle Eingaben des Benutzers selbst. Ob die API die wirkliche Position des Geräts liefert, ist dadurch nicht garantiert.“

Mit anderen Worten: Es ist Sache des Browsers, den eigenen Standort herauszufinden, während die API lediglich ein Mittel für den Webserver ist, diese Informationen zu anzufordern und zu erhalten. Wie funktioniert dieses Herausfinden in aktuellen Browsern? In Mobiltelefonen zum Beispiel ist das einfach: Häufig wird GPS verwendet, oft in Kombinationen mit anderen Daten („Assisted GPS“).

Aber wie funktioniert das mit einem normalen PC, z.B. mit einem Firefox Browser? Nun, letzterer wird die ihm zur Verfügung stehenden Informationen einsammeln – namentlich SSIDs und MACs von umliegenden WiFi „Routern“. Diese Daten werden dann an einen externen Service gesendet (z.B. Google Location Services). Dieser versucht daraus, sowie aus der Absender-IP der Anfrage, möglichst genauen den Standort zu ermitteln, und sendet das Ergebnis an den Browser zurück. Welcher selbiges schließlich an den Server weiterleitet.

Zur Veranschaulichung hier ein Beispiel, wie die gesammelten Informationen aussehen könnten:

GET /maps/api/browserlocation/json?browser=firefox&sensor=true

&wifi=mac:10-9a-dd-8e-5e-85%7Cssid:myhotspot%7Css:-60

&wifi=mac:10-9a-dd-8e-4d-86%7Cssid:anotheraccesspoint%205%20GHz%7Css:-67

&wifi=mac:00-14-85-1b-10-5b%7Cssid:yetanother%7Css:-72

HTML5 Geolocation liefert großartige Qualität in der Genauigkeit der Standortbestimmung. Es gibt jedoch einen bedeutenden Nachteil:

• Der Benutzer muss der Anfrage zustimmen, das seinen Standort ermittelt und übertragen werden darf. Was er wohl tun wird, er zum Beispiel das nächstgelegene Sushi-Restaurant sucht. Doch ansonsten wird die Anfrage oft als Schnüffelei aufgefasst und daher in der Mehrzahl der Fälle abgelehnt. Damit wird HTML5 Geolocation nahezu nutzlos für unser Thema!

Der Nutzer muss der HTML5 Geolocation-Anfrage zustimmen

Manuelle Auswahl durch den Benutzer

Gar nicht so selten sieht man die Technik… auf eine technische Lösung zu verzichten, sondern den Anwender zu fragen!

Dieses Vorgehen bietet sich besonders in solchen Fällen an, in denen die anderen Ansätze verstärkt Probleme haben:

• Bei Anwendern, die auf Reisen sind, wird die Standorterkennung nicht ihren Heimat-Standort wiedergeben. Welcher aber oft der eigentlich relevante Standort ist.
• Darüber hinaus wird bei Anwendern, die auf Reisen fremde Computer benutzen (etwa Internetcafés, PCs in Hotels usw.), selbst die Browsersprache falsche Ergebnisse produzieren.

Folglich findet man die manuelle Auswahl durch den Benutzer besonders oft auf solchen Webseiten, die mit Reisen bzw. Tourismus zu tun haben. Hier ein Beispiel:

Standort- und Sprachauswahl im Webauftritt der Emirates Airline

Regional unterschiedliche Website-Domains

Es gibt noch eine weitere Methode, die in der Praxis vorzufinden ist, und zwar die „triviale“: Es werden einfach komplett eigenständige Internetadressen für unterschiedliche Regionen zur Verfügung gestellt. Oft wird dies mit jeweils lokalen Top Level Domains erreicht („TLD“, sprich die Endungen z.B. in „ourwebsite.jp“ oder „ourwebsite.au“.) Manchmal werden allerdings auch komplett unterschiedliche Domains verwendet (wie z.B. „ourwebsite-asia.com“, „ourwebsite-southamerica.com“.)

Auch wenn dies nicht der Idee der „Global Website“ im engeren Sinne entspricht, wollen wir trotzdem einen Blick auf die Vor- und Nachteile werfen:

• Das Konzept kann nur wirklich gut funktionieren, wenn „pro Land“ gearbeitet wird. Das bedeutet entweder, die Zielgruppe auf wenige Länder zu beschränken, oder eine enorm große Anzahl von Domains zu verwalten – oder zu akzeptieren, dass der Webauftritt aus mehrerlei Gründen für viele Nutzer suboptimal funktioniert, weil
  a) ihre eigene TLD nicht vorhanden ist, ein Zugriffsversuch also fehlschlägt,
  b) sie stattdessen die TLD eines anderen Landes benutzen müssen,
  c) sie auch noch raten müssen, welche fremde TLD die richtige ist.
• Außerdem werden Nutzer weiterhin versuchen, die .com-TLD zu verwenden. Sofern die .com-Adresse überhaupt existiert, wären also auch diese Fälle abzufangen.
• Selbst bei eindeutiger TLD kann sich die Frage der richtigen Sprache stellen– man denke nur an .ch für „Schweiz“. Hier hilft der gewählte Ansatz dann ebenfalls nicht weiter.
• Und schließlich wird die Verwendung unterschiedlicher Domains als schlechte SEO-Praxis angesehen und dürfte zur Verschlechterung des Suchmaschinen-Rankings führen.

Was also tun?

Fassen wir zusammen: In diesem Blogeintrag haben wir die Ermittlung sowohl des Standorts als auch der Sprache untersucht, welche zwar in Zusammenhang stehen, aber nicht identisch sind. Dabei wurden bewusst die Ziele der ganzen Anstrengungen ausgeblendet, ebenso wie mögliche darauf aufbauende Maßnahmen. Doch in der Praxis gilt: Ohne ebendiese Hintergründe ist es gar nicht möglich, die optimale Wahl aus den oben vorgestellten Verfahren zu treffen.
Dennoch ist das gute Verständnis der dargestellten Prinzipien mit Ihren Vor- und Nachteilen natürlich Voraussetzung für die fundierte Konzeption. Ergänzend hier meine persönlichen Best Practices:

• Wenn ein Besucher zum ersten Mal auf die Webseite kommt, sollte die Ermittlung durchgeführt werden. Und zwar nicht nur auf der Startseite, sondern auf allen Seiten des Internetauftritts (Caching beachten – aber unnötige Performanceverluste vermeiden!)
  Diese Maßnahme ist besonders nützlich angesichts der Tatsache, dass viele Benutzer von „außen“ (Suchmaschinen, Blogs, Twitter, Facebook, eigene PR usw.) kommen, und so möglicherweise auf die falsche Version geraten.
  Beispiel: Selbst wenn der Nutzer www.testco.biz/us/pricelist/ anfragt, soll er unter Umständen doch auf www.testco.biz/uk/pricelist/ weitergeleitet werden.
• Auch neutrale Links wie z.B. „www.testco.biz/pricelist/“ sollten ermöglicht werden. Sie bieten sich für alle nicht-lokalen Dokumente und Kommunikationskanäle an, und sehen für den globalen Nutzer einfach besser aus.
• Der Anwender sollte die Möglichkeit haben, Standort- und Spracheinstellungen manuell zu ändern. Die getroffene Auswahl sollte persistiert, also auch bei späterer Rückkehr berücksichtigt werden.
• Je nach Situation kann es sinnvoll sein, die ermittelten Werte (Standort/Sprache) durch den Benutzer bestätigen zu lassen.
• Für bestmögliche Ergebnisse können mehrere Verfahren kombiniert werden, z.B. die Ermittlung des Standorts sowie der Browser-Spracheinstellung.