headers
Rebecca S Guenther | 20 Feb 21:19
Picon

ISO 639-5 code list is available

The ISO 639-5 code list (Codes for the Representation of Names of Languages. Part 5: Alpha-3 code for
language families and groups) is now available from the Library of Congress, which has been designated
its Registration authority:
http://www.loc.gov:8081/standards/iso639-5/ 

ISO 639-5 provides a code consisting of language code elements comprising three-letter language
identifiers for the representation of names of living and extinct language families and groups.

ISO 639-2 (Alpha-3 code) includes some language groups and language families, but by no means a complete
list. The purpose of the code elements for language groups and language families in ISO 639-2 is to provide
a means to register the language of a document even when the individual language in question is not
included in the code table because it doesn't meet the criteria for establishing a separate code. ISO
639-5 supplements the coding of language groups and language families in ISO 639-2. However, the depth
and detail of coding in ISO 639-5 is intended to support the overall language coding of the ISO 639 series of
International Standards rather than provide a scientific classification of the languages of the world. 

The list will be maintained by the ISO 639 Joint Advisory Committee with the Library of Congress as
Registration Authority.

Rebecca S. Guenther                                                       
 Senior Networking and Standards Specialist                  
 Network Development and MARC Standards Office     
 Library of Congress   
 101 Independence Ave. SE                                       
 Washington, DC 20540                                                      
 Washington, DC 20540-4402                                          
 (202) 707-5092 (voice)    (202) 707-0115 (FAX)           
 rgue <at> loc.gov
Permalink | Reply | 1 comment |
headers
Doug Ewell | 21 Feb 03:46
Favicon

Re: ISO 639-5 code list is available

Rebecca S Guenther <rgue at loc dot gov> wrote:

> The ISO 639-5 code list (Codes for the Representation of Names of 
> Languages. Part 5: Alpha-3 code for language families and groups) is 
> now available from the Library of Congress, which has been designated 
> its Registration authority:
> http://www.loc.gov:8081/standards/iso639-5/

for (int i = 1; i <= 3; i++)
    Console.WriteLine("Hip hip hooray!");

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ 

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 0 comments |
headers
Anthony Aristar | 21 Feb 15:51
Favicon

Re: Ietf-languages Digest, Vol 74, Issue 1

Good to hear this, but unfortunately the ISO 639-5 standard is really a 
problem. 

First, it is, like the original 639-1, so small as to be relatively 
useless.  The fact that it can be expanded through the normal change 
process is not very useful:  it will take a *LONG* time to get 
everything in that we as linguists need.  I might note that, as of 
today, we are using well over 2200 subgrouping codes in our MultiTree 
project--and the number keeps going up-- and the 110 codes that are in 
the 639-5 set are a twentieth of that,   In addition, the code-set is a 
mish-mash that is very reminiscent of the mess that ISO 639-1/2 were 
before ISO 639-3 came along:  it has geographical groupings mixed up 
with genetic groupings, for example, and some of the names used are  
enough to make linguists cringe.

Second, the use of Alpha-3 makes the codes easily confusable with ISO 
639-3 .  I know of at least one project that simply wont use them 
because of this.

Anyway, we need a real set of subgrouping codes, but to my knowledge the 
attempt to produce one has stalled...

--

-- 
             **************************************
Anthony Aristar, Director, Institute for Language & Information Technology
  Professor of Linguistics            Moderator, LINGUIST Linguistics Program
Dept. of English                       aristar <at> linguistlist.org
Eastern Michigan University            2000 Huron River Dr, Suite 104
Ypsilanti, MI 48197
U.S.A.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Doug Ewell | 21 Feb 21:04
Favicon

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

The LTRU Working Group needs the help of ietf-languages and the Reviewer 
to make a decision.

In LTRU, where we are finishing work on RFC 4646bis and 4645bis, there 
is a plan to change the Preferred-Value for subtags that point to other 
subtags that also have Preferred-Values.  The goal is to have 
Preferred-Value always point to the "real" preferred value instead of 
making the user (human or software) follow a chain.  In other words, 
instead of "A" -> "B" -> "C", we would have "A" -> "C", where the arrow 
represents a Preferred-Value link.

This is primarily necessitated by the addition of the ISO 639-3-based 
subtags, which are intended to supersede RFC 3066 registered tags and 
variant subtags whenever possible.  For example, we currently have 
"i-hak" -> "zh-hakka" for Hakka.  In RFC 4646bis, we will have the 
639-3-based subtag "hak", meaning that the Preferred-Value chain will 
become "i-hak" -> "zh-hakka" -> "hak".  We plan to change the 
Preferred-Value for "i-hak" to "hak" to eliminate this indirection.

