Doug Ewell | 1 Mar 2010 03:44
Favicon

Saint Helena, Ascension and Tristan da Cunha

ISO 3166-1 Newsletter VI-7, dated 2010-02-22 (but not posted until a few 
days later), announces a name change for code element SH from "Saint 
Helena" to "Saint Helena, Ascension and Tristan da Cunha."  This doesn't 
represent as much of a scope increase as it might seem, since the 
Remarks entry for SH previously stated that the code element "included" 
Ascension Island and the Tristan da Cunha Archipelago.

Normally for us, this simple ISO 3166/MA action would trigger a simple 
change to the Description field for subtag SH.  However, because the 
LTRU WG decided to add the ISO 3166-1 "exceptionally reserved" code 
elements to the Registry -- including AC for Ascension Island and TA for 
Tristan da Cunha -- we have a decision to make.  In addition to making 
the name change for SH, do we also deprecate AC and TA and give each a 
Preferred-Value of SH?

According to RFC 5646, "Usually, the addition of a 'Deprecated' field is 
due to the action of one of the standards bodies, such as ISO 3166, 
withdrawing a code."  Obviously the MA would not have "withdrawn" these 
two code elements, since they were not assigned, only reserved.  It is 
we (LTRU) who chose to put these reserved code elements on an equal 
footing with normal assigned code elements.

My opinion should be clear -- deprecate AC and TA -- but I'll wait to 
hear from others before posting any forms to the list.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages  <at>  http://is.gd/2kf0s ­ 

_______________________________________________
(Continue reading)

Randy Presuhn | 1 Mar 2010 04:18
Picon

Re: Saint Helena, Ascension and Tristan da Cunha

Hi -

> From: "Doug Ewell" <doug <at> ewellic.org>
> To: <ietf-languages <at> iana.org>
> Sent: Sunday, February 28, 2010 6:44 PM
> Subject: Saint Helena, Ascension and Tristan da Cunha 
>
> ISO 3166-1 Newsletter VI-7, dated 2010-02-22 (but not posted until a few 
> days later), announces a name change for code element SH from "Saint 
> Helena" to "Saint Helena, Ascension and Tristan da Cunha."  This doesn't 
> represent as much of a scope increase as it might seem, since the 
> Remarks entry for SH previously stated that the code element "included" 
> Ascension Island and the Tristan da Cunha Archipelago.
> 
> Normally for us, this simple ISO 3166/MA action would trigger a simple 
> change to the Description field for subtag SH.  However, because the 
> LTRU WG decided to add the ISO 3166-1 "exceptionally reserved" code 
> elements to the Registry -- including AC for Ascension Island and TA for 
> Tristan da Cunha -- we have a decision to make.  In addition to making 
> the name change for SH, do we also deprecate AC and TA and give each a 
> Preferred-Value of SH?
> 
> According to RFC 5646, "Usually, the addition of a 'Deprecated' field is 
> due to the action of one of the standards bodies, such as ISO 3166, 
> withdrawing a code."  Obviously the MA would not have "withdrawn" these 
> two code elements, since they were not assigned, only reserved.  It is 
> we (LTRU) who chose to put these reserved code elements on an equal 
> footing with normal assigned code elements.
> 
> My opinion should be clear -- deprecate AC and TA -- but I'll wait to 
(Continue reading)

John Cowan | 1 Mar 2010 06:50

Re: Saint Helena, Ascension and Tristan da Cunha

Randy Presuhn scripsit:

> I think there's no need to deprecate AC or TA.  

I agree with Randy on all points.

--

-- 
Verbogeny is one of the pleasurettes    John Cowan <cowan <at> ccil.org>
of a creatific thinkerizer.             http://www.ccil.org/~cowan
   --Peter da Silva
Phillips, Addison | 1 Mar 2010 07:37
Picon
Favicon

RE: Saint Helena, Ascension and Tristan da Cunha

> John Cowan scripsit:
> 
> > I think there's no need to deprecate AC or TA.
> 
> I agree with Randy on all points.
> 

I concur.

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.
Michael Everson | 1 Mar 2010 09:35
Favicon
Gravatar

