Misplaced Pages

Revision as of 13:34, 28 January 2014

This page (along with all other MOS pages and WP:TITLE) is subject to Arbitration Committee discretionary sanctions. See this remedy.

Manual of Style

This page falls within the scope of the Misplaced Pages:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Misplaced Pages Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Misplaced Pages's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Misplaced Pages policies of Misplaced Pages's policy and guideline documents is available, offering valuable insights and recommendations.

This is the talk page for discussing improvements to the Manual of Style page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcut WT:MOS

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228Auto-archiving period: 14 days

Template:MOS/R

For a list of suggested abbreviations for referring to style guides, see this page.

This is the talk page for discussing improvements to the Manual of Style page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228Auto-archiving period: 14 days

Hyphens instead of endashes

From the discussion at Talk:Epstein–Barr virus#Requested move, it came to my attention that, as currently written, the line "A hyphen is used by default in compounded proper names of single entities." (line A) contradicts the line just before it, "An en dash is used for the names of two or more people in an attributive compound." (line B). Line A is easily read to imply that entities such as Comet Hale–Bopp (one of our examples here) should be hyphenated, not dashed, contrary to what line B says. They are properly dashed, though. In a few cases, such as the examples accompanying line A (McGraw-Hill, Guinea-Bissau, etc.), there is properly a hyphen, not an endash. What seems to distinguish line A's category is that these are no longer simply seen as named after two entities, but as entities with a single name. --JorisvS (talk) 10:23, 19 November 2013 (UTC)

I can attest to the confusion caused by line A in the Talk:Epstein–Barr virus#Requested move. Lines A and B, to me, seemed to suggest contradictory ways of writing "Epstein Barr virus": hyphenated as a single entity, or en dashed as an attributive compound named after Epstein and Barr. Walternmoss (talk) 13:54, 19 November 2013 (UTC)

In an earlier discussion about en-dashes vs. hyphens, there was some agreement that the wording of this section of the MoS needed to be clarified, but nothing happened – partly, I think, because Noetica said he would look at it, but he left Misplaced Pages. JorisvS is right that the key difference is whether the separate entities are seen as distinct. Since the Epstein–Barr virus article explains the origin of the name from two people, an en-dash is clearly appropriate. "McGraw-Hill" still seems to me a problematic case. I don't see "McGraw" and "Hill" as the origin of "McGraw-Hill", so a hyphen appears appropriate to me. However, it might be that someone more familiar with the publishing industry would be aware of the two entities, and would use naturally use an en-dash. Can this subjectivity be avoided? Peter coxhead (talk) 17:31, 19 November 2013 (UTC)

I'm not familiar with previous discussions about this, but ... is there any reason why WP:COMMONNAME wouldn't apply to questions like this? --Stfg (talk) 18:43, 19 November 2013 (UTC)

Well, that has been the fiercely (sometimes viciously) debated issue on more than one occasion. In one corner are those who would answer that WP:COMMONNAME should apply, and that the relative usage of en-dash vs. hyphen in reliable sources should determine usage here. In the other corner are those who would answer that COMMONNAME does not apply to style issues, and that in the interests of consistency Misplaced Pages should apply its own style rules regardless of sources. Let's not start this debate all over again. (It applies to en-dashes vs. hyphens, capitalization of the English names of species, logical quotation style vs. traditional US quotation style, and doubtless a number of other issues. In every case the second position has been upheld.) Peter coxhead (talk) 18:55, 19 November 2013 (UTC)

There was a pretty heated discussion on the Epstein–Barr virus (EBV) talk page about the en dash (primarily me ranting). What the argument arose from, was the fact that I had never recalled seing an en dash used in any of the scientific literature...until pointed out by several other wikipedians in a minority of papers. From my count, a hyphen is used in EBV ~98% of the time in article titles archived on PubMed. I was fighting very hard for the hyphen w/o knowing about this WP:COMMONNAME rule, as it intuitively made sense to use the "consensus" or most-common form of the name to me. Eventually I changed my mind. What really turned me around was the recognition of the utility of the en dash, it's grammatical appropriateness, and (most importantly) the discovery of its use in several "key" or "landmark" papers. Ultimately, I think the source material (particularly for technical matters) should guide naming conventions on Misplaced Pages. In the EBV field there is a diversity of naming, so my attempted compromise solution has been to look for precedents in the lit. that jibe with the Misplaced Pages guidelines, good grammar (to the best of my knowledge), and that allow for some sort of consistency in the naming of pages. It's tough. Walternmoss (talk) 23:40, 19 November 2013 (UTC)

So, what about adding "... if these are no longer seen as named after two entities." to the sentence about the hyphens? Any problems with saying that? --JorisvS (talk) 08:28, 22 November 2013 (UTC)

Only that I've no idea what it means. But I've no idea what the present wording is supposed to mean either, so the addition won't make it any worse. In fact I think I know what it's supposed to mean. If the compound is "attributive", then it's dashed. That means if it qualifies another noun, as in the Hale-Bopp case, where it qualifies "Comet". (Presumably in the example with "just" Hale-Bopp, without the "Comet", the compound is still regarded as attributive because the noun is still understood.) But if the compound is the whole name, then it's hyphenated. The union of two cities seems to be an example of a different sort, that perhaps ought to have a separate bullet point. W. P. Uzer (talk) 09:57, 22 November 2013 (UTC)

So, how do you think we could rephrase it? --JorisvS (talk) 10:17, 22 November 2013 (UTC)

Somewhat like this, perhaps? W. P. Uzer (talk) 11:45, 22 November 2013 (UTC)

Sorry, can you actually suggest that directly on the talk page rather than actually editing the MOS and posting a link to that edit? The MOS needs to be stable and changes need to be discussed first. N-HH talk/edits 12:00, 22 November 2013 (UTC)

No they don't. Pages on which anti-Wikipedians try to enforce an ad hoc "no change without discussion" policy are the ones that have the most problems, because the normal channel by which problems are fixed is closed off. If you object to my changes, say why, and then we can have a discussion. Otherwise you're just making things worse with your groundless reverts. W. P. Uzer (talk) 14:17, 23 November 2013 (UTC)

@W. P. Uzer: this MOS guideline is a bit different from the average article. It has been struggled over for years, and hyphens and dashes are one area where development has been especially challenging. Please note the banner at the top of the project page itself, where it says "Please ensure that any edits to this page reflect consensus." This applies especially to issues that are under active discussion here and where there are differing views. Please also take care about dubbing the people around here as "anti-Wikipedians", as this sort of language escalates the kind of tension that can arise here, which we're all doing our level best to avoid. Regards, --Stfg (talk) 14:47, 23 November 2013 (UTC)

Indeed. This is not a substantive entry for an individual topic, where of course not every change needs pre-approval or prior discussion and consensus, but a site-wide guideline page. There's a rather obvious difference in content and purpose, and hence in terms of the need for stability, as the banner here makes clear. I have no idea what an "anti-Wikipedian" is. N-HH talk/edits 15:01, 23 November 2013 (UTC)

In this case, someone who would prefer to keep a problem rather than solve it, because by keeping it we achieve "stability". Or simply someone who doesn't get (or who opposes) the idea that "everyone can edit". Sadly, there seem to be more and more such people around, not only on this page. W. P. Uzer (talk) 15:21, 23 November 2013 (UTC)

Who says I'd rather keep the problem for the sake of stability? And who says your edits solved anything anyway? The first of the two I reverted together removed an entire sentence, claiming it was repetition when it wasn't, since it included the suggestion of using alternative, more common words. The second, which related more specifically to the hyphen/endash point, shuffled text around and added the confusing and confused claim about "a compound which qualifies another noun", when we are actually taking about names and proper nouns. Nor did it do anything to solve the actual underlying problem with this part of the MOS, which is its apparent internal contradiction. That's what's already being discussed, and it doesn't help to have the current text being shuffled around as that discussion takes place. N-HH talk/edits 15:38, 23 November 2013 (UTC)

All right, now you're providing reasons, good. If you'd done that to start with, rather than inventing quasi-procedural justifications for your action, then we would have made progress far more pleasantly. W. P. Uzer (talk) 16:00, 23 November 2013 (UTC)

The "quasi-procedural justifications" were a perfectly valid reason for reverting, without or without any fuller explanation of the problems with the content of the edit. If you'd made your proposal here, I and others could have responded substantively to that from the outset. However you try to rationalise this, the bottom line is that someone asked you for your suggestion; instead of explaining any proposed changes and awaiting comments, you simply edited the page and then pointed them to that edit. That is not how the editing process works, not least because if everybody went about it that way, especially for unclear issues and especially on site-wide guidelines, it'd be chaos. N-HH talk/edits 17:02, 23 November 2013 (UTC)

No, that's exactly how the editing process works, or is supposed to work. Even on a site-wide guideline (so what? I didn't change the substance of any guidance), we first try to make things better by making things better. It's honestly the most effective way, and the secret of Misplaced Pages's success. I won't respond any more on the topic since I know people like you are inaccessible to the light, but I remain in diametric disagreement with you on this point. W. P. Uzer (talk) 20:06, 23 November 2013 (UTC)

All this patronizing lecturing doesn't advance the issue. I still don't know if anyone objects to my changes, and if so, for what reason. This is exactly the kind of behavior which makes "development especially challenging". It would be a whole lot less challenging if people only reverted if they disagreed, and explained why they disagreed. That way we wouldn't waste time on non-issues and meta-issues, problems would be fixed without fuss, and discussion would be focused on such genuine problems as really require it. W. P. Uzer (talk) 14:57, 23 November 2013 (UTC)

The revert wasn't "groundless". The grounds were that it restored what had been agreed by a prior consensus, until such time as a new consensus might be agreed. Had you made your proposal here, people would surely have given reasoned opinions of it. Please remember that the MOS represents a previous consensus, which it's fine to change, but not OK to ride roughshod over. --Stfg (talk) 15:45, 23 November 2013 (UTC)

So I changed it, which you say is fine. I didn't "ride roughshod over it"; I didn't change any of the substance of the advice, just tried to improve the way it was worded. If someone disagrees that it was an improvement, that's fine. The implication of the original reasoning was that it didn't matter whether or not it was an improvement, it was that attempted improvements are not welcome here per se, which is obviously not a helpful attitude to take. W. P. Uzer (talk) 16:00, 23 November 2013 (UTC)

Just to clarify, what I said is fine to change is consensus; it isn't OK to change text that was hammered out in a consensus-building process, without first changing the consensus by means of discussion. --Stfg (talk) 17:42, 23 November 2013 (UTC)

Again, there is no attempt to "change the consensus", just to better express what the consensus is. That oughtn't to require long process, or we'll never achieve anything. W. P. Uzer (talk) 20:06, 23 November 2013 (UTC)

I have seen arguments over the years about em-dashes, en-dashes, hyphens, minus signs et al. I have not read all the walls of text about the arguments so maybe my question has already been answered somewhere but I have not seen it. For the reader or anyone for that matter what difference does it make which one is used? Do reader or writers for than matter gain more insight into a subject if the "correct" one is used? Do we lose some understanding if the incorrect one is used? I do not see any reason to worry about this minutia but maybe there is a good reason to spend so much time on dashes. Can someone explain to me why we need to spend so much time and space on this? 69.255.176.248 (talk) 11:37, 22 November 2013 (UTC)

Yes, for readers who understand normal English punctuation, the distinctions signaled by punctuation are useful and make it easier to understand the material quickly. Dicklyon (talk) 17:56, 23 November 2013 (UTC)

I suppose we spend the time and space here, at a central point, so that editors don't end up spending even more time and space debating the point on many diverse articles. Also, it's fun to apply one's mental capabilities to something that doesn't really matter (hence chess, crosswords, etc.) W. P. Uzer (talk) 11:45, 22 November 2013 (UTC)

There is also always the solution, suggested by me and others in the past, of going back to what many publishers and readers, especially online, are quite happy with: which is to only ever use a hyphen for all such joins (including prefixes) and to not worry about hyphen/endash distinctions to start with. Sadly, it's never going to fly because too many people on these pages think it's "unprofessional" while others seem to quite like these endless navel-gazing disputes about how to apply the rules in each case. N-HH talk/edits 12:00, 22 November 2013 (UTC)

I wasn't asking why the time is spent here, I was asking about overall time spent on this issue. I guess N-HH answered the question, editors think it is unprofessional to have the "wrong" dash but it does not look like it really makes any difference, people just love to argue. 69.255.176.248 (talk) 12:14, 22 November 2013 (UTC)

The wrong dash? You mean an em not an en dash? Tony (talk) 14:47, 23 November 2013 (UTC)

this is all really lame and of concern only to grammar nazis. -- TRPoD aka The Red Pen of Doom 15:37, 23 November 2013 (UTC)

Maybe you could try to make useful comments instead of ranting about "grammar nazis". --JorisvS (talk) 18:17, 23 November 2013 (UTC)

If I might try to continue the more substantial discussion at the bottom of the thread where we can find it, can anyone do a better job than I did at explaining the apparent contradiction (and in the process, perhaps explaining what an "attributive compound" is)? W. P. Uzer (talk) 16:15, 23 November 2013 (UTC)

Actually, is it even clear what the problem is? Is it that simply all compounds that are used attributively (whether or not implied) dashes and those are used substantively hyphenated. Or is it whether or not the entity is seen as one whole, no longer considered named after two distinct entities? --JorisvS (talk) 16:22, 23 November 2013 (UTC)

It's the latter surely. All the examples listed are names of things and proper nouns, whether it's McGraw-Hill or Hale–Bopp. The problem is that there is no obvious logic to that distinction, or at least no obvious logic than can be applied consistently. N-HH talk/edits 17:05, 23 November 2013 (UTC)

The difficulty with the latter is that that rule is pretty subjective, but that need not be a problem for the MoS. It could be worded as "A hyphen is used in proper names when the entity is seen as one whole and is no longer considered named after two distinct entities.". --JorisvS (talk) 18:17, 23 November 2013 (UTC)

Well, Wilkes-Barre is presumably considered to be named after two distinct entities, by those who know it is so named, just as Hale–Bopp is considered to be named after two distinct entities, by those who know it is so named. (People who don't know might think anything.) And they are both seen as one whole. So why does one have a dash and the other a hyphen? W. P. Uzer (talk) 20:13, 23 November 2013 (UTC)

Nobody got any ideas? Maybe I was right the first time, and we decided to use the dash in Hale–Bopp just because it is a shortening of Comet Hale–Bopp, in which Hale–Bopp is an attributive compound? W. P. Uzer (talk) 20:55, 24 November 2013 (UTC)

Okay, it is clear that it is not yet clear what the rule we are supposed to be clarify is exactly. --JorisvS (talk) 11:03, 25 November 2013 (UTC)

So should we not assume that the text is intended to say what it appears to be saying - that such compounds take a dash if they're "attributive"? Thus the clarification would involve merely defining "attributive", doing it in such a way that the definition includes cases like Hale–Bopp even when the word Comet gets omitted. W. P. Uzer (talk) 09:36, 26 November 2013 (UTC)

I think we're in danger of drawing a false distinction in terms of meta-language here. Hale-Bopp and McGraw-Hill are both proper names of things – of a comet and a publishing house respectively. In so far as they qualify those latter terms, they are also attributive and adjectival phrases. The fundamental issue, whatever language we use to describe it, seems to be that where the two names have in some mysterious way become one, we would use a hyphen. Until then, we use an endash. It might help if one of the people who regularly stick up for making a rule out of such distinctions – a minority practice among publishers as a whole, especially non-book publishers – and have helped foist it on Misplaced Pages, explained how, exactly, they think the distinction works and how the MOS might best be worded for clarity and to avoid confusion and apparent contradiction. N-HH talk/edits 10:23, 26 November 2013 (UTC)

It does seem that McGraw-Hill is a poor example, partly because its name has now changed, and partly because it always seems to have been attributive in virtually the same way that Hale–Bopp is. Perhaps we should just follow the conventions used in the relevant literature in cases like this. (The official company name, the official comet name as listed by astronomical bodies, etc.) W. P. Uzer (talk) 10:45, 26 November 2013 (UTC)

So why don't we make this easy? Every dash used on Misplaced Pages looks like this, -. It is easy because you just have to type it on the keyboard and most readers (the people we are creating this for) probably could care less what it looks like. Problem solved. 69.255.176.248 (talk) 20:23, 23 November 2013 (UTC)

Or not solved, because many people are used to using and seeing real dashes in certain situations and will try to insert them. There isn't really a problem anyway, because in the rules are clear for the great majority of cases and correspond to what most experienced writers will be used to. The ambiguity we're talking about here affects only a very limited set of cases. W. P. Uzer (talk) 10:46, 24 November 2013 (UTC)

I thought a hyphen and an en-dash were the same thing, and an em-dash was something slightly wider which some people insist on in some circumstances I can never remember, and which doesn't have a key for it. If "normal English punctuation" requires us to distinguish identical characters, and use special keys absent from English-language keyboards, with certain rules half the English-speaking world never knows about, then "normal English punctuation" isn't part of normal English. Ananiujitha (talk) 21:31, 24 November 2013 (UTC)

If you have a keyboard that looks something like this, there are only two keys that will directly give a hyphen, and none that will give a dash. The two that produce a hyphen are (i) in the main keyboard, immediately to the right of the digit 0; (ii) in the numeric keypad on the right, directly above the +. These give the same character, which strictly speaking is called hyphen-minus since it has a dual role. In Wikitext, the hyphen-minus and en dash are the same width as each other, with the em dash being slightly longer; but when displayed on a finished page, the hyphen-minus is about half the width of the en dash – which is itself half the width of the em dash — you can enter both of these characters into Wikitext using a variety of techniques. --Redrose64 (talk) 00:05, 25 November 2013 (UTC)

I think you'll find the hyphen-minus (-) is different from an en dash (–), the latter being longer than the former. They do perform different tasks. They were indistinguishable on typewriters with fixed-width characters and, sadly, computer keyboard makers failed to differentiate them when other fonts came along and the world got lazy. Microsoft Word automatically converts hyphens to endashes when surrounded by a space on both sides, but most other applications don't, so the subtlety has become lost to many. A hyphen, however, is never a correct substitute for an em dash (—), which basically denotes a parenthetical remark—like this one—where they are paired in the same way as parentheses. It can also be used for a parenthetical remark at the end of sentence without another em dash before the full stop—like this. Luckily, both of these dashes are readily available using the Wiki markup links below the edit box. —sroc 💬 00:46, 25 November 2013 (UTC)

It is sad that there is this problem with typing endashes, but it is not relevant for the issue at hand: The rule that describes the few cases when a hyphen should be used instead of an endash. --JorisvS (talk) 11:03, 25 November 2013 (UTC)

So to come back the question of why it's Hale–Bopp with a dash and Wilkes-Barre with a hyphen, does anyone have any better suggestions than the one currently implied: that in the first case the compound is "attributive" (the qualified noun "comet" being understood), while in the second it isn't? And if not, does anyone object to this being clarified with the addition of an explanation of what is meant by "attributive"? W. P. Uzer (talk) 10:21, 28 November 2013 (UTC)

Are any external style guides saying that, or are you inferring it from the examples to hand? If the former, could you give us some links? Then I'd say go for it. If the latter, I'd say it's original research, and from an anecdotal sample. And while I'm here, what is the rationale for removing the McGraw-Hill example from the guideline while this discussion is still in progress? The edit summary says "see talk", but I'm missing the explanation, and it may be important, since you've pointed out that it's attributive, which would mean that it's a counter-example to this theory, hence important. --Stfg (talk) 16:06, 28 November 2013 (UTC)

I'm inferring it from what's written in the guideline, which is supposedly based on a consensus that Misplaced Pages editors reached. "Attributive" seems to be the key word, and I'm inferring what is meant by "attributive" based on the examples given and my knowledge of what attributive actually means. I can't come up with any logical explanation for McGraw-Hill within the framework given, so I'm assuming it was an error, and since the present name of the company has no hyphen or dash, according to its article, the example seems to have lost its purpose in any case (but please restore it if you think it will help our deliberations). W. P. Uzer (talk) 18:20, 28 November 2013 (UTC)

"Attributive" is something of a red herring; it's incidental to the intended distinction. Using hyphens or en-dashes in the problematic cases being discussed here has to do with the "binding strength" of the two symbols: hyphens bind more tightly than en-dashes. Thus in Lennard-Jones potential the hyphen is intended to show that this is named after a single person called "Lennard-Jones". In Comet Hale–Bopp the en-dash is intended to show that it is named after two people called "Hale" and "Bopp". "Lennard" and "Jones" are bound more tightly than "Hale" and "Bopp". This makes excellent sense, until you consider more evidence and more cases. Thus:

• The distinction for comets is irrelevant, because the naming authority only uses one element of a hyphenated name. Thus if Lennard-Jones and Hale had jointly discovered a comet, the name would not be Lennard-Jones–Hale (1st = hyphen, 2nd = en-dash) but Lennard–Hale. So by using an en-dash in Misplaced Pages, we are making a distinction which isn't needed.
• Cities can acquire double-barrelled names in several ways. They can be named after two people or two cities can merge. We want the first case to bind the names more tightly than the second case, so a city named after two people uses a hyphen (hence Wilkes-Barre) but a union of two cities uses an en-dash (hence Minneapolis–Saint Paul). However, this leads to an inconsistency between cities named after two people, which use a hyphen, and theorems, laws, comets, etc. named after two people, which use an en-dash.
• What is being attempted is to use hyphen and en-dash to mark in text tightness-of-binding distinctions that can be made in symbolic contexts by parentheses. However, any number of levels can be marked by nested parentheses, but only two by hyphen and en-dash. Since hyphenated proper names can arise by more than two joining processes as shown above (one person with a double-barrelled name, two people, two cities) it's never going to work without some inconsistencies.

Personally, I don't think it's worth making the hyphen/en-dash distinction in proper names of this kind; it just causes too much hassle. However, if we do make the distinction, there are bound to be anomalies. Peter coxhead (talk) 18:14, 28 November 2013 (UTC)

Why do you say "We want the first case to bind the names more tightly than the second case, so a city named after two people uses a hyphen (hence Wilkes-Barre)"? Shouldn't it be Wilkes–Barre, for the same reasons as Hale–Bopp and Minneapolis–Saint Paul, namely, the combination of the names of separate entities? I think the hyphen/dash distinction is too subtle for anyone to make any assumptions whether Wilkes-Barre or Wilkes–Barre is one town named after two people or a merger between two towns, without context or clarification, when it could easily be put down to a typo or some editor misunderstanding the distinction. —sroc 💬 22:49, 28 November 2013 (UTC)

Personally, I would have thought Wilkes-Barre (hyphenated) was an individual’s surname, as in Double-barrelled name, rather than a thing’s name. —173.199.215.5 (talk) 23:12, 28 November 2013 (UTC)

So does anyone have any idea how to sort out this mess (with minimal change to the substantial consequences of the guidance, I suppose)? W. P. Uzer (talk) 20:55, 29 November 2013 (UTC)

I'd say leave well enough alone, unless you find a grammar guide that does a good job of it. Wilkes-Barre is a city, not much like Minneapolis–St. Paul, which is two cities. The distinction between Wilkes-Barre and Hale–Bopp is more subtle, but editors mostly know it when they see it, and there's not usually much disagreement that the former is more strongly bound into a single city name and the latter is the names of co-equal discoverers of the comet. Many sources use en dash in Hale–Bopp; none do for Wilkes-Barre, as far as I know. Dicklyon (talk) 06:09, 2 December 2013 (UTC)

The problem is that the current wording is unclear (see the link at the beginning of this post), no matter the rules, and so has to be changed. However, for it to be changed, we must be clear on what the rule is. --JorisvS (talk) 09:16, 2 December 2013 (UTC)

Here's another example to consider: The Hindi-Urdu language (hyphen, a single language, sometimes called Hindi, sometimes Urdu) vs the Hindi–Urdu controversy (dash, dispute between Hindi and Urdu).

McGraw-Hill is an oddity, but I think is universally hyphenated. It's an idiosyncratic exception that's being treated as a double-barreled name; there's no real reason for it, AFAICT. Guinea-Bissau is irrelevant: That's not a union of Guinea and Bissau, but rather the Guinea of Bissau vs. Guinea-Conakry.

But the constant attacks and attempts to dumb down Misplaced Pages so it contains nothing an editor doesn't already know is a distraction from actually trying to clarify such issues. If we can't discuss this rationally, I think we should probably just remove the counter-example and leave McGraw-Hill as an eccentric exception, with a link to this discussion rather than to the MOS. — kwami (talk) 07:35, 1 December 2013 (UTC)

And what about Wilkes-Barre? Would you put that in the same "eccentric" category, or do you think its exclusion from the dash rule is connected with the fact that the compound is not "attributive"? W. P. Uzer (talk) 20:02, 1 December 2013 (UTC)

Can we find a solution? Is the use of a hyphen instead of an endash:

a) a few oddities

b) because it is not in an attributive phrase attributive (whether implied or not)

c) because these are more strongly bound together (and if so, how to decide which should be used)?

d) or because they are seen as single entities no longer named after which they were originally named?

Or a maybe a combination of these? In any case, the current wording is unclear, as has been experienced here, and therefore must be changed. This can only be done, however, if we know how to change it. --JorisvS (talk) 19:25, 4 December 2013 (UTC)

It seems that most people here think "attributive" is in fact irrelevant. So how about we delete that word, and simply say afterwards that if some term (such as Wilkes-Barre) is invariably written with a hyphen rather than a dash in sources, then we do so also? The other examples like Guinea-Bissau probably don't even belong in that section, as Kwami pointed out. W. P. Uzer (talk) 09:41, 5 December 2013 (UTC)

But then, when is it enough? Is one example of a dash already sufficient for us to dash the term? --JorisvS (talk) 09:52, 5 December 2013 (UTC)

So, should we just delete the paragraph and just say that there are a few casewise-determined cases where a hyphen is used where one would expect an endash? --JorisvS (talk) 15:45, 8 December 2013 (UTC)

I was thinking, what about an endash is used to indicate a symmetrical relationship, and a hyphen to indicate the unity of the two? This would explain Hindi–Urdu controversy vs. Hindi-Urdu. It would also explain Wilkes-Barre (1 city) vs. Minneapolis–St. Paul (2 cities). It would also explain names such as Lennard-Jones. --JorisvS (talk) 12:39, 11 December 2013 (UTC)

No one disagrees or knows a counterexample? This MOS line style still needs to be clarified, so I'll do that if no one voices any disagreement. The latter explanation seems to be the best one we've been able to find, I think. --JorisvS (talk) 12:54, 15 December 2013 (UTC)

I don't think you have a mandate to make changes. Could you print here the current and your proposed new texts first, for our consideration? Tony (talk) 02:28, 16 December 2013 (UTC)

Sure. This is what I'm proposing:

An en dash is not used for a hyphenated personal name.

• Lennard-Jones potential with a hyphen: named after John Lennard-Jones

An en dash is used for the names of two or more people in an attributive compound.

• the Seifert–van Kampen theorem;   the Seeliger–Donker-Voet scheme;   the Alpher–Bethe–Gamow theory
• Comet Hale–Bopp or just Hale–Bopp (discovered by Hale and Bopp)

A hyphen is used by default in compounded proper names of single entities.

• Guinea-Bissau; Bissau is the capital, and this distinguishes the country from neighboring Guinea
• Wilkes-Barre, a single city named after two people, but Minneapolis–Saint Paul, a union of two cities
• John Lennard-Jones, an individual named after two families

