Page MenuHomePhabricator

[EPIC] Address vandalism issues with showing Wikidata descriptions on mobile
Open, LowPublic

Description

Mobile readers now see previously saw a Wikidata description when searching the English Wikipedia (T152743). Concern (https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#Hard_to_detect_mobile_vandalism) has been raised that it is hard for editors to know if this description has been vandalised (potentially introducing serious - libellous - errors); on desktop Wikipedia the wikidata descriptions can only be seen by manually clicking through to the Wikidata item.

Possible solutions

Wikidata descriptions in desktop

One solution might be to show the Wikidata description at the top of articles, under the title, to logged in editors, with an Edit button to quickly take them to Wikidata to fix any errors (which was explained in more detail in T141230).

Pros:

  • Editors are on desktop

Cons:
?

Providing editing experience on mobile

Stage 1
Let editors know where they can edit the description

search bar copy 7.png (1×750 px, 182 KB)

search bar copy 9.png (1×750 px, 159 KB)

Stage 2
Let editors edit the description on mobilefrontend

search bar copy 8.png (1×750 px, 158 KB)

For more info please check the draft. I didn't list this as a blocking task, the ticket is to triage, asses complexity and dev time required.

Pros:

  • There is an easy path to editing from mobile

Cons:

  • Most of our editors are not on mobile
  • Could actually increase vandalism by making editing easier

Wikidata edits in Wikipedia watchlist

Another would be to show relevant Wikidata edits in the Watchlist. I notice I have a "Wikidata" checkbox there, but editing a Wikidata description doesn't show up on the watchlist even if it's checked.

Cons:

  • Complex problem. Part of a bigger problem which is showing foreign project edits in your home project watchlist.

Event Timeline

I wonder why no one so far has created a gadget to show these descriptions in desktop articles. Seems pretty easy to do and will allow people to experiment before including it into the core software.

I have!
mw.loader.load('/w/index.php?title=User:Jdlrobson/wikidataInfobox.js&action=raw&ctype=text/javascript');

(although apparently it only works on the mobile skin now.. but easily fixable)

@Jdlrobson: How is T141230 (for mobile web) a duplicate of this task (for desktop)?

Jdlrobson renamed this task from Allow logged in users on desktop Wikipedia to see and quickly edit Wikidata descriptions to [EPIC] Address vandalism issues with showing Wikidata descriptions on mobile.May 16 2017, 9:55 AM
Jdlrobson added a project: Epic.
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

Just a note that I removed the Wikidata edits in watchlist part because I just didnt have the right setting enabled; I misunderstood, and have it set up properly to show wikidata edits in watchlist now.

Thanks @Samwalton9 for your feedback. To confirm this is not about showing Wikidata edits in Wikipedia? Feel free to remove that possible solution from the description if I've misrepresented it and it's not relevant!

My note was that one possible solution would be for Wikidata edits to show up in Wikipedia watchlists for watched pages, because I thought that feature didn't exist, but it turns out it does.

ovasileva changed the task status from Open to Stalled.Jun 6 2017, 11:48 AM

Is this still stalled Olga now they can be overridden? Does this mean we can add them back on English?

Is this still stalled Olga now they can be overridden? Does this mean we can add them back on English?

I think stalled is still appropriate. Even with the magic word, I think the conversation so far on keeping the descriptions has only revolved around the apps. We'd probably have to do another round of community consultation before looking at this again.

@ovasileva: If I understand the last comment correctly, this is "only" blocked on having consultations? If there is no (sub)task for such a consultation itself and no other technical blockers blocking this very task, then this task should likely be open with lowest priority, as stalled status means waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on, or declined. Thanks.

ovasileva changed the task status from Stalled to Open.Nov 20 2020, 10:35 AM
ovasileva triaged this task as Low priority.

@ovasileva: If I understand the last comment correctly, this is "only" blocked on having consultations? If there is no (sub)task for such a consultation itself and no other technical blockers blocking this very task, then this task should likely be open with lowest priority, as stalled status means waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on, or declined. Thanks.

Good point - done!