23540 - [FEATURE]pref UI for mail default charset

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[nhottanscp]

The default mail charset "intl.character_set_name" is used to set a charset of
new mails. If the pref is not specified then ISO-8859-1 is used.
We need UI for this pref value, otherwise non Latin1 users always have to set a
charset through menu before sending mails.
The detail UI spec to be given by Kat Momoi. For beta, we need a popup menu
which contains names of the fixed number of charsets (the same set as the mail
compose charset menu).

Comment 1

[nhottanscp]

Phil, we like this to be done for beta. Who is responsible for mail preference?

Comment 2

[nhottanscp]

We are expecting at least two more mail I18N pref UI post beta.
So we would like I18N specific are to be allocated under mail/news pref UI. And
put the mail default charset UI there.
Phil, could you reassign this to mail engineer?

Comment 3

[bobj]

This is required for Beta1, to enable the composing of NEW Japanese email
(vs. replying and forwarding).

The infrastructure we need for Beta from the mail team:
  1 - create new mail pref panel for internationalization
  2 - In this panel, create a drop down for the default mail sending
      charset that sets the "intl.character_set_name" preference.  The
      display names for the dropdown entries should be stored in a .dtd
      file (not .xul) for localizability.  The pref values can be hard-
      coded in the .xul for Beta1.  You can leverage the work done for
      the mail charset menu:

http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/messe
ngercompose.xul 
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/locale/en-US/
messengercompose.dtd

Post Beta1, I18N will rewrite the pref panel XUL to build up the dropdown
entries from a scriptable interface which will query the charset modules.

Comment 4

[bobj]

To clarify my previous comment, when I said you can leverage from the mail
charset menu .xul and .dtd, I meant you can get the list of display names
and pref charset values to be used for the dropdown.  The display names
in the .xul are reference via entities that come from the .dtd.

Comment 5

[leger]

Per pdt mtg last night, putting on the PDT- radar.  THis is not a beta1 
critieria bug.

Comment 6

[leger]

Update per nhotta:
"This is in the Beta 1 Criteria list. Under I18N Beta 1 Features -> Mail 
(Windows, Linux) -> Preference uI (dialog) to set default mail charset (used for 
new mail) 

http://client/seamonkey/prd/beta1criteria2.html#i18n"

Removing PDT- for re-eval.
  

Comment 7

[Phil Peterson]

That doesn't seem like the same thing to me (pref dialog vs. menu), but given
bobj's comments, which weren't available in the list PDT was working from
yesterday, I'm inclined to take it for B1. Reassign to ducarroz for M14.

Comment 8

[nhottanscp]

pop up menu in the pref dialog

Comment 9

[leger]

Putting on PDT+ radar for beta1.

Comment 10

[Jean-Francois Ducarroz]

Accepting

Comment 11

[Jean-Francois Ducarroz]

After speaking with the UI team, we decide to not add a pef UI but instead, we 
will just remenber the user last character set selected. That means every time 
the user select a charset, we write it in the pref. In 4.x, the user has to 
select the item "Set Default Character Set" at the bottom of the characters set 
menu to change the default. Do we want do the same?

Comment 12

[Katsuhiko Momoi]

No. That default setting is for Browser in 4.x.
We need a specific one for Mail, i.e. the mail default charset.
This is a critical part of "good" UI for international customers.
We should talk about this more. Call for a conference, please
inviting bobj, nohtta and me.

Comment 13

[shuang (gone)]

The default setting in 4.x is for Browser only. However, last time we 
discussed the overall Prefs panne and had conclution that the Language selection 
for 5.0 will be moved to "general" Panel and it will apply to all components 
(Netscape environment). By doing so, the default character set will apply to 
mail so there is no needs to have separate one for mail. The work was scheduled 
for after Beta 1, though. If you want to read about the details of Pref. 
structure, go to http://gooey/client/5.0/specs/preferences/ and take a look.
cc german (current UI Pref contact) and bijal ( PM for Pref) on this.

Comment 14

[Jean-Francois Ducarroz]

reassign to nhotta until we decide what we really want to do.

Comment 15

[Katsuhiko Momoi]

Sorry. I had to leave early today and am just now reading
additional comments. 
I went through the UI document shuang pointed to and found 
that there is only one reference to Accept-Language, mainly
for Browser. I found nothing that has to do with charset
related settings for Browser or Mail.

Language and charset issues are in most cases separate between
Brower and Mail. This is why there are separate mail related
charset settings in Outlook Express. I woud rather not go into
the details in the bug report but putting all charset
related pref items under general would only confuse users
and not in line with the reality of how the software will be
used by international users.

We have had a proposal out for Brower related pref items
and have asked german to review it:

http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html

Charset preferences and habits are different between browser and
mail/news. In order to meet the needs of the users, we need to
put several items under Mail/News.

I propose that I18n reps and UI team meet to map out plans 
for international related UI proposals and ideas.

For now, we would very much like to have the default mail
charset pref UI and there will be other items specific to 
Mail/News. Just like it doesn't make sense to put mail MIME
issues under Browser or General, it does not make sense
to put mail/news charset related items under general.

If you want to make do with only 1 general Language Preference
then there need to be a whole slew of backend work to map that
default language to that language-specific charset defaults
which are different among Berowser, Composer and Mail/News.

From my reading of the Languages under General, that does not
seem to be what is proposed. This seems to be applying to
just the Accept-Language choice and has only a limited
applicability.

Comment 16

[Katsuhiko Momoi]

Someone in the UI team, please explain what "Languages"
under "General" will set. Does it do the same thing as
"Edit | Prefs | Navigator | Languages" under 4.x? If so, all it 
will do would be set the "Accept-Language" header sent as one
of the HTTP headers. 

This setting under 4.x has nothing to do with the Browser default 
charset or the Mail send default charset. And Browser default
charet and the mail default charset are often different 
even for the same language. 

The mail default charset UI is part of the International Beta 
requirement and it needs to be implemented alogn the lines
discussed among ducarroz, nhotta, bobj, and momoi.

Sending it back to ducarroz.

Comment 17

[german]

Explain to me why -general consumers using Netscape- need a UI for a preference 
for -different- charsets for each mail and browser (does that mean each component 
would need one of those...?). So far nobody has made a compelling understandable 
argument here that would justify why we need to bother the average user with such 
a technical detail in multiple such exposed ways. Or in other words give us a 
real word user scenario that covers the 80% case that would require being able to 
set the charset differently for browser and mail. I would think such a pref would 
apply to whereever content is displayed hence Shuang's pointing to the 'General' 
panel which is -not- browser specific. 

Comment 18

[nhottanscp]

The bug is assigned to i18n until we have an agreement for the UI issue.

Comment 19

[Katsuhiko Momoi]

It seems that we need to have a meeting to iron this out ...

Comment 20

[bijals (gone)]

Since I am new to this issue, a meeting would be great.  I will setup something 
for Friday or Monday with everyone on this bug list.

Comment 21

[german]

In the mean time can we take off PDT+ from that one, since it obvoiusly needs
more time for discussion. I really don't think we should halt verything else for
beta1 for this one. My 0.02 Euro...

Comment 22

[shuang (gone)]

Agreed. Please remove PTD+.(Jan?)
Prefs is a complex issue that affact every components. Right now, the entire 
design of the Prefs UI is in a rough stage thus needs major clean-up after B1. 
We have already agreed in last Prefs meeting that a follow up design discussion 
will be scheduled soon after beta 1 code freeze.  Let's not just rush in this 
particular item for this beta.  

Comment 23

[Jean-Francois Ducarroz]

German, you are a cheap guy, 0.02 Euro doesn't even worth 2 cent anymore! Anyway, I've just removed the PDT+ tag 
to force this bug be reviewed again by the PDT team.

Comment 24

[nhottanscp]

There is a related bug which also mentions the default mail send charset.
20249 [FEATURE] feedback for mail charset when composing

I will attach screen shots about what users might encounter.

