Locale detection is broken, doesn't respect the accepted locales

VERIFIED FIXED in 1.0

Status

defect
P1
major
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: stas, Assigned: brez)

Tracking

({l12y})

Dependency tree / graph

Details

Attachments

(1 attachment)

Reporter

Description

8 years ago
I'm not sure how localeurl.middleware.LocaleURLMiddleware works, but it doesn't seem to take into account the accepted locales defined in the LANGUAGES array in https://github.com/mozilla/markup/blob/master/ffdemo/settings.py#L50. 

If I visit the staging site with the following locale prefs: (pl, fr), I see English, and I should see French (French is the first accepted locales on the list.)
Assignee: nobody → adam
Blocks: 628811
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → 1.0
Assignee: adam → jbresnik
Assignee

Comment 1

8 years ago
I don't understand - are the translations done?  If not, you will only ever see English
Assignee

Comment 2

8 years ago
Stas - assign this to you so you can answer...
Assignee: jbresnik → stas
I checked out http://svn.mozilla.org/projects/l10n-misc/trunk/markup/locale/ into a local directory

ffdemo/locale

I edited the es django.po
I added es to the list of supported locales in settings.py
I restarted my server.

I didn't see the Spanish strings :(
Reporter

Comment 4

8 years ago
Right now, independent of my browser's language preferences, I'm always served en-US on the staging server.

(Back when I filed this bug, the locale detection would only look on the first language in my preferences, and if it wasn't on the supported locales list in settings, it would fall back to en-US, instead of looking at my second preference, third, and so on.)
Assignee: stas → jbresnik
Blocks: 654862
Just to clarify a part of a test plan...

Locale detection Use Case
1) Switch primary language of Firefox 4 to French
2) http://209.20.77.205/

Actual
Redirected to http://209.20.77.205/en-US/#/

Expected
Redirected to http://209.20.77.205/fr/#/
By adding tower, jingo, commons/middleware.py etc i've got the fr redirect working locally for the homepage.

Cursory testing, this breaks mark submission, so I'm digging into why.
This should work now. I've added our usual middleware as well as jingo.

fr redirection works.
I've tested with fake Spanish strings, and gettext is working.

https://github.com/mozilla/markup/commit/120e63cd0cb5a408d2ac502596e83ef5d637d33b

https://github.com/mozilla/markup-lib/commit/9b6096ac13ffbad4febad825f10104c342b4b28c
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Not seeing the fix on stage. Troubleshooting in Bug#655271
Reporter

Comment 9

8 years ago
Comment on attachment 530471 [details] [diff] [review]
Adding commons, tower, etc

Review of attachment 530471 [details] [diff] [review]:
-----------------------------------------------------------------

::: ffdemo/settings.py
@@ +61,5 @@
>          from product_details import product_details
> +        return dict([(lang.lower(), product_details.languages[lang]['native'])
> +                     for lang in KNOWN_LANGUAGES])
> +
> +LANGUAGES = lazy(LazyLangs, dict)()

Any specific reason why you changed the tuple to a dict?  I think this broke the lang switcher in the footer.
Reporter

Comment 10

8 years ago
I filed bug 655305 to address comment 9.

Otherwise, the locale detection works very well now.  Thanks a ton, Austin!
This data structure is required by our middleware.
I'll look at updating the lang drop down.
Reporter

Comment 12

8 years ago
Filed another follow-up: bug 655875.
Reporter

Comment 13

8 years ago
This works as expected now, thanks Austin.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.