sgn-MT [et al.]: new RFC 3066 tag[s]

[Michael Everson]

At 20:02 -0700 2004-10-02, Doug Ewell wrote:

>Indeed, registering tags like this means that consumers are forced 
>to look in the registry, even for a tag that conforms to the normal 
>generative mechanism, because the registration may have given the 
>tag a different meaning.

That is what the registry is for. I know, all this revision is 
supposed to make it unnecessary but in this case any way

>"Sign languages as used in the United States" is not the same thing 
>as "American Sign Language," as everyone on this list (on both sides 
>of the debate) agrees.

"Sign languages as used in the United States" does not refer to a 
language. It is an error. There is no such "language" as "Sign 
Language". Each is a discreet entity with its own grammar and 
vocabulary. Interestingly, some sign languages are related; French 
Sign Language, Irish Sign Language, and American Sign Language were 
all influenced by French missionaries helping to set up Deaf schools.

>Plus, when a tag like "sgn-XX" is registered to mean "the one and 
>only XXish Sign Language," there is no longer an RFC 3066 tag that 
>means "Sign Languages (i.e. one of possibly many) as used in XX." 
>And there might be a reason to do just that.

I think the problem is that "sgn" does not refer to a language AT 
ALL, and (as I suggested once a long time a go) I think the RFC 
should define as SPECIAL syntax for what happens wit the prefix "sgn".

>Why shouldn't these be registered under RFC 3066 as:
>
>sgn-mdl    for Maltese Sign Language
>sgn-tss    for Taiwanese Sign Language
>sgn-fse    for Finnish Sign Language
>sgn-xml    for Malaysian Sign Language

Because that doesn't make sense to the existing user community who 
has been using, and wishes to continue to use, the scheme as 
developed.

>Such constructions are at least as much in keeping with the RFC 3066 
>registration procedure as the language-plus-country "informative" 
>registrations, possibly more so.  There is already a precedent for 
>registering tags composed of an ISO 639 code plus an invented 
>3-letter subtag: no-bok, no-nyn, zh-gan, zh-min, zh-wuu, and zh-yue.

"xml" isn't very informative. ;-P

>The great benefit of this approach would be that these subtags (mdl, 
>tss, fse, xml) are already the codes listed in the ISO 639-3 draft 
>for these sign languages, so if that draft is approved with those 
>codes, and RFC 3066bis is subsequently updated to allow ISO 639-3 
>codes as extended language subtags, then these four registered tags 
>will be automatically converted to "normal" tags that use the 
>generative mechanism.

Benefit to whom?

>OTOH, if the proposed language-country tags are registered, they will
>remain "grandfathered" exceptions forever.

I think the syntax for "sgn" should be defined to make sense. 
"sgn-US" "American Sign Language". Surely "sgn-ase" is redundant, if 
you are using those codes.

>I strongly support using "sgn-" together with the proposed ISO 639-3 
>codes to create any new sign-language tags.  I volunteer to help put 
>together the registration forms, if desired.

Then you would want to deprecate "sgn-IE" in favour of "sgn-isg", and 
I guess you will later want to deprecate that in favour of "isg"?

And what about Signed Spoken Languages? Those also MUST have country 
codes. "sgn-eng-IE" is different from "sgn-eng-US" and *very* 
different from "sgn-eng-GB". All of those are representations of 
spoken English.

I do not relish explaining the proposed changes to the user 
community, which helped develop this scheme. I would very much like 
the scheme there to be adopted as a special case for "sgn" in RFC 
3066bis.

-- 
Michael Everson * * Everson Typography *  * http://www.evertype.com