New message should not default to CP1252

[rq]

It looks like mail still defaults to CP1252 for new messages. Can this perhaps be changed to UTF-8? Users who use only ASCII will not notice anyway, and all others should have been using unicode-capable email clients for quite some time now.

[axeld]

It originally even was UTF-8 IIRC, but was later changed due to numerous problems with other mail clients at the time. But I think you're right; no need to cripple the user experience for non-latin writing users anymore.

[siarzhuk]

What if Mail guesses the encoding from the current locale settings?

[rq]

Replying to siarzhuk:

What if Mail guesses the encoding from the current locale settings?

This default could and probably should be configurable by localizers, but I would still suggest to default to UTF-8, and leave the localization possibility only for those locales where UTF-8 is really suboptimal or unwelcome. IIRC, China has its own transformation scheme for Unicode, so Chinese localizers may want to change that default.

[siarzhuk]

Replying to rq:

Replying to siarzhuk:

What if Mail guesses the encoding from the current locale settings?

This default could and probably should be configurable by localizers, but I would still suggest to default to UTF-8, and leave the localization possibility only for those locales where UTF-8 is really suboptimal or unwelcome.

I suspect in most regions UTF-8 is unwelcomed because 8-bits encodings were applicated much earlier than multibyte ones and still widely used in communication (re-read the comment from Axel above). And I see no reasons to prohibit any locale to use it's region-specific 8-bit charset as default e-mail encoding.

So default E-Mail encoding is definitely the object of localization. ;)

[rq]

Replying to siarzhuk:

Replying to rq:

Replying to siarzhuk:

What if Mail guesses the encoding from the current locale settings?

This default could and probably should be configurable by localizers, but I would still suggest to default to UTF-8, and leave the localization possibility only for those locales where UTF-8 is really suboptimal or unwelcome.

I suspect in most regions UTF-8 is unwelcomed because 8-bits encodings were applicated much earlier than multibyte ones and still widely used in communication (re-read the comment from Axel above).

You should re-read its second sentence too. :)

And I see no reasons to prohibit any locale to use it's region-specific 8-bit charset as default e-mail encoding.

So default E-Mail encoding is definitely the object of localization. ;)

Agreed. I was just suggesting to suggest UTF-8 as default, not to prohibit anyone from using something else in their localization.

[siarzhuk]

Replying to rq:

Replying to siarzhuk:

I suspect in most regions UTF-8 is unwelcomed because 8-bits encodings were applicated much earlier than multibyte ones and still widely used in communication (re-read the comment from Axel above).

You should re-read its second sentence too. :)

There is no need for me to re-read it, because I read it one hour ago and have predicted that you "stick" on that part of Axel's thesises. ;) But I referenced the first one, of course - hard-coding the default encoding back to UTF-8 can revive to life the ticket that was already fixed by mentioned "UTF-8 -> CP1252" modification. As soon as somebody in the Windows World cannot read multibyte message from Haiku Mail. Localization of this parameter give us a chance to avoid this endless cycle, IMO. :D

Agreed. I was just suggesting to suggest UTF-8 as default, not to prohibit anyone from using something else in their localization.

OK, now it is clear. Thanks for the explanation of your position.

[bonefish]

Replying to siarzhuk:

What if Mail guesses the encoding from the current locale settings?

Unless I'm much mistaken the locale settings don't contain an encoding. Since Haiku consistently uses UTF-8, there's no need to.

Other than that, whatever is set in the encoding combo box, if the user types something that can't be encoded using this character set, Mail should automatically use a character set that can (e.g. UTF-8). I assume rq has noticed that it doesn't. Hence I set the ticket type to bug. If it does, the ticket is invalid.

On a general note, I really doubt that it makes any sense to allow the user to choose a character set these days.

[rq]

Replying to bonefish:

Replying to siarzhuk:

What if Mail guesses the encoding from the current locale settings?

Unless I'm much mistaken the locale settings don't contain an encoding. Since Haiku consistently uses UTF-8, there's no need to.

I think the charset can be made localizable for this particular application though.

Other than that, whatever is set in the encoding combo box, if the user types something that can't be encoded using this character set, Mail should automatically use a character set that can (e.g. UTF-8).

This is what Thunderbird does, by the way.

I assume rq has noticed that it doesn't. Hence I set the ticket type to bug. If it does, the ticket is invalid.

Mail warns the user about unencodable characters and allows to either send the message and let Mail replace them with substitutes, or to cancel sending and choose a different character set or edit the message.

On a general note, I really doubt that it makes any sense to allow the user to choose a character set these days.

It could stay as a preference in the prefs dialog. But showing it in both Read and Write windows is way too geeky, IMO.

Should I file separate bugs asking for those features?

[bonefish]

Replying to rq:

I think the charset can be made localizable for this particular application though.

I don't see the point.

