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.