Our question has to do with applying this logic to a particular region 
subtag.  Currently "YU" is deprecated with a Preferred-Value of "CS", 
and "CS" is deprecated with no Preferred-Value at all, since there is no 
single successor country.  It might make more sense to remove the P-V 
from "YU" altogether, to prevent the user from following a chain which 
ultimately leads to a dead end.  However, RFC 4646, Section 3.1 does not 
permit this group to remove a Preferred-Value, although the proposed 
4646bis will allow this.

As part of the production of a replacement Registry in draft-4645bis, it 
has been proposed to remove the Preferred-Value from "YU" -- as an LTRU
(Continue reading)

Permalink | Reply | 11 comments |
headers
John Cowan | 21 Feb 22:13

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

Doug Ewell scripsit:

> As part of the production of a replacement Registry in draft-4645bis, it 
> has been proposed to remove the Preferred-Value from "YU" -- as an LTRU 
> change -- and optionally replace it with a Comments field such as 
> "Comments: see BA, HR, ME, MK, RS, or SI".  

IMHO we should have LTRU go ahead and do this.  When a new Registry is
installed, it should be as accurate and up-to-date as possible.  There is
no point in deferring this one change -- after all, in principle almost
*all* the new registry changes allowed by 4646bis could be deferred to
this list, but what's the point?

Furthermore, despite the technical distinction between LTRU and
ietf-languages, the person involved is the same, our very own Official
Doug.

--

-- 
Do what you will,                       John Cowan
   this Life's a Fiction                cowan <at> ccil.org
And is made up of                       http://www.ccil.org/~cowan
   Contradiction.  --William Blake
Permalink | Reply | 4 comments |
headers
CE Whitehead | 21 Feb 22:58
Picon

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



Hi, I feel that the comments field is absolutely needed!
 
> From: doug <at> ewellic.org
> Date: Sat, 21 Feb 2009 13:04:32 -0700
>

>
> For example, we currently have
> "i-hak" -> "zh-hakka" for Hakka. In RFC 4646bis, we will have the
> 639-3-based subtag "hak", meaning that the Preferred-Value chain will
> become "i-hak" -> "zh-hakka" -> "hak". We plan to change the
> Preferred-Value for "i-hak" to "hak" to eliminate this indirection.
>
> Our question has to do with applying this logic to a particular region
> subtag. Currently "YU" is deprecated with a Preferred-Value of "CS",
> and "CS" is deprecated with no Preferred-Value at all, since there is no
> single successor country. It might make more sense to remove the P-V
> from "YU" altogether, to prevent the user from following a chain which
> ultimately leads to a dead end. However, RFC 4646, Section 3.1 does not
> permit this group to remove a Preferred-Value, although the proposed
> 4646bis will allow this.

(This chain does provide a bit of history! )

> As part of the production of a replacement Registry in draft-4645bis, it
> has been proposed to remove the Preferred-Value from "YU" -- as an LTRU
> change -- and optionally replace it with a Comments field such as
> "Comments: see BA, HR, ME, MK, RS, or SI". This might be considered
> analogous to the existing Comments field for "CS". It might also be
> preferred by those who feel that "CS" was not a suitable P-V for "YU" in
> the first place.
>
However, it makes sense to shorten the chain for users.
I feel that the Comments field is absolutely needed.
(Can we always add comments when a subtag is deprecated & there is no preferred value?
[but I do wonder what way the comments field influences how applications process language info, if it does?])
> It has been objected that this type of change needs to be made by
> ietf-languages and the Reviewer, once 4646bis is approved and published
> and allows it, and should not be made by LTRU in the replacement
> Registry.
>
I am unsure as to whether we should wait for RFC 4646 or not (need to research protocol), but note that doing so involves having Doug modify 4645 still another time.
--C. E. Whitehead
cewcathar <at> hotmail.com
> . . .
>
> --
> Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
> http://www.ewellic.org


 
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 5 comments |
headers
Mark Davis | 21 Feb 23:05

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

I agree with John and Doug.

Mark


On Sat, Feb 21, 2009 at 13:13, John Cowan <cowan <at> ccil.org> wrote:
Doug Ewell scripsit:

> As part of the production of a replacement Registry in draft-4645bis, it
> has been proposed to remove the Preferred-Value from "YU" -- as an LTRU
> change -- and optionally replace it with a Comments field such as
> "Comments: see BA, HR, ME, MK, RS, or SI".

IMHO we should have LTRU go ahead and do this.  When a new Registry is
installed, it should be as accurate and up-to-date as possible.  There is
no point in deferring this one change -- after all, in principle almost
*all* the new registry changes allowed by 4646bis could be deferred to
this list, but what's the point?

Furthermore, despite the technical distinction between LTRU and
ietf-languages, the person involved is the same, our very own Official
Doug.

--
Do what you will,                       John Cowan
  this Life's a Fiction                cowan <at> ccil.org
And is made up of                       http://www.ccil.org/~cowan
  Contradiction.  --William Blake
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 2 comments |
headers
Kent Karlsson | 21 Feb 23:16
Picon

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

I agree as well. Note that that means *no change* compared to 4645bis draft 9 in the record for YU.

    /kent k

Den 2009-02-21 23.05, skrev "Mark Davis" <mark <at> macchiato.com>:

I agree with John and Doug.

Mark


On Sat, Feb 21, 2009 at 13:13, John Cowan <cowan <at> ccil.org> wrote:
Doug Ewell scripsit:

> As part of the production of a replacement Registry in draft-4645bis, it
> has been proposed to remove the Preferred-Value from "YU" -- as an LTRU
> change -- and optionally replace it with a Comments field such as
> "Comments: see BA, HR, ME, MK, RS, or SI".

IMHO we should have LTRU go ahead and do this.  When a new Registry is
installed, it should be as accurate and up-to-date as possible.  There is
no point in deferring this one change -- after all, in principle almost
*all* the new registry changes allowed by 4646bis could be deferred to
this list, but what's the point?

Furthermore, despite the technical distinction between LTRU and
ietf-languages, the person involved is the same, our very own Official
Doug.

--
Do what you will,                       John Cowan
   this Life's a Fiction                cowan <at> ccil.org
And is made up of                       http://www.ccil.org/~cowan <http://www.ccil.org/%7Ecowan>
   Contradiction.  --William Blake
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages


_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
 
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 0 comments |
headers
Michael Everson | 22 Feb 00:52
Favicon
Gravatar

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

Doug,

John Cowan's comments are spot-on.

Michael Everson * http://www.evertype.com
Permalink | Reply | 0 comments |
headers
John Cowan | 22 Feb 02:03

Re: Ietf-languages Digest, Vol 74, Issue 1

[Quoted fragments have been reordered]

Anthony Aristar scripsit:

> [T]he code-set is a mish-mash that is very reminiscent of the mess
> that ISO 639-1/2 were before ISO 639-3 came along [...].

Not surprising: it's the same mish-mash, just with additional codes for
some well-known groupings.

The purpose of 639-5, at least in connection with BCP 47, is to make it
possible to tag documents whose language has not been determined exactly.
It allows vagueness.  You may not know the exact language of a document,
but perhaps you at least know that it is written in a North American
Indian language, so you can tag it "nai" or perhaps "nai-Latn" or
"nai-fonipa" to add information about the transcription.  That gives
someone classifying or retrieving the document something more to go on
that a flat "und" or other indicator of absence.

For classification, it doesn't much matter if a group is genetic or not.
Indeed, genetic groupings may be singularly unhelpful, not to mention
unstable, in parts of the world where the relationships between languages
are not yet firmly established.  And in the BCP 47 world, we value
stability at least slightly higher than truth.

> [T]he use of Alpha-3 makes the codes easily confusable with ISO 
> 639-3 .  I know of at least one project that simply wont use them 
> because of this.

Whereas that is very convenient for BCP 47 purposes: the "primary
language" subtag can be a collection, a macrolanguage, or an individual
language without having to have variable syntax (except for the use of
639-1 two-letter codes, which is retained for backward compatibility).

> [ISO 639-5] is, like the original 639-1, so small as to be relatively 
> useless.  The fact that it can be expanded through the normal change 
> process is not very useful:  it will take a *LONG* time to get 
> everything in that we as linguists need.

It's simply not meant for use by linguists.

> [S]ome of the names used are enough to make linguists cringe.

True enough.

    A cocky novice once said to Stallman: "I can guess why the editor
    is called Emacs, but why is the justifier called Bolio?". Stallman
    replied forcefully, "Names are but names.  'Emack & Bolio's' is the
    name of a popular ice-cream shop in Boston-town. Neither of these
    men had anything to do with the software."

    His question answered, yet unanswered, the novice turned to go,
    but Stallman called to him, "Neither Emack nor Bolio had anything
    to do with the ice-cream shop, either."

This is generally known as the ice-cream koan.

--

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

Gmane