The lack of this feature is causing problems on Wikipedia when a vandalism occurs: the vandalized Wikidata description will appear on the Wikipedia page on mobile, and Wikipedians can't easily spot it because the edits don't show up in their Wikipedia watchlist. (see a recent discussion on French Wikipedia here).

Tracking edits of Wikidata descriptions was possibly not a priority when the Wikidata descriptions were not displayed on Wikipedia, but now with the description displayed on the Wikipedia app, we need to give Wikipedians information and control about what's happening with descriptions.

@Addshore Do you think this is something we could take on Campsite?

@hoo and I briefly looked at this in storytime today but need more input from product and should be deferred until the next storytime we are all together.

One thing I want to add here is that, while this feature is pretty vital, it wouldn't be as useful currently, given that wikidata edits are by default hidden from watchlist and recent changes, this is rather easily fixable (by splitting the filters of wikidata edits which is rather simple), we should start reducing the noise of wikidata edits in rc/watchlist heavily and start showing them by default.

Task breakdown notes:

• We understand the AC “a change is only propagated for a change of the description if the content language of the client wiki is the same as the language of the description that was changed” to mean that a recentchanges row is only created if the language matches. On the repo, we don’t know anything about the client’s entity usage, nor its content language, so the repo will always inject the ChangeNotification job into the client’s job queue.

• We expect that no changes to Wikibase Repository will be needed. Any potentially affected wiki will already be subscribed to the entity through a “title” and “sitelink” usage (edit: “title” usage not guaranteed to be there, but “sitelink” usage added in ClientParserOutputDataUpdater::updateItemIdProperty(), which also adds the wikibase_item page prop), and the repo will already send a ChangeNotification job to all clients. It’s up to the clients to now react to not only the real usages registered in their wbc_entity_usage table, but also to the implicit description usage in their content language.

• We will hard-code the knowledge that the implicit use we support is “description in the client’s content language”. Of course, nothing stops the client wiki community from creating a gadget or something else which effectively uses other parts of the item implicitly (e. g. getting the Japanese label through JavaScript), but we don’t support tracking that kind of implicit use or adding it to the recent changes / watchlist.

• The implicit use will probably be synthesized in an implementation of the UsageLookup interface (getUsagesForPage() and getPagesUsing() methods), adding to the current database-based implementation (wbc_entity_usage table).

Edit: see also subtasks T265897, T265898, T265899.

It looks like the mobile search actually uses the description in the page content language, not necessarily the wiki content language – see the search results for Wikimédia on Meta:

That’s on the mobile website; I haven’t been able to test the mobile app yet, since there’s no page linked to Wikidata with a nonstandard content language on English or German Wikipedia, but I assume it behaves the same way there, since it should use the same underlying API.

@Lydia_Pintscher should we track implicit usage in the page content language instead of the wiki content language?

In T191831#6570925, @Lucas_Werkmeister_WMDE wrote:

@Lydia_Pintscher should we track implicit usage in the page content language instead of the wiki content language?

Good point. Since we care about triggering notifications for what is shown to the readers we want to take the page language if that's what is being used in the mobile search, yeah. https://meta.wikimedia.org/w/index.php?title=Wikim%C3%A9dia_France&action=info&mobileaction=toggle_view_desktop also shows the French description. So I hope this is consistently used.

The acceptance criteria doesn't specify how this feature interacts with "Show Wikidata edits in your watchlist". I assume it's bundled into that option, but it would be nice to be explicit about that.

It's unclear to me whether it's good to bundle all the Wikidata edits into the same option on the watchlist. Given experienced Wikipedia users options to configure a feature like this to show them the edits that they want to see and not those that they don't want to see helps with acceptance of Wikidata in the Wikipedia's even if it bloads the UI and makes the configuration more complicated for new users.

It might be possible to convince a wiki like dewiki to activate showing changes in German Wikipedia descriptions by default but not to convince them to show edits to Wikidata statements by default (especially as long as the statements can't be filted for those that affect Wikipedia).

Yeah this is currently bundled into the same option. We have a different ticket for looking into more filter options there at T216265. Since that's conceptually more tricky I wanted to get this out of the way first.

The ticket looks to me more like it's about the option of filtering within Wikibase which is a slightly different concern then the filtering over at Wikipedia. At Wikipedia we have the situation that plenty of editors don't want to see Wikidata changes that don't affect Wikipedia.

It might be that there's a shared foundation for both but the user experience needs are different.

The change is now enabled, if you encounter any issue, feel free to report it here!

In T191831#6662872, @ChristianKl wrote:

The ticket looks to me more like it's about the option of filtering within Wikibase which is a slightly different concern then the filtering over at Wikipedia. At Wikipedia we have the situation that plenty of editors don't want to see Wikidata changes that don't affect Wikipedia.

It might be that there's a shared foundation for both but the user experience needs are different.

Ah understood. So I think there are two issues here then. One is seeing changes that don't actually affect the article. This should be very rare by now and if it's happening it should most of the time be due to a template that is accessing the whole Item instead of more finegrained statements. The other issue is about wanting to filter the remaining changes that do actually affect the article and yeah I guess that could be different on Wikipedia and Wikidata indeed.