Jan_Dittrich added a comment.
@Lucas_Werkmeister_WMDE : Yes this is better. I assume that the message is useful for most of our users now.TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Lucas_Werkmeister_WMDE added a comment.
Okay, wikidata-constraints now has a shim SPARQL service that just supports REGEX (we don’t have enough resources to run Blazegraph ), and there are two test statements on John F. Kennedy (see explanation in the fourth paragraph of the Main Page).
gerritbot added a comment.
Change 370476 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Include syntax clarification in Format violation message
https://gerrit.wikimedia.org/r/370476TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL
gerritbot added a comment.
Change 370475 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Add support for parsing syntax clarification param
https://gerrit.wikimedia.org/r/370475TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL
gerritbot added a comment.
Change 370476 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Include syntax clarification in Format violation message
https://gerrit.wikimedia.org/r/370476TASK
gerritbot added a comment.
Change 370475 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add support for parsing syntax clarification param
https://gerrit.wikimedia.org/r/370475TASK
Lucas_Werkmeister_WMDE added a comment.
Yes, there can be multiple format constraints (see e. g. ISBN-10).TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Lydia_Pintscher, Nikki,
Nikki added a comment.
As a qualifier would make more sense, since it's clarifying a specific statement.TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Lydia_Pintscher, Nikki, PokestarFan,
Esc3300 added a comment.
Should we use https://www.wikidata.org/wiki/Property:P2916 as a qualifier or directly as a statement?TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Lydia_Pintscher,
Jan_Dittrich added a comment.
Yes, I’m fine with it.TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jan_DittrichCc: Lydia_Pintscher, Nikki, PokestarFan, Lucas_Werkmeister_WMDE, Jan_Dittrich, Aklapper,
Lucas_Werkmeister_WMDE added a comment.
Yeah, let’s use messages like this:
The value for local dialing code (123/456) should match “string combining digits, spaces, - (All else excluded, such as: ,/;()+ )” (regex: [\d\- ]+).
or, if there’s no syntax clarification:
The value for local dialing
Nikki added a comment.Herald added a subscriber: PokestarFan.
In T170374#3429492, @Lucas_Werkmeister_WMDE wrote:
Could we use capture groups and see which does (not) capture?
I don’t see how – all we get back from the query service is “matches” or “doesn’t match”, and doing anything not on the
Esc3300 added a comment.
Some might have seen https://www.wikidata.org/wiki/Property_talk:P2302#Conversion_of_existing_properties : there are a couple of properties that duplicate format constraint templates.TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL
Jan_Dittrich added a comment.
To avoid that we miss the context of use here: What are examples where the regex-based constraint would be used? One example seems to be the definition of formatter URLs (https://www.wikidata.org/wiki/Property:P1630). But where else would these be used and where would
Lucas_Werkmeister_WMDE added a comment.
Is that a constraint-by-principle or something that the query service could do but currently does not?
A constraint by principle. We only have a REGEX() function that returns true or false.TASK DETAILhttps://phabricator.wikimedia.org/T170374EMAIL
Jan_Dittrich added a comment.
we would have a Regex, but it carries no context what it would do?
Yup.
That sounds problematic to me, regexes are hard enough to read even with comments and context. For a hack one runs for oneself it is OK, but having it as a more central element in the
Lucas_Werkmeister_WMDE added a comment.
we would have a Regex, but it carries no context what it would do?
Yup.
Could we use capture groups and see which does (not) capture?
I don’t see how – all we get back from the query service is “matches” or “doesn’t match”, and doing anything not on the
Jan_Dittrich added a comment.
And we don’t have a short description of the constraint (“a URL”).
So, just to get it right, we would have a Regex, but it carries no context what it would do?
figuring out how to “fix” a string so that it matches a regular _expression_ is a hard problem
Could we
Lucas_Werkmeister_WMDE added a comment.
@Jan_Dittrich your suggestions are very difficult to implement – figuring out how to “fix” a string so that it matches a regular _expression_ is a hard problem. And we don’t have a short description of the constraint (“a URL”).
@Esc3300 I wasn’t aware of
19 matches
Mail list logo
