Page MenuHomePhabricator

[Task] Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons
Closed, ResolvedPublic


For the Wikibase repo, the URL of Wikimedia Commons is hardcoded into extensions/ValueView/lib/jquery.ui/jquery.ui.commonssuggester.js and lib/includes/formatters/CommonsLinkFormatter.php, as well as in repo/includes/CachingCommonsMediaFileNameLookup.php.

A new setting $wgWBRepoSettings['commonsSiteId'] shall contain the id for the desired wiki providing the files. If this is not set, the default will be pointing to Wikimedia Commons.

Event Timeline

despens claimed this task.
despens raised the priority of this task from to Low.
despens updated the task description. (Show Details)
Ricordisamoa renamed this task from Make Wikibase Repo work with a customs File collection, not only wikimedia commons to Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons.Feb 26 2015, 5:51 AM
Ricordisamoa updated the task description. (Show Details)

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

@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'                 => '',
   '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.

Jonas renamed this task from Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons to [Task] Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons.Sep 10 2015, 1:21 PM

I note 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.

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)

despens claimed this task.

Rhizome commissioned the LocalMedia extension with Professional.Wiki, which provides this features. The extension has also become part of the official Wikibase Docker distribution.

Change 192885 abandoned by Addshore:

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


We have the local media extension now!