Commons:Village pump/Technical/Archive/2019/09

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

mysterious alphabetising?

Greetings - I can't figure out why "Cimitero comunale di Condera‎ (19 F)" is alphabetised under "R" in the Commons Category:Cemeteries in Italy by city . I edited in a DEFAULTSORT template, but it still goes under "R". (Is it because of its location in Reggio Calabria? I can't see what template or instruction might be causing this.)

Seauton (talk) 23:35, 4 September 2019 (UTC)

Fixed See Special:Diff/364664668. 4nn1l2 (talk) 01:48, 5 September 2019 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Roy17 (talk) 23:23, 10 September 2019 (UTC)

At English something weird appeared to me on files using this template:

"Template loop detected: Template:Autotranslate <includeonly></includeonly>"

In Pt is okay, for example.

Could you pleas check it out? -- Rodrigo Tetsuo Argenton m 05:41, 16 September 2019 (UTC)

Fixed Special:Diff/366174676. 4nn1l2 (talk) 05:55, 16 September 2019 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 05:55, 16 September 2019 (UTC)

Challenge speedy deletion button

Clicking the button gives a form to start the DR. If, at this point, you decide not to proceed and cancel, the DR is not created, but the SD tag is removed from the file - or at least that's what happened for me when I mis-clicked the button and cancelled. Is this desired behaviour? I would have assumed that cancelling would leave the SD tag in place, and I worry this could lead to "accidental" tag removals. -- Begoon 08:38, 11 September 2019 (UTC)

Pinging @Perhelion.   — Jeff G. please ping or talk to me 08:52, 11 September 2019 (UTC)
This is indeed not an expected behavior. But this was always present for admins in this way. I'll look for a fix. Thanks for ping. -- User: Perhelion 13:46, 11 September 2019 (UTC)
Fixed -- User: Perhelion 14:12, 11 September 2019 (UTC)
Thank you for fixing that so quickly. It now works as I would have expected. When I tested 'cancelling' again I did need to refresh the page afterwards for the 'challenge' button to reappear on the page, but that doesn't seem particularly important. -- Begoon 23:38, 11 September 2019 (UTC)
@Perhelion: there seems to be something wrong now. I saw that some files still retained the nxd notices, so I just tested two. Both times I was stuck at Notifying Username... and the npd notices were not removed: File:برج الساعة مكة.jpg File:جامعة عفت1W9318.jpg.--Roy17 (talk) 16:03, 30 September 2019 (UTC)
✓ Done ups* Thanks for ping. -- User: Perhelion 17:07, 1 October 2019 (UTC)
This section was archived on a request by: -- User: Perhelion 17:08, 1 October 2019 (UTC)

09:07, 4 September 2019 (UTC)

Subcategories not alphabetized by person's surname

For example, in Category:Female poets. Over time I've spot-checked and edited to manually add the DEFAULTSORT template with surname-comma-given name, but this is time-consuming and erratic. I don't understand why some subcategories are automatically alphabetized by their surname. Does it have to do with the Wikidata Infobox template? Can a bot take care of it? I should think this would be systematic, whether or not automated. How can I effectively intervene? -- Deborahjay (talk) 10:06, 3 September 2019 (UTC)

@Deborahjay: {{Wikidata Infobox}} will automatically set the DEFAULTSORT if family name (P734) and given name (P735) are set in the corresponding Wikidata item, otherwise it adds them to Category:Uses of Wikidata Infobox with no family name and Category:Uses of Wikidata Infobox with no given name accordingly. There's quite a backlog of categories without the infobox (i.e., without matched Wikidata items), and Wikidata items without those properties set, though. Thanks. Mike Peel (talk) 17:42, 3 September 2019 (UTC)
@Mike Peel: , I'm delighted to discover this - because it's exactly the sort of task I enjoy undertaking, and as a multilingual, multicultural former museum archivist, speed typist and professional proofreader, I can be counted on to do it well. Many thanks for steering me this way! -- Deborahjay (talk) 18:12, 4 September 2019 (UTC)
@Deborahjay: That's fantastic, have fun! You may also be interested in having a look at d:Wikidata:WikiProject Names. :-) Thanks. Mike Peel (talk) 19:19, 4 September 2019 (UTC)
@Mike Peel: it's really valuable that you so quickly got me connected with that Wikidata project, as I'd already created two items whose native label (Hebrew) spellings differ but with identical romanized transcription - and according to the guidelines I read on the project, I have to tweak them to conform with standards. Besides my experience with the vagaries of Hebrew romanization, my museum archival work dealt with Holocaust content, so I learned to identify many versions of names that appear in that population base (including in Cyrillic and the Yiddish variant of the Hebrew alphabet). Head's up also to @Ijon: to show how I can turn the corner with manual DEFAULTSORT fixes and do the work at the item level in Wikidata, as well I might. -- Deborahjay (talk) 19:46, 4 September 2019 (UTC)
Great! :) Ijon (talk) 23:59, 5 September 2019 (UTC)

17:42, 9 September 2019 (UTC)

17:43, 9 September 2019 (UTC)

17:49, 9 September 2019 (UTC)

Can anyone help to put Template:The Stand News into machine-readable license

Can anyone help to put Template:The Stand News into machine-readable license? The administer mention if nobody done it, all the files will be delete. I don't know how to use it and hope someone can help.--Wpcpey (talk) 16:14, 14 September 2019 (UTC)

Yes, I am not involving myself further in this undeletion, but it's important that at least the files are no longer in Category:Files_with_no_machine-readable_license, because this is our only way to detect files without a license and this category has to be monitored file by file on a regular base, so that it is highly disruptive to this maintenance job if these files are cluthering this problem category permanently. So anybody with knowledge of template coding, your help will be appreciated. Jcb (talk) 16:25, 14 September 2019 (UTC)
  • I did sniff around the code some, then checked the successive DR discussions, and… decided to leave this aside, though regretting: I am convinced that whoever will cause this template to keep files transcluding it off the mentioned maintenance cat — will find themselves on the fast lane to block town. -- Tuválkin 18:27, 14 September 2019 (UTC)

✓ Resolved by Roy17. Jcb (talk) 20:40, 14 September 2019 (UTC)

15:07, 16 September 2019 (UTC)

No preview for this PDF?

File:广东省安全生产委员会办公室转发国务院安委会办公室关于实施遏制重特大事故工作指南构建双预防机制的意见的通知.pdf. A buggy file, or a bug in mediawiki?--Roy17 (talk) 23:23, 10 September 2019 (UTC)

Also, the 81 PDFs uploaded on September 16 to Category:Finlands Allmänna Tidning 1878 have no previews. --LA2 (talk) 23:26, 17 September 2019 (UTC)

Video player regression in Safari 13.0

If you've just installed Safari 13.0, beware that the first video playback attempt on each page view may stall; closing the video popup and playing a second time works.

I have a fix in the works, but as it's late in the week it may or may not get applied immediately.

Note that you can enable the "new video player" in beta features which does not encounter the same bug. --Brion Vibber (WMF) (talk) 21:13, 19 September 2019 (UTC)

Unable to move categories

Whenever I go to click on "Move", my action gets immediately throttled, with the default message displayed, despite my last move having been more than a month ago, not a few minutes ago. What's going on here, exactly? – PhilipTerryGraham (talk) 03:34, 19 September 2019 (UTC)

Hi, I am having the same problem. My last move was 2 days ago. --LamBoet (talk) 04:07, 19 September 2019 (UTC)
Yes, I was able to move one too, it seems to be gone. --LamBoet (talk) 15:18, 20 September 2019 (UTC)
It was fixed in phab:T233308, and deployed here yesterday Sept. 19. – Ammarpad (talk) 21:26, 20 September 2019 (UTC)

Closing the mediaplayer doesnt stop playing?

Try Category:License_review_needed_(video) for example. Dont click into the file but simply open the player on the cat page. Then close it. It is still playing in the background. Is this happening for you? I use firefox win10.--Roy17 (talk) 20:59, 15 September 2019 (UTC)

As I tried today, this doesnt happen to Opera, so it could be firefox's bug, or the player is not compatible with firefox.--Roy17 (talk) 21:55, 23 September 2019 (UTC)

JFIF files

I'd like to ask how JFIF is best handled on Commons. Do we convert them to jpeg? (Hopefully your advice will be summarised into a page help:jfif so that future users wont need to ask again.)

The specific issue that troubles me, is how to extract a best possible copy of File:明治時代の万世橋駅 .png from http://dl.ndl.go.jp/info:ndljp/pid/762376/42 . If you figure out a way better than its jfif previews, please go ahead and use that method.--Roy17 (talk) 19:33, 20 September 2019 (UTC)

@Roy17: I extracted File:明治時代の万世橋駅.jpg from the PDF. Let me know if the PDF download doesn't work for you. - Alexis Jazz ping plz 19:53, 20 September 2019 (UTC)
Oops.. The preview is better than the PDF. Sorry. - Alexis Jazz ping plz 19:54, 20 September 2019 (UTC)
@Roy17: JFIF is just a kind of JPEG file (Exif being the other common one). So there's no conversion to be done: just upload them with a ".jpg" or ".jpeg" extension. --bjh21 (talk) 22:05, 20 September 2019 (UTC)
@Bjh21: thx for the tip! But I just wanna play safe. Do you mean that the file extension could be simply changed without any technical problems?--Roy17 (talk) 21:29, 21 September 2019 (UTC)
@Roy17: Yes. I could be wrong, but at worst we'll find out how Commons fails to handle these files. --bjh21 (talk) 12:45, 23 September 2019 (UTC)
Thx a lot! But strangely the library website exported a jpg this time when I tried again today...--Roy17 (talk) 21:55, 23 September 2019 (UTC)

20:20, 23 September 2019 (UTC)

Deleting an inferior duplicate of a different extension

It's quite common to find cases in which a worse version had been uploaded before a good one with another extension (for example a gif/png downsized thumb from the net). If the worse one is to be deleted, should the original filename in say PNG be redirected to the JPG? Or should users simply replace all global usage and then delete without leaving redirects?--Roy17 (talk) 21:55, 23 September 2019 (UTC)

"You are trying to add a OTRS permission tag ..."

Hi! I noticed this file has a dupe otrs permission template. (template otrs is a redirect to template PermissionOTRS) So I set out to remove it as it looks silly to have the otrs box twice. But!

1) First, there was a broken error massage at the top of the page. It read

Error: {| style="width:90%; margin:0 auto; background:#fff8f0; border:1px solid #b22; border-left-width:10px;" | style="width:52px; padding:2px 0 2px 0.5em; text-align:center;" class="com-mobile-handheld-hidden" | Wikimedia OTRS logo.svg | style="color:black;" | Warning You are trying to add a OTRS permission tag to this page. In general, such tags should only be added by OTRS members. You should not add such tag unless explicitely instructed to do so by the OTRS member. You may press "Save page" again if you like to save this edit. If you do so, your edit will be tagged for review. In case you aren't sure if your edit is okay, it's best to ask for help, on the OTRS Noticeboard. |}

I.e. that's the text I see on the wiki page, not some source view mode. It kinda looks like [25] But not exactly.

2) The text tells me to press again the save button. However that leads back to the very same page again... Is this because of some cookies silliness? -2001:14BA:984A:F200:0:0:0:8EA 20:32, 24 September 2019 (UTC)

Center appearance problem

Templates like Template:Vote archive and Template:Mbox are not appearing properly as they are supposed to be centered. 1989 (talk) 04:43, 19 September 2019 (UTC)

That was a side-effect of a change introduced a few days ago. We're tackling it in phab:T233359 --Volker E. (WMF) (talk) 03:13, 20 September 2019 (UTC)

Coming soon: FileExporter default on first wikis, making imports to Wikimedia Commons easier

The FileExporter and FileImporter extensions make moving files from a local wiki to Wikimedia Commons easier. Together they allow to move files with all their original data intact, while documenting the move in the version history. The feature originates in a top wish from the Technical Wishes survey on German Wikipedia.

The FileExporter, which lives on the local wiki, has been a beta feature on first wikis since June 2018, and on all wikis since January 2019. Currently, 15,000 people on the Wikimedia projects have activated the feature, and more than 12,000 files were imported successfully with this new tool. The first version from June 2018 was improved continuously, based on feedback by its beta testers. Thanks to everyone who gave feedback!

Now, the FileExporter will become a default feature on the first few wikis: de, fa, mr, ko Wikipedias and on the Wikisource for multilingual books (so called sourceswiki). This means that as an auto-confirmed user on these wikis, you'll see a link “Export to Wikimedia Commons” on local file pages. If you click on this link, the FileImporter then checks if the file can in fact be moved to Commons, and whether any replacements need to be made. These checks are performed based on the wiki’s configuration file which is defined by the local community.

The planned date for this deployment is September 24th, 2019. Deployment on more wikis is planned for later this year. As always, feedback on this feature is very welcome on this talk page. -- Best, Johanna Strodt (WMDE) (talk) 08:57, 23 September 2019 (UTC)

16:49, 30 September 2019 (UTC)

Hello, the FileExporter/FileImporter extensions make it easier to import files to Commons in a technically correct way. It was discussed on MediaWiki and Phabricator (T222445) how these two extensions should deal with files from wikis that have a high amount of copyright violations.

In the discussion, three ideas were suggested:

  1. Disable the FileExporter button "Export to Wikimedia Commons" for all users on a certain project.
  2. Show the button only to users with certain rights. (T232480)
  3. Make it easier for the Commons community to identify from which wiki imported files came. (T232481)

Disabling the export feature for all users on a project would mean that no Commons-compatible files could be transferred from there either, which is why the team behind the FileExporter/FileImporter would refrain from doing this. But the team can investigate if options 2 and 3 are doable. Could you please discuss which of these changes are wanted, and which aspects should be considered if these changes were implemented? -- Thanks a lot, Johanna Strodt (WMDE) (talk) 10:35, 13 September 2019 (UTC)

I have an idea that requires no technical changes. Steps:
  1. Require all wikis that want to opt in to apply for an inspection from Commons volunteers. Commons vote on applications.
  2. Those that pass the inspection, can have their setup pages at mw:Extension:FileImporter/Data unprotected.
  3. Lock up setup pages (sysop-create-and-edit only) for all wikis that have failed or not applied. Make everything bad and nothing good on the setup pages.
Criteria for pass would be: 1. local users check newly uploaded files regularly. 2. bad files are deleted in time regularly. 3. the effort does not rely on very few users, i.e. even if someone becomes inactive the work is still carried on smoothly.
This does not prevent them from manually transferring or using commonshelper though.--Roy17 (talk) 22:54, 13 September 2019 (UTC)
If it's preferrable to have a review process for imported files, I suppose it's not difficult to make the gadget automatically add {{BotMoveToCommons}} or something similar, which adds files into maintenance cats.--Roy17 (talk) 23:03, 13 September 2019 (UTC)
I add a coment abut this issue at mw:Topic:V3ytxmfmk93xu7lg. In general, I do think that FileImporter is a good idea but need some modification.
  • One of the issues I have mentioned there raised in MediaWiki talk:Gadget-AjaxQuickDelete.js#Notifying File Importers by Jeff G. and solved by Perhelion. I have also mentioned there a solution to #3. I do agree that some kind of template that gives the all the info saye something like: "This file was moved to Commons in DD/MM/YYYY by user:XYZ using FileImporter from en:File:ZZZZZ.jpg" or "This file originally uploaded to XX.wiki. It was moved to Commons in DD/MM/YYYY by user:XYZ using FileImporter from en:File:ZZZZZ.jpg". This at least, setting somehow the info about the history of uploading and importing of the file which is missing. I have created a basic template for my own imports (see File:Shlomo lorentz.jpeg). Also, the situation where the file was allegedly uploaded by an active user in Commons is simply not correct. The local wiki user must be linked to his local account.
  • I agree with #2: specify certain user-rights which users on certain wikis need to have in order to use the extension to move files to Wikimedia Commons.
  • Not sure about #1. Normally should be decition by Commons (Community-consensus) but problems of bad moves can be solved in other ways like limiting user rights (#2). -- Geagea (talk) 23:56, 13 September 2019 (UTC)
See also COM:VPP#Show the FileExporter's "Export to Wikimedia Commons" button only to users on other wikis with certain rights and COM:VPP#Make it easier for the Commons community to identify from which wiki FileExporter file transfers are coming using a template which applies maintenance categories.   — Jeff G. please ping or talk to me 12:31, 11 October 2019 (UTC)

I am inclined to disagree with option #1 (number one) because the fact that a person has acquired more user rights doesn't signify that they have more knowledge, and most certainly doesn't mean that they have more knowledge of copyrights and copyrighted materials. Also having a knowledge of how copyright works on a Wikipedia doesn't mean that they will understand “Commons:Licensing”, some Wikipedia's will basically accept anything (image-wise) because of fair use, which is great… for Wikipedia, but not for Wikimedia Commons, Wikimedia Commons is designed for absolutely free files (or at least free enough to re-use in any context), on the other hand limiting more users from transferring files isn't good. It should be easier to import files to Wikimedia Commons, but it should also be more easy to patrol these imported files. The Community TechBot should probably add daily or weekly galleries of new uploads PER WIKI so it’s easier to patrol what's coming in.

Also I often see good high quality own works on the Japanese- and Vietnamese-language Wikipedia's and would prefer to see those files imported to Wikimedia Commons, it's best to not limit users, it's odd but over the years I've seen a culture rise that is more centred around preventing content creation for the sake of "preventing" things (copyright violations, backlog, non-notable subjects, Etc.), it would be better to create more tools and options to patrol things, rather than trying to limit the people who can contribute, it's better to increase the tools and options for those patrolling the new content. The benefits always outweigh the risks. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:47, 11 October 2019 (UTC)

The "Show contributions of new accounts only" checkbox filter no longer appears on Special:NewFiles. Is this just for me, or has it been removed? Is there a way to restore it? (The "Newbies" button, which links to a wmflabs tool, remains, but is inferior to the new files gallery.) Эlcobbola talk 19:07, 4 September 2019 (UTC)

@Эlcobbola: It appears to have been removed. :(   — Jeff G. please ping or talk to me 19:23, 4 September 2019 (UTC)
[ec] @Elcobbola: It was removed for performance reasons, sorry. See m:Tech/News/2019/34 (posted a few sections up at #Tech_News:_2019-34). Using the "newcomers" and "learners" filters on Recent Changes for new File: creations will probably help (but doesn't show the thumbnail of the file, which is not quite as useful). Jdforrester (WMF) (talk) 19:26, 4 September 2019 (UTC)
Well, that was a bad idea. Copyright violations will be hanging around a lot longer unless there is a tool to replace this functionality. World's Lamest Critic (talk) 20:21, 4 September 2019 (UTC)
@World's Lamest Critic: As elcobbola mentioned, there is already a community-supported Toolforge tool which, unlike the removed functionality, doesn't take the site down. Jdforrester (WMF) (talk) 21:05, 4 September 2019 (UTC)
Can you supply any examples of when that functionality "took the site down"? World's Lamest Critic (talk) 21:12, 4 September 2019 (UTC)
@Jdforrester (WMF): Thank you for the response, but is there anything to be done about this? I find "The secondary feature is rarely used, complicates the code, and massively complicates the user experience" [28] untrue ("Massively complicates the user experience" Really?) Being able to see images unloaded by new accounts is how I detect well over 90% of sockpuppets, which is a lot. And, I believe echoing per World's Lamest Critic above, I understand this actually to be a very commonly used method of copyvio detection ("The secondary feature is rarely used" Where are data on this? Rare relative to what?) Now, without a corresponding throttling of "established user" uploads (which I don't advocate), "newbie files" will disappear among the constant and voluminous bulk/script uploads. This seems an incredibly short-sighted and ill-informed change, especially without ensuring the existence of a reasonable alternative before the discontinuation. Эlcobbola talk 20:37, 4 September 2019 (UTC)
@Elcobbola: Fair questions.
I made the determination from roughly eyeballing the request data; it was about 100000:1 (as in, I could barely find any uses of /newbies in the logs I briefly looked at).
I don't understand your comment about established users? The link I gave you for Recent Changes explicitly excludes them, as does the tool to which you linked (which is much more powerful in terms of setting arbitrary limits on what counts to you as a "newbie").
The core tool was removed because it kept breaking the site, and had no reasonable path to performance improvements that would make it stable enough to retain. In general, power tools support is carried out by the wonderful Community Tech team based on the community voting exercise each year (next time starting in a few months' time). However, even if it "won" a vote, that wouldn't get you a fix for many months. I'm not sure what path for solution I can offer, sorry.
Jdforrester (WMF) (talk) 21:05, 4 September 2019 (UTC)
@Jdforrester (WMF): You keep saying it "broke the site" but hasn't this functionality been around for years? Did something change to make it no longer acceptably efficient? And, as I asked above, can you give us some examples of when it "broke the site"? World's Lamest Critic (talk) 21:29, 4 September 2019 (UTC)
@Jdforrester (WMF): As you noted, the recent changes link does not show the thumbnail of the file, which is the critical functionality (i.e., it is necessary to see the image to assess whether it is a recreation, has the traditional hallmarks of a copyvio, etc.); the newbies tool is, among others, a) based on edits, not account age; b) does not include resolution data; c) has smaller images (making visual judgments more difficult); d) is not in a gallery format (less dense, thus more cumbersome to use); and e) is on tools.wmflabs.org which, in my experience has been very unreliable in terms of both performance and availability, at least relative to proper project space. If the tool was poorly coded (I know nothing of code; I'm reading between the lines of the issues you seem to be having with it), why is the solution not to code it properly? I have a hard time believing a gallery of new files uploaded by accounts aged less than a week (or whatever time is deemed appropriate) would be difficult to create and to make stable based on functionality that exists and remains. How, for example, is the "Show uploads by bots," which remains, significantly different? If reliant on an account flag, couldn't the code just do the inverse--exclude all accounts that are autoconfirmed (automatically granted at 4 days) and implicit members of autoconfirmed users? Эlcobbola talk 21:35, 4 September 2019 (UTC)
@Elcobbola: Details given by the Performance team at https://phabricator.wikimedia.org/T220447#5388610 as to the ways in which as a function it was unworkable (short version: the databases aren't designed for this kind of query, and we can't reshape them to make this one performant without breaking the performance everything else).
Adding a gallery view mode to Recent Changes is theoretically do-able but I don't think it's likely to work out well. I'm not sure whether Steinsplitter is actively maintaining the tool to which you linked; I suppose they could extend it to add a gallery view mode, and I'd be happy to help them in that.
Bot-flagged edits are encoded individually into the database so that we can do row-level operations against them, in a way that we cannot for account's relative "age". User flags/age/block status changes over time, but whether or not an edit/upload/etc. was bot-flagged is stored permanently and cannot be altered.
Jdforrester (WMF) (talk) 21:47, 4 September 2019 (UTC)
@Jdforrester (WMF): I wrote a dissertation on a manual typewriter, which tells you something of my vintage and familiarity with this stuff. That said, overgeneralising for what I am able to understand, is my understanding generally correct that the issue boils down as such: because NewFiles goes "to the beginning of time," asking it to sort out new users from established users for millions of files over more than a decade is too burdensome of a query (i.e., causes slowdown and/or timeout errors, etc.)? If so, given that there exist and remain a from and to date field (i.e., date limiting functionally is implemented), could the "Show contributions of new accounts only" option be made to tie into that and just force a, say, 30-day look back? Эlcobbola talk 22:10, 4 September 2019 (UTC)
@Jdforrester (WMF): Thanks for the link. The task description doesn't mention performance and is based on the incorrect assumption that the functionality was seldom used. It appears your contention that it "breaks the site" is bullshit unsupported by the evidence. Please rethink this change. I'm sure if you asked people about how they use it, you can find a way to do it more efficiently. World's Lamest Critic (talk) 22:15, 4 September 2019 (UTC)

@Jdforrester (WMF): Nthep made a comment on Phabricator that seems to have been ignored. They told you the same thing we are telling you now. Why didn't you pay attention to that comment? World's Lamest Critic (talk) 22:21, 4 September 2019 (UTC)

@Jdforrester (WMF): It's been about a week now. Are you coming back to discuss this? World's Lamest Critic (talk) 22:17, 11 September 2019 (UTC)
@World's Lamest Critic: Sorry, discuss what? I responded carefully, and you swore at me and made statements that were totally inaccurate which showed that continuing wasn't productive. What more is there to say? Jdforrester (WMF) (talk) 15:09, 2 October 2019 (UTC)
@Jdforrester (WMF): I neither swore at you nor do I believe I made any inaccurate statements. If you believe I did, you are welcome to point them out, but I don't think that will solve the problem we are discussing here. This change has removed functionality that facilitates detection of copyright violations, uploads of revenge porn, and uploads of child porn. You were alerted to this prior to the making the change but ignored the warning. It seems likely that any performance issues can be mitigated as elcobbola suggested above. That would seem to be a win-win solution. If the Newfiles search was limited to 30 days, would that solve the performance issue? World's Lamest Critic (talk) 19:49, 3 October 2019 (UTC)
@Jdforrester (WMF): A week has gone by with no response. I can only assume you had no real intention of working with the community to address this. World's Lamest Critic (talk) 17:13, 10 October 2019 (UTC)
 Info use this link to get a list of unpatrolled uploads by new users. MorganKevinJ(talk) 02:47, 19 October 2019 (UTC)

I will no longer be looking for copyvios or child porn

@Jdforrester (WMF): @Elcobbola: It's been over two weeks now since you stopped participating in this discussion, leaving unanswered questions and abandoning what seemed like a promising proposal from elcobbola to alter Special:Newfiles to mitigate any performance issues. The "newbies" tool mentioned above does not provide the same functionality. OgreBot's galleries of uploads by new users is very useful, but still "a work in progress". Since you seem to have no desire to help me help the project (even to the point of responding to questions) I am no longer going to look for copyright violations or license issues in new uploads. That means I probably won't notice child porn uploads either (yes, I have found and reported a few in my short time here). I doubt this will make much of a difference to you, but it will make a difference to the project and it is the direct result of your decision. World's Lamest Critic (talk) 16:51, 23 September 2019 (UTC)
Yeah, hopefully computers will do that job in the near future and we have just to undelete misidentified stuff. @Jdforrester (WMF): what are the plans on that? -- Rillke(q?) 00:46, 3 November 2019 (UTC)
What a shit show. - Alexis Jazz ping plz 20:13, 19 November 2019 (UTC)

https://tools.wmflabs.org/newbie-uploads/ written on Toolforge by Steinsplitter in 2016 has been linked from where the checkbox used to be. EllenCT (talk) 08:54, 20 November 2019 (UTC)