Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata

From Wikidata
Jump to: navigation, search
An editor has requested the community to provide input on "Allow the creation of links to redirects in Wikidata" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!

The main case[edit]

Currently, Wikidata has no problem linking to a redirect when the page wasn't a redirect at the time the link to it was created. On the other hand it's not possible to create links to pages that are redirects. I advocate here that it should be possible to create those links. ChristianKl (talk) 11:14, 28 May 2017 (UTC)

Also see Wikidata:Requests for comment/A need for a resolution regarding article moves and redirects#new Proposal zero closed in 2013 as "Consensus is clear: Wikidata links to Wikipedia redirect pages are allowed". 86.70.86.126 14:21, 28 May 2017 (UTC)

Bonnie and Clyde problem[edit]

The main motivation for having redirects is that they are a way to solve the 'Bonnie and Clyde problem' which lingers unsolved. The English Wikipedia has one article for Bonnie and Clyde (Q219937) while when Wikidata was founded in 2012 the Dutch Wikipedia had only an article for Bonnie Parker (Q2319886) and one for Clyde Barrow (Q3320282). In this case the problem got practically solved by creating redirects from the items Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282) to Bonnie and Clyde (Q219937) and the Dutch created their own article for Bonnie and Clyde (Q219937).

However the same problem appears in other contexts and the defacto solutions of creating the redirects is inhibited by the Wikidata software.

The 'Bonnie and Clyde problem' is bad because Wikipedians expect us to provide interwiki links and get unhappy when we don't have a good solution and have to tell them to add the interwiki links manually on their Wiki. It's a failure on our part if we have to tell them that we can't solve them and they have to add the interwiki links the old way. ChristianKl (talk) 11:14, 28 May 2017 (UTC)

TomT0m ArthurPSmith Place Clichy Daniel Mietchen DavRosen Dipsacus fullonum

Pictogram voting comment.svg Notified participants of WikiProject Cross Items Interwikis Obviously this has been discussed before - we even have a WikiProject nominally devoted to it, which I just pinged, which has a list of other problem cases to think about. I (Arthur) have also advocated for allowing redirects but it actually does not "solve" the 'Bonnie and Clyde' problem, which is fundamentally a User Interface issue for the language wikipedias. I'll comment below on why I think redirect links (or an alternative) would be helpful for wikidata. To fix wikipedia's "Bonnie and Clyde" UI issue I think the best approach is to use an item's "part of" (or "parent organization" etc) and "has part" relationships to augment the automatic inter-language links that are currently based only on having a common wikidata item. Wikidata linking to redirects helps slightly by adding these links on one side (from the more granular to the less) but it also confuses the assumption that the different language articles are actually about the same thing. ArthurPSmith (talk) 17:16, 30 May 2017 (UTC)

Some of the relationships are more subtle than "part of", the potato problem is a good example. All the best: Rich Farmbrough09:48, 1 June 2017 (UTC).

Wikidata is higher resolution than Wikipedia[edit]

The German Wikipedia has a list of streets and places in Berlin-Halensee. For the purposes of the German Wikipedia the streets aren't individually notable but for our purposes they are clearly identifiable conceptual or material entities that can be described using serious and publicly available references and thus is are notable. That means an item like Cicerostraße (Q30076706) has a place on Wikidata. The item can be linked from OpenStreetMap.

The German article that lists the street contains interesting information for someone who wants to know about Cicerostraße (Q30076706). It tells the reader that the street got it's name on 8. Jan. 1892 and is named after Johann Cicero while it was previously named Straße 41. It's useful for a reader who comes to Wikidata from OpenStreetMap to have the redirect to be able to continue to the German Wikipedia.

Whenever Wikidata has a higher resolution than Wikipedia, redirects are useful. Wikidata can have entries for all ICD illnesses but the individual Wikipedia often batch multiple ICD numbers together to a single article. It's useful to still have links from Wikidata to the Wikipedia article that describe the illnesses even when

Won't this cause the individual redirects to create more redirects than they currently do? Yes, it would and that's great. Having more redirects makes it easier for users to find what they are looking for. ChristianKl (talk) 11:14, 28 May 2017 (UTC)

This is a proxy for a more existential question[edit]

In truth, this question is really the surrogate for a broader question: To what extent is Wikidata a completely separate, standalone database project, and to what extent is Wikidata a support project for the other Wikimedia projects? Because make no mistake, there are aspects of both here. The former perspective is stated explicitly by User:Steak at this comment. The latter perspective is the one taken by those who feel that it's better to put a redirect link than no link at all.

To some extent, those two goals are partly conflicting goals. So what does one do about that? The principal reason I use Wikidata is to manage interwiki links. So I know what I want from this, and my !votes below reflect that. Truthfully, though, I don't much care how we get to this point, as long as we do get to the point. If it's done by "virtual sitelinks" as User:Succu suggests below, I'm ok with that. If it's done by allowing many-to-one sitelinks, as long as they're not redirects, I'm ok with that. If the latter in fact allows many-to-one-including-sections sitelinks, all the better. The truth is that the Wikipedias are not neatly in one-to-one correspondence, and a database serving them needs more flexibility than that. StevenJ81 (talk) 13:49, 30 May 2017 (UTC)

I think this question is largely orthogonal. To the extend that one wants Wikidata for the sake of Wikidata, redirects provide no negative effects. They provide some way to document notability of an item like fingerless glove (Q10700095) that had at the time I created it two label, one statement and one sitelink to a redirect. Without the sitelink it would have been flagged by our algorithms even through it's clearly notable (and the Wikipedia article has a paragraph on fingerless gloves). ChristianKl (talk) 18:06, 30 May 2017 (UTC)

Possible complaints that can be fixed with code[edit]

1) What happens with the other direction. How does a user get from Bonnie and Clyde (Q219937) to articles in a language that only have Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282) articles?

Possible technical solution: The existence of redirects would allow us to find the corresponding cases. We could create an automatically generated page that simply says: 'X Wikipedia has no entry for "label name in Wikidata in x-lang" but it has the article: "Article X" and "Article Y".

2) Won't the user get irritated when they click on a link and it's a redirect? Doesn't the user expect a direct link?

Possible technical solution: It's no problem to show an icon at the beginning of the line within Wikidata that signals to the user that a link is a redirect. → would be a suitable candidate. It can also be shown in the Wikipedia language list if that's desired in front of the language name. ChristianKl (talk) 11:14, 28 May 2017 (UTC)

3) Won't the existence of more redirects make merging harder?

We can rewrite the merging tool that if item A has a en-sitelink to a redirect and item B has a proper en-sitelink the tool doesn't throw an error and removes the redirect. ChristianKl (talk) 11:19, 29 May 2017 (UTC)

Voting for allowing creation[edit]

Wikidata should allow linking to redirects by default. ChristianKl (talk) 11:14, 28 May 2017 (UTC)

German Wikipedia has both entries for redirects and the article containing "science awards". Our best practice is to have separate items for awards so I created them. There are labels for the award in German, I removed them. The conferring organisation is a statement on the item for the award. The problem with this proposal is that it does not discuss the issues why either way. Personally redirects to a separate item is no real problem but all the other parts are. Thanks, GerardM (talk) 12:06, 28 May 2017 (UTC)
I find it hard to follow your description. It would be easier if you link to example items that you are talking about to follow the point that you are making. ChristianKl (talk) 12:57, 28 May 2017 (UTC)

As a note to those opposing this change, there are already a lot of links to redirects resulting from former content pages which have been redirected instead of deleted. I think if the existence of redirects in sitelinks is indeed unhelpful or confusing to readers then a new RfC should be made proposing the automatic removal of redirects from sitelinks. Jc86035 (talk) 11:58, 29 May 2017 (UTC)

At least in my case the same way I oppose to allowing redirects for sitelinks I agree on removing existing redirects from sitelinks, and probably everyone opposing to this RfC agree in the removal and everyone supporting this RfC would oppose to removing the existing redirects, so I don't see the point of creating another RfC for that -- Agabi10 (talk) 12:04, 29 May 2017 (UTC)

