3834 - Locale- nsICollation to add interfaces using nsString

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[nhottanscp]

By using nsString instead of byte stream/length pair, we can reduce XPCOM
overhead.

Comment 1

[nhottanscp]

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.

Comment 2

[nhottanscp]

The code has been checked in.
IQA will do tests us-ascii data for Win32.

Comment 3

[Katsuhiko Momoi]

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.

Comment 4

[nhottanscp]

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.

Comment 5

[nhottanscp]

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.

Comment 6

[nhottanscp]

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.

Comment 7

[nhottanscp]

I checked in a fix for the case less comparison problem.

Comment 8

[nhottanscp]

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.

Comment 9

[bobj]

Bookkeeping: Moved from M5 to M4 since its already fixed.

Comment 10

[Katsuhiko Momoi]

** 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.