- english

On trimming down translations

nospam@example.com (Abderrahim Kitouni) — Tue, 01 Nov 2011 14:55:31 -0700

Small translation teams always have problems prioritizing translations: you are faced with a huge file to translate and don't know where to start and get discouraged rapidly. Seeing the main interface translated after translating only 100 strings (something an inexperienced translator can do in an evening) can be a rewarding experience and encourages one to go further.

A few days ago, someone popped out on our mailing list and wanted to help translating gnucash (4098 strings, 26322 words; that's about the same size as evolution, the biggest file in the base gnome moduleset). After telling him to send the file back every 100--200 strings (both for reviewing for newbie mistakes, and to help him not losing motivation), I then looked at an old attempt to hack a little LD_PRELOAD library that catches calls to gettext to generate a POT file containing only the strings actually used when the software is run.

After some hacking, I got it to the point I could generate a small POT file for our new translator. Right now, it is very fragile; it needs some "postprocessing", ignores plurals and message contexts, and may well work only on my machine, but I hope it could be useful. The code is available here.

It uses a library I've found with gettext (preloadable_libintl.so) that looks like it was made specifically for this purpose, I wouldn't be surprised that I'm reinventing some wheel here. (UPDATE: this is exactly the purpose of preloadable_libintl.so, but the output is a bit different, so I'm keeping my version as well)

To compile:
valac -C poextract.vala
gcc -shared `pkg-config --cflags --libs glib-2.0` -o libpoextract.so poextract.c

and then run like this:
LD_PRELOAD=./libpoextract.so:/usr/lib/preloadable_libintl.so gnucash

This will generate a gnucash.pot file in the current directory. The following will remove duplicates and bring in locations and comments from the original po.

msguniq gnucash.pot | msgmerge ~/Downloads/gnucash-2.4.7.pot - > gnucash.reduced.pot

Now the question is, how can we take advantage of this to prioritize translations? My first idea is to take different common use cases to translate (for example, first-run, everyday use, configuration). This will both reduce the load on a small team, and improve their confidence that they are doing something useful.

On extracting data from windows files

nospam@example.com (Abderrahim Kitouni) — Tue, 16 Aug 2011 18:33:00 -0700

Hello, readers of my blog
(what, there are no more readers? then I'll write it for myself)

From time to time, you need to extract some data from a "legacy windows file format" (In my case, it was a JET database). Often, the data is encoded using the (windows-specific) cp1256 encoding (or something similar), but the tool you use assumes cp1252 (or latin1, they are mostly compatible, unlike say cp1256 and iso-8859-6) and you end up with a text containing "arcane" latin characters like:

Â ÇáÃáÝ ÊÃúáíÝåÇ ãä åãÒÉ æáÇã æÝÇÁ

While it should read

آ الألف تأْليفها من همزة ولام وفاء

Previously, I thought that after such (incorrect) conversions, it would be mostly damaged beyond repair But yesterday, as I met this problem again, I thought I could try to get something out of it (even if it is a bit broken), so I fired up ipython and after a few trials I found this:

f = file('file.in').read()
print >> open('file.out', "w"), f.decode('utf8').encode('latin1').decode('cp1256').encode('utf8')

and got the text in a readable form as you can see above. I hope someone finds this useful (by replacing cp1256 by some other encoding).

GNOME 3.0

nospam@example.com (Abderrahim Kitouni) — Sun, 10 Apr 2011 23:06:25 -0700

It's been a long time since I haven't blogged. I haven't contributed much to the Shell after my previous post (because all I have now is my unichrome integrated graphics, which barely runs 3D apps, and I can't seem to find an AGP card, so no shell for me).

So I wasn't able to fix all the RTL-locale bugs, but I think Florian Müllner did. Nevertheless, it's great to be part of this new release ...

One more thing: I'm going to be the coordinator for the Arabic translation team, so I'm even more GNOME

I'd also like to thank Khaled Hosny (the former coordinator) who did a good job so far (and even ended up translating alone at some point).