| Summary: | KMail should allow swithing encoding for reading individual messages | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | Mikhail Ramendik <mr> |
| Component: | mime | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | CC: | oded |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | RedHat Enterprise Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Mikhail Ramendik
2004-11-08 19:03:27 UTC
On Montag 08 November 2004 19:03, Mikhail Ramendik wrote:
> Sometimes messages arrive with wrongly set charset headers. This is not
> kmail's fault, of course.
A proposal for the experienced users: you can create filters which add (or
rewrite) certain charset headers. Add them to the filter action menu. You
can also add an icon to make them visible in the toolbar. Then you're able
to make permanent charset changes to the messages.
I agree that we should always fall back to Auto when another message is selected. A permanent override character encoding can be specified in the configuration dialog. I'm not sure about the X-KMail-CharsetOverride header because changing a message header is expensive over IMAP (download message, change header, upload message). IMO fixing/changing the charset should be solved via a script or a plugin once we support something like this. Actually a filter can already do this; I wrote one for Cyrillic autodetection, in Python, using the enca autodetection library. My plugin is at http://www.ramendik.ru/fomenca/index.html , a link to enca is also there. The feature is present in kmail in kde 3.5.2. Marking bug as resolved. Is this issue really resolved ? I noticed "Override encoding" in the kmail message viewer configuration dialog, but it doesn't do anything: I've set the override to Auto, and now if I try to view an e-mail with an incorrect character encoding, and it doesn't display right, and I choose a different encoding - then the new encoding still get stuck. When I then open a new message where the encoding is detected correctly (but is deferent then the encoding of the bad message), it is rendered incorrectly and I must go back to the character encoding list and choose "auto" again. I understood that this issue was about solving this problem so that I don't have to reset the character encoding manually after viewing one broken message. I've encountered mail that could not be solved with the change-header-through-filter hack. The mail is a multipart/mixed message, where the body of the e-mail is encoded in EUC-KR, but the Content-Type for this body is set to ISO-8859-1. The problem is, Kmail cannot access the Content-Type header for the body because there is already a Content-Type for the multipart/mixed e-mail message. There seems to be no way to change the headers of included sections in a multipart message. Therefore, the only way to view the message in Korean is to actually go to View->Set Encoding. As suggested in bug #94702, it would be convenient if we could have the ability to set the "View->Set Encoding" option for each individual message, and have it retained across sessions. This is actually a feature provided by the StickyCharset plugin for Thunderbird. |