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

[ESW Wiki] Update of "geoFaq1" by RichardIshida

From: <w3t-archive+esw-wiki@w3.org>
Date: Tue, 26 Apr 2005 06:48:49 -0000
To: w3t-archive+esw-wiki@w3.org
Message-ID: <20050426064849.9024.22516@swada.w3.org>
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "ESW Wiki" for change notification.

The following page has been changed by RichardIshida:
http://esw.w3.org/topic/geoFaq1


------------------------------------------------------------------------------
  
  === Pros and cons ===
  
- Pull-downs can be 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 you.
+ Pull-downs can be 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.
  
- If your site supports only a handful of locales, it is probably better to avoid using a pull-down menu altogether and simply include links directly to each locale. This gives you more flexibility to use graphics to represent non-Latin text, avoids the difficulty of finding a suitable non-linguistic label for the list, and 
+ 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 non-Latin 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.
  
  If your content is available for 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. In this case 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.
  
@@ -43, +43 @@

  
  If you do decide to use a pull-down menu, here are some best practices to keep in mind.
  
-  1. Locate the pull-down menu at or near the top of the page. This location is highly visible, reducing the chance that the visitor will not see it. Scanning studies show that for pages in left-to-right scripts positioning to the right side 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.
+  1. Locate the pull-down menu at or near the top of the page. This location is highly visible, reducing the chance that the visitor will not 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.
  
-  2. 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 some way off, though.  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.
+  2. 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 some way off, though.  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. People reliant on screen readers would be able to traverse the pull-down text to find the right link.
+  The language of the alt text for such a graphic doesn't have a great deal of importance. People reliant on screen readers would be able to traverse the pull-down text to find the right link.
  
   3. Translate the menu options into the target language. Instead of including a link on the pull-down menu that reads, for example, "French" the link should read "Français."; and instead of "Germany" the link should read "Deutschland".
  
  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 [http://www.w3.org/International/tutorials/tutorial-char-enc/en/all.html#Slide0420 escapes] to represent characters that are not supported by the encoding of your page.
+ First, you need to think about the encoding of your page. Preferably you would 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 [http://www.w3.org/International/tutorials/tutorial-char-enc/en/all.html#Slide0420 escapes] to represent characters that are not supported by the encoding of your page.
+ 
+ Secondly, you must also think about 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.
+ 
+ Herein lies one of the difficulties of dealing with pull-downs.  You do not have the option of using graphics within the list to represent non-ASCII text. An alternative you sometimes see is to embed non-Latin text within graphics located outside of the pull-down menu.
  
  
- 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.
+ [[RI How does one assign fonts?  Do you need a universal font for the whole select list, or can you assign fonts on an option by option basis?]]
  
- 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)
+ In some cases you may want to consider adding the names of the languages or countries in your list in the language of the current page, in addition to the native script and language.  Using parentheses is useful because it shows that this is a clarification. It may help users understand why there are empty boxes if they see ?? (Japan).  Note that this list should really be translated for every page where it appears - it is not good to leave it in English, since it may give the wrong message.
  
+ There is also the question of how to order a list of language or country names.  There is no simple answer to this. It is not an issue that is specific to pull-downs, however use of maps for selection get around the problem.
- '''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.'''
  
  ****
  
@@ -92, +74 @@

  
  ****
  
- '''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)    <---- instead of 日本 
+ [[AP    ?? (Japan)    <---- instead of 日本 
  
      USA
  
@@ -118, +92 @@

  
  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.'''
+ 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.]]
  ----
  == 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.
  
Received on Tuesday, 26 April 2005 06:48:53 UTC

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