Randy Presuhn | 1 Mar 2009 01:00
Picon

Re: Proposal to remove Preferred-Value field for region YU in LTRU

Hi -

The issue is *closed* in ltru.  Since it was discussed at length in
the WG, I wouldn't expect it to gain much traction if raised in IETF
last call.

As for this list, until someone does the work of filling out
language subtag registration forms to make these changes,
all this discussion is just so much idle chatter.

Randy
Tex Texin | 1 Mar 2009 01:29
Favicon
Gravatar

RE: Proposal to remove Preferred-Value field for region YU in LTRU

Randy,

Can you be more specific please, as several issues were in the thread?
Are you saying the specific issue of the preferred value of YU is closed?

Also, with respect to the registration forms, which change needs to be
filed, a form requesting the removal of the preferred value for YU, or a
form requesting it needs to be reinstated to CS?

tex
-----Original Message-----
From: ietf-languages-bounces <at> alvestrand.no
[mailto:ietf-languages-bounces <at> alvestrand.no] On Behalf Of Randy Presuhn
Sent: Saturday, February 28, 2009 4:01 PM
To: ietf-languages <at> iana.org
Subject: Re: Proposal to remove Preferred-Value field for region YU in LTRU

Hi -

The issue is *closed* in ltru.  Since it was discussed at length in
the WG, I wouldn't expect it to gain much traction if raised in IETF
last call.

As for this list, until someone does the work of filling out
language subtag registration forms to make these changes,
all this discussion is just so much idle chatter.

Randy

_______________________________________________
(Continue reading)

Michael Everson | 1 Mar 2009 01:36
Favicon
Gravatar

Re: Proposal to remove Preferred-Value field for region YU in LTRU

On 1 Mar 2009, at 00:29, Tex Texin wrote:

> Randy,
>
> Can you be more specific please, as several issues were in the thread?
> Are you saying the specific issue of the preferred value of YU is  
> closed?

Discuss this elsewhere.

Michael Everson * http://www.evertype.com
Stephane Bortzmeyer | 1 Mar 2009 21:19
Picon

MultiTree availability (Was: Ietf-languages Digest, Vol 74, Issue 1

On Sat, Feb 21, 2009 at 09:51:15AM -0500,
 Anthony Aristar <aristar <at> linguistlist.org> wrote 
 a message of 139 lines which said:

> we are using well over 2200 subgrouping codes in our MultiTree 
> project

Where can MultiTree be downloaded? Checking
<http://multitree.linguistlist.org/>, it seems it can only be browsed
online (and with difficulties since it requires uncommon software).
Stephane Bortzmeyer | 1 Mar 2009 21:29
Picon

[OT] ISO/IETF processes and rules (Was: Ietf-languages Digest, Vol 74, Issue 1

On Sun, Feb 22, 2009 at 10:11:50AM -0500,
 Anthony Aristar <aristar <at> linguistlist.org> wrote 
 a message of 107 lines which said:

> But it raises a recurrent issue for ISO standards.

Then, it is quite offtopic since this mailing list is devoted to work
around an IETF standard, not an ISO one. However the ISO works is not
on our agenda, we just use the result.

> yet the explanation for the oddities of that standard are known only
> to those who happen to be in a select group.

With IETF standards, it is much easier: you just browse several
thousands of messages on a public mailing list and you try to extract
something meaningful from this archive :-)
Anthony Aristar | 1 Mar 2009 21:40
Favicon

Re: MultiTree availability (Was: Ietf-languages Digest, Vol 74, Issue 1

As yet, there is no way to download the whole database,  This is 
something we intend to do, but since the project is not complete, it is 
still ahead of us.  The codes, I should point out, were never intended 
for general consumption:  just for our local use.  But since no complete 
set of codes for subgroups and dialects existed, we had to invent them.  
You *can* download an individual tree in XML, however.

As for the software MultiTree uses:  this software is very common 
indeed:  you just need to have ordinary old Java installed on your local 
machine.  Java is essential, since we needed to push the processing 
downstream, so to speak.  Processing trees is very memory-intensive, and 
to do all of it on our server would soon bring it to its knees.

Stephane Bortzmeyer wrote:
> On Sat, Feb 21, 2009 at 09:51:15AM -0500,
>  Anthony Aristar <aristar <at> linguistlist.org> wrote 
>  a message of 139 lines which said:
>
>   
>> we are using well over 2200 subgrouping codes in our MultiTree 
>> project
>>     
>
> Where can MultiTree be downloaded? Checking
> <http://multitree.linguistlist.org/>, it seems it can only be browsed
> online (and with difficulties since it requires uncommon software).
>   

--

-- 
             **************************************
(Continue reading)

Stephane Bortzmeyer | 1 Mar 2009 21:41
Picon

MultiTree content (Was: Ietf-languages Digest, Vol 74, Issue 5

On Sun, Feb 22, 2009 at 03:34:09PM -0500,
 Anthony Aristar <aristar <at> linguistlist.org> wrote 
 a message of 160 lines which said:

> If you are interested in what languages are included in East Germanic, 
> West Germanic and North Germanic respectively, you can look at these 
> three URLs:
> 
> http://multitree.linguistlist.org/trees/11435 <at> 303398

It yields only a blank page. Reading the HTML source code, I see only
calls to Javascript. It is enabled in my browser but clearly does not
work here (Firefox 3.0).
Anthony Aristar | 1 Mar 2009 22:16
Favicon

Re: MultiTree content (Was: Ietf-languages Digest, Vol 74, Issue 5

Sorry:  we re-uploaded the tree this past week, so the URLs are now, 
respectively:

http://multitree.linguistlist.org/trees/11494 <at> 315325

http://multitree.linguistlist.org/trees/11494 <at> 315369

http://multitree.linguistlist.org/trees/11494 <at> 315332

Stephane Bortzmeyer wrote:
> On Sun, Feb 22, 2009 at 03:34:09PM -0500,
>  Anthony Aristar <aristar <at> linguistlist.org> wrote 
>  a message of 160 lines which said:
>
>   
>> If you are interested in what languages are included in East Germanic, 
>> West Germanic and North Germanic respectively, you can look at these 
>> three URLs:
>>
>> http://multitree.linguistlist.org/trees/11435 <at> 303398
>>     
>
> It yields only a blank page. Reading the HTML source code, I see only
> calls to Javascript. It is enabled in my browser but clearly does not
> work here (Firefox 3.0).
>   

--

-- 
             **************************************
Anthony Aristar, Director, Institute for Language & Information Technology
(Continue reading)

Broome, Karen | 2 Mar 2009 16:57
Picon

RE: Proposal to remove Preferred-Value field for region YU in LTRU

Two cents: I have a real use case for tagging content with YU today. Motion pictures have a Country of Origin, which may be a country that no longer exists. Country of Origin indicates the country where the producer filed the origin certificate so it should indicate the country that existed at the time the certificate was filed.

 

I realize that this use case is not related to language, but in this case suggesting CS would not be appropriate. I almost wonder if countries should be considered "deprecated" in the traditional sense. They may no longer be current countries of the world, but that doesn't mean that people aren't going to continue to use these tags in appropriate ways for historical content. If I were to represent our data properly in ISO 3166-1, I need a tag for Bophuthatswana, which existed so briefly, it never had an ISO tag.

 

I support removing the preferred value.

 

Regards,

 

Karen Broome

 

From: ietf-languages-bounces <at> alvestrand.no [mailto:ietf-languages-bounces <at> alvestrand.no] On Behalf Of Phillips, Addison
Sent: Saturday, February 28, 2009 8:56 AM
To: CE Whitehead; ietf-languages <at> iana.org
Subject: RE: Proposal to remove Preferred-Value field for region YU in LTRU

 

It is always possible to add a comment.

 

As for the issue of countries that separate, there is no reason that I can see to address it further in any draft, past or future, of BCP 47. When new countries are formed, they are always formed from all or part of an old region (even Antarctica has a code). UN M.49 and ISO 3166-1 assign any new regions codes, which we use as subtags. There are quite detailed and clear rules in the current RFC for how this is to be done.

 

The P-V pointer is mainly useful for regions when a region changes its name (and associated code) but not its borders or “identity”. This *is* what happened when the then Yugoslavia changed its identity, hence the P-V. But since CS is defunct and since YU itself had a “larger” meaning (which is more familiar than the later meaning and is not part of remote history), it seems reasonable to make it revert to its older meaning by removing the P-V. Tag canonicalization will not suffer as a result, which is reasonable.

 

Addison

 

Addison Phillips

Globalization Architect -- Lab126

 

Internationalization is not a feature.

It is an architecture.

 

From: ietf-languages-bounces <at> alvestrand.no [mailto:ietf-languages-bounces <at> alvestrand.no] On Behalf Of CE Whitehead
Sent: Saturday, February 28, 2009 7:36 AM
To: ietf-languages <at> iana.org
Subject: Proposal to remove Preferred-Value field for region YU in LTRU

 


Hi.  Considering the current rule, which Doug has reminded of, that we need to have a subtag's preferred value point to whatever it points to points to,
instead of forcing readers/implementations to follow a chain, at this point I support removing the preferred-value and adding a comment as soon as it becomes possible to add a comment.

Tex Texin textexin at xencraft.com
Fri Feb 27 21:55:22 CET 2009

 

> 8) Separate topic- The number of countries in the world seems to grow. This suggests to me that regions being subdivided is not going to be a rare event. Perhaps there should be a mechanism to indicate subtags that have later been split, so instead of one preferred value, there is a way to indicate that a tag has been deprecated in favor of two or more possible values.

However, I do think Tex's point is good here; the issue of countries that separate should be addressed in the next draft of RFC 4646, but I agree we cannot address this at this time.

Hopefully a comment will be sufficient for the interim.

--C. E. Whitehead

cewcathar <at> hotmail.com

> tex

 

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
John Cowan | 2 Mar 2009 18:23

Re: Proposal to remove Preferred-Value field for region YU in LTRU

Broome, Karen scripsit:

> I realize that this use case is not related to language, but in
> this case suggesting CS would not be appropriate. I almost wonder
> if countries should be considered "deprecated" in the traditional
> sense. They may no longer be current countries of the world, but that
> doesn't mean that people aren't going to continue to use these tags
> in appropriate ways for historical content.

The region subtags in BCP 47 tags are meant only to discriminate among
varieties of language that happen to be aligned with those particular
regions: semantically, they are just like variant subtags.  It so
happens that in many parts of the world language varieties *do* align
with countries, and it is also true that many languages have official
orthographies (de jure or de facto) that vary by country.  Our registry
is by no means meant to replace ISO 3166 itself, much less provide a
historical conspectus of it.

> If I were to represent our data properly in ISO 3166-1, I need a tag
> for Bophuthatswana, which existed so briefly, it never had an ISO tag.

"What is a country?" is a vexed business.  In this case, the rest of
the world decided to treat Bophuthatswana as still part of South Africa,
as it was before 1977 and after 1994.  The IETF doesn't get involved --
we just track ISO 3166, which just tracks UNSD M.49, which makes its
decisions primarily on economic grounds.

--

-- 
He played King Lear as though           John Cowan <cowan <at> ccil.org>
someone had played the ace.             http://www.ccil.org/~cowan
        --Eugene Field

Gmane