This doesn't happen with Vector 2022 (default Wikipedia theme), as the Vue search component shows the redirect target rather than the name of the redirect.

Outside of that, as far as I'm aware, the behaviour you're exhibiting is intended. I think the built-in search engine in MW removes duplicate results (e.g redirects to the same page) and prioritises the redirect that is closest to the query you typed.

@DrDogs, could you please explain the issue? When I search for the example you provided on Wikipedia using Firefox, I get the expected results (

@RJ2904: I've edited the task description with a direct link to use the old Vector skin instead of the default Vector2022 skin. Also, your file cannot be seen by others. Please attach it. Thanks.

This is essentially a series of tradeoffs. The autocomplete algorithm looks at how close (via levenshtein distance) the autocompleted title is from the target title and will replace it if close enough. In this case the levenshtein is not close enough because the redirect has an additional prefix of List of and that counts against the distance. In the newer vector skin the team building that decided to perform full redirect resolution which means you will never see a redirect title and always see the target title.

As for what is the right answer, that ends up being a UI/UX decision. Redirects are sometimes misspellings, but not always. So for example:

The old vector uses the api call:

https://en.wikipedia.org/w/api.php?action=opensearch&format=json&formatversion=2&search=chasing%20a%20light&namespace=0&limit=10

Old vector can resolve redirects by providing redirects=resolve:

https://en.wikipedia.org/w/api.php?action=opensearch&format=json&formatversion=2&search=chasing%20a%20light&namespace=0&limit=10&redirects=resolve

The new vector uses the api call:

https://en.wikipedia.org/w/rest.php/v1/search/title?q=chasing+a+light&limit=10

Plausibly search could be modified to understand that there are some list of "ignorable" prefixes, the main blocker to getting that done is designing a system to collect and maintain that list on a per-wiki basis. That could be anything from some sort of system that requires editors to collect the list (plausible on large wikis, less so as they get smaller), to some sort of statistical analysis that looks for high-frequency prefixes to feed into the same system (might have surprising results).

Small proof of concept for detecting high-frequency prefixes in enwiki using a very naive word splitting. I would have hoped for a sharper distinction between The and John: P74175

Tagging the Web-Team since they seem to own legacy vector skin. The Search Platform team can provide support if needed, but changes needs to be done (or not) by whoever owns the Vector skin.

Untagging, while we own legacy vector and support regressions and some bug fixes, we are not currently supporting feature requests for non-default skins.

It might help this task if there were an easier way of identifying spelling mistakes; that's what I've proposed at T393668: Extension to create magic word for bad redirects but you'll have to implement that and then use the extra metadata somehow.