[I18n-sig] Strange gettext.find results

[Michael Scheper]

Hi everyone,

The documentation is a little sketchy, but I'm not sure that 
gettext.find is behaving the way it should. It's definitely not behaving 
how I want it to.

To illustrate, I've created two directories in /tmp/gettext called 
'en_US' and just 'en'. Each contains an LC_MESSAGES directory, which in 
turn contain test.mo and test.po.

When I run this:

    gettext.find('test', '/tmp/gettext', ['en','en_US'], True)


the results I get are this:

    ['/tmp/gettext/en_US/LC_MESSAGES/test.mo',
    '/tmp/gettext/en/LC_MESSAGES/test.mo']


The documentation states that it should return 'a list of all file 
names, in the order in which they appear in the languages list', but 
it's actually doing the exact opposite. The upshot is that when I 
specify just 'en', I'm still getting en_US translations.

I think one of three things is happening:

   1. I'm misunderstanding something, despite searching this forum and
      doing a lot of Googling
   2. When searching for the 'en' locale, find just grabs the first
      English locale it comes across, regardless of the territory---it
      probably depends on their order in the file system
   3. When searching for the 'en' locale, find defaults to U.S. English,
      a poor choice because U.S. English has far more spelling and
      formatting variations than any other version of English (there are
      far fewer differences between, say, en_AU and en_GB, or even en_ZA
      and en_CA, than en_US and any other)

If it's number 1, could somebody help me out? If it's number 2 or 3, 
does anybody know of an elegant workaround, and should it be considered 
a bug?

What I want is for U.S. English users to see messages from en_US, and 
users who prefer other forms of English (Australian English, Canadian 
English, British English, etc.) to see just en. Creating separate 
locales for each of them---there are a dozen or so---seems impractical.

Advice?

Thanks,
Michael Scheper.

P.S: Changing the system locale doesn't seem to make any difference.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/i18n-sig/attachments/20090925/205e621c/attachment.htm>