[Sugar-devel] some efforts that would be really useful for deployments

[Sayamindu Dasgupta]

On Thu, Nov 26, 2009 at 7:18 PM, Gary C Martin <gary at garycmartin.com> wrote:
> Hi Sayamindu,
>
> On 25 Nov 2009, at 16:55, Sayamindu Dasgupta wrote:
>
>> On Wed, Nov 25, 2009 at 9:47 PM, Daniel Drake <dsd at laptop.org> wrote:
>>
>> <..snip snip>
>>
>>>
>>> Another constant headache is with translations. How do you roll out new
>>> translations for old software? The best we have right now is language
>>> packs but they install files which conflict with both system packages
>>> and activity bundles. And they are difficult for deployments because you
>>> need Linux skills to execute them.
>>>
>>
>> For Sugar 0.88, I will be doing an extended gettext as sugar.gettext
>> which will allow parallel installation of translations (and will get
>> priority over the translations in the activity directory). In that
>> way, we may at least ensure that there is a clean way to upgrade
>> Activity translations.
>
> I'm curious, is there something flawed with the current process where deployments add translations to pootle via translate.sugarlabs.org so strings are pushed over to activities held in git.sugarlabs.org ready for re-release? Will this new mechanism lead to new activity releases with new translations being over ridden by old translation files installed in parallel by deployments?

I think Michael already provided a nice explanation, but anyhow,
here's a rationale from my side.  Currently, activities in string
freeze (for example, Fructose activities for 0.84) will seldom see
releases from the sucrose-0.84 branch. Now translations (especially
for the non European languages) often happen in large scale only when
a deployment is announced.
So, if OLPC has a deployment coming up in country X, translators in
country X will start work on branch 0.84, which does not see any
release.

Currently, we deal with this by languagepacks which install the latest
PO files from Pootle into the activity directories (overwriting the
existing ones), which is not a clean solution. We need some way to
decouple the translations from the release process, and this is my
proposed way of doing it. I also have patches for glibc, which would
deal with the translations handled by glibc gettext, but I did not get
any response from upstream about it (I sent a mail). I'll poke again
later (this time with a proper enhancement request in bugzilla).

The core idea is to allow deployments to update the translations
without developers having to do new releases.

Thanks,
Sayamindu

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