RE: New FAQ: Global Gateway

John, many thanks for putting this together!

See my comments below...

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

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

http://www.w3.org/International/ 
http://www.w3.org/International/geo/ 

W3C Internationalization FAQs
http://www.w3.org/International/questions.html
RSS feed: http://www.w3.org/International/questions.rss



> -----Original Message-----
> From: public-i18n-geo-request@w3.org 
> [mailto:public-i18n-geo-request@w3.org] On Behalf Of John Yunker
> Sent: 12 November 2003 15:33
> To: public-i18n-geo@w3.org
> Subject: New FAQ: Global Gateway
> 
> 
> 
> Hi all,
> 
> I'd like to submit the following as an FAQ on global 
> gateways. It is quite long (perhaps too long) 

Not necessarily ;-)

>and needs a bit 
> of work yet - please send me your comments.
> 
> I'd also like this to be a starting point for discussing best 
> practices in global navigation - something that we can 
> incorporate into the "Authoring Techniques" section on navigation.
> 
> Thanks...
> 
> ================================
> 
> Global Gateway FAQ
> 
> QUESTION
> My company has developed a number of country-specific Web 
> sites. How do I ensure that visitors to our global ".com" 
> home page find their country-specific sites?

Since I think you intend this to incorporate language sites too, perhaps
'country-specific' -> local or localized
Or even: how do I ensure that visitors to our global home page find the
local sites my company has developed?

> 
> ANSWER
> You need to develop a "global gateway" strategy. A global 
> gateway is an umbrella term for the visual and technical 
> devices you employ to direct users to their locale- and 
> language-specific Web sites.
> 
> A global gateway may employ one or all of the following devices:
> 
> 1.	Localized URL (country- and/or language-specific)
> 2.	Content Negotiation
> 3.	Splash Gateway
> 4.	Permanent Gateway
> 
> Ideally, the elements are used in concert to ensure that Web 
> users find the sites they need as quickly and seamlessly as 
> possible.

Very good point !

> Here is an overview of each device:
> 
> Localized URL
> 
> The URL is the most direct path to a localized Web site. At a 
> minimum, if you have a country-specific Web site, you should 
> register for a country-specific domain, such as www.foo.fr 
> for France or www.foo.br for Brazil. Country-specific domains 
> also help your site perform better in local search engines.

For example URIs we should say 'www.example.fr' etc.

> 
> Companies may also register domain names in non-Latin scripts 
> (sometimes referred to as internationalized domain names). 

Or IDN.

> For example, a company in Korea, Netpia (www.netpia.com) 
> offers support for Korean-language domain names. However, be 
> aware that the DNS currently only supports a subset of the 
> ASCII character set; all non-Latin workarounds are just that, 
> workarounds. Keep an eye on ICANN (http://icann.org) for 
> developments on internationalized domain names.

This is now out of date.  The IETF approved IDN in March this year.  It
is defined in RFCs 3490, 3491, 3492 and 3454, and already works on
Mozilla 1.4 / Netscape 7.1 and Opera 7.2.  The domain name is actually
still registered using a subset of ASCII characters, called Punycode,
but browsers above can convert native script URIs to this form.  For an
excellent overview of this see Internationalized Domain Names, K. Momoi
http://devedge.netscape.com/viewsource/2003/idn .  .jp and .cn already
support IDN (In Beijing this week I spoke with the head of the .cn
domain name org.)  Note also that all other approaches to this are now
disallowed in IDN.

This is of course too much detail for the FAQ.  We should probably say
here that domain names in local script are supported in many domains,
eg. .jp and .cn, and give an example - I have one in Chinese.  I don't
know whether it's worth mentioning in this FAQ that it makes sense to
register an alternative ASCII version of the domain name too, for those
who can't, eg, type in Chinese characters.

> 
> Content Negotiation
> 
> A Web browser, by default, will tell a Web server what 
> language it prefers when it requests a Web page. If a Web 
> server has multiple language versions of the same Web page, 
> it may be configured to respond with the matching language; 
> this process is referred to as content negotiation or 
> language negotiation and is invisible to the Web user.
> 
> Google (www.google.com) relies on content negotiation. 

I'm not sure that this is correct.  When I was in Budapest I got Google
automatically displaying in Hungarian, and on my home computer Google
comes up in Spanish.  I have neither of these languages in my list of
preferred languages.  I think it may use IP addresses.

>To 
> test it out, using Internet Explorer, go to Tools > Internet 
> Options > Languages and set a different language preference. 
> The language at the top of the list is the one you want 
> delivered to you first. Using Netscape Navigator, you select 
> Edit > Preferences > Navigator > Languages.
> 
> (Iinclude screen shots of both browsers preference screens)
> 
> After configuring your preference, exit your browser. Open it 
> back up and visit Google. The home page should not match your 
> first preference, unless you picked a language Google does 
> not support (Google supports more than 60 so far).
> 
> The downside to content negotiation is that many Web users do 
> not know how to re-configure their browsers should they wish 
> to change their language preference; this can be frustrating 
> for multilingual Web users or people who share a computer.

There are additional downsides, some of which are described in a
previous FAQ [ ].  In my presentation in Beijing I said:
-	the user may have never checked the Accept-Language setting
-	user agent may send a request that specifies only a language and
not a region 
(a particular issue if trying to establish locale for information like
date formats)
-	people borrow machines from friends, they use them in internet
cafes - in these cases the inferred locale may be inappropriate
-	always allow the user to select the appropriate language (and
locale) from whatever page they are looking at !

I think we should make the last point clearly. 

The example I used was http://www.w3.org//Press/1998/CSS2-REC 


> 
> Splash Gateway
> 
> A splash gateway forces the user to select his or her locale 
> before entering the main page of the site. The benefit of a 
> splash gateway is that ensures that visitors know what 
> locales are available to them; the liabilities of this 
> approach is that it draws attention to the fact that a 
> company many not offer many locales.
> 
> Splash gateways can also be annoying to repeat visitors. 
> Therefore, if you use a splash gateway, you should also rely 
> on cookies to save the user's language preference so that the 
> splash page is bypassed on return visits. eTrade 
> (www.etrade.com) uses a splash gateway and cookies.
> 
> (Screen 
> shot of eTrade splash page)

There are a number of things we could say about splash gateways in a
longer format, but I think we should at least say here that the splash
page should be language agnostic, and that the names of all countries /
languages should be in the language and script of that country.


> 
> Permanent gateway
> 
> If can only use just one global gateway element, this is the 
> one to use. The permanent gateway should be clearly visible 
> on every Web page, ideally located on the upper right-hand 
> corner of the page (most gateways are located in this area). 
> A permanent gateway is critical because not all users arrive 
> at your site through the "front door."

At this point, I still don't a clear picture in my mind of what we're
talking about here.  Would it be better to call this 'In-page links' ?


> 
> There is an art to designing a gateway - balancing creativity 
> with usability. A globe icon is becoming a default icon for 
> indicating a global gateway.
> 
> If your site has four or fewer locale selections, it makes 

Depends to an extent on the space available and type of site.  Maybe we
should be less firm about the number, and just say, 'if space allows'.

> sense to place direct links to each of these sites as shown here.
> 
> (Screen shot example)
> 
> If your site has more than four locales, you may need to use 
> a pull-down menu.

Be very careful here.  Pull down menus are notoriously bad for support
of multiple scripts and languages.  It may also be equally valid to link
to another page - especially where there are a large number of
alternatives, or where regional groupings are used that can most easily
be indicated by a map.  Some sites use dynamic HTML (see eg the former
eTranslate).  I would suggest we replace 'use a pull-down menu' with
'expose a selection list or page'.  


> 
> (Screen shot example)
> 
> 
> BY THE WAY
> 
> Translate the links
> Don't forget to translate the names of the languages in the 
> gateway. For example, don't use "German" when you can use 
> "Deutsch."  Always use the native language of your user.

And script!  Don't use 'nihongo', use the japanese characters.  This is
where difficulties arise, because you can't expect everyone to have the
required fonts to show all options in a list.  I think there is a good
case for using graphics rather than text for these items - since they
never need translation that's ok.  The problem with graphics, of course,
is that they are not supported in pull-down lists yet (watch out for
XHTML2).  

Good as this FAQ is, thinking about these things makes me suspect that
it might be good to work on the guidelines re navigation a bit more, so
that we can work through some of the questions a little more in a
coordinated fashion, then use this FAQ to summarise and point to the
detail.

> 
> Avoid flag waving
> Unless you offer a site specific to most countries, flags can 

I think perhaps you mean "Unless you offer sites that are only
associated with specific countries..."

> be troublesome. For example, what flag do you use to 
> represent a region or a language?
> 
> 
> ADDITIONAL LINKS
> 
> ICANN
> 
> Other links?

I just remembered I wrote a paper on this topic for a Unicode conference
a while back.  I'll try to find a copy and send it out when I get back -
for what it's worth.  

> 
> 
> 
> ================================
> John Yunker
> jyunker@bytelevel.com
> Byte Level Research
> 

Received on Sunday, 16 November 2003 19:27:00 UTC