Re: Official ISO 3166 country codes online

At 19:27 1999/11/27 -0700, Sean M. Burke wrote:
> At 10:32 AM 1999-11-26 -0800, you wrote:
> >The biggest downside to this list 
> [ apparently referring to
>   http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1 ]
> >is that it is only the region-specific codes, even though
> >applications like Netscape and IE use the language and region
> >when there is a need for clarity.


> The fact that countries aren't the same thing as locales or languages is a
> well-known problem; and it's why we have locale IDs and language codes.
> Anyone who tries to represent a locale with a country code, or a country
> with a language code, etc., is obviously misguided, and shouldn't be
> localizing anything.

> If a user agent requests an object while expressing a preference for
> "ar-ma" (Moroccan Arabic), if the server sees that the closest thing it has
> is an object tagged as being in "ar" ("generic" Arabic), yes, this would be
> probably the best thing under the circumstances.
> 
> However, answering an "ar-ma" request with an "ar-sa" (Saudi Arabic) object
> seems decidedly less of a good idea; if the object in question is an audio
> object, the Moroccan-speaker might find it quite unintelligible.
> 
> 
> I'm aware of no single good solution to this problem -- particularly not
> for Arabic or Chinese, where what "ar" or "zh" means varies so greatly
> depending on the medium in question.

There are other cases where a single prefix can include a very
wide valiability, in particular x- and i-.

HTTP clearly defines how cases like the above have to be handled:

If a client requests ar-ma, only a document tagged ar-ma or ar-ma-??
must be returned. If a client requests ar, then a document tagged ar
or ar-???, i.e. ar-ma or ar-sa can be returned. If a user selects
e.g. ar-ma in a browser, the browser should either by itself add
ar (with smaller priority) to the list of languages, if the browser
has the necessary knowledge that this may be acceptable, or point
out to the user that it may be a good idea to select ar, too
(if the user has to decide for that language).

A similar thing applies to selection of styles with stylesheets,...


> In these specific and problematic cases, I'd suppose that implementors
> could specially treat them by access to a table somewhere expressing the
> extent to which the average speaker of ar-X would accept an object in ar-Y.
> It's my guess that you'd need at least three tables for different media:
> writing, audio, video (that is, video without writing -- unlike Chinese TV
> shows I see that are in spoken Mandarin, but subtitled in written Chinese
> for the benefit of people who can read Chinese, but can't understand spoken
> Mandarin).
> Moreoever, the concept of "average speaker of ar-X" may also be fishy, or
> may change greatly over time.

The idea to have such tables on the server side was rejected, because
in the general case, there are too many individual differences.

The point about differences for writing, audio, and video is a good one.
Language negotiation would work here provided the following:

- The browser knows the type of stuff requested (usually the case)
- The browser maintains separate info for each type, and has a UI
  that allows the user to specify this (not seen this yet)
- There are appropriate tags available/in use (I wouldn't know what
  tag to use for Mandarin Chinese, for example).


Regards,   Martin.


#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:duerst@w3.org   http://www.w3.org

Received on Sunday, 28 November 1999 19:19:23 UTC