23179 - [RFE] Make Charset in use by OS very visible on View Menu

Status: VERIFIED FIXED

(Core :: Internationalization, enhancement, P3)

Description

[Sean Richardson]

There have been many complaints about the difficulty of presenting and
selecting all the Charsets that Mozilla knows about on the View menu.

Proposed: on profile creation, have the Profile Manager query any host OS known
to keep information about what Charset the OS UI is primarily using in an
easily queried location for what that charset is, and save it to a pref.

Then, on startup, give that charset a very visible position on the view menu.
That way, if the user needs to change to a different charset to view a page,
it will be easy to change back to the normal charset later.

CC-ing QA contact for Internationalization.

Since this is multi-platform-specific, I'm sure this will wait in any case...
but does it make sense?

Comment 1

[selmer (gone)]

It seems reasonable to me that the charset menu should somehow hilite the native
charset.  However, it's not a profile manager task to discover this.  The
profile manager's job is to create a container for other parts of the app to
store things in.

What should really happen, if this gets implemented, is that the consumer of the
information should properly deal with the absence of this pref and "do the right
thing" when it's missing.

Comment 2

[Frank Tang]

I agree that this should have nothing to deal with profile manager. I think the
main point is the charset menu should be custmoizable and there should be some
code suggest what should be in by default. Howerver, could you please propose
how to-
"query any host OS known
to keep information about what Charset the OS UI is primarily using " ?
Please provide API that we should call on Mac, Win and UNIX. Thanks.

Since cata is now working on charset menu cutomization, reassign to him. cc
bobj, momoi and tao.

Comment 3

[Katsuhiko Momoi]

The Browser Charset Menu specs have been externalized at the above URL.
The document contains a proposal for customization of the Browser
Character Coding menu. Please look it over and see how your idea might
fit in the proposal.
You can also start a discussion at "[e-mail]" Mailing List
if you have questions and/or sugegstions.

Comment 4

[Sean Richardson]

Responses to comments in the order issues were raised.

First, the only reason for finding out what charset the OS is using at
profile-creation time is that otherwise it would be necessary to do so
at each startup - and it is unlikely that the desired "default" charset
for a given profile will change over time, even if the profile is used
on other machines. Also, at that time the user could be presented a
Customize dialog to choose from if the OS isn't queriable or the response
makes no sense, something that could not reasonably done at each startup
and would otherwise need to be relegated to a panel or sub-dialog in the
preferences.

This may not be so important, however, if the appropriate charsets are made
easily accesible on the View menu in Localized versions of the browser, as
planned.

Second, the phrase "any OS known to keep information about what Charset the OS
UI is primarily using in an easily queried location" was meant to evoke either
an "A-ha" or a "???" response ... I don't know APIs for that myself, so if
nobody else does either, and nobody thinks this is a wonderfully useful idea,
feel free to assign to "[e-mail]" - I suspect that tracking down
such APIs for all major OS would be a difficult and thankless task.

In any case this is polish. If it does make sense to query the OS, perhaps
a request on the mailing list for help finding the APIs would
be in order before any engineer time is spent.

Third, the way that I see this proposal fitting into the Charset menu spec
at the above URL would be to ensure that the charset in use by the OS is
on the 1st tier menu, in the first or second position (before any manual
customization), if it is not there already. After all, the user almost
certainly has already made a choice to use that charset everyday.

The question that remains is whether there are enough potential instances
where the Localized version chosen by the user would not already contain
the charset in use by the OS on the first tier menu to make it worth
taking any action on this proposal. The answer is quite possibly no.

The only use that I can see, in fact, for this proposal, would be to
pre-customise which charset is first on the tier-one menu for those languages
and platforms where more than one is commonly used. The CCK may be a better
tool for this, though.

Comment 5

[tao]

On Unix, the charset information is often embedded in the system locale.
For example,  ja_JP.euc,  ja_JP.sjis,  zh_TW.big5, etc...
However, the mapping is vender dependent and platform-specific mapping
 is needed.

IMO,  a better approach might be to  allow the user to set a default charset via
GUI and save it as a user prefs (like Communicator 4.x does).
The user can always reset the view charset to this default.

Comment 6

[Katsuhiko Momoi]

The specs doc mentioned above touches on this topic.
Please direct your discussions on this topic to the
[e-mail] mailing list if a revision is being proposed.
The spec calls for the default charset group setting by the L10n group
when a localized version is available. Customizability is also
proposed and detailed in it. I believe that the specs as they stand now
more or less satisfy the points rasied in this RFE.

Comment 7

[Grace Bush]

changing QA contact

Comment 8

[Teruko Kobayashi]

Added beta1 because this is beta1 criteria.

Comment 9

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 10

[cata]

And the spec is pretty much implemented.

Comment 11

[Allan Masri]

verified in mozilla 2000021608