creidieki wikibugs wrote:

I was asked on MediaWiki-General to clarify why I think this is a bug.

I basically think that this violates user expectations. This bug will only
occur when a user is dealing with a redirect itself. That is, they are
currently editing a redirect, posting on the redirect's discussion page, or
viewing the redirect's history. In these cases, the user is thinking
specifically *about the redirect*. So, if they want to come back to the page
they were looking at before, I think it should be the redirect itself.

Fixing this bug shouldn't affect any user who isn't actively dealing with
redirects. On the other hand, it should make things a lot easier for those
users who edit a lot of redirects (I've personally been categorizing redirects
lately).

On the other hand this would complicate some tasks, such as testing that the redirect
works -- you'd have no way to do so except to edit the URL manually.

gangleri wrote:

(In reply to comment #0)

You would expect to be taken back to the redirect page (with &redirect=no), but
you're instead taken to the target of the redirect.

This also works with any of the other tabs ("Discussion", "History", etc.) in
step 2.

This has been annoying when attempting to categorize redirects, etc.

(In reply to comment #2)

On the other hand this would complicate some tasks, such as testing that the

redirect

works -- you'd have no way to do so except to edit the URL manually.

At
http://en.wiktionary.org/w/index.php?title=Transwiki:Side_chain&redirect=no
you can click on "Permanent link"
http://en.wiktionary.org/w/index.php?title=Transwiki:Side_chain&oldid=459760
to verify the rendering.

I think this is a fair "workaround".

best regards reinhardt [[user:gangleri]]

With the recent changes to the message shown after a redirect, it now has a link to the redirected page with &rediret=no in it, and a link to the destination page. Having this, I think the changes asked in this bug are no longer required. Thus, I'm marking it as FIXED.

As "FIXED" is regularly used when a change is made to fix the bug, I'm changing it to "INVALID".

I have no idea what comment #4 and 5 refer to, but the described issue seems to be entirely unchanged. Reopening.

Marking as WONTFIX; my original impression that current behavior is desirable still stands.

Reading the previous comments, I'm not clear that the original reasons for closing this actually address this report's request directly. To reply to Brion's comment, one can test a whether a redirect works as expected by clicking the large link that the redirect page produces. To reply to Huji's comment, the links that the redirect page generate when the redirect is created are irrelevant to the links accessed when switching between tabs; these are two entirely separate workflows.

As far as I can tell, there is no advantage to immediately going to the target page after switching to the Page or Read tabs. One can only access these tabs from other tabs, and when I am in the Edit, Talk, or History tab, I am already examining the redirect in more detail, usually in preparation for editing it. In fact, I cannot think of a single instance where I wanted to go directly to the target page when I clicked on the Page or Read tab.

While this can easily be partly solved by the user script posted here, I still think it would beneficial if this was the core behavior. This would also make the interface more consistent; one is not taken to a redirect page's target after saving and editing, so I think the the Page and Read tabs should behave the same.

I'm boldly re-opening; others are welcome to revert if they disagree.

I would agree that the intended behavior of the "Article" button, when on a talk/history page of a redirect, should be to link to the redirect itself. The number of times an editor wants to go directly from the redirect talk page to the redirect target is small compared to the number of times the editor wants to go to the redirect itself.

Change 585741 had a related patch set uploaded (by Agabi10; owner: Agabi10):
[mediawiki/core@master] Prevent redirecting to target when using the Article and View tabs

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

Adding Platform Engineering for review.

@Agabi10 I think it may be reasonable to announce this on the next issue of Tech News and solicit larger feedback.

Adding User-notice to ask for feedback.

Something like this (might be edited for simplicity and brevity) for Tech News?

If you edit a redirect page and then click on the article page you are taken to the target of the redirect. This could change to the page with the redirect with &redirect=no instead. You can leave feedback on this.

@Johan, I think that's a little difficult to understand. How about "The "Article" tab on talk pages of redirects currently links to the target of the redirect. A change is being considered to have it link to the redirect page itself. You can leave feedback on this."

Yes, I mainly wanted to make sure I had the concepts clear! Thanks.

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.