When a media file is used in a property it should show up as used on the image page on commons and on commons:Special:GlobalUsage. This way it can be taken into account when images are moved and renamed.
Version: master
Severity: normal
When a media file is used in a property it should show up as used on the image page on commons and on commons:Special:GlobalUsage. This way it can be taken into account when images are moved and renamed.
Version: master
Severity: normal
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T66794 Delinker should delink and replace images on Wikidata too | |||
Resolved | None | T48358 Wikidata properties linking media should show up in GlobalUsage | |||
Resolved | hoo | T46727 [Story] Statement should show a thumbnail for image/video/audio properties | |||
Resolved | hoo | T192869 Image link should link to Commons and not local file | |||
Open | None | T219226 See the details of the thumbnails while editing a Wikidata entity |
I'm dubious about this. Global usage is about image inclusion. It doesn't count links to the image page either. The data item (currently) doesn't show the image, it doesn't even link; It's just a string...
I see the intention, but we have to make sure we stay consistent. So this needs a little bit of thought and discussion.
Note that any *actual* inclusion of the image on a wikitext page, using the file name from the data item, will already show as global usage.
The issue is that when an image is called through a property the usage shows at the wiki in question. However, when global replacements are taking place, and that usually starts at Commons, the change needs to take place at Wikidata, however, no indicator that the change needs to take place at WD. Certainly makes replacement a lot harder, hence maintenance problematic.
Is there the potential for a new subsection to global WhatLinksHere? This would also be useful for sites like Wikisource, where a bust or painting may be mentioned in a work, so a wikilink is added to the work but not a display of the image.
Bryan.TongMinh wrote:
For consistency, inline links should definitely not be tracked in globalimagelinks, but in a global version of pagelink.
One could look on it in from a non-technical point of view (eg. is it a inline link or not). Each project may have its own "main use case". On Wikipedia, a file is being used if it is displayed. But on Wikidata, it is only truly used for the projects purposes if it is in a statement. In that sense, one can say that it fulfills the intention of the GlobalUsage and thus should be listed on Commons. However, if 44727 is fixed I guess this will resolve this issue as well, am I right?
Gerard.meijssen wrote:
One of the use cases of Wikidata is Reasonator.. It does show the images, the range maps, the coats of arms.
The question therefore is how the use of images is considered when used by Reasonator.
Thanks,
GerardM
There is a request on Commons for deleted images to be removed from Wikidata statements, see https://commons.wikimedia.org/wiki/Commons:Village_pump#Deleted_images_on_Wikidata . I guess this is another usecase related to this bug, which was not discussed before.
To clarify, this should be classified as a major regression in terms of maintenance from the community.
Even to the point where I'm fairly confident that the would-be-required maintenance will not happen as it is an unreasonably large amount of work, and as such will leave a trail of broken images behind in an ever growing fashion.
Right now we have CommonsDelinker which watches deletions by Commons admins (and iterates through all local usage pages and attempts to find the relevant wikitext and removes it). It also has a feature to do a global replace of one file for another.
If projects start to move information like file names for logos of companies or the primary portraits of people etc. into Wikidata, then this will no longer work. As a result, any rename or deletion that happens at Commons will result in chaos. CommonsDelinker is sufficiently integrated that Commons admins generally don't have a concept of updating links or fear of breakage.
I have no idea what the proper implementation would be, but, as a community member, I strongly urge wikidata is not to be used for image information in any major way until this is resolved. The traditional "I don't care how" applies. It's an unfair and messy environment, but this burden should not be placed on the community.
(If not already, I imagine it is a prerequisite to have a value type for "file name", which can be validated according to page title restrictions and even auto-completed based on search).
I consider an image claim usage of the image. The software already updates the pagelinks table when someone adds a claim, it shouldn't be too difficult to use the same logic to update the imagelinks table and globalusage.
Is anyone working on this? I assume Daniel is voicing his personal opinion and not that of the team. Wouldn't be very nice for a volunteer to implement this and than getting -1's because there is a conceptual different opinion.
My hope is that we will solve this with showing the actual images in the new design being worked on.
appears fixed, since we now register commons media value usage as a link in the parser output, e.g.:
https://commons.wikimedia.org/wiki/Special:GlobalUsage/Loews_Cineplex_Times_Square_Banner.jpg
Uh, what? Nice! Any link to the change set that fixed this?
Did anyone think about doing a purge server side? Take for example https://commons.wikimedia.org/wiki/Special:GlobalUsage/Grote-Kerk-Haarlem.jpg , it's used at https://www.wikidata.org/wiki/Q1545193 , but that item hasn't been edited for several week. The item doesn't show up in the usage now.
https://gerrit.wikimedia.org/r/#/c/155896/ is the patch
I am not sure about doing a purge but maybe there could be a maintenance script or something to get these populated...
(In reply to Aude from comment #17)
https://gerrit.wikimedia.org/r/#/c/155896/ is the patch
I am not sure about doing a purge but maybe there could be a maintenance
script or something to get these populated...