This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23710 - Add support for forced subtitles
Summary: Add support for forced subtitles
Status: RESOLVED DUPLICATE of bug 23507
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on: 21667
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-02 02:39 UTC by Silvia Pfeiffer
Modified: 2013-11-06 01:10 UTC (History)
11 users (show)

See Also:


Attachments

Description Silvia Pfeiffer 2013-11-02 02:39:31 UTC
+++ This bug was initially created as a clone of Bug #21667 +++

Rationale: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039374.html

also see the discussion on the bug.

The request is to introduce @kind="forced" with "forced subtitles" defineded as:
Forced Subtitles are common on movies. Forced subtitles only provide subtitles when the characters speak a foreign or alien language, or a sign, flag, or other text in a scene is not translated in the localization and dubbing process. In some cases, foreign dialogue may be left untranslated if the movie is meant to be seen from the point of view of a particular character who does not speak the language in question.

Note that WebKit already has an implementation of this and Chromium has a bug: https://code.google.com/p/chromium/issues/detail?id=271185 .
Comment 1 Philip Jägenstedt 2013-11-02 22:47:40 UTC
Some details on the processing model would be nice. For example, what should happen when there are multiple <track kind=forced> in different (or the same) language but no other tracks? What if the language of the forced subtitles isn't one the user understands?
Comment 2 Silvia Pfeiffer 2013-11-02 23:35:30 UTC
Interpreting Eric's email at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039374.html , he seems to say that only one "forced" track is necessary, so we can probably ignore all other "forced" tracks. Also, the first forced track is only activated when no other track is enabled, because translations would end up in subtitle or captions tracks in other languages.
Comment 3 Philip Jägenstedt 2013-11-03 21:46:50 UTC
OK, just allowing one and ignoring language certainly makes it easier. The only thing easier would be to enable all forced tracks but to make it non-conforming to have multiple forced tracks if that doesn't ever make sense.
Comment 4 Silvia Pfeiffer 2013-11-03 23:21:43 UTC
(In reply to Philip Jägenstedt from comment #3)
> OK, just allowing one and ignoring language certainly makes it easier. The
> only thing easier would be to enable all forced tracks but to make it
> non-conforming to have multiple forced tracks if that doesn't ever make
> sense.

FWICT: the forced subtitle track is only for native speakers of the main language of the video who need translation of only a few things that are in a different language in the video. Thus, a single track active at a time is the only sensible thing.

As for the language attribute: it should still be given as the language of main language of the video. This allows to provide several forced tracks for videos that have several audio tracks in different languages.
Comment 5 Philip Jägenstedt 2013-11-04 08:08:19 UTC
(In reply to Silvia Pfeiffer from comment #4)
> (In reply to Philip Jägenstedt from comment #3)
> > OK, just allowing one and ignoring language certainly makes it easier. The
> > only thing easier would be to enable all forced tracks but to make it
> > non-conforming to have multiple forced tracks if that doesn't ever make
> > sense.
> 
> FWICT: the forced subtitle track is only for native speakers of the main
> language of the video who need translation of only a few things that are in
> a different language in the video. Thus, a single track active at a time is
> the only sensible thing.

I'm just saying that activating all of them is the easiest thing to implement. If having multiple forced tracks makes no sense then presumably people won't do it even if it works.

> As for the language attribute: it should still be given as the language of
> main language of the video. This allows to provide several forced tracks for
> videos that have several audio tracks in different languages.

In comment 2 you seemed to say that only a single track would be forced, but the above sounds like picking a forced track based on its language and the language of the enabled audio tracks. That's a lot more complicated, so how should that work when audio tracks are enabled/disabled, when new forced tracks of a matching language are added, etc?
Comment 6 Silvia Pfeiffer 2013-11-04 12:33:59 UTC
(In reply to Philip Jägenstedt from comment #5)
> 
> I'm just saying that activating all of them is the easiest thing to
> implement. If having multiple forced tracks makes no sense then presumably
> people won't do it even if it works.

WFM.

> > As for the language attribute: it should still be given as the language of
> > main language of the video. This allows to provide several forced tracks for
> > videos that have several audio tracks in different languages.
> 
> In comment 2 you seemed to say that only a single track would be forced, but
> the above sounds like picking a forced track based on its language and the
> language of the enabled audio tracks.

Since you asked if there was a use case for several forced tracks, I considered it further and came up with this rather complicated example.

> That's a lot more complicated, so how
> should that work when audio tracks are enabled/disabled, when new forced
> tracks of a matching language are added, etc?

If we can identify what language an audio track is in (AudioTrack does have a language attribute), then activating such an audio track should trigger looking for a forced track in the same language, and activating that (unless a caption or subtitle track is activated).
Comment 7 Ian 'Hixie' Hickson 2013-11-04 21:51:54 UTC
This is currently blocked on more implementors being interested — see bug 23507.

*** This bug has been marked as a duplicate of bug 23507 ***