This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On Thu, 11 Apr 2013, Eric Carlson 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. On Fri, 12 Apr 2013, Silvia Pfeiffer 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? On Thu, 11 Apr 2013, Eric Carlson wrote: > > 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. On Mon, 15 Apr 2013, Jonathan Garbee wrote: > > 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 Tue, 16 Apr 2013, Silvia Pfeiffer wrote: > > The existing mean of publishing subtitles and the developer choice to > add a @default attribute on a track that a developer wants activated by > default is not affected by a new @kind=forced. You can still do all the > things that you're taking about. @kind=forced kicks in only if neither > the developer nor the user has made any explicit choice about which > track to activate. Also, Eric's suggestion to activate the forced > subtitle track that equals the language of the video seems to meet your > suggestion.
*** Bug 23710 has been marked as a duplicate of this bug. ***
WebKit already have an implementation of this and Chromium has a bug and are considering implementation: https://code.google.com/p/chromium/issues/detail?id=271185
So... I don't understand. How is this different to <track default="">? What exactly does kind=forced do? Does it exclude the track from the list of subtitles? Or...? What happens when there's multiple kind=forced tracks? What happens when there's a kind=forced track with default=""? Or a kind=forced track and a separate kind=subtitles track with default=""?
One difference from default would be that in-band tracks have no notion of being default, so if there are container formats which can hold information about forced tracks, the spec would have to add something to TextTrack to expose that. I don't know if there are such container formats.
(In reply to Ian 'Hixie' Hickson from comment #3) > So... I don't understand. How is this different to <track default="">? > > What exactly does kind=forced do? Does it exclude the track from the list of > subtitles? Or...? Eric Carlson wrote "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." Should we worry that authors will use kind=forced to enable captions that the user would rather turn off? Doesn't seem very far fetched that some would use it instead of default to get around the fact that implementors have some freedom in how to pick which tracks are enabled...
> Should we worry that authors will use kind=forced to > enable captions that the user would rather turn off? Forced subtitles are used on Blu Ray. I have not heard about such complaints.
(In reply to Ian 'Hixie' Hickson from comment #3) > So... I don't understand. How is this different to <track default="">? Think of "forced" as being burnt-in translations that get turned off as soon as the JS dev (through "default") or the user (through selection from the captions/subtitles list) activates a subtitles/captions track. It's basically forced to be shown when nothing else is activated. Here is an example: in "Avatar" the Na'vi speak a language that is different from any human language. So, it needs translating even when you watch the video with captions and subtitles turned off. These "forced" translations are only shown when no subtitles or captions are shown, because once a subtitle or caption track is selected, that track also contains the translation of the Na'vi words into the track language. > What exactly does kind=forced do? Does it exclude the track from the list of > subtitles? Or...? Yes, kind="forced" is not a subtitle track. It's basically and anti-subtitle/caption track. Therefore, "forced" wouldn't appear in the list of subtitle/caption tracks. > What happens when there's multiple kind=forced tracks? If they are all in the same language and their language is identical to the language of the active audio track, only the first (or last - take your pick) is "forced" on. Basically, it's not expected for there to be more than one "forced" track per audio track of different language. > What happens when there's a kind=forced track with default=""? In the unlikely case that there are multiple kind=forced tracks and their language is identical to the language of the active audio track, the "default" one could be the one that is "forced" on. > Or a > kind=forced track and a separate kind=subtitles track with default=""? If there is a subtitle or captions track that has a "default", then all "forced" tracks are turned off.
Some additional thoughts based on current practice. Blu Ray allows individual subtitles within a track to be labeled "forced", instead of mandating that the entire track to be labeled "forced". So, in practice, some Blu Ray titles use "forced-only" subtitle tracks plus "full-only", i.e. "non-forced", subtitle tracks. Other Blu Ray titles use tracks that include both "forced" and "full" subtitles. Some Blu Ray titles use a combination of both. See https://docs.google.com/spreadsheet/ccc?key=0AkGO8UqErL6idDhYYjg1ZXlORnRaM3ZhTks4Z3FrYlE&usp=sharing#gid=0/. This practice is apparently the result of (quote) "what has been prepared on what timeline and whether the master is "texted" or "textless" (note "texted" masters mean that text is burned into video, however you can also need to translate that via forced subtitles for the localized audio that is being presented)." So, based on existing workflow and catalog content, it would be good to consider allowing a track to contain both "forced" and "non-forced" subtitles. This would facilitate the reuse of assets. FWIW, this is the approach taken by Ultra Violet.
(In reply to Silvia Pfeiffer from comment #7) > If they are all in the same language and their language is identical to [...] How does their language affect anything? Can you elaborate on the very precise processing model you envisage here? > If there is a subtitle or captions track that has a "default", then all > "forced" tracks are turned off. Do "forced" tracks get disabled whenever a "subtitle" or "caption" track is enabled? Do they still fire events? Can you enable multiple "forced" tracks? (In reply to Pierre Lemieux from comment #8) > So, based on existing workflow and catalog content, it would be good to > consider allowing a track to contain both "forced" and "non-forced" > subtitles. This would facilitate the reuse of assets. FWIW, this is the > approach taken by Ultra Violet. That would be a VTT feature, primarily. It doesn't really fit the current design very cleanly, though.
(In reply to Ian 'Hixie' Hickson from comment #9) > (In reply to Silvia Pfeiffer from comment #7) > > If they are all in the same language and their language is identical to [...] > > How does their language affect anything? Can you elaborate on the very > precise processing model you envisage here? In the Na'bu example, you get multiple "forced" tracks by translating the Na'bu language into English, French, German, Japanese etc. Each one of the <track> elements has a @lang set to the target language (i.e. en, fr, de, jp). Then, depending on the active AudioTrack of the video element and its AudioTrack.language setting, the relevant "forced" track is forced on. E.g. if AudioTrack.language="de", you force on the <track kind=forced lang=de ...> track. > > If there is a subtitle or captions track that has a "default", then all > > "forced" tracks are turned off. > > Do "forced" tracks get disabled whenever a "subtitle" or "caption" track is > enabled? Yes they get disabled. > Do they still fire events? Not once disabled. > Can you enable multiple "forced" tracks? No.
(In reply to Ian 'Hixie' Hickson from comment #9) > (In reply to Pierre Lemieux from comment #8) > > So, based on existing workflow and catalog content, it would be good to > > consider allowing a track to contain both "forced" and "non-forced" > > subtitles. This would facilitate the reuse of assets. FWIW, this is the > > approach taken by Ultra Violet. > > That would be a VTT feature, primarily. It doesn't really fit the current > design very cleanly, though. On a side note, say the user has no "full" subtitle tracks selected, so the "forced" track is selected. Suddenly, the user selects a "full" subtitle track. Will there be an issue rapidly switching from one to the other in the middle of playback?
(In reply to Pierre Lemieux from comment #8) > > Blu Ray allows individual subtitles within a track to be labeled "forced", > instead of mandating that the entire track to be labeled "forced". Since you can only turn on/off full tracks, the labeling of individual cues as "forced" makes no difference to them being displayed in the current TextTrack model. I assume the use case here is to have another trigger to not display these "forced" cues when the translation is burnt-in. I don't think we should support that use case on the Web, but instead encourage publishers to not burn in any subtitles.
(In reply to Pierre Lemieux from comment #11) > > Will there be an issue rapidly switching from one to the other in the middle > of playback? Going from what I see in existing implementation, switching text tracks is instantaneous.
(In reply to Silvia Pfeiffer from comment #12) > (In reply to Pierre Lemieux from comment #8) > > > I don't think we should > support that use case on the Web, but instead encourage publishers to not > burn in any subtitles. Perhaps. This does not however change the fact that a large body of tracks have both "full" and "forced" subtitles. So I would recommend that the use case be considered in order ease reuse, e.g. reduce costs, increase availability, reduce possibility of mistakes, etc.
(In reply to Ian 'Hixie' Hickson from comment #9) > (In reply to Silvia Pfeiffer from comment #7) > > If they are all in the same language and their language is identical to [...] > > How does their language affect anything? Can you elaborate on the very > precise processing model you envisage here? > As reference, Annex A of [1] describes the subtitle track selection algorithm used in Ultraviolet. http://www.uvvuwiki.com/images/5/5c/ContentMetadata-1.0.7.pdf
(In reply to Pierre Lemieux from comment #14) > > Perhaps. This does not however change the fact that a large body of tracks > have both "full" and "forced" subtitles. A track like that is simply a kind="subtitles" track, which is already supported.
(In reply to Silvia Pfeiffer from comment #16) > (In reply to Pierre Lemieux from comment #14) > > > > Perhaps. This does not however change the fact that a large body of tracks > > have both "full" and "forced" subtitles. > > A track like that is simply a kind="subtitles" track, which is already > supported. Sure, but it contains "full" subtitle that someone might not be interested in, and "forced" subtitles that everyone should see. So the idea would be to have the ability to label individual subtitles as "forced" in a track otherwise labeled as "subtitle".
(In reply to Pierre Lemieux from comment #17) > > Sure, but it contains "full" subtitle that someone might not be interested > in, and "forced" subtitles that everyone should see. > > So the idea would be to have the ability to label individual subtitles as > "forced" in a track otherwise labeled as "subtitle". The way to deal with this is to transcode an existing such mixed Blu Ray track into 2 tracks: one that a "subtitle" track and has all the cues, and one that's a "forced" track and has only the "forced" cues. That provides full flexibility.
(In reply to Silvia Pfeiffer from comment #18) > > The way to deal with this is to transcode an existing such mixed Blu Ray > track into 2 tracks: one that a "subtitle" track and has all the cues, and > one that's a "forced" track and has only the "forced" cues. That provides > full flexibility. Sure... that is one more step in the authoring process, and thus an obstacle to availability.
(In reply to Pierre Lemieux from comment #19) > (In reply to Silvia Pfeiffer from comment #18) > > > > The way to deal with this is to transcode an existing such mixed Blu Ray > > track into 2 tracks: one that a "subtitle" track and has all the cues, and > > one that's a "forced" track and has only the "forced" cues. That provides > > full flexibility. > > Sure... that is one more step in the authoring process, and thus an obstacle > to availability. You have to convert from Blu Ray format to WebVTT anyway, so I don't see the problem.
(In reply to Silvia Pfeiffer from comment #20) > (In reply to Pierre Lemieux from comment #19) > > (In reply to Silvia Pfeiffer from comment #18) > > You have to convert from Blu Ray format to WebVTT anyway, so I don't see the > problem. The content publisher had one asset, now he/she has two.
Ok, let me ask more specific questions. 1. Do we want it to be possible for users to disable a forced track. 2. Do we want the forced track to automatically switch languages if script switches which audio track is selected. 3. Do we want the user to be able to manually switch forced track. 4. Do we want the forced track to automatically switch languages if script switches which audio track is selected even if the user had picked an explicit forced track. 5. Do we want the forced tracks to be script-selectable. 6. Do we want the forced track to automatically switch languages if script switches which audio track is selected even if the script had picked an explicit forced track.
> 1. Do we want it to be possible for users to disable a forced track. No. But when the user chooses a different caption/subtitle track, the forced track gets disabled. > 2. Do we want the forced track to automatically switch languages if script > switches which audio track is selected. Yes, it makes sense to switch to a different text track that aligns with the language of the now selected audio track. > 3. Do we want the user to be able to manually switch forced track. Probably yes. I can see two use cases: * When they discover that a different forced-track-@lang would be more appropriate than the current one. * When they want to switch from the current subtitle/caption track back to only display a forced-track. > 4. Do we want the forced track to automatically switch languages if script > switches which audio track is selected even if the user had picked an > explicit forced track. Probably yes, if there is a more appropriate forced-track-@lang than the previous one (where appropriate means: @lang of forced-track matches @lang of audio track better). > 5. Do we want the forced tracks to be script-selectable. Probably yes. The use case I'm basing that on is: if script knows a certain track to be more appropriate than the default forced-track, e.g. when the audio track has no @lang specified. > 6. Do we want the forced track to automatically switch languages if script > switches which audio track is selected even if the script had picked an > explicit forced track. Probably yes, if there is a more appropriate foced-track-@lang than the previous one.
So you want the user to be able to switch from "English" to "French" but not "English" to "none"? (Use case: Forced subtitles give English translation of Klingon audio, but this is a Klingon convention, where everyone does in fact speak Klingon, so the subtitles are distracting.)
(In reply to Ian 'Hixie' Hickson from comment #24) > So you want the user to be able to switch from "English" to "French" but not > "English" to "none"? (Use case: Forced subtitles give English translation of > Klingon audio, but this is a Klingon convention, where everyone does in fact > speak Klingon, so the subtitles are distracting.) Yes, that's how I understand what "forced" means. But I'd like others to clarify who have actual experience with this type of subtitles.
(In reply to Ian 'Hixie' Hickson from comment #24) > So you want the user to be able to switch from "English" to "French" but not > "English" to "none"? (Use case: Forced subtitles give English translation of > Klingon audio, but this is a Klingon convention, where everyone does in fact > speak Klingon, so the subtitles are distracting.) In general, a forced subtitle track is expected to match the language of the selected audio track. Specifically, according to the reference in Comment #15, the forced subtitle track is selected as follows (in order of decreasing priority): - a forced subtitle track that matches the language of the primary audio track - the selected primary subtitle track, if it contains forced subtitles - any available forced subtitle track So if a user selects Klingon as their preferred audio language (i.e. during a Klingon convention), then the "tlh" forced subtitle track would be selected (if it exists). This "tlh" forced subtitle track presumably would not contain Klingon forced subtitles over Klingon speech and instead (depending in Klingon subtitle/dubbing practices) Klingon forced subtitles over Federation speech.
(In reply to Ian 'Hixie' Hickson from comment #22) > 5. Do we want the forced tracks to be script-selectable. Even if the forced track is script-selectable, I recommend a default algorithm be specified, e.g. based on user preferences, as guidance to implementers.
Boilerplate question: Is this use case common enough to warrant a declarative solution? Do YouTube, Vimeo, Dailymotion, or any other video sites support something like this in a scripted implementation?
(In reply to Philip Jägenstedt from comment #28) > Boilerplate question: Is this use case common enough to warrant a > declarative solution? Do YouTube, Vimeo, Dailymotion, or any other video > sites support something like this in a scripted implementation? Wouldn't a scripted implementation need/benefit from an API to UA user preferences for language?
(In reply to Pierre Lemieux from comment #29) > > Wouldn't a scripted implementation need/benefit from an API to UA user > preferences for language? That already exists, see navigator.language (and newly navigator.getLanguages()).
So... given comment 28, do we actually have implementation interest here?
(In reply to Philip Jägenstedt from comment #28) > Boilerplate question: Is this use case common enough to warrant a > declarative solution? Do YouTube, Vimeo, Dailymotion, or any other video > sites support something like this in a scripted implementation? I don't know if video sites support forced subtitles, but they are fairly common in in-band captions.
(In reply to Eric Carlson from comment #32) > (In reply to Philip Jägenstedt from comment #28) > > Boilerplate question: Is this use case common enough to warrant a > > declarative solution? Do YouTube, Vimeo, Dailymotion, or any other video > > sites support something like this in a scripted implementation? > > I don't know if video sites support forced subtitles, but they are fairly > common in in-band captions. If this is mostly important for in-band, could a solution be devised where the forced track is exposed as kind=default, but the browser behaves as if the user always enables that track when all others are disabled? After all, scripts need to deal with users enabling/disabling tracks outside of their control anyway. I suppose that if the user then disables the forced track, it should really be disabled, but that only seems reasonable IMHO.
I assume you mean kind="subtitles"?
I was confused, default isn't a kind and it's an attribute of HTMLTrackElement, so it doesn't apply to in-band tracks since. Pretend I said kind="subtitles" instead :)
The spec already allows in-band tracks to be enabled for things like this. I've added a note explicitly referencing forced subtitles (see below). Do we actually need a feature here? Should we wait to see if we get a bigger volume of author requests?
Checked in as WHATWG revision r8500. Check-in comment: Add a note mentioning how forced in-band subtitles should trigger http://html5.org/tools/web-apps-tracker?from=8499&to=8500
Please let me know if there's implementation interest in supporting this for <track>. In the meantime, I'm punting on explicit support for this in out-of-band tracks, and the support for in-band tracks is just what's described in r8500.
(In reply to Ian 'Hixie' Hickson from comment #38) > Please let me know if there's implementation interest in supporting this for > <track>. In the meantime, I'm punting on explicit support for this in > out-of-band tracks, and the support for in-band tracks is just what's > described in r8500. Forced subtitles are really different than "regular" subtitles. Without a way for a script to identify a forced subtitle track, how can it know what to do with it - possibly exclude it from the track selection UI, when to enable it, etc?
Ian: the paragraph that you added to the spec assumes that UA can identify which of the tracks is the "forced subtitle" track. Firstly I wonder how the UA finds out in the first place which ones are the "forced subtitle" tracks when they come from a <track> element. Secondly, this gives UAs more knowledge over the properties of tracks for in-band tracks than JS developers and thus - as Eric correctly says - JS devs can't implement the logic stated in the paragraph.
Ian: Per Eric and Silvia's comments, "forced" timed text is a different kind of timed text than "subtitle" timed text. The changeset at http://html5.org/r/8500 states "if [...] this is a forced subtitle track". I do not see how this "if" test can be evaluated if there is no "forced" kind and the track not labeled as such. I was reminded of this issue when I purchased [1] and had to turn on captions globally on Android because no English subtitle track was marked as "forced" despite the fact that the US version of the movie is not dubbed and the entire dialog is in Hebrew. If a track had been labeled language="en" and kind="forced", the client would have known to turn it on without my involvement. [1] https://play.google.com/store/movies/details/The_Gatekeepers?id=mIJ82edWqWg Makes sense?
(In reply to Pierre Lemieux from comment #41) > I was reminded of this issue when I purchased [1] and had to turn on > captions globally on Android because no English subtitle track was marked as > "forced" despite the fact that the US version of the movie is not dubbed and > the entire dialog is in Hebrew. If a track had been labeled language="en" > and kind="forced", the client would have known to turn it on without my > involvement. > > [1] > https://play.google.com/store/movies/details/The_Gatekeepers?id=mIJ82edWqWg > > Makes sense? If the HTML text track model were followed, just having the audio track correctly labeled as Hebrew and an English track would have enabled the track, assuming the browser is configured to prefer English of course. If that were not reliable enough, adding the default attribute would have made English the fallback track. I don't think forced subtitles are a solution to the particular problem.
(In reply to Philip Jägenstedt from comment #42) > If the HTML text track model were followed, just having the audio track > correctly labeled as Hebrew and an English track would have enabled the > track, assuming the browser is configured to prefer English of course. If > that were not reliable enough, adding the default attribute would have made > English the fallback track. I don't think forced subtitles are a solution to > the particular problem. Philip: By "English track", do you mean an "en" audio track? If so, the point is that this particular movie did not have one, either by creative intent (dubbing can hide the original intonations) or by economic choice (cost). This is not a random occurrence. In fact, in some parts of the world, e.g. France, it is common to watch movies in their original (language) version (OV) with subtitles. Makes more sense?
(In reply to Pierre Lemieux from comment #43) > (In reply to Philip Jägenstedt from comment #42) > > If the HTML text track model were followed, just having the audio track > > correctly labeled as Hebrew and an English track would have enabled the > > track, assuming the browser is configured to prefer English of course. If > > that were not reliable enough, adding the default attribute would have made > > English the fallback track. I don't think forced subtitles are a solution to > > the particular problem. > > Philip: By "English track", do you mean an "en" audio track? If so, the > point is that this particular movie did not have one, either by creative > intent (dubbing can hide the original intonations) or by economic choice > (cost). This is not a random occurrence. In fact, in some parts of the > world, e.g. France, it is common to watch movies in their original > (language) version (OV) with subtitles. > > Makes more sense? No, I mean a Hebrew audio track and an English text track.
(In reply to Philip Jägenstedt from comment #44) > (In reply to Pierre Lemieux from comment #43) > > (In reply to Philip Jägenstedt from comment #42) > > > If the HTML text track model were followed, just having the audio track > > > correctly labeled as Hebrew and an English track would have enabled the > > > track, assuming the browser is configured to prefer English of course. If > > > that were not reliable enough, adding the default attribute would have made > > > English the fallback track. I don't think forced subtitles are a solution to > > > the particular problem. > > > > Philip: By "English track", do you mean an "en" audio track? If so, the > > point is that this particular movie did not have one, either by creative > > intent (dubbing can hide the original intonations) or by economic choice > > (cost). This is not a random occurrence. In fact, in some parts of the > > world, e.g. France, it is common to watch movies in their original > > (language) version (OV) with subtitles. > > > > Makes more sense? > > No, I mean a Hebrew audio track and an English text track. Philip: The 'language' attribute of the audio track indicates the language of the intended audience, and may not match the primary spoken languages, i.e. the languages to the which the actors lips move. For instance, the primary spoken languages of Hunt for Red October are "en" and "ru", even for tracks labeled "en", i.e. intended for release to audiences that speak "en". Similarly, an audio track of Avatar labeled "en" might in fact contain 50% Navi, for which "forced" subtitles would be provided in "en". Another example is where the spoken language is "fr" but is overdubbed in "en", in which case the audio track would typically be labeled "en". Further thoughts?
(In reply to Pierre Lemieux from comment #45) > (In reply to Philip Jägenstedt from comment #44) > > (In reply to Pierre Lemieux from comment #43) > > > (In reply to Philip Jägenstedt from comment #42) > > > > If the HTML text track model were followed, just having the audio track > > > > correctly labeled as Hebrew and an English track would have enabled the > > > > track, assuming the browser is configured to prefer English of course. If > > > > that were not reliable enough, adding the default attribute would have made > > > > English the fallback track. I don't think forced subtitles are a solution to > > > > the particular problem. > > > > > > Philip: By "English track", do you mean an "en" audio track? If so, the > > > point is that this particular movie did not have one, either by creative > > > intent (dubbing can hide the original intonations) or by economic choice > > > (cost). This is not a random occurrence. In fact, in some parts of the > > > world, e.g. France, it is common to watch movies in their original > > > (language) version (OV) with subtitles. > > > > > > Makes more sense? > > > > No, I mean a Hebrew audio track and an English text track. > > Philip: The 'language' attribute of the audio track indicates the language > of the intended audience, and may not match the primary spoken languages, > i.e. the languages to the which the actors lips move. For instance, the > primary spoken languages of Hunt for Red October are "en" and "ru", even for > tracks labeled "en", i.e. intended for release to audiences that speak "en". > Similarly, an audio track of Avatar labeled "en" might in fact contain 50% > Navi, for which "forced" subtitles would be provided in "en". Another > example is where the spoken language is "fr" but is overdubbed in "en", in > which case the audio track would typically be labeled "en". > > Further thoughts? The spec says "The AudioTrack.language and VideoTrack.language attributes must return the BCP 47 language tag of the language of the track" and nothing about an intended audience. In other words, if the audio track is in Hebrew, it should have language "he". Perhaps Avatar and Hunt for Red October are more complicated, but the example you gave in comment #41 seems to be simple subtitles, which AFAICT don't need to be forced for the UA to enable them.
(In reply to Philip Jägenstedt from comment #46) > Perhaps Avatar and Hunt for Red October are more complicated Sure let's focus on those. How would this work today, without "forced" timed text?
(In reply to Pierre Lemieux from comment #47) > (In reply to Philip Jägenstedt from comment #46) > > Perhaps Avatar and Hunt for Red October are more complicated > > Sure let's focus on those. How would this work today, without "forced" timed > text? OK, going back to your earlier comment: (In reply to Pierre Lemieux from comment #41) > Ian: Per Eric and Silvia's comments, "forced" timed text is a different kind > of timed text than "subtitle" timed text. The changeset at > http://html5.org/r/8500 states "if [...] this is a forced subtitle track". I > do not see how this "if" test can be evaluated if there is no "forced" kind > and the track not labeled as such. This information is available internally even if it is not exposed in the API.
(In reply to Philip Jägenstedt from comment #48) > > (In reply to Pierre Lemieux from comment #41) > > Ian: Per Eric and Silvia's comments, "forced" timed text is a different kind > > of timed text than "subtitle" timed text. The changeset at > > http://html5.org/r/8500 states "if [...] this is a forced subtitle track". I > > do not see how this "if" test can be evaluated if there is no "forced" kind > > and the track not labeled as such. > > This information is available internally even if it is not exposed in the > API. Philip: What is the criteria by which some track attributes are exposed and not others, i.e. why should 'language' and some 'kinds' be exposed and not other 'kinds'? How would the application tell the difference between an "en" "forced" track and an "en" "subtitle" track, if both are exposed as "en" "subtitle"? I appreciate your patience.
(In reply to Pierre Lemieux from comment #49) > (In reply to Philip Jägenstedt from comment #48) > > > > (In reply to Pierre Lemieux from comment #41) > > > Ian: Per Eric and Silvia's comments, "forced" timed text is a different kind > > > of timed text than "subtitle" timed text. The changeset at > > > http://html5.org/r/8500 states "if [...] this is a forced subtitle track". I > > > do not see how this "if" test can be evaluated if there is no "forced" kind > > > and the track not labeled as such. > > > > This information is available internally even if it is not exposed in the > > API. > > Philip: What is the criteria by which some track attributes are exposed and > not others, i.e. why should 'language' and some 'kinds' be exposed and not > other 'kinds'? I think Hixie can answer this better, but generally compelling use cases and implementor interest are a good start. In this case the use case is on the rare side and implementor interest unclear apart from Apple, so it makes sense to be restrictive with adding things that are hard to later remove/change. > How would the application tell the difference between an "en" > "forced" track and an "en" "subtitle" track, if both are exposed as "en" > "subtitle"? > > I appreciate your patience. Assuming that the application is "something using the TextTrack API" then it can't tell for sure why a particular track has been enabled by the UA. Given that forced tracks are supposed to be enforced by the UA, does this matter?
(In reply to Philip Jägenstedt from comment #50) > Assuming that the application is "something using the TextTrack API" then it > can't tell for sure why a particular track has been enabled by the UA. Given > that forced tracks are supposed to be enforced by the UA, does this matter? How is a UA supposed to identify a forced out-of-band text track so it can enforced it without kind=forced or the equivalent?
(In reply to Philip Jägenstedt from comment #50) > Given > that forced tracks are supposed to be enforced by the UA, does this matter? Ok. If the UA is responsible for activating timed text tracks, then the algorithm has to be more substantial than in http://html5.org/r/8500 to ensure that "forced" tracks are in fact (a) reliably detected and (b) reliably activated in the right conditions, otherwise movies such as Avatar will not work reliably or require burned-in subtitles. Happy to put together a concrete proposal.
(In reply to Eric Carlson from comment #51) > (In reply to Philip Jägenstedt from comment #50) > > Assuming that the application is "something using the TextTrack API" then it > > can't tell for sure why a particular track has been enabled by the UA. Given > > that forced tracks are supposed to be enforced by the UA, does this matter? > > How is a UA supposed to identify a forced out-of-band text track so it can > enforced it without kind=forced or the equivalent? An extra bool on TextTrack that isn't exposed to scripts, I guess. If it were exposed, what would scripts do with the information? Is the spec change Hixie made good enough for WebKit, or will you just stick with kind=forced?
(In reply to Philip Jägenstedt from comment #53) > (In reply to Eric Carlson from comment #51) > > (In reply to Philip Jägenstedt from comment #50) > > > Assuming that the application is "something using the TextTrack API" then it > > > can't tell for sure why a particular track has been enabled by the UA. Given > > > that forced tracks are supposed to be enforced by the UA, does this matter? > > > > How is a UA supposed to identify a forced out-of-band text track so it can > > enforced it without kind=forced or the equivalent? > > An extra bool on TextTrack that isn't exposed to scripts, I guess. If it > were exposed, what would scripts do with the information? > > Is the spec change Hixie made good enough for WebKit, or will you just stick > with kind=forced? I don't think the spec change is adequate because it doesn't give script authors enough information. For example, the default track selection UI doesn't include "forced" tracks because they are enabled/disabled by the UA.
(In reply to Philip Jägenstedt from comment #48) > (In reply to Pierre Lemieux from comment #41) > > Ian: Per Eric and Silvia's comments, "forced" timed text is a different kind > > of timed text than "subtitle" timed text. The changeset at > > http://html5.org/r/8500 states "if [...] this is a forced subtitle track". I > > do not see how this "if" test can be evaluated if there is no "forced" kind > > and the track not labeled as such. > > This information is available internally even if it is not exposed in the > API. I don't agree. Where is the information that this is a "forced subtitle track" available for a WebVTT file? As for in-band tracks: the browser may know that a text track is a "forced subtitle track" and may turn it on by default, but how is the JS developer to know?
(In reply to Philip Jägenstedt from comment #53) > If it were exposed, what would scripts do with the information? Write their own custom video controls and their own custom track activation logic.
(In reply to Silvia Pfeiffer from comment #56) > (In reply to Philip Jägenstedt from comment #53) > > If it were exposed, what would scripts do with the information? > > Write their own custom video controls and their own custom track activation > logic. OK, sounds like ignoring forced tracks in custom UI is the main problem.
(In reply to Philip Jägenstedt from comment #57) > (In reply to Silvia Pfeiffer from comment #56) > > (In reply to Philip Jägenstedt from comment #53) > > > If it were exposed, what would scripts do with the information? > > > > Write their own custom video controls and their own custom track activation > > logic. > > OK, sounds like ignoring forced tracks in custom UI is the main problem. Not ignoring, but controlling. Also, a second problem is that we can't currently author <track> sourced tracks as forced tracks.
https://github.com/whatwg/html/issues/4472