Addshore added a comment.

Thanks @TheDJ for summarizing many of the points in the RFC above. I'm going into this blank, and just want to add my thoughts once, and try to avoid any repeat discussion that may have already come up in the RFC. I feel that many issues have been identified, but this ticket isn't really addressing the underlying issue, rather making a quick fix that in the long term will just end up biting back.
Also I recognize that the issue of these descriptions being exposed via mobile and not being visible on wikipedia desktop, or in the controll of the enwiki community in any way was raised a year ago (or something like that) and the feature was half switched off, but this didn't really solve the issues identified back then. By not resolving that RFC properly / doing move investigation into the initial request we have ended up with this ticket.

One of the issues seems to be that the mobile apps surface data to users that is not displayed on the wikipedias in desktop. This leads to vandalism being missed, users don't see the data when they just flip to an article on enwiki, and the watchlist process as said can be delayed leading to changes dropping off the watchlist or only being added to the watchlist after a 'large' period of time (generally 2.5-5 mins, but can be greater).
This could be solved by simply displaying the en description, as is done on mobile, also on the desktop experience, this could live next to or under the title (for example).

The issue raised regarding the watchlist and items only being added when they have already fallen off the end could be solved by entries being sorted differently, perhaps sorted by the time that they are added to the watchlist or dispatched to the wiki rather than the time that change actually happened. This might be worth opening a ticket about.

One of the next issues is the control of the data, particularly protection of data. We have the situation where an enwiki admin can protect a page due to vandalism, yet the description is then still editable through the mobile app. enwiki admins have no control of over when the wikidata description is editable. A simple solution would be to have the mobile apps check the protection state of the enwiki article before allowing an edit to the description (I guess this is already done for the article itself).
I have not been following the research that the wikidata team has been doing regarding client editing, but it could make sense for edits to wikidata data from for example enwiki to come through the enwiki API. Wikidata / wikibase repo api modules could all be surfaced on client wikis. This could allow for the protection issue to be addressed further, editing a description via wbsetdescription would first check the enwiki protection for the page linked to the item, before doing some sort of internal call to the wikidata api, where the wikidata checks would also take place. This could also potentially allow control of wikidata editing via abusefilter etc on the client side.

The case of wanting to override the descriptions provided by wikidata still stands.
Rather than the description being fetched from wikidata through the apps and the editing of descriptions happening there this should / could happen on the client wiki via an api.
The API would fetch the description from wikidata / the local override location. An a configurable editing api could also be created, with options such as, edit on wikidata, edit on a local override (somewhere) and different communities can allow different levels on wikidata interaction.

The location of the override on the wiki could be anything, it could be a subpage of the article with some fancy code? It could be a magic word on the page, in the world of MCR it could also be its own content.

Overrides on wikis can be reconciled where possible by the wikidata community, improving the wikidata data, in cases where the override description is deemed an improvement, wikidata can be updated, and the override could be (optionally) removed.

I can probably pull some other tasks out of this comment.


TASK DETAIL
https://phabricator.wikimedia.org/T184000

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: TheDJ, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to