The merge gadget: https://www.wikidata.org/wiki/MediaWiki:Gadget-Merge.js

I assume we just have to remove the createRedirect(fromId, toId) method and it should be fine. Didn't test it yet though.

In T107275#1491316, @Lucie wrote:

I assume we just have to remove the createRedirect(fromId, toId) method and it should be fine. Didn't test it yet though.

It seems to work. When is the next deployment going to happen?

I am pretty sure the deployment is later today.

https://www.wikidata.org/wiki/?diff=237940999

Seems to work when there are no conflicts: https://www.wikidata.org/wiki/?diff=237941157&oldid=237917647
Not sure about edge cases though.

There's a merge here https://www.wikidata.org/w/index.php?title=Q16814025&action=history which didn't create a redirect. I've always fixed those by doing the merge again with the merge gadget, but now that just redirects me to the target ID without making any changes.

I just manually created a redirect, but had to clear the item to be able to do that. There were still 3 descriptions left. (And Special:Merge didn't want to do anything. Conflicting descriptions for language en was the error I got). When I check https://www.mediawiki.org/wiki/MediaWiki_1.26/wmf16 I don't see any changes regarding the merge function on Wikidata.

Should the gadget redirect the emptied item even if it is not actually empty?

In the past the item was cleared before creating a redirect: https://www.wikidata.org/w/index.php?title=Q8959621&diff=237705492&oldid=237705472

Special:Merge didn't merge before if two Items would have conflicting labels, descriptions or sitelinks either. So we decided to keep it that way.

So the merge gadget just deletes everything that is conflicting and then redirects? Is that the expected behavior? The SpecialPage (and API) does redirect now only if the merge doesn't have any conflicts and otherwise leaves an item with the conflicting label/description/sitelink.

https://www.wikidata.org/wiki/?diff=237985464&oldid=231048969
Now if the API hasn't redirected the item because it isn't empty, we overwrite and redirect it.

Please check again whether the current behavior is the desired one.

For me it works as desired. Don't know how @Sjoerddebruin thinks about this.

Time to close this? :)

ping @Sjoerddebruin