I wonder if this makes a lot of sense on review, thinking about going the other direction. Many talk pages can be redirected to a single core talk pages. Do we want to have the negative result of "here is a redirect page" display instead of taking the user to that page? Do we want to introduce this inconsistency only going from talk to view?

If we do it for all of the tabs, then we have a negative result which is "don't follow redirect of a talk page". If we do it only for some of the tabs, we end up with an inconsistent behavior.

@Izno this would be for going from Talk to Article, not the other way around. I'm not aware of any cases where multiple talk pages redirect to a core talk page whose accompanying article page is a redirect.

In T5324#6044278, @Ahecht wrote:

@Izno this would be for going from Talk to Article, not the other way around. I'm not aware of any cases where multiple talk pages redirect to a core talk page whose accompanying article page is a redirect.

Which doesn't answer the other question. Is this a good inconsistency?

This is an old bug and should be fixed in my opinion.

As someone who frequently deals with I agree with most commenters here that this change would be a good one.
Regarding the talk page issue raised, I don't think its relevant. I use "article" in the examples below but it also applies in other namespaces:

• If both article and talk page are redirects, then a user viewing the redirect talk page will be interested in the redirect page not the target page in every situation I can think of.
• If the article page is a redirect and the talk page not a redirect, then pretty much every user viewing the redirect talk page will be interested in the redirect page not the target page with two exceptions:
  • Some (but not all) users who navigated to the talk page without going via the article page redirect will be interested in the target page.
  • Some (but not all) users who navigated to the talk page immediately after creating the redirect will want to test the redirect works (in my experience, the redirect arrow appearing is an equally reliable indicator). Even together those users who do want the target page will be in the significant minority.
• If the article page is not a redirect but the talk page is, then a user viewing the redirect-hosting talk page will be interested in the page that is redirected not its target. If they are viewing the target talk page then what they are interested in is outside the scope of this bug.
• If neither article page nor talk page are a redirect then this bug is completely irrelevant.

In all cases someone viewing a redirect page is one click away from the target via a large and conspicuous link.

Why has this been closed as "resolved" (twice) when nothing has changed and the requested behaviour has not been implemented?
If no changes will be made then it should be "declined", surely? (for the reasons I noted in my last comment I think the change should be made, and would strongly encourage an explanation why the status quo is more desirable, but that's separate)

@Agabi10 the tech news item was posted and has long since been archived. What's the path forward?

At this point, I urge every to avoid from closing this task before first announcing their intention to do so. Clearly, there are some misunderstandings. As @Ahecht showed in the comment above, it is not resolved. There is a debate as to whether it should be resolved at all. If you really feel like you want to close this task (with any status, may it be Resolved, Declined or otherwise) your next move is to post a comment in which you say your intentions, and wait for others to opine on it.

Also we would like to see the commit(s) that you claim "resolved" this issue. They should always be linked from the task

@Dvorapa The commit that resolved the issue is linked to the task and the only reason for not merging it AFAIK is that it's not clear if this should be resolved or declined.

I know, but people above claimed the task is resolved and commit is merged, so I asked for the commit, that has been merged

In T5324#6188481, @Agabi10 wrote:

@Dvorapa the only reason for not merging it AFAIK is that it's not clear if this should be resolved or declined.

The item was posted in Tech News almost two months ago, and that only generated a single "I'm not sure" in opposition, out of the 12 subscribers to this task and the hundreds of editors that read Tech News. What needs to to happen to make it clear?

What it needs to happen is someone willing to +2 the patch, at least if that is enough for @Anomie's and @Huji's concerns

I'm neither in favor nor against this change really. I guess that makes me no different than all others here :)

I don't feel compelled to +2 it myself, but I wouldn't oppose someone else doing it either. I guess there is a way to convince me one way or the other, but I don't know what that way is. The indefference of others (including Tech News readers) was certainly not helpful.

Change #585741 abandoned by Agabi10:

[mediawiki/core@master] Prevent redirecting to target when using the Article and View tabs

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

Change #1094077 had a related patch set uploaded (by Saint Johann; author: Saint Johann):

[mediawiki/core@master] Make page tabs for redirects link to redirect pages

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

Since T380089: Page tabs on redirect pages should have redirect=no was closed in favour of this task, I’ll repeat how I think it should work:

1. When user visits action pages of a redirect page, ‘Article’ and ‘View’ tabs should link to the redirect page itself. https://en.wikipedia.org/wiki/WoW?action=history
2. When user visits action pages of a redirect talk page, ‘Talk’ and ‘View’ tabs should link to the redirect page itself. https://en.wikipedia.org/w/index.php?title=Talk:!Arriba!&action=history
3. This doesn't disallow users to still go to the redirect target by visiting the redirect first and then going to the only link there.

I think this is the most reasonable workflow and the fact that it hasn’t been implemented in 15 years is, frankly, a testament to how bad MediaWiki development is sometimes. Current workflow is broken: even if you are viewing a redirect page’s history or editing it, there is no way to view a redirect page without going to the page first and then having to click a small ‘Redirected from’ link. Since many wikis use redirect categorisation and templates, there is no reason to assume this is the best workflow, especially when the downside is extremely minimal: people would still be able to go to a redirect target, just with an additional click.

Since @Agabi10 abandoned their patch, I am submitting a new one according to this list above. I would hope @Anomie and @Huji do not –1 it again on principle alone since this is a real problem. This was announced once in Tech News (https://meta.wikimedia.org/wiki/Tech/News/2020/16) and no one was vehemently against this change. I think it is much easier to make this change, announce it in Tech News again, and see if people would complain than it is to wait another 15 years for some magical condition.

Also posted a topic at the English village pump about this (if this is genuinely controversial, comments there can be expected): https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Proposed_change_to_tabs_on_redirect_pages

Yeah that sounds more sensible and consistent compared to what we have now. Redirect pages already take additional effort to get to, so we need to consider what is the user's goal when they are clicking these tabs.

The current working version of what I outlined above has a demo at https://patchdemo.wmcloud.org/wikis/91df896148/wiki/Redirect_example?redirect=no (page itself and its talk are redirects).

‘Page’ tab only redirects when you are not at the page itself, and same with ‘Talk’ and ‘Read’ tabs. Non-current page tabs function as usual. There might be a better way to implement this in PHP than what I went with.

Another thing I didn’t mention in my initial message: many links in MediaWiki currently lack redirect=no for redirects, and at the same time, even if you have access to related pages like history, you cannot access the redirect page directly for anything other than editing. This makes, for example, redirect patrolling workflow (outside of enWP with its NewPagesFeed) much harder, since you need to go through hoops to actually access patrolling interface as it is only available when viewing the page (for instance, in FlaggedRevs). It should not be this way.

Example (last link is the only link that leads to redirect directly):

@stjn asked me to look at this task. I've read the discussions here and https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_216#Proposed_change_to_tabs_on_redirect_pages.

It seems to me that everyone agrees that when you're editing or viewing the history of a redirect page, then the tabs that link to the read mode of the same page should display the redirect instead of following it. This is what is implemented in the currently proposed patch by @stjn.

[To be painfully precise: the change will apply when the link goes to either the same page that you're viewing, or the "relevant" page of the special page you're viewing, e.g. in cases like Special:WhatLinksHere/Blah; and it will apply to all of the namespace tabs usually shown by the skin in the top-left corner like "Article" and "Talk", and to the "Read" tab on skins that display it. Note that all other action tabs already act on the redirect, instead of following it, this does not change. Note also that when you use the "Article" or "Read" tab to leave the visual editor on a redirect page, it already displays the redirect instead of following it as well.]

It's less clear what should happen when you're clicking on a tab that links to an associated talk or subject page (or other associated namespaces like TimedText). The previously proposed patch by @Agabi10 made that also display the redirect instead of following it, and this seems to have been somewhat controversial. Some people suggested that this should only happen in some cases (e.g. only when the page you're viewing is also a redirect, or only when going from talk to subject but not when going from subject to talk). A few people haven't made it clear what they had in mind when expressing their support.

Given the above, I think we should go with @stjn's patch, which takes care of the first scenario, and then close this task. (Probably announce it in Tech News again, just in case.) If, after that, anyone still wants to deliberate on what should happen in the second scenario, they could start another task.

I'll give everyone a few days to review this, and to object in case I misread the mood. If no one opposes it, I'm going to merge that patch about a week from now.

It seems to me that everyone agrees that when you're editing or viewing the history of a redirect page, then the tabs that link to the read mode of the same page should display the redirect instead of following it. This is what is implemented in the currently proposed patch by @stjn.

It will also change the tab when you're viewing the redirect, not just editing or viewing history. That part I disagreed with at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_216#c-Anomie-20241122130100-Agabi10-20241122090700 and some subsequent replies.

I still think that the objections raised there would be better solved by other means than messing with page tabs. Redirect page markup is currently considered to have an HTML overhaul, see T380530: Add Parsoid-compatible <link> tag to legacy parser output for redirects (though this is more of a long-term goal), so maybe a link to test how redirect works with ‘Redirected from’ message could be added to the content HTML instead of the page tabs output. Or there could be a URL parameter added to trigger ‘Redirected from’ message. There are other decisions for your use case that wouldn't make everything more inconsistent (since I would argue that Page/View tabs are also considered ‘reload current page’ tabs by many as much as they are considered ‘go to redirect’ tabs by you).

@Anomie Hmm, we could think of that as a third scenario: what should happen when you're in the read mode for a redirect page, and you click on one of the read mode tabs that are already selected? Should this also display the redirect instead of following it? @stjn What do you think about amending your patch to avoid the behavior change for this case as well? I don't think it matters for your situation from T380089, and there are some reasons for the current behavior (mostly testing how the redirect behaves). It would be "inconsistent", sure, but the behavior of the tabs is already inconsistent (and that's both before and after your change); it seems impossible to achieve consistency here without breaking people's workflows (or mildly annoying them, really, but that's still not nice).

I replied before about it in the discussion and replied here. Yes, strictly speaking, it is not described in the task you linked, but I feel like the benefit described there is extremely marginal. The redirect page already contains the redirect target in large letters, and that can be used for testing as much as page tabs do. The only difference is that there isn’t ‘Redirected from’ message. Should an inconsistency be introduced to the interface just for that reason?

Additionally, normally Page/View tabs have a number of other functions, like reloading the current page, opening it in a separate tab or copying the link to it via context menu. Currently much of these functions are hindered by this task not being solved for 15 years (despite my patch being the 2nd one attempting it), but it doesn’t mean it should be. When the redirect page is being opened directly, it is more consistent to keep all the things related to it pointing to the redirect, especially since things like UrlShortener do not do the same attempt to change where the URL leads when using them. Yes, it might be annoying to some, but the current way it works is pretty annoying as well (in part because of opposition raised by @Anomie 4 years ago).

I'll just quote myself from the VP discussion:

How often do people really need to get to view the redirect page that one click rather than two for this use case outweighs the drawbacks of increasing the inconsistency of the UI and requiring editing the URL to follow the redirect as a reader would?

Clicking the link to the target page in the redirect itself is not "follow[ing] the redirect as a reader would", BTW, as it requests the target page's URL from the server rather than the redirect page's URL. That avoids displaying the "Redirected from" and handles anchors differently, and may potentially behave differently if it's a double-redirect.

The only functional difference between the two is that ‘Redirected from’ message isn’t shown and navigating to anchor happens instantly instead of after the page load. Double redirects already link with redirect=no in redirect page text, so clicking on the page tab also has no difference other than ‘Redirected from’ message (just checked).

Also, as I mentioned in the reply to you there, current workflow is more inconsistent with how MediaWiki works and also requires to edit URLs, just in the other direction. If I navigated to a redirect and then I want to copy its URL, I only can do so by using the browser’s address bar (or URL shortener, I guess), or I also have to edit the one that I can get from page tabs.

@stjn There are actually a couple of other cases where there are functional differences between following a redirect, and viewing the redirect target (and therefore testing whether a redirect works could be useful). I can think of interwiki redirects (which will follow the redirect to interwikis marked as "Forward" on Special:Interwiki, but display the redirect page in other cases, while the link shown while viewing the redirect page always works) and scenarios where extensions using the InitializeArticleMaybeRedirect hook are involved (e.g. FlaggedRevs can override the redirect target to be retrieved from the stable revision, rather than the one that is viewed).

In T5324#10430793, @stjn wrote:

[…] Should an inconsistency be introduced to the interface just for that reason?

If we were discussing introducing an inconsistency, then I would agree that it shouldn't be introduced; but it seems to me that we're discussing removing an inconsistency that is already there. I think doing that should require a stronger proof that it's a good idea (since there may have been a good reason for it, or people may be used to this behavior even if there wasn't a good reason, and especially after someone objects to the change), and that's why @Anomie convinced me that the behavior in this case should be preserved.

In T5324#10430793, @stjn wrote:

[…], especially since things like UrlShortener do not do the same attempt to change where the URL leads when using them.

I'm afraid I don't understand this sentence, can you clarify?

In T5324#10430918, @Anomie wrote:

How often do people really need to get to view the redirect page that one click rather than two for this use case outweighs the drawbacks of increasing the inconsistency of the UI and requiring editing the URL to follow the redirect as a reader would?

I'm afraid I don't quite understand this sentence either?

In T5324#10430946, @stjn wrote:

Also, as I mentioned in the reply to you there, current workflow is more inconsistent with how MediaWiki works and also requires to edit URLs, just in the other direction. If I navigated to a redirect and then I want to copy its URL, I only can do so by using the browser’s address bar (or URL shortener, I guess), or I also have to edit the one that I can get from page tabs.

I'm not sure if that's right, but I may be misunderstanding something.

Currently, when you're in the read mode for a redirect page, you can a) copy the URL to display the redirect from the address bar, b) copy the URL to follow the redirect from the "Read" or "Page" tab, and c) copy the URL to the target page from the displayed content of the redirect page.

After your proposed patch, a) and c) work the same, but b) does the same thing as a), and you can't copy the URL to follow the redirect from anywhere that I can see.

