There was actually a good number of translations with this problem, I fixed them: https://translatewiki.net/w/i.php?title=Special%3AContributions&target=Matma+Rex&namespace=all&tagfilter=&start=2024-11-15&end=2024-11-15&limit=50

Agreed, this seems like the expected behavior for any message that allows wikitext (and this message has wikitext links in it).

# at begin of the line is a list, put nowiki tags around it to avoid this. Maybe a wiki want to use a list here. It seems not possible to define for each message if list is allowed or not.

Reopen. See T361446#10286612: Instead having a blank placeholder revision, what is better is mention that a revision that exists but has no available content.

Change #609798 abandoned by Reedy:

[mediawiki/core@master] Add img_deleted column

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

Change #1076828 merged by jenkins-bot:

[mediawiki/core@master] specials: Catch RevisionAccessException and ignore on Special:Undelete

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

Change #1076828 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] specials: Catch RevisionAccessException and ignore on Special:Undelete

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

Change #1072594 had a related patch set uploaded (by Brian Wolff; author: Brian Wolff):

[mediawiki/core@master] Add hook for all types of revdel

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

Tagging Trust and Safety Product Team as something we might want to look at (cc @Niharika @Madalina) at some point. Would also be useful to get Stewards' perspective on this (cc @Urbanecm).

@Aklapper: I see what you mean, but then see "Convincing reasons for raising the priority of a bug include evidence that it affects normal, everyday work significantly". I felt that was applicable and also: I did say in my above comment that I am thinking of writing a bot to fix the bug, at least retrospectively.

@Leaderboard: Do you plan to work on fixing this task, as you increased the priority of this task? Asking as the Priority field summarizes and reflects reality and does not cause it.

I don't think this one is "low" in my opinion. As a patroller, I regularly hit cases where I look at the account and it looks as if nothing has been done to it, but the account is actually globally suppressed. Similarly, there are multiple suppressed account freely visible at https://meta.wikimedia.org/wiki/Global_statistics (also: restricted task T331046), to the extent that I was motivated to consider writing a bot to fix this retroactively (see https://meta.wikimedia.org/wiki/Stewards%27_noticeboard#phab:T25310).

"Note that Parsoid isn't supposed to use the user context by design; all user-specific processing is expected to be introduced as a post-parse transform." (code comment)

Yes I do, and &useparsoid=0 does successfully render the page, yes.

I believe this is an issue caused by having the Parsoid page renderer switched on (and a bug there!); if you switch it off, you should avoid the error?