[Fwd]: Response to Mark's message]

[Mark Davis]

There is a misunderstanding here. However one defines locales, one needs a
language ID to be useful. For example, someone might define a locale to
include:

written language ID
country ID of residence
country ID of citizenship
country ID of bank account
timezone ID

[This is actually the defintion needed by a customer I was talking to just
yesterday.]

As a part of that definition, one needs an unambiguous specification of
*written* language.

ISO-639 fails miserably as unambiguous specification of written language. I
realize that the proponents of ISO-639 don't even want it to apply to
written language. But for information technology, distinguishing written
language is the 999% case; merely spoken language is mostly unproductive.

RFC 3066 is somewhat better, but has the problems as discussed on this list.
As to the issue of whether RFC 3066bis should include SIL codes directly or
not, technically I don't much care. I suspect it would be slightly cleaner
if 3066bis just included some ISO standard.

However, the need for the addition of a script subtag to 3066bis is clear
and present. And if 3066bis does not address that issue *very* soon, I
forsee a splintering of language IDs (we are already seeing that in the
Windows .NET values). The normal pace of an ISO standard is far too slow for
3066bis to be dependent on it. So I see two alternatives:

A. 3066bis adds script codes, SIL codes

B. 3066bis adds script codes, ISO adds SIL codes to ISO 639-3, (later)
3066bis#2 adds ISO 639-3 codes

Mark
(مرقص بن داود)
________
mark.davis at jtcsv.com
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799

----- Original Message -----
From: <Peter_Constable at sil.org>
To: <aphillips at webmethods.com>
Cc: "Ietf-languages" <Ietf-languages at alvestrand.no>;
<ietf-languages-bounces at alvestrand.no>; "Mark Davis" <mark.davis at jtcsv.com>
Sent: Wednesday, April 09, 2003 08:48
Subject: Re: [Fwd]: Response to Mark's message]


>
> Addison Phillips wrote on 04/04/2003 03:12:16 PM:
>
>
> > The latter. They aren't attributes of text (or numbers or dates or ...).
> > IOW a locale >>should<< not be used as a modifier to a data structure.
> > It, of course, can itself be exchanged or made to be a field in a data
> > structure. But to say that, for example, an "object of type 'x' has a
> > locale of 'y'" seems like (at best) very poor internationalization...
>
> This is in contrast to identifiers for things like languages,
orthographies
> and spelling conventions: it is completely appropriate that strings should
> be so tagged.
>
>
>
> > To go back to the starting point here, if (a) RFC3066 were changed to
> > resolve the majority of variant problems with locale identifiers
>
> I, for one, do not think that RFC3066 should be changed to deal with
> locales. It *should* be changed to accommodate distinctions in things like
> writing system/orthographies/spelling conventions as well as language, but
> not locales. Such an extended RFC3066 would be of use for locale
> identification since language and text-related distinctions are relevant
> for locales, but locales go beyond the scope of what RFC3066 has been and
> should be intended to deal with.
>
>
>
> - Peter
>
>
> --------------------------------------------------------------------------
-
> Peter Constable
>
> Non-Roman Script Initiative, SIL International
> 7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
> Tel: +1 972 708 7485
>
>
>
>