Page MenuHomePhabricator

Allow viewing of statement blocks with unsupported data types
Closed, ResolvedPublic


We have this

The file page outputs all statements that have been associated with it, regardless of their data types.

We want this

All statements, even with unsupported data types, must be displayed, in a way that makes sense, so that we can spot vandalism.

Acceptance Criteria

Test case set up at

  • statement with unsupported data type is shown
  • statement with unsupported data type doesn't cause other elements on the page (other, valid statements) to break
  • statement with unsupported data type is displayed in a acceptable fashion (no obvious errors)


Related Gerrit Patches:
mediawiki/extensions/WikibaseMediaInfo : masterHandle statements with unsupported data types

Event Timeline

matthiasmullie updated the task description. (Show Details)

Change 502516 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Handle statements with unsupported data types

Change 502516 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Handle statements with unsupported data types

Ha78na claimed this task.Apr 16 2019, 4:49 PM
Ha78na added a subscriber: Edtadros.
Ha78na added a comment.EditedApr 16 2019, 9:57 PM

This seems to be working fine on beta, @matthiasmullie I couldn't figure out how to test on test-commons though - couldn't get the wbsetclaim correct in the Api Sandbox. What is an example claim JSON I should submit to get into this state on some file in test commons?

Below is an example call for adding a claim with 'globecoordinate' datatype:

(new mw.Api()).postWithEditToken({
	action: 'wbsetclaim',
	format: 'json',
        claim: JSON.stringify({"type":"statement","mainsnak":{"snaktype":"value","property":"P625","datavalue":{"type":"globecoordinate","value":{"latitude":36.025155,"longitude":-113.788809,"globe":"","precision":0.000001}}},"id":"M23$f49ddd73-4bb5-5e42-f132-6819d56773f4","rank":"normal"})

Let's break down that 'claim' thing a bit:

  • "property":"P625": P625 is the id of the wikidata property that expects a globecoordinate value (I'm not aware of any convenient way to find properties by supported datatype, so I just try my luck searching for a property name that I'd expect to have such datatype, like 'coordinate')
  • "id":"M64624$f49ddd72-4bb4-5e41-f131-6819d56773f3"
    • M23 is the MediaInfo id for this page ('M' + page id). Can easily be fetched by executing this in console while on the page: 'M' + mw.config.get( 'wgArticleId');
    • $: delimiter, must be there to separate entity id from unique key
    • f49ddd72-4bb4-5e41-f131-6819d56773f3: just a unique key - this can be anything, as long as it's unique
  • "datavalue":{"type":"globecoordinate","value":{"latitude":36.025155,"longitude":-113.788809,"globe":"","precision":0.000001}}: the value - this one's a little annoying to craft by hand, since this varies wildly per datatype. I usually just go to one of the wikidata items on my local wiki (or a test/labs wikidata instance) and add a value for a certain datatype, inspect the request, and copy & adjust the value it submitted - it's faster than combing through the wikidata code and figuring out what that datatype looks like :)


  • browse to the file you want to add such statement to
  • copy the above snippet into your console
  • make sure to substitute M23 for the MediaInfo id of the page you're on ('M' + mw.config.get( 'wgArticleId');)
  • make sure to change the hash to something unique
  • execute that snipper, it'll submit an API call
  • once the API call has completed, refresh the page
  • unsupported statement is there, you should see it on the page and have a decent enough interface (that allows you to delete it)
Cparle updated the task description. (Show Details)Apr 17 2019, 4:24 PM

tested on beta

Tested on test-commons- works there as well. @matthiasmullie your instructions were what I needed i was formatting the datavalue wrong

Ramsey-WMF closed this task as Resolved.Apr 24 2019, 1:36 AM

Works on production but let's make sure T220213 gets implemented too