A quick update: I’m defending my thesis this Thursday, so I’m taking the next two days off to prepare for the defense (and buy a new suit :). I’ll continue the Fennec l10n productization guidelines series (part 1, part 2) right after becoming a graduate of Warsaw School of Economics. Hopefully, that is. See you on the other side!
In the last post I announced a short series about productization of Fennec. This is the second post in the series.
Before we actually start talking about the default services and best choices, we should provide some background on why’s and what-for’s.
There are two main purposes of adding default web services to Mozilla products:
The first one (provide users with useful and relevant content) is obvious: we want to improve our users’ experience on the Web, so we provide a couple of well-thought suggestions for different services. For example, we ship Firefox with 6 or 7 search engine plug-ins to make users’ lives easier when they’re looking for information, translation, products, multimedia, spelling and definitions etc. Another example: when the user clicks on a mailto: link, we suggest a couple of possible handlers chosen from the applications installed on their computer. But we also suggest a few web-based clients (in en-US these are Yahoo! Mail and GMail right now, Hotmail’s coming), so that if the user happens to use one of these in the browser, they don’t have to configure them.
The second purpose (demonstrate certain features of the product) is equally important: by providing these default services, we demonstrate particular features of the product, the ones which otherwise wouldn’t be as discoverable. For example, putting one sample news feed on the Bookmarks Toolbar in new profiles in Firefox helps in learning about the Live Bookmarks. Including a couple of search engines instead of one in the Search Toolbar can help users understand that they can add as many plug-in as they wish. Also the Getting Started page in Firefox was created with this goal in mind: to show users how to get the most out of Firefox and the Web in general.
Overall, in Firefox, the productization includes five areas:
We’re still no entirely sure what the list would be for Fennec, so for now, let’s focus on these 5 areas.
The guidelines for productization of Firefox can be found on the wikimo. Let me quote an important passage from that page:
We believe that localization teams are in the best position to provide recommendations on what local providers we can use for Web Services because you’re in the market, work in the language, and know your users.
The same thing is true for Fennec, or any other product for that matter. The guidelines that we are working on right now are supposed to offer helpful suggestions, evaluation criteria and rules for choosing default web services for your locale. Your feedback on these guideline will be greatly appreciated, because after all, you as localizers will be making suggestions for productization of Fennec is your locale.
Fennec is a XUL-based browser developed by Mozilla and designed for mobile devices. It shares much of the code with Firefox (e.g. the HTML rendering engine, bookmarking and history, download and add-ons management, JavaScript engine), but uses a different user interface, which is adapted to the mobile contexts in which it will be used.
The notion of the mobile context spans both the hardware and the situation in which the user operates. These are very different from what we observe and know from the desktop experience and Firefox. To name just a few key differences:
Just as Firefox ships with a set of default search engines, content and protocol handlers etc., which are adapted to the needs of a desktop user, so will Fennec. The ensemble of these settings is called the ‘productization’. The important thing regarding the web services that make up for the productization of Mozilla software is that they are often specific to a local market. For example, a search provider can deliver a very good quality of search results — but only in a specific country or language, and we have to take this into account when considering default search engines for a locale. This brings us to the need of customizing the set of default web services on a per-locale basis, in order to ensure a good user experience across all locales.
In a couple of next posts on this blog I will try to describe which factors should be, in my opinion, considered important when choosing default services for localized versions of Fennec. The series is intended as a discussion starter and I would like the guidelines laid out in it serve as a base for a conversation about the localization-related needs and issues with Fennec’s productization. As Fennec is still under development, all people involved in the localization process can make an important contribution to the project by bringing to our attention specific needs of their locale.
I’m happy to write this: in the upcoming Firefox 3.0.7 release (scheduled for tomorrow), four three of our beta locales will move out of the beta status!
Congratulations to the localization teams that made it possible!
Seth already did two great posts about our process: So what does “getting new languages ready for release” actually mean? and Moving a locale out of beta, but I thought I’d give some more detail on how the process fits into our code freeze and release schedule.
When we first add a new localization to the tree, it’s in its pre-beta status (let’s call it alpha). This happens after an initial review of the localization by Gandalf or Pike (the review includes checking if the directory structure is correct, the encoding is OK, if all entities are used correctly etc.), at which point a flock of new bugs is filed by the l10n-drivers team, as described on the wiki. These are things like creating a new Bugzilla component for the locale, landing the localization in its brand new repository or modifying the all-locales file for each branch that’s ready. The locale’s nightly builds start to build.
Localizers then continue working on the translation, pushing changes to the repository. At this point the productization and the web parts processes start. The guidelines and the description of the productization process can be found on the wiki. Two bits of the productization process are given special priority at this point: search engine plug-ins setup and protocol handlers setup (e.g. web-based mailto: handlers). We try to find a good and final list of both of this productization bits before the first beta release of the locale, or, if deciding on the final list is not possible straight away, we try at least to only include search engines and protocol handlers that we are sure are final. This is due to the fact that changing them later in the process is hard: once a user installs a beta release, their profile is created with these settings and removing search engines and protocol handlers from the profile gets tricky. For these reason search engines and protocol handler setup are both called ‘beta blockers.’
When the localization reaches a level at which it’s ready to be reviewed by the community, it is given the beta status and is listed on Mozilla.com website under ‘beta locales.’ This is done by modifying the shipped-locales file, which should happen before a code freeze for the next release. (Technically, the changes to shipped-locales are NPOTB, which stands for Not part of the build, so it is possible to land them after the code freeze, but is not preferred.) We also need to modify the product-details files which manage which versions are offered to download on Mozilla.com (e.g. on the all.html page). This is done by the WebDev team and the bug needs to be filed a couple of days before the release.
At this stage we can start gathering feedback from the users testing the release. Feedback can be anything: spelling or grammar mistakes, better wording suggestions, font rendering issues, dialog sizes, better suggestions for productization (this is why deciding on the final list in the previous step is preferred – it allows us to gather feedback on productization from users too) etc. This is a very important stage and the feedback that the localizers get from beta users helps improving the quality of the final release.
All fixes to the issues reported by the testers need to be landed in a timely manner before a code freeze. A couple of simple rules should be followed:
For example for the 3.0.x branch, if a localizer wishes to modify the translation (e.g. fix a typo), we ask them to file a bug and request a review of the patch. The reason for this is that we want to make sure that 3.0.x builds are green at all times (in case of an emergency in which a ultra-quick build is required to address a security hole, for example). Hence the review&approval process for all l10n changes on the 3.0.x branch.
While the locale is in beta, we also continue to work on productization and web parts. If not chosen before the beta release, we can now choose a news feed that will be featured on the bookmarks toolbar as the live bookmark or select a couple of good and popular news readers that will be offered to the user when they wish to subscribe to a feed. We also focus on the Getting Started page and other web parts, managed by Pascal. Since the web parts are served from the Mozilla.com servers, no changes to the l10n code are required to publish them. Consequently, it is possible to work on them even after the code freeze.
During all this time, the l10n-drivers team meet at least once a week for a so called triage call (Tuesdays at 6 PM CET / 9 AM PST) when we monitor and discuss the progress of the de-beta-ing process. We go through open blocker bugs for each locale and update a wiki page on which we track the whole process (for 3.0.x that’s Triage:3.0.x). From time to time we e-mail the localizers to discuss next steps, ask about the current feedback and offer help. We’d like to do a good job in this field, so if you are a localizer of a beta locale, please give us your feedback on how we did in the comments below, by e-mail or via Rypple (it’s completely anonymous).
If statistics are available, we look at the usages figures (ADU numbers and downloads) to see if they are increasing. This is a good indicator that end-users are, at least generally, satisfied with what is available. Finally, when the localizers feel good about their work, there are no more open blocker bugs, the feedback from the users is positive and the testing of the builds under all three platforms hasn’t showed any rendering/display/sizing/other issues, the decision to move the locale is taken. A couple of days before the release the product-details files are changed again to make sure that the locale will be listed as final, not beta (for 3.0.7 the bug for this was bug 480391). The release notes are changed accordingly. And when the release day comes, we party :)
UPDATE: Originally we also intended to de-beta Occitan (oc), which was on the list above, but it turned out that bug 454169 was still open. Stay tunned for 3.0.8! :)
As you probably know, minor releases of Firefox, denoted by the third digit in the version number (or fourth in case of 2.0 releases), are intended as security and stability updates. The idea here is that there shouldn’t be any significant changes to the user interface or browser behavior between, say, version 3.0.6 and 3.0.7. We don’t want to secretly surprise users who just installed a security update by introducing a new interface.
Changes to productization of Firefox are such interface changes. Replacing a news reader with a different one or adding a search engine plug-in are good examples. They should be only changed in major releases. For 3.0 there was a major review of default web services for every locale (there was a review bug for every locale), and we will probably do something similar in the future too (Firefox 4 anyone?).
For the 3.1 release, we’re going to mostly stick with choices made for 3.0, but it’s a good opportunity nevertheless to make changes to productization of Firefox in your locale, if you feel that users will benefit from them.
It’s also a good moment to check if there aren’t any outstanding changes that were supposed to happen earlier (e.g. for the 3.0 release), but for some reason didn’t happen. Today I worked with András Tímár from the Hungarian team and we were able to fix bug 478878, bringing 3 new search engine plug-ins to Hungarian Firefox. Thanks Andras for a quick turnaround!
If there are any similar web services related bugs or requests for your locale that went unnoticed in Bugzilla, please ping me in IRC (nick: stas) or leave a comment below. I’ll do my best to look into all of them in the near future.
© Staś Małolepszy. Powered by WordPress, theme based on the DePo Clean Theme.
