People recently wrote about the contributors to the Linux kernel and the GNOME project. Leonardo very aptly remarked that volunteers still make an important contribution to GNOME. I also saw today how the Pootle community can react with speed.

Less than 24 hours ago we asked our community to update translations for the upcoming Pootle 2.1. Within minutes there were already three translators busy, and after less than 24 hours there is already activity in 25 languages.

Pootle 2.1 will bring several improvements, such as a new design for the translation page, support for several new file formats, machine translation, extraction of common terms, and much better performance.

Here is the new design on a Japanese translation page with Belarusian as reference language:

We're having a translation event at Translate.org.za for Zulu speakers to learn more about software localisation. Join the Translate.org.za team for a fun filled day of translation, training, discussion and eating. Be part of advancing the support of Zulu in software.

We will be showing you how to use some of our translation tools, discuss some of the issues found when translating software and feed you a light lunch, all for free. You will be providing your language, discussion, a sense of fun and the willingness to learn, share and translate.

You can follow the directions.
When: 24 July
Time: 10:00 - 16:00

For more information and to let us know if you are coming, please contact us as soon as possible.

I recently had to do a slightly harder bit of translation work for Pidgin. Part of it was an extension for the XMPP protocol to standardise emotions. With this extension different chat programs can exchange information about the user's mood in a standard way. But the text shown to the user should of course be translated, and this ended up not being easy at all.

There are more than 80 emotions described in the specification and it includes a few physical states (such as "cold" and "sick"). I got started to translate but quickly realised that this isn't all that easy. Firstly I don't know all the nuances of all the English terms well enough, but of course I just consulted dictionaries to solve that. Shortly, however, there were terms with multiple translations, some of which overlap with the translations of other terms. Some of these terms that I had some trouble with:

• Amazed, In awe
• Thankful, Grateful
• Amorous, In love, Aroused
• Dismayed, Dejected
• Contented, Satisfied
• Humbled: It is ambiguous, in my opinion. It has meanings in the direction of "modest" and towards the direction of "abased" — quite a big difference. The intended meaning is given in the specification, but how will users know what is intended here?
• Lucky en Happy: These two unfortunately both translate to "Gelukkig" in Afrikaans, and the difference is usually deduced from context. There is likely to be no context where the translations are used; maybe just a list of emotions to choose from.

The goal is of course not just to get some translation, but something that is accurate, distinguishable from the others, and something that conveys the correct message to the person that you chat with — someone who likely uses a different chat program, maybe even in another language. It doesn't help if two terms are translated in the same way and you see something like "Gelukkig" twice in the list.

Although the specification gives the idea that the list of emotions is based on a bunch of good research about emotions (including cross-cultural studies of emotion), I wonder how useful this list is when it has terms that are so close to each other in meaning. Although some of the tricky bits specifically had to do with Afrikaans, it seems as if there are a few terms that can cause confusion for translators, and maybe even for users too.

Later in the same file I encountered stuff from the OSCAR protocol (used in ICQ and AIM) allowing users to indicate what they are busy with. Here are three of the strings: Surfing, Searching the web, Browsing the web — frustration! Then there are also a few in which I would have no interest to know that someone is busy with. Some of these didn't get my attention.

• Internationalisation is hard when it deals with emotions.
• Programmers must give comments to explain things to translators in the best possible way.
• These comments must be in the translation file. The link to the specification was only shared with translators later on the mailing list. Someone translating Pidgin in future will likely miss it.
• Good dictionaries are amazing. This work would have taken significantly longer if I didn't get good starting points each time in the dictionaries.
• A second opinion on my translations was a great help.
• These words can't simply be put into a sentence. Different verbs are associated with these emotions. So while you in English might be able to say "I am ...." and fill in any of these emotions, this simply won't work in Afrikaans. (Mens kry warm, maar voel hartseer.) There are probably more reasons in other languages to never even try to squeeze these into a sentence.

I've been convinced by a few friends to organise an event to bring together a few people to translate a bit. Dwayne is kind enough to offer the Translate.org.za offices for the occasion.

Read the full blog post (in Afrikaans)

Since I hope that we'll be making good progress towards GNOME 3.0, I'm just wondering: are all the deprecated modules removed from the GNOME 3.0 release set?

I've been interested in accessibility for some time and I believe that there are several areas of intersection between accessibility and localisation. For example: what does a translated program help if there isn't a screen reader in the particular language? The recent posts about accessibility on the GNOME planet probably inspired me to improve things in Virtaal.

Virtaal highlights certain elements of translations such as XML tags and variables with colours for the sake of legibility. It is also easy to insert these placeable items without typing. This can drastically improve productivity. Until recently we still hard-coded the colours in the code, which obviously meant that it didn't work well with inverse themes (light text on a dark background).

With the release of Virtaal 0.6 I was very pleased with the improvements that we made. We work much better with GTK themes now, which means that we work better with inverse themes. Furthermore we improved the contrast for the inverse themes, and got very good feedback from a user that can now use Virtaal without problems.

Here are some of the improvements:

• The URL and XML tags are lighter, to ensure that they can still be read.
• When the search feature doesn't find anything, it has a red background (similar to Firefox). This background is now darker to ensure good contrast with the search text.
• The term for which there is a suggestion ("Download") has a dark background.
• The placeable item with numbers ("0.6.0") now has a darker background, and the foreground colour is quite light.

The last two were hard, because there should be good contrast between the foreground and the background, but the difference with normal text should also be clear. Since the normal text already has optimal contrast, this means that we are, in effect, making the contrast less.

This is all done automatically if Virtaal is running in an inverse theme. I am really happy that this works correctly without the user needing to look for anything or configure anything. It also updates if the system theme changes while Virtaal is running.

My colleague Dwayne just wrote an interesting piece about the use of continuous integration for testing our product translations. Now I want to start thinking about how we can extend it with pofilter.

One difference between msgfmt and pofilter is that msgfmt has a few strict tests which a translation must pass. On the other hand pofilter has a lot of quality checks and not all of them are matters of life and death. While some tests sometimes incorrectly complain about something being wrong, I want to think about pofilter in terms of something like "lint" — something that helps you to clean up and improve translations, but it isn't all necessarily critically important (some of it is critically important, of course).

For this reason we are now talking about how to mark false positives so that pofilter won't complain about it in future (similarly to how you can disable a lint check with a comment). An entry in the lines starting with #, would have been ideal, but gettext programs don't keep any non-standard entries there. Therefore it will probably need to be in the comments. This has the advantage that a translator can easily edit these fields as comments.

But if this is in the comments, how do we handle an upgrade to the translations? If msgmerge or pot2po mark a unit as fuzzy (the English changed), then you would like to do the quality check again, but there will be a marker to indicate that it should not be done. It would be ideal if we could detect a change in either the msgid or msgstr and simply do the tests anyway.

I'm thinking of inserting a hash value, but that won't look as nice, of course. This will also not be easily editable by a human.