Mit DITA um die Welt – tekom-Jahrestagung 2012

Die tekom-Jahrestagung 2012 ist überstanden und es war mal wieder sehr interessant und schön dabei zu sein.

Vorab gibt es hier erst einmal die Folien zu meinem Vortrag “Mit DITA um die Welt”. Der Rückblick folgt in den nächsten Tagen. Ich gehöre nicht zu den Schnell-Bloggern wie Kai oder Sarah, die ihre Eindrücke wirklich rasend schnell online hatten.

Und hier noch der Beweis, dass ich ihn tatsächlich gehalten habe ;-)
(Special thanks to Axel)

Vortragsbild "Mit DITA um die Welt"

Geschrieben in DITA,Lokalisierung | 1 Kommentar

Communities für alle!

In meinem letzten Post  habe ich es schon angeschnitten: das Thema “Lokalisierung von Communities”.  (Ich konzentriere mich hierbei weiterhin vor allem auf Hilfe-Communities, d.h. Plattformen, die Hilfetext enthalten, die auch durch die User bearbeitet werden können.(

Es ist ein ziemlich ungeliebtes Thema, fürchte ich. Ich kann mich noch daran erinnern, wie beim Content-Strategy-Tag der tekom-Tagung 2011 eine Publikumsfrage dazu gestellt und recht schnell übergangen wurde.

Wie sieht es bei schon existierenden Communities aus?

In den Open-Source-Communities ist Lokalisierung der Hilfe-Communities oft kein Thema: Es gibt in der Regel eine Sprache und das ist Englisch. Das ist schlichtweg am einfachsten, damit Leute aus aller Herren Länder sich beteiligen können. Ein Beispiel ist auch hier die ubuntu-Community.

Teilweise gibt es auch den Ansatz, dass es pro Sprache eine eigene Community gibt. Da werden oft die wichtigsten Artikel übersetzt oder in der entsprechenden Sprache neu geschrieben, wie z.B. Mozilla. Oder es sind ganz eigenständige Communities pro Sprache wie bei Wikipedia.

Alles eine Frage der Organisation

Letztlich sind es vor allem konzeptionelle Fragen, vor denen man hier steht:

  • Lokalisiert man überhaupt?
  • Wer lokalisiert: die Community oder die Firma?
  • Übernimmt man das alteingesessene Prinzip, dass es eine Quellsprache gibt und dann entsprechend in die Zielsprachen übersetzt wird?
    So kann man zwar gewährleisten, dass eine Redaktion den Überblick über alles hat, aber man kann nicht davon profitieren, wenn in einer Zielsprachen-Community ein guter Artikel erstellt wird.
  • Lässt man jede Länder-Community ihr eigenes Ding machen?
    So muss jede Länder-Community das Rad neu erfinden und das kostet natürlich mehr.
  • Setzt man auf eigene Länder-Communities, die aber mit einander kooperieren?
    Wenn ein spanischer Artikel hilfreich ist, sollte es möglich sein diesen in die anderen Sprachen zu übersetzen, d.h. jede Sprache sollte Quellsprache sein können. So profitiert man am besten vom Community-Effekt.

Die Frage, ob man überhaupt lokalisiert, hängt an der Frage, ob das Unternehmen international tätig ist. Wenn ja, muss auch lokalisiert werden. Immerhin sollen die Kunden ja was kaufen und das erreicht man immer noch am besten, wenn man diese in der Landessprache anspricht. 

Bei der Organisation der Länder-Communities würde ich dieseVariante wählen: Pro Sprache eine Community, wobei ein Grundstock an Content bei allen gleich ist, und dieser von der Firma selbst lokalisiert wird. So könnte die Firma sicherstellen, dass grundlegendste Artikel wirklich überall verfügbar und up-to-date sind. Außerdem können Artikel aus jeder Sprache auch in die anderen Sprachen übersetzt werden, wenn sie als hilfreich erachtet werden. So profitiert die Firma auch vom Community-Effekt. Von einer Vorstellung kann man sich sicherlich verabschieden: Die Communities synchron zu halten. Dafür passiert in diesem Umfeld zu schnell zu viel.

Diese Variante bedeutet aber auch: Man wird für die Betreuung auch für jeder Sprache einen eigenen Community-Manager benötigen. Und diese gilt es alle auf dem aktuelle Stand zu halten. Hier verziehen sich dann sicherlich schon die ersten Gesichter von den Ressourcen-Verantwortlichen. ;)

Fazit

Ich denke, es ist nicht unmöglich, kommerzielle mehrsprachige Communities aufzubauen, aber es ist eine große organisatorische Herausforderung. Und ich würde zu gerne wissen, ob es solche kommerziellen Communities schon da draußen gibt – ich bin nur im Open-Source-Umfeld fündig geworden. Kennt ihr welche?

Geschrieben in Erweiterter Horizont,Lokalisierung,Social Media | 4 Kommentare

DITA-OT um Sprachen erweitern

Das DITA-Open-Toolkit bringt schon ziemlich viele Sprachen mit sich, aber irgendwo findet sich doch immer eine, die doch noch nicht abgedeckt ist.  Das Hinzufügen neuer Sprachen ist glücklicherweise kein Hexenwerk. Allerdings gilt letztere Aussage nur für Sprachen mit der Schreibrichtung “links nach rechts” – die andere Richtung hab ich noch nie getestet und weiß nicht, ob es da noch andere Dinge zu beachten gilt.

Das Sprachkürzel herausfinden

Im Attribut xml:lang jedes Topics muss die Sprache angegeben werden. Es gibt verschiedene Übersichten im Netz über diese so genannten “Locale IDs” , z.B. hier. Nehmen wir mal an, ich möchte kolumbianisches Spanisch einbinden. So lautet das Kürzel also: es-co.

Sprache in strings.xml hinterlegen

  1. Öffne das Verzeichnis xsl/common in deinem DITA-OT.
  2. Öffne die Datei strings.xml.
  3. Kopiere die Zeile mit der Definition des Spanischen und füge die Kopie direkt drunter ein.
  4. Ändere das Sprachenkürzel entsprechend der gewünschten Sprache, hier als Beispiel kolumbianisches Spanisch.
    es-co

Neue Sprachdatei anlegen

  1. Kopiere eine der vorhandenen Sprachdateien aus dem Verzeichnis xsl/commonund füge sie unter dem Namen es-co.xml in dasselbe Verzeichnis ein.
  2. Übersetze die Strings in der Datei in die gewünschte Sprache. Oder lasse übersetzen ;)
  3. Kopiere die Zeile mit der Definition des Spanischen und füge die Kopie direkt drunter ein.

Fertig!
Das war es tatsächlich schon. Ab sofort kannst du in den Topics und Maps das neue Sprachkürzel verwenden und die automatischen Strings wie z.B. “Hinweis” oder “Achtung” werden entsprechend lokalisiert :)

Geschrieben in DITA,Lokalisierung,Übersetzung | 4 Kommentare

Softwarelokalisierung und Kontext

Ich habe bereits erwähnt, dass ein GUI-Texter/Übersetzer einfach nur eine Datei mit Text bekommt, im schlimmsten Fall eine ellenlange Datei mit Tausenden von Einträgen. Die Schwierigkeit hierbei ist nun, dass man gar nicht weiß wo der Text genau erscheint, in welchem Kontext er sich befindet, wenn man einfach nur die Datei vor sich hat. In manchen Fällen macht es das sehr schwer, überhaupt einen Text zu formulieren, der in diesem Kontext Sinn macht und man hat auch das Problem, dass man nie weiß, ob der Text in der GUI überhaupt genug Platz hat (z.B. “Publish” versus “Veröffentlichen”: hier ist das deutsche Wort fast doppelt so lang).

Beispiel für die Folgen von Kontextarmut

Das Kontextproblem ist den meisten, die mit der Thematik kaum in Berührung kommen, nicht sofort verständlich. Für diese Fälle habe ich mein Lieblingsbeispiel aus der Praxis parat, das ich auch euch nicht vorenthalten möchte. Es führt klar und deutlich vor Augen, was fehlender Kontext bedeuten kann:

Der Ausgangs-Dialog:
html1

Was der Übersetzer sehen konnte, war einfach nur Text  (vereinfachte Version):

html_translator

Was am Ende dabei rauskam:

html2

Die Moral von der Geschicht: Übersetzen geht ohne Kontext nicht!

Wenn der Übersetzer des obigen Beispiels den Dialog vor sich gehabt hätte, wäre wohl kaum dieses Ergebnis rausgekommen. Es ist also dringend notwendig, dass ein Übersetzer den Kontext zu sehen bekommt.

Wie bekommt der Übersetzer den Kontext?

