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 mit Juliane Wünsche

s_gotoW3cHome Internationalisierung
 

Wann es angebracht ist, Sprachvereinbarung (language negotiation) einzusetzen

Zielgruppe: Webmaster, Serveradministratoren und alle, die verstehen möchten, wie Inhaltsvereinbarung anhand der Sprache funktioniert.

Frage

Wann ist es angebracht und wann nicht, Sprachvereinbarung einzusetzen?

Hintergrund

° In deutschsprachigen Quellen wird oft die englische Bezeichnung „language negotiation“ beibehalten. In der deutschen Ausgabe Apache – Das umfassende Handbuch von B. & P. Laurie (O’Reilly) findet man „Sprachvereinbarung“. (Anm. d. Übers.)

Sprachvereinbarung (language negotiation)° ist eine Funktion des HTTP-Protokolls, die einen Server aus mehreren Sprachversionen einer Seite eine auswählen lässt, basierend auf der Information über die bevorzugten Sprachen, die der Browser übermittelt (speziell im Accept-Language-Header). Dies unterscheidet sich von der Auswahl anhand der IP-Adresse des Browsers oder von der manuellen Auswahl durch den Benutzer auf einer Sprachauswahl-Seite. Wenn es keine Übereinstimmung zwischen den vom Browser bevorzugten Sprachen und den auf dem Server verfügbaren Sprachen gibt, wird entweder eine Sprachauswahl-Seite angezeigt oder die Seite in einer voreingestellten Sprache ausgeliefert.

In vielen Fällen ist die Voreinstellung der bevorzugten Sprachen im Browser in Ordnung. Hat jemand bspw. die japanische Version eines Browsers, so geht der Browser typischerweise davon aus, dass der Nutzer Seiten vorzugsweise auf Japanisch liest, und sendet diese Information zum Server. Mainstream-Browser erlauben es dem Nutzer, die bevorzugten Sprachen einzustellen. Für weitere Information siehe Einstellung der bevorzugten Sprachen im Browser.

Diese FAQ behandelt die Frage, wann es ratsam ist und wann nicht, Sprachvereinbarung auf dem Server einzusetzen.

Antwort

Einfache Antwort: immer.

Etwas ausführlicher: fast immer, aber nicht ausschließlich.

Sprachvereinbarung funktioniert nicht immer wie gewünscht; es gibt aber Wege, die Schwachstellen zu beheben; und man sollte für eine konsistente Navigation sorgen.

Schwachstellen der Sprachvereinbarung

Sprachvereinbarung ist offensichtlich eine nützliche Sache, aber bevor man sie implementiert, ist es wichtig, ihre Grenzen zu kennen. Um diese zu veranschaulichen, nehmen wir als Beispiel eine Website www.example.be, die ihre Inhalte in Flämisch, Französisch und Deutsch anbietet. Unsere Besucherin Sylvia spricht Italienisch, versteht aber auch Deutsch. Verschiedene Situationen können eintreten:

  1. Sylvias Browser ist korrekt konfiguriert; er gibt Italienisch als erste bevorzugte Sprache an, dann Deutsch als zweite. Italienisch ist auf dem Server www.example.be nicht verfügbar, die Seiten werden auf Deutsch ausgeliefert, die Benutzerin ist zufrieden, alles in Ordnung. Dafür ist Sprachvereinbarung da!
  2. Sylvia ist technisch nicht so versiert, hat nie von HTTP-Sprachvereinbarung gehört und noch nie das Bedürfnis gehabt, die Einstellungen ihres Browsers zu verändern. Dieser ist eine italienische Version und gibt (korrekt) Italienisch als bevorzugte Sprache an. Aber www.example.be gibt es nicht auf Italienisch und die Website-Voreinstellung Flämisch wird ausgeliefert, obwohl Deutsch verfügbar ist. Schlecht.
  3. Sylvia benutzt nicht ihren eigenen Browser, sondern sitzt in einem Internet-Café in Moskau. Der Browser dort ist auf Russisch eingestellt. Und wieder bekommt sie Flämisch zu lesen. Schlecht.

Die Beispiele zeigen: Sprachvereinbarung liefert nicht immer das gewünschte Ergebnis.

Außerdem ist Sprachvereinbarung irrelevant, wenn die Seiten nicht äquivalent sind, also in verschiedenen Sprachen nicht den gleichen Inhalt haben. Die FAQ Einsprachige vs. mehrsprachige Websites beleuchtet diesen Aspekt, siehe insbesondere die Abschnitte „Mehrsprachig, gleicher Inhalt“ und „Mehrsprachig, verschiedener Inhalt“. Allerdings führt ein gewisses Maß an kultureller Anpassung (z.B. Angaben in einer anderen Währung) nicht zwangsläufig zu nicht äquivalenten Webseiten. Sprachvereinbarung kann aber nicht mehr sinnvoll eingesetzt werden, wenn Webseiten nicht äquivalent sind, d.h. Language-Negotiation stößt an ihre Grenzen, wenn eine Website so übertragen wurde, dass sich Seiten in verschiedenen Sprachversionen nicht einander entsprechen.

Behebung der Schwachstellen

Trotz ihrer Grenzen ist Sprachvereinbarung eine nützliche Funktion und sollte bei mehrsprachigen Websites implementiert werden. Aber ihre Schwachstellen müssen beachtet werden. Kurz gesagt, es ist wichtig, dem Besucher Mittel in die Hand zu geben, die automatische Sprachauswahl zu umgehen, falls erforderlich. Das bedeutet, Interface-Elemente in die Seite zu einzubauen (nennen wir sie hier Sprachauswahl-Elemente), die zu den anderen verfügbaren Sprachversionen verlinken. Diese Sprachauswahl-Elemente müssen natürlich klar erkennbar sein und dem Nutzer verständlich, auch wenn er mit der gerade angezeigten Sprache nicht vertraut ist.

Es stellt sich die Frage: Sollen Sprachvereinbarung und manuelle Sprachauswahl für alle Seiten implementiert werden oder nur für die Startseite? Die beste Antwort ist „für alle Seiten“, außer für solche Seiten, die nicht hinreichend äquivalent sind. Sprachvereinbarung ist nützlich, denn wenn Jaap einen Link innerhalb von www.example.be an Pierre mailt, bekommt Pierre die französische Version zu lesen, obwohl Jaap die flämische gelesen hatte. Sprachauswahl-Elemente müssen immer angeboten werden, egal ob Sprachvereinbarung implementiert ist oder nicht. Wenn keine Sprachvereinbarung durchgeführt wird, benötigt Pierre die Sprachauswahl-Elemente, um von Jaaps Link zur französischen Version zu gelangen; auch wenn Sprachvereinbarung durchgeführt wird, muss Sylvia in den oben genannten Situationen 2 und 3 manuell auf Deutsch umschalten können.

Übrigens: Einige Websites liefern eine spezielle Sprachauswahl-Seite aus, wenn es keine Übereinstimmung zwischen den vom Nutzer bevorzugten und den verfügbaren Sprachen gibt. (www.example.be könnte dies auch tun, anstatt Flämisch auszuliefern.) Das hat den Vorteil, dass die Situation klar ist und keine Sprache einer anderen vorgezogen wird, was politisch bedenklich sein könnte. Unglücklicherweise liefern einige Websites immer eine solche Seite (als Startseite) anstatt Sprachvereinbarung durchzuführen. Dadurch muss jeder über diese Seite gehen – ohne ersichtlichen Nutzen. Nicht nutzerfreundlich.

Navigation

Angenommen, Sylvia besucht www.example.be und bekommt Flämisch (Situationen 2 und 3). Sie wählt dann die deutsche Version aus, kein Problem. Aber dann folgt sie einem Link zu einer anderen interessanten Seite auf dieser Website. Oh, wieder Flämisch! Glücklicherweise ist das Sprachauswahl-Element für Deutsch immer noch vorhanden, aber nach einigem solchen Hin-und-Her wird sie verständlicherweise verärgert sein. Kann sich www.example.be nicht einfach merken, dass sie kein Flämisch lesen kann? Was hier fehlt, ist Konsistenz, eine Art „Gedächtnis“ für die explizite Sprachauswahl.

