Closed Bug 3834 Opened 26 years ago Closed 26 years ago

Locale- nsICollation to add interfaces using nsString

Categories

(MailNews Core :: Internationalization, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: nhottanscp, Assigned: nhottanscp)

Details

By using nsString instead of byte stream/length pair, we can reduce XPCOM overhead.
Target Milestone: M4
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Summary: nsICollation to add interfaces using nsString → Locale- nsICollation to add interfaces using nsString
Change checked in on 3/19/99. At this point, my test cases are limited to very simple us-ascii strings. There is a test code checked in. So I would like someone in IQA to do unit tests. Currently, there are platform specific limitation. Win32 - #3867 nsLocale problem Mac,Unix - #3903,3904 only en_US is supported Work around for these problem is to pass NULL for nsILocale to force use a default (en_US) until #3867 is resolved.
The code has been checked in. IQA will do tests us-ascii data for Win32.
On US-Windows 95 using Naoki's LocaleSelfTest.exe, I got results found here: http://rocknroll/users/momoi/publish/sort/win95res/ These results are not correct with an initial character like "Z" coming right after "I". There are many other problems with these results suggesting that ascii-collation on US-Windows 95 is broken.
Looks like that unicode version of the API is not fully working under Win95. I need to use a converter and non unicode API for Win95. Fortunately, the code has been written for Mac and Unix so I can reuse it and check in by the week end.
I checked in the fix for Win95,98. It should work for us-ascii data except requires to pass NULL as for a locale until the bug #3867 fix.
Target Milestone: M4 → M5
IQA has found platform dependent behavior for case less comparison. I will investigate the problem but it is not critical for M4 (only significant for Naoki vs naoki). Setting to M5.
I checked in a fix for the case less comparison problem.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
For M4, please test us-ascii data in Win32 (NT4, 95, 98). Create a new bug for any sort order issue. Marking bug as resolved fixed.
Target Milestone: M5 → M4
Bookkeeping: Moved from M5 to M4 since its already fixed.
Status: RESOLVED → VERIFIED
** Checked with 4/8/99 evening build for Win32 on US Win NT4/98/95 ** To test this, we (marina & momoi) used: 1. the source for the latest LocaleSelfTest.exe for Win32 is at: http://lxr.mozilla.org/mozilla/source/intl/locale/tests 2. data files to sort are found here: http://lxr.mozilla.org/mozilla/source/intl/locale/tests/sort/us-ascii_base.txt http://lxr.mozilla.org/mozilla/intl/locale/tests/sort/us-ascii_sort.txt Files: us-ascii_base.txt (contains the entire ASCII characters) us-ascii_sort.txt (contains various key strings for tests) As of 4/9/99, there is one error in the us-ascii_base.txt. The corrected file and the corresponding results will be checked in later today. Results: The 4 result files are found here: http://lxr.mozilla.org/mozilla/intl/locale/tests/sort/ These results by marina and momoi agree that in all 3 Win OS's, there is consistency in the results. In earlier version of LocaleSelfTest.exe, we saw the sorted order even when the sort option was set to "case insensitive", but this defect is now gone with the latest version (make files modified last on 4/7/99) of LocaleSelftest.exe. In the sorted order, lowercase letters preceded uppercase ones in all the results and this is expected behavior. Marking the fix verified.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.