Re: RFD: translated description with dpkg
On Wed, Aug 29, 2001 at 09:14:26AM -0500, David Starner wrote:
> On Wed, Aug 29, 2001 at 02:56:51PM +0200, Michael Bramer wrote:
> > Principally we can go two ways:
> > - decentral translation
> >
> > We don't see real pros of this.
>
> How about the facts that the description travels with the deb,
> so I can mail you a deb and you get the descriptions appropriate
> for your language, whether or not you have access to any Package
> files. What about the fact that decentral translation lets Joe
> Bob release a deb with multilingual descriptions, whereas the
> central translation only lets Debian and people willing to
> set up a Packages file to release it.
Grisu explained a way to do that, I think. Instead of releasing preformated
.mo files, it would be possible that each project building packages put a po
file somewhere under /usr/share/dpkg-desc, and then all these files are
merged. So, this approach is more a centralized way within Debian,
decentralized for others...
> It also takes power over
> the desription from the developer; a description could be inaccurate
> or derogatory and there's nothing a developer could do about it.
Not quite true. If you change your description in english, the gettext
mecanism will notice that the translations are obsolete and use the original
version. And, as someone else noticed, the developper can use the ddts mail
server to modify the translation, too.
> Most developers are at least bilingual (unless I'm underestimating
> the monolinguage English-speaking contingent), and could probably
> understand many Latinate/Germantic languages well enough to pick
> out something really wrong and find a dictionary to check it out.
> A misformated description - 3 bullets changed to 2, or the like,
> could be seen in almost any language description by almost any
> developer.
That won't happen since the translator should not get the whole description
to translate, but a splitted version. He will face one string for the short
desc, and one per paragraph in the long version. Note that it may not be
implemented in the current version of the ddts, but that's it's pretty easy
to do.
We could also change the ddts mail server so that it mails new translations
to the maintainer for review. We already have it mail any new french
translations to the french l10n ML (don't we, grisu ? ;). So, the maintainer
would have a sort of veto on translations. The translation won't get blocked
until the maintainer says ok, but he can remove a wrong translation.
> You know, my general response to a report on a subject with one
> side only positives and one side only negatives is to discount
> the report; it's obviously not objective in any way. Not that I
> disagree with your solution; I just think you should understand
> the disadvantages and be honest about them.
Sure, and I think Grisu, I and the other peoples involved in this area are
open minded. But our experience with debconf templates and regular po files
do not encourage ourselves to submit wishlist bug reports.
See for example #87698 (a 187 days old fr.po file for bug) or #90574 and
#93444 (160 and 141 days old fi.po and fr.po for fileutils) or #83482,
#83767, #83925, #83926, #92373, #92841 and #93227 (several debconf template
translations for lynx, between 240 and 120 days old). There are only some
examples between others. In fact, the translators may have the feeling that
there work within Debian is mostly rotting as wishlists in the BTS...
That's why we choosed this centralized approach. The most important to me is
that a simple -9/+30 patch can reach what is needed to have translated
descriptions in dpkg and dselect. Any other approach would lead to a policy
modification, and a more in-depth modification of the tools used (and the
re-upload of each packages to get the translation in it). So, it won't be
possible for woody+1 (as our solution can be), but for woody+2 or +3, or
even never.
Bye, Mt.
--
Un clavier azerty en vaut deux.
Reply to: