Subject: [Ltru] Re: The "QU" territory/region code (was New Public Review Issue: #116 Proposed Update UTS #35 LDML)

From: "Mark Davis" <[email-masked]>
Date: Wed, 7 Nov 2007 16:10:21 -0800

This is a misreading of the text. One of the reasons for the last revision
of BCP 47 was to make it absolutely clear when codes were valid or not. The
valid codes are all and only those that are in
http://www.iana.org/assignments/language-subtag-registry. EU is not there
(as a region), thus it is not valid.

Now, personally, I agree with you that not having EU in BCP 47 is
unproductive. However, there was unfortunately no consensus in the working
group to add the exceptionally reserved codes. That's what forced us to use
QU in the first place in CLDR. If BCP 47 ever changes, we'd be pleased as
punch to deprecate QU in its favor.

(In retrospect, I also think it was unproductive to have incomplete M49
codes (http://unstats.un.org/unsd/methods/m49/m49regin.htm). It wouldn't
hurt to add the very few M49 codes that are excluded from BCP 47, even if
deprecated, if only to make testing and cross mapping easier.)

Mark

On 11/7/07, Philippe Verdy <[email-masked]> wrote:
>
> Rick McGowan wrote:
> > The Unicode CLDR committee is planning to release a minor version, 1.5.1
> ,
> > by the end of November. There are a few changes in the specificiation
> > associated with this change.
> >
> >       http://unicode.org/draft/reports/tr35/tr35.html
> > Notable changes include:
> > * Added C10. Likely Subtags for locale IDs or language tags.
>
> One problem about a "private use" territory code currently used (QU):
>
> [quote[TR35]]
>    3. Identifiers
>    (...)
>    A locale ID is an extension of a language ID, and thus the structure
> and
>    field values are based on [BCP47]. The registry of data for that
>    successor is now being maintained by IANA. The canonical form of a
> locale
>    ID uses "_" instead of the "-" used in [BCP47]; however,
> implementations
>    providing APIs for CLDR locale IDs should treat "-" as equivalent to
> "_"
>    on input.
>    (...)
>                     Locale Field Definitions
>    --------------  ----------  ------------------------------------------
>    Field           Allowable   Allowable values
>                    Characters
>    --------------  ----------  ------------------------------------------
>    (...)
>    territory_code  ASCII       [BCP47] subtag values marked as Type:
>                    letters,    region, or any UN M.49 code that doesn't
>                    numbers     correspond to a [BCP47] region subtag.
>                                There are three private use codes defined
>                                in LDML:
>                                    QO Outlying Oceania
>                                    QU European Union
>                                    ZZ Unknown or Invalid Territory
>                                The private use codes from XA..XZ will
>                                never be used by CLDR, and are thus safe
>                                for use for other purposes by
>                                applications using CLDR data.
>    --------------  ----------  -----------------------------------------
> [/quote[TR35]]
>
> Now let's look at the normative [BCP-47] reference:
>
> [quote[BCP-47]]
> 2.2.4. Region Subtags
>    (...)
>    The following rules apply to the region subtags:
>    (...)
>    2.  All two-character subtags following the primary subtag were
>        defined in the IANA registry according to the assignments found
>        in [ISO3166-1] ("Codes for the representation of names of
>        countries and their subdivisions -- Part 1: Country codes") using
>        the list of alpha-2 country codes, or using assignments
>        subsequently made by the ISO 3166 maintenance agency or governing
>        standardization bodies.
> [/quote]
>
> Note that [BCP47] cites [ISO3166-1] as a source of codes, but it
> ***forgets
> to list it in the list of normative references*** at end of the document.
> It's not very precise about the list being effectively used; it just gives
> the name of the whole document within the text itself: "Codes for the
> representation of names of countries and their subdivisions -- Part 1:
> Country codes", and refers to the "list of alpha-2 country codes"; it
> speaks
> about "assignments", but does not indicate the normative status.
>
> From there, I can find this official page:
> http://www.iso.org/iso/iso-3166-1_decoding_table where the "EU" code is in
> yellow background described as "exceptional reservations". This links to
> this page:
> http://www.iso.org/iso/customizing_iso_3166-1.htm, which says:
>
> [quote]
> To avoid transitional application problems and to aid users who require
> specific additional code elements for the functioning of their coding
> systems, the ISO 3166/MA may set aside code elements which it undertakes
> not
> to use for other than specified purposes during a limited or indeterminate
> period of time. These are called reserved code elements and their use is
> normally restricted to the application they were reserved for.
> (...)
> Code elements not included in the current version of ISO 3166-1 may be
> reserved by the ISO 3166/MA,
> * (...)
> * as "exceptional reservations", at the request of national ISO member
> bodies, governments and international organizations. This applies to
> certain
> code elements required in order to support a particular application, as
> specified by the requesting body and limited to such use; any further use
> of
> such code elements is subject to approval by the ISO 3166/MA.
> [/quote]
>
> So [BCP47] indicates that the [ISO3166-1] country code "EU", listed in the
> list of alpha-2 country code for the European Union, should be used as it
> was reserved for indeterminate time. BCP47 does not seem to restrict the
> use
> of alpha-2 codes that were "exceptionally reserved".
>
> For [ISO3166-1], the code "EU" is an exception reservation; its use in
> LDML
> (if it has to become an international standard) would conform to the
> needed
> "support for a particular application". All that is needed is that Unicode
> requests approval by the ISO 3166/MA.
>
> Why is LDML using the private use code "QU", apparently in contradiction
> with BCP47? Shouldn't it be changed to use "EU" according to BCP47
> recommandation and the other policy in LDML that warns against the use of
> private use codes that can be changed at any time?
>
> Does Unicode want to request approval by ISO 3166/MA for the use of the
> "EU"
> code in LDML and CLDR (as indicated in ISO3166-1)? I think it would be in
> the interest of many applications that already use "EU" in the
> localization
> data, but NOT "QU" because it is a "user-assigned code element" not meant
> for interchange.
>
> Note that [ISO3166-1] also says:
>
> [quote]
> When exchanging data with users of ISO 3166-1 not connected to this
> particular in-house application the definition of these user-assigned code
> elements should be given.
> [/quote]
>
> This is what is performed in the LDML specification, but is it enough to
> permit interchange of data?
>
>
>
>
>

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

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 7 Nov 2007 18:19:28 -0800

On 11/7/07, Philippe Verdy <[email-masked]> wrote:
>
> Mark Davis wrote:
> > This is a misreading of the text. One of the reasons for the last
> > revision of BCP 47 was to make it absolutely clear when codes were
> > valid or not. The valid codes are all and only those that are in
> > http://www.iana.org/assignments/language-subtag-registry. EU is not
> > there (as a region), thus it is not valid.
>
> Note that your URL is NOT directly referenced by [BCP47], and the
> terminology used cannot clearly state that fact. So it is not so clear in
> the [BCP47] text, as you could use any table shown in the ISO 3166-1/MA
> website. Note that [BCP47] does not even list [ISO3166-1] as a normative
> reference, and not even as an informative reference (most probably this
> was
> forgotten)!
>
> Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request
> to
> the ISO 3166-1/MA an authorization to use the "exceptionnally reserved" in
> LDML and CLDR, even if there's still no agreement without BCP47 (what the
> IETF wants to restrict for BCP47 would be immediately invalidated by any
> authorization made by the ISO 3166-1/MA).
>
> That's why I finished my message with this question: did you request such
> authorization to the ISO 3166-1/MA?
>
>
>
>

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 7 Nov 2007 18:30:13 -0800

> reference, and not even as an informative reference (most probably this

No.

I agree that in an ideal world we'd just have the URL in BCP 47, but it
clearly states that

    The Language Subtag
    Registry maintained by IANA is the source for valid subtags: other
   standards referenced in this section provide the source material for
   that registry.

So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is
just a *source* for data, and not all codes defined in 3166 will be valid in
BCP 47.

Anyway, the text in [ISO3166-1] allows the Unicode Consortium to request to
> authorization made by the ISO 3166-1/MA).

The Unicode Consortium could clearly use EU. No problem there. However, a
goal of the Unicode CLDR group was and is to be compatible with BCP 47, and
EU cannot be used there, conformantly.

> authorization to the ISO 3166-1/MA?

That is moot, since the goal is compatibility with BCP 47, not with 3166.

There is some background on BCP 47 on Addison's site (
http://www.inter-locale.com/); that might be easier to understand than the
spec.

---

From: Martin Duerst <[email-masked]>
Date: Thu, 08 Nov 2007 12:58:44 +0900

Mark, others,

[removing the Unicode mailing list from the cc.]

The LTRU WG has agreed some years ago to not use
"exceptionally reserved" codes from 3166-1.
We clearly don't want to reopen every
single discussion that we had leading to RFC 4646, but
if necessary, we can reconsider some of thae decisions
for RFC 4646bis. As an example, would it make sense for
the LTRU WG to ask for permission from the ISO 3166-1/MA?

Regards,    Martin.

P.S.: When we finalized HTML4, the Euro character was still
      not officially and finally approved by the UTC and
      ISO/IEC JTC1/SC2/WG2. We nevertheless assessed the
      risks and took the chance and defined a &euro; entity,
      with mapping to the proposed codepoint.

At 11:30 07/11/08, Mark Davis wrote:

>On 11/7/07, Philippe Verdy <<mailto:[email-masked]>[email-masked]> wrote:
>>Mark Davis wrote:
>>> <http://www.iana.org/assignments/language-subtag-registry>http://www.iana.org/assignments/language-subtag-registry. EU is not
>>reference, and not even as an informative reference (most probably this was
>>forgotten)!
>
>No.
>
>I agree that in an ideal world we'd just have the URL in BCP 47, but it clearly states that 
>
>
>    The Language Subtag
>So IANA is the source. As far as an user of BCP 47 is concerned, 3166 is just a *source* for data, and not all codes defined in 3166 will be valid in BCP 47. 
>The Unicode Consortium could clearly use EU. No problem there. However, a goal of the Unicode CLDR group was and is to be compatible with BCP 47, and EU cannot be used there, conformantly. 
>
>There is some background on BCP 47 on Addison's site ( http://www.inter-locale.com/); that might be easier to understand than the spec.
>
>
>
>
>-- 
>Mark 

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Mark Davis" <[email-masked]>
Date: Wed, 7 Nov 2007 20:53:53 -0800

I'd be very much in favor of it -- CLDR only adds a very small number of
codes to BCP 47 (it uses private use codes for compatibility). The QU code
is a hack because we don't have EU, so it'd be very nice to get rid of that.
(BTW, we don't really have to petition ISO to use it; if we want to use EU,
there is nothing stopping us.)

Mark

On 11/7/07, Martin Duerst <[email-masked]> wrote:
> >>> <http://www.iana.org/assignments/language-subtag-registry>

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 07:37:52 +0100

Martin Duerst asked:

> As an example, would it make sense for the LTRU WG
> to ask for permission from the ISO 3166-1/MA?

No.  

| Country Codes
|
|  The IANA is not in the business of deciding what is and what is
|  not a country.
|
|  The selection of the ISO 3166 list as a basis for country code
|  top-level domain names was made with the knowledge that ISO has a
|  procedure for determining which entities should be and should not
|  be on that list.

 Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 7 Nov 2007 22:57:32 -0800

Mark Davis wrote:

> (In retrospect, I also think it was unproductive to have incomplete 
> M49 codes ( http://unstats.un.org/unsd/methods/m49/m49regin.htm). It 
> wouldn't hurt to add the very few M49 codes that are excluded from BCP 
> 47, even if deprecated, if only to make testing and cross mapping 
> easier.)

I disagree rather strongly.  Non-geographical, non-linguistic groupings 
such as "Landlocked developing countries" and "Transition countries" 
(the modern name for the category once known as "Communist states") have 
no place in language tags or computer locales.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
NEW E-MAIL -->  dewell at roadrunner dot com
NEW URL -->  http://home.roadrunner.com/~dewell
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: "Philippe Verdy" <[email-masked]>
Date: Thu, 8 Nov 2007 07:50:49 +0100

> De : Martin Duerst [mailto:[email-masked]]
> Envoyé : jeudi 8 novembre 2007 04:59
> À : Mark Davis; [email-masked]
> Cc : LTRU Working Group; Rick McGowan
> Objet : Re: [Ltru] Re: The "QU" territory/region code (was New Public
> ReviewIssue: #116 Proposed Update UTS #35 LDML)
> 
> Mark, others,
> 

No. I am suggesting instead that the Unicode Consortium makes this request
for use in LDML/CLDR data and specification. No discussion needed to change
the BCP47 policy.

The only affected thing will be to replace "QU" by "EU" in the CLDR data,
but to make this, Unicode (and the promoters of the CLDR project) needs
approval by ISM 3166/MA. And this use should remain documented in the LDML
specs, saying that the use is for a exceptionally reserved code, and that
this was approved by ISO 3166/MA, in addition to the other codes used and
allowed in BCP 47.

In fact, given that "EU" is already widely used in localization data, it
would really make sense to unify this use with the codification in
LDML/CLDR, instead of maintaining two codes (EU and QU) in applications for
all the localized data applicable to the same region.

And then this would demonstrate that the exceptional use, permitted by ISO
3166/MA (for interchanged data with preexisting standards), which later
allowed the IETF/ISOC to accept the creation and registration of the .EU
ccTLD, now registered at IANA, and that would also be used and documented in
CLDR/LDML by Unicode, should better be approved by the sponsors of BCP47 for
inclusion the locale tags registry.

For now, the locale tags IANA registry at can only document the "QU" region
as "private use", but certainly not "European Union" as currently assumed in
CLDR/LDML.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Nov 2007 09:31:34 +0100

On Wed, Nov 07, 2007 at 06:30:13PM -0800,
 Mark Davis <[email-masked]> wrote 
 a message of 103 lines which said:

> http://www.inter-locale.com/); that might be easier to understand
> than the spec.

I suggest http://www.langtag.net/ which I find more beginner-friendly.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 10:04:14 +0100

Stephane Bortzmeyer:
 
>> There is some background on BCP 47 on Addison's site 
>> (http://www.inter-locale.com/); that might be easier 
>> to understand than the spec.
 
> I suggest http://www.langtag.net/ which I find more 

Oops, I completely missed that there's a new version 01
of http://tools.ietf.org/html/draft-phillips-record-jar

Why on earth did ICANN recognise EU as "ccTLD" ?  Until
today I thought it's a gTLD like ASIA or CAT.

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Nov 2007 10:16:32 +0100

[Quite off-topic for LTRU, I suggest to go on in private]

On Thu, Nov 08, 2007 at 10:04:14AM +0100,
 Frank Ellermann <[email-masked]> wrote 
 a message of 16 lines which said:

> Why on earth did ICANN recognise EU as "ccTLD" ?  Until today I
> thought it's a gTLD like ASIA or CAT.

There is no clear list of what TLD are ccTLD and what are gTLD. Try to
find one on ICANN or IANA Web site.

There are other TLD from the exceptional list (some moved later to the
normal list). ".uk" is the best known but there are others like ".ac".

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 13:46:18 +0100

> [Quite off-topic for LTRU, I suggest to go on in private]

Maybe.  If I got Mark's drift correctly the CLDR folks try to stay
in sync with BCP 47.  The BC 47 folks (= LTRU) try to stay in sync
with RFC 1591 (= IANA), i.e. ISO 3166 country codes.  And IANA has
"EU" on a web page <http://www.iana.org/cctld/cctld-whois.htm>, a
redirection to <http://www.iana.org/root-whois/index.html>.  They
have a link to the "ccTLD" redirection on their main page.

> There is no clear list of what TLD are ccTLD and what are gTLD.
> Try to find one on ICANN or IANA Web site.

See above for IANA, for ICANN see the eu ccTLD registry agreement
on <http://www.icann.org/cctlds/agreements.html>

> There are other TLD from the exceptional list

Yes, I know the grandfathered cases (three cleared by Debbie).

 Frank

---

From: John Cowan <[email-masked]>
Date: Thu, 8 Nov 2007 08:19:54 -0500

Frank Ellermann scripsit:

> in sync with BCP 47.

Yes.

> The BCP 47 folks (= LTRU) try to stay in sync with RFC 1591 (= IANA),
> i.e. ISO 3166 country codes.

No.  The DNS and language-tags are separate and independent consumers
of ISO 3166, and what IANA does for one is irrelevant to what it does
for the other.

> And IANA has "EU" on a web page
> <http://www.iana.org/cctld/cctld-whois.htm>, a redirection to
> <http://www.iana.org/root-whois/index.html>.  They have a link to the
> "ccTLD" redirection on their main page.

The European Union (which is what "EU" means as an exceptionally reserved
ISO 3166 code element) isn't relevant to language tagging: there are no
EU vs. non-EU regional variants of languages.

-- 
Here lies the Christian,                        John Cowan
        judge, and poet Peter,                  http://www.ccil.org/~cowan
Who broke the laws of God                       [email-masked]
        and man and metre.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Nov 2007 16:13:23 +0100

On Thu, Nov 08, 2007 at 08:19:54AM -0500,
 John Cowan <[email-masked]> wrote 
 a message of 34 lines which said:

> The European Union (which is what "EU" means as an exceptionally
> reserved ISO 3166 code element) isn't relevant to language tagging:
> there are no EU vs. non-EU regional variants of languages.

This point is not relevant for the Language Subtag Registry. We just
registered BL and MF and I can assure you that there is no regional
variants of French in these tiny islands...

More seriously, the LSR does not check if a country-or-region-code is
linguistically significiant before adding it. If it's in ISO 3166,
it's added. Period.

---

From: John Cowan <[email-masked]>
Date: Thu, 8 Nov 2007 10:21:14 -0500

> linguistically significiant before adding it. If it's in ISO 3166,

Very true, but EU is not "in" (that is, is not a code element of)
3166; it is extraordinarily reserved by 3166.  As such, special
justification is required before it can be used.  That special
justification is lacking here.

I'm not even clear on what the justification is for using it in
locales.   What element of a (computer) locale is specified by
being in the EU or out of it?  It can't be currency, as the
EU and the eurozone aren't coterminous.

-- 
I suggest you call for help,                    John Cowan
or learn the difficult art of mud-breathing.    [email-masked]
        --Great-Souled Sam                      http://www.ccil.org/~cowan

---

From: Addison Phillips <[email-masked]>
Date: Thu, 08 Nov 2007 07:33:16 -0800

> EU and the eurozone aren't coterminous.

I don't believe it is used in locale *identifiers*. It is used in locale 
*data*. In particular, there is a region display name for European Union.

  <territory type="QU">European Union</territory>

which you find in the document located here:

  http://tinyurl.com/25t3nr

CLDR uses the ILSR as a source for region codes (I believe) because of 
the stability rules we've installed. For that matter, I use it for 
various projects for precisely the same reason.

Actually, this whole conversation is overblown. I don't think CLDR's use 
of 'QU' is evil or a bad choice. I wish ISO 3166 would assign, rather 
than exceptionally reserve, 'EU' to ensure proper allocation of the code 
for applications that need it.

As John notes, in practical fact there is no real use for this in 
language tags (unless one wishes to posit a "EU official" version of a 
language for EU (say) translation purposes, such as for regulations or 
some-such without favoring a particular country-specific flavor).

Kind of like "es-419", eh? Not really a language, but useful sometimes.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 16:37:43 +0100

> of ISO 3166, and what IANA does for one is irrelevant to what it does

Sorry, my statement was unclear.  What you wrote is what I meant, in the
spirit of RFC 1591 (IANA) we're not in the business of deciding what's a
country:  <http://article.gmane.org/gmane.ietf.ltru/8739>

> EU vs. non-EU regional variants of languages.

Yes.  Besides EU members have territories in all oceans and continents,
it's messier than UM.  The CLDR QU might be nearer to LTRU region 150.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 16:52:10 +0100

> variants of French in these tiny islands...

...for another opinion see 
<https://cia.gov/library/publications/the-world-factbook/print/rn.html>

|    Population: 33,102 (October 2004 census)
| Ethnic groups: creole (mulatto), black, Guadeloupe Mestizo (French-East
|                Asia), white, East Indian
[...]
|     Languages: French (official language), English, Dutch, French 
|                Patois, Spanish, Papiamento (dialect of Netherlands
|                Antilles)

 Frank

---

From: Peter Constable <[email-masked]>
Date: Thu, 8 Nov 2007 08:11:27 -0800

> From: Addison Phillips [mailto:[email-masked]]

>   <territory type="QU">European Union</territory>

If CLDR is using it for a way not related to IETF Language tags, as appears to be the case here, then why are we discussing it on this list?

Peter

---

From: Addison Phillips <[email-masked]>
Date: Thu, 08 Nov 2007 08:22:13 -0800

> If CLDR is using it for a way not related to IETF Language tags, as appears to be the case here, then why are we discussing it on this list?

It's an application of the language subtag registry. Not its primary 
application, but it is an application.

In practice, this isn't *that* interesting a discussion for this list, 
since it's a "private" decision about a private use code.

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 8 Nov 2007 10:53:54 -0700

I agree with Addison.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 19:40:28 +0100

Addison Phillips wrote:

> CLDR uses the ILSR as a source for region codes (I believe)

While we're half OT, apparently some info isn't automatically
copied when available, e.g. languages_and_scripts.html still
says Zxxx for dsb, frr, frs, hsb, and nds.  It has Latn for
fy and gsw, apparently the LSTR isn't a source for this list,
or I looked at an old file.

More OT:  Deseret and Shavian aren't "und", they're "en" :-)
Too lazy to check TUS for Tagalog, was that Berber / Tuareg ?

Completely OT:  Does the CLDR mailing list still exist ?  I
tried to forward a mail some weeks ago (via GMaNe), but it
never arrived.

 Frank

---

From: Addison Phillips <[email-masked]>
Date: Thu, 08 Nov 2007 10:57:47 -0800

> or I looked at an old file.

It *might* be a timing issue. CLDR has regular releases, so the data may 
depend on when the snapshot of the LSR was taken.

However, it also might be that they don't copy the data at all but 
maintain their own list independently. You'd have to ask "them".

> Too lazy to check TUS for Tagalog, was that Berber / Tuareg ?

Tagalog? It's the script used (mostly formerly used, IIRC) to write the 
eponymous language Tagalog, a Filipino language unrelated to North 
African languages or regions. Its language code is "tl".

> tried to forward a mail some weeks ago (via GMaNe), but it

Yes. Are you subscribed to it? Note also that all Unicode lists were 
down for a period of time a few weeks ago for a server upgrade. This was 
generally well-announced on the Unicode list, but perhaps not so well on 
  the other lists.

Addison

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 8 Nov 2007 20:53:47 +0100

Addison Phillips wrote:
 
> You'd have to ask "them".

I'm tired of trying to fix obscure list issues for this year,
yesterday it ended up with Cc:s to the last three IETF Chairs
(it wasn't even one of my mail problems in this case), a week
ago it started to involve several W3C I18N folks.  Armed with
OE, old @xyzzy mailboxes over quota, and mail2news at GMaNe
these threads tend to be <span xml:lang="de"> kafkaesk </span>.
 
> Tagalog? It's the script used (mostly formerly used, IIRC)
> to write the eponymous language Tagalog, a Filipino language
> unrelated to North African languages or regions.

ACK, I confused it with Tifinagh.
 
> Are you subscribed to it?

<http://artice.gmane.org/gmane.text.unicode.devel/23402/raw>
is visible in 
<http://dir.gmane.org/gmane.comp.internationalization.cldr>,
but that could be a hallucination on GMaNe's side, if only
articles X-posted to other lists (typically the Unicode list)
appear in this "newsgroup".

> This was generally well-announced on the Unicode list, but
> perhaps not so well on the other lists.

IIRC I tested the forward from the Unicode to the CLDR list
after this announcement, and that ended up in a /dev/null not
under my control.  Or something.  We should use Wikis instead
of lists, Wikis are cute. 

 Frank

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 8 Nov 2007 13:49:39 -0800

On 11/8/07, Addison Phillips <[email-masked]> wrote:
> > copied when available, e.g . languages_and_scripts.html still

There is a timing issue. CLDR picks up the latest version of the LSR during
each cycle, but that takes some time. Also, some of the data is not
automatically incorporated: Rick McGowan is responsible for incorporating
the language-territory information, including suppress script.

We are right in the middle of a bug-fix release, so any feedback from the
experts here would be very useful. There is a table of "likely subtags" for
which review from people here would be particularly useful.

http://unicode.org/cldr/data/charts/supplemental/likely_subtags.html

Description: http://unicode.org/draft/reports/tr35/tr35.html#Likely_Subtags

> > Too lazy to check TUS for Tagalog, was that Berber / Tuareg ?

und, Zzzz, ZZ means that we don't have the information yet. (While we want
to -- over time -- flesh out all the data, the focus is on the highest use
cases, so Deseret and Shavian are lower priority; but I'm forwarding this to
Rick.)

> generally well-announced on the Unicode list, but perhaps not so well on

There are two CLDR lists; one for the public (which doesn't get a lot of
traffic), and one for members (that has much more). We also have a weekly
meeting, where most of the decisions get made.

Addison

---

From: Peter Constable <[email-masked]>
Date: Thu, 8 Nov 2007 18:10:43 -0800

> application, but it is an application.

Well, I'm not opposed to questions of what makes sense for an ecosystem of closely related tagging schemes. Nobody would be served in the long run if we had to have completely separate schemes and infrastructures for things that overlap 95%, so it may make sense to allow a 2% compromise of scope in one place or another to provide a single, coherent ecosystem of related schemes.

(Of course you don't compromise A for something in B when that something really isn't relevant for B -- a separate question altogether.)

Peter

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 9 Nov 2007 08:46:30 -0800

I agree.

On Nov 8, 2007 6:10 PM, Peter Constable <[email-masked]> wrote:

> Well, I'm not opposed to questions of what makes sense for an ecosystem of
> closely related tagging schemes. Nobody would be served in the long run if
> we had to have completely separate schemes and infrastructures for things
> that overlap 95%, so it may make sense to allow a 2% compromise of scope in
> one place or another to provide a single, coherent ecosystem of related
> schemes.
>
> (Of course you don't compromise A for something in B when that something
> really isn't relevant for B -- a separate question altogether.)
>
>
> Peter
>

---

From: Martin Duerst <[email-masked]>
Date: Tue, 13 Nov 2007 11:22:41 +0900

>EU vs. non-EU regional variants of languages.

This seems to be the current consensus.

What I'm a bit worried about, and would like to see some confirmation,
is the following scenario. Assume for one reason or another, some EU
variant of a language develops, is defined, or what not. Obviously
at least to me, the region subtag 'EU' would be most suited in this
case. Is it possible that the ietf-languages list just adds this
subtag to the registry, or would we have to convene a WG and write
another version of what's currently RFC 4646? If the later is the
case, my preference would be to carefully tweak our texts so that
we can avoid rechartering just for the potential scenario described
above.

Regards,    Martin.

---

From: Addison Phillips <[email-masked]>
Date: Mon, 12 Nov 2007 21:12:09 -0800

Hello Martin,

Actually, I think I already described a case for EU being used in 
language tags.

I think we would, given the present rules, be required to amend RFC 
4646. One could register a variant to represent the same meaning as 
'EU'. But registering 'EU' is not permitted (for very good reason). The 
way to get 'EU' would be to petition ISO 3166 MA to do more than 
exceptionally reserve it.

This doesn't strike me as bad, wrong, or problematic.

Addison

PS> Could you or Randy ***please*** respond to repeated requests for 
action on teleconference scheduling?

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 13 Nov 2007 07:55:41 +0100

Martin Dürst wrote:

> Assume for one reason or another, some EU variant of a language
> develops, is defined, or what not. Obviously at least to me, 
> the region subtag 'EU' would be most suited in this case.

EU is no proper "region" wrt language tagging, it includes the new
MF and other parts of the world far away from Brussels (Bruxelles).

> Is it possible that the ietf-languages list just adds this subtag
> to the registry

They could approve a variant "eurocrat" with several prefixes, if a
kind of "EU-lingo" has to be identified.  Or they could ask Debbie
how to transform EU in a proper region tag, but I fear the result
for language tagging wouldn't be much better than say UM.

 Frank