Jump to content

Community Wishlist Survey 2021/Editing/Allow editors to control PageImage

Add links
From Meta, a Wikimedia project coordination wiki

Allow editors to control PageImage

  • Problem: The PageImage for a given page is automatically selected by the software. Normally this works well, but there can be instances where it does not pick the most appropriate image e.g. w:Jim Crow laws where it takes the image from apartheid South Africa which is used in the navbox. Another example: Articles on upcoming elections often contain an image of each candidate. PageImage can grab one candidate photo and use it as the image for the election itself (thanks Alsee for pointing this issue out on Phabricator). PageImages are used in many places such as Page Previews, mobile search results, and fairly soon will start being used in desktop search bar results (as part of Desktop Improvements. There's also other potential uses such as in social media previews.
  • Who would benefit: Editors through having more control, readers through seeing more appropriate images
  • Proposed solution: It should be possible for editors to override the automatic PageImage choice, by use of a "magic word" or some other method.
  • More comments:
  • Phabricator tickets: phab:T91683, phab:T265713
  • Proposer: the wub "?!" 17:54, 30 November 2020 (UTC)[reply]

Discussion

PageImages should not take the image from a navbox in any case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:50, 8 December 2020 (UTC)[reply]

Indeed! That's just ridiculous, and certainly explains many instances of senseless and confusing PageImages.  — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  05:52, 15 December 2020 (UTC)[reply]
I think English Wikipedia is already set to only pull PageImages from the lead (lede) section? (Remember reading somewhere there is a per-wiki setting for that, correct me if I'm wrong.) In some cases this is undesirable, for example if there is no infobox, or the infobox image is the wrong aspect ratio, but there is a better image lower down in the article. Pelagic (talk) 21:59, 17 December 2020 (UTC)[reply]
Perhaps need two settings: (a) use specified image, (b) exclude this image from consideration. Then we could build (b) into templates like "part of a series on..." (If PageImages is pulling the info from Parsoid rather than raw wikitext (?), it might be unable to distinguish surrounding context though.) Pelagic (talk) 22:10, 17 December 2020 (UTC)[reply]

I'd also like to have the options to set a separate banner image, to specify a crop area within an image, and to pad a specified colour around a wide image like a logo. The banners on iOS Wikipedia app are automatically cropped down from the page image and often look sub-optimal. Perhaps the PageImage API should support an aspect parameter with values like square, wide so that other consumers can tap into the choice also. Pelagic (talk) 21:59, 17 December 2020 (UTC)[reply]

Comment Comment I've opposed the solution as-proposed as I believe it would be harmful to the quality of our content and community long-term. The immediate proposal might help you and I to fix a few pet-peeves in the short-term but ultimately, I think it helps no-one. We don't need yet another thing for every editor to discover, learn about and use "correctly". We need to think more outside the box and long-term. This isn't meant as criticism on the author, I love that attention is drawn to this problem. But figuring out appropiate and scalabe solutions that don't result in a net-loss for our mission isn't always easy. It also doesn't need to be decided during the wishlist process as far as I'm concerned, it'd be more than fine to defer that to the implementation phase. Sometimes issues have easy, obvious, and harmless solutions. But, in this case I think we need to approach the problem differently. Others have already pointed out that it would be challenging to surface this in an intuitive manner, and to avoid it going out of sync as the article evolves.

  • If we copied the name of the second image to the proposed PageImage override, what would happen if that image is deleted or otherwise delinked? It'll go straight back to the "wrong" image.
  • This would introduce yet another novel new way to attach media files to an article, which CommonsDelinker, AutoWikiBrowser, pywikibot etc would all need to understand and support.
  • If a regular infobox is added or otherwise a good image is added in the introduction section, it would not be picked up by PageImages due to the override.
  • If the natural instance of the photo in the article is replaced with an improved or similar photo of the same subject, the override would become outdated, which would likely not be obvious to most, and perhaps conside the editor into thinking the software is broken or outdated/cached for some reason.

In the given example of w:Jim Crow laws I think the problem isn't so much that "we" like a non-first image more than the first image, but rather the first image isn't meant for consideration at all. Providing tools for editors to mark and exclude such images would, I think, help us long-term and ultimately allows contributors to spend more time on other things instead. In the very unlikely scenario where there are multiple good images to consider but we still like the later ones more, we could apply the same marker to the first real image. The behaviour would be contextual, obvious, easily discoverable, and naturally evolve with the content when things are added or re-arranged. --Krinkle (talk) 03:47, 21 December 2020 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Editing/Allow_editors_to_control_PageImage&oldid=20877106"