I don’t think implementing TermIndex itself, as the linked change currently does, is a good idea. It’s not a great interface (combining lookup, search and modification), and for the new term store in Wikibase we did not write a new implementation of it, but instead implementations of several different interfaces – so I would be wary of any code that really needs a TermIndex (because that would likely be broken on Wikidata already as we migrate away from wb_terms). I think what you need to implement for WikibaseMediaInfo Lua support is PrefetchingTermLookup – implementing TermIndex gets you that (via BufferingTermLookup), but it would be better to do it directly.

I just discovered that in API requests (wbsetclaim, wbeditentity, etc.), the type is not, as I had assumed, optional – if you omit it, you’ll get some sort of error (though it seems to vary depending on situation – I’ve seen invalid-claim error responses as well as Deserializers\Exceptions\MissingTypeException uncaught exceptions). So an additional acceptance criterion should be that the type is no longer required there. (This part is not a breaking change, so it could be done sooner.)

An example file on real Commons, with a monolingual text qualifier: https://commons.wikimedia.org/wiki/File:CSD_Berlin_2019_-_Lucas_Werkmeister_-_33_%E2%80%93_Pride_Is_A_Protest.jpg. (I’m sorry.)

Alright, done: T229069: Don’t use heading elements (<h4>) in Wikibase diffs for coordinates and quantities

I don’t think Wikibase should follow the double redirect – that would go against longstanding Wikipedia tradition, and I don’t think Wikibase supports it for items either. Handle the error gracefully and move on, IMHO.

Yup, double PATH was due to not deleting the output file, thanks. (P8783 is a fixed version.) The extra directory is not the SGE_JOB_SPOOL_DIR (that’s somewhere in /var/spool/, though it ends with the same number), but it’s the same as TMP and TMPDIR.

This is the output file of the following command:

If it’s due to /etc/profile, then bypassing the shell might do the trick? I copied /usr/bin/jsub into my home directory and patched it to pass through qsub’s -shell option (P8781), and the results were… well…

According to its package.json, it uses its own lingua-recorder library, which has a browser compatiblity section in the README.

I was thinking of a pipeline like this:

I was able to log in with Firefox 67.0.4. I can check tonight which Firefox version I used to sign up yesterday. (Edit: it was Firefox 68.0b8.)

I just noticed that coordinate values still use h4 (example link). Quantity values, too, according to a code search (didn’t see that “in the wild” yet). Should I open another task for those or do we reopen this one?

Ah, those 107 pages are redirects :) if you filter redirects from the results, there’s nothing left to be done (Quarry 1, Quarry 2).

Okay, the Python script finished, and now there are only 107 lexemes without the page props left (Quarry 1, Quarry 2). Not sure why those few are still missing the page props… should I run the script again and see if that helps?

Perhaps you could also switch the sshd config to AuthorizedKeysFile and rebuild that file from the AuthorizedKeysCommand via a cronjob or similar? That would also let you test if it’s really the AuthorizedKeysCommand problem, without requiring a package rebuild. (Of course, it’s not a good permanent solution, since key changes wouldn’t become effective until the next file rebuild.)

The PAWS terminal died for some reason (I guess you can’t leave them running in the background?), so now I’m doing it with a separate Python script from a Kubernetes deployment. Source code is on GitHub; I can’t push it to Phabricator yet due to T224677.

I’m now running this on PAWS:

I looked into this a bit – a regular purge doesn’t refresh the page props, but apparently a link-update purge does. This is available via the API – for example, I just fixed the page props for L31883 with action=purge&titles=Lexeme:L31883&forcelinkupdate=1. So I think anyone could actually do this task :)

Why is this task still open? This was implemented, wasn’t it? (I just noticed that I don’t have to add SELECT NOW() AS as of`;` to my queries anymore ☺)

Note that the majority of pages are still missing these page props (see T199611, esp. T199611#5244691), so right now we wouldn’t have any data to show for those.

According to this Quarry query, almost 70% of all lexeme pages still don’t have this page prop. Is there really no way to populate it without an edit? As a tool author, I can’t really rely on it like this… (example)

Note that, for WikibaseLexeme entities, these numbers include the statements on senses and forms as well – i. e. they count all the statements/identifiers on the page, not just those of its “main entity”. Also see T224844 for a similar WikibaseLexeme task.

I’m not sure if it’s related to this task, but a while ago I wrote changeslist-notify.js, a user script to turn new changes on RecentChanges or Watchlist into desktop notifications. Perhaps it’s useful to some of the people subscribed here.

Seems to be working now \o/ see this patrol log for some examples.

See T194767: Set up OpenRefine on Cloud VPS.

I don’t remember seeing it in other repos – I think I just added the tag assuming that it wouldn’t be restricted to OAuth if it looked like a CirrusSearch failure. Sorry for the confusion.