FANDOM


  • I've gone through https://community.fandom.com/wiki/User_blog:Kirkburn/How_images_are_picked_to_represent_articles thoroughly, and found nothing helpful to get a specific image I'm using on a page to become the thumbnail, following this, I tried to find people with my same problem to see what their solutions were. Most, if not all, discussions I've seen on the topic of the wrong images being autoselected as a page's thumbnail, have had no solution, since shortly after the person is linked the article to how images are picked end in no response from the OP. I can't assume whether or not it solved their problems and what they did to solve them, so that did also not help.


    I don't understand why the only way to choose a page's thumbnail is through randomized image selection. This is a faulty, unorganized, useless system, that usually has no way of specific targeting, unless you removed every single image from a page, including templates, galleries, slideshows and anything with a PNG file, and left only the one you wanted to be put as the thumbnail matching the satisfaction criteria. In fact, in some cases, even with the criteria being matched with only one image in the page, the autoselection process will sometimes still only take a text quote from the page.

    The thumbnail autoselector can be useful for those new to editing wikia pages, who don't know how to go further into the details of editing and formats. But for an organized wikia with many experienced editors, autoselection is a buggy burden that is both hard to satisfy and sometimes, even when the criteria are matched, will divert from it's wide range and pick something that it shouldn't have according to the selection rules.

    This is why we're in need of a setting that allows us to either check an image to be ignored from selection (such as those in templates), or specifically tag a picture in an article's gallery, slideshow, or sliders to be selected as the thumbnail by default.

      Loading editor
    • From that blog:

      The image chosen is generally the first image on the page that satisfies these criteria:

      • Larger than 130px by 115px for use on category pages, larger than 200px by 100px for the related pages module. Note: the size on the 'File:' page is what counts, not how it displays on the page.
      • Used 10 times or fewer in content namespaces on the wiki
      • One of the first 50 used on the page
      • Not an SVG

      That doesn't sound like "randomized image selection" to me. I've seen it go right 999/1000 times. The only bug with it that comes to mind is Shared images.

      You've got to work with the selection process and decorate your page accordingly. Game the system if you have to. Adding an image picker just creates more work as an editor. What are you doing that's out of the ordinary? Can you link to a category where you see a lot of mistakes?

      It's unlikely that they'll be working on another custom feature, especially since pretty much all resources are sunk into UCP at the moment.

        Loading editor
    • I'd really like if we could select a page's thumbnail without having to reorganize my pages. And if it could be by infobox field but not displayed in the infobox even better. Currently, when people see an article (makeup) I want the first picture they see is the product. But in categories I want the colour swatch if available.

      But I agree with Tupka, it isn't exactly random atm, I know what the image will be with no surprises. I just don't want to have colour swatch first displayed on my page, so I leave it as product preview.

        Loading editor
    • It might be possible to add an image at the top of the page and use CSS to hide it, but it may still get used for the page thumbnail.

        Loading editor
    • I was thinking possibly even <includeonly><onlyinclude></onlyinclude></includeonly> tags formatted in the infobox. But I haven't tried yet. Funny enough this is something I have been thinking about a while but haven't actually got round to testing (mostly not looking forward to the mass editing of 6k+ pages XP because I did that for another reason recently).

        Loading editor
    • Hollowness wrote: I was thinking possibly even <includeonly><onlyinclude></onlyinclude></includeonly> tags formatted in the infobox.

      Ha, yeah no, trying to use those seem to break infoboxes XD

        Loading editor
    • Fandyllic wrote: It might be possible to add an image at the top of the page and use CSS to hide it, but it may still get used for the page thumbnail.

      I have seen wikis do something similar to this. However, rather than completely hide it with CSS, they just make it really small; like 1x1px.

        Loading editor
    • Andrewds1021 wrote:

      Fandyllic wrote: It might be possible to add an image at the top of the page and use CSS to hide it, but it may still get used for the page thumbnail.

      I have seen wikis do something similar to this. However, rather than completely hide it with CSS, they just make it really small; like 1x1px.

      Where do they traditionally hide this 1x1px?

        Loading editor
    • As the very first thing in the article; that way it should always get chosen.

        Loading editor
    • Does it not look like a misplaced period then?

        Loading editor
    • Andrewds1021 - Stolen Password Warning - Google Chrome - 2020-03-03-23-52Well, did you notice anything in this post?

        Loading editor
    • Andrewds1021 wrote: Andrewds1021 - Stolen Password Warning - Google Chrome - 2020-03-03-23-52Well, did you notice anything in this post?

      Yeah, I thought it was dirt or pixel off on my screen at first. But if the wiki is not white I can see it being less noticeable but my wiki is on white. However, my infobox isn't I could try to hide it there.

        Loading editor
    • Hmm, even there it kind of shows because swatches tend to have white backgrounds but can have a bold or dark colour. But I can't hardly notice on the lighter colours. But this is probably me just being anal retentive.

        Loading editor
    • Hollowness wrote:

      Hollowness wrote: I was thinking possibly even <includeonly><onlyinclude></onlyinclude></includeonly> tags formatted in the infobox.

      Ha, yeah no, trying to use those seem to break infoboxes XD

      Well these may not work in the infobox but they do seem to work in the article.

        Loading editor
    • Great! So that means there are at least 3 different options.

        Loading editor
    • I don't thin the include tags thing will work... and even if it does it could have many undesirable unexpected consequences.

        Loading editor
    • Fandyllic wrote: I don't thin the include tags thing will work... and even if it does it could have many undesirable unexpected consequences.

      It did work for the test I did (but I did only tested one page) but I am reluctant to use because of that reason : / I am holding off on this for the time being, I think.

        Loading editor
    • SOTupka217 wrote:
      From that blog:

      The image chosen is generally the first image on the page that satisfies these criteria:

      • Larger than 130px by 115px for use on category pages, larger than 200px by 100px for the related pages module. Note: the size on the 'File:' page is what counts, not how it displays on the page.
      • Used 10 times or fewer in content namespaces on the wiki
      • One of the first 50 used on the page
      • Not an SVG
      That doesn't sound like "randomized image selection" to me. I've seen it go right 999/1000 times. The only bug with it that comes to mind is Shared images.

      You've got to work with the selection process and decorate your page accordingly. Game the system if you have to. Adding an image picker just creates more work as an editor. What are you doing that's out of the ordinary? Can you link to a category where you see a lot of mistakes?

      It's unlikely that they'll be working on another custom feature, especially since pretty much all resources are sunk into UCP at the moment.

      How exactly, is just having a thumbnail picker, MORE WORK as an editor? So, you're saying that if I have to change all of my images so that they're the correct size for each thumbnail I want them to be in, that'd be less work than simply picking an image?

      It makes no sense to me why people are so defensive on this matter, why not just add the thumbnail pickers? What's wrong with it, it's a quicker method, multiple people want it, and it's better than having to deal with all those criteria and occassional bugs. It's understandable that it isn't possible as of the moment due to their resources and time, but at least we should all agree on it being a good idea. That way, when it's possible to update the editor, the feature can be included.

        Loading editor
    • The requirements are not, at all, unreasonable.

      • Infoboxes are usually 225-300 pix wide, so 200 is a normal absolute minimum standard.
      • Few images are used more than 10 times, this is just to rule out images used in notices.
      • The most important image is probably in the first 50. If not, you've done something wrong.
      • SVGs have specific uses and really shouldn't be used for regular images.

      If you have to change the way you work to fit those requirements, what were you doing before? There are undoubtedly wikis that only have small images at their disposal, like sprites, and those are screwed. But that's a very small minority.

      I'm not " defensive". I'm realistic. There are so many images, so many categories, that automation is really the only way to do things.

        Loading editor
    • Two things:

      1. No one is against a thumbnail picker, but it would be a new feature and the UCP needs far more work just to get to par, so such a new feature is both unlikely to be a priority and maybe shouldn't be a priority until the UCP is past Phase 2.
      2. On the requirements listed by Tupka217, I agree with the first 3, but SVGs are under-utilized because:
        • MediaWiki has a kind of stupid rendering implementation.
        • Adobe created the standard, but abandoned it.
        • The XML markup for SVG is inefficient and cumbersome.
        • SVGs would be great if the ecosystem hadn't damaged their reputation so much.
        Loading editor
    • I am not trying to be difficult but Wikipedia disagrees with your recount of SVG history.

        Loading editor
    • Wikipedia has incomplete info... however, please point out stuff that directly contradicts what I said.

        Loading editor
    • If the Wikipedia information is incomplete, then that might be part of it. From what the page does have, it sounds like SVG was developed by W3C after receiving competing proposals; one of which was from Adobe.

        Loading editor
    • Well, as an example, Firewire was technically a group proposed standard, but if you dig deeper, it was basically like 90% Apple. SVG was like 75% Adobe and when they decided not to support it as a standard format to import and export in its products, that basically crippled the format. If you look up Vector graphics in Wikipedia, you'll see the common vector graphics formats it names are SVG, EPS, PDF or AI... guess who developed EPS, PDF, and AI (Adobe Illustrator) formats?

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message
Community content is available under CC-BY-SA unless otherwise noted.