Change 192885 had a related patch set uploaded (by Dragan Espenschied):
https://phabricator.wikimedia.org/T90492

https://gerrit.wikimedia.org/r/192885

I have been proposing this for over a year... https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2014/01#CommonsMedia

Change 192885 had a related patch set uploaded (by Daniel Kinzler):
CommonsMedia: Make file repo URI configurable.

https://gerrit.wikimedia.org/r/192885

@adrianheine: Can you join in on that?
We need a sane way to pass the configuration which is to be picked up in wikibase.ui.entityViewInit.js on to jQuery.valueview.experts.CommonsMediaType and jQuery.ui.commonssuggester respectively. We could do that just like it is done for the content languages. However, since those options are rather of a static nature, I wonder why such are not just injected into the specific Expert prototypes in wikibase.experts.getStore instead of passing them down the whole view chain along with the ValueViewBuilder as that results in having the options passed to the Expert instance currently used by jQuery.valueview regardless of whether the Expert actually requires the option.

Here is some suggestion: How about scraping the underscore from jQuery.valueview.Expert._options have those act more like jQuery.Widget options and add an option like url to jQuery.valueview.experts.CommonsMediaType as well as to jQuery.ui.commonssuggester. Maybe that option should even default to null to get that hard-coded commons URL completely out of there. CommonsMediaType would just pass the url on to the commonssuggester. CommonsMediaType's url option default would simply be overwritten in wikibase.experts.getStore with the new Wikibase setting. Eventually, the prefix "commons" of those components should probably be replaced.

I'd suggest to introduce an ExpertFactory replacing the currently used ExpertStore. Then we could control instantiation arguments for the experts and the ValueViewBuilder would get simpler. ContentLanguages could be passed through the ExpertFactory, too. Currently the ValueView has to know a lot about the experts. Too much for my taste.

On a general note, I think it makes more sense to be much more flexible about this. I don't get why we don't support something like the following:

$wgWBSettings[ 'dataTypes' ][] = new FileDataTypeFactory( $someRootScope )->getForeignAPIRepoFileDataType( 'my-media', array(
   'name'                    => 'commonswiki', // Must be a distinct name
   'apibase'                 => 'https://commons.wikimedia.org/w/api.php',
   'hashLevels'              => 2
) ); // => array(
//        'DataType' => new DataType( 'my-media', 'string', array() ),
//        'Validator' => new SomeGreatForeignAPIRepoFileDataTypeValidator(),
//        'Expert' => 'de.adrianheine.myproject.MyMediaExpert' //optional, resource loader module name
//        'Formatter' => new SomeGreatForeignAPIRepoFileDataTypeFormatter( $allTheSettingsItNeeds ),
//        'Parser' => new StringParserOrWhateverItsCalled(),
//        … other cool stuff we need for actually implementing a new data type
//  );

This could have different levels of customizability which don't need to be available at once. The main issue, though, is that we don't even support the most basic level of configuration: Specifying the data types. If we would just do that, a lot of problems would not be about introducing new arbitrary configuration options, but instead be about improving re-usability and composability of our code.

PS: But I understand that a decision to reduce flexibility was made here, and I agree that we should get this feature out quickly if it actually helps people.

Relevant conversation on mediawiki.org: https://www.mediawiki.org/wiki/Topic:Tcavf3pq7asuvp4k

I note https://github.com/wikimedia/data-values-value-view/pull/159 was not merged either...

What really needs to be done to get this shippable?

I guess a lot of things have changed in the last 20/21 months...

Are there any updates/progress on this issue? The OpenStreetMap Wikibase has both the local images and it supports Commons, which means every OSM Wikibase "image" property is actually two properties - one of "image" type, and another being a manually copy/pasted string of the local (OSM) wiki file - in case the file is not on Commons. It would greatly simplify things for OSM community if an image property would be a single "media", regardless of where it is actually stored. What could be done to solve this?

I'm going to remove this from the campsite for now as the campsite is not planning to work on it right now.

I had a call with @despens yesterday filling him in on a summary of this task and the steps that would need to get there, and he will try to find someone to create an initial step in this direction, allowing for files from the local mediawiki to be used.

Superceded by T258932

Change 192885 abandoned by Addshore:

[mediawiki/extensions/Wikibase@master] CommonsMedia: Make file repo URI configurable.

Reason:

We have the local media extension now!

https://gerrit.wikimedia.org/r/192885