This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 145 | ← | Archive 149 | Archive 150 | Archive 151 | Archive 152 | Archive 153 | → | Archive 155 |
I propose adding a guideline that states whether the table of contents should be floated left or right. The vast majority of articles have it on the left, while very few have it on the right. I think there's a couple of cases where having on the right works better than having it on the left, but there aren't very many.
Thus, in order to maintain consistency across Wikipedia and affirm long-standing practice, I suggest adding something along these lines to the end of the first paragraph of section 1.2 (Article titles, sections, and heading: Section organization): The table of contents should be floated left unless there is a compelling reason to have it on the right. "Compelling" might be too strong, I suppose. Perhaps "clear", "good", or something else along those lines? AmericanLemming ( talk) 20:20, 6 January 2014 (UTC)
I warmly agree with Blueboar's sensible comment above. I can't immediately think of many overwhelmingly powerful reasons for putting the ToC on the right, but I do remember having put it there and not out of mere capriciousness or the pleasure of getting up the nose of some wiki-cop. In List of photographers, for example, it's now on the left but would require less scrolling on a tablet if it were instead floated on the right, which is where I'd move it right now if it weren't for the minor risk that I'd then be accused here of "pointy" behavior.
Look, the ToC goes near the top, on the left or the right. If you don't see it in one place you'll see it in the other -- it's not as if (like a "featured article" logo) it's something you('d) have to search for. Let it go where editors want to put it. If they argue over it (a rare event), then let the side with the more convincing arguments win.
As it is, I see no convincing argument above for enforcing a left-hand ToC. The request starts in order to maintain consistency across Wikipedia and affirm long-standing practice with no argument for either consistency or conservatism, which seem touted as virtues in themselves. The other voices largely echo the praise for consistency without saying why consistency here is helpful to anyone. Perhaps oddest: It's about a somewhat arbitrary choice of formatting, where consistency is important—the main concern of style manuals. Is consistency important as witnessed by the existence of (inter alia) a University of Chicago Press hardback grimoire of consistency? No, not least because "Chicago" makes no fetish of consistency, which is not its main aim. It does give you pretty clear prescriptions for the use of, say, en dashes; but then these are likely to be used in quantity. The book -- an intelligent one, aside from the newly introduced claptrap on grammar and usage -- is shot through with alternatives and invitations to use one's intelligence and override general guidelines where it is beneficial to do so.
Additionally, what's likely to be a powerful reason why ToCs are largely on the left is that this is simply where they are automatically generated (which, incidentally, is fine with me). Plenty of editors preferring them on the right for some reason (or even for no particular reason, just as they're normally on the left for no particular conscious reason) may not be bothered to locate and digest the recipe for moving them or may not even know that they can be moved. -- Hoary ( talk) 05:24, 11 January 2014 (UTC)
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)
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)
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
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)
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)
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)
MOS:ENDASH provides the following examples:
So, is it:
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)
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)
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:
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)
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)
I have nominated 11 (eleven!) MOS-related shortcuts for deletion at Wikipedia:Redirects for discussion/Log/2014 January 13. (one has already been speedy deleted) I would appreciate input from regulars at MOS. Terima kasih. John Vandenberg ( chat) 03:48, 15 January 2014 (UTC)
I've nominated another three (3!) MOS-related shortcuts for deletion at Wikipedia:Redirects for discussion/Log/2014 January 15. Please join in; in one of these, there is a suggestion to retarget a MOS: shortcut. Sorry for the disruption caused. John Vandenberg ( chat) 14:08, 15 January 2014 (UTC)
Two more MOS shortcuts have been nominated for discussion at Wikipedia:Redirects for discussion/Log/2014 January 25#MOS:FOLLOW. John Vandenberg ( chat) 03:22, 27 January 2014 (UTC)
MOS:COMMA currently states:
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:
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:
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.:
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)
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)
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)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)
@ 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)
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:
Tony (talk) 04:14, 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:
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:
Now, if that sentence were included in a WP article, how would you punctuate it? Here's one option:
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:
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)
Of course such examples occur. Writing down a sentence someone has spoken, we might come up with this:
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:
Tony (talk) 10:25, 27 January 2014 (UTC)
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)
Maybe trivia, but a edit war erupted over the question about if one should use the HTTPS or HTTP protocol for use in a official EL link. In this particularly case, verifiability might be used to prove if one is "more official" than the other, but it really seems to boil down to a Wikipedia editing style question rather than a actually content question. The only sure way to know for sure which protocol is the official one is if the site has a HTTP link=canonical field (like described in stackoverflow on transition to SSL and regards to SEO, and that is commonly only done by websites for SEO concerns. For every other site, it will basically be a arbitrary decision, which is why I think a general guideline in the MOS could help. Belorn ( talk) 14:36, 27 January 2014 (UTC)
//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)
//thepiratebay.se
. I thought it was only a wikipedia concept by reading [
[1]]. I see now it work with any url and not just wikipedia and its sister projects. Thank you. It might be a good idea to reword that page, so the intro do not say "from a Wikimedia page to other Wikimedia page".There is an active discussion taking place at Template talk:Track listing#Collapsibility, where the advice at MOS:COLLAPSE and its applicability to that template are being discussed. Please comment there if you have time. — Martin ( MSGJ · talk) 16:14, 28 January 2014 (UTC)
I'm about to start a conversation over at WT:FAC on putting together a word usage guide based on some subset of Wikipedia articles. I know there's interest at FAC ... I don't know if there's interest anywhere else, but I hope there is, and I don't have any preconceptions that the guide has to be based just on word usage in Featured Articles. Please join us. - Dank ( push to talk) 14:36, 31 January 2014 (UTC)
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)
‑
is as effective as "{{
hyphen}}", then a brief comment about usage can be added to the guideline "Non-breaking".|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)
{{cite book}}
be addressed and "corrected".{{cite book}}
, which is probably the primary offender of unnoticed invalid corrections.{{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.{{cite book}} |pages=
. Here are some examples. The last example shows its limitation.User Input | Parsed or Corrected | Comment | |
---|---|---|---|
|pages=3-15 | → | |pages=3—15 | A range of 13 pages |
|pages=3-1-3-15 | → | |pages=3-1—3-15 | The first 15 pages of chapter 3 |
|pages=3-15, 17-12 | → | |pages=3-15, 17-12 | Just two pages: 17-12 cannot be a range, so the book and all its pages must use the Ch-Pg numbering scheme |
|pages=3-15, 17-19 | → | AMBIGUOUS | This could be either (a) just two pages (like the previous example), or (b) a range of 13 pages plus a range of 3 more pages |
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)
In reference to this edit:
Previous discussions:
Can people say if they agree with this or not, and close it one way or other? -- Enric Naval ( talk) 18:48, 13 January 2014 (UTC)
This is an odd inconsistency in the MOS. It's intentional, though: Some people insisted on making suffixes an exception because they "look bad" when dashed. But recently I've noticed that The Week reliably uses en dashes in such situations. The Week is targeted to a broad audience, much as WP is, is designed to be as accessible as possible, and publishes in both the US and UK. (I've seen the US edition.) I haven't been collecting examples, though. — kwami ( talk) 18:11, 16 January 2014 (UTC)
Skimming the latest I have, no. 13:650 (2013-12-31), for all en dashes: Tea Party–related [groups] (p 4), 1.8 million–year-old skull (p 9), post–Hurricane Katrina nightmare (p 11), the city's first New England–style seafood shack (p 13), the "Paul Simon–esque" Afro rhythms (p 14), $85 billion–a-month bond-buying program (p 22), the Fort Worth–based airline (p 23), Nobel Prize–winning Irish poet, Nobel Prize–winning author, & Tony Award–winning stage and film actress (p 24), the National Geographic–supported expedition (p 31).
I see two patterns here: Proper names, which do not take hyphens, and compounded digit-word numbers, which I myself would probably just double hyphenate. Clearly The Week would dash "Academy Award–winning" and "World War II–era". I don't know about "Linux kernel–based", though. This is equivalent to credit card–sized, which came from a style manual, and of The Week examples, closest to $85 billion–a-month: X-Y Z becomes X–Y Z when X is more than one word, like "credit card" or "$85 billion", which would mean that the capitalization of "Academy Award–winning" is a cue but not the reason for the dash. — kwami ( talk) 18:54, 16 January 2014 (UTC)
( 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)
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)}}
{{collapse bottom}} –See "collapse top". - Wikid77 13:41, 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)
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)
Split off from the section above, for improved readability.
Isn't it simply a proposal to change (within Wikipedia:Manual_of_Style#En_dashes:_other_uses) this:
To this:
startswithj ( talk) 03:46, 22 January 2014 (UTC)
Split off from the section above, for improved readability.
Are we all Ok to have this in the end?
Please vote. — Dsimic ( talk) 01:36, 25 January 2014 (UTC)
The change runs against what was ironed out as a coherent suite of uses for the en dash, with wide and extensive community consultation in 2011. Since I don't have previous editions of CMOS at hand (nor by online subscription), I asked Noetica to look them up in relation to this proposal. I found the history interesting: Using an en dash with exactly the same meaning as a hyphen, but in special contexts, is almost exclusively a US invention – and a recent one at that. It first turned up as an option in CMOS12 (1969), where the examples (at 5.91) are all with prefixes ("post–Civil War period") or have two more or less equal elements combined ("New York–London flight"). There's no mention of suffixes, or examples of such a use, though prefixes are specifically mentioned in Table 6.1, with examples there and at 5.91.
CMOS13 (1982) reproduces the advice (at 5.94), and makes specific mention of prefixes (but not of suffixes, and no examples for them) at its Table 6.1. Same in CMOS14 (1993) where 5.117 gives virtually the same advice, with nothing on suffixes; and in Table 6.1: "When a prefix is added to an open compound, the hyphen becomes an en dash" (p. 230). Even CMOS15 (2003) sticks to that line (see 6.85, with no suffixes). It dispenses with the table, replacing it with section 7.90 where the ruling is still focused on prefixes: "pre–Vietnam War (before an open compound, an en dash is used; see 7.83)" (p. 307). [But in fact 7.83 says nothing about en dashes <sigh>.]
Only with CMOS16 (2010, current edition) do we get two suffix examples (at 6.80). The first three examples in that section: "the post–World War II years" "Chuck Berry–style lyrics" and "country music–influenced". Introducing these ("it should be used sparingly, and only when a more elegant solution is unavailable"), CMOS makes an extraordinary claim: "As the first two examples illustrate, the distinction is most helpful with proper compounds, whose limits are established within the larger context by capitalization." But this is nonsensical. If the capitals already mark "World War II" and "Chuck Berry" as recognised units—that is, we must never put a hyphen in them—why is an en dash called for when these units enter into compounds? Because of its capitals, hyphenated "Chuck Berry-style lyrics" is instantly understood—without resort to this Chicago novelty that some US writers embrace as an 11th commandment (and the rest of the world gets by brilliantly without, and does not understand).
CMOS16 continues: "The relationship in the third example, though clear enough, depends to some small extent on an en dash that many readers will perceive as a hyphen connecting music and influenced." Um ... so why bother to use that en dash? And what's unacceptable about "country-music-influenced" anyway? Why is "country music" not hyphenatable? It isn't what CMOS16 delights in calling a "proper compound"; so a two-hyphen solution is fine, one presumes ...
In sum, this use of an en dash is accepted on WP as a concession to US regionalism, just as it's hedged and mixed up in CMOS16. Chicago's weird decision for this use of the en dash fits with its avoidance of other uses that are common in the rest of the anglophone world (such as "US–Canada relations": CMOS wants "US-Canada relations" though it wants "United States–Canada relations", which all starts to get messy compared with our simpler guideline). To transplant that decision into Wikipedian style, where the background decisions are not CMOS-bound, would be inappropriate for our worldwide readership.
Tony (talk) 12:49, 25 January 2014 (UTC)
An edit war has broken out at Elevator (an article written in American English) over whether the lead image, which depicts two of these devices in London that are clearly labelled "lifts" (the British English term for an elevator) should be captioned "lifts" or "elevators". I have semi-protected the article, but the discussion needs more input. Please comment at Talk:Elevator#semi-protection. Thryduulf ( talk) 23:27, 5 February 2014 (UTC)
Is it normal/accepted to do this? Or is there a better approach? Splash - tk 00:14, 6 February 2014 (UTC)
We have an edit war going on at WP:NUM concerning the formatting of a template that's now being used directly in the MOS. This is dangerous: The MOS should be formatted manually. Otherwise changes in a formatting template will change the MOS without any discussion or consensus on the MOS. (The template did not conform to the MOS, though it claimed to; now that it's embedded in the MOS, the MOS conforms to the template, which has things backwards.) Thought I should mention it here for those of you who aren't watching that page. — kwami ( talk) 00:23, 13 February 2014 (UTC)
any input is welcome at Talk:Qumran#Collapsible_bibliography concerning the collapsible section headings presented here. thank you. Frietjes ( talk) 16:36, 13 February 2014 (UTC)
{{Collapse top}}
+ {{Collapse bottom}}
looks much better if collapsibility is the primary goal, as the collapsible area is clearly marked. —
Dsimic (
talk |
contribs) 18:50, 13 February 2014 (UTC)In Wikipedia:REFPUNC#Punctuation_and_footnotes, the wording
does not parse easily and can thus lead to unintended interpretation. May I suggest that addressing the relative positioning of the punctuation and the ref tags be moved to a separate sentence? — Quondum 17:34, 16 February 2014 (UTC)
As noted here on my talk page, the talk page at WP:Content forking is highly inactive. Therefore, I am seeking outside input from here for the following matter: Wikipedia talk:Content forking#Obligatory thread - making POVFORK less anti-AGF. Flyer22 ( talk) 17:05, 18 February 2014 (UTC)
There have been several edits recently at WP:MOS over whether seasons in the northern and southern hemispheres are "opposite" or just "different". FWIW, I'd say they're "reversed". - Dank ( push to talk) 13:10, 2 February 2014 (UTC)
I am having trouble understanding what is desired, without any examples of what not to do in red, it is almost as if anything is acceptable. Furthermore, the use of pronouns is not clear. For instance, Biblically speaking, in regards to those who went, is "they" used as a gender neutral substitute for she/he? Or does it signify that other than Martha, more than one person came? - Dirtclustit ( talk) 04:51, 15 February 2014 (UTC)
This RFC has three separate but related parts and my closure will address these parts individually as part of the whole discussion. It should be understood that abbreviated months are allowed only in certain circumstances. This RFC did not address various circumstances, rather clarifies usage when those circumstances arise. The first part of the RFC, about limiting characters, shows consensus in favor of using only the first three characters, mostly for consistency, but also to keep the shortened version as short as possible. The second part of the RFC, about full stop, shows consensus against using the full stop, specifically to shorten the text. The third part of the RFC, about the MOS's agreeing, shows obvious consensus that all MOS's should agree and not be contradictory. The consensus shows the changes in the relevant manuals should reflect the outcome of this RFC. In summation, there is overall consensus, in certain circumstances, that when it is necessary to shorten a month, the month should be shortened to the first three characters with no full stop and this should be reflected in the two relevant MOS's. Cheers, TLSuda ( talk) 21:44, 4 April 2014 (UTC)
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)
This discussion appears to have reached its conclusion, and the RFC is more than a month old. How do we close it officially? I am new to RFCs, so I don't know the formalities. – Jonesey95 ( talk) 23:41, 15 February 2014 (UTC)
#time
}} parser function gives us (so we're sort-of stuck with it anyway). If we do allow the dot, though, we should at least recommend consistency within an article, i.e. give editors a choice between two specific styles: three-letter-no-dot or three-or-four-letter-dot-or-no-dot (i.e. Jan., Feb., Mar., Apr., May, June, July, Aug., Sept., Oct., Nov. & Dec.).
Jimp 09:50, 6 February 2014 (UTC)The manual on mdash was inconsistent: it first says "use one or the other consistently in an article" and then shortly after it said "do not use spaced em dashes". Can we please have clarity. — RHaworth ( talk · contribs) 19:09, 22 February 2014 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 145 | ← | Archive 149 | Archive 150 | Archive 151 | Archive 152 | Archive 153 | → | Archive 155 |
I propose adding a guideline that states whether the table of contents should be floated left or right. The vast majority of articles have it on the left, while very few have it on the right. I think there's a couple of cases where having on the right works better than having it on the left, but there aren't very many.
Thus, in order to maintain consistency across Wikipedia and affirm long-standing practice, I suggest adding something along these lines to the end of the first paragraph of section 1.2 (Article titles, sections, and heading: Section organization): The table of contents should be floated left unless there is a compelling reason to have it on the right. "Compelling" might be too strong, I suppose. Perhaps "clear", "good", or something else along those lines? AmericanLemming ( talk) 20:20, 6 January 2014 (UTC)
I warmly agree with Blueboar's sensible comment above. I can't immediately think of many overwhelmingly powerful reasons for putting the ToC on the right, but I do remember having put it there and not out of mere capriciousness or the pleasure of getting up the nose of some wiki-cop. In List of photographers, for example, it's now on the left but would require less scrolling on a tablet if it were instead floated on the right, which is where I'd move it right now if it weren't for the minor risk that I'd then be accused here of "pointy" behavior.
Look, the ToC goes near the top, on the left or the right. If you don't see it in one place you'll see it in the other -- it's not as if (like a "featured article" logo) it's something you('d) have to search for. Let it go where editors want to put it. If they argue over it (a rare event), then let the side with the more convincing arguments win.
As it is, I see no convincing argument above for enforcing a left-hand ToC. The request starts in order to maintain consistency across Wikipedia and affirm long-standing practice with no argument for either consistency or conservatism, which seem touted as virtues in themselves. The other voices largely echo the praise for consistency without saying why consistency here is helpful to anyone. Perhaps oddest: It's about a somewhat arbitrary choice of formatting, where consistency is important—the main concern of style manuals. Is consistency important as witnessed by the existence of (inter alia) a University of Chicago Press hardback grimoire of consistency? No, not least because "Chicago" makes no fetish of consistency, which is not its main aim. It does give you pretty clear prescriptions for the use of, say, en dashes; but then these are likely to be used in quantity. The book -- an intelligent one, aside from the newly introduced claptrap on grammar and usage -- is shot through with alternatives and invitations to use one's intelligence and override general guidelines where it is beneficial to do so.
Additionally, what's likely to be a powerful reason why ToCs are largely on the left is that this is simply where they are automatically generated (which, incidentally, is fine with me). Plenty of editors preferring them on the right for some reason (or even for no particular reason, just as they're normally on the left for no particular conscious reason) may not be bothered to locate and digest the recipe for moving them or may not even know that they can be moved. -- Hoary ( talk) 05:24, 11 January 2014 (UTC)
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)
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)
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
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)
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)
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)
MOS:ENDASH provides the following examples:
So, is it:
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)
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)
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:
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)
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)
I have nominated 11 (eleven!) MOS-related shortcuts for deletion at Wikipedia:Redirects for discussion/Log/2014 January 13. (one has already been speedy deleted) I would appreciate input from regulars at MOS. Terima kasih. John Vandenberg ( chat) 03:48, 15 January 2014 (UTC)
I've nominated another three (3!) MOS-related shortcuts for deletion at Wikipedia:Redirects for discussion/Log/2014 January 15. Please join in; in one of these, there is a suggestion to retarget a MOS: shortcut. Sorry for the disruption caused. John Vandenberg ( chat) 14:08, 15 January 2014 (UTC)
Two more MOS shortcuts have been nominated for discussion at Wikipedia:Redirects for discussion/Log/2014 January 25#MOS:FOLLOW. John Vandenberg ( chat) 03:22, 27 January 2014 (UTC)
MOS:COMMA currently states:
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:
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:
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.:
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)
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)
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)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)
@ 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)
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:
Tony (talk) 04:14, 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:
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:
Now, if that sentence were included in a WP article, how would you punctuate it? Here's one option:
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:
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)
Of course such examples occur. Writing down a sentence someone has spoken, we might come up with this:
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:
Tony (talk) 10:25, 27 January 2014 (UTC)
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)
Maybe trivia, but a edit war erupted over the question about if one should use the HTTPS or HTTP protocol for use in a official EL link. In this particularly case, verifiability might be used to prove if one is "more official" than the other, but it really seems to boil down to a Wikipedia editing style question rather than a actually content question. The only sure way to know for sure which protocol is the official one is if the site has a HTTP link=canonical field (like described in stackoverflow on transition to SSL and regards to SEO, and that is commonly only done by websites for SEO concerns. For every other site, it will basically be a arbitrary decision, which is why I think a general guideline in the MOS could help. Belorn ( talk) 14:36, 27 January 2014 (UTC)
//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)
//thepiratebay.se
. I thought it was only a wikipedia concept by reading [
[1]]. I see now it work with any url and not just wikipedia and its sister projects. Thank you. It might be a good idea to reword that page, so the intro do not say "from a Wikimedia page to other Wikimedia page".There is an active discussion taking place at Template talk:Track listing#Collapsibility, where the advice at MOS:COLLAPSE and its applicability to that template are being discussed. Please comment there if you have time. — Martin ( MSGJ · talk) 16:14, 28 January 2014 (UTC)
I'm about to start a conversation over at WT:FAC on putting together a word usage guide based on some subset of Wikipedia articles. I know there's interest at FAC ... I don't know if there's interest anywhere else, but I hope there is, and I don't have any preconceptions that the guide has to be based just on word usage in Featured Articles. Please join us. - Dank ( push to talk) 14:36, 31 January 2014 (UTC)
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)
‑
is as effective as "{{
hyphen}}", then a brief comment about usage can be added to the guideline "Non-breaking".|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)
{{cite book}}
be addressed and "corrected".{{cite book}}
, which is probably the primary offender of unnoticed invalid corrections.{{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.{{cite book}} |pages=
. Here are some examples. The last example shows its limitation.User Input | Parsed or Corrected | Comment | |
---|---|---|---|
|pages=3-15 | → | |pages=3—15 | A range of 13 pages |
|pages=3-1-3-15 | → | |pages=3-1—3-15 | The first 15 pages of chapter 3 |
|pages=3-15, 17-12 | → | |pages=3-15, 17-12 | Just two pages: 17-12 cannot be a range, so the book and all its pages must use the Ch-Pg numbering scheme |
|pages=3-15, 17-19 | → | AMBIGUOUS | This could be either (a) just two pages (like the previous example), or (b) a range of 13 pages plus a range of 3 more pages |
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)
In reference to this edit:
Previous discussions:
Can people say if they agree with this or not, and close it one way or other? -- Enric Naval ( talk) 18:48, 13 January 2014 (UTC)
This is an odd inconsistency in the MOS. It's intentional, though: Some people insisted on making suffixes an exception because they "look bad" when dashed. But recently I've noticed that The Week reliably uses en dashes in such situations. The Week is targeted to a broad audience, much as WP is, is designed to be as accessible as possible, and publishes in both the US and UK. (I've seen the US edition.) I haven't been collecting examples, though. — kwami ( talk) 18:11, 16 January 2014 (UTC)
Skimming the latest I have, no. 13:650 (2013-12-31), for all en dashes: Tea Party–related [groups] (p 4), 1.8 million–year-old skull (p 9), post–Hurricane Katrina nightmare (p 11), the city's first New England–style seafood shack (p 13), the "Paul Simon–esque" Afro rhythms (p 14), $85 billion–a-month bond-buying program (p 22), the Fort Worth–based airline (p 23), Nobel Prize–winning Irish poet, Nobel Prize–winning author, & Tony Award–winning stage and film actress (p 24), the National Geographic–supported expedition (p 31).
I see two patterns here: Proper names, which do not take hyphens, and compounded digit-word numbers, which I myself would probably just double hyphenate. Clearly The Week would dash "Academy Award–winning" and "World War II–era". I don't know about "Linux kernel–based", though. This is equivalent to credit card–sized, which came from a style manual, and of The Week examples, closest to $85 billion–a-month: X-Y Z becomes X–Y Z when X is more than one word, like "credit card" or "$85 billion", which would mean that the capitalization of "Academy Award–winning" is a cue but not the reason for the dash. — kwami ( talk) 18:54, 16 January 2014 (UTC)
( 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)
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)}}
{{collapse bottom}} –See "collapse top". - Wikid77 13:41, 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)
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)
Split off from the section above, for improved readability.
Isn't it simply a proposal to change (within Wikipedia:Manual_of_Style#En_dashes:_other_uses) this:
To this:
startswithj ( talk) 03:46, 22 January 2014 (UTC)
Split off from the section above, for improved readability.
Are we all Ok to have this in the end?
Please vote. — Dsimic ( talk) 01:36, 25 January 2014 (UTC)
The change runs against what was ironed out as a coherent suite of uses for the en dash, with wide and extensive community consultation in 2011. Since I don't have previous editions of CMOS at hand (nor by online subscription), I asked Noetica to look them up in relation to this proposal. I found the history interesting: Using an en dash with exactly the same meaning as a hyphen, but in special contexts, is almost exclusively a US invention – and a recent one at that. It first turned up as an option in CMOS12 (1969), where the examples (at 5.91) are all with prefixes ("post–Civil War period") or have two more or less equal elements combined ("New York–London flight"). There's no mention of suffixes, or examples of such a use, though prefixes are specifically mentioned in Table 6.1, with examples there and at 5.91.
CMOS13 (1982) reproduces the advice (at 5.94), and makes specific mention of prefixes (but not of suffixes, and no examples for them) at its Table 6.1. Same in CMOS14 (1993) where 5.117 gives virtually the same advice, with nothing on suffixes; and in Table 6.1: "When a prefix is added to an open compound, the hyphen becomes an en dash" (p. 230). Even CMOS15 (2003) sticks to that line (see 6.85, with no suffixes). It dispenses with the table, replacing it with section 7.90 where the ruling is still focused on prefixes: "pre–Vietnam War (before an open compound, an en dash is used; see 7.83)" (p. 307). [But in fact 7.83 says nothing about en dashes <sigh>.]
Only with CMOS16 (2010, current edition) do we get two suffix examples (at 6.80). The first three examples in that section: "the post–World War II years" "Chuck Berry–style lyrics" and "country music–influenced". Introducing these ("it should be used sparingly, and only when a more elegant solution is unavailable"), CMOS makes an extraordinary claim: "As the first two examples illustrate, the distinction is most helpful with proper compounds, whose limits are established within the larger context by capitalization." But this is nonsensical. If the capitals already mark "World War II" and "Chuck Berry" as recognised units—that is, we must never put a hyphen in them—why is an en dash called for when these units enter into compounds? Because of its capitals, hyphenated "Chuck Berry-style lyrics" is instantly understood—without resort to this Chicago novelty that some US writers embrace as an 11th commandment (and the rest of the world gets by brilliantly without, and does not understand).
CMOS16 continues: "The relationship in the third example, though clear enough, depends to some small extent on an en dash that many readers will perceive as a hyphen connecting music and influenced." Um ... so why bother to use that en dash? And what's unacceptable about "country-music-influenced" anyway? Why is "country music" not hyphenatable? It isn't what CMOS16 delights in calling a "proper compound"; so a two-hyphen solution is fine, one presumes ...
In sum, this use of an en dash is accepted on WP as a concession to US regionalism, just as it's hedged and mixed up in CMOS16. Chicago's weird decision for this use of the en dash fits with its avoidance of other uses that are common in the rest of the anglophone world (such as "US–Canada relations": CMOS wants "US-Canada relations" though it wants "United States–Canada relations", which all starts to get messy compared with our simpler guideline). To transplant that decision into Wikipedian style, where the background decisions are not CMOS-bound, would be inappropriate for our worldwide readership.
Tony (talk) 12:49, 25 January 2014 (UTC)
An edit war has broken out at Elevator (an article written in American English) over whether the lead image, which depicts two of these devices in London that are clearly labelled "lifts" (the British English term for an elevator) should be captioned "lifts" or "elevators". I have semi-protected the article, but the discussion needs more input. Please comment at Talk:Elevator#semi-protection. Thryduulf ( talk) 23:27, 5 February 2014 (UTC)
Is it normal/accepted to do this? Or is there a better approach? Splash - tk 00:14, 6 February 2014 (UTC)
We have an edit war going on at WP:NUM concerning the formatting of a template that's now being used directly in the MOS. This is dangerous: The MOS should be formatted manually. Otherwise changes in a formatting template will change the MOS without any discussion or consensus on the MOS. (The template did not conform to the MOS, though it claimed to; now that it's embedded in the MOS, the MOS conforms to the template, which has things backwards.) Thought I should mention it here for those of you who aren't watching that page. — kwami ( talk) 00:23, 13 February 2014 (UTC)
any input is welcome at Talk:Qumran#Collapsible_bibliography concerning the collapsible section headings presented here. thank you. Frietjes ( talk) 16:36, 13 February 2014 (UTC)
{{Collapse top}}
+ {{Collapse bottom}}
looks much better if collapsibility is the primary goal, as the collapsible area is clearly marked. —
Dsimic (
talk |
contribs) 18:50, 13 February 2014 (UTC)In Wikipedia:REFPUNC#Punctuation_and_footnotes, the wording
does not parse easily and can thus lead to unintended interpretation. May I suggest that addressing the relative positioning of the punctuation and the ref tags be moved to a separate sentence? — Quondum 17:34, 16 February 2014 (UTC)
As noted here on my talk page, the talk page at WP:Content forking is highly inactive. Therefore, I am seeking outside input from here for the following matter: Wikipedia talk:Content forking#Obligatory thread - making POVFORK less anti-AGF. Flyer22 ( talk) 17:05, 18 February 2014 (UTC)
There have been several edits recently at WP:MOS over whether seasons in the northern and southern hemispheres are "opposite" or just "different". FWIW, I'd say they're "reversed". - Dank ( push to talk) 13:10, 2 February 2014 (UTC)
I am having trouble understanding what is desired, without any examples of what not to do in red, it is almost as if anything is acceptable. Furthermore, the use of pronouns is not clear. For instance, Biblically speaking, in regards to those who went, is "they" used as a gender neutral substitute for she/he? Or does it signify that other than Martha, more than one person came? - Dirtclustit ( talk) 04:51, 15 February 2014 (UTC)
This RFC has three separate but related parts and my closure will address these parts individually as part of the whole discussion. It should be understood that abbreviated months are allowed only in certain circumstances. This RFC did not address various circumstances, rather clarifies usage when those circumstances arise. The first part of the RFC, about limiting characters, shows consensus in favor of using only the first three characters, mostly for consistency, but also to keep the shortened version as short as possible. The second part of the RFC, about full stop, shows consensus against using the full stop, specifically to shorten the text. The third part of the RFC, about the MOS's agreeing, shows obvious consensus that all MOS's should agree and not be contradictory. The consensus shows the changes in the relevant manuals should reflect the outcome of this RFC. In summation, there is overall consensus, in certain circumstances, that when it is necessary to shorten a month, the month should be shortened to the first three characters with no full stop and this should be reflected in the two relevant MOS's. Cheers, TLSuda ( talk) 21:44, 4 April 2014 (UTC)
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)
This discussion appears to have reached its conclusion, and the RFC is more than a month old. How do we close it officially? I am new to RFCs, so I don't know the formalities. – Jonesey95 ( talk) 23:41, 15 February 2014 (UTC)
#time
}} parser function gives us (so we're sort-of stuck with it anyway). If we do allow the dot, though, we should at least recommend consistency within an article, i.e. give editors a choice between two specific styles: three-letter-no-dot or three-or-four-letter-dot-or-no-dot (i.e. Jan., Feb., Mar., Apr., May, June, July, Aug., Sept., Oct., Nov. & Dec.).
Jimp 09:50, 6 February 2014 (UTC)The manual on mdash was inconsistent: it first says "use one or the other consistently in an article" and then shortly after it said "do not use spaced em dashes". Can we please have clarity. — RHaworth ( talk · contribs) 19:09, 22 February 2014 (UTC)