eigentlich war manpages-l10n für mich lange Zeit eine eher
behelfsmäßige Lösung zum Verteilen übersetzter Handbuchseiten. Ich
habe etliche Projekte dazu bewegen können, diese Übersetzungen
upstream zu verwalten und auszuliefern. Aber irgendwann ging mir die
Luft aus. Don Quichottes Kampf gegen die Windmühlen … Es dauerte oft
ewig, bis so ein Umzug endgültig vollzogen war (zum Beispiel bei
procps: sechs Jahre).
Der Aufwand für so etwas ist mir zu groß, wenngleich manpages-l10n
doch immer noch nur der zweitbeste Lösungsansatz ist. Für util-linux
habe ich letztes Jahr das gesamte Portfolio an über hundert
Handbuchseiten von Groff auf Asciidoctor portiert, zwar
halbautomatisch mit Pandoc, aber viel manuellem Nachpolieren, um dafür
im Gegenzug die Zusage zu erhalten, dass die
Handbuchseitenübersetzungen fortan upstream verwaltet werden. Die endgültige standardmäßige Aktivierung des Baus der übersetzten
Versionen im Buildsystem lässt immer noch auf sich warten, obwohl
alles fertig ist und funktioniert; vermutlich wird das nie passieren.
Es wäre noch zu früh, wird mir immer wieder geantwortet … Nun ja, den Rückzug kann ich zwar nicht mehr antreten, aber ich habe mich
entschlossen, solche Vorschläge in Zukunft bleiben zu lassen. Hatte
ich zwar schon mal gesagt und dann der Verlockung wieder nachgegeben,
aber nun ist endgültig Schluss.
Deshalb werde ich nun hier wieder aktiv neue Übersetzungen einbringen.
Die Vorlage für mutt(1) wird in der nächsten Version wieder
aktualisierbar sein [1]. Da passt mir doch muttrc(5) ganz gut ins
Konzept, zumal wir die anderen Mutt-Handbuchseiten schon auf deutsch
haben. Allerdings ist das ein Projekt, das angesichts von 1807 Gettext-Meldungen in der .po-Datei eine Weile braucht; es werden
wenigstens ein paar Monate, vielleicht ein Jahr, mal sehen. Aber es
reizt mich doch, weil Po4a die Quelldatei lange Zeit mit zahlreichen Fehlermeldungen abgewiesen hat, aber jetzt problemlos baut. Nur nicht
für Opensuse Leap, aber das kann mir egal sein.
Nun bleibt noch zu hoffen, dass sich für die voraussichtlich 40~50
Teile dann auch ein Korrekturleser findet ;)
Hallo Mario,
On Mon, Mar 21, 2022 at 06:00:03PM +0100, Mario Blättermann wrote:
eigentlich war manpages-l10n für mich lange Zeit eine eher
behelfsmäßige Lösung zum Verteilen übersetzter Handbuchseiten. Ich
habe etliche Projekte dazu bewegen können, diese Übersetzungen
upstream zu verwalten und auszuliefern. Aber irgendwann ging mir die
Luft aus. Don Quichottes Kampf gegen die Windmühlen … Es dauerte oft ewig, bis so ein Umzug endgültig vollzogen war (zum Beispiel bei
procps: sechs Jahre).
Der Aufwand für so etwas ist mir zu groß, wenngleich manpages-l10n
doch immer noch nur der zweitbeste Lösungsansatz ist. Für util-linux
habe ich letztes Jahr das gesamte Portfolio an über hundert
Handbuchseiten von Groff auf Asciidoctor portiert, zwar
halbautomatisch mit Pandoc, aber viel manuellem Nachpolieren, um dafür
im Gegenzug die Zusage zu erhalten, dass die
Handbuchseitenübersetzungen fortan upstream verwaltet werden. Die endgültige standardmäßige Aktivierung des Baus der übersetzten Versionen im Buildsystem lässt immer noch auf sich warten, obwohl
alles fertig ist und funktioniert; vermutlich wird das nie passieren.
Es wäre noch zu früh, wird mir immer wieder geantwortet … Nun ja, den Rückzug kann ich zwar nicht mehr antreten, aber ich habe mich entschlossen, solche Vorschläge in Zukunft bleiben zu lassen. Hatte
ich zwar schon mal gesagt und dann der Verlockung wieder nachgegeben,
aber nun ist endgültig Schluss.
Hoffentlich kannst Du hier noch dranbleiben, wäre echt schade, wenn
die in den Orkus fallen.
Ich habe noch drei Projekte in der lokalen Warteschlange, die ich
ansprechen wollte und gehofft hatte, das mit Dir machen zu können,
aber den Frust kann ich verstehen.
Und bei System-V-Init warte ich auch noch drauf, dass die PO-Dateien auftauchen …
Deshalb werde ich nun hier wieder aktiv neue Übersetzungen einbringen.
Die Vorlage für mutt(1) wird in der nächsten Version wieder aktualisierbar sein [1]. Da passt mir doch muttrc(5) ganz gut ins
Konzept, zumal wir die anderen Mutt-Handbuchseiten schon auf deutsch
haben. Allerdings ist das ein Projekt, das angesichts von 1807 Gettext-Meldungen in der .po-Datei eine Weile braucht; es werden
wenigstens ein paar Monate, vielleicht ein Jahr, mal sehen. Aber es
reizt mich doch, weil Po4a die Quelldatei lange Zeit mit zahlreichen Fehlermeldungen abgewiesen hat, aber jetzt problemlos baut. Nur nicht
für Opensuse Leap, aber das kann mir egal sein.
Nun bleibt noch zu hoffen, dass sich für die voraussichtlich 40~50
Teile dann auch ein Korrekturleser findet ;)
Nun ja, da ich mutt nutze, kann ich vielleicht noch den ein- oder
anderen Tipp abstauben, sprich Sachen lernen, nach denen ich noch nie
gesucht hatte.
(Und wir haben die PO-Übersetzung ja auch in Sync gebracht, da ist
dann die Übersetzung mal aus einem Guß).
Und Du liest ja auch meine drögsten (Systemd-)Handbuchseiten QS …
Am Mo., 21. März 2022 um 20:53 Uhr schrieb Helge Kreutzmann <debian@helgefjell.de>:
Hoffentlich kannst Du hier noch dranbleiben, wäre echt schade, wenn
die in den Orkus fallen.
Verschwinden werden die nicht - ich bleibe natürlich dran. Solange der
Bau der übersetzten Handbuchseiten aber nicht per Vorgabe in
util-linux aktiviert ist, wird das sowieso kein Paketbetreuer von sich
aus explizit aktivieren. So lange bleiben die Übersetzungen sowieso
bei uns. Für Fedora wird Karel Zak und separates RPM-Paket mit den übersetzten Handbuchseiten bauen; wenn das da ist nehme ich util-linux
aus unseren Fedora-Paketlisten raus. Aber ich denke, er hat mit diesem Extrapaket keine Eile.
Ich habe noch drei Projekte in der lokalen Warteschlange, die ich ansprechen wollte und gehofft hatte, das mit Dir machen zu können,
aber den Frust kann ich verstehen.
Es ist einfach zu aufwändig. Die Geschichte mit util-linux ist das mit Abstand arbeitsintensivste, was ich je in der Richtung gemacht habe.
Klar, Karel Zak ist seinen Groff-Code los, dessen Wurzeln oft
Jahrzehnte zurückreichten und freut sich über das wesentlich besser handhabbare Asciidoctor-Format. Aber die Handbuchseitenübersetzungen
werden nicht aktiviert, obwohl das der einzig mögliche Weg ist, allen Paketbetreuern auf einen Schlag klar zu machen, dass das jetzt ein
Standard ist. Alles funktioniert, aber er zögert eben. Andererseits
hat die Version 2.38 ein brandneues, kaum getestetes Programm an Bord,
das aber keineswegs erst mal per Configure-Option aktiviert werden
muss. Das haut er einfach so raus. Die Prioritäten der Entwickler sind
eben andere, so ist es wohl fast immer. Um nun die Paketbetreuer
(wenigstens die der am meisten verbreiteten Distributionen) davon zu überzeugen, dass man den Schalter »--enable-po-man« ohne Risiko
aktivieren kann, müsste ich schon wieder zum Lobbyisten werden. Dazu
habe ich einfach keine Lust mehr.
Und bei System-V-Init warte ich auch noch drauf, dass die PO-Dateien auftauchen …
Das ist etwas kompliziert, man kommt nicht gleich darauf … Jesse Smith
hat meinen Patch nicht in »main« eingebaut, sondern in den Zweig
»3.02« [1]. Seltsam, aber wahr. Wenn du dir das Github-Repo auscheckst
und in man/po/ den Befehl »po4a po4a.cfg« ausführst, kriegst du eine aktuelle de.po, die du nach der Bearbeitung einfach wieder mit »po4a po4a.cfg« testen kannst. Ob die .po-Dateien mal irgendwo auf einer Übersetzungsplattform auftauchen werden (Transifex oder so), darüber
weiß ich auch nichts. Fakt ist, dass das so kaum einer mitkriegen
wird, wenn sie nur auf Github archiviert bleiben.
Also wenn es wieder mal um so eine Sache wie Sysvinit geht, wo es zu
Po4a im Upstream-Tree sowieso keine Alternative gibt (außer die
vorhandenen Übersetzungen für immer zu archivieren), dann werde ich
auch wieder was dazu beitragen, aber nicht mehr viel Zeit investieren
wollen. So ein Umzug wie der von util-linux, der kommt nicht wieder in
Frage. Eine Po4a-Konfiguration bauen und ein paar alte Übersetzungen importieren, das geht schon mal.
Hallo Mario,
On Mon, Mar 21, 2022 at 09:41:35PM +0100, Mario Blättermann wrote:
Am Mo., 21. März 2022 um 20:53 Uhr schrieb Helge Kreutzmann <debian@helgefjell.de>:
Hoffentlich kannst Du hier noch dranbleiben, wäre echt schade, wenn
die in den Orkus fallen.
Verschwinden werden die nicht - ich bleibe natürlich dran. Solange der
Bau der übersetzten Handbuchseiten aber nicht per Vorgabe in
util-linux aktiviert ist, wird das sowieso kein Paketbetreuer von sich
aus explizit aktivieren. So lange bleiben die Übersetzungen sowieso
bei uns. Für Fedora wird Karel Zak und separates RPM-Paket mit den übersetzten Handbuchseiten bauen; wenn das da ist nehme ich util-linux
aus unseren Fedora-Paketlisten raus. Aber ich denke, er hat mit diesem Extrapaket keine Eile.
Wenn Du mich hier auf dem Laufenden halten könntest, wäre gut, damit
ich bei Debian drauf achten kann.
Ich habe noch drei Projekte in der lokalen Warteschlange, die ich ansprechen wollte und gehofft hatte, das mit Dir machen zu können,
aber den Frust kann ich verstehen.
Es ist einfach zu aufwändig. Die Geschichte mit util-linux ist das mit Abstand arbeitsintensivste, was ich je in der Richtung gemacht habe.
Klar, Karel Zak ist seinen Groff-Code los, dessen Wurzeln oft
Jahrzehnte zurückreichten und freut sich über das wesentlich besser handhabbare Asciidoctor-Format. Aber die Handbuchseitenübersetzungen werden nicht aktiviert, obwohl das der einzig mögliche Weg ist, allen Paketbetreuern auf einen Schlag klar zu machen, dass das jetzt ein
Standard ist. Alles funktioniert, aber er zögert eben. Andererseits
hat die Version 2.38 ein brandneues, kaum getestetes Programm an Bord,
das aber keineswegs erst mal per Configure-Option aktiviert werden
muss. Das haut er einfach so raus. Die Prioritäten der Entwickler sind eben andere, so ist es wohl fast immer. Um nun die Paketbetreuer (wenigstens die der am meisten verbreiteten Distributionen) davon zu überzeugen, dass man den Schalter »--enable-po-man« ohne Risiko aktivieren kann, müsste ich schon wieder zum Lobbyisten werden. Dazu
habe ich einfach keine Lust mehr.
Klar.
Und bei System-V-Init warte ich auch noch drauf, dass die PO-Dateien auftauchen …
Das ist etwas kompliziert, man kommt nicht gleich darauf … Jesse Smith hat meinen Patch nicht in »main« eingebaut, sondern in den Zweig
»3.02« [1]. Seltsam, aber wahr. Wenn du dir das Github-Repo auscheckst
Ok, auf meine Nachfrage hatte er nicht geantwortet. Ich schaue mir das
in den nächsten Tagen mal an, ich habe nur „main“ momentan.
und in man/po/ den Befehl »po4a po4a.cfg« ausführst, kriegst du eine aktuelle de.po, die du nach der Bearbeitung einfach wieder mit »po4a po4a.cfg« testen kannst. Ob die .po-Dateien mal irgendwo auf einer Übersetzungsplattform auftauchen werden (Transifex oder so), darüber weiß ich auch nichts. Fakt ist, dass das so kaum einer mitkriegen
wird, wenn sie nur auf Github archiviert bleiben.
Ich hatte mit ihm abgestimmt, die de.po zu betreuen, falls ich
schreibzugriff aufs Git-Depot (Savannah, nicht Github) bekomme.
Allerdings war er da etwas pessemistisch, mal sehen, ob mein Antrag bearbeitet wird.
Wenn es kommt, wirds aber für Debian richtig kompliziert. Entweder
heißt es dann Sysv-Init oder manpages-de (Dateikonflikte) oder ich
muss mit Alternatives arbeiten, was ich noch nicht kenne. Insofern
könnte er sich von der Seite aus Zeit lassen.
Also wenn es wieder mal um so eine Sache wie Sysvinit geht, wo es zu
Po4a im Upstream-Tree sowieso keine Alternative gibt (außer die vorhandenen Übersetzungen für immer zu archivieren), dann werde ich
auch wieder was dazu beitragen, aber nicht mehr viel Zeit investieren wollen. So ein Umzug wie der von util-linux, der kommt nicht wieder in Frage. Eine Po4a-Konfiguration bauen und ein paar alte Übersetzungen importieren, das geht schon mal.
Gut zu wissen, Danke.
Am Mo., 21. März 2022 um 22:06 Uhr schrieb Helge Kreutzmann <debian@helgefjell.de>:
On Mon, Mar 21, 2022 at 09:41:35PM +0100, Mario Blättermann wrote:
Am Mo., 21. März 2022 um 20:53 Uhr schrieb Helge Kreutzmann <debian@helgefjell.de>:
Hoffentlich kannst Du hier noch dranbleiben, wäre echt schade, wenn die in den Orkus fallen.
Verschwinden werden die nicht - ich bleibe natürlich dran. Solange der Bau der übersetzten Handbuchseiten aber nicht per Vorgabe in
util-linux aktiviert ist, wird das sowieso kein Paketbetreuer von sich aus explizit aktivieren. So lange bleiben die Übersetzungen sowieso
bei uns. Für Fedora wird Karel Zak und separates RPM-Paket mit den übersetzten Handbuchseiten bauen; wenn das da ist nehme ich util-linux aus unseren Fedora-Paketlisten raus. Aber ich denke, er hat mit diesem Extrapaket keine Eile.
Wenn Du mich hier auf dem Laufenden halten könntest, wäre gut, damit
ich bei Debian drauf achten kann.
Sobald die erste Distribution die übersetzten Handbuchseiten mit
util-linux 2.38 selbst ausliefert (wird wohl Fedora sein) lösche ich util-linux in den betreffenden Paketlisten, mache eine komplette Upstream-Aktualisierung und haue zeitnah ein Bugfix-Release raus. Dann braucht kein Paketbetreuer zu patchen, sondern kann direkt unseren
Tarball nutzen.
Und bei System-V-Init warte ich auch noch drauf, dass die PO-Dateien auftauchen …
Das ist etwas kompliziert, man kommt nicht gleich darauf … Jesse Smith hat meinen Patch nicht in »main« eingebaut, sondern in den Zweig »3.02« [1]. Seltsam, aber wahr. Wenn du dir das Github-Repo auscheckst
Ok, auf meine Nachfrage hatte er nicht geantwortet. Ich schaue mir das
in den nächsten Tagen mal an, ich habe nur „main“ momentan.
und in man/po/ den Befehl »po4a po4a.cfg« ausführst, kriegst du eine aktuelle de.po, die du nach der Bearbeitung einfach wieder mit »po4a po4a.cfg« testen kannst. Ob die .po-Dateien mal irgendwo auf einer Übersetzungsplattform auftauchen werden (Transifex oder so), darüber weiß ich auch nichts. Fakt ist, dass das so kaum einer mitkriegen
wird, wenn sie nur auf Github archiviert bleiben.
Ich hatte mit ihm abgestimmt, die de.po zu betreuen, falls ich schreibzugriff aufs Git-Depot (Savannah, nicht Github) bekomme.
Allerdings war er da etwas pessemistisch, mal sehen, ob mein Antrag bearbeitet wird.
Mit Github wäre es einfacher. Sofern du dort noch kein Benutzerkonto
hast, legst du dir eines an, forkst sysvinit, bearbeitest die po-Datei
in deinem Fork und bietest ihm die Änderung per »Pull Request« an.
Dann stehst du trotzdem als Autor und Committer drin, ohne echten Schreibzugriff zu haben. Bei Savannah stelle ich mir das schwieriger
vor, einen direkten Zugang zu kriegen, die sind da bestimmt so
paranoid wie bei mir damals bei Gnome. Da hat es ein halbes Jahr
gedauert und brauchte einen Bürgen, damit ich endlich selbst committen konnte.
Wenn es kommt, wirds aber für Debian richtig kompliziert. Entweder
heißt es dann Sysv-Init oder manpages-de (Dateikonflikte) oder ich
muss mit Alternatives arbeiten, was ich noch nicht kenne. Insofern
könnte er sich von der Seite aus Zeit lassen.
Nein, ich habe doch die Sysvinit-Handbuchseiten aus unseren
Paketlisten schon letztes Weihnachten rausgenommen. Die vorhandenen .po-Dateien sind in den Archiven, können also keine Konflikte mehr verursachen. Siehe https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/a3181c0e50a28c0f180bfe83d5ba240395a8852c
Hallo Mario,
On Mon, Mar 21, 2022 at 10:33:50PM +0100, Mario Blättermann wrote:
Am Mo., 21. März 2022 um 22:06 Uhr schrieb Helge Kreutzmann <debian@helgefjell.de>:
On Mon, Mar 21, 2022 at 09:41:35PM +0100, Mario Blättermann wrote:
Am Mo., 21. März 2022 um 20:53 Uhr schrieb Helge Kreutzmann <debian@helgefjell.de>:
Hoffentlich kannst Du hier noch dranbleiben, wäre echt schade, wenn die in den Orkus fallen.
Verschwinden werden die nicht - ich bleibe natürlich dran. Solange der Bau der übersetzten Handbuchseiten aber nicht per Vorgabe in util-linux aktiviert ist, wird das sowieso kein Paketbetreuer von sich aus explizit aktivieren. So lange bleiben die Übersetzungen sowieso bei uns. Für Fedora wird Karel Zak und separates RPM-Paket mit den übersetzten Handbuchseiten bauen; wenn das da ist nehme ich util-linux aus unseren Fedora-Paketlisten raus. Aber ich denke, er hat mit diesem Extrapaket keine Eile.
Wenn Du mich hier auf dem Laufenden halten könntest, wäre gut, damit ich bei Debian drauf achten kann.
Sobald die erste Distribution die übersetzten Handbuchseiten mit util-linux 2.38 selbst ausliefert (wird wohl Fedora sein) lösche ich util-linux in den betreffenden Paketlisten, mache eine komplette Upstream-Aktualisierung und haue zeitnah ein Bugfix-Release raus. Dann braucht kein Paketbetreuer zu patchen, sondern kann direkt unseren
Tarball nutzen.
Yep, ich muss nur entsprechend Paketrelationen setzen, damit eine Aktualisierung von util-linux auch eine von manpages-de (oder
manpages-fr …) auslöst, obwohl die beiden ja normalerweise keinerlei Relation haben, d.h. unabhängig voneinander aktualisiert werden
können.
Und bei System-V-Init warte ich auch noch drauf, dass die PO-Dateien auftauchen …
Das ist etwas kompliziert, man kommt nicht gleich darauf … Jesse Smith
hat meinen Patch nicht in »main« eingebaut, sondern in den Zweig »3.02« [1]. Seltsam, aber wahr. Wenn du dir das Github-Repo auscheckst
Ok, auf meine Nachfrage hatte er nicht geantwortet. Ich schaue mir das
in den nächsten Tagen mal an, ich habe nur „main“ momentan.
und in man/po/ den Befehl »po4a po4a.cfg« ausführst, kriegst du eine aktuelle de.po, die du nach der Bearbeitung einfach wieder mit »po4a po4a.cfg« testen kannst. Ob die .po-Dateien mal irgendwo auf einer Übersetzungsplattform auftauchen werden (Transifex oder so), darüber weiß ich auch nichts. Fakt ist, dass das so kaum einer mitkriegen wird, wenn sie nur auf Github archiviert bleiben.
Ich hatte mit ihm abgestimmt, die de.po zu betreuen, falls ich schreibzugriff aufs Git-Depot (Savannah, nicht Github) bekomme. Allerdings war er da etwas pessemistisch, mal sehen, ob mein Antrag bearbeitet wird.
Mit Github wäre es einfacher. Sofern du dort noch kein Benutzerkonto
hast, legst du dir eines an, forkst sysvinit, bearbeitest die po-Datei
in deinem Fork und bietest ihm die Änderung per »Pull Request« an.
Dann stehst du trotzdem als Autor und Committer drin, ohne echten Schreibzugriff zu haben. Bei Savannah stelle ich mir das schwieriger
vor, einen direkten Zugang zu kriegen, die sind da bestimmt so
paranoid wie bei mir damals bei Gnome. Da hat es ein halbes Jahr
gedauert und brauchte einen Bürgen, damit ich endlich selbst committen konnte.
Ich gebe dem ganzen noch ein weilchen, bevor ich mir das mit dme
Forken und pull request anschaue.
Wenn es kommt, wirds aber für Debian richtig kompliziert. Entweder heißt es dann Sysv-Init oder manpages-de (Dateikonflikte) oder ich
muss mit Alternatives arbeiten, was ich noch nicht kenne. Insofern könnte er sich von der Seite aus Zeit lassen.
Nein, ich habe doch die Sysvinit-Handbuchseiten aus unseren
Paketlisten schon letztes Weihnachten rausgenommen. Die vorhandenen .po-Dateien sind in den Archiven, können also keine Konflikte mehr verursachen. Siehe https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/a3181c0e50a28c0f180bfe83d5ba240395a8852c
Ok, das meinte ich so nicht.
Nehmen wir an, ein Benutzer verwendet Devuan oder ersetzt händisch
Systemd mit Sysv. Dann bekommt er plötzlich die Übersetzung von
shutdown aus SysV-Init. Da jede Datei eindeutig einem Paket zugeordnet
sein muss, bekomme ich einen Fehlerbericht (Installation von
Systemv-Init schlägt fehl, da manpages-de shutdown schon enthält).
Um das Problem zu lösen, gibts zwei Varianten:
1. SystemV und manpages-de stehen im Konflikt. Wird also Systemv-Init
installiert, dann fliegt manpages-de raus und umgekehrt. Also
korrekt übersetzte Handbuchseiten für shutdown und Co, aber alle
anderen deutschen Handbuchseiten sind fort.
2. Beide Pakete erklären, dass es mehrere Varianten der Datei gibt.
Dann kann der Benutzer wählen, welche er sehen will
("Alternatives"-System, die Idee hat RedHat von Debian übernommen).
Standardmäßig hätte shutdown von Systemv-init eine höhere Priorität
als aus manpages-de, so dass (wenn der Benutzer nichts einstellt),
er die Systemv-Init-Variante bekommt. Ich muss mir halt nur
anschauen, wie das genau funktioniert und mich mit dem
Debian-Paketbetreuer des Systemv-Init-Pakets abstimmen.
Alle anderen, davon nicht betroffenen Handbuchseiten aus
manpages-de bleiben weiter verfügbar.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 376 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 52:37:18 |
| Calls: | 8,041 |
| Files: | 13,037 |
| Messages: | 5,831,891 |