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
On 4/16/07, Tim Starling tstarling@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. :)
On 4/17/07, Tim Starling tstarling@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]]
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
On 17/04/07, Steve Bennett stevagewp@gmail.com wrote:
On 4/17/07, Tim Starling tstarling@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]]
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]].
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
On 4/17/07, Brianna Laugher brianna.laugher@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
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@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@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
Steve Bennett wrote:
On 4/17/07, Brianna Laugher brianna.laugher@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.
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
-----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]].
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.
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)
On 4/17/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 17/04/07, Steve Bennett stevagewp@gmail.com wrote:
On 4/17/07, Tim Starling tstarling@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:
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]].
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
John Vandenberg wrote:
On 4/17/07, Brianna Laugher brianna.laugher@gmail.com wrote:
On 17/04/07, Steve Bennett stevagewp@gmail.com wrote:
On 4/17/07, Tim Starling tstarling@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:
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:.
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]].
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?
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.
No.
-- Tim Starling
On 4/17/07, John Vandenberg jayvdb@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
On Apr 17, 2007, at 1:03 PM, Simetrical wrote:
On 4/17/07, John Vandenberg jayvdb@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,
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@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
On 4/17/07, Jim Hu jimhu@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
On 4/17/07, Tim Starling tstarling@wikimedia.org wrote:
[[download:Foo.doc|Click here to download the text as an MS Word document]]
Or, we could keep the syntax and do what we did with images/tumbnails: * [[media:stuff.avi|text]] is a text link to the medium page * [[media:stuff.avi|thumb|text]] is a thumbnail (for video) or icon (for audio etc.) link to the medium page * [[media:stuff.avi|download|text]] is a text link to the medium file (direct download) * [[media:stuff.avi|play|text]] is a player * [[media:stuff.avi|play|start|text]] is a player that starts automatically
Magnus
Magnus Manske wrote:
On 4/17/07, Tim Starling tstarling@wikimedia.org wrote:
[[download:Foo.doc|Click here to download the text as an MS Word document]]
Or, we could keep the syntax and do what we did with images/tumbnails:
- [[media:stuff.avi|text]] is a text link to the medium page
- [[media:stuff.avi|thumb|text]] is a thumbnail (for video) or icon
(for audio etc.) link to the medium page
- [[media:stuff.avi|download|text]] is a text link to the medium file
(direct download)
- [[media:stuff.avi|play|text]] is a player
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
Tim Starling wrote:
Magnus Manske wrote:
On 4/17/07, Tim Starling tstarling@wikimedia.org wrote:
[[download:Foo.doc|Click here to download the text as an MS Word document]]
Or, we could keep the syntax and do what we did with images/tumbnails:
- [[media:stuff.avi|text]] is a text link to the medium page
- [[media:stuff.avi|thumb|text]] is a thumbnail (for video) or icon
(for audio etc.) link to the medium page
- [[media:stuff.avi|download|text]] is a text link to the medium file
(direct download)
- [[media:stuff.avi|play|text]] is a player
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
On 17/04/07, Gurch matthew.britton@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
On 17/04/07, Tim Starling tstarling@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
On 18/04/07, Rob Church robchur@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
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.
On 4/26/07, Nick Jenkins nickpj@gmail.com wrote:
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.
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
On Fri, Apr 27, 2007 at 02:47:23PM +1000, Steve Bennett 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)".
And that's the funniest thing I've read all day. Thanks, Steve.
Cheers, -- jra
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.
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
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.dj...
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.dj...
This is what it's meant to do:
http://commons.wikimedia.org/wiki/Image:Marchez_pendant_que_vous_avez_la_lum...
File a bug report.
-- Tim Starling
-----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.
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.
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)
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.
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.
...but that file already existed. Seems i had to check djvu support with the only broken file. Disregard it.
wikitech-l@lists.wikimedia.org