Find all other (registered) Wikibase instances that have information for "exact match" to something specific.

A good candidate query for a fresh Wikibase instance could also be to query the Wikibase registry for other instances of Wikibase.

We might also want to consider using some existing graphical UI for the SPARQL endpoint. One popular example is Blockly, and here are two papers that report on doing it for SPARQL:

• http://www.infomus.org/Events/proceedings/CHItaly2015/CHItaly2015/p86-bottoni.pdf
• http://ceur-ws.org/Vol-1456/paper12.pdf

Example for a user-friendly SPARQL interface
http://sparql-playground.nextprot.org/

Accessibility has multiple dimensions.

I like the suggestion of adding a load-dependent server-side delay for API edits.

There has been some erratic behaviour of this feature for Wikidata as well lately, e.g.
https://www.wikidata.org/wiki/Special:Nearby#/page/Q16896007
sometimes goes to where it would be expected, and sometimes to where the user is.

In T104762#3806240, @Smalyshev wrote:

Tabular data on Commons should be a good place for it, not? Do we need yet another place/way to store tabular data?

That seems like a good option indeed. In that case, we'd need a way to pull the data back into the WDQS for visualization.

I would suggest to start the items without a "published in" statement, and to build a tool/ Wikidata game/ Mix'n match catalog for reconciling those mismatches.

Here's a suggestion in terms of mechanisms to avoid malicious re-runs. I'm not sure how practical it is, but perhaps it helps us move forward

I posted this over at https://github.com/SuLab/WikidataIntegrator/issues/33 .

I think a Stop or Cancel button would be nice - sometimes, I know shortly after pressing the Run/ Play button that the query is not precisely what I wanted (e.g. because I changed something in one place, but should have done it in two places), and then I have to wait until it finishes or times out.

Adding the Tools tag in the hope that this helps find people who could help address this issue.

Affects audio files as well - just irritated uploaders at an audio-focused hackathon.
What about just "Describe the file" instead?

I agree that the current "add" buttons at the bottom are hard to find on large pages, and I have seen this put off newbies.
Replacing them with one predictably located bottom on the top sounds like progress to me.

They have created accounts but cannot edit. I am not not there. IP is 186.179.xxx.xx .

Here are notes from a group of people who did not know Wikidata and tried to find their
way into it on their own:
https://github.com/sparcopen/open-research-doathon/blob/master/wikidata_for_newbies.md .

In T151770#2922253, @Tgr wrote:

Maybe "Due to a browser bug users on Firefox 50 might occasionally get logged out or fail to save their edits. Workaround: enter about:config in the address bar and set network.cookie.maxPerHost to 5000."

That workaround does not work for me - my about:config (FF 50.1.0) does not seem to have anything named "network.cookie.maxPerHost" (though searching for "network.cookie" brings about a number of similarly named variables).

Just want to say that this error affects me too. Yes, there are some workarounds, but using them too often is a nuisance.

Here's a list of the longest pages:
https://www.wikidata.org/wiki/Special:LongPages

I have tried using ProveIt a few times, but it never fit with my workflows, so thanks for working on its usability.

Still does not work for me under Firefox 48.0.1 on OSX .

In T144707#2621758, @Catrope wrote:

As Stephane said, this appears to be because we use capped notification counts inconsistently, and also don't use messages that understand that "100" means "99+" in these places.

Another indication that at least the numbers for Wikidata total and for Q229883 are wrong: the first hasn't changed since I posted this ticket, while the second has gone down, despite new notifications for it coming in by the second.

Adding hashtags as a URL parameter would also be useful for campaigns involving projects other than Wikipedia - I'm particularly interested in Wikidata, where most edits are done in a way that does not allow users to add hashtags to the edit summaries.

The recent UI changes are an improvement from the perspective of this ticket, but the displayed numbers may be incorrect, as per https://phabricator.wikimedia.org/T144707 .

I just checked again and think string data types like P2093 in my example are still not supported.

As far as I can tell, this actually works now.

Yes, showing just the Q number is not very useful in most cases - it would be good to add label and perhaps description if these are available in the relevant language.

The problem seems to have been solved for this particular image, as per https://commons.wikimedia.org/w/index.php?title=Commons:Graphics_village_pump&oldid=192590809 . I do not know what this means for this bug thread.

@Aklapper I do not understand what the problem is, so cannot add any further information at this point. If "Wikimedia-SVG-rendering" is not the proper way to classify this problem, then please add something more relevant.

I just got this at https://commons.wikimedia.org/w/index.php?title=File:Error-threshold.svg&action=edit&undoafter=165826243&undo=166417493 when trying to deal with https://phabricator.wikimedia.org/T128464 .

In T99046#1765313, @DarTar wrote:

They are not part of the DOI AFAIK, @Afandian @Daniel_Mietchen?

In terms of test cases, I suggest to use the same sets of articles as in
https://www.wikidata.org/wiki/Wikidata:WikiProject_Source_MetaData/Source,_M.D./Tests#Test_case:_Malaria .

I shall be there.