Talk:Attribution API

Nice feature -- about time!

I remember having conversations about the need to have better attribution practices for Wikimedia Commons photos for a looooong time -- nice to see this finally deployed. Congrats to the team! Scann (WDU) (talk) 20:53, 20 April 2026 (UTC)

Thanks for sharing + feedback

Hi Team, from the bottom of my heart... thanks!. I dreamed about this few years ago -when I developed a tool to review WLM photos- but today, around 10 years later, it's a reality! The feedback -or question- is about attribution of embedded files into articles: in the example, Earth has a lot of images. Are there any plan about this? I imagine to include by using a query modifier (ie: ?include_media). Superzerocool (talk) 11:35, 21 April 2026 (UTC)

Thanks for the question/suggestion! We are actively considering what to do about this, and are anxious to see how folks will use it out in the wild to help inform what to do next with embedded media. You're right that articles increasingly feature many images, and intentionally so. One other aspect that we've been looking into is if people will request images from within the article, or if they will more consistently reference commons directly. My gut hunch is the former, but we're going to see what happens and adjust accordingly. Your idea is very interesting too, and I would love to hear more input on if that's how people would want and expect it to work, especially if they are most interested in the article content itself. Thanks for the suggestion! HCoplin-WMF (talk) 14:03, 21 April 2026 (UTC)

Just adding that I've created this ticket: https://phabricator.wikimedia.org/T424037 I personally think that it makes more sense to have the collection returned as a dedicated endpoint so that our REST responses remain well structured and reliable. In other words, while the `expand` pattern is common in REST, dynamically adding content is generally not. So it feels more 'right' to make it a dedicated endpoint than a query parameter. Would love your thoughts though! HCoplin-WMF (talk) 14:56, 21 April 2026 (UTC)

Thanks and feedback

Stumbled across this project today - looks potentially very helpful! A few thoughts/questions:

1. Could/should the API return attribution information for the lead page image of a given Wikipedia article? For example, I think that currently, to get attribution information for the image used on the “Iwo Jima” article, I would need to first query the Wikipedia Action API to get the pageimage (Ioto_Island_Aerial_photograph.2016.jpg), then query the Attributions API for that Commons image. It would be nice to do this in one step.
2. Could/should the API return attribution text? For example, this file has two templates in its Licensing section providing different attribution text. The Action API returns an attribution member, but the API returns neither.
3. Could/should the API return any additional text required by the image's licence? For example, the Free Art License asks users to include the text “Copyleft: This is a free work, you can copy, distribute, and modify it under the terms of the Free Art License” in any attribution. Could the Attributions API provide such required text?
4. Batch requests: The Action API allows imageinfo to be requested for up to 50/500 images per request, whereas the REST API appears to handle one image at a time. Is batch support possible?

Matthew at catfishing (talk) 13:10, 6 October 2026 (UTC)

5. The Attributions API credit member is different from the credit text that MediaViewer shows when you click Download. Which is right, and does the new credit member provide enough info that users can be reasonably confident they're complying with licenses? MediaViewer's algorithm is something like of "attribution, failing which artist and source, failing which artist, failing which source, failing which fallback text". The Attributions API looks like it just sets credit to "artist". It's common to find empty artist metadata, even for CC BY licensed images. Matthew at catfishing (talk) 21:01, 6 October 2026 (UTC)

Pinging @HCoplin-WMF, as a previous responder to Attribution API questions/feedback. Matthew at catfishing (talk) 06:14, 13 October 2026 (UTC)

Hey, thanks for the ping, and apologies for the delay in response! I can answer your questions below.

1. The team did some early investigation into providing attribution info for images embedded on article pages, but ended up deprioritizing it ended up being a lot more complicated than expected. However, specifically targeting the lead image to include on the article is an interesting idea that we can certainly review.
2. This is a good point, and something we may need to revisit. For now, the Attribution API is considered more of an MVP, with a "narrow" scope for what it supports. Ultimately correct attribution is still the responsibility of the reuser. We would like to expand over time to have "broader" coverage though, with the goal being that the Attribution API can fully cover everything you would need for full compliance. Getting there is honestly a little tricky, because of the prevalence of user defined templates over purely structured data. I think this specific suggestion is worth adding to our backlog to see if we can reliably target and include some more specific templates, though.
3. Potentially; basically the same answer as above.
4. Batch is intentionally not supported right now. Targeting arbitrary collections is really bad from a performance and cache-ability perspective. We might look into creating a dedicated batch endpoint in the future, if folks really need it, but for now it is intentionally limited to one file or article at a time.
5. @PMiazga (WMF) -- could you weigh in on this one to keep me honest and see if there might be anything you'd want to change in response to this? It's been a while since we talked about it, so I want to make sure I'm representing the decision behind the logic correctly. My general recollection is that because we have the source listed as a dedicated object in the response and we are not returning the pre-formatted attribution text, we are explicitly returning 'artist' in this field. Going back to your point #1, I think that approach would still be valid if we optionally include the full pre-formatted attribution string or something to that effect. We also chose the term 'credit' instead of 'artist' specifically because there are items in Commons where the term 'artist' is a bit too specific.

HCoplin-WMF (talk) 14:30, 13 October 2026 (UTC)