It might be simpler to include all three size options in the output rather than requesting them explicitly from the client side...

This would require the updated version to be running on Commons, but that's something we can coordinate obviously. :)

I think I agree that it might be more straightforward just to export thumburl, thumburl15, thumburl20, etc, but this may not scale well if different densities are required in the future.

I'd lean towards making the relevant parameters (iiurlwidth, iiurlheight, iiurlparam) multi-value parameters and letting clients request what they actually want, rather than special-casing to always return certain predefined density options.

Client-defined multivalue will be needed by a lot of applications including bug 54033 and bug 67323.

The current syntax looks like this:

https://commons.wikimedia.org/w/api.php?action=query&titles=File:Example.jpg&prop=imageinfo&iiprop=url&iiurlwidth=100

There can be a height parameter as well along with (or possibly instead of) the width, and also a parameter containing everything else:

https://commons.wikimedia.org/w/api.php?action=query&titles=File:Example.jpg&prop=imageinfo&iiprop=url&iiurlwidth=100&iiurlheight=100&iiurlparam=qlow-100px

Turning iiurlwidth into a multivalued field is nontrivial because it might have corresponding heigh/param values. This would fit some-sort of tree-based input format (such as JSON or XML, or even PHP-s GET array notation) nicely, but doesn't sit so well with the MediaWiki API's flat input syntax.

Some possible solutions:

1. make iiurlwidth & co. multivalue, use empty values to match up the values:
   
   iiurlwidth=200|300||500&iiurlheight=200||400|500&iiurlparam=|||qlow-500px
   
   The returned value could use the same syntax to preserve backwards compatibility:
   
   <ii thumburl="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/194px-Example.jpg|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/300px-Example.jpg|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/388px-Example.jpg|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/qlow-485px-Example.jpg" thumbwidth="194|300|388|485" thumbheight="200|303|400|500" url="https://upload.wikimedia.org/wikipedia/commons/a/a9/Example.jpg" descriptionurl="https://commons.wikimedia.org/wiki/File:Example.jpg" />
   
   This is fully BC but extremely hacky.

2. Deprecate iiurlwidth/iiurlheight/iiurlparam, come up with a new, multivalued parameter which can combine them (maybe use a wikitext-like dimension notation: 100, 100x100, x100, x100-qlow-100px) and a corresponding new response element which is also properly multivalued:
   
   iiurlsize=200x200|300|x400|500x500-qlow-500px
   
   <ii url="https://upload.wikimedia.org/wikipedia/commons/a/a9/Example.jpg" descriptionurl="https://commons.wikimedia.org/wiki/File:Example.jpg"> <iithumb url="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/194px-Example.jpg" width="194" height="200" /> <iithumb url="|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/300px-Example.jpg" width="300" height="303" /> <iithumb url="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/388px-Example.jpg" width="388" height="400" /> <iithumb url="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/qlow-485px-Example.jpg" width="485" height="500" /> </ii>

3. instead of using imageinfo, make a new prop=thumbnails module. Leave the old syntax for the (atypical but existing) use case of showing thumbnails of older revisions, use the new module for other thumbnail operations. The syntax could be the same as in 2).
   
   This would get around the problem with imageinfo that it is awkward to use it to get a list of contributors and other image data at the same time since it would return all data for all revisions, while e.g. thumbnail URLs or extmetadata are rarely needed for an old revision. OTOH a prop module which throws an error when called with no extra parameters (size) feels weird.

Thoughts? I am leaning towards 2) at the moment.

(In reply to Tisza Gergő from comment #4)

1. make iiurlwidth & co. multivalue, use empty values to match up the values:

[...]

This is fully BC but extremely hacky.

Extremely. -2.

Deprecate iiurlwidth/iiurlheight/iiurlparam, come up with a new, multivalued
parameter which can combine them (maybe use a wikitext-like dimension
notation: '100', '100x100', 'x100', 'x100-qlow-100px') and a corresponding
new response element which is also properly multivalued:

In general, yes. I see no reason for this to be not only wikitext-like but actually be exactly what's used in the image syntax, if at all possible. The only difficulty might be if any media handler needs multiple image-syntax parameters to fully characterize the thumbnail.

In specific, see below.

3. instead of using imageinfo, make a new prop=thumbnails module.

We already have too many image-related prop modules, IMO: imageinfo, videoinfo, and stashimageinfo all do basically the same thing, just for slightly different cases.

Thoughts? I am leaning towards 2) at the moment.

