User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:220.127.116.11) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:18.104.22.168) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6 Out of the blue, google started to display its main page in a language I quite wasn't able to read nor identify at the moment, while before it was in french. A picture is better than a thousand words: http://www.kanka.ch/pub/google1.jpg http://www.kanka.ch/pub/google2.jpg After some investigation (and some help from the Ubuntu forum), the problem was that the language in Preferences->Content->Language was set to [chrome://global/locale/intl.properties] which apparently google interpreted as the Cherokee (!) language, whose code is chr (i.e. "chrome" truncated). See the address bar in the second picture for confirmation. When I changed the language to [fr-ch] (Swiss french), the problem was solved. I suspect all started after an update, but I can't be sure about it as I didn't pay attention. Reproducible: Couldn't Reproduce Steps to Reproduce: The problem is, I can't directly enter [chrome://global/locale/intl.properties] as a language in Preferences->Content->Language, as I have to choose from a list. Actual Results: Google displayed in Cherokee language. Expected Results: Google displayed in french (or english, well a more broadly understood language) Probably started to happen after an update.
I just got bit by this. I wonder if it is related to: https://bugzilla.mozilla.org/show_bug.cgi?id=56889 I had just upgraded from SeaMonkey 1.7 to SeaMonkey 2.0.6. The settings migration left my Accept-Language and Accept-Charset headers as "chrome://..." as described above, which also lead to me getting Google in Cherokee. Also, it looks like this bug is only on Linux. It seems to be mostly Firefox 3.6 and SeaMonkey 2.0. I suspect this is due to the settings migration not working properly.
I've seen this as well on Ubuntu 9.10, Firefox 3.6.8. Happened suddenly. Fix in comment 0 helped.
I also see this, and another kind soul helped me diagnose it (with the same answer, see: http://webapps.stackexchange.com/questions/5042/google-what-language-is-chr-and-why-is-my-homepage-set-there/7203#7203 for the diagnosis). The poster believes it's the fault of Firefox sync.
I can confirm this bug being triggered by Firefox Sync. On a brand-new install of Ubunutu 10.10, using US English as the system language, google was working fine until the second sync. I imagine the first sync sent language data and the second sync tried to copy that data down. I worked around the bug by explicitly setting the language in Firefox to "en-us". This workaround has held through multiple sync events, so I think it would be worth checking to see if sync is accidentally truncating stored language settings.
(In reply to comment #4) Ditto to Matthew's experience: Fx 3.6.12 on newish Ubuntu 10.04 with Sync. Language now set to '[chrome://global/locale/intl.properties]'. I'm happy to send any data you might want from this machine. I'll use the URL workaround for now, to leave the settings as they are.
Same here on Kubuntu 10.10, bug appeared after setting up firefox sync. Changing the language preferences back to de-AT fixed it for me. BTW, Google being displayed in the Cherokee language, definitely one for the books. Hilarious.
Bug still present with FF 3.6.13, FF Sync 1.6.2, running Gentoo. Same thing with language preferences being set to a chrome:// URL.
I can reproduce this also with latest Fx4 nightly.
Google Web Search uses hl= to indicate the user interface language. They have added support for the Cherokee language (chr) recently, and use the AcceptLanguage value if present - parsing the first 3 characters gives the UI in that language.
Same as this bug on the ubuntu bug tracking: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/643899 My workaround: In firefox 4, go to about:config type 'intl.accept_languages' into the filter double click (or rightclick->modify) the intl.accept_languages entry press ok and it will automatically convert chrome://global/locale/intl.properties into the actual language properties If it does not convert automatically you will need to change it manually to your language e.g. en-us, en I am thinking this is a problem with chrome putting a link to one of it's config files instead of just putting the values in.
It's also affect me ... I have Change Languages Préférences to fix this: Edit > Preferences > Content > In "Language" section click to Choose. Delete "chrome://..." and replace by your language !
I can't seem to add a link to the see also links so someone who knows what they are doing can do that but; https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/643899 reports Status: Fix Committed
I've seen this bug on Ubuntu 10.10 and Firefox 6.0
This is still happening in the latest nightly (11.0a1, 2011-12-09), both in Linux and Windows (though Windows may just be the result of syncing).
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 3.6 Branch → Trunk
Moving to sync component as per comment 4, 5 and 6.
Component: Preferences → Firefox Sync: UI
Product: Firefox → Mozilla Services
QA Contact: preferences → sync-ui
Version: Trunk → unspecified
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Component: Firefox Sync: UI → Firefox Sync: Backend
QA Contact: sync-ui → sync-backend
Resolution: --- → DUPLICATE
Summary: Cherokee language code transmitted to google → Language preference synced as chrome URL
Duplicate of bug: 654099
For those not wanting to follow the bug dupe chain, you can prevent Sync from modifying any preference by setting the pref: services.sync.prefs.sync.<pref> to false For this bug, you would open about:config and set services.sync.prefs.sync.intl.accept_languages to false. By default it is true, which means to sync the "intl.accept_languages" pref across devices. This is a workaround until the root cause of the corrupted intl.accept_languages preference is addressed.
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.