Cannot change the language preferences in google side




17 years ago
14 years ago


(Reporter: Yuying Long, Assigned: Darin Fisher)


({intl, verifyme})

intl, verifyme

Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
Build: 10-22-18 0.9.4 branch build

Steps to reproduce:
1. Launch browser and go:
2. Click on "Preferences".
3. Choose language other than default(EN), e.g. Japanese, Chinese...ect.
4. Click on button "Save Preferences".

There is no language change confirm dialog pops-up, then return to the google
search page, and the language still in English, will you click on Preferences
again, the language in preferences page still point to English.

Expect result:
The search page will change to the language that you set in preferences page.

Seems the preferences page of google has been changed recently, it was works
fine before.  

And I checked it on IE, works fine there too.


17 years ago
Keywords: intl
QA Contact: teruko → ylong

Comment 1

17 years ago
wfm 2001102403 trunk win98
I tried with french, japanese, english and swedish

Comment 2

17 years ago
I checked some other machines with different platforms on both 10-22 branch
build and trunk build, got the same result.

I can not do the non-english search in site, I have to go to google
directory web and choose the language pages, then do search though there.

Comment 3

17 years ago
Assignee: yokoyama → jbetak
accepting - Yuying I remember attending one of Google's i18n presentations, at 
the first blush I'd like to point out that they also read the accept language 
header a client sends out. It could be that that's what's interfering here.

I can't see this with a 10/31/2001 trunk build. Saving language preferences 
seems to work (I see the alert confirming the change) and subsequent searches 
are restricted to the languages I picked. In addition to that, when changing 
the "accept language" preference (Prefs->Languages), Google's interface 
language changes also. I'm tentatively closing with a "WORKSFORME".
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 6

16 years ago
Yes, it works today on same builds which had problems before.  I guess it's
cause by the google's site changing.

Mark it as verified for now.

Comment 7

16 years ago
I saw it today again (on 12-13 trunk build).  IE doesn't has same problem.

Don't know why we can not change the language preferences some times.  
Resolution: WORKSFORME → ---

Comment 8

16 years ago
jbetak is not here any more.  Reassign to Ray for now.
Assignee: jbetak → yokoyama

Comment 9

16 years ago
workforme on the trunk. mark it workforme
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 10

16 years ago
OK, I finally found it cause by the cookie is diabled when I tried to change the
language preferences - see a followed screen shot later.

And I checked the setting in preferences, it sets to "enable all cookie".
Even I created a new profile, still see the problem.

It's not an i18n issue but a cookie problem, re-open and change the component to
Component: Internationalization → Cookies
Resolution: WORKSFORME → ---

Comment 11

16 years ago
Created attachment 64318 [details]
screen shot for the error message 

when tried to change language prfererences in google site

Comment 12

16 years ago
Reassign to
Assignee: yokoyama → morse

Comment 13

16 years ago
Check to make sure you have not told the cookie manager to block cookies from 
this site.  You can tell this from the cookie-manager dialog.

Can you demonstrate this starting with a fresh profile?

Comment 14

16 years ago
Also, are you sure it is not an evanglism issue.  You can determine that by 
putting the following line in your prefs.js file, thereby spoofing the site into 
thinking you are running a 4.x browser.  (Have you confirmed that it works 
correctly on 4.x?)

      user_pref("general.useragent.override", "Mozilla/4.75 [en] (Win95; U)");

Comment 15

16 years ago
> Check to make sure you have not told the cookie manager to block 
> cookies from this site.  You can tell this from the cookie-manager 
> dialog.

No, I didn't block this site.  And I even tried to switch between block and
unblock a few times, still didn't make any difference.

> Can you demonstrate this starting with a fresh profile?
Yes. I tried new profiles.

My N4.7 doesn't work correctly also, and I checked the cookie is marked "accept
all cookies" in preferences.
And I add the line in my prefs.js file:
user_pref("general.useragent.override", "Mozilla/4.75 [en] (Win95; U)");
still didn't change.

In fact, on my MacOS X machine, there is no N4.7 there, and I still has this

Maybe it's a an evanglism issue cause I remember it worked fine before.

Comment 16

16 years ago
OK, if this doesn't work correctly in 4.7 either, then it is definitely an 
evangelism issue and not a cookie issue.  They must be doing something that only 
IE can recognize.  Therefore the site will need to be fixed.

Reassigning to evangelism.
Component: Cookies → US General
Product: Browser → Tech Evangelism
Version: other → unspecified

Comment 17

16 years ago
Really reassigning to evangelism this time.
Assignee: morse → doronr
QA Contact: ylong → zach

Comment 18

16 years ago
I really think this IS a bug in our cookie code. I have NO problem with that
sites on my Windows. And ylong's window have no problem once she use a new
profile . But her old profile on window have problem and also fresh profile have
problem on MacOS.

Comment 19

16 years ago
> And ylong's window have no problem once she use a new profile
I do have problem even I used a new profile on my windows machine.  (I don't
remember what kind of change you made in my machine yesterday to made it worked,
and today it won't work on same machine)

Comment 20

16 years ago
and we are sure the issue is related to cookie because the google page said the
browser disable the browser in that page. ylong, can you include a screen shot ?

Comment 21

16 years ago
change back to browser cookie
Component: US General → Cookies
Product: Tech Evangelism → Browser
Version: unspecified → other

Comment 22

16 years ago
I have the screen shot in comment #11.

Yes, I think we should do something with our cookie - cause Frank doesn't has
this problem on his window machine with same site.

Comment 23

16 years ago
Well this is working fine for me.  And from the comments in this report, it is 
working fine for others as well.  Is this a problem unique to Yuying's machine?  
Is there any other machine beside the mac that you mentioned that has the same 
problem?  Is it 100% reproducible on Yuying's machine?

Just because you are getting the cookie error message does not necessarily mean 
that this is a cookie problem.  I have debugged many problems where the site 
reported that cookies were not working, only to localize the problem to being in 
some other module entirely.

Comment 24

16 years ago
I'd say it's 100% reproduce for me - WinXP and Win2000, Mac OS X, linux RH7.1.

Comment 25

16 years ago
And I see this on another person's Mac OS X also.

Comment 26

16 years ago
If it's 100% reproducible, can you run this under a sniffer and collect the 
traffic.  I'd like to see the cookie headers in the request and in the response.

Comment 27

16 years ago
Sorry, but could you let me know how can run this?

Comment 28

16 years ago
Created attachment 64888 [details]
Data in view window

2 steps with running this process:
1. Load the google site.
2. Change the language preferences to Japanese.

Comment 29

16 years ago
OK, I think I know what's happening.  Below is an abstract of the traffic that I 
see on my machine, and the traffic that Yuying has posted to this report.

My Traffic:

   GET / HTTP/1.1

   HTTP/1.1 200 OK
   Set-Cookie: PREF=ID=...

   GET /images/logo.gif
   Cookie: PREF=ID=...

Yuying's Traffic:

   GET / HTTP/1.1
   Host: google

   HTTP/1.1 200 OK
   Set-Cookie: PREF=ID=...

   GET /images/hp0.gif HTTP/1.1
   Host: google

Note that in Yuying's case the cookie is not sent back to the host on the second 
get.  That's already an error.  So now to determine why.  Note that one other 
difference between Yuying's traffic and mine is that in her case the host is 
"google" whereas in my case it is "".  Aha!  That suggests that she 
was typing "google" on the URL line whereas I was typing "".  So I 
tried it with just "google" and I got the same results that she reported -- site 
gave me a message saying "Your cookies seem to be disabled".

So here's what's happening.  Site is setting a domain cookie for the 
domain.  This is true in both cases.  But in the case that you visit "google", 
the domain-test fails and the cookie module does not send back the cookies.

So I needed to investigate a little further to determine whether this is a bug 
in mozilla or a bug on the site.  Therefore I decided to try it under nav4 and 
also under IE.  In both of those cases I got the identical error message when I 
visited just "google".  Visiting "", and also "" work 
just fine.

So I still think this should be assigned to the evangelism.  Site is broken and 
does not work with any browser.  But if Frank insists on keeping it in the 
cookies component, I won't object.

Comment 30

16 years ago
*** Bug 124746 has been marked as a duplicate of this bug. ***


16 years ago
Summary: Can not change the language preferences in google side → Cannot change the language preferences in google side
dwitte, mvl, is this an evang bug or not?  If its not, since ftang is gone,
should we keep it here or dump it off to evang and off our radar?
Assignee: doronr → darin
QA Contact: zach → cookieqa
From comment 28 and 29, it looks like Yuying Long visits the host "google", and
some proxy or dns adds the .com. Obviously, the cookie want get accepted,
because it is for, not google.
Yuying Long: can you try if visiting "" works? Do you use a proxy server?
This all sound like invalid to me.
(All this assumes this is still a problem ofcourse...)

Comment 33

14 years ago
I think this bug is fixed with the latest google website

Comment 34

14 years ago
They did this on the netscape campus as well, and it made testing for certain
bug reports vs "google" incredibly annoying.

DNS administrators should not be aliasing hostnames in their intranet domains to
public domains, no matter how popular they are.

Another lesson here is the power of the cookie log trace, which should have been
done immediately after mucking with prefs and profiles failed.
Last Resolved: 16 years ago14 years ago
Component: Networking: Cookies → DOM
Keywords: verifyme
QA Contact: core.networking.cookies → benc
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.