Re: Taskliste für Handbuchseitenübersetzungen (war: Re: [RFR] man://manpages-de/lsns.8.po)
Hallo Helge,
Am Fr., 4. Jan. 2019 um 15:16 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
>
> Hallo Mario,
> On Fri, Jan 04, 2019 at 02:17:08PM +0100, Mario Blättermann wrote:
> > Am Fr., 4. Jan. 2019 um 07:04 Uhr schrieb Helge Kreutzmann
> > <debian@helgefjell.de>:
> > >
> > > 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>:
> > 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).
>
> Das Zurückportieren passiert halbautomatisch, erzeugt für uns
> Übersetzer i.d.R. keine Arbeit (außer wir wollen die Zeichenketten,
> die es in der aktuellen Version so nicht mehr gibt, auch noch
> übersetzen). Daher würde ich mir über das secondary-debian-stretch
> keine Sorgen machen (es im Zweifel einfach ignorieren). Das einzige
> was dort nicht klappt, ist die Zuordnung der Übersetzer (siehe
> Debian_Fehler #897919). Und sehen tun das nur Benutzer, die
> »backports« aktiviert haben, d.h. Benutzer des reinen Veröffentlichung
> Stable nicht.
>
Ah, an die Backports habe ich gar nicht gedacht... Aber ist es
wirklich so, dass eine im Git explizit in »primary« eingefügte
po-Datei implizit in »secondary-xxx« landet, ohne unser Zutun? Das
würde mindestens voraussetzen, dass die Aktualisierungsskripte die
Verzeichnisse /upstream und /po abgleichen, um festzustellen, ob das
Vorhandensein einer bestimmten po-Datei in den
»secondary-xxx«-Verzeichnissen überhaupt sinnvoll ist.
> Analog würde ich es Tobias überlassen, das Verzeichnis für Buster zu
> erzeugen oder (irgendwann) das Verzeichnis für Stretch zu löschen.
>
Sowieso, die administrativen Sachen überlasse ich ihm. Für mich als
Nicht-Debianer ist es sowieso zweitrangig, ich will mir halt nur
Arbeit ersparen.
Gruß Mario
Reply to: