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=<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.
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
Reply to: