Our last trip to India was no exception.

On our first Sunday night in Mumbai (Feb 22), we co-presented with one of these organizations at a Mozilla community meetup.  The group calls themselves Pad.Ma or, in longer form, the Public Access Digital Media Archive.  The project “is an online archive of densely text-annotated video material, primarily footage and not finished films. The entire collection is searchable and viewable online, and is free to download for non-commercial use.”  And, right on their website, they state their intentions to align with web standards:

Q:  Which browsers do you support, on which platforms?
A:  We currently support Firefox and Safari, on Linux, MacOS and Windows.  We do not support Internet Explorer. However, if you wish to endeavour to make the site work on IE, please appeal to IE to support web standards in their next version.

(In fact, for some fun, fire up IE and visit their website to view a strong statement from them regarding your present use of IE.)

More on the meetup, but let’s rewind by just a few hours before we met Pad.Ma face-to-face…

After a four hour roadtrip on the Pune-Mumbai highway, we arrived at our hotel in the cool neighborhood of Mumbai called Bandra.  Freshened up in about fifteen minutes, we piled two-by-two into autoricks and motored our way on a humid evening through the snaking streets to the event location.  Arun had treasure map-like directions that led us down narrow alleyways.  “When you see a cross on the wall, proceed a few more feet and you’ll see an apartment entrance on your right…” Arun read as we navigated through the Pali Hill district’s corridors.  Up a few stories and our eyes opened to a rooftop event with a large projection screen, bean bag chairs, a minibar with soft drinks and beer, and two big vats of local food.  We made it.

Invited by a local community member named Sanjay, about 25 people came to hear us speak about the Open Web and how we were building community in India.  After our presentation, the team from Pad.ma followed by showing their amazing work to archive movies on the web.   If you’re a movie person, this site will fascinate you, so please look around it.  The Pad.ma presentation was followed by their demo of the “Firefogg” addon, which allows you to easily convert videos to .ogg theora video compression format.

It was a nice tandem.  Arun chatting about the Open Web and explaining cutting-edge demos.  And, just when we thought we might lose the audience on how the technology could be applied, Pad.Ma presented their work and the Firefogg addon.  It was a nice blend of demos and practice and I believe the group’s imaginations were sparked.  The Open Web had been delivered to a rooftop audience in the Pali Hill neighborhood of Bandra.  Sometime during the evening, fireworks started to explode.  This was not planned.  An Indian wedding was taking place in around the corner.

ShareThis

Our first big event was the three-day conference at gnuNify ‘10 held in Pune.  On Friday, February 19, we held an entire track to chat about Mozilla.  Arun gave a talk on web standards that seemed to be a crowd favorite throughout the entire trip.  Ragavan chatted about Mozilla Labs, and, since all of our Indian localizers are there, I invited Axel to join so we could chat about the new project “l20n” which I’ve blogged about in the past.  The rooms were pretty packed, in some cases, standing room was the only option.

I was particularly pleased that about half of our localizers cut out of work early on Friday to see Axel and me.  Not only did we chat about l20n, but we reviewed a new locale (मैथिली Maithilī), worked on moving Oriya out of beta status, and caught up in person with some of our most dedicated community members.

On Sunday, we held our annual entrepreneurs breakfast with local web entrepreneurs in Pune.   Arun lead the morning with a detailed discussion about the Open Web, covering the following:

• The Open Web as a platform
• Future of video on the Web
• Device orientation events in Firefox
• Font issues on the Indian Web
• The geolocation API
• WebGL and 3-D graphics

At the end of session, we held a small workshop where we split the groups into teams of three and asked them to come up with entrepreneurial ideas that encapsulated all that we had discussed.  The groups were given 10 minutes to come up with their ideas.  Then, each team had one minute to present to the audience.  We served as a panel, questioning about the idea, potential business model, etc.  Of the ideas we saw, four stood out:

