Please don't forget to add projects to your task :)

Thank you!

Hi @Yukichi99. Thanks for taking the time to report this!
This particular problem has already been reported into our bug tracking system as T55926, but please feel free to report any further issues you find. Further handling of the reported issue happens in T55926.

Example:

This text on https://commons.wikimedia.org/wiki/TimedText:Knowledge_for_Everyone_(no_subtitles).webm.ja.srt is explicitly broken in the source over two lines:

00:00:56,818 --> 00:01:03,528
そして、ウィキペディアへの無料のアクセスを実現する嘆願書にサインして、
私達と共に声をあげるよう、お誘いしたいと思っています

The displayed subtitle (at least as tested in Chrome) combines the lines together as one, then re-breaks them in a less convenient place:

So here's what seems to be happening:

• TMH's TimedText plugin fetches the blah.srt page from the wiki's API with an action=parse
• so, it receives the HTML of the .srt source text *processed as a wiki page*:
  • double-newlines in source become <p> breaks
  • single-newlines in source are removed
• mw.TextSource processes the HTML it's received:
  • removes all elements "for security reasons"
  • processes through the now-plaintext file...
  • if there were multiple lines in a single subtitle entry, it would put a <br> between them, but this can't happen because of the processing above

@TheDJ is of the impression that this was originally using action=raw and plaintext, and it was changed to use wiki parsing to enable some formatting, but that was disabled for security reasons, so we seem to be left with an unnecessary parse operation.

Unless templates are used *in actual subtitle text* it should be safe to switch these back to action=raw, which should get the line breaks working again, simplify processing, and improve performance.

Some TimedText pages containing templates (not all)

Some TimedText pages containing links (not all)

Example using internal links, fullurl links and italics: https://commons.wikimedia.org/wiki/TimedText:The_Impact_of_Wikipedia_Adrianne_Wadewitz.webm.it.srt

Change 231771 had a related patch set uploaded (by TheDJ):
[WIP] Do away with wikitext parsing in Timed Text

https://gerrit.wikimedia.org/r/231771

Change 231771 abandoned by TheDJ:
[WIP] Do away with wikitext parsing in Timed Text

https://gerrit.wikimedia.org/r/231771

Hi, any update on this? I just spent a painstaking amount of time subtitling a 40-minute video, using this website called Amara, and it reccomended I limit lines to 42 characters, so I went and broke up each line accordingly, only to find that the video player doesn't preserve line breaks... Not only does it become a readability issue, this also makes some lines very confusing, because it's a convention in subtitles when multiple people are speaking to format it like this:

– First person's speech
– Second person's

and now it just displays like:

– First person's speech – Second person's

making everything jumbled. Other players like VLC do keep line breaks.

Unfortunately, there is currently no one working on anything related to the video player and it's subtitles.

I'll be picking up some more of these bugs soon -- not sure if there's an easy fix on the current system, but the new frontend should be nicer to the original subtitle formatting. (However it may require manual adjustment of subtitle files that don't render correctly. I'll post some guidance when I'm closer in.)

Change 232214 had a related patch set uploaded (by Brion VIBBER; owner: Brion VIBBER):
[mediawiki/extensions/TimedMediaHandler@master] Subtitles served through API, with WebVTT conversion

https://gerrit.wikimedia.org/r/232214

Change 232214 had a related patch set uploaded (by Brion VIBBER; owner: Brion VIBBER):
[mediawiki/extensions/TimedMediaHandler@master] Subtitles served through API, with WebVTT conversion

https://gerrit.wikimedia.org/r/232214

Change 232214 merged by jenkins-bot:
[mediawiki/extensions/TimedMediaHandler@master] Subtitles served through API, with WebVTT conversion

https://gerrit.wikimedia.org/r/232214