https://bugzilla.wikimedia.org/show_bug.cgi?id=35133
--- Comment #2 from badon <[email protected]> 2012-03-15 06:58:46 UTC --- (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". -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
