580833 - Language preference synced as chrome URL

Status: RESOLVED DUPLICATE of bug 654099

(Firefox :: Sync, defect)

Description

[jul.cornu]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.6) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.6) 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.

Comment 1

[Sterling Stein]

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.

Comment 2

[Benedikt Pfeifer]

I've seen this as well on Ubuntu 9.10, Firefox 3.6.8.
Happened suddenly.

Fix in comment 0 helped.

Comment 3

[Paul Biggar]

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.

Comment 4

[Matthew Minuti]

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.

Comment 5

[Janet Swisher]

(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.

Comment 6

[Martin]

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.

Comment 7

[Hans Nieser]

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.

Comment 8

[[Baboo]]

I can reproduce this also with latest Fx4 nightly.

Comment 9

[Craig Cornelius]

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.

Comment 10

[Oliver Ewert]

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.

Comment 11

[Damien]

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 !

Comment 12

[Oliver Ewert]

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

Comment 13

[.salo]

I've seen this bug on Ubuntu 10.10 and Firefox 6.0

Comment 14

[Andrew Halberstadt [:ahal]]

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).

Comment 15

[Andrew Halberstadt [:ahal]]

Moving to sync component as per comment 4, 5 and 6.

Comment 17

[Gregory Szorc [:gps]]

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.

Comment 18

[hotmailwiki]

The information above is very good to me, thanks for sharing!
http://hotmailwiki.com/hotmail-login