headers
ISO639-3 | 24 May 2013 21:42
Favicon

Addendum to 2012 ISO 639-3 changes


Dear Ietf Community,

Several of the outstanding requests for the 2012 change cycle have been resolved. Please visit the
ISO639-3 website for the Addendum to the 2012 Summary report listing the accepted or rejected changes. If
you use the download tables, the new revised tables are also available.

Thank you for your interest in the ISO 639-3 standard.

Melinda Lyons
ISO 639-3 RA
SIL International
7500 W. Camp Wisdom Rd.
Dallas, TX 75236
Permalink | Reply | 0 comments |
headers
Martin J. Dürst | 3 Apr 2013 02:56
Picon
Gravatar

Re: [webfinger] Default language (Was: Last Call: <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standard

On 2013/04/03 2:39, Mike Jones wrote:
> I'd switch to using "und".  WebFinger has a normative dependency on RFC 5646 (Tags for Identifying
Languages), which specifies the use of "und".  We have only an informative dependency upon RFC 6415 (Web
Host Metadata) .  And I agree that the use of "default" in RFC 6415 is a spec defect that we should separately
try to have corrected, either through the errata process or by publishing an updated spec.  We certainly
shouldn't emulate the spec defect.
>
> But correcting 6415 shouldn't hold up WebFinger, which should just use the convention in the spec that we
normatively reference.

This makes a lot of sense indeed.   Regards,   Martin.

>
> 				-- Mike
>
> -----Original Message-----
> From: webfinger-bounces <at> ietf.org [mailto:webfinger-bounces <at> ietf.org] On Behalf Of Paul E. Jones
> Sent: Tuesday, April 02, 2013 10:20 AM
> To: '"Martin J. Dürst"'; 'Stephane Bortzmeyer'
> Cc: webfinger <at> ietf.org; ietf-languages <at> alvestrand.no
> Subject: Re: [webfinger] Default language (Was: Last Call:<draft-ietf-appsawg-webfinger-10.txt> 
(WebFinger) to Proposed Standard
>
> Martin,
>
>>> In this case, it seems the working group made a wrong choice, but
>>> deliberately.
>>
>> I think it's going a bit too far to say that there was a deliberate
>> choice.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin J. Dürst | 2 Apr 2013 03:59
Picon
Gravatar

Re: [webfinger] Default language (Was: Last Call: <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standard

Hello Paul, others,

ntohuntheonth

On 2013/03/21 11:55, Paul E. Jones wrote:
> Stephanie,
>
>>> The "titles" object comprises zero or more name/value pairs whose name
>>> is a language tag or the string "default". [...] If the language is
>>> unknown or unspecified, then the name is "default".
>>
>> Why inventing a special value when the language tag registry already has
>> a specific value, "und"? To quote RFC 5646:
>>
>>> The 'und' (Undetermined) primary language subtag identifies linguistic
>>> content whose language is not determined.  This subtag SHOULD NOT be
>>> used unless a language tag is required and language information is not
>>> available or cannot be determined.
>
> This is historical.  The JRD syntax was first defined in RFC 6415 and that
> document said to use "default" when the corresponding XML document did not
> specify the xml:lang attribute.

It would be very good if the people involved could come up with a way to 
get rid of this historic oversight, the earlier, the better. Maybe this 
should actually be an erratum to RFC 6415? It should have been caught 
before that RFC was published, but unfortunately, such oversights happen.

Regards,   Martin.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin J. Dürst | 18 Mar 2013 03:28
Picon
Gravatar

Re: [webfinger] Language tag too specific (Was: Last Call: <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standard

On 2013/03/16 1:02, Mike Jones wrote:
> I'll raise a related issue - the case of characters used in language tag values.  Given that "en-us" and
"en-US" are different JSON values, it's important for people to spell language tag values in a consistent way.

Hello Mike,

Language tags are case-insensitive, so whether it says "en-US" or 
"en-us" (or any other combination of caps and lower case), the final 
result (that those people who prefer English as used in the US get to 
see the title version that's labeled "en-US" or "en-us") should be the same.

Of course, it might be that there are two separate titles with match 
case-insensitively. Here's an example:

"titles" :
             {
                 "en-us" : "The Magical Theater of Bob",
                 "en-gb" : "The magical theatre of Bob",
                 "en-GB" : "The Magical Theatre of Bob",
                 "fr" : "Le Théâtre Magique de Bob"
             }

While the author might have intended for the user to select the lower 
case or the titlecase version of the title, that just won't work. So I 
guess we should call out this case and prohibit it for producers.

But I don't see the reason to specify that everybody has to use "en-GB"; 
using "en-gb" only should just do as well.

Regards,   Martin.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Doug Ewell | 8 Mar 2013 17:48
Favicon

Macrolanguages (was: Re: BCP 47)

Phillips, Addison <addison at lab126 dot com> wrote:

>> Why doesn't Swabian have German as a macrolanguage?
>
> The short answer is: because ISO 639-3 says so (or, rather, fails to
> say so).

This is the answer that Benson needed.

> But these generally do not convey additional utility for the uses to
> which language tags are mostly applied and the additional complexity
> of macrolanguages is something that generally this group tries to
> avoid.

This is NOT the answer that Benson needed.

This group isn't empowered to avoid the additional complexity of
macrolanguages. BCP 47 has a mechanism in place to deal with them. The
mechanism was an uneasy compromise and it does add complexity to the
tagging model, but when 639-3/RA decides to assign a macrolanguage,
that's pretty much that; the mechanism kicks in.

To say that the group tries to avoid the complexity of macrolanguages
implies that we can somehow override the RA's decision. I don't think we
want to perpetuate that belief among users.

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org |  <at> DougEwell ­
(Continue reading)

Permalink | Reply | 10 comments |
headers
Benson Limketkai | 8 Mar 2013 00:46
Picon

BCP 47

Hi,

Why doesn't Swabian have German as a macrolanguage?
See: http://en.wikipedia.org/wiki/Swabian_German %% Type: language Subtag: swg Description: Swabian Added: 2009-07-29 
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 1 comment |
headers
Doug Ewell | 22 Feb 2013 17:09
Favicon

Re: draft-gellens-negotiating-human-language-01

Draft-gellens-negotiating-human-language-01, "Negotiating Human Language
Using SDP", says this about the source of values for the SDP 'lang'
attribute:

> The "lang" attribute value must be a single [RFC3066] language tag
> in US-ASCII [RFC3066].

Although this wording is quoted from RFC 4566, the subsequent section
proposing a new 'humintlang' attribute uses the same wording.

Any new format or protocol that employs language tags should apply BCP
47 (RFC 5646), not RFC 3066, which was obsoleted in 2006. BCP 47 allows
the use of more than 7300 additional language subtags derived from ISO
639-3, as well as script subtags based on ISO 15924 and variant subtags,
none of which are permitted in a generative manner by RFC 3066.

The draft says, "The attribute value should be a language tag from the
IANA registry [IANA-lang-tags]", referencing
www.iana.org/assignments/language-subtag-registry, but RFC 3066 does not
use this registry; it references the core ISO standards directly, which
reduces stability, and it uses its own IANA registry (also obsolete)
only for a few dozen predefined variant tags, many of which are
deprecated in BCP 47. 

RFC 4647, also part of BCP 47, provides guidelines for matching language
tags, and may benefit the SDP negotiation process described in the
draft.

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org |  <at> DougEwell ­

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 2 comments |
headers
ISO639-3 | 13 Feb 2013 23:41
Favicon

New chair of ISO 639 Joint Advisory Committee


Dear Ietf Community,

Christian Galinsky has agreed to resume his previous role as chair of the Joint Advisory Committee
overseeing ISO 639. He is the Registrar for ISO 639-1 at Infoterm.

Please welcome him back to this role.

Sincerely,

Melinda Lyons
Secretary
Joint Advisory Committee
ISO 639
Permalink | Reply | 0 comments |
headers
Doug Ewell | 13 Feb 2013 05:12
Favicon

Proposed record and registration form for "State of Palestine"

LANGUAGE SUBTAG MODIFICATION
File-Date: 2013-xx-xx
%%
Type: region
Subtag: PS
Description: State of Palestine
Added: 2005-10-16
%%

---

LANGUAGE SUBTAG REGISTRATION FORM

1. Name of requester: Doug Ewell
2. E-mail address of requester: doug at ewellic.org
3. Record Requested:

   Type: region
   Subtag: PS
   Description: State of Palestine

4. Intended meaning of the subtag:

5. Reference to published description of the language (book or article):

6. Any other relevant information:

   This registration tracks a change made to ISO 3166-1 effective
   2013-02-06, changing the English short name from "Palestinian
   Territory, Occupied" to "Palestine, State of".

   For more information, refer to ISO 3166-1 Newsletter VI-14, "Name
   change for State of Palestine and other minor corrections", at
   http://www.iso.org/iso/iso_3166-1_newsletter_vi-14_name_change_state_of_palestine.pdf 
.

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org |  <at> DougEwell ­ 

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 0 comments |
headers
ISO639-3 | 25 Jan 2013 21:08
Favicon

Greek languages remaining on ISO 639-3 change list

I have consulted with the ISO 639-2 registrar, and we have agreed on a way to handle the Greek requests. Our
consultation happened after the closure of requests for 2012, so will be handled in the 2013 cycle. Vedic
Sanskrit will also be handled in this way.

Melinda Lyons
ISO 639-3 RA
SIL International
7500 W. Camp Wisdom Rd.
Dallas, TX 75236

Message: 2
 Date: Thu, 24 Jan 2013 16:02:22 -0500
 From: John Cowan <cowan <at> mercury.ccil.org>
 To: ISO639-3 <iso639-3 <at> sil.org>
 Cc: ietf-languages <at> alvestrand.no
 Subject: Re: ISO 639-3 changes posted
 Message-ID: <20130124210222.GD14317 <at> mercury.ccil.org>
 Content-Type: text/plain; charset=us-ascii

ISO639-3 scripsit:

> I have just posted the new tables to the ISO 639-3 webpage
 > (www.sil.org/iso639-3/). There is also a summary of changes for those
 > who need it.

Thanks.

Are the three outstanding Greek requests (2006-084, 2009-060, 2009-081)
 ever going to be processed?  They seem to remain perpetually in the
 "Current" section.

--
 One Word to write them all,             John Cowan <cowan <at> ccil.org>
   One Access to find them,              http://www.ccil.org/~cowan
 One Excel to count them all,
   And thus to Windows bind them.                --Mike Champion
Permalink | Reply | 1 comment |
headers
Doug Ewell | 24 Jan 2013 22:56
Favicon

ISO 639-3 changes announced

ISO 639-3/RA has announced their annual batch of changes, and posted new
data files:

http://www.sil.org/iso639-3/default.asp
http://www.sil.org/iso639-3/download.asp

The announcement says 136 change requests were approved, which probably
means there will be roughly (but not necessarily exactly) 136 changes to
the Language Subtag Registry.

I will be going through these in the coming weeks and preparing the
necessary forms. If anyone wants to look at the new 639-3 files and has
a question about how the Registry will handle this or that change,
please feel free to ask.

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org |  <at> DougEwell ­

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Permalink | Reply | 0 comments |

Gmane