[02:18:58] Hello, there are some IP user adding strange link to the description of various items [02:19:03] I wonder if it is possible to add that into AF to prevent such edit [02:19:14] (ref: https://www.wikidata.org/wiki/Wikidata:Administrators%27_noticeboard#Report_concerning_multiple_users [14:24:13] pintoch: oh [14:24:13] here [14:24:15] :D [14:24:18] LONG LIVE IRC [14:24:26] :-D [14:24:44] and long live the Telegram bridge actually, it works super well [14:24:46] is there any phab ticket tracking sometihg like this already? [14:24:55] Or an open refine ticket? [14:25:48] we have this for the reconciliation service: https://phabricator.wikimedia.org/T244847 [14:27:11] does the reconciliation API need persistence? [14:30:00] no, it does not keep any state [14:30:07] nice [14:30:46] if it were in PHP would you still support it? [14:31:27] I dream of it being in PHP! Do you mean, would I still work on it as a developer, personally? [14:31:46] (the reconciliation service is not part of the OpenRefine project currently) [14:32:30] I was told the WD telegram members oppose a bridge? [14:34:07] inductiveload: ah, then I am mixing up with another channel [14:34:30] i do not want to use Telegram because it needs my "real life" account [14:34:56] (also I am sick of having tons of chat apps) [14:37:57] pintoch: oh right! its not really worked on as part of open refine then or? [14:38:08] and open refine folks would prefer for it to be in PHP and maintain it like that? [14:39:07] indeed, it is just something I maintain in a personal capacity so far ("maintain" is maybe a big word actually >_<) [14:39:36] OpenRefine folks probably do not have any strong feelings about the language it is written in [14:41:32] OpenRefine users just want a reliable service they can hit hard, OpenRefine contributors do not care about the service (since they do not interact with the code base) [14:45:48] i forgot what the payloads to this api look like again [14:45:56] is that documented somewhere without digging through the python? [14:47:46] I cant remember if I thought it would make sense to have it just exist as a mediawiki extension before or not [14:48:13] I think we should just both try and carve out some time and port it to PHP and a mediawiki extension [14:48:24] shame this isn't in person, otherwise we might already have started, hahaha [14:49:12] totally! [14:49:28] the API is decribed here: https://reconciliation-api.github.io/specs/latest/ [14:50:23] are there e2e tests that dont care about it being python? [14:50:35] if there are aspects of the API that are unnatural to implement in a MediaWiki environment, we can change the specs too (coordinated in the W3C group) [14:51:39] I imagine the spec allows an api to edits only to reconcile against a single service, so in the case of a MW extension, to only reconcile for the wikibase it si hosted for? [14:51:43] no, because I do not really know how I would write those tests without relying on expectations about the data that is in the Wikibase instance *and* the heuristics used in the reconciliation endpoint (such as search scoring) which are beyond the scope of the specs [14:52:12] yes exactly, the specs describe a single service, which exposes a single database [14:52:35] hmmm, search scoring [14:52:58] but with a fixed known set of data, and a fixed wikibase version for example, in theroy woudl you be able to create some sort of CI then? [14:53:37] yes, you would be setting in stone the particular scores returned by your implementation (and that is useful, you would know if they change unexpectedly) [14:54:45] but it would be unreasonable for me to write up a series of test cases and say things like "When querying for 'R. Astley', the service should return 'Rick Astley (Q12345)' with score 78.4" [14:55:30] because maybe that is what my own implementation currently returns, but it's arbitrary and only makes sense in comparison to other queries where you will get higher or lower scores [14:55:31] okay, right [14:55:39] *puts his head in about to speak in a conference mode* [14:57:19] ideally there should be a way to formulate those test cases without relying on exact equality of the entire JSON responses, but only do assertions about parts of them (but even then, it is probably hard…) [14:58:23] one thing I am thinking of is extending https://reconciliation-api.github.io/testbench/ to perform a series of automated checks against an endpoint if you give it some hints about the sort of entities that live in the service (so it can make sort of meaningful queries) [14:58:57] I guess it could be written with CI use cases in mind (with a CLI interface or so) [15:54:40] pintoch: are you PHP savy then? :) [15:55:28] and I guess we should start a fresh repo? [15:55:39] its only 276 commits, how hard can it be? ;) [16:01:26] pintoch: hmmm `pip install convert2php` [16:01:27] ;) [16:01:58] "simple php code" boring [17:53:56] Hi, I am making a new version of theyrule.net, and I am trying to use Wikidata as the main data source, which means adding a lot of data! I plan to add the boards and revenue for companies from this list for a start: https://en.wikipedia.org/wiki/List_of_largest_companies_in_the_United_States_by_revenue [17:53:57] So far I have entered and or updated the boards and revenues for the top ten: https://w.wiki/4KB6 [17:53:57] I would like to invite friends and family to help, I am going to make some instructions etc, but I would also like to have a copy of a list of all the companies I want them to help update, so they can claim the ones they have done and the ones they plan to do. I think it makes sense to put that on Wikidata as a project page. [17:53:58] My question is: What is the best way to go about that - is there anything that I should know? [18:13:20] Is there a better place to ask this quaestion? [18:17:11] It's Sunday [18:17:27] Most people are with families and stuff [18:19:52] Ahhh, Sunday for me is also the day I get to work on my personal projects! But thanks, that makes sense! [18:21:15] I would suggest hanging round but EU awake hours on a weekday are probably best [18:21:22] Given wikidata is managed by WMDE [18:24:23] Guest52: the canonical answer is some kind of on-wiki page [18:25:29] but if you are working in some kind of "live" collaborative way, you could use something like an EtherPad or a public Google Sheets (or equivalent) to keep track [18:26:44] probably instructions and so on make more sense on-wiki, because then you get to use {{Q|xxxx}} templates etc [18:26:45] 10[1] 10https://www.wikidata.org/wiki/Template:Q [18:34:22] Thanks inductiveload. I was thinking about using Google Sheets - but then I thought in might be more in the spirit of things to do it using wikidata. I know there is a wikidata companies project: https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Companies. I have asked this question there. I was thinking of just starting a page on there to [18:34:22] host a table of all the companies and progress. Is that what you meant by "on-wiki"? [18:35:42] Yeah, just some page that starts Wikidata: [18:37:43] If you use some kind of off wiki thing for "live" collaboration, you can link to it from there [18:37:46] Thanks! [18:37:57] Rad [18:39:07] Imo on wiki is best, but it's also very frustrating if you need to keep refreshing [18:40:15] So it mostly depends on the pace of collaboration [18:42:19] Ahhhh, of course, there is no real time collaboration! [18:43:30] Hmmmm, maybe I will just use Google Sheets. It may save some errors, not that I expect rapid colaboration, but the idea of that happening even once or twice could be really frustrating! [18:44:34] Wikidata purity may have to take a back seat to practicality. [18:46:35] Of course I will still use Wikidata as the data store! [18:46:47] Well as long as the sheet is public, I don't think it's too controversial [18:50:07] Fair! [18:50:31] And the instructions will probably be easier on wiki anyway [18:50:55] So it's basically just the progress tracking and synchronisation [19:12:19] Exactly, thanks again! [19:21:23] addshore: wow nice, yes I am keen to give it a try! [19:22:14] my first goal was to create a new extension which would first just serve the description of the service (the thing you obtain when you do a GET on the endpoint) and then iterate from there, adding features gradualyl [19:23:40] I do not think it would be that useful to start from the existing wrapper, since the architecture will be quite different (since we would not go through the MediaWiki web API anymore) [19:28:57] (and also: I haven't programmed in PHP in about 15 years, maybe… but that is a detail, right ^^) [21:48:28] please protect [[Q839920]] and [[user talk:stang]], excessive vandalism [21:48:29] 10[1] 10https://www.wikidata.org/wiki/Q83992013 => [21:48:32] 10[2] 10https://www.wikidata.org/wiki/user_talk:stang [21:48:36] !admin@wikidata ^ [22:05:18] done, koi [22:08:25] ty [22:08:30] np