What happened to two localizations on the day of Firefox 3.5’s release
Not everything is picture perfect in the world of Mozilla localization. Though it pains me to say that, we hit two snafus at the release of Firefox 3.5. Here’s what happened with our Macedonian (mk) and Serbian (sr) localizations, complete with a mea culpa and a plan on how to fix things going forward.
On the day we released, our community found two very similar errors in our mk and sr builds. In both cases, a misspelling of &brandShortName; inside an <!ENTITY> triggered the “the yellow screen of death” when users selected the Help -> Check for Updates… option to get the new version.
A thousand apologies to our localizers and mk and sr users for not catching these errors pre-release.
With damage control in full swing, we removed the two localizations from the Firefox 3.5 release channels so that users would not receive a broken version of Firefox. The two localizers and the l10n-drivers then worked through our options. We could either release a special post-Firefox 3.5 Macedonian and Serbian version, or wait until the release of Firefox 3.5.1.
The unexpected timing of the Firefox 3.5.1 release helped us with the above decision. Although the circumstances of the security update were not ideal, it did allow us to release mk and sr earlier than expected, getting users of those localizations back on the release track. Furthermore, any users who might have gotten the broken mk or sr version of Firefox 3.5 on release day will be updated behind-the-scenes without having to check for updates. [1]
What happened on the 3.5 release day underscored a few errors in our system that need to be fixed. Here are the proposed and soon-to-be or already implemented measures we are taking to reduce this margin of error:
- Localization sign-off via the Web: Rather than opting-in with change sets, localizers will soon select the Mercurial change set they want to use for a release from a list of IDs pulled from their locale’s repository. How does this help? In Macedonian’s case, a localizer *had* submitted to Axel a change set that corrected the error prior to RC3. However, Axel was unreachable at a conference and couldn’t relay that update to me. Sadly, I submitted the incorrect change set. Mea culpa. This application allows localizers, l10n-drivers, and Firefox project managers to view the choices that have been made, and to the extent possible, test to make sure that the version the localizer wants is good for release.
- Test automation: We are working on creating a script that can be run by our QA team before each milestone that will scan for misspellings in things like &brandShortName;. This bug is tracking that progress. Our QA team also is increasing the number of automated tests that will be run on each locale before each milestone release.
- L10n-testable builds: Presently, we are producing testable nightly builds with Axel’s l10n-merge code that will create localizations with en-US strings replacing any untranslated ones. Now, localization teams can give their testing communities something to test from the beginning of the release process. In the past, localizers had to wait until they had 100% translation before we provided them a nightly build.
- Localized builds with nightly updates: Added to the testable builds above, we’ll soon be able to offer nightly updates to localizers and their testing communities. Right now, only en-US testers of Mozilla’s pre-release versions get nightly updates pushed to them. Soon, *all* localizations will get these nightly updates pushed their way so our global testing community can see the most recent additions made by Mozilla’s developers.
These tools empower the localizers and the testing community, and we believe will help narrow our margin of error so that we don’t repeat what happened to our mk and sr builds.
Many thanks to our Macedonian and Serbian localization teams for their understanding and patience and sorry for the errors discovered at the time of the Firefox 3.5 release.
[1] Mozilla developer rstrong and his team fixed this bug and cleaned up a lot of code for the Firefox 3.5 release so that users of Firefox get updated behind-the-scenes without having to check for updates or get prompted unnecessarily if they want/need an update.
For simple cases such as unresolvable entities, shouldn’t there be automated processes for validating localizations, perhaps as part of packaging a release? It wouldn’t catch minor embarrassments like spelling errors, but would certainly catch anything that results in an invalid page…
(Never mind… missed the comment about test automation)
For localizers who already want to test for misspelling entities in their localization, there is :
http://frenchmozilla.fr/glossaire/fr/entite
which search for difference between your locale and en-US entities name in their localisation.
(Replace fr with your short locale code).
This isn’t the first time this has happened for the mk locale. It has had issues with invalid rdf files. The ko locale is another culprit. Please also make sure to check for valid RDF when doing automation.
Gordon: Thanks for the comment. We’ll keep an eye out for that.
This doesn’t seem to work very well. See http://frenchmozilla.fr/glossaire/lt/entite for example.
Doh, my reply targets Philippe’s comment, actually.
@RK : yes it works, but I think that for the two first lines, it threats the ” (and the inversed ones) as entities (likes the "es; that appears further).
I am totally giving up on your so0ftware. I hate IE, and do not like Opra, so I guess I either develop my own or search for something new.