Wikipedia talk:Manual of Style

Should South Africa articles use "continental system" numbers?

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

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

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

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

Interesting. This should be re-examined. I'm skeptical that modern screen readers have an issue with  ; if they do, then there are other places in MoS where it's recommended and needs to be replaced with a template that's kerning with CSS instead.  — SMcCandlish ☏ ¢ 😼  03:35, 4 February 2018 (UTC)

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

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

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

No way. Why do we even support the comma=gaps options? Dicklyon (talk) 03:43, 4 February 2018 (UTC)

As a compromise between mathematical purists who would prefer not to have any separators at all because they're not a meaningful part of the number, and editors who think that numbers are more readable when broken into smaller groups of digits? (I'm in the former group.) On the other hand, if "no way" is a response to the question of whether we should use this weird South African format, I agree. —David Eppstein (talk) 04:15, 4 February 2018 (UTC)

South African articles should use 12,345.6, unless they are specifically about a mathematical or technical topic (which should be rare). Kaldari (talk) 06:23, 11 February 2018 (UTC)

RfC: Linking to wikidata

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

---

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

---

• Such links strikes me as a bad idea for multiple reasons:
  1. WikiData doesn't comply with en.WP's WP:Biographies of living people policy or our core content policies.
  2. Wikidata is not prose, so doing this is going to sharply transgress the principle of least surprise, and the reader may really have no idea what's happening at all.
  3. This isn't like linking to Wiktionary for WP:DICDEF material; that's linking to a sister project for material that should not be on Wikipedia at all because of what kind of material it is. Bios do not constitute such material.
  4. If a subject is arguably notable and should have an article here, it should be a redlink. If it's not, it should not be linked at all.
  5. It's WP:GAMING the system to keep promoting non-notable subjects.
      — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:02, 15 January 2018 (UTC)
• I agree with SMcCandlish here. I followed the wikidata links and my first thought was that this is a very elaborate and space-consuming way of presenting absolutely no information whatsoever. I think these links are a terrible idea. Reyk _YO! 14:06, 15 January 2018 (UTC)

How can a database of information contain "absolutely no information" unless it is an empty record, which this entry is not? --RAN (talk) 20:46, 16 January 2018 (UTC)

• I would consider indeed to revert this completely. I already shiver when a person who fails our local inclusion standards, but is notable for e.g. Spanish is cross-wiki linked to the Spanish article (which is rather difficult to see even). I see this as nothing short of an inline external link to the website or social media account of non-notable subjects. We could consider an EditFilter for this, at least to detect such cases. --Dirk Beetstra ^{T C} 14:08, 15 January 2018 (UTC)

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

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

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

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

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

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

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

• Which Karl Wagner? Karl Edward Wagner (1945–1994), American writer of fantasy stories

Karl Wagner (bobsleigh) (born 1907), Austrian bobsledder who competed in the early 1950s Karl Wagner (luger), German luger who competed in the 1920s Karl Willy Wagner (1883–1953), German pioneer in the theory of electronic filters?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You do realize that there is a template {{Unreferenced}} in the English Wikipedia that is posted in over 5,000 articles. I stopped at 10 pages of 500. There are over 10,000 paragraphs in biographies of living people with no reference and there are over 10,000 dates of birth in biographies of living people that are unreferenced. I stopped the search at 10K, you can run it longer. "Unreferenced at this point in time" is not the same as "inherently unreferencable". --RAN (talk) 22:18, 19 January 2018 (UTC)

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

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

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

It would be possible to create a redirect for every person that's mentioned in a Wikipedia article and let that point to that Wikipedia article but I'm not sure that's a clean solution either. If a person is only mentioned on two pages and on one of those pages there's a link to a redirect to the same page, that feels more like an hack. ChristianKl ❪✉❫ 17:25, 16 January 2018 (UTC)

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

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

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

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

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

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

Francis Schonken, yeah - like that would be an example use case. And Fram, setting aside your hyperbole, the value of having wikidata links in this kind of circumstance (list of items where not every item will/does have a WP article) is to give readers access to more, relevant, information about the subject than could be appropriately added within the context of the given table. It is easy to find a relatively empty item to point to as proof that no such links should be added. Equally, it would be easy to find a high quality item to 'prove' the reverse. The point of these links in tables is that we can give our readers access to further free-licensed information in a structure that we can control (as opposed to external links). We can ALSO, when we desire, add a column for external links, references, other authority-control numbers if applicable, and in such cases it would be possible to move a WD item reference to that column in addition/replacement to the external. That would need to be seen on a case by case or article by article basis. In the mean time, having an unobtrusive WD icon (instead of its WD Q-number) is a convenient way to indicate to readers that more information exists and STILL leaves open the possibility of the words in WP being red-linked, blue-linked, or not linked at all. Wittylama 15:58, 16 January 2018 (UTC)

I'd avoid doing that with a flag-like icon though, it seems too counter-intuitive. E.g. at the Mayors of Teaneck, New Jersey page: what club does this gentleman belong to?... this red-green-blue striped flag is not the icon of a political party I know. --Francis Schonken (talk) 17:22, 16 January 2018 (UTC)

Anyhow, I listed the template for deletion, see the template's entry on the Templates for discussion page. Don't think this kind of WP:EGG flag link is something we should be doing. --Francis Schonken (talk) 21:04, 16 January 2018 (UTC)

I find it premature to list a template for deletion that pertains precisely to the discussion being held here in this subsection: about the use of WD links within tables - clearly one outcome will prejudice the other. If you have an alternative image/icon to propose, go ahead, but the WD icon is standard visual iconography across our sister websites - unless we want to treat en.wp as a special exception (like we do with the Wiktionary logo). Wittylama 10:31, 17 January 2018 (UTC)

Never link to Wikidata

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

  Could you please explain what do you mean to "start over"? Start what over? If all links to Wikidata get banned (which is what you just supported), there is nothing to start anymore.--Ymblanter (talk) 15:18, 16 January 2018 (UTC)

  Across hundreds of discussions, it's become clear that opinions and positions have solidified into two or more camps that are intent on warring with and defeating all opposing camps. This isn't the way to construct a workable, shared community; it's the path to degrading and demeaning the people and policies of an existing community (such as it is, with all its flaws). I'm not psychic and I can't predict if there is some less intrusive plan for how to integrate Wikidata into Wikipedia that would respect Wikipedia's policies and ultimately work for everyone involved, but I hope there is. I feel your pain, and I'm not happy that it's come to this. I only know that being realistic and honest about how we've failed so far is the only way forward. - Dank (push to talk) 15:50, 16 January 2018 (UTC)

  I do not have any pain, I am not heavily using Wikidata in my English Wikipedia activities, and as a Wikidata user we have a number of projects actually quite happy with Wikidata such as Wikivoyage or external users. It is just my point, which I tried to get across below but only got personal attacks so far, is that the only way data could propagate from Wikidata to the English Wikipedia is that the Wikipedia users must find some way of filtering acceptable data. Right now, for whatever reason, they expect that Wikidata would filter it for them. If the result of the RfC is "to ban Wikidata", these discussions are not going to happen, and there obviously will be no import in any form. This might be ok (at least one user stated he is quite comfortable using Google) but we all must be quite conscious what this outcome actually implies.--Ymblanter (talk) 16:02, 16 January 2018 (UTC)

  The same old invalid arguments get made over and over. The first few times, I'm thinking, maybe there's information I don't know, or maybe they misspoke by accident. I'm past that point now, and I think probably others are too, which is why this has turned into a battleground where people aren't responding to each others' points, just as you didn't respond to mine. But I'll respond to yours: an individual editor can easily get information from Wikidata into Wikipedia, by copying that information into Wikipedia and taking responsibility for their edit; there are also ways to automate edits at high speed, but again, the individual editor is taking responsibility for the edits, following established policies and cultural norms, or else they face the consequences. That's not what happens when information is imported from Wikidata without being held to Wikipedia's standards. And what's "obvious" to you, that the only possible outcome if this RfC passes is that everyone stops working on these problems, isn't obvious, or even likely. And no, my position isn't black-and-white, even though the RfC statement that we're voting on is black-and-white: that's how it works around here. "Support" comes closest to my position, so I'm supporting. I'm not hostile to Wikidata or to people who identify with Wikidata. I want to see successful integration. I want to see Wikidata people getting a better understanding of what it means to be a Wikipedian, and learning more about our policies. I want to see higher quality discussions on these topics. Over the past year, it's been a solid wave of IDHT, across a wide variety of topics. If we can't start from a place of honesty and shared values, then there's no point in even discussing integration. - Dank (push to talk) 17:31, 16 January 2018 (UTC)

  I have no issues with you supporting, I just found it strange that you think smth would "start over" if this RfC is closed as "ban". I now see what you mean, though I clearly disagree with you. Btw I do not think you responded to my point, not that I expected this. And, to be honest, most of the "Wikidata people" you are referring to are established Wikipedia editors. If you are specifically addressing me, I am here for 11 years and have made 105K edits, most of them in the articles.--Ymblanter (talk) 17:40, 16 January 2018 (UTC)

• Oppose blanket ban. Can clearly sometimes be useful with {{Ill}} to identify which of various people with a particular name a redlink refers to, especially if the entry ties that identity to unique identifiers in multiple reputable biographical databases, eg VIAF, ULAN, RKD, Library of Congress etc etc. That's a useful form of clarification. Jheald (talk) 14:35, 16 January 2018 (UTC)
• Oppose Though we should be distinguishing between different types of links (like we do with other Wikimedia projects), wholesale removal of these links seems counterproductive: we should be pointing people to any reasonable information about them... Wikidata is one of those places. Sadads (talk) 14:35, 16 January 2018 (UTC)
• Comment - This subsection could use some clarification at the top. Surely it doesn't actually mean Wikipedia should never link to Wikidata, as we have handy links in the sidebar that don't create many of the problems people have listed. It's worth mentioning that this, as I understand it, is specifically about linking to Wikidata via links in the body and/or external links section of an article. If that's the case, then I've yet to see a compelling reason to do so, but at the same time I'm reluctant to support a "never". — Rhododendrites ^talk \\ 14:37, 16 January 2018 (UTC)

  Note that there are a few more cases, such as for example {{Commons category}}, which will have to stop retrieving data from Wikidata if this proposal succeeds.--Ymblanter (talk) 14:44, 16 January 2018 (UTC)

  @Ymblanter and Rhododendrites: The problem is this isn't a proposal. This is a sentiment that has ballooned into a poorly constructed "vote." -- Fuzheado | Talk 16:12, 16 January 2018 (UTC)

  This is clear, but I do not see any procedural way to stop this, and most supporters are clear that they support the blanket prohibition with a possible exception of interlanguage links.--Ymblanter (talk) 16:16, 16 January 2018 (UTC)

• Oppose. Absolutely absurd to hold Wikidata to a higher standard than any other website linked to by Wikipedia, other Wikimedia projects like Commons and Wiktionary, or Wikipedia itself. Gamaliel (talk) 15:17, 16 January 2018 (UTC)

This seems (or atleast started about) to be about body links to wikidata; we do not allow external links in the body. Galobtter (pingó mió) 18:35, 16 January 2018 (UTC)

we do not allow external links in the body. - Except when we link to Wikitionary, or Wikisource, you mean? Diego (talk) 19:08, 16 January 2018 (UTC)

• Oppose and Protest this badly formed RfC. This so-called Request for Comment was a casual question that started with "I don't know much about wikidata." And now we're voting support/oppose on a global policy in English Wikipedia that would effectively ban linking forever? No way. -- Fuzheado | Talk 15:55, 16 January 2018 (UTC)

@Fuzheado, Rhododendrites, Pigsonthewing, Guerillero, Galobtter, and Mike Peel:- I wrote the question at the beginning to get some feedback but I did not create the RFC. The RFC was created by User:Richard Arthur Norton (1958- ) in a way that was designed to skew the results. The issue should be whether or not we can link to wikidata in the body of the article, not never link to wikidata.--Rusf10 (talk) 18:43, 16 January 2018 (UTC)

• You can't read minds so please AGF and do not write that my motive "designed to skew the results". You took four people's opinions in 24 hours and began removing links. A formal RFC runs for 30 days. --RAN (talk) 19:38, 16 January 2018 (UTC)

I know; The RfC tag should be in the "Never link to Wikidata" section as the neutral statement and should be limited to linking in the body. Galobtter (pingó mió) 18:47, 16 January 2018 (UTC)

#Link to Wikidata in existing tables if they are not getting an article should remain part of the RfC imho: this part of the RfC would become more important again if the #Never link to Wikidata part would fail to find consensus one way or another. --Francis Schonken (talk) 18:59, 16 January 2018 (UTC)

• Oppose this non-neutrally worded and ill-conceived RfC, per Andrew Lih and others. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:59, 16 January 2018 (UTC)
• Support for the *style* issue, based on WP:EGG (which is guidance found on another manual of style page): clicking a bluelink in the body of a mainspace page (article), and getting somewhere outside Wikipedia is a WP:EGG problem and we should avoid it. *Transclusion* or other invisible/unclickable links are not a style issue: they are content issues, and thus fall outside the remit of the Manual of Style discussion page. Links that clearly identify themselves as external (e.g. by being in an EL section) or as going to Wikidata (e.g. when the {{ill}} template is correctly applied) are not problematic for style guidance such as WP:EGG afaik. --Francis Schonken (talk) 16:48, 16 January 2018 (UTC)
  • Modified to broader support: I do think "(Wikidata)" appearing mid-text or in a table or list to be bad style: Wikidata is not a household name (yet) like most two- or three-letter abbreviations for languages are, so the "Wikidata" term appearing with a link in the body of an article would still be more confusing to the average reader than most other usages of the {{ill}} template. --Francis Schonken (talk) 13:27, 22 January 2018 (UTC)
• Oppose Could you have a more non-neutrally worded RFC? I can't roll my eyes enough at the idea that we should never link to a sister project --Guerillero | Parlez Moi 16:51, 16 January 2018 (UTC)
• Oppose per Sadads, Fuzheado, Gamaliel, Guerillero, and others. --Rosiestep (talk) 17:00, 16 January 2018 (UTC)
• Oppose per many people above. There's a big disconnect between the initial question and the headers here, so the original requester may want to pull this RfC and try again with the narrower question. In the general case, those objecting to them could always create the missing Wikipedia articles/redirects and link to those instead (where notable)... BTW, are we supposed to !vote in the section above as well? Thanks. Mike Peel (talk) 18:25, 16 January 2018 (UTC)

• @Mike Peel: The cases with which this discussion opened - which may not even matter since we've gotten so far off that topic, but FWIW - were where the articles had been deleted at AFD, and links to Wikidata were added instead. In such cases, creating the article is not a good solution, unless the reason for deletion could be addressed. Nikkimaria (talk) 18:36, 16 January 2018 (UTC)

  In the case of AfD, policy is very clear. In other cases, Mike's suggestion is workable. --Guerillero | Parlez Moi 19:01, 16 January 2018 (UTC)

• Yes, AfD policy via ATD is clear, but because administrators are not requiring policy-based !votes, we get the dysfunction in which redirects that wouldn't be deleted at WP:RfD, are deleted without due process at AfD.  Unscintillating (talk) 21:56, 16 January 2018 (UTC)

