[Localization] [Proposal] Extending the USB key customization mechanism to add (or enhance) translations

[Sayamindu Dasgupta]

Hello,
Below is a brain dump of my thoughts regarding a mechanisms to add
support for a particular language (mostly wrt translations right now)
_after_ an OS release has been made.
This is a very rough, first draft, and comments, suggestions,
brickbats are more than welcome :-).
Thanks (and apologies for the cross posting),
Sayamindu

****************

Translations directly relevant to OLPC can be divided into two categories
1) Non activity translations (specifically - translations for sugar,
sugar-base and sugar-toolkit)
2) Activity translations (example: translations of Pippy activity,
Record activity, etc)
A major difference in the translation of these categories lies in the
filesystem path in which the translations are to be installed. For the
first category, the translations are to be installed in
/usr/share/locale, while for the second category, the translations are
to be installed in /home/olpc/Activities

My proposal is to extend the bundle installation capability of the
customization key, and make it install translations as well. Currently
the init process in the customization key looks inside the bundles
directory of the USB drive, and iterates over the .xo files,
installing them in /home/olpc/Activities  As per my proposal, it will
also look inside a directory called l10n, whose structure is shown
below (we are using a hypothetical Marathi (language code: mr)
deployment as an example):

.
`-- l10n
    `-- translations
        |-- activities
        |   |-- Journal.activity
        |   |   `-- locale
        |   |       `-- mr
        |   |           |-- LC_MESSAGES
        |   |           |   |-- activity.linfo
        |   |           |   `-- org.laptop.JournalActivity.mo
        |   |           `-- activity.linfo
        |   |-- Pippy.activity
        |   |   `-- locale
        |   |       `-- mr
        |   |           |-- LC_MESSAGES
        |   |           |   `-- org.laptop.Pippy.mo
        |   |           `-- activity.linfo
        |   |-- Read.activity
        |   |   `-- locale
        |   |       `-- mr
        |   |           |-- LC_MESSAGES
        |   |           |   `-- org.laptop.sugar.ReadActivity.mo
        |   |           `-- activity.linfo
        |   |-- Web.activity
        |   |   `-- locale
        |   |       `-- mr
        |   |           |-- LC_MESSAGES
        |   |           |   `-- org.laptop.WebActivity.mo
        |   |           `-- activity.linfo
        |   `-- Write.activity
        |       `-- locale
        |           `-- mr
        |               |-- LC_MESSAGES
        |               |   `-- org.laptop.AbiWordActivity.mo
        |               `-- activity.linfo
        `-- sys
            `-- mr
                `-- LC_MESSAGES
                    |-- sugar-base.mo
                    |-- sugar-toolkit.mo
                    `-- sugar.mo

There are two directories under l10n - one called sys, and the other
called activities. The sys directory contains the translations for
Category 1, while the activities directory contain the translations
for the activities. All files are pre-generated (eg: activity.linfo,
or .mo files) - since that would filter out malformatted PO files
during the USB key creation process.

The init script has to essentially do
cp -r /mnt/usb/l10n/translations/activities/* /home/olpc/activities
cp -r /mnt/usb/l10n/translations/sys/* /usr/share/locale


For creating of the layout above, I plan to supply a utility which
will automatically generate this hierarchy - given a list of
activities, the release being targeted and the language.
A very crucial assumption which this approach takes is that newer
translations are always better than older ones. This is true in almost
each and every case I have seen.

Some open items remain:
a) Fonts: We currently tend to cover almost all the scripts that we
target with our current installation. However, in the future, adding
support for a particular script might be a part of the job. If we come
up with a mechanism of installing RPMs as a part of the customization
key, I believe the problem will be solved
b) Locale data support: Sometimes glibc locale data need to be added
to the system for supporting a particular language.



-- 
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]