Firefox3/Schedule/L10n
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
This is an RFC for the l10n part of the Firefox 3 Schedule. Please don't edit this unless you're Axel or the Firefox 3 steering group.
Introduction
The target of this proposal is to make the amount of work to be done by our localizers and its outcome for Firefox 3 predictable, that is, if a localizer lives up to the requirements set out, that localization will be part of sim-ship for Firefox 3.
On top of that, we'd like to get our localizations in an as good as possible shape without putting too many constraints on the development of the en-US version.
Instruments
I propose two instruments in main release process,
- a time-to-patch for the localizer,
- a l10n swag.
The time-to-patch is basically the time a localizer has to come up with a localization patch for a (small) change to the en-US build, and get it landed.
The l10n swag is similar to the engineering days swag, and enables the steering group to assess how close we are to done when it comes down to localization impact changes. This is an estimate, and no exact science, of course. The proposal is to estimate the lines starting in '+' in the patch, with 80 char width. That implies that a single help change may actually count as 50.
Milestones
We don't care about the Granparadiso Alphas at all for l10n. What I would like to see is RC1 being an RC for l10n. Thus B2 should be a beta, and it'd be really good if we managed to make B1 an alpha for our localizations.
Firefox 2 ...
froze on Wednesday, and shipped the next Wednesday (B1), or the Wednesday 2 weeks later (B2).
Milestones
- en-US B2
- String frozen
- en-US B1
- Not really string frozen. Previous releases used string complete, or "no adding new files". What we really want is a well-known and low l10n swag, so that localizers find a stable basis for their work at this point the latest. My personal take would be an l10n-swag of 0 being great, of 1000 being bad. 10 per week between B1 and B2 is probably OK, but that's vague.
Proposal
- en-US B1, l10n alpha
- The proposal is to freeze en-US on Wednesday, go through QA end of the week, and freeze, tag, repack l10n on the following Monday. We'd alpha any localization that'd be green.
- en-US B2, l10n beta
- Same proposal as B1, just use the additional week to do dedicated QA
With a sufficiently well done l10n swag, we could start to feed localized B1 builds to smartware for 3rd party testing. Smartware testing between B2 and RC1 is possible, but the chance to actually fix bugs found goes down.
Alternative Proposal
If we decide that build is much better off with doing both en-US and l10n builds in one go, we would want to freeze the /cvsroot repository for l10n impact changes the Friday before the real freeze Wednesday.