This is a duplicate of the second bullet point in T168655: Query service UI editor placeholder is not translated, I believe.

You mean, for any triple? It would work, but IMHO that’s uglier :)

The task description is a bit confusing :) on its own, <number> is equivalent to "number"^^xsd:integer, both according to the spec (SPARQL 1.1 Query Language, § 4.1.2) and according to experiment (query). However, BlazeGraph fails to parse an integer literal immediately followed by a (triple-terminating) period, attempting to parse it as a decimal or double literal instead. I’m not sure if this is allowed by the spec or not, but I suppose it doesn’t matter that much.

I haven’t looked into this in too much detail, but I suspect we can use jQuery.extend instead of Object.assign here and in T206644: Lexeme forms can't be added in IE11.

I would clarify the requirements to “SPARQL support, including SPARQL Update”. For example, Sage boasts stable response times and general responsiveness, which would be useful for us, but its backing store is HDT, a read-only RDF serialization format: since HDT files cannot be efficiently updated, Sage is read-only, so we can’t use it for a live-updating query service.

Why does the whole entity need to be loaded? The requested violations are stored elsewhere no? Why would you need anything beyond the GUID of the Statement?

Hm, this isn’t working yet on Wikidata (test and real) even though it’s deployed on both as far as I can tell :/

It’s certainly supposed to be tested, see tests/phpunit/ServicesTest.php.

WikibaseLexeme doesn’t have any special features for usage examples, but they can be stored as regular statements, e. g. using the usage example property.

Yes, and it should be on test.wikidata.org by tonight, as far as I understand.

See T205560: Add option to disable Wikibase’ custom search box for @Yurik’s feature request. (This task is much more general, if I understand correctly.)

An alternative approach would be to listen for change events instead of for input events: change only fires when the change “is committed by the user”, e. g. when the input field loses focus. But I have no idea if that’s possible to do with Vue.js.

I’m not aware of one, but we could probably set up WikibaseLexeme on the wikidata-constraints system. @Jonas do you want to try? :)

One option would be to treat all invalid language codes as und (“undetermined”).

To the user, this should not result in a violation report. STATUS_TODO is probably a good status to return in that case.

This might be coming from a misbehaving gadget, lua module, etc. on a client wiki, which might try to do something like this:

When an invalid language code is requested some other default formatting will be used. << @Lydia_Pintscher to decide this.

It seems like this could be due to current JavaScript being incompatible with old, cached HTML. A simple way to fix that would be to purge all caches and drop all the old, cached HTML (e. g. increment the cache epoch); we should check with Ops if that’s acceptable or if we need a cleverer solution.

So Q29201051 is no longer a test item since I edited it to test something: proceeding to add a statement, with a different property, will succeed; the statement will initially be in the wrong statement group, but after a page reload it will look as normal.

Since purging doesn’t fix it, UBN per @Lydia_Pintscher.

I can also confirm that checking random items shows the bug fairly frequently (though it feels like less than 1 in 3 to me, but I haven’t counted), so raising priority for now.

I’m able to reproduce this on Q29201051, thank you. It happens on any of the existing statements.

Wikidata moved from 1.32.0-wmf.20 to 1.32.0-wmf.22 on September 19th, sounds like it could be a bug in that window. But I’m not seeing anything especially suspicious in the git log.

In T141859#4595822, @Lydia_Pintscher wrote:

Is there a place already where I can see it working?

I uploaded I7e91dd84ed to fix the Cognate issue I mentioned in T196053#4272028, and apart from that I think this is done, yes.

At least one place where we need to get the entity ID from the statement ID is WikibaseQualityConstraints: in the wbcheckconstraints API, you can ask for all constraint violations of a statement, but for that we still need to load the full entity to which that statement belongs.

At least for the request @Krinkle quoted, the problem does appear to be the precision. Quoting from Special:EntityData/Q3629997.json:

Wikibase composer.json could suggest that the PHP extension be installed?

Do we still need to keep this task open? Senses are entities now, but not really sub-entities if I understand correctly.

Done as part of T199206: Add wbleditsenseelements API action (first checkbox in task description).

Done months ago (without HierarchicalEntityId, but the LexemeSubEntityId class introduced later is vaguely similar (though lexeme-specific)).

WikibaseLexeme has been deployed on Wikidata for several months now and is using vue.js as far as I’m aware. Is there anything left to track or can we close this task?

Yes, it hasn’t been done yet. There are some patches on Gerrit for my old ConstraintCheckPlan idea, but I’m not sure if that’s the best approach, and the patches themselves are probably stale beyond saving by now.

• NewItem+NewStatement: T204704: Get rid of JsonFileEntityLookup in WikibaseQualityConstraints tests
• Arrange-Act-Assert: generally done for new tests and when existing tests are updated for other reasons, but not worth touching existing tests for by itself
• helper methods: done (ConstraintParameters trait)