Reasons why package central approach to handling translations may be suboptimal
Hello,
I have been reading the DDTS thread, and seeing that it was resolving into
a "each package should maintain their translation". I would like to
present what I think may be problematic in that approach :
1. This results in filing random bugs in BTS in random manner. Telling the
submitter to re-submit in a more useful format, and not gettinga response
is bad. Many of the debconf translation "bugs" have translated text
inserted in the mail body. It should really be an attachment if it were to
be handled sanely, to preserve the intended encoding. (for example,
Japanese mail is in ISO-2022-JP, while debconf data should be in euc-jp).
BTS doesn't seem to like attachments either.
2. A package is re-uploaded with translation. There is a package
uploaded with one-line changelog saying something like
"Merged spanish templates". It is a load to
autobuilder/ftpmirror/etc. and of course manual intervention
to rebuild a package means that an error occurs, and it does.
The main problem here is that translation start after the initial
upload of packageto Debian happens, which means there will be
a "-2" Debian package which will include the translation, and
a "-1" Debian package will have no translation.
3. No choice of "I want this locale and not others".
This is the reason I think the translation data would be
better off maintained outside of usual packages.
regards,
junichi
--
dancer@debian.org http://www.netfort.gr.jp/~dancer
Reply to: