Page MenuHomePhabricator

Link to file page instead of lightbox over file page in the HTML embed code
Open, LowPublic

Description

Per Lupo's comment in bug 69497

BTW, it'd be very nice if the MediaViewer would just generate the links back
to the file as

https://commons.wikimedia.org/wiki/File:Saint-Pierre-de-M%C3%A9sage_(38)_-
_Salle_des_f%C3%AAtes.jpg

instead of

https://commons.wikimedia.org/wiki/File:Saint-Pierre-de-M%C3%A9sage_(38)_-
_Salle_des_f%C3%AAtes.jpg#mediaviewer/File:Saint-Pierre-de-M%C3%A9sage_(38)_-
_Salle_des_f%C3%AAtes.jpg

I don't have a strong opinion either way; what would be the advantage of this?


Version: unspecified
Severity: normal

Details

Reference
bz69539

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:29 AM
bzimport added a project: MediaViewer.
bzimport set Reference to bz69539.
bzimport added a subscriber: Unknown Object (MLST).
  • Nicer, shorter backlinks?
  • Less HTML to paste? (Which in turn helps keep the text wherever the user is inserting this more easily understandable.)
  • Less HTML code where something could wrong when the user pastes it?
  • No pointless duplication of the filename?

(In reply to Lupo from comment #1)

  • Less HTML to paste? (Which in turn helps keep the text wherever the user

is inserting this more easily understandable.)

In your example this brings down the embed HTML length from 1027 to 873 characters; I don't think that makes much of a difference.

  • Less HTML code where something could wrong when the user pastes it?

A percent-encoded fragment in an URL in a href property does not seem like particularly risky to me.

  • Nicer, shorter backlinks?

The one location where that is exposed to the user is the status bar of the browser where the URL is displayed when hovering over the link. Modern browsers typically truncate that to ~70 characters. For Commons, that leaves about 40 characters for the file name; there is a tendency to use long and descriptive file names (the one in your example is 60 characters), so again, it wouldn't make much difference.

  • No pointless duplication of the filename?

It's not pointless; it opens MediaViewer, so that the image is displayed in a nicer format than the file page's default layout. That said, the duplication could be avoided by doing something like https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/416

  • Bug 69977 has been marked as a duplicate of this bug. ***

It would points to the 'canonical' representation of the image, which the file description page still is.

I've not seen many convincing arguments to auto opening the media viewer either if I'm honest... What was the rationale for that ? I suspect it is to facilitate the 'share' services flow, but we don't really have that down yet I think...

Also
How about MediaViewer on a File des. page just opens the viewer ? then then the duplication is at least no longer required.

I agree with Lupo. Please just link directly to the Commons page. It's simpler, cleaner, provides direct access to all the file information (why else would someone be clicking through the attribution link?), and would cause less confusion to those accustomed to URLs without parameters.

Gilles subscribed.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.