Code

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#13859 closed (duplicate)

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

Reported by: tonnzor Owned by:
Component: Core (Management commands) Version: master
Severity: Keywords:
Cc: tonn81@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Attachments (0)

Change History (12)

comment:1 Changed 4 years ago by tonnzor

  • Cc tonn81@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 follow-up: Changed 3 years ago by fheinz

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.

comment:3 in reply to: ↑ 2 Changed 3 years ago by tonnzor

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.

comment:4 Changed 3 years ago by fheinz

  • Owner nobody deleted

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.

comment:5 follow-up: Changed 3 years ago by ramiro

  • Summary changed from Always respect LANGUAGE_CODE to respect LANGUAGE_CODE in management command instead of overriding it with 'en-us'

comment:6 in reply to: ↑ description ; follow-ups: Changed 3 years ago by ramiro

  • Triage Stage changed from Unreviewed to Design decision needed

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?

comment:7 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by tonnzor

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)

comment:8 in reply to: ↑ 5 Changed 3 years ago by tonnzor

Replying to ramiro:

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

comment:9 in reply to: ↑ 7 Changed 3 years ago by fheinz

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.

comment:10 Changed 3 years ago by ramiro

See also #10078.

comment:11 in reply to: ↑ 6 Changed 3 years ago by ramiro

  • Resolution set to duplicate
  • Status changed from new to closed

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.

comment:12 Changed 3 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.