[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Taskliste für Handbuchseitenübersetzungen (war: Re: [RFR] man://manpages-de/lsns.8.po)



Hallo Helge,

Am Fr., 4. Jan. 2019 um 07:04 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
>
> Hallo Mario,
> On Thu, Dec 27, 2018 at 01:17:17PM +0100, Mario Blättermann wrote:
> > Am Do., 27. Dez. 2018 um 06:40 Uhr schrieb Helge Kreutzmann
> > <debian@helgefjell.de>:
> >
> > > […]
> > > Ich weiß ja nicht, welcher Systematik Du folgst, aber wenn Du über die
> > > Feiertage etwas Zeit hast, würden sich die Benutzer bestimmt über
> > > mount(8) freuen …
> > >
> > Irgendwie müsste man das so systematisieren, dass zumindest alle
> > Original-Handbuchseiten, die im Git enthalten sind, eine gewisse
> > Priorität erhalten, weil die entsprechenden Pakete sowieso schon zu
> > unserem Portfolio gehören. Entweder könnte man im Git-Repo die Inhalte
> > von /upstream/*/man* mit /po/*/man* abgleichen, alle noch fehlenden
> > po-Dateien erzeugen und diese ins Git einspielen. Das würde allerdings
> > unsere Web-Übersicht mit zahlreichen kaum übersetzten Dateien
> > überfluten, was die Sache schon mal ziemlich unübersichtlich machen
> > würde.
>
> Das müsstest Du mit Tobias klären. Ich habe kein Problem damit, dass
> auch ein Schwung halbleerer Dateien im Paket enthalten ist. Das hätte
> (für mich) den Vorteil, dass ich genau sehe, welche Übersetzungen noch
> in Frage kämen.
>
Dann hätten sich ja die Überlegungen bezüglich des Skripts erledigt.
Wenn du das sogar als Vorteil siehst, könnte ich demnächst damit
anfangen, für alle noch unübersetzten Manpages in /upstream die
zugehörigen po-Dateien zu erzeugen, damit sie in der Webübersicht
angezeigt werden können. Ist natürlich auch eine Menge Arbeit, ich
würde dann erst einmal mit den Abschnitten 1 und 8 anfangen, die ich
für wichtig halte und die ich auch vom Verständnis her besser
bewältigen kann als die Abschnitte 2 und 3.

> Ich habe mir mal ein Skript geschrieben, um die am häufigsten in den
> deutsch übersetzten Seiten zitierte aber noch nicht übersetzte
> Handbuchseiten zu finden, und da war mount(8) ganz oben.
>
> > Eine Idee hätte ich dazu, in Form eines Skripts, das der geneigte
> > Übersetzer aufruft. Ich stelle mir das so vor: Beim Aufruf durchsucht
> > es die Unterverzeichnisse von /upstream, vergleicht diese anhand der
> > Datei-Basisnamen  mit /po und zeigt fehlende po-Dateien an. Die
> > Ausgabe könnte dann noch gefiltert werden, damit beispielsweise
> > Debianer die Archlinux-spezifischen Sachen ausblenden können und
> > umgekehrt. Eine Filterung wäre auch anhand der
> > Handbuchseitenabschnitte denkbar, um zum Beispiel Entwicklerhandbücher
> > in den Abschnitten 2 und 3 ausblenden zu können. Ist nur eine Idee,
> > aber umsetzen könnte ich die mangels Kenntnissen in der
> > Shellprogrammierung leider nicht.
>
> In (wenig schönem) Skript klingt das machbar, aber wie geschrieben,
> das sollten mir mit Tobias besprechen.
>
OK, das Skript hat sich ja nun fast erübrigt, nur kommen beim
Aktualisieren aus den Upstream-Paketen immer wieder mal neue
Handbuchseiten hinzu, die uns bei einmaligem Abgleich von /upstream
und /po durch die Lappen gehen würden. Aber das ist Zukunftsmusik, mit
den derzeitigen Lücken haben wir mit Sicherheit auf längere Sicht
genug zu tun.

In diesem Zusammenhang noch eine Frage: Ergibt es noch Sinn, eine neue
Übersetzung im Git-Repo auch in secondary-debian-stretch einzufügen?
Wie ich sehe, gibt es für Stretch nur das alte Paket der Version 1.22,
und wenn ich mich recht erinnere, gestatten die Regeln sowieso nicht,
Paketversionen innerhalb einer bereits veröffentlichten Dsitribution
zu aktualisieren. Ich denke dabei noch an Etch zurück, das mit
xfce-4.3.99 (einem Release Candidate) veröffentlicht wurde und dieses
nicht auf die stabile Upstream-Version 4.4 aktualisiert werden durfte.
So müssten bei einer Aktualisierung des Debian-Pakets theoretisch die
neuen po-Dateien in das Paket manpages-de-1.22 zurückportiert werden,
aber das macht doch sicherlich keiner, oder?
Übrigens, es wäre vielleicht an der Zeit, für Buster ein eigenes
Verzeichnis im Git einzurichten (und im Gegenzug dafür Stretch zu
streichen oder einfach dessen Konfiguration auf Buster zu
aktualisieren).

Gruß Mario


Reply to: