Wikipedia talk:Manual of Style/Archive 116

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

Archive 110

←

Archive 114

→

Very specific MoS's

copied from Wikipedia_talk:Manual_of_Style_(road_junction_lists)#Remove_from_the_MoS This is a project guideline is every sense of the word . Why should this be part of the MoS which is meant to deal with issues covering large numbers of topics and areas. Removing from the MoS doesn't not affect how this project uses this guideline Gnevin (talk) 19:51, 9 May 2010 (UTC)

This covers a wide range of articles on a global scale. As such, it is the past consensus that it remain a part of the MoS. Imzadi 1979 → 21:48, 9 May 2010 (UTC)

Yes a wide range of articles but all part of WP:ROADS and as such is a project guideline Gnevin (talk) 22:07, 9 May 2010 (UTC)

Are all subject-matter style guidelines being similarly proposed for removal? If not, then this one should not as well. Imzadi 1979 → 22:18, 9 May 2010 (UTC)

Yes they have been removed Gnevin (talk) 22:24, 9 May 2010 (UTC)

Is there going to be an analog to the MoS for a content-specific style guide, a central location for editors to locate content-specific guidelines for the dissemination of content? The advantage to being a part of the MoS is that compliance with these types of style guides was required for Featured Content nominations. Now they're floating out there without the primacy of the MoS stamp to guide their enforcement on "our finest work". Imzadi 1979 → 22:32, 9 May 2010 (UTC)

The analog is Category:Style guidelines of WikiProjects and this guideline still takes its cue from the MoS. Removing this from the MoS doesn't affect Featured Content noms, FA noms should still comply with this guideline . I'm not sure I understand the rest of what your saying . Gnevin (talk) 22:39, 9 May 2010 (UTC)

So MOS:DAB, and Category:Science (Manual of Style) are also going to be removed, seeing as they are project specific? I personally oppose, as this is the first step backwards in unleashing a clusterfuck of vandalism to which we couldn't respond with a part of the MOS. Keep the status quo. - ʄɭoʏɗiaɲ ^τ _¢ 22:41, 9 May 2010 (UTC)

No MOS:DAB covers the entire project and science covers a huge range of fields. How does this being part of the MoS or not affect vandalism ? Vandalism should be reverted on sight as covered by WP:V Gnevin (talk) 22:46, 9 May 2010 (UTC)

(ec) That's a valid point. I don't know what the actual practice for FA nominations is, but of course they should be checking articles with any applicable subject-specific guideline. Category:Style guidelines of WikiProjects currently has 96 members, and while some of them may be obsolete or badly maintained, I guess many of them should really be followed by FAs. I agree that there needs to be a way for FA juries to find all applicable guidelines. Unfortunately the method of simply marking everything as part of the MOS conflicts with current attempts to reduce the MOS to a size that allows everybody to understand it.

I am sure we can find a solution that works for everybody. I think it would be nice to have a central page pointing to all the project guidelines. It would also make sense for the project tags on talk pages to link to the project's guidelines. And ideally all WikiProjects should have prominent links to the specific guidelines most relevant to them. Of course we still need a way to distinguish between those project style guidelines that are considered binding and those that are not. IMO the MOS category isn't particularly good for that purpose, but I guess we must find or create an alternative before removing it here. Hans Adler 22:48, 9 May 2010 (UTC)

How about a content-specific addendum to the MoS? If the main MoS is to be much more generalized in the future, how about creating a companion, a "Supplemental Style Guide" (SSG)? This page could then be moved to WP:Supplemental style guide (road junction lists) along with other style guides that should have a greater primacy than simple wikiproject guidelines. A simple process to vet the promotion of guidelines into the SSG should be easy to put in place.

My one problem with some of the pruning goes to the argument about the size of the MoS. There's no need for editors not working in certain content areas to understand the applicable MoS sections for those areas. Since I don't edit scientific articles, there's no need for me to understand all the ins and outs of Category:Science (Manual of Style) on a day to day basis. If I'm doing a review of an article at FAC in a scientific field, I know that I can find a section of the MoS at that time to consult. If I'm correcting something in my random readings of Wikipedia, and the exact formatting is not right, someone should come along and tweak my edits to conform. The same should be true with editors that don't regularly edit articles that fall under this guideline. If they choose to review one such article that's been nominated at FAC, they should be able to find the applicable sections at the MoS, which has been the current central repository for style guidelines to be enforced on Wikipedia. Imzadi 1979 → 23:18, 9 May 2010 (UTC)

My main concern would be WP:CREEP and the extremely specific nature of most of these guideline it may be hard for outsiders to review but I'm sure something can be worked out Gnevin (talk) 23:57, 9 May 2010 (UTC)

When this was discussed about a month or so ago with Tony1, one comment was made that MOS:RJL could be incorporated into a larger set of MoS guidelines on lists in general, as just one of a few types of specialized lists. In other ways, I don't see the content of MOS:RJL as much different from the MoS section on infoboxes and the like. It's a guide on how to standardize the display of a type of content, albeit one that's a bit more specialized than infoboxes in general. Imzadi 1979 → 00:03, 10 May 2010 (UTC)

Yes, I agree that the content of RJL isn't much different to MoS infoboxes. The key here is one applies to nearly every article on wiki and the other only applies to a tiny percentage. The one's that only apply to a tiny percentage shouldn't be part of the MoS as most users will never have a need to reference them as such I like the idea of a SSG or maybe Manual of Style Specific ? MoSS? MoSS:RJL

Well, I could say that there are more highway articles on Wikipedia than most people realize (10,500+ for the US alone), but the point remains. If content-specific style guides are removed from the MoS, there should be some kind of secondary level of style guide under the MoS to hold them. That will give WP:FA and other processes, and users in general, a location to reference them. Otherwise they will be scattered about in all the WikiProjects, some of which aren't very active of functional. Imzadi 1979 → 00:30, 10 May 2010 (UTC)

Yes, so how about MoSS? Gnevin (talk) 07:59, 10 May 2010 (UTC)

I'm partial to the SSG name, but as long as the end result is the same, I'm all for it. Imzadi 1979 → 08:16, 10 May 2010 (UTC)

I think "SSG" is a better name because it's more distinct from "MOS", avoiding confusion. Hans Adler 08:30, 10 May 2010 (UTC)

Additionally, the name spells out its exact purpose: to supplement the main MoS. Imzadi 1979 → 08:35, 10 May 2010 (UTC)

Thats fine. I was thinking the following would go to SSG

That works for me. So what's the next step? Imzadi 1979 → 08:48, 10 May 2010 (UTC)

Create Wikipedia:Supplemental style guide and outline what we think this will do, how it will interact with the MoS and the FA reviewers will be expected to use it ? Gnevin (talk) 09:05, 10 May 2010 (UTC)

I would need to see a proposed Wikipedia:Supplemental style guide before I could make any sort of decision on if I would support this. While I can understand the reasoning behind this, it seems like it's trying to make some MOSs less important (and therefore less needing to be followed) than others. That will only serve to cause more disputes along the lines of, "Well, that's only a supplemental style guide, so I can ignore it.". ···日本穣^? · 投稿 · Talk to Nihonjoe 09:10, 10 May 2010 (UTC)

I've taken a stab at a very rough draft Gnevin (talk) 09:36, 10 May 2010 (UTC)

Well, my vision is that SSG should be just as "binding" on articles as the main MOS. The difference is that going forward, MOS sections would be applicable to all articles, but SSG sections would apply to a smaller subset. Both together make up the larger Wikipedia style guide as a whole, and both should be followed. Imzadi 1979 → 09:44, 10 May 2010 (UTC)

Same here so I put The SSG is intend to supplement the Manual of Style and as such the SSG should be considered part of the MoS in the intro of my SSG draft Gnevin (talk) 09:49, 10 May 2010 (UTC)

This needs far wider consensus than just you two. Between them these guidelines apply to a vast range of articles, not just those on these subjects, but all those mentioning them in some way. Most parts of the MOS "proper" have narrower applications than these. We should not have rules on to handle religious/scientific/artistic/legal/military issues and terms that apply to articles covered by relevant projects, but not to other articles. That is ridiculous. I strongly oppose this suggestion, and repeat it needs far wider discussion. Johnbod (talk) 10:20, 10 May 2010 (UTC)

Wow way to assume we are just going off on a solo run. This proposal is very much in it beginning stages. We should not have rules on to handle religious/scientific/artistic/legal/military issues and terms that apply to articles covered by relevant projects, but not to other articles. That is ridiculous. Well we already do . This proposal is about moving these rules to a subsection of the MoS so the main MoS is less cluttered . All parts of the MOS proper have a far wide application than these! Gnevin (talk) 10:35, 10 May 2010 (UTC)

What makes you think that subject guidelines only apply to subject-specific articles? This is not the case. If there is a correct term to describe a legal or scientific concept that applies in any article. Project wide application of the MOS is a basic concept. Johnbod (talk) 10:43, 10 May 2010 (UTC)

No one said they apply to subject-specific articles and no one is attempting to limit the scope of the subject-specific guidelines. They apply to all article within the scope of a certain wiki project and in other cases like articles that make use of legal or scientific concepts but for some reason are outside the scope of the wiki project ,they also apply there . However all that considered they are still a small percentage of articles compared to scope of WP:Tables or WP:Layout. I can spend my life on wiki and never edit a article related to ships but you can't avoid layout or tables Gnevin (talk) 10:49, 10 May 2010 (UTC)

You are now contradicting what you said above! Obviously the vast majority of articles avoid tables very successfully, but vast numbers mention things from the very wide subject-areas listed above, without coming under the wiki-project. Johnbod (talk) 10:55, 10 May 2010 (UTC)

How am contradicting what you said above ? And more importantly we aren't changing the scope of these just moving them to a sub group for subject-specific guideline Gnevin (talk) 10:58, 10 May 2010 (UTC)

Your post just above said "we already do" ... "have rules on to handle religious/scientific/artistic/legal/military issues and terms that apply to articles covered by relevant projects, but not to other articles". Then you next post says "No one said they apply to subject-specific articles and no one is attempting to limit the scope of the subject-specific guidelines". Make your mind up please! Johnbod (talk) 11:51, 10 May 2010 (UTC)

To clarify moving to SSG will not affect the scope of these subject-specific guidelines Gnevin (talk) 12:25, 11 May 2010 (UTC)

“If there is a correct term to describe a legal or scientific concept that applies in any article.” Is that supposed to mean that weight should be replaced by mass in the Sumo article, and doughnut-shaped be replaced by toroidal in the Casino Nova Scotia article? A. di M. (talk) 11:46, 15 May 2010 (UTC)

Request for Comment on accepting Subject style guide as a guideline Gnevin (talk) 09:55, 20 May 2010 (UTC)

Tidy up of the text

Nothing controversial, I think. There was a bit of fluff.

But one thing troubles me: "Many points of usage, such as the treatment of proper names, can be decided by observing what other writers do." Errr ... I can't see the point of this: most users, including me, use poor style at least some of the time. Why are we telling people to follow each other? It seems to undermine the rest of the general principles. Tony (talk) 11:47, 17 May 2010 (UTC)

I don't think it means follow each other—it's the "follow the sources" section, after all. I've tweaked to clarify. PL290 (talk) 12:21, 17 May 2010 (UTC)

Thanks. In the "Article titles" section: Do not use a, an, or the as the first word (Economy of the Second Empire, not The economy of the Second Empire), unless by convention it is an inseparable part of a name (The Hague). Why the italics if "a" and "an", etc, are coloured. Is this consistently used throughout the MoS? Tony (talk) 13:20, 17 May 2010 (UTC)

Use–mention distinction? A. di M. (talk) 16:03, 17 May 2010 (UTC)

True, but the colouring does that already (as it is evidently deemed to do in the parenthetical part). PL290 (talk) 16:11, 17 May 2010 (UTC)

The advantage of coloring words that are mentioned but not used, instead of using italics, is we can more easily discuss items that should always be in italics, such as math variables, or should never be in italics, such as unit symbols. Jc3s5h (talk) 16:15, 17 May 2010 (UTC)

That's another good point; indiscriminate use of italics denies us that ability. I've now removed the italics. PL290 (talk) 16:38, 17 May 2010 (UTC)

Actually, no, it's because of Accessibility. We can't use colour alone to make a distinction. If anything, it's the parenthetical part that's wrong. I've reverted my change pending further discussion. PL290 (talk) 16:51, 17 May 2010 (UTC)

If the word-initial caps are meant to distinguish the title "Economy of the Second Empire", they do not do perform that function well at all; how would the colour-blind reader know that the subsequent comma and the word "not" are excluded from the title? I don't mean to cast doubt over the colour-coding: I like it. But it seems hard to create a logical system out of it while adhering to the accessibility rules. Aren't there any colours that colour-blind readers can distinguish for this purpose? Tony (talk) 17:21, 17 May 2010 (UTC)

I don't know, Tony, but the standard line I always see is that we should not rely on colour alone. I like the colours, too, but I think we need to find other ways of making the distinction at the same time. I am guessing that's why the italics are there. If using italics deprives us of another distinction (see above), then perhaps we need to look at other ways, such as quotation marks, linebreaks plus indentation, tables, etc. PL290 (talk) 18:01, 17 May 2010 (UTC)

Wikipedia:Accessibility says it applies to articles. At some point, you have to give up on accessibility for those who work on the infrastructure. I think the guideline is part of the infrastructure, just like the production line that built the computer that the color-blind person uses. Sure, infrastructure should be accessible if it isn't too much trouble, but it's ok to give up on it at some point, just as you require the person who drove the UPS truck who dropped off a computer at a blind person's home to be able to see. Jc3s5h (talk) 17:30, 17 May 2010 (UTC)

Hmm; not sure the analogy goes far enough. However you design the truck, we're not going to see the blind person driving one; here, though, colour-blind editors can potentially contribute to Wikipedia just as others can, and they need to be able to read its style guide (and potentially contribute to that, too). Are we really saying we wish to exclude them? The point at which to do so would surely be when a necessity arose for something that was simply not possible without the use of colour, which can't really be claimed here. PL290 (talk) 18:01, 17 May 2010 (UTC)

Speaking as a color-impaired user (not completely colorblind) I didn't notice the color difference right away, but the font difference is plenty to discriminate between which letters are in the title and what is not. --Joshua Scott (LiberalFascist) 18:29, 17 May 2010 (UTC)

I agree with PL290. We should reserve the use of color alone for those (at present hypothetical) rare cases in which it is truly necessary. As for whether infrastructure should be accessible to color-blind users, I believe that it should be. "Write for your audience" pretty much covers it there. That being said "accessibility" doesn't mean we have to skip color-coding entirely. The current rule on never using it alone should do. Darkfrog24 (talk) 19:21, 17 May 2010 (UTC)

This particular case is nearly obvious even if the colour (and the font change) is not rendered at all: It's hard to misunderstand "Do not use a, an, or the as the first word (Economy of the Second Empire, not The economy of the Second Empire), unless by convention it is an inseparable part of a name (The Hague)", even if it would take longer to parse than the formatted version. As long as colour is only used as an extra rather than relied upon, I think it's fine. A. di M. (talk) 19:45, 17 May 2010 (UTC)

That's an interesting point, and probably a reasonable compromise. I guess we need to look at each case as it comes up, and make sure the same principle applies. Given that {{xt}} and {{!xt}} already use a different font (which helps a bit too), perhaps we should make them use a font (or font size) that contrasts more strongly with the normal text. Personally I find that practice hideous when overdone, which I've encountered in some technical manuals, but maybe there's a perfect ratio. PL290 (talk) 10:50, 18 May 2010 (UTC)

That blind people cannot drive trucks is unavoidable. There is absolutely nothing unavoidable about basic Web accessibility when it comes to writing MoS pages. Chris Cunningham (not at work) - talk 08:55, 18 May 2010 (UTC)

Arbitrary break

What does this statement add in the lead to "Capital letters"?:

"There are differences between the major varieties of English in the use of capitals (uppercase letters). Where this is an issue, the rules and conventions of the cultural and linguistic context apply."

I suggest it be removed, lest it cause confusion among editors. Tony (talk) 07:23, 19 May 2010 (UTC)

The one that springs to mind is colons. But I see there's more here. I suppose the sentence above is an example of how not to summarize a detail page (obfuscates the issue, and provides no link to pertinent section). PL290 (talk) 08:58, 19 May 2010 (UTC)

Well, that brings up whether the claim that there are US/Br differences in colon usage is supportable. This is what it says, currently:

Sometimes, more in American than British usage, the word following a colon is capitalized, if that word effectively begins a new grammatical sentence, and especially if the colon serves to introduce more than one sentence:

The argument is easily stated: We have been given only three tickets. There are four of us here: you, the twins, and me. The twins are inseparable. Therefore, you or I will have to stay home.

No sentence should contain more than one colon. There should never be a hyphen or a dash immediately following a colon.

Can someone justify this assertion? Does anyone think it might enourage an editor to use a cap after a colon unwisely? (I do.) Tony (talk) 09:24, 19 May 2010 (UTC)

Or, to address the question from a different angle, does anyone feel there are strong national (or other) ties to ever doing that? Because if not, perhaps we can agree on a house style not to do it. PL290 (talk) 09:48, 19 May 2010 (UTC)

This sentence could encourage an editor, when a colon introduces several complete sentences, to start the first of them with a capital letter – which is exactly the logical thing to do. If there are any style guides out there in the real world that suggest otherwise, then they are badly broken. The main problem I see with this sentence is that it doesn't say you must, or at least should, do that, and that it even seems to suggest it is somehow wrong in articles written in British English. I don't have the time now to research what style guides actually say about this, but using a small letter in such a context would obviously be the kind of rule that only exists for its own sake, to make things more complicated for the writer, and to mislead the reader. Hans Adler 10:08, 19 May 2010 (UTC)

It is indeed logical; it's not always done that way though (and perhaps more often not done that way; I don't know). I suspect it can also indicate over-complicated prose, or prose that would make its point more clearly using bullets, etc. Perhaps the existing "Sometimes, more in American than British usage" is sufficient then, ideally expanded to explicate and guide. On a side note, I also note that a special case is section titles (as it is in a related discussion on capitalization above). For example, 1958: First unmanned landing. PL290 (talk) 10:26, 19 May 2010 (UTC)

So however it's to be resolved, the current wording is unclear. Yes? Tony (talk) 13:16, 21 May 2010 (UTC)

Volunteers?

I'm involved in style matters at SHIPS these days and won't have time to continue the monthly style updates at WP:Update/2. Can we get any volunteers? You're welcome to use that page or do something completely different. It's not clear to me what pages people will want monthly updates of with the reorganization going on; you'll have to work that out. I'll be happy to help you get started. - Dank (push to talk) 19:12, 19 May 2010 (UTC)

I've been thinking about this. My hunch is that the updates would be better less often. Three times a year, I'd opt for, published in The Signpost (well, they might think that's a boring topic, actually, so somewhere else that is prominent). This might work better for the writer of the updates (you, in this case), and have greater effect on the readers, who will see a more substantial chunk of changes highlighted. Tony (talk) 14:52, 21 May 2010 (UTC)

Great minds and all that, I was just coming over to say much the same thing ... if we can't find another volunteer, I could probably handle 3 or 4 times a year, and maybe that would get a bigger audience, too. How to draw attention is up to you guys. - Dank (push to talk) 14:58, 21 May 2010 (UTC)

I'd be very pleased for it to be mentioned as a link in the "News and notes" section of The Signpost, but their agreement would be necessary. VP and the other usual places too. Tony (talk) 15:24, 21 May 2010 (UTC)

Since I've been boxing everything up and creating new pages twice a year, would either two or four times a year work for you? - Dank (push to talk) 16:00, 21 May 2010 (UTC)

WP:MOS#Numbers as figures or words

"Render numbers greater than nine as figures or, with consistency within each article, render numbers over nine that take two words or fewer to say as words." I've got some unhappy campers at FAC who would like to write "eleven" and "twelve" but not "eighty-three". Is this possible? We have a special problem at SHIPS, in that weapons are often designated by numbers, and "eleven 12-inch and eight 10-inch guns" is easier to read than "11 12-inch and 8 10-inch guns" ... it looks like, under the current wording of MOS, this locks us into having to write out every number under 100 and then some. - Dank (push to talk) 03:09, 22 May 2010 (UTC)

Point 5 in that subsection says the following.

Render differently (with words or figures) adjacent quantities that are not comparable (thirty-six 6.4-inch rifled guns; not 36 6.4-inch rifled guns).

-- Wavelength (talk) 03:28, 22 May 2010 (UTC)

Okay, so you're saying that once you've written out "thirty-six", that doesn't lock you into writing out numbers less than 100, right? Also, as you can imagine, not everyone is on board with only two possible cutoffs, nine and (roughly) 100. Is the consensus firm on that, or is it possible to consistently write out all numbers up to twelve? or twenty? - Dank (push to talk) 03:52, 22 May 2010 (UTC)

Use common sense here. The section is meant for sentences such as "Jane wrote two books on the subjects" vs "Jane wrote 18 books on the subject". Sentences like "eleven 12-inch and eight 10-inch guns"are covered by Wavelength's bullet above. The cutoff at >9 has wiggle room (it is however, the recommended cutoff by most MOSes). Headbomb {talk / contribs / physics / books} 04:30, 22 May 2010 (UTC)

As Headbomb says. Tony (talk) 05:12, 23 May 2010 (UTC)

I've always been a cutoff at >ten man, myself. That is actually the point after which the number names get consistently "long."—DCGeist (talk) 06:16, 23 May 2010 (UTC)

In any event, the cut-off shouldn't be applied to numbers of the same "kind" (FLOABW) in the same context. "Nine pairs of blue socks and 27 pairs of black ones" is worse than either "9 ... 27" or "nine ... twenty-seven". A. di M. (talk) 11:12, 23 May 2010 (UTC)

Thx much. - Dank (push to talk) 12:51, 23 May 2010 (UTC)

Erratum and proposal about unit conversions

The shortcut box says that MOS:CONVERSIONS points to a section here, but it doesn't, it points to MOSNUM. And on the subject, I have a proposal about the wording, almost identical at MOSNUM, that says that you don't have to convert a unit "where inserting a conversion would make a common expression awkward (The four-minute mile)" ... I'd like to add "or linked" after "common". For instance, I'm copyediting an article right now where the editor wrote "BL 13.5-inch (343 mm) Mark V gun" ... as if "BL 13.5 inch /45 naval gun" isn't enough of a mouthful! ... but he's afraid (I'm guessing) that when he gets to FAC someone will fail the article because he didn't convert the units. The thing is, that corrupts the name of the gun ... no one calls it a "BL 13.5-inch (343 mm) Mark V gun", and anyone who wants to know how many millimeters(-res) that is can just click on the link and read it there. In fact, Americans typically say "9 mm" gun and Europeans say "12-inch gun", because the size of the gun doubles as the name of the gun, a name that's more or less universal. It doesn't make sense to me to convert these, since almost no one would know the gun by the converted units, and since the converted units are readily available if you follow the link to any individual gun. - Dank (push to talk) 04:12, 22 May 2010 (UTC)

In this case the "where inserting a conversion would make a common expression awkward" is more than enough to give the wiggle room that editor needs. Here "BL 13.5-inch Mark V gun" is the name of the gun. Compare with "35 mm film", which should never be rendered "35 mm (13.8 in) film". Headbomb {talk / contribs / physics / books} 04:40, 22 May 2010 (UTC)

I'd still like the addition of "or linked", because not many editors will think of "BL 13.5 inch /45 naval gun" as a "common expression", and because the current wording hasn't been successful ... people are still adding conversions in the middle of the linked name of a gun. A lot. - Dank (push to talk) 04:43, 22 May 2010 (UTC)

Support addition. The wording should give room, but making it a bit more clear never hurts. NativeForeigner ^Talk/_Contribs 05:47, 22 May 2010 (UTC)

Okay, we probably would have seen opposition by now if someone felt strongly about it; I left links at WT:MOSNUM, WT:MHC and WT:SHIPS. Making the change; feel free to revert, as always. - Dank (push to talk) 16:45, 22 May 2010 (UTC)

Just to pile on, as these are the names of the guns, conversions are inappropriate. The articles on the guns should give their calibre in the opposite units, however. Nick-D (talk) 08:24, 23 May 2010 (UTC)

Agree the gun is a BL 13.5 inch Mk V naval gun not a BL 13.5-inch (343 mm) Mark V gun, noting that for naval guns that calibre refers to the barrel length not barrel diameter. Such the BL 13.5in Mk V naval gun which is 45 caliber, has a barrel length of 13.5x45 inches = 607.5 inches. Under such circumstance the addition of SI unit is an irrelevant and unnecessary conversion that provides no useful information to the reader. Gnan garra 05:42, 24 May 2010 (UTC)

A new approach

This page is a central point (both for navigation and for discussion). But here's the thing. It doesn't have to be large itself. And it has to stop duplicating detail that's on its subpages. That's a chronic problem that causes chaos, both by making inconsistencies possible between two sets of the same detail, and by leaving users unsure where to find detail. We've talked about summarizing this page, and we've talked about an index, but neither of those seems to quite address the problem to everyone's satisfaction. A third way then: reduce this page to a glorified table of contents. I've created a mock-up to demonstrate how this could work. I've deliberately avoided any real content at this stage. See PL290/MoS for the mock-up. PL290 (talk) 09:09, 22 May 2010 (UTC)

Largeness is not a problem; a practical degree of comprehensiveness is an advantage, because it enables users to find the most important information conveniently in one place.

Duplication is not a problem; duplication is an advantage, because it enables one to find information in two places.

Inconsistencies can be avoided if anyone revising the main page also revises any relevant subsidiary page, and vice versa.

I said "subsidiary page" because "subpage" means something different on Wikipedia. (WP:SP) -- Wavelength (talk) 16:10, 22 May 2010 (UTC)

I think I like this idea but can you expand your example to use real examples so I can fully understand? Gnevin (talk) 16:11, 22 May 2010 (UTC)

Think of it as the same entries as the current ToC has on this main MoS page. I thought it best not to include real entries in the mock-up, so it can illustrate the principle very simply without us getting bogged down in "why have a section on this or that". But if you think it would help, maybe I'll see if it makes sense to expand just a single one of the entries with some detail. PL290 (talk) 16:24, 22 May 2010 (UTC)

Yeah just one example would be helpful to illustrate the concept Gnevin (talk) 16:27, 22 May 2010 (UTC)

OK--I've added a couple of real examples to PL290/MoS (Chronological items, and Numbers). PL290 (talk) 16:48, 22 May 2010 (UTC)

Hmm not what I was thinking . I was expecting you to link to sub MOS parts . Gnevin (talk) 16:57, 22 May 2010 (UTC)

We can decide exactly what to link to. The mock-up just shows the functionality. I've added an comment to to PL290/MoS explaining that you have to click the links to see the effect. PL290 (talk) 17:03, 22 May 2010 (UTC)

My version of this concept Gnevin (talk) 17:41, 23 May 2010 (UTC)

There will be inconsistencies between the main page and subsidiary pages. I suggest a rule that the main page always has priority, and the subsidiary pages can forced to consistency by all means including reversion: the main is the one more editors will consult first; and the main page will show all the implications of all its aspects, including any problems. --Philcha (talk) 19:14, 23 May 2010 (UTC)

Simple solution to inconsistencies don't repeat on the main page what is in a sub page Gnevin (talk) 19:40, 23 May 2010 (UTC)

Wouldn't relocating material from the subpages to the main page solve the inconsistency problem equally well? Darkfrog24 (talk) 23:34, 23 May 2010 (UTC)

In some cases, yes; especially if we can dump the subpage at the same time. It requires an audit one-by-one. Tony (talk) 01:49, 24 May 2010 (UTC)

Inconsistencies can be avoided if each subsidiary page has a summary (of the most important information) transcluded at the top of the page, and if all those summaries are transcluded on the main page. -- Wavelength (talk) 07:00, 24 May 2010 (UTC)

We looked at transcluding summaries before (Hans Adler's mock-up) and yes, that's certainly another approach worth considering if the technical concerns that were then raised are addressed to everyone's satisfaction. But here's the thing: okay, we have broadband most of the time, but there's an attraction in keeping this page (and ideally the constituent parts it links to) organized into smallish peices, giving faster page loads and quick navigation. On a side note, note that PL290/MoS automagically gives backlinks at the top of each page. PL290 (talk) 07:32, 24 May 2010 (UTC)

Transcluding doesn't work both technically and from a user perspective. Yes move the material to main page would also work but the reason we have sub pages was it was felt there was to much information to be kept on the main page Gnevin (talk) 09:21, 24 May 2010 (UTC)

Transcluding does work, both technically and from a user perspective, and is used in various places in the encyclopedia. There were specific concerns raised about using it for this particular purpose, that's all. Best reopen a separate thread if anyone feels the need to reexamine those concerns--let's keep this thread focussed on the non-transcluding approach being discussed, so it has a chance of due consideration and feedback in its own right. PL290 (talk) 09:36, 24 May 2010 (UTC)

I did suggest transclusion of the relevant sections from MOSNUM, last year I think; nothing came of it. The relationship between MOSNUM and MoS main is the biggest issue of all, in terms of keeping the garden neat (i.e., ensuring that the wordings stay the same on both). I have to own up to being responsible for duplicating a whole lot of MOSNUM here when I rewrote MOSNUM in ?2006. It was a popular move—more than I'd anticipated. Why? Because people immediately saw the importance of including advice on dates and numbers at this central location. I think such advice should remain part of MoS main, as long as both gardens are tended with comparison checks every few months.

All this questioning and doubt about MoS main ... I think it's a good page. Heck, if only the Chicago MOS took its own advice and fixed its amateurish glitches. We don't do too badly, really. There's not enough feeling of pride in the MoS.

It's the outlying MoS mess that needs to be addressed more than anything. I was delighted to see Slim Virgin's, Dan Geist's, Gnevin's and others' work on the Words to watch page, not to mention the efforts of others such as Jubilee at the music subpages. We should not be diverted from the task of rationalising the whole category. What is happening about the List mess? Tony (talk) 10:09, 24 May 2010 (UTC)

If we need a central place then we should just seealso the relevant sub topic User:Gnevin/MOS Gnevin (talk) 10:28, 24 May 2010 (UTC)

Sorry, Tony, my description of MoS problems wasn't intended to criticize anyone, but I can quite see how it could be taken that way and I should probably have put it differently. Yes, of course there's a lot to be proud of, and a lot of good work being done on the outlying pages. If we didn't think that, it wouldn't be worth all the effort folks are making to try and see how to jiggle it into just the right shape, structure-wise. The approach I'm suggesting here is one I think has potential, and perhaps others too are able to envisage potential in the crude, tiny mock-up I've created. But it's only one more of many suggestions about tweaking the structure of what we have, to make it more coherent and effective, and to remove the possibility of duplication. PL290 (talk) 16:19, 24 May 2010 (UTC)

Is this title correct Wikipedia:Manual of Style (anime- and manga-related articles)?

Resolved

– Query answered with citation to relevant MOS section.

Should this be Wikipedia:Manual of Style (anime and manga-related articles) ? Gnevin (talk) 21:04, 24 May 2010 (UTC)

It is correct, for it is an ellipsis of "anime-~~related~~ and manga-related articles" nohat (talk) 22:36, 24 May 2010 (UTC)

Ok thanks Gnevin (talk) 22:38, 24 May 2010 (UTC)

See Hyphen#Suspended hyphens and WP:HYPHEN, sub-subsection 3, point 7. -- Wavelength (talk) 22:48, 24 May 2010 (UTC)

Wikipedia:Citing sources

A user has objected to moving this page to Manual of Style (citing sources) saying while it offer stylistic advise it also offers non stylistic advise and as such is part of the MOS but not a sub part. It was my understanding that pages marks as part of the MOS should only offer stylistic advise but maybe I'm wrong . Comments at Wikipedia_talk:Citing_sources#Move please Gnevin (talk) 22:45, 24 May 2010 (UTC)

I have no objection to the MoS branching out. Makes things easier to find. Darkfrog24 (talk) 03:33, 25 May 2010 (UTC)

As long as links don't break, users don't get confused, etc., it really doesn't matter much. How-to material in it should probably be moved to a "Help:"-namespace page, however. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 06:54, 25 May 2010 (UTC)

More advice please

In my gradual tidy-up—here, the "the" issue: researchers at The Ohio State University

Something tells me it's a bad example, and that people would normally say researchers at Ohio State University. Is this hunch correct, and if so, is there a college or university that normally does have "the" in the middle of a sentence, as a better example? Or another institution? Tony (talk) 14:33, 21 May 2010 (UTC)

Well, officially, it is The Ohio State University. Switch it to Michigan State University for a better example. No official "the" there. Imzadi 1979 → 14:36, 21 May 2010 (UTC)

Thanks, but sorry, I want a name where you really must use "The", with capital T. The point is made in the section I've just edited that we should follow the insitution's usage. I guess I could do some googling. Tony (talk) 14:47, 21 May 2010 (UTC)

Ok, sorry, I misread the question here. I can't think of many institutions where a "The" is needed. Most schools of the form "University of X" need a "the" in front of them to flow in the sentence right, but OSU is the only university I know that includes the definitive article as a part of the (official) name. I can't think of many other types of institutions that need a definitive article either. Imzadi 1979 → 15:00, 21 May 2010 (UTC)

The Pennsylvania State University uses the definite article in its name. 75.2.209.226 (talk) 08:06, 25 May 2010 (UTC)

It's too Australia-focused given the Univ. of Sydney already there. I believe The University of Queensland is marching around insisting on the The, even in the middle of sentences, as though there's a carrot stuck up their ass. But who would want to encourage them? Tony (talk) 15:15, 21 May 2010 (UTC)

For an example, you could use "The Hague". Maurreen (talk) 17:09, 21 May 2010 (UTC)

I was the one who originally added this example. Tony, I think my purpose here was exactly the same as yours: The Ohio State University wants an extra The in front, even when it sounds ridiculous. It sounds like The University of Queensland does the same. (I suspect that demanding an extra The correlates with an inflated feeling of importance.) At the time I added this, I tried to think of a better example, but I failed (The Hague doesn't work, because it's not the name of an institution). Ozob (talk) 13:09, 22 May 2010 (UTC)

The British Museum? Tony (talk) 05:10, 23 May 2010 (UTC)

Hmm. But while the British Museum usually takes a "the", they don't ask it to be capitalized—their website has it uncapitalized except at the start of sentences.

Maybe we should replace this whole section with, "Wikipedia does not bow to institutions' egotistical typographic demands. Thus, ohio state university, not The Ohio State University. May they cower before our righteous minuscules!" Ozob (talk) 19:28, 23 May 2010 (UTC)

I would keenly support this. Tony (talk) 02:50, 24 May 2010 (UTC)

Explaining common abbreviations

The abbreviations and acronym section states that when introducing a new name or term in an article, use the full name or term on its first occurrence, followed by the abbreviated form in round brackets. Does that apply to commonly known abbreviations as well? For example, in a sentence of the form the position of research fellow normally requires a doctoral degree, such as a MD (Doctor of Medicine) or a PhD (Doctor of Philosophy), or equivalent work, is it necessary to spell out the MD and the PhD? (The associated RfC is here.) --RegentsPark (talk) 13:01, 24 May 2010 (UTC)

PhD definitely not, because to someone who doesn't know what a PhD is (if there's anyone who doesn't), spelling out "Doctor of philosophy" gives no more information.[1] MD maybe... (For one, I didn't know it, but the expansion allowed me to understand it, whereas the expansion "doctor of philosophy" would only have confused me if I didn't know it beforehand.) A. di M. (talk) 13:10, 24 May 2010 (UTC)

Yes, the trick is in determining the boundary beyond which the proportion of readers who need to google the abbreviation (or type it into our search box) outweighs the cumbersome clutter. NASA, for example, is as well-known throughout the anglosphere as many non-technical words; and it is likely to occur in an article on science. Like the decision to link or not, it requires editors to weigh up readers' needs and the context. There's no easy answer. I think MoS should mention that very common abbreviations, such as "PhD", are usually acceptable without the initial spelling-out. Tony (talk) 13:32, 24 May 2010 (UTC)

Questions. How to handle the use of abbreviation, if the term is only used once in the entire text? Many thanks. Mootros (talk) 18:16, 24 May 2010 (UTC)

If it's something which is much more widely known by the abbreviation than by the spelled-out name (e.g. DNA versus deoxyrybonucleic acid or whatever that's spelt), then use the abbreviation only, linking it if necessary. If they are roughly equally common, use the full name and the abbreviation in parentheses (or symbol in italics): Premiata Forneria Marconi (PFM), the reduced Planck constant ħ. If the full name is much more well-known, just give the full name: quantum mechanics (give the abbreviation QM in parentheses only if you're going to use it again in the article). A. di M. (talk) 07:48, 25 May 2010 (UTC)

That sounds close to it, or at it. Tony (talk) 12:12, 25 May 2010 (UTC)

Recent page moves

I see Gnevin is moving pages into the MoS, such as Wikipedia:Manual of Style (lead section). Has this been agreed, and in particular have we agreed to use brackets and not a slash, as in /lead section? Not using a slash means the pages don't point back to the MoS, which looks odd. SlimVirgin ^{talk contribs} 18:31, 24 May 2010 (UTC)

The poll was open for long enough . I asked should we close and no one objected . So I took it as the majority that was in favour of the status quo and moved. All but 5 have moved and they are listed at Wikipedia:Requested_moves Gnevin (talk) 20:42, 24 May 2010 (UTC)

I suppose if there's no objection it'll be fine, but someone uninvolved should have been asked to close it, especially as moves like this don't boil down only to numbers. SlimVirgin ^{talk contribs} 20:44, 24 May 2010 (UTC)

Not meaning to be rude but i work quite a lot with (or what used to be) WP:record charts... and i knew nothing about this moving of pages. If i had done i would have objected to it. i agree with comments by slimvirgin. :S Lil-unique1 (talk) 20:46, 24 May 2010 (UTC)

Really knew nothing ? Hmm Wikipedia_talk:Manual_of_Style_(record_charts)#MoS_naming_style ....Gnevin (talk) 20:49, 24 May 2010 (UTC)

Just a question: I can't understand what the benefit of using brackets is over Wikipedia:Manual of Style/lead section, which is the usual way of ordering subpages. I don't suppose it really matters, but it would be slightly nicer to have the subpages point back to the main MoS page, which slashes would achieve. Can someone explain in words of one syllable why brackets are better? :) SlimVirgin ^{talk contribs} 20:50, 24 May 2010 (UTC)

There was no benefit really is was a purely stylistic choice Gnevin (talk) 20:52, 24 May 2010 (UTC)

If there's no benefit I wonder why we're doing it that way. Because there is a small benefit the other way, and it seems more intuitive. SlimVirgin ^{talk contribs} 20:59, 24 May 2010 (UTC)

Apologies Gnevin but i honestly didnt see the notice. I would have proposed the same thing as SlimVirgin. I personally would have hoped that if the pages were to be moved they would be named something like: Manual of Style: Record Charts or Manual of Style/Record Charts. – Lil-unique1 (talk) 21:51, 24 May 2010 (UTC)

Count me among the confused. I see that Wikipedia:Record charts has been moved to Wikipedia:Manual of Style (record charts), with the reason provided in the edit summaries as "Consolidating naming per Wikipedia_talk:Manual_of_Style#Poll". Well, if I follow that link I come to a poll which has some !votes, and a bit of discussion and argumentation about ways of doing things, petering off at the end with:

Close

Should we set a time to close this ? Gnevin (talk) 09:59, 20 May 2010 (UTC)"

Nobody answered, so I guess Gnevin decided yes, and then closed it (poll and discussion, both) himself.

Up at the top of that whole section, I see that "The following discussion is closed...." and that the result was "Close as keep status quo"

I'm left wondering, then,

Who decided to close it, and when? There's neither a name nor a close date at the top.
If it was Gnevin who closed, why wasn't somebody less involved recruited to close it?
If the result was "keep status quo", why is anything being moved?

What's going on here? I don't see that a poll was appropriate (it appears to have been contested), or that the poll decided anything, or that the closer fairly decided what the poll's result was (maybe he did, but I can't tell that without reading the whole long thing), or why we're moving things if "we decided" to leave things as they were. — JohnFromPinckney (talk) 22:26, 24 May 2010 (UTC)

Do you object to a particular page move ? Gnevin (talk) 22:33, 24 May 2010 (UTC)

Well just to make clear... i object the moving of record charts as i commented above Lil-unique1 (talk) 22:56, 24 May 2010 (UTC)

The MOS is meant to be a Manual of style not a Loose collection of style . While I accept you would prefer other options. The Manual of Style (foo) naming is preferred and anything claiming to be part of the MOS should be under this banner. Gnevin (talk) 23:06, 24 May 2010 (UTC)

Hmmm the discussion ended in status quo so you've been very bold to move all of the pages as you have done. Something such as MoS has a massive impact upon wikipedia and im not sure its right to take action in the manner you did when there isn't really universal support for it. You should have waited until there was clear consensus that this was the best move ahead. So now that you've started doing it does that mean other subpages e.g. personal sandboxes and archives should be changed from Lil-unique1/Archive 1 to Lil-unique1 (Archive 1)? – Lil-unique1 (talk) 23:32, 24 May 2010 (UTC)

No, nothing but the MOS is affect Gnevin (talk) 23:38, 24 May 2010 (UTC)

See that's another reason why i would have objected the move. subpaging should be equally and consistantly doen throughout the project. Now its already been done it doesn't matter. Moving or changing the pages again would cause too much trouble. Lil-unique1 (talk) 23:42, 24 May 2010 (UTC)

I don't know. I don't think that I object to the move I mentioned and probably I won't. At the moment, I don't know what other pages have been moved, nor why. I was (and still am) primarily confused why we're renaming things to match a supposed consensus of "status quo". While trying to determine that, I had a bunch of procedural questions pop up. More whining later, potentially, after I've educated myself. — JohnFromPinckney (talk) 02:33, 25 May 2010 (UTC)

The foundational consensus was that the titles of all Manual of Style pages should be rationalized to follow a common style. "Status quo" referred to one of the possible styles that was debated—the one in which a plurality of MoS pages were already named. The sense of "status quo" is that Wikipedia:Manual of Style (foo) would require the fewest title changes, though still a considerable number. Other mooted styles would have required the retitling of all or virtually all MoS pages.—DCGeist (talk) 03:14, 25 May 2010 (UTC)

[Outdent] I have to agree with SlimVirgin's suggestion that "/foo" is better than " (foo)" styling here, because it automatically creates "breadcrumbs" navigation at top left. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 18:52, 25 May 2010 (UTC)

I dunno how this factors into the whole rethinking the moves thing, but I made this bot request, FYI. Equazcion ^(talk) 18:56, 25 May 2010 (UTC)

Expanding a bit of MOSNUM logic out to a more general MOS-ish topic: Don't mash symbols against prose

In Talk:Hybrid name#Spacing or not spacing the multiplication sign I strongly advocate the format "Genus × hybrid" rather than the "Genus ×hybrid" preferred by one botany organization (both spacings are found "in the wild", online and offline, along with versions that use "x" instead of "×"). I've based much of my rationale on what is recommended with regard to spacing by WP:MOSNUM ("2 + 4 = 6", "14 mm", etc.), as well as both usability and accessibility concerns (explained in quite a bit of detail at the discussion linked to above).

I've brought this here to WT:MOS for discussion, because I am thinking that the highly consistent spacing advice given at MOSNUM can be generalized into a clear principle in WP:MOS more broadly. The super-short version is "don't squish disparate types of text together (and no, we don't care if some group off-WP does)." :-) Another way of putting it is that symbols of most any non-punctuation sorts should never be mashed up against alpha-numeric prose, whether prefixed or suffixed, unless it is in computer code and is required or customary in that context ("@" in an e-mail address, "!" and "^" as operators, etc.). Someone else may have some better ideas for phrasing, of course; I'm just trying to get the principle in front of us. I'm also having a hard time thinking of exceptions. The degree symbol (though I have actually seen it spaced), the percent sign (ditto), currency symbols, and "#" as a shorthand for "number" (e.g. "#1", but we eschew that anyway), are all I can come up with. Pretty short and easy list of exceptions, really.

MOSNUM is written with this clear but uncodified maxim guiding it from top to bottom, but the idea does not seem to have escaped its page borders. I think it should (and MOSNUM can cite the more general MOS principle after we have one, without having to actually change any of its own advice). — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 06:51, 25 May 2010 (UTC)

Yes, please. Tony (talk) 07:15, 25 May 2010 (UTC)

Is a vast expansion of MoS under way before our very eyes?

Why has WP:WikiProject Films/Style guidelines/Copy-editing essentials suddenly been moved into the MoS? I wrote the original version—on which this Film version was based and largely written by Steve—for the MilHist WikiProject here. It was never intended to have the authority of the MoS, and has no consensus for such.

This is going way too far. Tony (talk) 07:12, 25 May 2010 (UTC)

I agree. The 20 polls with billion variants to restructure the MoS from top to bottom is very unsettling/confusing, especially when people take them to mean that consensus has been found to do X, when we can't even get a clear outline of what the problem even is, or what it's trying to settle. Headbomb {talk / contribs / physics / books} 07:16, 25 May 2010 (UTC)

It's not tagged as part of the MOS. How is it you think it is? Gnevin (talk) 08:52, 25 May 2010 (UTC)

Steve reverted the move, I think. Tony (talk) 09:49, 25 May 2010 (UTC)

(edit conflict) Probably because it's location in Wikipedia space implied it more than anything else. Anyway, I've moved it back now. On a related note, I've opened up a proposal to divorce the film style guide from the official Manual of Style. Anyone interested in discussing, supporting or objecting should take a look here. All the best, Steve ^T • C 09:50, 25 May 2010 (UTC)

WP:WIAGA allows only very specific parts of MOS, and hence would prevent Wikiproject extensions. For WP:WIAFA I suggesting a ruling at Wikipedia talk:Featured article candidates. --Philcha (talk) 10:15, 25 May 2010 (UTC)

I moved it. It was a subpage of a moved page, and part of a mass moving of all such pages. That mostly constituted archives, but I didn't see the point in leaving other pages under an unused path anyway. I don't mind it having been reverted, but you might want to consider some new title, maybe cutting out the unused page title in the name; like WP:WikiProject Films/Copy-editing essentials. Equazcion ^(talk) 11:17, 25 May 2010 (UTC)

I moved it back because you only moved the talk page, not the project page. Had you done the other, I might have waited for discussion to revert. :-) Your suggestion is a good one, though. I'll see how this pans out first though. Steve ^T • C 11:58, 25 May 2010 (UTC)

Oops. My main concern was archives so I was only looking at talk subpages, and didn't realize that also had a main WP page. Anyway it looks like we're on the same "page" now (no pun intended). I'll leave it up to you guys. Equazcion ^(talk) 15:48, 25 May 2010 (UTC)

Ain't got no style

Done Is it just me or do the following offer no stylistic guidance and should be removed from the MOS to Content guidelines? ~~#Wikipedia:Manual of Style (words to watch)~~

~~Wikipedia:Manual of Style (controversial articles)~~

~~Wikipedia:Manual of Style (spoiler)~~

And this should be marked as essay or a how to?

Wikipedia:Manual of Style (how to copy-edit) Gnevin (talk) 19:58, 25 May 2010 (UTC)

Consensus well-established that Words to watch covers matters of expressive style. While there is certainly overlap with the field of content, the guidance fits much more naturally into the field of style.
Agree, Controversial articles should be removed from MoS and rebranded as content guideline. [On further review, this should swiftly be rebranded as an essay. See new thread below.]
Agree, Spoiler should be removed from MoS and rebranded as content guideline. Really, it should be merged into the existing content guideline Wikipedia:No disclaimers in articles. [I have done the retitling—which merely restores the title it had until yesterday—and the rebranding as content guideline, which I believe is noncontroversial. The page itself describes its concern as content.]
Agree, How to copy-edit should be removed from MoS and rebranded, though not sure as what.—DCGeist (talk) 20:29, 25 May 2010 (UTC)

What is expressive style? I know W2W was just formed but looking by my rule of thumb which is

When the style guideline of a article not follow it can still be factually correct. For example saying joe bloggs is a politicianthe style is incorrect and should be Joe Bloggs is a politician but when content guidelines are not followed the article is factually incorrect Joe Bloggs is the greatest politician ever}} .

For me W2W falls squarely into content Gnevin (talk) 20:43, 25 May 2010 (UTC)

In Webster's, the first of six primary definitions of style is "designation, title". That is not directly relevant to our discussion.

The second primary definition of "style" is "a distinctive manner of expression (as in writing or speech)". That is the stylistic concern that Words to watch addresses. The dictionary gives an example of the word's use that happens to be exactly on point: "writes with more attention to style than to content".

The example you raise demonstrates a point over which there is no dispute—when it comes to word choice, there is some overlap between style and content. However, your example also demonstrates that Words to watch focuses on matters that are primarily stylistic. The essential problem with "Joe Bloggs is the greatest politician ever" is not that it is factually incorrect, but that it inappropriately interjects a particular POV. And that example is one of the most extreme that might have been chosen. In many of the other topics covered on the page—e.g., expressions of doubt, synonyms for 'said', euphemisms, clichés—the overlap with content is much less, and the concerns are much more purely those of appropriate style.

It appears that you believe the Manual of Style should basically be restricted to "convention[s] with respect to spelling, punctuation, capitalization, and typographic arrangement and display followed in writing or printing". That not only happens to be the sixth definition of style, it is a far more restrictive understanding of the word and the scope of our guidance than has been established and widely accepted here over the years.—DCGeist (talk) 21:00, 25 May 2010 (UTC)

No, I'm happy with your explanation. We really need Wikipedia:Comparison of guidelines or something similar . As you can tell I'm not great at telling the difference so gave up Gnevin (talk) 21:08, 25 May 2010 (UTC)

I agree that content guidelines should not be a part of the Manual of Style, which is itself a style guide. My understanding is, style guides do not affect content. I would think a Manual of Content could be an idea worth exploring, though it's been suggested before and gained little support.

I agree, more so, due to the fact that I have no idea when (or why) it was first decided that any of the current "guidelines" fall under the MoS. We have a system for "article history" when it comes to marking the point in time when an article becomes a "featured article"; wouldn't a similar system, to mark when exactly an article became a recognized part of the MoS, be sensible? For instance, I came here to get a better understanding of "what makes a guideline become 'recognized as a part of the Manual of Style'?" because of the current discussion at WT:FILM concerning the naming of WP:Manual of Style (film). I found that WP:MoS(film) was named "part of the English Wikipedia's Manual of Style" on March 18, 2007. Why? I don't know. Was there a discussion about it? Maybe, how should I know? The point is, this sort of thing should be made easily available, due to the importance of the MoS. WP: Manual of Style (spoiler) was just a guideline, until very recently when it was arbitrarily labeled "part of the English Wikipedia's Manual of Style".

I would like to propose a systematic review of all guidelines currently marked as "part of the English Wikipedia's Manual of Style". If consensus was obtained before a guideline was added, we should see if consensus remains; if consensus was not obtained previously, we should see if consensus is actually present and, preferably, develop some sort of "article history" to plainly document said consensus. Whether content guidelines are retained or not (which, if they are I would think labeling them as "This content guideline is part of the English Wikipedia's Manual of Style" would be best), the Manual of Style is quite unwieldy and I think this process might result in many of its current guidelines to be found "unworthy" of inclusion.

Just an observation/suggestion, because my head literally asploded trying to navigate much of the MoS. Chickenmonkey 22:48, 25 May 2010 (UTC)

Couldn't agree more, there is currently an on going review on the MOS as whole although a few elephants in the rooms refuse to let use see them such as what to do with the main MOS . As part of the review a large number of pages have been removed, WP:W2W has been created and accepted ,nearly all the pages titles have been moved to a common title and Category:Wikipedia_Manual_of_Style has been created. Just today 2 more pages where removed from the MOS as they where content . I feel the next step is to get Wikipedia:Subject specific guide accepted , remove some or all of the pages listed above and then. Have weekly review of Category:Wikipedia Manual of Style sub-categories Gnevin (talk) 23:08, 25 May 2010 (UTC)

I follow these matters relatively closely, yet only noticed the Wikipedia:Subject specific guide RFC today. Obviously, my delay in noticing it has partly to do with whatever else is grabbing my attention, but perhaps the proposal could use another advertising push. As you say, it can serve an important purpose in rationalizing the MoS.—DCGeist (talk) 23:27, 25 May 2010 (UTC)

Not sure how I could advertise it more but am open to suggestions Gnevin (talk) 23:59, 25 May 2010 (UTC)

MediaWiki:Watchlist-details seems to be the only way to guarantee sufficient publicity these days; it's been a significant problem for proposals as of late. Nifboy (talk) 03:50, 26 May 2010 (UTC)

(i) I agree with Dan Geist's posts in this section. (ii) There's not a hope in hell of getting an RfC watchlisted unless it concerns heaven, hell, and all matters eschatalogical. They wouldn't even agree to the watchlisting of an RfC on reforming ArbCom elections last October. (iii) "Subject specific guide"? Should this not be "Subject-specific guide"? Or am I misunderstanding the meaning? Tony (talk) 04:08, 26 May 2010 (UTC)

Great minds, bro.—DCGeist (talk) 04:53, 26 May 2010 (UTC)

Just Wikipedia:Manual of Style (how to copy-edit) left Gnevin (talk) 13:27, 26 May 2010 (UTC)

I'm leaning toward marking it as a how-to page.—DCGeist (talk) 13:48, 26 May 2010 (UTC)

I've moved it to How to and removed it from the MOS category Gnevin (talk) 14:00, 26 May 2010 (UTC)

Swiftly remove "Controversial articles" from MoS and guideline status entirely

Done A full review shows that the recently retitled Wikipedia:Manual of Style (controversial articles) is of very low quality. Aside from the fact that it is more relevant to content than style, it has virtually no substance that is not better treated in other policy and guideline pages. I have not been able to determine when it was first categorized as a guideline, but it was first tagged thus in April 2005 and first tagged specifically as a style guideline in August 2005. No discussion whatsoever accompanied any of these acts. The page never earned and probably never merited guideline status; it obviously doesn't now. It should swiftly be rebranded as an essay.—DCGeist (talk) 00:47, 26 May 2010 (UTC)

Yes indeed. Tony (talk) 04:10, 26 May 2010 (UTC)

This guideline is indeed poor, but the need for a good and binding guideline on controversial articles is a critical need. There are a number of guideline issues that we need to discuss and put into the style manual, including:

A higher level of attribution is required.
Even when a source is deemed reliable, the political affiliation of the source, and any controversy surrounding the source, must be mentioned in the article. Two examples of this would be Ilan Pappe, an historian associated with the "new historian" movement in Israel which is highly critical of the Zionist movement, and Anita Shapira, generally recognized as a leader of the pro-Zionist historical school.
Words that are inherently editorial in character - "terrorist", "freedom fighter", "massacre", "blood libel" - may only appear in an article within a direct quote. It is not the place of Wikipedia to apply these labels, even when they appear in reliable sources.

There is, in my opinion, great urgency in developing binding style guidelines for controversial articles. Our coverage of controversy, especially in the Middle East, is the cause of a decline in the Wikipedia's credibility worldwide. --Ravpapa (talk) 05:26, 26 May 2010 (UTC)

Ravpapa, the points you have raised here and those articulated in more detail on User:Ravpapa/The Politicization of Wikipedia point us toward a viable content guideline for controversial articles. The existing page under consideration, in contrast, is weak and redundant. Please do not take its relegation to essay status as a diminution of the importance of the points you raise. I would be happy to work with you on developing a new guideline page from the ground up that could (unlike the existing Controversial articles) achieve consensus support.—DCGeist (talk) 05:44, 26 May 2010 (UTC)

Agreed. --Ravpapa (talk) 06:55, 26 May 2010 (UTC)

... and here are my first thoughts. --Ravpapa (talk) 07:47, 26 May 2010 (UTC)

Well I suggested removing from the MOS above but your correct should be marked essay Gnevin (talk) 09:06, 26 May 2010 (UTC)

Done.—DCGeist (talk) 12:31, 26 May 2010 (UTC)

Recent years--content or style?

Wikipedia:Recent years is currently marked as an editing guideline, which it is clearly not. It embodies elements of a content guideline and a style guideline. (It is, in fact, a subject-specific guide.) For the time being, should we adopt it into the MoS or mark it as a content guideline?—DCGeist (talk) 15:16, 26 May 2010 (UTC)

Would mark it as SSG in a heart beat but for the moment can you put it on your to do list? If the SSG RFC fails then it may need to be split or something Gnevin (talk) 15:40, 26 May 2010 (UTC)

It's the first time my attention has been drawn to that page, and already I have misgivings about it. The year pages this "guide" relates to tend to be very cliquey, and consensus is in doubt on looking through the history of the talk page. Just who to ministering to whom is an interesting question. There are accusations flying around of sockpuppets in the edit summaries, unsurprisingly. But giving it the benefit of the doubt and taking it at face value for the moment, I recoil at passages such as:

The same editor(s) may create a designation's article, and then add that designation to the year article's second paragraph. However, it is incumbent upon this or these editor(s) to ensure that the created article is suitable for an encyclopedia and does not violate any of Wikipedia's policies. Does that mean other articles can breach policies? Should we plaster this imperative on all of the MoSes?

That an event is important to an individual editor, or even to a particular society or nation, is insufficient ground for its inclusion. The event must have a demonstrated, international significance. The fact that other year articles may include events which break this set of guidelines is not a valid reason to do so for another event.

I feel incompetent to contribute to recent year articles having read that. The whole page urgently needs a copy-edit; often there are logical inconsistencies. At this stage, I'm inclined to mark it as SSG, just to dodge these issues. Tony (talk) 16:15, 26 May 2010 (UTC)

Dispute: Life form capitalization run rampant

Enough is enough. Every other day I now run into articles where plant common names, animal common names, even breeds of animals and cultivars of plants, are being capitalized even where they do not contain a proper name (e.g. "Magyar Agár" instead of "Magyar agár", one I recently fixed). MoS badly needs to put its foot down very clearly on this matter and bring this to a halt. This is English, not German. We do not randomly capitalize nouns just because they are nouns. Some of the advocates of this practice are the same kind of people who write "Science" instead of "science", and so forth. (See User talk:SMcCandlish#Dog breed capitalization - greyhound Greyhound etc [sic] for example and really strange rationale, namely the claim that "greyhound" and "Greyhound" have different meanings). See also reversion of my painstaking cleanup of greyhound. I'm raising this dispute here rather than at the greyhound talk page, because this is an across-the-board issue, not limited to that particular article. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 17:22, 12 May 2010 (UTC)

I agree. One thing though, you might want to address this at the capitalization section; I think there is a separate page for that. Maurreen (talk) 18:04, 12 May 2010 (UTC)

This appears to be the right page: WP:Manual of Style#Animals, plants, and other organisms is the section. I cannot find a separate page about capitalization, and capitalization advice runs all through WP:MOS. There are some article naming conventions pages that are relevant, but their guidance is necessarily subordinate to the broader guidance here on the topic. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 19:41, 12 May 2010 (UTC) PS: I did find Wikipedia:Manual of Style (capital letters), but it's section on this topic simply directs the reader to the larger one here, so this is the right talk page. I put a pointer to this discussion on that other talk page. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 20:53, 12 May 2010 (UTC)

I agree with you on this point, although I have not raised the issue because the matter appeared to have been settled, and I did not wish to dispute the status quo. The capitalizations which you mentioned are reminiscent of characters by Beatrix Potter, where animals have been elevated to the status of personhood. Consequently, Wikipedia has been lowered (in that respect) to the status of children's literature. Wikipedia urgently needs to have a clear framework of consensus, for (1) defining consensus, (2) achieving consensus, (3) recording consensus, and (4) dealing with lapses in consensus. -- Wavelength (talk) 18:07, 12 May 2010 (UTC)

It's definitely not settled, at least not as far as actual practice goes. The wording at WP:Manual of Style#Animals, plants, and other organisms needs to be strengthened, and clarified that it applies to common names, breed names and cultivar/variety names. The problem is that (as usual) various random WikiProjects think that guidelines simply do not apply to them, that they are magically special and can do with the language whatever they want. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 19:41, 12 May 2010 (UTC)

Also, there was a related page somewhere at the Pump maybe a month ago.

If I remember right, the thrust of that was that some wikiprojects about specific animals (such as birds) had decided to capitalize all names of specific species. The rationale was that they are capitalized in bird references and are proper nouns -- regardless of the style in general references such as dictionaries. Maurreen (talk) 18:17, 12 May 2010 (UTC)

I found these websites which capitalize the names.

-- Wavelength (talk) 18:58, 12 May 2010 (UTC)

Yes, it appears that specialized references capitalize names of birds, and general ones do not. Maurreen (talk) 19:15, 12 May 2010 (UTC)

Right; a few birder editors here have been incredibly tendentious, in forum after forum, and entrenched on the issue of using their weird pet grammatical conventions that defy standard English, resulting in a WP:FILIBUSTER on the issue for several years now. This despite the fact that WP is a general, not specialized work, by definition. It's clear that most editors do not agree with them, but few have the patience to continue to argue with these people, for whom this is essentially a "religious" matter, in the figurative sense (an article of deeply held faith on which they will not budge, no matter the logic behind changing and costs of not doing so). The real problem, aside from bird-related articles that look completely stupid to everyone by ornithoscopists, is that their practice is now spreading like wildfire through a large number of animal- and plant-related articles, over about the last 18 months, with the result that more and more of the non-bird article now also look like they were written by Germans with an improper understanding of English grammar and spelling conventions. It has to stop. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 19:32, 12 May 2010 (UTC)

This page (Capitalization of Bird Names) gives a reason for capitalization, namely, to avoid ambiguity: for example, the expression "Black Wren" denotes a species of bird, whereas "black wren" denotes any wren which is black. See also the following pages: http://wiki.riteme.site/wiki/Wikipedia_talk:WikiProject_Birds/archive_7 and http://www.worldbirdnames.org/rules-caps.html and http://www.ibiblio.org/pardo/birds/archive/archive5/msg00727.html. (The link to Wikipedia is the tenth result from my Google search for the words bird name capitalize). -- Wavelength (talk) 20:24, 12 May 2010 (UTC)

And has been said by many before, this "reason" is bogus, since simple wording caution and basic wikilinking can easily avoid such ambiguities. E.g. "...similar to the black wren", "the black wren species does not intergrade with the rock wren (Salpinctes obsoletus)", "the black wren species should not be confused with other wrens of a black color, such as the...", and so on. Frankly the "reason" is insipid, childish and insulting, since it presumes that WP editors are such terrible, lazy, ignorant and helpless writers that they couldn't manage to write a clear sentence, and that our readers are abject morons who can't read plain English and come up with a cogent thought about any sentence they read. That said, I want to clarify that this thread is not about birds. As I've already noted, the birders have their articlespace locked up in a years-long filibuster on the matter. This thread is about the rampant spread of capitalization of life forms in non-bird articles. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 20:43, 12 May 2010 (UTC)

"The Black Duck is not the only black duck."; "The black duck is not the only black duck." Hmmm....Chrisrus (talk) 20:13, 15 May 2010 (UTC)

I think SMC might be overstating things a bit, but this is something that has come up before. Whenever we make rules based on a desire not to confuse people, we should ask this question: "Was anyone confused or do people just think they might be?" We established that there are cases in which the abbreviation US without its dots could be mistaken for "us," but these are rare and can be dealt with and there are no actual cases of Wikipedia readers getting confused by this so we determined that requiring the dots in all articles was not necessary. (American vs. British punctuation has a similar lack of evidence but also a different result.)

This isn't a rhetorical comment. These specialist publications have long histories. Do any of them have records of readers being confused and writing in because of the capitalization scheme? Even an old interview mentioning this problem as a basis for the decision would do. Darkfrog24 (talk) 13:44, 16 May 2010 (UTC)

Wikilinking only works the first time the locution comes up — after that, it's overlinking (though I can accept once per section in a long article, if the sections are reasonably long). Rewording to avoid the problem seems the long way around.

I think the MoS needs to know its place. It's a peripheral; it's not the CPU. It should defer to experts on content in the fields in which they are expert. I agree that sometimes the bird articles look a little unusual, but I am not a bird expert, and am not willing to override their judgment. You shouldn't try to do it either. --Trovatore (talk) 20:52, 12 May 2010 (UTC)

Update: See User talk:SMcCandlish#Dog breed capitalization - greyhound Greyhound etc for further discussion that reveals that dog people have the same two bogus reasons that the birders do: 1) Specialist publications do it; 2) readers might be confused between the greyhound as a specific breed and greyhounds as a class of breeds. Both of these have already been addressed above (and many times in many previous debates, mostly with birders): 1) WP is a generalist, not specialist publication, and specialist weirdness with grammar and spelling simply doesn't apply here; 2) write more carefully. This is dirt-simple, really. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 21:00, 12 May 2010 (UTC)

Oh this is dirt simple alright - this discussion is a clear case of a few dictators at MoS trying to dictate content with arguments littered with borderline personal attacks - "bogus reasons" and "specialist wierdness with grammar and spelling". MoS should leave well alone here and not just bulldoze away anythink it doen't like and chase away editors who actually know something of the subjects.Nigel Ish (talk) 21:18, 12 May 2010 (UTC)

SMcCandlish, from my Google search for animal name capitalize, I found the following results which agree with you: Capitalization#Nouns (point 6) and http://rwc.hunter.cuny.edu/reading-writing/on-line/capital.html and http://plants.ifas.ufl.edu/guide/scicom.html.

I used the style manual search engine (http://www.onlinestylebooks.com/) mentioned in the article linked to in the section before the previous one, and found these 18 results, of which the first agrees with you. -- Wavelength (talk) 21:21, 12 May 2010 (UTC)

I propose that someone (who supports capitalization) choose an article where a workaround is considered to be impractical, and that SMcCandlish produce a version with a practical workaround. That version can then be put on a new subpage (of the article page, or of SMcCandlish's user page). -- Wavelength (talk) 21:40, 12 May 2010 (UTC)

[I am correcting the spelling of "SMcCandlish". -- Wavelength (talk) 21:54, 12 May 2010 (UTC)]

I think this is an excellent proposal. Ozob (talk) 02:27, 13 May 2010 (UTC)

Agreed. Wavelength has done it again. We should invite everyone to a fresh page where this matter can be dealt with using references. Darkfrog24 (talk) 19:04, 14 May 2010 (UTC)

Re initial thread in the text:"Some of the advocates of this practice are the same kind of people who write "Science" instead of "science", and so forth.": the poster should be aware that it is standard practice in UK English to capitalise academic subjects. Kevin McE (talk) 22:35, 12 May 2010 (UTC)

I agree with SMcCandlish's point. HWV258. 03:26, 13 May 2010 (UTC)

Ozob wrote: "It should defer to experts on content in the fields in which they are expert." Not as a principle. I work with experts all the time, and they are almost always clueless on style and formatting. Biologists are, however, fussy about capitalisation. It requires discussion, not deferral to so-called "experts". Tony (talk) 07:44, 13 May 2010 (UTC)

Actually, that was me.

Yes, discussion, fine. Just the same I stand by the overall point. The MoS is getting uppity; the centralist impulse here is too strong. Absolutely, we can always discuss. But the centralists don't get to insist that it should be discussed on centralist home turf. --Trovatore (talk) 18:00, 13 May 2010 (UTC)

Does that mean we should change WP:CONLIMITED and maybe even the {{Uw-mos1}} {{Uw-mos2}} {{Uw-mos3}} {{Uw-mos4}} series? Art LaPella (talk) 23:38, 13 May 2010 (UTC)

It means that the people who hang around the MoS need to realize that they are not in fact "the wider community". They're the people who like to hang around the MoS. Consensus here is not noticeably broader-based than consensus among experts on a particular topic. --Trovatore (talk) 08:17, 14 May 2010 (UTC)

Huh? "hard to read format"... Is that supposed to be a joke? ;-) (Ill change it to "hard-to-read format" just because I don't want to be one whining without acting, not that I care about that so much.) A. di M. (talk) 13:39, 14 May 2010 (UTC)

If the issue is just how to interpret CONLIMITED, it says to ask "the broader community" whether "some generally accepted policy or guideline does not apply". If I were looking for what the wider community thinks about a policy or guideline, I would go to its talk page, where the people who care about that guideline could be expected to be watching. Where else would you go? The Village Pump maybe? Not the Wikiproject; CONLIMITED excludes that interpretation. I understand that controlling a guideline from its own talk page creates a bias towards instruction creep, but is there some dictator you would propose as an alternative? (A. di M.: the same issue occurs on mos4.) Art LaPella (talk) 21:07, 14 May 2010 (UTC)

Yeah, I was going to fix that, too, but for some reason I forgot to. Fixed. A. di M. (talk) 12:12, 15 May 2010 (UTC)

Caps: Arbitrary break

This should be relatively simple. We should look at the closest models to ourselves -- general encyclopedias such as Britannica and World Book. Britannica has greyhound in lowercase. (World Book appears to require a log in.) Maurreen (talk) 07:15, 13 May 2010 (UTC)

Ah, while we're on this topic, the formation of the new British government has brought a raft of capitalitis, a re-emerging disease. Or am I wrong? Could people provide advice as to whether "cabinet" should be "Cabinet"? "The Cameron C/cabinet"? "Mr Cameron's new C/cabinet"? "The new cabinet"? "UK cabinets over the years"? And, "the prime minister David Cameron" (should it be P and M?). The UK prime minister? Where do we stand on "the shadow cabinet"? I see S and C everwhere. And "the O/opposition"? Tony (talk) 07:20, 13 May 2010 (UTC)

- I think "Cabinet" is standard in the USA. But I just did a very quick scan, and it looks like the lowercase version is more prevalent in the UK (Britannica has it lowercase). U.S. style is standard to cap titles only directly before a name; I think British style might lean the other way. I see no reason to cap "opposition" on either side of the pond. Maurreen (talk) 07:33, 13 May 2010 (UTC)

Since I seem to have got stuck in MoS issues ... opinion is divided in most UK publications. The print media are pretty evenly split - interestingly, the more left wing publications, eg The Guardian and The London Review of Books, tend towards lower casing for posts, titles and collective nouns. Maybe it's a bid to not look too deferential or something. Thus "foreign secretary William Hague". I'm sure I've even seen "lord Smith" in the LRB. By contrast, The Daily Telegraph for example tends towards upper casing, definitely for Foreign Secretary and Prime Minister, and even "the Opposition". Hansard is also fond of the upper case, and would use it eg for Government, Cabinet (although probably shadow Cabinet) and Opposition, as well as for Home Secretary, whether as a title before a name, or when referring simply to the post itself. Where that leaves us, who knows. N-HH talk/edits 11:24, 13 May 2010 (UTC)

A frequent compromise seems to be to capitalise unique or nearly-unique titles such as Chancellor of the Exchequer, Pope, and First Sea Lord, but use lower-case for more generic terms such as managing director, editor, vicar. The problem with such a compromise is that it leaves the way open for endless debate. And while I can see there is a credible argument for capitalisation in some cases, the trouble with it as a universal rule is that it leads us toward an absurd situation where a film has a Director and we are served by Shop Assistants.

On animals - I don't know enough to have a strong opinion but it would seem to me that when it comes to distinguishing between species in a biology article the way round the problem might be to use the Latin names. Dog breeds are awkward because so many of them contain geographical names, and while logically consistent a sentence like this looks rather awkward to me: A great Dane-Irish setter cross met a Pyrenean shepherd dog and a toy Manchester terrier at the park. Barnabypage (talk) 18:22, 13 May 2010 (UTC)

Kevin McE, practically anything can be an academic subject. Maurreen (talk) 07:34, 13 May 2010 (UTC)

This should be discussed at Wikipedia:Manual of Style (capital letters). With any changes being made there first and here after Gnevin (talk) 11:29, 13 May 2010 (UTC)

With regard to capitalizing species names, I don't like the practice and I would prefer it if Wikipedia had a policy more appropriate to a general-readership publication, but if someone could cite a real reason with real references, then I could see myself supporting it. I agree with Maureen, though. We should take a hint from other encyclopedias in both British and American English. Wikipedia is not a specialist publication and its writing style should reflect that.

...if worst comes to worst, has anyone proposed the idea that we offer the ornithology fans a "The Beatles" exception? Accept that they have won the fight, and then let them do what they want so long as it doesn't spread? Darkfrog24 (talk) 19:07, 14 May 2010 (UTC)

As the person who brought The Beatles to FA status, I have maintained an interest in that issue ever since it (earlier) surprised and perplexed me when I first edited Wikipedia. I can report that there seems to have been a diminution in the demand for that rendering. The subject was recently discussed as part of Jubilee's Music MoS auditing activities, producing a lot of interest in, and support for, the view that Wikipedia band articles (it's not just the Beatles, by the way) would benefit from being brought up to date with what most of the rest of the world does, i.e., desist from using "The" in running prose. Further to Jubiliee's activities, I responded along these lines to a related Beatles discussion; my response provoked no particular reaction. I think it likely that the "The" was a passing phase and that editors are now generally more open to the notion of going with the more general flow. I would hope the same applies to flora and fauna in a general-readership publication, and that Wikipedia's main style guide should be sufficient voice and should aim for a standard that accords with mainstream practice for general-readership publications, whether for the birds or The Byrds. PL290 (talk) 20:14, 14 May 2010 (UTC)

‹The Beatles› (excluding occurrences at the beginning of a sentence) and ‹the Beatles› appear to be nearly equally split in the British National Corpus.[2] A. di M. (talk) 16:37, 16 May 2010 (UTC)

I'd suggest reputable style guides and HQ sources are more the point. Pick up almost any book on a band, and you'll find "the" in running prose. Sure, you can always find examples that put "The", but they're in the minority. Jubilee searched around for both renderings of band names, and came across 10 "the" versus 4 "The". I did a slightly more rigorous (while still small-scale) experiment: first 10 viewable hits in a Google Books search for some bands. (I think it was the Stones, the Beach Boys and the Beatles, but I'm not sure now). Of those 10, only one used "The" in running prose. An editor then drew our attention to this excerpt from the Chicago Manual of Style Q&A section:

Capitalization, Titles

Q. For rock fans, such as myself, it is sometimes important to know whether one is to capitalize the "the" preceding a rock group’s name. For instance, the group "the Who." In the middle of a sentence, do I say "the Who" or "The Who," given that the "the" is an integral part of the title and furthermore is the first word in the title?

A. When the name of a band requires the definite article, lowercase it in running text:

When I first saw the Who, they had short hair; when I last saw them, that was again true.

I can’t believe the Rolling Stones didn’t retire with all their money years ago.

The day I was introduced to the The was the day I learned that irony was finished.

It is true that "the" often gets capitalized on album covers, but our rule is to capitalize the first and last word in any title, which fits in with that practice (the The has usually employed a lowercase "the" nested above an uppercase "The" on its covers). Exceptions to the proper "the" rule are names that are captured within italics or quotation marks within running text. Hence,

Have you ever heard "The Real Me," that song by the Who?

I have three copies of The Soft Parade, one of the Doors' lesser-known albums. Chicago Manual of Style Q&A

I copied that onto the Beatles talk page recently, along with the suggestion that it was time for WP band articles to come up to date with the rendering used by most of the rest of the world, and adopt this style. There seems to be no good reason not to. I hope there will be acceptance. PL290 (talk) 17:15, 16 May 2010 (UTC)

Caps: Reframing

I'm hoping most of you will agree that names of species (e.g., Mimus polyglottus) are proper nouns, and names of animals (e.g., mockingbird) are common nouns. In many groups of organisms (including plants, my specialty), common names are common nouns. But with birds and some other animals, there are codified English-language equivalents for species names, so that Northern Mockingbird is an English-language equivalent of Mimus polyglottus.

This has advantages and disadvantages that extend beyond Wikipedia. Among the advantages are the provision of easy-to-pronounce names for species (Latin names such as Tyrannosaurus being tongue-twisters to most anglophones :-) and the standardizations of such things as life lists. Among the disadvantages are the suppression of legitimate regional vernacular names, and awkward constructions such as "We saw twelve Northern Mockingbirds before noon." (Technically, there's only one Northern Mockingbird, the single species.)

To me it is abundantly clear that bird names should be capitalized in article titles. To me is is abundantly unclear how to deal with capitalization in running text. Substituting the scientific name in the previous sentence yields "We saw twelve Mimus polyglottus before noon," or, for Latin pedants who want to get the case and number right, "We saw twelve Mimos polyglottos before noon." A correct alternative, "We saw twelve individuals of Northern Mockingbird before noon," is only somewhat less cumbersome.

Summary: the issues relating to capitalization are different for article titles and running text.--Curtis Clark (talk) 15:19, 16 May 2010 (UTC)

Just remember that real, not idealized, Wikipedia articles capitalize common species names randomly, because almost nobody understands the rules, and nobody understands all the unwritten exceptions; we only know that some people get very excited about them. Art LaPella (talk) 15:28, 16 May 2010 (UTC)

Well, all of us who frequent this of all talk pages are presumably to some extent "excited" about using words well, and about establishing/maintaining an effective styleguide for Wikipedia. Articles also contain spelling, punctuation and formatting errors because the perpetrators don't understand the rules, but that doesn't make efforts to correct them any less worthwhile. It's quite true that words in article and section titles need to be treated differently from those in running prose. And unless something like that is pointed out, it can be overlooked by people struggling to understand the rules. Let's keep up the effort to produce rational rules and to produce what consistency we can in the encyclopedia, and let's allow ourselves to be influenced in our style decisions by what the majority of mainstream style guides and HQ sources are doing. PL290 (talk) 13:01, 17 May 2010 (UTC)

Okay, restating my conclusion: Capitalization of bird names in article titles is arguably correct, and is at any rate under the jurisdiction of Wikipedia:Article titles. Capitalization in running text is problematic, and the MoS is the correct place to handle it.--Curtis Clark (talk) 13:35, 17 May 2010 (UTC)

(Outdent) I'm dead tired and will have to get to most of it later in detail, but I definitely will. In short, for now:

It's absurd to suggest that just because Bandersnatchus frumius has a capitalized genus that is a "proper name" (a.k.a. "proper noun"; rather lame terms, but we're stuck with them), like Jackson or Beijing or Ben Folds Five. It's not. It's a binomial (a "scientific name" to laypeople). Yes, it is very specific and unique, but that doesn't make it a proper name. It's doubly absurd to then suggest that the common name "frumious bandersnatch" is "also" a proper noun and thus must be capitalized because the binomial "is" a proper name. What a house of cards. If the binomial were a proper name, it would be Bandersnatchus Frumius, but it isn't. An argument can be made that the genus is a proper name, but we don't care, as it isn't relevant to this discussion, and it's a bogus argument anyway (genus is capitalized, just like the binomial is italicized, simply as a matter of convention - and (this is important) it's a convention that is completely accepted across all fields, scientific or otherwise. Even tabloid newspapers usually get it right.
There has never to my knowledge been any reliable evidence of any kind presented that (outside of the effect I raise as problematic here, of Wikipedians in particular starting to capitalized common names of everything because the birder habit is rubbing off) anything but birds gets this treatment even in refereed biological literature much less more generally. I have evidence to cite to the contrary.
Even the idea that bird common names are consistently capitalized in scientific literature is horsehockey; virtually no one does this outside of ornithological literature. I have evidence to cite about this, evidence published in a leading ornithological journal, no less. I'm going to be really loud about this: Given this fact, and given that Wikipedia is not an ornithological publication, even where it is presenting information about birds, that is pretty much the end of the debate right there, by the very logic of professional ornithological academia itself as well as standard Wikipedian reasoning and MOS precedent more specifically. I'm sure this will rage on even longer, but I'm basically serving some advance notice that the argument for capitalization of any common names of organisms (except where they contain proper names), including birds, on Wikipedia is very near to collapse.
There is no difference at all between capitalization (or not) in article prose and in article titles; WP:NC makes it very clear that article prose and titles should match to the extent possible. What is done with article titles proceeds from the MOS to begin with (e.g., if MOS says "don't use curly quotes", then article titles don't use curly quotes, either); the naming conventions do not operate in a vacuum. The bifurcation of the naming conventions and the MOS is illusory. Per the big discussion up above about style guideline pages on WP and their page naming, there's not really even a solid reason not to have the naming convention pages be renamed to be part of the MOS "officially"; it would probably reduce a fair amount of confusion and strife. But, that's another proposal for another time.

Anyway, more on the real topic here will come later in a new section; I just want to make sure this doesn't get archived again for being dormant for more than a couple of days. This needs to get resolved, finally, not archived and re-raised in a month, and archived and re-raised, ad nauseam. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 07:32, 25 May 2010 (UTC)

Inasmuch as I find it to be disturbing to defend an idea with which I disagree against an editor who is on this point inflexible, I'll bow out. My only horse in this race was this one, but I'm content to let the ornithologists take up the battle, and wait until they come for me.--Curtis Clark (talk) 01:06, 31 May 2010 (UTC)

Internationalized top-level domains

There is some disagreement about how to title articles about internationalized top-level domains such as امارات. or .бг.

A brief technical recap. When you type a domain name that does not use the Latin alphabet into your browser, the characters are translated into a string of Latin characters using punycode encoding; as far as the modern internet is concerned, the punycode string and the original non-Latin string are identical objects, and you can transparently substitute one for the other.

No, this is not correct. The IDN native scripts are only usable in end-user applications that have specifically been designed to accept them, whence the name Internationalizing Domain Names in Applications (IDNA). Kbrose (talk) 17:53, 22 October 2010 (UTC)

Thus, امارات. and .xn--mgbaam7a8h are the same top-level domain name; and similarly, http://الشيخ-محمد-بن-راشد.امارات/, http://الشيخ-محمد-بن-راشد.xn--mgbaam7a8h/ and http://xn------nzede7agleu2aj7ssabu7d.xn--mgbaam7a8h/ are precisely the same URL.

Now, a string like ".xn--mgbaam7a8h" is not all that pleasing on the eyes. As a result, some people (particularly ones unfamiliar with how IDN works) have taken to calling internationalized top-level domains by transcribing their pronunciation; e.g., since امارات is pronounced "emarat" or "imarat", you get امارات. being referred to as ".emarat".

The isssue with that, of course, is that phonetic transcriptions like ".emarat" are not valid domain names. There are no websites in ".emarat"; and if you click on http://الشيخ-محمد-بن-راشد.emarat/, all you get is an error message.

The truth is, that even domain names with a leading dot, as all ccTLD articles are named on WP, are not valid domain names. The dot does not belong to the domain name, and the DNS does not use dots internally to delimit DNS labels. The use of the leading dot even in end-user applications results in error conditions. This use is purely a result of marketing starting in the dotCom era. Kbrose (talk) 17:53, 22 October 2010 (UTC)

This brings us to the issue of article titling. Currently, all articles about national TLDs in Wikipedia bear the title of the TLD itself — so the article about .uk is called .uk, the article about .de is called .de, etc. But what about internationalized domains? If we strictly interpret the Manual of Style and WP:ENGLISH, we are forced into one of two bad choices:

title the article using the phonetic transcription (as at least one user has tried to do). This is utterly unacceptable, because a title like .emarat is guaranteed to mislead a good portion of our readers into treating the non-existent ".emarat" domain as valid, and that can only end in disaster. Furthermore, there is a chance that ICANN will one day assign the non-existent phonetic domain for a completely different purpose (this is rather likely for the Latin transliterations of two-letter Cyrillic top-level domains).
title the article using punycode. While not as awful as the above choice, this one is not optimal either, since article titles like ".xn--mgberp4a5d4ar" and ".xn--wgbh1c" induce headaches by the very shape of their letterforms.

Consequently, I propose giving articles about internationalized top-level domains an exception from the strict application of WP:ENGLISH and allowing them to be named using the most natural title — the internationalized top-level domain itself, no matter which script it uses. Besides, banning non-Latin letters from the URLs of Wikipedia articles about internationalized top-level domains (which were introduced precisely to make languages with non-Latin scripts fully usable for writing URLs) would be horribly, horribly ironic. --Tetromino (talk) 08:05, 30 May 2010 (UTC)

I would go with the foreign script redirecting to the punycode or vice versa. (Probably the former, because it's more likely to be linked as امارات. than as .xn--mgbaam7a8h.) Transliterations don't make any sense in this context. A. di M. (talk) 11:03, 30 May 2010 (UTC)

I have added a request for comment to this section. I would also like to suggest a third alternative: leave the non-English characters in the title, but prefix them with something explanatory, such as "Internationalized country code (United Arab Emirates): امارات.". That would at least give English-speakers an idea of what the article is about. You could still have a redirect with just the Arabic characters. --Auntof6 (talk) 11:52, 30 May 2010 (UTC)

We already have .рф for Russia and .укр for Ukraine. The expression .rf is redirected to .рф, and I have just redirected .ukr to .укр.

-- Wavelength (talk) 01:32, 31 May 2010 (UTC)

I think that both original script and transliterations are acceptable, if the lead makes everything clear:

For امارات.:

امارات. romanized as .emarat (punycode equivalence .xn--mgbaam7a8h) is ...

For .emarat:

The romanization .emarat corresponding to the actual domain امارات. (punycode equivalence .xn--mgbaam7a8h) is ...

Inserting the word dot would make things clearer (i.e. article name Dot emarat):

The romanization dot emarat corresponding to the actual domain امارات. (punycode equivalence .xn--mgbaam7a8h) is ...

Transliterations are already being used by the press. Also, note that مصر. is transliterated as .masr, .misr, .msr. and even dot Egypt. This multiplicity probably adds evidence in favor of مصر. See Internationalized country code#Future internationalized country codes to see that .中国 and .中國 are both romanized as Zhōngguó. Transliteration would force to create "Zhongguo (simplified Chinese)" and "Zhongguo (traditional Chinese)". HaŋaRoa (talk) 19:06, 31 May 2010 (UTC)

The articles ideally should use a transliterated romanized form without any punctuation to make the articles as accessible as possible. Not all users or devices will have the capacity to enter non-English scripts into an application, and the position of the dot (start or end) may not at all be clear to a user who does not know the directional writing conventions of the language. Kbrose (talk) 17:53, 22 October 2010 (UTC)

Well, ideally the lemma should be the domain itself. Other articles also have special characters in titles. But in view of the non-ideal reality, i.e. the known limitations of users and user agents, I suggest using a circumlocution that makes it very clear it is not usable as a domain name. Something like Internationalized top-level domain for Egypt. Using "masr", let alone "dot masr", is fine in speaking but not in the latinized written form because that is highly misleading.--88.74.194.50 (talk) 14:22, 4 February 2011 (UTC)

Search

This idea was raised before so I've added it to Template:Style Gnevin (talk) 08:18, 31 May 2010 (UTC)

Citations following quotations

There is a discussion at Wikipedia talk:Citing sources for which any input would be appreciated. I'm requesting here as I assume this talkpage gets more traffic. Relevant discussion here. Thanks, --Beloved Freak 11:06, 31 May 2010 (UTC)

Wikipedia talk:Citing sources, is not part of the MOS . I'd suggest raising it at WP:V Gnevin (talk) 11:14, 31 May 2010 (UTC)

Sorry, though it was!--Beloved Freak 16:40, 31 May 2010 (UTC)

Ongoing review, and traceability

As an almost tangential part of a response in a thread on another topic above, Chickenmonkey made two specific suggestions. They weren't taken up within the focus of that thread, but they may merit further thought:

We have a system for "article history" when it comes to marking the point in time when an article becomes a "featured article"; wouldn't a similar system, to mark when exactly an article became a recognized part of the MoS, be sensible?
I would like to propose a systematic review of all guidelines currently marked as "part of the English Wikipedia's Manual of Style".

Something in both, methinks. PL290 (talk) 11:09, 29 May 2010 (UTC)

Agree to both , there is a bot which monitors the MOS but is currently disabled due to the flux it's currently in . We could ask the bot owner to make a small change so it posts the x has been added/removed from the MOS it also add a note on WP:MOS/History saying who added/removed it and when. Gnevin (talk) 11:35, 29 May 2010 (UTC)

(I'm the bot operator.) It's not as easy as you'd think to tell who added a page to a category. At best, it requires trying to parse the actual wikitext looking for who added the category, and this is not very robust. But a lot of MOS pages are categorized by templates, which makes it even more difficult for an automated process. That's why the bot just says "this page was added" and lets people figure out if the addition was correct. But the bot is disabled right now because the category structure keeps changing, which would lead to a lot of false reports. — Carl (CBM · talk) 13:00, 29 May 2010 (UTC)

Well, thanks Carl--I think that the bot just saying "this page was added" and letting people figure out if the addition was correct is entirely appropriate, so I don't think any change to the bot is needed. Since concerns have been expressed more than once over the way pages can become part of Wikipedia's styleguide at the drop of a hat, with no proper process or justification, what I suggest we now need is a process whereby we routinely respond to such a notice by conducting a review of the added item, on its talk page, and updating its talk page header with the review outcome to confirm whether it is indeed accepted as part of the MoS. Regarding the other point, systematic reviews of existing pages, I suggest we establish a regular process whereby we routinely cycle through all pages, conducting a review (announced on the main MoS talk page, for any interested editors to join in) to establish whether the page continues to form a meaningful part of the MoS, and what actions if any are needed to improve it. Again the review should take place on its talk page, and the outcome be recorded in its talk page header. We may need something central to help us keep track of the overall review cycle of all pages. PL290 (talk) 20:05, 29 May 2010 (UTC)

Yeah, I think the bot does what it should do and does it well. What I had in mind was exactly what PL290 has expounded upon here (thank you for that, by the way). I think it would be best to manually "nominate" a guideline, discuss its addition to the MoS in a subpage of the guideline's talk page, manually place the consensus of that discussion on the guideline's talk page, and document when that consensus was reached. Such a discussion likely occurred when some of the current guidelines were added; if it did, the discussion should be, at least, noted on the guideline's talk page. As for routinely reviewing the guidelines that have been added to the MoS, I actually hadn't meant that; what I meant was a one-time review of those currently in the MoS. I think routinely reviewing them is a good idea, though. Chickenmonkey 21:20, 29 May 2010 (UTC)

Please see Manual of Style/Reviews, where I have now drafted an outline of how we might proceed. The criteria and approach I've listed are simply those that quickly came to mind; please edit the page to add or change things to everyone's satisfaction. The {{MoS history}} template does not yet exist, but I envisage a vastly cut-down version of {{Article history}}. PL290 (talk) 13:35, 30 May 2010 (UTC)

Before we do that we need to decide what way are we moving central or non central Gnevin (talk) 14:24, 30 May 2010 (UTC)

I disagree--how can it hurt? We've been talking MoS reorganization for months. Life goes on. The possibility of a reorg is (and will always continue to be) an ever-present reality; any improvement to page content meanwhile can only be a good thing. Focusing on a page's role within the MoS is not incompatible with other goals. If you think reviewers may not be aware of wider reorg discussions, by all means add a review comment to draw attention to same, but it doesn't really make sense to talk about one being a prerequisite of the other.

I've now created a template for MoS History. On consideration, I realized it would potentially have wider applicability than the MoS, so I've made it generic: {{DocumentHistory}}. I'll add some usage documentation to the template as soon as I get a chance. I've added the template to the talk page header of WT:Manual of Style (dates and numbers); please see the latter for an example of usage (which is self-exlanatory once you see an example). PL290 (talk) 05:37, 2 June 2010 (UTC)

Mdash for Canadian ridings

I stumbled upon Template:ON-ED, which uses mdashes for provincial ridings in Ontario (example: Algoma—Manitoulin). I think it's incorrect, but I don't have the time to start a mass clean up. There are more such templates in category:Canada riding navigational boxes. Could someone please look into this? Thanks, Renata (talk) 15:43, 31 May 2010 (UTC)

There are extensive discussions about this elsewhere (but don't have time right now to find them). The gist of it is that Elections Canada uses em dashes and, as do some of the provincial bodies – Ontario, for example. I think the reason en dashes aren't used is that they would be difficult to distinguish from hyphens in some riding names: Montmagny—L'Islet—Kamouraska—Rivière-du-Loup. Modal Jig (talk) 18:03, 31 May 2010 (UTC)

Found these: Wikipedia:WikiProject_Electoral_districts_in_Canada#Em-dash_use and Electoral_district_(Canada)#Naming_conventions. (The spaced em dashes in Canadian articles is a different kettle of fish.) Modal Jig (talk) 18:57, 31 May 2010 (UTC)

That discussion was way back in 2006 when WP:DASH was not generally understood or enforced. I think WP has made a lot of progress since then. IMHO, the pages should be moved to get rid of mdashes. Would think that Montmagny – L'Islet – Kamouraska – Rivière-du-Loup would be just fine. Renata (talk) 02:00, 1 June 2010 (UTC)

And what good would it do? You would spend hours and hours moving all of these articles, and then dozens of hours to fix all of the links to bypass redirects, and how would that improve Wikipedia? I am assuming that you are offering to do it yourself, rather than trying to get other people to do it. Ground Zero | t 02:20, 1 June 2010 (UTC)

Don't forget WP:NOTBROKEN, another guideline that should either be enforced or changed. Art LaPella (talk) 05:30, 1 June 2010 (UTC)

Should it be decided that the articles should be moved to conform to Wikipedia's guidelines, isn't there a bot that fixes double redirects? Personally, I say that Wikipedia has its own guidelines on naming, and while Elections Canada's usages might be persuasive, they aren't controlling. I have no dog in this fight, but I don't see a reason that these articles get an exception from the rest of the guidelines on Wikipedia, IMHO. Imzadi 1979 → 05:40, 1 June 2010 (UTC)

WP:NOTBROKEN and double redirects are not the same. WP:NOTBROKEN applies to an article that says, for instance, "He was born in Montmagny-L'Islet-Kamouraska-Riviere-Du-Loup". The link redirects to Montmagny—L'Islet—Kamouraska—Rivière-du-Loup. If you changed the link in such an article, you would change it to change how it appears to the reader, but not to "bypass redirects". In particular, you would never write [[Montmagny—L'Islet—Kamouraska—Rivière-du-Loup|Montmagny-L'Islet-Kamouraska-Riviere-Du-Loup]] because the redirect handles that link automatically, and there is no good reason to bypass according to WP:NOTBROKEN. That isn't the same as the bot that fixes double redirects. There are no redirects redirecting to Montmagny-L'Islet-Kamouraska-Riviere-Du-Loup, because if there were, a bot would have fixed them.
Come to think of it, for these ridings, hyphens are preferable to en dashes anyway. This is explained at Talk:Austria-Hungary#Dashes and at Wikipedia talk:Manual of Style/Archive 114#Hyphens vs. dashes in German federal-state names. Art LaPella (talk) 15:26, 1 June 2010 (UTC)

Recording consensus on unit usage

(Moved to MOSNUM page by original author) Martinvl (talk) 07:26, 1 June 2010 (UTC)

Actually, nobody moved it to MOSNUM. (WP:DASH isn't at MOSNUM anyway.)

That was a separate discussion, Art. Martinvl, who started said discussion thought it would be a better fit over at MOSNUM, but when he moved it he took the header with him, leaving this note attached to the Canadian riding discussion. oknazevad (talk) 18:51, 1 June 2010 (UTC)

Which units to use and how to present them

At the moment the Manual of Style deals with these two concerns in one subheading. I think it would be preferable to deal with them under two subheadings, one for which units to use and the other for how to present the units. Does anyone have any comments, suggestions or concerns about this proposal? Michael Glass (talk) 13:51, 1 June 2010 (UTC)

It is best to have discussion in just one place and I think MOSNUM is the appropriate venue. As such, see discussion already started there. _wjemather ^bigissue 14:18, 1 June 2010 (UTC)

Agree with wjemather. No need to split discussions. At best it is incredibly annoying, at worse it is forum shopping. Headbomb {talk / contribs / physics / books} 14:46, 1 June 2010 (UTC)

My purpose in putting this notice in this place was to let people know what I planned to do. It was not done to annoy or to forum shop, an insinuation that I totally reject. Nevertheless, for the convenience of all I would ask that if anyone on this forum has any comments, suggestions or concerns about my proposal that they put their comments at MOSNUM:talk Michael Glass (talk) 03:38, 2 June 2010 (UTC)

Review of Manual of Style (dates and numbers)

A review of the above page has now started. Interested parties are invited to contribute on the review page. Any improvement actions for which there is consensus will be completed during the review. The review is also now logged in the talk page header of the reviewed page, using the new {{DocumentHistory}} template. Enjoy! PL290 (talk) 21:08, 1 June 2010 (UTC)

We can't do a page review until we know what people want from the MOS and the out come of the SSG RFC Gnevin (talk) 21:34, 1 June 2010 (UTC)

I disagree--how can it hurt? We've been talking MoS reorganization for months. Life goes on. The possibility of a reorg is (and will always continue to be) an ever-present reality; any improvement to page content meanwhile can only be a good thing. Focusing on a page's role within the MoS is not incompatible with other goals. If you think reviewers may not be aware of wider reorg discussions, by all means add a review comment to draw attention to same, but it doesn't really make sense to talk about one being a prerequisite of the other. PL290 (talk) 05:25, 2 June 2010 (UTC)

Well if we starting a review , then fundamentally decided to change how the MOS is laid out then large parts of the review are going to be pointless Gnevin (talk) 08:45, 2 June 2010 (UTC)

Only if we decided to rewrite the MoS from scratch. Ain't gonna happen. Any reorg will use existing content. PL290 (talk) 19:45, 2 June 2010 (UTC)

If we decide to centralize the MOS and delete the sub-pages this is a total waste of time Gnevin (talk) 19:58, 2 June 2010 (UTC)

Only if we decided to rewrite the MoS from scratch. Ain't gonna happen. Any reorg will use existing content. PL290 (talk) 20:04, 2 June 2010 (UTC)

Why are you repeating yourself. How can we review the MOS if we don't know where the MOS could be in 30 days. What is your rush ? Gnevin (talk) 21:01, 2 June 2010 (UTC)

Sometimes it's necessary to repeat yourself, if people show no sign of having heard you the first time. Speaking of which, it just happened again. Please see the paragraph just above, starting "I disagree--how can it hurt?" Should you feel able to spare more than a brief second to consider a post, and to respond carefully and thoughtfully in terms that connect with what was actually said, perhaps a meaningful discussion will become possible. PL290 (talk) 09:07, 3 June 2010 (UTC)

Fine go a head and waste your time Gnevin (talk) 09:18, 3 June 2010 (UTC)

Gentlemen, please. Tony (talk) 11:04, 3 June 2010 (UTC)

I realize I haven't been our most active member over the past couple weeks but it seems to me that not knowing where the MoS is going to be in thirty days is pretty much business as usual. Gnevin has a point: anyone who minds the possibility that his or her work could be undone or rendered unnecessary by some later group decision should feel free to sit this one out. (Though that too seems BAU for Wikipedia.) Darkfrog24 (talk) 17:36, 3 June 2010 (UTC)

I know not knowing where the MOS will be in thirty days is pretty much business as usual but in this case we've SSG RFC active and a possible poll on the future of the MOS on the cards which is not business as usual both of which could radically change the MOSGnevin (talk) 21:42, 3 June 2010 (UTC)

Special Character Guideline Contradiction with WP:SP

The Manual of Style states that:

Avoid special characters [in titles] such as the slash (/)...

This contradicts with WP:SP, which states that:

Some topics have a slash in the name — e.g. GNU/Linux naming controversy or OS/2. This is not a problem. If that's what the thing is called, use the slash. In article namespace this doesn't define a subpage.

As the reason for The Manual of Style's prohibition of using slashes is a technical difficulty which is no longer a problem (since the use of subpages in the mainspace was disabled), I believe this portion of the guideline should be removed from the Manual of Style. Quinxorin (talk) 02:04, 2 June 2010 (UTC)

Here are the links for the guidelines cited above: ~~WP:MOS#Article titles~~ and WP:SP#Slashes in article titles (main namespace). Art LaPella (talk) 03:18, 2 June 2010 (UTC)

Well, your first link actually doesn't open to the correct heading, but this does:Manual of Style, Article Titles. Quinxorin (talk) 03:23, 4 June 2010 (UTC)

Issues caused by page moves

This just came to my notice. There seems to be some sorting out required. There may be other cases. Something we need to keep in mind when moving pages in future. PL290 (talk) 21:21, 3 June 2010 (UTC)

First letter between square brackets in direct quotations

If a sentence is quoted from a publication on which the first letter of the sentence in question is capital, isn't it appropriate to put the first letter between square brackets when necessary? Have a look at Head First (Goldfrapp album)#Critical reception for a better understanding. The closest I found on MOS:QUOTE regarding this matter was the following: "If an entire sentence is quoted in such a way that it becomes a grammatical part of the larger sentence, the first letter loses its capitalization (It turned out to be true that "a penny saved is a penny earned")." However, it is not clear if the first letter of the quotation in question ("a penny saved is a penny earned") was originally capital. Snap Snap 17:09, 1 June 2010 (UTC)

I think the MoS here just means to give an example of a complete sentence. In general, I prefer not to assume that the MoS reader will already know what I mean, but I feel that most of our readers will know that complete sentences such as "A penny saved is a penny earned" are supposed to start with capital letters.

Still, can you think of a way that this could be clearer? There's almost always room for improvement. This section of the MoS seems to be dealing more with general English rather than direct quotations. Maybe that's where the confusion lies. Darkfrog24 (talk) 19:29, 1 June 2010 (UTC)

Actually, the problem itself is not the "penny sentence" presented on the MoS, but the use of direct quotations in Wikipedia articles. Sorry if I didn't make myself understand. It's just that I used this method in Head First (Goldfrapp album)#Critical reception, putting first letters between square brackets in cases where the first letter of the original quotation was capital (you can have a better insight of the matter here), but another user removed them claiming it was an allowable typographical change as per MOS:QUOTE, and used the aforementioned penny sentence to support their removal, even though it's a common practice in album articles (and other articles as well, I suppose). However, MOS:QUOTE does not have any explicit guideline on the matter, since the penny sentence does not appear to be that helpful. I notice there are more specific talk pages; this was the closest I came across (end of the section), but no answer was given, so I decided to ask for help here since it's the most active talk page. Snap Snap 23:27, 1 June 2010 (UTC)

I think we agree that the proverb listed under this starts with a capital "A" when quoted by itself; that is, it was originally a capital letter. So why is it "not clear if the first letter of the quotation in question ('a penny saved is a penny earned') was originally capital", and why does the penny sentence "not appear to be that helpful"? Perhaps your unspoken point is that the MOS:QUOTE example says "It turned out to be true that ...", not just "Franklin wrote, ..." which would more closely resemble your own examples. Art LaPella (talk) 00:10, 2 June 2010 (UTC)

I think Snap means that this section of the MoS would be more useful if it used a direct quote from a source, which would indicate that yes, changing the first letter to lowercase-in-brackets would be an acceptable typographical change. However, since no part of the MoS, yet directly says that this rule applies to quoted material (though we can say that it implies it), it could be considered a case of us deciding on a new policy. Darkfrog24 (talk) 17:14, 2 June 2010 (UTC)

Way to go, Darkfrog. :) Snap Snap 22:36, 2 June 2010 (UTC)

I think that's what I said, but whatever ... Art LaPella (talk) 13:51, 3 June 2010 (UTC)

You didn't mention the square brackets, though. Snap Snap 19:36, 4 June 2010 (UTC)

MoS index, again

I am keen to create an index accessible through the kind of search box we have at the top of this page (the one that searches archives for this talk pages, which I've sourced to Template:Round in circles). Creating an index would, in my view, be of great service to editors. One of the most frequent complaints about the MoS is how much sifting people have to do to locate what they want to know. A good index has to anticipate all of the key words an editor is likely to enter, by working backwards from each "target".

Can someone advise me whether/how a search box can be easily created that will search a single page. This page would contain a huge number of entries based on key words users might enter into the box, with links to micro-topics on all MoS pages. For example, if a user wants advice on anything to do with percentages, it would provide the link if "percentage", "percentages", "percent", "per cent", or "%" were entered (these items would all have to be listed on the index page, which would have to contain much repetition and redundancy for this purpose).

Am I barking up the wrong tree, technically? Tony (talk) 09:06, 4 June 2010 (UTC)

Create a prefix for it. So for example [3] Gnevin (talk) 09:24, 4 June 2010 (UTC)

Thanks, but ... how do I create a search box that can be located anywhere, and that automatically inserts a prefix for, say, "User:Tony1/Sandbox for style-guide index"? At the "Round in circles" template page in edit mode, I can't fathom what to do—it's double Dutch to me. Tony (talk) 09:54, 4 June 2010 (UTC)

I assume you want it added to {{style}} or do you want a new template . I can do either for you Gnevin (talk) 09:59, 4 June 2010 (UTC)

Well it would be excellent if you were able to create a new template, one that initially just automatically adds "prefix Tony1/sandbox style-guide index" to the user's entry, but which I could later change if it turns into a useful device and I move the index into WP space. But I think it's important that the search box be located on other pages, such as at WT:FAC, etc. Possible? Tony (talk) 10:25, 4 June 2010 (UTC)

Well I created {{MOSIndex}} but why do you want it on WT pages wouldn't it be better on the MOS pages? Gnevin (talk) 10:54, 4 June 2010 (UTC)

Because MoS pages in all their complex structure are a benefit for the community at large, not just those who know about it already. FAC and FLC processes need instant access for MoS queries; I can imagine other places a search box would be useful. But it all comes down to how well it can be indexed: there's nothing more irritating than typing something into "Help" or "Search" on a website and getting no return, when you know there must be stuff on it. Thanks, Gnevin, for creating this; I'll investigate soon and get back to you. Tony (talk) 11:16, 4 June 2010 (UTC)

Ok I've dressed it up as a talk page Gnevin (talk) 11:24, 4 June 2010 (UTC)

Do you want something similar to Wikipedia:Manual of Style/List of talk page search boxes? -- Wavelength (talk) 13:26, 4 June 2010 (UTC)

Here is a sample of what I visualize for the index, showing search boxes for two pages. For other pages, the wikicode for the first box (and a blank line) can be copied and then it can be pasted multiple times in the edit window for the list of search boxes. Then, the page name in its two occurrences can be edited for each of the various pages. I recommend that the search boxes be listed in alphabetical order.

-- Wavelength (talk) 13:44, 4 June 2010 (UTC)

[I am correcting the wikicode for each of the sample search boxes. -- Wavelength (talk) 13:55, 4 June 2010 (UTC)]

Sorry, but if we're making a search box to find stuff, I think it ought search all of the MoS. Otherwise you'll have people having to know which place to look, with a lot of trial-and-error (and give-up) involved. I want to know whether to use U.S. or US or USA or U. S.; where do I search? I need to find out whether am or a.m. is the correct way; what search do I use? This problem isn't going to get solved by the search buttons I see above. To get folks to use/rely on the MoS, it needs to be easy to find stuff in it (you've all agreed this), and separate buttons won't get us there. Or am I enormously misunderstanding what you're aiming for? Is that upper button supposed to search all the pages? — JohnFromPinckney (talk) 14:10, 4 June 2010 (UTC)

We have a search box that search most of the mos on the style template . I say most as one or two mos pages still aren't titled correctly Gnevin (talk) 14:56, 4 June 2010 (UTC)

I now realise my idea of manually preparing a huge list of targets on a single page that would in turn link you to the place you want to go to, on any MoS page, was very complicated and would need to be constantly updated anyway. The fully automated function you guys have assumed would be much preferable. In which case Wavelength's boxes—"Search Wikipedia:Manual of Style" and "Search Wikipedia:Manual of Style (dates and numbers)"—are moving towards that goal. But is it possible to make two critical changes?

As JohnFromPickney suggests, and Gnevin suggests already exists (?), could all MoS pages be included in a single box?
Could we have two buttons for it, as I think Gnevin was toying with: "Search exactly this wording" and "Search for all of these words"?

For example, I typed "-ly adverb" (without the quote-marks) into Wavelength's first box, for MoS main, and got nothing. I had to put quote-marks around it to get the solution (I don't expect editors to know that that is the signal for "search exact wording"), and it delivered exactly the result I wanted: the WP:MOS#Hyphens section. It would be good to avoid the quote-marks. Tony (talk) 15:28, 4 June 2010 (UTC)

The two buttons are labelled confusingly by default . One searches all of wiki the other searches just the prefix rather than full or partials matches what's why I change the example above. The best we could do it offer a link to Help:Searching Gnevin (talk) 18:12, 4 June 2010 (UTC)

"–present" in article body

I could have sworn I read somewhere that using "–present" after a date in the body of an article was not recommended (but was okay for summarizing in infoboxes). Instead, one should say, e.g., "2008 onward" or something similar (I haven't seen any other choice of word used). I've searched WP:MOSNUM, where I thought I'd read it, but this guideline isn't there. Any ideas? – Kerαunoςcopia^◁_galaxies 18:34, 6 June 2010 (UTC)

See WP:MOSBD. -- Wavelength (talk) 22:38, 6 June 2010 (UTC)

Exactly... the editor I first saw making these edits used WP:OTHERDATE in his edit summary. This leads the reader to WP:MOSBD. The guidelines seem to be hinting that date ranges should not end with a hyphen. But there is no mention of the word "present" or the phrase "to the present", so I'm still not sure what the suggested use would be. In my particular examples, they would be date ranges for periods of time within, say, a band or a singer's career. 2000–2002, 2002–2008, and 2008... – present? or onward? – Kerαunoςcopia^◁_galaxies 22:58, 6 June 2010 (UTC)

I don't have full support of any one specific format ("2008-", "2008-present" or "2008 onward") but I am fully in agreement that this needs to be mentioned in the MOS. "2008 onward" appears to be the most logical choice (at least in this example of a history section divided by dates). The closest guideline I find is "When the date of death is completely unknown, it should be extrapolated from last known period of activity". Does this mean we should make the range "2008-2010"? My opinion is that a new guideline be included in WP:OTHERDATE (so that it is not merely a USELESS section that says "look at what you just read in WP:MOSBD and do that") with guidelines that specify what to do for date ranges not involving the lives of people. ~ [ Scott M. Howard ] ~ [ Talk ]:[ Contribs ] ~ 23:30, 6 June 2010 (UTC)

Investigating the MOS history, I found that this edit removed what K is referring to:

The form 1996–present should be avoided in the main text of articles, though it may be used in infoboxes, crowded templates or lists, with the caveat that they may need to be examined by editors more frequently to see if they need to be updated; it is helpful to other editors to add an HTML comment immediately after such constructions, giving the as-of date, e.g.: . The form since 1996 should be used in favor of 1996–present in normal article text.

The edit further references this discussion regarding its removal and yet I only see mention of it being called a "dead horse" without citing previous discussion. It appears to only have been removed to avoid arguing over if a format should have spaces between the dash ("2008-present" vs "2008 - present"). If we're beating a dead horse here, what did the horse say before it died?

Should we be using "Since 2008" instead? And isn't there a better way to include this into the MOS? ~ [ Scott M. Howard ] ~ [ Talk ]:[ Contribs ] ~ 23:43, 6 June 2010 (UTC)

Wow Scott, that's great that you found that paragraph. That's exactly what I remember reading; ~~my search for this paragraph in the history must've been too far back or not far back enough.~~ (I was using a bad keyword search, I remember now.) I don't understand why it was removed. While I didn't read the entire original debate(s), it seems to me that the discussions were about the spacing of the endash—what does this have to do with removing "since 1996"? This really probably wouldn't be an issue if this paragraph never existed; but it did, and now some of us remember it, and now I'd love to have a consensus on whether or not "–present" is acceptable in date ranges that are not specific to births and deaths. Because the paragraph was removed, for now, I'm going to have to presume that "–present" is suitable for at least the needs addressed above (viz., date ranges for career paths, etc.). – Kerαunoςcopia^◁_galaxies 02:30, 7 June 2010 (UTC)

I knew I'd read that somewhere. See, I'm not going mad! Since the dispute seemed to centre more around the colour of the wheel than the wheel itself, I'd say that passage should be reinstated- I doubt Keraunoscopia and I are the only editors who remember it and, as a GA reviewer, it would be nice to have something to quote other than "I vaguely remember reading something somewhere once". HJ Mitchell | Penny for your thoughts? 03:11, 7 June 2010 (UTC)

Maybe we should contact the contact the person who removed it from the page and ask their reasons for deleting it. Below shows the decision to remove it:

If it's a dead horse, why is it buried in MoS, and who's flogging it? I'd be quite happy to see it removed. While it remains, it has a bearing on the way this thread develops. PL290 (talk) 13:30, 11 March 2010 (UTC)

But why the entire section was removed rather than just rephrasing or fixing what conflicted with their current discussion, I don't know. I'm in total agreement with simply adding the information back in. ~ [ Scott M. Howard ] ~ [ Talk ]:[ Contribs ] ~ 03:15, 7 June 2010 (UTC)

Contacted. I wouldn't mind having the passage reinstated either. Sort of surprised no one else has commented here. – Kerαunoςcopia^◁_galaxies 04:20, 7 June 2010 (UTC)

WP:MOSBD says "Dates that are given as ranges should follow the same patterns as given above for birth and death dates." Specific wordings are not spelled out, but, with a little bit of thinking, we can produce wordings such as "The humanitarian relief began on June 1, 2010" and "the long war which came to an end on August 1, 2010". -- Wavelength (talk) 07:15, 7 June 2010 (UTC)

Hi Wavelength, thanks for the examples, but we understand that. I think I'm probably not making my specific example clear: in a level 2 or level 3 heading where an article is broken up into a range of dates, which is preferred for the "current" date (avoiding the use of "current', of course). Check out the Metallica page here: Metallica#Death_Magnetic_.282006_onward.29. This section could essentially be titled, for example:

2006–present
2006 onward
Since 2006

With the above paragraph (found by Scott) previously included in the MOS, I saw an editor change the "–present" into "onward" and cite WP:OTHERDATE in the summary. With the above paragraph removed... well, since several of us remember the paragraph, we're curious as to what to do now. Is "–present" acceptable or not? – Kerαunoςcopia^◁_galaxies 07:46, 7 June 2010 (UTC)

"[year]–present" is abominable in all places, especially in text that is likely to leave the notion of "present" beyond its use-by date. Just why this longer item should be allowed in infoboxes, where space is at a premium, is beyond me. What is wrong with "Since 1996"? Forget the "onwards", please. Tony (talk) 08:26, 7 June 2010 (UTC)

I'm all for whatever, but I want the MOS guide to have it written in stone. – Kerαunoςcopia^◁_galaxies 08:34, 7 June 2010 (UTC)

It appears that PL's reasons for removing (as outlined in the discussion linked below) is that there is no consensus on which format to use. There are advantages and disadvantages to either uses and strong support for both sides. Since no consensus can be reached (there is likely multiple other archived discussions on this topic), it's best just to leave a set-in-stone guideline off the MOS. This now leaves editors to simply do what's best for EACH particular case and create their own editors' consensus for that article. I'm somewhat dissatisfied by this outcome, but until a consensus can be reached, this appears to be the best solution for both sides. ~ [ Scott M. Howard ] ~ [ Talk ]:[ Contribs ] ~ 12:35, 7 June 2010 (UTC)

I see. This discussion is sort of the sequel; no consensus is being reached. I'm admittedly a weak link because I'll go with whatever way works; I have no major qualms with either –present or since or {{as of|year|alt=present}}. But since no consensus was reached, I don't see why there should be any major change to the standard at the moment, which is –present. – Kerαunoςcopia^◁_galaxies 19:16, 7 June 2010 (UTC)

The dead horse

The removal of the "dead horse" triggered this discussion on the Manual of Style (dates and numbers) talk page. (It went on for a couple of weeks in March; perhaps the folks now asking don't watchlist that page, or were not around at that point.) It turned out there were strong opinions both ways, but most people were of the opinion that "1990–present" is desirable, because it conveys a specific fact, and that the reason given for avoiding it (articles can become "wrong") is fallacious: "Since" or "Began" have no advantage over "present", because of their ambiguity. "Began 1990" is no better than "1990–present" for a series that has ended: either way, the article will need updating when the information ceases to be true. The conversation was primarily about infoboxes, but applies equally to section headings. PL290 (talk) 08:49, 7 June 2010 (UTC)

Ah, thank you for linking that discussion! So really we're just continuing the circle here. – Kerαunoςcopia^◁_galaxies 19:15, 7 June 2010 (UTC)

Split-apart of MUSTARD

Proposal to split apart Wikipedia:Manual of Style (MUSTARD) and merge it into the other Music Guidlines. See Wikipedia talk:Manual of Style (MUSTARD)#Page Split --Jubilee ♫clipman 20:40, 8 June 2010 (UTC)

Extremely bold idea

Delete Wikipedia :Manual of Style! All this pages does is inaccurately and inconstantly repeat what it's sub-pages says. Does this page say anything unique that can't be merged into a sub-page ? How would users feel about deleting this page and replacing with a page like Wikipedia:Subject style guide which explains the purposes of MOSs and some MOS stuff like naming and conflicts Gnevin (talk) 11:37, 21 May 2010 (UTC)

I think Gnevin's proposal is a little too bold. But my researches convince me that most of MOS was produced very quickly by a handful of people and with no consultation - in other words, MOS never had WP:CONCENSUS. I suggest a Zero-based budgeting approach, in other words each part of the current is out unless it's justified and gains concensus. Of course pure zero-based budgeting would leave no MOS at all, which would lead to chaos. I suggest the new MOS should include the parts specified in WP:WIAGA, or even just WP:LAYOUT, which provides benefits to readers and editors but with at minimal cost. --Philcha (talk) 13:01, 21 May 2010 (UTC)

Zero-based budgeting is an interesting idea. How would it work for the Main MOS. Do we just keep removing sections until people object? Gnevin (talk) 13:46, 21 May 2010 (UTC)

Needs a centralised location. Ease of consultation by editors is of the essence. Tony (talk) 13:17, 21 May 2010 (UTC)

How is a centralised location helpful? It's so often wrong to be useless. Have a overview page which points users to the one the centralised location where there issue is handled . Got a question about icons? WP:MOSICON. Got a question about tables? WP:Table Gnevin (talk) 13:44, 21 May 2010 (UTC)

A centralized location is helpful because it's easier for people, especially newbs, to find. I remember when I was new that I'd sometimes have to click through six and seven and ten pages of loosely interconnected pages before finding the relevant rules. If it were up to me, I'd make Wikipedia's guidelines even more centralized.

In addition, so many other organizations (even ones like NASA that aren't primarily about writing) have their own style sheets that many people will expect Wikipedia to have one—in the sense that someone who is wondering about capitalization or style issues will know to run a search for a "style sheet" or "manual of style." Such a person would not know to look for sub-pages.

Lastly, and I know this isn't a majority view, I believe that the Wikipedia style guide has a huge opportunity and responsibility to instruct Wikipedia users in correct and proper English. Yes, there are way too many codified pet peeves, but the solution to this is to rely on outside style guides of good reputation rather than on our own opinions. Darkfrog24 (talk) 14:43, 21 May 2010 (UTC)

To me Category:Wikipedia_Manual_of_Style solves the issue of being bounced around the MOS randomly Gnevin (talk) 16:05, 21 May 2010 (UTC)

Here is an even more bold idea:

Forget about the MOS and its subpages entirely. The second biggest Wikipedia (the German one) does not even have a MOS.
As a replacement, put some effort into WP:Writing better articles, which is our neglected equivalent of the central German page de:Wie schreibe ich gute Artikel.
Follow the principle "show, don't tell" to the extent possible on such a page, i.e.: Apply the principles for writing good articles to the page itself, where applicable.
Create subpages for that page to the extent necessary. Follow these principles:
- The creation of a new subpage requires consensus.
- There is a rigid upper limit for each page, which should be fixed upon creation. It can only be changed by consensus.
- Whoever wants to add something that would take a page above the limit must get a consensus for removing something else that is less important.

This would end the artificial separation into style advice and non-style advice for improving articles, and it would prevent cancer-like growth that results in an unreadable mess.

The MOS problem is a tragedy of the commons problem. We all have our pet peeves that we want included in the MOS so that others will be informed about them. Every single one of them contributes only a little bit to the MOS chaos. Collectively they make the MOS unreadable, so that in the end nobody is informed about anything.

This is not a serious proposal, as I don't think there is any chance of it being realised. But if there is some support for it I intend to bring it up occasionally over the next few years until the support gains critical mass. Hans Adler 13:29, 21 May 2010 (UTC)

Isn't just the MOS in a different name Gnevin (talk) 13:44, 21 May 2010 (UTC)

Hans, I'm glad to hear you say it's not a serious proposal (and I think WP.de does have a MoS under a different name, as Gnevin suggests). I wonder whether you've taken into account the unique characteristics of English: it's big and baggy and worldwide, and for this very reason needs in-house regulation. German, French and other European languages are not nearly as widely spread and have a much greater sense of ownership by authorities. The German/Swiss/Austrian parliaments passed laws on spelling reform last decade; the French are well-known for exerting linguistic control from the top. The Russians do it by government decree through their education system. That would never happen in the anglosphere, and paradoxically (on the surface), it is why publishing houses and a site such as WP have to operate in a more regulated linguistic environment.
While on this topic, we desperately need a MoS-wide index; that is, a micro-index that lists in alpha order individual words, items, and phrases. My question is this: does WP have at hand a technical facility by which a search-box can be used to type in and find items on a single page? If so, this is surely the way to go. It would be a considerable advance to install such a search box at key locations, such as at the featured content processes and, indeed, each MoS page itself. Tony (talk) 13:50, 21 May 2010 (UTC)

I'm pretty sure no but maybe ask at WP:VP/T to be sure Gnevin (talk) 13:59, 21 May 2010 (UTC)

Technical facility by which a search-box can be used to type in and find items on a single page: any browser I've seen can do this easily by itself. Or am I misunderstanding the question?—Emil J. 14:16, 21 May 2010 (UTC)

Yup, any browser will do it for a single page, and I expressed myself badly. I am suggesting the creation of an index for all MoS pages, so that you are provided with links to not just MoS main's treatment of a particular matter, but other style guide's treatments. Tony (talk) 14:44, 21 May 2010 (UTC)

OK, so I indeed misunderstood it. Now, if I want to know what the MoS has to say about, say, commas, it is possible to search for comma incategory:"Wikipedia Manual of Style" or comma prefix:Wikipedia:Manual of Style". This may be sufficient instead of an index. The "search archives" box on the top of this talk page does a similar thing, so it should be easy to wrap in something user friendly.—Emil J. 15:02, 21 May 2010 (UTC)

Hmm. And the reason the first one does not give useful results is that the category search does not traverse subcategories.—Emil J. 15:21, 21 May 2010 (UTC)

Which makes it nearly useless... I'll ask at the VP whether there's a good reason for that, and if not I'm going at Bugzilla to propose that they traverse them. A. di M. (talk) 18:51, 21 May 2010 (UTC)

I disagree with the idea of throwing away the page (ideally, WP:MOS should contain all the most important info which you'll need more often and the subpages should focus on details you'll rarely have to deal with), but I agree that there are a huge amount of bloat and instruction there's never been a strong consensus for. Re-writing a style guide from scratch would be an unrealistic idea, but we need to seriously reflect about whether all of the content of Category:Wikipedia Manual of Style (which would probably fill several volumes if printed) is really useful enough to justify its existence. (As for Tony's point, Spanish is nearly as scattered as English, and the Spanish Wikipedia's MoS is about one order of magnitude smaller than the English one's.) A. di M. (talk) 14:13, 21 May 2010 (UTC)

To write a 2 line stub you need to know about Layout, Capitals , Article titles, headings, sections,bold,Punctuation,link,categorisation. All of which are covered terribly here but in most cased excellently in their actually page. If I blanked this page and left {{Style}} would users be worse off,would they lose any information ? My opinion is no Gnevin (talk) 14:22, 21 May 2010 (UTC)

Errr ... my impression is that the outlying style-guide pages are a mess, and that this one is a relatively well-tended garden, even though it's not perfect. Binning MoS main would be a frightful move. I agree with A. di M. (but on the tiny Spanish MoS, well that really is a problem for them, but much of my point concerns the intrinsic nature of English versus the other languages: English is very dynamic (changeable); I suspect that formal Spanish, at least in written mode, is more conservative and ... straight-laced, for want of a better word). Same for Italian, I'm bold enough to guess, hehe. Tony (talk) 14:41, 21 May 2010 (UTC)

The outlying MOS if you remove the stuff going to the SSG is of a far high quality generally. I've removed about 20 pages of nonsense from the MOS since this whole process began. For me Wikipedia:Manual of Style (capital letters) which is on of the worse outlying MOS is far better than the multi colours ,randomly formatted , randomly broken up Wikipedia:MOS#Capital_letters while Wikipedia:Layout is miles better than anything this page offers Gnevin (talk) 16:02, 21 May 2010 (UTC)

Usage always wins in the end. English has the sense to acknowledge this. Whatever the Français Academie says, Jacques Bonhomme uses colloquial French, with Franglais when it suits him. --Philcha (talk) 15:36, 21 May 2010 (UTC)

That's the point to improve the treatment of those at WP:MOS, not to remove it. It's unhelpful to have someone about to write a two-line stub wade through WP:Layout, WP:MOSCAPS, WP:TITLE, ..., WP:CAT with all that stuff which is unlikely to interest them, such as WP:MOSCAPS#Military terms and the like. A. di M. (talk) 16:25, 21 May 2010 (UTC)

Surely they've to wade through all more unrelated stuff here? I mean your argument applies either side and no one has addressed the fact this MOS is stop out of step with the rest of the MOS. I mean in a case of WP:MOSCAPS disagrees with WP:MOS which takes precedent for me its the dedicated MOS not this random collection of nonsense Gnevin (talk) 17:15, 21 May 2010 (UTC)

Indeed, I think that this page has to be seriously trimmed. A. di M. (talk) 18:51, 21 May 2010 (UTC)

As I said back in April, if you read the MoS like a book, you're doing it wrong.

The problem isn't that the MoS is badly built, the problem is that some people don't know how to read a manual of style, thus complain about whatever. What is my answer to these people? Give them the Chicago MoS and they would be just as intimidated by it if not more. This is a general manual of style, not a book, and thus should read like a general manual of style. In fact Wikipedia's MoS should be many times more massive because:

We often do not have the luxury of imposing styles, and often we must not only provide more than one, but explain them as well as their pros and cons;

We cover a wider range of topics, allow for a wider style of articles;

We cover interactive online-media; a general MoS covers printed media;

We need to address the concerns which would generally be found in a field-specific MoS. Chicago doesn't address the matter of how to write mathematical formulas, chemical formulas, and so on;

We need to address concerns which are usually left to publishing houses and fall outside the scope of a generalist MoS;

We are volunteers, many of us amateurs, many of whom are unable to write at the professional level, and many of whom don't know the first thing about the art of publishing and its zillion details, and thus we need to provide more guidance than a general MoS would, and do a job few of us has done before;

Chicago has the luxury of telling people "This is how you should do it, and if you don't like it that's your problem." We don't.
If people expect to read the MoS from front to back before editing pages, they are doing it wrong. A manual of style is a reference, meaning that you look at the TOC, go to the relevant section, and get your answer. When you have your answer, close the page, and get back to work. It makes no sense to complain about "It's too long, because it contains information about blazons!". If you don't edit heraldry pages, then you shouldn't be reading the section on heraldry in the first place. Headbomb {talk / contribs / physics / books} 03:57, 1 April 2010 (UTC)

The MOS is a manual of style, not a "guideline to only what I, editor X, need". I suspect most who complain about the MoS being "too long, bloated, etc..." have never even held a manual of style in their hands. Headbomb {talk / contribs / physics / books} 04:55, 22 May 2010 (UTC)

Of course. Like me, for instance; I've never held one. Therefore, expecting me to look up answers in the Manual of Style as if it were a phone book is unrealistic, because I wouldn't have known something like curly quotes was even a problem. If a readable summary of the Manual of Style violates what a style manual is supposed to be, then call it something else; call it a banana, but by any name we need one. Art LaPella (talk) 06:39, 22 May 2010 (UTC)

I guess the Chicago MOS doesn't discuss all of those things in the same place, but rather is subdivided in chapters, sections, subsections and so on, with a decent table of contents allowing to quickly find what one needs, isn't it? And still I don't see what would be wrong with having some kind of introductory page addressing those issues likely to occur the most often, much like (say) the NIST site on physical constants has a "frequently used constants" page as well as an "extensive listing" page. A. di M. (talk) 10:08, 22 May 2010 (UTC)

Back to the MoS search-box/index idea: who wants to type in a string as long as comma incategory:"Wikipedia Manual of Style"? No one. It needs a search-box where you can type in the items we specify, otherwise you'll get huge numbers of false positives, anyway. It needs to be cross-page through all of MoS. And simple to use. Tony (talk) 05:18, 23 May 2010 (UTC)

Throwing out the MOS wouldn't be "bold" it would be wildly reckless. We don't really care what de.wiki is doing, any more than they care to abandon how they do things and create a MOS. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 18:46, 25 May 2010 (UTC)

Arbitrary break (Extremely bold idea)

In a case of WP:MOSCAPS disagrees with WP:MOS which takes precedent for me its the dedicated MOS not this random collection of nonsense? Can I suggest we remove or great trim any advise the MOS give which has a sub page ?Gnevin (talk) 10:46, 22 May 2010 (UTC)

How does MOSCAPS disagree with MOS? Headbomb {talk / contribs / physics / books} 15:03, 22 May 2010 (UTC)

It's an example . If MOSCAPS disagreed with the MOS which takes precedent? Gnevin (talk) 15:25, 22 May 2010 (UTC)

If you want a specific example, compare the summary WP:MOSCAPS#Animals, plants, and other organisms to the details at WP:MOS#Animals, plants, and other organisms. No that isn't a typo; the details are in the summary and the summary is in the details. So if you only read MOSCAPS, which is a reasonable choice because it's supposed to be more detailed, you might provoke the birds cabal to a full-scale war. Art LaPella (talk) 00:45, 23 May 2010 (UTC)

Then raise the issue and resolve the contradiction. Headbomb {talk / contribs / physics / books} 01:06, 23 May 2010 (UTC)

Does that mean you want me to go through everything again and list contradictions? Let's see if Gnevin's current initiative resolves them. Art LaPella (talk) 05:11, 23 May 2010 (UTC)

I've swapped them. Revert me if I've opened a can of worms (which I hope I didn't, as I just copied and pasted). A. di M. (talk) 16:07, 25 May 2010 (UTC)

I oppose throwing out this guideline, since I have found WP:ENGVAR salutary in helping to resolve endless and pointless arguments over whether British or North American English grammar, spelling, or terminology are "correct." The Manual of Style is a valuable part of Wikipedia, where stylistic differences can be resolved and a record kept of the consensus, rather than a recurring free for all of reverting in every article where contributors are used to, or prefer, different styles. Edison (talk) 21:42, 26 May 2010 (UTC)

#Extremely bold idea starts out with the words "Delete Wikipedia :Manual of Style! All this pages does is inaccurately and inconstantly repeat what it's sub-pages says." Moving things like ENGVAR to subpages isn't the same as throwing them out. The issue here is how to arrange the rules, not repealing them. Art LaPella (talk) 04:30, 27 May 2010 (UTC)

Some users have said the out lying MOS are a mess which is a lot of cases is true. What if we cut the entire contents of

Wikipedia:Manual_of_Style#Grammar and created Wikipedia:Manual of Style (grammar)
Wikipedia:Manual_of_Style#Punctuation and created Wikipedia:Manual of Style (punctuation)
Wikipedia:Manual_of_Style#Numbers ,Wikipedia:Manual_of_Style#Chronological_items and replaced/merged into Wikipedia:Manual of Style (dates and numbers)
Wikipedia:Manual_of_Style#Capital_letters and replaced/merged into Wikipedia:Manual of Style (capital letters)
Wikipedia:Manual_of_Style#Acronyms_and_abbreviations and replaced/merged into Wikipedia:Manual of Style (abbreviations)

etc ... Gnevin (talk) 14:08, 28 May 2010 (UTC)

May I be blunt? Because a lot of users want a centre of gravity on WP where they can see a significant body of advice in one place. And because the trade-off in having subpages is that they are high-maintenance to coordinate. MoS main page requires no interplanetary expeditions to places where the locals might be friendly or might not; it encourages no outlying patches of ownership. It brings together a strong editorial team to provide cohesive leadership on style, even if we don't always achieve it and occasionally squabble. Tony (talk) 15:00, 28 May 2010 (UTC)

In these days of tabbed browsing and high-speed broadband I just don't see it. In fact when I see long reams of text I think to my self why ? . The same coordination trade-off applies by having sub pages and a central page,in fact it's worse with a centralised pages . We have 2 pages claiming to be the authority on a subject which no clear guidance which is correct. "It brings together a strong editorial team to provide cohesive leadership on style" this clearly has not happened and in fact the MOS has become a bit of a joke . We need to stop duplicating concepts in a random and chaotic fashion. I've no real preference here either we make this a page about the MOS and move all it's content to sub-pages or we delete the sub-pages and up-merge here I just don't see anything else working. The parts of the MOS that work best at the moment are parts like WP:MOSICON ,WP:W2W is it just a coincidence these pages don't have any real presence in the main MOS ?

I'd like to suggest a poll with 3 simple and clear options .

Make Wikipedia:Manual_of_Style about the MOS and not about style such as Wikipedia:Subject-specific guidelines, with all content being moved to relevant sub pages such as Wikipedia:Manual_of_Style#Acronyms_and_abbreviations merged into Wikipedia:Manual of Style (abbreviations) or make Wikipedia:Manual_of_Style centralised with stylistic issues for issues with about a deadicated MOS such as User:Gnevin/MOS
Make Wikipedia:Manual_of_Style the core page with sub pages that currently feature heavily being up-merged here such as WP:MOSCAPS
The status quo Gnevin (talk) 15:51, 28 May 2010 (UTC)

I prefer 1 to 2. But nobody has explicitly argued that the summary of a guideline should almost duplicate the details of a guideline. Whenever the summary almost duplicates the details, the only debate should be about how to fix it, and I don't understand why that hasn't happened. If we want ownership (despite the rule against it), then I would think that is an argument for choice 2 not 3. As for what "a lot of users want", Wikipedia:If you could re-write the rules includes many comments on the MoS. Art LaPella (talk) 22:31, 30 May 2010 (UTC)

I'm sorry but I don't understand. Can you clarify? Gnevin (talk) 07:55, 31 May 2010 (UTC)

Hmm, I made several different points so I don't know which one needs clarifying ...

I prefer 1 to 2 (rejecting 3).
Nobody has explicitly argued that the summary of a guideline should almost duplicate the details. MOS:NUM#Percentages, for instance, makes only one point more than the "summary" version WP:MOS#Percentages. Is anybody defending that situation? If not, why can't we agree it needs some kind of correction?
"Ownership" comes from the post above from 15:00 28 May: "outlying patches of ownership". (The rule is of course WP:OWN) Anyway, that would be an argument for collecting everything on one page, not for keeping so much duplication. However, we should remember that Tony's preferred option is at User:Tony1/Beginners' guide to the Manual of Style.
What "a lot of users want" is another quote from the same 15:00 post above. A relatively impartial source of what a lot of users want is Wikipedia:If you could re-write the rules, which has comments you can find by searching for "MoS " (with a space after). Several people said "streamline"; nobody said "Please add 100 pages of explanation to guide us in case an en dash joins surnames containing spaces." Several people said fewer subpages, but that was in the context of axing the monster down to size, not combining it all into one; and somebody suggested a MoS for Dummies summary. And several people complained about contradictions. Art LaPella (talk) 22:33, 31 May 2010 (UTC)

I agree Gnevin (talk) 09:48, 1 June 2010 (UTC)

I won't get too involved in these discussions, although it's interesting to me since I was the major contributor for Sentence spacing in language and style guides and reviewed 50+ U.S. and UK style guides (among others) while researching English writing conventions. I'll just leave a few thoughts and let everyone keep sorting through an issue that seems unsolvable to me under the current circumstances on Wikipedia.

The English Wikipedia needs a style manual in some form. There is no single authority in English that makes binding decisions like some other languages like French, Spanish, Albanian, etc.
It will have to be comprehensive. It will be lengthy and that's ok. It must be a reference work (which would be a primary source reference for Wikipedians), not an encyclopedia article (a tertiary source). It doesn't matter how long it is.
This isn't a Wikipedia article. That's worth noting again. It's a primary source reference for Wikiepdia editors. Up to a point it can be built by consensus. At a certain point, it will not be possible to move forward in the normal Wikipedia manner. If we're not there, we'll be there in the next year or two. There are too many people that have closely-held style preferences and want to make sure they are included. E.g., there are no known style or language guides that allow double sentence spacing in final or published work (the Wikipedia article that the average visitor to Wikipedia sees). Most specifically prohibit the use (such as the Chicago Manual of Style and Oxford Style Guide). However, any mention of this has been blocked vigorously by Wikipedia editors that ignore what reliable style guides say, and prefer to make sure their style preferences are included here. This is one example of many I could note.
'Comment. The average visitor to Wikipedia will see one space at the end of each sentence no matter what's done in the source, because browsers collapse any number of spaces to one on displaying the page, as required by the HTML standard. A. di M. (talk) 13:44, 4 June 2010 (UTC)
So what's the answer? I don't know. The "delete the manual of style page" thread is an interesting way to try to wake people up—something needs to be done. I'll throw one idea on the table.

The Wikipedia Foundation (or whatever admins have the ability to do this) could arrange a panel (paid or otherwise), lock the manual of style, and create a tentative product that reflects some of the most reliable published style guides out there. The page would then be unlocked for editing, but a consensus would have to be reached to change an established style point.

I don't know the feasability of the above. Here's what I know.

Reliable style guides use a small panel of experts to decide conventions—which can change over time.

Asking everyone's opinion (expert or non-expert) will leave unsolvable problems (such as typewriter conventions that never die). A small panel of experts might agree that certain conventions should be used on Wikipedia, and they will be overridden by the average writers out there that have emotional responses to them (or just don't know any better). This problem is unsolvable in the current setup. A monthly or quarterly revision of a locked Wikipedia Style Guide might be the long-term solution—as distasteful as that might be for some editors.

Progressing in this manner is far harder than it should be. I'd be interested in knowing how many man-hours have been wasted on fruitless discussions on topics that, if put in front of the editorial panel for the Oxford Style Guide, would be laughed at and dismissed. I understand that Wikipedia was built on the principle that anyone can edit an article. However, this is not an article. It's a primary source reference tool for Wikipedia editors. That should be kept in mind.

Final thought. We need a vision for the style manual page. How do we envision the Wikipedia style manual looking in ten years? What is the ideal way to run it when we've reached a 90% solution? I've proposed a separate section on typography here that would consolidate typography and design topics—in a manner similar to comprehensive print style guides. There's been little discussion because it's too big of a leap for most editors here. There's no long-term vision that advocates large leaps that will improve the final product. Once there is a vision with an endstate in mind, all efforts should move toward that goal. However, it may be easier to agree on a vision than it would be to agree on specific conventions. Then, when people complain that a style convention was settled on that they don't agree with, everyone can point and say "it's part of the vision."

Just thoughts. --Airborne84 (talk) 00:44, 4 June 2010 (UTC)

I yield to your knowledge of publications like the Oxford Style Guide, but I note that nothing above addresses how to get Wikipedians to actually use the information we have now. Thus I assume you are right about double spaces (although you seem unaware that our software suppresses double spaces anyway), but most articles are written with little understanding that the Manual of Style even exists. Some of its rules (like WP:NBSP for World War II) are routinely ignored even in featured articles, and featured articles are an insignificant fraction of Wikipedia. That problem would be magnified if we mimicked style guides intended for professionals. We can link to unlimited information, but only if it doesn't get in the way of what we can realistically get people to actually use. Art LaPella (talk) 02:01, 4 June 2010 (UTC)

A couple of comments:

I'm familiar with HTML's spacing conventions as well as other digital spacing issues. This thread [4] is the type of issue I'm talking about—a discussion which you may remember. However, you're right in that my comments were meant to be very general and address the macro problem.

The Chicago Manual of Style, the Oxford Style Manual, and even foreign style guides like Italy's Il Nuovo Manuale di Stile are also written for the average writer. In many cases, they do not severely restrict writers in style matters. Chicago, for example, allows different types of usages for some conventions - as long as they are consistent. However, I simply meant to highlight the more efficient way that they make decisions on usage.

The above discussions about whether to use sub-pages, etc. address, in part, the larger issues regarding the Manual of Style here. However, it may be better to determine whether sub-pages are part of the "10-year vision" for the Wikipedia style manual first. I'm talking about a overall plan that drives these issues, instead of these issues driving an overall plan (which won't happen effectively or efficiently).

These are just words—which mean little here without a consensus. I just don't see a consensus being built over the major issues under the current "everyone gets a say" Wikiepdia method of creating a manual of style. I probably should have just abstained, since the opinions of individuals here, even experts IRL, are weighted the same as anyone with access to the Web. It's a good way to build Wikipedia, but an extremely challenging way to build a useful manual of style for the same. I wish you all the best of luck though. --Airborne84 (talk) 03:54, 4 June 2010 (UTC)

I too have often been frustrated at my inability to get clearer explanations of Wikipedia procedures approved by a consensus. Not because I understand the issues better than they do, but because my motivation is, well, different. Art LaPella (talk) 05:36, 4 June 2010 (UTC)

Oppose deletion, and disagree with the premise that "All this pages does is inaccurately and inconstantly repeat what it's sub-pages says." What this page does is provide a central point of access to all MoS content. That is a vital function, and removing it makes no sense. (Furthermore, deleting this page appears to have nothing whatsoever to do with the proposal for subject-specific guides, which should be considered in its own right.) This page needs reorganizing, not deleting. Various ways of doing this continue to be discussed. I have demonstrated one possible approach (reduce this page to a glorified table of contents) using a crude mock-up at PL290/MoS, and there are other ways to rebalance content with the same goal, i.e., a main MoS page that acts as a central point of access to subpages where the actual detail can be found. That should be our goal, not deletion of this page. PL290 (talk) 06:40, 4 June 2010 (UTC)

This isn't a vote. I've no issue with a table of contents and have suggestd it here Make Wikipedia:Manual_of_Style about the MOS and not about style such as Wikipedia:Subject-specific guidelines, with all content being moved to relevant sub pages such as Wikipedia:Manual_of_Style#Acronyms_and_abbreviations merged into Wikipedia:Manual of Style (abbreviations) or make Wikipedia:Manual_of_Style centralised with stylistic issues for issues with about a deadicated MOS such as User:Gnevin/MOSGnevin (talk) 07:41, 4 June 2010 (UTC)

While I'd like to say that the last time I checked (a while ago, I'll admit), MLA did permit either one or two spaces post-sentence, I do like most of what Airborne says. If it is possible to base the MoS on reliable style guides rather than Wikipedia consensus, then we should do it.

I'd also like to suggest that we think about what the MoS should contain (correct English, no exceptions) and getting Wikipedia editors to use it be considered two separate questions. After all, it's not like the MoS would prohibit someone with shaky English from contributing; it would only allow other users to go over that editor's work and correct it.

Art, I don't understand why you think that making the MoS more compliant with regular style guides would make it less likely to be heeded. Would you please explain your reasoning? Darkfrog24 (talk) 13:30, 4 June 2010 (UTC)

When a person originally discovers the Manual of Style, it isn't because he wants to look up our opinion on curly quotes. More likely he doesn't even know what a manual of style is. He can look at the table of contents and get some idea that it's something like high school English grammar. He will then look at the length of the page and decide he has better things to do. Now imagine that the page was 100 times longer! I have no objection to including 100 times more information. I just want it introduced a little at a time. At a newspaper, editors can presumably be fired for ignoring the style manual long enough. Therefore they can be given a 5-pound manual and be expected to find all the rules from the table of contents. Wikipedians are volunteers that can't be ordered to do anything, and the rest of you don't give me the feeling that you really understand how completely Wikipedians disregard most of the rules we have now. I can tell from my AWB edits. Multiplying the rules by 100 would cause less compliance, not more, unless those extra rules can be kept out of some kind of introduction. Once again, we can be "compliant with regular style guides"; it's our introduction that shouldn't look like a professional style guide. Art LaPella (talk) 14:21, 4 June 2010 (UTC)

I see. Why not create a manual of style page that has only a lede of a couple of paragraphs, and then links to the various "chapters" below? (Something like the archive box at the top of this page.) It would look like a stub. That will appear much less intimidating to the average editor and will reinforce that this is not an article to read from start to finish. It's a reference tool. --Airborne84 (talk) 16:01, 4 June 2010 (UTC)

It seems to me that some form of decentralisation is supported by the majority of users here . We just need to agree the fine detail Gnevin (talk) 18:16, 4 June 2010 (UTC)

Decentralization of detail yes; removal of central point of coherence, no. I'm not hearing any support for the latter. PL290 (talk) 18:20, 4 June 2010 (UTC)

Yes ,so do we want something like User:Gnevin/MOS or User:PL290/MoS Gnevin (talk) 18:33, 4 June 2010 (UTC)

The latter seems preferable. The lede would need to be enhanced a bit. The purpose of a style guide is to provide standards. Some of the standards are rather rigid English conventions (e.g., the first letter of each sentence is capitalized; a period, question mark, or exclamation mark are used to end sentences; etc.) Other topics are truly matters of style and are typically flexible - as long as the writer is consistent. So, a general statement in the lede that the style guide is intended to "provide a set of standards" would be useful, with the usual caveats here on Wikipedia briefly explained. --Airborne84 (talk) 20:53, 4 June 2010 (UTC)

Yes. I also like WP:COPYEDIT and I think it, or something like it, should be easier to find right away. Hundreds of copyeditors (teenagers for instance) could copyedit for years without needing to know any more than that. Hmm, I see it's no longer considered part of the Manual of Style. Well, link it from somewhere ... Art LaPella (talk) 22:07, 4 June 2010 (UTC)

The problem with PL's idea is subpages have been rejected Gnevin (talk) 11:00, 5 June 2010 (UTC)

Too strong a word. Status quo had more votes when that poll closed, but there was growing interest in subpages too. PL290 (talk) 13:02, 5 June 2010 (UTC)

What ever word you want to use. I see no evidence that CON has changed Gnevin (talk) 17:14, 5 June 2010 (UTC)

i agree there are problems with policy creep but torching an entire page is probably not the right way to get there... if someone has any other ideas i would gladly help... Arskwad (talk) 01:55, 7 June 2010 (UTC)

In response to Art's explanation, I find that decentralization is a bigger problem for new users. When I was new, I found myself clicking through six and seven and ten WP: pages just to find out where the rules were. That was what made me want to throw my hands in the air and give up. Not only was there a lot of information, but because it was scattered around, I had no idea how much there was in total. At least when there's one big page, people can see how big it is and look at its ToC all at once. Darkfrog24 (talk) 17:41, 7 June 2010 (UTC)

"[w]hen there's one big page"? Don't you mean "if we had one big page"? I went through Category:Wikipedia Manual of Style and its subcategories. Assuming that is the correct list of Manual of Style pages (despite some edit history comments to the contrary) and without trying to compensate for all the text that is duplicated on different pages, the MoS has 49 pages, for a total of about 1146 KB. That would cause performance problems all on one page. Compare Special:LongPages, which states that the longest page on Wikipedia is only 495 KB. Is that what you want? If not, we're talking about how many links to more detailed pages, not whether to have such links at all; and once the user understands a hierarchy, the link from subpage to subsubpage is easier to understand than the first link. I agree that finding all that information on 49 pages is harder than it has to be. My ideal is something like the "See also" links we have now, but on every paragraph or even on sentences, linking to more detailed information after you've found approximately what you're looking for. The table of contents model isn't bad either, but if that's where we're going, it should point to ALL our information on 49 articles, not just the somewhat arbitrarily selected 13% we have in the main article. Art LaPella (talk) 05:08, 8 June 2010 (UTC)

By "one big page" I indicate a general preference for fewer, larger pages over more, smaller ones. I do not believe that absolutely all of Wikipedia's policies (OR, CIVIL, V, etc.) necessarily need to be on just one page. I feel that the MoS should have all of Wikipedia's nuts-and-bolts word usage, punctuation, capitalization, spacing and style policies on just one page, where people who want to see them will be able to find them. Darkfrog24 (talk) 18:44, 8 June 2010 (UTC)

The trouble with is word usage, punctuation, capitalization, spacing are all different subject and shouldn't be mixed and for style policies covers the entire MOS Gnevin (talk) 18:57, 8 June 2010 (UTC)

When I counted 49 articles and 1146 KB, I used Category:Wikipedia Manual of Style, which includes "word usage, punctuation, capitalization, spacing and style" but not "OR, CIVIL, V, etc." Art LaPella (talk) 20:05, 8 June 2010 (UTC)

But they are all the same sort of thing, Gnevin, and all the sort of thing one would expect to find in a style book, like CMoS or a company style sheet.

Art: Good. Darkfrog24 (talk) 18:23, 9 June 2010 (UTC)

Does that mean you agree the complete Manual of Style won't fit on one page, for technical reasons apart from the usability question? Art LaPella (talk) 20:23, 9 June 2010 (UTC)

By "good," I was expressing my approval of your decision not to include OR, CIVIL or V in your assessment of how many KB the MoS consists of.

I believe that technical issues like that one should not be put to opinion. Whether or not something fits on one page (or consists of a certain number of KB) is an observable fact. If you tell me you've observed it, Art, then I'll take your word on it. The ideal way to organize the MoS is on one wikipage, but if it consists of too many KB for that, there are ways we could work around it.

I'm not a programmer, but do many smaller pages require more memory than one big page? Is the difference significant or negligible? Darkfrog24 (talk) 22:09, 10 June 2010 (UTC)

Many smaller pages presumably require more memory than one big page. Nevertheless, big pages are deprecated here and just above. As previously noted, the biggest page on Wikipedia is apparently 495 KB. Years ago, the biggest was a few MB, but no longer. Big articles also take more time to load, both for the waiting human and for the server. That pretty much sums up my knowledge of that subject. Art LaPella (talk) 22:27, 10 June 2010 (UTC)

Whether it fits on one page is based on my calculation and on a maximum size guideline, not on a directly observable fact or experiment, so perhaps that will clear up a misunderstanding. Art LaPella (talk) 03:38, 11 June 2010 (UTC)

Decentralising

Well we seem to have CON for decentralising . What our options? I'd like to keep it simple with a simple seealso to each of the sub-MOSs. Gnevin (talk) 16:04, 8 June 2010 (UTC)

I am not sure you have consensus for anything let alone decentralisation! Everyone above seems to be seeing different problems, proposing (often subtly) different solutions, looking at different aspects from different perspectives and often talking about different things with each other without realising it. If I may add my own thoughts, just to confuse things further...

My problem with the MoSes (all of them) is that there is no clear rationale for their existence and therefore for the advice that they contain. What is the purpose of them? More to the point why do we need more than one? This question applies also to Polices and Notability Guidelines etc, also. Taking Notability as an example: basically, a subject gets an article if there is enough justification for an article i.e. there are enough Reliable, Independent, Secondary Sources. In other words, if WP:V is met, we can have an article, if not we can't. Why then do we need all these Notability Guidelines? Well: we need to know how likely it is that we will find those sources. There are general principles that we can follow to help us determine if any particular subject is likely to have enough coverage (WP:N) but each subject-group (music, people, science etc) will have specific requirements. After all, a musician, a chemical compound, a virus and a planet are all quite different things and are judged by quite different standards in the real world: WP needs to follow those standards as best it can. By analogy then, all WP articles will need to follow a basic standard of Style so that the encyclopaedia is consistent, coherent and flows together logically. Individual subject-groups have their own Stylistic requirement, though: scientific articles need to present scientific data, music articles need to present music samples (sound files, music scores etc), biographies need to present biographical data, etc. All of these types of data present different challenges and are specific (though not necessarily unique) to particular groups of subjects. Hence, we need a general MoS for the things that are common to all articles (spelling, grammar, punctuation, heading, names etc etc) and the specific MoSes for things that are specific to particular groups of things. That's the way I see it anyway... this isn't spelt out anywhere, though, as far as I can tell.

Hope this helps --Jubilee ♫clipman 21:20, 8 June 2010 (UTC)

Well unfortunately Wikipedia:Subject-specific_guidelines didn't gain con. However I don't see how anything you've outlined above is contrary the proposal to decentralise and more important stop poorly duplicating guidance Gnevin (talk) 22:04, 8 June 2010 (UTC)

My thoughts are really just another way of looking at the overall issues surrounding the MOS, though I do suggest that we need a centralised MOS for things that affect all articles and specific MOSes (e.g. WP:Manual of Style (music), etc) for thing that affect specific groups of articles (e.g. those about musical styles, musical works, musicians, musical instruments, etc), while you seem to imply that we should ditch the main MOS and develop the specific MOSes. However, I still fail to see any consensus either for or against decentralisation: the only times the word has been used are in connection with you claiming consensus and each time other editors say there is no clear consensus unless you refine the meaning of the term in some sense. Therefore: what exactly do you mean by the word? --Jubilee ♫clipman 22:39, 8 June 2010 (UTC)

Oppose. I certainly don't see consensus for decentralizing, and I would strongly oppose such an idea. Keeping the most important aspects of the style guide centralized allows for centralized discussion. And the assertion that the style guide was written by a handful of people a long time ago and has no consensus is utter nonsense. Read through the 116 pages of archives and you'll see how much careful deliberation and discussion has gone into every detail of this guide. Kaldari (talk) 04:23, 9 June 2010 (UTC)

This isn't a vote but it may be time for a vote. So you'd support centralising the MoS and removing the duplication? Or are you happy with the status quo where the MoS is suffering from multiple personality disorder. Gnevin (talk) 08:43, 9 June 2010 (UTC)

Oppose. Darkfrog24 (talk) 18:22, 9 June 2010 (UTC)

This is not a vote and even if it was your expected to give a reason for your vote Gnevin (talk) 18:30, 9 June 2010 (UTC)

I'm not aware of that rule, Gnevin, nor of any rule that says people need the thread initiator's permission to express themselves using words like "Oppose." I oppose decentralizing the MoS for the reasons that I stated above in the conversation that you and I were just having. The main reason is that keeping all the style-guide-type rules in one place makes them easy for people in general and grammar/punct/style enthusiasts in particular to find and I believe it is also less intimidating to newbs than lots of blind clicking through unknown numbers of subpages. Darkfrog24 (talk) 22:02, 10 June 2010 (UTC)

...and tell what you're opposing, too. ;-) — JohnFromPinckney (talk) 18:57, 9 June 2010 (UTC)

What does decentralisation mean?

I asked this above and no one has yet fully explained what is actually proposed. Does it mean ditching the main MOS and moving all the advice out into the satellite MOSes (how?) or does it mean somehow minimising the main MOS's importance in favour of the satellites or... what does it mean? What exactly is proposed? --Jubilee ♫clipman 21:16, 9 June 2010 (UTC)

It means one of several options which haven't been decided but in a nut shell yes it means the main MOS stops repeating what is said in the sub-pages Gnevin (talk) 21:27, 9 June 2010 (UTC)

Does that mean that WP:MOS would just list the subpages? In other words, rather than have the current summarizations of the subpages, the main page would just direct readers to the pages directly with single sentences that reference what is contained in the subpages? Imzadi 1979 → 21:30, 9 June 2010 (UTC)

Do you mean {{see|WP:MOSICON}}

and nothing further .That is one option and my preference at the moment. However I'd not object to the main page containing some info once it's not repeated in a sub page Gnevin (talk) 21:45, 9 June 2010 (UTC)

The converse is also a possibility, then: i.e. subpages stop repeating what is in the main MOS. In other words, we could centralise more. I can see the issue with too much information causing people to navigate away from a page but, equally, having several tens of pages that people have to navigate to to find the advice is just as "bad". We need the advice somewhere! I personally favour centralisation of advice as much as possible and only using satellite MOSes where the advice is more specific to certain types of article (those dealing with music, natural world, literature, chemistry, etc) or where the advice needs to be eludidated further (WP:WTW, WP:MOSCAPS, etc). The point then is not to concentrate on one or the other extreme of all-on-one-page or all-in-subpages but to ensure the advice is consistent across the MOSes and not redundant in any MOS. BTW, I think the problem with this "Bold Idea" is precisely that there is no actual proposal, just a vague collection of possibilities that may or may not work. Suggest something concrete and we might have some better idea where we should be going --Jubilee ♫clipman 21:54, 9 June 2010 (UTC)

Well centralise or decentralise I don't care all I the status quo ain't working. I've made several concrete suggestions during this discussion however the key issues is we don't know what the community want. I've suggested before we have a poll to find out what the community prefers and I will suggest it here again. Gnevin (talk) 22:52, 9 June 2010 (UTC)

OK, if you want something specific, what I would prefer for the main MoS article is: A lede, including WP:MOS#General principles, and making it clear that we don't expect people to read it all at once. It would be followed by an expanded version of the MoS navigation template, including the search box. The search box would be right after the lede, with a sentence or two to explain it. Instead of introducing each choice with a single word such as "Arts" (what does that mean? Will I be asked to donate to the arts if I click that?), each choice would get a sentence or two to explain it. Each subchoice would also get a sentence or two, except when the subchoices closely resemble each other: "There are additional rules that apply only to specific countries and religions: [linked list]." Any other content on the main MoS page that isn't already on a detail page, would be moved down to an existing or new detail page.

More importantly, I agree with the post above that the status quo ain't working and we need something. And I don't think it has to resemble style manuals intended for people who can be fired if they don't use them, especially not in the introduction. When the rest of Wikipedia is unaware of most of our rules, then everything else we say here is almost irrelevant unless we can fix that problem. Art LaPella (talk) 23:33, 9 June 2010 (UTC)

That's quite good actually: I would support something like that now I think about this more --Jubilee ♫clipman 23:52, 9 June 2010 (UTC)

A straw poll isn't a bad idea but it can just polarise opinion and/or appear to be the last word. Remember also that many editors subscribe to WP:Voting is evil. I am also concerned that many editor that commented earlier in this discussion seem to have lost interest and moved on to other things. Focus is the key: you need to decide exactly what the poll is asking. E.g.:

Which of the following best describes your position:
- The main MOS should be deprecated entirely in favour of the satellite MOSes
- The main MOS should be a page explaining what a MOS is and simply act as a disambiguation page to the specific MOSes
- Much of the main MOS should be moved out into the specific MOSes
- The MOS and it subpages are fine as they are
- Much of the content of the specific MOSes should be moved into the main MOS
- The specific MOSes should act only as clarification of points covered in the main MOS where there are specific issues relating to a limited number of articles
- The satellite MOSes should be deprecated entirely in favour of the main MOS
- Something else (explain)

The wording needs work but I think I now get the gist of what you are trying to do and support the basic premise that the duplications, irrelevancies, contradictions etc all need to be dealt with. --Jubilee ♫clipman 23:52, 9 June 2010 (UTC)

I really like Art's idea this is pretty much what I was attempting to convey Gnevin (talk) 10:24, 10 June 2010 (UTC)

I'm like his idea too, which was roughly what I envisioned decentralization to encompass. Imzadi 1979 → 19:10, 10 June 2010 (UTC)

The specific MoSes should act only as clarification of points covered in the main MOS where there are specific issues relating to a limited number of articles best describes my position. Navigating to multiple pages is a pain in the neck. Darkfrog24 (talk) 22:15, 10 June 2010 (UTC)

Navigating to multiple pages is the way wiki works. We don't repeat items we use a link Gnevin (talk) 08:48, 11 June 2010 (UTC)

I don't think Darkfrog is saying that we should repeat items but I'll let him expand further. :) --Jubilee ♫clipman 21:24, 11 June 2010 (UTC)

Navigating to multiple pages works for the articles because the articles are all on different topics and meant to inform. The MoS is meant to instruct. People come to it for different reasons and purposes.

Of the nine options you listed, Jubilee, this one comes closest to my own opinion. It is best to keep the MoS in one place so that people can find what they need without being led by the nose from page to page to page. However, because conflicts between the main page and subpages have become an issue, reducing the number of subpages might help. One other thing we could do is establish a clear hierarchy between the MoS and any subpages. For example, every subpage could have a tag reading, "This subpage is meant to expand on and explain one element of Wikipedia's style. However, that style will occasionally change. If this information conflicts with WP:MoS, then WP:MoS can be assumed to take precedence. Users should feel free to bring this page up to date."

Foreign terms: could we get a warning about not throwing around "literally" like it's a synonym for "can be roughly translated as"?

IMO the foreign terms section should include a warning about not throwing around "literally" like it's a synonym for "can be roughly translated as". -- Gordon Ecker (talk) 01:43, 11 June 2010 (UTC)

The correct use of "literally" might be best mentioned at Wikipedia:Manual of Style (words to watch).--Wavelength (talk) 02:23, 11 June 2010 (UTC)

"Mac vs. Mc" Discussion again

I'm sure this has been discussed several times here, but I have looked through the archives and I have seen no consensus. This leads to my query: Which would come first alphabetically, McKie or Mailei? Does McKie actually stand for Mackie, or is it just Mckie? Eagles 24/7 (C) 01:27, 28 May 2010 (UTC)

Historically, we've always put "Mac" in the autosort of a person's article, so that Mc appears alphabetically as Mac. To me, this says Mc is Mac alphabetically.►Chris Nelson^Holla! 02:24, 28 May 2010 (UTC)

Just my opinion, but Mc should not be before an Ma or Mb. It just makes sense, at least to me. RevanFan (talk) 02:47, 28 May 2010 (UTC)

I suggest looking at the major telephone companies, e.g. BT. This seems to sort "Mac" and "Mc" is equivalent and the following letters do the real soring, e.g. "McCowan", "Macdonald", "McEwan", etc. --Philcha (talk) 05:45, 28 May 2010 (UTC)

And Verizon doesn't, sticking to straight letter-by-letter alphabetization. I tend to agree with the latter. The argumemt for the "Mc-as-Mac" sorting is that "Mc" is really just an abbreviation of "Mac". While that may indeed be the origin of the use, the effect is to essentially tell people they are spelling their own name wrong. I find that to be pompous, presumptious and, frankly, offensive. It is not the place of an unrelated know-it-all to tell someone that they are wrong about their own name. oknazevad (talk) 13:42, 28 May 2010 (UTC)

I agree. Straightforward alphabetical sorting leaves no room for doubt or debate. There is no sensible basis for making this a special case of sorting by etymology, as it were. Barnabypage (talk) 13:59, 28 May 2010 (UTC)

Another reason I think Mc is not Mac shortened is, do you think people would like it if you called them Mac when it's really Mc? Like, it's McBriar. That is definitely not Macbriar shortened. I also know someone who has Mc in her last name, and absolutely hates it when she is called "Mac". RevanFan (talk) 18:34, 28 May 2010 (UTC)

Traditionally, libraries have sorted all variations of Mac (Mac, Mc, M', etc.) under Mac (Gaelic for "son") in their (card) catalogues. It may be a rule specified in the AACR2. But with the ease with which computers can carry out searches these days, I agree that it may not be necessary to stick to this rule. — Cheers, JackLee ^–talk– 18:54, 28 May 2010 (UTC)

Another thing. Who comes first on this page? http://www.neworleanssaints.com/team/roster.html RevanFan (talk) 23:24, 28 May 2010 (UTC)

I thought the main reason for sorting "Mc" as if it were "Mac" is for the benefit of people who aren't sure which spelling to use. The different spellings apparently arose back in the day, when spelling was more lackadaisical than it is now, so it's not like there's much rhyme or reason to why one surname is "Mc" and the other is "Mac". Powers ^T 00:23, 29 May 2010 (UTC)

Definitely think we need to alphabetize "Mc" without consideration of "Mac". If we give special consideration to this etymology, then a whole slew of other cases might eventually come up. Let's just keep it as by-the-book as possible. — CIS ^(talk | stalk) 00:28, 29 May 2010 (UTC)

By which book? Several books do exactly the opposite of what you suggest. Powers ^T 13:31, 29 May 2010 (UTC)

"Mc-" is a variant of "Mac-"; for that matter, so is "M'-" (as has been mentioned). Should this result in "M'banza-Kongo" coming before "Macintosh"? Or, to stay within "names", Daniel M'Naghten before Timothy McVeigh? I'm sure there are other names that start with "M'-" that I just can't think of. Chickenmonkey 16:56, 29 May 2010 (UTC)

And that's the other problem with the old librarians' convention. It assumes that an "M'" or "Mc" is necessarily an abbreviation of "Mac" and of Celtic origin. While I don't know for a fact, I doubt the names mentioned here are Celtic names. Any such assumption is specious at best, especially in this ever-more connected world. the "file all as 'Mac'" convention is a relic that should be relegated to the dustbin of history. oknazevad (talk) 21:48, 29 May 2010 (UTC)

Sorting Mc as Mac does have a point (see Powers' post), but it's confusing for readers from other countries, and you have to know that (say) "Wright" is spelt with a W to look for it, anyway... A. di M. (talk) 11:07, 30 May 2010 (UTC)

Another thing. I just looked up the Saints' roster in the NFLPA database. They list Ma before Mc as well. RevanFan (talk) 17:16, 4 June 2010 (UTC)

Isn't this kind of like how when there's a word with the first syllable that sounds like a vowel but isn't actually a vowel (such as "Hour"), you put "An" in front of it instead of putting an "A". Thought this was a hard-coded rule of thumb? RF23 (talk) 00:44, 5 June 2010 (UTC)

Mac and Mc are identical. They both mean "son of" in Gaelic. In British phone books, Mc and M' are treated as if they were spelt "Mac" so that MacIntyre/McIntyre both come after MacDonald/McDonald and before MacMillan/McMillan. I can legally call myself either McIntyre or MacIntyre here in Scotland and in fact my family have interchanged both spellings for generations. More history here and here. However, computers work logically so that, unless you actually program the computer to recognise this fact, all Mac's would come before all Mc's and this appears to be what happens in most other phone books around the world. See Collation#Alphabetical_order for more on this issue. We as a community have to choose one way or the other and stick to it, IMO. Most Mc/Mac's these days stick to one spelling, anyway, (so there is no issue with having to list someone twice because they keep changing their mind about how to spell their name) and the advice is usually to alphabetise by spelling out letter by letter and ignoring old abbreviations etc, e.g. see here, here and here as real life examples of how this usually works (though they aren't really RS's!). Hence, Mabuchi, MacDonald, MacIntyre, MacKie, MacMillan, Mailei, McDonald, McIntyre, McKie, McMillan, Mellor, etc. Dab pages should still contain both spellings, however, since the names of many historical figures will have at least two different ways of being spelt depending which source (contemporary or modern) you look at --Jubilee ♫clipman 01:50, 5 June 2010 (UTC)

I agree. RevanFan (talk) 02:18, 5 June 2010 (UTC)

One would like to point out that an encyclopaedia and a telephone directory are two different things. Could someone look at the practice of other encyclopaedias and report back? -- Evertype·✆ 07:27, 5 June 2010 (UTC)

I favour merging Mc* with Mac* and sorting all based on a (lower case) next letter. Although the information in a directory and an encyclopaedia is different, the function of sorting remains the same - to find an entry quickly and easily. There is no easy way to distinguish between the three "prefixes" in speech. Finavon (talk) 17:22, 6 June 2010 (UTC)

There's no easy way to distinguish "Rack" from "Wrack" either, so should they be sorted together too? A. di M. (talk) 17:47, 6 June 2010 (UTC)

Perhaps you'll prefer "Katherine" and "Catherine" as an example, to avoid a discussion of the difference in meaning. Art LaPella (talk) 18:37, 6 June 2010 (UTC)

I was thinking about the family name Rack and the family name Wrack... A. di M. (talk) 19:22, 6 June 2010 (UTC)

(On the other hand, the fact that the same person in Scotland could call himself both McSomething and MacSomething would be a good reason to sort them together... A. di M. (talk) 07:39, 8 June 2010 (UTC))

From my experience there's a difference in usage between the Britain and America. In the UK, Mc and Mac are almost always sorted together. In the US, it's more common to see them sorted separately. I'd guess that some large English-speaking countries, like India and Australia, would follow the British example, while others, like Philippines and Nigeria, probably follow the US pattern. In other words, it's up for us to decide. Will Beback talk 21:23, 6 June 2010 (UTC)

Well, I'm from the U.S. and it looks completely unnatural to see Mc before Ma. I personally think it's ridiculous. Almost every article I've seen is using American English, so I think Ma should be before Mc. RevanFan (talk) 22:17, 6 June 2010 (UTC)

Oh good, another chance for the Yanks and Brits to fight! Not.

Maybe the thing to do would be just keep it simple and use straight ASCII/Unicode ordering (except without distinguishing case), so that Mc and Mac are not treated specially at all. So Mack comes after MacEwan but before MacLane. This may not fit anybody's style guide, but at least it's simple and predictable. --Trovatore (talk) 22:25, 6 June 2010 (UTC)

Have not seen Mc before Ma in any American English setting. Pats1 ^T/C 00:54, 7 June 2010 (UTC)

In America, I once came across a set of alphabetical index cards, like those used in old-fashioned library card catalogs, with all the letters of the alphabet plus a separate one for "Mc", as if it were it's own unique letter. Will Beback talk 01:00, 7 June 2010 (UTC)

Is it technically possible to have two sort keys for the same article, so that McAdam would be listed both between Mabbet and Maddox and between Mbuyi and Meredith? That would be helpful both for readers who don't know whether someone is MacAdam or McAdam and for those who aren't familiar with the sort-Mc-as-Mac convention. (On the other hand, listing the same item twice in the same list would be a little, er..., inelegant.) A. di M. (talk) 07:39, 8 June 2010 (UTC)

That's not directly possible, but what we could do is categorize the redirects, so Henry McAdam would be sorted as "Mcadam, Henry" while the redirect Henry MacAdam would be included in the same categories as "Macadam, Henry". That would require keeping categories synchronized between the articles and their redirects, however, which is a tedious manual task (at least until someone writes a bot for it). Powers ^T 15:40, 13 June 2010 (UTC)

Small change to MOSQUOTE

Under "Allowable typographical changes" at WP:MOSQUOTE, I'm about to change: "Styling of dashes—use the style chosen for the article: unspaced em dash or spaced en dash. (See Dashes, below.)" to: "Styling of dashes and hyphens: see Dashes, below. Use the style chosen for the article: unspaced em dash or spaced en dash." It's a small but important change, because hyphens aren't dashes (not in my dictionaries, anyway), so as written, our MOSQUOTE didn't allow changing hyphens to dashes inside quoted material, or by extension, inside titles. I believe that conforming even quoted material to WP:DASH is expected at FAC.

On another point, it's a shame that Google searches and spiders won't show a hit on a source title after you change the hyphen to a dash, so I'm recommending at my own wikiproject that we keep a page of common sources with the hyphens intact to catch these searches. - Dank (push to talk) 13:07, 10 June 2010 (UTC)

Previous discussion here. Google searches won't show a hit after changing to a dash? If so my AWB edits have spread a lot of mispunctuation. But I think Google searches ignore punctuation, and so do other search engines. This Google search was for "north–south" with a dash, but it also found "North-South" with a hyphen, as well as "North South", "North & South", and "NorthSouth".

However, I just discovered that Google is apparently unable to find an article that already has a dash in the text you're searching for, even if you explicitly search for a dash. That strikes me as a drawback for dashes in general, not just in article titles. Art LaPella (talk) 21:07, 10 June 2010 (UTC)

Try it and see. For example, googling site:wiki.riteme.site "British Battlecruisers 1914-1918" gives 2 hits, because there are only 2 en.wp pages where the hyphen hasn't been changed to a dash. Googling en.wp on ""British Battlecruisers 1914" gives all 6 en.wp pages where this book appears. Googling on site:wikipedia.org gives 16 hits, because wikipedias in other languages are leaving the hyphen intact. And the English Wikipedia is the only place I've seen someone change a hyphen in a book title to a dash, ever. - Dank (push to talk) 22:42, 10 June 2010 (UTC)

Yup. Dashes don't interfere with the dead link problem discussed before, but they do interfere with looking for articles using a specific source, or any other search phrase that includes a dash. Let's see what the others think ... Art LaPella (talk) 23:11, 10 June 2010 (UTC)

Google needs to stop being geeky. That's typewriter stuff, and shows the ignorance of many developers, who seem to be keen to privately claim that they know about language and style. Let's not bend to this ignorance, but simply ensure that a redirect page with hyphen is created. That is what it already advises. Tony (talk) 07:33, 11 June 2010 (UTC)

Actually, what the MoS already advises is: "Article titles with dashes should have a corresponding redirect from the title with hyphens". "British Battlecruisers 1914-1918" is the title of a book Wikipedia uses as a source, not as an article title. So how do you feel about citing that source as "British Battlecruisers 1914–1918" (with a dash), knowing that Google won't be able to list articles that cite that source because of the dash? Art LaPella (talk) 21:40, 11 June 2010 (UTC)

I'm seeking advice by email from User:Noetica, who's on a wikibreak. Tony (talk) 12:14, 14 June 2010 (UTC)

"Reviewer" userright

The "reviewer" userright, allowing you to to review other users' edits on certain flagged pages. Pending changes, also known as flagged protection, will be commencing a a two-month trial at approximately 23:00, 2010 June 15 (UTC).

The Flagged Protection trial is going to be starting very soon, and non-admins who have had access to edit semi-protected articles since roughly Day 4 of their editorship will now have their edits going into a vetting queue unless they are granted autoreviewer and/or edit reviewer permissions by an administrator. This will have a significant impact on editors who have, for years, been working on quality content. More detailed documentation and guidelines can be found here.

If you have not already done so, please request this "right" at WP:PERM/RW or ask any administrator. Cheers, Dabomb87 (talk) 15:26, 15 June 2010 (UTC)

Category:Lists of popular pages by WikiProject

You may wish to refer to the new category Category:Lists of popular pages by WikiProject.—Wavelength (talk) 21:39, 15 June 2010 (UTC)

Maybe there can be Wikipedia:WikiProject Manual of Style/Popular pages.

More information is at User:Mr.Z-man/Popular pages FAQ.—Wavelength (talk) 23:48, 15 June 2010 (UTC)

and/or

The opening, which someone removed recently but has now been restored, is: "The construct and/or is awkward". I don't agree with this blanket statement. Tony (talk) 07:29, 11 June 2010 (UTC)

How about "The construct and/or should normally be avoided"? To me, it is like "he/she" (or worse "s/he"), "if/when", etc. Such constructs have their place (e.g. in lists or very short summaries) but should really be avoided in running prose. I do use these when I feel I have no choice but always cringe internally as they feel "wrong" --Jubilee ♫clipman 21:06, 11 June 2010 (UTC)

BTW, the final paragraph of this section (Sometimes or is ambiguous in another way...) seems to have nothing to do with "and/or". Should that be moved elsewhere or should the section be renamed as Constructs involving the word "or"? --Jubilee ♫clipman 21:19, 11 June 2010 (UTC)

How about we cut out any descriptive statements whatsoever and just say, "Avoid using and/or on Wikipedia"?

This is why I feel that the imperative should be the main mood for the MoS. We're not making statements, so we don't have to offer proof/sources. The point of the MoS is to tell users what to do on Wikipedia, so let's do that here. The point of the articles is to tell users the interesting histories of words and other subjects, so let's do that there (and source it). Darkfrog24 (talk) 02:23, 12 June 2010 (UTC)

I don't agree with a proscription. "And/or" is sometimes useful, and occasionally necessary. Tony (talk) 03:09, 12 June 2010 (UTC)

Here's an example of something I would leave alone if my AWB software found it, from Neutering#Advantages: "Pyometra is prevented, either due to the removal of the organ (when ovariohysterectomy is performed) and/or because of the lack of female sex hormones (oestrogen and progesterone) after spaying." Taking the guideline at face value, the alternative would have to be "Pyometra is prevented, either due to the removal of the organ (when ovariohysterectomy is performed), or because of the lack of female sex hormones (oestrogen and progesterone) after spaying, or both." I think the "and/or" version is easier to understand because there's one less level of complication to remember throughout that complicated sentence. Art LaPella (talk) 05:35, 12 June 2010 (UTC)

I think the MoS should be silent on it. It does have only limited appropriate use, but in a way that's irrelevant: like any other word or phrase, it should be challenged if used inappropriately. If there are hard and fast rules for what's inappropriate, by all means let's state them, but I suspect there aren't in this case. (On a side note, Art, I hope that if AWB found the above example, you might in fact leave "and/or" but remove "either"!) PL290 (talk) 08:52, 12 June 2010 (UTC)

"Either ... and/or"? I'd rather throw away that either, wouldn't you? A. di M. (talk) 08:56, 12 June 2010 (UTC)

Here's another example of what I would consider appropriate usage (this time from the MoS itself): Some editors also like to provide euro and/or pound sterling equivalents, formatted as described in the next section. PL290 (talk) 09:02, 12 June 2010 (UTC)

Do we really care that some editors don't do both and some editors do? I doubt it - so "or" alone would be fine. Or we could say "Some editors also like to provide one or more equivalents in other currencies, formatted as ...". There are many ways to express the actual point there without resorting to "and/or". — Carl (CBM · talk) 12:04, 12 June 2010 (UTC)

Like any other phrase, "and/or" is never necessary: you can write around it. I would suggest always avoiding it, and I would remove it from any article that I edit, because 'and/or' does not have the desired encyclopedic tone. — Carl (CBM · talk) 12:01, 12 June 2010 (UTC)

In my example, granted that "either" should be removed, how would you rewrite that one? I'm not a doctor, so I surely wouldn't want to remove an ovariohysterectomy or two just to make the truth table match a style guideline. Art LaPella (talk) 04:17, 13 June 2010 (UTC)

Your rewrite with "or both" is fine. You could also say that the disease can be prevented by removal of the organs, by a lack of sex hormones, or by a combination of the two. My point is that "and/or" is just as inappropriate in a scholarly work as any other contraction would be. It's not a matter of "correctness"; it's a matter of code-switching into an appropriate writing style. — Carl (CBM · talk) 16:11, 13 June 2010 (UTC)

cough* "Use and/or sparingly on Wikipedia"? 74.105.135.235 (talk) 20:02, 15 June 2010 (UTC)

"And/or" is redundant. When using “or” without “either” the possibility of choosing all of the above is implied. “You can have cherry pie, apple pie, or chocolate cake” means you can have any number of the given choices. “You can have either cherry pie, apple pie, or chocolate cake” means you can only choose one. Using and/or is amateurish at best and should NEVER be used on wikipedia unless it is a direct quote. — Redsxfenway (talk) 05:51, 17 June 2010 (UTC)

Wiktionary:or agrees with you on the definition of "or", but several other dictionaries disagree. Dictionary.com, for instance, says "1. (used to connect words, phrases, or clauses representing alternatives): books or magazines; to be or not to be." It defines "alternative" as "1. a choice limited to one of two or more possibilities ..." (emphasis added; one, not "any number"). As the Logical disjunction article puts it: "In ordinary language 'or' sometimes has the meaning of exclusive disjunction", hence if "and/or" is verboten we need some other way to specify an inclusive or. Art LaPella (talk) 06:28, 17 June 2010 (UTC)

I was pinged here by Redsx. PL290 has provided at least one good use for "and/or". Sure, no one wants to encourage its use, but sometimes it's the neatest option where it's important to stress addition or alternative. I'd either be silent on it, as suggested above, or just say "usually best avoided". My whole point in starting this thread was that the banning of "and/or" and its blanket characterisation as "awkward" is unnecessarily cut-and-dried. Tony (talk) 09:29, 17 June 2010 (UTC)

It's just unnecessarily oblique; whether "and/or" seems awkward is irrelevant. We should just characterize it as "inappropriate for a scholarly work". Sometimes "ain't" sounds nice in a sentence, but we shouldn't use that either. There are numerous other ways to express inclusive "or" when it's necessary. — Carl (CBM · talk) 10:52, 17 June 2010 (UTC)

I cannot imagine a clause in which "ain't" "sounds nice"; it is oral language, anyway. Why do you say that "and/or" is always inappropriate in "scholarly" registers, and why do you class all WP article text as "scholarly"? Tony (talk) 12:31, 17 June 2010 (UTC)
- Because I believe those things to be true. If I submitted a paper with the phrase "and/or" I would expect the copyeditor to remove it. Natural language is very expressive and there is no difficulty avoiding that phrase. So for us it's entirely a matter of code-switching into appropriate usage, and as a native speaker and scholar I know "and/or" is not it. If you don't like "ain't", "irregardless" is another example of a commonly-used word that would not be appropriate for us to use in a Wikipedia article. — Carl (CBM · talk) 12:49, 17 June 2010 (UTC)

I agree with CBM that it is unnecessary to describe and/or as "awkward" or anything else in this MoS. My own opinion is that such assertions belong in the articles (and/or), where they can be attributed to sources. Darkfrog24 (talk) 23:45, 18 June 2010 (UTC)

Inanimate object pronoun usage

I was reading an article about a battleship, and the article kept referring to the ship as "she". I searched the MoS, but I couldn't find any specific guidance on this. My instincts tell me that using "she" for an inanimate object is ridiculous and that I should change it to "it". But I can't because I am not certain. Any editors out there with some specialized knowledge? Thanks. fds^Talk 04:14, 15 June 2010 (UTC)

Ships are traditionally given feminine attributes, including pronouns. Imzadi 1979 → 04:27, 15 June 2010 (UTC)

Aye I know. I'm just wondering if that's how we editors should handle it at Wikipedia. fds^Talk 05:28, 15 June 2010 (UTC)

The issue has been discussed, but I am not aware of any clear decision having been made. Wikipedia needs a clear and reasonable decision-making process. -- Wavelength (talk) 05:49, 15 June 2010 (UTC)

I was brow-beaten for suggesting that ships should not be treated explicitly as objects that men control (i.e., fuck). That is, in the end, the implication of the female "she" as ship. There was strong objection. Tony (talk) 12:42, 15 June 2010 (UTC)

Wow, that's a pretty twisted reason for someone to name a ship after their mother! Seriously though, there is no single WP:WORLDWIDE practice on this. Why should WP differ? We should follow the sources, which will in turn usually reflect local customs.LeadSongDog come howl! 13:27, 15 June 2010 (UTC)

I am of the opinion that even if the tradition of referring to ships as "she" originally had anti-feminist connotations, right now it is just a thing that a lot of people do. I don't consider it to be incorrect English, but it is a touch fanciful. Our only question should be whether referring to ships as "she" fits Wikipedia's encyclopedic tone. Darkfrog24 (talk) 20:38, 15 June 2010 (UTC)

I think it scandalizes encyclopedic tone. fds^Talk 21:05, 15 June 2010 (UTC)

For those of us who don't read minds, could Fdssdf please explain what that means and on what policy basis "I think" differs from a personal preference? LeadSongDog come howl! 15:22, 16 June 2010 (UTC)

Or a bit less confrontationally, given that 1. an opinion about tone is subjective and may be difficult to summarize concisely, 2. "I think" is an opinion which can only sometimes be restated as "I prefer", 3. it should be OK to state a personal preference until reliable sources or at least a wider consensus has been demonstrated (how else would we find that consensus?), and 4. "scandalized" is exaggerated; no opinion on pronouns compares to Watergate; almost nobody else cares except on this page: given all that, why do you think "she" for a ship is the wrong tone? Art LaPella (talk) 18:22, 16 June 2010 (UTC)

Agreed. It is okay to express personal opinions and preferences here so long as we make it clear that that's what we're doing. "I think" is one way to indicate that a following statement is an opinion (or a guess). Darkfrog24 (talk) 23:38, 18 June 2010 (UTC)

Why isn't this is alphabetical order?

Is there any particular reason why this is not in alphabetical order? It's not easy to locate items. --Klein zach 02:58, 23 June 2010 (UTC)

The guidelines at Wikipedia:Manual of Style are arranged in topical groups, providing the advantage that if an editor finds the relevant section, then finding relevant subsections within that section is easier. There could be more than one possible name for a section or subsection, and an editor consulting an alphabetical list might look for the section or subsection by a different name than the one used.

—Wavelength (talk) 03:33, 23 June 2010 (UTC)

The existence of the CTRL-F search feature takes away much of the advantage of alphabetization over a group-by-topic arrangement. Darkfrog24 (talk) 01:21, 24 June 2010 (UTC)

Agreed. I think it would be much harder to find items on this page if it were in alphabetical order. There is a certain internal logic in the arrangement presently used which would be lost if we used alphabetical order --Jubilee ♫clipman 02:49, 24 June 2010 (UTC)

Spacing em dashes

The MOS currently says not to space em dashes. I really disagree with this — spaced em dashes look great, and nonspaced em dashes look bad—there's an example — is there any record of how and why this decision was reached? Comet Tuttle (talk) 17:40, 25 June 2010 (UTC)

I must admit I came across that one the other day to my surprise, as I thought that spaced em dashes were OK. I'm just going to carry on using them anyway as I also think they look better; for that matter another style— such as this— is common in some other publications. I try to follow the MoS when I can, but common sense should prevail, and personally I think that an unspaced em dash looks too similar to a hyphen and so defeats the purpose of distinguishing them in the MoS. Si Trew (talk) 22:48, 25 June 2010 (UTC)

This is nonstandard formatting. The long-agreed consensus at the MoS is that we should follow the worldwide convention for em dashes: They are unspaced, only. (Except in newspapers, where the extra space helps to fit text into narrow columns). You may be thinking of a spaced en dash – like this – as they are used interchangeably with unspaced em dashes. Ozob (talk) 23:55, 25 June 2010 (UTC)

Eye of the beholder, Comet Tuttle. I find that unspaced em dashes look better to me than spaced ones. Now if you were to tell me you had a good-quality style guide that said that spaced em dashes were more correct than unspaced ones... Darkfrog24 (talk) 01:07, 26 June 2010 (UTC)

You won't find one. You might find one—even in English—that recommends to its users to do so. It would just be a style recommendation for its specific users though, and wouldn't say that it is more "correct". There's just no definitive guidance in English, as you undoubtedly know. Only conventions, which can change over time.

You might also be interested to know that the appearance of legibility is not a good indicator of readability (ease of reading). Something that looks better at first glance may actually be harder to read. See Miles Tinker and Colin Wheildon's studies in the 20th century. --Airborne84 (talk) 03:01, 26 June 2010 (UTC)

The overwhelming consensus of English-language styleguides is for unspaced em dashes. You can see why: when spaced, they are just long enough to be visually disruptive. Tony (talk) 09:22, 26 June 2010 (UTC)

I don't deny it's nonstandard, but I take WP:COMMON here. Em dashes are largely used for parenthesis and (with round brackets), or with commas, there are different spacing rules than there are for em dashes—why? It seems odd to me deliberately to want to separate out a piece of text and then to "merge" it into its surrounding text by omitting spaces. I think, as said above, it's in the eye of the beholder. I'm not going to argue with the MoS, there is little point if an "overwhelming consensus" has been reached (a narrow consensus I would probably argue it as a valid alternative), but will just continue to take WP:COMMON, not something I do lightly. If anyone doesn't like it they can change it— I won't change it back— but I'm not going to kow-tow to the MoS on something I disagree on, it is, after all, a guideline, and one I think makes no sense.

I should add that I rarely use them—after all they tend to make the reader have to kinda put the main thrust of the sentence on hold (and then maybe recursively if, as I say—notwithstanding typos—, there are multilpe levels of parenthesis) and so it's usually better to recast. Sometimes, though, where parentheses are "expected" (for example on converted measures, inline translations of foreign phrases, and so forth) they have their uses. That being said, I think I'll just go over to using spaced en dash. Si Trew (talk) 10:10, 26 June 2010 (UTC)

There's also the fact that an em dash may not be particularly wide in a given font/typeface. So it's not always easily distinguishable from a hyphen, if it's not spaced. This is most apparent in monospaced fonts/typefaces. Si Trew (talk) 10:12, 26 June 2010 (UTC)

Back to zany em dashes for Canadian ridings

I recollected it was discussed a while ago ... here, in fact. There appears to be no resolution to the fact that WP articles, in titles and main text, have been using the em dashes that the Canadian Electoral Commission uses, such as this highway stuck in the middle of the item: Capilano—Howe Sound. See the opening sentence, too, for what looks like an em dash as interruptor, the way MoS prescribes as the primary option. And the MoS prescribes also a spaced en dash for this and many other of these items, where there is a space within either or both items.

So I busily moved a few articles, then discovered this has been done before, back and forth, in some cases. I've stopped pending your advice.

I'm sure WP has a habit of doing what it finds best for the online, international context, even if it sometimes means overriding some electoral commission's frightful practices. I see also that the practice is not really consistent within the riding articles: there are hyphens, too. Tony (talk) 12:10, 14 June 2010 (UTC)

It its official publications, Elections Canada and parliamentary documents are very consistent in using either m-dashes or two hyphens. They only use single hyphens for compound French names, such as Lotbinière—Chutes-de-la-Chaudière or Notre-Dame-de-Grâce—Lachine and they never use n-dashes. I agree that in many uses other than Canadian electoral districts we should use n-dashes because they look better (I'v. moved many articles about towns to names with n-dashes), but in this case the subject has expressed a clear preference for m-dashes, and those are what are seen in publications, so I think we should go with the existing usage. —Arctic Gnome (talk • contribs) 18:07, 14 June 2010 (UTC)

I disagree with Arctic on this. The current name scheme is a direct copy of the system used by Elections Canada. While their scheme is persuasive, it's not controlling. Wikipedia is free to alter the dashes used in names to suit its own guidelines. I agree with Tony on this, and Wikipedia should be internally consistent with itself. Imzadi 1979 → 04:37, 15 June 2010 (UTC)

I agree that we aren't bound by the typographical conventions of the Canadian government. These should be en dashes, rather than em dashes. Headbomb {talk / contribs / physics / books} 05:15, 15 June 2010 (UTC)

I agree that Wikipedia isn't bound by the typographical conventions of the Canadian government but in this case the use of em dashes makes the structure of the name clear and unambiguous. In addition, and I don't know how important this is, en dashes in this situation are a problem with a font like Lucida Grande with its long hyphen: Lotbinière–Chutes-de-la-Chaudière or Lotbinière – Chutes-de-la-Chaudière. I agree with Arctic. Modal Jig (talk) 11:22, 15 June 2010 (UTC)

So the electoral agency uses double hyphens too for the names of ridings? Now that is trashy; sorry, it's when people from the typewriter age, either programmers or senior officers, make careless and unquestioned decisions about a major aspect of language such as this that dreadful typography becomes entrenched. Are you suggesting double hyphens should also receive a vote of confidence from WP just because some agency uses them? The MoS, may I point out, gives editors carte blanche to change such urchins as double hyphens within quotations into properly formatted punctuation; I don't see this as any different. And I do see that someone has marched in and reverted the moves; unwise, since it is under debate here. Tony (talk) 12:37, 15 June 2010 (UTC)

In most publications they use m-dashes, and when they use double-hyphens, their intent is still clear: double hyphens are used by people who intend to use an m-dash but don't know how or are too lazy. As Modal Jig points out, there is a practical reason for this preference. —Arctic Gnome (talk • contribs) 15:51, 15 June 2010 (UTC)

Doesn't this basically come down to WP:COMMONNAME. The common name clearly for these ridings includes the m-dash. -DJSasso (talk) 15:55, 15 June 2010 (UTC)

A double hyphen commonly means an en dash—certainly in LaTeX. Tony (talk) 16:16, 15 June 2010 (UTC)

I've never seen a double hyphen used to indicate a range or to indicate "and"; lazy people use hyphens for that. I only see double hyphens as a stand-in for abrupt breaks in sentences, which is a function of the m-dash. —Arctic Gnome (talk • contribs) 16:39, 15 June 2010 (UTC)

No but they usually use an m-dash in most of their writings, as do newspapers up here. -DJSasso (talk) 16:40, 15 June 2010 (UTC)

I agree with Djsasso. This is about what is locally used, and we used emdashes in Canada. I reverted the edits, because unless you plan on moving all the articles at once, there will be inconsistency. -- Earl Andrew - talk 23:01, 15 June 2010 (UTC)

For the record, there are some nits to pick. Elections Canada is most definitely not a "government agency", it is directly responsible to parliament, in the same fashion as the Office of the Auditor General. Their list of ridings here has no double hyphens in lieu of the mdash, at least that I can find. Neither does Hansard. Perhaps ArcticGnome could furnish an example of its use? LeadSongDog come howl! 15:51, 16 June 2010 (UTC)

I think "government agency" in this case was used in the broad, governing-authority sense, not in the cabinet-department-agency narrow sense. Either way, it appears the emdashes are part of the official, legal names of these constituencies as determined by the relevant authority. Therefore, we should continue to use the same, in the name of accuracy. oknazevad (talk) 05:21, 17 June 2010 (UTC)

LeadSongDog, Elections Canada's main database of riding names uses the double hyphens (almost every province has one in the first couple entries) and today's Hansard uses m-dashes (the very first person to speak is from Lévis—Bellechasse). —Arctic Gnome (talk • contribs) 07:23, 17 June 2010 (UTC)

I can see an argument for retaining these poorly formatted em dashes, but only just. It's disruptive when editors see a presumed breach of the style guide, as they will continue to do, and go in to make changes. Perhaps an editorial note at the top of such articles would alert them. I couldn't abide by double hyphens on WP. Tony (talk) 07:58, 17 June 2010 (UTC)

I fully agree with you about double hyphens; that's just some Elections Canada webmaster being lazy and ignoring the agency's own policy. I guess we could put a note explaining style usage, kind of like we have a hatnote template explaining the order of Korean names. Although I'd bet that 99% of casual readers couldn't tell you the difference between and n-dash and an m-dash anyway, so the note would just be there for our fellow punctuation sticklers. —Arctic Gnome (talk • contribs) 08:27, 17 June 2010 (UTC)

Yeah, I've just had phone advice from User:Noetica (currently on a wikibreak) that the en dash should prevail. While I agree with him, I can see that local editors are keen to retain the em dash. There's a job for someone to add an invisible editorial note (but there are an awful lot of those articles, yikes). [Punctuaton stickler? Yep, but stickling is what makes language stylish and easy to read.] Tony (talk) 09:17, 17 June 2010 (UTC)
- If you really wanted to make it easy to read, you'd use two hyphens, delete every instance of either dash form, and avoid french accents. WP:COMMONNAME and WP:ENGVAR are what you should be looking at. It is the common form, and the Canadian form. 70.29.212.131 (talk) 20:21, 19 June 2010 (UTC)
  Two hyphens is not easier to read. Hyphens, en dashes, and em dashes are different lengths because that makes them easier to distinguish, and proper use improves readability. Regarding accents, they are the proper way to spell certain words. Removing accents gives us a different word.
  
  I'm of the opinion that we should use en dashes consistently in the present situation, despite certain local editors' feelings—but that said, I don't want to offend them. Perhaps there is some way to change their minds. Ozob (talk) 22:30, 23 June 2010 (UTC)

I use User:Art LaPella/Because the guideline says so, but the rest of you would need something that better represents your opinions. For instance, the number of Wikipedians who recognize the difference among dashes so routinely that it improves readability, can probably be counted on one hand. Art LaPella (talk) 23:20, 23 June 2010 (UTC)

Indeed, as has been pointed out, the problem here is that some electoral district names also contain regular hyphens, so the em-dash is used to maximize the distinction between, frex, Saint-Lambert (which comprises one place called "Saint-Lambert") and Toronto—Danforth (which comprises two distinct places called "Toronto" and "The Danforth") and Rimouski-Neigette—Témiscouata—Les Basques (which is three things called "Rimouski-Neigette", "Témiscouata" and "Les Basques") and Montmagny—L'Islet—Kamouraska—Rivière-du-Loup (which is four things called "Montmagny", "L'Islet", "Kamouraska" and "Rivière-du-Loup".) We didn't make this stuff up just to be difficult or contrary on principle; there's an actual, unavoidable reason why the district names have to be punctuated the way they are. And yes, double hyphens are also used in some sources that either can't or won't be bothered to learn how to type an em-dash — but they're certainly not considered standard. But the problem remains that en-dashes aren't visually distinct enough from hyphens to be a viable solution to the problem. What's clearer and easier to read and understand: Montmorency—Charlevoix—Haute-Côte-Nord, or Montmorency–Charlevoix–Haute-Côte-Nord? Bearcat (talk) 04:33, 24 June 2010 (UTC)
- Seriously, I prefer the second example. Imzadi 1979 → 04:39, 24 June 2010 (UTC)
  - The first makes it quite clear and unmistakable that the three geographic units involved are "Montmorency", "Charlevoix" and "Haute-Côte-Nord", while 99.5 per cent of Wikipedia users couldn't look at the second and have the slightest clue in hell whether the three geographic units involved were "Montmorency", "Charlevoix" and "Haute-Côte-Nord", or "Montmorency-Charlevoix" and "Haute-Côte" and "Nord", or "Montmorency" and "Charlevoix-Haute-Côte" and "Nord", or "Montmorency-Charlevoix-Haute" and "Côte" and "Nord". The em-dashes, simply, are the only visually unambiguous way to do what the dashes in the names are there to do. It's not about what anyone prefers aesthetically — it's about the fact that the visual distinction between a hyphen and an en-dash isn't clear enough to properly communicate what the name means. Bearcat (talk) 04:45, 24 June 2010 (UTC)
    - And on this point, I disagree. The typeface my browser uses for inputting in the edit window aside, I can tell the difference between a hyphen, an en dash and an em dash. Using em dashes for the usage of an en dash just looks wrong in print, even if the reasoning behind it is to be beneficial. Sorry, you won't convince me here. Imzadi 1979 → 04:51, 24 June 2010 (UTC)
      - Bully for you. Most users can't. Bearcat (talk) 04:59, 24 June 2010 (UTC)
        Even if we had analysis telling us that unregistered readers' browsers would enable them to see that distinction as does Imzadi's, we must still prioritize correct communication of meaning over any such subtle visual distinctions. LeadSongDog come howl! 16:33, 24 June 2010 (UTC)
        It is precisely because I prioritize correct communication that I prize en dashes. I find en dashes, not em dashes, easier to read in the example above. To me the em dash makes the different parts appear too far distant, as if they are unrelated to each other. Whereas the en dash clearly separates them yet indicates that they are related. This is exactly the typographical purpose of an en dash, and in a properly designed typeface the en dash is sized precisely so that this visual effect is clear. This is true (thinking of Art LaPella's comment above) even when the reader does not recognize the en dash and cannot distinguish it from a hyphen or an em dash. Ozob (talk) 00:33, 25 June 2010 (UTC)
        If we just wanted to express how closely two ideas are related, a list of airline routes of different lengths could be "New York-Philadelphia", "New York–Chicago", "New York—Tokyo", and "Cape Canaveral——–Moon". Art LaPella (talk) 02:06, 25 June 2010 (UTC)
        Close in space is not the same as close in idea; neither is far in space the same as far in idea. (Unless you want to assert that there is no such thing as an idea or that "close" can never be used as an analogy. But I think that's an absurd epistemology.) Ozob (talk) 02:47, 25 June 2010 (UTC)
        But I don't think our dash rules depend on closeness by any definition (communist-socialist ideas, communist———capitalist ideas). I think they grow mainly because people imitate them to be perceived as correct. Which is not to say Wikipedia should necessarily lead the revolution; I probably do more than anyone to replace hyphens with dashes. Maybe it helps by confining the arguments to this page. Art LaPella (talk) 03:23, 25 June 2010 (UTC)

(edit conflict)

- - - - The vast majority of readers cannot tell an endash from a hyphen, they are in effect the same thing. A significant visual distinction of symbol, such as the emdash provides, is the only way to keep different places distinct from the words in the name of a single place. Imagine, for a moment, if "St. Paul, Minnesota" was instead spelled "St-Paul" or "St–Paul". Would "Minneapolis-St-Paul" or "Minneapolis–St–Paul" really be as good as "Minneapolis—St–Paul"? Of course not. A writer might instead resort to the visually repellant "Minneapolis/St-Paul" to make the distinction, but it must be made in some way. In Art's example area, would we run together "communist-capitalist-authoritarian-anarchist polarities" or rather distinguish the dimensions as "communist-capitalist—authoritarian-anarchist polarities"? I think the answer should be obvious. LeadSongDog come howl! 04:12, 25 June 2010 (UTC)
        
        "Prioritizing correct communication of meaning" is maximized by naming the thing with the correct name of the thing, not by deciding that because the correct name of the thing has an element in it that might be perceived as an error by some people, we're going to arbitrarily rename it something else. Bearcat (talk) 04:16, 25 June 2010 (UTC)

Wow, everyone involved here—on both sides—seems very stubborn. I think this is a good thing, because we're all trying to make Wikipedia as readable as possible. Unfortunately we have different ways of going about it. At this point we seem to have failed to convince each other logically. There are a few more things we can do. For instance, we can set up straw men, engage in personal attacks, and disrupt Wikipedia to make a point. But I think the right way forward is to have an RFC. Since the disputed articles currently use an em dash, I believe that those of use who prefer en dashes should be the ones to file the RFC. The RFC would, of course, be binding. I suggest a text such as the following (improvements are welcome):

Currently, articles about Canadian ridings separate the districts in the riding with em dashes. For example, Beauport—Limoilou. This is against the Manual of Style as well as all typographic and style manuals. All of these agree that the correct separator is an en dash: Beauport–Limoilou. En dashes are sized just so they link separate elements. They are not so short that the two elements appear to be part of the same concept, and they are not so long that the two elements appear to be unrelated. The Manual of Style gives as an example of proper en dash usage, France–Germany border.

The RFC would go on to propose that all articles about Canadian ridings be made to conform with the Manual of Style.

Please note! I am not starting an RFC right now! Do not vote! We're not there yet. I just want to know if others think this would be a helpful way forward. Ozob (talk) 11:38, 25 June 2010 (UTC)

This proposed RfC text is completely unacceptable. It utterly fails to mention why emdashes are currently used, namely that they are used by the official naming authority, Elections Canada (which apparently used endashes for extra contrast with the hyphens commonly found in the French names within the ridings), and that the emdashed versions are used throughout the Canadian press in referencing the ridings. It is generally phrased is a biased way that supports the idea that the MoS is inherently right and the current titles are inherently wrong, even though they are in full conformity with both official and common usage.

Frankly, it's a pointless exercise. While the use if emdashes may not be standard English in most cases, these names, which are the official, proper names and are commonly used by relevant sources, arise from a practical consideration that is peculiar to Canadian English, namely it's need to peacefully coexist with Canadian French. That makes it an ENGVAR and COMMONNAME issue. By those, they are in the right places. oknazevad (talk) 17:00, 25 June 2010 (UTC)

My proposed RFC is a case for change. I hope that it will influence people. I can't rightly present your view because I disagree with it, and I don't want to present your view because I want the RFC to make a clear and firm case for change. Instead I invite you to present a rebuttal to my RFC. I want everyone to hear both sides of the issue, but I will not pretend that I am neutral. Ozob (talk) 03:21, 26 June 2010 (UTC)

You might want to be aware that WP:COMMONNAME is a policy, whereas WP:MOS is a guideline. So commonname trumps the manual of style. Thus the articles should be named with their common names which are to use the emdashes. -DJSasso (talk) 13:45, 25 June 2010 (UTC)

I'd like to take a moment to thank Ozob for a well-timed and much needed injection of levity before proceeding to list complaints about the details of his proposed RFC. Thank you, Ozob. OK, please proceed with trashing it now. LeadSongDog come howl! 21:57, 25 June 2010 (UTC)

So if those gigantic strokes are to be retained, are the editors who this going to volunteer to go through the cat. and add an editorial note at the top, advising well-meaning editors that this is a departure from the MoS? Otherwise, it will waste people's time in the future. Tony (talk) 03:35, 26 June 2010 (UTC)

If the objection to an RfC is that the proposed RfC text makes no attempt to be neutral, that's easily fixed: "Should the names of Canadian ridings conform to Elections Canada or to WP:DASH?" Art LaPella (talk) 04:02, 26 June 2010 (UTC)

No it would be more properly worded "Should the names of Canadian ridings conform to Wikipedia:Article titles or WP:DASH." as technically the person asking is asking to override a policy which already lays out what they should be called with a guideline. As opposed to making it sound like we are bending to some outside force ie Elections Canada. -DJSasso (talk) 18:29, 28 June 2010 (UTC)

The point is, has been and continues to be that this can't be a question of which type of punctuation people like better. Canadian electoral districts have proper names, and those proper names contain em-dashes. Whether you like the fact or not, it's still the fact. Whether Elections Canada should have used en-dashes or not, they didn't. The name of the thing is the name of the thing is the name of the thing, and Wikipedia cannot arbitrarily rename a Canadian electoral district, any more than we could decide that we don't like ordinal numbers in titles and therefore we're going to arbitrarily pick out new names for American congressional districts. Whether it's how the proper name should have been spelled if Elections Canada were up to date on their Strunk & White is irrelevant — whether we like it or not, we're locked into what the actual proper name actually is. Accordingly, DJSasso is correct — this isn't a case of "do we follow Wikipedia policy or bend to some random unimportant source that has nothing to do with us?". It's a case "Do we follow the policy that requires us to title articles about things with the correct proper name of the thing, or do we follow the guideline about punctuation that might seem to encourage something else?" Bearcat (talk) 19:29, 28 June 2010 (UTC)

Inline reference to Chinese words?

Should Chinese (or other language) words referring to events, people, and things appear inline in Wikipedia articles? I have not been able to ascertain this through reading the MoS. See Dai Qing, which is typical. In scholarly works the standard is pinyin, italicised, in parentheses. I seek clarification as to whether the Chinese characters should be purged, left, or in which places they belong. Homunculus (duihua) 02:08, 25 June 2010 (UTC)

In linked proper names, no, just like we don't need "(München)" after "Munich" in any article which happens to mention it. Otherwise, I'd keep it. ― A._di_M.^{3nd Dramaout} (formerly Army1987) 10:19, 25 June 2010 (UTC)

In the Dai Qing article, I think the Chinese characters should be kept in the lede sentence (showing the Chinese spelling of her name) and in the sentence in "Early Life" about a different name that she is also called. Otherwise they should go. —David Eppstein (talk) 19:45, 25 June 2010 (UTC)

Thanks to you both. That's useful. There are quite a number of articles full of Chinese characters for words and phrases, seemingly quite out of place. I will take the above as a mandate for slowly cleaning these things up. Where appropriate, I will replace with italicized pinyin, and for names at the start of articles, will leave the Chinese.Homunculus (duihua) 02:56, 28 June 2010 (UTC)

Agree with what the others said--and I'd go further than A. di M., as I don't see why unlinked proper names are any different. Take "As a result, she joined the Chinese Authors Association (中國作者協會) in 1982." If the association is a clearly defined entity, what reader of the English Wikipedia benefits from the interposition of the Chinese word? (Beautiful though it is!) On the other hand, if it is not an unambiguously defined entity, the Chinese word does not serve the English Wikipedia best as a disambiguator of some kind. If the MoS is to guide, and I think it probably should, I'd like to see a reasoned justification that identifies principles for inclusion, not exclusion. I agree the lead is different, and seems quite appropriate there for the article title (and not disruptive, which it quickly becomes if there are more than one or two instances). On a side note, I suggest that whenever a Chinese equivalent is included, it would be preferable to position it directly alongside the English word. For example, the lead of Dai Qing currently reads:

Dai Qing, born in August 1941, (Chinese: 戴晴, Pinyin: Dài Qíng) is a journalist

but surely it would be better as:

Dai Qing (Chinese: 戴晴, Pinyin: Dài Qíng), born in August 1941 ...

I also note that although not obviously linked from the main MoS page, there exists Wikipedia:Manual of Style (use of Chinese language), where this question is the topic of the first section. Another chance to plug my suggestion to reduce the main MoS page to a glorified ToC which would link to all MoS subpages! PL290 (talk) 07:38, 28 June 2010 (UTC)

I think a construction in the form "Chinese Authors Association (中國作者協會)" is appropriate when the English name is not a well-known translation of the original Chinese name (and, indeed, may be a translation that the Wikipedia editor came up with herself), as this will help readers precisely identify the entity that is referred to. If the English term is well established or if there is already a Wikipedia article about it, then the Chinese characters in parentheses are unnecessary. — Cheers, JackLee ^–talk– 14:37, 28 June 2010 (UTC)

Headings with numerals

When a section title begins with a numeral, should word following it be capitalized or not? For instance, is it "2008 Local elections" or "2008 local elections"? I would figure it's the latter, but the important thing is to have a consistent rule. -Rrius (talk) 03:59, 18 June 2010 (UTC)

I figure the same, but my search for a rule or guideline was not successful. I did find a long list of articles with the following word not capitalized. Please see this list.—Wavelength (talk) 05:09, 18 June 2010 (UTC)

I agree that the second, non-capitalized version is correct. Since the section heading begins with 2008, local is no longer the start of the heading and should not be capitalized. We do not, for instance, write "The 2008 Local elections saw a high voter turnout." — Cheers, JackLee ^–talk– 05:29, 24 June 2010 (UTC)

Non capitalised is the only way that makes sense. Rich Farmbrough, 07:42, 30 June 2010 (UTC).

Replacing of HTML markup for dashes with Unicode characters

I always write em and en dashes using the HTML markup – and —. However I notice that a lot of editors replace these with the Unicode characters which appear in the built-in editor as a hyphen with a small green "n" or "m" above it.

My eyesight is not so great, and I find these very difficult to spot, so I dislike those changes as it hampers my following editing, if only a little bit. I imagine that somehow the tool these editors are using does it automatically, since I can't believe many would waste their time deliberately replacing the HTML markup with a Unicode character; similarly I don't go back and replace them with the markup.

Is anyone aware, then, of the tool that might automatically do this (or in the alternate, that editors make replacing such dashes easy?) I realise one do a global find-and-replace, but it seems to me that is not typically done, because even within a single section edit they are often missed, particularly if they occur within <ref> tags.

The point is very minor, I know, but I'm not grumbling because "someone changed 'my' article for no good reason", simply that I find it less legible that way, and I imagine other editors with visual impairments might do likewise (I don't know how it might appear on a screen reader for example). It's not life and death, but I imagine this might apply to other HTML markup that is displayed in a similar way by the built-in editor. There's no guidance I can find on which is preferred in the Wiki markup, unless perhaps it comes under general accessibility criteria: but I think that applies exclusively to the article as it appears in a browser, not in an editor?

I'd appreciate any pointers or comments. Si Trew (talk) 05:16, 24 June 2010 (UTC)

I don't have a tool. On a Mac, one can hold down the option key and type the hyphen key to get an en dash. Add the shift key to that to get an em dash. Bullets are option-8. Additionally, there's a link below the edit window that one can click to insert either dash. Imzadi 1979 → 05:27, 24 June 2010 (UTC)

Thanks for that, but I think it is beside my point, which is that I write ndash or mdash and "something else" changes it. I've no objection to the change beyond that I find it hard to see (and so am tempted then to change it back because I erroneously think it has been changed to a hyphen); and I assume (as the response below indicates) that a tool automatically does that.

Changing – to – and — to — is done with WP:AWB's "Unicodify whole page" feature, described here. So AWB prefers ~~–~~ –. Periodically people here express a preference for the opposite change. I wish there were one big discussion here, not an – camp here and a – camp at AWB. Art LaPella (talk) 20:40, 24 June 2010 (UTC)

Thanks; point noted about "one big discussion". I don't see much point in pursuing this if there are obviously two camps of thought; I could add that (as an essay I collaborated on [{WP:OWNFEET]] tends to carp on about) making these kinds of changes while also making other changes can be very distracting in general and I would wish that the two kinds of edit were made separately; presumably a fault/feature of AWB if it has some option just to do it automatically. I've no desire to learn AWB (and that's not from Luddism). Si Trew (talk) 21:07, 24 June 2010 (UTC)

On one hand, wiki markup is already hard enough to read, and using entities only makes that worse; on the other hand, in many monospaced fonts some or all of - – — − are very hard or impossible to distinguish. On the gripping hand, I know that proposing once again that en dashes be input as -- and em dashes as --- (as it's done in TeX) would be a waste of breath. ― A._di_M.^{3rd Dramaout} (formerly Army1987) 15:58, 25 June 2010 (UTC)

That's a pity, since -- and --- seem very good suggestions to me. I've not thought through the implications (not read your link yet) but I've edited enough articles to know that plenty of people write -- anyway (or perhaps copy/paste it from a tool that converts it to that on-the-fly? My guess is that people just get used to it being converted for them in Microsoft Word, and forget they can't do that in a plain old text editor: I do, sometimes.) Si Trew (talk) 22:54, 25 June 2010 (UTC)

I wouldn't say that "plenty of people write -- anyway"; I would say that far too many people write that way. It's ugly and I wish they would stop. It's the wrong mark to use; the hyphen isn't even punctuation, is it? I think it's a spelling tool. Hmm, I'll have to think about that one.

But the argument is not persuasive anyway. Plenty of people drive too fast, or without safety belts; plenty of people smoke; plenty of people— Ah, but we needn't be coerced into doing the wrong thing because plenty of people do it; we can choose the correct way. Hyphens aren't it, when we're writing what calls for a dash, and we're not forced to do it on a manual typewriter from 1956.

In the case of the ridings, I'd probably choose the em-dashes for maximum differentiation from the hyphens. But what I really want to know is, what does playing Scrabble have to do with knowing about dashes? — JohnFromPinckney (talk) 23:32, 25 June 2010 (UTC)

Scrabble players need to know lots of obscure words, and they need to have a definition for them. I know a guy who is a championship Scrabble player. He doesn't care about typography at all, but I'd bet you $100 that he knows what en dashes and em dashes are. Because—guess what—endash and emdash are legal plays. See [5]. Ozob (talk) 13:02, 26 June 2010 (UTC)

What I meant to suggest was not to use -- in the articles, but to implement a feature in wikimarkup automatically converting -- in the source to – in the rendered article (except in <code> tags and similar). That's what TeX does, for example. ― A._di_M.^{3rd Dramaout} (formerly Army1987) 23:40, 25 June 2010 (UTC)

SimonTrew, you wrote "However I notice that a lot of editors replace these with the Unicode characters which appear in the built-in editor as a hyphen with a small green "n" or "m" above it." What built-in editor is that? The built-in editor I see does nothing of the kind. I am using the default skin, and didn't select any special editor in the options. Jc3s5h (talk) 21:27, 24 June 2010 (UTC)

Simon, I appreciate your point; but newbies and our many visitors who attempt to edit must be bamboozled by the gobbledy HTML codes for these simple symbols. It works both ways, and my instincts are that "the encyclopedia that anyone can edit" should go simple wherever it can. May I suggest that if you have a large enough monitor, you do what I do: open the edit box beside the display mode, and read both. I like a WYSIWYG view, too—it's a very important part of editing. Tony (talk) 16:47, 25 June 2010 (UTC)

Well, is a newbie user likely to know what an em or en dash is? Possibly only if they are familiar with typography or play Scrabble. I don't have a particularly large monitor (1024×768). Personally I don't care much about "WYSIWYG" because Wikipedia is supposed to be accessible on all kinds of devices, so "what you see is not what someone else might get"; I think the point is more to structure the text properly and let Wikimedia do the rendering. Of course, I do always (ahem...) preview edits.

It's really not a big deal, I find it just annoying when you get a difference that is cluttered with these things and, if there is no edit summary, have to kinda rattle through them all to find what the real change was. Of course, that is more a case of WP:ES than this particular thing, although making multiple kinds of minor changes all in one edit exacerbates it, in my opinion. Si Trew (talk) 22:24, 25 June 2010 (UTC)

My take on the matter is that if it looks identical in reader-mode, then it's as good as a dummy edit. Let people decide how they want to waste their time so long as it's all the same to the readers. However, I do like the idea of setting things up to auto-convert "--" and "---" to en- and em-dashes, respectively. It seems much more intuitive and easy to learn than digging around through pages and pages to find out the code for an en dash. Darkfrog24 (talk) 01:02, 26 June 2010 (UTC)

DF, is someone considering creating an autoconvert for double and triple hyphens? Tony (talk) 09:25, 26 June 2010 (UTC)

A. di M. mentioned something about how it would be futile to introduce such a proposal. I think it sounds pretty neat, though. Darkfrog24 (talk) 01:23, 27 June 2010 (UTC)

I agree, though for dummy edits I usually change the number of spaces after a sentence. :-) ― A._di_M.^{3rd Dramaout} (formerly Army1987) 09:49, 26 June 2010 (UTC)

User:Cameltrader/Advisor.js does give the option to convert HTML entities to Unicode. ---— Gadget850 (Ed) ^talk 02:03, 1 July 2010 (UTC)

Italicised article titles

There seems to be some inconsistency surrounding the italicising of article titles. Eagle (comic), for instance, is italicised. The Dark Side of the Moon, however, is not. Hamlet, is. What's the rule here? Naming conventions suggests a different use of italics entirely. This discussion at WT:FAC also raises a point about radio programme titles. What gives? Parrot of Doom 19:55, 28 June 2010 (UTC)

In running prose? The idea there is not that article titles should be italicized, but rather that the titles of long-form works should be. Hamlet is a play, so it should be italicized when referred to. Ditto for comic titles. (I don't know about albums, though.) However, it seems that many editors forget to do this when the text is already different from regular prose in some other way, as in Hamlet. (Should be Hamlet). Songs and poems are short-form works so they'd be "Jingle Bells" and "The Road Not Taken."

It seems that the key question here is whether radio shows are long-form works or short. I'd have to look it up to be sure, but if Friends is a long-form work, then I suppose the radio serial of The Shadow would be too. Darkfrog24 (talk) 22:26, 28 June 2010 (UTC)

According to MLA, radio shows are long forms and take italics (or underline). Truthkeeper88 (talk) 22:37, 28 June 2010 (UTC)

Yes, that's the style I followed in the Featured Article Mutual Broadcasting System: the title of a radio series is italicized, the title of an individual episode from that series (e.g., an episode of an anthology series such as CBS Radio Mystery Theater) would appear in quotes.—DCGeist (talk) 22:38, 28 June 2010 (UTC)

None of which seems to address what I take to be Parrot of Doom's query: should article titles include italicization? (Um, right, Parrot?)

Apparently, the technology has been developed to italicized article titles. If you look at the very firts code line of Hamlet, you'll see {{italic title}}, which is what makes Hamlet show up that way at the top of the article. I do not see how Eagle (comic) is doing it, although I can see Template:Italic title is shown in the list of transcluded templates.

My understanding is that this ability was developed largely to satisfy the folks in the bio projects, who like Coyoteus stupidus and E. coli in italics. Somewhere in just the last couple of months I read through a long discussion as folks tried to decide whether to implement/allow/force this thing WP-wide or only among the life-sciences articles or not at all. As I understood it, there was some warm consensus for bio articles, with tepid consensus for not using this site-wide. I'll look again for this, but if you're interested, you should look too, because I have no idea where I saw it.

Parrot of Doom mentions Naming conventions, and I think that's because the text there says, "It is not possible for a title (as stored in the database) to contain formatting, such as italics or bolding." It then goes on to say, however, that displaying is possible, but should only be used in limited areas (flora, fauna, etc.).

I take that last bit to mean that Hamlet and Eagle (fauna though it be) are improperly formatted, as the consensus is against it in such cases. Parrot, is that what you meant? And what do you all think of the idea, since we're here? — JohnFromPinckney (talk) 23:05, 28 June 2010 (UTC)

Spot on John. Personally I think that italicised subjects should have italicised titles. I can't think of a valid reason not to do that. Parrot of Doom 23:14, 28 June 2010 (UTC)

The only reason not to do that would be the work involved to change all the article names of books, plays, televisions shows (but not episodes), albums, and so on. I agree with PoD - such a change makes sense, and I've often wondered why the title The Sun Also Rises is italicized but the article title not; nevertheless, unless the change could be botified, it would be a big task. Truthkeeper88 (talk) 23:58, 28 June 2010 (UTC)

@PoD; the idea of italicizing titles started with people doing it for species names by sticking it in infoboxes, but a great majority of media-related projects and people rejected widespread adoption of italics. I'll try and find the archives, I remember I participated but don't remember what venue all the chatter occurred at. Der Wohltemperierte Fuchs^(talk) 00:00, 29 June 2010 (UTC)

Ah, it can more or less be found at Template Talk:Italic title. The result of the RfC as archived stated: "This template may be used for the purpose of italicizing genera and species in the Tree of Life Wikiproject. All other scopes of the English Wikipedia are in disagreement about whether to use it, so please avoid using it for other purposes." A big reason for the resistance was the (as far as I know, unresolved) issue of extra space taken by the template/hidden formatting, as well as there is no consistent way to apply custom styles as needed. Der Wohltemperierte Fuchs^(talk) 00:07, 29 June 2010 (UTC)

That looks like the usual nonsensical wikipedia discussion about any proposed change. Malleus Fatuorum 01:08, 29 June 2010 (UTC)

There's no more reason to italicize article titles here than there would be to italicize a book's title on its own cover. (Look at the books on your own shelf and count how few of them italicize the title.) The title at the top of each article here is a label, nothing more. — Carl (CBM · talk) 01:50, 29 June 2010 (UTC)

I agree. Look at a print encyclopedia. How many of the article titles are italicized? Any? Ozob (talk) 02:07, 29 June 2010 (UTC)

Well, when you look at a book's cover, you know you're looking at a book. When you look at an encyclopedia article title, you have no such context. The idea seems worth considering. And it seems unsatisfactory to deprecate it without identifying specific objections, or for Naming conventions to speak vaguely of "special cases" without identifying any qualifying principles. However, the idea carries the implication that other typographical conventions too ought to apply to article titles in the same way, the obvious one being putting shorter work titles in quotes. And whereas we might quite like the idea of an article titled The Dark Side of the Moon, would we also want articles titled "Money" (Pink Floyd song) or "Us and Them" (song)? Perhaps. PL290 (talk) 06:45, 29 June 2010 (UTC)

Some of the books I own don't capitalise their names. Perhaps we should follow suit? Parrot of Doom 10:29, 29 June 2010 (UTC)

@PL290: when I look at an article on Wikipedia, I am well aware I am looking at an article on Wikipedia. Italicization is a matter of style, and it's perfectly reasonable for our style to simply put everything in roman. You argue it's unsatisfactory to deprecate italic titles without strong reasons, but that misses the point that there's no strong reason for implementing them in the first place. The argument seems to be built on the mistaken idea that certain titles must always be italicized. But looking just at the title pages of the books themselves will reveal that to be false. — Carl (CBM · talk) 10:48, 29 June 2010 (UTC)

It reminds me of a Two Ronnies sketch where a library organizes books by colour. I was going to add some more serious remarks, but really... all one has to do is take common sense. Considering how the various citation styles vary on italics (which makes references look a mess if they're mixed), I think that this is an uphill battle. For example, I put foreign words generally in italics; I put titles in italics; what do I do with titles in foreign languages? If I am not careful they will come out of italics: something easy to fix in articles but harder if one uses templates that use templates that each decide to put something in eyeties. Italics are purely typographical conventions and should not alter meaning (though of course they can alter emphasis). For if not, we will end up with Eagle (the bird) being a separate article from Eagle (the comic), which is absurd: but I am sure we would already have if the software allowed it. Si Trew (talk) 11:06, 29 June 2010 (UTC)

Some manuals of style consider that a "stand-alone" work should be italicized (book, monograph, etc.), while a work that is that is part of a larger (newspaper article, encyclopedia article, book chapter, journal article, etc.) is in quotation marks. For other uses of italics, there are some generally accepted conventions in style guides (I've examined quite a few), and for others there are differences. My recommendation would be for Wikipedia to conform to the italicizations that are "conventional" in the major style guides, and make a decision on the ones that are less firm. --Airborne84 (talk) 12:20, 29 June 2010 (UTC)

Yes, that's what we should do for running text or in a bibliography. But the title at the top of an article isn't part of the article's text, just as the cover page of a book isn't part of the running text of a book. For the actual title page or cover of a work, there is no convention towards italics or quotation marks. How many journals put every article title in the table of contents into quotation marks? — Carl (CBM · talk) 12:51, 29 June 2010 (UTC)

@Airborne84: The problem is that while there's a fair amount of consistency, there's still not enough. Essentially, if we decided to go with full-on formatting, it would fly in the face of many style guides, including those that might be used for formatting references (since we allow any type of recognized, consistent citation—actually, the citations don't even have to be from a style guide, as long as they're acceptable to follow.) My newspaper, for example, doesn't italicize works in its body, though it uses quotes for songs and smaller works. While it's generally accepted that books, albums, longer-forms get italics, in other places they are underlined instead. The standards for songs, journal articles, etc. vary even more widely. The only reason {{italic title}} was accepted by the Tree of Life people is because there's next to no dissent in the fact that you format species like Homo sapiens. Der Wohltemperierte Fuchs^(talk) 13:44, 29 June 2010 (UTC)

It's worth noting that the Merriam-Webster dictionary on my desk does not italicize the entry for "Homo sapiens". It also does not italicize the entries for "joie de vivre" or "aloe vera". — Carl (CBM · talk) 14:08, 29 June 2010 (UTC)

Revert to "Animals, plants, and other organisms"

All that I did in that edit was swapping the section on this page with the section in WP:MOSCAPS, because the former was more detailed than the latter. Now Ben MacDui reverted me on this page but not on MOSCAPS, so now we have this section exactly duplicated on the two pages. ― A._di_M.^{3rd Dramaout} (formerly Army1987) 08:54, 30 June 2010 (UTC)

News to me it existed at MOSCAPS at all (and your edit summary of 25.5.10 didn't refer to this). I think the current version is OK, save that "normally" needs to be inserted between "Common names shall not" and "be capitalized" in order to agree with the exceptions listed there. Ben Mac Dui 18:48, 30 June 2010 (UTC)

Etymology format needs standardizing

I would like some feedback about my ~~Requested Template~~ [..Since moved to here] and requested formatting standard of etymology within Wikipedia articles. It's a bit too long to repeat here, so please follow the link provided. If you want to comment about the template, please do so on that page. If you want to talk about standards, please comment below. Regards, Nagualdesign (talk) 23:51, 24 June 2010 (UTC)

Hang on, you want us to go and read it over there and then reply over here? Sorry, but I just replied over there (and I'm not the only one.) Si Trew (talk) 22:40, 25 June 2010 (UTC)

Having had some feedback I would like to withdraw my request for etymology placement standards. Maybe rigidly placing in-line etymology statements in the opening paragraphs is a bit restrictive. But as a guideline I'd still like to suggest that etymology statements do constitute part of a good definition (and are therefore suitable for opening paragraphs). Nagualdesign (talk) 00:15, 27 June 2010 (UTC)

I'll just add a note here that the result, with input from User:Nagualdesign, User:Svick and myself, was a new template {{ety}} that is currently RFM to {{etymology}}, this second being the first stab but the first being the one we intend to adopt. As mentioned, we're not suggesting incorporating into MOS at this time. Si Trew (talk) 07:44, 2 July 2010 (UTC)

Long s in quotations from primary sources

When I saw "Great Black Waſp" in the section "Did you know ..." on the Main Page, (permanent link here), I remembered a discussion now archived at Wikipedia talk:Manual of Style/Archive 115#Long s in quotations from primary sources.—Wavelength (talk) 00:31, 30 June 2010 (UTC)

But nobody else remembers this stuff. If your point is that it should have been changed (and I'm not sure it should; one isolated ſ is just the sort of curiosity Did You Know needs), then I don't remember seeing you at WP:ERRORS. Art LaPella (talk) 01:02, 30 June 2010 (UTC)

I do not have a preference either for or against the use of long "s", but I commented for anyone who may be interested in the matter, and who may or may not have a preference either for or against the use of long "s".—Wavelength (talk) 01:10, 30 June 2010 (UTC)

I have a preference against the long S. To general-audience readers, our target audience, it looks like an F. Using a legible S is like changing the font; we should do it. Darkfrog24 (talk) 02:53, 3 July 2010 (UTC)

Articles ("The and A") in section headings

I thought there was a preference not to have "The" or "A" at the start of section headings (i.e. a guideline in MOS:HEAD), but I can't find one there. Is there one? Si Trew (talk) 10:17, 1 July 2010 (UTC)

Point 6 of Wikipedia:Manual of Style#Article titles (permanent link here) says the following.

Do not use a, an, or the as the first word (Economy of the Second Empire, not The economy of the Second Empire), unless by convention it is an inseparable part of a name (The Hague).

The introduction of Wikipedia:Manual of Style#Section headings says the following.

All of the guidance in Article titles immediately above applies to section headings as well.

—Wavelength (talk) 13:51, 1 July 2010 (UTC)

Thanks, I thought it was indirected there, but failed to see it. Si Trew (talk) 18:51, 1 July 2010 (UTC)

Italics in section headings

Italics in section headings can disambiguate double entendres. I have assembled this assortment of links for the consideration of editors.

Felix Mendelssohn#Revival of St Matthew Passion (permanent link here)
Antonio Vivaldi#At the Conservatorio dell'Ospedale della Pietà (permanent link here)
Antonio Vivaldi#Mantua and The Four Seasons (permanent link here)
Mark Twain#Tom Sawyer and Huckleberry Finn (permanent link here)
Aesop#The Aesop Romance (permanent link here)
Shirley Temple#Baby Burlesks (permanent link here)
Shirley Temple#Bright Eyes and Academy Award (permanent link here)
Rolf Harris#"Stairway to Heaven" (permanent link here)
The Beatles#Revolver and Sgt. Pepper (permanent link here)
The Beatles#Magical Mystery Tour, White Album and Yellow Submarine (permanent link here)
Lewis Carroll#The Hunting of the Snark (permanent link here)
Johann Pachelbel#Popularity of the Canon in D (permanent link here)
Judy Garland#The Wizard of Oz (permanent link here)
Judy Garland#A Star Is Born (permanent link here)

—Wavelength (talk) 06:32, 2 July 2010 (UTC)

Are you aware that that section header formatting is completely dependent on the browser? All level-3 headings are italicized for me, so in the first article on your list the entire phrase "Revival of St Matthew Passion" is in italic, even though the HTML source does show italic tags around just "St Matthew Passion". On the other hand, the TOC is not italicized, and that entire section title is in roman in the TOC that I see (the actual HTML contains no instructions for italics in the TOC). — Carl (CBM · talk) 12:01, 2 July 2010 (UTC)

It is not your browser, it is the CSS rules in User:CBM/vector.css. Otherwise, I am not sure if the OP is asking or proposing something. ---— Gadget850 (Ed) ^talk 13:01, 2 July 2010 (UTC)

Sure. My point is that we can't expect that our section headers will have any particular formatting, because individuals are likely to have set specific formatting on them already. Similarly, we cannot assume our body font is any particular size, or that it is serif or sans-serif. All of these are things that we can expect a reasonable number of people to format using user stylesheets (which can be done locally inside most browsers). The Opera browser even has a UI to configure which fonts are used for H1, H2, etc., so no use of stylesheets is needed. — Carl (CBM · talk) 14:37, 2 July 2010 (UTC)

I was going to comment in the section #Italicised article titles above, before I decided to start a new section. I have not compiled a list of examples of article titles involving a similar ambiguity, but italics would be helpful with them also. I am proposing that italics (or quotation marks, according to the distinction between long and short works) be required for articles (or parts thereof) and for section headings (or parts thereof).—Wavelength (talk) 14:08, 2 July 2010 (UTC)

For readers with browsers which do distinguish italics from non-italics, section titles such as "Tom Sawyer and Huckleberry Finn" are better than "Tom Sawyer and Huckleberry Finn"; for browser which don't, they are no worse. So I can see no good reason to avoid using such titles. ― A._di_M.^{3rd Dramaout} (formerly Army1987) 19:31, 2 July 2010 (UTC)

Section headings— invalid HTML

While on the subject, headings must start with A-Z or a-z; any other characters will render an invalid HTML id. There are other rules for HTML ids, but the MediaWiki software takes care of these. The TOC to section link still works, but the page will fail validation. T11530. ---— Gadget850 (Ed) ^talk 13:23, 2 July 2010 (UTC)

DocumentHistory template--do we need to rethink?

Some editors here recently expressed interest in establishing a system for keeping track of MoS document status history. During that discussion, I created the template {{DocumentHistory}} for this purpose. An editor has since objected to its use at Wikipedia talk:Manual of Style (dates and numbers), proposed its removal, and in fact removed it, twice. I'm not aware of anyone else objecting to it or supporting that removal, but I feel I should now ask all interested parties to consider again whether such a template is indeed something that will be useful to us. I would like to think it is. I hope we can discuss and resolve any issues that may currently be being caused by its use. PL290 (talk) 22:10, 18 June 2010 (UTC)

This seems to have lost momentum. It's intended to address concerns raised repeatedly in the past, and some interest was initially expressed, so it would be unfortunate if the idea faded away simply because it's not being plugged enough or folks are busy on other things at the moment. The current template was very easy to create, and if it's dropped or replaced by something different, that's not an issue. But I'm hoping for further comments about the general initiative, which was suggested by Chickenmonkey in an earlier discussion, and which I think has potential. I would like to hear more voices about this, so that we can come to a clear conclusion about whether to go with it or drop it. Please comment! PL290 (talk) 04:28, 25 June 2010 (UTC)

I certainly believe this would be a helpful template. As I previously expressed, navigating the Manual of Style is exhausting, unnecessarily so. My initial suggestions were to run a systematic review of all current policies/guidelines listed as "part of the Manual of Style" and discern whether consensus exists to keep them within the MOS. Then, after such a consensus is reached, this template would make complete sense, in my opinion, to document exactly when a guideline became a "part of the Manual of Style". Currently, there isn't a system, that I know of, which documents this. If there is such a system, I believe it makes sense to place that on the given policy/guideline's talk page. We already do this for the history of "when an article was reviewed, was listed as good, was listed as featured, was delisted, etc"; that system works very well in providing transparency of how and why articles are "good" or "featured". It would make sense, I think, to document the discussions where a policy/guideline became a "part of the Manual of Style". Currently, it seems anyone can just tag a guideline as "part of the Manual of Style" and that's that. This makes no sense. What could possibly be the drawback of such a system? We would be: verifying whether a guideline should be a "part of the Manual of Style", documenting such verification for any future challenge's to such a claim, and providing transparency on what a guideline needs to be like in order to be a "part of the Manual of Style". Chickenmonkey 05:32, 25 June 2010 (UTC)

I think this is a terrific idea that should be promulgated throughout the MoS—frankly, throughout all policy and guideline pages. While doing research related to the recent style-guideline page-titling rationalization effort, I engaged in laborious edit-history combing to determine when and how certain pages had been accorded guideline and/or MoS status. Unless someone lucks onto my resulting Talk page posts, anyone interested in that sort of information will have to go through the exact same time-consuming process. This template both removes that burden from those who may be concerned with such matters after the task is accomplished just once and, obviously, makes the history instantly accessible and thus far more transparent to any interested editor. You have my full support.—DCGeist (talk) 23:38, 25 June 2010 (UTC)

Hats off to PL290 for creating this template. It looks extremely useful and functional to me. The template should be use as widely as possible to help editors keep track of all the important changes of status, reviews etc that otherwise get lost in the edit history and on talkpages. Can't understand why any one would object, frankly. Full support also from me --Jubilee ♫clipman 00:03, 26 June 2010 (UTC)

I agree. Thanks heaps for this, PL290. Anything we can do to keep tabs on the MoS sprawl is very welcome. We don't want an octopus monster; we want a neat, convenient, editor-oriented resource that is kept under good management and coordinated logically. Tony (talk) 09:20, 26 June 2010 (UTC)

There is clearly no objection here - although of course that may mean nothing at "Wikipedia talk:Manual of Style - car number plates" etc. Nonetheless I encourage boldness. Ben Mac Dui 11:30, 3 July 2010 (UTC)

Square brackets in page titles...?

Reading the manual of style, I see that square brackets are forbidden in page titles. Does anyone know of a workaround for this? Some organic chemistry pages I'm working on would benefit in a HUGE way from a workaround...namely, pages dealing with cycloaddition and sigmatropic reactions, whose notation uses square brackets (e.g. [4+2], [3+2], etc.). Any plans to get a solution in place, or does a solution exist now? OrganicReactions (talk) 18:59, 25 June 2010 (UTC)

See WP:NCTR about these. This is a technical restriction with no workaround. Your best bet is to file a feature request in BugZilla. Ozob (talk) 23:34, 25 June 2010 (UTC)

I don't actually like this kind of hacks, but one possible workaround is to use a non-ascii square bracket variant, such as U+FF3B/U+FF3D FULLWIDTH LEFT/RIGHT SQUARE BRACKET:［4+2］. Of course, no reader would ever figure out that the article is to be found at such a title, but that can be sorted out with a handful of redirects.—Emil J. 12:35, 29 June 2010 (UTC)

Except, of course, that you can't create the redirect page with the real []. Rich Farmbrough, 08:45, 30 June 2010 (UTC).

Just curious: would using ASCII codes (i.e., [ and ]) in the page name work? I'm assuming not. — Cheers, JackLee ^–talk– 20:27, 3 July 2010 (UTC)

Nope, it doesn't work. "[" in the URL is simply interpreted as an ampersand, and presumably anything after the hash is interpreted as a bookmark. — Cheers, JackLee ^–talk– 20:31, 3 July 2010 (UTC)

Following WP:NCTR, I suppose the solution is to call the article something like "4+2" and then have a hatnote stating {{bracketed|[4+2]}}. — Cheers, JackLee ^–talk– 20:37, 3 July 2010 (UTC)

Listing countries

What portions of the manual of style explain how to list dependencies of countries? Or is there a unified way to do so? A user asked me how to list territories like Hong Kong and Gibraltar on certain lists, but I am not sure where a policy or guideline is for that. Thanks WhisperToMe (talk) 19:38, 3 July 2010 (UTC)

And categories too. The footnotes of the article Country provide several examples under which dependencies are presented in the same manner as other countries. There are also links to court rulings regarding the meaning of the word country.

Crossposting from [6]: " Thanks. Hong Kong and the People's Republic are on the same continent.., so as the Channel Islands, Gibraltar and the UK. Could you suggest some examples in which they should fall under the same section, and examples in which they should have separate sections? Let's say, on a list of tunnels, on a list of subways, or on a list of museums? And what about categories? Should a category for buildings in the Faroe Islands or in the Åland Islands be placed right under the buildings by country category, for instance? Is there any official convention or guideline that we can rely upon, especially when dealing with troublemakers? 112.118.163.236 (talk) 19:28, 3 July 2010 (UTC) " 112.118.163.236 (talk) 19:46, 3 July 2010 (UTC)

It's not part of the MOS (or indeed any policy or guideline so far as I am aware), but we did have a discussion on this and similar subjects at WT:WikiProject Countries/Lists of countries. The conclusions were:

Where a list is based on a single source, the inclusion criteria of the source should determine the inclusion criteria for the list.
Otherwise, lists should include the entities listed on ISO 3166-1; states with limited recognition should be noted in a neutral way.
Where specific circumstances make it more logical that some other configuration should be used, that configuration should be used.

In the case of dependent territories listed on ISO 3166-1, I believe it's common practice to give them separate listings but with the name of the sovereign state concerned in brackets afterward. So, for example, you might list:

Greenland (Denmark)

Part of the problem is that the word country is ambiguous: most people "know" what it means, but their definitions often do not match. The word dependency is also not well defined and open to interpretation. Pfainuk talk 20:03, 3 July 2010 (UTC)

What about, e.g., a list of museums, where there are separate sections for each country? And what about categories within Category:Foo by country structures? The word country may be ambiguous, but it generally covers all sovereign states and inhabited dependent territories. The Australian court rulings cited in the article Country should provide some insights. User:Electionworld devised a List of countries some time ago with clear criteria for inclusion and exclusion. 112.118.163.236 (talk) 20:11, 3 July 2010 (UTC)

You demonstrate my point, I believe. To some people, a country covers all sovereign states and inhabited dependent territories. To others, it includes uninhabited dependent territories or excludes all dependent territories. To still others, it includes the integral parts of some sovereign states. To many, a country can perfectly well extend across international boundaries. To some it includes micronations. It may include all states with limited recognition, some of them, or none of them. This is why the old list of countries ended up as a redirect: there were intractable differences as to what belonged on a definitive list "of countries".

A "dependent territory" is similarly an awkward concept. Some would argue that this includes some entities that send representatives to a national parliament. Others would consider those entities excluded by definition. Some would include entities that have free association agreements, or that have a similar status historically. Others wouldn't. In your previous message, you gave several examples: Hong Kong, the Channel Islands, Gibraltar the Faroe Islands and the Åland Islands. All have slightly different statuses and most don't clearly fall into the "dependent territory" box. Pfainuk talk 20:30, 3 July 2010 (UTC)

Yes.. but for the purpose of listings (e.g. List of museums) and categorisations, is there any rule that we can rely upon? There are some users targeting mostly at Hong Kong and Macau. These communist nationalists basically got disturbed whenever Hong Kong is presented in the same manner as other countries, be it categories, lists, or whatever. Their solution is edit wars. 112.118.163.236 (talk) 20:37, 3 July 2010 (UTC)

Not in the MOS, so far as I am aware. There is a general rule (see also here) that lists should define their structure in the lede: if you can agree inclusion criteria and structure by consensus and add them to the lede of an article, then you can cite those criteria as reason to remove entries. Obviously these criteria can be changed by later consensus. Doesn't work so well for categorisation, though. Pfainuk talk 20:51, 3 July 2010 (UTC)

Thanks. Can any general rule be devised, let's say, under the WikiProject Countries, or under Wikipedia:Lists and Wikipedia:Categorisation? 112.118.163.236 (talk) 20:55, 3 July 2010 (UTC)

There is a reason why Instantnood was banned

Because he wants to use style, layout, templates, and categories for nationalist POV pushing. Please be aware of that while discussing this with his current IP sock. SchmuckyTheCat (talk)

Please substantiate your claim, and demonstrate in what way is your claim relevant to the discussion here. 112.118.163.236 (talk) 22:34, 3 July 2010 (UTC)

MoS/MOSNUM duplication

I've just reverted the excision of nearly 100,000 bytes of the MoS—apparently guidance that relates to MOSNUM. It needs thorough discussion first. Could editors provide feedback here? Tony (talk) 04:46, 5 July 2010 (UTC)

This discussion is already under way. Please do not comment here - rather continue the discussion in the section Layout on weights and measures in Mosnum (earlier in this article)

Undue weight question

I remember being told once that "X award-winning" shouldn't be used in the intro because it's undue weight. However, I've looked at all the MOS pages and WP:UNDUE but I can't find anything that says this — I just remember removing it from Shenandoah (band) when it went to GA. Ten Pound Hammer, his otters and a clue-bat • ^{(Many otters • One bat • One hammer)} 19:13, 5 July 2010 (UTC)

I think the part that you're looking for is MOS:LEAD#Relative emphasis, and also the biography section a bit below that. In short, you should only emphasize something in the lead if similar emphasis should be given on it in the body. In relation to a band, my interpretation is that it would usually be okay to mention a significant award, provided you gave a proportionate explaination of how they earned it. WFC (talk) 20:11, 5 July 2010 (UTC)

Layout on weights and measures in Mosnum

Recently the section on weights and measures was reorganised. This was not a matter of changing policy but in clarifying the layout by rearranging the dot points under slightly different headings. I propose to incorporate many of these changes into MOS.

The first one is to add a sub-subheading on scientific and technical units as per MOSNUM. Are there any comments, suggestions or concerns? Michael Glass (talk) 08:40, 27 June 2010 (UTC)

OK. My comment would be that WP:MOS should summarise WP:MOSNUM. I don't think that trying to replicate it in full is useful or beneficial. Pfainuk talk 08:53, 27 June 2010 (UTC)

How does your comment apply to my proposal to add a sub-subheading on scientific and technical units? Or is it a general comment? Michael Glass (talk) 12:30, 27 June 2010 (UTC)

Agree completely with Pfainuk's comment. The question of what form the main MoS page takes is one that's been discussed a lot recently, but whatever the answer to that question is, I think that WP:MOS#Units_of_measurement, if it continues to exist, ought only to summarize. The applicability of the comment to your proposal is that any reworking of WP:MOS#Units_of_measurement should, in my opinion, be to turn it into a summary, rather than to perpetuate the collection of partial detail from WP:MOSNUM that it is at present. PL290 (talk) 14:01, 27 June 2010 (UTC)

I agree. See User:A. di M./MOSNUM for an example of how the section at the main MoS page could look like. (Note that I wrote it a while ago based on the then-current content of MOSNUM, which has since changed a little.) ― A._di_M.^{3rd Dramaout} (formerly Army1987) 17:26, 27 June 2010 (UTC)

I also agree that it should be shortened. I would go further and say that rather than make is a summary, reduce it to just the objectives, as has been done for Geographical Names. As an example, visit User:Martinvl/MOSNUM - the text for this has been culled from WP:MOS. Martinvl (talk) 21:19, 2 July 2010 (UTC)

I have been WP:BOLD and invoked my suggestion of 48 hours ago. Given the amount of material that passes through this talk page, I felt that if I waited much longer, this entire discussion would fizzle out and disappear into the archive. Martinvl (talk) 19:31, 4 July 2010 (UTC)

The first problem with this edit is that it specifies two "main" references. The chances of them agreeing with one another in detail over a period of time are low. If a simple summary is provided here there needs to be a single point of reference. If a second one is provided at all it should be as a "see also". Ben Mac Dui 08:22, 5 July 2010 (UTC)

While User:Ben MacDui raises a valid point, I believe that there is a clear demarcation between the articles - one of them addresses which units should be used - for example yards, feet or both while the other addresses how they should be written - for example 4 metres, 4 meters, 4 m, 4 mtrs, 4 m's, 4 M's, 13 feet, 13', 13 ft, 13 FT (some items in this list have been prescribed in the article). As long as later authors keep within the subject matter, I do not see any risk of the two articles giving conflicting information. Furthermore, by making the split that has been proposed, we do not have to keep WP:MOS and WP:MOSNUM in perfect synchronisation. Martinvl (talk) 10:24, 5 July 2010 (UTC)

In which case can I suggest you draft something that would include a brief summary of the issues the two "main articles" refer to so that idle editors such as myself can get straight to the point? A secondary concern I have is that the summary you previously suggested is possibly too brief. I understand that there is a move or moves afoot to have unnecessary detail held elsewhere, but my first take on this proposal is that it said so little as to require anyone needing information to look at the "main" articles. This may be the intention and I have no in principle objection, but there is clearly a trade-off. Brevity here may make for a less daunting page, and as you suggest, make it easier to avoid conflicts. On the other hand the danger is that those even idler than myself may look at a very simple summary and think "common sense is OK then" without bothering to dig any deeper. Ben Mac Dui 15:32, 5 July 2010 (UTC)

I agree that having two "main" links is problematic. I also agree that shifting as much detail as possible off the main MoS page is a step in the right direction. I would advocate either that such detail be replaced by a simple summary (accompanied by a single "main" link to the subpage), or, perhaps better still (and here I again shamelessly plug my recent suggestion), be replaced by a simple entry in a glorified table of contents. The ToC approach is illustrated by the crude mock-up at User:PL290/MoS. Reducing the main MoS to a ToC removes both the duplication issue and the "not digging deep enough when presented with a simple summary" issue. PL290 (talk) 19:21, 5 July 2010 (UTC)

I have extended my proposal in User:Martinvl/MOSNUM. Each bullet point has a link to a specific section in WP:MOSNUM. My rationale has been that only rarely should changes in WP:MOSNUM affect WP:MOS as WP:MOS asks general questions, but WP:MOSNUM gioves several specific answers. Any comments? Martinvl (talk) 20:06, 5 July 2010 (UTC)

I've taken the liberty of adding a couple of comments about the wording on the assoc. talk page. I think its more useful, although I would still prefer to see a clear distinction in the text between the two "mains" that helps the reader understand which one to look at first. Ben Mac Dui 08:58, 6 July 2010 (UTC)

I think if there is to be a summary, this one demonstrates an effective approach. Rather than repeat detail, or even attempt to summarize that detail, it instead provides a helpful introduction to the concepts covered at the subpage. I'd suggest a couple of minor formatting changes relating to the wikilinked bullet points: firstly, since they work well to link to specific parts of MOSNUM, the section should open with only a single "main" link to MOSNUM itself, and secondly, the wikilinked bullets would be better if relevant words/phrases became the link instead of the first word of each bullet. In other words,

Presenting unit names and symbols in a consistent manner.

instead of

Presenting unit names and symbols in a consistent manner.

I would support this proposal and see no reason not to implement it straight away. Perhaps this will become a general trend in shaping the main MoS page, or perhaps we will go further and adopt the ToC approach, but either way this proposal is an improvement over the duplication of detail between MoS and MOSNUM we have now. PL290 (talk) 11:25, 6 July 2010 (UTC)

I have taken on board the helpful comments made by other editors and following on from PL290's suggestion, have implemented it. I know that it is not perfect, but I think that there is general consensus regarding its structure. Moreover its structure is stable enough that tweeks are now best done in situ. Martinvl (talk) 12:07, 6 July 2010 (UTC)

Hyphens in adjectives of dates

I'm just doing a Good Article Review and not for the first time I have seen "18th-century this" and "20th-century that".

Taking WP:HYPHEN it is clear that these should not be so hyphenated:

"Values and units used as compound adjectives are hyphenated only where the unit is given as a whole word. Where hyphens are not used, values and units are always separated by a non-breaking space (& )."

Looking at WP:DATE the examples conform to this, but nothing explicit is said about why. I presume that we are all supposed to have the MOS off by heart, but it isn't so.

So can we please have in that section of WP:DATE an explicit statement on using non-breaking spaces not hyphens, referring back to WP:HYPHEN? Thanks. I don't see this needs much discussion, since it's not a change to the style, simply to make it easy to get from one recommendation to another (er, it is a wiki).

Best wishes Si Trew (talk) 13:11, 5 July 2010 (UTC)

"Century" is given as a whole word. That example is about unit symbols. ― A._di_M.^{3rd Dramaout} (formerly Army1987) 14:46, 5 July 2010 (UTC)

The forms "18th-century event" and "20th-century event" are correct, even if the Manual of Style does not discuss them specifically, and I have been intending to check articles systematically to hyphenate the unhyphenated versions, but I have been busy with other matters.

—Wavelength (talk) 16:04, 5 July 2010 (UTC)

Here are some style guides which hyphenate "18th-century" used an an attributive adjective.

http://www.guardian.co.uk/styleguide/h ("Hyphens should, however, be used to form short compound adjectives, eg two-tonne vessel, stand-up comedian, three-year deal, 19th-century artist, etc.")
http://www4.samford.edu/communication/stylemanual/h.html ("Compounds with century are hyphenated when they work as modifiers: ninth-century art, 11th-century religion")
http://stylemanual.ngs.org/intranet/styleman.nsf/Alpha+Summaries%5C-+H+-/$first/?OpenDocument ("Hyphenate when required by Webster's, after a prefix, or when the hyphen is necessary for sense.")
http://www.timesonline.co.uk/tol/tools_and_services/specials/style_guide/article986720.ece ("centuries the style is the 3rd century BC, the 9th century, the 18th century etc; and adjectivally with the hyphen, eg, 20th-century architecture")
http://www.reading.org/styleguide/hyphens.html ("Adjective–noun compounds: low-frequency words; 14th-century structures")
http://stylemanual.ngs.org/intranet/styleman.nsf/332ad98b4acada0685256651006748ce/f0d90cec94e539c78525668a006dacd0?OpenDocument ("Hyphenate as a compound adjective before a noun: 12th-century artist, tenth-century B.C. vase, late 18th-century house.")
http://www.simstylebook.com/hyphens.php ("Use a hyphen in a one-thought compound modifier placed before the noun it modifies. ... 18th-century design")

—Wavelength (talk) 16:25, 5 July 2010 (UTC)

This usage of the hyphen is covered in WP:HYPHEN in point 3, which states that one use of hyphens is "[t]o link related terms in compound adjectives and adverbs". As you point out, in terms like "18th-century art" 18th-century is used adjectivally, so therefore hyphenating it is correct. — Cheers, JackLee ^–talk– 18:36, 5 July 2010 (UTC)

Just to clarify, I believe the idea is that there's an 18th-century event but an event that occurred in the 18th century. "18th-century" is a compound adjective, "18th century" an abstract noun. Adrian J. Hunter^{(talk•contribs)} 12:55, 6 July 2010 (UTC)

Yes, and I hope that all editors understand the difference and are attentive to it.—Wavelength (talk) 14:53, 6 July 2010 (UTC)

I hope that Noetica does not mind my referring to some related information archived at User:Noetica/Archive4#Complications with ly, in a series of running subsections 3 and 4. My purpose is not to draw attention to Noetica, but to draw attention to what Noetica has said and the reasons given.—Wavelength (talk) 15:02, 6 July 2010 (UTC)

MoS on SOFT HYPHEN (SHY)

Should not the MoS (in WP:HYPHEN) describe when and where SOFT HYPHEN () is used, if at all? -DePiep (talk) 10:59, 8 July 2010 (UTC)

I wondered whether there was such a thing on WP. Thanks for pointing it out. Tony (talk) 17:03, 8 July 2010 (UTC)

Infobox Capitalization

WOuld it be wrong to capitolize 'Novel' , 'Screenplay' and 'Premiere' like in this infobox? [7]?ChaosMaster16 (talk) 16:26, 8 July 2010 (UTC)ChaosMaster16

No, those words should not be capitalized in that context, as there is no reason to. The only time the first letter of a word should be capitalized is when it is at the beginning of a sentence (or a Wikipedia section) or is a proper noun of some sort. — CIS ^(talk | stalk) 16:28, 8 July 2010 (UTC)

I would think of if as some type of heading though, sort of how you start a list (Name: First, Last).ChaosMaster16 (talk) 16:58, 8 July 2010 (UTC)ChaosMaster16

I don't think they should be capitalised. Tony (talk) 17:04, 8 July 2010 (UTC)

Agree with CIS, they shouldn't be capitalised in that context. WFC (talk) 17:14, 8 July 2010 (UTC)

Use of various synonyms for the same item in an article

Sometimes the subject of a Wikipedia article has different names. For example, the subject of the article Wilderness acquired diarrhea is also called "wilderness-acquired diarrhea" and "wilderness diarrhea". In the article, most of the time "wilderness acquired diarrhea" is used, but sometimes "wilderness-acquired diarrhea" and "wilderness diarrhea" is used.

Another example is the article Pythagorean theorem where most of the time "Pythagorean theorem" is used in the article but "Pythagoras' theorem" is also used in the article.

Is this sort of thing covered in the Internal consistency section of WP:MOS? It's not clear to me whether the guidance of having a consistent style includes the guidance of using in the article only the term in the title (aside from the opening sentence), instead of using various synonyms here and there in an article. --Bob K31416 (talk) 03:44, 22 June 2010 (UTC)

In your first example, wilderness and acquired should either be hyphenated, or not, but not both. Otherwise, I think it's fine to switch things up a bit. Since I write and edit articles related to state highways in the US, highway, roadway, road, route all get used in addition to the proper abbreviated name. Since they're called trunklines in Michigan, I mix that term in as well for variety. I see no problem with using alternate names once in a while, but when an alternate is only different based on a variation of punctuation, a consistent style should be used in the article. That's my $0.02. Imzadi 1979 → 04:22, 22 June 2010 (UTC)

Definitely a hyphen for the article title. This is an interesting issue that I don't think MoS should cover. Some repetition in prose is dysfunctional ("significant" three times in two paras), and some is functional, where the readers might ask ... "oh, do they mean the same thing or is it something different now". Switching from "highway" to "road" etc might be OK depending on the context, but I'd be careful of putting readers on the wrong scent, and of using an item that really carries a different and unwanted meaning. Lexical repetition in prose—one of M.A.K. Halliday's four elements of cohesion in language—is fascinating, actually. I deal with it all the time in my RL work of editing mainly scientific text. Tony (talk) 05:28, 22 June 2010 (UTC)

I agree with Imzadi and Tony. This is a case-by-case matter. Editors will just have to decide what level of consistency is necessary to make the meaning clear within the larger context of the article. For most articles, such as the one covering the Pythagorean/Pythagoras's theorem, the meaning will be clear enough to most readers, and the variation provides some welcome relief. With regard to your question, Bob, I believe that the passage on internal consistency here refers to style and formatting rather than to synonym choice. Darkfrog24 (talk) 17:06, 22 June 2010 (UTC)

On one hand, you don't want to forbid using "somebody" and "someone" in the same article. On the other hand, using non-exact synonyms just for the sake of not using the same word too often is not always a good idea because the read might pick up a semantic difference where none is intended. ― A._di_M.^{3nd Dramaout} (formerly Army1987) 10:54, 25 June 2010 (UTC)

Agree with all the above. It's difficult to write a definitive guideline for. In the case of completely different words (for instance "team", "squad" and "side"), it may be worth using a footnote on the first occurance, particularly if one of the words might not be commonly understood in another country. WFCforLife (talk) 11:02, 25 June 2010 (UTC)

Yes, elegant variation can be confusing: ok if that is a highway, how does that differ from a roadway? I tend to take this tack: We are here to make articles informative before we make them interesting. Ideally they should be both, but if they lose clarity just to "liven things up a bit". Like Tony1, I also edit and review a lot of science & tech stuff in real life, and it is just a no-no. A study by Xerox PARC in the early 80s (I think) on machine translation recommended that authors used a limited vocabulary to aid the process (so, for example, a pushbutton was always so, and not variously a button, switch, push control and so on). They found – and I don't have a reference right here for this – that not only did it make the machine translation better, but that it also made the English more comprehensible.

I note also that just from personal experience, other WIkipedias I am familiar with (French, Hungarian) use elegant variation a lot more, and it does make the task of translation harder if one does not realise that they are referring to the same thing. That applies just as much to a reader who is unfamiliar to a subject (and presumably many if not most readers coming to an encyclopaedia are doing so because they are exactly that). WHere there are local terms, these can be easily incorporated explicitly, but after doing so I think it is best to stick to one term, however boring that may be.

Just my opinion of course. Si Trew (talk) 10:45, 26 June 2010 (UTC)

Simon, that is a very interesting observation. Of course, it's hard to tell whether a style-nerd in Hungarian or French might come along and purse their lips about the use of "elegant variation" in their own language, or whether this brings to light a widely accepted practice in those languages. Some non-native clients have told me that English-language tutors tell them to try not to repeat words in a text and to use a thesaurus to make your language more varied. This advice does so much damage, and is why it's not uncommon to find a single whacky word in a non-native's text that has been shoved in almost at random from the thesaurus. It's a problem. Tony (talk) 11:09, 26 June 2010 (UTC)

(ec) I agree that clarity is of paramount importance, but there is a tradeoff. If an article is boring, fewer people will read it through. If people who were interested in the subject matter do not ultimately read it, the article isn't fulfilling its full potential. And if sticking to a deliberately narrow vocabulary prevents an article from doing what it's meant to do, the MoS itself becomes redundant. WFCforLife (talk) 11:13, 26 June 2010 (UTC)

That's why this has to be a case-by-case matter. Editors must use their judgment as to whether a given synonym would confuse the intended reader. Darkfrog24 (talk) 01:27, 27 June 2010 (UTC)

Perhaps it would be worthwhile to make a succinct addition to Internal consistency that would inform editors about the possible benefits and problems of using synonyms, rather than making a rule? One possibility would be a reworded version of what A. di M. wrote.

"On one hand, you don't want to forbid using "somebody" and "someone" in the same article. On the other hand, using non-exact synonyms just for the sake of not using the same word too often is not always a good idea because the read might pick up a semantic difference where none is intended."

This is just a possible starting point and the final version could be quite different, if editors here decide to make an addition. --Bob K31416 (talk) 14:29, 27 June 2010 (UTC)

It's a fantastic philosophical starting point, and there may be some value in pursuing it. But is it possible to come up with a non-prescriptive guideline that's neither redundant, nor pure instruction WP:CREEP? WFCforLife (talk) 18:37, 27 June 2010 (UTC)

Dunno, though something about Tony's point about not choosing words at random from a thesaurus – something that apparently even native speakers do – would be nice to have. ― A._di_M.^{3rd Dramaout} (formerly Army1987) 19:11, 27 June 2010 (UTC)

I agree with that, from the bottom of my full-sized aortic pump. WFCforLife (talk) 19:49, 27 June 2010 (UTC)

I don't think that's a good idea. Absolutely anything that we put in the MoS is going to be interpreted as a rule in practice by enough Wikipedians to cause a problem (such as edit wars) over it. Darkfrog24 (talk) 14:40, 28 June 2010 (UTC)

What edit wars could Do not pick words at random from a thesaurus cause? :-) ― A._di_M.^{3rd Dramaout} (formerly Army1987) 16:25, 28 June 2010 (UTC)

To be fair, we literally have edit wars over how we should dot our i's and cross our t's. I'm leaning towards adding something, but careful thought needs to be given to whether the benefits outweigh the possible drawbacks. WFCforLife (talk) 18:05, 28 June 2010 (UTC)

I see both DF's and A. di M.'s angles. It's a difficult and subtle issue. I wouldn't object to a brief addition along A. di M.'s lines, I suppose. If you want it to hit the nail for editors who need the advice: "It is usually helpful to readers if technical and subject-specific terms are used consistently consistent throughout an article. However, many English words are repetition-sensitive, such as "significant" and "develop", and close repetition is often best avoided. By contrast, "the" is not at all repetition-sensitive, although "this" can stick out if used repeatedly." It's just off the top of my head, and again, I'm not sure anything should be said in the first place. Unsure. Tony (talk) 17:22, 28 June 2010 (UTC)

A lot of it can be avoided by using pronouns. (Though even I irrationally choke on opening paragraphs with "He" or "She" or "It" referring to the article's subject.) Fetch me the can-opener and the vermicelli! Si Trew (talk) 19:08, 1 July 2010 (UTC)

I thought the first part of Tony's suggestion, which addressed the consistent use of terminology, would work with some rewrite. As for the second part, I don't think we should discuss how to use words such as "significant", "develop", "the", and "this", that aren't terminology. Here's a possible version that rewrites the first part of Tony's suggestion, and adds an example from a previous message of Si Trew.

"It is usually helpful to readers if terminology is used consistently throughout an article. For example, in an article about a device, it may be helpful to consistently call one of its parts a pushbutton, and not variously a button, switch, push control and so on."

--Bob K31416 (talk) 20:17, 1 July 2010 (UTC)

Repetition of one or more words does not need to be boring. There is variety in the combinations and permutations of words in an article. However, instead of focusing on variety for its own sake, we can choose words for their contexts, and let variety happen as a consequence of that.

—Wavelength (talk) 20:32, 1 July 2010 (UTC)

What about "Avoid arbitrarily switching between non-exact synonyms to refer to the same concept in the same article when doing so might lead the reader to assume a semantic distinction where none is intended" (or a better way to word this? (The "non-exact" serves to exclude cases such as someone vs somebody.) ― A._di_M.^{3rd Dramaout} (formerly Army1987) 23:25, 1 July 2010 (UTC)

It's not that I disagree as such. But I think we're getting a bit too technical here. How about this: "Editors should strive to make articles as interesting as possible. However, a reader's understanding must always be given the highest priority." WFCforLife (talk) 00:26, 2 July 2010 (UTC)

While that is true, I don't think it addresses the point of near-synonymy at all. Si Trew (talk) 07:39, 2 July 2010 (UTC)

That does sound rather technical, and perhaps instructional. Here's my stab:

"It may be better to use the same word twice than substitute it with another word that has the same, or nearly the same, meaning: doing so might indicate that the two words refer to different things when that is not intended".

But I like Bob's idea of including an example. I think though we should change "terminology" there to "terms"; terminology is the study of terms, not the terms themselves. I'm still not entirely happy with that, but it does remove the "technical" aspect of it, even to the extent of the word "synonym". Si Trew (talk) 07:39, 2 July 2010 (UTC)

See Wikipedia:Reference desk/Language: Zsa Zsa figure of speech.—Wavelength (talk) 04:31, 7 July 2010 (UTC)

Let us not follow the extreme degree of variation shown at Heads-up sports verbs.—Wavelength (talk) 16:14, 9 July 2010 (UTC)

Seems to encourage full naming of common currencies

"Generally, use the full name of a currency on its first appearance (52 Australian dollars); subsequent occurrences can use the currency sign (just $88)."

Surely we can do without the clutter of spelling out "United States dollars" on first occurrence—who does that? I'd correct it immediately if I saw it in an article. And what is wrong with "AU$88" first occurrence, then "$46" once it's established and unambiguous. What does the link do? It shows no conversion—certainly not a current one or a conversion related to both inflation and the conversion at the time of the context. Better not to go there unless it's some little-known currency (Mongolian razoos), don't you think? Sometimes I see "US$" linked again and again and again in an article. Why? Tony (talk) 08:55, 5 July 2010 (UTC)

Agreed. US$, £ and € should be exceptions at the very least and your "AU$88" solution works fine for me. If it's a more obscure currency surely all that is need is a link. Ben Mac Dui 09:03, 5 July 2010 (UTC)

I agree, but caution needs to be used. The € is the only completely unambiguous case that's big enough to be used unqualified, 100% of the time. £ was once commonly (erroneously but commonly nonetheless) used for the Italian Lira. A few countries have their own $. While most English speakers will recognise ¥ as the Japanese Yen, the Chinese Yuan uses it too. Common sense should obviously prevail, but unclear cases (an article in which two forms of dollar are used, an article on Second World War reparations, or an article on, say, North or South Korea) do need to be mindful of the danger of confusion. WFC (talk) 12:53, 5 July 2010 (UTC)

I've changed it accordingly, so that where a currency is widely known among English-speakers, there's no need to spell it out, or to link it. Another issue there: "In country-specific articles, use the currency of the country, together with approximate conversions to U.S. dollars, euros, pounds, or a combination of these: for example, Since 2001 the grant has been 10,000,000 Swedish kronor (approx. US$1.4M, €1.0M, or £800k as of August 2009)." Is this really followed in articles? For example, Australia uses AU$, but it would be silly to convert it to US$ at all, since the exchange rate is unstable from month to month, and cumbersome too. Shouldn't this advice be changed to "if it is helpful to the readers", or something like that?

Better advice for all currencies apart from euros and sterling might be to link on first occurrence to an external, continually updated list of currency conversion rates, don't you think? Or to put the external link in the appropriate section at the bottom. Tony (talk) 17:30, 8 July 2010 (UTC)

In the spirit of keeping the reader on the page, I'd favour putting it at the bottom. WFC (talk) 17:39, 8 July 2010 (UTC)

Alternatively (although I doubt you'll like this Tony), I'm sure it would be possible to develop a simple template to convert a specific currency to US$, € and £ (or only one of them if preferred). Taking the Danish Krone as an example, the template would look like this to an editor:

{{krone|1000}}

and display something like this to the reader:

kr 1000 (US $170.01, £112.19, €134.15)

If you only wanted euros, you could use the template like this: {{kr|1000|€}}, getting kr 1000 (€134.15).

The question is, how many articles need the current exchange rate? I mean, if something was kr 1,000,000 in July 2002, surely that's the desired exchange rate? WFC (talk) 19:03, 8 July 2010 (UTC)

Comment: I say we only ever need ONE benchmark currency conversion, and that should always be to the USD, if it is provided at all, and then ONLY on the first occurrence. The conversion rate used should be historic rate (i.e. the rate prevailing at the time of the event) to be as meaningful as possible. Exceptions would be to the €uro-zone currencies, lest we forget they still exist, which should be stated at their parities to the €uro. There really should be no need to benchmark the major reserve currencies such as the USD, GBP, EUR, JPY unless that benchmark was particularly relevant to the content of the article. Not all currencies need to be spelt out in longhand, or linked - maybe the Polish zloty, but certainly not the United States dollar or the Pound sterling. Of course, it's easier for the pegged currency such as the Hong Kong dollar. Stating more than one benchmark currency only contributes to clutter not helpful in understanding the article. Ohconfucius ^¡digame! 01:10, 9 July 2010 (UTC)

I understand the sentiment of only having one base currency, but not of mandating use of the USD. ~~Partly because, whilst being the most recognised, it's also the most ambiguous symbol. But~~ Primarily because which currency is most appropriate depends on numberous factors such as geography and date; there are situations where any of £/€/$ will clearly be the most relevant. WFC (talk) 01:22, 9 July 2010 (UTC)

Take your pick - the top 3 reserve currencies of the world are the US dollar, Pound Sterling, and the euro. I don't think it should get any more complex than that. Ohconfucius ^¡digame! 07:46, 9 July 2010 (UTC)

Stereotypes of White people

An editor has made some large changes (diff) at Stereotypes of white people which includes using caps "B" and "W" in "black" and "white" (examples: "development of Black identity" and "stereotypes of White people"). I'm pretty sure that lowercase is correct, but I will need something stronger than my opinion to convince the other editor. Is there a guideline on this issue? Johnuniq (talk) 11:10, 11 July 2010 (UTC)

Ordinal suffixes in "2nd", "2d", "3rd", "3d"

Someone has asked about the use of "d" alone, instead of "nd" and "rd", to indicate "second" and "third" respectively. Please see the discussion at Wikipedia:Reference desk/Language, (sub)section 6.7: Ordinal notation with superscript and -d.—Wavelength (talk) 03:23, 12 July 2010 (UTC)
[I am revising the heading of this section.—Wavelength (talk) 03:30, 12 July 2010 (UTC)]

Consecutive "end of sentence" marks?

I am nominating the List of Red Hot Chili Peppers band members for a featured list candidate, and one of the reviewers brought up an issue with consecutive end marks. The list states that "...[the guitarist returned] to the Chili Peppers in 1985 after growing tired of What Is This?." "What Is This?" is a proper noun that refers to a band the guitarist was briefly in. The reviewer just wants me to confirm that the Manual of Style is okay with these consecutive end marks. Thank you for your help! WereWolf (talk) 19:22, 5 July 2010 (UTC)

I'm going with no. Just as an accountant does not lose her way with numbers when she decides to follow a band around the country, the question mark does not lose its ability to end a sentence for being loyal noun-roadie to a group of words. Darkfrog24 (talk) 03:38, 7 July 2010 (UTC)

Yes, but for heaven's sake follow the MoS on the position of the dot, which DF failed to mention. So after the quotation marks: ?".

And your quote would be better as:

the guitarist returned "to the Chili Peppers in ..." (i.e., move the quotation marks rather than using square brackets and ellipsis points. Tony (talk) 03:44, 7 July 2010 (UTC)

Honestly, I don't understand what Darkfrog24 and Tony1 are trying to communicate (I think it may be a case of misunderstanding the question) -- no slight intended.

WereWolf is saying, the article currently says

Sherman was fired soon after, with Slovak returning to the Chili Peppers in 1985 after growing tired of What Is This?.

Where What Is This? is a proper noun. In such a case, I would think using both the "?" (as a part of the proper noun) and the "." (to end the sentence) is fine. Chickenmonkey 04:00, 7 July 2010 (UTC)

Ah, thank you Chickenmonkey! I was sort of confused with the other comments; although, I should have made the sentence and example clearer. Thank you again! WereWolf (talk) 16:42, 7 July 2010 (UTC)

You could also simply duck the whole issue by rewriting it like this:

Sherman was fired soon after, with Slovak having tired of What Is This? he returned to the Chili Peppers in 1985.

Roger (talk) 18:07, 7 July 2010 (UTC)

Except that this version needs a semicolon instead of a comma before "with", to avoid a comma splice. Art LaPella (talk) 19:10, 7 July 2010 (UTC)

I'll say no.

(1) The Wikipedia manual of style gives an example of a phrase inside a sentence that ends in a question mark—where the question mark also ends the sentence as follows:

Martha asked, "Are you coming?"

(2) Various comprehensive style guides also agree with this position, for example, the 15th edition of the Chicago Manual of Style.

(3) Double punctuation is almost never seen in text.

(4) In this case, the question mark serves a function for the noun, but also as terminal punctuation. If this use introduced confusion as to where the end of the sentence was, rewording—as opposed to double punctuation—would be in order.

Hope that helps. --Airborne84 (talk) 19:16, 7 July 2010 (UTC)

I think the situation still needs a bit of clarification; the example -- Martha asked, "Are you coming?" -- is in situations dealing with quoted material. The situation on List of Red Hot Chili Peppers band members is not dealing with quoted material; it is dealing with the rare instance of a proper noun containing punctuation (the band What Is This?). In the situation on List of Red Hot Chili Peppers band members, I wouldn't think the question mark is also serving as terminal punctuation; the sentence is not a question. In these rare instances, I believe the proper action is to treat the question mark as if it isn't there. The same would apply when ending a sentence with Yahoo! or Wham!.

I think it may be a good idea to reword the sentence, but I also think it is fine the way it is. I could be wrong, however. I'm, in no way, an expert on this. Chickenmonkey 19:48, 7 July 2010 (UTC)

I apologize for putting the quotation marks around the problem sentence. I though that would've make my issue easier to understand, but it just made it worse. I do agree with Chickenmonkey though. I think that the sentence is fine as it is, but one of the reviews on the featured list candidate just wanted me to make sure that the Manual of Style was alright with it... WereWolf (talk) 20:45, 7 July 2010 (UTC)

For once, Tony, I hadn't noticed. WereWolf, it's not the quotation marks themselves. I think what happened is that Tony thought that the quotation marks were also present in the article, in which case MoS standards would require British English punctuation. Here on the discussion space, though, you are free to use American English punctuation if you wish. Darkfrog24 (talk) 03:09, 8 July 2010 (UTC)

Subtleties aside, you would be hard pressed to find an example of doubled punctuation in modern, professionally typeset text. However, since there's no standard that specifically addresses this case in the WP MoS, you should be fine either way. --Airborne84 (talk) 20:56, 7 July 2010 (UTC)

In Anthony Kiedis' (lead singer of Red Hot Chili Peppers) autobiography, Scar Tissue, What Is This? is mentioned numerous times, even at the end of the sentences. He and his co-author, Larry Sloman, use the consecutive end marks, ? and ., when referring to the band. Should there be a standard on the MoS so an issue like this doesn't come up again? WereWolf (talk) 21:10, 7 July 2010 (UTC)

He might have used it, but I doubt he used it correctly. Sub-par punctuation has become distressingly common these days, side effect of the Internet. We should consult reputable style guides.

My own take is that no, the period should not be there. Just because the question mark is part of a proper noun doesn't mean that it stops being a question mark. Darkfrog24 (talk) 03:09, 8 July 2010 (UTC)

Darkfrog is exactly right. I know of no professional style guide nor American publisher's house style sheet that allows two terminal marks at the end of a sentence. There are some cases mid-sentence where a comma aids clarity after an enquoted or italicized question mark or exclamation point—and many style guides are silent on this issue—but at the end of a sentence there is a professional consensus that two terminal marks are ugly and unacceptable.—DCGeist (talk) 03:55, 8 July 2010 (UTC)

So.. I should remove the period in that sentence? WereWolf (talk) 04:14, 8 July 2010 (UTC)

For what it's worth, this book says:

When two punctuation marks are called for at the same location, only the stronger is retained. In this sense, a question mark or an exclamation point is "stronger" than a comma or a period.

NOT His latest book is Why Are We Here?.

YES His latest book is Why Are We Here?

Clarity, however, sometimes demands that this rule be waived; for example:

NOT Her best-selling books include Who Was That Man? Here We Go Again! and Don't Be Late.

YES Her best-selling books include Who Was That Man?, Here We Go Again!, and Don't Be Late.

So, it would seem that leaving the question mark and omitting the period is the way to go; however, for clarity, I would still believe using both would make more sense. Using only the question mark causes the two sentences to run together. With the example book title Why Are We Here?, it is italicized which serves to set it apart from the rest of the sentence. With What Is This?, a band name is not italicized which leaves the end of the sentence open to interpretation. This source leaves the subjective quality "clarity" in an ambiguous state.

The point is, I believe multiple punctuation situations, such as this, should be avoided as often as possible. That way, the decision won't have to be made. My suggestion would be to rephrase the sentence so that What Is This? does not end the sentence.

The bigger question is, should a section on "multiple punctuation marks" be added to the Manual of Style? If so, I think a better source would be needed than the one I've provided. Chickenmonkey 04:24, 8 July 2010 (UTC)

Well, in any case, I did remove the period from the sentence. Thanks again for everyone's help! WereWolf (talk) 16:40, 8 July 2010 (UTC)

Yes, I believe it should. I've added a section along these lines. As this is WP's house styleguide, we don't need a source, just consensus. PL290 (talk) 18:24, 8 July 2010 (UTC)

Looks good.—DCGeist (talk) 18:28, 8 July 2010 (UTC)

No objection from me. Seems to explain everything well enough. Chickenmonkey 20:50, 8 July 2010 (UTC)

I also agree. It looks great. WereWolf (talk) 17:45, 9 July 2010 (UTC)

While I agree that the addition is a good one and very clearly phrased, I disagree with the assertion that we do not need to look at style guides. We have a responsibility to provide Wikipedia editors and readers with correct English guidance. Darkfrog24 (talk) 20:26, 9 July 2010 (UTC)

Agreed. I think this topic merits an addition here in the Manual of Style. Key points that should be understood by editors (IMO):

1. The use of consecutive (terminal) punctuation marks is discouraged.

2. Rewording to avoid consecutive punctuation should be the preferred course of action.

3. If a second, consecutive punctuation mark is necessary to more clearly indicate the end of a sentence (or other use), and rewording will be difficult or unwieldy, it should be allowed as an exception on Wikipedia.

If there's agreement, the above should be added as concisely as possible, of course. --Airborne84 (talk) 00:51, 10 July 2010 (UTC)

I disagree with point 3. Consecutive terminal marks should simply be disallowed, as they are disallowed by every style guide and house style sheet of which I am aware. In the rare event that the location of the sentence break is unclear, remember, there are always two sentences available for rewording—the one that ends with the question mark/exclamation point/abbreviation dot and the sentence that follows. On this clear and simple point, there's no need for exceptions.—DCGeist (talk) 02:11, 10 July 2010 (UTC)

I'll be cautious about making statements about "most" or "all" style guides. I've reviewed over 30, but I didn't specifically look for this issue. The only modern one I have on hand right now is Chicago's 15th edition, which would seem to agree with DCGeist's statement in that "Neither a period (aside from an abbreviating period) nor a comma ever accompanies a question mark or an exclamation point. The latter two marks, being stronger, take precedence over the first two" (p. 271). I only caution against making uncompromising statements because the only rule for which there are no exceptions...is that there are some rules for which there are... --Airborne84 (talk) 03:01, 10 July 2010 (UTC)

My sentence in question climaxed with "of which I am aware". I trust you agree that I exercised the appropriate caution, yes?—DCGeist (talk) 03:57, 10 July 2010 (UTC)

Of course. I was speaking for myself only. My note about "uncompromising statements" is in reference to adding one to the MoS, not your statement about style guides. --Airborne84 (talk) 04:13, 10 July 2010 (UTC)

Just a reminder, the List of Red Hot Chili Peppers band members is still currently a featured list candidate, and it urgently needs a review. It's been almost three weeks since the nomination began, and any feedback towards the list is appreciated. Thank you again. WereWolf (talk) 18:27, 10 July 2010 (UTC)

My two cents: the version without the full stop ‘looks wrong’ to me. I would expect the sentence to continue when getting to that point, so seeing "The band then" immediately thereafter throws me off for a while. (Probably the footnote reference immediately after the question mark plays some part in that.) So I would keep the full stop. ― A._di_M.^{3rd Dramaout} (formerly Army1987) 11:11, 11 July 2010 (UTC)

I agree in principle. The purpose of punctuation is to help the reader digest the information. In the case of terminal punctuation, the purpose is to help the reader identify when the sentence is concluded. If terminal punctuation does not serve that purpose then a change is in order. Thus, my recommendation to provide exceptions to a WP:MoS policy that discourages (as opposed to disallows) the use of consecutive punctuation. However, the other editors' suggestions that the sentence should just be reworded are still relevant. --Airborne84 (talk) 14:54, 11 July 2010 (UTC)

As Darkfrog24 emphasizes, naturally our consensus should be guided by HQ sources and styleguides. (We don't need to cite a source is all I meant, but perhaps that wasn't being suggested anyway.) Convention is the key here. Once upon a time, I instinctively used consecutive terminal punctuation myself, on the grounds firstly that it is indeed "logical" to do so, and secondly that a sentence can otherwise appear "wrong" (such as in the very example we started with, where the Chili Peppers sentence thereby ends with a question mark despite not being a question). However, in my experience (and, it seems, that of others who refer above to styleguide take on the matter), published works on the whole simply do not do this. They avoid it, because consecutive terminal punctuation marks themselves appear "wrong". It seems to me that just as with many style questions (such as alphabetizing "Mc" and "Mac", or positioning terminal punctuation inside or outside quotation marks), there may be subtle, inherent conflicts and no absolute right and wrong answers. Faced with such conflicts, we must simply choose a convention. The wording I added reflects what is, as far as I know, the most widely used convention; I suggest we consider sticking with that, unless to do so produces serious discontent, and that discontent is supported by another convention widely used by HQ sources and styleguides. PL290 (talk) 11:52, 12 July 2010 (UTC)

Internal space and en-dash

In WP:DASH, subsection ‘Spacing’, it says

Disjunctive en dashes are unspaced, except when there is a space within either one or both of the items (the New York – Sydney flight; the New Zealand – South Africa grand final; June 3, 1888 – August 18, 1940, but June–August 1940). Exceptions are occasionally made where the item involves a spaced surname (Seifert–van Kampen theorem).

This ‘internal spaces’ rule is not usual English orthography. The so-called ‘exception’ (about surnames) is actually the convention. I suggest we change this rule. – Kaihsu (talk) 13:38, 12 July 2010 (UTC)

Might as well dive into this oft-discussed area.

I concur we should change the guideline, though not neccessarily for the same reasons.

As the numerous previous discussions have shown, differet style guides use different conventions, so the choice we make is more a house style than anything else, but I believe the current guideline is deficient on two fronts.

Firstly, it's inconsistent. Using a different spacing rule for dashes performing the exact same function (joining two independent elements) easily can confuse and provides weak guidence. There should be no difference in punctuation for "Chicago–Sydney flight" and "New York–Sydney flight". Either all disjunctive endashes should be spaced or none should be.

I also find that the rationale for the differing standard is based on an unfounded assumption. There is no less inherent potential for confusion in using "New York – Sydney flight" instead of "New York–Sydney flight". In fact, "New York to Sydney flight" is no more inherently clear than using a dash in the first place. Truthfully, the exact meaning should be clear from context. If it is not, then rewording to remove the dash is the best option. In any case, spacing the dash does not improve comprehensability enough to warrant a differing rule.

However, I will acknowledge that changing the rules for dates would be a ponderously difficult task, if only because of the sheer number of biographical articles that use the spaced dash for birth and death dates, that it is reasonable for dates to remain with spaced dashes. oknazevad (talk) 17:34, 12 July 2010 (UTC)

We have had many en dash discussions here. Most recently there was Wikipedia talk:Manual of Style/Archive 114#RfC: Disjunctive en dashes should be unspaced, where I proposed basically the rule suggested above. It was rejected because it can lead to confusion when the en dash is used in a range. I formulated a replacement proposal near the end of that discussion, but by that time everyone was tired and nobody commented on it. If we are going to have an en dash discussion, then I would like to introduce it again. The main difference between this proposal and the current MoS is that I ~~eliminate entirely the category of "disjunctive en dashes"~~ do not treat all disjunctive en dashes the same. [Improved wording; see my discussion with Art LaPella below. Ozob (talk) 00:14, 15 July 2010 (UTC)] I think the rules are much simpler that way:

To stand for to or through in ranges (pp. 211–19, 64–75%, the 1939–45 war). Ranges expressed using prepositions (from 450 to 500 people or between 450 and 500 people) should not use dashes (not from 450–500 people or between 450–500 people). Number ranges must be spelled out if they involve a negative value or might be misconstrued as a subtraction (−10 to 10, not −10–10). If either endpoint of the range contains a space, insert spaces on either side of the en dash (5 January 1919 – 21 January 1919, 10 W – 100 kW). Otherwise, do not insert spaces.
To stand for to, and, or versus between independent elements (male–female ratio, 4–3 win, Lincoln–Douglas debate, diode–transistor logic, Seifert–van Kampen theorem). An en dash is not used for a hyphenated name (Lennard-Jones potential, named after John Lennard-Jones) or an element that lacks lexical independence (the prefix Sino- in Sino-Japanese trade). In this role, en dashes are never spaced.
In lists, to separate distinct information within points—for example, in articles about music albums, en dashes are used between track titles and durations, and between musicians and their instruments. These en dashes are always spaced.
As a stylistic alternative to em dashes (see below).

Thoughts? Ozob (talk) 22:52, 14 July 2010 (UTC)

If you want to purge the word "disjunction", it also occurs in WP:HYPHEN and WP:SLASH, so be consistent. Art LaPella (talk) 23:23, 14 July 2010 (UTC)

The word is fine when appropriate, but I don't think it's useful here. Ozob (talk) 00:01, 15 July 2010 (UTC)

I don't understand. The word "disjunction" is used in HYPHEN and SLASH to refer to how it's used in DASH, so I think we need to adjust all three or none of them. Art LaPella (talk) 00:05, 15 July 2010 (UTC)

Perhaps I should expand on that, then. The word is accurate here, but too broad. There are different kinds of disjunction, and my proposal above distinguishes them. But in WP:HYPHEN and WP:SLASH there is no need to distinguish them, so the broad word "disjunction" is excellent. Ozob (talk) 00:10, 15 July 2010 (UTC)

Maybe part of the confusion is that I said "eliminate the category of disjunctive en dashes". That's an error; there are still disjunctive en dashes. But there's no need to treat them all the same. Ozob (talk) 00:14, 15 July 2010 (UTC)

OK. Art LaPella (talk) 00:23, 15 July 2010 (UTC)

My thoughts are: not this again. We have debated this at least twice, and the decision was not to change the guidance. "This ‘internal spaces’ rule is not usual English orthography." Where is the source of this assumption? Previous discussions have shown authority for this, and widespread sloppiness and inconsistency on the Internet and hard copy. Who wants to spend a whole month arguing in circles again? Tony (talk) 04:59, 15 July 2010 (UTC)

Titles of people (Mr, Mrs, Miss but most importantly for me M)

There doesn't seem to be any guidance on whether Mr, Mrs, Miss used as honorifics should:

Be used at all (I usually don't, but do if it's necessary to make clear it's a name)
Have a stop after "Mr" and "Mrs" (I don't tend to, for various reasons)

In particular, translating from French Wikipedia I often come across "M" ("monsieur"). In the context of thinking that it is necessary (so as not to mislead the reader, however briefly, into thinking the name is that of a place or whatnot), I would generally write "M Mitterand" or whatever; this however I can see migt be taken as being his initial. I don't really see a way out of that, except to write it in full.

In either case, should the title be anglicised? There is not always a direct equivalent, for example, with the -san honorific in Japanese, or the "Mme/Mlle" and "Frau/Fraulein" distinctions in French and German.

Is there some guidance somewhere that I have missed? Si Trew (talk) 12:54, 13 July 2010 (UTC)

There's WP:Manual of Style (biographies)#Subsequent uses of names:

After the initial mention of any name, the person should be referred to by surname only, without an honorific prefix such as "Mr", "Mrs", "Miss", or "Ms".

(Which surely applies to all articles, not just biographies. I wonder if there's there a better place this guidance can be located.) PL290 (talk) 13:44, 13 July 2010 (UTC)

Should be extended to say also don't use "Dr.", "Lt.", "President", "Queen", etc. --Trovatore (talk) 02:20, 14 July 2010 (UTC)

OK that covers the point of them being used at all (and I generally follow that).

WP:ABBR seems to allow both with or without stops. (It also puts the full form of "Mrs" as "Missus", wich is just laughable: if you ever tried to write that in full, at least in British English, you'd get some odd looks – it is slang for "wife".)

I've replaced "Missus" with "Mistress" in WP:ABBR. A. di M. (formerly Army1987) (talk) 14:14, 15 July 2010 (UTC)

The thing is, as usual, it is "hunt the guideline". Si Trew (talk) 07:38, 14 July 2010 (UTC)

A name that can be a surname as well as a given name (especially a given name for either gender) can be ambiguous without an honorific.

—Wavelength (talk) 14:29, 15 July 2010 (UTC)

If the first time you refer to a person you use the full name, this isn't a problem... A. di M. (formerly Army1987) (talk) 14:43, 15 July 2010 (UTC)

Could we have a guideline on pronunciation placement?

Please see this discussion section. Thank you.—RJH (talk) 19:28, 16 July 2010 (UTC)

Wikipedia:Requests for comment/Naming conventions for United States federal buildings

Opinions are needed at Wikipedia:Requests for comment/Naming conventions for United States federal buildings, which addresses the questions of whether "United States" should be spelled out or abbreviated in the titles of articles regarding United States federal buildings (MOS offers no clear guidance), and whether the titles of such articles should use Congressionally designated names. Cheers! bd2412 T 19:19, 17 July 2010 (UTC)

URL format in infobox

What is the preferred format for web site URLs in infoboxes? Shouldn't there be an MOS guideline?—Finell 00:55, 19 July 2010 (UTC)

There is another ongoing discussion on this, but I can't find it now. ---— Gadget850 (Ed) ^talk 12:04, 20 July 2010 (UTC)

It was discussed at Wikipedia_talk:Manual of Style (infoboxes)#URLs in infoboxes early last month, but the discussion did not go anywhere.—Finell 00:03, 21 July 2010 (UTC)

Typographical Quotation Marks Made Hard

The Manual of Style recommends typewriter quotation marks. They are sometimes dysfunctional and always ugly, but I concede that the Manual's reasons are valid.

The special character box for editing articles includes single and double typographic quotation marks! Removing them from the box would help enforce the recommended style. Sicherman (talk) 14:34, 20 July 2010 (UTC)

You can discuss at MediaWiki talk:Edittools. ---— Gadget850 (Ed) ^talk 00:08, 21 July 2010 (UTC)

Very long quotations

First of all, we should rarely use them. Granted. But much of the text of the Rosetta Stone is quoted in Rosetta Stone, now up for FAC; this seems a reasonable exception. It was both in block quotes and italicized; since it was four paragraphs (in an article of 73K), and fills a screen, the italics served as a useful reminder that one was still reading quoted text after the block indentation ceased to be visible. (link.

Is the absolute rule we have now

For quotations, use only quotation marks (for short quotations) or block quoting (for long ones), not italics

a little too brief?

I agree that single paragraph quotes should be in Roman; that proper formatting should be used; and that applying common sense would solve the problem. But FAC applies MOS literally, without the solvent of common sense. Septentrionalis PMAnderson 18:49, 21 July 2010 (UTC)

The MOS style you quote above is correct; see Purdue OWL for one guide. The quote marks used in the last link are used by pull quotes. I don't believe we have any guidance on the use of pull quotes. The template used is {{cquote}}, which does state "This template should not be used for block quotations in article text." ---— Gadget850 (Ed) ^talk 19:06, 21 July 2010 (UTC)

Cquote is deprecated for anything except pull quotes at MOS:QUOTE. I've updated Rosetta Stone to use {{quotation}}, which puts a border around. PL290 (talk) 19:15, 21 July 2010 (UTC)

As to italics, see WP:ITALICS. "It is normally incorrect to put quotations in italics. They should only be used if the material would otherwise call for italics, such as for emphasis or to indicate use of non-English words." ---— Gadget850 (Ed) ^talk 19:06, 21 July 2010 (UTC)

Wikipedia is not a reliable source; especially something that's quoting this page; but {{quotation}} should work. Adding it to the section now. Septentrionalis PMAnderson 19:25, 21 July 2010 (UTC)

He's not quoting it as a source, he's just pointing out our house style. oknazevad (talk) 22:01, 21 July 2010 (UTC)

And I've taken it out. Although it was only a suggestion, anything in MoS is liable to be taken as imperative. I don't think this has been discussed enough for any editor to make that kind of change with an edit summary "see talk", and let's all go hunt the talk. This is the only mention of using box style and to my mind is too big a recommendation to make without getting proper consensus: since there are no replies to the comment here, I don't think there is any consensus. Just taking BRD here. Si Trew (talk) 22:08, 21 July 2010 (UTC).

Then let us make clear that there is one solution, or the same literalists will be removing any markup but typewriter quotes and plain blocks. Septentrionalis PMAnderson 01:17, 22 July 2010 (UTC)

{{Quotation}} stands (unremarked on) in Rosetta Stone and its FAC, which would seem to suggest that it is one acceptable solution. I have edited to say no more. Septentrionalis PMAnderson 01:25, 22 July 2010 (UTC)

Where/when was it decided that {{Cquote}} is depreciated? -- PBS (talk) 23:32, 21 July 2010 (UTC)

A long time ago; I've sesn people quoting guidance against it at FAC for years. Probably the usual consensus of two. Septentrionalis PMAnderson 01:17, 22 July 2010 (UTC)

It would probably be good idea to lay out examples of the different boxes and let editors decide on which one to use. Also there should be a note to the effect that if a citation is placed within the templates strange things can happen which can force the falling back on the use of <blockquote>text</blockquote> -- —Preceding unsigned comment added by Philip Baird Shearer (talk • contribs)

Nothing wrong with that; included the caution in the tweak. If somebody disagrees, please explain actual disagreement. Septentrionalis PMAnderson 01:35, 22 July 2010 (UTC)

Shortcut

I have proposed a change to {{shortcut}} at Template talk:Shortcut#Positioning. If implemented, it will remove the need to place shortcuts above the header or to redirect to the header instead of the shortcut. ---— Gadget850 (Ed) ^talk 19:54, 22 July 2010 (UTC)

Specific statement with respect to double sentence spacing or double spacing after terminal punctuation is needed

It seems that the merits of single versus double sentence spacing, or spacing after terminal punctuation, have been discussed extensively and that the consensus is that single sentence spacing is recommended on Wikipedia, as seen at MOS:PUNCTSPACE, so please do not debate that here. However, double sentence spacing is still used extensively. Thus, the Manual of Style should probably address double sentence spacing, perhaps with a second sentence after the current policy, "In normal prose, never place a space before commas, semicolons, colons, or terminal punctuation, but place a space after them." It could resemble one of the following, which differ greatly in policy:

"Double sentence spacing, or the use of two spaces after terminal punctuation,

is also acceptable."
is also acceptable, but consistency should be maintained throughout the article."
is not recommended but is permissible."
is discouraged."
should be avoided."
is incorrect."

Without any such statement, as we presently lack, editors may be unclear as to what is acceptable and what is not. Adavis444 (talk) 16:37, 13 July 2010 (UTC)

This is covered by the last bullet at WP:MOS#Terminal punctuation. (It makes no difference from a style point of view, since browsers ignore extra spaces.) PL290 (talk) 17:24, 13 July 2010 (UTC)

That's true. Besides, trying to get this changed to something less ambiguous will lead to screams of protest. You can find some of the discussions in the archives. More information is available at Sentence spacing and Sentence spacing in language and style guides, which are articles, not policies. --Airborne84 (talk) 18:11, 13 July 2010 (UTC)

It's not so much that there's consensus that one is better but rather consensus that most Internet browsers will shrink it to one regardless of what's typed in so our rage is better channeled to other ares. Heh. Frankly, I like that the MoS explicitly gives editors their freedom here. Darkfrog24 (talk) 01:17, 14 July 2010 (UTC)

I agree, there should be no attempt at trying to dictate how editors type in edit boxes—especially since it makes little difference there. However, I will note that a couple of attempts at adding WP:MoS material that would prevent/discourage editors from forcing double spaces in the final markup have also been (rather irrationally) opposed here. I don't know if Adavis was referring to the final markup (what readers actually see), or if he/she just didn't know about the entry at WP:MOS#Terminal punctuation. --Airborne84 (talk) 01:38, 14 July 2010 (UTC)

Has anyone actually ever done something like First sentence.  Second sentence.  (if that's what you mean by "forcing double spaces in the final markup")? If not, telling people not to do that is pointless per WP:BEANS and hence a Bad Thing per WP:CREEP, IMO. A. di M. (formerly Army1987) (talk) 09:41, 16 July 2010 (UTC)

A fair argument. However, the statment about not forcing double spaces between sentences (in quotations only) was placed next to this one that was already in the MoS about "Allowable typographic changes" in quotations.

Spaces before punctuation such as periods and colons: these should be removed as alien to modern English-language publishing.

No one suggested that both statements be removed. Only the one about double-spacing after sentences. Both statements were equally valid. Why remove one and not the other? Why allow one and not the other? I thought it rather irrational. --Airborne84 (talk) 11:52, 16 July 2010 (UTC)

To obtain a space before a colon, you just need to type it, whereas to obtain several spaces after a full stop (or anywhere else) you need to take special measures which I think most WP editors aren't even aware of. A. di M. (formerly Army1987) (talk) 10:35, 17 July 2010 (UTC)

Also, I don't know what statement you are referring to. "Allowable changes" has never had a statement about multiple spaces: it was added with this revision and that statement already wasn't there. A. di M. (formerly Army1987) (talk) 12:32, 17 July 2010 (UTC)

←So is it going to be Option 3? That seems sensible to me: no article is rendered in breach, but the inevitability of moving on from "French" spacing is acknowledged. Just a gentle bit of steering. Tony (talk) 11:19, 17 July 2010 (UTC)

Remembering that one of the aims of the MoS is to encourage consistency, where reasonably possible, between articles across the encyclopedia, I would have thought it beneficial to leave matters of basic text formatting (such as paragraph spacing, line spacing, default font face and size, margins ...) in the hands of the rendering environment (i.e., the combination of the WikiMedia software and users' custom css stylesheets). The present discussion appears to me to fall into that category. I would suggest that if anything, our guideline ought to state that articles should not include code that alters the basic text formatting style of article text. PL290 (talk) 11:42, 17 July 2010 (UTC)

For A di M, I added the line above to complement the one about spaces before colons, etc. with this diff, [8]. Both conventions are alien to modern English-language publishing, so it seemed logical to add one if the other was already present. However, only one was promtly deleted, and discussion about why the other was left untouched was ignored when I opened a new thread on the talk page.

I eventually just let it go, however, since it was only a small addition anyway—it only affected quoted material, not everything on Wikipedia. I referred to it here only to make a point about the original purpose of this thread. If the objection to adding a restriction about forcing double spacing only in quoted material (as alien to English-language publishing) was argued so strenuously, imagine the protest against similar language that affects all of Wikipedia. See also this archive, where I tried repeatedly to drop the POV statement at the end of Terminal punctuation to a simple statement that "it's irrelevant" and others kept trying to add material that supported their point of view and style preference. We finally had to settle on a statement that is inaccurate, but was the least worst solution.

Here is what gathered in the 40+ language and style guides that I have reviewed on sentence spacing.

Most smaller style guides that don't have the space to discuss typography do not discuss sentence spacing, but offer examples of text that are single sentence spaced.
Not one comprehensive style guide that I have seen allows double sentence spacing in final or published work.
I have seen three style guides that leave room for writers to use double sentence spacing in draft work only, but note that final and published work is single sentence spaced.

Thus, I would support language that allows editors to use whatever sentence spacing style they prefer while typing in edit boxes (editors should be able to type the way they learned, if they desire). I would not support language that explicitly states it is permissible to generate the final markup of an article (what readers see) that is double sentence spaced.

Of course, I am only one editor here. But the key point that I made before and I would like to make again is that editors here need to put aside the style preferences that they were taught in school and agree on a style that makes Wikipedia better, is consistent with print and Web media, and accounts for modern style guides and experts on typography. There's no issue with making allowances for people's style preference, as long as it doesn't make the final product look different than what people read everywhere else. --Airborne84 (talk) 16:39, 17 July 2010 (UTC)

We finally had to settle on a statement that is inaccurate, but was the least worst solution. Well, right now all that the MoS says about double spaces is:

The number of spaces following the terminal punctuation of a sentence makes no difference on Wikipedia because web browsers condense any number of spaces to just one. (See Sentence spacing#Digital age.) However, editors may use any spacing style they are comfortable with in Wikipedia. Multiple spacing styles may coexist in the same article, and adding or removing a double space is sometimes used as a dummy edit.

How is that inaccurate? A. di M. (formerly Army1987) (talk) 18:43, 17 July 2010 (UTC)

I suppose this is not the right place to grumble about this, but I intensely dislike using spaces for dummy edits, because they are extremely difficult to see in a difference. It's fine to use them as long as someone provides a good WP:ES. Sadly, that seems to be the exception rather than the rule.

Grumble over. Si Trew (talk) 18:31, 21 July 2010 (UTC)

This seems completely pointless to me. No matter whether we separate our sentences with one space or two in the text we edit, they appear identical in the browser. The MOS should be about the appearance of the encyclopedia, not about editing conventions. So, I think it should remain silent on this issue. —David Eppstein (talk) 18:12, 17 July 2010 (UTC)

"[B]ecause web browsers condense any number of spaces to just one" is the inaccurate portion of the statement. Most web browsers do. All do not.

However, I'm not advocating a change because of this. Methods of viewing the web that might display HTML spacing as typed are likely used by a very small percentage of people. That's the reason why I agreed to the inaccuracy in the original statement. left as is, it doesn't really make much difference, regardless of accuracy.

The only change I'd be interested in seeing is one that aligns the Wikipedia MoS better with established and reliable general style guides. Since that is not likely to happen in the next decade or so because some people won't let go of their personal preferences, the status quo will do. --Airborne84 (talk) 22:01, 17 July 2010 (UTC)

Condensing any sequence of spaces, line feeds and tabs to a single space character except in <pre> tags is part of the HTML specification, so a browser which doesn't do that is broken, and might well have other problems. (Furthermore, I'd not be surprised to find out that MediaWiki doesn't actually deliver two spaces to the browser.) A. di M. (formerly Army1987) (talk) 11:04, 18 July 2010 (UTC)

Indeed, there are two spaces before the ( in the wikitext of the post above, but only one in the HTML. So I'm replacing "browsers" with "the MediaWiki software". A. di M. (formerly Army1987) (talk) 11:09, 18 July 2010 (UTC)

"The only change I'd be interested in seeing is one that aligns the Wikipedia MoS better with established and reliable general style guides" - Airborne84, could you be more specific about the change you seek, so that other may respond? PL290 (talk) 11:14, 18 July 2010 (UTC)

Sure. I'm not sure what's the best way to refer to the "final" or "published" version of a Wikipedia article (after an editor selects "save"). If it were "final version", for example, my recommendation would be something simple such as "Only a single space is used after terminal punctuation in the final version of articles." Other items could be added through editorial consensus, such as a statement clarifying that editors can use any spacing style while editing, or that most browsers render additional spaces in HTML as one, or the "dummy edit" note. I'd say they are extraneous and better addressed in the FAQ section of the MoS talk page and a link to the sentence spacing article, but I also have to be realistic given the past conversations here.

The long term solution would be to create a "Typography" section of the style guide and consolidate all the typographic topics currently scattered throughout the MoS into that section—including this topic. I brought this up once before, [9] but there apparently wasn't much interest. --Airborne84 (talk) 13:37, 18 July 2010 (UTC)

The MoS should not explicitly state a preference for either one or two spaces. Both styles are correct English, and the peculiarities of the html system make this potentially contentious issue nice and moot. Darkfrog24 (talk) 09:58, 20 July 2010 (UTC)

Ah yes. This is the type of opposition I was talking about. I've seen this statement that "two spaces are correct English" here before. Never has it been accompanied by a reliable supporting reference. In fact, it's never been accompanied by any kind of reference.

"Correct English" is a fleeting concept. There is no single authoritative body in English like the "Real Academia" for Spanish that makes prescriptive language rules. People use writing style guides, reference grammars, and dictionaries, which may vary widely in interpretation. On this typographical matter, they do not vary widely. At Wikipedia, we just collectively refuse to acknowledge this, even in light of the evidence. --Airborne84 (talk) 11:43, 20 July 2010 (UTC)

Never, Airborne? Well, just with what I can reach without getting up from my desk, the Bedford Handbook mentions that MLA style allows either one or two spaces and that APA style prefers one but acknowledges that some places allow or even prefer two.

What is correct English does change over time, but at any given time, certain things are correct and others are not. Maybe in twenty more years two spaces will be considered incorrect, but right now, they're correct. Wikipedia's rules should reflect correct English without pushing any separate agenda.

But maybe we do need something more recent than my old Bedford. How about [this]? "As a practical matter, there is nothing wrong with using two spaces after concluding punctuation marks unless an instructor or editor requests that you do otherwise." --MLA Darkfrog24 (talk) 23:27, 21 July 2010 (UTC)

Yes, that's true. If you look above in the thread, you'll see my statment that "I have seen three style guides that leave room for writers to use double sentence spacing in draft work only, but note that final and published work is single sentence spaced." You have found two of those three. If you're reading an APA "preference" for double spacing, that is for draft work only, not the final or published version. They also note that it's easier to read for reviewers of manuscripts (which are double [line] spaced), but do not reference any studies to support that. Please see Sentence spacing#Effects on readability and legibility for the irrelevancy of that statement by APA, which has also been widely criticized (see the Sentence spacing in language and style guides article notes). I cannot ignore the MLA statement, which is further clarified in the print version. It is what it is and it is included in the Sentence spacing in language and style guides article. It is, however, an outlier caveat for MLA users only—allowing room for both uses.

And you keep using the words "correct" and "incorrect". I've never stated that sentence spacing is "correct" and double sentence spacing is "incorrect". To use those terms when discussing the English language is rather irrelevant. I make no such claim. I simply maintain that the vast majority of style guides either indicate that users should use single sentence spacing for non-draft work, or they don't discuss it but provide writing examples that are single sentence spaced. The reliable sources that also state this are referenced in the various sentence spacing articles—so no need to take me at my word. To ignore this evidence and return to the statement that "double spacing is correct" does not help make Wikiedia better.

But ok, lets entertain your position that there could be a "correct" or "incorrect" use of sentence spacing. Since your and my opinions on this matter are irrelevant on Wikipedia (see Personal essay) and this is a matter of typography, let's see what typographers have to say on the matter. For example, Ilene Strisver states "Forget about tolerating differences of opinion: typographically speaking, typing two spaces before the start of a new sentence is absolutely, unequivocally wrong". In her new book, Type Rules, she calls double sentence spacing a "type crime". You can read the positions of other typographers in the above link. If you can find a dissenting opinon from a typographic expert, please add it to the Sentence spacing article. I didn't cherry-pick sources. I just found all the reliable ones that I could. The results were unequivocal. However, I'm sure that you are using the words "right now [double spaces] are correct" because you are backed up with more sources than the two you mentioned (which do not support that statement). Since I must have missed these sources in my research, I would be happy if you could provide these sources to me here or on my talk page so I can improve the article.

Finally, I'll return to my earlier position. I have asked editors here to put aside their personal style preferences and focus on making Wikipedia better. Aligning the MoS here so that it reflects the collective position of style guides is a step in that direction. Arguing against is to ignore the evidence and assume an illogical position. --Airborne84 (talk) 15:29, 24 July 2010 (UTC)

What all that comes down to, Airborne, is that you personally like single spacing more than double spacing. There's nothing wrong with that. However, you're going around saying that anyone who doesn't share your preferences—or who acknowledges that style guides permit two spaces—must be the victim of illogical thinking and that's not okay.

The terms "correct" and "incorrect" are absolutely relevant to any project that instructs its readers in how to write. The Manual of Style is explicitly such a project, and we have a responsibility to provide Wikipedia editors with clear instructions on how to use the English language correctly and effectively.

I've already provided you with more than once source on English sentence spacing. The MLA, we can assume, has already dug through many strident and non-strident typographic experts and it came to the conclusion that it should prefer one space and permit two. Darkfrog24 (talk) 19:23, 25 July 2010 (UTC)

...look at it this way. Adding a statement explicitly preferring one space to two 1. is irrelevant to the reader experience because of the way the browsers work the vast majority of the time and 2. will piss people off. We have no reason to add the statement. We have one good reason not to. We shouldn't add the statement. Darkfrog24 (talk) 19:30, 25 July 2010 (UTC)

A truly amazing response. In its aftermath, it would be a waste of time to continue this discussion—especially since this isn't the purpose of the talk page. By the way, I actually prefer the appearance of traditional spacing. You would actually have to read the sentence spacing article to find out what that is though. Cheers! --Airborne84 (talk) 22:17, 25 July 2010 (UTC)

My recollection of previous discussion goes like this:

We pointed out repeatedly that the number of spaces on the edit page doesn't matter because the browser doesn't print the extra space.
You answered that you were talking about people who code   , not simply two spaces, so the browser would print them.
Someone answered that they couldn't find a significant number of examples of that in Wikipedia, so there is no reason to prohibit something that almost never happens.
You recently asserted that some browsers do in fact print double spaces.
The above has been obscured by arguments about what correct English is, but if the above summary is correct, I don't see why it matters how many unprinted spaces we have. The relevant questions are: if you want to prohibit double  , can you show us a significant number of examples? And if browsers are the issue, can you name the browsers that display double spaces? I think those are the relevant questions. Otherwise, we're arguing about spaces that nobody but editors will ever see. Art LaPella (talk) 22:27, 20 July 2010 (UTC)

OK. Shelby Moore, chief developer of the "Cool Page" browser, stated in 2002 that "I even programmed Cool Page to handle the case of 2 spaces following a period so that the browser won't ignore the 2nd space...in 1986 I released WordUp, one the world's first wysiwyg word processors". I'm sure there are other "wysiwyg" (what you see is what you get) browsers out there too, but I'm not an expert in this area. That's two "browsers" anyway, assuming you don't object to a word processing program that allows the creation of a Web page showing all the HTML spaces being called a browser.

I have some more examples in this area from my research in writing the Sentence spacing article, but I think this is sufficient for now. So, there are browser(s) that render the spacing as typed in HTML for the user. Hope that helps. --Airborne84 (talk) 02:07, 21 July 2010 (UTC)

I couldn't verify that. CoolPage makes this Web page designer, but that isn't a browser (Wikipedia has its own Web page design, but each browser reads it a little differently.) Do they also make a browser, and does anyone still use it? Same for WordUp; creating a Web page isn't the issue because Wikipedia creates it with one or two spaces after the period, but any browser I've tried condenses them into one. This WordUp looks like a blog, so do they make a browser? In summary, you have named some software but I didn't find any browsers that show double spaces after a period, so could you provide a link? Art LaPella (talk) 03:55, 21 July 2010 (UTC)

Sorry, I should have included this link in the first place. [10] Moore refers to the "browser" that he programmed and discusses how people would view the extra spacing on Web pages. I don't know how many people use it, but it's an example that it's not only possible, but has been used in the last decade. Again, I'm not an expert on this, but this page and this article list quite a few methods of viewing the Web besides Internet Explorer, Firefox, Opera, and Safari. A few aren't very relevant (e.g. made for blind people), but it is useful in showing that there are a lot of different browsers out there. That in itself is not meaningful, but Moore states on this page, "All web browsers use their own methods of rendering web pages," and "Pages (made with any editor) do not display exactly alike in all browsers." I also remember some threads that supported this as I was sorting through some very technical (read: above my head) archived Web discussions while researching for the Sentence spacing and Sentence spacing in the digital age articles. I hope this helps. I have more information buried in my notes, but I think the above is sufficient to show that the blanket statement, "web browsers condense any number of spaces to just one," is inaccurate. --Airborne84 (talk) 04:52, 21 July 2010 (UTC)

You refer to this: "I even programmed Cool Page to handle the case of 2 spaces following a period so that the browser won't ignore the 2nd space." Cool Page and the browser are two different things in that sentence, not synonyms. Yes, there are many different browsers and they don't display alike, but do they show two spaces after a period? I'm not an expert either compared to Wikipedia:Village pump (technical)#Double space after a period, so I asked there. Art LaPella (talk) 05:54, 21 July 2010 (UTC)

All right. I think that even if you interpret Moore as referring to Cool Page and "browser" as two different things, that just supports the statement more. That would mean that other browsers that viewed a Web page created on Cool Page would display the extra space. It works either way. Good idea about posting it on Village Pump though. Let's see what they say there. --Airborne84 (talk) 12:36, 21 July 2010 (UTC

1) The requirement of replacing several spaces with one is in the HTML standards, so a browser not doing that would be broken and likely to have more serious problems we can't cater; 2) MediaWiki converts double spaces in the wikitext to single spaces in the rendered HTML, so even such a browser would "see" one space. (My post of 11:04, 18 July 2010, above, has two spaces after the first full stop, but try seeing the HTML page source...) A. di M. (formerly Army1987) (talk) 13:45, 21 July 2010 (UTC)

And 3) yes, Moore does "mean that other browsers that viewed a Web page created on Cool Page would display the extra space." But only created on Cool Page, not on Wikipedia. Art LaPella (talk) 14:01, 21 July 2010 (UTC)

Fair enough. I'm just responding to requests about this. I could be wrong, and very well may be. My above comment still stands -- even if that was the case, I let it go months ago because anyone that would fall under that theoretical situation would be in a very small minority anyway. And I'll finish with the note that I didn't start this thread... There is interest in clarifying the WP:MoS, regardless of HTML's characteristics. However, I don't know that the interest is sufficient. In lieu of aligning the MoS to reflect major style guides, the status quo will do. Cheers! --Airborne84 (talk) 18:01, 21 July 2010 (UTC)

Adavis444's adjustments seem reasonable. Any changes that continue to introduce the under-represented topic of typography to the MoS are good ones IMO. I'd prefer a comprehensive section on typography (some major style guides dedicate an entire chapter to this topic), but at the present time, this seems a step in the right direction. --Airborne84 (talk) 02:45, 25 July 2010 (UTC)

Square brackets and parentheses

I think it makes sense to use square brackets in quotation when replacing or inserting text (as in "[Principal Skinner] already told me that") but to use round brackets when making a clarification (as in "He (Principal Skinner) already told me that"), but the article currently recommends square brackets even for clarifications (as in "He [Principal Skinner] already told me that". I think round brackets make more sense in this second case, the case of clarifications. Can we have this changed? Gregcaletta (talk) 09:50, 21 July 2010 (UTC)

I disagree - we have three types of brackets available - square, round and curly. If we start using round brackets as described above, we loose track of whether the text "Principal Skinner" was part of the original text or a clarification added by the author. Martinvl (talk) 11:04, 21 July 2010 (UTC)

Fair enough. Gregcaletta (talk) 11:37, 21 July 2010 (UTC)

I agree. Parentheses are a very common element in text, whereas brackets are not. I checked a few online style guides and all use brackets to indicate material that is not part of the original quote for any reason. ---— Gadget850 (Ed) ^talk 11:48, 21 July 2010 (UTC)

Using both is not our editor's invention; it is one way to indicate extremely complex modifications of text (for example, indicating the changes from initial to final draft of some historic document). If clearly indicated beforehand, this is harmless; but it falls under WP:IAR. But I agree round parens should not be used in treating normal text; they invite misunderstanding. Septentrionalis PMAnderson 18:31, 21 July 2010 (UTC)

Just my personal POV, square brackets should be used for any excisison or clarification in quoted text, not round ones. And they should be used nowhere else. I agree it would be confusing otherwise. The only problem arises when the quoted text itself uses square brackets, but that I imagine is quite rare, and editors have then to use judgment in how to deal with that. Si Trew (talk) 18:37, 21 July 2010 (UTC)

I agree with Si Trew. Tony (talk) 00:17, 22 July 2010 (UTC)

Me too. In the real world, the convention is that any words or characters that are changed or added to a direct quotation are surrounded by square brackets. Any other means to designate alterations in a quotation would be ambiguous. Other explanatory information about a quotation or alterations to it may be placed in parenthesis immediately before or after the quotation or after the citation. For example, if all or some square brackets were part of the quotation itself, that should be explained. Another common explanation in parentheses, outside the quotation, is (emphasis added).—Finell 15:12, 23 July 2010 (UTC)

Request for comment: Use of italics in article names

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

Please note that the discussion has now been moved here.

Currently articles titles are not supposed to be formatted to include italics except under the ambiguously termed "special cases". Should each specific WikiProject decide how to format article titles, or should there be one set guideline that is consistently applied throughout Wikipedia? Ω phois 00:03, 24 July 2010 (UTC)

I treat the MoS as gospel if doing so makes sense and (in my opinion) improves the encyclopaedia. By contrast, I wilfully, publicly ignore it where I think the MoS is hindering or harming the project in that instance. When it comes to article names I think the justification for ignoring has to be absolutely compelling. I'm sure there are cases where italics are necessary, and that's what the MoS is there for. If we leave the decision entirely down to editor discretion, where do we draw the line? Bold? Colour? Size? The whole lot? --WFC-- 00:30, 24 July 2010 (UTC)
- My main concern is that the use of italics is not consistently applied. For example, the comics project used a consensus of three editors to establish the use of italics for comic article names (and even this is not consistently applied within the project). However, other media (such as movies, television shows, books, etc) do not use italics in the title. Why should comics specifically be italicized, while films are not? This creates a large inconsistency across Wikipedia that I think should be removed. The use of italics should be all or nothing, IMO. Ω phois 00:36, 24 July 2010 (UTC)
It has to be encyclopedia-wide to avoid inter-project conflicts over something that is rather trivial. Titoxd^{(?!? - cool stuff)} 00:53, 24 July 2010 (UTC)
- I know, that's why I brought it up here. Ω phois 01:06, 24 July 2010 (UTC)
Let's set out the problem properly! Currently the guideline says:

It is technically possible to display formatting in titles using DISPLAYTITLE. A template, {{italic title}}, exists to display the title in italics. This should be used only in special cases – currently its only common use is for academic journals, taxonomic genera and species.

This list of exceptions apparently emerged from this debate on a template talk page, where strong pro-italic support for taxonomic genera and species is clear, but there is no consensus, and very little mention, of either academic journals or any other form of copyrightable works such as books, albums, films, paintings, newspapers etc, that are normally italicised in text. To me it is obvious that while the taxonomic genera and species, which have foreign names & evidently a strong convention of italicisation in scientific writing, are one case, the copyrightable works equally form a group that should be treated consistently, and either all italicised in article titles, or none. I strongly favour italicising none of them in article titles. The "academic journals" should be removed from the current guideline text. Johnbod (talk) 01:02, 24 July 2010 (UTC)

Comics were also added to that list today by User:Parrot of Doom. Ω phois 01:09, 24 July 2010 (UTC)

All terms normally italicized in running text should be italicized in article titles, as well. That is the most consistent and rational approach.—DCGeist (talk) 01:07, 24 July 2010 (UTC)

To be honest, as long as these terms are italicized in the body (where readers' attention is focused), I don't care too much if the titles are as well. However, if we do decide to use {{italictitle}}, it should be implemented in all articles where such a measure is necessary, rather than on a WikiProject basis. Dabomb87 (talk) 01:15, 24 July 2010 (UTC)

I agree with DCGeist, let's try to be consistent. These article titles are already italicised in the WP:FA and WP:GA listings anyway. What's the argument against consistency? Malleus Fatuorum 01:43, 24 July 2010 (UTC)

That's a good point. Personally, I would be fine with that just as long as it is applied to all appropriate articles. Ω phois 01:47, 24 July 2010 (UTC)

Then let's apply it to all appropriate articles, instead of complaining that it's not. Malleus Fatuorum 01:52, 24 July 2010 (UTC)

A consensus is needed before applying something this big. Ω phois 01:54, 24 July 2010 (UTC)

It's not big at all, it's trivial. There's no wiki-wide consistency in the way that articles are cited, for instance, or the way that dates are presented, or in many other things. Why is this particular mole hill so important? Malleus Fatuorum 03:12, 24 July 2010 (UTC)

It might be trivial, but it would probably require renaming tens of thousands of articles if all are italicised, or probably a few hundred if none are. Only 2/6 of a random sample from Category:Biochemistry journals actually had italicised titles. To me it just looks silly to italicize article titles on paintings, novels, newspapers and films. This is very rarely done in book or article titles in the real world, even when they are italicised in text. Johnbod (talk) 03:48, 24 July 2010 (UTC)

It would be a great task, and hopefully a bot would be able to do it. If not, I would understand why some would object to it. But even in that case, I hope that they, like you Johnbod, would agree that it should be consistently used (either all italicized, or none at all). Ω phois 03:55, 24 July 2010 (UTC)

It needn't be a big task - we could add it to the relevant templates (film, novel, comic book title, etc. - it already is for the last one) and this would automatically format the relevant articles. Adding them in by hand is always going to result in inconsistencies (even with a robot doing a lot of the grunt work). (Emperor (talk) 01:08, 25 July 2010 (UTC))

I would also like to point out that articles such as short stories or episodes are formatted in an article with quotes but not in the article title itself. Should this also be considered, or combined with the italics argument? Ω phois 01:59, 24 July 2010 (UTC)

Many aspects of MoS are not a big deal but they are minor adjustments that can greatly improve readability and understanding depending on the instance. Italics would be nice for ship names. I agree the titles should mirror how the subject is resented in the text. Does the italic template work or do the italic marks work for disambiguation pages (Tittle (whatever))? edit: er... pages that have a disambiguation.Cptnono (talk) 03:19, 24 July 2010 (UTC)

That's a subtley different question. The underlying issue here is the distinction between how an article title is stored in wikipedia'a database and how it is displayed. Malleus Fatuorum 03:16, 24 July 2010 (UTC)

I don't think it would be needed for a disambiguation page, since a single name or phrase can have different meanings that use different formatting. Ω phois 03:24, 24 July 2010 (UTC)

Oh, I think I misunderstood what you were asking. Anyways, yes, a specific part of a title can be italicized. See Eagle (comic). Ω phois 03:31, 24 July 2010 (UTC)

Sweet. Sorry for not being clear enough by the way.Cptnono (talk) 03:35, 24 July 2010 (UTC)

I'd like to take away italization (sp?) from the projects who have it now, but barring that, I'd like to let individual projects decide. - Peregrine Fisher (talk) 03:58, 24 July 2010 (UTC)

But that can create conflict. Think of articles that fit multiple projects, such as comic-based films. If the comic project accepts italics and starts wide implementation, but the film project disagrees, then who should have priority? Ω phois 04:01, 24 July 2010 (UTC)

Comment As I see it, we have three options:

Refrain from using any italic article titles, on grounds of absolute consistency;
Avoid their use except where successfully argued for by an editor or editors (and record the justification for each exception in the history of the relevant guideline);
Encourage their use wherever Wikipedia would italicize the title in normal article text.

I don't think we should allow our judgement to be swayed by suggestions that it would be a big task to update existing articles. There are plenty of willing hands, and much potential to automate using scripts and bots. The matter is one of style. My own personal choice would be option 3. PL290 (talk) 06:46, 24 July 2010 (UTC)

There are several other choices. For example, the biological species etc can be treated separately from the copyrightable works - I think they should be. Titles that would be in italics because they are foreign terms (which is why the species are) might also all be italicised. But we should, I think, be consistent within these large groups. Johnbod (talk) 16:46, 24 July 2010 (UTC)

I agree entirely. Change the guideline and the articles will follow. It is only a question of how long it will take, and as far as I know, we're in no hurry. Darkfrog24 (talk) 13:01, 24 July 2010 (UTC)

A Comment and a Question (equally uneducated):

The point of using italics in the middle of prose indicates that these words are not part of the flow but The Name of Something That Has Already Been Created. At the top of the page, what's the point?! The words are sitting there on their own. The use of capitals differentiates between List of words in English and A List of Words in English (book).
In the font used by WP, are the italics actually italics or just slopey letters?

Well, that's quite enough from me almost-instinct 09:44, 24 July 2010 (UTC)

Re. point 1, that's an interesting point. And a related point is, if we align with what's done in running prose, would we also want to see quotation marks for shorter works? ~~That would presumably necessitate a lot of redirects from unquoted titles! But it's not unthinkable.~~ EDIT: presumably not, actually, since this is just about rendering! Remember too that we would use such renderings in lists, not just in running prose, so there's more to it than simply making a distinction from surrounding text. Re. point 2, see, for example, Macbeth (although I imagine either is possible using suitable css, so that shouldn't be considered an issue. Note, incidentally, that Macbeth, like many single-word titles, does not enable us to differentiate by use of capitals.) PL290 (talk) 10:38, 24 July 2010 (UTC)

The use of quotation marks would be interesting: for consistency would we have to have

High Windows (the collection of poetry)
"High Windows" (the poem)
High windows (a redirect to an article on Velux-style windows)?

Personally, I think this shows that this could be the thin end of an unnecessary wedge almost-instinct 11:20, 24 July 2010 (UTC)

My issue is that italicizing comics is one edge of a style guide, but there are many that don't use italics for books and similar works. Others use underlines, others even use quotes. If we're to apply italics, we are essentially mandating one style over another, which we've tried not to do in virtually every other aspect of Wikipedia. Secondly, most applications of italics I've been seeing are hidden away in templates, violating the WYSIWYG principle we should be adhering to for usability and ease of editing purposes. Unless this could be consistently applied in a top-level way, it just opens up more headaches. Leave all the styling to the lead and body. Der Wohltemperierte Fuchs^(talk) 13:00, 24 July 2010 (UTC)

My preference is for no italics in article titles (with the possible exception of taxonomic names where it seems a strong consensus exists for italicization and it seems to be consistently applied). It simply creates another unnecessary area of confusion. Removing {{italic title}} from the film, comic, album, etc. articles currently using it would probably not be a large task, whereas applying it to all articles of those types would be a rather monumental task. Another point of consideration is this: Titles are only italicized within running text, to distinguish the title of a work from the words around it. Italics are generally not used on the work itself, for example on the cover of a book or album or on a film poster. Similarly they are not necessary in article titles. Remember also that the text at the top of a Wikipedia page is the title of the Wikipedia article, not the title of the work it discusses. --IllaZilla (talk) 14:40, 24 July 2010 (UTC)

Reminder: Please remember that the main question being asked here is if one guideline should be consistently applied, or the decision left up to WikiProjects. Please try to include this in your responses. Ω phois 15:07, 24 July 2010 (UTC)

The trouble is the guideline is itself not really consistent. Do you mean the version before comics were added, or after? Johnbod (talk) 16:46, 24 July 2010 (UTC)

I am referring to the use of italics in ALL article titles. Ω phois 16:51, 24 July 2010 (UTC)

I concur with the points raised about the true purpose of italicizing titles of long-form creative works in running prose; they set them apart from regular text to emphasize the uniqueness of the title. However, those italics are a styling convention, not an inherent property of the title. In other words, the title isn't always written with italics. Underlining is done instead when handwritten, and used to be common for typewriters. Some place titles of long-form works in quotes. (Though, frankly, that grates on me.) There's no compelling reason, in my mind, to italicize the title of a Wikipedia article on a creative work, as it isn't in the middle of running text that can become blended together. Tables and lists are a bit fuzzier, as there is still a need to set off the text to certain extent, so there's no real harm about including italics there.

On the other hand, taxonomical names, by strong convention of them being "foreign-language" terms (though most are made up), are inherrently italicized, and should be italicized in titles.

That said, I somewhat see why the Comics Wikiproject may have decided to use italics; the number of comic books, particularly long-running, ongoing superhero series, that simply use the (code)name of the hero as the title of the series. In such cases, italics may be the only thing that prevents confusion. Still, consistency with the rest of the encyclopedia should be maintained. As I don't think the titles of articles on creative works should be italicized, I believe the practice by the Comics Wikiproject should end. oknazevad (talk) 15:17, 24 July 2010 (UTC)

Comment. After having looked at several paper encyclopedias and dictionaries (including Britannica, New World, Collier's, The Grove Dictionary of Opera, The Film Encyclopedia, and others) it appears that the format used in published encyclopedias/dictionaries never uses italicized titles for its atricles/entries. They likewise do not underline titles or place them in quotes. The titles of artistic works, be they music, literature, plays, films, paintings, comics etc. are not ilalicized. Species and genus names are also not italicized in the heading, nor are any Latin or other foreign language words. Other commonly italicized words, such as court cases, are also not italicized in headings. This seems to be a universally applied stylistic format for encyclopedias and dictionaries. I agree that consistancy across the encyclopedia is the best policy. Inevitably the inconsistant application of italicized titles, both in the rules and in reality (people forgetting to italicize the right articles or italicizing the wrong ones), will result in time waisting clean up for everyone and the obligatory edit wars. The best option would be to simply remove the option to have an italicized title. It saves on having to clean up messes, mediate fights, and creates consistancy here and with other well established encyclopedias.4meter4 (talk) 15:25, 24 July 2010 (UTC)

Further comment. Specialist science encyclopedias do tend to use other formats, but not consistantly. For example, Concise encyclopedia biology By Thomas Scott gives the English name of the organism in bold followed by the species and genus name in itallics (example: Aardwolf, Proteles cristata). A counter example would be all of the Audubon Society publication which have their titles on two lines like this:

Aardwolf
(Proteles cristata)

It appears that there are a variety methods used in science publications. However, since wikipedia is not solely concerned with science, I suggest we adopt the no italicized format used by the more general Encyclopedias.4meter4 (talk) 16:08, 24 July 2010 (UTC)

In response to Ophois, per my above comment my preference is for one guideline, worded clearly in the MoS and consistently applied. Individual WikiProjects' style guidelines may clarify and complement the MoS, but cannot override or supercede it. --IllaZilla (talk) 15:39, 24 July 2010 (UTC)
- Agreed with Illa. Further balkanization of this issue will not help. Der Wohltemperierte Fuchs^(talk) 15:53, 24 July 2010 (UTC)

If it's italicized in the main text, then the title should be italicized as well. Simple. As for academic journals, we're updating them over time (most non-itacized entries are old articles). New ones are almost always italicized. Headbomb {talk / contribs / physics / books} 16:10, 24 July 2010 (UTC)

What 4meter4 said. Well, without the little typos. (edit conflict)
- Having italics for our heading entries is/would be unique among reference works, AIUI. I know we're already unique (or were, uh, mostly) by being an electronic encyclopedia, or by building our work from input of everybody, but we should follow some common conventions of encyclopedias to keep it as accessible as possible, and this is one place where conformance makes sense.
- If we italicize American Pie in the title of the film's article "for consistency", then we have to add quotation marks to the title of the article "American Pie" about the song. Italics for the American Pie album, nothing for the American Pie film series. The ugliness of quotes will outweigh the gratification of seeing Escherichia coli neatly italicized at the top of articles.
- Besides which, it will be complicated, messy, and people will get it wrong by mistake, and some will see it as a clever way to vandalize. We'll spend more time fixing things, and we do more than enough of that already.
- Now we have the "consistency" question, because those wacky Tree of Life people like their genera and species in italics, and have settled in to their somewhat recent conversion to italicized titles. I understand and respect their view (although I think they didn't all agree), because to most of them, genera are just always italicized. However, I think the consistency argument is important, and the article title doesn't need italicizing to tell you it's a spider, because it's not a spider, it's an encyclopedia article. Inside the article, which is about a spider, then, yes, the species name definitely ought to be in italics. But the title of the article labelling the article doesn't need italics any more than the title of a book labelling the book (on the front cover, the spine, or on the title page) needs to tell you it's a book. Mentions of the book title, or article title, or Latin-style genus elsewhere should get italicized.
- I'm not involved in any WikiProjects, so maybe I'm blind to some important issues, but I don't understand the weight Wikipedians place on projects. There's often a kind of hushed tone when we talk about the military history people, or the film project. I don't see why it's appropriate for such projects to decide what colors data tables should be, or that italics are good (mandatory?) for comics, while the English literature people must do without. Add to that the problem of cross-project articles, and I think we're just developing new areas where we can argue. Let the WikiProjects do what they do best, develop content and templates to improve the addition and display of that content, and establish guidelines for what info should or should not be in "their" articles.

No italics in titles, Wikipedia wide. — JohnFromPinckney (talk) 16:18, 24 July 2010 (UTC)

I think that wikipedia article titles do not need to be italicized or have quotes impelmented in them. If it were to be put into effect, then there would have to be a large amount of editing to conform to this rule change to the affected pages, and it wouldn't be necessary. There are larger concerns than changing the title format, and making a rule to do that all over wikipedia would be an inconvenient inflation of that concern. I've been very used to wikipedia articles not having italics or quotes put in them, and consistency for wikipedia article titles not having format modifications would be something that I support. Backtable _{Speak to me}^{concerning my deeds.} 19:43, 24 July 2010 (UTC)

I think that there is a very significant difference between rendering an article title in italics and enclosing it in quotation marks, in that there is no italic mark key on your keyboard, but there is a quotation mark key. I don't much care whether article titles are in italics or not; my view is quite simply that for consistency if they're italicised (i.e., not wrapped up in any padding characters like quotation marks) in an article, then they ought to be italicised in the article title. I am supremely indifferent to what printed encyclopedias may or may not do, as the printed page imposes different contraints than does a web page. I will point out, however, that some dictionaries – Collins is one example – do italicise entries for certain foreign words such as en suite. In any event, I doubt that the Tree of Life folks will be persuaded to give up the italicisation of their article titles no matter what is said here, so why not go with the flow, in the interest of consistency? Malleus Fatuorum 20:25, 24 July 2010 (UTC)

I hardly consider the relatively small group of editors of the "Tree of Life" persuasion a flow. More like a small drip out of the faucet that needs a plumber here at MOS to stop the problem. If we implement policy here they will have to comply or risk getting blocked by admins. WikiProjects do not have the authority to ignore or change policy. On the counter side, I can tell you that the music/theatre/and literature projects will all kick up a major fuss if we try and implement italicized articles. Most of the projects in those areas of interest have already decided to not use italics for the very reasons I gave above.4meter4 (talk) 20:48, 24 July 2010 (UTC)

Um, the MoS also has no authority to decide policy. In fact the MoS itself is only a guideline. Consensus at the MoS is every bit as much a limited consensus as that from a WikiProject. If you want to get a policy you need to go to the Village Pump. --Trovatore (talk) 21:24, 24 July 2010 (UTC)

True, but per Wikipedia:Consensus, "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope, unless they can convince the broader community that such action is right." This discussion is community-wide. If we get a large enough consensus, it will be more enduring than a single WikiProject's decision. Ω phois 21:35, 24 July 2010 (UTC)

The problem with that is that the MoS regulars are not in fact "the broader community". The MoS is in effect a WikiProject itself. So no, as to your last point, that's factually incorrect. This discussion is not community-wide, no more so than one at a WikiProject. --Trovatore (talk) 21:40, 24 July 2010 (UTC)

If this is counted as a WikiProject, it is still a representation of "the broader community" more than any other project. Ω phois 21:44, 24 July 2010 (UTC)

No, it isn't. --Trovatore (talk) 21:45, 24 July 2010 (UTC)

Well, you are entitled to your own opinion. But technically any policy/guideline is a "project". So if the TV Project decides to ignore Wikipedia:Neutral point of view, then you are saying they can? Ω phois 21:46, 24 July 2010 (UTC)

Of course not. NPOV is policy (actually it's beyond policy; it's a pillar. But the MoS is not empowered to create policy. Nor should it be; it's largely in the control of a small group of regulars who are especially interested in stylistic matters. Hard to see any way it wouldn't be. --Trovatore (talk) 21:56, 24 July 2010 (UTC)

Anyways, let's see how it goes here. If there is a great consensus one way or another, it will only help the case at the Village Pump. Ω phois 22:04, 24 July 2010 (UTC)

IOW, if the flow is headed in the wrong direction, we shouldn't go with it. — JohnFromPinckney (talk) 20:54, 24 July 2010 (UTC)

OK, as to the merits: My intuition is that names of artistic works should probably not be italicized, but I wouldn't fight it if the editors who are especially familiar with those areas thought otherwise. I would probably be against a general decision to italicize all foreign terms (e.g. I think laurea should remain in Roman type). However, I think Escherichia coli should absolutely stay in italics — looks much better that way. I see no need for the same choices to be applied to such widely disparate subject matters. --Trovatore (talk) 22:21, 24 July 2010 (UTC)

As the person who's probably indirectly responsible for this argument, my opinion is simple. We either italicise all article titles where the subject is normally italicised in the body, or we "ban" the practice outright, and all article titles are rendered identically. Parrot of Doom 22:45, 24 July 2010 (UTC)
- I'm not sure it's quite that simple, as with my example of en suite above. I don't have the resolution to go looking through the Tree of Life discussions, but species names are generally in some kind of doggerel Latin, which is obviously a foreign language unless you're a Catholic, and so should be italicised wherever they appear. I've come around to the view that only foreign language article titles should be in italics. Malleus Fatuorum 22:59, 24 July 2010 (UTC)
  - I think that's still too one-size-fits-all. My main objection personally is when people try to take stylistic ideas developed outside of science, and apply them naively to science articles. Frequently that runs counter to useful practices that have evolved inside the scientific discipline and that serve to promote clarity in that discipline.
  - So bottom line, I really don't care what the outcome is for comic books. But I would be strongly opposed to trying to impose it on biology articles whose titles are binomial names. --Trovatore (talk) 23:05, 24 July 2010 (UTC)

There needs to be a set guideline, and individual WikiProjects should not be able to suggest any guidelines that directly contradict (or any other community guideline). I personally think the italics should be dropped on ALL titles as they are the titles of the actual Wikipedia articles, not the titles of the books, movies, etc nor are they the actual items being talked about with the latin terms that managed to get limited consensus for italics previously. The Color Purple is the Wikipedia article about the novel The Color Purple. Title/latin italics should only be done in actual prose. The template needs to be deleted and whatever flaw in the software that allowed its use corrected. Previous RfC Template_talk:Italic_title#RFC:_Should_this_be_used? -- AnmaFinotera (talk ~ contribs) 22:57, 24 July 2010 (UTC)

My opinion, such as it is, is that if the subject of an article, if rendered in italics in the body of the article should be rendered as such in the title of the article where technically possible. Since the template can do it, then the articles should be set up that way. As for other side discussions above concerning quotation marks, etc, those situations can be discussed if a technical solution is developed to render the title differently than how the article is titled in the database. We already have a template that provides a solution to the situation where iPod is stored under the article title IPod, but rendered as iPod at the title of the article. Imzadi 1979 → 23:14, 24 July 2010 (UTC)
Okay, it's requested so here's my comment. I feel that article title italicization should be applied on an all-or-none basis. If the article title for Triceratops is italicized, then so too should Jumper (a novel), Barney & Friends (a television series), USS Emily (a US naval steamship), etc. Personally, I prefer non-application at all, but if it's to be implemented in some cases, it should be applied in all cases. — pd_THOR ^{| =/\=} | 23:42, 24 July 2010 (UTC)
- Exactly why should it be all or none? A lot of people have said that but I haven't seen much in the way of argument for it. The italicization of Triceratops is for a completely different motive, and conveys a completely different thing, than the italicization of Barney & Friends. It is not clear why a decision on one needs to apply to the other. --Trovatore (talk) 23:47, 24 July 2010 (UTC)

Clear arguments have been made for "all". There might not be "much in the way of argument", because the case is very simple and straightforward: Logical consistency is one of the hallmarks of good style. If some terms normally italicized in running text are to have their articles titles italicized (which is, in itself, a logically consistent choice), then all terms normally italicized in running text should have their articles titles italicized.—DCGeist (talk) 00:22, 25 July 2010 (UTC)

I think it suffices for "logical consistency" to have the same choice within a broad area, for things that are done for the same reason. I don't think we need the same stylistic choices in science articles as in comic-book articles, especially when the stylistic element in question (italicization) has quite different meanings in the two contexts. --Trovatore (talk) 00:39, 25 July 2010 (UTC)

I'd like to vote for italics and quotes based on how it would be in the article, or else nothing. I like the idea of quotes for media works that use them on how they are in running prose. - Peregrine Fisher (talk) 00:13, 25 July 2010 (UTC)

Since the titles at the tops of articles are merely labels, not part of the articles themselves, there is no reason for the formatting. We should just leave the titles in plain roman. This is the style followed by many publications. For example, the Merriam-Webster dictionary on my desk does not italicize the labels for the entries "Homo sapiens", "joie de vivre", "aloe vera", "Triceratops". — Carl (CBM · talk) 01:04, 25 July 2010 (UTC)

When they started italicizing taxonomic names, it looked strange to me. But now that I'm used to it I definitely prefer it. --Trovatore (talk) 01:07, 25 July 2010 (UTC)

Who is "they"? The dictionary I have does italicize them in the text of the entries, but the labels are never italicized as far as I can tell. Which makes sense to me, because the labels are just labels. — Carl (CBM · talk) 01:12, 25 July 2010 (UTC)

"They" being WP biology editors, I guess. --Trovatore (talk) 01:16, 25 July 2010 (UTC)

Move this RFC to Wikipedia talk:Article titles

The subject of this RFC is whether to change part of Wikipedia:Article titles. That page is policy, which takes precedence over guidelines (the MOS is a guideline). I believe that reflects a judgment that the way Wikipedia titles articles is so important to the encyclopedia that a policy is required to assure consistency. Therefore, this RFC must be moved to Wikipedia talk:Article titles. Nothing we say here can have any effect there. On the other hand, we can all go over there.

The current policy that we are discussing is the last paragraph of Wikipedia:Article titles#Special characters and formatting:

Do not apply formatting: Formatting, such as italics or bolding, is technically achievable in page titles but is used only in special cases, one example of which is taxonomic names of genera and species. (See italics and formatting restrictions.)

The exception for "special cases" is too vague for a policy or guideline, in my opinion. Also, in real world publishing, the use of italic for names of books, journals, and some other types of titles is just as widespread as for genera and species. Worse, this policy endorses WP:Naming conventions (technical restrictions)#Italics and formatting, which is a guideline. That guideline adds journals and comics to the "special cases". Comics but not books? These "special cases" aren't sufficiently special to be the sole departures from a policy that otherwise prohibits italic in article titles.

In my opinion, there are two policies worth considering:

Italic is used in article titles the same way it is used in text.
Italic is never used in article titles.

Unusually (for me), I don't have a strong preference between these two, although I leaning toward #1. I'll have more to say when the RFC is moved. Since we hopefully have learned something from the discussion thus far, I suggest that the new RFC be started fresh, rather than copying everything above—but that's for everyone else to decide.—Finell 04:47, 25 July 2010 (UTC)

There is at least one other choice which should be considered, which the various debates so far suggest would get the most support, or at least the fewest objections. This is to italicise biological taxa, or all foreign terms, but not italicise the titles of copyrightable works. This arguably best reflects normal practice in academic writing too. Johnbod (talk) 10:47, 25 July 2010 (UTC)

How would I go about moving it? Ω phois 05:35, 25 July 2010 (UTC)

If you do move it, please leave a link here, which you did not do last time you moved the discussion! Johnbod (talk) 10:47, 25 July 2010 (UTC)

I agree with every word of Finell's (except I do have a strong preference for #1). Ophois, simply initiate a new RFC at Wikipedia talk:Article titles; note in the introduction that a preliminary discussion was held here but has been centralized and started anew there; and leave a note here directing interested parties there.—DCGeist (talk) 07:21, 25 July 2010 (UTC)

Please note that the discussion has now been moved here. Ω phois 15:09, 25 July 2010 (UTC)

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

Proposing a direct link from MOS Weights and Measures to MOSNUM Weights and Measures.

The section on weights and measures has a link to the beginning of MOSNUM. I think it would be preferable for a link in this position to take the reader directly to the weights and measures section of MOSNUM. Then they would not have to look up the index of MOSNUM to find it. What do others think? Michael Glass (talk) 02:21, 29 July 2010 (UTC)

Totally logical, and accomplished.oknazevad (talk) 02:38, 29 July 2010 (UTC)

Excessive footnote links

In the article List of National Treasures of Japan (crafts-swords), there is quite some jargon used, which is explained via footnotes in the "Jargon" section. It has been suggested that the links to these footnotes (with group label "j") make the text more difficult to read (see for an example the end of the text in the "Yamato Province" section or the end of any of the texts in the subsections after it (Yamshiro Province, ...). Would it be preferable to just put a footnote link after the first occurrence of a jargon term (just like the practice with wikilinking), or how should I deal with it? Thanks for any suggestions. bamse (talk) 16:39, 3 August 2010 (UTC)

The article appears to be significantly over-tagged for references. Many are repeated numbers. I don't see the contentious statements that really require close, dense referencing. It is not a BLP. I think it needs to be pruned, especially the bunches of four or five ref tags, which disrupt the reader and look ungainly on the screen. Just one or two should be enough, shouldn't they—give us examples of good sources, please, not a comprehensive list of the source for every single statement. Tony (talk) 16:44, 3 August 2010 (UTC)

OK, I'll go through it and clean up the references. But what about the "Jargon" notes, should every occurrence of a jargon term be footnoted or only the first occurrence? bamse (talk) 17:11, 3 August 2010 (UTC)

On another note, what is a "craft-sword"? Is the hyphen used for conjunction, or to separate the category ("craft") from the type ("sword")? Dabomb87 (talk) 17:13, 3 August 2010 (UTC)

And regarding the jargon, footnoting the first occurrence is fine. We use the same principle for wikilinking. Dabomb87 (talk) 17:15, 3 August 2010 (UTC)

Thanks. I will change footnoting to the first occurrence only. "Craft-sword" is my invention (suggestions for better names very welcome) and originates from the following: There is a category of National Treasures of Japan called "crafts" (official name by the designating body). This category has about 250 national treasure craft items (tea bowls, temple bells, boxes,..., swords and sword mountings). About half of the crafts national treasures are swords (and sword mountings), which I split off into the List of National Treasures of Japan (crafts-swords). The other half (i.e. non-sword crafts) are found in List of National Treasures of Japan (crafts-others). I could call it just List of National Treasures of Japan (swords), but wanted to emphasize that these are crafts and that there are other (non-sword crafts). Also if I called it "List of National Treasures of Japan (swords)", how would I name the other list (List of National Treasures of Japan (crafts-others))? bamse (talk) 20:45, 3 August 2010 (UTC)

For an encyclopedia to invent words or compound forms sounds like a no-no to me. I imagine it violates our policies, though I haven't actually checked. My immediate reaction is that it would be better to rename List of National Treasures of Japan (crafts-swords) and its bedfellows to another form (perhaps simply substituting a colon for the hyphen, but there's probably something more elegant). Where mention is made within that article, would not the term "sword" be sufficient? And in other articles, whose focus may be outside the realm National Treasures of Japan, would craft sword convey what's needed? Ultimately, though, we should use the same terminology as the sources. PL290 (talk) 07:29, 4 August 2010 (UTC)

I agree. Wikipedia should work with the English we have, not the English anyone wishes we had. Also, I am not British and do not find "craft sword" to be confusing. Darkfrog24 (talk) 10:35, 4 August 2010 (UTC)

Hm, the reliable sources use only "crafts" and put everything (swords and non-swords) there. However as far as I understand, wikipedia also encourages not too long articles. That's why I split the craft category in two. How about "List of National Treasures of Japan (crafts: swords)" and "List of National Treasures of Japan (crafts: non-swords)", would that be better? bamse (talk) 11:36, 4 August 2010 (UTC)

~~Glancing at the articles, I see that the swords one is a miniscule list compared to the "other" one. That doesn't seem a helpful split to me.~~ EDIT: sorry, just looked again: I must be blind! At this point tbh, it ceases to be a MoS question, so it would probably be best to continue the discussion about the organization of those articles on their talk pages now. PL290 (talk) 12:08, 4 August 2010 (UTC)

Wikipedia:Manual of Style (poker-related articles)

This page has been marked from historical to part of the MOS recently . Wikipedia:Manual of Style (poker-related articles) has received less than 50 edits in 4 years and in my opinion it not near the standard required to be part of the MOS nor does it have the CON required . I've nowt marked it as Category:Style guidelines of WikiProjects Gnevin (talk) 08:53, 4 August 2010 (UTC)

Not having seen this (although I firmly oppose and have often documented MoS proliferation), the question that pops into my mind is: shouldn't the criterion be not the number of edits over four years, but the number of visits? A perfectly-composed Manual of Style subsection might draw little discussion or editing, but still be valuable to many editors. It's not the edit count or the number of rage-filled talk page archives that makes something like WP:MOSNUM significant; it's how useful it is to how many editors (and, through them, readers). ¶ Where the content of a particular style guide should fit on the MoS hierarchy is, of course, a distinct question. —— Shakescene (talk) 05:23, 6 August 2010 (UTC)

Comma usage when a state name follows a city name

The current MoS does not appear to directly address the issue of requiring of a comma after the State name if it is preceded by a city name, or similarly for the year that is used in a month-day-year format. I did a search through the MoS Talk page archives and found one historical discussion, Wikipedia_talk:Manual_of_Style/Archive_113#Comma_use, where many people debated the topic and Art LaPella pointed to Wikipedia:COPYEDIT#Common_edits where bullet #7 says:

"Except at the end of a sentence, location constructions such as Vilnius, Lithuania, call for a comma after the second element. (Example: He was born in Vilnius, Lithuania, after the country gained independence.) Similarly, a comma is often written after the year in month-day-year date format, unless the date falls at the end of the sentence. (Example: On January 15, 1947, she began tertiary study.)

I also see that we list the Chicago Manual of Style (CMoS) as the second entry in the list of references ( Wikipedia:Manual_of_Style#Further_reading) suggested to be read by Wikipedia editors. In the CMoS 16th edition there are some clear statements on comma usage around state names in specific situations. In CMoS section 6.46 Commas with addresses and place-names in text, two of the examples they provide are:

"Waukegan, Illinois, is not far from the Wisconsin border."

"The plane landed in Kampala, Uganda, that evening."

As for dates, in CMoS section 6.45 Commas with dates, the first sentence says:

"In the month-day-year style of dates, commas must be used to set off the year."

In section 5.82 Dates as adjectives it includes the sentence:

"If a full month-day-year date is used, then a comma is considered necessary both before and after the year {the May 18, 2002, commencement ceremonies}."

Note that it goes on to say when the date is used as an adjective it sometimes appears awkward and it would be better to reword the sentence like {commencement ceremonies on May 18, 2002}.

I assume with the COPYEDIT entry and one of our recommended style guides that the use of commas around the state name when preceded by the city name would be clear and required for any good article. What would it take to add this small change to the MoS section Wikipedia:Manual_of_Style#Calendar_items and Wikipedia:Manual_of_Style#Commas.
§ Music Sorter § (talk) 05:30, 7 August 2010 (UTC)

I've seen it done both ways. I'm sure I once saw a MoS subpage that said it's at the discretion of editors, but I couldn't find it when I looked for it again. PL290 (talk) 08:03, 7 August 2010 (UTC)

I would like to have a clear and prominent statement requiring commas. Ozob (talk) 13:48, 7 August 2010 (UTC)

If there is a page saying it's at the discretion of editors (beyond the usual discretion that applies to all our rules), then I haven't seen it, and the contradiction should be corrected one way or the other. I routinely insert such commas on the Main Page, citing COPYEDIT, although COPYEDIT is no longer part of the Manual of Style. Art LaPella (talk) 15:45, 7 August 2010 (UTC)

Hm, a well-sourced addition to the MoS encouraging correct punctuation? Can I get a heck yes? Darkfrog24 (talk) 17:18, 7 August 2010 (UTC)

Who says it's correct? Bumpety-bump, to most people. Tony (talk) 00:17, 9 August 2010 (UTC)

Hunted for what I saw before, and received a surprise bonus when I searched for "comma US states":

Did you mean: communist US states

Anyway I think this is what I found before. It's not the MoS, it's the Comma article. And not exactly discretionary: "most" style guides recommend the comma, thereby treating the year or state as parenthetical:

In dates When a date is written as a month followed by a day followed by a year, a comma separates the day from the year: December 7, 1941. This style is common in American English. Additionally, most style manuals, including The Chicago Manual of Style^[1] and the AP Stylebook,^[2] recommend that the year be treated as a parenthetical, requiring a second comma after it: "Feb. 14, 1987, was the target date."

In geographical names Commas are used to separate parts of geographical references, such as city and state (Dallas, Texas) or city and country (Kampala, Uganda). Additionally, most style manuals, including The Chicago Manual of Style^[3] and the AP Stylebook,^[4] recommend that the second element be treated as a parenthetical, requiring a second comma after: "The plane landed in Kampala, Uganda, that evening."^[5]

References

^ "It’s conventional to put a comma after the year. The commas are like parentheses here, so it doesn’t make sense to have only one.” "Chicago Style Q&A: Commas". The Chicago Manual of Style Online. Retrieved 2010-04-05.
^ "When a phrase refers to a month, day and year, set off the year with commas... Feb. 14, 1987, was the target date." "Ask the Editor". AP Stylebook. Retrieved 2008-10-29.
^ "Mary traveled to Seattle, Washington, before going on to California.” "Chicago Style Q&A: Commas". The Chicago Manual of Style Online. Retrieved 2008-10-29.
^ "Acme Pens was founded in Padua, Italy, in 2004." "Ask the Editor". AP Stylebook. Retrieved 2008-10-29.
^ Chicago Manual of Style, 14th ed., §5.67.

Not entirely unreasonable. Trashes adjectival use, but hey. PL290 (talk) 17:41, 7 August 2010 (UTC)

The key words in the comma article are "treated as a parenthetical", as that is exactly what it is. The inclusion of a state after a city serves to disambiguate or clarify it if it is a common name or a lesser-known place, such as Kansas City, Missouri, being disambiguated from Kansas City, Kansas. And the inclusion of a year serve to exactly specify a given day, such as specifying that today is August 7, 2010, from the 15 billion other August 7's that have transpired (based on the approximate age of the universe).

In short, I agree that proper grammar calls for the use of the comma, and, heck yeah, so should the MoS.oknazevad (talk) 19:07, 7 August 2010 (UTC)

And may I say that most readers are sick of a rigid postal-address formula in which a state has to be trotted out every time. "New York, New York", oh puhlease, save us. Just "Los Angeles" or "San Fransisco" alone, that's just fine: we really don't need to be reminded that some part-time body of pumped-up morons sits up in Sacramento pretending to lord it over these cities. Tony (talk) 00:16, 9 August 2010 (UTC)

Wikipedia:Naming conventions (geographic names)#United States follows the guidance of the AP Stylebook on this issue and since cities were moved to comply with it, it seems to have quietened down disputes over the article title for city names. Of course many non US cities have people lording it over them, its often good for a party. -- PBS (talk) 22:30, 9 August 2010 (UTC)

See: Union of San Franciscan Socialist Republics ;) Jack Merridew 10:18, 10 August 2010 (UTC)

Redirects to Union of Soviet Sausalito Republics. See also: Communistwealth of Massachusetts (1620). ;-) —— Shakescene (talk) 10:27, 10 August 2010 (UTC)

yours don't have deletion logs ;) Jack Merridew 10:39, 10 August 2010 (UTC)