Having presumably the same issue on enwiki. reqIds include 2223aab9-4820-990b-b2bf-2b5d58fa61d9 and 99ccd2c4-b542-46af-8366-b025702541d7

Thank you for all the patches @matmarex!

https://ru.wikipedia.org/wiki/Служебная:Метки
https://en.wikipedia.org/wiki/Special:Tags

@-chanakyakdas: Thanks for reporting this. For future reference, please use the feature request form (linked from the top of the task creation page) to create feature requests, and fill in all the sections in the template. Thanks.

Change #1098602 merged by jenkins-bot:

[mediawiki/core@master] Load codex messagebox styles for box on ContributionsSpecialPage

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

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

[mediawiki/core@master] Load codex messagebox styles for box on ContributionsSpecialPage

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

That is an argument for sending people to the best possible interface (action=edit), not arguably the worst and most wonky. And doing the redirection to Special:Translate client-side if possible (if action=edit gets visited with a parameter indicating that this needs to happen). Hacking around it with https://meta.wikimedia.org/wiki/User:Amire80/allMessages.js shouldn’t be necessary.

It's broken either way for some cases.

Well, the problem is that the SearchTranslations fails for any untranslated tag messages with spaces in their names, for example: https://zu.wikipedia.org/wiki/Special:AllMessages?prefix=Tag-&filter=all&lang=zu&limit=50

This is not possible in all the cases. We have ignored messages which should not be translated in translatewiki.net. We have optional messages (of which your example is an example of) that usually should not be translated in translatewiki.net. Then we have messages where the key does not match because we have had to rewrite the key for various reasons.

Re-opening since it clearly wasn’t: https://ru.wikipedia.org/wiki/Служебная:Системные_сообщения?uselang=en links to https://translatewiki.net/w/i.php?title=Special%3ASearchTranslations&group=mediawiki&grouppath=mediawiki&language=ru&query=1movedto2+moved+[[%241]]+to+[[%242]] which does not find the relevant message at all. Even if a link to translatewiki.net is required to go to the special page, it should go to Special:Translate, not to Special:SearchTranslations. Though personally I think just linking to the edit page would be better, since Special:Translate isn’t accessible without JavaScript enabled.

This caused a production error: T378727

It is not possible to revision delete the page name only, it hide all information for the log event, that includes the page and all parameters. It does not revision delete the action.
So the task is still invalid as written, because it is not possible to hide the action, but it is possible to hide the target of the event. But that was already in the previous comment.
It seems not possible to allow more gradually ways of deletion here, as there are only 3 options, but I leave it open to allow further responses to this topic.

As for rollback links, there is also T122546: Cache rollback edit counts shown on recent changes, but I have had some doubts about whether it would have the desired effect.

In T139858#10351080, @Umherirrender wrote:

1. Log in as oversighter

Can you provide steps to replicate? I do not see what log type you have hide. Maybe the title is just part of the parameters (like for move logs or user renames)

It's a bit of outdated thinking here (not necessarily your fault): CSS content is now announced in many cases by accessibility agents (and not in others). Moving it into CSS isn't necessarily going to fix away whatever we think the arrow is doing here and whether it's actually necessary.

Reopening; I meant to get around to this but never did.

Oddly I can't find a project tag for https://github.com/wikimedia/mediawiki/tree/master/includes/CommentFormatter which is where the code doing this is.

Special:Redirect is a badly named special page but it is unrelated to redirects. Restoring appropriate tags.