Bug 43701

Summary: icq plugin does not recode russian messages
Product: [Unmaintained] kopete Reporter: shift
Component: ICQ and AIM PluginsAssignee: Kopete Developers <kopete-bugs-null>
Status: RESOLVED NOT A BUG    
Severity: normal CC: shlomister
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description shift 2002-06-09 01:00:28 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kopete
Version:           0.4 (using KDE 3.0.1 )
Severity:          wishlist
Installed from:    SuSE
Compiler:          gcc version 2.95.3 20010315 (SuSE)
OS:                Linux (i686) release 2.4.18-4GB
OS/Compiler notes: 

Russian ICQ messages are usually encoded in CP-1251. Kopete ICQ plugin sends them in KOI-8r and it seems like there is no recoding facilities there so i cant talk to people using other ICQ clients. 

some recoding options needed.

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Till Gerken 2002-09-15 15:07:24 UTC
Re-assigning to ICQ plugin 
Comment 2 Stefan Gehn 2003-01-26 22:53:32 UTC
you mean you want to select a certain encoding for a user on your contactlist and outgoing 
messages get recoded to that encoding? 
Comment 3 Stefan Gehn 2003-01-26 22:54:10 UTC
*** Bug 47298 has been marked as a duplicate of this bug. ***
Comment 4 shift 2003-01-29 00:12:21 UTC
well,  
 
at least in the way it is done in SIM, which, AFAIK, is the prototype for the icq-plugin.  
there is a sort of the default-encoding for me, and i can select particular encodings for 
particular users from my contact list.  
 
BTW: as far as i have tried it in kopete 0.5 came with KDE 3.1 - at least some of my friends 
read my russian OK, but i dont know how it depends on their clients and protocols they use -- i 
just have not reached all of them yet,  i'll try to figure it out ASAP. 
 
Comment 5 shift 2003-01-29 00:23:14 UTC
well,  
 
my recent tests show, that all my friends (at least using ICQ clients with protocol version 6 
and newer) read my russian OK, so you may close this issue at least for Russian.  
 
(who knows if it works well for other languages)  
Comment 6 Stefan Gehn 2003-01-30 16:27:05 UTC
Encodings should get honored now, selecting a special encoding for outgoing messages will get 
added after kopete 0.6 is out (see roadmap on our homepage). 

*** This bug has been marked as a duplicate of 52013 ***
Comment 7 Oleg Cherkasov 2003-10-05 19:23:24 UTC
Set of LANG=ru_RU.CP1251 before running kopete 0.7.2 (QT 3.1.2, KDE 3.1.4) helps
to write/receive messages in CP1251, however CP1251 lang environment is not
available on all Linux distros by default.
Comment 8 shift 2003-10-06 16:16:18 UTC
Subject: Re:  icq plugin does not recode russian messages

On Sunday 05 October 2003 21:23, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=43701
>
>
>
>
> ------- Additional Comments From oleg@tiscali.no  2003-10-05 19:23
> ------- Set of LANG=ru_RU.CP1251 before running kopete 0.7.2 (QT 3.1.2,
> KDE 3.1.4) helps to write/receive messages in CP1251, however CP1251
> lang environment is not available on all Linux distros by default.
> ___________
> www.plod.nm.ru - 
Comment 9 Shlomi Loubaton 2003-11-15 00:21:04 UTC
Please reopen this whishlist-bug. until now i didn't report because i thought that there is going to be encoding selection. but as i downloaded and compiled Kopete0.8beta1, i noticed it's still missing :(

ICQ users in Israel have the exact same problem. Some windows ICQ clients use ISO-8859-8 while other clients (kopete, sim, etc) use UTF-8. if i run kopete with ISO-8859-8 locales, then i can't see UTF8. To resolve this problem i think you should add encoding selection for each user that will be stored together with the contact information. in the chat window - please add a configurable combobox to set encoding. if you think it's ugly (and you're probably right) then set it to be hidden by default. but please add it.

I think the combobox shouldn't display all available encodings, it should display only the ones supported by the system. 

Comment 10 Thiago Macieira 2003-11-15 03:51:51 UTC
It's already there, but it's not in the chat window. It's in the properties dialog. However, Kopete's OSCAR protocol will do the right thing and send Unicode if ASCII can't fit, if the other side said it understands Unicode. If it doesn't, Kopete will send using the user encoding.

In other words, Kopete might know better than you. If the other side isn't receiving correctly, maybe they were not configured correctly.

I might add that I've never had a problem with Unicode being displayed wrong in Kopete (Latin 1 being displayed wrong I have).

Since you're not in the CC list nor in the Voters list, I'm assuming it'll take a long time for you to read this, so I'm closing the bug again meanwhile. If you still have problems, please tell us what you typed and what the other side received (and what client they were using).
Comment 11 Shlomi Loubaton 2003-11-19 17:12:06 UTC
The problem still exists. it seems that i can see hebrew text sent to me by windows ICQ but when i send text they can't see it. the encoding option in the ICQ contact information seems to have no effect, lacale variables have no effect either. (still using kopete 0.8beta1)

i also tested other clients like sim,Licq, and the problem doesn't exist with these clients. in sim's chat window there's an encoding button but i didn't even have to use it for communicating with windows ICQ clients. it autodetected and worked with the correct encoding. I was able to send and recieve hebrew text.

I still think that encoding button (like the one in sim) is a good idea (even if autodetection would have worked) as this bug makes Kopete unusable for hebrew users.

look what happens after i set to some hebrew encoding and try to send:
-------------------------------------
kopete: [void ICQUserInfo::slotSaveClicked()] setting encoding to MIB:85(ISO-8859-8-I Hebrew, logically ordered)
kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] SEND (CLI_SENDMSG), msg='ממצב ?' to 'xxxxxxxxx'
kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] Outgoing message encoded as 'UTF-16BE'
-------------------------------------

i set it to "ISO-8859-8-I Hebrew, logically ordered" but "Outgoing message encoded as 'UTF-16BE'" ???

and then i set it back to automatic:
-------------------------------------
kopete: [void ICQUserInfo::slotSaveClicked()] setting encoding to MIB:0(Automatic)
kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] SEND (CLI_SENDMSG), msg='מה ?' to 'xxxxxxxxx'
kopete: [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] Outgoing message encoded as 'UTF-16BE'
-------------------------------------
still, the other side could not read my hebrew text.

BTW: i don't uderstand where did 'UTF-16BE' setting come from. my system uses  only UTF-8.

should i open a new bug?
Comment 12 Stefan Gehn 2003-11-19 18:00:16 UTC
> BTW: i don't uderstand where did 'UTF-16BE' setting come from. my system
> uses only UTF-8. 

If the other side understands UTF16 I send out UTF16 regardless of the setting as that can encode anything you want.

You forgot to mention the client used on the other side, in case it's not official ICQ or micq I suspect the bug to be on the other side (there are clients that claim UTF support although they don't have any).
 
> should i open a new bug?
NO!
Comment 13 Shlomi Loubaton 2003-11-19 19:00:11 UTC
the log i gave before i was chating with a sim user who doesn't use UTF-8. 

Here is a full session log with ICQ pro 2003b for Win:
http://t2.technion.ac.il/~shlomil/kopete_problem.log
in this session, after reading the log, it looks like Kopete detects the right
encoding but the other user recieved only "aaaaaaa" or "???????" strings.

> You forgot to mention the client used on the other side, in case it's not 
> official ICQ or micq I suspect the bug to be on the other side (there are
> clients that claim UTF support although they don't have any). 

And that's exactly why a set-encoding feature is needed.
right now i can see it exists but i wish it wasn't hidden in the ICQ contact information. This should be added to the chat-window toolbar, even if hidden option as default IMO.


Comment 14 Stefan Gehn 2003-11-19 20:30:45 UTC
>Here is a full session log with ICQ pro 2003b for Win: 

That can't be ICQ 2003, sorry to say. Every current Mirabilis client sends UTF and this client does NOT.

> And that's exactly why a set-encoding feature is needed. 

No, it's only used if the other side does not support UTF.

> right now i can see it exists but i wish it wasn't hidden in the ICQ contact > information. This should be added to the chat-window toolbar, even if hidden > option as default IMO. 

That's impossible with the current chatwindow, maybe later.
 

Comment 15 Stefan Gehn 2003-11-19 20:38:18 UTC
Actually this conversation does not make any sense because your logs are not the same. One time you're chatting with a client that supports UTF and one time you're chatting with some crappy/outdated client.
Please don't change clients while testing something.
In case you want really verbose logs about the other sides caps you might uncomment #define OSCAR_CAP_DEBUG 1 in oscardebug.h. That might reveal problems about the other side supporting UTF or not.

Actually I think Thiago is right. If the other side announces UTF support and still things don't get displayed properly then the other side is having problems displaying UTF strings on screen and Kopete can't do anything about that.

Again: I am NOT going to work around broken clients, the code is already complex enough to make string parsing a mess, just make your friends use a decent client, there are enough working ones out there.
Comment 16 shift 2003-11-20 00:15:56 UTC
Subject: Re:  icq plugin does not recode russian messages         

The workaround for what you call "old broken" clients is simplier, that forcing all my friends  to switch to new "correct" clients. 
for example for Russians:

most Russian ICQ users use Windows, and thus the default text encoding for them is "CP-1251" (if not UTF-8, which is rare)

so is for most Russian Linux Users, since they talk to other Russian users, who use Windows. 

so there are two obvoius and simple solutions: 

1. Make default Russain encoding when "autodetecting" in ICQ as CP-1251. 

and/or 

2. Make a "default Encoding" option for the owner's  ICQ profiles, like in LICQ. -- this "defaults" encoding, if specified, will be used by default, 
for chatting with any other party, unless otherwise specified in that partie's contact properties. 

i dont know details about ICQ protocols -- maybe a newer version supports UTF-8, then, if the other party supports it, and that clients can agree themselves about it themselves, it should be used, 
otherwise -- the specified or the "default" encoding.  


This will simplify life of beginner KDE users 



Hello Stefan Gehn 

Comment 17 Thiago Macieira 2003-11-20 00:31:31 UTC
I believe you've just described Kopete's current behaviour, except there is no "default encoding" configuration.
Comment 18 Stefan Gehn 2003-11-20 09:20:50 UTC
Exactly, as usual people just don't get what I repeat all the time :(
OSCAR uses UTF if both sides announce UTF-support, otherwise the encoding-selection OR a fallback encoding (which is hardcoded right now due to lack of time) gets used.
If something does not work it's either caused by QTextCodec not working properly or the other side announcing UTF support although it does not understand UTF (btw, UTF in here means UTF16-BE).
Comment 19 shift 2003-11-21 12:24:54 UTC
Subject: Re:  icq plugin does not recode russian messages

> ------- Additional Comments From thiagom@mail.com  2003-11-20 00:31
> I believe you've just described Kopete's current behaviour,
> except there is no "default encoding" configuration.

what about adding it? it will be simplier for user to select this one, 
when first trying kopete, rather than re-setting the same for all of ~150 
of his pre-existing users that he found before 

Comment 20 Stefan Gehn 2003-11-21 12:44:49 UTC
> what about adding it?
After 3.2, it's too late to add new strings.
Comment 21 mi+kde 2004-04-13 18:34:22 UTC
Although I can specify the contact's preferred encoding in the contact info, I'd still like to be able to change the encoding explicitly in the chat window -- for the chat duration. The other party may happen to use a broken client temporarily, or something like this...
Comment 22 shift 2004-07-12 20:13:07 UTC
i tried it once more, and the result is the same. 
even more -- my russian friends with Miranda (protocol v8)
were reading me with ???? and i was reading their messages 
as some Japaneese symbols. 

after i changed their encodings (in their contact properties) to CP-1251 -- they read my russian messages fine -- and i read their messages as if they came in wrong encoding (CP1251 sysmbols displayed as ISO-8859-1) 

with SIM i never had such problems. 

besides -- most of my friends have russian nick which are displayed "in wrong encoding" in kopete, and fine in SIM and other popular linux and windows clients.  
Comment 23 shift 2004-11-15 10:01:43 UTC
I tryied the Kopete wich comes with kde-3.3.1 
and the result is the same. 

even more bizare -- they read my russian text fine, but i can not read their's (even setting the default encoding for contacts  seems not to help) 

will this problem ever be fixed? take a look on how it works in SIM or LICQ. 

a proposal: maybe there should be a contact-wide option like "default encoding"? 
AFAIK -- there are several ICQ protocols, some of which use UNICODE, some not. 
then, this option could be valid for case when non-UNICODE transfer is used. 

for example -- for Russian users the best option would be to choose "CP-1251" -- every windows client uses it, and most unix users have to use it for ICQ too. besides -- all russian nicknames are otherwise shown in wrong encoding as well. 
Comment 24 Matt Rogers 2004-11-15 14:33:28 UTC
there are several other bugs that are similar to your problem, and it won't be fixed until i can find time to fix it.
Comment 25 Gleb Litvjak 2004-12-03 19:33:32 UTC
I had a look at the sources. The file kopete/protocols/oscar/oscarsocket/oscarsocket.icq.cpp has some comments like "//TODO: encoding"
But the functions in that file only send data, so problem probably isn't there.

The second interesting place is in the file kopete/kopete/chatwindow/chatview.cpp (line 197). I have a crazy idea: what if the encoding of the chat window is set incorrectly? I am not a great programmer, so this is just a guess.
Comment 26 Gleb Litvjak 2004-12-03 19:35:20 UTC
Sorry for my last post - it was intended for another bug. Shame on me
Comment 27 Vanya 2005-01-06 11:35:33 UTC
Kopete is great client for KDE. But this bug forces me to switch back to SIM, because there is no such problem.
When I use

LANG=ua_UK.CP1251 kopete

or

LANG=ru_RU.CP1251 kopete

to start Kopete - I get correct encoding for ICQ contacts. Otherwise - ukrainian/russian contacts are displayed with wrong KOI8 or another default system encoding.
But. This setting doesn't affect default encoding for message receiving.
And I always get messages from my friends in some ISO encoding instead of my CP1251.
I think, (as Gleb Litvjak said, even if he had mistaken (?) ), that bug can be in message displaying, not receiving. May be messages is really received in UTF-8 (or -16) encodings, but then displayed in wrong system encoding? or even some "default" ISO encoding? What do you think about this?
Also, contact's "encoding" setting doesn't affect anything..
Comment 28 Matt Rogers 2005-01-25 16:10:51 UTC
CVS commit by mattr: 

Merge the oscar_rewrite branch into HEAD. There are a ton of changes here
and while i'm not going to go over them one by one, here's a brief overview
of some of the things that have changed.

- Delayed contact creation. Contacts aren't created on the kopete list until
  we get a confirmation back from the server that they were added correctly.
 
- Timestamps of received offline messages are correct now (#45751)

- Hopefully, many many encoding problems with message receiving are fixed
  (#88033, #97116, #43701)

- Contacts that require authorization are now marked by a red 'X' over their
  icon. 

- Asking for and getting contact list authorization should be much more 
  user friendly.

- All the reported crashes (except for two dealing with ICQ RTF) are fixed

- Contact list handling in general should be more robust.

All in all, there are just a ton of changes and hopefully, your AIM and ICQ
experience within kopete should become more enjoyable. 

BUG: 92115
BUG: 97411
BUG: 86471
BUG: 88062
BUG: 89505
BUG: 89982
BUG: 90353
BUG: 87714
BUG: 88033
BUG: 97116
BUG: 45751
BUG: 43701
BUG: 86502
BUG: 93631
BUG: 95702
BUG: 84688
BUG: 92888


  M +4 -6      Makefile.am   1.32
  M +46 -13    TODO   1.12
  M +299 -609  oscaraccount.cpp   1.161
  M +61 -131   oscaraccount.h   1.73
  M +121 -663  oscarcontact.cpp   1.166
  M +83 -196   oscarcontact.h   1.89
  M +57 -0     oscarmyselfcontact.cpp   1.2
  M +59 -0     oscarmyselfcontact.h   1.2
  M +2 -2      aim/Makefile.am   1.10
  M +91 -179   aim/aimaccount.cpp   1.50
  M +43 -54    aim/aimaccount.h   1.20
  M +158 -248  aim/aimcontact.cpp   1.65
  M +64 -74    aim/aimcontact.h   1.24
  M +23 -34    aim/aimprotocol.cpp   1.29
  M +56 -57    aim/aimprotocol.h   1.11
  M +67 -64    aim/aimuserinfo.cpp   1.18
  M +0 -1      aim/aimuserinfo.h   1.10
  M +1 -1      aim/kopete_aim.desktop   1.33
  M +1 -1      aim/ui/Makefile.am   1.4
  M +2 -4      aim/ui/aimaddcontactpage.cpp   1.10
  M +8 -14     aim/ui/aimaddcontactpage.h   1.4
  M +13 -4     aim/ui/aimeditaccountui.ui   1.31
  M +40 -35    aim/ui/aimeditaccountwidget.cpp   1.23
  M +21 -17    aim/ui/aimeditaccountwidget.h   1.9
  M +4 -7      icq/Makefile.am   1.12
  M +201 -228  icq/icqaccount.cpp   1.58
  M +70 -54    icq/icqaccount.h   1.24
  M +218 -279  icq/icqcontact.cpp   1.67
  M +86 -130   icq/icqcontact.h   1.30
  M +226 -0    icq/icqpresence.cpp   1.2
  M +176 -0    icq/icqpresence.h   1.2
  M +72 -372   icq/icqprotocol.cpp   1.63
  M +62 -73    icq/icqprotocol.h   1.17
  M +1 -1      icq/kopete_icq.desktop   1.36
  M +0 -2      icq/ui/.cvsignore   1.4
  M +7 -4      icq/ui/Makefile.am   1.5
  M +85 -344   icq/ui/icqadd.ui   1.12
  M +38 -262   icq/ui/icqaddcontactpage.cpp   1.21
  M +26 -35    icq/ui/icqaddcontactpage.h   1.8
  M +69 -0     icq/ui/icqauthreplydialog.cpp   1.2
  M +45 -0     icq/ui/icqauthreplydialog.h   1.2
  M +202 -0    icq/ui/icqauthreplyui.ui   1.2
  M +136 -141  icq/ui/icqeditaccountui.ui   1.47
  M +33 -472   icq/ui/icqeditaccountwidget.cpp   1.43
  M +19 -42    icq/ui/icqeditaccountwidget.h   1.18
  M +481 -0    icq/ui/icqgeneralinfo.ui   1.2
  M +68 -0     icq/ui/icqotherinfowidget.ui   1.2
  M +442 -0    icq/ui/icqsearchbase.ui   1.2
  M +141 -0    icq/ui/icqsearchdialog.cpp   1.2
  M +60 -0     icq/ui/icqsearchdialog.h   1.2
  M +138 -0    icq/ui/icquserinfowidget.cpp   1.2
  M +55 -0     icq/ui/icquserinfowidget.h   1.2
  M +219 -0    icq/ui/icqworkinfowidget.ui   1.2
  M +2 -0      liboscar/.cvsignore   1.2
  M +12 -0     liboscar/DESIGN   1.2
  M +194 -0    liboscar/HACKING   1.2
  M +28 -0     liboscar/Makefile.am   1.2
  M +77 -0     liboscar/TODO   1.2
  M +382 -0    liboscar/aimlogintask.cpp   1.2
  M +82 -0     liboscar/aimlogintask.h   1.2
  M +91 -0     liboscar/blmlimitstask.cpp   1.2
  M +43 -0     liboscar/blmlimitstask.h   1.2
  M +474 -0    liboscar/buffer.cpp   1.2
  M +248 -0    liboscar/buffer.h   1.2
  M +270 -0    liboscar/bytestream.cpp   1.2
  M +78 -0     liboscar/bytestream.h   1.2
  M +206 -0    liboscar/changevisibilitytask.cpp   1.2
  M +58 -0     liboscar/changevisibilitytask.h   1.2
  M +675 -0    liboscar/client.cpp   1.2
  M +368 -0    liboscar/client.h   1.2
  M +115 -0    liboscar/clientreadytask.cpp   1.2
  M +44 -0     liboscar/clientreadytask.h   1.2
  M +270 -0    liboscar/closeconnectiontask.cpp   1.2
  M +67 -0     liboscar/closeconnectiontask.h   1.2
  M +207 -0    liboscar/connection.cpp   1.2
  M +154 -0    liboscar/connection.h   1.2
  M +62 -0     liboscar/connector.cpp   1.2
  M +59 -0     liboscar/connector.h   1.2
  M +245 -0    liboscar/coreprotocol.cpp   1.2
  M +109 -0    liboscar/coreprotocol.h   1.2
  M +66 -0     liboscar/errortask.cpp   1.2
  M +39 -0     liboscar/errortask.h   1.2
  M +72 -0     liboscar/flapprotocol.cpp   1.2
  M +46 -0     liboscar/flapprotocol.h   1.2
  M +134 -0    liboscar/icbmparamstask.cpp   1.2
  M +55 -0     liboscar/icbmparamstask.h   1.2
  M +113 -0    liboscar/icqlogintask.cpp   1.2
  M +47 -0     liboscar/icqlogintask.h   1.2
  M +151 -0    liboscar/icqtask.cpp   1.2
  M +63 -0     liboscar/icqtask.h   1.2
  M +213 -0    liboscar/icquserinfo.cpp   1.2
  M +195 -0    liboscar/icquserinfo.h   1.2
  M +224 -0    liboscar/icquserinfotask.cpp   1.2
  M +75 -0     liboscar/icquserinfotask.h   1.2
  M +100 -0    liboscar/inputprotocolbase.cpp   1.2
  M +72 -0     liboscar/inputprotocolbase.h   1.2
  M +86 -0     liboscar/locationrightstask.cpp   1.2
  M +57 -0     liboscar/locationrightstask.h   1.2
  M +219 -0    liboscar/logintask.cpp   1.2
  M +144 -0    liboscar/logintask.h   1.2
  M +392 -0    liboscar/md5.c   1.2
  M +93 -0     liboscar/md5.h   1.2
  M +236 -0    liboscar/messagereceivertask.cpp   1.2
  M +102 -0    liboscar/messagereceivertask.h   1.2
  M +159 -0    liboscar/offlinemessagestask.cpp   1.2
  M +54 -0     liboscar/offlinemessagestask.h   1.2
  M +97 -0     liboscar/onlinenotifiertask.cpp   1.2
  M +60 -0     liboscar/onlinenotifiertask.h   1.2
  M +138 -0    liboscar/oscarbytestream.cpp   1.2
  M +72 -0     liboscar/oscarbytestream.h   1.2
  M +425 -0    liboscar/oscarclientstream.cpp   1.2
  M +165 -0    liboscar/oscarclientstream.h   1.2
  M +108 -0    liboscar/oscarconnector.cpp   1.2
  M +69 -0     liboscar/oscarconnector.h   1.2
  M +349 -0    liboscar/oscartypeclasses.cpp   1.2
  M +210 -0    liboscar/oscartypeclasses.h   1.2
  M +252 -0    liboscar/oscartypes.h   1.2
  M +252 -0    liboscar/oscarutils.cpp   1.2
  M +75 -0     liboscar/oscarutils.h   1.2
  M +86 -0     liboscar/ownuserinfotask.cpp   1.2
  M +53 -0     liboscar/ownuserinfotask.h   1.2
  M +72 -0     liboscar/prmparamstask.cpp   1.2
  M +42 -0     liboscar/prmparamstask.h   1.2
  M +116 -0    liboscar/profiletask.cpp   1.2
  M +56 -0     liboscar/profiletask.h   1.2
  M +228 -0    liboscar/rateclass.cpp   1.2
  M +126 -0    liboscar/rateclass.h   1.2
  M +157 -0    liboscar/rateclassmanager.cpp   1.2
  M +76 -0     liboscar/rateclassmanager.h   1.2
  M +172 -0    liboscar/rateinfotask.cpp   1.2
  M +64 -0     liboscar/rateinfotask.h   1.2
  M +2427 -0   liboscar/rtf.cc   1.2
  M +864 -0    liboscar/rtf.ll   1.2
  M +207 -0    liboscar/rtf2html.h   1.2
  M +139 -0    liboscar/safedelete.cpp   1.2
  M +79 -0     liboscar/safedelete.h   1.2
  M +94 -0     liboscar/senddcinfotask.cpp   1.2
  M +41 -0     liboscar/senddcinfotask.h   1.2
  M +57 -0     liboscar/sendidletimetask.cpp   1.2
  M +46 -0     liboscar/sendidletimetask.h   1.2
  M +203 -0    liboscar/sendmessagetask.cpp   1.2
  M +47 -0     liboscar/sendmessagetask.h   1.2
  M +166 -0    liboscar/serverversionstask.cpp   1.2
  M +57 -0     liboscar/serverversionstask.h   1.2
  M +123 -0    liboscar/servicesetuptask.cpp   1.2
  M +69 -0     liboscar/servicesetuptask.h   1.2
  M +102 -0    liboscar/snacprotocol.cpp   1.2
  M +46 -0     liboscar/snacprotocol.h   1.2
  M +50 -0     liboscar/ssiactivatetask.cpp   1.2
  M +38 -0     liboscar/ssiactivatetask.h   1.2
  M +196 -0    liboscar/ssiauthtask.cpp   1.2
  M +60 -0     liboscar/ssiauthtask.h   1.2
  M +157 -0    liboscar/ssilisttask.cpp   1.2
  M +109 -0    liboscar/ssilisttask.h   1.2
  M +429 -0    liboscar/ssimanager.cpp   1.2
  M +131 -0    liboscar/ssimanager.h   1.2
  M +448 -0    liboscar/ssimodifytask.cpp   1.2
  M +127 -0    liboscar/ssimodifytask.h   1.2
  M +99 -0     liboscar/ssiparamstask.cpp   1.2
  M +43 -0     liboscar/ssiparamstask.h   1.2
  M +31 -0     liboscar/stream.cpp   1.2
  M +75 -0     liboscar/stream.h   1.2
  M +286 -0    liboscar/task.cpp   1.2
  M +114 -0    liboscar/task.h   1.2
  M +367 -0    liboscar/transfer.cpp   1.2
  M +169 -0    liboscar/transfer.h   1.2
  M +354 -0    liboscar/userdetails.cpp   1.2
  M +85 -0     liboscar/userdetails.h   1.2
  M +153 -0    liboscar/userinfotask.cpp   1.2
  M +69 -0     liboscar/userinfotask.h   1.2
  M +173 -0    liboscar/usersearchtask.cpp   1.2
  M +61 -0     liboscar/usersearchtask.h   1.2
  M +93 -0     liboscar/warningtask.cpp   1.2
  M +59 -0     liboscar/warningtask.h   1.2
  M +7 -0      liboscar/tests/.cvsignore   1.2
  M +19 -0     liboscar/tests/Makefile.am   1.2
  M +49 -0     liboscar/tests/clientstream_test.cpp   1.2
  M +49 -0     liboscar/tests/clientstream_test.h   1.2
  M +56 -0     liboscar/tests/logintest.cpp   1.2
  M +53 -0     liboscar/tests/logintest.h   1.2
  M +73 -0     liboscar/tests/ssigrouptest.cpp   1.2
  M +54 -0     liboscar/tests/ssigrouptest.h   1.2
  M +111 -0    liboscar/tests/ssitest.cpp   1.2
  M +34 -0     liboscar/tests/ssitest.h   1.2
  M +67 -0     liboscar/tests/userinfotest.cpp   1.2
  M +53 -0     liboscar/tests/userinfotest.h   1.2
  R            Doxyfile   1.3
  R            README.login   1.1
  R            icq/icqsendsmsdialog.cpp   1.1
  R            icq/icqsendsmsdialog.h   1.1
  R            icq/icquserinfo.cpp   1.21
  R            icq/icquserinfo.h   1.11
  R            oscarsocket/.cvsignore   1.1
  R            oscarsocket/Makefile.am   1.25
  R            oscarsocket/aim.cpp   1.9
  R            oscarsocket/aim.h   1.8
  R            oscarsocket/buffer.cpp   1.44
  R            oscarsocket/buffer.h   1.31
  R            oscarsocket/md5.c   1.1
  R            oscarsocket/md5.h   1.1
  R            oscarsocket/oncomingsocket.cpp   1.23
  R            oscarsocket/oncomingsocket.h   1.11
  R            oscarsocket/oscar_fam01.cpp   1.3
  R            oscarsocket/oscar_fam04.cpp   1.10
  R            oscarsocket/oscar_fam19.cpp   1.10
  R            oscarsocket/oscarcaps.cpp   1.5
  R            oscarsocket/oscarcaps.h   1.4
  R            oscarsocket/oscarconnection.cpp   1.32
  R            oscarsocket/oscarconnection.h   1.24
  R            oscarsocket/oscardebug.h   1.5
  R            oscarsocket/oscardirectconnection.cpp   1.24
  R            oscarsocket/oscardirectconnection.h   1.10
  R            oscarsocket/oscarfilesendconnection.cpp   1.14
  R            oscarsocket/oscarfilesendconnection.h   1.8
  R            oscarsocket/oscarmessage.cpp   1.6
  R            oscarsocket/oscarmessage.h   1.1
  R            oscarsocket/oscarsocket.aim.cpp   1.33
  R            oscarsocket/oscarsocket.cpp   1.213
  R            oscarsocket/oscarsocket.h   1.126
  R            oscarsocket/oscarsocket.icq.cpp   1.73
  R            oscarsocket/oscarsocket.icq.h   1.14
  R            oscarsocket/oscartypes.h   1.9
  R            oscarsocket/rateclass.cpp   1.5
  R            oscarsocket/rateclass.h   1.3
  R            oscarsocket/rtf.cc   1.5
  R            oscarsocket/rtf.ll   1.5
  R            oscarsocket/rtf2html.h   1.2
  R            oscarsocket/ssidata.cpp   1.22
  R            oscarsocket/ssidata.h   1.16



Comment 29 Dmitry Kagan 2005-02-16 13:05:16 UTC
Hi!

Are these changes included in beta2? I have KDE 3.4 beta2 installed and the problem is still there. Moreover, I cannot select a custom encoding for my ICQ contacts anymore, using the "Properties" page. I really hope this will be fixed, because I honestly prefer Kopete over SIM, but forced to use the latter because of this bug.

Thanks
Comment 30 Andrey Cherepanov 2005-03-30 10:09:40 UTC
I examine Kopete 0.10 from KDE 3.4.0. For ICQ protocol bug is still exists. Do you apply patch for KDE_3_4_BRANCH or in version 0.10.0 that can be download from kopete.kde.org? Or how I can build Kopete for stable usage with this patch?
Comment 31 Matt Rogers 2005-03-31 16:17:43 UTC
the new code is in version 0.10. Please open a new bug with exact details if you're still having problems with this in 0.10. I need the following details:

1. the name and version of the sending client
2. the name and version of the receiving client
3. the locale setting of the receiving client
4. the locale setting of the sending client
5. a debug log of a single aim or icq session where you get sent messages that aren't displayed correctly.

having items 1, 2, and 5 are the most important. I simply can't fix the bug w/o having that information.
Comment 32 shift 2005-04-04 16:28:50 UTC
I have no idea on what clients are those which my friends use, 
Also, i have no notion about internals of ICQ protocol, 
and what formats of messages are. 

I can only say, that the linux clients i usually use (licq, sim) 
handle this situation fine. 

From what i can see: 
my friend use VARIOUS clients from Windows.
(from ICQ98 till ICQ2003 including MIRANDA, ICQlite and icq2go.) 

I can read their messages fine if i set encoding  to cp1251 manually for 
every person in my contact-list manually. 

in other programs this issue is solved easilly: 
both SIM and LICQ allow to set so called "default" encoding for each IM 
account. 

As far as i know, some newer versions of ICQ protocols (clients) use 
unicode for messages transfer, and i suggest the following solution for 
the problem: 

If a remote client is UNICODE-compatible, use unicode, 
otherwise, for older clienst/protocols, if a special encoding is set for a 
specific person in contact-list, use that, otherwise, use an encoding set 
as "default" in the account setup, otherwise, use locale-default one. 

please note, i suggested the above solution 2 years ago (as soon as i tried 
one of the first public versions of Kopete) !!! 

Utill that issue is fixed, at least in russian LUGs and forums you will 
always see messages like "kopete is buggy with encodings, that is why i 
use SIM/LICQ/GAIM/ etc" 

On Thursday 31 March 2005 18:17, Matt Rogers wrote:

> 1. the name and version of the sending client
> 2. the name and version of the receiving client
> 3. the locale setting of the receiving client
> 4. the locale setting of the sending client
> 5. a debug log of a single aim or icq session where you get sent
> messages that aren't displayed correctly.
>
> having items 1, 2, and 5 are the most important. I simply can't fix the
> bug w/o having that information.

Comment 33 shift 2006-06-04 21:01:28 UTC
seems to be working fine with 0.12 release
the "default encoding" option seems to work fine, 

it didnot work for me in the version that came with SuSE 10.1 by default. (0.11.something -- it had the default encoding option, but it was grayed)

after 4 years since this issue was described, it seems to be resolved, HURAY (!)