Hello,
thanks Holger for rasing these issues.
I only want to reply to a few sub points, but I guess I could write
simmilarly long e-mails.
Am Sun, Dec 03, 2023 at 12:08:21AM +0100 schrieb Holger Wansing:
> Thomas Lange <lange@cs.uni-koeln.de> wrote (Wed, 29 Nov 2023 20:13:50 +0100):
> > Because these are important pages with many hits, I would expect to
> > have these translation updated in a few weeks, maybe 1-2 weeks.
> >
> > When should we remove these outdated translations?
> > What's your oppinion?
> So, the point is: translator's time might be rare; and you cannot force
> them on what pages they work, there might be more effective criteria then
> just the number of hits in our statistic.
I'm heavily involved in translations, e.g. for man pages, and I
noticed a similar pattern there as well - teams focus on different
aspects and by different schedule. So some translators take the "easy"
things first, some work by alphabet, some by some kind of popularity.
From outside, it is hard to tell. And some work seldom, some more
often, but all appear glad to have something to continue work with.
> Another point might be (while this is my personal opinion here !!!):
> there are too much commits to English, which only change trivial things
> (remove blank lines; fix typos in English; fix wording ...) and the
> translations are not synced or cannot be synced by the author of the
> English change. And the translations (might) become outdated because of this.
This is one of the most major PITA for translators. I've seen them
several times in different projects. Oh, we add the Oxford comma. Oh,
we change the quotes. Uups, wrong britsh/US spelling.
While the upstream change might be easily done with a script, each
translator, again and again, has to review the change and then to
determine if (or if not, often) an update is needed. No visibility and
much of redone work by far too few translators. This is time consuming
and demotivating.
So it would be great if people working on the english version could
strictly split their commits. First, doing (if necessary) the english
polishing. Then mark this commit appropriately ("no changes for
translations necessary") and also "sync" all up to date translations.
Seperately from this, work on content, where updates by the
translators are needed.
> I would not vote too strict against the removal of outdated translations,
> in fact I did that some years ago for German as well, due to lack of
> manpower in the German team.
Yes, it was me who was hit. I spend quite some time on translating the
web page but then I did not have the time anymore to maintain it
appropriately. But I always thought the notion "this page is outdate,
you can look here to get the lates version in english" is fine. And
other (potential) translators could easily pick it up. (And if it is
too old, then the english is shown).
> Of course you might say "Hey, the file is not lost, we have a git repo
> here! No need for such trick."
> That's of course correct, but translators might not be as familiar with
> such advanced usage of git as DDs are.
> So I think it would be worse it.
Pointing translators to git, as Holger said, does not work. They
are not programmers. Make it easy for them to discover previous work
and continue it. It might even be work from long ago.
In manpages-l10n we collect those old work and transform them in PO
files. They are there - translators can "easily" spot them and
continue work. If the translation is below 80%, then it will no longer
be built. But I'v been able to recruite many translators who happily
picked up the work. And yes, as (part of) upstream I can often sync
translations myself (e.g. version number changes).
Deleting/Removing is not the right way. It just hurts/demotivates
translators. And I don't think disc space is so much of a concern
nowadays (at least for text). Having a small translation, however,
just gives rise to the chance for some potential translator to say
"Hey, my language is welcome here, but it is not doing good. Maybe I
can contribute!"
Greetings
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