W3C home > Mailing lists > Public > public-i18n-geo@w3.org > January 2005

Gateway FAQ comments

From: Richard Ishida <ishida@w3.org>
Date: Mon, 24 Jan 2005 20:00:04 -0000
To: "GEO" <public-i18n-geo@w3.org>
Message-Id: <20050124200005.60BFD4F05B@homer.w3.org>

In an attempt to make it easier to review comments, and propose solutions, point by point, I have compiled all comments on John's FAQ from Martin, Addison and John.  I have then proposed solutions to those, myself - all preceded by RI. 

Please comment by email, and let's take any necessary decisions at next week's telecon (assuming that John will be back from Japan).

First a bit of process stuff: The whole text of the FAQ is here, paragraph by paragraph, with relevant comments sandwiched between.  Each point made begins with the initials of the author, and continues until the next author's initials or the next quote from the FAQ.  Multiple points by the same author on the same piece of text are preceded by multiple initials and separated by "===".  Related comments, and replies are grouped together were possible.

If you add comments on any of these topics, please copy out the relevant bit of text only, and use separate emails for separate points where you can.  This will make things easier to collate.

RI


==============================
FAQ: What are the best practices for using a pull-down menu on my company's 
Web site to direct visitors to their country Web sites?

MD: Is this the only FAQ on Global Gateways that we will ever have? If not,
I suggest to thange the title to "FAQ Global Gateway Pulldown" or some such.

JY: Good point. I expect there will be others on this topic.

GEO telecon: let's use a more specific title, eg global gateway pulldowns, as there is more to be said on global gateways 

===
AP: 1. I think it mixes up several different applications for a "pull down" which should be kept separate:

  - Selecting the language of the current content (i.e. "show me this site in French")
  - Selecting a different site or section of a site targeted to a different country audience (i.e. "show me the site for France")
  - Selecting formatting and other preferences, possibly as a combination of the above (i.e. "show me information on this site formatted using the French/France locale")

These are not the same application and the best practices here only apply (I think) to one of them (the middle one).

MD: I agree halfway with Addison here. Often, these three are combined.
Most formatting usually goes hand-in-hand with the language. And
there is usually only a small combination of courtry/language pairs.
How much a site empazises language or country may depend on business;
amazon for example is very much language-oriented (e.g. they ship
French books everywhere in the world from their French(France) site,
but you order in French) because the product is language-oriented
and the business isn't legally tied to a country. Things might be
much more country-oriented for e.g. a company offering legal services,
or a big global company that is traditionally organized in per-country
subsidiaries. But having more than one 'global gateway' doesn't
make sense.

So I think the FAQ should mention both language and country, but
should defer the exact relationship between them maybe to a separate
FAQ. And I don't think it should mention formatting conventions,
in this context, they are (or should be) a detail.

RI: I agree with Martin.  I think we should not get too specific in this FAQ about the type of link.  Therefore I suggest s/direct visitors to their country Web sites/direct visitors to localized Web sites/.  Note that this avoids the locale word.

===
AP: 4. The question's phrasing is awkward... Might I suggest:

What are the best practices for using a pull-down menu to direct visitors to a country- or language-specific content (such as a country Web site)?

I think this makes more sense because not all websites belong to a company. Also "country Web sites" are not always what is being accessed.

MD: Agreed, except that the phrase in parentheses can probably go;
the title is already very long.

RI: I propose the following text: "What are best practices for using a pull-down menu to direct visitors to localized content?"



==================================
FAQ: > Background
 >As companies 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 that includes links to 
the other locales.

AP: 2. The word "locale" is used sloppily and without introduction. In fact, I think the first occurrence ... Really refers to the other use of the word "locale", meaning something like a country site and not a software locale. The word locale, to the extent possible, should be expunged or very clearly handled, since the target audience is not other I18N-aware folks such as ourselves.

MD: Yes, I think 'locales' should be replaced with something like
'languages/countries'.

RI: I suggest "that includes links to localized versions of the content (eg. translations or alternative country sites)."



===================================
FAQ:  > Answer
 >The pull-down menu is not a silver bullet for global navigation and it 
may not be the best solution for your Web site. If your site supports only 
a handful of locales, it is better to avoid using a pull-down menu 
altogether and simply include links directly to each locale. Also, if your 
company offers more than 20 locales, a pull-down menu is not very usable 
for those Web users who must scroll to the end of the list.

