Thu, Mar 26
I think that other constraints still apply even if "manner of death" (P1196) is used as a qualifier for "category contains" (P4224). Also, "category contains" (P4224) will not be the only property with which "manner of death" (P1196) and other properties can be used as qualifiers.
(Sorry for commenting so late)
I'm afraid this will continue the path of overcomplicating property constraints with exception layers patching weak or ill-defined constraints. Do you think it would be okay to complete/relax the constraint by allowing P1196 to be used as a qualifier, @Bugreporter?
Feb 21 2020
Feb 20 2020
Feb 8 2020
Another option is that this constraint type becomes a default Wikibase feature consisting of checkboxes displayed on Property pages that enable the use of a Property for the main value, as a qualifier or in a reference.
This is one of only two types whose constraints have the mandatory severity level (1,221, 78%) more often than the normal severity level (349, 22%). Consistently, it has no constraints with the suggestion level and is one of the constraint types with the fewest exceptions. Widely applicable constraint types without exceptions, with a high proportion of mandatory constraints and with a clear and controlled set of parameters should be considered good candidates for becoming default Wikibase features.
Maybe. In the case of constraints, the section should never be empty and there is only one Property to define constraints, property constraint (P2302), but in the case of external identifiers it's harder to know which property to use (if any) and an empty section isn't necessarily wrong.
I don't know if it's worth the hassle, I can't imagine if the changes would take much or little time. :-/
I haven't been able to find a sufficiently descriptive name apart from those that list the three possible "scopes", something like "main-value/qualifier/reference constraint type", which is surely not the best name ever.
The box "Data: Number of constraints by constraint type and Property type" in the report can work as an approximation. Blank cells are cases that most likely don't make sense. It will probably be necessary to code a similar matrix in WikibaseQualityConstraints. If this is done, it will be very useful to show that information in T244044.
Feb 4 2020
Feb 3 2020
A specific data/property type for regular expressions or patterns would:
- ensure that the stored regular expressions or patterns are syntactically correct, in a similar way that quantity-type properties ensure that their statements are not paragraphs, something from which all implementations, tools and reusers would benefit;
- introduce a specific input (interface) control in Wikibase (not WikibaseQualityConstraints) that could make pattern editing more friendly: monospaced text, warnings, colored brackets, and all the amazing features that the developers want to implement. :-)
Feb 1 2020
Jan 15 2020
Related or not, sometimes I get the generic error screen instead…
Jan 14 2020
I think the reasonable default option is the talk page, thinking of all Wikibase instances. On Wikidata this won't be the most efficient possible solution, but it may serve until the community discusses and agrees on a more definitive solution for Wikidata, IMHO. Right now we have https://www.wikidata.org/wiki/Template:Edit_request. If the URL were defined by a MediaWiki message, the community would be able to change the default link (e.g., https://www.wikidata.org/wiki/Talk:Q42) to a more specific Wikidata link (e.g., https://www.wikidata.org/w/index.php?title=Talk:Q42&action=edit§ion=new&preload=Template:Edit%20request/preload).
Jan 2 2020
Dec 15 2019
On Q78347074 we have two cases: family name and given name. Purging both the Item page and the property pages doesn't fix the issue.
Dec 5 2019
Side note/spoiler: This month I expect to sound out users in the context of the analysis on property constraints, with which we'll know what constraint types users most want, considering this one, the rest of subtasks of T213803, and others.
Nov 19 2019
Oct 19 2019
Oct 15 2019
Oct 14 2019
Yes. But do Wikibase installation owners and technical people know how to escalate those issues? I think they're escalating them but through private channels, which implies that, if the problem is theirs, the next user with the same problem doesn't find anything in a web search or in the documentation and asks again; and, if the bug is in the software, it is sometimes forgotten or bypassed, or even the user decides to change the use case, before the bug translates into a Phabricator task.
Oct 13 2019
The status is automatically given by the software after carrying out some edits. By "care about Wikidata" people usually mean learning what Wikidata is about by carrying out those edits. In that case (the usual), the flag request is unnecessary.
(By the way, we can consider lowering the threshold of the number of edits if we conclude that it's too high, although it was actually increased a few years ago for the opposite reason; I was not involved in the process and, honestly, I don't remember what that threshold is right now.)
Oct 11 2019
Oct 10 2019
Usually editors have two opposite views about this option. One is similar to what @Amire80 exposes: if we propagate the autoconfirmed statuses from Wikipedias to Wikidata, then these autoconfirmed users are free to work on their wikis autonomously, without having to care about Wikidata. The other view is that they should actually care about Wikidata, that the confirmed status is easy to get and that you already get it automatically after carrying out the few test edits necessary to know what Wikidata is about. Some people will say the first option pursues our goals and contributes more to centralization/harmonization, and others will say exactly the same about the second option.