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.