With DiscussionTools that integrate the visual editor, I think this is mostly obsolete.

In T407664#11800701, @Sdkb wrote:

Documenting my query about regex flavors: Editors using AWB are used to the .NET flavor and those using Cirrus search are used to a MediaWiki-flavored version. Hopefully we can avoid introducing a third flavor that could cause confusion.

In T190531#4076950, @jeblad wrote:

This table is somewhat foolishly organized, the domain names should be split off from the path, put in a separate column, and the domain name should then be indexed. The table should only be searched for domain names not found in the store, and only for exact matches.

This indeed looks like the same bug. But I am not able to verify if it shares the same cause.

I recall myself making sure the sorting works regardless of the format in 105ec54 (T339149). Does this not work anymore? (It works for me on https://cs.wikipedia.org/wiki/Speci%C3%A1ln%C3%AD:Spravovat_mentory.)

In T421642#11785461, @Xqt wrote:

The problems began on March 25th:

Has anyone already mentioned languages with extensive use of suffixes?

DiscussionTools have mostly dealt with this.

Depends on how we want to instantiate it. pywikibot.Site('abstract', 'wikipedia') or pywikibot.Site('wikipedia', 'abstract')?
Note that multilingual Wikisource is also in the 'wikisource' family.

the instability of this metadata will lead to false positives (read: the Check not appearing in cases when people paste text directly from LLMs)

Sample fix per enwiki: https://en.wikipedia.org/w/index.php?diff=1343188790, https://en.wikipedia.org/w/index.php?diff=1343320597.

Neither disputes about local project practices nor Special:Block interface have anything to do with AbuseFilter.

T170577 has nothing to do with IP address exposure. @Aklapper This is AI slop worth Trash.

With Temporary accounts, this would now be relevant only for third parties.

With T391322 completed, the wildcards and legacy IP logs are left.

This has mostly been implemented as T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter.

In T417961#11638624, @Ivan-r wrote:

Can't the problem be on the site side?

This is possibly regression caused by some changes related to T157658

In T143486#10494797, @Oudedutchman wrote:

We already automatically create user accounts for meta.wikimedia.org and login.wikimedia.org—why not simply extend this to wikidata.org as well?

Some find it annoying to deal with copyright violations and unverified AI slop. Depends whom you ask.

rc_id foreign keys are effectively useful only for 30 days. This doesn't seem like a proper mitigation.

Yes, this is already in prod.

Unlike count in PHP, count in AbuseFilter is a string function that counts substrings in a haystack.

This three-year-old task is probably not actionable at this time. But it looks like an earlier reproduction of T364245.

It's definitely a way forward and, to some extent, a mitigation. Yes, let's divide the effort between communities, each focused on the language they are most fluent in, and have them observe the patterns.

T380573: UkWiki article not indexed on Google and T400022: 2025 Commons SEO review document recent analyses and efforts to improve Wikimedia wikis' SEO.

Is this a good candidate for backport?

T-V distinction? See examples.

... not really. The UnblockUser does a lot more, including running hooks. We need to make a change in the core first, otherwise this is a dead end. (The priority isn't very high as Wikimedia now enforces temporary accounts.)

Indeed, but we are not really bound to use that interface (notice that the code uses UnblockUser::unblockUnsafe which is actually marked as @internal).

Not anymore: T356984: Stop sending change notification email if edit is done by a bot. (I don't think it should be brought back without T358087.)

The minor edit flag should reflect the significance of an edit. Not whether it was done to one or thousands of pages.