Wikipedia talk:Manual of Style/Archive 151

This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 145

←

Archive 149

→

Adding a guideline on the position of the table of contents

I propose adding a guideline that states whether the table of contents should be floated left or right. The vast majority of articles have it on the left, while very few have it on the right. I think there's a couple of cases where having on the right works better than having it on the left, but there aren't very many.

Thus, in order to maintain consistency across Wikipedia and affirm long-standing practice, I suggest adding something along these lines to the end of the first paragraph of section 1.2 (Article titles, sections, and heading: Section organization): The table of contents should be floated left unless there is a compelling reason to have it on the right. "Compelling" might be too strong, I suppose. Perhaps "clear", "good", or something else along those lines? AmericanLemming (talk) 20:20, 6 January 2014 (UTC)

I don't see a problem with "compelling". A good, clear reason is a compelling one. But what reason could there be to move the ToC to the right? InedibleHulk (talk) 04:20, 7 January 2014 (UTC)

Well, I asked that question at list of municipalities in Manitoba, and I was told that it "avoid[s] the unnecessary white space that comes with the default left-aligned TOC format, and [allows] the entire TOC, or as much as possible, [to be] viewable upon arrival at the articles to avoid/minimizing scrolling down to view the TOC." AmericanLemming (talk) 04:27, 7 January 2014 (UTC)

Alright, I'm compelled. InedibleHulk (talk) 04:31, 7 January 2014 (UTC)

I don't really see any big deal with it, an essay I could see working as advice but a guideline seems a bit too much here. - Knowledgekid87 (talk) 04:38, 7 January 2014 (UTC)

Perhaps. However, I saw a TOC floated right and wondered whether or not the MoS says anything on it, which it currently doesn't. And I know for a fact that the vast majority of articles have it floated left, so I wasn't sure whether that was because of an unspoken rule or general practice or just the default setting of the software. A guideline could help clear things up. How about "The table of contents may be floated left or right, but general practice is to have it floated left (the default setting)"? AmericanLemming (talk) 04:48, 7 January 2014 (UTC)

Instruction Creep ... this is one of those things that editors can decide all on their own, without a "rule" (or even guidance) to tell them what to do. Blueboar (talk) 05:30, 7 January 2014 (UTC)

Perhaps. But the TOC is one of the most visible aspects of an article, and the vast majority of the time it is floated left. Thus, when I first saw a FL that had a TOC floated right, I wasn't sure if that was a mistake or if it was put their by choice. AmericanLemming (talk) 05:44, 7 January 2014 (UTC)

I wonder if there is awareness that a guideline (of sorts) already exists. Has Help:Section#Floating the TOC been reviewed? Cheers, Hwy43 (talk) 10:08, 7 January 2014 (UTC)

I took a look at that, but the top of the page says "This page explains the syntax of these elements." It's more of a page about what can be done with wiki markup than what should be done. AmericanLemming (talk) 19:22, 8 January 2014 (UTC)

This does sound to me like the sort of guideline that belongs in MOS. It's about a somewhat arbitrary choice of formatting, where consistency is important—the main concern of style manuals. Possible alternative to "a compelling reason": "a special reason". —Ben Kovitz (talk) 01:10, 8 January 2014 (UTC)

I don't seem to be hearing a clear consensus from other editors on whether or not a guideline should be added, and, if so, what that guideline should be. Perhaps I should start a RfC on the matter? AmericanLemming (talk) 19:25, 8 January 2014 (UTC)

I would support the addition of a guideline. I don't really know of a good reason to have the TOC on the right. To my mind that's non-intuitive. DonIago (talk) 19:43, 8 January 2014 (UTC)

The main page of the Manual of Style is already very large, and I prefer that it not contain a guideline about the position of the table of contents. A more convenient page for that guideline (if it is deemed to be important enough) is Wikipedia:Manual of Style/Layout, to which Wikipedia:Manual of Style#Section organization has a link.

—Wavelength (talk) 19:45, 8 January 2014 (UTC)

I would be fine with that. Seeing as the Layout subpage doesn't currently have a subsection under which my proposed guideline would fit, I think we would have to add one. Also, I think it would be worthwhile to add a sentence like "For guidelines on the position of the table of contents, see the Layout subpage" to the end of the first paragraph of section 1.2. That way it would be easy to find. AmericanLemming (talk) 19:54, 8 January 2014 (UTC)

I consider the link that is already there to be sufficient as a directional aid.

—Wavelength (talk) 20:46, 8 January 2014 (UTC)

Well, earlier in that paragraph it says "(see Wikipedia:Manual of Style/Lead section)". Is there any reason why we can't put "(see Wikipedia:Manual of Style/Layout#Table of contents)" at the end of that particular paragraph? AmericanLemming (talk) 21:00, 8 January 2014 (UTC)

It can be put in that same sentence and in the same italicized form, immediately after the wikified phrase "table of contents". I would accept that option, but still only reluctantly, because there are very many things that can be added to the already large page. Can you imagine what would happen if every addition were added as requested by an editor who considers his or her addition to be at least as important as the others?

—Wavelength (talk) 22:49, 8 January 2014 (UTC)

Hmm, I see your point. Maybe we should just add a subsection to the Layout subpage, then, and leave the main MoS page alone? AmericanLemming (talk) 01:36, 9 January 2014 (UTC)

That sounds perfect. —Ben Kovitz (talk) 07:27, 9 January 2014 (UTC)

(WP:THREAD) It might be all right to add it there (if it is deemed to be important enough), but I suggest that you open a discussion about it at Wikipedia talk:Manual of Style/Layout, with a (preferably permanent) link to this discussion, and find out whether there is consensus.

—Wavelength (talk) 03:56, 10 January 2014 (UTC)

I warmly agree with Blueboar's sensible comment above. I can't immediately think of many overwhelmingly powerful reasons for putting the ToC on the right, but I do remember having put it there and not out of mere capriciousness or the pleasure of getting up the nose of some wiki-cop. In List of photographers, for example, it's now on the left but would require less scrolling on a tablet if it were instead floated on the right, which is where I'd move it right now if it weren't for the minor risk that I'd then be accused here of "pointy" behavior.

Look, the ToC goes near the top, on the left or the right. If you don't see it in one place you'll see it in the other -- it's not as if (like a "featured article" logo) it's something you('d) have to search for. Let it go where editors want to put it. If they argue over it (a rare event), then let the side with the more convincing arguments win.

As it is, I see no convincing argument above for enforcing a left-hand ToC. The request starts in order to maintain consistency across Wikipedia and affirm long-standing practice with no argument for either consistency or conservatism, which seem touted as virtues in themselves. The other voices largely echo the praise for consistency without saying why consistency here is helpful to anyone. Perhaps oddest: It's about a somewhat arbitrary choice of formatting, where consistency is important—the main concern of style manuals. Is consistency important as witnessed by the existence of (inter alia) a University of Chicago Press hardback grimoire of consistency? No, not least because "Chicago" makes no fetish of consistency, which is not its main aim. It does give you pretty clear prescriptions for the use of, say, en dashes; but then these are likely to be used in quantity. The book -- an intelligent one, aside from the newly introduced claptrap on grammar and usage -- is shot through with alternatives and invitations to use one's intelligence and override general guidelines where it is beneficial to do so.

Additionally, what's likely to be a powerful reason why ToCs are largely on the left is that this is simply where they are automatically generated (which, incidentally, is fine with me). Plenty of editors preferring them on the right for some reason (or even for no particular reason, just as they're normally on the left for no particular conscious reason) may not be bothered to locate and digest the recipe for moving them or may not even know that they can be moved. -- Hoary (talk) 05:24, 11 January 2014 (UTC)

Actually, I think there's a good reason why the TOCs are on the left by default. Many articles have objects such as images and infoboxes that float on the right. Many of these continue below the introductory section and some are quite long (for example, see Margaret Thatcher). It makes sense not to force the reader to scroll past all of that to get to the TOC. Even if there is white space between the TOC and infobox, it's a good visual separator between the lede and the main content. —sroc 💬 07:47, 19 January 2014 (UTC)

The observation that started this thread was a floating TOC on the right, but stacked next to (left of) images/infoboxes. IMO, it would definitely be inappropriate to have a TOC floated to the right sitting underneath an infobox, and definitely inappropriate when it forces the TOC to appear beyond the lead to appears as if it is in one of the sections (in the case of Thatcher, it would be visually positioned in the second section). Hwy43 (talk) 08:29, 19 January 2014 (UTC)

As things stand

I'd like to thank everyone who has commented on my proposal, namely @InedibleHulk, @Knowledgekid87, @Blueboar, @Hwy43, @BenKovitz, @Doniago, @Wavelength, and @Hoary. I guess I proposed the addition thinking that it would be a fairly simple matter, but I think I didn't completely understand the issue at the time. You all have helped me to understand that the reason the TOC is on the left because that's the default setting, and that there's nothing wrong with having it on the right.

At this point in time I don't know if it's really necessary to add a guideline to the relevant subpage, and if I were to do so, I would first need to make surely I fully understand the wiki mark-up associated with floating the TOC left or right. (For example, I find it confusing that there is a difference between the default setting (having the TOC on the left) and floating the TOC left.) Again, I am grateful for your feedback, and I think I will study the issue more in depth before I make the decision to propose the addition of the guideline on the relevant subpage or not. AmericanLemming (talk) 23:48, 17 January 2014 (UTC)

Addendum: Actually, there is a guideline on the position of the TOC; it can be found on the subpage on the Lead section. It states "The table of contents (TOC) automatically appears on pages with more than three headings. Avoid floating the table of contents if possible, as it breaks the standard look of pages. If you must use a floated TOC, put it below the lead section in the wiki markup for consistency. Users of screen readers expect the table of contents to follow the introductory text; they will also miss any text placed between the TOC and the first heading." AmericanLemming (talk) 23:23, 18 January 2014 (UTC)

Trailing punctuation, again

What about punctuation marks in the following sentences, specifically the ones following "3DNow!", which is the name of a product:

In 1997, AMD introduced 3DNow!. The introduction of this technology...

Let's assume rephrasing isn't an option, as this is only an example for defining what to do in such cases. Would this be an option:

In 1997, AMD introduced "3DNow!". The introduction of this technology...

But again, what if a paragraph has multiple instances of such a case? Quoting "3DNow!" each time would be somehow... not so good?

Thoughts? — Dsimic (talk) 02:56, 20 January 2014 (UTC)

Just 3DNow!. is fine. If it has the exclamation as part of its name, then add other punctuation as if it's any other letter. (We are unlikely to be so excited about 3dNow! that we end a sentence with another exclamation mark.) If a brand name is slightly obnoxious, you won't make it less obnoxious by changing it. An article about a badly named product is always going to look like it's describing a badly named product, even over multiple mentions. The quotes would get to be too much over a full article, even if they seem like a short-term solution. __ E L A Q U E A T E 03:07, 20 January 2014 (UaTC)

And the 3DNow! page would be a complete disaster with quotes throughout. Don't worry though, I think most brands that start with exclamations eventually dump them in common use, as per Yahoo!. But if the exclamation is generally respected by sources, I'd keep it and just treat it as another letter while not calling any more attention to it then it already takes by itself. (Also see Factorials where a sentence that ended with x! would look like this sentence that ends with x!.) __ E L A Q U E A T E 03:28, 20 January 2014 (UTC)

It all makes sense, thank you for sharing thoughts! The whole thing was sparked by this edit, and "3DNow!" (which is old news) has been mentioned pretty much everywhere with the exclamation mark, to my knowledge. — Dsimic (talk) 03:51, 20 January 2014 (UTC)

Isn't this subject to Wikipedia:Manual of Style/Trademarks? It states:

Avoid using special characters that are not pronounced, are included purely for decoration, or simply substitute for English words (e.g., ♥ used for "love"). In the article about a trademark, it is acceptable to use decorative characters the first time the trademark appears, but thereafter, an alternative that follows the standard rules of punctuation should be used

So it should just be 3DNow after the first instance. —sroc 💬 07:00, 20 January 2014 (UTC)

Hm, but "3DNow!" is the name of an AMD's product/technology, not an "oh, it's cute" funky fish–like "♥" thingy. — Dsimic (talk) 12:42, 20 January 2014 (UTC)

I had another look, and I think sroc is correct that the MOS currently suggests stripping the exclamation point after the first instance, in the same style as the article on Yahoo! and similar to this editorial decision. The MOS notwithstanding, there could be a weak argument to ignore it in those places where it would help disambiguate between like-named technical products. (My punctuation advice remains the same, as I still think that wherever it maintains the exclamation point, as in the first mention, it never requires additional quotes and should have standard punctuation added as if the point was any other letter.) __ E L A Q U E A T E 13:06, 20 January 2014 (UTC)

That's fine with me and it makes sense; anyway, such names of products are coined that way just to catch more attention. Went ahead and edited the 3DNow! article, so repeated exclamation marks are now deleted. — Dsimic (talk) 13:19, 20 January 2014 (UTC)

Reducing template usage

MOS was mentioned in the first reply at User talk:Jimbo Wales/Archive 154#Reducing template usage (version of 19:15, 21 January 2014).
—Wavelength (talk) 19:31, 21 January 2014 (UTC)

National anthems: Quotation marks, italics, or nothing?

In the text of articles, should national anthems be in quotation marks, italicized, or plain text? Please discuss at WT:Manual of Style/Music if you care. — AjaxSmack 19:41, 21 January 2014 (UTC)

Clarifying the difference between a hyphen and an en dash

Recently there was some uncoordinated editing of the hyphen section, concerning en dashes. I reverted to the long-standing consensual version. But BenKowitz has chosen to forge ahead and reinstate his preferred version. So, for example, we have this:

"When the linked elements refer to independent entities, as in diode–transistor logic, use an en dash. Diode-transistor logic wrongly suggests that there is a special kind of transistor called a diode-transistor, rather than a kind of logic circuit involving both diodes and transistors. See En dashes, below."

