Last modified: 2010-05-15 15:33:09 UTC
Links to images (non-inlined, like [[:Image:something.png]]) should be red if the image does not exist. This would make life easier in discussions and work lists, esp. to be able to see if an image has already been deleted. Also, the current behaviour is inconsistent with the representation of other "broken" links. Presumablly, the trouble with this is that it is unclear if this should test for the existence of the image or the image description page. Images that are used from the commons often don't have a description page - should links to those be considered broken? It would probably be best to check for the image, not the description page. But that may be quite slow, as it requires a lookup on the filesystem, possibly on a different box. Alternatively, one could query the image table of the commons database, that would probably be more efficient. This seems to be related to the question about how to find out on which wikis a commons-image is used, and, in reverse, to find out which commons-images a specific wiki uses. The first is important for maintenance, the second for creating dumps.
I think the links should at least be red if shared upload is disabled - i.e. on the Commons, for example - that would be very useful.
From bug 1702 comment 1 (2005-04-21) : > In CVS HEAD for 1.5, Image: links to nonexistent files now produce a red link which goes to the upload page. In the 1.5alpha versions, :Image: links to nonexistent files are still blue.
Created attachment 635 [details] HEAD patch for parserTests.txt Patch to parser tests for the Image and :Image cases.
(Set a three-keyword combo for previously attached parsertest patch.)
*** Bug 2782 has been marked as a duplicate of this bug. ***
*** Bug 2853 has been marked as a duplicate of this bug. ***
Removing patch keyword since there's not an actual fix patch yet.
This is fixed in 1.5, is it not? Can we close this now since 1.4 is coming to its end?
(In reply to comment #0) > Links to images (non-inlined, like [[:Image:something.png]]) should be red if > the image does not exist. This would make life easier in discussions and work > lists, esp. to be able to see if an image has already been deleted. Also, the > current behaviour is inconsistent with the representation of other "broken" links. > > Presumablly, the trouble with this is that it is unclear if this should test for > the existence of the image or the image description page. Images that are used > from the commons often don't have a description page - should links to those be > considered broken? It would probably be best to check for the image, not the > description page. But that may be quite slow, as it requires a lookup on the > filesystem, possibly on a different box. Alternatively, one could query the > image table of the commons database, that would probably be more efficient. > > This seems to be related to the question about how to find out on which wikis a > commons-image is used, and, in reverse, to find out which commons-images a > specific wiki uses. The first is important for maintenance, the second for > creating dumps. What was the original issue: Should the *inline* links (as [[:Image:foo.png]]) be red? These are also used in discussion pages. This is *not* the case. Should the image inclusions (as [[Image:bar.png]]) be red? This is the case. > Presumablly, the trouble with this is that it is unclear if this should test for > the existence of the image or the image description page. This realy is the case: a) The existance of the file ({{ns:Media}}) can *be* seen / detected by referencing to the media namespace. b) However the existence of the description page ({{ns:Image}}) can *not* be detected. To me this is *inconsistent* to the existence of pages in other namespaces. See http://yi.wiktionary.org/wiki/user:Gangleri/tests for examples. regards reinhardt [[user:gangleri]] P.S. probably *crosswiki* should be added as keyword because the existance of a file on a common media server is a crosswiki issue
see http://commons.wikimedia.org/w/index.php?title=User:Duesentrieb/Test&action=history The example was always about *inline* links. This is *not* fixed / activated at WikiMedia projects until today.
Are you therefore saying that the bug, as reported, is fixed in CVS HEAD? It's still present, IIRC, in the 1.4 and 1.5.x branches.
Fixed in HEAD. Currently these will show an edit link, not an upload link; this is consistent with other _page_ links and also: [10:12pm] Bdka: brion_away, [[:Image:foo]] is *mainly* red because an image was deleted, and therefore it should show an edit link that users can easily get the infos on deletion imo Additionally such links will start showing up in Special:Whatlinkshere where they were formerly just ignored; cf bug 360.
Apparently the fix to this bug created a new bug. See http://en.wikipedia.org/w/index.php?title=Arapahoe_County%2C_Colorado&action=history. The edit summary for the December 4 edit links to [[Image:Map of Colorado highlighting Arapahoe County.svg]]. It uses a red link, presumably because the image doesn't exist on EN, but only on the Commons.
The link text should not be red if the linked file exists on commons. This bug fixed has created a rather unfortunate situation with the music template, which (in order to fullfill attribution requires in copyright licenses) automatically links to the image page of the linked image. For example: http://en.wikipedia.org/wiki/Beethoven#Media - almost all the info links are now broken.
Ok, fixed to force-blue if the file is present, even if there's no local page.
Commons image links are still red in edit summaries in page histories. See http://en.wikipedia.org/w/index.php?title=User:Dbenbenn/sandbox&action=history for example.
An additional workaround to handle blue links to deleted files in the aim of transparency (after history info of deleted revisions is no longer displayed) is to edit [[MediaWiki:Noimage]]. Simply add two links to the deletion logs of the specific project and to the shared repository. See for example: http://de.wikipedia.org/w/index.php?title=MediaWiki%3ANoimage&diff=12423454&oldid=7353141
I noticed that an image that doesn't exists is linking directly to the uploadpage now, instead of a page with the MediaWiki:Noimage text. On the Dutch Wikipedia we have there like de.wikipedia some links to the deletion logs. But for now it links directly to the uploadpage, so it is very difficult to examine the reason of a deletion by a user. I think it has to do with this bugfix of Magnus Manske with the log message: (bug 1850) Image link to nonexistent file fixed. http://article.gmane.org/gmane.org.wikimedia.mediawiki.cvs/11472 But here on this bugpage there is no comment by Magnus where he explains this solution and why. I think it is much better to link to the Mediawiki:Noimage text, because there is also an upload link if the user wants to upload the image, and the user can there simple retrieve the reason of deletion.
(In reply to comment #18) > I think it is much better to link to the Mediawiki:Noimage text, because there > is also an upload link if the user wants to upload the image, and the user can > there simple retrieve the reason of deletion. Maybe yes, maybe not. But this bug has been fixed, because the original description is no longer true. (Non-inline links to missing images / image description pages currently _are_ red, marked as broken.) If you want a change in the behavior, create a new bug report or feature request (possibly requesting a configuration variable to control that). Changing back to RESOLVED FIXED.
