Date: Fri, 2 Sep 2011 11:14:13 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] [RFC] Language packs
Message-ID: <20110902111413.2398fdaf@ncopa-desktop.nor.wtbts.net>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I would like to split out language support packages.

Mainly because in many situations you you don't want language support
at all (routers for example).

In other cases you might want support for one or two languages but not
all (error messages for squid? desktops?)

The very nice apk-tools feature "install_if" will allow us to do things
like: 'apk add lang-no' to install Norwegian language(s) and locales
for all applications providing such support. That is actually already
working in in current abuild, even if no apkbuild uses it. You can just
set 'linguas="no es" and it will automatically create
$pkgname-lang-no $pkgname-lang-es with proper install_if.

However, I don't think we want subpackages for every single language
since there are potensially thousands of languages, so we want group
them in some way. And we want be able to group them automatically with a
script, so each maintainer don't need to deal with 30+ different
languages for each package.

The big question is how do we group them?

I see the following options:

1. we group by ISO 639-1 (2 char codes). 
http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
This means we get packages like: squid-lang-no (which might hold no.nb
and no.nn for the 2 different norwegian languages). $pkgname-lang-en
would hold both en.GB and en.US. *-lang-es would hold spanish for both
spain and southamerica. I think this is the easiest way to do it, but
this might cause number of packages double in our repos. (or triple? i
don't know).

2. we group by first letter. For example $pkgname-lang-e holds english
(en) and spanish (es) and all other languages starting with 'e'. This
will give us fewer groups and is easy to implement from scripts. If you
want finish packages, then you apk add lang-f and you will get french
too even if you dont need it.

3. we group by language family.
http://en.wikipedia.org/wiki/List_of_language_families
This means we need some kind of database that can put the language dirs
in correct group. To install your language you will need to know what
family it is in and install it. For finish and swedish it would be
something like: apk add lang-uralic lang-indo-european

4. we group by continent.
With this its easier for enduser to pick the language. For norwegian
and finish it would be: apk add lang-europe. You would also get
hungarian and german. This means logs of work figuring out what
continent we put each language and create a database. Where do we put
spanish? lang-southamerica or lang-europe? French? lang-europe or
lang-africa?

5. you get all or nothing.
With this we have a single subpackage for each package with all
available languages. It means basically that you can enable all
languages or none with something like: 'apk add language-support'. You
could also add all languages for specific package: 'apk add
$pkgname-lang'

6. we don't bother split out language packs at all. Just ship them with
the main package and we don't bother the wasted space for unused
languages. This basically means: Do nothing. Let it be like it is now.

I think that the only practical solution would be either option #1 or
option #5.

What do you think?

Do we have other alternatives?

Thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---