32945 - Need default character coding in Composer

Status: VERIFIED DUPLICATE of bug 32301

(Core :: Internationalization: Localization, defect, P3)

Description

[Teruko Kobayashi]

If you did not select any character coding in Composer and type Japanese characters, the page is saved as UTF-8 when you save the file.
If you select the characters coding menu and save the file, the file is saved as the character coding as you selected collectly (it will added the
Meta charset).

Steps of reproduce
1. Open Composer
2. Type some Japanese characters
3. Select menu File | Save.. and save as html file
4. Look at the file you saved in step #3
    It does not contains Meta charset.  It was saved as UTF-8.
    We need the some default character coding in Composer.

Tested 2000032206 nblb M15 Win32, MAC, and Linux build.

  
Related issue:Editor charset encoding menu needs UE implementation issue is filed in 7849.

Comment 1

[Frank Tang]

nhotta- can you help to resolve this issue. 
brade- we may need your help.

Comment 2

[nhottanscp]

How 4.x works? Does it have default compose charset?

Comment 3

[Katsuhiko Momoi]

No. It does not. It simply picks up the encoding of the parent page from which the
composer page is opened. By the way, this is one of the items we have on our preference
list and it is mentioned in my spec document, I believe.

Comment 4

[Katsuhiko Momoi]

Please see this spec document for Editor Charset related issues:

http://rocknroll/users/momoi/publish/seamonkey/5_0intleditorui.html

The section which addresses thi sproblem is called: Meaning of Character Encoding menu related actions:
and Item 1 is what this bug is about. We need a default charset for Browser and that should be used
for Composer. This bug can be made a duplicate of that bug.

Comment 5

[nhottanscp]

Momoi san, what is the bug number you mentioned in your last comment?

Comment 6

[nhottanscp]

I read the document mentioned but it does not mention about browser's default 
charset.
Is there a separate document for browser default charset?
Has that been implemented?

Comment 7

[Katsuhiko Momoi]

Currently, the Browser proposal includes an item called
"Fallback Encoding". We need to formalize this either
as a seprate item or make it visible when the menu 
customization is done. 

http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html#definitions

Look under the "Fallback Encoding" subsection.

Comment 8

[nhottanscp]

Do we have a pref value available for the fallback encoding? If so, editor 
jsut need to use it for a new document instead of UTF-8.

Comment 9

[Katsuhiko Momoi]

Yes, it is:

intl.charset.default

Comment 10

[nhottanscp]

Reassing to brade. 
Please cahnge to use the pref value "intl.charset.default" for a new document 
instead of "UTF-8".

Comment 11

[msanz]

Adding jab1

Comment 12

[Katsuhiko Momoi]

I think this bug should go to fergus since "intl.charset.default"
will at least be a workaround for this problem for Beta 1.  

pref("intl.charset.default", "Shift_JIS");

It's not that we are saving into UTF-8 without this 
pref setting. We are right now assuming Latin 1 as the 
default encoding and so when these JPN charcters are saved,
we are using NCRs (i.e. Unicode values in decimal format.)

By setting the above pref, we get the right results we want 
at this point. The full machinery of savings including HTTP Meta-equiv
tag need to be implemnted accoring to Editor spec proposed.

So for this limited problem, I propose to make this into an
L10n bug. There is already an L10n bug for teh Browser default
charset and that bug, Bug 32301, will also take care of this
bug. Fergus, you can mark this bug a dupliacte of that one.

We will file a new bug for Edtior charset related UI implementation
based on the revised spec document.

Comment 13

[Fergus Sullivan]

*** This bug has been marked as a duplicate of 32301 ***

Comment 14

[Teruko Kobayashi]

Verified as dup.