Re: Saint Helena, Ascension and Tristan da Cunha

On 1 Mar 2010, at 02:44, Doug Ewell wrote:

> Normally for us, this simple ISO 3166/MA action would trigger a simple  change to the Description field for
subtag SH.

Right. That's it. 

Michael Everson * http://www.evertype.com/
Doug Ewell | 1 Mar 2010 15:13
Favicon

Re: Saint Helena, Ascension and Tristan da Cunha

Lots of people agreed:

> I think there's no need to deprecate AC or TA.

Very good.  Below are a proposed record and registration form to make 
the indicated change to SH.

---

LANGUAGE SUBTAG MODIFICATION
File-Date: 2010-03-15
%%
Type: region
Subtag: SH
Description: Saint Helena, Ascension and Tristan da Cunha
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: SH
   Description: Saint Helena, Ascension and Tristan da Cunha

(Continue reading)

John Cowan | 3 Mar 2010 17:25

Schedule for ISO 639-3 changes?

Are we in the waiting period now?  When do we submit to IANA?  I'm not
asking out of randomness, but for real reasons.

--

-- 
But the next day there came no dawn,            John Cowan
and the Grey Company passed on into the         cowan <at> ccil.org
darkness of the Storm of Mordor and were        http://www.ccil.org/~cowan
lost to mortal sight; but the Dead
followed them.          --"The Passing of the Grey Company"
Doug Ewell | 4 Mar 2010 03:18
Favicon

Re: Schedule for ISO 639-3 changes?

John Cowan <cowan at ccil dot org> wrote:

> Are we in the waiting period now?  When do we submit to IANA?  I'm not 
> asking out of randomness, but for real reasons.

For the ISO 639-3-based changes, we are in the review period until March 
11.  This was previously March 5, but the addition of a Macrolanguage 
field to 'hmz' moved it out, as I wrote on February 25.

For Saint Helena and Friends, we are in the review period until March 
15.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages  <at>  http://is.gd/2kf0s ­ 

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Doug Ewell | 4 Mar 2010 03:25
Favicon

Re: Schedule for ISO 639-3 changes?

John Cowan <cowan at ccil dot org> wrote:

> Are we in the waiting period now?

I would add that this should be viewed as a true review period, where 
careful and diligent list members (besides Kent) check over the posted 
records and registration forms and report any errors.  It's not intended 
to be a cooling-off period, in the sense of someone waiting to purchase 
a handgun in parts of the United States.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages  <at>  http://is.gd/2kf0s ­

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages
Alexandre Lecoq | 7 Mar 2010 13:45
Picon

Correction for pinyin


Name : Alexandre Lecoq
Email: alexandre.lecoq <at> live.fr

Related entries:

Type: language
Subtag: pny
Description: Pinyin
Added: 2009-07-29

Type: variant
Subtag: pinyin
Description: Pinyin romanization
Added: 2008-10-14
Prefix: zh-Latn
Prefix: bo-Latn

Problem description:

There is no such thing as a Pinyin language. Pinyin (pinyin) is a variant of Latin script (Latn).
It is a phonetic transcription using latin alphabet, and is only defined for Mandarin (zh-cmn, cmn) if it's a short for hanyu pinyin, otherwise it's nothing but something that means romanization in this context.

Therefore pny can't be a language. It could be an alias for Latn-pinyin in the best case.
And since hanyu pinyin is defined for zh-cmn, pinyin prefix should be zh-cmn-Latn or cmn-Latn and not bo-Latn.

It should be remembered that "pinyin" means something like "phonetics" or "spelling sounds". "Pinyin" is generally the short for Hanyu Pinyin (romanization for zh-cmn), but meaning wise: it is pretty generic, for example there is also Tibetan Pinyin, Tongyong Pinyin, etc... They are all romanizations, but they are different ones, and possibly for different languages.

As a conclusion, pny should be deprecated, and pinyin should probaly be clarified sooner or later.

--
Alexandre Lecoq



Acheter en ligne en toute sécurité ? Internet Explorer 8 vous protège gratuitement !
_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages

Gmane