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,

1. a time-to-patch for the localizer,
2. 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?) 

We have two weeks between freeze and shipping of B1. We'll need to evaluate the progress on short notice, but we're currenly not planning to ship B1 with localizations. If progress is looking good and we're not landing too many huge string changes the day we freeze, we'd alpha any localizations that are green, say, mid-freeze.

String freeze 

Two weeks prior to B2 freeze. Tentatively, there could be 6 weeks between B1 ship and B2 freeze, so we'd split that up in two weeks testing, two weeks feature fixing and landing, two weeks of localization.

en-US B2, l10n beta 

Well frozen, with localized builds for all localizaitons we want to ship.

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.