headers
Debbie Garside | 1 Jun 01:00
Picon

Re: ISO 639 language code addition rules...

Doug wrote:

>at least when 639-5 is published (which
> I don't believe has happened yet).

ISO 639-5 was published on the 15/05/2008

Best

Debbie

> -----Original Message-----
> From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On
> Behalf Of Doug Ewell
> Sent: 31 May 2008 19:23
> To: LTRU Working Group
> Subject: Re: [Ltru] ISO 639 language code addition rules...
>
> "Phillips, Addison" <addison at amazon dot com> wrote:
>
> > Now... if I understand correctly, ISO 639-2 is supposed to
> be a strict
> > subset of ISO 639-3 going forward.
>
> I thought 639-2 was supposed to be a subset of (the union of
> 639-3 plus
> 639-5) going forward, at least when 639-5 is published (which
> I don't believe has happened yet).
>
> > So I would tend to propose the rules as follows:
(Continue reading)

Permalink | Reply | 47 comments |
headers
Doug Ewell | 1 Jun 02:06
Favicon

Re: ISO 639 language code addition rules...

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> ISO 639-5 was published on the 15/05/2008

I hadn't realized that.  More to the point, I hadn't realized we had 
delayed quite that long.  ISO 639-5 was always one of those things that 
was regarded as being outside the scope of LTRU II since our deadlines 
were long before the scheduled publication of 639-5.

Should we consider incorporating the 639-5 code elements into 
draft-4645bis?  There would be no architectural change to 4646bis, since 
we already have collection codes from 639-2; this would just add more of 
them.  I can do this relatively easily, if someone can provide me with a 
code list.  (I assume access to the full standard is not required.)

I know some WG members will argue that collection codes are Evil, in 
which case I would respond that perhaps we need to think beyond Web 
servers and spell-checkers.  Our intent is for language tags to be 
useful for a wide variety of applications, and as far as I know --  
despite the horror stories -- collection codes haven't caused major 
tagging problems since 2001 (publication date of RFC 3066, which first 
allowed them).

At the very least, if we are going to continue to include the 639-2-only 
collection codes such as 'bad' and 'gem' but exclude the 639-5 ones, we 
should explain this decision in RFC 4646bis so it doesn't look like an 
oversight.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
(Continue reading)

Permalink | Reply | 32 comments |
headers
Doug Ewell | 1 Jun 02:19
Favicon

Re: ISO 639 language code addition rules...

Peter Constable <petercon at microsoft dot com> wrote:

> If it's an addition to 639-1, then either it will already have been in 
> 639-2, or it is being added to both simultaneously, and it would get 
> announced together.

My only concern is that the words "simultaneously" and "together" might 
have a creative meaning when applied to two different RAs using their 
own public reporting mechanisms and philosophies.  Sometimes one RA 
makes a change that isn't reflected in the other 639 part for some time. 
See my comment earlier today about the new name for 'zxx' still not 
appearing in the new 639-3 files, published within the past two days, 
though it was added to 639-2 eight weeks ago.

Our goal on ietf-languages -- mine, at least -- is to be responsive in 
registering subtags to track ISO.  If one "simultaneous" announcement 
comes significantly before the other, do we run the risk of making the 
wrong change in the Registry?

> It if is a new addition to 639-3, then likely it is not something that 
> would make it into 639-1. In general, I expect new additions to 639-1 
> to be pretty rare.

That seems probable.  The last 2-letter code to be added was 'ht' in 
February 2003.

> I've suggested before that we could decide that we will never again 
> register something from 639-1. That would eliminate these concerns 
> entirely.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Debbie Garside | 1 Jun 03:08
Picon

Re: ISO 639 language code addition rules...

Hi Doug

BSI have a copy of ISO 639-5 and I am pretty sure that, whilst the standard
itself is not available freely, the code list is.

I can enquire if you like?

Best regards

Debbie

> -----Original Message-----
> From: Doug Ewell [mailto:doug <at> ewellic.org]
> Sent: 01 June 2008 01:07
> To: LTRU Working Group
> Cc: Debbie Garside
> Subject: Re: [Ltru] ISO 639 language code addition rules...
>
> Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:
>
> > ISO 639-5 was published on the 15/05/2008
>
> I hadn't realized that.  More to the point, I hadn't realized
> we had delayed quite that long.  ISO 639-5 was always one of
> those things that was regarded as being outside the scope of
> LTRU II since our deadlines were long before the scheduled
> publication of 639-5.
>
> Should we consider incorporating the 639-5 code elements into
> draft-4645bis?  There would be no architectural change to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Ewell | 1 Jun 03:28
Favicon

Re: Minor change to 639-3 lists

I wrote:

> I'll add this to the next draft-4645bis, along with the new 
> alternative name for 'zxx' which is already in the current Registry 
> (but still not in 639-3).

I should point out that "the next draft-4645bis" is very much on hold, 
until the group decides what to do about extlangs.

--
Doug Ewell  *  Arvada, 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  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply | 0 comments |
headers
Doug Ewell | 1 Jun 07:28
Favicon

Re: ISO 639 language code addition rules...

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> BSI have a copy of ISO 639-5 and I am pretty sure that, whilst the 
> standard itself is not available freely, the code list is.
>
> I can enquire if you like?

That would be great.  Can you also check whether it is acceptable to 
"publish" the codes on this mailing list (which would have the effect of 
publishing them on a Web archive)?  It might be helpful for list members 
to see exactly what subtags would be added.

Thanks,

--
Doug Ewell  *  Arvada, 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  ˆ

_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www.ietf.org/mailman/listinfo/ltru
Permalink | Reply | 0 comments |
headers
John Cowan | 1 Jun 07:36

Re: ISO 639 language code addition rules...

Doug Ewell scripsit:

> I thought 639-2 was supposed to be a subset of (the union of 639-3 plus 
> 639-5) going forward,

Correct.

> at least when 639-5 is published (which I don't believe has happened
> yet).

It has!  It went to 60.60 (published) state on May 15, and is now
available for the usual exorbitant price (CHF 102, about USD 98 or
EUR 63).

> I just want to make sure that we don't register the 639-2/3 code *'fob' 
> for Foobazian, and then 639-1 assigns *'fb', and the only difference was 
> coordination of announcements between the RAs.

No more 639-1 assignments will happen, except in the unlikely case that a
language is registered simultaneously in -1, -2, and -3 (which would imply
both that it is *not* now known to Ethnologue, and that it is important
enough to justify a 2-letter code, quod absurdum est.

So we can pretty much rule out new -1 code elements, and likewise new
-2 elements except perhaps for a new macrolanguage (but I doubt it).

--

-- 
As you read this, I don't want you to feel      John Cowan
sorry for me, because, I believe everyone       cowan <at> ccil.org
will die someday.                               http://www.ccil.org/~cowan
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Constable | 1 Jun 08:56
Picon
Favicon

Re: ISO 639 language code addition rules...

> From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On Behalf Of
> Doug Ewell

> My only concern is that the words "simultaneously" and "together" might
> have a creative meaning when applied to two different RAs using their
> own public reporting mechanisms and philosophies.  Sometimes one RA
> makes a change that isn't reflected in the other 639 part for some time.

Unfortunately true; but on the other hand, the JAC secretary usually sends out mail notifications when
changes are made, and I believe this list and IETF-languages are among those audiences to whom those mails
are sent.

> > I've suggested before that we could decide that we will never again
> > register something from 639-1. That would eliminate these concerns
> > entirely.
>
> It might be better if ISO 639-1 instituted such a rule, instead of us.

Neither the JAC nor the 639-1/RA can institute a rule about practice for maintaining the LSTR. The JAC has a
guideline not to add an alpha-2 in case an alpha-3 previously existed, though that is not a binding rule.
The JAC has also informally agreed to adopt a very high bar for alpha-2 additions, making new alpha-2
additions less likely.

Peter
Permalink | Reply | 1 comment |
headers
John Cowan | 1 Jun 09:02

Re: ISO 639 language code addition rules...

Peter Constable scripsit:

> Neither the JAC nor the 639-1/RA can institute a rule about practice
> for maintaining the LSTR. The JAC has a guideline not to add an alpha-2
> in case an alpha-3 previously existed, though that is not a binding
> rule. The JAC has also informally agreed to adopt a very high bar for
> alpha-2 additions, making new alpha-2 additions less likely.

Given that, I think we should cease to add further alpha-2 codes.

--

-- 
John Cowan              cowan <at> ccil.org          http://www.ccil.org/~cowan
Any day you get all five woodpeckers is a good day.  --Elliotte Rusty Harold
Permalink | Reply | 0 comments |
headers
John Cowan | 1 Jun 09:05

Re: ISO 639 language code addition rules...

Phillips, Addison scripsit:

> <list>
>    <t>Codes assigned by ISO 639-1 that do not conflict with existing
>    two-letter primary language subtags and which have no corresponding
>    three-letter primary defined in the registry are entered into the
>    IANA registry as new records of type 'language'. Note that languages
>    given an ISO 639-1 code cannot be extended language subtags, even
>    if enclosed by a macrolanguage.</t>

As I just posted, I think this should say "no more 639-1 codes as of Date C."

>    <t>Codes assigned by ISO 639-3 that do not conflict with existing
>    three-letter primary language subtags and which do not have ISO
>    639-1 codes assigned are entered into the IANA registry as new
>    records of type 'language' or 'extlang'. Codes that have a defined
>    "macrolanguage" mapping at the time of their registration MUST
>    be entered into the registry as records of type 'extlang' with a
>    'Prefix' field containing the appropriate prefix tag. They MUST
>    also include a "Macrolanguage" field in their record. All other
>    records are of type 'language'.</t>

Presumably "a macrolanguage mapping to "zho" or "sgn".

>    <t>Any other codes assigned by ISO 639-2 that do not conflict with
>    existing three-letter primary or extended language subtags and which
>    do not have ISO 639-1 two-letter codes assigned are entered into the
>    IANA registry as new records of type 'language'. Subtags assigned
>    according to this rule will mostly be language collections.</t>
(Continue reading)

Permalink | Reply | 9 comments |

Gmane