[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Translations, locales and gconv



On a typical Gnome installation, /usr/share/locale/ can take up 250Mb
or more (those who attended the Emdebian talk at DebConf7 will have
heard how Emdebian currently handles this problem). [6] [7] [8]

This is one of the changes sought by Emdebian to support using Debian
on embedded devices where storage space is far from cheap and involves
running counter to the current Debian default of "install everything
that works, every time, every package".

http://lists.debian.org/debian-devel/2007/11/msg00116.html

A similar issue affects the glibc gconv support and the tzdata zoneinfo
support - both packages include files that need to be removed on
devices that have no translation/locale/tzdata requirements and both
need to have some form of set selection support for devices that can
only support one or (at most) less than 6 actual translation/locale
configurations. e.g. where en_GB, GMT, BST, ISO8859-1 and UTF-8 would
form a collective "set" of packages that provide the necessary support.
Extending that to include 'fr' could then simply be a case of
installing suitable translation packages that provide those .mo files
without providing any others.

The interim method used in Emdebian currently is unsustainable because
it increases the number of binary packages tenfold which has
unacceptable consequences for the dpkg and apt cache size if the
translation packages are included into the main repository. It is,
however, manageable for the small subset of packages currently in use by
Emdebian.

This thread will seek a sustainable method that separates the
translation files and all gconv and zoneinfo support into a dedicated
structure, outside the normal $mirror/debian main archive layout, such
that Debian can support installing all translations (as now), no
translations (for Emdebian on a router etc.) and any permutation of
translations, appropriate gconv support and any mix of zoneinfo support
that would be appropriate for an embedded device like a PDA or
smartphone etc.

Such a system would also be ideal for allowing translators to upload
translation updates without needing a package upload by the maintainer.
In due course, I would wish to see the presence of /usr/share/locale/
in a package in Debian main as an RC violation of Policy. It would also
be good to discourage non-gettext methods of translation to enable
support within the new system.

I am therefore seeking a second layer of repository structure that
removes all /usr/share/locale/ data from all packages in Debian,
creates language-specific packages for each individual .mo file from
each individual package and allies those to individual packages for the
gconv files from glibc and the zoneinfo files from tzdata into a system
that can provide two implementations:
a) Current Debian of install everything anyway
b) Necessary Emdebian route of installing ONLY the translations that
match the locale with appropriate gconv support and zoneinfo support
with a debconf frontend to add extra locales and necessary support so
that any user can specify that only en_GB, fr and sv should be
supported etc.

This second layer would need separate dpkg and apt cache data.

Ideally, the cache data would also be subdivided so that an embedded
device supporting translations would not need to even have cache data
for locales that were not listed in a form of apt sources list.

It may be possible, for example, to support a repository component for
each locale name and that component would contain all necessary
packages (or links to them).

[6] http://linux.codehelp.co.uk/emdebian/debconf7/htdocs/img9.html
[7] http://linux.codehelp.co.uk/emdebian/debconf7/htdocs/img13.html
[8] http://linux.codehelp.co.uk/emdebian/html/ch04.html

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpXH7RtcoDch.pgp
Description: PGP signature


Reply to: