Page MenuHomePhabricator

Make Lexemes appear in global usage of Commons files
Closed, ResolvedPublic5 Story Points

Description

As an editor, when I link a Commons file from a Lexeme, I want to see it appearing in the list of usages of the files, in order to monitor the use of a file.

Problem: When a Commons file is linked from a Lexeme or a Form or a Sense, it doesn't show up in the list of global usage.

Example: On Lufballon (L99) the file De-Luftballons.ogg is used for the property "pronunciation audio" but is not listed on Special:GlobalUsage on Commons.

BDD
GIVEN a Commons media file is linked in a statement on a Lexeme (doesn't matter if Lexeme, Form or Sense)
THEN the file is listed on the usage page of the file page on Commons

Acceptance criteria:

  • any usage of a media file on a Lexeme page is registered as a usage on the file page on Commons

Details

Related Gerrit Patches:
mediawiki/extensions/WikibaseLexeme : masterMake Lexeme implement SubEntityProvider
mediawiki/extensions/WikibaseLexeme : masterUpdate parser output for Form and Sense statements
mediawiki/extensions/Wikibase : masterReplace generic code with item/property specific code

Event Timeline

Restricted Application added projects: Wikidata, Multimedia. · View Herald TranscriptSep 11 2018, 3:54 PM
Nikki added a subscriber: Nikki.Sep 12 2018, 12:24 PM

I looked at this today and I think we should revisit the estimation for this task. The reason it doesn't work is that ImageLinksDataUpdater gets an entity and only adds image usages for the entity and not its subentities. The only possible way that I can think of is to add a "getSubEntities()" to EntityDocument interface and implement it with empty value everywhere, then use it in EntityStatementDataUpdaterAdapter + praying that in future we don't end up having subentities that would have subentities of their own.

hoo added a subscriber: hoo.Nov 1 2018, 1:44 AM

I looked at this today and I think we should revisit the estimation for this task. The reason it doesn't work is that ImageLinksDataUpdater gets an entity and only adds image usages for the entity and not its subentities. The only possible way that I can think of is to add a "getSubEntities()" to EntityDocument interface and implement it with empty value everywhere, then use it in EntityStatementDataUpdaterAdapter + praying that in future we don't end up having subentities that would have subentities of their own.

I would suggest to create a new interface for this method, should it be added… I don't think we should clutter up EntityDocument with that.

An alternative would be to create a new interface containing a method that is defined to return all statements (from the entity itself+sub entities). A possible name would be getDependentStatements/DependentStatementListProvider or getSubordinatedStatements/SubordinatedStatementListProvider. This way, we would have a mechanism that is subentity agnostic and we don't need WikibaseRepo to do the right thing™ with the subentities.

I think I prefer the suggestion to add an accessor of subentities. And I don’t see why it couldn’t work for subentities of subentities. If we change EntityStatementDataUpdaterAdapter::processEntity to this:

	public function processEntity( EntityDocument $entity ) {
		if ( $entity instanceof StatementListProvider ) {
			foreach ( $entity->getStatements() as $statement ) {
				$this->dataUpdater->processStatement( $statement );
			}
		}
		if ( $entity instanceof SubEntitiesProvider ) {
			foreach ( $entity->getEntities() as $entity ) {
				$this->processEntity( $entity );
			}
		}
	}

it should automatically support recursive subentities. (But perhaps that should be a separate adapter, not EntityStatementDataUpdaterAdapter? I’m not familiar with these classes.)

Change 472020 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseLexeme@master] Make Lexeme implement SubEntityProvider

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

I’ve uploaded one possible implementation, based on the above comment:

However, this will require a new data model release, and we aren’t even on the latest current release yet, so this would be blocked on T206325: Use wikibase/data-model 9.0 everywhere.

I made two commits simplifying the involved code in preparation of implementing the behavior change:

Discussed how to make the behavior change while not increasing tech debt with Lucas. Here is the basic idea: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/472730

Change 477117 had a related patch set uploaded (by Hoo man; owner: Jeroen De Dauw):
[mediawiki/extensions/WikibaseLexeme@master] Update parser output for Form and Sense statements

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

Change 477031 had a related patch set uploaded (by Hoo man; owner: Jeroen De Dauw):
[mediawiki/extensions/Wikibase@master] Replace generic code with item/property specific code

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

Change 477031 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Replace generic code with item/property specific code

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

Change 477117 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Update parser output for Form and Sense statements

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

I expected it to be deployed today. Just tried to test it on Luftballons but no change, maybe it's not deployed yet, or some pages need a purge?

Wikidata usually gets a new software versions on Wednesday afternoon (our time), and right now the train was also rolled back, see T206662: 1.33.0-wmf.8 deployment blockers. But you might be able to test this on test.wikidata.org – as far as I can see this fix only requires changes to be deployed to the Wikibase repository, not to Commons.

Change 472020 abandoned by Jeroen De Dauw:
Make Lexeme implement SubEntityProvider

Reason:
We used another approach, see https://phabricator.wikimedia.org/T204066

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

Lea_Lacroix_WMDE closed this task as Resolved.Dec 13 2018, 10:31 AM
Lea_Lacroix_WMDE claimed this task.

\o/
Works after making an edit on the Lexeme page and purging the Commons page.