If you want to count pages, then you are only looking at the current revision, right? And the current revision of a page is by definition never deleted/suppressed. So no need to check rev_deleted.

Whoops. I hadn't realized this was blocked on me! Thanks for the ping, @Krinkle & @Ramsey-WMF.

@Milimetric it wasn't being used to omit deleted pages (see inline comments about archive table), but to also exclude those RevDel'ed revisions.
I was thinking it made sense to exclude rev-deleted revisions: if a page only has (SDC) revisions that are partly restricted for most people, that we might not want to count those.
But one could argue that we should include them, and I'm happy to exclude that condition from the query! (though the number is likely extremely low, too low to even matter)

Current status: wbsetclaim fail silently, and (silently) restore the UI to the state it loaded with, in read mode.
IMO, when a change fails to submit, the widget should probably remain in edit mode, with (invalid) input untouched, and an error message.

Working on related: T239475: Validate input and inform the user about violations

I've split up this task. This ticket is not solely about enabling statement-level support for quantities.
I've split off the units-related work into T239474

I don't really know much about how mediawiki_history gets populated, but wbcreateclaim & wbeditentity (in addition to wbsetclaim) could also be used to create (or edit) statements IIRC, so this last set of results is likely incomplete.

As far as I can tell:
@mpopov's queries (wbc_entity_usage based) include both MediaInfo items, along with Wikidata-items pulled in via Lua.
@Addshore's queries are stricktly the amount of MediaInfo items.

In T181062#5683735, @Spinster wrote:

Can my colleagues from the StructuredDataOnCommons team do anything to make it easier to include filename-to-Mid conversion in QuickStatements?

In T226093#5657414, @Ramsey-WMF wrote:

Matthias will look into discrepancies between number of files with mediainfo slots vs. what's indexed in Cirrus.

federated-commons.wikidata-federation.eqiad.wmflabs & federated-wikidata.wikidata-federation.eqiad.wmflabs have been deleted

Patch has been updated:

@Cparle also no longer needs them.
I suspect no-one else needs these anymore, but speak up if you do! I'll wait another week before removing them.

federated-commons and federated-wikidata can be probably removed.
There's one more instance on there that is still being used (not on Jessie, though): sdc-test-runner - this one should stay.

Rate limits have been increased for registered & confirmed users.

We have been using it in the past - unsure if we plan to use it anymore - let me ask around

Currently being used in production: https://commons.wikimedia.org/w/index.php?title=File%3AJodrell_Bank_Mark_II_5.jpg&type=revision&diff=371864746&oldid=149735587
Closing this one - let's open other more specific tickets for additional work (T236691, T236692) or issues once they arise.

Same as with T236372, these happened at the exact time these changes were being scapped, and stopped immediately after: https://logstash.wikimedia.org/goto/cfd3017e60a6be127c9673fd9ff53536

These all happened at 11:10 UTC, when the change was being deployed. This stopped immediately after: https://logstash.wikimedia.org/goto/39611d534c6b97d76c367f4e4878ab15

I'll doublecheck, but I think these only happened the minute the patches were being scapped, and then stopped.

What other wikis have structured data enabled? 😃

That copy change in the confirmation dialog is a great idea, I'll go make that change.

In T223792#5598472, @WMDE-leszek wrote:

@matthiasmullie repeating myself from the IRC

Mmh - didn't see anything - what channel was that in? (or DM?)

So... @Ramsey-WMF/@PDrouin-WMF: here's a few screenshots of how I've implemented this thus far.
Let me know if we need to change things, or if this is ok as-is & we can move on with code review.

Commons is group 1. Let me know if you'd like me to deploy these patches once merged, or help in any way!

There is no magic involved.
Term lookups are performed differently for different entity types (because the data lives elsewhere), but in a non-hacky fashion (and it doesn't really matter where the data comes from or how it's retrieved anyway)

AFAICT, most operations seem to be working fine.
The one that don't are either:

• irrelevant (e.g. resolvePropertyId - MediaInfo's aren't properties; or getDescription - it works, but MediaInfo's don't tend to have descriptions...)
• use SiteLinkLookup (getEntityIdForTitle and getSitelink) - I'm not even sure we'll need these for MediaInfo's - if we do, we can implement that later on!

Other lookups seem to work just fine!

In T223792#5592264, @WMDE-leszek wrote:

Apologies for being hard to reach recently @matthiasmullie.
I've submitted a change pair https://gerrit.wikimedia.org/r/544972 + https://gerrit.wikimedia.org/r/544973 with a simple proof-of-concept of what would be my idea how to solve this. I am not certain how to verify that all lookup operations are working as expected, so I would appreciate if you could have a look.

In T223792#5563683, @WMDE-leszek wrote:

I should be able to help with it @matthiasmullie . Looking into it...

In T222867#5552682, @Ramsey-WMF wrote:

Heads-up - we're going to start addressing some of these issues soon, but there's a refactoring patch that has to go out first (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikibaseMediaInfo/+/528825/).

Update: while above patches got merged, Lua still won't work by next week's deployment (at least not until some more issues are straightened out, but they may require some more work)

@OlafJanssen It's not immediately clear to me exactly what's going on.
Did the new user start seeing this error message immediately, when the very first thing was being submitted? (in which case this is probably some yet unknown bug)
Or was it only after having already submitted a few things that it showed up? (in which case I suspect the user was rate limited - only a certain amount of edits are allowed in a short period of time for new users)

And unassigning myself - I don't want to claim this. Anyone can pick this up, work on any number of the acceptance criteria, and pass it on.

I've spun this off into multiple tickets - one per "category" - and I'm pulling this first one into "current work".