Page MenuHomePhabricator

Faster access to file names in MediaViewer
Closed, ResolvedPublic



As an editor, I can quickly copy and paste the full file name (with suffix), so that I can use that file in an article without extra clicks.

Acceptance Criteria

  • The complete filename (with extension) is shown at the metadata panel just below the license.
  • The user should be able to select and copy the text.
  • (Optional) We may consider select the whole text when clicking or double clicking since the default behaviour may leave the extension unselected. Marked as optional since we need to be cautious when overriding default behaviours.

Note: this is a frequent user request on Media Viewer and RfC talk pages, which could help address editor concerns that this tool is interfering with their workflows.


ejfvU.png (614×819 px, 278 KB)

Th file icon is available here.

Event Timeline

Tgr raised the priority of this task from to Medium.
Tgr updated the task description. (Show Details)
Tgr added projects: MediaViewer, Multimedia.
Tgr changed Security from none to None.
Tgr subscribed.

Ported from mingle #798.

To help finalize the design for this feature, we're inviting feedback from casual and experienced editors on these questions:

1. Is this file name feature useful for editors?
We know it’s not that useful for readers, which is why we propose placing it below the fold — but we wanted to offer it for editors who requested it, if it’s helpful.

2. Is the placement below the license practical?
Note that you have to scroll down to see the file name; but that seemed faster than placing it in the Share panel, which would be one click away and may be harder to find.

3. Should we include ‘File:’ before the file name?
Does it help editors if we display ‘File:Chamonix flowers.jpg’ — instead of just ‘Chamonix flowers.jpg’, as shown in the mockup above?
And if we do, in what language? Should it be the canonical form (ie. English) -- or whatever language the user is speaking?
Keep in mind that a key goal of this feature is to make it easy for editors to insert that file name in wikitext.

4. Any other suggestions for improvement?

Please let us know what you think, so we can make any final tweaks based on your feedback.

Here are community responses we received via email to the questions above:

  1. Is this file name feature useful for editors?

• [Yes]. I can't copy the file name from the [Share and Embed] panels because I can't select the file name. The fields are blocked. I would have to copy everything and remove not needed parts later, which I find counter-intuitive and non-practical. Please see
• Thank you for this improvement. IMHO, this is enough: power users know how to copy/paste a link or a short wikicode.

  1. Is the placement below the license practical?

• It's a good compromise, in my opinion.

  1. Should we include ‘File:’ before the file name?

• No, don't include the namespace. It's not needed in most cases (galleries, templates, VE) and may require different localizations in specific cases. Long-time users may request it just because they are used to it but I think the arguments for not adding the namespace should win.
• The "File:" prefix is optional: it is automatically added by the interface (and translated). If you type wikicode, you know how to add a prefix.

Based on this limited feedback, it would seem appropriate to proceed with the feature as shown in the mockup above, placing it below the license info. There doesn't seem to be a need to add the 'File:' prefix before the file name, for reasons stated above.

Tgr raised the priority of this task from Medium to High.Dec 11 2014, 12:49 AM

Just for the record, 3. is pretty critical for me: copy/pasting that bit is perhaps my most common interaction with images. Yes, I need the File: bit; yes, I would rather disable MV than having to type "File:" every time I need it :)
Those who do not need it, just won't highlight it to select it; plus, "File:" works everywhere, and if people really need to have that bit in their language, then they can use their localized word, but I don't see this as an argument not to include it. When people are on Commons, even if they change the interface language they still see "File:" in the file page, AFAIK.
For those wondering why copy/pasting from address bar shouldn't be enough, titles like "File:SK_%E5%8D%97%E9%9F%93_South_Korea_tour_%E6%BC%A2%E5%9F%8E_%E9%A6%96%E7%88%BE_Seoul_%E5%A4%A9%E4%B8%BB%E6%95%99_%E6%98%8E%E6%B4%9E%E6%95%99%E5%A0%82_Myeong-dong_Cathedral_CCVMIC_interior_July-2013_ceiling_01.JPG" are why.

@Tgr the SVG icon was linked at the end of the description above. Let me know if any adjustment is needed.

Regarding the inclusion of the "File:" prefix, if we consider its usecase important enough to be included, we should make sure it does not interfere in the selection of the filename part. One solution for that could be to include each part in a different span and add some extra padding to facilitate the selection of either the filename or the whole text ("file" prefix + filename).
I created a quick example to illustrate the point, but feel free to follow a different approach.

Change 184541 had a related patch set uploaded (by Unicodesnowman):
Display the file name in metadata panel


Change 184541 merged by jenkins-bot:
Display the file name in metadata panel