Version: 1.3 (using KDE 4.4.4)
There's two encoding for Korean, EUC-KR and CP949, and Qt4 supports both of them.
But konversation 1.3 which is based on KDE4, so also Qt4 supports EUC-KR only.
CP949 is superset of EUC-KR, so when the the IRC server encoding is CP949, konversation with EUC-KR cannnot display or transport some characters.
Is it difficult for konversation to give another selection of CP949 for Korean encoding?
I think if konversation uses QTextCodec, it is simply possible by adding CP949 item.
Steps to Reproduce:
Input a korean character which included in CP949 not EUC-KR like '잌'.
I get "Encoding Conflict Warning" message box.
By enabling CP949 encoding, there should be no problem.
Should be simple, yes, we just weren't aware of it / nobody else had asked for it so far. Thanks for your report, we'll look into adding it quickly.
Might actually not that simple -- we get the lists of character sets from kdelibs' KGlobal::charsets(), and KDE doesn't seem to support CP949 there right now. So the fix probably needs to be made in kdelibs, then Konvi would pick it up automatically. Since we ultimately use QTextCodec though we could special-case on Konvi's end until kdelibs gets fixed.
You mean that it's the problem of kdelibs rather konversation, right?
It looks like KCharsets also uses QTextCodec, so maybe this problem easily.
Anyway, I'll report this problem to kdelibs again.
Thanks for replying, Hein.
Yep, if KGlobal::charsets()->descriptiveEncodingNames() would return CP949, Konversation would make it available automatically.
I registered this problem as new feature of kdecore.
Thank you, I'm going to close this one as a duplicate then.
For the record, if you are building Konversation yourself and want to fix the problem locally until kdelibs is fixed, take a look at irc/irccharsets.cpp, specifically the IRCCharsets constructor. That's where it gets the list from kdelibs. You could easily put a hack there to add CP949 to the list.
*** This bug has been marked as a duplicate of bug 243513 ***