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...
> 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
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
> 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
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.
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: firstname.lastname@example.org via web11206.mail.yahoo.com; 15 Jan 2002 08:48:03 -0800 (PST) X-RocketRCL: 33624;1;3146689021 Received: from smtp015.mail.yahoo.com (18.104.22.168) by mta553.mail.yahoo.com with SMTP; 15 Jan 2002 08:48:03 -0800 (PST) Received: from unknown (HELO yahoo.com) (22.214.171.124) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jan 2002 16:47:59 -0000 Message-ID: <3C445D3B.email@example.com> Date: Tue, 15 Jan 2002 17:47:55 +0100 From: Shoshannah Forbes <firstname.lastname@example.org> 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: <email@example.com> <3C43FA13.firstname.lastname@example.org> <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>
> 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.
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 :-)
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.
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.