sgn-MT [et al.]: new RFC 3066 tag[s]
petercon at microsoft.com
Mon Oct 4 19:19:54 CEST 2004
> From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> bounces at alvestrand.no] On Behalf Of Doug Ewell
> >> 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...
> But I
> thought everyone had been saying that mnemonicity of subtags was
> explicitly not a goal.
It is certainly not a goal for ISO 639-3, since it is unachievable.
> >> I strongly support using "sgn-" together with the proposed ISO
> >> codes to create any new sign-language tags...
> > Then you would want to deprecate "sgn-IE" in favour of "sgn-isg",
> > I guess you will later want to deprecate that in favour of "isg"?
> The first, yes, I guess so...
> The second, I have no idea, because that depends on how Addison and
> intend for extended-language subtags to work. I know the main idea is
> to use them for individual languages that are part of what ISO 639-3
> calls a "macrolanguage." Sign languages are part of a "collective
> language" group, which is different. I don't know whether the intent
> was to encode Dominican Sign Language as "sgn-doq" or as simply "doq";
> assumed it was the former.
> But if "isg" is to be an ISO standard code for Irish Sign Language, is
> it really such a bad thing for it to be the standard language tag as
A thought on this: it seems to me that the value of using a multipart
tag (such as zh-yue or sgn-isg) rather than a simplex tag (yue or isg)
lies only in the ability to parse out the initial subtag to match
content and requests that use tags with differing levels of granularity.
(Mechanisms for fallback of some sort might also make use of multi-part
If you have content labelled "zh-yue" and a request for content in "zh",
then the language-range mechanism will treat the content as zh(-yue) and
provide a match. In macrolanguage situations, this is potentially
On the other hand, in the sign language cases, we'd be talking about
content tagged as "sgn-isg" (or "sgn-IE" or some other variation
beginning with "sgn-"), but a request for "sgn". Yet it doesn't seem
really to make sense to request "sgn" content since that can return many
The only possible benefit I can see from having tags for signed
languages take a complex form that always begins with "sgn-" would be if
signed-language content or resources often required some special type of
processing that was specific to signed languages and it was felt it
would be useful for implementations to be able to identify quickly that
a signed language was involved.
For users, though, I don't see that it matters: it has never been
expected that these tags would typically be exposed to users, and it is
a non-requirement that they be mnemonic or otherwise inherently
meaningful to humans.
> > 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 think there should be an RFC 3066bis variant subtag, "-signed", to
> cover this case. Michael and others have already stipulated that
> spoken languages are more like signed manifestations of a spoken
> language than like true sign languages. Signed U.S. English would be
> "en-US-signed". That should be mnemonic enough. Or is the user
> community already using "sgn-eng-US"?
There's certainly no question that signed English is something of a
distinct nature from a Sign Language such as ASL. It seems to me that
perhaps a signed representation of English isn't entirely unlike an IPA
representation of English: the linguistic variety is still English; it's
just been expressed using a representation other than the commonly-used
representation. Of course, there is a difference: if the content is
audio-visual, signed English is a difference in modality; but if we're
comparing a text representation of signed English versus an IPA
transcription of English, they're both text representations that are
alternates to the common orthography based on the Latin script.
So, inasmuch as there is an analogy, it might make sense to tag
"en-US-signed" for the one just as we might use something like
"en-US-Lipa" for the other. But I recognize some might not find the
Globalization Infrastructure and Font Technologies
Microsoft Windows Division
More information about the Ietf-languages