Re: Source L10n for extensions (ChatZilla, venkman and others)

Robert Kaiser <[email protected]> Tue, 11 Sep 2007 15:56:04 +0200
Newsgroups gmane.comp.mozilla.devel.jsdebugger
Message-ID <lYKdnW4mq4voA3vbnZ2dnUVZ_sejnZ2d__13773.4116673984$1189519228$gmane$org@mozilla.org>
Axel Hecht wrote:
> <...>, zip, basically, yes.
> 
> Let's make a post on which contracts we currently have. I might be 
> biased (I am), but I'm missing some release-management parts in the 
> discussion so far.

Thanks for bringing those in, I left those out at first because I 
thought they probably depend on what the technical solution is - and we 
need the module owners in this.

What I'd like to have for SeaMonkey is the following:

> - Does this thing need to get localized?

No, it should be optional.

> - Who's responsible for bustages?
> - Who's responsible for QA?
> - Who's responsible for sign-off for shipping?

Once a localizers opts into doing it and has a first working L10n, I'd 
like to hand him over the full responsibility on all of those and the 
L10n of the extension will be treated like it was non-optional and a 
part of the SeaMonkey L10n for this language. Upon request of the 
SeaMonkey L10n owner or the extension L10n owner, the L10n of the 
extension can be excluded from builds again.
Sign-off for shipping should be done for full SeaMonkey, which makes it 
the responsibility of the SeaMonkey localizer if it's included. I only 
want to have one person to talk to when it comes to shipping a SeaMonkey 
release. Upon the responsibility of this person, we'd also be able to 
exclude the extension L10n from the release for bustage or bad quality. 
That's probably also what I had in mind when creating that all-locales 
file for ChatZilla.

For shipping the external add-on XPIs, I think the extension owner/peers 
need to tell what they have in mind here, the SeaMonkey team of course 
can't force a process on them.


So, to take your terms, I basically like to have a reporter-style 
contract for the SeaMonkey case with a mechanism for making the 
localization of the extension optional and handle it as an extension in 
this way.
This is only one side of the medal though, as extension owners want to 
independently ship their add-on in different ways, so we need their side 
as well and formulate it into a common contract, even if that one might 
be two-fold.

Robert Kaiser