Opened 12 years ago
Closed 11 years ago
#19763 closed Bug (fixed)
LocaleMiddleware should check for supported languages in settings.LANGUAGE_CODE too
Reported by: | Emanuel Steen | Owned by: | Łukasz Langa |
---|---|---|---|
Component: | Internationalization | Version: | 1.4 |
Severity: | Normal | Keywords: | locale |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
We have a Django project with the setting:
LANGUAGE_CODE = 'en-us'
LANGUAGES = (
('en', 'English'),
('sv', 'Swedish'),
)
These settings should be correct according to the documentation https://docs.djangoproject.com/en/dev/ref/settings/#language-code.
We also have the middleware django.middleware.locale.LocaleMiddleware enabled.
However, in django.utils.translation.trans_real.py in the method get_language_from_request(...) it simply falls back to settings.LANGUAGE_CODE without any validation. I expected it to check whether the language is supported or not in the same manner as for what it done for the URL, the cookie and the HTTP header.
This can easily be tested with curl (for example).
$ curl -v -H "Accept-Language: asd" http://localhost:8000/ -o /dev/null * About to connect() to localhost port 8000 (#0) * Trying 127.0.0.1... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* connected * Connected to localhost (127.0.0.1) port 8000 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.27.0 > Host: localhost:8000 > Accept: */* > Accept-Language: asd > * additional stuff not fine transfer.c:1037: 0 0 * additional stuff not fine transfer.c:1037: 0 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0* HTTP 1.0, assume close after body < HTTP/1.0 302 FOUND < Date: Thu, 07 Feb 2013 08:45:28 GMT < Server: WSGIServer/0.1 Python/2.7.3 < Vary: Cookie < Content-Type: text/html; charset=utf-8 < Location: http://localhost:8000/en-us/ < { [data not shown] 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 * Closing connection #0
Here the client sends a totally unknown language and the server responds with redirecting to http://localhost:8000/en-us/ when I expect it to redirect to http://localhost:8000/en/
Attachments (1)
Change History (10)
by , 12 years ago
Attachment: | django_utils_translation_trans_real.py.diff added |
---|
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
Seems like the workaround here is simple enough - why not just set LANGUAGE_CODE
to "en"?
That said, given that LANGUAGES
is documented as "restrict language selection to a subset of the Django-provided languages", it seems reasonable that Django shouldn't redirect to a language code outside of that set.
I'm not an expert on the localization stuff, though, so other core devs: feel free to reverse this decision if I'm way off base :-)
comment:3 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
This is related to #17866. Picking up.
comment:4 by , 12 years ago
Needs tests: | set |
---|
comment:5 by , 12 years ago
comment:6 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:8 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
I reported this issue in #19811 but the fix was superseded by this one and unfortunately missed 1.5 release. Is it possible to backport it to 1.5.x branch?
comment:9 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I don't think we can backport it to 1.5.x at this point.
Patch for checking for supported languages when using settings.LANGUAGE_CODE