That's no improvement on what we started with. The piped link is weird and reader-unfriendly. Piped links are no use if they obscure the linguistic point being made by the title that is linked to. And there's a wrong supposition abroad that the thing wrongly referred to must be a "diode" kind of transistor. Are you sure?? It could be an entity referred to either as a diode or as a transistor – or indeed, only ever properly as a "diode-transistor", like a "partner-amanuensis". (Or like a "bed-sitting room". It's not a "bed" kind of sitting, nor a "bed" kind of sitting room!) Nothing is gained by these obscurities and narrowings. Any variation from the pre-existing plain version needs closely argued justification and consensus.

This latest version, today, is still full of flaws:

But, when linked elements modify a noun in combination but do not modify each other, an en dash is required. For example, diode–transistor logic is a kind of logic circuit involving both diodes and transistors. With a hyphen, diode-transistor logic would instead wrongly suggest a special kind of transistor called a diode transistor. See En dashes, below.

The first "but" shouldn't be italicised; it should not have a comma after it; the comma should not be italicised anyway (see WP:ITAL, and conform to it in MOS itself); and there should not be a second "but" in the same sentence.
The first sentence is factually wrong. There are many cases in which the premodifier's elements don't modify each other, but an en dash is quite improper: "bitter-sweet love"; "go-go dancers"; "a mentor-coach relation with his younger siblings"; "a holier-than-thou attitude"; "the Wilkes-Barre area"; "those in-between comments"; "make-believe principles of punctuation".
And this is still wrong: "For example, 'diode-transistor logic' would instead wrongly suggest a special kind of transistor called a diode transistor." It might not suggest any kind of transistor: just some entity or quality referred to as "diode~transistor" (however spelt or punctuated). Compare "Austria-Hungary foreign policy", in which the entity or quality referred to is not a kind of Hungary.

The text I restored earlier today, which has now been quashed, was:

In some cases, like diode–transistor logic, the independent status of the linked elements requires an en dash instead of a hyphen. See En dashes below.

This expresses exactly how such en dashes are used. If anything is unclear about it, please show concisely and clearly what the problem is. It's not helpful to use MOS as a sandbox.

The discussion above was inconclusive and confined to a small group of editors in a section that was labelled misleadingly (not about article titles; not about "trailing punctuation").

Tony (talk) 11:15, 6 January 2014 (UTC)

In the flurry of edits and reverts (NOT a good idea in the MoS), it's not clear exactly where we are now. However, Tony's wording is, in my view, correct, and all that is needed. The use of the hyphenated "diode-transistor logic" as an example is misleading. The normal practice in English with noun phrases made up of multiple nouns is not to hyphenate. Interpretation often relies on semantics or knowledge of the derivation. [A classic example of the former is "uniform resource locator protocol problem". This can only be parsed by knowing the derivation: "((uniform (resource locator)) protocol) problem". There's another example here: "Foothills Boulevard Landfill gas emission reduction credits transfer contract authorization bylaw". Maybe this should have hyphens to help parsing, but it didn't in the wild.] My guess is that most readers would interpret "diode–transistor logic" and "diode-transistor logic" in exactly the same way; previous discussions here have shown that few readers notice the difference between hyphens and en-dashes. On the other hand, I think that both are different from "diode transistor logic". Peter coxhead (talk) 12:21, 6 January 2014 (UTC)

Indeed most people don't know the difference between a hyphen and an en dash. I myself went years without noticing that the names of theorems had an en dash between their namesakes. Still, most greengrocer's don't know how to use an apostrophe. We're Wikipedia, and we have a more scholarly approach than most material on the web. I wouldn't want us to lose that. —Ben Kovitz (talk) 14:11, 6 January 2014 (UTC)

Points well taken (or is that well-taken?) that the new version isn't the great increase in clarity that I'd hoped for. Reasons for messing with the old version: it's not clear, either, I think partly due to the opaque phrase "independent status". Virtues of the new version that I hope we can retain in some corrected form: an example of the meaning that would be implied by a hyphen (this gets the concept across better than anything), proximity to the hyphen rule it's an exception to, a different level of indentation than the rules saying when to use a hyphen, less-abstract wording of the principle.

Perhaps even "modifying" isn't clear even in this context, given your examples. In "go-go", "holier-than-thou", "in-between", and "make-believe", linked elements do get modified. Specifically, the meaning of any one element would be different outside the phrase: "go-go" means something other than just two gos in a row, "believe" is the object of "make" in "make-believe", etc. I'm not sure that "bitter–sweet" and "mentor–coach" aren't at least good candidates for an en dash: don't the elements have "independent status"? Point well taken about Wilkes-Barre and Austria-Hungary as attributive nouns; place names are an exception to the exception, covered in the section about en dashes; hence the "See below". —Ben Kovitz (talk) 14:11, 6 January 2014 (UTC)

Could we avoid the diode–transistor example completely? I fear it will only confuse most readers, who have little idea whether they're independent or variants of each other or what (and yes, are struggling to see any difference between a hyphen and an en-dash anyway). Sorry to say, I am struggling to come up with a better example - perhaps a distinction between man-horse and man–horse? NebY (talk) 13:31, 6 January 2014 (UTC)

I agree that the diode–transistor example is obscure. Let's have an example, just not that example. —Ben Kovitz (talk) 14:11, 6 January 2014 (UTC)

Early in my career I worked on a variant of DTL. The reasons for calling it DTL are debatable, so I don't think it makes a great example. Jc3s5h (talk) 13:50, 6 January 2014 (UTC)

Isn't it just because it's made with diodes and transistors, as opposed to resistors and transistors before or transistors and transistors after? In any case, I agree a more widely accessible example would be better. Nobody would want to the implication an eye hand, for example, so eye–hand coordination. And agree with Tony that it would be better to work this out with a clear proposal here than do a lot of bold thrashing of the MOS itself. My tweak wasn't meant to endorse it so much as to poke fun at the grammatical weaknesses of those hacking on it. Dicklyon (talk) 23:39, 6 January 2014 (UTC)

Well, nobody is perfect, and – as a non-native English speaker – I prefer when someone clearly points out my weaknesses so I can improve myself, instead of poking fun at them... Please don't get me wrong, but openness and clear expression of thoughts is always better. On the other hand, I do agree that proposing MOS changes first is the only way to go; this could be taken as a lesson for the future.

Regarding the substitution for "diode–transistor logic" example, how about "father–son bonding", "analytic–synthetic distinction", or "subject–object problem"? Those examples might be more understandable to a broader audience, though I'd still prefer the "diode–transistor logic" example. :) — Dsimic (talk) 03:41, 7 January 2014 (UTC)

To answer Dicklyon's question, DTL might be so-named because first the incoming logic signals affects the diodes, and slightly later, the operation of the transistor changes. So it is a sequence. But there really isn't any system for naming logic circuits; each one has its own history. Jc3s5h (talk) 17:59, 8 January 2014 (UTC)

Perhaps "parent-child bonding"? (To avoid any accusation of sexism.) What is needed is an example where the obvious full paraphrase makes clear that it's the relationship between equal status entities which is involved, rather than one noun qualifying the next (as in "resource locator protocol"). "Parent–child bonding" clearly means "bonding between parent and child", so if the hyphen/en-dash distinction is to be made in Wikipedia (which I personally oppose), then why an en-dash is used is transparent. Peter coxhead (talk) 08:35, 7 January 2014 (UTC)

I agree that "parent–child bonding" would be better. Probably someone else can jump in with further wording? — Dsimic (talk) 17:49, 8 January 2014 (UTC)

Just checking, any further thoughts here? Are we sticking with the "diode–transistor logic" example, or are we moving forward with "parent–child bonding"? — Dsimic (talk) 03:50, 10 January 2014 (UTC)

... so, are we sticking with diodes and transistors? — Dsimic (talk) 03:21, 22 January 2014 (UTC)

Hyphen or en dash for dual nationality?

MOS:ENDASH provides the following examples:

Wrong: Franco–British rivalry; "Franco" is a combining form, not independent; use a hyphen: Franco-British rivalry
France–Britain rivalry; French–British rivalry
an Italian–Swiss border crossing; but an Italian-Swiss newspaper for Italian-speaking Swiss
Japanese–American trade; but a family of Japanese-American traders (or a family of Japanese Americans)
the Uganda–Tanzania War; the Roman–Syrian War; the east–west runway; the Lincoln–Douglas debates; a carbon–carbon bond
diode–transistor logic; {{xt|the analog–digital

So, is it:

Alanis Nadine Morissette (born June 1, 1974) is a Canadian-American singer-songwriter... (current version) or
Alanis Nadine Morissette (born June 1, 1974) is a Canadian–American singer-songwriter... (my intended revision)?

I would expect an en dash, since Canada and the USA are two distinct countries, so this seems like the "union" in the Minneapolis–Saint Paul example, but MOS is not explicitly, abundantly clear on this amidst the contrasting examples. —sroc 💬 23:48, 21 January 2014 (UTC)

No, the examples cover blended nationalities. it needs a hyphen, as per Italian-Swiss newspaper. It's a combined quality example, as this is not a connection between a Canadian Alanis Morissette and an American Alanis Morissette.

an Italian–Swiss border crossing; but an Italian-Swiss newspaper for Italian-speaking Swiss
Japanese–American trade; but a family of Japanese-American traders (or a family of Japanese Americans) __ E L A Q U E A T E 00:17, 22 January 2014 (UTC)

For an individual, I would say an oblique (Canadian/American). A hyphen or dash suggests she is an American-born person of Canadian descent, not someone with dual nationality. -- Necrothesp (talk) 00:46, 22 January 2014 (UTC)

If you can use the word "between" when describing it, then it's an en dash. As in:

France–Britain rivalry; a rivalry between France and Britain; the Roman–Syrian War; a war between Rome and Syria;
the Lincoln–Douglas debates; a debate between Lincoln and Douglas; a carbon–carbon bond; a bond between two carbons

But if you can use a version of is when describing it, for things where the qualities are happening at the same time without seperateness, then it's a hyphen. As in:

an Italian-Swiss newspaper a newspaper that is Italian and Swiss, but not a newspaper between Italy and Switzerland
Japanese-American family a family that is Japanese and American, but not a family between Japan and America __ E L A Q U E A T E 00:55, 22 January 2014 (UTC)

Sorry, I see that now. Thanks, everyone. I was confused because I thought the an Italian-Swiss newspaper example used a hyphen because it referred to an Italian-language newspaper in Switzerland, whereas someone who is both Italian and Swiss might be treated differently. I overlooked the relevance of the a family of Japanese-American traders example which seems to be applicable here. Still, it does seem like it's not as clear as it could be for the busy editor who wants to quickly check, given that descriptors for dual nationalities and backgrounds (e.g., Canadian-American, African-American, Scottish-Australian, etc.) are presumably quite common. —sroc 💬 08:42, 22 January 2014 (UTC)

En dash folks, plus "during" vs "from/to"

There are discussions at User_talk:Robert4565#House_style and below on that page that I believe would benefit from attention from people who know more about the MOS than I do. The two current issues are these:

WP:ENDASH says not to combine an en-dash with prepositions, e.g., "It was built in 1914–1919". The editor has been changing these to statements like "It was built from 1914 to 1919" and is receiving complaints.
Is there a set difference between "during" and "from/to"? Is it obvious that "During 2001-2005 he filed lawsuits" means that he did it only occasionally, and "From 2001 to 2005 he filed lawsuits" means that he did it continuously during those six years—or the other way around?

There have been other assertions, like claims that you may not have commas after introductory phrases, but I think we're past that. I would appreciate it if replies could be posted over there. Thanks, WhatamIdoing (talk) 20:01, 21 January 2014 (UTC)

I don't think the construction "It was built in 1914–1919" is in the same category as the "between/and" and "from/to" constuctions that the MOS talks about. Here the "in" refers to the whole interval "1914–1919", as opposed to the problem cases where the proposition refers to only the first element of the dashed construction. I'd leave the en dash. Dicklyon (talk) 21:28, 21 January 2014 (UTC)

The dash is poor style because it's ambiguous as well as inconsistent. Does it mean 'from/to' or 'between/and'? — kwami (talk) 22:38, 21 January 2014 (UTC)

Or does it actually mean "in 1914 and 1919, and during some the intervening years, it didn't get built at all, because there was a war going on and they couldn't get any building materials"? WhatamIdoing (talk) 23:36, 22 January 2014 (UTC)

I replied over there, but part of the reason this mix of "in" and "–" is unfortunate is that it is impossible to know how to read the sentence. "It was built in 1914 to 1919"? I would hope nobody would write that. "It was built from 1914 to 1919"? That's not what the sentence says. "It was built in 1914 and 1919"? That's not what a en dash would ordinarily imply. Overall, I wholeheartedly agree that mixing dashes and prepositions is terrible. AgnosticAphid talk 01:04, 23 January 2014 (UTC)

Human height in the metric system

Just seeking a wider range of input from informed persons at Template_talk:Height#rfc_97AACED.--Gibson Flying V (talk) 08:04, 26 January 2014 (UTC)

MOS shortcuts nominated for deletion

I have nominated 11 (eleven!) MOS-related shortcuts for deletion at Wikipedia:Redirects for discussion/Log/2014 January 13. (one has already been speedy deleted) I would appreciate input from regulars at MOS. Terima kasih. John Vandenberg ^(chat) 03:48, 15 January 2014 (UTC)

I've nominated another three (3!) MOS-related shortcuts for deletion at Wikipedia:Redirects for discussion/Log/2014 January 15. Please join in; in one of these, there is a suggestion to retarget a MOS: shortcut. Sorry for the disruption caused. John Vandenberg ^(chat) 14:08, 15 January 2014 (UTC)

Two more MOS shortcuts have been nominated for discussion at Wikipedia:Redirects for discussion/Log/2014 January 25#MOS:FOLLOW. John Vandenberg ^(chat) 03:22, 27 January 2014 (UTC)

MOS:COMMA on dates and geographical references

MOS:COMMA currently states:

In geographical references that include multiple levels of subordinate divisions (e.g., city, state/province, country), a comma separates each element and follows the last element (except at the end of a sentence). Dates in month–day–year format also require a comma after the day and after the year (except at the end of a sentence). In both cases, the last element is treated as parenthetic.

Incorrect:	On November 24, 1971 Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon and was destined for Seattle, Washington.
Correct:	On November 24, 1971, Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon, and was destined for Seattle, Washington.

The previous RFC: Proposed amendment to MOS:COMMA regarding geographical references and dates was closed as follows:

This is a fairly clear-cut no consensus closure. The !votes are roughly 50/50, and although supporters argue that the proposed change would clarify matters, there are several dissenters who believe that it would unnecessarily make this section of the MoS unwieldy, and/or that it would make it even more confusing for editors. I would suggest that this proposal has a reasonable chance of succeeding if the proposers make an effort to address the opposers' concerns through further, informal discussion to identify wording that is mutually acceptable.

The RFC concerned changes to address two main issues: (1) The existing wording "overlooks that the final comma may be superseded by other punctuation"; (2) "There is also heated debate regarding whether the final comma is needed when the place name or date is used as an adjective". It seems that there was almost universal support for (1) and the vast majority of the opposition concerned (2).

I am also cognisant of recent discussion over revisions to MOS:DATEFORMAT, which now states:

In the MDY format a comma is required between day and year, and (unless the date is followed by some other punctuation) after the year as well.
- The weather on September 11, 2001, was clear and warm.
- Everyone remembers where they were on July 21, 1969—when Neil Armstrong first set foot on the Moon.

Hence, there is inconsistency between MOS:COMMA which states that the second comma is required "except at the end of a sentence" and MOS:DATEFORMAT which states that the second comma is required "unless the date is followed by some other punctuation".

With this in mind, I would like to revisit the (1) issue separately and propose an amendment to MOS:COMMA as follows:

In geographical references that include multiple levels of subordinate divisions (e.g., city, state/province, country), a comma separates each element and follows the last element (unless followed by other punctuation). Dates in month–day–year format also require a comma after the day and also after the year (unless followed by other punctuation). In both cases, the last element is treated as parenthetic.

Incorrect:	On November 24, 1971 Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon and was destined for Seattle, Washington.
Correct:	On November 24, 1971, Cooper hijacked a Boeing 727 aircraft that had taken off from Portland, Oregon, and was destined for Seattle, Washington.

This would unify with MOS:DATEFORMAT. The amendment is not entirely accurate, as there may be some forms of punctuation where the comma would still be required, e.g.:

If followed by a remark in parentheses, although there is some disagreement about this and such cases may be rare:
- The events of September 11, 2001 (known as 9/11), had a lasting impact on aviation security.

If followed by a footnote, which is not really part of the sentence per se:
- Jones was born on July 17, 1943,^{[Note 1]} in Smallville, Fictionland,^[4] at the height of the Smallville War.

However, it may not be worth debating such exceptions to explicitly state them in MOS. The amendment would certainly be more accurate than the current wording, which would technically require some apocryphal cases (e.g., The events of September 11, 2001, – known as 9/11 – had a lasting impact on aviation security). —sroc 💬 02:19, 18 January 2014 (UTC)

MOS:COMMA change discussion

When someone adds something funky to an article that I edit and cites the MOS, I give them the benefit of the doubt and check what they're talking about (and if there's a good explanation, I learn, assent, and move on). When you pushed these changes (boldly, which is fine), others are now crawling the entire encyclopedia implementing it—without consensus—which is why having a firm agreement on something is important before pushing to a high-use doc such as this. Anyway, I don't follow your logic for why this is needed on either this page or the other WP:DATEFORMAT discussion (which also appears to have no consensus). This is going to need a whole lot more dialogue before implementation other than a handful of editors on the WP:DATEFORMAT changes. I've never encountered this grammatical rule in my life, and I consider myself a fairly savvy copyeditor. czar ♔ 19:16, 25 January 2014 (UTC)

Upon further investigation, it looks like my issue is less with the MOS text change and more with the examples, which highlighted what the rule already was... a rule that was added last year. I'm looking into it and will revert myself if necessary. czar ♔ 21:30, 25 January 2014 (UTC)|}

In short, I found this goes a whole lot deeper and I don't have the time to probe longer, so I'm reverting myself and I'll leave the BRD to someone else. If anyone is new to this discussion (like me) and interested, the whole commas following years and states comes from a May 2013 discussion (Archive 139) (with relative consensus) that led to its inclusion. The aforementioned change adds an example that isn't ideal because each of the commas would be added for reasons unrelated to the rule. An example similar to

The April 1, 2014 party was held in Paris, Texas for 13 children.
The April 1, 2014, party was held in Paris, Texas, for 13 children. (modified per below, formerly Austin)

would clarify the written rule. A smaller amendment from a December 2013 RFC (Archive 150) ended in no consensus as editors opposed the rule as it's currently written. There is some more related pushback at dates and numbers talk. Seeing the recent changes only brought my attention to that May 2013 change. Addressing that would require an RFC, which I don't have time to propose.

czar ♔ 22:48, 25 January 2014 (UTC)

Thanks, Czar. To explain, I made three successive revisions to MOS:COMMA:

my first edit followed my proposal above exactly, which I assume had consensus since: (1) it had near-universal support in the December 2013 RfC; and (2) no one objected this time;
my second edit replaced the example, which others had criticised as being too verbose and starting with the preposition "On", substituting a more succinct version based on one which gained support at the previous RfC—although this was a bold revision, I didn't think anyone would necessarily mind;
my third edit revised the copy to explain that the exception for "unless followed by other punctuation" does not apply to such references that are immediately followed by parentheses, in which case the comma would normally follow the parentheses—another bold edit that I thought might survive given that no one had bothered to comment when I raised this here.

I made these as three separate changes in case someone thought to revert the third and/or second revisions (without wanting to disrupt the first) and reinvigorate the discussion.

In relation to the substituted example, note that I specifically avoided using places or dates as adjectives (such the date in as your Austin children's party example) as such use is contentious and generally to be avoided anyway. I also used a city in a state that is not the most prominent to ensure that the necessity of mentioning the state is clear (Paris, Texas, would have been a better example). (Your example also uses the past tense for a future event, by the way.)

To explain the rationale for the comma appearing after the parentheses, the year in MDY dates and the additional element in geographical references is treated as parenthetic: e.g., April 1, 2014 = April 1 (2014); Austin, Texas = Austin (Texas). Thus, when they are used mid-sentence, matching commas are required on either side: e.g., The April 1, 2014, party = The April 1 (2014) party; ...in Austin, Texas, for... = ...in Austin (Texas) for.... When a parenthetic remark set off by commas is immediately followed by a parenthetic remark set off by parentheses, the final comma comes after the closing parenthesis:

Burke and Wills, fed by local Aborigines (on beans, fish, and "ngardu") survived for a few months.

Burke and Wills, fed by local Aborigines (on beans, fish, and "ngardu"), survived for a few months. [The first example at MOS:COMMA.]

Billy, the son of Joe (who died after Billy was born) was immortalized in a song.

Billy, the son of Joe (who died after Billy was born), was immortalized in a song. [From WT:MOSNUM#Why the comma is needed after parentheses]

The events of September 11, 2001 (known as 9/11) had a lasting impact on aviation security.

The events of September 11, 2001 (known as 9/11), had a lasting impact on aviation security. [New example for MOS:COMMA]

As seldom as this situation may arise, I wouldn't want editors using the blanket exception for "other punctuation" to justify omitting the final comma. —sroc 💬 01:32, 26 January 2014 (UTC)

That last one doesn't make sense to me, with "2001 (known as 9/11)" in the middle of it. Dicklyon (talk) 01:44, 26 January 2014 (UTC)

Thanks for the explanation and ping, sroc. Dicklyon's comment is kind of what I'm getting at. I follow your logic and the idea of the parenthetical comma, but it was totally foreign for me until I looked it up a few hours ago. That third example is going to look foreign to a wide audience, which makes it doubt its efficacy as a rule. I don't have more to say than that as I don't have time to entertain a RFC. The continual question: Is the encyclopedia better for this rule? I had read through the first thread and you totally have consensus there, and the online grammatical references affirm you—it's just going to trip up a great many people.

czar ♔ 01:57, 26 January 2014 (UTC)

The new rule is broad and unthinking. This example shows that you need to consider what the parenthetical refers to. Here, both "2001" and "known as 9/11" apply to "September 11", so it should be:

The events of September 11, 2001, (known as 9/11) had a lasting impact on aviation security.

We could consider whether the comma after 2001 is still needed in this case. I think it helps still. But a comma after the parentheses makes no sense in this context. Dicklyon (talk) 02:07, 26 January 2014 (UTC)

@Dicklyon: re reverting my self-revert, realize that this is what you reinstated:

* In geographical references that include multiple levels of subordinate divisions (e.g., city, state/province, country), a comma separates each element and follows the last element (unless followed by other punctuation). Dates in month–day–year format also require a comma after the day and also after the year (unless followed by other punctuation). In both cases, the last element is treated as parenthetic.

This text has been here since May 2013 (my post above describes its history). This is to say that the existing text to which you just reverted actually supports sroc's 9/11 example. I, too, don't find it intuitive, even though it is grammatically correct ("In both cases, the last element is treated as parenthetic"). I'll bow out now. czar ♔ 02:51, 26 January 2014 (UTC)

That's not quite correct. That's the amended text from my first edit. Note that it says "unless followed by other punctuation" instead of "except at the end of a sentence". —sroc 💬 11:49, 26 January 2014 (UTC)

Yes, I agree the "rule" is still imperfect. But at least it doesn't include the odd example; the revert of sroc's third edit was primarily motivated by the bad example. Here, I would interprent the 2011 as not being followed by other punctuation, since the following parenthetical goes with the day, not with the year; it comes after the closing comma, not before. Yes, some interpretation is still needed to understand how to apply the "rule". Dicklyon (talk) 03:37, 26 January 2014 (UTC)

Just curious, does your interpretation depend on whether the parenthetical remark applies only to the year?

The events of September 11, 2001, (known as 9/11) had a lasting impact on aviation security.
The weather of September 11, 2001 (a particularly cold year), was cool and calm.

If so, what then if the remark refers to another period such as the season — longer than the specific date but shorter than the year — or if its relevance is more vague? —sroc 💬 11:49, 26 January 2014 (UTC)

Yes, those two cases are appropriately different. I don't pretend to have a general rule that you can use to always get the best answer. Dicklyon (talk) 21:19, 26 January 2014 (UTC)

I don't think there need be a distinction here. The first example here contradicts the other examples given above (Burke and Wills, fed by local Aborigines (on beans, fish, and "ngardu"), survived for a few months; Billy, the son of Joe (who died after Billy was born), was immortalized in a song). Having this distinction leads to questions like the one below where you have to enquire what Tony1 meant in order to determine placement of the comma. Do you know of any reliable sources that comment on this one way or the other? —sroc 💬 02:08, 27 January 2014 (UTC)

Simplifying this

A few edits to try to resolve the matters discussed above—now reverted, I think—have been linguisitically and categorically faulty, and miss opportunities to simplify the guidance. This might do the trick:

A comma must precede any addition such as city, state, or country in placenames; and except at the end of headings and some captions, a comma or stronger punctuation must follow (even when parentheses intervene): Newtown, Ohio, should not be confused with Newtown, New Zealand; but it sometimes is; They migrated from Cambridge, England (where they had married), to Cambridge, Massachusetts.
The same applies to the year in month–day–year format: April 2, 1998, was equally uneventful; The manuscript was completed on May 21, 1790 (with Haydn’s assistance), and immediately mislaid.

Tony (talk) 04:14, 26 January 2014 (UTC)

Note that the fundamental revision (to "unless followed by other punctuation") and the revised example remain; only my third edit has been reverted.

There's something to be said for separating these analogous cases. I recall someone objected to using dates as the subject of a sentence though, so the April example should perhaps be replaced. Good, innovative thinking, though. —sroc 💬 11:49, 26 January 2014 (UTC)

Tony, does "(with Haydn’s assistance)" here intentionally modify the year, not the "completed" clause? See the 9/11 examples above. Are we making sense there, or are you rejecting that distinction? Dicklyon (talk) 21:19, 26 January 2014 (UTC)

Dick, this has never been resolved when mdy format is used. Contrast this sentence, recast only to use a more universally approved dmy format:

The manuscript was completed on 21 May 1790 (with Haydn’s assistance) and immediately mislaid.

This may not be an optimal sentence, and rewriting is always to be considered. But there's no problem like the one with mdy. Here's a bare mdy version:

The manuscript was completed on May 21 1790 with Haydn’s assistance and immediately mislaid.

Now, if that sentence were included in a WP article, how would you punctuate it? Here's one option:

The manuscript was completed on May 21, 1790—with Haydn’s assistance—and immediately mislaid.

But that avoids the issue: sometimes we do want parentheses immediately after the year. How would they be managed exactly? What guideline for the disposition of parentheses and commas would work, to avoid all problems like the one you raised?

Another case:

The manuscript—completed on May 21, 1790 (with Haydn’s assistance), and immediately mislaid—turned up in Vienna after World War II.

How would that be reworked, by changing only punctuation?

We need a robust guideline that works well enough against the genuine difficulties with mdy. These difficulties have been raised on many talkpages, with no resolution. No perfect resolution is achievable. What would you suggest, as a guideline complete with examples to show the hard choices (not just the easy ones)? Tony (talk) 04:20, 27 January 2014 (UTC)

As I said above, I would not pretend to have a rule that gives the best result for all situations. But I would avoid making examples that look wrong. Wouldn't life be grand if we could just retire the MDY date format? Dicklyon (talk) 04:31, 27 January 2014 (UTC)

Oh, can we, pleeeeeaaaase?! It would resolve so much of this.

For the record, the latter sentence (and probably most others) could be re-punctuated simply by using commas:

The manuscript—completed on May 21, 1790, with Haydn’s assistance, and immediately mislaid—turned up in Vienna after World War II.

Or it might be better to say:

The manuscript—completed with Haydn’s assistance on May 21, 1790, and immediately mislaid—turned up in Vienna after World War II.

Of course, these example conveniently ignore the issue of what to do when parentheses do immediately follow the date. Such examples seem to be scarce, which perhaps explain why this argument does not come up and perhaps justifies ignoring it for the purposes of MOS, but it may be helpful if anyone comes across any such cases where this would be in issue. —sroc 💬 07:20, 27 January 2014 (UTC)

Of course such examples occur. Writing down a sentence someone has spoken, we might come up with this:

The motets were eventually completed—on May 21, 1680 (his 50th birthday), and September 30, 1682—and published.

How could the parentheses be avoided? We might ingeniously find a way; but it seems strange to rule out their natural use just because mdy is used. And this, for example, would be fatal:

The motets were eventually completed—on May 21, 1680, his 50th birthday, and September 30, 1682—and published.

Tony (talk) 10:25, 27 January 2014 (UTC)

I don't mean to say that the parentheses should be banished, just that the particular example you gave might have been better off without it, as might many other cases where parentheses could be used but may not be the best option. My point is that I haven't come across a particular example on Wikipedia that I can recall, so this may be a fizzer of an issue. Nonetheless, the question remains, how are we to reflect this on the MOS (if at all)? I made my suggestion and was reverted. I'm not keen on the wording "must precede any addition" and "a comma or stronger punctuation" in your suggestion (what does this mean?). Any other suggestions? —sroc 💬 13:34, 27 January 2014 (UTC)

since I was dragged into this...

Could somebody first please explain to czar that what you mainly seem to be discussing in this section ("parenthetical use of commas when brackets or other punctuation marks are involved" and "second-comma-or-no-second-comma in dates or places assuming an adjectival rôle") does not concern nor address the occasion for his getting involved here? In other words, do any of you – no matter where you stand on the other issues mentioned – consider controversial and argue against these two edits, reverted and dismissively labeled as "funky" by czar? Thanks. – ὁ οἶστρος (talk) 13:11, 26 January 2014 (UTC)

Your edits to insert commas after the year in MDY dates are most certainly accurate, in accordance with MOS:DATEFORMAT and MOS:COMMA (whether you refer to the current wording of these guidelines or the prevailing consensus from yesterday or a week or a month ago). I have restored your edit. Czar will need a good explanation to revert them again despite these guidelines: looking at reputable style guides and sources would be a start. —sroc 💬 13:40, 26 January 2014 (UTC)

Yikes! the condescension. I thought this was resolved—we already talked through it. That revert was before all this began, so of course it's fine to reinstate. I had planned to do it myself. I'm sorry for the confusion. And the diff cited above has long been struck, so I hope you won't continue to hold it against me.

czar ♔ 15:25, 26 January 2014 (UTC)

HTTPS vs HTTP (EL with identical content)

Maybe trivia, but a edit war erupted over the question about if one should use the HTTPS or HTTP protocol for use in a official EL link. In this particularly case, verifiability might be used to prove if one is "more official" than the other, but it really seems to boil down to a Wikipedia editing style question rather than a actually content question. The only sure way to know for sure which protocol is the official one is if the site has a HTTP link=canonical field (like described in stackoverflow on transition to SSL and regards to SEO, and that is commonly only done by websites for SEO concerns. For every other site, it will basically be a arbitrary decision, which is why I think a general guideline in the MOS could help. Belorn (talk) 14:36, 27 January 2014 (UTC)

@Belorn: A third choice is to use a protocol relative link (e.g. //thepiratebay.se), so that readers on https://en.wikipedia.org will go to https://thepiratebay.se while readers on http://en.wikipedia.org will go to http://thepiratebay.se. GoingBatty (talk) 18:53, 27 January 2014 (UTC)

Belorn, you have mentioned Talk:The Pirate Bay#https vs http in infobox, 2014. In that case, there was evidence on the web that both prefixes were in use and were functional. Some web sites will not accept the https prefix and may return a garbled answer. If you want to create a secure link to an external site and intend to use https you should at least verify that it works that way before saving the link on Wikipedia. There may be advantages to using the protocol relative form as recommended by User:GoingBatty. I've started removing 'https:' before saving all the full URLs I might need to use that refer to other Wikipedia pages. This issue has been discussed previously at WP:VPT. EdJohnston (talk) 19:32, 27 January 2014 (UTC)

Thank you for the tip of //thepiratebay.se. I thought it was only a wikipedia concept by reading [[1]]. I see now it work with any url and not just wikipedia and its sister projects. Thank you. It might be a good idea to reword that page, so the intro do not say "from a Wikimedia page to other Wikimedia page".

EdJohnston, thank you for the link. I did look through the archive for MOS, and had both trouble searching (https is not a good keyword), and then even manually I could not find it being discussed prior. The VP link however was very interesting. Does it mean that the discussion on how to implement the VP consensus is still in discussion, and that adding it to mos is for now a bit too early? Belorn (talk) 20:40, 27 January 2014 (UTC)

Until the technical discussion is over it would be premature to regulate it as a matter of style. There needs to be an advice page created on Wikipedia for protocol relative links. For example, Wikipedia:Protocol relative links. We may not know enough to write it yet. There would also have to be a plan for converting existing uses of http: in Wikipedia articles. This would only be done if consensus determines that a change is necessary. EdJohnston (talk) 20:58, 27 January 2014 (UTC)

Collapsibility

There is an active discussion taking place at Template talk:Track listing#Collapsibility, where the advice at MOS:COLLAPSE and its applicability to that template are being discussed. Please comment there if you have time. — Martin (MSGJ · talk) 16:14, 28 January 2014 (UTC)

Word usage

I'm about to start a conversation over at WT:FAC on putting together a word usage guide based on some subset of Wikipedia articles. I know there's interest at FAC ... I don't know if there's interest anywhere else, but I hope there is, and I don't have any preconceptions that the guide has to be based just on word usage in Featured Articles. Please join us. - Dank (push to talk) 14:36, 31 January 2014 (UTC)

See Wikipedia:Manual of Style/Words to watch.

—Wavelength (talk) 17:16, 31 January 2014 (UTC)

I helped write it. One of my goals, though I can't speak for anyone else, is not to tread on any territory already covered by our MOS pages; those pages have a greater claim to consensus on WP than anything that will come from a quick survey. - Dank (push to talk)

See Common Errors in English Usage.

—Wavelength (talk) 17:17, 31 January 2014 (UTC)

I'm a big fan of Paul Brians, and I've already made notes comparing and contrasting various usage guides. - Dank (push to talk) 18:22, 31 January 2014 (UTC)

Have you checked to see if Wiktionary has a feature like this? Would Wiktionary be a more suitable home for this? Jc3s5h (talk) 17:28, 31 January 2014 (UTC)

Quoting myself from WT:FAC: Dictionaries don't provide what we're looking for here, and lexicographers will be the first to tell you that. Dictionaries are designed to be permissive and to cover a wide "corpus" (sample text that determines how words actually get used). So, some of their definitions are widely rejected in style and usage guides, some are many years out of date, some don't apply to encyclopedic writing, etc. There's no one usage guide out there that is precisely what we want, but the advice I've seen from FAC copyeditors generally corresponds to advice given by respected usage guides. [Having said that, I'm not wedded to FAC ... any theoretical or actual text corpus will do, as long as it makes sense as a corpus.] - Dank (push to talk) 18:22, 31 January 2014 (UTC)

Wanted hyphens

User:Dicklyon brought up an AWB bug, where page 2-4 (meaning chapter 2, page 4) is replaced by pages 2–4 (meaning pages 2 through 4). A possible fixe is to manually prevent this by replacing the "-" with "{{hyphen}}". It's probably worth noting this somewhere, but I don't know of a good place to put it. — kwami (talk) 20:23, 25 January 2014 (UTC)

I think you'd normally use a different punctuation, e.g., 2:4, 2/4, or even "chapter 2, page 4" if you were trying to provide that information yourself. But a lot of technical documents use the hyphenated page numbering system that you describe. There actually is a "page 2-4", which you'll find in between "page 2-3" and "page 2-5". In that case, the correct page number probably is "2-4". WhatamIdoing (talk) 02:37, 26 January 2014 (UTC)

If it is deemed to be important enough to be mentioned in the main page of the Manual of Style, then I suggest that it be mentioned in the sub-section Wikipedia:Manual of Style#Hyphens, between "Non-breaking" and "Soft hyphens". Alternatively, if the HTML code ‑ is as effective as "{{hyphen}}", then a brief comment about usage can be added to the guideline "Non-breaking".

—Wavelength (talk) 02:52, 26 January 2014 (UTC)

If this is in a citation like {{cite journal}}, the best thing to do is to put this page number in |at=, like this: "|at=p. 2-4". Maybe even add a comment to the effect that "this is a single page numbered '2-4', not pages 2–4" so that human editors won't change it. – Jonesey95 (talk) 04:52, 26 January 2014 (UTC)

The trouble is that the editors adding the citations are not going to be aware of such hacks. So editors running semi-automatic tools over such things need to exercise some care, and try to decide whether it's a page or a page range, and fix it appropriately. What has happened in many case (or a few that I've noticed at least) is that the tools (or their users) are too automatic, and they assume it's a page range and thereby change a correct reference to a wrong reference. Dicklyon (talk) 05:11, 26 January 2014 (UTC)

I'm thinking specifically of manual corrections of bots. Reverting won't do any good, as it will just get 'corrected' by the next bot, so we need s.t. the bots won't recognize. — kwami (talk) 06:29, 26 January 2014 (UTC)

It doesn't really fit here. What about at MOS:TEXT? — kwami (talk) 06:34, 26 January 2014 (UTC)

It would seem to me that for clarity we should try to avoid indicating "chapter 2, page 4" by "2-4", no matter what a lot of technical documents do, because it is too easily misread. --JorisvS (talk) 08:06, 27 January 2014 (UTC)

Of course I agree with JorisvS that ambiguities should generally be avoided. But this issue arises in part from the unstated requirement that a reference to a page number must use precisely the same numbering scheme and typographic format as used by the referred page numbers. The solutions suggested above use various mechanisms to 'hide' the hyphen. As noted, these are only useful to editors who are already aware of this automatic 'correction' issue with Ch-Pg numbering. It should be apparent that a more generally applicable solution would require that tools such as automatic input parsing and zealous-page-range-bots be stopped from making this false correction. Such efforts will be either impractical or incomplete, due to the potentially unending set of alternative tools and new hyphen-bots. However, I suggest that a few of the primary auto-culprits, such as {{cite book}} be addressed and "corrected".

I am proposing to modify {{cite book}}, which is probably the primary offender of unnoticed invalid corrections.

Documentation for {{cite book}} states that a hyphen is only auto-corrected to an en dash within |pages=. They are not replaced within the |page= or |at= parameters. It even mentions this problem, giving 3-1—3-15 as a valid page range of this type, and states that the |at= parameter must be used in this case. This is an unfortunate (and unnecessary) requirement, because an important piece of information is lost when using the |at= parameter (whether the parameter represents one page or several pages). For example, we can easily determine the editor's intended meaning of 3-15 thus: As a singular page |page=3-15 must be in Ch-Pg format. But in the plural, |pages=3-15 must be a range of normal page numbers.

The Ch-Pg numbering scheme is not mixed with normal page numbers within the same book (more accurately, the two numbering schemes are not mixed within the main body of text, such as all the chapters - the front matter may use lower case roman numerals). This observation leads to a considerably improved algorithm for parsing {{cite book}} |pages=. Here are some examples. The last example shows its limitation.

User Input		Parsed or Corrected	Comment
\|pages=3-15	→	\|pages=3—15	A range of 13 pages
\|pages=3-1-3-15	→	\|pages=3-1—3-15	The first 15 pages of chapter 3
\|pages=3-15, 17-12	→	\|pages=3-15, 17-12	Just two pages: 17-12 cannot be a range, so the book and all its pages must use the Ch-Pg numbering scheme
\|pages=3-15, 17-19	→	AMBIGUOUS	This could be either (a) just two pages (like the previous example), or (b) a range of 13 pages plus a range of 3 more pages

Note: I used em dashes rather than en dashes to emphasize that they're not hyphens.

With thanks, from ChrisJBenson (talk) 14:22, 27 January 2014 (UTC)

It may be useful to remember at this point that the goal of citations is to help a reader locate the original source material. If a reader sees an ambiguous set of page numbers like "3-5, 17-19" and locates the original source book or journal, that reader will see that "pages three through five and pages seventeen through nineteen" do not exist and the ambiguity will be resolved; the reader will see that the pages are numbered 3-1, 3-2, 3-3, 3-4, 3-5, etc. and locate page 3-5 with little trouble. Even if the hyphens are changed to en dashes by a bot, the reader will still be able to find these ambiguous page numbers. – Jonesey95 (talk) 15:20, 27 January 2014 (UTC)

I don't see how that's useful. Are you saying that it's OK for automated editing to insert errors, because readers with access to the referenced source will be able to determine that they are errors, and easily correct for them? Seems like a poor direction to want to go. Dicklyon (talk) 22:04, 27 January 2014 (UTC)

See Template:Not a typo, which I discovered within the past few days.

—Wavelength (talk) 03:49, 5 February 2014 (UTC)

Template:Not a typo can be mentioned at Wikipedia:Manual of Style#Miscellaneous.

—Wavelength (talk) 22:33, 5 February 2014 (UTC)

En dashes rather than hyphens for both prefixed and suffixed adjective phrases. (2)

In reference to this edit:

Previous discussions:

Can people say if they agree with this or not, and close it one way or other? --Enric Naval (talk) 18:48, 13 January 2014 (UTC)

My opinion is the same as documented in the above-linked edit message and Talk discussion. User:DocWatson42, this topic may still interest you. Thank you, Enric, for gathering those links. startswithj (talk) 19:20, 13 January 2014 (UTC)

It does, but at this time I have nothing new to add, other than my continuing support for the proposed change for the reasons I have previously stated.—DocWatson42 (talk) 06:34, 14 January 2014 (UTC)

I'm supporting en dashes instead of hyphens in both cases, what means while applying prefixes or suffixes to compounds including a space.

To me, "credit card-sized" is quite bad, when compared to "credit card–sized". I've read all of the linked threads (and even more threads linked further from there), and something like "New York-style" makes sense as it's clear that "New" and "York" are modified together; on the other hand, "credit card-sized" sounds more like a "card-sized" credit, so "credit card–sized" would be really a much better form – in the same way as it fits well within "ex–prime minister Thatcher". Or should we write it as "credit-card-sized" instead? Sorry-but-that-would-be-quite-awkward. :)

@Tony1: it's back to you – let's discuss, please. :) — Dsimic (talk) 20:12, 13 January 2014 (UTC)

The en dash in these circumstances is mainly a US phenomenon, first seen I believe in the 1930s. Most Americans don't use it, even though Chicago Manual of Style recommends it. I quite like it once I got used to it, although I was put off when I first saw it. I'd be happy with optional use, but both credit-card-sized, credit card-sized, and credit card sized seem unsatisfactory to me. Tony (talk) 00:04, 14 January 2014 (UTC)

Totally agreed that some time is required for getting used to it, but it's quite neat and makes things more clear once you're accustomed to it. Also, if we already have MOS specifying en dashes for such prefixes, having hyphens specified for suffixes makes little sense – if you agree. — Dsimic (talk) 00:19, 14 January 2014 (UTC)

But we need to go back to the decisive RFC on dashes in 2011, which made only prefixes optional as a compromise. I'll be back later. Tony (talk) 00:47, 14 January 2014 (UTC)

Hm, these dashes seem to be quite a trouble... However, in that case adding suffixes into the optional use guideline seems to be the way to go. Please let me know where is that 2011 RFC, so I can grasp all of the details from that previous discussion. — Dsimic (talk) 00:56, 14 January 2014 (UTC)

More or less at Wikipedia talk:Manual of Style/dash drafting#In compounds whose elements themselves contain hyphens or spaces. But 5b talks about the prefix case and the suffix case has already been left behind at that point, I think. Dicklyon (talk) 06:45, 14 January 2014 (UTC)

I would like to see a list of example applications of the current guideline versus the proposed alternatives before making an opinion based only on pure logic. Dicklyon (talk) 05:02, 14 January 2014 (UTC)

Current versus proposed: "Academy Award-winning" versus "Academy Award–winning"; "World War II-era" versus "World War II–era".—DocWatson42 (talk) 12:17, 14 January 2014 (UTC)

Another example (somewhat common on Wikipedia) is "Linux kernel-based" (current) versus "Linux kernel–based" (proposed). — Dsimic (talk) 02:36, 16 January 2014 (UTC)

Why would credit-card-sized be unsatisfactory? What is its disadvantage? --JorisvS (talk) 10:45, 14 January 2014 (UTC)

Hyphenating all words is not applicable in all cases, such as the ones I just posted above ("Academy-Award-winning": just—no), whereas the proposed change would (I believe) cover all cases.—DocWatson42 (talk) 12:17, 14 January 2014 (UTC)

Okay, but what about cases where it is, like credit-card-sized? --JorisvS (talk) 12:45, 14 January 2014 (UTC)

I would probably write it as a triple-monster, but I try to avoid where rewording is possible. Tony (talk) 09:22, 15 January 2014 (UTC)

Let's have a look at the above mentioned "Linux kernel–based" example; I'm always trying to write that as "based on (the) Linux kernel", but that isn't always possible because sometimes it makes sentences overcomplicated etc., while "Linux kernel-based" sounds more like "Linux" being "kernel-based" (especially for readers unfamiliar with the whole "Linux vs. Linux kernel vs. GNU/Linux" debate). On the other hand, it simply can't be written as "Linux-kernel-based".

Regarding cases where it's actually possible to use double-hyphen monsters, :) those could be some kind of exceptions to the proposed guideline change. Well, there are always some exceptions and there's nothing wrong with them, but some kind of unifying should be applied – especially as we already have a MOS guideline specifying en dashes for such prefixes to compounds including a space. Not having that for such suffixes, too, is pretty much a guideline inconsistency. — Dsimic (talk) 02:36, 16 January 2014 (UTC)

This is an odd inconsistency in the MOS. It's intentional, though: Some people insisted on making suffixes an exception because they "look bad" when dashed. But recently I've noticed that The Week reliably uses en dashes in such situations. The Week is targeted to a broad audience, much as WP is, is designed to be as accessible as possible, and publishes in both the US and UK. (I've seen the US edition.) I haven't been collecting examples, though. — kwami (talk) 18:11, 16 January 2014 (UTC)

Skimming the latest I have, no. 13:650 (2013-12-31), for all en dashes: Tea Party–related [groups] (p 4), 1.8 million–year-old skull (p 9), post–Hurricane Katrina nightmare (p 11), the city's first New England–style seafood shack (p 13), the "Paul Simon–esque" Afro rhythms (p 14), $85 billion–a-month bond-buying program (p 22), the Fort Worth–based airline (p 23), Nobel Prize–winning Irish poet, Nobel Prize–winning author, & Tony Award–winning stage and film actress (p 24), the National Geographic–supported expedition (p 31).

I see two patterns here: Proper names, which do not take hyphens, and compounded digit-word numbers, which I myself would probably just double hyphenate. Clearly The Week would dash "Academy Award–winning" and "World War II–era". I don't know about "Linux kernel–based", though. This is equivalent to credit card–sized, which came from a style manual, and of The Week examples, closest to $85 billion–a-month: X-Y Z becomes X–Y Z when X is more than one word, like "credit card" or "$85 billion", which would mean that the capitalization of "Academy Award–winning" is a cue but not the reason for the dash. — kwami (talk) 18:54, 16 January 2014 (UTC)

Thank you for providing such good examples! Such suffixes might "look bad" when dashed, but hyphenating them takes away a good chunk of clarity. To me, everything points into a need for rectifying this MOS inconsistency. — Dsimic (talk) 19:32, 16 January 2014 (UTC)

IMO they don't look bad at all: They make the text easier to parse, and therefore more enjoyable to read. I think "looks bad" is just a way of saying they're not accustomed to it. — kwami (talk) 19:43, 16 January 2014 (UTC)

Totally agreed. It takes some time for becoming accustomed to en dashes in such language forms, but they provide multiple benefits later. — Dsimic (talk) 20:07, 16 January 2014 (UTC)

(edit conflict) Dec 27 issue: to then–presidential candidate John Kerry (p 6), (but ex-medical student, p 11), the San Francisco–based singer and songwriter (p 27), a Cordon Blue–caliber cook (p 34), the New York City–based retailer (p 35), a credit card–size device (p 36).

Can't believe I actually found the "credit card" example! It also seems that dashed suffixes are more common than dashed prefixes. As for ex-medical student, I'm guessing it could be an oversight or, like the phrase high school student so commonly seen without a hyphen, judged to be so obvious that no dab was needed.

I want to do a comparison of the UK and Aus editions, but it might take me a while to find some. — kwami (talk) 19:37, 16 January 2014 (UTC)

Maybe "ex-medical student" (with a hyphen) actually isn't a mistake; could it mean that he/she is still a student, but no longer a medical student? Just thinking aloud about a potential edge case. — Dsimic (talk) 20:07, 16 January 2014 (UTC)

No, it's not that. The context is a Christmas truce on the front lines in WWII, and the clause is, one German, an ex-medical student, examined the wounded American. Perhaps you only think to use a dash when there's a problem with parsing, and this causes no problem. — kwami (talk) 20:24, 16 January 2014 (UTC)

Now it's clear, thanks for providing some context. — Dsimic (talk) 21:06, 16 January 2014 (UTC)

Well, I have found oversights. One below.

Dec 20 issue: The New York City–based Satanic Temple (p 5) (but: natural-gas-based fertilizers, p 9), ex–NSA contractor Edward Snowden (p 18), a Bronx, N.Y.–born con man (p 22), this Zach Galifianakis–produced series (p 24), pro–Volcker Rule (p 34).

But $85 billion-per-month bond-buying program (p 34), presumably an oversight, given that the exact phrase was repeated with a dash in the end-of-the-year wrap-up above. There's also the expected pork-and-dashi-based broth (p 25): no spaced words, so no dash.

Hyphen examples: "the cheaper-silicone implants" means industrial-grade rather than medical-grade silicone, as opposed to silicone implants being cheaper than other fillers. "The then-20-year-old actor" – sometimes there are questions about hyphenating ages. — kwami (talk) 20:15, 16 January 2014 (UTC)

Nov 29: The Tea Party–backed congressman (p 6), Clinton-era, Wall Street–friendly centrism (p 14), New York City–based firm / FlyKly bikes (2 ex, p 18). — kwami (talk) 22:06, 16 January 2014 (UTC)

No, sorry, not a joke, but a careful analysis of 2-word, versus 3-word, prefix phrases in adjectives, with examples to show use of multiple hyphens to denote 3-word format. -Wikid77 13:41, 17 January 2014 (UTC)

Denote 3-word adjectives by colon versus middot or hyphens: Rather than overuse the same en dash character, just assign the middot, non-spaced ("·") to connect 2-word prefix adjectives, but a colon connection for 3-word adjectives. Compare:

"Academy Award·winning" – for 2-word prefix
"Golden Globe Award:winning" – for 3-word prefix "Golden Globe Award"
"1984 Academy Award:winning" – as the 1984 version, 3 words
"900 Academy Award·winning" – as 900 people who are Academy Award winners
"Police Academy Award:winning" – 3 words for a Police Academy Award

However, the colon/middot seems too confusing, so I think just use the normal extra hyphens as with:

"The group included 900 Academy Award-winning actors" versus:
"The group included a 1984-Academy-Award-winning actor"
"A police Academy-Award-winning film could be a Police-Academy-Award-winning choice".

Well, that certainly settles the matter. The use of multiple hyphens is much more precise, so just extend the extra hyphens into all words, as people typically do when a whole phrase acts as the adjective. There's no need for colon/middots or en dash separators, just use the hyphens as in normal text. However, perhaps the middot could be used for 3-word possessive form: "Police Academy Award·s" to show it is owned by the Police Academy Award (3 words); but wait, in a case like that, just use a compound-noun form: "the Police-Academy-Award's ceremony is next month". Fine, all problems solved by just using hyphens. Excellent. Thanks to everyone for clarifying how all these issues can be solved by just using extra hyphens. -Wikid77 (talk) 11:29, 16 January 2014 (UTC)

No way! I want to see some brand new punctuation marks invented, teached in classes and used world-wide just for this purpose. :) — Dsimic (talk) 19:32, 16 January 2014 (UTC)

{{collapse bottom}} –See "collapse top". -Wikid77 13:41, 17 January 2014 (UTC)

Example of 4-part prefix phrase: Using the typical hyphenated form for adjective phrases, then a 4-part prefix would appear as: "The pre-Academy-Award-ceremony photos included red-carpet arrivals". When an adjective phrase includes multiple terms then simply join all words with hyphens in a logical manner, but also recommend to avoid using long phrases as adjectives. -Wikid77 13:41, 17 January 2014 (UTC)
- Yeah, and-we-could-also-include-hyphens-everywhere, as they're-so-ubiquitous. No, wait, middots·are·saving·space. :) — Dsimic (talk) 14:13, 17 January 2014 (UTC)
  - I usually try to get around triple and quadruple compounds by rewording. The photos of the pre-Academy-Award ceremony, or the photos of the pre–Academy Award ceremony. Tony (talk) 15:08, 17 January 2014 (UTC)
    - My vote goes to "photos of the pre–Academy Award ceremony". It's as clear as it can be. — Dsimic (talk) 18:17, 17 January 2014 (UTC)
      - Well, that phrase is even more-misleading, as the concept is not a "pre–Academy Award ceremony" but rather a pre–Academy-Award-ceremony timeframe, when guests arrived at the red carpet. The use of multiple hyphens can easily separate the almost 1,000, or "995 Academy-Award-winning people" from those few who were 1995-Academy-Award-winning actors (actors who won in 1995, among the 995 people). It might take a little while to get used to the multiple hyphens, but it is easy to see why they have been used for decades to clearly denote the exact meaning. -Wikid77 19:45, 17 January 2014 (UTC)
        Hm, but isn't "Academy Award", as an actual name, supposed not to be hyphenated at all? I agree that using multiple hyphens brings certain advantages, allowing much more condensed expressions, but quite frankly I'd say that such constructions would be actually confusing a broader Wikipedia audience. It would be much better to avoid multiple dashes by rewording that wherever possible. For example, I do agree that "pre-Academy-Award-ceremony" (as happening before the "pre–Academy Award ceremony") goes one step further into past than "pre–Academy Award ceremony" (which happens before the "Academy Awards")—but quite frankly again, that's confusing. Writing that as "during time before the pre–Academy Award ceremony", or "while guests were arriving at the red carpet", for example, would (or should?) be understandable to everyone. — Dsimic (talk) 22:54, 17 January 2014 (UTC)
      - Either way, we don't hyphenate proper names, so anything with "Academy-Award" in it is not an option. — kwami (talk) 18:45, 17 January 2014 (UTC)

With that in mind, it would be the best to collapse the (now unfolded) joke above. — Dsimic (talk) 18:57, 17 January 2014 (UTC)

It might seem funny to explore alternate punctuation styles, but it is not a joke. -Wikid77 (talk) 19:45, 17 January 2014 (UTC)

I'm more than open for (radically) new things, but can we expect to see such changes going into written English just because we're discussing them here? :) As another alternative notation, we could have additional colons designating how far an en dash goes into spaced compounds, for example "pre–::Academy Award ceremony", or "pre–:Academy Award ceremony". Multiple middots alone would be another option, so for example "pre··Academy Award ceremony", or "pre·Academy Award ceremony" etc.

But then again, aren't we going a bit too far away? :) — Dsimic (talk) 22:54, 17 January 2014 (UTC)

In many of these cases it's better to reword. But not always, and if we're forced to reword just to avoid a formatting argument, then the prose suffers. There are cases where neither a hyphen nor the lack of a hyphen is appropriate, and rewording is not a good solution, and we should have some idea how to address them. — kwami (talk) 20:45, 17 January 2014 (UTC)

Agreed; for the beginning, we should try to see what to do with en dashes and suffixes to compounds using spaces, while removing one MOS inconsistency at the same time. — Dsimic (talk) 22:54, 17 January 2014 (UTC)

Quickly reading the above comments, it seems to me that we have no clear consensus on why a discrepancy between prefixes and suffixes should exist, as well as moderate consensus that en dashes for compounded compound modifiers would be technically preferable to hyphens. Would others agree? startswithj (talk) 18:20, 20 January 2014 (UTC)

You're right that there's no clear consensus, although there are no strong opponents either. Having that in mind, I'd say going WP:BOLD and changing MOS so en dashes are also suggested for suffixed adjective phrases, would be the way to go. Agreed? — Dsimic (talk) 21:46, 20 January 2014 (UTC)

I think that if you see a consensus you should write it up as a proposed MOS wording change and take a quick survey to see if it is widely supported. I'm OK with some of the proposed examples like "Academy Award-winning" versus "Academy Award–winning"; "World War II-era" versus "World War II–era", "Linux kernel-based" (current) versus "Linux kernel–based"; but not credit card–sized because credit-card-sized is more clear and common for such cases. It is not OK to put hyphens into proper names, which is mainly why the others need the en dash (I'm not sure if saying Linux-kernel-based would be allowed or disallowed; I'm open to either way on that one). Dicklyon (talk) 23:14, 20 January 2014 (UTC)

Totally agreed, will write a new wording proposal and put it up for voting. Regarding "Linux kernel–based", it simply sounds (and looks) wrong to write it as "Linux-kernel-based". — Dsimic (talk) 05:30, 21 January 2014 (UTC)

Will that new proposal appear here or somewhere else? Thank you, startswithj (talk) 18:18, 21 January 2014 (UTC)

I'd say that this section (with the proposal in its separate subsection) would be a good place. I'll try to write it in the next hour or so... @Startswithj: Would you prefer to write the proposal yourself, based on your edit which (re)started the whole thing? — Dsimic (talk) 03:29, 22 January 2014 (UTC)

Proposed change (1)

Split off from the section above, for improved readability.

Isn't it simply a proposal to change (within Wikipedia:Manual_of_Style#En_dashes:_other_uses) this:

Instead of a hyphen, when applying a prefix (but not a suffix) to a compound that includes a space

ex–prime minister Thatcher; pre–World War II aircraft; but not credit card–sized

To this:

Instead of a hyphen, when applying a prefix or a suffix to a compound that includes a space

ex–prime minister Thatcher; pre–World War II aircraft; credit card–sized; Pulitzer Prize–winning

startswithj (talk) 03:46, 22 January 2014 (UTC)

Support: That's correct, though some editors prefer "credit-card-sized" instead of "credit card–sized", what I actually intended to have covered within the proposal; let's leave that to proposal comments from these editors, if you agree. Also, I've moved these two posts into a subsection, for improved readability. — Dsimic (talk) 03:57, 22 January 2014 (UTC)

Oppose if the proposal includes "credit card–sized". Dicklyon (talk) 03:59, 22 January 2014 (UTC)
Support as worded (though I am not wholly opposed to hyphenation).—DocWatson42 (talk) 18:35, 22 January 2014 (UTC)
Oppose – after reading Tony's exposition, and reviewing my own copy of CMOS, I think I agree that there are few or no situations where this is going to matter, unless it's written so broady that it gets applied to "credit card–size", which would be a mistake. I think the current compromise, which at least has a few years of CMOS aligned with it if nothing else, is a good place to leave it. Dicklyon (talk) 03:50, 26 January 2014 (UTC)

Proposed change (2)

Split off from the section above, for improved readability.

Are we all Ok to have this in the end?

Instead of a hyphen, when applying a prefix or a suffix to a compound that includes a space

ex–prime minister Thatcher; pre–World War II aircraft; Pulitzer Prize–winning; New York City–based

Please vote. — Dsimic (talk) 01:36, 25 January 2014 (UTC)

Support.—DocWatson42 (talk) 05:44, 25 January 2014 (UTC)
Oppose—To avoid cluttering this section, I've sequestered my reasoning below into a level 4 subsection. I hope no one minds. Tony (talk) 12:49, 25 January 2014 (UTC)
Support—For consistency with current prefix rule, per recommendation of outside style guides (e.g. Chicago Manual, American Heritage, and Webster's), for prevention of confusion (e.g. "York City-based that is new"), and per explanations at Wikipedia article En Dash. startswithj (talk) 23:16, 25 January 2014 (UTC)

In highly contrived cases or, rarely, in natural occurrences, confusions will arise from any punctuation rule (involving commas, parentheses, and even full stops). It should not be the basis for a completely new use of a punctuation mark. The en dash has enough well-founded uses on Wikipedia already. The WPian context is not the same as the CMOS context; and CMOS decisions about en dashes are sometimes not well-argued and consistent: please see my post below. Tony (talk) 02:22, 26 January 2014 (UTC)

C'mon, how can this be "a completely new use of a punctuation mark"? — Dsimic (talk | contribs) 03:42, 26 January 2014 (UTC)

Agreed; "completely new" is hyperbolic. And when does a punctuation mark have "enough" uses? startswithj (talk) 19:33, 26 January 2014 (UTC)

Comment. Agreed that this style (dash > en dash > attributive compounds, open compound cases) is not at all new (in the context of "under the sun"). I suspect Tony meant (?) that it would be new in the context of Wikipedia:Manual of Style (that is, that WP:MOS had never specifically called for it before). In American editing, this style is generally followed (and internalized as "correct"); one can get thrown off of projects for failing to follow it (either the project style guide will specify it or it will cascade from rules such as "CMOS style unless otherwise specified" or "AMA style unless otherwise specified"). I did not even realize that (apparently) it is a meme more popular in American English than in Commonwealth English until I read the discussion on this page. But I would not agree that it then follows that WP:ENGVAR's principle of "however the page got established, it can stay that way" applies to this instance, because this is not a "normal" AmE/BrE difference—it is more specifically a copyedited-vs-not-copyedited difference. Even in AmE, 99% of people will not follow this style when they write something; but if that something is edited, then the editing is expected to apply this style to it. Thus, most Americans who developed content in a WP article would not use this style, but another American can "rightfully" come along behind that and apply this style (because the idea of "however the page got established, it can stay that way" does not apply to the copyedited-vs-not-copyedited difference). Nonetheless, if this style is "American-leaning", then WP:MOS should respect those users of English around the globe who don't want to use it (even though I think they ought to anyway, because it is preferable just on the merit of its logic, even ignoring geographic origins; as another example, I prefer logical punctuation order (that is, British style) to traditional American punctuation order in my own writing, although I must enforce the latter when on the clock). Thus I think my current judgment is that WP:MOS should not require this style (dash > en dash > attributive compounds, open compound cases) but also should not treat it as a mere WP:ENGVAR thing, either. It should say that this style is encouraged. Quercus solaris (talk) 00:49, 27 January 2014 (UTC)

Hm, sorry but this isn't new to the MOS, as it already states that en dashes should be used between prefixes and open compounds; the whole thing is about suggesting that for suffixes as well. Am I missing something? By the way, isn't it absurd that the MOS and Dash article are saying different things about "Pulitzer Prize–winning novel", for example? — Dsimic (talk | contribs) 01:30, 27 January 2014 (UTC)

The "completely new use" that we speak of is the CMOS one, which has only cautious acceptance in CMOS16 and cautious partial acceptance in WP:MOS. It is completely new in recent decades, and an invention of CMOS that they only much later discovered the consequences of ("Chuck Berry–style lyrics") and are at a loss to analyse rationally. There is no reason for our MOS to adopt the problems that CMOS has brought upon itself. Tony (talk) 03:21, 27 January 2014 (UTC)

Sorry, but I really don't get it why would that be such a trouble, and why should WP:MOS be strictly bound to what's available in CMOS? Ok, CMOS sounds to be hedged and inconclusive regarding such suffixes, but can't we think outside the box in some areas? If some people weren't thinking in different ways, there would be no Wikipedia at all, or at least not in its current shape and size. — Dsimic (talk | contribs) 04:01, 27 January 2014 (UTC)

Of course Wikipedia shouldn't be bound to CMOS (the source of this novel practice with the en dash). But you want us to go further than CMOS, and wholeheartedly endorse what even they are embarrassed by? Tony (talk) 04:48, 27 January 2014 (UTC)

CMOS is embarrassed by that? Why should they be? Also, why then The Week uses such punctuation, according to numerous examples provided earlier by Kwamikagami? — Dsimic (talk | contribs) 05:18, 27 January 2014 (UTC)

Comment – Treat prefixes and suffixes the same. But I oppose requiring an endash instead of a hyphen, generally. Instead, make a requirement that usage within an individual article be consistent. Bwrs (talk) 09:48, 6 February 2014 (UTC)

Reasons for my oppose (proposed change 2)

The change runs against what was ironed out as a coherent suite of uses for the en dash, with wide and extensive community consultation in 2011. Since I don't have previous editions of CMOS at hand (nor by online subscription), I asked Noetica to look them up in relation to this proposal. I found the history interesting: Using an en dash with exactly the same meaning as a hyphen, but in special contexts, is almost exclusively a US invention – and a recent one at that. It first turned up as an option in CMOS12 (1969), where the examples (at 5.91) are all with prefixes ("post–Civil War period") or have two more or less equal elements combined ("New York–London flight"). There's no mention of suffixes, or examples of such a use, though prefixes are specifically mentioned in Table 6.1, with examples there and at 5.91.

CMOS13 (1982) reproduces the advice (at 5.94), and makes specific mention of prefixes (but not of suffixes, and no examples for them) at its Table 6.1. Same in CMOS14 (1993) where 5.117 gives virtually the same advice, with nothing on suffixes; and in Table 6.1: "When a prefix is added to an open compound, the hyphen becomes an en dash" (p. 230). Even CMOS15 (2003) sticks to that line (see 6.85, with no suffixes). It dispenses with the table, replacing it with section 7.90 where the ruling is still focused on prefixes: "pre–Vietnam War (before an open compound, an en dash is used; see 7.83)" (p. 307). [But in fact 7.83 says nothing about en dashes <sigh>.]

Only with CMOS16 (2010, current edition) do we get two suffix examples (at 6.80). The first three examples in that section: "the post–World War II years" "Chuck Berry–style lyrics" and "country music–influenced". Introducing these ("it should be used sparingly, and only when a more elegant solution is unavailable"), CMOS makes an extraordinary claim: "As the first two examples illustrate, the distinction is most helpful with proper compounds, whose limits are established within the larger context by capitalization." But this is nonsensical. If the capitals already mark "World War II" and "Chuck Berry" as recognised units—that is, we must never put a hyphen in them—why is an en dash called for when these units enter into compounds? Because of its capitals, hyphenated "Chuck Berry-style lyrics" is instantly understood—without resort to this Chicago novelty that some US writers embrace as an 11th commandment (and the rest of the world gets by brilliantly without, and does not understand).

CMOS16 continues: "The relationship in the third example, though clear enough, depends to some small extent on an en dash that many readers will perceive as a hyphen connecting music and influenced." Um ... so why bother to use that en dash? And what's unacceptable about "country-music-influenced" anyway? Why is "country music" not hyphenatable? It isn't what CMOS16 delights in calling a "proper compound"; so a two-hyphen solution is fine, one presumes ...

In sum, this use of an en dash is accepted on WP as a concession to US regionalism, just as it's hedged and mixed up in CMOS16. Chicago's weird decision for this use of the en dash fits with its avoidance of other uses that are common in the rest of the anglophone world (such as "US–Canada relations": CMOS wants "US-Canada relations" though it wants "United States–Canada relations", which all starts to get messy compared with our simpler guideline). To transplant that decision into Wikipedian style, where the background decisions are not CMOS-bound, would be inappropriate for our worldwide readership.

Tony (talk) 12:49, 25 January 2014 (UTC)

This whole thing turns out to be so exhausting, and what really sucks is that probably only 0.5% of people actually cares about it. However, thank you for such a detailed explanation; to me, CMOS sounds to be hedged and inconclusive whether en dashes are or aren't to be used with such suffixes. On the other hand, having Wikipedia guidelines specifying en dashes for prefixes only looks to me more like a compromise made for the sake of convenience, rather than like something making true sense. — Dsimic (talk | contribs) 19:23, 25 January 2014 (UTC)

Yup... most of us don't worry about whether you are supposed to use a hyphen, an en dash, an em dash, or what ever. Just pick which ever one you like... it does not matter which, because sooner or later someone will come along and "correct" you (no matter which one you picked). Then, someone else will come along and "correct" that... followed by yet another 3 month debate about which is "correct" here on the MOS talk page. Watching the 5% who really care about dashes and hyphens argue incessantly about them is one of the great spectator sports in Wikipedia. It has provided the 95% who don't really care with years of amusement and laughter. Come to think of it... that's true for most of the MOS. Blueboar (talk) 19:54, 25 January 2014 (UTC)

Yeah, and "screw all variants of dashes and use hyphens everywhere" has crossed my mind many times. Though, doing that would be contrary to the whole concept of human evolution, which (I guess?) supposes constant additions to the human knowledge. That simplification would be similar to what "Web 2.0" ("Web 3.0", or whatever) is doing – in the end, Web pages are going to have only one big blue "Do!" button, stretched all over 4096×2304 screens of course. Wouldn't that be plain stupid? — Dsimic (talk | contribs) 20:31, 25 January 2014 (UTC)

Comment: If this is just a Usonianism, then that's a good reason for opposing it. Probably 90% of cases are capitalized anyway, and that's enough of a cue that the two words form a unit that an en dash isn't necessary. So it's only actually disambiguating w things like country music–influenced or credit card–sized. So how do British style guides handle things like that? Do they just hyphenate all the way through, country-music-influenced and credit-card-sized? That looks terrible to me, but maybe just because I'm more used to Usonian than to British media. — kwami (talk) 07:38, 27 January 2014 (UTC)

Comment: 1) We don't hyphenate more than two words in a row in English, I suspect, because it looks contrived—as if the writer is trying to convey an emotional-or-cultural-reference-sort-of-meaning-kind-of-effect. 2) I wouldn't argue that in most cases meaning can't be discerned if an en dash rather than a hyphen used in compound adjectival phrases, but I would argue that meaning can't be discerned faster for more readers (even if only a split second faster). 3) It appears the Chicago Manual added further detail on a rule that was missing; they didn't change a rule. startswithj (talk) 19:11, 29 January 2014 (UTC)

- Well, regarding "(1) We don't hyphenate more than two words in a row in English": that can be qualified as "we seldom hyphenate more than two words in a row in English". The string-of-hyphens style is established in a few permanent compounds, whose hyphens stand in both attributive and predicative position, such as fill-in-the-blank format or the test format was fill-in-the-blank, and, as AMA styles them (8.3.1 in the 10th ed), up-to-date vaccinations and the vaccinations were up-to-date; or state-of-the-art equipment and equipment that was state-of-the-art. There's also an attributive-position-only class, such as 'very low-birth-weight children but children of very low birth weight and low-molecular-weight heparin but heparin of low molecular weight. Occasionally, temporary compounds such as private-sector-dependent funding arise, too, which can take hyphens in attributive position, but googling the internet corpus shows that people often don't bother with hyphenating them. Quercus solaris (talk) 01:45, 30 January 2014 (UTC)
  - Apologies, yes, I did mean "we seldom" rather than "we don't." startswithj (talk) 02:30, 30 January 2014 (UTC)
  - And of course, we do already allow multi-hyphenated phrases just above the en dash section, in the hyphens section, though we recommend keeping them minimal. This proposal wouldn't change that. startswithj (talk) 02:41, 30 January 2014 (UTC)

Picture caption at Elevator - discussion needs more input.

An edit war has broken out at Elevator (an article written in American English) over whether the lead image, which depicts two of these devices in London that are clearly labelled "lifts" (the British English term for an elevator) should be captioned "lifts" or "elevators". I have semi-protected the article, but the discussion needs more input. Please comment at Talk:Elevator#semi-protection. Thryduulf (talk) 23:27, 5 February 2014 (UTC)

That is one solution... the other is to swap in images of "elevators" (labeled as such) from the US. Blueboar (talk) 12:57, 7 February 2014 (UTC)

Is this use of categories normal?

Is it normal/accepted to do this? Or is there a better approach? Splash - tk 00:14, 6 February 2014 (UTC)

Looks reasonable to me, because (1) the article itself is about a system of categories, and (2) each of the linked articles is about a sub-category within that system. Bwrs (talk) 09:57, 6 February 2014 (UTC)

There is nothing wrong with the approach ... but I would avoid the word "Categories" in a level 2 section header (it causes confusion with WP:Categorization). I would suggest that a better word to use in the section-header would be "Classifications" ... that word would better tie the section header to the article title. Blueboar (talk) 15:35, 6 February 2014 (UTC)

There is a bit of a problem - the article is about a specific system, so:

The reader might reasonably assume that the list of classifications in Standard Occupational Classification System#Classifications is taken from SOC. A quick check of [2] suggests that it is, but (if it is) it would probably be useful to include a line of text (with a ref) at the top of Standard Occupational Classification System#Classifications, saying so explicitly.
The SOC document does not appear to define enumerable "classifications", but rather a hierarchical structure. Standard Occupational Classification System#Classifications would more accurately named as "SOC major groups" - because that appears to be what they are.
Given items 1, 2 above, the reader might reasonably expect that clicking one of the listed links named for a specific SOC major group would lead to a list of occupations or SOC minor groups that matched SOC. However that is unlikely to be the case, because Wikipedia's categories are not required to follow SOC. I suggest that it would be better to list the major groups (in an appropriately named section, with an intro sentence, per 2 above), but not make them links to categories. (Links to articles would be OK, eg the existing Legal occupations, and change the link from "Computer and mathematical occupation" to Computer professional instead of Category:Computer occupations.) Mitch Ames (talk) 13:46, 7 February 2014 (UTC)

