Extension talk:CommonsMetadata/Flow

Previous page history was archived for backup purposes at Extension talk:CommonsMetadata/LQT Archive 1 on 2015-07-10.

having the results in a specific language was something that was planned in the motivation, but trying today to pass language as a parameter ( https://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&format=json&iiprop=extmetadata&iilimit=10&titles=File:Aubagne%20centre%20-%20bo%C3%AEte%20%C3%A0%20livres.jpg&language=fr ) I am told that it is not recognized. Has it been implemented using another parameter or is this only in English right now?

iiextmetadatalanguage (see the API docs). It only works when the image metadata has been provided in that language by an editor, though.

thanks Tgr for the quick reply, it seems to work fine with some examples I have tested, will try to test it soon to display creator's names on my website rather than redirecting to Commons ( https://www.boites-a-livres.fr/ville/plassay/17250/boite-8119 )

I doubt there is a typo in Translations:Extension:CommonsMetadata/10/en; Isn't commons-inspecific a typo of commons-specific? Where can I find meaning to that terminology? The sentence goes: *Ideally such a system would be as commons-inspecific as possible, with the commons and non-commons part separated.

The design goal was to avoid being Commons-specific (ie. have parsing logic that works on any wiki, not just Commons).

In practice that's not really the case, the extension mostly looks for Commons-specific markup, but that markup is kept simple and is documented so any other wiki can easily add it. See Commons:Machine-readable_data.

Hello there, would it possible to extract description data also from another two sources: 1, description of the image in the gallery section of a page, and 2, plain text in the text body of an image (content of the page File:Image.jpg) ?

1. is hard, and we don't want to put much effort into parsing data from wikitext, the plan is to support structured data via Wikibase (Wikidata) instead. As for 2., it would not be very useful without locating out the useful part of the description (there will be license templates, section headers and whatever else intermingled with it) which is again more effort than worth. (If you do need the contents of the file page though, you can get the via the revisions API.)