Re: Multilanguage alt/title

HI Gregory,

After producing the wiki page on OBJECT element support in the latest  
browsers, I"m even more convinced this is the way to go [1]. From the  
results so far, it seems that every  current browser except Safari  
allows for a simplified  use of the OBJECT element (as nearly as  
simple as the IMG element except that for IE the dimensions need to  
be specified). The OBJECT element is much closer to being a  
replacement for IMG than I would have thought. If these bugs in IE  
(extracting and using the media's intrinsic dimensions) and Safari  
(not even handling this content at all) could be worked out, we would  
be there.

I also think the OBJECT element is close to being as simple to use as  
IMG even for video, audio: the time-based media. If we were to add  
requirements that time-based media handlers must provide a few simple  
controls, it would make sites using this media much more accessible.  
In other words, I think any handler of an OBJECT element that embeds  
an audio or video object should support  the basic time-based and  
audio controls through DOM APIs, i.e.: play/pause toggle, scan- 
forward, scan-reverse, volume-up and volume-down and mute. It may  
also be useful to provide an API to simply move to the focus to the  
next and previous embedded content element.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/ObjectSupport>

On Aug 29, 2007, at 10:18 AM, Gregory J. Rosmaita wrote:

>
> aloha, olivier!
>
> while i find your proposed "altlang" and "titlelang" attributes not
> only as intriguing, but necessary if ALT is retained in HTML5, and
> despite the excellent proposals of sander [1], rob and ben [2] for a
> better ALT, i am convinced that the solution lies in a more robust,
> much more detailed definition of, OBJECT -- rich markup would then not
> be an issue, and a browser could, through content-negotation with the
> rich content contained in the UA's preferences to expose the  
> equivalent
> for the primary language or any other supported language that the user
> has set as a natural language cascade as the primary equivalent/ 
> alternate
> content offered to the user;
>
> the superior mechanism i would prefer be implemented is to reform and
> tightly define OBJECT, so that only one element is needed to contain
> video, audio, static images, etc. -- it would need to be an element  
> whose
> children are marked up (lang="fr" or xml:lang="fr") so as to  
> facillitate
> content-negotiation, so that the appropriate alternate equivalents are
> easily available to the user...
>
> take, for example, a speech of vladmir putin -- obviously, if you are
> russian and deaf, you want to be served a russian transcript; if  
> you can
> hear and understand spoken russian, but don't have a russian-capable
> screen reader, a russian braille table for your refreshable braille
> display, or a cyrillic font on for one's UA, one might request the
> transcript in one's own native tongue, so that the meaning of any
> unfamiliar phrases one hears can be gleaned from the transcript;
>
> basically, in the ideal world, OBJECT would be able to  
> programmatically
> indicate the equivalent/alternate presentation options that are
> available to the user, so that the user can choose from amongst many
> forms of alternate/equivalent presentation of the contents of the
> OBJECT and not be limited to a single alternative incapable of  
> containing
> rich markup -- the content negotiation would be used to order, and --
> if so set by the user in the UA's preferences -- limit what kinds of
> equivalent content are presented to the end user, including the option
> of the simultaneous exposition of an alternate/equivalent and the
> OBJECT itself...
>
> using OBJECT as a universal media container capable of providing rich
> fallback, has been objected to because, it is claimed, it has been
> "broken" by implementors; to me that is a compelling arguement for
> standardizing the attributes and capacities of OBJECT and its  
> children in
> the "user agent conformance" section of the HTML5 draft...
>
> gregory.
>
> 1. http://lists.w3.org/Archives/Public/public-html/2007Aug/1096.html
> 2. http://lists.w3.org/Archives/Public/public-html/2007Jul/0987.html
> -----------------------------------------------------------------
> LANGUAGE, n.  The music with which we charm the serpents guarding
> another's treasure.     -- Ambrose Bierce, The Devil's Dictionary
> -----------------------------------------------------------------
>             Gregory J. Rosmaita, oedipus@hicom.net
> UBATS: United Blind Advocates for Talking Signs: http://ubats.org
> -----------------------------------------------------------------
>
> ---------- Original Message -----------
> From: "Olivier GENDRIN" <olivier.gendrin@gmail.com>
> To: public-html <public-html@w3.org>
> Sent: Tue, 28 Aug 2007 10:21:32 +0200
> Subject: Multilanguage alt/title
>
>> Hello WG !
>>
>> I found yesterday night an issue about multilanguage alt and
>> title : example : <span lang="fr">Lorem ipsum <abbr
>> title="National Aeronautics and Space Administration
>> (Administration nationale de l'aéronautique et de l'espace)
>> ">NASA</abbr> sit dolor amet</span>.
>>
>> As you can see, i'm in a situation where, in a french sentence,
>>  i have an abbreviation thas is used in french (so I don't need
>> to apply a @lang to my abbr) but who's long version is in
>> english. And as far as some of my readers don't read english, i
>> provide them with a tranlsated version of the abbreviation.
>>
>> How could we indicate (to page readers) the language of a part
>> of a title or alt ?
>>
>> Perhaps an attribute @titlelang end @altlang (like @hreflang)
>>  that will take language code and ponctuation séparations.
>> Language code an ponctuation have to be separated by withe spaces.
>>
>> Examples :
>> <abbr title="National Aeronautics and Space Administration
>> (Administration nationale de l'aéronautique et de l'espace)"
>> titlelang="en ( fr )">NASA</abbr>
>> <acronym title="Working Group - groupe de travail" titlelang="en
>> - fr">WG</acronym>
>>
>> The white space separator between language codes and ponctuation
>> is important because of fr-fr language codes...
>>
>> -- 
>> Olivier G.
>> http://www.lespacedunmatin.info/blog/
> ------- End of Original Message -------
>
>

Received on Wednesday, 29 August 2007 23:31:49 UTC