And they sort that list HOW, exactly?

by Michael S. Kaplan, published on 2005/12/09 10:01 -08:00, original URI: http://blogs.msdn.com/michkap/archive/2005/12/09/502054.aspx

Yesterday, when I was exclaiming that If you can't read it, don't switch to it! I did mention I would talk about the sort order in the language list another day.

Welcome to another day. :-)

I am going to talk about four different language lists:

Let's do some comparison/contrast work now....

First there is the user locale list. It is in the Regional and Language Options control panel applet (in the first tab), and lists the LOCALE_SLANGUAGE (this is the name of the locale that is localized into the UI language of Windows, as I discussed the other day) of every locale installed on the system. The combobox list has the CBS_SORT style and the list is sorted according to the default user locale.

Then there is the system locale list. It is also in the Regional and Language Options control panel applet (only in the third tab), and lists the LOCALE_SLANGUAGE (this is the name of the locale that is localized into the UI language of Windows, as I discussed the other day) of every locale installed on the system that does not have a LOCALE_IANSIDEFAULTCODEPAGE equal to 0 (which happens to be the same number as the CP_ACP constant). The combobox list has the CBS_SORT style and the list is sorted according to the default user locale.

Of course now we look at the AppLocale language list. It is in an external application, and lists the LOCALE_SNATIVELANGNAME (this is the name of the language of the locale, localized into that language, as I discussed the other day) of every locale installed on the system that does not have a LOCALE_IANSIDEFAULTCODEPAGE equal to 0 (which happens to be the same number as the CP_ACP constant). The combobox list has the CBS_SORT style and the list is sorted according to the default user locale. Now that sort does take advantage of a great deal of Unicode since obviously there are many different languages and scripts that will be there.

And finally we have the UI language list. It is also in the Regional and Language Options control panel applet (only in the second tab), and lists the LOCALE_SNATIVELANGNAME (this is the name of the language of the locale, localized into that language, as I discussed the other day) of every installed UI language. The comobox is not sorted at all; since it is populate via a validated registry enumeration, the list will tend to be more or less in the order they were installed in, a very non-guaranteed order that is easy to muck with when languages are added or removed. So let's just call it a somewhat random ordering of various languages and scripts.

If you grew up watching Sesame Street like I did, you'll remember the game where they show four things, one of which does not belong. Well I have four things, so we can play. :-)

Which one do you think doesn't belong?

I vote for the second one, though others might find the first to be better in their minds....

 

This post brought to you by "ᢈ" (U+1888, a.k.a. MONGOLIAN LETTER ALI GALI I)

# Maurits on Friday, December 09, 2005 1:30 PM:

Why not avoid the issue by using an alternative UI widget... instead of a dropdown box, how about a tree-style navigation element?

+ European languages
|--+ English
|--+ French
|--|-- France (this is first in the French subgroup)
|--|-- Belgium
|--|-- ...
|--\-- Monaco
|--+ German
|--\ ...
+ East Asian languages
+ African languages
...

This still leaves open the problem of how to sort the root nodes, and how to sort the leaves of the subnodes... but it may improve usability!

This could be implemented as an Explorer-style tree... or a menu/sub-menu-style tree... or a drill-down style multi-widget system... or even a map.

# Michael S. Kaplan on Friday, December 09, 2005 1:39 PM:

I am not sure which list you mean this for? And of course languages that cross those boundaries (or boundaries at all in dispute) could be problem as well....

# Maurits on Friday, December 09, 2005 3:20 PM:

For all of the lists, of course. As well as others, such as IE's View | Encoding | More submenu.

Not sure I get your cross-boundary question. If a language can fit in multiple categories, put it in both! If a language doesn't fit in any category easily, make a Miscellaneous category.

# Michael S. Kaplan on Friday, December 09, 2005 4:36 PM:

Ah, but notice how the UI language does not list all the regions? So it makes no sense for that one.... For the others I think users may find it to be confusing if they see their language without their region -- so it would end up even less intuitive for many....

