When user submit something through CX and they hit an AbuseFilter warning, they can't just submit the content again and let it go through.
An example failure is an external link from the source article that was transferred to the translation (example report). The issue is hard to spot for the user since the problematic content was not created explicitly.
Currently, we are showing an error when the user tries to publish (with a cryptic debug message). We can consider better approaches for (a) communicating the issue and (b) nor preventing publishing content.
For example, we can highlight the problematic content (e.g., the external link) for the user to fix. If the issues is not fixed when the user tries to publish, a warning informs the user that the content will be published without the problematic elements. In this way, most of the translation can be published instead of getting blocked because a small piece of content.
# Proposed approach
Some considerations:
- There are different kinds of issues: warnings and errors.
- We can identify them at different moments: once the article is loaded, as content is edited or when publishing.
- For some of the issues we can identify in which section/paragraph they are happening while others affect the whole document (or is not possible to identify the specific problematic content).
- It is possible to have more than one issue at a time.
An overview is provided below illustrating how to represent some of the above aspects:
{F3280587}
Based on the above, here are some representations for different cases:
**Error on load that can be mapped to a section: title blacklist**
In this case, as soon as the content is loaded, an error preventing from publishing is identified on one section:
{F3280610}
- An error message is shown in red.
- The publish button remains disabled until the title gets edited.
- The affected paragraph (the title) gets highlighted with a red line next to it. When the paragraph gets the editing focus, a contextual card will be shown (more below).
{F3280613}
- A card is shown with the specific error, and an indication that it prevents from publishing.
- A "Learn more" link points to the local page with Abuse filter information.
- A specific action that helps to resolve the issue can be provided. In this case, using MT to translate the title could be helpful. For other cases, other actions (e.g., a quick access to clear the content) or no action may be preferred.
**Warning while editing**
In this case, an issue is identified in a paragraph. Thus, the rest of the document can be published.
{F3280627}
- Paragraph gets highighted in yellow.
- The button for publishing remains enabled.
- A card with a yellow flag is shown when the paragraph has editing focus.
- The card describes the issue (in the example above, in a generic way, more on this later) and explains that the content will be skipped when publishing.
- A "learn more" link provides access to the local Abuse filter information.
- A quick action allows to clear the paragraph.
When the user publishes a translation with content issues, a warning is shown indicating that the article was published but some parts were skipped:
{F3280630}
Considering that spam links account for a high percentage of the abusefilter issues, a more specific card can be defined for this case:{F3280633}
**Warnings while publishing**
In this case, warnings should not prevent the user from publishing but they should surface the issues to encourage users to fix them.
{F3282778}
**Errors when publishing about the whole article: short article, protected page**
In this case, the issue is discovered when trying to publish and it is not attached to a specific part of the document.
{F3280635}
- A message is shown after the user clicked on "Publish article".
**Multiple issues**
Since we are extending the existing error/warning mechanism, it is possible that several issues apply.
For those cases, instead of showing multiple bars, it is better to show one at a time (errors having precedence over warnings) and allowing users to navigate them:
{F3280643}