#29281: In some cases i18n set_language does not change url language
-------------------------------------+-------------------------------------
Reporter: commilfo | Owner: nobody
Type: Bug | Status: new
Component: | Version: 1.11
Internationalization |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by commilfo:
Old description:
> In general POST to /i18n/setlang/ works fine.
> Sometimes it fails: if the current link is /es/smth/ (or just /es/,
> whatever), post to /i18n/setlang/ with 'en' reloads the same link
> /es/smth/, instead of /en/smth/.
> Happens from time to time in our prod, dev servers and locally. Sometimes
> just closing the browser window and opening the site again solves the
> issue. At the same time it may be fine in one browser and fail in
> another. Yesterday I encountered it locally and was able to debug:
>
> {{{
> # from django.views.i18n, set_language
> # current link is '/es/smth/', POST to /i18n/setlang/ with language: en,
> csrfmiddlewaretoken: xxx
> ...
> if request.method == 'POST':
> lang_code = request.POST.get(LANGUAGE_QUERY_PARAMETER) # ='en'
> if lang_code and check_for_language(lang_code):
> if next:# next = '/es/smth/'
> next_trans = translate_url(next, lang_code)# returns the same
> '/es/smth/'
> if next_trans != next:# next == next_trans, url is not
> changed, the same /es/smth/ url is reloaded, language haven't changed
> response = http.HttpResponseRedirect(next_trans)
> ...
> }}}
>
> {{{
> # django.urls.base, translate_url:
> ...
> parsed = urlsplit(url) # SplitResult(scheme='http',
> netloc='127.0.0.1:8080', path='/es/smth/', query='', fragment='')
> try:
> match = resolve(parsed.path)# triggers Resolver404
> except Resolver404:
> pass
> else:
> ...
> }}}
>
> {{{
> # django.urls.base, resolve
> def resolve(path, urlconf=None): # path is the current url, /es/smth/
> if urlconf is None:
> urlconf = get_urlconf() # None
> return get_resolver(urlconf).resolve(path) # <RegexURLResolver
> 'proj.urls' (None:None) ^/>, resolve(path) triggers Resolver404
> }}}
>
> Resolver404: {'tried': [[<RegexURLResolver <RegexURLPattern list>
> (admin:admin) ^admin/>], [<RegexURLResolver <module
> 'django.conf.urls.i18n' from 'C:\\Python36\\Scripts\\aliro\\Lib\\site-
> packages\\django\\conf\\urls\\i18n.py'> (None:None) ^i18n/>],
> [<LocaleRegexURLResolver <RegexURLResolver list> (None:None) ^en/>]],
> 'path': 'es/smth/'}
>
> So, sometimes get_resolver(None).resolve(path) where path matches a
> listed i18n_pattern, fails, and in another browser the same path is
> matched fine.
>
> {{{
> #proj.urls.py:
> ...
> urlpatterns += i18n_patterns(
> url(r'^', include('app.urls')),
> )
> ...
> }}}
>
> I don't have a setup and\or scenario to reproduce it everytime.
> Django 1.11.10
New description:
In general POST to /i18n/setlang/ works fine.
Sometimes it fails: if the current link is /es/smth/ (or just /es/,
whatever), post to /i18n/setlang/ with 'en' reloads the same link
/es/smth/, instead of /en/smth/.
Happens from time to time in our prod, dev servers and locally. Sometimes
just closing the browser window and opening the site again solves the
issue. At the same time it may be fine in one browser and fail in another.
Yesterday I encountered it locally and was able to debug:
{{{
# from django.views.i18n, set_language
# current link is '/es/smth/', POST to /i18n/setlang/ with language: en,
csrfmiddlewaretoken: xxx
...
if request.method == 'POST':
lang_code = request.POST.get(LANGUAGE_QUERY_PARAMETER) # ='en'
if lang_code and check_for_language(lang_code):
if next:# next = '/es/smth/'
next_trans = translate_url(next, lang_code)# returns the same
'/es/smth/'
if next_trans != next:# next == next_trans, url is not
changed, the same /es/smth/ url is reloaded, language haven't changed
response = http.HttpResponseRedirect(next_trans)
...
}}}
{{{
# django.urls.base, translate_url:
...
parsed = urlsplit(url) # SplitResult(scheme='http',
netloc='127.0.0.1:8080', path='/es/smth/', query='', fragment='')
try:
match = resolve(parsed.path)# triggers Resolver404
except Resolver404:
pass
else:
...
}}}
{{{
# django.urls.base, resolve
def resolve(path, urlconf=None): # path is the current url, /es/smth/
if urlconf is None:
urlconf = get_urlconf() # None
return get_resolver(urlconf).resolve(path) # <RegexURLResolver
'proj.urls' (None:None) ^/>, resolve(path) triggers Resolver404
}}}
Resolver404: {'tried': [[<RegexURLResolver <RegexURLPattern list>
(admin:admin) ^admin/>], [<RegexURLResolver <module
'django.conf.urls.i18n' from 'C:\\Python36\\Scripts\\aliro\\Lib\\site-
packages\\django\\conf\\urls\\i18n.py'> (None:None) ^i18n/>],
[<LocaleRegexURLResolver <RegexURLResolver list> (None:None) ^en/>]],
'path': 'es/smth/'}
So, sometimes get_resolver(None).resolve(path) where path matches a listed
i18n_pattern, fails, and in another browser the same path is matched fine.
The variables in both runs are the same until
get_resolver(urlconf).resolve(path), where one triggers Resolver404, and
the other returns a matched url (ResolverMatch(func=app.views.smth,
args=(), kwargs={'template_name': 'app/smth.html'}, url_name=smth,
app_names=[], namespaces=[]))
{{{
#proj.urls.py:
...
urlpatterns += i18n_patterns(
url(r'^', include('app.urls')),
)
...
}}}
I don't have a setup and\or scenario to reproduce it everytime.
Django 1.11.10
--
--
Ticket URL: <https://code.djangoproject.com/ticket/29281#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.2a72d350278da51ea7a2a69652eea282%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
