Subject: [Ltru] Language tag humor (was: Re: Question)

From: "Doug Ewell" <[email-masked]>
Date: Sat, 26 Mar 2005 17:44:59 -0800

Tex Texin <tex at i18nguy dot com> wrote:

> The question of speaking up for no-BC is a bit loaded when asked in
> that way.

I was scratching my head and searching frantically for a country code
'BC', so I could figure out where someone was speaking Norwegian, until
I realized that "no-BC" meant "no backward compatibility."

-Doug Ewell
 Fullerton, California
 http://users.adelphia.net/~dewell/

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

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 26 Mar 2005 18:19:45 -0800

Mark Davis <mark dot davis at jtcsv dot com> wrote:

> Look, we regularly get beaten up by various IETF people for the
> backwards compatibility of the Unicode Standard. I hate to see IETF
> take a much more lackadaisical approach to language tags. I'm ok with
> excluding codes that no reasonable person would believe is was valid
> at some time according to the text of 1766 and 3066.

I agree that we should not be lackadaisical.  I do feel that the text of
1766 and 3066 excludes pre-1988 codes.

> And if we start down the road of judging each individual case
> according to whether we think it was "lame" or not, we will just tie
> ourselves up in knots. We have a bright line; let's use it. We should
> simply not break backward compatibility, when the only benefit is
> having a very small number of additional codes.

Frank's concern, echoed by John in his comment about "lame," is not so
much that we lose a few codes, but that ISO 3166/MA will pull an ISO
3166/MA and reassign one of the codes, and the country to whom it was
reassigned will be forced to accept a UN M.49 code in language tags,
because we've reserved the subtag in perpetuity for "French Unrecognized
Antarctic Claims."

-Doug Ewell
 Fullerton, California

---

From: Tex Texin <[email-masked]>
Date: Sat, 26 Mar 2005 22:12:01 -0800

Actually it refers to a special Norwegian form of backward
compatibility.

;-)

My bad for abbreviating. Sorry. I thought this list was already using BC
for backward compatibility, but its possible it was being used regularly
in another list I am on and not this one.

But I should have anticipated the hyphenated no- form would look more
like a lang tag than an abbreviation.

tex

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:[email-masked]
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 27 Mar 2005 22:43:23 -0800

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

>> Joe Blow was deciding whether his code should allow "en-BU"
>
> That's a sad story, like Jane Blog's adventure in cyberspace:
>
> Seeing RH on a car in Haiti she checks the ISO 3166-1 Web
> page and finds something about "RH Haiti" as expected,  So
> she tags a Creole text with fr-RH, and later she's surprised
> when her job application is returned by the ZW embassy.

Jane lost the job because the HR director at the embassy also checked
the ISO 3166-1 Web page, which clearly says that indeterminately
reserved code elements like RH "must not be used in ISO 3166-1," and
decided that Jane doesn't follow directions well.

> The most serious problem with the actual draft is, that it
> forces us to choose between an erroneous concept of backwards
> compatibility and compatibility with future country codes for
> the known list of "invalid" country codes.  At least for the
> decade 1995 - 2005 we can get one unambiguous idea of "valid".

There is nothing "erroneous" about the concept of backward compatibility
being discussed here.  RFC 1766 and 3066 allowed language tags to
contain any code in the 1988 versions of ISO 639 and 3166.  Eliminating
the region subtags based on ISO 3166 codes that were withdrawn before
1988 removes 15 of the 24 "problem codes," notably the Antarctic codes
you have criticized most strongly.  Changing the date to 1995 would add
only five more codes (BU, DD, NT, SU, and YD) to the blacklist.  Is that
worth violating the agreement set down in RFC 1766?

-Doug Ewell
 Fullerton, California

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 30 Mar 2005 03:52:57 +0200

Doug Ewell wrote:
 
> RFC 1766 and 3066 allowed language tags to contain any code
> in the 1988 versions of ISO 639 and 3166.

Apparently.  Or maybe Harald forgot to update his references
in RfC 3066.  Or he's the lucky owner of a 1988 edition, and
didn't want to pay for a newer edition of ISO 3166.

> Changing the date to 1995 would add only five more codes
> (BU, DD, NT, SU, and YD) to the blacklist.  Is that worth
> violating the agreement set down in RFC 1766?

I'm not sure.  BU, NT, and SU are still visible on the 3166-1
page.  DD and YD are officially unassigned.  In other words
they could be assigned to a new region tomorrow when necessary.

Let's work on some decent "union" / "split" rules for a while,
that's more important than the two 1988 DD and YD incarnations
of "old" draft -00 oddities.

A simple fix could be a new rule, that whenever an existing
(3166-1 CC = UN number) relation for a registered CC is changed
by the introduction of a new UN number for the CC, then the old
UN number is added to the registry.  

That also proves that the stability in draft -00 is partially
an illusion.  But at least it doesn't lose complete regions
like the old DE, YE, or YU.
                           Bye, Frank