[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    [Kopete-devel] [Bug 43701] icq plugin does not recode russian
From:       <shift () newmail ! ru>
Date:       2003-11-19 23:15:58
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
     
http://bugs.kde.org/show_bug.cgi?id=43701     




------- Additional Comments From shift@newmail.ru  2003-11-20 00:15 -------
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 

Ср, 19.11.2003 23:38:19 you wrote:
> 
SG> ------- You are receiving this mail because: -------
SG> You reported the bug, or are watching the reporter.
SG>      
SG> http://bugs.kde.org/show_bug.cgi?id=43701     
SG> 
SG> 
SG> 
SG> 
SG> ------- Additional Comments From mETz81@web.de  2003-11-19 20:38 -------
SG> 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. SG> Please don't change clients while \
testing something. SG> 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. SG> 
SG> 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. SG> 
SG> 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. SG> __________

SG> www.zakaz.orc.ru - доставка карт связи: ОРЦ (IP-телефония, доступ в Интернет, \
хостинг), МТС, БИ Плюс



__________
www.newmail.ru -- Новая Почта для нового поколения.
_______________________________________________
Kopete-devel mailing list
Kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel


[prev in list] [next in list] [prev in thread] [next in thread]