Two and a half, but I have not watched my notifications as closely and do not think I experienced this in what I did see. I might post an update here in case I notice something different, but I suppose this could be closed for the time being.

[[Special:Diff/27415660|Added]] both Translation editor and Green links to the config. Sorry for the delay.

Looking at https://xtools.wmcloud.org/autoedits-contributions/species.wikimedia.org/1234qwer1234qwer4/4?tool=Generic%20rollback, it seems that currently multilingual wikis are considered to be part of wikis with "en" language. So unless multilingual wikis could be tweaked to be considered part of both the new "mul" group and the "en" group (most summaries like rollback etc. are still in English on multilingual wikis), having a mul group will potentially be no less redundant (due to the copy-paste of the contents of "en" into "mul") than just copy-pasting the (mul-specific, non-en) regexes for every multilingual wiki on its own.

Is this supposed to be fixed?

The on-wiki rename was subsequently reverted; not sure if this needs to be changed here too

Noting that this is also the case at https://en.wikipedia.org/wiki/Special:NewPagesFeed:

now looks like this to me:

Thanks for reporting this, this has been sitting on my list for a while. https://species.wikimedia.org/w/index.php?go=Go&search=intitle%3Atemplate&title=Special:Search&ns0=1 was my case in case anybody needs another example.

T285951. Looks like this task suggests some specific pattern though.

In T311360#8068029, @Ladsgroup wrote:

So if you remove that condition, it should be working again (until I find a fix for it).

The group membership has been revoked by @EPIC.

I'm not sure how this is "low" priority.

In T49177#9834118, @Tacsipacsi wrote:

just like page protection may be worth it

In T310961#9271415, @Stashbot wrote:

hiwikisource: Adjust width-height ratio of logo to fix display issue (T310961)

It seems that Modern is the only skin that separates the page header outside of the "content area". For the same reason, ContentTranslation's buttons on contribution pages appear on top of other toolbars:

In T358541#9598534, @1234qwer1234qwer4 wrote:

The query in the task description now throws a "500: Internal Server Error" for me.

The query in the task description now throws a "500: Internal Server Error" for me.

@Umherirrender I'm not familiar with antispoof, so I requested this mainly for AbuseFilter, see cases like https://en.wikipedia.org/wiki/Special:Contributions/ClearHarmony. AbuseFilter already normalises a lot of Cyrillic letters to Latin ones, so I don't really see the problem here.

See T311365 for a newer request regarding \operatorname*.

In T229992#9303513, @Xaosflux wrote:

Does that mean spelling variants would need to be recreated on every WMF wiki? -- not if they are localized, only if they are on that tiny list coming from external source

In T229992#9303385, @Xaosflux wrote:

Well, that's annoying - suppose we would need a highly advertised request to avoid this by having WMF wiki's "not accept en/xxx variants from translatewiki" anymore?

In T346187#9187371, @Xaosflux wrote:

Currently declined the stewards onwiki request; forking the wikiset just to add this for one project isn't the best course of action; we are of course open to a community discussion about adding the translation admin permissions to the entire GS opt-in wikiset; please open a discussion on meta-wiki if that is desired.

The API allows to view authors of deleted revisions (and page creations are logged on most wikis as well), so is the connection between separate "temporary accounts" (without disclosing the IP address itself), which could result from nuking pages from all such accounts simultaneously, an intentional consequence?

Unless that is yet to be deployed, no, revision deletion is still not possible.

Is there local consensus from the individual wikis or just the discussion on Meta? Clearly the contingent of people who visit Meta at all is very biased towards global things.

Unrelated to title blacklist as made clear in the title.

Oh, sorry, my bad. There's been a lot of redundant reports lately and I saw the HY000 error which had appeared in some other reports too, but thanks for fixing my mistake.

This is not XTools-specific and XTools can't fix this.

Works for me now; looks like this is resolved.

Thanks! I think Ӽӽ is still missing too. Also since you added ѿ you might as well add ѡ, and Ѽ should at least be mapped to Ѡ if that should not be mapped to W as well.

Cyrillic and Greek seem reasonable since they are quite closely related (though indeed it may be confusing for letters like Г or Ђ which have a completely different etymology -- for Г I've at least seen it being abused though). In fact, Cyrillic has quite a few more additions worth looking into, such as Ѻѻ for O or Ҏҏ for P. Also, it looks like ґ is normalised to Ґ; I wonder why this isn't leading to the R set the letter Г is pointing at.

thanks a lot for your help @Umherirrender! The ɕ character should be in the C equivset for sure since it is literally the letter c with a diacritic, and ѓӷ (plus their capital forms) should be in the R equivset considering that the letter г is. The rest probably needs some more investigation (ligatures appear to be sort of a difficult case in general).

This is about https://www.wikidata.org/wiki/MediaWiki:Gadget-Merge.js. However, I do not understand what is meant by a

Not sure if this is related, but in Firefox, the checkbox and buttons are accessible with the tab key, but hitting enter on the checkbox just confirms the login without changing the state of the checkbox.

@rook Both tasks are by me. The title (and if not, the description with the relevant links) should be clear enough in stating that this one is about the Wikidata sitelink change reflecting a page move while the other is about the redirect created when it is not suppressed in the move.

Fixed for short input parameters. But the issue persists with https://filedupes.toolforge.org/?language=commons&project=wikimedia&category=<%2Ftextarea><img+src%3D1+onerror%3D"alert('xss')">&doit=Do+it.

Note: namespace should be called "Ков", see https://inh.wikipedia.org/wiki/ОагӀат:Ковнаш.

In T31216#1898651, @Krenair wrote:

In T31216#1894107, @Trijnstel wrote:

Is this only about a suppression where one deletes+suppress a page at the same time?

Don't think so.

Another similar one, if it helps: https://de.wikipedia.org/w/index.php?search="Essays%2C+Reden%2C+Propagandaschriften+u.+a."

Sure, done.

Just noting that Special:GlobalBlockList has a similar issue.

There are multiple issues highlighted in this report: One is deleting a translation page without its units (what is stated in the title); the other is restoring translation pages, which is an unrelated issue affecting restoration of pages deleted by FuzzyBot in the same way and should be handled with a separate ticket (and is arguably more important since it actually makes the workflow with the translation extension so much harder, requiring you to temporarily unmark the whole page from translation first, as outlined here).

The bug I saw here was mostly your second point, though I'm pretty sure I have sent thanks for user rights log entries before (third point).

I reported this just after submitting this search query for the first time and realising it fails.

@Urbanecm Are you sure about this? This task is about the tool failing for a specific query, possibly due to the emoji/Unicode plane 1 character, while T316420 seems to be a more recent issue.

srwikisource has been fixed (thanks). hiwikisource is still to be handled, and I have also found https://eu.wikisource.org/, https://be.wikisource.org/, and https://cs.wikisource.org/ with this issue.

FWIW this has been existing since 2018 at https://www.wikidata.org/wiki/User:Mat%C4%9Bj_Such%C3%A1nek/patrolRevisions.js. Not sure the subtasks are arranged appropriately; I think this task can be closed.