Wikipedia talk:Manual of Style/Archive 204 - Biblioteka.sk

Upozornenie: Prezeranie týchto stránok je určené len pre návštevníkov nad 18 rokov!
Zásady ochrany osobných údajov.
Používaním tohto webu súhlasíte s uchovávaním cookies, ktoré slúžia na poskytovanie služieb, nastavenie reklám a analýzu návštevnosti. OK, súhlasím


Panta Rhei Doprava Zadarmo
...
...


A | B | C | D | E | F | G | H | CH | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Wikipedia talk:Manual of Style/Archive 204
 ...
Archive 200 Archive 202 Archive 203 Archive 204 Archive 205 Archive 206 Archive 210

Idiosyncratic styling

At Manchester Small-Scale Experimental Machine and other articles, User:Eric Corbett has styling the reference sections in a novel way using Template:style-nt that he created recently, to give himself control over text point size, whether or not an edit button appears by the headings, whether they show up in the TOC or not, and what-all. The coding looks cryptic, and it's hard to discern any good reason for not going with the usual default style that one gets with normal section and subsection heading markup. He keeps putting it back, with little justification; see User talk:Eric Corbett#What does Template:style-nt do?. Does the MOS have anything to say about editors going their own way on such styling? Dicklyon (talk) 04:28, 7 May 2018 (UTC)

What does it do? What's the point of writing documentation if nobody reads it? Eric Corbett 04:55, 7 May 2018 (UTC)
This template should probably be submitted to WP:TFD. The headings are the way they are and users really shouldn't be trying to Make Their Pages Perfect With Respect To Their Preferences. There is also a bit of false documentation regarding whether bold headings are allowed by MOS--they aren't. --Izno (talk) 05:15, 7 May 2018 (UTC)
That's not what the MoS says at all. What it explicitly discourages is the use of the semicolon as in ";pseudo-heading" to produce bold headings, not bold headings per se. And it strongly encourages the use of heading markup as in "===Real heading===" for accessibility reasons, which this template supports. But I'm interested in which part of the MoS you're using to justify your assertion that "users really shouldn't be trying to Make Their Pages Perfect". Do you have a link? Eric Corbett 06:45, 7 May 2018 (UTC)
Focusing on the template issue is really to miss the point. I could, for instance, achieve a similar result to the template by prefixing a normal section header with something like <div id="section-header" style="font-size:14px;"> and suffixing it with </div>, or I could even override the default look of a level 3 header - or any other - by writing a new CSS definition. What would the MoS have to say about that, and why should it care? Eric Corbett 07:12, 7 May 2018 (UTC)
Yes, you could do that, and it would likely get reverted (I see you've made a pointy edit to that effect at already). The use of the template is more insidious, as the naive editor will see it and just think it's some widely used way of making some consistent styling, rather than your personal idiosyncratic way of styling, which is what it really is. Can't we all just use a consistent style? Aren't you a software engineer? Have you not bought in to the advantages of coding with a shared and understood style guide? Dicklyon (talk) 14:23, 7 May 2018 (UTC)
Why would it get reverted? In what way does it go against the guidance in the MoS? Of course we could all use a visually consistent style, this one for instance, which is more aesthetically pleasing than the default site-wide css for level 3 headers. Is it necessary to point out that the purpose of such css definitions is so that they can be overridden? And it's rather insulting to call my demonstration, clearly labelled as such, as pointy, but insulting behaviour appears to be your forte. One final thing: inconsistency in other areas of the MoS is actively encouraged, date formatting and spelling are two obvious examples. Is your next campaign going to be to force a single date format down everyone's throats? Eric Corbett 14:35, 7 May 2018 (UTC)
That sounds uncomfortable. Dicklyon (talk) 14:46, 7 May 2018 (UTC)
To address the broader question: MoS is a guideline primarily about the most common WP-writing "style" (spelling, grammar, tone, layout, etc.) questions and problems. It is not the One True Source of all common sense and consensus on Wikipedia, the general operating principle of which is that what has been working fine for a long time and is well-accepted by the community is the consensus, even if it was not established in a particular discussion. If someone changes something about that de facto consensus, and the change is met with little or no objection then widely adopted by others, it becomes part of the new consensus. Otherwise, we'd have to have millions more consensus discussions and a huge database to keep track of them, a project that might exceed the scope fo WP's actual public-facing content. "MoS doesn't have a rule stopping me" doesn't equate to "I can do anything I want". Otherwise MoS would have to be longer than The Chicago Manual of Style combined with New Hart's Rules, to account for every imaginable style idea. PS: I have no objection at all to adding an explicit MoS rule against using CSS tricks (manual or templated) to alter the default formatting of headings and other page elements, except inline CSS within a heading to make it conform to a particular MoS expectation. There may be some other already-accepted tweaks of this nature, such as ToC template options to suppress display of level-3 and lower headings in some cases when necessary to prevent excessively long tables of contents. If there's something wrong with how elements like the headings work on Wikipedia, and it can be addressed in CSS, then the idea should be proposed at Mediawiki talk:Common.css for inclusion in the site-wide stylesheet. If it's a sweeping change, it should probably be proposed at WP:VPTECH first.  — SMcCandlish ¢ 😼  00:45, 8 May 2018 (UTC)
One more question: what does the name style-nt mean? nt for "next thing" maybe? Dicklyon (talk) 14:24, 7 May 2018 (UTC)
What does it matter? I would have preferred to call it simply {{style}}, but a template with that name already exists. Eric Corbett 14:40, 7 May 2018 (UTC)
So why not style-ec? It matters because the Template namespace is intended to be understandable and usable by editors; it's not your personal playground. Dicklyon (talk) 14:46, 7 May 2018 (UTC)
I've really done with discussing anything with you, anywhere. You're quite impossible to deal with. Eric Corbett 14:51, 7 May 2018 (UTC)
In what way? His point is correct and sensible, though what this template is named is the least of the concerns about it.  — SMcCandlish ¢ 😼  00:45, 8 May 2018 (UTC)
... you want to know…what it is?

A specimen, for delectation. I like gadgets, this is fun! Batternut (talk) 11:08, 7 May 2018 (UTC)

Apparently WP isn't meant to be fun. ;-) Eric Corbett 12:00, 7 May 2018 (UTC)
When misinterpreting WP as a CSS hacking playground and display case of Web-styling wizardry, that assessment is essentially correct. WP is meant to be an enjoyable environment in which to work on building an encyclopedia, but it's not even intended to be "fun" for readers, but simple and informative. It's not an entertainment website or a MMPORG, nor a place to flex one's Web coding skills in personally aesthetic ways. This is all covered at WP:NOT (#GAME, #WEBHOST, and some other sections).  — SMcCandlish ¢ 😼  00:45, 8 May 2018 (UTC)
  • See Wikipedia:Templates for discussion/Log/2018 May 7#Template:Style-nt Jc3s5h (talk) 13:16, 7 May 2018 (UTC)
    I was about to suggest TfD.  — SMcCandlish ¢ 😼  00:45, 8 May 2018 (UTC)
  • I don't think this really has anything to do with references, apart from the fact that the headings being formatted are in reference sections. The issue is using markup to change the way that section headings are formatted. The MOS does not cover this explicitly, but that's because it does not try to discuss every convention. In this case, there is a clear convention across the project not to try to change the font, size, weight, or other aspects of section titles. So editors should just leave that formatting as is, rather than trying to achieve some kind of special heading formatting in specific articles. I don't think this needs to be in the MOS, actually - 99.99% of editors seem to follow the convention without any trouble, so it's just a matter of fixing any uncommon articles that don't follow the convention. — Carl (CBM · talk) 15:18, 7 May 2018 (UTC)
    Agreed. This isn't about refs, but about consistency of standardized interface elements – or, rather, about unusual deviations from that consistency which don't seem to provide enough reader utility to cover the editorial cost of the divergence, or the cost to reader expectations in loss of consistency. There's a reason we don't do things like switch to a green background and a Celtic-y uncial font at articles about Ireland, and so on, despite the sense that "designer" types have that it would be fun and evocative to do so. WP is not a brochure, nor a Web-design experimentation platform. PS: Speaking of which, I'm strongly reminded of WP:TFD deleting quotation-stylization templates that attempted to mimic the blockquote styles of various blogging platforms.  — SMcCandlish ¢ 😼  00:45, 8 May 2018 (UTC); annotated further: 23:36, 18 May 2018 (UTC)
    More on this matter at User talk:J3Mrs/Archive 16#The H3 template where I was shot down for daring to question the purpose of what was, at the time, the {{h3}} template (I shall probably be shot down for bringing up the matter here, but I see it as germane to the topic). When I first saw this thread, I hadn't actually realised that {{style-nt}} had originated as {{h3}} which is why I've not commented here previously. --Redrose64 🌹 (talk) 07:26, 19 May 2018 (UTC)
  • Note: Multiple closely related templates&modules are being discussed at TFD Template:H4. Alsee (talk) 06:48, 24 May 2018 (UTC)

ndash vs hyphen vs slash in article titles

Advice is requested at Talk:Regional corporations and municipalities of Trinidad and Tobago#ndash vs hyphen in article titles. Shhhnotsoloud (talk) 07:26, 24 May 2018 (UTC)

Semi-protected edit request on 10 May 2018

In Wikipedia:Manual_of_Style#Celestial_bodies, it says sun, earth, and moon are not capitalized except in astronomical use. MOS:CELESTIALBODIES says the same exact thing except with solar system added. I am questioning whether solar system should be added to Wikipedia:Manual_of_Style#Celestial_bodies because the article title of the solar system on Wikipedia is capitalized while on other sites it is not. I can't think of other ways solar system is used outside of astronomical use. 2601:183:101:58D0:34E8:552C:3EB8:46BF (talk) 20:07, 10 May 2018 (UTC)

@2601:183:101:58D0:34E8:552C:3EB8:46BF: Umm ... you seem to be requesting that this page not be changed but rather MOSCELESTIALBODIES (which you could edit directly) be changed and the article Solar System be moved accordingly. For this reason, your edit request is unanswerable on its face. If I am misinterpreting you and you actually think this page should proscribe the use of "Solar System" ... well, that's not going to happen because you made an edit request on this page, unless there is also consensus to move the article. It should, however, be noted that there is not currently a contradiction between that article's title and MOS:CELESTIALBODIES; the article is about astronomy, and specifically our solar system (i.e., it's using it like a name rather than a common noun). That this page doesn't go into quite as much detail as the capitalization subpage should be a given. Hijiri 88 (やや) 01:43, 17 May 2018 (UTC)
I think (aside from the fact that one page contains extra detail, which is not necessarily an error) that the anon is misunderstanding. "I can think of other ways solar system is used outside of astronomical use" is an indication of this. If you say something like "There's a whole solar system of lobbyists orbiting around the senator", that's not something MoS (at either page) would have you capitalize, and this is not an oversight. Nor would it have you capitalize "the solar system of Alpha Centauri", for that matter. It means for you to capitalize our solar system when it is referred to as "the Solar System", a proper name. It the same as astronomical use of "the Sun" to refer to our star as a celestial body. But it's "She received a second-degree burn from extended sun exposure while unconscious in the desert". Here, it's a not a reference to the star, but a shortered version of "sunlight". If you were actually exposed to the Sun, literally, then you'd become plasma in under a nanosecond. Sun even in an astronomical sense isn't capitalized when it doesn't mean our sun as a celestial body: "the two suns of Tatooine" (celestial body, not ours); "Apollo was the sun god of the Romans" (our sun, not as celestial body in the literal sense, but as something the ancients didn't understand and deified); "My car gleams as bright as the sun" (our sun, not as a celestial body literally, but as a source of light we squint at, used in a figurative sense).  — SMcCandlish ¢ 😼  23:14, 18 May 2018 (UTC)

Closing duplicate threads: This has also been forum-shopped or at least talk-forked to Wikipedia talk:Manual of Style/Capital letters#Solar System capitalization (closed) and Talk:Solar System#Requested move 23 May 2018 (speedy closure requested).  — SMcCandlish ¢ 😼  23:11, 24 May 2018 (UTC)

Use of "founded" to describe in-name-only change of status of a municipal government?

The lead of our Katano, Osaka doesn't quite sit well with me. According to ja.wiki, the town of Katano was formally declared a "city" in 1971, but using "founded" brings to my mind an image of settlers venturing into the wilderness and establishing a new settlement. Our Takizawa, Iwate article describes a similar process with the word "promoted". There's also the problem of "new" municipal governments being established from mergers or dissolutions, which I also wouldn't think "founded" would accurately describe.

But this might all just be me and my hang-ups, so rather than changing it unilaterally (and I could almost certainly "get away with it") I figured I'd ask here. Thoughts?

Hijiri 88 (やや) 01:33, 17 May 2018 (UTC)

  • Reading the Japanese version, it sounds like that's when it went from being a -chō "town" to a -shi "city". The ja.wp version describes the -chō as being "市制前の名称" ("the name before municipal organization"?) I get the feeling that that's something like "incorporation". Curly "JFC" Turkey 🍁 ¡gobble! 01:45, 17 May 2018 (UTC)
No doubt - alternatives might be "achieved city status", "was declared a city" or something. Not founded if there was a pre-existing settlement. Johnbod (talk) 02:01, 17 May 2018 (UTC)
@Curly Turkey and Johnbod: What about cases like Ōshū, Iwate, which was apparently "created" in 2006 from two cities, two towns and a village that had existed before without any specific connection to each other? I'd still be averse to saying "founded" when describing municipalities that were created from mergers even when no city called "Ōshū" had existed before. (BTW, I'm pretty sure the name of the city is just as arbitrary as it sounds.) It may be hypothetical because that article currently uses "established", which I'm fine with, but I'm pretty sure there are a lot of places like this in Japan and maybe elsewhere (not Ireland, if I recall, and I don't know a lot about others). Hijiri 88 (やや) 07:07, 17 May 2018 (UTC)
"Merged" or "amalgamated" work—or "formed as a result of the amalgamation/merging of XXX and YYY". That was part of the whole 平成の大合併 about a decade-ish ago. Curly "JFC" Turkey 🍁 ¡gobble! 07:29, 17 May 2018 (UTC)
Yes - "founded" is really only appropriate for greenfield sites, or where there was just a little village. It's mainly appropriate for once-colonial places, or imperial whims. Johnbod (talk) 13:06, 17 May 2018 (UTC)
The term "incorporated" seems to be the more appropriate term, as far as I know, from municipal corporation. A city is incorporated rather than founded.--Jayron32 16:17, 18 May 2018 (UTC)
"Achieved" and "promoted" are PoV wording that presupposes that towns are worse, somehow, than cities. A neutral term would be "designated".  — SMcCandlish ¢ 😼  23:33, 18 May 2018 (UTC)
Towns are not worse, but lesser. Are majors "worse" than colonels? The term "incorporated" does not help when a town goes to a city. Johnbod (talk) 16:45, 20 May 2018 (UTC)
You're making my point for me, really. There is no hierarchical relationship between "city" and "town" (except perhaps within a particular municipality defined as a city and which has named its encompassed boroughs "towns" just to be a pain in the backside of collective understanding). If I live in the town of Apple Valley, California, the nearby cities of Victorville and Hesperia do not have jurisdiction over me (or control over my town's local government). If I serve under Major D'Lemma, and she answers to Colonel Korn, I also answer to Korn. They cases are not even remotely parallel. Anyway, the entire notion is still biased. Just read what you said: "Towns are ... lesser." This simply isn't a true statement categorically, only by particular rubrics that happen to interest you, such as perhaps the population level, the square mileage, or the tax monies in the coffer. By various other measures, cities are lesser. Some typical examples are quality-of-life and safety-related, including crime rates, suicide rates, frequency of deaths by fires and car wrecks, pollution levels, and many other things. Many towns also have longer and richer histories than many cities, with many of the latter being less than a century old, especially in difficult ecozones like Arizona that take significant modern technology to be support large human settlements.  — SMcCandlish ¢ 😼  22:47, 23 May 2018 (UTC)
I think you're making my point here - none of this matters in the slightest for the issue at hand. What about villages? They can be lovely too. So what? Johnbod (talk) 15:03, 24 May 2018 (UTC)
So, they aren't in a better/superior/commanding versus worse/lesser/subordinate hierarchy, in which wording like "achieved" and "promoted" might make sense. I thought that was pretty clear in my first post, especially since we have wording like "designated" that is accurate (the labels are an official designation, not a law of nature) and doesn't have this PoV problem, nor the reader confusion (hell, writer confusion) problem of "founded" or "established" being used for something that was actually founded/established long before the city designation.  — SMcCandlish ¢ 😼  23:19, 24 May 2018 (UTC)
This started off dealing with Japanese cities, now it is appearing to be US-centric. Frankly if any city hasn't got roots of a thousand or more years it ought to be called a modern town. :-) Consider the cities of Heidelberg, London, Rome, Athens and then approach on bended knee. Martin of Sheffield (talk) 13:27, 24 May 2018 (UTC)
  • I noticed the same thing in another article, there are three people claiming to be the first mayor of a location. One was mayor when it was part of another township, one was mayor when it was incorporated as a township on its own, and the final one was mayor when it was reorganized as a city. The obituaries all call them the first mayor of the location and the local government does not keep a canonical list. --RAN (talk) 14:55, 20 May 2018 (UTC)
    So we should simply be specific: "first mayor of the township of Foo", "first mayor of the city of Foo", or whatever the case may be. Sometimes this requires better research than that performed by an obit writer.  — SMcCandlish ¢ 😼  22:47, 23 May 2018 (UTC)
  • Local government reorganisations, like rail-replacement buses are a local speciality round my way. Take a look at City of Rochester-upon-Medway to see multiple ways of describing the disruption. ClemRutter (talk) 08:04, 23 May 2018 (UTC)
    Rochester. The only English town to lose its city status by accident. --Redrose64 🌹 (talk) 22:49, 23 May 2018 (UTC)

Semicolons.

Is their a stylistic difference we should be aware of between en-us and en-gb usage of semicolons? There obviously is a difference in what we call conjunctival adverbs - does this permeate further?--ClemRutter (talk) 19:02, 22 May 2018 (UTC)

In both variants, AFAIK there's no pedantically fixed standard, and use or non-use of the semcolon varies between writers. The article on the semicolon has some opinions on its use. Here's a New Yorker article: Semicolons; So Tricky. Here's a fairly standard note on British usage from the university of Leicester (England): Using the semi-colon and colondead link.
IMHO there's no encyplopedic reason to insist on any particular usage or to correct an article's usage of semicolons; however, {{Use xxx English}} tags should always be respected. — Stanning (talk) 20:20, 22 May 2018 (UTC)
Except that comma and semicolon usage in various articles here is often wrong by all "standards". If you think you're going to get some moratorium on cleanup of their abuse, think again.  — SMcCandlish ¢ 😼  22:33, 23 May 2018 (UTC)
Just a question that came up while training- you have to check before you give too forceful an answer! ClemRutter (talk) 22:50, 23 May 2018 (UTC) ;}
Sure. I was responding to Stanning's serious misstatement, "there's no encyplopedic reason to insist on any particular usage or to correct an article's usage of semicolons", which is just flat-out wrong in both parts. Otherwise MoS would have nothing on semicolons, nor would off-WP major style guides, but of course they do, because there are actual norms of use, most of which are cross-dialect.  — SMcCandlish ¢ 😼  23:21, 24 May 2018 (UTC)

In particular/usually

I made an edit to change the wording "in particular" to "usually" to more accurately reflect the content of the § Article titles guideline, which state, "Capitalize the title's initial letter (except in rare cases, such as eBay), but otherwise follow sentence caseb (Funding of UNESCO projects) not title case (Funding of UNESCO Projects). This does not apply where the title would be title case in ordinary prose". I summarize this that usually, not always, section headings should use sentence case, not title case. Dicklyon previously made an addition to the guideline, stating that "In particular, they should use sentence case, not title case (capitalize only the first word and proper names in headings)". This wording implies that in all cases the section heading should use sentence case, ignoring the exceptions mentioned in the article titles guideline. Therefore I changed "in particular" for "usually". Thinker78 (talk) 06:14, 24 May 2018 (UTC)

I saw that one, and pondered on which was right, concluding that neither reflected the meaning. Have you considered just using the humble colon to connect the two independent but closely related sentences. --ClemRutter (talk) 09:48, 24 May 2018 (UTC)
The only thing at title that's particularly relevant to headings is the capitalization; the "usually" or colon doesn't really connect this remark as intended. So I went back to "In particular" and noted that there are exceptions. See if that's more satisfying now. Dicklyon (talk) 14:16, 24 May 2018 (UTC)
Saw those edits... I like how it is with the "in particular" but then mentioning there are rare exceptions. I was wondering though... other than eBay, iPad, etc... are there any other exceptions? It says "except when the title would be title case in ordinary prose" but I'm having a hard time thinking up an example of that. Does it simply mean when the title of a work, for instance, is included in a section or article title, say "Imagery in A Clockwork Orange"? Or am I missing some other weird case? —Joeyconnick (talk) 18:13, 24 May 2018 (UTC)
I don't know. If and when exceptions are needed, I'd expect them to be obvious. Dicklyon (talk) 21:21, 24 May 2018 (UTC)
And it's not rational to assume that if one statement is simple, and another details some rare exceptions, that the exceptions don't apply because the other section didn't mention them. Much of the main MoS page is a glossing over of details and exceptions, the goal at this page being to lay out generalities. This is even true of material in one section that defers to material in another section of the same page with more detail on whatever that little side matter is. I have no objection to rewording either or both bits, as long as the intended meaning isn't changed.  — SMcCandlish ¢ 😼  23:26, 24 May 2018 (UTC)

List of definitions?

Someone added a list of symbol definitions for equations in the Lateral earth pressure article. All the definitions are correct, and they will help reading the equations in the article. My question is whether this table should be its own section, whether it should be a table or a list, and other stylistic questions about its placement. It's not whether the information belongs in the article, it's how the information should be presented. The presentation is a very textbook sort of presentation, and textbook is one of those things which Wikipedia is not. So what say you style mavens? — Preceding unsigned comment added by Argyriou (talkcontribs) 00:06, 23 May 2018 (UTC)

Containing one element of a textbook, does not make it a textbook article. I expect symbols to be identified in a mathematical article. In articles on films, I expect the characters in the plot summary to be identified in a list or table. --RAN (talk) 02:53, 23 May 2018 (UTC)
@Argyriou: Presumably you refer to this edit; since it is a list of definitions, mark it up as a definition list, like this. --Redrose64 🌹 (talk) 20:55, 23 May 2018 (UTC)
Agreed that's the right markup. We even have a nice template system for it, covered in detail at MOS:GLOSSARIES.  — SMcCandlish ¢ 😼  01:54, 27 May 2018 (UTC)
If it's not something we made up and it might be useful for other articles, maybe it should be its own article. We have many glossaries and other lists.  — SMcCandlish ¢ 😼  23:27, 24 May 2018 (UTC)

Citing a bowdlerised source

Comments welcome at Talk:Bruce McArthur#>>>Swearwords. The source reads I'm tired of these f---ing f---ots but that supports and verifies that the (alleged) statement was I'm tired of these fucking faggots. By the letter of the MOS we should reproduce the bowdlerised version, but by its spirit I think we should reproduce the quotation exactly as (allegedly) said. Andrewa (talk) 16:20, 26 May 2018 (UTC)

I notified WT:Citing sources and WT:Verifiability about this thread, since it's more about sourcing than style.  — SMcCandlish ¢ 😼  00:49, 27 May 2018 (UTC)
  • Use attribution would be my solution: 'According to Title of Source, McArthur said: "I'm tired of these f---ing f---ots".' Or use something more specific, e.g. 'According to an article by I. M. Whoever, ...'.  — SMcCandlish ¢ 😼  00:49, 27 May 2018 (UTC)
    • That would solve the problem, but it's a bit wordy and seems unnecessarily so to me... Surely, if I.M Whoever is a reliable source and states McArthur said: "I'm tired of these f---ing f---ots" in writing, we have verified by this source that McArthur in fact said "I'm tired of these fucking faggots"? But yes, it does overcome the more serious problem... McArthur did not say "I'm tired of these f---ing f---ots", and to cite this source as verifying that he did say this, rather than that he said I'm tired of these fucking faggots, is f---ing ridiculous. But a legalistic reading of the MOS did, in this example, lead to our article saying exactly that. Andrewa (talk) 09:18, 27 May 2018 (UTC)
      • "McArthur is quoted by Whoever as saying..."? This establishes that this isn't directly what McArthur said, just how the source quotes them. Ian.thomson (talk) 17:25, 27 May 2018 (UTC)
  • The "style" question – the question of writing – is whether this quotation is actually necessary at all. That paragraph feels a bit too blow-by-blow for me: Some (apparently random) guy describes a ten-minute temper tantrum that has no direct connection to the "plot". Encyclopedias do more "telling" than "showing". If the person telling the story is just some random acquaintance, it should be omitted altogether; if it isn't, then the connection should be explained (e.g., "father of one of the murder victims" or "brother of the accused") and the content should be summarized concisely: "He had an explosive temper". WhatamIdoing (talk) 05:42, 27 May 2018 (UTC)
    • That's another issue that may apply to this particular example, but ISTM it's a content issue. Andrewa (talk) 09:18, 27 May 2018 (UTC)
  • Unless there is an alternative source, we do not know for certain what McArthur did say. He might have said those "flaming flibbertigibbots". Unlikely, I know, but SMcC's suggestion avoids (mis)interpretation. Martin of Sheffield (talk) 17:21, 27 May 2018 (UTC)
    • Strongly disagree. While I agree we do not know for certain what McArthur did say, that's splitting hairs. We know what the source says, and when we say they're reliable we assume that they're not deliberately misleading us! And to say that he said I'm tired of these f---ing f---ots when in fact he said flaming flibbertigibbots would be so misleading, it would be reasonable to call it deliberate. So it's not a guess (as the edit summary of that last post claims) that according to the source he said fucking faggots. It is the only sensible reading of the source. Andrewa (talk) 18:39, 27 May 2018 (UTC)

Just to clarify, I'm not suggesting that we ever guess what the source means. But I am suggesting that when a reliable source is clear and explicit as to what was really said, but employs bowdlerisation because of the source's own style and content policies, and when the bowdlerisation has only one reasonable interpretation (as in the example), then we should read the source as verifying the unbowdlerised version. Because that is the only reasonable reading of the source.

If, on the other hand, we publish the bowdlerised version while knowing full well what the source means, we are ourselves guilty of bowdlerisation. Which is of course contrary to policy, and surely the MOS should reflect this policy? Andrewa (talk) 18:51, 27 May 2018 (UTC)

See WP:BOWDLERIZE on precisely this point "However, when quoting relevant material, rendering a quotation as it appears in the source cited trumps this style guideline". WP is not bowdlerising, the original source is. If you are worried, use the format suggested above and add {{sic}} to clarify: 'According to Title of Source, McArthur said: "I'm tired of these f---ing f---ots sic".' See MOS:SIC for guidance. Martin of Sheffield (talk) 19:16, 27 May 2018 (UTC)

Guideline clarification proposal to curtail MOS:TM vs WP:TITLETM gaming

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Trademarks#Minor clarification to avoid interpretational conflict between MOS:TM and WP:TITLETM
 — SMcCandlish ¢ 😼  20:59, 28 May 2018 (UTC)

In re single subsections

Please see Wikipedia talk:Manual of Style/Film#To be or not to be a subsection, on whether the use of a single ===Subsection=== (rather than two or more) within a ==Section== is compatible with good writing style. Please comment over there, not here. WhatamIdoing (talk) 23:33, 28 May 2018 (UTC)

MOS for portals

I've started a draft Wikipedia:Manual of Style/Portals, which would formalise the applicability of the MOS to portals, with just a few exceptions. Your feedback would be appreciated – discussion is taking place at Wikipedia talk:WikiProject Portals § To what extent does the MOS apply to portals? (please respond there, not here). Thanks, Evad37 talk 16:35, 27 May 2018 (UTC)

Thanks for doing that. Looking good so far. Dicklyon (talk) 17:00, 27 May 2018 (UTC)

Discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Portals#RfC: Adopt as a MoS guideline . - Evad37 talk 03:00, 31 May 2018 (UTC)

MOS:GNL side-matter

 – Pointer to relevant discussion elsewhere.

Please see Talk:Gender neutrality in languages with grammatical gender#Major update needed for Romance languages
People who edit here may be interested in it. The gist: there's a pattern of using the single character x as a stand-in for "a or e/i/o depending on your gender", and it's increasingly coming up in the proper names of organizations, forums, etc. So, we might want to address (in a footnote?) either here or at WP:GNL that good markup for this sort of thing is, for example, usuari<var>x</var>s or the equivalent usuari{{var|x}}s (rendered: usuarixs) as the shorthand for "usuarios/usuarias" or "usuaria|os" or whatever. This will alert editors that the x is not a typo but a metasyntactic variable. This mark-it-up approach is consistent with various advised uses of {{sic|hide=y}} or {{notatypo}}.  — SMcCandlish ¢ 😼  05:13, 2 June 2018 (UTC)

Is it standard to render the x in a different font than the rest of the text, the way your markup does? That formatting looks ugly, because fonts are not designed to mix in the middle of words like that so the kerning is wrong. —David Eppstein (talk) 07:07, 2 June 2018 (UTC)
Please centralize the discussion at the thread pointed to. Avoding talkforks is why we make pointers from one page to a thread at another.  :-)  — SMcCandlish ¢ 😼  00:42, 8 June 2018 (UTC)

RfC

An RfC concerning the categorization of biracial people has been opened at Wikipedia talk:Categorization/Ethnicity, gender, religion and sexuality#RfC on categorizing biracial people. StAnselm (talk) 04:31, 31 May 2018 (UTC)

It does touch on MOS:IDENTITY but seems mostly to be a WP:NOR dispute (including about the term biracial and when to apply it, though it's mostly actually about African-American in the context of Meghan Markle).  — SMcCandlish ¢ 😼  06:43, 9 June 2018 (UTC)

Singular possessives in -s

It's somewhat unfortunate that the section on Possessives includes "Jesus" as an example (Jesus's teachings). Whereas it's fine to add apostrophe+s on names ending in -s the most well-known exception to this in many style manuals is Jesus, which adds only the apostrophe: Jesus' teachings. I'm not saying that MOS needs to adhere to what most style manuals do, I'm only saying that we shouldn't pick as our example to illustrate the general -s rule, the most famous example which is an exception to that rule in many style guides; we can pick something else. Here is Bryan Garner:

To form a singular possessive, add -'s to most singular nouns—even those ending in -s and -x (hence witness's, Vitex's, Jones's, Nichols's). ... There are three exceptions to this rule. The first is the standard one: Biblical and classical names ending in -s take only an apostrophe:, hence Jesus' suffering, Moses' discovery, Aristophanes' plays, Grotius' writings. (No extra syllable is added in sounding the possessive form.) The second exception is words formed from the plural. Thus General Motors should make General Motors'—e.g.: "A merger by General Motors will excite great interest in an enforcement agency simply because of General Motors's read General Motors' size."

HTH, Mathglot (talk) 09:07, 8 June 2018 (UTC)

Consider, perhaps, that it was chosen because some style guides make such an exception, others don't, and the intent here is to dissuade insistence on that variance because "my style guide at work says so". Also, as of the edition put out last year, The Chicago Manual of Style (which has much more buy-in than Garner's Modern English Usage, a.k.a. Garner's Modern American Usage until its latest version) has shifted strongly away from such exception-making, for the first time in generations (though it observes that some do use such exceptions; the Hafiz' and Beatrix' variants are also fairly common). The relevant material in CMoS – the whole set of chapters on grammar, punctuation, and spelling, actually – were actually written by Garner under contract. So, either his own position is shifting, or he gives conflicting advice in different books on purpose, but a purpose we can't, of course, psychically determine. And Garner isn't a linguist, he's an attorney. Many of the things he says about language are demonstrably wrong (e.g. "No extra syllable is added in sounding the possessive form" is only true in some regional dialects, and not a majority of them).

Regardless, the CMoS shift is an indication that "Jesus'" isn't a rule in a sense we should care about here, but a subjective preference of some American writers and editors primarily (it's neither exclusive to them nor consistent among them), and is slipping in acceptance because it's confusing and illogical (it seems to've been picked from the Elizabethan-era pre-orthography-standardization King James Bible, used by many American Protestant sects, and retained in the 20th century because it coincides with a particular, blurred pronunciation in some variants of US Midwestern English (and some other dialects, e.g. in parts of Texas that's /ˈtɛksəz/ !, though CMoS wouldn't care). But it isn't actually dominant across the language or even in the US. Our own conversations on this page show it; every time the issue comes up, editors from around the English speaking world and the US more narrowly tell us that they pronounce "Jesus" and "Jesus's" differently, with a distinct syllable added to the possessive (the suprasegmental length is apt to vary, and might be rather short; it is for me).

There is no escaping a simple fact: for every single point of English usage on which different self-styled authorities disagree, there will always be some subset of readers and editors who don't like the version we pick. So, MoS works best when it detects and defuses "style-guide thumping" that's likely to recurrently arise. E.g., we've done the same thing with capitalization of prepositions in titles of works, something that style guides disagree on even in the same field, like journalism, and which is often laden with style-guide-specific exceptions. We just swept away the exceptions as inconsistent and troublesome, and went with neither of the more extreme approaches.
 — SMcCandlish ¢ 😼  12:05, 8 June 2018 (UTC)

So there! Any more questions? EEng 14:06, 8 June 2018 (UTC)
sigh The intent isn't to WP:WIN, it's cover what the rationale is for the MoS wording, and why a "Garner says ..." observation isn't particularly meaningful as an isolated point, without both comparison to other style guides and awareness that Garner writes more than one of them (at least 4 to date), often inconsistently. (Aside: As far as I can tell, Garner has carved this niche simply by having been one of the editors of Black's Law Dictionary; it's what got his foot in the door to put out A Dictionary of Modern American Usage in 1998, when OUP figured there was a market for an American counter to the very British Fowler's (and of course wanted to publish both of them).  — SMcCandlish ¢ 😼  22:36, 8 June 2018 (UTC)
Actually, that example is there simply to illustrate what "rearrange the wording" means with a practical example. It is carefully worded so as not to give the impression that it is an example of a possessive that is difficult to pronounce, or indeed the reverse (hence my revert of yesterday's bold edit, which changed the phrasing so as to make it such an example). We sidestepped the question of whether Jesus's is or is not "difficult to pronounce" and simply offered the two alternative phrasings to illustrate the preceding provision in the MoS. MapReader (talk)
That's a reason it's there. I'm pretty sure I wrote the wording in question.  :-)  — SMcCandlish ¢ 😼  23:04, 12 June 2018 (UTC)

A move review to consider

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia:Move review#List of Presidents of the United States. Some comments at WT:MOSCAPS has suggested there could be insufficient input so far to reach a clear consensus. Depending on how it turns out, MOS:JOBTITLES might require substantial revision, which could in turn affect the wording at the main MoS guideline. (That might or might not be a good idea, but people who watch this page should be aware of it either way.)  — SMcCandlish ¢ 😼  03:12, 14 June 2018 (UTC)

MoS section merge discussion

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Biographies#Merge MOS:JOBTITLES to this MoS page.

The proposal is to merge WP:Manual of Style/Capital letters#Titles of people (a.k.a. MOS:JOBTITLES) to WP:Manual of Style/Biographies, where the rest of the material about human titles is (academic, post-nominal, honorific, regnal, etc.). A short summary and hatnote pointer would be left behind in MOS:CAPS (about the same as those presently at found at MOS:CAPS#Occupational titles pointing to MOS:CAPS#Titles of people; the relationship would simply be reversed).  — SMcCandlish ¢ 😼  06:50, 14 June 2018 (UTC)

A whole lot of MoS-related WP:Redirects for discussion

 – Pointers to relevant discussions elsewhere.

Please see:

The "NOTES" one proposes that "MOS:" shortcuts should point to non-Manual of Style pages. The AMEN and BRIT ones are about ambiguity. The pseudo-namespace ones boil down to this: "MOS:" is a pseudo-namespace created, after a consensus discussion, to point to WP's Manual of Style and sections and subpages thereof, to deal with the decreasing availability of meaningful and memorable "WP:"-namespace shortcuts, and because there's often an MoS page and a content, naming, or other page about the same thing. However, pseudo-namespaces are actually in mainspace (articlespace). Some editors thus do not want to see a profusion of "typo redirects" like "MoS:CAPS", "mos:CAPS", "Wikipedia:MOS:CAPS", etc., while others are convinced that all redirects are necessarily "cheap" and always should be permitted even if only used by a handful of editors and of no use to readers.  — SMcCandlish ¢ 😼  06:42, 10 June 2018 (UTC)

Towards or toward

Quick question... In a statement such as: “The media’s attitude toward(s) the military shifted during the war”, should we use “toward” or “towards”. Blueboar (talk) 17:42, 3 June 2018 (UTC) Blueboar (talk) 17:42, 3 June 2018 (UTC)

I believe "toward" is preferred for American English, and "towards" for British English. The same style generally applies to other directional words as well (e.g. forward/forwards). - adamstom97 (talk) 21:46, 3 June 2018 (UTC)

Isn't this a better question for the Refdesk? Primergrey (talk) 21:48, 3 June 2018 (UTC)

Yeah... but I knew I would get a quicker answer here. Thanks. Blueboar (talk) 13:44, 4 June 2018 (UTC)
Bryan Garner is my go-to guy for this, and he agrees with adamstom97 on AE/BE distinction. However, this may be the wrong word entirely in this situation. As Garner says, Misused for to. Toward implies movement. It shoudln't be used when the sentence would be served by to or against—e.g.,... followed by three bulleted examples. The examples include expressions like "objections toward" (use to), or "prejudice toward" (use against). Attitude isn't movement, so my guess would be that you should probably not be using toward here, maybe about? However a quick check of other online grammar resources seems to indicate a preference for toward/s with attitude. Ngrams shows the top ten prepositions after attitude, but doesn't include multi-word expressions like with respect to or vis-a-vis. Mathglot (talk) 04:06, 8 June 2018 (UTC)
An additional way we approach this, especially on WP, is MOS:COMMONALITY, which is more important than the argument to authority inherit in relying on a favorite style book. There is no intelligibility problem with toward, in any dialect, so it's preferable for concision. However, towards isn't an unencyclopedic colloquialism, even in American English, so MOS:RETAIN would suggest not going around changing it to toward just for the heck of it (especially not as a trivial edit unto itself), since the potential editorial kvetching would probably not be worth saving a character here or there. If I were writing a new article, or substantively overhauling an extant one, I would use toward (if it weren't better replaced by to, etc., as Mathglot says). Same goes for similar words like forwards, amidst, etc.  — SMcCandlish ¢ 😼  06:41, 9 June 2018 (UTC)
This American finds the usage of "toward" in that construction to be extremely jarring. The point about movement sums up the usage I am familiar with. --Khajidha (talk) 04:13, 15 June 2018 (UTC)

If this isn't a suggestion to include some sort of guidance on this particular point to the MOS, then this entire discussion ought to be at the refdesk or a user's talkpage...no? Primergrey (talk) 00:13, 13 June 2018 (UTC)

Agreed, this is not WP:RDL. But (to me) it isn't clear that the OP does not propose an MOS change. ―Mandruss  00:20, 13 June 2018 (UTC)
My bad, per I knew I would get a quicker answer here. Make that: This is not WP:RDL, speed of answer irrelevant. ―Mandruss  00:22, 13 June 2018 (UTC)

Ellipses, capitalization, and whether an example of a common construction constitutes a quotation

 – Pointer to relevant discussion elsewhere.

Please see Talk:Ellipsis#"Save As..." style.  — SMcCandlish ¢ 😼  05:14, 19 June 2018 (UTC)

Additional input requested. This has turned completely circular in WP:IDHT fashion.  — SMcCandlish ¢ 😼  18:32, 21 June 2018 (UTC)

Why capital S?

Why is this page titled Wikipedia:Manual of Style, not Wikipedia:Manual of style? --SmokeyJoe (talk) 07:06, 22 June 2018 (UTC)

This should be a good one. EEng 07:19, 22 June 2018 (UTC)
I imagined it was based upon the ancient Manual of Stylos, the Greek etymology of the village being 'column' or 'pillar', with the MoS being the pillar that supports all good editing? But I am sure that other views are available... MapReader (talk) 09:58, 22 June 2018 (UTC)
Indeed. It was brought unto us by the ancients, passed down generation-to-generation by the Secret Order of Stylos (now a subsidiary of Brotherhood of the Cruciform Sword).  — SMcCandlish ¢ 😼  12:07, 22 June 2018 (UTC)
There was a discussion about it way back when. The gist is that it's intended as a work, of sorts. It was also observed that various other project pages, like a lot of wikiprojects, use title case. I'm not sure anyone feels strongly about it these days. My only qualm would be that lowercasing these pages would produce an enormous redirect cleanup job, which might have to be done manually. The recent move of WP:Manual of Style/Biographies to WP:Manual of Style/Biography had the double-redirect-fixing bot actually fail to do its job. Just fixing shortcuts to that page alone took me about two hours. I don't know who'd volunteer to fix several thousand redirs to all the MoS pages. Also, we typically abbreviate it "MoS", which would no longer make sense if it was down-cased to "style". In short, I don't think a lower-case tweak would be worth the effort. We're going to have a consistency issue no matter what: either it's not consistent with our mainspace article titles, or it's not consistent with its own advice on how to style the titles of works like The Chicago Manual of Style. So, I think we should choose the path of least agony and leave it as-is.  — SMcCandlish ¢ 😼  12:07, 22 June 2018 (UTC)

Variants of English

Should Singapore English be included for Singapore-related articles? --occono (talk) 17:58, 22 June 2018 (UTC)

Stand by for a tongue-lashing (so to speak) (so to speak). EEng 18:07, 22 June 2018 (UTC)
We should not list anything that doesn't exist in a codified, formal written register with its own style guides, distinct from British/Commonwealth English in general (Canadian and Australian English do, and I think I saw one for New Zealand, and maybe South African). In virtually all other former countries of the British Empire where English is still used as a first language by a notable percentage of the population, they refer to British style guides like New Hart's Rules, New Oxford Dictionary for Writers and Editors (combined as New Oxford Style Manual), Fowler's Dictionary of Modern English Usage, The Cambridge Guide to English Usage, etc. Even most of the journalism and lower-register professional writing (business, marketing) follows the same shared conventions as BBC News (a dominant news provider in most of them), The Guardian, The Times, The Economist, etc.

I've been looking for years, and I cannot find any "produced for public use" style guides for places like Malta, Pakistan, Kenya, Grenada, Singapore, Belize, etc., etc. These dialects exist almost entirely as spoken dialects and informal writing based on it, but WP isn't written in informal English, so it's not an ENGVAR matter. Formal writing from such places is generally indistinguishable from British, aside from some locally specific vocabulary words (just as you'll find in Wales or Scotland). Editors branding "their" articles as being written in such dialects is a) nonsense and b) a recipe for insertion of unencyclopedic colloquialisms. There's a good reason we don't have templates for "This article is written in Texan English" and "This article is written in Cockney". There's more difference between Texan and Manhattan English, and between Cockney and Shetland English as dialects than there is between written formal Singaporean or Maltese English and written formal British English. Basically, WP isn't written in bar/pub talk, and we mustn't pretend otherwise just because a handful of editors want to slap huge flag-waving banner templates in articles' editnotices for territorialism and national-pride reasons.

PS: Listing Irish English is basically an "avoid an ethno-political shitshow" concession; at the formal written level it also follows British norms (and I have yet to see an Irish English style guide), but people might quite literally threaten each other over putting "Use British English" templates on Ireland-related articles.
 — SMcCandlish ¢ 😼  18:41, 22 June 2018 (UTC)

{{Use Commonwealth English}} and {{Commonwealth English}} and related templates and categories now exist. We should consider nominating templates we don't need for merger with and redirection to the Commonwealth versions.  — SMcCandlish ¢ 😼  20:17, 22 June 2018 (UTC)

MOS:CONFORM and citation titles

In sourcing for most contemporary entertainment, sources generally omit italics or the like to format the name of the work being discussed in the title of their articles. So it seems that most of our citations/references generally end up presented these citation titles without italics/etc. for named works. Should MOS:CONFORM apply to citation titles, considering that these are technically quotations ? I do know we frequently removal allcaps and other unreadible aspects of titles in citations, so it would seem logical to apply appropriate MOS-elements like italics where they can apply. --Masem (t) 13:21, 16 June 2018 (UTC)

Yes. Any given written source will do any of at least 10 different things in presenting the title of a major published work inside the title one of that source's articles (e.g. giving a movie title in the title of a review of the movie): 1) italics, 2) double quotes, 3) single quotes, 4) bold-face, 5) ALL-CAPS 1, 6) SMALL-CAPS (rarely), 7) underline (rarely), 8) some other font tweaking (rarely), 9) some combination of more than one of these, 10) no markup at all. This is just farcically messy, and trying to mimic the other publication's style, under their stylesheet, in our citations is "reader-hateful" and just not what we would do in any other circumstance (e.g. we do not mimic logo stylization per MOS:TM, we do not over-capitalize job titles and do other "specialized-style fallacy" mimicry of other organization's house style quirks). We already routinely down-case any SCREAMING ALL-CAPS HEADLINES to title case (or to sentence case, if the citation style in question demands that for article titles), and do other font normalization in our citations (e.g., if a title looks boldface in the original publication, we do not ape that stylization here). This isn't any different. For over 12 years, I've been doing cleanup of this sort, especially italicizing the names of books and films in review articles' titles (per MOS:TITLES), and italicizing genus and species scientific names in biology journal article citations (per MOS:LIFE), and as far as I can tell not one single person has ever reverted me on it. It's completely normal do this sort of MOS:CONFORM tweaking.  — SMcCandlish ¢ 😼  11:22, 17 June 2018 (UTC)
This clearly makes sense, but it should be qualified somewhere, as I ask from seeing a recent dispute on a video game article. (assuming this is the consensus). --Masem (t) 15:21, 17 June 2018 (UTC)
Meh. We should generally avoid adding redundant line-items that simply re-state what can already be intuited from the existing ones and from actual overall editorial behavior. At an infrequent and weird dispute at an article talk page, maybe just point people to this thread (here now, or later at its eventual archive location). If we kept adding "rules" we don't strictly need (i.e., ones that do not address an actually frequent dispute type), we'd have thousands more lines in MoS, a major WP:CREEP problem.  — SMcCandlish ¢ 😼  20:14, 17 June 2018 (UTC)
@Masem: Maybe this could be addressed in a footnote, if we can come up with a concise one. And/or maybe address it at MOS:TITLES instead of the main MoS page. Length is less of a concern in a topical MoS subpage.  — SMcCandlish ¢ 😼  20:22, 22 June 2018 (UTC)

New RFC on linking to Wikidata

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
  • Summary--
    • Maneuvering through the crux of the !votes, there seems to be a numerical as well as a policy-based consensus in checkY favor of implementation of a slightly nuanced version of Option 1 i.e. Wikidata should not be linked to within the body of the article except in the manner of hidden comment(s) as to mentioning the Q-number.(This, in it's entirety also looks to be Option 4)
    • That being said, I do not see any consensus as to the proposed exception of linking to WD, by something similar to inline inter-language link(s)which may be executed using the same template.
  • Details:--
    • I do not find a single persuasive argument in favor of allowing them to be used in body (as RAN has used) esp. in light of their sourcing policies, accuracy issue(s) and other stuff, which often runs contrary to our en-wiki policies.(See Eppstein's, Reyk's, Outriggr's and SMC's argument(s))
    • Similarly, I fail to spot much rationale as to the supporter(s) opposing hidden comments mentioning the Q-number, given that it can be helpful to in a certain non-obtrusive manner and also note that many of those who have flat-out opposed the policy have mentioned this as a locus for their rationale.
      • Thus, I'm compelled to go with the numerical majority but with an important caveat that enabling this is not a license to mindlessly execute mass-commenting at various pages so as to append the Q-ID.
    • As to the other proposed exception of linking to WD, by inline inter-language link, given that there is roughly a numerical tie and there's no clear-cut refutable argument(s) from either side, I am unable to see any consensus.
      • I'll advice for a re-discussion on this very locus, shall this turn out to be another battle-focus between editors.
  • Note-This over-rides the closure of this RFC, as to the specific area of the body of any article.
  • Thankfully,WBGconverse 07:27, 24 June 2018 (UTC)

Should we ban links to wikidata within the body of an article? --Rusf10 (talk) 00:50, 10 May 2018 (UTC)

Background

Over two months ago we had an RFC on linking to Wikidata, the result of which was "no consensus". I initiated the RFC after a user was continually adding links to wikidata to replace articles that were deleted through AfD for notability concerns, here is an example. Unfortunately, I did not create the question that we voted on and it was worded with the extreme position of "Never link to Wikidata" which got mixed support. I think most people generally agree that the links are the sidebar are useful (in particular the inter-language links) and should not be removed. However, within the body of the article there was less support for using wikidata. Some people also indicated that inline interlanguage links (see WP:ILL) may also be appropriate. However, almost everyone agreed wikidata links should not be a substitute for a red-link (or a deleted article). While I agree that linking different language versions of wikipedia is a great feature, otherwise I find wikidata to be unreliable and directly linking to it would be confusing for the average user.--Rusf10 (talk) 00:50, 10 May 2018 (UTC)

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

I'm providing three options:

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

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

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

Survey

  • Support- full ban in body of article as proposer.--Rusf10 (talk) 00:50, 10 May 2018 (UTC)
  • exclamation mark  NOTE: Some !voters below may have arrived via partisan audience CANVASS. This RFC was posted & linked on the Wikidata central Project Chat at 01:52, 10 May 2018.2 Alsee (talk) 01:33, 13 May 2018 (UTC)
    WP:Canvas says to post at the projects involved! Calling them a "partisan audience" is just silly. They have as many diverse opinions as there are here. --RAN (talk) 20:50, 18 May 2018 (UTC)
    RAN, WP:CANVASS says notifying WP:Wikiprojects here on EnWiki is appropriate. We have had RFCs relating Wikinews, Wikiversity, and others. For example whether we wanted those wikis to appear in local search results, and whether our policy pages direct users to go to those other wikis for various purposes. Those RFCs were not advertised on those other wikis, because it was a purely local EnWiki matter and EnWiki community decision. It would have been seriously inappropriate to canvass Wikinews or other communities trying to swamp the EnWiki RFC to promote external agendas. You do not want to win this argument. A canvassed mob from EnWiki could overwhelm any other community at will. A canvassed EnWiki mob could delete or re-write Wikidata polices any way we please. We could re-write Wikidata policy to require deletion of any unsourced claims, and even deletion of all sourced claims which don't comply with EnWiki WP:RS policy. The fact that Wikidata would cease to exist as an autonomous community would actually help resolve some of the issues with using Wikidata on EnWiki, all content on Wikidata would be subject to EnWiki policies and EnWiki administration. Alsee (talk) 04:18, 20 May 2018 (UTC)
    Yeah, notifying off-site (even WMF-related) groups who have a vested interest in the outcome is WP:MEATPUPPETRY, a particular form of canvassing.  — SMcCandlish ¢ 😼  06:48, 9 June 2018 (UTC)
  • Oppose - This appears to be about Rusf10 removing hidden links Q-numbers formatted as <!-Q123456--> to Wikidata from tables that list multiple people that do not currently have an entry in English Wikipedia. The Wikidata entry links to Wikipedia entries in other languages and links to Wiki Commons and Wiki Quote, even if they do not have an English Wikipedia entry. The hidden links will let an editor know that if an article is recreated or a new entry is created for this person, an entry at Wikidata already exists. This will hopefully reduce duplication of Wikidata entries. It also allows Wikipedia to disambiguate people that appear in articles and lists that currently do not have Wikipedia entries. This way a person can know that say "John Smith, Mayor of Yourtown<!-Q123456-->" in an article on Yourtown is the same person as "John Smith, President of BigCompany<!-Q123456-->" that appears in the article on BigCompany. It will allow someone who creates an article in the future to search for hidden text on the string "Q123456" and find both entries and create the properly disambiguated link to the article. Of course only someone actually editing an article will be able to see the hidden link Q-number. --RAN (talk) 02:06, 10 May 2018 (UTC)
    This will do absolutely nothing to prevent duplicate entries in wikidata for topics that already have articles in wikipedia, so it seems to me to just be an excuse, not a real solution to a problem. If duplicate entries is really a widespread problem in wikidata then why doesn't wikidata come up with its own solution for this that doesn't involve wikipedia?--Rusf10 (talk) 03:38, 10 May 2018 (UTC)
    Okay, to clarify what I think RAN is talking about: Suppose there is a redlink here. Somebody sees it, creates an article, and then creates a Wikidata entry for the new article. What I think RAN is suggesting is that any hint we can give here is useful, that a Wikidata item already exists, and so if/when a new article is created here, then it should be linked to the existing Wikidata item, rather than have a new one created for it.
    Wikidata users make quite an effort to try to hunt down and merge duplicates, eg trying to spot potential duplicates that matching birth/death dates, or the same value for an external ID, or apparent duplicates that come up organically in search. But all these are playing catch-up, and are never 100%. It's altogether better if the new article gets linked properly from the outset.
    Another reason (IMO) may also be worth considering why such references in comments might be useful, namely that if a wikidata item exists, it may have some useful information and references for basic facts like full names, dates, external identifiers, places of activity, birth, death, etc that all may be of use to somebody creating an article. Jheald (talk) 10:54, 10 May 2018 (UTC)
  • Support a ban, or at least strongly discourage them, similar to the language in WP:EXTLINKS. Pburka (talk) 02:38, 10 May 2018 (UTC)
  • Oppose Such links should be allowed to be used where they can provide extra information to readers and editors about the topic. They are not completely external links, they are links within the Wikimedia movement. Thanks. Mike Peel (talk) 12:07, 10 May 2018 (UTC)
  • Support, but with exception for inline inter-language links. I oppose the concept of comments that point to Wikidata, because there is no unambiguous format to determine the exact meaning of such comments, or exactly how the comment would be associated with the text in the article. Such a situation is an invitation for people to write bots that screw things up. Jc3s5h (talk) 12:20, 10 May 2018 (UTC)
  • We should not link to wikidata at all. Inline interlanguage links have always been discouraged in practice (notice how few of them exist). There is no reason to add an exception for Wikidata about them. — Carl (CBM · talk) 12:40, 10 May 2018 (UTC)
  • Support with exception for interlanguage links per Jc3s5h. Ealdgyth - Talk 13:16, 10 May 2018 (UTC)
  • Support with exception for interlanguage links per Jc3s5h and Ealdgyth. ILLs may be rare due to the fact that the English Wiki is currently standing at 5,646,567 articles, well ahead of most other languages (wp:List of Wikipedias). (Indeed if you ignore those articles written by Lsjbot, well over double the size of any other Wiki.) Therefore few articles will appear in another language and not in English, except for small geographic features and locally notable persons. ILLs are invaluable for setting up a link that can be subsequently translated either full or as guidance. When I was working on Peter Harlan I used an ILL to get the basis of the article and there are still ILLs for Cornelia Schröder-Auerbach de, Hanning Schröder and Castle Sternberg de within it. It means the reader has at least the possibility of finding the information until someone has the time to create an English version. Martin of Sheffield (talk) 13:40, 10 May 2018 (UTC)
  • Oppose any restriction per my comment in the previous RfC. This an utter baby-with-the-bathwater case, which would disallow links to Wikidata in tables, for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 10 May 2018 (UTC)
  • Mu I'm all for creating a policy to explain how and what sorts of links are useful. This sort of RFC, which is too restrictive and too ignorant of nuance, is not the way to do it. --Jayron32 14:51, 10 May 2018 (UTC)
  • I cannot choose any one of the four options, although the closest thing would probably be "support with exception" + "allow hidden comments". The status quo appears to be to discourage inline interwiki links in general, except for Wiktionary and Wikisource links and those generated by {{Interlanguage link}}. Regardless of whatever concerns there are with Wikidata at this juncture, I think the current Manual of Style guidance should be sufficient, although I would update it to explicitly permit {{ill}} links to the Wikidata item. Banning hidden comments based on innocuous material, if the proposer is indeed in support of this, is patently ridiculous and unnecessarily heavy-handed, especially since these are not actually links and readers aren't supposed to see them. I don't think it's necessary to lump them together with real working links. Aside from the issue with hidden comments, I think the RfC should be clarified to indicate that the proposer is, at least according to their own words, in support of the status quo that currently exists. Jc86035's alternate account (talk) 15:06, 10 May 2018 (UTC)
  • Support—there are far too many issues with WikiData's implementation and with WikiData-folk contemptuously imposing WikiData on articles beyond the control—or even awareness—of the custodians of Wikipedia articles. This shouldn't be re-opened for discussion until it can be clearly demonstrated that all the issues—both technical and behavioural—have been dealt with. Curly "JFC" Turkey 🍁 ¡gobble! 00:32, 11 May 2018 (UTC)
  • Oppose A QID or URL in a comment is a good way to tip about the existence of the article in sister sites. At this stage practices are evolving and improving every day, but banning such info would just kill innovation. Syced (talk) 06:29, 11 May 2018 (UTC)
  • Oppose. The only reasonable usage of linking to wikidata (as opposed to pulling data from Wikidata, which the topic starter explicitly excluded from this RfC by saying it has no impact on {{Authority control}}), is to indicate next to a redlink that a Wikidata item for this redlink exists. I can not envision a single rational argument ("Wikidata is evil" is not a rational argument) against connecting a redlink on Wikipedia with Wikidata in the case the Wikidata item exists (there are plenty of items on Wikidata which do not have any sitelinks and which would be notable by our standards). Whether it should be a link similar to {{ill}} or just a number commented out is debatable, but I am not looking forward for this debate, as this RfC is very badly organized (similarly to the previous one) and is very untimely (similarly to the previous one).--Ymblanter (talk) 07:01, 11 May 2018 (UTC)
  • Support- with the possible exception of interlanguage links. From what I've seen of WikiData, its content is confusing, often mostly empty, and frequently erroneous. As Curly points out, it feels lioke this junk is being inflicted on Wikipedia with minimal oversight. I'd put a moratorium on the use of WikiData until we can be satisfied that we're not just rubbishing our standards of accuracy. Reyk YO! 07:08, 11 May 2018 (UTC)
  • Support until such time as Wikidata develops a better reputation for fact-checking, referencing, and accuracy, especially for details such as citizenship of living people (often listed, rarely sourced). —David Eppstein (talk) 07:24, 11 May 2018 (UTC)
  • Support - not a community based here.--Moxy (talk) 11:56, 11 May 2018 (UTC)
  • Oppose Banning comments is excessive, and doesn't seem to have had any justification given. Limited use of {{ill}}-style links in tabular material and lists could also be useful. Jheald (talk) 18:39, 11 May 2018 (UTC)
  • Support. Wikidata links are an inappropriate destination, except perhaps in the Wikidata article or other articles actually discussing Wikidata. In rare cases I could see a valid purpose for a hidden comment mentioning Wikidata. However hidden links are inappropriate without some unusual need in the specific case. Links to foreign language articles are generally a bad idea for a number of reasons, but sending a reader to Wikidata for interlanguage links is even worse. Alsee (talk) 02:56, 13 May 2018 (UTC)
  • Support. Sending readers to Wikidata is very rarely helpful, and if an editor believes that more information about a redlink or an unlinked term / name is needed, it would be better if they added a reliable source as a reference to it. The same applies to the vast majority of regular interlanguage links in our articles. Fram (talk) 13:33, 17 May 2018 (UTC)
  • Support. Rusf10, I'm not sure what "with exception for interlanguage links" has to do with the question "Should we ban links to wikidata within the body of an article?" SarahSV (talk) 14:13, 17 May 2018 (UTC)
    SarahSV I believe wikidata interlanguage links refers to replacing a redlink Jokery with Jokery Wikidata, which sends the user to the bottom of a Wikidata page. In my opinion the typical reader will WTF when they see the link, and they'll be confused as hell if they click on it. Alsee (talk) 09:26, 18 May 2018 (UTC)
    That's really confusing. I was thinking more along the lines of Olena Chaplynska uk; ru; ja. That could possibly have a use, but in my opinion, neither should be allowed. I just wanted to offer it as an option since some people had expressed support for these types of links in the past.--Rusf10 (talk) 14:24, 18 May 2018 (UTC)
    Rusf10, that's what I thought. It might be worth striking through that option, because those links have nothing to do with Wikidata that I know of, so it introduces a confusing tangent. SarahSV (talk) 16:08, 18 May 2018 (UTC)
    @SlimVirgin:Someone can correct me if I'm wrong, but I was under the impression that the ill links work by pulling information for the wikidata database.--Rusf10 (talk) 16:19, 18 May 2018 (UTC)
    Rusf10, you could be right, in which case it's a good idea to offer it as an option. SarahSV (talk) 17:21, 18 May 2018 (UTC)
  • Support. Disruptive without sufficient utility for almost all readers. Who actually uses Wikidata? My guess is a special type of reader. I have no objection if Wikidata links are added where they're easy to find and unobtrusive—in the "See also" section at the bottom, or some such. Tony (talk) 14:23, 17 May 2018 (UTC)
  • Support with the two exceptions. My reasoning is basically the same as that of David Eppstein who put it more succinctly than I would have. At some point, we can work-in an exception for WD material that is sourced to en.wp standards, when WD provides a means for us to be certain of this. WD-provided information would be useful for certain things, especially tabular data. But we're just not there yet. This project's core content policies are way more important that link-making convenience or data-provision centralization.  — SMcCandlish ¢ 😼  10:04, 18 May 2018 (UTC)
    PS: I also agree with Tony1 that an "External links" entry (a regular line-item or a templated one) might be appropriate, as we'd use for a Wiktionary entry, etc. But we don't need any kind of policy change with regard to that, since it's already covered by WP:EL and MOS:LAYOUT as a general matter. I.e., this RfC isn't going to magically carve out a special exception to those rules, so people can stop wringing their hands about it and casting FUD at the RfC.  — SMcCandlish ¢ 😼  12:56, 20 May 2018 (UTC)
@SMcCandlish:Here's the problem I have with the ILL template. It can be used to directly link to the wikidata entry rather than the different language articles. For example how it is being used here Take Paul Kiernan for example. He doesn't have any article on English wikipedia (It was deleted) and I'm near 100% sure no one is even going to attempt to create an article about him in another language, so why is an ILL being used here?--Rusf10 (talk) 04:12, 20 May 2018 (UTC)
Given what looks like an emerging consensus to not dump our readers into the middle of a WD page as if it's an article, I would expect that {{ILL}} would be changed to no longer do that, or to not do it when used in mainspace, or to put a red warning if done in mainspace (to permit the possibility in some circumstance we haven't accounted for, but which is rare), etc. I wouldn't dwell on this particular detail here and now.  — SMcCandlish ¢ 😼  12:56, 20 May 2018 (UTC)
  • Support with the two exceptions. Wikidata links can be useful external links, when used with consensus, as in the {{Taxonbar}} template), but direct links to Wikidata are not appropriate in the body of an article any more than a link to any other external database would be. Peter coxhead (talk) 05:58, 19 May 2018 (UTC)
  • Support Wikidata links should not be allowed in either the Lead or the Body of the article. I'm agnostic on links in infoboxes, external links, etc. LK (talk) 06:53, 20 May 2018 (UTC)
  • Oppose. I definitely support inline inter-language links and hidden-text Q numbers. That said, I support removing wikidata links from non-notable subjects where the sole purpose of the link is disambiguation. I'm not sure where the guideline is on this, but I believe inter-language Wikipedia links should always be required to meet WP:N. If there's debate, I expect the person arguing for the link to begin a draft on the subject. However, I think this blanket restriction on Wikidata links is too broad. Daask (talk) 20:27, 29 May 2018 (UTC)
  • Support with two exceptions - per SMcCandlish. Furthermore, Endorse SMcCandlish on not letting the ILL template dump a reader onto wikidata from mainspace easily. Tazerdadog (talk) 01:49, 1 June 2018 (UTC)
  • Oppose. They're not often going to be useful but as exceptions to that are possible it doesn't make sense to ban it. For the same reasons we don't ban links to the Esperanto Wikipedia or the Daily Mail - just because they are not often helpful doesn't mean they never are. Thryduulf (talk) 09:28, 3 June 2018 (UTC)
  • Support, with possible exceptions by specific consensus after verifying the specific Wikidata entries. Links are almost always confusing to readers. Invisible comments are only helpful to editors if it is probable that Wikidata does not have multiple entities conflated with the same index and multiple indicies covering the same entity, which is, at best, not proven. — Arthur Rubin (talk) 05:35, 4 June 2018 (UTC)

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

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

Overlaps with another RFC

  • Please note - This RFC overlaps somewhat with another that is still ongoing (see Wikipedia:Wikidata/2018 Infobox RfC). I do not believe that there is any intentional forum shopping involved... but we do need people to know that similar questions are being discussed elsewhere. Blueboar (talk) 15:01, 10 May 2018 (UTC)
Thank for letting me know about this, I will add a statement above to clarify the proposal will not apply to infoboxes since that is being decided elsewhere.--Rusf10 (talk) 16:07, 10 May 2018 (UTC)
Fair enough. However, please note that the other RFC has grown beyond just discussing infoboxes. It may be better to put this discussion “on hold”... Until we see how the other closes. Blueboar (talk) 16:36, 10 May 2018 (UTC)
Disagree strongly. This RfC is straightforward and already looking like a WP:SNOWBALL. That other RfC is a sprawling mess of 1A, 3C, etc. options, from which obviously no consensus is going to emerge, other than possibly the one that points in the same direction this RfC is going. Virtually every single answer there conflicts with ever other answer, except that multiple respondents are arriving at the most-restrictive option (1A+2A+3A+4A). It's a textbook example of why to not structure RfCs that way. Ask one question, then do another RfC to ask another question. Also, as I commented over there, the excessively geeky structure and wording of that RfC basically makes it invalid: it's heavily skewed toward the input of IT professionals (few who are not in that camp will be able to parse it), and they have a strong bias in favor of data centralization and automation.  — SMcCandlish ¢ 😼  10:27, 18 May 2018 (UTC)
I do not see it is straightforward, since different users are clearly addressing different issues, and the RfC question has been amended already during the RfC. I opened a proposal below to close it as invalid.--Ymblanter (talk) 20:19, 18 May 2018 (UTC)
That's not true! Since the day the RFC opened the question has been "Should wikidata be linked to in the body of the article?" as it is now. Stop trying to mislead people, just so you can shut down debate and get your way.--Rusf10 (talk) 20:30, 18 May 2018 (UTC)
No closer would shut this down as "invalid", because the course emerging is clear, as is the question, and that course matches the one at the other RfC (see the analysis I posted at bottom over there, to counter some similar snow-jobbing that was going on). The two discussions are in close synchrony. And whether some commenters choose to raise additional related issues that occur to them has nothing to do with the validity of an RfC; show me any RfC where this doesn't happen. What this all really comes down to: We all want WikiData to work, but the WD editors and their promoters on en.WP (to the extent they're not the exact same people, which may be 0%) have to do the work on the WD side to enable en.WP to filter WD data for en.WP policy compliance (and so on for other sites), or we simply can't use it, any more than we'd copy-paste content from any other website just because it was open-licensed, without also verifying the content and being able to control is appearance here. We'd never inline anything from another site where random people can change it and thereby instantly change what appears on Wikipedia, unless we can some way to control, undo, be alerted, etc. Even then it's a really, really iffy idea. The fact that WD in particular has received some WMF money doesn't change that. They fund all kinds of things that aren't pipelined directly through en.WP into readers eyes and brains.  — SMcCandlish ¢ 😼  23:28, 18 May 2018 (UTC)
SMcCandlish, what you write demonstrates very clearly that the two of us, to start with, understand the question of this RfC very differently. For me, it has nothing to do with the reliability of Wikidata (whereas another one does). The RfC does not define what "links" mean. It does not specify what is its scope - are templates which are not infoboxes included? Are hidden comments included? Nobody directly links to Wikidata now in the articles (with the exception I guess the article Wikidata). It is pretty clear from the comments of the !voters that they understand the scope differently. The RfC was not properly prepared. And the RfC with an unclear scope must be, well, closed as invalid.--Ymblanter (talk) 05:32, 19 May 2018 (UTC)
None of that is a problem we're unfamiliar with or incapable of dealing with. Many RfCs involve later detail clarification and hashing-out. RfCs are not legalistic or robotic processes; they are calls for discussion. One discussion leads to another. We do not try to shut down discussions, unless they are disruptive for some reason. The more detailed RfC covers, well, the details. This more general RfC takes an overall pulse, and it's beating with the same heart as the leading cluster of responses to the more detailed RfC. This one demonstrates (in being neither dominated by WD boosters nor mired in complex details only understood by entrenched WD boosters and WD critics) that the consensus emerging at that one (despite the cluster of WD fans gathered there) isn't false. Next, when different respondents have differing but compatible and rational reasons for arriving at the same conclusion, this makes the conclusion stronger, not weaker. The fact that one person cares more about data verifiability (over time, not just once), while another cares about editorial complexity and confusion, and another about something else, doesn't invalidate anything at all. Any proposal can raise multiple concerns. If this RfC isn't limited to infoboxes, then it isn't. It's also clearly about pulling data directly from WD; so, no, it's not about HTML comments. We might end up not needing those, depending on how and if WD integration into en.WP proceeds, and how WD evolves to deal with the core policy problems being raised at multiple other sites. But for now, I've agreed with you that trying to expunge Q numbers in HTML comments is overkill and even a net negative.  — SMcCandlish ¢ 😼  12:47, 20 May 2018 (UTC)

