Wikipedia talk:Manual of Style: Difference between revisions

Should we ban links to wikidata within the body of an article? --

NOTE- Since there is another RFC on using wikidata in infoboxes, none of the options below will apply to the usage of wikidata in infoboxes since that is being determined separately.

I'm providing three options:

1. Support- Wikidata should not be linked to within the body of the article (this includes hidden text links). This will have no impact on the sidebar links nor Wikipedia:Authority control
2. Support, but with exception for inline inter-language links- Same as above, but allows for exception for use of Template:Interlanguage link
3. Oppose-Link to Wikidata if an article does not exist

I am adding an additional option to clarify: --RAN (talk) 03:16, 10 May 2018 (UTC)[reply]
        4.  Oppose- Allow hidden text links with Wikidata Q-numbers such as <!-Q1123456--> so that a duplicate Wikidata entry is not created in the future

And another, because the one above isn't an oppose rationale but another exception:
        5.  Support, with two exceptions: for inline inter-language links and hidden-text Q numbers, as described above.  — SMcCandlish ☏ ¢ 😼  09:54, 18 May 2018 (UTC)[reply]

Survey

• Support- full ban in body of article as proposer.--
  Rusf10 (talk) 00:50, 10 May 2018 (UTC)[reply
  ]
•   NOTE: Some !voters below may have arrived via partisan audience
  CANVASS. This RFC was posted & linked on the Wikidata central Project Chat at 01:52, 10 May 2018.[1] Alsee (talk) 01:33, 13 May 2018 (UTC)[reply
  ]

  WP:Canvas says to post at the projects involved! Calling them a "partisan audience" is just silly. They have as many diverse opinions as there are here. --RAN (talk) 20:50, 18 May 2018 (UTC)[reply]

  WP:RS policy. The fact that Wikidata would cease to exist as an autonomous community would actually help resolve some of the issues with using Wikidata on EnWiki, all content on Wikidata would be subject to EnWiki policies and EnWiki administration. Alsee (talk) 04:18, 20 May 2018 (UTC)[reply

  ]

  Yeah, notifying off-site (even WMF-related) groups who have a vested interest in the outcome is

  WP:MEATPUPPETRY, a particular form of canvassing.  — SMcCandlish ☏ ¢ 😼  06:48, 9 June 2018 (UTC)[reply

  ]

• Oppose - This appears to be about Rusf10 removing hidden links Q-numbers formatted as <!-Q123456--> to Wikidata from tables that list multiple people that do not currently have an entry in English Wikipedia. The Wikidata entry links to Wikipedia entries in other languages and links to Wiki Commons and Wiki Quote, even if they do not have an English Wikipedia entry. The hidden links will let an editor know that if an article is recreated or a new entry is created for this person, an entry at Wikidata already exists. This will hopefully reduce duplication of Wikidata entries. It also allows Wikipedia to disambiguate people that appear in articles and lists that currently do not have Wikipedia entries. This way a person can know that say "John Smith, Mayor of Yourtown<!-Q123456-->" in an article on Yourtown is the same person as "John Smith, President of BigCompany<!-Q123456-->" that appears in the article on BigCompany. It will allow someone who creates an article in the future to search for hidden text on the string "Q123456" and find both entries and create the properly disambiguated link to the article. Of course only someone actually editing an article will be able to see the hidden link Q-number. --RAN (talk) 02:06, 10 May 2018 (UTC)[reply]

  This will do absolutely nothing to prevent duplicate entries in wikidata for topics that already have articles in wikipedia, so it seems to me to just be an excuse, not a real solution to a problem. If duplicate entries is really a widespread problem in wikidata then why doesn't wikidata come up with its own solution for this that doesn't involve wikipedia?--

  Rusf10 (talk) 03:38, 10 May 2018 (UTC)[reply

  ]

  Okay, to clarify what I think RAN is talking about: Suppose there is a redlink here. Somebody sees it, creates an article, and then creates a Wikidata entry for the new article. What I think RAN is suggesting is that any hint we can give here is useful, that a Wikidata item already exists, and so if/when a new article is created here, then it should be linked to the existing Wikidata item, rather than have a new one created for it.

  Wikidata users make quite an effort to try to hunt down and merge duplicates, eg trying to spot potential duplicates that matching birth/death dates, or the same value for an external ID, or apparent duplicates that come up organically in search. But all these are playing catch-up, and are never 100%. It's altogether better if the new article gets linked properly from the outset.

  Another reason (IMO) may also be worth considering why such references in comments might be useful, namely that if a wikidata item exists, it may have some useful information and references for basic facts like full names, dates, external identifiers, places of activity, birth, death, etc that all may be of use to somebody creating an article. Jheald (talk) 10:54, 10 May 2018 (UTC)[reply]

• Support a ban, or at least strongly discourage them, similar to the language in
  WP:EXTLINKS. Pburka (talk) 02:38, 10 May 2018 (UTC)[reply
  ]
• Oppose Such links should be allowed to be used where they can provide extra information to readers and editors about the topic. They are not completely external links, they are links within the Wikimedia movement. Thanks. Mike Peel (talk) 12:07, 10 May 2018 (UTC)[reply]
• Support, but with exception for inline inter-language links. I oppose the concept of comments that point to Wikidata, because there is no unambiguous format to determine the exact meaning of such comments, or exactly how the comment would be associated with the text in the article. Such a situation is an invitation for people to write bots that screw things up. Jc3s5h (talk) 12:20, 10 May 2018 (UTC)[reply]
• We should not link to wikidata at all. Inline interlanguage links have always been discouraged in practice (notice how few of them exist). There is no reason to add an exception for Wikidata about them. — Carl (
  CBM · talk) 12:40, 10 May 2018 (UTC)[reply
  ]
• Support with exception for interlanguage links per Jc3s5h. Ealdgyth - Talk 13:16, 10 May 2018 (UTC)[reply]
• Support with exception for interlanguage links per Jc3s5h and Ealdgyth. ILLs may be rare due to the fact that the English Wiki is currently standing at 5,646,567 articles, well ahead of most other languages (wp:List of Wikipedias). (Indeed if you ignore those articles written by Lsjbot, well over double the size of any other Wiki.) Therefore few articles will appear in another language and not in English, except for small geographic features and locally notable persons. ILLs are invaluable for setting up a link that can be subsequently translated either full or as guidance. When I was working on Peter Harlan I used an ILL to get the basis of the article and there are still ILLs for Cornelia Schröder-Auerbach [de], Hanning Schröder and Castle Sternberg [de] within it. It means the reader has at least the possibility of finding the information until someone has the time to create an English version. Martin of Sheffield (talk) 13:40, 10 May 2018 (UTC)[reply]
• Oppose any restriction per my comment in the previous RfC. This an utter baby-with-the-bathwater case, which would disallow links to Wikidata in tables, for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 10 May 2018 (UTC)[reply]
• Mu I'm all for creating a policy to explain how and what sorts of links are useful. This sort of RFC, which is too restrictive and too ignorant of nuance, is not the way to do it. --Jayron32 14:51, 10 May 2018 (UTC)[reply]
• I cannot choose any one of the four options, although the closest thing would probably be "support with exception" + "allow hidden comments".
  the proposer is indeed in support of this, is patently ridiculous and unnecessarily heavy-handed, especially since these are not actually links and readers aren't supposed to see them. I don't think it's necessary to lump them together with real working links. Aside from the issue with hidden comments, I think the RfC should be clarified to indicate that the proposer is, at least according to their own words, in support of the status quo that currently exists. Jc86035's alternate account (talk) 15:06, 10 May 2018 (UTC)[reply
  ]
• Support—there are far too many issues with WikiData's implementation and with WikiData-folk contemptuously imposing WikiData on articles beyond the control—or even awareness—of the custodians of Wikipedia articles. This shouldn't be re-opened for discussion until it can be clearly demonstrated that all the issues—both technical and behavioural—have been dealt with. Curly "JFC" Turkey 🍁 ¡gobble! 00:32, 11 May 2018 (UTC)[reply]
• Oppose A QID or URL in a comment is a good way to tip about the existence of the article in sister sites. At this stage practices are evolving and improving every day, but banning such info would just kill innovation. Syced (talk) 06:29, 11 May 2018 (UTC)[reply]
  • Note: This editor has acknowledged[2] arriving at this RFC via the
    partisan-audience advertisement at Wikidata. Alsee (talk) 01:33, 13 May 2018 (UTC)[reply
    ]
• Oppose. The only reasonable usage of linking to wikidata (as opposed to pulling data from Wikidata, which the topic starter explicitly excluded from this RfC by saying it has no impact on {{
  ill}} or just a number commented out is debatable, but I am not looking forward for this debate, as this RfC is very badly organized (similarly to the previous one) and is very untimely (similarly to the previous one).--Ymblanter (talk) 07:01, 11 May 2018 (UTC)[reply
  ]
• Support- with the possible exception of interlanguage links. From what I've seen of WikiData, its content is confusing, often mostly empty, and frequently erroneous. As Curly points out, it feels lioke this junk is being inflicted on Wikipedia with minimal oversight. I'd put a moratorium on the use of WikiData until we can be satisfied that we're not just rubbishing our standards of accuracy. Reyk _YO! 07:08, 11 May 2018 (UTC)[reply]
• Support until such time as Wikidata develops a better reputation for fact-checking, referencing, and accuracy, especially for details such as citizenship of living people (often listed, rarely sourced). —David Eppstein (talk) 07:24, 11 May 2018 (UTC)[reply]
• Support - not a community based here.--Moxy (talk) 11:56, 11 May 2018 (UTC)[reply]
• Oppose Banning comments is excessive, and doesn't seem to have had any justification given. Limited use of {{
  ill}}-style links in tabular material and lists could also be useful. Jheald (talk) 18:39, 11 May 2018 (UTC)[reply
  ]
• Support. Wikidata links are an inappropriate destination, except perhaps in the Wikidata article or other articles actually discussing Wikidata. In rare cases I could see a valid purpose for a hidden comment mentioning Wikidata. However hidden links are inappropriate without some unusual need in the specific case. Links to foreign language articles are generally a bad idea for a number of reasons, but sending a reader to Wikidata for interlanguage links is even worse. Alsee (talk) 02:56, 13 May 2018 (UTC)[reply]
• Support. Sending readers to Wikidata is very rarely helpful, and if an editor believes that more information about a redlink or an unlinked term / name is needed, it would be better if they added a reliable source as a reference to it. The same applies to the vast majority of regular interlanguage links in our articles.
  Fram (talk) 13:33, 17 May 2018 (UTC)[reply
  ]
• Support.
  Rusf10, I'm not sure what "with exception for interlanguage links" has to do with the question "Should we ban links to wikidata within the body of an article?" SarahSV ^(talk) 14:13, 17 May 2018 (UTC)[reply
  ]

  SarahSV I believe wikidata interlanguage links refers to replacing a redlink Jokery with Jokery [Wikidata], which sends the user to the bottom of a Wikidata page. In my opinion the typical reader will WTF when they see the link, and they'll be confused as hell if they click on it. Alsee (talk) 09:26, 18 May 2018 (UTC)[reply]

  That's really confusing. I was thinking more along the lines of

  Rusf10 (talk) 14:24, 18 May 2018 (UTC)[reply

  ]

  Rusf10, that's what I thought. It might be worth striking through that option, because those links have nothing to do with Wikidata that I know of, so it introduces a confusing tangent. SarahSV ^(talk) 16:08, 18 May 2018 (UTC)[reply

  ]

  @

  Rusf10 (talk) 16:19, 18 May 2018 (UTC)[reply

  ]

  Rusf10, you could be right, in which case it's a good idea to offer it as an option. SarahSV ^(talk) 17:21, 18 May 2018 (UTC)[reply

  ]

• Support. Disruptive without sufficient utility for almost all readers. Who actually uses Wikidata? My guess is a special type of reader. I have no objection if Wikidata links are added where they're easy to find and unobtrusive—in the "See also" section at the bottom, or some such. Tony (talk) 14:23, 17 May 2018 (UTC)[reply]
• Support with the two exceptions. My reasoning is basically the same as that of David Eppstein who put it more succinctly than I would have. At some point, we can work-in an exception for WD material that is sourced to en.wp standards, when WD provides a means for us to be certain of this. WD-provided information would be useful for certain things, especially tabular data. But we're just not there yet. This project's
  FUD at the RfC.  — SMcCandlish ☏ ¢ 😼  12:56, 20 May 2018 (UTC)[reply
  ]

@

Rusf10 (talk) 04:12, 20 May 2018 (UTC)[reply

]

Given what looks like an emerging consensus to not dump our readers into the middle of a WD page as if it's an article, I would expect that {{

ILL}} would be changed to no longer do that, or to not do it when used in mainspace, or to put a red warning if done in mainspace (to permit the possibility in some circumstance we haven't accounted for, but which is rare), etc. I wouldn't dwell on this particular detail here and now.  — SMcCandlish ☏ ¢ 😼  12:56, 20 May 2018 (UTC)[reply

]

• Support with the two exceptions. Wikidata links can be useful external links, when used with consensus, as in the {{Taxonbar}} template), but direct links to Wikidata are not appropriate in the body of an article any more than a link to any other external database would be. Peter coxhead (talk) 05:58, 19 May 2018 (UTC)[reply]
• Support Wikidata links should not be allowed in either the Lead or the Body of the article. I'm agnostic on links in infoboxes, external links, etc. LK (talk) 06:53, 20 May 2018 (UTC)[reply]
• Oppose. I definitely support inline inter-language links and hidden-text Q numbers. That said, I support removing wikidata links from non-notable subjects where the sole purpose of the link is disambiguation. I'm not sure where the guideline is on this, but I believe inter-language Wikipedia links should always be required to meet
  WP:N. If there's debate, I expect the person arguing for the link to begin a draft on the subject. However, I think this blanket restriction on Wikidata links is too broad. Daask (talk) 20:27, 29 May 2018 (UTC)[reply
  ]
• Support with two exceptions - per SMcCandlish. Furthermore, Endorse SMcCandlish on not letting the ILL template dump a reader onto wikidata from mainspace easily. Tazerdadog (talk) 01:49, 1 June 2018 (UTC)[reply]
• Oppose. They're not often going to be useful but as exceptions to that are possible it doesn't make sense to ban it. For the same reasons we don't ban links to the Esperanto Wikipedia or the Daily Mail - just because they are not often helpful doesn't mean they never are. Thryduulf (talk) 09:28, 3 June 2018 (UTC)[reply]
• Support, with possible exceptions by specific consensus after verifying the specific Wikidata entries. Links are almost always confusing to readers. Invisible comments are only helpful to editors if it is probable that Wikidata does not have multiple entities conflated with the same index and multiple indicies covering the same entity, which is, at best, not proven. — Arthur Rubin (talk) 05:35, 4 June 2018 (UTC)[reply]

