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