Closed Bug 23540 Opened 25 years ago Closed 25 years ago

[FEATURE]pref UI for mail default charset

Categories

(MailNews Core :: Internationalization, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: nhottanscp, Assigned: nhottanscp)

References

Details

(Whiteboard: [PDT-])

Attachments

(2 files)

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).
Phil, we like this to be done for beta. Who is responsible for mail preference?
Assignee: nhotta → phil
Summary: [BETA] pref UI for mail default charset → [FEATURE] [BETA] pref UI for mail default charset
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?
Keywords: beta1
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.
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.
Per pdt mtg last night, putting on the PDT- radar.  THis is not a beta1 
critieria bug.
Whiteboard: [PDT-]
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.
  
Whiteboard: [PDT-]
Assignee: phil → ducarroz
Target Milestone: M14
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.
pop up menu in the pref dialog
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Accepting
Status: NEW → ASSIGNED
Summary: [FEATURE] [BETA] pref UI for mail default charset → [FEATURE]pref UI for mail default charset
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?
Whiteboard: [PDT+] → [PDT+]2/15/00
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.
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.
reassign to nhotta until we decide what we really want to do.
Assignee: ducarroz → nhotta
Status: ASSIGNED → NEW
Whiteboard: [PDT+]2/15/00 → [PDT+
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.
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.
Assignee: nhotta → ducarroz
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. 
The bug is assigned to i18n until we have an agreement for the UI issue.
Assignee: ducarroz → nhotta
Status: NEW → ASSIGNED
It seems that we need to have a meeting to iron this out ...

Whiteboard: [PDT+ → [PDT+] No ETA
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.
Whiteboard: [PDT+] No ETA → [PDT+] No ETA, need UI discussion
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...

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.  
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.
Whiteboard: [PDT+] No ETA, need UI discussion → need UI discussion
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.
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: nhotta@netscape.com
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>
Marking PDT- due to UI team opinion
Whiteboard: need UI discussion → [PDT-]need UI discussion
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.
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)
Whiteboard: [PDT-]need UI discussion → need UI discussion
BTW, the UI used for Beta1 will probably be changed post-Beta1.
Cleared Whiteboard because UI discussion occurred this morning.
Whiteboard: need UI discussion
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I change to use a new pref name.
The new one is "mailnews.send_default_charset",
"intl.character_set_name" is obsoleted.
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.
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. 
Status: RESOLVED → VERIFIED
Blocks: 33977
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: