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)
Mein letzter Blogpost wurde netterweise von Sarah O’Keefe übersetzt und im Scriptorium-Blog „wiederverwendet“. In Anbetracht der durchaus großen englischsprachigen Blog-Szene im Bereich Technische Redaktion habe ich mir schon oft überlegt auf Englisch zu schreiben, weil ich damit vermutlich ein größeres Publikum erreichen würde. Und Sarah hätte hier einfach nur verlinken können 😉
Warum ich es nicht mache? Deutsch ist meine Muttersprache. Mein Englisch ist durchaus gut – ich habe ein recht gutes Sprachgefühl und kann einigermaßen flüssige Konversationen halten, wenn ich mich warmgeredet habe. Aber es kostest mich unglaublich viel mehr Zeit einen englischen Text zu verfassen, der in Inhalt und auch Ausdruck genauso rüberkommt wie eine deutsche Version. Da steht mir mein englisches Sprachgefühl sogar ein bisschen im Weg, weil ich irgendwie merke, wenn der Satz nicht passt, aber es nicht besser machen kann. Am Ende kann ich mir nicht sicher sein, dass der Text wirklich so rüberkommt, wie ich es mir gedacht habe, weil dafür dieses letzte Stück Sprachgefühl fehlt, das man nur bekommt, wenn man in der entsprechenden Kultur lebt oder aufgewachsen ist. Ganz zu schweigen davon, dass der enorme Zeitaufwand das Schreiben an und für sich vermutlich sehr schnell komplett lähmen würde…
Für mich heißt das „Muttersprachen-Prinzip“ Texte ausschließlich in meiner Muttersprache zu verfassen, für einen Übersetzer heißt es ausschließlich in seine Muttersprache zu übersetzen. Am eigenen Leib erfahre ich oft, dass ich nur nach diesem Prinzip schreiben sollte. Doch immer wieder lese ich in Stellenanzeigen für Technische Redakteure die Anforderung „Dokumentation in deutscher und englischer Sprache“ verfassen. Und jedes Mal bin ich ein klein wenig ärgerlich, dass solche Anforderungen gestellt werden. Ein Grund für die Firmen ist sicherlich, dass es kostengünstiger und schneller ist, den Quelltext sofort in Englisch zu erstellen. Gerade wenn man in „exotischere“ Sprachen (asiatische Sprachen zum Beispiel) übersetzt, ist es leichter Übersetzer mit dem Sprachpaar „Koreanisch-Englisch“ zu bekommen als „Koreanisch-Deutsch“.
Fazit
Ich glaube, der Endkunde wird es immer irgendwie merken, wenn ein Nicht-Muttersprachler einen Text geschrieben hat. Zumindest hab ich die Erfahrung schon oft gemacht. Viele beachten diesen Aspekt nicht, wenn es um das Schreiben oder Übersetzen geht, bzw. ist er ihnen nicht bewusst. In der Realität sieht es nun aber leider doch so aus, als ob man als deutschsprachiger Redakteur auch immer öfter Englisch schreiben muss. Zu Lasten der Qualität… Aber vermutlich setzen hier viele Firmen auf das oft zitierte „Gut genug“.
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
xsl/common in deinem DITA-OT.strings.xml.
Neue Sprachdatei anlegen
xsl/commonund füge sie unter dem Namen es-co.xml in dasselbe Verzeichnis 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 🙂
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:
Was der Übersetzer sehen konnte, war einfach nur Text (vereinfachte Version):
Was am Ende dabei rauskam:
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.
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:
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:
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.
In der Softwarebranche kommen technische Redakteure früher oder später mit dem Thema „Oberflächentexte“ in Berührung. Ob sie sie schreiben oder nur verwalten dürfen, variiert von Firma zu Firma.
Bei mir gehört das Betexten der Oberflächen zum Arbeitsalltag und hier möchte ich gerne mal berichten, wie sich das gestalten kann.
Terminologiekontrolle, Hilfe und Beta-Test
Ich sehe es als klaren Vorteil, dass ich die Produkte betexten darf. So kann ich nämlich von vorneherein für eine entsprechende Textqualität sorgen – mit dem richtigen Text in der Software entfällt oft so mancher Hilfetexte. Ich denke, jeder Redakteur musste schon die ein oder andere krude Formulierung von Entwicklern oder Produktmanagern umständlich in der Hilfe erklären…
Für einen Redakteur ist das Betexten der Oberfläche also eine wunderbare Möglichkeit, um für Verständlichkeit und Terminologiekontrolle zu sorgen, aber sie eignet sich auch wunderbar zur Recherche für die späteren Hilfetexte. Dabei ist man dann gleich Beta-Tester, der schon weit vor der Qualitätssicherung die ersten Bugs findet. Ich finde das sehr spannend, weil ich gerne Applikationen neu entdecke und dabei der erste Usability-Tester bin 🙂
Ein Feld, das sicher noch stärker von Redakteuren erobert werden muss 🙂
Wie funktioniert Software-Lokalisierung?
Nun aber mal zu den technischen Grundlagen: Glücklich kann man schon mal sein, wenn der Text überhaupt vom Code getrennt ist 😉 In der Regel machen das die meisten Software-Entwickler auch automatisch so. Erstens ist es für Entwickler übersichtlicher. Zweitens kann man so die Applikation leichter in verschiedenen Sprachen betreiben, was auch meistens gefordert ist.
Gerade im Web-Bereich gibt es verschiedene Möglichkeiten zur Anwendungsbetextung.
Gemeinsam ist den meisten, dass man man pro Sprache eine große Datei mit dem gesamten Anwendungstext hat. Für jede Stelle an der Text erscheinen soll, wird in der Software eine ID vergeben. Dieser ID ist dann in der Datei beliebiger Text zugeordnet: ein Wort oder sogar ganze Sätze.
Nehmen wir als Beispiel mal WordPress, die Blog-Software, die ich hier benutze. Im Screenshot seht ihr den deutschen Text angezeigt:
“
Und hier seht ihr, wie das ganze in der Sprachdatei aussieht:
#: wp-admin/edit-page-form.php:202
msgid "pub_202"
msgstr "<b>Sofort</b> publizieren"
Die ID pub_202 wird in der Software als Platzhalter verwendet und je nach gewünschter Sprache wird der dazugehörige Text entweder aus einer deutschen oder bspw. englischen Sprachdatei gezogen. In der englischen Sprachdatei sieht der Eintrag so aus:
#: wp-admin/edit-page-form.php:202
msgid "pub_202"
msgstr "Publish <b>immediately</b>"
Bei einer Software wie WordPress kommt man auf stolze 3342 Texteinträge (Einträge, nicht Wörter!).
Soviel zu dem Grundlegendsten. Wie solche Dateien nun editiert werden können, was es bei der Software-Lokalisierung zu beachten gilt und welche Felsen man wie umschiffen kann… das seht ihr in den bald folgenden Posts 🙂
Es ist der Traum eines jeden Budgetverantwortlichen: „Wir stellen den zu übersetzenden Text ins Internet und die Community macht den Rest. Bei Wikipedia klappt das doch auch und bei dem ganzen Open-Source-Kram. Die Leute machen das umsonst.“ Facebook setzt schon voll auf die Community bei diesen Dingen.
Google Translate
Bevor ich weiter in die „Ja, aber im professionellen Umfeld kann man doch nicht…“-Diskussion einsteige, gehe ich einen Schritt zurück und widme mich einer der aktuellsten Google-Neuheiten: Google Translate (oder „Google Übersetzer“ wie er auf Deutsch heißt).
Google hat ein neues Tool mit einem neuen Ansatz entwickelt:
Wir geben unzählige Texte mit Milliarden von Wörtern in den Computer ein. Dabei handelt es sich sowohl um einsprachigen Text in der Zielsprache als auch um abgeglichene Beispielübersetzungen von Menschenhand. Anschließend wenden wir statistische Lerntechniken zur Erstellung eines Übersetzungsmodells an. Bei den Auswertungen haben wir sehr gute Ergebnisse erzielt. (Quelle)
Google-Translate ist ein Online-Übersetzungsservice, den jedermann ziemlich einfach nutzen kann.
Übersetzen lassen
Man kann eine Übersetzungsfunktion in seine Homepage einbinden, die es den Lesern ermöglicht die Seite mit 2 Klicks in einer anderen Sprache anzeigen zu lassen.
Um eine Webseite in einer völlig fremden Sprache wenigstens ein bisschen zu verstehen, ist das oft schon genug. Hier und da ist die Satzsstellung nicht ganz korrekt, aber wie bei einer Unterhaltung mit einem fremdsprachigen Menschen, kann man sich auch erstaunlich viel zusammenreimen / ableiten. Dennoch stößt man noch auf genug der eher ulkigen Sätzen, die noch zeigen, dass eine automatische Übersetzung nicht an einen Muttersprachler heranreicht. Das sagt Google aber auch selbst klipp und klar. Diese Funktion erschließt einem also einen noch viel größeren Teil der im Netz verfügbaren Information.
Selbst übersetzen
Soweit die eher passive Komponente. Kommen wir zu dem Teil bei dem man als Teil der Community aktiv werden kann.
Nun wird die Seite vorübersetzt, sofern möglich, angezeigt. Sobald man seine Maus über einen Absatz bewegt, bekommt man die Möglichkeit eine bessere Übersetzung einzugeben.
Klickt man auf den Link, öffnet sich direkt ein kleines Eingabefeld, in das man die Übersetzung eingeben kann. Die Übersetzung landet nach dem Abschicken im Übersetzungsppol von Google.
An diesem Punkt gibt man selbst eine völlig neue Übersetzung ein und hat keine Möglichkeit auf ein TM zuzugreifen, das einem z.B. 80%-Matches anzeigt. Google will hier vor allem soviel Übersetzungssegmente wie möglich sammeln.
Fazit
Aktuell ist es ein Tool, dass es einem ein manches Mal vielleicht ein bisschen einfacher macht auf fremdsprachigen Seiten zu surfen. Ein Szenario, dass eine Firma ihre Kundenwebseite gar nicht mehr übersetzt, sondern einfach nur Google Translate einbindet, scheint mir utopisch. Denn man kann hier nie 100%ig gewährleisten, dass nicht doch Müll auf der Seite steht.
Und bei Googles eigenen, automatisch übersetzten Seiten hätte ich im Übrigens gerade sehr gerne eine korrekte Übersetzung ins Deutsche eingegeben oder versteht das jemand? 😀
In solchen Fällen können Sie ein Translation Memory mit einer Übersetzung, indem Sie folgende Schritte Gesellschafterin
Nachdem ich mir nun Google Translate für jedermann angeschaut habe, kommt demnächst die Profi-Version dran: Google Translator’s Toolkit.
Hach, auch ein Global Player wie Hasi und Mausi kann ins Fettnäpfchen treten. Da widme ich mich über die Feiertage dem angenehmen Online-Shopping, als mir die neue Kampagne ins Auge springt. Allerdings weniger wegen der Shirts:
Eingabe? Wieso Eingabe? Was soll ich denn da eingeben? Moment, dem erfahrenen Software-Dokumentar fällt sofort die Eingabe-Taste ein. Und wie heißt die in Englisch? Genau: Enter.
Ne, ne, liebe Leute, auch die 100%-Matches in einem TMS sollte man überprüfen 🙂
Hier die UK-Variante, die etwas mehr Sinn macht!
Ich habe bereits vorgestellt, welche Möglichkeiten des manuellen Verlinkens es gibt. Wie gesagt, erschwert diese Methodik die Wiederverwendung eines Texts. Da Wiederverwendung jedoch einer der Kernpunkte von DITA ist, gibt es natürlich auch hier Mittel und Wege. Und zwar indem man die Verlinkungregeln in die Maps auslagert. So kann man auch nur das verlinken, was in der Map drin ist und läuft nicht Gefahr tote Links zu erzeigen.
(mehr …)