Re: RFD: translated description with dpkg
On Wed, Aug 29, 2001 at 11:14:38AM -0500, Steve Langasek wrote:
> 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.
If the package adds a file to /usr/share/dpkg/descriptions/LANG/ (or
whereever we decide to put theses files), and call update-dpkg-description
(or what ever name we choose when implementing it), it should do the trick.
> > > 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.
Sorry, I misunderstood. If the maintainer receive a notification mail, and
have a veto right in the ddts, whould it seem ok to you ?
> > > 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.
20 days is not that bad... :)
> 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?
That's a problem the Debian Commitee should handle, I think. I can't help
you, I'm not even a Debian Developper ;)
I suggset a new category called 'l10n' (or at least a new tag). So, it will
be easy to see which bugs are of this kind. And then ? Would it be
acceptable to do massiv NMU to fix such problems ? I don't think so.
But I think you understand why we choosed the centralized way, even (or
because) it takes the maintainer out of the loop. That's sad, but good
translators don't have to be blocked by overhelmed maintainers.
I do translate some packages on a regular basis, and I have good contact
with some maintainers, which reupload their package each time I change
something in the french translation. For some other packages (and
maintainer) it's a nightmare between to get coordinated between translators
so that the work is not done twice just because the first version is rotting
in the BTS. The worst case is when the submited bug get so old that the
translation get outdated. In such case, we have to extract the old version,
update it, and resubmit it. See for example #93444, which were updated in
this mail,
http://lists.debian.org/debian-l10n-french/2001/debian-l10n-french-200108/msg00175.html
but nobody merged the review to the original version because it does not
seem it will be integrated to the package.
(To be honest, this problem is a bit more general than the one we discussed
before since the problem is the po file of a package with an upstream
source)
That's really hard to keep motivated as translator in such conditions.
Bye, Mt.
Reply to: