While most attention is focused on FF3.5, I wanted to echo what Coop said recently about a boring-sounding, yet really important, change to how we produce l10n nightly builds.

Every l10n nightly is now guaranteed to not be missing any entities.

Whats that mean? Why is that so important?

1. All the nightly builds (whether they are en-US or any other locale) have the same actual code functionality. ok, so what?
2. When running the en-US version of Firefox, the code displays the en-US version of a string. When running es-ES version of firefox, the code gets the es-ES version of the string. Yeah, ok, so what?

There is an interesting race condition problem here though.

Between the time when the new string is added in en-US and when a localizer gets to land the equivalent localized string in their locale, we are still producing nightly builds. This means that for some days/weeks, the generated l10n nightly build has problems when Firefox goes to load the localized string to display, and finds the string missing for that locale. The only symptom the nightly l10n user will see is an internal error message or blocked functionality, or refuse-to-start bustages or a crash-with-stackdump.

This has been a problem with l10n nightlies since before I got here, and as far as I know, has always been a problem since the Mozilla project started. This problem also has some significant consequences, detailed below.

What have we changed?

When a new string is added to an en-US build, the en-US nightly has that new string (as you would expect). The l10n nightlies will now also have that new en-US string (as you might not expect) but only until the localized string is created by localizer. (Its also tied into Axel’s L10n dashboard so he can track those non-localized strings, and make sure we don’t accidentally ship with them!). Once a localized version of string is added, the new l10n string will be used.

There are 4 important consequences of this change:

1. Localizers can now safely download the latest nightly without having to first manually read through the checkin logs, and l10n dashboard to figure if an l10n nightly is safe to use, or whether that new l10n nightly will crash out with missing strings.
2. Localizers can now see the exact location and usage of what they are translating, in the exact context. Much better than looking at a list of strings in a text file, and having to install en-US to see where the new string is being used. This is a really big deal when figuring out language subtleties.
3. Fixing this was the last big pre-req before we can start producing nightly updates for l10n builds. Recall that >50% of users are on non-en-US Firefox. However, only en-US nightlies have nightly updates. Until now localizers have to manually download a new nightly after they have manually figured out if it is safe to install. Now that we know each nightly has all entities, it makes it safe to offer automatic nightly updates for l10n, just like we do for en-US. And now that other infrastructure cleanup has been done, this is now finally possible. Here’s even a French nightly update that Armen has running in staging right now. 🙂 The curious can follow along in bug#449828.
4. This *might* help simplify how localizers get changes into place during the release cycle before a string freeze is announced for a release. Until now, some localizers prefer to wait until all new strings are in place, and string freeze declared before they start doing all translations as quickly as possible. Now, with each l10n nightly being as safe to use as the en-US nightly, localizers might start using l10n nightlies as their default browser. That means translated strings could be added when localizer has time, the automatic update to next nightly would show that translated string in use, and the localizer could adjust if needed for screen size, font bugs, etc.

All in all, its awesome stuff by Armen, Coop and Axel.