Re: [MSE] Resolving Bug 24370

On Sat, Apr 5, 2014 at 11:55 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Thu, Apr 3, 2014 at 12:20 AM, Jim Ley <jim.ley@gmail.com> wrote:
> > On 2 April 2014 09:26, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
> >>
> >> On Wed, Apr 2, 2014 at 6:04 PM, Jim Ley <jim.ley@gmail.com> wrote:
> >> >
> >> > Isn't the use case for language being mutable simply live subtitles
> of a
> >> > live "channel" that has programmes in different languages and
> therefore
> >> > has
> >> > closed captions / subtitles in different languages.
> >>
> >> Each one of those subtitle languages would be a different track, so
> >> there is no need for mutability.
> >
> >
> > No they're not, some shows are in English, some are in Welsh, the
> subtitle
> > track is a single one for the live broadcast, similarly with audio, the
> > broadcast audio changes languages.
>
> Every show should have its own subtitle track.


That is an operational policy issue that shouldn't be determined by the
technology. For example, TTML explicitly supports the presence of multiple
languages in a single TTML document. The user of TTML decides how to use
it: whether to create different TTML files for different languages, or
whether to merge different languages into the same TTML document (allowing
selection to occur at processing or rendering time).

It should not be construed to be poor practice of a TTML author merges
different languages into the same file, which translates to a single track
using HTML5 mechanisms.

In particular when a
> new language track starts. It makes no semantic sense to put them all
> in the same track. In particular if I am an English speaker and
> suddenly there is a new piece of content and it is on the same track
> that I have continued to watch, but it's in a language that I do not
> understand. Give me the chance to continue having the English track -
> if I want a different language, I will go and pick it. If there is no
> English track availaable, the browser may pick a language track that
> best meets my preferences.
>
> Maybe what needs to be pointed out is that the Web is different from
> TV and that we should not bring poor practice to the Web simply
> because there was no different option do it better on TV.
>
>
> >> I agree, there should be long-running streams. However, that doesn't
> >> mean that there can't be new tracks coming and going. Every time there
> >> is a change in language and a track of that language hasn't been
> >> created yet, there should be a new track. It makes semantic sense to
> >> keep such tracks separate.
> >
> >
> > I can see that argument, but the spec would need to say that instead,
> simply
> > making them non-mutable doesn't meet that use case.  I don't also see it
> > really solving the UA and user issues that were raised as the motivation
> for
> > not having mutable, but certainly it would solve the use cases.
>
> We could add a sentence to the spec clarifying that semantically
> completely distinct entities in a long-running stream should be
> represented by different tracks. That might be the best outcome of
> this discussion.
>
>
> >> Right, the app developer can change the value of the attribute, though
> >> I don't know what the use case would be, since nothing is going to
> >> happen in the browser as a result of this change of value, so it's not
> >> very useful.
> >
> >
> > Well it's very useful if you have built something on top of the track
> > metadata to provide the user with a choice - language and kind is not
> > actually enough for that (how do you identify which is the Audio
> Described
> > version)
>
> @kind actually includes audio descriptions.
>
> > to it will be have to controlled out of band anyway, but the point
> > was, the spec already requires it to not be read only from a track list,
> it
> > doesn't seem to be any value in not having mutable from elsewhere.
>
> I don't follow. I think you're misinterpreting the spec.
>
> >> You misunderstand: right now, nothing happens when the value of
> >> language is changed. However, for the use case of in-band tracks
> >> discussed here, we would need to introduce complicated changes that
> >> have to deal with a change in language - something that is NOT yet
> >> part of the spec.
> >
> >
> > Why?   If the language of a track changes, the language of a track
> changes,
> > you can't say you have to do some UX change for  it when in band when you
> > don't for out of band.  There's no distinction.
>
> Exactly. This is why we don't want to make it mutable.
>
> The UX is the displayed track. If the track that I am watching and
> have selected for watching changes its core properties under me, that
> is really poor UX and is therefore not allowed.
>
> Just imagine a person watching a video with described audio track in
> English activated, because they are blind. Now, suddenly, you change
> that into a "commentary" track in Russian and the user has to go
> hunting for the audio description track in English. I don't think
> that's acceptable.
>
> Hope that helps understanding the issues.
>
> Cheers,
> Silvia.
>
>