214729 - intl.fallbackCharsetList.ISO-8859-1 default value should be ISO-8859-15

Status: RESOLVED WONTFIX

(MailNews Core :: Internationalization, defect)

Description

[Nicolas PENINGUY]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030726
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030726

The default value of the intl.fallbackCharsetList.ISO-8859-1 should be
ISO-8859-15, not windows-1252.

Reproducible: Always

Steps to Reproduce:
1. Reply to a ISO-8859-1 message
2. Add the EURO symbol
3. Send the message


Actual Results:  
The message is sent in the windows-1252 encoding, and people are laughing at you.

Expected Results:  
The message should be sent in the iso-8859-15 encoding.


I'm not a specialist of that, but I believe that windows-1252 is a proprietary
stuff of Microsoft, while ISO-8859-15 is the standard...

Comment 1

[marina]

my iunderstanding is that Iso-8859-15 aka Latin-9 was introduced in a wake of
euro (and includes some other french and finnish chars, that's all compare to
8859-1) but win-1252 has a wider range that's why we fallback to 1252. Cc'ing
Naoki, Bob to correct if i am wrong.

Comment 2

[Simon Montagu :smontagu]

This has been discussed extensively already in bug 109342: see especially bug
109342 comment 35 for some of the disadvantages of ISO-8859-15.

You can always change the pref yourself if you want to go with ISO-8859-15 anyway.

Comment 3

[Jungshik Shin]

I agree with Simon(and Kat in the cited comment).  Both windows-1252 and
iso-8859-15 are registered with IANA  and the former has an edge over the latter
that it's   upward compatible with iso-8859-1. If windows-1252 hadn't been
registered, my opinion would be different. Besides, it's not hardcoded but can
be changed. With 'about:config', it's rather easy. 

Idealy, we'd have a pop-up dialog in which users are warned that an outgoing
email has chars. outside the repertoire of the current charset (as is currently
the case for other similar cases) and prompted to choose a charset with a
broader coverage. Apparently, it's decided that the second part be not
implemented for some reason (I didn't read all the comments in bug 109342)