Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported

From: "Addison Phillips" <[email-masked]>
Date: Fri, 20 May 2005 10:40:33 -0700

No.

It means that explicitly listed aliases must be mapped for matching purposes. For ISO 639 codes, this means stuff like jv/jw and he/iw. The 639-1/639-2 relationships are not listed because the only 639-2 codes that appear are ones for which there is no 639-1 code (by rule).

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Misha Wolf
> Sent: 2005?5?20? 10:32
> To: LTRU Working Group
> Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported
> 
> Randy Presuhn wrote:
> 
> > For matching to work, this would mean that an implementation
> > "MUST" treat as equivalent *all* the aliases (as of the
> > implementation date) for its supported set of (sub)tags.
> 
> I regret that my current workload does not allow me to analyse
> the text of the ID to get at the precise meaning.  So please
> help me: Does this imply that all implementations must support
> the ISO 639-2 codes even where there exists a long-established
> ISO 639-1 code?  I very much hope that the answer is No.
> 
> Thanks,
> Misha
> 
> 
> 
> 
> -----------------------------------------------------------------
>         Visit our Internet site at http://www.reuters.com
> 
> To find out more about Reuters Products and Services visit
> http://www.reuters.com/productinfo
> 
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Misha Wolf <[email-masked]>
Date: Fri, 20 May 2005 18:56:50 +0100

Good.  Thanks.

Misha 

-----Original Message-----
From: Addison Phillips [mailto:[email-masked]] 
Sent: 20 May 2005 18:41
To: Misha Wolf; LTRU Working Group
Subject: RE: [Ltru] [psg.com #954] all aliases must be equally supported

No.

It means that explicitly listed aliases must be mapped for matching
purposes. For ISO 639 codes, this means stuff like jv/jw and he/iw. The
639-1/639-2 relationships are not listed because the only 639-2 codes
that appear are ones for which there is no 639-1 code (by rule).

Addison

To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo

---

From: Misha Wolf <[email-masked]>
Date: Fri, 20 May 2005 19:05:13 +0100

John Cowan wrote:

> No, no, a thousand times no.

Hmm ... I'm disappointed.  Is there any chance of making that a million?

Thanks,
Misha

---

From: "Peter Constable" <[email-masked]>
Date: Fri, 20 May 2005 17:51:00 -0700

> From: John Cowan [mailto:[email-masked]]

> A language with both a 639-1 and a 639-2
> code must *always* use the 639-1 code in RFC 3066 and all its future
> successors.  The ISO 639 RA/JAC has guaranteed that no existing
language
> with a 639-2 code will ever be assigned a novel 639-1 code.  In
effect,
> the list of 639-1 codes is frozen at least until 639-3 comes on line
> (and I bet it's still in fact frozen then).
> 
> Peter, do you have any idea whether any of the new languages in 639-3
(new
> to ISO, that is) would be plausible candidates for ISO 639-1
registration?
> This is going to matter in RFC 3066ter.

WRT your last question, I cannot say -- I haven't thought about it in
any detail; I think there are languages already in 639-2 but not 639-1
that may in the near future meet the criteria for inclusion in 639-1.

What I *can* say is that there is no plan to add entries to 639-1 as a
result of the development of 639-3 except possibly in a very small
number of cases (if any -- I'd have to check) of problems existing in
639 as it exists now. (E.g. there's a current quirk in that 639-1 has an
entry for Serbo-Croatian, but 639-2 does not. The LOC site shows "sh" as
having been deprecated in 2000, but that appears to be incorrect since
it is included in the code table of ISO 639-1:2002 with no indication of
deprecation.)

I suggested some time ago (before the WG) that we don't have to, and
should not, leave ourselves at the mercy of the whims of a Joint
Advisory Committee that is happy to promise certain things today, but
may not ten years from now when it's composed of different people. My
proposed fix was that we simply freeze the set of ISO 639-1 IDs that are
permitted in IETF language tags to those that exist now. 

My suggestion wasn't accepted exactly, though it did result in a change
to the text of 2.2.1; specifically, the following got added:

<quote>
   In order to avoid instability of the canonical form of tags, if a two
   character code is added to ISO 639-1 for a language for which a three
   character code was already included in ISO 639-2, the two character
   code will not be added as a subtag in the registry.  See Section 3.3.
</quote>

I'd still prefer to lock the alpha-2 IDs to a frozen list, but this
paragraph, along with the intent expressed by the current JAC, is
sufficient.

Peter Constable