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.

To bépo or not to bépo

nospam@example.com (Abderrahim Kitouni) — Sun, 23 Oct 2011 22:32:00 -0700

(to those who can't read french: I'm switching to bépo, a dvorak-style keyboard made specially for french)

Et un billet en français pour mes lecteurs francophones.

Il y a quelques mois, je lisais sur le blog de Lionel Dricot (alias ploum) un billet sur la disposition de clavier bépo ; cela m'a paru intéressant mais je n'avais pas vraiment le courage de changer car j'avais un mémoire à rédiger. Début aout, j'avais terminé le plus gros de mon travail et j'ai commencé les exercices sur klavaro, 5 à 10 minutes, 1 à 3 fois par jour.

Comme je venais d'acheter un ordinateur et qu'il y avait un clavier avec le boitier, j'ai essayé de suivre le conseil de ploum et d'utiliser le nouveau clavier pour le bépo et garder l'ancien pour l'azerty. Ça n'a pas marché comme je le voulais car le nouveau clavier n'était pas bien différent de l'ancien, et j'ai dû renoncer.

La raison principale pour laquelle j'ai décidé de changer est que je n'arrivais pas à apprendre à taper correctement en azerty : je connaissais très bien le clavier, je tapais beaucoup plus vite à 6 doigts (en regardant le clavier, bien sûr) et je ne pouvais pas m'efforcer à taper à 10 doigts tout le temps. C'était plus confortable pour taper un long texte, mais pour taper rapidement une commande simple dans un terminal, j'avais terminé à 6 doigts en moins de temps qu'il ne fallait pour positionner mes doigts correctement.

Dès que j'avais terminé le cours de base la première partie dans klavaro, j'ai commencé à essayer de taper en bépo dès que j'avais un texte court à écrire ; cela m'a permis de voir les progrès que je faisais au fur et à mesure. À un certain moment, et parce que j'ai mis trop de temps à faire le saut, j'ai décidé de ne plus taper à dix doigts en azerty. Cela m'a permis de continuer à m'entrainer au bépo sans pour autant ralentir mon travail. Cela ne me dérangeait pas trop de changer entre les dispositions clavier vu que je devais de toute façon utiliser un clavier arabe en plus. Je ne pense pas que cela pourrait marcher pour tout le monde, mais j'espère que ça peut servir.

Il restait cependant un gros point d'interrogation : les raccourcis clavier. Il faut aussi tout réapprendre. Le problème est qu'il est difficile de reconnaitre les touches. La solution que j'ai trouvé est d'utiliser les raccourcis en mode 10 doigts. Je m'explique : j'ai trouvé un article sur internet qui suggère d'utiliser la paume de sa main pour la touche contrôle ; cela permet de ne pas trop tendre l'auriculaire et donc un meilleur confort mais aussi d'utiliser des raccourcis comme C-a sans bouger les doigts de la position initiale (je ne peux pas atteindre la touche contrôle droite sur mon clavier sans quitter la position initiale, je songe à l'échanger avec la touche menu).

Dans cette position, je trouve même que les raccourcis de déplacement d'emacs sont bien (je ne les connais pas encore par cœur mais je les apprécie déjà). Les fans de vi vont me dire que hjkl sont plus efficaces, mais je préfère emacs pour deux raisons : je n'ai jamais compris comment fonctionne vi (j'ai essayé d'apprendre vi d'abord vu la réputation qu'avait emacs, mais j'ai très vite abandonné) ; et les raccourcis d'emacs sont souvent des mnémoniques et s'appliquent quelque soit la disposition utilisée.

La seule chose que j'ai ajouté à la configuration d'emacs est

(global-set-key (kbd "C-ç") ctl-x-map)

ce qui me permet d'utiliser C-ç comme un deuxième C-x. Ceci est plus pratique vu que la plupart des lettres qui s'utilisent avec C-x sont à droite (c s f).

Bien sûr, tout ce billet a été entièrement écrit en bépo, pas mal pour un débutant. On verra ce que cela donnera avec le temps. Pour le moment j'ai une vitesse raisonnable, donc je ne pense pas que je risque d'abandonner.

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).