Re: [Comment on WS-I18N WD]

Hi Martin,

Please see my response below:

Martin Duerst wrote:
> At 23:46 08/06/17, Dan Chiba wrote:
>   
>> Phillips, Addison wrote:
>>     
>
>   
>>> I understand that's your intent. However I think this will confuse the vast preponderance of developers who have only a very rough idea what a "locale" or a "language" is. There are also different ways that services can be provisioned. It may not be possible to enumerate one list or the other easily. Having two things that do roughly the same thing doesn't seem that useful to me. How often do you actually set LC_MESSAGES separately from LC_ALL?
>>>   
>>>       
>> Whenever a user's preferred locale is supported but preferred language is not, he or she would set LC_MESSAGES explicitly. This is often needed because the set of supported translation languages is usually small. I wonder if you also mean LC_MESSAGES is confusing or not needed because it won't be set often and does not seem so useful.
>>
>> Because the sets of supported languages and locales are usually different, they are practically different. I do agree they are conceptually roughly the same. However, in reality, service consumers are usually interested in serving the user in their most preferred available language and locale, but this is hard to achieve without specifying the locale and language separately. Both of users' preferred locale and language should be honored, but too often language resources are not available and an alternative language different from the language deduced from the preferred locale ought to be used instead. This alternative language needs to be identified and this is why #3 language (and LC_MESSAGES) is needed.
>>     
>
> I'm not really sure I (or other users) would want to have localization
> and user interface language to be different. In some cases, this could
> work out (I'd prefer the Swiss convention to use "'" as a thousands
> separator quite independently of what language the user interface is).
> In some cases, it could look really weird (immagine German month names
> in an otherwise French user interface; I think Addison was giving some
> examples in that direction). In some cases, it may be highly confusing,
> such as when having very short dates such as 07/08/09 (but that's a
> bad idea anyway).
>
> 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.

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 Thursday, 19 June 2008 22:23:57 UTC