Re: (my) summary about translated description with dpkg (still RFC)
On Thu, Aug 30, 2001 at 09:58:59AM +0200, Martin Quinson wrote:
> The more controversial point of our proposal is that we where planing
> to centralize the translation in a way that keeps the maintainer out
> of the loop. But it's not the key point, it's an add-on which ease the
> work of translators. Each package can still provide the translation
> and be 'self contained'. For the MIA maintainers, or the ones not
> willing to interfere with the translation stuff, the po file providing
> the translation is in a translator-maintained package. There is no
> dependency between the formal package and the translation one. The
> second enhance the first when installed. When no translation is
> installed, the system will be the same than it is now, and will
> display the description in good old english.
I've got a suggestion regarding integrating the translations into the
packages themselves. Instead of having package translations which the
user has to install and are not included in the actual .deb, what about
generating and using package translation -dev packages in the same way
that e.g. autotools-dev is used to automatically integrate files
(config.guess,sub) that are maintained elsewhere into packages as they are
built by the maintainer or buildds?
The package translations would be used to generate -dev packages that
would be installed into the archive along with all the other tools that a
developer (not a user) needs. Maybe the package translations could be
split by something like archive section to keep the size down. The
developer would be able to keep these 'source' translations up to date
using existing infrastructure (apt-get update etc.)
At package build time, a dh_ helper script could be used to integrate the
translations into the newly built .deb, which is uploaded to incoming as
usual. You now have translated descriptions integrated into the .debs,
and it is possible to generate the Packages.<lang> files for use by the
modified dpkg/dselect as was originally suggested, except that the
translations are coming from the .debs instead of a single server.
Now this doesn't solve the possible bloat issue of a package containing
multiple languages - but that's something that needs to be solved along
with all the other types of translations that are put into a .deb (debconf
templates, program messages etc.). But at least the package translation
case is no longer such a special case, with a completely different way of
handling it. And the user's machine no longer needs to do .po file
merging from a central source, since the translations are distributed
along with the .deb in every case, not just the case that the maintainer
wishes to do the translation themseleves or it comes from another source.
Putting the maintainer back in the loop does have a cost - the time taken
for them to re-upload the package once the translation has been integrated,
and the resulting bandwidth and cost to buildds etc. But maybe that's a
problem that should be solved along with the other translation areas that
have the same issues in the .debs? At least by automating the translation
integration, you make the loop a lot smaller. And another advantage: A
user building a package themselves from the source packages ends up with a
.deb which includes the translated descriptions.
Would would need to be done to implement this?
- Translation server needs to generate packages with translations that
are put into the archives
- helper scripts modification to integrate translations into package
build process
- the scripts to generate Packages files from .debs need to also generate
Packages.<lang> files
- dpkg/delect patch to be applied
Chris
Reply to: