Wikipedia talk:File upload wizard/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5 Archive 6 Archive 7 Archive 8 Archive 9

Why does the upload tool add "n.a." automatically?

Today I was disappointed to see that User:The Rambling Man had removed the infobox image from Sister (2021 film) while it was on the main page, on the basis that two of the sections of Template:Non-free use rationale said "n.a.". Why does the upload wizard fill these sections with "n.a."? If users are going to remove images from articles when the NFUR says "n.a.", then I think the upload wizard should fill those sections of the template with something more meaningful, or prompt the user to indicate how they should be filled. —Mx. Granger (talk · contribs) 16:19, 29 April 2021 (UTC)

The template needs to be read in conjunction with the licensing that is assigned during the upload to evaluate all 10 points of NFCC. NFCC does not require the use of the template or that the template include all fields, just that on the file: page, all 10 points are addressed to a degree (and they don't have to be spelled out, point-by-point). There also is common sense aspects at play as well. So to take the version of that poster prior to today [1], it was "missing" an NFCC#1 (replacability) and NFCC#2 (respect for commercial). Meeting NFCC#1 should be patently obvious that a movie poster for a 2021 is not going to have a free replacement, while the NFCC#2 is actually addressed by the license terms.
I agree that the Wizard should have these fields available to be filed in, and should put in some better default text than n.a., but they aren't required to be spelled out per NFCC. The only required ones that are to be spelled out (either because this is info only the uploader knows or to show the actual thought going into NFCC selection) would be NFCC#4 (source of original publication), NFCC#7/9 (article to be used in) and NFCC#8 (purpose of use). Everything else is information that can be gleaned by considering how the image is used or comparing the source to what else is available, though obviously if the uploader included details, that would help. --Masem (t) 16:33, 29 April 2021 (UTC)
I use a belt-and-braces approach to this kind of thing. Assuming that something is "patently obvious" is a very bad idea, and adding "no free replacement exists as this is a movie poster" is far preferable to "n.a." which literally means "not applicable", and that should be "patently obvious" that it is still applicable, just covered. The time it takes to complain about this kind of thing is probably an order of magnitude longer than it takes to properly and comprehensively address it. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 18:52, 29 April 2021 (UTC)
As we have learned from the past with BetaCommand/Delta, while NFCC is a hard policy like BLP that allowed heavy-handed enforcement to make sure it is followed, it still requires interpretation and appropriate considerations for the given case (like, patently obvious situations that extend from the various drop-downs from the uploader like a movie poster). I do agree that leaving "n.a." is probably not the right answer at the end of the day because every part of the 10 NFCC criteria is applicable, just that some answers to the rationale don't need to be spelled out. I don't know of a better way to default-answer those cases outside of standard boilerplate that I've seen (eg NFCC#1: "It is believed there is no free equivalent version of this copyrighted work nor could a free version be obtained."; NFCC#2 "It is believed the use of this work is within fair use and does not harm the commercial nature of the original work", etc.) which should be given and allowed to be overridden by the Wizard users as needed. --Masem (t) 21:00, 29 April 2021 (UTC)
Yes, the point is "n.a." is factually incorrect. I don't care what the "wizard" does, what I do care about is fair use images which claim that certain aspects of NFCC are "not applicable" which is blindingly obviously incorrect to anyone who reads NFCC. There is absolutely no excuse to not fill in n.a. to something more appropriate, none at all. "Economy" is directly equivalent to laziness or ignorance. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 21:07, 29 April 2021 (UTC)
(ec) This has been discussed before (as Masem probably remembers). If somebody removed the image from the article because he felt the rationale was lacking, that's an unfortunate misjudgment. These rationales are perfectly adequate, for the standard use scenarios they are meant for. Some sections in them say "n.a." because in these particular cases, the fulfillment of these particular aspects of the NFCC is blindingly obvious and trivial and therefore doesn't require explicit explanation. This is simply a question of economy: in order to help uploaders understand the need to fill in rationales, we must reduce the information load during the process as much as possible, getting people to focus on those parts of the rationales that are actually non-trivial and do require individual thought and individual explanations. And the wizard doesn't fill in some default boilerplate rationale instead because that's not its job: the wizard must only ever fill in those pieces of information the user has seen and understood during the upload process. Fut.Perf. ☼ 18:56, 29 April 2021 (UTC)
Clearly "not applicable" is incorrect. But don't let that get in your way. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 18:58, 29 April 2021 (UTC)
  • So, what is the solution here? The current situation, where the upload wizard fills in "n.a." and at least one editor considers that to be grounds for removing valid images from articles, is not acceptable. Can someone change MediaWiki:FileUploadWizard.js to fill in something other than "n.a.", or will The Rambling Man agree to stop removing these images from articles? —Mx. Granger (talk · contribs) 09:52, 2 May 2021 (UTC)
    The correct solution is to fill in all fields and don't claim that certain aspects of NFCC are "not applicable" because it's patently obvious that that is completely untrue. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 20:52, 22 May 2021 (UTC)
    @The Rambling Man: I take it you're suggesting we modify the upload wizard so that it stops filling in "n.a.". Have I understood correctly? —Mx. Granger (talk · contribs) 05:37, 23 May 2021 (UTC)
    No, that's not what I'm suggesting. I'm saying make sure all uploaded fair use files are correctly tagged for every one of the NFCC. I don't care how that is achieved. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 07:19, 23 May 2021 (UTC)
@Masem, Future Perfect at Sunrise, and The Rambling Man: I suggest we modify the upload wizard so that it inserts something more specific and relevant than "n.a." in the disputed areas. Is this suggestion acceptable to everyone? If so, I'll make a protected edit request. —Mx. Granger (talk · contribs) 07:41, 23 May 2021 (UTC)
Yes, but what should it insert? It mustn't insert anything that the uploader hasn't read and agreed to during the upload process (because the rationale must ultimately be the uploader's responsibility, not the bot's). And our uploaders don't have the attention span to read and think about statements like 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". Forcing uploaders to read through that kind of trivial boilerplate doesn't help the process; it will only lead to information overload and reinforce the misunderstanding that the entire FUR issue is just about this kind of boilerplate, diverting uploaders' attention away from those parts of the form where their individual input really matters. So how are you going to break down that information into something that an average uploader can read and understand in less than ten seconds? Fut.Perf. ☼ 07:57, 23 May 2021 (UTC)
In the cases of the standard types of uploads, something boilerplate is better than nothing, but it is better to present the user that boilerplate and say "you can use this language below and continue with the uploader, but if your image is a special case, please consider modifying it as necessary to meet your needs." And no, complaining that it takes longer for 10 seconds to read is the wrong thing to be worried about with NFCC, as this is a serious matter for WP, editors need to be aware of the implications of NFC use and thus need spend time to at least read through the first few times they upload images. Experienced users will have no issues. --Masem (t) 13:30, 23 May 2021 (UTC)
If uploaders don't understand NFCC enough to fill in the fields themselves, they shouldn't be uploading fair use images. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 15:09, 23 May 2021 (UTC)
I mean, I think Fut Perf did what he had to do probably. It wasn't URGENTTTTT so maybe some kind of tagging... can you PROD images? Leave it in the article and do that, and if contested you have a hassle (images for deletion maybe) but then uploader learns. But what he did was OK too.
So I mean the totality, you have to look at the totality... rationale was "to serve as the primary means of visual identification at the top of the article dedicated to the work in question" which I think is generated by a checkbox... that's part of the totality, it is one date point to help answer the question "should this exception be allowed". It's not the same as "The map concealed in the protagonist's shirt lace (seen here) cannot be seen by people with green-black colorblindness, a rare condition which the villain unknowingly had, this being the driver of the plot" or something. Those're different things. The " visual identification" thing is really allowed because it's decorative (it does make these articles look much better, and that's good), it isn't really something that the owner is likely to mind in real life (it's publicity), and the community decided to carve out this exception. It's not mission-critical to these articles.
And we don't know for a stone fact that the answer to "Not replaceable with free media because:" is "actually it is, the studio has released a somewhat similar version to the public domain, I just think this one works better", or that the answer to "Respect for commercial opportunities" is "actually, turns out a guy downloaded this image from here and published it in a book (with other images, granted) which sold 100,000 copies, and he's being sued by the copyright holder, but enh."
I personally don't much care about being super-strict about copyright, but the Foundation realllllly cares, and that matters. We're not toadies to the Foundation but neither would being loose on copyright be a good hill to die on. So I enforce the copyright rules pretty strictly (reduce quotes from a paragraph to a sentence when I see them, that sort of thing), and admins are basically sworn to do so.
So, I always fill in the blank, and now OP has learned to, so win-win. Herostratus (talk) 15:17, 23 May 2021 (UTC)
Maybe change the "wizard" to say "FILL THIS IN YOURSELF" instead of "n.a." which is patently untrue. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 15:34, 23 May 2021 (UTC)
I don't know how all the use cases break down, but I do know the ones I commonly use, the two fields of "respect for commercial opportunity" (NFCC#2) and "nonreplacable" (NFCC#1) are given in the uploader as I work through it but are left empty and can be left empty but allowed to proceed to uploading (which results in the n.a.). As I mentioned, it would be far better to add placeholders for the more standard types of images like movie posters, logos, etc., which while may be boilerplate, does satisfy the NFCC requirements. For other images that do not have standard approaches, such as historical images, these fields should be required and non-empty.
Key is that "n.a." is the problem. There is some rational that applies and the choice to use "n.a." makes it look like this field was purposely ignored. I know FP has stated their intense dislike for boilerplate but there are times that boilerplate is just fine for common uses of NFC. --Masem (t) 15:56, 23 May 2021 (UTC)

I'm not sure if everyone in this discussion understands that the upload wizard does not give the user an option to input something other than "n.a.". The "n.a." is filled in automatically, and if the user wants to change it they have to somehow know that the upload wizard leaves them at risk of having the image removed by The Rambling Man and edit the description page to change the "n.a." to something else. For instance, @Herostratus: even though you always fill in the blank, a number of description pages for images you uploaded say "n.a." [2] [3] [4]. Indeed, the same is true of The Rambling Man's uploads! [5] [6] In any case, here is a concrete proposal below. —Mx. Granger (talk · contribs) 18:30, 23 May 2021 (UTC)

Oops. Well boy howdy, butter my buns and call me a biscuit. OK, well, mostly I do I think. Another random thought, I'll bet a number of ESL users, and maybe even some native English speakers from, I don't know, South Africa, are not familiar with "n.a." (BTW FWIW I often see it as "N/A".) Most are, but we want to be global when when it's easy. It's an easy change for the programmers I suppose. "This field intentionally left blank" or whatever. Herostratus (talk) 19:45, 23 May 2021 (UTC)
You also can't fill in the "Author or copyright owner" after uploading (it looks like to me) so that's a bug I guess. Herostratus (talk)

Specific proposal for changing MediaWiki:FileUploadWizard.js

Extended content

In lines 1236–1240, change 

        // 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.
        descFields.Replaceability = "n.a.";
        descFields.Commercial     = "n.a.";

to 

        descFields.Replaceability = "This file is not replaceable because it is the subject of the article.";
        descFields.Commercial     = "It is believed that this file does not replace the original market role of the original copyrighted material.";

In lines 1266–1267, change 

        descFields.Replaceability = "n.a.";
        descFields.Commercial    = "n.a.";

to 

        descFields.Replaceability = "The file is not replaceable with free media because the photographed work is copyrighted.";
        descFields.Commercial    = "It is believed that this file does not replace the original market role of the original copyrighted material.";

In lines 1279–1285, change 

        // FURs for screenshots etc. don't normally need to bother
        // about replaceability (with free images) and with commercial role,
        // but do need to bother about purpose and about replaceability with text.
        descFields.Purpose        = opts.NFPurpose;
        descFields.Replaceability_text = opts.NFReplaceableText;
        descFields.Replaceability = "n.a.";
        descFields.Commercial     = "n.a.";

to 

        descFields.Purpose        = opts.NFPurpose;
        descFields.Replaceability_text = opts.NFReplaceableText;
        descFields.Replaceability = "The file is not replaceable with free media because the underlying work is copyrighted.";
        descFields.Commercial     = "It is believed that this screenshot does not replace the original market role of the original copyrighted material.";

In lines 1293–1294, change 

        descFields.Replaceability = "n.a.";
        descFields.Commercial     = "n.a.";

to 

        descFields.Replaceability = "The file is not replaceable because it is the official cover art of the work.";
        descFields.Commercial     = "It is believed that this file does not replace the original market role of the original copyrighted material.";

In lines 1302–1303, change 

        descFields.Replaceability = "n.a.";
        descFields.Commercial     = "n.a.";

to 

        descFields.Replaceability = "The file is not replaceable because it is the official logo.";
        descFields.Commercial     = "It is believed that this file does not replace the original market role of the original copyrighted material.";

Is this change acceptable? —Mx. Granger (talk · contribs) 18:30, 23 May 2021 (UTC)

Well, most of these statements aren't really rationales. They are simply restatements of the corresponding NFCC clauses. You're merely asserting that the criterion is met, but you aren't really explaining why. Well, sure, it shouldn't be necessary to explain why, because in these cases it's so damned obvious. That's what I've been saying all along. But still, if you think you need an actual rationale, then provide one. Say why it's not replacing the original market role. If you don't do that, I don't really see how this change makes any difference. Fut.Perf. ☼ 18:56, 23 May 2021 (UTC)
And not only that, now it's just click to fill it, doesn't mean you've considered it for one second or that's it's true, you just want to use the image. It's like "own work", you see that when it's highly doubtful. So, you could mabye do one of these three:
1) replace the text with something else, such as "This field left blank, which will cause deletion of this file", or
2) make them type something, and refuse to upload the file if you don't. If they just type a letter or "n.a." that's obvious cause for immediate deletion, or
3) some kind of tag like PROD is generated if the field is left blank. Herostratus (talk) 20:39, 23 May 2021 (UTC)
Sigh. The whole point about having the File Upload Wizard is to relieve uploaders from the need to fill in their own text for these particular entries, in these specific cases, because it's not worth forcing them to consider them – because they won't do it anyway. Just accept the fact, we do not have the luxury of choosing which users can or cannot upload pictures, and the huge majority of them just won't understand and won't want to think about the technicalities of the NFCC. Forcing people to enter their own text in these fields will only lead to even more nonsense and even more deficient rationales. The whole point of this page is to guide uploaders away from these boilerplate fields and instead concentrate on those where they really have something meaningful and individual to say and where this individual input really matters. "Replaceability" and "Commercial opportunity" for logos or cover art isn't among those. Fut.Perf. ☼ 08:22, 24 May 2021 (UTC)
I have to agree with Future Perfect at Sunrise here. Making people type something to these questions they don't understand just results in self-defeating "rationales" that are worse than the boilerplate "n.a". The specific pitfalls of NFCC varies by media type, and as Fut.Perf. says above, for logos and cover art it's not NFCC#1 or NFCC#2. – Finnusertop (talk ⋅ contribs) 08:46, 24 May 2021 (UTC)
Repeat: If people can't justify every aspect of NFCC they shouldn't be uploading fair use images. It's very simple. "n.a." is patently incorrect for any aspect of a fair use image. Simple: lack the competence to fill in the justification for every criteria? Don't upload. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 09:22, 24 May 2021 (UTC)
@The Rambling Man: Then please help us build consensus to change the upload wizard. Currently there's no way for the uploader to stop it from filling in "n.a.".
I think it's unlikely we'll be able to come up with text that everyone thinks is ideal. My thinking with this proposal is that the text is at least more accurate and no worse than "n.a.". Can we agree that the proposed text is better (or at least no worse) than the current text, even if it's not ideal? —Mx. Granger (talk · contribs) 17:47, 24 May 2021 (UTC)
Alright, reasonable, let's do it. I suppose it's worth giving it a try. Herostratus (talk) 02:39, 25 May 2021 (UTC)
Thanks. I'm not sure if we quite have consensus here, so pinging the other users who have commented in this subsection. @Future Perfect at Sunrise and Finnusertop: Can you live with this proposal as a way to address the concerns about "n.a." without requiring uploaders to fill in their own text for these entries? —Mx. Granger (talk · contribs) 12:58, 30 May 2021 (UTC)
Are you going to present these contents to the user during the uploading process? I'm still quite opposed to having things filled in silently without the user's prior knowledge. But if the user should see them, more changes to the code will be required than the ones you proposed above. Fut.Perf. ☼ 19:31, 30 May 2021 (UTC)
@Future Perfect at Sunrise: The current version of the upload wizard silently fills in "n.a." without the user's prior knowledge – is that not equally objectionable? —Mx. Granger (talk · contribs) 08:57, 31 May 2021 (UTC)
Also, while there might be objections to some of the messages that might be used as fill-in in without the user's knowledge -- I don't see a problem there, within reason, but whatever -- surely some are OK: I think that "[this field left blank by uploader]" or whatever ("[uploader did not provide data]" etc etc) -- these are simple descriptions of what happened. Whenever you do something, a simple neutral description or record of what happened seems OK. Not every new user knows that they are leaving diffs I suppose, but we still do and its fine. Herostratus (talk) 21:37, 31 May 2021 (UTC)
"This field left blank by uploader" would be misleading, because the upload wizard doesn't allow the uploader to fill in the field. "This field left blank" would be okay with me. —Mx. Granger (talk · contribs) 18:12, 1 June 2021 (UTC)
I'm late to the party but this is continuingly relevant. The suggestions above are of the right form, but don't actually explain the reason the NFCC conditions are met. For instance, in the case of a screenshot, replaceability should be something like "The network, studio, distributor and/or production company [could use the already-asked "Author" field to fill in the specific organisation] own intellectual property rights and as such all depictions of the work in question are necessarily non-free". For commerciality, say something about a single frame from a much larger work not replacing the entertainment or educational value of the product. If Fut.Perf. insists then fill this in as a default in a textbox that the uploader can change. I also think we should be using a default for minimality—do I really need to say every time that it's one image, low resolution and I'm just using it once in one article? — Bilorv (talk) 23:57, 17 July 2021 (UTC)
This issue has been raised again below: #Ensuring compliance with wp:FUR. It would be great if we can get consensus for a solution. —Mx. Granger (talk · contribs) 16:32, 19 July 2021 (UTC)

