#29425 closed New feature (needsinfo)

Auto language redirect does not work if prefix_default_language=False in root URLConf

Reported by: Nathan Humphreys Owned by: nobody
Component: Internationalization Version: master
Severity: Normal Keywords:
Cc: Krzysztof Urbaniak, Carlton Gibson Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When the prefix_default_language is set to False in the root URL Conf, django does not redirect a user based on the Accept-Language header, it always displays the default language.

This means that if I want to show the default language without a language URL prefix I cannot do the automatic redirect if a user accept-language header matches another language. But if i want the automatic redirect, I have to show the default language prefix.

Change History (6)

comment:1 Changed 15 months ago by Nathan Humphreys

Type: UncategorizedBug

comment:2 Changed 15 months ago by Ingo Klöcker

Resolution: invalid
Status: newclosed

I think there is a misunderstanding about what i18n_patterns() does.

I have added the following to my root URL conf

urlpatterns += i18n_patterns(
    url(r'^about/$', about, name='about')
)

and set LANGUAGE_CODE to 'en' in settings.py.

When I try

curl -vs http://127.0.0.1:8000/en/about/ >/dev/null

then I get

[...]
< HTTP/1.0 200 OK
[...]

But, when I try

curl -vs http://127.0.0.1:8000/about/ >/dev/null

then I get

[...]
< HTTP/1.0 404 Not Found
[...]

As you can see, no redirect happens.

If I understand your report correctly, then you seem to have expected that the URL missing the language prefix (i.e. http://127.0.0.1:8000/about/) would have been auto-redirected to the prefixed URL (i.e. http://127.0.0.1:8000/en/about/). But that's not what i18n_patterns() does.

All that i18n_patterns() does, is that it makes sure that URLs prefixed with the language prefix matching the user's Accept-Language header open the corresponding view. I have checked the code (there's nothing there that redirects) and the documentation (only one section, "The set_language redirect view", mentions redirects).

If I have misunderstood your problem, then please reopen this report explaining your problem in more detail, e.g. by providing a small example project demonstrating the problem. Also provide some URLs demonstrating your expectations and what actually happens.

comment:3 Changed 14 months ago by Stefano Rivera

Resolution: invalid
Status: closednew

Ingo: Your example does not use prefix_default_language=False. The URL conf should have been:

urlpatterns += i18n_patterns(
    url(r'^about/$', about, name='about'),
    prefix_default_language=False
)

I've run into this issue too. And it looks like a last-minute design decision in #25933. The follow-up commit (85a4844f8a8e628b90fa30ba7074f162a2d188ef) introduced this issue, together with this test, that makes it clear it was intentional:

def test_unprefixed_language_other_than_accept_language(self):
    response = self.client.get('/simple/', HTTP_ACCEPT_LANGUAGE='fr')
    self.assertEqual(response.content, b'Yes') 

I'd expect the result of this request to be a redirect to /fr/simple/.

Presumably /en/simple/ would return an English result, if one needed to override the browser.

comment:4 Changed 14 months ago by Tim Graham

Cc: Krzysztof Urbaniak added

comment:5 Changed 14 months ago by Carlton Gibson

Cc: Carlton Gibson added

So why is the behaviour as it is?

Explanation from PR 6264, which added the extra test and behaviour:

The redirect should only happen on / URL, with prefix_default_language set to True (default behaviour).

Each other request (like /fr/whatever/) should not look at Accept-Language header at all,
just serve the page for the language requested in URL.

When the prefix_default_language is False the / url is the same as /en/
(with settings.LANGUAGE_CODE=en) so we should just ignore the Accept-Language here.

comment:6 Changed 13 months ago by Carlton Gibson

Resolution: needsinfo
Status: newclosed
Type: BugNew feature
Version: 1.11master

So, given no follow-up, I'm going to conclude the following:

  • The current behaviour is as expected, so there's no bug.
  • Possibly there's a New Feature request hidden in here. (Please allow doing X, Y, Z...)
  • However the description is not detailed enough to say exactly what would need to be added, and (so) whether that would be acceptable or not.

As such, I'm going to mark this needsinfo. If someone wants to flesh-out what's being requested, and how that might behave and could be implemented then we can re-open to re-assess.

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