https://bugzilla.wikimedia.org/show_bug.cgi?id=54035

--- Comment #4 from Tisza GergÅ‘ <[email protected]> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to