[Bug 10320] [WebSRT voice] Allow an arbitrary string as the voice for forwards compatilbity

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10320

--- Comment #18 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2010-10-14 07:49:41 UTC ---
(In reply to comment #17)
> At this point I'm leaning towards replacing the voice mechanism with <v foo>,
> where "foo" is any character name or other appropriate voice identifier. I
> think it might make sense to drop the hard-coded ones like <sound> and
> <narrator> and just have them be voices too, as in <v sfx> or <v narrator>. The
> <v foo> construct would only be allowed at the "top level" of a cue, and the
> </v> would be optional if the <v> was the first thing in the cue.


That seems to be more akin to the role of <span class="blah"></span> in HTML. I
think I like it. I also wonder if calling it "voice" may be too specific and it
should just be a region marker, maybe <m foo></m> ?


> I am not sure it makes sense to have the same timed track for captions and
> subtitles, that seems like one of those things that sounds clever to software
> engineers like us but in practice is not that great (case in point, as far as I
> know it's never been done before). We could, though, in the future, introduce a
> new kind of cue that the browser could then offer either as a subtitle track or
> a caption track, with the subtitle version having certain things hidden and the
> caption track having character names shown in some cases, or some such.
> 
> For the specific example of "<v Mary><sound>cough", in practice most captions
> I've seen would instead use <v desc>Mary coughs</v>" or some such, in italics,
> not the word "cough" in a special colour or anything. But my experience here is
> admittedly limited.

I tend to agree - I think we may be trying to over-engineer this if we shove
captions and subtitles in the same file. If somebody wanted to keep only one
copy in a databases with some extra fields for captions that then help
dynamically create the subtitles and caption files, that would equally deal
with this potential duplication of data.

Another potential approach towards solving this is to allow the @kind attribute
to have multiple values such that we can use e.g. an English caption file both
for caption and subtitle purposes.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 14 October 2010 07:49:44 UTC