235860 - Implement "Languages" pref pane for MailNews

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Stefan Borggraefe]

Implement the "Languages" pref pane from the MailNews spec:

http://www.mozilla.org/mailnews/specs/prefs/Preferences.html#Lang

This is needed to save some space in the "Message Display" pane to add a new
option (see bug 231428). I think this is the cleanest way to do it.

Also I think it is more user-friendly to have those settings together in one pane.

Comment 1

[Stefan Borggraefe]

Attachment: Patch

Comment 2

[Stefan Borggraefe]

Comment on attachment 142448 [details] [diff] [review]
Patch

Neil, do you agree with this approach? Do you have  the time to review this
patch?

Comment 3

[[e-mail]]

jshin, didn't you want UI for a new pref? I can't find the bug...

Comment 4

[Jungshik Shin]

It's bug 235285. BTW, I have a different idea about the rearrangment of menu 
items in thunderbird than this one. Having a separate 'language' doesn't seem 
to be such a good idea. I'd rather put the UI for 'the default character 
encoding for outgoing messages' in 'Composition'( Tools | Options) and the UI 
for 'the default character encoding for incoming messages' in 'Display' as 
Mozilla-mail currently does.

What TB does at the moment (putting both in Fonts) is rather confusing (at 
least to me). It took me a while to find whether they're. 

Comment 5

[Stefan Borggraefe]

(In reply to comment #4)
> It's bug 235285.

Ok, I can add this option to the new pane when the wording is finalized.

> BTW, I have a different idea about the rearrangment of menu 
> items in thunderbird than this one. Having a separate 'language' doesn't seem 
> to be such a good idea. I'd rather put the UI for 'the default character 
> encoding for outgoing messages' in 'Composition'( Tools | Options) and the UI 
> for 'the default character encoding for incoming messages' in 'Display' as 
> Mozilla-mail currently does.

IMHO it is more user-friendly to have more categories with less options per
category in the Preferences/Options dialog than to have less categories with
many options. This way the user doesn't see so many options at once and each
individual pane is more concise.

The "Display" and "Composition" panes are already quite crowded in Thunderbird,
so I think it would be better to add a new pane to TB, too. Just IMHO.

For Seamonkey there is an additional reason for the new pane: Since the
Preferences window isn't resizable there is no space left in the "Message
Display" pane to add new options. Moving away the character encoding-options
from there solves this problem.

> What TB does at the moment (putting both in Fonts) is rather confusing (at 
> least to me). It took me a while to find whether they're. 

I agree. Also it isn't apparent to the user that "[x] Appy default to all
messages (ignore character encoding specified by MIME header)" only affects
Incoming Messages, because of the current arrangement of the Languages options
in TB.

Comment 6

[Jungshik Shin]

(In reply to comment #5)

> > to be such a good idea. I'd rather put the UI for 'the default character 
> > encoding for outgoing messages' in 'Composition'( Tools | Options) and the UI 
> > for 'the default character encoding for incoming messages' in 'Display' as 
> > Mozilla-mail currently does.
> 
> IMHO it is more user-friendly to have more categories with less options per
> category in the Preferences/Options dialog than to have less categories with
> many options. 

 On the other hand, options we're dealing with here quite naturally belong to
Composition and Display. I'm afraid 'Language' is not such a good umbreallar for
them. It reflects a quite common misconception that languages and character
encodings are very tightly bound to each other. They're related, but not as
tightly as putting them in 'Language' suggests. 

> The "Display" and "Composition" panes are already quite crowded in 
> Thunderbird,

  Well, it depends.. To me, it's all right, but your mileage seems different.

> For Seamonkey there is an additional reason for the new pane: Since the
> Preferences window isn't resizable there is no space left in the "Message
> Display" pane to add new options. 

  Is it true? There is room for new options (I've just opened that pane and am
looking at it )


> Appy default to all messages (ignore character encoding specified by MIME
> header)" only affects Incoming Messages, because of the current 
> arrangement of the Languages options in TB.

  Moving it to 'Display' would solve the problem, too :-)

Let's see what others think about these issues.

Comment 7

[Stefan Borggraefe]

(In reply to comment #6)
> I'm afraid 'Language' is not such a good umbreallar for
> them. It reflects a quite common misconception that languages and character
> encodings are very tightly bound to each other. They're related, but not as
> tightly as putting them in 'Language' suggests. 

What about calling the new pane "Character Encoding"?

The problem here is that there already exists a pane called "Languages" below
the "Navigator" branch which includes character encoding options. So calling
this pane "Character Encoding" would be inconsistent. I can imagine this was the
reason the authors of the spec decided to call this pane "Languages", too.

> > For Seamonkey there is an additional reason for the new pane: Since the
> > Preferences window isn't resizable there is no space left in the "Message
> > Display" pane to add new options. 
> 
>   Is it true? There is room for new options (I've just opened that pane and am
> looking at it )

This looks different depending whether you use Classic or Modern. Also the
display resolution and font size have an effect here. When you use Classic it
also depends on the native theme used in your environment. I think when adding
new options, you have to consider the worst case: See the screenshot attached to
bug 231428.

Comment 8

[Katsuhiko Momoi]

I vote for keeping the location of 2 preferences items where they are -- under
Message Display and Composition. My reasons:

1. A lrage majority of users are monolingual and they often don't see language
as an issue. Many think that a program should work for their language as is. So
they tend to ignore a preference like "languages" thinking that this is for
foreign languages. "Character Encoding" as a pref panel name is even worse. 
2. But most users care about how messages should be displayed and how they can
compose their messages. Placing these preferences together with the functions
that they serve leads to much easier discoverability.
3. Visually I don't feel that having 2 items in one panel is crowded. I care
more about the logical placement of the items. 
4. Coupled with re-wording proposal in Bug #235285, these 2 pref settings will
be even easier to understand under familiar places to existing users.

Comment 9

[Stefan Borggraefe]

Comment on attachment 142448 [details] [diff] [review]
Patch

Bitrotted already.

Comment 10

[Stefan Borggraefe]

Attachment: Updated patch

I fixed the bitrot and added the new pref from bug 235285 with the wording I
proposed. I also rephrased the option to ignore the encoding specified in the
MIME header of the messages the user reads. I think it is easier to understand
now for an average end-user who typically doesn't know what a "MIME header" is
IMHO.

I can revert this change and use another wording for the new option if this
isn't wanted at all.

This is just a suggestion, so I don't put this into anyone's review queue for
now.

If this new pref pane isn't wanted at all, we need another place for the new
option in bug 231428.

Comment 11

[Stefan Borggraefe]

Attachment: Screenshot

This is a screenshot of the patch I just attached in action.

Comment 12

[Stefan Borggraefe]

Attachment: Updated patch without any wording changes

I still think this is a good idea(tm).

Kat: Please also consider, if we want to add new options to the "Message
Display" pane (bug 231428) or the "Composition" pane, we need to restructure
the placement of the options a bit. There is already a "Languages" pane below
the "Navigator" branch.

Comment 13

[Stefan Borggraefe]

Attachment: Screenshot with "Updated patch without any wording changes" applied

It would be nice if one of the CCed module owners would either give some kind
of "Go ahead" or mark this bug wontfix. Thanks! :-)

Comment 14

[Stefan Borggraefe]

Marking WONTFIX since no-one seems to want this change. Please reopen if I'm wrong.

Also I found another way to fix bug 235860.

Comment 15

[Stefan Borggraefe]

(In reply to comment #14)
> Also I found another way to fix bug 235860.

I meant bug 231428. Sorry for the spam.