To fill in some more detail: my comment was that this currently works as designed (see "Notes on the design" in T209318). An alternative proposal would be to pass through whatever error is set on the backend for the user to read. The advantage to doing so is that the user is informed (hopefully) about what went wrong and why their question didn't post. One could argue that the disadvantage is the newcomer may not understand the error message. We could consider showing both the current error message and the specific error message below it, but I'm not sure how well that would all fit within the help panel or mentorship/help modules.

If we are really worried about showing cipher-ish error messages to newbies, maybe show the current fail message with an "advanced" button to show the real error (abusefilter, read-only, whatever)?

@Aklapper Not fully sure this is relevant to T40638: [DO NOT USE] Interface messages needing rewording or documentation and other issues with existing messages [superseded by #Voice_&_Tone]. This is not about a interface message - unless I'm wrong, this currently shows an interface message intended for "general failure", which is phrased correctly. The proposal is to create a new message just for AF error, and show it in case of this error.

@kostajh -- is it possible or advisable to detect that the posting error is because of an abuse filter, and then to conditionally show a different message to the user when they are caught by the abuse filter than for the rest of errors?

@MMiller_WMF yes it is possible to surface only the abuse filter errors. Whether it's advisable to show the details of those and not others, I'm not sure. I would be in favor of starting with showing Abuse Filter errors then re-evaluating if we want to show all errors.

@kostajh -- okay, so here's what I was thinking:

• If the question can't be posted because of an abuse filter, then our existing design for errors would show the abuse filter's message.
• If the question can't be posted for any other reason, then our existing design would do exactly what it does now.

How does this sound?

Is there only one global abuse filter error message? Or can different filters send different messages?

In T222204#5168845, @MMiller_WMF wrote:

Is there only one global abuse filter error message? Or can different filters send different messages?

Any filter can send any message. Even more, each filter can prohibit the edit to be saved, or just warn the user before saving. It is up to you if we want to show any difference between warning and edit cannot be saved cases :).

EDIT: Not sure what you meant by "global", however, there are both global (applies on multiple wikis, IIRC all but large, which includes cswiki those days) and local (applies only on one wiki) filters. IIRC users can't tell which one matched without going through logs. I don't think there should be any design difference.

@kostajh -- wanted to check back on what you think of my proposed idea two comments above.

If the question can't be posted because of an abuse filter, then our existing design for errors would show the abuse filter's message.
If the question can't be posted for any other reason, then our existing design would do exactly what it does now.

How does this sound?

That sounds OK. The other reasons would include: 1) user has logged-out (but hasn't reloaded the page), 2) edit conflict on the help page; 3) page is protected. Maybe it does make sense to surface all error messages, and not just AbuseFilter ones.

Is there only one global abuse filter error message? Or can different filters send different messages?

As @Urbanecm mentioned, they can be customized. For example, https://en.wikipedia.org/wiki/Special:AbuseFilter/3 uses this message https://en.wikipedia.org/wiki/MediaWiki:Abusefilter-disallowed-blanking

Okay -- I think we should generally do this plan. I ran the numbers, and only 2 submission attempts out of 90 (that are still in the event.helppanel table) resulted in a "submit-failure". So this is not a common occurrence. But in case it is easy to detect which kind of failure the user encounters, I quickly wrote these error messages for the scenarios you listed:

• User has logged-out: "You are not currently logged in. Please log in to your account to ask your question." In this case, "log in" is a link to https://en.wikipedia.org/w/index.php?title=Special:UserLogin.
• Edit conflict: "An error occurred when trying to post your question. You can try again or you can visit Community Help Desk in your browser and add your question manually." This is the same as the default error message.
• Page is protected: "Community Help Desk questions are not available at this time. You can try again later or you can visit Community Help Desk in your browser and add your question manually." The second "Community Help Desk" should link to the page, like in the default message.

Change 530085 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] QuestionPoster: Return result for non-exceptional errors

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

@MMiller_WMF I've put this into code review but a few notes/comments/questions for you, since what I've submitted is a little different from what you specified in T222204#5238771

1. The patch will show the abusefilter message directly to the user, just as if the user had attempted to save an edit in VisualEditor (like the screenshot in this task description). AFAICT this is the most important item to address in this task.
2. The patch will show the "You are blocked" message directly to the user, in the same way that a blocked user sees the message when they try to save via VE
3. The patch does not show any more detail to a logged-out user, it shows the generic error message we currently show when there's a problem. There are two reasons for this: 1) the situation where a user opens the help panel (they are logged-in, otherwise they wouldn't see it) then their session expires and they try to post a question some amount of time later has to be pretty rare if non-existent in production, and 2) adding code to handle this case would be annoyingly complicated, so I'd prefer to not add the additional complexity for that, if you agree.
4. The patch shows "This page has been protected to prevent editing or other actions." (in the wiki's content language) when the help desk is protected or the user attempts to post to a mentor's protected talk page via the mentorship module. This is not ideal from a usability perspective since the user would think "This page" is the page they have open rather than the help desk, but similar to the point above, handling this case separately could be kind of difficult to implement cleanly. How often do we think this situation might occur? Should we try to address this?
5. Edit conflict, I haven't tested this but I believe it would show the edit conflict message rather than the generic message. Similar to the point above, it might be a little confusing to the user since they would have to intuit that the message is talking about the help desk page rather than the page they are looking at with the help panel open.

The alternative to the caveats above is to add the custom translation strings as requested in the task description, but I thought I'd see if what I've proposed here is satisfactory before proceeding with that.

Ideally in the case of an edit conflict the message should just be reposted.

@kostajh -- I'm late in responding to this, but all the comments you made sound fine to me. Let's proceed and test out what you've written. @Etonkovidova will let us know if things seem weird.

Looks like ContentTranslate has a workaround for dealing with AbuseFilter checks (T114621: Get ContentTranslation to anticipate and handle AbuseFilter warnings and blocks / includes/AbuseFilterCheck.php) so maybe worth upstreaming that into AbuseFilter and reusing it here.

In T222204#6594664, @Tgr wrote:

Looks like ContentTranslate has a workaround for dealing with AbuseFilter checks (T114621: Get ContentTranslation to anticipate and handle AbuseFilter warnings and blocks / includes/AbuseFilterCheck.php) so maybe worth upstreaming that into AbuseFilter and reusing it here.

See T266380. I wasn't aware of that task, I'll give it a read. Either way, the code in ContentTranslation is painful to maintain. Upstreaming should be fine, though.

Change 530085 abandoned by Kosta Harlan:
[mediawiki/extensions/GrowthExperiments@master] QuestionPoster: Return result for non-exceptional errors

Reason:

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