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.

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.

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.

Firefox has the ambition to be streamlined, simple, and polished. Nominating this for 1.0

-ing.

Hardware -> All Prog.

Also see Bug 301190 - "Better documentation for Character Encoding -> Auto-Detect" Prog.

*** Bug 332681 has been marked as a duplicate of this bug. ***

I am beginner and I would like to work on this bug.can someone please assingn this bug for me?

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

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 :)

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.

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.