Issues relating to the search engine in MediaWiki core. This includes API, backend code, and user interfaces relating to Special:Search, Special:PrefixIndex, Special:AllPages, and OpenSearch.
For the search engine on Wikipedia and sister projects, see CirrusSearch instead.
Maintained by: Discovery-Search
To my knowledge when clicking a search suggestion from an autocomplete drop-down we route to /w/index.php?title=Special%3ASearch&search=$selectedTitle, this will do an extra hop on the "go" feature which should target to the right page if it exists. I'm not sure I remember why this was done this way but possibly to avoid directing to a 404 if the page was deleted (old cached search response?) but rather redirect to fulltext search? @EBernhardson might know more. I'm not entirely clear if you need to do the same for wikibase. As to how it's done I'm not sure, I think some of it is in mediawiki.skinning.typeaheadSearch (esp. urlGenerator.js).
Yeah, I think we use the url from the response. Should we use mw.Title.newFromText( result.title ).getUrl() instead? (Probably worth checking if the API puts anything special in the returned URL that we’d be interested in preserving.)
Is it possible that the wikibase frontend code is using the url returned by the search endpoint at https://m.wikidata.org/w/api.php?action=wbsearchentities&format=json&search=da&limit=10&errorformat=plaintext&language=fr&uselang=fr&type=item ?
I think that other search frontends generally reconstruct the target URL using mw.config.get( 'wgServer' ) or something similar? I'm definitely not an expert here...
Notes:
Tagging experience after talking to Olga as we might run this as a small experience tied in with the new upcoming search initiative.
Since this only needed a code deploy and not a re-index, it went out pretty quickly. claſs → class on enwiki now, along with all the other test cases on enwiki and enwikt.
@Ioaxxere I wouldn't say that the "normalizer" tries S before s for ſ.. rather, there is accidental normalization because ſ is one of the few characters where lowercase(uppercase(char)) != char. It was the lack of explicit normalization that caused the problem... every individual step makes sense in general, but their edge cases happened to line up just right in this instance.
@TJones Thanks for the writeup. So it seems like the paradoxical situation arises because, in response to ſ, the normalizer tries S before s. Given that ſ is always s and never S in actual usage, this seems suboptimal, so I support the early normalization idea. But I am really surprised that all of your benchmarks showed string operations taking at least a full microsecond (an eon by modern CPU standards), including when nothing is changed at all! Is it possible that the actual performance killer is just PHP overhead? It seems like PHP supports FFI, though I doubt it will come to that.
I agree with T174057#4578576 that where to use UI language instead of content language for namespace names can be debatable. However for the Chinese case, the content language itself can change (in the chosen variant sense). The zh language code is mostly for technical purposes mentioned above (like preventing the title name in URL changing depending on the variant), and is rarely used as a display language.
Please check the following URLs instead:
The MessagesZh namespace names are intended to be in English to use them as the canonical namespace name in URL, prevent lean to one of the language variants and prevent technical issues related to the zh language converter.
The translation file for that wiki are in English.
Change #1176523 merged by jenkins-bot:
[mediawiki/core@master] Add early normalization to TitleMatcher
Change #1149401 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/core@master] Fix incomplete search-thumbnail-extra-namespaces-message docs
Reason:
Fixed via https://translatewiki.net/wiki/Special:Diff/13333590
Change #1149401 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):
[mediawiki/core@master] Fix incomplete search-thumbnail-extra-namespaces-message docs
Thanks for looking into ways to address this!
Change #1176523 had a related patch set uploaded (by Tjones; author: Tjones):
[mediawiki/core@master] Add early normalization to TitleMatcher
Thanks for testing, and no worries! Better to file a bug report about something that's already been reported, than to not file one about something that isn't yet known about ^^
@A_smart_kitten: Aha, no, the bug does not occur if I switch to Vector Legacy or Monobook. This explains why I only started encountering it within the last few months, because that's around when I switched to Vector 2022. Apologies for the redundant bug report, then.
@-sche thanks for the report! If you temporarily switch the selected skin in your preferences, does this behaviour occur on skins other than Vector (2022)? If not, I wonder if this might be the same issue as T333608: [Timebox] Vector 2022 search navigates to the wrong result if you type after selecting an item using arrow keys.
CirrusSearch is the piece of software to tag for search backend issues on Wikimedia wikis; MediaWiki-Search for frontend :)