the admin switches locales between refreshes

RESOLVED FIXED

Status

Input
General
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: willkg, Assigned: willkg)

Tracking

Details

Bear with me, this is weird. It's probably Fringe-worthy weird.

If you go into the admin and refresh any of the admin pages a few times, it'll switch locales: text that's been translated, the way dates are formatted, etc.

I can only see this in production--not stage or locally. It's likely because production has enough traffic that it's seeing requests from non-english locales. It's possible that I could figure out how to reproduce it given enough time.

I've never seen this before, so I'm guessing it's related to either upgrading to Django 1.8 and/or the changes we made when we dropped jingo and tower.

Since this only affects the admin, I think we're "ok", but it's definitely fishy and should probably be looked into.
MDN ran into this same issue and solved it be reordering middleware (bug 1237661)
See Also: → bug 1237661
Grabbing this because I'm going to look into it next week because it's irritating.

I was thinking first thing I could do would be to create an admin view that shows me all the relevant variable values for the request, user and session and whatever else.

Mike suggested that the problem could be that the locale middleware is ignoring admin/ views when it goes to set the locale and because it's ignoring them, nothing gets set, so then the admin uses the language set by the last request. That's definitely something to look into.
Assignee: nobody → willkg
Status: NEW → ASSIGNED
I can reproduce this on -stage now.

STR:

1. in one browser, log in and go to /admin/
2. in another fresh browser, go to /fr/ a bunch of times
3. in the first browser, refresh the admin

This will turn the admin french (assuming no one else is touching -stage at the time). I can switch to other languages, too--this isn't a problem with just fr.

I can't reproduce it locally using "./manage.py runserver" or "./manage.py runserver_plus", but if I fix the totally broken fjord/wsgi.py file, I can reproduce it using "gunicorn fjord.wsgi".

Now that I can reproduce it locally, I'll investigate Mike's theory.
I'm pretty sure I figured it out. Our prefixer returns '' for locale for the /admin/ pages. Our locale aware middleware calls translation.activate(prefixer.locale) which is '' for the /admin/.

Django 1.8 picked up this fix:

https://github.com/django/django/commit/543df07720181fe23737ba14f1a261ff6f37f49c

So then prefixer.locale is '', our locale-aware middleware calls translation.activate('') and now that does nothing which causes /admin/ to be rendered with the language of the previously handled request for that thread.

In a PR: https://github.com/mozilla/fjord/pull/732
Landed in https://github.com/mozilla/fjord/commit/5109f96c12a86f38123c59c6b05d73a0832266b6

I want to push this to -stage today, verify it works and then push it to -prod. I'll coordinate with Mike Kelly to do this.
Tested it on -stage and it was super duper. Yay!
I'm going to assume this has been pushed to -prod by now. Closing this out.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.