Das Allerbeste wäre eine Lokalisierungssoftware, die dem Übersetzer ein so genanntes “In-Place Editing” erlaubt, d.h. der Übersetzer öffnet bspw. einen Dialog der zu übersetzenden Applikation und kann direkt an Ort und Stelle den Text ändern. Dabei stehen im in der Regel auch Translation Memories zur Verfügung. Gängige Namen für Lokalisierungssoftware sind hier “Passolo” oder “VisuaLocalize”. Allerdings ist der Einsatz solcher Software bei den heutzutage hochdynamischen Web-Applikationen äußerst schwierig, da hier Seiten und Elemente zur Laufzeit generiert werden und eine ständige Verbindung zu anderen System haben müssen (deswegen bin ich auch gespannt auf den Vortrag “LOC13 Visual localization of web-based application” auf der tekom-Tagung). Wenn man dann auch noch mehrere Applikationen übersetzen muss, die auch noch unterschiedliche Basistechnologien einsetzen, wird es richtig kompliziert.

Eine andere gute Lösung für den Übersetzer ist eine Testversion der Software oder ein Testzugang der Webseite in der Quellsprache. Wenn das nicht möglich ist, dann sollte man zumindest Screenshots mitliefern. Und wenn das auch nicht praktikabel ist, muss ein Lektor her, der die übersetzten Texte in der GUI überprüft und bei Fehlern dann auch das Translation Memory aktualisiert.

Geschrieben in Beruf,Erweiterter Horizont,Lokalisierung,Übersetzung | Keine Kommentare

Softwarelokalisierung: Formate und Arbeitsablauf

Weiter geht es mit meiner angefangenen Serie zur Software-Lokalisierung für Technische Redakteure

Formate und Tools
Die Formate mit denen man sich auseinandersetzen muss, sind vielfältig. Es hängt von der eingesetzten Technologie ab und vielleicht auch von den Präferenzen der jeweiligen Entwicker. Mit diesen Formaten habe ich im Bereich von Webapplikationen am häufigsten zu tun:

  • PO-Dateien, oftmals bei Anwendungen mit JavaScript, PHP (z.B. WordPress)
  • selbst definierte XML-Dateien
  • Java Properties

Jedes dieser Formate hat seine Eigenarten, wie etwas unterschiedliche Zeichenkodierungen (UTF-8, ISO-8859-1).  Bei Java Properties muss man Sonderzeichen beispielsweise gesondert kodieren – so wird aus einem “ü” ein \u00fc. Glücklicherweise gibt es auch Editoren, die einem solche Späße übernehmen oder die das Editieren generell vereinfachen (für PO ist es z.B. PO Edit).

Diese Formate sind einigermaßen gängig und können heutzutage auch von den allseits bekannten Translation-Memory-Systemen eingelesen werden, die dann diese Kodierung beispielsweise auch völlig selbständig im Hintergrund übernehmen.

Datenaustausch und Pflege
Der Datenaustausch findet bei uns meistens über das SubVersion der Entwicklung statt. Die Entwickler generieren leere Dateien mit IDs, wir checken diese aus, befüllen die IDs mit Werten (also Text) und checken sie wieder ein.

Das initiale Betexten und Übersetzen solcher Textdateien ist noch eine schöne Sache. Man hat eine Datei von der man weiß, dass man sie nun komplett überarbeiten bzw. übersetzen muss.

Unangenehm kann es dagegen werden, wenn bereits bestehende Textdateien um einige Zeilen erweitert werden. Das kann dann unter Umständen so aussehen:

  1. In der ellenlangen Datei nach der leeren ID suchen
  2. Einen Text eingeben.
  3. Diesen Text rauskopieren in eine Extra-Datei
  4. Diese Datei zu Übersetzung geben
  5. Die Übersetzung manuell in die ellenlange Textdatei zurückkopieren.
  6. sie dann herauskopiert, zur Übersetzung gibt und am Ende manuell die fertigen Übersetzungen in die Textdateien zurückpfriemelt.

Wie man sieht: Eine sehr mühselige, zeitaufwändige und fehleranfällige Tätigkeit, die man ziemlich schnell mit Skripten automatisieren sollte. Man kann sich z.B. kleine Skripte bauen, die die neuen Strings automatisch in eine neue Datei extrahieren, die man dann bequmm betexten/übersetzen lassen kann. Und die Skripte bauen die Übersetzungen anschließend wieder zurück, so dass man sich diese fehleranfälligen Zwischenschritte sparen kann.


Geschrieben in Beruf,Lokalisierung,Redakteurs Alltag,Übersetzung | 1 Kommentar