your screenshot of your button assumes a large wide screen.
here is a small screen version

In T270911#6713999, @Reedy wrote:

Is there much work to migrate from GWToolset to Pattypan?

It feels like one of those if there's not, and no real objections to doing so... When we have agreement from the Commons community at large, make sure the right people are notified, and then set a deadline of turning it off in maybe 2-3 months (ie end of Feb or March)?

you could always run through pattypan that bypasses the upload wizard. and you can put a credit line and custom attribution template "we really really mean it is not cc0

rather than restricting importing, or stopping all imports, you should elevate potential problems, and put on a maintenance category. i.e. https://commons.wikimedia.org/wiki/Category:Image_overwrites_by_Jan_Arkesteijn_for_independent_review
(data searches are fine but undecipherable to some community members)

upload wizard needs a UX redesign, and workshop. layers of metadata entry are a barrier to entry, mixed licensing, done for historical reasons, are confusing to the naive.

this is not a duplicate of T250877 Visual editing interface for tabular data on Commons.
a visual editing interface could edit JSON data like cells in a spreadsheet as VE does. but that is a down select you have made.

In T222445#5175417, @Pikne wrote:

Blacklisting a Wikimedia project doesn't seem right to me as long as Wikimedia Commons is supposed to be a shared file repository for all Wikimedia projects. Also it'd be still possible to move files to Commons, by disallowing FileExporter you'd only impede copying file history properly.

Based on current comments it's rather unclear what is the actual scale of this problem with file exports on Arabic Wikipedia and if FileExporter has significant effect on it. Three examples of deleted files above in fact were moved before FileImporter/FileExporter were enabled. If export link should be available based on user group then do we actually know that problematic moves are (mostly) by users outside of these selected user groups?

If root of this problem is that particular projects are lax on copyright then proper solution in my opinion would be that these projects tackle this actual problem. For instance they could mark all files or files with some problematic licenses for individual review. (Then similar to Bild-PD-Schöpfungshöhe template on de.wikipedia "NoCommons" tag would block the import until particular file is reviewed as suitable move to Commons candidate.) Then maybe you could also disable FileExporter (hopefully as a temporary solution) and instead of tab link make the export link available in review tag after positive review of particular file.

As for categorizing all imported files as "unchecked" or "requiring review" per project, it's unclear to me what would be the purpose. Bots and some older tools used BotMoveToCommons tag (includes a tracking category) as bot moves may not have been reviewed during file transfer or because tools allowed limited editing of wikitext and then further cleanup was needed after transfer. This is not the case for FileImporter that asks users to "check the page in detail before importing" and allows cleaning up everything during import. So far there have been no particular review procedure and everyone have been able to check their own file transfers. So I don't see a point for submitting all files for rereview, at least not without developing a clear review procedure beforehand.

you also might want to consider cases like artwork and photograph template, where there is an artist, or photographer, and not author.

in addition, the "page body" field seems to have a limited size with a scroll bar, and the "Footer" field seems to expand to fill page even when empty

here is another example "Handbook of Nature Study."
https://tools.wmflabs.org/ia-upload/log/handbookofnature00coms_0
https://archive.org/details/handbookofnature00coms_0

yes, in addition some books are getting bounced at IAuploader for this reason (until IA starts converting to dejavu again)

here is some metadata cleanup that could have been avoided had this been implemented sooner

i think it is great that you know enough to file a "will not fix"
i guess i will stop making what little metadata cleanup i was doing by hand,
steering newbies to a cul-de-sac that creates more backlog is not isolated to this process.
i'm sure you will have a solution for this metadata debt in you own time.

yeah i understand if you have never tried to clean the metadata mess at commons, you would not see the point to the task.
the workaround currently is to use pattypan and not use upload wizard.
it takes some expertise to know not to use the tool, that does not support linking to wikidata.

i could save edits with index. fields did not load
additionally, in page space, header and footer field did not appear, but "noinclude" wikicode was shown, buttons to edit page status did not appear, but "pagestatus" wikicode did

at wikimania 2017 at the fundraising panel
the fundraising team admitted that there was negative feedback from readers concerned that the bad translations were a sign wikipedia was failing.
https://wikimania2017.wikimedia.org/wiki/Submissions/Fundraising_messaging_that_moves_our_readers:_What_we%E2%80%99ve_learned_from_testing_thousands_of_fundraising_appeals
perhaps the negative brand impact would motivate some consensus at WMF to develop a translation standard of practice?

keep in mind WMF is breaking scripts at each code deployment
leaving a train of grumpy power users

comment - it is important to have good usage metrics to show our GLAM partners. a systemic under-count of views transcluded from wikidata is sad

there is no clear consensus for this interpretation of PDM.

would suggest option for wikidata infoboxes where available
for example
https://en.wikipedia.org/wiki/Template:Infobox_person/Wikidata
and
https://fr.wikipedia.org/wiki/Mod%C3%A8le:Infobox_Biographie2

i'm not using upload wizard, and until the feature enabled, not using special:upload either

you need a process and team to add citations, not merely grow the "citation needed" backlog.

you can replicate the error

hi, yes my screenshot was trying to edit this article insert > pages on the WS VE menu

when trying to insert > pages get a 404 error ;' trying to switch to code hangs.
when refresshing and repeating it saves properly. on chrome browser

this is a problem, for example the article
https://en.wikipedia.org/wiki/Harriet_Tubman
displays a map prominently, not all the other images of the article subject.

i noted some buggy interaction for the insert > pages, initially rather than subsequenly editing pages template https://www.mediawiki.org/wiki/VisualEditor/Feedback

ok i have uploaded this 69.29 MB volume using metadata from IA uploader and uploading using chunked uploads.
https://commons.wikimedia.org/w/index.php?title=File:1977_Books_and_Pamphlets_July-Dec.djvu
could someone please incorporate chunked upload functionality into IA uploader?

this is a problem for uploading books
with IA moving away from dejavu the bloated jpegs will be larger
important copyright information is unworkable
https://commons.wikimedia.org/wiki/File:Upload_file_too_large.png

works well in chrome and firefox. saved first new article.

it could work as echo or bot message to user talk or email
opt in via education sign up or event signup

there seem to be 69000 articles with bare urls
https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=insource%3A%2F%5C%3Cref%5C%3Ehtt%28p%7Cps%29%5C%3A%2F&fulltext=Search

please add wikisource to the list

In T59308#1851298, @Tgr wrote:

@Slowking4 I don't believe we have that kind of metadata. There is Author from the Information template, and not much else.

creator is noted with metadata, but not noted "creator" or "artist" unlike "uploader" on right hand side
it would be nice to call out field name

i would agree with Pete. historically assumption was that uploader was creator, but this is increasingly not the case, and uploader may be bot. and many uploaders are long gone. only rarely do readers question my uploads

is it in compliance with EU Cookie Law?
https://econsultancy.com/blog/63118-17-useful-examples-of-eu-cookie-law-compliance/

thanks, sorry if off topic.
got here from
https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-HotCat.js
will post that other thread there

the look & feel appears different in commons:
when type in the text box, the auto fill does not appear in the drop down box,
until i click away from the text box
when i save when an auto fill is in drop down box
it does not save the first auto fill suggestion, but the text in the text box

have you recently changed hotcat?
i noticed different repsonses:
it is not changing lowercase to upper case, but requires a click on the drop down suggestion
it is not filling in suggestion consistently, but the drop down is blank, requiring typing in the whole category

+1 MZMcBride
a culture problem will not be solved with cookies.
you are just escalating wack a mole

the previous throttling had adverse impact on uninvolved newbies.
will cookies work against a browser change, or public machine restart?
we just had a determined sock who routinely overcame auto-confirmed.
any reason to believe this solution would work for them.
or is it merely a speed bump for the easily detectable?

i agree, but counseling not biting to new page patrolers is falling on deaf ears. hard to get engagement in a broken process. better to fix process by incorporating feedback.

the account creation throttle is a major headache at editathons.
not every technical solution to vandalism should be done, if it adversely affects newbies. i.e. first do no harm
consider improving algorithm https://wikimania2015.wikimedia.org/wiki/Submissions/Wikipedia%27s_health:_A_socio-technical_overview