Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Locale- nsICollation to add interfaces using nsString

VERIFIED FIXED in M4

Status

MailNews Core
Internationalization
P3
normal
VERIFIED FIXED
19 years ago
9 years ago

People

(Reporter: nhottanscp, Assigned: nhottanscp)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

19 years ago
By using nsString instead of byte stream/length pair, we can reduce XPCOM
overhead.
(Assignee)

Updated

19 years ago
Target Milestone: M4
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
OS: Windows NT → All
Hardware: PC → All

Updated

19 years ago
Summary: nsICollation to add interfaces using nsString → Locale- nsICollation to add interfaces using nsString
(Assignee)

Comment 1

19 years ago
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.
(Assignee)

Comment 2

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

Comment 3

19 years ago
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.
(Assignee)

Comment 4

19 years ago
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.
(Assignee)

Comment 5

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M4 → M5
(Assignee)

Comment 6

19 years ago
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.
(Assignee)

Comment 7

19 years ago
I checked in a fix for the case less comparison problem.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

19 years ago
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.

Updated

19 years ago
Target Milestone: M5 → M4

Comment 9

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

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 10

19 years ago
** 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.