235285 - add the UI for 'reply in the default character encoding'

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Jungshik Shin]

In bug 234958, I added a new preference entry 'reply_in_defaul_charset'. The
default value is set to false in mailnews.js. However, as Kat mentioned in bug
234958 comment #1, there was a lot of debate, which implies some people (like
me) want to use the default character encoding for outgoing messages regardless
ot the character encoding of a message I'm replying to. Although this can be
modified in the backend (about:config in Mozilla and editing prefs.js ), it may
be nice to have the UI for this option. 

Patch coming up shortly along with two screenshots for TB and Mozilla-mail.

Comment 1

[Jungshik Shin]

Attachment: patch

I also included the help file change. Some word-smithing is necessary here.
Currently, I have :

When replying to a message, use the default character encoding instead of that
of the message.  (for TB, I have something shorter, but I think I have to sync'
them)

The following may be better. 

When replying to a message, do not use the character encoding of the message,
but use the default character encoding. 

Comments are welcome.

Comment 2

[Jungshik Shin]

Attachment: thunderbird screenshot with the patch

A new checkbox is in Tools | Option | Font | Language.

Comment 3

[Jungshik Shin]

Attachment: mozilla screenshot

it's in Edit | Pref | Mail & News | Composition

Comment 4

[[e-mail]]

How about this:

Character encoding for (o) All messages (*) New messages only
    Western (Windows-1252) [v]

Comment 5

[Robert Accettura [:raccettura]]

This is a great enhancement.  It's been a pest to me as well.

I like Neil's proposition in comment 4.

Comment 6

[Katsuhiko Momoi]