Comment 25

[nhottanscp]

Attachment: composing japanse mail, this is what the sender see

Comment 26

[nhottanscp]

Attachment: received mail, this is what the receiver see

Comment 27

[nhottanscp]

Additional info about the screen shots:
This is what is sent in case of text/plain (everything was sent as '?'),

Subject: plain text jp
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

?????????????
?????????????
?????????????

and text/html (everything was sent as encoded unicode entities),

To: [e-mail]
Subject: html text jp
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html><head></head>
<body>&#12371;&#12428;&#12399;&#26085;&#26412;&#35486;&#12398;&#12513;&#12540;&#
12523;&#12391;&#12377;&#12290;<br>
<br>
&#12371;&#12428;&#12399;&#26085;&#26412;&#35486;&#12398;&#12513;&#12540;&#12523;
&#12391;&#12377;&#12290;<br>
<br>
&#12371;&#12428;&#12399;&#26085;&#26412;&#35486;&#12398;&#12513;&#12540;&#12523;
&#12391;&#12377;&#12290;</body>
</html>

Comment 28

[rickg]

Marking PDT- due to UI team opinion

Comment 29

[nhottanscp]

At today's meeting, it was decided to continue UI discussion about international 
preferences.
For this particular problem of mail send default charset, we will put work 
around code for beta1.
Here is the list of things to do for beta1,
1) Enable check mark for mail send charset menu.
2) Add "Set Default Character Set" to allow the user to set the mail send 
default.
3) If the user selects a menu item from the mail send charset menu and the 
default mail send charset is not defined then ask the user if the user like to 
use it as a default mail send charset as well.

Comment 30

[bobj]

Cleared PDT- for reconsideration.
We met with UI and mail folks this morning. It was agreed that we need
some way in Beta1 to set the default mail sending charset.

Referring to nhotta's previous comment:
  (2) Working in nhotta's local tree and needs review
  (1) nhotta will apply similar fix that we have used for checkmarks in other
      menus
  (3) Not necessary for Beta1.  We will initialized the default based
      upon the localization (e.g., US Beta1 will default to Latin1, Japanese
      Beta1 will default to JIS)

Comment 31

[bobj]

BTW, the UI used for Beta1 will probably be changed post-Beta1.

Comment 32

[bobj]

Cleared Whiteboard because UI discussion occurred this morning.

Comment 33

[leger]

Putting on PDT- radar for beta1.

Comment 34

[nhottanscp]

Checked in the work around. 
I added "Set Default Mail Send Character Set" at the bottom of the charset menu 
and that can be used to set the mail send default charset.
Charset menu check mark for messsage compose is implemented.
I am closing this bug as FIXED. Please file a separate bug for the international 
pref UI issue.

Comment 35

[nhottanscp]

I change to use a new pref name.
The new one is "mailnews.send_default_charset",
"intl.character_set_name" is obsoleted.

Comment 36

[nhottanscp]

By the change I made yesterday, I broke a part of reply/forward charset setting.
It happens when the replying mail charset is not the same as the pref charset. 
For example, when the pref is ISO-8859-1 (default value) and reply to the 
message of ISO-2022-JP, the menu check mark is put to ISO-8859-1 instead of 
ISO-2022-JP. The problem can be avoided by explicitly set a charset to 
ISO-2022-JP before the mail is sent.
There is problems in my JS code, I have a fix for that.

Comment 37

[Katsuhiko Momoi]

This menu is working as intended. The default value is 
preserved from session to session also via the prefs.js
item: mailnews.send_default_charset

The only problem I found is not with this fix but a random
crash which occurs when you quit Mozilla. If you happen
to have changed the value of the defaul send charset
during such a session, the value is not saved.
This crash occurs often enough so that it prevents
this feature being useful at all times.

I'll look for the crashing bug in the bug database, in the 
meantime, I'll mark this fix verified. 

Comment 38

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/6fb2528b13f4
[fenix] closes https://github.com/mozilla-mobile/fenix/issues/23540: scale wallpaper and translate to bottom of image