Selon Petter Reinholdtsen <[EMAIL PROTECTED]>: > [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
