Last modified: 2010-09-23 17:36:16 UTC
SRT files created by external tools can contain timed text with time intervals containing non-null milliseconds. Example: http://commons.wikimedia.org/w/index.php?oldid=44254955 (created and sync'd with Gnome Subtitles). It is possible to import these SRT files with the current mwEmbed interface enabled on Wikimedia Commons. However, they don't get recognized: they don't show in the list of available subtitles, and they don't show when the video plays. You have to reset all the milliseconds to 000 to make it work: http://commons.wikimedia.org/w/index.php?oldid=44255057 http://commons.wikimedia.org/w/index.php?action=historysubmit&diff=44255057&oldid=44254955 Expected results: subtitles should be recognized and show whether milliseconds are null or not.
I think this bug is related to adding the maxage headers to the request in response to bug 25238 and the 'subtitles missing' being cached for an hour. I have tested milliseconds and they appear to work fine. I have reduced the squid cache to 5 min instead of 1 hour in r73609. Since the action=parse request is for parsing a title it should pull from the parser cache, but we include smaxage headers so that when a video is featured on the 'michael jackson page when he dies' everyone does have to hit the Apaches caches which are relatively resource intensive. In an ideal world the api would understand how to set long squid expires on 'action=parse' for page titles and then purge the squids as the page got updated ( just like we do for normal http page viewing )
