Thoughts on Image:, Media: and Download:

List overview All Threads
Download

newer

older

Reasons never to remove nofollow

MediaWiki automated test run...

Tim Starling

17 Apr 2007 17 Apr '07

3:44 a.m.

Our handling of [[media:...]] links has the feel of a temporary solution. In the absence of true media support, we give the user a direct link to the file so that they can play it with an external application. Presumably this was never meant to be a permanent syntax feature. Now that we are edging closer to true audio and video support in MediaWiki, it might be a good time to re-evaluate this syntax convention. I'm making some architectural changes at the moment that will make it easier to support audio and video in the core, on the same footing as images. The question of syntax then becomes relevant. We could add another prefix that plays audio or video inline in the browser. But the thing is, "media" is a very good term for this operation, and its current function will be made all the more confusing by introducing a similarly named keyword that does what "media" should have done in the first place. What I propose is to introduce a new prefix called "download", which will replace "media" for cases where downloading is really what is desired. For example: [[download:Foo.doc|Click here to download the text as an MS Word document]] Wikimedia's text corpus can be transitioned to this syntax over a period of time. Then the stage will be set to introduce media player features to [[media:...]] style links. Backwards compatibility can be maintained for file types with no currently defined media player. Puns on putting the media back into MediaWiki have been studiously avoided until this closing sentence. -- Tim Starling

Show replies by date

Gregory Maxwell

17 Apr 17 Apr

5:43 a.m.

On 4/16/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

[[download:Foo.doc|Click here to download the text as an MS Word document]] Wikimedia's text corpus can be transitioned to this syntax over a period of time. Then the stage will be set to introduce media player features to [[media:...]] style links. Backwards compatibility can be maintained for file types with no currently defined media player. Puns on putting the media back into MediaWiki have been studiously avoided until this closing sentence.

What a downer. In any case, sounds good to me. :)

Steve Bennett

5:52 a.m.

On 4/17/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

Is it necessary to have two keywords? Consider the case of an image: It displays as a thumbnail, but if you click it, you can then download the full sized image. To get straight on with downloading it, you use [[:Image:Foo.jpg]]. Is it not possible to do something similar with video? It could display in a certain size, then if you click the video (or some link), you would be taken to the media page where you could download it. [[:Media:Foo.avi]] would take you straight to that page. I can't really picture how a .doc file fits in (would it ever be displayed inline?), but could the same convention be used? [[Media:Foo.doc]] attempts to display it inline, with a click taking you to the media page (and download link). [[:Media:Foo.doc]] takes you straight to the media page. I confess my Wikipedia bias. Perhaps that extra round of clicks is annoying for many projects. Steve

Brianna Laugher

6:02 a.m.

On 17/04/07, Steve Bennett <stevagewp(a)gmail.com> wrote:

...

On 4/17/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

Er, no you don't. That just makes a link to the image page. "To get straight on with downloading it", you do [[media:Foo.jpg]]. There are three things. (attempting) displaying the item inline, making a text link to the item page (i.e. pages in the Image: namespace currently), and making a text link to the item itself. Anyway +1 for anything that improves any media support. Wikisource might also have some ideas about how to improve wikisyntax as they use DjVU fies, and ditto Wiktionary with audio. cheers, Brianna user:pfctdayelise

Steve Bennett

6:21 a.m.

On 4/17/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:

...

Er, no you don't. That just makes a link to the image page. "To get straight on with downloading it", you do [[media:Foo.jpg]].

Yeah, bad wording of mine. If there is a strong need for links directly to download a file, could I suggest the "File" namespace rather than "Download", the latter being a verb and all. And "file" would fit well: It's not an article, it's not a discussion, it's not a category, it's just...a file. Steve

Dave Sigafoos

1:26 p.m.

FILE: I think is a much better term. This would work with all "files" including non-media. Download would 'imply' the use of the file. DSig David Tod Sigafoos | SANMAR Corporation -----Original Message----- From: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Steve Bennett Sent: Monday, April 16, 2007 23:22 To: Wikimedia developers Subject: Re: [Wikitech-l] Thoughts on Image:, Media: and Download: On 4/17/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:

...

Er, no you don't. That just makes a link to the image page. "To get straight on with downloading it", you do [[media:Foo.jpg]].

Tim Starling

2:57 p.m.

Steve Bennett wrote:

...

On 4/17/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:

Er, no you don't. That just makes a link to the image page. "To get straight on with downloading it", you do [[media:Foo.jpg]].

File is what the Image namespace should have been called. It doesn't tell you what you want to do with the file, it just describes the object. So it's ambiguous: is [[File:Thing.jpg]] a link to the description page, an inline image or a download link? I chose "download" because it describes the action, not the object. -- Tim Starling

Brion Vibber

6:51 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Starling wrote:

...

Steve Bennett wrote:

On 4/17/07, Brianna Laugher wrote:

Er, no you don't. That just makes a link to the image page. "To get straight on with downloading it", you do [[media:Foo.jpg]].

File is what the Image namespace should have been called.

...and *is* called in some languages... and has been planned as the new canonical name of the current Image: namespace when we get around to it, which we haven't yet.

...

It doesn't tell you what you want to do with the file, it just describes the object. So it's ambiguous: is [[File:Thing.jpg]] a link to the description page, an inline image or a download link? I chose "download" because it describes the action, not the object.

Yes; we should avoid resurrecting the old technique of overloading the regular linking syntax for "magic" namespaces (as with Image:, Category:, and the language interwiki prefixes.) It violates the principle of least surprise. Using at least a separate magic alias that doesn't appear in canonical titles (like Media: currently) is an improvement. However I would recommend against significantly changing what Media: does; changing old behavior gratuitously is also kind of user-hostile. If we want a new keyword that means "embedded media player", a new name something like 'Embed:' might be good, or even simply adding 'Video:' and 'Audio:' aliases alongside 'Image:' -- which is *already* an inline media embedding keyword, which happens to only support static images at the moment. - -- brion vibber (brion @ wikimedia.org)

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJRcrwRnhpk1wk44RAhNtAKCf+Arntt0fu9v5q8ktWGncyH3dowCgog0s gp0LumVxW1aHjJvQ7CpYmSI= =4+Z1 -----END PGP SIGNATURE-----

John Vandenberg

7:59 a.m.

On 4/17/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:

...

On 17/04/07, Steve Bennett <stevagewp(a)gmail.com> wrote: > On 4/17/07, Tim Starling <tstarling(a)wikimedia.org> wrote: > > What I propose is to introduce a new prefix called "download", which will > > replace "media" for cases where downloading is really what is desired. For > > example: > > > > [[download:Foo.doc|Click here to download the text as an MS Word document]]

Introducing a new keyword to better reflect the action makes sense. Altering the meaning of "media:" is a bad idea, as old documentation becomes bad advice. If it does go ahead at that name, I hope that the software upgrade with automate the migration of all media: to download:

...

Er, no you don't. That just makes a link to the image page. "To get straight on with downloading it", you do [[media:Foo.jpg]].

I like Steve's suggestion of overloading existing conventions rather than introduce new ones, if possible. Firstly, what is wrong with using [[Image:Blah.mov|200px...]]? Alternatively, could we use {{Media:Blah.mov}} to do the inclusion?

...

There are three things. (attempting) displaying the item inline, making a text link to the item page (i.e. pages in the Image: namespace currently), and making a text link to the item itself. Anyway +1 for anything that improves any media support. Wikisource might also have some ideas about how to improve wikisyntax as they use DjVU fies, and ditto Wiktionary with audio.

Is there a MediaWiki.org page that describes the "true audio and video support" being discussed. -- John

Tim Starling

3:53 p.m.

John Vandenberg wrote:

...

On 4/17/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:

On 17/04/07, Steve Bennett <stevagewp(a)gmail.com> wrote: > On 4/17/07, Tim Starling <tstarling(a)wikimedia.org> wrote: >> What I propose is to introduce a new prefix called "download", which will >> replace "media" for cases where downloading is really what is desired. For >> example: >> >> [[download:Foo.doc|Click here to download the text as an MS Word document]]

The thing is that most media: links on Wikimedia wikis really are media. So the correct prefix will still be media: after the change, not download:.

...

Er, no you don't. That just makes a link to the image page. "To get straight on with downloading it", you do [[media:Foo.jpg]].

I like Steve's suggestion of overloading existing conventions rather than introduce new ones, if possible. Firstly, what is wrong with using [[Image:Blah.mov|200px...]]?

Because a sound file is not an image. It's wrong and broken and deserves to be fixed.

...

Alternatively, could we use {{Media:Blah.mov}} to do the inclusion?

Is there a MediaWiki.org page that describes the "true audio and video support" being discussed.

No. -- Tim Starling

Simetrical

5:03 p.m.

On 4/17/07, John Vandenberg <jayvdb(a)gmail.com> wrote:

...

Alternatively, could we use {{Media:Blah.mov}} to do the inclusion?

I've always maintained that it makes much more sense for [[]] to be inline links, always, and {{}} to be inclusions of content (which may or may not be inline), always. So category, interwiki link, media, and template inclusion should all use curly braces, inline links to any of those should use square brackets rather than the bizarre initial-colon thing. Then linking really is [[pagename]], not [[pagename]] or maybe [[:pagename]]. (Some syntax would have to be devised for transcluding category/image pages, but that's a very rare use case.) But that's just me. :P

Jim Hu

6:12 p.m.

On Apr 17, 2007, at 1:03 PM, Simetrical wrote:

...

On 4/17/07, John Vandenberg <jayvdb(a)gmail.com> wrote:

Alternatively, could we use {{Media:Blah.mov}} to do the inclusion?

I don't think of category or interwiki as being inclusions of content. Category isn't inline since the link goes to the bottom of the page in the category list, but interwiki is inline, isn't it? I could see an argument for [[Image:imagename]] going to the image description and {{Image:imagename |params}} doing what [[Image:imagename|params]] does now. But I don't get the distinction for the others that you would move to {{ }} I suspect I am misunderstanding what you mean by "inline" and "inclusions of content". Template and Image seem like both inline and inclusion of content to me. Even regular links alter the content of what is in the braces. It also seems like your proposal is a much larger backwards compatibility nightmare than the others. Jim

...

