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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29425>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* type: Uncategorized => Bug
--
Ticket URL: <https://code.djangoproject.com/ticket/29425#comment:1>
* status: new => closed
* resolution: => invalid
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29425#comment:2>
* status: closed => new
* resolution: invalid =>
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29425#comment:3>
* cc: Krzysztof Urbaniak (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29425#comment:4>
* cc: Carlton Gibson (added)
Comment:
So why is the behaviour as it is?
[https://github.com/django/django/pull/6264#issuecomment-194897558
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29425#comment:5>
* status: new => closed
* type: Bug => New feature
* version: 1.11 => master
* resolution: => needsinfo
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29425#comment:6>