Subject: [Ltru] Re: Registry deltas

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Oct 2006 22:25:32 -0700

Here's a list of the changes to get from the current (2006-09-29) 
Registry to the one presented in draft-4645bis-00.  This list explicitly 
excludes the 7,200 new primary and extended language subtags, and 
includes only changes to existing subtags.

This is displayed as a list, rather than a true diff file, because I 
didn't think it would be very kind to insert a reference to "Line 3459" 
and expect that to make sense to anyone.

Please review this, or at least try to stay awake through it, and let 
the group and me know what you think of the scope of the changes.  I'm 
particularly wondering about the addition of "inverted"  language names 
from ISO 639-3.  These were taken to be The Official Name on the basis 
of being listed in [iso-dis-639-3_20060421], but apparently both the 
inverted and non-inverted forms are part of the standard.  So it may not 
be necessary to add "Newari, Classical" where we already have "Classical 
Newari", simply to reflect the official ISO 639-3 name.  This would be 
an easy rule to add: don't add "B, A" if a Description field of the form 
"A B" already exists.

-----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<-----
Language subtag cu
 Add: Description: Slavic, Church

Language subtag frr
 Add: Description: Frisian, Northern

Language subtag fy
 Add: Description: Frisian, Western

Language subtag gd
 Add: Description: Gaelic (Scots)

Language subtag ii
 Add: Description: Yi, Sichuan

Language subtag mh
 Add: Description: Marshall

Language subtag ms
 Add: Description: Malay (macrolanguage)

Language subtag sw
 Add: Description: Swahili (macrolanguage)

Language subtag ain
 Add: Description: Ainu (Japan)

Language subatg alt
 Add: Description: Altai, Southern

Language subtag bas
 Add: Description: Basa (Cameroon)

Language subtag bem
 Add: Description: Bemba (Zambia)

Language subtag chm
 Add: Description: Mari (Russia)

Language subtag doi
 Add: Description: Dogri (macrolanguage)

Language subtag dsb
 Add: Description: Sorbian, Lower

Language subtag fan
 Add: Description: Fang (Equatorial Guinea)

Language subtag frs
 Add: Description: Frisian, Eastern

Language subtag gba
 Add: ‏Description: Gbaya (Central African Republic)

Language subtag gsw
 Add: Description: Schwyzerd&#xFC;tsch

Language subtag hsb
 Add: Description: Sorbian, Upper

Language subtag kam
 Add: Description: Kamba (Kenya)

Language subtag kok
 Add: Description: Konkani (macrolanguage)

Language subtag men
 Add: Description: Mende (Sierra Leone)

Language subtag nso
 Add: Description: Sotho, Northern

Language subtag nwc
 Add: Description: Newari, Classical

Language subtag rup
 Add: Description: Romanian, Macedo

Language subtag sam
 Add: Description: Aramaic, Samaritan

Language subtag srn
 Add: Description: Sranan

Language subtag war
 Add: Description: Waray (Philippines)

Region subtag CS
 Add: Deprecated: 2006-10-01

Region subtag ME
 Add: Type: region
      Subtag: ME
      Description: Montenegro
      Added: 2006-10-01

Region subtag RS
 Add: Type: region
      Subtag: RS
      Description: Serbia
      Added: 2006-10-01

Grandfathered tag i-ami
 Add: Preferred-Value: ami
      Deprecated: 2007-01-01
      Comments: replaced by ISO code ami

Grandfathered tag i-bnn
 Add: Preferred-Value: bnn
      Deprecated: 2007-01-01
      Comments: replaced by ISO code bnn

Grandfathered tag i-pwn
 Add: Preferred-Value: pwn
      Deprecated: 2007-01-01
      Comments: replaced by ISO code pwn

Grandfathered tag i-tao
 Add: Preferred-Value: tao
      Deprecated: 2007-01-01
      Comments: replaced by ISO code tao

Grandfathered tag i-tay
 Add: Preferred-Value: tay
      Deprecated: 2007-01-01
      Comments: replaced by ISO code tay

Grandfathered tag i-tsu
 Add: Preferred-Value: tsu
      Deprecated: 2007-01-01
      Comments: replaced by ISO code tsu

Grandfathered tag sgn-CH-de
 Add: Preferred-Value: sgn-sgg
      Deprecated: 2007-01-01
      Comments: replaced by ISO code sgg

Grandfathered tag zh-cmn
 Reclassify as redundant

Grandfathered tag zh-cmn-Hans
 Reclassify as redundant

Grandfathered tag zh-cmn-Hant
 Reclassify as redundant

Grandfathered tag zh-gan
 Reclassify as redundant

Grandfathered tag zh-guoyu
 Add: Comments: replaced by ISO code cmn

Grandfathered tag zh-hakka
 Add: Preferred-Value: zh-hak
      Deprecated: 2007-01-01
      Comments: replaced by ISO code hak

Grandfathered tag zh-min
 Add: Deprecated: 2007-01-01

Grandfathered tag zh-min-nan
 Add: Preferred-Value: zh-nan
      Deprecated: 2007-01-01
      Comments: replaced by ISO code nan

Grandfathered tag zh-wuu
 Reclassify as redundant

Grandfathered tag zh-xiang
 Add: Preferred-Value: zh-hsn
      Deprecated: 2007-01-01
      Comments: replaced by ISO code hsn

Grandfathered tag zh-yue
 Reclassify as redundant

Redundant tag sgn-BR
 Add: Preferred-Value: sgn-bzs
      Deprecated: 2007-01-01
      Comments: replaced by ISO code bzs

Redundant tag sgn-CO
 Add: Preferred-Value: sgn-csn
      Deprecated: 2007-01-01
      Comments: replaced by ISO code csn

Redundant tag sgn-DE
 Add: Preferred-Value: sgn-gsg
      Deprecated: 2007-01-01
      Comments: replaced by ISO code gsg

Redundant tag sgn-DK
 Add: Preferred-Value: sgn-dsl
      Deprecated: 2007-01-01
      Comments: replaced by ISO code dsl

Redundant tag sgn-ES
 Add: Preferred-Value: sgn-ssp
      Deprecated: 2007-01-01
      Comments: replaced by ISO code ssp

Redundant tag sgn-FR
 Add: Preferred-Value: sgn-fsl
      Deprecated: 2007-01-01
      Comments: replaced by ISO code fsl

Redundant tag sgn-GB
 Add: Preferred-Value: sgn-bfi
      Deprecated: 2007-01-01
      Comments: replaced by ISO code bfi

Redundant tag sgn-GR
 Add: Preferred-Value: sgn-gss
      Deprecated: 2007-01-01
      Comments: replaced by ISO code gss

Redundant tag sgn-IE
 Add: Preferred-Value: sgn-isg
      Deprecated: 2007-01-01
      Comments: replaced by ISO code isg

Redundant tag sgn-IT
 Add: Preferred-Value: sgn-ise
      Deprecated: 2007-01-01
      Comments: replaced by ISO code ise

Redundant tag sgn-JP
 Add: Preferred-Value: sgn-jsl
      Deprecated: 2007-01-01
      Comments: replaced by ISO code jsl

Redundant tag sgn-MX
 Add: Preferred-Value: sgn-mfs
      Deprecated: 2007-01-01
      Comments: replaced by ISO code mfs

Redundant tag sgn-NI
 Add: Preferred-Value: sgn-ncs
      Deprecated: 2007-01-01
      Comments: replaced by ISO code ncs

Redundant tag sgn-NL
 Add: Preferred-Value: sgn-dse
      Deprecated: 2007-01-01
      Comments: replaced by ISO code dse

Redundant tag sgn-NO
 Add: Preferred-Value: sgn-nsl
      Deprecated: 2007-01-01
      Comments: replaced by ISO code nsl

Redundant tag sgn-PT
 Add: Preferred-Value: sgn-psr
      Deprecated: 2007-01-01
      Comments: replaced by ISO code psr

Redundant tag sgn-SE
 Add: Preferred-Value: sgn-swl
      Deprecated: 2007-01-01
      Comments: replaced by ISO code swl

Redundant tag sgn-US
 Add: Preferred-Value: sgn-ase
      Deprecated: 2007-01-01
      Comments: replaced by ISO code ase

Redundant tag sgn-ZA
 Add: Preferred-Value: sgn-sfs
      Deprecated: 2007-01-01
      Comments: replaced by ISO code sfs

Redundant tag yi-latn
 Change to: Tag: yi-Latn
-----8<-----cut here-----8<-----cut here-----8<-----cut here-----8<-----

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 Oct 2006 14:01:46 +0200

Doug Ewell wrote:

> Please review this, or at least try to stay awake through it

Okay, my first impression is "nothing special or unexpected" -
there's no A -> C shortcut for A -> B -> C yet, because that's
not yet in the rules (4646bis), correct ?

> it may not be necessary to add "Newari, Classical" where we
> already have "Classical Newari"

Not necessary, but maybe desirable for alphabetically sorted
descriptions (?).  I'm not hot about it.

For the XML fans: http://xyzzy.webhop.info/home/ltru/index.html

The script still won't work for collisions of language
and variant subtags with 5..8 letters (of course there's
no such collision without any non-ISO language subtag).

The <preferred> as child of <deprecated> idea didn't work
well with Debbie's application, I've replaced it by this:

(deprecated | (preferred, deprecated))?

Multi-descriptions (and in theory multi-comments) also
didn't work as expected, replaced by more black magic:

<!ELEMENT description  (#PCDATA | alt)*>
<!ELEMENT comment      (#PCDATA | alt)*>
<!ELEMENT alt          EMPTY>    <!-- separator -->

Same idea as <br />, certainly not pretty, but "works"
is more important.

Frank

---

From: John Cowan <[email-masked]>
Date: Mon, 2 Oct 2006 11:39:15 -0400

Doug Ewell scripsit:

> I'm particularly wondering about the addition of "inverted"  language
> names from ISO 639-3.  These were taken to be The Official Name on the
> basis of being listed in [iso-dis-639-3_20060421], but apparently both
> the inverted and non-inverted forms are part of the standard.  So it
> may not be necessary to add "Newari, Classical" where we already have
> "Classical Newari", simply to reflect the official ISO 639-3 name.

On reflection, though, I'm in favor of adding these inverted names,
simply because they provide useful information, namely which names can
be inverted and where to invert them.

I'd be more in favor of merging descriptions that are a prefix of other
descriptions:  if we have both "Foo (Bar)" and "Foo", to eliminate the
latter in favor of the former.  I don't feel strongly about this, however.

>      Comments: replaced by ISO code sgg

These "replaced by" comments existed in the RFC 3066 registry as a kind
of crude Preferred-Value, and we now have a better mechanism.  I can
easily see someone looking at this entry and not knowing whether to use
"sgn-sgg" or "sgg".

-- 
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part            http://ccil.org/~cowan
that cooks with olive oil, and the part that            [email-masked]
cooks with butter. -- David Chessler

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 2 Oct 2006 10:22:41 -0700

Overall, I think inverted names are a bad idea. They are rather
anglocentric, and we find that translators often do the wrong thing with
them. They are also hugely inconsistent in the current registry.

I think they are tolerable if (a) every single instance of a comma indicates
an inverted name, and (b) all names are consistently inverted. Because of
(a) one could programmatically fix the names to the correct value.

But we certainly don't follow these now:

(a) is broken in

Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese

which is not: Fuzhou, Hokkien, Amoy, or Taiwanese Min

Natisone dialect, Nadiza dialect
which is not: Nadiza dialect Natisone dialect

Resian, Resianic, Rezijan
Yiddish, in Latin script
...

and probably the following:

Description: English, Oxford English Dictionary spelling
That would make the normal form: "Oxford English Dictionary spelling
English", which is very odd.

German, traditional orthography
German, orthography of 1996
German, Austrian variant, traditional orthography
German, Austrian variant, orthography of 1996
German, Swiss variant, traditional orthography
German, Swiss variant, orthography of 1996
German, German variant, traditional orthography
German, German variant, orthography of 1996

(b) is broken in

Description: Northern Sotho
but
Description: Sotho, Southern

and many others.

Such inconsistency completely defeats the purpose. Plus, we are hardly
consistent elsewhere:

Description: Church Slavic
Description: Old Slavonic
Description: Church Slavonic
Description: Old Bulgarian
Description: Old Church Slavonic

but not

Description: Slavic, Church
Description: Slavonic, Old
Description: Slavonic, Church
Description: Bulgarian, Old
Description: Church Slavonic, Old
Description: Slavonic, Old Church

(BTW, surely we can add a few dozen more combinations, can't we --
isn't this also Old Russian, Old Ukranian,.... ;-)

At the end of this document are the multi-word descriptions where the first
word doesn't end with a , and the second doesn't start with a "(", and
sorted by the second column. This was a very quick and dirty parse, but
shows that many of these would be candidates for inversion, and thus are
inconsistent with the ones that have been inverted. But it is also clear
that in many cases it is a matter of taste as to whether a name is inverted
or not -- and the last thing we need are arguments in the language group as
to whether something should be inverted or not; and with 7,000 entries, I
see lifetime work for JFC.

If people really think they are necessary, however, it would be much better
to have more structure so that this was predictable. Eg.

Inverted-Description:  English, Old (ca. 450-1100)
Inverted-Description: Old Italic (Etruscan, Oscan, etc.)

where we make it explicit that the structure is:

inverted-description := core-name ", " inverted-prefix ["(" comment ")"]

Mark

Linear    A
Eastern    Africa
Middle    Africa
Northern    Africa
South    Africa
Southern    Africa
Western    Africa
Central    African    Republic
South    African    Sign    Language
Southern    Altai
Central    America
Latin    America    and    the    Caribbean
Northern    America
South    America
Central    American    Indian    (Other)
Latin    American    Spanish
North    American    Indian
South    American    Indian    (Other)
Antigua    and    Barbuda
Australia    and    New    Zealand
Bosnia    and    Herzegovina
Creoles    and    pidgins,    English-based    (Other)
Creoles    and    pidgins,    French-based    (Other)
Creoles    and    pidgins,    Portuguese-based    (Other)
Creoles    and    pidgins    (Other)
Serbia    and    Montenegro
Svalbard    and    Jan    Mayen
Trinidad    and    Tobago
Turks    and    Caicos    Islands
Wallis    and    Futuna
Netherlands    Antilles
Libyan    Arab    Jamahiriya
Syrian    Arab    Republic
United    Arab    Emirates
Saudi    Arabia
Samaritan    Aramaic
Eastern    Armenian
Western    Armenian
Central    Asia
Eastern    Asia
South-Eastern    Asia
Southern    Asia
Western    Asia
Linear    B
Nepal    Bhasa
Norwegian    Bokm&#xE5;l
Norwegian    Bokmal
Old    Bulgarian
New    Caledonia
Unified    Canadian    Aboriginal    Syllabics
Ol    Chiki    (Ol    Cemet',    Ol,    Santali)
Macao    Chinese    in    simplified    script
Macao    Chinese    in    traditional    script
Mandarin    Chinese
Mandarin    Chinese    (Simplified)
Mandarin    Chinese    (Traditional)
simplified    Chinese
Singapore    Chinese    in    simplified    script
Singapore    Chinese    in    traditional    script
Taiwan    Chinese    in    simplified    script
Taiwan    Chinese    in    traditional    script
traditional    Chinese
Old    Church    Slavonic
Haitian    Creole
Brunei    Darussalam
German    Democratic    Republic
Egyptian    demotic
Nadiza    dialect
Natisone    dialect
Natisone    dialect,    Nadiza    dialect
C&#xF4;te    d'Ivoire
Eastern    Europe
Northern    Europe
Southern    Europe
Western    Europe
Burkina    Faso
Russian    Federation
(alias    for    Hiragana    +    Katakana)
Code    for    unwritten    languages
Code    for    undetermined    script
Code    for    uncoded    script
Metropolitan    France
Eastern    Frisian
Northern    Frisian
Western    Frisian
Scottish    Gaelic
South    Georgia    and    the    South    Sandwich    Islands
Low    German
Swiss    German
Swiss    German    Sign    Language
Traditional    German    orthography
French    Guiana
Equatorial    Guinea
Saint    Helena
Egyptian    hieratic
Egyptian    hieroglyphs
Mayan    hieroglyphs
Pahawh    Hmong
Old    Hungarian
Azerbaijani    in    Arabic    script
Azerbaijani    in    Cyrillic    script
Azerbaijani    in    Latin    script
Belarusian    in    Latin    script
Bosnian    in    Cyrillic    script
Bosnian    in    Latin    script
Inuktitut    in    Canadian    Aboriginal    Syllabic    script
Inuktitut    in    Latin    script
Mongolian    in    Cyrillic    script
Mongolian    in    Mongolian    script
Serbian    in    Cyrillic    script
Serbian    in    Latin    script
Tajik    in    Arabic    script
Tajik    in    Cyrillic    script
Uzbek    in    Cyrillic    script
Uzbek    in    Latin    script
British    Indian    Ocean    Territory
Bouvet    Island
Christmas    Island
Heard    Island    and    McDonald    Islands
Norfolk    Island
&#xC5;land    Islands
Cayman    Islands
Cook    Islands
Falkland    Islands    (Malvinas)
Faroe    Islands
Marshall    Islands
Solomon    Islands
Virgin    Islands,    British
Virgin    Islands,    U.S.
Old    Italic    (Etruscan,    Oscan,    etc.)
Chinook    jargon
United    Kingdom
Saint    Kitts    and    Nevis
Hong    Kong
Hong    Kong    Chinese    in    simplified    script
Hong    Kong    Chinese    in    traditional    script
Default    Language
Algonquian    languages
Apache    languages
Athapascan    languages
Australian    languages
Bamileke    languages
Chamic    languages
Iroquoian    languages
Manobo    languages
Mayan    languages
Miscellaneous    languages
Multiple    languages
Munda    languages
Nubian    languages
Otomian    languages
Prakrit    languages
Salishan    languages
Sami    languages    (Other)
Sign    Languages
Siouan    languages
Sorbian    languages
Tupi    languages
Wakashan    languages
Yupik    languages
Sri    Lanka
Tai    Le
Sierra    Leone
Kayah    Li
No    linguistic    content
Saint    Lucia
PRC    Mainland    Chinese    in    simplified    script
PRC    Mainland    Chinese    in    traditional    script
Northern    Mariana    Islands
San    Marino
Hiri    Motu
Syloti    Nagri
Viet    Nam
North    Ndebele
South    Ndebele
Classical    Nepal    Bhasa
Papua    New    Guinea
Classical    Newari
Old    Newari
Norwegian    Nynorsk
Norwegian    Nynorsk
Isle    of    Man
Union    of    Soviet    Socialist    Republics
Kan    or    Gan
Mandarin    or    Standard    Chinese
Shanghaiese    or    Wu
Xiang    or    Hunanese
German    orthography    of    1996
Lao    People's    Democratic    Republic
Old    Permic
Old    Persian
Pollard    Phonetic
Saint    Pierre    and    Miquelon
Tok    Pisin
French    Polynesia
Czech    Republic
Dominican    Republic
Costa    Rica
Puerto    Rico
Western    Sahara
El    Salvador
Inari    Sami
Lule    Sami
Northern    Sami
Skolt    Sami
Southern    Sami
American    Samoa
Low    Saxon
Holy    See    (Vatican    City    State)
American    Sign    Language
Belgian-Flemish    Sign    Language
Belgian-French    Sign    Language
Brazilian    Sign    Language
British    Sign    Language
Colombian    Sign    Language
Danish    Sign    Language
Dutch    Sign    Language
French    Sign    Language
German    Sign    Language
Greek    Sign    Language
Irish    Sign    Language
Italian    Sign    Language
Japanese    Sign    Language
Mexican    Sign    Language
Nicaraguan    Sign    Language
Norwegian    Sign    Language
Portuguese    Sign    Language
Spanish    Sign    Language
Swedish    Sign    Language
Church    Slavic
Church    Slavonic
Old    Slavonic
Lower    Sorbian
Upper    Sorbian
Northern    Sotho
French    Southern    Territories
Visible    Speech
United    States    Minor    Outlying    Islands
United    States
New    Tai    Lue
Crimean    Tatar
Palestinian    Territory,    Occupied
East    Timor
Sao    Tome    and    Principe
Sranan    Tongo
Crimean    Turkish
PRIVATE    USE
PRIVATE    USE
PRIVATE    USE
PRIVATE    USE
PRIVATE    USE
PRIVATE    USE
Cape    Verde
Saint    Vincent    and    the    Grenadines
Sichuan    Yi
New    Zealand
Neutral    Zone

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 2 Oct 2006 23:36:00 -0700

John Cowan <cowan at ccil dot org> wrote:

> I'd be more in favor of merging descriptions that are a prefix of 
> other descriptions:  if we have both "Foo (Bar)" and "Foo", to 
> eliminate the latter in favor of the former.  I don't feel strongly 
> about this, however.

There's some fairly strong aopposition to that, from Debbie and (I 
believe) others who feel at least one Description field needs to match 
the name in each of the corresponding standards.  That's why "bas" is 
listed as both "Basa" (from 639-2) and "Basa (Cameroon)" (from 639-3), 
and "bzw" is listed only as "Basa (Nigeria)" since it appears only in 
639-3 and not in 639-2.

I'm not at all happy with having one of the Basas be listed as just 
"Basa", but I suppose I can't argue with the logic.  We do say that the 
purpose of the Description is "to indicate the meaning of that 
identifier [subtag] as defined in the source standard."  If we point 
back to the source standard for meaning, the names do have to match.

> These "replaced by" comments existed in the RFC 3066 registry as a 
> kind of crude Preferred-Value, and we now have a better mechanism.  I 
> can easily see someone looking at this entry and not knowing whether 
> to use "sgn-sgg" or "sgg".

I did some spelunking and found where the "requirement" came from to add 
these bogus comments.  Early copies of draft-ietf-ltru-registry, the 
document that became RFC 4646, included a section 3.7 called 
"Initialization of the Registry" (note, singular -- there was no 
extensions registry yet) that contains a good deal of text that was 
later moved into draft-ietf-ltru-initial (RFC 4645).  That section 
included this passage:

"All other tags in the RFC 3066 registry that are deprecated will be 
maintained as grandfathered entries... The 'Comments' field will contain 
the reason for the deprecation."

By that time we already had invented Preferred-Value, a much better 
mechanism (as John points out), but the passage was there.  I never 
liked it -- for example, in 
http://www1.ietf.org/mail-archive/web/ltru/current/msg02481.html from 
June 2005 (search for the word "mindless") -- but decided to live with 
it.  In the meantime, the "will" clause became "SHOULD" and then "may 
optionally" but the comments remained.

I am 100% in favor of deleting, as part of the RFC 4645bis Registry 
reload, every Comments field of the form "replaced by ISO code xxx" 
where at best the same information can be gleaned from the 
Preferred-Value, and at worst the comment may add confusion.  That is to 
say, all of them.  RFC 4646 allows Comments fields to be added or 
deleted with impunity; if we can do this as part of the update instead 
of taking it to ietf-languages I am all for it.  Comments that add no 
real information do not need to clutter up the Registry.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 03 Oct 2006 14:52:44 +0900

>(deprecated | (preferred, deprecated))?

That can also be written something like:

(preferred?, deprecated)?

><!ELEMENT alt          EMPTY>    <!-- separator -->

Separators are in general a bad idea. If we have multiple
description entries in the current format, the most straight-
forward way to deal with them is description*, i.e.
multiple <description> elements. Anything else would be strange.

>Same idea as <br />, certainly not pretty, but "works"

What about multiple description elements doesn't work?

Regards,     Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Tue, 03 Oct 2006 14:52:44 +0900

Regards,     Martin.

---

From: John Cowan <[email-masked]>
Date: Tue, 3 Oct 2006 12:08:20 -0400

> real information do not need to clutter up the Registry.

+1

-- 
John Cowan  http://ccil.org/~cowan  [email-masked]
All "isms" should be "wasms".   --Abbie

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 3 Oct 2006 09:18:14 -0700

+1

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 05 Oct 2006 19:31:01 +0200

> (preferred?, deprecated)?

Thanks, much better.
 
> Separators are in general a bad idea.

Indeed, but if that's working for Debbie's application it's
okay.  It's possible to implement it as option in the script,
either output <alt /> or </description><description> with a
corresponding DTD.

The day before yestderday I could test the behaviour with
MS Excel, apparently that works - I've no clue how to get
rid of some bogus columns, but Excel users should know how
that's supposed to work.

> What about multiple description elements doesn't work?

I can't tell, Debbie is experimenting with XML imports into
a database.  

Frank

---

From: Martin Duerst <[email-masked]>
Date: Mon, 09 Oct 2006 18:05:06 +0900

[co-chair hat off]

At 02:22 06/10/03, Mark Davis wrote:
>Overall, I think inverted names are a bad idea. They are rather anglocentric, and we find that translators often do the wrong thing with them. They are also hugely inconsistent in the current registry.
>
>I think they are tolerable if (a) every single instance of a comma indicates an inverted name, and (b) all names are consistently inverted. Because of (a) one could programmatically fix the names to the correct value. 

I don't think creating artificial syntax rules or some
kind of restricted (English) grammar for Description fields
is appropriate. What I can immagine is that we use semicolons
rather than commas to indicate boundaries between input
from different origins.

Regards,    Martin.

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 15 Oct 2006 15:52:32 -0700

We need to reach consensus on this. I see two basic options.

A. Allow inverted names with commas, but otherwise no commas (outside of
parentheticals). For consistency, also invert all the other names that could
reasonably be inverted.

ALLOW: Description: Ambae, West

REPLACE Description: Naga, Maring
WITH Description: Naga; Maring

REPLACE Description: Northern Sotho
WITH Description: Sotho, Northern

B. Disallow inverted names.

REPLACE: Description: Ambae, West
WITH: Description: West Ambae

REPLACE Description: Naga, Maring
WITH Description: Naga; Maring

Note: I think the suggestion to uniformally use ";" as a separator between
different names is a good one, so I've done that with both options above.

I did a quick & dirty dump of all description names containing ",", and toke
a shot at how option B would look for the 5% or so of the cases. These are
just my initial take -- that's the problem with the current names, they are
a hodgepodge when it comes to this issue!

FIX THE INVERSION

Slavic, Church    =>    Church Slavic
Greek, Modern    =>    Modern Greek
Frisian, Northern    =>    Northern Frisian
Frisian, Western    =>    Western Frisian
Ndebele, North    =>    North Ndebele
Ndebele, South    =>    South Ndebele
Sotho, Southern    =>    Southern Sotho
Ar&#xE1;ra, Par&#xE1;    =>    Par&#xE1; Ar&#xE1;ra
Abnaki, Eastern    =>    Eastern Abnaki
Abnaki, Western    =>    Western Abnaki
Acipa, Eastern    =>    Eastern Acipa
Pashayi, Northeast    =>    Northeast Pashayi
Arrernte, Eastern    =>    Eastern Arrernte
Ach&#xED;, Cubulco    =>    Cubulco Ach&#xED;
Ach&#xED;, Rabinal    =>    Rabinal Ach&#xED;
Agta, Isarog    =>    Isarog Agta
Agta, Central Cagayan    =>    Central Cagayan Agta
Agta, Remontado    =>    Remontado Agta
Alta, Southern    =>    Southern Alta
Agta, Mt. Iriga    =>    Mt. Iriga Agta
Aizi, Tiagbamrin    =>    Tiagbamrin Aizi
Aizi, Mobumrin    =>    Mobumrin Aizi
Aizi, Aproumu    =>    Aproumu Aizi
Altai, Southern    =>    Southern Altai
Amami-Oshima, Southern    =>    Southern Amami-Oshima
English, Old    =>    Old English
Apache, Jicarilla    =>    Jicarilla Apache
Apache, Kiowa    =>    Kiowa Apache
Apache, Lipan    =>    Lipan Apache
Apache, Mescalero-Chiricahua    =>    Mescalero-Chiricahua Apache
Apache, Western    =>    Western Apache
Alta, Northern    =>    Northern Alta
Arrarnta, Western    =>    Western Arrarnta
Atta, Pudtol    =>    Pudtol Atta
Atta, Pamplona    =>    Pamplona Atta
Altai, Northern    =>    Northern Altai
Acipa, Western    =>    Western Acipa
Awyu, South    =>    South Awyu
Awyu, Central    =>    Central Awyu
Awyu, Jair    =>    Jair Awyu
Awyu, Edera    =>    Edera Awyu
Ar&#xE1;ra, Mato Grosso    =>    Mato Grosso Ar&#xE1;ra
Armenian, Middle    =>    Middle Armenian
Ayta, Sorsogon    =>    Sorsogon Ayta
Ayta, Bataan    =>    Bataan Ayta
Ayta, Tayabas    =>    Tayabas Ayta
Amuzgo, San Pedro Amuzgos    =>    San Pedro Amuzgos Amuzgo
Amuzgo, Ipalapa    =>    Ipalapa Amuzgo

CHANGE TO SEMI-COLON

Yi, Sichuan    =>    Yi; Sichuan
Ayta, Ambala    =>    Ayta; Ambala
Agta, Camarines Norte    =>    Agta; Camarines Norte
Ayta, Abenlen    =>    Ayta; Abenlen
Malay, Ambonese    =>    Malay; Ambonese
Adi, Galo    =>    Adi; Galo
Tibetan, Amdo    =>    Tibetan; Amdo
Amis, Nataoran    =>    Amis; Nataoran
Amuzgo, Guerrero    =>    Amuzgo; Guerrero
Arapesh, Bumbita    =>    Arapesh; Bumbita
Asmat, Casuarina Coast    =>    Asmat; Casuarina Coast
Asurin&#xED;, Xing&#xFA;    =>    Asurin&#xED;; Xing&#xFA;
Asmat, Yaosakor    =>    Asmat; Yaosakor
Manobo, Ata    =>    Manobo; Ata
One, Molmo    =>    One; Molmo
Gbe, Ayizo    =>    Gbe; Ayizo
Atta, Faire    =>    Atta; Faire
Nahuatl, Highland Puebla    =>    Nahuatl; Highland Puebla
Kayan, Busang    =>    Kayan; Busang
Birifor, Malba    =>    Birifor; Malba
Pahari, Mahasu    =>    Pahari; Mahasu
Bareli, Rathwi    =>    Bareli; Rathwi
Chin, Bawm    =>    Chin; Bawm
B&#xE9;te, Guiberoua    =>    B&#xE9;te; Guiberoua
B&#xE9;t&#xE9;, Daloa    =>    B&#xE9;t&#xE9;; Daloa
Bareli, Pauri    =>    Bareli; Pauri
Itneg, Banao    =>    Itneg; Banao
Sorsogon, Masbate    =>    Sorsogon; Masbate
Karen, Pa'o    =>    Karen; Pa'o
Ayta, Mag-Indi    =>    Ayta; Mag-Indi
Kanuri, Bilma    =>    Kanuri; Bilma
...

NOTE
As I was doing this, I saw the following. It may be perfectly fine, but it
looks a bit suspicious, especially since there are a bunch of "Atga" entries
with different modifiers. Could this be a spelling error?

Agta, Mt. Iraya

Mark

On 10/9/06, Martin Duerst <[email-masked]> wrote:
> >I think they are tolerable if (a) every single instance of a comma
> indicates an inverted name, and (b) all names are consistently inverted.
> Because of (a) one could programmatically fix the names to the correct
> value.
>

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 15 Oct 2006 16:40:03 -0700

Mark Davis wrote:

> A. Allow inverted names with commas, but otherwise no commas (outside 
> of parentheticals). For consistency, also invert all the other names 
> that could reasonably be inverted.
>

There shouldn't be any Description fields with a semicolon separating 
two alternative names.  They should be two Description fields instead:

Description: Naga
Description: Maring

That, of course, assumes this is a valid example, and "nng" really does 
have the two alternative names "Naga" and "Maring."  That seems unlikely 
considering the existence of "mbw", which is also called "Maring."

> I did a quick & dirty dump of all description names containing ","

I can't verify the accuracy of much of this list, but one clear error 

> Yi, Sichuan    =>    Yi; Sichuan

This is currently listed in ISO 639-2 as "Sichuan Yi."

> Nahuatl, Highland Puebla    =>    Nahuatl; Highland Puebla

intuitively seems wrong.  I suggest if we want to embark on this, we 
have to go beyond the data files and look each of these up interactively 
on the 639-3 Web site, which does include both the inverted and 
non-inverted forms.  Sometimes, as in the case of Sichuan Yi, this may 
even require going to the linked Ethnologue page.

---

From: "Kent Karlsson" <[email-masked]>
Date: Mon, 16 Oct 2006 11:18:09 +0200

Mark Davis wrote:

A. Allow inverted names with commas, but otherwise no commas (outside of parentheticals). For consistency, also invert all the other names that could reasonably be inverted. 

I think this is preferable for LSR (and 639), but a bad idea for actual presentation (like via CLDR). CLDR (and others) should use non-inverted names.

Note: I think the suggestion to uniformally use ";" as a separator between different names is a good one, so I've done that with both options above. 

I was under the impression that the 639-3 draft tables almost did not include any alternative names (and in the few cases where it does, it uses ; as separator), (almost) just single but often qualified names. But that is just my impression. (As for "Naga", there are 39 different entries, with different qualifications (not alternatives, obviously).)
 
        /kent k

---

From: Peter Constable <[email-masked]>
Date: Mon, 16 Oct 2006 10:04:49 -0700

Definitely some of the changes below would be wrong: e.g., 

-        “Yi, Sichuan” is an inverted form of “Sichuan Yi”

-        “Agta, Camarines Norte” is an inverted form of “Camarines Norte Agta”

-        “Malay, Ambonese” is an inverted form of “Ambonese Malay”; “Ambonese” is an alternate name, but “Malay” probably isn’t a good choice for an alternate name since that would generally be understood as Bahasa Malaysia

-        “Nahuatl, Highland Puebla” is an inverted form of “Highland Puebla Nahuatl”

More of these are similar; a closer review would be needed to determine which of these changes would really make sense.

Peter 

From: Mark Davis [mailto:[email-masked]] 

CHANGE TO SEMI-COLON

NOTE
As I was doing this, I saw the following. It may be perfectly fine, but it looks a bit suspicious, especially since there are a bunch of "Atga" entries with different modifiers. Could this be a spelling error? 

Agta, Mt. Iraya 

Mark

[co-chair hat off]

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#   http://www.sw.it.aoyama.ac.jp <http://www.sw.it.aoyama.ac.jp>        mailto:[email-masked]

---

From: Peter Constable <[email-masked]>
Date: Mon, 16 Oct 2006 10:16:48 -0700

BTW, I meant to add in this discussion of inverted names and other aspects of the forms of descriptions (not registry deltas!), if there is feedback that this WG would want to send back to the ISO 639 JAC for their consideration as to changes they could make in the descriptions that would make things easier for the LSR, this is a good time to submit that as the JAC will be meeting in a couple of weeks (teleconf) to discuss various issues related to the completion of part 3 and maintenance of the various parts in relation to one another. There have been some plans to work on names (e.g. the 639-3 RA had a work item to review the names in the 639-3 draft code table to improve consistency, especially where the draft code table for part 3 doesn’t have names that are widely used, such as “Dari”).

(Also, btw: seeing the problems we have with managing description fields has for the first time made me wonder if the formal overhead of ISO 11179 might not offer some benefit. I don’t know enough about 11179 to be able to answer that; it’s just a question that popped into my head.)

Peter

From: Peter Constable [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 10:05 AM
To: LTRU Working Group
Subject: RE: [Ltru] Re: Registry deltas

 

Peter 

CHANGE TO SEMI-COLON

NOTE

Agta, Mt. Iraya 

Mark

[co-chair hat off]

Regards,    Martin.

---

From: Addison Phillips <[email-masked]>
Date: Mon, 16 Oct 2006 11:14:57 -0700

Peter Constable wrote:
> BTW, I meant to add in this discussion of inverted names and other 
> aspects of the forms of descriptions (not registry deltas!), if there is 
> feedback that this WG would want to send back to the ISO 639 JAC for 
> their consideration as to changes they could make in the descriptions 
> that would make things easier for the LSR, this is a good time to submit 
> that as the JAC will be meeting in a couple of weeks (teleconf) to 
> discuss various issues related to the completion of part 3 and 
> maintenance of the various parts in relation to one another. 

How about: use a different separator for multiple names than for 
reversed names and be consistent in that usage. That is, this list is 
unambiguous:

   Saxon, Low; Low Saxon

 > There have
> been some plans to work on names (e.g. the 639-3 RA had a work item to 
> review the names in the 639-3 draft code table to improve consistency, 
> especially where the draft code table for part 3 doesn’t have names that 
> are widely used, such as “Dari”).
> 

On some level, completing the list of names in the ILSR isn't that 
important. While it is nice to search the ILSR and find one's language, 
at some point the user will need to resort to external references for 
ambiguous items. Attempts to provide *every* commonplace name for a 
language in one particular language (English??) or script (Latin) is 
just as foolish as attempting to provide a localization in every language.

> 
> (Also, btw: seeing the problems we have with managing description fields 
> has for the first time made me wonder if the formal overhead of ISO 
> 11179 might not offer some benefit. I don’t know enough about 11179 to 
> be able to answer that; it’s just a question that popped into my head.)
> 

You're kidding, right? *We* (LTRU) don't appear to have a problem, 
woolly attempts at making the registry the One Shining Source for ISO 
639 aside. If ISO 639 made the names consistent, there wouldn't be any 
issue with description fields.

I'd be happier with a rule for Doug and Michael to follow that is clear 
and unambiguous and has the required latitude---and then letting the 
problem take care of itself, as, so far, it has. Perhaps:

--
If more than one name is provided by the underlying standard for a new 
or updated record or the same name appears in multiple formats, the 
Language Subtag Reviewer MAY select which name or names appear in a 
Description field in the associated registry record (subject to 
community consensus) and MAY edit the names to correct spelling, 
orthographic, or formatting errors. The Reviewer MAY split a list of 
names into separate Description fields. Note: Additional Description 
fields MAY be added in various formats via the registration process.
--

PS> I didn't have any problem finding the language record for 'cu' this 
morning to see what we'd done previously.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Peter Constable <[email-masked]>
Date: Mon, 16 Oct 2006 11:27:13 -0700

From: Addison Phillips [mailto:[email-masked]] 

   Saxon, Low; Low Saxon

I just glanced through the code table at the LOC site for 639-2 and cannot find any inconsistencies: ";" is used to separate alternate names and "," is used for name inversion. With that in mind, I don't see any ambiguity in

   Saxon, Low; Low Saxon

Peter Constable

---

From: "Kent Karlsson" <[email-masked]>
Date: Mon, 16 Oct 2006 21:51:08 +0200

+1 as modified below (but needs wordsmithing).

> orthographic, or formatting errors.

even if there is just one name given in the source registry

> The Reviewer MAY split a list of 

in this case: "MAY" -> "SHOULD", or (preferably) even "SHALL"

		/kent k