Recently, I have uploaded som eplant images to the commons. A few of these might have been incorrectly labeled. The current procedure for "renaming" them is #1 someone downloads the image #2 reuploads it under a new name, with the original description #3 fixes links on other wikimedia projects via chackusage #4 adds a "duplicate" template to the original image #5 the original image gets, eventually, deleted (unless it's an admin doing reuploading, who can skip #4)
For a site managing >1.5 million files, IMHO this is a rather cumbersome process. Also, it leaves a (perfectly OK) image deleted on the server, thus duplicating that data.
Maybe Tims recent file managing upgrade already has a solution for this, but if not, here's my 2 pennies (I'm in the UK now, after all:-)
* Make image pages movable (with the appropriate changes to the image table). * Replace the "404 error: File not found" error message for non-existant images with a script that checks if there's a REDIRECT page under that name in the database. * Return the new image if this is the case, and return 404 if not.
This would be an improvement to the manual steps described above: * MUCH easier and faster to do * Preserves original upload/edit history * Direct links to the image keep working * No space waste due to deleted image * Cost : an additional redirect page, and an SQL query for requests of non-existing images
To turn off this behaviour for an image, simply delete the REDIRECT page.
(Seems so easy, I'm afraid I missed someting obvious at this point:-)
Magnus
Magnus Manske wrote:
Maybe Tims recent file managing upgrade already has a solution for this, but if not, here's my 2 pennies (I'm in the UK now, after all:-)
- Make image pages movable (with the appropriate changes to the image table).
- Replace the "404 error: File not found" error message for
non-existant images with a script that checks if there's a REDIRECT page under that name in the database.
- Return the new image if this is the case, and return 404 if not.
This would be an improvement to the manual steps described above:
- MUCH easier and faster to do
- Preserves original upload/edit history
- Direct links to the image keep working
- No space waste due to deleted image
- Cost : an additional redirect page, and an SQL query for requests of
non-existing images
To turn off this behaviour for an image, simply delete the REDIRECT page.
(Seems so easy, I'm afraid I missed someting obvious at this point:-)
Magnus
I have also thought on this before. Some changes are that redirects are in page table, not on the image one. So the commons page table would need to be shared, too.
Then, our files are stored based on their filename, so either each page renaming means rename a lot of files, or we store in the image table the filename.
On 6/11/07, Platonides Platonides@gmail.com wrote:
Some changes are that redirects are in page table, not on the image one. So the commons page table would need to be shared, too.
Replace the standard 404 page for images with either * a single script that can query all databases (Wikimedia use only), OR * a script in each wiki (would be part of MediaWiki) that can query its own database
Then, our files are stored based on their filename, so either each page renaming means rename a lot of files, or we store in the image table the filename.
So, I upload an image, then move it. During this process, one file is renamed. If that image has five old versions, that means renaming five files. Just delete thumbnails, or wait for them to go out-of-date.
We should be able to cope with that :-) If I'm missing something here, please explain.
Magnus
On 6/11/07, Platonides Platonides@gmail.com wrote:
Some changes are that redirects are in page table, not on the image one. So the commons page table would need to be shared, too.
No, they're in the redirect table now, so only that would need to be shared.
Brion once said (http://bugzilla.wikimedia.org/show_bug.cgi?id=709#c19) that after the image backend restructure this would be trivial. Isn't the image storage backend restructured now? Is this now trivial?
The bug for this is, of course, http://bugzilla.wikimedia.org/show_bug.cgi?id=709, opened October 2004.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Simetrical wrote:
On 6/11/07, Platonides Platonides@gmail.com wrote:
Some changes are that redirects are in page table, not on the image one. So the commons page table would need to be shared, too.
No, they're in the redirect table now, so only that would need to be shared.
Brion once said (http://bugzilla.wikimedia.org/show_bug.cgi?id=709#c19) that after the image backend restructure this would be trivial. Isn't the image storage backend restructured now? Is this now trivial?
The frontend has been restructured in preparation for the backend restructure. Backend work is ongoing.
- -- brion vibber (brion @ wikimedia.org)
One issue is that it should be done in a way such that given a name and timestamp, you can still get the correct image version, rather than have to worry if some other image was moved over the desired one.
Currently, that is the only way you can make "stable versions" of pages with images.
Magnus Manske-2 wrote:
Recently, I have uploaded som eplant images to the commons. A few of these might have been incorrectly labeled. The current procedure for "renaming" them is #1 someone downloads the image #2 reuploads it under a new name, with the original description #3 fixes links on other wikimedia projects via chackusage #4 adds a "duplicate" template to the original image #5 the original image gets, eventually, deleted (unless it's an admin doing reuploading, who can skip #4)
For a site managing >1.5 million files, IMHO this is a rather cumbersome process. Also, it leaves a (perfectly OK) image deleted on the server, thus duplicating that data.
Maybe Tims recent file managing upgrade already has a solution for this, but if not, here's my 2 pennies (I'm in the UK now, after all:-)
- Make image pages movable (with the appropriate changes to the image
table).
- Replace the "404 error: File not found" error message for
non-existant images with a script that checks if there's a REDIRECT page under that name in the database.
- Return the new image if this is the case, and return 404 if not.
This would be an improvement to the manual steps described above:
- MUCH easier and faster to do
- Preserves original upload/edit history
- Direct links to the image keep working
- No space waste due to deleted image
- Cost : an additional redirect page, and an SQL query for requests of
non-existing images
To turn off this behaviour for an image, simply delete the REDIRECT page.
(Seems so easy, I'm afraid I missed someting obvious at this point:-)
Magnus
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Voice of All wrote:
One issue is that it should be done in a way such that given a name and timestamp, you can still get the correct image version, rather than have to worry if some other image was moved over the desired one.
Currently, that is the only way you can make "stable versions" of pages with images.
The identical issues exists for templates, which are also referenced by name and may change over time; how are you handling this in the current FlaggedRevs code?
My previous work on a similar snapshotting system stored the revision ids for each transcluded page by name with the snapshot record, using the stored lookup table when re-reading templates for rendering of the snapshot. Equivalent or similar records could be stored for images, though I didn't implement that at the time I was playing with it.
- -- brion vibber (brion @ wikimedia.org)
Currently, the extension maps template NS/title with the ID. So even if it was moved, by calling newFromId() on the that ID, we still get the sane template. Images have no Ids, so matching name to timestamp is the best I can do.
Maybe you can test this extension sometime btw :)
-Aaron Schulz
From: Brion Vibber brion@wikimedia.org Reply-To: Wikimedia developers wikitech-l@lists.wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] On renaming images Date: Mon, 11 Jun 2007 16:07:04 -0400
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Voice of All wrote:
One issue is that it should be done in a way such that given a name and timestamp, you can still get the correct image version, rather than have
to
worry if some other image was moved over the desired one.
Currently, that is the only way you can make "stable versions" of pages
with
images.
The identical issues exists for templates, which are also referenced by name and may change over time; how are you handling this in the current FlaggedRevs code?
My previous work on a similar snapshotting system stored the revision ids for each transcluded page by name with the snapshot record, using the stored lookup table when re-reading templates for rendering of the snapshot. Equivalent or similar records could be stored for images, though I didn't implement that at the time I was playing with it.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGbatowRnhpk1wk44RAsUsAJ4810aF+vnasV3xOCyt+UVw+lq7eQCdHa6M wPgn2/0u9x2/4IX7jG8Szgk= =Pg5s -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
_________________________________________________________________ Play games, earn tickets, get cool prizes. Play nowit's FREE! http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink1
wikitech-l@lists.wikimedia.org