1. A “Typekit.com” for indian languages – typekit.in
2. e-learning classrooms for physically impaired – using video capabilities of HTML5
3. A video mashup app – something like online maps with text to speech audio and video
4. Using the geolocation API from Firefox – giving users local search results through a map website

Everyone’s ideas were great, but we selected these as standouts and gave the winning team some Mozilla stuff.  We chose the e-learning idea.  We offered to follow up on specific ideas and questions if anyone had them.  The team that came up with the geolocation API use-case has already started their business and intends to experiment with the technology and promote Firefox on their local map website.

In conclusion, the event in Pune was a great weekend for us to kick off our Indian adventure.  We landed into familiar arms since we presented at gnuNify ‘09.  Because of that, we saw many faces we already new and were able to really push our conversations to very technical levels and Mozilla-related ideas.

ShareThis

Because we field many requests by volunteers interested in becoming an official localization, we have to find what is best for us and them.  That can mean promoting smaller localizations as language packs on our addons website.   Oftentimes, we find that a language pack might be the best possible solution for a new localization.

To make that determination, the l10n-drivers will work with the volunteer to assess not only how many users there might be, but also what productization elements might be included. By productization elements, I am referring to things like

1. embedded search providers such as Wikipedia, Amazon, etc.,
2. web protocol handlers like Yahoo as a  “mailto:” option, or 30 Boxes as a  “webcal:”, and
3. “live bookmarks“, which is an RSS feed for a local news provider that will be included in the bookmark toolbar.

Among many other things to do around release time, localizers are responsible for selecting each of the above for the localized version based on what they believe is best for local users.

Now, for new localizers who request that we add a version where Firefox already has prominent usage, it is important to determine if the services they are suggesting will be measurably different from what is already included in the predominant version in the region.  For instance, I recently asked a Breton localizer if his productization pieces would be dramatically different from what our French version already provides.  If the answer is no, a language pack might be the best best to serve this niche user base.  In this scenario, users download the dominant regional version, and then install the language pack to change the strings to the niche locale.  They use the productization pieces from the dominant version since those were determined to be the same for the niche user base.  (As an added bonus, with an addon like Locale Switcher or Quick Locale Switcher, a user can switch between language packs that are installed on his or her profile.)

In closing, it’s not bad to be a language pack!  I get the sense that somehow contributors might think it is.  We don’t diminish someone’s contribution to an arbitrarily lower level if they are not an “official” localization.  But, for the resource and demand reasons mentioned above, we often like to promote language packs as a solution.

ShareThis

Initially, I sketched out what I thought would be valuable information for the report, ran it by the l10n-drivers, and sent it to the metrics team to start implementation.  In my opinion, an effective report provides both download and active daily user information to our localizers about their locales AND the geos in which their locales are being used.  Let’s review the contents for those who might need a guide.  Feel free to reference the attached screen shots as you read.

Locale-specific information

We are presenting both the download and active daily user (ADU) information (usages statistics and pie charts) for versions of Firefox.  ADUs are based on the blocklist pings we track.  (More on blocklist can be found at Morgamic’s post.)

Geographic-specific information

Each report will show both the download and blocklist for the top five locales inside a country where the localizer’s translated Firefox is most prominently used.  In many cases, this is easy to map.  Locale code “fr” is probably most prominently used in France.  “de” in Germany.  “es-ES” in Spain.  In some cases, we’ll have to make guesses, like for our Kurdish localizers.   Finally, we will provide a list of the top ten countries (by average blocklist pings) where the localizer’s Firefox is being used.

For the first time, our community of l10n volunteers will have a more comprehensive set of data points to help measure the progress and spread of their work.  By providing both locale and geographic information, these reports illustrate the impact that each localization team is providing.

Below are two images of a sample two page report.

and

ShareThis

“In Mozcamp i said, mozilla is no helping just to translate firefox to mayan, mozilla is helping to rescue and make strong the mayan language. Well, i’ll send it and we’ll be in contact.” [sic]

Aw, shucks.  That just makes me happy.

