-
The L10n leadup to Firefox 3.5 RC1
Why am I nervous today? It’s that time again. We are in the final hours before the code freeze for Firefox 3.5 RC 1, and we’re biting our nails to see how many locales make the deadline. You see, each time we go through a milestone release, it takes a noticeable amount of coordination and work. The following post describes a bit about what the l10n-drivers do in the lead-up to each release.
During these last hours, to-do items fly around like a pile of leaves caught in a vortex, and the l10n-drivers stick our hands out trying to catch each one and put it to rest. For example…
I just sent out 23 final emails to our localization team leaders who have not translated the final strings that were added shortly after we shipped Firefox 3.5 beta 4. In case you’re wondering, if those 23 volunteer teams are unable to submit their final translations, then we won’t have 75 localizations for RC1.
Axel is tracking all the “opt-ins” for all the locales who are interested in making this release. For those familiar with how revision control systems works, we do not take the last updated Mercurial changeset that is listed on the localizer’s l10n repository. We want to be sure they are not testing or making any other last minute changes. To ensure we have their final approval, we ask them to tell us the specific version to take. I’ve blogged about this roll call in the past.
And, although it is not mandatory, many localizers are updating the corresponding in-product web pages and product pages hosted on our websites. Pascal is managing all of that by trading off sleep.
As I typed this, Staś was trying to follow up with new locales like Romansh, Chilean Spanish, and Sri Lankan Tamil, to see if those teams can finish their productization tasks for this milestone. Why do we make such an effort? The simple answer is that our l10n policy requires that any new locales must spend some amount of time with the release in beta so our localizers can gather feedback from end-users about their translations. During a major release cycle like now, it’s a perfect time for these new locales to ship releases within the official beta process so they don’t have to spend time in beta after we release Firefox 3.5.
Behind the scenes, the entire l10n-drivers team is on IRC answering questions and responding to requests from localizers and others about the release. Axel is also managing that one bug that keeps track of all the locales we intend to ship. And, we are all-hands-on-deck to make sure all goes smoothly.
Finally, mastering timing and communication when trying to coordinate a group of 75 localization teams is difficult, especially when you have moving pieces like the Geolocation strings that hit after last minute. It’s a bit of a new world with Mozilla l10n. Little changes like that one I just linked to are now multiplied by 75 groups who have to update their locales, even if we had already made announcements like, “Strings are frozen, begin translating“. In this specific example, we added two strings after we said go. That was followed up with some apologies and updates on work to be done.
I’m usually the optimist, but I’m not sure we are going to hit our mark for this release, as we have in so many releases in the past. In the end, when we are ready for the release of Firefox 3.5, we should have close to 75 localizations. Between now and then, we’ll be stressing all the way. For RC1…we’ll see what the final count is sometime tomorrow.
-
Firefox 3.5 beta 4, 70 localizations
Holy crap, that’s a lot!
For those who might not have been on today’s Firefox call at 11 AM (UTC -7), Axel announced that we have 69 locales participating in beta 4. (After the meeting, Macedonia went green!!) The number is huge, but it was the effort and patience from our localizers that was most impressive. Here’s why they made it a success:
- In the initial communication about Firefox 3.5 beta 4, we mentioned that the new beta would only be about 20 strings. It turned out to be 145 to translate! That’s not trivial. In terms of time required to do this, it goes from probably 1 hour to 1 day of work, depending on localizer familiarity with the process. No one complained about the increase in strings…
- Along the way, the code freeze slipped to April 15, after we pushed everyone to be ready by April 6. Again, no complaints from our localizers…
- Bugs regarding siteSearch and Mibbit caused some “breakage” to all of our localizations. Stas asked everyone over a few posts to the l10n newsgroup for their patience and understanding until proper policies were established on how to resolve bugs. And, no complaints from the localizers, once again…
In the end 70 of our 71 localizations made it into the beta process, making this our most successful localized beta ever.
Special congratulations to six new locales who will participate:
- Spanish (Mexican)
- Kazakh (Kazakhstan)
- Bengali (Bengladesh)
- Assamese (India)
- Croatian (Croatia)
- Tamil (India)
This one is nearly passed off to build and then we’ll be moving on to the Firefox 3.5 release candidates and final release. Can we get over 70? I’d bet on it.
-
Did Firefox market share cause major changes to online banking in Taiwan?
On February 27, 2007, Gen Kanai wrote an excellent blog post titled the cost of monoculture, which describes the state of the Web in Korea. Gen unfolds the decisions made by the Korean government that have forced computer/Internet users to use Microsoft’s ActiveX control to do any encrypted communication online.
Luckily, this extreme monoculture does not exist in most other countries, but it doesn’t mean that users are always free to choose whatever browser they want when doing things like banking transactions. Sites are still being created that require an ActiveX control to do encrypted communication.
For example, in Taiwan many people use Web ATM to do online banking. The Taiwan Review wrote an interesting article in 2005 called, “A Web of Opportunity“. In that article, they discuss the benefits of Web ATM:
“Some forward-looking local banks have introduced a new solution, Web ATM, a Web page that allows payers to transfer funds directly using a chip-stored identity card and their own card reader. Chip cards are much safer than the magnetic strip variety and as a consequence of this heightened security, Taiwan’s banks are now required to replace magnetic strip ATM cards with them.”
The problem is that all banks with Web ATM service required an ActiveX control, so users had to no choice but to use Internet Explorer.
Until now.
We recently got word that E.SUN Bank‘s Web ATM became the first to support Firefox (and other browsers with the same plug-in framework) on Windows. What an accomplishment and a step forward for banking on the Web in Taiwan!
I began to wonder about E.SUN’s motivation for this change.
- Did E.SUN Bank do this because of changes in browser market share?
- Did their users demand Firefox support?
- Was there a business opportunity for them to be the first to market?
- Are they a progressive organization promoting open standards for the Web?
Regardless of the strategic motivation behind this decision, online banking just changed in Taiwan and users benefit by now having more choice on the Web.
Soon after this decision, our Taiwanese localization team contacted us to ask how we can feature and promote this new service. In this bug, you’ll see the discussion and decision to feature E.SUN Bank on pages that we serve to Taiwanese Firefox users on Windows. Staś really sums it up best with his opening remark:
“E.SUN Bank from Taiwan has done a big effort to make their website available for Firefox users. This is an important step for Firefox adoption in the region and consequently, we would like to feature a link to their website for a certain period of time on the zh-TW web parts (whatsnew, firstrun and central pages)….The important thing is to show the link only to Windows users. We would love to see this live for the 3.0.8 release.”
Web evangelism efforts like these are taking place in Mozilla locales across the globe. Without having much to do with it, I am still proud of the accomplishment and that we can shine a spotlight on E.SUN Bank for crossing that frontier. A big congratulations is due to E.SUN Bank, the MozTW team (Bob Chao, Tim Dream, and flybird), and Gen. Thank you, guys.
-
70 locales
It’s been a busy week for the l10n team. Has anyone else been following the l10n release tracking bugs for Firefox 3.5? Take a look at this dependency tree from Bugzilla showing 79 open bugs for potential locales. That’s a rough list of the upcoming locales for Firefox 3.5. Please keep in mind that this does not mean that we will add all these langauges for the upcoming release. But, I will say that we will add *some* number of those listed. In fact, just this past week, Axel added the following localizations (language, primary region, locale code) to the l10n dashboard:
- Bengali, Bangladesh, bn-BD
- Oriya, India, or
- Spanish, Mexico, es-MX
- Croatian, Croatia, hr
If the locale is building on the dashboard, it means Mozilla’s build and release team is now officially generating localized versions of that language. It doesn’t mean they are usable versions, but localizers work on translations until their builds are green. If you looked at that l10n dashboard link from above and click on ff31x in the “Tree” section , then you’ll see that we are now building 70 versions of Firefox!
It’s likely that we will also a new version of English for South Africa, Kazakh, a version of Tamil for Sri Lanka, and Assamese at some point during Firefox 3.5. Finally, we are doing active outreach and support to Swahili, Malay, and Azerbaijani. This happens primarily because of the drive and passion of individuals who are eager to translate into their native language (they’re listed above in that bug tree). But, it’s also due to some specific community folks:
- Axel Hecht
- Pascal Chevrel
- Staś Małolepszy
- Zbigniew Braniecki
- Gervase Markham
- The Release Engineering team
Now, to reel in the celebration a bit, it’s easy to get excited by these numbers, but we put in serious effort to make sure we can scale…and we’re starting to feel the pressure. Managing 70 locales across three platforms is not an easy task. Look for more blog posts from me on what we are doing to sustain this pace.
-
Localization-QA survey results
At the end of last quarter, we launched and analyzed a survey about l10n testing needs. The hope was to find areas where we could provide help to our localization community around how to test their builds. The analysis was done by Mozilla contributor, Murali Nandigama, and he posted his slides here. The next step is to implement something from those findings for the community. Please take a look at the analysis and make help me with some conclusions.
Here are some takeaways our team noticed when we looked at the slides.
- Localizers are enthusiastic to see more automated tests and automation frameworks for testing compared to adding more Litmus manual tests.
- Survey participants might be assuming that more automated tests would provide the same functionality as Litmus manual tests.
- However, especially in the L10N context, font-rendering, text clipping, dialogue/character spacing etc., can be eye-only tests and might not be substituted by automated tests without a lot of non-trivial automation effort.
Conclusion: Litmus manual tests are important and hard to automate to replace visual verification. Has everyone played with Litmus?
- 95% of survey participants are using non-Bugzilla channels to report issues, problems, and bugs. (Or, only 5% use Bugzilla to report issues.)
- Because of this, we cannot quantify and archive the effort of l10n volunteers in finding bugs.
- How are people logging issues with local problems?
Conclusion: We might need to blog to demystify the bug filing process for l10n volunteers. Or, provide easy tools like bug-by-email templates.
- In the survey, we specifically asked if l10n communities are testing for a things like non-US keyboard input, clipping of text in boxes, RTL etc.
- A majority of communities are either not aware of these testing steps have no need to test these issues (like RTL).
Conclusion: We might have to provide a generic blue-print for effective test planning for any locale, indicating what are the key l10n steps in test planning.
- In the open comment section, we saw responses like this:
- Survey takers indicated that teams larger than 10 are using the l10n builds.
- Teams indicated that only one or two members are actually reporting problems and filing bugs.
- Some indicated that they do not have a formal test plan in place, no institutionalized knowledge-base on testing locales, and lack a coordinator/leader for their l10n testing efforts.
Conclusion: We might need a third-party QA service to help lead volunteer L10N test activities.
I’m still sifting through the data to find who might benefit from some of these recommendations and findings. If you’d like to make my job easier, please comment on what you think your locale needs. Questions are welcome too, please.
Many thanks to Murali who did the analysis posted above and helped me write this post.
community website