Re: [ITT] man://manpages-l10n/muttrc.5.po
Hallo Helge,
Am Mo., 21. März 2022 um 22:06 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
>
> 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.
>
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.
> > > 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.
>
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
> > 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.
>
OK.
Gruß Mario
Reply to: