No worries @Andrew and thanks for the update. Closing this task.

@Andrew : friendly bump. I double-checked with User:Tupini07, but no email was received regarding this so far.

Thanks a lot @Andrew for the reply, here's what you need.

cloud-services-team : friendly bump, this is becoming quite urgent, since we need to fix a couple of bugs that hit the project VPS instances. CCing @aborrero , @Andrew , @bd808 , @Bstorm.

cloud-services-team , CC @Harej

I'm sorry I don't have enough knowledge of your internal procedures to understand your point, @MaxSem:

Per T196073#4896829, this is not ready for review yet.

But you served as the first reviewer, what am I getting wrong?

when (...) the extension has been merged into Git master.

Can you please clarify what are the steps needed to address this? First of all, which Git master are you talking about? The extension code already lives in the master branch of its Git repository: https://github.com/Wikidata/primarysources/tree/master
I guess you are implicitly referring to some other Git master.

Hi @MaxSem,

Nobody reviewed it because you just made a pull request to an obscure repository that nobody knows about

I'm afraid I don't understand your point of view for the following reasons:

1. the code is part of a Wikimedia IEG project: https://meta.wikimedia.org/wiki/Grants:IEG/StrepHit:_Wikidata_Statements_Validation_via_References/Renewal;
2. the repository is located under the Wikidata organization umbrella on GitHub: https://github.com/Wikidata/;
3. it is in the master branch: https://github.com/Wikidata/primarysources/tree/master.

Hi @sbassett and thanks for the follow up

@MaxSem , thanks a lot for your review! This was my first experience writing a MediaWiki extension, so I must have done a bunch of obvious mistakes. :-)

@Hjfocs: There is no code. https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/PrimarySources/+/master is empty.

In T204542#4817688, @sbassett wrote:

Not seeing anything in master or REL1_32 for this. Is it somewhere else?

In T196073#4822907, @MaxSem wrote:

For starters, this extension's code should be in Wikimedia source control.

Works fine. Thank you @aborrero for your work.

@bd808 @aborrero : friendly bump (maybe I'm missing some specific tags?)

Thanks a lot guys for your work!

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.