An en dash is used to indicate a symmetrical relationship, but a hyphen is used to indicate a unity.

• Hindi–Urdu controversy (a dispute between Hindi and Urdu) vs. Hindi-Urdu (an alternative name for the Hindustani language)
• Minneapolis–St. Paul (2 cities) vs. Wilkes-Barre (1 city named after Wilkes and Barre)
• John Lennard-Jones, an individual named after two families

The en dash in all of the compounds above is unspaced.

Does anyone have suggestions or remarks? --JorisvS (talk) 16:32, 16 December 2013 (UTC)

At first look there's a comforting conceptual simplicity in what you propose: "An en dash is used to indicate a symmetrical relationship, but a hyphen is used to indicate a unity." But thinking it through, symmetry is not essential; separateness in the entities is what counts more. Consider:

• US–Australia cultural and linguistic exports.
• A Hanoi–Da Nang train journey.
• Our China–Siberia border crossing.

No symmetry, but separate entities invoked. Reversibility is one "test", but it's not always the case. Ontological separateness is what really counts.

We all want a guideline that is optimal for editors to understand. May I ask for a short statement as to what is unsatisfactory or difficult about the current text? That would help us to know where it stands. Tony (talk) 09:09, 18 December 2013 (UTC)

Okay, so we say "An en dash is used to indicate separateness of the names, but a hyphen is used to indicate unity." instead. The current text, as explained above, is unclear and appears to directly contradict itself. First it says "An en dash is used for the names of two or more people in an attributive compound.", with Comet Hale–Bopp as an example, but then it says "A hyphen is used by default in compounded proper names of single entities.", even though the name of a single entity was dashed just before. --JorisvS (talk) 09:45, 18 December 2013 (UTC)

Any other critical notes? --JorisvS (talk) 12:54, 30 December 2013 (UTC)

Exactly what is wrong with the current text? Tony (talk) 13:03, 30 December 2013 (UTC)

What did I say just above? That. --JorisvS (talk) 14:00, 30 December 2013 (UTC)

Indeed – exactly as was pointed out at the start of the thread all those weeks and bytes ago. It's amazing how long it can take for some things to sink in. As I recall saying at some point, it would be useful if one of those who initially insisted that WP apply this minority-practice distinction at all and/or any of those who then contributed to the drafting of the current detailed section, could actually weigh in and help out. Those people would include your interlocutor here, among others. N-HH talk/edits 15:39, 30 December 2013 (UTC)

I don't see a problem: it says "by default", which indicates that there are exceptions. If it would be clearer, perhaps add "However,"? "However, a hyphen is used by default in compounded proper names of single entities." Tony (talk) 00:57, 1 January 2014 (UTC)

But how is "Comet Hale-Bopp" not a "compounded proper name" of single entity? Fine, there are exceptions to any rule, but how is anyone meant to work out what they are, how frequent they are or how the distinction is drawn? N-HH talk/edits 12:02, 2 January 2014 (UTC)

Is there still anything wrong with my suggestion above?

An en dash is not used for a hyphenated personal name.

• Lennard-Jones potential with a hyphen: named after John Lennard-Jones

An en dash is used for the names of two or more people in an attributive compound.

• the Seifert–van Kampen theorem;   the Seeliger–Donker-Voet scheme;   the Alpher–Bethe–Gamow theory
• Comet Hale–Bopp or just Hale–Bopp (discovered by Hale and Bopp)

A hyphen is used by default in compounded proper names of single entities.

• Guinea-Bissau; Bissau is the capital, and this distinguishes the country from neighboring Guinea
• Wilkes-Barre, a single city named after two people, but Minneapolis–Saint Paul, a union of two cities
• John Lennard-Jones, an individual named after two families

An en dash is used to indicate separateness of the names, but a hyphen is used to indicate unity.

• Hindi–Urdu controversy (a dispute between Hindi and Urdu) vs. Hindi-Urdu (an alternative name for the Hindustani language)
• Minneapolis–St. Paul (2 cities) vs. Wilkes-Barre (1 city named after Wilkes and Barre)
• John Lennard-Jones, an individual named after two families

The en dash in all of the compounds above is unspaced.

--JorisvS (talk) 22:23, 3 January 2014 (UTC)

Does the silence mean that it is correct this way? --JorisvS (talk) 10:37, 7 January 2014 (UTC)

No. Tony (talk) 09:05, 10 January 2014 (UTC)

Then tell what's wrong! Let's correct it and build something better! --JorisvS (talk) 09:00, 11 January 2014 (UTC)

Definite improvement. Unless there's s.t. specifically wrong, I say we go for it. — kwami (talk) 06:13, 21 January 2014 (UTC)

It looks good to me, too. Removing the "single entity", which is too broad and ambiguous to be useful, is probably a good step. Tony, tell us what you're thinking. Dicklyon (talk) 06:26, 21 January 2014 (UTC)

Proposed change

Per the above discussion, I suggest changing:

A hyphen is used by default in compounded proper names of single entities.

• Guinea-Bissau; Bissau is the capital, and this distinguishes the country from neighboring Guinea
• Wilkes-Barre, a single city named after two people, but Minneapolis–Saint Paul, a union of two cities
• John Lennard-Jones, an individual named after two families

to:

An en dash is used to indicate separateness of the names, but a hyphen is used to indicate unity.

• Hindi–Urdu controversy (a dispute between Hindi and Urdu) vs. Hindi-Urdu (an alternative name for the Hindustani language)
• Minneapolis–St. Paul (two cities) vs. Wilkes-Barre (one city named after Wilkes and Barre)
• John Lennard-Jones, an individual named after two families

