Wikidata:Watchlist integration improvement input

From Wikidata
Jump to navigation Jump to search
Development plan Usability and usefulness Status updates Development input Contact the development team

When someone edits an item on Wikidata a notification is sent to all Wikipedias and sister projects that have an article on the topic. An entry in recent changes will be shown there. Anyone who watches the article will also get an entry in their watchlist. The whole system is currently not very good. This page collects input on how to improve it. If you want to stay up-to-date on progress about this please watch phabricator:T90435.

Initial input[edit]

This is working with the current watchlist integration[edit]

  • A lot of people get to see changes on Wikidata to help smaller projects with keeping the data quality high. This is set off by people turning them off completely because they get to see too many changes that are not relevant for them. --Lydia Pintscher (WMDE) (talk) 15:39, 11 March 2015 (UTC)[reply]
  • your input and signature

This isn't working with the current watchlist integration[edit]

  • It does not work for anyone using the "enhanced recent changes" setting. (phabricator:T46874) --Lydia Pintscher (WMDE) (talk) 15:39, 11 March 2015 (UTC)[reply]
  • Preview of changes when using the gadget Navigation popups. Preview should be human readable. At the moment, this gadget isn’t even useful on Wikidata’s internal watchlist. —MisterSynergy (talk) 17:23, 11 March 2015 (UTC)[reply]
    • +1, I triage all my (massive) watchlists by slowly moving the mouse up the line of "diff" or "prev" links, using navigation popups to preview the changes. Crosswiki navpopups would aid this, amongst many other things. --Quiddity (talk) 17:49, 11 March 2015 (UTC)[reply]
  • Do we have watchlist integration? Multichill (talk) 20:12, 11 March 2015 (UTC)[reply]
    @Multichill: yup, see "Show Wikidata edits in your watchlist" at enwiki, dewiki, enwikivoyage, etc. :) (see also many related phab tasks which could use some triaging/cleanup) Quiddity (talk) 22:27, 16 March 2015 (UTC)[reply]
    @Quiddity: I guess the irony didn't get across :-). I use the extended watchlist and Wikidata edit's don't show up in that one. So from my point of view we don't have watchlist integration. Multichill (talk) 16:59, 17 March 2015 (UTC)[reply]
  • Hi. The fact that Wikidata changes aren't integrated to extended watchlist is a really painful point, while this bug has been identified for so long time... In my point of view, it explains partly the current mistrust we can note in French Wikipedia (here). --H4stings (talk) 09:39, 7 January 2016 (UTC)[reply]

This is how I want watchlist integration to work[edit]

  • Nur Änderungen anzeigen die auch einen Einfluss auf den Artikel in der Wikipedia in der ich mich befinde hat ...Sicherlich (talk) 16:42, 11 March 2015 (UTC)[reply]
  • Möglichkeit Interwiki-Änderungen auszublenden ...Sicherlich (talk) 16:42, 11 March 2015 (UTC)[reply]
  • Lots of filter options. —MisterSynergy (talk) 17:45, 11 March 2015 (UTC)[reply]
  • Separate filter options for wikipedia and wikidata changes (e. g. show WP bot edits, but not WD bot edits). —MisterSynergy (talk) 17:45, 11 March 2015 (UTC)[reply]
  • Option to toggle patrolled changes, when these are not available at WP (as currently at dewiki). —MisterSynergy (talk) 17:45, 11 March 2015 (UTC)[reply]
  • By default, we should assume that Wikipedians are not also generally interested in Wikidata except insofar as it affects them. Only changes that change the displayed content should be displayed on watchlists. This includes: Local-language descriptions if they are used on the mobile site, statements and local labels when they are used on the page, and interwikis. I realize this will drastically lower the number of eyes on the items, at least on the short term, but I think on the long term this will result in more usage of the data (since it can be easily tracked), and thus eventually more actually interested eyes watching the data. --Yair rand (talk) 17:51, 11 March 2015 (UTC)[reply]
  • Clever cascading usage of CSS classes on watchlist: (a) changes on any item on my WD watchlist (b) changes on any item on my WP watchlist (c) only changes that affect data used within WP (presumably label/description of my language and properties, but not interwikis). Users can then use common.css to highlight whatever they want to look at in detail without having to filter everything else. —MisterSynergy (talk) 18:01, 11 March 2015 (UTC)[reply]
  • Most Wikipedia editors won't care if a link is added from a Wikidata item, to a Wikipedia in a language they don't speak. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 11 March 2015 (UTC)[reply]
  • Possibility to toggle (show/hide) bots, unregistered users, registered users. Especially, I would like to hide bots on Wikidata. --Leyo 21:54, 11 March 2015 (UTC)[reply]
  • Speaking about watchlists, there should be only one watchlist for all Wikimedia projects in the first place that all changes in the pages you watch on whatever wiki should be included in. If something on Wikidata is changed that is part of a Wikipedia article you should make it appear in the watchlist as an edit to the Wikipedia article so that a patroller can see at once what has been changed in terms of content in the article. I for one use the navigation popup gadget for reading my watchlist. So there should also be an integration into that.--Aschmidt (talk) 23:46, 11 March 2015 (UTC)[reply]
  • Saying something more descriptive than "Item changed". --Rschen7754 01:09, 12 March 2015 (UTC)[reply]
  • I would support Aschmidts comment - we need an aggregated watchlist for Wiki projects. --Aschroet (talk) 18:09, 13 March 2015 (UTC)[reply]
  • your input and signature

Ideas for new useful features around watchlist integration[edit]

  • Quite a common template design on client wikis is for a template that holds a value, that it compares to Wikidata, and then adds the page to a maintenance category if two no longer match. (There may then be scripts for AWB and similar to let a user then easily update the wiki page). Is there a mechanism for one of these templates changing state to also ping the user's watchlist?
(The disadvantage of this model is it doesn't send any feedback, positive or negative, back to Wikidata; approval is required separately on all wikis; and with large scale usage the number of pending changes to get reviewed on any particular wiki could get very large. Still, it does seem to be being used; and it may make sense for properties that are expected mostly to be written once, and then not updated). Jheald (talk) 16:16, 11 March 2015 (UTC)[reply]
  • Provide an option to separate WD and WP changes into two lists; separated lists could be displayed on tabs within <div id="mw-content-text"></div>; switching via CSS/JS without page reload; the tab header could include the number of unread/unseen changes on each list. Reason: that might be a clearer breakdown of changes in many situations than the current merged watchlist including changes from both WD and WP. —MisterSynergy (talk) 18:58, 11 March 2015 (UTC)[reply]
  • "Vertrauensliste" - Es gibt benutzer denen vertraue ich. diese Änderungen könnten bspw. stets "normal" dargestellt werden statt fett für noch ungelesenes. Die Liste sollte nur vom autor selbst zu lesen sein. Dies wäre aber etwas nicht nur für WD sondern für mediawiki im allgemeinen. ...Sicherlich Post 21:31, 11 March 2015 (UTC)[reply]
    Sicherlich, auch Benutzer denen du prinzipiell vertraust machen Fehler. Prüfst du solche Änderungen auf deiner "normalen" Beobachtungsliste nie? --Succu (talk) 22:05, 11 March 2015 (UTC)[reply]
    Ich spreche jetzt nicht für Sicherlich, aber Sicherlich kann ich von mir sagen, dass ich Änderungen von Benutzern, denen ich vertraue, mir nicht immer anschaue, sondern abhängig von meiner Zeit und dem Thema. Je näher mir ein Thema ist, desto mehr interessiert mich auch, was ein mir vertrauter Benutzer geändert nicht. Wenn Sicherlich ein polnisches Dort bearbeitet, wo ich nur mal zufällig durchgekommen bin und ein Foto in den Artikel eingebaut habe, so werde ich mir das Sicherlich nicht anschauen. Raymond (talk) 13:35, 12 March 2015 (UTC)[reply]
    Succu: Sicherlich sieht das wie Raymond :) - natürlich gucke ich auch bei "vertrauten" mal nach. aber meine zur Verfügung stehende Zeit ist begrenzt. vielleich wäre sogar ein ausblenden von edits sinnvoll. Dann kann ich effektiver die beobachtung abarbeiten. wenn mir dann doch noch zeit überbleibt kann ich wenn mir so ist ja trotzdem noch gucken ob Raymond wirklich ein Foto eingestellt hat das qualitativ okay ist :P ...Sicherlich Post 23:04, 13 March 2015 (UTC)[reply]

First iteration on feedback by dev team[edit]

The dev team took the above input and discussed it. The outcome of this is below. The next step is for the dev team to make one proposal for filtering options etc.

Important points:

  • In theory many people should see changes from Wikidata on their watchlist right now. In practice they don't for two reasons:
    • missing support for enhanced recent changes
    • flooding of their watchlist with changes they consider irrelevant and therefor they turn off showing Wikidata changes completely
  • Why do people consider it flooding their watchlist?
    • contains changes not relevant to them
    • the edit summary is not meaningful

Main conclusions:

  • We should offer a more meaningful edit summary.
  • We should support enhanced recent changes. (Also look into mobile watchlist.)
  • We should either offer more filters or make smarter choices about what to show in the first place.

Additional points:

  • Support for a diff view functionality like navigation popups offers it would be great to have.
  • Use CSS classes to allow people to hide or highlight different kinds of changes.
  • Keep in mind possible future global watchlist.
  • Solution needs to work the same way on watchlist and recent changes for filtering and edit summaries.


  • People seem to mostly be interested in the changes that actually affect the article on their watchlist.
  • This is a list of all things you can meaningfully filter by. Which of those are useful and how should they be grouped? Which ones should we offer? What are sane defaults for the ones we offer?
    • labels (all languages/language of current project/language of current project + fallbacks)
    • aliases (all languages/language of current project/language of current project + fallbacks)
    • descriptions (all languages/language of current project/language of current project + fallbacks) Keep in mind also descriptions being used on mobile without being actually included in the article but still affecting its presentation on mobile.
    • sitelinks (connecting/disconnecting of the item) Should we differentiate between changes to sitelinks for the same project vs sister projects (because of in other projects sidebar)?
    • badges Only for current project? What about sister projects and other languages?
    • statements (only if used on article?)
    • discussion page of the item
    • bot edits
    • patrolled edits
  • How do we handle changes to items that are transcluded via arbitrary access?
  • For options that can affect Wikipedia changes and Wikidata changes (like show bot edits): Should this be one option or two?

Open questions:

  • Should we or should we not separate the watchlist for Wikipedia changes and Wikidata changes. How much? (Tabs, completely different?)
  • Should we continue to group different changes to the same item?

 – The preceding unsigned comment was added by Lydia Pintscher (WMDE) (talk • contribs) at 15:09, 31. Mär. 2015‎ (UTC).


Hi Lydia Pintscher (WMDE), two comments:

RuWiki Gadget WEF WatchList Example
  • 1) A proof-of-concept/ example for extended watchlist support for WP+Wikidata was made last year by Vlsergey, see screenshot and here ("There is a new gadget in ruwiki that can be used to display wikidata changes in extended watchlist... Currently only for ruwiki..."). But unfortunately the user has closed the tool and left wikidata, after in September 2014 his Proposal: enable FlaggedRevs on wikidata and alternative proposal to get WP-vandalism-via-wikidata under control were ignored (Vlsergey: "The main idea of Wikidata is to provide _reliable_ source of data. If community would decline to enable this feature on Wikidata in near future then, at least in Russian Wikipedia, we will need to disable using wikidata completely on stabilized pages and living person pages, or provide some intermediate cache with manual update from Wikidata. Still this kind of workaround will be much better than situation when some vandal changing date of birth or adding date of death to page that is stabilized and shown on front page.") "Stabilized pages" in ruwiki are similar to all articles at dewiki/gesichtete Versionen. And as was demonstrated months before, a vandal can change, via wikidata, images on Wikipedia articles to dog shit images, despite flagged revisions and without watchlist detection. In Oktober 2014, one month after the ruwiki anti-datavandalism proposals were dismissed, another wikidata issue (T73519) led to the inability to edit thousands of ruwiki articles linked to wikidata item Germany Q183... I think this shows vividly that wikidata-WP-watchlist integration is not enough to fix underlying, fundamental problems.
It's a bad mistake that wikidata devs/Lydia refuse to built data-protection levels for wikidata ("Bevor ich weitere Sperrmechanismen einbaue würde ich gern noch ein paar andere Sachen probieren und schaun ob die ausreichend vor Vandalismus schützen. Dazu gehört zB das Vergleichen mit anderen Datenbanken. Wenn das nicht erfolgreich ist ziehe ich weitere Sperrmechanismen in Betracht." [1] -So, other ideas have to fail, before even considering to build data-protection levels: that means months-year of inactivity and zero development). But at more prominent pages, Wikipedians were shown a different announcement ("Was noch kommt - Auszug aus bald und in weiter Zukunft: ... Eventuell feingranularere Sicherung einzelner Bestandteile eines Datensatzes." [2]) As a Wikipedian i get the impression that the wikidata rationale is something like this: Why try to fix wikidata vandalism at wikidata, if we can just flood the stuff to Wikipedian watchlists and expect the humans to do the clean-up?
Current Wikidata integration on the client: "item was changed". Aha. ^^ Can be anything, urdu, bot or... Nah, Pass!
  • 2) "People seem to mostly be interested in the changes that actually affect the article on their watchlist. Which ones should we offer? What are sane defaults for the ones we offer?"
    • sitelinks (connecting/disconnecting of the item) show changes to Wikipedia sitelinks: restoring the status quo ante wikidata. (cf. wikidata anti-vandalism method [3][4][5]). including Help:Sitelinks#Badges, but only local wiki badges.
    • statements, only if used on WP article!!
BTW, i already wrote this same thing over a year ago, at Wikidata:Contact_the_development_team/Archive/2014/02#Wikipedia_Watchlists and Wikidata:Project_chat/Archive/2014/02#Wikipedia_watchlist.
And that's it. Do not spam wikipedia watchlists with wikidata stuff. Not wikidata discussions, not wikidata descriptions, not wikidata labels, not aliases. ("I want to have many people see all changes on an item so they can help keep Wikidata's data in good shape. They can even do this for languages they don't speak and they can definitely do this for data that isn't used in their article." Lydia) No. It's not your call as wikidata devs to decide by default, that Wikipedians attention should be diverted to wikidata issues. --Atlasowa (talk) 20:12, 2 April 2015 (UTC)[reply]
Atlasowa: That's why we're having this whole input collection and discussion here. You claim I don't want to fix the issues on Wikidata itself but instead just offload it to Wikipedia. That's not true. Fixing issues at the source is important and it is exactly why I am doing things like improving constraints checks, enabling integrated and easy checks against other databases, improving references, redesigning the user interface and so on and so on. But it is of course not the only thing. I am trying hard to make this work for everyone by having this conversation. The options I lined out above are clearly overkill. It is a list of everything possible. The question is where to draw the line. --Lydia Pintscher (WMDE) (talk) 07:05, 3 April 2015 (UTC)[reply]

Idea: Since there alredy is a preferences tab for the watchlist, how about giving a lot of freedom for the user to set these filtering options there? If so, this discussion could also be about what would be enabled for a user when the functionality is deployed. Ainali (talk) 07:57, 5 April 2015 (UTC)[reply]

Another comment[edit]

Hi @Lydia Pintscher (WMDE): Not sure if this is the right place to mention it, and I also left a not on Project chat. I see you're working on watchlist cluttering improvements, and here is an "issue" that I have not seen mentioned elsewhere before:

This edit on author (Q482980) was raised on my frwiki watchlist for fr:Amine Bouhafa (and 60 others), but neither the frwiki article nor item Amine Bouhafa (Q19543985) have a link to author (Q482980). They however link to composer (Q36834), a sub-class of author (Q482980). fr:Amine Bouhafa is in my frwiki watchlist, fr:auteur is not. I think it is a bit overkill to show edits to all mother classes of an item linked in a property of the WD item equivalent to the WP article in my watchlist (notwithstanding all other "cluttering" issues mentioned above).

Can you please confirm that this is either a bug, the expected behaviour, or something already listed in the watchlist integration improvement under way? Many thanks! Place Clichy (talk) 13:55, 1 March 2016 (UTC)[reply]