Last modified: 2011-01-25 00:33:22 UTC
At present, any image that is placed on a page using the [[Image:...]] syntax generates HTML output that includes a clickable link to the image page itself. For example, [[Image:Foo.jpg]] generates something vaguely like <a href="http://server/wiki/Image:Foo.jpg"><img src="..."></a>. Thumbnailed and framed images similarly include <a href="..."> links to the image information page, but the details are different. People sometimes want the <a href="..."> link to go somewhere else instead of to the image information page. For example, on [[en:Main Page]], people want the image associated with the featured article of the day to be a clickable link to the article, not a clickable link to information about the image. Please add new syntax such as [[Image:Filename.ext|link=[[Link to wiki page]]|more|options|here]] and [[Image:Filename.ext|link=[http: //link/to/external/page]|more|options|here]].
We are interested in getting this functionality added to Mediawiki as well. We will make a $25/donation to the Wiki drive when it is completed.
Just to note that I've got a half-finished patch for this, which I will probably attach for testing tomorrow. [ Or "mañana", as they say... :/ ]
(In reply to comment #2) > Just to note that I've got a half-finished patch for this, which I will probably > attach for testing tomorrow. [ Or "mañana", as they say... :/ ] Rowan, Excellent. Thx for keeping up on this.
Created attachment 61 [details] Limited and not-very-tested patch for 1.3 This feature is causing me to run into more problems than I expected, so sorry for the delay (as I said, "mañana"!) However, here is a patch which should add limited image-aiming functionality to a 1.3 release. I'm going to code a more complete version for hopeful inclusion in 1.4. This patch: * creates a new "magic word" (MAG_IMG_LINK) in Language.php, which recognises by default "link=" or "target=" as valid image parameters [incidentally, it fixes some broken handling of such magic words] * as long as the text of these links is valid as an internal page title, this will cause the image to point at that page * no special handling is made for non-existent pages * interwiki links *will* work, but this is currently the only way to link to an external page (I hope to have proper ext. links handled in the final feature, but they require wider changes to get right) * it should work for images with and without frame / thumbnail options selected; the "zoom" icon (magnifying glass) on thumbnails should still link to the image description page. Example use: * [[Image:Foo.jpeg|thumb|link=The article at the end of the link|Alt text]] * [[Image:WPLogo.png|frame|link=Wikipedia:Main_Page|Wikipedia is ace!]] ***THIS PATCH COMES WITH NO GUARANTEES WHATSOEVER*** I really haven't tested it very much, or thought about security implications, and it's now 3:30AM, so I don't intend to just yet. Feel free to test it yourself, but I make no guarantee that it is safe to use this on a live site. It probably is, but you never know.
Rowan, I have tested this briefly and it appears to work fine. I will be making the donation and I'll post a link here with some info on the donation. Thanks for your effort! Here's the donation, actually: Payment To Wikimedia Foundation, Inc. Oct. 2, 2004 Completed Details -$25.00 USD $0.00 USD
This patch does not provide any means to access the image description page. On GFDL wikis this is a potential problem. The revision history must be easily available.
(In reply to comment #6) > This patch does not provide any means to access the image description page. > On GFDL wikis this is a potential problem. The revision history must be > easily available. Yes, for the completed version of this patch I intend to implement the following behaviour: * if an image uses the |thumb| parameter, the existing "zoomicon" will continue to link to the description page (already implemented) * if an image uses the |frame| parameter, an additional icon (I propose an "i" for info) will link to the desc. (this should probably be displayed whether or not clicking the image also takes you there, for consistency) * if an image uses neither, but uses a |link=$1| parameter (i.e. is otherwise unframed, but clicking the image does not provide the info page), put it in a frame anyway with a message such as "<small>View image details and copyright status.</small>" where the caption would otherwise be (i.e. assume that the user did not intend a visible caption).
To include an image within a link to a specified page, like <a href="foo"><img src="bar.jpg"></a>. On mediawiki 1.3.9, this was possible as: [[en:Foo|[[Image:Bar.jpg]]]] On mediawiki 1.4beta5, this is rendered as if saying: <nowiki>[[en:Foo|]]</nowiki>[[Image:Bar.jpg]] I am running: Apache/1.3.33 Ben-SSL/1.55 (Debian GNU/Linux) (apache-ssl 1.3.33-3) Please change Hardware and OS to Any (currently PC/NetBSD).
(In reply to comment #7) > * if an image uses neither, but uses a |link=$1| parameter (i.e. is otherwise > unframed, but clicking the image does not provide the info page), put it in a > frame anyway with a message such as "<small>View image details and copyright > status.</small>" where the caption would otherwise be (i.e. assume that the user > did not intend a visible caption). There needs to be a way of disabling that. Perhape <nowiki>[[Image:whatever|link=...|noinfo|.. .]]</nowiki>. For example, on a page like [[meta:Template:WikipediaSister]], people want images that link to various places, but a "view image details" link would be inappropriate. Also, at [[meta:Www.wikipedia.org portal/Catherine]], the big round logo and the small bookshelf images should ideally appear just as raw images, without linking anywhere, without frames, without "enlarge" or "view image details" icons, but with alt text. It would be nice if we could say something <nowiki>[[Image:whatever|link=|noinfo|Alt text here]]</nowiki> to get something that translates to HTML as <nowiki><img src="whatever" alt="Alt text here"></nowiki>, without any <nowiki><a href="...">...</a></nowiki>.
Created attachment 293 [details] A slightly better patch, against 1.4 I've re-implemented the patch against 1.4, and also added some features to it. Current behaviour: * As with the previous patch, this includes the fix to bug 688, which really ought to have been checked in by now, but hasn't been. * To enable the feature, you need to set $wgAllowTargettedImages=true; in LocalSettings.php (This allows it, in theory at least, to be checked in, turned off by default, rather than people having to patch it themselves.) * Once enabled, it will recognise the parameters "link=..." and "target=..." in image markup (defined by the MAG_IMG_LINK entry in Language.php, override in LanguageXX.php as appropriate). * Anything that looks like an external link (as would be recognised by Parser.php) is linked to there *as long as it is followed by a space* - e.g. [[Image:Foo|link=http://example.com |foo]]. Without that, the "|foo" becomes part of the ext link, and everything goes screwy because the parser turns it into an HTML link. Eventually, I hope to be more sane, but right now image syntax isn't parsed in Parser.php, so it's mighty awkward. * Anything that looks like an internal page title is assumed to be one of those. * Anything else is just ignored. There is no way of linking to nothing, because I don't see the need for it. * This patch *does not* enforce an additional link for the description page, because that defeats the purpose many people will want to put this to. (Yes, I know that's a controversial attitude, but that's why I suggest it be disabled by default.) All feedback and testing welcome.
(In reply to comment #10) > There is no way of linking to nothing, because > I don't see the need for it. So, where do you think the big round logo at http://www.wikipedia.org/ should link to? Similarly with the word "Wikipedia" and the bookshelf images on that page. I think they shouldn't link anywhere. (And they currently don't link anywhere, which is possible because the page was written in HTML.)
(In reply to comment #11) > So, where do you think the big round logo at http://www.wikipedia.org/ should > link to? Similarly with the word "Wikipedia" and the bookshelf images on that > page. Hm, I guess you have a point there; maybe there *are* times when linking to nothing would be nice. Although I'm beginning to be a bit concerned that if the patch implements link to local page, link to external URL *and* link to nothing, all via one configuration switch, people are going to start wanting one without the others. But I guess in that case, they can just hack the code and comment out the bits they don't like... Unfortunately, this is a little more complicated an addition than it at seems at first sight, since we don't really want to link to "nowhere", we want to not link at all. I think I'll therefore go back and finish my larger rewrite (bug 689) before implementing that. In the meantime, you'll have to put up with every image linking *somewhere*, even with this patch.
Regarding the licensing, this is a non-issue if used responsibly and should be a matter of policy. To give an example, if the thumbnails on the Main Page point to the articles instead of the images, these articles include larger versions of the images, hence, the licensing information remains available.
If an image is explicitly linking somewhere, a link to the Image: description page should go into the image's longdesc attribute. This usage would closely follow the HTML standard and accessibility recommendations. Most browsers don't give access to the longdesc URL, but an interface could be provided using CSS and/or Javascript.
In a discussion on mediawiki-l, somebody proposed a quick hack of an extension for doing this - see http://meta.wikimedia.org/wiki/User:Sysy/Joshua_Oreman%27s_icon_extension
See www.enotifwiki.org and especially this extension (originally written by Brion) http://cvs.berlios.de/cgi-bin/viewcvs.cgi/enotifwiki/enotifwiki/extensions/ImageLink.php
Since the extension ImageLink did not exactly worked for me, and did not exactly satisfied me with the limited syntax, I came with a personal extension tested against 1.4.9 (should work with 1.5, too). http://meta.wikimedia.org/w/index.php?title=User:Jbennet/Navigational_images The principle is simple : it will substitute the target url of the generated image code, by the target URL of any other wiki code (e.g. [[My Page]] or [http...mysite/]). It allows you to specify any Image syntax, and any kind of destination, only with wiki code.
Magnus Manske suggested in a mailing list post that there could be a message shown on the target page, similar to the "Redirected from" one - something along the lines of "Information on the image you clicked is at [[:Image:$1]]". Of course, this is no good for images with external (or interwiki) targets, or with no link at all, but it's an interesting thought.
*** Bug 3330 has been marked as a duplicate of this bug. ***
Have any one requested image map yet? If no, I am doing it now. I have seen the encourage works here on image that link to article. Thank you all and keep it up. Now I am requesting that an image can link to several articles, depending on which region on the image we click. This is harder to edit by non-experienced, so it may be implemented on a different name such as [[ImageMap: ... ]] or <imagemap> ... </iamgemap> This would be so nice for the map (e.g. map of the world, when you click on each country, you get the article on that country, then click on the province in the map in that article, then you get to the province, and so on, ... ) on diagram of instrument (e.g. diagram of a car, when you click on ... well you get it by now), ... A donation of 20 euro to Wikipedia drive promissed for progress on this.
I've just noted that my comments is a duplication of Bug 1227
See also http://en.wikipedia.org/wiki/Template_talk:Click, which uses a weird CSS trick for achieving this.
Question: If we have this syntax for an image: [[Image:car.jpg|thumb]] And this syntax for an external link: [http://www.test.com/ This is a test] Then logically, wouldn't the syntax for an image that is also an external link be this? : [http://www.test.com/ [[Image:car.jpg|thumb]]] I've tried this, and unfortunately it doesn't work (and also the thumbnailing of the image is ignored).
(Patch was against 1.4, will now need to be against 1.6. Marking as obsolete and removing keyword.)
(In reply to comment #23) > Then logically, wouldn't the syntax for an image that is also an external link > be this? : > [http://www.test.com/ [[Image:car.jpg|thumb]]] No, because * it looks really ugly (and confusing to the user) * it would be a nightmare to parse correctly * what would [http://www.test.com/ [[Ordinary page]]] mean? ... or [http://www.test.com/ [[Image:car.jpg|thumb|Caption]]]? ... or, logically valid, [http://www.test.com/ [[Image:car.jpg|thumb|Caption with an [http://example.com external link]]]]? If this is implemented at all, it will be as an option inside the image markup specifying the target, not the other way around.
> If this is implemented at all, it will be as an option inside the image markup > specifying the target, not the other way around. Fair enough, that all makes good sense to me. I also think a link to nowhere (or rather, no link) would be very useful too. That's because I'd like to convert this: http://roubin.com/ into a personal wiki, so as to make it easier to update - but it uses images for internal links, for external links, and images with no links; It also uses image maps, but it doesn't strictly have to, although it'd be nice (but that's bug 1227). I figure if that page can successfully be made into a wiki page, and look & behave the same way as it does now, then most/all static text+image pages can.
Can't this be implemented simply by allowing span tags to have background: and padding: attributes? Then you can add a CSS background image to a link that appears as an icon next to it. Currently, they're stripped out on save.
That would be a simple solution, but implementing a special argument to the image syntax will keep the What Links Here feature working for image description pages. Also, CSS background images in the MediaWiki stylesheets (like [[MediaWiki:Monobook.css]]) don't always work: for [[vi:Tiêu bản:Sơ khai]], for example, the background image is a thumbnail of an SVG image at Commons. I have to periodically recreate that thumbnail, but upload.wikimedia.org gets rid of it from time to time.
That would be a simple solution, but implementing a special argument to the image syntax will keep the What Links Here feature working for image description pages. Also, CSS background images in the MediaWiki stylesheets (like [[MediaWiki:Monobook.css]]) don't always work: for [[vi:Tiêu bản:Sơ khai]], for example, the background image is a thumbnail of an SVG image at Commons. I have to periodically recreate that thumbnail, because upload.wikimedia.org gets rid of it from time to time.
*** Bug 5332 has been marked as a duplicate of this bug. ***
This feature is now necessary to do chemical structures linked to the article on the chemical compound, as described on [[en:Wikipedia talk:Wikiproject Chemistry]] and up to now handled through image redirect pages, but now failing b/c admin insists on image use tags on the image page (rather than its talk page), and this breaks the ability to use image redirects.
*** Bug 5573 has been marked as a duplicate of this bug. ***
A small note: the "manual thumb" feature allows you to link to different image pages, but not yet to anything outside of the image namespace. See "thumb=xyz" under [[m:Help:Magic words#Image modifiers]].
Really, clickable images should only be possible in the case of navigational images; templates or other similar "extensions" to the software. Encyclopedic images, like the ones found in article text, should never be allowed to be clickable, because of license and thumbnail functionality. Any solution that allows clickable images needs to take this into account. In effect, the images used in navigational templates and the like are actually part of the site's software instead of part of the encyclopedia text, and need to be licensed as such. (And things like the featured article star, admin mop, and the like should be implemented directly in the software with magic words or something; not CSS kludges.)
Previous comment is in regards to this current thread at TfD: [[w:Wikipedia:Templates for deletion/Log/2006 December 17#Template:Click]]. It'd be great if someone could create a better solution than Template:Click ...
In response to comment #34 .. I have a few ideas: 1) Well, since there is already a feature to allow mediawiki to understand the license terms of a new upload.. this feature could be implemented but restricted to the appropriate license fees. 2) Or if necessary a separate licensing dropdown selection could be made in the upload form.. and thus an image upload could be 'flagged' as available for use by this feature. 3) Either this, or some new feature has to be made: * The admin uploads images to a special directory. * These images are available via some kind of thing like <command link="http://destination">imagename.jpg</command>
MediaWiki doesn't understand what a licence is, per se; all it knows is that if a specific message is defined, it can parse that message to get a template name and a label for a combo box such that, when the upload form is submitted, depending on what's selected, the appropriate template is transcluded onto the bottom of the image description page. The licence isn't stored in metadata form at present. How about we work out an implementation, and trust people to be sensible about using it; communities leap on copyright infringement fairly well at present, so why can't we trust them to beat the living daylights out of abusers of this functionality, metaphorically speaking, of course?
http://www.mediawiki.org/wiki/Extension:ImageMap allows this
(In reply to comment #38) > http://www.mediawiki.org/wiki/Extension:ImageMap allows this So I will close this bug as FIXED
*** Bug 9059 has been marked as a duplicate of this bug. ***
*** Bug 9347 has been marked as a duplicate of this bug. ***
I found a "bug" in that extension. It doesn't have the ability to link to another part of the same page. I'm trying to get it going for this page: http://en.wikibooks.org/wiki/Paint.NET/Contents/Tools This is a short version of my code: <imagemap> Image:Pdntoolsmenu.png rect 9 26 20 37 [[Paint.NET/Contents/Tools#Rectangle_Select|Rectangle Select]] desc none </imagemap> What happens is that it just discludes "#Rectangle_Select" in the url. Is there a workaround for this, is this fixable, or is it just hopeless? If it is hopeless, I may just make separate pages for the tools (there's a lot of info on each one of them).
(In reply to comment #42) > I found a "bug" in that extension. It doesn't have the ability to link to > another part of the same page. I'm trying to get it going for this page: > http://en.wikibooks.org/wiki/Paint.NET/Contents/Tools > > This is a short version of my code: > > <imagemap> > Image:Pdntoolsmenu.png > > rect 9 26 20 37 [[Paint.NET/Contents/Tools#Rectangle_Select|Rectangle Select]] > > desc none > </imagemap> > > > What happens is that it just discludes "#Rectangle_Select" in the url. This is bug 8917 and fixed now with r21299.
This can be done with the imagemap extension. <imagemap> Image:myimage.jpg default [[page title]] </imagemap> It will create an imagemap where the entire image "myimage.jpg" links to the page "page title". There is an information icon that will be placed in the corner of "myimage.jpg" that links to the image's information page. It will also work with external links (if external links for imagemaps are enabled) and for headings on a page (as noted in the previous comment by Raimond). I guess this bug can be closed.
Bug 9059 was marked duplicate of this, for whatever reason. It probably makes more sense to keep that open and separate.
*** Bug 10168 has been marked as a duplicate of this bug. ***
I've closed this as fixed per comment #39 and comment #44.
Isn't this bug about getting this capability in MediaWiki without using an extension?
What's wrong with adding the feature through an extension? It's easy to install, not needed on most wikis, and already enabled on all Wikimedia wikis.
The expected syntax, [[Target|[[Image:Picture.png]]]], doesn't work. That was the original intent of this bug. That feature should be in core, and can only be fixed in core in any case. Image maps are a workaround for this, and can stay out of core.
I kept the bug open because I felt that a slightly easier syntax for the straight case this bug asks for might be more desirable. If you feel that the syntax used by the extension is good enough, feel free to close as fixed.
*** Bug 12114 has been marked as a duplicate of this bug. ***
There are two major issues with imagemap: It does not evaluate parameters and it is only an extension. Would it be this difficult to look up for a parameter "link"? I think one could even do it without square brackets for simplicity.
Just to note that I counted about 17,000 pages on the main article namespace that transcludes [[Template:Click]] in the English Wikipedia (this is a rough estimate by counting how many 500-entry pages the following query returned): http://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Click&limit=500&namespace=0 I think that is quite a lot of pages, for a wiki with such a strong policy of enforcing image links to lead to the image description page. I have also seen many bot user pages with the "red panic button" using the CSS hack to redirect to the Special:Blockip. I think that both arguments, for allowing and for disallowing image links to arbitrary pages, are very strong, and we may think about some kind of solution that aids both needs. I propose a namespace-whitelist for such special feature. If the [[Image:...]] link is expanded within a page in -- or transcluded from -- a whitelisted namespace, it allows the image to link somewhere else, otherwise, the current behavior is kept. So, for Wikipedia, since this feature is demanded only for some templates, NS_TEMPLATE would be the only whitelisted namespace (or, perhaps, NS_MEDIAWIKI). For other wikis, their administrators have the option of whitelisting the main namespace (and this includes www.mediawiki.org, where there are three big clickable images right in the main page using the [[Template:Click]] hack).
Fixed by Tim in r41727.
I believe this to be quite problematic, as there are major copyrights issues here: When an image is used that requires attribution, it *must* link to the description page of the image, otherwise it's a copyright violation. There should be at least the desc image (blue i) on one of the image corners that links there (that's what is being used for Extension:ImageMap). (Please forgive my ignorance if this is already the case)
(In reply to comment #56) > When an image is used that requires attribution, it *must* link to the > description page of the image, otherwise it's a copyright violation. For images with these constraints, you should use other means of enforcing that it doesn't contain the new click= parameter. Note that nothing blocks you today from making the image page inaccessible, there is [[Template:Click]] ready for you to use, but using it for the wrong purpose will probably cause your changes to be quickly reverted by someone else. With this change, the same policy today applied for the use of [[Template:Click]] will be applied also for the click= parameter. Nothing changes in this regard, and for the valid uses, we will avoid annoying and ugly hacks.
Any reason to use 'click' instead of 'link'? (Particular when 'no-link', not 'no-click', suppresses the link.) (In reply to comment #56) > I believe this to be quite problematic, as there are major copyrights issues > here: > When an image is used that requires attribution, it *must* link to the > description page of the image, otherwise it's a copyright violation. That's actually not true: 1) Attribution usually requires a name or reference to the original author -- this is often not going to be the image description page URL (though it might be *on* the image description page). 2) Attribution could be included another way, such as putting it in a caption or a list of credits. 3) As is, a printout of a page containing an image would fail to include any visible reference to the description page. Unlike inline URL references, these are not currently expanded on printout. > There > should be at least the desc image (blue i) on one of the image corners that > links there (that's what is being used for Extension:ImageMap). (Please forgive > my ignorance if this is already the case) This would interfere with the primary requirement -- using certain images as navigational elements. My recommendation remains adding some sort of image credits caption list; this should definitely be done for printable pages, but could include on-screen credit footers for images like this anyway. Currently we don't really have good metadata for attribution requirements; the minimum would be to add links to the description pages for now (which presumably have the rest of the data.)
(In reply to comment #58) > Any reason to use 'click' instead of 'link'? (Particular when 'no-link', not > 'no-click', suppresses the link.) > I totally agree! I think Tim did so because people are used to [[Template:Click]]. You really could rename (or copy) 'click' to 'link', but do so before r41727 goes live (if possible), as people will use 'click' instantly when the long awaited feature is finally available ;-)
In r41789, changed from 'click' to 'link' and added 3 parser test cases.
This doesn't seem to work properly. See test cases at [[w:en:Wikipedia:Images linking to articles]]. When used with a caption, the link is to the wrong target; and when ued without a caption, the alt text and title text are wrong.
I believe you're referring to [[bugzilla:16912]]. Re-marking this as RESOLVED FIXED. Please file a new bug for any further issues.
Bug [[bugzilla:17398]] filed.
