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).
Created attachment 173205 [details] [diff] [review] 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.)
Status: NEW → ASSIGNED
Target Milestone: --- → Camino0.9
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, firstname.lastname@example.org
Attachment #173205 - Flags: review+
Comment on attachment 173205 [details] [diff] [review] Proposed patch sr=pink. if mano's happy, i think we're good ;)
Attachment #173205 - Flags: superreview?(pinkerton) → superreview+
Created attachment 173256 [details] [diff] [review] 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.
Attachment #173205 - Attachment is obsolete: true
landed on trunk and branch
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.