Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#8147 closed enhancement (fixed)

New message should not default to CP1252

Reported by: rq Owned by: siarzhuk
Priority: normal Milestone: R1
Component: Applications/Mail Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (19)

comment:1 by axeld, 8 years ago

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.

comment:2 by siarzhuk, 8 years ago

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

in reply to:  2 ; comment:3 by rq, 8 years ago

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.

in reply to:  3 ; comment:4 by siarzhuk, 8 years ago

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. ;)

in reply to:  4 ; comment:5 by rq, 8 years ago

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.

in reply to:  5 comment:6 by siarzhuk, 8 years ago

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.

comment:7 by bonefish, 8 years ago

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.

comment:8 by bonefish, 8 years ago

Type: enhancementbug

in reply to:  7 ; comment:9 by rq, 8 years ago

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?

in reply to:  9 comment:10 by bonefish, 8 years ago

Type: bugenhancement

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.

comment:11 by axeld, 8 years ago

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.

in reply to:  11 ; comment:12 by bonefish, 8 years ago

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.

in reply to:  12 ; comment:13 by siarzhuk, 8 years ago

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.

in reply to:  11 comment:14 by rq, 8 years ago

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.

in reply to:  13 comment:15 by siarzhuk, 8 years ago

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.

comment:16 by rq, 8 years ago

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?

comment:17 by siarzhuk, 8 years ago

Owner: changed from czeidler to siarzhuk
Status: newassigned

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

comment:18 by siarzhuk, 8 years ago

Resolution: fixed
Status: assignedclosed

Fixed during GCI 2011 in hrev43549.

comment:19 by rq, 8 years ago

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

Note: See TracTickets for help on using tickets.