#28567: Incompatibility between the set_language() view, LocaleMiddleware, and
i18n_patterns() when prefix_default_language=False.
-------------------------------------+-------------------------------------
Reporter: George Tantiras | Owner: Jason
| Judkins
Type: Bug | Status: assigned
Component: | Version: dev
Internationalization |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jason Judkins):
I've picked this up (PR [https://github.com/django/django/pull/21240
21240]) and want to summarize where the ticket stands, since the history
is spread across several comments and duplicates.
The root cause was diagnosed by Carlton Gibson in comment:14:
translate_url() resolves the URL using whatever language is currently
active, rather than the language encoded in the URL itself. When
LocaleMiddleware activates a language that differs from the URL's prefix —
which happens whenever the language cookie and the URL prefix are out of
sync — resolve() raises Resolver404, translate_url() silently swallows it,
and the original URL is returned unchanged. comment:14 laid out three
possible fix locations (translate_url, set_language, LocaleMiddleware) and
suggested Option 2 (have the resolution account for the URL's own
language) as most likely, while noting none looked especially clean.
Eric Soroos independently arrived at the same conclusion in comment:20,
posting a translate_url()-based patch that resolves with the active
language first and falls back to the URL-prefix language. PR 21240
converges on that same approach: source-language detection now lives
inside translate_url() itself, so the function derives the correct
language from the URL it is given rather than depending on caller-set
context.
Two things PR 21240 adds beyond the prior patches:
A regression test for the set_language integration path (cookie language ≠
URL prefix language), plus direct translate_url() unit tests covering both
prefixed and unprefixed translated URLs — including the unprefixed case
raised in review, which the first iteration of the patch missed.
Full-suite verification. The i18n, view_tests, urlpatterns, and
urlpatterns_reverse suites pass with no regressions, which I think
directly addresses the "none of them look that nice" hesitation in
comment:14 — fixing this in translate_url() does not break any existing
caller.
The remaining open question from comment:14 is whether translate_url() is
the agreed-upon home for the fix, versus set_language or LocaleMiddleware.
Three independent contributors have now landed on translate_url(), and the
empirical results suggest it's safe, but a decision from someone with
authority over i18n would help unblock a ticket that has been pending one
since 2018. Given Claude Paroz is cc'd here as the i18n domain expert, his
read would be especially valuable.
--
Ticket URL: <https://code.djangoproject.com/ticket/28567#comment:23>
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019e410f8dda-6851d7c5-64e1-4ec9-8218-cc34e76f6bc6-000000%40eu-central-1.amazonses.com.
