[Fwd]: Response to Mark's message]

[Addison Phillips [wM]]

Martin wrote:
> >
> >OTOH, there has to be some guideline for developers to follow when
> >interpreting the language code. I want other software to make decisions
> >as similar to mine as possible, in order to obtain consistent results.
>
> There are two ways to interpret 'consistent results'. One means
> that all implementations on the same platform map the same
> 3066 codes to the same internal codes (and back). See below
> for more on that.

I more or less mean this one. See below.
>
> Another means that you actually want to e.g. have exactly the same
> date format on different platforms.

This is a good example of why this is hopeless. A Java locale contains no
fewer than 24 possible built-into-the-system patterns (in the DateFormat
class) per locale. C# is somewhat richer (in part due to the fact that it
supports non-Gregorian calendars and associates a collection of possible
calendars with each CultureInfo). A language tag cannot possibly tell you
which of these you will get back from the system (that's an implementation
decision). It merely implies that the date format you see when you specify
'fr-FR' should be recognizably "French" (and maybe it knows about national
holidays and the like).

>The only reasonable solution
> I see for this one is:
> 1) Define some format for describing the various conventions.

Like RDF?

> 2) Reference that format by an URI.

You mean an IRI, right? ;-)

> >
> >//---------
> >Although RFC3066bis identifiers are intended solely to identify natural
> >languages, data processing may sometimes need to infer certain
> >culturally and regionally affected settings or preferences from them.
> >These settings are sometimes referred to as a "locale" and are generally
> >constructed using identifiers that are similar to or indistinguishable
> >from some RFC3066bis identifiers.
>
> I'm okay up to there. Please also add some language indicating that
> many of these settings are actually very much related to language
> (date formatting, number formatting).

I think that would be appropriate.

>
>
> >When inferring these preferences from
> >RFC3066bis, you should xxxxxx.....
> >//------
>
> I think it doesn't work for RFC 3066bis to give such instructions.

I think that xxxxx would not give instructions on what to map TO, but rather
how to map FROM 3066bis. That is, how to group items in the more complex
hierarchy of scripts and whatnot when interpreting; how to deal with
deprecated values (no-nyn -> nn); how to deal with i- and x- values; etc.
The mapping would have to be idiosyncratic to the platform and would be
influenced by existing practice.

I see the value in this as being that finally there would actually be text
that codifies that this is a common, not-unreasonable practice [and
suggesting by inference that you use it instead of something else]. IOW, the
de facto practice of using 3066 as a 'locale tag' would be recognized and
codified (but not by changing the mission/role/structure/etc. of 3066
itself).

> We could try to give them for Windows, Java, Linux, the Mac,...
> But where to start, and where to stop?

Platforms would have to work this out. By giving guidelines on interpreting
3066bis, we can define in general terms the expectations that users would
have and give implementers a framework to use as a guide.

> The only way this can work
> is by the relevant platform providers to do the conversion to their
> internal codes. This is very similar to date formats,...
> ISO 8061 doesn't say how to map these formats to platform-internal
> formats, but each platform has the necessary code to do the conversion.
>
Exactly so.

Best Regards,

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods, Inc.

+1 408.962.5487 (phone)  +1 408.210.3569 (mobile)
-------------------------------------------------
Internationalization is an architecture.
It is not a feature.

Chair, W3C-I18N-WG Web Services Task Force
To participate see http://www.w3.org/International/ws