39793 - Message compose charset customize dialog shows initial active charsets number is not correct

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P2)

Description

[nhottanscp]

The customize dialog is suppose to show the active charset list same as the 
original compose message charset menu items (if not edited already before).
But is only shows three items (ARMSCII-8, Windows-1251 and ISO-8859-1).

Comment 1

[nhottanscp]

Attachment: screen shot of the dialog

Comment 2

[nhottanscp]

I think we also need a capability of revert the changes and back to the original 
set.

Comment 3

[Katsuhiko Momoi]

If you add additional item to the list of 3, then when
you re-boot, there is no longer the default menu list but
only the 3 items plus what you added in the last session.
This forces the user to re-make the list on their own. Very bad
user experience and makes the Character coding menu on the
Composer much less usable for testing also.
Nominating for nsbate2.

Comment 4

[Peter Trudelle]

[nsbeta2+] will take fix until [6/22]

Comment 5

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

fix should be in the builds starting on 06/06/2000

Comment 6

[Katsuhiko Momoi]

** Checked with 6/28/2000 Win32 build **

I thought this was working before the above build, but
with the above build, I still see the same problem
of only 3 charset names on the active list.
Re-opening

Comment 7

[nhottanscp]

Adding ftang to cc, we need to reassign this.

Comment 8

[Frank Tang]

reassign to ftang clean the status whiteboard

Comment 9

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Adding "nsbeta3" keyword. Not critical to beta2. 

Comment 10

[Frank Tang]

mark as assign

Comment 11

[Frank Tang]

nsbeta3- per i18n bug meeting. 

Comment 12

[Katsuhiko Momoi]

Hi, people, we had an easy solution to this problem for Beta 2 and missed it.
It's uppercase and lowercase AGAIN!

In this particular customize dialog, the default pref is currently  set in navigator.properties file as follows:

intl.charsetmenu.mailedit=iso-8859-1, iso-8859-15, armscii-8, iso-8859-4, iso-8859-14, iso-8859-2, gb2312, big5, koi8-r, 
windows-1251, koi8-u, iso-8859-7, iso-2022-jp, euc-kr, iso-8859-10, iso-8859-3, tis-620, iso-8859-9, utf-8, viscii


On this list, only iso-8859-1 can be either "iso-8859-1" or "ISO-8859-1" and it does not make a difference.
All the others are case-sensitive and if you make an error in case, it will not show in the customize 
dialog for Mail Edit.

So I corrected the default set above to the following set:

intl.charsetmenu.mailedit=ISO-8859-1, ISO-8859-15, armscii-8, ISO-8859-4, ISO-8859-14, ISO-8859-2, GB2312, Big5, 
KOI8-R, windows-1251, KOI8-U, ISO-8859-7, ISO-2022-JP, EUC-KR, ISO-8859-10, ISO-8859-3, TIS-620, ISO-8859-9, 
UTF-8, VISCII

and now all the charsets show up on a new profile.

Why do we have this kind of crazy dependency on case? 

We should check in the correct default set as soon as possible and get done with this
bug. (The internal default set info document was corrected.)

Comment 13

[Katsuhiko Momoi]

CC'ing rchen.

Comment 14

[Katsuhiko Momoi]

Re-nominating this for nsbeta3. 
It should take only a few minutes to check in the change.

Comment 15

[Frank Tang]

reassign to nhotta.
nhotta- can you please check in the fix as momoi suggest. Make sure search the 
commerical tree also. 

Do we have other places like this ?
nsbeta3+ per bug meeting. P2

Comment 16

[nhottanscp]

Checked in the charset names case change.

Comment 17

[Katsuhiko Momoi]

** Checked with 8/22/2000 Win32 build **

With the above build, all the charsets are now showing in the Customize list.
The only thing wrong is that ISO-8859-1 comes at the end of the list rather than
at the top as I had anticipated.

It turns out that the list checked in begins with "iso-8859-1" rather than with the 
uppercase "ISO-8859-1". For some reason, the lowercase puts 8859-1 at the end, while
the upper case puts it at the top of the list.

In an earlier comments I said that with Western (ISO-8859-1), it shows up on the list
whether or not it is lowercase.
Please note that the list I suggested above has "ISO-8859-1" in uppercase. I think we should
see this item at the top of the list. If you copy the list I have above, we should get
the correct order.

Re-opening for this minor fix. For UI correctness, the order is important.

Comment 18

[nhottanscp]

Checked in to corrected the case for ISO-8859-1.

Comment 19

[Katsuhiko Momoi]

** Checked with 9/11/2000 Win32 build **

The remaining problem that of ISO-8859-1 showing up at the bottom 
iw gone with the above build.
Verified as fixed.