KDE Localization/de/entwurf neue gliederung/Handbuch2

Handbuch für Übersetzer
(Autor: Thomas Reitelbach)
(Überarbeitet: Frederik Schwarzer)

Voraussetzungen

Einleitung

Dieses Handbuch soll neuen Übersetzern im KDE-Übersetzerteam eine Hilfe zum Einstieg sein. Doch auch für die Profis sollte es nicht nutzlos sein, sondern ist durchaus als Nachschlagewerk zu betrachten. Wer Fehler findet oder Verbesserungsvorschläge hat, möge diese bitte selbst korrigieren oder sich auf der Mailingliste melden. Wir sind dankbar für jede konstruktive Kritik!

Ein paar Dinge vorab

Der einfachen Lesbarkeit halber möchte ich in diesem Handbuch nur von "dem Übersetzer" sprechen. Gemeint ist damit gleichbedeutend natürlich auch eine Übersetzerin! Des Weiteren duzen wir uns auf der Mailingliste und so geschieht es auch hier. Es fühle sich also bitte niemand auf den Schlips getreten :)

Bevor ein Übersetzer mit seiner Arbeit in unserem Team beginnt, sollte er sich eingangs selbst ein paar Fragen stellen -- zuerst solltest du herausfinden, ob du ein paar Grundvoraussetzungen mitbingst. Natürlich machen wir keinen Einstellungstest - lies einfach weiter ;-)

Voraussetzungen fürs Übersetzen

Wenn man sich in einem Übersetzerteam betätigt, schadet es nicht, ein paar Voraussetzungen bereits mitzubringen. Das ist nicht nur für das Team wichtig, sondern auch für dich selbst. Denn wenn diese Voraussetzungen nicht erfüllt sind, könntest du schnell gefrustet sein und die Lust an der an sich sehr interessanten Arbeit verlieren.

Ein paar Dinge sind also wichtig:

Englisch- und Deutschkenntnisse

Wir erwarten keinen Deutsch- oder Englischlehrer, aber du solltest beide Sprachen zumindest gut beherrschen. Für manche Gebiete ist auch Spezialwissen hilfreich (z. B. mathematische Begrifflichkeiten).

Neue Deutsche Rechtschreibung

In KDE wird seit deren Einführung die Neue Deutsche Rechtschreibung verwendet. Das gilt übrigens auch für die Reformen der Reformen der Reformen ;-) Ein aktueller Duden oder Wahrig könnte sich als guter Freund erweisen.

Teamgeist und Eigenständigkeit

Auf der einen Seite solltest Du Dich möglichst eigenständig durch den ganzen Übersetzungswust durchkämpfen können; auf der anderen Seite muss man aber auch mal auf die eigene bevorzugte Übersetzung zugunsten der KDE-weiten Einheitlichkeit verzichten können. Hier ist es wichtig, Teamgeist zu zeigen.

Installation von KDE-Vorabversionen

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.

Was ist die richtige Aufgabe für mich?

Bevor du loslegst, solltest du dich erst einmal fragen, was du überhaupt machen möchtest und wo deine Stärken liegen. Übersetzen ist nämlich nicht gleich Übersetzen! Einige Arbeitsbereiche sind beispielsweise wesentlich technischer als andere.

Die meisten Übersetzungseinsteiger denken erst einmal nur ans Übersetzen der Programmoberflächen. Aber eigentlich gibt es drei große und wichtige Bereiche:

• GUI-Übersetzung (Programmoberflächen)
• Doku-Übersetzung (Handbücher)
• Korrekturlesungen

Wieviel Zeit bringe ich mit?

Vor der Auswahl eines Programms oder Handbuchs solltest du dich fragen, was du in deiner freien Zeit schaffen kannst bzw. wieviel Zeit du aufbringen möchtest. Grundsätzlich ist es empfehlenswert, sich erst einmal an einem kleinen Projekt zu versuchen, um herauszufinden, wieviel Zeit man benötigt.

Anmerkung: Entscheide dich nach Möglichkeit für ein Testprojekt, an dem du auch nach der "Erfahrungsphase" noch Freude hast - nach Möglichkeit sollte jedes Programm einen dauerhaften Betreuer haben und nicht ständig wechselnde Übersetzer.

Wenn du während der Arbeit an einem Programm merkst, dass du es zeitlich entgegen aller Voraussicht nicht mehr schaffst, solltest du deine bisher geleistete Arbeit umgehend an die Koordinatoren weiterleiten, da sie ansonsten komplett verloren ist. Das verursacht auch Frust bei den Koordinatoren, die beratend zur Seite stehen und dann eine blockierte Übersetzung haben, deren Status unbekannt ist und die womöglich nie abgeliefert wird.

Technisches

Einleitung

Dieser Teil des Handbuches beschäftigt sich mit den technischen Hürden und Fragen, die einen Übersetzer bei seiner Arbeit begleiten. Es ist nicht immer leicht, sich den ganzen technischen Kram zu merken. Dies gilt insbesondere dann, wenn man nur hin und wieder mal etwas übersetzt. Dieses Kapitel sollte also ohne Scheu auch als Nachschlagewerk genutzt werden.

Organisatorisches

Abläufe

Die organisatorische Struktur des Teams

Das deutsche Übersetzerteam von KDE ist im Grunde nicht hierarchisch organisiert. Es gibt also niemanden, der von oben herab die Arbeit befiehlt. Jeder wurstelt auf eigene Faust selbst herum und erledigt sein Tun auf gleicher Ebene zusammen mit all den anderen Wurstlern.

Das bedeutet aber nicht, dass wir völlig unorganisiert und durcheinander sind -- irgendwer muss natürlich den Überblick behalten oder auch mal eine verbindliche Entscheidung treffen. Deshalb gibt es bei uns die Koordinatoren.

Koordinatoren

Es gibt in unserem Team zwei Koordinatoren. Wie bereits erwähnt, sind die Koordinatoren nicht die "Chefs" des Teams, sondern vielmehr diejenigen, die den Überblick behalten und im Zweifelsfall das letzte Wort haben, wenn sich Begriffs- oder Verfahrensdiskussionen einmal komplett festgefahren haben.

Koordinatoren

Kontakt

Für Übersetzer gibt es ein paar interessante Mailinglisten. Eine davon ist absolute Pflicht:

<[email protected]>, Mailingliste der deutschen KDE-Übersetzer

Auf dieser Mailingliste sind alle deutschen KDE-Übersetzer eingetragen. Hier findet unsere gesamte Kommunikation statt.

Kontakt

KDE-Mailingliste zu deinem Programm/Modul

Es gibt noch viele weitere Mailinglisten.

Eine Liste mit allen findest Du hier: [1]

Was muss übersetzt werden?

PO(T)-Dateien

Alle KDE-Übersetzer arbeiten mit sogenannten "Portable Objects"-Dateien. Davon gibt es zwei Arten:

POT-Dateien

Hierin befinden sich nur englischsprachige Nachrichten. Das "T" in POT steht für Template, also Vorlage. In der Regel hat jeder Übersetzer für jedes Programm nur einmal mit einer solchen Vorlage zu tun, danach arbeitet er nur noch mit den daraus entstandenen PO-Dateien.

PO-Dateien

In den PO-Dateien befinden sich sowohl die englischen Originalnachrichten als auch die Übersetzungen. Die meiste Zeit arbeiten wir also mit den PO-Dateien.

stable/trunk? Was hat es damit auf sich?

In KDE gibt es vier wichtige Entwicklungszweige, aus denen die zu übersetzenden PO-Dateien kommen: "kde4 + kf5 stable" und "kde4 + kf5 trunk".

stable

ist der Entwicklungszweig, der die PO-Dateien zur jeweils stabilen Version von KDE enthält. Dazu gehören z. B. Plasma 5.3, Anwendungen 15.04 usw. Plasma basiert auf KF5, die Anwendungen auf KDE 4 bzw. KF5

trunk

ist der Entwicklungszweig, in dem für neue KDE-Versionen "experimentiert" und entwickelt wird. Aus dem, was die Entwickler in trunk verhackstückeln, wird irgendwann mal eine neue KDE-Version mit einer Hauptversionsnummer (z. B. Frameworks 5.x, Plasma 5.x, Anwendungen 15.08 usw.).

Wir verwenden bei der Übersetzung sogenannte Summit-Dateien, die vereinigte Dateien aus allen Entwicklungszweigen sind. Somit ist für Übersetzer erste einmal unerheblich, woher die Übersetzungen kommen. Einer der Koordinatoren verteilt die Übersetzungen aus den vereinigten Dateien regelmäßig auf die Entwicklungszweige.

Wo findet man die nötigen PO-Dateien?

Die PO-Dateien, also die zu übersetzenden Dateien von KDE, befinden sich auf dem Subversion-Server. Subversion ist ein Versionskontrollsystem, aus dessen Repository wir unsere Dateien beziehen können. Als Übersetzer muss man natürlich irgendwie an diese PO-Dateien vom Subversion-Server herankommen. Dazu bieten sich zwei Möglichkeiten an: WebSVN und der SVN-Client "svn".

Aber für wen ist nun welche Methode die beste? Kurz gesagt:

• Gelegenheitsübersetzer und Korrekturleser => WebSVN
• Dauerübersetzer und diejenigen, die viele Übersetzungen betreuen => SVN-Client

Im Folgenden wollen wir mal beide Methoden etwas genauer unter die Lupe nehmen:

WebSVN

Bei WebSVN handelt es sich um eine Webseite, mit deren Hilfe man auf Dateien des Subversion-Servers zugreifen kann. Diese Methode hat den großen Vorteil, dass man nur einen Web-Browser benötigt, um an die gewünschten Dateien zu kommen. Nachteil: Diese Methode wird schnell unübersichtlich und umständlich, wenn man es mit mehr als einer Handvoll Dateien zu tun bekommt.

SVN-Client

Das Kommandozeilenprogramm "svn" hat gegenüber dem WebSVN einen großen Vorteil: Man kann damit auch viele Dateien recht komfortabel handhaben (vor allem was das Aktualisieren angeht). Sobald du mehr als ein Dutzend Dateien zu übersetzen hast, wird die Handhabe mit WebSVN umständlich. Du wirst feststellen, dass du die heruntergeladenen Dateien hin und wieder auf den neuesten Stand bringen musst. Bei WebSVN bedeutet dies mühsame Handarbeit, weil jede Datei einzeln angeklickt und abgespeichert werden muss. Mit svn ist dies einfacher, weil du einen ganzen Ordner(baum) mit Dateien in einem Rutsch aktualisieren kannst.

Wo ist Bedarf?

Ob und wo wir Mithilfe benötigen, kannst Du leicht selbst herausfinden. Wir haben auf dem l10n-Server eine aktuelle Statistik für GUI (stable, trunk) und Doku (stable, trunk), aus der wir sehen können, welche Programme und Handbücher zu wieviel Prozent übersetzt sind.

