The above patch is merged and the staging site updated. Ready for QA.

I'm in favour of removing the uploading of graph images as wiki files (e.g. this patch, which would solve this issue too I think.

I've made a patch for this, but if we were to stop uploading graphs as images then this wouldn't be required at all. This is being discussed at T215391: Graphs are constantly being regenerated, no matter what.

I'm not sure that such tags are needed - isn't the potential copyright violation log created by this extension? Thus, aren't all entries in that log made through page curation?

You were quite right Dom, that was the issue. But even escaping the quotes didn't make epubcheck happy:

We could also have the badge be a count of talkpage messages, if that's of any use.

This is now ready for review. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/521445

Sure thing. We could add an extra badge at the bottom corner, e.g.:

You mean, like the red number bubble that indicates possible issues? There's nothing like that at the moment.

I think the styling of the info flyout has changed a bit since this issue was created. The above patch looks like the following; is it okay?

WiP PR: https://github.com/samwilson/embed-wikimedia/pull/2 — still needs better icons, and to figure out what the best UI is for each embed type (Commons, Wikidata, and Wikipedia).

This issue is not yet resolved. https://github.com/wsexport/tool/pull/184 still needs to be reviewed and merged.

Sorry! I hope I didn't stuff anything up! I opened this ticket and figured it'd go to you and whoever else is helping, and then didn't hear anything for 6 hours so figured you were all asleep and that I might be able to help (after Lego reminded me that I had access to do so). I hoped I wouldn't be stepping on anyone's toes, but I think probably just when I was thinking that was when you were doing the upgrade.

I forgot that I have access to this new instance.

In T210050#5316081, @Quarz wrote:

In T210050#5315880, @Samwilson wrote:

Firstly, I've made changes on our server so that URLs with wrongly encoded apostrophes and parentheses as in the 37 Toodyay URLs are now handled and redirected.

Thanks a lot! Wouldn't it be better not to handle every single special character but to generally run an urldecode? In German, for example, we also need äöüÄÖÜß. Accents are also needed (French, Danish...).

Jo Brook (WMUK) has been working on the site, and perhaps fixed this also. See my comment on T210050.

Jo Brook, working for WMUK, who I don't think is active on Phabricator, sent the following email today:

@mike42 you probably can help with this, if you've got time?

Challenge accepted: I'll try to emblockify the plugin, and @Prtksxna has even volunteered to help with the design of the block's interface. :)

Yes, that plugin can be used to display Commons files in WordPress, by just putting the whole Commons File-page URL on a line of its own in a WordPress post. It currently gets metadata via https://tools.wmflabs.org/magnus-toolserver/commonsapi.php but I've been meaning to update it to use WikibaseMediaInfo.

That's a good point, thanks @osorio-juan-microsoft.

This is merged and on the staging site. There's no real QA required other than keeping an eye out for anything completely not working any more. There may be some changes in error display for some types of error.

This has been merged, and is live on the staging site ready for QA. The book Les_Merveilles_de_la_science still doesn't work though, because it times out; that's better than failing I guess.

Thanks!

qrwp.org without any subdomain or path is meant to redirect to enwp main page, so that's good. It seems that URLs like https://fr.qrwp.org/Trait%C3%A9_de_Paris_(1815) are redirecting correctly (although with the extra-slash problem described in T214268).

PR: https://github.com/wsexport/tool/pull/189

I've created T226789: Add a #pagetriage revision tag to every edit made by the PageTriage extension

PR: https://github.com/wikimedia/svgtranslate/pull/124

Two PRs, because i18n updates are not compiled to public/assets when they're merged:

1. https://github.com/wikimedia/svgtranslate/pull/123 — i18n updates.
2. https://github.com/wikimedia/svgtranslate/pull/122 — this is the one for this issue.

Thanks @JHedden I should have thought of that!

I think it may have become more urgent because new members have joined the chapter and it's not possible for the list admins to add these new members to the list. Does this qualify for increasing the priority?

I think this is now fixed and working everywhere.

It looks like it's this (unresolved) Guzzle bug, but we can maybe work around it by using a request Pool (which by default is limited to 25 concurrent requests). I've made an example patch: https://github.com/wsexport/tool/pull/186

I'm not sure there is an issue with confusing YYYY-MM with a date range, because this seems likely to be only about using this in a place where we expect a single date.

Oh, I think awstats only generates for completed years and months. So the 50x error counts are as follows, for completed months this year:

Thanks @MusikAnimal that's great. Lots of our tools suffer from the 1- to 9-minute outages, so if we leave them out we get the following counts of longer ones:

If we go with the revision tag idea, it'd of course only be possible to show talk page feedback added since this new feature becomes active. Is that okay?

A preliminary patch, to make it possible to have custom config for tests, is https://github.com/wsexport/tool/pull/185 — it's ready for review.

PR: https://github.com/wsexport/tool/pull/184

I think adding a new large instance to that project would be sufficient. It's still got space:

When the toolbar is turned on, it makes an API request to get the metadata about the page, but the pagetriagelist endpoint doesn't return info about pages that aren't in the queue. So we have the option of either extending that endpoint (e.g. with an additional includeall flag), or having the toolbar make a second request to get the missing metadata (it's looking for creator, creation date, redirect status, etc. — all the ones that are independent of the review queue). This metadata is mainly used on the 'info' flyout tab, as well as for e.g. leaving comments for the page creator. It then uses other PageTriage API endpoings such as pagetriagetagging to submit the data, and these also only work for pages in the queue.