Re: [Comment on WS-I18N WD]

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.

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 Wednesday, 18 June 2008 01:54:19 UTC