l10n: More than one language

Falling back to English when translation of a particular string is not found is not always the best solution. As a practical example, our Aymara users would prefer that the fallback language be Spanish, and only if the Spanish translation is not found, English should be shown.

I was wondering how to implement this for Sugar and its activities, and I realized that something like this is already implemented in Python’s gettext implementation. So after some changes to Sugar, I had the following:

In the screenshot, the Restart Game pop-up is not translated into Aymara, and so it shows up in Spanish as Reiniciar Juego, while the rest of the strings are in Aymara.

Of course, there is a lot more to be done – the Sugar control panel language selector needs to be changed to allow selection and ordering of multiple languages, and currently this works for activities, core Sugar needs to support this feature as well.

Weekend hacks

Over the past few weekends, I have been working on a few (semi)hobby projects.

  • Conversion of XKB data to M17N tables
    I discovered pyparsing while working on this. The tool I wrote is supposed to extract the data out of XKB symbol files, and convert them into a format which can be easily modified into M17N db files. In fact, for some keyboard layouts, the output was directly usable in m17n (via SCIM), without any kind of direct modification at all.
    The only problem with the script is that the parsing of the XKB symbol files take a significant amount of time, but in the end, it does provide something useful. [Gitweb]
  • An image viewer activity for Sugar
    Sugar did not have a nice Image Viewer activity which I liked, so over the weekend, I hacked together a small activity which would perform the basic stuff expected of an image viewer (zoom, rotation, etc). [Gitweb]

Quote of the week

From this week’s community news:

Among them was the mayor of South Beirut, with whom I spoke. ‘The American government sends bombs to kill the innocent,’ he said, ‘and the American people send us computers for our children. We are very grateful to OLPC. This means opening up the world to our children.’



Also, in related news, Sugar is being translated into Aymara. If you can help in this effort, or for that matter, any of the translation efforts, you are more than welcome to jump in ;-) .

“Local Language Efforts” by the various government agencies

The government has recently shown a lot of interest about Free/Open Software, especially in the area of localization for Indian/Indic languages. However, this well meaning interest has resulted in some totally clueless individuals and agencies being delegated to work on these issues, resulting in a major mess. The prime example of this would be BOSS Linux, which has not bothered to work with the community in any way (at least for the translations), and a result, it looks like a large amount of work (paid for from the tax payer’s money) is going to be wasted. Gora has started a thread on the gnome-i18n mailing list on this, and we can see no easy way to reutilize the work done. Interestingly, as per the comments in Sankarshan-da’s blog post on this matter, the government agency responsible for this had actually contacted some people in the community (via a 3rd party), offering to pay around USD 0.07 per string translated. The condition was that the work needed to be secret and exclusive for BOSS. That’s interesting for an “Open Source” project, funded by the government.

Closer home, there’s this “Baishakhi Linux” distribution, which makes quite dubious claims such as “All Bangla compound words can be viewed and written in Baishakhi Linux, and this special feature distinguishes it from the other localized Linux distributions.“. After making this statement, they go on to show a list of “compound words” (conjuncts, or yuktakshars), of which, I believe only _one_ is not writeable in stock OpenOffice.org/GNOME, and the fix for that is a one liner (bug, with patch).
I downloaded the ISO image from their website (I didn’t see any link to any source code), and started it up in a VM. It looks like they took the existing upstream translations, made minor modifications to them (which includes adding the English msgid in parenthesis at the end of each msgstr). They took care, however, to replace each translator_credit translation with their own name. I ran msgunfmt on the Evolution mo file, and though the translator_credit had been changed, the header read:

“Last-Translator: Promathesh Mandal <promatesh@mat3impex.com>\n”
“Language-Team: Bengali <gnome-translation@bengalinux.org>\n”

In case you are wondering, gnome-translation@bengalinux.org is the email address of the upstream GNOME translation community for Bengali.
This kind of approach makes me pretty pissed off. In the past, we have included all the names possible in the translator_credit translation, IMHO that is the least the Baishakhi Linux people could have done.

It’s a sad state of affairs – it really is.

Free software translations for people who do not know English

Whenever we work on a PO file, we usually translate from English to the translate language. However, recently at OLPC, we had some Aymara translators who did not know English, but were quite comfortable with Spanish. We had been receiving such requests for supporting the display of an intermediate language in our translation system for quite some time now, and it was also a prominent feature request for Pootle, the web based translation software that we use. I was feeling a bit bored with my usual work, and decided to see if I could do something.


The straight forward way of implementing the feature would be to add yet another user preference which would store the list of languages in which the user would want to see the translations, but that seemed to involve significant amount of coding, and I was too lazy to do that. After thinking for sometime, I decided to take a short cut which should help us quite nicely now. Pootle can optionally show it’s interface in a non-English language, and I thought I would take advantage of that. Within around an hour (which included figuring out some of the Pootle code and understanding jToolkit), I had a patch which produced this:
Pootle with an intermediate language
So, if you select your UI language as Spanish, along with the original msgid, you will also get the corresponding Spanish translation when you are translating a message. I think this should do for now – though the “proper way” is probably the right thing to implement at some point.

OLPC: Call for translators

The Pootle server running at dev.laptop.org is now up and running. If you are interested in helping translate the software going to be bundled with the laptops, please do jump in :-) . More information is available in the mailing list post that I made.
If you have any questions – you can take a look at the FAQ and if you still have questions, feel free to join us on #olpc-pootle on Freenode, or ask on the mailing list.
Helping setup Pootle was an interesting project for us, since this is probably the first time a Pootle deployment is talking to a GIT repository, and adding support for GIT to Pootle (and adapting it for use in our scenario) was a bit of a battle. The results of the initial “beta tests” seem to be pretty satisfactory, and the next few days will hopefully tell us how well the entire system is working.