ITS WG Collaborative editing page

Follow the conventions for editing this page.

Status: Initial Draft ie. please focus on technical content, rather than wordsmithing at this stage.

Author: John Yunker/Richard Ishida

---

Using <select> to Link to Localized Content

What are the best practices for using pull-down menus based on the select element to direct visitors to localized content?

Background

As companies and organizations launch an increasing number of localized Web sites, user-friendly global navigation grows in importance. The term "global gateway" is frequently used to refer to the visual and technical devices that Web sites employ to direct visitors to their content. One of the more popular devices is a pull-down menu on the home page using the select element that includes links to localized versions of the content. Such selection lists are not restricted to use on the home page, but may also be seen as a space-effective way of allowing users to switch between translations or regionally localized sites on a page by page basis.

The localized content pointed to may be an alternative country site, a translated version of a site or page, etc. In this article we avoid discussion of the best practises associated with pointing to translated and/or region specific sites; we look specifically at some of the pros and cons of using selection lists, for whatever purpose, and best practises if you think this approach is right for you. There are numerous other aspects to global navigation that will be described in other articles.

Answer

Note that these recommendations do not apply to selection lists that are part of a form. For example, if you are filling in a form and selecting your country of residence or language from a list the selection list should be all in the language of the current page.

Should I use a <select> list at all?

Pull-downs can appear very attractive where space is at a premium. However, the pull-down menu is not always the best solution for global navigation and you need to decide whether it is the best solution for your Web site. The following points may help.

The key advantage of using pull-downs is to fit the selection into a smaller space.

Key disadvantages of using select for links to localized pages or sites are:

users may not have fonts for all the option text, and graphics cannot be used instead of text
it is hard to find a label for the list that is not language-specific
users cannot see or access the links straight away

If your site supports only a handful of localizations, it is probably better to avoid using a pull-down menu altogether and simply include links directly on the page. This gives you more flexibility to use graphics to represent foreign text, avoids the difficulty of finding a suitable non-linguistic label for the list, and allows users to recognize the presence of and link to a page much more quickly.

There are other techniques, too. For example, outline maps can be used to select region- or country-based local sites.

If your pull-down points to more than 20 other sites or pages you should consider whether this is usable for those Web users who must scroll to the end of the list. If not, you may consider linking to a dedicated global gateway page at the home page level. If linking between localized versions of specific pages, this may not be a practical solution.

Best practises

If you do decide to use a pull-down menu, here are some best practices to keep in mind.

Location. Locate the pull-down menu at or near the top of the page. This location is highly visible, increasing the likelihood that the visitor will see it. Scanning studies for pages in left-to-right scripts show that positioning to the top right increases visibility. Furthermore, an increasing number of Web sites have located their global gateways in this location, conditioning Web users to come to expect it here.

Certainly avoid putting the list at the bottom of the page so that it is likely to appear below the 'fold'.

Labelling. Come up with a graphic design to serve as a label for the pull-down menu. You cannot expect Web users who are not fluent in English to understand "Select language". Universally recognized icons communicate to people regardless of what language they speak. In an ideal world there would be a widely recognized symbol for this. That time is still not here, though globe icons seem to be becoming more popular.

Examples of possible graphics would include globes, iconic facial profiles with lines to indicate speech, alphabetic characters from multiple scripts (especially for links to translations), etc.

The alt text for such a graphic doesn't have a great deal of importance. You may think that it needs to be in all languages, or no particular language, for accessibility, but in reality people reliant on screen readers would be able to traverse the pull-down text to find the right link.

Translate options. Translate the menu options into the target language. Instead of including a link on the pull-down menu to a translation that reads, for example, "French" the link should read "français"; and instead of a link to an alternative country site like "Germany" the link should read "Deutschland".

Pay attention to capitalisation rules in other languages. Note how the correct translation of "French" is "français" with a lowercase 'f'.

Encoding To display a mix of non-Latin languages, such as Arabic, Russian and Japanese, you will need a way to represent all the required characters.

Preferably you would use UTF-8 (Unicode) as the encoding for your page, since this encoding supports all the characters you will need. If you cannot use UTF-8, then you should use escapes to represent characters that are not supported by the encoding of your page.

Fonts You must also think about whether the reader will have fonts to display this range of scripts. Be aware that a Web user in France, for example, may see empty boxes in place of the Japanese text while the user in Japan will see the text just fine. This is because the fonts available on the French user's system may not contain Japanese glyphs. One could argue that this is not too important, since French users don't need to be able to read the Japanese. On the other hand, you may feel that empty boxes are unsightly.

If you feel that empty boxes are unsightly you may be tempted to use text in graphics for non-Latin options. Unfortunately, it is not possible to include graphics in the selection list itself, but some sites add such graphics outside the pull-down menu.

[[1]]

Be warned, however, that addressing non-Latin text this way may still not solve all problems. Certain accented Latin characters, such as those in 'čeština' may produce the same effect for some users who have Latin fonts that only cover Western European languages.

Descriptions In some cases you may want to consider following a name of a language or country in native script/language with the name in the language of the current page.

For example:

français (French)

Using parentheses is useful because it shows more clearly that this is a clarification.

This approach is not always necessary or desirable. On the other hand users may feel more comfortable with missing font glyphs if they see

??? (Japan).  RI replace these in the html with a picture of missing glyph glyphs

Note, also, that names in the language of the current page should really be translated for every page where they appear - if you leave them in English it may give the wrong message.

Using the size attribute In some cases it may be effective to use the size attribute to display the first set of options in the list - particularly if this is a long list. This suggests to the user that this is a collection of languages/regions, and may remove the need for a non-language-specific label for the list. Here is an example:

[[2]]

Ordering There is also the question of how to order a mutilingual list of language or country names. It is not an issue that is specific to selection lists, and there is no simple answer to this.

By the way

You should not consider automatic content negotiation to be a replacement for providing links on a page. It always makes sense to provide in page links for occasions when things don't work out as expected.

This article is specifically focused on the use of the select element. Some designers may prefer to use JavaScript to simulate pull-down lists. This can help in that you are not limited to text - you can use text in graphics to avoid font issues. There are, of course, other potential problems associated with the use of JavaScript.

NOTE: THE CURRENT ARTICLE ENDS HERE!!

Comments relevant to other FAQs

RI: I think we should break out some of the tutorial material about escapes into a couple of FAQs: [1] What is an NCR/entity/escape? [2] When should I use escapes? Any offers? (Hint: it's almost a cut & paste job

))

[FTF 4mar] Agreed RI to do this.

Do you include links to localized sites on every page?

[[DC Re 'global gateway', are we seeing this as a sort of homepage? Given more and more deep linking, ie, linking into an information page within the site, should locale/language altenatives be offered on every

page? Eg, I may send a product page to a friend who speaks English, but prefers French, would they have to return to a homepage to see if that page existed in their prefered language with their preferred locale information (especially given the English locale page may not permit purchase and delivery where they live).

Suggestion: that locale/language alternatives are available on every page. Additionally, this would be a driver for using a drop-down, where the main focus of the page was information, rather than dedication to language/locale alternatives. However, there is a distinction between: - Sites that offer each and every page in each and every language, eg, where each and every product is available globally and the differences are language, currency, delivery, variation in product spec/branding, etc. - Sites like BBC World Service and Boeing (SM?) where a different cut of information is offered according to language/locale, eg, with BBC WS each news page is not available in each language.]]

[[SM I certainly see 'global gateway' as home page only. I can't imagine a scenario with loc. alternatives on every page. The only time Boeing has non-home page link is on a very few news releases translated for some reason, where at top of page is text link like "en espanol"]]

Can flags be used for language+region combinations, eg. fr-CA

[[DC You don't always get a globe icon with the Philips site, sometimes a flag. I googled 'Philips', choose the first likely link and got http://www.philips.co.uk, which contained the drop down in the same position but with a UK flag. The globe icon seems to function to show that there are language/country alternatives, the flag icon seems to confirm where you are. How would that read if I end up on a particular language/country

page and want to choose an alternative? Would that happen? Would I read the flag as one possibility of other country/language alternatives? I'm uncertain about the use of flags, though I suppose it works as an indicator of locale AND language. Also, I think content neg with geo ip is difficult where people live in countries where their language is not an official language of that country. My English-speaking mother has had

problems with this in Portuguese-speaking Madeira, where she is sometimes offered a page she can't understand.]]

[[RI Sometimes, but not always. For examples, how to treat Swiss German, vs. Swiss French vs. Swiss Italian? The problem here is that the language is a subdivision of country rather than the other way around.

Also, what do you do if you distinguish(as many companies do) between es-ES and es-for-Latin-America?

Or what if you can't afford to localize into all the flavours of, say, English that would cover people in all the English speaking territories that come to your site?]]

language vs country sites & use of flags

AP: 12. Going back to my first point, the difference between language, site content, and geo-location is an important one to this FAQ. The interplay between these three choices is a fundamental site implementation choice and our FAQ should make that clear. The use of flags for language identifiers and the use of language names for country identifiers are both, in my opinion, a bad choice for this application. It has to be clear why this is the case, though, by spelling out that these are actually different applications and what the difference is.

RI: I think mention of flags is leading us out of the pulldown-specific FAQ and into more general aspects of navigation. I think, as said earlier, that it is best for this FAQ to abstract away from questions of whether we are dealing with languages or countries etc. There is definitely another FAQ to be written about country vs language vs locale, but that, as they say, is another story...

common concepts

[TT: 16 feb] I would consider taking the comments that are not pulldown specific and making them general comments. For example, location, globe icon, utf-8, use of graphics etc. could be stated as considerations having nothing to do with pull-downs, but general techniques that may also be used for pull-downs.