• This RfC really needs clarification. Galobtter (pingó mió) 18:35, 16 January 2018 (UTC)
• Oppose per Yaroslav, Andrew, and Guerillero specifically. mahir256 (talk) 19:06, 16 January 2018 (UTC)
• Oppose and speedy close as patent nonsense and per snowball, per Ymblanter, Fuzheado, and Guerillero — OwenBlacker (talk; please {{ping}} me in replies) 20:22, 16 January 2018 (UTC)
• Oppose I see no reasons mentioned except for the ignorance and stubbornness regarding the Wikidata (like that it does not contain useful information) or unrelated arguments (like that Wikidata can be vandalized or that users don't like the way information from there is presented in the article)--Ilya (talk) 21:12, 16 January 2018 (UTC)
• Oppose  I'd never looked at Wikidata until about an hour ago, but fail to see why I should be able to link to articles on de.wikipedia.org, which does not support our policies; and add links to wiktionary, but not wikidata.  Unscintillating (talk) 22:03, 16 January 2018 (UTC)
• Oppose. Without addressing the specific merits of this case, procedurally, a blanket ban on linking to a sister project needs a better formatted and advertised RFC. ---- Patar knight - ^chat/_{contributions} 22:50, 16 January 2018 (UTC)
• Support. Interwiki links served up on the left sidebar are fine. Replacing red links in articles with links to Wikidata is not good. Wikidata is a free, collaborative, multilingual, secondary database, collecting structured data to provide support for Wikipedia, Wikimedia Commons, the other wikis of the Wikimedia movement, and to anyone in the world. Right, it's a secondary database. Secondary databases obtain data from primary databases; they don't deliver secondary data to primary databases. That's the equivalent of "citogenesis". Here's how Wikidata can use its structured data to provide support for Wikipedia: I want Wikidata to tell me when "the birthdate of John Doe in English Wikipedia is not consistent with his birthdate in the French, Spanish and German Wikis. When the place of birth of Jane Doe in English Wikipedia is different than Jan Doe's birthplace in the Portuguese, Japanese and Russian Wikis. Flag these for human, or bot attention. Wikidata can be useful as a quality-control vehicle. Its data elements could have a measure of confidence. When there is universal agreement on the value of a particular data item from a large number of independent wikis, then there is high confidence in the item's accuracy. When there is disagreement, the level of confidence is lower. This is needed support to ensure higher quality of a reference that anyone can edit. – wbm1058 (talk) 04:39, 17 January 2018 (UTC)
• Oppose. I'm okay with the idea of "no links to Wikidata in prose from the article space", but the way the question is worded is vague and could potentially be interpreted to mean no use of Wikidata at all, which I most certainly do oppose. Lankiveil ^{(speak to me)} 11:00, 17 January 2018 (UTC).
• Oppose procedurally, and also on the grounds that Wikidata links are better than nothing. As above I would support only linking to the interwiki links sections on Wikidata items, since Wikidata is a developing project, concerns about unsourced content etc. Do we also have to ban linking to articles (in other Wikipedias, and/or this Wikipedia) with {{unreferenced}}? (Note that Wikidata currently has an open RfC on privacy and living people.) Jc86035 (talk) 12:22, 17 January 2018 (UTC)
• Oppose. Perhaps if this were phrased differently and didn't give the impression of banning Wikidata everywhere ("[...] we should not link to it. At all."), I might be able to support this. I disagree with the idea of prose Wikidata links, but this may set a precedent for other interwiki links (and Wiktionary/etc can be useful some times). Anarchyte (work | talk) 12:35, 17 January 2018 (UTC)
• Support principle, oppose RFC statement. I quite agree that these WD links should not be in article text - but I thought we already had a long-established consensus to avoid, say, inline links to Spanish Wikipedia articles in the middle of sentences? Surely all we need to do is to formalise that existing position with a mention of WD - "Links to entries in other language Wikipedias or Wikidata items should not be used in running article text", put it in the MoS list of links to avoid, and we're done.

But titling the RFC position "Never link to Wikidata" seems to be just asking for trouble - in a year or two some people will look back at that header and choose to interpret it as an RFC on ever crosslinking to Wikidata, whatever the context, even if most commenters here are considering the inline links issue. That won't help anyone and will simply serve to entrench further conflict. I don't think it was deliberately intended that way, but as written it's playing into some very established community rifts (as Dank notes above), and we should try and avoid encouraging that. Andrew Gray (talk) 13:12, 17 January 2018 (UTC)

• Support Wikidata is a slow cancer eating away at WP. Lugnuts ^{Fire Walk with Me} 18:26, 17 January 2018 (UTC)
• Support. Wikidata can be used to host original research and unsourced claims, and allow such faulty information which cannot come in by the front door, instead enter by the back door. If there are valuable data missing from an article, it should come in only if properly sourced and added directly. And as to the assertion that something is better than nothing: No. It is not. Better to have no assertion than one based on faulty information or personal opinion. We do not need to compound errors by repeating them. Kablammo (talk) 19:03, 17 January 2018 (UTC)
• Support per my comments here. ‑ Iridescent 19:17, 17 January 2018 (UTC)
• Support per numerous editors above pointing out the dangers of such links more calmly than I can. Yngvadottir (talk) 22:30, 17 January 2018 (UTC)
• Support. Wikidata is a deeply flawed turd in the project, with too much unsupported information to be safe to use. - SchroCat (talk) 23:18, 17 January 2018 (UTC)
• Support. Wikidata should be clearly identified as an unreliable source and never ever used for anything on WP. It is absolute rubbish.Smeat75 (talk) 00:56, 18 January 2018 (UTC)
• Support - I'm very wary of Wikidata and the information it hosts, and until further notice I think its best to keep it away from this project. -Indy beetle (talk) 03:59, 18 January 2018 (UTC)
• Oppose blanket ban. I'm not specifically defending the links at issue; I haven't looked into them. But I don't think it's a very good argument to say that if a subject doesn't pass WP:N, we can't have a link to it. The point of N, or at least part of the point, is to avoid cluttering the index space on en.wiki — too many articles make for excessive disambiguation and reduce the utility of completion in the search box. That's not really an issue with links. A WD link could help users find the right instance of a search term, which might be more difficult with a general web search. Side note: Isn't this RFC in the wrong place? It's not clear that it's a style issue. A lot of people are making arguments that seem to be more about general policy than style. --Trovatore (talk) 05:00, 18 January 2018 (UTC)
• Support not linking to Wikidata in prose in mainspace. This is purely from a "path of least astonishment" perspective. Does any reader expect to wind up on Wikidata when they click a link in mainspace? Of course not. Nor do they really want to end up on Wikidata. Wikidata is great for many things, but human readability is not one of them. ~ Rob₁₃^Talk 09:16, 18 January 2018 (UTC)
• Support per Jayron. ​—DoRD (talk)​ 12:23, 18 January 2018 (UTC)
• Oppose. It is absurd to have a policy on a Wikipedia edition that it shall blacklist another Wikimedia sister-project. Shall we refuse to link to Commons next? It's not like they don't have their own content problems after all, so the same 'their policies aren't compliant with our policies, and some of their content is bad quality' argument could be used against Commons too. Wittylama 13:16, 18 January 2018 (UTC)
  • ​Er, we almost never do link to Commons. The question being asked isn't "do we include links in the EL section as we currently do with Commons?", it's "do we include wikilink terms within the text of an article to their Wikidata entries?". ‑ Iridescent 15:51, 18 January 2018 (UTC)
    • Iridescent: There are other parts of this discussion which have somewhat more nuanced points (e.g. about usage in tables, or when there's a redlink, or within the prose), but THIS section of the discussion is voting on a blanket ban on ANY Wikidata links - the subject heading is literally "Never link to Wikidata". Wittylama 15:59, 18 January 2018 (UTC)
• Oppose. The solution proposed is not a proportionate response to the issue raised. We should deal with compatibility issues on a case-by-case basis, not reject entire Wikimedia projects where a significant amount of work is being done by long term Wikipedians with the goal of supporting Wikipedia. Battleofalma (talk) 16:00, 18 January 2018 (UTC)
• Oppose—Linking to Wikidata is smart and logical way of dealing with the fact that Wikipedia is not a directory and has higher standards of notability than Wikidata. Especially in cases where Wikipedia provides a table or list of people, entities, or places, connecting them to individual Wikidata entries is the appropriate way to archive factual information about those entities, while preventing them from cluttering up things here. (To take an example I worked on, the muncipal council members of Sucre should get Wikidata entries, but not Wikipedia pages.) Yes, Wikipedia and Wikidata have some different policies. In some cases Wikidata policies should be moved towards Wikipedia's (Verifiability, BLP), but not on this front. Less notable data should not be part of Wikipedia, but it should be linked so as to enrich our content here.--Carwil (talk) 16:16, 18 January 2018 (UTC)
• Oppose per WP:CREEP. Per WP:BOLD, we should never say never. Andrew D. (talk) 16:21, 18 January 2018 (UTC)
• Oppose: I am sure there are times when liking to WD would provide the reader with useful additional information to compliment what WP has to offer. Data-related stuff is not really in my area of knowledge, though. –Sb2001 19:53, 18 January 2018 (UTC)
• Oppose. WD is the only chance for WP to deal with certain very „dynamic“ data. Ziko (talk) 05:15, 19 January 2018 (UTC)
• Support Comment as the RfC is not sufficiently well worded. The links currently do not specify that they are to Wikidata per here which will confuse our readers / editors. We should not IMO be replacing what looks like links to articles here with WD links. Once this is fixed we can than discuss the uses that may be reasonable. These should be spelled out before implemented however. Doc James (talk · contribs · email) 11:02, 19 January 2018 (UTC)

  Looking at this issue further and links to all sister sites appear the same as internal Wikipedia links. Not sure if their is a phabrictor ticket to have this adjusted?

  And to clarify further we already have Wikidata links in the left sidebar of all our articles plus we have wikidata links in some infoboxes which we should keep. When WD links appear as external links that is also fine. Doc James (talk · contribs · email) 19:31, 19 January 2018 (UTC)

• Oppose blanket ban. Links to Wikidata should be used cautiously as with any other inline interwiki link. Deryck C. 18:11, 19 January 2018 (UTC)
• Oppose. I share a number of concerns about how Wikidata gets used in Wikipedia. (Indeed, I just generally have concerns about the level of sourcing on Wikidata). But banning links from en.wp to Wikidata isn't in the best interests of either project in the long term. The Land (talk) 19:41, 19 January 2018 (UTC)
• support. The sidebar link serves to link the article to its Wikidata page, so there is no need for any more in the body of the article. Linking to any other Wikidata page is an even worse idea; if the Wikidata page has a corresponding article then link to that if it makes sense. If there is no such article then a red link should be used, if appropriate. In neither case is linking to Wikidata better. Such would just confuse and frustrate readers, and disrupt the process of building the encyclopaedia that red links are part of.--JohnBlackburne^words_deeds 21:43, 19 January 2018 (UTC)

  @JohnBlackburne: I think the idea is in some cases to show a red-link and an icon or reduced-sized link to Wikidata, eg in a list of people, to clarify who the redlink is for, as identified in external databases. But not a replacement for red-links, and only to be used occasionally and with discretion. Jheald (talk) 22:02, 19 January 2018 (UTC)

  That still has two problems. First the link to Wikidata will still confuse and frustrate readers, given Wikidata’s current UI of a badly formatted multilingual database. Second it encourages editors to create redlinks for the wrong reasons. Currently a redlink means someone thinks it could be an article. But if they are associated with Wikidata links then editors will add red links not because there might one day be an article, but because there is a Wikidata item and they want to link to it.--JohnBlackburne^words_deeds 00:57, 20 January 2018 (UTC)

• Oppose this overly broad proposal. Enterprisey (talk!) 09:09, 20 January 2018 (UTC)
• Comment the formatting of this RFC is leading an ambiguous outcome, the RFC question is about not linking to Wikidata in the body of the text, but the heading of this section is Never link to Wikidata. Comments from people supporting this RFC suggest that some people think they are voting for an overall ban of Wikidata linking on English Wikipedia and some people think they are voting on not having links within articles. One way to remove this ambiguity is to change the subsection heading from Never link to Wikidata to a concise statement that summarises the RFC statement. John Cummings (talk) 10:12, 20 January 2018 (UTC)

We cannot use Wikidata as a source in English Wikipedia, just as we cannot use Wikipedia or other user-generated sites. It is one think to have a link in the left sidebar; but another thing entirely to use Wikidata in Wikipedia infoboxes or any other part of the article. Our standards for reliable sources do not allow that. Kablammo (talk) 16:11, 20 January 2018 (UTC)

Using Wikidata to disambiguate people who don't have their own Wikipedia articles isn't using Wikidata as a source. ChristianKl ❪✉❫ 23:03, 20 January 2018 (UTC)

You are confusing using Wikipedia/Wikidata as a source for a fact, and using it to identify someone uniquely. We link people to their names in other Wikipedia articles all the time, that is what a blue link is for. That is not using Wikipedia as a source for a fact. --RAN (talk) 15:00, 24 January 2018 (UTC)

• Oppose blanked ban. Links to wikidata should be ok least for the cases where target is clearly marked. Zache (talk) 10:16, 20 January 2018 (UTC)
• Support Wikidata's mission is admirable, but it's too nascent to reliably support en.Wikipedia with supplemental data. While sourcing has been improved (according to WMF), there's still a massive gulf between its current state and what I'd consider a reliably sourced data repository. I'm also concerned with Wikidata's reported use by PR professionals and SEO firms for their own ends. Widespread support on en.Wikipedia would only aid their efforts. While I'd like to see something like this adopted in the future, it's too soon to greenlight this practice. - GS ⋙ ☎ 06:07, 21 January 2018 (UTC)
• Support. Wikidata is uncurated and unreliable. It can be host incorrect perhaps defamatory BLP claims. Strong support for blanket ban to biographical links and links in BLPs per WP:BLPSOURCES. LK (talk) 00:55, 22 January 2018 (UTC)
• Support Wikidata is a wiki that anyone can edit. It is thus an unreliable source and cannot be used to support any content in article space. I support a bar from using Wikidata in article space. --Malcolmxl5 (talk) 14:17, 22 January 2018 (UTC)
• Support. Per JohnBlackburne and GrapefruitSculpin. Kaldari (talk) 21:43, 22 January 2018 (UTC)
• Poorly worded - I cannot support such generic statements without a clearer proposal. But I understand and can agree with parts of the sentiments expressed. You'll have to come up with something more nuanced to get my support though. effeietsanders 22:14, 22 January 2018 (UTC)
• Support for all the good reason above. Wikidata is fundamentally flawed and until its deep-seated problems are sorted out it should only be dealt with at arms length. - SchroCat (talk) 23:16, 22 January 2018 (UTC)
• Support. The status quo is intolerable. It's a continual disruptive battleground, with both sides throwing all their work down the toilet as enthusiasts roll wikidata forwards and critics roll it back. We either need to go full-on wikidata wherever it's usable, or not at all. Those are the stable outcomes. And if we go full-on wikidata, god help us. Per abundant arguments above, nuke it from space (i.e. phab rollback the wikidata commands that were added to wikitext). It's the only way to be sure. We can keep the left-sidebar wikidata interlanguage links. Alsee (talk) 17:57, 27 January 2018 (UTC)
• Support per SMcLandish's astute observations at the top of this, and others'. The principle of least surprise is the biggest one, and it's a HUGE fucking surprise to land on a page that is effectively not readable without a bunch of investigation into where you've landed, what it means, etc. Aureliano Babilonia (talk) 04:48, 28 January 2018 (UTC)
• Support per SMcCandlish. -- Tavix ^(talk) 22:05, 1 February 2018 (UTC)
• Oppose. Linking to an item in Wikidata provides a kind of informational anchor and a helpful starting point for readers who want to understand particular names or phrases in a Wikipedia article. Here is a recent example of how Wikidata linking improves a Wikipedia article: Budapest Open Access Initiative. -- Oa01 (talk) 09:43, 13 February 2018 (UTC)
• Support blanket ban on principle, but IMO this is not a "style" issue and should be enshrined at WP:ELNEVER. Hijiri 88 (聖やや) 09:52, 13 February 2018 (UTC)
• Support. It's not useful for a name in a list to offlink to WikiData in lieu of an internal Wikipedia article. The Wikidata link doesn't add any useful information above and beyond what was already gleaned from the list that the person's name was included in — and, in fact, a WikiData link for any given person will only exist if we formerly had a Wikipedia article but it got deleted. A Wikidata entry doesn't get created without the prior existence of a Wikipedia article on at least one language wikipedia, yet the deletion of the Wikidata entry does not automatically follow from the deletion of the article. The primary purpose of Wikidata is to assist with the authority control data and the crosslinking of Wikipedia articles in different languages. An entry in there isn't informative at all, and it's not a resource that people independently consult in its own right for information about people or things — it's just a technical tool to simplify some Wikipedia editing tasks, nothing more, so offlinking a former article topic to their ghost wikidata entry as a replacement for the deleted article isn't contributing anything useful to anybody's knowledge of anything. I'm not suggesting that it's useless, as it clearly does have some very useful purposes — but serving as an alternate body text link for a person or thing that doesn't have a Wikipedia article to link to is not one of those. Bearcat (talk) 21:32, 13 February 2018 (UTC)

• @Bearcat: Your point about the creation of Wikidata items is incorrect - it's quite possible for an item to exist without a Wikipedia article having existed previously. Items can be created which meet one of three criteria outlined at WD:N - one of those is a valid sitelink, but the other two don't rely on that. That's why, for example, Wikidata items exist for individual scientific articles which would never meet our notability policies. Nikkimaria (talk) 02:24, 14 February 2018 (UTC)

• The context for my comment was that when articles about smalltown mayors are deleted, certain people are inserting links to their ghost wikidata entries to the town's overall list of mayors as a replacement for the deleted redlink. I can't speak to wikidata items existing for scientific articles, because I don't work in that domain — in the contexts where I encounter Wikidata links being inserted directly into body text, the prior existence of a now-deleted Wikipedia article is how the Wikidata number came into existence. Bearcat (talk) 02:30, 14 February 2018 (UTC)

• Fair enough, just wanted to make clear that it would be possible to go create a Wikidata item on a small-town mayor without ever having an article here, deleted or no. Nikkimaria (talk) 02:41, 14 February 2018 (UTC)

• Oh, I realize that it's possible. It's just that nobody ever would, because in the absence of a Wikipedia article about the smalltown mayor there'd be no purpose to doing so. Bearcat (talk) 02:51, 14 February 2018 (UTC)

• Well, User:Bearcat, that is in a way what WikiData is supposed to be. If it is a fact that John Doe is the king of FarFarAway, then that is data that WikiData wants to capture. Their database could contain ALL US mayors for every imaginable town from start of time till now, with tenure, town, etc. WikiData does not exist only for use on other Wikipedia's, its purpose is to be a database. (and part of the problem is that people on WikiData would make those entries, because it is data they want to capture and to be used - and for some data is it (was) more important to capture it than to have it locked down as reliable - they have no clue that the John Doe that was the mayor in FarFarAway is the same John Doe that invented the light bulb - they may have two the same John Does in their database, or two independent John Does who are the same person - and one might not be able to discern them in some cases). --Dirk Beetstra ^{T C} 05:55, 14 February 2018 (UTC)

• How frightfully pointless. Still doesn't mean that a list of mayors in Wikipedia should be linking to their Wikidata entries as substitutes for Wikipedia articles, though. Bearcat (talk) 06:02, 14 February 2018 (UTC)

• Indeed. Knowing that it may take extensive work to link (or de-link) the two John Does from the two different lists of people, and that that is probably not extensively done by WikiData people (if it is even possible in some cases) that may result in significant BLP issues. Now, on the other hand, I don't know whether it is significant for en.wikipedia to know whether the Mayor John Doe mentioned in the town article is the same as the inventor John Doe that is mentioned in the light-bulb article. --Dirk Beetstra ^{T C} 07:28, 14 February 2018 (UTC)

• Re. "It's just that nobody ever would" – incorrect, and I can't stress this enough: e.g. this Q item was created yesterday at Wikidata, by an editor who is currently blocked at en.Wikipedia, without *any* article or item on *any* other Wikimedia project. By this indirect technique Wikidata has been used to smuggle topics that wouldn't pass WP:GNG into en.Wikipedia (just dig a bit deeper than I just did and you'll see that some of the recent successful AfDs had a similar origin, just absorbing editor time over and over with no net benefit to Wikipedia). --Francis Schonken (talk) 06:54, 14 February 2018 (UTC)

Discussion (linking to Wikidata RfC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No you have said Wikidata's stated purpose is not in fact its purpose. Unless you back it up with some evidence that's a false statement. Please provide the requested information as to what wikidata's true purpose is. Clearly with all your experience you should be able to satisfy a simple question as to what wikidata is for. Only in death does duty end (talk) 13:37, 16 January 2018 (UTC)

I do not feel I should be communicating with someone who (i) calls me a liar thus lying themselfves; (ii) on top of this have difficulties understanding elementary text.--Ymblanter (talk) 13:44, 16 January 2018 (UTC)

Right, I will take that as 'No I cant state wikidatas purpose'. Glad we are clear. Only in death does duty end (talk) 13:55, 16 January 2018 (UTC)

Ymblanter, Only In death is not the only editor wondering whether the purpose of Wikidata is compatible with Wikipedia’s purpose. so, while I respect your decision not to respond to his/her comments, I would appreciate an answer to the question... what IS the purpose of Wikidata? Blueboar (talk) 16:04, 16 January 2018 (UTC)

The link which I provided right below says Wikidata is a free, collaborative, multilingual, secondary database, collecting structured data to provide support for Wikipedia, Wikimedia Commons, the other wikis of the Wikimedia movement, and to anyone in the world.--Ymblanter (talk) 16:07, 16 January 2018 (UTC)

Taking this out because it was hatted: d:Wikidata:Introduction. With this, I better quit the discussion, since I was already claimed to say smth I did not say, and this is probably not going to stop.--Ymblanter (talk) 14:18, 16 January 2018 (UTC)

Losing focus here: please comment on content ("Wikidata"; "links"; "Wikidata and links") not on fellow editors. --Francis Schonken (talk) 14:10, 16 January 2018 (UTC)
The following discussion has been closed. Please do not modify it.
True that. Understanding elementary texts is a basic requirement. Correctly writing such texts apparently not though... Fram (talk) 13:50, 16 January 2018 (UTC) Yeah, pulling rank to win an argument seems like a concession of defeat to me. Reyk YO! 13:53, 16 January 2018 (UTC) Only in death, you seem to have misunderstood the discussion. Ymblanter is an admin, you are not, so you are wrong and lose. Arguments and evidence only count between people from the same class, but people from a lower caste should never doubt the correctness of the higher castes. Please stop wasting Ymblanter's time by offering arguments and the use of a brain. Be glad that they are magnaminous enough to grant you the right to an opinion; if you don't stop, I'll start an ANI discussion Tbanning you from having an opinion and directly addressing admins. Fram (talk) 13:48, 16 January 2018 (UTC) I'm not sure even ANI has (yet, despite some attempts in the past) tbanned someone for having an opinion... Expressing it yes ;) Only in death does duty end (talk) 13:55, 16 January 2018 (UTC) I see, you guys have chosen a nice tactics: First, to misinterpret what I said, second, accuse me in lying and throwing a bunch of personal attacks on me, and then stating that I should prove that I am not lying. May be I can then explode, and sure you would be happy to bring me to ANI, or may be even to Arbcom. However, this is not going to happen. Who is genuinely interested in the subject, can go to d:Wikidata:Introduction, and then discuss it there if you are unhappy. Here, I do not see much point. I tried to be polite, it did not work. This is unfortunate, but I am not going to start call people names.--Ymblanter (talk) 14:05, 16 January 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

That requires making the data available on the those language versions of Wikipedia that could be persuaded to take part. ϢereSpielChequers 13:50, 16 January 2018 (UTC)

Using Wikidata to identify entities unambiguously

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You've quoted (have you? I don't see it) that guideline - I did it here.

Main problem is that we send readers to a page which is not intended for readers. - Then you haven't understood my proposal, which was to remove direct links to WikiData; but keep the fact that two parts of text in our articles refer to the same Wikidata object.

This would be used for navigating between our articles, without ever leaving Wikipedia, just like wikilinks; but withour requiring directional links ("connect this article to that article), and for topics that are not notable. Navigation within Wikipedia is the main purpose of MOS:LINK.

Adding such metadata around terms makes editing harder, as it is more visual clutter one has to ignore, avoid, maintain, ... - Fair point; yet the amount of clutter is similar to that of reusing references within an article, so hardly unmanageable.

Wikidata is too often used as a way to avoid blocks, deletions, policies on enwiki - Can you please explain that? How is data on Wikidata misused to disrupt Wikipedia? Diego (talk) 13:48, 16 January 2018 (UTC)

I self-corrected my "have you?" question before your post here, but thanks for taking the time to point it out anyway. "This would be used for navigating between our articles, without ever leaving Wikipedia" how? Not by readers apparently, but how would editors use this to navigate from one article to another without leaving wikipedia? Even when you follow the link to Wikidata, you don't have the option of going back to other Wikipedia articles which link to the same item. The issue is not that the clutter would be unmanageable, everything is manageable, but that the cost/benefit ratio would be bad. We already have a lot of necessary clutter like refs, please don't add unnecessary clutter as well (the same goes for things like hidden categories, which on many articles have lost their usefulness completely now that they are swamped with cats generated by authorty control and other Wikidata stuff). As for the "Wikidata for avoidance of enwiki issues" RAN (the editor at the start of all this) is a good example. When he got into trouble here for a whole range of issues, he created Wikidata items instead, added Findagrave there, and then added links to his Wikidata items to articles here. Fram (talk) 13:57, 16 January 2018 (UTC)

Readers would be able to find connected articles by searching for the Wikidata item ID (maybe with Search, preferrably by building a tool that searched articles containing the tag with that ID). What count as unnecessary is ultimately subject to personal preference; I've stated my case of how the people writing WP:BUILD found the idea valuable, just like myself.

he created Wikidata items instead, added Findagrave there, and then added links to his Wikidata items to articles here. - Only the last part would be problematic for us. If we restrict ourselves to in-Wikipedia links and didn't expose readers to the link to Wikidata, that strategy wouldn't do much good. Diego (talk) 14:08, 16 January 2018 (UTC)

But the readers wouldn't see the Wikidata ID, if I understand you correctly. So how would they do this search? In any case, you find it worthwhile, I find it a lot of hassle for something that would be rarely if ever useful (with a redlink, you can already easily click it and then use "what links here", so your proposal would only potentially help for items where we have multiple subjects for one redlink, which all have a Wikidata item, and where all of them have that Wikidata item correctly added to their text entry). Fram (talk) 14:33, 16 January 2018 (UTC)

But redlinks should not be added to items that are not notable...

Not havink a link to Wikidata doesn't prevent us from having a small internal link to the search page, like those for refs or notes. Diego (talk) 15:26, 16 January 2018 (UTC)

Ah, I see what you mean. Again, this would add visual clutter to what the reader gets, which to me is not worth the end result. I can't imagine many readers having the question "in what other enwiki articles is this non-notable subject used as well", and considering that it would only be really useful if it was somewhat complete, I see a gargantuan effort for little positive result. A nice idea, but (as you probably guessed by now) not something I support. Fram (talk) 15:36, 16 January 2018 (UTC)

@Diego Moya: Overall, I think there's merit to the idea. The accusation of "Luddism" by YMBlanter is nonsense; this is about ability of en.Wikipedia articles to comply with en.Wikipedia policies, and not have them skirted by "offshoring" to other projects. If WD information is pulled into WP, then it can be made to comply here. I'm not sure how that gets done, e.g. the template suggestion below. However, this RfC/firehose has obviously turned into a mess almost overnight and is unlikely to result in a consensus on anything. I would suggest letting the battleground fall to silence and you can float this idea again, with some specifics later, and not here. This is a policy debate, not a style one.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  00:29, 17 January 2018 (UTC)

@Diego Moya: Perhaps you are aware of this, but at the moment, searching for Qnumbers used in enwiki through our search interface doesn't seem to work. Q6167205 is used in Mayor of Verona, New Jersey, but a search gives no results. Fram (talk) 07:49, 17 January 2018 (UTC)

Searching for insource:Q6167205 works, though. —David Eppstein (talk) 07:55, 17 January 2018 (UTC)

Interlanguage link template

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

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

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

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

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

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

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

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

I believe that you'll find that SISTER was first labeled as a part of the Manual of Style by a logged-out editor in October 2005, which predates my involvement rather significantly. WhatamIdoing (talk) 19:53, 17 January 2018 (UTC)

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

It would not be a misuse, since that's part of what the template is designed to do. If you see an item on Wikidata "no information", by all means nominate it for deletion there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:06, 16 January 2018 (UTC)

Why would we send anyone willingly to a page where the only external sources (given in general, not as specific references) are to Familysearch (I have no intention to register to a wiki from the Church of Latter Day Saints, thank you) and Rootsweb ("is currently unavailable")? Just because it is a sister site doesn't mean that it is an acceptable site. Fram (talk) 14:56, 16 January 2018 (UTC)

On the other hand, why would you object, if the links establishing identity were to eg VIAF, ULAN, RKD, Benezit, Library of Congress? The motion above aims to ban all links via {{Ill}}, without any scope for editorial judgment, no matter how well identified the entry is. That's WP:CREEP, and over-reach. Jheald (talk) 15:08, 16 January 2018 (UTC)

How's that WP:CREEP? Creep is "Instruction creep is often a result of editors producing too much instruction, resulting in very long, complicated pages. " Here a very simple rule is proposed. You are free to disagree with the proposal, but I don't think "creep" is a valid argument here. I oppose such links in general because I see way too many problems at Wikidata. This doesn't mean that no entries at Wikidata are good, but that not enough of those without an enwiki article are. I see the "it's a sister project, so we should link to it (or be allowed to link to it) as a non-argument, we are not here to promote other WMF projects, and certainly not ones which basically bring us everything we don't want in enwiki (sourcing, policies, lack of vandal fighting, ...). It would be better, if we want to provide readers useful pointers to outside sources for subjects without an enwiki article, to allow such links directly to a small number of reliable sources (like the LoC) instead. I am not really fond of that either, but it would at least be better than linking to Wikidata. Using an unreliable intermediary to direct readers at best to reliable sources is not something I support. Fram (talk) 15:25, 16 January 2018 (UTC)

Yeah, this is WP:CREEP. You're taking something that is currently a matter of editorial discretion, you want to take that discretion away, and in the process you want to one more to WP's ever more voluminous pile of rules. The fact you don't even recognise this for the WP:CREEP that it is makes it even worse.

Now, your claim: not enough of those without an enwiki article are [any good].

Let's see. Currently 549,004 entries without an en-wiki article, but with a VIAF identifier. (tinyurl.com/yb8xkcg4). None of them worth being able to distinguish? 200,459 with a Library of Congress ID (tinyurl.com/y7yq8lkk); 29,351 with a ULAN identifier (tinyurl.com/y8cglcao); 15,075 entries with an Art UK identifier but no article here. (tinyurl.com/y8f8xxjl)

Now let's look at some of those Art UK examples (ie painters with works in UK public collections). tinyurl.com/y9nwpttk. The top one (most likely to be referred to?) has links to entries no fewer than 32 different biographical databases. Even down at number 3200, we find the identity is backed by links to four different external databases.

Yet none of this you think is useful, not ever, to uniquely identify somebody in a list or a citation section that is the subject of a redlink? Jheald (talk) 16:37, 16 January 2018 (UTC)

Please provide some useful links, instead of plain text tinyurls which turn out to be Wikidata queries. It's not really helpful this way. Anyway, no idea how you can quote my "not enough" statement and then translate it to not ever, none of this... Anyway, number 1 is Arnold van Westerhout. He is linked from two enwiki pages, as can easily be found. If we had used links to Wikidata instead (the type RAN used and which started this discussion), I would not have been able to find this. Fram (talk) 16:50, 16 January 2018 (UTC)

The proposal above is for a total ban on Wikidata links, so let's not mess about here. A redlink is all very well, but is hardly the point. It doesn't identify AvW uniquely -- there might be multiple articles that have redlinks intending different AvWs -- nor does it attach the identity intended to external databases. In contrast, the {{ill}} template gives the option to output a redlink with a Reasonator link Arnold van Westerhout that does all of that, and gives editors a heads-up that there is a Wikidata item to link to if/when they do choose to create an article. The proposal above would take away editor discretion to include such a link in all circumstances. Jheald (talk) 17:20, 16 January 2018 (UTC)

Ugh, please, not Reasonator. Those fake machine generated articles are just terrible. but that page (Reasonator and Wikidata) is again a good example of why we shouldn't use them. They both describe him as "Belgian", which is of course false. But it is sourced! Yes, to this which correctly describes him as Flemish. Has the source changed since it was added to Wikidata, and is Wikidata yet again not so up-to-date as is claimed? Or was it a wrong addition right from the start? No idea. But it's not something we should willingly expose our readers to. Fram (talk) 08:05, 17 January 2018 (UTC)

When did "external sources" on sister-project pages we link to become a requirement for linking? How many Commons pages, for instance, include "external sources"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:06, 16 January 2018 (UTC)

External sources are not a requirement, no. Reliable sources should be a requirement. Linking to poorly sourced pages with the intention to provide additional data to our readers goes against what enwiki should do, i.e. provide and summarize information from high quality sources. And I don't consider structured data and images to be similar enough to require them to be treated the same. Feel free to start a discussion about Commons of course, but don't expect me to base my position wrt Wikidata on what we do with Commons, or how Commons deals with problems. Fram (talk) 16:41, 16 January 2018 (UTC)

It more than "goes against what we should do". It is an explicit violation of WP:ELNO #2, which disallows linking to "Any site that misleads the reader by use of factually inaccurate material or unverifiable research". —David Eppstein (talk) 19:03, 16 January 2018 (UTC)

The same reasoning should then apply to links to other language Wikipedias ({{ill}}), which I would support. Btw it would also apply to links to the English Wikipedia which are formatted as external links (which does happen, though not very often).--Ymblanter (talk) 19:08, 16 January 2018 (UTC)

Links to Wikidata, such as those discussed above, are not "formatted as external links". HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 16 January 2018 (UTC)

OK (though that's not what was said above). When did "reliable sources" on sister-project pages we link to become a requirement for linking? How many Commons pages, for instance, include "reliable sources"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:11, 16 January 2018 (UTC)

You mean, aside from the licensing templates and requirement to note the sources the images etc. were taken from? Curly "JFC" Turkey 🍁 ¡gobble! 23:21, 17 January 2018 (UTC)

• The question of WP:ELNO#2 bothers me. We don't use {{ill}} to link to other-language Wikipedias with a reputation for uncorrected errors; why should we link to Wikidata while it has a reputation for uncorrected errors? — Arthur Rubin (talk) 23:20, 17 January 2018 (UTC)
  • We don't link to other wikis as references, but we do link to them for navigation. Different purposes may be covered by different guidelines. Diego (talk) 09:25, 18 January 2018 (UTC)

Wikidata link options

Here are some options:

1. Frank White Burr (rejected, should be more distinguishable from an internal link, per principle of least astonishment)
   • [[d:Q5490147|Frank White Burr]]
2. Frank White Burr (no redlink with Wikidata link icon)
   • {{Wikidata icon|Q5490147}}
3. Frank White Burr (redlink with Wikidata link text)
   • {{Interlanguage link|Frank White Burr|WD=Q5490147}}
4. Frank White Burr (redlink with Wikidata link text and reasonator link text)
   • {{ill|Frank White Burr|WD=Q5490147|reasonator=1}}
5. Frank White Burr
   • {{Interlanguage link|Frank White Burr|D|Q5490147}}
6. Frank White Burr
   • {{Interlanguage link|Frank White Burr|d|Q5490147}}
7. Frank White Burr
   • {{Interlanguage link|Frank White Burr|wikidata|Q5490147}}
8. Frank White Burr (Wikidata)
   • Frank White Burr ([[d:Q5490147|Wikidata]])
9. Frank White Burr (Wikidata)
   • Frank White Burr <small>([[d:Q5490147|Wikidata]])</small>
10. Frank White Burr (wikidata)
    • Frank White Burr <small>([[d:Q5490147|wikidata]])</small>
11. Milton Gideon Votee (the soft redirect, this would create a blue link but stop at a page that offers to send you to Wikidata, the message can be customized for Wikidata like the one for Wiktionary)
    • {{Soft Wikidata redirect|d:Q5490147}} (→ See Wikipedia:Templates for discussion/Log/2018 January 19#Template:Soft Wikidata redirect --Francis Schonken (talk) 05:38, 19 January 2018 (UTC))
12. Frank White Burr (invisible text to preserve the unique identifier, but no useable link)
    • Frank White Burr <!--Wikidata:Q5490147-->
13. W. Homer Axford (the standard soft redirect with no special Wikidata message)
    • {{Soft redirect|d:Q47462594}}
14. William Harold Bodine, Sr. (this option redirects the name to a list, but reminds the reader that more data is available at Wikidata on the redirect page)
15. National Register of Historic Places listings in Somerset County, New Jersey (this model uses a link to Wikimedia Commons along with symbol for commons and the phrase "more images". It would be adopted to read "more information" and use the symbol for Wikidata. It could be displayed in its own column in the table.

Comments on link style

• I oppose 1, 2 (flaglike icon doesn't work: should be something else for the link, see above), 5 and 6. --Francis Schonken (talk) 19:41, 16 January 2018 (UTC)
  • 8: not OK imho, parenthesis with link should have small text, so that it is graphically different from surrounding prose, which may also have parentheses. --Francis Schonken (talk) 21:24, 16 January 2018 (UTC)
  • Oppose #11: those that don't deserve a separate page in Wikipedia can be bluelinks, but then as a redirect to the Wikipedia page that has most information on them (which might very well be the page which contains the bluelink you started from). --Francis Schonken (talk) 21:49, 16 January 2018 (UTC)
  • #12: imho, no, not what we should be using invisible text for. --Francis Schonken (talk) 22:16, 16 January 2018 (UTC)
  • Oppose all, after having given this some more thought. --Francis Schonken (talk) 12:52, 22 January 2018 (UTC)
• 5 and 6 looks like he is a member of the Democratic party, remember cursor rollovers do not work in mobile Wikipedia. There is really no point in creating a red link especially since his entry was already deleted, we do not need a chart that is a sea of red links. The whole point of this is that these people will probably never get a full Wikipedia entry. We just want to uniquely identify them from others of similar name like VAIF and LCCN do. --RAN (talk) 20:26, 16 January 2018 (UTC)

8. Frank White Burr (Wikidata)

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 16 January 2018 (UTC)

Note that Francis has edited his first comment, since I replied to it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:35, 16 January 2018 (UTC)

? Didn't change anything to my first comment after you replied to it. --Francis Schonken (talk) 21:49, 16 January 2018 (UTC)

Yes you did; and now someone else has deleted half of my comment (now restored). WFT is going on? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:41, 16 January 2018 (UTC)

Again, I didn't change anything to my first comment after you replied to it. I expanded the list with the additional examples presented elsewhere by others (none of these examples were changes to a comment of whoever: I just copy-pasted the examples in the list, adding a few variants which were not "comments" nor "changes to comments" whatsoever). My first comment was untouched from the asterisk that preceded it to the signature that ended it. Then I also added another comment about one of the new examples, with an additional new signature. So, no, I did not "edit my first comment after you replied to it". --Francis Schonken (talk) 22:50, 16 January 2018 (UTC)

"I expanded the list" Yes. You changed your first comment, after I had replied to it. Stop denying that you did so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:29, 16 January 2018 (UTC)

Sorry, again: I did not change my first comment after you had replied to it. This is the entire comment:

• I oppose 1, 2 (flaglike icon doesn't work: should be something else for the link, see above), 5 and 6. --Francis Schonken (talk) 19:41, 16 January 2018 (UTC)

It remained unchanged after you replied to it. --Francis Schonken (talk) 04:55, 17 January 2018 (UTC)

• Oppose all- wikidata should not be linked in the body of an article. This is the case especially for non-notable subjects such as Frank W. Burr which already had an article deleted at AfD.--Rusf10 (talk) 21:43, 16 January 2018 (UTC)
• Oppose all per my contributions to the discussion above. Wikidata links fail WP:ELNO #2 (far too much of the "data" on Wikidata is unsourced speculation; Wikidata editors have explicitly rejected policies analogous to WP:BLP [7] so Wikidata should not be linked in a way that makes its data appear definitive). Additionally, Wikipedia's policies and guidelines on whether an article should be redlinked should be based purely on potential notability of the subject, not on whether some other project has a link. —David Eppstein (talk) 22:35, 16 January 2018 (UTC)
  • Wikidata is compliant with the Wikimedia Foundations policy on living people. WP:ELNO #2 forbids inherently "unverifiable" data, which is not "unreferenced at the moment", they are not synonyms. My quick calculation says that we would lose about 20% of the English Wikipedia if we removed every paragraph that is currently unreferenced. Correct me if you calculate a different number. --RAN (talk) 22:38, 16 January 2018 (UTC)
  • "Wikidata editors have explicitly rejected policies analogous to WP:BLP" This canard is as untrue now as it was at all the many previous points when I have pointed out its falsehood. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:44, 16 January 2018 (UTC)
    • "Wikidata is compliant with the Wikimedia Foundations policy" is a highly disingenuous way of saying that they don't follow the much stricter English Wikipedia policy. (As a separate project, they're allowed to set their own policies, but if their policies are incompatible with ours then we should not link to them.) And the link I posted, showing them rejecting a policy analogous to WP:BLP, speaks for itself. —David Eppstein (talk) 22:49, 16 January 2018 (UTC)
      • Your link does not "show them rejecting a policy analogous to WP:BLP" (and you've gone from "policies" to "a policy"); it shows the rejection of a weak, badly worded and ambiguous first draft of a policy, far from being the equivalent of enWp's, for the good reasons stated there - effectively sending it back to the drafters with the message that a better policy is needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:24, 16 January 2018 (UTC)
  • There are almost 300 Wikipedias, of which the English is one, all must comply with the WMF policies. (now corrected above) We link to Wikimedia for images and Wikisource and Wikiquote, all with their own policies. And oddly we already link to Wikidata for people who already have articles, despite it having its own policies. We also link to a half dozen outside Authority Control identifiers, each with their own policies. We also link to newspapers in references which may disclose a living person's age, and the name of their spouse and children. This is simply what to do about notable people without articles that have data at Wikidata.--RAN (talk) 22:53, 16 January 2018 (UTC)
    • This discussion started with links to NON-notable people (deleted at AfD) who have data at Wikidata so it is, again, disingenuous to shift the goalposts to talk only about the notable ones. And when we link to Wikisource and Wikiquote, it doesn't create the false impression that unsourced speculative birth and citizenship data at the link is reliable. And Wikimedia commons has shown itself to be good at making sure its images comply with policy (their licensing requirements are stricter than ours and well enforced); Wikidata has both weaker requirements and very weak enforcement. —David Eppstein (talk) 23:20, 16 January 2018 (UTC)
      • AFAICT, none of the other sister sites you mention - Wikisource, Wikiquote, Wikimedia Commons - have "policy analogous to WP:BLP", nor indeed do they require any sourcing for birth dates of living people, nor the death dates of the recently deceased. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:27, 16 January 2018 (UTC)
      • NO one has changed the goalposts, the initial statement was: "links to wikidata for people who fail notability requirements to have [standalone] articles on wikipedia. In some cases ... links to wikidata after the article on the person was deleted" (emphasis mine). The argument is people notable to be included on a list but not notable for a standalone article, whether deleted, or never created. The notabilty of the people included on the list has been an accepted fact in multiple AFDs. --RAN (talk) 00:00, 17 January 2018 (UTC)
• Oppose all Ugh, per David Eppstein, just looking at that link - more concerned about limiting expansion than having accurate information, and also rejecting stuff like The repeated addition of unverifiable information (such as "John Doe is the world's lamest man") can result in a block of the offending user. Not compliant with our policies on BLP. Galobtter (pingó mió) 07:22, 17 January 2018 (UTC)
• Oppose all per David Eppstein. Because Wikidata does not accept many of our more strict content requirements, particularly for BLPs, using Wikidata is equivalent to sneaking BLP violations in through the back door. The use of Wikidata should be the exception, not the rule, and should be done sparingly and with responsibility if at all. I oppose anything that would make linking to it routine. Reyk _YO! 07:25, 17 January 2018 (UTC)
  • addition- since it's been pointed out that this is the MoS talk page I should also say something about the style concerns. I oppose the invisible wikitext option, since that should be deprecated generally, and I don't approve of any of the other options because they are unnecessary clutter- especially given the low value of what's being linked to. Reyk _YO! 09:18, 17 January 2018 (UTC)
• Support 3, 8 and 9 (Wikidata should be capitalized; redlinks are fine in article text but can be hidden if a template is used; <small> can be used in body but not in infoboxes), assuming that links are kept. Jc86035 (talk) 12:16, 17 January 2018 (UTC)
• 3 or 9 could be acceptable in some cases, possibly replacing the direct Wikidata link with a soft redirect. Although, the question of whether the link would necessarily violate WP:EL bothers me. — Arthur Rubin (talk) 23:15, 17 January 2018 (UTC)
• Support 3rd, oppose others, because it's the only mobile-friendly way, for users that "oppose all", I would ask you all that if there are missed concepts here, are they all ineligible in English?! --Liuxinyu970226 (talk) 11:49, 18 January 2018 (UTC)

  Anyway, is there be possible to restore {{Internal link helper}}, but only for the Wikidata propose, so we can see a green link, and by moving our mouse we can see "The article XXX is not yet created, you may visit Wikidata for viewing its summary-of-details and other languages editions" and link changed to normal redlinks. --Liuxinyu970226 (talk) 11:04, 22 January 2018 (UTC)

• Support 3 and 9, with same-size text (8) used in infoboxes where text is already small. We should only redlink things that we think will pass as notable and be the subject of a Wikipedia article, and leave non-notable items un-redlinked.--Carwil (talk) 16:41, 19 January 2018 (UTC)
• Support 2, 3 and 9. The flag is already used by Commons for links to Wikidata so it shouldn't be too unfamiliar to our readers. Deryck C. 18:14, 19 January 2018 (UTC)
• Support 2, 3 + 9: if people really doesn't know what the flag is, they can hover over the link, or—if on Mac—can preview the page. I do not see how it could cause a problem. –Sb2001 18:30, 19 January 2018 (UTC)
• Support 9, if the subject is notable 3, and less so 2: Otherwise if we already have an article on the subject than linking to WD will occur on the article page itself. Doc James (talk · contribs · email) 09:17, 20 January 2018 (UTC)
• Support 2, as that matches the convention already in use in Wikidata-enabled infoboxes, on Wikimedia Commons, and elsewhere. Ideally #2 should also include a redlink. After that, 3 and 7 are OK, 8-10 aren't great since they're missing the redlink but are also sort of OK. 5 and 6 are rather meaningless, and 11-13 seem pointlessly complex or just pointless (in the case of #12). #4 would be nice, but it's getting too long (particularly on mobile devices), and that's also a concern with the ones that spell out 'wikidata' rather than showing the logo. Thanks. Mike Peel (talk) 13:51, 20 January 2018 (UTC)−
• Support 2, 3 + 9 All three work well and for non-Wikpedia notable people 9 does a good job at disambiguation. ChristianKl ❪✉❫ 23:09, 20 January 2018 (UTC)
• Support soft redirect I don't care if we make a special soft redirect just for Wikidata. Visually it gives the best look, a clean blue link, and gives the reader an option of not going to Wikidata. It links all the appearances of the person in Wikipedia should the decision be made later to start an article. If an article is made it will insure that it is properly linked to Wikidata, and a new entry not created as a duplicate. --RAN (talk) 01:07, 21 January 2018 (UTC)
• Oppose all, a redlink will do. We are not writing a database, that is WikiData. --Dirk Beetstra ^{T C} 05:29, 21 January 2018 (UTC)
  • @Richard Arthur Norton (1958- ): "this option redirects the name to a list, but reminds the reader that more data is available at Wikidata on the redirect page" - see WP:EL. We do not link lightly to external sources for 'more information'. As the situation is now, I don't think there is any legit reason to link to WikiData as a source of information. The option is worse than linking to the corresponding page on another language Wiki. --Dirk Beetstra ^{T C} 09:40, 31 January 2018 (UTC)
• Oppose all except 12. There should be a blanket ban to biographical links and links in BLPs per WP:BLPSOURCES. LK (talk) 01:01, 22 January 2018 (UTC)
• Oppose all... I have no issues with linking in the sidebar to Wikidata for the subject of the article - but we shouldn't be linking in the body of the article. Ealdgyth - Talk 13:22, 22 January 2018 (UTC)
• Oppose all We should not be linking to an unreliable source in article space. --Malcolmxl5 (talk) 00:11, 23 January 2018 (UTC)
• Oppose all. The link in the sidebar is all that’s needed. These just highlight the serious problems with putting links inline. 1 looks like an article link. 2 looks like a decoration. Most look like links to the Wikidata article. Two look like links to another language (d[e].wp e.g.). Worst of all is the soft redirect that looks like a normal link but instead takes readers a page with no content, just the link to the page they wanted and a data link they will probably regret clicking on. All of them have serious issues and so show how Wikidata links within articles are just a bad idea.--JohnBlackburne^words_deeds 06:18, 31 January 2018 (UTC)
• Oppose all Sidebar link is sufficient. Anything else is covered by ELMAYBE. Only in death does duty end (talk) 15:34, 31 January 2018 (UTC)
• Oppose all per the above arguments. -- Tavix ^(talk) 22:08, 1 February 2018 (UTC)
• They're all pretty awful. I guess 12 is the least bad, in its uniquely awful way. Aside from the usual Wikidata issues, the link usually falls under WP:ELNO #1 or a really lousy WP:ELMAYBE. Wikidata was designed as a database for values to retrieve, not for human reading. Alsee (talk) 09:03, 4 February 2018 (UTC)
• Oppose all, that way madness lies. Kaldari (talk) 06:30, 11 February 2018 (UTC)
• Support 8. Possible variation: Frank White Burr ^(Wikidata). (Frank White Burr ^{([[d:Q5490147|Wikidata]])}) -- Oa01 (talk) 09:50, 13 February 2018 (UTC)

Inline flag-like icon for Wikidata, at TfD

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia:Templates for discussion/Log/2018 January 16#Template:Wikidata icon.

The fact that the nominator was blatantly accused of bad faith in even daring to open this template for discussion says a lot about the bloc vote going on over there right now.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  00:36, 17 January 2018 (UTC)

No one should be nominating for deletion something being actively discussed at an RFC. --RAN (talk) 01:07, 17 January 2018 (UTC)

This is not a block vote. The nominator himself advertised the TfD here, and whoever was interested went there to vote. There was no conspiracy, at lest not than I know of. I agree though that nominating at TfD smth which is being discussed at RfC is not smart and serves no purpose.--Ymblanter (talk) 06:52, 17 January 2018 (UTC)

if people agree that the template shouldn't exist, then discussing any solution with this template (or anything similar) in it can be closed. Seems like a rather good purpose for a TfD. Fram (talk) 07:33, 17 January 2018 (UTC)

@Wittylama: Since the TfD was "suspended" (not sure if that's a valid procedure), commenting here: Assuming Wikidata links in articles are retained, would {{Interlanguage link}} adequately replace {{Wikidata icon}} (example: Douglas Adams vs )? Jc86035 (talk) 12:13, 17 January 2018 (UTC)

• Yeah, I do not agree with the "suspending" of the TfD discussion either. Reyk _YO! 12:23, 17 January 2018 (UTC)

Thank you Jc86035 for your productive contribution to this discussion! I would suggest that it's not quite the same for a couple of reasons. Firstly is the visual aspect (the use of the word "wikidata" rather than the logo) but that is of smaller significance in the grand scheme of things. I used the logo when I built the template because it is consistent with our sisterproject templates and consnstent with the way we link to wikidata items on Commons - a common visual vocabulary across projects. But, as we've seen in the 'template for discussion' debate, this stylistic choice is not appreciated by all... The more substantial point I feel that makes it different is that the Wikidata Icon template is independent of whether there is a blue, red, or no-link to the item in question. The ILL template has, as its main purpose: "So long as the page on this wiki does not exist (i.e. is "a red link"), this template temporarily displays" and then there is [[Template:Interlanguage_link#Forcing_links|the display=1 feature to "force" the wikidata link even if it is a bluelink. This template was designed specifically and deliberately to NOT interfere or interact with the normal link mechanics and policies on WP. So... it can be placed next to a bold word in a table or infobox, or a bluelink, redlink, or no-link and no template-alteration needs to take place if an article about that subject is created in the future (in the event of a redlink). See, for example, how it is used in the infobox in: The Offerings of Peace and The Offerings of War. This is an article about a pair of sculptures that are both notable for WikiDATA's perspective, but would not be worth writing about independently in WikiPEDIA - in this case the ILL template using the wikidata-field wouldn't be appropriate (I believe) because the title of the artwork in its own infobox shouldn't be linking to itself. See what I mean? Wittylama 13:03, 17 January 2018 (UTC)

But why would we link to the Wikidata pages for these two sculptures in the infobox / image? That's not the purpose of an infobox or image. In those, the link to Wikidata should go, the accession number should go (or at least should be correct!), and the overly precise coordinates should go (have one coordinate at the top right of the article instead). Then you end with readable, attractive, informative images without the barrage of needless information it has now, coupled with two meaningless "flags" (I understand you created these with the best intentions, and that they are being used in Commons and so on, but to most of our audience they will be confusing and meaningless). What this page could use, if you want to include links to reliable, relevant databases about the two sculptures, is something like the authority control template at the bottom (but a bit more restrictive than what is usually shown). Then again, the Wikidata pages about these sculptures are at the moment only sourced to the Art Gallery of New South Wales, a link which is already in the article . Basically, the links to Wikidata add nothing here but visual clutter and redundant information in a reader-unfriendly format. Fram (talk) 13:18, 17 January 2018 (UTC)

I've fixed the Accession number error, and removed the geo-coords from the image/infobox in that article - good points. Wittylama 21:13, 17 January 2018 (UTC)

I've removed all three Wikidata links (icons) from tha article, as none of them contained any information not already present in the article. It makes no sense at all to link to sister projects if that links doesn't give the reader any additional information. Fram (talk) 08:16, 19 January 2018 (UTC)

​Almost all of the non-Wikipedia sister project links I've seen have text explaining what the link does (e.g. "Media related to article subject at Wikimedia Commons"), aside from inline English Wiktionary links, which are often unmarked per Wikipedia:Manual of Style/Linking#Interwiki links. I think usage on Commons is different because there's no Manual of Style (if you're referring to c:Template:Artwork the addition of the logos without accompanying text seems to have been without formal consensus), and since Wikipedia has a guideline which advises against unexplained icons ("[Repeated use of icons in non-body text] should only be done if the icon has been used previously with an explanation of its purpose.") I think it would be better to at least have accompanying text to help readers understand what the icon is. Jc86035 (talk) 13:33, 17 January 2018 (UTC)

Hi again Jc86035, you make a fair argument that the other sister-project links are often surrounded by explanatory text. The purpose of this template was to UNclutter the space visually and leave the associated word UNencumbered to be (or not to be) a red or blue link. Alternatives in a table format would be to have: the full wikidata number (which is just an arbitrary number and not informative of anything); a more elaborated template (as you described like the commonscat template) but that would be very bulky; the word 'wikidata' (like in the ILL template you mentioned) but that also defeats the purpose of being small and unbotrusive to fit inside table cells. Perhaps, when the template is used repeatedly and throughout the article, such as in List of public art in the City of Sydney, then it should be prefaced with a short explanatory comment near the beginning which describes its purpose? This would be just like many articles take the time to explain the scope and features of complex tables before launching into the details. I realise this suggestion won't placate the people who dislike any wikidata links as a matter of principle.. but haters gonna hate, what can you do! Wittylama 21:13, 17 January 2018 (UTC)

What you could do is institute actual strict sourcing requirements on Wikidata instead of insisting that there is no problem other than "haters". —David Eppstein (talk) 21:26, 17 January 2018 (UTC)

On "complying with BLP policies"

There seems to be a general misunderstanding here on what Wikidata actually is. My attempt yesterday to get the point across resulted in a series of ad hominem arguments, so that these had to be hatted. I will try the second, and the last time. Whoever wants to listen, may get a chance; whoever has already an opinion, I do not expect them to listen. I will try to be brief.

Wikidata hosts data. It hosts a lot of data with very different provenance (which sometimes is not even recorded). There is data with good provenance and data with bad provenance. The data is used by external users, which include Wikimedia projects. All users use the data in very different ways. The usage of Wikidata by the German Wikipedia is very different from the usage of Wikidata by the Italian Wikivoyage and is different from the usage by the Smithsonian.

I see claims that "Wikidata must comply with the BLP policy of the English Wikipedia". By itself it does not make sense. If this means that Wikidata should only host data which comply with the BLP policy of the English Wikipedia (or with other policies) and delete all other data, this is not going to happen. Never, in any scenario. For a multitude of reasons. One of the reasons is that the English Wikipedia is not the only user of Wikidata.

The correct statement must be "The English Wikipedia must not import data which does not comply with its policies, including BLP". This is a perfectly valid statement. Indeed, Wikipedia must comply with its own policies.

The question is how this is compatible with Wikidata hosting, among others, data with bad provenance. It is clear that only data with good provenance (and by good I mean in this case compliant with the policies of the English Wikipedia) must be imported. Now, there are different scenarios how this is possible.

One scenario is that Wikidata itself must supply the data in the form which complies with the policies of the English Wikipedia, and then Wikipedia might want (or might not want) to import the data. Vandalism fighting on Wikidata aside, this is an unlikely scenario, because, as I mentioned, Wikidata also hosts and will host data which are just not suitable for import here. The conclusion that many users make is that Wikidata is badly designed, and all import must be banned. This is a perfectly valid conclusion, but it must be taken consciously. Indeed, one user here said they would be more comfortable by using Google than by using Wikidata. It is ok. I do believe that the community in general does not support this point of view (and in particular why this RfC is now heading to no consensus leaning oppose), but this is a valid point for an RfC.

Another, a way more realistic scenario, is that end users, including the English Wikipedia, must themselves select which information is suitable to import. This can be done by different means. It can be done by writing complicated lua templates, which would only import information which is sourced to sources from a whitelist, or not sourced to sources from a blacklist. It can be done by using bots and checking the transferred information manually (and in the meanwhile, it could be hidden similar to pending changes). It could be done by bots posting at the talk pages so that human users might later check it and transfer to the articles. There could be more options, or a combination of those. However, this must happen at this side, not at the Wikidata side. (Wikidata might help by better structuring data, for example, by promoting data of certain provenance to a preferred rank, but this is about it. All of these things need some development. Development is complicated and takes time. Nobody would start knowing that after two months work a member of the anti-Wikidata brigade would show up, nominate the developed template on TfD, make an appropriate ad campaign and get the template deleted. If we are going to behave like this, we can just forget about any integration with Wikidata. May be it is not needed and everybody is happy using Google, I do not know. But expectation that all of this will be done at the Wikidata side, if anybody has them, are unreasonable.--Ymblanter (talk) 08:09, 17 January 2018 (UTC)

"My attempt yesterday to get the point across resulted in a series of ad hominem arguments, so that these had to be hatted." You are the one who refused to engage further with another experienced editor because you are an admin and they aren't.

"I see claims that "Wikidata must comply with the BLP policy of the English Wikipedia"." I don't think anyone here has said what Wikidata must do. They can do (and actually do) whatever they like. But whether they comply or not has an impact on whether we will use their data or even link to them.

• "Indeed, one user here said they would be more comfortable by using Google than by using Wikidata. " You have been going on and on about this. As far as I can tell, User:Dirk Beetstra (who is that "one user") has never argued for the import of data from Google, or for the direct linking to Google (search results and the like) in articles. What they claim is that, to find good sources (which is often given as an argument for the links to Wikidata, that it can be used as a pointer to good sources), they'ld rather use Google than Wikidata. Using this "Google vs. Wikidata" again and again in this discussion is an obvious strawman. (see also: "May be it is not needed and everybody is happy using Google, I do not know.")
• "this RfC is now heading to no consensus leaning oppose" No "leaning oppose" is really noticeable. More recent votes have no more value than earlier votes. And in any case, if there is this much opposition to using Wikidata, it should give some pause to the proponents.
• "Nobody would start knowing that after two months work a member of the anti-Wikidata brigade would show up, nominate the developed template on TfD, make an appropriate ad campaign and get the template deleted." Any examples you have in mind? For someone complaining about ad hominem arguments (and I presume you were not complaining about your own ad hominem arguments there), you sure know how to present things in a neutral way which will sway people from all sides. The only "ad campaigns" I have seen is posting a "neutral" statement at Wikidata every time some Wikidata-related discussion happens on enwiki, after which suddenly the "opposes" and "keeps" increase. Or of course "neutrally" mentioning an RfC at some Wikidata convention, after which suddenly people who rarely or never edit here and never have shown any interest in the topic come to the defense of the Wikidata side. If you know of similar "ad campaigns" from people supporting some deletion of Wikidata uses on enwiki, feel free to post examples here. But don't present this as a battle between a poor policy-compliant community who love Wikidata, and some raging "anti-Wikidata brigade" mounting "ad campaigns" to delete your hard work out of sheer malice. Fram (talk) 08:31, 17 January 2018 (UTC)

nothing "on content" here. Second warning to stay on topic. --Francis Schonken (talk) 08:43, 17 January 2018 (UTC)
The following discussion has been closed. Please do not modify it.
I am not going to reply to Fram, as I mentioned earlier, but let me note they developed an unfortunate habit lying about my behavior, as if nobody can check what I actually said. One can easily check also whose statement goes first in the hatted section - surprise-surprise.--Ymblanter (talk) 08:34, 17 January 2018 (UTC) Another personal attack? Either retract the claim of lying, or tell us what exactly is a lie. As an admin who is so proud of their admin status, you should certainly know that accusing people of lying requires some good evidence with it (at least on enwiki, perhaps it's different on Wikidata?) Fram (talk) 08:41, 17 January 2018 (UTC)

I'd close this subsection without further ado: it's only and exclusively about content guidance, without relation to style guidance (must I rememberremind everyone that we are here on the Manual of Style talk page? – discussion of content guidance without style aspect is hardly appropriate here). With the diatribes veering off in even less related realms while, really, people seem to have little to discuss about the style aspect, this subsection should in fact be closed ASAP. --Francis Schonken (talk) 08:50, 17 January 2018 (UTC)

People vote above about the content guidance, not about the style guidance. But anyway it already did not go in a good direction, which I, to be honest, could have expected in advance.--Ymblanter (talk) 08:54, 17 January 2018 (UTC)

Re. "People vote above about the content guidance" – I didn't, so please let everyone speak for themselves.

Also, reminding everyone that this talk page is under DS (see banner above on this page). The DS resulted (at least in part) from diatribes conducted at talk pages such as this one. So I'd carefully, carefully ask everyone to stay on topic. --Francis Schonken (talk) 08:59, 17 January 2018 (UTC)

This is ok, but would you cross out the support votes which had the motivation "Wikidata is unreliable"? Actually, very few votes deal with the style (mine did, for the record).--Ymblanter (talk) 09:03, 17 January 2018 (UTC)

Wikipedia:Manual of Style/Linking#Overlinking and underlinking is part of the style guidance. Some people might find this:

• Frank White Burr

terribly underlinked; others might find this:

• De Danske, Norske og Tÿdske Undersaatters Glæde, TWV 12:10

terribly overlinked: which links to retain can be argued with whatever one thinks a viable rationale in a !voting area (I'll not be the one closing the RfC but any closer would usually weigh relative validity of reasons adhered to by various participants). My problem with the current section is that it is the second one initiated about "general" characteristics of Wikidata (we already have #Discussion (linking to Wikidata RfC), in the OP: "... that Wikidata is universally not useful ..." – emphasis added, which clearly sets the topic of that section as pro and contra that *general* appreciation), often with little connection to how that affects *linking* (this time even less than the previous time). In sum, my rationale for closing this section would be WP:NOT#BLOG or some such (and if not blog-like, at least a duplicate of the topic in #Discussion (linking to Wikidata RfC)). General advantages or disadvantages of Wikidata are hardly the topic here: the topic is whether, and if so under which conditions, we should link to Wikidata (not scores of characteristics of that website which have little or nothing to do with potential linking from Wikipedia). --Francis Schonken (talk) 07:21, 18 January 2018 (UTC)

Speaking of "elementary text", shouldn't the section header be "complying" instead of "complaining"? "Complaining with BLP policies" is rather weird... Fram (talk) 09:16, 17 January 2018 (UTC)

Weird perhaps, but we see it all the time. EEng 23:29, 17 January 2018 (UTC)

• Is there a way from a Wikidata entry to see if there is a link in a Wikipedia to that entry? --RAN (talk) 03:03, 18 January 2018 (UTC)

There's a whole section named Wikipedia with interwiki links on each item... Sabas88 (talk) 14:41, 18 January 2018 (UTC)

I think you are telling me that Wikidata has a field for links for articles in Wikipedia, that I know. When we create a link like d:Q000000 is that findable from within Wikidata? --RAN (talk) 17:44, 18 January 2018 (UTC)

When (and how) SHOULD we link to Wikidata?

From the comments above, it seems that many (not all) editors agree that we should not include links to Wikidata in the TEXT of an article, but many (not all) editors think it appropriate for an ARTICLE to include a single link to the corresponding page (on the article’s topic) in Wikidata... perhaps in a sidebar. Essentially, a note saying “FYI, Wikidata has a page on this topic”, but no more. I could live with that... but perhaps we should discuss this in more detail.

So far, we have focused on when (and how) NOT to link to Wikidata, so perhaps it would be helpful to discuss when (and how) TO link to it. Blueboar (talk) 15:32, 18 January 2018 (UTC)

We already have such link, it's the "Edit links" button under the language interlinks to other Wikipedias. I've seen the Spanish Wikipedia using more explicit links, with an Authority control template at the bottom of the page showing the Q number at Wikidata for the article's topic, but both point to the same place.

I'd prefer the discussion to be more fine-grained, and we studied when and whether we could create links to Wikidata for entities that are not whole articles, but are described within our articles and for which a Wikidata page exist. Authority control is a basic tool in library science, and Wikidata could be a perfect complement for incorporating it to our encyclopedia, if we find a way to keep in check its shortcomings regarding reliability. Diego (talk) 16:54, 18 January 2018 (UTC)

P.S. The links could take the form of a dfn tag, which doesn't create a link to the URL, but instead can be used to show the item's definition as a tooltip. I think this usage would be consistent with our WP:JARGON policy; we certainly often use Wiktionary as an external link in that way. Diego (talk) 17:12, 18 January 2018 (UTC)

Where this conversation seems to get stuck is along these lines: "There are recurrent problems with Wikidata information in Wikipedia articles, in part because the readers are being deceived about where the information comes from." "But Wikidata only exists as a database to feed information to other projects, so we can't send readers to Wikidata, or segregate Wikidata information in Wikipedia articles, and anyone who says different is trying to erase Wikidata from Wikipedia and kill it off." But ... who says the Wikidata community isn't responsible for presenting information in a way that would make sense to readers? Who says we can't send readers to Wikidata, rather than deceiving readers about where information on Wikipedia pages is coming from? I get that that's not their plan. "I'm only responsible for this one thing that I know how to do, you guys are responsible for everything else, and if we fail, if it causes problems, then that's your fault". I get why people want to say that, I'm even sympathetic, and I admit that there are specific exceptions where Wikidata links work without causing too much trouble ... but as a general philosopy of just sticking Wikidata links in wherever, whenever, it's not working and I can't support it. - Dank (push to talk) 17:00, 18 January 2018 (UTC)

@Dank: Where do get this Wikidata only exists as a database to feed information to other projects and the Wikidata community isn't responsible for presenting information in a way that would make sense to readers from? I think there are very few people working on/with Wikidata who would subscribe to either of those views. Although User:Fram might not be a fan, most of us I think would regard Reasonator as a doing really a pretty good job of formatting Wikidata information in a reader-friendly way, extensively use it ourselves to 'read' Wikidata, and routinely include columns of links to it from workpages such as eg Talk:List of Royal Academicians/RAs. Given many of the entries on that page have Wikidata items with in excess of 30-40 matches to external databases, I for one find that Reasonator presents them in a very effective and usable way. But, hey, we're just editors, trying (across en-wiki, Commons, Wikidata, other wikis) to improve coverage and add information, and making pages to help ourselves and other editors to do that, so what do we know? Jheald (talk) 18:35, 18 January 2018 (UTC)

But to add to the above, there are some very valuable external sites with links that are only somewhat stable and need to be regularly checked, because routinely some get changed (without forwarding). It is far easier to manage, check and routinely update those links centrally, and then present them via a template here. So I make no apologies that links to at least one site like that are now run entirely through Wikidata. Jheald (talk) 18:48, 18 January 2018 (UTC)

I'm sorry it sounded that way. I can't respond right now ... I just got a month's worth of TFA blurbs to do, I'll be back when I get done with those. - Dank (push to talk) 22:18, 18 January 2018 (UTC)

Sorry, it's going to be a while before I can get back to this. - Dank (push to talk) 19:35, 21 January 2018 (UTC)

Living people and Wikidata

The main concern for not linking to Wikidata is concerns about living people.

• Wikipedia already links to Wikidata for living people that have Wikipedia entries, whatever concerns there are, already apply.
• There is concern about errors in Wikidata, they are handled the same way they are in Wikipedia, by correcting.
• There is concern about referencing in Wikidata, "unreferenced at the moment", is not the same as "inherently unreferencable". There are over 10,000 Wikipedia articles on living people that have unreferenced paragraphs. There are over 10,000 Wikipedia articles on living people in which the birth date given is unreferenced. I stopped the search at 10K, someone else can do a more accurate count by letting the script run longer.
• Wikipedia already links to VIAF and LCCN as well as other Authority Control databases for living people that lists their birth year.
• Wikipedia already links to news articles as references that may give a person's birthday, and name their minor children, and name the city they live in.
• Wikipedia can just ban links to living people at Wikidata, not dead people, and not reference works.
• Wikipedia already allows interwiki links to any other language Wikipedias using {{Ill}}, when an article appears there.
• There was a concern that Wikidata's policy on living people does not 100% match the English Wikipedia policy, no other language Wikipedia does. Nor does Wikimedia Commons, Wikiquote, or Wikisource, all of which we link to. However, all do follow the Wikimedia Foundation's policy on living people.
• People also want to link to reference works in the reference section, that do not have ISBN entries.
• There are over 50,000 biographies of living people in which there is not a single reference to any data point displayed in the infobox.

--RAN (talk) 14:57, 19 January 2018 (UTC)

At least for me, the main concern about linking to Wikidata is

• Wikidata is not a reliable source
• Wikidata is poor in vandal fighting
• Wikidata is not reader-friendly (and Reasonator reads like what it is, a bot-created surrogate)
• All this is the most worrying for BLPs, but problematic enough in general
• For many links we currently have to Wikidata, there is no excuse for them: often they are links where the linked page already exists on enwiki anyway, and the sources in Wikidata are already listed at enwiki as well, so the page adds nothing at all

I'm no fan of using {{Ill}} to other wikis either, for much the same reasons. But at least these pages are structured the same as enwiki pages, and as long as you link to the bigger language versions (like de), you may be pretty sure that they do adequate vandalfighting, notability checks, BLP checks...

No one (I think) has brought up the issues of birthdays, minor children, ..., that seems like a strawman. Furthermore, there is no problem to link to reliable sites with this information. LCCN is considered a reliable site, Wikidata isn't.

It has never been a problem linking to reference works which don't have an ISBN, so no idea why you bring this up. Fram (talk) 15:11, 19 January 2018 (UTC)

No, my main concerns are not BLP. However it's inefficient to bother with complex or debatable issues when BLP is such a simple and blatantly fatal point to terminate any debate. I also need to call out the fundamentally false comment about "Wikidata's policy on living people does not 100% match the English Wikipedia policy". No. Wikidata does not have any such policy at all. Wikidata is in violation of the mission-wide resolution for all projects to create such a policy. And fundamentally, it's not even the lack of policy that's the BLP issue. The real BLP issue is the pathological community. All of Wikidata's attempts to create such a policy, up to and including today, are FUBAR because of the pathological community. A majority are opposed to living-persons-violations being listed as a blockable offense. Anything less than 90% support on that is appalling. Alsee (talk) 09:53, 4 February 2018 (UTC)

More on styles

• To me, the major issue is that blue-linking to Wikidata in article text creates the impression that there is a en.Wikipedia article on the linked subject/topic... when, in fact, the reader is sent to a page at Wikidata (or to put it another way... the link is presented as a link to a page inside en.Wikipedia, when it is actually a link to a page outside of en.Wikipedia). Blueboar (talk) 01:03, 20 January 2018 (UTC)
  • Maybe the MOS issue would be clearer if we set Wikidata aside and formulated it more generally as "Never assign direct interwiki links to the text of an article. All such links should be made either as a soft redirect or as a special marker that is not part of the main article text (such as a footnote or parenthetical interlanguage link)."? Because much of the discussion here has focused on "it's useful" vs "it violates BLP", neither of which is really a style issue, so it would help if we could decouple link style from the more general issue of whether we should link to Wikidata at all. —David Eppstein (talk) 01:18, 20 January 2018 (UTC)
    • Hmm... yes... I like that (because the issue isn’t limited to just Wikidata). It also keeps the focus of the concern to the appropriate page... Deal with the STYLE problem here at the MOS, and deal with any OTHER problems that people have with Wikidata (like the BLP concern) at the appropriate other policy and guideline pages (where they relate). Blueboar (talk) 02:30, 20 January 2018 (UTC)
    • I'd have no objection to that for prose, but we need to change "(such as a footnote or parenthetical interlanguage link)" to "(such as a footnote, table, or parenthetical interlanguage link)". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:33, 20 January 2018 (UTC)
      • How are interwiki links in tables any different than interwiki links in prose? Blueboar (talk) 12:25, 20 January 2018 (UTC)
        • They can have a column header. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:15, 20 January 2018 (UTC)
          • That would only be a valid explanation if you intend for *all* entries in a table column to link to the same interwiki site, even when there is an internal article link that could be used instead. When would that ever be a useful thing to do? —David Eppstein (talk) 20:32, 20 January 2018 (UTC)
            • When we have tables containing subjects significant enough to be in list articles but not necessarily the subject of their own article, and where there is more content relating to those subjects on sister projects such as images of listed buildings (monuments), texts by authors, data on species, or indeed on people. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:50, 20 January 2018 (UTC)
• I thought it was actually a slightly different blue colour from internal links, although not by much (but I haven't checked the colour codes recently). Presumably the link *could* be more of a different colour, but I'm not sure what the history / other uses of this are. Thanks. Mike Peel (talk) 13:55, 20 January 2018 (UTC)
  • Hmmm... I might be more accepting of interwiki links if the link were a significantly different colour (say bright yellow). My primary STYLE concern is avoiding surprise.... we don't want our readers to be confused when they click on a link, and end up being taken to a page in a sister project (when they were expecting to be taken to an article here on WP.en). We need something that makes it very clear to the reader (before they click on a link) that they are about to be taken out of WP.en... so they will know: "ah... if I click this, I will be taken to a sister project". Blueboar (talk) 14:46, 20 January 2018 (UTC)

Of course, only we cognoscenti will know what the yellow means... EEng 15:04, 20 January 2018 (UTC)

A valid point... but you could say the same about the difference between redlinks and bluelinks. Yet, everyone figures that out quickly. If we used a distinct colour for interwiki links, the non-cognoscenti would at least see that something was different about the link (and be less surprised when taken to a different project). Sure, at first, they might not know what the different colour indicated, but they would figure it out quickly. They would see a link in yellow (or orange or whatever), and wonder: "hmm, why is this link a different colour?"... (CLICK)... "ah, I see. Links in that colour take you to an interwiki page. Got it." Blueboar (talk) 16:42, 20 January 2018 (UTC)

I hate to break it to you, but I doubt more than 1 in 100 readers have any concept of an interwiki link, or understand that we have different "wikis", or anything like that. Red vs. blue is easy to grasp -- you get nothing, or something. EEng 19:17, 20 January 2018 (UTC)

I doubt that (or at least doubt that they'd have any difficulty making the leap of understanding Blueboar outlines after an initial experience or two). Even children understand how domain names work, e.g. that www.steam.com, steamcommunity.com, and support.steampowered.com are all different "places" within the Steam gaming system. At Meta, there's already a feature (optional in the preferences) to use different link colors for different projects. (It's not perfect; it uses more than color, including underlining and other style, which can be confusing, since the underlines look like those produced by <abbr> and by <element title="...">; but with some additional work it would be better, and it's already more useful than it is a hindrance).  — SMcCandlish ☏ ¢ 😼  19:04, 13 February 2018 (UTC)

Children understand domain names if they happen to look at them, or have some reason to. Most people don't. EEng 03:02, 14 February 2018 (UTC)

Not allowed to remove useless links to Wikidata?

Apparently even utterly useless links to Wikidata may not be removed, if the lead from User:Wittylama and User:Pigsonthewing is to be followed. The Offerings of Peace and The Offerings of War is an article given above by Wittylama as an example of where the Wikidata icon is used. I commented above with some remarks about this, after which Wittylama acted on some of the not-Wikidata related remarks but ignored the Wikidata ones. So I removed the icons, only to get reverted by the above two editors, despite asking repeatedly at User talk:Wittylama#The Offerings of Peace and The Offerings of War what these Wikidata links added for the reader.

As you can see from the diffs, there are three links to Wikidata items[8]. The first two are for the two artworks described collectively in this article (they have an individual Wikidata item, and the two together also have a Wikidata item). The third is to a later artwork made as a hommage to the works, which again is described in the article but has a separate Wikidata item.

The three Wikidata items contain no information not already present in the article. The only source at Wikidata is given in the same line in the enwiki articles.

Insisting that some link to an unreliable site, which adds literally nothing of information for any reader, must be kept, is a tell-tale sign of spam: not the enwiki article is important, not the reader is important, but the link, the website linked to, is the main concern. Spam gets routinely removed, and insistent spammers routinely blocked. Can someone indicate what information for readers these specific links actually add which isn't already present in the article, and if none, why these shouldn't be removed? Fram (talk) 15:02, 22 January 2018 (UTC)

The Wikidata item contains the same information, but it's in tabular format. So, it's no different than having an infobox, except that it's placed in a different website. But given the disputes provoked by infoboxes, it's no wonder that the same debate about the usefullness of structured information is repeated about Wikidata. Diego (talk) 15:22, 22 January 2018 (UTC)

"it's no different than having an infobox, except that it's placed in a different website." Which basically makes all the difference. If I make "wikiinfoboxes.com" where I repeat information from articles, I wouldn't be allowed to link to it either. Plus: infoboxes are supposed to be at-a-glance information, which is hardly the forte of Wikidata. An infobox should be reader-friendly, and Wikidata isn't. Fram (talk) 15:44, 22 January 2018 (UTC)

Comprehensive responses to each of Fram's complaints have been made over on my talkpage, at the subsection which Fram started: User talk:Wittylama#The Offerings of Peace and The Offerings of War. It does not automatically make Wikidata links "spam" just because Fram don't agree with these responses and does not believe Wikidata to be a useful supplement to Wikipedia articles in general. Anyone wishing to weigh in here might like to read that conversation on my talkpage first. Wittylama 15:33, 22 January 2018 (UTC)

"Comprehensive responses"? No indication has been given of what information a reader can find at these Wikidata pages which isn't already present directly in the article. "Anyone wishing to weigh in here might like to read that conversation on my talkpage first." Well, yes, that's why I linked to it. I didn't claim that Wikidata links are automatically spam: I claimed that these links are spam, because these links, in these articles, don't add anything but are only useful if you want a link (no, multiple links) to Wikidata no matter what. If Wikidata proponents want to include Wikidata links in the body of articles, preferably with a fancy flag-like icon, even if they serve no purpose for our readers and don't offer any aditional information, then it is no surprise that there is such a heavy backlash against these. Fram (talk) 15:44, 22 January 2018 (UTC)

• Comment- these really do seem like just linking to Wikidata just for the sake of linking to Wikidata, adding extra clutter and an unexpected perplexing diversion to an unreadable page for the hapless reader. Reyk _YO! 15:46, 22 January 2018 (UTC)
• Comment- let's wait for the RfC above to see whether there is consensus to link to WikiData in article content, then we can start a second RfC (because that is what it likely is going to need) to gauge what to do with the already existing links and possibly remove the fait accompli, and possibly an RfC for data that is pulled from WikiData (if it is unreliable to link to, it is also unreliable to pull data from them - and note that on BLPs data is pulled from WikiData to transclude in our content). --Dirk Beetstra ^{T C} 06:37, 23 January 2018 (UTC)

Another template for discussion

For anyone interested in this discussion, there is also a discussion on the Soft Wikidata recirect template that User:Richard Arthur Norton (1958- ) recently created as another way to link to wikidata within the body of an article--Rusf10 (talk) 01:26, 27 January 2018 (UTC)

Can we clarify what does and does not constitute 'strong national ties'?

• 1. Quite a long time ago I spent quite a lot of time in a fruitless dispute over whether British or American English should be used in an American-English article about a German warship that only ever fought the British, during which it became clear that there had been other such disputes about British-English articles about Japanese warships that only ever fought the Americans. Eventually the original language was kept, largely through exhaustion, as well as through claims that I later suspected, perhaps wrongly, were at least arguably contrary to WP:LOCALCONSENSUS.
• 2. I suspect there have been similar disputes involving other kinds of conflicts and other kinds of ties. For example should articles about Mexico be in American English because of the ties arising from America and Mexico being neighbours, and similarly for Britain and its non-English-speaking European neighbours, and so on?
• 3. Although I used to think the opposite, I now tend to think that keeping the original language variety is usually best from our point of view as editors (even though in theory it's arguably wrong from the point of view of most readers, but even that's debatable as arguably most of our readers are American and prefer American English in all circumstances).
• 4. And I suspect future disputes might be avoided if this were spelled out more clearly in MOS:TIES, along with some examples of what does NOT constitute strong national ties.
• 5. But I don't want to try to do anything about it until I get some feedback from other editors (and possibly not even then, especially if it seems likely to be controversial, as there may not be much point in having a long argument now just on the off-chance that it might prevent some arguments in future).
• 6. Regards, Tlhslobus (talk) 08:15, 18 January 2018 (UTC)

I think it's futile to try to completely nail this down. I will say that my opinion is that ties need to be clear. If you have to stretch a point to establish national ties, then don't do it — fall back to WP:RETAIN.

Examples of clear ties: A bio of a person who is/was a citizen of an English-speaking country, or spent most of his/her life in such a country or in its service. A geographic location in an English-speaking country. A company based in an English-speaking country. An aspect of the law or culture of a specific English-speaking country. An event carried out by citizens of a particular English-speaking country (say, the Moon landing).

Unclear ties: A person who is/was a citizen of both the UK and the US, or a citizen of one but spent most of his/her life in the other. A legal concept that applies to both English and American law. A scientific discovery that happened to be made by citizens of one country (science has no nationality). Anything with strong ties to a non-English-speaking country, even if one English variety is more prevalent there (so no automatic preference for British English in France, say).

These are just a few examples that come to mind; I'm not proposing codifying them anywhere, and it could be that you'd come up with specific cases that I would judge differently from what I've written above. But hopefully it clarifies what I mean. --Trovatore (talk) 09:19, 18 January 2018 (UTC)

That's right. If the ties are not straightforward—if there is any room for argument—then TIES does not apply, and you are in the realm of RETAIN. TIES is meant to avoid disputes, never to be used as fodder for them. Unfortunately there are many editors who use guidelines such as TIES and WP:COMMONNAME to stir the pot. These guidelines should have explicit wording that they apply only when their application is virtually beyond dispute (Toronto in CanEng, Ringo Starr as COMMONNAME). Curly "JFC" Turkey 🍁 ¡gobble! 10:07, 18 January 2018 (UTC)

It's left open to editorial discretion for a reason.  — SMcCandlish ☏ ¢ 😼  22:07, 19 January 2018 (UTC)

Good point, SMcCandlish. One area of concern that I have is I don't want to risk forcing the retention of problematic language varieties (for instance ones which very few editors are familiar with, or perhaps where it's debatable whether a 'standard' variety even exists - I'm Irish and I've lived most of my life in Ireland, but I'm not too sure what is and is not to be deemed part of 'standard' Hiberno-English, though admittedly this has never stopped me editing articles about Ireland that are presumably all supposed to be written in the afore-mentioned 'standard' Hiberno-English). As I'm still looking for editors' feedback, if it's not too much trouble (if it is, please don't bother) can you perhaps suggest some other reasons why editorial discretion might be wanted, perhaps especially in the context of whether it would be a bad idea to give a few guidelines and/or examples of what should usually not be deemed a strong national tie? (I also suspect there's a case for having different recommendations for newly-created or planned articles compared to already existing articles, such as recommending that a new article about a German ship that only fought the British should ideally be in some variety of British English, but that existing such articles should stay as they are, though that is perhaps a separate issue, and perhaps also not worth worrying about)Tlhslobus (talk) 08:45, 23 January 2018 (UTC)

My view is that "only fought the British" is too tenuous a connection to be worthy of consideration. I would not support adding any recommendation that such thin reeds be used to decide the variety even for new articles. --Trovatore (talk) 08:50, 23 January 2018 (UTC)

Fair enough, Trovatore, and thanks for all your useful feedback. But would you then support mentioning it as an example of something that should NOT (or perhaps 'usually not') be considered a strong national tie? Tlhslobus (talk) 08:58, 23 January 2018 (UTC)

I would. Curly "JFC" Turkey 🍁 ¡gobble! 09:30, 23 January 2018 (UTC)

Thanks for all your useful feedback, Curly "JFC" Turkey.Tlhslobus (talk) 21:57, 23 January 2018 (UTC)

I concur with "TIES is meant to avoid disputes, never to be used as fodder for them." Yet it's more and more being used to feed than prevent dispute. See subthread below for picking up where we left off in fixing that. PS: I also agree that "a German ship that only fought the British should ideally be in some variety of British English" is too tenuous a connection, and it's a RETAIN matter.  — SMcCandlish ☏ ¢ 😼  09:39, 23 January 2018 (UTC)

Thanks, SMcCandlish, and thanks for all your other useful feedback. But, as I already asked Trovatore, would you then support mentioning it as an example of something that should NOT (or perhaps 'usually not') be considered a strong national tie (or would you instead prefer to avoid doing so, perhaps per your above mentioned need to keep things flexible)? Tlhslobus (talk) 21:57, 23 January 2018 (UTC)

I don't feel strongly about it either way. Examples are often helpful, as long as people don't take them to be an exclusive list of cases/situations.  — SMcCandlish ☏ ¢ 😼  23:14, 23 January 2018 (UTC)

Thanks for the useful feedback, SMcCandlish. I think I now have enough feedback to think about whether I want to make a preliminary proposed change or not (perhaps sometime in the next few days).Tlhslobus (talk) 01:17, 24 January 2018 (UTC)

Revisiting the pointless profusion of ENGVAR templates

One issue – and we do need to qualify this – is that ENGVAR only applies to dialects that exist in a formal written register. That appears to mean American, Canadian, and "British" for certain. I've yet to see any credible evidence that Australian, New Zealand, Australian, South African, Irish, Indian, Hong Kong, etc., exist in the formal register distinctly enough from British English that they can be codified in a meaningful way that would affect how we write articles here. I.e., they're all Commonwealth English, and almost totally conformant, in formal writing, with the major British style guides, which are usually the only ones used as references in these countries. Most of them produce no reputably published style guides of their own. Australia does, kinda-sorta, but only a) one very infrequently updated government-published manual that is widely excoriated including by Australians, and b) one published by Cambridge (if I recall correctly) that is actually just a copy-paste of their British one with a handful of tweaks.

The notion that you can write articles in pidgin dialects like Jamaican and Philippine English is false. For some reason (namely blatantly nationalism) we have a large number of ENGVAR-related "This article is written in ..." assertion templates. A couple of years ago, these were mostly deprecated in an RfC here (a WP:TFD-preliminary discussion), but the cleanup effort got derailed after someone flat-out misrepresented the nature and intent of the RfC at WP:VPPOL and started an "anti-RfC" that stalemated the situation. We need to revisit that. I'm thinking we should probably end up with templates only for American, Canadian, and Commonwealth English.
 — SMcCandlish ☏ ¢ 😼  09:39, 23 January 2018 (UTC)

Interesting viewpoint, though it's clearly contrary to MOS:TIES in its current ('consensus'?) form, as that currently gives the following examples:

Afrikaner (South African English)

American Civil War (American English)

Australian Defence Force (Australian English)

Christchurch (New Zealand English)

Great Fire of London (British English)

Muhammad Ali Jinnah (Pakistani English)

Mumbai (Indian English)

Vancouver (Canadian English)

Institutions of the European Union (British or Irish English)

Presumably after Brexit next year there will be demands that articles on the Institutions of the European Union will all have to be changed to Irish English per the above example. Incidentally I'm not at all sure that there are no proper published (or at least accessable on request) style guides for Irish English - I would think that 'registers' like The Irish Times and RTE have one each (and quite likely so do some other Irish media outlets), and, I would expect, so do Irish Government Information outlets (whose style guide(s) is/are possibly or probably obtainable under Ireland's Freedom of Information Act). And they need them for things like accents on words like Dail (needs an accent on the a) and RTE (needs an accent on the E) as well as writing Ireland rather than Irish Republic, Taoiseach rather than Prime Minister, Derry rather than Londonderry, Ireland and Britain rather than The British Isles, etc. And I would expect that English media in countries like India and Pakistan have similar guides to meet similar needs (such as writing Lok Sabha rather than Parliament in India, and Mumbai rather than Bombay, etc, and writing Qur'an rather than Quran or Koran in Pakistan) and so on ad infinitum. And it's not at all clear that British (which actually has English, Welsh, and Scottish 'standards' and 'registers', at least according to the relevant articles) and American English have any official style guides, as opposed to a plethora of often conflicting unofficial ones (almost as many as there are major media outlets, as most of these seem to have their own style guides). Tlhslobus (talk) 21:31, 23 January 2018 (UTC)

This just points out why I'm on the right track. Brexit and the EU have nothing to do with language and dialects thereof. This is all extraneous political nationalism.  — SMcCandlish ☏ ¢ 😼  23:16, 23 January 2018 (UTC)

English is one of the official languages of the EU. If Britain were no longer a part of it, are you confident there'd be no claim to having EU-related articles moved to formal Irish English?—assuming there are significant differences that would affect the articles (I wouldn't know). This sounds like one of those edge cases ENGVAR maybe isn't prepared to deal with. Curly "JFC" Turkey 🍁 ¡gobble! 23:24, 23 January 2018 (UTC)

There is no difference, that WP needs to care about, between formal written British and Irish English (it's a difference of accents and of colloquial vocabulary like gansey for what the British call a jumper and North Americans call a sweater). Articles on rockets, sea lions, Madagascar, or the Rape of Nanking written by a Irish person would not be distinguishable from ones written by native speakers from England, South Africa, Australia, or Hong Kong, but you would be able to tell if the writer were from the US or (maybe) Canada. We need to get rid of these divisive, politicized, WP:BATTLEGROUNDish templates and retain only those that identify solidly sourceable differences in overall form of English and the register in which WP employs it.  — SMcCandlish ☏ ¢ 😼  06:26, 24 January 2018 (UTC)

Sorry, as I had already pointed out below, it's not simply accents and words like gansey, it's also about outlawing a fairly large (and sometimes surprising) list of expressions like British Isles and Irish Republic and words like Londonderry and Eire (my inclusion of Eire and Irish Republic are intended as instances of what may seem surprising to those unfamiliar with the issues), all of which are liable to cause nationalistic Battleground behaviour by both Irish and non-Irish editors in articles about the EU (and probably also in many EU documents after Brexit, always assuming they don't already do so before Brexit). It is a matter of opinion whether this is a difference 'that WP needs to care about', but the battleground behaviour by both sides is difficult to resolve and has thus been going on intermittently for decades or centuries outside WP (both linguistically and in literal battles, in both Ireland and, in modified form, everywhere else across the former British Empire such as India, Pakistan, South Africa, etc), and is thus liable to occur within WP whether WP cares about it or not. However WP can at least in theory try to minimize it by putting clear consensus guidelines and policies in our rules, though in practice I don't know whether that is what we are now wisely trying to put in place, or whether that is what we already have and are now unwisely in danger of tearing up (but the latter risk is increased if we are misinformed about the nature of the differences involved).Tlhslobus (talk) 13:28, 24 January 2018 (UTC)

Given the current wording of MOS:TIES, I would expect attempts to slap Irish English templates on the EU articles even when no other change was needed at the time. I would also expect attempts to remove expressions like British Isles and words like Londonderry from any such EU articles in which they appear. Whether any such attempts would succeed is unclear. It is also unclear whether there is such a thing as formal Irish English (at least as far as most Wikipedians are concerned). My common sense and my experience tell me there is (even if I'm only consciously aware of a few of the details, and even if I suspect the differences are too small to constitute a proper dialect, as distinct from a mere linguistic variety). But my common sense and my experience are Original Research unless their conclusions are mentioned in Reliable Sources, and I'm not sure there are any such mentions. And even if there are such mentions it would still be open to argue that the EU itself continued to use British English, not Irish English (and there might even be Reliable Sources that said this), and that I-forget-where-else it says we're supposed to use the variety of English used by an international organisation in articles about it (which is yet another instance of a conflict between MOS:TIES and other rules elsewhere). Tlhslobus (talk) 01:12, 24 January 2018 (UTC)

Quite likely it could also be argued that Malta is an EU member which has English (British and/or Commonwealth and/or Maltese variety?) as one of its official languages, which could either allow the retention of British English, or lead to a row over whether there was such a thing as formal Maltese English.Tlhslobus (talk) 02:00, 24 January 2018 (UTC)

You're probably right, SMcCandlish, that it's all political nationalism (including also the insistence on having both British and American English articles, but let's not get into that). But political nationalism is something we're stuck with in this world, in Wikipedia as elsewhere, so I rather doubt whether there's any such thing as a 'simple sensible fix' that can achieve consensus support - and if there is in fact such a fix I have no idea what it is.Tlhslobus (talk) 01:29, 24 January 2018 (UTC)

I'll outline one in an RfC below. We're stuck with a million kinds of PoV pushing in the real world that we dispense with on Wikipedia; there's no reason for this to be specially different.  — SMcCandlish ☏ ¢ 😼  06:26, 24 January 2018 (UTC)

Comment 1 - TLDNR (but the first bit). Comment 2 - Au Eng accepts some American spellings (per Macquarie dictionary). It is probably not too unlike Canadian Eng in that respect. An article can be written in either Br Eng or Am Eng or something that accepts the spelling of a particular word in either - so long as it is consistent. Perhaps the biggest difference in language is in "colloquial" words and terminologies and words - but this is otherwise covered by the MOS. The indirect issue is things like date formats, that might be defined by a "language". One could say, if it is written consistently (particular words spelt the same in the same context [and dates etc]), then keep it (them) the same. Regards Cinderella157 (talk) 15:09, 5 February 2018 (UTC)

There's long-standing consensus at WT:MOSNUM that WP:ENGVAR and WP:DATEVAR are not strongly tied to each other, and are separate guidelines for a reason. For example, articles on the US military use DMY dates, following military standards. This is another of those common-sense thing. No one needs to be told that, on average, US articles are going to use MDY dates and those written in non-North American English are likely to use DMY. It's actually permissible to write an article (or make one a non-stub) using British English and MDY dates; it's not really an ENGVAR matter. However, if you did this, it's likely that a consensus discussion on the talk page would favor changing the date format to DMY to match reader and editor expectations better. Remember that the *VAR guidelines are not laws, they're provisions that direct us to have consensus discussions rather than change certain things willy-nilly, and only after failure to come to consensus to default to what was done in the first major (non-stub) contribution. Ergo, it's very unlikely that DMY would survive in a BrEng article, rather likely that it would in a CanEng one, and virtually guaranteed that it would in an AmEng one unless the context (e.g. military) strongly suggested MDY – not because of any rules and "enforcing" them but because of WP:COMMONSENSE and WP:CONSENSUS.

PS: Whether an American spelling appears in an Australian dictionary is probably not very relevant; British spellings also appear in most American dictionaries, and vice versa. We'd need to see that the majority of Australian dictionaries favour an American versus British spelling. And even then this is no cause for annoying banner templates or other "Australian English" labeling; the existence of a consensus to prefer an American-leaning spelling over a British-leaning one, based on RS about usage, is sufficient to use the Americanized spelling in a article about an Australian topic, without any templated chest-beating.
 — SMcCandlish ☏ ¢ 😼  18:58, 13 February 2018 (UTC)

I am disappointed that you continue to push this, in the face of broad opposition. The points you make about Australian could apply equally to Canadian, and you have never properly justified why your proposal singles out Canadian for exceptional retention. Your use of the term non-American English betrays the cultural bias in your proposal. Your use of the term Commonwealth English is clearly inappropriate given that Canada is a leading member of the Commonwealth yet excluded from this template under your proposal. And you might wish to review your earlier post on date formats; you may have confused yourself regarding DMY and MDY? MapReader (talk) 06:27, 14 February 2018 (UTC)

MapReader: How familiar are you with CanEng? The reason CanEng othography is singled out is that it really is irreconcilable with either BrEng or AmEng. Can you give an example of formal AusEng orthography that couldn't be reconciled with BrEng orthography? I ask because I don't know, and you seem to suggest that CanEng articles could actually be written in Commonwealth orthography.

You haven't given an example yourself; the WP articles for both Canadian and Australian set out how these are mostly a mix of British and American spelling and vocabulary, each with some unique features. But I do not seek to downplay Canadian English, in the slightest - my point is simply that the proposal for "American", "Canadian" and "Other" ('Commonwealth' clearly being the wrong title) is being put forward from a perspective of North American bias that is inappapropriate for a global encyclopaedia. MapReader (talk) 07:10, 14 February 2018 (UTC)

MapReader: "You haven't given an example yourself"—"The driver was colourblind and, on the way to the theatre, drove the car over the curb when she failed to realize the traffic signal had turned red, resulting in a flat tire." This isn't just "acceptable" CanEng orthography—if the spelling were made more American or British, it would become unacceptible CanEng. "Colorblind"/"theater" and "kerb"/"tyre" are unacceptable in CanEng—the only acceptable alternate spelling is "realise" for "realize". This is what I mean when I say CanEng orthography is irreconcilable with either BrEng or AmEng orthography. Do you have an equivalent in AusEng orthography? SmC tells us that Tony1 says there isn't. Curly "JFC" Turkey 🍁 ¡gobble! 07:35, 14 February 2018 (UTC)

I have no particular expertise in Australian to offer, but ISTM that it would be possible to construct such a sentence with different spellings from any of the dialects listed here where there are varying forms in use. Canadian is special but not uniquely special. Further, I see that this WP article cites the Cambridge Encyclopedia of the English Language as stating that the principal branches or strands of English are British (Isles), North American, and Australasian. MapReader (talk) 07:58, 14 February 2018 (UTC)

MapReader: "... the Cambridge Encyclopedia of ..."—You seem to be forgetting that we're talking orthography. Spoken Canadian definitely falls sqaurely within "North American", and WP:COMMONALITY demands CanEng articles to default to vocabulary and grammatical constructions not limited to CanEng. It's strictly orthography that makes CanEng an exception at en.wp. Curly "JFC" Turkey 🍁 ¡gobble! 21:31, 14 February 2018 (UTC)

To respond to MapReader's "How familiar ..." reply to my latest post, point-by-point since this has been separated by so much later material and the points are not closely related to each other:

• "I am disappointed that you continue to push this" does't make sense. I didn't "continue to push" anything; I pointed out two clear facts: 1) ENGVAR and DATEVAR are not slaved to each other. 2) Apearance of a spelling in a dictionary doesn't mean anything; what matters is aggregate preference one of spelling over another in a majority of dictionaries written for a particular dialect.
• "in the face of broad opposition" is a distortion; there's plenty of support here as well, and the opposition arguments are weak, mostly argument to emotion, and assertions without any backing.
• "you have never properly justified why your proposal singles out Canadian for exceptional retention" – Patently false statement. I was quite explicit that Canadian English is the subject of multiple, reputably published style guides and dictionaries, published for several decades and based on search like nation-wide usage surveys and corpora built from Canadian publications. Meanwhile, Australian English seems to have only one notable dictionary and one notable style guide; the latter is just for governmentese and is widely criticized even by Australians (i.e., it is not actually a reliable source for anything other than what the .au government writes; it is the .au equivalent of the .us Government Printing Office Style Manual, another work no one follows but bureaucrats).
• "The points you make about Australian could apply equally to Canadian" isn't true at all. Canadian English cannot be generally represented in either American or British/Commonwealth orthography; it's isn't one or the other with an occasional maybe-an-exception-according-to-one-dictionary; it's a wild blend of them, veering back and forth (but doing so in increasingly regular and codified patterns, which makes it a recognizably distinct written dialect, which Australian is not).
• "Your use of the term Commonwealth English is clearly inappropriate given that Canada is a leading member of the Commonwealth yet excluded from this template under your proposal" – We've already been over this red herring; I'll quote my earlier response to this: "The term Commonwealth English wasn't invented by us, and does not mean "English exactly as spoken in every single Commonwealth of Nations country", it means English as generally used in most of them; it's a blanket term, and it could not be any other way, since even British English isn't one monolithic thing, but a widely ranging dialect continuum .... Whether the term, as one to use for an ENGVAR categorization and template, is 'perfect' or not is immaterial; it's close enough. It's a well-documented term, and the fact that Canada doesn't fit the pattern entirely isn't consequential." I.e., you're engaging in the fallacy of equivocation, trying to redefine the term on-the-fly to mean what you think it should mean, or what it would be convenient to you for it to mean, rather than what it usually connotes in the real world. CanEng is generally excluded from Commonwealth English by the actual meaning and usage of the term, though our stubby article doesn't go into it very much. But it doesn't matter anyway. The point of the thread isn't "use this term and force everyone to be happy with it", it's "stop abusing ENGVAR with templates that serve no purpose but anti-collaborative nationalism". We could use some other term, like "non-North American English", "world English", "international English", or "global English" (all RS-attested terms, and sometimes capitalized as "Global English", etc.). This is not an argument about a term, so please stop trying to turn it into one.
• "you might wish to review your earlier post on date formats; you may have confused yourself regarding DMY and MDY" – Not sure what post you mean. My 18:58, 13 February 2018 (UTC) post uses DMY and MDY as intended. The point is that MDY ("February 14, 2018") is generally the default in North American writing, with exceptions like military topics, and DMY ("14 February 2018") is generally the default otherwise, but this is not because of ENGVAR rules, it's because common sense and consensus lead it there. Not everything is a matter of rule thumping, and the fact is significant that people with the misconception that date formatting is an ENGVAR matter and that DATEVAR isn't its own guideline (and that ENGVAR is some rule to push to start with when it is actually the if-consensus-discussion-has-failed last resort) tend to overlap with people who think that every spoken dialect deserves a template for "enforcement". It's entirely the wrong conceptualization of what MoS is for and how it works.

 — SMcCandlish ☏ ¢ 😼  08:51, 14 February 2018 (UTC)

That's a lot of characters to dismiss all of the arguments and evidence you don't like, including our own WP articles on varieties of English, try and muddy the water on the aspects of your proposal that dont work such as the terminology, skip over the key point that your proposal is being made from a partial North American rather than a global perspective, and still not notice that your DMYs and MDYs are all mixed up? ;) MapReader (talk) 11:00, 14 February 2018 (UTC)

Re-deprecate and merge the ENGVAR-related templates that do not serve an encyclopedic purpose

Issue statement:
We have arrived at a bewildering profusion of ENGVAR-related templates, the only purpose of which seems to be advancing nationalistic viewpoints. For those not reading the discussion above this one, the short version is that in an encyclopedic, formal register, there is no meaningful difference between English, Scottish, Irish, Australian, New Zealand, African, Hong Kong, etc., varieties of English, only between Commonwealth English as a dialect continuum and the North American varieties (American English, and Canadian English which is a hybrid of American and British/Commonwealth). Commonwealth English is based on UK-published style guides; there are virtually no reliably published style manuals for Commonwealth dialects that are not produced in England in particular (by contrast, US and Canadian English are the subject of multiple mainstream style guides published in those countries).

Concrete proposal:

• For WP purposes, we would just a {{Use Commonwealth English}} template with a {{Use European English}} redirect to it (since Ireland is not part of the Commonwealth at present). That will cover the full gamut of non-North American dialects of English following the style most often called "British".
• We would retain {{Use American English}} and {{Use Canadian English}} to cover the North American written dialects. Canadian is essentially a hybrid of US and British, and there are multiple, reputably published style guides for both US and Canadian writing.
• This would take care of the quiet, categorizing templates in Category:Use English templates; the big talk-page and editnotice banner equivalents (e.g. {{American English}}, etc.) in Category:Varieties of English templates would also be merged into a corresponding set of templates.
• Categories used would also, naturally, be merged as needed.
• MOS:ENGVAR and MOS:TIES would be clarified and shortened, no longer suggesting that things be written in Pakistani English, etc., which is essentially meaningless with regard to encyclopedic prose.

 — SMcCandlish ☏ ¢ 😼  06:36, 24 January 2018 (UTC)

A similar but weaker and more dispute-prone solution would be to retain all the "Jamaican English", "Scottish English", "Hong Kong English", etc. nonsense template names, and redirect them to Commonwealth English, with a category up-merge. This would still result in nationalism-inspired tagging, but maybe with reduced potential for actual edit-warring over style matters.

Rationale:
We already resolved to deal with this problem once, several years ago, only to have the RfC which concluded to deprecate and merge away most of these templates get stalemated by a counter-RfC that seriously misrepresented the original one. More than enough time has passed to revisit this and break the deadlock. We've permitted, by inaction, the hijacking and proliferation of linguistic templates, for jingoistic, nationalistic posturing which serves no interest but WP:NPOV violation. It's actually worse, in that politicized language forking (like that promulgated by Noah Webster, by the USSR forcing intentionally divergent forms of Cyrillic on subject populations in Asia, and by various machinations of a nationalistic character in the former Yugoslavia) is destructive, harming mutual intelligibility. No WMF project should be bent toward such an end, not even a little at a time with the best of alleged intentions.

Of more immediate concern are:

1. Nationalistic conflicts at articles (e.g. re-branding all EU articles as "Irish English" or "Hiberno-English" after Brexit).
2. Misuse of ENGVAR arguments to lace articles with colloquialisms instead of following WP:COMMONALITY.
3. Assertion of dialects like Trinidadian and Sierra Leonean which have no formal register at all other than what's generally called Commonwealth or "British" English; this is being done just to stake a claim, and most of the profusion of big, annoying ENGVAR banners can be traced to a handful of singleminded editors tagging page after page despite lack of any dispute in evidence.
4. Templates in Category:Varieties of English templates do not map onto those in Category:Use English templates; people have been randomly creating nationalistic templates without any regard for what they're for or whether they make sense (other than claim-staking) {{Sierra Leonean English}}? Seriously?

 — SMcCandlish ☏ ¢ 😼  06:36, 24 January 2018 (UTC)

Survey on ENGVAR template proposal

• Support merging down to three templates: Commonwealth/British/etc., American, and Canadian. As the OP notes, formal style guides for English writing essentially recognize these three styles, and there does not exist a formal, written form of many forms of vernacular English which is meaningfully different from one of these three written forms. If there is, and someone can produce several, we may modify this to include those as a possibility, but absent that, the proposal makes sense. --Jayron32 13:34, 24 January 2018 (UTC)

• Oppose. It is unclear whether what is being proposed here is essentially that Commonwealth counties (other than Canada - so immediately there is a terminology problem) should follow British English - in which case this should be the proposal, presented honestly and transparently - or whether some sort of amalgam "Commonwealth English" - which doesn't exist anywhere - is being proposed to try and bundle all of the smaller differences in usage into a category that is distinct from American and Canadian (and what is so special about Canada anyway - it uses a mix of British and American constructions, plus some unique vocabulary, just as you'll find, with different elements, in Australia). And it would be a nonsense to have a set of categories for 'varieties of English' without one for its parent country. And even more of a nonsense to have to make changes to the vast library of British historical, geographical and cultural articles on WP to conform with some new non-existent variety of "Commonwealth" English, in instances where it differs from British usage. And we're going to keep the bits of the MOS that direct to following the particular styles of individual authors or organisations, in articles about them, yet deny a country the size of Australia its own linguistic nuances in all of the articles about that country? Really?? So an article about an Australian author or organisation can be written in Australian English, but not an article about Australia itself? Whoever proposed this hasn't given the implications much thought, ISTM, and whatever problem this solution is trying to solve would surely end up worse rather than better, if we try to implement it. MapReader (talk) 14:36, 24 January 2018 (UTC)

And, besides Australia, you might (per WP:WORLDWIDE (aka WP:BIAS), WP:CSB, and WP:WER (assuming we wish to retain editors from places like India), etc) have added a country the size of India, whose English-speaking population, estimated at 125 million (see Languages of India), outnumbers that of any country except the USA, while its total population of over 1.3 billion is far more numerous than all the world's English-speakers put together. So arguably we should 'logically' scrap British English and (non-existant?) Commonwealth English and just keep Indian English (and presumably American English, though even that could 'logically' be debated). Tlhslobus (talk) 15:21, 24 January 2018 (UTC)

• Oppose: per MapReader above, per WP:WORLDWIDE (aka WP:BIAS), WP:CSB, and WP:WER (see my comment above), and per misleading/misinformed elements in the proposal (see my comment below in the Discussion section).Tlhslobus (talk) 15:50, 24 January 2018 (UTC)

And also (as already mentioned below in my comment and questions of February 3rd, and in my reply below to Blueboar at 15:50, 30 January 2018 (UTC)) per the apparent folly of a group consisting largely or entirely of Westerners repeating the same mistake we made a few years ago, which will presumably eventually be reversed once editors from the affected countries (both Western and non-Western) get to hear about it, just as happened last time, but not before a lot of unneccessary harm has been done to Wikipedia through wasted time and pointless inter-cultural unpleasantness, and pointless damage to Wikipedia's reputation in the affected countries, with negative consequences for retention of good editors from those countries, while simultaneously attracting many POV-pushing ultra-nationalist editors from them to resist what they would presumably see as 'the Western imperialist racists', etc... Tlhslobus (talk) 05:56, 7 February 2018 (UTC)

• Currently oppose, but it is indeed unsettling to think most readers might encounter peculiar English in an article about Jamaica. However, MOS:COMMONALITY covers the the basic need for articles to be comprehensible to all readers. It should already be clear that colloquialisms and idioms are not allowed in articles, and if it isn't clear, that should be added. As stated above, this proposal concocts a "Commonwealth English" which does not clearly exist, and creates a bias against certain English-speaking countries. Then again, if Singapore had some peculiar grammatical rules (for example) this would call into question the very basis of ENGVAR. I also would not like to see European Union articles caught in a tagging dispute between British and Irish English when the distinctions are trivial, and to me, as an American, Irish English seems irrelevant when trying to read an article about the European Union. —DIYeditor (talk) 19:57, 25 January 2018 (UTC)

The EU question is an interesting side-issue (as Ireland currently nominates Gaelic and Malta Maltese, and one will need to change if English is to remain an official EU language, unless a more pragmatic solution is reached), but the ENGVAR issue is resolved by the existing MOS provision that for organisations the style follows that of the organisation. I doubt the EU will be introducing Irish-specific nuances to English style or vocabulary, even if Ireland changes its linguistic nomination. (The existence of the organisation-provision is, as I say above, a further reason why the proposal doesn't make logical sense) MapReader (talk) 20:17, 25 January 2018 (UTC)

Actually English is an official language of the EU and will remain one after Britain leaves, and this will not require any change by Ireland or Malta (and it would remain one even if both Ireland and Malta were to leave too). However as far as I know the variety of English used is not officially defined. It is already somewhat influenced by Irish English in practice (for instance its official documents are supposed to use the misleading Irish English expression Ireland instead of the British English expression Irish Republic, a rule which, incidentally, we already largely have in Wikipedia too, quite likely largely as a result of this EU practice). And this influence will presumably gradually increase if Britain leaves. Meanwhile MOS:TIES is currently in conflict with the MOS organisation provision (and MOS:TIES logically takes precedence by explicitly stating that EU institutions should be dealt with in British or Irish English). But none of this should matter too much to us in practice, as explained below.Tlhslobus (talk) 03:48, 28 January 2018 (UTC)

And in any case the EU issue won't arise for another 14 months, and will only ban British English in the seemingly unlikely event that we then modify the current example in MOS:TIES so as to ban it (for which there will probably be no consensus). The current proposal is not required to handle that issue, if and when it arises. (All we are likely to have is a few almost certainly unsuccessful attempts in March 2019 to ban British English for EU articles, but these should be fairly easily seen off at the time) Tlhslobus (talk) 03:03, 28 January 2018 (UTC)

• Oppose per Mapreader. The assertion that there are no significant differences between varieties such as Australian, Indian, South African, Jamaican, etc. is unproven. There are many authorotative grammars and dictionaries for at least some of these varieties which demonstrate their evolution away from the British "mother" variety. It is obvious nonsense to assert that only North American English varieties have undergone such divergence. Roger (Dodger67) (talk) 12:34, 30 January 2018 (UTC)
• Oppose per MapReader and Tlhslobus. There are in fact many distinct dialects or versions of English, with significant differences, which is why there are articles about them – see Scottish English, Australian English, etc. There's no article on Commonwealth English because there's no such thing: Commonwealth English is a redirect to English in the Commonwealth of Nations which ironically is an article that discusses the variations of English across the Commonwealth and points out in its lead that "many regions, notably Canada, Australia, India, New Zealand, Pakistan, South Africa, Malaysia, Brunei, Singapore and the Caribbean, have developed their own native varieties of the language." — Stanning (talk) 16:45, 30 January 2018 (UTC)
• Support, as something that reduces the number of Englishes used and bickered about in English Wikipedia and/or removes Wikipedia from the role of legitimizing nations. Bryan Henderson (giraffedata) (talk) 17:44, 2 February 2018 (UTC)
• Weak oppose. I sympathize with the underlying reasoning, but I don't think it's worth the hard feelings. See my more detailed comments in the discussion section. --Trovatore (talk) 21:21, 2 February 2018 (UTC)
• Support The original British and American English templates were meant to discourage situations where an American editor 'corrects' an article to all American spelling, followed by a British editor 'correcting' it to all British spelling, and endless bouncing between the two. This was fine. But the other country specific templates are just exercises in flag waving. As SMcCandlish pointed out above, Australians using 'servo' for 'service station' or 'petrol station' is just slang. Since WP is meant to be understandable by the majority of English speakers (both native speakers and those that learnt it later), it is not a good thing to promote localised languages that can only be understand by a limited number of readers. Like it or not, practically all English speakers favour either British English or American English. Some may be a blend of the two (eg Canada and my native Australia) or a blend of one of them with a different language (eg 'lakh ' in Indian English) but they still understand British and American English. I find it jarring when I read an article and find a phrase like '10 lakh ' that could have used the widely understood '1,000,000' or '1 million'. I would gladly agree to lose the use of my native Australian English on WP if it meant that a wider audience could read the articles.  Stepho  talk  13:26, 5 February 2018 (UTC)
• Support As explained above, the purpose of ENGVAR is to stop edit wars regarding color/colour etc. There is no evidence showing any encyclopedic purpose would be served by encouraging the proliferation of language quirks. Text such as "in the year 1984" should be corrected to "in 1984" regardless of a tag someone thoughtfully added to the article. Johnuniq (talk) 23:41, 5 February 2018 (UTC)
• Support – If we're going to try to get editors to respect established variants, we can't have more of those than are well documented. Three seems good. Dicklyon (talk) 07:30, 12 February 2018 (UTC)
• Support, in principle. The only templates that are needed are those that flag up actual, practical difference in *formal*, *written* English, to help readers and editors understand why, respectively, certain things might look odd to them or need to be written in a certain way for consistency. This shouldn't be about slapping flags on pages or declaring ownership. There are 101 dialects of English, but WP is not written in dialect or slang. As pointed out, there are probably at best three or so broad "styles" of formal English when it comes to significant spelling, grammar etc distinctions. N-HH talk/edits 22:08, 15 February 2018 (UTC)
• Oppose as currently phrased. RfCs should be neutral; this one isn't. The very title, "that do not serve an encyclopedic purpose", is already loaded, and in the proposal itself I read "the only purpose of which seems to be advancing nationalistic viewpoints". That these don't serve a purpose should be the result of an RfC, not its premise, and that they "advanc[e] nationalistic viewpoints" suggests a lack of good faith (really), as if all of those editors are nationalists who use Wikipedia only as a platform. I'm somewhat disappointed to see Giraffedata make a similar point: Bryan, I know you as a conscientious editor, not as a politically-inclined prescriptivist. "Reduc[ing] the number of Englishes" is not one of our pillars and shouldn't be; if it were, we might as well throw a coin and call AmE or BrE, or have a shootout--why would we need more than one if reduction is good? Morever, "legitimizing nations" repeats the same mistake made in the beginning of the RfC, with the additional problem of confusing nations with languages.

  Babylonic confusion and needless proliferation of templates is not a good thing, of course, but this is not the way. The first way should be science, not politics--the science of linguistics. Between BrE and AmE are legitimate differences of spelling, and some (minor) syntactical differences. If it turns out that, say, formal writing in Singaporean English cannot be distinguised from regular BrE (or whatever), then that particular template/distinction can be dropped. But this way, to get rid of them wholesale with the premise that only two (or three?) Englishes are legitimate and thus suitable, that is not the proper way to do it, and smacks of (yes) systemic bias, and if we throw in "nations" (I didn't, proponents did), then we're open to the charge of linguistic, encyclopedic colonialism as well.

  (For the record, I wouldn't have been here if Tlhslobus, whom I don't believe I know, hadn't left me a note--but they wrote me only, as far as I know, and while their note was more desperate than neutral, I don't think they could have guessed how I would come down on the matter.) Drmies (talk) 16:33, 16 February 2018 (UTC)

• Oppose - this is just not very well thought out. To a Canadian, "color" and "honor" are misspellings, as are "tyre" and "aluminium", and if we impose that Canadian articles must now use one or the other foreign dialects of English from now on, each and every one of those articles will more or less immediately join a nationwide edit war the likes of which Gord Downie would have written an epic ballad about, had he not passed last year. And you'll all think it's amusingly polite but it will really be laden with passive-aggressive yet bitter personal attacks that only a Canadian would recognize, probably involving beer, hockey, the status of Québec as a distinct society, and farm animals. That being said, Canada is a likely outlier in this discussion; perhaps there are some useful takeaways here: articles adhering to different varieties of English should still strive to be mutually intelligible to all English readers, as some have pointed out; using local jargon and slang in an article is what's unencyclopedic, not the standardized use of a broadly-recognized dialect. If an article on a Scottish topic is describing "wee bairns" throughout it should be cleaned up, or perhaps transwikied to the Scots Wikipedia. And I'll also say that if there are going to be templates enforcing the use of a particular flavour of English, then there need to be corresponding on-wiki style guides explaining what quirks those flavours entail. In the Indian example given somewhere above, it ought to be written in a style guide (I think it is already) not to use measurements of lakh or crore exclusively in an article, and perhaps a template created along the lines of {{convert}} to automatically convert those numbers to widely-recognized formats inline. Ivanvector (^Talk/_Edits) 16:54, 16 February 2018 (UTC)
• Oppose as written, if you want to eliminate all English varieties besides US or UK, or US, UK, and Canada, or US, UK, Canada, and Australia, or some grouping thereof, (add and subtract as required), that is a reasonable request. I could even possibly get behind reducing to simply US and UK (by begrudgingly using US spelling for Canadian articles and UK spelling for Australian, Indian, etc., for example as they have the most similarities). However to say "everything which isn't US, UK, or Canadian falls under Commonwealth English" is preposterous as it simply doesn't exist. If Commonwealth English were actually a thing, it would be what we would have been using for the last 10-15 years. --kelapstick^(bainuu) 16:59, 16 February 2018 (UTC)

The proposal is actually worse even than that, because it abolishes the British (UK) English template as well. MapReader (talk) 20:01, 16 February 2018 (UTC)

Discussion on ENGVAR template proposal

• Comment

• 1) At least for now, I am broadly neutral on the proposal I've now switched to oppose (see my above vote)
• 2) But I think at least two parts of it is arguably misinformed and misleading:

• 2b) These are:

• 2b1) The assertion in the Issue statement that "For those not reading the discussion above this one, the short version is that in an encyclopedic, formal register, there is no meaningful difference between English, Scottish, Irish, Australian, New Zealand, African, Hong Kong, etc., varieties of English, ..."
• 2b2) The assertion, in relation to modifying MOS:TIES and MOS:ENGVAR, that being told to write things in Pakistani English, etc, is 'essentially meaningless with regard to encyclopedic prose'.

• 2c) I don't know much about Pakistani English, tho I expect that disputes over whether one writes Qur'an or Quran or Koran are involved (as well as other less inflammatory issues), a question that an encyclopedia can't easily avoid (and disputes about which are potentially so inflammatory that they just might some day get editors murdered, although hopefully that is none too likely, tho that's perhaps what people once thought at publications like Charlie Hebdo before the terrorist killings there).
• 2d) The proposer has also written in the discussion before his/her proposal, that the differences between Irish and British English are simply about accents and words like gansey, which s/he placed immediately above a comment I had already written that mentioned it was actually largely about outlawing expressions like British Isles and words like Londonderry.
• 2e) I later expanded that to say that it's about outlawing a fairly large (and sometimes surprising) list of expressions like British Isles and Irish Republic and words like Londonderry and Eire (my inclusion of Eire and Irish Republic are intended as instances of what may seem surprising to those unfamiliar with the issues), all of which are liable to cause nationalistic Battleground behaviour by both Irish and non-Irish editors in articles about the EU (and probably also in many EU documents after Brexit, always assuming they don't already do so before Brexit).
• 2f) I then added: It is a matter of opinion whether this is a difference 'that WP needs to care about', but the battleground behaviour by both sides is difficult to resolve and has thus been going on intermittently for decades or centuries outside WP (both linguistically and in literal battles, in both Ireland and, in modified form, everywhere else across the former British Empire such as India, Pakistan, South Africa, etc), and is thus liable to occur within WP whether WP cares about it or not.
• 2g) I fail to see how, at least in practice in the real world, the question of whether, for instance, an editor can or cannot write British Isles or Londonderry instead of Britain and Ireland (or should that be Ireland and Britain?) and Derry, or vice versa, is 'essentially meaningless with regard to encyclopedic prose'. For further details, see for instance Geographical naming disputes, although non-geographical issues also arise, such as job-names (deputy or TD instead of Irish MP, etc), names of institutions (Lok Sabha instead of Indian House of Commons, Seanad instead of Irish Senate, Bord Failte instead of Irish Tourist Board, etc), and so on. And see also 2c above, about the spelling of Qur'an/Quran/Koran, etc.
• 2h) However WP can at least in theory try to minimize the resulting battleground behaviour by putting clear consensus guidelines and policies in our rules.
• 2h) But in practice I don't know whether that is what we are now wisely trying to put in place, or whether that is what we already have (at least to some extent) and are now unwisely in danger of tearing up (which is why I was originally neutral on the proposal, though I've now switched to oppose, though partly for other reasons, as I'm still not 100% sure about which of the 2 possibilities mentioned here is more likely, though I'm now very much inclining towards the 2nd one).
• 2j) But the latter risk is increased if we are misinformed about the nature of the differences involved.

• 3) Meanwhile I have split the original section into Votes and Discussion sub-sections.
• 4) Regards. Tlhslobus (talk) 14:25, 24 January 2018 (UTC)

• Request: Can somebody please supply links to the Rfc a few years ago that proposed this, and to the counter Rfc that reversed it, so that we ca have a more informed discussion, and a better chance of understanding whether this proposal has a realistic chance of long-term success or is bound to be reversed if it succeeds in the short term, thereby presumably just wasting everybody's time.Tlhslobus (talk) 16:23, 24 January 2018 (UTC)

• Comment regarding Indian English. Yes, it is basically British English and it has long bugged me that consensus is to designate it separately. Attempts to discuss it hit a brick wall of Hindutva-type nationalists in past local discussions at WT:INB. The three very noticeable differences are (a) occasional use of rather archaic terms, current during the Raj era; (b) the frequent omission of "the"; and (c) a tendency not to put a space between initials in names of people. The latter two of these are particularly common. - Sitush (talk) 03:05, 30 January 2018 (UTC)

What the above comment appears to be unwittingly saying is that British English is basically the same as Indian English. And since there are about twice as many speakers of Indian English (c 125 million, see Languages of India) as British English (c 60 million), the 125 million could complain, with at least as much 'logical' justification, that it has long bugged them that attempts to discuss suppressing British English in favour of Indian English invariably hit a brick wall of British nationalists, made much worse and much more offensive by Imperialist-type British nationalists who don't merely want to keep British English but actually propose to suppress Indian English as well, despite there being twice as many speakers of the latter as the former, a proposal that requires quite a bit of charity to attribute to mere thoughtlessness or ignorance rather than something much worse. Even more charity seems needed given the vast amount of rather horrific evidence on that question from both history and current affairs, including some rather well-known offensive sayings in British English about this question, which I will charitably refrain from repeating here. It is not entirely clear to me where to find the logical error in such an Indian argument if it were put forward (always assuming that there actually is an error in it, which is far from self-evident, at least to me, and especially with regard to its second half, where it is objecting to proposals to suppress Indian English). Tlhslobus (talk) 11:27, 30 January 2018 (UTC)

I suppose it could be argued that British English is older than Indian English, but on that basis we should also be proposing the suppression of American English, which for some strange reason we are not proposing. Tlhslobus (talk) 12:26, 30 January 2018 (UTC)

Of course the irony of all this is that I'm a Westerner (and one from an archipelago first called 'The British Isles' by Roman historians about 2000 years ago) trying to defend the Indian perspective from a comment by an editor who appears, at least to me (though my impression may well be mistaken), to be an Indian defending the British perspective . I guess this just proves it's a funny old world . Tlhslobus (talk) 12:09, 30 January 2018 (UTC)

I am British. "Indian English" (such as it is, which is effectively nothing) did not exist until ca. 17th/18th century, and was uncommon until ca. late 19th century. There are plenty of people in India who do not speak any English, probably the vast majority in fact. I could check some figures if anyone is that fussed - the 2011 census probably covers it. The single most common "Indian-ism" I see is Britisher, which is a bit like using Hun every time German would suffice. I guarantee you, the nationalist issue of wanting to avoid mention of "British" is the key argument used by those at WT:INB who have favoured a separate tag. And many of them have ended up blocked or topic banned for their other activities. - Sitush (talk) 13:04, 30 January 2018 (UTC)

For the numbers, try this story, remembering that the headline figure includes second- and third-language speakers. - Sitush (talk) 13:13, 30 January 2018 (UTC)

