Page MenuHomePhabricator

Allow MediaInfo pages to be accessed via associated file name
Closed, ResolvedPublic

Related Objects


Event Timeline

MarkTraceur moved this task from To Do to Doing on the Multimedia-Team-Working-Board board.

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.
Ramsey-WMF moved this task from Untriaged to Next up on the Multimedia board.Oct 4 2017, 1:50 AM

@Lydia_Pintscher - this ticket has been blocked on technical issues raised by some of your team members (namely @daniel and @thiemowmde) and we wanted to make sure the appropriate people were tracking it or working on it. Do you have any updates about the status of the work?

@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...

daniel assigned this task to thiemowmde.Dec 2 2017, 7:57 PM

Thiemo, I'm assigning this to you to make sure it's at least in our process somewhere. Mark and his team are blocked on this, so we should really look into it.

Lydia_Pintscher moved this task from incoming to monitoring on the Wikidata board.Dec 18 2017, 3:07 PM
Lydia_Pintscher moved this task from incoming to monitoring on the Wikidata board.
Abit moved this task from Blocked to Doing on the Multimedia-Team-Working-Board board.
MarkTraceur closed this task as Resolved.Jan 8 2018, 5:32 PM

Should be finished for now - maybe some work to do later, but the current state is enough to move forward.