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.

On the day we released, our community found two very similar errors in our mk and sr builds.  In both cases, a misspelling of &brandShortName; inside an <!ENTITY> triggered the “the yellow screen of death” when users selected the Help -> Check for Updates… option to get the new version.

A thousand apologies to our localizers and mk and sr users for not catching these errors pre-release.

With damage control in full swing, we removed the two localizations from the Firefox 3.5 release channels so that users would not receive a broken version of Firefox. The two localizers and the l10n-drivers then worked through our options.  We could either release a special post-Firefox 3.5 Macedonian and Serbian version, or wait until the release of Firefox 3.5.1.

The unexpected timing of the Firefox 3.5.1 release helped us with the above decision.  Although the circumstances of the security update were not ideal, it did allow us to release mk and sr earlier than expected, getting users of those localizations back on the release track. Furthermore, any users who might have gotten the broken mk or sr version of Firefox 3.5 on release day will be updated behind-the-scenes without having to check for updates.  [1]

What happened on the 3.5 release day underscored a few errors in our system that need to be fixed. Here are the proposed and soon-to-be or already implemented measures we are taking to reduce this margin of error:

• Localization sign-off via the Web: Rather than opting-in with change sets, localizers will soon select the Mercurial change set they want to use for a release from a list of IDs pulled from their locale’s repository.  How does this help?  In Macedonian’s case, a localizer *had* submitted to Axel a change set that corrected the error prior to RC3.  However, Axel was unreachable at a conference and couldn’t relay that update to me.  Sadly, I submitted the incorrect change set.  Mea culpa.  This application allows localizers, l10n-drivers, and Firefox project managers to view the choices that have been made, and to the extent possible, test to make sure that the version the localizer wants is good for release.
• Test automation: We are working on creating a script that can be run by our QA team before each milestone that will scan for misspellings in things like &brandShortName;. This bug is tracking that progress.  Our QA team also is increasing the number of automated tests that will be run on each locale before each milestone release.
• L10n-testable builds: Presently, we are producing testable nightly builds with Axel’s l10n-merge code that will create localizations with en-US strings replacing any untranslated ones.  Now, localization teams can give their testing communities something to test from the beginning of the release process.  In the past, localizers had to wait until they had 100% translation before we provided them a nightly build.
• Localized builds with nightly updates: Added to the testable builds above, we’ll soon be able to offer nightly updates to localizers and their testing communities.  Right now, only en-US testers of Mozilla’s pre-release versions get nightly updates pushed to them.  Soon, *all* localizations will get these nightly updates pushed their way so our global testing community can see the most recent additions made by Mozilla’s developers.

These tools empower the localizers and the testing community, and we believe will help narrow our margin of error so that we don’t repeat what happened to our mk and sr builds.

Many thanks to our Macedonian and Serbian localization teams for their understanding and patience and sorry for the errors discovered at the time of the Firefox 3.5 release.

[1] Mozilla developer rstrong and his team fixed this bug and cleaned up a lot of code for the Firefox 3.5 release so that users of Firefox get updated behind-the-scenes without having to check for updates or get prompted unnecessarily if they want/need an update.

——————————————–

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/:

1. Always include the Build ID that you tested on.  If you type about: in the URL bar, this will give you the Build ID.
2. Always include clear “Steps to Reproduce” the bug.
3. Always check to see if your bug has already been filed.  This link will help: http://tinyurl.com/2465be
4. 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.
5. 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!

• Philipp Kewisch, who is our first participant in the Community Loan Program.  He is helping on the Calendar project.  Philipp has been a critical member to the team and figured out how to make Lightning read and write to Google Calendar.  He is working on better integration of Lightning with Thunderbird.  I asked Philipp if I could include any specific information about his work and he wrote back:”My next big feature will be a patch to bug 353492, to allow support for multiple alarms and also different alarm types. This in turn will allow specifying Email and SMS type reminders for the Provider for Google Calendar. This will be integrated after the 0.8 release.”The unique aspect of Philipp’s participation in the Community Loan Program is not only that he is the first to participate in this new subset of our program, but also that he has mapped out a 1 year project timeline of what he hopes to be doing with the new Dell that we are lending to him.  In that year, he hopes to really advance the calendar project and has set specific metrics to hit.  Together, we will regularly check in on progress and revisit his accomplishments quarter-by-quarter.  After one year, we’ll reassess and see if he is ready to move on to something new, or let another developer use the resource that we are lending.

• Kai Engert:   Kai did some tremendous work to get us working on yet another mobile device.  Because of his great work and continued dedication to Mozilla, we are reimbursing him for the hardware that he purchased.

• Henrik Skupin:  Henrik has been very active doing Mac QA.  He does not have the Leopard OS, so we are purchasing him a Mac Mini and I am going to see if it makes sense for him to also participate in the Community Loan Program.  We’ll meet at FOSDEM in Brussels to discuss more. For some stats, a quick query indicates comments in 2195 bugs.  Lately, he has been very active verifying trunk bugs for QA.

• Babelzilla:  We’ll pay the annual hosting costs for Babelzilla.  If you’ve visited Babelzilla, you’ll see that it is a very vibrant part of our community, creating a platform for extension developers to have their extensions localized into other languages.  Jürgen Berg has been my community contact and his been very understanding and helpful.  The payment has been a bit of a logistical nightmare, mostly due to my own fault because I accidentally requested a monthly payment be sent rather than the entire year.  Manitu is the hosting company and has been very understanding.  Thanks everyone, and sorry for the delay!

I think it’s an important time to recognize that in a little over one year, this program has distributed over US$ 315,000 in resources to the Mozilla community.  We have looked at each request carefully to ensure that it fits with the goals of the program.  In the coming year, I’d like to continue to focus on leverage, rather than set our sights on any dollar amount.  Dollars rarely mean success, unless they’re spent wisely.  So, we’ll continue to seek leveraged ways to support our community.

What did I learn in this process, and what, if any, valuable takeaways from this process are worth sharing?

Here goes…

This is one of the first major events that I helped take a lead role in planning.  Mary Colvig is our event planning manager and has been a long standing member of Mozilla’s marketing team.  (If she had a blog, I’d link to her…but no…though she’s thought about it, apparently.)  Mary’s brought some nice rigor to this process.

Here are some things we agreed were important for this trip to succeed:

• Create clear goals and potential outcomes if we were to participate;
• Enlist key constituents from the Mozilla community and Mozilla Corporation to help in the decision process;
• Host weekly, purposeful meetings to discuss updates;
• Divide tasks among all involved in planning;
• Carefully craft and adhere to a budget;
• Gather approval from senior staff that we should do this.

I had a few clear cut goals that I knew I wanted to push if we were to participate.

1. Riding the momentum from our trip to India in late July, use FOSS.IN to grow, build, cultivate our Indian developer community;
2. To get as many Indian localizers together so we can add a few more languages to our list of localized languages;
3. To test Firefox in India, creating an evangelism community who can either help file bugs and/or reach out to web developers who sites might not work on Firefox;
4. To explore and learn about other issues for Indian Web users that will help us better serve users in the region (fonts and font rendering has been an issue in the past…likely to change with Firefox 3).

To accomplish these goals, we proposed the project day, a large undertaking by me, Mary, Chofmann and a few others.  I wrote the first draft of the proposed events, sent it around for feedback, incorporated that, and then finalized the proposal.  We were then accepted.  After a few enthusiastic meetings, we were suddenly in the midsts of many moving pieces seeming to come from different directions, all colliding at one intersection.  (random picture illustrating how we felt…)

From one side, we had FOSS.IN asking us to prove that this would be a valuable, contributor-focused day.  The conference organizers were NOT interested in having another discussion about a product or applications of a product.  They asked us to come to the project day with some interesting projects to work on.  They wanted us to get into the code and work!

Another side came from a set of key decision makers we asked to help think about this day.  The questions we repeatedly had to answer,

•  ”What value will this bring to the Mozilla community?”
•  ”Is this a good use of resources and is it a leveraged way to build and empower community members?”
•  ”If someone is going, is it a good use of their time or would their time be better used elsewhere?”
•  ”How will each Mozilla participant contribute to an effective project day?”
•  ”What are the deliverables of this event?”

Finally, we had emails from contributors, colleagues, and new friends asking how they could participate in the day and where their talents could be used.   With an approved project day and set of events, we had to figure out how to incorporate everyone and meet everyone’s objectives.

