Hallo Helge, Am 12.11.2014 um 19:55 schrieb Helge Kreutzmann: > Hallo Mario, > On Tue, Nov 11, 2014 at 09:05:45PM +0100, Mario Blättermann wrote: >>>> Es ist wieder eine der Übersetzungen, die bei mir auf Halde liegen und >>>> eigentlich ihren Platz in den Upstream-Projekten finden sollten. Doch leider >>>> sind die Maintainer meist wenig kollaborativ und erwarten für die >>>> Implementierung von po4a in ihren Projekten fertige Patches, die sie nur noch >>>> nachschauen und anwenden müssen. Mir fehlt das Know-How dazu, also ist >>>> manpages-de (vorläufig oder auch dauerhaft, wer weiß) der bessere Platz. >>> >>> Da ich das schon bei mehreren Programmen (allerdings meistens Spiele) >>> durchexerziert habe, schick mir doch mal eine Liste der in Frage >>> kommenden Programme (d.h. wo Du genau so eine Aussage hast, dass der >>> Betreuer fertige Patches auch einspielen würde). Dann kann ich mir die >>> mal anschauen und Patches bauen (geht allerdings nicht über Nacht). >>> Die Liste ist recht übersichtlich, denn konkret verwertbare Zusagen habe ich nur für recutils [1], exif [2] und nano [3]. Es sind nicht unbedingt direkte Zusagen, einen Patch einbauen zu wollen, so es denn einen gäbe, aber zumindest wurde hinreichendes Interesse signalisiert. Die recutils verwenden help2man, das müsste nur dafür fit gemacht werden, beim Bau des Release-Tarballs neben den englischen auch die übersetzten Handbuchseiten (mit dem Schalter -L) zu generieren. Das funktioniert übrigens für alle Sprachen, für die es po-Dateien für sowohl recutils als auch help2man gibt, und würde auf einen Schlag eine wahre Schwemme an lokalisierten Dokumentationen erzeugen. Für exif ist es klar, die po-Datei haben wir, es geht nur um den Einbau von po4a in die Autotools des Projekts. Gleiches gilt für nano, dafür habe ich aber die Übersetzungen noch nicht fertig. Hinzu kämen noch die vorbis-tools, aber da mache ich mir wenig Hoffung, dass uns ein Patch in einem annehmbaren Zeitrahmen weiter bringen würde. Der Maintainer hat es in vier Jahren nicht einmal geschafft, wenigstens ein Bugfix-Release mit den letzten UI-Übersetzungen herauszubringen. Eigentlich ein Kampf gegen Windmühlen, nutzloser Aufwand. Weiterhin hatte ich bei cryptsetup angefragt und zunächst eine positive Antwort bekommen [4]. Aber dort hat man Angst davor, dass die Übersetzung fehlerhaft sein könnte [5]. Ein Sonderfall ist parted. Dort gibt es po4a schon, es funktioniert aber nicht. Vor dem letzten Release wurde es nur notdürftig repariert, weil es sonst den Buildvorgang gestört hätte [6]. Wirklich in Ordnung gebracht wurde es nicht, die letzte Version enthält wiederum nicht die portugiesischen Handbuchseiten, die es im Git schon seit 2006 gibt. >> Meinst du die Integration in die Upstream-Versionsverwaltung oder in das >> jeweilige Debian-Paket? Letzteres möchte ich nur ungern unterstützen, ein >> debianischer Alleingang ist nicht in meinem Interesse. Wenn schon, dann möchte >> ich alle Distributionen bedienen. > > Klar, das verstehe ich. Leider klappt manchmal nur die »kleine« > Variante (z.B. bei sgt-puzzles). Prinzipiell ist Upstream immer die > Wahl. Aber das ist auch nur ein Angebot ohne Garantie, ich kann es > halt nur versuchen. > >> Ich habe selbst schon ein Skript geschrieben, das aus vorhandenen Groff-Dateien >> mit po4a eine pot-Datei baut, aus einem Übersetzungspool wie ... > > Das macht doch po4a selbst? (Ich habe ja die Handbuchseite übersetzt > und es auch schon gemacht ...) > Ja schon, das Skript war dafür gedacht, den Maintainern die Schritte zu zeigen, um die übersetzten Dateien auch in der richtigen Verzeichnisstruktur zu erzeugen. Im Anhang findest du zwei Beispiele für vorbis-tools: Das erste Skript baut die pot-Vorlage, das zweite zieht die Dateien aus einem imaginären TP-Modul und baut die übersetzten Handbuchseiten. Es sind nur Machbarkeitsstudien, sicherlich noch verbesserungswürdig. Man könnte aber vielleicht die Skripte so ausbauen, dass sie nur irgendwie in »make« aufgerufen werden müssen, ist nur so eine Idee. > Nun ja, po4a hat ja viele Eingabefilter, so dass das Ursprungsformat, > so es denn unterstützt wird, relativ egal ist. > Es sei denn, es kommt help2man zum Einsatz, dann wäre es sinnlos, po4a zu verwenden. Und po4a kann auch nicht alles, RestructuredTxt zum Beispiel, das wird im Yum-Nachfolger DNF genutzt. Es gibt einen Patch dafür, der schon über ein Jahr alt ist, aber keiner ist bereit, ihn einzubauen [7]. [1] http://lists.gnu.org/archive/html/bug-recutils/2014-01/msg00002.html [2] http://sourceforge.net/p/libexif/mailman/message/32246938/ [3] http://lists.gnu.org/archive/html/nano-devel/2014-07/msg00050.html [4] http://www.saout.de/pipermail/dm-crypt/2014-March/004032.html [5] http://www.saout.de/pipermail/dm-crypt/2014-March/004035.html [6] http://lists.alioth.debian.org/pipermail/parted-devel/2014-June/004534.html [7] http://lists.alioth.debian.org/pipermail/po4a-devel/2014-May/002245.html Gruß Mario
Attachment:
create-man-pot.sh
Description: application/shellscript
Attachment:
translate-man.sh
Description: application/shellscript