Apache-Tricks zur Website-Lokalisierung

Heute schauen wir uns mal ein eher technisches Thema an: Und zwar vergisst man ja allzu leicht, wie mächtig der weitverbreitete Apache eigentlich ist, daher möchte ich ein paar Anregungen darstellen, quasi als Ausgangspunkt für den Apache als Schweizer Messer der Website-Lokalisierung.

Die zentrale Idee ist, dass Apache bestimmte Kriterien auswertet, und dass Apache daraufhin in unserem Sinne eingreift.

Warum man das mit Apache tun will, statt auf CMS-Ebene (oder generell: per Web-Applikation)?

  • Riesiger Geschwindigkeitsvorteil: Apache hilft uns, Caching viel besser einzusetzen, indem unnötige Zugriffe gar nicht erst zum CMS gelangen.
  • Noch ein Geschwindigkeitsvorteil: Apache ist für solche Dinge generell wesentlich schneller als jede Anwendung in einer Hochsprache (Java, PHP,…)
  • Kein Programmieraufwand: Apache kann hier Dinge leisten, die viele Anwendungen standardmäßig gar nicht beherrschen, sprich: Die erst entwickelt werden müssen .

Was kann Apache auswerten?

Oben sagte ich ja, “dass Apache bestimmte Kriterien auswertet” – aber welche wären das?

Erinnern wir uns zunächst an die fünf Signale, die für Lokalisierungs-Entscheidungen von Interesse sein können:

Weiterlesen

“hreflang”: Besucher schon bei Google richtig leiten

Hat man mehrere Sprach- und/oder Regionsversionen einer Webseite, so besteht ein klassisches Problem ja darin, dass Besucher per Google-Suche möglicherweise  Links angezeigt bekommen, die sie zu einer falschen Version führen. Sprich: Sie sehen unnötigerweise falsche Sprachen, möglicherweise abweichende Kontaktdaten und andere Inhalte, vielleicht sogar falsche Spezifikationen oder gar Preise.

Was tun? Prinzipiell haben wir zwei Möglichkeiten:

  1. Auf dem Webserver jede Anfrage prüfen, ob sie auf der richtigen Version gelandet ist (und bei Bedarf umleiten), oder
  2. dafür sorgen, dass Google seine Links zu unserer Seite dynamisch an Sprache und Standort des Besuchers anpasst und ihn also gleich auf die richtige Version schickt.

Für letzteres ist “hreflang” das zentrale Stichwort, was hier einmal genauer erklärt werden soll.

Weiterlesen

Eine schlanke Alternative zur vollständigen Lokalisierung

Für kommerzielle Webauftritte ist ein wichtiger Grund für die Lokalisierung in der Regel eine einfache Botschaft an den Kunden:

Ja, wir sind ein geeigneter Partner für Dich! Wir sind in Deinem Markt präsent. Wir kennen ihn, wir haben dort Erfahrung und auch die nötigen Prozesse implementiert. Du bist uns wichtig!

Nun kann man natürlich die vollständige Lokalisierung als den perfekten Weg ansehen, diese Botschaft zu unterstützen, noch dazu wenn er von lokalem Personal unterstützt wird. Andererseits ist dieser Ansatz oft schlicht zu teuer; effizient oder gar das Optimum ist er eher selten bzw. nur für ausgewählte Märkte. Weiterlesen

SPDY für das TYPO3 Backend: Erstes Benchmark

SPDY (gesprochen “Speedy”) ist ein aktueller Ansatz zur Beschleunigung des Web-Datenverkehrs durch Einfügen einer ausgefeilten Zwischenebene zu den Netzwerkprotokollen (Wikipedia für Details und Links zu den einschlägigen Seiten und Standards.)

SPDY gibt es nun seit einiger Zeit, und inzwischen wird es von diversen sehr großen Websites wie Gmail und Twitter verwendet… Aber wie ist der praktische Nutzen, sprich: Geschwindigkeitsgewinn für den “normalen” Anbieter globaler Webauftritte?

Um mich dieser Frage zu nähern, habe ich mich dazu entschieden, ein bestimmtes Szenario herauszugreifen und zu überprüfen: Und zwar die Bedienung der TYPO3 CMS Redakteursoberfläche (Backend) aus großer Entfernung – man denke an den asiatischen Kollegen, der auf dem Server in Deutschland arbeiten und z.B. Übersetzungen einpflegen soll.

Also… habe ich ein Testsystem in Singapur aufgesetzt und Messungen von hier in Deutschland aus durchgeführt, mit und ohne SPDY. Hier sind die Ergebnisse.

Weiterlesen

Terminologie der Lokalisierung

Seit den ersten Beiträgen in dieser Serie hat Steffen Gärtner während seines Praktikums und seiner Bachelor-Arbeit bei der Bitmotion TYPO3 Agentur eine Menge “Grundlagenforschung” geleistet.

Eine Erkenntnis, die sofort klar wurde, war: Die übliche Begrifflichkeit ist eigentlich zu ungenau, um die Dinge exakt zu beschreiben.  Denn warum sollte mit der “Sprachversion” einer Website in Wirklichkeit eine Landesversion gemeint sein? Was, wenn sich die Themen Sprache und Land vermischen – wie nennen wir das? Um es kurz zu machen: Wir haben uns hingesetzt und uns trennschärfere Bezeichner gesucht, die dennoch handhabbar sind.

Hier sind die Resultate, die wir von jetzt ab verwenden werden. Weiterlesen

Bausteine der Website-Lokalisierung

Im letzten Beitrag haben wir uns damit beschäftigt, welche Informationen zu Sprache und Standort eines Webseiten-Benutzers verfügbar sein könnten, und auf welchem Wege. Heute steht nun die Frage im Vordergrund, was wir mit den Erkenntnissen anfangen können und wollen.
Dies führt im Grunde auf den Kern unseres Themas der„Optimierung von Globalen Websites“, was ich in gerne wie folgt umreiße:

a) Auslieferung von passenden Inhalten
b) in passender Darstellung
c) mit guter Performance

an Anwender überall auf der Welt (oder besser „auf Zielmärkten rund um den Globus“, um ganz genau zu sein).

Während Performance ein komplett eigenes Thema ist – und ein sehr spannendes, mit dem wir uns in einem Folgeartikel intensiv befassen werden – wollen wir hier einen Blick auf die einzelnen Komponenten von (a) und (b) werfen: Auf Inhalt und Darstellung, die für den Besucher gut funktionieren.

Weiterlesen

Geolocation und Sprache erkennen: Eine Einführung

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.

Weiterlesen

Willkommen!

Willkommen zu meinem neuen Weblog. Hier möchte ich Erfahrungen und Überlegungen rund um das Thema “Webauftritte für weltweite Nutzer” (oder doch zumindest für Nutzer in verschiedenen Regionen) teilen – und zwar für solche Fälle, wo man nicht alle Benutzer mit einer Einheitslösung “abspeisen” möchte. Mit anderen Worten, es geht um das Ermöglichen von global guter User Experience, von gleichmäßig guter Benutzbarkeit für Anwender in verschiedenen Teilen der Welt.

Weiterlesen