Closed Bug 185123 Opened 22 years ago Closed 11 years ago

View > Character Encoding > Auto-Detect options are confusing

Categories

(Firefox :: Menus, defect, P4)

Product:
Firefox
Component:
Menus
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: elektroschock, Assigned: hsivonen)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [fixed by bug 805374]) 

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

Hard to get. 

Reproducible: Always

Steps to Reproduce:
1. menu view - character codic - auto- detect 
2. selected option is called "(off)"
3.



Expected Results:  
"off" - I don't understand. does it mean that autodetection was off. And will it
be "on" when I choose "chinese"?? what is the purpose of auto-detection?
Also the other options "more" and "customize" make little sense to me.

I also believe this option is not that important. You should reorganize this.
Summary: Usability menu "view" → View > Character Coding > Auto-Detect options are confusing
i agree.  view > character coding > auto-detect > off = checked on my computer,
but phoenix still seems to use whatever coding is specified by the web page.  i
also think the entire character coding submenu is very confusing.
Confirming for developer review.
URL: http://www.mozillazine.org/forums/vie...
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: other → All
It seems like the default should be "Universal" instead of "(Off)". The issue
was brought up in the following thread:

http://www.mozillazine.org/forums/viewtopic.php?t=7554
> Also the other options "more" and "customize" make little sense to me

See Bug 52157

Prog.
Taking QA Contact as designated owner of Firebird-Menus. Sorry for bugspam.
QA Contact: asa → bugzilla
Firefox has the ambition to be streamlined, simple, and polished.
Nominating this for 1.0
Flags: blocking1.0?
Summary: View > Character Coding > Auto-Detect options are confusing → View > Character Encoding > Auto-Detect options are confusing
-ing.
Flags: blocking1.0? → blocking1.0-
Hardware -> All

Prog.
Hardware: PC → All
Blocks: 254868
Also see Bug 301190 - "Better documentation for Character Encoding -> Auto-Detect"

Prog.
Assignee: firefox → nobody
QA Contact: bugzilla → menus
*** Bug 332681 has been marked as a duplicate of this bug. ***
Severity: enhancement → minor
Priority: -- → P4
Target Milestone: --- → Future
I am beginner and I would like to work on this bug.can someone please assingn this bug for me?
Assignee: nobody → athirasnamby
Hi Athira,

You need to change "(off)" in [1] to "Universal".

To see the change, you could just build toolkit/locales/ with `mach build toolkit/locales/` and `mach run` to see the changes.

Good Luck!

[1]: http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/charsetMenu.dtd#10
Whiteboard: [mentor=darkowlzz]
No, no, not at all. "Universal" is going to be killed.
I think this bug is obsolete due to recent massive changes to Character Encoding menu.
(In reply to Masatoshi Kimura [:emk] from comment #14)
> No, no, not at all. "Universal" is going to be killed.
> I think this bug is obsolete due to recent massive changes to Character
> Encoding menu.

In that case, I am letting someone else take over this :)
Whiteboard: [mentor=darkowlzz]
Bug 805374 made both the Auto-Detect submenu and the Character Encoding menu in general less confusing.

I think we should either consider the menu adequately non-confusing as of Firefox 28 and mark this FIXED or concede that it's not going to become less confusing until/unless we get rid of the menu eventually some day: i.e. WONTFIX. (I think we have a pretty good chance of getting rid of the remaining Russian and Ukrainian options and then coupling Japanese autodetection with Shift_JIS fallback and getting rid of autodetection UI.)

Trying the FIXED interpretation.
Assignee: athirasnamby → hsivonen
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 805374]
I think that the first thing for Character Encoding Autodetect to be less confusing is ti say what it does.
Assuming that it means that any indication of a character set is ignored ans that it is guessed by the contents...
Character Encoding Autodetect is normally not needed because a page MUST specify the encoding it uses.
Using it instead of reporting an error to a webmaster is causing the webmaster to continue to make the same errors.
Also, picking the character code from the HTTP request is an error because the contents of the page MUST specify the encoding, it knows better than an Apache server and the browser won't update the page when it's written to a file.
The only case where character encoding mangling is necessary is when, for example, displaying a text file of which the character set is specified nowhere and, of course, displaying the page correctly before reporting to the webmaster.
(In reply to André Pirard from comment #17)
> I think that the first thing for Character Encoding Autodetect to be less
> confusing is ti say what it does.
> Assuming that it means that any indication of a character set is ignored ans
> that it is guessed by the contents...

It means: If the type of the document is text/html or text/plain and there is no character encoding label on the HTTP layer or inside the document (in the text/html case) and there is no BOM at the start of the document, assume the language of the page is the one selected from the Auto-Detect menu and make a guess based on the contents of the file given that language assumption.

How would you make the menu "say" this?

Note: My current belief is that we don't actually need the Russian and Ukrainian autodetectors. Once the only autodetector we have is the Japanese one, we should probably not bother the user about its existence but couple it with choosing Japanese in Preferences: Content: Advanced: Fallback Character Encoding [or choosing "Default for Current Locale" in the Japanese localization]. Therefore, I think activity to get rid of the Russian and Ukrainian detectors (bug 845791) would be more productive than activity to polish the menu.

> Character Encoding Autodetect is normally not needed because a page MUST
> specify the encoding it uses.

Correct.

> Using it instead of reporting an error to a webmaster is causing the
> webmaster to continue to make the same errors.

Indeed.

> Also, picking the character code from the HTTP request is an error because
> the contents of the page MUST specify the encoding, it knows better than an
> Apache server

Indeed, Ruby's Postulate generally holds. Unfortunately, HTTP disagreed and it's too late to change that, because it would break pages that currently work due to Ruby's Postulate not being true for them.
http://www.intertwingly.net/slides/2004/devcon/69.html

And besides, all browser now agree on the precedence of HTTP over <meta>, so it's not worthwhile to break interoperability.

> and the browser won't update the page when it's written to a
> file.

Firefox is supposed to if you choose the "complete" option in Save As...

> The only case where character encoding mangling is necessary is when, for
> example, displaying a text file of which the character set is specified
> nowhere

Or when displaying an HTML file whose character encoding is specified nowhere. :-(
André Pirard added the following comment to Launchpad bug report 206884:

On 2014-01-21 07:45, Henri Sivonen wrote :
> (In reply to André Pirard from comment #17)
>> I think that the first thing for Character Encoding Autodetect to be less
>> confusing is ti say what it does.
>> Assuming that it means that any indication of a character set is ignored ans
>> that it is guessed by the contents...
> It means: ...
>
> How would you make the menu "say" this?
Language to [auto]detect encoding for
Language to suit [auto-detection]
... something like that

The key hint is to understand that it's a language.  I'm the reporter of
this bug and you made me discover this explanation after 5 years.  I,
and everybody according to the bug title, had looked for it all over the
place in vain.
Pity there are no HTTP links on system menus. Graphic things (No doc.
Any questions?) badly need it.

Please note that "Universal" is not a language and that I still do not
understand what that means. My guess was that it meant utf-8 but what
would that mean? it's not a language either.
Also, (Off) could be "no encoding auto-detection" to make it very clear
what we're about.

Note: I did not report this problem at all.  See Description and read below.
Alexander Sachs changed the subject to mean a problem of his.
Strange doings.  I opened another bug to be able say what I meant.
I was accused of saying things that did not happen (but that some 6
other persons met).
I was even accused of tweaking the encoding identification by forcing
the encoding of the preceding page in a test.
As if the encoding of one page influenced the encoding of the next one.
I finally shuddered and turned away to something else.
>> Also, picking the character code from the HTTP request is an error because
>> the contents of the page MUST specify the encoding, it knows better than an
>> Apache server
> Indeed, Ruby's Postulate generally holds. Unfortunately, HTTP disagreed and it's too late to change that, because it would break pages that currently work due to Ruby's Postulate not being true for them.
> http://www.intertwingly.net/slides/2004/devcon/69.html
>
> And besides, all browser now agree on the precedence of HTTP over
> <meta>, so it's not worthwhile to break interoperability.
That is wrong.
MIME was intended to describe the single character set of a file that
does not provide it.
HTML self-describes it and can contain many character sets that MIME is
unable to describe.
It's like saying "he speaks English" of someone who says "Je parle
français ik spreek vlaams и я говорю по русский"
>> and the browser won't update the page when it's written to a
>> file.
> Firefox is supposed to if you choose the "complete" option in Save As...
Right and you made me notice it.
But why is it correct with a "complete" page and surprisingly incorrect
with a "HTML" one?
In fact, I met so many character handling bugs in my life that I no
longer care reporting anything.
Like that craze of removing http:// from Firefox URL bar.  This caused a
tons of bugs and I still have a stock of 12 or so.  Why the hell do that
when it was going so well, everyone in the street knew what http:// was
and started asking why one removed it?

>> The only case where character encoding mangling is necessary is when, for
>> example, displaying a text file of which the character set is specified
>> nowhere
> Or when displaying an HTML file whose character encoding is specified
> nowhere. :-(
Sorry to say that if a HTML file contains no specification it *must* be
ISO8859-1.
That default has been decided one day and must be respected to remain
compatible with existing pages.
I was perfectly astounded by the W3C validator which stated that it was
using UTF-8 by default.
My bug report was that Firefox displayed the wrong character set, and it
was probably only when there was no specified character code.
I'm not sure that bug is corrected.
I see much less such errors, but also less pages without a charset
specification.










-- 
http://launchpad.net/bugs/206884
(In reply to Launchpad from comment #19)
> André Pirard added the following comment to Launchpad bug report 206884:
> > How would you make the menu "say" this?
> Language to [auto]detect encoding for
> Language to suit [auto-detection]
> ... something like that

That's unusually wordy for a submenu label. :-(

> Please note that "Universal" is not a language and that I still do not
> understand what that means.

The people who understood what it *really* meant can probably be counted with the fingers of one hand. That's one of the reasons why I removed that item from the menu.

> Also, (Off) could be "no encoding auto-detection" to make it very clear
> what we're about.

I wouldn't be opposed to re-labeling "(Off)" to something like "No Detection".
> That's unusually wordy for a submenu label. 
Striving to use a single word instead of three is indeed a usual,
prominent reason why people don't understand what the software does.  As
well as putting menu entries where the programmer thinks they must be
and not wondering where the user will look for them. Putting the same
menu entry in several places is not idiot at all if the user is liable
to look for it in different places. Yet, I don't remember having ever
seen that.
A typical case is the Firefox Preferences menu which is under Tools in
Windows and Edit in Unix.  Most of the time, support personal knows
absolutely nothing  about that that and you guessed that the discussions
can be very funny.  I would put Preferences under both.
Unusual does not mean Inappropriate.  It even often means Progress.
You need to log in before you can comment on or make changes to this bug.