Re: Source L10n for extensions (ChatZilla, venkman and others)
Axel Hecht <[email protected]> Tue, 11 Sep 2007 12:57:44 +0200
| Newsgroups | gmane.comp.mozilla.devel.jsdebugger |
|---|---|
| Message-ID | <8pydnbFAB9jV7nvbnZ2dnUVZ_uygnZ2d__4297.86484824053$1189536910$gmane$org@mozilla.org> |
<...>, 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. With domi and reporter, we currently expose the "contract" via client.mk. reporter is in LOCALES_browser, and it's not optional. domi is not in LOCALES_browser, and it's so optional it hurts. What do these contracts fix? Here are the questions that I can answer, or make up answers for, depending on client.mk: - Does this thing need to get localized? - Who's responsible for bustages? - Who's responsible for QA? - Who's responsible for sign-off for shipping? REPORTER-style contract reporter is not really an extension in its own right anyway, we really just use it as an optional package. Thus it's not that bad that the extensions contract ID isn't perfect. reporter is part of Firefox, and it's up to the localizer to make sure it works in her or his localization. The localizer needs to fix the bustages, needs to organize QA, and signs-off on the localization for release as part of the sign-off process for the complete localization. DOMI-style contract DOMI lives as a regular extension, built as shipped as one big blob. For the most part, it's up to the DOMI owners to make sure that that extension doesn't bust Firefox. Localizers sign off on their localization at the time they make a change and request to be added back. Not shipping a DOMI localization at release time requires an explicit action to pull a localization, whereas in the reporter-style, the localization would just not have been added to the shipped-locales file. One question that we could ask in addition would be: - When is a localization built? Like, we could only start to build localizations of an extension after it is frozen. That would take out the part of "oh, you changed something, and now the localization needs to... what?" We'd basically would move, in firefox-speak, move from cvs to shipped-locales, without bothering about all-locales at any point in time. That would require a way for localizers to locally test, though, and to check if something has a bustage. These are my experiences and thoughts from a more release- and process-driven perspective. Axel