In T5324#10431218, @matmarex wrote:

I'm afraid I don't understand this sentence, can you clarify?

What @Anomie proposes is that the page tabs function differently when they are in view action and when they are not in view action. I am saying that, since other extensions etc. do not follow the same logic of generating links without redirect=no, the page tabs themselves should also not follow that logic just because of another separate concern.

In T5324#10431218, @matmarex wrote:

I'm not sure if that's right, but I may be misunderstanding something.

Yes, I am saying that if I wanted to copy the URL to a redirect page itself from anywhere other than the address bar (the most logical and convenient place being page tabs), I have no ability to do so without editing the URL afterwards. So I am being required to add redirect=no whereas @Anomie doesn’t want to have to remove redirect=no. Either way it is a trade-off, since when I want to copy the link or open the same redirect in a new page tab, I currently can’t do that via links on the page. And that, I would argue, is a more common use case when you are on the redirect page itself.

I think this inconsistent behaviour can be introduced as a temporary solution until redirect HTML can be adjusted so that the link without redirect=no is present there. I do however fundamentally disagree with the opinion that this use case of following a redirect should be solved via page tabs long-term, and the fact that it was like that for years shouldn’t commit us to that. MediaWiki has a lot of bad interface design that no one touches for years because the process of doing so is too arcane and bureaucratic.

This task as a whole is a prime example of that: instead of figuring out and fixing it 5 years ago, it lingered for years due to opposition from 2 people despite many other people agreeing or not minding this change when being asked over the years. People shouldn’t have to run user scripts to be able to do trivial work with redirects.

Another reason why I think this would introduce inconsistency: what should happen with page tabs on the link like https://ru.wikipedia.org/?oldid=55439330? My opinion is pretty consistent: I should be able to navigate to the current version of the redirect page from there as long as it is still a redirect. But currently and under proposed workaround it’s impossible to do so either from the interface message (fixable locally, at least) or the page tabs. And I don’t think that’s a correct way to do things long-term (short-term is fine, though https://bash.toolforge.org/quip/AU7VTzhg6snAnmqnK_pc is eternal).

In T5324#10431218, @matmarex wrote:

In T5324#10430918, @Anomie wrote:

How often do people really need to get to view the redirect page that one click rather than two for this use case outweighs the drawbacks of increasing the inconsistency of the UI and requiring editing the URL to follow the redirect as a reader would?

I'm afraid I don't quite understand this sentence either?

I'm questioning whether the use case for "view the redirect page in one click" (versus two clicks, following the redirect then clicking the "Redirected from" link) is really a use case we should be prioritizing over use cases involving following the redirect. For going from History or Edit or Info tabs I could see it making sense, but from the View "tab" I remain skeptical.

In T5324#10431218, @matmarex wrote:

Currently, when you're in the read mode for a redirect page, you can a) copy the URL to display the redirect from the address bar, b) copy the URL to follow the redirect from the "Read" or "Page" tab, and c) copy the URL to the target page from the displayed content of the redirect page.

After your proposed patch, a) and c) work the same, but b) does the same thing as a), and you can't copy the URL to follow the redirect from anywhere that I can see.

I'm increasingly thinking that this is an important use case. The other day I was reviewing some patch, and I wanted to copy a short link to our code conventions into a comment on Gerrit – that is, https://www.mediawiki.org/wiki/CC. I got it by searching for "CC", then going to the redirect page, and copying it from the "Page" tab. I wouldn't want this workflow to be broken.

As I’ve said above, I do not have an opinion that it is not an important use case, I just don’t agree that it should be solved long-term via page tabs. You are welcome to modify the patch so that action=view on the current version of the page leads to the redirect target, if we add a FIXME comment that this link should eventually be moved on the page itself and that condition should be removed. I would do this myself but I’d probably spend too much time figuring out how to add that condition.

Updated: the patch was modified to reflect this, see https://patchdemo.wmcloud.org/wikis/a02452fc4f/w/index.php?title=Redirect_example&action=history for the demo

Change #1094077 merged by jenkins-bot:

[mediawiki/core@master] Make page tabs for redirects link to redirect pages

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

Something like this:

When a user is doing any actions on a redirect page, the tabs linking back to viewing it would no longer go to a redirect target.

(this was moved to "Already announced/Archive" back in 2020 during the previous attempt to resolve it, apparently the column sticks if you remove and re-add the tag)

Tech News note: I'm bumping the entry to next week, so that it's already functional (beyond beta-cluster) when editors read about it on a Monday. P.s. Thanks to stjn for drafting an entry :>

I'm planning on revising the Tech News entry, with this wording which I think is clearer. Please comment if you have any objections (ideally offer a corrected version) or additional improvements. Thanks!

A change has been made to pages connected to a Redirect, such as History pages. When you click the interface tab for that page, you will open the Redirect page itself, instead of automatically being sent to the redirect's target. This should make it easier for editors who do a lot of work with redirects. Thanks to user stjn for this improvement. [1]

This is too verbose without an increase in understandability (‘a change has been made to pages’? redirect page change should make it easier for editors who work a lot with redirects?). ‘Redirect’ and ‘history pages’ should not be capitalised mid-sentence. ‘The interface tab’ is something that would probably be harder to translate, if anything. Suggestion on alternative wording:

You can now navigate to view the redirect pages from their action pages, such as history page. Previously you were forced to go first to redirect target. This change should help redirect editors. Thanks to user stjn for this improvement.