Wikipedia talk:Manual of Style

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style
WikiProject icon This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.

Criteria for including guidelines[edit]

According to MOS:LIST#List naming, "the precise inclusion criterion of the list should be spelled out in the lead section". WP:LIST#List layout says: "Don't leave readers confused over the list's inclusion criteria or have editors guessing what may be added to the list." (The noun "criterion" has the plural form "criteria".)
WP:MOS is a list of style guidelines, but the current version (version of 03:21, 26 October 2015 [UTC) does not specify inclusion criteria. Ideally, it would contain every guideline that every editor should know: guidelines with frequent applications. (Ideally, its size would not be daunting to an editor who wishes to study all of it.) However, sometimes editors want it to include decisions made about matters with infrequent applications. (Understandably, they want it to settle disputes on those matters, but the possibilities for inclusion are almost limitless.)
Therefore, I propose that the introduction of WP:MOS include a brief mention of one or two criteria for limiting what can be included in the main page. I perceive that deciding on one or two inclusion criteria will not be easy, inasmuch as there is a degree of subjectivity involved. However, the benefits can be worth the effort.
Wavelength (talk) 16:34, 26 October 2015 (UTC)

I don't believe that that's how the MoS is used. Editors will come to the MoS and then either use the table of contents or CTRL-F to jump to the section that they need at that moment. Darkfrog24 (talk) 18:54, 26 October 2015 (UTC)
There are known knowns and known unknowns and unknown unknowns. An editor who consults WP:MOS only for answers to specific questions could be for a long time unaware of guidelines that he or she is not applying. Wikipedia articles contain enough stylistic errors to occupy many editors for a long time.
Do you agree that the size of WP:MOS (the main page) should be limited? If you do, how do you propose that it be done?
Wavelength (talk) 00:00, 27 October 2015 (UTC)
Speaking from my own experience, when I was new to Wikipedia, clicking through six and seven and ten different pages of rules and still not finding the one I needed was a problem, but the size of the MoS never was. Because it was all on one big page, I could hit CTRL-F and get right to the point. If the idea is to give new Wikieditors a set of instructions short enough that they can actually be expected to read all of it, then we have to look far beyond the MoS.
So no, I don't agree that it's too big but that doesn't mean I'd automatically oppose any proposal to shorten it. If any part of the MoS can be shown to be unnecessary or no longer necessary, it might be best to remove it. Darkfrog24 (talk) 04:18, 27 October 2015 (UTC)

Using the search box at the top right-hand corner of WP:MOS searches not only WP:MOS itself but also all of its subpages, so using the search box is superior to using CTRL-F and not more difficult.
One example of an "unknown unknown" involves the use of "&" where "and" should be used. I have frequently seen that error when I have searched in Wikipedia articles for other errors. An editor who has not read all of WP:MOS might continue editing for years without being aware of the error. WP:MOS itself contains many instances of "&" and many instances of "and", and there are people who do not know the word "ampersand", so in this example even searching on WP:MOS (if an editor has the idea to search) would not necessarily locate the guideline (at MOS:&).
Wavelength (talk) 16:55, 27 October 2015 (UTC)
So the problem is that people don't know when they're breaking the rules. Shortening the MoS does not seem the optimal way of solving that. In that scenario, the Wikieditor would still have to take it upon him or herself to come here and look for information. It would make more sense for the information to be sent to them. Darkfrog24 (talk) 19:05, 27 October 2015 (UTC)
In each of my edit summaries involving MOS, I almost always provide one or more links to MOS, but in at least one recent case, my revision was later undone.
Wavelength (talk) 19:26, 27 October 2015 (UTC) and 15:08, 28 October 2015 (UTC)
My proposal to limit the size of the main page of WP:MOS does not explicitly say that it is necessarily too large already. We can take preventive action before a crisis. Also, editors can overcome their reluctance to study WP:MOS. (One statement in my original post—"Ideally, it would contain every guideline that every editor should know: guidelines with frequent applications"—needs some revision.)
Wavelength (talk) 15:08, 28 October 2015 (UTC)
In that case, I'd say the criterion for adding new content to the MoS should be the existence of a non-negligible number of instances of a non-hypothetical problem that adding said content would solve or ameliorate.
Remember the discussion about the use of animate vs non-animate pronouns for fictional characters? We worked out a good wording but consensus formed that fights over animate vs non-animate pronouns did not occur often enough for a rule about it to earn the space that it would take up in the MoS. Darkfrog24 (talk) 18:23, 28 October 2015 (UTC)
Yes, I remember that discussion, although I observed it only briefly when it was active. Since your post of 18:23, 28 October 2015 (UTC), I have been studying it more closely, but without much benefit.
I propose the addition of the following text to the end of paragraph 2 of the introduction of WP:MOS.
  • New content on this page should be able to improve or solve style issues in more than a trivial number of real instances.
Wavelength (talk) 23:54, 29 October 2015 (UTC)
Well maybe that page seems more straightforward to me because I was there to watch it develop scrap by scrap, but I suppose you could use the table of contents [1] or hit CTRL-F "should the MoS" or "explicitly" to jump right to the part relevant to the issue at hand. ;)
I think it would be clearer phrased as *"Any new content added to this page should directly address some style issue that has [shown up in a non-trivial number of real instances]" because "new content" can refer to content that has already been added rather than proposed content.
But we should ask ourselves this: Would adding that line directly address some non-hypothetical style issue that has troubled Wikipedia in a non-trivial number of real instances? Darkfrog24 (talk) 01:29, 30 October 2015 (UTC)
My answer is: Yes, it would address a style meta-issue. I have read, in a non-trivial number of instances, on this talk page and on other talk pages on Wikipedia, complaints that the size of the MOS main page deters editors from reading it. If the addition of content about a minor style issue results in editors being less attentive to style guidelines of more importance, then that addition is counterproductive on balance to the purpose of the page.
However, I do support the inclusion of minor style guidelines on other pages, preferably on existing subpages of MOS. Also, there can be a new subpage: Wikipedia:Manual of Style/Minor points or Wikipedia:Manual of Style/Supplement or something similar. That new subpage can also be an optional place for keeping any content removed from the MOS main page as not important enough to be there but still deemed worthy of being kept for settling disputes.
Wavelength (talk) 02:32, 30 October 2015 (UTC)
Well I've gone over what makes that a bad idea: Everything gets harder to find once it's not all on the same page. Whether someone's willing to read something is moot if they can't find it or don't know it exists.
Okay, then, I can get behind inserting some version of this line. Darkfrog24 (talk) 05:27, 30 October 2015 (UTC)
I have considered your revision of the additional text that I proposed, and I have revised it further.
  • If any new content is added to this page, then it should directly address a style issue that has occurred in a non-trivial number of real instances.
By using a conditional clause, I hope to emphasize (even if only slightly) the fact that we are not actively seeking to enlarge the page.
Wavelength (talk) 18:00, 30 October 2015 (UTC)
I have added the text mentioned in my post of 18:00, 30 October 2015 (UTC).
Wavelength (talk) 18:35, 31 October 2015 (UTC)
The additional sentence has been revised, with the edit summary "simplify language as MoS states", to the following.
  • Any new content added to this page should directly address issues that have occurred repeatedly.
The adverb "repeatedly" is too vague, and the adverb phrase "many times" does not account for simultaneous instances in many places, so I have revised the text again, with the edit summary "making wording more precise", to the following.
  • Any new content added to this page should directly address issues that have occurred in many places.
Wavelength (talk) 21:19, 1 November 2015 (UTC)
That's actually completely different. It suggests that problems that affect just one kind of article don't count. I think it should refer to number of incidents and it should definitely keep some version of "non-hypothetical" or "real" or "actual." We do get a lot of "Well this would stop people from doing something that I haven't actually seen them do" around here. Darkfrog24 (talk) 22:35, 1 November 2015 (UTC)
Please revise the additional text on WP:MOS to match your standards.
Wavelength (talk) 00:29, 2 November 2015 (UTC) and 00:32, 2 November 2015 (UTC)
I have revised the additional text again, with a version almost identical to what you suggested in your post of 01:29, 30 October 2015 (UTC).
  • Any new content added to the body of this page should directly address a style issue that has occurred in a non-trivial number of real instances.
Wavelength (talk) 21:28, 2 November 2015 (UTC)
Concur with Darkfrog24; MOS is primarily used by way of ToC, in-page searching, and incoming links to anchors. Furthermore, MOS:LIST#List naming applies to list articles, not internal documentation.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:07, 5 November 2015 (UTC)
Although it is true that MOS:LIST#List naming applies to list articles, the principle of clear inclusion criteria is relevant to WP:MOS, because many editors consider it to be too large, and because some editors still want to add things to it. The page should be less like a frog about to burst, and it should be less like a chameleon. For acquisition of a thorough understanding of WP:MOS guidelines, a systematic study of the page from beginning to end is more effective than sporadic access to specific guidelines.
Wavelength (talk) 20:48, 5 November 2015 (UTC)
I got the metaphors the first time around. The problem is that for everyone who thinks MOS is too long and covers too much, there are several people who want to add yet another rule (sometimes they're even the same people; MOS is too long for them when it includes rules they don't care about or disagree with, but critically lacking in their view when their own pet peeve is not covered the way they want it covered). For everyone who thinks the main MOS page is too long and that it should be split up more, there's someone else who feels the opposite, and that it would be better to have a long, integrated MOS that can be page-searched easily than a forest of sub-guidelines. The inclusion criteria for MOS and its subpages are the same as for all other policypages: Consensus to add/retain the material in question.

An artificially limiting set of inclusion criteria will simply result in increased conflict, as material that MOS should cover – because doing so resolves/prevents disputes, and/or results in better article prose – starts being targeted for removal by people wikilawyering the criteria, and material that MOS does not need, because it does not serve those purposes, starts being shoehorned in because it technically fits the criteria despite being useless to us. Any major, general-public style guide has hundreds, even thousands, of line-items that MOS does not have because they're not important or even applicable here, and MOS, being about how to write WP, not a magazine article or a journal paper, has advice not found anywhere else. It can't really be any other way. For those who want a more concise overview of MOS, see MOS:SIMPLIFIED.

I certainly agree that systematic study of MOS (and its subpages, and the naming conventions) provides a more thorough understandings of style on WP, but that would be true of anything, and doesn't really relate to whether MOS, alone out of all WP guidelines, should have some kind of "you can't/must include that here" pre-emptive inclusion criteria.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:19, 6 November 2015 (UTC)

In both places, the metaphors are for many readers, not only one. (Compare User talk:Wavelength/Archive 3#Do not lecture me [June 2010].)
Consensus itself has been a topic of discussion on this talk page. (1) How are we to define consensus? (2) How is a consensus to be achieved? (3) How is a consensus to be recorded, for all editors to see? (4) When and how does a consensus ever lapse? (Credit to User:Noetica)
Your other points describe a difficult situation, and I need to contemplate them more before I (possibly) respond to them.
Wavelength (talk) 01:51, 6 November 2015 (UTC)
For recording consensus, MOS:REG seems to be working well.
For most pages, consensus would be established by the weighted preponderance of reliable sources, though it usually breaks down to a vote. The MoS is not held to as high a standard for sources as other articles are, so "consensus" often ends up as "popularity contest." I see this line that you've added here as a good way to mitigate that problem. We've already been using it unofficially for a while, and it's worked well. Now that "only add to the MoS if there's a non-imaginary problem" is official, we might see a slow change in mindset around here. Here, diffs proving the existence of the problem, can be numbered among reliable sources.
I have one example of consensus lapsing: The rule about double quotation marks only was based on the idea that single quotation marks mess up the search function in older browsers. Once those browsers are phased out, the consensus for the rule will have lapsed and the issue should be reevaluated. So I guess we could do that: Whenever the problem that the addition to the MoS was meant to solve becomes moot, consensus has lapsed. Darkfrog24 (talk) 02:04, 6 November 2015 (UTC)
Wikipedia talk:Manual of Style/Archive 113#Recording consensus (January 2010) led to the establishment of Wikipedia:Manual of Style/Register.
Wavelength (talk) 02:52, 6 November 2015 (UTC)
Responding to both Wavelength and Darkfrog24 at once: I'll rephrase: We all got the metaphors the first time around. :-) Again: Consensus works here like it does everywhere else at WP. Much of the strife around MOS is rooted in the pretense otherwise, that something special and different should be done here. Demands and proposals in this regard have been going on for years, from one editor's [failed] RfA platform to have some kind of "parental" (their word) oversight over MoS and other guidelines, to another's lengthy campaign to have MoS, alone among all WP:POLICY pages, subjected to WP:V / WP:RS as if it were article content. These proposals never go anywhere because they don't make cultural sense here. It's no different from suggesting that WP:No original research be subjected to some kind of review bureaucracy, and not be able to say anything that didn't come from some external source on how to do research. Such ideas are unworkable because there is no one who knows what is best for WP and its policy formation processes than the editors involved in it, and there is no source for how to do reearch on WP than is more authoritative than WP's own internal documentation and the learning process by which it developed. Similarly, no third-party source can dictate to WP's editorial community how best to write for WP's own purpose and audience.

MOS:REGISTER could work well in theory, except that it is not complete or consistently maintained. I agree it's a helpful tool for finding some parts of some prior discussions, but that's pretty much all it is. The primary tool is simply the archive search form and doing the mental-sweat work of digging the stuff up. But frankly there is way, way too much focus on "show me exactly where there was a previous RfC on this nit-pick, or I'm going to change MoS to say what I want it to say to suit my own pet peeves" behavior. [Cf. #MOS:ELLIPSIS thread below, for example.] That is not how WP works. Consensus, especially with regard to policies and guidelines, is often strongly tied to longevity of the point in question and how integral it has become to extant content and procedures. It cannot really be any other way: Changes to these pages can have serious consequences across thousands, even millions of articles, and long-standing rules, in any WP:POLICY pages should not be deleted, much less reversed, out of any kind of "correctness" campaign. Their stability is of more value than most any of their particulars, and they exist primarily to have something to agree on so we get the work done, instead of continuing to argue about what we should establish some rules about. No one is happy with every single rule in any complex system, and no single rule in such a system has universal support within it. Pretty much ever. It's the system as a synergistic whole that matters.

When it comes to MOS, this is especially true, since most style matters are essentially arbitrary; having established a rule is the important part, not which of several options the rule selected. When they are not arbitrary, then there's an even stronger reason not to undo them – not only would a major change be disruptive across innumerable articles for no real gain, if the rule in question was there for practical reasons, it will re-problematize long-settled problems. A major showing of site-wide consensus is thus necessary for sweeping changes with serious impact. A temporal local consensus of editors to push in some peeve-based change to MoS cannot trump a decade or more of consensus to do it a particular way. This is really a basic fact of how human organizations work. The productivity cost of imposing a change that does not suit overall organizational interests almost always outweighs the benefit that might result, in a localized way, from the change, no matter how strongly some individuals in the organization feel about pushing the change through. For example, this is why so few companies, even in the high-tech world, have switched to using Linux as a desktop operating system despite the various arguments in favor of doing so; the opportunity cost is too high.

The perennial double-vs-single quotation marks thing is a case in point. While it actually is not an accurate assessment that "the rule about double quotation marks only was based on the idea that single quotation marks mess up the search function in older browsers", even if we pretend for a moment that it was, the idea that consensus for it will have "lapsed" soon when the older browsers are effectively extinct is not plausible. The consensus lies in the site-wide implementation, not in one of the various reasons it was implemented in the first place. If we decide to take a road-trip to Vegas to see a particular show (and for other reasons), once we are in Vegas the trip is not suddenly off when it turns out the show was cancelled at the last minute; we have already arrived and work with the present situation, we don't turn around and drive back home, and then take a different road trip somewhere else.

"Official" doesn't make sense in this context; there is no office, and no officials were elected. Consensus formation process works the same at MOS as it does everywhere else here. Finally, "For most pages, consensus would be established by the weighted preponderance of reliable sources" is not a factual statement; that's true only of mainspace content, not "pages" generally, and certainly is not true of our internal "Wikipedia:"-namespace documentation. "The MoS is not held to as high a standard for sources as other articles are" doesn't even logically parse. MoS is not an article, so "other articles" is not a valid construction in that sentence, and the comparison it contains is of unlike things. Directly equivalent statement: "My cat is not held to as high a standard for equestrian ability as other horses are."  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  05:40, 9 November 2015 (UTC)

Actually, no. Consensus does not work exactly the same way here as it does in the article space. If it did, most of the MoS would be sourced and marked with ref tags.
Consensus on Wikipedia is not supposed to come down to votes but to the preponderance of sources and of logical arguments. I know it often doesn't end up working out this way, but the scales are more tipped toward it out in the article space than they are here. For a solution, I'm all for increasing the role of sourcing in the MoS. In this MoS's particular case, difs proving the existence of a problem can be considered RS.
Also consider that the role of an article is to say "this is true/verifiable; here are facts" and the role of the MoS is to say "do this; here are instructions." These can be very different.
The idea that no one but the MoS regulars know what is best for the MoS is why we're so often accused of cliquishness. Anyone proposing a change would be wise to consult the regulars, but disregarding or weighting against outside input is improper.
Third-party sources, such as style guides, can tell us what is correct English, and helping editors write articles in correct English is the MoS's core goal, so yes they do have a role here as sources.
The fact that you and others think that it's okay that the MoS is arbitrary is probably one of the reasons why so many editors ignore it. "Do as I say not because it's verifiably true but because I say so" is antithetical to Wikipedia's mission.
I'll be more specific: One of the reasons for the double-vs-single rule was that single messes up search browsers, and if you want me to link to the discussion saying so, I will. It's just that the other reason is kind of stupid: Early during Wikipedia, there was a split-the-difference decision between American and British English rules. Those Wikieditors decided that the MoS would require British commas-out placement (WP:LQ) in all articles but double quotation marks in all articles. They did so in the entirely mistaken belief that British English always requires single. (One more reason to chuck WP:LQ.) I'm sure you can see how I don't think that this reason for the establishment of the double-only rule would prevent that rule from lapsing when the non-arbitrary problem that it was meant to solve becomes moot.
By "The MoS is not held to as high a standard for sources as other articles are," I mean that content in articles has to be sourced, but the MoS has a lot of unsourced material, including assertions of fact (as opposed to instructions). Some of its text, if moved to the article space, would be deleted for lack of support or at least changed dramatically. People get away with saying things here that they can't get away with saying elsewhere, and some of the things they've said have been misleading or even flat-out false.
I notice that you are assuming something: That any change in the MoS must immediately be carried out. That would of course take a lot of work. However, this is not true. The changes to the articles could merely be allowed to happen slowly, with new articles written in accordance with the updated rules from the start. Also consider that some of the worse rules in the MoS already have low compliance anyway. In the specific case of double-vs-single quotation marks, the MoS would be updated to allow both systems in British English articles, so it isn't as if even one article would be rendered incorrect (or "non-compliant," for those who don't like the term "correct") by lifting the ban. It is not as though articles magically get worse when the MoS is improved. Rather, their likelihood of getting better increases.
Yes, the MoS is different from articles in many important ways but that means we must be more strict with its content, not less. Darkfrog24 (talk) 20:56, 24 November 2015 (UTC)

Use of the word "the" at the Lauren Lapkus article[edit]

Opinions are needed on the following matter: Talk:Lauren Lapkus#Concerning the 4 characters that have caused such a fuss. Flyer22 Reborn (talk) 05:22, 30 October 2015 (UTC)

Hatnote mentions sidebar, not visible in mobile view[edit]

In § Guidelines within Manual of Style we state "... see the sidebar at top right of this page." However, the sidebar is invisible when viewing the page in the mobile skin (look). (See MediaWiki:Mobile.css; the sidebar is hidden due to its CSS class "vertical-navbox", if I am interpreting correctly.)

I can think of three possible approaches:

  1. Do nothing, because nobody who cares is using the mobile skin.
  2. Remove the hatnote, because it's not important.
  3. Add a note such as: "(only visible in desktop view, not in mobile view)".

Comments? Thanks. Wdchk (talk) 04:30, 1 November 2015 (UTC)

  • Or 4: Make all templated content such as that sidebar visible to mobile users on clicking an "expand" button or similar. Stubsorting on a mobile when stub templates are invisible is another problem! PamD 07:00, 1 November 2015 (UTC)
I have added the following text: " (visible only in desktop view, not in mobile view)". I consider this addition to be in harmony with the following statement in the introduction.
  • Any new content added to the body of this page should directly address a style issue that has occurred in a non-trivial number of real instances.
I consider the edited subsection to be outside the body of the WP:MOS. I hope that even additions there be made very sparingly. As soon as this issue with the mobile view is resolved, the added text can be removed.
Wavelength (talk) 18:54, 4 November 2015 (UTC)
Something like #4 is needed. This is not an MOS problem, but a problem with all sidebar content on WP. This should be addressed at MediaWiki talk:Common.css (to which Mediawiki talk:Mobile.css redirects). There does need to be some kind of placeholder for where these sidebars (infoboxes, nav sidebars, etc.) are, that either allows people to open them in situ, or which re-opens the page in the full-browser view, or something otherwise effective.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  04:11, 5 November 2015 (UTC)
@SMcCandlish: infoboxes show up correctly in the mobile view (at least on the devices/operating systems/browsers I use). See this view as an example. The problem seems to be with the "top level" Wikipedia sidebar, not part of the article, which is not accessible. Peter coxhead (talk) 15:22, 5 November 2015 (UTC)
Same or similar CSS classes can probably be used to resolve this, and the problem that collapse-boxed content remains inaccessible to mobile users. While such material need not be right in their faces, they shouldn't be prevented from accessing it entirely.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:02, 6 November 2015 (UTC)

Abbreviations: "US" and "UN"[edit]

At 21:41, 4 November 2015 (UTC), an anonymous editor revised WP:MOS#Abbreviations, replacing "US" with "UN" (substituting "UN" for "US"). I do not remember the reason for "US" being chosen previously, but it might have been chosen as a robust example, because US citizens have a tendency to include full stops [periods] in some places where UK citizens do not include them.
This example of an edit illustrates an advantage that comes when editing of WP:MOS is limited to a specific group of editors, and a disadvantage that comes when new editors continually appear in the edit history. Editors experienced with the history of WP:MOS are more likely to remember the reasons for previous decisions, whereas new editors might easily (and with good intentions) overturn the results of long discussions.
I propose the insertion of hidden text identifying archive pages and sections of previous discussions which led to specific decisions. For example, if the discussion leading editors to choose "US" is in section 10 of Archive 100, then the hidden text could be "100:10" or "A100:10". The hidden text could be placed immediately after the relevant passage in WP:MOS.
Wavelength (talk) 03:39, 6 November 2015 (UTC)

Any hidden text should be in plain English. A user who's not a regular here would probably not know our shorthand.
As for directing people to archives ...who's going to want to sit and read through one of our long threads and try to guess which part of it has to do with the section in question?
While this particular case does not seem controversial, there are other parts of the MoS whose rationale is disputed. "We put this here for reason X!" "No, reason X is BS; it's really because of reason Y!" I can see this being a can of worms if we make it a regular thing.
How about we ask this user why they made the change? Darkfrog24 (talk) 04:07, 6 November 2015 (UTC)
I left a message at User talk:, with a link to this discussion.
Wavelength (talk) 16:50, 6 November 2015 (UTC)
I have restored the previous version, with the more robust example.
Wavelength (talk) 03:24, 7 November 2015 (UTC)
WP:POLICY pages do not need citations for what they recommend or require; they are not articles that the public readership depends on, but internal documentation that exists strictly for editorial support purposes and which is determined by internal consensus (or, in a few particular bits, imposed on us by WMF's legal department, as with parts of WP:COPYRIGHT and WP:BLP, which is still an organizationally internal matter, distinct from encyclopedic content). In the rare case that the rationale for a guideline or policy saying something is unclear and questioned frequently enough that it needs to be documented, just do it in plain wording with a footnote. We have footnote templates for a reason, and our internal documentation is no stranger to them (see, e.g., several at MOS:LEAD). The few cases of consensus-discussion "citations" that are not in footnotes (there are a couple at WP:AT#DAB, for example) should be converted into footnotes, because they're extraneous, distracting asides when inserted into the flow of the policy/guideline wording. PS: An exception to "do not need citations" is when we're explicitly following external technical standards like WCAG, ISO, W3C, etc. In these rare cases, they should actually be proper reference citations, as at MOS:ACCESSIBILITY.)

Re: "This ... illustrates an advantage that comes when editing ... is limited to a specific group of editors, and a disadvantage that comes when new editors continually appear.... Editors experienced with the history of [the topic] are more likely to remember the reasons for previous decisions, whereas new editors might easily (and with good intentions) overturn the results of long discussions." That's true of every conceivable topic, in or out of mainspace, and is not an MoS issue.

US and UN: Yes, the "US" example was put there for a reason, and surely the "UN" one put in its place in a well-meaning gesture of internationalization. Not a big deal, but proper to revers, as the examples do not illustrate the same thing. As for the underlying issue behind the "US" example, it's not really true that "US citizens have a tendency to include full stops [periods] in some places where UK citizens do not include them"; rather US-based people steeped professionally in "U.S." as a conventional style (i.e. the U.S. government and fields directly tied to it, like the U.S. military and the American legal profession) have a tendency to use it even outside contexts in which is it actually conventional (i.e, irrespective of register of use, and simply out of habit), while most other Americans, and most non-Americans, don't do it at all, especially in the post-IM / post-SMS world in which punctuation is increasingly eschewed when not necessary for clarity. Within a single generation, you can expect to see "U.S." being viewed as archaic as "to-day" and "coöperate", through exactly the same process that has rendered "A.T.M." and "U.N.E.S.C.O." obsolete renderings of "ATM" and "UNESCO".  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:46, 9 November 2015 (UTC)

Where are you getting your info on what "most Americans" do? I see a lot of "U.S.," actually. Darkfrog24 (talk) 17:30, 9 November 2015 (UTC)
I read a lot. Thread below covers, more analytically, where "U.S." is used. Short version: In US legal and governmental documents, in US academic writing that follows CMoS and was produced prior to the 16th ed. (2010), in non-headline prose in American journalism that follow AP Stylebook, and even in headlines by the handful of papers that follow NYT style. And that's just in formal writing; see any number of analyses of computer-mediated communication's effect on general public use of optional punctuation (it's being dropped increasingly, and millennials never used it to begin with).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:59, 15 November 2015 (UTC)

Other style guides on "US" vs. "U.S."[edit]

The process of moving from "X.Y." initialisms to "XY" format appears to be inexorable, and it's only government/jurisprudence and a few conservative (mostly East Coast) newspapers who keep the "U.S." variant alive at all. This trend is easy to see in style guides (aside from non-US ones, which consistently use "US"). If you look at 1980s editions, you find recommendations (e.g. in the 1981 Los Angeles Times Stylebook, and the Chicago Manual of Style [see below] from the same era, among others) to treat geographical initialisms the same as human initials ("J.R.R. Tolkien" – virtually no external works support WP's weird "J. R. R. Tolkien" style), thus "U.N." and even "U.S.S.R."

Today, the New York Times Manual of Style and Usage has mostly abandoned this, yet still insists on "U.S." for the United States any time it is abbreviated (except in longer initialisms like "USAF"), and does likewise for a handful of other "intrinsically American" initialisms like "G.O.P.", which competing style guides like that of the Los Angeles Times have been rendering "GOP" since the 1970s. The new edition of the NYT guide, the first in years, came out a couple of months ago and still says this, demonstrating its conservative approach to typography and language. Meanwhile, the more efficient and populist Associated Press Stylebook abandoned even "U.S." in headlines, several years ago, permitting it only in running prose. The combination of slipping usage in the AP Stylebook (the dominant journalism style book in the US by a very wide margin) and the no-dots style in virtually all non-US publications, and the overwhelming use of "US" in headlines and abstracts, as well as in running prose outside American newspapers and legal/regulatory material, has lead to "US" dominating in online sources that are not tied directly to traditional US newspaper publishers. (See August threads here for some external sourcing on that, for those who care.) Virtually no one writes "U.N." any more, or "U.A.E."; to the extent the style survives at all it's limited to "U.S." in certain American publishing contexts.

Similarly, the Chicago Manual of Style, a conservative-leaning work, until the 14th ed. (1993) recommended "U.S.", "U.K.", etc. consistently (for country initialisms, but "UNESCO", "USAF", etc. for longer constructions incorporating them). The current edition (16th, 2010) has abandoned this and explicitly says to use "US" (§10.33), except in legal citations (§14.293).

The now-obsolete 15th ed. (2003) is what MoS's own rule is based on, and is wishy-washy like ours, recommending "UK", "GDR", etc., consistently, except saying (in part) "U.S. traditionally appears with periods ... [which] may nonetheless be omitted in most contexts. Writers and editors need to weigh tradition against consistency."

MoS implications:
MOS pretty much just outright plagiarized "U.S. traditionally appears with periods" from CMoS, without any critical thinking about the meaning and implications of that statement. We should've read that last CMoS part twice, since we generally go with consistency and have little use for "tradition", which varies between audiences, but which we can't reasonably permit here because no article is edited only by editors from a particular "tradition". Part of MOS's mission for inter-article consistency, when practical, for both reader and editor benefit is studious avoidance of colloquial and jargonistic constructions.

This is a good illustration, BTW, of why MoS should not be explicitly based on external style guides vs. our own determinations through consensus (often considering multiple external style books, giving more weight to the reasoning and context behind their rules rather than their wording), arriving at an internal WP finding of what makes best sense for our context and readership. Paper style guides change randomly from edition to edition, for reasons that have nothing to do with WP's needs or audience, but primarily based on pressure from the editorial staff at big-name publishing companies in a particular market. As argued in a thread above, MoS should not be changing randomly to suit off-WP whims. If we were nuts enough to establish rules like "MoS punctuates following the recommendations of the CMoS", we'd be in a world of metaphoric fecal matter, having to change millions of lines of wikicode every few years simply to match what some essentially irrelevant off-WP book said.

If MoS changes to eschew "U.S.", it should be on the basis of an WP-internal rationale. Arriving at one is not challenging:

  • Except in American government/legal contexts (where they are a term of art and mostly used in legal/regulatory citations in specific proper name abbreviation constructions like "U.S." and "U.S.C."), the "U.S." spelling does not match conventional expectations of most readers, only Americans intimately involved with the legal system or branches of the U[.]S[.] government.
  • It is no longer supported by any major style guide consistently outside of those contexts (unless you consider the rarely-updated NYT guide to be "major", which even the world of journalism publishing does not).
  • It leads to strife and conflict, as various editors squabble over whether to make "U.S." be consistent with "UK", etc., in articles in which they both appear (sometimes with "UK" or whatever being added long after "U.S" was already "established" in the article prose).
    • Sometimes it goes the other way around, with an American editor imposing "U.S." on an article that was not using it, just because they're convinced it's the "only proper way to do it in American English" despite MoS not saying this and no modern style guides off-WP saying this.
    • Some may even go further and try to convert "UN", "UK" ,and "UAE" to "U.N.", "U.K." and "U.A.E." to be consistent with "U.S.", despite MOS not supporting any such thing (MoS is only a guideline after all).
  • It can also lead to broader confusions, e.g. about how to handle other abbreviations like "UNESCO" and "NASA" (a confusion worsened by some external style guides' insistence that true acronyms of this sort – those pronounced as if words not letters in series – should be rendered the same way as "Jackson" and "London": "Unesco", "Nasa" – yet another reason that "an external style guide says so, so we have to follow suit" is not valid reasoning here).

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:46, 9 November 2015 (UTC)

Props for the legwork, SmC. Have you seen anyone on Wikipedia get confused and use "U.N.E.S.C.O." or "Nasa" or is this an extrapolation? Darkfrog24 (talk) 17:28, 9 November 2015 (UTC)
I have actually seen someone use "Nasa" before, but I straight reverted it as it had he hallmarks of a copy-and-paste bit of copyvio. Indeed, that "Nasa" was used was part of what tipped my off. The "use only a starting capital if pronounced like a word" format is the standard practice of the British press (good old Fleet Street); in this case the text came from The Financial Times. That said, it's prevelance in the British press does mean it's quite possible to see it here if someone doesn't know the guideline and/or doesn't realize it's an acronym because of the UK press style. And I seem to vaguely remember a discussion on the use not too long ago here; a proposal to allow it was rejected if I recall. oknazevad (talk) 17:44, 9 November 2015 (UTC) PS Wikipedia_talk:Manual_of_Style/Archive_164#Lowercase_acronyms_.2F_uppercase_initialisms here was that discussion. Not soundly rejected, but it kinda just died without consensus.
In my current employ as a legal journalist, my employer has a standard that "U.S." shall be written with periods, while EU, UK, UN, etc. are not. This reflects official U.S. government usage (see, e.g. The U.S.-EU Partnership, which has some mixed use in titles, but consistently uses U.S. in running text, while using EU and other unpunctuated abbreviations in the same text. I vaguely recall hearing at some point in my life that U.S. is punctuated to avoid having it pronounced as "us" or otherwise confused with the pronoun. Whatever the root cause, it remains prevalent and seems intuitive to me. bd2412 T 18:28, 9 November 2015 (UTC)
I find nothing even faintly intuitive about "The U.S.-EU Partnership"; it looks like someone had a mild seizure while typing. The "U.S." spelling is retained simply because the government (and thus law and the military) like it. It is not plausible that people will mistake it for "us", or the rest of the world, including the rest of the US, would not spell it "US". QED (or Q.E.D. as old-timers write it. ;-)  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:48, 15 November 2015 (UTC)
(edit conflict) Yes, I've personally corrected both "U.N.E.S.C.O." (or maybe it was "U.N.I.C.E.F." – one UN agency or another – and "Nasa" (as well as either "Unicef" or "Unesco" again). I also frequently run into "U.N." I don't log trivia like this though; I just edit-summary it "typo", "ce", "style fix", or whatever, or it's often a tiny part of a bunch of other changes in the same edit. I generally decline to participate in "can you prove editors are doing this?" fishing expeditions; either it's logically plausible that MoS should clarify something, or it's not. When the potential error is likely (e.g. because one or more style guides or other major publications or regional sets of publications do it, ergo many readers/editors will be familiar with that variant), then we can just implement the clarification. With an entire planet of editors available, it's inevitable that the mistake will; we only have to consider how frequently we guesstimate it may arise. Per WP:AGF, editors' word that they recall having encountered it already is sufficient if there's also a plausible rationale for why it's happening. We needn't entertain something like 'MOS should say not to spell "I" as "i" or "me" as "Me", and I keep seeing people do that.' MoS mostly doesn't cover basic writing rules, unless they've actually turned out to be something experience tells us we need cover. If you encounter "i" for "I", it will probably be in a block of text with no capitalization at all, or an isolated typo; we don't find editors who really believe it should be spelled that way.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:48, 15 November 2015 (UTC)
Thanks for answering my question, SmC.
I disagree with your reasoning, however, and with your characterization of my question as a fishing expedition. While it is possible that any error will occur sooner or later, not all of them will occur often enough for a line about them to earn the space it would take up in the MoS, and assuming otherwise leads to rules banning pet peeves. In this case, the answer to "How often does anyone on Wikipedia actually make this mistake?" seems to be "Often enough that SmC noticed and remembered." Memory should hold more weight than imagination in these matters. Darkfrog24 (talk) 01:47, 16 November 2015 (UTC)

Sub pages[edit]

Is there a way to access an automated list of sub pages? For example:

The ones I saw so far are informative and would like to read them all or have easy access to know which content types have them. Like for example does MOS for TV episodes match films regarding them being primary sources for themself? (talk) 01:37, 8 November 2015 (UTC)

See this page and Category:Wikipedia Manual of Style and Wikipedia:Manual of Style/Contents.
Wavelength (talk) 01:50, 8 November 2015 (UTC)
For maintenance use (e.g. to find redirects, sandboxes, etc.), use Special:PrefixIndex/Wikipedia:Manual of Style or the WP:Manual of Style/ soft redir.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:24, 15 November 2015 (UTC)

Number signs example[edit]

MOS:NUMBERSIGN gives as its first Correct example: "Her album reached number 1 in the UK album charts." I don't think that's correct. If "number" is used then the numeral should be spelled out as well (one). But, I think that the other example: "Her album reached No. 1 in the UK album charts." is preferred, so it should be listed first. --Musdan77 (talk) 20:47, 9 November 2015 (UTC)

I've never seen anything that states using the "No." abbreviation is preferable with numerals, nor conversely that if "number" is spelled out then the value should be expressed as words. Is there someplace (off-wiki) that you can point to with that recommendation? oknazevad (talk) 01:43, 10 November 2015 (UTC)
When I say "preferred", I mean from what I've seen used in articles. But, when the section is about the Number sign, it seems more natural to go from one shortened version (#) to another (No.), than to to the spelled-out word. I have not found anything that actually says that it's better to use "number one", but it makes more sense for consistency. --Musdan77 (talk) 18:08, 10 November 2015 (UTC)
One could say it's an unordered list, and no preference is implied in the listing. However, some readers might infer differently. I'll have to admit that in most of my work in sports-reated articles, a number for a ranking or a jersey number is usually seen as "No. 1" than "number one". Consistent with WP:PROPOSAL ("Most commonly, a new policy or guideline simply documents existing practices, rather than proposing a change to them"), I'd support at the very least to list the "No." example first, whether or not we say it is preferred.—Bagumba (talk) 21:01, 10 November 2015 (UTC)
Last I looked, we're also not advocating "No." but "no." when it's used; its an abbreviation of Latin numero, not "Numero". I've raised this issue before, but there are also contexts in which "#" is preferred usage, but they're uncommon enough maybe we can continue ignoring them. I sympathize with OP's view that we should use either "number one" or "no. 1"; this would be in agreement with a lot of our other guidance on abbreviations and numerals (mostly in WP:MOSNUM). I don't know if any major external style guides cover this, but I'd be surprised if they don't. I can start looking it up if we care.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:29, 15 November 2015 (UTC)

Shortcuts (number of)[edit]

At 21:57, 19 August 2015 (UTC), Voidxor removed several shortcuts, using this edit summary.

  • There are more shortcuts than can practically be listed here. Therefore, let's only advertise the MOS: versions in the {{Shortcut}} boxes, for consistency. Also, mv floating {{Shortcut}} elements below hatnotes.

At 16:35, 10 November 2015 (UTC), Danhash added three shortcuts to the subsection "Quotation marks", which already had one shortcut, using this edit summary.

Wikipedia:Shortcut#Link boxes (shortcut: WP:2SHORTCUTS) has this guideline.

  • The point of these template boxes is not to list every single redirect for any given page (indeed, that's what Special:Whatlinkshere is for); instead, they generally should list only one or two common and easily remembered redirects.

Wavelength (talk) 18:02, 10 November 2015 (UTC)

That's fine with me; I did not realize there was already a discussion or de facto guideline for shortcut boxes. Feel free to remove the ones which aren't necessary. —danhash (talk) 20:49, 10 November 2015 (UTC)
Thank you for your reply. At 21:35, 10 November 2015 (UTC), I removed the three added shortcuts.
Wavelength (talk) 21:38, 10 November 2015 (UTC)
I support Voidxor's & Wavelength's approach (and we've been over this many times before), generally, though there a few cases where sections have merged, or they cover several distinct things, and it's practical to have a few extra non-alike shortcuts. There's no reason at all, however, to have "WP:MOSFOO" variants in addition to the "MOSFOO" variant, nor minor spelling variants like plurals, nor various people's attempts to impose odd camelcase variants or other approaches. That's just pointless clutter that adds no actual utility.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:23, 15 November 2015 (UTC)

Why is "WP:Manual of Style" title case?[edit]

I was just wondering, why is "WP:Manual of Style" title case? Per WP:TITLEFORMAT, shouldn't it technically be sentence case? (I.e. "WP:Manual of style".) I apologize if this isn't the place for this type of question, or if there is already an explanation on the topic. Main reason I ask is because I'm helping craft a MOS guideline at a Wikia community, and was wondering if there's a reason Manual of Style is title case. Thanks, User:Jacedc (talk) 21:26, 11 November 2015 (UTC)

It probably started in that form, before the community decided that article titles should be in sentence case.
Wavelength (talk) 22:41, 11 November 2015 (UTC)
Also, it's not a Wikipedia article.  SchreiberBike | ⌨  00:18, 12 November 2015 (UTC)
It's less relevant whether it's an article and more relevant whether it's a proper noun. Chicago Manual of Style is capitalized. Why not Wikipedia Manual of Style? Wikipedia articles can contain title case if they include the name of a proper noun, such as List of Star Trek characters or Critical approaches to Hamlet. Darkfrog24 (talk) 01:00, 12 November 2015 (UTC)
There have been objections on a number of previous occasions, all, I think resolved as "too hard". It shouldn't be upcased. Tony (talk) 11:38, 12 November 2015 (UTC)
Thanks for the clarification, at any rate. Yeah, I don't think "manual of style" is a proper noun so much as "Wikipedia Manual of Style" is. User:Jacedc (talk) 23:55, 12 November 2015 (UTC)
If you check the archives, there were previous discussions of this; the consensus was that the MoS is essentially a work, and should be titled as one. There are various other projectpages treated as proper names, e.g. Main Page a.k.a. WP:Main Page, Help:Wikipedia: The Missing Manual, WP:The Wikipedia Adventure, the WP:WikiProject Council, [most] wikiprojects, WP:Mediation Committee, WP:Arbitration Committee, WP:The Wikipedia Library (I have no idea why it has "The" in it), and the former WP:Mediation Cabal, etc. There's also WP:Video and Interactive Tutorials, the name of a formal WMF project, and various things in Category:Wikipedia tools, which are basically software or documentation named for the software. If the WP:Signpost were renamed to a multipart name like "Wikipedia Gazette" it would surely be capitalized that way. A few others probably should capitalized as proper names but are not, e.g. a few wikiprojects with only their first word capitalized, plus the WP:Village pump, WP:Five pillars, WP:Welcoming committee, WP:Community portal, maybe also WP:Help desk and WP:Reference desk. There are some other inconsistencies, like WP:Request Edit Wizard vs. WP:Article wizard, and WP:The newcomer's manual vs. the other "Manuals", as well as WP:Editor's index to Wikipedia and WP:Reader's index to Wikipedia (essentially stand-alone works also). On the other hand, various disused essays are capitalized and should not be; I WP:RM these on sight or just move them manually.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:17, 15 November 2015 (UTC)


There is a dispute as to whether we should say "Donald Trump is a politician", "Ben Carson is a politician", and "Carly Fiorina is a politician". One side argues that anyone seeking office is a politician, while the other side cites common usage -- all three of the names listed above have multiple reliable sources that say they are "not a politician". Does the MOS give us guidance on this question? --Guy Macon (talk) 04:28, 14 November 2015 (UTC)

  • The dispute is a content question, not a style question. I would suggest that the NPOV notice board would be the best place to start resolving it. Blueboar (talk) 12:41, 14 November 2015 (UTC)


I created a disambiguation page at Wikipedia:Manual of Style/Religion, indexing all the non-trivial MoS coverage of religion/faith/philosophy/scripture that I could easily locate, since people are apt to wonder where to find that stuff, and it is a bit scattered.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:18, 15 November 2015 (UTC)

RM to move wikiproject content essay misnamed as a MoS subpage back to wikiproject[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/New religious movements#Requested move 15 November 2015.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:35, 15 November 2015 (UTC)


As of November 2015, the MOS states WP:MOS#Ellipses states "Pre-composed ellipsis character (…) generated with the … character entity or as a literal "…". This is harder to input and edit and too small in some fonts. Not recommended." Automated edits are being made that convert ellipsis (…) into sequences of three full-stops. This loses semantic information, and appears to do so on the basis of

  1. Presentation on some unknown set of "some fonts"
  2. Input mechanisms that are "harder to input", but this doesn't appear to suggest removal

For the latter, input mechanisms have moved on a lot eg. ISO 14755 entry. For the the former fonts provide a very carefully spaced ellipsis glyph (nb. normally wider, not small-er than a row of full-stops). Thus, the basis for preferring rows of full-stops over the correct semantic form seems doubly flawed. If there are no objections, I would proposed the following adjustment:

"The ellipsis character (…) literally inserted Preferred, or from its corresponding … HTML entity. Not recommended."

(This would remove the flawed/distracting perceptions about fonts and input mechanisms from the policy text). —Sladen (talk) 21:54, 18 November 2015 (UTC)

I object to the proposed adjustment. The affected fonts are not specified, probably for the sake of brevity. Characters generated with … can be replaced by three unspaced periods (full stops). (In Wikipedia articles, "very carefully spaced" and "doubly flawed" should be unhyphenated.)
Wavelength (talk) 23:10, 18 November 2015 (UTC)
I have a question. Will all of the existing instances of … have to be converted to three full stops, if this passes? epic genius (talk) 01:30, 19 November 2015 (UTC)
Epicgenius, the first priority/aim would be to discourage robotic conversion of ellipsis (coded as … or …) to sequences of full-stops, could you suggest an improved wording? —Sladen (talk) 08:48, 19 November 2015 (UTC)
@Sladen: Oh, OK, I see what you mean. An improved wording would be Pre-composed ellipsis character (…), generated with the … character entity or as a literal "…". This is harder to modify and is too small in some fonts. Not recommended." epic genius (talk) 13:59, 19 November 2015 (UTC)
Epicgenius, perhaps I'm missing something? That seems to be (a) the present wording, and (b) doesn't appear to discourage attempts at converting ellipsis into full-stops. —Sladen (talk) 14:02, 19 November 2015 (UTC)
@Sladen: Maybe this should be a new line: If possible, it is not recommended to change a pre-composed ellipsis character into three full stops. epic genius (talk) 14:06, 19 November 2015 (UTC)
I support the use of literal ellipsis characters. An ellipsis looks like three periods but is semantically different (much like a lowercase L looks like the numeral 1, but is different!). I think we should prefer the ellipsis character over three unspaced dots. I would, therefore, even support discouraging the use of three dots, spaced or not. It's not clear to me why we wouldn't also recommend the HTML entity, since it is functionally equivalent and solves the "hard to input" problem. Pburka (talk) 14:07, 19 November 2015 (UTC)
I think the three full-stops should be the norm. It is by far the easiest way to create ellipsis while editing in the Wikipedia environment, and it is far less likely that millions of casual editors are going to dutifully use the other options, one which requires knowledge of the HTML code, ALT-keycodes, or the use of word processors, which we would have to discourage because we don't want curly quotes and weird hidden formatting in articles either. If the issue is semantic difference, then maybe the software should be coded to convert "..." to "…" when the article is being read, similar to how the software ignores multiple spaces between words and presents a single space in read mode. But I gotta say, "..." looks very much like "…" on my screen, so I don't know what additional value we're getting by using the semantically correct version, except when we're in edit mode. Cyphoidbomb (talk) 16:48, 19 November 2015 (UTC)
Cyphoidbomb, yes three full-stops is an easy way to enter three full-stops. We have a situation where lots of editors who do know how to use '…' enter it, but later an AWB-user comes along and converts it. My hope here would be wording that encourages AWB users to leave this as-is, just as with – and — (endashes and emdashes). —Sladen (talk) 16:56, 19 November 2015 (UTC) For not being able to tell the difference on some particular font/settings/browser/platform, see Pburka's comment above "…lowercase L looks like the numeral 1, but is different!"
I also object to this claim for reasons given above. The idea that font-related issues can be ignore because we aren't providing a catalogue of all the fonts in the world that are affected is nonsense. This is a style guideline, not a font debugging tutorial, and the suggestion smacks of WP:GAMING and WP:LAWYER. There is not "gotcha!" to be had here.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:02, 19 November 2015 (UTC)

I've gone back through the history to try and track down where the additions of the Recommended/Not recommended came from. In October 2007 there was a replacement of ellipsis characters in the MoS itself with full-stops by an editor[2]. The same editor then replaced the (at the time) short/clear ellipsis policy with a longer version with significantly changed meaning.[3]. Some of the more extreme aspects were immediately reverted[4] by SMcCandlish in subsequent edits with some pretty strong words "That's just wrong…". There is reference to apparent discussion, which from the timeline is probably Wikipedia talk:Manual of Style#Ellipses revisited, but which does not appear to mention alleged problems with fonts, nor input mechanisms, nor most of the rest. Andreas Toth,[5] Goffrie[6] made further small corrections. Subsequently Andyvphil and atakdoug also expressed concern at some of what had changed in Wikipedia talk:Manual of Styl#Ellipses .E2.80.93 Proposal to expand_the treatment thereof. In the latter jacobolus expressed concern over "flimsy" arguments,[7][8] and mms was around too. To those pinged here, are any of you able to shed any more light on this? Was it continued elsewhere—SMcCandlish does at one point note about taking an apparent dispute with the editor in question off privately, but I don't know if there was further discussion that wasn't documented. —Sladen (talk) 21:47, 19 November 2015 (UTC)

Eight years of stability, in one of the most actively edited guidelines on the system, is more than sufficient evidence of consensus. Wikipedia is not a bureaucracy, and inclusion of advice in guidelines is often a matter of WP:COMMONSENSE; there is not a formal ratification process. "I can't find old discussions justifying something I don't like to my satisfaction" isn't a rationale. If you think the present advice is sub-par, then present a new rationale for changing it, rather than argue about procedural matters from almost a decade ago. WP:PROCESS evolves over time, so any procedural objection predicated on present-day process is inapplicable to consensus formation that long ago to begin with. Who discussed what, with whom, back when, isn't really relevant to what MoS should say now.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:25, 19 November 2015 (UTC)
I (think) this the first time I've raised this here, and as noted it was in response to observing diff-noise from search-and-replace of ellipsis with full-stops. Many things have changed in eight years, including the mw:Typography refresh, and now seems an excellent time to be having such a discussion. On my trip through the Talk archives I've not (yet) been able to find anything supporting there being a general (nor singular) problem with fonts, nor with input mechanisms. Are you aware of any consensus-forming discussion that would justify the continuance of the present asserts? —Sladen (talk) 22:34, 19 November 2015 (UTC)
Whether there used to be justification for it in 2007 is essentially irrelevant. I'll repeat what I said in user talk for the benefit(?) of other readers: It doesn't matter why we arrived 8 years ago at something. It's been stable and has resisted change so there's a consensus for it. Consensus can change, but it does so by presenting a new rationale for why that change should happen, not second-guessing why a decision was made that long ago. We do not have a time machine and cannot go back and re-examine the entire decision-making process. The breadcrumbs left though old discussions are an incomplete snapshot of what the thinking was. We do not need an endless raft of people showing up at MoS claiming they can't find a decade-old consensus for some line-item that triggers one of their personal pet peeves. Nothing would happen at MoS ever again, pretty much, other than dealing with people raising bogus procedural "appeals" against every single thing in MoS they want to change for their own personal reasons. The specific rules in MoS are less important than its stability. Zero editors agree with every single line-item in MoS, and zero line items in MoS have universal agreement. What we do agree on is to operate under it because any project of this sort has to have a style guide, which will necessarily contain many arbitrary things simply to settle disputes and prevent inconsistent usage. Every sport, by analogy, has to have a ruleset, and not everyone will always agree that each of them is perfect, but the game does not go on unless people agree to play by the same rules.

If you have evidence that that rationales for the rule against the (for me, nearly impossible to make out) unicode ellipsis character are faulty, then present that evidence. It's a waste of time to try to "re-litigate" an eight-year-old consensus discussion on the merits of the arguments 8 years ago. If nothing else, it's a WP:DGAF matter. No one cares whether the arguments were good 8 years ago. We care what MoS should say now, based on arguments that make sense now. I see no case really presented for the benefit of using that character today. It's hard to read, hard to type, and may well still present font problems on some systems. Even if that last point is no longer true, it is not the only (present-day) rationale against that character. This is part of a wider-ranging set of issues, e.g. about using Unicode fraction characters and so on. Just because a character exists does not mean it is the ideal representation of something in an encyclopedia.

PS: The idea of a "leave-it-as-is" rule, like we have for spaced en-dash vs. unspaced em-dash, doesn't track. We have that rule because they're both universally recognized style approaches, well documented in most style guides; this isn't true of "…" vs. "..."; they're a different coding approach to what is intended to be parsed by the reader as the same thing; it has more in common with he choice of whether to use a "fi" ligature (fi) or not for kerning purposes. [Interestingly, it does not in fact render as a ligature in all fonts, and Google tells us that there may be accessibility concerns with those, too [9].] — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:55, 19 November 2015 (UTC)

[I moved a bit of this comment of mine to new sub-thread below. -SMcC.]
(edit conflict) If it's helpful for the discussion to know, I would discourage the use of legacy single-codepoint fractions. They go against one meaning one codepoint, and using them disguises multiple characters under a single codepoint (eg. 5 / 16), whereas they each have own semantic meanings. Conversely an ellipsis does have its own semantic meaning and therefore its own encoding and distinct (codepoint) that is different from a trigraph of three consecutive full-stops. A row of row-of nine full-stops ('.........') is not the same as three ellipses ('………'). Endashes ('—') and emdashes ('–') have semantic meanings different to rows of hyphens ('-'), and so their own distinct codepoints too. Not everyone can see the difference with every configuration, but we do do our best to get them encoded appropriately so that it is possible, and would likely discourage any bot trying to replaces emdashes with trigraphs of three hyphens ('---') or endashes with digraphs of two hyphens ('--'). I'm hopefully with a minimal wording change such as that suggested by epic genius above we can reach a wording where the directly/correctly encoded form, or entity, does not appear to be prejudiced to the point that AWB/bot operators are tempted to try easy one-way conversions. Part of this may stem from the example style being different to the rest of the MoS, where instead of Good: …example/Bad: …example, whilst the ellipsis section presently has bold-face Recommended/Not recommended at the end of the line; with the bold-face appearing to overshadow the example itself. —Sladen (talk) 23:29, 19 November 2015 (UTC)
Except that the ellipsis actually is a series a three periods (BrEng: full points). The choice by some typesetters to put it on a single block of type and (often, buy but no means universally) to kern them closer together, and the choice to provide this facility in digitized typefaces to keep the typesetting world happy, really has nothing to do with semantics. The fact that Unicode, and some pre-Unicode code pages, fonts, etc., have supported it as a separate character of its own does not magically imbue it with new semantic meaning. It originated as and is literally written as a period-period-period series. Sematically a series of nine periods and a series of three Unicode ellipsis characters are in fact the same thing - a line of dots that conveys no meaning, but is used as a visual aid or decoration, e.g. to evenly space page numbers in a table of contents. The character string "........." (whatever glyphs and codepoints are used to generate it, and whatever its kerning, either intrinsic to the character encodings or applied by the font or later steps) has no linguistic or other symbolic meaning. There is such meaning in English for "..." and "&9633;", and it's the same in both cases. The only time there's going to be an actual semantic difference is in a language other than English (or probably any other natural language), e.g. in a programming/scripting language where the literal character "." may have a particular meaning to the interpreter/compiler, including in series, where the Unicode character would not parse as the same thing as "...". Some uses of en- and em-dashes are semantically identical (when spaced properly), but in other cases this is not true; e.g., an em-dash is never used in a construction like "US–UK relations". So, some uses of these dash usses are syntactically distinct, while others – like this these—that you are reading now—passages – are not.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:22, 20 November 2015 (UTC)

Looking into accessibility issues[edit]

External searching brings up probably-relevant results: [10] [11] [12].

A similar issue came up very recently (August?) with regard to use of the hair space character,   (rendered here between two em-dashes: — —, vs. two consecutive em-dashes: — —, and a thin-space between em-dashes: — —), which seems like a no-brainer for fonts to support, but many do not. I.e., it's unwise to make assumptions that a particular character is supported it if's not among the most used (–, •, etc.)

If someone actually wanted to test support of the ellipsis character, to do it adequately they'd need to set up virtual machines for at least Windows XP through 10, and MacOS X in various versions, plus various flavors of Unix, and NetBSD, just for starters, and check rendering of a webpage containing that character in various stock fonts in each OS. Doesn't seem like a practical use of anyone's time. Even if you already had all of these VMs handy, it would take many hours. I would hope that someone somewhere has already done some kind of Unicode font support tables for common "Web fonts" across multiple platforms, and by OS version. Hopefully something in this search is what we need.

The fact that reliable sources tell us that Unicode support for non-common characters is spotty and that their use can present accessibility problems should be sufficient for us to remain skeptical and exercise caution. No one is going to suffer any problem at all if their preferred "…" character gets replaced with "...", but the opposite may not be true.

The argument that the character conveys semantic meaning, if I bought it, could make me philosophically inclined to support it, on principle (see parallel discussion among Drupal developers [13]), but only if it's known to not be problematic at the font level, and only if it were done with a template wrapper that applies a CSS class so that those of use with crap vision can make it more legible with a slight font size or character width (transform-scale [14]) increase. (And I don't buy the semantic argument, anyway; see above.) My earlier comment "Just because a character exists does not mean it is the ideal representation of something in an encyclopedia" is particularly salient in this regard. The use of WP as some kind of typography showcase has to take a distant back seat to getting information across to as many people as possible. The hint of semantic information allegedly lost in the translation from "Pi is 3.14159265…" with Unicode ellipsis to "Pi is 3.14159265..." with three dots is much less significant than the loss of parseability information ("this digit continues") in the failed rendering of "Pi is 3.14159265…" as something like "Pi is 3.14159265□" or "Pi is 3.14159265?" (depending on how the OS handles unknown characters). The actual output of the Unicode ellipsis is wildly inconsistent. In many of the fonts I use, it is almost indistinguishable from an underscore (_) with my eyesight, especially in a monospaced or narrow font, but in one I just tested, it's actually wider than three dots. This means that a template wrapper should not force a font-size increase, just apply a class people can adjust to suit their browser's usual font, and their eyes. It's also notable that the use of Unicode fractions actually interferes with many things, including templated math operations and the ability to copy-paste (or otherwise get at) the numbers in a way that can be operated on by external tools, (e.g. pasting into a calculator app, or exporting a WP table to a spreadsheet), so we devised {{Frac}} to do something visually like this but more functional. I.e., avoidance of Unicode can sometimes increase semantic value. An over-generalized approach of "Unicode can do this now, so we must do it with Unicode" is not valid. It's always going to be case-by-case. A strong argument can be made, for example, for using "–", not the bare character "–" in wikicode, because in many fonts (especially monospaced ones in the editing window) it's impossible to tell the difference between "–" and "-". It's unfortunate that the "–" button in the editing tools cannot be configured (and isn't configured by default) to insert the character entity code instead of the bare symbol (especially since this may also interfere with editability on some Unix/Linux platforms when in a text browser, not that this comes up too often, I guess).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:22, 20 November 2015 (UTC)

Proposed ArbCom decision will directly affect "language activism"[edit]

WP:MOS (and WP:AT, and WP:RM) are frequently beset by language change advocacy, and we'll shortly have something to use against this particular form of PoV pushing. The upcoming ArbCom decision at Wikipedia:Arbitration/Requests/Case/Genetically modified organisms/Proposed decision: The purpose of Wikipedia is to create a high-quality, free-content encyclopedia in an atmosphere of cameraderie [sic] and mutual respect among the contributors. In particular, it is not the purpose of Wikipedia to right great wrongs; Wikipedia can only record what sources conclude has been the result of social change, but it cannot catalyze that change.

While that's not an MOS/AT case in particular, this is a general statement of principle, and its reasoning obviously applies broadly, including to various sorts of campaigning that are brought to MOS and AT.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:39, 20 November 2015 (UTC)

Skimming the PD I'm not seeing much in the way of reasons why this was brought up. It's kind of unfortunate that "follow the sources" has to even be said, but there /have certainly been several cases (Bradley/Chelsea Manning) where that principle has gotten lost with poor results. Der Wohltemperierte Fuchs(talk) 04:06, 20 November 2015 (UTC)
Well, yes. I brought it up because that's true, it's been true in other areas like GMO articles, and ArbCom is finally spelling this principle out clearly. Most of the quoted passage is just summary of policy, but the new part is "Wikipedia can only record what sources conclude has been the result of social change, but it cannot catalyze that change." It's liable to come up repeatedly henceforth.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:34, 20 November 2015 (UTC)
No question that we have to be vigilant about people trying to use WP as a vehicle for language reform. But no arbcom decision is going to be a magic bullet. It just has to be addressed case-by-case. As I understand it, ArbCom decisions, in theory, don't even set precedent. --Trovatore (talk) 06:53, 20 November 2015 (UTC)
Sure would be nice. Darkfrog24 (talk) 13:19, 20 November 2015 (UTC)
(ec) They don't set precedent, in the sense that ArbCom does not consider itself bound by previous decisions in addressing new cases; in this, it's more like a civil law than common law system. However, in actual practice there's a strong influence from one similar case to the next (easily observable by the increasing number of boilerplate Principles and Remedies reused in similar cases); admins and the community at large apply reasoning in decided cases to similar situations (aided by the "broadly construed" language in various remedies); and ArbCom, AE, ANI, etc., look strongly askance at WP:LAWYER / WP:GAMING attempts to evade application of accepted principles on the basis that it was from a particular case and can't be applied just because the page in question is different from the one[s] in the case[s]. Yes, no magic bullet, but I expect it will have a significant effect. If the constant battlegrounding about how we write about transgender individuals, for example, were to continue (I seem to recall at least four different mile-long Village Pump debates about this in the last 6 months or so, as well as several years of "slow editwarring" over the content of the applicable section at MOS), I have no doubt that it'll end up at ArbCom, and that a similar MOS-specific Principle that "WP ... cannot catalyze that change" will be in the decision in that case, perhaps directly copy-pasted from the one in the GMO case. This is overdue and badly needed; I doubt any of us are unaware that WP being in the top 5 websites in the world, and millions of people's go-to source for basic information about just about everything, has markedly increased special-interest pressure on our content and self-governance from outside parties with advocacy/propaganda goals.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:34, 20 November 2015 (UTC)
Well, with transgender pronouns there's really no way to not take a position. Say "she" and you say that the trans woman really is a woman. Say "he" and you say she isn't. Switch back and forth and you say that human beings can change gender. Don't switch back and forth and you say they can't. We could never talk about transgender individuals, but that's taking the position that they shouldn't be talked about. But for most issues, yes, there's some neutral or standard or at least prevailing option that can be used. Darkfrog24 (talk) 18:19, 20 November 2015 (UTC)
So avoid pronouns (at least in historical material before the change / public coming out). The only cost of that avoidance is some rewording time and sometimes a little bit of extra use of a surname. "Foo produced the play Bar in 1997. In 2000, Foo then ..." instead of "Foo produced the play Bar in 1997. In 2000, he then ...". It's certainly much less painful than two months of flamewarring on the talk page about whether to use "he", "she", "he/she", "(s)he", etc., etc.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  18:41, 20 November 2015 (UTC)
The surname solution does work much of the time, always avoiding pronouns is poor writing. Darkfrog24 (talk) 02:13, 21 November 2015 (UTC)
For most subjects, the "before" material won't be all that much of the article (Jenner is an exception, due to the unusual lateness in life of the transition). Some awkwardness in writing is preferential to years of continued editwarring about the matter at article after article, surely. Because English is itself in transition on this issue, every possible way to attempt to write about such subjects is going to be awkward, even uncomfortable, for a significant portion of our audience, no matter what. I think I'm mostly re-stating what you're saying, on a re-read, but not coming to the same conclusion (?). Anyway, I wasn't trying to create a redundant thread about what we should do about TG subjects; I was just using it as an example of what this kind of ArbCom reasoning will probably be applied to sooner or later.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:16, 27 November 2015 (UTC)

Confusing gender constructions[edit]

There's been a bunch of back-and-forth just now over the wording of the "avoid confusing constructions" advice at MOS:IDENTITY. The advice to avoid confusing constructions very clearly does reflect consensus, and is an in-context application of the MOS lead's common-sense advice to rewrite around intractable conflicts. Ongoing debate at the Village Pump, in discussions that have not even concluded yet, doesn't change that. Reviewing this, it's clear that the contentious part is the suggestion, in the example, to revise by using a pronoun-based construction that is presently hotly disputed at VP, and has previously been disputed at VP and at MOS, and at other places. The solution half of an example being disputed is not a dispute about the identification of the problem.

The obvious workaround is using example language like this instead: "Avoid confusing constructions (she fathered a child) by rewriting (e.g., Smith became a parent)." Or not providing an example of what to rewrite to, and only preserving the example of what we mean by confusing constructions. (And, yes, it was pulled from an actual article; in a search during the previous round of debate, I found at least half a dozen cases of "she fathered a child" or "he gave birth" in real articles, and that was long after the advice had been in MOS, meaning there used to be even more of them, that triggered that addition to MOS in the first place and got cleaned up afterward).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  13:51, 21 November 2015 (UTC)

"Smith became a parent" sounds good. Darkfrog24 (talk) 13:57, 21 November 2015 (UTC)
Sounds good to me too. Peter coxhead (talk) 14:56, 21 November 2015 (UTC)
Sounds good to me as well.Godsy(TALKCONT) 16:37, 21 November 2015 (UTC)
It looks like this points towards the idea that transgender people should not be referred to with pronouns at all before the transition. Any clarification on the exact rule?? It says:
Any person whose gender might be questioned should be referred to by the pronouns, possessive adjectives, and gendered nouns (for example "man/woman", "waiter/waitress", "chairman/chairwoman") that reflect that person's latest expressed gender self-identification. This applies in references to any phase of that person's life.
But this points towards the idea that it should go:
Any person whose gender might be questioned should be referred to by the pronouns, possessive adjectives, and gendered nouns (for example "man/woman", "waiter/waitress", "chairman/chairwoman") that reflect that person's latest expressed gender self-identification, as long as no confusion can result from wordings. If confusion can result, then try to avoid pronouns.
Any corrections on the wording?? Georgia guy (talk) 15:01, 21 November 2015 (UTC)
This section was recently discussed. A good point raised in that thread was that part of the problem comes from putting undue emphasis on biology in ways we wouldn't normally do. The phrase "fathered a child" is only used in 244 articles, which appear to mostly deal with situations where there is some doubt as to paternity. However "became a parent" is even rarer, appearing 18 times, many of which are "became a parent figure/company/etc.". By my count, only three of those uses are intended as direct statements about a real person having a child. I think part of what makes this advice stick out is that the language being recommended isn't much of an improvement over what is being proscribed.
A possible rewording could be: "Avoid confusing constructions and placing an undue emphasis on biology (e.g., she fathered a child) by rewriting (e.g., Smith had a son)."--Trystan (talk) 16:48, 21 November 2015 (UTC)
Trystan, I can't believe that you disagree with the absoluteness of the original rule; you're the one who wrote the Wikipedia:Gender identity essay, and included as one of the questions "Isn't it confusing??" Georgia guy (talk) 16:59, 21 November 2015 (UTC)
For clarification on what I'm talking about, this is the second question in the "Retroactivity" section of the Wikipedia:Gender identity essay. Georgia guy (talk) 17:00, 21 November 2015 (UTC)
I don't see a conflict. I do support a presumption of retroactivity when someone comes out as trans (as opposed to the presumption that someone changed genders). The essay also says that clear drafting is the antidote to confusion, and in some cases it is clearest to simply write around the pronoun, rather than going into undue detail about someone's gender identity and gender presentation at a given time. I don't know that I agree with the absoluteness of any MoS rule.--Trystan (talk) 17:36, 21 November 2015 (UTC)
It's not clear what "An undue emphasis on biology" is. Dingsuntil (talk) 23:02, 21 November 2015 (UTC)
I don't like "Smith became a parent" because it's not obvious how Smith became a parent. Did Smith provide sperm? An egg? Did Smith adopt? I don't know of any English word besides "Fathered" which indicates that Smith actually did. "Smith had a child" is better than "Smith became a parent" in that it indicates that Smith is the natural parent of the child. I still prefer "Smith fathered a child." Dingsuntil (talk) 23:00, 21 November 2015 (UTC)
You mean, for you the Smith we're talking about should be treated like a man for this purpose, not a trans woman?? Georgia guy (talk) 23:31, 21 November 2015 (UTC)
(edit conflict) If it needs to be clarified, we'd clarify it with a sentence explaining what happened. It's senseless in this area to attempt to rely on hotly disputed pronouns to do this for us. Especially given that it's physically impossible for a transwoman, born biologically male, to have provided the egg in the process for forming a baby. The question simply doesn't arise. If you adopt, you aren't becoming a parent, you're become and adoptive parent, and regardless, we'd say "The Smiths adopted a son", or "Smith and Jones adopted a daughter" or whatever, anyway, using prose that doesn't read like it was written by a robot. :-) I return to the MoS lead's common-sense admonition: Rewrite to avoid confusion and conflict.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:12, 27 November 2015 (UTC)

Anything that states or implies that transgender subjects should never be referred to with pronouns should be chucked. Yes, most of the time we just use the surname for any subject, but requiring it in all instances requires poor writing. Does it need to be obvious how Smith became a parent? "Smith's son was born," "Smith had a daughter," etc. are also good in my book. As for the text of the guideline proper, that's under discussion at the village pump and currently awaiting closure. We should probably wait for that to finish before making any other changes. Darkfrog24 (talk) 04:39, 23 November 2015 (UTC)

I support including advice to prefer "became a parent" or "had a child" to "fathered a child" for reasons I outlined in last month's discussion; I oppose bringing a preference for names vs pronouns into this, especially since it contradicts the guidance earlier in the paragraph to use (gender-identity-based) pronouns. Let's stick with the wording we currently have ("name → name"), or else go back to the "pronoun → pronoun" language which had been in the MOS, unless there's consensus specifically to switch from those to a construction that deprecates pronouns. @Dingsuntil, noting who provided sperm would generally be undue, in Wikipedia parlance, if sources only consider "A is B's parent" important and not details of how "[trans woman A] used her sperm to become the father of B with an ovum from C via penis-in-vagina sexual congress". -sche (talk) 07:13, 23 November 2015 (UTC)
I concur with -sche on this, in the interests of "cleanness of consensus". We need to address this one part at a time, or more flamewarring will surly erupt. While I dispute recent changes that seem to suggest rewriting history, and dispute that they represent consensus more specifically, it's clear that there's a consensus to advise avoiding constructions like "she fathered a child" and "he gave birth", and we can fix that independently of any other questions, and come back to those separately. The less we commingle these issues, the more stability we'll achieve.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:08, 27 November 2015 (UTC)

Should Wikipedia use made-up or neologistic pronoun replacements in Wikipedia's own voice?[edit]

FYI: Pointer to relevant discussion elsewhere.

This has come up before, but here it is again: Talk:Genesis P-Orridge#RFC: is the idiosyncratic use of s/he and h/er acceptable in this article?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  21:26, 21 November 2015 (UTC)

We don't need special pronouns for transgender people. A trans woman should be referred to as she/her throughout her life. The only times we refer to a trans woman as he/him are:
  1. Direct quotations (direct quotations must keep their original words; this rule takes priority over all other rules except the need to avoid foreign languages.)
  2. Titles of works (e.g. if somebody wrote a book called "Bruce Jenner: How He Did at the Olympics", we would keep the old title.
  3. Situations where the statement that someone is transgender is an un-verified rumor, per WP:VNT.

Any how abouts?? Georgia guy (talk) 22:44, 21 November 2015 (UTC)

I'm going to go with no. Wikipedia should not use made-up words. If some kind of gender-neutral pronoun enters the lexicon, we can start using it then. Darkfrog24 (talk) 22:56, 21 November 2015 (UTC)
  • This was a pointer to an ongoing thread on another page not an attempt to forum-fork it. And to clarify (since one respondent here knew what I meant but one did not) this isn't about pronoun use in general, but about adopting neologistic ones preferred by the subject and using them in WP's own voice.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  10:01, 27 November 2015 (UTC)

№ no. no[edit]

I have a memory of advice on the use of the symbol № and other replacements for "number", as in number 4, №4, #4 etc (see e.g. Nonna Mordyukova). Whereabouts would I find it? TIA Mr Stephen (talk) 23:45, 23 November 2015 (UTC)

See MOS:NUMBERSIGN.—Wavelength (talk) 23:58, 23 November 2015 (UTC)
Ah, that's it. Many thanks. Mr Stephen (talk) 00:03, 24 November 2015 (UTC)

UK punctuation[edit]

MoS currently offers substantive advice on "National varieties of English", but on punctuation remarks curtly "The accepted style of punctuation is covered in § Punctuation, below". In my observation the guidance there on dashes does not reflect the usual British practice, whereby m-dashes – which are used only as stops – have spaces before and after; while date or time ranges (such as 4-13 November) use hyphens rather than dashes. Deipnosophista (talk) 12:00, 24 November 2015 (UTC)

Deipnosophista, in your query – above – you have en-dashes—is this intentional? However, yes, date ranges such as upcoming holidays circa 24–25 December do preferably use en-dashes, not hyphens. —Sladen (talk) 12:50, 24 November 2015 (UTC)
This is not a query, but an assertion that the policy is unacceptably US-centric, and should be subordinate to WP-TIES. Deipnosophista (talk) 16:40, 24 November 2015 (UTC)
Likewise, I wanted to get the use of the likes of "Isil" and "Nato" permitted on the basis of ENGVAR, but that was to no avail. Regardless, the issue with dashes is so minor as to be not worth arguing over. It is already standardised, and standardisation is desirable, as it limits conflict. Have you not noticed that this style guide prefers logical quotation, for instance? RGloucester 17:02, 24 November 2015 (UTC)
Just because the MoS does something incorrect doesn't mean it needs to keep doing it. The rule that RG cites here, WP:LQ, requires that all articles, even those written in American English, use British punctuation styles. It has low compliance in the article space, even in featured articles, and is probably the single most challenged part of the MoS. If Depnosophista is right and the MoS requires that articles written in British English use a punctuation system that is incorrect in British English, then we should of course correct the MoS. Darkfrog24 (talk) 17:09, 24 November 2015 (UTC)
How do we know it is incorrect? Is there a reliable source I can read that will tell me this? --Jayron32 17:20, 24 November 2015 (UTC)
DrKay has provided this information from a sourced Wikipedia article. Darkfrog24 (talk) 17:34, 24 November 2015 (UTC)
Our articles on English punctuations topics are mostly a farcical shambles, and are not reliable sources for anything other than the conclusion "these articles badly need work". I've already done the source research to improve one of them, but haven't had to time to spare to work on it in detail. And compliance with LQ is quite high in mainspace, and has been since the project started. If people are not willing to do the source research to back their claims of some ENGVAR grievance, the thread should simply be closed and archived. WT:MOS spends to much time dealing with these "I want unsupported style nitpick inserted into MoS" demands. Even if a usage is sourceable doesn't mean that consensus here will adopt it. Style is largely arbitrary, and stability is more important than any particular line item's exact wording in the MoS. Some changes to MoS could affect quite literally millions of articles and tens, maybe hundreds, of millions of lines in them, and thus should not be implemented unless there are overwhelmingly compelling reasons to do so.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:21, 26 November 2015 (UTC)
No, compliance with WP:LQ is not high in the mainspace. While we're on the subject of doing the research, a while ago, I actually counted how often featured articles were in compliance with WP:LQ, and a few other editors did the same assessment in non-featured articles. It was about 60% in featured articles (sample size ≈365 articles) and in the 30–40% range for American and Canadian articles (sample size ≈40 articles). But by all means go count them yourself if you don't want to take anyone else's word for it.
But there's no need to scold Deip for not doing the research. Maybe he or she just didn't know that that's how things work around here. We have someone who showed up with a problem. We asked for sources to confirm that the problem was real. Said someone did not complain about it. That means the system's working. Darkfrog24 (talk) 04:09, 27 November 2015 (UTC)
(edit conflict): "Isil" and "Nato" are not permitted because they're confusing, and not standard English. It's certainly not an ENGVAR matter, and this usage isn't supported by anything but a small number of minor journalism style guides (both US and UK). No major style guides support it, journalistic or (more importantly) academic. We already examined and established that pretty recently.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:21, 26 November 2015 (UTC)
EDIT CONFLICT: In general, I agree that ENGVAR has its place in the MoS. Let's start there. Deipnosophista, do you have a source, like a mainstream style guide, that gives British practice vis a vis dashes and hyphens? A group of specifically British sources that stipulate "do this" would be good, but one that says, "British/U.K. practice is to do this as opposed to other practices that do that" would be better.
Yes, yes, I know not everyone here thinks that the MoS has to be sourced, but establishing what British practice is is a question of fact. Even those of you who think that the only authority we need is our own decisions should not object to basing those decisions on a solid foundation. Darkfrog24 (talk) 17:04, 24 November 2015 (UTC)
Dash#Spacing and substitution says mdashes are not spaced in the Oxford style guide and are spaced in the New York and AP style guides, which is the opposite way 'round to what is suggested above. It also says at Dash#Ranges of values that hyphens in date ranges are used by the AMA style guide but not the APA style guide, which indicates no preference for hyphens versus dashes in dates in the United States. DrKay (talk) 17:07, 24 November 2015 (UTC)
It's not really a matter so much of this publisher vs. that one, but the simple fact that virtually no journalism style guides even concede that the en dash exists; they use a hyphen for all situations where other publishers would use an en dash, or even a minus; for short horizontal lines they have nothing but the "hyphen-minus", used singly as a divider/conjunction, and the em dash, used (as in other styles) paired for emphasized parenthetical markup, and singly to indicate truncation or a syntactic break. WP doesn't care, because WP:NOT#NEWSPAPER and is not written in news style. Our article structure has only passing similarity to that of a newspaper article, and our prose style is nothing like that of news copy, unless you compare us to a Facebook post or a letter from Grandma. Being an online development from the formerly all-book world of encyclopedia publishing, WP style is based primarily on academic book publishing styles, with some influence from journals, and very little influence from journalism style (which typically sacrifices precision for economy due to space and reader-attention constraints, and is heavily influenced by PR and fiction styles). The primary inspirations for MoS's rules are The Chicago Manual of Style, The Oxford Guide to Style (under various titles) and the Manual of Scientific Style and Format, and the Modern Humanities Research Association Style Guide.

As for the original question, I've done, below, about 40% 80% or so of the necessary research. I don't see any sources yet drawing a sharp distinction between US and UK style on this (and MoS does not always care if there is one, if it's more trouble to implement than it's worth). The closest so far is Oxford/Hart's, suggesting that spaced en dash (versus unspaced em dash) is primarily a British style, but is not universal among British publications (Oxford style itself does not use it). So, there is no evidence of a strong national tie (so far). More to the point, I find no evidence in support of either of the OP's assertions, that "British style" may use spaced em dashes for commas (stops) in parentheticals, and that it uses unspaced hyphens to separate numbers in spans/ranges. I firmly predict that the latter will appear only in journalism style guides (which it does on both sides of the Atlantic, as demonstrated below) and that the former is simply wrong. All the British sources cited so far do not agree with the OP.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:21, 26 November 2015 (UTC)</a>

40%? I'd say you've gone above and beyond, SmC. Darkfrog24 (talk) 04:09, 27 November 2015 (UTC)
Heh. That was from the draft stage; I'd meant to update that to 80. :-) I'm cursing myself for not including page numbers though; need to dig them all up so this can be used for article sourcing, which is more important than MoS discussions. I'm going to try to remember to dual-purpose any such sourcing runs from now on.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:50, 27 November 2015 (UTC)

External sources on possible ENGVAR issues with spaced en dashes[edit]

MoS doesn't need external sources cited in it to offer any advice (which is determined by consensus on what's best for WP), but it's often helpful to formation and maintenance of consensus to review what they're doing (sometimes these things change in "the real world" faster than most people think they do, e.g. the decline in "U.S." outside of certain publishing contexts over the last decade). I'm eliding various nitpicks like use of dashes next to other punctuation, and use of spaced em dashes in indexes and dictionaries to indicate repetition of a headword, or doubled em dash (= 2-em dash character) to indicate repeated author name in a bibliography, etc. We don't care about that stuff.

Wikipedia is written in academic style, not news style. Here's some key academic style sources on dashes [more later, when I get home again]:

Sources that comment on the matter seem to agree that use of pair of dashes as parenthetical interruptors—like this—will emphasize the interruption more than use of commas does. The MLA Handbook, adds: "Dashes make a sharper break in the continuity of the sentence than commas do, and parentheses make a still sharper one". The Copyeditor's Handbook observes "a pair of commas is the neutral choice; dashes emphasize the interrupter, while parentheses de-emphasize it." These views are not mutually contradictory, as the former is about syntactic relationship to the core of the sentence, and the latter is about visual and perhaps mental parsing impact. Oxford/Hart's somewhat combines these observations: "Use the dash to ... express a more pronounced break in sentence structure than commas, and to draw more attention to the enclosed phrase than parentheses."

Journalism style guides, which have little effect on MoS, non-fiction books, journals, or other forms of academically-oriented writing:

Given these journo stylebooks, I think it is safe to conclude that some WP editors' loathing for the use of the en dash in "France–Germany relations" constructions is most often directly tied to individual familiarity with and preference for news style, probably especially the AP and Guardian stylebooks (the NYT guide is not widely used, while AP style has even had a bit of influence on British and other journalism that can be detected if you study changes in British style guides over time).

It's also clear that the "Nato" style of giving acronyms is simply The Guardian's own house style. The one attempt I can find to emulate it, by The Times of London, didn't even get it right and isn't self-consistent. While the NYT proposes something similar, it's only for long acronyms, has a different rationale, and directly conflicts with Guardian usage except where they converge on longer acronyms like UNESCO -> Unesco by accident. It's not "British style", it's simply expedient at the cost of precision, and has no place here. That said, all these sources – UK, US, academic, journalism – accept full lower-casing of acronyms that have been reinterpreted and integrated into English as everyday words, such as "laser" and "radar", which most people don't even know are acronyms. Exactly what words qualify varies from sources to source (when they provide many examples at all), but is essentially a matter of linguistic description not prescriptive grammar; MoS thus need not try to provide a list, and we can just leave this up to editorial discretion at articles, since it's liable to vary by context anyway. There's also broad agreement that company names that originated as acronyms (Exxon, Ikea) may be written in mixed case when it's conventional to do so, and may remain upper case when conventional for those companies (GEICO). All the guides also accept lowercasing of some "functionary" initialisms and acronyms, like "e.g." (whether to use dots varies by guide, with the no-dots style only appearing in British one, and only in some of them); there's disagreement about a few of these, e.g. "a.m. / p.m." versus "AM / PM".

PS: A template-coding upshot of all this is that almost everyone thin-spaces or at least hair-spaces em dashes, so our own — template should be doing this (I've sandboxed this at Template:Em dash/sandbox just now, and had already used such kerning on all the quotation templates several months ago (except one, I think {{quote box}}, which does not preprend a dash before the cited author the way the rest of them do).

To-do?: This is just a quick run through some handy volumes; I could pull up plenty more if it's wanted, but I have a holiday party to get to, so I have to run for now. In particular, I've not gone over legal style guides, the ACS, AMA, & APA manuals, the Columbia, McGraw-Hill and American Heritage guides, the guides included in major dictionaries, the UN's various "international English" guides, Writing for Scholarly Journals, The Blue Book of Grammar and Punctuation, The Handbook of Good English, and a few others that might be worth looking at (I have a Canadian and an Australian one around). The odds that I'll bother with that are low, however, since this is time consuming, and we already have enough evidence at hand to put to bed the various complaints raised.

Conclusions so far:

  • No particular dash usage has a strong national tie (though unspaced em dashes are more common in AmEng than spaced en dashes, for uses in which either are acceptable).
  • The uses of en dashes we outline in MoS are not made up WP-isms.
  • The substitution of hyphens for en dashes (and even minuses) is a journalistic expediency, not supported in academic style guides.
  • When en dashes are used in place of em dashes, they should be spaced.
  • Em dashes are not spaced in most uses.
  • En dashes are not spaced in constructions like 1997–2002.
  • Acronyms should be written UNESCO not Unesco, except where they're company names or the like for which the convention is to treat them otherwise (Ikea, Exxon), or where it's conventional to give them all-lowercase (e.g., i.e.), or where they've been assimilated as words (scuba, laser).
  • The "Unesco" style is not "British", it's just an expediency favored by a small number of US and UK newspapers, who do apply contradictory rules, rationales, and results to the question.

The only thing I did not run across in this sourcing spree is spacing of en dashes in complex ranges. But who cares? It's entirely and perfectly sufficient that WP has arrived at a consensus to do it that way for readability. The style exists off-WP, even if a morning's research didn't turn up a paper-book rule for it.

— SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:21, 26 November 2015 (UTC)

Way to bring it, SmC. Darkfrog24 (talk) 04:09, 27 November 2015 (UTC)
Happy to do it, when it settles a dispute. Several at once, in this case.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:40, 27 November 2015 (UTC)

Followup sourcing[edit]

Arbitrary break. And I am so full of [American] Thanksgiving dinner I'm in pain. >;-)

I went thru some of that too quickly, and forgot some stuff; have also added one source:

Anyway, I was in a bit of a hurry when I did all of the above, and should have thought to input the page numbers as I was going along, so that all of this could be used to improve our actual articles on dashes with source citations. I guess I can re-examine this stuff tomorrow and add that info, as I now want to look at the "en dashes for compound, complex modifiers" material again more closely. There seem to actually be three divergent rules: Do it generally, do it when there's already a hyphen, do it with or without a hyphen if it involves a multi-word proper name. MoS should probably use the generalized version, since editors familiar with either rule are apt to follow it, it improves readability, and it's backed by multiple sources. The last matters because it means a lot of editors and readers will expect it to work that way and be confused by with the narrower, conflicting approaches, not because MoS "needs to be sourced". What does need to be better sourced are our shaky grammar and style articles.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:40, 27 November 2015 (UTC)

Need help determining the common name of an individual[edit]

This is regarding a naming dispute at WP:VIDEOGAMES and the individual in question is a Swedish professional Counter-Strike: Global Offensive player for Ninjas in Pyjamas. Possible variations of an article title as seen in reliable and unreliable sources include:

--Prisencolin (talk) 15:15, 24 November 2015

Are you disputing the article title or the lead sentence? If it's the article title it should either be Patrik Lindberg or f0rest. Then you should determine what common name is most prevalent in secondary reliable sources such as gaming competition articles. Cases can be made for either. Swedish wikipedia uses his real name, but with other gamer articles like Nadeshot use the gaming handle. I don't see any cases where the quotes version need to be in the article title. As for lead sentence, writing Patrick "f0rest" Lindberg would imply that people would call him f0rest Lindberg, which I don't see any support for that in what you have presented. AngusWOOF (barksniff) 19:42, 24 November 2015 (UTC)
This is regarding the article title. It's an interesting concern that first "alias" last shouldn't be used if the individual isn't actually known as alias last, but I'm not sure if that's actually standard English usage.--Prisencolin (talk) 14:39, 25 November 2015 (UTC)
Concur with AngusWOOF. The lead should probably say something like "Patrik Lindberg, better known as f0rest", since it's an alias, not a nickname used with his surname. Titles questions should usually go to WT:AT unless they're about a style matter within the title (diacritics, etc.). But since it's already been raised here: Judging from the sources cited so far, the stand-out appears to be "f0rest" as what this person is publicly known as. The sourcing giving his real name all seem to be self-published. They're valid per WP:ABOUTSELF for establishing what is real name almost certainly is (barring unlikely weirdness like he's really an at-large criminal using a fake name as well as a gamer moniker :-), but they don't have anything to do with WP:COMMONNAME which is based on independent, secondary sources.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:58, 27 November 2015 (UTC)

Wikipedia:Manual of Style/Supports[edit]

Formerly Wikipedia:Manual of Style/Sources

See also: Wikipedia talk:Manual of Style/Archive 105#Guideline-by-guideline citation of sources (November 2008)

I have started Wikipedia:Manual of Style/Sources, and I invite editors to populate it with sources.
Wavelength (talk) 23:35, 24 November 2015 (UTC)

If you mean to list sources that support existing MoS content, then I'm pleased to say that we've gotten started. If you want the actual sources that were used to place the rules there in the first place, that might be harder.
I was against the MOS:REGISTER when it was first proposed, but it's quite won me over. Darkfrog24 (talk) 03:54, 25 November 2015 (UTC)
Thank you for your support. Sources that support existing MOS content are adequate. (The external links at User:Wavelength/About English/Adverbs and hyphens#Google Search may be helpful.)
Wavelength (talk) 04:16, 25 November 2015 (UTC)
I am considering the shortcut "MOS:SOURCES", but I have found that "MOS:SOURCE" is already in use.
Wavelength (talk) 05:02, 25 November 2015 (UTC) and 05:26, 25 November 2015 (UTC)
I have applied the shortcut "MOS:SUPPORT".
Wavelength (talk) 05:35, 25 November 2015 (UTC)
I have renamed the new subpage as "Wikipedia:Manual of Style/Supports" and I have revised the shortcut to "MOS:SUPPORTS". I am revising the heading of this section from Wikipedia:Manual of Style/Sources to Wikipedia:Manual of Style/Supports, in harmony with WP:TPOC, point 12 (Section headings). Please see Microcontent: How to Write Headlines, Page Titles, and Subject Lines. The new heading facilitates recognition of the topic in links and watchlists and tables of contents.
Wavelength (talk) 16:28, 25 November 2015 (UTC)
Now it looks like "things that the MoS supports." Given that we're on Wikipedia, the word "sources" is a little more recognizable. EDIT: I think it's the plural that's knocking the meaning out. Darkfrog24 (talk) 19:54, 25 November 2015 (UTC)
The word "Supports" is a noun (not a verb), as it is in "Wikipedia:Supports".
Wavelength (talk) 20:20, 25 November 2015 (UTC)
Yes, a plural noun. Still sounds funny. Both here and in this page you've cited, it would work better as "Support." Darkfrog24 (talk) 22:04, 25 November 2015 (UTC)
As I explained in June 2015 (User talk:Jimbo Wales/Archive 189#Wikipedia:Supports), English readers might initially be alarmed by what appears to be a command ("Support!"). Also, English "sources" is like English "supports" in being both a noun and a verb. Do you prefer the singular form "Source"? If you or I change it back to "Sources", what would be a suitable shortcut? Alternatively, what other one-word options are available for the name of the subpage? If this issue is important for you, I can try to find another name, possibly with more than one word (such as "Supportive style guides"), and a corresponding shortcut (such as "MOS:SSG", in which "SSG" is unfortunately close to "SSF" in "WP:SSF" on a QWERTY keyboard).
When I changed the name to "Supports", I actually anticipated that you would find it to be better than "Sources", as I found it to be. Not all the MOS guidelines are necessarily supported by outside sources, because in a few cases MOS guidelines are based on the unique needs of Wikipedia.
Wavelength (talk) 23:02, 25 November 2015 (UTC)
In case this isn't clear, this is a "huh, sounds funny" objection and not a "no no no no no!" objection.
"Sources" is clearly not being used as a verb in "Manual of Style Sources." "Supports" does look like a verb in "Manual of Style Supports," while "Manual of Style Support" looks like it means "Support for the Manual of Style." Darkfrog24 (talk) 01:21, 26 November 2015 (UTC)
"Manual of Style External Support"? "Manual of Style Independent Support"? "Manual of Style Third-party Support"? Darkfrog24 (talk) 01:23, 26 November 2015 (UTC)
Skillful reading is like skillful driving, inasmuch as one needs to pay attention to all the important signs. (Commercial billboards are not important.) Ignoring a virgule can have undesirable results, and ignoring an important traffic sign ("Stop", "Slow", "Merge", "Yield", "Detour") can have undesirable results. The article "Non-restrictive clause" illustrates how the meaning of a statement can be affected by the presence or absence of a comma. The virgule in "Manual of Style/Supports" is a sign performing an important function, and it should not be ignored.
Wavelength (talk) 05:28, 26 November 2015 (UTC)
"Should not be ignored" is one thing. "Will not have an effect during a new reader's first impression of the phrase" is another. Darkfrog24 (talk) 11:35, 26 November 2015 (UTC)
Here is a point-by-point analysis of the situation.
  • The word "supports" can be a plural noun or a singular verb (a third-person singular present indicative active verb).
  • The word "support" can be a singular noun or a verb (a third-person plural present indicative active verb, a first- or second-person present indicative active verb, an infinitive verb, a subjunctive verb, or an imperative verb).
  • The plural noun "supports" is valid as a reference to various sources supporting WP:MOS guidelines.
  • The singular noun "support" is valid as a reference to those sources collectively.
  • The verb "supports" can be a problem for a reader who ignores the virgule.
  • The verb "support" (especially the imperative verb "support") can be a problem for a reader who pays attention to the virgule.
  • Tailoring the subpage name for readers who ignore the virgule disadvantages the readers who pay attention to it, and vice versa.
  • How far should we go to accommodate the less competent readers? I believe that, in matters like this one, accommodating incompetency tends to promote incompetency. On the other hand, accommodating competency tends to promote competency.
  • At this moment in the history of the World Wide Web, many readers (possibly most readers) are already familiar with virgules in web addresses, so they are accustomed to paying attention to them.
  • Therefore, the form "supports" in the subpage name is the preferred option for the benefit of readers who pay attention to the virgule, and also even for the benefit of readers who ignore it (briefly at first).
Wavelength (talk) 20:23, 26 November 2015 (UTC)
"Competency" vs "incompetency" might be a little extreme for this situation. I've been using the Internet for as long as it's existed, and that's how I parsed this title when I saw it, and I already knew what the page was for. Wikipedia is known for flippant and non-standard use of essay titles. "Things that the MoS supports" is a reasonable first-impression interpretation. Darkfrog24 (talk) 04:13, 27 November 2015 (UTC)
A better exercise would be trawling the archives to identify where consensus was established for each particular !rule. A listing of external sources for particular items does Wikipedia zero good IMO. --Izno (talk) 00:42, 26 November 2015 (UTC)
We already have that, Izno. It's MOS:REGISTER. As for what good this new page does, it establishes that the MoS is not entirely based on the whims and arbitrary personal preferences of a clique (though it is partially based on them; we've got to work on that). Think of someone coming to the MoS and saying, "Why should I follow this rule if you guys just made it up because you felt like it? What makes you so much better than I am? I just don't feel like it, so it all cancels out." Even if you don't think that sourcing is necessary, I don't see how it does any harm. Darkfrog24 (talk) 01:21, 26 November 2015 (UTC)
Consensus doesn't work that way. It doesn't work that way anywhere on WP, so there's no reason to expect it to work that way at MoS. The fact that MoS is sometimes approached as if it were specially different, as if normal consensus operation doesn't or shouldn't apply here, and as if WP:LOCALCONSENSUS policy doesn't exist or somehow doesn't apply to a particular wikiproject or pet topic, is the #1 reason that WT:MOS flares up in perennial flamewars and WP:MOS and its subpages are subject to perennial bouts of editwarring. Maybe MoS's lead needs to just be clarified a bit more.

Fixing the Register: It would be useful if it were well-developed, but it's very incomplete, and is cherry-picked too much to highlight particular threads that a small number of editors want to highlight about particular style points (a natural result of someone taking the time to dig through pages to settle some question, but a strongly biasing factor nonetheless). Large segments of it have nothing at all, and those that do are gappy as to their inclusion of the actual discussions that took place about the topics in question (people tend to stop digging and cataloguing when they find what they're looking for).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:52, 27 November 2015 (UTC)

  • Merge to MOS:REGISTER, what little material there is in there. I disagree with the rationales for such a "/Supports" page (however named), I do agree with Izno that it would be a better expenditure of "process editor" energy (and agree with Darkfrog24 that the Register is where it belongs) to improve the indexing of consensus discussions in the Register, than to start up an essentially competing side project for the pointless exercise of trying to externally source every single thing in an internal, consensus-based document. The more obvious problems with such a diversion of volunteer labor:
    1. This kind of sourcing research should be done for, and in, our actual articles. Our articles on English grammar, punctuation, and style mostly are in only poor-to-fair shape. It's one thing to do some sourcing at WT:MOS to settle an actual, ongoing dispute claiming that part of MoS is "wrong". It's a very different matter – one that is likely to look like or mutate into WP:NOTHERE, WP:LAWYER, and WP:BUREAUCRACY for its own sake – to launch a whole new side project to do this in an ongoing, never-ending manner for every line-item in MoS. Does not compute! Whatever the intent of it, it's difficult to see how this would not turn into circular process-wonkery and provide a further avenue for editwarring. (Cf. the history of Wikipedia talk:Manual of Style/FAQ for strong evidence that this is exactly what the result would be. I can even firmly predict a dozen or so of what the disputes will be, what OR would be used to push PoVs about them, even specific paragraphs in some sources that would be misused.)
    2. WP consensus does not have to demonstrate to anyone that it derives from or agrees with any off-WP viewpoint. Like all of WP:POLICY, including guidelines, MoS is based on an internal WP:CONSENSUS about what is best for and works best on WP for our readers and, secondarily, our editorial pool. Consensus may change, but it does so through the same processes at this guideline as anywhere else on WP, not by wrongfully trying to "disprove" WP editorial consensus about WP-internal matters by resorting to the obvious fallacy of argument to authority. The only authority for how to best write Wikipedia is the collective experience of WP's own editorial pool, just as no third-party body can tell us what we consider to be sufficiently reliable sources (or insert any other guideline or policy of your choice). We do that, and only we can do that, even if some off-WP writings sometimes help inform our approach to such questions. Consensus is never magically trumped because someone outside of WP does things differently or recommends that they be done differently. We have a long, multifaceted policy about this at WP:NOT. It's hard to think of anything to even add to that page, it is so comprehensive in driving home the point that WP is its own unique thing with its own principles, standards, rationales, and goals.
    3. We would never consider any such thing for any other guideline or policy. Can you imagine someone saying "We need a WP:Identifying reliable sources/Supports page, citing other publications'/publishers' rules about how they go about determining what sources they consider reliable, otherwise our own internal rules that we come to, based on our judgement about our project, are invalid"?! No one would take that seriously for five seconds. That's why virtually no one appears to take this notion seriously here, either, no matter how many times it's been advanced.
    4. Improving the MOS:REGISTER will automatically make this "/Supports" page moot. The Register is arguably a legitimate side project, in that it catalogues consensus discussions better and thus protects MoS's stability better, in turn protecting the whole encyclopedia's content stability and consistency. Since the sourcing that some of us do on this talk page to resolve particular disputes here also gets archived here, improving the Register will automatically catalog and make it easier to find the source material, rendering the proposed page redundant. If anyone wants to add sources that did not happen to be raised in prior discussion yet, just add a "References" subsection under that subtopic on the Register page. There are no rules about how the Register page is structured and what material it may contain, after all. It would probably be genuinely helpful to copy-paste citations from discussions and add them to a cited-sources subsection at the bottom of each Register segment. Certainly a plausible task, compared to sourcing the entire MoS, much of which is based on internal consensus, not slavish adherence to some particular external work.
    5. Only a tiny number of editors have ever suggested "source the MoS", and they don't do the work. Thus, it likely would not actually happen anyway. The page would, rather, be a breeding ground for gaming the system, in POINTy, cherry-picking attempts at "winning" on some particular nit-picking peeve, at the expense of MoS's and WP's content stability.
    6. It is not possible to source all of MoS. Even aside from the fact that it's based on internal consensus, there are nearly zero style matters that MoS ever mentions that do not have sources in the off-WP world that directly contradict each other (otherwise MoS would not need to mention them; we need no rule that sentences do not end with the % character, or that people's names are not written backwards, or anything else that all style/grammar books agree on. The entire point of MoS is to identify places where there are conflicting rules, and to just pick one, so people stop arguing about them (or to explicitly allow MOS:ENGVAR variation where there is a strong "national" [real linguistics: dialectal] tie to a particular usage, like "colour" vs. "color"). In virtually every single case, contradictory sources are going to be found. The only practical use for ever sourcing anything in MoS is settling false claims about things like alleged strong national ties. Very few things in MoS raise such debates, so trying to source all of MoS is a total waste of time on multiple levels. BF: Anyone aiming to tilt at "MoS is OR" windmills in hopes of making ENGVAR "rule everything" need to consider carefully the fact that ENGVAR is the most OR thing in MoS.
Tl;dr version: This is not what we're here for. Given that the articles badly need work, the Register is incomplete and renders the proposed page redundant anyway, while the proposed one would likely just perpetuate the same perennial disputes, and is based on fallacious argument to authority, there would seem to be no point in launching it. It looks like WP:MFD fodder, especially if (as is likely) it would primarily be bent to the end of campaigning against various long-standing consensuses at MoS.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  07:52, 27 November 2015 (UTC)
SmC has just demonstrated something very important: Some people care about sources and other people care about discussions. I guess MOS:REGISTER and MOS:SUPPORT(s/etc.) could work as one page, but since there are two such different mindsets, maybe two pages are best. I was originally thinking that they'd be heavily cross-linked.
Even though you don't think the MOS needs sources, SmC, surely you don't think that proving that we're not making things up does any harm. Darkfrog24 (talk) 14:27, 27 November 2015 (UTC)
"surely you don't think that proving that we're not making things up does any harm." is a non sequitur. The only thing, and I'll echo SMC here, that we should care about here is whether or not there is consensus for a change. That's it. Bringing sources to bear in the context of those discussions can help us make a decision, but is not what we have PAG for. Having a separate page just for us to "add sources to" (a document that doesn't need them) places the wrong focus/understanding of utility on those sources rather than the decisions that we have come to consensus on. That's why the "MOSSOURCES" page is not useful and MOSREGISTER is. Also like SMC, I'll echo that there are likely a large number of mainspace pages that could use this proposed sourcing. Comma, full stop, and diacritic await your sourcing. --Izno (talk) 16:27, 27 November 2015 (UTC)
So if I were trying to convince you personally that you should do what the MoS says, I should steer you to MOS:REGISTER because you find discussions more convincing than sources. I'm not seeing how it's harmful to create a document that people who give more credence to sources would find convincing. (My assumption here is that "Here is why you should follow the MoS" is one of the purposes of both of these pages.)
Which suggests to me that MOS:SUPPORTS could be a useful resource to anyone seeking to improve those pages. I've used sources that I found in MoS discussions on such pages, and a whole page listing them would have been more convenient. Darkfrog24 (talk) 22:36, 27 November 2015 (UTC)
My 2c: If this page is kept, it should be titled "Sources" or "Support" or something other than "Supports", which does sound like a verb. But it would probably be sensible to combine it with MOS:REGISTER (list the sources in a thread here or wherever is appropriate, and then add a link to that thread to MOS:REGISTER). -sche (talk) 19:02, 27 November 2015 (UTC)
Each of the words "Source" and "Sources" and "Support" and "Supports" can be either a noun or a verb. The word "Support" sounds like an imperative verb. It is better to keep the new page separate from MOS:REGISTER to avoid one page becoming eventually too long. Also, separate pages make it easier for editors to search for either sources or discussions. However, the two pages can definitely be cross-linked.
Wavelength (talk) 00:09, 28 November 2015 (UTC)
Yes, but not all of them are going to read the same way when parsed for the first time.
A lot of this problem could be solved but adding another word to the article's title (though not necessarily to the shortcut): "Manual of Style Outside Support," "Manual of Style Third-party Support," "Manual Style Corroboration" (eh, too vague), "Manual of Style External Support," "Manual of Style RS Support." Darkfrog24 (talk) 01:27, 28 November 2015 (UTC)
Darkfrog24, I am willing to accept a page move to "Wikipedia:Manual of Style/External support" (still a subpage).
Wavelength (talk) 02:01, 28 November 2015 (UTC) and 02:46, 28 November 2015 (UTC)