Strange gettext.find results
Michael Scheper <[email protected]> Fri, 25 Sep 2009 18:53:09 -0700
| Newsgroups | gmane.comp.python.internationalization |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0659531113==
Content-Type: multipart/alternative;
boundary="------------000607060607040106080504"
This is a multi-part message in MIME format.
--------------000607060607040106080504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.
--------------000607060607040106080504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi everyone,<br>
<br>
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.<br>
<br>
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.<br>
<br>
When I run this:<br>
<blockquote><font face="monospace">gettext.find('test', '/tmp/gettext',
['en','en_US'], True)</font><br>
</blockquote>
<br>
the results I get are this:<br>
<blockquote><font face="monospace">['/tmp/gettext/en_US/LC_MESSAGES/test.mo',
'/tmp/gettext/en/LC_MESSAGES/test.mo']</font><br>
</blockquote>
<br>
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.<br>
<br>
I think one of three things is happening:<br>
<ol>
<li>I'm misunderstanding something, despite searching this forum and
doing a lot of Googling<br>
</li>
<li>When searching for the 'en' locale, <font face="monospace">find</font>
just grabs the first English locale it comes across, regardless of the
territory—it probably depends on their order in the file system<br>
</li>
<li>When searching for the 'en' locale, <font face="monospace">find</font>
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)</li>
</ol>
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?<br>
<br>
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.<br>
<br>
Advice?<br>
<br>
Thanks,<br>
Michael Scheper.<br>
<br>
P.S: Changing the system locale doesn't seem to make any difference.<br>
</body>
</html>
--------------000607060607040106080504--
--===============0659531113==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
I18n-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/i18n-sig
--===============0659531113==--