Mobile web

Why this File Upload Wizard in Wikipedia not working in mobile web? Nghiemtrongdai VN (talk) 06:02, 12 July 2021 (UTC)

Special:Upload

Is there an easy way or JavaScript that can change the "Upload file" link? I want it to send me directly to Special:Upload instead of Wikipedia:File Upload Wizard as I don't feel like clicking 'upload file' and then 'plain form for local uploads' every time I need to upload an image Some Dude From North Carolina (talk) 01:04, 14 July 2021 (UTC)

You're talking about the left sidebar link? We could change that, yeah, but I don't think we'd want to. It's very important that we help out beginners, and the wizard does that (somewhat) better than the plain form. Overall, the whole thing needs a top-to-bottom refresh to make it more like the Commons wizard. {{u|Sdkb}} talk 01:34, 14 July 2021 (UTC)
Yeah, I was referring to the sidebar link, but I'm not suggesting changing it for everyone. I was asking if there an optional way for experienced users to be sent directly to Special:Upload, like creating a downloadable code that I could add in Special:Mypage/common.js. Some Dude From North Carolina (talk) 11:38, 14 July 2021 (UTC)
@Some Dude From North Carolina, oh, I see; thanks for clarifying. That should be fairly straightforward for someone who knows how to code scripts; you could ask at WP:Script requests. {{u|Sdkb}} talk 03:15, 20 July 2021 (UTC)
Thanks for the tip. I have entered a request. Some Dude From North Carolina (talk) 13:47, 20 July 2021 (UTC)

Ensuring compliance with wp:FUR

Background
Problem

The uploader currently presents the WP:FUR for WP:NFCCP#1 and WP:NFCCP#2 as "n.a.". Various users have taken exception to that as it is not really a proper WP:FUR.

Pings

@Future Perfect at Sunrise, The Rambling Man, Seraphimblade, and Levivich: Discuss? –MJL ‐Talk‐☖ 04:06, 19 July 2021 (UTC)

  • It appears that the New Hampshire image has already been corrected, so that's not at issue. The wider question is that apparently, this script has since 2012 been generating invalid nonfree rationales with "n.a." in some fields. That cannot continue, as every NFCC criterion applies to every use of every nonfree image. There is never a "not applicable" case for any reason or at any time, nor may anyone say "Well it's obvious." If it's obvious, it should be easy to say why it passes, but it is required to explicitly say why, not handwave at it.
    So, that said. We have a couple of issues here; the first being how to fix the script to generate complete and valid rationales, and the second being how to remediate existing images. The fix should be the highest priority; when there's a pipe gushing water, the first priority is to shut the water off. So we need to determine if there is appropriate boilerplate to use for all of these nonfree instances (or at least 95%+ or so of them; we'd get at least that much of an error rate if entered by hand.) If we can do that, the bailing out of the water (or in this case the remediation of existing broken rationales) is also simple—we'll have a bot replace "n.a." with the appropriate boilerplate text. We should also then have the image added to something like Category:Automatically fixed nonfree image rationales, so that interested editors can verify that the bot fixes are right and remove that category, and if the bot fix is wrong handle it however need be. Once that category is empty, we've finished the cleanup. I have already proposed some wording for logos, but will see if I can come up with appropriate proposed wording for all ten cases where there is currently an "n.a.", and if so will propose those shortly.
    If for any particular category of images boilerplate is not reasonable, then we'll have to figure out exactly how we'll handle that, both in terms of fixing the Upload Wizard tool and in terms of remediation to impacted existing images. My suggestion, should this be necessary, would be a prompt in the Upload Wizard for the uploader to explain their rationale for those criteria, a category for images that cannot be automatically fixed, an automated talk page note to the uploader of impacted image(s) which were already uploaded, and some grace period (the length to be determined based upon the number of files impacted) during which files with an invalid "n.a." entry should not be removed for that reason alone. Once the grace period expires, files which still have an "n.a." should then be removed and if appropriate nominated for F5 deletion. Seraphimblade Talk to me 04:53, 19 July 2021 (UTC)
  • All sounds reasonable. Just for avoidance of doubt, this isn't new news, see the "Why does the upload tool add "n.a." automatically?" section above here. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 11:02, 19 July 2021 (UTC)
  • Pinging @Masem, Herostratus, Finnusertop, and Bilorv: who also participated in the discussion above about this problem. —Mx. Granger (talk · contribs) 16:31, 19 July 2021 (UTC)
  • I have said before that the Upload Wizard should not be leaving behind n.a., and thus it should be fixed. We allow canned responses to some NFC rationales (we even have some FUR templates like for logos), and having something in place , even if canned, is better than nothing for future NFC maintenance. Users of the wizard should be encouraged to review even the canned rationales after uploading to make sure they are happy with them, but this should not be a required step. --Masem (t) 16:38, 19 July 2021 (UTC)
  • Seraphimblade suggests some very good ways forwards. I just thought I'd add that I am actively in favour of (rather than just tolerating) canned rationales where the reason is based on the type of work depicted (e.g. an official movie poster). Users should obviously be asked to enter bespoke rationales where the reason is actually different from case to case ("Purpose of use in article"), and be free to change the cookie cutter if they have something valuable to say in specific, but boilerplate is actively advantageous for speed of uploading an image, speed of reading comprehension by patrollers, ability for automation to make mass changes at a later date based on new consensus etc. And "n.a." is not sufficient as boilerplate. — Bilorv (talk) 18:11, 19 July 2021 (UTC)
OK, I got pinged. After reading the above arguments, I became pretty flexible, and what I think is:
  • "n.a." is not acceptable or at any rate capable of being improved, and it looks like most everyone agrees with that.
  • Beyond that, most anything is better. Blank is a better. "This field left blank by uploader" is better. "No rationale provided" is better. Anything like that, count me in with which ever has the most votes. If there's going to be a formal RfC and the decision from these discussions will provide the alternative to "n.a" (please don't provide multiple alternatives, that makes a stalemate), or if these discussion right here are going to decide what the change will be if any, either way: If "No rationale provided" has more votes, add my vote to that. If "Field left blank, please provide data" has more votes, add my vote to that. The point is to get one of these over the finish line, I don't care which. Even "no rationale provided, please either provide or delete" or automatically PRODding the image is better I guess, altho kind of drastic. Whatever has the best chance of replacing the horrid "n.a.".
  • I am not on board with replacing "n.a." with ""It is believed that this file does not replace the original market role of the original copyrighted material" and similar for other fields. It's likely to be false in some cases and that is not OK. If a human uploader typed this herself for all her uploads even when its not true, she would be scolded. Robots don't get a pass. I suppose even "n.a." is better than that. Herostratus (talk) 19:26, 19 July 2021 (UTC)
  • We have a number of templates like {{Non-free use rationale logo}} which, if the user doesn't override the fields, will insert boilerplate rational that is appropriate for the bulk of logo uses out there. There is zero difference between this and boilerplate entries on the Wizard, as long as it is clear to the user on uploading they should double check the final rationale and make changes if the situation is atypical of the common usage of that type of non-free. --Masem (t) 04:24, 21 July 2021 (UTC)
  • I think it's clear now that the involved threat from the admin use Future Perfect who said they would block people for commenting out fair use images with incorrectly completed fair use criteria because of the badly coded wizard should now be summarily ignored. This was never about disruption or doing anything harmful to Wikipedia, quite the opposite in fact. I will continue to comment out badly formatted fair use images which whose articles are targeted from the main page, and if I am blocked for doing so, I will happily reference this discussion. It would be better if the involved user clarified their position and agreed their initial threat was unfounded and inappropriate. The Rambling Man (Keep wearing the mask...) 19:33, 19 July 2021 (UTC)
    Future Perfect at Sunrise can you confirm your erroneous statement and retract it here please? The Rambling Man (Keep wearing the mask...) 23:34, 19 July 2021 (UTC)
    Read carefully. I never said I personally would block somebody, and I certainly didn't say I'd block you personally. I've had the misfortune of being exposed to your poisonous character a few times to often to feel comfortable doing that. I predicted somebody would have to be blocked, and I still believe going through existing images and removing them – if the images themselves are objectively ok and the uploaders were relying in good faith on what the community was telling them was the right way to upload them – would be a colossal dick move, and potentially blockable disruption if done persistently. But this is off-topic here. If you're not here to contribute to actually improving the rationales, go and take your grievances somewhere else. Fut.Perf. ☼ 08:16, 20 July 2021 (UTC)
    A personal attack from an admin. What a surprise. I think you're the one who needs to take a look at yourself here. I've suggested a fix to this several times and all you want to do is sit on your hands and ignore that there's even a problem. As noted several times, I'm only commenting out the images with a note that "n.a." is simply not an acceptable rationale (which we all agree) and I'm only doing it on images in articles targeted from the main page. So do yourself a favour, dial the personal attacks down a notch and stop with the threats. The Rambling Man (Keep wearing the mask...) 08:28, 20 July 2021 (UTC)
@The Rambling Man: Please stop commenting out images purely because they were uploaded with the upload wizard. That is disruptive behavior. —Mx. Granger (talk · contribs) 05:29, 20 July 2021 (UTC)
Yes, now that the problem is identified and we look like a chance will be coming to the Wizard, we have to resolve how we'll fix the existing images. There's a good chance many can be "fixed" using other information (if its a logo, a film screenshot, etc.) that a bot can fill in any current n.a.s, but we should not be forcing this on images since this is only a recently discovered problem and no resolution method has been identified. That said, images on articles up for TFA, or at FA, should be appropriately fixed a priori of any solution here. --Masem (t) 05:32, 20 July 2021 (UTC)
I've only commented out images with inadequate fair use rationales that are in articles targeted from the main page and will continue to do so, whether it's the wizard at fault or a human at fault. It's a problem and just letting it slide is not acceptable. Cheers. The Rambling Man (Keep wearing the mask...) 08:25, 20 July 2021 (UTC)
Feel free to edit the image description pages as appropriate. It is disruptive to remove valid images from articles just because they were uploaded using the upload wizard, and it's especially disruptive if the articles are being featured on the main page. —Mx. Granger (talk · contribs) 18:56, 20 July 2021 (UTC)
No, you've got it the wrong way round. I'm not responsible for correctly filling in NFCC for fair use images that are in articles linked from the main page unless I've uploaded them myself. People who upload fair use images are solely responsible for the correct adherence to our policy, NFCC. Your claim that me commenting them out, and stating that is somehow disruptive, is indicative of a lack of comprehension and/or competence. Please, don't do that again. Your attitude along with that of the NPA-loaded admin here is just beyond belief. The Rambling Man (Keep wearing the mask...) 01:18, 21 July 2021 (UTC)

Proposed boilerplate and results of a semi-random check

I put together some proposed boilerplate, and then semi-randomly checked 25 files to see if it would be appropriate to use the boilerplate there. (By "semi-random", I used ProcrastinatingReader's script populated category of affected files, and used five files each from the first two pages, and then five each from the first three pages of "A" in case the use of non-letter characters introduced some skew). On 22 pages the replaceability boilerplate would have been valid to use, on 3 it would not have been for at least one rationale on the image page. On all 25, the commercial boilerplate would have been appropriate. The proposal and test results are located here. If anyone else would like to check some more images so we can have more comprehensive test results, please feel free to add them there. I would like to get feedback, given these results, if the use of boilerplate is a realistic solution. Seraphimblade Talk to me 22:24, 19 July 2021 (UTC)

It's certainly "realistic" to the extent that uploaders have used the wizard's upload types correctly – like, choosing the "logo" category for items that are actually logos used at the top of an article, etc. The categorization used by the wizard was designed rather carefully in such a way that all files of a given type should fulfill the same conditions in a predictable way. What we can't of course control for are those cases where uploaders misused an upload category for something else – e.g. uploading something as "object of commentary" when it isn't an object of commentary. In those cases, the rationales are of course wrong now, and will remain wrong after you substitute the text. They also would have been wrong in just the same way if the wizard had offered that text from the start during the upload, and they would still have been wrong if we had left it to the uploader to provide their own text. Unsalvageable uploads will remain unsalvageable no matter what we do, or might have done. Fut.Perf. ☼ 09:41, 20 July 2021 (UTC)
Well, if that's a frequent occurrence, hand entry would be the ideal way, as that would at least force the uploader to give it some amount of thought. But from the sample of images I looked at, I didn't see any wrongly categorized, and only a few for which the rationales were invalid generally. We would have some error rate with any solution, of course, so the question is if the error rate with the boilerplate would be unacceptably higher, and I don't believe it would be. But right now, the error rate, at least on those image types when uploaded with this tool, is 100%, as an incomplete and invalid rationale is being generated for them all. Seraphimblade Talk to me 18:33, 20 July 2021 (UTC)
Agreed. And as you can see from earlier discussion, even when simply commenting those out with a note that the erroneous "n.a" needs to be filled in (by the uploader, who is responsible for NFCC compliance), we have at least one admin suggesting that's a blockable offence. I think almost literally any boilerplate is better than the errors the "wizard" are currently introducing in tens of thousands of instances. It's pretty clear that the average uploader is just assuming "not applicable" is justification when it patently is not. The Rambling Man (Keep wearing the mask...) 21:00, 22 July 2021 (UTC)
Seraphimblade it's been a week now and there's been no reasonable objection to your plan. What now? The Rambling Man (Keep wearing the mask...) 18:07, 26 July 2021 (UTC)
The Rambling Man, sorry, I had some things come up unexpectedly and wasn't really able to find time here. I think that's settled now, so I think the first step is to edit the script to put in the boilerplate and at least fix it going forward. From there, we'll need to set up the bot to correct previous ones. I don't have a ton of experience at bot/script writing, so if someone who already is more experienced wants to take care of that, good by me. Otherwise I can get it figured out. Seraphimblade Talk to me 19:15, 30 July 2021 (UTC)
Seraphimblade no worries, life happens. It's disappointing that the 'admin' who apparently condones the current behaviour of the faulty wizard won't help, but hopefully you can help when you get the time. A couple of images I commented out (which were in articles targeted from the main page, for the avoidance of doubt) appear to have been fixed up nicely with no hostility (unlike what I've seen and experienced here and elsewhere), so I'm glad we're going to finally resolve this problem, thanks for your efforts. The Rambling Man (Keep wearing the mask...) 21:20, 30 July 2021 (UTC)

Interface-protected edit request on 31 July 2021

Line 1239

Current: descFields.Replaceability = "n.a.";
Replace with: descFields.Replaceability = "Any derivative work based upon the artwork would be a copyright violation, so creation of a free image is not possible.";

Line 1240

Current: descFields.Commercial = "n.a.";
Replace with: descFields.Commercial = "The use of a low resolution image of the artwork will not impact the commercial viability of the art.";

Line 1266

Current: descFields.Replaceability = "n.a.";
Replace with: descFields.Replaceability = "Any derivative work based upon the artwork would be a copyright violation, so creation of a free image is not possible.";

Line 1267

Current: descFields.Commercial = "n.a.";
Replace with: descFields.Commercial = "The use of a low resolution image of the artwork will not impact the commercial viability of the art.";

Line 1284

Current: descFields.Replaceability = "n.a.";
Replace with: descFields.Replaceability = "The software or website from which the screenshot is taken is copyrighted and not released under a free license, so creation of a free image is not possible.";

Line 1285

Current: descFields.Commercial = "n.a.";
Replace with: descFields.Commercial = "The use of a low resolution screenshot from software or a website will not impact the commercial viability of the software or site.";

Line 1293

Current: descFields.Replaceability = "n.a.";
Replace with: descFields.Replaceability = "Any derivative work based upon the cover art would be a copyright violation, so creation of a free image is not possible.";

Line 1294

Current: descFields.Commercial = "n.a.";
Replace with: descFields.Commercial = "The use of a low resolution image of a work's cover will not impact the commercial viability of the work.";

Line 1302

Current: descFields.Replaceability = "n.a.";
Replace with: descFields.Replaceability = "Any derivative work based upon the logo would be a copyright violation, so creation of a free image is not possible.";

Line 1303

Current: descFields.Commercial = "n.a.";
Replace with: descFields.Commercial = "The use of a low resolution image of an organization's logo in the article about that organization will not impact the commercial viability of the logo."; Seraphimblade Talk to me 17:32, 31 July 2021 (UTC)

 On hold @Seraphimblade: would you please make the changes in a sandbox (I inited one that can be deleted after this is done here: User talk:Seraphimblade/MediaWiki:FileUploadWizard.js) and verify that there are no syntax errors first? — xaosflux Talk 21:38, 31 July 2021 (UTC)
Xaosflux, this is done ([7]). Note that the five warnings present were there prior to the changes as well. Seraphimblade Talk to me 21:45, 31 July 2021 (UTC)
Changes look good (I tested them as well), so  Done; thanks, Seraphimblade. (I also took the liberty of removing the "I hate FURs" comment.) Writ Keeper ⚇♔ 17:08, 2 August 2021 (UTC)
Thanks folks, some tangible practical improvement, much appreciated. The Rambling Man (Keep wearing the mask...) 17:20, 2 August 2021 (UTC)

Add Spanish language

Hello, could you add spanish language to edit spanish pages? GyzerDesigns (talk) 15:09, 5 August 2021 (UTC)

@GyzerDesigns: While it's possible to set your interface language to Spanish, this is ultimately the English Wikipedia. Spanish Wikipedia presumably has it's own wizard (if it accepts fair use works; not all do), and Commons is multilingual. {{u|Sdkb}} talk 16:09, 5 August 2021 (UTC)

Grammar

In the options for This is an historic portrait of a person no longer alive., I think there are two grammatical errors.

This is an historic portrait of a person no longer alive.

A quick search on Google brings up a majority of sources favouring "a historic".

(where exactly did you get this file from?)

'Where' should be capitalised for consistency with the rest of the labels.

Seloloving (talk) 00:32, 24 August 2021 (UTC)

 Done here. Thanks for spotting those things! I think there are much bigger changes we should be considering for this wizard, too, but having better grammar for it in the interim will be a plus. Cheers, {{u|Sdkb}} talk 02:34, 24 August 2021 (UTC)
Sdkb, Thanks! I would just like to point one the "This is an historic portrait of a person no longer alive" text itself, where "an historic" has been left out. :) Seloloving (talk) 03:15, 24 August 2021 (UTC)
Fixed that, too, now! {{u|Sdkb}} talk 03:27, 24 August 2021 (UTC)

Edit request; 9 October 2021

This is a '''historic portrait''' of a person no longer alive.<br/>This is a historic photograph or other depiction of a person who is no longer alive. It will be used as the primary means of visual identification of that person in the article about them.

Please change the two uses of "historic" to "historical". Please see Merriam-Webster's explanation on the distinction. Thank you, Sdrqaz (talk) 20:27, 9 October 2021 (UTC)

 Done --Ahecht (TALK
PAGE) 20:38, 12 October 2021 (UTC)

Edit requests on 27 September 2021

Please make the changes here and here. This adds a notice if you do not have javascript enabled. Thanks. Dylsss(talk contribs) 00:13, 27 September 2021 (UTC)

Interface-protected edit request on 29 October 2021

Remove lines 19–22 ("loading the accompanying CSS"). This is better done using withCSS (as I've done in Special:Diff/1052460258) to remove delay between loading of the JS and CSS. Now they're getting loaded twice.

I am assuming Wikipedia:File Upload Wizard is the only place where the script is being used. – SD0001 (talk) 08:05, 29 October 2021 (UTC)

 Done — xaosflux Talk 14:29, 1 November 2021 (UTC)

Recognize mp3 as accepted format

I discussed the Wizard not recognizing mp3 as an accepted format (#mp3 not accepted by Wizard?). Then I was told that, to make Wizard recognize mp3, whose patent has expired a few or several years ago, I must add audio/mp3 as part of filebox.accept (line 108 of MediaWiki:FileUploadWizard.js). Now here I am requesting the addition/change to the Wizard. George Ho (talk) 18:57, 28 October 2021 (UTC)

 Done try now @George Ho: — xaosflux Talk 19:11, 28 October 2021 (UTC)

Thanks. But the Wizard doesn't automatically add ".mp3" after titling a file without adding extension. I figured that mp3 must be also added in name.replace (line 1819) and var extensions (line 1852). --George Ho (talk) 19:36, 28 October 2021 (UTC)

 Done added. — xaosflux Talk 14:25, 1 November 2021 (UTC)

Thanks again. What about adding "mp3" among the list of "Permitted file types", like mid and ogg, in the source of Wikipedia:File Upload Wizard? --George Ho (talk) 22:56, 8 November 2021 (UTC)

 Done – Jonesey95 (talk) 23:30, 8 November 2021 (UTC)

"You do not have JavaScript enabled"

I'm unable to use this script as I'm told that I don't have JS enabled, despise the fact that I have got it enabled. Can someone please have a look at this? ‑‑Neveselbert (talk · contribs · email) 19:39, 6 November 2021 (UTC)

@Xaosflux: since you were the last person to edit. ‑‑Neveselbert (talk · contribs · email) 19:40, 6 November 2021 (UTC)
@Neveselbert: is this a new problem? Are you trying to upload a free file or a non-free file? Check your browser to see if you have any script blocking extensions (such as AdBlock or NoScript) that may be interfering. — xaosflux Talk 22:25, 6 November 2021 (UTC)
It appears to be a new problem, yes, ever since the JavaScript message was added. I'm trying to upload a non-free file on Chrome, and I've disabled most of my extensions including AdBlock. I've tried going incognito where none of my extensions are enabled, and I'm having the same problem. ‑‑Neveselbert (talk · contribs · email) 00:11, 7 November 2021 (UTC)
I can also see the "You do not have JavaScript enabled" message even though the buttons are clickable and files can be uploaded. – SD0001 (talk) 04:45, 7 November 2021 (UTC)
Till now it appears the message was always being shown to everyone (unless I'm missing something). I edited the page in Special:Diff/1053959909 to put it within {{noscript}}. @Neveselbert Can you check if you're still facing any issue? – SD0001 (talk) 04:48, 7 November 2021 (UTC)
@SD0001: I've checked, and I'm still stuck on the "Upload in process" page. The only difference now is that I no longer see the message. ‑‑Neveselbert (talk · contribs · email) 21:57, 8 November 2021 (UTC)
@Xaosflux: can you possibly rollback the edit request you implemented? I'm still unable to upload without the "Upload in process" page freezing. ‑‑Neveselbert (talk · contribs · email) 22:02, 8 November 2021 (UTC)
@Neveselbert: what type of file are you trying to upload? One of these recent changes was specific to mp3, the other should have only removed extra CSS. We certainly can rollback changes, just trying to target it as best as possible. — xaosflux Talk 22:53, 8 November 2021 (UTC)
If it's freezing, the likely explanation is that an error occurred in the javascript code, which prevents the rest of the code from running. @Neveselbert Please follow the steps at WP:JSERROR and let us know exactly what buttons are you pressing, and what errors can be seen in the browser console. – SD0001 (talk) 14:36, 9 November 2021 (UTC)
It's working now, I think this was my mistake, sorry. I deleted the file after dropping it but before uploading it to Wikipedia, which may have indeed caused the problem I've had. Thanks all, I'm sorry for any inconvenience. ‑‑Neveselbert (talk · contribs · email) 18:23, 9 November 2021 (UTC)
Sorry about that, the style rule was working, but the CSS was only being loaded when the button was clicked, which I failed to realise. The templatestyles implementation at {{noscript}} is much better. I am not sure how the addition of this message could have any affect on the ability to upload files though, as appears to be the case above? The wizard is clearly working. Dylsss(talk contribs) 23:11, 8 November 2021 (UTC)

Image upload not working!

For non-logged in user from Firefox on Mac, https://commons.wikimedia.org/wiki/Special:UploadWizard just gives 'Secure Connection Failed' — Preceding unsigned comment added by 103.59.74.173 (talk) 11:03, 19 December 2021 (UTC)

The Commons upload wizard and the Wikipedia one are different. You need to raise this at commons:Commons_talk:Upload. Nthep (talk) 16:51, 19 December 2021 (UTC)

Interface-protected edit request on 9 February 2022

@Xaosflux: I think you or I must have accidentally omitted one comma at line 1864, causing people to be unable to use the Wizard. The comma should be added after "oga" : "video/ogg" in order for the Wizard to work properly. --George Ho (talk) 21:40, 9 February 2022 (UTC) George Ho (talk) 21:40, 9 February 2022 (UTC)

@George Ho:  Done — xaosflux Talk 21:49, 9 February 2022 (UTC)

Add webP and webM as accepted formats

WebP and webM are open formats, but this Wizard hasn't yet accepted them. Someone else brought up webP last year. Similar to my request on adding mp3, for MediaWiki:FileUploadWizard.js, the following must be added: image/webp and video/webm for filebox.accept (line 103); webp and webm for name.replace (line 1819) and var extensions (line 1852). Both formats must be also listed as "Permitted file types". --George Ho (talk) 01:19, 8 February 2022 (UTC)

@George Ho: here are the lines you referenced (103, 1819, 1848-1864)
103
   filebox.accept = 'image/png,image/jpeg,image/gif,image/svg+xml,image/tiff,image/x-xcf,application/pdf,image/vnd.djvu,audio/ogg,video/ogg,audio/rtp-midi,audio/mp3';
1819-1827
   // common generic filename patterns: 
   // IMG......jpg
   // Image....jpg
   // DSC......jpg
   // Picture......jpg
   // Pic..........jpg
   // anything that has fewer than 3 alphabetic letters and then just numbers
   var pattern = /^(img|image|dsc|picture|pic)?(\\s*|\\_*|[a-z]{,3})?\\d+$/i;
   var auto = name.match(pattern);
1848-4864
   var mimetypes = {
      "png"  : "image/png",
      "gif"  : "image/gif",
      "jpg"  : "image/jpeg",
      "jpeg" : "image/jpeg",
      "xcf"  : "image/x-xcf",
      "pdf"  : "application/pdf",
      "mid"  : "audio/rtp-midi",
      "ogg"  : "audio/ogg",
      "mp3"	 : "audio/mp3",
      "ogv"  : "video/ogg",
      "svg"  : "image/svg+xml",
      "djvu" : "image/vnd.djvu",
      "tiff" : "image/tiff",
      "tif"  : "image/tiff",
      "oga"  : "video/ogg"
   };
 On hold I think at least one of your line numbers is wrong. I made a sandbox for you at User:George Ho/sandbox.js, please make the changes you are requesting there, then reactivate the edit request above when ready. — xaosflux Talk 14:19, 9 February 2022 (UTC)
@Xaosflux: Ready. Added webp and webm in my sandbox version. Please feel free to delete the .js page when you're done with this request. George Ho (talk) 21:04, 9 February 2022 (UTC)
 Doing... Reviewing. — xaosflux Talk 21:18, 9 February 2022 (UTC)
@George Ho: this is  Done and  Done, thank you! — xaosflux Talk 21:21, 9 February 2022 (UTC)

Update documentation

Disaster below averted; now the "webp" and "webm" should be listed amongst "Permitted file types" when opening the Wizard. --George Ho (talk) 21:54, 9 February 2022 (UTC)

 Done — xaosflux Talk 00:20, 10 February 2022 (UTC)

Non-free uploader not working in phones

Hello, the 'upload a non-free file' option is not working in smartphones. I clicked it multiple times from my smartphone, but nothing is happening. Just the page is reloading. Please fix this problem. ThePremiumBoy 09:03, 10 February 2022 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:File_upload_wizard/Archive_8&oldid=1130063371"