Sorry about thinking you were probably Indian, based on the amount of Indian stuff on your user page (though I did mention that 'my impression may well be mistaken'). The story to which you link confirms that there are about 125 million speakers of English in India, adding that this is about twice as many as speakers of English in Britain. (It doesn't seem to discuss varieties). Obviously the Indians tend to speak it as a second or third language, but so what? Tlhslobus (talk) 13:54, 30 January 2018 (UTC)

The "so what" is competence. Hang around the India-related pages and you will see a massive array of competence, including a lot of people who think they can write it but in fact produce mostly gibberish (not intended offensively, as I am utterly incompetent in Indic languages and gibberish is probably my own second language). Those that are competent tend not to fall into the sort of habits that I mentioned above, nor to produce ambiguous statements etc. In addition, there is a pride issue: while ultra nationalists don't even want English to exist, some other groups like to claim an association that actually does not exist for reasons of social standing. If you don't understand the caste system etc in India, there is no way you will understand these nuances, unfortunately, but social aspirations, often based on the flimsiest of notions, give rise to all sorts of wild claims, including linguistics. And before anyone says it, I'm on record as being no fan of the Raj era, its methods and its theories. - Sitush (talk) 14:16, 30 January 2018 (UTC)

Indians presumably have no monopoly on pride, nationalism, xenophobia, or incompetence (and those Indians who are incompetent are presumably even more incompetent in British English). Finding some kind of Indian style guide, or, if none exists, getting Indian editors to gradually build one as part of Wikiproject India, using registers such as Indian Government publications and The Times of India, etc, might be a less hopelessly WP:SNOW fix than Westerners, and especially Britons, telling them they can't use Indian English for Indian articles. But I guess that's probably something that is better discussed there than here, and mainly by Indian editors rather than us Westerners. Tlhslobus (talk) 14:57, 30 January 2018 (UTC)

The Times of India is a crap newspaper nowadays. Do not be mislead into thinking it somehow has a connection to The Times of London, and do not think that huge circulation is a guide to comprehension. It is incredibly inconsistent and ambiguous in much of its reportage - precisely because of its linguistic incompetence - and is little more than a tabloid-style news organ in practice. I think you will find that the likes of RegentsPark and SpacemanSpiff will agree on this point, if nothing else that I have said in this discussion. - Sitush (talk) 01:20, 1 February 2018 (UTC)

As for "pride" etc, true, there is no monopoly. But the extent of it is probably much greater than you think. There is a reason why the entire India/Pakistan etc topic area has a notoriety that puts off even the involvement of experienced admins etc, and the issues of pride etc are fundamental to much of it. I think you perhaps lack an understanding of these issues and are trying to hard to approach it from a meta level. - Sitush (talk) 01:26, 1 February 2018 (UTC)

We can't go around creating our own definitions of languages so, no, we shouldn't be trawling through the Times of India's constructing an Indian English grammar and lexicon. Regardless of the quality of writing in that once august newspaper --regentspark (comment) 02:57, 1 February 2018 (UTC)

• Question: With both US English and UK English, there are dictionaries and published style guides that help define the variety - that can tell us what the style rules actually are. There are works such as Webster's dictionary or the OED (for spelling) and the Chicago Manual of Style or the Oxford Manual of Style (for grammar and style). My question is this: Are there similar dictionaries and published style guides for (say) Indian English or Trinidadian English (etc.) - Reference works that would help us to actually define a given national variety and distinguish them from other varieties? Blueboar (talk) 13:45, 30 January 2018 (UTC)

For [[South African English these publications are generally accepted as authorotative. Roger (Dodger67) (talk) 14:02, 30 January 2018 (UTC)

Nothing for Indian English that I am aware of. Of course, there are numerous loan words from India in British English, eg: bungalow, dhobi. - Sitush (talk) 14:06, 30 January 2018 (UTC)

And vice versa, I think (e.g. I understand practical words like 'spanner' are now used in many native Indian languages). Does the Indian Government have a Freedom of Information Act that might oblige it to release any English style guide(s) that it may use in its publications (assuming it hasn't already done so)? Tlhslobus (talk) 14:40, 30 January 2018 (UTC)

Yes, there is legislation related to freedom of information - see Right to Information Act, 2005. Don't expect much joy with it, though. The Indian legal process is dreadfully slow and, to be honest, I would be pleasantly surprised if there is any coherence on this particular issue. As for spanner, well, that word has more meanings in British English than it probably does in India: someone can be a spanner in Brit Eng slang, where it would be a mild insult, but I doubt that has entered Indian lexicography because it is a usage that would have been uncommon in the Raj era, if it existed at all.

I'm not that fussed about this entire debate, either: I regularly insert {{use Indian English}} because I accept that it is the consensus. It just narks me that there is little practical difference in well-written prose and that the template appears mainly to exist to promote nationalist/political agendas. Any lack of comprehension of British English by contributors from India has next to nothing to do with language and everything to do with education and caste prejudices etc - the desire for self-glorification etc that has no connection to omitting the or occasionally preferring cops to police, and so on. Erudite contributors from India routinely use what we would all recognise as British English, and the less erudite certainly understand it except when they are here merely to promote an agenda. Gosh, I sound so racist now but hopefully people will understand; certainly, those who frequent WT:INB will. - Sitush (talk) 01:14, 1 February 2018 (UTC)

Roger (Dodger67) wrote above "There are many authorotative grammars and dictionaries for at least some of these varieties which demonstrate their evolution away from the British "mother" variety. It is obvious nonsense to assert that only North American English varieties have undergone such divergence." So he may be able to provide you with some details. (I now see he has already done so above for South African English). I don't know of any myself (though that most definitely does NOT mean that none exist, as thankfully Roger (Dodger67) has just proved above), but there are plenty of registers in the form of newspapers like The Times of India, The Irish Times, Government publications, etc. Most probably need and thus have style guides, some of which may be published or available on request - many of the Governments have Freedom of Information Acts which oblige them to supply such information on request, tho usually for a small fee, and perhaps only for requests from its own citizens (the Irish Government definitely has such an obligation, if it has such style guides, which it probably does). Of course the problem with all such style guides, including the numerous British and American ones (but perhaps not the Canadian Government one), is that they tend to be unofficial and sometimes contradict each other - the 'logical' solution might therefore be to ban all varietes of English except Canadian English, but such a 'logical' proposal would fail WP:SNOW, for various reasons, including that it would run into a brick wall of British and American nationalists (among many others). Tlhslobus (talk) 14:10, 30 January 2018 (UTC)

In terms of major linguistic strands, I would expect most authorities to recognise Australian and South African English as equivalent in distinctiveness/status to Canadian. But the proposal here isn't to narrow down to five or six main varieties - but to recognise only American, Canadian, and lump everything else together as 'Commonwealth'. Which remains so ridiculous (advanced from an overly-narrow geographical perspective might be more polite) it is remarkable that we are still debating it days later. Narrowing down might make sense, although achieving consensus on a shortlist would remain exceptionally difficult. But the fact remains that, so long as the MOS enables the styles of individual authors and organisations to be mirrored by related articles, we are accepting a very wide variety of English language will be used in WP, and there is nothing to be gained here whatsoever. MapReader (talk) 14:20, 30 January 2018 (UTC)

MapReader: "I would expect most authorities ...": not in the case of spelling, which is where CanEng stands out from a MoS perspective. In terms of vocabulary, etc. the MoS calls for CanEng articles to conform to MOS:COMMONALITY, which means preferring "couch" to "chesterfield" and "napkin" to "serviette", even if the editor (me, for instance) grew up using the latter terms. Canadian spelling, however, cannot be reconciled with American or non-Canadian Commonwealth spellings. In what ways can formal Australian writing not be reconciled with non-Canadian Commonwealth conventions? Note: I'm not actually taking sides in this discussion. Curly "JFC" Turkey 🍁 ¡gobble! 02:26, 1 February 2018 (UTC)

It's set out in the WP article, which recognises Australian English as a major variety. Just like Canadian, Australian is mostly a mix of British and American spellings, leaning more toward British than Canadian does. Note that I am not arguing that Canadian shouldn't be recognised/accepted - simply with the OP proposal that it is so distinct that it deserves such, not only in the absence of the same for Australian, but also for British English! MapReader (talk) 05:40, 1 February 2018 (UTC)

SMcCandlish: I was taking you at your word when you characterized AusEng as more-or-less conforming to BrEng standards, but it looks like that's not the case. Curly "JFC" Turkey 🍁 ¡gobble! 22:01, 1 February 2018 (UTC)

Australia in particular: Based on what evidence? I've never seen anything to suggest that AU English is leaning unusually or increasingly toward US English, any more than other dialects are (given very strong ties between Aus. and the UK and lack of them between the former and the US, it's not plausible). Long-term MoS cat-herder Tony1, an Australian, has said this before, too; my earlier phrasing, that in a formal written register all the Commonwealth Englishes are basically indistinguishable from British aside from minor vocabulary tweaks, is a paraphrase of something he said ca. 2008, borne out by 10 years of style research. Our own article says "Among the changes starting in the 19th century were the introduction of words, spellings, terms and usages from North American English." That's true of all Englishes, including British. You'll notice that American "program" (not "programme") tends to be used for computing contexts, but this is also true in British English, not just Australian. Someone's trying to generalize from "AusEng uses 'program' and some other Americanisms sometimes" to "AusEng is a mixture of BrEng and AmEng", a logic error of not noticing that the relationship isn't unique or unusual; this is the worst form of OR. There's also lots of recent flow in the other direction, especially with the rapidly globalized uptake of BBC and other British output in the US over the last generation.  — SMcCandlish ☏ ¢ 😼  12:04, 2 February 2018 (UTC)

Anecdotally, I can testify that my generation speak of cracking a tinny while sitting on the lounge to watch telly, getting a sore arse and filling up at the petrol station (or servo). The millennials talk of having a can of beer while sitting on the sofa to watch TV, getting a sore butt (or ass) and filling up at the gas station (even though they don't say gasoline). Mostly because we are bombarded by American TV and movies. Growing up in the 1970s we had a lot of British TV shows but now it's all American and we copy what we hear.  Stepho  talk  13:36, 5 February 2018 (UTC)

Tlhslobus,I've addressed your attitude to The Times of India a few minutes ago, above. But I will refer to it here because that might get lost in the noise. As far as matters India are concerned, I think you have a significant lack of knowledge, sorry. You are the "do-gooder" coming into a situation of which you have effectively no understanding, which is pretty much what the Brits were like when they arrived in India in the first place. No offence intended - it is a common problem. Some argue that it was that lack of understanding (by the Brit colonialists) that caused all the problems related to caste that now exist, so this is not a trivial point. Unless you immerse yourself in the topic area, you know nothing that could possibly be helpful to it. - Sitush (talk) 01:35, 1 February 2018 (UTC)

Indeed, the more we dig into this matter, it is increasingly looking like an exemplar of the stereotypical "solution in search of a problem". Roger (Dodger67) (talk) 14:43, 30 January 2018 (UTC)

OK... thanks for the replies. I have a few follow up comments: Perhaps we could use the existence of an "authoritative style guide" as an initial criteria for saying whether a "national variety" actually exists (note: by "authoritative" I don't mean "official"... I am thinking more along the lines of "widely followed and influential"). If there is at least one such reference work published for country X, then we can say that country X actually has a "national variety". More importantly, we can then use the work (or works) to determine whether a given article is well written within that national variety. We can use these reference works to inform our discussions on usage, vocabulary and spelling (understanding that, where there are multiple "authoritative" style guides, they may not agree). However, if no such work(s) exist, then we can say that country X does not have a unique "national variety" of English. Just an idea. Blueboar (talk) 15:36, 30 January 2018 (UTC)

Good idea in theory. But it would probably need a completely new proposal. And in practice it would probably just waste even more time than this proposal already has, because, even if it somehow succeeded, it ignores the likely reaction of editors whose preferred variety gets banned. Even in the seemingly unlikely event that there really is no relevant unpublished style guide used by the country's main newspaper(s), it probably takes less than a day for offended nationalists to create and issue online an 'authoritative style guide' - you just take an existing style guide, make a few obvious changes, and add on a newspaper name, a date, and a claim that this style guide has been used internally in this 'authoritative' linguistic register (newspaper) for many years - it should be easy to find a newspaper that cooperates because it needs the publicity, etc; you then update it and publish a new edition as often as desired. But in the meantime we will have wasted a lot of editors' time on the debate, driven away a number of offended editors, damaged Wikipedia's reputation in the offended country, and attracted in a lot of fiercely nationalist POV-pushing new editors, all for no clear benefit. Tlhslobus (talk) 15:50, 30 January 2018 (UTC)

• Comment: Wikipedia is the encyclopedia anyone can edit. This principle leads to the idea that to recognize a variety of English, there should be sufficient published reliable sources on the variety's vocabulary and usage that a person fluent in a different variety could manage to edit an article written in the putative variety using the reliable sources. Newspapers are not such a source, because they are not organized in a way that would help the editor fluent in a different variety. Government-published style manuals should be viewed with suspicion because they may be designed to reinforce the political beliefs of the current government rather than intended to reflect the actual usage of well-educate inhabitants.

Some of the arguments above aren't really about an entire variety of English, but rather, which geopolitical words should be used in a particular article. Jc3s5h (talk) 15:03, 30 January 2018 (UTC)

Anybody can edit any article without knowing anything about English varieties. If they make a variety-related mistake (which will normally be rather rarely), then others can fix it, as with any other kind of mistake. All style guides, not just Government ones, can hide a political agenda, as has long been the standard experience of Irish people when they check the Ireland-related parts of British style guides (this is often unavoidably so, because the most contentious stylistic issues usually stay contentious because they have no neutral non-political fix). The geographical names are mentioned above as just some obvious examples of why an Encyclopedia can't simply ignore the problem (but there are plenty of non-geographical examples too). Tlhslobus (talk) 15:19, 30 January 2018 (UTC)

• Question: how do you propose to treat {{Use British English Oxford spelling}}? This variety is the same as BrE WRT diction and grammar, while resembling CanE orthographically (with a few exceptions).—Odysseus1479 17:44, 30 January 2018 (UTC)
• Comment When no formal style guides exist for a variety of a language, I don't see how we can ask that our articles conform to that variety. With Indian English, the only documented difference is in numbers (lakhs, crores) and all we get is the occasional nationalist demanding that Bangalore be moved to Bengaluru or Ganges be moved to Ganga because Engvar trumps common name. Other than that, whether there are spaces between initials or whether there are differences in the way "the" is used is pointless because we don't have a style guide to refer to and, in all likelihood, these usages are unlikely to be consistent. (It is also worth pointing out that much of the discussion about Mumbai vs Bombay centered around the common name argument so using it as an example of engvar is not really kosher.) However, I'm loathe to support the current proposal because creating a non-existent commonwealth english variety is no solution. --regentspark (comment) 02:52, 1 February 2018 (UTC)

Surely, the very first sentence of your comment makes it a logical oppose to the proposal as put? As effectively stated by your last sentence. MapReader (talk) 05:45, 1 February 2018 (UTC)

• Some further matters for consideration; the proposal as written doesn't seem to be gaining any traction (and I didn't expect it to on a first draft):

  Dealing with minor "national" variation (short of colloquialisms): We can just have a rule to permit it in articles with a strong national tie, though it would be better to drop "national" and use "cultural". E.g., if the most common Australian term for a particular vegetable is the Italian "zucchini" as in N. Am. Eng., rather than the French "courgette" as in Br. Eng., then use "zucchini" if the plant is mentioned in an article about an Australian subject. But there's no sensible rationale for, say, writing an article on a Korean village using Commonwealth English except for the word "zucchini" and then branding it with a huge, annoying Australian English template. It's a form of sublimated mammalian territory marking filtered through nationalism, and it serves no encyclopedic or encyclopedia-management purpose. "I'm going to spray my Singaporean English musk on this article", "I'm going to leave my Scottish English spoor on that one." This just needs to stop.

  Mis-conceptualized: Most pronouncements about what's "correct" in one dialect or another are prescriptivist nonsense; what you'll actually find in dictionaries and (when they exist for a dialect at all) style guides are ranges of usage trends, with multiple variants of things ("semi-final" vs. "semifinal", etc.) found together in most such works, with one favored over the other by some but not others, except for a handful of very sharp splits between US and British/Commonwealth (even Canadian) English, because they were invented by Noah Webster in 1828 (in living memory of the American Revolution) as an anti-British political move. Dialects are almost entirely a spoken matter; where the vocabulary and (rarely) grammar doesn't differ (which of course affects written word choice), then otherwise the spelling, hyphenation, and other style matters are not really questions of dialect but of the preferences of major publishers in particular markets and their own style guides (aside from a few noteworthy monographs by Fowler, Strunk & White, Gowers, and Garner, all of them either American or British – zero other countries have produced any general-audience English style guide worth mentioning). Differences aside from the sharp -re/-er and -our/-or split are mostly shifting waves of usage and have more to do with era (including age of writer), type of publishing (books, academic papers, news journalism, and informal writing), and sub-national regionality, than anything like national standards. No bodies exist to set them, unlike in French and some other languages (not that they have much effect; Quebec French, for example, remains notably distinct from France French).

  Canada in particular is undergoing major usage shifts, as can be seen by comparing fairly current Canadian dictionaries and style guides with those from the 1990s and earlier (on the plus side, it's shifting away from chaos and slowly towards standardization). Plus there are plenty of articles on the matter, following on organized surveys and corpora of Canadian spelling and usage (e.g., we know the shifts are moving from the coastal major cities inland). It's not even really clear what it means here that an article is written in Canadian English, since that varies from Canadian to Canadian; it probably resolves to using -re and -our spellings, with vocabulary, collocations, and punctuation that mostly coincide with US usage. Aside: The term Commonwealth English wasn't invented by us, and does not mean "English exactly as spoken in every single Commonwealth of Nations country", it means English as generally used in most of them; it's a blanket term, and it could not be any other way, since even British English isn't one monolithic thing, but a widely ranging dialect continuum with marked intelligibility complications between, say, Devon and Inverness locals. Whether the term, as one to use for an ENGVAR categorization and template, is "perfect" or not is immaterial; it's close enough. It's a well-documented term, and the fact that Canada doesn't fit the pattern entirely isn't consequential.

  Commonality is key. This should be our no. 1 guiding principle and should supplant our current fetishization of nationality, a patently anti-linguistic, anti-scientific, all-emotional idea that's caused more harm than good. This even speaks to the "chesterfield" post above; that term is also used in the US, and there are numerous other words for couches/sofas, like "davenport", "divan", "settee", "dufo", etc., some with shades of meaning (there have been entire dialectology papers written about this). It has nothing to do with national dialect but highly localized dialect. By this point everyone knows what "couch" or "sofa" means just like everyone now recognizes "aluminium" even if they'd prefer "aluminum". By now, most fluent speakers know that a sweater and a jumper are the same thing, but have no F'ing idea what a gansey is, as an illustration of why "This article is written in Hiberno-English" templates are a terrible idea: "Write in colloquial vocabulary just to stick it to the Brits and the Americans". This kind of politicized bullshit harms Wikipedia's mission. Similarly, the reasoning "The average Australian uses 'servo'" is no rationale to use it here in place of "petrol station" (universal in Commonwealth English and understood by North Americans), and the reasoning "there are lots of weird Australianism like this, so Australian is a dialect [including at the formal written level], and should have a template, and we should write WP articles in this dialect as faithfully to local usage as possible" is a chained load of bollocks [another phrase everyone understands at this point].
   — SMcCandlish ☏ ¢ 😼  12:13, 2 February 2018 (UTC)

  Frankly, I would be looking for someone to draw this pointless discussion to an end on the basis of WP:SNOW. It is offensive for an editor to have suggested that the only English varieties that deserve recognition are American and Canadian, and that the other billions of English speakers, including those in the language's mother country, can be lumped together under "Commonwealth" (which is an association that includes Canada). Enough already? MapReader (talk) 12:37, 2 February 2018 (UTC)

  If that's what you thought the proposal was, then you didn't actually read it.  — SMcCandlish ☏ ¢ 😼  03:31, 4 February 2018 (UTC)

• Comment: I support the proposal. Commonwealth English is indeed vague, much like British and US English are, and definitely Pakistani English. Yes, there are identifiable differences between the English used in many of the nations we're talking about. But that doesn't mean we have to fly national flags over these articles and pretend there is some standard that will resolve any dispute over wording in them.

And tagging an article as Commonwealth English will not stop it from using nation-specific language either. The MOS suggestion to use the English variety of an organization in articles about the organization is helpful here; a commenter above mentioned this, but misinterpreted the suggestion. It doesn't say that if an organization invents its own variety of English we should feel obligated to use it. It says if for example an international welders union, to avoid an argument like this, has a bylaw that says all of its publications should be in British English (just because its first chapter was in London), then Wikipedia articles about the union, and probably welding in general, should probably follow suit. And by the same philosophy, regardless of whether we use templates to recognize the legitimacy of a national variety, if there is a local word for something and no common word for it, an article with strong ties to that local place would use that local word. Bryan Henderson (giraffedata) (talk) 18:00, 2 February 2018 (UTC)

• Comment. I think Stanton's proposal recognizes this key fact, which MapReader refuses to: As a practical matter, ENGVAR is a compromise between Americans and everyone else. There are lots of distinct English varieties, but among the ones that get lots of use in scholarly writing, American English is the really distinct one; all the others are sort of clustered together.
  There is a view on the "everyone else" side that says, well then, the Americans ought to just give in, because counting by countries, they're outnumbered. But American English is the variety that claims about 2/3 of the world's native English speakers, so there's that. As a practical matter, it would deeply alienate many American editors to have "British" rules imposed on Wikipedia; there would be a movement to split en.wiki into two languages, to no one's benefit.
  All that said, I don't see the benefit to this change that justifies the affront to editors from Australia and India and et cetera. Yes, it would be a little more honest about what we're really trying to accomplish, and yes, it might prevent an occasional argument about whether some article ought to be in Australian English versus New Zealand English. But an occasional argument at an individual article is OK. Probably better than the argument we'd have to have about this. --Trovatore (talk) 20:42, 2 February 2018 (UTC)

I don't see anyone arguing for the imposition of "British" rules, and neither is the proposal being debated here simply "American" rules versus the rest? The proposal is to recognise American English, Canadian English, and 'other' English. Which is objectionable as I have tried to explain above. MapReader (talk) 22:04, 2 February 2018 (UTC)

I wasn't saying anyone was arguing for doing everything the British way; I was explaining my understanding of why we need ENGVAR in the first place. As for Canadian, yes, the proposal does muddy the waters by including that. It would have been clearer as just "American" and "Commonwealth". --Trovatore (talk) 22:24, 2 February 2018 (UTC)

• Comment This discussion feels surreal, at least to me, in that we appear to be largely or entirely a bunch of Westerners discussing the banning of existing varieties of English from India, Pakistan, Jamaica, etc, without any input from people from those areas, even tho we were told at the beginning that a similar proposal was passed years ago and then reversed when editors from those countries got to hear about it. If only to try to avoid a repetition of that pointless disruption (among other reasons), I would bring it to the attention of those Wikiprojects, except that I don't know whether that would be a violation of WP:CANVASS, and I also fear that it might unnecessarily inflame a dispute about a proposal that currently appears to be just wasting everybody's time as it currently appears, at least to me, to have no hope of gaining consensus support (which is why I have now stopped taking part in the above seemingly endless and pointless discussion, even tho I have sometimes been mistaken when I have had similar impressions about other seemingly 'doomed' proposals in the past). Tlhslobus (talk) 20:56, 3 February 2018 (UTC)
• Question Per my comment (currently immediately above), should affected Wikiprojects (such as India, Pakistan, Jamaica, Australia, New Zealand, South Africa, Ireland, etc) be informed of this proposal that particularly affects them? (Note: It is possible that some projects are already notified, tho I saw no notifications on the main Talk Page for the first two I checked, India and Pakistan) Tlhslobus (talk) 20:56, 3 February 2018 (UTC)
• Question Per my comment (currently immediately above my previous question), should this debate be closed per WP:SNOW as having no chance of reaching consensus, as has also been suggested by another editor above (MapReader)? (Unfortunately that editor and I seem too involved in the debate to be able to assess this question neutrally) Tlhslobus (talk) 20:56, 3 February 2018 (UTC)
• Comment I think this makes sense, with one thing to clear up in my mind. Can we just clarify that we are talking about restricting only the templates here, and not proscribing the variety of English someone chooses to use in an article that has no trend yet? I.e., if a new article appears to be written in Ozzie or Jamaican English, I'm fine with the fact that there's no template to enforce that variety going forward, but do we also now Template the User and say, "Sorry, that's not one of our approved 'Big Three', you'll have to change that."? Not sure I'm comfortable with that. Suppose they're not comfortable in writing in any variety but their own: I would want to ensure that they can continue to do so, without prejudice, ad infinitum, with other editors (perhaps) picking up the slack to convert to a standard variety (if deemed necessary) but I don't want to see people slapped on the hand for using the only variety they know at a native level of competency. With that caveat, I'd vote to support. Mathglot (talk) 07:23, 12 February 2018 (UTC)

So you're fine with me and my China plate grousing about drongos yapping on in their foreign lingo? S'truth - save me from the Seppos! I'd happily give up my Aussie quirks if it means more readers can actually understand what I am writing.  Stepho  talk  09:41, 12 February 2018 (UTC)

Regardless of the national variety of English, we should only be writing in formal English, not slang. Indeed slang isn't internationally comprehensible. But we're only talking about differences like "President pro tem" (American English) vs. "President pro temp" (Liberian English). —Ben Kovitz (talk) 11:15, 12 February 2018 (UTC)

There's no reason to abbreviate "President pro tempore", anyway; both the "tem" and "temp" versions are politico MOS:JARGON opaque to many readers, and save a maximum of four characters, so not worth doing.  — SMcCandlish ☏ ¢ 😼  18:47, 13 February 2018 (UTC)

If that's the only way you can communicate, Stepho-wrs, then yes, I"m fine with it. One of your OZ mates compatriots will come along soon enough and fix up your bodgy Strine colorful regionalisms. Mathglot (talk) 22:06, 14 February 2018 (UTC)

An historic

Where is the MoS advice on use of an before h e.g. "an historic", "an honourary", etc. etc.? Is this ENGVAR? Thanks. Martinevans123 (talk) 13:59, 29 January 2018 (UTC)

• I'm against it. It should only be "an" is the H is silent: an hour, an honour person. But not "an" is the H is sounded: a horse, a hat, a historic event. Reyk _YO! 14:02, 29 January 2018 (UTC)

  Thanks. I think that's generally accepted. I've seen "an historic" both ways. But do we have a policy? Martinevans123 (talk) 14:11, 29 January 2018 (UTC)

  I'm not sure if the MoS currently says anything about it. If so, it's well hidden. But like I said, I don't want it made mandatory. Reyk _YO! 15:30, 29 January 2018 (UTC)

  Should e.g. this be reverted? Thanks. Martinevans123 (talk) 15:47, 29 January 2018 (UTC)

  No, I do not think it should be reverted. Reyk _YO! 15:51, 29 January 2018 (UTC)

  @Martinevans123: do you pronounce the 'h' in honourary? The use of "an historic" with a pronounced h is an issue that has some variation, but I didn't realize it was at all common to pronounce the h in honourary. — Carl (CBM · talk) 19:35, 29 January 2018 (UTC)

  Not when I'm reading Graham Greene, I don't. Nor when I'm impersonating Zeb Soanes. My examples were merely intended to stimulate debate - please don't take them as any indications of supposed frequency of use. Martinevans123 (talk) 19:43, 29 January 2018 (UTC)

• This is a matter of different usage, both in British and American English. A history is the correct form, because the h is hard and the first syllable is stressed. For historical, both forms are considered correct, although A is nowadays more common. The argument for An, which as it happens I was taught at school, is that the second syllable is stressed, and hence the h isn't so hard (indeed barely pronounced in some accents) and An historical is easier to say. This An before an unstressed h was considered the correct usage historically in British English (in times when such h's were rarely pronounced), but is now on the decline. If a policy were considered necessary, I expect the consensus would head towards A, but meanwhile An should be accepted IMHO, particularly in British English articles MapReader (talk) 16:18, 29 January 2018 (UTC)
• I don't think there's any specific guidance on this – we leave it up to the editors involved. I invariably use "a", due in part to my North American upbringing and in part because I think "an historic" is a pointless imitation of the French "silent h", as in histoire, that was popular in Britain in the 18th and 19th centuries.  White Whirlwind  咨  16:24, 29 January 2018 (UTC)
• The words historic, humble, hotel have undergone H-insertion since entering the English language from Old French sometime after 1066. Originally the "h" would not have been pronounced, so "an hotel" would sound like "an 'otel" which is natural; such pronunciation can though be "stigmatized and perceived as a sign of careless or uneducated speech" (per H-dropping lead). If you pronounce the "h", and you insist on saying "an hotel", it sounds awful to me; I much prefer "a hotel". Batternut (talk) 16:24, 29 January 2018 (UTC)

  Or, if you seem to say the word "ahistoric" when you meant to say "an historic", you sound confused?  :) Ngrams shows only about 3:1 preference for "a historic" recently in American English, and only a 9:5 preference recently in British English. Because American style guides have been trending towards regularizing irregular usages, I suspect they will recommend "a historic", but both usages are well represented in actual usage. — Carl (CBM · talk) 18:46, 29 January 2018 (UTC)

  I have never come across An hotel, because the first syllable is stressed in hotel and therefore it clearly carried an A. My distant recollection from grammar lessons at a British school in the 1960s is that h-words need at least three syllables to carry an An. MapReader (talk) 19:00, 29 January 2018 (UTC)

  My grandmother (born 1904, and very much brought up in Edwardian elegance) always talked of "an hôtel", pronouncing the word as a French loan-word without sounding the initial 'h'. And she lived until 2004, so it's certainly been current (at least in some circles) a bit more recently than 1066. The rest of us always found it rather extraordinary though. But there may still be some people who still talk about a "round of goff", a usage my Physics teacher thought ended with the coming of Special Relativity in 1905. Jheald (talk) 19:33, 29 January 2018 (UTC)

  herbs :) --Izno (talk) 19:23, 29 January 2018 (UTC)

  yuge ones ? Jheald (talk) 19:35, 29 January 2018 (UTC)

• An historic with silent h is perfectly natural. An historic with sounded h is an American affectation that lingered for a while but has mostly died out. But Wikipedia is a print medium, so in most cases you can't tell the difference. Therefore there is no need for MoS guidance (even assuming that it would be worthwhile to give guidance against the affected form, if you could tell the difference). --Trovatore (talk) 19:30, 29 January 2018 (UTC)

  You're saying there are different conventions for the spoken and the written word? And that one need not influence the other? I'm surprised that, on this basis, you think guidance unnecessary. I thought that Wikipedia generally took great pains to provide correct pronunciation guidance. And that, at least for some articles, there were spoken versions? Martinevans123 (talk) 19:39, 29 January 2018 (UTC)

  Not exactly. I'm saying that the correct spelling depends on how the author intends the word to be pronounced. Since we can't tell how the author intends the word to be pronounced, there is no useful guidance to give. --Trovatore (talk) 19:43, 29 January 2018 (UTC)

  Fair point. I was just hoping for some easy Engvar guidance to avoid pointless edit warring. Seems it's not that simple. Martinevans123 (talk) 19:47, 29 January 2018 (UTC)

  @Trovatore: You're right that both are correct in their own circumstances, but those circumstances (silent h vs. sounded h) are, I'm pretty sure everyone here agrees, an ENGVAR issue, which means internal consistency in this or that article (except in cases of TIES, where it's internal consistency in favour of one over all others) is the governing principle), so in a given article one is right and the other wrong (or possibly just archaic -- "lingered for a while but has mostly died out" as you said it). Hijiri 88 (聖やや) 03:17, 30 January 2018 (UTC)

  Well, actually no, I don't agree with that. I'm an American and quite capable of saying an historic with silent h, at least in fast speech. It's not an affectation; it just comes out quite naturally. The affectation is using "an" together with sounded h, but we don't need to worry about that one, because the reader can't tell whether the h is pronounced. --Trovatore (talk) 03:21, 30 January 2018 (UTC)

  I'm an American and quite capable of saying an historic with silent h Well, I'm pretty sure you're in the minority there. I don't pronounce my final -ts in ʃ-ish manner, which sets me apart from my mother and ash least two of my siblings (bush nosh my father), and a glottal stop (I think? not a linguist...) comes quishe naturally to me, but thash doesn't mean the former is nosh a feature of Hiberno-English. Hijiri 88 (聖やや) 06:14, 30 January 2018 (UTC)

  "An historic" is only half 1/3 as frequent recently in the American English corpus of Google Ngrams, so rumours of its demise may be exaggerated. — Carl (CBM · talk) 19:36, 29 January 2018 (UTC)

  But how can you tell whether the author intends the h to be silent? I don't always pronounce the h in historic (and I would never spell it rumour). --Trovatore (talk) 19:40, 29 January 2018 (UTC)

  You can't tell, of course. I also corrected my numbers after looking up Ngrams again. — Carl (CBM · talk) 19:42, 29 January 2018 (UTC)

• In northern (specifically, Yorkshire) English, which I speak, it is generally—but not solely—'an historic' with a silent 'h'. I agree that this is not something to be covering in the MoS, other than perhaps to advise editors not to change it either way, unless for consistency. With the whole debate, it is a matter of dialect. I would not like to see wikipedia taking a stance over which dialect is 'better' than others. 'An hotel' ('an 'otel'), 'an hospital' ('an 'ospital'), etc, are not only spoken in some regional versions of English, but written, too. –Sb2001 19:54, 29 January 2018 (UTC)

  Especially in Scouse? Martinevans123 (talk) 19:57, 29 January 2018 (UTC)

Don't get me started on the north-west ... can that even be called 'English'? And yes—I am bitter.–Sb2001 00:18, 30 January 2018 (UTC)

• Great! another case where we get to hear folk pull bullshit explanations for their preferences out of their asses! We even get a smear against the colonials! Curly "JFC" Turkey 🍁 ¡gobble! 23:20, 29 January 2018 (UTC)

  Did someone mention Persia? Martinevans123 (talk) 11:33, 30 January 2018 (UTC)

  Persia? How foolhardy of you, Martin. Surely our MOS tells us that use of that word instead of Iran will automatically earn the errant editor a most grave Fatwa from Ayatollah Khomeini's successor. And if it doesn't tell us, then this MUST be promptly rectified . Tlhslobus (talk) 04:43, 11 February 2018 (UTC)

  Haha, yes. I'm sure we all know an Admin or two like that. Martinevans123 (talk) 10:08, 11 February 2018 (UTC) p.s. have you read my very popular Shambolic Verses??

• Yes, it's perfectly natural. I (from Southern England with a standard RP accent) would always both write and say "an historic" and "an hotel", although "a historic" and "a hotel" are both also perfectly acceptable in British English. So in articles written in British English either usage should be left well alone. "A honorary" (or "a honour"), though, is clearly incorrect, since I don't think anyone (except a Cockney stereotype) pronounces the initial 'h'. -- Necrothesp (talk) 12:07, 30 January 2018 (UTC)

  Here's the thing: many North Americans say "an historic" and aspirate the h—and I have never heard of this being taught in at school. It cannot be chalked up to being an affectation, as it appears to be mostly unconscious, and the same people would never say "an hotel". Still, we get the "pretentious Americans" folk explanation, with nothing empirical to back it up. Curly "JFC" Turkey 🍁 ¡gobble! 21:21, 31 January 2018 (UTC)

As I said above, that was how I was taught in school. Historic has a stressed second syllable, therefore the h is weak and it takes An. MapReader (talk) 21:42, 31 January 2018 (UTC)

MapReader: You're one data point. Let's see some statistics backing up the idea that North Americans who pronounce it that way do so only because they were taught to. It wasn't taught at any school I went to, yet plenty of people pronounced it that way in informal conversation. Curly "JFC" Turkey 🍁 ¡gobble! 23:08, 31 January 2018 (UTC)

I wasn't the only guy in the school, but, for sure, it's just an anecdote. I don't claim it is meaningful other than as a response to your never heard of this being taught in school. Now you have ;) MapReader (talk) 05:28, 1 February 2018 (UTC)

Curly: I was the one who introduced the term "affectation", and I am American (and not a "self-hating" one in case that was your next thought). It's possible I was incorrect, but it certainly was not an anti-Yank slam. --Trovatore (talk) 23:41, 31 January 2018 (UTC)

Okay, but my point remains: here we have a lot of folk theorizing, and a tad of anecdotal evidence wrung through people's beliefs and prejudices, and nothing empirical for anyone to make their pronouncements on. Are Americans who say "an historical" a bunch of miseducated stuffed shirts? Maybe they are where you come from—and maybe they aren't where I come from. And maybe we're both wrong. But nothing that has come up in this discussion can provide the basis of any sort of advice the MoS could give. Curly "JFC" Turkey 🍁 ¡gobble! 00:09, 1 February 2018 (UTC)

Well, since my view is that the MoS should continue to say nothing about this, that works for me. --Trovatore (talk) 04:09, 1 February 2018 (UTC)

If you want an example of how this has changed over time, consider "humble". In the 1662 Prayer Book, it's always preceded by "an" and was clearly pronounced "umble". But Dickens uses Uriah Heep's use of "'umble" as a negative marker. In the 1960s and 1970s, older academic historians at Cambridge University almost universally pronounced the name of their discipline as "istory", but few younger people did, and I didn't and don't. What's annoying to a pedant (which I admit to being) is to hear people read "an humble" with the "h" pronounced.

More seriously, this is a complex issue, with differences in usage between and within ENGVARs, which is all the MoS could usefully say. Where possible it's better to avoid "a/an" before words with different contemporary pronunciations – "a/an" before "herb", "herbaceous", etc. cause perennial^* edit wars in plant articles. (^* pun intended.) Peter coxhead (talk) 23:00, 31 January 2018 (UTC)

In Australia (and probably New Zealand), we pronounce the h and hence we nearly always say and write 'a historic'. However, since we get so much TV, movies, magazines, internet-blather, etc from the US and UK, we barely notice when somebody says or writes 'an historic'.  Stepho  talk  23:23, 31 January 2018 (UTC)

• Use "a historic". The h-dropping from "historic" is just a matter of localised accent (it's not at all consistent even in England); we wouldn't permit "King 'Arold died on 'is 'orse with 'is 'awk in 'is 'and", either; WP is not written in eye dialect. "An h[something]" is reserved in writing for h words where the h is universally silent, as in "an honorable discharge".  — SMcCandlish ☏ ¢ 😼  03:23, 4 February 2018 (UTC)
  • That might be how you want it to be, but it's really not how it is. The an+h appears plenty in writing. I don't have examples immediately at hand, but I'm sure they can be found. A calculus book of my dad's that I used to read as a kid had "an hyperbola", for example, which I thought was odd at the time which was why I noticed it. --Trovatore (talk) 03:27, 4 February 2018 (UTC)

    This isn't a discussion of how every single English speaker in the world has ever written something, it's about encyclopedic writing standards on Wikipedia. WP is not written in eye-dialect. The fact that something things in the world are written that way has nothing to do with how WP is written.  — SMcCandlish ☏ ¢ 😼  09:09, 7 February 2018 (UTC)

    • Well, you haven't given any evidence that this spelling is "eye dialect". Look, I don't particularly approve of it either, but that's not really the point. There are plenty of uses in high-quality formal writing. --Trovatore (talk) 09:13, 7 February 2018 (UTC)

I was taught to use "an" before vowels. "h" (and one other I think but it escapes me ATM). The link [www.grammar-monster.com/lessons/an_or_a.htm] says "an" before a vowel sound. It is how we speak, if not how we write. So, "an honour" but "a history"? Regards, Cinderella157 (talk) 14:52, 5 February 2018 (UTC)

I was taught the opposite in Australia in the 1970s. Australians pronounce the 'h' in 'history', therefore we aren't trying to join an 'a' and an 'i', therefore we say and write 'a history'. That's the point of this discussion: different regions (and possibly different generations) have different grammar and pronunciation rules, so there is no universal rule to cover everybody.  Stepho  talk  12:05, 8 February 2018 (UTC)

No one said it's unknown, it's just a minority usage (and a largely obsolete one, even in British news, e.g. there's about a 1:500 usage ratio of "an horrible" [9] to "a horrible" [10] in The Guardian, and 1 to 300 [11][12] in The Economist); when it is used, it's often in quotations of speech and in signed editorials (i.e., reflecting a personal style, not the publication's voice). So, we wouldn't use it absent a really compelling reason to do so, and there are more compelling ones to not, outside of direct quotations.  — SMcCandlish ☏ ¢ 😼  10:36, 9 February 2018 (UTC)

Sorry, but this is utter rubbish. It's not obsolete in the slightest. That smacks of a somewhat arrogant "I don't use it, so it must be obsolete". Well, you might not, but many people do. And it's not "eye dialect". It's standard usage for many with standard (not localised) British English accents. Of course "an horrible" is (and hence would usually actually be written as "an 'orrible"), but nobody except you has mentioned this. "An hotel" and "an historic", however, are used by many, many people with standard accents; they're not in the least incorrect, obsolete or eye dialect. -- Necrothesp (talk) 14:55, 13 February 2018 (UTC)

WP:KETTLE. You're not in a position to make an argument that someone's engaging in WP:ILIKEIT / WP:IKNOWIT when they've presented evidence of a one-to-hundreds usage ratio against "an" – including in the very dialect (British) your asserting its alleged correctness and currency, and you're presenting nothing but your preference and your unsourced belief in a "standard" of usage and a "standard" accent. What standards? Who issued them? Please cite them in detail. LOL. There's no such thing as a standard in English. (Even languages that do have them, like French, find the standardization attempts widely ignored; language just doesn't work that way).  — SMcCandlish ☏ ¢ 😼  18:42, 13 February 2018 (UTC)

Hardly. I've said it's commonly used and should be left alone if it is used. You've said it shouldn't be used. I'm not saying either I like it or I don't like it. I'm saying leave it alone and let editors use it if they choose to do so. You're alleging it's obsolete, with absolutely no evidence apart from your own belief. I'm saying it's not, with the "evidence" that I and many people I know and hear use it daily. I'm not trying to force you to use it. You, however, are trying to force me not to! Have you not heard of Received Pronunciation then? I shall quote from our article: Received Pronunciation (RP) is the accent of Standard English in the United Kingdom and is defined in the Concise Oxford English Dictionary as "the standard accent of English as spoken in the south of England", although it can be heard from native speakers throughout England and Wales. Hmm, looks like there is a standard then! Or at least, that totally unreliable source the OED thinks there is. I think maybe you're getting confused between French attempts to impose a standard language and the term "Standard English", which is most definitely commonly used in the UK, but doesn't hold any implication of trying to impose a standard language; it just means the accent and usage that is considered to be the commonest throughout the country and which is therefore the accent and usage that people most often associate with English people (for example, it's the version of English that actors usually learn at British drama schools, even if they don't already speak it, to prepare them for the widest range of roles). You also seem unable to differentiate between "an hotel" and "an historic" (commonly used in both written and spoken standard British English) and "an horrible" (never used except in some spoken dialects). So, I shall reiterate: Nobody is saying we should write "an horrible" because nobody does that. Okay? So I have no idea why you think your "hundreds to one" comment is at all relevant to this discussion. -- Necrothesp (talk) 13:41, 14 February 2018 (UTC)

The ratio I see on Google Ngrams is more like 9:5 in British English [13] and 3:1 in American English [14]. But the arguments about "h" dropping miss part of the point. The rule about "using 'an' before a vowel sound" was often accompanied by a second rule about words like 'historic' that begin with a pronounced h and an unstressed syllable. So even if the 'h' is not dropped, "an historic" fits the second rule, although "an history" doesn't. So the 3:1 ratio in American English is not a sign that 25% of American writers drop the h in "historic" - it means that the presence or absence of a pronounced h is not the only factor in the choice of article. — Carl (CBM · talk) 14:13, 14 February 2018 (UTC)

• I !vote for use a historic as Wikipedia is not spoken but read, standardization is good, and standard grammar uses "an" only when the next sounded letter is a vowel, and regardless of how one pronounces it, "historic" starts with a consonant when looking at it in print; SMcCandlish said this better than me. People who pronounce the h in "an historic" sound exactly like nails on a chalkboard to me, as the reporters on CBC Radio seem inclined to do, as they also do when emphasizing the first syllable in "harassment". But these are rants, not comments applicable to a written style guide. Ivanvector (^Talk/_Edits) 16:27, 16 February 2018 (UTC)
• "An historic" etc. is perfectly fine. Carl's statistical evidence is much appreciated. We don't need testimony from all accents (or commentary on how something sounds to them)--there's plenty of "an" usage in various Englishes, written and spoken. The MOS is already dictatorial enough and we don't need to add to it, certainly not on grounds of taste or linguistic favoritism. Drmies (talk) 16:38, 16 February 2018 (UTC)

"issues" referring to more than one child of a royal consort?

See Taejo of Goryeo#Family. I would have thought "issue" was the same in plural. Wiktionary defines it as a synonym of "offspring", and says that "offspring" can be pluralized with an -s or not, for what that might be worth. (Homestly I don't think I've ever seen "offsprings" referring to more than one child of someone.) Hijiri 88 (聖やや) 02:32, 30 January 2018 (UTC)

Yes, it is always "issue", never "issues". -- Necrothesp (talk) 12:14, 30 January 2018 (UTC)

I agree... I suspect the confusion arrises from the fact that he had issue / offspring by multiple consorts. While having children by multiple ladies may well have caused issues at his court, when discussing genealogy they all should be referred to as “issue” or “offspring”. Blueboar (talk) 12:30, 30 January 2018 (UTC)

Just an anecdote: "issue" in this context is WP:JARGONy. --Izno (talk) 13:24, 30 January 2018 (UTC)

Not really. It's used in many reliable sources. -- Necrothesp (talk) 17:10, 30 January 2018 (UTC)

Which doesn't stop it from being jargon? I have literally never seen or heard or used "issue" as anything other than a synonym for "problem", as a noun. --Izno (talk) 18:54, 30 January 2018 (UTC)

Your life experience is not a reliable source we can use to edit text in Wikipedia. --Jayron32 19:02, 30 January 2018 (UTC)

The OED, on the other hand, is. :-) 1931 E. Linklater Juan in Amer. 31 In 1873 he married a Miss Harriet Dormer, by whom he had issue Hildebrand, Oswald, Caroline, Cuthbert, and Anne. — Preceding unsigned comment added by SarekOfVulcan (talk • contribs)

Yes, I'm glad we agree that my life experience is not a reliable source; hence, "anecdote" up the way. I'm just noting that if you tried using this to refer to [royal] offspring outside this apparently-specific context, the reaction would be "um, what?". Dictionary.com note "Chiefly Law. to proceed as offspring, or be born or descended." (as its 5th listed use of the verb); MW lists it only as a synonym for offspring and progeny as its 4th definition; the OED website lists it last of its nouns and "Law formal mass noun Children of one's own.". That makes it seem very much jargon. --Izno (talk) 19:19, 30 January 2018 (UTC)

Actually, the OED page I'm looking at lists it 5th out of 19, with " Offspring, children, descendants (also occasionally with singular reference). Also occasionally with reference to animals. Also fig. Now chiefly in legal contexts or with reference to family history." So, granted, jargon, but the examples included aren't exclusively jargon.--SarekOfVulcan (talk) 19:58, 30 January 2018 (UTC)

I'm pretty sure its widespread use in English layman sources means it's intelligible to majority of native speakers, so WP:JARGON is a bit much, but I wonder about that example sentence you quote above User:SarekOfVulcan: it reads to me like the kind of thing we would not generally write per WP:NOTOBITUARY. That said... Hijiri 88 (聖やや) 06:59, 31 January 2018 (UTC)

Yeah, "issue" meaning "offspring" is a fairly old-fashioned, somewhat euphemistic usage that only retains currency in a few fields such as law that tend towards an intentional staid formality. Not necessarily incorrect, but not a style we need to imitate per se, as it becomes the sort of straining for formality that we should avoid. oknazevad (talk) 19:34, 30 January 2018 (UTC)

Used in the bible too, and you can't say that's old fashioned! ;-) I tend to agree with you about avoiding such formality though. Batternut (talk) 21:51, 30 January 2018 (UTC)

I dunno: what synonym is most appropriate in this case? If it were my article draft, I might have actually written "children" and got a chill up my spine because it felt a bit too informal (plenty of them probably grew up, and all of them are dead anyway) but the synonym "issue" didn't come to me so I settled with "children". But I don't know if I agree with actively changing "issue" to "children". I basically agree with WW below here. Hijiri 88 (聖やや) 06:59, 31 January 2018 (UTC)

I'm not sure that the use of "issue" for offspring has ever been common in colloquial English. Regardless, though, it is very commonly used to refer to the lineal descendants of a royal person, and as such should be familiar to any educated English speaker.  White Whirlwind  咨  19:40, 30 January 2018 (UTC)

Not common, but certainly not jargon. -- Necrothesp (talk) 13:32, 31 January 2018 (UTC)

• Issue is specifically a person's natural children, ie excludes adopted children. Hence its use in royal and legal situations, particularly wills. Wiktionary suggests some synonyms (at wikt:issue), but for the specific use at the Taejo of Goryeo article I'd suggest "lineal descendant" or just "offspring". Batternut (talk) 09:45, 31 January 2018 (UTC)

Offspring is so much better...according to (ever reliable) wiktionary "issue" is "(now usually historical or law) Offspring: one's natural child or children." I certainly hadn't heard of it, and even googling it is quite hard to figure out what it means (just search "royal issue"). Galobtter (pingó mió) 09:53, 31 January 2018 (UTC)

@Galobtter: You hadn't heard of it? Did you read the article and become confused about what it was talking about? We can't create style guidelines under the assumption that every word used anywhere in the encyclopedia should be familiar to all of our readers without any context. In the context of the article, I imagine that even if I wasn't already familiar with the word I would have been able to figure out immediately what was meant. "offspring", on the other hand, feels a bit too ... graphic? Hijiri 88 (聖やや) 10:02, 31 January 2018 (UTC)

​This is actually especially for the infobox, actually (not in the body), where some months ago on another article I first saw of it. In the infobox there is no context whatsoever. And we certainly should strive for the most recognition and clarity, and not use terms considered historical/legal-only. Galobtter (pingó mió) 10:07, 31 January 2018 (UTC)

If it's good enough for HRH Elizabeth II, it's good enough for me, infobox and all. Batternut (talk) 10:39, 31 January 2018 (UTC)

Well, Her Majesty's a pretty nice girl, but she doesn't have a lot to say. I say let's stick with "offspring" as a modern, formal, but not too formal. oknazevad (talk) 20:24, 31 January 2018 (UTC)

How about "children"? Gråbergs Gråa Sång (talk) 12:17, 1 February 2018 (UTC)

Children generally includes adoptees, which may not be intended. Batternut (talk) 13:56, 1 February 2018 (UTC)

But often is, even in royal contexts (e.g. Roman emperors adopting nephews as "sons" and heirs), and being natural children doesn't always matter (e.g. European bastardy), plus there's things like matrilineal inheritance as practiced by the Picts before their absorption by the Dál Riata (the king's sister's son was first in line for the throne, and whether the king had children – natural or otherwise – was irrelevant). It depends on the cultural and legal system. This is another instance where the infobox is too blunt an instrument, and the situation (if complicated) should be explained in prose, and the infobox bent to agree with it (e.g. "Children: Foo, Bar (adopted), Baz" or whatever. We have separate parameters for succession anyway. "Children" is fine, "issue" is confusing and obsolete, and "offspring" is liable to incorrectly limit the scope in too many cases.  — SMcCandlish ☏ ¢ 😼  03:11, 4 February 2018 (UTC)

Although I don't believe that "issue" is obsolete, as its use continues in legal and royal circumstances, I suspect the word will not be understood by a sufficient portion of readers, and using "children" in the infobox is reasonable. "Children" may typically be taken to mean natural children, and other cases (where reasonable to do so) can be hinted at as suggested by SMcC. Batternut (talk) 13:38, 4 February 2018 (UTC)

To the extent it may not be obsolete, "issue" is MOS:JARGON.  — SMcCandlish ☏ ¢ 😼  17:59, 8 February 2018 (UTC)

English IPA where the foreign pronunciation is theoretically more "correct" and the English one is intuitive?

See Iris (mythology). I guess standard practice would actually be to give both the English and (one of?) the Greek pronunciations and the article at present is just incomplete on this point, but in this case the common English pronunciation (full disclosure, I don't think I've ever heard a native English speaker talk about her, and Japanese pronunciation is based on the Greek) is apparently the same as the flower, and it's spelled the same. So I'm wondering if the English IPA might be overkill and maybe including only Greek (specifying that it's not the English pronunciation so as to let the reader figure out for themselves that the English one is the obvious one) might be better? As is, though, it's implying that the English one is "correct" and others not. Hijiri 88 (聖やや) 06:46, 31 January 2018 (UTC)

It would depend on a lot of things:

how intuitive the English pronunication is (in which case a pronunciation key may not be necessary)

how relevant the foreign-language pronunciation key would be to the reader. Sometimes there is no accepted anglicized pronunciation, in which case the foreign-language pronunciation key could be very helpful. In other cases, a (say) economic term might derive from French, Latin, or Greek, but the fact that it does might not be relevant to the article (or at least to the lead).

etc.

I can see the argument for including both in Iris (mythology): since the article is about Greek culture (and not just a Greek-derived term), a significant number of readers will be interested in the Greek pronunciation, at the same time, you don't want to imply the English pronunciation is similar to the Greek one, because the Greek-like pronunciation is not common in English.

Whether, how, and where to include either pronunciation would be an editorial decision—there's no broad consensus on this. What do you think would best serve the reader in this article? Do the other editors of the article disagree? Curly "JFC" Turkey 🍁 ¡gobble! 21:09, 31 January 2018 (UTC)

Agreed with everything CT said. It's a judgement call, and for the mythological figure, it's appropriate, while for the other articles disambiguated at Iris it would not be.  — SMcCandlish ☏ ¢ 😼  03:03, 4 February 2018 (UTC)

I think this is the sort of situation that calls for a detailed (and sourced) explanation of the varying pronunciation in the body of the article, rather than a glib IPA listing in the lead. —David Eppstein (talk) 18:16, 8 February 2018 (UTC)

Assuming it's either-or—there are plenty of articles that give a very helpful IPA gloss in the lead, and then go into finer detail in an "Etymology" section. We serve different needs and types of readers this way. Curly "JFC" Turkey 🍁 ¡gobble! 22:25, 11 February 2018 (UTC)

Sfn template

Hey there,

In Template:Sfn, parameters p and pp are used. Sometimes users mess up which one to use (like I did in John Glenn), and I am looking into ways to make it so users cannot mess it up. Some options:

1. Remove one of the parameters, and have the template detect if it is one page or multiple pages. Template displays p or pp based on the input.
2. Modify the template so p and pp display an error if you give it the wrong input. Bot finds errored templates, edits en-masse.
3. Leave it as-is.

Thoughts on this? Is there something major I am missing? Kees08 (Talk) 02:47, 4 February 2018 (UTC)

• It sounds like something someone good with regexes could implement. Curly "JFC" Turkey 🍁 ¡gobble! 03:03, 4 February 2018 (UTC)
• I would ask about it at WT:CS1; this is where most of the citation-related coding gets hashed out.  — SMcCandlish ☏ ¢ 😼  10:48, 4 February 2018 (UTC)

Or... do what I do... don’t use a template. Format the citation the “old fashioned” way. Blueboar (talk) 12:24, 4 February 2018 (UTC)

Which conflicts with WP:CITE if the article is already consistently using template-formatted citations. Doing that also costs us COinS metadata and has some other issues.  — SMcCandlish ☏ ¢ 😼  10:21, 9 February 2018 (UTC)

"Have the template detect if it is one page or multiple pages" isn't as simple as it sounds. While 99% of the time this field will be populated by either a number or a number range, there are also other circumstances in which we should actually be using the loc= field, but editors aren't always aware of that field's existence and try to shoehorn things into the page field. (One that comes up fairly regularly is Middleton Press, who maintain the affectation of not numbering their pages and instead numbering the sections of their text using Roman numerals for sections of the introduction and modern numerals for sections of the body text; see this reference for an example of a citation to a numbered section using {{sfn}}.) We actually want the template to generate an error when it comes across something it isn't sure how to handle, rather than attempting to guess what the person entering its data meant, as otherwise we're not only potentially directing readers to the wrong part of the source, we're not making the person using the template aware that they're using it incorrectly. ‑ Iridescent 10:47, 9 February 2018 (UTC)

Sometimes it's handy to use both p and loc, especially with legal codes, where loc can be very handy for, e.g., §17.3.4.1.1 where the page number alone isn't enough. As someone who uses p= and pp= in the right way, I would not be happy to see the template "dumbed down" by a regex that tries to reinterpret my use of p to figure out if I "really" meant to use pp. Maybe the page number really is "5–7" (and the next page is "5–8"). As long as there's a way to preserve old functionality, I don't care what new features they add. I'm even okay with having to use a new param I didn't have to use before ({{sfn|Smith|2009|p=5–7|yesIreallyMeanIt=1}} to get it to do what it did before, but just please don't remove existing functionality; thanks. Mathglot (talk) 07:33, 12 February 2018 (UTC)

Article short descriptions

The issue of using Wikidata descriptions for Wikipedia articles on Mobile view and in other applications where there have been problems was discussed in several places, and the latest, this RFC, has closed as The consensus is #5 for the first question - To populate the magic words by starting with blanks, and allowing them to be filled in manually and/or by bot (as per usual bot procedures). The consensus is #2 for the second question - Show no description where the magic word does not exist. This provides a way to ensure that the disambiguation description of Wikipedia articles is editable on Wikipedia, and remains within the control of Wikedians regarding BLP and other relevant policy, and can be protected from vandalism in the same way that our other content is protected, without treading on the toes of the Wikidata community.

These short descriptions will be text content hosted in the article and probably selectively visible. We will soon have the task of providing suitable short descriptions for articles, and it may be useful to consider whether this should covered by the MoS.

The Phabricator ticket gives the syntax as {{SHORTDESC:character string}} where the character string is a non-blank text description of undefined length, which is intended to provide a reader with a reasonable idea of what the article is about. Apparently WMF consider it necessary even when the title is adequately self explanatory, but in that case presumably we can simply repeat the title.

There will be millions of these to create over the years, and it would be nice to decide on any limitations and a bit of guidance before producing them in bulk. This seems to me to be within the scope of MoS, so I open the matter for discussion here.

My own opinion is that the short description should be, when possible, sufficient to distinguish between any two items likely to come up together as search results, but remain as short as practicable, so need not be a full sentence, and should be treated as any other content regarding policy and when disputed. I suggest that citing a reference would be inappropriate, and that talk page consensus should be the preferred path in those cases where there is disagreement. · · · Peter (Southwood) ^(talk): 14:42, 8 February 2018 (UTC)

For reference, the following are some threads that have looked at some of the descriptions that currently exist on Wikidata, and how they might be improved:

• Wikipedia_talk:Wikidata/2017_State_of_affairs/Archive_9#Wikidata_descriptions_of_Wikipedia_pages:_How_much_work_to_improve_them? (sample of 30)
• Wikipedia_talk:Wikidata/2017_State_of_affairs/Archive_10#Extended_disambiguator_analogy (suggested harvesting of {{About}})
• Wikipedia_talk:Wikidata/2017_State_of_affairs/Archive_12#Strategies_for_improving_the_descriptions (includes sample queries for groups of 200 items of various types; English parishes as a sample case)
• Wikipedia_talk:Wikidata/2017_State_of_affairs/Archive_12#first_sentences (a sample of 33 'most read' on October 2, comparing Wikidata with en-wiki first sentences)
• Wikipedia_talk:Wikidata/2017_State_of_affairs/Archive_12#Update_on_experimental_addition_of_short_description_templates (Perspective on scale of task)
• Wikipedia_talk:Wikidata/2017_State_of_affairs/Archive_12#section_break (Abraham Lincoln; and descriptions that should be blank)
• Wikipedia_talk:Wikidata/2017_State_of_affairs/Archive_14#Statistically, what fraction of Wikidata descriptions are bad? (discussion of sample of 1000 random pages)
• ...

Some particular areas for attention that have been raised, that may need special focus, include

• Disambiguation pages, list pages, category pages (given very generic descriptions on Wikidata; though dab pages are useful to identify in search)
• Pages with a disambiguator in the page title
• Descriptions including regional or ethnic or national identities
• Auto-descriptions with an overly large number of occupations
• High-value (GA, FA, etc) articles, and articles that are the most heavily read
• Descriptions of living people
• Medical conditions, treatments etc, may need something at MEDMOS
• Other WikiProjects may wish to standardise the format for descriptions of classes of items like ships, works of art, athletes, tropical storms, roads, astronomical objects, chemical compounds, species of living organisms etc.
• ...

(Feel free to expand) Jheald (talk) 15:21, 8 February 2018 (UTC) & Peter (Southwood)

At the moment there are also machine-generated auto-descriptions used as a fallback, when there's no manual description on Wikidata. As a starting point, looking at the code that creates them might give a useful typology of some of the different cases to consider, and some default description formats to critique. Jheald (talk) 16:08, 8 February 2018 (UTC)

• Sigh... another issue with both mobile view and Wikidata. To my mind, the mobile version of Wikipedia should be based on (and use) the actual text of the desktop version... and not populated via Wikidata (a separate project). Blueboar (talk) 19:41, 8 February 2018 (UTC)
  • @Blueboar: That's exactly what this section is trying to move towards. But to generate (and police) 5.5 new short descriptions, we need to start from something; and we need to have some agreed idea of what we want. Jheald (talk) 20:28, 8 February 2018 (UTC)
    • Start with the first few sentences of the lead paragraph of the actual article text (desktop version). No need to involve Wikidata at all. Blueboar (talk) 20:39, 8 February 2018 (UTC)
      • @Blueboar: We're not talking about the preview of the lead, we're talking about a short description. See the images on the right, above. Needs to be maximum about 40 characters, ideally less. Jheald (talk) 21:37, 8 February 2018 (UTC)
        • Use the first few sentences of the lead AS the short description. Blueboar (talk) 22:12, 8 February 2018 (UTC)
          • The "first few sentences" is not 40 characters. The short descriptions need to be much more concise -- something more like the short discriminators on dab pages. Also, repeating the lead is not ideal, if you're then going to show a preview of the lead, as per Abraham Lincoln above left. But see some of the threads links above for more detailed evaluations of trying to use the opening words. Jheald (talk) 23:58, 8 February 2018 (UTC)

• Still no reason to involve Wikidata. We could have a {{Short description}} template that provides this information, populates HTML metadata fields for search and indexing purposes, defaults to the lead if under 40 chars, uses the first almost-40 chars of the lead followed by "..." if the lead is longer than 40 chars, and throws an error if you try to feed it a custom description of 40+ chars. Easy peasy. I would suggest making that a Phabricator request, perhaps after an RfC. Best raised at WP:VPTECH I would think, maybe advertised on Meta. Like the sprawling Wikidata thread higher up this page, this isn't really an MoS discussion, but an en.WP (and other projects') data integrity and editorial control policy discussion.  — SMcCandlish ☏ ¢ 😼  10:20, 9 February 2018 (UTC)
• @SMcCandlish: For project management, there's a thread discussing some preliminary thoughts at Wikipedia_talk:Wikidata/2018_State_of_affairs#Practicalities_of_implementation, where you can offer such a suggestion.

But there absolutely is a need for an MoS discussion, to try to clarify what styles we would actually prefer and recommend for the short descriptions, for different sorts of articles -- what to put in, what to leave out, what facts to prioritise. Jheald (talk) 13:33, 9 February 2018 (UTC)

What to put in the description seems more a content issue than a style issue (for one thing, the type of content that should go into the description may not be the same from one topic area to the next... or even from one article to the next). It sounds like you are trying to automate something that really shouldn’t be automated. Blueboar (talk) 14:06, 9 February 2018 (UTC)

But the point of an MoS guidance (or guidance devolved to WikiProjects) is really to save editors time, to save them from re-inventing the wheel, or having essentially the same discussion about the same issues over and over again in different talk pages.

As a concrete example, from one of the threads above, here's a query for the current short descriptions on Wikidata for 159 parishes in the English county of West Sussex: tinyurl.com/y9ek4y9u. It's clear that the current state is not particularly good, there's a lot of room for improvement.

But what do we want to improve them to, for say the civil parish of Donnington,_West_Sussex? Would we prefer, eg:

• "village and civil parish in the Chichester district of West Sussex in United Kingdom"
• "village and civil parish in Chichester, West Sussex, England"
• "village and civil parish in West Sussex, England"
• "civil parish in Sussex"

Any of the above could be systematically rolled out as an intermediate, first-draft step to replace existing cloned descriptions that don't look as they have been manually edited; and similarly, one could come up with default forms for people; films and media; other sorts of places; etc, etc.

But there is a discussion to be had, as to what forms we prefer or don't prefer, and why. Jheald (talk) 14:46, 9 February 2018 (UTC)

Meh... I think ALL of those are equally acceptable... and there are probably others we have not thought of that are also acceptable. We don’t need uniformity for this. The wording of each “description” can be determined on an article by article basis. Beyond purely technical limitations (example: keep it under 40 characters) the editors who work on any given article can figure out how best to phrase the description for that article. We don’t need to over-regulate it further. Blueboar (talk) 15:21, 9 February 2018 (UTC)

@Blueboar: But are they all equally acceptable? I wonder if you're fully appreciating the strength of the imperative to be concise, and to get to the point quickly. Being short and to the point is at a real premium on mobile, as the images on the right show. In fact, if the target length is 40 characters, all of the above are over-length, apart from the last one -- the first is 84 characters long; the others 60, 48, and 22. But there's a real trade-off -- the descriptions are disambiguators, they need to capture the scope of the article too. It's quite a challenge.

(While we're at it, a further alternative:

• "village in West Sussex, England; also civil parish"

-- slightly over length again, yes; but gets straight to the point.)

Yes, the final call will be made by discussion on the talk page of the article. It's not a question of centrally laying down how the descriptions MUST be. But there is a place for central (and project-level) discussion of what works better or not, and examples of best practice -- not prescription or central regulation, but there is a place for discussion and gentle advice, .

Furthermore, the first drafts of these will be created by machine, because that's the only credible way we can get to a point of covering 5.5 million of them. So it's a good idea to think about what we actually prefer the machine to make for those draft descriptions. Jheald (talk) 17:54, 9 February 2018 (UTC)

If it were automated, it'd have to use some kind of excerpting algorithm, then. There are expert systems that do this, so we'd presumably have to adapt one of them. Still not an MoS matter, but a VPTECH one. And this is about content, not style. Compressed that much, there is no style, just a few keywords of content, probably not even in a complete sentence. Aside from automation (and, if it were automated, then also when it comes to human fine-tuning of this metadata) it will end up being a case-by-case matter (or at best a topic-by-topic one), just as with infoboxes. The issue is pretty much identical: how to present key tidbits of info in an even more compressed summary than the lead. That's going to vary widely, even within many topics (e.g. chemist bios, or whatever). As for the specific example, "village in Chichester, West Sussex, UK" would work. Whether it's also co-extensive with a "civil parish" is trivia, just like the fact that the the city of San Franciso and San Francisco County, California, are co-extensive is also not crucial information. For longer cases, abbreviation, shorter but less specific word choices, truncation, and other compression might be needed. Example: "place; Lyminster & Crossbush, W. Sussex" fits with 1 char. to spare. Stuff like this is why automation is probably not practical. If such a string were 2 chars longer, we'd have to use "W.Sussex" with no space.  — SMcCandlish ☏ ¢ 😼  23:45, 9 February 2018 (UTC)

I don't see why we should be pulling these from Wikidata at all. It is easy enough to put a template in our article here which contains the text for the short description. Ideally the content and edit history of that description should be visible here, without need to look at any other project. — Carl (CBM · talk) 14:10, 9 February 2018 (UTC)

@CBM: That's exactly what this thread is trying to move towards, what's going to be put in place. But to get there, there needs to be some kind of discussion about what forms for those descriptions should be preferred. Jheald (talk) 14:54, 9 February 2018 (UTC)

I agree. I like the goal of having a “short description” (in fact, I would like to see it implemented on the desktop version and not just on mobile)... but we don’t need to use Wikidata for us to achieve that goal. Blueboar (talk) 14:25, 9 February 2018 (UTC)

We absolutely do not need to use Wikidata as a source of short descriptions, but Wikidata does have a lot of short descriptions available for use when they are suitable. When they are unsuitable for Wikipedia, of course they should be ignored, though they may still be suitable for Wikidata, and a better description composed by an editor who has some idea of the scope of the article they are describing. Having some clue of what is needed and what would generally be considered acceptable will save a lot of time and probably reduce the amount of unpleasantness involved. Flexibility is necessary, in some cases well over 40 characters will be needed, Scuba diving comes to mind as an example - the current short description is diving while breathing from self-contained underwater breathing apparatus - 73 characters (on Wikidata it is quite accurate, but longer, underwater diving where the diver breathes from apparatus (scuba) which is completely independent of surface supply at about 115 characters, counting spaces). It may be possible to cut it down, but it may not, and a slightly long description is better than a wrong, confusing or ambiguous description, which may be a bit shorter. Using Wikidata short descriptions is merely a convenience which should save some time.

A short description has definite practical utility, and in principle is a good thing. The problems are with the current method of providing them.

The short description will be visible on desktop when signed in, but may be only as an opt-in, depending on what Wikipedians want. My opinion is that the more eyes on them the less vandalism will slip through, and the better quality they will develop, but there may be people who really object to seeing them.· · · Peter (Southwood) ^(talk): 22:02, 9 February 2018 (UTC)

Position in Wikitext and display in Desktop

These are possibly more matters of style than the actual content of the short description.

Logically I would expect the short description to be before the content of the lead, but there may be a better place. From a practical point of view it may not matter, except that for maintenance it would be useful to know where to find it.

As it is in a way an extension of the title I suggest as close to the top as does not conflict with anything else than may be usefully closer to the top. In other words, first thing on the page until someone comes up with a good reason why it must be further down.

How should it display on desktop? It is not regular content, so I suggest display in small text first thing under the title. Could be in parentheses. Opinions? · · · Peter (Southwood) ^(talk): 12:28, 10 February 2018 (UTC)

Use of determiners before proper nouns beginning "The"? Cut the "The"?

This issue has been bugging me for a while. A brief Googling indicates that we use the words "a New York Times article" in roughly 5,000 articles while we only use "a The New York Times article" in just over one-tenth that much. And frankly I'm surprised it's not less; I don't think anyone would come after me for removing the "The". Then there is The Dark Knight Trilogy: movie trilogies usually have a lower-case t "the" before them when referred to in running prose ("the Star Wars Trilogy), but is the trilogy named for the second film, making it "the The Dark Knight Trilogy"? I'm pretty sure I've seen external sources treat it the same as the Star Wars Trilogy (or even the Star Wars trilogy). Has this come up before? Do we have a standard policy on it? Hijiri 88 (聖やや) 11:39, 11 February 2018 (UTC)

Sorry, I should clarify. I did check before, and both the main MOS page and WP:THEMOS:THECAPS list a few examples, but the closest this seems to come to is the titles of "creative works", with the standard example being The Lord of the Rings. But are newspapers with "The" in the name creative works? Hijiri 88 (聖やや) 11:42, 11 February 2018 (UTC)

I think it depends on context... “This was outlined in an article appearing in ‘The New York Times’” but “This was outlined in a ‘New York Times’ article”. Or... “He played a detective in the movie ‘The Dark Knight’” but “He played a detective in the ‘Dark Knight’ trilogy of films”. Blueboar (talk) 14:44, 11 February 2018 (UTC)

The "The" in titles such as The New York Times are doing nothing more than presenting the real-world name of the newspaper. Since Wikipedia is an encyclopedia, if using the real world name isn't causing a problem then Wikipedia should continue reflecting it in the title. In running text both versions, per Blueboar, have their uses. Randy Kryn (talk) 14:51, 11 February 2018 (UTC)

What Blueboar describes above is ordinary formal English usage. In English, we normally drop an initial article in the name of something when modified by another determiner. Phrases like "A The New York Times article" or "Some The Dark Knight Trilogy character" are clumsy and arguably ungrammatical. This probably doesn't belong in the MOS. It's implied by a general prescription to write in plain, formal English and avoid clumsiness. Also, as with most matters like this, it's best not to make a rule. I can't think of an example right now, but I would not be surprised if there's some odd situation where doubling up determiners actually does make sense. —Ben Kovitz (talk) 15:02, 11 February 2018 (UTC)

Blueboar and Ben Kovitz both describe standard usage, but the issue has come up in the past where users have insisted on keeping the The because "it's part of the title". We don't need a rule, but guidance telling us it's safe to drop the The would be welcome. Curly "JFC" Turkey 🍁 ¡gobble! 22:13, 11 February 2018 (UTC)

The only problem is that if we give guidance to say it’s OK to drop the “The”, we will get people pointing to that guidance arguing that we should drop it in situations when it ISN’T appropriate to do so. Sometimes it’s better to not say anything, and trust that most of our editors can use common sense. Blueboar (talk) 22:22, 11 February 2018 (UTC)

Indeed this is a common problem on Wikipedia: many of our editors, being amateurs or having only a weak command of written English (whether native speakers or not), lack the background needed to apply much common sense to these things. I concur with Blueboar (and you) that the solution isn't to add more rules. That way lies madness. Our manual of style is just that: a style guide, a set of stylistic choices designed to produce consistency and the desired encyclopedic tone of Wikipedia, not a substitute for knowing the customs and conventions of formal, written English. This kind of thing might be best addressed through education rather than rules. User:Tony1 once wrote an entire course on copyediting for Wikipedia, but I'm not sure how well suited it is to people who just don't have a solid command of written English. Another possible solution: something like the WP:Reference desk, where editors could ask people with professional writing experience about these things. Or do we already have something like that? —Ben Kovitz (talk) 00:29, 12 February 2018 (UTC)

Actually, having a house set of stylistic choices is, in many ways, a functional substitute for "knowing the customs and conventions of formal, written English". Wikipedia, with a few exceptions, avoids the role of "educator". It specifically does so on talk pages and tacitly through its conspicuous absence in Wikipedia's stated purpose.

Also, someone earlier mentioned WP:THE, which has to do with article titles, not titles in articles. Primergrey (talk) 21:33, 12 February 2018 (UTC)

@Primergrey: Thank you for pointing that out. Fixed it now. Hijiri 88 (聖やや) 06:17, 13 February 2018 (UTC)

It's standard English practice to drop a leading "The" or "A/An" when it's awkward to not do it; thus "My favorite Beatles album is The Magical Mystery Tour" (not "My favorite The Beatles ..." or "My favorite the Beatles ..."). What counts as "awkward" varies by context; it's become conventional to retain the leading article in titles of works after possessives ("J. R. R. Tolkien's The Hobbit") but fairly common to drop it in other constructions that don't read very naturally when it's included ("Freeman's Hobbit co-star Richard Armitage"). It's entirely reasonable, normal writing, to use "Jane Q. Public is a New York Times editor", "As reported in a New York Times article", etc. And we'd never do "in the The Dark Knight Trilogy", as simply redundant. We've done fine without saying anything about this to date, and it's not a source of frequent or heated dispute, so I'm going to go with Blueboar's "Sometimes it’s better to not say anything, and trust that most of our editors can use common sense."  — SMcCandlish ☏ ¢ 😼  18:34, 13 February 2018 (UTC)

Side Question

A quick and totally unrelated question: when talking about the three “Dark Knight” movies, wouldn’t the word “trilogy” be lowercase?... ie “The Dark Knight trilogy”? Blueboar (talk) 18:52, 13 February 2018 (UTC)

Generally, yes. A specific issue (e.g. a DVD boxset) might actually be literally titled The Dark Knight Trilogy. And some novel series have overarching titles like this (The Chronicles of Thomas Covenant, etc.).  — SMcCandlish ☏ ¢ 😼  09:02, 14 February 2018 (UTC)

How to determine if "incident" should be capitalized?

There have been some moves recently between capitalized/lowercased "incident" (Honnō-ji Incident,[15][16] Jōwa incident[17][18]) and would like to get some clarification on when "incident" should be capitalized. There is a discussion with limited participants at Talk:Honnō-ji Incident#Move. Some questions that arose:

• When and under what circustances can "XXX incident" be considered a proper noun?
• Does the term used in the source language affect whether "incident" would be capitalized?
• Does the styling of the "incident" in RSes affect whether we capitalize it here?

I assume these questions are not limited to Japanese topics, so I bring it up here. Curly "JFC" Turkey 🍁 ¡gobble! 22:09, 11 February 2018 (UTC)

Discussion

• I haven't taken a hard stance on capitalization, but I do think it should be consistent—either capitalize or lowercase consistently. You can see my arguments at Talk:Honnō-ji Incident#Move. I lean towards lowercasing, as that seems to be the way Wikipedia leans—we consistently lowercase XXX dynasty and YYY period titles, which are as much proper nouns as XXX incident titles.
  I see no value in leaving it to RMs—it leads to unpredictable titles and the instability of constant moves back and forth over hairsplitting differences. Editors' time could be used better. Also, this can result in awkward, broken-looking text such as "General Turkey was involved in the XXX Incident in 1937, which led to the YYY incident the following year." Curly "JFC" Turkey 🍁 ¡gobble! 22:09, 11 February 2018 (UTC)

note... we had a similar discussion many years ago about the capitalization of the word “massacre”... what we came up with was that it depended on the sourcing... it is capitalized in names such as “Boston Massacre” and not capitalized in descriptive situations. In other words... if historians routinely NAMED the event “the XXX Massacre” (or in this case “the XXX Incident”) then we capitalized, but in other situations... no. User:Blueboar|Blueboar]] (talk) 23:41, 11 February 2018 (UTC)

A situation: Journal A, B, and C have a style guide requiring capitalization, while Journal D, E, and F require lowercasing—XXX Incident appears in Journal A, B, C, and F, while YYY incident appears in Journal B, D, E, and F. We capitalize or not based on which journals happened to have printed articles on the incident? We end up with the situation I described above, where one is capitalized and the other not—is this what we want? Curly "JFC" Turkey 🍁 ¡gobble! 01:01, 12 February 2018 (UTC)

As much as I hate adding new rules, you've pretty well convinced me that MOS:CAPS should address this. Hopefully we can do it without making a rule specifically for "incident". See my comments below for a general rule of thumb that reasonably follows the precedents that we've set already. Curly, would you object if I move this to WT:MOSCAPS? If we're going to propose a new rule about capitalization, or even a consolidation of existing rules, that would be the place where the most interested parties would see it. —Ben Kovitz (talk) 03:03, 12 February 2018 (UTC)

I wouldn't mind. I was under the impression that MoS discussions were supposed to be centralized here (I thought there had been some discussion about it). Curly "JFC" Turkey 🍁 ¡gobble! 10:29, 12 February 2018 (UTC)

OK, I'll wait one more day before moving it, to see if anyone can provide a link to that discussion or its conclusion. (I looked briefly, here and on WT:MOSCAPS, and I didn't see anything.) —Ben Kovitz (talk) 18:59, 12 February 2018 (UTC)

The MOS has an entire page devoted to capitalization. It doesn't specifically render a decision about "incident", but I think it's pretty clear that we favor lower case for everything except proper names. Perhaps this could be clarified. It does say to choose lower case unless "a substantial majority of independent, reliable sources" capitalize. So, Gulf of Tonkin incident is how we normally do it. "Gulf of Tonkin" is a proper name; "incident" isn't. —Ben Kovitz (talk) 00:38, 12 February 2018 (UTC)

• Okay, but what do we do when we disagree whether it's a "proper name"? What criteria determines that "Edo period" is not a proper name, but "Honnō-ji Incident" is? Or are you saying that neither is? Curly "JFC" Turkey 🍁 ¡gobble! 01:01, 12 February 2018 (UTC)

You have to do it the same way everything in English works: by precedent. But here's a simple rule of thumb (not a true rule, as it can be overridden by precedents in specific cases): if there's a name of a person or place combined with "incident", then that person's or place's name gets capitalized but "incident" doesn't. You can think of "incident" as a common noun being modified by a proper noun. (Yes, I know that this explanation doesn't run very deep, since words like "gulf" and "lake" are common nouns, too. So let's not just not dig there unless we really need to.) Since Honnō-ji is the name of a place, it's a proper noun modifying "incident". You still need to check the sources, though. When I take a quick look at Google Books, I find (in the body of texts, not titles of books and articles) "Honno-ji Incident", "Honno-ji incident", "Honnoji Incident", and "the Incident at Honnoji". If you put "incident" first, then it definitely gets capitalized. But I don't see any clear preference in the sources. "Honno-ji incident" seems to be the most common. So, I'd say that "Honnō-ji incident" wins, especially given the MOS's preference for lower case. Does that help? —Ben Kovitz (talk) 02:57, 12 February 2018 (UTC)

Well, the wording of the article title has already settled on "honnō-ji incident". What hasn't been settled is the capitalization, as you can see from the moves and reverts. By relying on "precedent" (especially with subjects not often discussed in English) we'll end up with a hodge-podge, as in the ABCDEF example I've given above. The "rule of thumb" does us no good if it's not explicit in the guidelines—as you can see, Dekimasu has a different "rule of thumb" with different reasoning behind it. Do we want a thumb war? Curly "JFC" Turkey 🍁 ¡gobble! 08:51, 12 February 2018 (UTC)

At the risk of repeating myself, a few points on this: 1) ”Incident,” unlike, say, “bombing,” is fundamentally not descriptive; further, when part of the proper name of an event, it does not describe “an incident called X,” but rather “an incident called the X Incident.” For example, calling the Mukden Incident “Mukden” or the Gunpowder Incident “Gunpowder” would not convey what you were talking about. The set is necessary in order to convey the intended meaning. This is probably true of most “incidents.” I have trouble agreeing that "You can think of 'incident' as a common noun being modified by a proper noun." 2) I think it's important to point out that whether or not there is a single term for something is not a determining factor in whether the names for it are proper nouns (World War II, Second World War; Willam, Bill). 3) Whether something attaches to a word that can be a common noun has little, if anything, to do with whether the end of the name is acting as a common noun. In addition to “Gulf” or “Lake” in your example, we could pull up any number examples from all walks of life: United States Senate, May Day, Spanish Inquisition, Nanking Massacre, Doosan Bears, etc. 4) This proves Curly Turkey's point that rules of thumb only go so far. I never intended to use only my own, but if the result is to rely upon reliable sources in each individual instance, then I have to say we are back to WP:RM and local consensus. Not that there's anything inherently wrong with that. Dekimasuよ! 09:03, 12 February 2018 (UTC)

