Wikipedia talk:Manual of Style

Should South Africa articles use "continental system" numbers?

I have started a discussion at Wikipedia talk:WikiProject South Africa#Should South Africa articles use "continental system" numbers? which could benefit from MoS and WP policy regulars. It was prompted by edits changing South Africa to 12 345,6 format. Searching the MoS talk archives revealed lengthy discussion Grouping of digits and also Indian currency number conventions.

I am supposing that MOS:ENGVAR applies to number formats - dates are mentioned explicitly, though numbers are not. Batternut (talk) 01:35, 21 December 2017 (UTC)

Definitely shouldn't be in "12 345,6" format on en.Wikipedia, per WP:Manual of Style/Dates and numbers#Decimals: "A period/full point (.), never a comma, is used as the decimal point (6.57, not 6,57)." The "12 345,6" style is almost entirely non-English, and to the minor extent it's used in English it's ambiguous and not understood by the majority of our readers. They all do understand "12,345.6" and "12345.6" (which cannot actually be said for "12 345.6", though "12 345.6" with a &thinsp; thin-space character is marginally less awful and geeky; we're using that in some technical articles, but not everyone is happy about that).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:18, 21 December 2017 (UTC)

MOS:DIGITS says   is problematic for screen-readers. Thus {{val}} and {{gaps}} seem the preferred if not the only way to do gap separation.

I understood SMcCandlish's "Definitely shouldn't" to apply to commas for the decimal mark, but that 12345.6 can perhaps grudgingly be used. Wikipedia talk:WikiProject South Africa#Should existing South Africa articles be changed to use gaps as thousands separators? discusses imposing gaps across all South Africa articles. Batternut (talk) 21:04, 22 December 2017 (UTC)

The really imposing gap is in Arizona, though.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:33, 23 December 2017 (UTC)

NHR says that spaces should be used in technical contexts, otherwise commas. It is probably safer to stick with commas only, but a change in policy doesn't seem to be required at this time. –Sb2001 00:34, 3 January 2018 (UTC)

Proposal: Adopt WP:WikiProject Video games/Article guidelines into MoS

Should WP:WikiProject Video games/Article guidelines be moved to WP:Manual of Style/Video games, as part of the MoS?  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:33, 22 December 2017 (UTC); revised 18:06, 22 December 2017 (UTC)

Background and rationale: I'm normally skeptical about wikiproject advice pages, since most of them are represent single narrow viewpoint, conflict with site-wide guidelnes, and haven't been worked on since the mid-2000s. However:

• This one is comprehensive (for the topic), as well as actively maintained and stable (as such things go).
• It really is all style material (in successive sections with subsections: relevance, tone, and sectioning; spelling, italics, punctuation, capitalization, jargon, and similar style details; then image usage).
  • Many such wikiproject pages are dumping grounds for all kinds of stuff about topical notability, original research and independent sourcing, etc., but this one is not; non-style material is only touched on, appropriately, in WP:SUMMARY style and cross-referenced to the main pages on such matters.
• It's been tagged with {{Guideline}} for over a decade, and I don't see any controversy about this since 2007. VG articles actually seem to be following it, which means it can be taken as a legitimate guideline.
  • However, it's aberrant for a guideline to be in the "Wikipedia:WikiProject" sub-namespace; this implies (and can frequently lead to) WP:OWNership over its content. An actual style guideline should be in "Wikipedia:Manual of Style/" (and a non-style one directly in "Wikipedia:").
  • This move was actually previously done unilaterally and without discussion, then reverted, on 3 December 2013. It wasn't a bad idea, but needs an actual WP:PROPOSAL like this one.
• It appears to be consistent with MOS (and other WP:P&Gs) throughout; the page history demonstrates a continual maintenance effort to keep it synched with site-wide best practices.
  • Many such pages are full of "here's how we want to defy the rules because our topic is magically different" nonsense; this isn't one of them.
• The move would be consistent with MOS:TV, MOS:FILM, MOS:FICTION, MOS:COMICS, MOS:ANIME, etc. The video game guideline has already had a MOS:VG shortcut for years, which is confusing if it's not part of MoS. This probably could have been done via WP:RM but I like to be formalistic about adding pages to MoS proper, to avoid later disputes.

The only cleanup work it seems to need is some copyediting to be more concise; better cross-referencing to other parts of MoS (which may also result in more concision – one can simply state a rule and link to where it is, rather than restate the rationale for it); and removal from the lead the statement that it's a wikiproject page; then the appropriate page-top template and categorization, updates to shortcuts, and addition to the {{Style}} navbox.

PS: The only other WP:PROJPAGE I know of that is MoS-ready is Wikipedia:WikiProject Computer science/Manual of style (for a similar pattern of good reasons). It should either be moved to Wikipedia:Manual of Style/Computer science or Wikipedia:WikiProject Computer science/Style advice. See also previous thread about merging salvageable parts of the abortive WP:Manual of Style/Computing into it. I've recently found several abandoned wikiproject pages at "/Manual of Style" names and moved them to "/Style advice" names because they were clearly not guidelines, were not MoS-compatible, and were just low-input essays or even {{Failed}} proposals; I tagged some of them with {{Superseded}} when applicable, pointing to current MoS sections that cover the same stuff in currently maintained and accepted ways.

 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:33, 22 December 2017 (UTC); revised 18:06, 22 December 2017 (UTC)

Comments on MOS:VG

• Support per nom. jd22292 (Jalen D. Folf) (talk • contribs) 01:40, 22 December 2017 (UTC)
• Support - assuming there is no downside to this, which it doesn't appear to be. ~ Dissident93 ^(talk) 01:49, 22 December 2017 (UTC)
• Support no glaring problems like, no or must have infobox. ..or can't link to so and sI etc... Would like to see User:SMcCandlish trim this a bit.--Moxy (talk) 03:12, 22 December 2017 (UTC)

  It's worth doing it slowly and in stages, though.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  04:22, 22 December 2017 (UTC)

• Support I read through it and it seems good. Galobtter (pingó mió) 04:18, 22 December 2017 (UTC)
• Support I am in agreement, it makes sense to move it._{ZXCVBNM (TALK)} 11:50, 22 December 2017 (UTC)
• I have quibbles with parts of the page here and there. Some of it gets more into "what a video game article is (not)" and strays away from the style aspects, or touches a bit more on categorization aspects than style, (or... x-not-quite-MOSy-thing) but our MOS is not exactly a traditional MOS either. Broadly, support, and we can talk through the parts that might be better off in other places (or centralized, as I've discussed elsewhere with SMC). --Izno (talk) 12:38, 22 December 2017 (UTC)

  Most of the topical MoS pages do that. This page is one of the least problematic in that regard, and it's easily cleaned up, to the extent is needs it. More on that in the extended discussion section.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:06, 22 December 2017 (UTC)

• This is probably the most obvious exception to the way we usually think about WP:Local consensus... it is a “project” guideline that has input from a very large group of editors and is strongly supported by the entire community. Because it IS project related, and covers more than just style, it is not really appropriate to call it an MOS page. Yet because it IS so strongly supported, there is a desire to “promote” it out of being just a “project” guideline. Yet because it IS so strongly supported, there is a desire to “promote” it out of being just a “project” guideline. I would say leave it where it is... but think of it as having the same WEIGHT as an MOS page. Blueboar (talk) 14:52, 22 December 2017 (UTC)

  Replied in the extended discussion section.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:06, 22 December 2017 (UTC)

• Broad support as natural evolution/maturing from project- and scope-specific guideline to a project-wide one. Since we don't really have topic-based guidelines (yet), the MoS seems as good target as any following existing precedent. Individual issues with guideline can be resolved as needed. It seems broad, neutral, based on existing guidelines/policies, despite originating in a single project (a large one though). —  HELLKNOWZ   ▎TALK 19:36, 22 December 2017 (UTC)
• Oppose, only because it does not yet seem clear how the VG project retains its "control" on this. We at the project clearly are trying to stay in the bounds of established MOS, the last thing we want to do is fork the existing MOS as if we are s pecial. That said, the content that goes beyond MOS like article guideline suggestions are things we as interested BY editors move quickly on that potentially would be bogged down by having this as a project wide MOS. O appreciate that the page is recognized as a good basis, but I am very concerned that trying to elevate project level guidelines to wp-wide ones loses some of the project's capabilities. --Masem (t) 08:30, 23 December 2017 (UTC)

  Not sure what to tell you other than a) if the goal is for a small cadre of editors to control the page, then it's not a guideline (though I don't think that really is the intent); and b) it's not been a problem for TV, movies, anime, comics, fiction/novels, popular music, classical music, etc., nor numerous sports, or country/ethnicity/language projects, nor various fields like mathematics, law, medicine, and so on. If there's just some nebulous concern along "those Others from MoS are going to tell us what to do" lines, that's actually a less likely outcome if this becomes part of MoS, since it's then part of the MoS gestalt instead of some page most of us probably thought of as an essay (to not care much about), or weren't even aware of.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:41, 23 December 2017 (UTC)

• Oppose. I don't see the upside. The content doesn't warrant any increase in standing than what it currently has as a project advice page. And I say that as a major contributor... If these sorts of pages need title standardization, I'd sooner see them grouped as "topical advice" than "style guidelines". (not watching, please {{ping}}) czar 16:37, 23 December 2017 (UTC)
  • The upside is that the community backs it, not just the cache of editors hiding out on WT:VG. No questions ever elsewhere of "it doesn't say 'guideline' on it", of which we have had a few before. --Izno (talk) 18:49, 24 December 2017 (UTC)

    But last I checked, the page functions as topical advice, not as a guideline with firm expectations, e.g., WP:WAF. It's more like a codification of common sense, but its text is not delivered as gospel and editors are freer to disagree than they are with MoS guidelines. czar 02:03, 26 December 2017 (UTC)

• Oppose -It functions exactly as it should now. If we start having issues like "Hey, that not an official MOS, so I'm not following it" I'd reconsider, but I experience this very little, if ever. We've worked very hard to make this, and it works. I don't want to risk breaking it by shoe-horning it into a different standardized form. Sergecross73 msg me 15:08, 24 December 2017 (UTC)
  • Meaning what? No one has mentioned any standard form or a shoehorn.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:58, 24 December 2017 (UTC)
    • Well, it sounds like there's more to it than just renaming it something with MOS on the name, or you would have just done it and not had this discussion. Sergecross73 msg me 04:45, 25 December 2017 (UTC)

      Nothing more to it at all. As I said in the opening statement: "This probably could have been done via WP:RM but I like to be formalistic about adding pages to MoS proper, to avoid later disputes." Various pages have previously been added to MoS without discussion, with such moves later being reverted as undiscussed, and sometimes outright objected to (e.g. because the projpage is question is a terrible pile of WP:CREEP and WP:OWN – which this page isn't, though I detect a disturbing level of OWNishness in the oppose comments so far, enough that should this MoS merger fail, it's likely to result in another RfC to demote this back to a WP:PROJPAGE essay. There is no such thing as a WP guideline that is completely controlled by a tiny handful of wikiproject people. I.e., WP:VG is badly sabotaging its own interests here.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  22:22, 25 December 2017 (UTC)

      • Its nothing more than "If its not broke, don't fix it", so please assume good faith. "Sabotage" is a stupid word choice for choosing to retain something that functions as a well oiled machine too. Sergecross73 msg me 00:47, 26 December 2017 (UTC)

  • We have had at least one editor suppose that WP:VG/GL is "just" a project page simply because it has not gone through the WP:PROPOSAL process, and I have gotten a similar feeling from a few others as well, though nothing explicit. If it works--and it does--then we should put it to the community, as has been done for this discussion, and let the community decide if it actually works. I don't want to risk breaking it by shoe-horning it into a different standardized form. I think this gets to the comment ferret made, but I'll reply to him separately. --Izno (talk) 18:49, 24 December 2017 (UTC)
    • Well, it's hard to respond without you explaining what exactly you're talking about, but I've been pretty active with WP:VG since 2010-2011, and I can't think of any times where an actual consensus was affected by this. Some random grumbling? Sure. But nothing that actually affected things. Sergecross73 msg me 04:45, 25 December 2017 (UTC)
  • Oh, and lastly: It would encourage users to engage with the page who are not typically video game writers, as well as allow us to refer to the page authoritatively (especially with newbies!) as the guidelines. (I'm thinking of another writer who went against the Layout expectations set out in WP:VG/GL.) --Izno (talk) 18:56, 24 December 2017 (UTC)
• Support - Our MOS is a resource for editors. As such, it is the obvious place to go when one wants to know this or that about Wikipedia's house style. Project pages exist more for content collaboration and, as such, are not nearly as obvious a location for style guidance. If style advice on a certain topic has widespread (not only project-wide, but site-wide) support, then not putting it in our MOS does a disservice to editors and, ultimately, readers. Primergrey (talk) 16:19, 24 December 2017 (UTC)
• Oppose Per Blueboar, Masem and Serge. I have concerns about statements that it needs a few things removed or trimmed before it's truly suitable and "100% style". What will ultimately be removed? What is WP:VG's say on that? If the result is that our current subpage, "Article guidelines", moves to MOS, but we have to create a brand new "Article guidelines" to cover the things removed, we have split our guidance on VG articles and made it more difficult to point users to said guidance. Like Serge, I don't ever really see any challenges such as "That's just project advice so not following it". -- ferret (talk) 16:30, 24 December 2017 (UTC)

  My argument is that nothing substantive in it should be removed at all, because it's standard operating procedure for topical MoS pages to have summarized bits of naming, notability, and matters stuff in them, then referring to main pages on such matters for the details. The page in question is already doing this well, though it probably wouldn't hurt to summarize a little more and merge more, since VG already has both WP:NCVG and WP:NVG. What it actually needs work on is concision. One of several examples: "That said, it is still possible to use gaming jargon in an article. This could be of necessity if the game's concept deals closely and often with the jargon. The jargon would, however, have to be clearly explained (simple and clear sentences) before its first use in the article." This could be compressed by about 50%, retaining all the real meaning, and actually get the point across better and more memorably.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:58, 24 December 2017 (UTC)

  My comments in that direction have not been "we should remove obviously good sense entirely from Wikipedia without replacement elsewhere" but instead a) we should remove !rules that do not (obviously) jive with broader guidelines and policies (if there are any such--I've noted a few) and b) if there are matters not covering style in the document, I'd like to see those documented elsewhere as not-style issues. We do a disservice to our editors currently by not distinguishing style from content guidelines--across the board for topical matters, even, not just with respect to video games. As I said, I'd prefer to see it in a different form from today, but that's not a discussion that is make or break. (And clearly, I am but one editor.) --Izno (talk) 18:49, 24 December 2017 (UTC)

• Support—there are compelling reasons that matters of style and formatting throughout en.WP, let alone within these related wikiprojects, should be harmonised. WP's high-level policies reject the notion of ownership, and that seems to be what is fuelling some editors' objections. They should be disregarded. Tony (talk) 00:29, 26 December 2017 (UTC)

  If it were only relegated to issues of style and formatting, I would have no problem, since that part of the VG MOS follows global MOS. But the VG guideline s are more than MOS issues, particularly related to organization, appropriate content, and notability, which are to be taken as advice, not exacting standards. One speaks of ownership issues but in my mind it is more an issue which those MOS enforcers that "own" the MOS that will try to make unilateral decisions on our content advice, which MOS should not be covering. --Masem (t) 12:27, 26 December 2017 (UTC)

• Support – The VG style recommendations seem like they fit best under the MOS, and as Tony says need to be kept in harmony. I don't see a downside to putting this as part of MOS. Dicklyon (talk) 05:54, 26 December 2017 (UTC)
• Support – Given the length and extent of the advice at WP:VGG that applies to both style and content, a portion (if not most or all of it) would seem more appropriately placed in the MOS. The film project has MOS:FILM for example, which combines both content and style guidelines. Though it is listed there, it is primarily maintained by members of the film project with occasional help from non-members. That's how it should be, and VG project members shouldn't fear the change. Others listed at CAT:MOS show how commonplace this has become. I agree with the motivation behind the proposal; the additional oversight would be a good thing. If VG members feel that some items in WP:VGG don't belong in the MOS, simply retain said items within the WikiProject when there is consensus to do so. --GoneIn60 (talk) 18:47, 26 December 2017 (UTC)
• Support per nominator. Jc86035 (talk) 09:17, 28 December 2017 (UTC)
• Support: we should also try to move the other projects' style advice into the main MoS—it is often the case that editors try to bring in what is believed to be MoS-compliant style only to be told of another set of guidelines. –Sb2001 00:37, 3 January 2018 (UTC)

  Indeed. Most of the sports-related ones could be merged into a single MOS:SPORTS with sport-specific sections.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:53, 10 January 2018 (UTC)

• Support per Sb2001.--Kevin Dewitt ^{Always ping} 19:48, 12 January 2018 (UTC)
• Support MOS:VG move to unify it under WP:MoS and increase visibility.   —  Hei Liebrecht 19:20, 14 January 2018 (UTC)

Extended discussion of MOS:VG

• Question I know this may strike on the "ownership" point above but... What impact will this have on the project's ability to make changes based on discussions and consensus that occur at the project's talk page? WP:VG/DATE, WP:JFN, WP:VGSCOPE #6, and WP:VG/MIXED for example are relatively new or recently adjusted (within last two years), that arose from such discussions. -- ferret (talk) 02:41, 22 December 2017 (UTC)

  Yes, is like to know this too, before I support. Sergecross73 msg me 03:54, 22 December 2017 (UTC)

  I don't think there'd be any real effect, judging from the other media-topical projects and associated MoS pages. WP:VG is unusually good about not WP:POLICYFORKing this page from broader guidelines, anyway – among the main reasons I think it's MoS-ready. I would suggest to just move discussions about the MOS:VG from WT:VG to WT:MOSVG. When that doesn't happen, a pointer on the latter to a discussion on the former should be good enough; I think people just want to see that it was discussed somewhere. It'll probably be mostly the same project people most of the time (low potential for dispute between the pages), but it's helpful if some unconnected WP:FRS respondents get involved – a stronger, broader consensus (WP:CONLEVEL). Can have good synergistic effects; e.g., the recent overhaul of MOS:FILM on "Production" sections can be generalized, with minimal retooling, to MOS:FICTION, and WP:SUMMARY-treated as essentially the same key points in MOS:TV, MOS:COMICS, MOS:VG, etc., and was intended to do that from the start. Wouldn't've happened if it was just some wikiproject page that none of the MoS regulars were watching.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  04:22, 22 December 2017 (UTC)

  That the VG/GL page has had discussions about content in it not on its page has actually concerned me for a bit. When it is obvious the matter that comes up at WT:VG is about the guidelines page, it should be moved to the talk page of the guide page. --Izno (talk) 12:38, 22 December 2017 (UTC)

  Sure; I just doubt anyone will flip out if there's an occasional exception, just as they don't when it happens with the other media-topical MoS pages and the associated wikiprojects.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:06, 22 December 2017 (UTC)

  I find it makes it harder to track when, where, and why changes are made to the PAG page. This one in particular has seen me needing to go Back And Forth between two separate sets of archived pages. --Izno (talk) 18:25, 22 December 2017 (UTC)

• A note: Should this have an RFC tag? --Izno (talk) 12:38, 22 December 2017 (UTC)

  We could always open an RfC to find out. EEng 13:47, 22 December 2017 (UTC)

  RFC yourself out the door. --Izno (talk) 15:03, 22 December 2017 (UTC)

  There izno need to get defensive. EEng 16:55, 22 December 2017 (UTC)

  Seemed superfluous for a question that could have been resolved at WP:RM, and has already been advertised to the relevant projects and to VPPOL and VPPRO. But I put an RfC tag on it just now.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:06, 22 December 2017 (UTC)

  I don't mind whether it's an RFC tag or an RM tag--those both have a different set of people even than those who watch VPP or VPPR. However, WP:PROPOSAL has a specific idea in mind when proposing an addition to the PAGs. --Izno (talk) 18:25, 22 December 2017 (UTC)

• Re Izno's initial comment, on not-strictly-style material: It's better for a topical MoS page to have a tight WP:SUMMARY-style segment on topical notability or naming conventions than to fork off an entire new "WP:NTOPIC" or "WP:NCTOPIC" for that if it'll say essentially the same thing in five paragraphs, instead of two sentences with cross-references to more general WP:P&G pages. It's also perfectly legit to put a notability or naming convention or whatever guideline tag on a section; we do this in various topical guidelines, and at WP:SAL, to avoid pointless profusion of short, topical pages.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:06, 22 December 2017 (UTC)

  I broadly agree with this comment (though, I note both WP:NCVG and WP:NVG :). My concern is more toward the "what is a video game-related article" side, as well as some stuff about sourcing that has elsewhere it could go (and some stuff on the current WP:VG/S that could go elsewhere also). --Izno (talk) 18:30, 22 December 2017 (UTC)

  A bit further: WP:NOT does a NOT-great job at defining what Wikipedia is, for which we are probably seeing one of effects here. There is a lot of guidance on how to write a good article and not simply how to make your article have a conformant style. --Izno (talk) 18:32, 22 December 2017 (UTC)

  Yeah, there is cleanup to do. WP:COMICS is perhaps a better example (or, rather, a clearer example of what's not better). The MOS:COMICS page has extensive material on naming conventions yet there's also a separate WP:NCCOMICS page, and last I looked at them they weren't even in agreement. It would be much better to merge and reconcile that NC material to the NC page for it, and at the MOS page leave behind either no NC material at all, or just a few-main-points synopsis with a {{Main}} pointing to the NC page. WP:VG already has this under much better control. That said, "how to write a good article on X" is a common feature of many of the better topical MoS pages; it may be the most natural way to do that, since a great article on medieval monarchs isn't going to look much like a great article on viruses or on the concept Chicano. MoS, though, does have it's MOS:WBA general, non-topical supplement page (why that's at WP:Writing better articles without "Manual of Style/" in it is some historico-organizational mystery, and another thing to add to the no-deadline cleanup list, especially since it's explicitly self-described as an MoS supplement page. Yesterday I found a page like that described as a MOS:ACCESS supplement and moved it to be under WP:Manual of Style/Accessibility/ along with the rest of them).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:38, 23 December 2017 (UTC)

• Re Blueboar's initial comment, on WP:CONLEVEL: The level of support is what we're actually testing here, and there's no such thing as a {{Guideline}}-claimant that has the same weight as a wikiproject page as it would have it it were not one. This is not the only topical page to have had {{Guideline}} on it for years without a proposal, and they should not all retain it; it was removed in favor of an essay tag on several of them of them recently after discussions of their level of site-wide acceptance ([1] among others). Things like WP:MEDRS are not under WP:WikiProject Medicine (despite mostly being developed by the same people) for a reason: it's like keeping the article you've written as a draft in your userspace indefinitely; at some point it's ready to face the world, or it's old trash we don't need. I think MOS:VG is ready.

  Would you have us just move all topical MoS pages back to wikiprojects (and consequently cost them a lot of acceptance)? WP:PROJPAGEs is how they originated, same as in this case. So, no, this is not an exception to how we normally do things, it's just not been done in a while, because most topical style pages under wikiprojects have either been moved into the real MoS years ago, or tagged {{Historical}}, {{Essay}}, or {{Rejected}}. Most such page ideas get strongly rejected (see, e.g. [2] and [3] recently) or just ignored (even for massive projects like WP:MILHIST, e.g. here), even when the output of multiple RfCs [4], even when non-topical but of narrow editorial concern here (see also about 95% of what happens at WP:VPPRO). There's also the repeated failure [5][6] to get consensus for the idea that topical subject-specific notability guidelines (SNGs) can trump the WP:GNG. The continual gist of all this: the community takes a dim view of attempts by a topical group of editors to control guidelines; it even inspires efforts to demote them to essays, and these sometimes succeed [7],[8]. We have a bot that reports "[pagename] has been added to the MoS" in posts to WT:MOS, and most such additions are immediately reverted back to WP:PROJPAGE essays or individuals' d[r]aft proposal essays.
   — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:06, 22 December 2017 (UTC)

my only point (if there is one) is that not all project guidelines are equal... many are indeed low on the consensus scale... but some enjoy broad consensus. This is one of them. What I reject is the idea that we need to in some way “promote” it to MOS status to make it more “official”. Just accept that it enjoys broad consensus. Blueboar (talk) 00:02, 23 December 2017 (UTC)

Sure. Whether the material and the editorial pool that put that page together have earned it the right to be taken seriously isn't in question here; the fact that it should be is why this is proposed for adoption into the site-wide style guidelines. Under a wikiproject name, the "just accept its consensus" ideal is less likely to happen for any particular editor who encounters it. It's also organizationally problematic; if people don't actually encounter it in the MoS pages, they're less likely to encounter it at all, plus more likely to assume there's no coverage of the topic; time is limited, and they're not going to go trawling around in wikiproject pages in hopes of finding it. The consistency and consolidation are useful both for finding the material and keeping it in synch.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:18, 23 December 2017 (UTC)

If you think it could be improved, improve it. No need to change it to MOS. Blueboar (talk) 17:08, 24 December 2017 (UTC)

if people don't actually encounter it in the MoS pages, they're less likely to encounter it at all, plus more likely to assume there's no coverage of the topic; time is limited, and they're not going to go trawling around in wikiproject pages in hopes of finding it. Yup yup yup. If it isn't in the style box, I'd assume there isn't a broadly accepted guideline. Also being there affirms that it has broad consensus to someone who doesn't know much about it. Galobtter (pingó mió) 16:02, 23 December 2017 (UTC)

• Two major concerns I have. First we have to acknowledge that WP has so called MOS warriors, that fight a lot about exact adherance towards MOS standards. Second, the standards that affect the overall WP like about punctuation, those are fine to make sure are consistent. But much of the current vg guidelines is advice, not meant to be read as standards, or what other MOS feed into our guidelines but not creating new MOS. This would be like the issue of infoboxes on BIO articles, which resulted in case that says this can't be forced. Making the vg guidelines a MOS level would trigger those that are stickers to MOS adherence override local consensus on, say, article content order, where that local consensus had previously determined the non MOS order wickedness for that article. It is why we give these as project level advice, not absolutes that MOS are often read as. I know there are other MOS from other projects that are in the MOS but I have also the MOS stickers thy to enforce those as if they were policy. --Masem (t) 19:16, 24 December 2017 (UTC)

• As SMC has posted to several other MOS project pages looking for the idea of unified media MOS, this is a bad idea. The different forms of media have different ways of how they are treated in the relevant media. The structure used to cover a film differs greatly from that of a musical album, from a TV series, or a video game. Trying to unify these is really a bad idea, coupled with those that want to enforce MOS with a degree of strictness, is a recipe for orobkems. Segregate the true MOS elements out from these, but leave elements like struxture, cintent, etc up to each project. --Masem (t) 23:59, 25 December 2017 (UTC)

My mother has a recipe for orobkems that's just to die for. The secret is to add just a hint of mishegas along with the kabuki. Struxture and cintent give me heartburn. EEng 00:18, 26 December 2017 (UTC)

• Question... is there anything in the VG guideline’s style section that is not ALREADY in the main MOS? Blueboar (talk) 13:18, 26 December 2017 (UTC)
  • As best as I am aware (eg one of the VG MOS's authors), no. That style/formatting stuff can be taken as "Here is what are applicable aspects of the site-wide MOS that affect VG project articles", and does not attempt to introduce anything new. The structure/content/notability stuff is based on what the core content policies look for (NOT, V, etc.) but where those policies are not rigid, we going into more depth on advice there. --Masem (t) 15:21, 26 December 2017 (UTC)
    • Then moving it is pointless... the style section of the VG guideline is simply a reiteration of already established MOS guidance. Blueboar (talk) 15:51, 26 December 2017 (UTC)
      • That I agree with. I also express concern that we have wikiproject guidelines like film, music, etc. pushed into MOS when, to the best of my understanding, those were similarly written to reiterate/summate how the appropriate style and formatting MOS apply to articles in those fields. They are not creating a new style/formatting MOS. (Contrast this to something like WP:MEDMOS, MOS that applies to medical topics that cross many topic fields and possible wikiprojects. I do think that having links to this project-level content guidelines in one easy-to-find place helpful but they should not be considered a part of MOS but subservient to MOS, and thus, where there is advice that is outside the standard format and style MOS, should not be enforced as some editors typically seek to bring articles into compliance with the MOS. --Masem (t) 17:06, 26 December 2017 (UTC)

Having a subcategory in the MOS that concentrates on a specific topic area such as film or video games allows for tailored examples (especially those that have been a heated subject of debate at one time) to add additional clarification that may not have been as clear otherwise when reading the general MOS. Complementing the MOS in this fashion is helpful and not unnecessarily redundant. I imagine it's the same reason why a style section exists at WP:VGG. If there was no point in moving it on the basis that it reiterates MOS guidance, then there's no point in having the section to begin with. Just provide a link to the MOS. The logic in the argument goes both ways. --GoneIn60 (talk) 19:58, 26 December 2017 (UTC)

The problem is that these MOS sections in the wikiproject guidelines are not new MOS (that I'm aware of, and definitely the case for VG), they are a summary of the most common standard MOS points that can come up while writing articles in topic space to be most aware of, a type of FAQ. Given how complex our MOS are, this is completely reasonable for any wikiproject to offer. It seems much better to have a completely different category of "content guidelines" that sit outside of the site-wide MOS. Only a few would apply across a large number of articles, the rest are content guidelines with many reasonable exceptions that apply to narrow topic areas, including those set by Wikiprojects. I will note these cannot be managed in isolation of site-wide consensus (eg a wikiproject cannot override core notability principles) but it is still important that they are developed by editors with the most interest and involvement in those articles. --Masem (t) 14:28, 27 December 2017 (UTC)

I can understand and appreciate that viewpoint. Keeping content advice housed under the WikiProject makes sense. Regarding style guidance being just a summary, it's worth mentioning that the same holds true for MOS:FILM and other similar subcategories in the MOS. These pages are not new MOS either. The debate is whether or not that "FAQ" should be housed in a more general Wikipedia namespace as opposed to the project's. The trend appears to favor the latter, and giving it more visibility may help keep it in check; VG editors maintaining it could unknowingly contradict the MOS. I'm not implying that has happened or will happen, but it seems reasonable to want to move it on that basis. Doing so may help avoid creating a recipe for future conflict with the MOS, whether intentional or not. The more oversight you have, the less likely that will happen. There's also precedence to support this. MOS:FILM is well-maintained by those closely affiliated with the project, with the added bonus that non-film members are more likely to weigh in on talk page discussions. Moving it wouldn't damage the project's ability to maintain it. I don't feel too strongly about it either way, but it's worth having the discussion for sure. --GoneIn60 (talk) 20:26, 27 December 2017 (UTC)

Inline quotations accompanied by inline attribution

I often see at Wikipedia that quotes are provided inline without any inline attribution, which is really bad IMHO unless the speaker is clear from the context. Am I correct that this MOS merely requires attribution, rather than inline attribution? If so, I support editing the MOS to require not just attribution but inline attribution, unless the context makes it obvious. Often the attribution isn’t even explicit in the footnote, and so you have to click on a link in the footnote to figure out who made the quoted statement. I don’t think readers should have to go look at a footnote at all, because the body of the Wikipedia article should only include quotes with inline attribution unless the attribution is otherwise obvious. Here’s an example, which I now promise to never edit since I’m seeking a policy change that would affect it. Anythingyouwant (talk) 18:51, 29 December 2017 (UTC)

MOS:QUOTE says you should use in-line attribution to name the speaker of a quote, unless you're talking about a statement made by the person/entity whom is the topic of the article. WP:WHYCITE says any quote or close-paraphrase should have an immediate citation to that source at the point the quote is used. In the diff example, that does need to be attributed as I cannot tell from context who said it. --Masem (t) 19:06, 29 December 2017 (UTC)

Thanks User:Masem, can you please quote the part of MOS:QUOTE? Thanks. Anythingyouwant (talk) 19:46, 29 December 2017 (UTC)

It's the Attribution section "The author of a quote of a full sentence or more should be named; this is done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section" --Masem (t) 20:04, 29 December 2017 (UTC)

Hmm, that wouldn’t seem to apply to the example I gave because it’s not a full sentence. Do you know why we require it to be a full sentence or more? Anythingyouwant (talk) 20:40, 29 December 2017 (UTC)

Would anyone object if I change this MOS to say: "The author of a quote of a full sentence or more should be named unless their identity is already obvious in context; this is done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section"? Anythingyouwant (talk) 21:47, 29 December 2017 (UTC)

I suspect the present text might have been intended as a bright line to take account of things like

• "She is widely described as 'the Leader of the Free World'." [with a footnote referring to several articles]
• "She met the Dalai Lama for 'private and informal talks'." [with a footnote referring to a press release]
• "She is sometimes referred to as 'the decider'." [with no attribution for the inner quotation]

--Boson (talk) 23:47, 29 December 2017 (UTC)

Thanks Boson, good examples. I think we can take account of stuff like that by saying, "The author of a quote of a full sentence or more should be named unless their identity is already obvious in context, or the quote is not attributable to any particular named author; this is done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section"? Does that take care of your examples? Anythingyouwant (talk) 00:41, 30 December 2017 (UTC)Edited01:46, 30 December 2017 (UTC)

Wait... the author should be named unless scare quotes are being used? And when do we use scare quotes, except when they occur inside a larger quote? I'm... confused. EEng 00:53, 30 December 2017 (UTC)

Sorry, I have just removed the bit about scare quotes, it’s unnecessary. Anythingyouwant (talk) 01:46, 30 December 2017 (UTC)

OK, so here's the proposal:

The author of a quote of a full sentence or more should be named unless their identity is already obvious in context, or the quote is not attributable to any particular named author; this is done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section

Any comments, objections, snide remarks, glowing praise? Anythingyouwant (talk) 03:50, 30 December 2017 (UTC)

The "not attributable to a named author" bit isn't going to work. Everything we quote is attributable (unless it's quoted in a source we attribute that doesn't attribute who it's quoting, in which case it would be dubious to include it without some special context for it). It's just that sometimes it's not important to attribute a quote inline, usually when it's a string of descriptive material from multiple, similar sources. E.g. 'The film was praised by critics as "edgy and creative"^[1], "darkly humorous while seriously thought-provoking"[2], and "the best thing Jackson has done since My Life with the Weasels",^[3] though also reviewed less favorably for "its self-consciously shaky camera work"^[4] and "overuse of pop music, making some scenes feel more like music videos".^[5]' No one cares which non-notable but reputably published reviewer said what, unless they're digging into the citations.

There needs to be a better way to get at "attribute the quote when it needs to be attributed", basically. What we don't want to see is "She is 'gunning for the governorship in 2020, on a platform that amounts to center-left backlash against ignorant populism'.^[1]" without this opinionated encapsulation being attributed, right there in the sentence, to someone whose opinion our readers might GaF about.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:17, 30 December 2017 (UTC)

Well, if the source is one particular author, then that author always needs to be named inline, right? So:

The author of a quote of a full sentence or more should be named, and for a shorter quote that is sourced to only one author or source we also should provide that name; this is done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section

Anythingyouwant (talk) 05:35, 30 December 2017 (UTC)

I don't think that quite works for quoted short phrases that should be attributed, but where the decision whether this should be in a footnote or in the main text is left to editorial judgement (e.g. theatre critics, press officers, reporters). --Boson (talk) 13:48, 30 December 2017 (UTC)

One issue in one of Boson's examples: "She met the Dalai Lama for 'private and informal talks'." might need attribution if the context is related to criticism of this hypothetical person. Say this person is a member of Free Tibet or a similar organization but known to support militaristic action against China or the like, so that any time she travels to Tibet, her critics suggest she's plotting some type of violent action (again, hypothetical case here). If that is the context where that phrase is used, that needs inline attribution , like "She met the Dalai Lama for 'private and informal talks', according to her press agency." or something like that to avoid . On the other hand, if we're talking a non-controversial person, like a country's ambassador, the lack of attribution is probably okay, though even there, the need to quote that may be unnecessary.

A lot of this comes down to context. Editors should step back, consider the context, and make sure that the phrase being quoted makes it clear who the speaker(s) may be or immediate sources where they can be found if there are far too many to list, and avoid having the text within the quote appear as controversial statements spoken in Wikipedia's own voice (hence the need for attribution to id the speaker). But it still is all about context; I don't think it is very easy to make exacting rules here, but instead remind editors what the reason for inline attribution is, and methods of how to include it when needed. --Masem (t) 14:06, 30 December 2017 (UTC)

Okay well, User:Boson and User:Masem, here is my last attempt:

The author of a quote of a full sentence or more should be named, and for a shorter quote that is sourced to only one author or source we also should seriously consider providing that name; this is normally done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section

That’s more flexible. Personally, I don’t see why it’s not better to name theatre critics inline; likewise for press officers and reporters, the name of their organization (i.e. the name of the source if not the person) ought to be provided inline, IMHO. But if you disagree with this newest proposal, please suggest an alternative. Thanks and Happy New Year. Anythingyouwant (talk) 16:46, 30 December 2017 (UTC)

• I appreciate you're trying to improve the guideline, but we're certainly not going to say anything like we also should seriously consider; that can be fixed of course. My major worry, though, is that we need to address the points SM made: there are times when it really is appropriate to quote material which is either uncontroversial (but expresses a point better than any our paraphrase would) or, even if potentially "opinion", is just one of many similar such opinions whose authors need not be specifically called out. In these cases there's no need for in-text attribution, and the guideline as it is doesn't allow for these cases. That's what needs to be fixed. EEng 01:37, 31 December 2017 (UTC)

User:EEng#s, I find 15 (fifteen) occurrences of the word “consider” already in this guideline, so it wouldn’t be the first such instance. Anyway, if the quote marks in SM’s example were removed it would still not be in wikivoice, so maybe that’s the distinction we need to make. If a sentence uses a quotation and would be in wikivoice without the quote marks, then a source needs to be named. I don't think it's wise for this guideline to suggest that no inline attribution is needed for quotations that are less than a sentence. Anythingyouwant (talk) 02:19, 31 December 2017 (UTC)

Consider, yes – we should seriously consider, no; but like I said that can be probably be fixed. I don't know what you mean by "would [would not] still be in wikivoice". EEng 02:32, 31 December 2017 (UTC)

User:EEng#s, if we remove the inner quote marks from SM’s example, it becomes this: “The film was praised by critics as edgy and creative[1], darkly humorous while seriously thought-provoking[2], and the best thing Jackson has done since My Life with the Weasels,[3] though also reviewed less favorably for its self-consciously shaky camera work.” That is not in wikivoice so I agree no inline attribution is needed (with or without quote marks). But consider this example: “The film was ‘edgy and creative’[1], and ‘darkly humorous’[2], and also ‘the best thing Jackson has done’.[3]” That’s in wikivoice, if the quote marks are removed, so it needs inline attribution of some sort (with or without the inner quote marks). Anythingyouwant (talk) 02:44, 31 December 2017 (UTC)

That's a distinction without a difference. The inner quotes make it clear that it's not wikipedia saying this, but someone else; rewritten slightly as

The film was reviewed as ‘edgy and creative’[1], ‘darkly humorous’[2], and ‘the best thing Jackson has done’.[3]

-- there's nothing wrong with it. Or maybe I'm misunderstanding what you're saying. Please give exact examples of article text, enclosed in the {{tq}} template and set off on their own lines with :, so there's no confusion about the function of the various quote marks. In the meantime, you'll find numerous examples of appropriate use of unattributed quotations in Sacred Cod and Widener Library. EEng 03:10, 31 December 2017 (UTC)

SM said, “There needs to be a better way to get at ‘attribute the quote when it needs to be attributed’”? So there’s no way to do that more comprehensively than this guideline’s present statement about quotes longer than a sentence? Anythingyouwant (talk) 03:18, 31 December 2017 (UTC)

I now have no idea what you're talking about? EEng 03:20, 31 December 2017 (UTC)

User:EEng#s, do you have an idea what SM was saying when he wrote, “There needs to be a better way to get at ‘attribute the quote when it needs to be attributed’”? I think there needs to be a better way than how this guideline does it now. The present guideline only refers to inline attribution of quotes over a sentence in length, whereas shorter quotes often need it too. Are you saying there’s no way we can edit this guideline to address quotes shorter than a sentence? Anythingyouwant (talk) 03:25, 31 December 2017 (UTC)

I'm not sure exactly what he meant there; I'm talking about his prior paragraph. The sentence-length cutoff is obviously arbitrary and shouldn't be there, but as I've tried to show (and, again, I point you to the two articles I linked) it already overprescribes where in-text attribution is needed. EEng 03:30, 31 December 2017 (UTC)

Please take a crack at scaling back the overprescription. If you do so, then maybe you will have come up with a way to address attribution of quotes of any length. Anythingyouwant (talk) 03:34, 31 December 2017 (UTC)

Against my better judgment, I'll try

Here's the old:

The author of a quote of a full sentence or more should be named; this is done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section.

I've scrapped the inexplicable "full sentence" criterion. And the "clearly from the person" criterion. In fact, I scrapped the whole thing and just made it refer to NPOV's attribution requirement, which was a pretty clever thing to do, even if I do say so myself. Here we go:

As with all article content, the reader must be able to determine the source of any quotation, at the very least via a footnote. But the source should be additionally attributed in article text if, were it recast as paraphrase, it would need to be attributed per WP:Neutral_point_of_view#Attributing_and_specifying_biased_statements.

I'll point out right now that this is in conflict with weaker than WP:Citing_sources#In-text_attribution, which (in my opinion) greatly overprescribes what should be in-text attributed – it says all direct speech, indirect speech, or close paraphrasing "should" be in-text attributed, and that's clearly wrong. (At least it doesn't say "must" be in-text attributed.) EEng 06:12, 31 December 2017 (UTC)

• Support. Looks like a big improvement to my eye. And I don’t think it contradicts any other guideline or policy, because it doesn’t say that “the source should be additionally attributed in article text ONLY if, were it recast as paraphrase, it would need to be attributed....” Anythingyouwant (talk) 18:33, 31 December 2017 (UTC)

Good point. I've modified my post just above. EEng 18:47, 31 December 2017 (UTC)

Doesn’t anyone want to disagree with me? Anythingyouwant (talk) 00:18, 3 January 2018 (UTC)

Negative. EEng 00:30, 3 January 2018 (UTC)

No disagreement with what you are trying to do here, but I have a few quick copy-edit ideas for you:

1) "As with all content" is not necessary (it's implied).

2) "if, were it recast as paraphrase, it would need to be" isn't quite grammatically correct. The second "it" can be removed, or moved before the word "were".

3) Could we say "were it to be paraphrased" instead of "were it recast as paraphrase"?

4) How about "it requires attribution" instead of "would need to be attributed"?

Warren -talk- 00:32, 3 January 2018 (UTC)

I support Warren's proposed amendment (especially No 2—it was a little clunky to my eyes). –Sb2001 00:44, 3 January 2018 (UTC)

• Oppose. The length of the material is not the issue, it's whether it's clear who's speaking/writing in the context and whether it's something that actually needs individual attribution. I've covered this in detail above. PS: I agree with Warren's copyedits, but it's putting a suit on a scarecrow and expecting it to go to a business meeting.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:10, 3 January 2018 (UTC)

  Thanks... I think?? 😁 Warren -talk- 05:28, 3 January 2018 (UTC)

• Here's a new version taking Warren's points into account:

The reader must be able to determine the source of any quotation, at the very least via a footnote. But the source should be additionally attributed in article text if a paraphrase of it would require attribution under WP:Neutral_point_of_view#Attributing_and_specifying_biased_statements.

SM, I can't understand you. If you agree the length doesn't matter, then surely you agree something needs to change in the guideline. Can you suggest new text of your own? EEng 05:35, 3 January 2018 (UTC)

SM's example was this: “The film was praised by critics as ‘edgy and creative’[1], ‘darkly humorous while seriously thought-provoking,[2] and ‘the best thing Jackson has done since My Life with the Weasels’,[3] though also reviewed less favorably for ‘its self-consciously shaky camera work’[4] and ‘overuse of pop music, making some scenes feel more like music videos’.[5]” Recast as paraphrase it would be something like, “The film was praised by critics for its creativity and edginess,[1] as well as thought-provoking dark humor,[2] surpassing anything Jackson has done since My Life with the Weasels,[3] though the film was also panned by reviewers who complained about jittery and self-conscious camera work,[4] along with excessive pop music.[5]” So now we go to WP:Neutral_point_of_view#Attributing_and_specifying_biased_statements to examine whether the paraphrase includes any biased statement. I don’t think it does, because it’s completely factual. So, no in-text attribution would be required in the original version before we paraphrased it. Anythingyouwant (talk) 05:37, 3 January 2018 (UTC)

No, there's no difference in "bias" between "The film was praised as 'edgy and creative'" and "The film was praised for its edginess and creativity". That a film was as "praised as 'edgy and creative'" is as precisely as much a "statement of fact" as its being "praised for its edginess and creativity"—both wordings require attribution, for the exact same reasons. Curly "JFC" Turkey 🍁 ¡gobble! 05:48, 3 January 2018 (UTC)

They both require attribution via footnotes, but neither requires additional attribution by name in article text. Anythingyouwant (talk) 05:52, 3 January 2018 (UTC)

(edit conflict) If there's no in-text attribution, there's no attribution, and the quote lacks sufficient context for the reader to evaluate it. Curly "JFC" Turkey 🍁 ¡gobble! 06:07, 3 January 2018 (UTC)

Per policy, attribution can be other than in-text: ”Attribute all quotations and any material whose verifiability is challenged or likely to be challenged to a reliable, published source using an inline citation.” Anythingyouwant (talk) 06:27, 3 January 2018 (UTC)

You've (a) ignored the point, and (b) disregarded WP:INTEXT. Curly "JFC" Turkey 🍁 ¡gobble! 07:03, 3 January 2018 (UTC)

I'm sorry if I did not correctly understand you. Regarding WP:INTEXT, I don't know whether you agree or disagree with the comment above that it "greatly overprescribes what should be in-text attributed". You say I've disregarded WP:INTEXT but I don't know what part of WP:INTEXT you're referring to. Anythingyouwant (talk) 07:14, 3 January 2018 (UTC)

It might help understanding your position if you gave us some clue as to why you think attribution should not be given in-text. As a reader, I put less trust in text that does not give proper in-text attribution. It feels almost manipulative, rather than strictly informative. Curly "JFC" Turkey 🍁 ¡gobble! 09:26, 3 January 2018 (UTC)

No one's saying there should never be in-text attribution, just that there are times it's required and times it's best omitted. There are many examples at Sacred Cod and Widener Library. EEng 09:32, 3 January 2018 (UTC)

I can't imagine why anyone would think the attributions in those articles are "best omitted". Why are "indignant" and "scores" even quoted in the first place? What is the point of an unattributed "painted to the life"? If it's only meant to mean it's realistic—why not just say so? Please explain? I honestly don't get this at all. Curly "JFC" Turkey 🍁 ¡gobble! 09:58, 3 January 2018 (UTC)

"Scores" and "indignant" are quoted to put some distance between WP's voice and the New York Times' slightly facetious tone; to pass on as straight fact the idea that police personnel were individually indignant, or that literally scores of leads were followed, would be to misrepresent the source. "Painted to the life" is, as you say, a way of saying "realistically painted", but a way that engages the reader instead of simply reciting a cold fact; in particular it prepares the reader for the style in which most commentary on the subject, quoted later in the article, is written. But whether or not this particular quotation should be used directly, or paraphrased as "realistically painted", isn't important here. What's important is that if it's quoted, it doesn't need in-text attribution because if it was paraphrased as "realistically painted" that wouldn't need in-text attribution either. EEng 10:28, 3 January 2018 (UTC)

Reading this response made me go crosseyed. A facetious tone is the last thing we need in a Wikipedia article, and your last sentence is a non sequitur. Those quotes draw attention to themselves by the act of quoting—that alone requires in-text attribution to make sense of why they are being quoted. This is an extraordiarily poor example of how quotation would be "appropriate", let alone non-attribution. These are encyclopaedia articles, not articles in the Lifestyle section of the local newspaper. Curly "JFC" Turkey 🍁 ¡gobble! 22:30, 3 January 2018 (UTC)

The article doesn't take a facetious tone; as I said it merely passes on the sources' words so readers can make of them what they will. As for the rest, a friend was kind enough once to pass on Teresa Nielsen Hayden's evaluation of the article; she called it Wikipedia as art, deft, beautiful, possibly even perfect (after following the link, hover over the words Sacred Cod at lower left). Perhaps you take refuge in the idea that articles are supposed to be grey and lifeless, but some of us aim higher.

Anyway, none of this has anything to do with the question at hand. Do you have any comment on the proposed text? As you say, a given statement either requires in-text attribution, or doesn't, whether it's a paraphrase or a quote – and that's exactly what my proposed text says. EEng 03:50, 4 January 2018 (UTC)

If the proposal can be interpreted as allowing attribution to be shoved into an endnote, I'm opposed to it, for the reasons I've already given. Quotation needs in-text contextualization. Without attribution it's not even clear if a quotation is a quotation or merely scare quotes, or something else. Curly "JFC" Turkey 🍁 ¡gobble! 08:13, 4 January 2018 (UTC)

Why do quotations need "in-text contextualization" any more than do any other content? EEng 11:08, 4 January 2018 (UTC)

All text needs sufficient contextualization for the reader to make sense of it. That's why we avoid unexplained technical jargon, include background sections, etc, etc, etc. Why would quotations be an exception? Curly "JFC" Turkey 🍁 ¡gobble! 22:57, 4 January 2018 (UTC)

All text needs sufficient contextualization for the reader to make sense of it. That's why we avoid unexplained technical jargon, include background sections, etc, etc, etc. Why would quotations be an exception? Right. Exactly. Quotations are not an exception. They have exactly the same needs for "contextualization" as does anything else not a quotation. That's what this proposal precisely says, on the specific question of the aspect of contextualization known as attribution: the source should be additionally attributed in article text if, were it recast as paraphrase, it would need to be attributed. EEng 00:26, 5 January 2018 (UTC)

I'm not following where you're going with this at all. I don't see an argument in your comment against requiring attribution. Curly "JFC" Turkey 🍁 ¡gobble! 02:12, 5 January 2018 (UTC)

Arbor tree-ish break

Curly, this MOS says in-text attribution is not needed if a quote is less than a sentence long ("The author of a quote of a full sentence or more should be named; this is done in the main text and not in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section"). I believe shorter quotes often should have in-text attribution, and I understand you to feel the same way. But not every one, right? There are plenty of examples above, like "She is widely described as 'the Leader of the Free World'." [with a footnote referring to several articles] That doesn't need in-text attribution, right? Anythingyouwant (talk) 23:05, 4 January 2018 (UTC)

"widely described" gives the reader the context needed to make sense of the quotation; in a sense, that's a form of "attribution" (it's attributed "widely"). That's a whole world of difference from "The work was described as 'enlightening' and 'ground-breaking'." Both those quotes are less than a sentence and would absolutely require attribution. Curly "JFC" Turkey 🍁 ¡gobble! 23:16, 4 January 2018 (UTC)

Can that be easily cleared up by amending the proposal to say, "The reader must be able to determine the source of any quotation, at the very least via a footnote. But the source should be additionally attributed in article text, by name if a paraphrase of it would require attribution under WP:Neutral_point_of_view#Attributing_and_specifying_biased_statements."? I have inserted "by name". Incidentally, the current sentence in this MOS is already addressing when the source "should be named". Anythingyouwant (talk) 23:28, 4 January 2018 (UTC)

I'm not sure what advantage there is to the rewording besides dropping the "full sentence" thing, which never should have been there in the first place. Curly "JFC" Turkey 🍁 ¡gobble! 00:13, 5 January 2018 (UTC)

User:Curly Turkey, you said, "'widely described' gives the reader the context needed to make sense of the quotation; in a sense, that's a form of 'attribution'". But it's not a form of attribution by name. This MOS section is about when attribution is required by name. You don't think attribution by name is required for every quotation, do you? Anythingyouwant (talk) 00:18, 5 January 2018 (UTC)

The text should make clear where the quotation's coming from. In most cases, that would mean naming the source, and there shouldn't be any room in the wording to allow wikilawyers to arbitrarily worm out of that. In certain contexts, attribution should or must be handled without naming names, but should not be dropped into running text without contextualization along the lines of a "widely considered" or whatever. Curly "JFC" Turkey 🍁 ¡gobble! 00:32, 5 January 2018 (UTC)

The text should make clear where the quotation's coming from. No, see I'm not going to let that pass. Why should the text male clear where the quotation's coming from, always, any more than the text needs to make clear, always, where anything else comes from? I agree that in most circumstances quotes should be in-text attributed (usually definitely – "Smith said", or "his sister said" – but sometimes less so – "a witness later said"), but not always. To drag in another of my pet articles, when the lead of Phineas Gage says that the subject was once termed "the case which more than all others is cal­cu­lated to excite our wonder, impair the value of prognosis, and even to subvert our phys­i­o­log­i­cal doctrines", it doesn't help the reader at all to learn have it rubbed in his face, directly in the text that was written by H.F. Campbell in The Ohio Medical & Surgical Journal for 1851, though if he really wants to know he can check the citesfootnotes. Had we paraphrased as Gage's case attracted unprecedented interest, made physicians question their ability to predict whether a given injury would or would not be fatal, and brought many established ideas about human physiology into question, no one would dream of requiring in-text attribution, so why for the quotation, which gives precisely the same information (in a much longer and less vivid way)? EEng 01:47, 5 January 2018 (UTC) Later insertions and deletions for clarity. 03:30, 5 January 2018 (UTC)

Of course the Phineas Gage quote requires attribution. How could it not? Why is this your example? If that quote doesn't require attribution, then how could any? Curly "JFC" Turkey 🍁 ¡gobble! 02:15, 5 January 2018 (UTC)

Jeez, Louise! Of course it requires attribution – in a footnote at least. But does it require IN-TEXT attribution? It's the IN-TEXT question we're talking about. How is the reader helped or informed or contextualized or englightened or whatever it is we're doing, by telling him IN THE TEXT that H.F. Campbell was the specific writer? EEng 03:24, 5 January 2018 (UTC)

Do we really have to go around in circles with this? I've already given reasons. You don't appear to be reading them. Aside from all the regular reasons, a quotation draws attention to itself by the act of quotation. In-text attribution justifies and clears up for the reader why it's being quoted. Curly "JFC" Turkey 🍁 ¡gobble! 11:46, 6 January 2018 (UTC)

Do you think EEng's proposal leaves any room in the wording to allow wikilawyers to arbitrarily worm out of that? If so, can you please suggest how to improve EEng's proposal? If we take out the one-sentence minimum from the current MOS, then attribution by name would be required for every quotation, and I don't think you or me or EEng would agree with that. Thanks. Anythingyouwant (talk) 00:38, 5 January 2018 (UTC)

I suppose the consequences of merely dropping "by name" would be a lot of "a certain professor"-type "attributions", which obviously isn't acceptable. An eloquent and concise wording escapes me. Curly "JFC" Turkey 🍁 ¡gobble! 02:18, 5 January 2018 (UTC)

I like where Anythingyouwant is going with this. And agree with CT that the "one sentence" thing is nonsense.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:15, 5 January 2018 (UTC)

I think we all agree the one-sentence thing is nonsense, so that's something. I hope you'll stay with this, because we need a brain that can keep track of all that's going on in a discussion like this. EEng 01:48, 5 January 2018 (UTC)

Resuming an earlier subthread

Remember I said I was doing this against my better judgment. At least as between Anythingyouwant and C.T., the disagreement seems to be on what the outcome of applying WP:Neutral_point_of_view#Attributing_and_specifying_biased_statements would be, not whether WP:Neutral_point_of_view#Attributing_and_specifying_biased_statements is the right standard. I'd still like to hear any alternative text from S.M., if he can. EEng 05:57, 3 January 2018 (UTC)

I don't have strong feelings about this one way or the other, but I flipped through several featured articles that have reviews or critical analysis (The Concert in Central Park, The Autobiography of Malcolm X, Z. Marcas, Ultima Underworld: The Stygian Abyss) and they all consistently identify the source of a quote, in the article text itself: The Swedish Datormagazin considered the game to be "in a class by itself".[29] In Germany, Power Play praised its "technical perfection" and "excellent" story,[31] while Play Time lauded its graphical and aural presentation, and awarded it Game of the Month.[15] .... This is pretty high-quality construction and seems to neatly take care of bias issues, but I also appreciate that getting there is quite a lot of work. Warren -talk- 06:17, 3 January 2018 (UTC)

We're getting bogged down debating individual examples instead of focusing on what the right standard is. Is, or is not, WP:Neutral_point_of_view#Attributing_and_specifying_biased_statements the right standard for in-text attribution of quotations (whether there's disagreement on how to apply it in the particular examples above)? S.M., help!!!! EEng 06:35, 3 January 2018 (UTC)

Current draft proposal

The current draft proposal is kind of buried above, so here it is (slightly prettified):

The reader must be able to determine the source of any quotation, at the very least via a footnote. But the source should be additionally attributed in article text, by name if a paraphrase of it would need attribution as a biased statement.

This drops the silly limitation to quotes that are a sentence or longer; merely dropping that limitation would mean every quotation would have to be attributed by name in the article text, which no one thinks would work, so this proposal loosens that requirement by only asking for attribution by name if it’s a biased statement. Anythingyouwant (talk) 04:32, 6 January 2018 (UTC)

• Support. This does not preclude in-text attribution by-name for any quotation, nor does it preclude in-text attribution not-by-name for quotations that do not need in-text attribution by-name. So it’s quite flexible. Anythingyouwant (talk) 00:32, 7 January 2018 (UTC)

If no objection within 24 hours, I think someone can go ahead and make this change. The current language in the MOS is “The author of a quote of a full sentence or more should be named; this is done in the main text and not merely in a footnote. However, attribution is unnecessary with quotations that are clearly from the person discussed in the article or section.” Anythingyouwant (talk) 21:33, 9 January 2018 (UTC)

• Anythingyouwant, to reduce the change from the current guideline, would you be OK with –

The reader must be able to determine the source of any quotation, at the very least via a footnote. But the source should additionally be named in article text if a paraphrase of it would need attribution as a biased statement.

–? EEng 22:45, 9 January 2018 (UTC)

Sure. Anythingyouwant (talk) 23:37, 9 January 2018 (UTC)

• Support. EEng 00:57, 10 January 2018 (UTC)

Placement of ref tags for parentheticals

Long-standing text

Exceptions: Ref tags are placed before dashes, not after. Where a footnote applies only to material within parentheses, the ref tags belong just before the closing parenthesis.

Someone removed the second sentence; I restored it, and it was removed again.

My rationale

This is long-standing practice. There's a huge difference between:

1. Claim (caveat<ref 1 />).
2. Claim (caveat).<ref 1 />
3. Claim (caveat<ref 1 />).<ref 2 />

In the first, the claim isn't even sourced, only the caveat is. In the second, the claim and caveat share the same source.

I think this should be restored. It maybe looking better, to some people, to change #1 into #2 is no excuse for sacrificing certainty about what is being attributed to which source (if any). If the claim in this case is not in fact attributable to the same source as the caveat, then doing this is outright falsification of the sourcing. We can't have MoS advising to do this on purpose.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  10:52, 30 December 2017 (UTC)

• I'm the someone.
• This was added by a single editor [9] with no apparent discussion [10].
• Chicago (14.26) opposes this except "on rare occassions":

Though a note number normally follows a closing parenthesis, it may on rare occasion be more appropriate to place the number inside the closing parenthesis—if, for example, the note applies to a specific term within the parentheses.

(In an earlier book he had said quite the opposite.)[2]

Men and their unions, as they entered industrial work, negotiated two things: young women would be laid off once they married (the commonly acknowledged “marriage bar”[1]), and men would be paid a “family wage.”

-- but we don't do the kind of writing seen in that second example because in our work, everything needs to be sourced e.g.

Men and their unions, as they entered industrial work, negotiated two things: young women would be laid off once they married[2] (the commonly acknowledged “marriage bar”),[1] and men would be paid a “family wage.”[2]

-- or something like that. It's simple: each cite covers everything back to the prior cite.

• Similarly, I don't understand SM's example (1.) because he's leaving Claim unsourced, apparently. I'd write:

Claim[2] (caveat).[1]

His example (2.) is obvious -- everything's covered by a single ref:

Claim (caveat).[1]

His example (3.) I'm not sure I understand. If [1] applies only to Caveat, and [2] applies to both Claim and Caveat, then write

Claim[2] (caveat).[1][2]

English isn't a programming language with push-down stacks of subsidiary clauses. Like I said, it's simple: each cite covers everything back to the prior cite, parens or punctuation or whatever notwithstanding. Cites come after parens for the same reason they come after periods and commas: because otherwise they look stupid, and awkward, and (awful).

EEng 15:04, 30 December 2017 (UTC)

"This was added by a single editor" is not a rationale for anything. Everything is added by a single editor or an edit conflict will result. The question is whether it describes consensus practice, and the answer is yes. If you'd like to change that practice, please open an RfC. Given that it could affect untold numbers of articles, it should probably be advertised at WP:VPPOL. Yes, you are not understanding the examples. I'm not leaving the claim in the first examle unsourced, it simply is unsourced, as are millions of claims in our articles (and this is fine, per WP:V policy – claims must be sourceable not sourced unless/until they're controverted, though with special exceptions like WP:BLP and WP:MEDRS material, in which anything potentially counterfactual but unsourced should be deleted not tagged). The editor who added the caveat and source for it in example one is unlikely to be the same editor who added the original claim or have access to source material needed for the original claim (or no time or inclination to deal with it, being a volunteer). Adding the sourced caveat may be very important, e.g. if the claim is generally true but is not under particular circumstances, or whatever.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  12:53, 31 December 2017 (UTC)

To me EEng's "stupid, and awkward, and (awful)." looks perfectly normal. The other option (stupid, and awkward, and (awful).) would seem to mean that we are citing the punctuation as well as the text. --Khajidha (talk) 15:03, 31 December 2017 (UTC)

I wouldn't advocate any of those examples. EEng 18:54, 1 January 2018 (UTC)

The rest of the section regarding the location of refs and other punctuation (full stops, commas, and the like), is not in question. We're specifically speaking on parentheses. --Izno (talk) 15:24, 31 December 2017 (UTC)

And my point applies either way. --Khajidha (talk) 16:39, 31 December 2017 (UTC)

You could make all these same arguments for periods or commas: Where a footnote applies only to material within a single sentence, the ref tags belong just before the closing period. Where a footnote applies only to material within text set off by commas, the ref tags belong just before the "closing" comma. There's nothing special about parens in this regard, or with regard to any of the arguments that have been made.

Really, none of SM's examples are even on point to my quibble with the current guideline. I just want to be able to write

Claim.[1] (Additional.)[2] More.[3]

instead of being forced to write

Claim.[1] (Additional.[2]) More.[3]

How about if we follow Chicago's "rare occasions" recommendation and say something like this:

Where it is desired to emphasize that a footnote applies only to material within parentheses, the ref tags may be placed before the closing parenthesis.

EEng 18:54, 1 January 2018 (UTC)

Works for me.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:07, 3 January 2018 (UTC)

• Any dissent? EEng 05:11, 4 January 2018 (UTC)
  • I respectfully dissent on three grounds:
    1. Citation clarity: Putting the anchor within the parenthetical signals its scope with minimal hassle, and a modest gain in precision ought to outweigh minor stylistic quibbles. This crops up regularly in biographies:

       Alice Betty Carolie Smith (born January 1, 1990) is a Martian saxophone player and political candidate.

       References

       1. ^{^} Ref for birth date that doesn't give the middle names.

    2. Ease of reading: In my lay opinion, having the footnote before the closing parenthesis makes it easier for the eye to skip over the entire parenthetical.
    3. Stare decisis: That the guideline—in our main style guide—went unchallenged for more than five years is not insignificant, and, in my opinion, the lukewarm and indecisive discussion here is insufficient reason to overturn this longstanding practice.
    Rebbing 03:37, 5 January 2018 (UTC)

    Shit, just when there was agreement on something on this page.

    • 1. The proposed text allows you to do that if you want.
    • 2. In my lay opinion the superscipt [1] inside the paren catches the eye, and you trip on it instead of skipping over it.
    • 3. MOS is supposed to reflect good practice actually in use, not tell everyone to change an OK thing they're already doing. A quick sample of FAs shows about a 2:1 ratio (but let's just call it even); the proposal simply recognizes that.

    EEng 04:01, 5 January 2018 (UTC)

    SMcCandlish, what now? EEng 22:39, 7 January 2018 (UTC)

    Bueller? Bueller? EEng 20:31, 14 January 2018 (UTC)

    Then the long-standing original wording should be restored, since its removal is challenged by multiple editors and no one is agreeing with the removal, and it's widely followed (so appears to represent consensus practice). The numbered stuff:

  1. I almost agree with your first point, that the operational effect of both versions is the same, but it's not really, since your version couches it in terms of "desire for emphasis", when this is really about sourcing accuracy. So, the original wordig was fine. The effort to compress MoS wording is not much of an end in and of itself, especially if it leads to dispute or confusion in the process of doing it.
  2. The second point is just subjective opinion, and doesn't appear broadly shared, or we wouldn't have been doing it this way for years (and the "rule" wasn't inserted out of the blue, but to describe actual practice, which has been common the entire time I've been here). This alleged readability issue is the exact same sort of WP:ILIKEIT concern as "I want to put put all punctuation inside quotation marks [i.e. typographer's quotation] because it just looks more tidy, tucked in like that" and "Sammy Davis Jr. doesn't look right without the comma to me", and "I've always written it as Jesus' not Jesus's", and so on. Here, it's neither more nor less a reading impediment, on average, by being inside or outside the bracket. However, we lose precision – sometimes very misleadingly – when it's moved outside and the preceding material doesn't have its own inline citation. And it usually won't in leads – we discourage use of inline citations in leads, preferring them in the body text.
  3. I cannot agree with your third point at all; it's flatly impossible for you to prove that citations in the form "Alice Betty Carolie Smith (born January 1, 1990)" were intended to convey the same thing as "Alice Betty Carolie Smith (born January 1, 1990)". If you encounter the former, I'll bet good money that at least 95% of the time, especially in FAs, that the cited source provides the full name not just the date, and that when the second is used it provides the date but not the full name (or a citation is already provided for the full name).

  No one else seems to have difficulty with this format, and we have a twin policy reason for using it (WP:V accuracy about what facts are sourced and WP:NOR avoidance of misrepresentation of sourcing, two sides of the same coin). In a case where there actually is a citation "^[1]", your preferred "Claim.^[1] (Additional.)^[2] More.^[3]" would actually be permissible, since MoS is a guideline not a law, and no confusion could result. "Claim. (Additional.)^[1] More.^[2]", where the initial claim has no source yet, is simply a wrong format (if "^[1]" is a source only for the parenthesized material) and would probably prevent anyone from sourcing the unsourced claim, perhaps for years, because it falsely already looks sourced.

  I'll ask you the same thing you ask everyone who wants a substantive rule change: Can you provide evidence there's an ongoing problem to solve, that editors are actually fighting about "(something^[x])" formatting? What I see is editors following it without incident.
   — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  21:30, 14 January 2018 (UTC)

The "what problem needs solving" challenge applies where it's proposed to add rules; here the proposal is to relax one. As I think I mentioned somewhere above a quick sample of FAs reveals this rule is widely ignored. EEng 23:00, 14 January 2018 (UTC)

MOS:TENSE - Museum exhibits

I hope that you folks can help (have searched the archive). I regularly create aircraft engine articles, the subjects are often museum exhibits only or no longer exist at all. In the lead first sentence I always use the past tense as this seems natural to me. This is 'corrected' to present tense as if I have made a mistake. If the subject is still in service or even limited use in retirement I will use present tense.

Reading the guideline wording of do not use past tense except for dead subjects, past events, and subjects that no longer meaningfully exist as such I would regard an aircraft engine in a museum as not meaningfully existing as it is no longer running, turning a propeller or producing thrust and powering an aircraft.

Does this wording need adjusting for clarity? I've looked at some other random museum items (retired/defunct etc) and they all seem to use the past tense in the first sentence, e.g. Stephenson's Rocket, North American XB-70 Valkyrie, Space Shuttle Enterprise, RRS Discovery and the Wright Flyer, all subjects that no longer operate as they were originally designed to do ('retired' in less words!). Cheers Nimbus (Cumulus nimbus floats by) 07:27, 3 January 2018 (UTC)

• It seems a little odd, but what if there were an article about the Foo Exhibit? An article that would focus, at least secondarily, on a thing that obviously exists, no matter how tenuously, would have to refer to it in the past tense. I do a lot of tense-related copyediting and I see the fairly strong language in the current wording as a bright line. If there's one around, anywhere, it gets present tense. Primergrey (talk) 02:04, 4 January 2018 (UTC)

  So the articles I linked are incorrect then? There are clearly other editors that think the same way as me. On the Foo exhibit I would agree that many objects could always be referred to in the present tense, a sculpture or painting was intended to be looked at by its creator so it is still 'meaningfully existing'. A piece of engineering machinery (ship, aircraft, car, engine etc) once it is in a museum with none left working is not 'meaningfully existing'. Perhaps it's an engineer's/operator's thing along the lines of vessels having female gender, if a device is broken or stops working it immediately becomes 'was' in my eyes, its 'soul' has gone like a person passing away. There's a nuance in the grammar that is being overlooked. Nimbus (Cumulus nimbus floats by) 12:11, 4 January 2018 (UTC)

  Really, the whole "meaningfully" thing is problematic anyway, as it is in the editing guideline, but the end result, in the article, is "The Foo was this and that. A well-preserved example is housed at..." This reads, correctly, as contradictory. There are nuances here, but if they don't get conveyed through article prose, then we are simply navel-gazing. Primergrey (talk) 15:06, 4 January 2018 (UTC)

  The "Foo Exhibit" is not the same as "Foo" itself. You could say that "the Foo Exhibit is a museum exhibit focusing on foos. Foos were an item used for bar." (bar being the function of the foo) This would make it clear that the foos themselves no longer meaningfully exist, but that relics are available for viewing.--Khajidha (talk) 13:23, 4 January 2018 (UTC)

  I see your point, but I think that if something has existing examples and a museum exhibit, it has a meaningful existence. Primergrey (talk) 14:51, 4 January 2018 (UTC)

  Not sure how you figure that non-used examples and a museum exhibit equals a "meaningful existence". By those criteria I could claim that Vladimir Lenin has a meaningful existence because his unused body is still on display. --Khajidha (talk) 15:04, 4 January 2018 (UTC)

  Vladimir Lenin's body has a meaningful existence. Primergrey (talk) 15:09, 4 January 2018 (UTC)

• "meaningfully exist" is more reasonably interpreted as "destroyed", not "decommissioned and now used only in an exhibit". "X is an aircraft engine that was available in Y timeframes used in Z aircraft" is a fairly easy rewording for the case where you could walk into a museum and find the engine. If you have a reasonable belief that no engines of the model/class remain (where "reasonable belief" might be translated as "reliable sources tell you all of them were scrapped"), then I don't see an issue with "X was an aircraft engine (... available in Y timeframe)". I would suggest similar rewordings for a number of those example articles. --Izno (talk) 14:20, 4 January 2018 (UTC)

  Sorry, but ""meaningfully exist" is more reasonably interpreted as "destroyed", not "decommissioned and now used only in an exhibit"" is the exact point being discussed. Your pronouncement that this is so is no more valid than Nimbus227's pronouncement of the the converse. To me, the idea that a disused piece of technology no longer "meaningfully exists" is much more reasonable than your point of view. --Khajidha (talk) 14:44, 4 January 2018 (UTC)

  Let's look at another sphere: A computer program which is still known to exist, but which I can't use because I don't have the correct technology, does not cease to "meaningfully" exist just because I can't install and use it on my modern-day machine. It ceases to meaningfully exist when the only record we have of it is in writings rather than some potentially installable form. An engine model is no different: it only ceases to exist meaningfully when all of the class of engines no longer exist. Just because they were "retired" (i.e. no longer installed in an aircraft and no longer intended to be installed in an aircraft [because X technology deprecated it, etc.]) doesn't mean they don't work (I bet any number of "retired" engines could be tinkered with a bit and subsequently function as originally intended). --Izno (talk) 14:51, 4 January 2018 (UTC)

  Is your inability to install the program indicative of the fact that machines that could run the program are no longer used or only that you, yourself, do not have such a machine? The first seems not to "meaningfully exist" to me, while the latter might mean only that you have the most up to date technology while the program is still commonly used by many others with less up to date technology. --Khajidha (talk) 15:00, 4 January 2018 (UTC)

  Thought provoking stuff. I've had a look at the 'factsheets' from several museums including the Royal Air Force Museum, London Science Museum and the National Museum of the United States Air Force. They tend toward using the past tense for their retired aircraft and engine exhibits, which is my preferred method. In some cases they are using past tense for types that are still in limited use which I also wouldn't disagree with. Quite cleverly they avoid the use of tense at times by constructing their object descriptions in a different way. The MOS:TENSE guideline either needs clarifying considerably or amending to say that either style is acceptable. The nutshell box at the top of the page indicates that exceptions may apply (IAR) if all else fails. I have two more articles in the pipeline and would be reluctant to create them if they are going to be 'corrected per the guideline' the instant they are published, I find it very annoying unfortunately. Nimbus (Cumulus nimbus floats by) 17:41, 4 January 2018 (UTC)

  Writers always dislike it when the editorial staff of their publisher “corrects” their writing. It shouldn’t keep you from publishing. Granted, our “editorial staff” is self appointed... but then ... so are our writers. Blueboar (talk) 20:14, 4 January 2018 (UTC)

  Anyone who won't write an article because it is likely to get copyedited in line with our MOS (or for a multitude of other reasons) lacks the collaborative spirit this website relies on for success. Primergrey (talk) 00:59, 5 January 2018 (UTC)

  And they wouldn't get published by traditional publishers either. Heh.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:20, 5 January 2018 (UTC)

"Lenin's body has a meaningful existence." Exactly. It's perfectly fine to say that Challenger was a space shuttle and that parts of it are in a museum. If the entire something is in a museum, and still in working or potentially working condition (not just a shell or a fragment), though, it should probably remain in present tense. Cognitive dissonance about this can be resolved by sensible rewriting. Wright Flyer is a perfect example: The Wright Flyer (often retrospectively referred to as Flyer I or 1903 Flyer) was the first successful heavier-than-air powered aircraft. It was designed and built by the Wright brothers. They flew it four times on December 17, 1903, near Kill Devil Hills, about four miles south of Kitty Hawk, North Carolina, US. Today, the airplane is exhibited in the National Air and Space Museum in Washington D.C.. Analyze it: Past-tense claim about something it did. Past-tense claim about something they did. Ditto. Present tense claim about what the plane is up to right now. There is no problem there. PS: The style on that needs fixing; it should be '''''Flyer'' I''' or '''1903 ''Flyer'''''; the name of the aircraft did not change.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  01:29, 5 January 2018 (UTC)

I am very open to copy editing of my actual mistakes, I strive very hard not to introduce them. I would disagree that I lack collaborative spirit, it should be apparent that I have created many articles and happily left them to be edited, indeed they are often short on text and I hope that they will get expanded, I am very aware of WP:OWN having been accused of it several times. I have also uploaded many photographs for free use and am only too happy if someone improves them through editing. This tense guideline is a guideline but appears to be being enforced as a policy which is worrying considering the wording is open to interpretation (editors commenting above clearly read it in different ways). I'm afraid that most retired engine types are so dull and boring that it is very difficult to write the first sentences in the manner suggested for the Wright Flyer. Nimbus (Cumulus nimbus floats by) 20:30, 5 January 2018 (UTC)

So write it however you want and let someone else edit it in that manner. Nothing is being "enforced as a policy" unless "enforced" means "someone coming along and making style-related changes to an article to bring it in line with this site's style guidelines". No one is blocked for writing in a different house style, but people have been blocked for disruptive reversions to MOS-compliant edits. Primergrey (talk) 21:39, 5 January 2018 (UTC)

To comply is to acquiesce. Wikipedia has an editor retention problem, blanking the educated foot soldiers' opinions and experience might be related. Nimbus (Cumulus nimbus floats by) 22:02, 7 January 2018 (UTC)

Unless you are speaking literally, I don't know what you mean by "educated foot soldier". Regardless, as I said before, any editor that cannot work collaboratively is one not worth retaining. No article worth a damn has ever not been proofed and copyedited. Here or anywhere else. Primergrey (talk) 22:22, 7 January 2018 (UTC)

Just to be clear, you would rather I leave the project than discuss a problematic guideline? Nimbus (Cumulus nimbus floats by) 23:38, 7 January 2018 (UTC)

I was addressing the "editor retention problem" that you had mentioned during this discussion. But I wouldn't want to be the cause of anyone's martyrdom so, no, I would rather you did not leave the project. In fact, if it's causing you this much consternation, I would suggest, again, that you not comply with what is looking like the consensus interpretation of MOSTENSE. Just let other, equally well-meaning, editors tweak it (not correct it) to this site's house style. Primergrey (talk) 00:00, 8 January 2018 (UTC)

MOS:LQ clarification: when to include terminating punctuation from the source

Can we get a clarification on how MOS:LQ should be interpreted with regards to including terminating punctuation without quotemarks? For example, given two source sentences:

(1) "Curly Turkey can really get under people's skin when he gets going."

(2) "I really hate it when Curly Turkey opens his beak; he gets so annoying."

Would we quote them in a Wikpedia™ article in the following manner:

(A) Critic A stated Curly Turkey could "really get under people's skin". Critic B concurred, stating that Curly Turkey "gets so annoying".

or:

(B) Critic A stated Curly Turkey could "really get under people's skin". Critic B concurred, stating that Curly Turkey "gets so annoying."

—Curly "JFC" Turkey 🍁 ¡gobble! 11:42, 4 January 2018 (UTC)

Discussion

• Obviously, LQ requires the first quote fragment to have its terminating punctuation outside the quotemarks. Logically, the period punctuates the enclosing sentence, not the quoted fragment. Following that logic, the second sentence would also require the period outside, but some argue that, because the original had a period there, the quoted fragment should also include the period inside the quotemarks. Problems with that:
  • It ignores the "logic" in "logical quotation"—the period terminates a complete sentence, not a sentence fragment.
  • It results in a hodge-podge of in-and-out styles throughout an article that:
    • makes no sense from a reader's perspective
    • can be verified or resolved only by consulting all the sources
    • may motivate reader/editors to "fix" the article by putting all the terminating punctuation inside (breaking text–source integrity), or placing them all outside (a violation of MOS:LQ if MOS:LQ truly requires the original terminating punctuation to be included within the quotemarks).

Is there really any plausible reason to prefer (or even allow) (B)? Regardless, how can MOS:LQ be amended to make whichever interpretation clear? Curly "JFC" Turkey 🍁 ¡gobble! 11:42, 4 January 2018 (UTC)

• LQ starts by saying, without qualification, Include terminal punctuation within the quotation marks only if it was present in the original material, and otherwise place it after the closing quotation mark, then goes on to give a bunch of examples which in many cases contradict that. If you LQ zealots would get your act together and come up with a guideline that actually makes sense, is self-consistent, and is not too far off from they way normal people here on earth actually write, I'm sure most editors will do their best to follow it. In the meantime I, for one, will just do what that first sentence clearly tells me to do. EEng 12:08, 4 January 2018 (UTC)

  Now I understand: it wasn't a dispute over interpretation of LQ, but your opposition to LQ that led to the dispute. Curly "JFC" Turkey 🍁 ¡gobble! 22:53, 4 January 2018 (UTC)

  No, you don't understand. It was about the impossibility of making sense of LQ's contradictory provisions. EEng 23:26, 4 January 2018 (UTC)

  It's awfully straightforward. I'm sorry you're having difficulty with it. Curly "JFC" Turkey 🍁 ¡gobble! 00:09, 5 January 2018 (UTC)

• Seems to me that we could make it clearer just by removing the sentence EEng quoted. --Khajidha (talk) 16:05, 4 January 2018 (UTC)

  Then no one would understand it it all. It would just be a bunch of examples without any principle to follow. If we removed or changed anything, it would be an allegedly confusing example, but none have been identified. What seems to be happening here is that EEng is extrapolating beyond what it actually says and arriving at something like "Include terminal punctuation within the quotation marks if it was present in the original material, no matter what, and place all other punctuation after the closing quotation mark", or something to that effect, though it's not entirely clear, since he's just objecting without being specific. The only likely clarification I can see to make is to reverse the order of these two sentences one one line, about full versus fragmentary quotes, so that we have: If the quotation is a single word or fragment, place the terminal punctuation outside the closing quotation mark. If the quotation is a full sentence and it coincides with the end of the sentence containing it, place terminal punctuation inside the closing quotation mark. We should do that because we more often quote fragments than full sentences, so people should see and absorb that part first and foremost.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:08, 5 January 2018 (UTC)

• My interpretation of LQ is that we put inside the quotes the things that we intend to quote, and not the punctuation that is part of our framing sentence. In this example, what we intend to quote is "gets so annoying". In most contexts it would not make sense for what we quote to be extended by one character to "gets so annoying." (this sentence being an exception to the "most contexts") because that longer quote is less-grammatical, having a period after something that is not a complete sentence. So in this case the clear choice is A over B. The weird part is that when a sentence ends on a quoted sentence, we omit the period from the framing sentence and let the quoted period do the job. Instead, we should have both; for instance, "This is a quoted sentence.". It looks uglier that way but it would be more logical. —David Eppstein (talk) 19:03, 4 January 2018 (UTC)

  There was actually one (and only one, as far as I've been able to determine, with almost every style guide ever) that actually advised this. So, it's not totally unattested, but incredibly rare, presumably because it's too pedantic for most people to tolerate. Technical writers would still do this when quoting code in which the . at the end wasn't a full stop/period but a different meaning of the glyph, and that's fine. But it would probably be better to rewrite.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:00, 5 January 2018 (UTC)

  Unless it can be demonstrated to solve an actual, real-world problem, there's no way it will gain traction at Wikipedia. Curly "JFC" Turkey 🍁 ¡gobble! 02:23, 5 January 2018 (UTC)

  • Well, lets keep the discussion to that of sentence fragments, as the quoting of compete sentences is a different issue; your solution doesn't apply to this one. Curly "JFC" Turkey 🍁 ¡gobble! 22:53, 4 January 2018 (UTC)
    • Ignore the last two sentences of my comment if you wish, but all the rest is directly relevant. —David Eppstein (talk) 01:14, 5 January 2018 (UTC)
      • Sure. Curly "JFC" Turkey 🍁 ¡gobble! 02:09, 5 January 2018 (UTC)
• Both of them would go outside, since they're just fragments, and our terminal punctuation belongs to our entire sentence and is only meaningful in that fuller context; the string "really get under people's skin." by itself is meaningless. LQ forbids insertion of punctuation not in the original, as blatant misquotation; it does not require retention of terminal punctuation that was in the original when it doesn't make sense to do so. Otherwise no excerpting would be possible at all. I.e., there is no difference between taking an original statement, "Janet's cat is orange and ugly.", and quoting it as "He said her cat is "orange and ugly", which I though was funny.", versus "He said her cat is 'orange and ugly'." But include it inside the quote here: "He said: 'Janet's cat is orange and ugly.'" Leaving it out when quoting a full sentence strongly implies we're quoting a fragment. But if we're quoting a fragment, the exact same principle that allows us to partially quote without all the words also allows us to partially quote without terminal punctuation that doesn't make sense inside the fragment when the fragment is viewed on its own. A third way of putting it: If I write "My cat is loud, ha ha", you would not partial-quote it as "McCandlish said 'My cat is loud,'." – desperately retaining the comma as part of the original construction.

  Re: the claims that MOS:LQ "then goes on to give a bunch of examples which in many cases contradict that" we "[i]nclude terminal punctuation within the quotation marks only if it was present in the original material, and otherwise place it after the closing quotation mark" – I've reviewed it line by line and it does not do that at all. All the examples are correct. (This has not always been the case; people have monkeyed with it before, especially to make it match one of the dozen+ British styles that were inspired by LQ but have diverged from it in inconsistent ways.)
   — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:00, 5 January 2018 (UTC)

  Which is how I interpret things, but is this what MOS:LQ actually says? EEng believes it does not, and has placed the punctuation at Sacred Cod back inside the quotemarks, citing MOS:LQ. I've (occasinally) had others interpret MOS:LQ this way (which is why I opened this discussion), although not to the point of reverting me. Curly "JFC" Turkey 🍁 ¡gobble! 02:09, 5 January 2018 (UTC)

  After just re-reviewing it, yes that is what it says. I think flipping the order of two sentences and examples [11] will resolve it.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:54, 5 January 2018 (UTC)

  (edit conflict against SM's post just above, and maybe that fixes it, I don't know) Look, LQ says Include terminal punctuation within the quotation marks only if it was present in the original material, and otherwise place it after the closing quotation mark, period (so to speak). It says if X, do A, otherwise do B. It purports by its wording to dispose of every case that arises. The later examples don't call themselves exceptions to this Prime Directive; they're just there, telling you to do things, some of which (depending on circumstance) contradict the opening instruction. For example, let's say the source says, What Marlin said was, "I need to find Nemo.", and for whatever reason I want to cast this as either Marlin needed, he said, "to find Nemo". or Marlin needed, he said, "to find Nemo." According to the later examples given by LQ, I'm supposed to write the first, but according to the LQ's unambiguous, here's-how-it's-done, no-exceptions-provided-for Prime Directive, I'm supposed to use the second. Thus the contradiction. EEng 03:17, 5 January 2018 (UTC)

  It's a question of what you mean by "the original material" that you're quoting. If you intend the original quoted material to be "to find Nemo." as a sentence fragment with a terminal period, then by all means include the period within the quote. But why would you want to do that? If, as seems much more likely, that what you intend to quote is the unpunctuated fragment "to find Nemo", then the period is not part of the original material that you're quoting and should not be put there merely because it syntactically matches a period in the quoting sentence. —David Eppstein (talk) 03:26, 5 January 2018 (UTC)

  You're not understanding what you're quoting, EEng. The guidline does not say to include punctuation if it's in the original, but only that you can include punctuation only if it appears in the original—meaning: don't through a comma or period in there that wasn't in the original. The "to find Nemo" example at MOS:LQ is totally correct—why do you think it's not? Which part of the guideline do think think makes it ambiguous? Curly "JFC" Turkey 🍁 ¡gobble! 03:35, 5 January 2018 (UTC)

  Yep. I had the same perception, though I sandwiched into the above material: 'What seems to be happening here is that EEng is extrapolating beyond what it actually says and arriving at something like "Include terminal punctuation within the quotation marks if it was present in the original material, no matter what, and place all other punctuation after the closing quotation mark", or something to that effect, though it's not entirely clear, since he's just objecting without being specific.' [12]  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:39, 5 January 2018 (UTC)

  The Prime Directive absolutely says If X do A, otherwise do the opposite of A. There is no middle. It does say or imply If X do A, otherwise you don't have to do A; if it's trying to say the latter it does an incompetent job of it. David Eppstein, I appoint you my proxy for the rest of this discussion, to vote my shares for me as if I were personally present. Perhaps SM's changes fixed it. I'll rely on your judgment. EEng 03:49, 5 January 2018 (UTC)

  But where does it say that? None of us sees that. Curly "JFC" Turkey 🍁 ¡gobble! 04:18, 5 January 2018 (UTC)

  What part of Include terminal punctuation within the quotation marks only if it was present in the original material, and otherwise place it after the closing quotation mark don't you understand? David Eppstein, can you toss me a lifeline here? EEng 05:26, 5 January 2018 (UTC)

  Maybe it's the meaning of "only"? To me it means that you cannot add punctuation that was not already there in the quote, but it says nothing about whether you should or should not take as part of the quote the punctuation at the beginning or ending of the quote. You are trying to add extra punctuation at the end of your quote. I don't understand why that string, and not the shorter string without the punctuation, is what you want to quote. —David Eppstein (talk) 05:34, 5 January 2018 (UTC)

  You keep quoting that, EEng, and the rest of us keep telling you you're misreading it. The sentence does not convey the meaning you insist it does—it would if the word "only" were not in it. Are you making sure you're reading the whole sentence before you copy-&-paste it? Curly "JFC" Turkey 🍁 ¡gobble! 07:15, 5 January 2018 (UTC)

  Exactly. The "prime directive" does not say "If X do A, otherwise do B [the opposite of A]" at all. It says "Do A only if X; default to B", and "doing A when X" is not even required, just permissible. See first revision proposal below. It will just end this confusion (which is rare, but apparently hard to shake when it happens) without further question or ado.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:53, 5 January 2018 (UTC)

Potential clarification

This following semi-recent addition is not actually very helpful, and may be the primary source of confusion:

For the most part, this means treating periods and commas in the same way as question marks: Keep them inside the quotation marks if they apply only to the quoted material and outside if they apply to the whole sentence. Examples are given below.

Aside from being repetitive of much of the sentence that precedes it, and vaguely worded, this presupposes that the reader understands all about the niceties of question mark usage, when this actually varies between style guides, and we have a section here instructing editors on our version, so we know they didn't all arrive here with this in their brains already. Worse, question marks themselves are subject to an LQ rule of their own, rendering this statement confusing and meaningless.

It would probably make more sense to just say this:

Logical quotation in a nutshell: Never insert new punctuation into a quotation; retain a full stop (period) or comma at the end of and inside a quoted passage only when it is needed by both the quoted material and the quoting sentence.

It's shorter and doesn't presuppose anything, uses clearer wording, and it covers both the He said "Ouch, that hurts." case and the "Ouch," he said, "that hurts." case (it's not all about terminal punctuation), while ruling out "Why," he asked, "did you hit me?" (must be "Why", he asked, "did you hit me?") and "Ouch," was what he said. (it's "Ouch" was what he said.) It also doesn't exclude retention of "!" and "?", which we cover in a later point. We already provide conforming examples; this isn't a substantive change in any way, just a better clarification than that "same way as question marks" attempt.

However, we should ditch the insipid fictional dialogue examples we have. Replace them with structurally identical material that actually pertains to how we write encyclopedia articles, e.g. quoting from non-fiction sources. It would make this all much easier to relate to and apply.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:39, 5 January 2018 (UTC)

• I don't think that'll satisfy EEng if the current wording doesn't. Should there not be something explicit about sentence fragments vs complete sentences? Curly "JFC" Turkey 🍁 ¡gobble! 04:21, 5 January 2018 (UTC)

  There already is ("If the quotation is a single word or a sentence fragment, place the terminal punctuation outside the closing quotation mark. When quoting a full sentence the end of which coincides with the end of the sentence containing it, place terminal punctuation inside the closing quotation mark."), and this wouldn't touch it, just prepare people for it. I.e., there is no "exception" as EEng's been conceiving of it; the existing language about fragments doesn't diverge from or contradict the main LQ rule, it's just so clouded with "same way as question marks" blather – before we even get to question marks in LQ at all – that at least a few people aren't getting it. This nutshell replacement sentence should fix that.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:05, 5 January 2018 (UTC); revised 06:16, 5 January 2018 (UTC)

Apology

You're all correct. I was somehow parsing the only if as if, even when it was rubbed in my face. In my (very pale) defense I'll say that the second half of Include terminal punctuation within the quotation marks only if it was present in the original material, and otherwise place it after the closing quotation mark is redundant to the first, and it's natural for the brain to look for two different imports i.e. an implication and its converse. Laugh at me if you will.

Nonetheless, I'm glad to see there's recognition that the presentation needs improvement. May I suggest that the Prime Directive be restated simply as something like Any terminal punctuation inside the quotation marks should be marks present in the material quoted. EEng 18:32, 6 January 2018 (UTC)

Knew you'd come around. Coffee is your friend. I'm thinking on the revision idea. I'm not sure it can be stressed enough how particular we have to be in this section of MoS or people won't understand or will, secretly, but will wikilawyer and look for ways to drive wedges. I don't dig the "marks should be marks" bit. And "the material quoted" is apt to be misinterpreted; this could be misread (willfully) as "If you're quoting something, and using quotation marks (instead of a block quote), then always put the terminal punctuation inside." I.e. use typographer's quotes a.k.a. "American" style.

The original isn't really redundant so much as giving both sides of the coin for extra clarity, and is fixable by juggling words a little, maybe Place terminal punctuation after the closing quotation mark by default; only include it within the quotation marks if it was present in the original material. That seems totally unambiguous to me, especially if we combine it with #Potential clarification above and get rid of the confusing "like questions marks" stuff.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:48, 9 January 2018 (UTC)

Potential clarification 2

Moot

 – Withdrawn.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:48, 9 January 2018 (UTC)

Things like this have (not for the first time) inspired me to consider adding something like the following after the fragments and full sentences part: "However, for long fragments that form most of a complete sentence and simply omit an introductory clause, the terminal punctuation may be retained inside the quotation marks." This a) would not be inconsistent with general LQ principles, and b) would agree better with both typical North American and most (not all) British/Commonwealth quotation styles. While it verges on WP:CREEP at first glance, I think it would have a tension-reduction effect that, while subtle, would be widespread and long lasting. Similar to no longer requiring a colon before a quote of a full sentence if it's short. (People just don't like writing XYZCorp's response was: "Not yet." We don't really have a reason to demand it, even if a colon is better as an introduction of longer material. Same principle applies here.)  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:16, 5 January 2018 (UTC)

The revised wording looks OK to me. Personally I would prefer to choose my quoted 'fragment' to end before any terminal punctuation, so that the punctuation sits outside, where it belongs. The 'parent' of the sentence in the article is, after all, the quoting editor, who should also give birth to its terminal punctuation; whether the quoted author happened to take breath at the end of his or her contribution isn't material to the meaning of the sentence. To distinguish between he said "this rule is crap." and he said "this rule is crap". on the basis of whether the quoted author concluded his sentence there is somewhat bizarre. MapReader (talk) 10:57, 5 January 2018 (UTC)

I share that view, especially for short quotes, but when the material being quoted is, e.g., "Our study's methodology is [30 more words]." – I mean that there are 30 more words we're actually quoting, not a bracketed thing saying "30 more words" – and we quote it as The study's methodology was "[30 more words]". , then people are apt to fuss about having to keep the period outside the quote. The same thing could be done as "[The] study's methodology is [30 more words]."  I'm just looking for ways to avoid people grinding their teeth, especially when it's about something we don't actually have a strong reason to care about. That said, if no one after a week or so is enthusiastic about this one, then there's no reason to add it, since it is a minor consistency variance. I'm just going by what I see people do fairly often, and what I've seen people revert about in confusion or disagreement.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:32, 6 January 2018 (UTC)

How could the length of the fragment play into it at all? Sitting punctutation inside the quotes based on the length of the quoted fragment (a) is arbitrary, (b) is illogical, and (c) complicates the rule. What is going through these people's heads? Curly "JFC" Turkey 🍁 ¡gobble! 07:42, 6 January 2018 (UTC)

I was thinking the same. It is not misquoting someone to use their exact words, simply leaving the full stop off the end and sticking it quite properly outside the quotation. The only purpose of such edits is as a leisure activity for editors otherwise occupied in scouring articles for double spaces to delete. MapReader (talk) 08:23, 6 January 2018 (UTC)

Plays into it the same way that dropping of the serial comma does in short constructions like "I like metal, punk and industrial music". And also how it plays into dropping of introductory-phrase commas when the phrase is short, as in "In 1998 Smith moved to Botswana." It's not logical from a writing structure perspective, but it is from a mental processing one. I'm entirely happy to not make such exceptions, mind you, I'm just not particularly gung-ho about opposing them; bigger fish to fry. I'll abandon this "Potential clarification 2" idea, though, since the response has been negative so far. My effort to appease some and reduce their tooth-grinding is causing others to grind their own.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:32, 9 January 2018 (UTC)

Proposed: Complex inline lists

Some of the most frequent comprehension-impeding errors I encounter and correct could be addressed in a small section. I think it would ease some copyediting load in the long run (and of course make the encyclopedia text better for readers in innumerable places); probably goes right after MOS:SERIAL, but it could also live in MOS:LISTS, and just be summarized in the main MoS page without the example table:

Use of conjunctions, commas, and parentheticals in complex inline lists

When writing an inline list containing compound expressions, always use the serial comma and always include an "and", "or", or "nor" (depending on list type) before the final element in the list even if that element already contains its own internal conjunction. Use semicolons or parentheticals (in any of various forms) as necessary for clarity. Do not mistake a parenthetical tacked on at the end to be the last list item (which was the item before that). It may help to imagine them all in grouping brackets somewhat like mathematical terms when deciding how to format the list.

Use	Answers rely on archaeological evidence, the accounts of foreign observers, and legends and literature from centuries later. Structure: (A), (B), + ((C1) + (C2))
Or	Answers rely on archaeological evidence, the accounts of foreign observers, legends, and literature from centuries later. Structure: (A), (B), (C), + (D) This is a different meaning (old-time legends, much later literature) but may be what the source(s) indicated.
Not*	Answers rely on archaeological evidence, the accounts of foreign observers, legends and literature from centuries later. Structure? (A), (B), ... uh, which is it?
Use	The region consists of Mexico, the United States (excluding Hawaii), Canada, and Greenland, together with associated offshore islands. Structure: (A), ((B) minus (B1)), (C), + (D)), parenthetically: don't forget (E). Parenthesizing "excluding Hawaii" greatly aided parseability here.
Not	The region consists of Mexico, the United States excluding Hawaii, Canada, and Greenland, together with associated offshore islands. Structure? (A), ((B) minus: ((B1), (B2?), (B3?) ... is this (B4?) or (C?) ... Help!
Not*	The region consists of Mexico, the United States excluding Hawaii, Canada and Greenland, together with associated offshore islands. Structure? Any of at least three possibilities! Adults can probably figure it out with effort, but school children who don't yet know their geography well would be sorely confused, especially since these might not be linked.
...	[could add a semicolon example]

^* The form the articles actually used before revision. The second could have been worse still, with no comma after "Greenland".

An inline list structured like A, B C, and D is not proper writing (missing a required comma). Nor is A, B, C as well as D (missing a required and, even if a comma is included after C).

[End proposed material.]

Quite short as to rulemaking, though the examples are rich. These are just two real examples from about an hour ago (some details compressed for brevity) – in otherwise very well-written articles. The journalistic and fiction-writing aversion to the serial comma is poisonous. While no one is confused by the lack of one in a very simple construction like "My dog strangely likes pistachios, potatoes and eggplant", there's no question that it's needed in these kinds of constructions.

Yet only two days ago, I had someone tendentiously revert-warring against a comma despite patently obvious ambiguity (that was a case of "So-and-so guitarist was a member of the Chicken and Dumplings, Doodah and the Snorkel Weasels" (whatever the actual band names were); only someone familiar with the bands would be certain this meant three bands (C&D, D, and SW). The reverter's excuse? As always: "MoS doesn't say it's required."

— Preceding unsigned comment added by SMcCandlish (talk • contribs)

Oh boy, Oxford comma wars. *gets popcorn* —David Eppstein (talk) 17:39, 6 January 2018 (UTC)

Did you say "comma wars"? Will go dust off my uniform from the past skirmishes. Better yet, did you say "popcorn"! (p.s. nice work, would happily support this proposal.) Randy Kryn (talk) 20:45, 6 January 2018 (UTC)

Could be worse – could be an Oxford coma. EEng 15:08, 7 January 2018 (UTC)

• SM, does the lowly semicolon have no place in your toolbox of disambiguators? EEng 22:35, 7 January 2018 (UTC)

  Argh! Yes, you know I wallow in the semicolon. I left it out by accident due to copy-pasting and whatnot while building that table. I've put it back in.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:07, 9 January 2018 (UTC)

Question re use of infobox parameter

When a list of areas served is present in an article's infobox, should Puerto Rico be listed if the United States is already on the list? Daylen (talk) 00:02, 7 January 2018 (UTC)

Can someone activate our team of rabbis, please? EEng 22:28, 7 January 2018 (UTC)

I would say “yes”... most readers don’t think of Puerto Rico (or other US Territories) when they see a reference to th US... they only think of the States. Alternatively, the listing can read: “United States and its Territories”... or something similar. Blueboar (talk) 23:46, 7 January 2018 (UTC)

Agreed. It'll depend on context.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:08, 9 January 2018 (UTC)

RfC: "Allows to"

Should MoS deprecate the use of "allows to" in constructions like "The application allows to download files more rapidly"? 18:55, 10 January 2018 (UTC)

Been putting this off for a while, but it's time. We need to decide on whether to welcome this non-standard construction or deprecate it. It's been making more inroads into our articles, especially those on technical subjects and non-Western (especially South Asian) ones (I first encountered it on Wikipedia in the article Carrom, probably around 2006 or so). I've encountered this referent-dropping practice with a handful of other words, but the only one it seems to be particularly common with is "allow[s|ing|ed]".

"Allows ... to" requires a referent in standard English ("allow you to", "allows someone to", "allowed a soldier to", "allowing chickens to", etc.), in both North American and Commonwealth English. But constructions like "The application allows to download files more rapidly" have been entering English since around the mid-1980s, and have become more common since ca. 2010. It got here ultimately from some Indian and other South Asian languages (I think Malay might be one, but I may misremember) that use such a construction, and have imported it into their regional, informal, second-language English as a pidgin formation (the same process that leads to dialectal output in Ireland like "She's after putting it on the table", "Look at your man there", "He's me dog he is", etc., all from Irish Gaelic grammar). It's gotten into English via technical documentation written in South Asia, and has picked up steam due to the large influx of people from that part of the world to the UK, US, etc.

• Stats: Here's just the first page of 500 instances, and there are 4 more (just searching mainspace), mostly in technical-subject articles. Less that 1% of these are the awkward but grammatical construction found in "A tenant who causes, or allows to transpire, damage to the property is liable ...". But they're not random typos. This is a programmatic insertion of things like "This allows to define easily complex manifolds" as if it's valid formal English. Google Ngrams shows a radical increase in frequency of "allows to" in published material since 1980. Using other searches, e.g. at Google Books, one can see that it's almost always in technical material. Similar results are found in Google Scholar searches [13].

 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:25, 9 January 2018 (UTC); revised: 18:05, 10 January 2018 (UTC)

PS: Expert testimony [14] also has "allows to" as a common error of Germans with English as a second language.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  17:28, 10 January 2018 (UTC)

• I think this should be treated in the same class of informal colloquialisms as "ain't" and "irregardless" and "yous", except that it's worth mentioning specifically in MoS somewhere, because the frequency of its use in gadget manuals and online software documentation lends it a veneer of purloined formality, so use of it on WP has been on the rise. If we add it to MoS (even as just an example somewhere) then it'll be easy to get it added to AWB cleanup lists and other scripts as something to look for. Even the rare cases where the string "allows to" can be used grammatically (see below), it can almost always be written to be less awkward.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:25, 9 January 2018 (UTC); revised: 18:05, 10 January 2018 (UTC)
• Do not allow: it reads really oddly, and does not seem appropriate for an encyclopaedia. –Sb2001 20:30, 9 January 2018 (UTC)
• We should not allow to use this formation Agree with Sb2001: it's not WP:FORMAL enough for an encyclopedia. (Note to User:SMcCandlish though: Your last example of an informal Hiberno-English construction doesn't really serve its intended purpose, since the possessive "me" is not exclusive to Ireland, nor I believe does it have anything to do with Irish-Gaelic grammar, but it stands out a lot more -- at least to me as someone who grew up in Ireland and is fairly accustomed to both -- than what was presumably your intended point of the final ", he is".) Hijiri 88 (聖やや) 05:07, 10 January 2018 (UTC)
• Disallow: I've never seen this construction and cannot accept it. "Allows [subject] to" or "allows the [verb-ing] of" are of course fine.  White Whirlwind  咨  05:41, 10 January 2018 (UTC)
• Doesn't the MoS disallow non-standard English as it is? Is anyone arguing it's acceptable? This sounds like a case of WP:JUSTFIXIT—I doubt addressing it in the MoS will have any affect if nobody's arguing for its acceptance. It's not even an informalism like "ain't" if it's non-native speakers doing this. Curly "JFC" Turkey 🍁 ¡gobble! 06:01, 10 January 2018 (UTC)

Yeah, unsure if it needs to be there. Galobtter (pingó mió) 06:04, 10 January 2018 (UTC)

• Noooope Yup, the MOS should not allows to using this ungrammatical construction/colloquialism. Galobtter (pingó mió) 06:04, 10 January 2018 (UTC)(edit conflict)
• Comment - I'll ask the CREEP question: How much editor time is being spent arguing about this? I often improve bad writing with no objection. (add) Oh I now see Curly already asked it. See, I'm not crazy. ―Mandruss ☎ 06:18, 10 January 2018 (UTC)

  I'm not sure that's the question, and we need not add a whole line item about it, but use it as an example. Better questions are how much reader time is spent puzzling over it, how much editorial time is spent correcting it in page after page, and how much are both going to increase if we *allow to continue? My wager is multiplicative growth in both problems. It's also going to be argued to be an ENGVAR matter, especially as Western familiarity with the expression increases. We're already getting too much colloquial exceptionalism out of that quarter (e.g. acceptance of counting in krore even though that's completely meaningless to everyone else in the world reading our articles in which this is done, and Indic speakers of English have no trouble at all with the non-krore-based, decimal number system, any more than native speakers have any trouble with 10s even if they also understand dozens. I don't think that allowance has actual consensus, yet there it is in an MoS page and there it is in our articles).

  If we don't deal with "allows to" stuff now we'll just have to do it later after there's already an entrenched camp in support of it. Just Google (or Yandex or DuckDuckGo) "allows to", and the entire first page of results consists of debates on grammar and usage forums, bleeding into actual usage of it in books and such. Some are what we'd call reputable publications [15] (though virtually never in material by native English speakers). If you do a Google Books or Google Scholar search on it, you'll find that its spreading from Asian writers to other non-native English speakers in Europe; it seems to suit the love of grammatical compression in journal writing. Because these works are not copy-editing at that level, it lends another illusion of acceptance or even preference to "allows to". PS: There's actually an awkward and primarily legal construction in which it's permissible in more broadly accepted English ("A tenant who causes or allows to transpire damage to the property is liable ...").
   — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:39, 10 January 2018 (UTC)

  English is an official language of India—is "allow to" coming from Indian native English speakers? If not, it's not an ENGVAR issue—it's simply incorrect English, regardless of register. It's a pain in the ass to clean up, but what are you going to do? Spank non-native speakers for having imperfect English? Ban them? There are a lot of Japan-related articles that have errors typical of Japanese non-native English speakers in them—I clean them up all the time. Should I make a list of typical patterns that we can also add to the MoS?
  When someone makes an argument in a GAN or FAC that such usage should be accepted, that will be the time to consider whether the MoS should deal with it. Curly "JFC" Turkey 🍁 ¡gobble! 09:56, 10 January 2018 (UTC)

There are actually very few indian native english speakers - most speak some other language at home and learn a different language first. Only 226,449 - 0.02% - according to stats. So I don't think "allows to" is from Indian native english speakers (and either way it's just ugh) Galobtter (pingó mió) 10:20, 10 January 2018 (UTC)

CT, the issue is that the frequency with which this construction has been appearing in technical writing produced by South Asians (and, apparently, Germans) is giving native speakers (especially young ones) the impression that it's actually a standard English construction. I've noticed a shocking increase in its usage just over the last two years. In a generation or two, maybe our dictionaries will say that it has in fact become standard English (I actually firmly predict this result), but in the interim, it's a weird colloquialism that's invading our text.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:50, 10 January 2018 (UTC)

I'd have to see evidence that it has reached "colloquial" status and that it has had an actual impact on native speakers. Curly "JFC" Turkey 🍁 ¡gobble! 23:08, 10 January 2018 (UTC)

• Comment - IMO it's generally a bad idea to convert open discussion to RfC mid-stream (rather than starting the RfC separately). RfC needs more structure than open discussion to be effective. At bare minimum, the part copied to the RfC listings—that preceding the first time stamp—needs to be a concise statement of the question or proposal. I've added that, but SMcC or anyone else is welcome to improve it. ―Mandruss ☎ 18:55, 10 January 2018 (UTC)
• Oh, come on -- really??? An RfC? Obviously this is not a phrasing we want, but neither do we need a rule against it, until and unless (as others have said before) there's evidence that editor time is being wasted in arguing about it -- not just that it appears sometimes in our articles. The kind of people who would write allows to aren't reading MOS on their own anyway, so the value of a guideline on this is that it's something to which more experienced editors can point to avoid a tiresome discussion. But absent (as I said) evidence that editor time is being wasted in arguing about this, it won't be called into service in that role either. As I always like to say: if MOS does not need a rule on something, then it needs to not have a rule on that thing, because it's far too bloated as it is. EEng 19:41, 10 January 2018 (UTC)

  I think the idea is that it would allow editors to remove instances of it systematically, without being questioned. –Sb2001 23:52, 10 January 2018 (UTC)

  You can do that right now. Curly "JFC" Turkey 🍁 ¡gobble! 00:04, 11 January 2018 (UTC)

  Not with the "not being questioned" part. The entire point is that this has become increasingly common in writing in general, but no where near common enough for encyclopedia wording.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:28, 11 January 2018 (UTC)

  I think I've asked this already, but where has it been questioned when someone has fixed it? Curly "JFC" Turkey 🍁 ¡gobble! 10:23, 11 January 2018 (UTC)

  Yes, an RfC, after two editors recently vented here and at WT:MOSCAPS about substantive changes to MoS pages being, in their view, insufficiently discussed. Can't have it both ways. Either stuff gets discussed well or it doesn't. While the change proposed here could be very short (e.g. "allows to upload quickly" or something like that including as "don't" example without any elaboration), it's significant in that someone way want to make some kind of ENGVAR case and present evidence, and it might have precedential value down the road for excluding or (to not predict the RfC outcome) permitting nascent usage changes before dictionaries adopt them. If this were about use of a one-off phrase at one article then not an RfC topic, but this already affects ~2000 actual articles (so far, and that was just the "allows to" construction, without looking for "allow to", "allowing to", etc.).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:28, 11 January 2018 (UTC)

• Per EEng, this is trying to swat a fly with a nuclear missile. Proper usage is still proper usage, and we should feel free to correct bad grammar when we find it; there's no possible way to pre-suppose every way someone will screw up the language, and we don't need an RFC to allow us to correct every possible bad usage before we can fix it. This is WP:BURO run amok. --Jayron32 19:48, 10 January 2018 (UTC)
• An RfC? Well, it's not grammatically correct as far as I see, so it shouldn't be used. It's missing the referent making the sentence awkward at best and ambiguous at worst. Should it be part of MoS? No. It's just grammar and we should not try to codify English language into MoS. —  HELLKNOWZ   ▎TALK 20:10, 10 January 2018 (UTC)
  • Over-interpretation; MoS contains many grammar points as do all style guides; it's implicit in what a style guide is, in the writing sense. In this context, "style" means grammar, spelling, layout, punctuation, font effects, accessibility, tone, world and symbol choice, and a dozen other things, not just "stylization".  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:28, 11 January 2018 (UTC)
    • Never said you cannot include grammar. I said this is a single case of misused grammar. It doesn't belong in any style guide. That's like listing "it is wrong to spell 'corect'." It's not part of some larger group of common misspellings or regional variations. —  HELLKNOWZ   ▎TALK 16:24, 11 January 2018 (UTC)
• Sounds OK to me. Not great or anything. InedibleHulk (talk) 20:23, January 10, 2018 (UTC)

InedibleHulk, I'm having trouble digesting what you're saying. What's OK? The usage, the rule against it, or the RfC? EEng 20:29, 10 January 2018 (UTC)

The first and last ones. InedibleHulk (talk) 20:32, January 10, 2018 (UTC)

• Oppose The MOS should not try to codify every piece of non-standard grammar out there. Suggest closing this early as a really questionable use of the RFC process. --SarekOfVulcan (talk) 20:34, 10 January 2018 (UTC)
• Yes and no – we can agree that we don't like "allows to", but also not bother putting it into the MoS. Thanks for asking. Dicklyon (talk) 02:46, 11 January 2018 (UTC)
• It already does deprecate it. "Avoid words and phrases that give the impression of straining for formality, that are unnecessarily regional, or that are not widely accepted." No additional change needed. There are too many ways that a piece of writing might deviate from widely accepted formal English to enumerate them all. —David Eppstein (talk) 02:50, 11 January 2018 (UTC)

  No one suggested enumerating them all, only this particular one because it's measurably and vastly increasing in frequency (yet still remains poorly accepted as of 2018). The idea isn't to add a paragraph about it, but to use it as an example.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:34, 11 January 2018 (UTC)

• Deprecate with extreme prejudice Anything we can do to thwart the advance of this noisome locution is worth the time and effort. Thank you for bringing our attention to it, SMcCandlish. — DCGeist (talk) 09:41, 11 January 2018 (UTC)
• Comment - Is the proposal for a specific section in the MoS, such as MOS:ARAB? Would it not suffice to add it to Wikipedia:List of commonly misused English words, which is already linked under WP:MOS#Contested vocabulary? Batternut (talk) 10:04, 11 January 2018 (UTC)
• Correct the usage when discovered, but there is no need for the MOS to explicitly discuss it. If someone reverts or questions your correction, point them to this RFC. Blueboar (talk) 12:04, 11 January 2018 (UTC)
• Comment: Some here seem to be assuming that the result of an RfC must be some change in MOS. It is perfectly valid to post an RfC, get a consensus, have an uninvolved closer write up a closing summary, and then do nothing. You can then point to the RfC when you are correcting grammar and someone objects or revert. --Guy Macon (talk) 15:46, 11 January 2018 (UTC)
• Oppose I oppose this phrasing's usage in (and support its removal from) Wikipedia.

But it does seem beyond the scope of MOS, as a word usage/syntax thing. I'm not saying MOS shouldn't cover word usage and syntax, but it doesn't today and there are hundreds of controversial wordings that could be included if it did.

On whether "allows to" is worth consensus gathering: It is my impression from where I've seen it used that many people believe it is appropriate wording and if you removed it from Wikipedia a thousand times, you'd start half a dozen fights. Anything we can do to bring those fights to a quick conclusion would help. Bryan Henderson (giraffedata) (talk) 16:58, 11 January 2018 (UTC)

• Meh. Discussions like this one, that Wikipedia allows to happen, are not necessarily ripe for consideration. Thomas Jefferson already gets enough grief. I think someone needs to speak with a grammar expert to find out exactly how the uses and misuses of “allows to” are properly described and explained by experts in this field. Definitely I oppose the misuses, but we need to more carefully distinguish from the proper uses. Anythingyouwant (talk) 18:22, 11 January 2018 (UTC)

Um... Actually, TJ's text you linked is a completely different usage which happens to have the same two words in a row. EEng 19:07, 11 January 2018 (UTC)

I know, but how would an English professor describe the difference between the proper usages and the improper ones? Anythingyouwant (talk) 19:10, 11 January 2018 (UTC)

The object in your sentence is "discussions" and in Jefferson's is "funds". SM^c is talking about when allows has no such object. Curly "JFC" Turkey 🍁 ¡gobble! 21:52, 11 January 2018 (UTC)

Ah, thank you User:Curly Turkey. So the idea is to ban saying "allows to" unless the word "allows" has an Object (grammar). I like idea much, but not at talk page where illiterate must take refuge. Anythingyouwant (talk) 22:14, 11 January 2018 (UTC)

You are most goodly much the learning of your new language being English! EEng

Only issue there is that linguists don't actually classify that as an object; it's something similar (with at least two different names), and people reading MoS are generally not up on linguistic terms anyway. We're writing in "how you learned English sentence diagramming in 7th grade" wording throughout MoS, and it's both imprecise and misleading at times (e.g. the stuff about prepositions versus coordinating conjunctions in MOS:TITLES is actually factually wrong but commonly how non-linguists try to write about it, so we've adopted their wording, conveniently but not necessarily wisely. Similarly, we sometimes make reference to adjectives and modifiers that are not actually either, but are often something else, such as complements. This is happening because the "schoolmarm" terminology is limited to the type of word that something is, and this doesn't always match the function that the word is fulfilling. I'm not sure whether we should fix this. It's probably easier to write around the imprecision of using word-type labels incorrectly for word-function concepts, than to introduce and define word-function concepts in MoS. Avoidance of doing so is one of the reasons MoS is so example-laden, on the theory that it's easier to illustrate/show than to explain.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:16, 12 January 2018 (UTC)

Regardless of labels, what you're talking about and the examples Anythingyouwant gives are not the same thing. The pattern you're talking about has not entered usage amongst native English speakers. We fix this the way we fix every other error on Wikipedia—this is not a style issue. Curly "JFC" Turkey 🍁 ¡gobble! 06:02, 14 January 2018 (UTC)

It's allowed to catch on by this RfC, though. This RfC allows to catch on. I'm both a full-blooded native English speaker and a Native English speaker by marriage; since I "voted" above, it's already gone from seeming OK to more than OK. I verily say my old ways shan't persist this strange fever past noonfall on the morrow. Probably the same thing our ancestors felt when foreigners introduced a quicker form of "please to"; must've hurt at first, but we compromised and got used to it. InedibleHulk (talk) 16:58, January 14, 2018 (UTC)

If you're saying that native English speakers actually use this pattern, we'll have to see evidence of that to evaluate whether it's appropriate on Wikipedia. SM^c has told us all the instances he's seen are by non-native speakers, in which case it is (as of 15 January 2018) an error—not even a colloquialism—not a matter of style. Curly "JFC" Turkey 🍁 ¡gobble! 23:29, 14 January 2018 (UTC)

Not yet they aren't, generally speaking. I'm just saying they will be soon enough, if the overall trend of dropping syllables, words or everything but the initials (OMG!) continues. There's also an accelerating pattern of Indian English (the South Asian sort) replacing Old School English in the online marketplace and forums (the "real world" for a decade or so now). Sticking to our roots, pedantically, is a noble defiance, but foolish when confronted with a wave yay big. Best to make like a tree and leave, as the natives used to say. Personally though, I've had it up to here with their obituary writers calling heart attacks "cardiac arrest" and respiraratory arrests "breathing their last". Other than that, I fold and look forward to seeing what our new rhetorical masters have in store for our still-proud language and its always-winding history. InedibleHulk (talk) 23:08, January 15, 2018 (UTC)

I'm having a lot of trouble following you—you seem to be saying that the usage should both be accepted and dealt with in the MoS? One way or the other, the MoS should not be dealing with issues that require a crystal ball. Curly "JFC" Turkey 🍁 ¡gobble! 01:20, 16 January 2018 (UTC)

Sorry about that. In a nutshell, I'm saying it'll be soon more accepted than it is, so don't deal with it in the MoS. Just let whatever happens happen organically. InedibleHulk (talk) 02:06, January 16, 2018 (UTC)

• Disallow. What's wrong with proper English, such as application allows (or enables) downloading files more rapidly, or application allows you (or users) to download files more rapidly  ?? MapReader (talk) 18:53, 11 January 2018 (UTC)
• Swat this fly with a nuclear missile. A brief example should be added, so when editors fight like animals from a crashed circus train over using or not using it, one of them will have something to shake. Since this discussion is already well along and looking bad for allows to, thanks to the likes of SMcClandish for thinking of minutia within Wikipedia's big picture. Randy Kryn (talk) 22:40, 11 January 2018 (UTC)

  I do have an "l" in my surname, but not where you've been putting it lately. :-)  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:16, 12 January 2018 (UTC)

• I have added an entry to Wikipedia:List of commonly misused English words#A, effectively deprecating "allows to". Batternut (talk) 07:15, 14 January 2018 (UTC)
• Add new "Phrasing" section: This is but one example of Engrish. It seems obvious that it has no place on Wikipedia, but perhaps a more general admonition would be useful: that the constructions of standard English are to be used (or shall we say those of the national variety of English in use in the article). Maybe a whole new section on specifying such and giving some common examples of what is not English. Surely there are more instances than just this? — Preceding unsigned comment added by DIYeditor (talk • contribs) 03:40, 15 January 2018 (UTC)
• Do not allow - if this is allowed to continue, Wikipedia could lose clarity. An encyclopedia that is internally confusing is not of much use.--Rpclod (talk) 12:25, 16 January 2018 (UTC)

Capitalization of the first letters of Wikipedia articles (&c) being referred to as such?

See the disambig header at Mind Meld. I'm pretty sure that, technically, "mind meld" when used in running prose like that would be spelled with all lower-case letters, but are we supposed to refer to it in this context the same way it would appear as the title of a Wikipedia article? It's particularly weird in this case since the way it is linked it looks like a standalone article; should it rather read For the fictional practice, see Vulcan (Star Trek)#Mind melds.? Hijiri 88 (聖やや) 04:58, 10 January 2018 (UTC)

I would think lowercase as well, though there's no reason not to do For the fictional practice, see mind meld; I don't see the point of giving Vulcan (Star Trek) § Mind melds. Just makes the hatnote take longer to read and understand.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:54, 10 January 2018 (UTC)

I would cap the initial letter of an article title in a hatnote, or in contexts like "see Mindmeld" and such, so it looks like an article title (sentence case). Dicklyon (talk) 02:44, 11 January 2018 (UTC)

Right, but mind meld isn't an article title, and redirects to a section with a different title. I don't feel strongly about it either way; it's kind of a link-style consistency versus link-target surprise thing. Hijiri's not arguing for something like "for the genre, see science fiction", to an actual article title. (At least I don't think that's the idea.)  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:32, 11 January 2018 (UTC)

It's already linked though. And not really a title of an article as SmCCandlish points out. IMHO it should be "mind meld"- it's a sentence, so this sort of capitalization looks strange. Galobtter (pingó mió) 17:03, 11 January 2018 (UTC)

One of Our Upper Case Letters is Missing? Martinevans123 (talk) 19:37, 11 January 2018 (UTC)

• When hat noting to a specific section of an article, I would indicate the article title ... just so the reader knows where he/she is being pointed to. This does not need to be done in the link, however... the text of the hatnote could read: “For the fictional usage (by Vulcans in Star Treck), see mind meld.” Or something similar. Blueboar (talk) 12:24, 11 January 2018 (UTC)

That's great for Star Treck, but what about Star Trek? EEng 19:19, 11 January 2018 (UTC)

blink... oh, yes... that too. 🙂 Blueboar (talk) 23:04, 11 January 2018 (UTC)

Using complete sentences in the prose

Is there any guideline concerning using complete sentences in the article prose? In particular, I am referring to this version of the lead sentence vs. this version. In the first version, the first paragraph ends with a sentence fragment. In the second version, the first paragraph ends with a complete sentence. Is there any guideline concerning which version is preferred? If there isn't, I have been told that I should start an RFC to discuss it [16]. Thank you. Frietjes (talk) 01:00, 12 January 2018 (UTC)

Somebody really thought that was worth an RfC? I think it goes without saying that the text of an article should be regular English, which means sentences, so I don't think you'll find any guidelines saying that.

The example here, "Population: 8,086 (2013 est.)", isn't even a sentence fragment. I don't know what you call it; it's not English. Bryan Henderson (giraffedata) (talk) 03:23, 12 January 2018 (UTC)

The idea is covered in WP:PROSE. I can see that some might prefer what is essentially a bullet point ("Population: whatever") because it shows the essentials with no fluff. However, it ain't English and prose is preferred. Johnuniq (talk) 06:43, 12 January 2018 (UTC)

thank you for the feedback, it appears it may not be an issue going forward[17], but it's good to have the feedback. My personal opinion is that the population figure should be moved out of the lead section and into the infobox. Frietjes (talk) 13:04, 12 January 2018 (UTC)

Yep, something like "Population: whatever" is an infobox or list or table entry, not regular article text. This is actually covered, in a sideways manner, at MOS:TRIVIA, which instructs us to avoid building up lists of factoids and to instead write in full sentences and paragraphs.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:00, 12 January 2018 (UTC)

Examples like that belong in the infobox. I wouldn't go as far as others to say it's "not English", but it doesn't fit in the running prose of a Wikipedia article. Hijiri 88 (聖やや) 04:14, 13 January 2018 (UTC)

It could be used in a parenthetical, though, "Doodah, Iowa (population 12,345)"; no colon.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:04, 15 January 2018 (UTC)

Keeping in mind that could draw the ire of those bent on removing prentheticals from the leads. Curly "JFC" Turkey 🍁 ¡gobble! 01:22, 16 January 2018 (UTC)

RfC: Linking to wikidata

I have noticed another editor adding links to wikidata for people who fail notability requirements to have articles on wikipedia. In some cases, the he links to wikidata after the article on the person was deleted in WP:AfD. Before I start reverting his edits, I like to know if this is an acceptable practice. I don't know much about wikidata and what gets included there, but it would seem to me if a person is mentioned in an article (usually as part of a list) and is not notable enough for his/her own article, then there shouldn't be a link to anything. Here's an example of what I'm talking about: Mayors of Teaneck, New Jersey That article has a lot of links to wikidata. I appreciate input on this.--Rusf10 (talk) 05:15, 14 January 2018 (UTC)

---

If someone wants to see how the article looked with the Wikidata links: https://en.wikipedia.org/enwiki/w/index.php?title=Mayors_of_Teaneck,_New_Jersey&oldid=817759493 ―Justin (koavf)❤T☮C☺M☯ 08:07, 16 January 2018 (UTC)

---

• Such links strikes me as a bad idea for multiple reasons:
  1. WikiData doesn't comply with en.WP's WP:Biographies of living people policy or our core content policies.
  2. Wikidata is not prose, so doing this is going to sharply transgress the principle of least surprise, and the reader may really have no idea what's happening at all.
  3. This isn't like linking to Wiktionary for WP:DICDEF material; that's linking to a sister project for material that should not be on Wikipedia at all because of what kind of material it is. Bios do not constitute such material.
  4. If a subject is arguably notable and should have an article here, it should be a redlink. If it's not, it should not be linked at all.
  5. It's WP:GAMING the system to keep promoting non-notable subjects.
      — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:02, 15 January 2018 (UTC)
• I agree with SMcCandlish here. I followed the wikidata links and my first thought was that this is a very elaborate and space-consuming way of presenting absolutely no information whatsoever. I think these links are a terrible idea. Reyk _YO! 14:06, 15 January 2018 (UTC)
• I would consider indeed to revert this completely. I already shiver when a person who fails our local inclusion standards, but is notable for e.g. Spanish is cross-wiki linked to the Spanish article (which is rather difficult to see even). I see this as nothing short of an inline external link to the website or social media account of non-notable subjects. We could consider an EditFilter for this, at least to detect such cases. --Dirk Beetstra ^{T C} 14:08, 15 January 2018 (UTC)

Wouldn't it make sense to keep the information without the link, though? Wikidata is also a sister project, and having items decorated with information about their meaning is a basic principle of the semantic web; it could be invaluable for automatic treatments of our content, or creating an improved browsing tool in the future. Our WP:BUILD policy supports the principle of creating a connected network of information that brings related items together.

I can imagine a specific template for this purpose, similar to how we already have WP:INTERWIKI tags. It should be a systematic effort though, and not the initiative of a single editor, so this should be discussed at the village pump, not at the manual of style. Diego (talk) 14:30, 15 January 2018 (UTC)

Generally WP:EL discourages external links within article bodies. The problem is EL operates on the basis that the EL's are about providing more information on the subject of the article, not unrelated information about someone who appears in the article. When it comes to lists, the only links within the list should either be a link to the relevant Wikipedia article, a properly cited reference, or an external link at the end to an appropriate resources on the subject of the article. In the above example, the wikidata EL's don't provide any further information on the subject 'Mayors of Teanick' than is already covered by an appropriate reference. Only in death does duty end (talk) 14:39, 15 January 2018 (UTC)

Links to Wikidata are under Wikipedia:Wikimedia sister projects, not WP:EL. The question here is whether we can make such links useful to readers (the requirement by that guideline); this doesn't need to be with a direct link to the URL, maybe we can explore more useful ways. Perhaps we should simply follow WP:SOFTSISP and create a soft link, to avoid WP:Astonish wighout losing the utility? Diego (talk) 14:53, 15 January 2018 (UTC)

It's unclear to me what use there is in linking to completely empty wikidata entries, as is the case here. Reyk _YO! 15:00, 15 January 2018 (UTC)

Can you give an example of a linked empty Wikidata entry? --RAN (talk) 20:30, 15 January 2018 (UTC)

The Karl Wagner entry was an example of a link to a contentless entry. It's a big sprawling page with pretty boxes everywhere but no information. Reyk _YO! 21:24, 15 January 2018 (UTC)

I'm not sure if you're being sarcastic, but those big boxes are the information stored in Wikidata (properties and values), together with the unique ID. Diego (talk) 11:31, 16 January 2018 (UTC)

Wikimedia sister project links are also covered by WP:EL. All external links are covered by WP:EL except for the named exceptions. See WP:ELMAYBE. The 'external' in EL is 'external to wikipedia' not 'external to wikimedia'. -edit- to expand, in an article about a person on Wikipedia, it may be acceptable to add a link to wikidata per ELMAYBE if wikidata contains more/useful information that is not covered within the article (leaving aside the issue of wikidata being unreliable for the moment). In an article about something else, in which the person is named, its almost certain the wikidata entry will not contain useful information to that article, as the wikidata material would be linked to the person. Only in death does duty end (talk) 15:24, 15 January 2018 (UTC)

But WP:EL covers links within an article; it does not cover soft redirects. Diego (talk) 15:41, 15 January 2018 (UTC)

Those are not soft redirects. Only in death does duty end (talk) 20:44, 15 January 2018 (UTC)

I know that. My proposal was changing them to soft redirects, because that's how the relevant guideline WP:SOFTSISP says that links to sister projects should be handled. Diego (talk) 10:24, 16 January 2018 (UTC)

• Much of this discussion is redundant, it seems to me. Links to Wikidata now appear automatically under "Tools" in the left margin of the desktop version as soon as there is a Wikidata item that links to the article. So there's never a need to add a link to Wikidata (or Wikispecies) in the External links section. Peter coxhead (talk) 15:28, 15 January 2018 (UTC)

See the above example RE Mayors of Teaneck, the wikidata links added to the Wikipedia article are not to wikidata items that link to the article page. (The wikidata link under tools goes here. Only in death does duty end (talk) 15:33, 15 January 2018 (UTC)

Rusf10 already considers the case closed and has removed the links. An example would be Frank White Burr. -RAN (talk) 21:07, 15 January 2018 (UTC)

User:Richard Arthur Norton (1958- ), the response here was a near unanimous consensus against linking to wikidata, but if you want to drag this on, go right ahead. It is also worth mentioning that the article for Frank White Burr was deleted as per WP:Articles for deletion/Frank W. Burr. The result was not redirect either, but that's another issue.--Rusf10 (talk) 21:19, 15 January 2018 (UTC)

Taking out the wikidata links might be jumping the gun a little, although I don't think consensus will change, but I do agree with taking out that big blob of hidden text. I'm not sure what it was even for. Reyk _YO! 21:34, 15 January 2018 (UTC)

"the response here was a near unanimous consensus" Well, given the one-sided comments posted above, that's perhaps understandable, but the RfC has only been open for two days, and has not been centrally advertised (which is required for something so sweeping), so it's too soon to suggest consensus has been reached. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 16 January 2018 (UTC)

Re. "centrally advertised": sorted --Francis Schonken (talk) 12:35, 16 January 2018 (UTC)

While the links in the Mayors of Teaneck list are indeed to different items than that of the equivalent to the page, the links mentioned by Peter do indeed render moot any suggestion that Wikidata is not a suitable target for us to link to, or that there is not consensus to regard it as such.

"WikiData doesn't comply with en.WP's WP:Biographies of living people policy or our core content policies." Neither does Commons, nor Wikisource, nor any of our sister projects, including other Wikipedias. This point is completely irrelevant. Wikidata, does though comply with WMF policy on BLPs.

Link to Wikidata in existing tables if they are not getting an article

• Link to the name in Wikidata if they appear in a table. Mayors of Teaneck, New Jersey is a good example of people that will not get full articles. If someone thinks they can expand an entry into a full biography, nothing stops them if they meet WP:GNG. Linking to Wikidata allows us to disambiguate people of the same name and link to other authority control identifiers like VIAF and LCCN. No one is arguing that being in Wikidata makes you Wikipedia notable. This is for people who do not have a full biography and most likely never will. It is no different than linking to the Italian Wikipedia for people there, that will not get an article in the English Wikipedia. Do not link to people in Wikidata for "Notable people from X" in location articles. Being in Wikidata does not make you notable, but notable people can be in Wikidata where the biographical data is too thin for a full article. --RAN (talk) 20:26, 15 January 2018 (UTC)

It is different, because Italian Wikipedia contains useful information to a reader which is more compliant with our local policies. Wikidata does not. Only in death does duty end (talk) 20:47, 15 January 2018 (UTC)

What useless information is in Wikidata? --RAN (talk) 21:00, 15 January 2018 (UTC)

Let me turn that question around.... what USEFUL information is at Wikidata? Blueboar (talk) 06:15, 16 January 2018 (UTC)

Interwiki links. And, um, ... I think that's it really. As an example of what's wrong with Wikidata, its page on one of the Teaneck mayors [18], an immigrant from India to Tanzania and then the US, lists his citizenship as US, based on zero sources. It's a plausible guess that he's a naturalized citizen (maybe Teaneck requires its mayors to be citizens, I don't know), but as far as I can tell it's only a guess, and if true is only true for a certain period of time and doesn't tell the whole story. That sort of thing would not be acceptable in a BLP here, and I think it violates WP:ELNO #2 and #12. —David Eppstein (talk) 06:22, 16 January 2018 (UTC)

• Only link to the interwiki links section of Wikidata items in cases where there are articles for something in three or more Wikipedias but not in English. This is the way {{Interlanguage link}} does it (though the choice of Wikidata link vs. direct link(s) to other Wikipedias is at editors' discretion), solely for the purpose of allowing the reader to use the links, and it avoids presenting the reader with too many or too few language links and allows the reader to skip past the offensive, objectionable and completely untrue piles of useless data large number of tangentially relevant statements and links to other databases that some items have. Jc86035 (talk) 03:14, 16 January 2018 (UTC)

It's useful to specify when two Wikipedia articles speak about the same person. Pernell Roberts, Helen Schucman and Saybrook University all speak about the same Eleanor Criswell. Wikidata links allow this information to be conveyed to the reader and otherwise it wouldn't be expressed in Wikipedia. I see no need for a subject to be notable for us to specify that when a subject is talked about in multiple articles to specify that it's the same person. ChristianKl ❪✉❫ 10:16, 16 January 2018 (UTC)

Like this: Eleanor Criswell? --Francis Schonken (talk) 10:24, 16 January 2018 (UTC)

• Just thinking out loud: what if our 'page' of a non-existent article (the red-linked page) is interwiki-linking to other Wikipedia's articles (including wikisource/wikidata/etc) of said article if articles exist there (it may help the reader to more information, or editors to a quick start if they wish to create the article)? --Dirk Beetstra ^{T C} 07:39, 16 January 2018 (UTC)
  • Did you mean what we do with {{ill}} templates, which makes linking to more than one page on other projects possible, starting from a redlink? --Francis Schonken (talk) 07:47, 16 January 2018 (UTC)
    • Roughly, though without telling the page which interwikis to show (though I then don't know how a page would detect the existence etc.). --Dirk Beetstra ^{T C} 07:51, 16 January 2018 (UTC)

      Technically, one can call multiply Wikidata entries from the same page, and actually Wikivoyage heavily uses this.--Ymblanter (talk) 07:54, 16 January 2018 (UTC)

      E. g. "De Danske, Norske og Tÿdske Undersaatters Glæde, TWV 12:10" would link to multiple articles on other Wikipedias & Commons (via the Wikidata item). Would that approach what you had in mind? Note that at the TWV list I had used "De Danske, Norske og Tÿdske Undersaatters Glæde, TWV 12:10" instead, with three direct links to the sister projects instead: this has the advantage of one-click reach of these other pages, but the disadvantage of not linking to any future other Wikimedia project which may have an article on this before en.Wikipedia (although it would also not take more than two clicks via any of the linked pages to any future additional page on the same topic elsewhere). --Francis Schonken (talk) 08:15, 16 January 2018 (UTC)

With regards to Wikidata links within tables of items: a while ago I created Template:Wikidata icon which allows for this in a visually clear way (without having to have the Q-number showing to the reader). This is useful for list articles where not every item in the list is necessarily appropriate for a standalone Wikipedia article [yet?] but THEY ARE ALL applicable for Wikidata items (practical example), or when the infobox is about two separate things described in the same article (practical example). Wittylama 12:51, 16 January 2018 (UTC)

Like his? --Francis Schonken (talk) 13:20, 16 January 2018 (UTC)

The horror :-) Adding meaningless (to readers) "flags" to items in lists or in the middle of text just to indicate that some other unreliable site has "information" (well, some structured data) on this item, which in most cases will leave them disappointed anyway, is a bad idea. There is no reason to spam one specific site simply because it is a "sister site". That specific example sends readers to an unsourced page with an external link to Findagrave, where the Findagrave page doesn't even include the information that he was mayor of that town. Why would we ever want to promote such links (either disguised as bluelinks, or by giving them a pretty icon)? Fram (talk) 13:29, 16 January 2018 (UTC)

Never link to Wikidata

• I thought we had this discussion a few months ago at the Village Pump... any way... until wikidata can comply with our Policies and guidelines, we should not link to it. At all. Blueboar (talk) 22:28, 15 January 2018 (UTC)
• Support. Had enough of WikiData shenanigans. Curly "JFC" Turkey 🍁 ¡gobble! 01:23, 16 January 2018 (UTC)
• Support No wikidata links as per  SMcCandlish above.— Preceding unsigned comment added by Rusf10 (talk • contribs)
• Support Unless and until Wikidata can prove its security is as good or better than here at Wikipedia, we should not use it. A good model here is Commons; Commons works for use here because they've gotten good at stopping abuse. Unless and until Wikidata can establish themselves as good as Commons, we should not use it here. --Jayron32 01:37, 16 January 2018 (UTC)
• Support - I am not sure that we need to use Wikidata in any manner, but certainly not as a replacement for articles. Moreover, if an article might be plausible, it is better to have a redlink so that we can tell that an article is missing. — Carl (CBM · talk) 01:49, 16 January 2018 (UTC)
• Support avoiding wikidata links in article text. They do not have anywhere near the quality control or useful content of other inter-language links provided e.g. through {{ill}}, and seem to have been included in some of the examples discussed above primarily as a way to sidestep Wikipedia's BLP requirements. The link from an article to its own wikidata item (provided through wikimedia software and not under our control) should stay, of course, because we need it to make our links to other language versions of the same article. —David Eppstein (talk) 01:51, 16 January 2018 (UTC)
• Support per Jayron32 and David Eppstein. · · · Peter (Southwood) ^(talk): 06:12, 16 January 2018 (UTC)
• Support - There hasn't been a good case made for using Wikidata at all. And if its use in the Teaneck mayors article is typical, it seems to be just a means to dodge our content requirements while sending readers to a series of perplexing and useless dead ends. Reyk _YO! 06:28, 16 January 2018 (UTC)
• Support - No good case has been made for use of Wikidata, perhaps other than to replace the old interwikis. - Sitush (talk) 07:04, 16 January 2018 (UTC)
• Support per all the good reasons above. Fram (talk) 07:17, 16 January 2018 (UTC)
• Support not using WikiData (for transcluding data at all, only interwikis), and certainly not in this way. --Dirk Beetstra ^{T C} 07:26, 16 January 2018 (UTC)
• Support per Jayron - and for largely the same reason I have been harping on for months about. The comparisons to commons don't hold up under the slightest scrutiny because Commons has content policies that are equal to, or stricter than ENWP - which means content hosted there is 99% of the time able to be used as-is here. We don't have to use it, and commons doesn't force itself upon us. But should be choose to, we can be assured they (almost always) meet our free content requirements. Wikidata has no policies that come close to matching our content policies. It doesn't have a userbase remotely as large as is required to administer it effectively *to the point where we would consider it adequate*. And the userbase it does have is more concerned with collecting vast amounts of factoids rather than making sure they are accurate. Only in death does duty end (talk) 08:37, 16 January 2018 (UTC)
• Oppose as luddism (though I believe that in the case in question such links were not needed).--Ymblanter (talk) 10:08, 16 January 2018 (UTC)
• Oppose It's useful to specify when two Wikipedia articles talk about the same person even when that person isn't notable. That's for example the case for Pernell Roberts, Saybrook University and Helen Schucman which all talk about the same Eleanor Criswell. Disambiguation is also useful for list articles in general where Wikipedia might not want to show the date of birth/death for every person in the list but where that's still useful information to be able to disambiguate the listed people. ChristianKl ❪✉❫ 10:20, 16 January 2018 (UTC)
  • @ChristianKl: What? That is why Pernell Roberts, Saybrook University and Helen Schucman should all three link to Eleanor Criswell (and if that article gets created, the editor should make sure they all incoming links are actually to this specific Eleanor Criswell), or that all three articles should have a proper reference on the statement that talks about Eleanor Criswell from which readers can conclude it is the same Eleanor Criswell. We don't need WikiData for that (especially since we know that there is so much unreliable data on WikiData, that I would not be surprised that the WikiData Eleanor Criswell could very well be a mix of several persons with that name). --Dirk Beetstra ^{T C} 10:28, 16 January 2018 (UTC) (screwed up ping. --Dirk Beetstra ^{T C} 10:29, 16 January 2018 (UTC))
  • Created Eleanor Criswell and Eleanor Criswell Hanna as redirects to Saybrook University, where this person is now mentioned in the lead as founder of the university. Note that the Wikidata item of that university (Wikidata:Q7429134) links to the Wikidata item about this person. --Francis Schonken (talk) 10:56, 16 January 2018 (UTC)
• Comment I've made a proposal below to use the information in Wikidata without sending our readers there. I'd want to ask editors supporting the removal of links what they think about this alternate proposal. Diego (talk) 10:44, 16 January 2018 (UTC)
• Oppose Though I think the link should be in some way distinguishable from a standard wikilink. We're sending readers to a totally different looking page and that's pretty confusing; most readers will have never heard of Wikidata. A small icon or something that could flag this as a link that leaves Wikipedia would be a solution. As is often the case with Wikidata discussions on Wikipedia, 'dont use it at all ever' just isn't a convincing argument for me here. Sam Walton (talk) 12:40, 16 January 2018 (UTC)

Discussion (linking to Wikidata RfC)

What I would like to comment about here is the statement (actually, several statements) in the above section that Wikidata is universally not useful except possibly for interlanguage links. May I please remind the community that we had (and still have) a severe problem that our information quickly gets outdated. If (a random example) a mayor of Diyarbakır gets reelected (the example is so random, that I did not even look up whether they have a mayor and whether this is an elected post), the information about a new mayor is unlikely to propagate to the English Wikipedia any time soon. It can be propagated first to the Turkish Wikipedia (which is understaffed due to the Wikipedia ban in Turkey), and then someone may be so nice and come here to update the article - or may not, depending on whether they speak English and feel comfortable to edit the English Wikipedia, whether they had enough coffee in the morning, and whether they have promised their girlfriend to go to a movie tonight. Indeed, I am currently going through articles on Ukrainian localities and occasionally remove information about their mayors which someone added there 10 years ago and never cared to update. In the pre-2012 era it was actually recognized as a problem and there were some discussions on how to handle this problem - not so many, because who cares about mayors of cities outside English-speaking world. One example I remember was the project organized by WereSpielChequers with the goal to follow whether a person is designated as living on some projects and as dead on other projects. At the time I thought this was a brilliant idea. It worked by using a bot which was checking info on different language versions on Wikipedia and made project-specific lists. It was fully superseded by Wikidata (which is, at the end of the day, still more reliable than just a collection of data from different language versions on Wikipedia), and, as far as I understand, stopped working. One (not the only one, but I would dare say the main one) idea of the early Wikidata was to host all this information centrally, so that updates do not take ages to propagate from one project to each other and get stuck there, possibly without sources. Now, whoever votes above "never use Wikidata", basically undersigns that they failed to accomplish this task. The task does not necessarily have to be accomplished by direct import of data via templates (and at this stage I would discourage the direct import because of the vandalism issues), but it can be dome differently, for example by using bots and creating lists off the main space. But by voting "never use" you guys send the project - not Wikidata, but the English Wikipedia - back to the middle of the 2000s. (For the record, I do not think there are many advantages in using Wikidata in the case from which this RfC started - the Wikidata entries about mayors may have useful info such as for example DOB reliably sourced to databases, but indeed nobody cares, since they are not notable for Wikipedia, and Google gets the same results faster; if they are notable, I agree it should be a redlink).--Ymblanter (talk) 07:50, 16 January 2018 (UTC)

Courtesy @WereSpielChequers:, the ping failed the first time.--Ymblanter (talk) 07:52, 16 January 2018 (UTC)

I do agree to the sentiment expressed here - but thinking in real BLP-level situations: what if a living person's data here is extracted from WikiData, and someone is changing the WD data it results in BLP violations here; I can block someone from changing data here but I can't block someone on WikiData from changing data here. Then there are cases of incongruent data (the way that WD is displaying data is not how we want to display it, or the data can be displayed in multiple ways while all being correct - http://example.org; https://example.org; http://www.example.org .. all correct, all different - try to get that 'aligned' with a local choice, while other wikis chose another option), or data that we cannot display but comes in through the WD-backdoor (blacklisted external links are one example of that).

If the WD's own policies are not violated, then there is nothing that we can do to not have our policies (or even global decisions) violated except for breaking the link with that WikiData item (which, at some point, becomes impossible to maintain). --Dirk Beetstra ^{T C} 08:08, 16 January 2018 (UTC)

If you want my personal opinion, we should have bot transfer and a system similar to pending changes (or may be even incorporate it into pending changes). Such edits typically need reliable sourcing anyway, which can seldom be recovered from Wikidata.--Ymblanter (talk) 08:12, 16 January 2018 (UTC)

May be I should expand on this a bit. The main problem of Wikidata is that it is understaffed, and I do not expect this to change any time soon. I do not expect Wikipedia editors to start editing Wikidata on a regular basis, even if the interface becomes very simple (which is kind of what we are close to). On the other hand, this is a real problem which needs to be solved. IMO the only way in principle to solve it is to shift it to the projects whereas kiiping at the same time Wikidata as a central repository of information. Bots are probably the easiest way to do it, though I am pretty open to other workable solutions.--Ymblanter (talk) 08:20, 16 January 2018 (UTC)

Btw I can block someone for vandalism on Wikidata (and do). If you see instances, especially coming from registered users, which require administrative intervention, pls let me know.--Ymblanter (talk) 08:13, 16 January 2018 (UTC)

That is great .. but just a small fraction of the problem (though in case of BLPs and banning cases a rather big problem - though I doubt you can block an editor on WikiData who is blocked here just because he is blocked here for making such changes). You can not solve the dissimilarity problem (except through big hacks in every single wiki's translusion template for each parameter that would suffer that problem, or defining the same parameter on WikiData 800+ times (once for each Wiki)), nor the problem that WikiData can have data that we transclude here that here gives problems (e.g. solve this: blacklist an url here, then add it to WikiData so that it transcludes here and then try to edit a page that transcludes the data here ..).

Regarding sending Wikipedia back to the middle of the 2000s .. that would not have happened if editors would not have been so eager to delete the data here after having it on WikiData - then breaking the link would not have resulted in loss of data here (except that we don't display the data anymore that was since added to WikiData .. which actually we never had here anyway). --Dirk Beetstra ^{T C} 08:51, 16 January 2018 (UTC)

I do not know - in the example with Shrivallabh Vyas the original vandalism was on the Wikipedia side [19], and if the guy were still alive, we would return to the same vandalized article now. In any case, all this information can be imported back to Wikipedia overnight, I just do not see any point in doing this. We can outline complex templates as well and go back to 2003 - but would anyone benefit from this?--Ymblanter (talk) 09:10, 16 January 2018 (UTC)

Short answer: yes. Except for a couple of things (interwikis), most data on WikiData is similarly incorrect as here, and as I and Fram outline, there is data on WikiData that we decided already not to use (but which is difficult to filter out - is WD's date-of-death referenced to a NYT obituary: transclude - is WD's date-of-death referenced to Find-a-Grave: do not transclude). Is http://www.example.org the same as what WD mentions to be https://www.example.org?). Go on and on. And all local editors have to find a solution, while it is so easy: can I find a reliable source for the date-of-death: no - don't edit, yes: write it and reference it. Someone adds a date-of-death with a Find-a-grave reference: revert (or better, check and use a proper reference if available), now I have to jump through hoops to see whether the date-of-death is properly referenced on WikiData (and as it is referenced, we will display it). Can you see how easy it is to vandalise en.wikipedia? And I haven't even started about those excessively high-speed bots that are running on WikiData that could wreak havoc on thousands and thousands of pages on 800+ wikis in a short time if they would have an undetected bug. --Dirk Beetstra ^{T C} 09:25, 16 January 2018 (UTC)

I do not see how it contradicts to the soultion I proposed. One possible implementation (not the only one and possibly even not the best one): Take a bot; let it find an article which has no date of death, whereas the Wikidata item has; if Wikidata item is unsourced or sourced to Wikipedia -> make a bot leave a message at the talk page; no infobox -> make a bot leave a message at the talk page; if the Wikidata item is sourced and there is an infobox in the Wikipedia article -> have a bot edit the infobox and mark the edit as needed a human attention (via pending changes or differently, needs to be figured out) -> a human comes and sees whether this is NYT of Find a grave -> a human edits the article, everybody is happy.--Ymblanter (talk) 09:32, 16 January 2018 (UTC)

'Take a bot; let it find an article which has no date of death, whereas the Wikidata item has; if Wikidata item is unsourced or sourced to Wikipedia -> make a bot leave a message at the talk page; no infobox -> make a bot leave a message at the talk page; if the Wikidata item is sourced and there is an infobox in the Wikipedia article -> have a bot edit the infobox and mark the edit as needed a human attention (via pending changes or differently, needs to be figured out) -> a human comes and sees whether this is NYT of Find a grave -> a human edits the article, everybody is happy.' .. or just have a tracking category with 'hey, there is a WD item but no local data .. ' and have a human editor coming and add it here. 'have a bot edit the infobox and mark the edit as needed a human attention (via pending changes or differently, needs to be figured out)' .. so yes, whether through transclusion or through a bot, you still want to run the risk of transcluding BLP violations ...

Your example of Shrivallabh Vyas is nice .. say I vandalise a page here, my vandalism gets transported to WikiData and then transcluded on 800+ other wikis, here my vandalism is wiped, but because we are transcluding WikiData data, it gets back-transcluded until we also wiped the WikiData entries (and in the meantime, on 800+ other wikis N00bs might want to edit the data themselves because something wrong is transcluded). I am getting a headache. --Dirk Beetstra ^{T C} 09:40, 16 January 2018 (UTC)

Another solution might be: make sure that the WikiData data is of such a level that we can trust it. But that is not the quality control that WikiData has, worse, it is demonstrating to bot-import notoriously unreliable sources or plain spam. --Dirk Beetstra ^{T C} 09:47, 16 January 2018 (UTC)

Realistically, it is not going to happen without engagement of a much larger set of users than current Wikidata users, and they are obviously not going to be angaged if Wikidata is banned here. This is not a solution.--Ymblanter (talk) 09:57, 16 January 2018 (UTC)

(EC)Well there is the point. ENWP requires information that is compatible with its policies. Until Wikidata can provide that, its of minimal usefulness. I doubt anyone seriously expects that to happen anytime soon as I don't see a horde of wikidata users waiting to leap into action to tidy up its unsourced/badly sourced/non compliant info, so yes, there is no solution other than to not use Wikidata for almost all purposes. Only in death does duty end (talk) 10:17, 16 January 2018 (UTC)

Well, the notion that Wikidata is a service provider and Wikipedia is a customer is just entirely wrong. Wikidata is the data repository, and Wikipedia is not the only user of this data, and I believe not even the biggest user. Everybody uses data in different ways. It is up to the user to decide which data is acceptable and which is not. The data selection must happen on the Wikipedia side. It will never happen on the Wikidata side; it is perfectly acceptable in Wikidata (and will always be acceptable) to have different (contradicting) data cited to different sources. And actually Wikipedia users do select the information. Now it just happens via the Google search. If anybody thinks that Google is more reliable than Wikidata - fine, but this is just short-sightedness. You guys just believe that someone needs to bring you data and ask you to accept it - and when it does not happen, you are pointed out to a repository and get asked to select data yourself, you get upset and say that the repository is evil. Do you know Wikipedia is unreliable? Yes, sure. Is this morally wrong to cite data referenced to Wikipedia? I guess not. Do you expect this data to magically become reliable because it is not on Wikipedia anymore but on Wikidata? No, I guess not. Just do not use it. Use smth which is reliably sourced, and ideally check the source before using it.--Ymblanter (talk) 10:26, 16 January 2018 (UTC)

Yet another point to made. Exactly. And I think it is time that this customer decides not to use the data. --Dirk Beetstra ^{T C} 10:32, 16 January 2018 (UTC)

This is ok. Use Google if you think it is better. It sure never gets vandalized and always reports reliable information.--Ymblanter (talk) 10:34, 16 January 2018 (UTC)

No, but as I said just below, if I have the choice between going to WikiData and then having to use google to check whether WikiData is correct, or I have to use Google directly, then I chose the latter. --Dirk Beetstra ^{T C} 10:41, 16 January 2018 (UTC)

You are a physicist, right? You should know then that finding a solution and checking the validity of an existing solution ate two completely different things, of quite some different degree of complexity and necessary computational effort.--Ymblanter (talk) 10:45, 16 January 2018 (UTC)

Chemist, to be precise. I know, but I am also aware how a wrong DOE can completely go wrong. And I am sorry to say, but I am afraid that WikiData took the wrong approach - if they would have started to serve the Wikimedia community by serving them properly they would have engaged Wikipedians to supply more reliable data. And with that reliable data they would automatically have started to serve the community outside of Wikimedia as well. It is now such an entangled mess that it is hard to use for the Wikimedia community, and anyone outside of that. --Dirk Beetstra ^{T C} 10:56, 16 January 2018 (UTC)

(ec) I actually do agree that Wikidata from the beginning should have concentrated more on importing data from databases and less on importing data from Wikipedia, and only sort out these issues later. However, I do not think it is inherently wrong to store there data imported from Wikipedia. They should just not be reimported back here, and it is not actually difficult to prohibit such import for example at the template level, but of course nobody would do this if the template is likely to be attacked by a member of an anti-Wikidata brigade, with all this work destroyed overnight. Definitely, if one views Wikidata just as an extension of the English Wikipedia, which must deliver data in exactly the same format and which would conform with exactly the same policies (changing as well when policies change) as the English Wikipedia, then it is not reasonable to have it as a separate project, it should be just part of the English Wikipedia. Concerning more engagement, I disagree, there was no additional engagement on Commons (which is understaffed as well and would seriously benefit from an influx of more constructively-minded and less trigger-happy users) even despite the fact that the Commons requirements are stricter than the Wikipedia requirements.--Ymblanter (talk) 11:11, 16 January 2018 (UTC)

On the contrary, Wikipedia is the customer, and Wikidata is the service provider. The service they wish to provide is a data repository of content factoids to be used on all projects. Much like commons is a media repository. As the service provider wikidata needs to comply with our, the customer's, requirements. Until it does so, we can choose not to use its services. That wikidata editors do not understand that wikidata exists to serve the other projects is not our problem. Only in death does duty end (talk) 11:01, 16 January 2018 (UTC)

I am afraid you completely misunderstand what Wikidata actually is.--Ymblanter (talk) 11:12, 16 January 2018 (UTC)

From the front page of WikiData: "WikiData acts as central storage for the structured data of its Wikimedia sister projects including Wikipedia, Wikivoyage, Wikisource, and others." That is all completely true. As such, the data should all flow in the direction of WikiData, and not necessarily the other way. And I would argue, lets just have it flow that way, and not back - I am sorry, but it simply doesn't work, the data cannot be reliably used, even for simple, non-sensitive data. We've tried, we failed. --Dirk Beetstra ^{T C} 11:27, 16 January 2018 (UTC)

I see indeed that you argue this way. I just disagree with this vision and find it extremely short-sighted.--Ymblanter (talk) 12:41, 16 January 2018 (UTC)

Well you need to tell your fellow wikidata editors to stop attempting to use it that way. As it stands (as Beetstra above quotes) wikidata is a central data repository - the intent of which is that data is used on Wikimedia projects. I cant put it any simpler to you, you clearly don't even understand the scope of your own pet project. Only in death does duty end (talk) 11:34, 16 January 2018 (UTC)

Well, sure, you are not active on Wikidata, you are way less active than me have on the English Wikipedia, but you understand better than me and also better than everybody else how it should work, and you are sure what you say would be taken seriously. Fine, I can survive this.--Ymblanter (talk) 12:39, 16 January 2018 (UTC)

Much like your response to Fram this is another example of your 'NA NA NA CANT HEAR YOU' bullshit when you hear something you don't like and cant refute. Perhaps you over-estimate how seriously you are taken. Saying 'that's not wikidata's purpose' when it is both the stated purpose (as a central data repository), and the purpose its currently (being attempted by wikidata editors) to be used for on ENWP (drawing information from Wikidata for use in articles) is either extreme ignorance or flat-out falsehood. Only in death does duty end (talk) 13:25, 16 January 2018 (UTC)

Well, both communities felt confident enough to award me administrator privileges, something which I have not seen you to achieve with either of them. But, as I said, you are certainly entitled to have your opinion on the subject, even if it is completely uninformed and aggressive. This is ok with me. I am not even going to report you for a personal attacks. But I hope you will excuse me if I stop spending my time replying you.--Ymblanter (talk) 13:33, 16 January 2018 (UTC)

I agree, they are obviously not engaged if WikiData is banned here, they are now also not engaged because of the massive problems that WikiData has because of the way that they started to collect data (import, import, import .. import ..). If all Wikipedia editors with some remote interest in the data would all walk over to WikiData to get it all correct (which is now a gargantuan task) we would not be editing Wikipedia anymore, and because of the mess WikiData is people would not get engaged there to get it correct. WikiData would have engaged many more editors if they would have put quality first, now people don't get engaged because of the lack of quality, and because of the task at hand to get it up to scratch. And in the meantime you expect, with the current policies of importing WikiData has, to just take it because it is the best you can do? 'Format C:'/'are you sure?'/'yes', and start over .... --Dirk Beetstra ^{T C} 10:13, 16 January 2018 (UTC)

See my response above. Right now you are using Google, and nobody suggests to ban Google. You just have wrong expectations from Wikidata. What you want will never happen.--Ymblanter (talk) 10:28, 16 January 2018 (UTC)

I know that it is not going to happen .. Jimmy Wales sending me 1 million dollar is not going to happen either. I will just have to live with it. And if I have the choice between checking with Google to see whether WikiData is correct, and if it is not using Google to get the correct data, or skip WikiData and just get the correct data from Google directly, then I choose the latter option. WikiData has its place in this world, but no place on en.wikipedia. --Dirk Beetstra ^{T C} 10:39, 16 January 2018 (UTC)

"in the example with Shrivallabh Vyas the original vandalism was on the Wikipedia side [20], and if the guy were still alive, we would return to the same vandalized article now." The vandalism was here first, true, but it was corrected here as well before the removal of Persondata happened.[21] Neither that correction from 2016 nor the addition of the correct date of death this month were done at Wikidata, which still showed the original error or vandalism from enwiki (which was never visible to readers here in the first place). Fram (talk) 09:48, 16 January 2018 (UTC)

Agreed, that BLP data is not transcluded (unless by choice, we have special templates for living people that can completely rely on WikiData data), but twitter feeds are. It is just a matter of finding one that is not on WikiData, transclude some vague account here, wait for WikiData to take my value (that is why we have WikiData-only maintenance categories like Category:Twitter username_not_in_Wikidata, right, to tell WikiData that they can take our data? I still fail to see how that maintenance template is improving en.wikipedia, we have the data ..), and then wipe the data here. It is good we are more careful with BLP data, but we transclude a lot from WikiData. --Dirk Beetstra ^{T C} 10:22, 16 January 2018 (UTC)

There is no evidence that in general, Wikidata is more up-to-date or correct than e.g. enwiki. Shrivallabh Vyas died on 7 January 2018, as correctly noted and sourced in enwiki. According to Wikidata[22] he was dead since 2011, which was sourced to "imported from English Wikipedia" in July 2014. Which is weird because at the time the enwiki article[23] said (correctly) that he was alive. So Wikidata is not simply outdated, but filled with false information, referenced to an unreliable source, which didn't even have that information at the time. Saying "never use Wikidata" is not "send the project - not Wikidata, but the English Wikipedia - beck to the middle of the 2000s." but protect the project from using a generally inferior, unreliable source. Fram (talk) 08:20, 16 January 2018 (UTC)

To make it clear, I am not going to respond to any arguments provided by Fram, since in my experience this is a loss of time. Other people may try if they want.--Ymblanter (talk) 08:22, 16 January 2018 (UTC)

"My claims are rubbish, so I'll try a personal attack instead". If you can't stand criticism of your hyperbolic claims and don't know how to react when it is shown that even the imports from enwiki by Reinheitsgebot (10,947,043 edits at Wikidata!) can't be trusted, then just don't participate in these kind of discussions, it would be even less lost time for all of us. Fram (talk) 08:36, 16 January 2018 (UTC)

• Respectfully, yes, I do think that Wikidata fails at the task it's intended to perform. From what I have seen it is cluttered with empty, out of date, or simply erroneous entries. There's enough of that on this site already, and it is no solution to delegate responsibility for it onto another. That doesn't solve the problem, it just makes the problem present in two locations instead of one. Reyk _YO! 08:38, 16 January 2018 (UTC)

My point was actually that Wikipedia (specifically, the English Wikipedia) fails to perform the task - to solve the problem I outlined.--Ymblanter (talk) 08:51, 16 January 2018 (UTC)

Is a lot of data on enwiki outdated? Yes. Does Wikidata solve this problem? No. Correctly identifying a problem doesn't make your solution automatically correct. Wikidata may be an improvement for small, rarely edited wikis (and certainly for those wikis which are largely bot-populated in the first place, like Cebuano or some invented languages). No one here is arguing to abolish Wikidata or to restrict how other wikis may use it. But enwiki, with all its problems, generally is more up-to-date and reliable than Wikidata is (for starters, we don't accept wikis or findagrave as sources, while Wikidata explicitly supports bot importing such sites as references), so replacing our data with data from Wikidata is in general a bad idea (and yes, you can find counterexamples). Using bots on enwiki to import selected, vetted, well-sourced series of data from Wikidata may be useful in some cases, and bots providing in projectspace lists of articles where e.g. the date of birth or the date of death mismatches between enwiki and Wikidata is something few people would object to. But none of this means that not using Wikidata live in articles is throwing enwiki back in time, it means that people look at the actual situation, not the ideal one, and realise that Wikidata is not (yet?) an improvement. Fram (talk) 09:05, 16 January 2018 (UTC)

• @YMBlanter thanks for the plug for the death anomaly project. Yes I designed it and it did identify a lot of anomalies between wikipedia language versions. A large group of us across about 11 languages then fixed those we could across many many language versions of Wikipedia. It didn't stop because Wikidata superseded it, it stopped because our bot writer retired. If someone is interested in writing a new bot for it please get in touch, it might be easier to code now that we have Wikidata. What I'm not sure of is whether Wikidata has equivalent volunteers using it to identify and list anomalies such as "people who are alive according to one language version of Wikipedia but not according to another". Call me overly cautious, but I'd prefer a data integration project that had such anomaly finding at its core. You would still find cultural anomalies because, for example, different language versions of Wikipedia have made different decisions as to how old someone needs to be before you assume they are dead; and more embarrassingly, if we have two unsourced bios for the same mid twentieth century sportsperson one describing the person as dead and the other as living, it is tricky to resolve if you can't find a source in a language you know. But I for one would be more comfortable with Wikidata at this stage if it led on anomaly finding rather than populating infoboxes. ϢereSpielChequers 12:40, 16 January 2018 (UTC)

I think there are a lot of pages of a similar intent on Wikidata (I am not immediately sure though whether there is one specifically on death anomaly - @Pasleim: probably knows everything about it, but even if there is not one, it can be I guess easily written. The problem is then more on the projects' sides - who is going to use this bot-generated lists to actually use it and how this information would propagate to the projects.--Ymblanter (talk) 12:46, 16 January 2018 (UTC)

Using Wikidata to identify entities unambiguously

In the discussion above I've proposed using the knowledge that some entity (person, building, art work...) has a Wikidata entry and keeping that information withing our article when relevant, not as a link to that entry, but as metadata for the entity as described in our article. I want to ask those editors supporting a ban of links to Wikidata what do they think about this proposal. Such metadata could take the form of a template that creates no visible link, but that is visible when editing the article - and maybe in a Special page or at Page information.

The idea would be to unambiguously identify topics of discussion which are not notable enough to have a Wikipedia article, but that are nevertheless verifiably identified as an existing entity that has a unique identifier at Wikidata. Adopting this practice throughout the project would provide invaluable to automated and semi-automated tools for processing articles, and could help research projects to better analyze the knowledge contained in our encyclopedia.

Note that the only information in Wikidata that we would be using by this approach is the existence of the entity registered, not any of the properties stored there. We are already doing this for topics that have a Wikipedia article; and we have parameters in the infoboxes templates that allow us to specify fine-grained usage of information in those topics, or avoid using them when we don't trust them. Diego (talk) 10:43, 16 January 2018 (UTC)

@Diego Moya: But how sure are you that all the data collected for WikiData-personality Donald Trump is talking about ONE physical incarnation of Donald? The way WikiData is sometimes importing data I would not be surprised that they could very well have imported data from Donald Trump (yes, I know, a Google search can also here on Wikipedia result in information being included about another Donald). And with a less notable personality (especially the ones which do not pass our bars) the risk of confusing the data is only bigger. --Dirk Beetstra ^{T C} 10:50, 16 January 2018 (UTC)

(edit conflict) The editor adding the template should make sure that d:Q22686 correspond to the entity[humang being] that has property[45th President of the United States of America], of course. That responsibility would belong to a Wikipedia editor, not a Wikidata one. It's no different than adding an internal wikilink to an article; the editor should make sure that the target topic is the same one being described at the origin article. This would allow us to increase this hyper-linking to entities that are not notable. Diego (talk) 10:56, 16 January 2018 (UTC)

@Diego Moya: but that is in core the same problem as discussed above. When transcluding an official website from WikiData you have to make sure that it is actually the one of the subject here. But we can do the same thing without WikiData. We now link to a redlinked person, and if we know that there are two distinctly different we make sure we disambiguate. With WikiData you just add a layer of complexity to that. --Dirk Beetstra ^{T C} 11:01, 16 January 2018 (UTC)

We seldom disambiguate redlinks, and that wouldn't work accross the interwikies for items that have different names in different languages. The idea would be to use an unambiguous identifier (the bit that is provided by Wikidata and not redlinks), and make sure that all our articles in all language 'pedias point consistently to the same ID when they refer to the same object. A good place to do this is at WP:CSC items that have been included in a list because they fail the notability criteria or short, complete lists of every item that is verifiably a member of the group - precisely the case in the example provided in the discussion. Also, aren't redlinks only for entities that we deem likely to be notable at some point? Diego (talk) 11:06, 16 January 2018 (UTC)

And we don't disambiguate those because we don't care whether non-notable subject A is the same or not as other non-notable subject A or that they are the same non-notable 'subject A'. But it is a function of WikiData, having two 'subject A's who are disambiguated by identifiers. But until WikiData IS that reliable database that does that, we should not use it on Wikipedia, as the unreliability of WikiData data may very well mix 2 'subject A's, or split one 'subject A' into two persons, or display very wrong information on the correct 'subject A'. --Dirk Beetstra ^{T C} 11:33, 16 January 2018 (UTC)

Have you just said that we don't care about the items described within our own articles if they happen to be not notable? Note that the reliability would be provided by us using the same identifier consistently in several of our articles; not by looking at what's stored at Wikidata for that identifier. We'd be using Wikidata only as a placeholder to make sure that we're not needlessly replicating identifiers. This could benefit both projects, I see it as Win-Win. Diego (talk) 11:41, 16 January 2018 (UTC)

No, we use references to make the statements about the person reliable. Whether the John Doe in article A is the same or different from the John Doe in article B is from a greater perspective not important until they link to the same article. WikiData is the central repository of data, en.wikipedia is, per pillar, not. --Dirk Beetstra ^{T C} 11:47, 16 January 2018 (UTC)

And I do agree, it would be great to be able to disambiguate those two John Does .. but again, if they are both non-notable on en.wikipedia grounds, then how I am to expect that WikiData is capable to properly deconvolute the data between those two John Does .. they will each link to two different WikiData IDs and have no data to identify them properly with sufficient reliable data. At best you know that one is from here, and the other from there (if it is not accidently the same person who moved inbetween). There will be John Does out there that cannot be sufficiently distinguished. It may be what WikiData aspires to do, but I would not keep up the hope that Wikipedia will at some point turn into a more reliable source based on such assumed data. --Dirk Beetstra ^{T C} 11:56, 16 January 2018 (UTC)

(edit conflict)The way I read WP:Build the web, registering that John Doe is the same in articles A and B is important "to enable readers to access relevant information on other pages easily" and "deepen their understanding of a topic by conveniently accessing other articles", which can't be done if we don't have the information to begin with. We do that with wikilinks to articles for items that are notable, and wikilinks to sections for items that are discribed within a larger article. I don't see why the same principle couldn't be extended as well to items that are described within our articles but don't have whole sections of their own; this information would allow us to reliably "find all articles where John Doe (Q1234567) is mentioned", or know that the Eleanor Criswell at Saybrook University is the same one listed as the spouse of Pernell Roberts. (^{, by the way}).

P.S. Again, this information would be added only for items that we can reliably identify as being the same according to our reliable sources; not according to what is stored in Wikidata. Diego (talk) 12:08, 16 January 2018 (UTC)

Creates a lot of extra clutter in the wikicode for very little actual benefit. We had things like persondata for years because of similar claims of this being invaluable metadata, but apart from then being mass-imported to Wikidata it was in the end a massive effort to have it all, and very little was actually done with it. Fram (talk) 10:54, 16 January 2018 (UTC)

And there won't be much use in the future either, if every time we propose a way to use the data, it is summarily rejected ;-)

Apparently these organizations are using Wikidata identifiers to unambiguously identify entities. Diego (talk) 11:11, 16 January 2018 (UTC)

Good for them (or not, but anyway that's up to them). But that's not really what we are discussing, what you propose is adding metadata to specific bits of enwiki article text so some hypothetical organisation or person may use this data for whatever. While this is not impossible, it seems like a lot of clutter and effort for little result. There are countless problems and issues that need fixing on enwiki, and finding reliable references for our articles seems like a lot more necessary than tracking down which Wikidata item, if any, belongs with which bit of article text, and then adding this invisible link for the benefit of, well, not the readers, not the editors, but some nebulous hypotheticals specifically interested in subjects notable enough for Wikidata but not for enwiki. Fram (talk) 12:52, 16 January 2018 (UTC)

not the editors says you. I've quoted the part of our current guideline that explains precisely how this may benefit our readers, given the right tools for navigation (just not a plain link to Wikidata). People supporting a ban on this should explain why this potential benefit is to be forbiden universally. Diego (talk) 12:59, 16 January 2018 (UTC)

I agree with Fram on this. The proven downsides in terms of reliability and maintainability far outweigh the claimed benefits. Reyk _YO! 13:00, 16 January 2018 (UTC)

Care to ellaborate? What are these proven downsides in terms of reliability and maintainability? Diego (talk) 13:02, 16 January 2018 (UTC)

You've quoted (have you? I don't see it) that guideline, but I don't see how it applies. To quote that guideline: "Ask yourself, "How likely is it that the reader will also want to read that other article?"" I simply don't see a potential benefit, and I see many problems. Main problem is that we send readers to a page which is not intended for readers. But for editors as well, we send people to a page at an unreliable wiki as if it is a good resource to use. We wouldn't allow such links to findagrave or ancestry to be placed in article text next to names, so why would we allow or encourage such links to Wikidata? I'm not a fan of such links to Wikipedia articles in other languages either for that matter, but it's not because those are allowed for the moment that we should accept the same for links to a site with a different purpose, policies, structure, ... Adding such metadata around terms makes editing harder, as it is more visual clutter one has to ignore, avoid, maintain, ... And it encourages people to recreate articles, links, on Wikidata which we don't want here, and to add sources like findagrave which we don't want here; Wikidata is too often used as a way to avoid blocks, deletions, policies on enwiki. Fram (talk) 13:16, 16 January 2018 (UTC)

Interlanguage link template

We already have both established precedent, and a template, for links to Wikidata, albeit they should take a different form to that used in the example quoted above, by Koavf. That template is {{Interlanguage link}}, and for Wikidata it works like this - {{Interlanguage link|William Harold Bodine, Sr.|WD=Q45371935}} renders as William Harold Bodine, Sr.. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 16 January 2018 (UTC)

"Established precedent" is meaningless if this RfC decides otherwise. That we have a template is nice, but again hardly relevant if this RfC decides that such links are not welcome. Fram (talk) 12:33, 16 January 2018 (UTC)

Maybe, but as Andy said, this should be announced centrally for it to override the precedent. Diego (talk) 12:41, 16 January 2018 (UTC)

It is announced centrally now (not by me), and I don't think this requirement was valid anyway. An RfC on this page is not really an obscure location. The "precedent" is one or two users adding it to a template and starting to use it, not something that was centrally announced and decided either... Fram (talk) 12:46, 16 January 2018 (UTC)

The precedent to override is the WP:Sister projects guideline. Diego (talk) 12:51, 16 January 2018 (UTC)

I see that this was labeled a guideline by Whatamidoing in 2012, I can't find any discussion to establish whether this really was and is a generally accepted guideline or not (but I may well have missed said discussion). The blanket statements in that page about inline links to sisterprojects seem not to match generally accepted practices. Considering how even for search results, there were sister projects we explicitly rejected (i.e. sister projects which are not allowed by enwiki to be shown i na search here), I doubt the community at large would be happy with the promotion of inline links to such projects. Anyway, central notice was asked for, central notice has been provided, so whether the precedent is a valid guideline or not is not really an issue, this RfC can decide what to do with this specific issue. Fram (talk) 13:01, 16 January 2018 (UTC)

I'd also like to see the discussion to promote this to a guideline. If it's been just kind of snuck in without anyone noticing, that would be reason enough to revisit which of these sister projects we should really be linking to. Reyk _YO! 13:10, 16 January 2018 (UTC)

@WhatamIdoing:--Ymblanter (talk) 13:12, 16 January 2018 (UTC)

That would be a misuse of the template since there are no other language articles as far as I can see (if there were, we would interlanguage link directly unless there were multiple ones), and by both EL and sister projects we wouldn't link to a page with no information. Only in death does duty end (talk) 13:30, 16 January 2018 (UTC)