Mail warns the user about unencodable characters and allows to either send the message and let Mail replace them with substitutes, or to cancel sending and choose a different character set or edit the message.

That's at least semi-reasonable behavior. Switching back to enhancement.

On a general note, I really doubt that it makes any sense to allow the user to choose a character set these days.

It could stay as a preference in the prefs dialog. But showing it in both Read and Write windows is way too geeky, IMO.

In the read window it makes some sense, since otherwise there wouldn't be a way to deal with mails with incorrect encoding.

Should I file separate bugs asking for those features?

IMO the very simple solution is to leave things as they are but don't bother the user when sending the mail or, alternatively, remove the encoding combo box completely and use a reasonable encoding automatically.

[axeld]

Replying to bonefish:

On a general note, I really doubt that it makes any sense to allow the user to choose a character set these days.

How so? The number of clients supporting UTF-8 should be greatly increased, but that's all. I wouldn't mind using UTF-8 again as a default after the installation. Alternatively, Mail could also use locale depending settings (I would guess there are only a handful of encodings we would need to encode this way), and could silently fall back to UTF-8 when the mail cannot be encoded else. That would make the preferences item superfluous which I think would be a nice aim.

Replying to rq:

But showing it in both Read and Write windows is way too geeky, IMO.

Why? It's the same in Thunderbird, BTW. It certainly doesn't need to be a very obvious feature (thanks to Clemens, I don't recall how Mail looks like), a menu item would certainly suffice. I just wouldn't entirely remove it just yet.

[bonefish]

Replying to axeld:

Replying to bonefish:

On a general note, I really doubt that it makes any sense to allow the user to choose a character set these days.

How so? The number of clients supporting UTF-8 should be greatly increased, but that's all. I wouldn't mind using UTF-8 again as a default after the installation.

Why would a user want to set the character set? Seriously, what's the use case? The only thing I can come up with is that you want to send a mail to someone from whom you know that they use an ancient mail client that doesn't support certain charsets. How realistic is that?

I would remove the option and let Mail internally first try a simple legacy charset and, if that doesn't work, fall back to UTF-8.

[siarzhuk]

Replying to bonefish:

Why would a user want to set the character set? Seriously, what's the use case?

As Rimas already noted above, Chinese are using their's own Unicode standart GB18030 that is not compatible with UTF-8.

The only thing I can come up with is that you want to send a mail to someone from whom you know that they use an ancient mail client that doesn't support certain charsets. How realistic is that?

With Russian "encodings soup" it is realistic scenario. ;-) Many clients are still using koi-8r, cp1251 etc.

I would remove the option and let Mail internally first try a simple legacy charset and, if that doesn't work, fall back to UTF-8.

I propose the following:
1) Introduce the string B_TRANSLATE_CONTEXT("Default (UTF-8)", "Default Message Compose encoding") as the key to select default encoding in the mentioned menu;
2) During translating, for example, to Russian, the Translator can decide to use "Windows CP-1251 charset" translation for this string;
3) At the run time the program use localized string as key in the menu and fallback to UTF-8 in case encoding was not found.

[rq]

Replying to axeld:

Replying to rq:

But showing it in both Read and Write windows is way too geeky, IMO.

Why? It's the same in Thunderbird, BTW. It certainly doesn't need to be a very obvious feature (thanks to Clemens, I don't recall how Mail looks like), a menu item would certainly suffice. I just wouldn't entirely remove it just yet.

Thunderbird certainly doesn't have that option in the prime spot in UI. It's in the menu in Thunderbird. Whereas in Mail it's a drop-down that is ALWAYS visible both when composing and when reading e-mail.

I don't mind that option, it might still be useful. I just don't think it deserves the prime spot it currently has.

[siarzhuk]

Are there any objections if I publish this issue as GCI 2011 task to fix it in the way described below?

Replying to siarzhuk:

I propose the following:
1) Introduce the string B_TRANSLATE_CONTEXT("Default (UTF-8)", "Default Message Compose encoding") as the key to select default encoding in the mentioned menu;
2) During translating, for example, to Russian, the Translator can decide to use "Windows CP-1251 charset" translation for this string;
3) At the run time the program use localized string as key in the menu and fallback to UTF-8 in case encoding was not found.

[rq]

Yep, I think it's fine. Although I think mail could benefit from more UI love, as discussed above. Plus, I think it still doesn't use the Layout Manager, does it? Perhaps some of that could become GCI tasks too?

[siarzhuk]

I take ownership of this issue because it was published as GCI 2011 task.

[siarzhuk]

Fixed during GCI 2011 in hrev43549.

[rq]

siarzhuk, can you fix the URL in the comment of the default mail charset string? The given URL: ​http://cgit.haiku-os.org/haiku-tree/src/kits/textencoding/character_sets.cpp is incorrect, it should be: ​http://cgit.haiku-os.org/haiku/tree/src/kits/textencoding/character_sets.cpp