79911 - Need to change IBM-866 decoder registration to CP-866

Status: VERIFIED WONTFIX

(Core :: Internationalization, defect)

Description

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

this is a follow-up bug for bug 77588. We still need to change internal charset 
factory registration from ibm-866 to cp-866. Futhermore we need to reverse the 
aliasing from ibm-866 to cp-866.

http://lxr.mozilla.org/seamonkey/source/intl/uconv/ucvlatin/nsUCvLatinModule.cpp
#919
http://lxr.mozilla.org/seamonkey/source/intl/uconv/ucvlatin/nsUCvLatinModule.cpp
#577
http://lxr.mozilla.org/seamonkey/source/intl/uconv/src/charsetalias.properties#3
05

Comment 1

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

accepting, marking future

Comment 2

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

Attachment: RDF menu test

Comment 3

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

hmm, the internal changeover from IBM866 to CP866 would result in a bigger 
patch than originally expected. Autodetectors in both commercial and open-
source trees are also involved. 

I'm lean towards letting go of this and leave the current change to CP-866 at 
the UI level. There is too big a risk of hard-to-find regressions. 

cc'ing mkaply for the needed changes on OS/2 and risk evaluation.

Comment 4

[Frank Tang]

>We still need to change internal charset factory registration from ibm-866 to
cp-866.
Why ?

Comment 5

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

the change was intended for consistency, if the effort required would be 
justifable. The current changeover to CP866 is on the UI level only, although 
that's enough to meet the functional requirements from bug 77588.

I thought the changes would be constrained to nsUCvLatinModule.cpp ans worth 
it, but it looks like more now. I'm up to a dozen individual changes and a 
handful of files.

Comment 6

[Frank Tang]

No, I think this is a invalid bug. We could pick up any name internally. There
are no conssitency needed in this level. Please do not spend time in this bug.
Thanks.
mark thsi bug as won't fix

Comment 7

[Andreas Becker]

Verified, please reopen in case someone strongly disagrees.

Comment 8

[bobj]

I agree this is low priority.  I disagree that this is invalid.

In general, internal naming should be consistent.  This is even more important
in an open-source world where people often use what exists as "documentation"
when adding something similar.

When someone adds the next cp/ibm codeset, if the existing code is consistent,
there's a better chance the new code will also be consistent.  My 2 cents.