Topic on Talk:Page Previews/Flow

Page images are article metadata, avoid embedding it into article

8
197.218.81.208 (talkcontribs)

I see that the plan seems to be creating a parser function for choosing page images on a page, phab:T91683.

As a passive observer that has used other wikis before, I'd say that this is a pretty massive mistake of simply repeating history by putting metadata into the article. Categories are a great example of a tool which has massive problems because of this:

  • Localization is impossible - A category is really just a tag, but because it is embedded in an article it can't be translated without massively duplicating the data
  • No stable id- This causes several issues, it can't be removed or renamed without needlessly editing every single article containing it
  • No centralized GUI or curation tools to manage it
  • Performance issues - Phab:T116001

The same thing will be repeated if this is added as a parser function for setting page images:

  • Parser function on each article - on 100000 articles, every single article will need to be edited to remove or change it
  • GUI or better tools - this would make it once again hard to choose or change images using mobile devices
  • Duplicate work - A bat would use the same image, but this would need to be set on every article on every wikipedia, instead of using and encouraging something like wikidata
  • Complicated parser function + wikitext - people will likely add parser functions within it, and use hacks like "{{#tag" on it

About the only benefit is setting these images using templates. That in itself is a problem because templates are complicated beasts. This could be done way better by using simplified GUI based decision trees.

Unlike categories, images can be understood by everyone and many people can help out to choose appropriate image for articles. Anyway, this parser function path seems to be already set, but perhaps one day it will be revisited.

Pere prlpz (talkcontribs)

Hovercards show a summary of the article. Therefore, the image shown in the hovercard should be "the image" of the article, and it should be updated when article updates. Usually the automatic choice of image is fine - at least, as fine as the automatic choice of text - but sometimes it isn't and a template or magic word could fix it.

I agree that the tool could be simpler if the image were stored somewhere else (Wikidata?), just as it could be simpler if text would stored somewhere else, but then the hovercard wouldn't be showing a summary of the article. It would be showing something else.

Could hovercards show a summary of Wikidata instead a summary of the article? Yes, they could. Would that be more useful? I think it wouldn't.

Jdlrobson (talkcontribs)

The idea is to replicate the PAGEBANNER magic word that the Wikivoyage community has been using. It's probably worth reaching out there to see what issues they've had if any with using this. With regards to Wikidata that's captured here: https://phabricator.wikimedia.org/T95026 but I suspect the user of this is going to be an edge case, not the norm. Usually the choice made by the automatic algorithm is good enough.

Pere prlpz (talkcontribs)

The most common case where the automatic algorithm fails is when it takes an image from a template (e.g. a background map from an infobox or an image from a navigation template) unrelated to the article subject. For those cases a negative magic word (that is, telling the algorithm not to take a given image) could work as well as a positive magic word (telling the algorithm to take a given image).

In fact, positive and negative magic words could be included in templates.

197.218.81.177 (talkcontribs)

> I suspect the user of this is going to be an edge case, not the norm To quote yourself: "Why edit in the page when you can edit outside it? ... how many things could be made into metadata?)"@Jdlrobson, Phab:T87686.

I'd also refer you to this:

http://top-10-list.org/2009/09/02/great-inventions-that-went-bad-for-mankind/

Embedding this in the article wikitext will severely limit the possibilities of this useful tool, as you rightly noted about categories. First of all it will be based on a name and not an ID, prolonging the problem with English parser functions, and image names.

To put it into perspective, imagine just how much more warring and how big of a mess it would be if the title of the page was embedded within the wikitext. This will also need proper wikitext, VisualEditor, parsoid support and probably many other tools, when it could simply be a value in the database set with an API. Then people will likely also create rules and strange ideas about where it should be placed within an article or template, much like how they argue about the location of categories.

Instead doing this "properly" would also encourage micro-edits, and participation that doesn't require learning yet another parser function, and looking through a huge list of parser functions.

It doesn't necessarily have to be in wikidata, it could use a mechanism similar to how the page title works stored in an on-wiki database.

197.218.81.177 (talkcontribs)

A simple way they can easily abuse the parser function is by simply running a bot that will put it into ALL articles thereby negating any perceived benefits of the "pageimages" algorithm. This would essentially disable the pageimage algorithm and put the choice of image completely under their control, and waste processing power because the algorithm will probably still choose an image before or after they change it. Or even put it into a template, and trigger the same problems as currently exist when a highly transcluded template is changed.

This could be used as a counter measure to force their choice if their demands that the algorithm be completely disabled are ignored by the WMF.

See? it isn't hard to abuse any useful tool.

Pere prlpz (talkcontribs)

If you are concerned that an affirmative parser function can be abused, we can use a negative parser function, to tell the software which image not to use in hovercards.

197.218.90.116 (talkcontribs)

> If you are concerned that an affirmative parser function can be abused, we can use a negative parser function, to tell the software which image not to use in hovercards.

Seems that would create even more work a bit like whack a mole where they might need to add multiple "disable page images". It could still be abused in the same way though, simply run a bot to detect all images used in an article, and disable all of them.

Anyway, I've made my point, the developers will probably find their own way, or simply follow the path of pagebanners, which to be honest has the exact same anti-pattern (problem).

Reply to "Page images are article metadata, avoid embedding it into article"