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)

django_utils_translation_trans_real.py.diff (614 bytes ) - added by Emanuel Steen 12 years ago.
Patch for checking for supported languages when using settings.LANGUAGE_CODE

Download all attachments as: .zip

Change History (10)

by Emanuel Steen, 12 years ago

Patch for checking for supported languages when using settings.LANGUAGE_CODE

comment:1 by Carl Meyer, 12 years ago

Triage Stage: UnreviewedAccepted

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:2 by Jannis Leidel, 12 years ago

Component: TranslationsInternationalization

Yep, I agree with Carl.

comment:3 by Łukasz Langa, 12 years ago

Owner: changed from nobody to Łukasz Langa
Status: newassigned

This is related to #17866. Picking up.

comment:4 by Tomek Paczkowski, 12 years ago

Needs tests: set

comment:5 by Łukasz Langa, 12 years ago

Pull request:

Tests pass on both 2.7 and 3.3.

comment:6 by Łukasz Langa <lukasz@…>, 12 years ago

Resolution: fixed
Status: assignedclosed

In 8c8f94fe9dcdd4983ebeb59951e6f7399bc287a2:

Fixes #19763 - LocaleMiddleware should check for supported languages in settings.LANGUAGE_CODE

comment:7 by Ramiro Morales, 12 years ago

This ticket was a duplicate of #9340. Will close it as a dupe.

comment:8 by Max Arnold, 12 years ago

Resolution: fixed
Status: closednew

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 Łukasz Langa, 11 years ago

Resolution: fixed
Status: newclosed

I don't think we can backport it to 1.5.x at this point.

Note: See TracTickets for help on using tickets.
Back to Top