Wenn man sich aus einer dieser Listen etwas Passendes herausgesucht hat, sollte man trotzdem noch einmal den Koordinator oder die Mailingliste fragen, ob das betreffende Programm auch wirklich noch frei ist (damit man nicht frustrierenderweise doppelte Arbeit macht).

Software

Gettext / Qt Localization

In KF5 wird Qt Localization (Dateinamen *_qt.po) und Gettext (Dateinamen *.po / json*po / desktop*po) verwendet. Für Übersetzer sehen alle Übersetzungskataloge wie im Gettext-System aus, die Umwandlung von Qt in Gettext und bei der Installation zurück erfolgt automatisch durch Skripte.

Lokalize

Nachdem man die nötigen PO-Dateien heruntergeladen hat, beginnt die Arbeit mit Lokalize, mit dem die PO-Dateien übersetzt werden.

Wenn Lokalize installiert ist, musst du nach dem ersten Start noch deine Benutzerdaten eintragen und ein Projekt erstellen. Das ist schnell erledigt und wird hier erklärt.

Arbeiten mit Lokalize

Navigation / Tastenkombinationen

Eine PO-Datei besteht üblicherweise aus vielen zu übersetzenden Nachrichten. Nach dem Laden einer PO-Datei zeigt Lokalize die erste Nachricht an. In der Statuszeile sieht man, dass aktuell Nachricht 1 angezeigt wird; daneben sieht man, wieviele Nachrichten die aktuelle PO-Datei enthält. Wenn die erste Nachricht übersetzt ist, musst Du die nächste anzeigen lassen. Dies geht mit der Taste "Bild runter". Zur vorherigen Nachricht geht es mit "Bild hoch".

Die wichtigsten Tastenkombinationen in Lokalize sind

• Bild hoch: Nächster Eintrag
• Bild auf: Vorheriger Eintrag
• Strg+Umschalt+Bild ab: Nächster fraglicher oder nicht übersetzter Eintrag
• Strg+Umschalt+Bild auf: Vorheriger fraglicher oder nicht übersetzter Eintrag
• Strg+U: Zeichenkette als fraglich (fuzzy) markieren oder freigeben

Status von Zeichenketten

fraglich (Text wird kursiv dargestellt)

Dies bezeichnet einen "fuzzy"-Eintrag. Hier muss kontrolliert werden, ob die deutsche Übersetzung noch zum englischen Originaltext passt. Der Programmentwickler oder Handbuchschreiber hat etwas am Originaltext geändert und die deutsche Übersetzung muss nun nachgezogen werden. Die Änderungen am Original sind manchmal sehr gering (manchmal ändert sich nur ein einziger Buchstabe) und daher schwer zu erkennen, man muss also sehr genau aufpassen! Die LED erlischt, sobald Du etwas in das Feld "Übersetzung" eingibst. Wenn keine Änderung nötig ist, kannst Du auch Strg+U drücken, um die LED von Hand auszuschalten. Achtung: Alle fuzzy-Einträge erscheinen im laufenden Programm unübersetzt. Daher sollte man die fuzzies nicht einfach unbekümmert "links liegen lassen".

nicht übersetzt (kein Text in Übersetzungsfeld)

Diese LED bedeutet, dass der gerade angezeigte Eintrag noch unübersetzt ist. Sie erlischt, sobald Du etwas in das Übersetzungsfeld einträgst.

Sonderzeichen und geschützte Zeichen

Während der Übersetzung wirst Du hier und da auf Zeichen mit einer besonderen Bedeutung stoßen:

Die Bedeutung und der richtige Umgang soll im Folgenden etwas näher erläutert werden:

& - Et-Zeichen

Das Et-Zeichen wird in Programmoberflächen verwendet, um den Buchstaben für einen Kurzbefehl zu markieren. Ein Menü mit dem Namen "&Datei" erscheint in der Oberfläche so: "Datei". Der auf das & folgende Buchstabe wird also unterstrichen und kann später im Programm als Kurzbefehl mit Alt+<Buchstabe> aufgerufen werden. Das & muss nicht am Wortanfang stehen, auch folgendes ist möglich: "E&xtras" -> Extras, "Speichern &unter ..." -> Speichern unter ...

Wenn in der Programmoberfläche tatsächlich das Zeichen & sichtbar sein soll, muss man es in der Übersetzung doppelt schreiben: "Thomas && Stephan" -> Thomas & Stephan

\n - Zeilenumbruch

Dies ist zumeist das Zeichen für den Zeilenumbruch. Wenn man in Lokalize durch Drücken der Eingabetaste Leerzeilen erzeugt, sind diese normalerweise in der Programmoberfläche unsichtbar. Um sichtbare Zeilenumbrüche zu erzeugen, wird oft dieses Zeichen verwendet. Man kann es aber nicht wahllos an allen Stellen einsetzen, daher muss man im laufenden Programm gründlich prüfen, ob der gewünschte Effekt tatsächlich erziehlt wird. Mann kann das Zeichen entweder von Hand oder mittels Umschalt-Eingabetaste eingeben. Hinweis: In der Regel ist es besser, man überlässt den Zeilenumbruch dem Programm und gibt ihn nicht vor!

%1 - Argument Nr. 1

Dieses Zeichen wird im laufenden Programm durch das Argument 1 des i18n()-Aufrufs im Quelltext ersetzt. Im Original könnte z. B. "Opening file %1 ..." stehen. Die deutsche Übersetzung lautet dann "Datei %1 wird geöffnet ...", im laufenden Programm ist das %1 nicht mehr sichtbar, sondern wird durch etwas sinnvolles ersetzt: "Datei irgendwas.txt wird geöffnet ...". Wenn es mehrere Argumente gibt, werden diese der Reihe nach durchnummeriert: %1, %2, %3 usw. Die Reihenfolge in der Übersetzung ist egal, folgende Umsortierung der Argumente ist also möglich:

Original: "Failed to open file %1. The error was: %2"

Übersetzung: "Der Fehler %2 ist aufgetreten, daher lässt sich die Datei %1 nicht öffnen."

" - Anführungszeichen

Das Anführungszeichen ist ein Gettext-spezifisches Sonderzeichen. Wenn man in der Übersetzung ein Anführungszeichen schreiben möchte, so muss dieses maskiert (entschärft) werden. Ein Zeichen maskiert man, indem man einen linksgerichteten Schrägstrich davorsetzt: \"

Seit KDE 4 verwenden wir in normalem Fließtext keine englischen Anführungszeichen mehr, sondern die im Deutschen korrekten typografische Anführungszeichen „ und “. Wie diese auf der Tastatur eingegeben werden können, wird später noch erklärt.

Typografische Anführungszeichen („“) müssen nicht maskiert werden; die englischen (") allerdings schon! Vergisst man dies, so erhält man einen Syntaxfehler und der Eintrag wird als fehlerhaft markiert. Zum Glück unterstützt Lokalize dich und maskiert das Anführungszeichen bei der Eingabe über die Tastatur automatisch. Kopierst Du allerdings einen Text aus der Zwischenablage in die Übersetzung, so musst Du darin vorkommende Anführungszeichen selbst nachträglich maskieren!

Installation von KDE aus dem SVN

Es gibt im Netz ein paar nützliche Anleitungen und Hinweise zur Installation von KDE-Vorabversionen. Wenn Du Deine Übersetzung am laufenden Programm kontrollieren möchtest, solltest Du diese Anleitungen lesen:

TechBase - Build/KDE4

Dies ist der wichtigste Artikel! Er geht sehr intensiv auf die Installation von KDE 4 ein und wird regelmäßig aktualisiert. Der Artikel ist umfangreich, aber auch absolut lesenswert und hilfreich.

KF5

Hier wird die Benuzung von kdesrc-build empfohlen

Anpassen der Tastaturbelegung (für „“ und ‚‘)

Auf aktuellen Systemen können die deutschen typografischen Anführungszeichen über die Tastenkombinationen AltGr+V („), AltGr+B (“), Umschalt+AltGr+V (‚) sowie Umschalt+AltGr+B (‘) eingegeben werden.

In älteren X-Versionen sind im deutschen Tastaturlayout keine deutschen typografischen Anführungszeichen vorgesehen. Daher ist es mit einer Standard-Tastaturbelegung nicht möglich, diese Zeichen einzugeben. Im Folgenden werden zwei Lösungen vorgestellt, mit denen das Problem elegant umgangen werden kann. Danach kann man die typografischen Anführungszeichen über die Tastenkombinationen AltGr+A, AltGr+S, AltGr+D und AltGr+F erreichen. Lösung 1 ist ohne root-Zugriff und auf die Schnelle möglich, aber ein wenig umständlicher in der Handhabung. Sie ist geeignet, um X „mal eben schnell“ umzuschalten. Lösung 2 ist die Dauerlösung und wird bevorzugt, allerdings ist dazu root-Zugriff nötig. Außerdem muss man nach der Anpassung der Konfigurationsdateien den X-Server neu starten, damit die Änderungen wirksam werden.

Lösung 1: Temporäres Aktivieren der Tasten mit xmodmap

Das Konsolen-Programm xmodmap ermöglicht es, eine Tastaturbelegung in die laufende X-Sitzung zu importieren. Wenn X beendet wird, werden die Änderungen verworfen und bei der nächsten Anmeldung ist alles wie vorher. Das Vorgehen ist in wenigen Schritten erledigt und ganz einfach:

Vorbereitung

• Starte eine Konsole-Sitzung als normaler Benutzer
• Lege in Deinem persönlichen Ordner die Datei .xmodmaprc an mit folgendem Inhalt:

keycode  38 = a A U201E AE U201E AE
keycode  39 = s S U201C section U201C section
keycode  40 = d D U201A ETH U201A ETH
keycode  41 = f F U2018 ordfeminine U2018 ordfeminine

• Sichere die aktuelle Tastaturbelegung:

xmodmap -pke > ~/.xmodmap.orig

• Den folgenden Schritt musst du jedesmal ausführen, wenn du dich eingeloggt hast und typografische Anführungszeichen verwenden willst. Die Änderungen bleiben für die aktuelle X-Sitzung aktiv. Beim nächsten Einloggen müssen sie dann wieder durchgeführt werden:

xmodmap ~/.xmodmaprc

• Wenn man die Änderungen in der laufenden Sitzung wieder rückgängig machen möchte, geht das übrigens mit dem Befehl

xmodmap ~/.xmodmap.orig

Lösung 2: Eintragen der Konfiguration in die X keymap

Hierzu ist es nötig, eine Systemdatei zu verändern. Melde dich als root an der Konsole an und bearbeite die Datei /usr/share/X11/xkb/symbols/de. Je nach Linux-Distribution kann die Datei auch woanders liegen. Im Zweifel muss man mal die Suchfunktion von KDE bemühen. Die meisten deutschen Nutzer werden vermutlich in X11 die Tastaturvariante „nodeadkeys“ ausgewählt haben. Suche daher den Abschnitt xkb_symbols "nodeadkeys" und füge die folgenden Zeilen an:

key <AC01>  { [ a, A, U201E,          AE ] };
key <AC02>  { [ s, S, U201C,     section ] };
key <AC03>  { [ d, D, U201A,         ETH ] };
key <AC04>  { [ f, F, U2018, ordfeminine ] };

Inhaltliches

Einleitung

Dieser Teil des Handbuches beschäftigt sich mit den Besonderheiten, die mehr inhaltlicher und weniger technischer Natur sind. Hinweise zu Sonderzeichen finden sich hier.

Sprachstil

Neue Deutsche Rechtschreibung

In KDE wird seit Version 2.0 die Neue Deutsche Rechtschreibung in ihrer jeweils gültigen Form verwendet. Alle Übersetzer sollten sich daher mit ihr befassen (falls nicht eh schon geschehen). Natürlich muss niemand ein Rechtschreibgenie werden, aber eine weitgehend korrekte Rechtschreibung ist (nicht nur in KDE) wünschenswert.

Wenn Du Dir im konkreten Fall unsicher bist, kannst Du im Web nachschlagen oder auf unserer Mailingliste nachfragen. Eine interessante Anlaufstelle im Web ist: [2]

Außerdem solltest Du einen möglichst aktuellen Duden oder Wahrig griffbereit halten.

Stilrichtlinien

Zugunsten eines einheitlichen Sprachstils haben wir uns in KDE auf die folgenden einfachen Richtlinien geeinigt. Jede einzelne wird unter der Zusammenfassung noch etwas ausführlicher erläutert:

• unpersönliche Wendungen, keine Ich-Form (1. Person)
• Witze, Jargon und Umgangssprache vermeiden
• höflich siezen, nicht duzen
• Punkt statt Ausrufezeichen
• komplizierte Bindestrich-Konstrukte vermeiden
• kein Denglisch
• frei übersetzen und den ursprünglichen Sinn bewahren
• unmissverständliche Ausdrucksweise, Fachchinesisch vermeiden

unpersönliche Wendungen, keine Ich-Form (1. Person)

Programme, die ständig das Gespräch mit dem Benutzer zu suchen scheinen, werden allgemein als anstrengend empfunden. Deshalb sollten wir in unseren Übersetzungen vermeiden, das Programm in der Ich-Form zum Benutzer sprechen zu lassen.

• So Nicht: Ich lade die Datei ...
• So Nicht: Lade die Datei ...
• Sondern so: Die Datei wird geladen ...

Witze, Jargon und Umgangssprache vermeiden

Diese Sprachelemente gehören einfach nicht in eine professionelle Übersetzung wie die von KDE, es sei denn es handelt sich um ein Zitat bzw. wörtliche Rede. Diese kommen bei uns aber in der Regel nicht vor.

höflich siezen, nicht duzen

Der Benutzer wird grundsätzlich höflich gesiezt und "Sie" wird groß geschrieben. Die einzige Ausnahme bilden hier Programme und Handbücher für Kinder, hier ist Duzen erlaubt. Auch das "Du" schreiben wir groß.

Punkt statt Ausrufezeichen

Besonders im amerikanischen Englisch wird das Ausrufezeichen sehr gern verwendet. Im Deutschen reicht aber meistens einfach ein Punkt. Wenn doch mal ein Ausrufezeichen nötig ist, dann bitte nur eines und nicht gleich mehrere.

komplizierte Bindestrich-Konstrukte vermeiden

Bitte vermeide komplizierte Bindestrich-Konstrukte wie diese hier ;-)