I would tend to agree with Mitch. --Izno (talk) 14:52, 7 February 2014 (UTC)

Danger of formatting with templates with can change the MOS without discussion

We have an edit war going on at WP:NUM concerning the formatting of a template that's now being used directly in the MOS. This is dangerous: The MOS should be formatted manually. Otherwise changes in a formatting template will change the MOS without any discussion or consensus on the MOS. (The template did not conform to the MOS, though it claimed to; now that it's embedded in the MOS, the MOS conforms to the template, which has things backwards.) Thought I should mention it here for those of you who aren't watching that page. — kwami (talk) 00:23, 13 February 2014 (UTC)

What are you talking about? Maybe a link to some discussion please? Dicklyon (talk) 05:16, 13 February 2014 (UTC)

Ah, you probably meant MOS:NUM, not WP:NUM. I still don't understand what's going on there. Dicklyon (talk) 06:15, 13 February 2014 (UTC)

Collapsible section headings

any input is welcome at Talk:Qumran#Collapsible_bibliography concerning the collapsible section headings presented here. thank you. Frietjes (talk) 16:36, 13 February 2014 (UTC)

To me, it doesn't look so good, sorry. Standard {{Collapse top}} + {{Collapse bottom}} looks much better if collapsibility is the primary goal, as the collapsible area is clearly marked. — Dsimic (talk | contribs) 18:50, 13 February 2014 (UTC)

