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