*Support. Tony (talk) 06:25, 4 June 2018 (UTC) [Sorry, mistakenly posted support twice. Tony (talk) 03:34, 5 June 2018 (UTC)[reply]

• Support I have just seen a horrendous example of circularity caused by this. Wikidata simply does not have the controls necessary to make it a worthwhile addition and it has the potential of allowing people to game en-WP's controls. - Sitush (talk) 13:44, 4 June 2018 (UTC)[reply]
• Support ban, per others, and per my essay about the godawfulness of Wikidata for the accuracy of Wikipedia's articles. Outriggr (talk) 02:47, 6 June 2018 (UTC)[reply]
• Oppose – I've placed several-to-many inter-language links and find them helpful. I have no opinion on the other usages. However, the proposal makes no distinction, although several supporters of the ban do. Dhtwiki (talk) 19:03, 6 June 2018 (UTC)[reply]

Overlaps with another RFC

• Please note - This RFC overlaps somewhat with another that is still ongoing (see Wikipedia:Wikidata/2018 Infobox RfC). I do not believe that there is any intentional forum shopping involved... but we do need people to know that similar questions are being discussed elsewhere. Blueboar (talk) 15:01, 10 May 2018 (UTC)[reply]

Thank for letting me know about this, I will add a statement above to clarify the proposal will not apply to infoboxes since that is being decided elsewhere.--

Rusf10 (talk) 16:07, 10 May 2018 (UTC)[reply

]

Fair enough. However, please note that the other RFC has grown beyond just discussing infoboxes. It may be better to put this discussion “on hold”... Until we see how the other closes. Blueboar (talk) 16:36, 10 May 2018 (UTC)[reply]

Disagree strongly. This RfC is straightforward and already looking like a

WP:SNOWBALL. That other RfC is a sprawling mess of 1A, 3C, etc. options, from which obviously no consensus is going to emerge, other than possibly the one that points in the same direction this RfC is going. Virtually every single answer there conflicts with ever other answer, except that multiple respondents are arriving at the most-restrictive option (1A+2A+3A+4A). It's a textbook example of why to not structure RfCs that way. Ask one question, then do another RfC to ask another question. Also, as I commented over there, the excessively geeky structure and wording of that RfC basically makes it invalid: it's heavily skewed toward the input of IT professionals (few who are not in that camp will be able to parse it), and they have a strong bias in favor of data centralization and automation.  — SMcCandlish ☏ ¢ 😼  10:27, 18 May 2018 (UTC)[reply

]

I do not see it is straightforward, since different users are clearly addressing different issues, and the RfC question has been amended already during the RfC. I opened a proposal below to close it as invalid.--Ymblanter (talk) 20:19, 18 May 2018 (UTC)[reply]

That's not true! Since the day the RFC opened the question has been "Should wikidata be linked to in the body of the article?" as it is now. Stop trying to mislead people, just so you can shut down debate and get your way.--

Rusf10 (talk) 20:30, 18 May 2018 (UTC)[reply

]

No closer would shut this down as "invalid", because the course emerging is clear, as is the question, and that course matches the one at the other RfC (see the analysis I posted at bottom over there, to counter some similar snow-jobbing that was going on). The two discussions are in close synchrony. And whether some commenters choose to raise additional related issues that occur to them has nothing to do with the validity of an RfC; show me any RfC where this doesn't happen. What this all really comes down to: We all want WikiData to work, but the WD editors and their promoters on en.WP (to the extent they're not the exact same people, which may be 0%) have to do the work on the WD side to enable en.WP to filter WD data for en.WP policy compliance (and so on for other sites), or we simply can't use it, any more than we'd copy-paste content from any other website just because it was open-licensed, without also verifying the content and being able to control is appearance here. We'd never inline anything from another site where random people can change it and thereby instantly change what appears on Wikipedia, unless we can some way to control, undo, be alerted, etc. Even then it's a really, really iffy idea. The fact that WD in particular has received some WMF money doesn't change that. They fund all kinds of things that aren't pipelined directly through en.WP into readers eyes and brains.  — SMcCandlish ☏ ¢ 😼  23:28, 18 May 2018 (UTC)[reply]

SMcCandlish, what you write demonstrates very clearly that the two of us, to start with, understand the question of this RfC very differently. For me, it has nothing to do with the reliability of Wikidata (whereas another one does). The RfC does not define what "links" mean. It does not specify what is its scope - are templates which are not infoboxes included? Are hidden comments included? Nobody directly links to Wikidata now in the articles (with the exception I guess the article Wikidata). It is pretty clear from the comments of the !voters that they understand the scope differently. The RfC was not properly prepared. And the RfC with an unclear scope must be, well, closed as invalid.--Ymblanter (talk) 05:32, 19 May 2018 (UTC)[reply]

None of that is a problem we're unfamiliar with or incapable of dealing with. Many RfCs involve later detail clarification and hashing-out. RfCs are not legalistic or robotic processes; they are calls for discussion. One discussion leads to another. We do not try to shut down discussions, unless they are disruptive for some reason. The more detailed RfC covers, well, the details. This more general RfC takes an overall pulse, and it's beating with the same heart as the leading cluster of responses to the more detailed RfC. This one demonstrates (in being neither dominated by WD boosters nor mired in complex details only understood by entrenched WD boosters and WD critics) that the consensus emerging at that one (despite the cluster of WD fans gathered there) isn't false. Next, when different respondents have differing but compatible and rational reasons for arriving at the same conclusion, this makes the conclusion stronger, not weaker. The fact that one person cares more about data verifiability (over time, not just once), while another cares about editorial complexity and confusion, and another about something else, doesn't invalidate anything at all. Any proposal can raise multiple concerns. If this RfC isn't limited to infoboxes, then it isn't. It's also clearly about pulling data directly from WD; so, no, it's not about HTML comments. We might end up not needing those, depending on how and if WD integration into en.WP proceeds, and how WD evolves to deal with the core policy problems being raised at multiple other sites. But for now, I've agreed with you that trying to expunge Q numbers in HTML comments is overkill and even a net negative.  — SMcCandlish ☏ ¢ 😼  12:47, 20 May 2018 (UTC)[reply]

Proposal to close

Since the RfC so badly formulated that the participants do not really understand what is exactly asked, and one week after it was open new proposals appear (which are not reflected in the past votes), and the proposer says that they are thinking about adding new options, I propose to close this RfC as invalid. Any user in good standing can open a new one, formulating the options clearly and not changing them as the RfC runs its course. I would have also suggested to topic-ban

@

Rusf10 (talk) 20:27, 18 May 2018 (UTC)[reply

]

[3]. The rest of your comment are baseless personal attacks. RAN is not "my friend", it is still not clear whether the proposal covers for example {{

commonscat}} and other similar cases (and it is too late to clarify ot now), and I am not going to strike anything. It is up to administrators to listen or to not listen to my opinion in this section.--Ymblanter (talk) 20:41, 18 May 2018 (UTC)[reply

]

People appear to be confusing a clickable link with a hidden annotation. There is no clickable link that Rusf10 is removing, he is removing hidden Wikidata Q-id annotations such as <!--Q1234567-->. They are used to properly disambiguate people that do not have Wikipedia articles, but have a Wikidata entry with more information on them. The annotation is only visible to someone editing the article. They let a future editor know that the person in the table of "Mayors of X" is the same guy appearing in the article on "X Township" and the article on "X Cemetery" and that the person has a photo in Wikimedia Commons. It lets a future editor know that the James Smith in one article is the same as the Jimmy Smith in another article and same person as the James Smith named in a quote in another article. People also seem to be confused about the !vote, it is not a binary support/oppose !vote. They are writing "support" without choosing one of the five mutually exclusive options, it is not clear what they are supporting. --RAN (talk) 20:46, 18 May 2018 (UTC)[reply]

Interpersonal venting aside, yes, the HTML-comment annotations should not be deleted since they're harmless, serve a useful function, don't cloud the code very much, and are invisible to readers. It would probably be preferable if there were another way to do it. Maybe the system being worked on to shunt CSS code for pages, and various metadata for templates, into special subpages could also be adapted to this purpose. I'm not really clear on the details of that work, and haven't looked into it all in months, so someone else should who understands it better can probably chime in about whether that's feasible.  — SMcCandlish ☏ ¢ 😼  23:31, 18 May 2018 (UTC)[reply]

@

Rusf10 (talk) 00:49, 19 May 2018 (UTC)[reply

]

Call me out on what? On that you have opened a second RfC with an unclear scope? Is it exclusively about {{

ill}}? Then it should have been in the RfC question, and it is not. If it is about anythong else, it should have been in the question. Nobody is linking the Wikidata from the body of the article directly. You opened another "Wikidata vs anti-Wikidata" shitstorm, and the result of the storm will be nothing because you could not even define the question properly.--Ymblanter (talk) 05:36, 19 May 2018 (UTC)[reply

]

The RFC is crystal clear, it is about linking to wikidata in the

Rusf10 (talk) 06:38, 19 May 2018 (UTC)[reply

]

Again, the example you have given is linking to Wikidata next to a redlink which can not be a valid article. Red links which can not become valid articles are not allowed. Period. We do not need an RfC to establish this. Concerning possible Wikidata links next to valid redlinks, this has whatsoever no relation to reliability of Wikidata, because the function of such a link (which is next to a redlink) is not to provide information, but to facilitate future linking. If a Wikidata has an item about X, it stays forever an item about X, even if it gets vandalized or sourced to unreliable sources. If someone links to Wikidata from the body of the articles (not in templates), and these links are unrelated to Wikipedia redlinks, I would like to see an example. Instead, we have the whole rant again "Wikidata is not reliable, OMG". Just because of the way you formulated the question and because you did not care to discuss it with anybody before running it live. This is why we have supports which are actually opposes, and opposes which are actually supports.--Ymblanter (talk) 06:53, 19 May 2018 (UTC)[reply]

And please stop telling me such as "your cause" and "your case". My cause is to improve Wikimedia projects, including the English Wikipedia. I have been doing it for years, and I am currently one of 500 most active editors here of all times. If you believe I have a double agenda pls go to ANI, but stop saying it here.--Ymblanter (talk) 06:56, 19 May 2018 (UTC)[reply]

(1) I don't think there's any serious problem in relation to the other RFC. During the drafting of the other RFC, there was a deliberate decision to focus on infoboxes. This RFC focuses on the body of the article. There are wide-ranging discussions and arguments spilling over to both areas, but I don't see any inherent-or-likely conflict in allowing the RFCs to proceed in parallel.

(2) Concerns have also been raised about the formulation, scope, or intent of this RFC. I don't think it would be productive or appropriate to invalidate and restart the RFC. We've got substantial and productive examination of the issues invested from many people, and I believe participants have a reasonable understanding of at least the generalized topic. Either the !votes and discussion will be sufficient for the closer to sort out the issues, or the closer may may be able to provide a partial result and/or guidance on exactly what unresolved point(s) we need to focus on in any new RFC. Alsee (talk) 18:40, 20 May 2018 (UTC)[reply]

