Opened 4 years ago

Closed 4 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 4 years ago.
Patch for checking for supported languages when using settings.LANGUAGE_CODE

Download all attachments as: .zip

Change History (10)

Changed 4 years ago by Emanuel Steen

Patch for checking for supported languages when using settings.LANGUAGE_CODE

comment:1 Changed 4 years ago by Carl Meyer

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 Changed 4 years ago by Jannis Leidel

Component: TranslationsInternationalization

Yep, I agree with Carl.

comment:3 Changed 4 years ago by Łukasz Langa

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

This is related to #17866. Picking up.

comment:4 Changed 4 years ago by Tomek Paczkowski

Needs tests: set

comment:5 Changed 4 years ago by Łukasz Langa

Pull request:

Tests pass on both 2.7 and 3.3.

comment:6 Changed 4 years ago by Łukasz Langa <lukasz@…>

Resolution: fixed
Status: assignedclosed

In 8c8f94fe9dcdd4983ebeb59951e6f7399bc287a2:

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

comment:7 Changed 4 years ago by Ramiro Morales

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

comment:8 Changed 4 years ago by Max Arnold

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 Changed 4 years ago by Łukasz Langa

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