Last modified: 2014-11-17 10:34:57 UTC
Files on the Wikimedia commons are visible to all projects -- however, the what-links-here on Commons' image pages only lists instances where it is used on Commons. Ideally, on the commons, what-links-here should list all pages where an image is used across all the various projects.
The absence of this feature makes any modification (such as deletion, replacement, renaming) of material on Commons nigh unto impossible to accomplish safely, as images may be in use at any project at any time and there is no method to determine this.
I think this bug should be considered a top priority at the moment. We're leaving broken image links scattered across all the wikis every time an image is deleted on commons.
On travaille dans le brouillard, ajoutez cette fonctionnalité svp : "pages liées" doit lister les articles qui utilisent le média dans tous les wikis (pédias, books, etc)
Until this bug is resolved, you may use http://www.juelich.de/avatar/check-usage/ prior to deleting/moving images in commons.
Note: As far as I know "Special:Whatlinkshere" is allways empty. In other namespaces "Special:Whatlinkshere" relates to the page. What we see on the image description page is where the image is used but not where is refered *inline*. Inline image links are / where always *blue* and did neither indicate the presence of the description page nor that of the media. Red links apear only if you *include* an image which does not exist. The image talk page behaves "normal". The consequences of this is that if you delete an image you can not detect this *only* with a link (on your user page). Regards Reinhardt [[user:gangleri]]
No there is no problem with inlines (I assume you meant [[:Image:Image.jpg]]). Pages with images links beginning with : are also refered at the bottom of an image description page (I wish it wouldn't) like a page with a normal [[Image:Image.jpg]]. Check-Usage gives you all usage of an image by looking at all the local image pages of an image out of the Commons and evaluating the HTML-Code. Not a very nice technical solution but it works... ;-)
In response to comment 6 Please see [[http://commons:User talk:Gangleri#bugzilla:1394]] http://commons.wikimedia.org/wiki/User_talk:Gangleri#bugzilla:1394 I tried Check-Usage for [[Image:Himalayas.jpg]] see [[en:User talk:Gangleri#bugzilla:1394]] and [[commons:User talk:Gangleri#bugzilla:1394]] I was not able to find these inline links. Is there a delay? Are you checking *online*? Regarding http://commons.wikimedia.org/wiki/User_talk:Avatar/Check-Usage please provide the parameter syntax. Then it could be used as a interwiki prefix "checkusagelocal" searching {{SITENAME}}. Regards Reingardt [[user:gangleri]]
I think Daniel is wrong if he states "No there is no problem with inlines (I assume you meant [[:Image:Image.jpg]]). Pages with images links beginning with : are also refered at the bottom of an image description page (I wish it wouldn't) like a page with a normal [[Image:Image.jpg]]." I just tested it with [[Image:Himalayas.jpg|thumb|...]] and afterwards with [[:Image:Himalayas.jpg]] on my german user page. The second wasn't listed and won't be found by check-usage. (I deleted the tests. Here is a typical check for Himalayas.jpg on all listed projects: http://www.juelich.de/avatar/check-usage/check-usage.php?saved=0O1Q6tk-x9 It will find pages, where the picture is used, but not pages including links with a colon-prefix). There is no-delay. Check-Usage is running online. It parses the "Image links"-section beneath the Media on the Media Description page. It does not interfere with the 'What-links-here'-page. I can tell you the actual parameter syntax, but it won't be good to use it, because I'm still working on it and it's possible, that a few things will change: filename = string. "search for ..." wp[] = array. including projects to be checked (everything before the .org) output_form = can be plain (show article-names) or paste (show articles enclosed in brackets with starting colon) Example: http://www.juelich.de/avatar/check-usage/check-usage.php?filename=Himalayas.jpg&wp[]=en.wikipedia&wp[]=de.wikipedia&output_form=plain
note: comment 6 is described in bug 1850: broken links to images should be red
addition to comment 5 (comment 6 and comment 7) "As far as I know "Special:Whatlinkshere" is allways empty. In other namespaces "Special:Whatlinkshere" relates to the page." "What we see on the image description page is where the image is used but not where is refered *inline*." compare with bug 85: "What links here" image links are nonexistent until the pages linking to the image are edited and its duplicates: bug 97: "What links here" on images seems to be completely empty bug 136: "What links here" on images seems to be completely empty which deal with normal linking (inclusion) not with *inline* linking
bug 360: what links here doesn't work for image: seems to be a duplicate of this bug
(In reply to comment #11) > bug 360: what links here doesn't work for image: > seems to be a duplicate of this bug No; this bug (as I understand it) is specifically about the Commons, and the fact that because the images are in a different database, usages of an image on another site don't show up. I think there's much confusion because of the phrase "what links here" - the main problem is the list of "File links" on the description page, which show what pages directly include the file in question; the "what links here" page shows links to the *description page*, which are less likely to be important. I'm changing the summary to say "file links" rather than "what links here" for that reason.
Anyway Duesentrieb coded a replace. Bug should be set to CLOSED. Marco
Duesentrieb's 'check usage' tab fulfills exactly the function needed when I filed this bug.
Toolserver sometimes-working non-core tools should *not* be considered replacements for feature requests for MediaWiki. What we really want is a proper solution.
This is still unresolved as of MW 1.9.3. I agree with James F., this should be considered a feature request, not 'how do I workaround this problem.' I can only imagine this will need to be a new table in the database schema which would maintain information about interwiki transclusion of files. (As an aside... is there a bug for this same issue, but regarding article pages (whatlinkshere), instead of 'file links'?)
Changed name to reflect that this is a feature request for MediaWiki, not a fix for Commons...
Just filed related feature request at: http://bugzilla.wikimedia.org/show_bug.cgi?id=12830 .
I started some work on this as an extension: <http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/GlobalUsage/> It is not nearly complete, but should do something under certain circumstances. It creates a new table globalimagelinks on the shared image repository. Some things that still need to be done: * Implement a hook FileDelete * Look how this is going to work when APIEdit is implemented (some hooks are not called) * Get the interwiki to work actually * How is undeletion handled In particular the last item is a problem. When a file is deleted on Commons, the globalimagelinks table will not be updated. This means that at undeletion all wikis should be queried, which is not a good idea with 750 wikis. Also one of the more useful features of CheckUsage is that one is able to see the image usage after deletion. This extension currently deletes items from the globalimagelinks table when an image is deleted.
Updated code update the links on links update, article deletion, file deletion, file undeletion, upload, article move, which were all the actions I could think of that change the image links. Needs review, shiny interface and API module.
(In reply to comment #20) > Needs review, shiny interface and API module. You're still talking about that extension (GlobalUsage), right? Drop me an e-mail after the reviewing and testing is done, and I'll work up an API module.
I did some work on this, and optionally $wgServerName can be used instead of $wgLocalInterwiki. This should solve the problem that it is currently not possible to resolve all Wikimedia wikis via interwiki links. I also added a script that populates the globalimagelinks from a local imagelinks table and continues to update the table from recentchanges. This should ensure that a consistent globalimagelinks table is built. I tested this script on the toolserver and it appears to actually work. It takes quite some time to run this; about 7 hours for ptwiki.
Deployed GlobalUsage and currently running seeding script.
