Closed Bug 409725 Opened 17 years ago Closed 16 years ago

general.useragent.locale is busted

Categories

(SeaMonkey :: Preferences, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0a1

People

(Reporter: neil, Assigned: neil)

References

Details

(Keywords: regression)

Attachments

(1 file)

This used to be a localised pref but under Toolkit it's now a regular pref.
where can one see that it's busted? It seems to work fine for me...
I thought there were more consumers, but I was mistaken.

nsInternetSearchService actually retrives the locale from
chrome://global/locale/intl.properties ... I guess that still works.

pref-locales.xul is dead anyway.

sidebarOverlay.js has bug 409780.

So that just leaves the redundant entry in navigator.properties to remove.
Assignee: prefs → neil
Status: NEW → ASSIGNED
Attachment #294662 - Flags: review?(kairo)
umm, why do we duplicate so much stuff in intl.properties and navigator.properties? IMHO, we should clean up that duplication before doing a release, it doesn't look very healthy to me...

And http://mxr.mozilla.org/mozilla/source/suite/browser/src/nsInternetSearchService.cpp#4645 should actually get the pref instead of intl.properties, which is hardcoded to en-US.

Anyways, the part of cleanup attached here look good to me by code inspection (I have no build environment where I am currently, so can't test myself).
Attachment #294662 - Flags: review?(kairo) → review+
Target Milestone: --- → seamonkey2.0alpha
No longer blocks: 409780
Depends on: 409780
(In reply to comment #2)
> sidebarOverlay.js has bug 409780.

The patch there will remove that use.

***

See
<http://mxr.mozilla.org/seamonkey/search?string=general.useragent.locale&find=%2Fsuite%2F&tree=seamonkey>
Comment on attachment 294662 [details] [diff] [review]
Proposed patch
[Checkin: Comment 6]

{{
1.101	neil%parkwaycc.co.uk	2007-12-27 13:59	 	Remove obsolete property b=409725 r=KaiRo
}}
Attachment #294662 - Attachment description: Proposed patch → Proposed patch [Checkin: Comment 6]
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
[Ah, "Mid-air collision detected!";
Neil, what about the following ?]

Last case to fix, per comment 4:
<http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/suite/browser/src/nsInternetSearchService.cpp&rev=1.260&mark=4626-4627#4617>

See
<http://mxr.mozilla.org/mozilla/search?string=general.useragent.locale&find=%5C.cpp%24&filter=%5E%5B%5E%5C0%5D*%24&tree=mozilla>
{{
/browser/components/dirprovider/nsBrowserDirectoryProvider.cpp
    * line 257 -- rv = prefs->GetCharPref("general.useragent.locale", getter_Copies(locale));

/suite/browser/src/nsInternetSearchService.cpp
    * line 4626 -- intlBundle->GetStringFromName(NS_LITERAL_STRING("general.useragent.locale").get(),

/chrome/src/nsChromeRegistry.cpp
    * line 143 -- #define SELECTED_LOCALE_PREF "general.useragent.locale"
}}
Serge, we are supposed to use that pref, it's still the place that defines what locale we are using, it's just that it's defined directly as a pref now! See http://mxr.mozilla.org/mozilla/source/suite/locales/en-US/suite-l10n.js#39
IRC:

(me)
Neil, (I asked KaiRo, who replied to ask you...)
I'm not sure I understand Kairo's comment 8.
I thought from his comment 4 that nsInternetSearchService.cpp/GetStringFromName should be updated to work like nsBrowserDirectoryProvider.cpp/GetCharPref.
Should it ? Or is it good to stay as it is ?

(Neil)
well, what GetStringFromName returns is the displayed locale, rather than the requested locale, which I guess is what GetCharPref would return

(me)
Obviously, I know too little to understand if that means whether our code/call should be kept or modified ;-/
(In reply to comment #9)

I filed bug 441816 too...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: