2820 - "Set Default Encoding" choice very confusing

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P2)

Description

[Katsuhiko Momoi]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #70451
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=70451
Imported into Bugzilla on 02/01/99 18:01)

** Observed with 6/5 Win32 and 6/4 Mac builds **

1. The "Set Default Encoding" behavior is different across different windows.
   For example, only the browser window remembers it from session to
   to session.  So if you quit as the encoding is set to Japanese, but
   the default encoding of Western, the next time you start browser,
   you will open with the Western encoding.

   With the Composer and Mailbox folder windows, this is not true.  Even
   if you set the default encoding to Western, the next time you open
   the Mailbox window, it will be in Japanese if you quit after you
   temporarily set the encoding to Japanese.

   Thus, in the Mailbox and Composer Windows, "set default encoding"
   has no meaning.

2. Win32 and Mac are different even when it comes to the browser window with
   regard to "set default encoding".

   For example, on Windows, all subsequent new brower windows will follow the
   'global default' set by the 'set default encoding', but on Mac all subsequent
   new browser windows will follow the temporary encoding you have chosen
   before you opened a new browser window.

3. For Composer window, all subsequent windows will inherit the last
   set encoding, not the 'set default encoding' choice.

4. "Set Default encoding" menu is inconsistent between Mac and Windows
    for the Composer window.  Mac has the menu item but Windows does not.

The above state of affairs is too confusing for average users.

Can we do something about this?  Because this is too confusing, I would
like our group to have a consensus before we implement any more changes.
It is not right that no one person really knows how this vital function for
I18n works in its entirety.

Comment 1

[Frank Tang]

I think this is really UI design issue and I don't believe we can do anything to
change this kind of design issue in this late stage.

Comment 2

[Katsuhiko Momoi]

I didn't expect the fix to be made but I wanted to raise the issue so that
we will address this kind of problem early on the next time.

I did find out why the Windows Browser was opening to "ISO-8859-1" no
matter what setting I chose for the encoding prior to opening a new page.
It turns out that my default page is ftang's Unicode 10 paper's Page 1.
This page has a Meta tag set to ISO-8859-1!  So, no matter what setting
you change it to, the subsequent window will open to "ISO-8859-1" since that
is the meta tag on the home page.

Of course, if you open a Masilbox window with a different encoding, and
open a new browser window from there, it will change to that encoding rather
than to the Meta tag one.

So, this eliminates the inconsistency between Windows and Mac as far as
the browser is concerned.

Then, what I have remaining on this issue are:

1. "Default" encoding menu choice should not be there for Mac's
    Composer and Mailbox folder Windows.
2. "Default" encoding does seem to be functional on Composer window.
    You can set the default there, and change it to something else,
    quit Communicator and re-boot to open to Composer.  If you do that,
    it will open to the default choice rather than to the last set
    choice.

Comment 3

[Katsuhiko Momoi]

Reassigning it to momoi for review and proposal for 5.0.
Part of the encoding menu re-vamping that needs to be proposed.
Finish before the UI freeze.

Comment 4

[leger]

kat, I am clearing out 5.0 bugs and moving to Bugzilla.  If you still want to
correct this, could you please close out this bug and move to Bugzilla?  Thanks!

Comment 5

[Katsuhiko Momoi]

I'm going to consider this as a review item for the new
Mozilla client under development. What this means is that
when Browser and Mail components are reasonably ready for
international testing, I will review the problems
mentioned here (orginally filed in 6/97). Some of the behavior patterns
changed during the Communicator 4 development phases.

Accepting this bug until the initial review is done, at which
time, it will be re-assgined to an appropriate i18n person.

Comment 6

[leger]

Setting all current Open Critical and Major to M3

Comment 7

[Christine Hoffman]

This bug was categorized under Style System' component which is incorrect. I
have taken my best guess and changed the component to 'internationalization' and
reassigned qa contact.

Comment 8

[chris hofmann]

not an M3 bug.  figure out what needs to be done then assign it a milestone.

Comment 9

[Frank Tang]

mark it as P2 and set the target milestone to M4, set the Serverity to major.

Comment 10

[msanz]

Moving to M5, I don't think this is a M4 stopper

Comment 11

[Katsuhiko Momoi]

I'm going to resolved this bug as fixed/remind.
Some of these are still issues to think about for 5.0,
but most of the questions need to be re-phrased in 5.0 terms.
So rather than tinkering with this this bug, I'll open a series
of new bugs to think about for 5.0 later.

Comment 12

[Katsuhiko Momoi]

verified as "remind".

Comment 13

[Christopher Hoess (gone)]

REMIND is deprecated.

Comment 14

[Christopher Hoess (gone)]

Given the age of this bug, I'm going to presume the bugs in question were filed
and mark "FIXED".

Comment 15

[Teruko Kobayashi]

Verified.