Wikipedia talk:File Upload Wizard

So, what's this?

This is a draft of an experimental new file upload wizard that I believe might improve our uploading process, especially for newcomers (who typically don't understand the present system, at all.)

I now need to get some Javascript written that will do the following things:

• On loading the page, substitute actual HTML form code (text boxes, textareas, radiobuttons and checkbuttons) for the various placeholder elements (each now marked <span id="placeholder..."> in the wikicode).
• Add event handlers that will switch visibility of the different alternative question sets in "Step 4" in response to the user's choices among the radio buttons of "Step 3". Each type of file thus gets its own, tailor-made input questionnaire, including specific questions about sourcing, evidence of permissions, and NFCC rationales.
• Add some evaluation code to check that all necessary fields are filled properly. Should also check for overly short or generic file names, filenames that are already taken, and so on.
• Add a submit event handler that will assemble the user input into a string of wikitext for the image description page, sends a http PUT query to the MediaWiki API, notifies the user of success or lack of success, and redirects the user to the finished file page. Apparently this has to be done through Ajax (programming), similar to the way Twinkle does it.

Damn. I'm crap at writing Javascript. Any help welcome. Fut.Perf. ☼ 23:25, 14 January 2012 (UTC)

Update

So, let's say this is now in alpha stage.

• The basic functionality is there. It can actually upload stuff. The dialog mechanism that takes the user through the different options should be working.
• Validating filenames, checking for files that already exist: working for me now.
• Validating article links given for NF files, checking for non-existing targets, non-mainspace targets, redirects and dab pages: working for me.
• Still missing / to be written:
  • response after successful upload
  • option to enter manual edit summary (must be obligatory for uploads overwriting existing files)
  • possibly a mechanism of choosing between different modes for different users. The script could try to figure out if the user is a newcomer or experienced editor, and provide closer or more relaxed guidance accordingly
  • a slightly modified fair-use rationale template with some extra fields to accommodate the input generated by the script

Some of the workflow also needs to be reviewed. I'm not sure about the whole "work type" section being put in front of the free file options. On the one hand, it's important to catch these misunderstandings (e.g. a screenshot from television is "my own work"), but on the other hand the presence of the many dead ends in that part of the wizard may come across as confusing.

Fut.Perf. ☼ 01:51, 3 February 2012 (UTC)

Comment on Section 3

Rather than refer to "Fair Use" wouldn't it be better to refer to Wikipedia's non-free content criteria? So: ...but I believe it meets all of Wikipedia's non-free content criteria.  – ukexpat (talk) 16:38, 3 February 2012 (UTC)

My first test

Tried a text but the licence I chose a cc attribution licence did not come through on the sandbox page. It showed "undefined". Otherwise I like the concept of making the upload more friendly yet more exact, so copyvios cannot be so easily uploaded or information left out. Good work. ww2censor (talk) 16:51, 9 February 2012 (UTC)

Silly bug, thanks for spotting. I think I fixed it. Can you try again? Fut.Perf. ☼ 17:30, 9 February 2012 (UTC)

Nope, still shows "undefined" after choosing a proper licence. ww2censor (talk) 17:38, 9 February 2012 (UTC)

Tried purging your browser cache? I think one also needs to purge it explicitly on the "withJS=" url, not just on the normal page reload. It's working for me now. Fut.Perf. ☼ 17:41, 9 February 2012 (UTC)

It works now. One suggestion might be to let uploaders know they can make wikilinks in their descriptions. Looks good otherwise. ww2censor (talk) 22:35, 9 February 2012 (UTC)

Seems broken

When I click on "Start the Upload Form", it does not start the Upload form; the "Start the Upload Form" link disappears, but it stays on the same page. —teb728 t c 08:19, 10 February 2012 (UTC)

Ouch. It is in fact supposed to stay on the same page, but it should be showing the previously hidden form questionnaire by that point. Maybe a browser compatibility issue I had no idea of. Could you tell me what browser you are using? Fut.Perf. ☼ 08:27, 10 February 2012 (UTC)

I've tried a bugfix. Could you purge your browser cache on [1] and tell me if it is working for you now? Fut.Perf. ☼ 08:41, 10 February 2012 (UTC)

Still the same. I use IE9 on Win7. My firewall is ZoneAlarm Security Suite. I sometimes trip on blocked 3rd party cookies; do you use any of those? —teb728 t c 10:32, 10 February 2012 (UTC)

 :-( No, the script uses nothing of the sort. The only explanation I have is that the code I used to switch an element from invisible to visible isn't working for your browser. Because the rest of the script was apparently working for you. Must be a very trivial thing. I was previously using "element.style.display = null", which works on Firefox (has the effect of setting the display attribute back to default, i.e. visible). I now tried changing the code to the jQuery wrapper "$(element).show()". Are you sure both the script page (MediaWiki:UploadScriptDemo.js) and the wizard page itself were properly cache-purged for you when you tried it again? Fut.Perf. ☼ 10:46, 10 February 2012 (UTC)

I don't have this issue with Firefox 9.0.1 for Mac but will try some other browsers to see if I can recreate this problem for you on a Mac. ww2censor (talk) 11:22, 10 February 2012 (UTC)

OK, so I found the same issue with only on browser: OmniWeb 5.11 but the page just stays the same with the link visible. All other browsers, Safari, Opera, SeaMonkey, Camino,Google Chrome and iCab worked fine to bring up the form. I did not test any further. ww2censor (talk) 11:54, 10 February 2012 (UTC)

Thanks for this. The issue in OmniWeb must be a different one. Turns out OmniWeb may be one of the few browsers that still don't support the "getElementById()" function. Maybe I'll have to write a workaround for that? Fut.Perf. ☼ 12:09, 10 February 2012 (UTC)

I've replaced all calls to getElementById with something from jQuery, which I hope should be valid across browsers. Fut.Perf. ☼ 12:35, 10 February 2012 (UTC)

Yeah! It works for me now. —teb728 t c 18:40, 10 February 2012 (UTC)

teb728 tests

Looking at the non-free section:

• "The file will serve an important function in an article": The important function has to be reader understanding.
• At first I tried to skip over the article name, and I was surprised that the buttons in the rationale section were inactive. If you are going to make them inactive, maybe don't display the rationale section until there is an article name.

—teb728 t c 19:11, 10 February 2012 (UTC)

Will change the thing with the disabled controls; good point. That was a leftover from an earlier stage where I had the system make much more use of that, trying to force the user to do things in a specific order, but then I felt it was not very user-friendly that way. – As for the wording of the NFC notice, I was trying to find an "in-a-nutshell" formulation that gets the central idea across in as few and as simple words as possible. The "important function in an article" is actually meant to hint not just at NFCC#8, but also #5, 6 and 9. Fut.Perf. ☼ 11:36, 11 February 2012 (UTC)

Oh, by the way, just in case it wasn't clear: everybody please do feel free to edit the questionnaire if you have a good idea about improving the wording. I protected the page against likely vandalism, but it's still a wiki after all :-) You will find that almost all the text of the questionnaire is actually simple wikitext hidden in Wikipedia:File Upload Wizard. Just be careful not to mess up the nesting tables code, because it's a bit messy. Fut.Perf. ☼ 11:46, 11 February 2012 (UTC)

Some statistics

Just as a background for possible later testing: here's the sad statistics of the dysfunctionality of our current upload system. I took a sample of 1,000 file uploads from 1,000 different uploaders during January 2012. 37% of these files had been deleted by mid-February (plus a few more still being nominated). 26% of all files were deleted for licensing/copyvio issues (per PUF or speedy for bad license, lack of info, lack of evidence or obvious copyvio). 17% of all files had obviously bad description pages at the time they were deleted or first edited by somebody other than the uploader (either completely blank, or with preloaded standard templates but crucial fields or all fields left blank).

For new uploaders, the figures are dramatically worse: almost 70% deletions, 57% licensing/copyvio deletions, 38% bad description pages.

Just so we have a benchmark against which to compare stuff, in case we get to test the new system on real newcomers some time. Fut.Perf. ☼ 23:41, 10 February 2012 (UTC)

	user contribs before upload			total
	<30	<100	>=100
total uploads (January 2012)				14,310
total new files (January 2012)				10,623
total in sample	205	200	595	1,000
survived	48	89	443	580
deleted	143	100	128	371
other outcomes	14	11	24	49
% deleted	69.8	50.0	21.5	37.1
copyvio/licensing deletions	116	81	66	263
% licensing deletions	56.6	40.5	11.1	26.3
NFC speedies	10	4	17	31
other deletions	17	15	45	77
tagged for deletion	80	67	101	248
completely blank description page	53	34	18	105
blank template	24	18	27	69
%incomplete/blank description	37.6	26.0	7.6	17.4

Browser locked up solid

I don't knoiw what you did recently but when I clicked on the upload button I got a message about could not move something and my whole browser locked up solid, so I had to force quit the browser and did not try again. I'm using Firefox Mac v 10.0.2. Cheers ww2censor (talk) 12:20, 20 February 2012 (UTC)

Oops. Sorry about that. I'm doing some testing with a local copy of the script right now and made a few changes to the page to match the changes in the local script. Should be back to normal soon. Fut.Perf. ☼ 12:36, 20 February 2012 (UTC)

Will check again sometime later. ww2censor (talk) 13:58, 20 February 2012 (UTC)

Now I can't choose a file as there is no browse button or field to type a file name, but browser does not lock up on me. Perhaps this last edit caused it as that seems to be the choose a file section code. ww2censor (talk) 16:49, 21 February 2012 (UTC)

Grrrhhrrrhhmph :-(. But I think this time it's just another browser cache issue. Please make sure you purge your browser cache not just on the wikipage itself, but on the wikipage as loaded through the "start the wizard" link, i.e. with the "withJS" parameter. This is happening because the version of the script your browser is using is out of sync with the current page. Sorry for the trouble. Fut.Perf. ☼ 16:56, 21 February 2012 (UTC)

BTW, I made that change in order to have identical "id" and "name" parameters on the file input element, having read that there might be problems otherwise. Though I have to say it didn't solve the compatibility problems with IE I'm having. Fut.Perf. ☼ 16:57, 21 February 2012 (UTC)

I uploaded File:Stamp Irl-USA sept 39 censorHS.jpg but because the template I was using is a redlink on this wiki I used the commons upload button and besides refining a few bits it worked out pretty fine. ww2censor (talk) 17:22, 21 February 2012 (UTC)

Thanks for confirming this! The send-to-commons functionality ought to be pretty safe, technically, except for possible incompatibilities between licensing tags (but all the ones standardly used by this wizard ought to be present on Commons, at least). What I'm still mostly concerned about is the actual local uploading code and how compatible it is across browsers. I somehow couldn't get it to work on IE8 today, and have no idea why. The form.submit() mechanism apparently just didn't send the file data. Fut.Perf. ☼ 17:37, 21 February 2012 (UTC)

I do not like it

As it is now the notice about Commons is very small and you get the notice to late. I think the number of free files uploaded to en-wiki instead of to Commons will be much bigger with the new version.

If the photo is free then uploader should be forwarded to Commons unless they specificly chooses "No I do not want the file on Commons" and if they choose that they should be send to a manual upload page. It should be much easier for users to upload free files on Commons than on en-wiki so we should not make the upload of free files on en-wiki easy. --MGA73 (talk) 17:47, 24 February 2012 (UTC)

Well, if you want A to be easier than B, then I guess the best solution is to make A as easy as possible, but not to make B artificially difficult. And sending people to a manual upload page would go counter to the primary purpose of this whole thing, which is: avoiding copyvios and poorly described files. I really think that is the first and foremost priority about what needs to be fixed about our upload process. The issue of choosing between local and Commons uploads really doesn't come anywhere near it. Fut.Perf. ☼ 17:53, 24 February 2012 (UTC)

Commons was easier untill the upload wizard was copied to en-wiki. How are we going to make A easier than B if all improvements on A is copied to B?

And the old upload form had very big notices about Commons. They are now almost invisible. I think that only unfree files should be uploaded to en-wiki so I do think that it is a relevant issue to discuss. We could for example remove the option to upload free files with the upload wizard. --MGA73 (talk) 17:58, 24 February 2012 (UTC)

Sorry, but I'd be very strongly opposed to that. Under the old system, with its huge notices, were were getting massive numbers both of free files "falsely" uploaded here, and of allegedly free files that were copyvios. First priority is to reduce the copyvios; second priority is to reduce the local files. The old system failed to achieve either; that much is certain. Fut.Perf. ☼ 18:01, 24 February 2012 (UTC)

There are two problems. 1) Users that do not understand the system and 2) users that are trying to cheat. Both systems will fail option 2. What we can do to help users in category 1 is to ask uploader a few questions before they get to the upload wizard. If the file seem to be free then we could send them to Commons. If the file is not free then users should be told not to upload it or to upload it as fair use and then send them to the upload wizard. --MGA73 (talk) 18:22, 24 February 2012 (UTC)

