An interesting discussion about inverse properties is now happening at https://www.wikidata.org/wiki/Wikidata:Property_proposal/has_Member.

Yes I am in contact with them (we had an online meeting on June 22 and they reported to me the existence of the endpoint, which I did not know and I was very happy to discover).

The sections of https://www.wikidata.org/wiki/MediaWiki:Wikibase-SortedProperties in principle could be used as section titles, although fixes would be probably needed to make some of them clearer. T328217 regarding the creation of a specific section, in the items, for Wikimedia-related properties, is also related to this issue.

Maxlag dropped from 51 minutes (!) to a normal ca. 5 seconds at 10 UTC today, but already shortly after 11 UTC it restarted a significant growth and is now (17:30 UTC) slightly above 8 minutes. Considering the light editing today on QS 3.0, I guess we can say QS 3.0 is probably unrelated with the issue we are having.

As a note: I have started a new import through QS 3.0 a few hours ago - cf. https://www.wikidata.org/wiki/Property_talk:P227#Massive_import_of_data_from_GND_(May_2026) - but since the tool respects maxlag, it should not have a relevant impact.

I proposed a possible solution for this issue in T423011; an alternative solution would be T106670. IMHO, anyway, the priority of this should be raised.

I think this would be a better solution than T106670 (which, if I understand correctly, proposes to enable LabelLister by default).

thanks for the investigation @Lucas_Werkmeister_WMDE , the second would be a very good improvement (not only for Wikidata, but if possible I would appreciate it also on Wikibase Cloud)

Hi, this may be related to my import of data from GND into Wikidata via QS 3.0 which ran from April 1 to April 5 (https://w.wiki/KdP6). I thought QS 3.0 respected automatically maxlag; but maybe there is some kind of exception to be removed for users with admin flag. I have just reported at https://meta.wikimedia.org/wiki/Talk:QuickStatements_3.0#Maxlag_issues

Related (more general) task: T341405

I confirm, they work now. Thanks very much!

Thanks @sbassett I confirm the gadgets now restarted working; @EMill-WMF OK I opened T419285 for these 3 library catalogs.

Hi @EMill-WMF thanks very much for the update; so I send you here (or is it better to open a separate ticket?) some other library catalogs used in existing gadgets by User:Bargioni, which should be allowlisted:

• https://catalogo.pusc.it used in https://www.wikidata.org/wiki/User:Bargioni/pusc.js + https://www.wikidata.org/wiki/User:Bargioni/P12458_add_or_update_P1810.js
• https://parsifal.urbe.it used in https://www.wikidata.org/wiki/User:Bargioni/P12458_add_or_update_P1810.js
• https://opac.sbn.it used in https://www.wikidata.org/wiki/User:Bargioni/P396_add_or_update_P1810.js + https://www.wikidata.org/wiki/User:Bargioni/Compare_Titles.js

The problem persists with items also: https://www.wikidata.org/wiki/Q137425313 (del. 2025-12-17) and also https://www.wikidata.org/wiki/Q121585638 (del. 2025-10-04) still appear in query results.

important IMHO, and currently in Wikidata Preferences > Gadgets:

• Merge
• labelLister
• moveClaim
• keyShortcuts
• DuplicateReferences
• currentDate
• relatedItems
• Compact items
• Rearrange Values

IMHO this can be closed as solved, https://www.wikidata.org/wiki/MediaWiki:Gadget-moveClaim.js and https://www.wikidata.org/wiki/User:Magnus_Manske/duplicate_item.js do what the proponent @SJu requested.

And T105427 seems also related to this issue.

Previous tickets include T272120 and T155954 - I also have a case found today, in https://w.wiki/7NMU I still see http://www.wikidata.org/entity/Q137425313 which was deleted on 17 December (6 days ago).

Cf. now draft of https://www.wikidata.org/wiki/Wikidata:External_identifiers/Obsolescence where this ticket is mentioned.

IMHO it would be useful to have the possibility to do the following: select through a SPARQL query a group of items, and extract a dump containing all these items. https://wdumps.toolforge.org/ allows to do this only to a very limited extent, selecting one or more statements that the items included in the dump must contain; using a query to select all the desidered items would allow much more flexibility.

I have just opened this thread: https://www.wikidata.org/wiki/Wikidata_talk:WikiProjects#Update_lists_of_participants

Thanks very much for the patch! I would just add to the points:

• Update the documentation on MediaWiki: https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format.

As a positive update, I have retried today a federated query (https://w.wiki/Efw6) and it worked perfectly; a similar one (https://w.wiki/Eg6V) results in "Unknown error: POST with unexpected action parameter value: null" but it seems to be an issue on BNCF side, not on WDQS side.

T378627 surely mitigated this issue IMHO, although in fact importing a gadget from Wikidata to Wikibase remains challenging for most common users probably.

Reported to Magnus Manske (https://www.wikidata.org/w/index.php?title=User_talk:Magnus_Manske&diff=prev&oldid=2315516746).

By the way, restoring the right for Wikidata administrators to block batches in QuickStatements would mitigate the issue; this function ceased to work many years ago.

Should we open a RfC on Wikidata about this and mass-message it to all other projects?

The issue is not reproduced anymore (example of edit: https://datalib.wikibase.cloud/w/index.php?title=Item:Q1&diff=31234&oldid=29566). I think the task can be closed. Thanks very much!

Just to mention the gadget relateditems, which allows to show inverse statements automatically if enabled in the Preferences: https://www.wikidata.org/wiki/MediaWiki:Gadget-relateditems.js

(I report two blog posts about the issue: https://blog.factgrid.de/archives/3467 and https://blog.factgrid.de/archives/3541)

(I have opened https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Improve_Wikidata_handling_of_duplicate_references_in_model_and_UI regarding this issue.)

Maybe the best solution would be adding a parameter to the constraint allowing the user to specify if, for that specific property, "mul" should be taken into account or not. This would be the most flexible solution IMHO.

In my opinion it is highly probably related to T325871 (as I said in my comment of June 7).

I forgot to to write it here, but the issue disappeared more than one month ago. I close the ticket accordingly; I will reopen of course if it happens again.

I have checked again today in https://hypotheseis.wikibase.cloud/wiki/Main_Page and the problem has disappeared; it also doesn't appear in other Wikibase instances on which I have been editing in the last days. So I close the ticket; I will reopen it if it happens again (hopefully not).

@Fring in the above example the precise message I get for the error is:

Illegal value: http://mw138test.wikibase.dev/entity/Q2

Could it be that the problem is that http://mw138test.wikibase.dev/entity/Q2 is a malformed URI, due to the fact that all the URIs on Wikibase Cloud instances have https (i.e. https://mw138test.wikibase.dev/entity/Q2 would be correct)?

It can be reproduced in https://mw138test.wikibase.dev/tools/quickstatements/#/ using:

This has been solved by the same patch which solved T365916; thus I close the ticket.

I tried again today and all the three cases work perfectly as in Wikidata; probably when I tried yesterday afternoon the fix had not been deployed yet on the Wikibase Cloud instance I was using (i.e. https://datalib.wikibase.cloud/).
Thanks very much for the fix!

As of now, in cases 2 and 3 the command is skipped by QuickStatements giving "Error!"; so the edit which should be saved by these commands are not saved; this is highly problematic. Hovering on the errors I get no further information. To be clear, in cases 2 and 3 _edits need to be saved_ (in case 2 the edit should add a further value of a property already having one or more values; in case 3 the edit should add a qualifier to an existing value)

Not exactly. Above I wrote:

It seems that unfortunately the fix didn't solve the issue, although I notice a change: once the batch encounters one of the 3 cases described above, before today it remained stuck in "run" status, whilst now it gives an "error" with no motivation and goes to the next edit. But effectively it is not yet able to save correctly the edits in cases 2 and 3 (for case 1 no edit should be saved, so, although seeing an unnamed error is not ideal and it would be better do see instead "done!" with the message "the value already exists", the present situation is fine because the main issue was the batch being stuck).

In my experience of today, QuickStatements on Wikibase Cloud instances is able (given a property Y with datatype string) is able to create one statement PY:value (if the item has no other values of PY already in itself); however, QuickStatements is unable to create a second value for PY in the same item, or to add qualifiers to the existing value(s) of PY. See T365916 about this.

MediaWiki:Sidebar in specific Wikibase Cloud instances can be edited, as far as I can see; e.g. I have edited the one in my instance, https://hypotheseis.wikibase.cloud/wiki/MediaWiki:Sidebar