If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Correct wording: Character coding warning on Save has a text for Send.

VERIFIED FIXED in mozilla0.8

Status

MailNews Core
Internationalization
P3
normal
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: hirata masakazu, Assigned: nhottanscp)

Tracking

({intl})

Trunk
mozilla0.8

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
To reproduce: Set text to FIXED width or PlainText Only.  Write ?? in subject
and write some Japanese text in the body.  Then choose Save instead of Send.
Result:Character coding warning as bug 42871.  Furthermore, if you cancel as the
warning dialog suggests to change the text, actual result is the message gets
lost without saving to Draft or going back to compose mode.(I am filing another
bug for this loss of message).
(Reporter)

Comment 1

17 years ago
I am changing the Summary, because I realized that the char code was actually
set to ISO8859-1.  Therefore, the getting the dialog itself was correct.
Summary: Japanese in Subject cuases character coding warning on save. → Character coding warning on Save has a text for Send.
(Assignee)

Comment 2

17 years ago
The warning is intended because we need to apply charset conversion before
saving the message.
(Reporter)

Comment 3

17 years ago
Well, actually, I sometimes get the warning even if the char is set to ISO2022JP
from the beginning in rare cases just like it used to be in 42871.(still trying
to find reproducible one, because I lost the message by 57083)  Please wait for
another bug filing, Hotta-san.

Updated

17 years ago
Keywords: dataloss, relnote

Comment 4

17 years ago
so is this a bug or not.  We should Confirm if it is or Invalid it it if it
isn't.  nhotta, can you make the call here please.  Thanks
(Assignee)

Comment 5

17 years ago
worksfome

There are situations the warning comes up not properly. They are filed
separately as bug 59679 and bug 59229.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 6

17 years ago
Hirata-san,

> Well, actually, I sometimes get the warning even if the char is
> set to ISO2022JP from the beginning in rare cases just like it
> used to be in 42871.

Please file a new bug when you find a reproducible test case
on this problem.

Marking it verified as Worksforme.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 7

17 years ago
You are missing the point of this bug.
This bug is not for wether the character warning should appear, or not.
This bug is for the misleading text that appears when you are trying to save the
message that does not match the character set.
The text says "To send it anyway....", which is a dialog for sending.  This
gives you an impression that, since you are not saving it as a draft, your
composed message does not get screwed up.
  I suggest the text be modified to "To Send or Save", or use a separate dialog. 
Status: VERIFIED → UNCONFIRMED
Keywords: dataloss, relnote
Resolution: WORKSFORME → ---

Comment 8

17 years ago
Thanks, Hirata-san.
If we are going to use the same warning, then
let's add "Save" to the eording.
Confirming the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Character coding warning on Save has a text for Send. → Correct wording: Character coding warning on Save has a text for Send.

Comment 9

17 years ago
The current wording of this dialog as of 11/8/2000 Win32 MN build
is:

"This message contains characters not found in the chosen
Character Coding. The message may be unreadable to the
recipient. Send it anyway or "Cancel" to choose a different
Character Coding."

How about changing this to:

"This message contains characters not found in the chosen
Character Coding. The message may be unreadable to the
recipient. Send/Save it anyway or "Cancel" to choose a
different Character Coding."

It will "eventually" be 'unreadable' to the recipient.
I think it would be OK to leave this word in there.
(Reporter)

Comment 10

17 years ago
It is not "evetually" unreadable, but unreadable to the writer after the message
is saved as draft.  That point is very important in the context of Save as
Draft.  I think we need to add "converting this message may result in unreadable
text" or something like that to stress that it is going to be converted if you
proceed.

Comment 11

17 years ago
We want to avoid the wording "convert" as warning to
average users.

If this text can be separate from the "send" warning, we can
make radical changes but this were to be shared among
the 2 types of cases, then how about:

"This message contains characters not found in the chosen
Character Coding. The sent/saved message may be unreadable.
Send/Save it anyway or "Cancel" to choose a different
Character Coding."


(Reporter)

Comment 12

17 years ago
You do not like "convert" ?  Interesting.  Is this a watched against word in
Christian-dominated society?
Anyhow, is it a bad idea to change the order to saved/sent, Save/Send?
Maybe it is only I, but I have a feeling that save should come first since save
is a local matter.  (I understand that the order of send/save was based on the
order of operation when send and save copy is performed.)  Otherwise, the
suggested text seems OK to me.
(Assignee)

Comment 13

17 years ago
I have just checked in the wording change for bug 52429 this week.
Adding gemal@gemal.dk, verah@netscape.com to cc and have their opinions.


Status: NEW → ASSIGNED
(Assignee)

Updated

17 years ago
OS: Mac System 8.6 → All
Hardware: Macintosh → All

Comment 14

17 years ago
In response to hirata-san,

> You do not like "convert" ?  Interesting.  Is this a
> watched against word in Christian-dominated society?

The problem with "convert" is it immediately raises a
question as to from what to what? And what does it mean to
convert in this context? A average user should not be
bothered with such details. "Send" and "Save" on the other
hand describe operations known to users.

> Anyhow, is it a bad idea to change the order
> to saved/sent, Save/Send?

If we need to use just this one dialog for both purposes,
my reasoning is based on which operation is more common.
I suspect that it is "Send" which is used more often.


(Reporter)

Comment 15

17 years ago
I am not so sure about whether average user should be or not be bothered with
details.  Character coding is bothering enough in this situation, and
"converting" clearly convey to average user that something will change forever
and the result may be total loss of what is displayed.  Is it not a situation
grave enough to warn an average user for coming danger?  More so if indeed the
user does not know much and never bother to save the work of typing a long text
somewhere else before hitting OK. 
(Reporter)

Comment 16

17 years ago
>The problem with "convert" is it immediately raises a
>question as to from what to what? And what does it mean to
>convert in this context?
From what you see or what you have typed to something different, obviously.
Having lost a lot of texts before getting used to this, I believe that there
should be a strong warning here, especially in Save, because Save implies that
the text is safely preserved locally, which actually is not about to happen.
> A average user should not be
>bothered with such details. "Send" and "Save" on the other
>hand describe operations known to users.
Yes, and Save is known to be safer than Send, that is an implication for an
average user.
If you do not like "convert", how about "the sent/saved text may BECOME
unreadable."  By changing from "be" to "become", the sentence sounds more
dangerous to me, and may serve the purpose of warning.
Oh, and I am talking about the danger especially in the situation when you close
the compose window and then you are asked whether you want it to be saved as
draft.  In that case, there will be total loss of information after you hit OK
in this char code warning.
(Reporter)

Comment 17

17 years ago
>The message you composed contains characters not found in the >selected
Character Coding, so your recipient may not be able to read >it. To send it
anyway, click OK. To return to the Composer window >where you can choose a
different Character Coding, click Cancel.
 This is the checked-in text in bug 52429, I suppose.  I like the way it
describes that you go back and set the character codings.  I think Save can be
incorporated by replacing the "so your recipient may not be able to read it. To
send it anyway" with "and your sent/saved message may become unreadable.  To
send/save it anyway".


Comment 18

17 years ago
The suggestion to change "be" to "become" is a good one
and serves the purpose well.

As to the 2nd suggestion, i.e. going back to the Compose
window, that is just fine. I liked it in the other bug
also when verah suggested it.

This discussion raises a question as to whether the
warning dialog under discussion is something
we are using just for "save" context or something
that is being shared by the "send" and "save" contexts.

nhotta, can you check the code to see if we are sharing
this warning with "send"? If not, we can just use "save".
I'll suggest the revised warning when we know for sure
the status of this warning dialog.

(Assignee)

Comment 19

17 years ago
Yes, he code is shared for send and save.
(Assignee)

Comment 20

17 years ago
Yes, the code is shared for send and save.

Comment 21

17 years ago
How about this:

'The message you composed contains characters not found in the selected
Character Coding, so your message may become unreadable after you send or save 
it. To send or save it anyway, click OK. To return to the Composer window where 
you can choose a different Character Coding, click Cancel.'

Comment 22

17 years ago
The wording sounds good to me.
Thanks for the re-write.

Updated

17 years ago
Keywords: intl, nsbeta1

Comment 23

17 years ago
QA contact to marina.
QA Contact: momoi → marina
(Assignee)

Comment 24

17 years ago
Created attachment 22823 [details] [diff] [review]
patch, wording change
(Assignee)

Comment 25

17 years ago
r=nhotta

Comment 26

17 years ago
sr=erik
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla0.8
(Assignee)

Comment 27

17 years ago
checked in
(Assignee)

Comment 28

17 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 29

17 years ago
the wording is correct now and it fixes bug # 57083 as well, verifying
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.