#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
-------------------------------------+-------------------------------------
Changes (by Carlton Gibson):
* cc: Claude Paroz, Simon Charette (added)
Comment:
OK, this is a goody.
To be clear the issue is that `get_language()` returns `None` in the
context of
a `migrate` command on 3.1, but `settings.LANGUAGE_CODE` (so `en-us`) on
3.0.
In the example project this manifests when the result of `get_language()`
is interpolated into a field name on a `ModelForm` — either way there's an
error, it's just what the missing field is called that's at stake.
So, on Django 3.0:
{{{
from letsagree.views import PendingView
File "/Users/carlton/Desktop/ticket_31911/letsagree/views.py", line 2,
in <module>
from letsagree.forms import TestView
File "/Users/carlton/Desktop/ticket_31911/letsagree/forms.py", line 6,
in <module>
class PendingConsentForm(forms.ModelForm):
File "/Users/carlton/Documents/Django-
Stack/django/django/forms/models.py", line 267, in __new__
raise FieldError(message)
django.core.exceptions.FieldError: Unknown field(s) (summary_en-us)
specified for Term
}}}
vs Django 3.1:
{{{
from letsagree.views import PendingView
File "/Users/carlton/Desktop/ticket_31911/letsagree/views.py", line 2,
in <module>
from letsagree.forms import TestView
File "/Users/carlton/Desktop/ticket_31911/letsagree/forms.py", line 6,
in <module>
class PendingConsentForm(forms.ModelForm):
File "/Users/carlton/Documents/Django-
Stack/django/django/forms/models.py", line 267, in __new__
raise FieldError(message)
django.core.exceptions.FieldError: Unknown field(s) (summary_None)
specified for Term
}}}
Other commands, e.g. `check` do not trigger this difference. That is
because
`migrate` runs with the `@no_translations` decorator applied.
In this context, it looks like the 3.1 behaviour is correct:
> **get_language()**: Returns the currently selected language code.
Returns `None` if translations are temporarily deactivated (by
`deactivate_all()` or when None is passed to `override()`).
Reading that, I'm expecting `None` here when `@no_translations` is in
play.
The change in behaviour occurs in Simon's
0b83c8cc4db95812f1e15ca19d78614e94cf38dd.
From the change there to `migrate.py`, it looks like it must have
something to do with:
> This also removes unnecessary `BaseCommand._run_checks()`` hook.
(But I didn't yet experiment reverting that bit.)
`@no_translations` was introduced by Claude in
d65b0f72de8d35617fe0554ddabc950c7f323eef (for Django 2.1).
Interestly, the behaviour before that commit (during `migrate`) was for
`get_language()` to return `None`. With d65b0f72 it changes to returning
`LANGUAGE_CODE`. Then with 0b83c8cc it went back to returning `None`.
So we need to decide what to say...
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31911#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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.931fe8f23a2220969a5bca4f1b96cbaa%40djangoproject.com.