Wording about punctuation and ref tags

In Wikipedia:REFPUNC#Punctuation_and_footnotes, the wording

The ref tags should immediately follow the text to which the footnote applies, including any punctuation

does not parse easily and can thus lead to unintended interpretation. May I suggest that addressing the relative positioning of the punctuation and the ref tags be moved to a separate sentence? —Quondum 17:34, 16 February 2014 (UTC)

This text has always been clear to me. Can you propose a version that is clearer to you? – Jonesey95 (talk) 21:38, 16 February 2014 (UTC)

If the intent is that punctuation should precede the ref tags, irrespective of whether ref applies only to the preceding phrase, I'd suggest

The ref tags should immediately follow the text to which the footnote applies, with no intervening space. Any punctuation (see exceptions below) must precede the ref tags.

The ambiguity seems to arise from the phrase "to which the footnote applies" feeling as though it binds to "the text" rather than to "the text ... including any punctuation". —Quondum 22:22, 16 February 2014 (UTC)

WP:Content forking

As noted here on my talk page, the talk page at WP:Content forking is highly inactive. Therefore, I am seeking outside input from here for the following matter: Wikipedia talk:Content forking#Obligatory thread - making POVFORK less anti-AGF. Flyer22 (talk) 17:05, 18 February 2014 (UTC)

Edit reversions over "seasons"

There have been several edits recently at WP:MOS over whether seasons in the northern and southern hemispheres are "opposite" or just "different". FWIW, I'd say they're "reversed". - Dank (push to talk) 13:10, 2 February 2014 (UTC)

Reversed is just fine, Dank. Opposite is fine too. Different is unnecessarily vague, don't people think? Tony (talk) 13:37, 2 February 2014 (UTC)

(ec) I don't see any good reason to object to the original wording, "opposite", which is used in the article Season. I suggest to restore that word. -- Michael Bednarek (talk) 13:41, 2 February 2014 (UTC)

Hmmm... why are we limiting this to northern and southern hemispheres. What about parts of the world where "winter, spring, summer, fall" have no real meaning... where the "seasons" actually are completely different (Dry season, Monsoon season, etc.).

I would suggest rewriting it as: Avoid ambiguous references to seasons (seasons are different in different parts of the world).

That said... I'm not sure why the MOS has to mention this at all. Another option is to simply cut the entire bullet point. Blueboar (talk) 14:01, 2 February 2014 (UTC)

MOS mentions this because editors do tend to occasionally refer to the seasons to indicate when something happened or will happen. ("The new movie is scheduled for release in spring 2014.") This can be ambiguous, or at least confusing, because "spring" happens at a different time of year in different parts of the world. Mitch Ames (talk) 09:12, 5 February 2014 (UTC)

I certainly don't think they're "reversed", which to me would mean they progress in the order winter, fall, summer, spring. Unfortunately "opposite" could also mean that (reversed order), though that probably wouldn't have occurred to me if "reversed" hadn't been mentioned. --Trovatore (talk) 05:12, 4 February 2014 (UTC)

"Opposite" is more an adjective. "Reversed" is a more a verb. Two things concurrently across from another are opposite, one thing which has changed its position or orientation to the other side of an axis has reversed. More appropriate for pole shifts than hemispheres. InedibleHulk (talk) 05:52, 4 February 2014 (UTC)

According to Tamil calendar#Seasons (version of 14:37, 31 January 2014), "[t]he Tamil year, in keeping with the old Indic calendar, is divided into six seasons, each of which lasts two months": spring, summer, monsoon, autumn, winter, and prevernal.

According to Bengali calendar#Seasons (version of 15:54, 2 February 2014), "[t]he Bengali calendar consists of 6 seasons, with each season comprising two months": summer, monsoon season, autumn, dry season, winter, and spring.

The guideline can say:

Avoid ambiguous references to seasons (generally, seasons are opposite in the southern and northern hemispheres; some cultures have six seasons instead of four).

—Wavelength (talk) 16:03, 2 February 2014 (UTC)

Perhaps it might be more all-encompassing to just say, "some cultures have different numbers of seasons" or something like that? AgnosticAphid talk 05:29, 3 February 2014 (UTC)

The main thing is that it should be clear about what it's advising, and then explaining why it should be avoided. What about something more like:

Avoid ambiguous references to seasons, such as the Spring of 1995. Seasons occur at different times in the southern and northern hemispheres, and have different definitions by region.
__ E L A Q U E A T E 13:31, 3 February 2014 (UTC)
- Great! One suggestion and one thought: it should be in red instead of green, and do we want to say "better to specify the month", or something, also? Perhaps the latter is obvious. AgnosticAphid talk 15:48, 3 February 2014 (UTC)
  - I think it might go overboard to work out scenarios of what is suggested instead. In context, the solution to avoid ambiguity could be the month, or "the first half" or a set of specific dates, etc. Better to raise awareness of the problem. I'm neutral on different/opposite, I think my suggestion says about the same thing either way, and I accidentally capitalized spring.
Avoid ambiguous references to seasons, such as the spring of 1995. Seasons occur at opposite times in the southern and northern hemispheres, and have different definitions by region.
__ E L A Q U E A T E 16:50, 3 February 2014 (UTC)
But according to MOS you'd write spring 1995—no point in building in multiple breaches of the guideline where only one point is at issue here. I was happy with the one Mitch reverted to (from my change, actually). Tony (talk) 04:55, 4 February 2014 (UTC)
Thank-you. Per my edit summary, I think we should keep it short and simple. For the purpose of this guideline it doesn't matter how or why or where they are different, merely that they are. If someone wants to know the details, they can follow the link to the seasons article. Mitch Ames (talk) 09:21, 5 February 2014 (UTC)

We should also consider that as well as WP:Manual of Style#Months and seasons (the direct subject of this talk page discussion) this guideline is mentioned in WP:Manual of Style/Dates and numbers#Other periods - shortcut WP:SEASON - the latter having more detail. Perhaps WP:Manual of Style#Months and seasons should have a hatnote:

To further complicate matters, as well as WP:SEASON, we have MOS:SEASONS (but not MOS:SEASON), which is part of MOS:CAPS, and covers only capitalisation. WP:SEASONS exists, but is a WikiProject subpage about football seasons. Mitch Ames (talk) 09:43, 5 February 2014 (UTC)

Without having seen this, I created MOS:SEASON to mirror WP:SEASON. Then I realised the similar MOS:SEASONS exists although it appears to be unused so I have removed the shortcut from the target section. I've explained further at [[Talk:MOS:SEASONS#Confusion with WP:SEASON and MOS:SEASON]]. Hopefully this will help to avoid confusion (but not with WP:SEASONS—not sure what to do with that). —sroc 💬 07:17, 16 February 2014 (UTC)

I also took the liberty of adding hatnotes to the various sections of Wikipedia:Manual of Style#Dates and time to point to the relevant sections of MOSNUM for further information, unintentionally applying Mitch Ames' suggestion. —sroc 💬 07:22, 16 February 2014 (UTC)

Actually, I have the idea to deprecate the WP:SEASONS shortcut, too: see Wikipedia talk:WikiProject Football/Season article task force#Deprecation of WP:SEASONS. —sroc 💬 22:31, 18 February 2014 (UTC)

Inside or outside punctuation

I am having trouble understanding what is desired, without any examples of what not to do in red, it is almost as if anything is acceptable. Furthermore, the use of pronouns is not clear. For instance, Biblically speaking, in regards to those who went, is "they" used as a gender neutral substitute for she/he? Or does it signify that other than Martha, more than one person came? - Dirtclustit (talk) 04:51, 15 February 2014 (UTC)

It's hard to tell which questions you're asking, but you've hit on at least two issues that we at the MoS tend to fight about (a lot), the use of punctuation with quotation marks, and the use of the singular they.

For the "inside or outside of quotation marks" issue, what this MoS does not want you to do is use American-style punctuation. It requires only British at all times. A more in-depth explanation of how to use British style (also called "logical style") correctly is given in the article quotation mark. If you want a simple rule of thumb, if the period or comma applies to or belongs to the quoted material, then put it inside. If not, put it outside. (Generally, British English does for periods and commas what all forms of English do for question marks.)

To the best of my memory, the reason the MoS doesn't list a rule for the singular they is because we couldn't agree on one. When it comes to the singular they, use your own judgment. So long as each article is internally consistent, it will look neat enough.

So does this answer your question? Also, were you asking a question about what to do on Wikipedia or were you suggesting improvements to the MoS?Darkfrog24 (talk) 06:02, 15 February 2014 (UTC)

It answers my suggestion, which was poorly written indirectly, thank you for being gentle with a reminder as to where questions about what to do on Wikipedia belong. I guess I should just spit out my suggestion concisely and directly; that while I understand both sides to any standardization debate, if everyone involved took a minute to remember that lettered languages, specifically written forms, have the potential to be as precise as numbered languages when complete standards are implemented. As the only reason mathematics appears to be so precise, is because nobody argues about the boundaries of estimations and rounding to whole numbers. When the boundaries are not as clear as numbering things like people, we still agree on definite boundaries so that numbers such as 1.5 enter an equation as 2, or 1.534 enters an equation as 1.5 or any number less than or greater than the amount of significant figures possible so that the language has clarity described as crystal. So agreed upon are the boundaries of estimation for numbers that it could be said that one cannot tell a lie when speaking with numbers. The reason that lettered languages cannot be as clear has a lot to do with disputed standards. And I will read your link to quotation marks although after a second read through I've come to realize the British rules for depositing punctuation here; under the inside or outside explanation is more than clear.- Dirtclustit (talk) 00:03, 16 February 2014 (UTC)

That might be true if you were writing for computers, but Wikipedia is written for humans. The human brain does not process language the same way it processes numbers. You can untanrsderd tihs cnat you? Logically, you shouldn't be able to, but you can.

This is a classic hypothesis-versus-evidence issue. Many proponents of our current ban on American punctuation argue that British style is more logical and that American punctuation surely confuses people. However, no one has ever cited any case of American punctuation confusing any readers or causing any misquotations or problems in subsequent editing, not even one, even though this rule has low compliance. So sure, if British punctuation appeals to your sense of logic, there's nothing wrong with having a personal preference, but there's no evidence that either system actually performs better than the other under any kind of real-world or Wikipedia conditions. The situation doesn't merit banning a punctuation system that is flat-out required in one of the major varieties of English in which Wikipedia is written.

And if you ask me, questions about what to do on Wikipedia belong right here, at least if you want an answer. Darkfrog24 (talk) 04:33, 18 February 2014 (UTC)

Actually, you misrepresent the arguments for logical quotation style (WP:LQ). But we don't need to get into that again. Dicklyon (talk) 04:54, 18 February 2014 (UTC)

I misrepresent nothing, Dicklyon. Look at what I said: 1. People have argued that American style causes "ambiguity and errors in subsequent editing." They have. Sometimes those words are even in the MoS itself. 2. No one has ever shown a case of that actually happening on Wikipedia. They haven't. You were there for a lot of that. There's a belief that makes sense to a lot of people but no evidence to show that this belief is correct. A lot of the time, people think that if an idea is beautiful or appealing or simple, then it must also be true. So far, we haven't seen this to be the case with the ban of American punctuation. Darkfrog24 (talk) 14:23, 18 February 2014 (UTC)

The proponents of LQ are not promoting "American style" as you should be well aware; they are promoting "logical quotations": not including something inside that is not part of the quoted material. "American style" is your spin. And the common preference for logical quotes is not based on any claim of "errors in subsequent editing" as far as I can recall; you keep asking about "subsequent editing" but nobody is arguing that as far as I can see; did I miss it because these are your words and someone else said it differently? Please point out something I can search for in the archive. Dicklyon (talk) 00:03, 19 February 2014 (UTC)

I think you meant to say "British," but yes, "British" is actually the name of the style currently required by the MoS, though "logical" can also be found in plenty of sources. British style has two names, and you prefer to use the one that supports your argument: You want people to think of it as logical, so you call it logical, even though the term "British" is more common. Don't fault me for using the name that I prefer. Unlike British style, American style doesn't have a secondary name that is common enough for people to recognize.

"American style" is not my spin, unless you think that I'm on the boards of all the style guides and website that call American style by this name. You don't have to take my word for it: [3] [4] [5] [6].) If you want me to stop calling British style "British" then please find me sources of equal or better quality showing that I am wrong to do so. This is not a dare or a rhetorical comment. It is a description of how my mind works. Show me convincing evidence, and I'll change my mind. I've done it before.

As for something in the archive, here's one from 2008, but there are others: [7] Darkfrog24 (talk) 00:47, 19 February 2014 (UTC)

RFC: Month abbreviations

This RFC has three separate but related parts and my closure will address these parts individually as part of the whole discussion. It should be understood that abbreviated months are allowed only in certain circumstances. This RFC did not address various circumstances, rather clarifies usage when those circumstances arise. The first part of the RFC, about limiting characters, shows consensus in favor of using only the first three characters, mostly for consistency, but also to keep the shortened version as short as possible. The second part of the RFC, about full stop, shows consensus against using the full stop, specifically to shorten the text. The third part of the RFC, about the MOS's agreeing, shows obvious consensus that all MOS's should agree and not be contradictory. The consensus shows the changes in the relevant manuals should reflect the outcome of this RFC. In summation, there is overall consensus, in certain circumstances, that when it is necessary to shorten a month, the month should be shortened to the first three characters with no full stop and this should be reflected in the two relevant MOS's. Cheers, TLSuda (talk) 21:44, 4 April 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Shall month abbreviations be limited to the first three characters of the month, or may a fourth character be used?
May a month abbreviation be followed by a full stop when it is not at the end of a sentence?
Shall WP:Manual of Style#Months and seasons and WP:Manual of Style/Dates and numbers#Acceptable date formats be required to agree on this point?

General discussion

As the originator of this discussion, I don't much care which abbreviations are allowed, but I am not pleased that the "Manual of Style" and the "Manual of Style/Dates and numbers" contradict each other, nor am I pleased that User:BattyBot is automatically changing abbreviations such as "Sept." to "Sep" within Citation Style 1 templates before this contradiction has been resolved. Jc3s5h (talk) 23:28, 13 January 2014 (UTC)

Likewise. I point out that this discussion could be subdivided on several points.

Presumably, in special cases "where conciseness is required" (e.g., tables) exceptions are allowed for use of abbreviated (with a period) or "short month names" (without a period).
For the rest: should abbreviated month names (including a period) be: a) allowed, b) disallowed, or c) no position?
If abbreviated month names are allowed, may they use four characters (e.g.: "Sept.")?
Outside of special cases, should should three-character short month names (like abbreviations, but lacking a period) be: a) allowed, b) disallowed, or c) no position?

~ J. Johnson (JJ) (talk) 00:15, 14 January 2014 (UTC)

Question: Can you specify exactly which sections of MOS: and WP:DATES are in conflict for the purposes of this RFC? As many readers as there are, it is possible that there will be as many different interpretations of just which sections your mean. Is it possible to focus the purpose of this RFC more carefully so that perhaps a more definitive result may be determined? Perhaps either of these things:

consolidate the grouped questions into a single statement / question
break up the grouped questions into multiple non-overlapping statements / questions

Of the several RFCs I've watched, we editors seem to wander a bit a way from the intent of the question. I wonder if by carefully crafting the question a better result might be obtained.

—Trappist the monk (talk) 00:11, 14 January 2014 (UTC)

I'm not sure it's helpful to break up the questions; to much structure might be incompatible with the direction the discussion ends up taking.

As for the point of contradiction, WP:Manual of Style#Months and seasons specifically endorses the abbreviation "Feb.", with the full stop. WP:Manual of Style/Dates and numbers#Acceptable date formats takes great care to spell out acceptable formats character by character, and the example Sep 8, 2001 does not contain a full stop. A discussion at Wikipedia talk:Manual of Style/Dates and numbers/Archive 143#Month abbreviations with four letters rejected my attempt to bring the two guidelines into agreement. Jc3s5h (talk) 00:24, 14 January 2014 (UTC)