MD: This is somehow given in the background, but should probably also appear in the
answer: A pull-down menu can very well be a good solution! [i.e. say things
positively rather than just let the reader infer that if the concerns don't 
apply, it's a good solution (or, if you don't think it's that a good solution in 
general, say so more clearly)]

GEO telecon: divide into: 1) should I use a pulldown? 2) best practices.

RI: It is important to make the point that pulldowns can have significant drawbacks, and should be used with care.  It may help to actually focus more attention on the reason we are saying this. Suggest we have two subsections in the answer with headings "Should I use a pulldown menu?" and "Best practises for use of pulldowns".   

===
AP: 3. The phrase "silver bullet" is not a globally accessible metaphor. Depending on your culture you need to know either the Lone Ranger or all about werewolves, I suppose?

MD: Yes. It's a true (but somewhat sad) fact that globally oriented
English has to abstain from most metaphors.

RI: John's decision.





==================================
FAQ: >However, if you do decide to use a pull-down menu, here are some best 
practices to keep in mind:

MD: Probably leave out the "However,", or reword more positively, such as simply
"When using a pull-down menu,..."

RI: John's decision.



=====================================
FAQ: >1. Locate the pull-down menu at the top of all Web pages, preferably to 
the right side. This location is highly visible, reducing the chance that 
the visitor will not see it. Furthermore, an increasing number of Web sites 
have located their global gateways in this location, conditioning Web users 
to come to expect it here.

AP: 5. I think the discussion of pull-down location should be more generalized. Perhaps something like: 
"The right location of the site selection box depends on the design of the page and the relative importance of finding alternate language or country sites to the home page. Putting the drop down box in the upper right corner makes the selection prominent and easily located. Many sites place it in that location for this reason."
Location is a usage consideration that should be carefully considered as part of the design and making it a best practice to put it in such a prominent position ignores the considerations that might go into locating such an item. I think the discussion of not overly favoring the USA site is a good one.

RI: The suggested location of the pull-down originates from studies of user scanning behaviour, generalised over many different designs of web page, and from the need to find those links quickly if you need to switch.  I think it makes sense to propose that designs allow for it to be located there.  Note that we are not dogmatic here, especially wrt the right side. I think John's text is ok.



=====================================
FAQ: > 2. Include an icon of a globe or map next to 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. Over time, the globe icon could be as widely 
recognized as the shopping cart icon. See the example below from the 
Philips Web site. (image: philips.jpg)

MD: map -> world map? (coul be any map otherwise)

RI: Hmm. In general I'd agree that world map would provide a recognisable cue. But I suppose that if someone's Web pages only catered for, say, European countries, a map of Europe may be appropriate??  I'd say it's John decision.

===
MD: "Over time, the globe icon could be as widely recognized": Can we say something
like "The globe icon is more and more getting recognized ..., "? I.e., can
we express this in a way that says that it's already starting to be recognized
rather than say that we are not yet there?

AP: 6. The discussion of an icon is interesting. The example of a shopping cart is slightly bad: some companies localize this to a basket for certain locales precisely because the icon is *not* recognized.

RI: Suggest we say something like "Over time, the intention of an icon representing a globe or world map could be as widely recognized as the various icons used to represent shopping carts, baskets, etc."

===
AP: 8. I don't agree with including example shots of other folk's websites. I think we'd be better off mocking up examples, since commercial sites change design format.

RI: I think this is a difficult one.  Showing real applications creates immediacy and interest for the reader, and shows that this is not purely theoretical.  On the other hand, they can indeed become out of date or even contradicted by later practise on the same site.  On the third hand, there are very few sites that do everything perfectly, and this is one in my mind, since it includes text in English too.  I think we need more discussion.



========================================
FAQ: >3. Translate the menu options as necessary. Instead of including a link 
on the pull-down menu that reads, for example, "French" the link should 
read "Fran軋is."

MD: This needs to more clearly indicate that each language label is supposed to be
in the target language.

AP: 7. Translate the menu options is nice. The example should probably mention a country though instead of a language. I think it is better to be consistent here: if you are finding a country site, then the country name should be featured. The problem here is mixing language selection and country selection.

RI: Despite earlier proposals to abstract away from the country vs language debate, I agree with AP that a country name would be better here, but for the reason that links to country sites, in my experience, are the worst offenders in this regard.  It is also slightly less intuitive to a designer, in my experience, to need to translate country names.  So use of a country name would have more impact on the reader, I believe.



