I was thinking about this some more. Maybe it's a bad idea to actively mess with the list of suggested values. After all it was a user who wrote the list. The fact that certain values are not in the list is probably intentional. If listing the default and/or auto-value is something the user wants they can actively add these to the list of suggested values. And what happens in the opposite case, when a user disagrees with what VE does and wants to remove the default/auto-value from the list, but still keep the default/auto-value in their dedicated documentation slots? This would be impossible.

[…] starting to show the search field at 4 would work well. I'm fine to go ahead with this cut-off.

No further information given. Please feel free to reopen this if you think this should still happen. The requested change itself is easy to do. I just would like to understand what the benefit is.

I think this is mostly a misunderstanding. There is nothing special about what FileImporter does to the source wiki. The file is deleted (technically only marked as deleted, you know) and can be restored as every other deleted file/page. I don't think it makes sense to create some kind of duplicate of [[Special:Undelete]].

Comma works.

I don't see anything actionable here, sorry.

While I understand the idea, I'm afraid the problems this will create are not worth it. Namespace prefixes are already a thing, and already cause issues, see T223694: Misleading namespace input in Advanced Search when searching with a prefix.

This is effectively a duplicate of T223694: Misleading namespace input in Advanced Search when searching with a prefix as well as T210665: Auto-add namespaces if search field fully matches their names.

No other complains for 2 years now. Let's stick to the original decision to trim whitespace in all cases.

Baseline:

• Remove or hide the (x) button.
• Don't display the default sort order as a pill when the form is collapsed. The fact that "no special sort order is selected" will still be communicated simply because there is nothing special to see.
• Change the text in the dropdown to say "Relevance (default)".

To be discussed:

• Should the (x) be shown when the sort order is not the default, and reset it back to the default?

While doing work for the WMDE-Templates-FocusArea we had a closer look at TemplateWizard as well, even did a bunch of smaller code cleanups, but had to deprioritize it in favor of VisualEditor. We didn't manage to pick this up.

I'm curious. Why does SVGO replace smaller files with bigger ones? Isn't the purpose of the tool to make them as small as possible? Maybe the issue is that SVGO compares the uncompressed file size? Some of the later optimizations I did have been done based on the compressed file size.

I think this will be resolved with T274907: Change template search in TemplateWizard to use standard search API and T286990: DRAFT: Deploy template search improvements, back button+warning message, and delete button to all wikis later this year.

… but we don't know how many of these double clicks are accidental. 😆 https://blog.codinghorror.com/double-click-must-die/

[…] when there are no parameters at all?

From a technical standpoint this is relatively easily to implement. We use the existing OOUI ComboBoxInputWidget. Items can have labels that are different from the submitted value. The widget even supports icons and item groups. The complex part of this task is to decide if and how exactly we want to support this. Problem is: once decided it's very hard to change the TemplateData specification.

Just to let you know: The mentioned T260150: VE Dialog on the Test Instance: Increase height is part of our team's current WMDE-Templates-FocusArea. This should be resolved when T286991: DRAFT: Deploy inline descriptions, extended sidebar and bigger dialog to all wikis is done later this year.