Problem with i18n - "en_US" locale translations coming through for "en"

[Fran O'Reilly]

Hi all,

I've got a situation where even though the user has selected language
"en", the "en_US" translations are being rendered. My setup has three
languages - "en", "en-us" and "en-gb". I also have three locale
translations corresponding, i.e. "en", "en_GB" and "en_US".

Anyone seen a similar problem before?

My settings file has the following:

LANGUAGE_CODE = 'en'

ugettext = lambda s: s
LANGUAGES = (
('en', ugettext('English (Default)')),
('en-us', ugettext('English (American)')),
('en-gb', ugettext('English (British)')),
)

I have created translations for each of the three locales above using
the normal django-admin.py commands:

% django-admin.py makemessages -l en
% django-admin.py makemessages -l en-gb
% django-admin.py makemessages -l en-us

... then filled in the django.po files with the translations (for this
test, I made sure to use text that was different for each locale so I
could tell which translations were coming through), then :

% django-admin.py compilemessages

then restart my server to pick them up.

I also have locale middleware setup so that LANGUAGE_CODE is available
on the request. Here's my settings.py:

MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.middleware.transaction.TransactionMiddleware',
)

Here's a snippet from my template. It lives at /index.html/ and has a
dropdown control that allows the user to select the default language.
It's basically just a homepage where the user chooses their preferred
language setting with a dropdown form and submit button. It hooks into
the django set-language view (django.conf.urls.i18n) being mapped to
the url /i18n/setlang/. It has a h1 element that is translated as well
as a debug print of the value of request.LANGUAGE_CODE. The "Homepage"
text is translated in each of the locale's django.po files with text
like "Homepage (en)", "Homepage (en-gb)" or "Homepage (en-us)" so I
can tell which translation is coming through to the template.

--snip--
<form action="/i18n/setlang/" method="post">
<input name="next" type="hidden" value="/index.html" />
<label for="lang">{% trans "Current selected native language/dialect"
%}</label>
<select id="lang" name="language">
{% for lang in LANGUAGES %}
<option value="{{ lang.0 }}" {% ifequal lang.0 request.LANGUAGE_CODE
%}selected {% endifequal %}>{{ lang.1 }}</option>
{% endfor %}
</select>
<input type="submit" value="Change" />
</form>

<p>LANGUAGE_CODE={{ request.LANGUAGE_CODE }}</p>

<h1>{% trans "Homepage" %}</h1>
--snip--

So when I select the language "en", the template renders the "en_US"
values in the template which is wrong - expect "en" locale. If I
switch to "en-gb" or "en-us", it works as you'd expect, pulling back
the en_GB or en_US locale translations. Just with "en", for some
reason, it pulls back the "en_US" translations, but obviously I'd
expect the "en" translation to come back.

Also very odd: If I take out the "en_US" locale and language code from
the above, the "en" and "en_GB" locales now work correctly! It's as if
there were something special about the "en_US" locale in the code
somewhere?!

I'm running django svn 8015, about a month old or thereabouts. Haven't
had time to try this on the latest svn.

Any help appreciated,

Fran O'Reilly.

[Fran O'Reilly]

I've raised the following ticket for this issue:

http://code.djangoproject.com/ticket/8626

Have also confirmed on latest from svn, 1.0-beta_2-SVN-8643. The
ticket includes all the files needed to reproduce the problem.

[cardhu]

Hi Fran,
Sorry if I can't help but I've been looking myself for a possibly
quick answer to a strange problem regarding i18n.
I am running latest svn rev and the strangest thing is that in the
admin app I am presented with both LANGUAGES and LANGUAGE_CODE.
My custom templates however do not recognize these variables, even
though they're being passed through the same middleware and context
processors (or at least I'd like to believe that)
Maybe i'm just thinking out loud,
Regards
RiCardo