I have boldly reformatted the original questions to try to cut down on the amount of wandering. I have also placed three separate discussion sections below. Please revert this edit if my changes do not meet the original intent. – Jonesey95 (talk) 00:46, 14 January 2014 (UTC)

Thanks to Sroc for alerting me to this conversation, and thanks to Jc3s5h for starting it here. (It seems that typing User:BattyBot didn't send me an email, even though I have the notifications set to do just that, so I've added web notifications for the bot account.) The goal of BattyBot 25's edits were to remove articles from Category:CS1 errors: dates, and changing abbreviations such as "Sept." to "Sep" did exactly that. While this RFC is open, I will not run that bot task. Upon completion of this RFC, I will see how Trappist the monk adjusts which citations get included in the error category, and adjust the bot accordingly. GoingBatty (talk) 04:44, 14 January 2014 (UTC)

I have also invited the three editors who posted at Wikipedia talk:Manual of Style/Dates and numbers#Abbreviated months in citations but have not yet posted here to join the discussion. GoingBatty (talk) 04:59, 14 January 2014 (UTC)

This discussion appears to have reached its conclusion, and the RFC is more than a month old. How do we close it officially? I am new to RFCs, so I don't know the formalities. – Jonesey95 (talk) 23:41, 15 February 2014 (UTC)

See WP:RFC#Ending RfCs. The general idea is an uninvolved editor summarizes the results and encloses the discussion in a box so that it is apparent that an RfC occurred and conclusions resulted. This provides a convenient target to point to when justifying edits to guidelines to make the guidelines conform to the consensus that was expressed. Jc3s5h (talk) 23:49, 15 February 2014 (UTC)

Thanks. After looking at the whole discussion, I feel that consensus is reasonably clear, but I am too involved in the discussion. I have posted a request at WP:ANRFC. – Jonesey95 (talk) 03:43, 21 February 2014 (UTC)

Discussion of 1. Three-letter abbreviations only

Three-letter and four-letter month formats I have seen in actual use: Jan, Feb, Mar, Apr, May, Jun/June, Jul/July, Aug, Sep/Sept, Oct, Nov, Dec. It seems to me that an allowable list would either be three-letter abbreviations only, or this list. Are we talking about more than this? I'm fine with being wrong; post a modification of this list for discussion. – Jonesey95 (talk) 00:50, 14 January 2014 (UTC)

In my opinion, the list above should be the way to go; in other words, June, July and Sept variants should be allowed in addition to three-letter abbreviations. Actually, it's just that Sept should be also allowed as an abbreviation, as June and July are full names. — Dsimic (talk) 01:12, 14 January 2014 (UTC) After spending some more time thinking about this, I'm changing my comment to allowing only three-letter abbreviations, and only where horizontal space is really tight. The only reason for having those abbreviations should be lack of horizontal space, and in that case space should be preserved as much as possible. — Dsimic (talk) 02:42, 14 January 2014 (UTC)

I think the first post in this subsection, by Jonesey95, lists the only realistic possibilities. Jc3s5h (talk) 01:09, 14 January 2014 (UTC)

If we are to use abbreviated months at all, which I do not support except for very tight spaces, I fail to see any advantage in keeping "Sept" or "Sept." as an abbreviation. "Sept" is clearly the odd man out and is not comparable to "June" or "July" – would look messy and inconsistent to have three and four-lettered month abbreviations in the same table or infobox. And if space is really tight, it would be an advantage to shorten "June" and "July" to "Jun" and "Jul" respectively, and also lose the full stop. That would also make it more consistent as the "May" in "31 May 2013" ought never to have a full stop under any circumstance. -- Ohc ^¡digame! 02:02, 14 January 2014 (UTC)

Agreed, though even three-letter-only abbreviations are still going to look a bit messy in a table column, due to proportional fonts. — Dsimic (talk) 02:42, 14 January 2014 (UTC)

I agree it's best to allow three-letter month abbreviations only. Allowing four-letter months only allows Sept as an abbreviation and the full months June and July; and would promote inconsistency with May which is always only three letters, and all the other months which do not have acceptable four-letter variants. —sroc 💬 03:53, 14 January 2014 (UTC)

I see no problem with a fourth letter for Sept, which is widely used by people. Insisting on the number 3 would be instruction creep and counterproductive, since people will use Sept anyway and should have the right to do so. June and July are allowed in any case as the full names, and there is no such thing as allowing only the abbreviations and not the full name. I don't think the extra letter should be a problem. Even with a period, which I am in favor to allow, as below. Debresser (talk) 10:19, 14 January 2014 (UTC)
- You can't have a period after May., June. or July., if that's what you're implying, as they are not abbreviations. (Incidentally, this is another reason to avoid the period, as it leads to inconsistency when using these full month names alongside three- or four-letter abbreviations. —sroc 💬 11:38, 14 January 2014 (UTC)

I agree with Ohconfucius that we should stick to 3-letter abbreviations and eliminate Sept as an option. There needs to be more consistency not less. Keith D (talk) 11:49, 14 January 2014 (UTC)
If it is really necessary to save space, only the shortest form should be used: three letters, no full-stop. Otherwise write month names in full. Justlettersandnumbers (talk) 12:15, 14 January 2014 (UTC)

You all seem to be ignoring the two drastically different contexts: 1) where space is tight and "conciseness is required" (such as tables), and 2) elsewhere, which is largely article text, but can include notes and references. The validity of arguments for or against abbreviations are generally context specific. ~ J. Johnson (JJ) (talk) 23:49, 14 January 2014 (UTC)

Pretty neutral. While I can see the argument for consistency in minimizing space, the four letter version "Sept" is so widely used that it's going to be hard to keep out, what with being the encyclopedia anyone can edit. Indeed, that's kind of why I lead to this being instruction creep. I wouldn't revert if anyone were to make an edit going for the consistent use of three-letter abbreviations, but I don't know if we need to mandate it. oknazevad (talk) 00:27, 15 January 2014 (UTC)

Stick with 3-letter abbreviations, where needed, and kick into touch the 4-letter abbreviation of Sept for September. 217.39.7.254 (talk) 19:00, 23 January 2014 (UTC)

It doesn't matter. Neutral as to whether 3-letter or 4-letter abbreviations should be used, and oppose requiring the use of one or the other unless minimizing space is required (or useful) for compliance with the Americans with Disabilities Act. Bwrs (talk) 09:24, 6 February 2014 (UTC)

Support — For simplicity, consistency, conciseness & æsthetics, as I've mentioned below, I'd say allowing only three-letter-no-dot abbreviations of months is the way to go. Jimp 10:00, 6 February 2014 (UTC)
Oppose - Pure instruction creep. The difference between Sep. and Sept. is negligible. Both are acceptable and standard. There is no reason to favor one over the other (unless it is an ENGVAR issue?). I would favor consistency within an article... but see no reason to mandate consistency across the entire project when it comes to month abbreviations. Blueboar (talk) 15:22, 6 February 2014 (UTC)
support if we are using abbreviations to save space – and I agree they shouldn't be use otherwise – then an extra two characters is probably a big help. Also, the comments to the effect of "we can't keep "Sept" out, so why bother adding more rules" are a bit silly since this whole thing was prompted by a bot. What exactly is the actual benefit to using "sept"? I see none. AgnosticAphid talk 07:55, 15 February 2014 (UTC)

Discussion of 2. Full stop after month abbreviation

I think it would be inconsistent to allow full stops and to also say that month abbreviations are allowed "only where space is extremely limited". – Jonesey95 (talk) 02:19, 14 January 2014 (UTC)

There's no point in allowing periods after month names abbreviations, if the primary intention for allowing them is to save some horizontal space. — Dsimic (talk) 02:47, 14 January 2014 (UTC)

I agree. I prefer the abbreviations without full stops. —sroc 💬 03:54, 14 January 2014 (UTC)

Abbreviations are routinely follow by stops in most languages, including English. Not allowing for this would therefore not be logical and cause problems because many editors will add them anyways. I think another period doesn't take up too much space. In short, I think a period can and should be allowed. Debresser (talk) 10:14, 14 January 2014 (UTC)
- Like many publications, Wikipedia has its own style guide and we can choose what formats are permitted. That's why we have MOS:BADDATEFORMAT; otherwise there would be anarchy in allowing any format that anyone uses. We try to limit the number of date formats we use and promote consistency in the few that we allow. Just because some editors may use a style that is disallowed by MOS is not a "problem" that means we need to change MOS; just fix the errors to conform with MOS. No problem. —sroc 💬 11:42, 14 January 2014 (UTC)

I agree that we should not be using a full stop after abbreviated months. Keith D (talk) 11:53, 14 January 2014 (UTC)
If it is really necessary to save space, only the shortest form should be used: three letters, no full-stop. Otherwise write month names in full. Justlettersandnumbers (talk) 12:15, 14 January 2014 (UTC)

Yes, if space is restricted. But: for any abbreviated form used in text (if that is allowed) a full-stop is required. That is the nature of abbreviations. ~ J. Johnson (JJ) (talk) 23:53, 14 January 2014 (UTC)
- Abbreviated forms are only permitted "in references, tables, lists or areas where conciseness is needed"; not in prose: see MOS:DATEFORMAT. We don't want different formats for abbreviations in different locations, either: see MOS:DATEUNIFY. —sroc 💬 00:10, 15 January 2014 (UTC)

Agreed. I wouldn't use a dot with an abbreviated month in any context; it would partly defeat the purpose of abbreviating. Tony (talk) 23:54, 14 January 2014 (UTC)
Eh, like above, don't know if we need to mandate this. oknazevad (talk) 00:29, 15 January 2014 (UTC)

If (where) abbreviations are allowed, then as abbreviations they should have the full-stop. But there is a special case: three letters, all capitals (e.g.: "JAN"). This is standard in some places (e.g., communications, esp. military) where economy is desired and the full-stop seems excessive. While I would not want to see that as a generally acceptable "style", I think we should allow it for tables (only). ~ J. Johnson (JJ) (talk) 21:49, 20 January 2014 (UTC)

As these are only used in context of extremely tight space then using a full-stop is counter-productive so we should not be allowing this as an option. 217.39.7.252 (talk) 19:03, 23 January 2014 (UTC)

Let's measure how much width this full-stop is using:
- Jan Jan Jan Jan Jan Jan
- Jan. Jan. Jan. Jan. Jan. Jan. 6 full-stops seem to take the width of 3 letters, so each period is about half a character. Decide for your selves how important half a character is to a table (most tables are likely to have only one, maybe two date columns). Stepho talk 23:44, 23 January 2014 (UTC)

That means "Jan." is about 17% longer than "Jan", reducing the shortening of "January" to 50% instead of 43%. Meh. :) — Dsimic (talk) 01:23, 24 January 2014 (UTC)

Allow a period. In general, abbreviations usually have a period after them unless they are part of an acronym (and are optional as part of an initialism). I generally disfavor making rules of style mandatory ("Wikipedia's Manual of Style (MoS) is a guideline, or a set of 'best practices' supported by consensus. The MoS is not a collection of hard rules")[8]; otherwise I might even want to require the use of a period after abbreviations. If there is no legal compliance issue then I strongly favor allowing the dot. But if legal compliance requires us to save space, that is more important than following the rules of standard English. Bwrs (talk) 09:31, 6 February 2014 (UTC)

Disallow the dot in favour of consistency. If we could settle on one style of abbreviations for month names, I reckon the gain in consistency would be worth the trouble. If we are going for one style, the three-letter-no-dot style would be preferable; it's consistent in terms of length (which is nice especially for tables), it's simple and it's what the {{#time}} parser function gives us (so we're sort-of stuck with it anyway). If we do allow the dot, though, we should at least recommend consistency within an article, i.e. give editors a choice between two specific styles: three-letter-no-dot or three-or-four-letter-dot-or-no-dot (i.e. Jan., Feb., Mar., Apr., May, June, July, Aug., Sept., Oct., Nov. & Dec.). Jimp 09:50, 6 February 2014 (UTC)

Discussion of 3. Agreement between WP:MOS and WP:MOSNUM

It is my impression that WP:Manual of Style/Dates and numbers (MOSNUM) is intended to provide additional details so the length of this guideline may be kept reasonably short; since this guideline has a larger audience, I don't believe statements in this guideline should be contradicted by statements in subsidiary guidelines. Jc3s5h (talk) 01:25, 14 January 2014 (UTC)

Good guidelines are never mutually opposed or inconsistent. — Dsimic (talk) 02:49, 14 January 2014 (UTC)

I agree that one or other of the guidelines (or both) should be amended to remove the (perceived) inconsistency. My preference would be to edit:
- WP:MOS#Months and seasons to omit the option with a period, consistent with MOS:DATEFORMAT which only uses three-letter month abbreviations without a period; and
- MOS:BADDATEFORMAT to explicitly state that four-letter month abbreviations and periods after a month abbreviation are not acceptable variations. —sroc 💬 04:00, 14 January 2014 (UTC)

Support that there should be agreement between WP:MOS and WP:MOSNUM, and that Help:Citation Style 1, Template:Cite web/doc and other documentation should reinforce and cite these guidelines. GoingBatty (talk) 04:50, 14 January 2014 (UTC)

Both guidelines should say the same. This is obvious IMHO. Debresser (talk) 10:16, 14 January 2014 (UTC)

Agree that the two manuals should be consistent, also as per sroc above that we should explicitly disallow 4 character date abbreviations and remove the use of a full stop after the abbreviated name. Keith D (talk) 11:58, 14 January 2014 (UTC)
There must be consistency. Justlettersandnumbers (talk) 12:15, 14 January 2014 (UTC)
It's only be a disservice to newer editors not to have consistency, so naturally the guidelines should match. Not that every detail need be in the main MoS, but what is covered here should give the same advice as is in the specific guideline. Indeed, I'd say that goes without saying. oknazevad (talk) 00:18, 15 January 2014 (UTC)
They should definitely not require different or contradictory things. But as for one guideline being permissive and the other being mandatory, that may simply reflect a lack of consensus. Once a consensus is formed, they should say the same thing. Bwrs (talk) 09:24, 6 February 2014 (UTC)
There is no question that the MOS an all its subpages should be consistent. As stated above, it's obvious. Jimp 09:29, 6 February 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

mdash

The manual on mdash was inconsistent: it first says "use one or the other consistently in an article" and then shortly after it said "do not use spaced em dashes". Can we please have clarity. — RHaworth (talk · contribs) 19:09, 22 February 2014 (UTC)

I can't see the inconsistency: if em dashes are chosen for interruptors on the sentence level, they need to be closed, not open. In contrast, en dashes in that role must be open. Tony (talk) 08:40, 23 February 2014 (UTC)

Yes. It does not say "don't use em dashes", it says to not use spaced em dashes. The desired consistency here is in using either spaced en dashes, or unspaced em dashes. ~ J. Johnson (JJ) (talk) 21:12, 24 February 2014 (UTC)