Bug 219524 - (gaim) could be more informative in the ICQ encoding warning [NEEDINFO]
(gaim) could be more informative in the ICQ encoding warning
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pidgin (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Warren Togami
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-13 13:42 EST by Josef Kubin
Modified: 2014-06-02 09:21 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-02 09:21:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pm-rhel: needinfo? (jkubin)


Attachments (Terms of Use)

  None (edit)
Description Josef Kubin 2006-12-13 13:42:32 EST
Description of problem:
I have problem to read some ICQ messages with diacritic signs, it writes me:
(11:07:48 PM) Karel: (There was an error receiving this message.  The buddy you
are speaking to most likely has a buggy client.)

It should _always_ prints "a buggy garbage-message" with appended warning
message about error, because culprit is sometimes minor error but the rest of
garbage-message is human readable.

I don't know which SW is culprit, one of the problematic clients is:
http://www.qip.ru/downloads.html

Version-Release number of selected component (if applicable):
gaim-2.0.0-0.17.beta4.el5

How reproducible:
always
Comment 1 Luke Schierer 2006-12-13 17:41:24 EST
have you set your encoding in your account options? 
Comment 2 Josef Kubin 2006-12-13 17:49:22 EST
Encoding: UTF-8
Comment 3 Luke Schierer 2006-12-13 17:52:41 EST
The other party is almost certainly not sending UTF-8.  There is no way to tell
at a protocol level what encoding *is* in use though.  ICQ clients typically
have a similar selector in their preferences (though some provide a drop down),
and it is your job as a user to match the encoding being sent by the people you
want to talk with.
Comment 4 Josef Kubin 2006-12-13 18:03:34 EST
It means that the error message should inform the user more accurately "There
was an error receiving this message, try to check your encoding settings".
"The buddy you are speaking to most likely has a buggy client."
It is missleading message, isn't it?
Comment 5 Luke Schierer 2006-12-13 20:41:14 EST
The problem is that there *are* buggy clients out there that will send
untranslatable text no matter what you put in that preference. Unfortunately
some of the buggiest clients (I'm not sure they hit this particular situation,
but they are the cuase of a great many gaim bug reports) such as miranda and
sim, are also very popular clients. 

Perhaps the error message could be made clear, but it is not wrong for all cases
where it occurs. 
Comment 6 Luke Schierer 2006-12-13 20:48:23 EST
I have changed this to read "There was an error receiving this message.  Either
you and the buddy you are speaking to have a different encoding selected, or the
buddy has a buggy client."  That should handle both your case and the other
possibility. 
Comment 7 Ethan Blanton 2006-12-13 21:13:35 EST
We should probably use gaim_utf8_salvage for this sort of thing.  That would at
least show the ascii characters embedded in most 8-bit encodings.

(Why is this bug irritatingly viewable only when logged in?)

Ethan
Comment 8 Luke Schierer 2006-12-13 21:27:07 EST
presumably that would be about the same as the current case when the message is
in russian or hebrew or chinese or some other entirely unascii encoding?
Comment 9 Ethan Blanton 2006-12-13 22:12:32 EST
Yes; it would simply be preceded by ????????????.

However, for most Western European and several Eastern European encodings, you
would see things like "se?or" for "señor", "r?sum?" for "résumé", etc., which is
probably intelligible in context.

Ethan
Comment 10 Tony Fu 2008-10-05 21:29:44 EDT
User jkubin@redhat.com's account has been closed
Comment 11 RHEL Product and Program Management 2014-03-07 08:47:05 EST
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Comment 12 RHEL Product and Program Management 2014-06-02 09:21:26 EDT
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).

Note You need to log in before you can comment on or make changes to this bug.