Currently on the server side the ImageRecommendationProvider fetches a JSON object from the image recommendation API, that gets included in the HTML, and stored in SuggestedEditSession where AddImageArticleTarget (or maybe the dialog) can access it. That's the same mechanism we used for Add Link. But it only includes the image name and recommendation-related metadata (source wikis etc); not the thumbnail URL or the description. (For Add Link IIRC we extended a VisualEditor component which handled fetching data via extra AJAX requests, so the issue did not come up there.)

There are two approaches to getting the data: do an AJAX request from somewhere in the Add Image JS code, or do it on the server side in ImageRecommendationProvider. Some thoughts:

• As long as we only needed the thumbnail URL and description, those are available via cached cross-wiki-available abstraction layers (FileRepo and FormatMetadata::fetchExtendedMetadata()) which provide much better performance. It seems likely though that we'll eventually use more things, and AFAIK the WikibaseMediaInfo data (like captions and depict tags) isn't made available in a similar way and would require web requests to the Commons API.
• Even for web requests, intra-datacenter requests are much faster than a request from the user's browser (especially if they are on a slow connection).
• OTOH Javascript parallelizes web requests and PHP does not (or at least there is no precedent of trying to do it within MediaWiki, apart from a few very specific maintenance scripts and RESTBase clients), so depending on when the request is fired it might happen during other slow things like VE setup and might be a freebie performance-wise.
• Commons (obviously) prefers high-quality, high-resolution images. For such images thumbnailing can be quite slow, even if the thumbnail itself is small. MediaWiki (with the configuration used on Wikimedia wikis) thumbnails on-the-fly, whenever the given image in the given resolution is requested for the first time. We might want to make the thumbnail use a "standard" size which is used elsewhere on the wiki (such as the size used in the image history entries) to increase the chance that it is already thumbnailed, or use a standard size that's a bit larger than the visible size, and let the browser scale it down (and accept the quality hit, as the browser will use a faster and less precise algorithm). This goes for T290540: Add an image: image viewer too. Then again, we didn't care about this for the task card thumbnails and it did not seem to cause any issues. (I do remember having lots of trouble related to this with MediaViewer, though.)

Change 721088 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add an image: show suggestion-specific content in image inspector

https://gerrit.wikimedia.org/r/721088

Note: Currently the suggestion reason just shows the projects the image is used in. This will be updated once the parent task is finalized.

Change 721088 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add an image: show suggestion-specific content in image inspector

https://gerrit.wikimedia.org/r/721088

Change 723028 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Foward metadata errors in ServiceImageRecommendationProvider

https://gerrit.wikimedia.org/r/723028

Change 723028 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Foward metadata errors in ServiceImageRecommendationProvider

https://gerrit.wikimedia.org/r/723028

The relevant patches have been reviewed, so moving this into QA.

@mewoph -- I just updated this task with the latest specifications from the final mockups and our deep dive. There have been a few changes.

For Design review

• Filename: in black bold, including the extension (e.g. ".jpg"). It only has one line. It should not be a link or have the "open in another window" button. If the filename is too long, it should have a "...".

Just a suggestion: a file name is displayed with underscores in the add image inspector. File page on commons displays a file name without underscores. If filenames will be displayed as File pages titles (as on commons) it would be more readable for users?

Below are the screenshots for illustration only - all specs seem to be in place.

One note about the image above - https://commons.wikimedia.org/wiki/File:Boubou_Ciss%C3%A9,_first_minister_of_Mali,_june_2019.jpg image is used on many wikis; the the reason "One of several images linked to the Wikidata item for this article" sounds too technical. Is it expected from newcomers to correctly evaluate that reason?

In T290911#7497619, @Etonkovidova wrote:

For Design review

• Filename: in black bold, including the extension (e.g. ".jpg"). It only has one line. It should not be a link or have the "open in another window" button. If the filename is too long, it should have a "...".

Just a suggestion: a file name is displayed with underscores in the add image inspector. File page on commons displays a file name without underscores. If filenames will be displayed as File pages titles (as on commons) it would be more readable for users?

One good thing about me taking so long to finish design review of this item is that this suggestion has been implemented already :)

Below are the screenshots for illustration only - all specs seem to be in place.

One note about the image above - https://commons.wikimedia.org/wiki/File:Boubou_Ciss%C3%A9,_first_minister_of_Mali,_june_2019.jpg image is used on many wikis; the the reason "One of several images linked to the Wikidata item for this article" sounds too technical. Is it expected from newcomers to correctly evaluate that reason?

We decided to launch with this copy as the simplest explanation for the source being a Commons image found that shares a category tag with the wikidata item matching the Wikipedia article, partly seeing that users in testing tended to ignore the reason when they didn't understand it but it had not adverse impact on their evaluation.