Someone asked on the translate-devel list about integrating something like libtranslate into Virtaal. What a great idea! Except, its already done and then I realised I hadn't told anyone about it outside of the devel lists. So let me tell you what I did.

Virtaal 0.3, due in a few days maybe hours, added - thanks Walter - a plugin framework that allows various features to be coded as plugins, including of course translation memory or TM. Walter and Alaa created some that can access open-tran.eu and our own TM server. I was curious and wondered how hard it would be to add others, so I added two:

• TinyTM - a TM solutions that we stumbled upon. Although they talk about linking with OmegaT and others, on careful reading it turns out we're probably the first CAT tool client to be able to connect with TinyTM.
• libtranslate - this uses the libtranslate library to query various online machine translation tools to get potential translations.

It took me a weekend to do this. Most of the time was consumed finding and fixing libtranslate compile issues to allow it to be used by Python's ctypes module. I spent very little time doing the actual implementation. With my TinyTM implementation I spent most of the time working out which Python module I should use for PostgreSQL access.

libtranslate: Many people have got and continue to get quite excited about this. Me, I'm not overly excited. I think it will prove useful. but only as useful as the actual machine translations that are provided. How good are the machine translations?. My guess is not that good. For a new translator we run the risk that they accept the suggestion blindly. For an experienced translator we may find that they can type faster than we can get the MT result. What I think is useful is that it can give someone a push in the right direction, so if you really don't know how to translate the segment, you might get enough information to type your own translation. Time will tell.

TinyTM: Nice name. They use PostgreSQL's built in Levenshtein distance module with some nice recursion ideas to speed things up. Potentially they can add other text matching idea. Personally I think the TM server we've built for Virtaal will give better results in the long run and be less database dependent, although we already use FTS on sqlite.

open-tran.eu: I didn't work on this module but I think its worth talking a little about what makes the Virtaal plugin different from everyone else's. Some background for those who don't know about this resource: Open-tran.eu is a repository of all translations in the FOSS world (maybe not all, but everything you'd care about). They use the Translate Toolkit for some manipulation into PO files, so they must be nice guys! You can query from the web and they also expose an XMLRPC interface for querying the database. Think of it as having an absolutely massive TM of all FOSS in all possible languages at your fingertips - neat. So we had to have a plugin to this resource. Except we didn't quite like the results. Open-tran does word based lookups, anything else would probably be too expensive on their server, this results in some matches that are just way off and not useful. Our solution was to mix the open-tran results with a bit of Levenshtein distance. In layman's terms it means we get quick results from open-tran for highly probable matches, we then reduce that list through Levenshtein distance matches and take those results which have the best final matches to you the user of Virtaal. We let open-tran serve us without extra overhead and rather let the client software do the hard crunching. My feeling is that it's open-tran done right.