Change #1093976 had a related patch set uploaded (by Varnent; author: Varnent):

[operations/mediawiki-config@master] Setting wmgUseTranslationMemory to false for Office Wiki.

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

This issue is about Wikipedia but this would be much more useful for Commons, Also see Talk:Add an AI image filter to MediaSearch. See also this proposal.

I should add a special page to this for searching and then see if I can get any support for deploying it to the Wikimedia wikis. I imagine the slipperiest part of that will be finding a Foundation team willing to provide long-term maintenance support for the extension.

For the Community Wishlist we're adding support for machine translation on Meta. The first part of this is T371098: Providing machine translation for Community Wishlist mainspace pages on demand, which is currently being tested (you can enable the gadget now on Meta). The second part is T371006: Translating comments on talk pages on demand and I'm starting work on that now. It'll be using MinT.

No, I don't disagree that building an extension in this specific case was a reasonable decision. But I've seen so many "build this existing feature as an extension instead" tasks lurking on Phabricator for other features (as this task was when it was created before IP masking stuff made it make more sense) , and consider them to be pointless.

In T28957#10037140, @Pppery wrote:

See also T337089

(Random personal anecdote: this quest to lift things from toolforge tools or templates to MediaWiki extensions has never made sense to me - it is a lot of work and all you have really accomplished is to create an ossified clone)

I started looking at this, initially just for sending webmentions, and it seems like we'll want to add a new database table to track all external URLs. The docs say:

That is a great idea. There are PHP libraries available and several other CMS do already have plugins: https://webmention.net/implementations/
So a WebMentions extension would be a great benefit for many users!

https://www.mediawiki.org/wiki/Extension:UserMerge already does thus.

See also T337089

For Wikimedia wikis we already have https://pageviews.wmcloud.org

https://www.mediawiki.org/wiki/Extension:LifeMarks is archived.

Closing per previous comment.

I disagree with the principle here entirely. The fundamental core of the way MediaWiki works is that people build their own workflows using templates. Moving things off of templates and into PHP code just makes things less flexible for everyone.

https://mediawiki.org/wiki/Extension:CookieWarning has existed for ages.

Nobody seems to want to do this anymore.

Please note any extensions that restricts specific users from viewing specific pages are not bug-proof. See https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions

In T34815#9437885, @Bugreporter wrote:

Simply we can just do so:

• Remove the user row from user table. Now MediaWiki will treat the account as unregistered
• Change the actor_name to something like "Deleted user #123123" so histories and logs now shows the anonymized name, and (optionally?) actor_user to null
• Some table (e.g. user_groups, user_properties) now contains rows that make no sense, and can simply be removed
• Now the user is deleted for good

For non-Wikimedia wiki, this provides a simple way to remove e.g. (1) spam/vandalism only account and (2) account closed on GDPR request.

Does some extensions assumes the existence of a user_id? Check and fix them

https://en.wikivoyage.org/wiki/Wikivoyage:Listing_editor seems to cover everything requested here. MediaWiki-extensions-Listings is being archived and listings are now just template calls so this sort of thing should be handled by on-wiki gadgets not extensions

And https://www.mediawiki.org/wiki/Talk:Moderator_Tools

This is also being discussed https://www.mediawiki.org/wiki/Talk:Growth#c-KStoller-WMF-20240627182400-Alexanderkowal-20240609170800

So was flagged revs giving some users rights to mass revert back to a previous rev? I still don't think I get it lol. Apparently the German wikipedia uses proposed edits unilaterally for new editors, so you might be able to copy that and put it behind a checkbox? The edit history shenanigans may be more technically complex

@Aklapper

Hi, one of the things that inflame edit wars is the binary between published and unpublished. If someone makes an edit that they feel corrects a grave injustice and it is published, they have achieved their goal. If someone reverts that and makes it unpublished, they would receive it as regression and likely respond angrily. Encouraging the use of proposed edits for controversial edits means that that editor has to work with the reverter in order to achieve their goal of getting the edit published, and the process is one constant progression.

Hi @Alexanderkowal, thanks for taking the time to report this and welcome to Wikimedia Phabricator!

Please do not "bump" tasks in Phabricator. Thanks!

I would like to bump this again, just in case anybody out there is still working on these sorts of things.

one could try to fix the current tool, for instance by migrating it to a Cloud VPS instance (as sketched in Wikidata_talk:Edit_groups)

Quick update on this: undoing edit batches on Wikidata via the current EditGroups has been broken for about two months now and the few hours I have spent trying to fix it have not been sufficient so far.