Last modified: 2011-03-13 18:04:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20923, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18923 - uploadcorrupt error message is vague and confusing
uploadcorrupt error message is vague and confusing
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.16.x
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-26 08:57 UTC by Tim Starling
Modified: 2011-03-13 18:04 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch for Splitting Messages (5.85 KB, patch)
2009-09-16 11:45 UTC, Karun
Details
Patch that splits messages (1.52 KB, patch)
2009-09-16 11:48 UTC, Karun
Details

Description Tim Starling 2009-05-26 08:57:08 UTC
The uploadcorrupt message, "The file is corrupt or has an incorrect extension. Please check the file and upload again." is vague and confusing and commonly leads to support requests:

<http://toolserver.org/~mzmcbride/cgi-bin/mw-logs.py?search=The%20file%20is%20corrupt%20or%20has%20an%20incorrect%20extension>

It can be generated when either:
* MimeMagic detected unknown/unknown but extension is listed as "recognizable", or
* MimeMagic detected a type which was different to the type suggested by the extension.

The details of why the upload was rejected are logged in exquisite detail to the debug log, but the user doesn't get to see any of that. Some users (presumably Windows users from the post Win 95 era) don't really understand file extensions and are easily confused by talk about them. Sometimes the error is the fault of the external detection utility and extra details need to be provided for debugging. 

I suggest:

* Splitting messages for the unknown/unknown case from the "different MIME type" case
* Mapping the most common file extensions and the most common MIME types to a set of localised messages, so that we can talk about e.g. "JPEG" instead of "image/jpeg" and ".jpg". 
* Providing the detected type, the file extension, and the type that the file extension implies, as message parameters.
Comment 1 Brion Vibber 2009-05-26 22:58:07 UTC
Sounds good...
Comment 2 Karun 2009-09-16 11:45:38 UTC
Created attachment 6556 [details]
Patch for Splitting Messages

I have begun working on this bug. I attach a simple patch that splits the messages. I am not yet so sure about localised messages or what to do to add the message to multiple languages, as I have not used them previously.
Comment 3 Karun 2009-09-16 11:48:14 UTC
Created attachment 6557 [details]
Patch that splits messages

I have removed LocalSettings.php from the initial diff.
Comment 4 Brion Vibber 2009-09-23 21:03:29 UTC
This patch seems to reject all files whose type is not detected, which is a change in behavior from the current code; if we're configured to allow non-blacklisted file extensions to be uploaded, and we can't detect a mime type out of it successfully, and it's not an extension that we know we can recognize for sure, then previously we'd let it through.
Comment 5 Karun 2010-01-30 23:41:24 UTC
The uploadcorrupt message is no longer used in the current release of MediaWiki so does not require fixing.
Comment 6 Karun 2010-01-30 23:42:51 UTC
Comment on attachment 6557 [details]
Patch that splits messages

No longer required as uploadcorrupt is no longer used.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links