• Note to closer If this is closed with no clear consensus, please restrict when it can be brought to RFC again. We really do not need to go through this every two months. It consumes a huge amount of time. The issue is complex, involving half a dozen permutations. The sister RFC on WIkidata and Infoboxes has over a dozen permutations. --RAN (talk) 20:17, 20 May 2018 (UTC)[reply]

  unfortunately, I think this is going to need further RFCs... we are going to have to explore each permutation separately (rather than all at once)... so we can better determine consensus on which permutations the community approves of, and which it does not. Blueboar (talk) 20:33, 20 May 2018 (UTC)[reply]

  @

  Rusf10 (talk) 23:30, 20 May 2018 (UTC)[reply

  ]

  Is that what all this fuss is about? You wanting to remove links to Wikidata in a table that you have not contributed to, and have no interest in reading. It is kinda silly overkill. You can always just not look at what I am editing, have you tried that? --RAN (talk) 01:27, 21 May 2018 (UTC)[reply]

  So what is the intended audience for that article? yourself? Articles should be easy to read for the average person, not contain complex tables scattered with links to another website that is even more confusing. Wikipedia is an encyclopedia, not an extensive database for every person who has ever lived. If that what you want to do over at wikidata, by all means, I have no opinion on what goes on there, but I think I speak for most people on wikipedia when I say, I do not want that massive unreliable database spilling into the content here. Reliability issues aside, the fundamental question is does anyone want to see wikipedia get changed from an encyclopedia to a database full of every trivial bit of information that can be found.--

  Rusf10 (talk) 01:44, 21 May 2018 (UTC)[reply

  ]

  "a table that you have not contributed to" is illegitimate reasoning here, Richard. See

  WP:ENC

  . Everyone is here to work on content (and its presentation, categorization, policy compliance, and all other facets). It is never, ever required that one has to have previously been an editor at a page before one can have anything to do with its current and future direction. Otherwise WP would have no articles, because no one would have any standing to every write any in the first place. But this isn't about any particular articles anyway, it's about whether en.WP policies will be respected and enforceable on en.WP or whether WD editors can ignore them with impunity and inject their unvetted content into this site.

• Or you can stop stalking my edits, and get the same effect. There are 5,650,219 articles in the English Wikipedia you still have not nominated for deletion. By concentrating on one article, you are neglecting all the other articles that can be deleted. Use better time management and maximize you deletions stats. --RAN (talk) 03:25, 21 May 2018 (UTC)[reply]

  You really don't want to go down that road, just think about the last ANI you opened, do I need to keep going? Back on topic, you still haven't explained the value of using the ILL template for articles that do not exist in another language.--

  Rusf10 (talk) 04:23, 21 May 2018 (UTC)[reply

  ]

  It is irrelevant whether articles exist in another language or not. They may exist and be not notable for our standards, or they may not exist and be notable. What is important here is notability.--Ymblanter (talk) 07:16, 21 May 2018 (UTC)[reply]

• I tend to support the moratorium idea (and have no idea where the suggester of it, Blueboar, stands with regard to which issues raised). This is tedious rehash, and the next round will be, too.  — SMcCandlish ☏ ¢ 😼  23:42, 24 May 2018 (UTC)[reply]

Modified Proposal

In an effort to make the RFC come to a clear consensus, I'd like to purpose the following: Wikidata may not be linked to within the

• I'm not a fan of any of the links being discussed. Even for interlanguage links to an existing article somwhere, I have concerns about clutter, few readers being able to read them, few readers understanding what the links are unless they blindly click on them, and the open door for promotional or policy-subverting ILLs to non-notable or otherwise problematical cases. If an article or redlinks or red-template-links are being deleted here, we don't want that user trying to manufacture an appearance of legitimacy with ILLs to an unpatrolled microwiki. Alsee (talk) 07:26, 24 May 2018 (UTC)[reply]

I agree with you, ILLs are a mess and ideally I'd like them banned but I'd prefer this compromise over keeping things the way they are. A majority of people above support restrictions on wikidata links, but what to do with ILLs is what no one seems to agree on.--

Rusf10 (talk) 07:31, 24 May 2018 (UTC)[reply

]

• I tend to agree with Alsee. It's not actually helpful to our readers in the aggregate (only to some individual readers by the random accident of what other language they're fluent in) to put something like "
  albondigas [es]" in an English-language article. Driving them sideways to a WD page full of raw data that isn't subject to our (or any other Wikipedia's) verifiability policy seems even worse. If it came down to a choice between limiting the WD restrictions to just ILL and a few other exemptions, or having no restriction on WD's use at all at en.WP, I'd side with the former. But I don't think that's where this heading. The strongest showing for any option, at both RfCs, is in favor of not using WD here until WD has a way to ensure compliance with our policies for material that would be shoehorned into this site from that one.  — SMcCandlish ☏ ¢ 😼  23:50, 24 May 2018 (UTC)[reply
  ]