[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFD: translated description with dpkg



Michael Bramer wrote:
>  With a hack, this translated description are now also suitable. Daily
>  the server make translated Packages files on gluck and you can use
>  this with apt-cache [search|show] and without other sources in apt's
>  sources.list also with all apt based tools (dselect, gnome-apt, etc.)
> 
>  For more information, see the gifs, guides, faq's etc. on
>  http://auric.debian.org/~grisu/ddts/

FWIW, I think you all have done some very good work here, and done a
masterful job of getting the ball rolling on this issue, that has been
stuck far too long before. But, I agree with you when you say it's a
hack.

[ putting translations in package ]
> This has some heavy cons:
>     - this way will by very slow. We will never get all translation in
>       all packages. The maintainer will collect some translation
>       before make a new upload. All packages must build from the build
>       servers. This all delay the process. Every selling error
>       generates uploades, builds, ...
>     - No package maintainer can't speaking all languages. He can't
>       check the translation, he can't improve the translation, he only
>       add blindly the translation in the package source. This is 
>       unneeded work for the maintainer.
>     - The deb package is growing with the number of translations
>       added.
>     - unneeded translation on the system.

I just want to point out that every single one of these cons applies to
the standard mechanism used to translate messages in programs in Debian
packages and in the GNU system in general. That is, po and mo files.

I would think that translating programs themselves is of greater utility
in the end that translating package descriptions[1]. And it tends to be
more work to translate all the messages of all the programs in a package
than it does to translate a single, simple, package description. So not
only do these cons apply to po files, but they apply even more strongly.
And I don't see anyone seriously proposing that we throw mo files out of
Debian packages and download them seperatly. Why not?

Well, one reason is that many packages are translated upstream, and so
we don't feel the weight of all the cons. The cons are still there;
upstream gets to deal with some of them though. And they can still
easily reach into Debian and bite maintainers: Fix a message -- oops,
now you have to fix all the translations from upstream as well. And of
course other cons like package bloat and unneeded translations on the
system are still there, and we deal with them. Nobody said that
maintaining a package would be a trivial job. You have to communicate
with people. You will run into stuff you don't understand, and have to
pass it to upstream -- and trust upstream. (Upstream for translations is
the translators that provide them.)

Another reason we don't split out mo files from debian packages is
because we have a clear idea about what a debian package is[2], and mo
files are clearly an appopriate part of a debian package. And it turns
out that this concept of a debian package, that we use consistantly for
all sorts of things throughout debian, makes debian a much more powerful
system. Oh sure, we could ship kernels as build-your-own-source
tarballs, and let users browse package documentation on
http://docs.debian.org/ rather than include it in a package, and ship
maintainer scripts outside of debian packages, and use LDAP to look up
package maintainers, and provide yet another mechanism for downloading
translations. And that would be an unholy mess, so instead we shoehorn
docs and translations and everything else that fits in our concept of a
debian package, in the package. And our users thank us for it.

I think that splitting mo files out of debian packages and distributing
them seperatly would be insane[3]. I think it would create a level of
confusion and mess that would make me very glad I am a mere mono-lingual
'merkin.

I think that continuing to keep translated package descriptions out of
packages will lead to the same manner of confusion and mess in the end,
though it will be of a lesser degree, because translating package
descriptions is less far-reaching than localizing programs. It's not
insane, but have you really thought it through? What makes package
descriptions so special that they must be treated in such a different
way? How does treating them in such a different way gain us much of
anything, when we still have to deal with all of your cons as applied to
po and mo files?

-- 
see shy jo

[1] I don't really know, since I don't use translations. I just reason
    as follows: I use a debian package translation once or twice. I use
    program messages many times each day.
[2] And no I won't try to articulate it here. :-P
[3] Unless, that is, they are distributed in other debian packages. The
    kde i18n packages are ugly and I've ranted and railed about them, but
    they at least fit within the overall debian packaging system.



Reply to: