Page MenuHomePhabricator

TMH audio player missing for clips inside <indicator>
Open, Needs TriagePublic

Description

The "Spoken Wikipedia" template on Dutch Wikipedia (nl.wikipedia.org) features an audio clip with small player through which the user can read to a spoken version of the article. This is similar to the "Featured article" and "Coordinates" indicators found on other wikis.

The template is at https://nl.wikipedia.org/wiki/Sjabloon:Gesproken_Wikipedia_klein and still uses the legacy JavaScript/CSS hack which requires Common.js hacks to eject the element from the page content and move it around (after page load) to the page header.

This is what <indicator> is for, but it seems that when trying to convert it to that syntax, the TMH player is no longer applied.

When editing the template, and switching it to <indicator>, and then previewing it on an article results in the following:

Event Timeline

Krinkle created this task.Wed, Aug 14, 11:07 AM
Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptWed, Aug 14, 11:07 AM
Nirmos added a subscriber: Nirmos.Wed, Aug 14, 12:21 PM

Maybe the TMH JavaScript is scoped to #bodyContent or #mw-content-text?

brion added a comment.Wed, Aug 14, 1:07 PM

Can you create a copy of the template that uses the form that fails? I'm uncertain what to modify from the description.

brion added a comment.Wed, Aug 14, 1:15 PM

Looking at the TimedMediaHandler JS, it uses the wikipage.content hook which passes a jQuery object holding the content area in which to process elements. Anything outside the content area is not processed.

You can force a new player to process individually without regard for being in a wiki content area but it's a little funky and the API's not stable.

Maybe something like:

if ( mw.processEmbedPlayers ) {
  // For the old code, still deployed for most people
  mw.processEmbedPlayers( $( '#my-audio-element' ) );
} else {
  // For the new code, available through beta feature
  $( '#my-audio-element' ).loadVideoPlayer();
}

and that assumes the relevant modules are loaded, which are also unstable and changing. Hmm, a consistent API would be good here. :D

brion added a comment.Wed, Aug 14, 1:43 PM

Or... perhaps MW should run wikipage.content against the contents of <indicator> as well?

Krinkle added a comment.EditedWed, Aug 14, 2:32 PM

Aye, that's the underlying issue indeed.

This affects all hook-triggered enhancements, in all places that aren't the main body content.

Such as sortable and collapsible tables inside indicators), albeit unlikely (but never say never...).

Or sortable content inside a DISPLAYTITLE.

TMH is probably the only enhanced feature one realistically use in an indicator, though, hence the one we found first.

I'd rather not make the the wikipage.content hook feature aware of the indicators feature explicitly. But, we might be able to work with a common class name. Such as mw-body-content or (ideally) mw-parser-output. Except the latter isn't set for indicators currently.

I wonder if this means TemplateStyles don't work in indicators either?

brion added a comment.Wed, Aug 14, 2:50 PM

Since AFAIK extensions are meant to use wikipage.content for setup, I think any area where wikitext features are expected to work _should_ trigger the hook... A common class name would still require knowing when to run setup, and potentially one might want to update the indicator (what happens during edit preview?). So we either have to add a second hook that does the same thing as wikipage.content but is explicitly scoped to non-primary areas, or ...? Hmm, bears further thought.

I wonder if this means TemplateStyles don't work in indicators either?

Well, you would have to add the mw-parser-output class yourself for it to work. See T37247, https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/352835/ and T188443.