Re: [RANT] French translation for debconf templates stucked at 90% : analysis
Selon Petter Reinholdtsen <pere@hungry.com>:
> [Marco d'Itri]
> > Translations should be reviewed by the language translation team
> > before uploading, so they are supposed to have a decent quality
> > level anyway.
>
> This do not remove the need for testing.
>
> There can be charset conversion problems, dialog size limits, and
> misunderstandings only discovered when a user of the package read the
> text. It is not an option to delay upload with updated translations
> to just before a release of debian.
And I'm rather sure that the release manager will not like the fact that a whole
bunch of libraries get recompiled to update the translation just before the
release. Recompiling stuff can triger subtle bugs, can't it?
For the waste of bandwidth, it's not the fault of translators. Someone ought to
implement a diff or rsync solutions for the debian packages. Using the debsums
to prepare some kind of "update package", with only the files which got changed
also comes to mind. In the meanwhile, that's rather anoying as translator to
feel that even we do our best to help, some people don't care. Uploading a
package is far easier that translating it, isn't it?
For the waste if time on buildd, I hope you don't mean that the time of a robot
is more important than the time of the human translator, do you? Moreover,
beside some specific architectures like arm ans sparc, where the compilation of
a beast like X can last for days, I have the feeling that we do not leak
compilation power. What is missing here seem to be humans checking the results
(cf the "maybe-failed" and "maybe-successful" results of the robot).
I am thinking about a tool which could help for those two problems since a long
time, but I never had the time to actually implement it. A *very* crude
prototype is in the logs of the oldest translation bug of the french team (226
days). That's #220803, against libpam-ldap, maintained by Stephen Frost (hello
there ;).
The concern of Stephen is that in order to upload his package, he has to
recompile it, and he don't want to deal with the binary incompatibilities it may
trigger. So, the tool would take a binary package, an updated source tree, and
produce another binary package with the exact content of the previous one,
beside of the translation material (and debian changelog, debsums), which would
come from the source tree.
Such uploads could be given a specific kind of numering, such as changing the
fourth part of the package number (xx-1.0.0.1). This would even allow the buildd
to detect this fact, and do the same trick for their architecture (altrought it
ought to be done very carefully).
As I said, a proof of concept can be found in #220803, but that's very far from
being a usable implemention.
In summary, translation upload induce three problems (bandwidth, buildd,
recompilation), but theoritical solutions for all of them exist. The problem is
that very few people have both the time and the motivation to tackle them.
Translators struggle to keep there work uptodate despite the current situation,
and every people feeling concerned by those problems ends up being translator...
Any volunteer? ;)
Mt.
PS: Sorry for any brokenness of the webmail email.
Reply to: