After T250144 is done, the getting of the actual descriptions should be implemented in the WikibaseClient extension.
At the moment the Wikibase extension implements similar functionality for query api (prop=description)
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| rest: Implement SearchResultProvideDescription hook | mediawiki/extensions/Wikibase | master | +138 -0 |
@Aklapper the task is about 'ShortDescription'. But I can't find the proper tag/project with a similar name.
@Peter.ovchyn: Thanks. If this is about the extension https://www.mediawiki.org/wiki/Extension:ShortDescription then this extension is currently not deployed on any Wikimedia sites. (Is that planned? If yes, is there a task for that?) Would be good to add that to the task summary to have more clarity - currently it only says "in extension". Looks like there is unfortunately no dedicated tag so nobody can find tasks about that extension, indeed.
According to T245674, the description should come from Wikidata. So the extension in question would be MediaWiki-extensions-WikibaseClient.
WikibaseClient would need to implement the new hook, with code similar to the one in Wikibase\Client\Api\PageTerms. Ideally, logic could be factored out of the PageTerms API modules, so it could be re-used for the new hook handler.
I might miss some context on what "description" is meant here. Is this the "description" as in the sense of what https://en.wikipedia.org/w/api.php?action=help&modules=query%2Bdescription provides (i.e. "description" from related Wikidata item, possibly local overridden using a magic word or so)?
If that's the case, I figure there is a reason why this API couldn't be use for this work here?
Regarding implementing/adding this to WikibaseClient: I am not opposing (I don't know the context, hence I cannot form an opinion), but, especially if we the local wiki overrides are also intended to be covered for your use case, I would like to resurface that when prop=description API thing was initially created there was a discussion on does it really fit into Wikibase, and WMDE team was rather skeptical about it. The initial implementation has been added to WikibaseClient extension only :for speed (of implementation, performance was not meant here) and convenience" (see https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/master/client/includes/Api/Description.php#14). If now we're seeing the growing need for similar functionality (as expected), it might be a good time to re-open this conversation.
Oh, I totally forgot about the local overrides. Yes, indeed.
So, the equivalent existing API modules in Wikibase is Wikibase\Client\Api\Description, not Wikibase\Client\Api\PageTerms.
If that's the case, I figure there is a reason why this API couldn't be use for this work here?
We are building a REST API endpoint for type-ahead completion. The completion suggestions returned should by accompanied by a disambiguating "description", very much like what Wikibase does for its own search box. The core REST API doesn't allow API endpoints to be combined in the way that the Action API'S generators and property modules do, so the search endpoint itself has to know about the descriptions (that is, it calls a hook). We plan to do the same for thumbnails, by having PageImages implement the respective hook.
Regarding implementing/adding this to WikibaseClient: I am not opposing (I don't know the context, hence I cannot form an opinion), but, especially if we the local wiki overrides are also intended to be covered for your use case, I would like to resurface that when prop=description API thing was initially created there was a discussion on does it really fit into Wikibase, and WMDE team was rather skeptical about it. The initial implementation has been added to WikibaseClient extension only :for speed (of implementation, performance was not meant here) and convenience" (see https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/master/client/includes/Api/Description.php#14). If now we're seeing the growing need for similar functionality (as expected), it might be a good time to re-open this conversation.
I agree that it would be cleaner to have a separate extension for integrating the description with search, instead of making this something that WikibaseClient itself does. I'd argue that the hook handler to be added is very similar to the existing Description API module, and should live wherever that module lives. I also expect the new code to be roughly the same size as the existing Description class, ~150 lines plus tests.
Since the purpose of that separate extension would be to use information from Wikibase to augment search results, I'd say it's up to the Wikidata team to decide if and when they want to pull this functionality out of WikibaseClient. I suppose one could also argue that such an extension should be owned by the WMF search team - it's basically glue between two domains, so either team could be responsible. For practical reasons, it seems that leaving ownership of this functionality with the Wikidata team seems simpler - simply because you already own that functionality now.
So, what would be a strategy to push this forward? Can I start changing Wikibase, or should we create another one ticket to move the functionality to a separate extension?
You can make a patch for Wikibase, modeled after the Description API module. Maybe some code can be factored out and reused. Once the patch looks good, we'll try to get review from the Wikidata team.
Change 592397 had a related patch set uploaded (by Peter.ovchyn; owner: Peter.ovchyn):
[mediawiki/extensions/Wikibase@master] WIP! rest: Implement SearchResultProvideDescription hook
Change 592397 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] rest: Implement SearchResultProvideDescription hook