here's my take on the l10n story for the new development process:

- the long tail of localizers need a simple story, dead on simple, really.
- our development community needs help to not break l10n early.

Let me start with the latter:

We already have a few localizers that work very close to mozilla-central
[1], and interact with our development community in bugs. We need to
keep this up, and find and fix issues for l10n (and rtl) before we put
the work out to the long tail of our l10n community. I plan to formalize
this a bit, and have only those locales bother with mozilla-central at
all. That may be a hand-full or two. Going forward, I also would like to
get this community to respond to project branches, maybe even localize
project branches. Also, I'm part of that group, at least as far as
responding to requests in bugs go.

=> a limited number of locales track mozilla-central. The rest doesn't
exist there at all (?).

On to the dead-simple story for the majority of our localizers, that
should hopefully turn out to be:

wake up on calendar alarm, and
  pull mozilla, pull l10n/ab-CD,
   hit whichever l10n tool
   land, push
   get builds, with nightlies to testers
   rinse, repeat.

The hope is that for the most part, localizers won't need to bother with
repos on an earlier stream, or a later stream. They'll just stay put
like a sea-devil and bite any string that swims along.

The whole cycle should be doable in a weekend, aka, 2-3 days. That as a
boundary condition to how/why/when we generate and publish localized builds.

The proposed procedure also has the benefit that it's dead simple to
document, and that the documentation doesn't change. Easier for me (and
the communications guy we want to hire), for localizers, for external
infrastructure like narro or ANLoc's pootle.

The right channel for this procedure seems to be -experimental, after
talking to legneato.

=> All locales work on experimental to get their localizations ready to
ship. Sign-offs stay, and happen here.

Now a few fall-out items:

=> There shouldn't really be all that much traffic on beta at all.

We should probably take fixes, still, but whether those should be
marshaled by a release driver or if that tree is owned by localizers, no
idea. Might be worth to reconsider here at some point down the road.

=> Beta-only locales don't end up on release.

Right now, we have that funky setup where new locales in Beta are
regular release builds, just with a different flag on the website. I'd
like to get rid of that. Just have them in Beta, and once they mature,
pull them into the next release, perhaps even platform dependent?

Comments?

Axel

[1] http://hg.mozilla.org/l10n-central/fr even shows the en-US check-in
messages, for example.