Bruno Haible has provided me with gettext-0.15pre1.tar.gz, with a *much* improved public API that allows programs (such as gtranslator, kbabel etc) use it's po file parsing, hook in a custom error handler to the parser, update translations in the parsed messagelist, and write translations back to a po f ile. Basically, I can now start ripping out the custom parsing/writing code from gtranslator and use this instead, which is a far cleaner solution. Then, as this will provide easier access to the plural form translations, I can provide a nicer UI when editing them. I have most of this done already in a proof-of-concept branch, but it just needs to be reworked a bit to use Bruno's new gettext API. I'm excited.

GNOME sysadmin

Lots of fun with the content_filter (amavisd/spamd/clamd) on menubar.gnome.org. Jeff disabled it as he thought it was causing multi-hour mail delays (not good near the end of a release cycle), but it turns out it was DNS failures. I tried using SpamCop's RBL for a bit, but it turned out it would have caused a few too many false positives, so we'll just rely on RCVD_IN_SPAMCOP_RBL for now.

I briefly looked into the CVSROOT loginfo file. I was annoyed that it only runs the first match in that file. It means my 'cvs-commmits-po-list' hack was not being reached if the commit was being handled by one of the other (more important) scripts further up. I figured we needed a hacked martin-log.pl that would 'Cc' that po commits list if a '.po' file was one of the files affected. However, I don't think my Perl skills were quite sharp enough, as it seemed to put an invisible spanner in the works, resulting in a handful of (test) commits not generating the mail notification, so I reverted it. I'll have to find a better way to test it at some point.

Toni seems to be showing some enthusiasm towards getting RT (Request Tracker) packaged up for window, which will be good. He's also looking at getting NAGIOS up, so we can react to and track service outages a bit better. I'm also thinking of making a more concrete proposal for setting up MRTG monitoring of load and system/network I/O on the various boxes, which I think would be useful/interesting.

Whacky ideas dept.

Now my lappy keyboard is giving up the ghost, and I'm starting to wish I could get information into my iPAQ quicker than tapping it's touchscreen, I came up with an idea. Quite a few years ago now (when TV presenters had big hair and bushy sideburns, and wore brown jackets with big ties), I saw a show called Tomorrows World, which demonstrated how a someone with only a few days experience using this one-handed keyboard was able to type faster than the fastest touch typist in the world on a normal keyboard. I was impressed, but I never heard anything more about it after that.

Well, I found them. They are Infogrip, and they make the BAT. Your hand rests with four fingers on four black buttons, and your thumb free to move between three coloured buttons. By pressing the keys in a certain combination (chord), you can simulate just about any keypress from a standard keyboard. Apparently, you can learn all the chord combinations in a few hours, and can be up to a reasonable typing pace in just a few days. Hopefully, I'll be in a position to order one in a few weeks time.

I like it, but I thought maybe I could do one better. I thought about a small, kind of cylindrical device, moulded a bit like a joystick handle, with the four main buttons along the front, and the three thumb buttons on top. It would contain an AA battery, and would simply send signals (via Bluetooth) when a key is pressed or depressed. This just means that you would need to buy a USB Bluetooth dongle, and write a keyboard driver to convert the received signals into keycodes. Theres probably a little more to it than that, but not much.

You could go even further and give the transmitter the concept of channels. So that, with a certain chord, you could switch between sending your input to different devices (your desktop, your laptop, your PDA, your mobile phone, your TV, your cashpoint, your other electronic device).

I guess there would be a few security issues involved here too, but they could easily be addressed during my next daydream. For now, back to writing PHP code to keep the bills at bay (yawn!). Maybe someone from Infogrip wants to pick up where I left off :)