Re: debian-edu-doc: reworking content of binary packages
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= 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 signature.asc Description: PGP signature
Re: debian-edu-doc: reworking content of binary packages
Hi Wolfgang, Wolfgang Schweer schreef op zo 23-08-2020 om 11:43 [+0200]: > > 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= 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. Ah, I see. I erroneously thought that you had 40% of translatable strings in mind. That's why I asked about the Swedish translations for audacity and 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? To me it sounds a reasonable compromise. If necessary, this can always be adjusted later. > > > Agreed, dropping (es) has been nagging me, too. So I did some unfuzzying > to raise the translation status. The (es) package can be kept. Good for now, but it would be good to have the Spanish translation in a better shape in the future. I will first (but not immediately, because I will be unavailable for next week) ask Rafael what he thinks is the best way to achieve this, and depending on what he says, I will ask for a translation revival on the Spanish mailing list afterwards and possibly activate Spanish on weblate than. > > > > > 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? > I think it could also work differently. When a developer prepares his software for internationalization, a translator can assume that he will welcome translations. The same could apply to the debian edu doc manuals. When we submit the documentation for translation (via the Debian localisation infrastructure and/or via weblate), it implicitly suggests that we find translations of it meaningful. In my opinion it is up to Debian Edu doc maintainers to eventually decide whether keeping manuals open for translation still makes sense. > > 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). Adding a "Debian Edu Legacy Docs" translation project to weblate wouldn't be that much work, I hope, and it would be clearer for possible translators that those documents are more or less obsolete. This would make it easier for translators to set priorities. > > > 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. Back in 2014 when I started to translate Debian Edu documentation, I asked for it (https://lists.debian.org/debian-edu/2014/04/msg00040.html). According to Pere translating rosegarden still made sense, while he was in doubt about audacity. At that time the ITIL anual wasn't translatable yet. While the latter contains some valuable timeless information, it also has a lot of outdated stuff. Also documentation must be constantly updated to protect it from becoming obsolete, I guess. -- Kind regards, Frans Spiesschaert
