Change Details

The “Add links” tool on the client wikis allows the wiki editors to simply add a sitelink to the current page to Wikidata. As I have just learned, it is even capable of //merging// already existing items: when the current page is linked to an item with no other sitelinks, the tool allows to “add a link” to another wiki by _merging_ the current item with the item containing the //destination// sitelink. This seems useful and mostly it is. However, the [[ https://www.wikidata.org/wiki/Wikidata:Wikinews/Development | current practice of linking Wikinews _categories_ to Wikipedia _articles_ (and Wikidata subject items) ]] causes trouble here. When a Wikinews category has a Wikidata item with the singular sitelink (e.g. [[n:pt:Categoria:Atentados de 13 de novembro de 2015 en Île-de-France]]) and a user on Wikinews clicks on the “Add links” tool (“Please select a site and a page that you want to link to this page.”) and enters the name of the corresponding category on another-language Wikinews site (e.g. [[n:fr:Catégorie:Attentats du 13 novembre 2015 en Île-de-France]]), the tool finds the current page’s Wikidata item (Q34178806, a category item) has a single sitelink and it finds the French Wikinews category is already linked to Q21479779 (a subject item), shows you a completely acceptable notice (“The page you have chosen is already associated to an item on our central data repository. Please confirm that the pages shown below are the ones that you want to link to this page.” Yes, that’s exactly what I’d like.) and proceeds to //merge// those two items which is wrong and results in a mess of wrong descriptions and instance-of statements. I have tested the problem by “adding a link” from [[https://pt.wikinews.org/wiki/Categoria:Mosul | n:pt:Categorie:Mosul]] to [[https://en.wikinews.org/wiki/Category:Mosul | n:en:Category:Mosul]], resulting in [[https://www.wikidata.org/w/index.php?diff=1327034047 | this merge]] (which I have reverted and fixed the problem manually, obviously). However, it’s not very obvious what should be done here. I understand there is no obvious //bug// in the tool. However, the result of using it is wrong. And the users of the tool cannot be blamed for it, really. Maybe the best option would be just to refuse to merge two items which //both// have //any// statements; leaving this merging usage only for the bare sitelink items auto-created by various bots and leaving the proper complex merges to be done on Wikidata? Or, disable the merging behavior altogether on Wikinews which is the different animal here? That would be at least a good temporary patch. Or should the tool check for those wrong merges specifically? That would mean hardcoding those Wikidata specific items (like “instance-of Wikimedia category” means something more special than “instance-of country”)? Not sure if that is a good path anywhere.

The “Add links” tool on the client wikis allows the wiki editors to simply add a sitelink to the current page to Wikidata. As I have just learned, it is even capable of //merging// already existing items: when the current page is linked to an item with no other sitelinks, the tool allows to “add a link” to another wiki by _merging_ the current item with the item containing the //destination// sitelink. This seems useful and mostly it is. However, the [[ https://www.wikidata.org/wiki/Wikidata:Wikinews/Development | current practice of linking Wikinews _categories_ to Wikipedia _articles_ (and Wikidata subject items) ]] causes trouble here. When a Wikinews category has a Wikidata item with the singular sitelink (e.g. [[n:pt:Categoria:Atentados de 13 de novembro de 2015 en Île-de-France]]) and a user on Wikinews clicks on the “Add links” tool (“Please select a site and a page that you want to link to this page.”) and enters the name of the corresponding category on another-language Wikinews site (e.g. [[n:fr:Catégorie:Attentats du 13 novembre 2015 en Île-de-France]]), the tool finds the current page’s Wikidata item (Q34178806, a category item) has a single sitelink and it finds the French Wikinews category is already linked to Q21479779 (a subject item), shows you a completely acceptable notice (“The page you have chosen is already associated to an item on our central data repository. Please confirm that the pages shown below are the ones that you want to link to this page.” Yes, that’s exactly what I’d like.) and proceeds to //merge// those two items which is wrong and results in a mess of wrong descriptions and instance-of statements. I have tested the problem by “adding a link” from [[https://pt.wikinews.org/wiki/Categoria:Mosul | n:pt:Categorie:Mosul]] to [[https://en.wikinews.org/wiki/Category:Mosul | n:en:Category:Mosul]], resulting in [[https://www.wikidata.org/w/index.php?diff=1327034047 | this merge]] (which I have reverted and fixed the problem manually, obviously). However, it’s not very obvious what should be done here. I understand there is no obvious //bug// in the tool. However, the result of using it is wrong. And the users of the tool cannot be blamed for it, really. Maybe the best option would be just to refuse to merge two items which //both// have //any// statements; leaving this merging usage only for the bare sitelink items auto-created by various bots and leaving the proper complex merges to be done on Wikidata? Or, disable the merging behavior altogether on Wikinews which is the different animal here? That would be at least a good temporary patch. Or should the tool check for those wrong merges specifically? That would mean hardcoding those Wikidata specific items (like “instance-of Wikimedia category” means something more special than “instance-of country”)? Not sure if that is a good path anywhere. --- Addendum [2022-10-15]: While the original bug above complains explicitly about merging category entities with non-category entities, the problem is more general. A similar problem was discussed [[ https://www.wikidata.org/w/index.php?title=Wikidata:Bot_requests&oldid=1749178259#Request_to_mass-merge_items_(2022-07-03) | at Wikidata:Bot requests ]]: linking an article about a given name on itwiki with a disambiguation page on another wiki was requested by a user, which caused the disambiguation item to be merged with the given name item, which is wrong. (To add insult to injury, the merged item was not even redirected because of T59745.) This means the extremely specific “solutions” referring to Wikinews above are in fact unusable. The best way forward is probably rejecting to merge entities which both have statements.

The “Add links” tool on the client wikis allows the wiki editors to simply add a sitelink to the current page to Wikidata. As I have just learned, it is even capable of //merging// already existing items: when the current page is linked to an item with no other sitelinks, the tool allows to “add a link” to another wiki by _merging_ the current item with the item containing the //destination// sitelink. This seems useful and mostly it is. However, the [[ https://www.wikidata.org/wiki/Wikidata:Wikinews/Development | current practice of linking Wikinews _categories_ to Wikipedia _articles_ (and Wikidata subject items) ]] causes trouble here. When a Wikinews category has a Wikidata item with the singular sitelink (e.g. [[n:pt:Categoria:Atentados de 13 de novembro de 2015 en Île-de-France]]) and a user on Wikinews clicks on the “Add links” tool (“Please select a site and a page that you want to link to this page.”) and enters the name of the corresponding category on another-language Wikinews site (e.g. [[n:fr:Catégorie:Attentats du 13 novembre 2015 en Île-de-France]]), the tool finds the current page’s Wikidata item (Q34178806, a category item) has a single sitelink and it finds the French Wikinews category is already linked to Q21479779 (a subject item), shows you a completely acceptable notice (“The page you have chosen is already associated to an item on our central data repository. Please confirm that the pages shown below are the ones that you want to link to this page.” Yes, that’s exactly what I’d like.) and proceeds to //merge// those two items which is wrong and results in a mess of wrong descriptions and instance-of statements. I have tested the problem by “adding a link” from [[https://pt.wikinews.org/wiki/Categoria:Mosul | n:pt:Categorie:Mosul]] to [[https://en.wikinews.org/wiki/Category:Mosul | n:en:Category:Mosul]], resulting in [[https://www.wikidata.org/w/index.php?diff=1327034047 | this merge]] (which I have reverted and fixed the problem manually, obviously). However, it’s not very obvious what should be done here. I understand there is no obvious //bug// in the tool. However, the result of using it is wrong. And the users of the tool cannot be blamed for it, really. Maybe the best option would be just to refuse to merge two items which //both// have //any// statements; leaving this merging usage only for the bare sitelink items auto-created by various bots and leaving the proper complex merges to be done on Wikidata? Or, disable the merging behavior altogether on Wikinews which is the different animal here? That would be at least a good temporary patch. Or should the tool check for those wrong merges specifically? That would mean hardcoding those Wikidata specific items (like “instance-of Wikimedia category” means something more special than “instance-of country”)? Not sure if that is a good path anywhere. --- Addendum [2022-10-15]: While the original bug above complains explicitly about merging category entities with non-category entities, the problem is more general. A similar problem was discussed [[ https://www.wikidata.org/w/index.php?title=Wikidata:Bot_requests&oldid=1749178259#Request_to_mass-merge_items_(2022-07-03) | at Wikidata:Bot requests ]]: linking an article about a given name on itwiki with a disambiguation page on another wiki was requested by a user, which caused the disambiguation item to be merged with the given name item, which is wrong. (To add insult to injury, the merged item was not even redirected because of T59745.) This means the extremely specific “solutions” referring to Wikinews above are in fact unusable. The best way forward is probably rejecting to merge entities which both have statements.