This is an archive of past discussions on Wikipedia:File upload wizard. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I am concerned that certain combination of non-free uploads e.g. tv screenshots end up displaying n.a. as the response to WP:NFCC#1 and WP:NFCC#2 in the resulting fair use rationale e.g. File:Jeremy in English as a Second Language.jpg The use of not applicable does not appear to be in keeping with the requirements of the WP:NFCC to give a full explanation as to why an image meets the criteria. While some boilerplate to meet these two criteria probably is ok, it shouldn't be n.a. Any suggestions for improvement in wording or should it not be boilerplate and the uploader needs to establish reasons for themselves. Nthep (talk) 11:26, 29 May 2017 (UTC)
N/A don't make a whole lot of sense when we have standardized fair use rationale templates for a wide variety of categories that fill in the information for you. The use of {{non-free use rationale 2}} needs to be deprecated in my opinion and replaced with the more specific templates. Failure to actually fill in all the required information does not meet fair use policy and the use of N/A was a poor choice when we have templates that literally do the work for you. --Majora (talk) 19:19, 29 May 2017 (UTC)
We do still need that template for things that do not fall into some of the standard NFC uses. It's more the case that if something does fall into a standard use listed on this scripts' dropdowns (such as a logo), this page should use the specialized templates which 1) include a catch-all explanation that does show some metrics for meeting NFCC (eg {{Non-free logo}}) and 2) trims down the rationale template to remove elements covered by this catch-all box. However, we should make sure what standard rational templates exist, what catch-all NFC templates they associated with, and that the combination of them, when properly filled in, would have all 10 points of NFC met. This thus should eliminate any "n.a." in any rationale produced by this script. --MASEM (t) 15:28, 30 May 2017 (UTC)
Oh and FPaS, the legal field is full of boilerplate language because of the necessity of it. Standardized material covers everyone because the standardization of such things ensures that the necessary steps are followed and are valid. Copyright is a legal area through and through. Your fight against such language might have made sense if we were forcing people to copy and paste such information themselves. We aren't. The templates do it for you if you use the right template. Failure to have a complete and valid FUR is against policy and we should be doing everything in our power to avoid that. --Majora (talk) 19:24, 29 May 2017 (UTC)
Fair-use rationales have nothing to do with the law. Nothing in what we ask uploaders to say in their FURs is legally necessary. The last thing a court of law would do, if ever a situation were to arise where our use of non-free material were to be challenged legally, is to read what FUR templates an uploader placed on a file description page – the suggestion that such templates would be necessary or even helpful to "cover" us is ridiculous. What FURs are meant for is to nudge uploaders to consider the right questions and (hopefully truthfully) tell us the crucial pieces of information while uploading. For that purpose, boilerplate language is absolutely the worst possible thing to have around. And all the existing "standard" FUR templates are completely useless when it comes to FURs that have to be composite of standard components and individual, user-supplied information. That's what this wizard has been trying to guide users through (with moderate success), and what all previous systems of standardized templates were absolutely hopeless with. No, it is simply not true that those standard templates could "do it for you". They just don't. Fut.Perf.☼20:03, 29 May 2017 (UTC)
The fact that you favor the continual violation of our policy here is truly shocking. If you want to do that get the policy changed. Otherwise, every use of the wizard you wrote is a violation. WP:NFCC is a legal policy. It says it right there. There really isn't any way around that. If you don't like it get the policy changed. Otherwise, Nthep should fix the .js script to avoid the continual violations that have gone on, unchecked, for years. --Majora (talk) 20:32, 29 May 2017 (UTC)
There is no policy violation. Nothing in the policy demands that a fair-use rationale needs to explicitly talk about each and every NFC criterion to demonstrate that they are all met, in cases where that compliance is self-evident. (If that were the case, it would lead to the absurdity that every rationale would have to self-referentially assert and confirm its own existence, among other things.) If there were such a policy written somewhere, it would be so idiotic and so obviously out of touch with actual practice that it would be prima facie invalid (and yes, in that case it should be changed, as soon as possible). Fut.Perf.☼20:38, 29 May 2017 (UTC)
It is only standard practice because you made it so. Unilaterally. Your decision is even written as a comment in the script. I hate FURs filled with trivial/predictable/redundant verbiage, so we'll just cut it short. And don't anybody dare complain that that's not a valid FUR. You had no right to unilaterally make that decision and for you to do so and then claim that that is now "standard practice" is ridiculous. That is dictatorial.
WP:NFCCE states, Note that it is the duty of users seeking to include or retain content to provide a valid rationale; those seeking to remove or delete it are not required to show that one cannot be created—see burden of proof. A valid rationale states why the image meets all 10 required criteria. Your unilateral action has made it so tens of thousands of fair use images do not have a complete, valid, FUR. We all know that most people have zero actual grasp on the necessities of images here (or anywhere). To default to an incomplete FUR because you don't like boilerplate language with the knowledge that most people will just ignore it because they don't know any better is facilitating a policy violation. --Majora (talk) 21:48, 29 May 2017 (UTC)
You can repeat the myth that a rationale is valid only if it explicitly mentions all ten criteria until you're blue in the face; it won't make it truer. Not even your "standard templates" do anything of the sort. Have fun trying to delete all images whose rationale doesn't explicitly address NFCC#9 and #10. This wizard has consensus, because it was presented to the community, tested under its eyes, and has been running like this for five years. Now go away and do something useful. Fut.Perf.☼04:43, 30 May 2017 (UTC)
Fut. Perf, given that several people are now disagreeing with you on the matter, the status of its having consensus is clearly in question. Even if it once did, consensus can change, and when multiple people are in good faith questioning the practice, I think it's reasonable to ask whether it does (still, if applicable) have consensus. I didn't even know the Upload Wizard did that. I know some other people don't either, because I've seen them get after people for using the "n.a.". In fact, that just came up at a Teahouse question, and led to a new editor being chastised for that, and getting thoroughly confused having no idea what they did wrong. Generally speaking, I want a rationale to show that an editor actually carefully considered the NFCC before uploading a nonfree image, and came to the conclusion that the use does indeed meet each and every one of them. I might support boilerplate in some of the "identification" cases where use is widely considered acceptable, but it should still at least be there to show how the image passes it. SeraphimbladeTalk to me15:18, 30 May 2017 (UTC)
There are two very important considerations, which I have the feeling you are overlooking. The first is: the edit made by the script on behalf of the user must remain the user's responsibility. The rationale has to be the user's rationale, not the bot's. When the user looks back on the finished page, they should recognize the rationale as their own ("yes, this is what I said in the questionnaire; I wrote this rationale, I'm responsible for it"). We mustn't create a situation where they could say: "Oh, there's some funny fine print that turned up suddenly; I wonder where that came from, but I'm sure it has nothing to do with me." It would therefore be unacceptable for the script to simply sneak boilerplate verbiage into the rationale without the user at least seeing and endorsing it before (e.g. through clicking some checkbox).
But now comes the second consideration: every single additional bit of "fine print" you present to the reader during the upload will decrease user acceptance of the whole process, and will dramatically increase the number of uploaders who either just give up or opt to ignore the whole questionnaire and just click boxes at random. Newbie uploaders simply won't read fine print. The questionnaire is already taxing the average newbie's attention span with the few questions it asks now. The quality of our uploads won't become better if you dump more text and more criteria on the users. It is absolutely crucial that the weight of the fair-use questionnaire be kept down to the absolute minimum.
So, if you really want "a rationale to show that an editor actually carefully considered the NFCC" (which is what I also want), then your only chance of achieving that is to allow the user to focus their attention on the few criteria that really matter. Fortunately, we don't have to force our uploaders to waste their attention on "considering" commercial damage in the case of logos, or replaceability in the case of artworks that are objects of discussion, because we know in advance that there's nothing to consider there. Forcing them to look at boilerplate text for these trivialities will neither increase their understanding of the NFCC nor improve the quality of the uploads. It will only detract from the attention they are willing to give to those other bits where we really need it. Fut.Perf.☼21:09, 30 May 2017 (UTC)
I think what is better is to ask the script maintainer (read: Future Perfect at this time), to make sure we're not leaving empty / "n.a." fields, even if that means filling in "obvious" boilerplate text. I do fully agree that a random new users is not going to bother as they simply won't know and thus we'll get problems in any fashion (eg we can't make them think about "is this use appropriate"). But we can minimize cleanup and satisfying NFC if we didn't leave those "n.a." in place and instead had language that would be at least appropriate for the image type. For example, uploading a TV screenshot should assert with boilerplate that copyrighted shows aren't going to necessarily have a free equivalent available, and a screenshot is not going to be commercially infringing. If possible, the template here should offer the user a means to fill these in but this should be optional, and if not used, defaulting to these statements. --MASEM (t) 21:27, 30 May 2017 (UTC)
Yes, I could see that. It could even be as simple as an editable field, that's prefilled in the cases where it's almost always a certain way, and the user approves it (or makes changes if need be). If even that's too taxing to someone's attention span, we've identified someone who really shouldn't be uploading nonfrees at all. SeraphimbladeTalk to me00:07, 31 May 2017 (UTC)
I like the idea of default text in text fields in the edit form that the user doesn't have to touch for the most common cases (screenshots, covers, etc.) but that we should wrap with language that the more the user can describe in this field, the more likely the image will never suffer a trip to FFD. FutPerf point is right on that the average editor isn't going to play with this stuff and we can't force them either without losing contributions (I remember ppl have been put off and turned away from WP because of the seemingly draconian NFC policy), so let's make it as easy as possible to bring to full compliance while providing the hooks for experienced users to make their rationales better as needed. --MASEM (t) 00:14, 31 May 2017 (UTC)
I'm still to be convinced there is any need for change at all. Nothing in what any of you three have said convinces me there is any such rule that these fields need to be filled for "full compliance". There is no more need to explicitly cover NFCC#2 (in cases where compliance with it is trivially obvious) than there is a need to explicitly cover NFCC#10 (which is always trivially obvious, and not even you seem to want to be addressed explicitly). And, Seraphimblade: "If even that's too taxing to someone's attention span, we've identified someone who really shouldn't be uploading nonfrees at all" – you are talking about 99 percent of our uploaders here, not merely newbies but established users too. Do you really think our uploaders want to ponder the fact that if you were to replace a logo with something else, "any substitute that is not a derivative work would fail to convey the meaning intended, would tarnish or misrepresent its image, or would fail its purpose of identification or commentary"? Do you really think wasting half a minute reading and comprehending that sentence and its implications would help anybody at all during upload? That beggars belief. Fut.Perf.☼04:57, 31 May 2017 (UTC)
Per WP:NFC a rational is expected to provide the minimum elements listed at WP:FUR. This includes "Why the subject can't be adequately conveyed by properly sourced text or using free content media" (one of the fields that is currently filled with "n.a."), and respect for commercial opportunity is an element for meeting fair use defense. So leaving these as "n.a." fails what FUR requires. And yes, we want editors to slow down and think about non-free, rather than think "I'll just upload an image". Case in point is of the character image in question; that really does not have any purpose on WP since a free image of the actor could be used (and as the current page it was meant to be used on, all the images are free images of the cast). Editors are not putting enough thought into this, so we need to help them out better. --MASEM (t) 06:06, 31 May 2017 (UTC)
But you're not going to "help" them to "put more thought into this" by making them look at some boilerplate like the stuff that is currently included in some rationale templates. That will only make them put less thought into what really matters. In the case you mention, the thought that a character illustration could be replaced by a free photo of the actor is such a specialized, difficult case and applies to only such a (relatively) rare special group of situations, there is simply nothing we can do to force them to consider that. We can't include an exhaustive list of warnings and reminders about what not to upload in all of the myriad special case groups that we NFC experts are familiar with – they would never read it anyway. Sure, we could keep the "explain why this couldn't be replaced with some other picture" option active in this case group, just in case a user might have something to say. But if the thought of this particular possibility of replacement just doesn't occur to them, then there's simply not a thing on earth we can do. Even if we forced them to write something just for the sake of filling in the field, what would that help? We'd only end up with one more bad upload with a bad attempt at a #1 rationale, instead of one more bad upload with no #1 rationale. Fut.Perf.☼07:37, 31 May 2017 (UTC)
BTW, just for clarity: we are talking about two entirely different problems now. Your problem with the character image is: how do we dissuade editors from uploading stuff if their images are bad? The initial problem of this thread was: what do we want to get editors to write if their images are good? Unlike what one might expect, the two problems have absolutely nothing to do with each other. Nothing we could possibly teach them about writing rationales will ever dissuade a user from making a bad upload, if they came here with a bad image to upload to begin with. The following train of thought is entirely unrealistic: "This instruction tells me that I should explain how my image meets condition X. But I can't truthfully assert that it meets condition X, because unfortunately it just doesn't. Therefore, I'll go away and not upload it." Ten years of patrolling image uploads have taught me that no newbie editor, ever, comes to that conclusion. Fut.Perf.☼11:34, 31 May 2017 (UTC)
The problems are connected because newer editors will often follow by example. If no changes are made to this upload script, the will see other images have "n.a." in fields, and that will lead them to believe that "n.a." is an acceptable entry for any field in the rationale, which it is not. It would be much better to have boilerplate language in those fields so that these same editors would recognize some language is required for all fields, and telling the uploader that "hey, here's some default language appropriate for this type of image upload, but you can edit onto that", it avoids the issue of them purposely leaving empty fields, and will make all future rationals generated by this template in accordance with NFC. And it also reinforces what NFC is meant to be allowed for, even if it is a standard case. If an uploader hasn't considered the issue of a free replacement, they will upon seeing that default boilerplate. At that point, it becomes the type of knowledge they will gain by repeated exposure to the upload script. --MASEM (t) 15:25, 31 May 2017 (UTC)
I still won't buy the idea that uploaders learn anything, ever, from being exposed to boilerplate text. The only reaction people have to boilerplate text is, "it's small print, I can ignore it". As for fields being left empty by uploaders (other than the ones that the questionnaire omits): they can't; the script forces something to be put in. And I very much prefer seeing bad uploaders leave empty or near-empty fields than having them filled up with good-looking (but false) boilerplate text; this way we can at least filter out the bad ones more easily and have an easier handle for deleting them. Fut.Perf.☼15:46, 31 May 2017 (UTC)
It's not the parts of the rationale they can't see of concern, it's the parts they can edit that they might decide to leave as "n.a.", since that reply "seems appropriate" for other fields, with the current rationales this produces. I'd rather see some reasonably legit boilerplate that covers the bases that the uploader likely will not think about at all, than no effective entries at all. --MASEM (t) 15:52, 31 May 2017 (UTC)
Pretty much what Masem said. Having something there leads by example, and shows that all criteria apply to all images. If you leave "n.a." in some fields in some cases, you are telling people that is an acceptable practice for them to do too, since obviously plenty of other people have done it and gotten away with it. I also, FPaS, disagree with your assertion that no one would learn anything. I think there are some people who do not learn, but those are the ones we run into and have to deal with and clean up after. Those who do learn become good, discerning users of nonfree media, carefully considering if it is appropriate or not, so we never notice them. Even if we notice something they uploaded, we just look, say "Yep, looks fine", and move on. Regardless, though, the question is whether the practice really does have consensus. I read the past discussion, and I don't see it ever really coming to a consensus, just kind of dying off. The fact that the community was OK with the upload wizard as a whole does not indicate they were fine with this part of it; I suspect most of them did not even notice and just looked at the shiny widgets. Which, by the way, are very cool and helpful, and I certainly don't want to make it seem like your work writing the tool isn't appreciated. But sometimes, tools need to be refined, not just stay static. I suppose if you really want, we could raise an RfC on this specific issue, but I don't see why it's necessary to go that far. It's long since been accepted that all nonfree criteria apply to all nonfree images. So saying "n.a.", which means "not applicable", is clearly not in line with the consensus that they do apply. Even when a particular use case means that a particular NFCC is almost always satisfied, it still does apply. SeraphimbladeTalk to me18:04, 31 May 2017 (UTC)
You are going round in circles now; this is getting annoying. Nobody has ever claimed that any of the criteria isn't applicable. What is "not applicable" isn't the criteria; it's the need for bloody stupid explanations for them if and when they are bloody stupid obvious. I'm going to make one final attempt to get you to address the logical flaw in your claims that you have now three or four times avoided: NFCC#9 and #10 always apply (like all the other criteria), but compliance with them is always bloody stupid obvious, so we never address them in our FURs. (Not even those famed "standard rationales" do, and not even you seem to be claiming that we should.) NFCC#1 and #3 are sometimes bloody stupid obvious, so why should we not also omit addressing them, if and when they are? The claim that because all criteria always apply they all need to be always explicitly addressed is simply a patent untruth. We can perhaps talk about this or that tweak to our treatment of routine #1 or #3 coverage here, but not as long as that idiotic canard keeps being thrown around here. Fut.Perf.☼05:17, 1 June 2017 (UTC)
#9 is addressed by the fact we ask the editor to include the article they want to use the image at, which of course must be in mainspace. #10 is met by the fact that a rationale is not sufficient alone, a license tag is also required. No, we're not asking for explainations on #9 or #10, but they're still required elements. However, nearly all the rest are ones that require some type of short statement of how they are met. "n.a." does not cut it for these. --MASEM (t) 05:25, 1 June 2017 (UTC)
Addressing all 10 criteria points for an NFCC is a requirement; there is no case where one or more of the factors do not apply. There are a number of cases where a blanket statement does cover many instances of the same class, but is not saying that some NFCC do not apply these classes, just that there's simplified but essential language that can be used instead. --MASEM (t) 06:06, 1 June 2017 (UTC)
Also, #9 and #10 are addressed in the rationale. For #9, that's addressed by the fact that the rationale itself must state which article it applies to. If the rationale is written for a mainspace article, it satisfies #9, and the rationale says so by the very act of saying which page the rationale is meant for as is required. So, no, we don't need boilerplate text for that, but it is required to be there. Similarly for #10, we do in fact require all that to be there on the image description page, and since the person reading the rationale is already at that page, they can already see whether there is a copyright tag and acknowledgement of source, and again, the fact that the rationale says which page it's for lets them see if "c" is satisfied by having rationales for every use. So proof of compliance with those is actually required to be on the image page, and unless the rationale or image page are deficient, already is present. However, compliance with #1, #2, etc., are not contingent on any material on the image page, since it depends where and how they are used. An image could easily be compliant with, for example, #1 for one use, but fail it for another. That's why we need explanations of how they are in compliance for the particular contemplated use. #9 and #10 already have evidence of compliance on the image page, so you're essentially saying we'd be asking people to place it twice. Well, no. But they're already required to place it once. SeraphimbladeTalk to me06:52, 1 June 2017 (UTC)
This discussion is now over. I'm tired of dealing with the IDHT disruption from you two. As the current maintainer of this script, I am most certainly NOT going to implement any changes to it at this point. If you insist on changes, you'll have to do it yourself. (But if you try to make the script sneak in boilerplate text that the user hasn't written or endorsed in the questionnaire, forget it, I'll fight you tooth and nails to prevent that.) If you want, start by presenting a mock-up here of what you think a questionnaire section for any one of the routine cases ought to look like, and then good luck narrowing it down to something people will actually read and understand. They won't. You're only going to make the quality of uploads get worse. Have fun. Fut.Perf.☼07:53, 1 June 2017 (UTC)
I really believe this is more serious an issue towards proper NFC policy than Fut.Perf. thinks it is, and to that end, I've dropped a notice on the WT:NFC page to here. --MASEM (t) 16:06, 1 June 2017 (UTC)
I agree that it is. And FPaS, with all due respect, I don't believe it's everyone except you in this discussion engaging in "I didn't hear you". SeraphimbladeTalk to me17:51, 1 June 2017 (UTC)
Having seen this discussion flagged at WT:NFC, I do think FPaS has a point here. I remember -- before the templated upload system was so evolved -- when people used to simply cut and paste a numerical list 1-10 of all-purpose sentences, one each for each of the NFCC. Thankfully most of the uses probably aren't controversial, but those are really really crap rationales. As per FPaS (I think), I'm much happier with a handmade rationale that actually focuses on the points that might be controversial, in particularly the key NFCC #8 criterion, rather than covering everything by rote just for the sake of having some text. I think FPaS is right, that "bloody stupid explanations for them if and when they are bloody stupid obvious" are not particularly helpful per se, and the pages work better if they bring out and focus on the questions that are more nuanced and need more explanation. Jheald (talk) 18:44, 1 June 2017 (UTC)
Tiny little miniature checkbox
If you omit the check box "Will be used at the top of the article.... " the image won;t upload. But there is no diagnostic, indicating what you have missed out.
When a new user presses Upload File- they land here. Most of the time they need to land at the Commons Upload Wizard. On a normal page, there would be a prominent hat-note to take them there- obviously I can't add one myself. When the new user arrives here, the first thing they see is the large link to the WP(en) Upload wizard, what I would like to see is a 80% link underneath- linking them to the commons wizard. The problem that a trainer faces, is that there is no easy way to describe where to find the little link in the big blue box at the left hand side- no eas way to put it into documentation. Please ping me when a solution has been agreed. --ClemRutter (talk) 01:35, 26 May 2017 (UTC)
The problem is, before a new user can decide whether they should use the Commons or the local upload, they first need to understand the difference between free and non-free items, and that's something the wizard tries to teach them in the process (giving them another option to go to Commons after they clarified what kind of file they have). If we wanted to add such a prominent link right at the beginning, we'd also have to confront them with yet more explanative boilerplate about rules at that point (and people never read that). Fut.Perf.☼05:07, 26 May 2017 (UTC)
I see your point (feel your pain)- but I had never really understood why beginners- and potential donors were having so much difficulty with Upload file because personally and in the classroom I was always on Commons when used or demonstrated the Upload file link. Last night, while cleaning up a help page I discovered Upload file (en).
Could you look at the Upload file (commons) link, the copyright issue is raised on page 2 of the form, and if the user doesn't select checkbox one- they are thrown back out. As an IT dinosaur, I would have queried the idea of uploading images before doing the paperwork serverside, but nothing is published until all syntax and criteria are OK. It works.
My big issue as a trainer is the need to speak simply- I want to say, follow the link and press the pink button. It doesn't need to be at the top- Upload file (en) can be modified to give me something better than what we have at the moment.
There seems to be a great inconsistency between, me expecting a tool (as in Upload file (commons)), and the aim to make this a tutorial, to enhance understanding and minimise damage.
The graphics on Upload file (commons) are so much better, and encouraging to neophytes. The source code does not allow an easy cut and paste! Certain improvements can be made just using wikitext but that will require the will to change. The UI must be donor friendly oriented and donor friendly directing them to the tool they need. I do think it will be worth the effort. ClemRutter (talk) 08:55, 26 May 2017 (UTC)
OK no answers- so lets try it another way I will change the text on this page to make the Commons upload wizard more prominent to new users. Any objections- I have already given this 6 weeks!.ClemRutter (talk) 17:11, 16 July 2017 (UTC)
This really is an important issue. I get caught every time, I use the wizard, click upload to commons and then either have to do everything again or say **** and go back and just upload locally. The choice between uploading locally to Wikipedia or to Wikimedia Commons needs to be obvious and at the start of the process. The current arrangement isn't just inconvenient and illogical, its silly! The problem is that anyone in a position to make the advanced edits needed to sort this knows the procedure like the back of her hand and doesn't see the problems. Stub Mandrel (talk) 21:11, 26 July 2017 (UTC)
Sorry, but could you specify what exactly you found you had to do all over again after being redirected to Commons? The script was designed so as to pre-fill the Commons upload form with the appropriate data copied over from this questionnaire. I tried it out again just now and this seems to be still working, by and large. You do have to re-press the file selection button and re-select the local file on your disk; this is unfortunately technically unavoidable, since the file selection process cannot be automatically scripted, for security reasons. Other than that, I get the impression the Commons upload form may have undergone a few slight changes in the meantime, since this script was written, so there might be one or two boxes that don't get pre-filled the way they could, but apart from that it still seems to be working as planned. Fut.Perf.☼21:33, 26 July 2017 (UTC)
@Future Perfect at Sunrise: I have enormous respect for guys like you that write these scripts- a wikisuperhero. I deal with the mere mortals who we are trying to persuade to contribute, and I am forever trying to make the process simpler. So looking at it from my POV. Photos come in two shapes- the easy ones, that Fred took himself, and the complicated ones that he screen grabbed from the internet or whatever. In class I say, we are only dealing with photos you took yourself- when you have uploaded a hundred so you can read up about the other ones. Indeed 85% of the photos we upload are the first sort.
To cater for the two types of photos, I suggest that we make the interface more like the Commons upload wizard but with a preview pane before publish. However at the moment, I suggest a quick and easy method would be to change the landing page to have two large pointer.
Wikipedia loves free files. However, we would love it even more if you uploaded them on our sister project, the Wikimedia Commons. Files uploaded on Commons can be used immediately here on Wikipedia as well as on all its sister projects. Uploading files on Commons works just the same as here. Your Wikipedia account will automatically work on Commons too.
Please consider uploading your file on Commons.
However, if you prefer to do it here instead, you may go ahead with this form. You can also first use this form to collect the information about your file and then send it to Commons from here.
There we have it- follow the link and all the information is lost, and we discover the third Upload Wizard. The Commons Upload Wizard. If Fred follows this route- he will complete the upload and remain in commons, and use that wizard for all his future uploads. Except of course when he arrives home and logs on again to practise the skill he has learnt. There may be another path through the script that I haven't tested, but I think that this is enough to demonstrate the difficulties caused by having 3 pages with the same title.
I have called my sample user Fred, but often the guys in the room are acting professors and heads of faculties, who supervise PhD students- they can lack computer skills but are sharp to point out inconsistencies. The request is can you modify the landing page so that there is the large extra link direct to commons, and then we can read thought the comprehensive wizard script looking to eliminate forward references and change the interface to be aligned with Commons Upload Wizard. ClemRutter (talk) 21:56, 27 July 2017 (UTC) Re formatted ClemRutter (talk) 09:29, 18 August 2017 (UTC)
I click on it but it keeps on restarting to the same page LD.leira 18:57, 2 November 2017 (UTC) — Preceding unsigned comment added by Quinn Leira (talk • contribs)
That tells us you are frustrated but we need a few basic details to sort out a solution or work-around.
Are you using, an iphone, android, or a laptop with Linux, a laptop with Windows?
Which page are you coming from? What is it that you try to press?
Wikimedia Upload wizard not working on web or mobile
I've tried several times today to upload some photos using the wikimedia upload wizard.
I get as far as the "Release Rights" page, tick the "These files are my own work" radio button, but when I click the "Next" button, nothing happens (literally nothing, no processing, no error message)
I've tried half a dozen times over a 6 hour period (approx 5pm to 11pm GMT)
The "Next" button is definitely enabled as a button, because the cursor changes to a hand when I hover over it
I've tried it on my PC (Windows 7) with Chrome and with Internet Explorer 11
This sounds like you were using the Commons upload wizard, not this local one on the English Wikipedia, which is technically entirely different. You'd have to enquire at Commons about this problem. Fut.Perf.☼13:53, 2 December 2017 (UTC)
In the section "excerpt from a copyrighted work", the first dropdown box contains an entry "software screenshot", which will insert the template {{Non-free software screenshot}}. This should be appropriate for your use case. There is also a more specific {{Non-free Microsoft screenshot}}, which contains some additional information, but there isn't really any need to use it instead. In general, the script doesn't offer the full range of possible copyright tags; a fuller list can be found under WP:Image copyright tags. Fut.Perf.☼09:46, 26 December 2017 (UTC)
Buggy, frustrating, lost all the information I entered into it
This tool seems to be very buggy. I spent time entering all of the information and submitted it, then the file upload didn't complete and all the information I entered was lost. This occurred multiple times. Finally I got the file upload to work, but without entering the complete information needed for the file submission. Please fix this! --Wykypydya (talk) 06:37, 12 January 2018 (UTC)
How to add pictures taken from an instagram account?
I have submitted an article and given an image from instagram, but they deleted the image as due to copyright issues?
So can i use an image from google instead? if so how? Thewrecklessmind (talk) 15:10, 9 February 2018 (UTC)
Copyright is like a Russian Doll- there are many layers, and all the conditions have to be fulfilled. Simple answer -NO, but there is a workaround called Fair Use. Take a look at this image, File:Manor Mill, Chadderton 0005.png; here I have scanned to image from a catalogue dated 1951, and answered a series of questions about why no other image was possible, and which page it was to be used on. Once you have learned the system you propably will find a way that works for you. ClemRutter (talk) 10:48, 13 February 2018 (UTC)
I WAS B
Not working
Can someone please fix this. It doesn’t work anymore with the IOS11 update. I need to upload some images to Wikipedia, not Wikimedia. DatBoy101 (talk) 20:55, 26 November 2017 (UTC)
I don't have access to IOS11, so I'm afraid I can't reproduce your problem. Uploading is still working normally on my machine here. Can anybody with IOS11 help? Fut.Perf.☼13:54, 2 December 2017 (UTC)
I do, can't reproduce. @DatBoy101:, can you make sure that you have JavaScript enabled, are not running an ad blocker or other software that would interfere with JavaScript, have not changed any of Safari's Experimental Features settings, and that you are logged in to Wikipedia? --AntiCompositeNumber (Ring me) 17:15, 2 December 2017 (UTC)
The problem seems to be related to the mobile version of the Wikipedia website. I had that problem but feedback I received was that it’s a bug with the mobile version of the website and to fix the problem I had to use the desktop version of the page from the “desktop” link at the bottom of the page. File upload works fine with the desktop version of the page.
Adrian816 (talk) 10:22, 28 February 2018 (UTC)
File upload doesn’t work on iPad for both safari and Firefox browsers
(see previous post for context) - Please can an administrator of the project page add a note “If you are using an iPad or safari browser select the desktop version of the file upload page to avoid compatibility issues due to the mobile version not working.” I can post comments here on the talk page but the file upload page seems to be protected.
Adrian816 (talk) 10:33, 28 February 2018 (UTC)
The wizard currently asks that the image be such that "Its use does not negatively affect the commercial interests of its owner".
If you follow the link, you get:
"Respect for commercial opportunities. Non-free content is not used in a manner that is likely to replace the original market role of the original copyrighted material."
This is sometimes significantly different. I just uploaded a copyright ad by the tobacco industry in order to discuss recent marketing practices; this is clearly fair use, and there is no way the Wikipedia article, or its use of the ad, will somehow replace the ad's function (selling a product). But critical discussion of the ad might reasonably be considered to negatively affect the commercial interests of the company that owns the copyright. This has broader implications for any "criticism and review" application; obviously it is not forbidden to write, say, that critics panned a film, and why, even if you illustrate the statement with a movie poster, and even if some people read the article and then decide not to go see the film.
I suggest rephrasing: "Its use is not likely to replace the original market role of the copyrighted material", perhaps? HLHJ (talk) 20:52, 21 May 2018 (UTC)
kyykaarme: I've deleted all the duplicate text from archive 7 and when the bot has finished with archive 6 it will start filling in 7 as there is plenty of space. ww2censor (talk) 16:36, 5 August 2018 (UTC)
So what? Why delete it when eventually it will start to be populated, so why delete it to just have it recreated in the future? Seems like a waste of effort. ww2censor (talk) 21:18, 9 August 2018 (UTC)
So that people who are looking for information in the archives won't see an empty page and wonder why there is an empty page linked in the archive menu. The bot won't mind having to recreate the page. It might take a while before archive 6 is full and eventually also this conversation will be archived and then one day someone might start a conversation here asking why there is an empty page linked in the archive menu. -kyykaarme (talk) 16:24, 10 August 2018 (UTC)
The easiest way to find anything in the archive page is by using the search box not by opening each archive page. If you are so determined to get it deleted then nominate it for deletion. I'm not wasting any more time of this. ww2censor (talk) 16:46, 10 August 2018 (UTC)
Align design to follow the Wikimedia Design Style Guide
@Manns8447: It appears that you asked this question via the mobile website. Due to some limitations on how the mobile website works, the File Upload Wizard is not compatible. Please try again using the desktop site, or leave a note at the Teahouse if you have more questions. --AntiCompositeNumber (talk) 12:57, 30 May 2018 (UTC)
Well that's lame. With all of the cellphones in the world you would THINK that Wikipedia would be able to come up with some kind of coding that would allow a person to add photos to a page. Afterall a photo is only digital coding pulled together into a classified unit with a designated file type.
A photo can be opened by the antiquated DOS program, so why can't they utilize that to translate photos?
Amazing... ToddlyLovesJesus2 (talk) 07:13, 3 September 2018 (UTC)
I think I spotted a bug in the form. In Step 3, when I do the following:
Click radio button 2 "This is a copyrighted, non-free work, but I believe it is Fair Use" radio button
Click radio button 3 "This is an excerpt from a copyrighted work."
Select an item from the select menu "Which of these options describes this item best?"
Then change my mind and click radio button 7 "This is some other kind of non-free work"....
... the textarea id="NFPurpose" has been removed from the uploadDetails panel id="detailsNFMisc". The result is that all required fields cannot be completed and the Submit button remains disabled. The only fix is to reload the page and start all over again.
Can we get our terms straight here? This is confusing.
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
TL;DR: could you please change the text "titlepage of a book" to "cover or dustjacket of a book" in the text that is presented to the reader for non-free fair use rationales. That is,
change
|style=""|<span id="placeholderOptionNFCover"></span>
|This is the '''official cover art''' of a work.<br/>This is the titlepage of a book, the cover of a CD or video, the official release poster of a movie, or a comparable item. It will be included as that work's primary means of visual identification, at the top of the article about the book, movie, etc. in question.
to
|style=""|<span id="placeholderOptionNFCover"></span>
|This is the '''official cover art''' of a work.<br/>This is the cover or dustjacket of a book, the cover of a CD or video, the official release poster of a movie, or a comparable item. It will be included as that work's primary means of visual identification, at the top of the article about the book, movie, etc. in question.
Reason given below.
One of the choices given when the uploader selects that the file to be upload is non-free but is believed to be fair use is (emphasis added) is:
This is the official cover art of a work: This is the titlepage of a book, the cover of a CD or video, the official release poster of a movie, or a comparable item. It will be included as that work's primary means of visual identification, at the top of the article about the book, movie, etc. in question.
The highlighting is to show the conflicting advice given regarding books.
For books, "official cover art" (generally meaning the dustjacket if there is one, the actual cover if there isn't) and "title page" (a page inside the book, giving the title and publishers name etc.) are very different things indeed.
Both are works of craft, both are copyrighted, and both serve mostly decorative functions in the article. But a book cover/dustjacked it much more a work of craft, with the artist often credited and sometimes being a notable graphic designer, while a titlepage is simple and uncredited. A title page has no commercial value, a cover/dustjacket can have some. And a title page conveys no useful information to the reader, being purely decorative, while a cover/dusjacket can provide at least a bit of contextual background of how the work was presented to the public.
The advice is contradictory, but when it drills down specifically to books it does specifically say "titlepage", so that would supersede the more general instructions. And titlepage would be the more conservative choice.
But the "titlepage" advice given is wrong, for these three reasons:
All of our other materials (that I know of) say "cover" rather than "title page". For instance in Wikipedia:Non-free content it says "to allow identification of music albums, books, etc., only an image of the front cover art of the object is normally used".
As a practical matter, the great majority of our book articles use the cover/dustjacket rather than the title page and always have I guess.
By extrapolation from CDs (we allow covers to be used rather the allowing just an image of the disk label (which is the closest thing a CD has to a titlepage)) and from movies (we allow the movie poster to be used rather than tan just the title screen (which is the closest thing a movie has to a titlepage)), we can assume the more expansive definition of allowable images for identification is in effect.
I've never uploaded a photo before, but I've done three today--very easy, no trouble. Also, I really appreciated the template for adding the photos to articles, which I promptly did. N'Awlins Contrarian 02:48, 3 February 2019 (UTC) — Preceding unsigned comment added by N'Awlins Contrarian (talk • contribs)
I just want to say thanks for letting the file upload process be more seamless; I had to upload a book cover the other day, (File:Warriors, The Sight, Second edition cover.jpg), and it helped me through the copyright and fair use process better than I would've done myself. (I probably would have screwed up somewhere.) Anyway, thanks! – Ben79487 (talkcontribs) 02:28, 12 February 2019 (UTC)
www.interwork.com/
Please prepend <noinclude>{{pp-template|small=yes}}</noinclude> to the start of the page. It is currently template-protected (see the protection log) but the page is not currently tagged as such. Thanks, --DannyS712 (talk) 06:10, 8 March 2019 (UTC)
Nthep, The bigger problem is the upload wizard does not support en.m.wikipedia.org because MobileFrontend does not support the JavaScript required for the wizard to run. --AntiCompositeNumber (talk) 19:47, 8 February 2019 (UTC)
I found out a way to do so. Mobile users, click on the "Desktop" button at the bottom of the page. Then the page will reload. Once reloaded click the "Click here to start the Upload Wizard" button again. You should be able to see a new page and not a reload. Islameditor47 (talk) 11:10, 13 March 2019 (UTC)
Well, can something be done about this? I'm tired of having to click "Plain form for local uploads" then paste desired FUR in the upload form. --Kailash29792(talk)04:33, 22 June 2019 (UTC)
Well, can something be done about this? I'm tired of having to click "Plain form for local uploads" then paste desired FUR in the upload form. --Kailash29792(talk)04:33, 22 June 2019 (UTC)
Well, can something be done about this? I'm tired of having to click "Plain form for local uploads" then paste desired FUR in the upload form. --Kailash29792(talk)04:33, 22 June 2019 (UTC)
Adding a small notice re "Created by Upload Wizard"
I have been having the odd issue with editors that see the empty "n.a." fields that are no wholly required to meet NFC complain that these have to be filled in to meet NFC. I have tried pointing them to past discussions here where its been agreed those are not mandatory fields and the "n.a."s are fine.
I think it might be helpful that on the upload, if this wizard could spit out an additional line after the rational tables along the lines "This rationale was generated through the Upload Wizard, which by design may leave some fields as unfilled but otherwise meets the minimum requirements for NFC. If you make any edits to this rationale, please remove this text." This would make it clear that we broadly do not have problems with missing "n.a." fields that are generated by the Upload Wizard, but as soon as you make any rationale changes, you should try to complete those better. --Masem (t) 23:05, 16 July 2019 (UTC)
