Open Bug 548791 Opened 15 years ago Updated 11 years ago

appearance pane does not display the currently used locale

Categories

(SeaMonkey :: Preferences, defect)

SeaMonkey 2.0 Branch
All
Linux
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: wolfiR, Unassigned)

References

Details

Let me describe my usecase and environment since it's special. I've just started to ship openSUSE packages for seamonkey including language "packs" (as we do for FF and TB). These are not complete packs but only the chrome jars including the translations and we are setting intl.locale.matchOS. That means that seamonkey always starts in the UI language of the system in every case. Now there is a difference between SM and the others: You have UI to change the language which doesn't have any effect. To improve that I backported two changes from trunk to obey general.useragent.locale from within a user profile and to override the machOS in that case. I confirmed that this is working as expected. Now there is one issue left: You are setting general.useragent.locale hard to AB_CD (en-US by default) in suite-l10n.js so I needed to change it and I'm using pref("general.useragent.locale", "chrome://global/locale/intl.properties"); now. This works through most places but it apparently fails within the appearance pane and the displayed locale is always the first item instead of the currently used one. var pref = document.getElementById(aElement.getAttribute("preference")); if (pref.value) { matchItems = aElement.getElementsByAttribute("value", pref.value); // If the pref matches an entry that actually is in the list, use it. if (matchItems.length) return pref.value; } So my guess is that the above doesn't resolve the chrome uri down to the actual value?
A "localized pref" (i.e. one that points to a locale chrome file where the actual value resides) needs to be dereferenced with a different method, which the <preference> element might not do. Could you point to the bug that did the trunk change you backported?
Hmm, I still wonder why you need to set the locale to a localized pref there, though.
The matchOS pref just makes sure that the correct locale is loaded through chrome. It doesn't modify general.useragent.locale. So two issues with that: - the useragent always shows en-US instead of the currently used locale - the pref pane has no change at all to figure out the currently used locale
The UA string is an option for sure. The UI depends on the <preference> element, so the question probably is if it understands "localized prefs" at all...
You need to log in before you can comment on or make changes to this bug.