[Django] #30675: Ignore ACCEPT_LANGUAGE header only on i18n prefixed url patterns
Django
------------------------------------------------+------------------------
Reporter: janezkranjc | Owner: nobody
Type: New feature | Status: new
Component: Internationalization | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
In the current version of django the localization middleware ignores the
accept language header if any i18n prefixed url pattern exist. It should
only ignore it if the active url pattern is prefixed.
This would allow the following usage:
* Have i18n prefixed urls for a website
* Allow accept language header for api views which are not prefixed
I am willing to write a patch for this if there it would be merged to
django eventually.
--
Ticket URL: <https://code.djangoproject.com/ticket/30675>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Janez Kranjc | Owner: nobody
Type: New feature | Status: new
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
Changes (by Janez Kranjc):
* version: 2.2 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/30675#comment:1>
Django
Reporter: Janez Kranjc | Owner: nobody
Type: New feature | Status: closed
Component: | Version: master
Internationalization |
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => needsinfo
Comment:
Hi Jenez,
Thanks for the report. I kind of see the use-case here but changes here
are non-trivial, so I think we need to flesh out the proposal, probably on
the DevelopersMailingList, before moving forwards. (This is a delicate
area and there's lots of expertise available there.)
Some thoughts...
* What's the exact use-case that's failing, and are the existing
workarounds that we can use? (Custom middleware... Setting active language
etc...)
* There's a long history for the Internationalization component, and open
tickets around `get_language_from_path()` and `..._request()` etc. Are
these related?
* What would the proposed change look like and what breaking changes would
be involved?
The need here is just to flesh out what's involved. I hope that makes
sense.
--
Ticket URL: <https://code.djangoproject.com/ticket/30675#comment:2>