#31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during
./manage.py
migrate
-------------------------------------+-------------------------------------
Reporter: George Tantiras | Owner: nobody
Type: Bug | Status: new
Component: | Version: 3.1
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
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
Thanks for the detailed investigation Carlton.
> Interestingly, the behaviour before that commit (during migrate) was for
`get_language()` to return `None`. With
d65b0f72de8d35617fe0554ddabc950c7f323eef it changes to returning
`LANGUAGE_CODE`. Then with `0b83c8cc` it went back to returning None.
>
> I'm inclined to think that using `get_language()` at import time (during
start-up) shouldn't be supported, since we're not in an active language
context, but happy to take guidance on that.
I tend to agree here. If it always returned `None` before
d65b0f72de8d35617fe0554ddabc950c7f323eef and wasn't tested to return
`LANGUAGE_CODE` we could maybe accept a ''new feature'' request to make it
default to `LANGUAGE_CODE` but we can hardly define it as a regression.
--
Ticket URL: <https://code.djangoproject.com/ticket/31911#comment:3>
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 on the web visit
https://groups.google.com/d/msgid/django-updates/066.04a4c7ad60f7931c0cc14ccf4d7ead62%40djangoproject.com.