# Maurits on Friday, December 09, 2005 5:40 PM:

Huffman would say to put the frequently-used languages first. Then the challenge is, how to come up with an appropriate measure of "frequent use" for the audience of Microsoft software users?

# Michael S. Kaplan on Friday, December 09, 2005 5:49 PM:

Of course over 95% of all users never see any of the UI in question, which makes almost anything we do here for a small group.

Huffman's solution only works if we expect people to look at the whole list asnd want to optimize the search. But for msot, alphabetical covers their needs (so the user locale is best).

I should add that in all casesd, the intial selection is the current setting....

# Maurits on Friday, December 09, 2005 7:53 PM:

An even bigger challenge is to Huffman-sort the languages given the previous settings... so if the user knows Swahili, Mandarin, and Thai, they should go at the top of the list (like Word's font menu.) And the other languages should be sorted in descending order of relation to the known languages (closest relatives at the top.)

# Michael S. Kaplan on Friday, December 09, 2005 8:53 PM:

Hmmm... the usefulness of the related language proximity idea makes some assumptions that I think may be false to fact. Knowing Dutch does not mean that I would ever want or need Flemish to be there too....

# Gabe on Saturday, December 10, 2005 3:06 AM:

I think that clearly the right thing to do is to have the UI Language list always sorted the same way so that when a person wants to switch languages (which perhaps they might do every time they sit in front of a computer), that the procedure will be about the same each time. In other words, the relative positions of the entries on my computer should match the relative positions on your computer.

# Adam T on Saturday, December 10, 2005 4:09 AM:

Heh, it's nice to see the screenshot I made on my computer end up in an MSDN blog. It's the AppLocale screenshot -- the point I was making to Michael is that if the support for all languages is not activated in the system, the localized language list is a far less-than-perfect solution. The last four entries in the AppLocale list stand for Chinese Simplified, Chinese Traditional, Korean and Japanese -- but they all come out as boxes if you don't have the right fonts installed.

I believe that the only perfect solution is to present language names both ways: the language name in its own language along with the language name in the current locale's language. Different types of customers will need different captions. Somebody may be a beginner or intermediate speaker in Arabic but fluent in English. He would want to switch to the Arabic user interface but may be confused by the many variants of Arabic locales presented, written out in Arabic language -- so he'd like to see an English translation. In my own case, I needed to run a Japanese application using AppLocale without even knowing what "Japanese" is called in Japanese. In the end, I managed to find the right one and I could run the application. I can operate the application using hotkey combinations and icons, entirely without reading a single word on the screen. But it needed to run within a Japanese locale. So what I was looking for was a switch in AppLocale saying "Japanese" but in English. Of course, many other users will prefer to see "Japanese" spelled out in Japanese. So I guess these kinds of controls really should try to provide both.

+ European languages
|--+ English
|--|-- U.S.

Huh? U.S. English being a "European language"? I thought U.S. is in North America.

A.

# Adam T on Saturday, December 10, 2005 4:17 AM:

+ African languages
|--+ Arabic
|--|-- Egypt

I guess some would expect to find Egyptian Arabic under African languages (since Egypt, after all, is located in Africa), but some would not. Should Arabic be listed in severl groups because it's spoken so widely? What about Turkish? Would you list it in both European and Asian? Why list "East Asian" under a name that only denotes a part of a continent, while not splitting European into, say, "West", "North" and "East"? And then of course, the Polish people would expect their language to be listed under "Central European" while Americans would expect to find Polish under "Eastern European".

No, I don't think the idea of grouping would work. It surely would NOT improve usability. Most users have no idea which "linguistic group" their native language -- of any language, for that matter -- belongs to. Is Slovak Central Slavic or Western Slavic?

There may be users in the community who enjoy puzzle solving but I'm not sure the language selector is the right place to present them one.

Best,
Adam
Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day