Muttersprachen-Prinzip

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“.

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.

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.


Arbeite mit DITA und sprich darüber?

Ich war in den letzten Monaten häufiger in der Situation, das ich Kollegen aus anderen nicht-TR-Abteilungen erklären musste, wie wir in unserem Team eigentlich inzwischen Hilfe schreiben und warum manches nicht mehr so läuft wie früher.

Das Wort DITA nehme ich dabei übrigens eigentlich nur ganz nebenbei in den Mund. Warum? Weil es den Damen und Herren total egal sein kann 🙂 Das ist jetzt nicht überheblich gemeint, aber es ist für sie ja auch gar nicht wichtig zu wissen,dass wir mit DITA arbeiten. Viele Leute konzentrieren sich oft viel zu sehr darauf einem zu erklären WIE sie etwas machen anstatt dass sie einem erklären WAS es den Beteiligten bringt. Oft beobachtet bei Entwicklern, die einem gern die Namen der neuesten Trendtechnologien um die Ohren hauen, die einen dann nur ratlos schauen lassen…

In unserem Fall ist das Prinzip unserer neuen Arbeitsweise an und für sich beispielsweise das wirklich Essentielle:

  1. Standardisierung
  2. Topic-Orientierung
  3. Trennung von Inhalt und Layout

Das sind die wichtigsten nach außen sichtbaren Vorteile und ich konzentriere mich lieber darauf diese transparent zu machen als dass ich groß DITA erkläre.

Man muss hierbei bedenken, dass sich das Vehikel mit dem wir diese Prinzipien umsetzen, auch mal ändern kann.

Die Abteilungen mit denen ich hier zusammen arbeite sind in der Regel vom Endergebnis betroffen und dann kann ihnen das WIE völlig egal sein. Sie müssen vor allem wissen warum sie die neue Arbeitsweise gut finden sollen 😉

Technische Redaktion – eine gute Wahl?

Diese Woche bekam ich eine Anfrage einer zukünftigen TR-Studentin, die gerade etwas verunsichert ist:

Seit ich die Zusage habe stolpere ich aber eigtl. nur noch über Berichte, wie langweilig und undankbar der Job als Technische Redakteurin sei und dass sowieso die meisten nicht lange in diesem Job durchhalten. Langweilig deswegen, weil es oft nur noch darum ginge, die von den Entwicklern gelieferten Texte in die Doku zu kippen. […] Wie beurteilst du denn die Punkte Langeweile und Undankbarkeit? Was denkst du, sollte man unbedingt mitbringen, wenn man diesen Beruf ausüben will?

Suche dir eine interessante Branche
Das ist für mich einer der wichtigsten Punkte. Bei mir waren es schon immer Software und Internettechnologien, die so mein Steckenpferd waren. Für mich sind die Recherche und das Ordnen meiner Ergebnisse mitunter die interessantesten Aspekte an der Arbeit und da sollte einen der Gegenstand doch etwas mehr interessieren. Einen Ausflug in die Elektrotechnik habe ich z.B. sehr schnell beendet, da ich kein besonderes Faible dafür habe. Ich konnte mich schon in die Materie einarbeiten, aber am Ende fiel es mir immer schwer mich in den Installateur oder Inbetriebnehmer hinzuversetzen – und dementsprechend habe ich sicherlich auch nicht die besten Hilfetexte meiner Laufbahn abgeliefert. Es war einfach nichts für mich.
Suche dir deine Schwerpunkte

Ich hab schon die Vielfalt des Studiums, des Jobs und der späteren Möglichkeiten erwähnt. Man kann sich seinen Schwerpunkt suchen und den möglichst bei der Jobwahl berücksichtigen. Wenn ich bspw. feststellen würde, dass ich nur Entwicklertexte in ein Worddokument reinkopieren und umformatieren soll… DAS ist  keine technische Redaktion.

Mach was draus

Was ist, wenn man schon im Job steckt und nicht so ganz zufrieden ist? Nun, ein Weg ist mal zu schauen, was der Horizont um einen hergibt. Also Augen offen  halten und selbst aktiv  werden. Was kann man bspw. im Team und in der Zusammenarbeit optimieren? Du merkst z.B. dass es doch immer wie zu Inkonsistenzen beim Schreiben kommt, weil der Redaktionsleitfaden nicht eindeutig ist. Hey, organisiere ein  regelmäßiges Review von Texten und ggf. das Update des Leitfadens. Oder du fängst mal an überall für Terminologiearbeit zu werben, weil diese aktuell nur von der TR betrieben wird.

Bringe folgendes mit

Neugier, Geduld (auch bekannt als:  Leidensfähigkeit und langer Atem), gute Strukturierungsfähigkeit, ein bisschen Unnachgiebigkeit (auch bekannt als: den Technikern mit 100 Rückfragen alles aus der Nase ziehen), ein bisschen Kämpfertum (auch bekannt als: und wir kriegen euch alle dazu diesen Term zu verwenden!). Und natürlich: einwandfreie Sprachkenntnisse und Interesse an Technik.

Akzeptiere einiges… 🙂

Gegen die Langweile kann man schon vorab sehr viel tun – das ist meine Meinung. Außer man ist vielleicht in einer sehr strengen und unflexiblen Umgebung, aber für mich wäre sowas schon mal gar nichts 😉

Und nun zurUndankbarkeit… ja… das ist so. Jeder kann schreiben (handwerklich gesehen) und manche verstehen nicht einmal den Unterschied zwischen dem vom Entwickler geschriebenen Text und dem vom Redakteur (ok, das sind echt die ganz harten Nüsse, die man am besten ab sofort mit dem bösen Blick straft). An der TR wird gern gespart – mit Zeit,  Geld und Anerkennung. Manchmal kann man die Hilfe nicht so gut machen wie man gerne möchte, manchmal kriegt man doch wieder einen Term um die Ohren geklatscht, den das Marketing dann bitte doch anders haben möchte… Manchmal kriegt man einfach echt nur die Krise.

Das muss man teilweise einfach ertragen können – und teilweise muss man einfach so kämpferisch sein und unermüdlich immer wieder die Wichtigkeit des eigenes Berufs betonen. Für mich ist dieser Beruf gerade wegen seiner Vielfalt noch immer genau mein Ding. Früher sah ich es als Makel ein Allrounder zu sein, so nach dem Motto: man kann viel, aber nichts zu 100%. Inzwischen weiß ich, dass auch 75-80% langen und genau das mein Vorteil ist 🙂

Nachtrag: Sehr interessant hierzu ist auch der Artikel Tired of technical writing? How I revjuvenated my career