matej_suchanek added a comment.
I'm not sure how the users are creating the edits, but it seems like unintended behaviour.
Propably with the client sitelink widget.
In T127213#2035936, @Mbch331 wrote:
When they use Special:MergeItems no redirect is created when there is a conflict with descripti
Nikki added a comment.
@Esc3300: I'm not sure that it's a good idea to combine your case with the problem I originally reported where the merges should have been completed, not prevented. They have different expected behaviour and I think your case should be a higher priority, which I assume would
Esc3300 added a comment.
Looking the source of QuickStatements, it seems to use ignore conflicts = sitelinks.
https://bitbucket.org/magnusmanske/wikidata-todo/src/0bfdfdb727913ff71b2d6ea49949d4203d122c3a/scripts/quick_statements.php?at=master&fileviewer=file-view-default
This probably explains th
Magnus added a comment.
So what should I set "ignore" to?
Phrased differently: With which settings will wbmergeitems fail and not edit the item, in case of non-resolvable conflict?TASK DETAILhttps://phabricator.wikimedia.org/T127213EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/e
Esc3300 added a comment.
I'd use "description" or "description|statements".
Statements is probably to avoid that items linking to each other don't get merged.
To be safe, use "description".
Obviously, there is still the bug that sometimes the api doesn't work .. but this is what this bug was ori
Magnus added a comment.
Now switched to "ignoreconflicts:description".TASK DETAILhttps://phabricator.wikimedia.org/T127213EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MagnusCc: Lydia_Pintscher, Esc3300, Magnus, matej_suchanek, hoo, Mbch331, Aklapper, Nikki,
hoo added a comment.
This is desired behavior and applies equally to ignoreconflicts=description and ignoreconflicts=sitelink (and combinations of both).
Basically if either or both of these are set, we will just leave the conflicting piece of data (description or sitelink) on the Item we're mergi
Nikki added a comment.
I think it shouldn't allow a merge unless it is also going to create a redirect - either the merge is good and both parts should be done, or the merge is bad and neither should be done. Doing one but not the other always (as far as I can tell) creates a situation where someon
Esc3300 added a comment.
In T127213#2691838, @hoo wrote:
In T127213#2691830, @Esc3300 wrote:
I don't think it should abandon the merger half way through.
It doesn't, it fully completes the merge, but doesn't create the redirect.
Well, yes and no. There are two ways of seeing it. Currently Pas
Esc3300 added a comment.
It seems that initially items were merged into one and then the other deleted. This might just be a leftover from that.TASK DETAILhttps://phabricator.wikimedia.org/T127213EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Pasle
hoo added a comment.
In T127213#2691902, @Esc3300 wrote:
It seems that initially items were merged into one and then the other deleted. This might just be a leftover from that.
We never automatically deleted items, but users did that with scripts.TASK DETAILhttps://phabricator.wikimedia.org/T127
Addshore added a comment.
The current behaviour is exactly as it was designed, you cant technically merge something that has conflicts. If you try to merge two items that both an an enwiki sitelink then you are probably doing something wrong and should resolve the conflict before merging.
Having t
Esc3300 added a comment.
I think you should add :
4. undo semi-"merge"
TASK DETAILhttps://phabricator.wikimedia.org/T127213EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Addshore, Pasleim, Lydia_Pintscher, Esc3300, Magnus, matej_suchanek, hoo,
13 matches
Mail list logo
