Hi.
This architecutre would be great, even for language like mine that we
don't expect official deployment in near future.
my comments will follow in lines...
On Fri, Jul 11, 2008 at 11:51 PM, Sayamindu Dasgupta
<[EMAIL PROTECTED]> wrote:
> 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.
Pre-generation is good, but I think shipping also source POs would
be better for consistency as we have old POs in activity bundles.
And with POs in sync we could see version of translations that are
installed.
> 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.
Agreed.
> 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
I think for some languages also input method like SCIM (and its
configuration) would be needed, and it will be installed as RPM also.
> b) Locale data support: Sometimes glibc locale data need to be added
> to the system for supporting a particular language.
>
>
> --
> Sayamindu Dasgupta
> [http:/
