Page MenuHomePhabricator

Allow "go" search feature to reach messages
Closed, ResolvedPublic


As a translator or interested MediaWiki user, if I already know the key of a message, I want to reach it with one click from the main page, without special knowledge of the site's functioning being required.

Details follow if the issue is not clear enough for the reader.

Context: the new main page suppresses all the normal wiki elements, including the search bar. The new search, based on Special:SearchTranslations, doesn't search normal pages nor bring to pages with exact title matches (called "go" feature in monobook and internals, default for Vector's search). Two solutions come to my mind:

  • restore the normal search bar on the main page (the new one is made visible enough by its huge size),
  • make the new search work with exact title matches.

Workarounds used currently:

  1. entering the page title directly in the location bar (requires knowledge of the wiki's structure and of the browser location bar's functioning),
  2. entering the page title with interwiki prefix in the browser's search (requires a properly configured Firefox or other equally good browser and knowledge of the interwiki prefix),
  3. reaching the actual search bar (Special:Search-based) by clicking one of the five links at the very bottom of the page, or the username link in the personal tools (requires knowledge of the wiki's structure and it's very slow).

Filed on behalf of Nnemo:

Version: master
Severity: enhancement

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:53 AM
bzimport set Reference to bz60570.
bzimport added a subscriber: Unknown Object (MLST).

[offtopic] Just in case someone else likes it, I use this a script like this to easily get from a WMF wiki to Translatewiki:

// Add a link to Translatewiki above the interface messages
if ( 8 === mw.config.get( 'wgNamespaceNumber' ) ) {
		'//' +
			mw.util.wikiUrlencode( mw.config.get( 'wgPageName' ) ) +
			'/' + mw.config.get( 'wgUserLanguage' ),
		'See this message on'

I'd like to discuss expected behaviour here. We have Special:Translations for a list of all translations of a key. For example

You could search for "MediaWiki:Show" on the main page, or for "Show".

  1. What would be expected behaviour, and
  2. What would the algorithm look like that makes the decision?

Suggestion: I think the easier way would be a two click work flow. Similar to a "Did you mean". We can have Special:SearchTranslations do a check for keys that match the search term, and if it finds something, we could add a link to Special:Translations/<key> at the top of the search results.

How does that sound?

(In reply to Siebrand Mazeland from comment #3)

How does that sound?

It sounds like a separate feature requests, unless Nnemo disagrees on my interpretation of his request. The "go" search feature only checks title match; optionally you could pick an appropriate langcode subpage.

Nnemo set Security to None.

I think that @Nemo_bis has understood my request correctly. You may see the edited link to the discussion in the task's description.

Change 196140 had a related patch set uploaded (by Phoenix303):
Search message with message key without interwiki prefix

Change 226335 had a related patch set uploaded (by Phoenix303):
Search with exact title match

Change 226335 merged by jenkins-bot:
Search with exact title match

The "go" search feature only checks title match; optionally you could pick an appropriate langcode subpage.

More: that's definitely T70518: Special:SearchTranslations: allow messageid with ElasticSearch (we already take care of language scoring etc. there). This is for Special:Search-like "go" title match, while that's for the generic message key search.

Phoenix303 claimed this task.

This works, but let's consider the (believed) common scenario:

  1. Go to main page
  2. Write or paste message name to the search box, for example MediaWiki:Newarticletext/fr

This will not show the search message (unless your interface language is French), because it appends language=<interface language> to url parameters. I think we should ignore the language parameter in this case to "do what I mean".

Change 196140 abandoned by Nikerabbit:
Search message with message key

Does not rebase cleanly, and I think we can resolve our use cases in other ways.

Change 236403 had a related patch set uploaded (by Phoenix303):
Ignore language parameter in the query when url parameter 'language' is present.

Change 236403 merged by jenkins-bot:
Ignore the language query parameter when a title with language subpage is given.