Page MenuHomePhabricator

Improve Mobile/Web upload page Special:Uploads
Closed, ResolvedPublic


I just tried (for the first time :-) this Mobile/Web upload myself. (I don't use these newfangled smartphones :-), but it occurred to me that I could try this in my desktop browser, too...) Here's my experiences:

  1. Just copied a random file from the Internet on my computer.
  1. Tried Special:Uploads on the mobile site and tried to upload it. Good: it displays below the "Contribute an image" button thumbnails of images I had already uploaded. I like that, but it leaves me perplexed why some users keep uploading images they already had uploaded before. Maybe they don't see the thumbs on a small smartphone screen?
  1. Since the file did not contain any EXIF, I did indeed get the warning popup "this file looks suspicious...". Good!
  1. Added a minimal EXIF as it appears to be added by some smartphones: just a EXIF:ColorSpace=sRGB. Nothing else. Tried again.
  1. This time I got no warning.
  1. Noticed the "I took this image" line. Hm, that's not true. So even if I wanted to correctly attribute the image, I couldn't.
  1. There's a link "What does this mean?" below. Clicked on that and got a completely uninformative blue page containing the image and the text "Contribute your images. Help Wikimedia Commons come to life! Images on Wikimedia Commons come from Wikimedia Commons". That's all. Huh??? I would have expected some explanation that I must not upload images that I did not take myself, plus a warning that if I upload third-party images, they will be deleted, plus a mention to respect third party copyrights. In fact, there might be space to put such a mention right below that "What does this mean?" link: "Respect third-party copyrights: only upload your own images!". Possibly even "Respect third-party copyrights: only upload your own images! Do not upload images from other websites."
  1. Entered a description and uploaded. Result: a prototypical bad upload that I then deleted right away.
  1. Repeat with the same file. This time I entered a single blank as description. Upload button becomes enabled.
  1. Click the upload button. Whoa! I get no error feedback, but the upload is just not made.
  1. Created a new user account and went (manually, since I don't get the link) to Special:Uploads. The tutorial shown is the same blue page as in point (7) above. I just hope that works with real smartphones. Somebody please check that the tutorial works. It doesn't for me (FF 30.0 on OS X).

So, three improvements:

  • Verify that really works. If it does for you, let's assume this is a quirk on my end.
  • Add a short "respect copyrights" after the "What does this mean?" link on the description page, possibly with text as suggested above.
  • Do not enable the upload button unless the description contains valid text, or if you do enable it and then can't perform the upload (single blank test above), provide an error message and let the user re-try.

All in all, this looks like a nicely streamlined upload process with only one (big) problem: how to make users understand that they absolutely MUST NOT upload third-party images through it?

(One possibility: run (server-side) a Google image search for each Mobile/Web upload (synchronously) and refuse the upload if it indicates more than one hit. May give a few false positives, but not many.)

Or how to improve or "un-streamline" this so that people like [[User:Qpeezee]], who mostly uploads PD-old images, has a way of saying "no, I didn't take this picture, it's from XYZ, was made by ABC, and is so old that it must be PD-old-100"? With the current process, his uploads end up wrongly labeled as "own work" and then usually get a "no source" tag.

Version: unspecified
Severity: normal
See Also:



Related Objects

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:38 AM
bzimport set Reference to bz68375.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card

(In reply to Lupo from comment #0)

All in all, this looks like a nicely streamlined upload process with only
one (big) problem: how to make users understand that they absolutely MUST
NOT upload third-party images through it?

Currently, we sometimes get funny occurrences of this pattern:

  • User uploads a file from somewhere else: [[:commons:File:Remember the old mario in the classical game? 2014-07-23 13-51.jpg]]
  • The file gets nominated for deletion
  • This user noticed that and...
  • ... uploads his next file: [[:commons:File:I dont know how to change the thing that says i created this image but anyway i need help on that- I really like luigi 2014-07-23 14-04.jpg]] (Mario again)!!!

If it weren't so sad, it'd be hilarious.

Admittedly, this precise pattern is rare. More common is just a re-upload a couple of hours later with the same name, without any attempt to get help.

Problems I see from this:

  1. The user doesn't know where to get help.
  2. The user doesn't understand why his upload got nominated for deletion.

He probably only noticed his talk page notification about the deletion request, but not the deletion request itself. Because the request gives a reason: "This is en:Mario, so certainly not the uploader's own work but ©Nintendo. From the content of Category:Mario (video game series) I'd guess that we don't consider this to be in the Public Domain for simpleness, right?"

  1. The user doesn't even pause to think about what happened, he just wants an image of Mario in Wikipedia.
  2. The user is using the mobile/web upload process, which is only for self-taken photos, for an image from somewhere else.
  3. The user has even realized this (i.e., point 4), yet still uses this process because it is the only process available to him.

The user is, as far as I see, autoconfirmed at the English Wikipedia (account created on July 1, 2014, and he did have more than ten contributions, although most of them got deleted).

Not all of these are a problem with the mobile front-end. For instance, the talk-page notifications could perhaps be improved to repeat the deletion reason. Help links could be made available more liberally in more places. But the mobile/web upload process also clearly has a problem.

Maybe it is possible, that we add a link above the upload summary with the title "Please read the notices before upload your media" (like the "This page has issues", e.g. which opens a new Overlay with a mobile optimized short upload 1x1. The content can maybe come from a page in project namespace (e.g. Project:Mobile-Upload-1x1, translated with /de, /it and so on), so it can be edited simply as wikitext (nevertheless following the idea to make it mobile optimized) which is loaded in the overlay.


  • the user can read it without loosing the actual state of upload workflow
  • it doesn't take too much place
  • it's enough flashy for all users
  • (maybe hide the link with an editcount on wiki > 75 or something else)
  • if the user know the rules, he can simply ignore and can upload without any problem


  • the last point is a cont, too: If the user won't to read this

I wonder if the design should have some kind of screen saying 'Did you take this photo?" with YES NO buttons. On clicking No, the user could be informed that we don't accept uploads not owned by you for legal reasons. (This wouldn't solve the issue of correctly attributing photos but it would optimise for the photos taken from mobile phone angle). That said it probably wouldn't help much with selfies :)

It would be worth testing this sort of workflow to see if it has any impact on educating, I worry the existing blue slideshow doesn't quite solve this problem. It's very passive and can be ignored. We should be challenging the user in some way, and at least getting them to think about the impact of their upload.

mobile or not, there can be photos that the user did not take themselves but that are perfectly fine for upload, like images from public domain sources etc.

Sure.. but as I understand it the issue here is wanting to stop mobile users uploading photos from the web no? We should fix that problem first.

Okay, during today's meting we decided that we will set a hard minimum limit of edits for uploads (we'll try to do that by tomorrow). If that doesn't work after a week or something, we will disable mobile uploads completely until the time we're able to do something about it.

Thanks, Max and everybody else.

Just a note: the fix for bug 68414 is set to go live tonight. I actually do hope that this has already a beneficial effect.

If the hard limit comes only by Monday, that's not a problem. In fact, that would give us a few days to see what the results from "autoconfirmed only" actually would be, and whether that fix makes any difference. (The current rule is also "autoconfirmed only", but it still allows non-autoconfirmed users to upload because of bug 68414.)

Change 143751 had a related patch set uploaded by Florianschmidtwelzow:
Add Uploadrestriction using edit count

Change 143751 merged by jenkins-bot:
Add Uploadrestriction using edit count

Change 150075 had a related patch set uploaded by Kaldari:
Add Uploadrestriction using edit count

Change 150075 merged by jenkins-bot:
Add Uploadrestriction using edit count

Change 152748 had a related patch set uploaded by Florianschmidtwelzow:
Check userCanUpload when wgMFPhotoUploadEndpoint is set

Change 152748 merged by jenkins-bot:
Check userCanUpload when wgMFPhotoUploadEndpoint is set

Change 154364 had a related patch set uploaded by Florianschmidtwelzow:
Check userCanUpload when wgMFPhotoUploadEndpoint is set

Change 154364 merged by jenkins-bot:
Check userCanUpload when wgMFPhotoUploadEndpoint is set