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

Re: [Comment on WS-I18N WD]

From: Martin Duerst <duerst@it.aoyama.ac.jp>
Date: Fri, 20 Jun 2008 15:37:59 +0900
Message-Id: <6.0.0.20.2.20080620153621.06085c70@localhost>
To: Dan Chiba <dan.chiba@oracle.com>
Cc: "Phillips, Addison" <addison@amazon.com>, "www-international@w3.org" <www-international@w3.org>

At 07:22 08/06/20, Dan Chiba wrote:
>
>Hi Martin,

>> So my guess would be that if there is a need for a fallback for user
>> language, the best thing is to also use that fallback for the locale-
>> related stuff. While this may not always be the absolutely best thing
>> for any particular user, it is sure to be consistent, and we should
>> be able to assume that if the user understands the language, s/he is
>> familliar with the locale-related stuff. This solution will avoid
>> many weirdnesses and confusions. The alternative is NOT to just have
>> two separate settings, leading to two separate selections on the
>> server side, but a much more fine-grained set of preferences that
>> most users won't care to set up and most servers won't care to
>> provide.
>>
>> Dan, I think that if you disagree, giving some concrete examples of where
>> your proposal would help would be best to help us understand it.
>>   
>A table is often filled with dates and numbers and text may only appear in the column headers. While a language fallback may be desirable, date/number formats that don't match the user preference can be unacceptable. I am saying UI language and localization locales should be consistent (yes that sure is the desirable state), but in reality fallback happens, then the preferred locale should still be honored in many cases. I agree that depending on the scenarios, different behaviors seem more adequate than the others. An application or service may define its behavior however it decides, but I would like WS-I18N to be able to support all common requirements. In some cases, language resource is not available, and then the system must be able to identify the alternative language. I think I am requesting the fine-grained set of preferences. The language element appears to be the only reasonable way that can resolve the common situations due to missing language resources
.

Okay, I see your point for cases such as tables, where things
such as formatted numeric data is predominant, and there is only
very little UI language text.

Regards,    Martin.


>Another possible way to identify the preferred language for the fallback scenarios is allowing multiple values in the locale element. (e.g. "<i18n:locale>fr-CH, de, it</i18n:locale>") This is the conventional way for the traditional web use cases, but I thought this is not a good idea because it would become harder for the application to produce the desired UI experience without mixed languages/locales. The service consumer should specify the locale, not the provider, as mentioned before.
>
>Regards,
>-Dan
>> Regards,    Martin. 


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     
Received on Friday, 20 June 2008 10:09:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:17 GMT