Moving parts.

What lesson did I reinforce?  As always, get buy-in.  Have clear goals that are both valuable to Mozilla and attainable.  Collaborate openly.  Be creative.  Communicate.  Sure, you might think these are so obvious.  They probably are.  But, tying clear goals and outcomes like these to event planning is something we are trying to do more systematically.  For FOSS.IN, it’s worked for the planning.  We’ll see how the day goes in early December.

And, if you’re going to be in Bangalore for the conference, please do consider attending our project day.  I think it will be a huge success.

We’ll look at the following:

1) Hosting and other support for the extension localization project: Babelzilla

2) Hosting support for FoxieWire

3) Support for a QA team member who focuses on Mac platform bugs

4) Setting up a VM for Sunbird community to do their own builds

5) Support for a platform engineer for Firefox.

I’ll report back when I can. I’m especially excited because this time around, we’ll have two new participants in the meeting. I’ve been trying to expand the group and rotate in a few spots so other long-time contributors/module owners/employees/etc. can observe and participate in the process.

Also, Asa and I will be planning our Q3 goals for what we can do to empower more members of our community this week.

(non-sequitor) Finally, I am one of the masses that bit and got an iPhone last Friday when it came out. I was in L.A. for a wedding and ducked out of the rehearsal dinner to text a friend to get me one at the Apple store. One of my friends and fellow groomsmen was lead on marketing communications for the iPhone launch and was watching me pretty intently as I unpacked the device for the first time. Have to say…the Apple team did a terrific job on the experience. I am sure it took countless emails, Powerpoi…er…Keynote presentations, meetings, and TPS reports to get it all together. I was thoroughly impressed at the detail and sleekness of the packaging. Nice job on that, Apple.

The phone is certainly very cool. Being mired in the open-source world, I am disappointed that you can’t add any applications and the phone itself is so locked down. But, I can get past that because the phone is way better than any other mobile device I have ever used.

To the dismay of Apple, I am still using Thunderbird and Lightning as my main email and calendaring clients. Ever since Philipp figured out how to allow read/write to Google Calendar (and since Mac’s iCal can read Google Calendar), I use Lightning in Thunderbird. And, my iPhone syncs with iCal, which is reading my Google Calendars, which are getting all their content from my Lightning calendar extension in Thundebird…phew…did you follow all that?

http://quality.mozilla.org/

Also, this request was posted by Tomcat:

If you haven’t already, please create a QMO account and help us pick the official QMO logo!

See the choices below:

In blue…

or….in green….

Calling all Vista-Community Testers!

Please join the Mozilla QA community for Testday on Friday, June 8th, 2007. This week, we will be testing the new Gran Paradiso Alpha 5 Build and also at Thunderbird 2.0.0.4

The event will run Friday, June 8th, 2007, from 7am – 5pm PDT

Please visit http://quality.mozilla.org/events/test-days for all the info regarding the event.

You can also find also more information about the Thunderbird 2.0.0.4 testing on http://wiki.mozilla.org/Thunderbird:Current_QA_TestDay

Jump into the #testday channel on irc.mozilla.org on Friday to participate. We hope to see you there!

And, if you’re also like me, you might not be able to delve into the depths of debugging something wicked hard, but you want to help Mozilla in an important way.

Or, maybe you just want a break from your day to help out with Mozilla a little bit…

Try participating in our QA testdays. This couldn’t be easier…honestly, I did it today, and it’s fun.

Here are the steps

1) Check out the Q.M.O. Blog to find out when the next test day will be, or follow the latest wiki page describing everything for the test day;

2) Create an account on Litmus when the next day comes up and then log-in;

3) Take Tomcat’s Tutorial on how to use Litmus (this is a great and easy-to-understand tutorial…Thanks Tomcat!);

4) Start testing the latest builds of Mozilla’s software.

Honestly, this couldn’t be easier and it is definitely a great way to contribute. Hope you give it a try. Today’s test day will end at 5 PM (Pacific Time). If you can’t log into today, sign in next time. When you arrive to test, you can always log into IRC (irc.mozilla.org [#testday]) to collaborate with other testers.

Just follow the wiki page or the QMO blog that describes what will be happening. Again, here is the page for today.