Page MenuHomePhabricator

[8 hours] Create list of next steps and blockers on on select PageImage
Closed, ResolvedPublicSpike

Description

Relevant Task: T91683: Allow editors control of the page image
Gerrit-Patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageImages/+/835079/

Considerations

  • Enforce that the image is inside the page to have better visibility and patrolling
  • If the above requirement is implemented, what should we do when the image is removed from the page but the parser tag is not updated?

Gerrit Comment
Consider the following:
{{#pageimage:Offensive image with seemingly harmless name.jpg}}

Since the page image is only visible at ?action=info this kind of vandalism could go undetected for some time, during which it would be shown to a variety of people inside apps and search.

We saw this problem before with Wikidata descriptions when we showed them on mobile web only.

The other challenge here, is what to do if the image in the page is removed, but the parser tag is not updated.

Event Timeline

@Samwilson we created this for you during Wishathon wrap up, because we might want to move it into the sprint

NRodriguez renamed this task from Wrap up work on PageImage to Create list of next steps and blockers on on select PageImage.Oct 6 2022, 5:07 PM
NRodriguez moved this task from In Progress to Needs discussion on the Wikimedia Wishathon board.

It sounds like the best way forward here is to not add a parser function but instead go with a class-based approach in that any image with class goodpageimage is given a higher score. This would work in much the same way as the existing notpageimage class does (which gives an image -1000 on its score).

It'd look like this:

[[File:Lorem.jpg|class=goodpageimage]]

These classes don't really need to be localizable, because templates can do that. For example, an infobox could set the goodpageimage class on its image. Pages using direct image syntax already have to use English parameter names.

As @Ciencia_Al_Poder points out in T91683#8279841 it'd still be possible to introduce vandalism via something such as <span style="display:none">[[File:Good-name bad-image.jpg|class=goodpageimage]]</span> but this is an existing risk anyway and not made much worse.

I think the main blocker currently is that the Web-Team-Backlog team needs to be involved in the development here, and they don't have time right now.

T319559#8299241 sounds good, but if we want to go with the parser function, it could ensure that the image provided is used somewhere on the same page. If the image gets removed, then the parser function could silently fallback to the normal logic for image selection. That would seemingly eliminate misuse, vandalism or otherwise.

Jdlrobson subscribed.

Tagging with our team so that we make sure to arrange time to talk about this.

JMcLeod_WMF renamed this task from Create list of next steps and blockers on on select PageImage to [8 hours] Create list of next steps and blockers on on select PageImage.Nov 9 2022, 12:06 PM
JMcLeod_WMF added a project: Spike.
Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptNov 9 2022, 12:06 PM

@ovasileva and @Jdlrobson Pinging you both as we have the Wishathon week and will have capacity to hopefully make some progress on this.

Thanks so much!

(The Wishathon is next week, and it's a week dedicated to making progress on smaller wishes)

I can make time to talk about this next week and share my understanding of the problem. Who would be best to meet with?

Following our chat in the Wishathon, I think this can be closed, right @NRodriguez ?

@Jdlrobson Feel free to remove from the Readers-Web-Backlog board

Removing inactive task assignee account. (Community-Tech: Please do so as part of offboarding.)

KSiebert claimed this task.