Re: RFD: translated description with dpkg
On Wed, 29 Aug 2001, Michael Bramer wrote:
> - 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.
I don't think this is a good reason for keeping maintainers out of the loop.
I'm wary of the attitude that "the maintainer can't help us, he doesn't speak
our language and doesn't care about translations". Most developers are
interested in making their packages as good as possible, and making sure that
they serve the needs of their users, and I think it's important that
translators recognize this and take advantage of the very people who can be
the best advocates for the individual packages. Also, many maintainers may
not speak a language well enough to do their own translations, but they may
recognize when a translator has misunderstood and be able to help the
translator in this way. I would like to see a solution where this sort of
collaboration is encouraged.
I'm not suggesting that all translations must be approved by maintainers, and
that maintainers must take action before the translation is available; this
can definitely lead to delays. I agree it may be a better technical solution
to use detached translations, but I think whatever solution is found should at
least include notifications to the package maintainer.
Personally, I wonder if the /best/ solution would be similar to what we have
in the archive now for overrides file: create a central repository with all
of the translations, used by the archive, so that there are no delays in
making the translations available; but submit the translations to the
maintainer, so that they can also be included in the .deb.
> - The deb package is growing with the number of translations
> added.
The extra translations are going to take up space /somewhere/ in the archive.
Are you concerned about this specifically because of download times? Because
it takes up space on CDs, meaning resellers have to either put fewer packages
on a disk or rebuild the packages themselves, taking out the translations?
This latter point seems persuasive to me, although I wonder how much space
these descriptions will really occupy in each package. We do have debconf
translations in the packages already, after all. How many packages would be
pushed off of CD1 if we made space for (highly compressible) translations?
One? Two? Or would the translations fit in the spaces between?
> - unneeded translation on the system.
> Normal a system have only one (or maybe some) system admins (aka
> root's). The all speach the same languages (or only some). A
> german root user don't need japanese package description. He
> only need the german and (as fallback) the english description.
I don't see where having the translated descriptions within the .deb file
means they must also take up space on the end-user's system. If they're in
the .deb, they take up space in the archive, and they take up bandwidth when
downloading; but when the package is installed, there's no reason to keep
descriptions other than the ones the administrator has asked to keep...
> - if you put all translations in the same file, you'll have
> encoding problems
But this is a problem that must be solved anyway, because we currently do
this with debconf templates!
> But you don't believe, that the dpkg source code changes are small?
> Show the attachment. Martin Quinson <Martin.Quinson@ens-lyon.fr> have
> patch the dpkg source code and now we have a dpkg with translated
> description support. This is only a -9/+30 patch! you see the patch is
> pretty small.
I must say that I'm pleased and impressed by this.
> If the translated descriptions are store in
> /usr/share/locale/<lang>/LC_MESSAGES/dpkg-desc.mo and you have patch all
> outputs in dpkg and dpkg.
> Maybe somebody will now say: "But some users don't get all packages
> from debian project, there are some privat deb archives, Progreny,
> ..."
> This is not a real problem. We can collect more po files in one dir
> (maybe /var/lib/dpkg/dpkg-desc/<lang>/) and generate one dpkg-desc.mo
> file from this *po-files.
Ah. Until I read this last part, I was going to argue for a name such as
'debian-desc' instead of 'dpkg-desc', but this makes perfect sense to me. :)
Cheers,
Steve Langasek
postmodern programmer
Reply to: