Now that the bug to show days, hours, minutes, seconds for download times [bugzilla.mozilla.org] has landed, there’s some new neat things to use to help support localization of plural strings [ed.agadak.net] as well as making download progress texts consistent.

PluralForm for Developers
To get the correct plural form of a word in Firefox or an extension, the javascript file just needs to import the module and call a method.

// Load the module at the top of the javascript file
let Cu = Components.utils;
Cu.import("resource://gre/modules/PluralForm.jsm");
// Get "word" or "words" based on the number
let word = PluralForm.get(number, "word;words");

In this English example, there’s only two words, but other languages might need fewer or more. More information about what string to give to PluralForm.get() for various languages is on the devmo wiki page Localization and Plurals [developer.mozilla.org].

So anywhere in your code you’re doing something like..

let string = number == 1 ? singular : plural;

.. you might want to consider using the PluralForm module.

PluralForm for Localizers
To help localizers make sure they’re correctly localizing the plural strings, I’ve created a pluralForm Checker extension [ed.agadak.net xpi 3.6 KB].

Strings can be checked to have the right word for a corresponding value

With this tool, localizers can list the property files and properties that have plural forms to check. Each string is split up into its appropriate plural form and there’s a sample output display at the bottom for the first few numbers of each plural form.

Notice that “words” don’t necessarily have to be a single word.

pausedDownloads=One paused download;#1 paused downloads

Of course, for a language that has multiple values that are treated as singular (1, 11, etc.), the first paused string can’t be hard coded to “One”.

DownloadUtils
In fixing the bug, there is now also a DownloadUtils.jsm module [mxr.mozilla.org].

This provides some useful methods for downloads such as displaying file sizes, transfer times, and download locations. Once again, it’s loaded just like PluralForm.jsm using Cu.import(), and it can be used in Firefox or extensions.

For example, right now the automatic updates dialog still uses the old download strings from long before: “1.2 of 8.4 MB at 146 KB/sec; 00:32 remain”. We could use DownloadUtils to make it consistent with the redesigned Download Manager for Firefox 3 to be “32 seconds remaining — 1.2 of 8.4 MB (146 KB/sec)”. This mean it would also get the benefits of being able to display “days, hours, minutes, seconds” and “GB, MB, KB, bytes” as well as time smoothing. (Hopefully updates never take that long or are that big.. 😉 )

This DownloadUtils.jsm module helps simply implementing download related displays such as the new download activity summary in the status bar [bugzilla.mozilla.org].

Download Activity Status Bar
Thanks to Michael Schonfeld, we can now monitor downloads from the status bar! 😀

Michael first uploaded a patch to the bug [bugzilla.mozilla.org] out of nowhere about a month ago. I had him wait on me because he would be running into issues with plural forms and download strings. After I landed the patches for PluralForm and DownloadUtils, Michael was able to quickly update his patch in about an hour to be ready for the l10n string freeze. (Additionally, the original patch went from 22.13 KB to 5.76 KB just to show how much the modules simplified things. 🙂 )

A brief summary of downloads for easy user monitoring

Personally, I’ll be turning off the preference that shows the download manager when a download starts. I can now open files without having an extra window pop up while still knowing how much time it’ll take. As for saving files, I can easily alt-click links to save many files at once without being interrupted with the download manager flashing.

For the work on the AwesomeBar [ed.agadak.net], I’ve noted before that getting relevant results [ed.agadak.net] in the location bar to select is important before the adaptive behavior is useful.

A friend of mine pointed out that if he knew multiple words in the title, typing both resulted in no results instead of seeing some results if he typed a word individually. This is because Beta 2 tries to match the whole input against either the title or url of a page.

Drilling down results with 3 words matching the title

Instead of getting rid of all those good results, we can treat each word separately and match them in different places in the title. This lets the user incrementally filter out results by typing words s/he see from the current results.

But what if you knew the domain and a word in the title? No problem! 😀

Matching the url and title at the same time

Here’s some builds that you can use to test things out: Win32 zip (installer exe), OS X dmg, Linux tbz2 [build.mozilla.org].

These include the incoming changes for “global frecency” as well as adaptive learning. So as an additional bonus, the browser will learn which pages you’ve selected after drilling down and show it first the next time — even when you’ve only typed the first word. (I haven’t changed the UI, so it doesn’t show which words matched, but the results will be there.)

There has been plenty of work by developers to get the results to show up immediately, so comments on performance are appreciated. 🙂

Edit: I just realized things might be initially slow because of the “global frecency” migration for existing profiles. So if you don’t do anything in the browser.. leave the room, grab a drink for a few minutes, things should go faster after it calculates some frecencies for your pages.

It’s been over two months since I first posted about the AwesomeBar [ed.agadak.net], and some of you have been able experience the power of the learning behavior. Frequently visited sites are easily accessed with just a single letter. These “automatic bookmarks” bubble up to the top of the location bar autocomplete list just after selecting a result once.

However, I noticed that the list contained many “random” results below the adaptive learning results for these single-letter-bookmarks. Looking at the highlighted portions, they would be in the middle of words and all over the url. Or in the case of ‘p’, the list would contain pages that matched http which isn’t too useful when searching.

Random results for ‘n’ (or ‘p’) in Beta 2

The adaptive learning won’t be useful if the user can’t find anything of interest to select out of the list. Sure, one could keep typing and typing to filter out more pages and find something specific, but that requires typing more.. (and people are lazy! 😛 )

So I decided to improve the quality of the pre-adaptive results [bugzilla.mozilla.org]. Now matches near the beginning of the title or on word boundaries (and ends of words) are given preference. The same applies to the url, so matches near the front (like the domain) are preferred as well. Matching more helps as well, so top level pages are preferred over sub-pages with long, mysterious ?queries. 🙂

Preference for matches near the beginning

However, even with smarter matching of the title or url, the ordering might not be the one you want. Perhaps you have a page with the same title on the internet and locally for development, and you want one over the other. Only so much can be done without making things overly complex and slow, so that’s where the adaptive learning can fill in the gap.

There are builds available for people to try: Win32 zip (installer exe), OS X dmg, Linux tbz2 [build.mozilla.org]. These contain the changes for smarter matching results as well as the adaptive learning.

Adaptive results up top in addition to smarter matching
(The highlighted portion doesn’t necessarily correspond to the smart-matched portion.)

So hopefully with these combined, people will need only to type a fewer letters to find a page they want initially and then type a single letter to find it again. (Are people lazy or am I making them lazy? .. I mean efficient! 😀 )