Opened 3 years ago

Closed 2 years ago

#19763 closed Bug (fixed)

LocaleMiddleware should check for supported languages in settings.LANGUAGE_CODE too

Reported by: kozz Owned by: ambv
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 kozz 3 years ago.
Patch for checking for supported languages when using settings.LANGUAGE_CODE

Download all attachments as: .zip

Change History (10)

Changed 3 years ago by kozz

Patch for checking for supported languages when using settings.LANGUAGE_CODE

comment:1 Changed 3 years ago by carljm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to 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:2 Changed 3 years ago by jezdez

  • Component changed from Translations to Internationalization

Yep, I agree with Carl.

comment:3 Changed 3 years ago by ambv

  • Owner changed from nobody to ambv
  • Status changed from new to assigned

This is related to #17866. Picking up.

comment:4 Changed 3 years ago by oinopion

  • Needs tests set

comment:5 Changed 3 years ago by ambv

Pull request:

Tests pass on both 2.7 and 3.3.

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

  • Resolution set to fixed
  • Status changed from assigned to closed

In 8c8f94fe9dcdd4983ebeb59951e6f7399bc287a2:

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

comment:7 Changed 3 years ago by ramiro

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

comment:8 Changed 2 years ago by lwarx

  • Resolution fixed deleted
  • Status changed from closed to 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 Changed 2 years ago by ambv

  • Resolution set to fixed
  • Status changed from new to closed

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