ShareThis

Presently, we have two communities, the tzLUG and the Kilinux teams, who have translated the Firefox application into Kiswahili (sw-TZ).  Unfortunately, we have had tough luck in getting an unbiased, thorough evaluation of each body of work to help us decide which one to use.  As it turned out, it was hard to find a number of individuals familiar enough with technical writing and Kiswahili who had time on their hands to volunteer for Mozilla.  Furthermore, we didn’t have an easy package to evaluate, except for the “diff” of the code differences between the two.  Yeah, that sounds ugly and it was.  Still is.

To solve what has become a long-standing debate, we asked each team leader to create a Mozilla language pack of their work as an add-on that we would then host on and promote though our addons.mozilla.org website.  Both teams agreed and uploaded their versions.  Since then, I created two separate “collections” that bundle each language pack with Ben Smedberg’s Locale Switcher addon.  Our hope is that end-users ready to test will install both versions and use the addons.mozilla.org site to provide feedback to each developer team.

If you are interested in testing each version, please install the following two collections:

• Kilinux:  https://addons.mozilla.org/en-US/firefox/collection/kiswahili.kilinux
• tzLUG:  https://addons.mozilla.org/en-US/firefox/collection/kiswahili.tzlug

Once you have installed these, you can switch between the two versions and your English interface by going to the menu item Tools –> Languages…

Now for testing…

Requirements: You must be able to read Swahili and English fluently and you must use Firefox.

If you choose to test these localization language packs, you’ll need to follow something similar to the “Firefox 3.5 Localizer Test Run” that has been created in Litmus, Mozilla’s testing application.  If you use Litmus, please follow the steps I have posted in the first comment on this blog post.

You can also just use each language pack and keep notes of errors you spot.  Whether you choose to use Litmus or not, please record any translation errors that you find in the user interface of each version.  Please be very descriptive and thorough with any notes you keep, and write the notes in English.  Take a look at the word choices, terminology, spelling, grammar, etc. and keep a record of errors you see.  When you are finished, you can submit your evaluation to me.  Just ping me on this blog.

As always, please ask some questions if you have them.  Nothing is off limits.

ShareThis

Here’s a little anecdote on why I believe that.

Although it may be known by some, we try to ship each localized version of Firefox with a language dictionary so users can have the same spell-checking functionality in their native language that en-US users have when writing web mail, blogs, or whatever.  Sometimes, licensing issues determine if we can ship Firefox with a particular dictionary.  If an open source license prevents us from shipping that dictionary, the dictionary still can be created as an add-on and offered to end users from our Add-ons website via the Getting Started page.

This was the case in Denmark.  When a license prevented a dictionary from shipping, our localizers thought creatively and suggested that we feature the Danish add-on on the Getting Started page.  The experiment resulted in a bit of a surprise.  The link became the most popular click-through on the page!  See the attached image I mocked up.

The above image is a “heat map” from the month of May that shows total number of user clicks and the ranking of those links out of the total number of points of interaction on the page.  You can see that the dictionary ranked one out of twenty-eight with 2,216 clicks.  I’d like to think that over 2,000 users added the dictionary after clicking.  When you check the download statistics on the add-on’s page, you can see that it is quite popular.

Where else could we see this benefit to dictionaries?  I suspect that it would be useful to present dictionary add-ons on the Getting Stared pages where bilingual users are prevalent.  Don’t hesitate to make the suggestion to us and we’ll make the change if feasible. And, if you are a localizer who faces a licensing conflict with a dictionary, please let us know.  Let’s put it on the Getting Started page.

ShareThis

1. The addons.mozilla.org (AMO) editor community will use this Xserve to test extensions on platforms where some of them lack access.  They filed this bug, which provides more background on the need.
2. The SeaMonkey team filed a request with this bug to get more virtual machines for testing.  It took us some time to process as we decided what was best and most leveraged.
3. Finally, the server will be used as a place for the IT community (with AMO and SeaMonkey) to test virtualization of OSX.

Just today, I was at a conference and was asked what we mean by providing leveraged resources to our community.  This is a good example.  With the Xserve, we are serving many different purposes:  hundreds of thousands SeaMonkey users will benefit;  all add-on editors can now test on three platforms, which may result in quicker processing of the sandbox where new add-ons go before being listed on AMO; and, the IT community will use the Xserve to test virtualization.

Finally, if anyone is asking, I am still managing community requests, but at a slower pace for two reasons:  community requests have slowed down a bit since we launched the program a couple years back, and localization occupies most of my time so I don’t do as aggressive outreach as I did in the past.  But, we are receiving requests and I do get to them.  If you’ve contacted me about a request, we will respond.

ShareThis

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.

ShareThis

Here’s a link to their Firefox extension.

You don’t have to speak Hindi, Marathi, Sanskrit, Nepali, Konkani, Sindhi, Kashmiri, Bengali, Gujarati, Punjabi, Tamil, Telugu, Oriya, Assamese, Kannada, Malayalam, Arabic or Urdu to see how cool or powerful this is.  But, if you do speak one of those 18 languages, now you’ve got a tool to help create content your constituents can read.  And, that’s thanks to Lipikaar.

I’m blogging about projects like Lipikaar and Heredict because I want to see how we can impact the web in new markets.  Localization is just one small piece.  With website evangelism and the ability to create content, users will start to see dramatic increases in what’s available to them on Firefox and on the Web more generally.

Please help spread this project around if you are in India or speak one of the languages listed above.

ShareThis