Im Juni 2009 führte WIENFLUSS im Auftrag von WienTourismus den Relaunch der offiziellen Wiener Tourismuswebsite wien.info durch. In einer losen Artikelserie wollen wir ein wenig die Hintergründe und Erfahrungen aus diesem Projekt beleuchten.

Diesmal geht es um die Mehrsprachigkeit von wien.info, wie wir mit den zwölf Sprachen der Website umgegangen sind, darunter auch solche mit nicht-lateinischen Buchstaben (Russisch, Japanisch, Arabisch) und einer Sprache die von rechts nach links geschrieben wird (Arabisch).

Aufmerksamen LeserInnen wird unter Umständen nicht entgangen sein, dass es wien.info auch noch in einer 13. Sprache gibt. Die wollen wir nicht verschweigen, weil wir abergläubisch wären, sondern weil diese Website direkt in China betrieben und betreut wird.

Internationalisierung vs. Lokalisierung

Internationalisierung (auch mit I18N abgekürzt) bedeutet eine Website so zu gestalten, dass sie an andere Sprachen und Kulturen angepasst werden kann.

Im wesentlichen beinhaltet dies die Vorbereitung von Templates, CMS und Websitestruktur für Mehrsprachigkeit. Auch die durchgehende Verwendung einer Unicode Zeichencodierung (konkret UTF-8) ist eine wichtige Voraussetzung für die Internationalisierbarkeit.

Lokalisierung (L10N) steht für die Übertragung einer Website in eine andere Sprache und Anpassung an die kulturellen Bedürfnisse, Vorlieben und Gegebenheiten.

Hier geht es um die tatsächliche Übersetzung von Texten, Anpassung von Maß- und Zeitformaten und unter Umständen auch unterschiedliche Inhalte und inhaltliche Schwerpunkte für die jeweiligen Zielgruppen. Eine Aufgabe die im globalen Tourismusmarketing eine Selbstverständlichkeit ist. Arabisches und japanisches Zielpublikum können nicht mit den selben Schwerpunkten, Botschaften und Bildern gewonnen werden wie jene in England oder Russland.

Internationalisierung im CMS

I18N bedeutet für das Contentmanagement-System im wesentlichen, dass es für die Redaktion die Übersetzung und Pflege mehrsprachiger Inhalte unterstützt. Drei Beispiele:

Informationsstruktur und Seitenadressen

Nach reiflicher Überlegung hat sich WienTourismus mit uns dafür entschieden, für alle Sprachen eine parallele Informationsstruktur und Navigation aufzubauen, wenngleich in manchen Sprachen einzelne Zweige – hauptsächlich auf den unteren Ebenen – zumindest vorläufig entfallen. Das heißt natürlich nicht, dass alle Inhalte jeweils 1:1 übertragen werden müssen.

Der große Vorteil dieser Struktur ist es, dass die User von einer Seite in der Sprache A direkt in das selbe Dokument der Sprache B wechseln können. Ist dieses nicht vorhanden führt der Wechsel automatisch in die nächsthöhere vorhandene Ebene. Jeder benutzergesteuerte Wechsel setzt ein Cookie für die bevorzugte Sprache.
Die Internetadressen einzelner Seiten werden entweder in Deutsch oder für alle anderen Sprachen in Englisch vergeben. Ein Kompromiss der es den RedakteurInnen erleichtert Seiten in allen Fremdsprachen zu identifizieren und Probleme bei URLs mit nicht-lateinischen Schriften vermeiden hilft.

Übersetzungsworkflow

Ebenso wie sich die Struktur und die Inhalte der Website nach den Informationsbedürfnissen und am Nutzungskontext der User orientieren sollen und nicht umgekehrt, sollten die Workflows im Redaktionssystem sich an den Arbeitsabläufen der RedakteurInnen orientieren. Das ist im konkreten Fall nicht so einfach, da die Übersetzungen sehr unterschiedlich bearbeitet werden. Manche ÜbersetzerInnen arbeiten direkt im CMS, andere offline in Textverarbeitungsprogrammen.

In fast allen Fällen ist das Ausgangsdokument ein fertiger deutscher Artikel. Wird von diesem im CMS eine Übersetzung angelegt, wird im konkreten Fall eine Kopie des Ausgangsartikels erstellt, bei der Bilder und website-interne Links – sofern vorhanden – automatisch in die Zielsprache übertragen werden. Externe Links und jene die nicht in der Zielsprache vorhanden sind werden sichtbar im Linktext als nicht übertragen markiert. Der Text des Dokuments bleibt natürlich Deutsch und dient als Ausgangsbasis für die Übersetzung.

Ein anderer wichtiger Aspekt für jene Übersetzungen die in Word verfasst werden, ist die Möglichkeit, beim Einspielen der übertragenen Texte, Formatierungen und Links zu erhalten, da es bei Unkenntnis manchen Sprachen eine mühsame Kleinarbeit darstellen kann, solche Formatierungen an den richtigen Stellen manuell nachzutragen. Die RedakteurInnen können sich zusätzlich bei der Übersetzungsarbeit jederzeit die Ausgangsdokumente neben den Übersetzungen anzeigen lassen.

Obwohl jedes übersetzte Dokument ein völlig eigenständiges Inhaltsobjekt darstellt, sind Übersetzungen immer fix mit dem Artikel der Ausgangssprache verbunden, was einen Wechsel zwischen den Sprachen erleichtert. Für einige Artikeleigenschaften (z.B: Zuordnung von Taxonomie-Kategorien) haben wir uns bewusst für sprachunabhängige Werte entschieden. Solche Daten müssen daher von der RedakteurIn nur ein einziges Mal eingepflegt werden.

Alternativtexte für Bilder

Die meisten CMS bieten inzwischen die Option Alternativtexte direkt beim Bildobjekt abzuspeichern, um sich die Eingabe bei jeder Verwendung des Bildes zu ersparen. Die wenigsten Systeme ermöglichen es aber, für ein Bildobjekt Alternativtexte in beliebig vielen Sprachen anzulegen, ohne das Bild selbst mehrmals einpflegen zu müssen.
Im konkreten Fall ging es darum, das Internationalisierungsmodul von Plone, dem hier verwendeten CMS, so anzupassen, dass Alt-Texte direkt in allen Sprachen eingepflegt werden können. Die Copyright-Informationen zu einem Bild werden hingegen nicht übersetzt – wie wollen sie auch Eigennamen übersetzen – und müssen daher nur einmal sprachunabhängig von den RedakteurInnen eingepflegt werden.

Die Übersetzung von Alternativtexten für einige tausend Bilder ist übrigens einer der wenigen Budgetposten die man unmittelbar als Kosten für Barrierefreiheit verbuchen muss. Eine einfache Plutimikation Anzahl der Bilder mal Anzahl der Sprache mal Kosten pro Wort mal durchschnittliche Wortzahl pro Alt-Text ergeben eine nicht zu vernachlässigende Summe.

Lokalisierung der Frontends

Auch wenn die Umsetzung der HTML, CSS und Javascript-basierten Templates aus Sicht der Mehrsprachigkeit weit weniger anspruchsvoll umzusetzen ist als im CMS, so waren doch einige Herausforderungen zu bewältigen. Auch hier wollen wir an Hand einiger Beispiele zeigen, wie damit umgegangen wurde.

Du sollst lechts und rinks nicht velwechsern

Arabische Schrift wird bekanntermaßen von rechts nach links geschrieben (und gelesen). Die Orientierung des Textes erfolgt automatisch durch den Browser. Die arabischen Templates erfordern selbstverständlich dementsprechend einen Richtungswechsel: d.h. die Anordnung der Inhalte einer Seite wird komplett gespiegelt um der Schreib- und Leserichtung von rechts nach links genüge zu leisten. Das betrifft die Spaltenabfolge, Beschriftung von Formularfeldern, floatende Elemente, Ausrichtung von Texten, Aufzählungszeichen und vieles mehr.

Ein nettes Tool von Google erleichtert hier das Umschreiben des CSS: CSSjanus. Einfach das CSS in die Webapplikation kopieren und auf Knopfdruck kommt der angepasste Code raus. Manuelles Nacharbeiten bleibt einem aber nicht erspart, hält sich aber in Grenzen – solange man nicht auf diverse Browserbugs aus Redmond stößt.

Javascript

