982703 - fallback character encoding doesn't work when opening text file in encoding ibm-862

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect)

Description

[queency jones]

fallback character encoding different from the default doesn't work whenever using the  ibm-862 encoding
whenever open .txt files

Comment 1

[Masatoshi Kimura [:emk]]

We don't support ibm862 anymore per the encoding standard.

Comment 2

[queency jones]

The ibm862 handle my .txt file well when changed manually 
 but 
the fallback option doesn't serve its purpose! 
Its purpose according to my understanding is to open .txt files , in the noted encoding .
i.e ibm862

Comment 3

[Masatoshi Kimura [:emk]]

The ibm862 will be removed from the encoding menu soon.

Comment 4

[Henri Sivonen (:hsivonen)]

It is unclear to me if "fallback character encoding" in this report means what we usually mean when we say "fallback encoding". The usual thing we mean should never be an IBM* encoding. Reporter, what do you mean?

Also, this report lack a URL of a real broken site. Is there one?

Comment 5

[queency jones]

I use firefox in order to open text files.
My legacy system produces text files  in encoding cp862 which is (ibm-862) old encoding.
The fallback encoding from my perspective is like this:

when ever firefox doesn't get encoding (charset html tag) he should use the
encoding that marked/appeared  in the fallback character encoding text box!

in my firefox fallback character encoding i choose (ibm-862)

now when ever i open text files (which lack the html charset tag) 
i expect firefox to use the ibm-862 encoding.

Comment 6

[Masatoshi Kimura [:emk]]

The ibm862 encoding has been removed from the fallback encoding dialog since Firefox 28.

Comment 7

[queency jones]

This is very unpleasing to hear and could affect my busyness strategy.
Why you drop ibm862 support ?
What can i do in order to support it ?

Comment 8

[Masatoshi Kimura [:emk]]

We are implementing encodings defined in <http://encoding.spec.whatwg.org/>. You will have to file a spec bug from <https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=Encoding> and convince the spec editor to add the encoding.

Comment 9

[queency jones]

this comment posted as a bug in https://www.w3.org (Bug number  25136 )
please guide me how to support this feature.

quote
-firefox 28 had dropped support for ibm cp862 encoding.

-This is very important feature for my busyness.

-A lot of my clients need this kind of support and i expand this 
-support to others as well.

-many legacy systems create text files with encoding cp862
-i have turned many system to work in firefox thus can read
-those text files properly regardless the operation system running.

-based on this feature i have transfer clients from windows to linux
-as well.

-Dropping this support will hurt firefox as a leading 
-open source browser for me and make me think again on what browser
-should i based my busyness on from now on.

-I hope you consider again about that feature which i assure you 
-make just good for firefox ,gnu/linux and the whole open source 
-comunity.
end of quote

Comment 10

[Henri Sivonen (:hsivonen)]

(In reply to queency jones from comment #5)
> My legacy system produces text files  in encoding cp862 which is (ibm-862)
> old encoding.

In https://www.w3.org/Bugs/Public/show_bug.cgi?id=25136#c2 you refer to legacy systems belonging to others instead of a legacy system belonging to you. Which is it?

> The fallback encoding from my perspective is like this:
> 
> when ever firefox doesn't get encoding (charset html tag) he should use the
> encoding that marked/appeared  in the fallback character encoding text box!
> 
> in my firefox fallback character encoding i choose (ibm-862)

IBM862 is not coming back to the Fonts subwindow of the Content pane of the Preferences window. If it did, chances are that users who don't know enough about encodings would break compatibility with windows-1255 legacy Hebrew content depending on a proverbial coin flip.

I'm marking this WONTFIX in the sense that IBM862 is not coming back to the fallback encoding UI. However, if IBM862 was added to the Encoding Standard, we'd restore support for pages that *declare* IBM862. (Your description makes it look like that your legacy system didn't even declare IBM862.)

(In reply to queency jones from comment #7)
> This is very unpleasing to hear and could affect my busyness strategy.

In general, if your business strategy depends on DOS encodings (or non-UTF-8 encodings more generally), you are going to have a bad time.

> Why you drop ibm862 support ?

We are trying to get a consistent platform across browsers and to remove unnecessary bloat, though removing 8-bit encodings isn't that much of a bloat win (removing support for unnecessary multi-byte encodings is a bloat and security win, though).

Since Chrome and Presto-Opera had gotten away with not supporting IBM862 and, despite that, Chrome is the desktop browser with the largest usage share in Israel, we assumed that support for IBM862 is not necessary to have sufficient Web compatibility.

Now after the removal, it has also turned out that browser that did support IBM862 didn't agree on whether it's a logical or visual encoding, which further suggests that IBM862 support isn't critical for Web browser success.

> What can i do in order to support it ?

Since it appears that you only need to deal with text/plain output and don't need to deal with form submissions, I suggest putting an nginx reverse proxy in front of the legacy system and configuring nginx to to perform conversion from IBM862 to ISO-8859-8. See http://nginx.org/en/docs/http/ngx_http_charset_module.html . (Note that I'm not 100% sure that the nginx recoding feature works together with the nginx proxying feature.) I suggest then proceeding to perform a migration to UTF-8-encoded logically ordered Hebrew. Chrome developers have shown intent to remove support for visual Hebrew (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nhCfOhRV-I4), so you shouldn't expect ISO-8859-8 support to stay around forever.