Last modified: 2012-12-19 14:05:12 UTC
Currently, non-sysops cannot upload images to a local wiki if that image is already uploaded on Commons. This is good. We should, however, do the same thing for the image descriptions. That is, there is no reason for, say, the English Wikipedians to edit the local image description of an image that is stored on Commons. The whole idea of Commons is to be multilingual and the free image HQ for all wikis, and local descriptions collide these goals. Also worth considering is that Image description pages, especially for those on Commons, are very loosely watched, and are many times used to vandalize or by unexperienced editors who think that's the place to discuss the image. All edits to a description of an image on Commons should logically be made on Commons.
The implementation for this would be interesting; it would need to check if there's a commons image and is not overwritten by a local image (already done). However, would edits to the local Image: page be disabled, or would they be automatically redirected to the Commons:Image: page? The second might be doable after Bug 57 / SUL is implemented, but it might not be advisable until then.
I don't see a problem with simply disabling them. Does anyone else?
As this is a method of vandalism frequent on eswiki, it might be prudent to disable edits in the Image: namespace altogether; however, I'm still unsure as to what to do about the Image talk: namespace. I'm not sure those should be disabled, but rather forwarded to commons, and a new user would be confused as to why his account does not exist after just clicking on a link.
(In reply to comment #2) > I don't see a problem with simply disabling them. Does anyone else? Hmm, do you really want to see _all_ local translations for images like [[Image:Robal.png]] alltogether on one page on Commons? Of course, it might be no big problem for English projects at the moment, but it is one for other, especially smaller, languages. Unless we'll have a real multilingual interface for file descriptions on Commons, that only displays a user's (or a default) language out of the full range of given translations, this request is not reasonable in general. You may request disabling ns:6 and ns:7 for single projects, preferably after closer discussion within the community. That should be no problem.
(In reply to comment #4) > Hmm, do you really want to see _all_ local translations for images like > [[Image:Robal.png]] alltogether on one page on Commons? Yes. why not? (Besides which, very few images need that much translating, and very few even have that many translations) Are you saying that some communities put caption/description translations on their local shadow pages instead of on the Commons page? :o That is surely very bad. Then people of that lang community won't see the caption when they are casually browsing the Commons.
(In reply to comment #5) Commons has many more images like the one given above – not only "very few", and we've got 200+ languages >:o In theory, we want to store all these descriptions directly on Commons, of course (also to be able to use better, still unknown features in the future, I know). But at the moment and in fact a lot of translations are stored on local pages (if we like it or not), not only because non-english users often feel unwanted on Commons. Note: The biggest objectors against "overflowing" descriptions commonly are the original authors who don't want "their" precise and short descriptions to be stuffed with 10 or more translations, so that external users of a file have problems to find out the important facts for reuse at first glance (they claim that clutter produces copyvios). Anyway, discussion should better be resumed on local projects IMO.
In some future day when multiple language data can be more conveniently stored side-by-side on Commons itself we may reopen this dicsussion.
[Removing RESOLVED LATER as discussed in http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064240.html . Reopening and setting priority to "Lowest".]
WONTFIX is the current solution.
