Ok, this is not worth it, esp. since it's really only a cosmetic issue. (To be fair it also wastes a tiny bit of resources when the browser needs to follow a chain of multiple redirects.)

I would like to reiterate that the way the blur effect is implemented actively makes the users wait longer. It's called unblurWithAnimation and intentionally takes 300 extra milliseconds to fade out the blur effect. That's often longer than it took to fetch the data. Just removing this delay would reduce the waiting time for everyone.

Probably not relevant, but I want to mention that we are currently abusing this error message in two other situations when something is wrong with a Cite-Extends. These code paths are obviously not enabled on production wikis.

I don't think I can find anything that explains the about attribute on the current https://www.mediawiki.org/wiki/Specs/HTML. Is this what you are referring to when you say there is a gap?

@Logan, are you able to verify if this is fixed?

When you search again, it creates a new hidden element with a name attribute set to an empty string […]

That's a great analysis, thanks a lot! I can confirm this is an issue in the Advanced-Search code. I will try to get this prioritized and fixed as soon as possible.

I suggest to close this as resolved. As explained above this is just how static maps work. The only additional thing we could do is to increase the image size further, but as mentioned this is unfortunately not possible with the currently used software versions.

Test coverage should be ok now. The cite_references_no_link message is gone via https://gerrit.wikimedia.org/r/892491.

I honestly can't tell what this refers to. There are no icons anywhere: Not on Special:Search, not in Advanced-Search, not in the MediaWiki-User-Interface. What kind of "search" is this about?

Now I get

13:48:17 includes/UserMergeHooks.php:13 PhanUndeclaredInterface Class implements undeclared interface \MediaWiki\Extension\UserMerge\Hooks\AccountFieldsHook
13:48:17 includes/UserMergeHooks.php:14 PhanUndeclaredInterface Class implements undeclared interface \MediaWiki\Extension\UserMerge\Hooks\MergeAccountFromToHook
13:48:17 includes/UserMergeHooks.php:15 PhanUndeclaredInterface Class implements undeclared interface \MediaWiki\Extension\UserMerge\Hooks\AccountDeleteTablesHook

See https://integration.wikimedia.org/ci/job/mwext-php74-phan/9483/console.

I find that a great first step is almost always to just improve the error message. This is extremely cheap to do and can greatly improve the user's confidence. The current message "we couldn't make a citation for you" especially doesn't say anything about a reason.

if ( str_ends_with( ".pdf" ) )
    show_error( "Unfortunately, extracting metadata from PDF files is currently not supported. Please try the document's DOI, title, or check if one of the citation templates on the \"Manual\" tab above supports PDFs." )

Alternative suggestion for User-notice:

Advanced-Search is the only WMDE-TechWish product that contains client-side mw.hook hooks. These have always been documented as public and stable. We also added @stable tags to the code now, see https://gerrit.wikimedia.org/r/1021410.

The content of the popup is a tiny wikitext document (label and description). If it contains images and if the images use alt= attributes is up to the author of the GeoJSON and/or the author of the map template used.

The dialog explains "This template has no documented parameters and may be intended for use without them". The button says Add undocumented parameter, emphasis on "undocumented". We rephrased these labels just recently during the WMDE-Templates-FocusArea where we reworked this part of VisualEditor. Removing the button might cause even more confusion. Why does it disappear on some templates, but not on others? How do we explain this? How does the user get the button back if they really need to? What's the point of the dialog when there is nothing to do? Do we need to remove the edit feature altogether for such templates? But then again, how do we explain this to the user?

What do you mean when you say "grouping"? How would this look like in the different tools that consume TemplateData? Does this include some functional changes, or is it really only visually?

I just had the idea to compare this with how UniversalLanguageSelector solves the problem of the list becoming unreadable when some of the lines are right-aligned, but most aren't. Turns it sets the lang="…" dir="…" attributes but still forces all lines to be vertically aligned on the left. @Amire80, you are more an expert here. Is it ok to do it like this?

There is a single place in the code that uses the data-pos-x and data-pos-y attributes from the DOM. I assume this is what we see in action. The page properties appear to be unrelated to that.

Suggestion for TechNews:

Not sure why, but the attached image is private.

This is probably the same as T259111. Should we merge them?

The last part I don't understand. VisualEditor strictly follows what is specified via TemplateData and always formats the template the same way. There is no "constant trimming and appending". This only happens when another editor uses a gadget that doesn't follow the agreed on specification.

Let's say there is

{{Template
| name    = …
| short   = …
| another = …
}}

in the article and all I want to do as a normal editor is to add the line | longest parameter = …. Out of a sudden I have to re-format the entire template? Why?

Unfortunately not, sorry. At the moment the ticket explains neither a solution nor a problem. What is the user story? How should the new syntax look like? How should it be presented and explained in the interactive TemplateData editor? How should it be documented? How should consumers like VisualEditor, the MediaWiki-extensions-TemplateWizard, Citoid, or the ContentTranslation workflow behave? Should this really block the user's edit from being saved? How would this look like in the UI? What does the error message say? What if the template already contains an unknown value that wasn't entered by the current user? Should we still block the user from continuing what they wanted to do? Why? How do we explain it to the user? How do we help the user to get unstuck? How do we measure the success rate to make sure the change was worth it and we don't loose meaningful edits due to users getting frustrated and giving up?

It sounds like number 1 is pretty much what people already do: We count how long the longest parameter is and add that number of _ characters to the format string.

Should we merge this ticket into the existing T53375?

The second half sounds like a duplicate of T363053. While T363053 is newer I feel like it describes the issue better.