It is used, but with the deployment branch, not the master branch: https://gerrit.wikimedia.org/r/plugins/gitiles/wikidata/query/gui-deploy/+log/production

Should’ve claimed this and moved it to Doing a few hours ago, sorry. But here it is.

I think this can be closed now, we’ve made a lot of improvements here.

Seems to be working on Beta, including in IE11.

I’ll pick the readonly part, since it seems relatively easy to grep for that.

Apparently the screenshot looks like this:

Both of the above changes got +2ed, so unassigning myself and moving back to TODO. (I think there’s still a few page objects to be extracted, though we’re probably getting diminishing returns already.)

• the Omit helper type: Omit<TypeName, "memberName">; I think I introduced a duplicate of that in MwApiParameters, something like MwApiParamsWithout?

Regarding assertion signatures, I left them out of my list because I didn’t remember any assertion functions we had, and so I thought the ability to correctly type them wasn’t very important. But maybe we want to refactor some of our current type checking functions (returning x is Type), when they are called only to throw an error if they don’t match, into assertion funtions?

Thanks! I spotted additionally:

The user interface and the API show you the original date value and its calendar model, which in this case is the Julian calendar. The RDF export, on the other hand, always converts dates to the proleptic Gregorian calendar (source). I assume that’s the cause for this apparent discrepancy (two days sounds roughly in the right ballpark for a date some half a century after Caesar’s death).

The code throwing the exception:

I think the notable changes are:

in the wdqs gui the search ultimately happens here https://github.com/wikimedia/wikidata-query-gui/blob/b49263487713775140201c8adb7bc3fcf1c67fd8/wikibase/queryService/api/Wikibase.js#L81-L97 right now always hardcoded to wikidata.org

(We should probably also have tests for this, if we don’t have them already.)

This is probably a Blazegraph thing, not sure how much influence we have over it. But I disagree that it should be fixed – FILTER(?dateOfDeath >= "2020-01-01"^^xsd:dateTime) is much more convenient to write, and in my opinion also more legible, than FILTER(?dateOfDeath >= "2020-01-01T00:00:00"^^xsd:dateTime).

The test cases linked in the task description work again, and this bug is/was severe enough that if it still happened, I’m sure we would’ve heard of it. That’s good enough for me, at least.

Thanks Michael, that all sounds right to me. I uploaded the partial patch above, though without the upstream change it doesn’t reduce the dist/ size at all.

Also, we still need the “Data Bridge” tag to be created on Wikidata. I guess one of us (Léa) should ask on WD:AN?

In T232584#6163607, @Lydia_Pintscher wrote:

In T232584#6161922, @Lucas_Werkmeister_WMDE wrote:

@Lydia_Pintscher: my second config change above also enables the feature for Wikidata itself. Does that make sense or should Wikidata wait until later? (Technically, I think it would be possible to enable the repo-only parts, which cawiki needs to function, from the client parts, but I don’t know if that makes much sense.)

Only allowing it on Catalan would be best but if it's a significant amount of effort to make that happen then I'd say we can live with it.

See also this AC/DC commit, where I excluded the Promise polyfill in a plain webpack project. Hopefully it’s not a lot more complicated in conjunction with vue-cli-service.

@Lydia_Pintscher: my second config change above also enables the feature for Wikidata itself. Does that make sense or should Wikidata wait until later? (Technically, I think it would be possible to enable the repo-only parts, which cawiki needs to function, from the client parts, but I don’t know if that makes much sense.)

Then I think this is done!

Changes are merged, I guess we still need to actually create the graph?

Verified in a Win10 VM that Data Bridge is usable now.

The only way we’ve found so far is to go to the item in the second tab and completely remove the statement that’s being edited in the first tab. (See also T252433, especially the “problem” section.)

Ugh. Quoting myself from the commit message:

No further reports in almost a week, let’s close this I guess. (If anyone sees it feel free to reopen, or create a new task.)

Second Gerrit change is still open…

Should be possible to verify on Beta now; I’ve set up an AbuseFilter on Beta that mirrors the P​21 one on Wikidata, so if you try to add “sex or gender” (here, P​963) with an invalid value (e. g. Q​6) to an item, you should get an error, and see the detail in the error message.

Note that there’s no train this week (releng offsite, apparently), so this would remain unfixed until next Wednesday/Thursday.

No new occurrences, seems to be fixed indeed.

Backport deployed. In the past 24 hours, Logstash has mostly had a handful of occurrences of this per hour (from group0 and group1); I’ll check later if those are gone now.

This was deployed last week and is working now (example).

T252800: Regression: Option add links in other languages has disappeared seems to be the same issue, and given that that task already has Gerrit changes attached, let’s merge this one into that one, though this one was created earlier.

Backport scheduled for Monday’s EU SWAT. Lowering priority since I don’t think this needs any further action at the moment.