Wie auf modernen Websites üblich, wird die Funktionalität vieler Elemente des Templates durch Javascript erweitert (Stichwort progressive Enhancement). Durch die Dynamisierung der Benutzeroberfläche muss auch in diesem Bereich die Internationalisierbarkeit sichergestellt werden.

Um die Übersetzungen nicht bunt mit dem restlichen Code zu vermischen, werden alle Texte in einzelnen Übersetzungsdateien gesammelt, für jede Sprache eine File. Je nach Sprache wird dann die entsprechende Datei eingebunden, aus der die übersetzten Texte ausgelesen werden.

Und es kommt doch auf die Länge an

Wer kennt den ewigen Kampf mit der Textlänge nicht. Nur, wenn man das Problem mal gelöst hat und sich dann an die Übersetzungen macht, wird man schnell merken wo Schluss mit lustig ist. Z.B. im Russischen, oder im Ungarischen. Dazu kommt, dass Texte beim Übersetzen schon aufgrund der oft notwendigen Umschreibungen länger werden.

Das führt dann rasch einmal zu ungewollten oder zumindest unschönen Zeilenumbrüchen. Leider sind Zeilenumbrüche manchmal keine Option, man denke nur an die horizontale Navigation, oder Beschriftungen von Formularfeldern. Gerade die Navigation ist ein heikler Bereich: sie kann und wird sich mit Sicherheit im Laufe der Zeit ändern – und meist wird sie nicht kürzer.

Im konkreten Fall haben wir eine Javascript-basierte Lösung entwickelt, die damit umgehen soll. Beim Laden der Seite überprüft eine Funktion die Länge der Subnavigation und noch bevor es zum Zeilenumbruch kommt, werden die überstehenden Einträge zu einem aufklappbaren Menüpunkt zusammengefasst.
Vorteil der Lösung ist die dynamische Anpassung an Navigationslänge und Schriftgröße. Umgesetzt ist das ganze natürlich wieder als progressive Enhancement: mit Javascript die praktische und schöne Zusammenfassung der überlaufenden Navigationspunkte, ohne Javascript bricht die Subnavigation einfach in die nächste Zeile um, nicht so sexy, aber trotzdem funktional.

Ein Wirrwarr nach babylonischer Zeitrechnung

Unlustig wird es wenn Frontend und Backend sich nicht vertragen. Das passiert leicht mal bei Datums- und Zeitfeldern. Das Eingabeformat hängt von der Sprache (genau genommen eigentlich vom Land) ab, d.h. der Server muss wissen in welchem Format die Zeitangabe verarbeitet wird und wie sie wieder ans Frontend zurückgeliefert werden muss. Ein verborgenes Formularfeld mit einem Format-Identifier (z.B. dd-mm-yyyy) erleichtert dem Server die korrekte Umwandlung in ein internes Datumsformat.

Aber natürlich müssen auch Datepicker und andere Frontend-Eingabehilfen für Datum und Zeit an die unterschiedlichen Standards und Formate angepasst werden. So ist im anglo-amerikanischen Raum der Sonntag der erste Tag der Woche. Zum Glück ist z.B. das Date-Picker Widget von jQuery bereits darauf vorbereitet und geht mit diesen Anforderungen gut um.

Ungewollte Mashups

Nicht immer sind alle Inhalte in allen Sprachen vorhanden, und schneller als man denkt ergibt das Seiten die mit anderssprachigen – zumeist englischen – Inhalten aufgefüllt werden. Veranstaltungsbeschreibungen z.B. sind nur in Deutsch und Englisch verfügbar, das Wetter gibt es auch noch auf italienisch. Bei zusätzlichen Übersetzungen in diesen Bereichen stößt man logistisch und von den Kosten rasch an die Grenzen.

Hier zeigt sich, wie eng der Zusammenhang zwischen Accessibility und Internationalisierung in der Praxis ist. Für Screenreader-User wird ein ständiger Sprachwechsel rasch zu einem Irrgarten. Ein englischer Text mit einer französischen Stimme im Screenreader vorgelesen ist schlicht unverständlich. Der Sprachwechsel muss daher im Code angezeigt werden (durch das LANG-Attribut).

An den wichtigsten Stellen haben wir das im CMS bereits integriert, aber bei weitem noch nicht überall.