Hi Frans, [ Frans Spiesschaert, 2020-08-22 ] > Wolfgang Schweer schreef op vr 21-08-2020 om 20:55 [+0200]: > > After some percentage re-calculation now that the filtering is > > showing effect and a look at the actual translation content, a value > > of 40-45% seems to be adequate. (Audacity and ITIL 45%, the other > > ones 40% - this is the k param value in po4a.cfg, the real > > percentage is higher because of a smaller divisor.) > > As I understand it correctly, after the transition to two binary > packages we would keep about the same situation in terms of generated > manuals as before. Perhaps this is not that bad as an approach, and > later on, after having had an evaluation of the new situation, we > could still make adjustments if they seem preferable. Agreed. What I was trying to say: if there is a manual specific threshold (-k param value in the related po4a.cfg file), building the binary packages is much faster, doesn't spoil the build directory, requires less system resources and means less energy consumption. Taking the audacity manual as an example: There are 140 strings, reduced to 86 due to filtering. If the package is built (or if one runs 'LINGUA=<lang> make html' manually), 140 is taken as divisor, not 86. So if we want a translation to not be discarded if at least 66% of the strings are translated (then maybe qualified as 'partially translated'), 86*.66=57.76 strings need to be translated. This results in a k param value of 86*.66/140=0.4054, i.e. a -k param value of 40. > > Legacy block: > > en, nb-no, nl: Audacity, ITIL and Rosegarden manuals > > fr: Audacity and Rosegarden manuals > > ja, pl, pt-br, zh-cn: Audacity manual > > Shouldn't "sv" be added here too? (49 translated strings out of 86 for > audacity and 239 translated strings out of 598 for rosegarden) Maybe, yes. As you pointed out earlier, it's a compromise between availability and meaningfulness of a given translation, Is 66% an appropriate value? Too low, too high? > > Please note that debian-edu-doc-es isn't contained in the list, a look > > at the content as a whole confirmed me that the Spanish translations > > (Buster, Bullseye) are no longer useful indeed - please check it > > yourself on jenkins.debian.net. > > This is a bit sad, because in general the Debian Spanish localization team > is doing a rather good job. Agreed, dropping (es) has been nagging me, too. So I did some unfuzzying to raise the translation status. The (es) package can be kept. > Because a concurrent translation update of a same language via > different ways (e.g. a wihslist bug, git, weblate) eventually leads to > chaos, Spanish is currently disabled on weblate. Yes. > Perhaps I'd better enable Spanish on weblate from now on. I > am unsure. For da, it, fr and ja we surely need to prepare a similar > effort as back in 2019, timely before the freeze of bullseye. Maybe reconsider adding (es) to weblate if there isn't any feedback from the Spanish team? > Some questions remain, though: > > Is it expected that these legacy manuals will ever get updated again or is > it rather expected that they will only lead a dormant existence from now > on, to disappear completely eventually? I don't know. People seem to translate those manuals on weblate for unknown reasons. May even partially outdated information seem useful enough? > Does it still makes sense to have those manuals translatable on weblate? If > so, I would definitely be in favour of splitting up the weblate translation > effort in two separate projects too. Splitting into two separate projects seems to be too much work, I figure. The manuals will simply go into legacy binary packages, as per an adjusted Makefile.common and some additional files (already prepared). > If we do not want to make a definite decision now about how long we want to > keep those legacy manuals alive, within what time frame do we want to > reconsider the question whether keeping them alive still makes sense? Good question. In my opinion, the ITIL manual could stay forever, for the Audacity and Rosegarden ones, I'm not so sure if they are too outdated to be useful. Someone using these programs could tell us more, I guess. Wolfgang
Attachment:
signature.asc
Description: PGP signature