-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Clements schrieb:
I don't know if anyone has any suggestions to deal with this kind of problem, or even if it has already been recognised as an issue. The non-technical answer is, of course, to copy the commons images to the local wiki, but that kind of defeats the point of commons, doesn't it?
We have the CheckUsage tool on the toolserver and every admin should check the usages _before_ deleting an image. If there are (more or less) prominent usages, at least at non user/user talk pages, he shouldn't delete the image or previous replace all usages with the duplicate image.
I know, it's a lot of work
Exemptions are copyvios.
Raymond.
On 4/30/07, Raimond Spekking raimond.spekking@gmail.com wrote:
We have the CheckUsage tool on the toolserver and every admin should check the usages _before_ deleting an image. If there are (more or less) prominent usages, at least at non user/user talk pages, he shouldn't delete the image or previous replace all usages with the duplicate image.
I know, it's a lot of work
This doesn't work for english wikipedia though right? We just have to accept that commons images can be deleted at any time with no warning.
Judson [[:en:User:Cohesion]]
"Raimond Spekking" raimond.spekking@gmail.com wrote in message news:f15ar6$c5r$1@sea.gmane.org...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Clements schrieb:
I don't know if anyone has any suggestions to deal with this kind of problem, or even if it has already been recognised as an issue. The non-technical answer is, of course, to copy the commons images to the
local
wiki, but that kind of defeats the point of commons, doesn't it?
We have the CheckUsage tool on the toolserver and every admin should check the usages _before_ deleting an image. If there are (more or less) prominent usages, at least at non user/user talk pages, he shouldn't delete the image or previous replace all usages with the duplicate image.
I know, it's a lot of work
Exemptions are copyvios.
Well, the original image was [[Image:Crystal_128_down.png]], which was deleted [1] because it was a duplicate of [[Image:Crystal_Clear_action_build.png]].
No one at MediaWiki.org was informed of the deletion. A user spotted the broken image and reported it about an hour and a half after it was deleted. It took a further 3 hours for an admin to spot the note and fix 25 broken pages (with the edit summary "yay, Commons sucks"). From the history, this seems to have taken 20 minutes of their time, which is 20 minutes that could have been spent much more constructively (I'm just glad it wasn't me!).
If there is a policy on Commons as described above, then it clearly isn't being followed. If this is normal behaviour then the case is very strong for making local copies of any images you want to use prominently...
- Mark Clements (HappyDog)
[1] http://commons.wikimedia.org/w/index.php?title=Special:Log&type=delete&a... Image:Crystal_128_down.png
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Clements schrieb:
If there is a policy on Commons as described above, then it clearly isn't being followed. If this is normal behaviour then the case is very strong for making local copies of any images you want to use prominently...
Duplicates are marked with http://commons.wikimedia.org/wiki/Template:Duplicate
I think the advices are clearly. I have left a note to the admin: http://commons.wikimedia.org/wiki/User_talk:Siebrand#Image:Crystal_128_down....
Raymond.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Raimond Spekking wrote:
Mark Clements schrieb:
If there is a policy on Commons as described above, then it clearly isn't being followed. If this is normal behaviour then the case is very strong for making local copies of any images you want to use prominently...
Duplicates are marked with http://commons.wikimedia.org/wiki/Template:Duplicate
(Note that duplication isn't a good reason to delete something from Commons, since by definition Commons is a repository.)
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber wrote:
Raimond Spekking wrote:
Mark Clements schrieb:
If there is a policy on Commons as described above, then it clearly isn't being followed. If this is normal behaviour then the case is very strong for making local copies of any images you want to use prominently...
Duplicates are marked with http://commons.wikimedia.org/wiki/Template:Duplicate
(Note that duplication isn't a good reason to delete something from Commons, since by definition Commons is a repository.)
I brought this up at http://commons.wikimedia.org/wiki/Commons_talk:Deletion_guidelines#Deleting_...
-- Tim Starling
On 01/05/07, Brion Vibber brion@wikimedia.org wrote:
(Note that duplication isn't a good reason to delete something from Commons, since by definition Commons is a repository.)
Commons thinks otherwise.
If Commons is to be an effective service project, it needs the infrastructure. A kludged-together usage detector that misses en:wp is not a substitute for something showing right there in the image page if the file is in use.
- d.
On 01/05/07, David Gerard dgerard@gmail.com wrote:
If Commons is to be an effective service project, it needs the infrastructure. A kludged-together usage detector that misses en:wp is not a substitute for something showing right there in the image page if the file is in use.
I'm in 100% agreement with this one, and have been thinking on solutions to provide that information right there in the page. A brief discussion with Brion confirmed the need for a centralised Commons image link table of some sort, which can be updated by all client wikis upon image use.
The trickier issues, as I see them, are detecting image links to shared images (MediaWiki treats them the same, more or less), and producing a list of additions and deletions in a timely fashion. Fortunately, the LinksUpdate code contains quite a bit of this logic which might well be adaptable.
Rob Church
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Gerard wrote:
If Commons is to be an effective service project, it needs the infrastructure. A kludged-together usage detector that misses en:wp is not a substitute for something showing right there in the image page if the file is in use.
That doesn't have any bearing on the fact that Commons is meant for the wider population, where such detection is much tricker, as well as our own projects, of course.
- -- brion vibber (brion @ wikimedia.org)
On 01/05/07, Brion Vibber brion@wikimedia.org wrote:
David Gerard wrote:
If Commons is to be an effective service project, it needs the infrastructure. A kludged-together usage detector that misses en:wp is not a substitute for something showing right there in the image page if the file is in use.
That doesn't have any bearing on the fact that Commons is meant for the wider population, where such detection is much tricker, as well as our own projects, of course.
Yes, though the service project function is (a) what it was created for at all (b) a solvable problem.
It would be a bit silly if Wikimedia had to start a second service project because Commons had gone off on crack ;-)
- d.
"David Gerard" dgerard@gmail.com wrote in message news:fbad4e140705011309u4cea8179h55cc33a20f0bdfc6@mail.gmail.com...
On 01/05/07, Brion Vibber brion@wikimedia.org
wrote:
David Gerard wrote:
If Commons is to be an effective service project, it needs the infrastructure. A kludged-together usage detector that misses en:wp is not a substitute for something showing right there in the image page if the file is in use.
That doesn't have any bearing on the fact that Commons is meant for the wider population, where such detection is much tricker, as well as our own projects, of course.
Yes, though the service project function is (a) what it was created for at all (b) a solvable problem.
It would be a bit silly if Wikimedia had to start a second service project because Commons had gone off on crack ;-)
I think the point Brion was making is that commons will ultimately be used by 3rd party wikis without using a shared database, so the information about which images they are using will not be available.
- Mark Clements (HappyDog)
wikitech-l@lists.wikimedia.org