Bearbeiten Drucken

Voraussetzungen fürs Übersetzen


Was solltest Du können?


  • Englisch- und Deutschkenntnisse, letztere einschließlich der so genannten Rechtschreibung (d. h. auch bei KDE: der neuen Rechtschreibung). Also bitte einen aktuellen Wahrig oder Duden oder sowas griffbereit haben. Erste Hilfe zu den neuen Regeln gibts natürlich hier (external link) und da (external link) auch im Netz. Auch in der Link-Liste finden sich ein paar gute Hilfestellungen.

  • Selbstständiges Arbeiten und Teamfähigkeit sind wichtig (nicht zu vergessen: eine gewisse Zähigkeit — schon allein um sich durch diesen ganzen Wust hier durchzugraben ;)
    Zunächst mal wurstelt hier jeder allein vor sich hin und kriegt die andern Wurstler und Wurstlerinnen niemals zu sehen. Insofern ist Übersetzerei auf den ersten Blick ein prima Tummelfeld für Individualisten. Außerdem machen alle ihren KDE Job ja "irgendwie nebenher" (was nicht dasselbe ist wie "mit links"). Jedes Rumgefrage und Rumdiskutieren geht von dieser immer zu knappen Zeit ab.
    Trotzdem soll spätestens am Stichtag einer Release-Version ein möglichst einheitliches Ergebnis vorliegen, das auch professionellen Ansprüchen genügt.
    Das geht nicht ohne ein Mindestmaß an Organisation im Ganzen und Verlässlichkeit beim Einzelnen — jeder, der eine Aufgabe übernimmt, sollte sie auch bis zum Stichtag durchziehen oder zumindest rechtzeitig Bescheid geben, wenn das nicht klappt. Unter Umständen muss man auch mal zurückstecken und die persönlich bevorzugte Übersetzung opfern, um die Einheitlichkeit zu wahren.

  • Du solltest dich so weit mit der KDE-Umgebung auskennen, dass du Vorversionen selbstständig installieren kannst. Das bedeutet: den Code der jeweils bevorstehenden Version bzw. den "trunk" des SVN kompilieren und installieren. Das ist notwendig, um deine Übersetzungen im realen Umfeld überprüfen zu können, bevor sie offiziell veröffentlicht werden. Das Übersetzen findet nämlich in einer Art Blindflug statt, und es ist oft schwierig, von mehreren möglichen Übersetzungen eines Wortes auch nur die völlig verkehrten auszuschließen. Die nachträgliche Kontrolle im Kontext zeigt dann, in wie weit das geklappt hat oder eben nicht. Außerdem ist auch erst hier zu sehen, ob nicht irgendwo die meist längeren deutschen Übersetzungen in Dialogboxen und Meldungsfenstern abgeschnitten werden, ob alle Tastenkürzel funktionieren usw. Man kommt also nicht drum rum.
    Grundkenntnisse im Programmieren sind hier (und überhaupt) ein großer Vorteil, aber nicht zwingend erforderlich. Wenn sie nicht vorhanden sind, braucht man allerdings Nerven und eine gewisse Zähigkeit. Erste Hilfe findest du dabei im Developer HOWTO (external link) (leider nicht immer ganz aktuell), den entsprechenden Rubriken der KDE-Website (external link) und den diversen "resources", die auf der Startseite (external link) des Editorial Teams angeführt sind (darunter z. B. "Get the Sources / Anonymous SVN" (external link). "Zweite Hilfe" findest du am ehesten in den KDE-Newsgroups und -Mailinglisten.

  • Für die Übersetzung von Onlinehilfe und Dokumentation solltest du dich mit XML anfreunden. (Man muss aber kein Experte werden: Näheres steht im Doku-Howto.) — Die Tendenz geht dahin, dass GUI und Dokumentation möglichst vom selben Übersetzer stammen oder, bei zwei Übersetzern, die beiden zumindest eng zusammenarbeiten sollten. Siehe unten, Stichwort "Kontrolle der Übersetzung" und besonders "Endredaktion".


Software und Kompilieren der Quellen


Zur Kompilierung des Quellcodes siehe How to get KDE3.x.x and KDE3.5 (from SVN repository) working on the same machine (external link) von Anne-Marie Mahfouf. Weiteres Material dazu findet sich auf den KDE-Webseiten (external link) bzw. den Entwicklerseiten (external link).

Zum Übersetzen der Benutzeroberfläche genügte früher ein ASCII-Editor. Nachdem die entsprechenden Dateien allerdings auf Unicode umgestellt wurden (UTF8-Format), ist das nicht mehr der Fall. Das einzig wirklich dafür in Frage kommende Programm für diese Arbeit ist jetzt KBabel von Matthias Kiefer, beziehbar von dem l10n FTP-Server (external link) oder der Homepage des Programms (external link), wo sich auch weitere Angaben dazu finden. Außerdem besteht eine gute Chance, dass du KBabel bereits auf deinen Distributions-CDs hast, zu finden im Paket "kdesdk". Für die praktische Arbeit reicht es, KBabel auf automatisches Speichern in UTF-8 einzustellen. Das Programm kümmert sich dann um den Rest.
Eine Aufzählung der Pakete, die für die Arbeit mit Dokumentationen im DocBook-Format benötigt werden, findest du in dem MiniHowto von Frank Schütte.


In welche Mailinglisten solltest du eingeschrieben sein?


In mindestens zwei, nämlich




In diesen Zusammenhang gehört auch das Webforum für die Diskussion schwieriger Begriffe bzw. die Archivierung solcher Diskussionen.
Wenn du dich für die Übersetzung bzw. Gestaltung der deutschsprachigen KDE-Webseite interessierst, solltest du zudem eingeschrieben sein in die


Darüber hinaus gibt es natürlich eine Menge weiterer Mailinglisten zu anderen Aspekten von KDE (siehe www.kde.org/contact/ (external link) bzw. die zugehörigen Archive unter lists.kde.org (external link)) sowie zwei Newsgroups (die deutsche unter de.alt.comp.kde (external link) und die internationale auf comp.windows.x.kde (external link)). Zumindest die deutsche Newsgroup sollte so weit als möglich mitverfolgt werden, da dort immer mal nützliches Feedback zu unserer Arbeit zu finden ist.
Auch ein gelegentlicher Blick auf die üblichen News-Sites wie Slashdot und natürlich die entsprechende KDE-Site dot.kde.org (external link) können nicht schaden.


Ziele der Übersetzung


"Professionalität" und was damit zusammenhängt


Im Großen und Ganzen scheint Einmütigkeit darüber zu bestehen, dass das Produkt unserer übersetzerischen Bemühungen folgende Eigenschaften aufweisen sollte:

  • Es sollte "professionellen Ansprüchen" genügen — und zwar in doppelter Hinsicht: mit der Übersetzung sollte sich reibungslos arbeiten lassen, und: sie sollte mindestens dieselbe Qualität haben wie kommerziell erstellte Übersetzungen.

  • Was "professionell" hier nicht heißen soll, wäre: "nur für UNIX-Profis"; im Gegenteil: die Übersetzung wendet sich an "deutschsprachige Normalnutzer" — soll heißen: Leute, die in ihrem Feld alles mögliche draufhaben mögen, aber weder gelernte Systemadministratoren sind noch mit englischsprachigen Originalversionen vertraut. Idealerweise sollten auch die UNIX-Profis nicht von unseren Übersetzungen genervt sein. Aber man kann's bekanntlich selten allen recht machen. Wer was auszusetzen findet, ist herzlich eingeladen, das mitzuteilen und ggf. Verbesserungsvorschläge zu machen. Der beste Platz dafür ist wohl das Webforum.

  • Was in der "Professionalität" und im ganzen Ansatz eines graphischen Desktops dagegen schon drinsteckt, ist die Vorgabe der "Einheitlichkeit", hier eben als "Einheitlichkeit der Übersetzung" — dazu unten mehr.


Wörtlich oder frei übersetzen?


Insgesamt eher frei. Jedenfalls immer dann, wenn das Original mindestens einen der folgenden Punkte erfüllt:

  • es ist unklar (schwammig, widersprüchlich usw.)
  • missverständlich bis irreführend
  • veraltet oder sachlich falsch (was in Dokus durch einen gut sichtbaren "FIXME"-Kommentar kenntlich gemacht und an den Autor gemeldet werden sollte)
  • oder einfach zu schlecht geschrieben (massenhafte Wortwiederholungen, Formulierungen "von hinten durch das Knie ins Auge" usw.) Siehe den nächsten Abschnitt.


Stilfragen


Neben rein inhaltlichen Überlegungen gibt es auch stilistische Überlegungen, die zu einer freieren Übersetzung führen. Was im amerikanischen Sprachraum noch völlig in Ordnung ist, wirkt hierzulande leicht zu kumpelhaft, zu wenig sachlich und somit unseriös. Andererseits sollte man auch nicht vor lauter Seriösität in Krämpfe verfallen und reinen Akademikerjargon produzieren. — Die folgenden Regeln haben sich bewährt:

  • Umgangssprachliche, witzelnde, jargonbefrachtete oder kumpelhafte Wendungen sollten durch neutrale ersetzt oder ganz weggelassen werden.

  • Außer bei Spielen und Kinderprogrammen bitte persönlich gefärbte Programmeldungen vermeiden. Das betrifft nicht nur krasse Fälle wie "Hey, was ist los?" (statt: "Es ist ein Fehler aufgetreten"), "Ich weiß nicht, was ich machen soll" (statt: "Unzulässige Benutzereingabe") oder massenhafte Smileys und sonstige Emoticons. Man mag das als "typisch deutsche Humorlosigkeit" bedauern, aber Programme, die beständig das Gespräch mit dem Benutzer zu suchen scheinen, werden hierzulande oft als aufdringlich, ablenkend und anstrengend empfunden. Es sind daher generell unpersönliche oder passive Konstruktionen gegenüber "Ich"-Aussagen des Programms vorzuziehen. Und statt der reichlichen, überschwänglichen Ausrufezeichen tut es im Deutschen meistens ein Punkt.

  • Möglichst keine akademischen Ausdrücke und überflüssige Abstrakta, erst recht kein Techno- oder Newsgroup-Slang. (Also einfach "Einrichtung" statt "Konfiguration", "Knopf" statt "Button" oder "Schaltfläche", "Die Funktion ist noch nicht verfügbar" statt "nicht implementiert" usw.)

Außerdem:

  • Man sollte sich um eine Wortstellung bemühen, die Bindestrich-Ausdrücke vermeidet. ("Benutzer von x und y" statt "x-y-Benutzer" oder "Ausdrücke mit Bindestrich" statt wie eben gelesen;) Das heißt aber nicht, dass orthographisch korrekte Bindestriche einfach weggelassen werden sollten. (Es heißt also weiterhin "KDE-Benutzerhandbuch". Alles andere erschwert nicht nur die Lesbarkeit, es ist einfach falsch.)

  • Und natürlich: Bitte keine englischen Ausdrücke verwenden, wenn es entsprechende deutsche gibt.

Die Grenzen in diesem Bereich sind naturgemäß schwer zu ziehen. Insgesamt sollte ein gut lesbarer, sachlicher Text entstehen, der möglichst wenig von dem ablenkt, worum es in erster Linie geht, nämlich Programmfunktionen. Außer bei hochspezialiserten Programmen sollten die Texte möglichst für normale Büroangestellte ohne technische Zusatzausbildung verständlich sein.


Ideal und Wirklichkeit


Oft ist es natürlich furchtbar schwer zu entscheiden, was all diese hehren Zielsetzungen für den konkreten Übersetzungsfall bedeuten. Und manchmal kommt am Ende doch nichts heraus, womit man wirklich zufrieden sein könnte. Oder es passt halt nur im einen Fall, aber ein paar Zeilen später schon wieder nicht mehr. Damit hat nun mal jede Übersetzung zu kämpfen.

Klassische Fragen sind z. B.:

  • Soll der Begriff überhaupt übersetzt werden? ("mount", "Email", "Newsgroup"...)

  • Gibts eine Standardübersetzung des Begriffs und wenn ja, wollen wir die übernehmen?

  • Soll die Übersetzung durchgehend sein (Stichwort "Einheitlichkeit") oder je nach Kontext (Stichwort "Verständlichkeit")?

  • Soll der Begriff die englische Vorstellung transportieren, so dass man das Original möglichst leicht wiedererkennt (z.B. "Thema" für "theme"), oder sucht man etwas, was die Sache auf Deutsch vielleicht verständlicher macht, aber dafür den Wiedererkennungseffekt verliert ("Design" für "theme")?

Grundsätzlich werden solche Sachen in der Mailingliste diskutiert, konkrete Einzelfragen zu bestimmten Begriffen im Webforum.


Stichwort: Einheitlichkeit

...oder: die Sache mit der Teamarbeit.


Einheitlichkeit ist ein wichtiger Aspekt in der Übersetzungsarbeit. Zum Beispiel sollte überall dieselbe Rechtschreibung zugrunde liegen (d. h. für uns: die neue). Nicht mal "dass" und mal "daß", oder mal "Menu" und dann "Menü" oder mal "Panel" und dann "Kontrollleiste" und dann vielleicht wieder eine ganz andere Übersetzung. Womöglich auch noch unterschiedlich in den Menüs und der Dokumentation des Programms — jedenfalls nicht ohne zwingenden Grund.

Klar, dass wir hier auch auch keine Bürokratie aufbauen wollen, um alles bis ins Letzte durchzuregeln. Aber da es bei KDE nun mal v. a. um Einheitlichkeit geht, sollte das natürlich auch die Übersetzung widerspiegeln.

Im Moment kristallisiert sich dazu Folgendes heraus:

  • Erste Hilfe bietet KBabelDict, das eine Datenbank aller übersetzten Strings aus den deutschen PO-Dateien erstellt und für das Übersetzen mit KBabel benutzt werden sollte; damit können z. B. Begriffe im Original markiert und dann alle bisher auftauchenden Übersetzungen dafür angezeigt werden; es wird auch für "Diffs" benötigt (also die Anzeige dessen, was sich im Original seit dem letzten Durchgang eventuell geändert hat)

  • Weiterhin zu konsultieren wäre kdedict (external link), weitere Info dazu gibt es auf einer extra Seite (external link).

  • Die Diskussion der Begriffe selber läuft in einem separaten Webforum, und zwar nur dort! Wer sich ein Bild vom Stand der Diskussion machen möchte bzw. herausfinden will, warum ein Begriff so und nicht anders übersetzt ist bzw. selber Vorschläge zu machen hat, der schaut sich am besten dort um.

Alle Beiträge, die ins Übersetzer-Forum gestellt werden, gehen übrigens automatisch auch in die deutsche Mailingliste kde-i18n-de. Die Beiträge sollten aber bitte nicht über die Liste, sondern ggf. wiederum über's Forum beantwortet werden, siehe den entsprechenden Link am Ende solcher Mails.

Vorschläge zur weiteren Verbesserung der Situation sind, hier wie überall, stets willkommen. Die nächste Frage wäre aber natürlich, wie das eigentlich kontrolliert werden soll — kein gescheiter Laden kommt ohne eine Form von Qualitätskontrolle aus. Und wir sind da keine Ausnahme.


Kontrolle der Übersetzung


Korrektur- und Gegenlesen


Ursprünglich hat sich da jeder selbst drum gekümmert. Bekanntlich ist das aber der sicherste Weg, einen Haufen Rechtschreib- und Grammatikfehler einzubauen — man "kuckt sich einfach blind" an Texten, die man dauernd vor sich hat.

Folgendes Verfahren hat sich über die Zeit hin bewährt:

  • Sämtliche fertigen PO-Dateien und Dokumentationen werden zunächst an den Koordinator geschickt, der sie dann entweder selbst gegenliest und "offiziell freigibt" oder andere Teammitglieder darum bittet. Letzteres sollte natürlich durchgehend für die Übersetzungen des Koordinators selbst gelten (passiert aber leider auch nicht immer). Ein transparenteres Verfahren, wer wann was gegenliest, wird angestrebt, ist aber noch nicht gefunden. Insgesamt sollte aber vermieden werden, dass immer die selben Leute immer die selben Sachen Korrektur lesen, um eben den Effekt von "sich blind kucken" zu vermeiden.

Beim Gegenlesen selbst werden:

  • Rechtschreib- und Grammatikfehler stillschweigend korrigiert, einschließlich eventueller Umstellung auf die neue Rechtschreibung
  • Konsistenzfehler ebenfalls korrigiert, aber nicht stillschweigend (der jeweilige Übersetzer wird auf den aktuellen Stand hingewiesen)
  • Dasselbe gilt für Stilprobleme. Die werden je nachdem mit dem Übersetzer diskutiert oder, in verallgemeinerter Form, über die Mailingliste bzw. im Webforum.

Letzteres ist natürlich der schwierigste Punkt. Das Ganze darf keinesfalls in "typisch deutsche" Schulmeistereien oder leerlaufende Streitereien ausarten. Es wird grundsätzlich ein Konsens angestrebt und nur, wenn der absolut nicht zustande kommt, wird eine vorläufige Festlegung durch den Koordinator vorgenommen.


Endredaktion


Zumindest die Endredaktion von GUI und Doku sollte aus einer Hand kommen und nicht nur eine Überprüfung auf Standardprobleme umfassen, sondern einen kompletten Abgleich von derzeitiger Programmoberfläche, eventuellen Bildschirmphotos und allen übersetzten Texten. Um das überhaupt sinnvoll machen zu können, muss einer natürlich den gesamten Stand der Diskussion zum "Stichwort: Einheitlichkeit" und sämtliche offiziellen Übersetzungen präsent haben, auf die sich das Team zum jeweiligen Zeitpunkt geeinigt hat bzw. die vom Koordinator als jeweils verbindlich "abgesegnet" sind.

Wenn man dann noch berücksichtigt, dass eventuell auch noch einiges Hin- und Hergeschreibe mit den Programm- und/oder Doku-Autoren ansteht, dann dürfte klar sein, dass diese Endredaktion manchmal eine sehr zähe und zeitaufwändige Sache sein kann.


Die Rolle des Koordinators


Ursprünglich wurde das "Team Leader" genannt und hier und da liest man den Ausdruck immer noch. Im deutschsprachigen Team allerdings nicht. Der gegenwärtige Koordinator kann prima auf "Führer" verzichten, einschließlich einer solchen Rolle für sich selbst. — Das ändert naturgemäß nichts daran, dass sich Begriffs- oder Verfahrensdiskussionen dermaßen festfressen können, dass jemand das letzte Wort haben muss, wenn es trotzdem weitergehen soll. Das deutsche Übersetzerteam hat derzeit zwei Koordinatoren.


Wer macht gerade was?


Es gibt zwei Tabellen in denen man nachsehen kann, wer gerade an welchen Programmteilen und Handbüchern arbeitet. Die Tabelle berücksichtigt nur fest zugewiesene Betreuer für die jeweiligen Übersetzungsarbeiten. Es kann immer mal vorkommen, dass jemand kurzfristig etwas übersetzt, was in der Liste als frei markiert ist. Wer eine freie Datei übersetzen möchte, schickt bevor er anfängt(!) eine E-Mail an die Mailingliste (external link).



Wo wird Hilfe gebraucht?


Es werden immer wieder Leute gebraucht, die in den Extragear-Modulen aushelfen.
Auch im Bereich Doku-Übersetzung wird oft Hilfe benötigt. Eine Liste der noch komplett unübersetzten Dokumentationen zeigt KBabel (bzw. der Katalogmanager) an. Dafür müssen nur die entsprechenden deutschen Dateien und Vorlagen aus dem SVN installiert sein. Hilferufe und Übersichten über den aktuellen Bedarf erscheinen gelegentlich auch in der Mailingliste.


Wo fange ich an?


Schick am besten eine E-Mail an den Team-Koordinator oder an die Mailingliste. Aus der Mail sollte ungefähr ersichtlich sein, was dich besonders interessiert. Und sage möglichst dazu, wieviel Zeit du ungefähr mitbringst — genug, um hier und da mal ein Progrämmchen zu übersetzen oder genug für einen ganzen Ordner voll davon?

(Um einen Punkt der Standardantwort gleich vorwegzunehmen: es führt leider kein Weg um die Lektüre des gesamten Materials auf der Teamsite herum. Ich weiß, das ist ein harter Brocken, aber leider nicht zu vermeiden. Vorschläge, wie man ihn verdaulicher machen könnte, sind natürlich immer willkommen.)

Falls du an einer bereits betreuten Übersetzung was auszusetzen hast, tritt bitte direkt mit dem zuständigen Übersetzer in Verbindung. Für allgemeines Feedback zur KDE Übersetzung bitte den dafür vorgesehenen Bereich im Webforum benutzen.

BearbeitenQuelleHistorie

Menü