Maybe I have delusions of grandeur as I sit here and sip my Kool-Aid, but I think there is something critical to language preservation happening in the Mozilla localization project for cultural anthropologist and linguists to study.  I’ve discussed this topic with other Mozillans who are interested like Tiffney Mortensen, Chofmann, Staś, John Lilly, Søren Skrøder (Mozilla Denmark), and Kadir Topal (Mozilla Germany).  Every time we ship a new version, even for some of the most niche locales, Mozilla helps just a little bit to preserve the culture of language and communication.  Imagine how unique an experience it becomes for a total newcomer to browse the web with an application whose user interface is both translated and customized for local use.  That can be very powerful and is why we want Mozilla locale count to continue to grow.

To see a little more about what our Mayan friends are doing, check out these links:

• Mayan Firefox language pack
• Screen shot of Mayan Firefox
• Mozilla México en Mérida, Yucatán
• Local press

Do you know of a new localization effort?  I will pay chocolate dipped cake donuts for every referral that becomes a localization.  

ShareThis

Something had to change, but to rectify that problem was a daunting task.  Not only were documents outdated or obsolete, but also they were scattered through the Mozilla Wiki (wikimo) and the Mozilla Developer Center (MDC) like wet leaves across a yard, over into flowerbeds and onto the driveway.

Staś (and the l10n team, but primarily Staś) took up the goal of overhauling Mozilla’s l10n documentation.  One result of a lot of work and many meetings was a Delicious page that we created and titled “Mozdocs“.  If you’ve clicked through on that link, you’ll see our attempt to bookmark and tag *every document written* about Mozilla localization.  This became our base for updating all of our documentation.

The Mozdocs Site

Staś determined that the best way to work was to create an inventory of what we had, categorize that, and then begin work.  And so, we began by finding pages in our documentation and adding them to the Mozdocs page.  We then tagged each page we found with something that described it.

Tagging pages became critical in our ability to work on these docs.  Staś created a set of meta tags that tell us some information about the state of the page.  Namely, does it need to be updated, is it obsolete, does it need to be fixed, should it be deleted, and more.  We also have “location” tags that tell us where we found the document (i.e. my blog, Axel’s blog, Mozilla Wiki, etc.).  Lastly, we have general purpose tags that describe the document.

If you’re interested, Mozdocs could be a very helpful page for you to get a sense of what is in the Mozilla L10n inventory of docs.

New documents, New Naming Guidelines

As foreman of the cleanup crew, Staś also determined that we needed to separate our documents properly.  MDC would serve as the place for docs that describe how to develop and localize and can be abstrated from the Mozilla process.  The Mozilla Wiki would serve as the spot for anything specific to the Mozilla Project’s localization process.

Get that?  MDC = how to/abstract from Mozilla; Wikimo = Mozilla process.

As we created and edited documents, we made sure that they were placed on the proper platform.  Furthermore, we started to rename documents using new “Naming Guidelines“.  If you plan to create a new localization document on the Mozilla Wiki or MDC, we are asking that you use the following (Below is one massive hyperlink to the Naming Guidelines from the previous sentence):

1. Always use the L10n: namespace (wikimo only)
   • Bad: Firefox_productization_guidelines
   • Bad: L10n_Firefox_Productization
   • Good: L10n:Firefox/Productization
2. For hierarchies, use /, not :. This will create breadcrumbs automatically.
   • Bad: L10n:Firefox:Productization
   • Good: L10n:Firefox/Productization
3. Prefer hierarchies than longer names if you need to disambiguate.
   • Bad: L10n:Firefox_Productization
   • Good: L10n:Firefox/Productization
4. If not ambiguous, simplify.
   • Bad: L10n:Product/Firefox/Namoroka
   • Good: L10n:Namoroka
   • Good: L10n:Firefox/Productization and L10n:Mobile/Productization are OK, because L10n:Productization is a more general document.
