As an editor, I only want to see constraint violations if a statement is actually incorrect.
Problem:
Currently, any property of type tabular data or geographic shape with a “commons link” constraint will result in a constraint violation, since CommonsLinkChecker does not handle the Data: namespace correctly. In T214856, we taught it about the Data: namespace, but it looks like it’s still trying to parse titles in this namespace using a TitleParser for Wikidata, which doesn’t work (there’s no such namespace there); consequently, it then searches the database for a page with page_title = Data:Highland.map (and page_namespace = 486) instead of page_title = Highland.map, and reports an error when the page isn’t found. (Also, the valueIncludesNamespace() condition in checkConstraint() looks suspicious to me as well. For tabular data and geographic shapes, the namespace is required, as far as I can tell.)
Example:
https://www.wikidata.org/wiki/Q208279#P3896
Screenshots/mockups:
BDD
GIVEN I am logged in
WHEN I look at a statement of type “geographic shape” or “tabular data”
AND the statement’s property has a “commons link” constraint (query of such properties)
THEN I do not see a constraint violation (unless the value is actually not well-formed, e. g. uses _ instead of )
Acceptance criteria:
- CommonsLinkChecker recognizes the Data: namespace
Open questions:
- CommonsLinkChecker is annoyingly difficult to test locally (the commonswiki database name is hardcoded), do we want to improve that as part of working on this task? (T169538)