Subject: [Ltru] Re: Sign languages (was: Re: additions to ISO 639 and the IANA language subtag registry)

From: "Doug Ewell" <[email-masked]>
Date: Mon, 20 Feb 2006 20:17:25 -0800

John Cowan <cowan at ccil dot org> wrote:

> I propose that in 3066ter, the 'sgn' subtag should be treated as sui
> generis: partly a language, partly a macrolanguage.  For the national
> sign languages, it is a language and the country subtag serves to
> discriminate; the corresponding 639-3 code element is suppressed from
> the subtag registry.  For the non-national sign languages, it is a
> macrolanguage and the 639-3 code would be used as an extlang.
>
> I agree that this is messy, but we know that people have used codes 
> like
> sgn-US, and there can be no assurances that they have not used 
> 3066-valid
> codes like sgn-CR even though they were never registered with IANA.

We have no assurances that people have not done lots of things that 
aren't valid.  (NOT to reopen this dead-end thread, but I'm sure 
someone, somewhere has used "en-UK".)

"sgn-CR" is perfectly 3066-valid for "sign languages as used in Costa 
Rica," but if anyone has used it to mean specifically "Costa Rican SL" 
on the basis of Michael's page, they have no assurance that it will be 
interpreted as such by 3066-conformant processors.

> Here's my specific proposal:
>
>    Adamorobe SL  [sgn-ads] (Ghana)
>    Algerian SL  [sgn-DZ] (Algeria) (suppress asp)
>    American SL  [sgn-US] (USA) (suppress ase)
> ...

In cases like Algerian SL, American SL, and so forth, where the sgn + 
region syntax would be syntactically legal, why don't we add *both* to 
the registry and make one Preferred over the other?

Type: extlang
Subtag: asp
Description: Algerian Sign Language
Added: 200x-xx-xx
Prefix: sgn
...
Type: grandfathered
Tag: sgn-DZ
Description: Algerian Sign Language
Added: 200x-xx-xx
Preferred-Value: sgn-asp
Deprecated: 200x-xx-xx
Comments: replaced by ISO 639-3 code asp

"sgn-DZ" could be considered grandfathered because it can already be 
composed from existing subtags, although not with that exact meaning. 
(Again, the whole reason we are having this discussion is that "Algerian 
Sign Language" is not guaranteed to be identical to "sign languages as 
used in Algeria.")

In cases like Adamorobe SL, where the tag "sgn-GH-EP" is not legal under 
RFC 3066bis, we would pretty much have to do as John suggests.  The only 
alternative would be to amend the syntax to allow such stuff, which 
would break just about all of the new 3066bis syntactical features.

I suspect this discussion really belongs on LTRU, and I've cross-posted 
it there.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/

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

---

From: John Cowan <[email-masked]>
Date: Mon, 20 Feb 2006 23:25:17 -0500

> interpreted as such by 3066-conformant processors.

I think that's splitting hairs.  sgn-US unquestionably means American
Sign Language, by RFC 3066 registration; it would be entirely proper
for people to use sgn-CR for Costa Rican SL.

> the registry and make one Preferred over the other?

Because multiple codes for the same thing is a big annoyance and impedes
matching.  Essentially the same reason why we are going to use zh-yue
instead of just yue.

-- 
Where the wombat has walked,            John Cowan <[email-masked]>
it will inevitably walk again.          http://www.ccil.org/~cowan

---

From: John Cowan <[email-masked]>
Date: Tue, 21 Feb 2006 12:43:22 -0500

Michael Everson scripsit:

> I think using the 2-letter code for Ghana plus a 
> modifier might be better here. That is what we 
> used for Martha's Vineyard SL, isn't it?

MVSL has no registered code, so we can do what we like with it.
In any case, the 3166-2 modifiers are too short; we would need to
go with sgn-US-martha and sgn-GH-adamo or some such.

> In general I favour whaat John has suggested. I 
> would LIKE to work with Phil Blair and his 
> contacts at Gallaudet on this. Can we take time 
> to do that? It will take time.

Yes, certainly.  All this won't become live until the next round of
revisions, after ISO 639-3 becomes available.

-- 
John Cowan  [email-masked]  www.ccil.org/~cowan
Female celebrity stalker, on a hot morning in Cairo:
"Imagine, Colonel Lawrence, ninety-two already!"
El Auruns's reply:  "Many happy returns of the day!"

---

From: r&d afrac <[email-masked]>
Date: Tue, 21 Feb 2006 19:57:38 +0100

Could the debate over the obsolete Language Tag Registry and the not 
yet manned Language Subtag Registry be kept out the LTRU mailing 
list? The Charter is this list precludes these issues to be discussed 
here. Please stop cross posting.
jfc

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 21 Feb 2006 13:38:12 -0800

> From: [email-masked] [mailto:ietf-languages-
> [email-masked]] On Behalf Of John Cowan

> for people to use sgn-CR for Costa Rican SL.

Picking this arbitrary point to respond and give my opinion.

First, I agree with others that signed expression of spoken languages is
simply another modality, like writing, and a variant subtag -signed is
the appropriate solution; e.g., en-signed for Signed English.

As for tags for signed languages (not signed expression of spoken
languages), I think the use of region IDs in the template "sgn-XX" to
identify *languages* is a bad idea; (note: with "sgn-XX" tags, the "sgn"
is largely redundant, and a large part of the semantic distinction is in
the country subtag):

- As Mark Davis pointed out, many matching implementations will treat
"sgn-XX" and "sgn-YY" as though there was some significant common
relationship even if in fact the two are entirely unrelated.

- The "sgn-XX" template cannot accommodate cases in which multiple
signed languages are spoken in a given country. This is a real scenario
with multiple instances, and where it occurs you necessarily end up with
some kludge. 

- Because a country ID is required to indicate the *language* identity,
a region subtag is no longer available to support region-based
sub-language distinctions (e.g. ASL as used in Canada rather than the
US). I don't know of specific scenarios requiring this, though it's
certainly plausible.

I don't particularly see what benefit is gained by having a common
subtag prefix for all signed languages. But I'm willing to consider
arguments that there is some significant benefit. For sake of
discussion, let's assume that there is: then I strongly prefer that
3066ter would handle "sgn" like a macrolanguage ID and use ISO 639
alpha-3 extlang subtags; thus, "sgn-csd" for Chiang Mai Sign Language
and "sgn-tsq" for Thai Sign Language rather than using "sgn-TH" for
either.

 Peter Constable

---

From: John Cowan <[email-masked]>
Date: Tue, 21 Feb 2006 17:16:41 -0500

> is largely redundant, and a large part of the semantic distinction is in

I agree that it's a bad idea considered de novo; however, we have a bunch
of 3066-registered tags of this form which people have been encouraged
to use.  We can't just sweep that history under the rug.

This is closely analogous to the "zh" and "ar" problems that caused you to
devise the macrolanguage machinery.

> relationship even if in fact the two are entirely unrelated.

The same is true of macrolanguages in general.  Spoken zh-cmn and spoken
zh-yue are not usefully interchangeable, but matching implementations
will treat them as related.  It can't be helped.

"We learn from history that we learn nothing from history."  --Hegel

> > Country designations (or some other designation)
> > are necessary in some instances.
> 
> The key here is "or some other designation". In no case is a country
> subtag *necessary* to provide a distinction between language identities.

They're necessary because history has made them necessary.  It is not
*necessary* that some language subtags are 2 letters and others are
3 letters, but history has compelled us to make this arbitrary
distinction.

> Frankly, it seems to me that a need to take some time working out a
> scheme arises only when we've got a hair-brained scheme that tries to
> use country subtags in some cases and (necessarily) not in others. If we
> just use treat signed languages like any other normal language using
> tags like "ads", or if we agree on a consistent template using alpha-3
> extlang subtags e.g. "sgn-ads", then there's nothing to be worked out as
> far as the tagging scheme is concerned; the only open issue is
> identifying what are all the distinct signed languages out there.

I agree with all that.  I just don't think that's where we are.

-- 
We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.
Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
fishes, for a poor creature, and they say death.  So wise they are; so just,
so very just.  --Gollum        [email-masked]  www.ccil.org/~cowan