@Aklapper I assume backticks (i.e.`<input>`) will do. Compare the section for simulateLabelClick() and the corresponding source.

@Aklapper Is it clearer now?

Thanks, that makes sense. Looking forward to anchors on modules.

Then why not make sure such anchors are not used in existing Lua documentation, or use a unique enough prefix to avoid conflicts in the first place? It still makes little sense to leave out Scribunto because if line number anchors are going to be most useful on any type of pages, it must be Lua modules.

In T29531#6728446, @Esanders wrote:

@Johan, correct.

@thiemowmde Alright, created T270774: Wrong curid and title (tooltip) in grouped category changes on Watchlist/RecentChanges.

It seems this has been quietly resolved. Now categories with grouped changes are followed only by the plain text "(n changes)", no "history" link. Can someone identify the commit that implemented this change and close this task?

I can't reproduce this; now categories with grouped changes are followed only by the plain text "(n changes)". Can someone identify the commit that implemented this change and close this task?

This is good news.

Now the link text "WikiLove" is clipped when collapsed inside "More".

#ca-wikilove.icon a

should probably be

#p-views #ca-wikilove.icon a

This may be too trivial for Tech News, but at least the fact live diff now works for user CSS/JS is noteworthy, I think.

I've written a user script that effectively achieves this. Still it would be nice if it was supported natively in wiki syntax, perhaps via a MW extension.

@Pppery Jinx! :D

@Tgr Can you clarify what the behavior should be? That user CSS/JS will preview the normal, non-Ajax way even if live preview is turned on in Preferences, even after the first time?

In T260500#6456383, @Ammarpad wrote:

The entire page reloads just like the first time...

That initial reload is not intentional itself, see T186390

By the way, I've never really understood the point of preventing the live preview when viewing a diff, not a preview, of a user CSS/JS. I've find it a bit annoying when I want to simply check the diff and the entire page reloads.

@Tchanders Wow, thanks a lot!

@Tchanders Can you take a look at this?

@Xaosflux The request is to add an extra help button next to the already existing "Thank" and "Cancel", not within the existing message like I proposed on enwp. "Send thanks (help)?" was originally suggested as a compromise of the option I'm requesting now after it was pointed out that adding an extra button would involve a change in the software. But now that we know the compromise would also require a change in MediaWiki anyway, why not go for the original (and better, if you ask me) option?

What would also be nice: an ability to pre-select (or opt out) the CC in [[File:...]].

That's exactly what I meant by "like these".

@Xaosflux:

there isn't likely a good "help" target to put in to the code on this one, but if it processed wikitext projects could add their own help links

What do you mean? What's wrong with linking to mw:Help:Notifications/Thanks?

According to SharabSalam on Wikipedia VPT:

T20852 hasn't really solved this issue because you still can't play MIDIs inline. The problem is not unique to MIDI, however, because not all browsers support all of the audio formats Commons accepts, especially Ogg/FLAC/Wave/WebM. Servers transcode them into Ogg and MP3 to fill this gap but the derived files cannot be linked to via a method like [[Media:...]] or {{filepath:...}}, while {{Audio}} remains to be one of the most common ways to refer to an audio clip on Wikipedia.

JFYI, there were files with the MIME type "audio/mid" on at least jawp, ltwp, slwp, and srwp.

Purging 21 files wouldn't be hard I don't think.

Those files are all from 2006 or earlier. There are no files with "audio/mid" on Commons, for example. It could be the case that it is the MIME type of those files on English Wikipedia that needs to be fixed, rather than the MIDI conversion not supporting such a peculiar MIME type.