W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

Re: [whatwg] Forced subtitles

From: Jonathan Garbee <jonathan@garbee.me>
Date: Mon, 15 Apr 2013 17:25:33 -0400
Message-ID: <CANQy2y3iuHryVOg1S_wd48WKa7TwUs1P9FcMWx2Ucaz4M=a0tw@mail.gmail.com>
To: WHAT Working Group <whatwg@lists.whatwg.org>
I think it should be up to the developer to chose the default subtitles
they want. What if someone is trying to localize a page, and the default
subtitle is always English when they want Spanish? If not specified, the
default subtitle should be the language specified of the page or video.
But, if a specific subtitle language is told to the browser it should use
that.


On Thu, Apr 11, 2013 at 7:35 PM, Eric Carlson <eric.carlson@apple.com>wrote:

>
> On Apr 11, 2013, at 3:54 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>
> > I think Eric is right - we need a new @kind="forced" or
> @kind="forcedSubtitles" value on track elements, because they behave
> differently from the subtitle kind:
> > * are not listed in a track menu
> > * are turned on by browser when no other subtitle or caption track is on
> > * multiple forced subtitles tracks can be on at the same time (see
> discussion at https://www.w3.org/Bugs/Public/show_bug.cgi?id=21667 )
> >
> > I only wonder how the browser is meant to identify for which language it
> needs to turn on the forced subtitles. If it should depend on the language
> of the audio track of the video rather than the browser's default language
> setting, maybe it will need to be left to the server to pick which tracks
> to list and all forced tracks are on, no matter what? Did you have any
> ideas on this, Eric?
> >
>   I believe it should be the language of the video's primary audio track,
> because forced subtitles are enabled in a situation where the user can
> presumably understand the dialog being spoken in the track's language and
> has not indicated a preference for captions or subtitles.
>
> eric
>
>
> >
> > On Fri, Apr 12, 2013 at 4:08 AM, Eric Carlson <eric.carlson@apple.com>
> wrote:
> >
> >  In working with real-world content with in-band subtitle tracks, I have
> realized that the spec doesn't accommodate "forced" subtitles. Forced
> subtitles are used when a video has dialog or text in a language that is
> different from the main language. For example in the Lord of the Rings,
> dialog in Elvish is subtitled so those of us that don't speak Elvish can
> understand.
> >
> >  This is only an issue for users that do not already have
> subtitles/captions enabled, because standard caption/subitle tracks are
> expected to mix the translations into the other captions in the track. In
> other words, if I enable an English caption track I will get English
> captions for the dialog spoken in English and the dialog spoken in Elvish.
> However, users that do not typically have subtitles enabled also need to
> have the Elvish dialog translated so subtitle providers typically provide a
> second subtitle track with *only* the forced subtitles.
> >
> >   UAs are expected to automatically enable a forced-only subtitle track
> when no other caption/subtitle track is visible and there is a forced-only
> track in the same language of the primary audio track. This means that when
> I watch a version of LOTR that has been dubbed into French and I do not
> have a subtitle or caption track enabled, the UA will automatically show
> French forced subtitles if they are available.
> >
> >  Because forced subtitles are meant to be enabled automatically by the
> UA, it is essential that the UA is able to differentiate between "normal"
> and "forced" subtitles. It is also important because forced subtitles are
> not typically listed in the caption menu, again because the captions in
> them are also in the "normal" subtitles/captions.
> >
> >  I therefore propose that we add a new @kind value for forced subtitles.
> "Forced" is a widely used term in the industry, so I think "forced" is the
> appropriate value.
> >
> > eric
> >
> >
> >
>
>
Received on Monday, 15 April 2013 21:26:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC