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
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.
>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.
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
Verified, please reopen in case someone strongly disagrees.
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.