So are you suggesting modifying the legacy parser to make this an error there too? Because I think it can be useful to have this syntax error show up as the name parameter does not work as expected in this case.

Ugh, thanks. Indeed the /ref_name"/ regexp I'm searching for only causes a "Cite error: Unknown parameter [...]" error in Parsoid, which is why the search together with incategory is empty. I assume the categorisation will be consistent once Parsoid becomes the default?

However, it is displayed for me in the categories at the bottom of the page (even after a null edit):

Right now this seems to happen to me on protected pages, like https://foundation.wikimedia.org/wiki/?action=edit.

Hmm, okay. So I had to click the "Syntax" button in an edit window elsewhere for the syntax highlighting to appear at Special:Undelete. Definitely not good UX, and different from the behaviour on protected pages, where the button appears:

https://en.wikipedia.org/wiki/Special:Undelete/Feted_Inner_Core shows the revision sizes instead of the byte changes:

Currently I do not have CodeMirror on any Special:Undelete page

Huh? The task describes that the (original) regexp did not match the account names though? Not sure if this issue still exists, but was wondering about it since I am about to restore part of the original regexp due to lots of abuse.

Yes, that same portlet also has the other links I mentioned.

In T422984#11810554, @Novem_Linguae wrote:

• Could alphabetize.

Seems inconvenient to have them in a different order depending on the selected language (especially for users who work on wikis in different languages, this makes it much harder to build muscle memory, and in the case of cross-wiki patrolling in languages you have no knowledge of it would make navigation very confusing).

Actually, that preference does not even seem to work for me.

cf. T249293#7497112.

In T413459#11483978, @Bhsd wrote:

I would say this is the expected behavior because the user may want to add tag attributes.

I cannot imagine the lists being client-dependent. Did you actually look at the two links above? This should be on the first:

It seems that this particular query is working now, so barring further examples of this, I suppose the task can be closed.

Potentially the reason this has not been done is to avoid aggregation of data capable of building user profiles as described in T388320.

Well, idk, it would be useful to be able to generate the relevant JSON from translatewiki or something, but since it should include various older versions of the edit summaries as well, I don't know what exactly you are imagining.

Why don't you copy them to that page then?

There seems to be some issue when a single \omicron is rendered without any other content in the math tag...

In T301615#9628739, @MusikAnimal wrote:

Following T190108, you won't need WikiEditor to have syntax highlighting on read-only pages (or any page, for that matter).

Not sure if this is in any way related, but a generic search such as the one in the screenshot below (-deepcat:"Articles using English type template") would not be expected to return 5 potentially NSFW results within the first 21.

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.