With MultiGadgetRepo, adoption will be gradual with users having full autonomy at the individual gadget level. This means adopting a JSON gadget is as easy as creating the appropiate page (JSON will have precedence over the entry from the legacy definition page). And switching back would involve deleting or moving said page, or changing its content model, so as to not be loaded.

For those interested in implementing this, there is code for a Gadget Manager implementation already, and can be found in the RL2 branch of the mediawiki/extensions/Gadgets repo. This is from the 2011 prototype that @Catrope and myself worked on at the time.

I just undid all reviews by WizardGamer775 (currently 747 edits and 3 months old) directly in the database due to a significant number of them being inaccurate (35%) and/or not having the proper actions taken (20%).

Change 981622 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@master] Introduce MultiGadgetRepo to facilitate repo migration

https://gerrit.wikimedia.org/r/981622

Change 981622 had a related patch set uploaded (by Krinkle; author: SD0001):

[mediawiki/extensions/Gadgets@master] Introduce MultiGadgetRepo to facilitate repo migration

https://gerrit.wikimedia.org/r/981622

Done in the new CopyPatrol (hopefully to be released later this week). There's also "revdel" link for those with the requisite user rights.

We now query the database directly.

CopyPatrol has long had i18n support. This task is about the Copyvios tool.

Any recent progress on this? I recently came back from a hiatus, and I'm still having to manually regenerate a list of all a project's pages for project change patrol purposes. It would be nice to no longer have to do that.

If the community wants this and the WMF works out access to other provider APIs, then this could be reopened.

This is an uninteligible, non-actionable request filed by a long-inactive user. There are plenty of other tasks open in the task tree or elsewhere about global templates/modules. Boldly declining.

I regularly (most days in March) see errors where CopyPatrol reports a 500 error for a few minutes at a time.

I'm not sure if this is still a problem. Boldly closing, anyone please re-open if you feel this still needs attention.

IRC isn't being used currently.

See Synchronizer for a semi-automated tool for solving or mitigating this issue.

Looks like Community-Tech never got around to investigate this, thus declining this task to reflect reality.

Looks like Community-Tech never got around to investigate this, thus declining this task to reflect reality.

Looks like Community-Tech never got around to investigate this, thus declining this task to reflect reality.

In T121470#5638768, @Tgr wrote:

Without raw you get back a HTML blob rendered by a different parser, there is no end to the exciting bugs that could cause (local interface changes would get ignored, for example; links would be blue or red based on whether they exist on the templatecommons wiki). If you prefix all template names with raw:central_wiki_name, they won't work on the central wiki itself (I guess that would be not super hard to fix). It will also break cache invalidation and maybe performance, plus Parsoid would have to be updated to support it. Functionally, this is more or less what the shadow namespace proposal was aiming at (but it was a wishlist item and wasn't finished within the year, so I imagine there must be much more complexity to it than I can see at a glance).

Still the case.