5. Don’t repeat yourself:
   • Bad: L10n:Firefox/Firefox_Productization
   • Good: L10n:Firefox/Productization
6. Add localization-related tags (on MDC) or categories (on wikimo)
   • On wikimo, use [[Category:L10n]] anywhere in the contents of the page.

Our hope is that all new pages that deal with Localization will follow these naming guidelines.

And now, your turn…

As I mentioned, if you’re interested in scanning the inventory of documents, take a look at Mozdocs and the tags we have created.  This could be a very helpful page for you to get a sense of what is in the Mozilla L10n inventory of docs.

Also, if you are finding new documents, can you please tell us and we’ll tag them on the Delicious site?  Staś is the module owner of this site and we are accepting any “patches” to it.  So, if you want to add something, just let us know and we will make the change.

ShareThis

ShareThis

Last quarter, the l10n-drivers set out to document the steps necessary to make a web site or web application localizable (i.e. designing a project so it can be translated and localized).  All too often, we found ourselves providing feedback on projects that had begun with the intention to reach a global audience, but had not been designed to scale at the intended level.

To illustrate our point, we decided to choose a real life example that we could go through with a team of project managers to document the steps necessary to make a project localizable.  What we needed was a pilot project that had launched quickly to test a concept and see if the idea had enough global appeal that it would require localization.  We chose Get Personas as the test case because it fit our criteria perfectly.  With this project, Mozilla Labs had a site that had launched to prove its concept.  Mozilla Labs often moves quickly and may not have the time or resources to map out just what of its many projects might take off since some of them may not.  In this case, Personas quickly appeared to have global appeal and a need for l10n, but it contained project design flaws that did not have localization in mind from the beginning.

After working for the entire quarter with Mozilla’s Ryan Doherty, who was charged with making the site localizable, Staś Małolepszy, with Pascal Chevrel’s guidance and some from me, compiled all that we learned into several documents now hosted on the Mozilla wiki and on the Mozilla Development Center.  Our intended audience for these documents is marketing and web dev folks.

If you’ve ever wondered what it takes to make a website localizable so it can scale to a global audience, please take a look at this wiki page and its links to other important documentation.

We’ll walk through the piece of this wiki page in more detail in a few forthcoming posts.

ShareThis

Got a presentation or topic you want to discuss?  Email me or comment or this blog and we’ll see how to get it in a slot.  I intentionally left some open blocks so localizers can attend other non-l10n talks of interest.   See you in Prague next week.

ShareThis

“This causes the comment to become irrelevant to the text it references.  Additionally, if someone then fixes the localization note, localizers won’t be notified on this change, and the comment does not get changed in our translations…As some of us are actually reading such comments before translating, it is important to get it 100% accurate.”

Here is an example that Tomer provides.

<!– LOCALIZATION NOTE (bookmarksSidebarGtkCmd.commandkey): This command
-  key should not contain the letters A-F, since these are reserved
-  shortcut keys on Linux. –>
<!ENTITY bookmarksGtkCmd.commandkey “o”>

You can see that example in our code on MXR here:  http://mxr.mozilla.org/mozilla1.9.2/source/browser/locales/en-US/chrome/browser/browser.dtd#110

For those readers who may not be seeing what is happening here, notice that the <!– LOCALIZATION NOTE –> is referencing “bookmarksSidebarGtkCmd.commandkey“, but the !ENTITY variable name is actually “bookmarksGtkCmd.commandkey“.

That mismatch in the entity names has made that localization note untrackable by any locaization tools.  Unfortunately, localization tools will not understand which comment belongs to bookmarksGtkCmd.commandkey.  Furthermore, localizers who use these notes for translations will have to make the educated guess where the comment is pointing.  If the note gets updated in the future, it’s likely that localizers will miss it.

Tomer suggested writing a script to look for these mismatches.  In the very least, I am hoping this post will spread the awareness to developers to remember to do this.  A quick request from l10n community: please maintain localization notes if entities get changed.

ShareThis