KDE Localization/de/UebersetzungVoraussetzungen

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 so etwas griffbereit haben. Erste Hilfe zu den neuen Regeln gibts natürlich hier und da auch im Netz. Auch in der Link-Liste finden sich ein paar gute Hilfestellungen.

Selbstständiges Arbeiten und Teamfähigkeit

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

KDE kompilieren

Du solltest dich soweit 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, inwieweit 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 (leider nicht immer ganz aktuell), den entsprechenden Rubriken der KDE-Website und den diversen "resources", die auf der Startseite des Editorial Teams angeführt sind (darunter z. B. "Get the Sources / Anonymous SVN". "Zweite Hilfe" findest du am ehesten auf den KDE-Mailinglisten oder im IRC.

Doku/XML

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 die TechBase-Seite zum Kompilieren von KDE 4 aus Trunk oder, etwas einfacher, verwende kdesrc-build. Zum Übersetzen der Benutzeroberfläche genügt ein ASCII-Text-Editor, sofern dieser UTF8 unterstützt. Wesentlich kompfortabler ist jedoch das Programm Lokalize.

In welche Mailinglisten solltest du eingeschrieben sein?

In mindestens eine:

Die deutschsprachige Teamliste [email protected]

Einschreibmöglichkeit und Archive finden sich unter [1].

Wer zusätzlich die allgemeine Koordination der Übersetzungen verfolgen möchte, kann sich auch auf [email protected] einschreiben. Einschreibmöglichkeit und Archive finden sich unter [2].

Darüber hinaus gibt es natürlich eine Menge weiterer Mailinglisten zu anderen Aspekten von KDE (siehe [3] bzw. die zugehörigen Archive unter [4]).

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 sind. Idealerweise sollten auch die UNIX-Profis nicht von unseren Übersetzungen genervt sein. Aber man kann es bekanntlich selten allen recht machen. Wer was auszusetzen findet, ist herzlich eingeladen, das mitzuteilen und ggf. zu machen.

• 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" usw.)
• 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 auf der Mailingliste diskutiert.

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.

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 "guckt 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 in Phabricator gestellt, wo sie dann von anderen Teammitgliedern gegengelesen und vom Koordinator "offiziell freigegeben" werden. Langjährige Übersetzer spielen ihre Übersetzungen normalerweise direkt ein, wo sie stichprobenmäßig von anderen langjährigen Übersetzern überflogen werden.

Beim Gegenlesen selbst werden:

• Rechtschreib- und Grammatikfehler korrigiert, einschließlich eventueller Umstellung auf die neue Rechtschreibung
• Konsistenzfehler korrigiert
• Stilprobleme korrigiert

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 Bildschirmfotos 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

Begriffs- oder Verfahrensdiskussionen können sich manchmal dermaßen festfressen, dass jemand das letzte Wort haben muss, wenn es trotzdem weitergehen soll. Das deutsche Übersetzerteam hat derzeit zwei Koordinatoren.

Wo fange ich an?

Schicke am besten eine E-Mail 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.)