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

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!

THIS RFC IS CLOSED. Please do NOT vote nor add comments.

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.

Well, this is a difficult one, since there are good arguments from both sides. In short, I see a strong numerical advantage (factor of 3) and slightly better argumentation of those who want to allow addition of redirects. I would call this consensus to add redirects to Wikidata items.

However, there are very strong issues surrounding this conclusion, some of which have been discussed properly, and some have been mentioned but not properly discussed.

I would say there is also consensus that not all redirects should be added to Wikidata, but only those redirects which help to solve existing problems are welcome. Indiscriminate addition of redirects, and, even worse, creation of redirects followed by their indiscriminate addition, is clearly not welcome and probably will be considered as disruption. This argument was raised by both supporters and opposers, and has not been convincingly rebutted.
- Given that we currently have no mechanism of redirect addition (except for twice moving articles on the projects, which is a clear disruption and I am sure will be perceived as such on the projects), before the phabricator task can be opened we need to discuss some policies on when redirects can be added, by whom and how. These questions were not properly addressed in this RfC. For example, one suggestion was that redirects must be added in such a way that constraint violations are not created, however, there was no proper discussion of this point.
There was also a suggestion that redirects must be clearly visible and discriminated from other links. Ideally, they should not only be human-readable, but also bot-readable. Again, this needs to be discussed.
I am sure during the implementation some other issues will surface out. Opposers point out to some of the issues (for example, read Lydia's comment carefully). The more we can foresee before actually allowing the redirects, the easier it will be to implement the change, and the more conflicts we can avoid.--Ymblanter (talk) 16:38, 6 November 2018 (UTC)[reply]

The main case

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)[reply]

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)[reply]

Bonnie and Clyde problem

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)[reply]

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)[reply]

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

Wikidata is higher resolution than Wikipedia

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)[reply]

You can use described at URL (P973) such in Special:Diff/610245926. Visite fortuitement prolongée (talk) 12:50, 17 December 2017 (UTC)[reply]

This is a proxy for a more existential question

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)[reply]

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)[reply]

Possible complaints that can be fixed with code

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)[reply]

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)[reply]

Voting for allowing creation

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Support

Strong support ChristianKl (talk) 21:49, 28 May 2017 (UTC)[reply]
Strong support --Morten Haan (talk) 22:51, 28 May 2017 (UTC)[reply]
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)[reply]
Support Queryzo (talk) 06:31, 29 May 2017 (UTC)[reply]
Support Viciarg (talk) 09:10, 29 May 2017 (UTC)[reply]
Support --Coffins (talk) 11:12, 29 May 2017 (UTC)[reply]
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)[reply]
Support --Ptolusque (talk) 17:53, 29 May 2017 (UTC)[reply]
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)[reply]
Why can't you use arbitrary links? That is their purpose. — billinghurst sDrewth 22:53, 29 May 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Strong support --Jbergner (talk) 06:44, 30 May 2017 (UTC)[reply]
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)[reply]
Support Such sitelinks already exist; indeed there is even a template, Template:Soft redirect with Wikidata item (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)[reply]
Strong support _• _{• hugarheimur} 13:10, 30 May 2017 (UTC)[reply]
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)[reply]
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)[reply]
Support. Per Arthur Smith et al. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:16, 30 May 2017 (UTC)[reply]
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[reply]
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)[reply]
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)[reply]
Support --Labant (talk) 22:18, 30 May 2017 (UTC)[reply]
Support Gz260 (talk) 08:47, 31 May 2017 (UTC)[reply]
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)[reply]
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)[reply]
Support per ArthurPSmith. Nikkimaria (talk) 00:42, 1 June 2017 (UTC)[reply]
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)[reply]
Strong support --Dipsode87 (talk) 13:57, 1 June 2017 (UTC)[reply]
Strong support Richard Nevell (WMUK) (talk) 16:56, 1 June 2017 (UTC)[reply]
Support --CENNOXX (talk) 11:06, 2 June 2017 (UTC)[reply]
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)[reply]
Strong support --Mauerquadrant (talk) 12:25, 2 June 2017 (UTC)[reply]
Support For example, w:en:Farm to Market Road 289. --Rs chen 7754 07:00, 3 June 2017 (UTC)[reply]
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)[reply]
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)[reply]
Support Could be extremely useful. All the best: Rich Farmbrough, 08:37, 5 June 2017 (UTC).
Weak support Not happy about it implications but probably the best solution existing. -- MichaelSchoenitzer (talk) 12:53, 5 June 2017 (UTC)[reply]
Strong support Form Follows Function (i.e. content) VINCENZO1492 18:24, 6 June 2017 (UTC)
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)[reply]
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)[reply]
Strong support --RolandUnger (talk) 07:45, 14 June 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Support In my opinion the advantages outweigh the disadvantages.--Wdwd (talk) 19:17, 5 July 2017 (UTC)[reply]
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. -happy 5214 22:58, 8 July 2017 (UTC)[reply]
Strong support Badly needed! --Quarz (talk) 17:44, 9 July 2017 (UTC)[reply]
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)[reply]
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)[reply]
Support but only if the redirect page contains a specific magic word.--GZWDer (talk) 10:05, 11 July 2017 (UTC)[reply]
Support --Steenth (talk) 18:43, 19 July 2017 (UTC)[reply]
Support --Jojhnjoy (talk) 15:47, 4 August 2017 (UTC)[reply]
Strong support The interwiki system is basically broken without this. --YMS (talk) 12:13, 9 August 2017 (UTC)[reply]
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)[reply]
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)[reply]
Support Agathoclea (talk) 16:23, 13 August 2017 (UTC)[reply]
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)
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)[reply]
Strong support --Mauerquadrant (talk) 05:37, 25 August 2017 (UTC)[reply]
You can't vote twice. Stryn (talk) 16:02, 1 February 2018 (UTC)[reply]
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)[reply]
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.[reply]
Support --Agentjoerg (talk) 10:16, 16 September 2017 (UTC)[reply]
Strong support--Bestoernesto (talk) 01:34, 4 October 2017 (UTC)[reply]
Support I use Wikipedia to find information. I'm Swedish. If I find an English article about a subject, I wonder if there is a Swedish article, but there is no Interwiki. After researching, maybe through Google, I find this information in some other article. To have an A↔A correspondence requirement to have interwiki links, requires all different Wikipedias to have the same article structure. That is hard. For example there are many more science articles in English since many publications are in English for science. Geographical articles can be more detailed in the language spoken in each area. To require perfect order, as some claim, is like a story I heard about a shop attendant who complained that it is hard to keep good order when there are customers buying stuff. Well, the reason for the existence of Interwiki links in Wikidata is not for Wikidata itself, it is a service for readers of Wikipedia. And curses do not give one extra vote in this discussion.--BIL (talk) 07:15, 21 October 2017 (UTC)[reply]
Support — Mike Novikoff 22:50, 20 November 2017 (UTC)[reply]
Support, long waited option. --Infovarius (talk) 13:45, 27 November 2017 (UTC)[reply]
Support. --Epìdosis 13:13, 13 December 2017 (UTC)[reply]
Support if an icon or something can be shown with the redirects so that the users can clearly see the difference between redirects and normal links.--Stevenliuyi (talk) 09:23, 14 January 2018 (UTC)[reply]
Support. Asav (talk) 08:35, 16 January 2018 (UTC)[reply]
Strong support, keeping current UI warnings and feedback. Keep the UI that tries to convert a redirect to its target article. Keep the UI that warns you when that target article already exists as an interwiki assigned to a different Wikidata item. But instead of disallowing adding the redirect anyway, with the error message "if the two topics are the same you can merge them", offer an option in that error message to add the redirect anyway, because this is a Bonnie & Clyde or hatmaker/hatmaking issue. Sj (talk) 20:34, 24 January 2018 (UTC) For an example of how widespread the problem, see most 0-byte entries in these lists.[reply]
Strong support Daask (talk) 14:02, 2 February 2018 (UTC)[reply]
Strong support Dan Koehl (talk) 09:49, 12 February 2018 (UTC)[reply]
Strong support Shyamal (talk) 10:57, 15 February 2018 (UTC)[reply]
Strong support Alexei Kopylov (talk) 19:51, 9 March 2018 (UTC)[reply]
Support -- Achim Raschka (talk) 05:27, 3 May 2018 (UTC)[reply]
Support On Wikidata, it looks as if there is no article about murderer Brenda Ann Spencer (Q237119) on the English Wikipedia, though 18 other sites have articles. But her biography is there, in Cleveland Elementary School shooting (Q50841850). The redirect should be connected to her name on Wikidata, so that the true state of her coverage can be shown on Wikidata. This is only the most recent example I’ve run across. It’s frustrating and damages the data integrity. NotARabbit (talk) 21:12, 25 June 2018 (UTC)[reply]
Strong support TED (talk) 11:57, 28 June 2018 (UTC)[reply]
Support ShinePhantom (talk) 19:05, 30 June 2018 (UTC)[reply]
Support. Depending on the rules of the wiki, there may be articles about the same, but in a different format (for example: Ali Feruz (Q35495844) and Trial of Ali Feruz (Q55267209) — properties of these items are completely different). NBS (talk) 19:15, 30 June 2018 (UTC)[reply]
Support. --VladXe (talk) 20:38, 30 June 2018 (UTC)[reply]
Support. Useful for linking monospecific taxa, which sometimes have different sitelinks: for instance, a wikipedia have an article about the species, to which the genus is a redirect. When another wikipedia choose the other way (article about the genus, the species being a redirect), it is not possible to link them, despite the subject being obviously the same — because on wikidata there is an item about the species and another item about the genus, which is plain legit. Chaoborus (talk) 21:07, 30 June 2018 (UTC)[reply]
Support. --Insider (talk) 11:11, 2 July 2018 (UTC)[reply]
Strong support.--Arbnos (talk) 22:24, 2 July 2018 (UTC)[reply]
Strong support. — evs 💬 06:17, 4 August 2018 (UTC)[reply]
Support Someone say that this feature can be confusing... but every feature can be confusing. Anyway lot of people need to do this, and they already do this removing the local redirect before saving it in Wikidata (and than rollbacking locally). --Valerio Bozzolan (talk) 15:19, 5 August 2018 (UTC)[reply]
Strong support. — Rfassbind (talk) 23:16, 7 September 2018 (UTC)[reply]
Strong support. — Rainald62 (talk) 00:10, 16 September 2018 (UTC)[reply]
Strong support and having a badge for such redirect would be nice. Wikisaurus (talk) 02:59, 16 September 2018 (UTC)[reply]
Strong support Yes, there are plenty of issues with allowing this and plenty of cases that will be messy. But!, there are vastly more issues with the status quo especially in terms of Wikidata as connector of Wikimedia sites, and I'm happy to see there already immediately implementable solutions proposed for the biggest such problems above. Innotata (talk) 23:40, 16 September 2018 (UTC)[reply]
Support --Kmhkmh (talk) 10:46, 26 September 2018 (UTC)[reply]
Support Very usefull in case of monotypic taxa. --Salix (talk) 12:29, 27 September 2018 (UTC)[reply]
Support Germartin1 (talk) 11:11, 4 October 2018 (UTC)[reply]
Support Forcing Wikipedia contributors to go back to interlanguage links, which are/were supposed to be fully replaced by Wikidata, would be bad. The RedBurn (ϕ) 06:07, 9 October 2018 (UTC)[reply]
Support You can already do this (as it's been stated). And what happens if a page becomes a redirect. Currently we don't clean this up, it just stays around, so either we need to fully commit to 'yes' redirects or 'no', but I'm not a fan of the inbetween we have now. U+1F360 (talk) 20:49, 27 October 2018 (UTC)[reply]
Strong support, nécessaire lorsqu'un sujet sur Wikidata n'est traité que dans un article plus général dans une Wikipédia. O.Taris (talk) 11:03, 2 November 2018 (UTC)[reply]

Against

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)[reply]
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)[reply]
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(s) (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)[reply]
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)[reply]
Oppose creates confusing situations for readers. Sjoerd de Bruin (talk) 08:42, 29 May 2017 (UTC)[reply]
Oppose Ich schließe mich da ganz Marcus Cyron an. --Mogelzahn (talk) 12:17, 29 May 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose --Metrónomo (talk) 20:35, 29 May 2017 (UTC)[reply]
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. We are not about massaging items to fit articles, or the wikipedias. — billinghurst sDrewth 22:11, 29 May 2017 (UTC)[reply]
@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)[reply]
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)[reply]

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)[reply]
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)[reply]

