Last modified: 2014-11-04 22:53:13 UTC
Two changes are needed, primarily: 1) During file uploads, throw an overwrite warning if the image exists in the commons. 2) If the upload replaces a commons file, add the text "An alternative copy of this image exists in the shared upload repository" or something similar.
I would add: 3) ability to explicitly refer to the commons version ("[[commons:Image:Foo]]" or similar); without this, (2) is only partially useful.
*** Bug 1666 has been marked as a duplicate of this bug. ***
I'm upgrading this image from an enhancement to normal severity. Users uploading images to Wikipedia with the same name as an image on Commons can cause a lot of disruption on articles that use Commons images. We either need a way to explicitly include the Commons version of an image (right now we can only explicitly link to them) or we need to prevent images on Wikipedia from overwriting Commons images. There's no point to moving images to Commons if this problem isn't fixed; moving the images just creates more difficulties.
We already prevent images on Wikipedia form overwriting Commons images. Only sysops can do it, and I think there's a warning displayed for them.
Ah, I'm a sysop, so I didn't see that regular accounts can't overwrite Commons images. However, there is no warning displayed for sysops, which is why I didn't realize it in the first place. Should I file it as a seperate bug? Once there is a warning, this bug can be closed.
not really, there is still the issue of existing images that the commons uploader is unaware of and existing conflicts to REALLY close this issue we need a way to reference the commons image even when there is a local image of the same name.
I would rather propose to *prevent* name collisions between the commons and the local images. KISS principle. Besides this, I think we should have a way to rename images, both on commons and on single wikis, and a well-done image naming policy. It is a mess now, as we have names such as asuslogo, AsusLogo, asus_logo1, as187whoknowsm etc; and these are all things which cause error and waste of time for everyone. The reason for supporting image renaming and a naming policy is maybe better illustrated with an example: let's say I upload, an image named origami.jpg to en.wikipedia while an image with the same name exists on commons. On receiving the warning I go to commons and see that the image showed there is about the Microsoft ultra mobile PC, while mine concerns the paper-folding art. There should then be an unambiguos way to decide what to rename and how; it could be origami (paper folding)/origami (umpc) or origami/origami (computer) or anything else (the example is purely illustrative, it's obvious that "origami" is such a generic name that it is obviously inappropriate for the image of a particular origami example). Maybe we could just enforce that all (and only) image from commons have a name beginning with "common_" I don't object to having a syntax to specify that the image is from commons, but I don't support the use of "namespaces", so to speak. IOWs, common::name would just be an alternative to common_name.
(In reply to comment #7) > common::name would just be an alternative to common_name. Is there a difference between the two punctuation marks? The latter, since MediaWiki treats underscores as spaces, would incidentally prevent any non-Commons image to be identified by anything beginning with the word "common" (which is a fairly, well, common word), and would also mess up localization (since the prefix would be added centrally at the Commons rather than a "virtual" namespace being added locally at each project). As for moving, that's Bug 709. You can try voting for it if you like.
Commons should likewise indicate impending name collisions with e.g. images on any of the local projects (Wikipedia, Wikibooks, etc.). If we can check usage globally (http://tools.wikimedia.de/~daniel/WikiSense/CheckUsage.php), we ought to be able check for those collisions. I also agree with the first sentence of Gennaro's comments.
Fixed in r33972.
