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

Robert Kaiser wrote:
> 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.

I'm not sure if this is right, but let's assume for the moment that it is.

extensions/irc would thus not be part of LOCALES_suite, and localizers 
that do want to localize chatzilla had to use MOZ_CO_MODULES to get it?

There would be joint deal between suite/locales/shipped-locales and 
extensions/irc/locales/all-locales, too, to formulate the shipping of, 
say, chatzilla-ab-CD.jar?

Axel