@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)[reply]
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)[reply]
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)[reply]
Oppose per Stryn. Mahir256 (talk) 23:25, 29 May 2017 (UTC)[reply]
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)[reply]
I interpret it, you want wikidata interwiki to point only to articles, and they can have a link and a statement only. That is more stub articles? --BIL (talk) 07:21, 21 October 2017 (UTC)[reply]
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)[reply]
Oppose --Hubertl (talk) 17:35, 30 May 2017 (UTC)[reply]
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.[reply]
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(s) (P527) etc. --Pasleim (talk) 19:35, 30 May 2017 (UTC)[reply]
Oppose --Holder (talk) 03:47, 31 May 2017 (UTC)[reply]
Oppose per Agabi10 --HHill (talk) 19:46, 31 May 2017 (UTC)[reply]
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)[reply]
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)[reply]

"Mergeing several items" is not necessarily a good thing. Indeed i would argue for more discrimination. All the best: Rich Farmbrough, 08:34, 5 June 2017 (UTC).
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)[reply]
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)[reply]
Oppose Miodzio3 (talk) 16:14, 5 June 2017 (UTC)[reply]
Strong oppose --Smaug the Golden (talk - contributions - logs) 18:19, 9 June 2017 (UTC)[reply]
Oppose. MechQuester (talk) 14:11, 22 June 2017 (UTC)[reply]
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)[reply]
Oppose @xqt 14:23, 4 July 2017 (UTC)[reply]
Oppose --Senechthon (talk) 07:59, 8 July 2017 (UTC)[reply]
Oppose we will have millions of fake sitelinks. --Mr. Ibrahem (talk) 22:22, 20 July 2017 (UTC)[reply]
@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)[reply]
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(s) (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)[reply]
That solution would seem more hacky to me. has part(s) (P527) and part of (P361) gets used in a lot of different ways in Wikidata and this would lead to some virtual links that make little sense without there being a good way to remove the virtual links. There will be likely a few fights about statements that are decent usages of those statements as they stand at the moment but that would create bad links. I don't think you can get the best result without actually reading the involved Wikipedia articles and looking at the content that they cover. It's quite possible that the English article on X is long and speaks about A which is a part of X but the Italian article on X is short and doesn't mention A at all. It might even have a paragraph about A at article Y. At the same time part_of won't get you a lot of cases that need interwiki links. The street example is one. Another is anatomy. One Wiki might have an article that speaks specically about a human arm while the next has an article that speaks about arm in general. There's no part_of relationship and it would still be good to have links. ChristianKl (talk) 14:12, 17 October 2017 (UTC)[reply]
Unstructured links are hacks. You do not want this within a database. One of the main motivations for this proposal appears to have interwiki links where the corresponding articles are close but still handle different subjects (like a human arm vs. an arm in general). But this is not a real problem. You would, however, create a mess by introducing unstructured links as you have then no idea what you are heading to if you follow such a link. --AFBorchert (talk) 08:14, 4 November 2017 (UTC)[reply]
# Oppose -- MovieFex (talk) 15:03, 3 August 2017 (UTC)[reply]
Oppose --Balû (talk) 11:13, 9 March 2018 (UTC)[reply]
I concur with Sjoerd de Bruin. — regards, Revi 13:31, 16 May 2018 (UTC)[reply]
Oppose --Niridya (talk) 14:44, 16 August 2018 (UTC)[reply]
Oppose - In sitelinks we link to other articles about the same subject. Often redirects do not link to the same subject but to a page that only for a small part mentions the subject. Not a good idea. Romaine (talk) 16:43, 2 September 2018 (UTC)[reply]

Neutral

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)[reply]
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)[reply]

Comment I strongly support Deryck Chan's proposal for a message and confirmation when creating links to redirects. Daask (talk) 20:25, 13 March 2018 (UTC)[reply]

Neutral When attempting to add a link there is a check on whether it's a redirect or not. Would it be possible to use this to put redirects in a separate section when added (and have a bot update them when necessary - as is done when existing pages are redirected)? Peter James (talk) 19:56, 20 September 2017 (UTC)[reply]

Discussion

Other problems caused by/related to redirects

Redirect connected in a item with wrong interwiki; redirect to article connected with a disambiguation page
Redirect which keep alive a perfectly duplicated item. One month later after that article in Wikipedia was transformed into redirect, our WD item even was improved a bit "blindly" :) (history). A similar example: oldid (hist)
Former Wikipedia duplicated article with a duplicated WD item: the page in WP was transformed in redirect a month ago, WD item still alive. There are a lot of items marked as duplicated, and many connected WP pages will be redirected but WD items here will need an additional individual review, I suppose, before removing sitelink/mergind/deleting, etc. Who will do this for thousands and tens of thousands of items?
One more nice case: sh redirect is connected in good item, the redirect target is connected in an ~empty item.
Q16633690, Q16109704 - redirects which keeps intact some ~empty items.

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)[reply]

I don't see how items like Clarke County (Q16633690) and transport in Belgrade (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)[reply]

@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)[reply]

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)[reply]

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 (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 (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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

Removing existing links

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

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.[reply]
Support -- Agabi10 (talk) 10:11, 30 May 2017 (UTC)[reply]
Support There are actually thousands. --Metrónomo (talk) 13:04, 30 May 2017 (UTC)[reply]
Support --UV (talk) 14:19, 30 May 2017 (UTC)[reply]
Support kill that spam. --Matthiasb (talk) 19:00, 30 May 2017 (UTC)[reply]
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)[reply]
Support --Smaug the Golden (talk - contributions - logs) 17:28, 2 June 2017 (UTC)[reply]
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)[reply]
Support --Niridya (talk) 14:44, 16 August 2018 (UTC)[reply]

Against removing existing links

Oppose --Jbergner (talk) 06:45, 30 May 2017 (UTC)[reply]
Oppose You’d at least have to migrate them to old-style interwikis. Any volunteers? _• _{• hugarheimur} 13:13, 30 May 2017 (UTC)[reply]
Oppose for all the reasons I support having such links at all. StevenJ81 (talk) 13:32, 30 May 2017 (UTC)[reply]
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)[reply]
Strong oppose I don't understand people wanting to remove useful links. ArthurPSmith (talk) 17:40, 30 May 2017 (UTC)[reply]
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)[reply]
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)[reply]
Oppose per @ArthurPSmith. Thanks. Mike Peel (talk) 20:27, 30 May 2017 (UTC)[reply]
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)[reply]
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)[reply]
Strong oppose Form Follows Function (i.e. content) VINCENZO1492 18:26, 6 June 2017 (UTC)
Strong oppose --KaiKemmann (talk) 23:54, 16 June 2017 (UTC)[reply]
Strong oppose --Quarz (talk) 17:47, 9 July 2017 (UTC)[reply]
Weak oppose Not an easy bot job, not until an algorithm would be proposed. d1g (talk) 09:17, 11 July 2017 (UTC)[reply]
Strong oppose --Steenth (talk) 18:41, 19 July 2017 (UTC)[reply]
Oppose ... since opposing this proposal coincides with my support for linking redirects. Steel1943 (talk) 23:11, 11 August 2017 (UTC)[reply]
Strong oppose Agathoclea (talk) 16:26, 13 August 2017 (UTC)[reply]
Strong oppose Bigbossfarin (talk) 11:06, 14 August 2017 (UTC)[reply]
Oppose. This can only be done in small fraction of cases, manually, and possibly with some preliminary discussion. --Infovarius (talk) 13:46, 27 November 2017 (UTC)[reply]
Oppose until Lydia Pintscher's proposal to generate some sitelinks automatically based on statements is implemented, and even then only when the redirect target is linked to a wikidata item associated with the current one by a statement. Daask (talk) 19:03, 31 March 2018 (UTC)[reply]
Strong oppose --Infovarius (talk) 15:11, 25 April 2018 (UTC)[reply]
Strong oppose.--Arbnos (talk) 22:26, 2 July 2018 (UTC)[reply]
Oppose, for reasons given above and in view of the clear consensus in the original RfC on this page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:57, 2 August 2018 (UTC)[reply]
Oppose, for the same reason stated in support of such links. The RedBurn (ϕ) 06:18, 9 October 2018 (UTC)[reply]

Comment

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)[reply]

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)[reply]

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)[reply]

Oh .. should I also vote that we should stop doing maintenance at Wikidata?
--- Jura 16:47, 13 August 2017 (UTC)[reply]

Number of redirects as sitelinks by project

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

This may be some left-over of the partially fixed page-move bug.
--- Jura 17:28, 31 May 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Because of SUL, every user of Wikipedia has also an account on Wikidata. Steak (talk) 07:03, 1 June 2017 (UTC)[reply]

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)[reply]

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)[reply]

Technical solutions to this problem are discussed inphabricator:T143486. --Pasleim (talk) 11:42, 1 June 2017 (UTC)[reply]

Related project

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)[reply]

Thoughts from Lydia and a way forward

First of all let me say I am really sorry it took me this long to write this. You deserve better than this from me. The main reason it took me so long (besides being super busy) is that I've really struggled with this complex topic.

There are very good reasons for people to want to link to redirects. Based on the comments here the by far biggest point is wanting to link between different Wikipedia language versions even if the concepts don't quite match up in the articles. That's a fair and understandable request.

There are however also very good reasons to not do it. The sitelinks are a part of what defines what an item is about. At first this seems trivial but there is a whole lot behind it. For example we have tools that import data from Wikipedia infoboxes and categories as well as from outside databases. Quite some of them rely on the sitelinks to identify a concept. I have seen way too many import mistakes already simply because the concepts were not separated correctly. Suddenly you end up with data about a particular episode of a TV show in the item for the TV show and so on. That is really bad from a data consumer side. Another issue is the creation of duplicate items. The check that makes sure that one article is only linked in one item is a huge help in finding duplicates and maintaining our data that I'd rather not lose. Redirects also have very different semantics (typos, broader concept, narrower concept, different facet, ...) and it isn't clear how to keep the "good" ones apart from the "bad" ones consistently. And last but not least there are the parser functions and Lua modules that take data from the connected item by default. It isn't clear which item they should be getting their data from if more than one item is connected with an article.

Taking all this together I think we need to figure out ways to give the Wikipedias the sitelinks they want without linking to redirects. The best suggestion I've seen so far (which would also reduce duplication of information) is the idea of generating some sitelinks automatically based on statements. I'd like to explore this further with you and see if this is feasible. As a next step it'd be great if we can collect specific cases to see which statements could provide a large number of them without too much overhead. --Lydia Pintscher (WMDE) (talk) 21:38, 31 January 2018 (UTC)[reply]

Not surprisingly I agree. --Succu (talk) 21:45, 31 January 2018 (UTC)[reply]

@Lydia Pintscher (WMDE): I don't think some of these arguments add up:

too many import mistakes already simply because the concepts were not separated correctly. Allowing links to redirects helps better separation of concepts on Wikidata. At the moment people are forced to link articles for all related concepts into a single Wikidata item here, if they want to keep interwiki functionality. But when redirect pages can be sitelinked to Wikidata items, then it becomes possible to have the main articles sitelink to different (more precise) Wikidata items, without losing the interwiki functionality. Making this possible is actually a stepping stone to much better definition and distinction of concepts here, and data import from more accurately corresponding counterparts on wiki.
parser functions and Lua modules that take data from the connected item by default. An article will still only connect to a single item via a sitelink. That is the item information will be drawn from. The redirect page will connect to a different item -- but the redirect page won't have an infobox on it.
The check that makes sure that one article is only linked in one item is a huge help in finding duplicates and maintaining our data. This is very true. But one wiki-page would still only be linked to one item, and vice-versa. We need to think of the process here. Where do bad sitelinks to redirects come from? Mostly, because two articles have been merged on the target wiki, but the corresponding items have not been merged here. That happens now, and the software doesn't stop it. What the software does stop is making a 'good' sitelink to a redirect. It is probably true that most current sitelinks to redirects are 'bad'. But a reasonable way forward for dealing with this (which people have voted for with their feet) is to have a mechanism to identify the consciously-created good ones and distinguish them. On en-wiki this is done by marking the redirect page with en:Template:Wikidata redirect. As the wikidata item Template:Soft redirect with Wikidata item (Q16956589) reveals, this now has counterparts on eight wikis, including French, German, and Russian. With this marker, redirects with the template can be whitelisted as intentional, redirects without it can be considered suspect, and targeted for evaluation/clean-up.
One needs to make sure one is looking at this the right way round. The proposal on this page is to allow sitelinks to redirect pages on Wikipedias. It is not about allowing sitelinks to redirect items on Wikidata. Most of your objections seem to be framed as if thinking about the latter, not the former.

Jheald (talk) 22:37, 31 January 2018 (UTC)[reply]

I share her concerns that a mixture or actual sitelinks and redirects in the sitelink section is rather dangerous. If at all an apporach similar to sitelinks would be chosen for implementation, one would probably rather invent a new “redirects” box in the web frontend, and of course a separate handle in the data model (something else than schema:about), in order to cleanly keep sitelinks and redirects apart from each other. This RfC unfortunately did not really address practical problems about the request enough, but I guess the actual implementation would not really play a role if it effectively improved the sitelink management in difficult cases. Side note: I am really sceptical about a property-based approach for sitelinks. —MisterSynergy (talk) 23:09, 31 January 2018 (UTC)[reply]

In terms of the presentation on the Wikipedias, it's not necessary to invent a new “redirects” box in the web frontend. The more straightforward solution is just to indicate interwikis that go to redirects with a marker next to them -- a red circle perhaps, to indicate only an approximate match -- in the same way that we use gold stars to indicate an interwiki link to an article of particularly high quality.

Similarly it would be a good step forward if links to redirects were marked as such in the appropriate boxes of the page on Wikidata. Jheald (talk) 23:17, 31 January 2018 (UTC)[reply]

As far as I know we do not have real-time information about whether a sitelink is a redirect or not. So if we kept actual sitelinks and redirects together, we would have to invent an expensive mechnism of continuous checks whether all sitelinks that are not marked as redirects are still sane, and we would probably also have to align a lot of redirect sitelinks manually. I am not sure whether this scales properly, since the number of redirect sitelinks would quickly explode. It is also very bad if redirects were delivered as sitelinks to data users (e.g. via Query Service), since they expect a 1:1 correspondence to the item as they are used to, not something that is somehow related. Consider such a query to be an input source for an import procedure and you see how this could go wrong if the 1:1 correspondence does not hold any longer … —MisterSynergy (talk) 23:31, 31 January 2018 (UTC)[reply]

@MisterSynergy: There's a flag in the page table as to whether a page is a redirect. It ought to be easy enough to access that, or track changes in it.

You may be right that if sitelinks to redirects were officially approved of, the number might greatly increase. It would probably make sense to require a vigorous clean-up of existing sitelinks without the whitelist template first. But any worry that it would then become impossible to separate 'bad' sitelinks from 'good' sitelinks I think is overdone.

I think User:Sj is exactly right in his comment above that, when somebody tries to add a sitelink to a redirect, we should keep current UI warnings and feedback. Keep the UI that tries to convert a redirect to its target article. Keep the UI that warns you when that target article already exists as an interwiki assigned to a different Wikidata item. But instead of disallowing adding the redirect anyway, with the error message "if the two topics are the same you can merge them", offer an option in that error message to add the redirect anyway. And at that point, then also add the template Template:Soft redirect with Wikidata item (Q16956589) to the redirect page, so that it can be distinguished as a redirect sitelink that has intentionally created from Wikidata, rather than a redirect sitelink that is a sitelink that has been left over after a merge on-wiki but not on wikidata.

It is worth remembering that it is the redirect page that would be returned by WDQS, not the wikipage that is the target of the redirect. Even if the redirect page were then to be an input source for an import procedure, the impact would be very limited, because there the redirect page would contain no data to scrape, just the redirect template. But I agree that if we're keeping a local record of which linked pages are redirects, it would be useful to include that in the triplestore. And it should be easy enough. We already include the triples ?article schema:about ?item, ?article schema:isPartOf <https://en.wikipedia.org/> and ?article wikibase:badge ?badge, so one would just need to introduce another value of badge. Or one could create a new wikibase: predicate as well. If we were going to keep a local record anyway, maintaining that as part of the RDF update stream should be very easy to include. Jheald (talk) 00:23, 1 February 2018 (UTC)[reply]

Just a note that I

Support Jheald's comments above, and to add that wikidata editors are working around the current UI to do this now - @Lydia Pintscher (WMDE): I believe it's wrong to claim the main motivation for this is a desire on the part of the various language wikipedias - rather it is something that a considerable majority of wikidata editors want to do, and I think it is related to the desire to better define wikidata items. A redirect page has a title that is distinct from the title of the page it links to; that page title helps define more precisely what that wikidata item is about. If you have a wikipedia page about a foundation named after a particular person, and the page with the name of that person redirects to the foundation page, then it is helpful to have a sitelink to that redirect on the wikidata item about the person, rather than just having one sitelink on the item about the foundation. In cases like that I don't care if there are any inter-language links to any other language; the existence of the two sitelinks in a single language better defines the two wikidata items. ArthurPSmith (talk) 15:17, 1 February 2018 (UTC)[reply]

WD:XLINK has been collecting some examples of statement patterns that may lead to a sitelink. said to be the same as (P460) is already used by Module:Interwiki on a few tenth of pages on enwiki and a few pages on frwiki, for example. author TomT0m / talk page 10:27, 12 February 2018 (UTC)[reply]
- As the projects of automagic interwikis will succeed if enough wikimedians are involved, I tried to raise the subject on the frwiki main chat today to see if some people on frwiki would be ready to try to scale things up. author TomT0m / talk page 11:33, 12 February 2018 (UTC)[reply]

Thanks for this input, Lydia. I recognize some of the concerns you raise. I only ask, please put the burden of clarifying things on the data-editor who is adding a non-standard sitelink -- and make it obvious how to jump through those hoops, from the natural edit workflow of {1. find broken sitelink, 2. try to edit it in place}. +1 to specific examples from Jheald and Arthur. Sj (talk) 21:37, 12 February 2018 (UTC)[reply]

@Lydia Pintscher (WMDE): In terms of infoboxes, we tried that approach by using {{#ifexist}} statements (in parser functions or in lua code) to check, e.g., for combinations of parameters (e.g., en:Palomar Mountain, California rather than en:Palomar Mountain, en:California). It sort of works, but it unfortunately also creates phantom "what links here" entries, a bug that dates back to 2007. See m:2017 Community Wishlist Survey/Miscellaneous/Stop ifexist checks from appearing in Special:WhatLinksHere for a writeup. If that's fixed, then that would help somewhat, but I don't think that can solve the problem - you then end up writing more and more complex code to deal with the edge cases. Being able to store information about redirects on Wikidata, and then to be able to query which ones exist rather than guess what might be there, would simplify things a lot. Thanks. Mike Peel (talk) 15:24, 15 February 2018 (UTC)[reply]

Dear all WMDE staffs, I think instead of allowing redirects, how about allowing more than one sitelinks for one site entry which is bumped again and again in phab:T54971? In this way, we can set up just one set of statements for all kinds of articles in single interface, rather than trying bot to sync such things. --Liuxinyu970226 (talk) 08:02, 18 February 2018 (UTC)[reply]

I support Lydia Pintscher's proposal to generate some sitelinks automatically based on statements. This gets users the links while preserving data quality and a 1:1 relationship between Wikidata items and their associated Wikipedia article. I just hope this is implemented soon, as this page indicates that this is a major issue. Daask (talk) 19:06, 31 March 2018 (UTC)[reply]

I just want to put in my two cents (or repeat them, from above): We who work on Wikipedias (and the like) need a way to sllow some interwiki links to go to places that are something other than ordinary, stand-alone pages. Because Wikidata and different Wikipedias all have differnt levels of granularity, insisting that only one-to-one correspondences will do is just not practical. We really do understand why, from a pure database perspective, a pure one-to-one correspondence is the most desirable way to go. But if it's not practical, what do you do, then?
Mostly, I am indifferent to the mechanism used, as long as the mechanism is something that ordinary Wikipedia contributors can easily handle. One reason that redirects are popular is that ordinary Wikipedia contributors can handle them. And on the whole, we can handle them even in languages where we are not very fluent.
- Personally, I really like best the idea of allowing redirects when the redirect has been marked with a template saying "this was done intentionally for this purpose". It creates a nominal page on the target wiki representing the topic (thereby creating the skeleton of one-to-one correspondence), and the presence of the redirect gives a potential future author a place to work if s/he wants to build out the page in the future. And this is simple for Wikipedians to do. If we do this, I'd love the need to hack to do this disappear. But I can live with the hack; it's not that hard to do, and makes it more difficult for people simply to make random redirects, which none of us really want to see.
- Still, I'm not wedded to the approach. If you were to tell me that I could add a real link to a section header (or any other anchor on a page), I'd do that. I think a number of people above have stated reasons they think this is not as good an approach, and I tend to agree. But what I want is a solution that works, and I can live with a less-than-optimal one.
- And, again, to summarize: if we do this by statements instead, that's fine, too, as long as the way to do it is documented, and can be handled by an ordinary Wikipedian. I'm largely indifferent to the mechanism, as long as I get a solution. But I will strongly disapprove of making even the hack impossible. There needs to be a way to do this. StevenJ81 (talk) 15:23, 30 May 2018 (UTC)[reply]

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

Contents