-
Responding to Walt’s rhetorical criticism
If you advance to the two minute thirty-five second point of this interview of Mitchell Baker and John Lilly, you’ll hear Walt Mossberg remark about the quality of Mozilla’s localizations by saying,
“I have a deep distrust of somebody who I don’t know to be actually responsible for the quality of the end product.”
We’ve heard that before, haven’t we? To entertain the point, I’ll answer a question, “Just how do we know that our translated product is high quality?” by linking to several posts (with very brief summaries) as a response to Mossberg’s rhetorical criticism.
- Testing the latest localized version of Firefox 3.5 — In this post, I ask our localizers to test a release, with specific steps that each locale can follow.
- Moving a locale out of beta — This is a basic software release principle. No, our localizers don’t get a free pass into “official status”. We give each locale a proper amount of time to bake so the beta users can provide feedback to our localizers. After feedback is “triaged”, bugs are fixed, and signs of user adoption become obvious, we move a locale out of beta.
- Localization-QA survey results — At the end of 2008, we conducted a survey to gauge our teams’ testing efforts. The posted results point us to where localizers might need our assistance. From this, we have begun an experiment to provide a third-party QA service to help test a sample of our localized versions.
- Adding contextual information to a localized build – Some of our localizers even create, share, and use customized tools to help perfect translations
Perhaps it’s hard to express without sounding naive or idealistic, but maybe there is an important theme that didn’t make Mossberg’s conversation that should be articulated:
We take localization very seriously. This is not just a hobby for our community, and many have the battle scars to prove it. Just ask someone who has stayed up all night to perfect a translation before a code freeze and you’ll understand what I am getting at. Each of our localizers is keenly aware that greater than fifty percent of our end-users are NOT using an en-US version. When a localizer is responsible for a translation, the quality of their work impacts a massive amount of end users. We could ask our German localizer Kadir, whose localized version of Firefox is being used by an estimated twenty-five million people. Or, Romi, our Indonesian localizer, who’s translated version has climbed to sixty-three percent market share. That level of impact keeps our localizers sharp and tremendously dedicated.
Other highlights from the transcript:
“Walt: 71 of the foreign-language versions of Firefox are written by volunteers. Why should I use a product like that? Lilly says Mozilla has a system for verifying the quality of these other versions and vets them prior to release. Beyond that, users will alert the company to any problems.”
“Walt: Why wouldn’t it just be better for the consumer to go with the company that’s hired experts to do its translations? Baker: How much software do you really think is great? Walt: Not very much. Lilly: But it’s all written by experts. Walt nods, point taken.”
NB: John Lilly mentions that we’ll have seventy-one localizations for Firefox 3.5. We’re growing everyday! We are actually going to ship seventy-three localizations for Firefox 3.5′s release candidate, with an outside chance of seventy-five for final release.
-
Adding contextual information to a localized build
A volunteer from the Tanzanian Linux User Group passed me this blog post that describes a tool he created to help localizers with context of strings in the Firefox user interface. As Alberto writes,
“It is difficult to translate something that you have never used before, functionalities that the translation team is not familiar with or English words that can be understood in several ways.”
His tool allows a localizer to add tags to each string so that when the localizer builds Firefox locally, they can see the translation with a tag in the UI. If the translation seems incorrect in the context, the localizer can use the tag to find the file that needs adjustment. See the screen shot below and check out his post for more information.
-
Koala
Many of you may remember our localization intern, Adrian Kalla, from last year. A dedicated community member before his internship, Adrian returned to school to continue his contribution to Mozilla. Recently, he approached us with a request to support a project that would help complete his course of studies. After expanding the idea with Axel, he had a project idea to pursue and the l10n-drivers jumped at supporting such an interesting experiment that Adrian calls “Koala”.
He will be blogging about his project on a regular basis, but he asked me to post the following initially to describe the idea:
During my internship at Mozilla last year, I developed a Silme-based “compare-locales” version. It is a command-line only tool, that requires from the user to have experience in working with a console. Well – we all know that a text-interface is not necessarily a user’s first-choice, so Axel came up with a great idea to develop a user-friendly graphical front-end for it.
Being back at my University, one part of my major is to work on a project, which may be done in cooperation with external companies. This project is officially scheduled for the term directly after the internship – that is, the chance to move Axel’s idea from the ‘ideabox’ to the ‘real’ world. I see it as a great opportunity to continue my work on Mozilla L10n tools and my major at the same time. Everything went quickly: Axel defined the project and its details, which was then accepted by my professor as an official university project. Together with my fellow computer science students, namely Adam Kowalewski and Florian Schloegl, we created a project team. And…
What exactly are we working on?
Calling the project just a “graphical interface for compare-locales” would underestimate the objectives we have set for it. It will be an extension for the Komodo Edit & Komodo IDE developer-editor/IDE applications, which are based on Mozilla technologies, that will help with the daily work of holding Mozilla localizations up-to-date. Starting with pulling Mercurial repositories, comparing the changes, showing that changes to the user directly in the work files, …, ending with helping during the translation process (e.g. translation-suggestions, syntax highlighting) and committing the changes back to a repository – everything in just one tool.
We named the extension “Koala”, which stands for “Komodo Advanced Localization Addon”.
More information will be available soon on http://koala.mozdev.org .
To accomplish the project, we have a September, 15 (2009 of course
) deadline. But you will hear of us sooner. Stay tuned. -
An experiment to integrate Silme with Narro
Many of you know Romi Hardiyanto as our Indonesian localizer who has helped grow Firefox’s market share in Indonesia to 50% since he started localizing in 2007. Romi is also a dedicated Mozilla contributor who recently hosted a terrific add-ons workshop at the Information System Department Park, ITS Campus in Sukolilo, Surabaya, Indonesia. (But, I know you’ve read Gen’s post about that.)
Recently, Romi responded to a Google Summer of Code idea I had posted about helping to enhance Mozilla’s dashboard. The l10n-drivers knew that this project was a bit of an imperative, so we decided to take on development within our team before we had any guarantee from GSoC if our proposal would be accepted. (Some blog post about the dashboard vision and progress are coming from me and Axel.) Given the amount of ambiguity on the resources Mozilla would commit to the idea, the GSoC proposal was rejected.
But, from the ashes came an idea to do a similar summer of code style project within Mozilla. What if we could redirect Romi to do another experimental project that would have some benefit to the localization community? Could Romi contribute to Silme by working on an implementation? In the past, we’ve supported some of our tool authors with funding and development resources. It turns out that Narro, another tool used by many of our localization teams, seemed like a good fit for the experiment. Voila, a new proposal took shape.
I am pleased to announce that Romi will be working to integrate Silme, a library of localization scripts created by Gandalf, into Narro. With Silme integration, we should be able to get exports of translated strings from Narro that are file-type independent (because Silme does that nicely) and can be used by the localizers and l10n-drivers to smooth out any commit bugs when it comes time to push changes back to the l10n code repositories.
Why is this important?
I’ve blogged in the past about the uniqueness of Mozilla’s DTD and property file types. Our file structure and file types can create conflicts with the output people who choose to localize with tools send to us. With Silme integration, we’ll have something that maps a bit more nicely to DTD and property files with less conflict. You can read more about Silme on Gandalf’s blog, including this wiki page that describes what features we hope to add in the 0.7 release.
The early challenge for Romi’s project is going to be embedding a Python interpreter into Narro’s PHP code base He researched a bit about PECL and will blog soon about his findings. If you can provide any ideas on how to do this, Romi would love to hear your remarks. We also have some stretch goals to hit if Silme gets integrated into Narro, and Romi will continue to blog about his progress, and those goals, over the next couple months. Please welcome Romi when his first post to Planet appears and provide any advice you might have.
-
Testing the latest localized version for Firefox 3.5
I posted this to the Mozilla L10n newsgroup, but for maximum coverage, I’ve reposted it on my blog. Special thanks to Marcia, Axel, and Chofmann the various resources I reference below.
——————————————–
To all of our great community localizers and testers…
Over the past few weeks, many of our Mozilla community members have done testing and landed fixes for Firefox 3.5 as we close in on our release. We are now in the last hours before we ship our release candidate that we can comfortably call Firefox 3.5. If you have time this weekend, it is a great opportunity to do some last minute testing for your localization.
Where to download the latest localized nightly version of the Firefox 3.5
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1-l10n/
Please hammer on these builds mercilessly to make sure that things work well. If you notice things that worked in Firefox 3.5 beta 4, but do not work in this release, we would like to know about it right away.
What to Test
You can run a set of localization test cases by going to Litmus, Mozilla’s testing suite. This URL will take you to the “l10n run”.
https://litmus.mozilla.org/run_tests.cgi?test_run_id=36
If you don’t have a Litmus account, you should be able to create one quickly. Please email us if you need any help.
How to report feedback
Please try filing a bug for your locale with Bugzilla. The basic set of instructions are below. If you are not comfortable filing a bug, you can report it to your locale leader who should be listed in the specific locale on this main Teams page:
https://wiki.mozilla.org/L10n:Teams
Things to remember when filing a bug in https://bugzilla.mozilla.org/:
- Always include the Build ID that you tested on. If you type about: in the URL bar, this will give you the Build ID.
- Always include clear “Steps to Reproduce” the bug.
- Always check to see if your bug has already been filed. This link will help: http://tinyurl.com/2465be
- Use the regression keyword if it indeed a regression from a previous release. And, please tell us in the main comment of the bug if it is a regression from a previous release.
- If you happen to crash, please include the Breakpad ID in the bug. You can get this by typing about:crashes in the URL bar.
If you don’t wish to file a bug, report issues through http://feedback.mozilla.org or through the mozilla.feedback.firefox.prerelease newsgroup (I just linked to the Google Group). However, we prefer bugs as feedback since those are easier to track.
Finally, keep in mind that no comments or questions are off limits. Please send along any remarks or questions that you think are appropriate at you test. It’s all appreciated.
Thanks to all of you for helping test Firefox and making it the browser of choice for millions and millions of people all over the world!
