If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED WONTFIX

Status

()

Core
Internationalization
VERIFIED WONTFIX
17 years ago
16 years ago

People

(Reporter: jbetak@netscape.com (away - not reading bugmail), Assigned: jbetak@netscape.com (away - not reading bugmail))

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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
accepting, marking future
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Summary: Need to change IBM-866 decider registration to CP-866 → Need to change IBM-866 decoder registration to CP-866
Created attachment 34145 [details]
RDF menu test
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

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

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.

Updated

16 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 6

16 years ago
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

Updated

16 years ago
Status: RESOLVED → VERIFIED

Comment 7

16 years ago
Verified, please reopen in case someone strongly disagrees.

Comment 8

16 years ago
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.
You need to log in before you can comment on or make changes to this bug.