@Tgr -- I have some questions about Commons metadata to help finalize these specifications:

• Is it possible to show some of the metadata in the local language? Like the date or the license? Does Commons have such a concept, in which it could say "11 Junio 2020" instead of "11 June 2020"?
• I think captions are the thing that are built to be shown in the local language. Would we be able to show the local language where it is available, but default to English when it is not (and English is available)?
• Some of the fields seem like they would have simple contents, but actually don't. For instance, sometimes the "Author" field just has a username (like this file). But sometimes it has more info, like this file or this file. How would we handle those sorts of things? Is it just that whatever is in that field gets a little sanitized (links/formatting removed) and then displayed?
• Other files don't have an "Author" field, but have a "Photographer" field, like this one. What do you think we should do there? Might it be best to show the username of the person who created the file?

In T290782#7396018, @MMiller_WMF wrote:

• Is it possible to show some of the metadata in the local language? Like the date or the license? Does Commons have such a concept, in which it could say "11 Junio 2020" instead of "11 June 2020"?

• File names are not multilingual (sometime not even lingual - they don't necessarily have to be legible, although it's preferred).
• Captions are multilingual (via some Wikidata-like mechanism). Not sure if they handle language fallback (for the pilot wikis, cs has a fallback to sk) but it's not too hard to implement by hand if needed.
• Description is multilingual (it's usually present in multiple languages on the page, and the CommonsMetadata API returns all languages so we can pick the right one). Language fallback is done manually.
• License, author and date are obtained by parsing the file page; parsing happens in the specified language so conceptually this is multilingual (the wikitext can include language-dependent contexts) with fallback support.
  • For authors who have a Wikidata item, the Creator template can pull data from there, including the name, which happens in the appropriate language, not quite sure about fallback support (it used to be a problem, but I think Wikidata supports it these days).
  • Dates vary. Some are machine-readable, CommonsMetadata parses them and returns them in a standard localized format. Some are generated by a language-aware wikitext construct so their format will be non-standard but still localized. Some are just strings (usually in English).
• Categories are always in English. A few of them are linked to Wikidata items which could in theory be used to fetch the name of the category on another wiki, but it adds complexity and I don't think it would work often in practice.

• I think captions are the thing that are built to be shown in the local language. Would we be able to show the local language where it is available, but default to English when it is not (and English is available)?

Yes, we can do that for any metadata that's multilingual. (More precisely, we'd probably want to use the local language's fallback chain.) The local language is the wiki's content language, not the language confiugred by the user (the user interface language), right?

• Some of the fields seem like they would have simple contents, but actually don't. For instance, sometimes the "Author" field just has a username (like this file). But sometimes it has more info, like this file or this file. How would we handle those sorts of things? Is it just that whatever is in that field gets a little sanitized (links/formatting removed) and then displayed?

The CommonsMetadata extension, which we are relying on here, can handle some common formats (like the creator box in your second example). For the rest, I think we should have a list of "see-through" tags (links, italic, bold) which are converted to plain text, and other tags should be discarded alongside their content.
There's a copyright angle here (some licenses require the link to the author or the license to be preserved), but I think we are good as long as we link to the image description page prominently. Maybe worth double-checking with WMF Legal though.

• Other files don't have an "Author" field, but have a "Photographer" field, like this one. What do you think we should do there? Might it be best to show the username of the person who created the file?

Internally, that's still marked as the author field.

There are image types where the concept of the author is less clear - e.g. photographs of statues where there is an author for the statue and an author for the image; restored/retouched images with multiple contributors; collages. I suppose the biggest problem here is if the user wants to mention the author of some artwork in the image caption and gets confused and mentions the photographer instead. Not sure what to do about that.
The username of the uploader doesn't seem like relevant information to me.

note @MMiller_WMF – I made minor updates to the task description around not showing the metadata when the field is blank, and also showing suggestion reason on the dialogs.

@Tgr -- I updated the task description to incorporate your info about how the metadata is pulled from Commons. This is now ready to work on.

For Author, we'll be at the mercy of what data CommonsMetadata provides. (We could try to improve that extension over time, but for Iteration 1 I don't think we want that kind of distraction.) It's always a single field, and it isn't structured, just a HTML string.

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

[mediawiki/extensions/GrowthExperiments@master] Add Image: Collect more image metadata

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

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

[mediawiki/extensions/GrowthExperiments@master] [WIP] Add Image: Image details dialog

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

Change 736271 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add Image: Collect more image metadata

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

Change 736643 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add Image: Image details dialog

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

Checked the specs on wmf.12 and wmf.13(arwiki was checked too) - works as expected, except for Categories.

@Tgr - please review the following. It could be filed as a separate issue if it needs to be followed up.
Two issues:
(1) On testwiki wmf.13 - the categories are present.

The language wikis (cswiki wmf.12, arwiki wmf.12) do not display the categories although the suggested images have them on commons. For example:
The following file does not display Categories, but the file on commons - https://commons.wikimedia.org/wiki/File:1948_San_Francisco_trafficways_plan.jpg - have several Categories.

(2) The categories are not displayed on commons mobile. So, if a user sees Categories displayed in the image detail and switches to view the file on commons, it might be confusing to see that there are no categories dispalyed.

In T290782#7574356, @Etonkovidova wrote:

(2) The categories are not displayed on commons mobile. So, if a user sees Categories displayed in the image detail and switches to view the file on commons, it might be confusing to see that there are no categories dispalyed.

This is an issue with MobileFrontend or MinervaNeue, I assume.

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

[mediawiki/extensions/GrowthExperiments@master] Add Image: Do not use local namespace name when calling Commons API

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

Change 752368 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add Image: Do not use local namespace name when calling Commons API

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