Source L10n for extensions (ChatZilla, venkman and others)

Hi,

[Posted to dev-l10n as well as ChatZilla and venkman groups and 
owners/peers; please follow up to the dev-l10n group/list with 
discussion, reactions and followups, so everyone affected can read all 
of this discussion in one single place]

You might have seen my recent rush for ChatZilla and venkman source 
L10n, and I admit I probably was too eager to get something going that I 
stepped on a few people's toes. I want to start a discussion with this 
post now to get this all solved the hopefully right way, with 
participation of everyone directly affected by this.


I've been informed that what we need for any addition to the L10n CVS 
mechanism is a proposal on what's expected to work, and what is not, and 
who's expected to do what (Axel called that "concrete agreement" or 
"concrete contract" in bug comments).
This means that everyone should know how it affects 'hourly' builds, 
nightlies, release builds, and language packs and what release manager, 
extension author, and localizers are supposed to do in the process for 
the added locale strings of those extensions - in this case ChatZilla.
The contract/agreement should also tell what is supposed to turn the 
build red, what turns the build green, when something gets shipped, when 
not - everything one needs to know about how our processes will/do work.


I will NOT post this contract here because we obviously need the 
extension author(s)/owner(s) to agree. I'm posting my intentions here 
and a way how I propose we can move forward on this. This should be a 
base for discussion, not something anyone reasonable has already agreed 
with - just to make this clear from the beginning.


My main target here is to enable us to ship SeaMonkey 2 in a fully 
localized fashion, including ChatZilla and possibly venkman, but not 
force localizers to provide those extensions in their language.
As DOM inspector and reporter have other ways of providing L10n which 
work in a way that we can ship in a way where a user get them to display 
in their language, my planning has no priority for them but should 
include figuring out a system that could be applied to them later 
(possibly only after the 1.9 cycle that SeaMonkey 2 is based on).

So, the highest priority for me is to get localized SeaMonkey 2 (trunk) 
working with optionally localized ChatZilla (and possibly venkman).
If it's easy and nice to do, we should figure out and possibly enable 
some way of L10n for XPI packages for those extensions as well as 
SeaMonkey builds created with --enable-ui-locale and langpacks.

Localized SeaMonkey 2 is created via repackaging, which takes an en-US 
build and replaces its various localizable content with resources for a 
different language. Unfortunately we don't have machines running yet 
that would do this in an automated fashion, so my first attempt was for 
getting --enable-ui-locale working and I figured out a way that would 
make some kind of localized XPIs possible.
While the locations of the en-US and actual L10n files are the same for 
all those ways of L10n, the Makefile and XPI creation changes might be 
more or less different. In this way, my first take on this problem 
probably wasn't ideal - but at least the locations of the ChatZilla 
files in CVS are correct. So far, so good.
I'll probably work on getting one of my private trunk tinderboxen to run 
that repackaging stuff so I can get some idea of what changes we need to 
get this working correctly.

I don't know for sure yet, but what we might need there is to have 
localizations for the extensions in different files from the extension, 
or at least have the non-en-US localizations separately from the main 
extension.
Interestingly, ChatZilla currently distributes separate language XPIs to 
supplement their extension with add-on locales. They even invented a 
locale versioning method to make sure users are having the correct 
language pack. Gecko-1.9-based extension manager now can cope with that 
itself due to supporting extension dependencies. And this process has 
its L10n files separate from the extension itself, which is what 
repackaging and even AUS2 might want or prefer to work correctly.

So, to me, it seems that the way to go for those extensions is something 
Axel called "dependent langpacks" - which is more or less what ChatZilla 
already uses, but with extension dependency added into it (which is 
ignored on older applications, so ChatZilla langpacks can easily add 
them and still be compatible with older apps).
What this means is that the original extension packages will probably 
all include the en-US locale as previously, and additionally we'll have 
every existing additional language as a separate extension (both in 
SeaMonkey and as XPIs).

How does that idea/proposal sound?
Something you feel comfortable with having?
If not, what alternatives do you see?
What additional processes do we need to go with that?
How can we arrive on a contract/agreement like described in the first 
section of this post, maybe based on this solution?

If we arrive at a point that extension owners/peers and L10n people feel 
comfortable enough with, I'd be happy to spent some time looking into 
how we can make it a reality and work on the needed changes to 
Makefiles, etc. - but first, let's get to a point where we agree on how 
to do it.
Sorry again for being to eager to get something done in my first 
attempt. I felt I needed to get something moving before some doors might 
close and we might not get a solution in the 1.9 cycle which we need for 
SeaMonkey2 though. I hope we can now come to a solution that will work 
for all of us and make our processes smoother all in all.

Robert Kaiser