Topic on Talk:Reading/Readers contributions via Android/Outcome

Ideas:

• Add images via wikidata or simple commons search
• Work on choosing the most qualitative images

This is probably the most feasible and easiest option and to implement for the simple case. It will likely have the most impact at the lowest cost.

Some concerns though:

• Infoboxes - It is nigh impossible to determine how to add an image to an infobox consistently using template parameters
• Cultural differences - some images are perfectly fine in one culture but may be offensive or inappropriate in another. This may lead to "editphoto wars".
• Rating - frankly commons has too many images, so using rating or pageviews to surface possible candidates makes sense.
• Duplicate work - the page image could primarily be stored in wikidata to reduce duplicate work in other wikis
• Wiki preferences - It might require adding more properties on wikidata to ensure that each wiki can choose its preferred image there. This may reduce arguments over which image is best for which wiki.

For infoboxes or templates that add images, the ideal option might be to add a new property to templatedata, maybe something like parameter type:

params": {</nowiki>

        "user": {

            "label": "This is the main image. It is shown in search results, and represents the page",

            "type": "main-page-image",

If no infobox exists in the article, it can just fallback to adding the default markup, e.g.: "<nowiki>[[file:page-image.png|thumb]]</nowiki>". Yet another alternative might be to use the image from wikidata whenever this parameter doesn't have any value. This might be highly controversial, and this wikidata functionality could be opt-in for wikis that want it.

The simplest MVP implementation is probably to avoid infoboxes altogether, and just add the "standard" file:image markup to the article only when there is no "infobox class".

Fixed templatedata markup:

params": {
        "pageimage": {
            "label": "This is the main image. It is shown in search results, and represents the page",
            "type": "main-page-image",
}

Thank you for your feedback!

I see two different things in it: add images to illustrate a wiki and take the quality of an image into consideration.

Choose an image to be the universal representation of a person or a topic can be controversial, as you mentioned it. There is already a way to take an image and put it on Wikidata as the default image. This image will be taken into consideration in search or on wikis that use Wikidata data on templates, mainly infoboxes. It is still possible to override the default image by using another one locally.

Some wikis doesn't have infoboxes that use Wikidata, but there is an idea to have a central repository for templates. Also, have a way to indicate default value of a Wikidata element into TemplateData is also a (slow) work in progress.

If there is no infobox, well, that's indeed easier and it can be considered. :)

Concerning quality image, I think it would be a very good idea. However, I would advise to wait for the first steps of Structured data on Commons to avoid adding a new system that would have to be re-integrated to wikibase later.

All of this is context. We will of course consider your ideas, but based on it.

> Some wikis doesn't have infoboxes that use Wikidata, but there is an idea to have a central repository for templates.

Yes, the problem is when the infobox doesn't use wikidata for its image. In those it is probably better to avoid adding an image. The central repository might not use wikidata either, and even if it does, convincing wikis to use it is a huge task.

Maybe the long term solution for this would come from Multi-Content Revisions. It could have a special slot for article image for articles that don't use any infoboxes along with either templatedata property or the regular wikidata parser function for all other cases.

Avoiding is probably the best in that case, unless if there is some help to deploy more Wikidata on infoboxes (which is indeed difficult, to convince people).

Concerning Multi-Content Revisions, that's a possible future: have all meta-informations out of the articles (infoboxes, portals, categories...). The question is now, should we create some features that may be obsolete in a few years because of a feature?

> The question is now, should we create some features that may be obsolete in a few years because of a feature?

100% yes.

If it were a complex feature then it would depend on the cost of developing it. This feature is technically easy to develop. In fact it can even be done without any special app, just by using javascript and the api. This would be trivial to change to work with whatever new api for MCR comes around eventually.

Waiting for MCR doesn't seem like a good idea, structured data is a very long term project.