Closed Bug 551113 Opened 16 years ago Closed 16 years ago

Locale-detection is broken

Categories

(Websites :: browserchoice.mozilla.com, defect)

Product:
Websites
Component:
browserchoice.mozilla.com
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: stephend, Assigned: wenzel)

References

(
URL
)

Details

Attachments

(2 files)

browserchoice.mozilla.com using ca Accept-language as first option
46.48 KB, text/plain
Details
browserchoice.stage.mozilla.com using ca Accept-language as first option
4.99 KB, text/plain
Details
Sadly, since we switched to (implemented?) EdgeCast's CDN solution on http://browserchoice.mozilla.com/, locale-detection code isn't working/getting hit/run. This works fine on staging, where a different architecture (Citrix NetScaler) is employed. (Alex can fill us in on the gory details.)
OS: Windows 2000 → Windows XP
r63933 fixes this on trunk, Now, when you hit /fr (and you have French in your browser prefs) you will be redirected to /locale/fr. This is to avoid the caching issues causing this bug. One benefit, is that you can now go directly to a locale, without having it in your browser prefs, by going to /locale/{code}
Assignee: nobody → buchanae
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
changed it from /locale/{code} to /lang/{code} to avoid conflicts with an existing /locale/ directory (gettext)
Verified FIXED on prod; works like a charm.
Status: RESOLVED → VERIFIED
The routing works from browserchoice.mozilla.com, but not from browserchoice.eu, is that correct? Patrick
(In reply to comment #4) > The routing works from browserchoice.mozilla.com, but not from > browserchoice.eu, is that correct? > > Patrick Not sure what you mean. If you go to browserchoice.eu, with Catalan as your preference, you'll get English there. When you click "Tell me more" you will (should) get browserchoice.m.c in Catalan.
Browser detection from Microsoft's ballot screen -> browserchoice.mozilla.com has always worked, thankfully: http://screencast.com/t/ZjBlMzZmYTI
(In reply to comment #5) > Not sure what you mean. If you go to browserchoice.eu, with Catalan as your > preference, you'll get English there. When you click "Tell me more" you will > (should) get browserchoice.m.c in Catalan. I cannot test on Windows at the moment, but Fx on Linux, with Catalan as my only language preference, when I click "tell me more" I get browserchoice.m.c. in en-GB
I've tried to reproduce this but can't. Tried different locales, fresh browsers and VMs. No luck. I haven't tried Linux though.
I have made some testing having 'ca' locale configured in Windows, and after last update in the server this has worsened. You can check situation on Sunday: http://www.cau.cat/blog/sites/default/files/images/browserballot2010/bb-captura3.png en-GB screen presented after clicking tell me more, but download in Catalan. Yesterday: http://www.cau.cat/blog/sites/default/files/images/browserballot2010/bb-captura-context-CAT.png en-GB page and download in en-GB, despite webpage in Catalan is already available: http://browserchoice.mozilla.com/lang/ca
It happens in any platform, in my Firefox in Linux as well. I tried browserchoice.mozilla.com in different primary languages an all them showed en-GB version.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
It seems to work in http://browserchoice.stage.mozilla.com/ Would you push this to production? I close back the bug.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Toni, there are no code differences between stage and production. The main difference between stage and production is the caching system, which I believe is causing your problem. I'm having IT clear the cache entirely (again). If someone who can reproduce this bug could record their http headers, that could be helpful. This Firefox add-on will do that, Live HTTP Headers https://addons.mozilla.org/ca/firefox/addon/3829 Before you load the browserchoice.eu page, go to Tools -> Live HTTP Headers. Now, load the ballot, and click the Firefox Tell Me More link. After it's loaded, switch back to the Live HTTP Headers window. In the bottom left, there is a "Save all" button. Save the headers you've generated as a file, and attach that here. Please. Thanks!
Confirmed working again for me, Toni, could you test too?
Hi, yes it is working. I cleared my Firefox cache, and also cleared it in IE in Windows XP. Thanks for all!
Apologies, but it's not working anymore. I attach a Live Http-headers output from my Firefox in Linux.
Stage serving redirecting well to ca
I can't reproduce with IE 8; I set [ca] as my language, get redirected to http://browserchoice.mozilla.com/lang/ca, change it back to [nl], and get redirected to http://browserchoice.mozilla.com/lang/nl. I don't dispute what the headers show, though.
I confirm that redirection is not working for me either (french locale).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Still works fine for me. Talking to Aravind about it, see if we can spot the problem. Thanks for the recorded headers Toni.
After a minor code change and a cache clear, Pascal reports this working. Thanks Aravind for the help. Toni / Pascal, if you don't mind, please continue to check this. I'm worried the cache clear was a temporary fix, as this seemed temporarily fixed last time too (e.g. comment 12, 13, & 14)
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
At this time, not working for me.
yes, reopening, no longer working for me either
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Not working for German: Redirecting to http://browserchoice.mozilla.com/de and not http://browserchoice.mozilla.com/lang/de testing other locales now.
Tested all locales that should be live. The following are not working: German de Norwegian (Bokmal) nb-NO Spanish es-ES Swedish sv-SE These are directing to http://browserchoice.mozilla.com/%locale% instead of http://browserchoice.mozilla.com/lang/%locale% Catalan ca Russian ru Frisian fy-NL Gaelic ga-IE These are directing to http://browserchoice.mozilla.com/en-GB instead of http://browserchoice.mozilla.com/lang/%locale%
You are getting to this by clicking 'Tell me more' from browserchoice.eu, aren't you? (In reply to comment #26) > Tested all locales that should be live. The following are not working: > > German de > Norwegian (Bokmal) nb-NO > Spanish es-ES > Swedish sv-SE > > These are directing to http://browserchoice.mozilla.com/%locale% instead of > http://browserchoice.mozilla.com/lang/%locale% > > > Catalan ca > Russian ru > Frisian fy-NL > Gaelic ga-IE > > These are directing to http://browserchoice.mozilla.com/en-GB instead of > http://browserchoice.mozilla.com/lang/%locale%
(In reply to comment #27) > You are getting to this by clicking 'Tell me more' from browserchoice.eu, > aren't you? yes
Depends on: 551946
Assignee: buchanae → fwenzel
Severity: critical → blocker
It took me a while but I was able to find out what was the problem here. If a user did not send any Accept-Language header, nor specify a correct /lang/xx URL, the app would fall back to en-GB, not redirect at all, and just serve a British page under whatever the requested URL was. QA: to test: - pick an accepted language (German, for example) and visit the Microsoft URL - delete all accepted languages (so that no header will be sent) - click the "more info" link - It'll take you to, browserchoice.m.c/de - that's an "invalid URL", which should redirect to lang/en-GB (because you sent no header saying what you want). It should NOT just not redirect, and serve a British page. In general, might be a good idea to include "what happens if I don't have any preferred languages" as a test for multi-lingual sites.
fox2mike pushed it live, and it works. Woot!
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
mmmm, all the people that tested were sending accept-lang headers, so I don't think it was the problem. It's working now but I'll keep watching that it still works later just in case ;)
(In reply to comment #31) > mmmm, all the people that tested were sending accept-lang headers, so I don't > think it was the problem. Pretty sure it was. It was reproducible locally and on stage. Mix that with a server-side cache, and you promptly have one misconfigured client that'll spoil it for everyone, no matter what *their* request headers are... FWIW: This problem would probably also not have occurred if we sent Vary: Accept-Language headers. > It's working now but I'll keep watching that it still > works later just in case ;) That's a good idea, thanks.
Pascal, have you heard any recent reports of this not working?
No, I haven't
(In reply to comment #34) > No, I haven't Thanks, Pascal. Since I can't verify for myself, but have heard no new reports, assuming this is good. Please reopen if that's not the case.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: