RE: FW: [Distributed services] What is i18n on web services based webapplications

Things are taking shape here, I am sending this back
to the locales group as it contains important new
information. 

I am cutting some text out as well. If our threads go
on like this we will need a different email system ...
the replies are getting too long for Yahoo.

Dave

--- "Addison Phillips [wM]"
<aphillips@webmethods.com>> wrote:
>> Hi Andrea,
>> 
>> Thanks for the response.
>> 
>> I think we're more or less in agreement here. We
>> need both locale and language. We need them in both
>> directions (request and response).
>> 
>> I think W3C-I18N should try to make as much headway
>> as possible, as quicklyas possible, to prevent 
>> over-loading (such as is sometimes the case now
with
>> Accept-Language).
>> 
...
>> 
>> I would like to add an observation that there seems
>> to be some desire amoung folks to ditch the POSIX 
>> style locale format (lang_region). I admit that it
>> is an inexact mapping (will we ever get Chinese
>> sorted out? what about bi-lingual countries like
>> Belgium and Canada, where the region should
>> probably come first?). But it is generally useful
>> and matches the internal locale structures of most
>> of our platforms (even Microsoft's). I'm concerned
>> about the acceptance of something new (hence "odd")
>> that might be incompatible with existing APIs...
>> this is a topic that should be considered
>> carefully.

The existing POSIX model should continue to exist,
especially for legacy purposes. Mechanics will be
needed to convert between the various models. Windows
already offers a lot under the hood that doesn't have
anything to do with POSIX anymore, I bet interfaces
can be easily created there, as probably in other
operating systems as well.

>> 
>> In any event, if I had my druthers I would vote
that
>> we have these items turned into functional RFCs as
>> quickly as possible, so that other standards groups
>> can be coerced into adopting them ;-).

A very good idea.

>> 
...
>> >> -----Original Message-----
>> >> From: A. Vine [mailto:andrea.vine@sun.com]
...
>> >> >> I fear that an infrastructure might not be
>> >> >> accepted because it would not be
>> >> >> simple enough (we would understand it in this
>> >> >> forum, but the authors of SOAP
>> >> >> et al aren't thinking all that much about it,
>> >> >> as near as I can tell. There is an 
>> >> >> expectation that xml:lang already does
>> >> >> this, I believe.).

>> >> But we all know it doesn't (I assume that's what
>> >> you're implying here).

>> Yes. xml:lang is supposed to be a language
>> attribute, after all, not a locale tag.
>> 
>> >>
>> >> >> ...... Correctly structured data is nearly
>> >> >> always locale neutral (the data model in SOAP
>> >> >> for example sees to that).

>> >> It's that "nearly" which will bite us.
>> 
...
>> 
>> There is a tendency to make locales do too much, in
>> my opinion. Country
>> codes or language tags are often what is actually
>> needed when a locale is
>> called into play---or some other value may be
>> important (like currency
>> code). These are not locales or even locale
>> components, but specific data
>> elements or field values. Their relationship to
>> locale is often a loose one.

This is the whole issue. As long as all these data
attributes are somehow tied to the locale we will
overload the purpose of the locale. 

We need i18n attributes (for the data, like xml:lang)
and tags (for the envelope), and an architecture to
relay this information correctly. We also need the
tags for other protocols.

>> 
>> But I digress.
>> 
>> The "nearly" does bite. But locales will not
prevent
>> it from biting. In
>> fact, I suspect that locale structures will lead to
>> as much silliness as
>> having nothing. ("Well I tagged the record with a
>> locale! What do you mean
>> you can't read the date?")
>> 
....
>> >> >> [A] XML file should probably match the 
>> >> >> expected order of the client...
>> >> Where possible, of course.  The client can 
>> >> request anything, but it's the server
>> >> which must decide what it can and should serve.
>> 
>> Hence request and response being separate... and
the
>> need for fall-back
>> definitions.
>> 

And defaults if for the final fall back.

>> >>
>> >> Of course the above is language-based, not
>> >> (usually) locale-based.
>> Yes. But implementations are generally locale
based,
>> though. See locale
>> overloading complaints above ;-)

