Adding design keyword, setting importance to low.

(Thank you to Okki to have reported this issue and suggest a solution.)

n.b., some of the title uniqueness and duplicate checks rely on the return value(s) of the initial uploads, so if the filename that is used on the describe step needs to be changed, we won't (necessarily) know until after the upload is done. This could be a problem, or it might be obviated by later calls to the server to check for uniqueness.

Plus plus also and, it could take some maneuvering to postpone the final upload API call until after the initial stash upload is finished.

Also, Dereckson, does your last comment mean that someone has already worked on this particular problem? Is there a patch ready, or some code available that I could help with?

(No, it meant the bug report is written from an Okki's suggestion on the IRC channel #wikipedia-fr. Alas, it means no patch/code ready.)

That's perfectly fine! I wonder if there are any relevant details in that conversation. If so, could you post some of the relevant information here? Maybe it could help us decide how to implement this, at least. I should be able to understand the French, so there's no need to translate (at least not for now).

Another potential problem, though: Since the uploads start automatically now, we might need to put a barrier between the upload step and the details anyway, to prevent putting the uploads in the background too quickly, before the user is finished adding files. Else, they might think that they should do one file at a time or something. I think the current mechanisms for copy-to-all-files vs. use-this-for-only-one-file should work pretty well for this purpose, though. This feature would simply not wait for the server's replay after the initial stash upload(s), and enable the "next" button from the start. That's easy enough to do, and might actually make our lives easier.

I'm adding in a separate issue that I can fix initially, then I can jump in to doing this. I may be doing this for several other things, because this bug is a very complex one.

OK, cool! It sort of works right now.

HOWEVER, there's a slight problem in that there appears to be a problem similar to bug 32469, except in (presumably) all browsers. This likely happens because I've totally changed the way uploading happens, and the error handling in the latter bits of the form don't like the idea of me meddling with the UWU class's innards.

In any case, this bug is now blocked by bug 32469, so that patch needs to be merged in before I can move further.

If you would like to test the current implementation, the patch is here: https://gerrit.wikimedia.org/r/11004

• Bug 39051 has been marked as a duplicate of this bug. ***

I am actually against this, what if I uploaded 10 files, moved on to enter descriptions and later only realized that the uploads all failed. My efforts in writing descriptions is wasted right?

Maybe that's why in most websites I always have to wait for the upload first. Of course you can open up a new tab and continue something else while its uploading ;)

Good software should not fail and if it does (e.g. for reasons the software can't control or fix), you could offer either trying another file or saving the file description page without uploading a file so the user can ask at HelpDesk why their file failed and upload them later. Just an idea.

(In reply to comment #9)

I am actually against this, what if I uploaded 10 files, moved on to enter
descriptions and later only realized that the uploads all failed. My efforts
in writing descriptions is wasted right?

I've seen high-resolution photos being uploaded by hand on a 128kbps uplink (this was before UploadWizard and I saved uploader's life by showing them how to use Commonist). A whole night process requiring constant operator attention? No, thank you.

Metadata and large content can and actually are handled pretty separately. It belongs to the error handling and transaction management what happens if one of those processes fails (upload can fail too). Ideally all those situations should be recoverable, even if - for example - binary uploads failed but the metadata are fine.

Change 11004 had a related patch set uploaded by MarkTraceur:
(bug 37462) Allow "next" without completing all uploads

https://gerrit.wikimedia.org/r/11004

Change 11004 abandoned by MarkTraceur:
Allow "next" without completing all uploads

Reason:
I don't think this is how we want to do this. Will return to the issue later with a different approach.

https://gerrit.wikimedia.org/r/11004

This will probably wind up being a pretty large refactor and UX improvement effort, requiring more of our time than we currently have to give.