2010-03-30 // Internationale, mehrsprachige Websites: Content Negotiation to the rescue?

Eigentlich sollte es heute kein Problem mehr sein: internationalisierte Websites in verschiedenen Sprachen. Oder – falls keine vollständige Internationalisierung¹⁾ nötig ist – zumindest die Anzeige des gleichen Inhalts in den jeweiligen nativen Sprachen. Doch die Aufgabe ist komplizierter als man denkt und in großen Teilen des Webs nur mangelhaft gelöst.

Ein Weg aus der Misere kann Content Negotiation darstellen, dieser Text setzt sich damit auseinander.

Ich arbeite in der Webbrache. Werden Umsätze online generiert ist je nach Projektausrichtung jeder Nutzer wichtig. Trotz offensichtlicher Dominanz der englischen Sprache wäre es daher ein grober Fehler Lokalisierungen links liegen zu lassen. Das Internet ist mittlerweile bei der breiten Masse angekommen, 2009 wurden mehr als 50% der Google Suchanfragen in anderen Sprachen als Englisch gestellt, 33% davon in einer europäischen Sprache,²⁾ Tendenz steigend. Der e-Commerce-Markt Europa ist riesig und sofern eine Website in der nativen Sprache vorliegt, kaufen Benutzer vier mal häufiger online ein und verbringen mehr als doppelt so viel Zeit auf ihr.³⁾
Außerdem hat man im Web vornehmlich mit in den USA ansässigen Unternehmen zu konkurrieren, welche Lokalisierungen oft gänzlich oder sehr lange vernachlässigen – so kann man sich mit lokalisierten Projekten einen Vorteil auf nicht-US-Märkten verschaffen. Manchmal funktioniert dies sogar, wenn man ansonsten viel schlechter ist – ein StudiVZ wäre meiner Meinung nach niemals möglich gewesen, wenn Facebook sich von Beginn an mehr um übersetzte Versionen der eigenen Seite inkl. Marketing gekümmert hätte.⁴⁾

Das Thema ist also wichtig und ein paar Gedanken wert.

Die meiste gängige Web-Software ist mit der Verwaltung eines Dokuments in mehreren Versionen ziemlich überfordert oder entsprechende Features für nicht-Techniker kaum zu bedienen. Oft existiert lediglich kein Problembewusstsein, da einfach in der jeweiligen Muttersprache veröffentlicht wird oder gar das ganze Projekt für jede Sprache auf einer spezifischen Länderdomain parallel gepflegt wird. Letzteres sorgt aber mit Garantie für höheren Wartungsaufwand (→ parallele Infrastrukturen), mehr Kosten (→ Domains, Infrastruktur) und manchmal sogar redundanten Code (denn nicht immer arbeitet man mit Systemen, der Architektur man komplett selbst beeinflussen kann). Zudem bergen parallele Strukturen die ständige Gefahr, dass veraltete Inhalte entstehen oder nicht alle Inhalte auf allen Plattformen verfügbar sind, was wiederum aufwendige Synchronisation bedingt. Diese Probleme können die eigentliche Übersetzung von Inhalten bezüglich Aufwand als auch Kosten leicht um ein Vielfaches übersteigen.

Daher wird oft komplett auf Übersetzungen verzichtet oder vieles ausschließlich in Englisch veröffentlicht, um mit einer Inhaltsversion möglichst viele Menschen zu erreichen (So handhabe ich das auch hier mit diesem Blog). Englisch hat eben nicht nur den Vorteil, dass mit den USA, Australien, Großbritannien etc. schon eine ganze Menge Menschen beisammen sind (das wäre mit z.B. Spanisch ebenso der Fall), sondern dass eben sehr viele Menschen Englisch als Zweitsprache gut genug verstehen, um an die präsentierten Informationen in hinreichender Qualität zu gelangen. Nichts desto weniger vergrault man Leser, Nutzer und Kunden, welche ggf. mit dem Projekt ansonsten glücklich wären.
Für kleinere Websites und private Projekte wie dieses Blog mag das kein Problem sein (vorallem wenn keine kommerziellen Interessen verfolgt werden). Doch auch Konzerne mit viel Geld haben ähnliche Probleme (und die grottigen Internationalisierungen und Websites die außer toller Grafiken und Marketing-Sprech nichts bieten, sind der Beweis dafür). Sie können sich das oft nur leisten, weil das eigentliche Geschäft Offline stattfindet.⁵⁾

Für Web-Unternehmen ist das freilich kein Trost. Doch vielen kann mittels Content Negotiation geholfen werden, solange man die Fallstricke kennt.⁶⁾

Technisch sind mehrere Übersetzungen in den Griff zu bekommen, Content Negotiation heißt das entsprechende Stichwort. Es beschreibt das Vorgehen, dass die Website http://example.com/foobar je nach Spracheinstellung des Besuchers (→Accept-Language-Header) den Inhalt in der jeweils passenden Sprache anzeigt. Falls keine passende Übersetzung vorhanden ist wird auf einen Fallback zurückgegriffen, meist Englisch.

Die Vorteile liegen auf der Hand: Man hat eine Infrastruktur ggf. sogar unter lediglich einer Domain zu pflegen. Auch hinsichtlich der Aktualität und Flexibilität wäre man im Grunde aus dem Schneider, da bei fehlenden Übersetzungen ohne Aufwand zumindest aktueller “Fallback”-Inhalt in Englisch angezeigt werden kann. Im schlechtesten Fall steht man also immerhin genauso gut da wie ein Konkurrent, der ausschließlich englischsprachige Inhalte anbietet – so kann schnell reagiert und nach und nach ergänzt werden.

Mittels Content Negotiation kann man also dafür sorgen, dass der Besucher immer die vermeintlich geeignetste Übersetzung erhält. Damit das alles klappt und auch Proxies etc. nicht verwirrt werden teilt man über den Vary-Header mit, dass der Inhalt Aufgrund bestimmter vom Client gesendete Daten verändert wurde (z.B. mit dem Wert Negotiate,Accept-Language).

Zusammen mit einer manuellen Sprachauswahl auf der Website selbst (welche die Präferenz z.B. via Cookie speichert) wäre die Lösung IMHO fast perfekt, sofern man davon absieht, dass die URLs selbst natürlich nicht lokalisiert sind (→ http://example.com/free vs. http://example.com/kostenlos). Damit die URLs vorhersehbarer sind, könnte man noch diverse Alias-Seiten anlegen und mittels 301 Moved Permanently-Weiterleitungen und/oder Tags wie <link rel="canonical" href="http://example.com/page.html"/>⁷⁾ dafür Sorgen, dass Suchmaschinen nur die gewünschte URL in den Index aufnehmen.

Kurzusammenfassung:

• Der Accept-Language-Header des aufrufenden Clients wird analysiert.
• Die enthaltenen, gewichteten IETF-Language-Tags werden ausgewertet und basierend darauf die passende Übersetzung/Lokalisierung ausgeliefert.
• Damit der Client wahrnimmt was passiert und Proxies weniger Probleme bereiten, sollte serverseitig der Vary-Header verwendet werden.
• Die “Duplicate Content”-Problematik bekommt man ohne Probleme mittels 301-Redirects und <link rel="canonical"> in den Griff.
• Beispiel: http://example.com/content.html wird aufgerufen mit einem Browser, welcher Accept-Language mit dem Wert de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 sendet. Deswegen wird die Seite in Deutsch ausgeliefert und über Vary mit dem Wert Negotiate,Accept-Language mitgeteilt, das das Ergebnis mit einem anderem Accept-Language-Wert anders aussehen könnte.

Ich denke mittels “reinem” Content Negotiation kommen viele Lösungen aus (für reine Intranet-Software würde ich sofort darauf zurückgreifen). Man sollte vor einem Internet-Einsatz allerdings die Nachteile kennen, und sich in der technischen Realisierung auf einen gewissen Mehraufwand einstellen, um einen Workaround zu realisieren (womit Content Negotiation nicht mehr ganz so elegant ist ):

• Google ignoriert den ''Vary''-Header, Yahoo! ebenso.
  Indiziert wird daher lediglich die Sprachversion, die der jeweilige Crawler/Bot angefordert hat. Die Bots von Google und Yahoo! geben sich selbst als englischsprachig aus und “sehen” daher nur die englische Version der bereitgestellten Inhalte. Man kann das Problem damit beschreiben, dass Suchmaschinen “eine URL, eine Version des Dokuments” fordern.⁸⁾
• Die Folge sind weniger Besucher durch nicht-englischsprachige Suchanfragen
  Z.B. solche, die sich in den jeweiligen Sprachen stark unterscheiden. Internationale Produktnamen sind weniger das Problem aber “Fahrrad” und “Bicycle” wäre eines. Bei der Google-Suche kommt sogar noch hinzu, das viele Nutzer mit der Spracheinstellung “Seiten auf X” suchen, was die indizierten Inhalte u.U. komplett ausschließt. Sucht jemand über das deutschsprachige Google.de mit der Einstellung “Seiten auf Deutsch” wird er unsere nur auf englisch indizierten Inhalte nicht finden, obwohl eine deutsche Übersetzung verfügbar ist.

Die IMHO praxistauglichste Lösung dieser Problematik ist, Content Negotiation einzusetzen aber dennoch auf jeder Seite permanente URLs zu einer erzwungenen Sprache anzubieten (entweder über Unterverzeichnisse oder Subdomains). Selbige werden dann zusätzlich indiziert und decken Suchanfragen in den jeweiligen Landessprachen zuverlässig ab. Beispiel mittels Unterverzeichnissen:

• http://example.com/free – Content Negotiation-Version mit Englisch als Fallback, jeweils mit Links auf:
  • http://example.com/de/free – Deutsche Version
  • http://example.com/fr/free – Französische Version
  • […]
  • http://example.com/en/free – Englische Version (der Konsistenz wegen).
    Diese Version ist hinsichtlich der Suchmaschinen allerdings redundant und sollte ggf. auf http://example.com/free weiterleiten oder via <link rel="canonical"> auf diese Version verweisen. Man könnte auch mittels “noindex” ausschließen.

“Real-World”-Beispiel, direkt zum selbst ausprobieren – Die Apache-Webserver-Dokumentation:

• http://httpd.apache.org/docs/2.0/content-negotiation.html mit einen englischen und französischen Browser aufrufen⁹⁾ (Portable Firefox ist dafür ganz praktisch) oder den eigenen Browser umkonfigurieren. Obwohl die Sprachumschaltung perfekt klappt werden rechts oben noch sprachspezifische URLs angeboten:
  • http://httpd.apache.org/docs/2.0/en/content-negotiation.html
  • http://httpd.apache.org/docs/2.0/fr/content-negotiation.html
  • […]
• Man kann auch direkt vergleichen, was von Google.com bzw. Google.fr gefunden wird (man achte auf die URLs der Ergebnisse!):
  • entsprechende Suchanfrage in französischer Sprache mit der Einschränkung “Pages francophones”, welche ohne diese Technik ins Leere laufen würde, weil Google nur die englischsprachige Version der Negotation-Seite indiziert
  • entsprechende Suchanfrage in englischer Sprache

Diesem Workaround kann man bei Bedarf sogar noch einen Vorteil abringen, indem die sprachspezifischen Links lokalisiert und so seine Schlüsselworte besser positionieren kann:

• http://example.com/free/
• http://example.com/en/free/
• http://example.com/de/kostenlos/

Die Lösung “Content Negotation + einzigartige URLs zu den Übersetzungen” ist in meinen Augen ein guter Kompromiss. Der Benutzer bekommt beim normalen Surfen immer möglichst kurze, universelle URLs präsentiert, die bei Weitergabe den jeweiligen Nutzer wiederum in der geeignetsten Sprache präsentiert werden. Bei Bedarf kann dennoch auf explizit eine Sprachversion verlinkt werden, Sprachspezifische Google-Suchen führen nicht ins Leere und man erhält bessere Page-Ranks, da ggf. doch mehr Nutzer auf ein und die selbe, universelle URL verweisen.