May 5 2020
Apr 8 2020
Feb 13 2020
Feb 12 2020
Migration to buster done, see https://tools.wmflabs.org/openstack-browser/server/pst.wikidata-primary-sources-tool.eqiad.wmflabs
Hey @Andrew , thanks for the heads up.
The dumps mount is not needed anymore, you can safely eliminate it.
Nov 12 2019
both declared not being involved anymore
That's not true, I didn't say that. @Lea_Lacroix_WMDE , could you please rephrase the description?
May 6 2019
No worries @Andrew and thanks for the update. Closing this task.
May 3 2019
Apr 26 2019
Thanks a lot @Andrew for the reply, here's what you need.
Apr 25 2019
Apr 23 2019
Apr 16 2019
Jan 22 2019
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.
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:
- the code is part of a Wikimedia IEG project: https://meta.wikimedia.org/wiki/Grants:IEG/StrepHit:_Wikidata_Statements_Validation_via_References/Renewal;
- the repository is located under the Wikidata organization umbrella on GitHub: https://github.com/Wikidata/;
- it is in the master branch: https://github.com/Wikidata/primarysources/tree/master.
Jan 21 2019
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. :-)
Dec 14 2018
@Hjfocs: There is no code. https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/PrimarySources/+/master is empty.
Dec 13 2018
Dec 12 2018
Works fine. Thank you @aborrero for your work.
Dec 10 2018
Nov 23 2018
Nov 19 2018
Nov 7 2018
Thanks a lot guys for your work!
Nov 5 2018
Sep 17 2018
T204542 replaces this ticket.
Jul 23 2018
Jul 18 2018
Yes, please, that would be great.
Got it, no problem. Just wanted to avoid manually tagging every task with Wikidata.
Jul 17 2018
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.
Jul 11 2018
Jun 9 2018
May 31 2018
Thanks a lot for the clear explanation!
See T196073 for details
This is unfortunately not possible until a Wikidata UI SDK is made available.
May 24 2018
And sorry if the question sounds silly, I'm no sysadmin :-)
@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 220.127.116.11.
However, listen 18.104.22.168:443; raises error code 99 in the nginx log:
bind() to 22.214.171.124:443 failed (99: Cannot assign requested address)
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.
See also these discussions:
See also this discussion: https://www.wikidata.org/wiki/Wikidata_talk:Primary_sources_tool#Quality_of_sources
May 23 2018
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.