⚓ T164354 Check wording of messages/constraint check results
Check wording of messages/constraint check results
Check wording of messages/constraint check results
Story: As a user I want to understand the results of the constraint check/violations
Direction
Task:
We should check the messages for
- Being clear in what they refer to. Bad: "The value" Better: "The value 'car' for 'instanceof'…
- Even if a minor misunderstanding happens, the message should still come across right. Bad: using double negative statements
- We should check for usage of Wikidata jargon. If we have an more commonly understood alternative, we should use this. (Works well with point 1., "Being clear in what they refer to")
- Enables action. We should enable users to improve Wikidata after reading the message. Instead of "Something complicated is broken, and it is out of my control" they should think "There is something that can be improved, and I can support this by doing [action]"
Event Timeline
Some examples from T163997:
Some of the constraint violation messages are hard to understand. This one is, in my opinion, particularly bad:
This property's value entity must be in the relation to the item (or a subclass of the item) defined in the parameters.
Example violation: Douglas Adams has religion: atheism, but atheism is not an instance of religion, which the religion property demands.
All the important information you need to understand this message – that the relation is “instance of”, and that the class is ”religion” – is hidden in the parameters, which the user script doesn’t display at all!
We should include this information in the message (hyperlinked), and also split up this particular message into two, one for “instance of” and one for “subclass of”. Suggestion:
This property’s value (atheism) must be an instance of religion, Christian church, or religious denomination (or a subclass thereof).
Perhaps the list of classes needs to be truncated if it’s very long, but most of the time I hope we should be able to include it fully.
Jan also suggested including the property name in the message. Perhaps something like this?
The value for religion (here: atheism) must be an instance of…
An entirely different question is whether we want to assemble this message server-side or in the user script. The API already returns all the information required to assemble the message (constraint type and parameters), but currently the message is built on the server, which keeps the client very simple (it doesn’t have to retrieve labels or know about translations).
T102758 seems to be related to this, but it seems unclear if anyone still knows what to do with that task.
Change 351834 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Improve violation messages for Type and Value type
In a real-life discussion yesterday, there was the question if we can say something like "with father" (in which "father" would be a property) (@Lydia_Pintscher, @daniel)
The current form is grammatically not correct; other forms we briefly thought about would be longer and/or more technical.
@daniel suggested that "with" would be ok, if we indicate that we refer to father as name-of-something, e.g. formatted like father or »father«. One additional idea I had now would be putting it into a little "pill"? Like phabricator does with Issues? ( Example self link to this issue: T164354). That paradigm could be helpful in other places too where we need to distinguish a plain string from a-string-that-means-it-is-an-item/property/…-in-our-database
Thinking about this a bit more yesterday, it occurred to me that "...items using the father property" would perhaps be a good way to phrase this. The verb "using" sounds less awkward.
"father" could still be set italic, but it being linked is probably enough to mark it as a proper noun, as Jan noted yesterday.
Wait, that only covers the “Type” constraint, but not the “Value type” constraint. “The value for father should be…” is there a good way to phrase this with “using”?
Perhaps “the value of a father statement…”?
Edit: but then we have an a/an problem – “a ISBN statement” is wrong.
You can avoid a/an by using the (generic) plural:
“the values of father statements…” or "Values for the father property…”
Perhaps “the value of a father statement…”?
In that case, I think »with father« is as good and preferable if it does not cause who-do-we-construct-a-sentence problems.
Hm, I like the sound of using plural in both cases:
Entities using the father property should be instances of human, but whatever currently isn’t.
Values of father statements should be instances of human, but whatever currently isn’t.
There’s a nice separation between “all entities should have this” (plural) and “this entity doesn’t have this” (singular).
Change 353315 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Improve violation messages for Symmetric and Inverse
Change 353568 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Improve violation messages for Qualifiers and Mandatory qualifiers
Change 353569 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Improve violation messages for Conflicts with
Change 353852 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Improve violation messages for Item and Target required claim
Note that users have always two ways of fixing the constraint violations but, generally, only one is correct. These two options are:
- making the (indirectly) suggested changes, and
- removing the statements that are causing the violations.
A new message could be added to the UI for each set of warnings that explains that the right actions might not be making the suggested changes but simply removing these wrong statements.
@abian: Thanks for the suggestion!
@Lucas_Werkmeister_WMDE: As far as I can see there are no messages suggesting concrete actions like making changes or improving a check – is that correct?
We may want to consider some options e.g.
- putting this in a help text shown on demand (behind a ? icon or so)
- Writing it behind/below the popup’s headline "potential issues"
I assume that giving feedback to improve the constraint or to remove it is not that easy, so I would opt for something you can call up instead of something that is always there.
I was thinking on a simple and short message like "Fix the following issues or remove this statement if appropriate" (probably not the best wording, just an idea).
- Writing it behind/below the popup’s headline "potential issues"
This short message could be added here...
- putting this in a help text shown on demand (behind a ? icon or so)
I assume that giving feedback to improve the constraint or to remove it is not that easy, so I would opt for something you can call up instead of something that is always there.
... and, behind a ?, something more explanatory (although I'm not sure what to explain).
Change 354011 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Improve violation messages for Range and Diff within range
Change 354198 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Minor improvements to constraint violation messages
Change 354496 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Remove detailHTML / parameters from user script
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits