@JoeWalsh Would this be useful for iOS as well? Would you need anything else?

@bearND we don't absolutely need it (we're making a separate fetch for the full info), but we could save the second fetch if these properties were included: License|LicenseUrl|LicenseShortName|ImageDescription|Artist

@JoeWalsh Are you using the /page/media endpoint in iOS already?

@bearND no - we're making a MW API request for image info for picture of the day (and article images) when the user enters the image gallery

@JoeWalsh ok, then I must have misread T193274: PCS Media end point for iOS . For picture of the day I would understand that it's not yet used but not for article images.

@bearND we implemented it but ended up not shipping it due to T195325 . Even though that's now fixed, we haven't had time to circle back and ship it. We might wait until switching to the new html endpoint to make the change all at once.

@JoeWalsh I see. That makes sense.

Hey @bearND - any update on this?

@Charlotte No updates yet. Is this something that's blocking you? In any case I've moved this to Upcoming so it hopefully gets picked up earlier.

@Charlotte / @JoeWalsh Feel free to add a priority based on the relative urgency of this work to the app teams.

@Charlotte and/or @cooltey the media endpoint returns the description as HTML, would it be desired for the new fields? From the mwapi we have HTML content for Credit and Artist:

Credit.value: "<span class="int-own-work" lang="en">Own work</span>"

Artist.value: "<bdi><a href="https://www.wikidata.org/wiki/Q42412772" class="extiw" title="d:Q42412772">Jeevan Jose</a> </bdi>"

Also, the API returns two fields with the license name (do you need the link too?)

License.value: "cc-by-sa-4.0"

and

LicenseShortName.value: "CC BY-SA 4.0"

The latter seems ready for display but I would like to confirm which one you prefer.

@MSantos I'd suggest following the same conventions as are used on the /page/media endpoint. We could (should) probably even reuse the same code.

https://en.wikipedia.org/api/rest_v1/page/media/Jellyfish

Note: There is an emerging convention of providing an object containing both HTML and plain text representations of the properties where they are originally stored as HTML, but as you can see, that's only been done for some properties in the /page/media endpoint. I don't remember exactly why it wasn't done for others, but it shouldn't be too hard to extend if the app teams want that. (OTOH, at some point not too far away, Structured Data on Commons will take care of this problem, so it may not be worth doing too much work to update in the meantime.)

The only aspect of the /page/media output I'm not sure I'd emulate here is the attempt to extract structured artist info, including the name and user page, in some cases (see getStructuredArtistInfo() in lib/media.js). @cooltey @JoeWalsh Do the apps actually use the sometimes-available artist.name and artist.user_page fields in /page/media responses? If not, maybe it would be better to go with the more standard html/text/lang pattern for the artist field for both endpoints.

Thanks @MSantos and @Mholloway.

Yes, follow the same conventions as are used on the media endpoint will be great.

The app now actually uses the article.name as the credit string, which you can find from here:
https://github.com/wikimedia/apps-android-wikipedia/blob/master/app/src/main/java/org/wikipedia/gallery/GalleryActivity.java#L573-L575

if the artist.name is null, then the app will get and trim the artist.html content to get the artist's name.

Change 472334 had a related patch set uploaded (by MSantos; owner: MSantos):
[mediawiki/services/mobileapps@master] Adding attributes to Picture of the day

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

Thanks, @cooltey, and @Mholloway!

Change 472334 merged by jenkins-bot:
[mediawiki/services/mobileapps@master] Adding attributes to Picture of the day

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

@cooltey Can you check if this meets your expectations? If so, feel free to resolve 👍