Wikipedia talk:File upload wizard/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

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)

Hello, File Upload Wizard. You have new messages at Commons:Commons:Administrators' noticeboard.
You can remove this notice at any time.

Stefan2 (talk) 09:32, 11 July 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. [1]. 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.wiki.x.io/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 [2] 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 [3], 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)

Problem with the "source" field

I'm getting nagged by various people because, in getting US Gov images off of their websites, I do exactly what the text says at that point: I put the url of the image in, because that's the "exact source". What I'm told, by implication, is that this step actually requires two urls: one for the image itself, and one for a referencing page. I'm told that the former is insufficient, and the latter is also insufficient because the websites I'm working with now have lots of images on the same page. The form needs to handle this more gracefully, or at least needs accurate instructions (but I would prefer grace). Mangoe (talk) 21:55, 7 May 2012 (UTC)

The problem is that US government websites sometimes host images not made by the US government. This is particularly common on some websites (such as NASA's website), not sure how often it happens on the coast guard's website. If you just provide a link directly to the image, there is no way to verify that the photo indeed was taken by the US government; it could be one of those photos which was taken by someone else. There was recently a discussion over at Commons on the matter because someone missed this and uploaded an image from Getty Images which happened to be hosted on a US government website at some point. --"People" (talk) 22:40, 7 May 2012 (UTC)

The explanation doesn't fix the problem, though. Mangoe (talk) 23:01, 7 May 2012 (UTC)

I'm not quite sure what you find ambiguous or inaccurate about the instructions. It says: "State exactly where you found this file. [...] please provide a link to the html web page where the file can be found ("http://... .html"), not a direct link to the image file itself ("http://... .jpg"). So, in the case of File:Cattle Point Light.jpg (assuming that's one of the cases you are thinking of), the right page to link to would be [4]. It's not really a problem that there are multiple image links on that page (once you are there, it's very easy to identify the right one), and it's also not really a problem that the image isn't shown in that page but only linked to. What matters is that it is this page that gives us the description and copyright info. Of course, in some very special cases where the structure of the source page is particularly confusing, it might be useful to have both links. But I'm not sure such cases are frequent enough to make it worth adding extra instruction text to the form. We should keep in mind that it's all a balance between completeness and simplicity of instructions, and having too many may easily lead to information overload. Fut.Perf. ☼ 23:14, 7 May 2012 (UTC)

trying to move logo

would like if you can move logo or a hint on how to go about.--Kevo1cat (talk) 20:40, 18 May 2012 (UTC)

The number of deleted images could be reduced with an extra function for license checking

There is room to enter the license, however for files on commons this is useless busywork, would it be an improvement if the Wozzard checked the license and entered the details itself, rather than have users go and find the information from commons and enter it themselves ? I'm not demanding it be done, I just want to know do people think this would be a helpful function.

For collage images, there are complex license compatibility rules, which are harder to work out than making the image itself, I just do not bother checking very much as it's too hard to understand and too poorly documented. When the files are all from commons, having the option of multiple fields to enter sources, and then having the wozzard check the licenses of those files and enter the information, warning of problems, would mean the image can be fixed at the time rather than discarded later. This would help many artists I believe. Penyulap ☏ 11:57, 19 May 2012 (UTC)

This boils down to factoring out "image based on an existing image already on Wikipedia or Commons" into an option of its own, separate from the "image from a free published source". This would probably be a good idea and I've been thinking about it myself. Images derived from existing Wikimedia images are a special case in several ways: (a) you want to link to them not through a url but preferably through a filename wikilink; (b) it should normally be possible for the w[io]zz?ard to figure out the licensing and authorship automatically, as you say (which is not normally true for off-wiki free sources), and (c) such cases often involve more than one source, especially when doing collages. All of these factors would make a separate form desirable. Some of this could be implemented easily, although the option of having several sources and having the program look them all up and import the authorship data would require some non-trivial work.

I also agree with your proposal to call it Wozzard rather than Wizard. It certainly sounds nicer. Fut.Perf. ☼ 12:15, 19 May 2012 (UTC)

Automatic Upload to Commons

Any chance we could get an update that includes as smooth an upload to Commons as it does locally? It's a little annoying to have to go through another upload page, even if it is automatically filled in... --Nathan2055^talk 23:54, 22 May 2012 (UTC)

Unfortunately not. The same origin policy, a browser security rule, prevents writing Javascript that manipulates a Commons upload directly from an en-wp page. Fut.Perf. ☼ 06:12, 23 May 2012 (UTC)

Would bugzilla:32341 simplify the process? --Stefan2 (talk) 11:57, 23 May 2012 (UTC)

Upload Wizard not uploading

I tried to upload two small jpgs (82 KB and 320 KB) and after clicking upload the wheels just keep going round and round and the page still says "Uploading..." . I deleted the second larger image in hopes this would speed things up, but the image has been uploading for about two hours. I'm using a Safari browser. What could be keeping my image from uploading? Thanks! --Alibasye (talk) 19:17, 29 May 2012 (UTC)

UPLOAD WIZARD NOT WORKING

CAN SOMEONE PLEASE HELP ME - ITS STARTING TO FRUSTRATE THE HELL OUT OF ME!!!

I complete everything, press upload NOTHING happens!!?? Im trying to upload an organizations logo. image spec etc all good. Someone rescue me please!

☻Ÿ 22:38, 6 June 2012 (UTC) — Preceding unsigned comment added by Sipooti (talk • contribs)

Commons

Is there a way the Commons can get a box on their own (or at least something bigger than what they have now)? User:Zscout370 ^{(Return Fire)} 05:55, 12 June 2012 (UTC)

Not sure what you mean by a "box on their own"? Fut.Perf. ☼ 05:59, 12 June 2012 (UTC)

Like what was done at http://en.wiki.x.io/wiki/Wikipedia:Upload/old User:Zscout370 ^{(Return Fire)} 06:08, 12 June 2012 (UTC)

There are currently three points in the process where the user is pointed to Commons. Which of them would you want to make more prominent? But please keep in mind that making notices larger and boxing them is no guarantee to make people read and heed them, quite to the contrary. Experience suggests that more message boxes only leads to visual information overload and to people not reading any of the instructions at all. The old upload form was a prime example of that; it was utterly dysfunctional. Fut.Perf. ☼ 06:17, 12 June 2012 (UTC)

I would suggest to make a bigger mention is the Commons Upload Wizard. User:Zscout370 ^{(Return Fire)} 06:33, 12 June 2012 (UTC)

Sorry, that doesn't answer my question. At which of the three points in the process? Fut.Perf. ☼ 06:42, 12 June 2012 (UTC)

When someone clicks onto the form to star the upload (so the main landing page) there should be a link under "Click here to Start the Upload Form" and put the link top the Commons Wizard. User:Zscout370 ^{(Return Fire)} 06:47, 12 June 2012 (UTC)

Making it yet another, fourth point in the process? I think that would be counterproductive, because at that point the user hasn't yet been walked through the crucial distinction between free and non-free items. They do get the big prominent Commons link once they have figured out that they are dealing with a free file. In any case, as explained above under #Commons pointer, I'm actually somewhat skeptical about the wisdom of pushing new users towards Commons too hard. With new users, we should in fact prefer it if they make their first upload attempts here. Fut.Perf. ☼ 06:52, 12 June 2012 (UTC)

Ok. I been asked before by other Commons admins why we have a lot of free images on our site (almost 400K if I read the numbers right) and trying to provide suggestions to reduce that number. User:Zscout370 ^{(Return Fire)} 16:26, 12 June 2012 (UTC)

Fair enough. You'll see part of the problem if you look at commons:Category:Uploaded with en.wp upload wizard – That's the tracking category for the items we do manage to channel over to Commons from here. See the overall low quality and high proportion of copyvios. That's the kind of quality of "free" images we get here on en-wp. Would Commons really want yet more of that stuff to be sent their way? I'm not getting the impression that Commons is particularly good at patrolling them, and it's quite hard to patrol them on Commons from here, considerably harder than patrolling the locally uploaded ones. Fut.Perf. ☼ 17:34, 12 June 2012 (UTC)

I see your point. There are a lot of times I am still catching uploads from 2008/09 that are problematic and there are just a lot that I do not see (since I still have my own little areas of the Commons to deal with). User:Zscout370 ^{(Return Fire)} 18:23, 12 June 2012 (UTC)

Template:Other

The wizard sometimes inserts {{other}} in the Licensing section without any parameters. Do you know why this happens? See Special:PermanentLink/497379019 for an example of this. --Stefan2 (talk) 12:53, 13 June 2012 (UTC)

Dang, that's a bug. It happens when a user selects "other license" from the license dropdown in the "given to me by its owner" or "free website" forms, but then leaves the following input field (for manual entry of a license code) blank. Will try and fix shortly. Thanks for reporting. Fut.Perf. ☼ 13:31, 13 June 2012 (UTC)

Clarify copyright status of graphs made fresh but from data published by others

It is not clear from the help associated with the upload wizard, what is the copyright status of graphs made by the uploader from data that has been transcribed into a spreadsheet by the uploader from tabulated data created and previously published by others. Is the graph then 'entirely my own work' or 'fair use of copyrighted material'. Could this clarification be added please.Stringybark (talk) 00:15, 17 June 2012 (UTC)

Further, can Wikipedia clarify the copyright situation as above, but with regard to these more detailed queries:

• How is fair use or creative property affected by incorporating an acknowledgement of the source of the original data (e.g. by adding a full citation into the title or image of the graph)
• What is the copyright effect (as far as Wikipedia is concerned) of simply redrawing a graph in a more or less similar appearance to a graph that has already been published?
• What is the copyright effect (as far as Wikipedia is concerned) of generating a new graph that portrays the data of existing graphs in a new and different way? For example, combining data points from a series of x,y coordinate "2D" graphs all published by a single original author into a single x,y,z coordinate "3D" graph, or converting data shown on a straight-line axis plot into a "rose diagram" plot using polar coordinates?
• By extension, what is the copyright effect (as far as Wikipedia is concerned) of drawing a new map that incorporates contour lines from a copyrighted topographic map?
• What is the copyright effect (as far as Wikipedia is concerned) of redrawing an existing textbook diagram? At what point of modification of the original is such redrawing considered a new work rather than being a copy?
  

Stringybark (talk) 00:40, 17 June 2012 (UTC)

DOES THIS WORK?????

Im Pressing upload upload and NOTHING!!!?? - Does this work?? I need to load some pictures on my article?? Getting fustrated. ☻Ÿ 23:33, 17 June 2012 (UTC) — Preceding unsigned comment added by Sipooti (talk • contribs)

Same here. I'm trying to use this to upload the main title shot/logo of a TV show, and I've filled out all the required fiels, and the Upload button is not enabled. What's going on here? Nightscream (talk) 18:55, 22 June 2012 (UTC)

I honestly have no idea. There have been a couple of reports of this kind, always mentioning logos, but I simply cannot replicate it. I just tried it again and had no problem uploading File:Just_an_example.jpg. Are you sure you also checked the obligatory checkbox saying "This image will be shown as a primary means of visual identification..."? What browser were you using? Which of the three licensing tags under "Which of these options describes this item best" did you choose? Fut.Perf. ☼ 19:32, 22 June 2012 (UTC)

Im on windows, I uploaded onto commons no problem, but this is proving to be a great challenge LOL I tick logo and its a one off non free image. I also tick as primary image and explain ctriteria etc, but no prevail... Are we on a block of some sort that no-one is telling us?? ☻Ÿ 22:33, 24 June 2012 (UTC) — Preceding unsigned comment added by Sipooti (talk • contribs)

I messed around with it, and a few times even though I filled out all of the appropriate fields, it didn't register them as filled out until I clicked on another field to move the text cursor out of the field, and then it would enable the submit button. I don't know if that's the issue here, but I thought I'd point that out. - SudoGhost 23:17, 24 June 2012 (UTC)

Multiple uploads

Possible or not? I can't see an option for multiple free files to be uploaded at once. Thanks Jenova20 23:18, 23 June 2012 (UTC)

Not possible here. If you have multiple free files to upload, the strong recommendation is to upload them on Commons. The Commons wizard has good support for serial uploads. Fut.Perf. ☼ 05:59, 24 June 2012 (UTC)

Wording for free

Presently the wording for one of the free use options is: "This file is from a free published source.: I took it from a website or other published source, where its author has explicitly placed it under a free license, allowing free re-use by anybody." While technically right, based on a conversation at WT:MCQ, the concept of re-use should be spelled out to explain it is both re-use in publication, and re-use within derivative works, with or without attribution. That way we know its two requires that should be met; many sites allow the first but not the second, but just saying "re-use" leaves it vague. --MASEM (t) 23:15, 27 June 2012 (UTC)

Feel free to reword if you can think of a wording that gets the crucial points across efficiently. I'd just recommend keeping in mind the danger of information overload. To my mind, the crucial thing is that all these instructions need to be kept as brief as possible; anything longer than what a reader can easily take in at a single glance will likely not be read at all. The amount of information that would be worth trying to get across in the various parts of the questionnaire is already massive, which means we need to prioritize. Fut.Perf. ☼ 23:29, 27 June 2012 (UTC)

All I think it needs is two words "allowing free re-use and X by anybody". What X is, I'm not 100% sure of the best word, from something like "modification", "alteration", or something else. The explanation for this can be included in a link, but I agree not to dilute the short tight language already there. --MASEM (t) 23:55, 27 June 2012 (UTC)

Good!

Complicated, probably intimidating for a new editor, but as an experienced editor I must say I found it extremely useful. Good stuff! WLU (t) (c) Wikipedia's rules:^simple/_complex 00:34, 28 June 2012 (UTC)

Option to request reviews of uploaded image

I just rea a comment at Wikipedia:Help Project/June 2012 survey (Comment was: "I wish Wikipedia had a review section for pictures BEFORE they are uploaded, just like we have for new articles") and I think think this is a good idea, as an opt in "Please someone review my uploaded image" option. The image would have to be first uploaded for it to be reviewed. I would watchwish a page where requests for reviews are made. --SmokeyJoe (talk) 19:42, 29 June 2012 (UTC)

We have already such a service, it is called Files for Upload and Wikipedia:Media copyright questions. For the first, the user is requesting an upload (esp if it is an ip editor or not confirmed if it has to be uploaded at enwp directly), the latter is for direct copyright questions. mabdul 20:08, 29 June 2012 (UTC)

Upload from iPhone

Is there a reason I cannot upload from an iPhone? --SmokeyJoe (talk) 20:06, 29 June 2012 (UTC)

Remarkable! Easy, fast, simple!

I just wanted to say what a treat it was to use this image uploader! It's not the first time I've tried to upload a simple image - in this case a logo - to wikipedia. And typically, it takes days to figure out all the various things. This uploader was designed extremely well for someone (like me) who's not in IT, and who's not here 24/7. Whomever came up with it should get a raise! :D --Charlie Inks (talk) 09:43, 6 July 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)

Heh, I'm having this problem as well right now. I'm also uploading a copyrighted logo that i have full permission to use. KingstonFC (talk) 18:36, 4 May 2012 (UTC)

Im having it swell, with a logo that Im allowed to use.. strange. User:Wordshop1

help, i cant upload images either, the upload button is greyed out... refreshed the page several times... using the latest firefox browser User:sfk-coolermaster —Preceding undated comment added 07:35, 20 July 2012 (UTC)

Edit request on 9 July 2012

Hi, i want to update the information so kindly provide me with the edit request.

Regards krishna Pune

Krishnavyukta (talk) 09:16, 9 July 2012 (UTC)

✗ Not done Please provide the information what should be changed to what. mabdul 09:33, 9 July 2012 (UTC)

The UI experience: No labels for inputs

UI and technical feedback

• On a well-designed UI you can click on the text associated with a control and it gets selected. This is achieved with the use of <label for="id-of-control">.
• The upload to Commons could be eased using an iframe and an Ajax-proxy-script on Commons
  • The <iframe> has a message-event that allows cross-site-scripting. A working example was developed by de:User:Schnark in de:Benutzer:Schnark/js/screenshot.js (The counter part that has to be loaded at Commons (in the iframe) is at de:Benutzer:Schnark/js/ajaxProxy.js). There should be an easier way in-between for files so they don't need to be JSON encoded (posted as File object), at least in some browsers.
• You can add a category-picker using JSONP or the iframe+Ajax-proxy-script approach.
  • http://commons.wikimedia.org/w/api.php?action=query&list=allpages&apfrom=B&apnamespace=14&format=json&callback=callbackfunction

Content

Oh, why I am actually here? It's because I had a glad look at commons:Category:Uploaded with en.wp upload wizard and found that half the files are either copyvios or out of project scope and attempted to find the reason.

I haven't got the evidence right now, but I will provide some if requested to do so. is useless if it just places {{subst:OP}} on the pages like the option The license hasn't yet been forwarded, but I will do so shortly or ask the owner to send it himself.

If one of the OTRS-options was chosen, and no ticket id was inserted, I think no license should be added. Often it turns out that the uploader did not contact the copyright holder, the copyright holder did not agree publishing under a free license or that they want a more restrictive one. It's unfortunate for re-users if they pick-up the wrong license.

All in all it's a useful tool and a logical user interface. Thanks for your work. -- Rillke (talk) 12:36, 21 July 2012 (UTC)

Further talk

Hi, thanks for the feedback! I'll have a look if I can figure out how to do that labels thing. As for the Ajax functionality for Commons, I tried to do that in the beginning. Tried really hard, but came to the conclusion it wasn't possible, at least not on the basis of my level of technical understanding. The problem is the Same origin policy, and I really cannot see a way to circumvent that. (The script you showed as an example seems to require that the user first go to Commons and install something in their personal js files there – that's probably beyond what we can expect most of our uploaders here to do).

About the OTRS data, we discussed this a short while ago on Commons and agreed to disable the "evidence will be provided on request" option, because indeed the amount of misuse was too great. As for the overall poor quality of the uploads: yeah, I know. Sigh. Image work here on en-wp has always been absolutely horrible. The copyvio statistics were even worse before we introduced this thing, so what you're seeing is already an improvement over what was going on earlier. On the one hand, I'd actually prefer it if we encouraged newbies to make their first upload attempts here, so we keep this stuff away from Commons and deal with the rubbish locally, but then there's been quite a bit of pressure from those who prefer that local uploads of "free" material should be minimized and that all uploaders should be very strongly pressed – if not forced outright – to do their uploads to Commons. Fut.Perf. ☼ 14:14, 21 July 2012 (UTC)

The same-origin-policy does not restrict JSONP. They are included like JavaScripts and they work cross-domain. So fetching categories would work without any special tricks. You just get no token with JSONP and you can't POST the request. As for the Ajax-Proxy: It could be simply installed at our commons:MediaWiki:Common.js like this: (if ('Commons:AjaxProxPage' === mw.config.get('wgPageName')) { importScript('MediaWiki:UploadProxy.js') })

Yes, please disable evidence will be provided on request. Thank you. -- Rillke (talk) 16:34, 22 July 2012 (UTC)