Thoughts about separating language packs

[Martin Pitt]

Hi folks!

Today I had some time to think about separating language packs for
Hoary. I wrote down some ideas below, in a wiki-suitable syntax.

I would appreciate to get some feedback to this, especially from our
Ubuntu Dpkg Development Team (aka Scott :-) ).

Thanks in advance, nice hacking and sqash bug #1!

Martin

= Creating language packages for Ubuntu =

== Goal ==
The goal is to separate all translation and localization parts from
all packages to "language packs". Per supported language we want to
have one package which contains l10n stuff for all Ubuntu supported
packages.

In particular, the following package components are affected:

 * translations using gettext
 * translations and language elements that do not use gettext
 * debconf translations

(Details below.)

== Automatic extraction ==

There are two obvious points where an automatic extraction could be
hooked in during package build:

 1. dh_builddeb
 2. dpkg-deb
 
We currently have 1047 source packages, but as much as 265 do not use
debhelper. Although a debhelper hook would be easier, it would miss
about a quarter of our source packages, which is not acceptable.

Therefore, dpkg-deb must be modified, preferably in a general way so
that it could go to Debian, too. dpkg-dev should introduce a directory

  /etc/dpkg/dpkg-deb-hook.d/

All files in this directory are executed by dpkg-deb (with at least
the build directory as parameter) right before actually assembling a
.deb file. 

Then we can create a package ubuntu-langpacks (or so) which puts
scripts in the hook directory that do the extraction. This approach
does not clutter up dpkg itself and allows to write the scripts in
arbitrary languages.

The extraction package then needs to be installed at the buildds. The
extracted l10n stuff would be copied to an accumulation directory. The
language pack source package should automatically be able to build
debs from this directory (i. e. it should be enough to put a debian/
directory into the accumulation directory and call dpkg-buildpackage).

The last script in the hook directory can check if a regeneration of
the language packs is necessary and trigger it if appropriate.

== gettext translations ==

This part should be easy; it should be sufficient to move all files
that a package wants to install under /usr/share/locales.

Could be done with a simple shell script
/etc/dpkg/dpkg-deb-hook.d/extract-gettext.

== non-gettext translations ==

Since this must be handled on a by-case basis, it might be impossible
to catch each and every tiny bit. However, the two major cases are
currently mozilla-firefox and openoffice.org. Both packages currently
provide separate debs for languages, so the contents and maintainer
scripts should just be merged into the appropriate language packs.
A quick check showed that both should be possible fully automatically.

== debconf translations ==

This is probably the most tricky part. All translations are stored in
a single ".templates" file. It is possible to automatically extract
them, but it is difficult to dynamically add them again at package
installation. If we want to do this, we need a dpkg pre-installation
hook.

The question is whether it is really worth to separate debconf
translations in the first place. During normal installation the user
does not see any questions anyway, and I doubt that debconf
translations account for a significant increase of package size.

-- 
Martin Pitt                       http://www.piware.de
Ubuntu Developer            http://www.ubuntulinux.org
Debian GNU/Linux Developer       http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20041103/71d94921/attachment.pgp