Wann es angebracht ist, Sprachvereinbarung (language negotiation) einzusetzen

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.