Support[edit]

  1. Symbol strong support vote.svg Strong support ChristianKl (talk) 21:49, 28 May 2017 (UTC)
  2. Symbol strong support vote.svg Strong support --Morten Haan (talk) 22:51, 28 May 2017 (UTC)
  3. Symbol support vote.svg Support, although it should be clarified that this proposal refers to sitelinks to redirects on other projects and not links to Wikidata redirects. Jc86035 (talk) 05:13, 29 May 2017 (UTC)
  4. Symbol support vote.svg Support Queryzo (talk) 06:31, 29 May 2017 (UTC)
  5. Symbol support vote.svg Support Viciarg (talk) 09:10, 29 May 2017 (UTC)
  6. Symbol support vote.svg Support --Coffins (talk) 11:12, 29 May 2017 (UTC)
  7. Symbol support vote.svg Support for two reasons. First, you can already do it now. It's just a pain in the neck, and it would be nice to make it easier. Second, the question of dealing with the resolution of different projects is really a legitimate question. Let me give an example. Consider Seventh day of Passover (Q3481993). hewiki, yiwiki and frwiki all have separate articles on the subject. Enwiki does not, but covers it in some detail within the larger article on Passover. The redirect there points directly to the section on the subject of the Seventh Day of Passover. So to the extent available within enwiki, it takes you to the best possible location in the project. I don't think that Wikidata has the right to insist to the other projects that they have to have an article on a given topic. And at the same time, I think it is more useful to make such a link available than not. I think it's a fair question how one would implement this, and I'd want such redirects to be as specific as possible, often to a section of the target page. But it's absolutely appropriate for such links to exist. StevenJ81 (talk) 17:24, 29 May 2017 (UTC)
  8. Symbol support vote.svg Support --Ptolusque (talk) 17:53, 29 May 2017 (UTC)
  9. Symbol strong support vote.svg Strong support This is vital if we want to comprehensively use Wikidata information in Wikipedia infoboxes. At the moment the absence of redirect information through Wikidata is a huge pain - thanks to the efforts of @RexxS we can auto-identify some redirects and add links to them as appropriate in enwp infoboxes, but not in a curated way that would systematically work across all infoboxes, and not in a cross-wiki way. Bonnie and Clyde is a cute example, but this goes much deeper than that. For example, see archaeologist (Q3621491) - which redirects to archaeology (Q23498) on enwp, but there's no evidence of that here - and the same applies across different occupations. Or for telescopes (my pet project for Wikidata infoboxes), it makes sense to have an entry for smaller telescopes here but on enwp they are often covered in the observatory article rather than having a separate one - and we just can't handle that here right now. Thanks. Mike Peel (talk) 22:10, 29 May 2017 (UTC)
    Why can't you use arbitrary links? That is their purpose.  — billinghurst sDrewth 22:53, 29 May 2017 (UTC)
    Because "arbitrary links" is just two words glued together with no context. Feel free to explain how I alter my generic Lua code to use "arbitrary links" in a generic infobox. Then I might be prepared to take your suggestion more seriously. --RexxS (talk) 23:22, 29 May 2017 (UTC)
    Well, it's not that hard. I don't know how generic your code is, but let's suppose that it works as a wrapper for {{#property:}}. Then you just have to add a parameter like "fallback-sitelink-property" which would take the id (or ids) of the properties where the sitelinks should be taken from. Let's take as an example the field of this occupation (P425) as bellow. Then if the linked property has a local sitelink you just use it. If it doesn't have a local sitelink you get the local sitelink of the fallback property chain until you find one or you finish the list. Repeat for all the occupations. -- Agabi10 (talk) 23:41, 29 May 2017 (UTC)
    The code is completely generic and you can see it at en:Module:WikidataIB. If it's not that hard, tell me what would the "fallback-sitelink-property" parameter be for educated at (P69)? or for work location (P937)? or for any of the dozens of other properties that have values where Wikidata has higher resolution than Wikipedia? A solution for occupation (P106) is possible only because of the coincidence that field of this occupation (P425) has been created. There's no such convenience for the vast majority of other properties where the lack of a link to a redirect causes problems. --RexxS (talk) 00:13, 30 May 2017 (UTC)
  10. Symbol support vote.svg Support: I am completely underwhelmed by the arguments of the opposers, which seem to fall into three categories: (1) "We do it this way, so no other way could be considered"; (2) "It's the wrong way" (no reason why it might be wrong; (3) "Our readers won't like it". Well, try to understand this: Wikidata provides a service, not a stand-alone resource. Its value is in how it can be used by other systems, such as Wikipedia and the sister projects, as well as third-parties. Think about it: how many people looking for information about Howard Carter would go to Howard Carter (Q133682) and how many would go to en:Howard Carter? The point of Wikidata is to make information programmatically available. At present I can auto-populate the infobox at en:Howard Carter from Wikidata with his citizenship, places of birth and death, and so on, all properly linked to the corresponding articles, but I can't directly link to his occupation because archaeologist (Q3621491) doesn't provide the calling code with a site-link to en:archaeologist, simply because Wikidata refuses to accept that the redirect to en:archaeology is a sensible convenience. How does that improve the usage of Wikidata for readers of the English Wikipedia? So the opposers are going to tell me that having a site link from archaeologist (Q3621491) to en:archaeologist is heresy, because a reader following that link would be astonished to find themselves at the article en:archaeology. What nonsense. Readers follow links labelled archeologist to the article on 'archeology' all the time, and there's not been one complaint demanding that enwiki create a separate article for archeologist. Forget about the direct use of inter-language links on Wikipedias; that's trivial compared to the potential for auto-creating content in smaller wikis that don't have the editor base to create articles at the rate that information is streaming into Wikidata. What about the potential for dynamically created lists? But if I write code to generate a list of 20th century anthropologists, I want Howard Carter's entry to have a link to an article that discusses his occupation as an Egyptologist (that would be en:Egyptology), but Wikidata refuses to allow egyptologist (Q1350189) to hold that link. What useful purpose does that serve? --RexxS (talk) 23:19, 29 May 2017 (UTC)
    That usecase is easily fixable by coding the template to take the sitelink of the item linked to field of this occupation (P425) for the occupation parameter of the template. That's hardly a reason to allow redirects to sitelinks and could be easily done with some Lua code today. And probably other cases could be also fixed similarly. Arbitrary access is very useful for things like that. -- Agabi10 (talk) 23:30, 29 May 2017 (UTC)
    No, it isn't easily fixed. I already have Lua code to fetch and link the value of any property for an entity, but you want me to check whether the call is looking for occupation and then fetch the field of this occupation (P425) of the entry for the value of that property. Sure, but that handles one case. How does it help me with fetching the work location (P937) of Jacques Benoit (Q29964516) when Wikidata has no link from University of Strasbourg (Q20808141) to the enwiki article en:University of Strasbourg? That's because Wikidata has two entities: University of Strasbourg (Q20808141) and University of Strasbourg (Q157575), and every language Wikipedia has just one. What about the hundreds of other cases where Wikidata has a higher resolution than the Wikipedias, but there's no indirect link like field of this occupation (P425)? --RexxS (talk) 00:02, 30 May 2017 (UTC)
    It's worthwhile to note that if you move more logic into the code of the template, page loading time will increase. Even when you can theoretically write code that handles all edge cases of the template, it will make Wikipedia slower for it's users. ChristianKl (talk) 08:43, 30 May 2017 (UTC)
    The idea would be setting the fallback chain in the fields in en:Template:Infobox book/Wikidata/Sandbox, where the parameter is specified, so it wouldn't move too many logic into the template code. And Wikipedias use many layers of caching, so it would be unnoticeable for readers, it would affect at most editing the articles, and I doubt the effect would be noticeable in most of the cases. -- Agabi10 (talk) 10:08, 30 May 2017 (UTC)
    And what would the fallback chain be for work location (P937) or educated at (P69) or any of the other fields used in infoboxes? Solving a single example =/= solving the problem. --RexxS (talk) 20:14, 30 May 2017 (UTC)
  11. GA candidate.svg Weak support in principle. Though #Possible complaints that can be fixed with code is really vital for this. They should not appear in the data model or the user interface here or on other projects as sitelinks but as "redirect links". It's bad that the currently existing "redirects links" are not recognizable as such.
    Another domain where this could bring more consistency are instance of (P31):Wikimedia disambiguation page (Q4167410) items. "The item should only contain links to Wikipedia disambiguation pages with the exact same spelling" (Wikidata:WikiProject Disambiguation pages/guidelines) is simply not expedient to applicate in many cases at the moment. But with redirects it could be applicated. --Marsupium (talk) 23:40, 29 May 2017 (UTC), 00:34, 30 May 2017 (UTC)
  12. Symbol strong support vote.svg Strong support --Jbergner (talk) 06:44, 30 May 2017 (UTC)
  13. Symbol strong support vote.svg Strong support per my comment on the related Phabricator task. Many entities in wikidata will never have a full wikipedia pages but will be described quite extensively within another one. Toto256 (talk) 09:19, 30 May 2017 (UTC)
  14. Symbol support vote.svg Support Such sitelinks already exist; indeed there is even a template, Template:Wikidata redirect (Q16956589), with equivalents in 8 languages, to tag the redirects that are the targets of such sitelinks. The ability to make such sitelinks doesn't harm or affect Wikidata at all; however it is of value for interwiki, to help people click through from a foreign-language wikipedia to where a topic is treated in their own language. The one thing I think would be useful, however, would be to mark such links-to-redirects with a badge, so that (i) they can be easily queried for; and (ii) the fact that they are sitelinks to redirects can be visibly indicated on the interwiki. Jheald (talk) 11:05, 30 May 2017 (UTC)
  15. Symbol strong support vote.svg Strong support  TRN 3.svg • hugarheimur 13:10, 30 May 2017 (UTC)
  16. Symbol strong support vote.svg Strong support The blockade of large parts of the Wikidata community against denies the needs of the different language variants of Wikipedia concerning Interwikis. Not every Redirect is equal to an article, many direct to a subtopic which often has its own article in other languages. If a distinction between this types of redirect is needed, there already was propoes da magic word for that. --MGChecker (talk) 15:33, 30 May 2017 (UTC)
  17. Symbol strong support vote.svg Strong support however as I noted above NOT because of the Bonnie and Clyde issue. Allowing linking from wikidata to redirects has the potential to make every wikidata item more useful by pointing to the "best match" article in a given language wikipedia for that concept or entity. I don't understand people advocating for removal of useful links. The existence of a redirect implies either that there once was an article with that label in the given language, or that people using that language at least find that label to be something commonly queried on and so it is useful to point people to an actual page that is closely related. So there's some real-world existence of that label represented by the redirect for which it is useful to have a pointer from wikidata. Now perhaps these should be handled differently than standard "sitelinks" in some way - there seem to be various suggestions here on how that could be done. ArthurPSmith (talk) 17:34, 30 May 2017 (UTC)
  18. Symbol support vote.svg Support. Per Arthur Smith et al. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:16, 30 May 2017 (UTC)
  19. Symbol support vote.svg Support --Ghilt (talk) 19:34, 30 May 2017 (UTC) imho it's good to have redirects to subsections linked, which may never get their own article
  20. GA candidate.svg Weak support I want to add that a redirect link alone should not be counted as a valid link in the sence of notability. Redirects at various wiki's may indeed be created because of various reasons, including frequently encountered typo's, which would add a lot of not very interesting duplicate items here. So, please, no bot imports... However, if there are already valid sitelinks or if an item is notable even without sitelinks, I don't see objection to linked redirects. And for that it might be an idea to allow creation. Lymantria (talk) 20:35, 30 May 2017 (UTC)
    I'm not claiming that redirects by themselves demonstrate notability via notability criteria (1) but it's quite often necessary to research a concept to see whether it's notable. If you have a redirect that makes the research about whether the item is notable a lot easier. Given that we have a deletion backlog of items that are worthy to delete it's also useful to focus our automated efforts on items that are very clearly not notable. ChristianKl (talk) 21:06, 30 May 2017 (UTC)
  21. Symbol support vote.svg Support --Labant (talk) 22:18, 30 May 2017 (UTC)
  22. Symbol support vote.svg Support Gz260 (talk) 08:47, 31 May 2017 (UTC)
  23. Symbol strong support vote.svg Strong support, redirects can be marked by badge. And there are already redirects (merged to bigger article) with categories like 1924 borns or German musicians. On Wikipedias can be linked redirects marked - some tracking category. JAn Dudík (talk) 11:18, 31 May 2017 (UTC)
  24. Symbol strong support vote.svg Strong support, taking a recent situation for example: I read on enwiki about kinematic viscosity, then went to frwiki to read about it, but was surprised to find out frwiki did not feature an interwiki link to enwiki. I thus set out to fix that but Wikidata wouldn't allow me to link fr:Viscosité kinématique and en:Kinematic viscosity, which is plain old dumb -- frwiki should not give the impression that this topic is not covered on enwiki because it is, and not having an interwiki link between the two is detrimental for readers. So I had to unredirect temporarily the enwiki title, add the Wikidata interwiki linkage, then redirect the enwiki title. See how stupid this is? Salvidrim! (talk) 13:25, 31 May 2017 (UTC)
  25. Symbol support vote.svg Support per ArthurPSmith. Nikkimaria (talk) 00:42, 1 June 2017 (UTC)
  26. Symbol strong support vote.svg Strong support, this is a very useful service for Wikipedias, both for links to other language versions, and for generated links in infoboxes. I cannot see any real disadvantages. --Dipsacus fullonum (talk) 07:36, 1 June 2017 (UTC)
  27. Symbol strong support vote.svg Strong support --Dipsode87 (talk) 13:57, 1 June 2017 (UTC)
  28. Symbol strong support vote.svg Strong support Richard Nevell (WMUK) (talk) 16:56, 1 June 2017 (UTC)
  29. Symbol support vote.svg Support --CENNOXX (talk) 11:06, 2 June 2017 (UTC)
  30. Symbol strong support vote.svg Strong support Wikidatas main job for what it was created is to support Wikipedia with interwikies. If interwikies to redirects (or subsections of other articles) are needed outside wikidata that is against the purpose. That links to sections might be problematic from a technical point I understand, for redirects I don't understand it. In fact redirects would be a workaround to provide interwikies to sections. --Fano (talk) 11:25, 2 June 2017 (UTC)
  31. Symbol strong support vote.svg Strong support --Mauerquadrant (talk) 12:25, 2 June 2017 (UTC)
  32. Symbol support vote.svg Support For example, w:en:Farm to Market Road 289. --Rschen7754 07:00, 3 June 2017 (UTC)
  33. Symbol strong support vote.svg Strong support About frigging time. However this is dealt with behind the scenes, it's a frigging nightmare for a typical user, simply to preserve some ideal purity that few others care about. Make it simple for the user, and clean up any philosophical issues behind the scenes, somehow. Nfitz (talk) 16:42, 3 June 2017 (UTC)
  34. Symbol strong support vote.svg Strong support I have seen this problem happen so many times with things like multiple games created by a common company that are grouped together in one article. It should be where if you click on a redirect Wikipedia link it should redrict you once you get there. PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 02:07, 4 June 2017 (UTC)
  35. Symbol support vote.svg Support Could be extremely useful. All the best: Rich Farmbrough08:37, 5 June 2017 (UTC).
  36. GA candidate.svg Weak support Not happy about it implications but probably the best solution existing. -- MichaelSchoenitzer (talk) 12:53, 5 June 2017 (UTC)
  37. Symbol strong support vote.svg Strong support Form Follows Function (i.e. content) VINCENZO1492 18:24, 6 June 2017 (UTC)
  38. Symbol strong support vote.svg Strong support: I really do see the reason that this isn't allowed, and was tempted to oppose, but in the end I agree with the function before form argument. Does it really matter whether the data item has its own article, or a section on another one? I think the benefits outweigh the loss of clarity with the data. Laurdecl talk 08:46, 9 June 2017 (UTC)
  39. Symbol strong support vote.svg Strong support Replacing the earlier (clumsy but working) system of interwiki linking was one of the main promises on which Wikidata was sold to the 'pedia communities. Placing arbitratry limitations on which articles can be added to the interwiki graph would break that promise. --Tgr (talk) 21:20, 11 June 2017 (UTC)
  40. Symbol strong support vote.svg Strong support --RolandUnger (talk) 07:45, 14 June 2017 (UTC)
  41. Symbol support vote.svg Support I can't say that I fully understand the consequences, but I am always in favor of allowing more flexible ways of linking wikipedia articles for the benefit of the users. And allowing links to redirects would absolutely allow for the creation of links between articles in different languages that so far could not be linked directly because of differences in the structure of multiple articles on a certain subject (i.e. the said Bonny and Clyde problem). With the replacement of direct Inter-Wikipedia links by Wikidata entries linking became less flexible. And this proposal would provide a way to recover some of the possibilties that were lost. --KaiKemmann (talk) 23:54, 16 June 2017 (UTC)
  42. Symbol strong support vote.svg Strong support At present, the list of linked Wikipedia articles in Wikidata is showing the lemma of the target article instead of the redirect lemma, i. e. an article belonging to a completely different Wikidata entry; and what's even worse, the redirect in Wikipedia gets a "Wikidata entry not found" label and cannot be linked to the correct Wikidata entry, though this entry definitely exists. This makes not only correct interwiki linking impossible, but also correct association of (redirect) articles with Wikidata entries. This is a fundamental bug in the construction of Wikidata and should be addressed speedily. --Jossi (talk) 10:08, 22 June 2017 (UTC)
  43. Symbol support vote.svg Support This would also solve the hatmaker/hatmaking problem—where different Wikipedias use a different conceptual ontology for covering the same information. Kaldari (talk) 00:29, 4 July 2017 (UTC)
  44. Symbol support vote.svg Support In my opinion the advantages outweigh the disadvantages.--Wdwd (talk) 19:17, 5 July 2017 (UTC)
  45. Symbol support vote.svg Support There are several fields in which certain objects (e.g. roads) are represented as separate articles on one wiki but as part of a list on another. Allowing a redirect as a sitelink would allow the wiki with the distinct article to link to the wiki with the list, using a redirect to the list as the link. I'd caution against the reverse (linking to the distinct article from the list), though. -happy5214 22:58, 8 July 2017 (UTC)
  46. Symbol strong support vote.svg Strong support Badly needed! --Quarz (talk) 17:44, 9 July 2017 (UTC)
  47. Pictogram voting comment.svg Comment I agree with Brya that we should be able to filter them out or mark them using different color. Maybe we need WD->WD redirects separate from new redirects. d1g (talk) 09:07, 11 July 2017 (UTC)
  48. Symbol support vote.svg Support This is a way to solve some problems. Yes to allow the creation of links to redirects to WD, but certainly No to create items for all redirects.--Jklamo (talk) 09:16, 11 July 2017 (UTC)
  49. Symbol support vote.svg Support but only if the redirect page contains a specific magic word.--GZWDer (talk) 10:05, 11 July 2017 (UTC)
  50. Symbol support vote.svg Support --Steenth (talk) 18:43, 19 July 2017 (UTC)
  51. Symbol support vote.svg Support --Jojhnjoy (talk) 15:47, 4 August 2017 (UTC)
  52. Symbol strong support vote.svg Strong support The interwiki system is basically broken without this. --YMS (talk) 12:13, 9 August 2017 (UTC)
  53. Symbol support vote.svg Support While I agree, that links to redirects should be identifiable (similarly to featured articles, etc), all in all the advantages outweigh the disadvantages. --MB-one (talk) 15:26, 10 August 2017 (UTC)
  54. Symbol support vote.svg Support I wanted this four years ago (Wikidata:Requests for comment/A need for a resolution regarding article moves and redirects), and my stance has not changed. Steel1943 (talk) 23:09, 11 August 2017 (UTC)
  55. Symbol support vote.svg Support Agathoclea (talk) 16:23, 13 August 2017 (UTC)
  56. Symbol strong support vote.svg Strong support I just ran across three cases of this problem - paper plates, disposable cutltery, and kitty litter. Each of them is a redirect in English Wikipedia. Not being able to link to these redirect (and not being able to have links with fragment ids) means that any information in Wikdata about these is divorced from their dicussion in English Wikipedia - I horrible outcome as far as I am concerned. Peter F. Patel-Schneider (talk)
  57. GA candidate.svg Weak support I strongly support the cause of reducing the unavoidable granularity (resolution) gaps between Wikidata/Wikipedias/other projects. The close connection to Wikipedias has been incredibly useful to start and grow Wikidata, and we should keep it strong. Nevertheless, I am open regarding the technical solution chosen. Allowing sitelinks to have section anchors (fragments) seems to be a slightly more attractive approach that gives Wikidata more control (e.g., this would address the concerns that redirects on Wikipedia change too often and we would not notice). On the other hand, after thinking about concrete cases, I have doubts regarding the "virtual sitelinks" idea brought up by User:Succu: it seems very topic-dependent what type of property would lead to a reasonable "virtual sitelink" and there might be confusingly many (e.g., consider the relation of "Homer Simpson" to "The Simpsons" -- surely not "part of", but there might also be a "part of" link to something else). So, given what I heard so far, my preference order would be: "sitelinks with fragments" (possibly with automatic mechanisms to check if the anchor still exists in the target page) > "sitelinks to redirects" > "virtual sitelinks". But I remain convinced that solving this problem can help both Wikipedia & Wikidata readers (by adding meaningful links where we have nothing now) and Wikipedia & Wikidata editors (by helping them to discover related information on Wikipedia even when there is no dedicated article). Overall, it will improve coherence. The use of fragments would make it easier to filter "real sitelinks" from "section sitelinks", so this useful functionality should be preserved. --Markus Krötzsch (talk) 06:03, 22 August 2017 (UTC)
  58. Symbol strong support vote.svg Strong support --Mauerquadrant (talk) 05:37, 25 August 2017 (UTC)
  59. Symbol strong support vote.svg Strong support. As a Wikisource editor, I see this as an elegant solution to the problem of works vs. editions. If English Wikisource has only one edition of a work, it is common practice to create a redirect from the work page to the edition page, e.g. from s:Ave verum corpus to s:Catholic Hymns (1860)/Hail to Thee, true Body. Per established consensus, the Wikidata item Ave verum corpus should be linked to the work page at s:Ave verum corpus, and NOT to the edition page at s:Catholic Hymns (1860)/Hail to Thee, true Body. Allowing Wikidata to link to a redirect will resolve this issue nicely. Beleg Tâl (talk) 13:15, 28 August 2017 (UTC)
  60. Symbol strong support vote.svg Strong support --Sänger (talk) 13:22, 15 September 2017 (UTC) I was just denied such a useful link today, and as I remembered reading something about it in the de:Vorlage:Beteiligen, I got here, and fail to see any real problem with allowing it.
  61. Symbol support vote.svg Support --Agentjoerg (talk) 10:16, 16 September 2017 (UTC)

Against[edit]

  1. Symbol oppose vote.svg Oppose - Oh my god, hell NO! What a terrible idea! The good thing with Wikidata is, it's clear here. Not mixing up things. Bonny, Clyde and Bonny & Clyde are three different things. And the street problem is not a problem. Sorry for the clear words, but for me this is a nonsense request. Marcus Cyron (talk) 22:36, 28 May 2017 (UTC)
    this proposal doesn't involve wikidata "mixing up things". There would still be 3 distinct wikidata entities in the example case, each well-defined. Why do you think "mixing up things" is what is being proposed? ArthurPSmith (talk) 17:54, 30 May 2017 (UTC)
  2. Symbol oppose vote.svg Oppose per my comment on the related Phabricator task. If linking to similar entities is wanted by the Wikipedias there are other alternatives like creating a gadget that would display sitelinks to items linked to specific properties like has part (P527) and part of (P361) in the sidebar indicating to which entity they are linking instead of having articles linking to redirects. At least that way the reader will know where they are going and both articles will be linked with each other instead of being linked only from the more specific to the more general one. -- Agabi10 (talk) 23:03, 28 May 2017 (UTC)
  3. Symbol oppose vote.svg Oppose We connect articles uniquely. Connecting articles with redirects would undermine this. If Bonnie Parker has no interwiki link to en:wp, so what? Since our notability criteria are not limited to items having an interwiki link, there is no need to artificially add an interwiki link. Steak (talk) 07:29, 29 May 2017 (UTC)
  4. Symbol oppose vote.svg Oppose creates confusing situations for readers. Sjoerd de Bruin (talk) 08:42, 29 May 2017 (UTC)
  5. Symbol oppose vote.svg Oppose Ich schließe mich da ganz Marcus Cyron an. --Mogelzahn (talk) 12:17, 29 May 2017 (UTC)
  6. Symbol oppose vote.svg Oppose, no please. I hate clicking on sitelinks and then seeing that it's actually a redirect. I have removed links on Wikidata which are redirects as redirects should not be used as sitelinks. Stryn (talk) 16:18, 29 May 2017 (UTC)
  7. Symbol oppose vote.svg Oppose:What we really need is a feature I call virtual sitelinks, sitelinks that do not physically exist (as a true link) but are based on certain relations modeled within Wikidata. --Succu (talk) 18:11, 29 May 2017 (UTC)
  8. Symbol oppose vote.svg Oppose: „A=A” and „a=a” and not „A=A or a or á or å”. The MC has damn´d right. --Hannes 24 (talk) 19:41, 29 May 2017 (UTC)
  9. Symbol oppose vote.svg Oppose --Metrónomo (talk) 20:35, 29 May 2017 (UTC)
  10. Symbol oppose vote.svg Oppose -- at a practical level redirects are too easily changed, to either be a disambiguation page, or to point somewhere else; and that makes wikidata wrong; too hard to manage and to check. At a theoretical level, we should not making the assumptions or forcing round pegs in square holes. Bonnie and Clyde has two parts, but Bonnie nor Clyde are the people with a whole lot of different meta data, not the articles Bonnie and Clyde, completely agree with Marcus Cyron (talkcontribslogs). We are not about massaging items to fit articles, or the wikipedias.  — billinghurst sDrewth 22:11, 29 May 2017 (UTC)
    @billinghurst, Marcus Cyron: I'm struggling to understand your arguments here. From my perspective, it helps the Wikipedias if redirects are tracked in a structured way, and it helps Wikidata to point to the relevant piece of text in the Wikipedias where they aren't stand-alone in a separate article, or if the concept is covered in a more general article. Changes can be tracked by a bot if needed - and potentially problematic changes could be flagged. But I can't see an argument against having Wikidata say "you can find information about this topic in this part of this Wikipedia article", or "this topic is covered in this general article on the subject". Surely we're adding useful information here? Thanks. Mike Peel (talk) 22:30, 29 May 2017 (UTC)
    Redirects are not articles. So we not use them as those. At Wikidata we can have pages for every detail - and these pages are linked. More is not needed. It would cause a big chaos, to link from articles to redirects to articles. If there's no artikel - there's no article. Marcus Cyron (talk) 15:32, 30 May 2017 (UTC)
    We're not adding any useful information, we are repeating the information that already is in Wikidata. The entities of these elements are already linked to the entity without the need of adding a sitelink redirect. Additionally, in Wikipedia the elements are not really linked. In an example in which B is part of A, if the sitelink redirects you to another page then you can go from en:B to es:A (through a redirect), but if you try to go from es:A to en:B it will be impossible. One of the good things of Wikidata's sitelink management is that you can go through languages you know to get more information, but allowing redirects prevents you from doing that, just because one of the Wikipedias decided that they want to redirect to a page about a more generic concept instead of to the one the reader is trying to get more information about. As I said before this could be fixed with a gadget adding sitelinks to related articles better and more consistently than adding trap-redirect-sitelinks. -- Agabi10 (talk) 23:15, 29 May 2017 (UTC)
    Yes we are adding useful information, because it would allow readers to follow an infobox link (for example) to an article about a subject's occupation, regardless of whether that occupation were a stand-alone article or a section of a larger article. What's not useful about that? If you were able to go from it:Archeologo to en:Archaeologist (a redirect), it would take you to en:Archaeology, but there would be a hatnote (Redirected from Archaeologist) and following that link would take you back to the redirect, where you would find the inter-language links to take you back to it:Archeologo. Try it starting from it:Teologo if you don't believe me. "Impossible", eh? --RexxS (talk) 23:39, 29 May 2017 (UTC)
    @Agabi10, Marcus Cyron: In addition to what RexxS says, let me give you a concrete example where data is added to Wikidata. Transit Telescope (Q3546483) has a French Wikipedia article, but not an enwp article - en:Transit Telescope is a redirect to en:Jodrell_Bank_Observatory#Transit_Telescope, which has a reasonable amount of info about the telescope (but not enough to justify a separate article at the moment). If we can't link to the redirect from Wikidata, how can we point people towards that information? Thanks. Mike Peel (talk) 20:25, 30 May 2017 (UTC)
    Why you think, we must do this? I don't think, we have to do so. A redirect is an article we don't have. So we should not act as we would have this article. So such articles never come. To use redirects in such a manner would mean, we fake. We betray readers. Marcus Cyron (talk) 10:06, 31 May 2017 (UTC)
    The redirect to the en:Jodrell_Bank_Observatory#Transit_Telescope doesn't prevent the creation of a separate article about the transit telescope. It might even make it easier because a user who wants to create such an article can simply copy-paste the existing information from the existing article as a basis for his new article. In many cases there are also notability issues with creating a new article. The fact that a topic is notable enough to warrant it's own paragraph doesn't mean it can get it's own article. ChristianKl (talk) 15:50, 2 June 2017 (UTC)
  11. Symbol oppose vote.svg Oppose per Stryn. Mahir256 (talk) 23:25, 29 May 2017 (UTC)
  12. Symbol oppose vote.svg Oppose. Redirects can have very different semantics. Better create different Wikidata items and link them with appropriate statements. --UV (talk) 14:19, 30 May 2017 (UTC)
  13. Symbol oppose vote.svg Oppose redirects as sitelinks. We need to find a solution for the Bonnie & Clyde problem, but this ain’t one. —MisterSynergy (talk) 16:54, 30 May 2017 (UTC)
  14. Symbol oppose vote.svg Oppose --Hubertl (talk) 17:35, 30 May 2017 (UTC)
  15. Symbol oppose vote oversat.svg Strong oppose – When we started with Wikidata one benefit was getting rid off all the interwiki conflicts. Hell no, please not introduce them through the backyard again. Keep each topic one item. --Matthiasb (talk) 18:58, 30 May 2017 (UTC) BTW: I consider B&C as a feature, not as a problem.
  16. Symbol oppose vote.svg Oppose better invest time and money into developping an extension/a gadget which provides to the reader some additional sitelinks based on part of (P361), has part (P527) etc. --Pasleim (talk) 19:35, 30 May 2017 (UTC)
  17. Symbol oppose vote.svg Oppose --Holder (talk) 03:47, 31 May 2017 (UTC)
  18. Symbol oppose vote.svg Oppose per Agabi10 --HHill (talk) 19:46, 31 May 2017 (UTC)
  19. Symbol oppose vote oversat.svg Strong oppose. FYI in last months I've removed hundreds of sitelinks to redirected templates in several major Wikipedias. By result of this action many items became eligible for merging here on Wikidata, and I've merged those items. Also, I've removed (by) tens of sitelinks which are redirects to disambiguation pages in several Wikipedias. Also, by result of this action it became possible to merge several items as well. Another point: in past, as an established WP editor I focused my attention and activity on writting new articles, and frequently I used Wikidata (generally interwikis) to know if an article is missing in my WP; thus if in a WD item was connected a redirect from my local wiki - it just confused me letting me think that we have an article about that subject, but actually it just misled me. Allowing and encouraging introducing sitelinks to redirects in Wikidata items will just increase the amount of maintenance work necessary to do, without major benefits. XXN, 20:31, 31 May 2017 (UTC)
    If your concern is getting confused by the fact that a link is shown that can be solved by marking the redirects with a badge. The merging tool can also be configured in a way to merge even when redirects exist. ChristianKl (talk) 11:28, 1 June 2017 (UTC)
    "Mergeing several items" is not necessarily a good thing. Indeed i would argue for more discrimination. All the best: Rich Farmbrough08:34, 5 June 2017 (UTC).
  20. Symbol oppose vote.svg Oppose too Trumpization, it's much more sense to consider solutions of Phabricator T54971 - Sitelinks to Incubator, OldWikisource and BetaWikiversity to be applied to all WMF wikis. And such implementation may also introduce problems with VisualEditor. --Liuxinyu970226 (talk) 04:47, 3 June 2017 (UTC)
    Why do you see problems with VisualEditor? Can you be more specific about the problems you imagine? ChristianKl (talk) 09:22, 3 June 2017 (UTC)
  21. Symbol oppose vote.svg Oppose Miodzio3 (talk) 16:14, 5 June 2017 (UTC)
  22. Symbol oppose vote oversat.svg Strong oppose --Smaug the Golden (talk - contributions - logs) 18:19, 9 June 2017 (UTC)
  23. Symbol oppose vote.svg Oppose. MechQuester (talk) 14:11, 22 June 2017 (UTC)
  24. Symbol oppose vote.svg Oppose as long as redirects are not immediately recognizable (like in a different font), the inclusion of redirects will make editing a lot harder. - Brya (talk) 16:38, 22 June 2017 (UTC)
  25. Symbol oppose vote.svg Oppose  @xqt 14:23, 4 July 2017 (UTC)
  26. Symbol oppose vote.svg Oppose --Senechthon (talk) 07:59, 8 July 2017 (UTC)
  27. Symbol oppose vote.svg Oppose we will have millions of fake sitelinks. --Mr. Ibrahem (talk) 22:22, 20 July 2017 (UTC)
    @Mr. Ibrahem: Citation needed - see the table of redirect numbers further down the page. Also, why are these fake if they are pointing to useful info? Thanks. Mike Peel (talk) 23:12, 20 July 2017 (UTC)
  28. Symbol oppose vote.svg Oppose I am not sure that a link to a redirect is a good approach. This would have the characteristics of a quick patch or hack to get links. However, Agabi10 pointed already out that we have has part (P527) and part of (P361). These relationships could be exploited to provide virtual links as proposed by Succu. --AFBorchert (talk) 11:50, 3 August 2017 (UTC)
  29. # Symbol oppose vote.svg Oppose -- MovieFex (talk) 15:03, 3 August 2017 (UTC)

Neutral[edit]

  1. Symbol neutral vote.svg Neutral moving away from a data model that is primarily linked to Wikipedia articles to one that develops on Wikidata may be an excellent opportunity for Wikidata growth and development of new Wikibase software features.
    --- Jura 07:20, 24 July 2017 (UTC)
  2. Symbol neutral vote.svg Neutral for technical reasons: allowing sitelinks to redirects will take away checks that are currently in place to avoid creation of duplicate items. I will support this proposal if it comes with a technical solution that throws up a warning when somebody tries to link to a redirect and makes the user confirm they don't mean to link to the redirect target. Deryck Chan (talk) 22:44, 16 September 2017 (UTC)

Related questions[edit]

How many duplicates have you merged recently?[edit]

  1. Pictogram voting comment.svg Comment too many. 3+ yesterday.
    --- Jura 10:31, 29 May 2017 (UTC)
I also merged more than 3 duplicates today. I don't have a good count on how many I merge per month. ChristianKl (talk) 11:22, 29 May 2017 (UTC)
  1. Pictogram voting comment.svg Comment About 3 a day during last month (91 in total). --Epìdosis 10:19, 2 June 2017 (UTC)
  2. 1~10 times per week before 20 May, currently inactive due to real life stuffs. --Liuxinyu970226 (talk) 04:49, 3 June 2017 (UTC)

How to do maintenance on items linking to the same article through a sitelink and (1 or several) redirects?[edit]

  1. Pictogram voting comment.svg Comment If we allow several ways to link to the same article, we need to find a better way to maintain such duplicate links. Otherwise we end up with even more items about the same topic.
    --- Jura 05:10, 31 May 2017 (UTC)


Should we drop the assumption that sitelinks lead to articles about a topic?[edit]

  1. Pictogram voting comment.svg Comment if we allow redirects, many uses that build on that assumption will end up breaking. I don't think we want that.
    --- Jura 05:10, 31 May 2017 (UTC)
I think the reader should have the assumption that he will find information about the topic of the sitelink at the article towards which the sitelink points. I don't think there needs to be an assumption that all the information in the linked article is about the same topic. Even without redirects articles in different languages have different scope, so there isn't a 1-to-1 match anyways. ChristianKl (talk) 09:09, 31 May 2017 (UTC)
  • I'm wondering: if there are 10k of items about random books/songs/paintings considered non-notable for Wikipedia, and if in several Wikipedias they will have redirects (to related subjects) for them, do you consider necessary to connect all these redirects in Wikidata items? In what consists their usefulness in such case?
Moreover, there are too many homonymous works in our world, and the target of a redirect in Wikipedia may be changed in time (assuming that they does not create disambigs for missing articles, things with unproven notability), so how will look our items mixing a number of pages (redirects in Wikipedia) about different concepts? Who will verify and maintain tons of sitelinks to redirects potentially connected in wrong items, if the Wikipedians generally will don't care about them? --XXN, 14:40, 1 June 2017 (UTC)
I don't think that every redirect has to be connected to a Wikidata item. I don't think that enabling the ability of linking to redirects will lead to every Wikipedia redirect being connected to a Wikidata item. If a particular Wikidata link to a redirect doesn't go to a useful target, it can be removed. The decision can be made on the merit of each individual redirect. ChristianKl (talk) 15:03, 1 June 2017 (UTC)
I have to admit that I never considered for a moment that people would start adding such redirects to Wikidata items that have no independent articles on any Wikipedia (or whatever) project. That I don't favor. I'm mainly interested in preserving redirects in cases where independent articles do exist on one or more wikis, while other wikis incorporate the topic in a material way within an article of greater scope.

Discussion[edit]

Other problems caused by/related to redirects
Other such cases, plus few more diverse ones (related to other wikis as well) I've found and fixed in past - but is only a drop in sea/ocean.
So, is there any volunteer who plans to spend a good amount of time on maintenance of items with redirects, analyzing individually each item and redirect? XXN, 23:20, 1 June 2017 (UTC)
I don't see how items like no label (Q16633690) and no label (Q16109704) need more significantly more volunteer labor to be maintained because they have a redirect. Especially if we change the UI to make it clear that the links are indeed redirects. The proposed solution would make it even easier to automatically generate a list of all items with one label, a redirect link, and no statements. ChristianKl (talk) 09:33, 2 June 2017 (UTC)
@ChristianKl: if redirects will be allowed in WD, such sitelinks will be considered ~notable by default, or better said - protected by policies, and they couldn't be removed without an individual human analyzis. On the other hand if we don't allow redirects in WD, in such cases when items are ~completely empty with the exception of existing sitelink, these redirects can be removed without any review even using bots if it is the only sitelink, and then the ~empty item can be merged (also by that bot) into the item of redirect's target page in wiki. --XXN, 09:19, 10 June 2017 (UTC)
I don't think that items should be in general be deleted human analysis. If we believe that it's good to delete items without statements that only contain a sitelink we are free to write a policy that legitimizes a bot that deletes such items. I believe that in most cases a person who manually adds a redirect link will also add other statements and the item gets enough human attention so that it shouldn't be deleted without human review. ChristianKl (talk) 17:08, 10 June 2017 (UTC)
Protecting our data model

At the moment there's a conflict on our Admin board because of whether the Amharic items for tomato should be linked to the Wikidata item for the taxon or the fruit. The Amharic editor wants it to be linked with the taxon to have more interwiki links. This very day I also had to undo an edit by a Spanish user who moved "Articulación de la rodilla" from it's proper place knee joint (Q28792803) to knee (Q37425), presumably to have more interwiki links. To the extent that we want to have a data model that is able distinguish a fruit from a taxon or knee joint (Q28792803) to knee (Q37425), it's very helpful to have links to redirects. I don't see any reason to want to enforce 1-to-1 relationships when there are clearly multiple items that conceptualy map to a given article. ChristianKl (talk) 15:35, 2 June 2017 (UTC)

many redirects MUST NOT be changed 

this is also a very nice example of redirects that should not be changed for direct link :( --Hsarrazin (talk) 10:58, 5 June 2017 (UTC)

I don't think that one was changed on purpose, and regardless of the outcome of this RfC that link would be changed anyway. At least for what I see it seams that it was changed due to a page move on enwiki. --Agabi10 (talk) 11:06, 5 June 2017 (UTC)
The redirect would be changed automatically but the issue would be fixable if we could recreate the redirect. ChristianKl (talk) 11:27, 5 June 2017 (UTC)
Amount of work needed

So anyone works currently/periodically on items of redirects? How many items with redirects have you improved recently / over time? I would ask you (especially those who supports redirects in WD) to take a look at the report of items without claims by categories: on enwiki - as of 20 July we have over 4500 items without any single claim connected to enwiki redirects. XXN, 18:28, 20 July 2017 (UTC)

Why do you think work about items without claims is about manually added redirects? If I add manual created redirects to an item I generally also add other claims. ChristianKl (talk) 18:34, 20 July 2017 (UTC)
I see this RFC more generic - to accept or not redirects in Wikidata. And the problem I raised above is that accepting redirects in WD will automatically grant some kind of notability to any almost empty item with only a single redirect, and people will have to waste their time checking carefully each item, then its linked redirects and their targets, and then maybe searching on web, and only after this they could go to RFD requesting deletion of such an item. But if we don't consider automatically an item with a single redirect notable by itself, then after an controlled mass-removal of redirected sitelinks from such items they become empty - we can mass delete them. But what we have currently is thousands of junk items not easily accesible and detectable. XXN, 19:17, 20 July 2017 (UTC)
XXN sorry I followed your link to the claim of "over 4500 items without any single claim connected to enwiki redirects" and I could not actually find an example from that page. Do you have something specific? The ones I looked at either (A) did not appear to have wikidata items at all for those redirects, or (B) were clearly independent legitimate items and many of those actually had claims in wikidata. Is there some delay in that report and things are actually being cleaned up quickly? Or maybe that page is not actually listing what it says it's listing? ArthurPSmith (talk) 20:27, 20 July 2017 (UTC)
@ArthurPSmith: seems that it's necessary to manually enable option "redirects" in the second petscan tab (Page properties) and to re-run query. E.g. this query will return a list of over 1000 items with en.wiki redirects. XXN, 20:39, 20 July 2017 (UTC)
Whether or not an item without any claims but a single redirect should be notable is a question that can be debated on it's own. Writing a bot that periodically removes redirect sitelinks isn't much less work than writing a bot that puts all items without any claims and only redirect sitelinks into a special list or even a bot that deletes them directly. ChristianKl (talk) 21:10, 20 July 2017 (UTC)
XXN well that looks quite manageable then. I limited the search to redirects created in the last 5 days, and found only 5 items; 4 of which appeared to be to me legitimate separate entities to which I added relevant statements, and the last of which looked like it did not deserve its own item and I merged it with the item it was redirected to in enwiki. If that 1/day and 20% invalid rate is typical I can't see it as a huge issue. We have far too many regular items that don't have any statements as it is, this seems a very small piece of the problem. ArthurPSmith (talk) 21:15, 20 July 2017 (UTC)

Removing existing links[edit]

In case the first proposed policy fails, an alternative policy to allowing the creation of redirect links would be to decide completely against having redirect links and have a bot that regularly deletes them. The makes the second thesis "A bot should remove existing sitelinks to redirect pages at regular intervals"

Support removing existing links[edit]

  1. Symbol support vote.svg Support Steak (talk) 08:26, 30 May 2017 (UTC) Including redirects destroys the 1-to-1-correspondence between the articles. We have definitely much less strict rules regarding our own database links (= links to wikipedia articles) compared to links to other databases (where for every property constraint violation lists exist that ensure uniqueness and single-valuedness). I don't see a reason why this should not also apply to interwiki-links. Wikidata wants to be a self-standing database, not an appendix of wikipedia, so we should be consistent there.
  2. Symbol support vote.svg Support -- Agabi10 (talk) 10:11, 30 May 2017 (UTC)
  3. Symbol support vote.svg Support There are actually thousands. --Metrónomo (talk) 13:04, 30 May 2017 (UTC)
  4. Symbol support vote.svg Support --UV (talk) 14:19, 30 May 2017 (UTC)
  5. Symbol support vote.svg Support kill that spam. --Matthiasb (talk) 19:00, 30 May 2017 (UTC)
  6. Symbol support vote.svg Support Page moves (the technically reason why redirects are at Wikidata at all) are not very well handled by the Wikimedia software. A page move at a certain Wikipedia can have different reasons e.g. correcting a misspelling or misconception, different naming conventions or of cause a broadening or narrowing the content of the topic. All this pages moves are done independently from the linked Wikidata item and the concept this Wikidata item is intended to model. So a cleanup is logical. --Succu (talk) 19:44, 30 May 2017 (UTC)
  7. Symbol support vote.svg Support --Smaug the Golden (talk - contributions - logs) 17:28, 2 June 2017 (UTC)
  8. Symbol support vote.svg Support but perhaps not too soon, sometimes users are over-enthusiastic in turning pages into redirects and they are reversed after a while. So a period of two weeks to a month after creation of the redirect should work out well. - Brya (talk) 16:49, 22 June 2017 (UTC)

Against removing existing links[edit]

  1. Symbol oppose vote.svg Oppose --Jbergner (talk) 06:45, 30 May 2017 (UTC)
  2. Symbol oppose vote.svg Oppose You’d at least have to migrate them to old-style interwikis. Any volunteers?  TRN 3.svg • hugarheimur 13:13, 30 May 2017 (UTC)
  3. Symbol oppose vote.svg Oppose for all the reasons I support having such links at all. StevenJ81 (talk) 13:32, 30 May 2017 (UTC)
  4. Symbol oppose vote.svg Oppose Software doesn't do anything against the possibility, if this doesn't change, this idea simply isn't feasible. --MGChecker (talk) 15:35, 30 May 2017 (UTC)
  5. Symbol oppose vote oversat.svg Strong oppose I don't understand people wanting to remove useful links. ArthurPSmith (talk) 17:40, 30 May 2017 (UTC)
  6. Oppose: I don't think it's an improvement to remove useful links. A database only has value when information is retrieved from it. A "self-standing database" is the computing equivalent of a book with a spine on each edge. --RexxS (talk) 19:42, 30 May 2017 (UTC)
  7. Symbol oppose vote.svg Oppose I agree that we have large problems with unintentional links to redirects, för example created when users have merged articles in WP. But that is not solved by a large bot-supported removal of sitelinks. -- Innocent bystander (talk) 19:45, 30 May 2017 (UTC)
  8. Symbol oppose vote.svg Oppose per @ArthurPSmith. Thanks. Mike Peel (talk) 20:27, 30 May 2017 (UTC)
  9. Symbol oppose vote.svg Oppose if there are no software changes to handle redirects. Otherwise this is just removing useful links. Jc86035 (talk) 06:23, 31 May 2017 (UTC)
  10. Symbol oppose vote.svg Oppose --PokestarFan • Drink some tea and talk with me • Stalk my edits • I'm not shouting, I just like this font! 02:14, 4 June 2017 (UTC)
  11. Symbol oppose vote oversat.svg Strong oppose Form Follows Function (i.e. content) VINCENZO1492 18:26, 6 June 2017 (UTC)
  12. Symbol oppose vote oversat.svg Strong oppose --KaiKemmann (talk) 23:54, 16 June 2017 (UTC)
  13. Symbol oppose vote oversat.svg Strong oppose --Quarz (talk) 17:47, 9 July 2017 (UTC)
  14. BA candidate.svg Weak oppose Not an easy bot job, not until an algorithm would be proposed. d1g (talk) 09:17, 11 July 2017 (UTC)
  15. Symbol oppose vote oversat.svg Strong oppose --Steenth (talk) 18:41, 19 July 2017 (UTC)
  16. Symbol oppose vote.svg Oppose ... since opposing this proposal coincides with my support for linking redirects. Steel1943 (talk) 23:11, 11 August 2017 (UTC)
  17. Symbol oppose vote oversat.svg Strong oppose Agathoclea (talk) 16:26, 13 August 2017 (UTC)
  18. Symbol oppose vote oversat.svg Strong oppose Bigbossfarin (talk) 11:06, 14 August 2017 (UTC)

Comment[edit]

  • Too early to make such a definitive statement. How big is the problem? How manageable is the matter? I have seen cases where someone has converted a page to a disambiguation page, rather than move it so that WD updated. Scope the issue, and see if we can make some good data choices rather than just go and delete links. From my PoV, I would clean up the links for enWS, or put it to the community to help, if such a problem list was created.  — billinghurst sDrewth 22:15, 29 May 2017 (UTC)
I think it's useful to have a consistent policy on how we handle redirects. The status quo where it's possible to add them in a hacky way but not possible to add them otherwise seems an inconsistent solution. ChristianKl (talk) 22:18, 29 May 2017 (UTC)
The process of resolution can be separate from the policy guidance to remove them, so please don't conflate their addition and how we remove them.  — billinghurst sDrewth 12:59, 30 May 2017 (UTC)
  • Oh .. should I also vote that we should stop doing maintenance at Wikidata?
    --- Jura 16:47, 13 August 2017 (UTC)

Number of redirects as sitelinks by project[edit]

I have just evaluated actual numbers of redirects as sitelinks, on a per project basis using this quarry query. All numbers apply to namespace0 of the projects exclusively, and only projects with more than 500,000 articles have been considered.

project redirects (ns0) redirects+articles (ns0) redirect fraction
enwiki 78422 5456842 1.44%
cebwiki 67 3001716 0.00%
svwiki 7184 3764825 0.19%
dewiki 4538 2063613 0.22%
nlwiki 4104 1906391 0.22%
frwiki 7760 1872651 0.41%
ruwiki 5090 1396199 0.36%
itwiki 4045 1357847 0.30%
eswiki 3741 1287638 0.29%
warwiki 16 1261956 0.00%
plwiki 1905 1217373 0.16%
viwiki 3974 1157207 0.34%
jawiki 3664 1058237 0.35%
ptwiki 5945 968397 0.61%
zhwiki 3902 940664 0.41%
ukwiki 1319 689743 0.19%
fawiki 8731 548694 1.59%
cawiki 2843 545402 0.52%
arwiki 2772 524865 0.53%

Results: the redirect fraction is typically well below 1%, except for enwiki and fawiki. —MisterSynergy (talk) 09:11, 31 May 2017 (UTC)

This amounts to something like 100.000 redirect interwiki links. In my opinion this is a huge maintanance issue. Allowing redirect interwiki links will lead to an explosion of the already high number of duplicates, so the merging will consume even more time. Steak (talk) 11:09, 31 May 2017 (UTC)
I would have said that in total we have around 200,000 redirects as sitelinks, but this is in fact the same order of magnitude. Using quarry, they can at least be found somewhat effectively in case we want to apply changes in relation to them. However, I would suggest to wait with any changes until this RfC has ended. If repairs become necessary, they might to a large extent be performed automatically and systematically with bots. —MisterSynergy (talk) 11:14, 31 May 2017 (UTC)
@Steak: Why do you believe that allowing redirect interwiki links will lead to people creating a lot of new duplicate items? ChristianKl (talk) 13:23, 31 May 2017 (UTC)
I cannot recall at the moment why I was drawing this conclusion. Maybe this was an incorrect implication. In any case, I was not thinking of manually created duplicates, but of such that are remains of movements, deletions etc. Steak (talk) 15:32, 31 May 2017 (UTC)
I don't think that the duplicate that stays because of a move gets resolved if you removed the link to the redirect. If you still have the redirect it would be easier to write a tool that detects the duplicate because the redirect leaves a record that suggests the two articles belong together. @Steak:, if this is the reason why you voted in opposition, do you have other reasons that you believe are still valid? ChristianKl (talk) 10:07, 1 June 2017 (UTC)
No, this is just one of the reasons. Having a 1-to-1 correspondence between articles and items is for me the most important reason to oppose. Steak (talk) 10:45, 1 June 2017 (UTC)
@Steak: Why do you think it's valuable when University of Strasbourg (Q20808141) has no correspondence to https://en.wikipedia.org/wiki/University_of_Strasbourg ? ChristianKl (talk) 11:12, 1 June 2017 (UTC)
I am not talking about value. I am talking about unique relations between items and articles. If you are talking about value, the next consequence would be to allow interwiki links on sections. There is always something which is more "valuable". Steak (talk) 15:23, 1 June 2017 (UTC)
This may be some left-over of the partially fixed page-move bug.
--- Jura 17:28, 31 May 2017 (UTC)
Nice query. It would be interesting to look into this further, and compare the wikidata items corresponding to the source and target of (say) all the en-wiki redirects. How often can we identify a property (or chain of properties) linking the two wikidata items? How often do the two wikidata items appear to definitely relate to distinguishable things (eg instance of human being vs. instance of duo)? How many are eg disambiguations with different capitalisations, that some wikis lump together and other wikis separate? How many, on the face of it, could be duplicates? This could be very useful. Jheald (talk) 18:05, 31 May 2017 (UTC)
To be clear on my support for linking to redirects, this is only useful in the case where we have two clearly distinct concepts or other entities that deserve their own separate wikidata items, but which are treated on the same wikipedia page (at least in some languages). If the redirect is the consequence simply of a renaming of the wikipedia page, that's not useful at all - if there are two wikidata items about the same thing they should be merged, I agree. Is this "page move" issue resolved now, i.e. do page moves on language wikipedias get immediately reflected in wikidata sitelinks, or is there still an issue there? ArthurPSmith (talk) 18:45, 31 May 2017 (UTC)
I want to be clear that I'm of the same opinion as Arthur. (Obviously, the two concepts in question would be at least a little related, or else there is no reason they would be ever be treated on the same Wikipedia page in any language. But I think everyone understands what Arthur means.) StevenJ81 (talk) 16:15, 2 June 2017 (UTC)
page moves on Wikipedia get only reflected in Wikidata sitelinks if the user has an account on Wikidata and is not blocked here. --Pasleim (talk) 19:54, 31 May 2017 (UTC)
Because of SUL, every user of Wikipedia has also an account on Wikidata. Steak (talk) 07:03, 1 June 2017 (UTC)
I think your account name is unique in the Wikimedia universe, but you need to visit Wikidata at least once (while logged in) to create a local account, or use one of the global account expansion tools. If you didn’t do that at the time of your move action in another project, you don’t have an account at Wikidata in spite of your SUL account. Pasleim’s comment sounds as if an automatic local account creation at Wikidata is not possible during remote page moves. —MisterSynergy (talk) 07:19, 1 June 2017 (UTC)
Is this a technical problem that could get solved? Couldn't the Wikidata accounts be created automatically when someone uses the page move tool? Alternatively couldn't the page move tool write a log and afterwards a bot does the required actions on the Wikidata side? ChristianKl (talk) 10:07, 1 June 2017 (UTC)
Technical solutions to this problem are discussed inphabricator:T143486. --Pasleim (talk) 11:42, 1 June 2017 (UTC)

Related project[edit]

WD:XLINK This project is aiming to generate sitelinks from templates in the wikipage that computes the links from the Wikidata statements. It needs input and support from community. author  TomT0m / talk page 08:01, 11 August 2017 (UTC)