inline links to any of those should use square brackets rather than the bizarre initial-colon thing. Then linking really is [[pagename]], not [[pagename]] or maybe [[:pagename]]. (Some syntax would have to be devised for transcluding category/image pages, but that's a very rare use case.) But that's just me. :P _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054

Simetrical

7:31 p.m.

On 4/17/07, Jim Hu <jimhu(a)tamu.edu> wrote:

...

I don't think of category or interwiki as being inclusions of content. Category isn't inline since the link goes to the bottom of the page in the category list, but interwiki is inline, isn't it?

I meant interlanguage, like [[fr:Whatever]]. Those jump off to the side. I agree that those could just as easily be put as [[]], but if they're {{}} then [[]] has totally consistent meaning, and {{}} means "do what you would normally want to do with the target other than link to it" (include templates, display images, add to categories, add interlanguage link).

...

It also seems like your proposal is a much larger backwards compatibility nightmare than the others.

Yeah, that's the slight problem with it. If only this were five years ago . . . :P

Magnus Manske

11:38 a.m.

On 4/17/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

[[download:Foo.doc|Click here to download the text as an MS Word document]]

Tim Starling

3:58 p.m.

Magnus Manske wrote:

...

On 4/17/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

[[download:Foo.doc|Click here to download the text as an MS Word document]]

It's a reasonable proposal.

...

* [[media:stuff.avi|play|start|text]] is a player that starts automatically

Do we really need that feature? -- Tim Starling

Gurch

5:35 p.m.

Tim Starling wrote:

...

Magnus Manske wrote:

On 4/17/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

[[download:Foo.doc|Click here to download the text as an MS Word document]]

It's a reasonable proposal.

* [[media:stuff.avi|play|start|text]] is a player that starts automatically

Do we really need that feature? -- Tim Starling

First, there were bad colour schemes. Then, there were userboxes. Now, witness annoying userpages taken to the next level. You're right, we really don't need that feature. -Gurch

Rob Church

5:39 p.m.

On 17/04/07, Gurch <matthew.britton(a)btinternet.com> wrote:

...

First, there were bad colour schemes. Then, there were userboxes. Now, witness annoying userpages taken to the next level.

Jeez, this is why the term "Don't stove beans up your nose" was introduced, wasn't it? Don't give the goddamn user base any IDEAS! Rob Church

Rob Church

5:14 p.m.

On 17/04/07, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

What I propose is to introduce a new prefix called "download", which will replace "media" for cases where downloading is really what is desired. For example: [[download:Foo.doc|Click here to download the text as an MS Word document]] Wikimedia's text corpus can be transitioned to this syntax over a period of time. Then the stage will be set to introduce media player features to [[media:...]] style links. Backwards compatibility can be maintained for file types with no currently defined media player.

That sounds like a good solution to me; realistically, we can't do much more for backwards compatibility, and I certainly support the change to using appropriate markup if it's going to allow nifty things like inline media players to be used sensibly, and in line with user expectations overall. I'm not sure if it wouldn't be worth renaming the Image namespace to "File" at some point; keeping "Image:" as a prefix when performing image embedding, of course - audio files and video aren't really "images", and probably shouldn't be in there from a first-glance point of view. Rob Church

Brianna Laugher

5:24 p.m.

On 18/04/07, Rob Church <robchur(a)gmail.com> wrote:

...

I'm not sure if it wouldn't be worth renaming the Image namespace to "File" at some point; keeping "Image:" as a prefix when performing image embedding, of course - audio files and video aren't really "images", and probably shouldn't be in there from a first-glance point of view.

For a "first glance", some kind of preview is useful. For audio file I can't think of anything foolproof, just a music note image, but for video there is an obvious one - a still from the video (somehow YouTube does this by magic. Could we do it too?). And don't forget documents such as DjVU, pdf, whatever else people want to allow. Probably a true preview is not that useful and just an image of a file/document will do. cheers Brianna

Nick Jenkins

26 Apr 26 Apr

10:12 a.m.

...

image embedding, of course - audio files and video aren't really "images", and probably shouldn't be in there from a first-glance point of view.

For a "first glance", some kind of preview is useful. For audio file I can't think of anything foolproof, just a music note image,

Maybe a music note image + the length of the audio file (if there's not something else that shows this information). If some sound bite is 20 seconds long, I'm far more inclined to listed to it at a computer than something which takes a hour - but either way, length is useful 'audio-preview' information. -- All the best, Nick.

Steve Bennett

27 Apr 27 Apr

4:47 a.m.

On 4/26/07, Nick Jenkins <nickpj(a)gmail.com> wrote:

...

And since we have a text field, we show that too. So we have a box, with a symbol (why a music note? standard would be a loudspeaker symbol), and underneath, some text like "John Cage's 4'33, played by Elton John. (4m 40s)". Steve

Jay R. Ashworth

1:44 p.m.

On Fri, Apr 27, 2007 at 02:47:23PM +1000, Steve Bennett wrote:

...

And that's the funniest thing I've read all day. Thanks, Steve. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

Platonides

18 Apr 18 Apr

10:47 a.m.

Against. Don't make more innecesary magic namespaces. We can already achieve it without making more namespaces. [[Image:Foo]] switch(MIME(Foo)) { case image/gif: case image/png: case image/jpeg: echo <img src=`convert... break; case image/svg-xml: echo <img src=`rsvg.. break; case image/vnd.djvu: echo <combobox=page2,page3...><img src=`djvu ... break; case vnd.oasis.opendocument.* echo <img src= Extract(Path(Foo) . /Thumbnails/thumbnail.png) break; case application/ogg: echo <applet video-viewer.class> . Path(Foo)... break; default: echo <img src="Unknown type.png" } What's wrong with it? An array of callbacks to handle the MIME. Making [[Image:*.djvu]] a red link pointing to Special:upload as we currently do is clearly wrong. Note: On viewing djvu page, i get <img src= to wiki pages (html). What was intended? Renaming to File & Download could be ok. Using {{ }} syntax to include images is more consistent, but i don't think we can do such change now. We don't need players which start automatically.

Tim Starling

19 Apr 19 Apr

5:24 a.m.

Platonides wrote:

...

Against. Don't make more innecesary magic namespaces. We can already achieve it without making more namespaces.

This isn't a vote.

...

[[Image:Foo]] switch(MIME(Foo)) { case image/gif: case image/png: case image/jpeg: echo <img src=`convert... break; case image/svg-xml: echo <img src=`rsvg.. break; case image/vnd.djvu: echo <combobox=page2,page3...><img src=`djvu ... break; case vnd.oasis.opendocument.* echo <img src= Extract(Path(Foo) . /Thumbnails/thumbnail.png) break; case application/ogg: echo <applet video-viewer.class> . Path(Foo)... break; default: echo <img src="Unknown type.png" } What's wrong with it? An array of callbacks to handle the MIME.

I already answered this question in another post. http://lists.wikimedia.org/pipermail/wikitech-l/2007-April/030928.html

...

Making [[Image:*.djvu]] a red link pointing to Special:upload as we currently do is clearly wrong.

What's that got to do with anything?

...

Note: On viewing djvu page, i get <img src= to wiki pages (html). What was intended?

I don't know what you mean. I haven't seen anything like that. -- Tim Starling

Platonides

7:01 a.m.

Tim Starling wrote:

...

Platonides wrote:

Against. Don't make more innecesary magic namespaces. We can already achieve it without making more namespaces.

This isn't a vote.

It's a summary. On the wiki there're many "votes" which really aren't, at the end, a sysop decides. But people vote anyway. Of course, you will end up doing whatever you want. :P

...

What's wrong with it?

I already answered this question in another post. http://lists.wikimedia.org/pipermail/wikitech-l/2007-April/030928.html

The link is wrong. It's http://lists.wikimedia.org/pipermail/wikitech-l/2007-April/030911.html I read it, but you're answering there is a need to change because the used namespaces have a different meaning. If the names are wrong, change (or aliase) them. Don't create "correct" names.

...

Making [[Image:*.djvu]] a red link pointing to Special:upload as we currently do is clearly wrong.

What's that got to do with anything?

This would be a bug fixed with using Image: to visualize.

...

Note: On viewing djvu page, i get <img src= to wiki pages (html). What was intended?

I don't know what you mean. I haven't seen anything like that.

http://commons.wikimedia.org/wiki/Image:Juliana_Ernstin_Chronik_Villingen.d…

Tim Starling

4:39 p.m.

Platonides wrote:

...

Making [[Image:*.djvu]] a red link pointing to Special:upload as we currently do is clearly wrong.

What's that got to do with anything?

This would be a bug fixed with using Image: to visualize.

The fact that image links to nonexistent files create a red link to Special:Upload was a feature I introduced. It was intended to be a simpler way to upload files, similar to the way you create articles.

...

Note: On viewing djvu page, i get <img src= to wiki pages (html). What was intended?

I don't know what you mean. I haven't seen anything like that.

http://commons.wikimedia.org/wiki/Image:Juliana_Ernstin_Chronik_Villingen.d…

This is what it's meant to do: http://commons.wikimedia.org/wiki/Image:Marchez_pendant_que_vous_avez_la_lu… File a bug report. -- Tim Starling

Brion Vibber

8:38 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Starling wrote:

...

Platonides wrote:

Making [[Image:*.djvu]] a red link pointing to Special:upload as we currently do is clearly wrong.

What's that got to do with anything?

This would be a bug fixed with using Image: to visualize.

And in that it's a good feature. There are some minor issues, though, since you don't get the tab and tools links on the resulting page. This can in particular make it harder to work with deleted files (tracing usage or history, etc). One possible way to handle this would be to have the upload form actually appear inline on the Image: page itself, much like the edit form does, maintaining all the tab and toolbox links to the title. - -- brion vibber (brion @ wikimedia.org)

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJ9M8wRnhpk1wk44RAvr7AKC8E0zmJk5QEpoaE3DwxcRNzRQXbgCfThF9 BelrcJ7Ti0MuJQypFATwo6E= =r+ij -----END PGP SIGNATURE-----