[Tickets #10148] Re: Incorrect message charset in replies with reply_headers

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10148
------------------------------------------------------------------------------
  Ticket             | 10148
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Incorrect message charset in replies with reply_headers
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Resolved
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-09-01 16:33) wrote:

>> at least one of his MUA's) in that charset.  And generally people
>> aren't doing something like responding to a Norwegian message in
>> Mandarin Chinese, so this charset hint is useful in almost all cases.
>
> actually, it is quite short-sighted approach to the problem -  
> especially in case if there still exist mail clients not sticking to  
> original encoding, but adjusting it to the minimum - for example -  
> it is real situation that the reply to UTF8 message is demoted to  
> ISO8859-1 just because the text of reply does not contain letters  
> with vowels.
>
> As for my specific case - it is nothing extraordinary having two or  
> three languages in replay - Latvian, English and Russian for which  
> only UTF8 offers full coverage.
>
> the problem already starts with the lack of automatic promotion from  
> transliterated Latvian (iso8859-1, using "aa" instead of "?" etc) to  
> the correct one - iso8859-13 or UTF8

Your assumption is that everybody can read UTF-8 messages.  While I  
wish that was the case, I guarantee there are legacy clients that  
don't handle UTF-8 (or have buggy handling).  So changing our default  
to always send in UTF-8 is a decision NOT to be taken lightly.

FYI: Gmail doesn't send all messages in UTF-8 either.

>>  But the code would be so much easier to maintain if we just convert
>> everything to UTF-8 and consistently stick with that internally.
>
> do you have any internal plans when this "will hit the ground"?

There are none.  This would require a complete refactor of both IMP  
and various framework code.

>> Having the user pick the charset is simply out of the question.
>> Nobody, outside of maybe programmers and computer scientists, has any
>> clue what charsets mean anyway, so giving them an option to change is
>> completely pointless.
>
> so, if one do not understands how the air plane is flying, lets  
> delete it from the list of available transportation means including  
> for those, who know even how to steer them? Do you really think that  
> "stupidification" of software is the way to go?

This is a terrible analogy.  Whether or not I know how an airplane is  
flying is irrelevant because when do I have to use that information?   
And if I don't have that knowledge, or have the wrong knowledge, it  
doesn't affect anything.

Conversely, whether or not I know about charsets is important because  
I, as a user, **must proactively make a decision** using this  
information at compose time.  And if I use my non-existent/incorrect  
knowledge, there is a good chance I could break the outgoing e-mail  
since the chosen charset may not support the characters I have placed  
in the body.