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.