Locate subset language problem
Nuno Mariz
system.
I can't define only the "pt" locale, because if the user uses in his
browser "pt-br" it loads the "pt-br" and not the "pt" that was defined
in LANGUAGE settings:
gettext = lambda s: s
LANGUAGES = (
('pt', gettext('Portuguese')),
('en', gettext('English')),
)
Any idea to resolve this, or I must do a middleware to fix this?
Thanks,
Nuno Mariz
Malcolm Tredinnick
On Fri, 2007-03-30 at 11:36 +0000, Nuno Mariz wrote:
> Seems that is not possible to disable a subset language in locale
> system.
What do you mean by "disable the subset language" here?
> I can't define only the "pt" locale, because if the user uses in his
> browser "pt-br" it loads the "pt-br" and not the "pt" that was defined
> in LANGUAGE settings:
This sounds like you want fallback behaviour, so that pt-br falls back
to pt (if pt-br isn't available) and then to C (or whatever the default
is). Is that correct? Or what do you expect to happen if they send in
pt-br?
We don't actually do fallback handling in Django at the moment, but I've
been wondering if we should -- I've been a little surprised that nobody
has brought it up previously.
If you can give an example of what you expect to have happen it would be
useful. If it's simple fallback, I think it's a reasonable request
(certainly happens in other packages / programming languages).
Regards,
Malcolm
Nuno Mariz
Simple example:
In my settings.py:
gettext = lambda s: s
LANGUAGES = (
('pt', gettext('Portuguese')),
('en', gettext('English')),
)
Imagine a client accessing to my site with a browser using 'pt-br', my
applications falls in 'pt-br'(because of
'django.middleware.locale.LocaleMiddleware'), I think is wrong,
because in my settings.py I don't have the 'pt-br', only 'pt'.
When I say "disable the subset language", I mean that if the subset of
a language is not defined in the settings.py of the project shouldn't
be loaded.
Do you agree?
Malcolm Tredinnick
Something strange is going on here. Reading the middleware code and
django/utils/translation/trans_real.py (in particular, get_language()),
it looks like we should be following the rules laid out in i18n.txt.
That is, only LANGUAGES settings are used (so pt-br should not be
possible) and if they submit "pt-br" it will fall back to "pt".
You are seeing different behaviour, I gather?
I'll have to do some tests here to see what's going on. It's possible a
bug has crept in somehow. We should be doing exactly what you expect
(assuming I am understanding you): somebody who submits "pt-br" as their
preference will end up with "pt" as far as your application is
concerned.
Regards,
Malcolm
Nuno Mariz
is in the first visit on the site. The language is not selected(i.e.
not in the user cookies) and the middleware tries the locale of the
user browser and sets it even if the locale is not in the settings.py.
Im testing with the "Quick Locale Switcher" plugin for firefox(I
always clean my cookies for the test of course).
Malcolm Tredinnick
Hmmm... we should be treating the browser preference just the same as
other settings (with a lower priority). Might be a bug here. When I get
time, I'll have a look at it.
Could you file a ticket about this, please?
Thanks,
Malcolm
Nuno Mariz
On Apr 3, 2:37 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
Nuno Mariz
A patch that works for me is in: django/utils/translation/
real_trans.py in the function: "def
get_language_from_request(request):":
for lang, mainlang, order in langs:
if lang in supported or mainlang in supported:
# If the lang is not supported but mainlang is, than
activate mainlang
if not lang in supported and mainlang in supported:
lang = mainlang