=========================================
FAQ:  >To display a mix of non-Latin languages, such as Arabic, Russian and 
Japanese, your Web page will need to support the UTF-8 (Unicode) encoding. 
Please note that if you do switch to UTF-8, the Web user must have a font 
that can display this range of scripts; most new operating systems do ship 
with such a font. Be aware that a Web user in the US, for example, may see 
empty boxes in place of the Japanese text while the user in Japan will see 
the text just fine.
 >
 >If you do not want to change encodings, an alternative is to embed 
non-Latin text within graphics located outside of the pull-down menu, as 
demonstrated by the Symantec Web site. (image: symantec.gif)

MD: What about numeric character references? In a decent browser, these are
supposed to work as well as the actual (e.g. UTF-8 encoded) characters.
Pull-downs, similar to title bars, often have more limitations than the
page itself, but this is usually due to the browsers calling the system
widgets, and these in turn using the system character encoding rather
than Unicode (in particular on older systems or when not using wide-character
APIs). But in this case, this is not an encoding issue, and should not
affect what ultimately shows up in the pull-down.
There are other browsers (in partilar Netscape 4) that do not correctly
interpret numeric character references, but these browsers should be
ignorable by now.

JY: Good point. My only concern is that the process of converting 
characters to their numeric equivalents would probably merit an FAQ of 
its own. But this probably should be mentioned as a workaround.

MD: Having an FAQ about numeric character references is a good idea.
Probably there could also be a separate FAQ about things like pulldowns
and their limitations on certain browsers, or that could go into the
techniques.

But it definitely needs to be mentioned here, because otherwise
people who know about it will get the impression that it won't
work in this case.

AP: 9. The discussion of UTF-8 is good. You might also mention the use of entities to encode names into pages that are otherwise Latin-1 or legacy encoded.

RI: I think there are two topics here: [1] encoding [2] fonts.  It might help to more clearly separate them (separate paragraphing would be a good start).  

How about something like:
"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. An ideal approach would be to use UTF-8 (Unicode) encoding for your page, since this encoding supports all the character 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." The word 'escapes' could link to http://www.w3.org/International/tutorials/tutorial-char-enc/#entities

Then a separate para, or even a separate point, about fonts.  Note that you also need a universalish font if you use escapes rather than UTF-8, so the initial sentence could be generalised more. For example: "Please note that if you need to display non-Latin text the Web user must have a font 
that can display this range of scripts".  Where it says "most new operating systems", I think the meaning is "most localized versions of new operating systems", or are you saying that universal fonts exist on most PCs?  If so, you need to massage the following sentence, since the issue is that of font use. 

===
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 ;)

===
AP: 10. You might want to add to this discussion:

Be aware that a Web user in the US, 
for example, may see empty boxes in place of the Japanese text while 
the user in Japan will see the text just fine.

And point out the need to include ASCII or English identifiers or use bilingual entries in the list. If the site is available in multiple languages it sometimes makes sense to make the drop down accessible to users in the current page language too. For example:

  日本 (Japan)
  USA
  France
  Deutschland (Germany)

Although RFC 3066 or ISO 3166 identifiers are sometimes used for this purpose, I would tend to caution against them because they are in many cases obscure to users.

MD: [AP says] "it sometimes makes sense". When/why?

MD: [AP cautions against RFC ids] Yes.

RI: I see the inclusion of labels in the language of the current page as a separate point in the list of best practises, if included. It might be worth discussing in what situations this is useful.  I don't think it is necessary in all cases.




==================================
FAQ: General points

AP: 11. You omitted the problematic discussion of list organization. This is actually an interesting topic and probably deserves its own FAQ. I had some issues with that text in the previous version, but would suggest that you consider revising and contributing on that topic separately in the future.

RI: This is indeed an interesting question, though not one for which I see any clear answers.  I think it may be worth alluding to it in this FAQ, even if we have to admit that we don't really know the answer.  It would be good to discuss this.  Of course, this is also one of the good reasons for avoiding the use of lists, and going for, say, a map based selection.


===
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...



============
Richard Ishida
W3C

contact info:
http://www.w3.org/People/Ishida/ 

W3C Internationalization:
http://www.w3.org/International/ 

Publication blog:
http://people.w3.org/rishida/blog/
 
Received on Monday, 24 January 2005 20:00:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:02 UTC