-
What Goes Into Reviewing New Locales
Each time we add a new locale to the Firefox build and release process, the files from the new localization team need to be reviewed by the l10n-drivers team before we move forward with the request. For the last eight locales that we added, Pike provided me with a brief, but helpful wiki page that I used to successfully review the new requests. I took that page and bolstered it with more wording to describe what we do for the process. If you are curious what goes into a new locale review, please review this wiki page. (One understandable caveat, it is a work-in-progress and can always be improved with new things to review.)
-
Friday night in SF – Saturday morning in Manila – Same time on the Web
==Log, Friday, March 19, 2010==
18:30: I arrive home after work and return online for a webinar hosted by the community folks in Manila, the capital city of The Philippines where it is presently 09:30 Saturday morning. (I just linked you to another MCS installation, which is a tool created by Gandalf.) Since Gen’s and my visit, a burgeoning Filipino community has been promoting Mozilla with community get-togethers and other activities, including this evening’s webinar on how to localize Firefox
18:45: Audio/Video test with Regnard Raquedan, the local community leader. I share with him my Tokbox video conference URL and we have audio with intermittent video. Not a big deal, with chat room functionality on Tokbox, I can speak and pass URLs to all who attend the webinar. Those with video can see me on a Friday night in my SF apartment.
19:00: Webinar starts with 7 people initially logging in. Introductions made. Active Filipino community includes Regnard, Joel, Kevin, Gian, Bob, Martin, Charmaine, and other guest users joining as we go.
19:15: I pass the following URLs to demonstrate localization:
- How to create a new localization – The centerpiece of our documentation written by Stas (and me) that we believe is the one-stop for all localizers to begin (or reference later when a question arises).
- Localizing with a web tool (in this case Narro) — A sub-article of the above piece. I gave Regnard a few options to look at before this webinar and he chose Narro.
- Narro — The webtool developed by Alexandru, our Romanian localizer, and hosted on our l10n-server.
19:30: I walk the webinar attendees through localization of the two main Mozilla l10n file types: DTD and property files. The demo we constructed has new localizers translating two highly visible strings so they can immediately see the impact of their work. As show in the document in point 2 above, we choose the “Manage Search Engines…” DTD file and the “Add %S” property file as examples of where to start. These strings are located in the search box UI of Firefox. You know where it is, check for yourself!
19:45: The Filipino community offers translations for these two strings and decides which to use. Regnard is the initial Narro admin, so he reviews all the suggestions from the community participating in the webinar. After consensus, he approves the appropriate translations.
19:50: I discuss how we can create a language pack for testing through out the process so we don’t have to wait until all strings are translated to see the fruits of the labor. Narro allows teams to easily generate .XPIs for testing straight from the UI. Regnard can do this for the team and we decide to version our language packs (using the date as the versioning number) so people can keep the archive if they choose. (i.e. Tagalog_langpack_marso_20_2010, Tagalog_langpack_marso_21_2010, etc., or something like that…)
19:55: Final Q&A. Joel asks, “If we install a testable Tagalog .XPI, how can we switch back and forth to our original English-only UI?” I pass along the Quick Locale Switcher add-on. Everyone smiles.
20:00: We end the evening with pretty solid progress having been made. I think the evening was a success. I retire on my couch to watch Cal and Ohio State win their opening round games of the NCAA basketball tournament. Go Bears! Go Buckeyes! I fall asleep before the games are finished, much to the chagrin of my brother who excitedly texts me updates.
==Signing off==
-
The L10n Documentation Overhaul
What could be worse than outdated and disorganized documentation for an open source project looking to grow its volunteers and support its contributors? I’m not sure, but the l10n-drivers had to wake up each day asking ourselves that question about the state of our localization documents.
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):
- Always use the L10n: namespace (wikimo only)
- For hierarchies, use /, not :. This will create breadcrumbs automatically.
- Prefer hierarchies than longer names if you need to disambiguate.
- If not ambiguous, simplify.
- Don’t repeat yourself:
- Add localization-related tags (on MDC) or categories (on wikimo)
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.
-
Nice finds
Now and again, we’ll come across volunteers who speak languages where we do not have a localization, but who look promising to join us for future Firefox releases. We receive references from everywhere: Gerv forwards me names from the comments on his blog; Gen does outreach at conferences he attends and then sends us information; or we find newcomers through our l10n newsgroup. Soon after, one of us then makes contact to see if the people are ready or willing to start our localization process. If the answer is yes, we give them the basic set of documents to get a localization going and we then start the work together, oftentimes with Mozilla’s l10n community helping to answer questions along the way.
Swahili, Romansh, and Oriya are a few in our near-term pipeline. Which languages are in our longer-term list? Maybe you saw Gen’s post about a Gecko-based browser in Khmer. And, here’s a new one: a screen shot from new volunteers who are working on localizing Firefox into Azerbaijani. If you know of some other possibilities, please feel free to share them here.
-
Could a usability change to AMO increase the percentage of compatible add-ons?
I finally got around to updating my add-on that I created last year so it can be used in Firefox 3.5. After finishing the process, I was left asking myself, could a usability change to AMO increase the percentage of compatible add-ons ready for the next release of Firefox?
After going through the process, I’ll say that the https://addons.mozilla.org (AMO) team has done a bang-up job with the developer tools. Take a look if you haven’t already. I took most interest in the stats about downloads and daily usage of my add-on. Those figures have driven me to make my add-on better.
So, here is an opinion on the update experience. Without trying to be annoying, I found the compatibility update might have taken a few too many clicks into the developer tools page. Hoping to update quickly, I entered the developer tools section and then went to “Use New Tools” page pictured right below.
I actually clicked on each of the options that you see above to see how to update. Keep in mind that this is before I read the AMO documentation…someone happened to tell me I could do it through developer tools and I just went there to do it. Eventually, I was able to update the add-on by clicking on its version number (in my case it was 1.0.). From there, I changed the drop down option to 3.1b4pre. You can see that “Compatible Applications” interface below:
Now, It’s very likely that I am the problem here and not the usability of the site. Let’s not rule that out.
But, I got to thinking. It seems that updating compatibility of add-ons is an ongoing challenge that the AMO team faces during each release cycle. This MDC link shows how things have changed and users can log into AMO to update. And, here is a post that describes how addon compatibility will occur for the renaming of Firefox 3.1 to Firefox 3.5. More and more blog posts will come along about getting ready for Firefox 3.5. It’s an important goal for AMO.
But, because I had to click around so much, I started to wonder if we should feature the ability to update compatibility more prominently on the developer dashboard. Sometimes unsolicited advice can be a bit obnoxious, but I sketched a potential change to that developer tools front page. (I also filed this bug for AMO developers to consider.) The drawing is oh-so-simple, but take a look:
My theory is that if we featured this prominently up front, then a subset of add-on developers would update more quickly in advance of each new release. I don’t know how many have zero code changes from release to release, but it’s probably a sizable number. The ability to quickly update compatibility would allow add-on creators to get their users beta testing that much faster. And, perhaps our percentage of compatible add-ons at the time of release of Firefox would go up.
I realize this update took me a while. But, I procrastinated updating the <em:maxVersion [Firefox_Version_number]</em:maxVersion> found in the install.rdf file. Naively, I thought I would have to repeatedly upload an update of my add-on to AMO every time the version number changed for Firefox 3.1 (i.e. ff3.1b1pre, ff3.1b2pre, etc.). I guess I was reading outdated documentation from Firefox 3.0 days and I didn’t know that I could update the add-on straight from the developer tools inside AMO. Mea culpa.
I thought about all this over the weekend because it’s been bugging me that my add-on is out-of-date and incomplete. Then, I learned how to update. Sometime soon, I hope to make it more complete for the release of Firefox 3.5 by preparing it for localization, creating icons that look good on a Linux and Windows, and providing appropriately sized icons for those who use small icons in their browser UI.
For reference, here is the a post I wrote a year ago about writing my addon.
community website
