Page MenuHomePhabricator

Track implicit use of non-overridden wikidata description
Open, LowPublic13 Estimated Story Points

Description

Problem:
Edits on the repo that affect the clients are dispatched to the clients in order to show the change in recent changes and watchlist there as well as to purge the pages that are affected by the edit. The tracking that this relies on does currently not take into account edits to descriptions unless the client is subscribed to the whole Item (which we discourage). This is causing a problem since descriptions are implicitly used in various places like article header, search bar and link picker. Vandalism to a description might pass by the usual patrolling because it doesn't show up on watchlists and in recent changes. We need to make description changes show up there.

BDD
GIVEN an edit to a description of an Item on the repository in language X
WHEN saving the edit
THEN the change is propagated to all clients subscribed to the Item that have content language X
AND the change shows up in the client's recent changes and watchlists

Acceptance criteria:

  • a change of the description on Wikidata triggers that change to be propagated to the clients that are subscribed to that Item
  • 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

Open questions:

  • Can we determine if a local overwrite is in place for the description on that wiki and not propagate a change in this case?
  • What about locally overwritten descriptions via local magic word? We shouldn't track it in that case.

Notes:

  • We ultimately care about this because our editors want to be notified about a change happening on Wikidata that affects their article. This happens via Recent Changes and watchlist. They also look at listings like https://en.wikipedia.org/w/index.php?title=V._Gordon_Childe&action=info to see which other resources affect their article.
  • Purging or re-parsing the connected pages is not necessary – if the page directly used the description, it should already have an explicit usage on the description.

Event Timeline

Tgr created this task.Apr 9 2018, 7:33 PM
Restricted Application added a project: Wikidata. · View Herald TranscriptApr 9 2018, 7:33 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
LGoto triaged this task as Low priority.May 14 2018, 5:42 PM

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?

TomT0m added a subscriber: TomT0m.Jan 27 2020, 11:41 AM
Addshore added a subscriber: hoo.Jun 2 2020, 1:08 PM

@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:

Wikimedia Foundation (American non-profit charitable organization); Wikimédia France (chapitre de la Wikimedia Foundation en France)

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?

@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.

Nirmos added a subscriber: Nirmos.Mon, Nov 16, 11:08 PM