Closed
Bug 2820
Opened 28 years ago
Closed 23 years ago
"Set Default Encoding" choice very confusing
Categories
(Core :: Internationalization, defect, P2)
Tracking
()
VERIFIED
FIXED
M5
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.
Comment 1•28 years ago
|
||
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.
Assignee | ||
Comment 2•28 years ago
|
||
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.
Assignee | ||
Comment 3•28 years ago
|
||
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!
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•26 years ago
|
||
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.
Updated•26 years ago
|
Component: Style System → Internationalization
QA Contact: 4110 → 3851
Comment 7•26 years ago
|
||
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.
Updated•26 years ago
|
Target Milestone: M3
Comment 8•26 years ago
|
||
not an M3 bug. figure out what needs to be done then assign it a milestone.
Updated•26 years ago
|
Severity: critical → major
Priority: P1 → P2
Target Milestone: M4
Comment 9•26 years ago
|
||
mark it as P2 and set the target milestone to M4, set the Serverity to major.
Comment 10•26 years ago
|
||
Moving to M5, I don't think this is a M4 stopper
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → REMIND
Assignee | ||
Comment 11•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 12•26 years ago
|
||
verified as "remind".
Comment 14•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•