|· · ·|
|Resolved||Ramsey-WMF||T176012 Complete outstanding work on MediaInfo Wikibase extension|
|Resolved||thiemowmde||T177005 Allow MediaInfo pages to be accessed via associated file name|
|Resolved||MarkTraceur||T177022 Add an API module for querying MediaInfo entities by file page title|
|Resolved||matthiasmullie||T177023 Add a page_props entry to new file pages linking to the associated MediaInfo entity|
|· · ·|
OK, just going to write down some notes about what I've found out so far...
First, we decided that the key accomplishments here would be the following:
- An entry in the file page's page_props that corresponds to the mediainfo page (accessible via action=query&prop=pageprops, similar to wikibase_item)
- An API module that allows for getting a mediainfo entity via the file page title (e.g. action=wbgetmediainfo&titles=File:LighthouseinDublin.jpg|File:Foobar.jpg, with all other params of wbgetentities, essentially just an alias other than the ID lookup)
I have discovered several interesting things that I will document here, mostly for my own edification:
- The MediaInfo id string (M13, for example) is just the ID of the file page in the MediaWiki database (and, therefore, the normal MW API results), so it would be relatively easy to use that as a temporary implementation if anyone wanted to start writing bots. This is not useful for internal code, because there are abstraction functions we should use to avoid problems later.
- I thought I might be able to use action=wbgetentities&sites=local&titles=File:LighthouseinDublin.jpg, but it turns out the sites= param is looking at the interwiki map, so there won't be any way to get at MediaInfo entities on the same site. Oh, well.
- I haven't yet determined at which point I should create a page_props entry for each file...creating them on file upload would be easiest, but would mean running a real mean maintenance script upon first deployment. That could be okay. I suppose that's what we'll do.
- Furthermore, I am skeptical of skipping the database entry and relying on on-demand data for each API call. There wouldn't be a huge performance hit, but it seems wrong to represent something as being true via the API that isn't true in the database.
- Some of the above should probably be further split into different tasks. I will do that now and claim the API task.
@MarkTraceur Hey! I just got back from 10 days of vacation. Last I talked to Thiemo, he said he'd work on my patch. It's quite possible that it's now waiting for review from me, I'll check on Monday.
We have recently changed out sprint process, so this may have been lost somewhere - I hope that did not happen...