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

From: "Addison Phillips" <[email-masked]>
Date: Thu, 19 May 2005 10:20:13 -0700

+1

All that would be required to achieve this (if we also adopt John Cowan's suggestion from #992) would be to change Canonical-Value to work more-or-less like "Use" by modifying this paragraph:

<t>None of the subtags in the language tag has a Canonical-Value mapping 
      in the IANA registry (see <xref target="ianaformat"/>). Subtags with 
      a Canonical-Value mapping MUST be replaced with their mapping in order 
      to canonicalize the tag.</t>

To this paragraph:

   <t>Subtags of type 'Region' that have a Canonical-Value mapping 
      in the IANA registry (see <xref target="ianaformat"/>) SHOULD be 
      replaced with their mapped value.</t>

And add these paragraphs for the remaining ISO 639 corrections and grandfathered/redundant garbage collection:

   <t>Redundant or grandfathered tags that have a Canonical-Value mapping 
      in the IANA registry (see <xref target="ianaformat"/>) SHOULD (MUST??)
      be replaced with their mapped value. These items are either
      deprecated mappings created before the adoption of this document
      (such as the mapping of "no-nyn" to 'nn' or "i-klingon" to 'tlh')
      or are the result of later registrations or additions to this
      document (for example, "zh-gouyu" might be mapped to a 
      language-extlang combination such as "zh-cmn" by some future 
      update of this document).</t>

   <t>Other subtags that have a Canonical-Value mapping 
      in the IANA registry (see <xref target="ianaformat"/>) MUST be
      replaced with their mapped value. These items consist entirely of   
      clerical corrections to ISO 639-1 in which the deprecated subtags
      have been maintained for compatibility purposes.</t>

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 Frank Ellermann
> Sent: jeudi 19 mai 2005 04:18
> To: [email-masked]
> Subject: [Ltru] Re: [psg.com #954] all aliases must be equally support ed
> 
> McDonald, Ira wrote:
> 
>  [aliases]
> > The so-called 'preferred MIME name' label on aliases in the
> > IANA Charset Registry is useless and dangerous.
> 
> We don't make them up for fun, they just happen, like YU -> CS
> or jw -> jv.  Or the grandfathered cases like i-klingon -> tlh.
> 
> > Whenever possible, the language tag registry draft should not
> > encourage the proliferation of aliases for tags or subtags.
> 
> It doesn't, actually it tries to avoid them like hell.
> 
> > support for the Canonical subtags is REQUIRED, but support
> > for Alias subtags is merely RECOMMENDED.
> 
> IBTD, the subject says it all.
> 
> > Your mileage may vary.
> 
> Certainly.  The complete concept of "Canonical:" appears to be
> wrong, if you even think about any "let's forget the rest".
> 
> The more flexible "Use:" concept (all aliases pointing to the
> same "best current practice" tag) is better.
> 
> > Required support for all registered aliases is a bad idea and
> > it will be ignored by the majority of implementors.
> 
> Supporting only an obsolete idea of "Canonical:" as stated in
> an obscure IANA registry not reflecting the state of the art
> in the source standards after date-B was a worse idea.
> 
> With 7000+ languages our few aliases can't be the showstopper.
> 
>                          Bye, Frank
> 
> 
> 
> _______________________________________________
> 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: John Cowan <[email-masked]>
Date: Thu, 19 May 2005 13:59:35 -0400

>       update of this document).</t>

This still suffers from the problem that we don't know what the Canonical-Value
is used for.  For example, there is no indication whether "no-nyn" is mapped
to the *language* tag 'nn' or to the *region* tag 'nn' (not currently defined,
but could be).  A subtag will be canonicalized to a subtag of the
same type, but a grandfathered tag could be canonicalized to any kind of
subtag or a combination of subtags.  We need a provision for this.

(Credit: Doug has been making this point repeatedly.)

-- 
Don't be so humble.  You're not that great.             John Cowan
        --Golda Meir                                    [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 19 May 2005 20:11:48 +0200

Addison Phillips wrote:

> change Canonical-Value to work more-or-less like "Use"

That's a plan.  Replacing it by Use: later if Ira still thinks
that implementors might get Canonical: wrong is no problem.

> Subtags of type 'Region' that have a Canonical-Value mapping
> in the IANA registry (see <xref target="ianaformat"/>) SHOULD
> be replaced with their mapped value.

Why is it restricted to regions ?  Any iw, ji, and jw should be
also replaced, dito grandfathered tags, dito future deprecated
variants, or all other future modifications introducing a new
"best current practice" alias - whether we like it or not.

> Redundant or grandfathered tags that have a Canonical-Value
> mapping in the IANA registry (see <xref target="ianaformat"/>)
> SHOULD (MUST??) be replaced with their mapped value.

That's about redundant _and_ deprecated at the same time, like
a hypothetical ji-Latn.  I'd still prefer to grab the complete
redundant tags, put them into an appendix, and then forget it.
If that's still possible with John's idea.

SHOULD.  A worldwide "MUST retag everything" won't fly.  It's
also unnecessary if we get Ira's okay that implementors won't
ignore aliases, all tags are stable.

> Other subtags that have a Canonical-Value mapping in the IANA
> registry (see <xref target="ianaformat"/>) MUST be replaced
> with their mapped value.

Okay, here you get jw etc.  I'm still lost why NH -> TV should
be different from jw -> jv (i.e. from a future similar case).

> These items consist entirely of clerical corrections to
> ISO 639-1 in which the deprecated subtags have been
> maintained for compatibility purposes.

At the moment.  What about future deprecated variants, or a
future deprecated registered-lang ?  The "Use:" idea is to go
with the relevant standard as far as possible,

The limit is a collision with a registered subtag.  That's only
possible for 3166-1 region codes, and then the registry would
switch to the UN number if it exists, otherwise the poor tag
reviewer should get a danger bonus... ;-)

                             Bye, Frank

---

From: John Cowan <[email-masked]>
Date: Thu, 19 May 2005 14:48:27 -0400

> "best current practice" alias - whether we like it or not.

Because we know where the ISO 639 and 15924 Registration Authorities live,
and we know which keys to turn if they misbehave.  :-)

> If that's still possible with John's idea.

Still possible, but some tags may become redundant in future, like
en-boont (once boont is a registered variant) and zh-yue (once extlangs
are turned on and yue is a registered extlang encompassed by zh).

> ignore aliases, all tags are stable.

This is about canonicalization, which didn't exist before, so MUST is
appropriate.  Generating tags in canonicalized form is, as a whole, a SHOULD.

-- 
John Cowan  www.reutershealth.com  www.ccil.org/~cowan  [email-masked]
'Tis the Linux rebellion / Let coders take their place,
The Linux-nationale / Shall Microsoft outpace,
We can write better programs / Our CPUs won't stall,
So raise the penguin banner of / The Linux-nationale.  --Greg Baker

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 19 May 2005 13:20:13 -0700

I have to look this over in detail, but a crucial requirement is to
guarantee the invariant:

if isValid(tag, date1), then canonicalize(tag, date1) = canonicalize(tag,
date2), for all date2 > date1

Does this still preserve that?

‎Mark

----- Original Message ----- 
From: "Addison Phillips" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 19, 2005 10:20
Subject: RE: [Ltru] Re: [psg.com #954] all aliases must be equally support
ed

+1

All that would be required to achieve this (if we also adopt John Cowan's
suggestion from #992) would be to change Canonical-Value to work
more-or-less like "Use" by modifying this paragraph:

To this paragraph:

And add these paragraphs for the remaining ISO 639 corrections and
grandfathered/redundant garbage collection:

Addison P. Phillips

---

From: John Cowan <[email-masked]>
Date: Thu, 19 May 2005 16:37:46 -0400

> Does this still preserve that?

It does not preserve that invariant for grandfathered tags: they remain
always valid but not necessarily always canonical.

I think we should be able to live with that, as the alternative is very ugly:
we will be stuck with some linguistic objects that can never have generative
names.

-- 
John Cowan  [email-masked]  www.ccil.org/~cowan  www.reutershealth.com
Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
        --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 19 May 2005 16:02:49 -0700

ok, I can live with that for the grandfathered stuff.

‎Mark

----- Original Message ----- 
From: "John Cowan" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 19, 2005 13:37
Subject: Re: [Ltru] Re: [psg.com #954] all aliases must be equally support
ed