Litmus is a great tool used by our QA community for testing purposes. With a wide range of test cases grouped in test runs, it’s probably safe to say that it covers all aspects and features of Mozilla products. You can read all about Litmus over at QMO, in the Litmus tutorial.

If you want to test your localization of Firefox 3.5 using Litmus, the best place to start is the 3.5 l10n test run. It’s a great way of giving your testing a structure, which will help make sure you cover all localization. It’s also very helpful when testing periodically—by following the test run, you’re sure not to miss anything that you tested last time.

To do a Firefox 3.5 l10n test run for your locale, go to the Firefox 3.5 l10n localizer test run on Litmus and sign in. You can also created a new account if you haven’t already. Or, go to litmus.mozilla.org and choose Firefox 3.5 l10n localizer test run from the list of active test runs. (You may have to click View all available test runs at the bottom of the page first.)

Next, fill in your Build ID, Platform and Operating System, and, most importantly, your locale. Click Submit configuration. On the following page you’ll see testcases subgroups available in this test run. Right now there are no testcases in the RTL (right-to-left) subgroup, so just click Submit in order to proceed.

As of this writing, there are 23 testcases to go through, and for each of them you can indicate a result: not run, pass, fail or test unclear/broken.  Please leave a comment when a testcase fails or the instructions are unclear or outdated.

When you’re done (you don’t have to do all testcases at one time), just click Submit All Results. Congratulations, you’ve just contributed to the testing efforts to ensure best quality of your localization!

There are other test runs available on Litmus, many of them more detailed and more thorough than the l10n test run (e.g. the catch-all test runs). You’re encouraged to perform these tests to provide even more testing coverage for your locale, but generally they’re not required to move a locale out of beta.

You may also be interested in seeing how much testing has already been done for your locale. It’s simple. Just go to the Search Results page, choose your locale on the far right and hit Show Results. You may also want to specify the product, branch and platform, as well as the timespan (e.g. show only tests performed in the last 2 weeks).

If you’d like to have more information about how to use Litmus, be sure to check out the tutorial on QMO. If you have questions, don’t be shy and do ask us in #l10n or #qa.

For development, the process takes place simultaneously on several branches. For example right now, we work on trunk (mozilla-central, Firefox.next), 1.9.1 (releases/mozilla-1.9.1, Firfox 3.5) and 1.9.0 (CVS trunk, Firefox 3.0.x). When a bug receives a patch, it first lands on trunk, and the bug is marked as fixed. Then it lands on branch(es), after getting needed approvals, and the bug is given the fixed-* keywords, for instance, fixed1.9.1.

I have a feeling that this workflow doesn’t fit well into the localization process. The localization efforts often focus on only one branch. In the current case, that’s 1.9.1. Some localizers like to keep their 1.9.1 and central repos in sync, and that’s great, but we don’t require them too. If they prefer working on 1.9.1 only, that’s perfectly fine. After all, strings on trunk have higher probability of changing, so it’s understandable that someone prefers to wait until they stabilize. I.e. until they land on a more stable branch.

So translations land first on 1.9.1, and for many localization, they will only be pushed to central after the 3.5 release, at which point central will no longer be central, but will be given its own branch. The process will start over: the localization efforts will focus on this branch, because this is where the next major release of Firefox will come from.

As you can see, for localization the workflow is reverse: we first translate on the more stable branch, and then port over to the dev branch (trunk). And this is what made me start thinking whether we should change the rules of marking the bus as fixed.

Why is this a problem? Let’s take Assamese as an example (just because it illustrates my point quite well and I’ve been working on it recently). Bug 443139 is the Firefox 3.5 release tracker for Assamese and it’s blocked by a couple of bugs that will need to be resolved before we can release Assamese version of Firefox. In fact, most of them have been already resolved, so we’re really close to releasing Assamese. Congrats to the Assamese team :)

If you look for example on the “Firefox 3 RSS reader setup for Assamese” bug (bug 443145), you’ll notice that it was marked as fixed and has a fixed1.9.1 keyword. That’s because it was fixed on both trunk and branch. So the bug’s status is now “resolved fixed” (thanks to the landing on trunk), and it doesn’t block the release tracker anymore.

But now take a look at the “Search engine setup for Firefox 3 for Assamese” bug (bug 443142). The fix landed on 1.9.1 only, so the bug has the fixed1.9.1 keyword, sure. But since it hasn’t been yet fixed on central (for Firefox.next, mind you), the bug’s status is “new”, and it is still blocking the 3.5 release tracker. Why the lack of landing on central should block a 3.5 release?

That’s a problem for me, because it makes using and following the tracker bugs harder. Of course the right question to ask here is “if we mark this bug as resolved fixed right now, how do we make sure that the fix lands for Firefox.next, too?”. I don’t have a good answer to this yet. But even in the current workflow, if the fix lands for Firefox.next after mozilla-central gets branched again, will we mark the bug as fixed, or maybe just add a fixed1.9.2 keyword? (or a different one, depending on what the name of the branch will be).

I don’t have any concrete proposals right now to address the problems described above. I feel that we should just resolve bugs as fixed when the fix lands on current next-major-release branch (1.9.1 these days). We should still use keywords to make it easier when looking back at fixed bugs to figure out on which branches they were fixed. Lastly, next time we branch from trunk, we should somehow make sure all the fixes are included. I’m not yet sure how, though.

What do you think? I wanted to share my thoughts on this out in the public. I’d be grateful for your comments!

• Добре дошли, хора!
• Planvenguts umans !
• मनुष्यांचे स्वागत आहे!
• (Welcome Humans!)

Many thanks to Ognyan (Bulgarian), Sandeep and Priti (Marathi) and Yannig (Occitan) for their continuous work on the quality of the localization and awareness of it among local users. The 3.0.9 release is a culmination of weeks and months of the efforts by these guys, both on the localization front (translation, productization, web parts, testing) and the promotional one (advertising the beta builds, getting feedback from beta users, increasing awareness of the browser etc.). Good job!

Thanks for all the bugs we fixed together. Looking forward to working with you again soon on next updates and versions of Firefox.

This race is only about to start :)

• Estonian (et)
• Kannada (kn)
• Telugu (te)

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:

1. Changes to translation on the development branches can be landed freely.
2. Changes to productization on the developement branches additionally require a review (r+) before they can be landed.
3. On stable branches, all changes to localization (translation and productization) should be reviewed and approved by the l10n-drivers team.

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! :)

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.

Once the bug is fixed, we will be able to add Mibbit for all other localization that will want it. I just filed the bug on that: bug 479030. The change itself will be done en masse, so we actually just need your “OK”. So:

If you would like to have Mibbit added in your locale, please update the whiteboard in this bug with your locale’s code.

Although Mibbit is currently localized only into French, German, Spanish, Dutch and Portuguese (Brazil), our recommendation is to add it to all locales, even if most of them are not supported right now by Mibbit. It will serve well as a demonstration of this kind of protocol handler and it will be useful for users familiar with English. We do a similar thing with 30boxes, our en-US webcal: protocol handler. We ship with it in almost all locales even though it’s available only in English.

If you wonder what an IRC protocol handler can be good for, just head over to MDC where you can see a couple of irc:// links in action. Just look on the right, under the Discuss in IRC header. I can easily imagine this kind of links on other Mozilla sites, e.g. on SUMO, or on local communities sites.

Ah, one more thing: if you know of another IRC web-based client available for your locale that you would like to include, please file a new bug under Mozilla Localizations > {your locale} with the following summary: “[{your locale's code}] Add {service name} to the default IRC protocol handlers.”

Pod koniec zeszłego tygodnia, raczej po cichu, wystartowała ankieta pt. Firefox w Polsce: kto używa Firefoksa, dlaczego go używa i w jaki sposób. Chcemy poznać Wasze opinie nt. tego, dlaczego w Polsce ludzie używają Firefoksa, nt. funkcji, które są w naszym kraju najważniejsze i nt. czynników, które w największym stopniu hamują Firefoksa. Interesują nas też oczywiście pomysły na promowanie Firefoksa :)

Do ankiety zapraszamy wszystkich: użytkowników zaawansowanych, tych, którzy dopiero co spróbowali Firefoksa, a także tych, którzy jeszcze się do niego nie przekonali :) lub po prostu wolą inne rozwiązania. Opinie Was wszystkich będą dla nas niesamowicie cenne.

Namawiamy także do poproszenia o wypełnienie ankiety Waszych znajomych i rodziny, także jeśli nie używają oni Firefoksa.

Tak więc: wypełnij ankietę! :)

PS. Dziękuję koleżankom i kolegom z Aviary.pl za pomoc w rozgłaszaniu informacji o ankiecie i za korektę językową.

PPS. O ankiecie po angielsku pisze Jane Finette.

Jest to nieprawda.

Wydaje się, że ktoś miał na początku ochotę na prowokacyjny nagłówek:

Organizacja SuMa-eV podała, że również Firefox wysyła dane o użytkownikach do Google.

Szybko jednak się poprawiono (za co dziękuję), bo w uzupełneniu czytamy (choć to wciąż nieprawda):

Organizacja dodała również, ze w żadnym wypadku Firefox nie wysyła informacji o odwiedzanych serwisach do Google. Dopiero jeśli znajdzie wśród nich adres znajdujący się na liście, odpytuje Google’a, czy ten wpis jest jeszcze aktualny. W skrócie można powiedzieć, że adres URL jest przekazywany wtedy, gdy uważąny jest za szkodliwy.

To jaka jest prawda? Prawdą jest, że co 30 minut Firefox pobiera aktualizacje listy podejrzanych stron, a więc dane o odwiedzonych stronach nie są wysyłane do Google. To Google wysyła użytkownikom Firefoksa listę podejrzanych stron, a Firefox (lokalnie, na komputerze użytkownika) sprawdza, czy odwiedzane strony nie znajdują się na tej liście. Choć też nie do końca – aby zrozumieć, jak to dokładnie działa, trzeba wiedzieć że lista ta nie składa się z URL-i, tylko z tzw. hashy. Specyfikacja podaje przykład:

Input is “abc”

SHA 256 digest is ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad.

The 32-bit hash prefix is ba7816bf.

Firefox przechowuje lokalnie listę 32-bitowych “przedrostków” hashy (hash prefixes) i aktualizuje ją co 30 minut (podczas aktualizacji, Firefox pobiera tylko informacje o dodanych i usuniętych stronach, a nie całą listę). Każdy odwiedzany URL jest hashowany i jego prefiks jest porównywany z tą listą. Jeśli jest na niej obecny, to Firefox prosi Google o wszystkie pełne 256-bitowe hashe, które pasują do danego prefiksu. Tak więc jedyne, co może wiedzieć Google, to to że użytkownik odwiedził którąś z N stron (gdzie N jest duże), których hashe zaczynają się od wysłanego przez Firefoksa prefiksu. Dodatkowo, nie widomo dokładnie, jakie to strony, bo hashowanie jest procesem nieodwracalnym, tj. z URL-a można zrobić hash, ale z hasha nie można zrobić URL-a.

Dzięki takiemu systemowi, lista przechowywana w Firefoksie jest niewielkich rozmiarów, zawiera bowiem tylko prefiksy. W przeciwnym wypadku jej rozmiar liczony byłaby prawdopodobnie w megabajtach, co uniemożliwiałoby tak częste jej aktualizowanie (i narażało użytkowników na większe niebezpieczeństwo).

* * *

Po premierze Chrome w sieci pojawiło się wiele artykułów o Google i o Firefoksie. Wiele teorii, porównań i czasami zarzutów. Krytyka jest dobra i potrzebna, ale warto też sprawdzić najpierw, czy słuszna :)

Wczoraj o 19:00 Mozilla ogłosiła wydanie Firefoksa 3. Zainteresowanie na całym świecie było olbrzymie i na samym początku serwery nie wytrzymały, ale już po godzinie udało się wszystko naprawić. Z tego względu, Dzień Pobierania trwa do godziny 20:16 dzisiaj w Polsce (18:16 UTC).

W tej chwili liczba pobrań wynosi 5 445 604. Po zaledwie 15 godzinach! Obie Ameryki już śpią, więc obecnie to Azja pobiera. Europa niedawno się obudziła i cały dzień dopiero przed nami :-)

Ponieważ w Księdze Rekordów Guinnessa nie ma jeszcze zapisu o pobraniach aplikacji w ciągu 24 godzin, Dzień Pobierania to próba ustanowienia nowego rekordu, a nie pobicia już istniejącego. Aby mieć jakiś punkt odniesienia, chcieliśmy na początku przebić wynik z 2006 roku, kiedy to w ciągu jednego dnia Firefox 2 został pobrany 1,6 miliona razy.

Wczoraj ten wynik osiągnęliśmy po 5 godzinach :)

I pędzimy naprzód. Udział Firefoksa 3 w rynku wzrósł w ciągu tych 15 godzin z 1% do 4%! Pobiera cały świat, bo Firefox został jednocześnie wydany w 46 językach. Czy ro przypadkiem nie zasługuje na kolejny rekord świata?

Z okazji wydania trójki, na świecie odbywają się w tym tygodniu spotkania użytkowników. My w Polsce też zachęcamy do organizowania takich spotkań: wystarczy umówić się ze znajomymi w pubie czy kawiarni i ogłosić to na stronie Mozilla Party. Aviary.pl będzie obecne na dwóch takich spotkaniach: w Krakowie (w sobotę) i w Warszawie (w niedzielę). Zapraszamy!

A tymczasem, pobierz Firefoksa przed 20:16 :)