Thu, Apr 18
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.
Wed, Apr 17
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.
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:
Tue, Apr 16
@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.
Mon, Apr 15
@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?)
Fri, Apr 12
Thu, Apr 11
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)
Wed, Apr 10
Tue, Apr 9
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
Mon, Apr 8
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?