It would be nice to be able to embed images and other media from Commons, too, e.g. for charts, screenshots, mockups and screencasts.

What would you like to accomplish and why is a link not sufficient?
(Comparing to an image thumbnail here I don't count more clicks to see a bigger version; and compared to non-previewed media like videos I don't count more clicks on external than internal sources.)

The footer below [...]. So I'm kind of curious how that works legally.

See link in https://gerrit.wikimedia.org/r/#/c/239073/

I believe this feature would be very difficult to implement (given that there isn't even a trace of remote image engine support in Phabricator) with very little gain. It isn't that hard to re-upload or just post a link like Aklapper said.

In T116515#1751512, @Aklapper wrote:

It would be nice to be able to embed images and other media from Commons, too, e.g. for charts, screenshots, mockups and screencasts.

What would you like to accomplish

See the third paragraph of the task description.

and why is a link not sufficient?

Well, ask the people who are already using embedded images instead of links ;) From my own perspective as data analyst, communication about data is greatly facilitated by that ability, and it seems other users agree, see task 116609 for a current example (not by me). I've also seen designers use it for mockups, etc.

That questions is a bit orthogonal here anyway though: if you think the option to embed images is unnecessary altogether and should be removed, that should be discussed in a separate task.

(Comparing to an image thumbnail here I don't count more clicks to see a bigger version; and compared to non-previewed media like videos I don't count more clicks on external than internal sources.)

That's interesting (do you have a link to those stats?), but is likewise a bit beside the point here, as the proposal is not about enabling viewing of enlarged versions - rather, it's about enabling and facilitating reuse. And I'm not quite sure what you mean by a comparison to videos, as those can't be embedded anyway in our current setup.

The footer below [...]. So I'm kind of curious how that works legally.

See link in https://gerrit.wikimedia.org/r/#/c/239073/

I already quoted the updated wording above. That link doesn't answer the question I had posed, on how a valid release (under CC BY-SA) is granted when a user uploads an image to Phabricator. Can you explain further?

In T116515#1751939, @Negative24 wrote:

I believe this feature would be very difficult to implement (given that there isn't even a trace of remote image engine support in Phabricator) with very little gain.

Admittedly I too am not familiar with Phabricator's code base, but their code for YouTube support consists of just 50 not very complicated looking lines, much of which could possibly be reused. And I don't think Commons is that much more complex as a remote engine. I would be happy to help figuring out how to generate the required thumbnail image URL from the full file description URL for Commons.

It isn't that hard to re-upload or just post a link like Aklapper said.

Except that, as I already said, you can't currently upload content authored by others here on Phabricator, and concerning the other direction, the licensing seems shaky. And even disregarding the licensing issues, it's certainly much more user-friendly to be able to reuse without re-uploading - that's why Phabricator already includes the YouTube feature, and platforms such as WordPress enable embedding media from other sites as well.

So it seems pretty straightforward to support some form of commons embedding, assuming we can just use a <video> that direct-links to the stream url. It would require some modifications to remarkup but presumably the youtube embedding code would be a fairly good example for how it's done.

Looking at the code, it seems like an iframe for Youtube, and Commons does have a URL to be put in an iframe, so that's perfect. I think we need the actual Commons video player because:

• it can switch between streams (useful for low bandwidth situations)
• it displays proper attribution and license information

Cool, that seems reasonable. @Gilles: you can take a stab at copying the youtube implementation if it seems straightforward, or I can look into it. It's been a while since I worked on the remarkup code but I think I remember how it works, generally.

I can try writing that this summer, right now I'm swamped until the end of the quarter.

Sounds great! Would this work for images too, besides video?

Other formats like images will need their own markup and probably a separate syntax. Images in particular are challenging because currently you really need to make an API call before you can tell that the size you're going to request is possible for that image. I don't know if that's possible, and even if it is, desirable, in that context of phabricator's code.

Ideally we'd have a standardized viewer you can put in an iframe for all file types, which means we'd have a single syntax to embed a file from Commons. But that's significantly more work on the Mediawiki side to make this integration possible. It would be nice to have Media Viewer support all file formats to begin with, and then figure out how to make it embeddable inside an iframe...

Embedding media viewer in an iframe would be cool indeed, but that sounds like a rather serious project, maybe not something for the skunkworks.

Dosent seem to work on an iPhone.

:(

Oh I see why, it's an webm video. iPhones doint support webm. Though we have a js shim that should allow this.

Right, that will fix itself when TMH switches to videojs: T100106: Replace Kaltura player with Video.js. It's a limitation of the Commons embed code, not of Phabricator.

@mmodell, @Gilles video.js is enabled on test2 btw:

https://test2.wikipedia.org/wiki/File:Folgers.ogv

In case you want to test that.

Upstream task is T4190.

This task was originally mainly about images, but then morphed into a task about videos and was closed as such. I have split the image part off into T199407.

BTW, the example video above in T116515#3309596 doesn't work for me right now, in either Chromium ("Requests to the server have been blocked by an extension." - even when I have no browser extension enabled) or Firefox.

maybe we need to adjust content security policy?

In T116515#4419390, @mmodell wrote:

maybe we need to adjust content security policy?

Indeed, it looks like it has to do with that - filed as T200757.