Besser: komplizierte Konstrukte mit Bindestrichen vermeiden.

Im Deutschen werden sowieso schon viel zu viele Bindestriche verwendet. Das bedeutet aber nicht, dass wir notwendige (korrekte) Bindestriche einfach weglassen!

kein Denglisch

Wenn es für einen Begriff eine passende deutsche Übersetzung gibt, dann benutze sie. Statt downloaden schreiben wir herunterladen, der Button ist bei uns ein Knopf und die Settings sind bei uns die Einstellungen. Grundsätzlich sollen einfache und für jeden verständliche Wörter benutzt werden.

frei übersetzen und den ursprünglichen Sinn bewahren

Bitte vermeide stur wörtliche Übersetzungen. Selbst wenn man nicht den englischen Originalwortlaut kennt, wird eine wörtliche Übersetzung auffallen und in den meisten Fällen schlecht verständlich, schwer lesbar und aufgesetzt wirken. Ein wörtlich übersetzter Text hemmt fast immer den Lesefluss.

unmissverständliche Ausdrucksweise, Fachchinesisch vermeiden

Versuche bitte, den Sinn eines Textes immer so klar und unmissverständlich wie möglich auszudrücken. Wir versuchen so gut es geht, ohne Fach- bzw. Fremdwörter auszukommen.

Einheitlichkeit

In KDE werden überall die gleichen Abläufe und Bedienkonzepte verwendet. Der Benutzer wird darauf geschult, dass das, was in Programm A auf bestimmte Weise funktioniert, in Programm B ebenso geht. Diese Regel ist wichtiger Bestandteil der Einheitlichkeit einer integrierten Arbeitsumgebung wie KDE. Als ein mindestens genauso wichtiger Bestandteil passt die einheitliche Übersetzung in dieses Konzept.

Daher gilt: Bitte übersetze den gleichen Begriff innerhalb eines Programms nicht unterschiedlich, achte auf Einheitlichkeit. Dies gilt natürlich nicht nur für das zu übersetzende Programm, sondern für KDE im Ganzen. Behalte immer auch im Auge, wie ein Begriff im Rest von KDE verwendet und übersetzt wird. Um Dich mit der KDE-weiten Einheitlichkeit zu unterstützen, gibt es natürlich auch einige Hilfestellungen. Nutze sie:

1. Lies die oben beschriebenen Richtlinien und wende sie an
2. Halte Dich an die Standardübersetzungen

• Auf der Teamseite findest Du eine Tabelle mit Standardübersetzungen.
• Wenn sich ein fragliches Wort nicht in der Tabelle findet, ist die Datei kdelibs.po eine gute Referenz. Was dort steht, kann bedenkenlos als Übersetzung herhalten.
• Nutze die Mailingliste zur Begriffsdiskussion. Wenn wir uns dort auf eine Standardübersetzung einigen, wird sie in die Tabelle übernommen und ist verbindlich.

GUI-Übersetzung

Die Abläufe im Überblick

Wir wissen ja nun, dass wir unsere PO-Dateien von dem KDE-Server bekommen. Aber wie funktioniert nun eigentlich das Zusammenspiel zwischen uns Übersetzern, den Programmierern und den Automatismen auf dem KDE-Server?

Im Folgenden möchte ich dieses Zusammenwirken etwas näher erläutern.

Am Anfang der Kette stehen immer die Programmautoren. Diese bereiten ihre Programme zur Übersetzung vor. Dazu betten sie die englischen Original-Texte in eine i18n()-Funktion ein. Auf dem KDE-Server läuft nun regelmäßig ein Skript (auch liebevoll "Scripty" genannt), welches aus den Programmen diese übersetzbaren Texte herausfiltert und in den POT-Dateien unter l10n-kf5/templates speichert. Wir Übersetzer laden nun diese POT-Dateien herunter und erstellen daraus fertig übersetzte, sprachbezogene PO-Dateien, die wir dann unter l10n-kf5/de abspeichern.

Damit ist die Arbeit zunächst einmal erledigt, auf dem Server befindet sich nun eine funktionsfähige Übersetzung des Programms. Allerdings ändern die Programmierer von Zeit zu Zeit etwas an den Originaltexten im Programm. Müssen wir mit der Übersetzung nun von vorn beginnen? Also schauen wir uns an, was als nächstes geschieht:

Beim nächsten Lauf erzeugt Scripty aus den Programmen, wie zuvor auch, neue POT-Dateien, in denen die Änderungen der Programmierer enthalten sind. Nun folgt aber noch ein zweiter Schritt: Scripty vergleicht die neuen POT-Dateien mit unseren übersetzten PO-Dateien (die wir ja unter l10n-kf5/de gespeichert haben) und kopiert die Neuerungen aus den POTs in unsere POs. Damit liegt nun auf dem Server eine PO-Datei mit vielen fertigen Übesetzungen und ein paar wenigen fraglichen und neuen Nachrichten. Wir Übersetzer holen uns von nun an nicht mehr die POTs, sondern die von Scripty aktualisierten POs vom Server, übersetzen nur noch die Änderungen und speichern die PO-Datei erneut auf dem Server ab.

Wenn der Programmierer nun wieder Änderungen an seinem Programm vornimmt, geht die Prozedur wieder von vorne los: Scripty übernimmt die Änderungen in unsere PO-Dateien; wir übersetzen und speichern die Ergebnisse wieder zurück auf den Server.

{picture file=img/wiki_up//workflow-GUI.png}

Spezialfälle

Bei der Übersetzung von Programmoberflächen gibt es einige Spezialfälle, die es zu beachten gilt.

Das Sonderzeichen "&"

Das Et-Zeichen "&" markiert einen Kurzbefehl in einer Programmoberfläche. Eine genaue Erklärung dazu findet sich unter "Sonderzeichen und geschützte Zeichen" weiter oben.

Rich Text und Markup

Besonders in der "Was ist das?"-Hilfe erscheinen häufig Abschnitte mit Rich Text und Markup. Dies könnte z. B. so aussehen:

<qt>This button does simply <b>nothing</b>, it's just 
here to explain how <quote>Rich Text</quote> 
works :)</qt>

Rich Text ist im Grunde nichts weiter als formatierter Text. Die Formatierungen erreicht man durch sog. Markup. Im obigen Beispiel wird das Markup mit der Markierung <qt> eingeleitet und endet mit </qt>. Die meisten Markup-Elemente haben ein einleitendes und ein abschließendes Element. Wenn man sich mit Markup (HTML, XML usw.) nicht auskennt, sollte man in der Übersetzung nicht einfach beliebige Markierungen weglassen oder abändern. Sie müssen in der Regel in der korrekten Reihenfolge übernommen werden. Ein Fehler führt in Programmoberflächen meist zu Darstellungsfehlern im Text, Handbücher lassen sich mit einem solchen Fehler gar nicht erst kompilieren.

.desktop- und .json-Dateien

Desktop- und JSON-Dateien enthalten verschiedenste Formen von Einrichtungsinformationen. Bestimmte Teile dieser .desktop-/.json-Dateien können von uns übersetzt werden. Die Übersetzung einer .desktop-/.json-Datei muss aber eine bestimmte Syntax einhalten.

Die zu übersetzenden Einträge in einer Desktop- oder JSON-Datei haben den Kontext "Name=", "GenericName=" oder "Comment=" / "Description".

Nachrichten mit dem Kontext "Name" werden meistens nicht übersetzt wie z. B. "Dolphin", "Konqueror". Nachrichten mit dem Kontext "GenericName=" oder "Comment=" / "Description" sollten immer übersetzt werden.

Englische Wörter, obwohl alles zu 100% übersetzt ist?

Manchmal kann es vorkommen, dass im laufenden Programm englische Wörter auftauchen, obwohl man in Lokalize die gesamte Datei vollständig übersetzt hat. Dafür kann es zwei Gründe geben:

• a) Die Übersetzung ist veraltet. Dies kann vorkommen, wenn das Programm während Deiner Übersetzungsarbeit weiterentwickelt wurde und die Übersetzungen nun nicht mehr im Programm zugeordnet werden können. Die Lösung: Die Übersetzung wird auf den Server hochgeladen und dort von Scripty aktualisiert. Einen Tag später kann man sich die Übersetzung wieder herunterladen und die neuen Fuzzies übersetzen. Nun sollte alles funktionieren.
• b) Falls Lösung A nicht hilft, liegt möglicherweise ein Fehler im Programm vor. In selteneren Fällen kann es vorkommen, dass die Programmierer es vergessen haben, einige Texte im Programm für die Übersetzung vorzubereiten. In dem Fall hilft ein Hilferuf auf der Mailingliste oder direkt eine Meldung an den verantwortlichen Programmierer.

Installation der Übersetzungen

Bevor Du Deine fertige Übersetzung installierst oder zum Einspielen an den Koordinator sendest, solltest Du sie auf Syntaxfehler prüfen. Dies erreichst Du mit "msgfmt --statistics <datei.po> -o/dev/null". Wenn msgfmt keine Fehler findet, kannst Du Deine Übersetzung installieren. Der Installationsvorgang verläuft unterschiedlich, je nachdem, ob Du die PO-Dateien aus dem WebSVN heruntergeladen, oder den SVN-Client benutzt hast:

Installation (Fallbeispiel WebSVN)

Wenn Du die PO-Dateien aus dem WebSVN heruntergeladen hast, musst Du jede PO-Datei von Hand kompilieren und installieren. Dafür benötigst Du eine Shell (z. B. Konsole).

• Wechsele in den Ordner mit der PO-Datei:

cd ~/applications-l10n-de

• Kompiliere die PO-Datei in eine MO-Datei:

msgfmt kate.po -o kate.mo

• Kopiere die kompilierte Datei in den KDE-Ordner (dafür muss man als Systemverwalter angemeldet sein):

cp kate.mo $(kf5-config --prefix)/share/locale/de/LC_MESSAGES

(kf5-config --prefix sollte den Basispfad zur KDE-Installation ergeben. Dies könnte z. B. /usr sein.)

Nun ist die neue Übersetzung KDE-weit verfügbar. Das betreffende Programm (hier Kate) muss neu gestartet werden, damit die Übersetzung benutzt wird.

Installation (Fallbeispiel SVN-Client)

Die Installation kann wesentlich vereinfacht werden, wenn Du das ganze Übersetzer-Grundgerüst mit dem SVN-Client heruntergeladen hast. Siehe dazu den letzten Abschnitt unter "Wo findet man die benötigten PO-Dateien?".

• Die folgenden Anweisungen funktionieren nur, wenn Du die folgende Ordnerstruktur mit dem SVN-Client heruntergeladen hast:
  • l10n-kf5 (nur die Dateien, keine Unterordner)
  • l10n-kf5/de (inklusive Unterordner)
  • l10n-kf5/documentation (inklusive Unterordner)
  • l10n-kf5/scripts

• Wechsel in den Basisordner:

cd l10n-kf5

• Erstelle alle CMakeFile-Dateien:

./scripts/autogen.sh de

• Wechsel in den Ordner de:

cd de

• Erstelle den Build-Ordner und erzeuge alle Makefiles:

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=$(kde5-config --prefix) ../

• Wechsel in den Ordner für das entsprechende Modul:

cd messages/applications

• Kompiliere die PO-Dateien:

make

• Installiere die PO-Dateien:

su -c "make install"

Nun ist die neue Übersetzung KDE-weit verfügbar. Das betreffende Programm muss neu gestartet werden, damit die Übersetzung benutzt wird. Der Vorteil dieser Methode ist, dass man in einem Rutsch einen ganzen Ordner mit Übersetzungen installieren kann.

Wohin mit den fertigen Dateien?

Gut, Du bist also fertig, hast Deine eigenen Übersetzungen noch einmal formal überprüft und im laufenden Programm getestet?! Dann solltest Du sie nun am besten in ein tar.gz-Archiv verpacken und per E-Mail an den Team-Koordinator schicken. Ein paar Dinge solltest Du in der E-Mail erwähnen:

• Wohin gehören die Übersetzungen (stable/trunk) und in welches Modul? (kdebase, kdegames ...)
• Sind ganz neue Übersetzungen dabei, die es vorher noch nicht in KDE gab?
• Gibt es irgendetwas besonderes zu beachten?

Beispiel für so eine Mail:

Betreff: /trunk/l10n-kf5/de/messages/kdegames

Inhalt: Hier wieder etwas zum Einspielen. Es sind auch
ein paar ganz neue Dateien dabei, bitte beim Einspielen
nicht übersehen! Bitte schau dir mal xyz.po an, die
Fuzzies sind mir nicht ganz klar. Danke.

Der Koordinator wird Deine Übersetzungen noch einmal auf bestimmte Konflikte überprüfen und von Zeit zu Zeit gegenlesen. Wenn Deine Übersetzungen eingespielt wurden, erhälst Du eine Nachricht. Ab da ist Deine Übersetzung Teil von KDE und wird als solche auf zehntausende von Rechnern übertragen und bestimmt den Eindruck mit, den die Leute draußen von dem Ganzen haben. Das sollte man sich hier und da mal klar machen.

Doku-Übersetzung

Die Abläufe im Überblick

Die Abläufe für die Doku sind denen der GUI ähnlich; jedoch gibt es ein paar grundlegende Unterschiede.

Zunächst gibt es da einmal die Doku-Autoren, die die Handbücher in englischer Sprache verfassen. Sie verwenden dafür die Markup-Sprache Docbook/XML. Handbücher in dieser Form zu übersetzen wäre sehr umständlich, daher wird täglich ein Skript ausgeführt, welches aus den Docbook-Dateien die für Lokalize lesbaren POT-Dateien erzeugt und auf dem Server unter l10n-kf5/templates/docmessages speichert. Wie bei der GUI auch holen wir Übersetzer uns diese POT-Dateien und übersetzen sie in deutsche PO-Dateien, die wir dann wiederum unter l10n-kf5/de/docmessages abspeichern. Die Bildschirmfotos in den Handbüchern nehmen eine Sonderrolle ein, auf die ich später noch eingehen werde.

Der Doku-Koordinator erzeugt nun aus den neuen PO-Dateien wieder Docbook-Dateien (dazu benutzt er das Skript "update_xml") und speichert diese auf dem Server unter .../l10n-kf5/de/docs/.

Damit ist die Doku-Übersetzung zunächst einmal erledigt, auf dem Server befinden sich nun Handbücher in deutscher Sprache. Jedoch: Von Zeit zu Zeit ändern sich natürlich die Programme und die Doku-Autoren müssen die englischen Handbücher anpassen. Wie wir bereits aus der GUI wissen, müssen wir nun natürlich nicht das ganze Handbuch erneut übersetzen:

Die Änderungen in den englischen Original-Docbooks finden sich bald in den POT-Dateien unter l10n-kf5/templates/docmessages wieder. Das täglich laufende Skript "Scripty" vergleicht die neu erstellten POT-Dateien mit unseren übersetzten PO-Dateien (die wir ja unter l10n-kkf5/de/docmessages gespeichert haben) und fügt die Unterschiede an den richtigen Stellen ein. Damit liegt nun auf dem Server eine PO-Datei mit vielen fertigen Übersetzungen und ein paar wenigen fraglichen und neuen Nachrichten. Wir Übersetzer holen uns nun also nicht mehr die POTs, sondern die von Scripty aktualisierten POs vom Server, übersetzen die Änderungen und speichern die PO-Datei erneut auf dem Server ab. Der Doku-Koordinator erzeugt wieder die Docbooks und fertig ist die aktualisierte Doku-Übersetzung.

Finden erneut Änderungen an der Original-Doku statt, geht die Prozedur wieder von vorne los: Scripty übernimmt die Änderungen in unsere PO-Dateien, wir übersetzen und speichern die Ergebnisse wieder zurück auf den Server.

{picture file=img/wiki_up//workflow-DOKU.png}

Spezialfälle

Bei der Übersetzung von Handbüchern muss man viele Spezialfälle beachten.

Entities

Entities sind spezielle Platzhalter, die nur in der Dokumentation vorkommen. Sie beginnen mit & und enden mit einem Semikolon. Eine Liste der verfügbaren systemweiten Entities findet sich hier und der in deutsch übersetzten hier.

&i18n-foo; sind übersetzbare Entities, die im Header der Docbook-Datei definiert werden. &i18n-foo; erscheint als eigenene Nachricht im Katalog und wird dort einmal übersetzt. Dann wird diese Übersetzung in allen Vorkommen von &i18n-foo; bei der Generierung der Doku verwendet.

CREDIT_FOR_TRANSLATORS / ROLES_OF_TRANSLATORS

CREDIT_FOR_TRANSLATORS: Ersetzen durch: <othercredit role="translator"> <firstname>Vorname</firstname> <surname>Nachname</surname> <affiliation> <address><email>E-Mail-Adresse</email></ address> </affiliation> <contrib>Übersetzung</contrib></othercredit>

ROLES_OF_TRANSLATORS: Ersetzen durch: <para>Übersetzung Vorname Nachname <email>E-Mail-Adresse</email></para>

&underFDL; &underGPL;

Diese Entities werden nur kopiert und nicht übersetzt. Sie werden in der generierten Doku durch Verknüpfungen auf die Lizenzen ersetzt.

Technischer Hintergrund

XML

• Erläuterung zur Extensible Markup Language
• Tags / Markup
• Vorteile von XML
• Docbook-XML
• Benötigte Programme: meinproc, libxml2, po2xml (eventuell zu den technischen Voraussetzungen?)

Bildschirmphotos

• Spectacle
• Richtlinien
• Wo müssen deutsche Bildschirmfotos gespeichert werden?
• das PNG-Format
• Woher weiß ich, welche png-Dateien ich erstellen muss?

Installation der Übersetzung

• Prüfen der XML-Struktur mit checkXML5
• Interpretieren und Beheben von Fehlern
• Installation mittels update_xml und make

Tutorial

• Ein Beispieldurchlauf vom Anfang bis Ende

Korrekturlesen

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.

Abläufe

• Die groben Abläufe des Korrekturlesens im Überblick
• Was muss korrekturgelesen werden? => Tabelle im Wiki
• Eintragen des Datums im Wiki

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.