The depicts work was covered in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikibaseMediaInfo/+/504225/ the captions work is not complete.

Assigning to @matthiasmullie since he wrote the patch to wb we are waiting on.

Blocked by https://gerrit.wikimedia.org/r/506123 (Requires wikibase team to merge)

thanks @Jdforrester-WMF --- I agree, things look correct on production

I see the correct i18n values on the master branch now. Not clear on what would be the difference between this code and production at this point - @Jdforrester-WMF could you shed some light? I didn't change the key name so maybe cached lang value is appearing? Let me know how to fix.

Tested on test-commons- works there as well. @matthiasmullie your instructions were what I needed i was formatting the datavalue wrong

@PDrouin-WMF Can we considered this finished and close/resolve this ticket?

@PDrouin-WMF do you think we could close/resolve this ticket now?

This looks correct on beta and depicts is not on for UploadWizard on test-commons yet. Moving to 'Verify on Production'.

This seems to be working fine on beta, @matthiasmullie I couldn't figure out how to test on test-commons though - couldn't get the wbsetclaim correct in the Api Sandbox. What is an example claim JSON I should submit to get into this state on some file in test commons?

This is merged now but seems like we can't really verify/qa till this ships to prod

This is working properly now on Beta again.

Seem blocked by failures due to T221111

Seem blocked by failures due to T221111

nice --good move on making this!

@PDrouin-WMF Moved this into "verify on production" column - when something passes QA feel free to move it along

I've QA'ed this on test commons and it looks good, I see icons.

Still working on this best solution this that doesn't effect i18n support. Re-assigning to reflect who is working on it now and moving back to in progress.

@Ramsey-WMF Uh oh. You are right. The work I completed for that ticket was to make sure we prompt for discarding changes from hitting 'cancel' button. I must have misinterpreted the ticket or our conversation. You can see that in the work and I did and my questions about the text. The issue described in that ticket was never occurring for me locally at at that time (or James either it looks like) and the default browser alert was opening fine.

For posterity: this bug was regression caused by T219197 which had recently merged. We luckily noticed it on beta before it got any further.

Another update from design.

@matthiasmullie Thanks for calling this out.

Sounds good!
So remaining work is to adjust the trash can. I've updated the description to reflect this.

Hey! Several of these changes we got for free with the recent CSS design refactor. That work will be visible on mobile production once any of T216773, T216772, or T218707 moves to the verify column.

Is this ticket complete? seems like it could be closed.

Done! thanks

So that warning is the browser default when you unload a window - actual implementation will just use a simple alert. We aren't navigating away from the main file page (which is why that other alert rightly does not trigger), we are discarding changes to form inputs and re-rendering dynamically in place.

^ simply blocked till CSS refactor merges

Updates screenshots including work from T216773 (and in person design-dev pairing). @PDrouin-WMF

@PDrouin-WMF I'm going to now combine my work onto this patchset as well - I will upload new images later today that also reflect the changes I made together with Eric's.