Last modified: 2014-05-22 16:11:39 UTC
Right now, if a file of the same name as an existing file is uploaded, it will "overwrite" and replace the existing file. But, both versions of the file are preserved. When this happens accidentally, the most straightforward and expedient way of fixing it is to download and save both files, then delete the wiki version of them, and then re-upload them both separately. It would be helpful if it were possible to simply split out file versions into their own file pages, completely, or just as a replicated copy. That would not only help with fixing accidental overwrites, but it would also allow people to access arbitrary versions of the files too, for whatever purpose.
What I'm getting out of this bug is that the current file page interface sucks... > [..]But, both versions of the file are > preserved. When this happens accidentally, the most straightforward and > expedient way of fixing it is to download and save both files, then delete the > wiki version of them, and then re-upload them both separately. Just to clarify, is this most convenient because the revert button is hidden/hard to understand/just not known it exists/etc, or is the method you suggest still better from your position even with knowing how to revert image uploads? (Sorry, that's kind of poorly worded - but basically I'm asking do you think the current system sucks because you're not familiar with its secrets, or do you think it sucks even with knowing how it works. Both possibilities are bad, the former means the interface is really bad as its not discoverable by users, and the latter is just obviously bad). I would think the most expedient way of fixing such a situation would be to revert the recent overwrite, then upload the new file under a different name. > > It would be helpful if it were possible to simply split out file versions into > their own file pages, completely, or just as a replicated copy. That would not > only help with fixing accidental overwrites, but it would also allow people to > access arbitrary versions of the files too, for whatever purpose. I'm not sure that would improve the situation (It could be I'm just not sure how to visualize properly in my mind what you're suggesting). Note, as it stands people can still get the full or scaled old versions of files, just not embed them using [[file:...]] syntax
(In reply to comment #1) > What I'm getting out of this bug is that the current file page interface > sucks... > > basically I'm asking do you > think the current system sucks because you're not familiar with its secrets, or > do you think it sucks even with knowing how it works. It sucks even with knowing how it works. Just as a matter of safety or "idiot-proofing", overwrites should just not be done, ever. But, there are a lot of better reasons to use that approach too, which I'll describe in a moment. My solution to the file name overwriting problem is to automatically assign a random name to every file upload. File names are a terrible place to store information about the file anyway, so such an extreme solution isn't actually so extreme from a technical perspective. Image annotation of various kinds is the present (image file pages) and future (see my MW.org User:Badon page, especially Lupo's image annotator) of image management (searching, etc). Putting information in the filename itself is a waste of energy, and should at the very least not be allowed to cause problems, if it isn't actually being automatically prevented. The whole concept of naming a file could be disposed of. In fact, the only place where I think a descriptive file name is useful is when looking at code, and you're trying to figure out what image the code is describing. Indeed, the future direction of MediaWiki seems to be pushing away from code as much as is practical, into the Visual Editor and WYSIWYG editing. But, even with code that is aided by descriptive file names, it would still be wise to append something unique to the file name to ensure uniqueness. Doing something like that could work in an optional way, where if no name is specified, it's assigned uniquely, and even if it is specified, the file name still gets a unique string appended. When an image is to be used, the [[File:...]] syntax should be treated akin to a template call. Then, the specific image that is delivered can be changed if someone wants to change it. But, all versions, including old ones, should be available. That will require internally linking up image versions similarly to how the list of templates used on a page is made apparent when editing. It could all appear to the user exactly the way it currently does on an image file page. I'm already doing this sort of thing with Semantic MediaWiki, but MediaWiki could do it natively, and faster. Each "version" could have an incremented "file name" that is optionally used in the [[File:...]] syntax "template" call if a specific version is desired. If a specific version is not desired, simply omit the version number, and the most recent (highest numbered) "version" is automatically used. > I would think the most expedient way of fixing such a situation would be to > revert the recent overwrite, then upload the new file under a different name. That's not quite right. You have to save the file first, if you weren't the person that uploaded it. Then, you could follow the procedure you described. It is expedient, but not straightforward if you're a user that's not familiar with the revert operation, or not brave enough to use it. The "revert" has baggage that makes it seem like an insult to new, inexperienced, or very mild mannered editors, so the future of WMF editors depends on finding a way to do something like that without putting people off from editing. So, who knows, maybe in the future we won't always have a revert procedure quite the same way as we do now, and certainly it shouldn't be a solution to fundamental design problem. > > It would be helpful if it were possible to simply split out file versions into > > their own file pages, completely, or just as a replicated copy. That would not > > only help with fixing accidental overwrites, but it would also allow people to > > access arbitrary versions of the files too, for whatever purpose. > > I'm not sure that would improve the situation (It could be I'm just not sure > how to visualize properly in my mind what you're suggesting). Note, as it > stands people can still get the full or scaled old versions of files, just not > embed them using [[file:...]] syntax Under the scheme I described above, where optional version numbers are assigned to the images, a version that is "split" away into its own page would basically just be a redirect to the original location of the "version", and the redirect would provide an increased level of visibility for the image (searches, etc) that is not normally given to mere "versions".
Hmm, interesting. By the way, have you read [[mw:User:NeilK/Multimedia2011/Titles]]? Some of Neil's thoughts are quite similar to your own So basically what you're suggesting is another layer of indirection? I'm going to repeat back what I think you're saying to see if I understand. *User uploads a file. It becomes some random string (base 36 sha1 hash of its contents would perhaps be a good choice. So something like nw0i4k7agg53rak074baj2fqowrxmae *Somehow, user then associates the file they just uploaded with a "real" file name. So the user might associate nw0i4k7agg53rak074baj2fqowrxmae with [[File:Saskatchewan_Farm_Elevator.jpg]], and then could reference the image nw0i4k7agg53rak074baj2fqowrxmae by using the code [[File:Saskatchewan_Farm_Elevator.jpg]] in wikitext. Individual file pages would not be intimately associated with the file they represent, they're more like pointers to a specific file. Other file pages could also be associated with a specific file, a file page could be unassociated on a whim, etc. When thought that crossed my mind, is that we're slowly moving in the direction of file names being less permanent, but from the other direction (With features like moving of file pages). ----- >In fact, the only place where I think a descriptive file name is useful is when >looking at code, and you're trying to figure out what image the code is >describing. Indeed, the future direction of MediaWiki seems to be pushing away >from code as much as is practical, into the Visual Editor and WYSIWYG editing That's still quite a long way off. And even then, I (personally) have my doubts on how much it will be accepted by old timers. I think it will result in a mix, where a stubborn portion (to pull numbers out of my hat, I will guess 10%) will still use the wikitext. ---- >Each "version" could have an incremented >"file name" that is optionally used in the [[File:...]] syntax "template" call >if a specific version is desired. If a specific version is not desired, simply >omit the version number, and the most recent (highest numbered) "version" is >automatically used. Even as the system is right now, it might be useful to have syntax like [[File:SomeFile.png|version=20100101111310]] which would reference a specific version of an image. (and I believe such a change would be relatively simple)
(In reply to comment #3) > Hmm, interesting. > > By the way, have you read [[mw:User:NeilK/Multimedia2011/Titles]]? Some of > Neil's thoughts are quite similar to your own I've never seen it before, but I like some of his ideas better than my own, especially the part about internationalization. I had not considered internationalization when I wrote up my ideas here. > So basically what you're suggesting is another layer of indirection? I'm going > to repeat back what I think you're saying to see if I understand. > > *User uploads a file. It becomes some random string (base 36 sha1 hash of its > contents would perhaps be a good choice. So something like > nw0i4k7agg53rak074baj2fqowrxmae > *Somehow, user then associates the file they just uploaded with a "real" file > name. > > So the user might associate nw0i4k7agg53rak074baj2fqowrxmae with > [[File:Saskatchewan_Farm_Elevator.jpg]], and then could reference the image > nw0i4k7agg53rak074baj2fqowrxmae by using the code > [[File:Saskatchewan_Farm_Elevator.jpg]] in wikitext. > > Individual file pages would not be intimately associated with the file they > represent, they're more like pointers to a specific file. Other file pages > could also be associated with a specific file, a file page could be > unassociated on a whim, etc. Yes, mostly. But, I envisioned it a bit differently. If no file name is specified, the file name becomes: [[File:Saskatchewan_Farm_Elevator.jpg]] But if a file name is specified, it then becomes: [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae.jpg]] That does not handle internationalization of the file name, but even though I like NeilK's proposal, I disagree that internationalization is required or even desired. I feel that file names are mostly obstructive, and should be reduced to meaninglessness. His proposal accommodates that viewpoint too, though. In his proposal, everything still works without internationalization, and without meaningful file names of any kind. His concerns about deception in the meaning of the file name are unimportant, since that kind of deception has always been possible, and will always be possible. There's no way to eliminate it, other than actually seeing images instead of meaningless file names. File names are already just as meaningless now as they will be when the proposals of NeilK and myself are implemented. > When thought that crossed my mind, is that we're slowly moving in the direction > of file names being less permanent, but from the other direction (With features > like moving of file pages). I like simple solutions, and this is a simple solution. If you want to change the name, or internationalize it, a legion of redirects could be used for as many languages as you wanted to support. > >In fact, the only place where I think a descriptive file name is useful is when > >looking at code, and you're trying to figure out what image the code is > >describing. Indeed, the future direction of MediaWiki seems to be pushing away > >from code as much as is practical, into the Visual Editor and WYSIWYG editing > > That's still quite a long way off. And even then, I (personally) have my doubts > on how much it will be accepted by old timers. I think it will result in a mix, > where a stubborn portion (to pull numbers out of my hat, I will guess 10%) will > still use the wikitext. It's not very far off. Already, maybe 1 in 10,000 (or less) Wikipedia users ever see the code. Instead, they all see the images themselves. The only thing that will change is the barrier to becoming an editor. There are always good reasons to have direct access to the code, so the code will never go away, I hope. That doesn't mean we have to use it - it only means we CAN use it, if needed...Kind of like flour and eggs instead of sliced bread. We can bake a cake with the flour and eggs, or we can make a quick sandwich with the sliced bread. Both are useful, and never going to go away. > ---- > >Each "version" could have an incremented > >"file name" that is optionally used in the [[File:...]] syntax "template" call > >if a specific version is desired. If a specific version is not desired, simply > >omit the version number, and the most recent (highest numbered) "version" is > >automatically used. > > Even as the system is right now, it might be useful to have syntax like > [[File:SomeFile.png|version=20100101111310]] which would reference a specific > version of an image. (and I believe such a change would be relatively simple) That's a simple solution, and I like simple solutions. The way I envisioned it would look like this: [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae.jpg]] <!-- Always uses the most recent version. --> [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae_1.jpg]] <!-- Always uses the first version. --> [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae_2.jpg]] <!-- Always uses the second version. --> Using the simple syntax you suggested, it would look like this: [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae.jpg]] <!-- Always uses the most recent version. --> [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae.jpg|1]] <!-- Always uses the first version. --> [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae.jpg|2]] <!-- Always uses the second version. --> Both sets of examples above assume that the uploader specified a file name. In a perfect world, the file name would not exist, and it would look like this: [[File:nw0i4k7agg53rak074baj2fqowrxmae.jpg]] <!-- Always uses the most recent version. --> [[File:nw0i4k7agg53rak074baj2fqowrxmae.jpg|1]] <!-- Always uses the first version. --> [[File:nw0i4k7agg53rak074baj2fqowrxmae.jpg|2]] <!-- Always uses the second version. --> One way to make a visual editor IMMEDIATELY useful is to cause the image thumbnail to be displayed when hovering over the code. Then, there's know need for internationalization, no need for descriptive filenames - in short, the image speaks a thousand words and does not need any sort of translation into text. Of course, NeilK's suggestion to omit file extensions would mean that the above example would look like this: [[File:nw0i4k7agg53rak074baj2fqowrxmae]] <!-- Always uses the most recent version. --> [[File:nw0i4k7agg53rak074baj2fqowrxmae|1]] <!-- Always uses the first version. --> [[File:nw0i4k7agg53rak074baj2fqowrxmae|2]] <!-- Always uses the second version. --> I think that might be the future, but the world is not ready for extensionless files, in my opinion. Is it audio, visual, both, or neither? The extension carries that information in some dominant operating systems, so for now, I think the extensions shouldn't be removed completely. But, I see no reason why it should be REQUIRED. So, the above example should still work without a file name extension, but that syntax should not be encouraged, because it will achieve very little, and possibly cause unnecessary confusion. Very good thinking on your part, Bawolff. I always enjoy working with you to solve problems. I wish everyone were like you.
(In reply to comment #4) > (In reply to comment #3) > > So the user might associate nw0i4k7agg53rak074baj2fqowrxmae with > > [[File:Saskatchewan_Farm_Elevator.jpg]], and then could reference the image > > nw0i4k7agg53rak074baj2fqowrxmae by using the code > > [[File:Saskatchewan_Farm_Elevator.jpg]] in wikitext. > > > > Individual file pages would not be intimately associated with the file they > > represent, they're more like pointers to a specific file. Other file pages > > could also be associated with a specific file, a file page could be > > unassociated on a whim, etc. > > Yes, mostly. But, I envisioned it a bit differently. If no file name is > specified, the file name becomes: > > [[File:Saskatchewan_Farm_Elevator.jpg]] > > But if a file name is specified, it then becomes: > > [[File:Saskatchewan_Farm_Elevator_nw0i4k7agg53rak074baj2fqowrxmae.jpg]] Whoops, that should be: [[File:nw0i4k7agg53rak074baj2fqowrxmae.jpg]] not: [[File:Saskatchewan_Farm_Elevator.jpg]]
I just had another thought about a possible benefit to changing the way MediaWiki handles file pages. If different versions of files can be linked to each other in a web network pattern, it will allow people to find both derivative works, and source works. So, for example, if an image is altered and made part of a new image, the new image file page would be able to link back to the source image. That would give people a chance to see the original form of the image, and maybe give them ideas on how they can improve usage of the file in their own derivative works. I think WMF should take ownership of contributed content to make the issue of licensing simpler, but until then, this network of relationships between diversely-licensed source works and derivative works will at least give people something new to argue about, if it doesn't persuade people to standardize on a single license :)
>I think WMF should take ownership of contributed content to make the issue of >licensing simpler yeah, that's unlikely to happen ever.... ----- I do think it would be nice to be able to associate source files with final files on the mediawiki level (especially for things like linking the source gimp xcf image to the final png image, but having just general this is a derrivitave of that links on files would be cool).
It's already done for Wikipedia: By clicking the "Save Page" button, you agree to the Terms of Use, and you irrevocably agree to release your contribution under the CC-BY-SA 3.0 License and the GFDL. That's not quite "taking ownership", but it achieves the same goal that I'm hoping for - simpler licensing.
