- Go to en.wikipedia.org
- Search for 'iO'
Expected: Top result is displayed as 'iOS'
Seen: Displayed as 'IOS'.
This is set with {{DISPLAYTITLE:iOS}} in the page, and should probably show up here the same way.
Version: 1.23.0
Severity: normal
Description
Description
Details
Details
- Reference
- bz63975
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T26139 Use display title from page_props as the displayed title everywhere (tracking) | |||
| Open | None | T65975 Search results do not respect DISPLAYTITLE |
Event Timeline
Comment Actions
(In reply to Chad H. from comment #1)
Oooh, good spot. Should be an easy fix :)
Maybe not so much. We'll have to do this two ways.
Core will have to do database quer(y|ies) to get this data from page_props. Cirrus will override core's implementation to do this in a way that doesn't hit the database at all.
Not hard, just needs some noodling to do it cleanly.
Comment Actions
It would be great to have such a feature, especially for third parties that allow to override the title with Displaytitle with a completly different string (e.g. Page title is "Foo" and Displaytitle is "Bar"), which actually brings a completly different name in search result as shown on the article itself :)
(Would, maybe, fix T66703: Title autocompletion should also match display title and show it, too, or would make the fix for it a lot easier?)
Comment Actions
This seems like two different bugs: for wikis with $wgRestrictDisplayTitle set to true (ie. displaytitle is same as real title, apart from capitalization and formatting) the search view just needs to fetch the displaytitle and use it instead of the raw title. For other wikis, the displaytitle needs to be stored in the search backend, and used besides (or instead of) the raw title.
Comment Actions
Closing out low/est priority tasks over 6 months old with no activity within last 6 months in order to clean out the backlog of tickets we will not be addressing in the near term. Please feel free to reopen if you think a ticket is important, but bare in mind that given current priorities and resourcing, it is unlikely for the Search team to pick up these tasks for the indefinite future. We hope that the requested changes have either been addressed by or made irrelevant by work the team has done or is doing -- e.g. upgrading Elasticsearch to a newer version will solve various ES-related problems -- or will be subsumed by future work in a more generalized way.
Comment Actions
IMO this should be done at some point, in some cases it can be quite confusing (try searching for Tocopherol and you'll get A-Tocopherol instead of α-Tocopherol) and isn't really blocked on the Search team (it seems like a relatively simple change in the Special:Search frontend code and the search typeahead APIs). Probably not really specific to CirrusSearch either.
For other wikis, the displaytitle needs to be stored in the search backend, and used besides (or instead of) the raw title.
This probably should be a different task: if you enter the displayed title (which on non-$wgRestrictDisplayTitle wikis can differ arbitrarily from the real title) in the search box, it should still find the article (ie. it should work as a kind of alias). But I don't think it's worth the effort, and in any case it's not relevant to Wikimedia wikis.
Comment Actions
For what's worth, here is a fix at the cost of an extra database hit per search result, based on the reply by @Bawolff in this topic. Just add the following to LocalSettings.php:
$wgHooks['ShowSearchHitTitle'][] = function ( Title &$title, &$titleSnippet ) {
$dbr = wfGetDB( DB_REPLICA );
$displayTitle = $dbr->selectField( 'page_props', 'pp_value', [
'pp_propname' => 'displaytitle',
'pp_page' => $title->getArticleId()
] );
if ( $displayTitle ) {
$titleSnippet = $displayTitle;
}
};