The hack added in https://gerrit.wikimedia.org/r/#/c/244698/ will do this, but it should be replaced by a non hack.

There are open conceptional issues with doing this in a proper way. Let's create a separate ticket once we figured out how to solve it.

Notes from today's story time:

• API allows to ask for a description, and uses the connected item for that.
• Project page on Wikidata can be connected to *one* item, which links to *one* connected page on enwiki.
• Problem arises when a sitelink links to an other item. This item then does have *two* ways of resolving the description API request.
• Suggestion: Special case only for the item namespace. Items are always exclusively connected to themself and can *not* have sitelinks to other items. Plus disallow sitelinks to the item namespace on the item namespace, then this is consistent.
• Todo investigation: How many sitelinks link to items on wikidata.org?
• Next: Find valid use cases and decide based on them.

In T115117#1829896, @Lydia_Pintscher wrote:

Notes from today's story time:

• API allows to ask for a description, and uses the connected item for that.
• Project page on Wikidata can be connected to *one* item, which links to *one* connected page on enwiki.
• Problem arises when a sitelink links to an other item. This item then does have *two* ways of resolving the description API request.
• Suggestion: Special case only for the item namespace. Items are always exclusively connected to themself and can *not* have sitelinks to other items. Plus disallow sitelinks to the item namespace on the item namespace, then this is consistent.
• Todo investigation: How many sitelinks link to items on wikidata.org?

there are no sitelinks to items or properties on wikidata.

the sitelinks to wikidata pages are only for categories (a lot of these babel categories), help pages, lua modules, Special:Recentchanges, templates and project (Wikidata) namespace.

• Next: Find valid use cases and decide based on them.

I ended up looking into this task as part of T255110 and wondered why this ambiguity should only affect the pageterms API and not the Lua code. But the situation there is slightly different; rather than pageterms’ “give me the terms for this page/title”, Lua has different functions:

• “give me the terms for this Entity ID” (getLabel, getDescriptionWithLang etc.)
• “give me the Entity ID for this page/title” (getEntityIdForTitle)
• “give me the terms for the current page” (getLabel, getDescriptionWithLang etc. without Entity ID argument)

Only the last one is potentially ambiguous, and if you’re running Lua that looks at the current page, then the current page can’t be an Entity page, since Items, Properties etc. don’t contain wikitext, so it’s never ambiguous (it can only mean “terms of the linked Entity”, because the current page can’t be an Entity).

…Unless you use the action=parse API, specify the title of an Entity, but set the contentmodel=wikitext and the text to some wikitext that calls a Lua module. Then you can ask for the terms of the current Item page, and the API will return the terms of the Item linked to that Item (rather than, like pageterms with the hack mentioned in T115117#1719166, the terms of the Item you specified in the title).

And also, the “Entity pages don’t contain wikitext” assumption is in fact violated by WikibaseMediaInfo. For the pageterms API, this was reported at T215292; I don’t know if anyone has so far tried to use the Lua term functions on File/MediaInfo pages and found+reported unexpected results. (Testing locally, it seems that mw.wikibase.getLabel() never returns a label on a File/MediaInfo page, regardless of whether it’s linked to an item or not.)

I'm tentatively removing MediaWiki-extensions-WikibaseClient here, because this is not actually about changing functionality on the client, but rather bringing something that works on the client also to the repository. Or did I get something wrong?