-
Changes to the l10n-build system
John O’Duinn, Armen Gasparnian, and the rest of Mozilla’s build team should be very proud of their latest accomplishment. I am rechanneling a bit from joduinn who will blog in more detail later. But, this morning, they’ve made the l10n-build system capable of doing multiple repacks at one time. John also tells me that the “nightly l10n-repacks will be generated the same way as the release bits”.
Mostly, it means we have allocated more resources to our l10n build infrastructure with less custom setup to maintain. We have several identical machines working together to repack l10n builds, while in the past we repacked them one build at a time in one giant pack…see where we are going here?
Ultimately, this will allow us to better service localizers with build resources. We can do things like “one last repack” for those localizers who might have that need. In the past, we lined up all builds in a specific order and started the process as one big batch. If your build was in there, well, you’d have to wait until next time if something happened. Now, we have a pool of identical machines working in unison to service the l10n-build queue, grabbing the next build to be done as fast as the machines can. And, everything will happen much, much faster (perhaps 7x), since we have multiple machines working for us.
For the time being, the “new builds” are in the usual nightly directory here:
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla1.9.0-l10n/
If you want to view “the old way”, this URL takes you to the builds that are generated the traditional way:
ftp://ftp.mozilla.org/pub/firefox/nightly/old-l10n/
If you see any problems with the new nightlies, before you file a bug, can you check to see if the same problem occurs with the nightlies that are created in the traditional way? Functionally, these should be identical, but it will be helpful if we can see if the problem is in the new system or in both.
This post from Armen explains more. Please read.
John O’Duinn will post later today or tomorrow with more details. We are going to run these two systems in parallel for one week. If there are no complaints, we will shut down the traditional system and only use the new system. Please send along any questions if you have them.
-
More visibility into the l10n-drivers
Back in July, I blogged about the l10n-driver team reviewing some goals from previous quarters and how we did. In that post, I wrote about defining the role and scope of the l10n-drivers team so that people in the Mozilla community might understand more about the team’s function. We want to answer the questions “What are the l10n-drivers? What do they do? And, how can they help us?”
This quarter, I think we’ve started to make some progress on those questions. Here’s what I have noticed so far:
L10n dashboard
I won’t spend too much time here because I’ve blogged about it before, but this tool will only become better and better as time goes on. It is the one tool I look at consistently to remind me what localizations are translating Firefox, who might need to be contacted, and how we are doing as a community upcoming releases. If you haven’t checked it out yet, please do so.
Weekly Meetings
One thing we added recently is a weekly, Tuesday bug triage call. In those meetings, Axel uses the l10n-dashboard and Bugzilla to review which localizations are awaiting responses from us or might need a “poke”. He then gives good recommendations to each of us for next steps. This is when Axel is playing quarterback for our team and passing out assignments for each member. Perhaps some of you have noticed that we are trying to proactively get people to start localizing Firefox 3.1. We’ve been pinging people in bugmail to see if they are ready to move their translations from cvs into Hg. The whole team meets by phone every Tuesday at 10 AM Mountain View time to discuss who we should ping and which member on the team needs to do what.
Tricks of the trade
I blogged last week about changes to the l10n team. Here are some additions to our process from the new team members.
Stas has created a Firefox 3 l10n release trackers bug and then shows the dependency tree inside bugzilla to help us track each language we are trying to get into upcoming releases. It’s a simple change allows us to not let anything slip through the cracks. With Axel’s l10n dashboard and little things like this blocker bug, we’ll continually track who in our community might need some help or hear from us in bug- or email.
In addition, Gandalf is working closely with me to reach out to some of the newer localization teams in the queue. We try to gather the status of these teams and see where they might need help in navigating through the early stages of our process. I often send people to these pages that dicsuss things necessary for starting a new localization. (Those links discuss Mercurial and starting a new localizaiton). One specific example on how we have helped, just today, Gandalf and Axel prepared a zip file that presented all the string changes from Firefox 1 to Firefox 3.1 for a localizaiton team from Africa who had stopped its work right around the launch of Firefox 1. That team hopes to translate and get into the 3.1 release cycle.
Responding to requests
With these tools and team members, I think we are doing a pretty good job at responding to requests. We’ve scheduled IRC meetings with a lot of teams, including all of the teams that are launching in Firefox 3.0.2. I’ve also considered scheduling a monthly call for all localizers to dial into. It would be a time for locales to ask questions and for the team at Mozilla to give a semi-regular in-person update. This is just an idea, but might be worth a try. Thoughts?
Adding languages
We added 8 new languages with the upcoming release of Firefox 3.0.2. By the release of Firefox 3.0.3, we hope to add 5 more. That’s 13 more languages in the span of two minor updates. The challenge going forward may be keeping the pipeline filled with languages and making sure we reach out to the locales that have been working away for a long time.
I am up for more suggestions from the community on how we can improve. Please just comment or email me.
-
The L10n Team at Mozilla
Recently, the Localization team has made a few changes to the team that are worth noting.
Simon Paquet (IRC nick sipaq) will be leading up nearly all communication about localization efforts for Thunderbird. Technological questions will also be fielded by Simon and his team, but Axel and the l10n-drivers will remain a very strong support network for any questions that need help. Nothing changes in how localizers should expect to communicate though…please point questions to the dev-l10n mailing list.
Zbigniew Braniecki (IRC nick gandalf) has joined the l10n-drivers team and will be helping with several things, including developing Silme; supporting localizers by providing code reviews, creating patches, and checking in code; building community with tools like the Community Pack; and being another outlet to ping with all questions. Gandalf has a long history as a localizer and understands deeply the Mozilla process. He should be a great compliment to Axel’s hard work and knowledge of just about everything Mozilla l10n.
Staś Małolepszy (IRC nick stas) also joined the l10n-drivers team. He will be taking over all web services and productization elements of the localization process for Firefox. Additionally, he will be supporting localizers with code review, creating patches, and checking in code. He’s also running Mozilla Community Survey program, so we hope to use his talents there to continue to learn more and more about our community. Staś will also support Pascal Chevrel and our community with the localization of web parts that are included in Firefox. Staś had his beginnings as a localizer and deeply understands the Mozilla process. He’ll help with our efforts to make everything run as best and as transparent as possible.
Adrian Kalla has joined Mozilla for a few months as a localization intern hacking on Silme with Gandalf and Axel. Like Gandalf and Staś, Adrian is a localizer who has a great grasp of our localization process. We’re excited to have him around for the next few months.
Mic Berman (IRC nick mic) will be moving on from Mozilla. We are so thankful for all her contributions in helping to guide fully localized releases for Firefox over the past couple years. Please do send along any thanks and praises to Mic if you’d like. We are thankful for her service to the Mozilla community. Thanks, Mic!
As always, please ping us with questions. Firefox 3.1 Beta is approaching quickly and we are eager to help all localizers with questions. We want to have a fully localized beta, so if you are a localizer, please let us know what you need to make that happen.
-
Measuring Impact
With the release of the Chrome browser, Google presented two ways to measure its global impact with the localization of its Web browser: languages available and presence in number of countries. (Take a look at the opening line of this article.)
Gerv and I have both blogged a bit about how Mozilla tries to measure the impact that its community has by localizing Firefox for Web users across the globe. Specifically, we look at both the number of localizations and the percent of the world’s Internet population covered by Firefox with our translations. We don’t really measure by country boundaries.
But, to see how we rated against this Chrome metric, Pascal ran an analysis to see how many countries a user could find Firefox. He started by looking at the total number of countries listed by the U.N. Then, he looked at the Wikipedia entry for each country to find the official language spoken. By that count, Firefox is in 161 countries.
If we were to add that to our list of metrics, for the upcoming release of Firefox 3.0.2, we can provide the following about Firefox:
- Firefox is present in 161 countries
- Firefox is localized in 57 languages officially shipped across three platforms
- Firefox has 93.1%* of the world’s Internet population covered
I guess my first question that comes up when I think about coverage in terms of countries: what happens to languages that do not map to geopolitical boundaries? Guys like Erdal from our Kurdish localization probably have some thoughts on that. What about India? Do the people in Andhra Pradesh think that India can be represented as a country if Telugu is not a localized option for their browser?
Admittedly, I think our metrics are a better measurement (though slightly incomplete…see below) of the impact of a localization effort. It would be nice to open this conversation to the guys at IE, Safari, Chrome, Opera, Flock, etc. We have a lot of open discussions about security, performance, and standards. How are these other browsers looking at localization metrics? Did the Chrome team use the same methodology we did above to get the number of countries? What are the other metrics that help illustrate impact? Perhaps it’s wishful thinking, but I’d like to learn more from the other localization teams.
* I’ve mentioned before how we get this percentage and that our model is a bit incomplete, but here is how we think about our metrics:
Our goal is to count the number of people in the world speaking different languages who have access to the Internet, irrespective of country boundary, and then see where Firefox localizations provide coverage. Our premise is that some countries (like the U.S.) have people whose native language may not be the official language of that country. Therefore, we’ve set up a matrix where across the top we list most languages spoken in the world. We have a column that lists all countries. Then, we do as much research as possible to find out how many people in each country speak another language “at home”. The assumption is that people who speak a different language at home would also like to browse the Web in those languages. In the case of the U.S., one might expect to see its population speaking English, Spanish, Arabic, Chinese, and so on. The biggest challenge is getting accurate data of who speaks what languages in each country.



















