installing GNU gettext for use with Python on OS X

I've been working on my blog post about Python's gettext module for the past couple of mornings, and ran into a snag. The documentation claims that the Python source distribution includes all the tools you'll need, but when I got to the point where I wanted to write examples of internationalizing plural strings, pygettext.py wasn't working.

It worked great for extracting individual string messages up to that point, but refused to extract messages wrapped in the ungettext() call, even when I used what seemed to be the appropriate command line options. I ended up installing the GNU gettext tools and using xgettext instead. Installation took me longer than I expected, so I'm documenting the process I went through here.

Fink or MacPorts: Not so much.

Since OS X doesn't ship with a version of gettext by default, and there doesn't seem to be one in the Xcode package (Apple has their own internationalization tools), I needed to find a copy elsewhere.

Ages ago I had installed fink as an "easy" way to grab copies of these sorts of utilities. However, it seems that somewhere along the line the version of fink I have stopped working (probably due to upgrading to 10.5, I haven't tried using fink or FinkCommander directly in some time). After wiping and reinstalling, I was pleased to find a slightly old version (0.14.5) of gettext installed as part of the default set of packages. Unfortunately, xgettext wasn't included in the package at all.

Next, I grabbed a copy of MacPorts, a competitor to fink. Although I've been warned off of MacPorts by a few people I trust, others have had no problems with it. Installation was fairly easy, and as with fink it installed everything to its own directory tree (under /opt/local). Once I had the port program installed, the next step was to run:

$ sudo port install gettext

It downloaded several dependencies, patched the source, compiled everything, and installed it. Voila! Well, not so much.

Even though the most current version of gettext (0.17) was installed, and the documentation clearly described the included Python language support, the binary refused to recognize any language other than C.

Scratch that.

Compiling from Source: Partial Success

Since MacPorts had to download the package and compile it anyway, I decided to go ahead and do that on my own. I was a little wary because I wasn't exactly sure what port was doing in its "patching" step, but I thought I would give it a try anyway. I snagged the most recent tarball from the gettext site and ran the usual

$ ./configure
$ make

That gave me a binary for xgettext inside the source directory, and testing it against my Python source yielded the results I wanted. A simple .pot file was extracted with the original message strings and placeholders for singular and plural translations.

Next, I thought I'd get clever and install the results into the virtualenv I use for working on PyMOTW. Re-configuring with my --prefix set to $VIRTUAL_ENV, rebuilding, then running make install copied the binaries and a bunch of associated data files right where I expected them to be. And the binary only recognized the C language.

After a little more fighting, I did manage to get it working by installing with a prefix of $VIRTUAL_ENV/gettext and adding $VIRTUAL_ENV/gettext/bin to my PATH. I'm not sure if the problem was solved by clearing out an older, bad version of xgettext from elsewhere in my path or if using $VIRTUAL_ENV as the prefix somehow confused the install script.

Conclusion: I think I understand why internationalization is frequently the last feature dealt with in a project.