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

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

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

Some time ago, I've updated an old and unmaintained python plugin loader for Anjuta so it can use PyGI, the python gobject-introspection bindings. At that time, it needed a patched version of PyGI (to be able to implement virtual methods) and so wasn't easy to install. Now this is all over, and the git version of PyGI should work without problems (Update: PyGI 0.6.0 got released). You can find it here.

But that's not all, today, I implemented virtual methods support in Seed, and guess what, I've written another plugin loader for Anjuta, so now you can have Javascript anjuta plugins.
You'll need the patch from bug 620516. You'll also need to install gobject-introspection girs which are with the python plugin.

I didn't test them extensively, especially with multiple plugins loaded, but they should be useable. If not, report a bug :-).

Now you have no reason not to write Anjuta plugins (unless you prefer writing emacs lisp or vimscript rather than python and javascript). So go and write some niceties for our beloved GNOME IDE ;-).

P.S. The vala support plugin I wrote for GSoC 2008 should be added in time for anjuta 3.0 (I just need to integrate it in the anjuta tree)

If you're wondering what I've been doing lately, here is one of them : Bug 584662 RTL locales support for GNOME Shell.
Since Shell is still rapidly evolving, there are new (RTL related) bugs every now and then, if you want to test this, get gnome-shell from git, apply whatever uncommitted patches from the above bug and, if you find something that doesn't work correctly or doesn't make sense for RTL locales, add comments to that bug.

Augie Fackler released a new version of hg-git yesterday, it should be relatively stable, there are still some rough edges, but it should be useable for most day-to-day tasks.
Please test it and report any bugs you find to http://github.com/schacon/hg-git/issues

If you have any questions or suggestions, or want to contribute to the development, there is a google group : http://groups.google.com/group/hg-git

Just a quick post to say that I've moved the Anjuta Vala plugin from freehg to bitbucket, which has more features (wiki and issue tracking) and freehg is often down. The repository can be found here.

Feel free to add whatever information to the wiki (I've not written anything yet) and report bugs and feature requests (and why not send patches;-))

I guess the three readers of my blog owe me some updates (what? there aren't even three of them?)

I've been working on Scott Chacon's hg-git (my branch can be found here).

Basically, I made it feel more like mercurial. (you feel you're actually using mercurial, not using git and typing hg).

Now you can clone/push/pull from a git repository, git branches are converted to hg bookmarks, and when pushing, all the hg bookmarks are pushed as git branches. The annoying thing now are named branches (since they aren't converted meanfully, and so cause problems).

I have also started working on converting git submodules to mercurial subrepos (a new feature of 1.3). I'm keeping these experimental changes on a patch queue.

P.S. I'm trying to use some desktop blogging software (trying drivel now, if you know of something better, let me know). I hope to be able to blog more often.

Update: drivel couldn't send the post and gnome-blog added too many <p> tags all over the place, so I'm still searching for a better tool.

It's a bit late for announcing this but I've been accepted for Summer of Code again this year, I'll be working on interoperability between git and mercurial, so you can use the nice UI of mercurial with the ever growing number of projects moving to git (I'm thinking of gnome here).

I'll try to resend a new version of my Vala patch to gdb later this week.

As bug 542920 has been fixed, I've released a new version of the Vala plugin for anjuta.
Highlights for this release :

* Now compiles without patching anything, you'll need vala 0.5.7 and at least version 2.24 of anjuta.
* Reparse when a file is saved.
* Various bug fixes.

You can get it from here. I hope it'll be included in anjuta-extras for 2.26.

On other news, I've sent my gdb patch, you can follow the thread here(my latest mail is here).

Hi all,

there are some new things in the repository about the vala plugin of anjuta. I'll try to make a release as soon as I finish a last little thing and get all the needed patches included in libvala.

meanwhile, you can play with it (apply the patch in bug 542920, and change the last "return false;" to "return sym1.get_full_name () == sym2.get_full_name ();" I'll try to fix it).

If you make it crash, send me a backtrace, and I'll try to fix it

Hi,

I've just uploaded my latest patch to add Vala support to gdb.
It works mostly ok, and I'd like more feedback on it.
You can get it from here. (apply it against gdb 6.8 )

Summer of code is almost over, and I think I'm on track for completing my project.

Now, more about what I've been doing lately :

The next step in my project is Vala debugging support for Anjuta. I tried to work directly on gdb so that others can use it even if not using anjuta. Here are the results as a small demo video.

So what do you think of this? Of course you can try it yourself : get the patch from here, and apply it on gdb 6.8.

There are still some things to clean, some things to add, but I think it's useable now. the main thing to add is printing of values (now it uses the C), and the main thing to add is accessing private fields directly (i.e. obj.privfield instead of obj.priv.privfield).

P.S: I'll try to prepare a video using Anjuta.

Another release of my Vala plugin for anjuta is available. The patch for libvala I've posted earlier are still needed.
This release features :
* completion based on return types of methods.
* showing errors in anjuta ui (only red underline right now).
* call tips.
* fixed completion popup alignment.
* various fixes.
* a dozen more warnings on compilation :-p

I'd love to put a screenshot, but I'm not on my pc right now.

Anyway, I consider code completion mostly done, and will be concentrating on other things (I'll try to add Vala support to the debugger). If you feel something is missing or if you find a bug, feel free to send feedback.