Here’s a screen recording of this happening to a real user (affected by an IP block due to using a VPN), to give an impression of just how fast the error message vanishes: https://twitter.com/leli_gibts_scho/status/1199843097431171072

In T238908#5685414, @LucasWerkmeister wrote:

In T238908#5685165, @Harmonia_Amanda wrote:

Can you add this tool on the official list of tools you can open a PagePile with? For example: https://tools.wmflabs.org/pagepile/api.php?action=get_data&id=27097 you have a button "Use this pagepile in [list of tools]".

https://bitbucket.org/magnusmanske/pagepile/pull-requests/9/add-minefield-as-consumer/diff

In T238908#5685165, @Harmonia_Amanda wrote:

Can you add this tool on the official list of tools you can open a PagePile with? For example: https://tools.wmflabs.org/pagepile/api.php?action=get_data&id=27097 you have a button "Use this pagepile in [list of tools]".

Yeah, seems to be working now. Thanks!

My best idea so far is to make the SPARQL query concatenate all the image titles, separated by pipe characters –

As far as I can see, the CommonsMetadata extension hasn’t had any significant changes in a while, so this might be due to some change in its input (I’m not sure if it ingests wikitext or parser output HTML, actually). @Jarekt’s Lua version of Template:Information sounds like a potential candidate, though that’s just a guess at this point.

Do you need a beta tester?

In T230833#5654878, @LucasWerkmeister wrote:

In general, I suspect the language of the match is the Wikimedia language code of the language item, not the language code of the lemma matched. You can also see this when searching for “colour” – the match language is en (or, for the Middle English version, und) rather than en-gb (or mis).

In general, I suspect the language of the match is the Wikimedia language code of the language item, not the language code of the lemma matched. You can also see this when searching for “colour” – the match language is en (or, for the Middle English version, und) rather than en-gb (or mis).

I think this is also affecting real Wikidata (though I’m not completely sure it’s the same issue). Searching for “das” with language code ku (Kurdish) returns L221811 and L221957, but with language code und instead of ku. This might be because the language item used for the lexemes is Kurmanji, not Kurdish languages – only the latter has a Wikimedia language code statement. (The difference between the two still isn’t quite clear to me – perhaps we should have used the more general item after all. This was discussed (in German) here.)

No VPN, no data saver settings as far as I’m aware.

From a technical perspective, I wonder what distinguishes edit groups from tags? We already have an API function to create tags (managetags, guarded by the managechangetags right), API functions to view edits / log actions with a certain tag, and a tags parameter on most actions that create new revisions or log entries (not yet complete, see T155109).

It doesn’t seem to be a cache problem – I still get the 502 Bad Gateway even when adding ?foo=bar to the URL.

(But apart from that, I don’t see why this wouldn’t work.)

You can probably remove the if around L18 – logname should always return something, so it’s probably safer to inject it into the message unconditionally.

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 Developer Edition 70.0b5 (64-bit) on Arch Linux.

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 to run, 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.