232722 - change 'character coding' to 'character encoding'

Status: RESOLVED FIXED

(Core :: Internationalization, enhancement)

Description

[Jungshik Shin]

As I recall, 'character coding' was chosen ('invented') to avoid the confusion
around 'charset', 'character set', 'coded character set',  'encoding',
'character encoding', 'code page', 'character set encoding scheme' and so forth.
However, W3C consistently uses the term 'character encoding' [1] and MS IE,
Opera, Konqueror/Safari all use 'encoding'. Given these, wouldn't it be better
(user-friendly) to join them espeically considering that we want to lure MS
IE/Safari users to Mozilla/Firebird (one fewer change in migration)?   




[1] http://www.w3.org/TR/charmod/#sec-Digital

Comment 1

[Katsuhiko Momoi]

(In reply to comment #0)
> As I recall, 'character coding' was chosen ('invented') to avoid the confusion

The term "character coding" predates Mozilla and HTML 4. As I recall, this term
was advocated by Alan J. Flavell. You might find the following page and a couple of
links from it useful in this connection:

http://ppewww.ph.gla.ac.uk/~flavell/charset/

> around 'charset', 'character set', 'coded character set',  'encoding',
> 'character encoding', 'code page', 'character set encoding scheme' and so forth.
> However, W3C consistently uses the term 'character encoding' [1] and MS IE,
> Opera, Konqueror/Safari all use 'encoding'. Given these, wouldn't it be better
> (user-friendly) to join them espeically considering that we want to lure MS
> IE/Safari users to Mozilla/Firebird (one fewer change in migration)?   
> 
> [1] http://www.w3.org/TR/charmod/#sec-Digital

As stated above, the term "character encoding"/HTML4.0 existed when this menu
wording was considered during the summer of 1999. I think we should first review
the discussions that took place 
about this issue. The following two comments by Alan J. Flavell are informative
in his 
regard:

http://www.geocrawler.com/archives/3/113/1999/6/100/2329814/
http://www.geocrawler.com/archives/3/113/1999/6/100/2344104/

One other factor that was considered but not discussed on mozilla-18n was that
that the mneu
was not just for encodings. It also houses auto-detection module selection. The
term "character
encoding" has strong association with specific character encoding schemes like
iso-2022-jp. In
this sense, "chaarcter coding" feels like a general term that can subsume
"character encoding"
and might be more appropriate for a menu that includes both a list of encoding
names and 
auto-detect modules.

Comment 2

[Jungshik Shin]

>> As I recall, 'character coding' was chosen ('invented') 

> The term "character coding" predates Mozilla and HTML 4. As I recall, 
> this term was advocated by Alan J. Flavell.

 OK. It's not invented by Mozilla, but still it doesn't sound familiar to me. He
doesn't give any reference to the term (as far as I can tell), which may be an
indication that it's of his own 'invention'. 

Alan J. Flavell's only argument against 'encoding' (for view menu [1]) is :

> a.k.a "encoding", but this term risks confusion with a
> different protocol layer, such as encoding with base-64, binhex,
> uuencoding etc.). 

That might be valid, but not so strong as to preclude our use of (almost
'standard') character encoding. Base64/Quoted-printable, uuencoding, binhex and
so forth have to be 'invisible' from end users as much as possible and they're
indeed rather 'invisible' on the internet these days. Besides, preprended with
'character', the tern 'encoding' is not so likely to be  confused with
'transfer-encodings' like Base64/QP/binhex/uuencoding. While reading his
postings with the term 'coding' used throughout, I felt rather 'uncomfortable'.
That's probably because I had never seen the term 'coding' be used for UTF-8,
UTF-7, UCS-2 (for that matter, I had never seen it outside Mozilla for other
character encodings, either)  before reading his posting. The term 'encoding'
was definiltey far more widely used than 'coding' in that context. Ken Lunde
used the term in his CJK.inf and Japanese information processing that was
followed by CJKV Information Processing. Unicode 3.0 (2000) used the term. I
don't know what Unicode 2.0 used (I should have kept Unicode 2.0), but I think
the chance is very low that it used 'coding' in place of 'encoding'. IBM and MS
people always prefer 'code page' so that they're not relevant when it comes to
choosing between 'encoding' and 'coding'. In Unix, 'code set' was/is used (see
the manual page of 'iconv'). Againt, that's not pertinent. 

Alan wrote that Martin Duerst also favored 'character coding'. I guess he
doesn't any longer :-) judging from W3C CHARMODE. Back in 1999, there may have
been a valid reason to favor the term, but it appears that we have reached
consensus on 'character encoding' since. Unicode, W3C, and Java[3] (and IETF in
some RFCs) use 'character encoding'.  

As for 'autodetection', I don't see a big problem. What's auto-detected is
'character encoding' so that it seems to me pretty natural that 'character
encoding' menu houses various auto detection modules as well as actual character
encoding names. 


[1] He also dealt with the term to use for Edit | Preference | Appearance |
Font, but Mozilla has since changed and we don't need it any more.  

[2] For examples, he had :  'In the case of unicode, one can choose 
codings utf-8, ucs-2 etc. These codings are denoted in MIME terminology ...'.
This usage sounds very strange to me. Needless to say, I'm well aware that some
poeple used 'character code' or just 'code'.
[3] http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html

Comment 3

[Katsuhiko Momoi]

(In reply to comment #2)
> >> As I recall, 'character coding' was chosen ('invented') 
> 
> > The term "character coding" predates Mozilla and HTML 4. As I recall, 
> > this term was advocated by Alan J. Flavell.
> 
>  OK. It's not invented by Mozilla, but still it doesn't sound familiar to me. He
> doesn't give any reference to the term (as far as I can tell), which may be an
> indication that it's of his own 'invention'. 
> 
> Alan J. Flavell's only argument against 'encoding' (for view menu [1]) is :
> 
> > a.k.a "encoding", but this term risks confusion with a
> > different protocol layer, such as encoding with base-64, binhex,
> > uuencoding etc.). 
> 
> While reading his  postings with the term 'coding' used throughout, 
> I felt rather 'uncomfortable'. That's probably because I had never seen the 
> term 'coding' be used for UTF-8, UTF-7, UCS-2 (for that matter, I had never 
> seen it outside Mozilla for other character encodings, either)  before reading 
> his posting. 

The phrase "charcter coding" is a perfectly valid term. I don't believe
the term was invented by Mr. Flavell. As I explained above, it is a general term 
sometimes used synonymously with "character encoding". I think of it as a perhaps a 
more general one than "character coding. 
Contrary to your claim, the term is used even within the description of the Unicode
Standard and other credible places. See for example this top page at the Unicode
org.

http://www.unicode.org/unicode/standard/standard.html

or section 3.1 of recent Unicode TR#17:

http://www.unicode.org/reports/tr17/tr17-3.3.html#CharacterNaming

and of course there are other references outside of unicode.org. And of course
this is not at all strange given what the phrase "character coding" means.

Comment 4

[Jungshik Shin]

OK.  I should have run google search for both terms. 'character coding' (with
quotation marks enclosing the word) return ~9000 hits while 'character encoding'
returns about 1.7 million hits. That is, the latter is used 200 times more
frequently than the former. The very first hit for 'character coding' is Alan's
web page you cited earlier, which indicates that most references to the term
refer to his document (if I understand correctly the way google works).

> even within the description of the Unicode Standard and other credible places.

Well, the title of UTR #17 is 'Character Encoding Model'. It used only once the
term 'character coding' to refer to the process of assigining unique integer
numbers to characters in a characater repertoire. That is, 'code' in 'character
coding' in UTR #17 has the same meaning as 'code' in 'coded character set' which
 is different from 'character encoding' (according to UTR #17 and W3C CHARMOD
TR). Note that UTR #17 section 3 (where 'character coding' is used) is about
'coded character set'. 

UTR #17> SC2, the JTC1 subcommittee responsible for character coding, requires
UTR #17> the assignment of a unique character name for each abstract character in 
UTR #17> the repertoire of its coded character sets. T

Exactly the same is true of the first sentence of 'about the Unicode standard':

Unicode> The Unicode Standard is a character coding system designed to support 
Unicode> the worldwide interchange, pr

 Unicode is a coded character set (a character coding system) while UTF-8,
UTF-16(LE|BE), UTF-7, UTF-32(LE|BE) are character encoding (scheme/form).  As I
wrote, I had never seen anyone use the term 'character coding' when talking
about UTF-8, UTF-7 before I read his posting. Of course, this does not mean that
the term is invalid by any means, but it could be an indication that it's not as
widely used as character encoding when refering to UTF-8, EUC-JP, ISO-8859-1,
etc, which is kinda confirmed by the result of google search of two terms.

> I think of it as a perhaps a  more general one than "character coding.
 
    I guess you meant 'character coding' is more general than 'character
encoding'. Or did you mean the opposite? 
   

Comment 5

[Katsuhiko Momoi]

>   I guess you meant 'character coding' is more general than 'character
> encoding'. Or did you mean the opposite?

Sorry! I meant to say that "character coding" is more general in usage than 
"character encoding" -- but for some reason submitted my comment without 
cleaning up the writing. 

Here's a summary from my perspective and a suggestion:

1. The term "character coding" is ambiguous like "character encoding" between a
process
   sense and an end result (of a process) sense. This is generally true for English 
   verbs that describe process, e.g. coding, encoding, etc.
2. "Character Coding" is as valid a term as "Character Encoding" for these 2 senses.
3. Both Unicode Standard and W3C seem to be using "encoding" rather than
"coding" in their
   official documents. (They probably unified on it for editorial consistency
though 
   "Coding" is Ok as well.)
4. For average users, the word "coding" or "encoding" is equally obtuse. It
really does not 
   improve the usability of this menu just because we change the wording.

The question to me is: is there an overriding reason now to change the wording
of an UI/menu
item based just on the point #3? We would have to change the wording in several
encoding related
dialogs, warning dialogs, help files, etc. as well as having an effect on
documents that 
have been written about "Character Coding". This menu name has been there since
1999.

Do we change the wording "View > Reload" to "View > Refresh" because IE uses the
latter wording?
Does changing "Coding" to "Encoding" really gain us more users when we know that
average users
simply don't know what they mean anyway? Does a UI name have to use an official
definition
term? If so, why not use "Accept Language(s)" for a dialog that is now named
"Languages for
the web"?

I think it would be better if we bring in some other opinions and see if we have
strong reasons to change this wording at this point in time. I suspect that
people like
Martin Duerst and Alan J. Flavell have been seeing the UI/menu name for a while.
M. Duerst
occasionally writes to us about Mozilla issues and things that need to be
changed. I have
heard from some active W3C and Unicode contributors but this is the first time I
heard this
particular suggestion from an active Unicode contributor. Let's contact people
like M. Duerst,
R. Ishida, A.J. Flavell and others to find out more.

Comment 6

[Katsuhiko Momoi]

I sent a message to Alan, Martin and Richard requesting a 
comment on this bug. 

Comment 7

[Jungshik Shin]

Thanks  for the summary. Richard has been on CC for a while :-).

Your point #3 and point #4 are related (although rather weakly). The fact that
W3, Unicode and other standard organizations converged to 'character encoding'
means more and more people will use / see the term. ( In an ideal world,
end-users should not concern themselves with character encodings. Unfortunately,
we don't live in such a world so that we are dealing with it.) How much would
that help end-users? Perhaps only a little.  

I'd not say there's an overwhelming reason to switch to 'character encoding' at
this point (5 years after the decision was made). Perhaps, I should have voiced
my concern back in 1998 - 1999. As you wrote, my argument that it'd help
ordinary users (not I18N expert) migrate to Mozilla is pretty weak and I have to
admit that it's rather pedantic of me to ask for change that is of little
_practical_ value. 

Comment 8

[Katsuhiko Momoi]

There were responses to this issue from Richard, Alan and Martin. 
Richard and Martin prefer the term "Character Encoding" and Alan
says that "Character Encoding" seems to have established as a term
since 1999 when we last had this discussion though he is fine with
"Character Coding" as well. Alan would not mind changing it to
"Character Encoding". (I will attach their responses below so that
we can retain them for future.)

I am like Alan in this regard. For current terminology use, "Character
Encoding" seems to be an established term though I don't see anything
wrong semantically with "Character Coding". I don't believe, however, 
this change will have much of an impact to current or future average 
Mozilla users. 

Jungshik, if you want to make this change, please investigate 
thoroughly how many places this change will have to be made. This
include HELP files. If there is official documentation on how to use
Mozilla, document writers also need to be informed. My suggestion would
be not to hurry and take your time assessing the UI change impact and
also avoid doing this near a major milestone release.

Comment 9

[Katsuhiko Momoi]

Attachment: Responses from Richard, Martin, and Alan.

This attachment contains responses from Richard Ishida@W3C, Alan J.
[e-mail], 
and Martin Duerst@W3C.

Comment 10

[Jungshik Shin]

OK. I'll do that tomorrow. It's  rather simple  compared with a few other
tree-wide changes I made/am planning to make (e.g. bug 91190, bug 229032). 

Comment 11

[Jungshik Shin]

Attachment: patch

This patch also replaces 'character set' (in some places) with 'character
encoding'. It works in most of places. There's a problem, though. 'View |
Character Encoding | Customize' dialog window doesn't pop up in  Composer and
Mailnews window. "Customize' works fine in Navigator window. Strange is that it
didn't work even after I removed the patch and recompiled the Mozilla from the
scratch.

Comment 12

[Jungshik Shin]

Kat, can you go over my changes in help files?

rlk, can you tell me why there are both html files and xhtml files (in
extensions/help)? They're almost identical in contents, but are a little
different (aside from differences due to one being html and the other being
xhtml). Both types of files have been updated recently (but not at the same
time). In the patch, I fixed both because I don't know which is used for what. 

Comment 13

[R.J. Keller]

> rlk, can you tell me why there are both html files and xhtml files (in
> extensions/help)? They're almost identical in contents, but are a little
> different (aside from differences due to one being html and the other being
> xhtml). Both types of files have been updated recently (but not at the same
> time). In the patch, I fixed both because I don't know which is used for what. 

They're there from bug 95770, which isn't complete yet.

Please note that any changes you make to Firebird Help on the trunk need to also
be checked into the Firebird Help on MozDev (http://firebirdhelp.mozdev.org).
I'd file a new bug and post your patch there.

Currently, all development is done there because of the slow review process on
the Firebird side, but you can try. Note that to check this in you need review
from a Firebird peer (probably ben) for the Firebird Help part and a Help
Systems owner/peer (probably me or neil) for the Seamonkey part. The only people
who can review Help documentation that aren't peers are Daniel Wang and caillon,
so remember that this can't be checked in without the proper approval. You might
want to split this into two patches. One for Seamonkey and one for FBH.

If you get review from Neil and Ben, you should be good to go since Neil can
cover every module except for Firebird in this patch (while I can't review for
xpfe changes).

Comment 14

[[e-mail]]

Attachment: Fix customize menus

My fix to stop the customize menus from reusing the preferences dialog only
worked properly for the browser, I forgot to check the other windows :-[

I also found a regression from the charset atom bug - some of the methods had
not changed from Get... to get... consistently.

Comment 15

[Jungshik Shin]

Comment on attachment 140799 [details] [diff] [review]
Fix customize menus

r=jshin

Thanks for fixing this, Neil. A few minutes ago, I downloaded a nightly to find
that my pach is not to blame.

Comment 16

[Jungshik Shin]

Attachment: seamonkey part

per rlk's suggestion, I broke down the patch into two (actually three because I
guess 'rhino' needs a separate review). this is seamonkey part.
The only difference (aside from not containing FB/TB patch) from attachment
140795 [details] [diff] [review]	is that I removed spaces around '/' as in 'language / script'. Now I
have 'language/script'.

Comment 17

[Jungshik Shin]

Comment on attachment 140805 [details] [diff] [review]
seamonkey part 

asking for r. 

Kat, can you also word-smithing my changes in help files? 

Neil, is there anyone particular I have to ask for sr?

Comment 18

[Jungshik Shin]

Attachment: firebird part

firebird and thunderbird path

Comment 19

[Jungshik Shin]

Comment on attachment 140806 [details] [diff] [review]
firebird part

asking for r/sr.

rlk, thanks for your suggestion about review.

Comment 20

[R.J. Keller]

Comment on attachment 140806 [details] [diff] [review]
firebird part

r=[e-mail] on this patch. Once ben gives a review+ on this, I'll check it
in!

Filed MozDev Bug 5732 so we can get this on Firebird Help 1.1 beta.

Comment 21

[Jungshik Shin]

Comment on attachment 140799 [details] [diff] [review]
Fix customize menus

I should have caught these in my previous review. Fortunately, it's not late
because you haven't gotten sr, yet. :-)

>Index: xpfe/global/resources/content/charsetOverlay.js


>+function MessageMultiplexHandler(event)

   This function had better be named 'MaileditMultiplexHandler', IMHO.

window.openDialog("chrome://communicator/content/pref/pref-charset.xul",
>+                          "_blank", "chrome,modal,resizable", "browser");

  Instead of 'browser', the last parameter should be 'mailedit' because we
maintain a separate list of active character encodings for the mail editor
(xpfe/components/intl/nsCharsetMenu.cpp).

>Index: xpfe/global/resources/content/charsetOverlay.xul

>     <!-- Mail Edit Charset Menu -->
>-    <menu id="maileditCharsetMenu" label="&charsetMenu.label;" accesskey="&charsetMenu.accesskey;" datasources="rdf:charset-menu" ref="NC:MaileditCharsetMenuRoot" oncommand="SetDocumentCharacterSet(event.target.getAttribute('id'));" onpopupshowing="CreateMenu('mailedit');InitCharsetMenuCheckMark();" onpopupshown="CreateMenu('more-menu');">
>+    <menu id="maileditCharsetMenu" label="&charsetMenu.label;" accesskey="&charsetMenu.accesskey;" datasources="rdf:charset-menu" ref="NC:MaileditCharsetMenuRoot" oncommand="MessageMultiplexHandler(event);" onpopupshowing="CreateMenu('mailedit');InitCharsetMenuCheckMark();" onpopupshown="CreateMenu('more-menu');">

Here's why I think 'MaileditMultiplexHandler' is better than
'MessageMultiplexHandler'. Perhaps, you may want to make it a noun like
'MaileditorMultiplexHandler'.

Comment 22

[Katsuhiko Momoi]

It probably take me a day to proof the help files changes, but here's
one problem I found so far:

diff -u -7 -p -r1.11 cs_nav_prefs_navigator.xhtml

-<li><b>Default Character Coding</b>: Use the drop-down list to select the
character 
+<li><b>Default Character Encoding</b>: Use the drop-down list to select the
character 
 coding you want for displaying web pages. </li>

More later.

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 140806 [details] [diff] [review]
firebird part

yes! 

so much for international stakeholder preferring the term "coding" for some
inane reason. I tried to do this 3 years ago but was stopped by inept
management. good times. 

sr=[e-mail]

Comment 24

[[e-mail]]

Attachment: Addressed jshin's comments

Very sorry about that - I must have copied the wrong line :-(

Comment 25

[Katsuhiko Momoi]

Attachment: Help files edits.

I've gone through the help files lanaguage changes. I indicated the problem
spots in red color, followed by suggested changes. I didn't notice a change in
the Composer window menu, "File > Save As Charset..." and its associated
dialogs and help files. We probably should extract the relevant parts aand
change them as well.

Comment 26

[Jungshik Shin]

Thanks a lot for your thorough review !

+<p>The character encoding method for a document may depend on its language. Some 
+ languages .... Unicode (e.g. UTF-8) can be used 
+for any language/script.</p>

> Note: This is an entirely new addition. 
 
  Actually, it's not. I added a sentence, but the paragraphe was already there.

> To change the order in which the browser checks for character encodings, 
>       highlight character encodings i

> Comment: This is factually incorrect

  You're right. Currently, it gives a false impression that it's a priortized
list, but actually it's not. I'm gonna file a bug about making it actually a
priortized list along with an autodetection module that makes use of the list.
We also have to emit  the list in 'accept-charset' http header.  Anyway, for the
now, I'll change it to reflect the 'reality' as you suggested. 

> Change: "choose a language group/script" --> "choose a language 
> group/script/character set"
> Note: 'script' for Cyrillic, 'character set' for Unicode.

  I'd rather leave that alone. We have to do something about 'Unicode' in the
font selection menu soon. (there are several bugs on this.) It's confusing and
its usage (and the effect of setting fonts for that) is rather inconsistent
across Gfx ports.

> Comment: what do we do about:
> <!ENTITY windowTitle.label "Save As Charset">

Yeah, I thought about changing it to 'Save As Character Encoding' (too long for
a menu item) and 'Save As Encoding' (potentially confusing), but left it as it
is partly to 'solicit' your comment :-)

Comment 27

[Katsuhiko Momoi]

> Yeah, I thought about changing it to 'Save As Character Encoding' (too long for
> a menu item) and 'Save As Encoding' (potentially confusing), but left it as it
> is partly to 'solicit' your comment :-)

Your patch eliminates the use of 'character set' unless it really means a set
and so leaving this wording in the Composer menu would be much worse
than changing it to "Save As Encoding...".
Something like the following may be better:

"Save and Change Encoding"

Comment 28

[Jungshik Shin]

Comment on attachment 140854 [details] [diff] [review]
Addressed jshin's comments

r=jshin

Comment 29

[[e-mail]]

(In reply to comment #27)
>>>what do we do about: "Save As Charset"
>>"Save As Encoding"
>"Save and Change Encoding"
How about "Save With Encoding" ?

CC'ing glazou because that menu item is in his module.

Comment 30

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

"Save with encoding" will be very hard to understand for average users... Give it
another try if you can. Even if people don't use it, the meaning has to be
intuitive. Sorry, but this is not.

Comment 31

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

My preference would go to something like

   Save changing character encoding

Momoi-san : it's no too long for a menu entry. It's even shorter than the
existing "Delete Mail Marked as Junk in Folder" :-)

Comment 32

[Jungshik Shin]

Attachment: update

I addressed Kat's concerns. 

As for 'Save As Charset', I haven't changed it yet. I'm a bit out of gas so
that I rather like to land this first and deal with it later.

Thanks to Daniel, I realized that 'Save As Character Encoding' or variants are
not that long compared with others we have. Granted, I prefer to go with 'Save
As Character Encoding'. 'Save As' is frequently used and just replacing
'Charset' with 'Character Encoding' seems to be most straightforward. A
downside of changing 'Save As Charset' is that a couple of files (dtd, js, xul)
files have names derived from 'Save As Charset'. So do several entity names.
It'd make a little tough for future developers to track down these if we just
change the UI string without renaming them as well.

Comment 33

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

"Save As Character Encoding" is not a good choice at all. It does not do what
it says. The menu entry does not save an encoding, it saves WITH an encoding.

Sorry, I don't want that change into Composer if it's a new incorrect text and
if the dialog is still also incorrect.

Comment 34

[Jungshik Shin]

It saves an html document in a  character encoding. 'As' is not so clear, but
'with' is worse than 'as'. At least, 'as' has been used in mozilla and other
products. 

> if it's a new incorrect text and if the dialog is still also incorrect.

I'm not following you here. Did you mean you just want to keep 'Save As
Charset'?  I'm fine with that for the now. That's what I wrote in my previous
comment.

Comment 35

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

With/in. But not 'save as'. 'Save as xxxx' means you save the current instance
as if it was an xxxx. 'Save as charset' means 'save making it become a charset'.
The dialog this menu entry fires makes the same confusion "select the charset
you want to save as". If you want to touch this menu entry, please make a choice
we don't have to change again later on.

Comment 36

[Jungshik Shin]

If the number of hits in google can be a guide, 'save as' and 'save in' are a
lot more widely used than 'save with'. 'save as UTF-8' and 'save in UTF-8'  have
~150 and ~120 hits, respectively while 'save with UTF-8' has only 3 hits. One of
hits for 'save as utf-8' is an FAQ at W3C I18N WG
(http://www.w3.org/International/questions/qa-utf8-bom.html)

re your last comment: no matter what you think about the usage, I18N people have
been using 'save as ISO-8859-1', 'save in ISO-8859-1' for a long long time. 

Comment 37

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Well, just show this string 'save as ISO-8859-1' to an average computer user,
not a geek like us, and you'll understand what I mean when I say we should find
more intuitive menu entries.

Comment 38

[Richard Ishida]

I'm not sure of the context, but I agree that Save as Character Encoding sounds
wierd. I always thought that the phrase Save As.. refers to a (different) file
name or format.

Thinking about applications where I am able to select an encoding while saving,
it seems a common model is to select Save As.. then find a option on the dialog
box to select the character encoding.

Comment 39

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

ishida : I agree 100% with you.

Comment 40

[Jungshik Shin]

Well', even if we do that, the meaning of 'save as' doesn't change a bit (that
is,  it's used like 'save ... as utf-8', which you're not so fond of).

Anyway, 'Save As ...' is already taken in composer. The composer file menu has
both 'Save As' and 'Save As Charset', which appears redundant. 'Save As' prompts
only for the title while 'Save As Charset' prompts for the title and the
character encoding. What can be done is to get rid of the current 'Save As' and
rename the current 'Save As Charset' to 'Save As ..'.  I wouldn't deal with it
here because that's outside the scope of this bug. If you like that, why don't
you file a new bug? 

Comment 41

[Katsuhiko Momoi]

I remember talking about the wording with bobj who might have come
up with "Save As Charset...". He himself knew that this was awkward
but left it in there for lack of a better term at the time. The menu
length was one of the issues also. (But Daniel says that this is not
an issue!)

What makes the current wording very difficult to understand is the fact
that "Save (it) as Charset (of) X" forces the reader to fill in 
at least 2 holes in syntax and the 2nd of which is not a simple
noun object but must be an object of a missing preposition.  
The syntax is in terribly poor English -- we are forcing an unfair
role on "as". If we are forcing the reader to guess, missing holes 
must be straightforward.

I vote for either of the two solutions:

1. Make the meaning explicit if length is not of concern.

   Save Changing (Character) Encoding (per daniel glazman)
   Save to Change (Character) Encoding (mine)

2. More permanently, combine the current "Save As ..." and "Save As Charset..."
   into one. As jshin suggests, getting rid of the current "Save As ..." should
   do that job. If this is not doable quickly, then I suggest making
   a change in 1 first until 2 is doable.

Comment 42

[Jungshik Shin]

The second option has to be a separate bug because it needs sorta 'substantial
changes' in xul/js as well as in dtd. Perhaps, filenames have to be changed as
well. 

As for the first option, I like your  proposal 'Save and Change (Character)
Encoding' (comment #27) better than two alternatives in comment #41. 'Change
(Character) Encoding and Save' might better reflect what it does, but if we do
that,  I'm afraid 'Save' would be made a bit obscure.

Comment 43

[Katsuhiko Momoi]

> As for the first option, I like your  proposal 'Save and Change (Character)
> Encoding' (comment #27) better than two alternatives in comment #41. 'Change
> (Character) Encoding and Save' might better reflect what it does,

I am OK with "Save and Change Encoding" or "Save and Change Character 
Encoding". BTW, "and" does not always indicate a sequential occurrence.
In this case and many others, "and" simply indicates co-occurrence, i.e.
some things happening at the same time. There is no need to change the
order of 2 conjuncts to get the meaning we want.

Let's file a new bug to combine the 2 "Save As ..." menus into one
very soon. The only reason I recall that we didn't do this at the 
beginning is lack of time to persuade everyone involved. Instead
we just added a new menu item, which was a lot easier. 

Comment 44

[Jungshik Shin]

I filed bug 233650 for combining 'Save' and 'save as charset' into one. 

Comment 45

[[e-mail]]

Comment on attachment 140805 [details] [diff] [review]
seamonkey part 

>+        <rdf:li> <rdf:Description ID="nav-doc-charencode" nc:name="Selecting Character encodings and Fonts" nc:link="chrome://help/locale/nav_help.html#nav_charencode"/> </rdf:li>
"Selecting Character Encodings and Fonts"

>+use a character encoding method (also known as a character set, character coding, or chareset, ).</p>
"or charset)."

>+to set default fonts for the West European languages/script (Latin), 
"for West European languages"

>+<li>If an appropriate font is available for your language/script , select 
"script, select"

>+For instance, to set default fonts for the West European 
"for West European"

>+<li>If an appropriate font is available for your language/script , select 
"script, select"

>+    default fonts for the West European languages/script (Latin), 
"for West European languages"

>+    default fonts for the West European languages/script (Latin), 
"for West European languages"

> <!ENTITY languages.customize.right.header			    "Select Supported Charsets">
Not changed?

>-  gDialog.FilenameInput.value = unescape(filename);
>+  gDialog.FilenameInput.value = decodeURIComponent(filename);
:-)

Comment 46

[Jungshik Shin]

Attachment: update

addressed review comments and replaced 'Save As Charset' with 'Save and Change
Character Encoding'  (in editor/ and composer/)

Comment 47

[Jungshik Shin]

Comment on attachment 141206 [details] [diff] [review]
update

asking for r

Comment 48

[[e-mail]]

Comment on attachment 141206 [details] [diff] [review]
update

I haven't looked at the editor changes yet.

>+Some languages e.g. most of West European languages, share the same encoding 
I was OK with "most of the Western languages" but if you want to change this
use "most West European languages."

>+</p>
Not sure why this is here... if you want to fix this, it belongs before the
<ol>, not after the </ol>

>-<li><b>Fonts for</b>: Choose a language character set. For instance, to set 
>-    default fonts for the Western (Roman) character set, choose "Western." 
>+<li><b>Fonts for</b>: Choose a languge group/script. For instance, to set 
>+    default fonts for West European languages/script (Latin), 
>+choose "Western." 
Typo, somehow you deleted the second "a" in "language".

Comment 49

[[e-mail]]

Comment on attachment 141206 [details] [diff] [review]
update

r=me if you fix that last lot of comments.

Comment 50

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

moa=[e-mail] for the editor part

Comment 51

[Jungshik Shin]

Thanks for your review. Also, thanks for moa. I've fixed issues raised by your
review comments in my tree. 

BTW, Neil, shouldn't we push attachment 140854 [details] [diff] [review] (your patch) for 1.7a? Perhaps,
it's too late. Well, 1.7alpha is not that important...

Comment 52

[Jungshik Shin]

Comment on attachment 141206 [details] [diff] [review]
update

asking for sr (with neil's review comment addressed).

Comment 53

[Scott MacGregor]

Comment on attachment 141206 [details] [diff] [review]
update

I can take this off brendan's review plate and look through it.

I've wanted this change for a long time.  

nice patch and nice review work Neil.

Comment 54

[Jungshik Shin]

thanks all, patch got landed. 

Comment 55

[Jungshik Shin]

Ooops. I forgot that Neil's patch (attachment 140854 [details] [diff] [review]) hasn't yet been landed.
Scott, can you sr it  so that he can commit attachment 140854 [details] [diff] [review]. Neil, you should
have filed a separate bug for that instead of piggybacking it here ;-).

Comment 56

[Scott MacGregor]

Comment on attachment 140854 [details] [diff] [review]
Addressed jshin's comments

sorry, I didn't notice this bug had two patches in it needing review.

Comment 57

[[e-mail]]

Fix checked in.