Es gibt verschiedene Wege, wie sich www.example.be die Sprachauswahl merken kann. Welcher gewählt wird, hängt von der auf dem Server verfügbaren Technologie und dem zu erwartenden Arbeitsaufwand ab.

Wenn die Website einen Session-Mechanismus bereitstellt (z.B. durch Cookies), dann ist es ein Leichtes, die Sprache mit in den Session-Zustand einfließen zu lassen. Wenn Sylvia auf das Sprachauswahl-Element für Deutsch clickt, wird dies gespeichert (entweder im Cookie selbst oder auf dem Server, Zuordnung über eine Session-Nummer im Cookie) und von da an bekommt sie die deutschen Sprachversionen der Seiten, wenn sie durch die Website navigiert. Der Cookie kann sogar dauerhaft gespeichert werden (allerdings kommen hier Fragen des Datenschutzes ins Spiel), so dass Sylvia auch wieder automatisch die deutschen Seiten bekommt, wenn sie das nächste Mal www.example.be besucht. Websites, die einen Login-Mechanismus anbieten, können die bevorzugten Sprachen auch in den Nutzerprofilen speichern und die Seiten entsprechend ausliefern. Sprachvereinbarung kommt dann nur bei nicht eingeloggten Nutzern zur Anwendung.

Ein anderer Weg, der Verärgerung entgegenzuwirken, ist, alle internen Links innerhalb der Website sprachspezifisch zu machen. Auf der deutschen Homepage hätten Links zu weiteren Seiten die Form href="company/about.de.html" (anstatt company/about.html, was generisch wäre)*. Bei der Navigation bleibt man auf den deutschen Seiten, bis man wieder eine andere Sprache auswählt. Dies hat jedoch auch einige Nachteile. Einer ist, dass alle internen Links bei der Übersetzung angepasst werden müssen, was sowohl die Kosten als auch das mögliche Fehlerpotential erhöht. Ein anderer ist: Wenn Jaap einen Link an Pierre schickt, dann ist der URI (aus der Adressleiste des Browsers herauskopiert) sprachspezifisch; Pierre wird die flämische Seite bekommen. Keiner dieser Nachteile ist jedoch gravierend, und so sind sprachspezifische Links ein gangbarer Weg, wenn die Konsistenz nicht mit einem Session- oder Nutzerprofil-Mechanismus erreicht werden kann.

* Die tatsächlichen Formen der hier gezeigten sprachspezifischen und generischen URIs (company/about.de.html bzw. company/about.html) hängen von der Technologie ab, mit der Sprachvereinbarung auf dem Server implementiert wurde. Wenn Apache MultiViews verwendet wurde, würde man auch eher company/about.html.de bzw. company/about.html sehen oder ganz ohne .html-Endung: company/about.de bzw. company/about.

Übrigens

Der HTTP-Accept-Language-Header ist nicht die einzige verfügbare Quelle für die Sprachinformation. Alle Browser senden auch einen User-Agent-Header, der den Hersteller, die Versionsnummer und in einigen Fällen auch die Sprachversion des Browsers angibt. Dieser kann genutzt werden, um die bevorzugte Sprache des Nutzers zu erraten, wenn der Accept-Language-Header fehlt, was aber nicht so zuverlässig und nur auf eine Sprache beschränkt ist. Nur mit äußerster Vorsicht zu benutzen.

Sprachvereinbarung ist nur ein Aspekt von HTTP-Inhaltsvereinbarung (content negotiation). Andere Aspekte, die automatisch vereinbart werden können, sind der Medientyp (d.h. das Format: z.B. HTML, PDF oder Text), die Zeichencodierung und die Übertragungscodierung (verschlüsselt, komprimiert usw.). Sprachvereinbarung ist der nützlichste und am meisten verwandte.

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: François Yergeau. Übersetzer: Gunnar Bittersmann mit Juliane Wünsche.

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

Übersetzung der englischen Version vom 2004-02-26. Letzte Änderung der übersetzten Version am 2010-09-03 18:54 UTC.

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