On Thu, Nov 26, 2009 at 7:18 PM, Gary C Martin <g...@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 <d...@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] _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
