Hello Julian, Am Sat, Feb 08, 2025 at 01:13:41PM +0100 schrieb Julian Andres Klode: > On Sat, Feb 08, 2025 at 11:12:21AM +0000, Helge Kreutzmann wrote: > > Hello Julian, > > hello Andres, > Did you count me twice? Muhaha
Aplogies.
> > hello Michael,
> > hello David,
> > hello Chris,
> > there are three long standing open bugs with German translation
> > updates. I haven't seen any activity from Chris as well. Thus the
> > German translation shipped is quite outdated.
>
> Oh dear. Well the last bug, this one is over a year old, so you
> could have pinged earlier as I'm pretty sure it has fallen through
> the cracks.
Well, there are long lists of open translations, some maintainers are
not very fond of applying them. Thus I often perform some L10N NMUs,
but I did not check the status of apt.
And probably those translations are already outdated.
> > I would like to have a good/complete German translation of apt in
> > Trixie.
> >
> > I see two possible ways:
> > 1) Whenever the original changes, I supply updated translations by bug
> > reports. However, then these reports should be handled in one of
> > the next uploads.
>
> So it's mostly David handling translation updates from bug reports as
> he has tooling for it; whereas I do a crazy weekly release cadence at
> this time that I don't think it's useful to keep up with on the
> translation side.
>
> My suggestion is to avoid translation updates until the freeze as
> there is significant churn and new strings ahead. In particular, I
> did not mark the `modernize-sources` command as translatable in any
> way to avoid pointless work.
Thanks for considering the translators. Unstable strings should be not
shown to the translators, this is very welcome.
As a translator, though, I prefer incremental updates. So once in a
while a few strings is ok, but having to do dozens of strings within a
short time frame (including review) raises the bar. But of course,
each project is different.
> > 2) I get write access to the repository of apt and update the German
> > translations myself by commiting updated de.po whenever needed,
> > following your commit guidelines (if there are any).
>
> The correct workflow for APT is to submit merge requests. We do not
> usually commit directly to the main branch. It's almost exclusively
> release commits, sometimes maybe a tiny bug fix for which a merge
> feels a bit silly, but in any case it requires careful consideration
> and presence in #debian-apt to ensure one does not commit while a
> release is being prepared (usually this takes about half an hour
> as the previous branches got merged and I wait for CI to pass on
> the commit).
>
> I'd prefer to handle translation updates via merge requests as well
> but we should put a validation pipeline in place, as most of the
> translation updates we receive cannot be committed as is, but
> need to be merged with the template first (which is what David's
> script does IIRC).
I know that many translators are not that careful, being maintainer of
manpages-l10n. For dpkg, Guillem wrote a set of validation checks and
a dedicated script, so I haven't broken the build for about 15 years
now there.
Given that merge requests quit break text based workflows and cause
quite a bit of overhead, I guess I simply go down route 1).
Thus I will send in appropriate bug reports whenever a need arises,
i.e. strings are to be updated. Then you can safely perform your
validation workflow. And in case an L10n bug gets stuck, I simply ping
you earlier.
Greetings
Helge
--
Dr. Helge Kreutzmann deb...@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/
signature.asc
Description: PGP signature
