Moin Mario,
On Sun, Jan 05, 2020 at 07:40:08PM +0100, Mario Blättermann wrote:
> Am So., 5. Jan. 2020 um 18:59 Uhr schrieb Helge Kreutzmann
> <debian@helgefjell.de>:
> > On Sun, Jan 05, 2020 at 06:25:28PM +0100, Mario Blättermann wrote:
> > > Am So., 5. Jan. 2020 um 07:06 Uhr schrieb Helge Kreutzmann
> > > <debian@helgefjell.de>:
> > > >
> > > > Hallo Mario,
> > > > On Fri, Jan 03, 2020 at 10:43:40PM +0100, Mario Blättermann wrote:
> > > > > im Projekt manpages-l10n wäre es wieder Zeit für eine
> > > > > Upstream-Aktualisierung. Wir haben derzeit noch Debian Buster drin,
> > > > > was aber wohl kaum noch wichtig ist. Wenn überhaupt, wäre eine
> > > > > Auslieferung der manpages-*-Pakete nur über die Backports möglich.
> > > > > Wäre es an der Zeit, Buster zu entfernen und auf Bullseye zu wechseln?
> > > >
> > > > Und genau das machen wir doch?
> > > >
> > > Nein, eben nicht. Wir haben immer noch die Handbuchseiten aus Buster
> > > im Programm. Bekanntermaßen gibt es keine Möglichkeit, in eine bereits
> > > veröffentlichte Debian-Version neue Paketversionen einzubringen. Das
> > > geht nur über die Backports, die möglicherweise nicht allzu viele Fans
> > > haben, so dass letztendlich kaum neue oder aktualisierte
> > > Handbuchseiten beim Leser ankommen.
> >
> > Ich habe in den Veröffentlichungshinweisen eben jene Backports
> > beworben [1] und mein Eindruck (keine Zahlen) ist, dass die Backports
> > durchaus gut angenommen werden. Bei den bestehenden Handbuchseiten
> > fliegen immer wieder Fehler raus, und neue kommen ja auch hinzu. Und
> > es wäre kein Problem, Zeichenketten von Buster mit niedrigerer
> > Priorität zu handhaben (wenn Du dran bist).
> >
> Beim Vervollständigen einer Übersetzung will ich nicht diejenigen
> Strings aussortieren, bei denen nicht »Archlinux« drüber steht.
> Schließlich sind wir ein multidistributionales Projekt.
Danke, handhabe ich genauso.
> > > > Ich würde gerne Sid + Stable, d.h. derzeit Sid + Buster behalten.
> > > > Bullseye (Testing) bringt dagegen gar nichts, wohin soll das denn
> > > > hochgeladen werden?
> > > >
> > > Keine Ahnung, das geht über meine Kenntnisse zu Debian hinaus. Vergiss
> > > die Idee einfach, hinsichtlich Debian bin ich sowieso
> > > leidenschaftslos.
> >
> > Ok.
> >
> > (Falls es Dich interessiert: Pakete sind erst in Sid, gehen dann nach
> > Testing. Irgendwann wird Testing eingefroren und zu Buster umbenannt.
> > Abgesehen von Spezialfällen (z.B. während des Einfrierens) läuft alles
> > ausnahmslos über Sid)
> >
> OK, verstanden. Dann wäre die Ersetzung von Buster durch Bullseye erst
> dann fällig, wenn Bullseye im Freeze ist, richtig?
Ja.
> > > > > Das würde ich nämlich gerne noch vor der Aktualisierung machen, um
> > > > > Zeit zu sparen. Ich habe bei der vorletzten Prozedur Ende November mal
> > > > > die Zeiten notiert, die für die einzelnen Schritte nötig sind (die
> > > > > später hinzugekommenen polnischen Dateien sind noch nicht
> > > > > berücksichtigt):
> > > >
> > > > …
> > > >
> > > > > Wenn man mal die Aktualisierungen der nicht-deutschen *.po-Dateien
> > > > > außen vor lässt, die eigentlich Sache der jeweiligen Sprachteams sind,
> > > > > dauert das Ganze auf meinem Rechner etwa eineinhalb Stunden. Daher ist
> > > > > mir sehr daran gelegen, hier und da etwas einsparen zu können.
> > > >
> > > > Muss dass denn alles sequenziell laufen? Wäre es nicht eher sinnvoll,
> > > > mittelfristig die Infrastruktur auf einen parallelen Lauf zu
> > > > aktualisieren? Die Sprachen sollten doch auf jeden Fall parallel
> > > > laufen könne, eigentlich auch die Distributionen, oder?
> > > >
> > > Die Aktualisierung der Upstream-Pakete läuft seriell, braucht aber bei
> > > mir auch nur 15 Minuten. Das geht alles noch. Aber auch wenn es
> > > parallel laufen würde, setzt der Rechner seine natürlichen
> > > Leistungsgrenzen. Ganz allein vor sich hin rödeln lassen kann man
> > > diese Prozedur auch nicht. Da ist immer mal was zwischendurch zu
> > > korrigieren, zum Beispiel wenn sich aus einer Handbuchseite wegen
> > > Syntaxfehlern keine Vorlage bauen lässt oder bei Umbenennungen oder
> > > so.
> >
> > Wären die Fehler (eher) zu fangen, wenn Du in einem temporären Ort
> > z.B. einmal täglich (Anacron mit Mittags) einen Bau der Handbuchseiten
> > anstoßen und Dir das Ergebnis zumailen lässt? Wäre eine E-Mail
> > täglich, und ggf. ein Fehler täglich raus. Ich gehe davon aus, dass
> > die Aktualisierung der Upstream-Pakete das nicht bedarf.
> >
> > > Das größte Problem ist das Skript templates/update-all-templates.sh.
> > > Das arbeitet nacheinander die Po-Dateien aller Sprachen ab, aber
> > > dupliziert vieles. Der erste Befehl im Skript liefert derzeit folgende
> > > Verzeichnisliste:
> > >
> > > de/man1
> > > de/man2
> > > de/man3
> > > de/man4
> > > de/man5
> > > de/man6
> > > de/man7
> > > de/man8
> > > fr/man1
> > > fr/man2
> > > fr/man3
> > > fr/man4
> > > fr/man5
> > > fr/man6
> > > fr/man7
> > > fr/man8
> > > nl/man1
> > > nl/man2
> > > nl/man3
> > > nl/man4
> > > nl/man5
> > > nl/man6
> > > nl/man7
> > > nl/man8
> > > pl/man1
> > > pl/man2
> > > pl/man3
> > > pl/man4
> > > pl/man5
> > > pl/man6
> > > pl/man7
> > > pl/man8
> > > ro/man1
> > > ro/man5
> > >
> > > Die Liste wird dann sequenziell abgearbeitet. Nun ist es aber so, dass
> > > sich beispielsweise eine Datei namens man1/chmod.1.po in allen
> > > Sprachverzeichnissen befindet und daher fünfmal eine neue Vorlage
> > > chmod.1.pot erstellt wird. Diese Verzeichnisliste ist bei mehreren
> > > Sprachen einfach der falsche Ansatz. Das Skript müsste gleich eine
> > > Dateiliste bauen, in der es keine Duplikate gibt. So könnte man die
> > > derzeit für die Ausführung nötigen 44 Minuten auf vielleicht 25
> > > Minuten schrumpfen lassen. Das wäre schon mal ein Fortschritt. Nur
> > > leider würde ich das mit meinen bescheidenen Kenntnissen nicht
> > > hinkriegen. Jedenfalls würde es wohl so lange dauern, bis es
> > > funktioniert, dass der Zeitvorteil wieder dahin wäre.
> >
> > Ok, das ist in der Tat nicht gut. Aber schon die Parallelisierung der
> > Sprachen (dann würden die POT-Dateien eben parallel erstellt) wäre ja
> > ein erster Schritt, oder?
> >
> Ergibt keinen Sinn. Die Rechenleistung ist begrenzt, daher würde das
> bei mir wohl kaum schneller gehen. Ich habe einen zehn Jahre alten
> Laptop. Der ist noch leistungsfähig genug für ein aktuelles KDE, aber
> wenn die Aktualisierungsskripte laufen, geht er in die Knie und wird
> zum Heizgerät. Da bringen parallele Abläufe wohl nichts. Der
> springende Punkt ist doch, dass die Skripte in ihrer derzeitigen Form
> einen Flächenbrand im Git-Repo entfachen und zum Beispiel jede Menge
> Pakete herunterladen, die nicht heruntergeladen werden müssten, dito
> für die Erstellung der Vorlagen und Aktualisierung der po-Dateien. Da
> müssen wir ran, wie auch immer.
Ok, das war mir nicht bewusst. Dann ist das (leider) keine Option.
> > Aber ich gebe Dir recht, ich könnte es wahrscheinlich auch nicht
> > (kaum) »mal eben« umbauen, aber vielleicht liest Tobias ja mit und
> > findet einen Weg …
> >
> > > Einmal ziehe ich die Aktualisierung mit den derzeitigen Skripten noch
> > > durch, aber dann reicht es mir auch. Eineinhalb Stunden sind einfach
> > > zu viel. Zwanzig Minuten weniger sind aber auch noch kein Meilenstein,
> > > deswegen brauchen wir auch für die Upstream-Pakete eine andere Lösung.
> > > Derzeit werden die Verzeichnisse in usptream/*/man* komplett geleert
> > > und *alles* neu heruntergeladen und entpackt. Wir müssten
> > > Versionsnummern in upstream/*/packages.txt hinzufügen und das Skript
> > > so ändern, dass nur noch Pakete heruntergeladen werden, deren
> > > Versionsnummer auf dem Server neuer als die in der Paketliste ist.
> > > Danach müssen auch nur die Vorlagen erstellt werden, für die es
> > > tatsächlich neue Originalhandbuchseiten gibt. Insgesamt würde sich der
> > > Zeitaufwand damit dauerhaft auf deutlich unter eine Stunde drücken
> > > lassen, was bei einer oder zwei Aktualisierungen pro Monat durchaus
> > > akzeptabel ist. Ich weiß, das Umstellen der Skripte ist viel Arbeit
> > > und ich kriege das selbst nicht hin, aber ich möchte meine Freizeit
> > > lieber in die Übersetzungen selbst investieren als in das Starten von
> > > Skripten, die vieles doppelt, drei- oder fünffach abarbeiten.
> > > Möglicherweise kommen ja auch noch mehr Sprachen und/oder
> > > Distributionen hinzu, was wieder mehr Zeit bedeutet.
> >
> > Kann ich gut verstehen.
> >
> > Ist denn die Last bei der Arbeit mit den Skripten hoch? Ansonsten
> > könnte könnten die i.d.R. unproblematischen Teile z.B. auch mittels
> > anacron nach dem Booten, z.B. jeden Montag[2], durchgeführt werden. Dann
> > würdest Du zumindest die ersten 20 Minuten gar nicht mitbekommen. Und
> > wenn Du den anderen Anacron-Job von oben auch machst, könntest Du
> > sogar den zweiten Teil riskieren, ggf. läuft es ja dann schon durch
> > und Du hast es gar nicht mitbekommen.
> >
> Wo solle denn die Cronjobs laufen? Auf meinem Laptop, der mal abends
> für ein oder zwei Stunden eingeschaltet wird? Außerdem habe ich in der
> Regel nur am Wochenende unbegrenztes Netzwerkvolumen, ansonsten nur
> Mobilfunknetz. Das hilft mir nicht weiter und ist nur weitere sinnlose
> Ressourcenvergeudung.
Ok, wir haben da andere Hardware und Netzanbindung.
> > > Die Aktualisierungen seltener auszuführen ist auch keine Lösung, damit
> > > schießen wir uns selbst ins Knie und werden den zweifelhaften Ruf
> > > niemals los, dass übersetzte Handbuchseiten den Originalen zeitlich
> > > weit hinterherhinken. Die bedingungslose Aktualität ist ja gerade das
> >
> > Ich sehe das nicht so dramatisch. Wir müssen nicht tagesaktuell sein.
> > Natürlich ist für den Benutzer aktueller auch besser, aber ich fände
> > es nicht dramatisch, wenn die Übersetzung nur ein paar Mal pro Jahr
> > nachgezogen würde. Dann sind die Erklärungen der neusten Optionen ggf.
> > noch nicht da (d.h. es müsste in die englische Seite geschaut werden),
> > aber ich glaube, viele Benutzer sind schon über die 80% oder mehr, die
> > durch die Seite abgedeckt werden, erfreut.[3]
> >
> Ich will definitiv so aktuell wie möglich sein. Es verärgert mich als
> Leser nur, wenn ich für eine zum jeweiligen installierten Programm
> passende Dokumentation in die englische Handbuchseite schauen muss,
> obwohl es eine deutsche gibt. Klar, gegenüber manpages-hu, was 19
> Jahre alte Klartextübersetzungen enthält, ist selbst manpages-it von
> 2016 brandaktuell. Aber so einfach relativiere ich das nicht. Wenn
> schon die allermeisten Upstream-Entwickler keine Notwendigkeit sehen,
> übersetzte Handbuchseiten direkt in ihre Projekte aufzunehmen, will
> ich das wenigstens hier irgendwie abfedern, aber nicht mit einem
> verklärten Blick auf die Aktualität.
Ich sehe Deinen Punkt, auch wenn ich eine (leicht) andere Sichtweise
habe.
> > > Argument, mit dem ich bestehende Sprachteams anzulocken versuche. Was
> > > soll ich denen denn sagen, wenn wir vielleicht nur noch vier Mal im
> > > Jahr aktualisieren und zwei Mal einen neuen Tarball
> > > veröffentlichen...? Außerdem würde ich so etwas den Benutzern auch
> > > nicht zumuten wollen, gerade als Nutzer einer
> > > Rolling-Release-Distribution, die auf Aktualität zwingend angewiesen
> > > ist.
> >
> > Das kann ich nicht beurteilen, aber im Vergleich zu vorher
> > (Übersetzungen teilweise Jahr(zehnte) alt - da ist unser Ansatz schon
> > ein großer Fortschritt.
> >
> > Und Danke, dass Du Dich da so reinkniest.
> >
> Gern geschehen. Wäre nur schön, wenn seitens der französischen und
> polnischen Übersetzer mal ein wenig Aktivität erkennbar wäre. Mal
> sehen, was sich so bis Ende nächsten Jahres tut... Die Anfrage an die
> Italiener ist zwar schon beantwortet, aber es ist noch nichts
> entschieden. Wenn sie wirklich zu uns kommen wollen, landen ihre
> po-Dateien sowieso erst einmal in einem separaten Git-Zweig und werden
> erst in den Hauptzweig überführt, wenn alles importiert ist.
Hat den ein polnischer Übersetzer schon Git-Zugriff (beantragt)?
Viele Grüße
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: PGP signature