Missing internal file-wide language declaration

[zcorpan]

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=28255#c16

Straw-man syntax:

WEBVTT
lang:en

00:00:00.000 --> 00:00:05.000
Hello world.

The in-file language would be added to the language stack after the fallback language (if any) (see #257), and set on the "list of WebVTT Node Objects" object regardless of the fallback language, so a node's applicable language would be

1. Language of the nearest <lang>
2. Language of in-file declaration (this issue)
3. Language of external fallback language (<track srclang>) Allow external language information to apply #257

Are implementors interested in supporting this?

[zcorpan]

Also note that this addition might need changes to getCueAsHTML() or TextTrack#language, or something else, if we want to expose it in the API. See #258

[dwsinger]

looks like a good idea to me.

On Nov 13, 2015, at 4:39 , Simon Pieters [email protected] wrote:

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=28255#c16

Straw-man syntax:

WEBVTT
lang:en

00:00:00.000 --> 00:00:05.000
Hello world.

The in-file language would be added to the language stack after the fallback language (if any) (see #257), and set on the "list of WebVTT Node Objects" object regardless of the fallback language, so a node's applicable language would be

• Language of the nearest
• Language of in-file declaration (this issue)
• Language of external fallback language () #257
Are implementors interested in supporting this?

—
Reply to this email directly or view it on GitHub.

David Singer
Manager, Software Standards, Apple Inc.

[silviapfeiffer]

WFM.

[foolip]

I'm not so enthusiastic about adding something that is redundant with <track srclang>. If the language isn't available before the track is selected, how would one create a track selection UI? And if the language changes by this mechanism, what should happen?

If any metadata is added, I would prefer that it has no effect at all in browsers, unless these questions have reasonable answers that I haven't thought of.

[zcorpan]

In my mind this would be semantically equivalent to specifying <lang xyz> on every cue, not affecting track selection or UI

[aphillips]

@zcorpan Exactly so. It's a convenient way of saying what language all the cues in the file are in so that you don't have to repetitively mark each <track> etc. with a language. This is especially useful when localizing (translating) the source file, as you only have to make one change to the file.

[foolip]

@zcorpan I see. Could we state this as a cue-level setting and file-wide defaults, perhaps?

WEBVTT

DEFAULT lang:en

00:01.000 --> 00:02.000
English

00:11.000 --> 00:12.000 lang:sv
Svenska

[zcorpan]

Sure.

[foolip]

Great, that WFM, but I'm not wedded to the exact syntax of my example.

[dwsinger]

On Nov 23, 2015, at 7:18 , Philip Jägenstedt [email protected] wrote:

I'm not so enthusiastic about adding something that is redundant with . If the language isn't available before the track is selected, how would one create a track selection UI? And if the language changes by this mechanism, what should happen?

If any metadata is added, I would prefer that it has no effect at all in browsers, unless these questions have reasonable answers that I haven't thought of.

The point is to have self-describing files, so that, given the file, one can write the srclang in the track.

David Singer
Manager, Software Standards, Apple Inc.

[zcorpan]

What problem does that solve? What are the answers to @foolip's questions about track selection and UI?

[lorettaguarino]

The problem it would solve is: given a webvtt file, what value to set the
srclang attribute to when adding it to the web page.

On Mon, Nov 30, 2015 at 11:44 AM, Simon Pieters [email protected]
wrote:

What problem does that solve? What are the answers to @foolip
https://github.com/foolip's questions about track selection and UI?

—
Reply to this email directly or view it on GitHub
#259 (comment).

[zcorpan]

OK, it seems to me that that is already possible with a NOTE block, like

WEBVTT

NOTE Use this markup to include this file in HTML:
<track src="foo.vtt" label="Foo" srclang="en" kind="subtitles">

Not unlike what you would do in JS or CSS. (Case study: https://resources.whatwg.org/file-issue.js )

[dwsinger]

Only if we establish a common practice that people follow; we want tools as well as humans to be able to insert/retrieve it.

I’m not sure what your concern is; if we document it as either (I don’t think we can do both!) of

a) the embedding environment (e.g. the srclang in HTML) overrides it
b) it’s as if every cue that lacks a language declaration were tagged with this language

is there still a problem?

On Nov 30, 2015, at 12:53 , Simon Pieters [email protected] wrote:

OK, it seems to me that that is already possible with a NOTE block, like

WEBVTT

NOTE Use this markup to include this file in HTML:

Not unlike what you would do in JS or CSS. (Case study: https://resources.whatwg.org/file-issue.js )

—
Reply to this email directly or view it on GitHub.

David Singer
Manager, Software Standards, Apple Inc.

[zcorpan]

I'm trying to understand what people want to achieve here, so I can evaluate different solutions. Now I know the bit about tools.

I guess one concern is that if there is dedicated syntax for srclang (and kind etc?) in the file, people will expect browsers to pick it up for the purpose of automatic track selection and showing the UI, which is not possible because the file has not been downloaded yet.

(Case study: <meta http-equiv> in HTML4 was meant for servers to set HTTP headers in the response, but they didn't; browsers ended up supporting that instead.)

[dwsinger]

On Nov 30, 2015, at 13:18 , Simon Pieters [email protected] wrote:

I'm trying to understand what people want to achieve here, so I can evaluate different solutions. Now I know the bit about tools.

That’s all good to me. I also would like to understand!

I guess one concern is that if there is dedicated syntax for srclang (and kind etc?) in the file, people will expect browsers to pick it up for the purpose of automatic track selection and showing the UI, which is not possible because the file has not been downloaded yet.

(Case study: in HTML4 was meant for servers to set HTTP headers in the response, but they didn't; browsers ended up supporting that instead.)

ah, right. we can say that it’s not for that, but those words might not stick.

David Singer
Manager, Software Standards, Apple Inc.

[lorettaguarino]

The problem I would like to solve is that caption files get used in a
variety of tools, e.g., in caption editors or converters as well as when
serving the content. If the file is not self-contained, we need ways of
associating the additional metadata with the caption track as it is passed
around in the workflow. This becomes error-prone quickly.

I'd like this type of metadata available as an option (but not required) in
the file itself, with clear rules that the embedding environment prevails
if there are conflicts, and that it is an error not to provide the required
information in the embedding environment. And I'd like it to be represented
in a way that is consistent so that tools that are generating the embedding
environment from the file can extract that information easily and reliably.

On Mon, Nov 30, 2015 at 1:18 PM, Simon Pieters [email protected]
wrote:

I'm trying to understand what people want to achieve here, so I can
evaluate different solutions. Now I know the bit about tools.

I guess one concern is that if there is dedicated syntax for srclang (and
kind etc?) in the file, people will expect browsers to pick it up for the
purpose of automatic track selection and showing the UI, which is not
possible because the file has not been downloaded yet.

(Case study: in HTML4 was meant for servers to set
HTTP headers in the response, but they didn't; browsers ended up supporting
that instead.)

—
Reply to this email directly or view it on GitHub
#259 (comment).

[silviapfeiffer]

@zcorpan the suggestion below doesn't work when the WebVTT file is read in a stand-alone video player. Think of loading a mov file into vlc and adding its webvtt file. You don't get to provide a track element there.

WEBVTT

NOTE Use this markup to include this file in HTML:
<track src="foo.vtt" label="Foo" srclang="en" kind="subtitles">

The easiest way to provide the track element default settings to a stand-alone player would be to have them as file-wide defaults that the browser ignores, e.g.

WEBVTT

NOTE Use this markup to include this file in HTML:
<track src="foo.vtt" label="Foo" srclang="en" kind="subtitles">
The following defaults are ignored by browsers. 

NONBROWSER DEFAULTS
label: Foo
lang: en
kind: subtitles

This way, you have both, but the browser is bound by the track element settings. (Also, the NOTE above is ignored by ALL players, which it should.) Yes, it introduces some duplication in providing those settings (and possible authoring errors), but we have to be ready for both use cases.

[dwsinger]

On Nov 30, 2015, at 17:13 , Silvia Pfeiffer [email protected] wrote:

@zcorpan the suggestion below doesn't work when the WebVTT file is read in a stand-alone video player. Think of loading a mov file into vlc and adding its webvtt file. You don't get to provide a track element there.

WEBVTT

NOTE Use this markup to include this file in HTML:

The easiest way to provide the track element default settings to a stand-alone player would be to have them as file-wide defaults that the browser ignores, e.g.

WEBVTT

NOTE Use this markup to include this file in HTML:

The following defaults are ignored by browsers.

NONBROWSER DEFAULTS
label: Foo
lang: en
kind: subtitles

This way, you have both, but the browser is bound by the track element settings. (Also, the NOTE above is ignored by ALL players, which it should.) Yes, it introduces some duplication in providing those settings (and possible authoring errors), but we have to be ready for both use cases.

Nice.

What does this mean, though?

and foo.vtt says

NONBROWSER DEFAULTS
label: Foo
lang: fr

?

David Singer
Manager, Software Standards, Apple Inc.

[silviapfeiffer]

@dwsinger in the case where the HTML page doesn't have all the information included, it defaults to these not being set. That's an authoring error, just as it is right now.

[zcorpan]

Use cases:

• Should be easy to translate/localize WebVTT files.
• Given a WebVTT file, a human should be able to write appropriate HTML markup for it.
• Given a WebVTT file, a tool should be able to write appropriate HTML markup for it.
• A stand-alone media player, given a video file and a WebVTT file, should be able to set the language/kind/label, for its rendering and UI.
• Roundtrip the language/kind/label, for a variety of tools, e.g., in caption editors or converters as well as when serving the content.

Requirements:

• When the file is used with <video><track>, the in-file declarations should have no effect*.
• When WebVTT is used in-band in a video resource, these declarations should have no effect*. (?)
• The syntax should make it obvious that it has no effect for automatic track selection or UI in browsers, even if the HTML markup does not set the relevant attributes.

*) The language could have an effect on glyph selection and :lang() selector, but not automatic track selection or UI.

Anything else? Did I misrepresent something?

[dwsinger]

LGTM

On Dec 1, 2015, at 5:48 , Simon Pieters [email protected] wrote:

Use cases:

• Should be easy to translate/localize WebVTT files.
• Given a WebVTT file, a human should be able to write appropriate HTML markup for it.
• Given a WebVTT file, a tool should be able to write appropriate HTML markup for it.
• A stand-alone media player, given a video file and a WebVTT file, should be able to set the language/kind/label, for its rendering and UI.
• Roundtrip the language/kind/label, for a variety of tools, e.g., in caption editors or converters as well as when serving the content.
Requirements:

• When the file is used with

Anything else? Did I misrepresent something?

—
Reply to this email directly or view it on GitHub.

David Singer
Manager, Software Standards, Apple Inc.

[lorettaguarino]

LGTM

On Tue, Dec 1, 2015 at 5:48 AM, Simon Pieters [email protected]
wrote:

Use cases:

• Should be easy to translate/localize WebVTT files.
• Given a WebVTT file, a human should be able to write appropriate
  HTML markup for it.
• Given a WebVTT file, a tool should be able to write appropriate HTML
  markup for it.
• A stand-alone media player, given a video file and a WebVTT file,
  should be able to set the language/kind/label, for its rendering and UI.
• Roundtrip the language/kind/label, for a variety of tools, e.g., in
  caption editors or converters as well as when serving the content.

Requirements:

• When the file is used with
• When WebVTT is used in-band in a video resource, these declarations
  should have no effect*. (?)
• The syntax should make it obvious that it has no effect for
  automatic track selection or UI in browsers, even if the HTML markup does
  not set the relevant attributes.

*) The language could have an effect on glyph selection and :lang()
selector, but not automatic track selection or UI.

Anything else? Did I misrepresent something?

—
Reply to this email directly or view it on GitHub
#259 (comment).

[foolip]

That sounds about right, and I agree with "When WebVTT is used in-band in a video resource, these declarations should have no effect" without the trailing question mark.

[dwsinger]

re: "in the case where the HTML page doesn't have all the information included, it defaults to these not being set. That's an authoring error, just as it is right now." We can say that as much as we like, but I am fearful that people will write HTML with no lang declaration and say "but the caption file declares the language" (as we're discussing here for VTT, and TTML already can) and expect it to work. Not sure what to DO about it, though.

[silviapfeiffer]

@dwsinger flag it with a warning or error in a HTML validator?

[dwsinger]

sure, we can and should flag errors; but we may end up having to pave an undesirable cowpath here, which worries me

[silviapfeiffer]

Would you prefer a "flash of change" as the file is selected in the web browser, the file is loaded, and the metadata replaced? It's the only way, bar having to download & interpret the metadata of all vtt files listed for a media file as the page loads, and surely that is a new cowpath that is even less desirable? Best Regards, Silvia.

[dwsinger]

@Silvia -- no, no flashes of change! If someone has an HTML label that says 'greek' and the file itself says 'swahili', well, perhaps the users wanting greek may be surprised; the browser should nonethless show that to the user wanting greek, and hope that the swahili label is a bizarrity.