Evaluation von Pology

Panagiotis Papadopoulos pano_90 at gmx.net
Sun Jul 11 13:37:47 CEST 2010


Am Montag 05 Juli 2010, 17:26:36 schrieb Frederik Schwarzer:
> Moin,
> 
> immer mal wieder wird der Ruf nach der Verwendung von Pology
> laut. Ich möchte diesen Thread nutzen, um zu klären, ob und
> inwiefern Pology für unsere Arbeitsweise von Nutzen sein kann.
> 
> Zuerst muss dafür geklärt sein, _was_ Pology ist und _wie_ es
> in unseren Arbeitsablauf integriert werden könnte. Kann dazu
> jemand, der sich mit Pology bereits auseinandergesetzt hat,
> ein paar Sätze schreiben?

Ich hab mich da mal ein bisschen schlau gemacht:

Erstmal müssen wir die Begriffe Pology und PO Summit unterscheiden.

„Pology is a Python framework for custom processing of PO files.“ [1]
Beispiele für solche Pology-Werkzeuge sind poediff (ein Diff-Programm, das auf po-Dateien zugeschnitten ist und das ich in unserem IRC-Kanal schon angepriesen habe ;-)), posieve, was sogenannte „sieves“ ausführen kann (das sind verschiedene Skripte, z. B. gibt es ein Skript zum Durchführen von Rechtschreibprüfungen) und auch posummit, was das Werkzeug ist, mit dem der 

PO Summit ist eine alternatives System zum Umgang mit den verschiedenen SVN-Zweigen, wofür es einige Werkzeuge aus Pology verwendet (hauptsächlich „posummit“).
Es schafft (aus Sicht der Übersetzer) die zwei Zweige (Stable und Trunk) ab und ersetzt diese durch einen einzigen Zweig namens „Summit“. In diesem Zweig befinden sich dann po-Dateien, die Strings aus Trunk und Stable enthalten. Um die Strings später wieder auseinander halten zu können markiert es die Strings mit einem zusätzlichen Kommentar:

#. +> trunk
#: kdeui/jobs/kwidgetjobtracker.cpp:469
msgctxt "The destination url of a job"
msgid "Destination:"
msgstr ""
⁠
#. +> stable
#: kdeui/jobs/kwidgetjobtracker.cpp:469
msgid "Destination:"
msgstr ""
⁠
#. +> trunk stable
#: kdeui/jobs/kwidgetjobtracker.cpp:517
msgid "&Keep this window open after transfer is complete"
msgstr ""

Die ersten Zwei sind Strings, die nur in Trunk bzw. Stable vorkommt, während das letzte in Trunk und Stable vorkommt.
Nach getaner Arbeit müssen die Änderungen dann in die eigentlichen Zweige (Stable/Trunk) eingespielt werden. Dies erledigt dann der „Language Coordinator“ mit dem posummit-Werkzeug. Die Übersetzer müssen sich keine Gedanken mehr über Die einzelnen Zweige machen.


> 
> Danach müssen wir Vor- und Nachteile sammeln und schauen, ob
> der weitere Overhead (Stichwort: Einstiegshürde) vertretbar ist.
> 

Da die po-Dateien im Summit-Zweig weiterhin ganz normale po-Dateien bleiben, können sie auch weiterhin so bearbeitet werden wie bisher (Lokalize, vim, was-auch-immer). MMn ist die einzige Hürde die es gibt den Leuten zu erklären, dass Sie die po-Dateien nun aus dem Summit-Zweig holen sollen und nicht direkt aus Trunk/Stable.
 

Ich werde die Tage mal testweise (lokal) nach dieser Anleitung [2] einen Summit-Zweig/Ordner erstellen…

Grüße

[1] http://techbase.kde.org/Localization/Tools/Pology


More information about the kde-i18n-de mailing list