(In reply to comment #4)
> How about this:
> 
> Character encoding for (o) All messages (*) New messages only
>     Western (Windows-1252) [v]

Q: So are you proposing two radio buttons instead of one toggle box?
Comment: I think "only" would be misleading to users. The default
          may be used also when the original message is in that
          encoding. We should void using "only". A toggle box
          as jungshik has it with some re-wording works better, I think.

Comment 7

[Jungshik Shin]

Kat, can you do some rewording? 

Comment 8

[Katsuhiko Momoi]

(In reply to comment #7)
> Kat, can you do some rewording? 

One proposal: (please compare to those in comment #1 and comment.)

"Always use the default character encoding in reply messages. (When unchecked, a
reply will reflect the character encoding of the original message.)" 

My aim here is to inform the user that this option allows only the default
encoding for replies, but at the same time, the usual practice (when unchecked)
is to reflect the original encoding. Since average user is not aware of the
encoding reflection in replies, this additional wording may be helpful in that
regard.

Comment 9

[Stefan Borggraefe]

See bug 235860 for a different idea about where to place this option in
Seamonkey's Preferences dialog.

Comment 10

[Stefan Borggraefe]

(In reply to comment #8)
> "Always use the default character encoding in reply messages. (When unchecked, a
> reply will reflect the character encoding of the original message.)"

I think this is much to long. Such a detailed description is more suited for the
help files IMHO. What about inverting the pref and using the following wording:

[x] In replies, use the character encoding of the message you reply to

which defaults to checked.

Just add the attribute prefinverse="true" to the checkbox to invert the pref.

Comment 11

[Katsuhiko Momoi]

(In reply to comment #10)
> (In reply to comment #8)
> > "Always use the default character encoding in reply messages. (When unchecked, a
> > reply will reflect the character encoding of the original message.)"
> 
> I think this is much to long. Such a detailed description is more suited for the
> help files IMHO. What about inverting the pref and using the following wording:
> 
> [x] In replies, use the character encoding of the message you reply to
> 
> which defaults to checked.

Your suggestion disconnects the relationship between this option and the default
character encoding setting.  The user will have to guess that the default is
used for all reply messages when this option is unchecked. If you want a shorter
version, my suggestion without the content in the parentheses is better. 

Comment 12

[Stefan Borggraefe]

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > "Always use the default character encoding in reply messages. (When
unchecked, a
> > > reply will reflect the character encoding of the original message.)"
> > 
> > I think this is much to long. Such a detailed description is more suited for the
> > help files IMHO. What about inverting the pref and using the following wording:
> > 
> > [x] In replies, use the character encoding of the message you reply to
> > 
> > which defaults to checked.
> 
> Your suggestion disconnects the relationship between this option and the default
> character encoding setting.

I think the options should be connected by their placement in the UI and be
grouped together in a <groupbox>.

This is already the case for Seamonkey and jshin will change TB accordingly,
too, if i understood him correctly (see bug 235860 comment 4 and bug 235860
comment 6).

But I agree this would be a problem in TB if the options stay where they
currently are and are not grouped in a better way. Sorry, I mainly thought about
the Seamonkey prefs when I made my suggestion.

> The user will have to guess that the default is
> used for all reply messages when this option is unchecked.

No, that's what the word "default" means, so I don't think the user has to guess
here. The default is used when nothing else is specified as an exception.

When the checkbox is checked, it means an exception to the default. Perhaps this
should be made more explicit:

[x] But in replies, use the encoding of the message you reply to

Note the added "But".

> If you want a shorter
> version, my suggestion without the content in the parentheses is better. 

Without the sentence in the parentheses, I think it will be unclear to the user
what happens, when the checkbox is not checked.

Also without the sentence in the parentheses it is disturbing to additionally
check the "[x] Always use..." checkbox since you already selected a default
behaviour and "always use" doesn't sound like an exception. The exception is
explained in the sentence in the parentheses.

Comment 13

[Katsuhiko Momoi]

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > (In reply to comment #8)

> No, that's what the word "default" means, so I don't think the user has to guess
> here. The default is used when nothing else is specified as an exception.
> 
> When the checkbox is checked, it means an exception to the default. Perhaps this
> should be made more explicit:
> 
> [x] But in replies, use the encoding of the message you reply to
> 
> Note the added "But".

I think the problem I have with your suggestion is that you've changed the
meaning of the default character encoding as existing users know it. This
default currently applies to only new messages. You're saying that the default
applies to all messages whether or not they are replies or new msgs. I think we
should preserve the original sense of this pref. Otherwise the user will be
confused by such a sudden change in basic meaning of the original pref setting.

Let me shorten my original suggestion:

"Always use the default character encoding in reply messages. (When unchecked,
only new messages use the default.)" 

Look at the similar check box for Message Display, it runs into 2nd line and
contains 12 words. My suggestion contains 16 and still easily fit into 2 lines.

BTW, placing this item in some other place should be discussed in another bug.
If everyone is agreeing that the placement should be moved, then this bug should
be closed and new wording should be discussed there.

Comment 14

[Stefan Borggraefe]

(In reply to comment #13)
> I think the problem I have with your suggestion is that you've changed the
> meaning of the default character encoding as existing users know it.

No, I just reverted the meaning of the *new* pref, because this way the IMHO
overly long UI string isn't necessary.

> This
> default currently applies to only new messages. You're saying that the default
> applies to all messages whether or not they are replies or new msgs.

No, I don't. I wrote by default the checkbox should be checked, so the default
character encoding is only used for new messages, but not for replies. This is
the behaviour the user is used to (meaning the exception to the usage of the
default character encoding is active, like it always was).

> I think we
> should preserve the original sense of this pref.

Yes, me too. ;-)

See the screenshot in bug 235860. This may make my idea a bit clearer. This
could be implemented whether we introduce a new "Languages" pref pane or not, so
just ignore the fact the option is placed inside this pane in the screenshot.

Comment 15

[Jungshik Shin]

(In reply to comment #14)
> (In reply to comment #13)

> > This
> > default currently applies to only new messages. You're saying that the default
> > applies to all messages whether or not they are replies or new msgs.
> 
> No, I don't. I wrote by default the checkbox should be checked, so the default
> character encoding is only used for new messages, but not for replies. This is
> the behaviour the user is used to (meaning the exception to the usage of the
> default character encoding is active, like it always was).

You missed Kat's point. Your suggestion preserves the default _behavior_, but
doesn't preserve the meaning of 'default'. The length should not matter as long
as it fits the space we have. IT's rather confusing to end-users so that we'd
better be kind than brief. 

Comment 16

[Stefan Borggraefe]

(In reply to comment #15)
> You missed Kat's point. Your suggestion preserves the default _behavior_, but
> doesn't preserve the meaning of 'default'.

You mean because the new checkbox needs to be checked, to achive the old
behaviour? I agree this might be unexpected for users used to the UI when a new
option is added. But I think this is a minor problem, if the wording is clear.

> The length should not matter as long
> as it fits the space we have. IT's rather confusing to end-users so that we'd
> better be kind than brief. 

I agree understandability is more important than brevity here. I still think my
wording idea is brief and understandable at the same time. See the screenshot in
bug 235860. I think this is much better than what we have now/is proposed here
(independent of whether these options are placed in a new "Languages" pane or not).

But if noone agrees, I think I better be quiet now. Sorry, if this turns out to
be just an annoying fruitless discussion in this case. I really thought I had a
point here.

Comment 17

[Jungshik Shin]

Attachment: patch v2 with wording changes.

the same as attachment 142028 [details] [diff] [review] except for wording changes suggested by Kat.

Comment 18

[Jungshik Shin]

Comment on attachment 143087 [details] [diff] [review]
patch v2 with wording changes.

Asking for r/sr (assuming Kat is fine with this)

Comment 19

[David :Bienvenu]

Comment on attachment 143087 [details] [diff] [review]
patch v2 with wording changes.

fine with me, as long as it's fine with Kat.

Comment 20

[Katsuhiko Momoi]

(In reply to comment #19)
> (From update of attachment 143087 [details] [diff] [review])
> fine with me, as long as it's fine with Kat.
> 

The UI wording for the option is fine with me, too. Thanks!

Comment 21

[[e-mail]]

Comment on attachment 143087 [details] [diff] [review]
patch v2 with wording changes.

I checked this in to make sure it made the l10n freeze.

>     var _elementIDs = ["forwardMessageMode", "spellCheckBeforeSend", "strictlyMime", 
>                        "wrapLength", "sendDefaultCharsetList", "mailWarnOnSendAccelKey",
>-                       "FontSelect", "fontSizeSelect", "textColor", "backgroundColor"];
>+                       "FontSelect", "fontSizeSelect", "textColor", "backgroundColor", "replyInDefaultCharset"];
I moved replyInDefaultCharset to after sendDefaultCharsetList to keep these in
document order.

>+<!ENTITY replyInDefaultCharset.label          "Always use the default character encoding in reply messages. (When unchecked, only new messages use the default.)">
I changed "reply messages" to "replies" because I think it's better English. In
mailnews I also changed "the" to "this" because the seamonkey pref panel
doesn't have the word "default" in it, but I think the original wording seems
to work for thunderbird.

Comment 22

[Jungshik Shin]

fix landed.