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.

zigger wrote:

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.

zigger wrote:

HEAD patch for parserTests.txt

Patch to parser tests for the Image and :Image cases.

Attached:

zigger wrote:

(Set a three-keyword combo for previously attached parsertest patch.)

zigger wrote:

*** Bug 2782 has been marked as a duplicate of this bug. ***

zigger wrote:

*** Bug 2853 has been marked as a duplicate of this bug. ***

Removing patch keyword since there's not an actual fix patch yet.

webmaster wrote:

This is fixed in 1.5, is it not?
Can we close this now since 1.4 is coming to its end?

gangleri wrote:

(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

gangleri wrote:

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.

robchur wrote:

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.

dbenbenn wrote:

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.

mapellegrini wrote:

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.

dbenbenn wrote:

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.

wiki.bugzilla wrote:

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

jepe wrote:

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.