Re: [Comment on WS-I18N WD]

Dan Chiba さんは書きました:
>
>>
>> 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.
> Just wanted to clarify that I do agree with this idea. My intention is 
> explicitly define the way to selectively override the top level locale. 

Note there is already an example in the draft that demonstrates that 
functionality:

(01) <i18n:international>
(02)   <i18n:locale>en_US</i18n:locale>
(03)   <i18n:preferences>
(04)     <ldml:collation>
(05)       <ldml:alias source="de_DE" type="phonebook"/>
(06)     </ldml:collation>
(07)   </i18n:preferences>
(08) </i18n:international>

I guess what you are saying is that you want to have that functionality 
not baked into e.g. the LDML or some other namespace, but rather as a 
general means, e.g. a "locale attribute" (not namespace qualified at 
i18n:xxx elements, but namespace qualified at other elements). How about 
this:

(01) <i18n:international *locale="en_US"*>
(02)   <i18n:preferences>
(03)     <ldml:collation>
(04)       <ldml:alias source="de_DE" type="phonebook" 
*i18n:locale="de_DE"*/>
(05)     </ldml:collation>
(06)   </i18n:preferences>
(07) </i18n:international>

Felix

> The additional items are all optional and if they are not specified, 
> the values should be deduced from the top level locale.
>
> Regards,
> -Dan
>
> Phillips, Addison wrote:
>>> 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.
>>
>> Addison
>>
>>   
>
>
>

Received on Tuesday, 17 June 2008 03:11:44 UTC