--JorisvS (talk) 14:20, 21 January 2014 (UTC)

For the sake of consistent formatting, may I suggest:

An en dash is used to indicate a conjunction of separate entities or concepts; a hyphen is used to indicate unity of a single entity or concept formed by combining multiple names.

• Hindi–Urdu controversy (a dispute between Hindi and Urdu); but Hindi-Urdu (an alternative name for the Hindustani language)
• Minneapolis–St. Paul (a union of two cities); but Wilkes-Barre (one city named after Wilkes and Barre)
• John Lennard-Jones (an individual named after two families)

I'm not sure the words "separateness" and "unity" made the distinction clear, so I've suggested alternate wording for the introductory line, too. —sroc 💬 14:48, 21 January 2014 (UTC)

Yes, I think that looks better. Thank you. --JorisvS (talk) 16:04, 21 January 2014 (UTC)

• Support: Looking good to me, the examples are better and it's more easily understandable. Also, the numbers are now spelled out. :) However, let's wait to see the feedback from more editors. — Dsimic (talk) 03:19, 22 January 2014 (UTC)
• Support for sroc's change, for the reasons given by Dsimic.—DocWatson42 (talk) 18:42, 22 January 2014 (UTC)
• Support improved wording by User:Sroc. People, please join this discussion! --JorisvS (talk) 08:22, 27 January 2014 (UTC)

The way I was taught the typographic use of a en dash, is that it's showing some sort of relationship between two things. Hence "Human–Computer Interaction" and use in page ranges. That makes sense to me as an explanation of the above examples as well. Well, except Minneapolis–St. Paul, that's an odd one. Arguably that the combination of the two cities represents their close relationship. SamBC(talk) 19:08, 22 January 2014 (UTC)

• Comment: I agree in principle with the distinction between separation (Hindi–Urdu controversy, Hindi and Urdu are separate literary registers and/or languages) and unity (John Lennard-Jones is one individual), but I see problems with the examples:

1. Minneapolis–St. Paul is not "a union of two cities" - it is "the most populous urban area ... composed of 182 cities and townships ... its two largest cities, Minneapolis, ... and Saint Paul". Ie it is a single urban area that includes the two named cities and 180 others cities/towns. Perhaps Minneapolis–St. Paul is a good example (named after two separate cities), but it is poor and misleading description.
2. Not shown in the proposed change, but immediately above in MOS:ENDASH is "En dash is used ... Comet Hale–Bopp ...(discovered by Hale and Bopp)." Yes the comet was named after two people, but generally Hale-Bopp is the common name of a single comet. Why does a single comet have an en dash when a single city (Wilkes-Barre), also named after two people, have a hyphen? Do you intend to delete/replace the existing sentence and examples "An en dash is used for the names of two or more people in an attributive compound..."? The "proposed change" didn't say so.

Mitch Ames (talk) 13:34, 28 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.

1. 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.
2. 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".
3. 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. 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 Misplaced Pages, 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 Misplaced Pages (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)

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 Misplaced Pages 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, January 7, 2014 (UTC)

Well, I asked that question at list of municipalities in Manitoba, and I was told that it "avoid the unnecessary white space that comes with the default left-aligned TOC format, and the entire TOC, or as much as possible, 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, January 7, 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 Misplaced Pages:Manual of Style/Layout, to which Misplaced Pages: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 Misplaced Pages:Manual of Style/Lead section)". Is there any reason why we can't put "(see Misplaced Pages: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 Misplaced Pages 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 Misplaced Pages 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)

Loftus William Jones

Hi, I wasn't sure what should be done with the large (overlarge?) quote on this page; given that the Telegraph reference (which I possess from the paper) gives a detailed account, would I be justified in removing the quote from the article? Thanks, Matty.007 12:52, 11 January 2014 (UTC)

I'd suggest going to List of Victoria Cross recipients (A–F) or one of the similar articles and looking at some of the other individuals who have won the Victoria Cross. Then duplicate a format that seems standard for those articles. There might be more specific advice, and real experts in this issue, at Misplaced Pages:WikiProject Biography/Military. Keep up the good work. SchreiberBike talk 22:20, 12 January 2014 (UTC)

Do you mean the VC citation from the London Gazette? Yes, it should absolutely be retained. It's the entire basis for his notability. -- Necrothesp (talk) 10:00, 13 January 2014 (UTC)

OK, thank you. Necrothesp, I know, but is it better to rephrase it from the Telegraph source, or keep in the long quote? Thanks, Matty.007 18:18, 13 January 2014 (UTC)

I would say keep the original citation. No problem with that. -- Necrothesp (talk) 08:34, 14 January 2014 (UTC)

Italics within quotations: 2 suggestions

From the main article: "Use italics within quotations if they are already in the source material. When adding italics on Misplaced Pages, add an editorial note after the quotation. 'Now cracks a noble heart. Good night sweet prince: And flights of angels sing thee to thy rest' . If the source has used italics (or some other styling) for emphasis and this is not otherwise evident, the editorial note should appear after the quotation." SUGGESTIONS: I won't make these changes, but if anyone else agrees/wants to, how about we delete "on Misplaced Pages". Then, consider changing "should appear" to "may appear" since otherwise the whole thing would seem like a redundancy with "emphasis added", if it were ALWAYS necessary to indicate when it was not added. It seems that "emphasis in original" is a somewhat subjective editorial decision based on, whether explicit or not, what the context calls for. — Preceding unsigned comment added by BobEnyart (talk • contribs) 17:57, 13 January 2014 (UTC)

RFC: Month abbreviations

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Misplaced Pages style and naming Misplaced Pages policies and guidelines When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

1. Shall month abbreviations be limited to the first three characters of the month, or may a fourth character be used?
2. May a month abbreviation be followed by a full stop when it is not at the end of a sentence?
3. 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.

1. 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).
2. For the rest: should abbreviated month names (including a period) be: a) allowed, b) disallowed, or c) no position?
3. If abbreviated month names are allowed, may they use four characters (e.g.: "Sept.")?
4. 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 ] 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:

1. consolidate the grouped questions into a single statement / question
2. 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 Misplaced Pages 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 Misplaced Pages 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)

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  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)

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, Misplaced Pages 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)

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)

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

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Misplaced Pages style and naming Misplaced Pages policies and guidelines When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

In reference to this edit:

Previous discussions:

• Wikipedia_talk:Manual_of_Style/Archive_150#En_dashes_rather_than_hyphens_for_both_prefixed_and_suffixed_adjective_phrases.
• Wikipedia_talk:Manual_of_Style/Archive_140#En_dashes_and_suffixes

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 Misplaced Pages 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 Misplaced Pages) 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 (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)

{{collapse top|1=(apparent joke)}}

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 Misplaced Pages 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

Split off from the section above, for improved readability.

Isn't it simply a proposal to change (within Misplaced Pages: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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages: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 Misplaced Pages at all, or at least not in its current shape and size. — Dsimic (talk | contribs) 04:01, 27 January 2014 (UTC)

Of course Misplaced Pages 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)

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).

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 Misplaced Pages 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 Misplaced Pages. 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)

MOS outside the MOS

More a comment than anything, I have been trawling through all the 'MOS:' shortcuts, and found that only the following are not linked to either 'Manual of Style' pages, or pages that are essentially part of the MOS (like naming convention policies):

• Misplaced Pages:Trinidad and Tobago Wikipedians' notice board/Style guide (MOS:TT)
• Misplaced Pages:Film project (MOS:FILMPROJECT)
• Misplaced Pages:WikiProject Anthroponymy/Standards (MOS:APO)
• Misplaced Pages:WikiProject Judaism/Manual of Style (MOS:JEW, MOS:JESUS)
• Misplaced Pages:WikiProject Computer science/Manual of style (MOS:CODE, MOS:CODESAMPLE , MOS:SOURCECODE , MOS:ALGO, MOS:ALGORITHM, MOS:ALGORITHMS, MOS:PSEUDO, MOS:PSEUDOCODE, MOS:SOURCE, MOS:SYNTAX, MOS:CODESAMPLES, MOS:CS & MOS:COMPSCI)

They all have 'WP:' shortcut equivalents (e.g. WP:PSEUDOCODE, however WP:PSEUDO is not aligned with MOS:PSEUDO), and most of those guides list those WP: shortcuts instead of the MOS: shortcuts. I think the Comp Sci MOS might have a few too many MOS: shortcuts, and the idea of 'JESUS' redirecting to the MOS defined by WikiProject Judaism is interesting. Has any of these WikiProject MOS topics been covered in the 'real'/centralised MOS? John Vandenberg 16:45, 14 January 2014 (UTC)

Misplaced Pages:Styletips

Misplaced Pages:Styletips provides editing advice in conveniently small portions. (I am mentioning it here to increase awareness.)
—Wavelength (talk) 17:50, 14 January 2014 (UTC)

MOS shortcuts nominated for deletion

I have nominated 11 (eleven!) MOS-related shortcuts for deletion at Misplaced Pages: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 03:48, 15 January 2014 (UTC)

I've nominated another three (3!) MOS-related shortcuts for deletion at Misplaced Pages: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 14:08, 15 January 2014 (UTC)

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

Proposal to change MOS:TM

Comments are invited at Misplaced Pages talk:Manual of Style/Trademarks#Proposed change. --Rob Sinden (talk) 09:01, 16 January 2014 (UTC)

When to use country subdivisions and when not

There is a discussion on the WikiProject Cycling about when to use country subdivisions (states, provinces, regions etc.) and when not, when listing a cyclist's birth place in an infobox. Example:

• Amsterdam, North Holland, Netherlands or Amsterdam, Netherlands
• Silver Spring, Maryland, U.S. or Silver Spring, U.S.

We seem to agree that in some cases this is appropriate (the Silver Spring case) and in some cases it is not (the Amsterdam case). I have tried to look for something in the MoS or in the discussion archives, but I was unable to find anything. Is there some agreement within Misplaced Pages on for which countries the subdivisional entity should be mentioned and for which it should be avoided? Or is there a rule that says always use subvision or never use subdivision that I am unable to find?--EdgeNavidad (Talk · Contribs) 17:41, 16 January 2014 (UTC)

Page length

2013 in film is 332,397 bytes (without images). Please discuss whether or not to sub-divide it, at Talk:2013 in film#Length. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 16 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, in Smallville, Fictionland, 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.

• 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.

• 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.

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 Misplaced Pages 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)

Proposal that MOS should cover Portals

There is currently an RFC on a proposal to update MOS to explicitly state that it covers Portals - Misplaced Pages:Village pump (policy)#Proposal: MOS should apply to portals. Editors are invited to contribute to the discussion there. Mitch Ames (talk) 08:17, 19 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 Misplaced Pages: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)

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)

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)

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 Misplaced Pages: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.

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)

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)

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 Misplaced Pages 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 Misplaced Pages. 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 Misplaced Pages 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 ]. 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 Misplaced Pages for protocol relative links. For example, Misplaced Pages: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 Misplaced Pages articles. This would only be done if consensus determines that a change is necessary. EdJohnston (talk) 20:58, 27 January 2014 (UTC)

• Misplaced Pages requests for comment