Proposal to close

Since the RfC so badly formulated that the participants do not really understand what is exactly asked, and one week after it was open new proposals appear (which are not reflected in the past votes), and the proposer says that they are thinking about adding new options, I propose to close this RfC as invalid. Any user in good standing can open a new one, formulating the options clearly and not changing them as the RfC runs its course. I would have also suggested to topic-ban Rusf10 from opening new RfCs about Wikidata, since the previous one was a disaster and this one is going to be a disaster, but this is clearly not an appropriate forum for such a proposal.--Ymblanter (talk) 20:17, 18 May 2018 (UTC)

@Ymblanter:Please strike your comment. You are making false statements. I have not changed any of the RFC options since the day the RFC opened. The only thing I changed on the second day was to add a note clarifying that the proposal would not apply to infoboxes since that is being determined elsewhere (and if you want to see a really bad RFC, take a look at that one). Also, where did I say I was "thinking about adding new options"? because I have not. The suggestion of a topic ban is uncalled for as I've done nothing wrong here. If you really want to pursue it though, I dare you. Wait until you see how quickly that will get shot down. The only reason the past RFC was a disaster is because your friend RAN worded the RFC options in a way to make the proposal more extreme so it would not pass. You obviously just want to shut down debate because the RFC is not going your way.--Rusf10 (talk) 20:27, 18 May 2018 (UTC)
4. The rest of your comment are baseless personal attacks. RAN is not "my friend", it is still not clear whether the proposal covers for example {{commonscat}} and other similar cases (and it is too late to clarify ot now), and I am not going to strike anything. It is up to administrators to listen or to not listen to my opinion in this section.--Ymblanter (talk) 20:41, 18 May 2018 (UTC)
People appear to be confusing a clickable link with a hidden annotation. There is no clickable link that Rusf10 is removing, he is removing hidden Wikidata Q-id annotations such as <!--Q1234567-->. They are used to properly disambiguate people that do not have Wikipedia articles, but have a Wikidata entry with more information on them. The annotation is only visible to someone editing the article. They let a future editor know that the person in the table of "Mayors of X" is the same guy appearing in the article on "X Township" and the article on "X Cemetery" and that the person has a photo in Wikimedia Commons. It lets a future editor know that the James Smith in one article is the same as the Jimmy Smith in another article and same person as the James Smith named in a quote in another article. People also seem to be confused about the !vote, it is not a binary support/oppose !vote. They are writing "support" without choosing one of the five mutually exclusive options, it is not clear what they are supporting. --RAN (talk) 20:46, 18 May 2018 (UTC)
Interpersonal venting aside, yes, the HTML-comment annotations should not be deleted since they're harmless, serve a useful function, don't cloud the code very much, and are invisible to readers. It would probably be preferable if there were another way to do it. Maybe the system being worked on to shunt CSS code for pages, and various metadata for templates, into special subpages could also be adapted to this purpose. I'm not really clear on the details of that work, and haven't looked into it all in months, so someone else should who understands it better can probably chime in about whether that's feasible.  — SMcCandlish ¢ 😼  23:31, 18 May 2018 (UTC)
@Ymblanter: How does 5 change anything? my comment there is consistent with my original position that I support banning all wikidata links within the body of an article (including ILL). The rest of your comment are baseless personal attacks. Actually, it is a response to your personal attack. RAN is not "my friend" Good, at least we have something in common. it is still not clear whether the proposal covers for example {{commonscat}} and other similar cases (and it is too late to clarify ot now) It does not apply, the RFC is already clear that it applies only to the body of the article, of which categories are not a part of. and I am not going to strike anything. It is up to administrators to listen or to not listen to my opinion in this section. You are entitled to your own opinion, but if you are going to continue to make up facts (ie. the question has been changed or that I am thinking of changing the options), I will call you out on it.--Rusf10 (talk) 00:49, 19 May 2018 (UTC)
Call me out on what? On that you have opened a second RfC with an unclear scope? Is it exclusively about {{ill}}? Then it should have been in the RfC question, and it is not. If it is about anythong else, it should have been in the question. Nobody is linking the Wikidata from the body of the article directly. You opened another "Wikidata vs anti-Wikidata" shitstorm, and the result of the storm will be nothing because you could not even define the question properly.--Ymblanter (talk) 05:36, 19 May 2018 (UTC)
The RFC is crystal clear, it is about linking to wikidata in the body of the article. RFC questions are supposed to be short and simple, not complex. (read WP:RFC if you don't believe me)"Nobody is linking the Wikidata from the body of the article directly." You could not be more wrong! Go back and read the first RFC, that is what caused this issue to begin with. RAN was adding direct links to wikidata in the body of articles and insisting that he could do so because there was no rule specifically banning him from doing so. The reason the last RFC didn't work was RAN (not me) worded the position as "never link to wikidata" in hopes of getting more opposition and keeping the status quo (ie. there is no rule, so he can do whatever he wants). Now you're trying to paint this RFC as flawed, so debate can be shut down and nothing changes. Your obstructionist behavior, is not helping your cause. In both this RFC and the previous one, it has been clear that the consensus is wikidata has problems and its use must be limited. The only question is how exactly do we want to limit it? Its clear something need to be changed, so do you want to be part of the problem or the solution? I took the position that at least in the body of the article wikidata shouldn't be used at all (at least for now). If in the future, some major improvements are made to the reliability of wikidata, then we can revisit the best way to use it within articles. But if there are any really good uses of wikidata within the body of the article I'd like to hear about them. Although, I am not changing my vote as of now, I could certainly live with SMcCandlish's proposal. --Rusf10 (talk) 06:38, 19 May 2018 (UTC)
Again, the example you have given is linking to Wikidata next to a redlink which can not be a valid article. Red links which can not become valid articles are not allowed. Period. We do not need an RfC to establish this. Concerning possible Wikidata links next to valid redlinks, this has whatsoever no relation to reliability of Wikidata, because the function of such a link (which is next to a redlink) is not to provide information, but to facilitate future linking. If a Wikidata has an item about X, it stays forever an item about X, even if it gets vandalized or sourced to unreliable sources. If someone links to Wikidata from the body of the articles (not in templates), and these links are unrelated to Wikipedia redlinks, I would like to see an example. Instead, we have the whole rant again "Wikidata is not reliable, OMG". Just because of the way you formulated the question and because you did not care to discuss it with anybody before running it live. This is why we have supports which are actually opposes, and opposes which are actually supports.--Ymblanter (talk) 06:53, 19 May 2018 (UTC)
And please stop telling me such as "your cause" and "your case". My cause is to improve Wikimedia projects, including the English Wikipedia. I have been doing it for years, and I am currently one of 500 most active editors here of all times. If you believe I have a double agenda pls go to ANI, but stop saying it here.--Ymblanter (talk) 06:56, 19 May 2018 (UTC)
Zdroj:https://en.wikipedia.org?pojem=Wikipedia_talk:Manual_of_Style/Archive_204
Text je dostupný za podmienok Creative Commons Attribution/Share-Alike License 3.0 Unported; prípadne za ďalších podmienok. Podrobnejšie informácie nájdete na stránke Podmienky použitia.






Text je dostupný za podmienok Creative Commons Attribution/Share-Alike License 3.0 Unported; prípadne za ďalších podmienok.
Podrobnejšie informácie nájdete na stránke Podmienky použitia.

Your browser doesn’t support the object tag.

www.astronomia.sk | www.biologia.sk | www.botanika.sk | www.dejiny.sk | www.economy.sk | www.elektrotechnika.sk | www.estetika.sk | www.farmakologia.sk | www.filozofia.sk | Fyzika | www.futurologia.sk | www.genetika.sk | www.chemia.sk | www.lingvistika.sk | www.politologia.sk | www.psychologia.sk | www.sexuologia.sk | www.sociologia.sk | www.veda.sk I www.zoologia.sk