Page MenuHomePhabricator

Articles published with Content Translation are no longer linked to Wikidata
Closed, ResolvedPublic

Description

Users started reporting problems that Wikidata links are no longer automatically created.

After doing some investigation, I concluded that problems started since 1.34.0-wmf.20.
I have checked SAL to see when group 1 wikis were updated to 1.34.0-wmf.20.
Then, went on Catalan Wikipedia to check the articles created with Content Translation and saw that first article published after deployment is Cividade de Terroso and it was not automatically connected on Wikidata, but later connected by some other user.

This is a Regression since automatic linking to Wikidata was working in CX2 since T197221.

Event Timeline

Pginer-WMF triaged this task as Normal priority.Sep 13 2019, 11:11 AM
Pginer-WMF moved this task from Needs Triage to Bugs on the ContentTranslation board.
Pginer-WMF raised the priority of this task from Normal to High.Sep 16 2019, 9:58 AM

This is a regression from T203696.

Our wikidata linking works as follows:

mw.loader.using( [
			'wikibase.api.RepoApi',
			'wikibase.client.currentSite',
			'wikibase.client.getMwApiForRepo',
			'jquery.wikibase.linkitem'
		] ).then( function () {
			mw.hook( 'mw.cx.translation.published' ).add( addWikibaseLink );
		} );

Now the RL module wikibase.client.currentSite does not exist

@Ladsgroup, Need some help here. I guess the above list of modules are no longer needed, and I can just use

mw.loader.using( [
            'jquery.wikibase.linkitem'
        ] )

( The need to import a jquery module is weird, Ideally I should just load a module like wikibase.client.PageConnector, but I guess this is a consequence of removing modularity for reducing RL modules)

Then

var repoApi = new wikibase.api.RepoApi( wikibase.client.getMwApiForRepo() );

is supposed to work. But it is throwing error: TypeError: repoConfig is null from wikibase.client.getMwApiForRepo.js

MODULE.getMwApiForRepo = function () {
		var repoConfig = mw.config.get( 'wbRepo' ),
			repoApiEndpoint = repoConfig.url + repoConfig.scriptPath + '/api.php';

		return wikibase.api.getLocationAgnosticMwApi( repoApiEndpoint );
	};

Which RL module I need to load for getting mw.config.get( 'wbRepo' ), working?

I was testing the above code in https://en.wikipedia.beta.wmflabs.org. In https://en.wikipedia.org, jquery.wikibase.linkitem does not come with wikibase.client.getMwApiForRepo.js - (is that a bug?)

Which RL module I need to load for getting mw.config.get( 'wbRepo' ), working?
I was testing the above code in https://en.wikipedia.beta.wmflabs.org. In https://en.wikipedia.org, jquery.wikibase.linkitem does not come with wikibase.client.getMwApiForRepo.js - (is that a bug?)

You need to add 'mw.config.values.wbRepo' as dependency as well. Something along the lines of:

mw.loader.using( [
            'jquery.wikibase.linkitem',
            'mw.config.values.wbRepo'
        ] )

Change 537348 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] Fix: Articles published with Content Translation are no longer linked to Wikidata

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

Change 537348 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Fix: Articles published with Content Translation are no longer linked to Wikidata

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

Petar.petkovic added a comment.EditedWed, Sep 25, 9:16 AM

The fix has landed with 1.34.0-wmf.24 (deployed on 18 Sep for group 1 wikis like Catalan Wikipedia), but linking to Wikidata is still not working.
Check out some of translations made on 25th of September. Timestamps of when article is created with Content Translation and when that article is linked to Wikidata are not matching. In the two examples, different user has added Wikidata link.

By looking at one of the last articles published before 1.34.0-wmf.20 was deployed, we see that time and author of article creation and Wikidata linking are the same.

Edit: There are many examples of articles created with Content Translation (after deployment of 1.34.0-wmf.24) which are not linked to Wikidata, meaning no one did it manually. I'm not providing examples, as someone might link the page to Wikidata in the meantime.

Change 539222 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] Fix the js error in identifying targetWikiId

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

Change 539222 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Fix the js error in identifying targetWikiId

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

Jpita added a comment.Mon, Oct 7, 2:31 PM

I just translated this article and is still not linking to wikidata
https://pt.wikipedia.org/wiki/Marianne_(serie_de_televis%C3%A3o)
https://www.wikidata.org/wiki/Q67521330

got this message a few hours after creating the article

, this was done manually by that user, right?

I just translated this article and is still not linking to wikidata
https://pt.wikipedia.org/wiki/Marianne_(serie_de_televis%C3%A3o)
https://www.wikidata.org/wiki/Q67521330

got this message a few hours after creating the article

, this was done manually by that user, right?

Yes, another user linked your new article to Wikidata item.
Patch 539222 to fix this problem for the second time was deployed with 1.34.0-wmf.25 and Wikidata linking is still not working.

I just translated this article and is still not linking to wikidata
https://pt.wikipedia.org/wiki/Marianne_(serie_de_televis%C3%A3o)
https://www.wikidata.org/wiki/Q67521330

Was there any js error in console while publishing?

Change 541749 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] wgWikiId -> wgWikiID

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

Change 541749 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] wgWikiId -> wgWikiID

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

Jpita closed this task as Resolved.Fri, Oct 18, 5:07 AM

I have double checked and Wikidata linking is working automatically after publishing again.