you're reading...
Internationalisierung

Strategien für die Lokalisierung

Uff, fast geschafft! — Hat man seine Informationsarchitektur entworfen und in Form einer Web Site oder Web Applikation implementiert, und hat dabei darauf geachtet, dass der HTML/JSP/ASP/* Code internationalisiert wurde, die Übersetzungseinheiten sind identifiziert, reviewed und eingefroren … dann ist die Lokalisierung nicht mehr weit.

In diesem Eintrag möchte ich Euch verschiedene Strategien für die Lokalisierung vorstellen. Im wesentlichen geht es um das Management der Inhalte, die man übersetzen muss. Jeder, der mal bei der Lokalisierung einer Web site oder Software beteiligt war, weiss, dass es wie mit dem Hüten von Flöhen ist:

  • Neue Übersetzungseinheiten werden geschrieben oder erst entdeckt.
  • Bereits übersetzte Inhalte werden geändert.
  • Die übersetzten Inhalte werden nicht oder spät kontrolliert oder reviewed.
  • Inhalte veralten und schwirren in falschen Versionen umher.
  • Inhalte liegen im falschen Format vor, oder müssen konvertiert werden (evtl. mit Datenverlust).
  • Rückfragen der Übersetzer, weil die Bedeutung nicht klar ist
  • und so weiter und so fort …

Um den Überblick zu behalten, ist es wichtig eine Strategie zu verfolgen. Dann weiss jeder der Beteiligten Bescheid, wann und wie übersetzt wird. Hier sind die einzelnen Strategien:
Bei dieser Strategie gibt es nur eine Quellsprache, in der alle Inhalte erstellt werden und die in verschiedene Zielsprachen übersetzt werden. Das ist der Regelfall bei Software und Web Applikationen. Es ist zudem die einfachste Strategie. Probleme gibt es dann, wenn man einen Sim-Ship liefern will (d.h. die Software oder Web Applikation wird in allen Sprachen zugleich ausgeliefert.). Wenn man nicht genügend Zeit für die Lokalisierung einplant, dann wird das Problem der ständig neuen oder geänderten Inhalte viel Ärger einbringen, weil man die lokalisierten Produkte nicht ausreichend testen kann.

Gerade bei grossen Web Sites internationaler Firmen kann es sein, dass es nur lokale Inhalte gibt, z.B. wie in national regulierten Branchen wie Versicherungen. Oft sieht man dann unabhängige Web Sites, die nicht konsistent sind und kein einheitliches Look and Feel bieten. Will man trotzdem die Infrastruktur oder das Content Management vereinheitlichen, muss die Informationsarchitektur in der Lage sein, die Inhalte von verschiedenen Authoren in verschiedenen Sprachen einzupflegen. Ansonsten profitiert man nicht von einem gemeinsamen Design, Infrastruktur oder teurem Content Management System.


Ein Variante der gleichberechtigten Sprachen unterscheidet zwischen den Sprachen, in denen Inhalte erstellt werden und in solche, in denen Inhalte übersetzt werden. Das kommt oft vor, wenn Web Sites regional organisiert sind, z.B. eine für Nord- und Südamerika, eine für Europa und Mittlerer Osten und eine für Asien und Pazifik. Oft spiegelt das dann die internen Strukturen der Firmen wieder, die dann in regional Zentren die Inhalte erstellen oder pflegen. Wie bei den gleichberechtigen Sprachen stellen verschieden Quellsprachen besondere Anforderungen an das Projektmanagement, weil es das Problem der neuen oder geänderten Inhalte multipliziert.
Manchmal kommt es aber auch vor, dass man für das Paar Quell- und Zielsprache nicht genügende Übersetzer findet und so die Kosten steigen oder Qualität oder Durchsatz leiden (z.B. finnisch-japanisch).
Dann macht es Sinn, die Quellsprache erst in eine verbreitete Sprache (oft Englisch) zu übersetzen und dann in die eigentliche Zielsprache. Das ähnelt ein bisschen dem Spiel „Stille Post“ und kann in der Tat Informations- oder Qualitätsverluste bedeuten. Diesem Problem begegnet man am besten mit einem kontrollierten Vokabular und (wenn möglich) mit einer Kontrolle durch Rückübersetzung, um die resultierende Qualität zu prüfen.

Auf fast allen Web Sites gibt es verschiedene Kategorien, für die man verschiedene Strategien verfolgen muss oder kann. Zum Beispiel kann der Produktkatalog aus einer Hauptsprache heraus übersetzt werden, während für die Marketinginhalte regionale Authoren zuständig sind. Und für die legalen Anforderungen sind lokale Authoren vor Ort zuständig. Diese Situation stellt sehr hohe Ansprüche an das Projektmanagement. Die Informationsarchitektur sollte hier die Metadaten für die einzelnen Kategorien definieren und die jeweiligen Lokalisierungsstrategien festlegen. Man kann man das auch in Form von Business Rules definieren und so den Lokalisierungsprozess automatisieren. (Wenn man bei dieser Kategorie angekommen ist, sollte man sowieso an Automatisierung denken … )

Aber am besten macht sich bereits am Anfang eines Projekts oder Programms darüber Gedanken, welche Strategie verfolgt werden soll. Dann kann man das Management und die Qualitätsicherung besser einplanen und weiss auch immer, wo man gerade Feuerwehr spielen muss …

powered by performancing firefox

Advertisements

Diskussionen

Es gibt noch keine Kommentare.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Brian Heumann

%d Bloggern gefällt das: