Talk:QuickStatements 3.0

QuickStatements 3.0Software collaboration for Wikidata

AboutSurveyUser storiesDocumentationTalk page

Here you can give feedback, post questions and provide suggestions for the development of QuickStatements 3.0, including, but not limited to, commands syntaxes, available command operations, UI, UX, ease of use, specific pages, login flow, error display, csv report, or performance. Thanks for using the tool!

Thank you!

Thanks for the super great tool! Especially the function to remove individual sources or qualifiers is greatly appreciated! I already ran a small test batch. Can I proceed to running larger batches or should I wait? Samoasambia ✎ 16:05, 24 February 2025 (UTC)

Yes, you can! Thank you for your feedback! Cheers, EPorto (WMB) (talk) 16:43, 24 February 2025 (UTC)

Sorry I really don't know what is the links 41.116.26.51 18:25, 14 March 2025 (UTC)

Error?

I'm confused - the documentation links to the existing Quickstatements (v2) but the documentation is for v3? Is this intentional? Those looking for the new quickstatements: https://qs-dev.toolforge.org/ Thanks. - Fuzheado (talk) 16:24, 24 February 2025 (UTC)

@Fuzheado, I think this is solved. Let me know if it is not! Thanks for joining! Joalpe (talk) 23:00, 24 February 2025 (UTC)

yes i'd like to join 41.116.26.51 18:26, 14 March 2025 (UTC)

sorry me too i was really confused 41.116.26.51 18:29, 14 March 2025 (UTC)

Target tool url?

I'm guessing qs-dev will change to something else shortly - do you have a plan for what the final URL for the tool will be? (And thanks for developing this, it looks amazing so far!) ArthurPSmith (talk) 21:31, 24 February 2025 (UTC)

Oh I heard at the end that the plan was to replace quickstatements.toolforge.org - that's reasonable but if it's taking too long to come to agreement on that I think something like qs3.toolforge.org would be fine. ArthurPSmith (talk) 21:38, 24 February 2025 (UTC)

Run vs. Run in background

Love it so far. Will QS3 only have the run in background option? For small edits or tests, I sometimes like the non queued version. Best NGOgo (talk) 17:18, 25 February 2025 (UTC)

Hello @NGOgo, all batches run in the background. However we decide technically to do it, we want the user experience of running small batches to be as fast as possible, and we are working on this. Thanks for your feedback, ACorrêa (WMB) (talk) 17:15, 26 February 2025 (UTC)

Thanks. I would love to have a „test the first x rows“ option, since that‘s the biggest reason I usually do a foreground option first :) Best NGOgo (talk) 17:26, 26 February 2025 (UTC)

Hmmmm, that's an interesting idea. I'll bring it to the team. ACorrêa (WMB) (talk) 17:52, 26 February 2025 (UTC)

Issue with removing two references having one coincident part

Tracked in GitHub:Bug 204Resolved

Hi! I would like to report the following issue with the REMOVE_REF function. I started, inside this batch (https://qs-dev.toolforge.org/batch/187/), the following 4 commands:

REMOVE_REF	Q124412568	P21	Q6581072	S887	Q69652498
REMOVE_REF	Q124412568	P21	Q6581072	S813	+2024-02-05T00:00:00Z/11
REMOVE_REF	Q124412568	P21	Q6581072	S887	Q69652498
REMOVE_REF	Q124412568	P21	Q6581072	S813	+2024-07-09T00:00:00Z/11

As you can see from the item, the first two commands pertained to ref 1 and the second two commands to ref 2. Unfortunately, only command 4 succeeded; command 1 and 2 got "The next command failed" and command 3 got "No reference parts with given value". Did I do something wrong or is it a bug?

I add another question: from documentation, I see REMOVE_REF and REMOVE_QUAL exist only in V1 syntax and not in CSV syntax; this is strange because, in old QuickStatements, V1 and CSV syntaxes could do the same things; so I wonder if you have already implemented REMOVE_REF and REMOVE_QUAL in CSV syntax but the documentation hasn't been written yet, or REMOVE_REF and REMOVE_QUAL aren't yet implemented in CSV syntax but are scheduled to be implemented; otherwise, why did you chose to implement REMOVE_REF and REMOVE_QUAL only in V1 syntax? Thanks in advance! Epìdosis 20:46, 25 February 2025 (UTC)

Hello @Epìdosis, thanks for reporting this bug, it should have worked because, as I saw in the history, there were two Q69652498 as reference parts, so the second one should have worked. Command 3 combined the previous changes but failed to perform the modifications, but it should have worked. I am working on this bug and I'll return to you.

About v1 x csv syntax, REMOVE_REF and REMOVE_QUAL are currently only available in v1 syntax. If there is demand for it, it is possible to implement in csv as well, after deciding on how that syntax would look like.

Thanks for your feedback. Kind regards, ACorrêa (WMB) (talk) 17:27, 26 February 2025 (UTC)

I was able to track the problem. The first REMOVE_REF removed both Q69652498 and the third tried to remove it but found none, so it throwed an error (because they were combined it used the previous state instead of checking the API every time, which is the desired behaviour). REMOVE_REF should remove just one reference part. I filed an issue no GitHub and we will work on it. ACorrêa (WMB) (talk) 17:33, 26 February 2025 (UTC)

@ACorrêa (WMB): I have a similar issue with https://qs-dev.toolforge.org/batch/221/, which I had to stop: the intent was removing entirely references to VIAF on P21; however, in at least 3 cases it didn't behave as expected, because there were other references with the same P813 as VIAF and so P813 was removed from the other reference instead from the VIAF one (examples: 1, 2, 3). This is a complex problem and I would suggest two possible ways to solve it:

1. since we add references with multiple parts in one line of text, e.g. Q237888 | P36616 | Q219 | S98324 | Q208456 | S77057, I think we should also remove references with multiple parts in one line of text: so the reference is removed only if it contains all the parts listed in the line
2. I think the should be a slightly different command that allows to remove an entire reference if it contains one part: e.g. REMOVE_REF! | Q237888 | P36616 | Q219 | S98324 | Q208456 to remove all the entire references to Q237888 | P36616 | Q219 containing S98324 | Q208456 - this would be a very simple and effective solution IMHO, since it avoids the user mistakenly removing only some parts of the reference and leaving others because they didn't notice them (e.g. it would avoid this).

Thanks! Epìdosis 09:58, 28 February 2025 (UTC)

Hello @Epìdosis, those are great ideas! I'll bring it to the team. It makes sense that having two or more S's in REMOVE_REF should remove two parts, the difficult bit is deciding if it should behave as two REMOVE_REF or that it should be more restrictive than two REMOVE_REF (like you suggested). We didn't implement that to gather some feedback on it. Your suggestion makes sense, because if the user wants to remove two parts, they can do two REMOVE_REF...

The new syntax is cool, and it definitely looks very useful, I'll bring it to the team as well.

By the way, the previous issue, of REMOVE_REF removing 2+ parts, is already solved. Best, ACorrêa (WMB) (talk) 17:41, 28 February 2025 (UTC)

Batches stopping without apparent reason

Tracked in GitHub:Issue 207Resolved

Hi! In the last hours I have sometimes experienced batches stopping with no apparent reason; in order to have them restart, I had to "Stop execution" and then "Restart". E.g. https://qs-dev.toolforge.org/batch/185/ stopped at 23:17 CET (last edit) and restarted at 0:00 CET (first edit) after I stopped and restarted. Could this issue be avoided? I also got some 502 errors in the last hours, with the message "Webservice is unreachable".

Another related question: which is the maximum rate of edits per minute that old QuickStatements and QuickStatements 3.0 presently allow? Thanks again and good night, Epìdosis 23:04, 25 February 2025 (UTC)

P.S. https://qs-dev.toolforge.org/batch/185/ is a batch of 18579 commands and it is running well, apart from these unexpected stops; so it is well above the tested 11000 commands that are presently mentioned in the documentation. Epìdosis 23:09, 25 February 2025 (UTC)

Hello @Epìdosis, thanks for sharing this. Yes, we are having difficulties with multiple large batches, but are working on it. For the moment, you can stop and restart them. Sorry for that inconvenience. Kind regards, ACorrêa (WMB) (talk) 17:13, 26 February 2025 (UTC)

Content-Security-Policy (?)

Tracked in GitHub:Issue 205Resolved

I'm not sure it is relevant: in the browser console appears the following message, anyway the .css is correctly loaded.
Content-Security-Policy: The page’s settings observed the loading of a resource at https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.colors.min.css (“default-src”). A CSP report is being sent.
Bargioni (talk) 15:54, 26 February 2025 (UTC)

Hello @Bargioni, thanks for the notice. I'll work on it. Instead of the CDN, it's best for us to serve that static file just as we are serving the others. Best regards, ACorrêa (WMB) (talk) 17:10, 26 February 2025 (UTC)

Combining commands

Tracked in GitHub:Feature 266Open

Presently in the documentation I read: "Multiple command statements targeting the same entity are combined and executed with one API call. This improves the speed of command execution." The documentation doesn't specify that the command statements, to be combined, should be consecutive. However, in https://qs-dev.toolforge.org/batch/211/ I put 177 + 177 command statements for the same items, and I got 344 edits instead of the expected 177, so the two commands did not combine, probably because they weren't consecutive. Options thus are:

1. update documentation to specify that commands, to be combined, should be consecutive - however, requiring users to order commands could be not so user-friendly
2. if possible, when ingesting commands QS3 should order them by target item, so as not to mix possible commands to be combined; I think it would be much better, and not implausible, since batches are maximum around 20k or 25k lines

Thanks in advance! Epìdosis 14:43, 27 February 2025 (UTC)

Hello @Epìdosis, thanks for the heads up. We will update the documentation accordingly. About reordering commands, I don't think we should change the user command's order without consent. Maybe we could implement a new toggle for that... I'll bring it to the team. Thanks!! ACorrêa (WMB) (talk) 17:19, 27 February 2025 (UTC)

It makes sense a toggle rather than reordering by default, I agree. Thanks very much, I subscribe to this thread to get updates! Epìdosis 17:20, 27 February 2025 (UTC)

Run QS3 by URL

Tracked in GitHub:Feature 194Open

Is it possible to run QS3 by URL, like in https://www.wikidata.org/wiki/Help:QuickStatements#Running_QuickStatements_by_URL ? Thx again. Bargioni (talk) 12:29, 28 February 2025 (UTC)

Hello @Bargioni, currently not but it will be possible. This is the GitHub issue, if you want to subscribe to its notifications. Best, ACorrêa (WMB) (talk) 17:37, 28 February 2025 (UTC)

Batches and blocks

Tracked in GitHub:Feature 234Open

Since the situation of old QuickStatements, due to batches of blocked users still running, is quickly deteriorating (cf. phab:T386978 and d:User talk:Magnus Manske#QuickStatements issues with batches of blocked users), I think it should be prioritary to be ready to QS3 also being widely misused soon. So I would like to ask: if admnis are able to block individual batches in QS3 (as they were, a few years ago, in QS) and, most importantly, if QS3 checks if the user is blocked each time the batch tries to make an edit and, if the user is blocked, stops automatically the batch and doesn't allow the user to restart it unless unblocked. Thanks as always, Epìdosis 21:56, 3 March 2025 (UTC)

Hello @Epìdosis, thanks for bringin this. For me it seems there are three things here:

1. Don't allow blocked users to create batches. This seems the easiest, and it will already do great good. We already check for autoconfirmed, so it's basically checking another field that we receive from the profile endpoint.
2. Automatically stop running batches from blocked users. This seems harder and more complex. We can't check for every command or every N commands if a user is blocked. I don't know what is the API response when the user is blocked, probably it doesn't specify "blocked". So, maybe with (1) and (3) this is not necessary.
3. Allow Wikidata admins to stop batches. This is a bit harder than (1) but doable in any way. We would need to implement a new button instead of the stop (because the owner can still restart it), and also a way for to check if the user is a Wikidata admin.

What do you think of these? Best, ACorrêa (WMB) (talk) 17:16, 5 March 2025 (UTC)

@ACorrêa (WMB): thanks for unpacking this. 1) is easy, I agree it is good, although I don't remember cases in which already blocked users start batchs; but it may well happen, so I think it is a good start implementing this. 3) worked in old QS for many years, I think it should be easy - in old QS the stop button was the same and I think it worked differently if it was used by the user who started the batch, or by an admin, or by a user who wasn't neither the starter nor an admin (in this last case basically it didn't work); basically this is useful to stop batches which contain good-faith errors made by good users, so it is better to stop their batches instead of blocking them. 2) I think this is also necessary: if a LTA uses 3 different account, each with 3 batches, each day, basically admins would need to block both 3 accounts and 9 batches a day, and there are already difficulties in managing this situation, which could worsen; I think checking every 1k or 2k commands if a user is blocked would be a very good compromise. Epìdosis 18:01, 5 March 2025 (UTC)

@Epìdosis a LTA can use/create autoconfirmed accounts easily? Because we don't allow non-autoconfirmed users to create batches. Is that scenario feasible even with this protection? ACorrêa (WMB) (talk) 18:38, 5 March 2025 (UTC)

Yes, it is and in fact it is already happening (see links above); having an auto-confirming multiple account is very easy, since the requisites are just 4 days of registration and 50 edits. Epìdosis 20:21, 5 March 2025 (UTC)

Damn. Okay, so I guess there is no escape from checking blocked status mid-batch. ACorrêa (WMB) (talk) 20:27, 5 March 2025 (UTC)

Historical note: the functionality allowing admins to stop batches stopped working in Summer 2020, I found the report. --Epìdosis 08:11, 15 March 2025 (UTC)

@ACorrêa (WMB): Magnus just added a check for blocked users to the old QuickStatements; maybe you can take inspiration from it, it seems to work well. Epìdosis 17:24, 7 April 2025 (UTC)

Cf. https://github.com/magnusmanske/quickstatements/commit/1af45eef33ba87b5bd214525da3f30459b7581d8. Epìdosis 17:29, 7 April 2025 (UTC)

+ cf. https://github.com/magnusmanske/quickstatements_rs/commit/3e50c3a9356e1ddc34a0de7cfd345a4a78b51be5 (mentioned also in phab:T386978). Epìdosis 14:53, 8 April 2025 (UTC)

Hello @Epìdosis, thanks for sharing those commits. I'll share them with the team. Cheers! ACorrêa (WMB) (talk) 16:52, 8 April 2025 (UTC)

More detailed edit summaries

Tracked in GitHub:Feature 235Open

Would it be possible to include the property and value in the edit summary, at least for simple changes such as adding a single statement? It is very helpful to be able to see this information when monitoring recent changes and searching through revision histories.

--Quesotiotyo (talk) 01:28, 4 March 2025 (UTC)

Hello @Quesotiotyo, thanks for your suggestion. This seems a good thing to implement, indeed. I wonder what should we do about combined commands. We could have 1 edit that changes multiple statements, labels, etc, what do you think we could do in that situation? ACorrêa (WMB) (talk) 17:16, 5 March 2025 (UTC)

Yes, I figured that combined commands might need to be handled differently. My suggestion would be to list out only the PIDs (in plain text as opposed to links) and any language codes involved. For example, here are the summaries for four separate edits made through the Wikidata user interface:

• (‎Created claim: instance of (P31): human (Q5))
• (‎Created claim: given name (P735): Sample (Q111072551))
• (‎Created claim: family name (P734): Person (Q16881132))
• (Added [mul] label: Sample Person)

And if QS 3.0 were to combine those into one edit, the summary might look something like this:

• (Updated Item: P31, P735, P734, mul)

So there would be less information overall but it would still provide some indication of what has been changed, and this should be able to scale up for even larger edits (I guess there would still be a limit though...compare this edit summary which mentions all 43 affected language codes with this edit summary which gives only the total number, presumably because listing them all would have exceeded the character limit).

What do you think, does this sound reasonable or are there too many complexities for it to work?

--Quesotiotyo (talk) 21:13, 5 March 2025 (UTC)

@Quesotiotyo this looks very good. I'll bring it to the team. I believe it is reasnoable, indeed, and it would be helpful to the item watchers to quickly see what was changed. ACorrêa (WMB) (talk) 14:59, 7 March 2025 (UTC)

Batch stopped, but can not restart

Tracked in GitHub:Bug 219Resolved

I have the batch https://qs-dev.toolforge.org/batch/306/ that stopped after 37%, in the list https://qs-dev.toolforge.org/batches/NGOgo/ it's marked as DONE, so I can't stop and restart. Thanks to the great report download, I fixed it, so no need to act on it, just a bug-report. Best NGOgo (talk) 08:13, 7 March 2025 (UTC)

Hello @NGOgo! Yeah, it should have not marked itself as done... Can you share the commands that caused the error so we could investigate? You can also send them to me by email if you want. Best! Also, if you want, we can restart the batch manually here. ACorrêa (WMB) (talk) 14:58, 7 March 2025 (UTC)

Thanks. I only see the error on https://qs-dev.toolforge.org/batch/306/ "LAST could not be evaluated" while creating a new item. "LAST P1454 Q117600050 S854 "https://spis.ngo.pl/191460-lubelskie-hospicjum-dla-dzieci-im-malego-ksiecia" S813 +2025-03-07T00:00:00Z/11".

No need to restart, I fixed it with a new batch. NGOgo (talk) 16:48, 7 March 2025 (UTC)

Running QuickStatements by URL

Tracked in GitHub:Feature 194Open

Is it possible to run QuickStatements by URL in the new version. So far it is possible and I am using this feature for a tool. Hogü-456 (talk) 20:26, 21 March 2025 (UTC)

Hello @Hogü-456, currently not but it will be possible. This is the GitHub issue, if you want to subscribe to its notifications. Best, ACorrêa (WMB) (talk) 21:10, 21 March 2025 (UTC)

Reference split

I run the following batch as a Test and it created to references instead of one what I would expect. This was the raw input of the statement. qid,P463,S854,S813 Q325859,Q1205780,"https://www.deutsches-klima-konsortium.de/ueber-uns/",+2025-03-21T00:00:00Z/11 Hogü-456 (talk) 21:34, 21 March 2025 (UTC)

Hello @Hogü-456, in the csv syntax, the uppercase S always creates a new reference block, unlike in v1 syntax. To add a reference part to the same block, use a lowercase s in the second reference. Best regards, ACorrêa (WMB) (talk) 19:40, 28 March 2025 (UTC)

@ACorrêa (WMB) Thank you for the answer. The documentation says an Exclamation mark adds before the S adds a new reference. So it is necessary to change the documentation. Hogü-456 (talk) 19:47, 28 March 2025 (UTC)

@Hogü-456 that's for the v1 syntax. In the csv syntax it is another uppercase S.

• v1 works with S and !S for adding a new block
• csv works with S which will always create a new block and s to stay in the same block

Best, ACorrêa (WMB) (talk) 19:57, 28 March 2025 (UTC)

Adding quantity with units as qualifiers failed

Tracked in GitHub:Bug 265Open

Any idea why this test batch failed? I tried to remove age of subject at event (P3629) qualifiers without a unit and add them back with a unit (years old (Q24564698)).

REMOVE_QUAL | Q1038599 | P3602 | Q28752945 | P3629 | 33
Q1038599 | P3602 | Q28752945 | P3629 | 33U24564698
REMOVE_QUAL | Q10998907 | P3602 | Q29379624 | P3629 | 49
Q10998907 | P3602 | Q29379624 | P3629 | 49U24564698

Samoasambia ✎ 14:36, 24 March 2025 (UTC)

Hello @Samoasambia, after some debugging I figured out that units in qualifiers and references are not working properly. That's why it failed. I added our tracking template in this section so that you can check the issue status in GitHub. Thanks for sharing this bug. Best, ACorrêa (WMB) (talk) 19:55, 28 March 2025 (UTC)

Thanks a lot! Samoasambia ✎ 20:26, 28 March 2025 (UTC)

Restarting the batch

Tracked in GitHub:Feature 249Resolved

After processing my batch nr:605 https://qs-dev.toolforge.org/batch/605/ I got 80 errors Error 429 ('request-limit-reached'): Exceeded the limit of actions that can be performed in a given span of time and now I can't Reset the errors and restart the batch. This used to work in the V2. Also on 429 error, you should automatically wait for a while and retry and continue executing commands. Lesko987a (talk) 15:36, 24 March 2025 (UTC)

Hello @Lesko987a, QS3 now automatically won't reach request-limit-reached, so you don't need to worry about that type of error anymore. Besides that, we implemented a "Rerun" button to reset all errors, try it out! Best regards, ACorrêa (WMB) (talk) 16:11, 22 April 2025 (UTC)

Can't handle three letter label and description under csv mode

Tracked in GitHub:Bug 242Resolved

Hi, I am a Taiwanese Hokkien (Q36778) speaker and Wikidata contributor, I can't add label and description using the language code nan under csv mode. And it seems other three code languages are effect too. I test adding official name or native name is ok to add three letter language content. Supaplex (talk) 04:39, 28 March 2025 (UTC)

Hello @Supaplex yes, currently QS3 is (wrongly) only accepting two letter language codes, we already have an issue for that, if you want to get notified through GitHub. We'll work on it. Best, ACorrêa (WMB) (talk) 16:16, 28 March 2025 (UTC)

Edit rate

Tracked in GitHub:Issue 248Resolved

(amplifying Lesko987a above)

Just used QS3 for the first time (Batch 815, User:JhealdBatch). It seems very smooth. But from 3998 requests, it's given me 1280 errors ("Error 429 ('request-limit-reached'): Exceeded the limit of actions that can be performed in a given span of time").

Does QS3 not manage its edit rate automatically?

Also there seems to be no "Try to reset errors" button, to try to re-run requests that have failed.

Without fixes for these two issues (GitHub #248 and #249) QS3 is pretty much unusable. Jheald (talk) 13:57, 3 April 2025 (UTC)

Hello @Jheald, we apologize for the inconvenience. We are working on solving it, so that QS3 can automatically correct its request rate to not incur into a 429. We are also working on the rerun button. Cheers, ACorrêa (WMB) (talk) 19:42, 3 April 2025 (UTC)

Hello again @Jheald, we just deployed a fix for the 429 error. Let me know if it happens again. Thanks for your understanding. ACorrêa (WMB) (talk) 17:42, 4 April 2025 (UTC)