@dom_walden Thanks, those are useful examples. I think you're right, it should be paginated. For most cases, there will only be one page required, so it won't be any worse performance.

I've updated the patch above to the 4px/6px padding, and kept the space between them.

Done.

Removing myself as assignee as I don't maintain this project.

@AFZL210 Go for it! Assign this task to yourself, then prepare a patch and send a pull request (link it here).

I'm not able to replicate this bug. It looks like $wgPhonosIPARenderingEnabled = false; works as expected already, for Wikibase-retrieved ipa values.

@JSengupta-WMF Is the difference in capitalization between the tooltip and the legend intentional?

The above CSS fixes are included in 2.11.1 which I just tagged. It'll be live on the site shortly.

Actually, I was thinking the opposite: that it does make sense to track the usage, even though it's wrong. Because if someone's trying to use a jpg as an audio file, it's still a usage and is useful to know when e.g. deleting that file (or whatever).

(Sorry, I didn't mean a duplicate of that issue, but caused by it.)

In T332125#8696916, @Bennylin wrote:

And what does it mean by

Please download the content and pass it in.```?

I've made a PR for adding these new styles to the default WS Export stylesheet: https://github.com/wikimedia/ws-export/pull/450 (ready for review).

I think it'd be fine to not add any extra styling, if that's easier for now.

Ah right, yep, that sounds good. It does feel a bit sad to mark something as not backwards-compatible where actually it might be, but that's definitely better than saying it is compatible where it's not!

I'm not quite sure I'm understanding: so the required MediaWiki version number will be bumped in the release branches, but not in the master branch? Or will it be bumped in the master branch just before cutting a new release branch?

Sounds good! Have a go at adding this feature, and send a pull request on GitHub, and we'll review it.

@Sohamdas07 Thanks for your interest! To get started, you first need to download the code and get it running in your local development environment. How familiar are you with PHP development?

It looks like there's slightly variable handling of directionality when an inline block is next to an inline element (like the label and icon are, within the anchor). One fix is to make them both inline-block.

UptimeRobot reports that the tool was down for 84 hours and 22 minutes.

There was an empty job.json file, presumably which was written when the volume filled up and so couldn't have its contents added.

The error is:

@Lens0021 thanks for pointing this out, and making the fix! I've moved the array-fixing to be in PHP in the above patch, although I'm not sure which side it makes most sense to put it (it's perhaps easier to write tests for PHP in the current set-up, which is why I put it there).

In zhwiki, “MediaWiki:Template-protected” message displayed as wikitext when previewing, not parsed as HTML. Seems to be the same problem?

Thanks @GMikesell-WMF that's terrific. I've made a patch for the first issue (which is related to the margin etc. when phonos is the first thing on a line). Will follow up with the others soon.

Thanks for reporting this @Nux.

The actual issue at hand is solved manually via https://ban.wikisource.org/wiki/Kusus:GadgetUsage but the issue of the view not existing remains valid.

It sounds like the model is going to be made public, so the first part of this isn't required.

Document process people should follow to switch from the old user script to gadget.

@Nardog I think your suggestion of "Play audio" is good.

I've been getting this issue too.

I'm not sure I understand. Would this be an API for getting descriptions of the local wiki (i.e. UnlinkedWikibase would provide {{SHORTDESC:}} and a means to fetch it), or a way for modules on the local wiki to retrieve the short descriptions of e.g. Wikipedia pages that are linked to Wikidata?

Stalled pending resolution of remaining work on the tool.

Yes, absolutely, you're both right. I didn't mean to rush ahead here! I was just looking into it briefly and thought I'd upload the patch just for interests' sake. Nothing will be done till we're actually sure we want to do it! :-)

@JSengupta-WMF Thanks. And just to confirm: we are aiming to match the skins' default link focus styles, and not the OOUI button focus style?

It sounds like adding a new hook at the top of the toggle() method will make this possible to fix in the gadget. I suggest mw.hook( 'ext.WikiEditor.realtimepreview.toggle' ).fire( this );.

It sounds like the above changes haven't done anything to this bug. I'm still not able to reproduce it.

That old task T41577: Toolbar shouldn't appear in view source if page is protected was also talking about the RefToolbar gadget on enwiki, which is what was allowing it to insert text in the protected page. WikiEditor when enabled on protected pages doesn't allow anything to be changed in the textbox (or rather TextSelection, which is used by WikiEditor and CodeMirror, doesn't).

The tool is for exporting in formats like EPUB or PDF. It is not for "editable" formats like ODT.

There's also the QRLite extension which can be used to embed QR codes in wiki pages.

Dom pointed out another issue here (from T327354#8620988):

Thanks @dom_walden and @GMikesell-WMF those are all great points.

is this what you are talking about with the italics on the redirects that should be continued?

Good catch, thanks! This is because the restriction-level-templateeditor message is not available on the front end, so needs to be loaded separately.

The most-tokened tasks are listed here: https://phabricator.wikimedia.org/token/leaders/ (it's not possible to filter by project; T302850 is for that).

Since upgrading to 1.39 this is no longer happening, and live preview works as it should.