96856 - The order of Katakana Accent characters in Character Coding names is not correct

Status: RESOLVED INVALID

(Core :: Internationalization, defect, P3)

Description

[Teruko Kobayashi]

This is copy of http://bugscape.netscape.com/show_bug.cgi?id=8242

The order of Japanese character set name in Customize Character Coding dialog 
is not system locale order.

Steps of reproduce
1. Select menu View | Character coding->Customize to open Customize Character
coding dialog
2. Look at the Japanese Character set name in Available character set list

The order is not system locale (Shift_JIS since I am using Japanese window).
The order should be same as Default Character coding section and Mail Language
section.

Tested 7-27 Win32 JA build.  

In US build, the name is in English.  The order is Ascii order.



------- Additional Comments From [e-mail] 2001-08-02 16:26 -------

Created an attachment (id=2481)
patch replacing calls to the charset manager by queries to the corresponding 
charset menu RDF source



------- Additional Comments From [e-mail] 2001-08-02 16:30 -------

this should work, since the charset menu performs its own locale-aware 
collation. The RDF source used in the patch serves as a template for 
the "Default Character Coding" drop-down menus in both the "Languages" 
and "Mail Language" preference panes.

BTW I realize that this is in Bugscape, since it was found in a commercial 
Japanese build, but we should move it to Bugzilla, since it affects all 
locales.



------- Additional Comments From [e-mail] 2001-08-02 16:47 -------

Created an attachment (id=2482)
cleaned-up patch, removed references to the charset manager, this shows 30-50% 
performance gain compared to 6.1 RTM



------- Additional Comments From [e-mail] 2001-08-09 16:25 -------

r=tao. Please open a new bug against JS engine's builtin function sort(), thx!



------- Additional Comments From Joaquin Blas 2001-08-21 13:07 -------

Comments on the 08/02/01 16:47 patch:

  * readRDFString should return a value in all cases. Right now it only returns
    something if n is non-null.

  * LoadAvailableCharsets() isn't doing a lot of error checking. Is there
    any possibility that some of the setup code in that function can fail?

  * I don't think we're allocating enough space in the following diff. We're
    allocating an array of 1 element, yet we're indexing into it as if there
    were 2 elements:

+    availCharsetDict[i] = new Array(1);
+    availCharsetDict[i][0] = readRDFString(rdfDataSource, charset, kNC_name);
+    availCharsetDict[i][1] = charset.Value;


  * Are we sure that the RDF data source and the manager (ccm) can never be
    out of sync? Or should we stick with the old way, and just roll our own
    array sorter?



------- Additional Comments From [e-mail] 2001-08-21 17:09 -------

Created an attachment (id=2756)
updated patch - improved error handling, groomed indentation a little, fixed 
array allocation size



------- Additional Comments From [e-mail] 2001-08-23 13:23 -------

kin says sr=kin

dbaron: this is a little stange situation, it's filed as a Bugscape bug, since 
we noticed it in a Japanese Netscape build, however the changes go into the 
Mozilla tree. Since you are on campus - can you read this bug? Could you 
approve the checkin?



------- Additional Comments From David Baron 2001-08-23 16:28 -------

Changes in Mozilla should have an associated Bugzilla bug.  As far as Mozilla 
is
concerned, it's no more useful to cite a bugscape bug than it is to site an IBM
PR# (and both have been done, although neither should be).



------- Additional Comments From [e-mail] 2001-08-23 16:44 -------

I agree on principle, although the QA argued in this case that the bug could 
not be reproduced in Mozilla, because we don't have a current Japanese language 
pack and although I mentioned it, I didn't insist on moving this to Bugzilla.

dbaron, what do you want us to do? We can open a Bugzilla bug to document the 
change, if that technicality would allow this into the tree. Please also note 
that the verification will most likely happen in a Japanese commercial Netscape 
build in as soon as we have one.

Comment 1

[[e-mail] (away - not reading bugmail)]

Attachment: most recent patch with r=tao, sr=kin

Comment 2

[[e-mail] (away - not reading bugmail)]

dbaron: 

this is the Bugzilla version of the Bugscape bug I was pestering you about. 
Could you have a look and possibly a=?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

a=dbaron (on behalf of drivers)

Comment 4

[[e-mail] (away - not reading bugmail)]

thanks dbaron!

marking fixed - Teruko the corresponding Bugscape bug will be resolved soon...

Comment 5

[Teruko Kobayashi]

I tested this in 09-07-03-0.9.4 pseudo Ja build. The order of Ja character set 
name is not correct.

For example, Katakana characters for character set is not correct.
1.ギリシャ語
2.キリル文字

In shift jis code, ギ(834d) and キ(834c) is displayed the opposit order.

Comment 6

[[e-mail] (away - not reading bugmail)]

Teruko,

the order of the elements should be identical to "Default Encoding" (Language 
pref window) dropdown menu. Is the order there correct?

Comment 7

[Teruko Kobayashi]

No. The default encoding list has same problem.

Comment 8

[Teruko Kobayashi]

I checked this in 6.1 JA rtm build.  This order is the same as default encoding 
list.  The order of JA character set in Customize Character coding and Save as 
charset did not have this problem.  

Comment 9

[Asa Dotzler [:asa]]

0.9.4 is out the door.

Comment 10

[[e-mail] (away - not reading bugmail)]

Teruko,

all of these lists are now sharing Cata's RDF template. The template is 
supposed to be locale-aware and sorts all elements accordingly. However, it 
seems that it has some issues.

Could we file a bug on "Default Encoding" sort order? I could fix that one and 
the remaining bugs could be then closed.

Comment 11

[Teruko Kobayashi]

Jurai, I logged new bug 100417 for Defalt character coding problem.

Comment 12

[[e-mail] (away - not reading bugmail)]

missed this train

Comment 13

[Frank Tang]

please reassign to ftang AFTER you check in the fix of 64146.

Comment 14

[Frank Tang]

m0.9.7

Comment 15

[Frank Tang]

jbetak's contract is up. Bulk move bugs to ftang

Comment 16

[Frank Tang]

rchen- ui issue, please try. work with nhotta.

Comment 17

[Jaime Rodriguez, Jr.]

if this his landed on the trunk, should we resolve this as fixed?

Comment 18

[rchen]

The problem remains only for Katakana Accent characters.  It seems Windows API 
LCMapStringW can't take care of them properly. RawSortKey generated from 
LCMapStringW pushes the accent to the low bits, which causes the accent ignored 
when compares the RawSortKey. 

According to Naoki, the impact to the Japanese users minor.  Change the title to 
reflect the fact.  

Comment 19

[rchen]

*** Bug 96859 has been marked as a duplicate of this bug. ***

Comment 20

[rchen]

*** Bug 100417 has been marked as a duplicate of this bug. ***

Comment 21

[Teruko Kobayashi]

Changed QA contact to [e-mail].