92499 - View Menu not obvious place for character coding in compose

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, enhancement, P4)

Description

[David Woolley]

The character coding menu is presented in the view menu when composing an
email.  I considered this to be the last place to look for such a feature during
composition as it doesn't even affect what is being viewed.  I guess that the
logic is that the item should be in the same place for all modes.

Incidentally, Exchange does some guessing on character coding when you send
email, although it seems to use GB2312 for Chinese when one might want Big5
(Outlook ~98 doesn't allow the use of input methods and doesn't support
international headers, but does support cut and paste of international text, on
NT.  I was trying Mozilla because it does allow input methods and international
headers.)

Comment 1

[Frank Tang]

Should we move from "View" menu to "Options" menu instead ?

Comment 2

[Frank Tang]

UI stuff, move to m9.5. too risky for m9.4

Comment 3

[[e-mail] (away - not reading bugmail)]

I'm futuring it for now - we have way too much for the next few release cycles. 
David, could you come up with a UI proposal? We could have it reviewed within 
the Mozilla organization.

Comment 4

[[e-mail] (away - not reading bugmail)]

accepting - leaving milestone on "future"

Comment 5

[Frank Tang]

jbetak's contract is up. Bulk move bugs to ftang

Comment 6

[Eugene Savitsky]

I belive this is the same issue as bug 58143.

Comment 7

[Mike Cowperthwaite]

I think this is a UI issue with the Compose window rather than a true i18n 
issue.

I think comment 1 is right on: the character encoding should be under Options 
rather than View.  Note that the structure of this menu, as well as its meaning, 
is completely different from the one seen in the browser, 3pane and standalone 
message windows.  (The Composer program might benefit from using this sort of 
Encoding menu, too.)

Its placement under View probably contributed to the apparent misunderstanding 
in bug 122420.

Comment 8

[Jungshik Shin]

Attachment: patch (move Char. Encoding to Options)

It's uploaded to bug 227265 (thunderbird bug) and I'm moving it here.

Comment 9

[Jungshik Shin]

Attachment: screenshot

Comment 10

[Jungshik Shin]

Comment on attachment 158603 [details] [diff] [review]
patch (move Char. Encoding to Options)

acess key for character encoding is the same as that for 'select address'. I
think we have to change the latter to 'a'.

Comment 11

[Jungshik Shin]

Attachment: patch v2

'Options | Select Address' is now assigned the access key 'a' instead of 'c'.

Comment 12

[Jungshik Shin]

Comment on attachment 158610 [details] [diff] [review]
patch v2

asking for r/sr.

Comment 13

[Jungshik Shin]

Attachment: patch v2

Per bug 227265 comment #13 and bug 227265 comment #11, I made a new patch.

Comment 14

[Jungshik Shin]

Attachment: screenshot

'Character Encoding' is now between 'Priority' and 'Send a copy to'

Comment 15

[Jungshik Shin]

fix checked into the trunk. it turned out that I patched a dummy file for TB. I
uploaded a new patch to bug 227265 for TB, which is independent of the patch for
the mozilla suite.

Comment 16

[Mike Cowperthwaite]

Verified fixed with
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040924