Last modified: 2012-12-23 00:25:16 UTC
At least changing extension between "compatible ones" (such as .JPG <-> .jpg; .jpg <-> .jpeg) should be allowed.
Something tells me this would be more easily, and more reliably, accomplished on the client's side before the upload process is initiated....why would a user need to change the file extension only after choosing the file?
Well, not really. I uploaded recently IMG_6152.JPG to become https://commons.wikimedia.org/wiki/File:Lower_St_Francesco_Basilica_in_Assisi_-_Interior.JPG I would prefer to be able to change IMG_6152.JPG to "Lower St Francesco Basilica in Assisi - Interior.jpeg" in the process.
OK, that makes some sense. So maybe having arrays of names that are compatible with each other, then offering to switch between them (dropdown after the filename field?) during the details step. I'll see what I can do.
Thanks for taking this up. I would say the dropdown is an overkill. Maybe just extension added at the end of the filename with the dot. However, it might be difficult to determine whether the intention was to add an extension or some dotted segment (some.file.name - do we accept this?). Maybe if the filename ends with . + one of the allowed extensions, it is left as-is?
Hm. A big concern of mine is that less-experienced users might see an error message like "incompatible filetype" and not know what to do. For those users, it would almost certainly be nicer to not even allow the mistakes that might cause the error. We already have plenty of confusing error messages in UW, I'm not about to add another one! The more I think about this, the more I think it might be better to solve this problem with a server-side configuration setting--let the site admins specify that they want all file extensions (upper|lower)case, and then perform that operation on the client-side before upload. Maybe that's the way to solve this, because there's no burden on the user whatsoever, and it would make things look a lot more uniform. Thoughts? (also, I'm not currently working on this, but I might during the next UW sprint, which is coming up soonish)
We already have http://www.mediawiki.org/wiki/Manual:$wgFileExtensions plus we have also a pretty complex MIME/content type detection mechanism (see also http://www.mediawiki.org/wiki/File_upload) some.file -> uploaded as (autodetected), add default extension file.jpg -> uploaded as the JPEG file, keep JPG extension file.jpeg -> uploaded as the JPEG file, keep JPEG extension file.svg -> uploaded as the SVG file, keep SVG extension But there is a problem too, suppose I want to upload today some.file.webm -> upload as (autodected), I will probably get an error but once bug 30653 is fixed, it will become: some.file.webm -> upload as WebM file, use .webm extension do you think this is too confusing? (however, to add some confusion, there is bug 38927 as well, did bug 30653 got fixed?).
I don't understand what any of that has to do with this. The solution I just suggested would not affect anything like what files you could/couldn't upload, it would just be "if the file extension (the string after the last '.' in the filename) is upper case, make it lower case". That's the only thing I think we need, plus another parallel solution for making it upper case. Would that be enough? We could also add a config option for funneling, e.g., 'jpeg' -> 'jpg'.
I have pointed to a related problem like Marcin Cieślak (my camera generates .JPG files and UW does not allow me to normalize this to .jpg) in bug 40326. That bug, however, is receiving a treatment somewhat different from what I originally wished. I am fine with Mark Holmquist's solution, because I do not see any rationale for which someone would might like having a file with extensions like .JpG, .Jpg or even .JPG, if we all agree that .jpg is the normalized letter case (and perhaps even spelling – cf. .jpeg and its variants). Furthermore, the discussion at bug 40326 reveals that there actually already exists the practice of promoting a "normalized" extension, which is .jpg in this case. Therefore, the solution proposed by Mark Holmquist would actually resolve what bug 40326 was in fact originally about. I am glad that somebody else in concerned with this as well and wants to do something abou it, and I hope that things will go on rolling in the right direction.
