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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/localization > -- Walter Bender Sugar Labs http://www.sugarlabs.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
