Language support summary/discussion

[Martin Pitt]

Hi everybody!

In yesterday's meeting we had a rather lengthy and multithreaded
discussion about language packs. This is a summarizing of the topic
and an invitation to discuss this further since many questions are
still open.

(1) Which language packs should be shipped on the install CD?

According to [1], the most widely spoken languages in the world are:

      Language (#native speakers)       langpack size
   1. Chinese* (937,132,000)		3379218
   2. Spanish (332,000,000)		3181222
   3. English (322,000,000)		2654930
   4. Bengali (189,000,000)		 610776
   5. Hindi/Urdu (182,000,000)		 513176
   6. Arabic* (174,950,000)		 747176
   7. Portuguese (170,000,000)		4018494
   8. Russian (170,000,000)		2217870
   9. Japanese (125,000,000)		2556682
  10. German (98,000,000)		3174524
  11. French* (79,572,000)		3306650
 
These account for approx. 30 MB worth of language-pack debs (if you
leave some room for update packages). OTOH, the ongoing stripping of
translations from application debs should already have saved lots of
space, so that the addition of some language packs should not enlarge
the overall CD compared to Warty.

A broad consent in the meeting was to add langpacks from the top of
the list until 20 MB are reached. (Unfortunately that would rule out
French and German :-) ) The other proposal was to add languages by the
popularity of Open Source, not by the number of native speakers.

Another general consent is that we don't ship support packages (and
their dependencies) on the CD, they just don't fit.

[1] http://www2.ignatius.edu/faculty/turner/languages.htm

(2) How shall we eventually map the three different use cases of
foreign languages to the metapackage structure?

    a. Reading foreign languages: this is mostly a matter of matching
       font packages.
    b. Creating content in foreign languages: This requires input
       methods, dictionaries, etc.
    c. Localization: This requires application translations.

These use cases are concentric, with a. being a subset of b., and b.
being a subset of c. 

Ideally, this relation would be reflected in the dependencies, however
that is tricky:

Currently our goal is to provide a basic set of fonts in Desktop to
fulfill a. everywhere (are the current fonts enough?). 

Then we have language-support packages (for b.) and language-pack
packages (for c.); these two recommend (but not depend on) each other.
l-pack-foo must not depend on l-support-foo, since otherwise we could
not ship l-pack-* on the CDs (the dependencies are too big). OTOH
l-support-foo should not depend on l-pack-foo since a./b. don't imply
c. (and shouldn't force to install translations just to get a few
dictionaries).

(3) For Grumpy^W Bbb..., Bbbenn..., Hoary+1 we need a nice and
colorful frontend for selecting various grades of language support
(a/b/c). This should be a small pygtk application integrated in the
Desktop/System Management menu.

(4) Installer: Right now the standard mode just tries to install
l-pack-foo and l-support-foo that matches the language that the user
selected in the very first question. 

However, in expert mode there is a multiselect question that allows to
install additional languages/locales. The idea was raised to show this
question also in standard mode. Personally I think we should keep the
status quo since support just for the main language will be fine for
95% of the desktops out there (especially if we have (3)).

(5) It was proposed to always install the English language pack (i.
e. move it from Ship to Desktop). However, there was no justification
for that in the discussion, so why should that be done?

Right now it does not make much sense to me. An user which selected
English as his primary langugage in the installer will get teh English
pack anyway. OTOH a French user will not see English texts as a
fallback if there is no French translation even if he has the English
language pack installed; he will see the C strings instead.

Thanks in advance for any thought, and have a nice day!

Martin
-- 
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/20050216/181903a1/attachment.pgp