There is something inherently wrong it—constant title moves back and forth, unpredictability for editors writing text (so they have to check every link before they link it), inconsistency in running text, meaning lots of good-faith "fixes" and reverts, lost time and effort over RMs, amongst the other reasons I've brought up. There's basically nothing right with it. Curly "JFC" Turkey 🍁 ¡gobble! 10:03, 12 February 2018 (UTC)

Instability sounds like the normal state of things on Wikipedia, and much in line with its dialectical philosophy. In either event, the assumption that it is acceptable to revert bold moves and reinstate the status quo should not go anywhere anytime soon. And when that happens, I have faith in RMs to create consensus for titles. I spend much of my time at Wikipedia around WP:RM, and don't consider the time people spend there to be wasted. Dekimasuよ! 20:04, 12 February 2018 (UTC)

(edit conflict)Two small points to make here: (1) see Proper noun which covers proper nouns, proper names and noun phrases; and (2) other people's style guides are useful for inspiration but are not WP's style guide, this is. Martin of Sheffield (talk) 10:08, 12 February 2018 (UTC)

Dekimasu, those are some excellent examples. Your point is well taken. I think the current MOS:CAPS suggests that all those should be capitalized and "incident" in "Honnō-ji incident" should not, but it's not written clearly enough to prevent the back-and-forth editing, WP:RMs, textual inconsistencies, etc. that Curly brings up. Hopefully we can fix this without too much trouble. We could also provide some advice about how to settle this sort of question efficiently and prevent arguments from restarting. —Ben Kovitz (talk) 19:29, 12 February 2018 (UTC)

Since it seems like it might be necessary, I'll write a little about zeroing in on “incidents.” Not that I think it’s particularly helpful for the MOS, but there is something in particular different about these events from a good deal of what's being discussed here. Wars and battles and revolutions tend to be capitalized, correct? “Incidents” in the cases I have been concerned with usually refer to military conflicts or coups: Xuanwu Gate Incident, Mukden Incident, February 26 Incident, Fashoda Incident, Memali Incident, Auspicious Incident, High Treason Incident. I am not at all concerned with trying to add caps to incidents named after someone getting kicked off an airplane or arrested for DUI (or for that matter, at all trying to argue that the animal attached to a breed name should be in caps). But there is a significant number of articles about this type of “incident” that appear to be proper nouns, based on either the article at proper noun (which notes that major manuals of style are often inconsistent on the point) or on usage in reliable sources. I’d be happy if these articles simply aren’t de-capped without evidence based upon blanket application of an interpretation of something that’s not laid out explicitly in the MOS. I certainly do not intend to go around adding caps to things that are at stable lowercase titles. Perhaps there is a set of words relating to historical events that is worthy of special mention as deserving of further consideration before a change. Dekimasuよ! 19:57, 12 February 2018 (UTC)

• I'd like to stay out of this as much as possible, but NB there wasn't really a great discussion that resolved the capitalization issue at Gulf of Tonkin incident: just an assertion at Talk:Gulf of Tonkin incident#Move? that switched the page from the previous, capitalized, title. Also noting Three Great Gardens of Japan at MOS:NAMECAPS, it's not clear to me what about that might be more a proper noun than the Honnō-ji Incident is. Dekimasuよ! 02:41, 12 February 2018 (UTC)
• Almost never – If consistently capped in sources, then we cap it. But few incidents are. Do we know of any? Dicklyon (talk) 07:32, 12 February 2018 (UTC)

Arguably the Incident on King Street (that is, the [in]famous incident on King Street, Boston, in 1770, not the incident on King Street, Charleston, in 2017). --Boson (talk) 11:40, 12 February 2018 (UTC)

• Lower case, except in the odd case that RS do in fact consistently capitalize it almost all the time. There may be no such case. This is not a new or special capitalization question; it's the same standard we apply to everything.  — SMcCandlish ☏ ¢ 😼  17:57, 12 February 2018 (UTC)
• Comment In my experience the majority of X no Hens and X Jikens in Japanese history are usually referred to as "X Incident" (capitalized) in English RSes, or are referred to with a different word entirely like "Battle" or "Rebellion", and those are capitalized. The most famous one of these in modern history is probably the "Nanking Incident", which is usually capitalized in those rare cases where non-Japanese sources refer to it as an "Incident" rather than a "Massacre". (There was also another Nanking Incident, but that is almost certainly a failure of titling, since the Japanese euphemistic name for the massacre in 1937-1938 is much better-known than the minor incident ten years earlier. Anyway, the earlier one appears to have significantly less to do with Japan and also currently capitalizes.) I don't have strong feelings on the matter either way, but I think saying "Well, in the few cases where we have a lot of English RSes, they overwhelmingly capitalize, so we should capitalize those, but we should not capitalize where there are not as many English sources and proportionally more don't capitalize" is silly and will necessarily lead to inconsistencies. Cover them all together (and then maybe where other names using "Battle", etc. are more common, use those, but still count the sources that say "Incident" or "incident"). Hijiri 88 (聖やや) 06:31, 13 February 2018 (UTC)

  Japan-related stuff isn't a special case. This is no different from any other kind of "incident". It is not possible to have 100% consistency, because qualitatively different kinds of conformance are in direct conflict with each other. Thus various things in English are capitalized (here and in other writing), or are not, based on the overall convention (in our terms: what the majority of reliable sources do) for the exact topic in question, not based on what word is used. While it would be nice and convenient if every conceivable thing that had a word like "incident", "war", or "battle" in our article title were either capitalized or not capitalized, that would be an artificial, WP:OR consistency, in direct conflict with more important principles, the main one of which is the application of WP:V and WP:RS filters to WP:MOS: WP does not capitalize (or otherwise stylize) unless the vast majority of independent, general-audience RS do so for the exact topic (not vague category) in question.

  In this particular case, I agree that "incident" naming is wrong in both cases. A WP:COMMONNAME analysis seems to have arrived at Nanking Massacre (whether that should be "Nanking massacre" is another question, but it seems unlikely). A COMMONNAME analysis for what is present at Nanking Incident does not appear to have been performed, and it's more likely that whatever term is applied would be lower-case, because the sources are even less consistent in how they refer to it, and it's generally descriptive (cf. the difference between American Civil War, a term used (and capitalized) rather consistently in sources, and Basque conflict, just one of numerous descriptive terms used inconsistently with regard to it (it's basically a WP:DESCRIPTDIS, not a proper noun phrase; see also the difference between Arab Spring, an evocative proper name consistently used and capitalized, and African-American civil rights movement (1954–1968), a descriptive appellation that WP made up, and which has many names (generally ambiguous ones) that are closer to proper names (most commonly "the Civil Rights Movement", which only makes sense in particular contexts, since there have been a great many civil rights movements), and note that Arab Spring synonym Arab revolutions is a descriptive label not a proper name, and not capitalized.
   — SMcCandlish ☏ ¢ 😼  18:20, 13 February 2018 (UTC)

  Note: there's been discussion about whether a different title or romanization would be appropriate for Nanking Massacre, as sources are thoroughly inconsistent, but I can find no discussion of capitalization in the article's talkpage archives. An NGRAM shows about a quarter of sources using the lowercase. "Nanjing Incident" is not one of the titles that's been considered, as it's inherently non-neutral (though that might not be obvious if you haven't read up on the subject). Curly "JFC" Turkey 🍁 ¡gobble! 21:52, 13 February 2018 (UTC)

Well, a 3/4 majority is fairly conclusive to me... historians routinely use the word massacre as part of a proper name for the event (like”Boston Massacre”)... so capitalize “Massacre”. As for using “incident”... that is rarely used by historians... but when they do, they do so not as a name but descriptively. We can tell by the fact that NGRAMS shows almost NO hits on “Nanjing Incident”. Blueboar (talk) 12:24, 14 February 2018 (UTC)

Blueboar: "a 3/4 majority is fairly conclusive to me": This is an arguement that comes up fairly frequently, and has two problems: (a) where is the line drawn? 2/3? 51% And what happens when the percentage falls below this threshold? (b) it doesn't address the ABCDEF example I gave above, which results in article text that looks "broken". (a) + (b) If the threshold were, say, 2/3, then it would take a single article from a "competing" journal in the ABCDEF case to mess things up.

Obviously, I think that's a silly way to determine capitalization. We should have a simple, easy-to-follow rule, and exceptions should be truly exceptional. Curly "JFC" Turkey 🍁 ¡gobble! 21:24, 14 February 2018 (UTC)

Yes, it would be nice if reality has simple and easy to follow rules... unfortunately, it doesn’t. Blueboar (talk) 23:36, 14 February 2018 (UTC)

Blueboar: It's as if you didn't actually read what I wrote. Let's turn this around—in what way does Wikipedia benefit from not having such a simple, easy-to-follow rule? Of course, we're talking about this specific, concrete case. Curly "JFC" Turkey 🍁 ¡gobble! 00:11, 15 February 2018 (UTC)

Readers who are used to seeing a word capitalized in the real world (ie in the majority of sources) will be surprised to not see it capitalized on Wikipedia (and vice versa). Wikipedia is not the place to “right great wrongs”... even when those “wrongs” involve style. Wikipedia should reflect the world outside Wikipedia... as messy as that may be. Blueboar (talk) 00:34, 15 February 2018 (UTC)

Blueboar: We're not talking about cases where it is consistently capitalized—not to be rude, but, seriously, have you read any of the discussion before responding? Readers are certianly not used to reading "General Turkey was involved in the XXX Incident in 1937, which led to the YYY incident the following year."—or can you cite real-world examples where sources consistently do this? Given that you're concerned that we should "reflect the world outside Wikipedia". Curly "JFC" Turkey 🍁 ¡gobble! 01:41, 15 February 2018 (UTC)

Perhaps this is a good place to break in and point out that as far as I can tell the Honnō-ji Incident (let alone the Manchurian Incident or High Treason Incident or Auspicious Incident, a few examples I listed above) is mostly capitalized. (We went through the fact that there are a variety of translations, of course, but:) Here are the top hits on Google Books for "Honnoji Incident": a capitalized LOC subject heading, capitalized in Columbia Chronologies of Asian History and Culture, capitalized in Mary Elizabeth Berry's Hideyoshi, capitalized in The Samurai of Japan, capitalized in Samurai War Stories: Teachings and Tales of Samurai Warfare, capitalized in The Hutchinson Dictionary of Ancient and Medieval Warfare, capitalized in Monumenta Nipponica, capitalized in Kodansha Encyclopedia of Japan, capitalized in Treatise on Epistolary Style, lowercase in Compendium catholicae veritatis, capitalized in Journal of Cultural Science, capitalized in The East. Also caps in 6 out of 8 on Google Scholar. For Manchurian Incident, 23 out of the first 30 in caps, mostly from well-respected sources like Louise Young's Japan's Total Empire and Sources of Japanese Tradition. This was a couple of minutes of searching I probably should have done earlier, but are you getting different results? Dekimasuよ! 05:37, 15 February 2018 (UTC)

It may be a case that 本能寺の変 is one of those "exceptional exceptions" I was talking about (or not, if the default were to capitalize), but we're not talking about a single article here, but general principles. I'd like someone to give a straight answer to my question about who is supposed to benefit from having text like "General Turkey was involved in the XXX Incident in 1937, which led to the YYY incident the following year." Do any of our sources do this? Do any style guides recommend it? If not, why would we do something so bizarre? Especially when Blueboar tells us our style should "reflect the world outside Wikipedia". Curly "JFC" Turkey 🍁 ¡gobble! 06:13, 15 February 2018 (UTC)

When this sort of formulation exists it is not necessarily incorrect. Style guides can allow like items to be styled differently based upon circumstances. For example, AMA says not to capitalize proper nouns in the plural, so you could have "General Turkey sailed the Atlantic and Pacific oceans, but he has never crossed the Indian Ocean." Or many style guides would say "Last year he was ten, but now he is 11," or spell out only numbers at the start of sentences. Or we might have "Leaves of Grass was written before Quelques-uns des mots qui jusqu'ici m'étaient mystérieusement interdits." Dekimasuよ! 07:20, 15 February 2018 (UTC)

None of those parallel the example I've given, do they? We don't talk of the "Pacific Ocean" and the "Atlantic ocean". My question again: who benefits? Aside from those who thrive on splitting hairs and manipulating NGRAMs at RMs? And the moves and moves back and moves back—I count seven moves at Honnō-ji Incident alone. Curly "JFC" Turkey 🍁 ¡gobble! 08:58, 15 February 2018 (UTC)

There aren't always enough sources for a meaningful analysis. E.g. a Google Ngrams search on "the Honnoji Incident,the Honnoji incident,the Honnō-ji Incident,the Honnō-ji incident" produces no results at all [19]. And we're mix-and-matching evocative proper names like "the High Treason Incident" and "the Auspicious Incident" with simple descriptive appellations like "the Honnō-ji [or Honnoji] incident" and "the Manchurian incident" (it's the same as the difference between Grand Central Terminal and Olympic Station – evocative names – and Van Ness station (the station at Van Ness and Market) and the Daly City – Richmond line (the line between those two cities) – descriptive appellations.

There's nothing inherently problematic about writing "He started his transportation career at Van Ness station in San Francisco, and later became the superintendant at Grand Central Terminal in New York City." A refrain of "but it's not consistent!" is basically meaningless, because there's a conflict of qualitatively different kinds of consistency, as with some other threads ongoing on this page. The desire to be consistent in the treatment of all station names in China or all Japanese "incidents" is at war with the desire to be consistent in the treatment of proper names versus descriptive labels, and the latter kind of consistency is much more important. Avoiding a construction like "General Turkey was involved in the XXX Incident in 1937, which led to the YYY incident the following year" is just a matter of competent writing, like using piped links, and not treating descriptive terms as proper names (e.g., there's no reason to use [[YYY incident]] when something else, e.g. [[YYY incident|resumed hostilities in YYY]] will do the job (and doing it that way often provides more context; a litany of "incidents" without an indication whether they were wars or scandals isn't useful to the reader).

Moving on, "23 out of the first 30 in caps" isn't consistent capitalization in RS, it's just a majority, and looks to be a WP:Specialized style fallacy (i.e., it's a style favored by writers in a particular discipline for particular journals, and WP doesn't follow their house style, otherwise we'd be capitalizing hundreds of thousands of things we do not capitalize, just to mimic the style of specialists writing for other specialists). As with previous discussions, e.g. of Japanese and Chinese transit stations and rail lines, we're also dealing with English-language approximations of names and descriptive terms that are not in English in the first place, so claims of proper name status have to be based on the character of the terms (non-descriptive or descriptive?), not on what a tiny number Ωof sources are doing, since they're almost entirely clustered in a very narrow style avenue that conflicts with WP style. By the same reasoning, we do not mimic the bombastic style of rock journalism when writing about a band, even if 100% of sources we have about the band are rock journalism and written in that style. We probably should not be using these "incident" euphemisms in the first place, per WP:NPOV, unless the sources overwhelmingly prefer a particular such "incident" name for a particular case, and there are more than just a handful of English-language sources for that case.
 — SMcCandlish ☏ ¢ 😼  17:43, 15 February 2018 (UTC)

SMcCandlish: I intended the "General Turkey" example to link to two qualitatively similar "incidents" that had arbitrarily been capitalized or lowercased, which is what we have with (at least) Japanese articles right now. I've copyedited a lot of articles on Japanese historical figures, and this keeps coming up. I have to keep checking the articles for capitalization, but it does little good because they keep getting moved (Honnō-ji Incident at least seven times).

Re: piping—are you saying (or is the MoS) that we should decide on whatever capitalization standard for "incidents" mentioned in an article? That they could all be capitalized in one article, and the same "incidents" all lowercased in another?

Re: "evocative names": you can see there's disagreement over what sort of names fit this bill. I doubt Dekimasu believes they're making these moves in violation of the guidelines. Curly "JFC" Turkey 🍁 ¡gobble! 21:52, 15 February 2018 (UTC)

I have made only two moves, both reversions reinstating the status quo. I'd be just as happy as you to see some sort of guideline if one was possible, since some editors have a lot more energy than me and preemptively change a large number of titles to their preferred style. Dekimasuよ! 22:25, 15 February 2018 (UTC)

I understood the point of the General Turkey example. Where something is a proper name, Foo Incident, and something else is descriptive labeling, Bazquux incident, and it's awkward to have them in series because of the differing capitalization, replace one with another description. Desire for consistency within the article isn't an excuse for down-casing proper names conventionally capitalized, or overcapitalizing things that are not proper names; that's an artificial pseudo-consistency, a mistake. E.g., we would not write "The Cure's Greatest Hits 2001 anthology contains twice as many tracks as their previous Greatest Hits release, Galore: The Singles (1997)"; the second instance of "greatest hits" is description, not a proper name (adjectival or otherwise).

I agree there's a lot of confusion on Wikipedia about what a proper name is. (There's some confusion even among academics in linguistics and philosophy.) The simplest, hybrid ling./phil. explanation is that if a name is not descriptive but figural (or an eponym) it's a proper name (Pacific Ocean, Van Ness Avenue); if it's descriptive (including of something else that's an eponym) then it's a not a proper name (Van Ness station, the station at Van Ness Avenue). There can be exceptions, which occur when virtually all RS agree to make them. E.g. the American Civil War is descriptive, but is treated as a proper name (aside from the now obsolete "War Between the States", it's pretty much the only name that conflict has); the Druze–Maronite conflict of 1860 is just a descriptive term amonSMcCandlishg many. In the other direction, bottlenose dolphin is a figural name for a species (it doesn't literally have nose made out of a bottle), but near-universal convention is to not capitalize species names (capitalization of them is just the house style of certain academic publications, and is a common style in field guides, to make them easier to visually scan in a hurry).

The beliefs that "if it's a proper name it must be capitalized" and "if it's capitalized, it's a proper name" are wrongheaded myths (and patently circular reasoning). E.g., genus names are capitalized while species names are not, yet there's no difference between them but in degree. Works known by their incipits have these treated as proper names consistently in reliable sources (i.e., they are typically the only names the works have), yet it is is not conventional to capitalize them the same way as proper titles. Titles of published works are always capitalized, even when purely descriptive ("Model XB-2349 User Manual"). And so on. There is no one-to-one mapping between proper names or proper nouns (under any definition) and capitalization; there's just a conventionalized trend, with numerous exception, to capitalize proper names (and some but not adjectives derived from them) in English. Another example is that genres are not capitalized (by much of anyone), but global artistic movements tend to be, despite being another difference of degree; thus science fiction and jazz, but Art Nouveau and Classical.

Yes, this is "inconsistent" on one trivial level, but it's consistent on anSMcCandlishother, more important one (the categorical one). Over time, the trend in English, across almost all types of writing, is to capitalize less and less, and we should respect that real-world shift in the language (ongoing since the early nineteenth century at least, and greatly accelerated since the second half of the 20th). The MOS:CAPS default to use lower case unless less sources almost always capitalize something reflects that. I.e., any time there's a "should we capitalize 'the Bazquux [i|I]ncident'?" kind of question, assume lower case, and make people provide a truly compelling argument for capital letters.
 — SMcCandlish ☏ ¢ 😼  16:59, 16 February 2018 (UTC)

SMcCandlish: "I understood the point ... Where something is a proper name ... and something else is descriptive labeling"—then you haven't gotten the point, because this is not what's happening at all. If you went through a pseudorandom set of Japan-related XXX rebellion and YYY incident articles, you would not find a "categorical" consistency to their capitalization—you wouldn't even find stability at individual articles, as I've pointed out already. If this is something the MoS addresses, then it's obviously not getting across—neither Dekimasu nor Blueboar interpret it the way you do, do they? Curly "JFC" Turkey 🍁 ¡gobble! 22:38, 16 February 2018 (UTC)

MOS:DONTHIDE law or not?

I see that the MOS page has a "this page is policy" header even though I thought that while generally accepted, it was unenforceable. Does DONTHIDE always have to be followed or are can it be excepted? Thanks, plz ping L3X1 ◊distænt write◊ 22:49, 12 February 2018 (UTC)

Um... The MOS is NOT marked as a policy... it’s marked as a guideline... which means that while it (generally) should be followed, there can be (and are) occasional exceptions. To know whether a specific situation is one of those “occasional” exceptions (or not), we would need to know the specific situation. Blueboar (talk) 23:09, 12 February 2018 (UTC)

Someone suggested adding a collapsible route table to a Transit station during an RfC but DONTHIDE was invoked as a reason against that. I don't think it is an accessibility issue because the material we are looking to add could be found externally, and while that may be an argument againsty inclusion, I don't think a collapsed template on the page will be a major issue. In the MOS header it was the "it is a generally accepted standard that editors should attempt to follow" part which was throwing me off because common sense can vary among editors. Thanks, L3X1 ◊distænt write◊ 23:19, 12 February 2018 (UTC)

To clarify the instruction... note that it says “should attempt to follow”... not “must follow”. It is strongly encouraged guidance, but not “law”. Which means it isn’t an always or never thing.

In the case you are discussing... I do know that there is a LOT of debate right now over whether Wikipedia should even HAVE airline destination lists. So this was probably suggested as a potential compromise between the two extreme camps. Things are still up in the air on that broader issue... with no clear consensus (yet). The idea of collapsing the lists is an interesting idea, worth discussing further... but there is no way to know now if it will or will not be accepted. If it is, we can amend any policies or guidance to account for it (one of the beauties of Wikipedia is that our policies and guidelines are not written in stone, and can be amended if necessary). Still too early to say whether it gain consensus or not, however. Blueboar (talk) 23:41, 12 February 2018 (UTC)

Ok, thank you for explaining to me :) L3X1 ◊distænt write◊ 00:11, 13 February 2018 (UTC)

Collapsed content in article bodies is "user-hateful". Either the information is relevant and should be presented, or it is not and should be moved to a spin-off article or just removed per WP:NOT#INDISCRIMINATE. "Enforcement" is the wrong mental model to apply to this or any other page. There's a consensus that hiding content in articles in unconstructive – it's not just an accessibility problem but several kinds of usability problem (e.g., it makes the content inaccessible in the mobile view, and it also interferes with in-page search). Collapse boxing is frequently used in infoboxes and navboxes, however; they already have accessibility limits, and are not part of the core content of the article anyway, so doing it there isn't a big deal. None of this has changed in years, so the consensus is clear. Whether something's in a guideline, a policy, or an essay with site-wide acceptance (like BRD and AADD) is irrelevant; either it represents consensus or it does not. The question is whether there's some overwhelming reason to ignore the consensus in this particular case. There would not appear to be such a reason; there's nothing unusual about this particular kind of list or table, and if "this may not be of interest to all readers" and "this is long and detailed" where collapsing rationales, then we'd be collapsing hundreds of thousands of lists and tables, but we are not. "Maybe Wikipedia shouldn't have destination and timetable lists in transit articles at all" is a WP:NOT debate, not a MOS:HIDE one.  — SMcCandlish ☏ ¢ 😼  17:14, 13 February 2018 (UTC)

Thanks for the phrase "user-hateful"! It's perfect. —Ben Kovitz (talk) 17:23, 13 February 2018 (UTC)

It's an old one, the opposite of "user-friendly". Bruce Sterling was using it as early as 1994 in The Hacker Crackdown. Weirdly, The Jargon File doesn't include it, though it has "programmer-hostile" as a humorous synonym of "user-friendly".[20]  — SMcCandlish ☏ ¢ 😼  18:25, 13 February 2018 (UTC)

Era's

Hello fellow Wikipedia users. Some people on here tend to use Common Era (CE) and Before Common Era (BCE) when talking about calendar dates.

Now those terms aren't widely understood by the general public, they are also deemed to be politically correct and therefore offensive.

The terms Before Christ (BC) and Anno Domini (AD) are acceptable. Also acceptable are the terms for different era's used by the Islamic faith, the Jewish faith, the Sikh faith, the Hindu faith and the Buddhist Faith.ScottieRoadPatriot (talk) 21:13, 15 February 2018 (UTC)

@ScottieRoadPatriot: What is acceptable to you, or any specific person, is not what we have decided, by consensus decision, to allow on Wikipedia. WP:ERA is clear that many different kinds of era are acceptable. --Izno (talk) 21:23, 15 February 2018 (UTC)

Greengrocer's apostrophe's

Just another in my series of humorous section heading's.

@EEng: Is that what that's called? Drives me nuts. --Izno (talk) 04:20, 16 February 2018 (UTC)

Pre-nominals and post-nominals for school articles

There is a discussion about allowing pre-nominals and post-nominals for school articles. See WT:WPSCH/AG#nominals. BillHPike (talk, contribs) 20:06, 16 February 2018 (UTC)