respect LANGUAGE_CODE in management command instead of overriding it with 'en-us'

[Artem Skoretskiy]

For now settings.LANGUAGE_CODE is not used at all for all tasks except runserver and runfcgi

That makes a real issue when we use some custom commands that uses i18n - for example, celery.

Investigating that I found that code in django/core/management/base.py:202 (ommited useless details):

        # Switch to English, because django-admin.py creates database content
        # like permissions, and those shouldn't contain any translations.
                from django.utils import translation
                translation.activate('en-us')

First of all - this assumption is invalid - nothing broken when I created tables (including permissions) after disabling this code.

Then - even DB creation must respect selected locale. If I have a project in Russian and generate database having Russian locale - it should really use it.

After I disabled it - everything works fine

I can provide patch if needed.

[Fede Heinz]

There's not enough information in the report to decide whether this really is an issue or not.

The report states that nothing broke when the code was disabled, but that doesn't mean that it won't ever break anything... just that the reporter was lucky enough to have a setup that didn't break, while other setups may.

It is also not clear what the user means with "DB creation respecting selected locale"... what exactly is not being respected? What was the expected behavior, and what happened instead?

The available info is insufficient to reproduce the problem.

[Artem Skoretskiy]

Replying to fheinz:

The available info is insufficient to reproduce the problem.

The problem that settings.LANGUAGE_CODE is ignored when custom management commands are executed. So my management command is executed with invalid (en-us) language context making all translation work wrong.

Reproduce steps:
1) Set LANGUAGE_CODE to "ru-ru" in settings.py file
2) Write custom management command "mycustomcommand" that use translations anyhow
3) Run in via "./manage.py mycustomcommand"
4) See that result of "mycustomcommand" was generated using "en-us" for translations, i.e. texts in English

Expected result: result of "mycustomcommand" is generated using "ru-ru" for translations, i.e. in Russian

The report states that nothing broke when the code was disabled, but that doesn't mean that it won't ever break anything... just that the reporter was lucky enough to have a setup that didn't break, while other setups may.

I removed the ugly hack used in django/core/management/base.py:202 and found that it works for this current issue. That hack should be removed or used on commands that may crash without it (that's DB management command if comment is actual). So I just provided the starting point for further investigation - like why we force English for django-admin.py DB content generation.

[Fede Heinz]

Would you mind providing a small project with just enough code to expose the problem? It would help a lot in understanding the issue you are seeing.

[Ramiro Morales]

Replying to tonnzor:

First of all - this assumption is invalid - nothing broken when I created tables (including permissions) after disabling this code.

The names of permissions stored in the DB are in essence constants, and I suspect they are in English simply because it was the first (and only, Django hadn't I18N support at that time) language when the auth app was created. That's why these values aren't translatable, if you stored values translated to ru-ru there, code that checks and parses these permissions wouldn't work at all for an user with another locale preference.

Then - even DB creation must respect selected locale. If I have a project in Russian and generate database having Russian locale - it should really use it.

After I disabled it - everything works fine

We digress, your original report is about not forcibly activating en-us for custom management commands.

Maybe we can add a can_manage_i18n (or similar) command class-level flag similar to can_import_settings, requires_model_validation`, etc. that defaults to False so third party commands can override it to True at their own risk?

[Artem Skoretskiy]

The names of permissions stored in the DB are in essence constants, and I suspect they are in English simply because it was the first (and only, Django hadn't I18N support at that time) language when the auth app was created. That's why these values aren't translatable, if you stored values translated to ru-ru there, code that checks and parses these permissions wouldn't work at all for an user with another locale preference.

Please, look at the table auth_persissions - it has following structure (and data - trimmed):
Here's a small piece of data:

+-----+-----------------------------------------------+-----------------+----------------------------------------+
| id  | name                                          | content_type_id | codename                               |
+-----+-----------------------------------------------+-----------------+----------------------------------------+
|   1 | Can add permission                            |               1 | add_permission                         |
|   2 | Can change permission                         |               1 | change_permission                      |
|   3 | Can delete permission                         |               1 | delete_permission                      |

As you see - codename is in English and may be - and it is done - easily parsed - that should stay English for sure.
"name" is human-readable name that is not used for parsing and SHOULD be translated into the user language.

Maybe we should fill another bug for this specific issue (permissions name)

[Artem Skoretskiy]

Replying to ramiro:

Yes, I will provide it as soon as I get a bit more time for that.

[Fede Heinz]

Replying to tonnzor:

As you see - codename is in English and may be - and it is done - easily parsed - that should stay English for sure.
"name" is human-readable name that is not used for parsing and SHOULD be translated into the user language.

While I agree that this info should be shown to the user in translated form, I don't think it's reasonable to do so by storing a localized string in the database, but rather by translating it in the UI. Storing the human-readable name in English makes sense, because it makes it easy to provide translations for all languages, while if you store this kind of info in the local language, you can no longer provide a translated string to a user with a different locale.

If the issue that prompted you to report this as a bug is similar to this, maybe you should reconsider the wisdom of storing structured data in localized form.

[Ramiro Morales]

See also #10078.

[Ramiro Morales]

Replying to ramiro:

We digress, your original report is about not forcibly activating en-us for custom management commands.

Maybe we can add a can_manage_i18n (or similar) command class-level flag similar to can_import_settings, requires_model_validation`, etc. that defaults to False so third party commands can override it to True at their own risk?

I'm going to close this as a duplicate of #10078. Malcolm already explained there the reasons having a stable locale active is desirable and how the Django docs can help management command authors to take LANGUAGE_CODE in account if they need to.

[Jacob]

Milestone 1.3 deleted