96859 - The order of JA character set name in Editor Save As Charset dialog is not correct

Status: VERIFIED DUPLICATE of bug 96856

(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)]

dbaron: 

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

Comment 2

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

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

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!

correcting summary, marking fixed. Teruko - I'll close the corresponding
Bugscape bug Monday morning. BTW for some reason both Bugzilla bug have the same
description - the one from "Customize Charset".

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)]

missed this train...

Comment 11

[Frank Tang]

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

Comment 12

[Frank Tang]

m0.9.7

Comment 13

[Frank Tang]

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

Comment 14

[Frank Tang]

ui issue, give to rchen.
rchen- try to reproduce it first. It may got fixed on the trunk already. If so,
mark it fixed.

Comment 15

[rchen]

The same issue in bug 96856.

*** This bug has been marked as a duplicate of 96856 ***

Comment 16

[Teruko Kobayashi]

Verified as dup.