Smileys

People are used to see little images like in conversations instead of the plain text version :-). Testers of Instantbird 0.1.* have probably noticed that this feature was missing. No more.

Instantbird 0.2 supports smileys, and has a theme system for them. Creating a new smiley theme is easy: it is just a bunch of images and a file (JSON format) describing how to use them, bundled into an XPI file.

Message styles

Selecting a smiley theme is not enough for you to feel comfortable when looking at your conversations? Ok, we have more! We have borrowed the message style system of Adium to let you fully customize the way your conversations look.

An image is worth a thousand words so… I’m gonna give you a thousand of images. Ok, not really a thousand, but we took a few hundreds of screenshots to show how Instantbird is doing with the hundreds of Adium message styles downloadable from adiumxtra.com.

The compatibility is not perfect because there are some differences in the way Instantbird and Adium handle themes, and some Adium themes may use some webkit-specific features, but most themes look right.

This theme system is very flexible, and quite easy to learn. The technologies used (HTML, CSS, JavaScript) are well known by web-developers and web-designers. If you are not happy with the existing themes, go ahead an create your own. And don’t hesitate to let your creativity play with all the cool new developer features of Firefox 3.5.

Extensibility

The eye candy is cool but… I’m a developer, I want to create extensions and I want to be able to interact with the conversations! Don’t worry, we love you too. We added several new APIs for extension developers. It is now easy, for example, to change the way we filter incoming messages, modify the text before it is displayed (adding links for instance), and more coming!

Comparison of translation systems used by Mozilla and libpurple:

Inside libpurple, localizable strings are just marked by _("string"). For example, you can find this in the code:

description = _("Unknown error");

During the compilation, _() is expanded by the C preprocessor to a call to a gettext function. Gettext tools can analyze the source code, find all strings enclosed in _() markers, and produce a translation template. This template (a .pot file) is then handed to translators, who translate the strings and then provide a .po file for their language.

The translation system for XUL applications is quite different, here are 2 significant differences:

• localizable strings are not directly in the source code. The source code uses unique identifiers, and these identifiers are used to find the actual string in the locale files.
• the strings are spread across several localized files. Usually each window has its separate files, which makes it easy to decide at a later point that something will become an extension, and makes it easy to localize an extension like any other part of the application.

How do we deal with this in Instantbird?

Obviously, we don’t want Instantbird to use both of these localization systems, so one had to be removed. In Instantbird 0.1.*, we just removed gettext without replacing it. This means that the gettext _() macro was defined to something doing nothing, and the string used was just the one specified directly inside the source code.

For Instantbird 0.2, this is no longer acceptable, and we worked on a way to simulate the action of gettext, that is, hiding the 2 differences I’ve just explained.

Splitting the translation in different files wasn’t very difficult. Actually, gettext has a concept of packages that makes it possible to split the translation of an application into several packages, the feature is just unused by libpurple. With a little bit of build system tweaking, I finally got a translation file for the core of libpurple, and a separate translation file for each protocol plugin. This was needed so that libpurple protocol plugins packaged as extensions can be localized.

Creating a unique identifier for each localizable string was a bit more work. The solution we have settled on is:

• Take the original string and remove all string formatters (words starting with %), hexadecimal numbers (words starting with 0x) and more generally, all non alphanumeric characters.
• Remove all the whitespace in the remaining string, keep only the 7 first words, and convert to camel case.

At this point, we have an identifier for the original string, but it is not unique. Long strings that differ only at the end result in the same identifier, and strings that don’t contain any real word (‘%s:%s’ for instance) all result in an empty string. To disambiguate in these cases, and only in these cases, we append the 8 first characters of the hexadecimal MD5 hash of the original string to the identifier.