Instead of checking if the API result includes wikibase fields, I’d check whether WikibaseRepository is present in the siprop=extensions result – it feels more stable. You can add it to the same batched request.

It would be even better if we could just ask MediaWiki to “format this link”, but I couldn’t find any API endpoint that would do this.

Even better, thanks a lot.

Change #1230911 had a related patch set uploaded (by IKhitron; author: IKhitron):

[mediawiki/extensions/GlobalWatchlist@master] Recognize Wikibase when no wgGlobalWatchlistWikibaseSite system variable is set

https://gerrit.wikimedia.org/r/1230911

Test wiki created on Patch demo by IKhitron using patch(es) linked to this task:
https://d0b55f241f.catalyst.wmcloud.org/w/

I’ve just read T415306: Global Watchlist works wrong on Wikibase sites with items outside the main namespace, and I realized that you don’t actually need to know whether a site is a Wikibase site – you only need to know whether a particular page is in a Wikibase namespace. So you could solve both tasks by querying siprop=namespaces, and looking for defaultcontentmodel being wikibase-item, wikibase-property, wikibase-lexeme or EntitySchema. If the namespace of a page has one of these content models, its label needs to be queried, otherwise it doesn’t have to be.

Also, with this auto-discovery, there’s no reason anymore to determine which site is the Wikibase site – maybe I want to read my watchlist both from https://www.wikidata.org and https://test.wikidata.org at the same time, and both should have labels displayed.

In T415337#11548745, @Tacsipacsi wrote:

I’ve just read T415306: Global Watchlist works wrong on Wikibase sites with items outside the main namespace, and I realized that you don’t actually need to know whether a site is a Wikibase site – you only need to know whether a particular page is in a Wikibase namespace. So you could solve both tasks by querying siprop=namespaces, and looking for defaultcontentmodel being wikibase-item, wikibase-property, wikibase-lexeme or EntitySchema. If the namespace of a page has one of these content models, its label needs to be queried, otherwise it doesn’t have to be.

Also, with this auto-discovery, there’s no reason anymore to determine which site is the Wikibase site – maybe I want to read my watchlist both from https://www.wikidata.org and https://test.wikidata.org at the same time, and both should have labels displayed.

But this way there is a need to calculate it every refresh. You're right about multiple sites, but in this case maybe better to continue keeping tbe data in javascript runtime config object, but replace it with a list.

In T415337#11548767, @IKhitron wrote:

But this way there is a need to calculate it every refresh.

The way I wrote the patch for T412505, it does reload data on every refresh (I chose this solution to simplify the control flow, and because I didn’t feel this would be a performance bottleneck), but this isn’t actually technically strictly necessary: once you got the list of entity (“Wikibase”) namespaces, you can store the namespace numbers in an array, and then simply use .includes(entry.ns) to determine whether the page is in an entity namespace.

You're right about multiple sites, but in this case maybe better to continue keeping tbe data in javascript runtime config object, but replace it with a list.

To be honest, I’d even think about deprecating the configuration variable if we can get the data at run time: the fewer configuration variables, the easier the extension is to configure and the less mistakes one can make (what if one sets $wgGlobalWatchlistWikibaseSite to a non-Wikibase site?).

Very well. I need this patch soon, so I'll try everything you suggested in another one, in the next couple of days, maybe even today. The original idea already works. I'll finish the testings and open it to review, this will release the stalled tasks bottleneck, because I can't decide when changes will be merged, it depends on +2 people time.

Test wiki created on Patch demo by IKhitron using patch(es) linked to this task:
https://b65d6ea192.catalyst.wmcloud.org/w/

In T415337#11548901, @IKhitron wrote:

Very well. I need this patch soon, so I'll try everything you suggested in another one, in the next couple of days, maybe even today. The original idea already works. I'll finish the testings and open it to review, this will release the stalled tasks bottleneck, because I can't decide when changes will be merged, it depends on +2 people time.

You can base Gerrit changes on other changes without the other changes having been merged, which I think would reduce the urgency of the current task. Patch Demo should be able to handle this, e.g. https://9e25b0c40d.catalyst.wmcloud.org/wiki/Main_Page uses a such stacked change.

When working from the command line, it’s as easy as doing multiple commits; when using the Gerrit UI, I think this can be achieved by going to the base change and selecting Follow-up from the three-dot menu in the upper right corner.

Work on them yes, I already did it last week. But not open them to review, because the reviewers should see it on master, to be sure they not interfere in an unexpected way.
And one more thing, your suggestion about the namespaces will be very helpful in T415306, because now trying to edit a wikitext page in the main nameslace of Wikibase wiki blows up the Global Watchlist.

In T415337#11549049, @IKhitron wrote:

Work on them yes, I already did it last week. But not open them to review, because the reviewers should see it on master, to be sure they not interfere in an unexpected way.

Stacking changes is a pretty common thing, reviewers should be able to understand what it means. When changes are stacked, Gerrit doesn’t allow merging changes whose ancestors haven’t been merged yet.

And one more thing, your suggestion about the namespaces will be very helpful in T415306, because now trying to edit a wikitext page in the main nameslace of Wikibase wiki blows up the Global Watchlist.

Then why don’t you use that suggestion right now? Implementing a feature or fixing a bug in two ways (and getting both ways merged) is a waste of your and your reviewers’ time.

Because this change is about sites configuration, and it also should be open to review as soon as posdible. Now I think I will have some time later today, I'll start working on the change that fixes the main namespace part, and this array will be the part of it, of course. It's still the same day, but it will speed up the things. At least I never want to try to review a change that depends on not yet merged change, I know myself enough to avoid this.
UPD: Well, looks like I didn't have to return to this today. Don't know if there will be tomorrow. All this time is more chances to approve this change, which was otherwise marked WIP.

Change #1230911 merged by jenkins-bot:

[mediawiki/extensions/GlobalWatchlist@master] Recognize Wikibase when no wgGlobalWatchlistWikibaseSite system variable is set

https://gerrit.wikimedia.org/r/1230911

Test wiki on Patch demo by IKhitron using patch(es) linked to this task was deleted:

https://b65d6ea192.catalyst.wmcloud.org/w/

Test wiki on Patch demo by IKhitron using patch(es) linked to this task was deleted:

https://d0b55f241f.catalyst.wmcloud.org/w/