Wikidata:Property proposal/constraint text
Wikidata constraint text
editOriginally proposed at Wikidata:Property proposal/Property metadata
Withdrawn
Description | text that gets shown when a constraint gets violated |
---|---|
Data type | Monolingual text |
Domain | Wikidata property constraints property constraint (Q21502402) |
Example | single-value constraint (Q19474404) → en:"This property should only contain a single value. That is, there should only be one statement using this property." |
See also | MediaWiki:Wbqc-violation-message-single-value |
- Motivation
Currently, the texts in the constraint tool aren't editable by Wikidata editors. That means we can't easily change them through community consensus. It also makes it harder to translate them into other languages.
I used the current text for the example, even if I don't think it's the best way to express the constraint.
WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Notified participants of WikiProject property constraints ChristianKl (✉) 17:39, 16 December 2017 (UTC)
- Discussion
- It would be easier to do translation on entity labels and descriptions instead of monolingual strings on statements. -- JakobVoss (talk) 20:02, 16 December 2017 (UTC)
- Comment For the issue at hand, maybe it's sufficient to improve MediaWiki:Wbqc-violation-message-single-value. The longer text already lists some likely exceptions: Help:Property constraints portal/Single value (disclaimer: I wrote some of it).
--- Jura 20:13, 16 December 2017 (UTC) - Oppose According to the links in the comment above David (talk) 07:32, 17 December 2017 (UTC)
- If there is a good reason to overwrite them then this can be done locally in the messages as described. However I would really urge not to do that for three reasons: 1) It does not benefit other installations of the software outside Wikidata 2) The messages have gone through at least some usability testing to make them understandable for non-hardcore editors. 3) It doesn't go through translatewiki and therefore doesn't get as many translations as it should and other languages will still have the message Wikibase provides. If the messages have issues please let me know and we'll change them (unless they make things less understandable for new people). The list of all messages is here: https://phabricator.wikimedia.org/diffusion/EBQC/browse/master/i18n/en.json --Lydia Pintscher (WMDE) (talk) 13:47, 18 December 2017 (UTC)
- @Lydia Pintscher (WMDE): I'm not sure what the word "understandable" means in that sentence. Given of the result of the text of the first iteration of the "single value constraint" I guess that the process that was used isn't likely to lead to anything that corresponds to what most people take "understandable" to mean. It seems to me that however wrote the text didn't go through the excercise of first trying to understand what hardcore editors mean with the constraint to then chose a wording that will make non-hardcore editors understand the same thing.
- I can understand who someone how not familiar with the way how the "single value constraint" is used could come up with the text that includes the word "should" when the existing text doesn't use it. I can even see how the text the UX person wrote is more clear. The problem is that it has a different meaning.
- I have no problem with those text being written by an UX person, but in general when writing UX texts that could be easily understood by users to represent policies, it would be nice to involve our community in the process. In addition I'm also happy about any UX input in the wording of policy proposals like https://www.wikidata.org/wiki/Wikidata:Living_persons_(draft).
- "This property should only contain a single value. That is, there should only be one statement using this property" can easily read as an recommendation against adding addition values even if you don't read the should as defined in RFC2119. You actually do need to be a hardcore user to interpret is the way it's supposed to be interpreted which for date of death (P570) is more like "If you add an additional value, it would be nice if someone would give the best value preferred rank and deprecate any incorrect values".
- I have withdrawn this proposal and I'm okay with the information being stored in the templates. Sooner or later we likely will also have to translate them via translate-wiki.
- As far as the usage of the functionality by other Wikibase installation, I think it would be best if other Wikibase installation could use Wikidata's entities from the Q and P namesspaces and have their own items and properties in their own namespaces. Even if you store the information about the constraint texts outside of the items of the constraints, the items of the constraints are still necessary to declare the constraints and it would be added complexity for new Wikibase installations to create items and see what kind of Wikibase setting they have to set to make those items recognized as constraints. That would also mean that projects like FactGrid don't have to run bots to copy over data from us. As far as I understand the FactGrid people and also another party from whom I heard at WikidataCon who had a Wikibase installation both would be happy to reuse our existing properties when we have existing properties for the data they want to describe. ChristianKl (✉) 16:13, 19 December 2017 (UTC)
- Oppose per the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 18 December 2017 (UTC)