KDE Localization/de/TeamHowto: Difference between revisions

Revision as of 17:38, 15 October 2016

Einführung

Jedes Team hat seine eigenen Strukturen und Arbeitsweisen. Neben der Einarbeitung in die Technologien, die für die Mitarbeit notwendig sind, ist das Zurechtfinden im Team die größte Hürde, die ein potenzieller Helfer zu nehmen hat.

Diese Seite soll die verschiedenen Arbeitsweisen in unserem Team beschreiben und Beitragenden die Möglichkeit geben, sich ein Bild von den einzelnen zu erledigenden Aufgaben zu machen.

Aufgaben

Allgemeine Hinweise:

Um sich bei der Übersetzung an der bisherigen Wortwahl orientieren zu können, ist es ratsam, Lokalize richtig einzurichten. Die Übersetzungsdatenbank kann so häufig vorkommende Wörter und Phrasen vorschlagen.
Nur die Koordinatoren und einer Anwendung oder einem Modul fest zugewiesene Übersetzer arbeiten ohne Vorankündigung. Alle anderen kündigen ihr Vorhaben auf der Liste an. So wird doppelte Arbeit und das Bearbeiten veralteter Dateien verhindert.

Übersetzen der GUI

Wer GUI-Nachrichten übersetzt, arbeitet mit den PO-Dateien unter

Korrekturlesen der GUI

Wie?

Korrekturlesen gibt es in vielen Ausprägungen.

grep (erfordert Erfahrung und viel Handarbeit :))
PO-Dateien sytematisch durchgehen
die Anwendung starten und duch die Menüs und Dialoge klicken

Die letztgenannte Herangehensweise ist die einfachste und kann ohne weitere Vorbereitungen unternommen werden. Dabei ist lediglich darauf zu achten, dass die Version, die man betrachten möchte, so neu wie möglich ist.

Worauf achten?

Die Liste der Dinge, auf die zu achten ist, ist lang und kann hier nur ansatzweise aufgeführt werden.

Rechtschreib- und Grammatikfehler: Das ist für uns die neue Rechtschreibung. Referenzen sind beispielsweise Duden, Wahrig, Wikipedia, Google usw.
Unübersetzte Wörter und Phrasen: Es gibt verschiedene Ursachen für unübersetzte Wörter und Phrasen in der GUI. Behoben werden müssen alle.
Unklare und falsche Übersetzungen: Manchmal kommt es vor, dass man in der PO-Datei ein Wort korrekt übersetzt, im Kontext der Anwendung aber eine andere Übersetzung passender wäre oder die gewählte Übersetzung schlicht falsch ist. Beispiel aus der Praxis: "Drücken Sie Weltraum, um fortzufahren"
Falsch gesetzter Satzpunkt: Menüeinträge, Optionen-Labels in Dialogen, Knopfbeschriftungen, Fenstertitel ... Es gibt viele Texte, die in keinem Fall einen Satzpunkt tragen sollten.
Fehlender Doppelpunkt an Labels vor Konfigurationsoptionen: Steht das Label an einer Option vor dem dazugehörigen Schaltelement, muss der Text mit einem Doppelpunkt abgeschlossen werden.

Übersetzen der Doku

Wer Doku-Nachrichten übersetzt, arbeitet mit den PO-Dateien unter

Korrekturlesen der Doku

Wie?

Auch die Doku kann man mit grep oder systematisch in den PO-Dateien korrekturlesen. Aber auch hier ist es sinnvoller, die fertig generierte Doku im Web-Browser zu lesen. Dabei gibt es sogar noch weniger zu beachten, als beim Korrekturlesen der GUI. :) Unter

https://docs.kde.org/index.php?application=&package=&language=de

kann man sich die gewünschte Doku aufrufen und sie im Web-Browser oder im PDF-Format lesen.

Worauf achten?

Aktualität von Bildschirmfotos: Stellt ein Bildschirmfoto nicht mehr den aktuellen Stand der Anwendung dar oder stimmen Texte im Bild nicht mit den Texten in der Beschreibung überein, muss das Bildschirmfoto erneuert werden.

Wie kommt die Übersetzung rein?

svn diff l10n-kf5/de >/tmp/foo.diff
svn.reviewboard.kde.org -> New Review Request -> Repository kde auswählen -> Select drücken -> /tmp/fooe.diff auswählen -> Basisordner für Diff eingeben z. B. trunk oder branches/stable, wenn der Diff in l10-kf5 oder l10n-kde4 generiert wurde. Eintrag als Basisordner + Pfad im Diff muss immer den vollständigen Pfad in SVN ergeben, z.B. trunk/l10-kf5/[doc]messages/modul/foo.po
Als Reviewer die Gruppe: kde-i18n-de einstellen
Falls keine eigenen SVN-Commit-Rechte, dies in Description anmerken
Wenn "Ship it" erhalten und Inhaber von SVN-Commit-Rechten, patch selbst einspielen, Commit-Nachricht kann simples "Translation update" sein, falls nichts außergewöhnliches getan. Ansonsten bzw Summary + eventuell Description benutzen.
Review-Request nach Commit manuell schließen, derzeit kein Commit-Keyword verfügbar

@@ Line 55: / Line 55: @@
 ==Wie kommt die Übersetzung rein?==
-* svn diff l10n-kf5/de >/tmp/de.diff
+* svn diff l10n-kf5/de >/tmp/foo.diff
-* svn.reviewboard.kde.org -> New Review Request -> Repository kde auswählen -> Select drücken -> /tmp/de.diff auswählen -> Basisordner für Diff eingeben z. B. trunk oder branches/stable
+* svn.reviewboard.kde.org -> New Review Request -> Repository kde auswählen -> Select drücken -> /tmp/fooe.diff auswählen -> Basisordner für Diff eingeben z. B. trunk oder branches/stable, wenn der Diff in l10-kf5 oder l10n-kde4 generiert wurde. Eintrag als Basisordner + Pfad im Diff muss immer den vollständigen Pfad in SVN ergeben, z.B. trunk/l10-kf5/[doc]messages/modul/foo.po
 * Als Reviewer die Gruppe:	kde-i18n-de einstellen
 * Falls keine eigenen SVN-Commit-Rechte, dies in Description anmerken
-* Wenn "Ship it" erhalten und Inhaber von SVN-Commit-Rechten, patch selbst einspielen, Commit-Nachricht kann simples "Translation update" sein, falls nichts außergewöhnliches getan
+* Wenn "Ship it" erhalten und Inhaber von SVN-Commit-Rechten, patch selbst einspielen, Commit-Nachricht kann simples "Translation update" sein, falls nichts außergewöhnliches getan. Ansonsten bzw Summary + eventuell Description benutzen.
 * Review-Request nach Commit manuell schließen, derzeit kein Commit-Keyword verfügbar