>> >> >> ......(can we formally co-opt
>> >> >> Accept-Language, seeing as almost everyone 
>> >> >> uses it as both "locale" and "language 
>> >> >> choice"?)

>> >> Prefer not.  This is an opportunity to separate
>> >> language and locale.  Please
>> >> let's take advantage of it, and maybe other
>> >> protocols and apps will follow.

>> I do too. The question is whether too much prior
art
>> exists not to coopt. I
>> saw two presentations as IUC20 that used
>> Accept-Language for locale
>> negotiation (and one that used it for both language
>> and locale and
>> specifically distinguished the two).
>> 

I think we need it like Accept
[i18n-attribute/i18n-tag], not just language and
locale, locale alone is overloaded, as already stated.
I still prefer locale to be a geographical identifier
only. Or dump it here and use region or something
else, locale stays reserved for legacy compatibility.

>> >> I'm not saying you can't have a language fr-CA, 
>> >> what I'm saying is you can have a locale US 
>> >> (or en_US just to keep the current naming 
>> >> convention) and have a language of fr-CA.  

>> Servers now may not be able to accommodate
>> fr-CA, but little by little they will 
>> *if* we provide the mechanism.  No mechanism,
>> no chance for provision.

Not only servers, clients as well.

>> Also, there is the question of browser rotation. If
>> we have to wait for IE 7 (or 8) to predominate,
>> it could be a long time before we can use the
>> results... which will encourage misuse of existing
>> things further.

It will take even longer for the operating systems to
adapt. I believe we will have fastest success in the
XML area and with web services, maybe databases. It
will be a slow migration (hopefully).

>> >> and especially in Web Services (possibly via an
>> >> "xml:locale" tag). This is not the same thing as
>> >> indicating the locale/format of returned data.
>> >> These are two separate things.
>>
>> If, as you say below, xml:lang is to be regarded 
>> strictly as an attribute (which I think is a good
>> idea), then so goes xml:locale. I believe requests
>> for a language and for a locale require a separate 
>> *tag*, not an attribute.

Exactly, we need tags and attributes to separate the
purpose.

>> 
>> >> Accept-language is separated from Content-
>> >> language.  What we want and what we
>> >> get are 2 different things ;-}
>> Utterly agree.

But we could getting more than nothing, especially
with well-defines fallbacks and defaults.


>> >>
>> >> 1a. SOAP in particular needs to have a locale 
>> >> passing mechanism. Thereneeds to be thought 
>> >> given to how multiple hops on the way to the
>> >> destination handle locale, for example. I 
>> >> realize, from several long chats with our WS
>> >> folks, that SOAP has gone out of their 
>> >> way to avoid protocols, but I firmly
>> >> believe that the locale passing belongs in the 
>> >> envelope and I think it should be defined at the
>> >> most abstract level so that the most 
>> >> implementations inherit good i18n behavior. Call
>> >> me crazy.
>>
>>....
>>
>> >> I don't see the relevance of hops.  A client 
>> >> requests a locale -Regardless of the number of 
>> >> hops, doesn't the request remain the same?
>> >> The server serves a locale - the content 
>> >> locale.  
>> >> Again, why should hops change this?  
>> >> Are you suggesting that there are other services

>> >> which will take the data and format it according
>> >> to the locale, without a separate SOAP envelope
>> >> with a separate request-locale and content-
>> >> locale?  Or am I missing something?

>> My point isn't clear. If you put the locale in the
>> transport (e.g. Accept-Language) then it tends 
>> to get stripped off by the first server 
>> in the chain. This is not very useful. 
>> Putting it in the SOAP envelope
>> guarantees that it will get to the destination.

It definitely belongs in the the SOAP envelope.

>> In addition, there is the problem of doing 
>> housekeeping (such as logging) in
>> the server that does the passing. It may need to 
>> embellish the locale list
>> for the purpose of local processing (whereas the 
>> payload still has the original client locale 
>> on it). I'm theorizing here, not really 
>> seriously so.
>> My point is in the previous paragraph.

>>
>> >> I vote for a tag.  Its use can be optional, but
>> >> when it is used, it should always be via that 
>> >> particular tag and its attributes.
>>

>> I agree. Actually, a structured tag similar to 
>> Accept-Language might be most useful. 
>> I get a lot out of multi-valued sets like A-L.

I agree as well.

>> >>
>> >> 3. The rules for handling these requests 
>> >> (chaining, negotiation, defaulting/fallbacks, 
>> >> what to do if no locale is requested,
>> >> what to do if multiple locales are 
>> >> requested, etc.) would also be a useful adjunct
>> >> (perhaps this is part of the locales group's 
>> >> project already??)
>>
>> Yes, absolutely.
>>

Yes, it is.





=====

Dave Possin
Globalization Engineer
www.heartlab.com
http://groups.yahoo.com/group/locales/

 


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Received on Tuesday, 9 April 2002 14:37:13 UTC