At 0:02 -0400 10/06/07, Brian Campbell wrote:
On Jun 9, 2007, at 5:26 PM, Dave Singer wrote:
I have to confess I saw the BBC story about sign-language soon
after sending this round internally. But I need to do some study
on the naming of sign languages and whether they have ISO codes.
Is it true that if I say that the human language is ISO 639-2 code
XXX, and that it's signed, there is only one choice for what the
sign language is (I don't think so -- isn't american sign language
different from british)? Alternatively, are there ISO or IETF
codes for sign languages themselves?
Almost no sign languages are related to the spoken language in the
same region any more than any two spoken languages are related to
each other.
OK, but are they often, sometimes, or never geographically
co-located? i.e. if there are N spoken languages in the world and M
sign languages, do we really have MxN possibilities of what a given
sign-language-capable person can do?
Sign languages are full-fledged languages in their own right, not
signed transliterations of spoken language (though they do
frequently have an alphabet system for signing words and names from
spoken languages). So, American Sign Language is not actually
related to English any more than other languages spoken in America
are (like Cherokee or Spanish).
The situation with the ISO 639-2 codes is unfortunate, because there
is only a single code for all sign languages, sgn. It appears that
the solution is to add extensions specifying the actual language,
such as sgn-US or sgn-UK. There's more information available here:
<http://www.evertype.com/standards/iso639/sgn.html>
That is truly unfortunate, however, I guess it's not in scope for
HTML to solve.
At 12:05 +0100 10/06/07, Benjamin Hawkes-Lewis wrote:
The proposal does not describe how conflicts such as the following
would be resolved:
User specifies:
captions: want high-contrast-video: want
Author codes:
<video ... > <source media="all and (captions:
want;high-contrast-video: dont-want)" ... /> <source media="all and
(captions: dont-want;high-contrast-video: want)" ... /> </video>
There is no suitable source here; it's best to have something (late)
in the list which is less restrictive.
But if UAs can apply accessibility preferences to a catch-all <source>
listed last, then what's the advantage of creating multiple <source>
elements in the first place?
There are two common cases to consider:
a) the accessibility option is 'burned in' to the media (e.g. burned
in captions); you then need to select the right one
b) the media is adaptable (e.g. tracks that can be enabled in a QT
movie); you then need to select it and adapt it.
It may be that there isn't an accessible version of the movie
suitable for your accessibility needs (it does hapen sometimes -:().
It might be prudent to author the page so that such users get to see
something.
Current container formats can
include captions and audio descriptions. So is the problem we're trying
to solve that container formats don't contain provision for alternate
visual versions (high contrast and not high contrast)? Or are we
trying to cut down on bandwidth wastage by providing videos
containing only the information the end-user wants?
Both, I think.
a) I should think sign-language interpretation needs to be in
there.
sign-interpretation: want | dont-want | either (default: want)
Unless we want to treat sign interpretation as a special form of
subtitling. How is subtitling in various languages to be handled?
I think we assume that a language attribute can also be specified, as
today.
The lang attribute specifies "the primary language for the element's
contents and for any of the element's attributes that contain text",
not the referenced resource. hreflang "gives the language of the
linked resource" as a single "valid RFC 3066 language code." So we'd
need a new attribute or to change the content model of hreflang to
explicitly specify the separate multiple languages of a resource.
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-global.html#the-lang
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#hreflang3
I note in passing that these attributes should be updated to use RFC
4646 not RFC 3066 as per:
http://www.w3.org/TR/i18n-html-tech-lang/#ri20030112.224623362
This could quickly become unworkable, and I feel that perhaps it
would be best to drop into a composition language such as SMIL, where
one can then explicitly ask for a 'par' of two selections, one
selecting the audio (by spoken language) and one the signing (by sign
language).
I have to confess I saw the BBC story about sign-language soon after
sending this round internally. But I need to do some study on the
naming of sign languages and whether they have ISO codes. Is it
true
that if I say that the human language is ISO 639-2 code XXX, and
that it's signed, there is only one choice for what the sign language
is (I don't think so -- isn't american sign language different from
british)? Alternatively, are there ISO or IETF codes for sign
languages themselves?
Brian Campbell has eloquently answered some of these questions.
The reason I was thinking of using a CSS property was that signed
interpretation is not the same as signing featured in the original
video. But it's true that information about what sign languages are
available is important, so a CSS property alone wouldn't solve the
problem. Maybe we need new attributes to crack this nut:
<source contentlangs="en,sgn-en"
captionlangs="sgn-en-sgnw,fr,de,it,sgn" dubbinglangs="fr"
subtitlelangs="de,it"
signedinterpretationlangs="sgn-en,sgn-fr,sgn-de,sgn-it" ...>
This would indicate that the main video content features people
talking in English and people signing in English; the video is
captioned in English, French, German, Italian, and their SignWriting
analogues (American Sign Language in the case of English), dubbed in
French, subtitled in German and Italian, and provided with signed
interpretation in American, French, German and Italian Sign
Languages.
Granted it's a sledgehammer,
It really does seem very heavy. I guess a meta-goal here was to try
to make a system that was simple and comprehensible enough that a
reasonable number of web authors would use it.
I think we'd prefer not to get into quantitative measures here, but a
boolean "this program is unsuitable for those prone to epilepsy
induced by flashing lights" might make sense. epilepsy: dont-want
-:)
Why?
simplicity, comprehensibility, both of which lead to likelihood of
adoption. Also, the matching process doesn't need to know anything
about what the axes mean. If we allow quantitative measures, then
the user would have to be able to express "less than X", "greater
than Y", or maybe even "between X and Y", and content authors would
have to know how to measure, rather than simply knowing how to tag.
--
David Singer
Apple/QuickTime
