280814 - Automated determination of accept-language header has some problems

Status: RESOLVED FIXED

(Camino Graveyard :: Preferences, defect)

Description

[Bruce Davidson]

Following the landing of bug 161337 a couple of minor problems with our
automated determination of languages to send to accept-language have been uncovered.

Because we set the gecko pref we override anything the user may have specified
in user.js. For languages for which there is no MacOS X localisation (e.g.
Hebrew) the user cannot put Hebrew at the top of the list because some bits
(e.g. OS X, Software Update...) break. To fix this we need to provide an
override option.

Using the region to determine the primary language is messing up users who are
in one country but prefer to run their systems using a different language. This
is easily fixed by removing the use of locale to determine primary language, and
brings us closer to the Safari method. It will however mean that for some
languages we are unable to send dialect info (because Mac OS X doesn't provide
separate options).

Comment 1

[Bruce Davidson]

Attachment: Proposed patch

This patch addresses both problems:
1. We no longer examine the regional settings from system preferences, we use
just the language list.
2. If the user specifies the option camino.accept_languages in user.js then the
string in this option is used for the accept language header, and the system
settings are ignored. (Note if you want to go back to using the system settings
you will have to delete this option from both user.js and prefs.js.)

Comment 2

[Asaf Romano (gone)]

Comment on attachment 173205 [details] [diff] [review]
Proposed patch

Works fine for me.

>+    if (    userProvidedLangOverride == YES
>+         && [userLanguageOverride length] > 0 )

Please change it to:

>+    if ( userProvidedLangOverride && [userLanguageOverride length] > 0 )

otherwise, r=[e-mail]

Comment 3

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 173205 [details] [diff] [review]
Proposed patch

sr=pink. if mano's happy, i think we're good ;)

Comment 4

[Mike Pinkerton (not reading bugmail)]

Attachment: actual path checked in, for branch posterity

i changed some spacing and made the if correction suggested in review. this is
what actually landed on the trunk and branch.

Comment 5

[Mike Pinkerton (not reading bugmail)]

landed on trunk and branch