Page MenuHomePhabricator

Make new Vector search navigate to item search results on Wikidata
Closed, DuplicatePublic

Description

As a user or editor browsing the Wikidata website, I want to quickly navigate to search results when using the main search bar on the page.

Problem:
Currently, navigation for search results in the new Vector search works in two different ways.

In both cases, Special:Search will then redirect you to the page whose title exactly matches the search text (e.g. https://en.wikipedia.org/wiki/Test), unless it’s configured to show search results even for exact matches (either by user preference or, such as on Commons, even by default: https://commons.wikimedia.org/w/?search=Leonardo+da+Vinci does not redirect to https://commons.wikimedia.org/wiki/Leonardo_da_Vinci).

The second approach doesn’t work at all for Wikidata items, where the search result’s label is not the same as the page title, or even uniquely identifies the search result: there are plenty of items labelled “Berlin”, but if I highlight the search result for Berlin, Illinois and press Enter, I want to navigate to that particular item, not a search results page for “Berlin” in general.

Example:
Currently, you can only try this out using the proof of concept from T316093; you can paste the following code into the console on Test Wikidata (not real Wikidata):

var vectorSearchClient = {
			fetchByTitle: ( q, domain, limit = 10, showDescription = true ) => {
				var api = new mw.Api();
				var data = {
					action: 'wbsearchentities',
					search: q,
					format: 'json',
					errorformat: 'plaintext',
					language: 'en',
					uselang: 'en',
					type: 'item'
				}
				var getJson = api.get( data );

				function getMatchText( { type, text } ) {
					if ( type === 'alias' || type === 'entityId' ) {
						return text;
					}

					return '';
				}

				const searchResponsePromise = getJson.then( ( res ) => {
					return {
						query: q,
						results: res.search.map( ( { id, label, title, url, match, description, display = {} } ) => ( {
							value: id,
							label,
							match: getMatchText( match ),
							description,
							title,
							url,
							language: {
								label: display?.label?.language,
								match: match.type === 'alias' ? match.language : undefined,
								description: display?.description?.language
							},
						} ) ),
					};
				} );

				return {
					fetch: searchResponsePromise,
					abort: () => {
						api.abort();
					}
				};
			}
		};

		mw.config.set( 'wgVectorSearchClient', vectorSearchClient );

Otherwise, you can see the described behavior difference e.g. on English Wikipedia, if you look at the network monitor – each way of selecting a search result will eventually send you to the result page, but the Special:Search URLs in between will look slightly different depending on whether you clicked a search result or selected it using the keyboard.

Screenshots/mockups:

BDD
GIVEN I am on a wiki using the Vector 2022 skin
AND Wikibase is configured to provide custom search results for Vector 2022’s search (instead of the default title-based search)
WHEN I search for a string
AND highlight a result using the arrow keys
AND press Enter
THEN I am redirected to the item I highlighted

Acceptance criteria:

  • Users can select and navigate to search results using the keyboard on Wikidata

Open questions:

Related Objects

Event Timeline

@Jdlrobson Could you provide some background on why the URL for a search result goes through Special:Search, rather than linking directly to the page? If we could make linking directly to the page the default behavior for search results, this would be one less customization needed for wikidata, but I'm assuming there's a reason it was set up this way.

Jdlrobson added subscribers: phuedx, EBernhardson.

Not sure. I looked through T249366 and T249299 and couldn't find any clues.

I notice the old Vector search does the same so we copied it across. I suspect it relates to analytics. Perhaps @EBernhardson or @phuedx can confirm that search results need to point to Special:Search and not directly to the page.

Regardless it seems understandable there should be an easy way to turn this behaviour off as an additional configuration option to wgVectorWvuiSearchOptions

I'm not sure why search results go back into the search engine to be redirected instead of going directly to the page. We return the full link in action=opensearch which is used in other contexts (browser go-bar, etc.). It has simply "always" been that way, at least for the last decade, and never revisited. I wouldn't be surprised if it was done that way as a simplifying factor long ago, or perhaps based on an assumption that search autocomplete might some day complete search queries in addition to page titles.

I don't see any particular reason the queries need to route back through the search engine instead of following the provided link directly.

@phuedx told me that there is a user setting where Special:Search will not redirect to an article whose title exactly matches the search term (search-match-redirect option, SpecialSearch::redirectOnExactMatch()). As far as I’m aware, it’s very rare for users to customize this setting, but it’s enabled by default on Wikimedia Commons (see the Leonardo da Vinci example in the task description), so it’s still relevant. We thought this was likely the reason that the search result links point to Special:Search.

But either way – I’m not proposing to change this :) as far as we’re concerned for Wikidata, we only need to bypass Special:Search for Wikidata search results, by setting the search result’s URL to the item page URL. Regular search results on other wikis could still go through Special:Search – they should just do that by loading the URL from the search result (which is a Special:Search URL), rather than by submitting the search as an HTML <form>.

I think we can merge this task into T317682: Make new Vector search navigate to search result URL when selecting search result using keyboard, it sounds like we have consensus that that’s the way to go (and we don’t need this open-ended parent task that was written to permit alternative solutions).