LANGUAGE SUBTAG MODIFICATION File-Date: 2006-06-05 %% Type: language Subtag: nqo Description: N’Ko Suppress-Script: Nkoo Added: 2006-06-05 %% -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/
As most list members probably know, Montenegro voted two weeks ago to leave the confederation of Serbia and Montenegro (our dear friend "CS") and declared its independence. More recently, Serbia completed the circle by declaring independence from Montenegro on June 5. While there is no official statement yet on the ISO 3166/MA Web site, it is widely expected [citation needed] that the MA will withdraw the controversial alpha-2 code element CS and assign two new code elements for the two new countries. Of course, this would affect the Language Subtag Registry by causing the region subtag CS to be deprecated and two new subtags to be added. There is an article on Wikipedia titled "Serbian country codes" which gives one Belgrade resident's take on the matter. The following passage may be of interest, especially the last paragraph, which would constitute a mistake orders of magnitude greater than the reuse of CS. --- begin quote --- Two-letter ISO 3166-1 Alpha-2 This code, used also as Internet TLD, is the major problem with ISO assignment to Serbia. All combinations of S as a first letter and any other letter in word Serbia, or even Srbija (in Serbian), are already taken by other states: Country names Alpha-2 ------------- ------- Saudi Arabia SA Slovenia SI(Continue reading)
Debbie Garside <debbie at ictmarketing dot co dot uk> wrote: > You may be interested to know that no 639-6 alpha4 representation will > be allocated to a linguistic entity that already has a 639-3 alpha3 > code. That is a dramatic step toward eliminating my concerns -- and probably those of others as well -- that 639-6 couldn't be made to work with a successor to RFC 3066bis. I'll still be interested to see how we would go about defining equivalences between a language-script combination, or a language-region combination, and a unitary 639-6 code element that means the same thing. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/
I apologize for sending this message to the wrong list. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/
Would it make sense to have two Description entries, reflecting both the spellings used in the other standards (but perhaps with the smart apostrophe first)? eg. Type: language Subtag: nqo Description: N’Ko Description: N'Ko Suppress-Script: Nkoo Added: 2006-xx-xx There are precedents for multiple descriptions already, eg. Type: language Subtag: cu Description: Church Slavic Description: Old Slavonic Description: Church Slavonic Description: Old Bulgarian Description: Old Church Slavonic Added: 2005-10-16 RI ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium)(Continue reading)
Richard Ishida scripsit: > There are precedents for multiple descriptions already, eg. > > Type: language > Subtag: cu > Description: Church Slavic > Description: Old Slavonic > Description: Church Slavonic > Description: Old Bulgarian > Description: Old Church Slavonic > Added: 2005-10-16 That reflects the underlying standard providing more than one name. That is not the case for N'Ko. -- -- Verbogeny is one of the pleasurettes John Cowan <cowan <at> ccil.org> of a creatific thinkerizer. http://www.ccil.org/~cowan -- Peter da Silva
It is not a requirement in the spec that it "reflects the underlying standard"
"The field 'Description' MAY appear more than one time. At least one of
the 'Description' fields MUST contain a description of the tag being
registered written or transcribed into the Latin script; the same or
additional fields MAY also include a description in a non-Latin script.
The 'Description' field is used for identification purposes and SHOULD
NOT be taken to represent the actual native name of the language or
variation or to be in any particular language. Most descriptions are
taken directly from source standards such as ISO 639 or ISO 3166."
That being said, what we specifically didn't want was for the description to have multiple transcriptions, rather than use a source that is designed to have the names of entities in different languages (like CLDR).
Mark
Richard Ishida scripsit:
> There are precedents for multiple descriptions already, eg.
>
> Type: language
> Subtag: cu
> Description: Church Slavic
> Description: Old Slavonic
> Description: Church Slavonic
> Description: Old Bulgarian
> Description: Old Church Slavonic
> Added: 2005-10-16
That reflects the underlying standard providing more than one name.
That is not the case for N'Ko.
--
Verbogeny is one of the pleasurettes John Cowan <cowan <at> ccil.org>
of a creatific thinkerizer. http://www.ccil.org/~cowan
-- Peter da Silva
_______________________________________________
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
Richard Ishida <ishida at w3 dot org> wrote: > Would it make sense to have two Description entries, reflecting both > the spellings used in the other standards (but perhaps with the smart > apostrophe first)? > > eg. > > Type: language > Subtag: nqo > Description: N’Ko > Description: N'Ko > Suppress-Script: Nkoo > Added: 2006-xx-xx > > There are precedents for multiple descriptions already, eg. > > Type: language > Subtag: cu > Description: Church Slavic > Description: Old Slavonic > Description: Church Slavonic > Description: Old Bulgarian > Description: Old Church Slavonic > Added: 2005-10-16 The concept of multiple Description fields was intended to reflect situations where two or more genuinely different names are used to identify the same language. This does not mean providing translations of a language name into multiple languages (German, Deutsch, allemand, tedesco, etc.), but providing alternative names -- generally in their English form -- that are likely to translate to alternative names in other languages as well. For example, providing "Spanish" and "Castilian" as alternatives, as ISO 639-2 does, seemed appropriate since speakers of that language may refer to their own language as either "español" or "castellano" (usually depending on where they live). The Church Slavic example you gave also seems reasonable, since all five names differ from the others in some substantive way. Choosing between a plain ASCII apostrophe and a more typographically accurate, curly apostrophe does not seem to me to constitute "alternative names" in the same sense. When building the initial registry -- and there was plenty of opportunity for input on this -- the LTRU Working Group decided to use the exact spellings, including apostrophes and other non-letters, employed in the various ISO and UN standards from which subtags were derived. We even went so far as to use the "acute accent" character, U+00B4, in the name "Gwich´in" because that is what ISO 639 used. The "smart" apostrophe was used for the script N'Ko because it appeared in ISO 15924. Personally I think it is unfortunate that this uncoordinated variety of apostrophes appears in the registry, but after all, the spelling in the Description field is not normative and can be changed. The decision is up to the list and the Reviewer, but personally I would argue against adding multiple Descriptions that differ only in a minor typographical detail like this. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/
At 23:32 -0700 2006-06-07, Doug Ewell wrote: >Choosing between a plain ASCII apostrophe and a >more typographically accurate, curly apostrophe >does not seem to me to constitute "alternative >names" in the same sense. So much so that I wonder why this is an issue. I mean really. Why is this an issue? >We even went so far as to use the "acute accent" >character, U+00B4, in the name "Gwich´in" >because that is what ISO 639 used. You did WHAT? Oh, this is too depressing. The Gwich'in language uses a glottal stop, which could be represented by U+0027 APOSTROPHE or by U+2019 RIGHT SINGLE QUOTATION MARK, although the **correct** character to use is U+02BC MODIFIER LETTER APOSTROPHE (see http://www.languagegeek.com/dene/gwichin/gwichin.html). If ISO 639 is using U+00B4 ACUTE ACCENT this is some sort of bizarre fallback, and it is **not** what we should be using. We should use the correct character (as we do in ISO 15924), and if ISO 639 is using the wrong one, we should help them to correct it. It is the codes (Nkoo, nqo) that are normative, not the descriptions. >The "smart" apostrophe was used for the script >N'Ko because it appeared in ISO 15924. >Personally I think it is unfortunate that this >uncoordinated variety of apostrophes appears in >the registry, but after all, the spelling in the >Description field is not normative and can be >changed. Gwich'in should be changed to Gwichʼin, surely. >The decision is up to the list and the Reviewer, >but personally I would argue against adding >multiple Descriptions that differ only in a >minor typographical detail like this. APOSTROPHE and RIGHT SINGLE QUOTATION MARK are a well-known typographical pairing and I don't suppose we need to have both. -- -- Michael Everson * http://www.evertype.com
Michael Everson <everson at evertype dot com> wrote: >> Choosing between a plain ASCII apostrophe and a more typographically >> accurate, curly apostrophe does not seem to me to constitute >> "alternative names" in the same sense. > > So much so that I wonder why this is an issue. I mean really. Why is > this an issue? I think it would be inappropriate and silly to use one type of apostrophe for the script N'Ko and another for the language N'Ko. To me they are not "alternative names," but they create a completely arbitrary difference. Searching would not necessarily work as expected, for instance. >> We even went so far as to use the "acute accent" character, U+00B4, >> in the name "Gwich´in" because that is what ISO 639 used. > > You did WHAT? Oh, this is too depressing. The Gwich'in language uses a > glottal stop, which could be represented by U+0027 APOSTROPHE or by > U+2019 RIGHT SINGLE QUOTATION MARK, although the **correct** character > to use is U+02BC MODIFIER LETTER APOSTROPHE (see > http://www.languagegeek.com/dene/gwichin/gwichin.html). If ISO 639 is > using U+00B4 ACUTE ACCENT this is some sort of bizarre fallback, and > it is **not** what we should be using. We should use the correct > character (as we do in ISO 15924), and if ISO 639 is using the wrong > one, we should help them to correct it. I found the thread in LTRU, from the 2005-04-24 time frame. I had originally flattened all the apostrophes to U+0027 (also for Ge'ez and N'Ko), then Frank Ellermann suggested leaving them as the ISO standards had them instead of "second-guessing" ISO, and nobody else weighed in pro or con, so I put them back. I did object that "U+00B4 is not even an apostrophe," but ultimately I considered my role to be one of editing the initial registry draft, reflecting the will of the list, not imposing my preferences if list consensus did not seem to support them. > It is the codes (Nkoo, nqo) that are normative, not the descriptions. The choice was between being (or appearing to be) arbitrary on our own, or accepting the arbitrariness of others. We had recently taken a good deal of criticism for not justifying some of the decisions we'd made. > Gwich'in should be changed to Gwichʼin, surely. Then this should be discussed here. Please, list members, if you have a view on this, speak up within the next two weeks. > APOSTROPHE and RIGHT SINGLE QUOTATION MARK are a well-known > typographical pairing and I don't suppose we need to have both. Indeed, my original motivation was to avoid "having both" for N'Ko, one for the script and the other for the language. We should focus here on Richard's suggestion to have two Descriptions, one with the straight apostrophe and one with the curly one. I don't agree and apparently Michael doesn't either. Do we need to restart the two-week review period? We can always revisit any or all of the Description fields at any time. Apparently there is no debate on the Suppress-Script field for N'Ko. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/
RSS Feed5 | |
|---|---|
39 | |
5 | |
16 | |
199 | |
1 | |
2 | |
65 | |
7 | |
21 | |
6 | |
30 | |
35 | |
14 | |
98 | |
5 | |
1 | |
13 | |
63 | |
93 | |
35 | |
38 | |
10 | |
21 | |
73 | |
5 | |
19 | |
49 | |
2 | |
112 | |
151 | |
24 | |
137 | |
73 | |
3 | |
40 | |
85 | |
111 | |
187 | |
227 | |
115 | |
37 | |
189 | |
129 | |
44 | |
66 | |
4 | |
10 | |
129 | |
114 | |
30 | |
72 | |
59 | |
56 | |
479 | |
252 | |
50 | |
25 | |
8 | |
67 | |
158 | |
21 | |
247 | |
164 | |
21 | |
73 | |
21 | |
121 | |
142 | |
107 | |
97 | |
326 | |
187 | |
178 | |
221 | |
275 | |
174 | |
52 | |
147 | |
128 | |
42 | |
262 | |
14 | |
98 | |
343 | |
176 | |
56 | |
12 | |
52 | |
95 | |
113 | |
9 | |
36 | |
170 | |
92 | |
103 | |
174 | |
302 | |
306 | |
17 | |
32 | |
66 | |
47 | |
112 | |
187 | |
30 | |
9 |
