Only one hebrew encoding is available in the mail/news encoding list for composing mail

RESOLVED WONTFIX

Status

()

Core
Layout: Text
RESOLVED WONTFIX
16 years ago
10 years ago

People

(Reporter: Shoshannah Forbes, Assigned: mkaply)

Tracking

Trunk
PowerPC
Mac System 9.x
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020111
BuildID:    20020211108

only one Hebrew encoding is avalible in the mail/news encoding list, both for
reading and for composing mail, and it is NOT mac Hebrew (what you would want to
use when writing Hebrew on the mac).

Reproducible: Always
Steps to Reproduce:
1. start new email 
2. try to choose Hebrew encoding

Or: 
in the prefrences, go to the list to shoose defoult Hebrew composing encoding

Actual Results:  only logical Hebrew (ISO-8859-I) is in the list. Everything
else is missing

Expected Results:  All Hebrew encodings should be avalible

since I am on a Mac, I should be able at least to choose Mac Hebrew as my
encoding...

Comment 1

16 years ago
> Actual Results:  only logical Hebrew (ISO-8859-I) is in the list.
> Everything else is missing

Shoshana, this is according to the spec. We are promoting only one
encoding for mail send. For Hebrew, that is logical Hebrew (ISO-8859-I).
This is a general policy in Mozilla and a sound one since we should not
be proliferating encodings used for a script. I wish we can do the same
for web pages but for mail, we should use only one standard encoding 
for all platforms. 
You need not worry about Mac or Linux. While inputting on Mac, the
platform will use MacHebrew but Mozilla will transcode that into
ISO-8859-I as it sends out to the Internet. This is how it works on
all other language platforms in case the platform encoding and the
mail send encoding are different. 

Marking it as Wontfix.

Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 2

16 years ago
So if i sent mail to someone whose mail client only supported visual, what we 
that person do?
Summary: Only one hebrew encooding is avalible in the mail/news encodings list for composing mail → Only one hebrew encoding is available in the mail/news encoding list for composing mail

Comment 3

16 years ago
s/we/would/

Comment 4

16 years ago
> So if i sent mail to someone whose mail client only supported visual, 
> what would that person do?

I'll let Simon answer this question definitively but I will note 
that "informational" RFC 1555 for Hebrew Internet Messages recommends 
ISO-8859-8. 

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1555.html

For web pages ISO-8859-8 and ISO-8859-8-I seem to be equivalent, but
the following W3C page points out that this is different for
Internet Mail:

http://www.w3.org/International/O-charset-lang.html

If this is true, we may have to change the default send encoding
to ISO-8859-8. 

But one thing will not change -- we should not support multiple
mail send encodings for Hebrew unless there is a compelling reason
for it.
QA Contact: giladehven → zach

Comment 5

16 years ago
timeless, in all language scripts where there is an agreed on
standard encoding for mail, it is fair to ask software designers
to support that standard encoding. If the software you're using
does not support it, then users should not use that software. 

For example, no reputable Japanese mail software makers will 
support Shift_JIS but not ISO-2022-JP -- the latter is
the mail standard for Japanese. If such software existed, no one
will use it and it is fair for us to reject any support for such
software.
> So if i sent mail to someone whose mail client only supported visual, 
> what would that person do?

Get a new mail client :-P
You could also ask: "If I design web pages in logical, how could someone read
them if they had a web browser that only supported visual?" In general, our
policy on logical/visual is the classic "be strict when sending and tolerant
when receiving".

The w3c page quoted in comment 4 seems to be incorrect.
http://www.w3.org/TR/html4/struct/dirlang.html#bidi88598 says "Because HTML uses
the Unicode bidirectionality algorithm, conforming documents encoded using ISO
8859-8 must be labeled as 'ISO-8859-8-i' ... the value "ISO-8859-8" implies that
the document is formatted visually."

It's true that by choosing ISO-8859-8-i as default encoding for mail we are not
conforming to the letter of RFC 1555, but even though (AFAIK) RFC 1555's
recommendation to use visual ordering has never been officially superseded, it
is very old (1993) and today should be considered as deprecated.
(Reporter)

Comment 7

16 years ago
If this is so, then why when I replay to a windows-1255 HTML email in HTML
Mozilla marks it as windows 1255? Do we have a bug here? Should I file it?
see example header from a recent email:
--
From - Tue Jan 15 17:48:12 2002
X-UIDL: 6dec5ee407e7c727f64be01d06f50331
X-Mozilla-Status: 0011
X-Mozilla-Status2: 10000000
X-Apparently-To: xslf@yahoo.com via web11206.mail.yahoo.com; 15 Jan 2002
08:48:03 -0800 (PST)
X-RocketRCL: 33624;1;3146689021
Received: from smtp015.mail.yahoo.com (216.136.173.59)
  by mta553.mail.yahoo.com with SMTP; 15 Jan 2002 08:48:03 -0800 (PST)
Received: from unknown (HELO yahoo.com) (193.106.171.3)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jan 2002 16:47:59 -0000
Message-ID: <3C445D3B.9070501@yahoo.com>
Date: Tue, 15 Jan 2002 17:47:55 +0100
From: Shoshannah Forbes <xslf@yahoo.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020111
X-Accept-Language: en-us, he
MIME-Version: 1.0
To:< removed for privacy reasons>
Subject: Re: At last...
References: <009601c19d9f$daafcdc0$40294a84@haifa.ac.il>
<3C43FA13.5060900@yahoo.com> <009f01c19de0$1528e000$6a5f003e@sharon>
Content-Type: multipart/mixed;
 boundary="------------050001030105050208020001"

This is a multi-part message in MIME format.
--------------050001030105050208020001
Content-Type: text/html; charset=windows-1255
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
=E4=E9=E9 =F9=F8=E5=EF.<br>
<rest of email snipped>

Comment 8

16 years ago
> If this is so, then why when I replay to a windows-1255 HTML 
> email in HTML Mozilla marks it as windows 1255?

This is called charset reflection and is according to the spec.
The reply mail mimic the original encoding of the sender. 
In the case of windows-1255 mail, we can do one of 2 things:

1. Manually correct the compose window encoding to ISO-8859-8-I.

or 

2. Let it go out as Windows-1255.

Let's assume that ISO-8859-8-I is the standard mail encoding -- needs
to be defined somewhere like in an RFC, if so, you should do 1.
If Hebrew uses both ISO and Windows encodings, then we recommend
ISO encoding when we generate it but for reply we go along with 
the original sender's encoding. 

So there is no bug here, either. I hope that there is an agreement to use
only one encoding for mail for Hebrew. There is such an agreement for
lang scripts like Japanese, Korean, Traditional Chinese and Simplified
Chinese. The situation is less clear with ISO languages. I think it is
up to standards body for each language script to come with a single
encoding which will simplify everyone's life.

(Reporter)

Comment 9

16 years ago
Ok, that fine with me, as long as mozilla does the convertion correctly :-)
since ISO-8859-8-i is a subset of windows-1255, marking a ISO-8859-8-i  
document  as windows-1255 should not be problematic anyway.
I was just afriad that this change was a symptom of something going 
wrong....
Thanks for the education :-)

Comment 10

16 years ago
Some Windows products tend to lock you into Windows specific **internal** 
encodings  for external uses like the Internet Mail. ISO encodings are 
usually subsets of such encodings (also of Mac encodings) works on all 
platforms and that is why Netscape Communicator and now Mozilla promote 
the use of ISO encodings as opposed to platform specific encodings. This 
has been the difference between MS and NS approaches to this issue. 

Users need to educate each other about what encoding to use for 
their own script. By doing so, even MS may not be able to ignore it.
This is why most people use KOI8-R for Russian mail even though Web 
pages may use Windows-1251. 

For mail, interoperability requirements are more stringent because of
plain text mail. For HTML web, you can use HTML entities to cover up for 
characters outside of your encoding range. You can do the same for
HTML mail but not for plain text mail. Windows-1255 only characters
will show up as ? marks in plain text.
Product: MailNews → Core

Updated

10 years ago
Component: MailNews: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.