#8626: Translations from "en_US" locale being used even though
request.LANGUAGE_CODE is "en"
-------------------------------------------+--------------------------------
Reporter: francisoreilly | Owner: nobody
Status: closed | Milestone: 1.0
Component: Internationalization | Version: SVN
Resolution: wontfix | Keywords: locale language
en-us en-US
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------+--------------------------------
Changes (by mtredinnick):
* status: new => closed
* resolution: => wontfix
Comment:
This is excellent work and it's nice to understand what's going on.
However, at the end of the day, I suspect this is probably not a bug.
Firstly, the `locale.locale_alias` dictionary maps every single "language
only" locale specifier to a languagee + country version. It's unfortunate
that English as spoken by the English isn't the canonical mapping and the
US version is used instead, but a choice had to be made. The fact is that
the designator "en" is ambiguous. It needs to be mapped to "English as
spoken in XYZ" for some value of XYZ.
With, say, Norwegian, the intuitively right thing is what actually happens
because Norwegian as spoken by the people of Norway is relatively obvious
(the English case was obvious, too, dagnabbit! But they chose poorly! Yes,
I know there are historical reasons why this is done in POSIX systems;
doesn't make it right :-( )
The same problem as noted here will occur if somebody creates differing
"es" and "es_ES" translations. They will always get back the "es_ES"
version. Again, because the initial designator has to have the ambiguity
resolved somehow.
Conclusion: this is a wontfix situation, because it's arguably not a bug
and the behaviour is consistent. If we patch English, why not start
patching all the other locales (`en_uk -> en_GB`, but `english_uk ->
en_EN` ... huh?!)? A documentation patch (in a separate ticket so that it
can be handled in isolation) might be appropriate to explain this. I
realise the whole i18n situation can get pretty convoluted when you're
trying to do the right thing.
--
Ticket URL: <http://code.djangoproject.com/ticket/8626#comment:9>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
