W3C home > Mailing lists > Public > www-international@w3.org > April to June 2008

RE: [Comment on WS-I18N WD]

From: Phillips, Addison <addison@amazon.com>
Date: Mon, 16 Jun 2008 12:42:58 -0700
To: Dan Chiba <dan.chiba@oracle.com>, Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
CC: "www-international@w3.org" <www-international@w3.org>
Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA013B11C6F9@EX-SEA5-D.ant.amazon.com>
> A search engine whose help is provided in English and German is
> indeed a
> good use case for the requirement to identify the UI language
> independently from locale. For example, a French speaking user in
> Switzerland would want German translation and Switzerland locale
> conventions for datetime and number formatting. Then #1 locale="fr-
> CH"
> and #3 language="de".

I disagree. A French speaking user in Switzerland will not want to see something bizarre like "A trouvé 1.624 articles le 1. Juni."

Users may have a separate language element to their search (that is, a French speaking user might search for a word like "Zeitung", which is German). But they don't want mixed UI experiences.

> Support for non-translation locale sensitive operations such as
> datetime
> and number formatting is available for most common locales and
> usually
> the system can serve the user in his or her most preferred locale.

But almost always in concert with the rest of the system.

Note that the language of content DOES have an effect on the outcome here. Just because my Kindle is in English doesn't mean that I want my German newspaper or book to display in the English manner. How the search engine tokenizes text should depend on the language of the content. And so on. However, it is very difficult to provide mixed locale interactions that users understand (German search results are sorted in the German manner, but Swedish ones in the Swedish manner usw.: users think of that as a "bug").

> On
> the other hand, it must select the UI language from among the
> available
> languages, so the selected preferred language is often different
> from
> the preferred locale.

This may be the case. However, we should provide for negotiation of locale in a consistent manner. If you want to negotiate several things, you should provide several attributes for negotiating it. If the service can (for example) sort results in one locale but provide UI messages in another, those are *two* facets of the service. In particular: WS-I18N lets you set (it should be "negotiate") the locale at the top level and then override that setting for specific items using the <preferences> feature. Having more than one top-level locale/language will be very confusing.


Received on Monday, 16 June 2008 19:43:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:29 UTC