Software developer on the Wikidata team at Wikimedia Germany. Private account: @LucasWerkmeister.
Fri, May 29
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.
Thu, May 28
I’ll pick the readonly part, since it seems relatively easy to grep for that.
Apparently the screenshot looks like this:
Video is here (it doesn’t play in my Firefox but works in VLC after downloading).
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:
Wed, May 27
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).
Tue, May 26
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?
Mon, May 25
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.)
Wed, May 20
Then I think this is done!
Changes are merged, I guess we still need to actually create the graph?
Tue, May 19
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:
Mon, May 18
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 P21 one on Wikidata, so if you try to add “sex or gender” (here, P963) with an invalid value (e. g. Q6) 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.
Fri, May 15
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.