Version: (using KDE KDE 3.1.3) Installed from: Mandrake RPMs OS: Linux Kmail needs a set encoding option for its messages like Konqueror has. This is to deal with E-mail messages that do not set their encoding properly.
view->set encoding works fine for me. I somewhat doubt it's a 3.2 feature, but possible
Subject: Re: Need a "Set Encoding" feature On Sat, 11 Oct 2003, Stephan Kulow wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=65862 > coolo@kde.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |WORKSFORME > > > > ------- Additional Comments From coolo@kde.org 2003-10-11 15:03 ------- > view->set encoding works fine for me. I somewhat doubt it's a 3.2 feature, but possible > Thanks, this works. It was easy to miss because it was not in the right mouse button context menu. Regards, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif@vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ An apple a day will keep a doctor away. Two apples a day will keep two doctors away. Falk Fish
This is so not fixed! Kmail needs to auto-detect the encoding (possibly by the user choosing a number of encodings to try, similarly to how it's done for composed messages). Why on earth would anyone assume all of my incoming emails use the same encoding?!?
Marcus Sundman: I think it would be a good idea if KMail automatically changed the encoding if it's explictly specified in the message headers. (in case it doesn't do so already) However, "guessing" the encoding if it's not explicitly specified is Evil. This will encourage people to send messages with incorrect encodings hoping they will be detected correctly by the Mail User Agent. We should not sanction such incompliance with standards. This is similar to what happens in the browser world. MSIE guesses the encoding and language of the page, and as a result there are numerous pages on the Web, that are written in a foreign language, yet did not specify an encoding proper, in the HTTP headers or HTML <head> block. (which its authors did not notice because they are only using MSIE) Other browsers are more standards compliant and do not guess the encoding and so the user needs to switch encoding manually and explicitly. I can see it in many Israeli sites that I browse to. In many of them the Hebrew is initially displayed in ISO-8859-1. (weird accented characters). In one site, parts of the same page (!) are in logical Hebrew and others are in visual Hebrew. MSIE displays it fine, but other browsers cannot display both parts correctly. To conclude: if the encoding was explicitly set by the message, it should be switched (in case it isn't the case already). If it wasn't set, it should display it as gibberish, and afterwards give the user the option to explicitly set the encoding. If you receive messages encoded in a different encoding than the ones they were composed with, send the author a note so he will correct it. Let's keep our mail (and web) free of standards' non-compliance.
What you are suggesting would be fine in a perfect world, but unfortunately the world isn't perfect. People sending messages usually: a) have no control over the email systems they're using b) won't care that 1% of the people receiving his/her emails can't view them (at least not enough to do anything about it) c) has control and cares, but doesn't have the know-how to fix the situation, or doesn't want to switch to an otherwise inferior system If you really want it fixed at the other end then you could show an error message whenever reading emails with invalid headers. This might be annoying enough to make people complaint about the error to the sender. Actually the error message could have a button for sending such a complaint message to the sender. The fact still remains that there is very little I can do to fix the error at the sender's end, so I have to fix it at my end if I want it fixed. This means either making a workaround in kmail or dumping kmail in favor of some other email client. I'd prefer the former.
Hello, I have now encountered this problem. I've checked, and I think that there are two things which should be solved. I'll start with the easier. 1. The "encoding" menu should go into the context menu, since when I open a message in its own window there's no menu on the top of the window. Indeed, after reading this discussion, I've discovered that when I use the "preview pane" I can choose the encoding and it worked. However, I didn't find it (and couldn't find it) on the first place because there was no menu! 2. The HTML message that I received was standard-compliant - the encoding was specified explicitly (<meta http-equiv="Content-Type" content="text/html; charset=windows-1255">). Konqueror opened it perfectly. However, when it was displayed as a message, the encoding wasn't detected, probably because kmail added a box with from, to, subject at the head of the message. Could these problems be fixed? Thanks, Noam Raphael