@Etonkovidova I misunderstood the ask and thought we wanted to convert all warnings to notice style.
Above patch should change warnings back to their original style, and re-introduce "notices" for "we recommend providing a full date if it is known" (date) and "we recommend keeping the number of items to a maximum of x" (depicts/statements)

Update: at some point, the plan was to show an error message listing all fields that had wrong input. This has since been revised, and scrolling back up to the first error is the preferred option. I have updated the description to reflect that.

@Etonkovidova Captions remain required if "same as captions" has been unchecked. Only when they uncheck "same as captions" (and fill out a description) do they become optional.

For #1 - I think the implementation is correct - at least AFAICT.
The color looks to be correct: Figma has it as #54595D (which was later once more confirmed in Slack), and that's also what it is on beta.
The font size for both the title and the "optional" label and up being 14px, making them equally large. It does indeed look a bit off in your screenshot, though. It looks like they have different units (title = 14px vs optional = vector's default calc(1em * 0.875)), so that might cause differences depending on skin/browser settings. On Minerva, in my browser, the title is actually smaller then the "optional", and the rest of the text.
I'll remove the explicit 14px for the title, so they get the same defaults.

Those (and many more) messages are the result of an upload being rejected because the title violates the TitleBlacklist.
TitleBlacklist is a separate extension used to prevent spam and otherwise bad pages from being created on all wikis - it lets admins define patterns, and if a page name matches it, it'll be rejected.

I think this can be closed - this work was done as part of T355248. All that remains is T358593 (removing the community's gadget)

@Sannita The on-wiki CSS overrides for UW should no longer be necessary: most of them have been incorporated into UW itself, while some of it has been solved in a different way (see T355248)
Keeping the CSS overrides up is not only no longer necessary, it can be harmful, because it may prevent us from accurately reproducing how things look in production (this has actually happened before, and what prompted us to actually incorporate these CSS into the extension)
Can you work with an admin to get these (https://commons.wikimedia.org/wiki/MediaWiki:Gadget-uploadWizardMobile.css) removed, or should I gain access & do it myself?

In T355715#9666968, @Etonkovidova wrote:

(2) Uploads with mixed (Flickr and other files) silently fail to display flickr images. I suspect that the issue has been present for a long time. The gif below shows

• three uploaded files - a file from flickr and two files from a hard drive
• going to the next step - Release rights, the flickr image fails to be displayed.

@Etonkovidova I think that's a beta-specific issue (T249486, I think). This just got deployed in prod, where uploads from Flickr seem to work AFAICT!

As mentioned in the description already, mw.UploadWizardDetails.js already submits structured data (the caption) from the "details" step.
It does still first submit the file & wikitext (there's no getting around that - the file first needs to be uploaded before we can submit structured data, which needs the file's page id), but then submits the caption(s) immediately after, before proceeding to the next step.
See mw.UploadWizardDetails.js's submit method:

@Etonkovidova The arrows look off, but that's caused by the on-wiki overrides. I removed those (T358593 to do this in prod), and things look better now:

Yes, I did indeed!

I have made a couple of changes to the new copy:

Thanks for catching that missing one, @Etonkovidova - will be fixed shortly!

That was intentional. The current (on-wiki CSS, with most of the markup removed) steps are terrible: they are just a bunch of words.
People who are not familiar with these steps on desktop, would not know what this represents, and would either have no clue what this even is, or likely mistake them for links.

The patch that fixes #1 is still in CR, but should be fixed once that is merged.

AFAICT, the behavior described here matches current implementation.

Input field & button height misalignment has been fixed.

Updated description with results.

Both similarly feasible, but I have a preference for #2 (mostly due to not being a big fan of autoscrolling)

This request seems sensible, but appears to conflict with how templates are documented to be used.
E.g. https://commons.wikimedia.org/wiki/Template:Self seems to conflict with this request.
They seem to instruct to use the |attribution= param only when it is different from “Author” (which in turn is instructed not to be used unless author differs from uploader)

I think the log line will still exist and render just fine (except that that human-readable tag name will no longer be there), but would need to doublecheck.

I think that, once the extension is removed (and there no longer is code that recognizes how to handle this notification type), those notifications will no longer be shown.
Notifications also don't grow infinitely; when a user has too many, older ones get purged at some point; so it doesn't *really* need to be cleaned up either.

Let's make sure to check why this template was added in the first place, and that removing/changing that doesn't unexpectedly break something else.

In T353683#9444888, @Cparle wrote:

Don't remember for sure, but it seems unlikely that we excluded it on purpose. @matthiasmullie do you remember? Shouldn't be a huge deal to add it anyway

Yes, I still run Vagrant on Apple Silicon through Parallels Desktop (€99.99/yr)

FYI; this revert also solved T353849