I like option 4: Deprecate prop=imageinfo entirely in favor of something that isn't so full of warts. Details at https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Rewrite_prop.3Dimageinfo_from_scratch_as_prop.3Dfileinfo

Although my proposal there includes option 2 when it comes to thumbnails.

Fleshing out that proposal and even help with coding it would be very welcome.

(In reply to Brad Jorsch from comment #5)

I see no reason for this to be not only wikitext-like but
actually be exactly what's used in the image syntax, if at all possible. The
only difficulty might be if any media handler needs multiple image-syntax
parameters to fully characterize the thumbnail.

All media handlers which take nontrivial parameters need that: the size will be one parameter, and all else (page number, quality, language etc)

We already have too many image-related prop modules, IMO: imageinfo,
videoinfo, and stashimageinfo all do basically the same thing, just for
slightly different cases.

I don't see why multiple image-related modules would be a problem. We have half a dozen link-related modules; it's actually a lot less problematic than stuffing all the functionality in a single module. If anything, imageinfo should split up further IMO.

(As a matter of fact, I would like to split out extmetadata into a separate module, with significant changes. I hope to put up an RfC about that in a couple days.)

The problem with imageinfo/videoinfo/stashimageinfo is that they are split the wrong way: instead of providing different functionality for the same file they provide the same functionality for different file types.

I like option 4: Deprecate prop=imageinfo entirely in favor of something
that isn't so full of warts. Details at
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Rewrite_prop.
3Dimageinfo_from_scratch_as_prop.3Dfileinfo

Although my proposal there includes option 2 when it comes to thumbnails.

Fleshing out that proposal and even help with coding it would be very
welcome.

The proposal sounds good but also sounds like a long-term thing. It would be nice to have a solution for the single-size-per-request limitation right now, MediaViewer development is inconvenienced by it.

If I understand correctly, code written for option 2 could be reused when implementing option 4, so going with that option now would not be wasted effort, right?

(As a side note, my dream API would have JSON instead of string inputs so that attributes can be set per-file instead of globally; in the case of thumbnail URLs, this would lift the current limitation that the same thumbnail size(es) have to be returned for all files (and all revisions of them). Something like [{ "title": "File:Foo.jpg", thumbs: [ { width: 220px }, { width: 640px } ] }, { "title": "File:Bar.jpg", thumbs: [ { revision: 123456, width: 100px } ] }] would make more sense to me. Consider an interface similar to the file page, with a large image of the current revision and small images of the old ones, or a collection interface like [1] - wanting different sizes for different images / different revisions is a fairly natural use case.)

[1] https://www.mediawiki.org/w/index.php?title=File:Media_viewer_designs_-_media_support.pdf&page=3

Per IRC discussion with Brad, I'll add a new mode to imageinfo (since I need a patch for this soonish) and try to make it compatible with the eventual format of the future fileinfo API:

• use an iiwikitextparam parameter which takes parameters in the same format as wikitext images; since those use | as a parameter separator, use || as a parameter group separator
• use the output format described in comment 5 2)

deleted - was an attempt to format an old comment

Current plan is to have guessable thumbnail URLs via T66214: Define an official thumb API, which would make this functionality mostly irrelevant. Not sure about the case of images from a foreign repo which does not support that API (either because it's an old MW version or because that API ends up being implemented outside of MediaWiki), though.

Change 542775 had a related patch set uploaded (by Lucas Werkmeister; owner: Lucas Werkmeister):
[mediawiki/core@master] WIP: imageinfo: add wikitextparam

https://gerrit.wikimedia.org/r/542775