Page MenuHomePhabricator

Add an image: image details
Closed, ResolvedPublic

Description

This task is about the dialog for viewing image details, to be used with both T290045: Add an image: image inspector and T290781: Add an image: captions. The dialog appears in these two situations:

  1. On the image inspector, when the user taps the image details area.
  2. During the caption process, when the user taps to "View image details".
  3. Header: "Image details"
  4. Body: it should contain the suggestion reason, followed by the specified metadata fields from the image on Commons. The labels of the fields should be in bold. For each of these fields, we should display in the wiki's content language when available, and then use the wiki's fallback chain if available. Otherwise, fallback to English, and to any available language if English is unavailable. We would rather show something in a different language than nothing at all.
    • "Suggestion reason": this is the suggestion source reason. Display business rules will follow whatever is shown in the inspector card (per T292467)
    • "Filename"
    • "Description": this is the free-text description.
    • "Caption": this is the structured data caption.
    • "License"
    • "Date"
    • "Author": if an image has multiple author-like attributes, such as a photographer and a painter, we should try to show all of those in this field in a sensible way.
    • "Categories": these are the page's actual categories. This should not show hidden categories.
  5. There should be a line of whitespace between "Caption" and "License"; and also between "Author" and "Categories".
  6. When a field is null, it should contain a dash, like this: "Caption: -" not appear at all
  • The bottom line should be a blue link with "external link" icon: "Image file on Commons"
  • The dialog has a single "Close" button at the bottom.
  • If some of the fields have a lot of content, that's okay -- the dialog should just be scrollable.

Event Timeline

MMiller_WMF renamed this task from Add an image: image details (PLACEHOLDER) to Add an image: image details.Oct 2 2021, 1:22 AM
MMiller_WMF removed MMiller_WMF as the assignee of this task.
MMiller_WMF updated the task description. (Show Details)
MMiller_WMF removed a subscriber: Mmiller0712.

@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?
  • 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.

kostajh triaged this task as Medium priority.Oct 6 2021, 9:50 AM

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.

Screen Shot 2021-12-15 at 5.05.06 PM.png (1×804 px, 216 KB)

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.

Screen Shot 2021-12-15 at 5.15.02 PM.png (1×746 px, 234 KB)

(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.

Screen Shot 2021-12-15 at 5.25.20 PM.png (1×756 px, 181 KB)

(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

Checked on wmf.18 - all specs seem to be in place. The issue with absent Categories - https://phabricator.wikimedia.org/T290782#7574356 - is fixed.

long Description (Caption title is absent)ruUI langdescription in Arabic
Screen Shot 2022-01-21 at 4.36.20 PM.png (922×1 px, 220 KB)
Screen Shot 2022-01-21 at 4.44.27 PM.png (966×790 px, 171 KB)
Screen Shot 2022-01-21 at 4.42.36 PM.png (872×682 px, 161 KB)