If I haven’t blogged much here lately, it’s because I’ve had my nose to the grindstone — along with the rest of the Ubiquity team, including our insanely dedicated volunteers — on getting the next version, 0.5, released.
Well, yesterday we released a preview version, 0.5pre. It is still somewhat buggy; we’re going to spend the next week fixing the biggest bugs and then release 0.5 for real on Tuesday, June 30.
The biggest news in Ubiquity 0.5 is that it finally supports multiple languages. At release, we have Japanese and Danish supported in addition to English; the infrastructure is in place to add more languages as rapidly as we can recruit volunteer translators.
I celebrated the first release of a Japanese Ubiquity by wearing my happi and geta to the Mozilla meeting on Monday:
(The headband says: 合格 (goukaku), which means to pass a test. Japanese students wear them when studying for exams. In this context, let’s just say it refers to unit tests.)
I may be wrong, but I think that Ubiquity may be the first truly global attempt at a natural-language interface, as opposed to one which targets only a single language. Does anyone reading this know of any other similar experiments? If you do, please leave me a comment — I would love to know about what other work has been done in this field.
I have already written a bunch about Ubiquity 0.5 elsewhere, so rather than repeat myself, let me just link you to the appropriate places:
- Here’s the Labs blog post about 0.5pre. It includes the credits for the main people who contributed to the release.
- Here’s where you can download the 0.5pre extension itself.
- Here’s the release notes that list everything that’s new in this version.
I do want to talk a little more about the fact that we changed the command API. This change meant breaking commands written for older versions of Ubiquity, something I am loath to do without very good reason. But the old API was holding us back: it wasn’t extensible enough, it couldn’t support localization, and it was getting in the way of defining sane and consistent naming standards. Since our original hacky prototype, we have gained so much knowledge (about what the parser and the command API realistically need to support) that a fresh start was in order.
Since breaking backwards compatibility has a high cost, we don’t want to have to do it ever again. We tried our best to look ahead at everything that would make us change the API — and concentrate all of those changes in this one single revision, so that there is just a single “breaks everything” release rather than three or four consecutive “breaks everything” releases.
Updating commands to work with the new API is fairly easy. It mostly has to do with how your command declares arguments. If your command doesn’t take any arguments, then you don’t have to do anything. Full instructions are here: Command Conversion Tutorial. The same page also explains how to ensure that your commands are localizable.