Well, PagePile Visual Filter exists and is ready for use, so I suppose we can close this task.

I’d have to explicitly remove all the statements in wbeditentity.

My motivation for this is that I’m trying to write browser tests for the AC/DC gadget, for which I need a way to reset an entity to a known good state before I start editing it. As far as I can tell, there’s currently no good way to do that – I can’t find a “restore” in the API, and without the clear parameter, I’d have to explicitly remove all the statements in wbeditentity.

Firefox, probably 70, I can check the exact version when I’m home.

LOL, thanks :)

I’ve looked into this a little bit. As far as I can tell, it should work in principle – PHP sets the status field in the database to STOP, and Rust only selects batches with certain statuses, not including STOP.

In T231916#5464877, @Magnus wrote:

Actually, that bitbucket repo is for the _really old version_ (pre-1.0).
The repo for V2 (at https://tools.wmflabs.org/quickstatements/ ) is here: https://phabricator.wikimedia.org/source/tool-quickstatements/
Which makes phabricator the place to be.

Can confirm that this is fixed in 1.34.0-wmf.22, currently live on Wikimedia Commons.

I’ve also seen similar problems when editing a page with VisualEditor (without reloading it after save), though I can’t seem to reproduce it right now.

Minimum viable product

• Import from various sources
  • All sources offered in PagePile
• Export to various places
  • All consumers offered in PagePile

That said, only ~3½% of piles are that large:

Moreover pagepiles are static -- which means that they only output at one point, but the options for updating it mean you have to "regenerate" the list as a new output, even if its just an extension of the previous list (there is not "list history" so to speak -- instead each pile is a separate independent object). This means that "list owners" can't lean on these lists too update multiple other locations -- instead you have to recreate the list and manually update its use elsewhere. This kind of application is partially being solve by tools like Listeria, but that is entirely dependent on the Wikidata Query Service, but that only includes a subset of the criteria that you might use to form a list (with a tools like PattyPan, Quarry or Manual work).

At least for statements, this issue is still present – I just got a bunch of new watchlist entries from some AC/DC edits.

It’s mostly working well now, but it’s a bit odd that the whole StatementWidget is grayed out even though the supported parts are still functional (mark/unmark as prominent, edit qualifiers, remove).

I don’t think implementing TermIndex itself, as I51bc8c9703 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.)