93237 - Character Coding menu is messy (Turkey is ... where?)

Status: RESOLVED DUPLICATE of bug 10999

(SeaMonkey :: General, defect)

Description

[Ken Harris]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010726
BuildID:    2001072606

The "Character Coding" menu is a mess.  I especially notice
this when I'm looking for Turkish.

- I have to hit 5 menus (View -> Character Coding ->
More -> SE & SW Asian -> Turkish) to change the encoding.
It's very easy to slip and have to start over again.
(FWIW, Apple's old Human Interface Guidelines say never go
more than 1 level deep with submenus.)

- Turkey's largest city, Istanbul, is in Europe (I'm told
it's Europe's largest city, now, even).  "East European"?
Nope.  OK, well, www.dmoz.org lists Turkey under "Middle East",
so maybe "Middle Eastern"?  Nope.  Hmm, maybe "SE & SW Asian"?
Yup, right between Thai and Vietnamese.  For some reason that
doesn't seem to be the most logical placement.

Reproducible: Always
Steps to Reproduce:
1. Open the "View" menu
2. Mouse down to "Character Coding"
3. Slide over to "More"
4. Go down to "SE & SW Asian"
5. There it is!

Actual Results:  (see description above)

Expected Results:  IE5's version of this menu isn't hierarchical -- it
shows all the encodings immediately, so it's easy to
skim the list and find what I'm looking for.  (I
don't have to guess which continent they think Turkey
is on.)

Yeah, Mozilla has more encodings.  If more submenus
is really better than scrolling (and I'm not convinced
it is), maybe the hierarchy should be More -> Turkish
-> (IBM, ISO, Mac, Windows).  There would be the same
number of menus to spelunk through, but we'd know
exactly which submenus to follow.

Bugs #47343 and #52157 might be relevant.

When I select the "Properties" for my Inbox in Mozilla
Mail, it gives me a single (non-hierarchical) popup to
choose the encoding.

Comment 1

[Matthias Versen [:Matti]]

confirming...

Comment 2

[Katsuhiko Momoi]

We could put Turkish under Middle Eastern but linguistically and
typologically, it probably is not a good fit given the history of 
Turkish away from the Arabic script for most of the 20th century.

Another possibility is to put it under East European, which 
had been considered but this makes the East European list too long,
which defeats the whole purpose of subcategorizing in the firsst place.

There are also other ideas within the sub-category framework.

It would be nice to have an IE style menu here -- I wonder if that
type of widget is now available in Mozilla.
In any case, let me CC some i18n folks so that we are aware of 
what's going on. I take it that this bug is not really about
just Turkish.

Comment 3

[bobj]

> It would be nice to have an IE style menu here

Did you mean a Windows-style menu widget which will have multiple columns
if longer than the window?  The IE encoding menu is just one long list of
more encodings.

When the mozilla character coding menu was implemented menus were not
scrollable -- it just ran off the end of the screen and became inaccessible.
It think that has been fixed -- it works for bookmarks.  So we could go back
to the original design of having one very long list.  But note that mozilla
supports many more charsets than IE, so our list will very likely need to
scroll.

Comment 4

[timeless]

1. scrolling long menus _sucks_.
2. if you're going to reference other apps, please attach pictures.
3. we don't currently support multiple collumns, a bug is filed, but MPT would 
contest that.
4. if you have a list of 1000 locales/languages you'll never have a good menu 
based UI for it.

Here's my proposal: remove turkish from the list entirely. then no one could 
complain about finding it in some random place.  Of course... then you couldn't 
use turkish, but well...

Comment 5

[Ken Harris]

Re timeless's #1: yes, it does, but so does digging through
sub-menus 3 levels deep, especially when you may have to do
it several times in a row.  (Quick, here's a page in Turkish:
is it in IBM, ISO, Mac, or Windows encoding?  And Cyrillic
has even more encodings.)

Re #4: Possibly, but then we need to think of a better way
of doing it, if we plan to add 1000 languages before the web
turns to Unicode.

My general problem is that when I use this menu, I'm
thinking "Ok, here's a Turkish page, now I need to figure
out which encoding they used" (by trial-and-error), not
"Ok, I'm looking for a SE/SW Asian language encoding".

Based on that, here's a new idea for the menu.  Tell me
what you think:

Character Coding >
    Auto-Detect >
        (...whatever's there now...)
    Language >
        Arabic
        Armenian
        Celtic
        Chinese
      x Greek
        (...all the rest of them...)
    Encoding >
      x ISO-8859-7
        MacGreek
        Windows-1253
    ----

The Language submenu lets you pick the language (I count fewer
than 25 languages in Mozilla, so it wouldn't be huge).

The Encoding menu displays the available encodings for whatever
language is selected.  When you select a new language, it
defaults to the last-used encoding for that language.  Or it
could default to "Auto-Detect" (I'm not sure how that works).

Let me know what you like/hate/etc...

Comment 6

[Katsuhiko Momoi]

Western, Central , Baltic, Cyrillic, etc are not languages. They are either language
groups or script groups. If you list all the languages within it, you will have
a huge
list. 

Comment 7

[timeless]

Character Set>
Language>
Encoding>

this might work, but by the time you need to pick3 you need a dialog (sounds 
familiar).  anyone have the winning 200$million powerball numbers?

Comment 8

[Ken Harris]

Strictly speaking, the current menu items are "language - encoding",
"language group - encoding", or "script group - encoding", then, so
I don't think grouping (say) "Western" with "Greek" would be any more
inconsistent.

"Language > Western" I'd interpret as "the Western languages", just
as "Language > Greek" is "the Greek language".  (Put "Western" at
the top, then list the rest alphabetically, as is done now.)

How about calling them "Script >" and "Encoding >", then?  Mozilla
doesn't care what language it's written in (unless that language
is its own script, like Greek).  I just figured "Language" made
the most sense to the most users.

Comment 9

[Shoshannah Forbes]

>I just figured "Language" made the most sense to the most users.

I am not so sure about it. Would I find Hebrew encodings under Hebrew or under 
Arabic, since they are both Bidi?
You have to group them somehow, but I am afraid that using the term "language" 
you will either get umbiguos resoults, or you would get a very long list...
IE has two nice fratures in that menu:
1. If you don't have the language pack for a language installed, you will only 
see the general language name, not the full list of encodings avalible for that 
language (if you select that language, you get prompted to download the 
appropiate language pack).
2. IE remembers the last few selections you made, and lists them at the top 
level, so if you use the same set of encodings over and over again, you don't 
need to dig in the menu.

I think we already do #2. Could we do something similar to #1, and not list 
unused encodings (or encodings we know the system can not display)?

Comment 10

[Matthew T (active 1999-2002)]

Unfortunately, this bug falls into the `I told you so' department ...

    The current UI may make perfect sense to those who are specialists in
    i18n, or who are familiar with `linguistic typology'. But it would make
    very little sense to the Japanese, Chinese, Korean, Russian, and Israeli
    customers who come into the Internet cafe where I work, who are not
    specialists in i18n, and for whom changing the encoding for Web pages is
    a frequent task.
                                                     -- bug 10999.2000-12-16

Ken is correct that multiply nested menus are terrible. Timeless is also 
correct that very long scrolling menus are terrible. Fortunately, there is a 
solution which involves neither: a single submenu listing the n most recently 
used encodings and/or auto-detection modules (where n ~= 6), and an `Other...' 
item which opens a dialog listing the other encodings and auto-detection 
modules.

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