Closed Bug 4732 Opened 25 years ago Closed 25 years ago

GetApplicationLocale always return en-US

Categories

(MailNews Core :: Internationalization, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: nhottanscp, Assigned: tague)

Details

"en-US" is hard coded in GetApplicationLocale (and GetSystemLocale).
GetApplicationLocale is used by the mail thread pane sorting.
M5 plan includes international sorting.
Target Milestone: M5
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed. checked in code by 4/27/99.
It is my understanding that intl sort did not make it in M5. Naoki, please add a note here when this
becomes usable.
The unit test for collation and date format uses this unless the locale is
explicitly specified. So it can be tested implicitly by that.
Tague's unit test may have a way to test it.
Tague, unless theres is a test program for this,
I'm inclined to look at just the results of Naoki's
LocaleSelftest for collation and date on a few different
language platforms. If the results there are not amiss,
I'm inclined to mark this fix verified. If you have
other thoughts, please let me know.
you can use intl/locale/tests/nsLocaleTest on windows and unix.
Status: RESOLVED → VERIFIED
Collation for mail headers is working now.
Based on the results for Latin1 and Japanese
sorting in the thread pane headers, I'm inclined to
mark this verified fixed now. The testing has not been
extensive and requires further refinement later.
For now, I'm marking it verified fixed.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.