Closed Bug 2820 Opened 28 years ago Closed 23 years ago

"Set Default Encoding" choice very confusing

Categories

(Core :: Internationalization, defect, P2)

All
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: momoi, Assigned: momoi)

Details

(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.
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.
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.
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.
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!
Status: NEW → ASSIGNED
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.
Setting all current Open Critical and Major to M3
Component: Style System → Internationalization
QA Contact: 4110 → 3851
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.
Target Milestone: M3
not an M3 bug. figure out what needs to be done then assign it a milestone.
Severity: critical → major
Priority: P1 → P2
Target Milestone: M4
mark it as P2 and set the target milestone to M4, set the Serverity to major.
Target Milestone: M4 → M5
Moving to M5, I don't think this is a M4 stopper
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → REMIND
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.
Status: RESOLVED → VERIFIED
verified as "remind".
REMIND is deprecated.
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
Given the age of this bug, I'm going to presume the bugs in question were filed and mark "FIXED".
Status: REOPENED → RESOLVED
Closed: 26 years ago23 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.