This is already working for the HTML pages of Wikidata.

Side note: Please keep in mind that data quality is often understood as the "fitness for use" (http://www.semantic-web-journal.net/system/files/swj414.pdf) or "purpose" (https://www.cio.com/article/3124402/ensuring-the-quality-of-fit-for-purpose-data.html) of the data. From the RfC "Data quality framework for Wikidata":

Everything looks good to me on https://wikidata.beta.wmflabs.org/. Thank you, folks!

I'm sorry I put this aside (my fault). I didn't include tests, but I feel I don't know the architecture well enough to write them; I sense that these will be complex or that I'll need to touch code elsewhere. I think it's better for me to officially give up on these tests so that a developer on the team (or other volunteer) can code them. I'll list a few checks I have in mind, but please don't consider this list essential or exhaustive:

• A request for a page that is not a Wikibase entity does not generate a response with links to alternative structured representations.
• A request for a Wikibase Item generates a response with links to alternative structured representations.
• A request for a Wikibase Property generates a response with links to alternative structured representations.
• The link headers are well formatted.
• All the alternative structured representations listed are available.
• All the alternative structured representations available are listed.
• All the alternative structured representations listed are about the requested Wikibase entity.

@DannyS712: I think I don't understand your question. What do you mean by reusing a regex? What would you expect could be done on the UI that is not possible now? On https://www.wikidata.org/wiki/Wikidata:2020_report_on_Property_constraints#format there are also some general stats about our regular expressions.

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, and other properties, to be used as a qualifier, @Bugreporter?

In T244054#5907030, @Lucas_Werkmeister_WMDE wrote:

(I assume you meant that this would allow any unit with P31 coherent SI unit?)

Great! So, as far as WikibaseQualityConstraints (and not other implementations) is concerned, we could use "coherent SI unit" in the "allowed units" constraint of "conversion to SI unit" (P2370)?

In T244054#5844581, @Lucas_Werkmeister_WMDE wrote:

I also observe that the property with the highest number of allowed units, conversion to SI unit, presumably wouldn’t profit from this at all – its 84 units should all be different “classes”, otherwise it’s not very much of a standard conversion. From a glance at the list, that indeed appears to be the case (the classes being “length”, “mass”, “length squared”, “length over time”, etc.).

(It also follows that for this particular constraint, the checker should in fact not apply unit conversions, but we don’t have a way to express that in the constraint statement yet.)

<joke>
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.

</joke>

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.

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. :-)

In T244047#5844332, @Lucas_Werkmeister_WMDE wrote:

the extension itself doesn’t have any constraint names

Related or not, sometimes I get the generic error screen instead…

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&section=new&preload=Template:Edit%20request/preload).

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.

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.