This ticket is just for the most basic "support": making sure other statements don't break things and can be deleted.
This will already be in production, so we can deal with vandalism from manually crafted API calls to submit other statements.

Okay, this seems to have worked: FlickreviewR 2 got its edit in, and captions kept submitting.

Actually, the more captions are added, the longer submitting all of them (sequentially) will take, and the better the odds of the bot making its edit.
We should try an upload with 10 or so captions, and we can validate whether the bot edited in time by examining the file's history.
Let's see... :)

Yeah, it's pretty hard to test as it depends on the timing of a couple of things...
As we're unable to reproduce this now, I suggest we resolve this ticket. If the problem reappears, we can reopen or file a new ticket.
Sounds good?

Actually, maybe even better than an error message (if we can't get it to work at all) would be to sniff out IE11 and just not load the JS widget. Things will then just be read-only.

Works on beta!

Works on beta & test-commons!

@PDrouin-WMF might have ideas on how to fix some of these things.

Below is an example call for adding a claim with 'globecoordinate' datatype:

There's other tickets (T220613 & T220614) for unsupported data types, so I'll move this one to "Verify on production".

@Ramsey-WMF level of effort depends on exactly what we want do do (the devil is in the details), but should be small, <1d.

Current status: MediaInfo content is included in other wikis.
E.g. https://en.wikipedia.org/wiki/File:2019-01-13_Commons_Structured_data_captions.png has unstyled (because MediaInfo is not installed on enwiki) captions that it got from Commons.
I've submitted T221071: We don't want MediaInfo content to show up on wikis sharing Commons files to hide MediaInfo content from other wikis for now (because it looks terrible), which is probably the easiest solution right now.

@PDrouin-WMF or @Ramsey-WMF might have a good idea for how to indicate that statements are being submitted.

@Ramsey-WMF: this ticket was pulled in from a later milestone to improve how we deal with T219381.
I'm not sure if you've had the time to review exactly how this is supposed to work and if you're ok with this, so can you verify the acceptance criteria?
TL;DR: non-depicts statements are going to look & behave exactly like depicts, minus the depicts-specific title, and they'll be greyed out.

@Ramsey: this one wasn't really fleshed out. I updated the original description to add more detail & acceptance criteria based on earlier conversations, and on what I felt makes sense. Can you please verify these acceptance criteria ok are?
If yes: this has already been merged and is currently on beta - please re-assign to Edward!

Tried it on beta (with link provided by @Ramsey - thanks) and HTML is now displayed.

Do we really need to clutter the upload interface even more? There's so much information, help text, legal text, ... on this step already.
As a user, I probably wouldn't even read it: information overload/blindness... And now the license text no longer stands out, so I'd probably skip it too.
Furthermore, I feel like "initiate the upload process" is very vague, and doesn't make it clear that the file is going to be published immediately (which is the point of adding this message, right?)

@Aklapper it's not. It looks like T220651 got fixed last night, while this only started then. Responded on that ticket.

Yes, a couple of changes to UploadWizard were deployed yesterday.
I'm not sure exactly what your problem was, or what fixed it, though - I suspect https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UploadWizard/+/501188 has fixed your issue, but I'm confused at why it was different in different browsers.
Anyway, glad to hear it's been resolved now!
I'll close this ticket - should you continue to encounter this issue, feel free to reopen!

The "caption is not saved and no error is shown" thing is T220665 - I'll ignore this submission failure here.

I can no longer reproduce this, but I believe this is related to https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/500006.
I can prepare a quick little something to fix this if it persists, but I think it's just browser cache, which should refresh soon (or try a hard refresh or clearing your browser cache)

As discussed yesterday, we're going to distinguish them visually (#2) AND apply the JS widget to make it easy to edit/delete vandalism.

I'm going to move this out of QA: the label having a different name than in the original acceptance criteria is ok, that changed because of T219945

So basically, our options in screenshots, for how to deal with other statements should user manage to sneak them in by crafting their own API calls to create them:

Agreed that #2 is the best option, and we can make that work. I guess we could lower the opacity of non-depicts statement blocks to indicate the difference?