Last modified: 2011-09-17 14:01:50 UTC
the UploadWizard automatically adds .jpg file extension to files which have the upper-cased one (.JPG). This makes the files have a double extension, e.g. .JPG.jpg, which doesn't look very good and then people have to move it manually. http://commons.wikimedia.org/w/index.php?title=File:19663_Sulechow_Handlowa_5.JPG.jpg&action=history> is a good example.
I tried this locally and could not reproduce the issue. When I upload a file foobar.JPG extension, it ends up as foobar.jpg. Are you sure it's the UW that added this extension, and not some other tool you used?
Neither can I reproduce this issue. This has been raised in a talk with me and I've written about it to the WLM mailing list, without checking it before. I think this had to be an error made by the user, so closing as RESOLVED INVALID.
The UploadWizard asks for a title (which doesn't include the extension, seems appended later by UW). If the user gives a title with an extension, that double extension will appear in the final page. I think that if the user provides a title with an extension (could just compare with a few common ones, such as /(gif|jpe?g|png|pdf|bmp|djvu)/i) it should give a warning.
Ah. Could do that. But what about when the extension matches that of the file being uploaded? Also show the warning, or is it better then to just omit it? Like that you cannot get a destination file name like foo.png.png, but I don't see why you'd want to do this.
I'd just show the warning all the time. User clicks on Upload, and gets the following window; The provided title 'Modern monument 5.jpg' seems to include a filename extension. As the extension is automatically added, the final would be 'Modern monument 5.jpg.jpg' Are you sure you want to proceed? Yes, upload - No, strip .jpg and upload - Cancel
Is there any valid use case for adding an additional extension in the "Describe" step? If not, I suggest either quietly stripping redundant extensions, or doing it as part of the interactive flow and notifying the user. But I don't see a need for the UI clutter of confirm/yes/no/cancel.
Reducing severity and importance which is IMO appropriate unless 1) the original bug description can be reproduced, or 2) we see evidence that this is a major issue affecting many users.
(In reply to comment #6) > Is there any valid use case for adding an additional extension in the > "Describe" step? If not, I suggest either quietly stripping redundant > extensions, or doing it as part of the interactive flow and notifying the user. > But I don't see a need for the UI clutter of confirm/yes/no/cancel. Maybe the user wants to keep the original filename (eg. downloaded from somewhere else)? What's the difference between "interactive flow" and showing a dialog?
This was noted by some previous testers (who were familiar with MediaWiki already). Probably the right answer is twofold: 1) add the extension to the interface, in non-editable text at the right end of the title input. 2) silently remove an extension in the filename, if it matches the existing extension case-insensitively.
I'm not sure (1) turns out to be pretty. A text below the title saying "Will be saved as $1.jpg" that updates as you write looks nicer imho but that may have its own issues (silly browsers, the change disturbing the user...). I personally find uglier extensions with a different case than the main part of the filename. Maybe not adding instead of removing the user part? (that's still a magic behavior for the users, though)
Okay I did (2) without (1), which is semi-magical, but does the right thing IMO. If you added .jpg, and the extension was going to be .jpg, then it's normalized to just one. However, if you make a filename like filename.avi, and the ultimate extension is .ogg, then you get filename.avi.ogg. Maybe some people will want that to represent the original filename or whatever.
that is: fixed in r97638
r97638 is a future revision. It is r97368.
