Page MenuHomePhabricator

Page tabs on redirect pages should have redirect=no
Closed, DuplicatePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What should have happened instead?:
Redirect workflows in MediaWiki are currently very hard. Basically any action you normally want to do with a page is done via page tabs. Some projects have templates and other information on the redirect pages. Currently MediaWiki forces them, while working with the redirect pages, to go to the target page, find a pretty small ‘Redirected from X’ link, and go back there to actually do anything.

It would be far better if, on redirect pages, links from page tabs/actions led to the redirect page itself, and not the target page. It would cause less friction since navigating to the target page will still be possible, but if someone is already looking at the history page of a redirect for whatever reason, chances are they want to see the redirect page first when using ‘Page’/‘Read’ tab. This change should not be controversial and would improve UX for people working with redirects.

To clarify, links that do not lead to the current page should not have redirect=no, for example redirect links to talk pages should still lead to redirect target, but tab link ‘Talk’ for redirect talk page should lead to redirect=no if you are looking at its history etc.

Informed in part by T379860: Category pages should be able to link to redirect pages with redirect=no and T379863: Special:WhatLinksHere transclusions should link to redirects with redirect=no.

Event Timeline

See also T5324, which includes a lot of old arguing over this.

Thanks for finding it. Seems like most of old arguing seems about misunderstanding of what the change would entail. It would still be possible to check the redirect target by looking at how the page looks. Seems like given comments at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/585741 by @Anomie, it is best to close that task and discuss the issue again here?

In addition to the inline comments, I'm concerned that this is the sort of seemingly-minor behavioral change that is liable to result in a lot of editor complaints. It may need more communication than a 15-year-old task that has only been commented on by a handful of people in that time.

Btw I don't know how you could alleviate that concern unless we announce this sort of task/discussion itself in Tech News or something. Maybe that is a solution that can revive and fix this issue.

it is best to close that task and discuss the issue again here?

Unless things have changed since I stopped paying close attention, normally we close the new task in favor of the old than vice versa, since the old task normally has more extensive information.

But you yourself have -1’d a patch to resolve this issue because it was on a ‘15 year old task without much feedback’. It is hard to see how one can resolve that conundrum then given your (and Huji’s) personal opposition.

You can just as easily get feedback there as here.

Yes, and people have tried to do so, and didn’t get widespread opposition after a Tech News item at the time, and yet the patch was still -1’d a few times and then abandoned instead of getting resolved. So clearly having that old task didn’t bring any resolution to the issue.