Opened 10 months ago

Closed 10 months ago

Last modified 10 months ago

#22868 closed Bug (duplicate)

Activated language not respected in post_save signal called during custom management command

Reported by: stodge Owned by: nobody
Component: Core (Management commands) Version: 1.6
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This one is a little tricky to explain. My problem seems to be this:

  • run custom management command
  • activate language from settings, which is "en-gb"
  • dynamically import module for a Django app and invoke custom bootstrap function
  • calling get_language() in bootstrap function returns "en-gb"
  • bootstrap function calls loaddata management command (using management.call_command)
  • data created in DB, which triggers a post_save signal
  • get_language() in post_save signal always returns "en-us"

I don't know if the signal is invoked in a separate thread but I would expect get_language to return the newly activated language when called in a post_save signal. Or am I missing something? Thanks

Change History (4)

comment:1 Changed 10 months ago by timo

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

As documented, most management commands force the locale to en-us which I suspect is what you are running into when your command invokes loaddata.

You may be able to work around the problem for now, but I think this the root cause would be fixed by #17379.

comment:2 Changed 10 months ago by stodge

I should have referenced the documentation as I aware of the limitation it describes. I am running into this problem although I don't understand why I can activate and use a different language but not when running code in a signal handler.

I may be able to workaround this but it would be an ugly hack. #17379 was opened 3 years ago so I'll have to accept it won't get fixed any time soon.

comment:3 Changed 10 months ago by timo

  • Component changed from Uncategorized to Core (Management commands)
  • Resolution set to duplicate
  • Status changed from new to closed
  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Uncategorized to Bug

Claude's patch in comment 16 looks like it has potential for resolving the issue. Maybe you'd like to review it and provide feedback and try to work with him on getting it committed. Resigning yourself to the position that the ticket won't get fixed soon because it was opened 3 years ago is a rather defeatist position to take. If you care about the problem, please pitch in and help!

comment:4 Changed 10 months ago by claudep

If I get some support from other core devs, I'd be happy to push #17379 forward. This should probably deserve a post on the developers mailing list.

Note: See TracTickets for help on using tickets.
Back to Top