Page MenuHomePhabricator

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

Description

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 created this task.Feb 23 2015, 9:38 PM
despens claimed this task.
despens raised the priority of this task from to Low.
despens updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 23 2015, 9:38 PM
Lydia_Pintscher set Security to None.
Lydia_Pintscher added a subscriber: daniel.
despens updated the task description. (Show Details)Feb 24 2015, 3:33 PM

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

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

Ricordisamoa added a subscriber: Ricordisamoa.
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.

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

Lydia_Pintscher moved this task from incoming to ready to go on the Wikidata board.Mar 2 2015, 1:56 PM

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

adrianheine added a comment.EditedMar 11 2015, 2:30 PM

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.

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
Restricted Application added a subscriber: Steinsplitter. · View Herald TranscriptSep 10 2015, 1:21 PM
Reedy added a subscriber: Reedy.Dec 15 2016, 7:38 PM
Reedy added a comment.Dec 15 2016, 8:22 PM

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

Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptAug 1 2017, 10:41 AM
Yurik awarded a token.Jan 2 2019, 8:16 AM
Yurik added a subscriber: Yurik.EditedJan 2 2019, 8:23 AM

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?

jmac added a subscriber: jmac.Mar 5 2019, 9:15 PM