Not sure I get what you're saying. "Ask the uploader a few questions"? But that's exactly what the wizard does. Sending them through one wizard first just in order to let them enter the real wizard afterwards? That doesn't sound very useful. Fut.Perf. ☼ 18:31, 24 February 2012 (UTC)

(ec) Maybe to put your mind to rest a bit: this thing has now been online for about two hours. During this time, only two images marked as free have been uploaded through it (one a copyvio, one apparently legit). That's a pretty low rate. Of course we don't know how many uploaders came here and decided not to upload, and why (realized it wasn't legit? went to Commons instead? Didn't understand the form and gave up?) But if this first impression is representative, then perhaps the system is actually more successful at avoiding unwanted uploads than you'd have thought. – One thing we might do to get better data, but I'm not sure if there'd be consensus for that, is this: when the user presses the "go to Commons" link, it could cause their account to first automatically make a log edit somewhere, registering the intended filename, so we could track how many people actually went to Commons from here. I'm just not sure if that would be okay, "ethically", because it would mean making an automated edit that the user didn't explicitly authorize, through their account. Fut.Perf. ☼ 18:29, 24 February 2012 (UTC)

(ec) Oki. Maybe it is not that bad after all. It turns out that if you click long enough a "Upload to Commons" button appears. That is good.

But I still think that there should be a bigger notice on top with a notice "If you upload free files go to Commons." and "If you want to upload many free files Commons has an upload wizard that makes it easier for you" or something like that.

As for the files found on the Internet there should be a notice about Flickr, Panoramio etc. that they must be uploaded to Commons to get a license review to make sure that they will not be deleted if the Flickr user (etc.) should change the license to one that is unfree.

Anyway I hope that it will work and I do appriciate that someone try to do something to get less copyvios uploaded. So thank you for that. :-) --MGA73 (talk) 18:35, 24 February 2012 (UTC)

Another idea. Once a file is uploaded perhaps 1, 2, 5 or 100 (?) users that check the same file to see if it is ok. But we can't see if a file has been checked unless it has a no source, no permission etc. Perhaps we should implement a review system. That way there is a chance that all files are checked and only checked one time. But that should probably be discussed somewhere else. --MGA73 (talk) 18:52, 24 February 2012 (UTC)

True, that will be useful but it's something that goes for all image uploads, independent of how they're uploaded. By the way, sorry I wasn't aware you hadn't yet noticed the existence of that "Upload-to-Commons" button. It's true it's currently a bit hidden. I should tweak the script so that it makes it visible at an earlier stage, as soon as the "free file" option is chosen. Another idea is that the files that are sent to Commons through that button might get a special tag added to their Commons description, as another tracking method. About the information you suggest to be added, true, all of those things are very useful for an uploader to know. I'm only a bit wary of the danger of information overload. I think that's been one of the big problems of the old system; people tried to cram too much instruction into those pages. I think the issue is to find a good balance and prioritize the information. Fut.Perf. ☼ 19:01, 24 February 2012 (UTC)

What if we were to switch steps 1 and 3 around, so that you don't have to go through steps 1 and 2 to find out, for example, that if your doesn't fit any of the categories above, it doesn't belong. Or that if it is a free file you can upload it to commons. Perhaps the the subsequent parts of step 3 don't belong before choosing the file, but that way at least they don't go through steps 1 and 2 unnecessarily if they decide to upload it to commons, or if it isn't fair use. - SudoGhost 07:18, 25 February 2012 (UTC)

Hmm. I guess switching the order between steps 3 and 1 would be fairly easy. But then, that too might lead a n00b user into blind alleys. For instance, what if they spent a long time sweating over the copyright stuff of Step 3, only to come to Step 1 later to discover that they can't technically upload a file that's not yet on their own computer but only somewhere out on the web? – Splitting Step 3 up into an initial pre-questionnaire to decide between free and non-free status and then the main questionnaire to enter the actual sourcing stuff might be possible but would require quite a bit more rewriting, both of the wikipage and the javascript logic. Also keep in mind that there are several places where a user might discover only while working on the details of the free sourcing/licensing that the piece isn't free after all. About the workflow of when the user should be sent to Commons, there are currently three points: (a) right in the beginning, when they see the entry in the "alternative upload methods" in the navbox (admittedly small); (b) in the middle of the process, after completing steps 1 and 2 and on beginning step 3, when they click the "free work" option; this link will lead them to the Commons Wizard, which means they have to start over but get the most comfortable uploading method available on Commons; (c) at the end, when they have completed the whole questionnaire; this link goes to the plain old upload form on Commons, but preserves the work they have already done about the sourcing. Fut.Perf. ☼ 10:04, 25 February 2012 (UTC)

Regarding the comment above "First priority is to reduce the copyvios; second priority is to reduce the local files. The old system failed to achieve either; that much is certain."

People are going to upload copyvios no matter what wizard we use, and no matter where we shoot people to. This is because a good number of people are stupid don't read or follow basic instructions. Under this system, most of the uploads, both truly free and copyvio, will wind up here. This creates the dual problem of having to deal with copyright violations and having to transfer over the free files (we get between 50 and 100 a day). Instead, we should try to direct all of the images people are claiming to be free over to Commons. Yes, that means that commons will have to deal with the copyvios, however this is actually the ideal solution. This is because Commons has 250 reviewers and 300 admins, all of whom are willing and able to deal with files that aren't as free as they claim to be. Wikipedia has about a dozen users in total, a third of whom are admins, that do file work of any type at all. In short, there are going to be copyvios no matter what we do, we might as well send them to the place where they will actually be found and dealt with. That's Commons, not Wikipedia. Sven Manguard Wha? 18:00, 25 February 2012 (UTC)

It's certainly not my impression that Commons has been more efficient at filtering out copyvios than en-wp, rather the contrary. And after observing the first 24 hours worth of uploads with the new system, it's also certainly not my impression that it is less efficient at persuading people to go to Commons than the old system. Rather the contrary. Fut.Perf. ☼ 18:14, 25 February 2012 (UTC)

Not sure we can judge by what happend the first 24 hours. I bet that we were many users that checked the uploads made in the first hours and tagged with "no whatever" minutes after the file was uploaded if there were a problem. I also think that the Commons drive get many users to check new uploads. Anyway we will know more in a few days when we have seen more uploads. --MGA73 (talk) 21:30, 25 February 2012 (UTC)

I'm reading the logs, obviously, so I'm also including files that have already been deleted in the meantime. On Commons, this can now be used for tracking. Fut.Perf. ☼ 21:35, 25 February 2012 (UTC)

It was suggested above that we do not select the file to upload before we are sure the file is ok. I think that in most of the cases where uploader aborts it is because (s)he finds out that the file is not ok for Wikipedia/Commons and not because it is not stored on her/his pc so swapping sounds ok to me.

As for the notice to get users to upload to Commons we could change the notices to

• Click here if you know the file is free (upload to Commons) [Link to Commons upload form]
• Click here if file is unfree or you are not sure etc. (upload to Wikipedia) [Link to WP upload form]

Then the Commons option is more visible. --MGA73 (talk) 09:24, 26 February 2012 (UTC)

Well, not quite: if the file is non-free, it makes no sense to show them the Commons button at all. This is the one thing where we really cannot give them any choice. Whether it is free or not follows from the initial option button choices while doing Step 3; it's no longer open to choice by the time they are ready to submit. And if they are "not sure" about whether it's free, then they must be told to not upload anything at all but ask at Wikipedia:Media copyright questions first. – About the order of steps, I'll have to think about what changes in the script that would necessitate. Another issue to consider in that respect is those editors who come here not to upload a new file but to overwrite an old one, or indeed who really don't want to upload anything at all but merely to change a description page and haven't yet understood they can simply click "edit" on the file page. These are very frequent cases among newcomers, and for them the early file name selection is important.

Back to the "how to get people to Commons" issue in general, I see the argument as articulated most clearly by Sven Manguard above, but at the same time, I think the same argument can be turned upside down and still make just as much sense. Sven is saying: "people will continue to upload copyvios no matter what we do, so if we can't stop them from doing that, let's at least make sure to send as many of them to Commons as possible". What I'm saying is: "people will continue to upload locally no matter what we do, so if we can't stop them from doing that, let's at least make sure to prevent as many copyvios as possible." Fut.Perf. ☼ 12:02, 26 February 2012 (UTC)

What I meant with the 2 links was that if they are sure it is free they could be send to the upload wizard on Commons at once. If they are not sure they could use the upload wizard on en-wiki and hopefully find out if it is free or not free before they upload (there is a few "stop signs" or warnings in the upload wizard). --MGA73 (talk) 16:43, 27 February 2012 (UTC)

Here's one possible model of how the form could be restructured that might satisfy us both:

1. remove the whole structuring of "Step 1 – Step 2 – Step 3"
2. instead, start out just with the three option buttons that are currently Step 3, with the next logical level below them already visible – i.e. let the user peruse those twelve or so main option types to get a first orientation of what is or isn't possible, and what "free" and "non-free" means.
3. move everything else, including the file selection box and description textfield, into the details form area that opens up when you click on one of those main options.
4. Show the "Why Not Go To Commons?" nag screen, possibly as a popup window, when the user clicks on any of the five free file type options – i.e. at a time when they have already read through the most crucial copyright-related criteria, but haven't yet spent time typing anything in.
5. Keep the "Submit to Commons" button as an alternative way of getting to Commons at the end of the process, as it is now.

How about that? Fut.Perf. ☼ 17:33, 27 February 2012 (UTC)

Not working

Clicked to start and it returned to same page. Used the old form instead.REVUpminster (talk) 21:05, 25 February 2012 (UTC)

Thanks for reporting this. Could you tell me what browser you are using please? Also, was this the first time you visited this page, or had you perhaps loaded it at some earlier date (in the latter case, there might be an issue with an outdated version of the script still being in your server cache.) Sorry about the problem. Fut.Perf. ☼ 21:26, 25 February 2012 (UTC)

• I use windows 7 and Internet explorer 9 or 10 I think and it was the first time this new upload page appeared. I tried again a few minutes ago and it is now working so I had a look at it. I specialise in screenshots of titlecards for infoboxes and cast lists per the manual of style so i am mainly on english wikipedia (I have uploaded a few items to the commons and foreign wikis) and the old form with the non-free rational form provided to fill in was easy to use. This new process looks more complicated but I will give it a go when I come across a new titlecard to upload if this new process survives but I think there will be a lot of complaints.REVUpminster (talk) 07:35, 26 February 2012 (UTC)

Choose your file - finicky?

Using FF 10.0.2 - Needed to "Choose your file" 3x before it "took" - rest of the materials were correct, wasn't picking up that field. Also, at the completion of the upload, the preview image was about 30px X 30px, too small to determine success or not! Skier Dude (talk) 02:49, 26 February 2012 (UTC)

About the sluggish behaviour on picking the file, the only explanation I have is that at that point the script may be making an API request to determine if a file already exists under the chosen name. If you do that step at the end rather than at the beginning, and the API happens to be slow for some reason, then the script will fail to set the submit button enabled immediately. About the thumbnail size, the script uses a fixed width of 120px, which means that a wide-format image might end up with a rather small height. If you're talking about File:Hawthorne girl school logo.png, are you sure the whole image was only 30x30? Because in that case I'd have no idea how that could happen. Or was it just the embedded logo at the right edge of the image, as in [2]? Fut.Perf. ☼ 06:54, 26 February 2012 (UTC)

Confused about how to label a photo

I have a photo to upload that was given to me by its owner. My impression is that he is only granting permission for me to use this on the specific Wiki page that I'm currently putting together rather than offering it for everyone to use. I'm not sure if any of the 3 categories currently listed on the file upload wizard pertain and would love it if someone could let me know how best to proceed on this. Thanks. — Preceding unsigned comment added by Canamets (talk • contribs) 22:00, 26 February 2012 (UTC)

Hello, thanks for asking. I'm afraid from what you're saying, it sounds like there's probably no way we can use that image, unless you can persuade the owner to grant a more far-reaching license. The only alternative would be if you could make a case for "fair use". Is it an historical photograph? If it is old and unreplaceable, you might be able to make a case under our WP:NFCC rules. However, this presupposes that the photo was previously published somewhere. If it was merely a private photograph somebody had in their personal collection, fair use is out. Fut.Perf. ☼ 22:10, 26 February 2012 (UTC)

Hi, and thanks for the quick reply. The photo in question is a shot of the cover of a piece of music published perhaps 100 years ago that this person I'm assuming took on his own. He owns the music outright and, to the best of my knowledge, the publisher is long since defunct. It may well be that the owner will allow it to be used as you say in a more far-reaching way. If this turns out to be the case, what would you suggest would be the best way for me to so indicate this when I try and upload it? Would I need a document from the owner, an email, or something else perhaps? — Preceding unsigned comment added by Canamets (talk • contribs) 01:39, 27 February 2012 (UTC)

Thanks for this. If it's a photograph of a printed piece of sheet music from the early 20th century, then we can treat it as "public domain" – the photographer doesn't actually own any copyrights on it, because the photograph itself is a mere reproduction, and the original print is out of copyright if it was published before 1923. You could upload it using the option "This work is so old its copyright has expired", under "free works". Fut.Perf. ☼ 07:14, 27 February 2012 (UTC)

Terrific. Thanks again! — Preceding unsigned comment added by Canamets (talk • contribs) 15:24, 28 February 2012 (UTC)

Syntax of the desc page for files uploaded to COM

Apparently everywhere {{en}} is added. That is not good. Dates should be entered simply in ISO (yyyy-mm-dd) notation. The author field does not really need the "english" tag. That is just what I noticed just now. I would only add the "en" to the description. Cheers --Saibo (Δ) 23:58, 26 February 2012 (UTC)

Point taken. Will change that. Fut.Perf. ☼ 06:48, 27 February 2012 (UTC)

uploaded without a license?

Here - I had guessed that this is not possible with this wizard. Even the source does not show up (apparently syntax errors). --Saibo (Δ) 00:14, 27 February 2012 (UTC)

There was a problem with some license tags that didn't match exactly between this script and the dropdown box in the Commons form; this has been improved in the meantime and should not be happening again. Thanks for reporting. The other thing must be about the overuse of the "{{en}}" tag you mentioned above. Also now fixed. Fut.Perf. ☼ 07:07, 27 February 2012 (UTC)

Final upload button shadowed

I filled in all the boxes to upload a website screenshot and the final upload box never became available for me to click. I filled in everything and checked twice. I wish it would declare what is wrong if it does not like my work. Blue Rasberry (talk) 01:21, 27 February 2012 (UTC)

My apologies, that was a bug. Should be fixed now. (When you try the next time, please purge your browser cache after clicking the "start" button, to make sure you get the new, corrected version of the script.) Fut.Perf. ☼ 07:04, 27 February 2012 (UTC)

I'm having the same problem. All fields are completed bu the upload boxes are grayed out. BlueGold73 (talk) 14:02, 29 February 2012 (UTC)

Actually now it's appearing, but I had to wait several minutes before the buttons stopped showing up as grayed out. BlueGold73 (talk) 14:04, 29 February 2012 (UTC)

I'm having the same problem. All fields seem to have been filled out properly, yet the upload button is grayed out. __meco (talk) 13:36, 1 April 2012 (UTC)

Could you say which of the main options you were using? Fut.Perf. ☼ 13:49, 1 April 2012 (UTC)

I was uploading a copyrighted logo. __meco (talk) 13:52, 1 April 2012 (UTC)

Strange. I'm afraid I can't reproduce this, so I have no idea what might cause it. Fut.Perf. ☼ 13:55, 1 April 2012 (UTC)

OK, you'll just have to be on your toes on this one then. __meco (talk) 17:52, 1 April 2012 (UTC)

Categories?

For COM-Uploads. Are there no ones added usually? Does the user has no chance to? If possible then {{subst:unc}} should be added. A sidenote: please have a look in the COM:VP section. --Saibo (Δ) 12:51, 27 February 2012 (UTC)

I know, the thing with the categories is a bit of a problem. Our local uploads typically aren't categorized, so the wizard doesn't contain functionality for that, and of course it doesn't have access to the categories at Commons. It does include a request to the uploader to add categories manually, in the message screen shown before they are forwarded to Commons, but that is fairly easy to overlook, or users may easily fail to understand what's meant by it. Not sure how to overcome this:

• Create a better message screen, using not a simple browser alert() box but a jQuery .dialog(), which can have formatted wikitext and could contain a richer set of instructions. (I'll be working on that.)
• Add some instructions in html comments in the preloaded description text sent to Commons
• Add {{subst:unc}}, as you say.

Fut.Perf. ☼ 13:31, 27 February 2012 (UTC)

Well, you could try to borrow the category adding code (with auto-suggestions) from the COM:UW. But probably that is far from easy. That said, the COM:UW hides it's category selector that good that most uploads are also without categories (subst:unc is added then). ;-) --Saibo (Δ) 13:40, 27 February 2012 (UTC)

I think categorizing files is just objectively a very difficult thing to do for a newcomer. If you have no prior experience with how the category system works, little to no understanding of what its purpose is, no way of quickly looking up how the whole category hierarchy is structured, and nothing telling you what possible categories might exist and how they might be named, it's basically a hit-and-miss, even with the help of that autocomplete feature. By the way, the reason why the Commons UW often produces files without categories might be not so much because the selector is "hidden", but because it's so stupidly designed that you have to not just input a category name, but separately hit a "save" button for it to make it stick, unlike with all other stuff you put into the form. That's very easy to miss (has happened to me too). [<rant>And since we're at it, why is it that the popup helps that are supposedly meant to be shown when you hover or click on all those little question marks in the wizard's labels aren't working for me on FF10? And why is it showing me that big distracting "Learn > Upload > Release rights" bar at the top, always making me expect I can click on it for navigating between the steps, but then I can't? Something makes me think the wizard isn't quite as well designed as the public-relations-speak of the people who so proudly put all their resources and nifty testing methods into it [3] wants us to believe :-P </rant>] Fut.Perf. ☼ 16:31, 27 February 2012 (UTC)

Please do not rant about COM:UW here... :-D And yes, we^TM (or I) know that COM:UW is quite fucked up (since it was released). See commons:Commons talk:Upload Wizard. The error that you cannot click on the labels and generally have no way to navigate back and forth is known since probably a year... That the category picker has a confusing UI even if someone finds it is known, too. The servers are currently being not really available, cannot the the ?-bubble boxes... By the way: if you get those open, it is confusing to get them closed again: bugzilla:34337.. Cheers --Saibo (Δ) 17:27, 27 February 2012 (UTC)

author field with "own"

{{own|[[User:Nixenzo|Nixenzo]]}} e.g. at commons:File:CCP Tanghalang Nicanor Abelardo.jpg. That is probably not intended. ;) --Saibo (Δ) 12:57, 27 February 2012 (UTC)

Dang. The Commons "own" template doesn't take the author name as an optional parameter? Ours on en-wp does. :-( Better like this? [4]. Fut.Perf. ☼ 13:14, 27 February 2012 (UTC)

Looks better, yes. Thanks. Commons has a very useful template by the way: {{self-photographed}}. I personally think it is more clear than "own work" since it makes it clear that it does not refer to any depicted work. --Saibo (Δ) 13:28, 27 February 2012 (UTC)

Confusing licensing info at uploads at COM

Quite often confusing licensing info like in commons:File:Asiel Snow Founder of Snowville,VA.jpg - but at least it is not simply labeled "own work" without any other information... that makes it obvious and easy to detect problematic files. However, from today's uploads in commons:Category:Uploaded_with_en.wp_upload_wizard it gets obvious that this uploadwizard does not really lead to a good upload. ;-) My first impression. --Saibo (Δ) 13:10, 27 February 2012 (UTC)

About cases like commons:File:Asiel Snow Founder of Snowville,VA.jpg: I'd say that's "a feature, not a bug". We can't really stop people from misunderstanding the "own work" option, but with this wizard, they are at least tricked into revealing enough other information to make it easy to detect. (I'm not quite sure what you were saying in your second sentence; somehow the grammar has gone astray there :-) Fut.Perf. ☼ 13:18, 27 February 2012 (UTC)

Before I saw your comment I made my mind up: the thing is: probably all users who use this wizard are newbies - so the uploads are kind of "newbie only". So this cannot be compared that easily to other means of uploading. As soon as the users know about licensing they will maybe stop using this wizard. So it could be that only "shit" is uploaded with it... but that is much better than the plain "own work" claims of so many newbie copyvio uploads with the COM:UW.

Second sentence: hmpf ;-) Added some words... this sentence was not really complete. --Saibo (Δ) 13:24, 27 February 2012 (UTC)

Found one good upload! ... but: the uploader's stats: "195 edits since: 2006-10-09". So that wasn't a newbie. ;-) --Saibo (Δ) 13:38, 27 February 2012 (UTC)

(ec) Yes, I think you hit the nail on the head here. What you're seeing in the new Commons category is representative of the kind of stuff we used to get uploaded here – the people who fail to get the recommendation of going to Commons from the start are typically newbies, and the percentage of problematic or plainly low-quality images has always been very high (see the "statistics" section above). Fut.Perf. ☼ 13:40, 27 February 2012 (UTC)

No, some (fairly) experienced users have tried (and much like) the new wizard. I use Commons, of course, for images I know are free, but for fair-use images this is certainly a good thing if not the obviously-right route. The questions seemed to me considerably less of a nuisance than the previous wizard, and the checking it seemed to do appeared considerably more intelligent, so well done all round. Will report any problems if they arise! Chiswick Chap (talk) 17:12, 29 February 2012 (UTC)

File upload seems to be broken at the moment

File upload seems to be broken at the moment. When I click the "Click here to Start the Upload Form", nothing happens. Banaticus (talk) 21:19, 27 February 2012 (UTC)

Sorry about that; should be fixed now. Please purge your browser cache after clicking start the next time, to make sure you get the most recent, corrected version of the script. Fut.Perf. ☼ 21:46, 27 February 2012 (UTC)

COM uploads: subst:OP instead of OTRS pending

Please use subst:OP instead of OTRS pending Cheers --Saibo (Δ) 00:44, 28 February 2012 (UTC)

Okay. [5]. Fut.Perf. ☼ 09:10, 28 February 2012 (UTC)

I do not see the "subst:OP". Instead there is "Harry Potter and the Order of the Phoenix"?! --Saibo (Δ) 14:34, 28 February 2012 (UTC)

Oh sh.... Why on earth does it treat the {{subst:OP}} string as a substitutable template here on en-wiki when I insert it into a javascript page?! :-(.... Fut.Perf. ☼ 14:45, 28 February 2012 (UTC)

LOL - I understand (no harm done). JS pages are no different from other wiki pages except in display. You have to break such templates with e.g. \. That is a reason why it can be useful to wrap the JS in nowiki tags. ;-) You can also add speedy tags or categories to JS pages to sort it into a category example: commons:User:Saibo/catgraphtabs.js. One question: you even give me a diff link without looking at the diff? ;-) Cheers --Saibo (Δ) 23:30, 28 February 2012 (UTC)

Revert test version please?

Please return me to the normal page, please? I want to upload a file, thanks.--♫GoP♫_T^C_N 13:15, 28 February 2012 (UTC)

Please revert to this good, old version. Thanks.--♫GoP♫_T^C_N 13:16, 28 February 2012 (UTC)

You can still use that form, of course. You can also still use the plain old Special:Upload. However, experience shows that these methods lead to a huge lot of problems because new uploaders don't understand them. Can I ask what exactly you didn't like about the new one? Fut.Perf. ☼ 13:19, 28 February 2012 (UTC)

Complicated, premature and unprofessional. Really confusing, especially for newbies.--♫GoP♫_T^C_N 13:24, 28 February 2012 (UTC)

Well, I regret you don't like it, but this criticism doesn't really do much to improve things. Initial observation shows that newcomers can work with it much better than with the old form (which undoubtedly is a lot more complicated and unprofessional), so I doubt reverting to that will be much of an option. Fut.Perf. ☼ 13:26, 28 February 2012 (UTC)

I'm sure that many people spent many long hours to create this, for which I sincerely thank you. My reaction is: I hope I never have to actually use it again. (and this comes from am "early adopter" type of person). Something simple has been turned into something complex. I can tell it is designed for the newbie user, but even so it has too many "fill in the blanks" that aren't explained until after clicking the button. The previous "complete the pre-filled template" method seems superior to me. Hope you find the comments helpful. Senator2029 (talk) 21:34, 9 March 2012 (UTC)

Heh, actually, no, so far it's basically just one person who spent many long hours creating this :-) – I'm not quite sure what you mean when you say "fill in the blanks that aren't explained until after clicking the button"; could you give an example?

About "something simple turned into something complex": I'm afraid the whole problem is that this is the minimum level of complexity dictated by the subject matter. The decisions an uploader has to make during the upload process simply are this complex (or actually, even more complex than this.) The old form did nothing for guiding people through this necessary level of complexity. Finally, about the "pre-filled template" method: no, that one never worked. From months of frequent patrolling of the image logs, I know that most people never figured it out. Many newcomers, at that stage, haven't even grasped the basics of what a template is, technically; they never realized they were supposed to enter stuff after those equals signs. 15% of all image uploads with the old system came with completely blank description pages. Also, there was nothing explaining what those template parameters meant and what output they would produce. What does "|Purpose=" mean in a FUR template? A very large number of uploaders either left it completely blank, or they thought it referred to the original purpose of an image for its author (so they would enter stuff like "promotion" if it was a promotional image.) What does "|Date=" or "|Source=" mean, when you're dealing with an old public domain item? People had no way of knowing. Fut.Perf. ☼ 21:58, 9 March 2012 (UTC)

Forward slash

I tried to upload an image called "Office of HIV/AIDS Network Coordination". Things seemed to work but then it gave me a bogus link to my file and I could not find it. Eventually I found it as File:AIDS Network Coordination.gif, so it seems to have ignored what came before the slash. I sorted this issue for myself, but maybe others will have this problem too. Blue Rasberry (talk) 19:33, 28 February 2012 (UTC)

Thanks for reporting this. I've added the slash character to the list of characters the script will disallow, and made another change to the response script that reports on the completion of the upload so that it retrieves the actual filename properly, in case there might be other unforeseen situations where the server might have changed it. Fut.Perf. ☼ 20:02, 28 February 2012 (UTC)

I've also taken the freedom of moving your file to File:Office of HIV-AIDS Network Coordination.gif, as being closer to the originally intended name, supposing that's okay with you? Fut.Perf. ☼ 20:08, 28 February 2012 (UTC)

Thanks for appreciating the feedback. I am always thrilled when my contributions matter. I appreciate your moving the file, also. Blue Rasberry (talk) 20:18, 28 February 2012 (UTC)

Upload Button Not Working

Trying to upload an image, I've filled in everything I need to, and the upload button is still unclickable. It shows the Upload button but it doesn't let me actually press it. Benjamin7887

That's strange. Can you tell me which of the main file type options you were working with? Fut.Perf. ☼ 07:13, 29 February 2012 (UTC)

Ah, wait, I see now. In your case, it's because your account is not yet old enough to be technically able to upload files (see WP:autoconfirmed). But the wizard ought to have shown you a message about that at the beginning, did it not do so? I'll check. Fut.Perf. ☼ 07:36, 29 February 2012 (UTC)

I'm also unable to upload an image, and I have had an account for quite some time. Richiekim (talk) 19:13, 29 February 2012 (UTC)

Can I ask which browser you were using, and which of the main file type options you had chosen? Fut.Perf. ☼ 19:15, 29 February 2012 (UTC)

No default filename

I really do not like this. I also do not like that everything is cluttered up on a single page, making the upload process seem more difficult than it is. I really see no reason this isn't modeled on the new Commons uploader, with just the addition of a page for Fair Use and an option to insert your own templates under both the summary and licensing. (This is essential to being able to replace an image with another filetype: it's annoying to have to retype the entire fair-use rationale.) Distinct sections make the process look easier. — trlkly 04:12, 29 February 2012 (UTC)

The lack of an automatically filled in filename is by design. The old mechanism that just copies over the local filename from the user's harddisk leads to too many poorly named files (often much too generic, or random strings of the "DSC0012345.jpg" type). We actually want to force the user to give some thought about how to best name the file, and there's no reason to expect that what was a handy filename for local storage will also be a good filename for Wikipedia in most cases.

About whether to divide it into several pages, well, I guess that's a matter of taste then – I for one find the structure of the Commons wizard with its rigid separation of stages annoying (you can't even navigate back and forth between them). There are also a number of other factors, both technical and design matters, that would have made a direct adaptation of the Commons wizard not an optimal solution, in my view.

I'm not quite certain what you mean by "option to insert your own templates" – there is in fact such an option; you can put whatever tags you like in the "description" box at the top and in the "any other info" box at the bottom, and you can also enter alternative license tags in several of the file categories. However, in the scenario you seem to be thinking of, where you are uploading a new version of a pre-existing file with an identical description page but a different extension, you are certainly better off using the old, plain form (think of it as a kind of "expert mode" that allows all sorts of rare extra things.)

Fut.Perf. ☼ 07:33, 29 February 2012 (UTC)

Test?

hello,

when will the "beta version" period end? Regards.--♫GoP♫_T^C_N 10:15, 29 February 2012 (UTC)

Personally, I'd propose letting it run until at least 4 March as a start, by which time we should have some first, reasonably reliable statistical data based on a full week's worth of uploads. Once we have that, we can decide whether to keep it running, make the old system the default again, or start a new test with an improved version later. Fut.Perf. ☼ 10:47, 29 February 2012 (UTC)

I was going to upload a photograph but

I was going to upload a photograph, but having spent some time looking through all this palaver I shan't bother. I don't upload to the Commons, much too complicated for an old dear like me. I learned to upload to enwikipedia but refuse to learn how to do something more complicated. Wikipedia's loss, not mine.J3Mrs (talk) 15:07, 29 February 2012 (UTC)

That's regrettable. Did you see that you can still access the old form if you prefer that one? The thing is, the files you have been uploading are real, good, honest, self-made photographs; just the kind of work that we really ought to welcome most; and for this kind of work, uploading indeed ought to be easy. The trouble is that so many other people are trying to upload other stuff where the copyright situation is far more complicated (fair-use stuff, photos they didn't take themselves etc.), and unfortunately the upload forms have to be so complicated in order to catch all these other cases. Fut.Perf. ☼ 16:48, 29 February 2012 (UTC)

I can no longer be bothered. Why should I have to jump through hoops to provide free images to Wikipedia? I didn't see the old form or I would have used it, but .....well it's supposed to be my hobby not something to wind me up. Odd isn't it, anybody can edit wikipedia, even vandalise someone's perfectly good work, but good-faith editors who are useless with computers and find these things so complicated are driven away. J3Mrs (talk) 17:24, 29 February 2012 (UTC)

At the bottom of the upload page there are links to all the other upload pages. I presume one of these is the one you are familiar with. Try again. ww2censor (talk) 18:15, 29 February 2012 (UTC)

Thank you, yes now I see it, but it wasn't obvious to me when I was feeling miffed at the change. I won't be uploading anything as I've lost interest and run out of patience. J3Mrs (talk) 19:50, 29 February 2012 (UTC)

Simplification made

After observing the incoming files, I deactivated the first subsection under "free files" with its questions about various types of derived works. This section appears to have added too much complexity for too little benefit and rarely produced good output.

I apologize for likely browser cache problems that will be experienced by people who have visited the form before and reload it now; they will initially see a few error messages. Please make sure to purge your browser cache after clicking on the start button. Fut.Perf. ☼ 19:39, 29 February 2012 (UTC)

Statistics after first week of test run

January sample (1–31 January; 1,000 out of 10,623 files)
		Newcomers		Other editors		Total
		N	%	N	%	N	%	approx. per day
Free	bad	194	48.0	83	22.0	277	27.7	94.9
	ok	85	21.0	131	22.0	216	21.6	74.0
Non-free	bad	58	14.4	55	9.2	113	11.3	38.7
	ok	52	12.9	312	52.3	364	36.4	124.7
Other		15		15		30
Total		404		596		1000		342.7
Sample from Wizard test run (26 February – 4 March, 1,016 out of 2,050 files)
Editors using the File Upload Wizard
Free	bad	42	16.3	8	2.9	50	9.3	16.4
	ok	85	33.1	55	19.8	140	26.2	45.9
Non-free	bad	34	13.2	15	5.4	49	9.2	16.1
	ok	94	36.6	184	66.2	278	52.0	91.2
Other		2		16		18
Total		257		278		535		175.6
Editors using the wizard's "upload to Commons" button
bad						112	22.0	16.0
ok						396	78.0	56.6
Total						508		72.6
Editors using the old upload methods
Free	bad	75	36.6	26	8.9	101	20.3	33.1
	ok	71	34.6	72	24.6	143	28.7	46.9
Non-free	bad	19	9.3	16	5.5	35	7.0	11.5
	ok	40	19.5	176	60.1	216	43.4	70.9
Other		0		3		3
Total		205		293		498		163.4

Discussion

So, here's my evaluation of the statistics above.

tl;dr summary: In conclusion, I believe the first week's results show that the new WP:File Upload Wizard has an overall beneficial effect increasing the quality of our uploads and decreasing the number of problematic uploads. I therefore propose leaving it in place as the default upload entry point for the time being. Fut.Perf. ☼ 09:37, 6 March 2012 (UTC)

Could we not make this a User Preference?

I have to say I don't like this form - I'm sure it's far more effective when you don't know which templates etc you're supposed to be using - however when you do it just makes the whole process much slower. It would be good, for those users who aren't too keen on this approach, to be able to set the default to, say, the "plain form" if desired. Is this at all possible? Thanks, Nikthestoned 16:14, 7 March 2012 (UTC)

Hmm, I see your point. I guess it would be possible through a Gadget manipulating the "Upload file" link in the sidebar, making it point either to the one or the other form. These days, I understand Gadgets can be both opt-in and opt-out (i.e. activated by default), so I guess we could choose which of the two forms would be the default for new users. With a bit of tweaking it might even be configurable to choose between all three forms (WP:FUW, Special:Upload and Wikipedia:Upload/old) Given the apparent advantages for new users, I'd suggest to keep the wizard active by default though. I'm not too sure about how to write and install Gadgets, so I'd like to get some advice from the tech gurus on this. Fut.Perf. ☼ 16:22, 7 March 2012 (UTC)

Commons has such a preference: in the gadgets tab there is a checkbox "UploadWizard: Upload Wizard. Especially useful for new users.". If set, you get commons:Special:UploadWizard; if cleared, you get commons:Commons:Upload. --Redrose64 (talk) 16:41, 7 March 2012 (UTC)

Great, that's good to know. As soon as I find some time I'll try and figure out how it works. Fut.Perf. ☼ 16:47, 7 March 2012 (UTC)

Thanks guys, that's great! I'm finding this especially troublesome as I lose the ?wpDestFile=foo.jpg part of the URL when clicking on the "plain form" link in the navbox at the bottom... Nikthestoned 17:08, 7 March 2012 (UTC)

True. But then, that never worked with the old system either, did it? I mean, when you were led to the Wikipedia:Upload page from an image redlink. Or are there other situations too where ?wpDestFile= parameters get passed in from somewhere? Fut.Perf. ☼ 17:10, 7 March 2012 (UTC)

Previously, the redlink would take you to a page where you could "Create" the image page (for files that already exist on Commons) or click a link through to the Special:Upload page. This did indeed maintain the ?wpDestFile= from the originally-clicked-filelink. To be honest I don't think I've ever used Wikipedia:Upload/old - I'm not even sure I've seen it before. Nikthestoned 10:24, 8 March 2012 (UTC)

Wikipedia:Upload/old is what was accessed via the Upload file link in the left-hand margin until 24 February 2012, see this page move. --Redrose64 (talk) 14:28, 8 March 2012 (UTC)

Is that a response to me? I've never used the left-hand-pane upload link either - I just create a filelink like thus: File:Foo12345.jpg; and click it, which exhibited the behaviour previously detailed. Nikthestoned 15:19, 8 March 2012 (UTC)

Odd. We were discussing something similar on WP:VP/T the other day, and people there were saying this kind of image redlink always used to lead to Wikipedia:Upload too (rather than Special:Upload), and Wikipedia:Upload was exactly the page that's now Wikipedia:Upload/old (i.e. before I redirected it here). This is quite confusing, because my own memory also matches yours more than theirs. I suspect there may have been some change related to the introduction of the latest MediaWiki update (1.19), which happened to coincide with that of our wizard. But in any case, it's interesting to hear of somebody doing things this way – I always assumed everybody went to the upload form first and inserted the image code in their pages only afterwards. It turns out we may need more script stuff to fix this, both for those who want to use the wizard and for those who don't. Handling of image redlinks is seriously broken either way. Fut.Perf. ☼ 15:43, 8 March 2012 (UTC)

Update: It seems some changes in the built-in MediaWiki handling of image redlinks are being brought in again with MediaWiki v.1.20, which was deployed on Commons today. Not quite sure yet how it will affect the situation here. Fut.Perf. ☼ 20:25, 16 April 2012 (UTC)

File upload wizard sucks, frankly

When using the previous form, if I selected that the file was a company logo, necessary portions of the rationale would be completed with language to satisfy NFCC #2 and other NFCC requirements. This form only has a couple fields that I can fill in and neither of them enter anything for Author or copyright holder info, explaining why it is not replaceable or respect for commercial opportunities sections. Why did we have to fix something that was not broken? And can I please have my old form back? - Burpelson AFB ✈ 14:17, 9 March 2012 (UTC)

Ok, I see the link up above to /old. I'll use that until someone deletes it. - Burpelson AFB ✈ 14:24, 9 March 2012 (UTC)

Two responses: first, I'd disagree with the claim that the old system "was not broken". Under the old system, 15% of all uploads came through with completely blank description pages or with skeleton licensing templates (preloaded by the wizard) but with all their parameter fields left blank. Almost 70% of all files uploaded by newcomers had to be speedy-deleted for false or lacking licensing information and related reasons. That's what was broken about it. About the treatment of logo rationales, the wizard does in fact produce an automatic standard rationale. It doesn't ask for input for the other FUR components exactly because with logos those parts are so predictable. The idea is to get the uploader's mind off those parts of the FURs that are trivial and redundant, and ask for specific input just about those parts that are not. The rationale templates are documented at Wikipedia:File Upload Wizard/doc. The one for logos is quite brief, much briefer than the output of {{logo rationale}}, but that's by design. Good fair-use rationales should be short and simple, and there's no use in having huge boilerplate pseudo-legalese walls of text about the most predictable and trivial fair use cases.

Of course there's nothing wrong about continuing to use the old form if you prefer that. There's no danger of it getting deleted any time soon. Fut.Perf. ☼ 14:36, 9 March 2012 (UTC)

Only problem with omitting the old wordy legalese is I can remember back when certain folks were going around tagging fair use images for deletion because of what they saw as invalid rationales, or incomplete rationales, etc. I see what you're trying to do here and commend you, but that boilerplate legalese didn't appear in a vacuum. It evolved from certain circumstances. If people think this wizard will help prevent n00bs from boofing their uploads then more power to them. I do think it would be helpful to either give people control at the User Preferences level over which upload interface they see, or else add it as an option to Twinkle or one of the other semi-automatic tools. - Burpelson AFB ✈ 15:00, 9 March 2012 (UTC)

Yeah, that's a long and sorry story, I know. I believe there's been a very counterproductive effect in this whole FUR business over the last few years, leading to an exaggerated focus on the perceived formal "correctness" of rationales much to the expense of focussing on their content. (And I'm saying this as an image deletion hardliner myself when it comes to judging the actual substance of fair-use justifications). – But in any case, I agree about the user preferences thing, as discussed in the section above. There'll be a solution on the Gadgets level, no doubt. Fut.Perf. ☼ 15:21, 9 March 2012 (UTC)

Experience of a new user: ITS BEAUTIFUL

As a new user i was having so much trouble with pictures as the admins kept deleting it for one reason or another (although it was my own work). The new upload wizard really gives you the assurance that you've done things right and it just worked! Thanks...lets just hope a trigger happy admin doesn't delete it again for some reason i cannot understand and then block me from uploading it again!!! (yes I've suffered allot as a new user!) — Preceding unsigned comment added by Immi2k (talk • contribs) 15:15, 10 March 2012 (UTC)

null

When users upload files using the file upload wizard, the file information pages often (always?) end with the word "null", for example here. Is this a bug somewhere in the wizard? --Stefan2 (talk) 20:51, 12 March 2012 (UTC)

Indeed, something that crept in with my latest revision. I'll fix it. Thanks for spotting. Fut.Perf. ☼ 00:10, 13 March 2012 (UTC)

Also showed up on File:Steven L. Rubenstein.jpg (removed). Fixed in the script with this edit. Krinkle (talk) 04:54, 16 March 2012 (UTC)

Evidence: Will be provided on request.

I see a lot of files uploaded using the wizard showing someone else's work and tagged with "Evidence: Will be provided on request." in the permission field in {{Information}}. This is obviously not the right way to do; permission should be sent to OTRS, and yesterday I searched for files containing those words on Wikipedia and Commons, resulting in a large number of files being tagged as "no evidence of permission." Example here and lots of examples here and here. This seems to originate from the upload wizard (step 3: "This is a free work," "This file was given to me by its owner," "I haven't got the evidence right now, but I will provide some if requested to do so"). This option seems to confuse users, so I assume that something should be done here. --Stefan2 (talk) 19:31, 13 March 2012 (UTC)

I know this option is somewhat open to problematic uses, but I included it because I thought it matches current policy. According to my understanding, there is no strict obligation for an uploader to provide OTRS evidence right from the start; they only need to be aware that they might be asked to provide it later on and the file will be in danger of deletion if they don't. Image patrollers are free to either ask for evidence or accept the uploader's word for it on AGF. It's a judgment call. There are in fact situations where I personally tend to do the latter – for instance portrait photographs in bio articles where it's quite obvious the editor/uploader is working on the article subject's behalf, e.g. as a representative/employee of the subject's company etc. I would also tend to accept OTRS-less claims if the uploader was a highly trusted, experienced user.

I also believe giving uploaders the option of declaring this situation openly and acknowledging the lack of evidence gives them a useful incentive for not trying to cheat their way around a stricter requirement, for example by falsely declaring the file as "own work".

The wizard now also adds these files to a temporary tracking category, Category:Files licensed by third parties, which should help with the necessary patrolling work. There are several new categories of this type, all of them representing case groups where problematic uploads in need of review are known to occur. Fut.Perf. ☼ 19:50, 13 March 2012 (UTC)

I don't think that it is an issue if the image is uploaded by an experienced user, but I'm not sure what the exact policy says. I think that the problem is that this checkbox mainly seems to be used by people who don't know how copyrights or licensing policies work and that uploaders using this checkbox typically only have a very small number of uploads. On the other hand, if it prevents falsified data, I guess it might be better to keep the option. --Stefan2 (talk) 20:28, 13 March 2012 (UTC)

Logo uploads are more complicated

All the info you needed under the old system was the article in question and the source. This asks for a lot more information, and makes a lot of it required.

It also means that, if someone uploads a logo with the new system, any curator like myself has to go through and remove the extra information that is often times worse than the default. So both the uploader and the maintenance people have to do more work.

I still don't understand what was wrong with asking what type of image you were uploading before presenting any fields to fill out. — trlkly 05:54, 16 March 2012 (UTC)

Can you be a bit more specific about which parts of the questionnaire you feel are unnecessary, and what bad data it produces that has to be removed afterwards? If there's anything wrong with the default rationales it produces, that should be easy enough to tweak. Fut.Perf. ☼ 07:29, 16 March 2012 (UTC)

Integrating into MediaWiki

Hi. How much research has been done into integrating this type of improved upload functionality into MediaWiki? Or alternately using an extension such as UploadWizard?

I appreciate all the effort you've put into this, but frankly this is a giant hack and generally is quite amateurish. I would like as much as anyone to have a better upload process (and as a result, better uploads), but I do not believe for a moment that this should be the default upload form currently. It is very poorly integrated with MediaWiki because of it's hackish nature and we can and we must do better. --MZMcBride (talk) 21:56, 28 March 2012 (UTC)

Integrating this functionality with MediaWiki or turning it into an extension is unfortunately beyond my programming powers. If anybody wants to explore such possibilities, I'd of course welcome it. As for the existing UploadWizard extension (as used on Commons), there are several reasons why in its current form it would not be suitable for us, and I expect adapting it to our local needs would be no less work than improving this one (or in fact writing something entirely different from scratch).

Of course, I agree it's a hack and I agree there's lots of room for improvement. But for the moment, the only choice we have is between this thing and the old forms-with-preloaded templates hack. Which was even more ugly, even more hackish, and proven to be completely dysfunctional for newcomers. Fut.Perf. ☼ 08:47, 29 March 2012 (UTC)

Hmm, yes. "Perfect is the enemy of the done" and all that. I don't want to impede progress, but I also don't want to continue down the road of hacks. It's a tricky situation. I actually made a request at Wikipedia talk:Upload#Please revert test to revert the test now that it's gone on for a bit over a month, but maybe this stop-gap measure is good enough for now.

Uploading media to a Wikimedia/MediaWiki wiki should be a simple, easy experience. I uploaded a video to YouTube for the first time yesterday and it was nearly painless. Fast upload time, built-in editing tools, tagging system, progress notification to the end user, etc. MediaWiki should have similar capabilities. The question becomes whether this new system is better than the old system or if it just encourages us to add further hacks and accept mediocrity. Hmm. --MZMcBride (talk) 17:26, 29 March 2012 (UTC)

Well, there are limits to how simple we can make things. Of course, technically, a lot could be improved. But the big difference to Youtube is: On Youtube, nobody really bothers about copyright, free content, NFC etc. Here, we have to. Most of the complexity is not on the technical side but on the policy side. Fut.Perf. ☼ 19:13, 31 March 2012 (UTC)

Edit request on 31 March 2012

173.77.183.225 (talk) 17:40, 31 March 2012 (UTC)

Not done: please be more specific about what needs to be changed. --Redrose64 (talk) 19:03, 31 March 2012 (UTC)

A couple of suggestions and a bug

This wizard would be more useful if it had a section where categories common to all the images in the batch being uploaded could be entered just once. Uploading several views of the same subject gets very tedious now. (You can cut and paste descriptions and titles, but categories must be done one at a time.)

I'd also like a checkbox to suppress geocoding, say when the image is one I took at home.

Here's the bug: when I upload photos taken with my iPhone 4S (iOS 5.1) the altitude information shows as a fraction (e.g. 24/1), which gets reported as an error when I try to finish the upload. --agr (talk) 20:02, 4 April 2012 (UTC)

Hello, thanks for your suggestions. From what you say about batch uploads, I believe you are actually talking about the Commons Upload Wizard, the one at commons:Special:UploadWizard, right? That is actually an entirely different program from the one we are talking about here on this page. Feedback about the Commons wizard is invited at commons:Commons:Upload Wizard feedback, so maybe you might want to re-post your ideas there. Fut.Perf. ☼ 23:26, 4 April 2012 (UTC)

"disambiguation" in category name does not imply dab page

A problem was reported at Wikipedia:Help desk#Heroes Welcome UK. A user tried to upload a fair use image for use in Heroes Welcome UK and got the message: "This is a disambiguation page! The page Heroes Welcome UK is not a real article, but a disambiguation page pointing to a number of other pages. Please check and enter the exact title of the actual target article you meant."

MediaWiki:FileUploadWizard.js looks for categories with "disambiguation" in the name. Heroes Welcome UK belongs to the hidden category Category:Articles with links needing disambiguation from January 2012. This does not imply it is a disambiguation page but it fools the script. PrimeHunter (talk) 14:02, 12 April 2012 (UTC)

Ouch. Thanks for reporting this. I wasn't aware of those categories. I've changed it to check only for Category:All disambiguation pages; hope that category does in fact hold all of them. Fut.Perf. ☼ 14:18, 12 April 2012 (UTC)

That was fast but now it accepts real disambiguation pages, for example Gold (disambiguation) which is in Category:All disambiguation pages. PrimeHunter (talk) 01:59, 13 April 2012 (UTC)

The likely reason for this is the fact that I'm stupid. [6]. Fut.Perf. ☼ 06:57, 13 April 2012 (UTC)

Crown Copyright

It seems that some people using the upload wizard tag images as being under Crown Copyright although I fail to see why this would be the case, for example here. I've seen it at many other places too. Is there something in the upload wizard which might confuse users, causing them to select a wrong licence tag? --Stefan2 (talk) 13:46, 13 April 2012 (UTC)

The wizard offers that option towards the bottom of the form, under "Special source and license conditions (optional)", as one of several possible tags describing special non-free licensing situations (e.g. "for Wikipedia only" licenses, promotional press kit material, etc.). There isn't currently any further help text that goes with it. I have no idea what would make people insert those tags randomly in cases like the one you pointed to. I can only recommend simply removing such tags if they are obviously baseless. Fut.Perf. ☼ 14:36, 13 April 2012 (UTC)

I remove the crown copyright licence as there is no evidence for it and the FUR appears to be ok. ww2censor (talk) 16:57, 13 April 2012 (UTC)

Upload failed for no token

The file which I eventually uploaded was File:Consent_of_the_Networked_book_cover.jpg. I was in Google Chrome and nothing unusual happened. It is a copyrighted book cover. When I got to the end and hit "upload" it took me to another page and said that the upload failed for lack of a token. I went back and repeated the process and it told me the same thing. It was bothersome because I had to complete the form again. I decided to try in Firefox doing the same thing and it worked properly. I have no problem now, but there is a bug somewhere here. I like this new upload system when it works. Blue Rasberry (talk) 16:41, 13 April 2012 (UTC)

Thanks for reporting this. That's strange. The script uses a Mediawiki function called mw.user.tokens.get('editToken') to retrieve the edit token, and I can't think of any reason this should work differently across browsers. Also, if it was a general bug, I'd expect to have seen more complaints from other Chrome users earlier. Maybe it was just a one-off error in your browser? I've seen occasional unexpected browser errors about "loss of session data" when editing normally, and this might be basically the same thing. Could you perhaps give it another try some other time, to see if this is reproducible? Fut.Perf. ☼ 21:05, 13 April 2012 (UTC)

I just uploaded another book cover using Chrome and this time I had no problem. I do not know how to reproduce this problem. Should it ever happen again I will report it here with details. Thanks for your attention. Blue Rasberry (talk) 15:43, 14 April 2012 (UTC)

Blank image description

How did this get uploaded with a completely blank description page? --Redrose64 (talk) 20:18, 14 April 2012 (UTC)

That's always been possible with the old Special:Upload form. Used to be a very frequent occurrence when that form was more visible to newbies. Fut.Perf. ☼ 20:32, 14 April 2012 (UTC)

Question

What kind of license is a picture that isnt copyrighted, and it's author is unknown? Maxwell the scribblenaut (talk) 01:13, 16 April 2012 (UTC)

Depends on how do you know it isn't copyrighted? Is it too old? Is it too simple? You can find some of the main scenarios in the upload form under the two last entries under "free work", and some more detailed info here. However, if by "not copyrighted" you merely meant to say "it has no visible copyright mark", then the answer will be disappointing: in the absence of some special rule to the contrary, modern works will typically be protected by copyright even in the absence of a note. Also, what about the "unknown" author: do you mean it is an established fact the author cannot be found, or merely that you don't know right now? Fut.Perf. ☼ 05:40, 16 April 2012 (UTC)

Discussion at the Italian Wikipedia

I happened to notice this discussion at the Italian Wikipedia. A user has proposed importing an upload wizard to the Italian Wikipedia. The discussion might interest readers of this talk page. --Stefan2 (talk) 21:20, 19 April 2012 (UTC)

Commons pointer

I think the pointer to Commons is too low down. People are being pointed to Commons after they have entered an image description. This is bad, since most will think "why should I? I've already typed in the info", and those that do decide to go onto Commons will discover that the information they typed is not transferred to the Commons upload form.

To alleviate this problem, I suggest either:

1. to prevent local uploads of free files with this form (with a discouraging statement like "If you still wish to upload the file locally (not recommended), please use our local upload form."), or
2. to move Step 3 before Step 2, so that users haven't entered their description before being pointed to Commons.

The backlog of free files tagged for transfer to Commons is growing, and (for the most part) needlessly so. — This, that, and the other (talk) 07:35, 20 April 2012 (UTC)

I think it would be a good idea if a bot could tag uploaders' talk pages with {{subst:un-commons|filename}} if a free file has been uploaded to Wikipedia. The bots tagging files as eligible for Commons used to use User:Fbot/Blacklist2 as a blacklist: unless the file information page used (or transcluded, I think) a template listed on that page, the bots would tag images as eligible for transfer to Commons. Maybe a bot could be set up to post {{un-commons}} for new uploads based on the same blacklist. Won't stop new users, but maybe it would at least mean that users uploading lots of free files would start using Commons. --Stefan2 (talk) 13:09, 20 April 2012 (UTC)

What could be done to alleviate the issue TT+O mentioned, relatively easily, is to move the image description field out of "step 2" and integrate it with the rest of the detailed questionnaires under "step 3". Exchanging the whole of step 2 and step 3 would have disadvantages in many ways and would necessity a very thorough change of design. As for the general issue of sending people to Commons, those editors who wish to have their input preserved can also choose to have it sent to Commons at the end of Step 3. This is done by about half of all uploaders who have that option (see commons:Category:Uploaded with en.wp upload wizard). Adding to that the unknown number of people who skip to Commons at the beginning of Step 3 or right at the start, the wizard's performance at sending people to Commons is not at all bad.

However, a look at that tracking category on Commons also reveals that sending stuff to Commons has a serious downside. There are still a very large number of copyvios and other bad items among those uploads, and Commons is considerably less efficient at filtering them out than we are here. This makes me tend towards the view that the whole "press people to send all free stuff to Commons" idea may be counterproductive, at least for very new users. We should be glad if new users upload stuff here, because it makes it far easier to keep track of them, filter out the bad apples and recognize links between bad image uploads and bad editing in other areas.

As for the other suggestion, of disallowing free local uploads through the wizard completely and sending such candidates back to the old Special:Upload form, I believe that would be the worst possible step to take – it would negate all the advantages the wizard has brought in terms of enforcing proper descriptions and of detecting bad uploads, and would throw us back into a situation where most files were uploaded with no information at all. Fut.Perf. ☼ 15:06, 20 April 2012 (UTC)

I think that we just need to check the Commons uploads better. The ones sent there from here all end up in the same category, so we just need to go through that category and tag for deletion if necessary. Maybe we could use the category as a tracking category for new files and remove files from the category if they are found to be OK. --Stefan2 (talk) 15:59, 20 April 2012 (UTC)

Sure (and agree about the removal of checked files), but it's also objectively more difficult to get much of the editing context on Commons. When I check a file here on en-wp, I have a lot of important information just a click away, or even just a mouse-hover away if I'm using navigation popups: is this an old or a new user; what other images have they uploaded earlier, what articles are they using them for, is there something problematic about the articles themselves too, are they a likely sock of some earlier similar account, and so on. All of this information is much much more difficult to find once they have moved to Commons. Fut.Perf. ☼ 16:14, 20 April 2012 (UTC)

Hmm, perhaps the issue isn't as straightforward as I initially thought. Firstly, I didn't realise that the wizard can also upload directly to Commons. And secondly, having work spread across two wikis is terribly confusing for new users. The workflow (two sets of contributions logs, etc.) is terrible, and relying on Toolserver tools to bridge the gap is ridiculous.

However, my main point (about losing the file description, info, etc. when the big bold "Please consider uploading your file on Commons" link is clicked) still stands. Maybe it would be more sensible to remove that link altogether, since this very well-made wizard can upload to Commons as well. — This, that, and the other (talk) 04:40, 21 April 2012 (UTC)

Upload to Commons is only possible if the user is logged in on Commons. If you are proposing removing Wikipedia upload of free images, this could cause problems for people with SUL conflicts on Commons and/or Wikipedia and for people who haven't activated SUL. --Stefan2 (talk) 11:42, 21 April 2012 (UTC)

At least one of the Commons upload tools has a feature which verifies that the user really is logged-in on Commons. See the old Commons:Upload form, entry titled "It is a derivative work of one or several files from Commons", very first screen that you reach from that link. Perhaps Luxo (talk · contribs) could be invited to add that feature where necessary. --Redrose64 (talk) 18:26, 21 April 2012 (UTC)

tools:~luxo/derivativeFX/deri1.php just displays Commons:Special:MyPage and leaves it up to the user to determine if the user is logged in or not. No automatic check. --Stefan2 (talk) 21:27, 21 April 2012 (UTC)

The wizard already does essentially the same thing, if perhaps a bit less visibly, where it says "Check here to see if you are logged in". The only difference is that the Luxo script displays the result in a frame inside the same page, whereas this one loads it into a new page. I tried to do it in a more elegant way, through a direct call to the Commons API, but that turned out to be impossible to achieve in JavaScript due to the browser security rules of the Same origin policy. Fut.Perf. ☼ 23:13, 21 April 2012 (UTC)

No file information page

File:50 caliber bullet headstamp 1943.jpg was uploaded in March without any file information page. I've now created one by listing {{shadowsCommons}} and {{di-no license}}, but what exactly happened here? --Stefan2 (talk) 18:12, 21 April 2012 (UTC)

Wow, that must be a really really weird technical glitch. Never seen anything like it. The file clearly exists locally, and it is clearly distinct from the one on Commons, but it lacks not only a local description page but also a local upload log entry. I'm only glad it can't be a glitch in the wizard script, but must be a server-side error. (Uploading, for the script, is a single, atomic API call, and the server is supposed to create all these things together automatically just as it does during a manual upload.) I think I'll IAR on this and delete the local file, because shadowing the near-identical Commons file it's more trouble than it's worth. Fut.Perf. ☼ 22:58, 21 April 2012 (UTC)

Broke, Nothing Happens After Upload Click

I've tried probably about 7 or 8 times now, but all with the same result. After filling out all the information, I try clicking the Upload Locally or the Upload to Commons, but there is no response. I have tried in both Firefox and in Chrome. I've cleared the cache, full reload, different computers, I've entered the information enough times I have the information memorized, but whenever I click the upload button, the page sits there with no response, no net activity. :( Trying to upload expired copyright, public domain image (published 1890 in NY, USA; author died 1910). I'm not sure what is wrong, I've uploaded image files before without any kind of issue. — al-Shimoni (talk) 23:23, 21 April 2012 (UTC)

Tried investigating further. Javascript error console gives me a "Error: parts is undefined; Source File: http://en.wikipedia.org/w/index.php?title=MediaWiki:FileUploadWizard.js&action=raw&ctype=text/javascript Line: 2153" Looking at the source, the problem line of code is within the fuwAppendLines function where parts is one of its parameters, yet when it gets to line 2153 (a for loop that loops up to less than length of parts) it fails. Whatever is calling the function must be passing a bad (undefined) parameter. That's about the extent of bug tracking I'll do here... I'll let it go to someone who deals with WP javascript, but I hope that this gives a lead. Any suggestions on how I can upload another way is welcome. — al-Shimoni (talk) 23:34, 21 April 2012 (UTC)

Thanks for the detailed report. I think I figured out what was causing this. This [7] should fix it. Sorry for the trouble. Fut.Perf. ☼ 11:07, 22 April 2012 (UTC)

Add text to description

I would suggest adding some text to this wizard's description such as: "Where possible please upload media to Wikimedia Commons. Images should be uploaded here only if they are not suitable for Commons, but are acceptable for the English wikipedia, such as fair use images."--agr (talk) 18:42, 23 April 2012 (UTC)

Federal PD licensing options

Any reason why there's only about eight options, instead of the thirty or so actual options? Mangoe (talk) 18:56, 25 April 2012 (UTC)

Probably just because I copied the entries from the old form at [8], which had only those. We can easily add more, although I am a bit wary about it becoming somewhat confusing and difficult to navigate if we put in too many. Category:USGov copyright templates actually has as many as 94 entries, which really is more than a selection box should contain, I'd say. Would you have a list of some that you were missing particularly? Fut.Perf. ☼ 19:12, 25 April 2012 (UTC)

I use the coast guard and some of the Interior ones quite a bit (especially the HABS collection). Mangoe (talk) 17:19, 1 May 2012 (UTC)

Edit request on 1 May 2012

Trying to upload the official NEIGRIHMS logo. Please approve request

Pl.sahkhar (talk) 17:27, 1 May 2012 (UTC)

Hello, thank you for your interest. What you are requesting is not actually technically an "edit" to this page. Could you please take it to WP:Files for upload and follow the instructions there? Thank you, – Fut.Perf. ☼ 17:32, 1 May 2012 (UTC)

Commons upload bug

It appears when this wizard tries to upload to Commons it successfully sends the correct licensing and information tags, but doesn't send the location of the image! This means users have to virtually complete the form all over again on Commons, which would be really frustrating for noobs. Any way we can fix this? Thanks, Nathan2055^talk 22:03, 1 May 2012 (UTC)

Unfortunately not. This is not a bug, but a browser security feature. The file selection control is the one thing in an HTML form that browsers won't allow Javascript to manipulate automatically. (Apparently, this is to prevent hidden scripts in a malicious webpage from sending arbitrary files from the user's computer to a malicious server without the user knowing). A script can neither read out the currently selected filename of the local file selection box here, nor pre-load the corresponding box on the Commons form.

Of course, the user only needs to re-do this one input field on arriving on Commons, so I'm not quite sure what you mean by "complete the form all over again". Fut.Perf. ☼ 22:20, 1 May 2012 (UTC)

That should be noted within the wizard, though. --Nathan2055^talk 23:09, 1 May 2012 (UTC)