english

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.

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

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.

I'm pleased to announce the first release of my Anjuta plugin featuring code completion for Vala.

You can get a tarball from here. You'll also need a patched version of vala : GCompletion binding, public Vala.Scope.symbol_table (maybe should be read only, there is also another small change that removes a warning), better source_reference for Vala.Block and support for error reporting in anjuta ui (not included in the plugin). (I'll bug Jürg later to include them.
The plugin compiles with a dozen warnings (about ignored errors) so don't worry about it.
to compile : make && make install, it needs to install in the same prefix as Anjuta, so you may need to install as root.

If you have any suggestions, bug reports or other feedback, don't hesitate. Meanwhile, I'll be working on call tips.

It's been a long time since I've posted anything, and the last thing I've posted was about vala support for ctags. The good news is : it's done.

I'm pleased to announce the first release of vala support for (exuberant) ctags. It supports every vala tag kind I'm aware of, and most exuberant ctags extensions. And since it's based on libvala, it also supports Genie. Vala was tested with the entire libvala code, and genie was only tested with the two examples on Jamie's blog (but this should be sufficient as it uses libvala)

What's missing now is the ability to produce pattern based tag entries (only line number is supported), and tag scope (such as namespace and class name for a field).

You can get a tarball (based on latest svn of exuberant ctags), or patches : against exuberant ctags and against anjuta's local copy, both svn versions.

Update: The exuberant ctags based version needs to be configured with --enable-vala
Update 2 : I've just updated the tarball because it had a problem (I forgot to run aclocal)
Update 2009-07-22 I've updated the patch to compile latest (0.7.x) vala, here it is

And since a screenshot is better than talk, here is one: