Thanks for the progress so far. I'd like to see the tool expanded to cover usage of Wikidata outside namespace 0 (including on Wikidata itself) and in SPARQL queries/ API calls.

Ideally, clicking that button would translate into something SPARQLable attached to that statement, e.g. a reference of the kind "within focus list" (P5008) "WikiProject Citation needed". See also citation needed constraint (Q54554025), which works on basically any statement involving a property, rather than a specific statement.

Thanks!

I just got French text on https://www.wikidata.org/wiki/Q1035 (with language set to English) but a purge fixed it.

Thanks. This is a known issue (cf. https://github.com/fnielsen/scholia/issues/53 and https://github.com/fnielsen/scholia/issues/189 ) for which we have not found a good solution yet - see discussion at https://github.com/fnielsen/scholia/issues/301 .

Thanks all!

The problem seems to affect graphs in general, not just the two types mentioned above. Other examples are the Co-author graph and Academic tree graphs in author profiles, e.g. https://tools.wmflabs.org/scholia/author/Q8219 .

@WMDE-leszek Can you provide some more details on why this is to be phased out?

Thanks for working on this, @Addshore . Looking forward to see this resolved - had to cancel a demo of it due to the spam interfering.

Still hundreds of spam pages at https://wikibase-registry.wmflabs.org/wiki/Special:AllPages , and I don't see how to get rid of them at scale.

So far, spam seems to go exclusively to the main namespace, so perhaps it's worth restricting edits there to autoconfirmed users.

@Addshore My example is from Commons (see main page), but in case we allow local uploads (not sure about that right now), it would certainly be nice to be able to display these properly as well.

This now exists at https://phabricator.wikimedia.org/project/view/3356/ .

Another aspect of this would be to consider ShEx for selecting the data to be migrated. More info via https://phabricator.wikimedia.org/T192884 .

This would include considerations about

This sounds like something for ShEx: https://www.wikidata.org/wiki/Wikidata:WikiProject_ShEx .

This could also include tokens or API keys or things like that for the associated MediaWiki APIs or the respective SPARQL endpoints

@Magnus seems to be working on this: https://twitter.com/MagnusManske/status/986260652237967360

e.g. how to change the logo, license or user rights in a new Wikibase/ WDQS installation.

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.