Page MenuHomePhabricator

VisualEditor: Link input widget filters out redirects for target pages, but this logic is wrong for existing pages
Closed, DeclinedPublic

Description

Have a link [[Foo]] which is a redirect to [[Foobar]].

Inspect link; it will suggest:

New pages

Foo

Existing pages

Foobar

This is because "Foo" does not come back in the list of pages you can link to - which is filtered to remove redirects - but we should special-case the existing link.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50240

Details

Reference
bz49502

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:44 AM
bzimport set Reference to bz49502.
  • Bug 49540 has been marked as a duplicate of this bug. ***

In my local copy, the redirect URL is not filtered out, but I did notice another bug in that code: https://gerrit.wikimedia.org/r/69871

  • Bug 50274 has been marked as a duplicate of this bug. ***

I'd say the desired behavior would be that the link inspector show the existing redirect in different way (such as blue but with a parenthetical note that this is a redirect).

In most cases, the link to the target article is the preferred link choice, but in many cases the redirect is also valid. For cases where the redirect points to a subsection, the redirect is probably the preferred link most of the time.

  • Bug 59208 has been marked as a duplicate of this bug. ***

Many redirects exist because they respond to expected (simplified) alternative names, plurals, synonyms, non-complete names of people and places, and popular uses in general. It is likely that these popular uses are also used in articles. When selecting a word, the difference between VE recognizing or not these redirects is important:

  • If the redirect is recognized and the destination page is shown, most editors will understand the difference and will choose the complete name.
  • If the redirect is not shown then you can be a lazy editor and insert the link (having no idea whether it will result in a red or blue link), you can avoid the link altogether just in case, or you can be a good editor (as I try to be), open a new tab, and search that term only to find that many times such term is a known redirect.

Do the latter 20 times in a long article and you will come to this bug report as I did. I found this to be a big nuisance in real editing. (with the side benefit that I tested Cirrus Search more and I even found a bug, thanks to these deviations caused by VE)

PS: or simply show the redirects in italics, as they are already displayed in some MediaWiki lists.

James couldn't either so RESOLVED WORKSFORME

There are a bunch of bugs about this, so I'm pretty sure I'm adding my comment to the wrong one :D
Anyway, it is possible that the inspector does not recognize immediately a page as an existing redirect. See https://en.wikipedia.org/wiki/File:VE_wrong_link_state_in_link_editor.png .
https://en.wikipedia.org/wiki/New_York_Kennedy is a valid redirect page.
Unfortunately this is not easy to reproduce.
(I never managed to do it by just typing New York Kennedy and then wikiling those words, anyway.)
I sometimes managed to reproduce by selecting a completely random word (or even more than one), clicking on the chain icon, writing New York Kennedy in the dialog. Every time though it does correct itself if, after observing the same result from the screenshot above, you click again in the text field, so the page will correctly appear as a blue link listed as a redirect.

Another couple of examples I found:
I write Indian religion, select the two words and try to add the relevant link; it doesn't recognize the page as an existing redirect, while it lists Indian religions as "matching page".
Same story for Tafkap; in this case, a couple of all caps variants are listed as redirects.
In these cases the "click in the text field" trick didn't work.

AFAICT this underlying bug was fixed in October; the issue that MediaWiki's search system sometimes comes back with bad results from time to time (falsely claiming that short titles don't exist) is distinct, as part of bug 54361.