W3C home > Mailing lists > Public > www-international@w3.org > October to December 2015

[Bug 28255] [webvtt] no provision for indicating overall content language(s) [I18N-ISSUE-420]

From: <bugzilla@jessica.w3.org>
Date: Fri, 02 Oct 2015 09:00:51 +0000
To: www-international@w3.org
Message-ID: <bug-28255-4285-mmQozTLzqo@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28255

nigelmegitt <nigel.megitt@bbc.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #13 from nigelmegitt <nigel.megitt@bbc.co.uk> ---
Asset management databases are like search indexes - they're very useful but
shouldn't be relied on as a permanent record of the content. The general
experience with asset management is there should always be an alternative
mechanism to recover asset information in case the database cannot be relied
upon.

>From http://www.w3.org/TR/html5/embedded-content-0.html#the-track-element :

> The srclang attribute gives the language of the text track data. The value must be a valid BCP 47 language tag. This attribute must be present if the element's kind attribute is in the subtitles state. [BCP47]

> If the element has a srclang attribute whose value is not the empty string, then the element's track language is the value of the attribute. Otherwise, the element has no track language.

So even if there is no asset management system, anyone wanting to publish a
WebVTT file in a track with @kind="subtitles" is forced to derive the main
language from some external knowledge. Since the language in the case of
@kind="subtitles" is expected to be different from the main media language
there may be multiple WebVTT files to publish. Having no standard mechanism to
derive the language of each file is a huge hole in the spec in my opinion. This
is a practical point not an academic one.

Additionally, I've proposed a very simple solution that will not break existing
implementations, so on that basis I'm reopening this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 2 October 2015 09:00:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:09 UTC