Re: RFD: translated description with dpkg
On Wed, 29 Aug 2001, Martin Quinson wrote:
> 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...
This still means there's no way for someone to get description translations if
they have just a single .deb that they're distributing; if I understand
correctly, they must also set up the infrastructure of an apt-gettable
archive, even if they have no interest in doing so. Being able to include the
.mo files /within/ the .deb has advantages for `projects' that consist of only
one package.
> > 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.
This addresses the issue of outdated translations very well. It does not
address the issue of (deliberately) inaccurate translations, which is what
David was getting at.
> > 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.
I would like to be able to disagree with you, but I know this is a real
concern. I let a debconf translation sit as a bug against my package for over
20 days before doing anything about it -- it was a post from Grisu /talking/
about such delays that reminded me the translation was there and shamed me
into acting.
It doesn't make sense to wait on maintainers for translation availability if
there are other ways.
> 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...
Switching tracks here slightly. Is it reasonable to raise the severity of
these bugs? It's certainly polite to the maintainer to file these bugs as
wishlist, because naturally there are many bugs that are more important than
translations (since today, most administrators of Debian machines have at
least some English comprehension, so lack of translation does not make most
packages unusable). However, I think it's *because* these bugs are filed as
wishlist bugs that maintainers allow them to languish for hundreds of days.
What priority can Debian as a whole assign to this issue in order to help
encourage developers to keep debconf translations up-to-date?
Steve Langasek
postmodern programmer
Reply to: