User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050712 Camino/0.9a1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b3) Gecko/20050712 Camino/0.9a1+
only loads the gmail page in an asian language and i am unable to reload it in
Steps to Reproduce:
1.go to gmail login page
3.repeat un til you go insane
gmail is in an asian lang.
opened the english version of the page
What happened was Gmail changed what they were looking for in their prefs.
They're now looking for "en-US" instead of just "en". You can fix this now by
setting your dialect in prefs.js.
Some people will see this in Japanese, French, Chinese, whatever your second
language is in the intl.accept_languages preference of your prefs.js file.
Back -> pinkerton
More on this: See bug 161337, bug 281107, and bug 280814.
bug 161337 shows the initial checkin to "auto discover" this from system prefs.
But bug 280814 shows the reason we no longer discover the locale/dialect.
I think backing out part of bug 280814 (the part that removes the auto-discover
locale) would fix this. No?
Bruce, is there another way we can do this? Maybe pull the locales and only use
them if it has not been specified. Sites that are looking for it, bypass the
first specified language and use the second one instead.
Seems to me if the user just sets en-US, en, etc., in the System Prefs that
there wouldn't be a problem. My accept string does include the dialect info,
and I didn't add it manually.
(In reply to comment #4)
> Seems to me if the user just sets en-US, en, etc., in the System Prefs that
> there wouldn't be a problem. My accept string does include the dialect info,
> and I didn't add it manually.
Hmm... I'll check this, but if so, I suppose we should make a special case:
If a user specifies English but does not specify a locale, we specify the locale
Yep that's exactly the case. So, we need to say "set your locale if you want,
otherwise (if it's en) it's en-US."
Would that work?
I don't understand exactly what it is that google is doing. Reporter, please can
you paste the accept-language header that Camino is sending to google that is
causing the problem. (Pages such as http://gemal.dk/browserspy/accept.php) will
tell you this information.)
Auto-detecting the locale was definitely the wrong idea, and I think we were
right to remove it. MacOS X's language selection includes dialect for some
language (e.g. mine has "British English" before "English", with "Australian
English" and "US English" both turned off). I can see other languages (e.g.
Portugese) with dialects present too.
I very much doubt that google are only looking for "en-us"; was the problem that
you didn't have "en" as a fall back? Samuel, can you post more details about any
testing you have done.
The problem is that gmail is apparently understanding only en-US and not en
alone. The localization defaults in Mac OS X include only en. Unless the user
has modified the list to add a dialect (and this is a big "unless" for English
speakers), it won't include en-us.
It's Google's problem, but I've seen it on other sites in the past as well. I
don't think it's unreasonable to transform en to en-US,en if English is present
in the list but no en dialects are.
I'm not sure you're right that Google only accepts "en-us"...
If I remove en-gb from my language list, clear all my google cookies and log
into GMail with an accept-languages starting "en, fr, de, ..." I get a perfectly
sensible English interface and it sends me a www.google.com/Accounts cookie for
the language indicating "en".
It will be easier to debug if people could:
1. clear all mail.google.com, www.google.com (and possibly .google.com) cookies
before visiting GMail
2. Post their accept-language headers with the report
3. State what language they expected GMail to appear in (presumably the first in
the list above!) and what language they actually got it in.
if i clear my google cookies (i had a "ja" cookie in there), then it all works
fine. I wonder if something else on their site mis-set the cookie and then gmail
just picked up on it.
Clearing cookies for me did not work last night. What seems to have happened is
Google looked for en-US (or any other dialect) and if it didn't see it, moved to
the second language in the list (which happened to be japanese for me).
I'm unable to test this now (I'm at work), but I'll try when I get home. Gmail
may have fixed the problem. If that's the case, users just need to clear their
cookies. I *hope* this is the case.
If not, I really don't see a problem with defining the dialect if it's not
already chosen. Gmail still works with en-GB/en-AU and I'm sure other sites
would act the same.
OK, I just created a fresh profile and tested. First I set my languages to
English, French, Arabic (en fr;q=0.7 ar;q=0.3 from gemal.dk), then opened
Camino, went to Gmail, and logged in. The whole process was in English, no
French involved. Camino 2005071408 (v0.9a2), 10.3.9.
I was gonna say, I think that *Gmail* should really be checking for general 'en'
also, and not just 'en_US'. I'm 99.99% sure that this is/was a mistake on their end.
(In reply to comment #13)
> I was gonna say, I think that *Gmail* should really be checking for general 'en'
> also, and not just 'en_US'. I'm 99.99% sure that this is/was a mistake on
Oh, that's already been said. Remind me to not respond to bugmail when I'm not
i emptied my cookies and now the site loads in english.
Gmail has fixed the problem. Unless there are other sites presenting this
problem, there's no reason for us to change our current approach.
(In reply to comment #16)
> Gmail has fixed the problem. Unless there are other sites presenting this
> problem, there's no reason for us to change our current approach.
> Resolving... WORKSFORME.
Reopening. See dependencies for some other sites presenting the problem, and see especially bug 327517 comment 8: "This behavior is a part of how ASP and IIS will handle locales, i.e., it's a Windows Server behavior..."
Per smontagu's last comment, I think we're probably going to have to change to sending en-US when "English" is the top language and no other English dialects are listed, or something like that (i.e., comment 5/6/8).
I'm hoping than British, Australian, etc., English speakers actually change their language list appropriately and that we are really only special-casing lazy Americans anyway ;)
Tweaking summary to reflect what's actually going to happen, but let it be known that I believe this bug is entirely Tech Evangelism, and not something that Camino should be trying to work around. Note that all the dependencies are TE bugs.
Created attachment 246245 [details] [diff] [review]
Converts any lonely 'en' to an 'en-US, en' pair.
Comment on attachment 246245 [details] [diff] [review]
(Since I haven't given review before, treating my review as a second-r.)
r=me on the code, but I haven't run it through a functional test.
Comment on attachment 246245 [details] [diff] [review]
Looks good to me. Are we going to have to worry about other language packs other than en-US in the future?
Checked in on trunk and MOZILLA_1_8_BRANCH.