Action triggered by django.core.management.base.BaseCommand.can_import_settings is a side effect of i18n locale handling

[Ramiro Morales]

As discussed in #17379

(from https://code.djangoproject.com/ticket/17379#comment:7):

can_import_settings was supposed to check if settings are available before execution of a command according to documentation (​​https://docs.djangoproject.com/en/dev/howto/custom-management-commands/#BaseCommand.can_import_settings). It was doing that only by coincidence… it was doing that by forcing en_us locale via translation module which relies on settings.

This ticket will act as a dependancy of #17379.

[Claude Paroz]

Fixed in [869c9ba30615cb24fb5786787a2db8655f2f0d2b]:

Fixed #19730 -- Don't validate importability of settings by using i18n in management commands.

They are handled independently now and the latter can be influenced by
the new BaseCommand.leave_locale_alone internal option.

Thanks chrischambers for the report, Claude, lpiatek, neaf and gabooo for
their work on a patch, originally on refs. #17379.

[Claude Paroz]

Thanks Ramiro for taking this forward. However I'm not sure about the comment: because many of them create database content that is locale-sensitive (like permissions).

So apart from syncdb, which are the commands who alter the database with potentially localized content?

[Ramiro Morales]

Replying to claudep:

Thanks Ramiro for taking this forward. However I'm not sure about the comment: because many of them create database content that is locale-sensitive (like permissions).

So apart from syncdb, which are the commands who alter the database with potentially localized content?

I will reword that paragraph beacuse I can only think of 'test'. Thanks!