Wikidata:Requests for permissions/Bot/PintochBot 3
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Request withdrawn --Lymantria (talk) 06:54, 7 June 2018 (UTC)[reply]
PintochBot[edit]
PintochBot (talk • contribs • new items • new lexemes • SUL • Block log • User rights log • User rights • xtools)
Operator: Pintoch (talk • contribs • logs)
Task/s: migrate back the snak location constraints to the original format.
Function details:
The goal is to maintain existing functionality, reverting KrBot's edits to move back to the original syntax. I am already removing the new claims created on identifiers. This bot task will migrate constraints where only one type of location (main value, qualifier, references) is allowed.
See discussion at Wikidata talk:WikiProject property constraints
See sample edits at toollabs:editgroups/b/CB/782f83abc/
− Pintoch (talk) 18:10, 25 May 2018 (UTC)[reply]
- Not sure whether a revert is a good idea here. Ivan's single-handed move to the new system certainly wasn’t an appropriate action, but it seems to me that his approach is much more comprehensible; Lea's comment indicates that WMDE has a similar opinion.
Now what to do? There is certainly a need to have the old constraints in the properties, but shall we really remove the new ones to eventually add them again at some point in the future? Can't we have both for a while, even if this means that there may be inconsistencies? —MisterSynergy (talk) 18:35, 25 May 2018 (UTC)[reply]
- @MisterSynergy: I agree that a new syntax would be better. But as Lucas wrote, the current syntax is neither desirable (because it uses the constraint scope qualifier in an invalid way) nor effective (because the gadget does not support it). So we need to come up with a new proposal, which could potentially involve creating a property (which takes time to create), then we need to write patches for the implementations (which also takes time), deploy them (which also takes time), and finally migrate the constraints to the new syntax. In the meantime, all these constraints will be unchecked. I am just proposing to restore them as a temporary measure and I am perfectly happy if someone migrates them afterwards to a syntax that has been properly discussed. − Pintoch (talk) 08:04, 26 May 2018 (UTC)[reply]
- It's known that the gadget works slightly different than the bot reports. So, I don't see a problem of having both of them in place.
--- Jura 13:21, 1 June 2018 (UTC)[reply]
- @Jura1: sure! but currently, only one is in place: Ivan's syntax. He did not just add constraints in the new format: he also deleted all the existing ones in the previous format. So we don't have both of them in place at the moment (except at rare exceptions where some editors re-added the previous format themselves). Do you think we should A) not do anything about this B) duplicate the constraints, so that they use both the old syntax and Ivan's syntax C) migrate everything to the old syntax? − Pintoch (talk) 08:32, 2 June 2018 (UTC)[reply]
- a temporary duplication of the constraints seems the best solution to me. --Pasleim (talk) 17:55, 3 June 2018 (UTC)[reply]
- Withdrawn since the consensus is for duplication, I have done this directly as a QuickStatements batch: https://tools.wmflabs.org/editgroups/b/QSv2/2704/ − Pintoch (talk) 14:01, 4 June 2018 (UTC)[reply]