[Localization] [Proposal] .xot bundles, for translations

[Walter Bender]

It doesn't sound too invasive of a change and yet it is in keeping
with the basic update system and may evolve into a simpler framework
for end users to contribute translations as well.

-walter

On Thu, Nov 13, 2008 at 3:58 PM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
> Hello,
> One of the things in my TODO for 9.1 is to have a better mechanism for
> language packs[1] in the XO. The primary goal of language packs is to
> decouple the process of translations from the process of OS release as
> much as possible, since as our software gets larger and more
> complicated, it will become more and more difficult for translators to
> keep up with the pace of development.
> Our current language pack mechanism handles the decoupling part, but
> two of its significant shortcomings include
>
> a) Overwriting of existing translation files (it may overwrite the
> original .mo file in certain cases)
> b) Difficulty for deployments (deployments have to manual start each
> XO, and run the pack installer script from a console)
> c) No auto update mechanism
>
> I have been thinking of having a separate place in the filesystem for
> _new_ translations, and using RPM to manage the installation and
> upgradation of the new translations.
> However, Scott suggested in a recent email conversation that deploying
> new translations through a bundle like format (used for activities and
> content right now) may make more sense as users themselves can use the
> Sugar control panel to download updated translations (as currently
> done with activities). I think this may be a better option than RPMs
> as
>
> a) It makes the new translations user modifiable (we can have a
> translate activity later on which would let users modify the
> translations)
> b) It would be pretty trivial to add support for a new .xot format in
> the customization key mechanism (just unzip them in /home/olpc)
>
> However, this would need XO specific changes in glibc, python, etoys
> and scratch (I think). I already have patches for glibc and python
> (based on patches from Ubuntu, which already uses a similar system,
> where they generate language packs out of their launchpad/rosetta
> based translations)
>
> Am I missing something out here ? If there are no problems with this
> proposal, I would like to start testing such a system in Joyride (with
> at least glibc and python patched) by the end of the month.
>
> Thanks,
> Sayamindu
>
>
> [1]http://wiki.laptop.org/go/Localization/LanguagePacks
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
> _______________________________________________
> Localization mailing list
> Localization at lists.laptop.org
> http://lists.laptop.org/listinfo/localization
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org