[Python-Dev] Re: gettext in the standard library

[James Henstridge]

On Fri, 18 Aug 2000, Barry A. Warsaw wrote:

> 
> Apologies for duplicates to those of you already on python-dev...
> 
> I've been working on merging all the various implementations of Python
> interfaces to the GNU gettext libraries.  I've worked from code
> contributed by Martin, James, and Peter.  I now have something that
> seems to work fairly well so I thought I'd update you all.
> 
> After looking at all the various wizzy and experimental stuff in these
> implementations, I opted for simplicity, mostly just so I could get my
> head around what was needed.  My goal was to build a fast C wrapper
> module around the C library, and to provide a pure Python
> implementation of an identical API for platforms without GNU gettext.

Sounds good.  Most of the experimental stuff in my module turned out to
not be very useful.  Having a simple gettext module plus your pyxgettext
script should be enough.

> 
> I started with Martin's libintlmodule, renamed it _gettext and cleaned
> up the C code a bit.  This provides gettext(), dgettext(),
> dcgettext(), textdomain(), and bindtextdomain() functions.  The
> gettext.py module imports these, and if it succeeds, it's done.
> 
> If that fails, then there's a bunch of code, mostly derived from
> Peter's fintl.py module, that reads the binary .mo files and does the
> look ups itself.  Note that Peter's module only supported the GNU
> gettext binary format, and that's all mine does too.  It should be
> easy to support other binary formats (Solaris?) by overriding one
> method in one class, and contributions are welcome.

I think support for Solaris big endian format .po files would probably be
a good idea.  It is not very difficult and doesn't really add to the
complexity.

> 
> James's stuff looked cool too, what I grokked of it :) but I think
> those should be exported as higher level features.  I didn't include
> the ability to write .mo files or the exported Catalog objects.  I
> haven't used the I18N services enough to know whether these are
> useful.

As I said above, most of that turned out not to be very useful.  Did you
include any of the language selection code in the last version of my
gettext module?  It gave behaviour very close to C gettext in this
respect.  It expands the locale name given by the user using the
locale.alias files found on the systems, then decomposes that into the
simpler forms.  For instance, if LANG=en_GB, then my gettext module would
search for catalogs by names:
  ['en_GB.ISO8859-1', 'en_GB', 'en.ISO8859-1', 'en', 'C']

This also allows things like expanding LANG=catalan to:
  ['ca_ES.ISO-8859-1', 'ca_ES', 'ca.ISO-8859-1', 'ca', 'C']
(provided the appropriate locale.alias files are found)

If you missed that that version I sent you I can send it again.  It
stripped out a lot of the experimental code giving a much simpler module.

> 
> I added one convenience function, gettext.install().  If you call
> this, it inserts the gettext.gettext() function into the builtins
> namespace as `_'.  You'll often want to do this, based on the I18N
> translatable strings marking conventions.  Note that importing gettext
> does /not/ install by default!

That sounds like a good idea that will make things a lot easier in the
common case.

> 
> And since (I think) you'll almost always want to call bindtextdomain()
> and textdomain(), you can pass the domain and localedir in as
> arguments to install.  Thus, the simple and quick usage pattern is:
> 
>     import gettext
>     gettext.install('mydomain', '/my/locale/dir')
> 
>     print _('this is a localized message')
> 
> I think it'll be easier to critique this stuff if I just check it in.
> Before I do, I still need to write up a test module and hack together
> docos.  In the meantime, here's the module docstring for gettext.py.
> Talk amongst yourselves. :)
> 
> -Barry

James.

-- 
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/