Translation refresh

[Bernie Innocenti]

On Sun, 2008-04-20 at 18:54 +0530, Sayamindu Dasgupta wrote:

> I don't think it makes sense to make seperate releases _only_ for
> translations.

Why does rolling a release seem to be such a big thing?
Generating a new OS image takes 10 minutes of machine time
and this is as simple as it can get.

All the other steps our release procedures that create overhead
assume some amount of testing is necessary before a new OS hits
users.

But if the only thing you change is translations, it doesn't
matter whether you're doing it with a new OS image or through a
separate language pack.  The resulting system will in both cases
be the old one plus these new strings.  And this is what you
have to retest in both cases.

What we need is a fastpath in our procedures for this case.
I think we had something adequate for security updates.  Michael?

<sidenote>
Our friends here told me that we must urgently translate the word
"Pippy" because apparently it has a very inappropriate meaning in
Turkish :-)
</sidenote>

>  I am currently working on a language-pack builder for
> deployers and testers, which would  generate language packs for
> different releases (eg: Update-1, or Joyride), etc. This should
> separate the release process substantially from the translations, and
> deployers can add enhanced language packs for the deployed systems as
> the translations evolve.

This would add yet another degree of implicit dependencies to our
system.

The way I see it is that we already have a very dangerous situation
where Sugar and the activities can freely vary with respect to each
other with no robust dependency tracking.  If we also add translations
to the equation, we're making it much worse.

Then you get bug reports such as "I don't get a string translated to
Turkish", you'd have to ask the user:

 - what OS release?
 - what activity version?
 - what language pack?

Unless we plan to switch to a true package manager, we can't modularize
things too much.


> However, to make this work we also need to follow some kind of
> branching policy wrt the releases (eg: once Update-1 is released,
> bugfixes targetted for subsequent minor releases f'd uor Update-1 should
> be committed to the Update-1 branch only, while development for
> Update-2 should continue in the devel branch). This has to be done for
> _all_ activities (and of course, the components of Sugar as well).

Yes, this is what is being done already for Sugar and many other
packages hosted on dev.laptop.org (although there's no policy that
mandates it).

-- 
  \___/
  |___|  Bernie Innocenti - http://www.codewiz.org/
   \___\ CTO OLPC Europe  - http://www.laptop.org/