Talked about it with the team.

A concern is that the validation happens currently server-side (don't trust the client etc. ) and would be bad if we would need to replicate the code client side.

We could just do it on save, but @thiemowmde noted on T138312 that this is not a nice way either (aside of line-validation performing much better in tests)

So one decent way would be to send the data to the server, e.g. after 300ms and have the validation result send back to the client.
It may be too costly for some values but it would be already great if we could provide an easy way to resolve most of the errors via inline-validation.

If there are specific questions regarding the nature of the errors (e.g. a particular value is too costly to check but maybe it happens very rarely anyway) we could log it (would need consultation with @Addshore to prevent huuuuuuge logs)

@daniel, @adrianheine – did I get this right?

Added it to Wikidata-Sprint-2016-07-19 so we don't forget it next storytime.

Error handling of the VisualEditor on Wikipedia:

Short summary of the planning in regards to this on 12.7.16:

Quick Fixes: T140085 (autosuggest shows "nothing found"), T54843 (expand error message on default)

Interface-wise:

• Concerns about a checkmark indicating that the value is real-world truthy and not just technically correct.
• We need at least 3 states: Unresolved, OK, error. And maybe a 3.5th one that is like "unresolved because we can't reach the server"
• Some Errors will not relate to a specific input field. @daniel : Which are those?

Architecture:

• We could generalize the preview API for the send-and-recieve part.

Thats what preview currently looks like in the UI:

@Jan_Dittrich Errors that do not correspond to a single input field:

1. Uniqueness constraints on the combination of language, label and description: the error applies to the three fields together (one line in the term-box). Currently, you can edit terms for multiple languages at once, so there may even be multiple conflicts for clicking save once. Finding out which error belongs to which line is tricky. Also note that the constraint check is pretty expensive (see T74430). We don't really want to do this before saving.
2. Uniqueness constraints on sitelinks (on the combination of site ID and page title): the error applies to the two fields together (one line in the sitelink bar). Currently, you can edit links for multiple sites at once, so there may even be multiple conflicts for clicking save once. Finding out which error belongs to which line is tricky. Also note that the constraint check is pretty expensive (though not nearly as expensive as the check for terms). We don't really want to do this before saving.
3. When editing a Statement, it's possible to add an URL as the main value, 3 qualifiers, and as part of 2 references. That's 6 URLs that may fail to validate once the user hits save. If we do real-time validation, this isn't a problem though. In that case, the correct control should always be known.

I'd like to repeat my suggestion from the Story Time session:

Tell the save button why it is disabled. There are already code paths that update the save button's state to enabled or disabled. It should be simple enough to indicate the reason via the same code paths. Even if it's still unclear how this information will be shown, and if we also want to show it elsewhere, I believe this is worthwhile doing.

As to the architecture: we should generalize real-time validation for the widgets for all data types. The delayed-update-while-typing part is already there for some data types (the ones that have previews), we should have that for all widgets. We should also improve our server side API to allow for a full parse/validate/format cycle in a single request.

I would personally also suggest to generalize our preview mechanism, but there was no agreement on this point. If we had a preview area for all data types, we could use this as the generic place to display validation failures.

@daniel :

• on "Errors that do not correspond to a single input field": that seems manageable. We would need to find an alternative location for the error and maybe convey that it will not be checked live. This is best determined in a user test anyway.
• on the suggestion: Yes that makes sense to me. I can't estimate how this all will play together (so infos for the save button will take a different path than the info for the fields?).
• also on the suggestion: It would make sense to display failures in such a place. Semantically it would make sense if the preview and the error message data are easy to tell apart technically on the client side (come in different JSON-properties or so)

In T138748#2456812, @Jan_Dittrich wrote:

so infos for the save button will take a different path than the info for the fields?

As far as I understand, they have to, because the save button lives on an entirely different level of the code as the input field. They also have different cardinality (a single save button can save the content of dozens of input fields).

Semantically it would make sense if the preview and the error message data are easy to tell apart technically on the client side (come in different JSON-properties or so)

That's already the case, of course :)

@WMDE-leszek, @Aleksey_WMDE: This issues was one that seemed to be difficult to implement.