T204542 replaces this ticket.

Yes, please, that would be great.

Got it, no problem. Just wanted to avoid manually tagging every task with Wikidata.

Thanks a lot @Aklapper .
Would it be possible to add Soweego as a subproject of Wikidata , too?

Most probably either on Toolforge or on a cloud VPS project. We do not know that yet, will depend on the hardware requirements of the implementation.

Thanks a lot for the clear explanation!

See T196073 for details

This is unfortunately not possible until a Wikidata UI SDK is made available.

And sorry if the question sounds silly, I'm no sysadmin :-)

In T192292#4197658, @bd808 wrote:

To use the ::nginx module in a Cloud VPS project you would need to write a custom role class and either get it merged into the main operations/puppet.git repo or setup a project local Puppetmaster and add the class there. The "easy" thing to do is sudo apt-get install nginx and then edit the configuration files, but Puppet automation can be nicer in the long term.

@bd808 , I'm trying the "easy" thing, but I don't know which IP the server directive should listen to here.
If you curl -v https://pst.wmflabs.org/v2, the IP is 208.80.155.156.
However, listen 208.80.155.156:443; raises error code 99 in the nginx log:

bind() to 208.80.155.156:443 failed (99: Cannot assign requested address)

See T148170#4227707

A folk from my team is developing a script that enriches plain URL references of a dataset serialized in QuickStatements: https://github.com/EdoardoLenzi9/Wikipedia.StrepHit
It does take care of URL formatting, too.

FYI, a folk from my team is developing a script that enriches plain URL references of a dataset serialized in QuickStatements: https://github.com/EdoardoLenzi9/Wikipedia.StrepHit
It does add the stated in and retrieved references.

And this one: https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Semi-automatic_Addition_of_References_to_Wikidata_Statements#A_whitelist_for_sources

See also these discussions:

• https://www.wikidata.org/wiki/Wikidata_talk:Primary_sources_tool#Quality_of_sources
• https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Semi-automatic_Addition_of_References_to_Wikidata_Statements#A_whitelist_for_sources

See also this discussion: https://www.wikidata.org/wiki/Wikidata_talk:Primary_sources_tool#Quality_of_sources

I totally agree, but I think this must be tackled at the dataset level, not at the tool level.
What you are reporting here is probably caused by the Freebase datasets.

Related to version 1.
Should work in version 2: the codebase is ready to be deployed on beta/test.wikidata (T95289).

There is no way to fix this, due to the lack of specific pointers in the source.
It probably makes more sense to dismiss the small set of affected items.

T148179 left open for future work.

This would require a complete rewrite of the front-end module responsible for the item-based curation: https://github.com/marfox/pst-frontend/blob/master/modules/ext.PrimarySources.itemCuration.js
Unfortunately, it is out of scope for the StrepHit renewal to handle this.
On the other hand, the filter component is not affected by this issue.

Applies to version 2 as well.

Applies to version 2 as well.

Related to version 1.
Should not apply to version 2, but feel free to re-open it in case.

Related to version 1.
Should not apply to version 2, but feel free to re-open it in case.

Duplicate of T148179

Version 2 is implemented as a MediaWiki extension, which has native support for translation.

I think it is unsustainable to keep implementing rules that enforce checks like this one.
Perhaps the data provider can probably be responsible of this.

This depends on the dataset, not on the tool.
StrepHit version 2 has more structured references.

Related to version 1.
Does not apply to version 2.

Related to version 1.
Does not apply to version 2.

Related to version 1.
Should work in version 2.

Related to version 1.
Should work in version 2.