Adding @Prtksxna & @nayoub, so you're aware of this ticket. No action required at this time, unless you have questions or concerns to voice, of course.

I have provided a brief description of how this ticket has evolved in the description above. Happy to discuss it in more detail with either of you, if you have any questions. Thank you!

@Samwilson Keep in mind that this is an "investigation" and no actual "code" is required.
Writing down what we discussed yesterday plus whatever you find regarding what error messages are worth handling (or not) is good enough. We'll create some tasks out of this and size them in our next estimation.

A few notes from what we talked about in the Engineering meeting the other day:

• Without a job queue there's no easy way to get error (or progress, or success) messages displayed in the popup.
• The alternative is how it works now: in case of an error the user is taken to the export form and an error notice box is displayed at the top.
• This error box can be improved in a few ways:
  1. Translate the error messages.
  2. Provide a backlink to the page the user has just come from.
  3. Handle all errors that we can in the error-above-form display, rather than the generic white-page 500 error page (at the moment we only show Request and Http errors this way).
  4. Some errors, notably timeout ones now that we have caching enabled, can go away on a second try; tell the user this.
  5. Add better (non-retry) errors for books we know will just keep failing — e.g. T222690: Wikisource Exports: Show useful error if more than N subpages are found
  6. Add a link to a wiki page where we describe the different types of common error.
  7. Some sorts of errors are from wikitext or template/module problems, and we can help editors fix these (e.g. highlighting epubcheck validation errors; this is probably not something we'd want to do on every error though, but only on request, e.g. via a new options checkbox).

There are some error messages that are very unlikely to be displayed to users coming from an on-wiki link (either in the sidebar or the popup), because the language code, book title, and format are provided automatically and so will never be incorrect (although we might add functionality in the future to make it possible to change these).

@Prtksxna, @nayoub, and I have discussed this ticket a bit, and some things that are recommended for the user experience (whenever we implement the outcome of this investigation should include):

• Short and to-the-point language on cause of error and next steps
• Lengthier explanation of error could be in a separate pop-up or documentation page accessed by clicking on a link within error text
• Fields should be pre-populated with selection previously made that resulted in error (in case user wants to try again)
• There should be an easy way to go back to Wikisource (perhaps a button on the top of the page or next to the error statement)

Note: We have discussed this in our meeting, and all of the points above (other than #2) seemed doable and useful to users, according to @dmaza. We discussed that #2 can be for a more generalized documentation page instead, which provides info on common errors and next steps. We will invite community members to help improve and expand the page.