To be deployed Monday, July 4. The pull request isn't merged yet but everything works, I just want to do some finishing touches first and I won't have time until next week.

Bumping the Node dependencies (which was necessary on my machine since my Node 11.x is busted) turned into a rabbit hole, hence the 3 point estimate. Anyway the PR is now ready for review: https://github.com/wikimedia/WhoWroteThat/pull/170

Sooo sorry this took so long to review :/ The PR is merged now and we'll be issuing a new release soon. Thanks for both identifying this issue and fixing it, Ed!

I think the backend bits were basically done with T310140: Create action API endpoint in Phonos. The only thing left now is to add the configuration setting to change which engine the extension uses. Thus, perhaps it makes sense to merge this into T311234: Create Larynx phonos engine? The reason being, we'll need a way to change the code to use the Larynx engine, so we might as well do that via configuration setting.

It's worth mentioning that installing MediaWiki extensions via composer isn't well-supported (T250406). This is probably why so many of them aren't published and lack the necessary properties in composer.json.

For global contributions, you may wish to use https://xtools.wmflabs.org/globalcontribs since it supports IP ranges. But for single IPs, some may prefer GUC. On that note, ideally we'd expose these links with an interface message so that the community can change them as desired.

I just tried this and the subpages exported for me. I see that T293708 (which was filed around the same time as this task) similarly somehow resolved itself. Assuming the same is true here I'm going to mark this as resolved. Please re-open if you're still experiencing this issue.

Further to the above, I ran a query to see how many transclusions of IPA templates there are that don't have community-recorded audio already:

SELECT COUNT(*)
FROM templatelinks
WHERE tl_title LIKE "IPA-%"
  AND tl_title NOT LIKE "%/%"
  AND tl_namespace = 10

which comes out to 124,854; minus the 17,858 with audio already (by counting at transclusions of Template:IPA audio link) we have 107,269 possible audio files. This data is just for English Wikipedia.

I had created https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Phonos/+/805871 for this but after the Collab Session today, I understand that's not the route we're going. Since the parser tag is already there, I think this can be closed now. There's nothing to QA yet so I will just mark as resolved. I'll also assign this to TheresNoTime since she and Sam did most of the work.

WikiWho (which powers Who Wrote That?) is now hosted and maintained in-house, so it is possible to extend it to other namespaces. However the storage requirements are massive: the enwiki mainspace alone consumes 2.5 TB. It would be neat to add more namespaces but this would be very costly and with questionable benefits, seeing as most are only interested in the mainspace. It would be better to reserve extra storage for additional language editions.

It's a CSS problem that's definitely fixable I just never gave it much thought. With two bug reports now filed, I shall give this another go :)

All set! The redirect is no longer served by https://eranbot.toolforge.org/ but rather https://copypatrol.toolforge.org/ithenticate

I've managed to build this into CopyPatrol and will have this working soon. Since it took a little time I'm going to move into CommTech's sprint.

In T309816#7977815, @Diannaa wrote:

The "Compare" feature and Earwig's tool (https://copyvios.toolforge.org/) cannot see behind paywalls. If the user has copied from a journal article or a website that's behind a paywall, we can't see the overlap or assess the case without the iThenticate report.

The eranbot webservice has not been migrated to Strech or moved to Kubernetes (T306888). I tried to do this just now but am not having luck.

I had serious issues running the EditPage tests locally, which meant I wasn't able to write any tests.

In T265716#7898610, @TTO wrote:

Just in case anyone is wondering, I have a completed patch for this, but I had serious issues running the EditPage tests locally, which meant I wasn't able to write any tests. I idled in some of the above mentioned IRC channels for a few days but spotted precisely 0 active humans in any of them, which didn't really make me feel very welcome.

Merging into T307725 to keep the discussion centralized.

In T307838#7911446, @JJMC89 wrote:

I've applied the below hotfix and restarted the enwiki job.

…

To be clear, this task is (or was) about research around deploying WikiWho to WMF production. I left my summary at T293386#7715345. With the VPS instance performing swimmingly, I don't think this task is high-priority and it could even be closed, assuming no one has any plans to work on this effort further (CommTech does not). We do want to add more languages to our WikiWho installation but that can be done with the existing VPS infrastructure.

In T268163#7928743, @Prtksxna wrote:

@MusikAnimal from your experience, do you think it’d be useful to have the number of edits and actions separately, as in (2 edits/3 actions)? Or is it ok to bundle them together, as in (5 edits/actions)?

Could this also use https://meta.wikimedia.org/wiki/Research:Wikipedia_clickstream to find the articles where users ended up at [[Help:IPA]]?

Same as T309569, which is a side effect of T60674. If it is still broken now it will be fixed soon. There's nothing we (XTools developers) can do, unfortunately.

We now have our own WikiWho installation, so it's theoretically possible that we could expand it to other namespaces, but this is extremely unlikely to happen. The storage needed just for the mainspace is massive (~5 TB across all languages we support) and adding the userspace alone would have a significant toll. Better we reserve that storage for adding other language editions. The mainspace is what most are interested in, so I don't foresee it being expanded beyond that. Most revisions on userspace pages are going to be the same author anyway. Sorry, we will have to decline this.

Discussed on slack, related to a $wgNamespacesWithSubpages config change — not unexpected behaviour for this change then :)

A bit unexpected in my opinion. But nothing I changed. Not sure if I need to fix something here

Good news! We have had 1 million credits added. We are still in talks to negotiate a longer-term partnership, so I'm still going to keep this task open. But, for the time being, we should be all set for the next year or so. I have re-enabled the bot for French and Spanish. The other languages as mentioned above (T305318#7861775) have been retired since no one is (or recently was) using them regularly enough to warrant the number of credits consumed.

This is finally done! I just double-checked and no remaining tools (except for unrelated jobs for erabot, see T306888#7931423) have webservices or cron jobs on the grid that aren't at least running on Buster. I don't think this needs QA; the fact the tools are up and running is enough. I'll just go ahead and mark as resolved.

I've simply set the cron job to run on buster and all seems to be working fine. I'm going to hold off on moving it to the copypatrol account for now. The current installation seems to have lots of relics and unused code, etc., and it's unclear what we need and what we don't. @JJMC89 has expressed interest in taking on T293688: CopyPatrol: port Plagiabot to Python 3 by rewriting the bot from scratch. I think that would be the better time to move it to the copypatrol account.

If it retries, I'm guessing that means it's another N hours before it auto-kills again. I suppose I can just cut the timeout in half to compensate. Alternatively, we might be able to have a separate job that runs toolforge-jobs delete [job name]?

So the basic concept here is to:

One of the goals for introducing the limited width was Establishing a common reading experience. Bearing that in mind, I'd like to suggest - let's maybe consider making the editor window appear in full width while keeping the non-live preview above it in limited width?

https://mwstew.toolforge.org/ may make this easier

This also breaks Event Metrics. Has anyone other than @Marostegui attempted to rebuild the view? Or could we try again? :)