Wikipedia talk:Manual of Style/Archive 97

From Wikipedia, the free encyclopedia

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


Contents

Right-facing images and {{Toc right}}

The current text of MOS includes suggestions to place right-facing portraits on the left, even at the beginning of the article, and suggest using {{Toc right}} if that interferes with "navigation elements". IMO, this is unacceptable. Wikipedia articles aren't stand-alone works, they're a part of a wider work, i.e. the encyclopedia. It is important for all articles to have the same basic visual structure and placement of the TOC. Aesthetics are an entirely secondary concern. Unless somebody provides a good reason for these suggestions to stay in the guideline, I will remove them. Zocky | picture popups 03:22, 23 February 2008 (UTC)

Go ahead, they are taken far too prescriptively. However, I cannot agree that the same placement of the TOC is essential; some articles develop large areas of white space which can most easily be resolved by moving the TOC. Septentrionalis PMAnderson 04:03, 23 February 2008 (UTC)
  • (edit conflict) I strongly suggest that this exception remain in the MOS - without the exception, the MOS will dictate that all articles begin with an image on the right. Aesthetic principles dictate that right-facing portraits do not "look off the page" (in this case, the screen) as it leads readers' eyes away from the page. It is a principle followed in the layout of art books which we would do well to follow as well. Aesthetic concerns such as these are important as they keep readers' attention focused on our articles. Such exceptions have already been debated and consensus achieved for FA articles such as Joseph Priestley (both before the FAC and at the FAC), if that is any indication of community support. My personal experience with this issue has been that primary article contributors tend to endorse left-alignment as they are working daily with the article layout and thinking about it while it is gnomes and other editors who make small clean-up changes who endorse right-alignment. Clearly the needs of consistency need to be balanced with those of aesthetics, but I don't think that an image, a lead, and a TOC in various arrangements is so very confusing. It is those three elements that we like to have at the top of all of articles for our readers. Achieving the best balance between those three elements for each article is the goal - sometimes this means restricting the TOC, sometimes this means shifting the image to the left, and sometimes this means granting extra room for the lead. We need to be flexible to allow for each article's individual needs. Awadewit | talk 04:07, 23 February 2008 (UTC)

OK, as far as I can see, we have the following arguments:

The layout should be kept standard
  • It makes finding standard pieces of information easier
  • It makes it easier for bots to maintain articles and extract information from them
The layout should be customized to the article
  • It makes prettier articles
  • It can save space
  • We shouldn't follow arbitrary rules
  • We should follow an arbitrary rule of aesthetics

AFAICS, the reasons for customizing the layout are either subjective (the prettiness), irrelevant (Wikipedia is not paper, and saving space is not essential), or contradictory (we should ignore our arbitrary rule in favor of another (at least as) arbitrary rule, i.e. an "aesthetic principle". Am I missing anything? Zocky | picture popups 04:50, 23 February 2008 (UTC)

I came here via the Jane Austen talk page, so forgive me for intruding. Zocky, I think you're taking Awadewit's fairly valid points and twisting them to fit your own agenda. I do not think that ensuring that an article fulfills clearly established and precedented aesthetic values is merely a matter of making the article "prettier". It's a matter of academia, which is what Wikipedia, as an encyclopedia, should aspire to above all things. All articles are different, not only in quality but in substance, and should be considered on a case by case basis. This is why stringent rules regarding infoboxes and image placement simply cannot apply to each and every article. For examples, articles as broad as Austen's tend to attract crufty infoboxes in which original research by way of synthesis (influences and influenced fields) and other un-encyclopedic entries often find a home. In a well written article all important information will be listed in the lead section; the reader won't even have to scroll.
I agree with the idea that Wikipedia is not paper, but integrity should outweigh conformity. One article is different than the next; all images simply do not belong on the right side and all articles do not necessitate an infobox -- because of these reasons, you will find it highly difficult to reach a consensus on both of these matters. I for one support the optional placement of infoboxes and the choice to put a right-facing image on the left side of the lead. Bots are not readers and are therefore not our priority, readers are capable of reading through an article if they are dying to find important and key facts about a subject, and strict standardization on these issues will never reach a consensus. María (habla conmigo) 05:14, 23 February 2008 (UTC)
First of all, I have no strong feelings on the infobox issue. I can see how it can be useful, and I can see how it can be annoying. But let's not mystify the "aesthetic issue" of the right-facing pictures having to go to the left. It's a more-or-less arbitrary rule intended for paper books. The likelyhood of a reader's eyes being drawn to the right of the article on a computer screen is minimal and in all likelyhood entirely irrelevant for our purposes.
Oh, and a thought about bots: Our mission is to collect and arrange information, so that the free knowledge can be used by people. One way that the people need to use the knowledge is for creating more free knowledge by extracting bits and pieces from hundreds or thousands of articles. Examples include Google Earth layers with markers representing Wikipedia articles, computer-generated lists of people from a certain profession, etc. Enabling these uses is a part of our core mission, and standard layout and infoboxes are among the ways that we accomplish that. The need to have information about Jane Austen included in those computer-generated compilations of knowledge should obviously trump the need to have her portrait face into the article. Zocky | picture popups 05:33, 23 February 2008 (UTC)
As I understand it, bots are not affected by the visuals of the article as they run on the "code". Please explain which bots you think this would affect and how. Usually bots are not affected by such things. If they are, they should be fixed. Awadewit | talk 06:05, 23 February 2008 (UTC)
You achieve the visual changes by changing the code. A bot that extracts information from intros may not be aware that you're using non-standard (for articles) ways of displaying the TOC and may thing that the code for it is a part of the article text. That can be fixed in the bot code, of course, but the more variations, the harder it becomes to do. OTOH, information that could be extracted from a template call (i.e. an infobox) can't be extracted from text by a program at all. Zocky | picture popups 06:09, 23 February 2008 (UTC)
This doesn't really make sense because many articles (such as stubs) don't even have introductions. In fact, the majority of articles are "non-standard". Please give examples of bots that would be affected so we can see the real ramifications of this. Your speculation might indeed be pointing to a serious problem, but the problem is hard to see right now. I am not inclined to endorse to change a policy for bots over readers when we haven't even pointed to specific examples yet. Awadewit | talk 06:13, 23 February 2008 (UTC)
The question is not whether such a bot exists at this moment or not, the question is, are we enabling it to potentially exist. The bot that scrapes geographical articles for coordinates to produce the Google Earth layers didn't exist before we standardized the information, because there was nothing for it to scrape. The added information that can be produced by scraping data from multiple articles emerges from the standardization. This makes the standardization of data a good thing in itself, regardless of how it's currently used. Plus, what Stradivarius said below. Zocky | picture popups 06:26, 23 February 2008 (UTC)
I don't think that it is a good idea to design policy around a yet-to-be-designed bot. Policy should think of readers first, editors second, and everything else third. We can design bots to do whatever we want. Awadewit | talk 06:42, 23 February 2008 (UTC)
Policy should think of encyclopedia first, encyclopedia second, and encyclopedia third. The goal of the project is to write an encyclopedia and to produce free knowledge, not to please readers. Zocky | picture popups 06:51, 23 February 2008 (UTC)
But the encyclopedia is for readers - not for bots. We need to think about their needs. Awadewit | talk 07:00, 23 February 2008 (UTC)
More than my eyes being "led off the page" by a right-facing, right-aligned portait, my eyes have an initial difficulty locating the beginning of the text block if it doesn't start at the top left corner of the article frame. If keeping right-facing portraits on the left side of the page is really that important, I suggest that they be coded to appear a bit lower, so that there are at least a few lines of text that start flush left. Strad (talk) 06:21, 23 February 2008 (UTC)
I don't mind having text above left-aligned portraits, however I don't know if it is really necessary. Readers are already used to having adjust right to find text because of the menu bar on wikipedia (and most websites). It is not a big adjustment to keep looking a little further right. Awadewit | talk 06:44, 23 February 2008 (UTC)

Hmmm, I think we need a clarification here. Awadewit says that the majority of articles are non-standard, but this is incorrect. The standard, as far as humans are concerned, is to have the text start in the top left corner, and for the TOC to follow the intro section, flushed left. The standard, as far as bots are concerned, is for the article text to begin in the first P tag in HTML, and for the TOC to be included in the DIV tag right before the first section break, (i.e. a H2 tag). The vast majority of articles follow this standard, simply because it's the default behaviour. Only a tiny share of articles, probably well under 1%, uses non-standard layouts. Zocky | picture popups 06:38, 23 February 2008 (UTC)

  • That's not what I meant. When I said "non-standard", I meant that most articles don't have an image, a lead, and a TOC. Because most articles are stubs, most don't have a lead and a TOC, for example. Awadewit | talk 06:41, 23 February 2008 (UTC)
    • Well, they do have a lead, they just don't have the article body ;) But, most articles aren't stubs. The vast majority of articles (clicking on the random article link suggests 90-95%) have at least one section header, and the majority (70-80%) have a picture or an infobox. Whether the TOC gets shown for articles with at least one or at least four section headers depends on your user preferences. (BTW, user preferences and personal CSS styles are another reason not to mess too much with the layout.) Zocky | picture popups 06:49, 23 February 2008 (UTC)
      • But it is still not clear to me why left and right-alignment would mess up any of these things. Please provide evidence of that. Thanks. Awadewit | talk 07:00, 23 February 2008 (UTC)
        • No, I'm arguing for the standard way of doing things. The claim that it's easier to work with standardized information, whether for readers, bots or CSS is self-obvious and doesn't need proof. What you need to do is argue that deviating from that established standard in the case of right-facing portraits brings net benefit. Your argument so far seems to be based purely on aesthetics, and that is simply not enough. Zocky | picture popups 07:05, 23 February 2008 (UTC)
          • But standardization isn't necessarily the best way to present information and that is the primary goal of the encyclopedia. Articles should be laid out in the way that best presents information on that particular topic. I would also like to point out that I am not arguing that we deviate from an established standard. I am arguing that we keep the current wording of the MOS, which agrees with established artistic principles, which is indeed important. I'm asking you to demonstrate how the current MOS regulations are harmful. You want to change them because you say without standardization bots will not be able to function. That is a claim that needs to be proven. 07:50, 23 February 2008 (UTC)
        • P.S.: As for aesthetics: are you aware that different users use different skins? When you change the layout of an article, do you check that it looks right in all skins? Do you expect other editors to do that? Zocky | picture popups 07:08, 23 February 2008 (UTC)
          • Yes, I do know about different skins. However, this is a minor percentage of users - most users come to us from something like google search and see the "classic skin" so I tend to check layouts in that skin. I was also under the impression that skins only changed the colors and design of the space surrounding the article. I did not think that skins changed the articles themselves. Awadewit | talk 07:42, 23 February 2008 (UTC)

(de-indenting). I concur with those who support flexibility here. "Aesthetic principles" are hardly "arbitrary rules", but rather is a fancy way of saying "We should design the encyclopedia in such a way that it is readable," which is indisputable. I disagree that we should promulgate a rule that will require making our pages uglier for the benefit of some hypothetical, poorly-written bot. As with article content, this is an area where we have to rely on our editors to use their judgment. If a picture on the left looks better on a given article, then the editors should be able to put it there. Nandesuka (talk) 08:48, 23 February 2008 (UTC)

"Standardization" on wikipedia is only meaningful when speaking about humans. Wikipedia articles are not created in a parseable markup language. While there are still many bits of information that might be parsed from them by a "bot", articles are designed for people. Whether or not the MOS guidelines under discussion affect bots is a red herring, and doesn't need to be proven, because it doesn't matter. The human argument seems to come down to aesthetics on both sides, and I don't doubt someone can find a vague reason that left-aligned portraits affect accessibility or usability. Examples would be good. (After learning from the MOS that left-aligned images in the article body should be placed before headers, so the header indents with the paragraph below it, I later saw someone change this based on accessibility.) It's a wiki. Not everything is going to be the same everywhere, and few people but the self-selecting wiki editor niche even notice these differences. This is what no one gets. So if we're going to consider "the reader" (a good idea), such alignment issues should perhaps be scheduled for their eighth discussion on behalf of the reader sometime after wikipedia has 50,000 featured articles on major subjects of human interest. –Outriggr § 10:41, 23 February 2008 (UTC)

Of course articles in Wikipedia are created in a parseable markup language. I'm not sure what that argument is supposed to mean, anyway.
And you talk as if bots work for themselves. They don't. They work for humans. When a bot parses a page to extract information, it's a human using the information with a bot. Thus the argument that standardization to facilitate data extraction is not human-oriented is simply wrong. We're creating a volume of free knowledge. The fact that most of the time most of us access that knowledge through a web site and a web browser is coincidental. Standard formatting of information is information in itself.
In effect, varying the layout of the standard pieces of information reduces the total amount of information for users, readers and data-extractors alike. It should be done only for good reasons, and this particular aesthetic principle (which is also somewhat dubious in our setting) doesn't seem to be one. Zocky | picture popups 01:10, 25 February 2008 (UTC)

As right-aligned TOC have problem with printing and you can see it if you try to print Jane Austen article on A5 pages. And as I tested and I feel it's not much different wethere to right-align or left-align a right faced picture. I think it's a good idea to try to have TOCs left aligned as much as possible. however i believe it depends on the article and shouldn't be discussed totally. Moreover I believe bots aren't important in right-aligning or left-aligning images or TOCs and for machine readable contentes another way except than wikipedia articles should be used. only a few visitors are such those bots and its bot's problem in that case.--Soroush83 (talk) 14:10, 25 February 2008 (UTC)

The discussion of bots is interesting, but I don't think it's the primary issue here. My concern is that the choice of image placement and its impact on article formatting affects readers. About three months ago, the layout of Jane Austen was changed to left-align the only authentic portrait of the subject, which initiated a cascade of other changes to work around this choice, most signficantly, removing the infobox and right-aligning the TOC. Since then, the article has been edited repeatedly in obviously good-faith attempts to (in their eyes) correct a formatting mistake. Clearly many readers find this layout objectionable. The subject has been brought up on the Talk page, but objections there are dismissed by references to this guideline... which is odd, because most of what it says here argues against the change.
The guideline currently states, "Portraits with the head looking to the reader's right should be left-aligned (looking into the text of the article) when this does not interfere with navigation or other elements." This is a sound recommendation. Graphic design professionals know that it's better to have the people in pictures looking into the page, not out of it. But those working in user interface design know there's also the question of usability to consider, which is why the caveat about navigation elements is important. Like I said: so far, so good.
Strangely, the next sentence flatly contradicts this, suggesting that the TOC – a navigation element. – be shoved out of the way to make room for a left-aligned image. Now, I don't claim to the world's foremost expert on user interface design, but I have taken classes in the subject, in which I was told that it is a Bad Thing for user interface elements to move around the screen, because that can be disorienting and it requires the user to spend more time looking for them. My professional experience supports this. It's less-than-ideal that the TOC moves up and down to accommodate the length of the intro, but that's tolerable because readers quickly come to expect it within WP. However, having seemingly-random articles substitute left-placement of the TOC for right-placement is confusing to many readers. After all, the rule about which way portraits should face is not generally known, nor is it self-evident. But the rules that UI elements should stay in place, and that articles should be formatted consistently unless there is "a compelling reason to do otherwise" (WP:MOS#Images, line 1), are intuitively understood. The suggestion to move the TOC just to accommodate a face pointing the wong way is (IMHO) bad UI design, and should be removed in favor of statement that precedes it. - JasonAQuest (talk) 03:52, 9 March 2008 (UTC)

Numbers in words

Please explain below what is wrong with the changes in wording made to the section on numbers represented as words, all of which were reverted without exception. —Centrx→talk • 02:32, 10 March 2008 (UTC)

To start with, there were problems in your wording. Tony (talk) 02:50, 10 March 2008 (UTC)
What exactly are they? A pithy declaration like this is useless. —Centrx→talk • 03:26, 10 March 2008 (UTC)
Centrx!!! No no! Pay attention: We need a completely fresh discussion, don't you see? There's nothing wrong with using italics for mentioning; I do it all the time! I insisted that we get rational and consistent about doing that (search the archives, if you like). Try again. Leave things as they were before your undiscussed alterations of 24 February; fix it at WP:MOSNUM also (and get rid of that protection: no one will edit-war, provided only that the current consensus guideline is left alone). Off you go! Come back when the current damage has been undone.
–⊥¡ɐɔıʇǝoNoetica!T– 02:53, 10 March 2008 (UTC)
This is a fresh discussion, in a fresh section. Present the reasons why you reverted or do not revert. That is all. —Centrx→talk • 03:26, 10 March 2008 (UTC)
It is not a fresh discussion. PMAnderson and I were doing one of those (look and learn!). This, on the other hand, is a pusillanimous attempt to dwell on italicising and such minute matters, which have nothing to do with the topic as a whole, and for which there are clear principles already in place. All that can be fixed easily.
I'll not try any more to get this matter addressed rationally. Plague someone else for a while, Centrx. I have better work to do. I'll come back when things are restored to proper order, and your damage has been undone. That is all.
–⊥¡ɐɔıʇǝoNoetica!T– 03:40, 10 March 2008 (UTC)
I made an edit, which you reverted. You have not explained anything wrong with the edit. —Centrx→talk • 03:49, 10 March 2008 (UTC)
I haven't??? Amazing. Sorry, Centrx. Too late. Talk to someone else.
–⊥¡ɐɔıʇǝoNoetica!T– 03:59, 10 March 2008 (UTC)

Single quotation marks

Everything about quotation marks and the usage of single and double ones revolves around quotations. Everything. There is not a single sentence about the usage of single quotation marks in any context other than quotations. Well, except for this:

If a word or phrase appears in an article in single quotes, such as 'abcd', Wikipedia's search facility will find that word or phrase only if the search string is also within single quotes. This difficulty does not arise for double quotes, and this is one of the reasons the latter are recommended.

But it's not very clear, is it? Yet single quotation marks are used for all sorts of terms and names. From the above excerpt I can only infer that they are not supposed to be thus used, but it is not clear enough, and it has obviously not affected the flourishing current practice. I have replaced single quotation marks with double ones in some cases, but only tentatively; it actually took me some time to locate this little sentence and fully realise what it said.

I think that it ought to be more clearly shown in the MoS what exactly the guidelines are on single quotation marks. I mean, there are guidelines, right? Waltham, The Duke of 01:27, 11 March 2008 (UTC)

In general, single-quotation marks are used where double-quotation marks might mislead the reader into thinking text was quoted where it was not, or in other words in situations where a word is to be somehow distinguished as not being used in it ordinary sense or as a use-mention distinction. Italics are often better as we have that formatting option. —Centrx→talk • 02:28, 11 March 2008 (UTC)
I agree that italics are usually better, and I use them very much myself. But shouldn't this be mentioned somewhere? I'm tired of seeing single quotation marks everywhere, and people will keep adding them unless instructed otherwise.
Note that the italics in my message are just for emphasis. :-) Waltham, The Duke of 11:09, 11 March 2008 (UTC)

PD quotation clarification

As apparent at Wikipedia talk:Citing sources#Return of PD text style, the Quotations section needs clarification that reused text from public domain sources such as EB {{1911}} do not need to be walled off inside quotation marks. Or else a bot needs to go wrap quotation marks around a bunch of articles and city descriptions. -- SEWilco (talk) 17:52, 11 March 2008 (UTC)

Romanisation

I have encountered at least ten mentions of romanisation on this page so far, and yet nobody has seen it fit to explain what exactly romanisation is in this context. Although I have a vague idea, I do not really trust myself to draw accurate conclusions in such matters. Waltham, The Duke of 03:07, 13 March 2008 (UTC)
Romanisation is giving a Latin-alphabet version of text that is originally in another script. We normally speak of romanisation with Chinese and Japanese. When the source script is alphabetic (like Greek or Russian), we normally use the narrower term transliteration. Whether our articles mark this distinction adequately is another matter.
I suppose some people might use romanisation in the sense of de-italicising, since normal, non-italic styling is called roman. SOED gives this definition, at "Roman":

3 (Now usu. r-.) (Of printed type) of a plain upright kind resembling that of ancient Roman inscriptions and manuscripts, esp. as distinguished from Gothic and italic; (of handwriting) round and bold. E16.

But given the more established meaning associated with transliteration, it is better not to use romanisation in this alternative way.
–⊥¡ɐɔıʇǝoNoetica!T– 03:21, 13 March 2008 (UTC)
Waltham: I did a computer search with my browser and found neither romanisation nor romanization. Can you give a searchable example? --Gerry Ashton (talk) 03:12, 13 March 2008 (UTC)
I think our noble young colleague is licensing himself to nominalise for convenience. The noun romanisation does not itself appear here. I'm glad he asked the question, though. Good for us all to be accurate with our terms, and to have an occasional reminder.
–⊥¡ɐɔıʇǝoNoetica!T– 03:25, 13 March 2008 (UTC)

(de-indent) Thank you for your quick reply. I was obviously asking about the alternative version, as you cannot really have expected me not to have looked for the Romanization article before asking here (although one can expect anything from Wikipedians). As you were all talking about Latin, which is already using the Latin alphabet (any surprises there?), the basic definition looked simply irrelevant in this case.

By the way, sorry about the confusion, Mr Ashton; if you had happened to look, the last mention of the term (in a different form, obviously) was in the message immediately preceding mine. Waltham, The Duke of 13:47, 13 March 2008 (UTC)

Noetica's reference to the SOED is helpful, that does give some support, but Gerry brings up an interesting point. In the Wikipedia entry on Romanization, and in the first 3 pages of a Google search on the term, including all the online dictionaries I usually use, there is no hint that it means "de-italicize". The 5 thesauruses I looked in didn't give a single antonym for "italicize" (other than things like "de-emphasize"). So, I'm stumped. - Dan Dank55 (talk) 20:31, 13 March 2008 (UTC)
The Online English Phrase Checker is quite good for this type of search:
The question is "How widely is the term used with the alternative meaning?" Perhaps the Wikipedia article should include a note, or at least the Wiktionary entry, in which case a box linking to it ought to be added in said Wikipedia article. Waltham, The Duke of 14:58, 14 March 2008 (UTC)

Another unclear but significant change

We discussed this once, but it's lost in archives. WP:MSH is a much used shortcut for proper section headings, and I'm suddenly seeing errors and confusion all over articles again, so I came over here to see what happened, and lo and behold, another example of long-standing wording that seems to have gone missing again. What happened to:

Avoid restating or directly referring to the topic or to wording on a higher level in the hierarchy.

When did it get deleted, why, and where is the discussion?

Months ago we had a clear WP:MSH section which explained: 1. Don't use "a", "the", etc. 2. Don't repeat wording from a higher level 3. Capitalization of first word only, yadda, yadda ...

A lot of that got merged into the top of the article, and lost from WP:MSH. Even though it's still linked, people don't see it. Further, the business about repeat wording is now completely gone, so section headings are showing up a mess. Can someone point me to the discussion that resulted in dropping the business about repeat wording ? The section just is not clear any longer, and not effective. MoS needs to have a monthly digest of changes made, or risk becoming obsolete as people stop trying to keep up. SandyGeorgia (Talk) 02:33, 14 March 2008 (UTC)

  • I really think the same old issues should not be stamped out twice in full within the space of three subsections at the top of MOS. That was the reason for the rationalisation and, thus, the cross-references between the Article and Section Heading subsections. I've copy-edited and strengthened the cross-reference; but why not make MSH link to the top subsection instead? Tony (talk) 03:09, 14 March 2008 (UTC)
  • That issue continues to confound, but why/when did we lose the sentence about not repeating words? As I refer editors to WP:MSH, I'm seeing they're not comprehending, and now I see why. SandyGeorgia (Talk) 03:26, 14 March 2008 (UTC)
  • Not relevant; whether you link to the acronym or the actual section heading, the problem is the same. SandyGeorgia (Talk) 03:27, 14 March 2008 (UTC)
  • But but: the "Avoid restating" point is there:

* Avoid restating or directly referring to the topic or to wording on a higher level in the hierarchy (Early life, not His early life).

Tony (talk) 03:35, 14 March 2008 (UTC)

Archiving this elephant

That was getting ridiculous: I've just archived 236 Kb, at Wikipedia talk:Manual of Style/Archive 97, leaving 185 Kb here. Tony (talk) 09:21, 14 March 2008 (UTC)

According to the request at the top of this page, MiszaBot archives after 20 days. -- SEWilco (talk) 13:33, 14 March 2008 (UTC)
Thanks, but 400+ Kb is too much. Tony (talk) 14:11, 14 March 2008 (UTC)
There appears to be a certain problem with the organisation of the archiving process for this page. Archive 97, you said? The directory listed the contents of archives up to number ninety-four. (I have already fixed that, but it does show a lack of attention.) Furthermore, Archive 96 was only 88 kilobytes in size while the previous ones range from 250 to 400 KB. I have thus moved the entirety of the contents of 97 to 96, leaving the former empty for the next archiving (with the template at the top, which was missing).
As thematic archiving is not an issue here, I suggest that we should specify a standard size for the archives. Furthermore, if nobody objects, I shall add an archive navigation template at the top, under the archive template, and add a second archive template to the bottom. This will make the archives more navigable and is consistent with current practice and the suggestions in WP:ARCHIVE. I have applied this to Archive 96, as a sample for the esteemed editors to comment on.
PS: I've just got wound of the exitstence of {{talkarchivenav}}, which combines {{talkarchive}} and an automatic variant of {{archive-nav}}; we could use that instead of the two last templates for the top of the pages, although I don't have a clear preference. Waltham, The Duke of 16:23, 14 March 2008 (UTC)
Don't accuse me of "a lack of attention", and be grateful that I bothered to do this selective archiving at all. Next time, why don't you get off your arse and do it? The archiving system is bizarrely complicated, and I took the first red link. Make it easier to use before you complain. Tony (talk) 01:47, 15 March 2008 (UTC)
I always edit seated, Tony, so I shouldn't get off my arse anyway. Now, I suggest that you should read a message twice before you respond to it rudely; it does have a bad impression upon your person, you know. (Although you must have missed the opportunity to make a good impression behaviour-wise a long time ago, from the looks of it. Just an observation from my brief tenure in this page.) The specific comment you are referring to was made with regards to the lack of updates in the archive directory, and was not meant for anyone specifically (unless there is anyone believing to own the MoS, which is certainly a possibility with any page). My moving the archive was stated afterwards, as a simple fact. I think the order of my sentences was clear enough on its own.
Of course, your reaction might actually be concealing a certain degree of guilt, which could be interpreted in various ways. My alter ego, Dr Fraud, would be very interested. ;-D
Having solved that, I look forward to hearing the constructive comments I know you can make. An improved archive system is to the benefit of us all. Waltham, The Duke of 03:25, 15 March 2008 (UTC)
I've re-read it, and it still looks like a rude, insensitive comment directed at me. Fine if you meant otherwise, but reflect your meaning accurately in your text. And garnering "good impression"? I've never been interested in that. Tony (talk) 03:49, 15 March 2008 (UTC)
Perhaps it did because I do not necessarily make it clear that I generally do not hold specific editors responsible for community actions. Archiving project talk pages is certainly not any one editor's responsibility.
Now, can we please get back to the subject?
  1. Archive size
  2. Usage of archive and archive navigation templates
See my first message in this thread for more details. Waltham, The Duke of 04:33, 15 March 2008 (UTC)
Thanks guys for archiving this elephant. It was getting slow to load even on my 2 Mbit/s ADSL connection...
--David Göthberg (talk) 16:42, 14 March 2008 (UTC)

Hard-space proposal: invitation to comment

A completed draft

The working group on hard-space markup has completed a detailed proposal. Click "show" to see it:

We took the discussion elsewhere so we could work on the proposal without cluttering this page, and to keep things self-contained. But we now present our work for your comments and assistance, right here at WT:MOS. This is not a call for a vote, or for formal expressions of support or opposition.

Any thoughts on the proposal as it now stands?

– Noetica♬♩ Talk 03:24, 21 January 2008 (UTC)

The use of ,, as a substitute for &nbsp; seems odd, and exactly counter to your examples of ''...'' for <i>...</i> and '''...''' for <b>...</b>. The more wiki-like technique would be something like ,,...,, (e.g., ,,17 sq ft,,) to turn all spaces within the markup into hard spaces. RossPatterson (talk) 05:27, 21 January 2008 (UTC)
Thanks, Ross. Yes, it isn't wiki-like if we assume that wiki markup must affect a whole block of text, rather than standing for a single entity. But single insertions of the entity &nbsp; are what we need most pressingly.
– Noetica♬♩ Talk 05:46, 21 January 2008 (UTC)
I think it would be better to devote improvement efforts to making the Wikipedia editor show Unicode hard spaces distinctively, and making them easy to insert. This would not only solve the problem of new text, but also allow editors to work effectively with articles that already contain Unicode hard spaces, or to work effectively with passages that are copied from other sources which already contain hard spaces. --Gerry Ashton (talk) 06:32, 21 January 2008 (UTC)
Nobody seems to have noted this comment, but I strongly agree with it. Rather than introduce new Wikicode markup, it would be vastly superior to just adjust the editor to display hard spacing in some distinctive way within the editor window, and to add a button to create a hard space. If the distinctive appearance of the hard spaces is well designed, this will be superior in readability to any wikicode markup, and easy to use.--Srleffler (talk) 16:30, 11 March 2008 (UTC)
The current proposal tends toward that sort of clear visibility, doesn't it? What will ,, mean, if not a hard space? It doesn't mean anything else at present. We never see it! If we didn't already have '', that markup would look just as suspect and counterintuitive. But we recognise it, insert it, and edit it very naturally. I'm interested in your mention of "articles that already contain Unicode hard spaces". Are there many of those, in fact? It's hard to research such a thing. In any case, if ,, were adopted surely bots could be deployed to convert both existing Unicode hard spaces and occurrences of &nbsp;. Soon all hard spaces would be very visible, and all would have the same appearance to editors. Thanks for your comment.
– Noetica♬♩ Talk 07:01, 21 January 2008 (UTC)
Basically, Mr Patterson's proposal is reminiscent of the nowrap template, the deficiencies of which have already been indicated; the double double-commas idea, though less intrusive, would still present problems, including greater confusion in reading it and more mistakes in applying it correctly. Waltham, The Duke of 10:22, 21 January 2008 (UTC)
That equivalence is hard to understand. After all, there don't appear to be any acknowledged deficiencies of the bold and italic wiki markups after which my suggestion is modeled. If the working group's proposal is to stand on its own, perhaps it should explain why Wikipedia should introduce this new concept of "wiki character entities" before making arguments about which notation to use for it. RossPatterson (talk) 18:43, 21 January 2008 (UTC)
If this is intended for more Mediawiki projects than just English Wikipedia, here is probably not the best place to discuss it, because there may be issues with the proposed markup in other languages, e.g. ,, may look very similar to „, which is used as an opening quotation mark in some languages.
I think the underscore _, maybe doubled __, would be more intuitive, because it already represents (soft) spaces in links. _foo_ or __foo__ is used in some adhoc inline markups for underlining, though, and sometimes for Tex-like subscripts too (CO_2).
If we did character replacement markup, there would be some others I’d like to see: typographic quotation marks ("foo" → “foo”, for English) and apostrophes (foo's → foo’s), dashes (foo -- bar → foo – bar, foo---bar → foo—bar), ellipses (... → …), arrows (-> =>), Tex-inspired diacritics (f"oo or f\"oo → föo), superscripts (m^^2 → m²), fractions (3/4 → ¾, although also an OpenType feature), mathematical symbols (1deg * 2 N*m >= x → 1° × 2 N·m ≥ x) etc.pp. — Christoph Päper (talk) 12:46, 21 January 2008 (UTC)
Crissov's underscore for hard spaces may be a worthwhile idea; but to push for a large number of shortcuts at once is likely to capsize the whole thing. Hard spaces are our major concern, and I hope that we can keep to the original, specific issue here. Of course it needs to be taken elsewhere, but I think the matter has been raised here to generate constructive comments and much-needed support if this important initiative is to succeed. Let's see if we can succeed in this first addition to MediaWiki's code for a long time; with that experience behind us, more may be possible. Tony (talk) 14:05, 21 January 2008 (UTC)
I would love to see those automatic replacements too. The straight ' and " really make my eyes bleed. This could enhance significantly the typography of articles which is sometimes a bit unoptimal let's say. Med (talk) 00:39, 14 February 2008 (UTC)
  • I also think underscore would be far more intuitive; though it would clash inside math tags, I'm not sure if that would pose real problems. I'm not convinced ,, is as intuitive as ''; and as for ,,,--, : yuck! Also, the date example in the exposition is infelicitous given MOS:DATE#Autoformatting and linking. jnestorius(talk) 14:41, 21 January 2008 (UTC)

Several of the above comments start discussing the exact form the new markup should have. May I take that as an approval of the principle of adding some markup symbol(s) for hard to enter special symbols? −Woodstone (talk) 16:14, 21 January 2008 (UTC)

I don't think that's an appropriate argument by extension. There seems to be a significant difference between spaces (hard or otherwise) and everything else. In other words, the English Wikipedia would die if you were forced to type spaces as &#x20; (and to read them that way in the editor), but it will probably survive every other character-handling difficulty. RossPatterson (talk) 17:15, 21 January 2008 (UTC)
I think each additional symbol needs to be more intuitive to justify the mental cost of learning it. Far more people are familiar with HTML tags than Wiki markup. Replacing <BR> with markup seems pointless at best; it's mostly easier to read concatenated XML tags than long strings of punctuation symbols, and often easier to read character-entities too. In summary, I would quite like to see -- for en, --- for em, and _ for nbsp, but any more complicated markup, or any extra other replacements, seem unnecessary for the default edit mechanism; though clever mappings and substitutions in whatever layer may be useful options for particular users. jnestorius(talk) 17:32, 21 January 2008 (UTC)
Many valuable observations! Already our request for comment has paid off.
Waltham is right that Ross's ,,...,, is relevantly like (not equivalent to) {{nowrap}}. I don't know if Ross's suggestion is serious or just illustrative; but let's note in passing that it wouldn't work well. Apart from problems of parsing (surmountable), consider an en dash, with hard space before and normal space after:
,, –,, ; or
,, ,,– .
And if the en dash were done another way (see below for --):
,, --,, .
All silly-looking! But then, consider the current options (setting aside direct use of a Unicode hard space):
&nbsp;— ;
{{nowrap| –}} .
Does any of us like any of those? Under the current proposal:
,,— .
Stands up rather well, does it not? Then there is one possible extension touched on in the proposal, and mentioned above by jnestorius:
,,,--, .
The status of future extensions has been problematic in the proposal. It is important to address wider implications of ,,; but all we need is to show that more could be done, without attempting immediately to do it. Anyway, surely we can see the virtues of ,,— . If there is any option, current or mooted, to which jnestorius does not say yuck, perhaps it should be this last.
The underscore _ might be more intuitive than ,,, but unlike ,, it has too many existing applications, whether these are deprecated or not. Christoph raises other matters: the curly question of ‘’ and “”, for example. Again, we do need to have an eye to the big picture. Despite earlier exchanges in this forum, I am sympathetic to calls for better typographic substitutions. (Not all available ones: preformed … is inferior to ..., I think.) Regrettably, none of that seems achievable. Faced with this reality, we have attempted to solve a single pressing problem.
Ross makes a useful point by considering an extreme case: "if you were forced to type spaces as &#x20;...". Yes, WP can survive anything short of such absurd inconvenience. But that is no reason to refuse reforms.
Finally, jnestorius comments on intuitiveness. So have we all! But in the end, intuitiveness is not an intuitive matter. There is very little intuitive about ''...'' or '''...''', but they work. So might other markup, given a gentle push forward.
– Noetica♬♩ Talk 22:26, 21 January 2008 (UTC)
I agree completely with Noetica, and should like to add the following:
  • Although the underscore is indeed more intuitive than the double-comma, the latter is, nevertheless, much more intuitive than most other symbols, as it is restricted to the base of the line, much like an underscore; there are no dots or lines hovering above the commas.
  • True, more people with Internet experience are more familiar with HTML than with Wiki-markup; however, there are infinitely more people without any experience with markup. This ought to be taken seriously into consideration when judging what would be easier for editors to use.
  • The resemblance of the double-comma with a „ might indeed pose a minor problem, yet not nearly as great as one may imagine; the distinction in the edit box is quite clear, and if editors use the preview button (which is, of course, always recommended in every editing manual) they will immediately notice the effects of what they have typed; the position of hard spaces is also rather characteristic and quite different from wherever one might expect to find quotation marks. In my opinion, there is no obstacle here.
  • Finally, in respect with the date example, I agree that there is an error there (one which had slipped under my radar until now); there is no practice of hard-spacing a day with a month in a date. However, it is still perfectly valid to use a hard space between the first date and the connecting en-dash.
Waltham, The Duke of 21:09, 22 January 2008 (UTC)
Waltham is right, I think, that the similarity of „ and ,, is a minor concern – compared to the potential for confusion of '' and ", in some contexts of WP work. We have to remind ourselves of the relative frequency of these things. A hard space will be required orders of magnitude more often than „ . In the few articles that use „ an inline note could be supplied at the head, to alert editors if confusion is at all likely.
Minor it may be: but we hadn't noticed it, and it's great to have such a thing pointed out.
[Corrected contribution]– Noetica♬♩ Talk 01:23, 23 January 2008 (UTC)
Confusion between ,, and „ may be little (here and now), but choosing double comma for the no-break space makes it unavailable for other uses. (Obvious fact, but sometimes worth pointing out.) Such a future use might be entering „, if language-dependent replacement of " would not be implemented, but more ASCII character aliases as envisioned earlier were. — Christoph Päper 09:35, 23 January 2008 (UTC)
Thank you, Christoph. I agree: obvious facts should be on the table for discussion, so they are not neglected in the rush to address every last subtlety. I too had thought about unavailability, though not for „. Any system of coding, from the profligacy of hieroglyphics to the parsimony of binary, involves decisions so that what is important or common is given an easier representation than what is trivial or uncommon. I can't think of a character that needs reformed representation more urgently than the hard space. I know you are a crusader for other characters! I would be too, as I have said above, if Wikipedia were ready for huge changes. I'll just add this: the hard space supports many of those characters that interest you (and me), so that they sit properly with their adjacent text. Hence the privileged treatment some of us have given to the problem of the hard space. The difficulties with {{nowrap}} (see below) are yet more evidence that the whole thing has been neglected and misunderstood for too long – by developers of wiki markup, browsers, and HTML itself.
– Noetica♬♩ Talk 12:14, 23 January 2008 (UTC)
Amendments to the draft, and problems with {{nowrap}}

I have made amendments to the draft, prompted by two considerations:

  • Amendment 1. The date example has been disputed. MOS currently says this: "In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line." This is, quite properly, very general. On a reasonable reading it applies to dates (which have numerical and non-numerical elements). But since there are further contested guidelines for dates at WP:MOSNUM it seems better to remove that example from the draft. I have substituted "89 sq in – 3 sq ft". Which may look contrived (it is!) and unlikely (not necesarily); but it illustrates the sort of thing that can arise in real editing.
  • Amendment 2. I discovered that the behaviour of {{nowrap}} is not as documented at Template:Nowrap; I have therefore added this text to the draft, at Objection 4: "Currently, {{nowrap}} does not behave as specified in its documentation, since a space at the start or end of the enclosed text is rendered in HTML outside of that text, leading to unexpected breaks." This fact is of some interest for the proposal and the discussion here. See my detailed report and request for amendment at discussion for {{nowrap}}.

– Noetica♬♩ Talk 00:23, 23 January 2008 (UTC)

A point that I don't believe has been brought up is the handling of this markup within wikilinks. One might want to use a hard space in the name of a linked article, for one of the usual reasons. Could Mediawiki parse [[23,,Skidoo]] to link there without piping it as [[23 Skidoo|23,,Skidoo]]? 'Twould be nice. - JasonAQuest (talk) 19:18, 9 March 2008 (UTC)
This is a highly interesting proposition. Although I cannot think of any titles requiring hard spaces right now, it is reasonable to assume that there are. Pipe-linking is not a problem, of course, but any change that makes editing easier and removes code from the edit window is certainly welcome. If the double comma feature is enacted, I will definitely support such an idea, but I don't think it will be easily integrated into the main proposal. I believe that it will be better treated as... an afterthough. Waltham, The Duke of 02:50, 13 March 2008 (UTC)
It's not that the titles themselves require hard spaces, but that editors might wish to use them in the text of an article, and then link that text to an article. If they do so, the only reasonable interpretation of a double comma in a wikilink would be to treat it the same as a soft space (i.e. translate it into an underscore character). - JasonAQuest (talk) 17:23, 16 March 2008 (UTC)

Technical report: the nowrap template

As I mentioned above, there has been some action at discussion for {{nowrap}}. Woodstone, a key participant in the hard-space working group, has since joined me in exploring the behaviour of the template, and of the HTML code it generates. Here are our findings, and latest developments in documentation of {{nowrap}}:

  • x{{nowrap| TEXT }}y generates this HTML code:
x <span style="white-space:nowrap">TEXT</span> y
This is against expectations, since the spaces are forced outside. This anomaly has now been added to the documentation. We are informed by editor Random832 that it cannot be corrected without radical changes to the parser.
  • x<span style="white-space:nowrap"> TEXT </span>y is the expected code for the template to generate. But it too would be inadequate, because both Microsoft IE and Mozilla Firefox still allow a break before and after TEXT with this code.
  • x<span style="white-space:nowrap">&nbsp;TEXT&nbsp;</span>y also breaks in IE before TEXT, but not after it. This does not occur in Firefox.
  • x&nbsp;<span style="white-space:nowrap"><code>TEXT</span>&nbsp;y, quite remarkably, also breaks before TEXT in IE (but not in Firefox).[Correction: inadvertent <code> tag deleted from the code. See posts below.– Noetica♬♩ Talk 09:57, 25 January 2008 (UTC)]
Conclusion 1
The template {{nowrap}} is irredeemably quirky, and deficient for some purposes.
We might think it doesn't matter if spaces at the start or end of the included text are allowed to break. What are they doing inside in the first place? But there are situations in which we do want them inside. In fact, such a situation arose in the last few days, here at WT:MOS. That's how I made the lucky discovery that prompted my enquiries.
Conclusion 2
The code &nbsp;, along with markup that inserts it, is superior to {{nowrap}}.
Conclusion 3
The hard-space markup proposal should be supplemented and strengthened with these further facts.
We can do that some time later, perhaps.
Conclusion 4
Deficiencies in this template, and allegedly in the parser, suggest that template solutions to the hard-space problem generally will not work.
This is interesting, because we examined one such solution. It came second in our poll, in fact. Further research would be useful.
Conclusion 5
WP:MOS should alert editors to these deficiencies in {{nowrap}}.
Anticipating agreement on this obvious point, I'll make an addition right now.

Comments?

– Noetica♬♩ Talk 09:28, 24 January 2008 (UTC)

Pure shock, sir...
...and, thinking of the increased acceptance of the double-comma solution this would bring about... Glee... (Evil grin) Waltham, The Duke of 15:15, 24 January 2008 (UTC)
I can't agree that case #1 is "against expectations"; Wikipedia's general template markup documentation makes it very clear that whitespace between and around parameters and their values is ignored. I.e. x<span style="white-space:nowrap"> TEXT </span>y is not the expected output, if you absorb the templating system more fully. This has its minor downside, but it is generally pretty helpful for most cases. For example it, it's what lets us do:
{{WPBiography|
|class=Start
|priority=Low
}}
instead of:
{{WPBiography|class=Start|priority=Low}}.
(The readability/usability importance of this may not be clear until one uses a template with 27 parameters...) The principal downside is that occasionally one wishes that the spaces were interpreted as literals, and the workaround for that is to use &nbsp;.
Your second, "also breaks in IE before TEXT, but not after it", example: Well, what else is new? IE is just known to be severely broken. More than 300 (X)HTML and CSS bugs have been documented in it, and the ver. 7 "upgrade", while yes there were some security improvements, was mostly cosmetic plus addition of widgets (RSS parser, etc.); if you read the MS developer blogs and various other forums, it is clear that MS made a conscious decision to not f'ing bother fixing the CSS and other parsing bugs in the last long-overdue IE development round, despite it being clear that the most-needed IE fixes were precisely the ones they punted on. We (by which I mean web developers generally, not WPians in particular) cannot keep bending over backwards to account for IE's failures to follow the standards forever (and yes the abiguity of that phrase is intentional). If the result for MOS purposes is that some things will wrap in broken browsers, but will behave properly in standards-compliant browsers, then that's just fine. Inveterate, insistent users of IE are already used to having to mentally compensate for their preferred but weird browser's shortcomings, so this will be nothing new for them.
The third case – "quite remarkably, also breaks before TEXT in IE (but not in Firefox)" – is invalid markup, so who knows what would actually happen were it cleaned up. The tag order in that passage is: begin-template code nowiki span code /span /nowiki /code end-template; there is not only a missing /code, there is a span code /span /code overlap. With XHTML that broken, the results cannot possibly be predictable; different browsers have different failure compensation modes.
Hope that helps. — SMcCandlish [talk] [cont] ‹(-¿-)› 03:55, 25 January 2008 (UTC)
If I may "reconclude": Your conclusion 1 and 4 are incorrect with regard to there being something broken with the nowrap template or the template parser, and I remain neutral on conclusion 1's second point that the template may simply be deficient for some purposes (since I can't imagine all possible purposes :-) Conclusion 2: I've been saying that all along. Conclusions 3 and 5: Probably so, though I think these findings and the alleged deficiencies need to be seriously re-examined given what I've said so far. — SMcCandlish [talk] [cont] ‹(-¿-)› 04:01, 25 January 2008 (UTC)
Thanks very much, SMcCandlish. We have needed someone with sufficient knowledge to address template matters. A request at talk for {{nowrap}} was ignored. Some comments and queries for you, though. Your text in italics:
I can't agree that case #1 is "against expectations"; Wikipedia's general template markup documentation makes it very clear that whitespace between and around parameters and their values is ignored. I.e. x<span style="white-space:nowrap"> TEXT </span>y is not the expected output, if you absorb the templating system more fully.
The normal experienced editor's reasonable expectation is that a template will do what its documentation says it will do. This one did not, and that has now been acknowledged and rectified. The documentation for templates and the templating system as a whole is generally poor, and impenetrable to non-geeks. Is this satisfactory, when templates are supposed to be a service to all editors?
[...] The principal downside is that occasionally one wishes that the spaces were interpreted as literals, and the workaround for that is to use &nbsp;.
Well, yes. And in the present case, which is all about spaces, that should have been accounted for and pointed out. We could ask for greater clarity in the documentation. Question: would it have been possible for {{nowrap}} to use multiple instances of &nbsp; instead of span tags? If so, could the system be made to pick up a first or a last space and do that with them? After all, it seems to be able to identify them in order to drop them outside the span tags, yes?
Your second, "also breaks in IE before TEXT, but not after it", example: Well, what else is new? IE is just known to be severely broken.
That's certainly true. I wouldn't use IE except to test things. Relevantly for this whole discussion, in IE x&nbsp;–&nbsp;y and x&nbsp;—&nbsp;y will not break after the first &nbsp;, but will before the second &nbsp;. And x&nbsp;…&nbsp;y (preformed ellipsis) will not break at all. None of these will break at all in Firefox.
[...] If the result for MOS purposes is that some things will wrap in broken browsers, but will behave properly in standards-compliant browsers, then that's just fine. Inveterate, insistent users of IE are already used to having to mentally compensate for their preferred but weird browser's shortcomings, so this will be nothing new for them.
Perhaps. But we should remember that we write for all browsers, no matter which we use ourselves. Despite IE's serious shortcomings, it does seem to behave better with &nbsp; (at least breaking after a dash rather than before, as explained) than with {{nowrap}}. We should document this for editors, and take it into account, shouldn't we? To excuse ourselves on the ground that a major browser is a non-compliant "outlaw" seems a bit rash and unrealistic.
The third case "quite remarkably, also breaks before TEXT in IE (but not in Firefox)" – is invalid markup, so who knows what would actually happen were it cleaned up. [...]
So sorry. I input the code wrongly here and at talk for {{nowrap}} (fixed now), with a stray and unmatched CODE tag. The corrected code:
x&nbsp;<span style="white-space:nowrap">TEXT</span>&nbsp;y
Do you acknowledge that this is valid code that might turn up in attempts to circumvent IE's and WP's deficiencies? This code is what I tested, with the result that I report. And it is generated by:
x&nbsp;{{nowrap|TEXT}}&nbsp;y
So I still think there are more deficiencies in WP's existing options for the hard space than are acknowledged or documented. For the non-expert, it takes an extraordinary amount of time, cunning, and effort to hunt these things down. This just reinforces the need for better analysis in the first place: and better documentation, coding, and understanding of what a sound editing system demands. That is not being delivered – certainly not for the hard space, certainly not for most editors. Hence our attempt at reform. So far we have seen many invaluable comments here; but I have to say: I see nothing compelling against the proposed markup with ,,. They would have to be an improvement over the present arrangements, surely?
– Noetica♬♩ Talk 06:54, 25 January 2008 (UTC)[Amended contribution– Noetica♬♩ Talk 07:10, 25 January 2008 (UTC)]
Well, if we can't sort this out here or at Template_talk:Nowrap I might make some enquiries at WP:VPT. It's important for us to sort out just what these templates can and can't do. How is it, I ask, that a template can shift spaces but not convert them (to &nbsp;, say)? Can anyone help with an answer?
– Noetica♬♩ Talk 05:32, 28 January 2008 (UTC)

This process of development

The process of working on the hard-space proposal has been unusual. We set up a page in userspace (a subpage of my own userpage: User:Noetica/ActionMOSVP). Our experience, I think, has been positive: we were able to educate ourselves and each other, and keep to a system that appears to have been fruitful. We are not closing that page, but transferring discussion to here for now, before making the proposal even more public in the wider WP community.

Any thoughts, positive or negative, on that process? I think it's independently interesting.

– Noetica♬♩ Talk 03:24, 21 January 2008 (UTC)

Indeed, it is. Ignoring for the moment the possibility of a multitude of unchartered "working groups" and Wikipedia's mixed opinions on experts or expert groups, I like it. But if you expect the proposal to derive some credibility from the group's status, membership, deliberations, etc., it might have been helpful to start with a set of stated goals. The User:Noetica/ActionMOSVP archives imply that the proposal itself is the goal, but given the numerous alternatives considered, I doubt that was the case at the beginning. As things stand right now, I expect you're going to have to recapitulate the private discussions "in public", so it will be interesting to see how the working group members handle the concomittant frustration. But thanks for giving it a try! RossPatterson (talk) 17:32, 21 January 2008 (UTC)
Please see my message in the next section (item #1: idea about project page). Waltham, The Duke of 21:09, 22 January 2008 (UTC)
I think it would have been preferable to conduct the whole process here, with more users, a simpler structure, a lot less text, and a greater level of pro-active presumption with invitations to criticise. In my experience, relatively fast-moving, stratified democracy is the best way to garner expertise and opinion from a wide range of people without losing momentum. It did lose momentum, I'm afraid, and I found the page unnecessarily difficult and time-consuming to negotiate, when all I wanted was to be clearly directed—like a sheep—to the decisions already made, the issues that needed input, and the plans for action. Only early on when we were asked to vote on candidate codes was it easy to see what was going on and to contribute. Even then, it would have been simpler to ask people to list their first, second and third choices in one simple row separated by commas (4, 1, 5) and to sign once than to negotiate the table in the edit-box. Keep it simple and quick is my advice. We still don't know how/where/who further down the line, and it's this lack of a big-picture strategy that put me off. IMV, one-to-one legwork to produce options for where to take the proposal would have made a difference, not open-ended discussion lacking fine-grained goals and interim deadlines.
However, I support the proposal, thank Noetica for taking the initiative, and look forward to progress. Tony (talk) 09:05, 23 January 2008 (UTC)
Thank you, Tony. Interesting and useful to have your views concerning our experiment recorded here. I will not give my detailed response, though there is much to challenge in what I have just read. I'll wait for others to give opinions.
– Noetica♬♩ Talk 11:50, 23 January 2008 (UTC)
"Recording" my views wasn't uppermost in my mind; just responding to your call for feedback. I didn't see it as combative. Tony (talk) 23:00, 23 January 2008 (UTC)
Combative? I didn't see it that way either. You have indeed responded to my call for feedback, and I have thanked you. But in my assessment you raise some questions on which we disagree, and which it is not profitable to pursue right here, right now. Good to have a range of opinions recorded.
– Noetica♬♩ Talk 23:28, 23 January 2008 (UTC)
Enough with the "recording" idiocy, both of you; we are not at Abbey Road here. Focus on the subject, please. Waltham, The Duke of 15:18, 24 January 2008 (UTC)

How to promote the proposal

The working group would appreciate your thoughts on how to move forward with the completed proposal. Certainly your interest and help are important, for a start. We had thought Village Pump (proposals) would be a proper place to present it. But that may not be best. It needs a big vote of support, from editors who have studied it and have come to see the need for this simple change.

Suggestions?

– Noetica♬♩ Talk 03:24, 21 January 2008 (UTC)

In my opinion, this proposal is even more embracing than the rollback tool, for it concerns a markup: it is meant to be used by literally everyone, regardless of status, and as a part of the regular editing process. Therefore, I believe that it ought to receive maximum publicity. These are the steps I think we should take:
  1. Create a page in the project namespace, thoroughly explaining the proposal and the procedure by means of which it has emerged. The discussion on the proposal and any potential straw polls will take place there. The page shall, of course, be appropriately tagged; it might also have a shortcut.
  2. Leave messages in the Village Pump's Technical, Proposals, and Policies sections, referring to said page.
  3. Leave messages in the relevant Manual of Style talk pages: here, in dates and numbers, and in mathematics.
  4. Leave a note in the Community Portal's bulletin board calling editors to comment on the proposal.
  5. Leave a message in the Administrators' Noticeboard similarly calling sysops to comment.
  6. Create an entry in Centralized discussion regarding the proposal.
  7. Leave messages in the talk pages of all the relevant WikiProjects (ideas including the League of Copyeditors and the Punctuation and Typo projects).
  8. Leave messages in whatever other relevant pages' talk pages we can locate.
I do not find it necessary to ask an administrator to create a watchlist note; we could mention it somewhere, but if the proposal does gather momentum, someone will probably do it on their own accord anyway.
Anything I have left out? All this might sound slightly excessive, but, seriously, we are talking about a major change here; we need all the input we can get. Waltham, The Duke of 21:09, 22 January 2008 (UTC)
Perhaps seeking an article in the Signpost would effectively bring it to the attention of a large number of committed editors. Franamax (talk) 00:19, 23 January 2008 (UTC)
Indeed. However, it will probably be hard to gain more than a mention in the Signpost; a full article will be written if this becomes a story worth including, which will only happen if and when a lot of activity takes place. See what happened with the rollback debate: after the discussion, the poll, and the reactions, and only then, was the story published. Waltham, The Duke of 15:52, 23 January 2008 (UTC)
Now that I think of it, maybe this kind of treatment would be excessive; after all, this is just one of tens of such proposals being made every year (not to say hundreds). However, if we are to discuss it in the Village Pump (instead of creating a separate page in the project namespace), we probably ought to prefer the Technical section, as more relevant. Waltham, The Duke of 22:37, 23 January 2008 (UTC)
My experience of that is that the entry will soon be covered in a swamp of others, possibly without comment. Tony (talk) 22:58, 23 January 2008 (UTC)
Yes, Tony. Being swamped is the problem: just as the developing proposal would have been lost in noise if it had been pursued here, as experience shows for other such efforts.
Waltham, looking at the various pages of Village Pump, I don't think this belongs primarily in the technical area. There are certainly technical implications, but the immediate question is to do with policy: in general, the kinds of markup that WP should embrace, and then the specific suggestion for one change, regardless of the deep technical mechanisms involved.
– Noetica♬♩ Talk 23:40, 23 January 2008 (UTC)
  • No, Noetica, it could have been managed here, and experience has shown that reforms have been worked through successfully here. I'm not interested in the bickering though, so let's concentrate on moving forward the hard-space reform. Tony (talk) 23:59, 23 January 2008 (UTC)
Interesting to see your further opinion recorded, concerning what can and cannot be achieved here (and at WT:MOSNUM, perhaps?). I see no bickering, but sure: let's work on the job in hand.
– Noetica♬♩ Talk 00:09, 24 January 2008 (UTC)
Hey guys, do I detect an inability to play nice together? Tony, the best way to show you're not interested in bickering is to not bicker, especially in the immediately preceding sentence. Noetica, if you see no bickering present, best not to introduce your own example. Did either of your most recent posts here get us farther toward implementing double-comma? Just asking. :) Franamax (talk) 00:17, 24 January 2008 (UTC)
No, they didn't; Interesting to see your rejoinder recorded here, Noetica. What else are we going to record? Tony (talk) 00:21, 24 January 2008 (UTC)
Tony, you are aware that every time you click "Save page" the text you entered is recorded in perpetuity? That's how wikis work and it's a correct statement, I hope you're not accusing Noetica of making a correct statement. Are you trying to pick a fight? Maybe this isn't the best place to do so. :) Did that last post help with the double-comma proposal? Let's cool down a bit. :) Franamax (talk) 00:34, 24 January 2008 (UTC)
Or are you being combative now, Franamax? I just object to the continual explicit framing of my contributions as recordings, rather than current engagement in discourse. The mild put-down is not helpful, and nor is your "recording". For example, I could frame your entries as "html code", although even that would not carry same negative connotation as "recording". Understand? Tony (talk) 00:54, 24 January 2008 (UTC)
(e/c I think this is the right spot)Umm, I guess the short answer is: no I don't understand :) I'm certainly not trying to be combative, I was actually trying to defuse a potential off-topic fight I saw developing. Obviously I've failed in that effort, but I don't mind failure, in fact I've honed that skill throughout my life. :) I'll include my recent posts in the question "are we advancing the subject of the thread?", the question applies to all of us, and I'll offer apologies if I've offended you. Franamax (talk) 01:21, 24 January 2008 (UTC)
For the record, I say (and said) that it is a Good Thing to put useful and relevant opinions on record. We are all doing that. I asked for that, more or less. Tony, you think it is a put-down to label a contribution as an act of recording? I didn't see it that way. Sorry if you were offended. I simply wanted to record that I disgree with you on some matters, and also that I don't want to engage with you about those, at this stage.
– Noetica♬♩ Talk 01:07, 24 January 2008 (UTC)
For the record, I should like to add that you are all being ridiculous, and amusingly so, too. (chuckles) Seriously, can we go back on-topic, please? I fail to locate the reason for this distasteful digression.
Now, do we, or do we not, agree that this page is suitable enough to serve as the main forum of discussion for the hard space proposal? Please answer this question, and no other. Believe me, it is for the best. Waltham, The Duke of 15:06, 24 January 2008 (UTC)
I don't find it amusing. I hope that, having insulted each other, Noetica and I can very soon move on and resume our very productive friendship. Tony (talk) 10:23, 26 January 2008 (UTC)

{{nowrap}}, {{nowraplinks}} and {{nowrap begin}}

As a webmaster and Wikipedia editor I have worked a lot with line breaking issues. In the end I created {{nowraplinks}} and {{nowrap begin}} and their helper templates to solve/handle the problems with {{nowrap}}. (I just wanted to mention those since most of you don't seem to be aware of them.)

I took a look at the suggestion above to use the wikimarkup 34,,kg to mean 34&nbsp;kg and it seems to me it is a good suggestion. Although as others have pointed out it has to be discussed with the other language wikipedias too of course, especially those languages that use the low double quotation mark: „Quoted text“

Of course what really is needed is that the World Wide Web Consortium (W3C) finally accept and standardise the old well working and easy to use HTML markup <nobr> + <wbr> + </nobr>.

--David Göthberg (talk) 10:05, 26 February 2008 (UTC)

Thanks for joining the discussion, David. I see that you have also commented at Template_talk:Nowrap. As you can see, the discussion has paused for a while. The whole matter of hard spaces has been argued over at length in another context, at WT:MOSNUM. That discussion centred on extent of use rather than means of inputting. Since it grew long and heated, I suggested that the whole thing be put aside for now. But we should resume it soon, in a more integrated form.
I wrote (see above):

Well, if we can't sort this out here or at Template_talk:Nowrap I might make some enquiries at [[WP:VPT]]. It's important for us to sort out just what these templates can and can't do. How is it, I ask, that a template can shift spaces but not convert them (to &nbsp;, say)? Can anyone help with an answer?

This was about spaces at the start or finish of the string enclosed in a {{nowrap}}. The spaces are dropped outside when the HTML is generated. If that can be done, why can't such a space be converted to a &nbsp;? I'd be grateful if you would answer that!
I note your remarks about reform of HTML itself. But let's not wait for that! As for „ , surely at German Wikipedia for example they don't use two commas to input that character. And ,, and „ are surely no more confusable than '' and " are. We all live with these, all the time.
– Noetica♬♩ Talk 22:26, 26 February 2008 (UTC)
Well, it is not the {{nowrap}} template itself that move the leading and trailing spaces outside the span-tag it creates. It is the MediaWiki rendering that does it. And from what I read and experienced that is the default behaviour for MediaWiki rendering for all things that internally in MediaWiki rendering uses span tags, such as bold and italics too. I am not sure if that is a good or bad default behaviour for the span-tag rendering for bold and italics, but yes in the nowrap case it seems to be a bad thing. But note if you need more control we now do have the {{nowrap begin}} + {{wrap}} + {{nowrap end}} templates. Simply enclose the whole line of text in {{nowrap begin}} + {{nowrap end}} and then insert {{wrap}} where you want to allow line breaks.
Currently we can not process and convert characters in input to templates, thus converting spaces to &nbsp; is not possible from just template programming. To make that possible the MediaWiki functions for template programming would have to be extended with a whole new set of string handling functions. Again, it seems to me the situations were you want spaces converted to &nbsp; is the same situations where I would currently use {{nowrap begin}} + {{wrap}} + {{nowrap begin}}. (Yeah I know that might in some cases look very ugly when we edit the pages, but at least it is clear.) But yes, using ,, for &nbsp; would in many cases be a much nicer solution and give the editors much more control.
And I more than agree that ,, is a good notation for &nbsp;, see at least in the three web browsers I have I can see the difference between ,, and „ but I can not see the difference between '' and ".
Also, the ,, notation would make it easier to use hard spaces which probably would make people use them more often, which I think would be a good thing.
By the way, as you already have seen this kind of suggestion causes a lot of discussion and needs a lot of examples and explanations. You already have spread this discussion and examples over many different pages. Therefore I suggest the same as someone suggested above, move all these examples and discussions to a single page + talk page. You can see how we did with for instance the article message boxes standardisation project. We put the examples and draft write ups at Wikipedia:Article message boxes and put all discussions at Wikipedia talk:Article message boxes. Then we advertised that all over Wikipedia. That would also make it easier to get people from other language Wikipedias to join in since we could ask them all to come to that one single place. You kind of started that by using User:Noetica/ActionMOSVP, but if you put it on a more official address instead of in user space it would be more inviting. Come to think of it, even more correct would be to move all this to Wikimedia Meta-Wiki.
So I suggest you move all this to say meta:Wikimarkup for hard spaces and its talk page. And I mean literally move it as in cut and paste all the discussions from the different pages (including this page) to that talk page. And of course put a notice in the old pages: "This discussion has been moved to meta:Talk:Wikimarkup for hard spaces." If you don't want to go as official as using Meta-Wiki then at least move all this to say Wikipedia:Wikimarkup for hard spaces and Wikipedia talk:Wikimarkup for hard spaces.
--David Göthberg (talk) 07:39, 27 February 2008 (UTC)
Thanks for your thoughtful response. I'll think through all that you have said. We will take this up again, and I'll advise you when we do so. I look forward to your continued involvement, and your very useful contributions.
– Noetica♬♩ Talk 09:35, 27 February 2008 (UTC)

Discussion of markup for hard spaces to continue

There has been a trickle of continued contributions here in recent times, and some heated commentary earlier about whether and when to use hard spaces at all. I myself have been happy to wait for these, and to accumulate all that we can from this exposure of the issue here at WT:MOS. In about ten days I want to open up User:Noetica/ActionMOSVP again, for us to digest some of these suggestions, and so improve our full proposal. All editors will be very welcome to join in, as always. The mood here and at WT:MOSNUM has been difficult lately, so I think we may then need to move this forward at yet another place, as David Göthberg proposes above. As secretary to the group working on this I'll notify everything here.

–⊥¡ɐɔıʇǝoNoetica!T– 22:07, 11 March 2008 (UTC)

With the risk of sounding harsh (but I say this since I like your proposal and want it to succeed): This talk page (Manual of Style) is not really the place to discuss your proposal, among other things since it will get mixed up between many other unrelated discussions. (And it will disturb those other discussions.) And neither is User:Noetica/ActionMOSVP since it is in your user space. So you really should move this proposal discussion to say Wikipedia:Wikimarkup for hard spaces. As long as you don't move it to an official page you are seriously hampering the discussion. Trust me on that. We succeeded with the Wikipedia:Article message boxes and I think that in many senses was a much bigger project/proposal than your "Wikimarkup for hard spaces".
--David Göthberg (talk) 23:37, 11 March 2008 (UTC)
I think Noetica is just trying to be cautious here and not "go public" with a proposal that has easily pokable holes in it. That said, I'm thinking MetaWiki might not be a bad place to go next. (And of course, it's easy enough to make the feature optional for different language wikis). Franamax (talk) 00:10, 12 March 2008 (UTC)
Thank you, Franamax.
And thank you too, David. David, if you had followed all of the dismal history of this matter you might hold back from such a seemingly harsh judgement. Those of us involved in User:Noetica/ActionMOSVP did everything we could here before starting up that page; we sought comments on every move, and reported here zealously. We sought discussion of all available options; and at the time, no one so much as hinted at the move you have since suggested. I myself volunteered my services, with no dissent from my going on to facilitate as I did. Some found the excess of consultation excruciating! And hard work it was for us all.
The result is a thoroughly researched proposal. No one pretends that it is a consensual one; but to get this far we needed to act as we did. For the third or fourth time now, thank you for your very useful input! I look forward to more. We will move things elsewhere, as you have suggested and as I agree we must. Meanwhile, we'll polish the proposal we had developed, and present that to a new forum.
(Call any of that "hampering"? Some of our reflex enemies here will seize on that with glee!)
 
: )
 
I really do look forward to working with you on this. Please let us tidy things at the page I made, and then we can proceed. For reasons to do with The Real World, I have to wait ten days now.
–⊥¡ɐɔıʇǝoNoetica!T– 01:06, 12 March 2008 (UTC)
[Revised above, and re-indented the following after edit conflict.–⊥¡ɐɔıʇǝoNoetica!T–]
(Note: this was written before Noetica's reply was posted—check the times.) 01:05, 12 March 2008 (UTC)
Naturally; an entire namespace (Portal) is restricted to the English Wikipedia, surely the same thing can be done for a lousy character.
As far as the venue is concerned, you know that I support the centralised format: one well-advertised page where the proposal can be presented properly and in depth, with a talk page for all the discussion about it. I have no great problem with using Meta space for the proposal, although this will limit participation on the part of the English Wikipedia, which I consider crucial in these early stages. Don't forget that most Wikipedians have no account in Meta (including me). My idea is to use Project namespace, discuss the idea, and if it is approved by the community and the developers, the feature can be activated for us and the proposal moved to Meta, to be taken from there to the other Wikipedias, which will decide individually.
Finally, I don't believe the holes are as pokable as some might think, knowing that we have already submitted the proposal to a fair degree of scrutiny and most counter-arguments have been successfully rebutted. And it's not like we'll go to battle unprepared... Waltham, The Duke of 01:01, 12 March 2008 (UTC)

I started actively editing on Wikipedia in early December, and I saw this new little proposal to figure out new markup for no-break spaces, and I thought, "Neat, what a simple, technical, non-controversial issue, what a perfect little project to start on before I know much about Wikipedia". Ouch!

Our current long-running conversation at WT:Layout on the subject of ordering of end sections may contain some helpful hints on how to make progress with no-break spaces ... I would link it, but it's long and most of it isn't relevant, I'll just copy some of my comments here. My fear about no-break spaces before was that it would turn into a conflict that never got resolved and never went away (and I admit that I got too pushy at various times, trying to avoid that fate), but we have a new weapon: people are getting more serious about Wikipedia 1.0, which will be a (largely) printed version, and people are more sympathetic to look-and-feel issues (possibly including no-break spaces) when we're trying to make a printed encyclopedia look nice. And that might get us past the opposition at Wikia ... we have to look nice on paper, they don't, so as the Duke points out, maybe the techs can apply this markup just to Wikipedia. Anyway, here's my take on a similar issue from WT:Layout, feel free to cherry-pick any of these arguments that might be helpful.

When printed sections of Wikipedia's Version 1.0 come out, Wikipedia will get even more criticism from journalists and publishers who feel that their place in the world is being threatened. TV news and newspapers prefer to criticize style over substance, so the look-and-feel of the printed Wikipedia is likely to be very important to Jimbo and the Foundation ... and it would be a matter of pride even if there were no criticism at all. - Dan

Any disagreement with Rlandmann's suggestion to put a message on the talk page of every wikiproject? (That's a huge number btw, there are for instance around 160 active science and tech wikiprojects and more inactive ones...could a bot do this? Do we want to post the notice other places as well?) - Dan

I may be missing something, but hasn't everyone made their points already? Isn't there consensus to gather information and get on with it? If we put something about "order of end sections" on a bunch of wikiproject talk pages and other places besides, people are going to think the issue is too narrow and accuse us of spam. We can get more done at once, and get a better reception, by giving a link instead of an argument, "Go to X page to give your input...", and making the subject a bit more widely relevant, so first we should invite people to a page to make their case for which other questions are also "printed look-and-feel" issues ... perhaps at Village Pump (misc). - Dan
- Dan Dank55 (talk) 15:59, 12 March 2008 (UTC)

Another bit I'm copying over from WT:Layout: On second thought, it wouldn't hurt to ask first how widely we should ask around! Lots of people have been flamed for being too spammy on the one hand or not notifying a wide enough audience on the other hand, I'll go ask over at WP:VPP what the target audience is, and whether WP:VPM or WP:VPP is better for discussions that are part policy and part not. - Dan Dank55 (talk) 20:15, 12 March 2008 (UTC)

New prohibition against regionally variant terms in articles

See the archived discussion Wikipedia talk:Manual of Style/Archive 92#"Press up" and "Push up:" Are articles limited to one country's term?. In a long duration sub-3RR edit war at Press up there has been disagreement about whether it is permissable to use at all (other than mentioning it in the introduction) any term which is a regional variant for the term used in the article's title, or the main term used in the article, where there is variation between English-speaking countries. See the talk page of Press up, in the section "Sub-3rr edit war." The North American term "Push up" has been repeatedly removed and replaced by the British term "Press up" in photo captions of a U.S. Marine doing the exercise with the argument that WP:ENGVAR does not allow any variation of terminology. The WP:ENGVAR section of the manual of style had been cited to justify the numerous reversions in Press up which removed any use of "push up." I pointed out the WP:ENGVAR section of MOS does not prohibit use of a variant regional term, that it only disallows variation of grammar or spelling. Matt Crypto recently changed the Manual of style [1] to disallow such variation of terminology, in addition to these previously disallowed variations of grammar and spelling. I reverted to the previous version of the MOS because I feel such a restriction should first arrive at consensus here on its talk page. The archived discussion cited above did not support the recent change. In a number of articles, one country's term has gained the title, and is the main term because of priority in editing the article, or for other good reasons, but the other country's term is allowed to occasionally appear where appropriate. Examples where Matt's new rule would allow large changes in the form of purging all but the main term are the article Rooster (U.S. term) where the British term "cock" appears many times, the article Eggplant (U.S. term) where the British term "aubergine" appears many times, the article Elevator (North American term) where the British term "lift" appears many times, the article Windshield (U.S. term) where the British term "windscreen" appears numerous times, and the article Wrench (North American term) where the British term "spanner" appears several times. I expect there are other articles where the British term is the main one for the article but other regions' terms are also allowed to appear , such as Maize (term used in Britain) where the U.S, Canadian and Australian term "corn" appears several times. This change to the Manual of Style would indeed make it easier to keep "push up" from being used in a photo caption showing a U.S. Marine doing the exercise in the Press up article, but it might be a license to similarly purge regionally variant terms from numerous other articles, and therefore deserves a careful examination here. Edison (talk) 08:09, 2 March 2008 (UTC)

I for one feel that the situation has become silly. However, it is complex. For consistency and style, an article shouldn't mix up equivalent terms willy-nilly, whether they're regional variations or general synonyms. However, in a caption or section which clearly applies more closely to one term, it's sensible to switch for that section or caption (or whatever). This is especially obvious if there's a quote using that variation. SamBC(talk) 12:30, 2 March 2008 (UTC)
The reason for ENGVAR is two-fold. Anglo-American edit wars are silly and unproductive (and implicitly discourage part of the English-speaking world from editing; anyone can edit, remember?). On the other hand, flipping back and forth from British to American without a good reason can be disconcerting to the reader. (One such is noting the existence of two terms, as the article does.) Here there is a reason, and I think a good one; U.S. Marines doing press-ups is also disconcerting to the reader; if it were not, this controversy would never have arisen.
I have tried putting "push ups" in quotes, as the dialect local to the picture; will that settle it? Septentrionalis PMAnderson 16:53, 2 March 2008 (UTC)
Would it be equally appropriate to put "cock" in quotes in the Rooster article or "lift" in quotes in the Elevator article? This style guide should apply to all articles equally. Edison (talk) 01:48, 3 March 2008 (UTC)
Yes, of course, provided we are preferring to an obviously and solely British usage; if we have a picture of the lifts to the London Underground, for example, I would not even use quotes in the caption. Septentrionalis PMAnderson 16:46, 3 March 2008 (UTC)

Heh - should be "Press-up" anyway, if it's BrE, with the hyphen. Just to be annoying ;) Carré (talk) 09:30, 3 March 2008 (UTC)

Even the "push up" in quotes has been reverted out of the Press up article with the rationale that no instances of the regional variant are allowed (in that one article, at least.) That is why it is important to get a consensus here either that the non-title regional variant term is strictly forbidden (as has been the practice in Press up) or that it is allowed within reason, as has been the practice in the numerous other articles cited above. Anything which causes passions to rise as this has in a few articles is not as silly or trivial as it may seem. Set a guideline and then have it apply equally to all articles. Edison (talk) 19:33, 3 March 2008 (UTC)
Well, there certainly seems to be no consensus for that interpretation here, at least. I say that alternative terms should be allowed within reason. How much is reasonable is for each article to determine but "none at all" is probably never reasonable. Especially where the two terms are so darn close to one another... SamBC(talk) 22:17, 3 March 2008 (UTC)
As a data point, I would like to note how we have the article on Airplanes (or Aeroplanes) at Fixed-wing aircraft. There's certainly no valid basis for rejecting one regional term in favor of another one across the entire encyclopedia. The only reason we have articles titled Press up, Gasoline, etc, is that there is no ambivalent title available (and not for lack of trying) as there is for fixed-wing aircraft. —Random832 20:00, 3 March 2008 (UTC)
Following this side point, why not have the main article for that one at "Petroleum spirit", I thought that was a technical, non-regional term? But lets not get sidetracked. SamBC(talk) 22:17, 3 March 2008 (UTC)


I have set up a straw poll at Talk:Press up#Straw poll, with four options. Septentrionalis PMAnderson 23:46, 3 March 2008 (UTC)

Vague proposal

Given that this strange and frustrating situation has occured, is it not perhaps worth clarifying the guidance to indicate that this does not mean that articles must religously and strictly stick to one form of a term, especially where that term is (used for) the subject of the article? SamBC(talk) 15:19, 4 March 2008 (UTC)

WP:ENGVAR already permits exceptions. A general point on Consistency within articles like
Each article should generally be consistent within itself; it should not change from one variety of English to another, one form of citation to another, or one stylistic choice to another, unless there is good reason to do so. Arbitrary shifts will be disconcerting to readers, who will look for reasons.
would permit most of calls for consistency to be subsumed, which would shorten and simplify this document. Septentrionalis PMAnderson 18:22, 4 March 2008 (UTC)
In the case in point, Press up, WP:ENGVAR has been cited as justification for refusing to allow a caption to say a U.S. Marine is doing a push up, or that Paddy Doyle did the most back of the hand pushups in one hour, cited to Guiness Book of World Records [2]. If the reference calls them pushups, it should be permissable to use that term in the article. Edison (talk) 21:48, 5 March 2008 (UTC)

Edit warring is back

Two users seem to be entering a new revert war [3] [4] [5] over whether the term 'push up" can be used in the Press up article in a caption of a U.S. Marine doing said exercise. Any suggestions how to resolve this in light of the above discussion? Edison (talk) 03:17, 13 March 2008 (UTC)

One of the users in question seems to be wilfully defying what seems to be consensus in terms of interpretation of ENGVAR. If they won't listen to reason, perhaps time to escalate somehow? SamBC(talk) 21:10, 15 March 2008 (UTC)

Where is the change in spelling out nine to ten?

The verbosity here is a killer, and there is (as yet) apparently no attempt to summarize changes to long-standing guidelines so that others will be in the loop. Will someone kindly point me to the part of the discussion that resulted in a change to the spelling out of single digits only, from nine to ten, and the consensus for that change to the long-standing guideline? Thanks, SandyGeorgia (Talk) 21:57, 4 March 2008 (UTC)

Sandy, the verbosity may be a killer. But so is any simplistic approach to complex or contentious issues. Discussion is done with words; and sometimes many are needed, especially when editors here ignore what is plainly said or asked the first time.
I have called for a register of MOS changes to help all editors keep track, and especially to help with your FAC work. My suggestion was met with stony silence. (Few enough words for you?) The issue of a register may be dealt with at WP:MOSCO, when that page is more developed.
There has been no substantial change concerning figures or words for numbers. PMAnderson has altered some details, that's all. But the whole thing is disorderly and complex. There should be changes, so that your work and everyone else's will be helped. Let's hope we can negotiate a genuine and rational guideline for this. And then for centuries, also.
– Noetica♬♩ Talk 22:33, 4 March 2008 (UTC)
OK, so 10 is still a digit, and nine is spelled out? Thanks, Noetica. If the goal of some here is to kill MoS via verbosity, it may succeed. SandyGeorgia (Talk) 22:36, 4 March 2008 (UTC)
The guideline is not that simple, in fact. A pity it can't be! But there must be exceptions to any edict so draconian as that.
Kill MOS? Certainly not my goal! I want straight and respectful discussion, towards rational, simple, suitable guidelines. Hard to get such discussion, with many words or few.
– Noetica♬♩ Talk 23:23, 4 March 2008 (UTC)

Yes or no: can someone please point me to when, where and why the boundary between nine and ten changed (from the previous wording):

In the body of an article, single-digit whole numbers (from zero to nine) are given as words; numbers of more than one digit are generally rendered as figures, and alternatively as words if they are expressed in one or two words (sixteen, eighty-four, two hundred, but 3.75, 544, 21 million).

Thank you, SandyGeorgia (Talk) 23:54, 4 March 2008 (UTC)

Genuinely sorry, Sandy. The text was indeed changed on 24 February by User:Centrx, in this edit, from this text:

In the body of an article, single-digit whole numbers (from zero to nine) are given as words; numbers of more than one digit are generally rendered as figures, and alternatively as words if they are expressed in one or two words (sixteen, eighty-four, two hundred, but 3.75, 544, 21 million).

To this text:

In the body of an article, whole numbers from zero to ten are spelled out in words; numbers greater than ten may be written out if they are expressed in two or fewer words (sixteen, eighty-four, two hundred, but 3.75, 544, 21 million).

Centrx's edit summary: "Use previous language, which is more accurate and concise".
Of course, the text is not more accurate, since it is not strictly clear what the boundary is any more. (Is Centrx American, and therefore likely to express an inclusive range like this: whole numbers from zero through ten? I don't know!) I trusted the edit summary, which we sometimes cannot do: so I did not know that the substance was changed.
There was no consensus for that change; I'll now restore the wording that we had.
Centrx, please don't do that again.
– Noetica♬♩ Talk 03:49, 5 March 2008 (UTC)
So I'm not entirely crazy :-) Thanks, Noetica; I thought I was blind or missing it among all the verbosity. It was another one of those "gotchas" that was getting me at FAC. SandyGeorgia (Talk) 03:55, 5 March 2008 (UTC)
No problem, Sandy. It took me a long time to track down that rogue edit. It just highlights the need for big reforms like a register of changes, doesn't it?
May your words be few but heeded. :)
– Noetica♬♩ Talk 04:06, 5 March 2008 (UTC)
welllll ... when a basic, common, used-every-day sorta thing (like the boundary between spelling out numbers and digits) changes, we need to know about it at FAC :-) Thanks again. No matter how much I tried to get through, um, more of the usual from the usual, I couldn't find a consensus or discussion for that change on this page :-) SandyGeorgia (Talk) 04:11, 5 March 2008 (UTC)
Since that barrier is both disputed (discussions above have argued for nine, ten, and one hundred as the upper bound of mandatory words) and permeable, in both directions, in special situations (sentence boundaries, a function other than counting discrete objects), it would be better to rephrase. FA should not be imposing any rule, but considering specific situations. Septentrionalis PMAnderson 02:04, 7 March 2008 (UTC)
So why not make ten and 10 both acceptable? Anderson, it's "boundary", not "barrier". Tony (talk) 11:25, 7 March 2008 (UTC)
Depends on the vehicle of the metaphor; see potential barrier. Septentrionalis PMAnderson 16:47, 7 March 2008 (UTC)
  • As for the substance, 10, ten, 9, nine, 1, one are all acceptable under the right circumstances; a careful writer may use 9 where he would not use 1, and 10 where he would not use 9; but that is why we should indicate the general tendency, with sample "rules", rather than pretending to legislate. Septentrionalis PMAnderson 16:47, 7 March 2008 (UTC)

Where is the change in spelling out ten to nine?

Will someone kindly point me to the part of the discussion that resulted in a change to the spelling out of numbers up to ten, to spelling out single digits only, up to nine rather than to ten, and the consensus for that change to the long-standing guideline?

Rhetorical question, of course. I've already found the answer as pointed out #Lack of jurisdiction above. It was the real undiscussed change of a longstanding guideline. Gene Nygaard (talk) 17:12, 7 March 2008 (UTC)

Wrong as usual, Gene. And wantonly careless. Interesting how you select your "facts". Without trawling through all of the archives to demonstrate how conscientiously Tony has discussed and consulted on such matters, I refer interested editors to this section of WT:MOSNUM (yes, that is MOSNUM!). Since you have perpetrated such a slander, Gene, I reproduce parts of the section here. Sorry if that seems to take up too much space, but the facts need to be shown clearly. (I add bold and underlining for emphasis):

[Tony initiates discussion; section header:] Proposed revision of "Numbers in words"

I don't understand the title. Please provide feedback on this new version. Don't you all think it's time to bite the bullet on "billion"? (Except that it doesn't quite belong under the new title.) Should there be guidance on hyphenating spelled out fractions? I've added something, and I'm unsure about it. And what about hyphens in numbers such as "twenty-four"—mandatory or optional?

...

EXISTING

Numbers in words

*Whole numbers from zero to ten should be spelled out as words in the body of an article. Use numerals in tables and infoboxes.

*Numbers above ten may be written out if they are expressed in two or fewer words, except in tables and infoboxes. Example: "sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million".

*Proper names and formal numerical designations should instead comply with common usage. Example: Chanel No. 5, 4 Main Street, 1-Naphthylamine, channel 6.

*Within a context or a list, style should be consistent. Example: "There were 5 cats, 12 dogs, and 32 birds" or "There were five cats, twelve dogs, and thirty-two birds", not "There were five cats, twelve dogs and 32 birds".

*It is considered awkward for a numeral to be the first word of a sentence: recast the sentence or spell the number out.

*Fractions standing alone should be spelled out unless they occur in a percentage. If fractions are mixed with whole numbers, use numerals.

...

NEW

Spelling out numbers

General rule

*In the body of an article, single-digit whole numbers (from zero to nine) are spelled out; numbers of more than one digit may be spelled out only if they are expressed in one or two words ("sixteen", "eighty-four", "two hundred", "twenty million" but "3.75", "544", "21 million"). Many people prefer all multi-digit numbers to be expressed generally as numerals, within the bounds of the exceptions below.

Exceptions

*Dates and times.

*Numerals that open a sentence are spelled out; alternatively, the sentence can be recast so that the number is not in first position.

*In tables and infoboxes, all numbers are expressed as numerals.

*Within a context or a list, style should be consistent (either “There were 5 cats, 12 dogs and 32 birds” or “There were five cats, twelve dogs and thirty-two birds”, not “There were five cats, twelve dogs and 32 birds”).

*Fractions are spelled out unless they occur in a percentage or with an abbreviated unit ("3.5 mm", “⅛ mm”) or are mixed with whole numbers.

...

*Proper names and formal numerical designations comply with common usage (Chanel No. 5, 4 Main Street, 1-Naphthylamine, Channel 6). This is the case even where it causes a numeral to open a sentence, although this is usually avoided by rewording.

...

[[User:Tony1|Tony]] 04:47, 12 July 2007 (UTC)

I have no objection other than the one you probably read under the previous heading #Contradictions II. Nobody is arguing that 0-10 should always be expressed as words, so that rule should mention that there are exceptions. Art LaPella 05:03, 12 July 2007 (UTC)

I didn't read that previous entry, actually. Um ... can you be explicit as to your objection? I don't think this new version changes much WRT the ten/11 boundary for spelling out numerals, does it? If I could have it my way, I'd insist on numerals above nine as the norm, but I think too many people would object. Am I right?

So we need to know what change you'd require for this new version to have your total support. [[User:Tony1|Tony]] 09:11, 12 July 2007 (UTC)

...

*Looks good to me. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 14:50, 12 July 2007 (UTC)

...[suggestions from User:Jimp]...

*Jimp, I like your suggestions; I've tweaked and incorporated them. Please note:

(1) I've stuck my neck out by changing the ten/11 boundary to nine/10, because it's so simple to conceive the spell-out-single-digits rule. Happy to hear objections on that.

(2) "What does it matter what editors prefer"? It's a polite way of strongly recommending a usage without making it mandatory.

...

[[User:Tony1|Tony]] 02:09, 14 July 2007 (UTC)

...

Interested editors can see the whole comprehensive, public, and inclusive discussion for themselves, if they like.
The conclusion is inescapable: Tony's continued attempts to bring reason and reform to MOS, MOSNUM, and related pages have been consultative and consensual. (So, by the way, have mine. So have those of several others.) Editors like Gene Nygaard and Centrx, on the other hand, have typically not consulted, and have sought to reinstate old and superseded guidelines, with the risk that hard-won consensus will be subverted.
Editors should beware of Gene Nygaard's glib assertions, and look to the hard facts concerning our efforts at consensus-building by checking the archives.
–⊥¡ɐɔıʇǝoNoetica!T– 00:10, 8 March 2008 (UTC)
Okay, you've convinced me it was discussed, and it had some support. I wasn't about to try to dig trhough 108 archive pages to see if it had been. Gene Nygaard (talk) 00:56, 8 March 2008 (UTC)
This insulting response is mentioned above, at #Lack_of_jurisdiction. Please stop fragmenting the discussion. In fact, let's just drop this futile and slanderous exchange. And then perhaps you can set about fixing the damage to WP:MOSNUM that you have been party to, Gene Nygaard.
–⊥¡ɐɔıʇǝoNoetica!T– 05:16, 8 March 2008 (UTC)
That discussion has nothing about "numbers of more than one digit are generally rendered as figures"; it does not use the terms "figure" or "given as"; and the trend of the discussion is that "ten" ought to be the maximum rather than "nine". —Centrx→talk • 20:57, 9 March 2008 (UTC)
Centrx, your edit summary on 24 February purported to be about wording, but you changed the substance. You changed the substance without any discussion, anywhere. Your edit was reverted for that reason, basically. Even setting aside substance, your wording was no improvement, and also was not discussed!
The "trend of the discussion" was not, as you claim, that the boundary should be between 10 and 11. One editor said, as the complete last entry in the section, "ten/11 is not at all arbitrary: ten is the greatest number childrens may count on their fingers. After "ten" begins the abstraction of the number." That was User:Taxipom, who took no part in the discussion until then. Jimp had said, in argument against it, that it was "a seemably arbitrary choice". A very limited point, which got a limited and isolated answer. That's all!
Don't allege a trend on such a flimsy basis, Centrx. And if you won't discuss things lucidly on these talkpages yourself, don't carp at those who are committed to doing so. I remind you yet again (since you seem to need repetition): you edited on a key issue without ANY discussion, and you therefore caused the present difficulties.
I must now resist repeating things to you though, and having any discussion with you. It has no good effect, and takes up space and valuable time.
–⊥¡ɐɔıʇǝoNoetica!T– 21:32, 9 March 2008 (UTC)
Do you have any objection to the other changes? —Centrx→talk • 22:59, 9 March 2008 (UTC)
Yes I do. Wording is not as important as substance, but your wording was not good. We (including you) had been talking about just this matter in connection with centuries; and then we began a discussion of the entire subsection on numbers as figures or words. Some of us thought that should be revisited, at least to enable a rational dialogue about centuries. PMAnderson and I were talking about a new draft. But that cannot continue under present circumstances, as I note at the relevant section of this page.
The proper procedure, as you should know, would be to leave the guideline as it is right now, and as it was established by due discussion earlier, then join the conversation about any changes. But that conversation is stalled, for now.
–⊥¡ɐɔıʇǝoNoetica!T– 23:36, 9 March 2008 (UTC)
How is "single-digit whole numbers (from zero to nine) are given as words" better than "whole numbers from zero to nine are spelled out in words"? Why shouldn't examples be italicized to distinguish them from the mainstream text? —Centrx→talk • 23:46, 9 March 2008 (UTC)
What have italics got to do with this? Your undiscussed edit did not affect italics at all!
But this is a conversation we can have when you and Gene Nygaard have restored normality and stability by getting your undiscussed altered guideline at WP:MOSNUM reverted, so that the guideline there is consistent with the established guideline at WP:MOS. And see to it that WP:MOSNUM is unprotected and editable, OK? Then we can all work through the whole matter, in a properly named section either here or at WT:MOSNUM. Fragmenting the discussion just complicates the issue, and alienates editors who might be interested – no way to get durable consensus.
–⊥¡ɐɔıʇǝoNoetica!T– 00:05, 10 March 2008 (UTC)
Italics: [6]. We do not need to wait to discuss changes. If you have objections to an edit, explain them or improve the edit. —Centrx→talk • 01:07, 10 March 2008 (UTC)
Centrx, I note your continuing strong aversion to fresh, rationally organised discussion; and I have reverted your latest undiscussed changes! If you want to edit-war, and persist in altering the guideline that had been established for MONTHS, and had CONSENSUS and WELL-DOCUMENTED DISCUSSION, you will be responsible for the consequences. But don't expect the rest of us to appreciate your unruly and uncollegial acts, or to stand idly by.
–⊥¡ɐɔıʇǝoNoetica!T– 02:02, 10 March 2008 (UTC)
If you want to discuss it, discuss it. All you do is talk about how it ought to be discussed and how it was discussed in the past, but you don't actually discuss it. You do blanket reverts without accommodating any change, even the obvious italics. It is unproductive and it is a waste of everyone's time, yours most of all. I have opened a section below for you. —Centrx→talk • 02:32, 10 March 2008 (UTC)

What on earth is going on here, and how many places do you want to spread the discussion? Centrx changed a long-standing issue with no discussion, left a deceptive edit summary, it was changed back, and now apparently Centrx and one other editor are trying to reinstate it here and at MOSNUM without consensus. Please stop this silliness, and if you want to change, please discuss and gain consensus. Thank you, SandyGeorgia (Talk) 02:22, 11 March 2008 (UTC)

I think you mean Tony1. —Centrx→talk • 02:26, 11 March 2008 (UTC)
I don't have a preference between the versions, but as with many MoS issues, it doesn't appear that there have ever been enough participants in the discussions on this issue to demonstrate a meaningful consensus for either version. I think it would be best to approach the issue with no preconceptions and see if a genuine consensus can be developed. If there isn't sufficient interest to generate a consensus, it's a good issue that people don't care about the issue, and it isn't a good topic for a guideline. Christopher Parham (talk) 02:34, 11 March 2008 (UTC)
I have no pony in the race either as to what the final conclusion is, but these constant changes to long-standing consensus appear intended to confuse and render MoS useless. From one day to the next, we need to know what the guideline is, and we need stability on these pages. A few parties constantly edit war here and insert instability. Changes should be based on consensus so the rest of us don't have to guess from day to day what the guidelines are. Centrx, please stop inserting changes without discussion, and with deceptive edit summaries. If you want to change something, pls gain consensus first. SandyGeorgia (Talk) 02:37, 11 March 2008 (UTC)
I'm fast becoming FED UP with your attitudes and accusations, Centrx. It has been plainly pointed out to you that I did gain consensus at MOSNUM for the change, some time ago. Now behave like an adult, or MOS will be frozen, just as MOSNUM has been—due to you. Tony (talk) 02:38, 11 March 2008 (UTC)
While you certainly attempted to discuss the issue, I don't agree that you gained a consensus on the topic. If you propose a change that affects 2000000+ articles edited by thousands of people, and 5 people participate in the discussion, it demonstrates indifference, not consensus, even if the participants were unanimous in support (and there does appear to have been a quiet dissenting voice at the end). Christopher Parham (talk) 02:49, 11 March 2008 (UTC)
  • I do consider that the discussion represented consensus and that sufficient time elapsed for people to provide feedback. MOS relies on the hard work of a core of editors, yet the talk page is open to all to scrutinise, at any time. That is where changes are proposed. It's very easy for a contrarian such as you to claim lack of consensus on whatever basis you please, but ... where were you? If you want to participate, you need to do so at the time. Tony (talk) 01:11, 16 March 2008 (UTC)

Common mathematical symbols: spacing

The section Common mathematical symbols says that the times symbol (×) should be spaced on both sides. I'm fine with that in equations, but it should not be spaced when it appears inside numbers in exponential notation (e.g. 2×104). This is a single entity, and should not have internal spaces. This prescription in the MoS has caused someone to change the {{e}} template (for exponential notation) to add spaces, which makes numbers ugly and sometimes confusing when they appear in text. The template currently renders as 2 × 104.--Srleffler (talk) 16:41, 11 March 2008 (UTC)

I added spaces in response to a request (Wikipedia:Village_pump_(assistance)/Archive_7#Template:e, but I agree that the general rule does not necessarily apply inside numbers in exponential notation. Do you have examples where it is confusing?--Patrick (talk) 17:43, 11 March 2008 (UTC)
It is customary in mathematical typesetting to place a space on either side of binary operators (+, −, ·, ×, etc.) in order to improve readability and make the structure of the formula clearer at first glance. In the case of 2×104, I usually would not use spaces, as such a constant in a formula is semantically a single object and therefore the space distracts rather than contributes to readability, especially if there are other operators nearby.
Good: 2×104 m/s − 3×104 m/s (space to separate quantity and unit as well as to distinguish outer operator)
Bad: 2 × 104 m / s − 3 × 104 m / s (spaces inserted in mindless rule following everywhere)
Maybe: 2 × 104 m/s − 3 × 104 m/s (no spaces around operators in units)
In the second example, the use of spaces provides no useful information to the reader. Likewise, we also do not use spaces around binary operators that occur within units of measurements (i.e., km/h and not km / h). There is ultimately only a single criterion on which any typographic convention should be judged: whether it offers any benefit to the reader or not. Markus Kuhn (talk) 19:48, 11 March 2008 (UTC)
I don't agree; if there's a problem, you can always enclose each compound item in curly brackets, but that would not normally be necessary. Tony (talk) 03:37, 12 March 2008 (UTC)
Clearly the version without the spaces within the constants and units is easier to read and better typography, though. I propose adding an exception to the MoS prescribing no spaces within constants in exponential notation, nor within units.--Srleffler (talk) 04:03, 12 March 2008 (UTC)
The squashy version is harder to read, IMV. Tony (talk) 08:01, 12 March 2008 (UTC)
Bearing in mind here that I'm a mathematician, I find the second version mildly easier to read, apart from the spaces inside the units; there really shouldn't be spaces inside units, even compound ones, regardless of the operators. Otherwise, the spacing is slightly better, and anyone with the knowledge to understand the expression at all will know what is meant because there's only one way to read it that makes any sense. SamBC(talk) 12:37, 12 March 2008 (UTC)
For what it's worth, my opinion is that "2.3×10−13" is a single number, rather than a product of numbers. So it makes sense to not include the gaps. The only reason spaces were imposed is because of the Wikipedia standard, MoS.
Springer, a reputable publisher of scientific books, does not use spacing in exponential notation.[7] Then again, there are some journals[8] that do include gaps. My personal preference would be to do away with the gaps for exponential notation.—RJH (talk) 15:46, 12 March 2008 (UTC)
I agree – a number in scientific notation is a single entity. Bubba73 (talk), 01:40, 13 March 2008 (UTC)
I’m commenting here at Tony (Tony1)’s request: I, too, agree that we should omit the spaces in scientific notation. I’ve reverted the template back to its original (non-spaced) behavior for the time being, at least. — Knowledge Seeker দ 09:12, 13 March 2008 (UTC)
And you've acted improperly by not gaining consensus for (re-)introducing and inconsistency WRT to MOS. FAs have to comply with MOS, and this was the original reason that RJH requested the change. Now, if you want to judge for yourselves just how ugly and hard to read squashed-up scientific notation is—at least on a computer monitor—here are examples from the article Ampere, the first linked article to the E-template that I looked at:

μ0 \ \overset{\underset{\mathrm{def}}{}}{=}\ 4π×10−7 H/m

6.24150948×1018

1.60217653×10-19 ± 0.00000014×10-19 C

This is unacceptably difficult—squint material, all the more given that our text does not appear in hard copy, and is designed to be read by a wider audience than the highly specialised audience that Knowledge Seeker et al. here are clearly thinking of. Not fair to our readers, I say. I don't buy Sleffler's idea that the squashed-up version is somehow "better typography" (run that argument past me again?). Nor do I buy the argument that these expressions are single numbers and thus should be squashed up; they can be seen as either single or composite expressions, just like 2.1 × 2; you may wish to make professional distinctions on this basis, but I think they might elude most of our readers, and it is they who count.

Here are the spaced versions, as currently required by MOS:

μ0 \ \overset{\underset{\mathrm{def}}{}}{=}\ 4π × 10−7 H/m

6.24150948 × 1018

1.60217653 × 10-19 ± 0.00000014 × 10-19 C

Tony (talk) 10:05, 13 March 2008 (UTC)

And here is the form used (but not prescribed) by the BIPM in their brochure on SI:

μ0 \ \overset{\underset{\mathrm{def}}{}}{=}\ 4π × 10−7 H/m

6.241 509 48 × 1018

1.602 176 53(14) × 10-19

—Preceding unsigned comment added by Woodstone (talk • contribs) 05:35, March 13, 2008
The space-less version looks perfect to me, except that I would also remove the whitespace around the ±, since it is used here between a number and its tolerance rather than between two values in a mathematical expression. (But that is a debate for another day.) If you have to squint, perhaps you have the fonts set too small on your computer? :)--Srleffler (talk) 17:06, 13 March 2008 (UTC)

It looks like the extra spaces have already been stripped from the {{e}} template. Does that mean a consensus has been reached not to use spaces?—RJH (talk) 21:22, 13 March 2008 (UTC)

No, as I've complained on the template talk page and here, Knowledge Seeker has arrogantly stripped off the spaces (thus causing MOS breaches en masse) with the say-so of only one of his friends there. It's the kind of behaviour that mop-people should be resisting, not perpetrating, and is another example of the use of petty admin powers in a dysfunctional way. If KS had any decency, s/he would revert it NOW and wait for the discussion to evolve here and/or there. The fact that Srleffler thinks the squashed-up version is just fine, thank you, is is disregard of what a semi- or non-expert might say. Tony (talk) 01:45, 14 March 2008 (UTC)
I'm not sure what a "mop-person" is, but I do hope it's not a derogatory term. Your usage seems rather uncivil. --Srleffler (talk) 02:21, 14 March 2008 (UTC)
An admin (Knowledge Seeker) reverted the template to the version without spaces, on the grounds that the addition of the spaces had not had consensus.--Srleffler (talk) 02:21, 14 March 2008 (UTC)
Um ... just why you and KS represent consensus against at least three people who came down on the opposite side is totally beyond me. That is why I suspect that this behaviour was arrogant. In addition, the change goes against MOS, rendering all FACs a failure unless they strip the template from their text. It's not behaviour that befits a mop-and-bucket person (that's the name some admins use themselves—don't blame me). Tony (talk) 06:14, 14 March 2008 (UTC)
You seem to have misunderstood what I wrote just above. Neither KS nor I asserted that there was consensus to revert the template back to its former state. Rather, KS asserted that there had not been consensus to add the spaces to the template in the first place. He felt comfortable reverting the template back to the previous state, as a result. --Srleffler (talk) 02:36, 15 March 2008 (UTC)

Consensus??

I'm not sure if we have consensus on the issue of spaces in exponential notation. Reviewing the discussion above, I see one person strongly opposed to changing the MoS to allow exponential notation without spaces, and one who mildly prefers it that way. Five editors have expressed an opinion in favour of removing spaces from exponential notation.

I do believe we have consensus on the issue of no spaces around the solidus ("/") in units, but note that the MoS does not require spaces around the solidus.--Srleffler (talk) 23:03, 15 March 2008 (UTC)

Who ever suggested that there should be spaces around a solidus? However, mathematical operators are a different matter, and no, I do not consider that you can claim consensus for changing the guideline. Tony (talk) 01:07, 16 March 2008 (UTC)

Since no one else has commented, I assume we have consensus to proceed (with one dissenter). I will adjust the text in the guideline.--Srleffler (talk) 22:02, 17 March 2008 (UTC)

I'm a bit late for this, but since Tony1 doesn't seem to be happy with the result it may be worth saying anyway: Not using the spaces in exponential notation is a standard typographical practice and should be followed because it enhances readability. You can think of this rule as similar to a ligature. The case of the solidus "/" is even clearer: It is most frequently used in ersatz notations for fractions, as in 3/4 or km/h, and in those cases spaces would be wrong. In some cases, however, it may be used as a substitute for "÷". In those cases it should be written with spaces. --Hans Adler (talk) 22:40, 17 March 2008 (UTC)

Not only the official SI brochure, but also a few books on physics I randomly picked from my shelves all use spaces around the × sign. So based on that I would rather say it's "standard typographical practice" to use spaces. Before we can make a decision here we will need more investigation and sources. −Woodstone (talk) 23:03, 17 March 2008 (UTC)
Indeed. And Adler's concentration on the solidus perplexes me; what on earth has it got to do with this issue? Srleffler, please don't misrepresent what people have said during this debate: several (is it four) have not agreed with your stance. Tony (talk) 02:13, 18 March 2008 (UTC)

Units if surrounding text is italics

I was most perplexed when I just discovered the recent addition of a new very strict never-italic-unit-symbols rule:

  • Unit symbols (abbreviations) are never written in italics, even if the surrounding text is in italics.

How was this justified? I am, of course, very well familiar with the SI and ISO 31-0 rule of using an upright font for unit symbols in order to distinguish them in equations from variables and quantities, which are normally written in italics. That rule makes perfect sense as the advantage to the reader is obvious: in "m = 1 m" we know – thanks to the rule – exactly that m is a variable and m is the unit meter.

But what can possibly be the justification for strictly always using upright type for a unit name even outside equations (i.e., no italic quantities nearby) in the middle of a fully-in-italics sentence? What is wrong with a 30 km/h speed limit? I don't get it and I've never seen anyone outside Wikipedia write: What is wrong with a 30 km/h speed limit? Please explain to me what advantage to the reader this surprising new rule has. Unless someone has a good explanation for the practical advantage to the reader, I propose to rephrase the rule into:

  • Unit symbols (abbreviations) are never written in italics, unless the surrounding text is in italics.

Markus Kuhn (talk) 20:06, 11 March 2008 (UTC)

Thanks Markus. Yes, that is an unruly change indeed, and not discussed first. I have therefore reverted it, along with another undiscussed change to a provision currently under dispute.
This whole matter of italics for unit symbols no matter what was discussed at length some time ago. There was no consensus for the absurd suggestion that symbols stay upright no matter what! If this must be talked through yet again, so be it. But I hope editors will restrain themselves in the meantime, and will revert all non-consensual changes. MOS needs stability.
–⊥¡ɐɔıʇǝoNoetica!T– 21:44, 11 March 2008 (UTC)
Exactly, Noetica. How ridiculous is the notion that ISO's erroneous wording (I'm convinced that it is a mistake) should be parrotted here. ISO almost certainly intended that symbols not normally be italicised. The writer(s) of their guideline were probably irritated by the normal italicisation of the symbols, and in intensifying the wording, changed the meaning completely. Tony (talk) 00:56, 12 March 2008 (UTC)
And there's nothing wrong with italicising a symbol for emphasis, either. Why not mirror our wording for quotations and italics? ("a quotation is not italicized inside quotation marks or a block quote just because it is a quotation")?

Do not italicize unit symbols (abbreviations) just because they are unit symbols.

Tony (talk) 01:00, 12 March 2008 (UTC)

This is not limited to ISO. NIST gives this recommendation:

The typeface in which a symbol appears helps to define what the symbol represents. For example, irrespective of the typeface used in the surrounding text, "A" would be typed or typeset in

  • italic type for the scalar quantity area: A;
  • roman type for the unit ampere: A;
  • italic boldface for the vector quantity vector potential: A.

An example of them following their own advice is this: "...the recommended symbol for the liter in the United States is L". Here they are discussing the symbol, rather than using it, yet it is not in italics. --Gerry Ashton (talk) 03:53, 12 March 2008 (UTC)

Also, a recommendation from NIST is not absurd. I consider this a deliberate insult from Noetica, which I will not forgive. --Gerry Ashton (talk) 04:13, 12 March 2008 (UTC)

Sorry for changing the guideline first without bringing it up here; I know better than that. Tony, this is not simply an error by ISO. NIST's guide to SI units (SP811) is explicit about this. Gerry has quoted it already, but did not quote the clearest statement in that document. Section 6.1.1 "Typeface" reads "Unit symbols are printed in roman (upright) type regardless of the type used in the surrounding text." In NIST's opinion, it is never correct to write an SI unit symbol (abbreviation) in italics. I propose that Wikipedia's style guide should comply with this standard. Note that spelled-out unit names are not precluded from appearing in italics, only unit symbols.--Srleffler (talk) 04:16, 12 March 2008 (UTC)

Yes, but here we're not beholden to any particular guideline (and nor is NIST in developing its own, for US usage, I presume). WP has different conditions both for writers and readers. Give me one good reason that symbols should not be italicised for emphasis or where the surrounding text is in italics. I'm not interested in blindly following an external guideline—whether NIST or ISO or whatever—unless there's good reason to. Tony (talk) 07:58, 12 March 2008 (UTC)
Yes, we are not beholden to any particular external guideline, but it behooves us to look at the best practices of other organizations in the course of forming our own guidelines. Printing unit symbols in italics leads to confusion, since italics are normally used for variables in mathematical writing. It is also unnecessary. Units rarely require emphasis, and the use–mention distinction can be marked just as well by quotation marks as with italics. Proper typography is important because it is not uncommon for a math or physics article to use symbols that are distinguished only by the typeface. One may use "m" for mass and "m" for metres simultaneously without confusion, for example, only because of consistent application of this rule. If italics are permitted for emphasis, one creates situations where the reader may be unsure whether m is a mass or a distance. It goes beyond single symbols as well. An expression like 2 dm could otherwise be mistaken for "two decimetres", but in fact is a product of a constant and two variables (perhaps a distance and a mass). --Srleffler (talk) 01:39, 13 March 2008 (UTC)
There is a genuine problem, Srleffler, and it is not to be lightly dismissed. But it is not to be heavily dismissed either! I mean that heavy-handed and one-size-fits-all approaches are not helpful. Very often, in casual use, unit symbols fit seamlessly into the surrounding text, and nothing is gained by making them non-italic when surrounded by italics. Usually such contexts will be non-technical, and the unit symbols will not be highly esoteric.
Apart from that consideration, think of these two factors:
  • We are dealing with a large number of volunteers who need straightforward and memorable guidlines. They will, like it or not, use italics in mentioning or emphasising all sorts of things, regardless of the problems we can see arising from that practice. It is unfortunate that the relevant authorities have invested mere styling (italics, bold, etc.) with semantic significance. That was a mistake, I say, and bound to end in tears. But good everyday editors need a good everyday way to deal with this.
  • For anyone, though, the matter of singling out some items as always non-italic is fiddly and error-prone. You might have to leave a solidus (/) or other maker in italics (because overall the text is italicised), sandwiched between romans. It could get pretty ugly in markup! And the result could often be unreadable or misinterprested, when a font or a browser is used that tends to overlap italic and roman elements, as we sometimes see with this sort of thing: " '...to speak of' ".
–⊥¡ɐɔıʇǝoNoetica!T– 03:59, 13 March 2008 (UTC)
I understand your point here, and it is a good one. There is merit in a simpler prescription that is more likely to be implemented correctly by editors unfamiliar with this standard, rather than a less intuitive rule that would be broken more often. On the other hand, there is merit in having the MoS uphold a standard even if individual editors sometimes fail to meet that standard. Errors can always be fixed later, and it isn't so critical if some are overlooked.
Regardless of what we decide on the larger issue of whether unit symbols can sometimes be italicized, it seems to me that having the MoS section on unit symbols filled with examples of symbols in italics is a bad idea, because of the same issue of inexperienced editors. I hope we would both agree that when unit symbols are used normally (rather than mentioned or emphasized), they are in Roman type, and that the SI standard is clear on this. The current MoS section might leave a new editor with the impression that unit symbols are supposed to be in italics, since nearly all of the unit symbols in it are shown in italics. I understand the use-mention distinction, but lots of editors do not. It's also unnecessary, since "mention" can be denoted just as well by quotation marks. Editing the section to remove most or all of the italicized symbols would set a much better example of proper SI usage, regardless of one's opinion on whether it is acceptable to italicize unit symbols for emphasis.--Srleffler (talk) 02:52, 14 March 2008 (UTC)
Ah, Gerry Ashton. You need to be a little more careful. I said: "There was no consensus for the absurd suggestion that symbols stay upright no matter what!" The recommendation from NIST does not explicitly say that they must. It may be interpreted that way, but it is not clear. As I will show, its own practice illustrates this uncertainty beautifully. "Surrounding text" is one thing; a styling that is applied in blanket fashion – say, in giving the title of a book – is another. Gerry, you offer this example of NIST's own mentioning practice to support your case: "...the recommended symbol for the liter in the United States is L" (p. 12, as I find). What you do not say is that in the same document NIST has text like this: "The liter (L) is a special name for the cubic decimeter (dm3)" (p. 23). Here the word "liter" is also mentioned, not used: and it too is unitalicised. Symbols are not treated exceptionally. But in fact, NIST is inconsistent in its mentioning practice, and therefore is a poor model for us to appeal to, being itself so deficient in that department. Sometimes, as we have seen, it has no special marking for mentions (words as words); but sometimes it uses double quotes, as this small selection shows:

...the spellings ‘‘meter,’’ ‘‘liter,’’ and ‘‘deka’’ rather than ‘‘metre,’’ ‘‘litre,’’ and ‘‘deca,’’ and the name ‘‘metric ton’’ rather than ‘‘tonne.’’ (p. iv)

Similarly, standardized mathematical signs and symbols such as are given in Ref. [6: ISO 31-11] are used, for example, ‘‘tan x ’’ and not ‘‘tg x .’’ (p. 6)

Note the difference between ‘‘surface’’ and ‘‘area,’’ ‘‘body’’ and ‘‘mass,’’ ‘‘resistor’’ and ‘‘resistance,’’ ‘‘coil’’ and ‘‘inductance.’’ (p. 6)

...under the name ‘‘International nautical mile.’’ (p. 52)

This inconsistency is a departure from BIPM's more careful practice:

The multiples and submultiples of the kilogram are formed by attaching prefix names to the unit name “gram”, and prefix symbols to the unit symbol “g” (BIPM, The International System of Units (SI), 8th edition, 2006, p. 106)

NIST's own bibliographic practice is decidedly unusual. It does have digits in roman, surrounded by italics:

Letter symbols to be used in electrical technology, Part 1: General (p. 73)

And the very NIST document that cites in that fashion has its own title presented in uniform italics:

NIST Special Publication 811 / 1995 Edition Guide for the Use of the International System of Units (SI)

Consistency would demand that "811", at least, be in roman, not italics!
And in any case, as Tony suggests immediately above, we are not constrained to respect anything from NIST (National Institute of Standards and Technology: for National, read American, and the publication is produced for the United States Department of Commerce).
You'll never forgive me, Gerry Ashton? I think I can live with that. :) But such a public display of inflexibility cannot reflect well on your attitude as an editor, I fear.
–⊥¡ɐɔıʇǝoNoetica!T– 12:55, 12 March 2008 (UTC)
None of what you write really addresses the fact that NIST's document directly prescribes the use of Roman type for unit symbols "regardless of the type used in the surrounding text". Inconsistencies in NIST's adherence to its own standards are not a valid argument against the merits of those standards, especially when those inconsistencies do not involve a single instance of unit symbols being presented in italics.--Srleffler (talk) 01:39, 13 March 2008 (UTC)
You think not, Srleffler? It does address it, I think. I said, in effect, that "surrounding text" may be taken in more than one way. To disambiguate, we have to look at examples in NIST's own practice. And right there, on the title page and the next page, we see evidence that it allows "blanket italicising" for titles, at least. No unit symbol occurs in the title, but digits do – digits that NIST elsewhere treats as needing to be in roman.
As for NIST's inconsistencies, that might be taken as a mere ad hominem or a tu quoque; but in fact, given the difficulty of interpretation, and the absence of strong corroboration from the BIPM document, we have to resort to such measures. In any case, examining the practice of a supposed "authority" is a perfectly legitimate move. Would you trust the grammatical advice of an incompetent user of the language?
And of course there are no examples of NIST using unit symbols in italics, for mentioning and the like. When I explain things in detail, with chapter-and-verse evidence, please pay attention: I pointed out that NIST's general practice is not to italicise in mentioning. It appears always to use other means (and inconsistently!).
–⊥¡ɐɔıʇǝoNoetica!T– 03:36, 13 March 2008 (UTC)
Your argument is empty sophistry, and adds nothing to the discussion. You admit that there are no examples of NIST using unit symbols in italics, and have offered nothing else of value.
Contrary to what you imply, the BIPM also unambiguously prescribes that unit symbols be printed in roman type "regardless of the type used in the surrounding text".[9] They introduce their standard for the presentation of unit symbols with the text

General principles for the writing of unit symbols and numbers were first given by the 9th CGPM (1948, Resolution 7). These were subsequently elaborated by ISO, IEC, and other international bodies. As a consequence, there now exists a general consensus on how unit symbols and names, including prefix symbols and names, as well as quantity symbols should be written and used, and how the values of quantities should be expressed. Compliance with these rules and style conventions, the most important of which are presented in this chapter, supports the readability of scientific and technical papers.[10]

Wikipedia's house style should comply with the standards for the SI system, and with the international consensus on how SI unit symbols are rendered.
As stated in that same BIPM document: "Unit symbols are mathematical entities and not abbreviations." They follow different rules from English prose because they are not prose. Unit symbols are presented in roman type in the same way that scalar variables are presented in italics, independent of whether they appear in an equation or in text.--Srleffler (talk) 04:42, 13 March 2008 (UTC)

For the record, since I'm not sure it has been referenced here already, the prescription that unit symbols are presented in Roman type is officially part of the SI system, described in Resolution 7 of the 9th CGPM (1948) (Comptes Rendus de la 9e CGPM (1948), 1949, 70).[11] Noetica will of course point out that it does not explicitly say that this is regardless of context. The information cited above is sufficient to demonstrate the way this standard is interpreted by international standards bodies.--Srleffler (talk) 04:49, 13 March 2008 (UTC)

Srleffler, you write: "Your argument is empty sophistry, and adds nothing to the discussion. You admit that there are no examples of NIST using unit symbols in italics, and have offered nothing else of value." Yet you ignore the answer that I have already twice given concerning the absence of italicised unit symbols in the NIST publication. It inconsistently uses two alternative systems instead (in the superseded version that has been cited!). I have also argued, effectively, that we can get little guidance from an American-based organisation making prescriptions for professional writing in circumscribed contexts, which itself exhibits inconsistency. Hardly a good example for Wikipedia – an international encyclopedia pieced together by volunteers in a very general setting, where consistency is much harder to achieve. To label my arguments "empty sophistry" will advance things not at all. In your sophistic response, you fail to mention the other points I have made, concerning the special needs of Wikipedia as a generalist, HTML-based encyclopedia.
You also ignore the points I have made that acknowledge the problem we face, and that address in detail the particular issues at the coal-face. It is a characteristic of empty rhetoric that it does not confront hard details; I do, but so far you do not, apart from in carefully selected citation without page numbers.
You cite the relevant BIPM brochure, but you sophistically suppress the context. Here is the paragraph in full (emphasis added; and note: I do give page numbers, something others might consider doing also):

Unit symbols are mathematical entities and not abbreviations. Therefore, they are not followed by a period except at the end of a sentence, and one must neither use the plural nor mix unit symbols and unit names within one expression, since names are not mathematical entities. (p. 130)

You seek to hijack the selective quotation, lacking what I here show in bold, to your own purpose:

They follow different rules from English prose because they are not prose.

As if that were BIPM's intent! No, they do not claim that unit symbols are "not prose"; they do not even mention prose, anywhere in the document. Careless at best, Srleffler. At worst, deceptive.
Your assumption that I have not looked at this in some detail, and deliberated about it with care, is unfounded and does you no credit. Let me stress the main point yet another way, to see it that will get across any better. You cite the BIPM brochure:

Compliance with these rules and style conventions, the most important of which are presented in this chapter, supports the readability of scientific and technical papers. (p. 130)

If only we could apply exactly the same rigorous standards to our Wikipedia articles as BIPM seeks to impose on "scientific and technical papers". But we cannot. Journal articles are written by professionals, and are subject to rigorous review and editing before coming under the glare of public scrutiny. We simply cannot match that standard, and must therefore compromise. There are alternative ways to deal with all this. When I have reason to believe that we can look at the matter dispassionately and flexibly, I may well offer a suggestion or two.
If on the other hand you and other editors think that adherence to those draconian standards will magically evaporate all our concerns, I look forward to MOSNUM and MOS including BIPM's firm and unequivocal requirement that sans-serif fonts be used for dimensions – strangely not reflected in our guidelines. Surely we must require markup to impose sans-serif in dimensional analysis, yes? (There's probably some template somewhere, but how can we know such things?)
–⊥¡ɐɔıʇǝoNoetica!T– 06:50, 13 March 2008 (UTC)
OK, let's step back a bit from this. I recognize that your comments about NIST's inconsistent use of italics were motivated by Gerry Ashton's use of a single unitalicized L to support his argument. I agree with you that that was a poor and insufficient example. Clearly an unitalicized "mention" of a unit symbol proves nothing without evidence of consistent use of italics for mentions in other cases, and you have shown that is not the case. I disagree, though, with the apparent attempt to imply that NIST's inconsistent use of italics for mentions says anything about the merits of their opinion on SI typography standards.
I'm not sure if there are still worthy points you have made that I haven't responded to. This discussion is rather long and unsequential. I have responded to a rather good point you made, above. I'll respond to other things as I find them.
Regarding page numbers, note that I was working from HTML versions of most of these documents, and that I provided links. In most cases the links go to short web pages containing a small section of text; less than one printed page. In other cases I cited section or chapter numbers, which should be sufficient because the sections are shorter than one page, and are preferable because pagination can change when material is reprinted or transferred from one medium to another.
About the "selective quotation": I stand by what I wrote. Material quoted from the BIPM document is in quotation marks. Material I wrote is not. I do assert that it was BIPM's intent to imply that unit symbols follow different rules from English prose because they are mathematical entities. They make the comment about unit symbols being mathematical entities in the context of discussing why they do not obey other normal rules such as pluralization or periods for abbreviations, but I feel the principle applies just as well to the issue of why they are not italicized for emphasis, etc.
I see what you are getting at about the distinction between a scientific/technical journal and Wikipedia. Perhaps there is some room for compromise. The MoS should, however, definitely say that unit symbols are (normally) to be in Roman type, since this is a requirement of the SI standard. (For simplicity, Wikipedia should apply the same rule to non-SI units.) I also strongly feel that, independent of the general policy on italicizing symbols for emphasis or to denote "mention", the unit section in the MoS should be rewritten so as not to require any symbols to be italicized. This will avoid confusion on the part of editors who might assume that these symbols should always be entered in italics, based on the examples in the MoS.--Srleffler (talk) 04:13, 14 March 2008 (UTC)
Srleffler, thank you for your thoughtful recognition of, and reply to, some of the points that I have made. I would dispute some of the details, but there is no need to press any of that. I think we might come to agree on essentials. I have applied a dispute tag to the relevant section at WP:MOSNUM, and to the corresponding section here, but just to alert editors to the disparity between those, and to the fact that we are working towards a solution here.
Often there are opposing forces affecting our guidelines, and this is one such case. I have a couple of ideas that might help alleviate the stress those forces induce. We should really be looking at different fonts at MOSpages, for all sorts of short examples. And we should, I think, more often use new lines for longer examples, separating them from maintext rather than relying on italics or quote marks (which can bring their own problems). A simpler version of such practice could be generalised to mainspace articles, with modified guidelines for quoting certain sorts of technical matter. And then, perhaps there will remain some innocuous cases in which uniform italicising will be the best solution.
And we should keep all of that simple!
Give me a little time to read through all of the above once more, and to think about it. I might then put forward a compromise proposal, OK? Or you might have something in mind before I get there myself.
Collegially,–⊥¡ɐɔıʇǝoNoetica!T– 06:52, 14 March 2008 (UTC)

Proposal regarding italics and unit symbols

I propose two changes to the section Unit symbols and abbreviations, reflecting the above discussion:

  • First, add the line "Roman (upright) type is used for unit symbols."
This simple rule brings Wikipedia's formatting of SI unit symbols into compliance with the SI system (Resolution 7 of the 9th CGPM (1948)). I propose that we apply this to non-SI unit symbols as well for simplicity. Note that I don't explicitly specify what happens when the surrounding text is in italics. This leaves open the possibility that more technical articles might comply with the international consensus for technical documents (roman regardless of context), while less technical articles might end up with more intuitive use of italics. Conflicts over this should be rare, since cases where it would make sense to italicize units are not that common.
  • Second, to avoid confusion I propose that the section be edited to eliminate all examples of unit symbols in italics. This can be done by using quotation marks for "mentions", and by rephrasing.
Note that I am not necessarily prescribing that unit symbols can't be italicized for emphasis elsewhere on Wikipedia, but rather I am arguing that having the style guide section on unit symbols be filled with examples of unit symbols in italics will lead to unnecessary confusion. Editors coming here for information on how to format unit symbols may not appreciate that the examples shown are in italics because they are "mentions" or just because they are examples, and may be misled into using italics when they are not justified. This confusion is easily resolved by eliminating the italics from this section.
  • While we are updating this section, would anyone object to combining the line "Non-breaking spaces are used between values and units..." with the paragraph "Values and unit symbols are spaced..."?
Combining these would make more sense, since they deal with the same issue.

Comments?--Srleffler (talk) 04:18, 22 March 2008 (UTC)

As noted at my talkpage, Srleffler, I have been away from Wikipedia. So I have not been able to address this matter here. I have thought about it, though. Here's how I respond to your proposal:
  • If we are to bring WP into conformity with Resolution 7 of the 9th CGPM (1948), as you suggest, we must also zealously ensure adherence to this provision of the resolution also: "These symbols are not followed by a full stop." Since you and others are being resolutely literalist in your interpretation of what BIPM calls for, we must see to it that a unit symbol never occurs at the end of a sentence (unless that sentence ends with a question mark or an exclamation mark).
  • I agree with you that the problem with italics will rarely turn up in practice. (But the difficulty to which I allude above will be more salient, will it not?) I had thought a better solution would be to acknowledge that the BIPM recommendations preclude the normal use of italics for mention or emphasis. I propose, therefore, that articles in which the BIPM standards are to be respected (that is, formal scientific-style articles) abjure all such normal use of italics. If BIPM wants to make give italic styling (and bold styling, and sans-serif styling) such fine-tuned significance, this restriction is a natural consequence. And why not? We must have rigour, at all costs!
  • I note that an editor has recently implemented your suggestion for quotes instead of italics at WP:MOSNUM. This was a preemption of our discussion here, and therefore provocative. Worse, that editor uses the curled versions of single quotes (‘’), wilfully ignoring MOS's recommendations and also introducing obvious inconsistency into MOSNUM. I am surprised that you did not act to fix that. No one else did, either. No one remarked on it at all, in my absence.
  • This state of affairs prompts a question: What hope can there be for rational and collegial efforts towards good practice at Wikipedia, if editors here at MOS can't even maintain consistent use of MOS guidelines at MOSpages? This is a serious and challenging question. I will be giving my personal response to it shortly.
–⊥¡ɐɔıʇǝoNoetica!T– 10:19, 25 March 2008 (UTC)
Welcome back. I noticed you were away. I did not notice the change at WP:MOSNUM.
Your sarcastic comments about full stops seem unhelpful. As discussed above, there is a clear international consensus among standards bodies about how the BIPM's rule on italics is to be interpreted. Your comment about full stops is just silly.
Proposing to prohibit italics for mention or emphasis altogether in technical articles seems somewhat less simple than simply precluding the use of italics for SI unit symbols (whether just in technical articles or in all articles). I would prefer to do the latter. I put forward the proposal above as a compromise. If you have a better suggestion, I would be interested to see it.--Srleffler (talk) 17:24, 25 March 2008 (UTC)
On the contrary, Srleffler. My proposal to work by the letter of the BIPM resolution is no more silly than the idea that italics are never to be used in the case of unit symbols, even in book titles or in mentioning. After all, we have seen earlier that it is ignored even by an "authority" that proposes it; and it is ignored by many other eminent authorities, like New Hart's Rules. Why should we interpret BIPM one way with italics, and another way for the full stop? I would remind you that some authorities ask for an ordinary number expressed in figures never to occur at the end of a sentence – just because the full stop may be ambiguous in the context of numerical expressions used in running text. The reasoning is just as plausible for italics and for full stops: more for full stops, if we take New Hart's practice seriously.
Before you say that what I propose above is "just silly", reflect on its isomorphism with what you propose yourself. Others consider that proposal utterly absurd.
As for my proposal not to use ordinary italicising in rigorous scientific contexts, I am perfectly serious about it. It is, as I say, a rational consequence of the rigour with which the BIPM position is interpreted for unit symbols. And what is wrong with it? Not much, I submit. The context is highly specialised, and may quite reasonably call for practice that is not appropriate in other contexts.
–⊥¡ɐɔıʇǝoNoetica!T– 22:28, 25 March 2008 (UTC)
I don't believe you have shown a case where an SI authority has printed an SI unit symbol in italics. I'm not sure on what you base your claim that this rule is "ignored even by an 'authority' that proposes it".
Does New Hart's Rules actually have examples of SI unit symbols in italics? For what type of writing are these "rules" intended? Are they appropriate for an encyclopedia? Why should we consider their opinion to override the official SI standard on matters directly pertaining to SI?
It does not appear that we are going to achieve consensus on this issue without input from other editors.--Srleffler (talk) 02:29, 26 March 2008 (UTC)
Ah, quite right, Srleffler. I only showed that a NIST document was inconsistent about practice with mentioning, and practice with presentation of numbers as figures. Bad enough, we might think, in a supposed "authority" whose recommendations we are asked to treat as gospel. But no, I temporarily forgot: NIST has no example of an italicised SI unit symbol. CMOS, however, joins New Hart's Rules in quite happily italicising SI unit symbols in mentioning them – as MOSNUM did until the preemptive and unruly changes made by another editor (still unrepaired, I see). I refer to this, at CMOS (and I underline the italicised mentions for emphasis, and also, by the way, that uncompromising and uncompromised ruling against periods):

15.58 Absence of periods. No periods are used after any of the SI symbols for units, and the same symbols are used for both the singular and the plural. Most symbols are lowercased; exceptions are those that stand for units derived from proper names (A for ampere, etc.) and those that must be distinguished from similar lowercased forms. All units are lowercased in their spelled-out form except for degree (°C).

And from the next paragraph:

15.59 [...] Note also that no degree sign is used with the symbol K.

And, since you ask, some of the highly relevant material from New Hart's Rules, in Chapter 14 ("Science, mathematics, and computing"; excerpts from pp. 259ff.):

14.1 General principles

14.1.1 Official guidelines

[...] In general, authors and editors should follow the relevant practices by the Royal Society and the Système Internationale (SI), particularly those for styling symbols and units [...] Internal consistency is vital where more than one standard is acceptable, or where recommendations conflict.

So far, then, SI practice is held up as a standard; yet it is acknowledged that recommendations might conflict. Skipping forward:

14.1.3 Numerals

[...] It is better, therefore, to write 22 km rather than 22 000 metres, or 3 mm3 rather than 0.003 cubic centimetres. [...]

And so on, consistently.
Note:
  • Both CMOS and New Hart's take their own advice, and impose their own uniform practice for mentioning. This, despite holding up the SI norms generally. Both guides are adopted for a very broad range of publications, certainly including dictionaries and encyclopedias.
  • CMOS (American) and New Hart's (British) are the general publishing style manuals for the English-speaking world; but other guides I could quote also impose uniform mentioning practice, despite what the SI authorities appear to be calling for.
  • Wikipedia's MOS has the same sorts of guidelines for uniform mentioning practice. These guidelines do not include an exception for SI units, or for any other units. In that way, our MOS so far conforms to the rational and uniform procedure enshrined in practically every guide to style.
  • Wikipedia is not a vehicle for publication of rigorous scientific journal articles. In fact, it specifically excludes original research, and is specifically aimed at a general audience, and is specifically not to be cited as rigorous journals might be. As such, it is a general publication, and there is no reason for it to diverge from the standards of uniformity that are almost universally adopted for general publishing.
  • The HTML-based character of Wikipedia furnishes no special reason for such variation; and indeed I have argued earlier, with a particular illustration, why this provides extra reasons for uniform practice in text styling.
So there's the case. Unfortunately, many editors here are not familiar with such publishing standards and publishing practices. I hope they will pay attention to the evidence that is now clearly laid out before them: at least for mentioning, here at MOS and especially also at MOSNUM, it is perfectly natural and in accord with standard practice uniformly to use italics in mentioning and in short quotations. On exactly the same principles, it is also acceptable for the vast majority of our articles, in the vanishingly few cases in which the question will ever arise.
Finally, Srleffler, in rejecting your proposal I should record that it fails for an independent reason, based on NIST's own published requirements. You write: "I propose that we apply this to non-SI unit symbols as well for simplicity." But in Appendix B of the very NIST document that we have been discussing, some non-SI units are required to be in italics: the US survey foot (ft) and US survey mile (mi). To the extent that this NIST document expresses or extends SI standards authoritatively, it precludes what you have suggested.
–⊥¡ɐɔıʇǝoNoetica!T– 06:48, 26 March 2008 (UTC)
Well, I have to admit that this is more persuasive than most of what you have written. It comes down to a dispute between authorities, and the CMOS is certainly widely referred to in developing Wikipedia's "house style". The MoS probably should say something about the matter, however, at least to indicate that unit symbols are normally in roman text unless another rule overrides. Without that, there is a danger of editors mistakenly putting symbols in italics for no good reason (or just because they looked at the unfortunate examples in the MoS).--Srleffler (talk) 05:20, 27 March 2008 (UTC)
There is of course also the practical issue that if you stick with the CMOS and Hart, you'll have to refight this battle periodically, since every physical scientist is familiar with the "no italics" rule (and understands why it exists). Most will perceive unit symbols in italics as a typographical error to be corrected on sight regardless what the MoS says.--Srleffler (talk) 16:32, 27 March 2008 (UTC)

Non-breaking spaces

In the current version of this MOS page there is a section called "Non-breaking spaces" that talks a little about how to handle line wrapping. We now have a detailed technical how-to guide about line wrap handling at Wikipedia:Line break handling.

I would like that the section "Non-breaking spaces" of this MOS page in some way link to Wikipedia:Line break handling. Perhaps as a "see also" link at the top of that section?

--David Göthberg (talk) 23:01, 12 March 2008 (UTC)

That Wikipedia:Line break handling is a very welcome development, David. I agree: it should be linked from WP:MOS, and also from WP:MOSNUM. I think a "see also" is most apt, rather than a "main article" link. At this stage, the new page focuses more on technical matters, and does not fully address issues of usage.
Have you made the standard shortcuts yet for Wikipedia:Line break handling, and for its talkpage?
All of this will help enormously when the discussion of ,, as markup for the hard space gets back to full speed.
–⊥¡ɐɔıʇǝoNoetica!T– 00:11, 13 March 2008 (UTC)
Yes, as the shortcut box says on Wikipedia:Line break handling it has the shortcut WP:NOWRAP. And now that you mentioned it I fixed so its talkpage has the shortcut WT:NOWRAP.
"... does not fully address issues of usage"? Oh? I would love if you could elaborate on what you mean by that on the talk page of the how-to guide.
--David Göthberg (talk) 01:40, 13 March 2008 (UTC)
Ah yes, good to see both shortcuts deployed.
All I meant by ... does not fully address issues of usage is that the page is so far about how to force or prevent line breaks, not whether or when to do so, except what is implicit in examples. (See how I contrasted usage with technical matters, above.) That is in no way a negative! MOS and MOSNUM have so far had to give guidelines on both questions; but they will not have to do so much any more, since the new page deals very well with the question of how.
We could extend WP:NOWRAP to cover all of that, of course. Not a bad idea! Was that your ultimate intention? The wording at the top all points to confining the page to methods.
–⊥¡ɐɔıʇǝoNoetica!T– 03:10, 13 March 2008 (UTC)
Right, when I wrote the how-to guide I tried to stay away from almost all the style issues and stick to the technical issues. The big reason was that it was more pressing to explain the technical issues and advertise the how-to guide in all the relevant places, since I see that people do lots of technical mistakes in their wrapping handling.
But yeah, the other reason was to avoid controversy. For instance I did not mention the main case where I like to use two empty lines (between the last article text row and the first navbox) since I know that is controversial.
But I guess we could add a section with less controversial wrapping style advice and style examples to the how-to guide. Like I don't think it is controversial to state that formulas and equations should be completely surrounded by {{nowrap begin}}+{{nowrap end}}. Off course that can already be inferred from the 2+2=4 and |2|<3 examples and also from the Manual of Style, but I guess it wouldn't hurt to state it more clearly.
--David Göthberg (talk) 04:12, 13 March 2008 (UTC)
An ally, finally. I have long now been using two empty lines before succession boxes or, in their absence, article series boxes. I once tried to bring the subject up in the Village Pump, but the ensuing discussion did not last long. There didn't seem to be any real disadvantages to this practice, from what I remember, but you know how these things are... I hope we can co-operate in the future in order to take this idea one step further. Waltham, The Duke of 14:20, 13 March 2008 (UTC)
David, your involvement in both the non-breaking space issue (shortcut for it) and the MOS project would be greatly appreciated. Tony (talk) 14:32, 13 March 2008 (UTC)

Since no one protested I boldly went ahead and added "See also: Wikipedia:Line break handling and Wikipedia:Manual of Style (dates and numbers)#Non-breaking spaces" to the top of the "Non-breaking spaces" section.

Waltham: Yeah, unfortunately most people seem to dislike "air" in texts, web pages and source codes. After studying lots of people when they read pages I have come to this preliminary conclusion (and I am not joking): They seem to not have enough motor skills to click and drag the scrollbar with enough precision, thus they have problems scrolling a page at a time. I guess that is why scroll wheels have become so popular, although the scroll wheels are slower so then lots of air is annoying to them. And most users of course have never learnt to use the keyboard to scroll or page down. So you and I perhaps have to accept that people want as much text as possible squeezed together on each screen full.  :((

Tony: Yes, I have done a lot of work on line wrapping here at en.Wikipedia the last year so I like to share my knowledge.

I think I migth do a work over of the "Non-breaking spaces" sections at WP:MOS and WP:MOSNUM some day. (I will of course first discuss my changes at these talk pages before I actually do them.) Now that we have the technical how-to guide Wikipedia:Line break handling to point to we might be able to shorten the "Non-breaking spaces" sections to mostly contain style recommendations. Perhaps we should change the title of those sections to something like "Line wrap handling"?

--David Göthberg (talk) 16:04, 13 March 2008 (UTC)

Perhaps you are right about the "air"; people tend to be this ridiculous. However, all we are talking about is a single space at the bottom of the page. Surely they will not object to that on such grounds?! It is one lousy row, and half the readers won't even get to reach that part of the article. I certainly don't think we should lose hope; after all, it will improve the appearance of articles, which, as has been mentioned, is becoming increasingly important. Waltham, The Duke of 16:33, 14 March 2008 (UTC)
Oh, they usually just state that they "hate" empty lines. Some times they say they think it makes the article look thin or empty. And some even say it causes too much scrolling. When I press those that just said "hate it" or "looks empty" in the end they often say that they think it causes too much scrolling. So scrolling seems to be the main reason they hate it. But I agree with you, its amazing that they are so bothered by one lousy line at the end of the article. But well, you and I are bothered by the lack of that line, soo...
--David Göthberg (talk) 05:17, 18 March 2008 (UTC)
No, no, no, I will not accept this kind of resigned attitude; they are simply lazy, while we are trying to refine the appearance of articles. They resist change while we are trying to improve things. Our cause is valid and we cannot afford to lose our faith. (How is this for a pep-talk, eh?)
The bottom line is that we have arguments, and they do not, and if we combine this fact with a carefully planned and executed proposal, we could prevail. Waltham, The Duke of 13:33, 18 March 2008 (UTC)

Images

I swear not long ago it said to avoid stacking images in a row on the right (one on top the other). Was this removed, or is it simply in another guideline/policy? VanTucky 00:57, 13 March 2008 (UTC)

I see Wikipedia:Picture tutorial#Avoiding image .22stackups.22. -- SEWilco (talk) 04:36, 13 March 2008 (UTC)
Would anyone be opposed to adding this to the guideline then, since it's already a part of the tutorial? The text I'm thinking would say (verbatim): Avoid stacking images directly on top of each other. This can can conflict with the readability of the text. VanTucky 18:33, 13 March 2008 (UTC)
There is a significant exception that should be articulated: When two separate images are being compared, stacking is often the most appropriate arrangement. See, e.g., Pulp Fiction (film)#The mysterious briefcase.—DCGeist (talk) 22:11, 15 March 2008 (UTC)
Remember, this is a guideline. It's already made clear that any part can be ignored if there is a compelling reason. We don't need to list every possible compelling reason to ignore a particular bit. VanTucky 22:41, 15 March 2008 (UTC)
I don't suggest we list every possible compelling reason. As stated, I believe there is one particular clear and significant exception that should be stated, and it can be done succinctly.—DCGeist (talk) 20:21, 16 March 2008 (UTC)
Well, I don't actually agree that this is a compelling enough reason to add it to the guideline. The necessity of stacking images to compare them really depends on the particular images in question, and should be taken on a case-by-case basis. It should still be avoided when possible, and encoding it in to the guideline makes people think it's a free pass to stack images - which it isn't. VanTucky 20:53, 16 March 2008 (UTC)
Some indication of exceptions would be useful, as there are too many occasions where FAC are interpreted as requiring almost religious adherence to MOS. A simple "unless there is a specific reason"-type phrase would make some sense and go a long way to preventing that sort of craziness. SamBC(talk) 20:59, 16 March 2008 (UTC)
That sounds fine to me. I'll add a note in right now. The criteria is already part of a bulleted list that is headed by the phrase "The following general guidelines should be followed in the absence of a compelling reason to do otherwise." I'll highlight it to be clear, but stating it once in the section is enough imo. VanTucky 21:02, 16 March 2008 (UTC)

Observation

I suppose there was a reason, long ago in the Paleozoic era of Wikipedia, that these little discussion-subworlds came to be known as "talk" pages. As I look at many of them, especially within documents like the MoS that are intended simply to guide editors in the creation and improvement of this project, there seems to really be little more than...talk.

For instance, as I add these words, this (apparently well-named) "talk" page is bordering on 395 kilobytes in size. The cursor is literally pausing as I type, even at cable broadband speeds, because it's struggling to keep up.

Is there something wrong with simply discussing a problem or query, coming to consensus (or determining that it hasn't yet arrived) and just moving on? For those who will say that this page just needs to be archived, I think that misses the point. Remember, we're at 395 kilobytes in just about three months. When actual articles (the reason we're all here, right?) are mandated to stay under 30K, that seems very counterintuitive.

And for those who apparently enjoy seeing their words (all of them, it looks like) in print on the screen, I'd suggest working on improving articles rather than spending an evening debating the finer points of how to render obscure Latin phrases or whether some bit of English punctuation will conflict with usages in Catalan. Honestly, it's more satisfying for me to have actually created something in the end.

Thanks for hearing me out; now feel free to grapple over which dictionaries and style manuals are or aren't regarded as canon. Meanwhile, I'll be somewhere else in the wiki-ether, improving my craft and editing others' as well. Duncan1800 (talk) 06:39, 13 March 2008 (UTC)

At first I thought I should just remove this useless rant. Obviously the only reasonable response is "so don't hang out here". The problem is not that there is too much discussion here; the problem is that the scope of the MoS is too large and this single page doesn't really meet the discussion needs. The scope of the MoS and the associated talk pages should be partitioned. Nohat (talk) 07:20, 13 March 2008 (UTC)
...and therefore Duncan1800, Nohat, and all other editors with a view concerning the role of MOS and other MOSpages are encouraged to sign up at WP:MOSCO, and to have their say on these important issues at WT:MOSCO.
–⊥¡ɐɔıʇǝoNoetica!T– 08:47, 13 March 2008 (UTC)
I second Noetica's suggestion. Please see the proposal for the systematic auditing of our uncoordinated tangle of MOSpages; volunteers are urgently needed to end the chaos by reportage and discussion at MOSCO. And yes, this talk page needs to be archived more often. Tony (talk) 09:11, 13 March 2008 (UTC)
I third the suggestion, if there is such an expression. I intend to start helping out with the assessment myself within the following days. A note to Nohat: the rant is perfectly in the spirit of this page, as demonstrated (in the rant itself), so your removing it would have resulted in a series of unpleasant legal threats on my part. Thank you for reconsidering. :-D Waltham, The Duke of 14:07, 13 March 2008 (UTC)
Really? Legal threats? Like this kind? Nohat (talk) 07:17, 16 March 2008 (UTC)
Well done, I knew you'd recognise them. Waltham, The Duke of 14:46, 19 March 2008 (UTC)
I fourth that, forthwith, and I'd also like to put a positive spin on Duncan's position. I look at the backlog at WP:GAN, and see Version 1.0 coming fast, and I really wish that all these incredibly talented people didn't need to spend so much time here. There's so much to do and so little time. But, it's all about the journey, and I concur with the optimistic tone in these replies that things really are getting done that will help avoid conflict and confusion in the future. - Dan Dank55 (talk) 19:30, 13 March 2008 (UTC) P.S. Note that I'm sucking up to everyone at once, which is completely acceptable, and completely unlike sucking up to Raul, as Giano does here (fnord). - Dan Dank55 (talk) 20:00, 13 March 2008 (UTC)
Note for the postscript: If you want us to stop taking you seriously, you're trying too hard. (evil grin) Waltham, The Duke of 15:21, 14 March 2008 (UTC)

Em dash

"Em dashes are normally unspaced on Wikipedia." Lately I have defended that position twice at WP:ERRORS, but the rule as written is a bit silly because it is false as written - by my count spaced em dashes are about twice as common as unspaced em dashes. If it's a good rule, then it should probably say something more like "Em dashes should be unspaced on Wikipedia." Art LaPella (talk) 23:51, 14 March 2008 (UTC)

Quite right, Art. I don't think it's controversial, so I have made the change you suggest. I have taken the opportunity to fix a couple of other points about dashes while I was at it, for clarity and accuracy. I think there's nothing of substance that people will object to. Let's be especially careful how we present guidelines for dashes, because many editors "out there" need help with them.
–⊥¡ɐɔıʇǝoNoetica!T– 00:54, 15 March 2008 (UTC)

Thank you. Art LaPella (talk) 03:27, 15 March 2008 (UTC)

The policy on this seems to have changed. The last time I looked at it (maybe a year ago?) the MoS was agnostic on spaced vs. unspaced em-dashes, and recommended against changing from one to the other. That probably explains why there are so many spaced dashes.--Srleffler (talk) 23:12, 15 March 2008 (UTC)
As I recall, the rule was specifically phrased in that way because there was no consensus to reject the spaced em dash. I think that Noetica's new wording moves uncomfortably in that direction, so I have reverted it. If we are going to take a specific stance on this issue there needs to be an established consensus. To address Art's concern, if a statement of fact is incorrect it can certainly be removed, but it can't be replaced by a rule that is not supported by consensus. Christopher Parham (talk) 23:31, 15 March 2008 (UTC)
Well, I recall that there was a complete overhaul of the guidelines for hyphens and dashes last year. That was certainly needed.
I have never been comfortable myself with what appears to be a mere description ("Em dashes are normally unspaced on Wikipedia"), for the reasons that Art gives above. What is the point of such a description? The intention was to be modestly prescriptive, but that amounts to offering a timid and unhelpful guideline.
I myself favour the spaced en dash, instead. But if the em dash is used, let it be in the style that almost all its advocates recommend: unspaced. If we sanction three styles for dashes, it's too complex and editors will ignore the guidelines, with inconsistency in articles that others then have to mop up, if they can settle which style already predominates in any given article.
What do people think? The two most used styles in English-language publishing, or expand this to three, with a style that is far less accepted?
–⊥¡ɐɔıʇǝoNoetica!T– 00:06, 16 March 2008 (UTC)
My personal view would be to allow any of the styles; this issue is trivial and prohibiting particular styles does not improve the clarity or readability of articles. It places a burden on editors, but does not improve the reader experience. Christopher Parham (talk) 00:13, 16 March 2008 (UTC)
I agree with Noetica. Although I have little knowledge on the subject myself, I have rarely ever seen spaced em-dashes in print (and in the cases that I have, it was in works of literature); furthermore, even if one only looks at the aesthetic side of the issue, spaced em-dashes take way too much space in the text. Even worse, imagine how text would look with a stray em-dash in the beginning of a line because of wrapping (thanks to a space before it).
By the way, it is I who had Art defend the position in question in WP:ERRORS. I have been experiencing something akin to an obsession with the Main Page lately. :-) Waltham, The Duke of 00:17, 16 March 2008 (UTC)
To take a current example from the top of Drudge, here are some spaced em dashes. I feel that any aesthetic issues are well left to individual editors and specific article talk pages. Christopher Parham (talk) 00:19, 16 March 2008 (UTC)

[Shifted down, after edit conflict:]

So does that mean you don't care so much about consistency in the style of dashes in an article? As I say, if that is to be safeguarded (and we do generally call for such consistency), it places a burden on editors if they must work through an article to determine which of three standards predominates, and then bring about consistency. I agree that there is a small burden for editors in finding out in the first place what MOS says, but that needs to be done only once. And what about my point about dominant standards outside of Wikipedia? The spaced em dash appears mostly in newspapers, not in books or journals, and not in encyclopedias.
With respect, it would help if you address detailed and pertinent points that are raised. Others do not like long-winded contributions here; to help avoid that, please respond to what is written.
–⊥¡ɐɔıʇǝoNoetica!T– 00:27, 16 March 2008 (UTC)
What's more, the matter of what is to be left for discussion at talk pages is not especially relevant to dashes. It is extremely broad, and needs to be addressed now at WT:MOSCO. Myself, I am amazed when people want to duplicate discussion of elementary questions of style at every article! Why do we have MOS in the first place? A serious question, not merely a rhetorical one. Again, see WT:MOSCO.
–⊥¡ɐɔıʇǝoNoetica!T– 00:33, 16 March 2008 (UTC)
It seems to me that determining which of three standards predominates is no more difficult than determining which of two predominates, as you suggest - either way, one needs to look through the history to determine which style was first to be introduced. In any case, inconsistency within an article on this matter does not greatly trouble me, and I see no evidence to suggest that a reader will be bothered by it. To your second point, it seems to me that the distinction between books and journals and encyclopedias and newspapers, all print media, is of little use in guiding an online publication. More important to consider is our status as a wiki, the fact that new editors will be familiar with many different style guides, and the fact that inculcating them in Wikipedia-specific guidelines is time-consuming and unproductive. Therefore, we should be careful before larding up the MoS with rulings on trivial issues. Christopher Parham (talk) 00:35, 16 March 2008 (UTC)
Homeless by crane... Who would have imagined that... That's the sort of thing only New Yorkers get to experience. :-/
Although I must admit that my attention was equally drawn by the hyphen-less "best equipped city". Personally, I am not sure how attentive websites are to their style (although chances are that their MoS could just be different). Waltham, The Duke of 00:43, 16 March 2008 (UTC)
Christopher, I absolutely agree that we have to attend to our special situation as the major online encyclopedia, and that the precedent from books and journals is of limited use. I've said such things often, here. But how exactly does that fact affect the making of guidelines at MOS? Actually, our many editors may need clearer guidelines; not more, but more definite. Do you advocate accepting -- as a dash, spaced or otherwise? How about a spaced hyphen: - ? These belong the days of typewriters, but are entrenched in the practice of very many editors (and some old-fashioned but current style guides, still). We have to draw a line somewhere. Why not simply take the consensus of the major current style guides, when it is simply stated and clearly can be adapted to online use? And that consensus is for spaced en dashes (Penguin and several other major publishers, and gurus like Robert Bringhurst), or unspaced em dashes (CMOS, New Hart's Rules).
–⊥¡ɐɔıʇǝoNoetica!T– 00:54, 16 March 2008 (UTC)
I'm not really opposed to the spaced hyphen or double hyphen: I expect that our readers will be bright enough to figure them out, and for editors they are simpler to produce. But I accept that if someone believes changing spaced hyphens to en or em dashes is the best use of their limited time on Earth, it is probably not worth reverting them.
If there is really a consensus among style guides on an issue, that is one thing, as it indicates an English language standard, but it is pretty clear that significant authorities accept the spaced em dash. Christopher Parham (talk) 01:01, 16 March 2008 (UTC)
  • On the contrary, I am opposed to spaced hyphens and double hyphens. They look crappy, especially on a computer monitor. Tony (talk) 01:03, 16 March 2008 (UTC)
Christopher, it is unhelpful to belittle the concerns most MOS editors have for the details of style. Managing such things is our core business! If you don't share that concern, I am left wondering why you weighed in on this issue.
Please direct us to a relevant major style guides that proposes equal status for spaced and unspaced em dashes.
–⊥¡ɐɔıʇǝoNoetica!T– 01:08, 16 March 2008 (UTC)
It seems unlikely that a style guide would propose equal status for spaced and unspaced em dashes. More to the point is that different style guides come down on different sides of the issue, and that there is no reason for us to choose one way or the other. To your first point, my main concern for the MoS is that fact that once something is entrenched in the guideline, the burden of making the changes will fall on people who don't care about the issue. This is not a valuable use of time and on a net basis damages Wikipedia, by using up time that could be spent on productive activities. Christopher Parham (talk) 01:12, 16 March 2008 (UTC)
  • I have no problem in strengthening the guideline from implied preference for unspaced to "should", which is what Parham inserted a while ago. Unspaced em dashes in justified text on a computer screen—especially in the short columns created by infoboxes—are much more likely to hang. Do you agree, Parham? Tony (talk) 01:23, 16 March 2008 (UTC)
    • I'm a bit confused: I changed it from "should be unspaced" to "normally unspaced", undoing the edits made by Noetica. I do not believe that an implied or explicit preference is desirable; it's debatable whether "normally unspaced" implies a preference, but if people are reading it that way, I would suggest removing it entirely. Christopher Parham (talk) 01:28, 16 March 2008 (UTC)
      • Sorry, I misread your entry above (specifically, the "not"), and also misread the edit diff sequence. The "normally unspaced" was a compromise at the time, and does indeed show a preference. However, to avoid substantial back-compatibility issues, it was decided not to prescribe the unspaced version. I can't think of one styleguide that allows spaced em dashes, and as I said above, in justified short columns, it's a significant formatting issue. As well, the lateral size of the spaced em dash is beginning to be obtrusive, whereas the unspaced en dash (the much-used alternative) is regarded by many people as being below the limit of obtrusiveness. These are subjective judgements, of course, but the limit has to be drawn somewhere. I'm happy to leave it as it is, or to proscribe the spaced em dash. Tony (talk) 01:57, 16 March 2008 (UTC)

(de-indent) I don't really understand all those, forgive me for applying such a label, "style anarchists". Having a clear Manual of Style with detailed guidelines is not instruction creep, for the simple reason that such guidelines have little to do with the way editors go about with their business, interact with each other, or write the encyclopaedia. Simply enough, editors who do not want to bother using the MoS will simply add or alter content, and someone else will correct its style, as happens with grammatical and wikification errors all the time. People who are interested in learning the MoS will do so and use it, but there is no real limit to the level to which one can apply it. Making a mistake is nothing of importance because someone else will eventually correct it. And there are people who actually like doing this very thing: improving the style of pages. And the clearer the guidelines are, the better, because there will be fewer questions and less confusion. And in a matter irrelevant from national variants, like dashes, where there is no reason why consistency should not be desired, it is unreasonable to insist in applying laissez faire, when there is no real gain to be made by giving people more choices which they are usually unable to handle. I repeat: this is a manual. Everything stated here will eventually be applied on pages, but no individual editor has any reason to feel pressured to do it on their own if they do not feel that they are up to it. It's as simple as that. Waltham, The Duke of 02:00, 16 March 2008 (UTC)

Take a look at FAC, and you will see that it not how it works. Individual editors are frequently asked by others to bring articles into compliance. If your description were accurate, the problem posed by the MoS would be greatly reduced. Christopher Parham (talk) 02:04, 16 March 2008 (UTC)
Christopher, that's usually the case in the FAC review process, and not only for MOS-related issues. FAs are the flagships, the models, for all WP's articles; the stylistic harmony (and we hope quality) that compliance with MOS brings to FAs is thus important to the whole project. I agree with The Duke concerning explicit, simple guidelines: it would be preferable to guide WPians towards using either spaced EN dashes – or unspaced EM dashes—the best of both worlds to choose from. Tony (talk) 02:14, 16 March 2008 (UTC)
The differences between MoS-related issues and other FAC issues are (1) that the other issues generally impact the quality of the reader experience, and (2) that fixing the other issues often requires expertise in the topic, or access to sources. The point I am making is that the small group of people who feel these issues matter - of which most of the people who participate here are members - should not be able to impose the burden of work on the indifferent majority. Christopher Parham (talk) 02:22, 16 March 2008 (UTC)
I disagree with everything you just said. Tony (talk) 06:34, 16 March 2008 (UTC)
Let's review what's happened here. Christopher, you reverted a straightforward change that I made – conservatively, cautiously, explaining all the way – meeting a concern raised by Art (who started this section). All my edit did was make explicit an intention that had not been clearly expressed: that we limit sentence-punctuating dashes to spaced en dashes and unspaced em dashes.
Since then you have variously said that, or suggested that, or acted as if:
  • the whole matter is trivial;
  • the work of MOS is a waste of time;
  • style decisions can just as efficiently be wrangled over at the talk pages of every article in WP;
  • there are no established trends with styling of dashes, to guide practice at WP;
  • experienced editors who specialise in style matters, and are thoroughly conversant with style guides used outside of WP, cannot determine these questions better than anyone else; and
  • a section like this is the place to expatiate broadly on the role of MOS within WP.
Well? Yes. Tony disagrees with you; and so do I.
–⊥¡ɐɔıʇǝoNoetica!T– 07:05, 16 March 2008 (UTC)
I should like to make one final comment: Christopher, the burden is only placed upon those editors who want to make style-related edits. The rest need not bother. See the eventualist approach—sooner or later, someone will fix the mistakes. FAC and GAC simply have priority, that's all. Waltham, The Duke of 22:36, 16 March 2008 (UTC)
False, while editors continue to want FA and GA, and opposes are made on these grounds. I think both halves of this regrettable, but we have not yet obtained this utopia. Septentrionalis PMAnderson 22:22, 19 March 2008 (UTC)
  • Comment on ncDave's "oppose" below. Good point, but to what extent should WP pander to the inadequacies of ASCII? En dashes also translate to hyphens in that format, I presume, and probably other symbols and formats that are part of WP's style do not translate to ASCII either. It's really up to whoever "borrows" our text to go through it and ensure that all is good, I say. Otherwise we'll be afeared of doing anything that may not be perfectly rendered in other settings. BTW, the New York Times may be an excellent newspaper, but some of their house style sucks. I wouldn't use it as a benchmark. Tony (talk) 13:42, 17 March 2008 (UTC)

To reiterate my point: I have no opinion on spacing itself, but it should either say "Em dashes should not be spaced" or if that is too strong, "Em dashes are preferably unspaced", or even "Em dashes may be spaced or unspaced", or delete the sentence completely. My objection to "Em dashes are normally unspaced" is because that just isn't true. Art LaPella (talk) 14:49, 18 March 2008 (UTC)

I agree with the apparent consensus here.
  • My copy of the 1999 paperback NYT MOSAU ("and Usage"), p. 96, in the entry on "dash", shows no spaces around the em-dash (or possibly hair-spaces), so I don't know what the basis is for saying NYT requires spaces around em-dashes. The link that Christopher gave above showed en-dashes. Even if newspapers required spaces, newspapers have narrow columns, so they take every opportunity they can to wrap lines, unlike encyclopedias. New Hart's Rules and TCMOS (note the new redirect; CMOS and CMS are disambiguation pages) are very relevant; thanks for looking it up, Noetica.
  • I hate to be Johnny One-Note, but Version 1.0 is not that far off. Version 1.0 considerations certainly don't trump WP style guidelines, but they should at least enter the discussion. It appears no one here is aware of any regional variation or major disagreement among style guidelines on this point, and it appears most of us have done our homework, so it's hard to me to see the publisher having any preference for spaced em-dashes in the printed version of Wikipedia. If so, then the question becomes: are spaces around em-dashes so important that we need for the online Wikipedia to differ from the printed Wikipedia?
  • So far, the question is moot: no one has shown up to give an argument that they prefer or need spaces around em-dashes. I'm not sympathetic to the argument that it's extra work to get rid of spaces around em-dashes; I wouldn't be sympathetic if it only required a straightforward bot, but this doesn't even rise to that level, this is just search-and-replace. And of course, Wikipedia doesn't accept "populist" arguments ("I speak for all the people who don't show up here!"), because there are no "little people" on Wikipedia who need someone else's representation. We could do a better job of notifying and inviting people to speak on subjects they're interested in, we could make the process more transparent, but the bottom line is, if people don't show up for the debate, their voice isn't heard.
  • I am sympathetic to the plea that corrections should be as non-intrusive as possible. Because many people either have seen, or think they've seen, spaces around em-dashes, perhaps it would be better to say in our guideline, "Spaced em-dashes should be replaced by spaced en-dashes". People may be more willing to buy the idea that their intuition is wrong about the length of the dash than to buy the idea that their intution is wrong about the spaces. - Dan Dank55 (talk) 16:49, 20 March 2008 (UTC)
    • Since Art's original objection that normally was a misstatement of fact, how about something like
      Wikipedia usage varies; however, many editors prefer emdashes unspaced—spacing them can be unwieldy and makes unwanted linebreaks possible. Conversely, unspaced endashes look all too like hyphens.
    which states what Wikipedians actually do, and gives the reasons to do otherwise? Septentrionalis PMAnderson 02:39, 21 March 2008 (UTC)
That would be fine if we all agreed that spaced em-dashes are acceptable. However, there seems to be a general agreement here that they are not. Therefore, such a phrasing would be too weak. For good or for bad, the Manual of Style must be, to a degree, more prescriptive than descriptive. It wouldn't be a Manual if it weren't. Waltham, The Duke of 22:41, 22 March 2008 (UTC)
Then let's try Dank's idea:
Dashes between spaces should generally be endashes, emdashes are too long; unspaced dashes as punctuation should be emdashes to avoid confusion with hyphens."
The Manual of Style would do a great deal more good if it were more descriptive; for example, the section which reminds editors who don't know that there are good writers who use the serial comma and good writers who don't. This is not working; but that should only remind us that nobody reads this long, unfounded, and opinionated page. Septentrionalis PMAnderson 16:53, 24 March 2008 (UTC)
Btw, dash advice is different in every style manual I've looked in. APStylebook.com likes en-dashes, and says they're always surrounded by spaces, "except the start of a paragraph and sports agate summaries". NYTM (note the new redirect) says "never use en-dashes", but admits that its advice on dashes is governed by the need to keep things from looking weird because of narrow columns. TCMOS says writers should "use a single hyphen both for a hyphen and for an en dash", and the job of figuring out if an en-dash should be inserted is then up to the typesetter or publisher, but they generally don't like en-dashes except to connect two numbers or sometimes two words (without spaces). And in most online contexts, the en-dash is just about dead. Look at the title bar at top of your screen, and you might see (name of this page) (hyphen) Wikipedia, the free encyclopedia (hyphen) Mozilla Firefox. - Dan Dank55 (talk) 22:01, 24 March 2008 (UTC)
And, of course, anyone who usually thinks of their role as typing and not copyediting will type a hyphen instead of an en-dash. This includes most academics these days, even when writing for peer-reviewed journals, and most journalists when they're self-publishing. The academics and journalists are some of our most valuable contributors, and also the ones most likely to get huffy when we tell them we don't like the punctuation style that they know damn well has been good enough for peer-reviewed journals (not my opinion, I'm just anticipating their reaction). I totally supported the "no spaces around em-dashes" thing, but I have to admit that I have the same kind of worries that Sept does when we try to start sorting out other dash rules. All things considered, this might be one of those issues where the guideline is something like "do whatever you want, and in some cases, we'll have a bot do a search-and-replace". Hard to imagine someone going through the roof because we tweaked the length of one of their dashes in an automated way. - Dan Dank55 (talk) 22:40, 24 March 2008 (UTC)
Clarification: I meant that academics are "the ones most likely to get huffy" not because they're academics, but because people who are used to having their writing approved in a formal setting are the ones most likely to get huffy if a Wikipedian tells them that it's not good enough. For this reason, I'm going to do more research into writing standards in peer-reviewed journals, and pointers would be appreciated. - Dan Dank55 (talk) 16:53, 25 March 2008 (UTC)

(de-indent) This proposal has been on the table for a week (plus forteen hours); how much longer do the esteemed editors believe that we should linger? Waltham, The Duke of 21:25, 23 March 2008 (UTC)

Dashes: concrete proposal, please express your view

Prompted by the discussion above (which I call on people to read):

I now propose that we change the guidelines to favour only two kinds of sentence-punctuating dashes: spaced en dashes and unspaced em dashes, consistently in any given article.

This was strongly implicit in MOS for many months, with no dissent expressed. Opposition? Support? –⊥¡ɐɔıʇǝoNoetica!T– 07:05, 16 March 2008 (UTC)

  • Support - In the interest of keeping styles consistent, constraining the MoS guidelines to include the two most-used styles seems like a good idea. I prefer the en dash myself, but that's not what this proposal is about. --clpo13(talk) 07:12, 16 March 2008 (UTC)
  • Support—The time has come. Spaced em dashes take up just a little too much horizontal space, which renders them too likely to dangle at line's end, especially where the width of text is narrowly wrapped against infobox or image. Anyone who desperately wants a spaced interrupter can choose the spaced en dash. Tony (talk) 07:28, 16 March 2008 (UTC)
  • Oppose; incidentally, dissent to prohibiting spaced em dashes was expressed at the time the change was made. That's why it was written as it was. Christopher Parham (talk) 16:45, 16 March 2008 (UTC)
  • Support. A consistent style, in agreement with common typesetting rules is preferable. −Woodstone (talk) 17:09, 16 March 2008 (UTC)
  • Support – What's left to add? Common practice, suggested by most real-world manuals of style, avoids the excessive length of spaced em-dashes... True, spaced em-dashes are common; so are spaced hyphens in lists, however, and double hyphens in text. Common does not equal right—in the case of my examples, it probably equals plain awful. My concern is another, however; how many know about this poll? We had better advertise it at least in the most important venues, including the Village Pump and the most relevant WikiProjects. We cannot take such decision in secret! And if I hear one word about canvassing, I will have that person assassinated. Waltham, The Duke of 22:36, 16 March 2008 (UTC)
I generally support what you say, but be careful here, Duke.
  • We aren't paying anyone to write articles, so non-Dukes can't simply make a pronouncement that "Everyone does it, but it's awful, so it has to go." We must sell people on the idea that the change is desirable, and this should be easy: we have a bulletproof argument that a printed encyclopedia shouldn't have spaced em-dashes; no one has given a solid argument to prefer spaced em-dashes online or in print; the fix is an almost trivial search-and-replace; and em-dashes and en-dashes are almost the same length in some fonts on some screens, so it's very easy to reassure people that confusion on this subject is natural and we're not challenging anyone's competence.
  • There seems to be agreement that asking about a narrow style question in 200 different places is spammy, and also that running a bot to enforce a change site-wide would be a policy decision and can't be argued on this page, and also that creating a "dash police", or any kind of style police, would be intrusive and unwelcome. It's much better to make style changes either widely and all at once after consensus in some policy forum, or to make style recommendations when people are consenting to have their article reviewed or asking for help. Wandering around making changes when we see something we don't like is not good salesmanship. - Dan Dank55 (talk) 17:54, 20 March 2008 (UTC)
I probably wasn't clear enough, and I guess my tendency to make jokes in every second post does not help things.
  • I completely agree with you. What I was thinking is that it is common to find some typographic constructs in articles, not necessarily because the editors responsible insist on using these forms but because they don't know any better. This is especially prevalent with wiki-syntax: one often copies something one sees somewhere, not having read the relevant guideline / how-to page, thus unwittingly replicating mistakes. This, of course, is not intended to be a blanket statement, but it does cover a great percentage of divergences from the Manual of Style's suggestion.
  • Again I agree; the humourously named "Dash Police" was intended to be (if it was intended to be anything) an unofficial page where the onerous task of moving the hundreds of articles with the wrong dashes in their titles could be co-ordinated. This, of course, would be in done in accordance with the provisions of the Manual of Style and full explanation of the moves would be provided in every case, especially when required. Such changes are more or less uncontroversial anyway, as they concern en-dashes exclusively, and mostly in ranges (usually unspaced).
I hope I have adequately addressed your—reasonable—concerns. You do seem rather confident about your knowledge of salesmanship, by the way. Anything we should know? :-) Waltham, The Duke of 21:02, 20 March 2008 (UTC)
I'm a terrible salesman. It seems like an easy job; whether it will be easy in fact, I don't know. Thanks for the clarification and support. - Dan Dank55 (talk) 04:12, 21 March 2008 (UTC)
  • Oppose. If we were to prefer one style over the other, spaced em dashes should get the nod. According to Em_dash#Em_dash the Chicago Manual of Style prefers unspaced em dashes, but the New York Times prefers spaced em dashes. Spaced em dashes are more readable, and they translate better into plain ASCII. When an unspaced em dash is converted to plain ASCII, it turns into a plain hyphen, which converts two adjacent, unrelated words into a single, hyphenated word, which is just plain wrong. Since snippets of Wikipedia articles are often copied/pasted into other documents, having unspaced em dashes in the articles often introduces such errors. (BTW, I was not canvassed, Waltham, I just stumbled across this topic while looking for something else.) NCdave (talk) 08:03, 17 March 2008 (UTC)
    • See my comment above. Tony (talk) 13:37, 17 March 2008 (UTC)
      • I'm not sure where I stand on this, but I think the copy-paste issue is one that should definitely be considered, and had not occurred to me before. SamBC(talk) 11:23, 17 March 2008 (UTC)
        • No, NCdave, I actually said that we should make this a little more prominent. As far as the copying is concerned, I don't see why Unicode characters would not be converted into ASCII. And there is also the other option (en-dashes), as Tony has pointed out. Last note: which do you think has more authority on the matter, a specialised Manual of Style (like CMOS) or a newspaper? See my comment in the middle of the thread about the lack of a hyphen; it looked really ugly to me. Waltham, The Duke of 17:52, 17 March 2008 (UTC)
    • I think the copying to ASCII issue is a straw man. ASCII is obsolete. Copying Wikipedia articles into ASCII (which is an 8-bit character set) will produce all kinds of typographical problems, and is just a bad idea. Modern applications should support Unicode, and copy/pasting into them should pose no problem. If an application fails to accept Unicode text, that is not really Wikipedia's problem, and Wikipedia's format should not be designed around the limitations of such software. A related issue, though: unspaced em-dashes don't look very good in monospaced type, such as in the edit window.--Srleffler (talk) 02:10, 18 March 2008 (UTC)
      • I know that there is little difference between the Unicorn—sorry, Unicode—dashes in the edit window, but the em-dashes do stand out somewhat, especially for the trained eye. I have come to the point where I can rather easily tell em-dashes and hyphens apart, and, although en-dashes are still rather indistinguishable from hyphens, it is really the em-dash's appearance that matters in this case. Waltham, The Duke of 13:20, 18 March 2008 (UTC)
        • Duke, the sun shines out of them ol' en dashes: who wants a squashy 2006-08 when they can have a swish 2006–08? As an aside, Noetica has won me over to the virtue of spaced en dashes as an alternative to unspaced em dashes. I used to be a totally em-dash guy. Tony (talk) 13:30, 18 March 2008 (UTC)
          • How he has done that, I shall never know. I remain a staunch supporter of the (unspaced) em-dash. On the other thing, I was talking about the edit window. The difference is, of course, plainly visible on the page. As another aside, we have a few hundreds of pages with titles including date ranges or constructs like "United States-Mexico", which will have to be moved. How this will be done, I have no idea; we are talking about a massive undertaking. Waltham, The Duke of 02:45, 19 March 2008 (UTC)
            • We need to sool the en-dash police onto these wrongly cast article titles. It's a problem, and at FAC I often recommend piping links to articles, where the link should have an en dash but doesn't. Tony (talk) 09:17, 19 March 2008 (UTC)
              • I do that at WP:ERRORS. Question: is there a Dash Police? I'd like to found one if there isn't. Nothing official, just a page in my userspace for ideas and small-scale co-ordination. Waltham, The Duke of 13:17, 19 March 2008 (UTC)
                • Put me down as Deputy Commissioner. Tony (talk) 13:33, 19 March 2008 (UTC)
  • Support because the proposal reduces the number of inconsistent typographical choices. It's really an arbitrary choice. There are historical reasons for unspaced em-dashes, and technical reasons for spaced em- or en-dashes. Let's all make sure to avoid the bycicle shed effect. --Hans Adler (talk) 11:53, 17 March 2008 (UTC)
    • It's not really arbitrary (see "takes too much space" argument)... Waltham, The Duke of 17:42, 17 March 2008 (UTC)
  • Support—I agree with what other supporters have said, in the interest of greater consistency. --Paul Erik (talk)(contribs) 23:05, 17 March 2008 (UTC)
  • Support Being raised in the UK, I prefer spaced en-dashes, but I accept that unspaced em-dashed are a valid stylistic choice (common in the US, or some older UK publications). I can't remember ever seeing a guide where spaced em-dashes are prefered: the sole times I have seen them seem to be user-error. (Or UK users who know TeX/LaTeX, and mistakenly try to apply the dash examples in the book to the spaced UK usage) Bluap (talk) 04:34, 18 March 2008 (UTC)
  • Oppose solely due to the problem of unspaced dash conversion. Web browsers are expected to convert some characters and converting two punctuated words to a hyphenated word is bad. I prefer the New York Times use of spaces around em dashes. -- SEWilco (talk) 16:16, 18 March 2008 (UTC)
    • For an example of the conversion issue, click on "edit" see how similar all the dashes look in the edit window:
Compare a squashy hyphenated 2006-08 to a less-squashy en-dashed 2006–08, and a big em-dashed 2006—08.
The edit window (at least in FireFox) is monospaced, like this:
Compare a squashy hyphenated 2006-08 to a less-squashy en-dashed 2006–08, and a big em-dashed 2006—08.
Note that that line actually still contains an en-dash and an em-dash, but they both look a lot like hyphens, in a monospaced font. (The en-dash looks exactly like a hyphen, to me, in the monospaced font that FireFox uses.) NCdave (talk) 20:33, 18 March 2008 (UTC)
As you point out, "conversion" is not the only issue. If dashes look the same to the reader they may as well be the same. It doesn't matter what kind of dash does not have spaces if the result looks like a hyphenated word. I still prefer spaces around the dashes, and it's the browser's task to make the spaces visible. -- SEWilco (talk) 20:40, 18 March 2008 (UTC)
I think all browsers feature monospaced edit boxes. However, I believe that this has no bearing on this matter. For one thing, there is the famous Preview button, which is useful for many things; we've just found one more of its numerous utilities. (Besides, the em-dashes are distinguishable from hyphens; only the en-dashes can be easily confused, and they shouldn't be unspaced anyway.) Two, if you want spaced dashes, there are the en-dashes, whose usage is perfectly uncontroversial. Spaced en-dashes take up about the same space as unspaced em-dashes, which is one of the reasons why they are interchangeable; spaced em-dashes are way too intrusive, because they take up the space of about one and a half spaced en-dashes. It's just way too much. Waltham, The Duke of 02:45, 19 March 2008 (UTC)
(Besides, the em-dashes are distinguishable from hyphens; only the en-dashes can be easily confused, and they shouldn't be unspaced anyway.) – um, en-dashes definitely want to be unspaced when used in ranges, and certain constructs like "Human–Computer Interaction", and the difficulty of seeing what one is doing is very relevant there. This is why I staunchly keep using character entities (&ndash; and &mdash;) despite their supposed lack of readability—because I can then see what I've done. But this is getting off the point somewhat. SamBC(talk) 10:24, 19 March 2008 (UTC)
This is getting off-topic, Sam, because I was talking about disjunction interruption. Waltham, The Duke of 13:17, 19 March 2008 (UTC)
Sorry, my bad. I meant interruption, not disjunction. I confused the terms. Waltham, The Duke of 23:00, 22 March 2008 (UTC)
  • Strongly oppose This is a matter of stylistic preference. No case for mandating cross-article uniformity has been made, or exists. Anyone can edit WP, including those who prefer spaced emdashes. Septentrionalis PMAnderson 21:58, 19 March 2008 (UTC)
    • Anderson, where have you been? I almost inserted a strong oppose and your usual anarchist-flag-flying reason for you, but thought that would be rude. Why don't you propose that the whole of MOS just be closed down? Tony (talk) 00:43, 20 March 2008 (UTC)
      • My answer to this mentality can be found around the middle of the previous section, in the large paragraph marked "de-indent". I could repeat my arguments here, but it would be bad style (pun intended).
      • PS: I think he's kind of proposed it already, Tony. The phrasing's just a bit different. :-) Waltham, The Duke of 03:26, 20 March 2008 (UTC)
  • Support, for the sake of simplicity. The two most often-used options is enough, and Wiki should be consistent. SandyGeorgia (Talk) 03:36, 20 March 2008 (UTC)
  • Support, two options is clearly fine - spaced en or unspaced M. Cheers, Casliber (talk · contribs) 09:22, 20 March 2008 (UTC)
  • Support, for reasons I just gave in the discussion section above. - Dan Dank55 (talk) 16:49, 20 March 2008 (UTC)
  • OpposeSupport, although I'd prefer to have both em- and en-dashes unspaced.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:53, 20 March 2008 (UTC) Changed vote due to mis-understanding the intent of the proposal the first time.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 20:22, 20 March 2008 (UTC)
  • Question. To what extent is it acceptable to change the style of dash-like marks in quotations? If we are not allowed to change dash-like marks in quotations to one of the options listed in the MOS, that would rule out using bots to make changes. --Gerry Ashton (talk) 18:44, 20 March 2008 (UTC)
  • Good question. Perhaps all standardization-bot issues should be discussed in one place or two places. WP:BOT and subdirectories (in general) or WP:STYLE1.0 (for bots used to conform articles to Version 1.0 guidelines, which hopefully will be virtually identical to style guidelines at that time) might work. I will go add your suggestion to WP:STYLE1.0 now: "If a bot finds an irregularity of any kind inside a quotation, it should flag it as such and make no change." - Dan Dank55 (talk) 19:24, 20 March 2008 (UTC)
  • I would think of that as a purely typographical change, not a substantive one, and thus perfectly permissible. SamBC(talk) 20:08, 20 March 2008 (UTC)
As long as the output doesn't look too different from the input, I think I would agree, SamBC; on the other hand, just to be safe, I like what I'm taking to be Gerry's point, that style-bots shouldn't screw around inside quotes, they should tell a human to go look at it, just to be safe. Unless there are a lot more quotations than I'm aware of, and as long as we're talking about a one-time procedure, it shouldn't be a burden to eyeball flagged irregularities inside quotations. In fact, I'll volunteer. - Dan Dank55 (talk) 20:20, 20 March 2008 (UTC)
I think automatic identification of quotations is a problem. There is the false-positive problem, where there are quotation marks, but they are used for some reason other than marking a quotation. Then there is the false-negative problem, where an editor has marked a quotation with some mechanism other than the <blockquote> tag due to the deficiencies of that tag. --Gerry Ashton (talk) 20:37, 20 March 2008 (UTC)
  • Support. As a Brit I infinitely prefer spaced ndashes, but spaced mdashes are simply ridiculous. Happy‑melon 10:48, 21 March 2008 (UTC)
  • Support as proposer. Comment: the objection concerning ASCII-compatibility is, as far I'm concerned, dead in the water. A great deal of the markup currently used at Wikipedia, along with many routinely proposed additions and refinements to our practice, goes well beyond what ASCII would permit. That standard is well and truly superseded, and it is absurd to limit ourselves out of respect for inept and outmoded uses to which Wikipedia text might be put.
  • Oppose. Since both spaced and unspaced em-dashes are used in the wider world, the obvious question to ask is whether it is necessary for Wikipedia to make a uniform stylistic choice between the two conventions across the entire spectrum of its articles. This presumed necessity should be weighed against the difficulties and drawbacks of imposing such a choice, which is that Wikipedia does not have a managing editor, but instead a huge number of editors with many different stylistic preferences. It has been noted that spaced em-dashes are common in Wikipedia. Even the wording of the new requirement has been modified to reflect this: "Spaced em dashes should not be used on Wikipedia". Why not? Who says? How does this interfere with the readability and professional presentation of an article?
The trend to make the Manual of Style more prescriptive as time passes is not well received at the editorial chalk-face, where editors working hard to create articles with high quality content and presentation are told that their stylistic choices are not approved. The argument that these "guidelines have little to do with the way editors go about with their business, interact with each other, or write the encyclopaedia. Simply enough, editors who do not want to bother using the MoS will simply add or alter content, and someone else will correct its style, as happens with grammatical and wikification errors all the time." is weak because it applies to almost every stylistic decision which editors can make. Suppose we were to apply this argument to English language variants? Do we really want to say to editors, "Don't worry about contributing in Australian English; someone else will correct its style to the approved U.S. version later on"?
The Manual of Style is already daunting. Every single new prescription has the potential to discourage and put off editors. I know, because I try to help new editors overcome these barriers. Furthermore, with a single stroke of the keyboard, this change adds a huge total future workload to Wikipedia's volunteers to fix the many spaced em-dashes that exist or will be created in good faith. This is wikitime that could be spent far more productively. The benefit is that unspaced em-dashes are shorter and don't cause line breaks. Hmmm... I'm not convinced it is worth it. Wouldn't it be better to say "Wikipedia uses both spaced and unspaced em-dashes, but editors should be consistent within each article"? Geometry guy 22:02, 25 March 2008 (UTC)
As Omegatron says, this is not a choice imposed upon the body of our editors, and its disregard is not penalised. The majority of the Manual of Style's guidelines (ENGVAR and some other, basic guidelines, are excepted—I might have been over-generalising a little but that does not necessarily make my argument a weak one) are only enforced in FAs, which make up for a very small percentage of Wikipedia articles. A choice is made here to serve as a directive for those editors willing to write by the book, and it is made purely on its virtues and not because we feel that we need to make a distinction of some kind. As for the correction of the existing dashes, this is also not placed on the shoulders of editors, including copy-editors; nobody is expected to edit an article just to fix the dashes. Most dashes can and will be corrected in the course of general copy-editing or other changes. Unless, that is, the number of articles with spaced en-dashes but otherwise perfect in terms of style is much higher than I thought. :-) Waltham, The Duke of 20:53, 31 March 2008 (UTC)
  • Oppose. I'm in favor of recommending a single consistent style for the entire project, especially on trivial issues like this. People are free to edit however they want; there is no penalty for entering the wrong formatting, and editors are not required to read through the Manual of Style before editing. But it's good to have a consistent recommendation for people like me who willingly defer to the recommended style when they discover what it is, and to prevent long edit "wars" between people "fixing" things back and forth to their preferred version. However, I disagree with this particular proposal because spaced em dashes are more appropriate for the web than the other alternatives. The fact that they are already twice as common on Wikipedia should not be ignored. — Omegatron 01:52, 26 March 2008 (UTC)
    • The first part of your message can only be perceived as a reply to Geometry Guy, but this is not easy to see; it is generally preferable that such comments are made as indentions following the statements they are replying to. In any case, how exactly are spaced em-dashes more appropriate for the web? This is not a sustainable argument on its own. And the fact that they are used a lot does not really mean that they are correct; hyphens in lists are also very popular even though they are bad style, and the MoS discourages them.
    • PS: Poor Noetica's message was cut in half here; surely is it appropriate to oppose here rather than at another point of the thread? Waltham, The Duke of 20:53, 31 March 2008 (UTC)

After nine days' clear exposure of this issue, we have 17 opinions, 13 of which are in favour of the proposal. I take it that this counts as consensus. I am therefore making the necessary change to our guidelines.

–⊥¡ɐɔıʇǝoNoetica!T– 09:31, 25 March 2008 (UTC)

Seems like I am late for the party :-) Nine days over the Easter break is not that long, and I'm surprised to find consensus here being determined by counting "votes", especially after the lively discussion before the "vote". I'm also surprised that the change is described as "necessary". See my comments above. Geometry guy 22:02, 25 March 2008 (UTC)
And I note that James MLane has now commented in favor of the spaced emdash; so it is no longer true that no-one has done so. I think presenting the argument of many editors against it is fair and reasonable; but there has been no discussion of the wording except my own below. Septentrionalis PMAnderson 03:26, 1 April 2008 (UTC)
Wikipedia decisions are not made by vote, but by general agreement and genuine consideration of other people's opinions. — Omegatron 01:52, 26 March 2008 (UTC)
On your objections to the process used, G-guy: would you prefer that this issue get a wider airing? I had a discussion today at the Wikicouncil's talk page with Happy-Melon on what he calls "the Council's evolved function as a discussion forum", which might or might not be the solution to the problem of getting a wider airing for style questions, or maybe an appropriate subset of style questions, out to the wikiprojects in a way that doesn't get us labeled as spammers.
  • I concur with G-guy that if we choose to close a 13 to 4 discussion without pulling in an objective admin to make the call, then an explanation would be preferable to just saying "we won", which gives the impression that the other 4 "don't count", which is certainly not true. What is true is that none of the opposition gave an argument against spaced en-dashes as an alternative. As I mentioned in the discussion section, it's true that NYTM likes em-dashes, usually with hair-spaces, but there are 3 problems with relying on this for support of em-dashes in Wikipedia: we don't use hair-spaces, they are alone in this recommendation (as far as we can tell, not even supported by the AP Style Manual), and they admit that their recommendation has to do with the needs of narrow newsprint columns. So, again, from where I was sitting, I had no problem with seeing consensus here, I just would have used different words if someone had asked me to make the call.
  • I'm not done yet with researching this, I want to learn a lot more about what dashes appear in peer-reviewed journals; can anyone point me in the right direction? There are reasons to believe that we're nearing a tipping point for increased participation by academics in Wikipedia (that's an argument for another page), and we don't want them to feel uncomfortable. I'll try to research this tomorrow.
  • Questions about dashes may have solutions that few other style issues have. The Dash article in main-space gives good and well-sourced information. Anyone who would like to dispute the information there is welcome to ... but of course, if you don't have a source, you'll be reverted for WP:NOR. Arguing in main-space may give us some tools that we don't otherwise have. Also, G-guy, you might poll people who have spaced em-dashes in their articles to see how much it would upset them to have it converted to an en-dash; my guess is that people pay very little attention, in general, and if it's true that few journals and encyclopedias outside of Wikipedia used spaced em-dashes, most of them would be more than happy to conform. They would be especially happy if they don't have to do any work, which is another way this issue is different than the others...a bot that replaced (space)(em-dash)(space) with spaced en-dashes might be a good thing. Does anyone know a way to search for "all GA and FA articles containing spaced em-dashes"? - Dan Dank55 (talk) 05:37, 26 March 2008 (UTC)
  • OMG, who cares about making academics comfortable? Part of my job is to show them how to write, up to the top echelons, and I can assure you that it's a rare one who writes well. On the "admin" comment above—they are the last people I'd implicitly trust to be NPOV. Just what qualities do you ascribe to mops that might qualify them to make objective judgements. If only I saw objectivity on the part of mops out there in the project, I'd be pleased. But again, it's rare. Tony (talk) 14:21, 26 March 2008 (UTC)
  • The introduction of the notion that an admin must be involved in making the call here doesn't show an understanding of the role of admins; nothing about interpretation of this discussion requires admin tools. Academics who write for journals must submit to the style guidelines of those journals; not an argument for Wiki not to be on par with other publications. Wiki is mature enough to have its own guidelines. SandyGeorgia (Talk) 16:25, 26 March 2008 (UTC)
I expressed myself badly; I didn't mean "objective admin", I meant objective person. I thought that there was consensus that, even if many admins aren't good at this sort of thing, they're supposed to be, and that they can be de-sysoped if they have a habit of getting it wrong; but the argument goes far beyond my experience. From what I've read at WP:AN, I think admins come closer to my position than yours ... but then, they would, you'd say. The point stands that there's no support at all on Wikipedia for "13 to 4, we won", at least on an argument that could affect so many articles in Wikipedia; I don't know how much more is needed, but something more is needed.
On the other hand, I point to the fact that I had already made the argument that the opposition didn't seem to have submitted any arguments against spaced en-dashes, and the opposition had time to respond to that, so that despite the opposition votes, there was the appearance of consensus. Folks who think otherwise are invited to read the discussion. On the other other hand, it has been noted more than once that not many people show up to argue their case here, certainly a small number in proportion to the number of people that might be affected by the decision, and, speaking for myself of course, I am more than willing to throw out the previous discussion and start over with more facts and wider participation. Perhaps the Wikicouncil will be helpful; there has been no objection yet to the proposal over there of posting arguments that will be visibile to all the wikiproject people who check in there, as a nice non-spammy alternative to posting notices all over the place whenever we have a style discussion.
Tony says "Part of my job is to show them how to write, up to the top echelons, and I can assure you that it's a rare one who writes well". In the world I'm aware of, there is no black-and-white dividing line between academics and people who are successful in other ways; there's a constant back-and-forth between participation in academia and participation at all levels of business and politics. In this world, saying that your writing skills are significally better than almost all academics and the equal of the best is the same thing as saying that you're the best writer in the world. This being Wikipedia, I can't accept original research, so I'll need a source for that. Certification from the United Nations and the relevant Nobel Prize committee would be sufficient.
Lastly, the subject of the long and tortuous relationship between Wikipedia and academics goes way beyond what we can discuss here; let's try to discuss it in another forum. The topic sentence is: there has been a deliberate attempt to alienate academics in a variety of ways since the founding of Wikipedia, probably for very good reasons, but there has clearly been a decision reached at the highest levels to turn that around, because the decision has apparently just been made to give academics the three things they crave most: flagged revisions, "trusted-usership", and some kind of printed form of Wikipedia. I need to do some poking around to find out where to discuss this; I have already collected many pieces of the puzzle. - Dan Dank55 (talk) 17:14, 26 March 2008 (UTC)
I didn't mean for my brief remark to drive the discussion off-topic, even if the off topics are very interesting. As far as I am concerned, part of the process of finding consensus is making a bold step as Noetica has done, and seeing if it raises any objections. Well it raised some, and I don't think they've been answered yet. As for a wider airing, I think the broader issue of "How prescriptive should MoS be?" needs a wider airing, as it seems to underlie many of the disagreements that arise here. There is a tension between those who want consistency and a definitive Wikipedia style, and those who want all good practice to be permissible. This should result in a healthy tension which leads to the best compromises, but it may not always work out that way.
Participation is not an issue to be dismissed: it is very important in Wikipedia, not only in terms of content contributors (academic or otherwise), but also content reviewers. All content review processes are desperately short of participation now, and the current reputation of MoS is not helping to turn more editors into reviewers. Geometry guy 19:27, 26 March 2008 (UTC)

Quotations

Had I noticed this discussion previously, I would have opposed the proposal; I favor spaced em-dashes on aesthetic grounds.

Without returning to that issue, however, I do think that the proposal should be modified to follow our normal practice of preserving verbatim quotations exactly. A quoted source may depart from the MoS in many respects, but altering it is generally wrong. This principle is noted in the first paragraph of the article. It's reiterated several times with respect to specific points, such as contractions. I suggest it be reiterated here as well.

The concern for the convenience of bots doesn't move me to approve misquoting an author (even in so minor a way). JamesMLane t c 21:35, 31 March 2008 (UTC)

First of all, if you had supported the spaced em dash on aethetic grounds, I would have told you "get an argument" (but much, much more nicely). We have made a decision here based on the technical virtues of dashes, like line-breaking qualities. Like in many other things, everyone has preferences about everything, but we must see here what works best.
In any case, changing the spacing of dashes or correcting the hyphenation of words is not misquotation; think that in half the cases the quotes are not even written by the person who's said them, so punctuation is decided by the interviewer or someone else. Such small changes will bring the quote in line with Wikipedia's style conventions, producing a clearer and more professional-looking article, and yet will not change the quotation's meaning one bit (unless, of course, someone is careless, about which we can do nothing).
But we are talking about a very narrow range of edits here; everything else is, of course, unacceptable. Waltham, The Duke of 14:16, 3 April 2008 (UTC)
And I would have responded (nicely, I hope) that "producing a clearer and more professional-looking article" is a preference on aesthetic grounds. I dislike the look of words crowding the dash on each side. (Spacing also helps the reader distinguish a hyphenated construction like "professional-looking" in which the two words are linked.)
In the unlikely event that I'm ever quoted in Wikipedia, I'd be (very mildly) annoyed to see my quotation changed against my preferences. You're right that, in some instances, an editor at the source publication might have already wreaked such mischief, but our most obvious assumption is that the quotation represents exactly what the quoted person wanted to say. JamesMLane t c 02:58, 4 April 2008 (UTC)

Suggested change to images section

The images section says that "Multiple images in the same article can be staggered right-and-left", but also "Do not place left-aligned images directly below second-level (===) headings, as this disconnects the heading from the text it precedes. Instead, either right-align the image, remove it, or move it to another relevant location." In articles with relatively short sections, it may not possible to obey both of these at once, since there may no easy way to move the left-aligned image away from the second-level heading. I'd like to change the second sentence to read "Try to resolve the problem by right-aligning the image, removing it, or moving it to another relevant location; if none of these are possible without causing other layout problems it is acceptable to leave the image under the second-level heading." Mike Christie (talk) 13:53, 15 March 2008 (UTC)

I suppose I don't see a conflict between the two. I read the "staggering" phrasing as an extension of "Generally, right-alignment is preferred to left- or center-alignment"; that is, it's merely an assurance that left-alignment can have its place. Phrasing of "Multiple images ... can be staggered" seems about as noncommittal and unimposing as possible; it's certainly no criterion. I don't believe the wording revision is necessary, as the "compelling reason" verbiage (not to mention IAR) already provides sufficient leeway for instances when a left-aligned image must be under a level two heading. ЭLСОВВОLД talk 14:18, 15 March 2008 (UTC)
There isn't a conflict between the two: it's very easy to stagger l-r and not divorce headers from text. You simply place the image on top of the header, instead of below it. Then is moves the header with the text. VanTucky 21:48, 15 March 2008 (UTC)
In that case I think I don't understand the rule. I was under the impression it was objecting to the visual separation between the title and the beginning of the text that occurs when you left-align a picture under a title. What is it that changes when you place the image on top of the header? Mike Christie (talk) 13:53, 16 March 2008 (UTC)

Format Citation

Hi. Im currently going through FAC for Tel Aviv and I am not sure how to format citation number 10 which is Kipnis, B.A. (2001-10-08). Tel Aviv, Israel - A World City in Evolution: Urban Development at a Deadend of the Global Economy. Globalization and World Cities Study Group and Network at Loughborough University. Retrieved on 2007-07-17. Cities in Transition. Ljubljana: Department of Geography, University of Ljubljana, pp. 183-194.

The information is given at Loughborough Univeristy website but is from the Univeristy of Ljubljana - please advise. Thanks in advance. Flymeoutofhere (talk) 09:46, 16 March 2008 (UTC)

Left alignment of pics

As to this rule concerning images:

Exception: Portraits with the head looking to the reader's right should be left-aligned (looking into the text of the article) when this does not interfere with navigation or other elements. In such cases, it may be appropriate to move the Table of Contents to the right by using {TOCright}. Since faces are not perfectly symmetrical, it is generally inadvisable to use photo editing software to reverse a right-facing portrait image; however, some editors employ this controversial technique when it does not alter obvious non-symmetrical features (such as Mikhail Gorbachev's birthmark) or make text in the image unreadable.

Who created this rule and why? Not only is it nonsensical, it makes articles look clunky and downright stupid.

Examples:

Roy Campbell (poet) Charles Piazzi Smyth

I'm sure Wikipedians can come up with others.

Let's ditch this silly rule.

TuckerResearch (talk) 06:51, 9 March 2008 (UTC)

I agree that the application of this rule is problematic. (As mentioned in the discussion above, adherence to the portraits-facing-in principle above any other consideration has messed up the Jane Austin article also.) The idea behind this is a valid aesthetic consideration: it's a little distracting when a figure on the page seems to be looking off to the side away from the text. But it fails to consider the negative aesthetic and functional impact of putting a photo where the opening text should be and moving the TOC to a non-standard location. That's bad user interface design, and it's bad article layout. The first sentence you copied here even acknowledges that by saying it should be done only "when this does not interfere with navigation or other elements"... before the bit that was tacked on later, contradicting it with the suggestion to move the TOC. I propose the following replacement:

Exception: Portraits with the subject looking to the reader's right should be left-aligned (looking into the text of the article) when this does not interfere with navigation elements such as the table of contents or with other principles of page layout. For example, left-aligned images should not appear at the top of the article, causing the lead of the article itself to be displaced. Photo editing software can reverse a right-facing portrait, but since faces are not perfectly symmetrical, this is discouraged, especially when it alters obvious non-symmetrical features (such as Mikhail Gorbachev's birthmark) or makes text in the image unreadable.

You'll note that this doesn't provide a definitive answer of what to do with articles where the only acceptable portrait of the subject is right-facing. That should be worked out on a case-by-case basis through standard Wikipedia consensus-building. Maybe the solution will be flipping the portrait, maybe it will be putting it elsewhere in the article, maybe it will be accepting a right-aligned right-facing portrait, and maybe it will be something else. I just know that shoving the TOC and the lead of the article around just to make room for a left-aligned portrait is more distracting, and therefore a poor solution that should be discouraged, not endorsed. - JasonAQuest (talk) 14:37, 9 March 2008 (UTC)
Agreed. I think the right-facing portraits should be right-aligned if they are at the top of the article, they should only be left-aligned if they occur further down in the article. Your Jane Austen example is good. I'm sure Wikipedians have other examples that make Wikipedia look silly and clunky.
TuckerResearch (talk) 20:49, 9 March 2008 (UTC)

I've pulled this discussion out of the archive because it was never resolved, in particular the suggestion I made in it was dismissed without discussion. I realize that this might not be as sexy as whether 11 is better than eleven :), but current wording of the MOS is confusingly contradictory, and this is leading a few editors to impose some rather clunky article layouts based on it. It's fundamentally a conflict between design principles. On one hand, there's the principle that figures in portraits shouldn't be looking away from the text. On the other hand, there's the principle that standard elements of the user interface and page layout should remain consistent from article to article, in particular the upper-left corner of the article is where the lead of the article goes (not an image) and the TOC should be placed on the left under the lead. The image-facing principle is a fairly minor design issue. The latter is the whole reason why we have a MOS in the first place, and its something that's evident enough to most editors that many of them will repeatedly seek to apply if it's not followed. Dismissing it leads to edit wars. It's closely related to the principle of least surprise in user-interface design, which states that things should be where the user/reader expects them to be. The good news is that most of the time these principles don't conflict; a right-facing portrait can be left-aligned almost anywhere in an article. The bad news is that once in a while they do: when the right-facing portait is at the top of the article. In those cases, I think the weight of the more fundamental principles of page and UI design (esp. least surprise) should take precedence over a minor one, especially since the minor one can also be accommodated in any of a few ways (e.g. put the image elsewhere on the page, flip the image horizontally, substitute a different image). But even if we let (IMprofessionalO) bad design win, the contradiction in the MOS needs to be fixed. - JasonAQuest (talk) 14:26, 16 March 2008 (UTC)

I agree; in my opinion, we should retain the inward-facing guideline with exceptions in the cases of disruption of the normal layout, with particular emphasis on the page's top. A person looking out of the monitor will raise a couple of eyebrows; a messed up page layout will cause many frowns.
PS: I've changed the all-capitals heading; I simply couldn't stand it. :-D Waltham, The Duke of 23:16, 16 March 2008 (UTC)
Any more input before changing this? - JasonAQuest (talk) 19:28, 18 March 2008 (UTC)
Better, as always, to give reasons. Pictures looking out of the page may divert the reader's attention out of the page. Therefore, if right-facing images can be placed on the left side of the page, or left-facing images can be placed on the right, without creating other problems, it is better to do so. If this would produce clumsy layout, or conflict with some other design criterion, treat on a case-by-case basis. Septentrionalis PMAnderson 22:03, 19 March 2008 (UTC)

RFC mandatory quotation of public domain text

An editor has been forcing reused public domain text to be within quotations and requesting that ship descriptions from public domain sources be quoted. Wikipedia:Public domain does not mention formatting requirements. Despite widespread use of public domain text such as marked with {{1911}}, there is no mention in WP:MOSQUOTE about a requirement for public domain text to be quoted. Is it acceptable to require that reused public domain text be quoted? -- SEWilco (talk) 03:28, 17 March 2008 (UTC)

  • Comment — If the text is truly in the public domain and the source is cited inline, I can't see why the text would need to be quoted. The original author of a work that has entered the public domain has no right to control any use of that work, including the manner of reproduction, effective from the date it entered the public domain. - Neparis (talk) 03:54, 17 March 2008 (UTC)
  • Comment No offense Neparis, but there has been an argument running for some time elsewhere, with which you are not yet familiar, and it is not as SEWilco represents. There is no issue with an author controlling public domain text. I believe this Talk page is the forum for discussion about Manual of Style issues, not a content dispute between SEWilco and myself. I don't know what SEWilco seeks to accomplish here, but it seems to relate mostly to a discussion he opened and participated argumentatively in Wikipedia talk:Citing sources#Return of PD text style, where he got a full hearing. That itself was a followup to a prior discussion there, now archived, that was an RFC, which also reached no consensus in favor of his opinions. In my view his arguments amounted to him calling for, and failing to get, a consensus to prohibit quoting from public domain texts, to prohibit giving credit to an author of a text that has fallen into the public domain. This is absurd, as of course it can be appropriate to quote giving full attribution to an author of text which has gone into the public domain. That discussion seems to have ended (knock on wood) with a comment that there may be a content dispute between him and myself with regards to the Bathhouse Row article that he mentions. I have been extremely patient with him, and tried to cooperate. Please see the Talk page and the edit history of that article if you are in fact interested. He also opened discussions at Wikipedia talk:SHIP#Public domain text quarantine and Wikipedia talk:WikiProject Cities#Public domain text quarantine where he sought by scaremongering to bring others into that discussion, which did lead to other productive discussions on the USS Pampanito article and led to creating a new DANFS section-template option. It is not appropriate to raise any issue here, it has been getting very personal and is either a content dispute regarding Bathhouse Row or it should relate to some policy relating to personal attacks. I have not been involved in an edit war ever before, but think i am stuck in one now with SEWilco. Anyhow, there is a dispute, but I don't believe this is the forum for it. doncram (talk) 05:03, 17 March 2008 (UTC)
  • Neutral third party comment WP:PD is prety clear, "Proper attribution to the author or source of a work, even if it is in the public domain, is still required to avoid plagiarism." Absent any other specific formatting instructions in MOS, the PD work should be quoted as if it were any other source. This does not have to be via blockquote or quote marks or whatever, a simple inline ref should suffice. -- RoninBK T C 07:11, 17 March 2008 (UTC)
    • The issue is when the PD text is not a source for the article, but simply is part of the article. In cases like that, we use attribution templates to tell that the text came from another source, but there is no general reason to quote it. Similar practice holds if we copy text from one Wikipedia article to another - we don't put it in quotes. — Carl (CBM · talk) 14:55, 17 March 2008 (UTC)
      • CBM fully expressed his opinions along these lines in the discussion at Wikipedia talk:Citing sources#Return of PD text style. I don't know if his expression of what "we" do includes what Roninbk does; I know it does not include what I and some others do in many of the various circumstances laid out in the other discussion. But I don't believe that reprising a full discussion here would be welcomed or helpful here. doncram (talk) 17:39, 17 March 2008 (UTC)
        • I was not a part of that other discussion, but I do think that addressing all of the issue is the only way to truly come to a consensual resolution. As to the issue that CBM brings up, I recall a time that I was editing an article that I attempted to use a State Department source in the manner that you are advocating, and was taken to task for it. The better practice is to write your own copy amd use the PD work as a source, rather than than to simply cut and paste from the PD work. -- RoninBK T C 20:20, 17 March 2008 (UTC)
          • Is that "better practice" documented anywhere? Category:Attribution templates is pretty strong evidence that we permit external free content to be reused as part of Wikipedia. — Carl (CBM · talk) 22:22, 17 March 2008 (UTC)
            • Perhpas not, Perhaps the person who reverted my edit was in error. I only offer that from my experience it would be, (perhaps "better" is the wrong word,) less controversial, to functionally treat the PD material as you would any other source. -- RoninBK T C 02:40, 18 March 2008 (UTC)
          • That "better practice" works best when the material has little detail and can be rephrased easily. In the Bathhouse Row case much of the detail seems relevant, although the order of the text and minor phrasing needs improvement. At least it has been improved when it's not walled off. -- SEWilco (talk) 23:27, 17 March 2008 (UTC)
  • Comment What do other manuals of style say? Most style manuals require citations except when the quote is so well-known that it providing a citation would be pointless. For example, very famous excerpts like To be, or not to be, Thou Shalt Not Kill or E=mc2 need not be cited, but less-well-known quotes from Shakespeare, the Bible, or Einstein should be. A general rule of thumb and possible compromise: If less than 50% of the adult, literate, English-speaking world would recognize the quote, improve the article by adding the citation or flag it with "citation needed" or something similar. If more than 50% would recognize it and you are too busy to find the citation and improve the article, hold your peace and don't be disruptive about it. If more than 90% would recognize it and be able to name the author, don't even bother finding the quote since almost everyone knows it's a famous quote anyways. davidwr/(talk)/(contribs)/(e-mail) 19:17, 17 March 2008 (UTC)
    • The issue at hand isn't quotations at all. Honestly, I'm not sure why this is on the MoS page. The issue is when other free content is used to create Wikipedia articles, not when material is quoted from other sources. — Carl (CBM · talk) 19:22, 17 March 2008 (UTC)
      • The issue is here because the existing WP:MOSQUOTE rules have been used to support that long passages of text must be quoted. The present guideline does not distinguish between text which represents exactly what someone stated as opposed to text which is merely being reused as a bunch of editable characters. The editor has been removing alterations to the text and walling off the original text inside quotations. Some of this has come up here before: Wikipedia talk:Manual of Style/Archive 89 -- SEWilco (talk) 23:27, 17 March 2008 (UTC)
        • The question is whether such a distinction exists in reality. In the rest of the publishing world, there is only one way to use paragraph after paragraph of somebody else's text: to quote it. The concept of simply taking someone else's text, lumping it in with your own, and then giving a vague credit hasn't really been acceptable for centuries. While the concept is not novel, I don't know that it's in Wikipedia's interest to revive practices the rest of the world has rejected. I suppose that bringing it up here has value in that someone may know of a style guide or reputable published work where this practice is endorsed or employed. Christopher Parham (talk) 02:23, 18 March 2008 (UTC)
          • To be fair, the concept of free content hasn't existed for centuries, either, and is generally nonexistent in professional publishing. The entire point of free content is that other people can reuse our writing, and we can reuse theirs. There's no reason we should give up that central benefit of free content by refusing to use others' work as part of our encyclopedia. — Carl (CBM · talk) 02:36, 18 March 2008 (UTC)
            • (edit conflicted)Yes, but just because something is in the public domain doesn't change how much of it we should rely on to write our articles. Wikipedia is intended as a tertiary source of information, and our articles should write "about" things, not to simply restate them. -- RoninBK T C 02:55, 18 March 2008 (UTC)
          • And, on further reflection, I can't see that this practice is in complete disagreement with professional publishing. It's common enough to see a book with one author on the cover in which a few chapters or an appendix are by other authors, who are credited in the TOC and at the beginning of their chapter but not on the cover of the book. — Carl (CBM · talk) 02:53, 18 March 2008 (UTC)
            • I'm not really thinking so much about public domain stuff; I'm thinking of other GFDL (and, in time, CC-BY-SA) material. We routinely share text with other GFDL projects, in the sense that they can copy our text and we can copy theirs, with attribution. Also, the Wikimedia foundation has been negotiating with the FSF for the next version of GFDL to permit us to use CC-BY-SA content such as Citizendium and parts of the Encyclopedia of life. There's no reason for us to duplicate work done by other encyclopedias provided that everyone has compatible free licenses. — Carl (CBM · talk) 03:02, 18 March 2008 (UTC)
            • The concept of the public domain has existed for centuries. As for the your counterexample, in such a work it would always be clear who created what text. Nobody's suggesting that all the author names need to be in a banner across the top of the page. Editors of Wikipedia generally are knowingly giving up specific attribution of text to author, beyond what is shown in the history; but we can't assume that other authors are doing so simply because their work is released under a free license or into the public domain. In general human society the public domain does not carry that connotation. Christopher Parham (talk) 03:09, 18 March 2008 (UTC)
              • Everyone agrees that proper attribution should be used; that's what Category:Attribution templates is for. I think it's safe to assume that users who intentionally put material under a free license such as GFDL or CC-BY-SA are expecting that others might reuse it (with attribution as required by the license). Public domain is more touchy, I agree, but templates like {{1911}} are well established. — Carl (CBM · talk) 03:16, 18 March 2008 (UTC)
                • The problem is that nobody who is not a Wikipedia editor (i.e. 99.9% of all human beings) believes that is proper attribution. Have you ever seen a published work with a box at the end saying "I threw in some paragraphs from an essay by some National Parks woman. Forgot which ones exactly. Don't quite remember her name either. Best check for yourself."? Why do you believe Wikipedia should lead the campaign to make this acceptable? Christopher Parham (talk) 03:29, 18 March 2008 (UTC)
                  • If the attribution template actually says that, I'm sure it can be improved. — Carl (CBM · talk) 03:33, 18 March 2008 (UTC)
                    • The attribution template can't be improved to clarify who created what text, which is what is meant by attribution. Christopher Parham (talk) 03:38, 18 March 2008 (UTC)
                • I do agree that this is less of a problem with works actually released under the GFDL or similar, where this sort of reuse is presumably better expected by the author. Christopher Parham (talk) 03:41, 18 March 2008 (UTC)
                  • For that matter, the text being reused in Bathhouse Row was created by a government employee so it was created without copyright. There are some similarities to an author creating for reuse such as ours. -- SEWilco (talk) 03:46, 18 March 2008 (UTC)
  • More examples: Forcing quotation of public domain text does seem relevant to the one known WP:SHIPS example: tag for "refimprove". Article has sources but also general disclaimer it includes text from DANFS article with an invalid URL. Such text ought to be put in quotes, separately sourced.(diff). How many other articles have been labeled such as "Such text ought to be put in quotes"? Then I remembered refimprove being mentioned someplace before. Wikipedia search for "refimprove quotation" through Google finds what I remembered: Given the attempted injunction, i feel like i oughta go out and mark 10 articles with "refimprove" or similar tags today.... :) doncram (talk) 22:01, 11 March 2008 (UTC)". The search also found User talk:MilesAgain#Please stop reverting my edits.3B please discuss the issue about the edit summarized The article reportedly uses text from "In Coins We Trust" brochure. Any text copied needs to be in quotes. Proper referencing is needed for that material (quoting, indicating source)(diff). How many articles are getting quotation notices on reused public domain text? -- SEWilco (talk) 02:34, 18 March 2008 (UTC)
    • The coins article seems to be back to the ordinary attribution template style. I think that, provided nobody starts disruptively changing numerous articles, it's better to deal with the ones under discussion on a case-by-case basis. — Carl (CBM · talk) 02:44, 18 March 2008 (UTC)
  • Is it just me, or is there some bad faith going on between User:SEWilco and User:doncram that is above and beyond this simple content dispute? -- RoninBK T C 03:02, 18 March 2008 (UTC)
    Not that I'm aware of. We're working OK elsewhere. It just happens that the examples of PD quotation requirements keep appearing from doncram. Try to search for other phrasing which might be used to discuss this and let us know what other examples you find. -- SEWilco (talk) 03:39, 18 March 2008 (UTC)
    • Um, yes, I am aware of getting-to-be-extreme bad faith between SEWilco and myself. I experience him as trying to instigate a witch-hunt against me, because I disagree with him and revert his edits (as he reverts mine) in one article, Bathhouse Row. I also speak up when he instigates controversy in WP:SHIPS and WP:Project Cities, which led to some productive discussion developing the USS Pampanito article, which he deliberately misrepresents. I would actually like for him to open some kind of mediation or other dispute between us, where someone would be responsible for judging who is responsible for bad blood that is developing. This seems irrational and out-of-place in the Manual of Style Talk area. I really would prefer not to indulge him in a full discussion here. Please see the last several discussions he initiated elsewhere, instead. Sincerely, doncram (talk) 04:42, 18 March 2008 (UTC)
    You mean, Wikipedia:Coatrack? -- ReyBrujo (talk) 03:43, 18 March 2008 (UTC)
    I don't think so. His most recent edit removed other stuff to lock up the original text supposedly to honor Harrison more than a dozen <ref> do, but he hasn't created Laura Soullière Harrison. -- SEWilco (talk) 03:58, 18 March 2008 (UTC)
  • Third party comment: As mentioned above, public domain text should be referenced for the sake of verifiability. However, I don't think we should quote everything in the article, but instead in the "quote" parameter of the {{cite book}} template, for example. While the articles would grow longer than what they are now, we would be able to quickly assert the original public domain text and our version which uses it as reference. -- ReyBrujo (talk) 03:46, 18 March 2008 (UTC)
    • The text which is being requested be quoted are large amounts of public domain text which is being reused the same way we reused {{1911}} text to start/boost many articles. -- SEWilco (talk) 03:58, 18 March 2008 (UTC)
  • Comment - In general, we don't want large chunks of text within quotation marks in our articles. We don't because that signals to other editors to leave the quoted text alone. But that's wrong - we want other editors to improve the text - rewording so that the article reads better, adding in facts from other sources, splitting the text as the article gets longer, and so on. I don't know what was done with the 1911 Encyclopedia Britannica text (before my time), but if it was indeed in quotation marks, there had to have been - either explicitly or implicitly - an understanding of when it was appropriate to remove those quotation marks. And there were a lot fewer editors then, I'm sure, who needed to know such a system.
As long as we properly cite the source of information added to articles (and I'd be inclined to argue that each paragraph should be footnoted, not just a section, so the source of information is less likely to get lost), then I think it's better - for the sake of the follow-on editors - if the quotation marks stay off.
And finally, I'd hope that most editors would have time to do a bit of copyediting whenever they dump a bunch of text into an article - it seems to me highly unlikely that whatever is pasted into the article is going to have exactly the right tone and level of detail for Wikipedia. And once there is even a little bit of copyediting, then quotation marks are, of course, inappropriate. -- John Broughton (♫♫) 13:42, 18 March 2008 (UTC)

Comment. Perhaps I am missing something, but I really do not understand why the MoS needs to cover this. If a public domain text is being used as a source, it can be quoted and/or cited like any other source. If the text is being used as an article starter, to be used as a base for rewriting and referencing with up-to-date materials, we have longstanding templates to indicate such attribution. We already have standards about how public domain sources should be handled through long-standing good practice, content policy and citation style guidelines. I don't see any need for any additional guidance beyond the existing standards. I am honestly at a loss to understand why there is any perception there might be such a need. Vassyana (talk) 18:21, 18 March 2008 (UTC)

  • I think the point is challenging the existing standards because they are defective. One good piece of evidence that our attribution practices are defective is that the rest of the world has rejected them. Christopher Parham (talk) 23:59, 18 March 2008 (UTC)
Evidence that Wikipedia's existing standard of attribution for PD sourced content is certainly not defective: the complete absence of published (blog/forum/newspaper/conference proceedings) criticism of those practices outside of Wikipedia. --Paleorthid (talk) 02:00, 19 March 2008 (UTC)
Some examples of preparing a revised version of a work that had fallen into the public domain are modern revised editions of Robert's Rules of Order. I consider this to be evidence that Wikipedia's approach has not been rejected by the rest of the world. --Gerry Ashton (talk) 02:10, 19 March 2008 (UTC)

PD quotation suggestion

  • Suggestion: Add something like the following to the Quotation section. -- SEWilco (talk) 13:04, 18 March 2008 (UTC)
Public domain
Quotation shall not be used with reused public domain text except for short sections where the article has to preserve the original style and spelling of the text.
Support. That nicely satisfies the specific concerns I have in this area. I think this statement is needed to control the level of conflict caused by strongly held philosophical differences in this area, differences not adequately addressed in existing Wikipedia policy or guideline. Quotes effectively lock text from the wikification and copyediting otherwise compelled by MoS. Quotes also imply specific importance in the unaltered state of the quoted text, an implication that overshadows the refinement gained in source attribution. Quotes imply notable importance in preserving the source text in an unaltered state, and will mislead the reader into conferring more significance onto the source text than is constructive. --Paleorthid (talk) 18:16, 18 March 2008 (UTC)
Support. This is spot-on. Quotes (or a quote-box) should only be used when the text should not be changed because it is being attributed to the author. For example, a direct quote from an old PD source where copyright has expired, which is used to provide historical context, etymology, etc., should not be changed (e.g. see: clapotis). But large chunks of PD text manually transcluded to WP should not be quoted, because it should be changed as needed to update or expand the coverage of the subject. For example, material from the 1911 Britanica should be updated, not quoted, as it is typically out of date. Also U.S. Government sources are valuable, but may need to be revised to reflect a worldview. Dhaluza (talk) 23:51, 21 March 2008 (UTC)
Public domain
Quotation should not be used with public domain text added to articles except for short excerpts where it is useful to the reader to have text shown as it was in the original source.
Support. Sounds better than "used with reused" and focuses on reader rather than whatever an "article has to". -- SEWilco (talk) 19:18, 18 March 2008 (UTC)

This is not the forum for that sort of proposal. The MOS is about how to format things. The issue is whether these are quotes at all, or simply incorporated material. If they are quotes, of course they should have quotation marks. — Carl (CBM · talk) 14:04, 18 March 2008 (UTC)

Then please define the difference between a quotation and incorporated material so WP:MOSQUOTE can be more specific than requiring block quotation for "four lines". -- SEWilco (talk) 14:32, 18 March 2008 (UTC)

Large numbers / commas between digits

WP:Style#Large_numbers says:

  • Commas are used to break the sequence every three places (2,900,000).

However, that does not make it clear whether such commas should be used in four-digit integers (1000 to 9999).

Long, long ago I learned to use commas in numbers of five digits or more, only. But some folks use commas in four-digit numbers, too.

This topic might be covered in section 9.59 of the Chicago Manual of Style, but I don't own a copy, and I don't have a subscription to the online version. Perhaps someone who does could look it up?

So, my question is: should a comma be used between the first and second digit of a four-digit integer in an English language Wikipedia article?

Also, can we please add that guidance to WP:Style#Large_numbers?

Thanks! NCdave (talk) 07:42, 17 March 2008 (UTC)

In a table column with also larger numbers a comma in four-digit integers may look better.--Patrick (talk) 11:45, 17 March 2008 (UTC)
Yes, it’s usually better to use the same style for all numbers, but note that years, which are four digits most of the time, are exempt from this one. — Christoph Päper 12:25, 17 March 2008 (UTC)
Yes, 10,000 BC, but 2008.--Patrick (talk) 15:46, 17 March 2008 (UTC)
Yes, that's how I was taught to punctuate all numbers, not just dates. NCdave (talk) 17:23, 17 March 2008 (UTC)
The MOS doesn't specify, which means the rule is "it depends". - JasonAQuest (talk) 20:50, 17 March 2008 (UTC)

Y34RZ3R0R3M1X3D Issue

Ever since this album has been announced, there's been a massive argument between people on Wikipedia whether it should be written in it's leetspeak letters, Y34RZ3R0R3M1X3D, which is how it is referred to on the Official Nine Inch Nails website. http://yearzero.nin.com/remix . This is an issue, but according to the MOS, this would be against policy. However, nowhere is the album ever referred to flat-out Year Zero Remixed. This is an issue, which I feel should consistute a change in POS policy. Tribestros (talk) 14:25, 17 March 2008 (UTC)

What about the URL you provide? Without further investigating the issue, Year Zero Remixed seems appropriate. Such discussion should be based on thinking, not feeling, by the way. — Christoph Päper 14:40, 17 March 2008 (UTC)
The first line on that website clearly states Y34RZ3R0R3M1X3D. Every review of the album refers to it as Y34RZ3R0R3M1X3D, and even on iTunes it's called Y34RZ3R0R3M1X3D. If Trent Reznor, NIN or anyone at Interscope ever referred to it as Year Zero Remixed, it'd be appropriate. But due to the obvious... Tribestros (talk) 16:50, 17 March 2008 (UTC)
I took a look at the reviews listed in the Infobox, to see how the press referred to it. Of the seven reviews linked from the box, three referred to it as Year Zero Remixed, While this is admittedly not a representative sample, it can be concluded that Y34RZ3R0R3M1X3D is not the only valid name for the title. As such, I do not see that it warrants an exception to our MOS. -- RoninBK T C 20:44, 17 March 2008 (UTC)

I took at look at the talk page for that article. It seems part of the reason people are worried about using the spelling Y34RZ3R0R3M1X3D both in the page name, infobox and the article text is that it is hard on screen readers. (The programs blind people use to hear the articles.) That made me come up with an idea. So I would like to hear peoples comments on it and see if it is worth suggesting to Wikimedia foundation. Here goes:

I know we mark infoboxes and navboxes etc with CSS classes that is supposed to make so they don't get read in screen readers. But we have no idea how well that works in different screen readers, and we know that for some screen readers it means the end user has to manually do some fairly fancy configuring to get rid of those boxes. The same is true for hand held devices, they need to strip those boxes too.

So I got a simpler idea. It would be better if such things get stripped at the server end. (Actually not that hard to do.) And gets shown on a separate URL. Say like "en.wikipedia.org/hear/Pagename" instead of "en.wikipedia.org/wiki/Pagename". So on all articles there could be a link to the stripped "hear" version of the articles. Then we who edit articles can check how our articles get rendered there. And the blind users and those who surf with small hand held screens can instead simply surf Wikipedia from that alternate "site".

What do you people think? Is the idea worth of promoting?

--David Göthberg (talk) 05:02, 18 March 2008 (UTC)

Sounds like something to bring up at WP:VP/T. -- RoninBK T C 05:14, 18 March 2008 (UTC)

MoS optional implementation?

I was trying to implement the Manual of Style on a featured article, removing the sizing and alignment specifications implemented on the images therein (see WP:MOS#Images). I was rebuffed and reverted: the sole effective editor of the article (87% edit rate) said that the images were fine and that they feel the MoS is wrong; and as the article had passed WP:FAC with the images formatted such, they were going to respectfully disregard my arguments.

I realize that the WP:MoS is just a guideline, but to what extent can/should it be enforced to ensure some semblance of uniformity across Wikipedia? — pd_THOR | =/\= | 18:20, 18 March 2008 (UTC)

You answered your own question: they're guidelines, and therefore open to discussion on a case-by-case basis. Uniformity is certainly a goal but if there's a good enough reason for doing otherwise, that's permissible. (I might add that I don't see anything in MOS#Images that calls for the removal of image size specifications, and most of the alignment guidelines are clearly expressed as suggestions.) - JasonAQuest (talk) 19:02, 18 March 2008 (UTC)
So effectively (as in my above), it's the preference of any given editor to implement and take the MoS into consideration at their discretion? — pd_THOR | =/\= | 19:18, 18 March 2008 (UTC)
No, it is the responsibility of every editor to take the MOS into consideration; simply ignoring it is not justified. Whether the case in question warrants deviating from it is something to be determined by consensus. It is not "enforced" simply by pointing at WP:MOS and it isn't dismissed without a discussion. No decision is made unilaterally. - JasonAQuest (talk) 21:35, 18 March 2008 (UTC)
  • MOS is not optional for FAs. Criterion 2 binds them to follow it. The FA in question should be taken to FAR to receive reviews of this issue. Tony (talk) 02:13, 19 March 2008 (UTC)
    • A misstatement of the intent of Criterion 2. The word guidelines exists there to make this clear. Septentrionalis PMAnderson 21:53, 19 March 2008 (UTC)
      • In your anarchical dreams, Anderson. Criterion 2 says: "It follows the [[Wikipedia:Manual of Style|style guidelines]], including:...". That's quite clear enough. Tony (talk) 01:10, 20 March 2008 (UTC)
  • A disingenuous use of language. The MoS may be a guideline, but as Tony said, FAs are bound to follow it, so it is not optional. --Malleus Fatuorum (talk) 23:25, 19 March 2008 (UTC)
  • Part of the MoS is that it should not be followed where breaching it would improve an article. (This is at the very top.) That applies to FAs as well. The primary consideration in the FA criteria is that the article exemplifies our best work (again, this is at the very top); considerations of article quality, as determined by consensus, supercede the MoS. Both WP:MOS and WP:WIAFA agree on this point. Christopher Parham (talk) 23:29, 19 March 2008 (UTC)
    • And the present wording of WP:WIAFA says no more; indeed we should follow guidelines, but no guideline is binding. That is what following our style guidelines means. Septentrionalis PMAnderson 18:37, 20 March 2008 (UTC)
Anderson, see WP:NOTLEX. Relevant definitions from the online American Heritage Dictionary:
  • 5. To adhere to; practice: followed family traditions.
  • 6. To take as a model or precedent; imitate: followed my example and resigned.
  • 7.a. To act in agreement or compliance with; obey: follow the rules; follow one's instincts.
  • 7.b. To keep to or stick to: followed the recipe; follow a diet.
- Dan Dank55 (talk) 19:14, 20 March 2008 (UTC)
So why quote a dictionary? WP:WIAFA uses "follow"; so does {{guideline}}. This is intentional; and they are to be read as the same sense. Septentrionalis PMAnderson 20:02, 20 March 2008 (UTC)
I thought you were trying to redefine "follow"; I see I was wrong. If I understand right, you're saying that all guidelines specify that they are to be treated with common sense and the occasional exception, and therefore "following" them means following that advice. That seems sensible. - Dan Dank55 (talk) 04:02, 21 March 2008 (UTC)

No easy answer. WP:WIAFA says FAs have to follow MoS; this says they don't always comply (see WP:SIZE). SandyGeorgia (Talk) 23:31, 19 March 2008 (UTC)

The answers seem pretty straightforward to me. Is the MoS a guideline? Yes. Do all articles have to conform to the MoS? No. Do FAs have to conform to the MoS? Yes. Do all current FAs conform to the MoS? No. And, as a supplementary question: Do all current FAs conform to the current FA criteria? No. --Malleus Fatuorum (talk) 01:24, 20 March 2008 (UTC)
Sandy, I don't think your link is a good indication that the articles are nonconforming. Perhaps these are some of the instances mentioned in the guideline where "common sense and the occasional breach will improve an article." Christopher Parham (talk) 01:41, 20 March 2008 (UTC)
Fine, but the onus is on contributors to convince reviewers why breaching MOS makes their article better. Tony (talk) 02:19, 20 March 2008 (UTC)
Right (which only happens when reviewers actually engage with the criteria). SandyGeorgia (Talk) 02:22, 20 March 2008 (UTC)
Indeed: the onus is on every editor to be able to explain how their edits make articles better. That goes without saying. Christopher Parham (talk) 02:48, 20 March 2008 (UTC)

Wow, I step away for a minute, and my question keeps going; awesome. I like to think that our best-of-the-best articles should show a superior level of consistency and formatting arrangement. FWIW, the article I was referring to was 1994 Black Hawk shootdown incident; disregarding my pointy tone, I brought up my concerns and input on the talk page duly as well. Thoughts? — pd_THOR | =/\= | 13:28, 20 March 2008 (UTC)

It's a recommendation. The part about facing is currently disputed anyway, some sections up. Septentrionalis PMAnderson 00:05, 21 March 2008 (UTC)

200 000 vs 200 thousand

Resolved.

We're working on Polar bear and there's a few of these...any prefernces? Cheers, Casliber (talk · contribs) 20:59, 18 March 2008 (UTC)

I don't think MOS has a view on this. If there are lots of figures in the vicinity, perhaps the "thousand" option is better. Unsure. BTW, there are inconsistent uses of single and double quotes. Either the latter or italics are the go for "words as words". Is it a scientific article? Looks like it to me; unless there consensus not to, you can remove the obstructive imperial conversions for a smoother read. Tony (talk) 02:18, 19 March 2008 (UTC)
Note: 200 000 is wrong; the correct format is 200,000. Regards, Waltham, The Duke of 02:28, 19 March 2008 (UTC)
"200 thousand" is unusual; you should use "200,000". In general, numbers 10 and above should not be written as words unless they start a sentence. (FWIW, "200 000" is not, strictly speaking, wrong; the ISO suggested it, with either a comma or point for the decimal, as an international standard to make numerical notation more consistent worldwide. It's fair to say it hasn't caught on, and it isn't used on English Wikipedia.) ProhibitOnions (T) 07:28, 20 March 2008 (UTC)
This is better advice than mine. Tony (talk) 08:43, 20 March 2008 (UTC)
A belated thankyou to all. Cheers, Casliber (talk · contribs) 02:18, 30 March 2008 (UTC)

STYLE1.0

Version 0.7 decisions are being made now, and the printed and DVD Wikipedia Version 1.0 is not that far off. Wikipedians don't have absolute discretion in formatting decisions (where the periods should go, where the lines should break, end section format, etc) in the printed version; there's also the publisher to deal with. Why formatting decisions in the printed version might affect Wikipedia style guidelines is a bit complicated (short answer: "Jimbo said so"), so anyone interested in either is encouraged to join the discussion at WT:STYLE1.0. Some of the discussions above do seem to involve these kinds of issues. - Dan Dank55 (talk) 18:34, 19 March 2008 (UTC)

An historic, an hotel, etc

Hi, I had a quick shufti through the Manual of Style but couldn't find an answer - what's the policy on using "an" before a noun beginning with an "h"? e.g. "an historic monument" vs. "a historic monument"? I've just held off on reverting a change on 1963 from "makes an historic civil rights speech" to "makes a historic civil rights speech" since it could be the editor is quite justified in making the change (even though it offends my overly sensitive senses!)  This flag once was red  06:33, 20 March 2008 (UTC)

Only if the initial "h" sound is silent, as in "hour" (= "our"). There's slight confusion arising from the dropping of the initial "h" sound in many urban accents in England. In the case of "historic", many people drop it in quick speech regardless of their accent (anistORic MONument). In such cases, I think a/an could go either way. Tony (talk) 08:47, 20 March 2008 (UTC)
I am not sure about correctness but I find "an historic" really grating..Cheers, Casliber (talk · contribs) 09:19, 20 March 2008 (UTC)
I'm the exact opposite! I was taught that for, say, hotel and historic - even though the 'h' wouldn't normally be silent - it would be after an 'an'. Since there's no policy, I'll learn to live with the evilness of "a hotel" and "a historic" ;-)
Thanks for your advice, Tony1 and Casliber.  This flag once was red  09:36, 20 March 2008 (UTC)

I don't want to miss the chance of agreeing with Tony and proving him right. In some forum post I found the following quotation "from the OED": "There is still some divergence of opinion over the form of the indefinite article to use preceding certain words beginning with h- when the first syllable is unstressed: 'a historical document' or 'an historical document'; 'a hotel' or 'an hotel'. The form depends on whether the initial h is sounded or not: an was common in the 18th and 19th centuries, because the initial h was commonly not pronounced for these words. In standard modern English the norm is for the h to be pronounced in words like hotel and historical, and therefore, the indefinite article a is used; however, the older form, with the silent h and the indefinite article an, is still encountered, especially among older speakers."

My Collins COBUILD dictionary says this under "an": "is used […] in front of words that begin with vowel sounds […] Notice that a, not an, is used in front of a word that begins with 'u' when 'u' is not pronounced as a vowel. E.g. …a university."

Webster's (1961 edition) is more comprehensive, mentioning the following uses of "an":

  1. "Usu. in speech and writing before words beginning with a vowel sound." E.g. "an hour", "an X ray".
  2. "Usu. in speech and often in writing before h-initial words beginning with an unstressed or lightly stressed syllable in which \h\ may or may not be pronounced." E.g. "an historian", "an heroic". [Note the use of "often" rather than "usu." as far as writing is concerned.]
  3. "Sometimes (less often now than formerly) before words whose initial letter is a vowel and whose initial sounds are \yü\ or \yù\ or \w\ in one." E.g. "an European", "an unique", "such an one".
  4. "Sometimes in speech and writing and regularly in the Old Testament (AV) before a stressed syllable in h-initial words." E.g. "an hundred", "an heritage".

Sidney Greenbaum's article on "indefinite article" in the Oxford Companion to the English Language gives a short summary and implicit usage advice: "A occurs before consonant sounds (a garden, a human, a use) and an before vowel sounds (an orange, an hour, an uncle, an MP, an SOS). A is sometimes used before certain words beginning with an h, such as an hotel, an historian, particularly if the h is not pronounced. Some, however, pronounce the h, giving rise to controversy and being regarded by some others as slightly pretentious or precious. --Hans Adler (talk) 12:28, 20 March 2008 (UTC)

In this case, the CMOS also agrees [12]. The general history of "an historic", as Tony pointed out, is that it arose when the h was silent. Later, some people treated it as an exception - permitting an historic but not an hit record (this was the style I learned first). One common justification for this is (was) the lack of stress on the first syllable. But the motivation for this exception has apparently dwindled to a point where "edited English requires a" according to the Columbia Guide [13]. Curiously, they mention an hysterical; my guess is that in another 50 years that will also be archaic, along with an Hispanic man. — Carl (CBM · talk) 12:57, 20 March 2008 (UTC)

P.S. the point I wanted to make is that, for people like me, this has to be explained as a matter of editorial style rather than a matter of pronunciation. I already know that I would say It's an historic event to see an Hispanic woman elected president without a second thought, as a relatively well educated native speaker. — Carl (CBM · talk) 13:08, 20 March 2008 (UTC)
There seems to be a general trend away from h-dropping, which is really a French feature. In educated BE it may have been accelerated by the following phenomenon: "In England and Wales there are several h-less accents, such as Cockney and Brummie, where the pronunciations an 'orrible 'appening and an 'opeless case are normal" (Oxford Companion). British authors have been using this kind of h-dropping as a means to mark uneducated speakers for a long time. But in the absence of such dialects it is of course seen as more educated to use more conservative pronunciations (or analogues of such). My dictionaries don't even mention the possibility of dropping the h in "historic" or "hispanic", so it's probably best not to do it even in AE. --Hans Adler (talk) 13:47, 20 March 2008 (UTC)
I'm with Tony and others on this one and I don't see that there is a general move away from h-dropping towards RP as in the UK only 2% speak it.[14] When one writes British English (to use an American expression ;) ) one would usually write "an hotel" whatever one's native British accent (or risk loosing marks in those school exams). But I have a question: Americans seem to drop the "h" at the start of "herb" do they say "an 'erb gardern" or "a 'erb garden" and what do they usually write? --Philip Baird Shearer (talk) 16:30, 20 March 2008 (UTC)
In ordinary American english, it's an herb in speech and writing. It's interesting that the OED gives a pronunciation of hotel with an h [15], and calls the one without an h "old fashioned", but lower down uses "an hotel" in writing definitions. — Carl (CBM · talk) 16:42, 20 March 2008 (UTC)
"An hotel" in BE? Losing marks for writing "a hotel"? Are you serious? I can find no evidence in my offline sources that the h can be dropped in this word, and the Collins entry for hotel starts "A hotel is a building…". This source from Oxford however mentions that some people pronounce it that way, and the Google test seems to confirm this. Also, the relevance of RP for the continuum of dialects and accents that is BE can very obviously not be reduced to the number of people who speak it, so long as it is the standard form of the language in British media. --Hans Adler (talk) 16:54, 20 March 2008 (UTC)
It turns out that we already have a nice little entry on h-dropping and h-adding, and that there is a comprehensive blog entry on the topic a Language Log [16]. Apparently the battle between "hotel" with and without h was waged in Britain in the middle of the 20th century, and the h won. --Hans Adler (talk) 19:05, 20 March 2008 (UTC)

(Outdent) Disclaimer: I do not intend to revert changes from "an historic X" to "a historic X" or vice cerca... that said, it seems that there are two issues being discussed here: the 1st was "formal H-dropping" ("an hotel", "an historic X"). This was (is?) taught as "proper English" within Britain (and New Zealand, and possibly Singapore, from my experience (1970s - 1980s)). The 2nd issue is "informal H-dropping" ("'Orace the 'appy 'orse") which is taught as "improper English". The H-dropping article seems only to discuss the latter. That said, it does seem that "formal H-dropping is largely archaic (dammit, I'm old, apparently!) and should be/could be deprecated within Wikipedia?  This flag once was red  19:40, 20 March 2008 (UTC)

Not exactly, it is whether h "makes position" as a consonant and is therefore preceded by a, or does not. The OED cites both; the instances of a hotel are from James Joyce (Right opposite is a hotel particulier of 2 storeys. and therefore a silent h.) and E.F. Wyatt. We should not rule; to make a general rule would be an WP:ENGVAR breach; to rule on British English would be to assert a uniformity that plainly does not exist. Septentrionalis PMAnderson 19:57, 20 March 2008 (UTC)
Anderson, why is the h silent in the Joyce example?? Tony (talk) 08:46, 24 March 2008 (UTC)
Because hotel particulier is French, as the spelling and placement of the adjective should both make clear. Septentrionalis PMAnderson 17:20, 24 March 2008 (UTC)

Trivia

Although it probably has no bearing on this, I should like to mention a historic trivium that I believe is of interest: historic is derived from the Greek word ιστορικός, which has no consonant before it; the h that is added before many Greek words which long ago passed into English was the representation of a rough breathing, which has since disappeared. Ironically, Greeks speaking English will now always pronounce the h (most of them quite strongly, actually; it will often sound like ch), and thus use a instead of an before the word, as I have done in the beginning of this message. Waltham, The Duke of 01:50, 21 March 2008 (UTC)
The classical Greek rough breathing was a consonant (in the modern phonetic sense), however, most likely equivalent to h (ἱστορικός)  ; the Latin historicus certainly had one (which also disappeared in the Middle Ages). But this is trivia upon trivium (hexia?) Septentrionalis PMAnderson 02:19, 21 March 2008 (UTC)
(EC) Hmmm, I find this hard to believe. I would have thought that the word came to English on the route Greek -> Latin -> French -> English, and already in Latin it is definitely "historia". Classical Greek had h in some words, but it wasn't spelled. Since this was a problem for the colonised people who had to learn Greek in the Hellenistic era, an aspiration sign and a non-aspiration sign were introduced, especially for learners. The word "ιστορικός" doesn't include either sign on the first iota, but I would be quite surprised if the word wasn't aspirated [17]. The Romans usually transliterated Greek exactly as it was spoken, and they even updated the transliteration when the Greek pronunciation changed. (That's why the Italians now write "filosofia" - the Greek pronunciation changed.) However, the Language Log link above suggests that there was a time when the h in history was not pronounced in English (probably because it was lost in French), and it was reintroduced later. --Hans Adler (talk) 02:22, 21 March 2008 (UTC)
See Buck's Comparative Grammar of Greek and Latin. The loss of French and Latin h was probably at the same time; the loss of the Greek rough breathing was much earlier, and may well be unconnected. I believe filosofia is a learned borrowing into modern Italian, and reflects mod. Italian spelling as much as anything else; compare Fr. frail and fragile, both from fragilis. Septentrionalis PMAnderson 02:31, 21 March 2008 (UTC)
I wrote the word as it is spelt today, Hans; all words beginning with vowels had one of the two pneumata. (Actually, in school they taught us that the two of them together made up an H, which was added in front of all initial vowels when these words passed into Latin. Go figure.) In any case, I am not that knowledgeable as far as the exact route of the words is concerned; I merely noted their ultimate origin and the paradox of what—in Greek—kind of was, and now certainly is, a word beginning with a vowel, being pronounced—by Greeks—invariably as beginning with a consonant when in English context. I wonder what Xenophon Zolotas would say about this. (I have certainly managed to derail the conversation with this little deviation of mine. Almost; thanks for the heading, Mr Anderson.)
Generally speaking, numerous differences have been noted between the pronunciation of ancient and modern Greek; I should be very excited to hear an Ancient Greek speak a few sentences. I doubt I should understand half of it without having the text in front of me. :-D
Etymology is a fascinating science; pity that I'm not that good in languages, or it would certainly be one of my numerous hobbies. Waltham, The Duke of 03:00, 21 March 2008 (UTC)
Your Grace's most humle & obt Servt Septentrionalis PMAnderson 03:30, 21 March 2008 (UTC)
Indeed, PMA. Petrarch has philosophia. See for example Canzoniere, 7, line 10: "Povera et nuda vai philosophia".
Now tell me where in Buck's definitive volume (among my favourite bedtime reading) I may find anything to support your suggestion that "the loss of French and Latin h was probably at the same time". One might even ask, what loss of Latin h? Certainly there was inconsistency in Medieval spelling of Latin, so that h might frequently be omitted or erroneously supplied. And certainly there was variation in pronunciation to match. But weren't there norms in liturgical usage at least, to guarantee conservation? Indeed, wasn't the spoken h strengthened to a /k/ (intervocalically, in "nihil" for example), in some liturgical practice?
Harrington's Medieval Latin informs us that there was "incorrect use of aspirates", with both omissions and insertions (p. xxv). In Sidwell's Reading Medieval Latin we read that "local dialects and languages dictated the actual sounds produced" (p. 373). But this is hardly h being "lost".
–⊥¡ɐɔıʇǝoNoetica!T– 10:52, 25 March 2008 (UTC)
The strengthening, as Buck says quite clearly (look up nichil in the index), was an artificial reaction to the general loss of h, to preserve liturgical usage. That's why they hypercorrected to a guttural sound. Septentrionalis PMAnderson 23:07, 26 March 2008 (UTC)

Exponential notation

I see that Tony has been running all over Wikipedia declaring that {{E}}, which produces exponential notation is a "MOS breach", because it doesn't space the '×'. We do quite rightly commend spacing 4 × 4, but that's actual multiplication. Since discussion at Template talk:E has turned up much sentiment and some evidence that exponential notation is sometimes closed up, adding a clarifying sentence seemed warranted. Septentrionalis PMAnderson 02:31, 21 March 2008 (UTC)

Scientific notation is actual multiplication. It's just that many well-edited publications choose to use different typography for it than other types of multiplication. --Gerry Ashton (talk) 02:54, 21 March 2008 (UTC)
My concern is that WP's mode and register are different from those of such "well-edited publications" that choose the squashy version (μ0 \ \overset{\underset{\mathrm{def}}{}}{=}\ 4π×10−7 H/m; 1.60217653×10–19 C). We aim to be accessible to a wider range of readers than most specialist scientific publications; this is one of WP's most valuable contributions to the wider world—providing a window by which non-experts (and experts in cognate disciplines) can approach and understand scientific topics that are otherwise embedded firmly in the ivory tower. The mechanics of achieving this come right down to the seemingly trivial: not insisting that our readers negotiate large items of scientific notation that appear as lumps, in which the all-important factorial sign is squashed in with the other symbols. I need to squint and get close to the screen to comprehend the larger ones. Consistency with the use of the multiplication sign elsewhere, as now mandated by MOS, is the obvious solution (μ0 \ \overset{\underset{\mathrm{def}}{}}{=}\ 4π × 10−7 H/m; 1.60217653 × 10–19 C). We're not so short of space as to be unable to grant our ordinary readers the right to read scientific notation a little more easily. Some respected scientific publications use the spaced version, in any case. Tony (talk) 03:06, 21 March 2008 (UTC)
I find the "squashy version" somewhat easier to comprehend as a single number than the spaced out version—much the same reaction as many have to the spaced emdash. But it is a matter of taste; if editors agree that the spaces assist comprehension, they will insert them. Since both are standard notation, why do we need to legislate? Septentrionalis PMAnderson 03:26, 21 March 2008 (UTC)

PMA, this pages needs to be stable; please stop making undiscussed controversial changes, as that editing method doesn't make the best use of anyone's time. SandyGeorgia (Talk) 16:28, 21 March 2008 (UTC)

Neither does your reversion. This very section discusses the change, which also reflects the discussion at Template talk:E. Septentrionalis PMAnderson 16:34, 21 March 2008 (UTC)

Careful there with your edit summaries, PMA. SandyGeorgia (Talk) 16:38, 21 March 2008 (UTC)

Perhaps I was less than temperate; but those who wish not to be called revert warrior should avoid reverting, especially with non-factual edit summaries. Since silence permits both versions, there is no change in guidance here, merely clarification; it is Tony's new doctrine which is both novel and unilateral. Septentrionalis PMAnderson 21:09, 21 March 2008 (UTC)
  • But upon reflection, I shall retract; I would avoid the bad example of the editors who get their way around here by continual invective. Septentrionalis PMAnderson 22:52, 21 March 2008 (UTC)
    • Two personal attacks: one directly explicitly at Sandy, another as a spraying of those around you. Please desist. Tony (talk) 02:44, 22 March 2008 (UTC)

I agree that the unspaced version should be permitted; it is conceptually different to normal multiplication. Consider 1.37×1013 × 4.29×109 vs 1.37 × 1013 × 4.29 × 109, and for completeness 1.37×1013×4.29×109. Now, the unspaced (third) version is fairly obviously horrible, while the partially-spaced (first) version clearly indicates that you're talking about two distinct numbers being multiplied, with those numbers written in standard form, while the fully spaced (second) version looks like 4 separate numbers. Hence, I personally prefer the first version. SamBC(talk) 18:06, 21 March 2008 (UTC)

Exponential notation involves one number; multiplication two. Septentrionalis PMAnderson 21:09, 21 March 2008 (UTC)
It's also not a terribly advanced concept. Plenty of pocket calculators write such numbers as 1.37 13 etc., so quite a lot of people (especially among those who are likely to encounter the notation in articles) are used to the idea. --Hans Adler (talk) 21:26, 21 March 2008 (UTC)
So what do you think about spacing? Septentrionalis PMAnderson 21:36, 21 March 2008 (UTC)
I think I said that above already. I would prefer a prescription to drop spaces in this case. Btw, I think it should also be allowed to drop the spaces in some other cases. E.g. compare:
  • a × b + c
  • a×b + c
  • (a × b) + c.
These are all equivalent, but often the second version is the best. --Hans Adler (talk) 22:16, 21 March 2008 (UTC)

Septentrionalis wrote "exponential notation involves one number; multiplication two." That all depends on what you think of as a number. For example, 1.37×1013 is a multiplication of two numbers, 1.37 and 1013. In some contexts, a person might choose to view it as one number; it depends on the situation. --Gerry Ashton (talk) 21:42, 21 March 2008 (UTC)

In terms of the very concept of standard form, the idea is that it represents a single quantity. Of course if there happens to be a mathematical expression where one quantity is multiplied by a power of ten, that's not the same thing, but where it is honest-to-goodness scientific notation/standard form, it really is only representing one number. It's rather the point, that it's one number that is being represented in a way that allows seperate focus on the significant figures and the order of magnitude. SamBC(talk) 21:59, 21 March 2008 (UTC)
I grant Gerry's point of principle; I'm not sure what conclusion he draws from it. Most of the time, we will be treating 1.37×1013 as a single number, exactly as if it were written out as 13,700,000,000,000. (I hope I counted correctly, which is why to use exponential notation in the first place; please emend.) If anything, this would seem to be an argument for flexible spacing: space if treating as two numbers, close up if one. Septentrionalis PMAnderson 22:49, 21 March 2008 (UTC)

N.b: I've posted a note about this discussion at WT:MOSNUM, as recent friction makes me think this is a good idea. SamBC(talk) 22:03, 21 March 2008 (UTC)

  • All: As amply noted above, coding {{e|9}} and {{subst:e|9}} omits spaces on one side of the × sign and returns ×109. Effectively, for balance, this means one must code 1.23{{subst:e|9}} to obtain 1.23×109 so there is no space on either side of the × symbol.

    I’m sure there are different ways to format scientific notation and I suppose that the above method isn’t “wrong.” However, the way it has been implemented by certain influential standard bodies is a very common and exceedingly professional way to do it. Please see NIST:Fundamental Physical Constants, as well as SI Brochure: 5.3.5 for examples of proper formating in this regard.

    This oversight is being addressed in the {{delimitnum}} magic word, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies. The primary purpose of this magic word is to delimit long strings of numbers. For instance, number strings like this: e = 2.718281828459, which actually appeared in Natural logarithm until recently, will instead appear as follows: e = 2.718281828459. The full-featured use of the {{delimitnum}} will allow an editor to type {{delimitnum:6.02246479|30|–23|kg}} in order to obtain the following: 6.02246479(30)×10–23 kg. Another slick little thing this magic word does: The delimiting gaps in the significands are not non-breaking spaces; it uses character-placement tricks so you can copy the values and paste them into programs like Excel, where they will be recognized as real numeric values. Go ahead, select the above black-text value by slowly dragging your cursor across it. Notice how the selection snaps across the gaps?

    Please note that the magic word and its appearance was extensively debated here at Talk:MOSNUM, Archive #94, it achieved near unanimous consensus (only one hold-out), and was advanced to be written by one of Wikipedia’s behind-the-scenes developers.

    Current articles using the {{e}} template will be unaffected so editors who like having no spaces alongside the × symbol will see no change in articles that currently use it. Those editors who want to avail themselves of the new, very powerful {{delimitnum}} magic word will be able to do so once it becomes available. And of course, for those editors who choose to, existing articles can easily be converted to the {{delimitnum}} magic word using global search & replace in their text editors. Greg L (my talk) 23:28, 21 March 2008 (UTC)

  • Is it possible to put a switch on {{delimitnum}} so that spacing can be avoided where it is not wanted (as SamBC and Hans argue above)? THat might be the best solution. Septentrionalis PMAnderson 23:52, 21 March 2008 (UTC)
  • Pmanderson: Well, I note that you weighed in on this issue a number of times on Talk:MOSNUM and hadn’t raised this issue. But, yes, I suppose a “toggle-space option” could be implemented. However, note that every single aspect of this template was debated for a long time by many users—including you—at Archive #94 of Talk:MOSNUM and everyone was quite pleased with the proposal. It seems to me that that was the time to raise appearance issues like toggling spaces alongside the × sign so all the others could weigh in on the subject. Does it strike you that now is the time to try to change things after all that discussion has transpired (and after a near-unanimous consensus has already been achieved)? There were one or two things I might have changed after-the-fact on this template myself but I was disinclined to even head down that path since I have been entrusted with shepherding the group’s consensus decision through to completion in good faith.

    Having said all that, I realize that the full-width non-breaking spaces alongside the × sign are probably too wide. I am rather familiar with the nature of the problems the developer is facing. Please bear in mind that the developer is a volunteer in all of this, just like you and I, so we don’t want to be hitting him up with a whole bunch of “Oh, we changed our damned minds.” Last I checked, he had all the code done on the magic word and was trying to compact the code to make it tight and tidy. However, I think it should be fairly easy for the developer to change to gaps to thin spaces. In fact, I changed the above example to thin spaces on both sides of the × sign. In fact (again), this issue was one of the very things on my mind that I wanted to change on my own but was disinclined to do so in order to properly discharge my duties as a good shepherd. I really doubt anyone else who weighed in on this on Talk:MOSNUM would have any objection so I am inclined to contact the developer and ask him to do so. Going with narrow, span-based gaps alongside the × should be a good compromise for all and, besides, has the virtue of introducing some standardization across articles on Wikipedia, which has to be a good thing. Greg L (my talk) 00:25, 22 March 2008 (UTC)

It didn't occur to me that spacing was a problem until Tony made it one; my own preference is mild, and I tend to avoid magic words for formatting I can do myself. No rush; at the moment we are merely discussing what WP's practice is, not whether delimitnum is configured to do all of it. (A switch would be best, expecially if there are still technical reservations about thin spaces, as I recall from the discussion.) It would be nice if it could. Septentrionalis PMAnderson 00:44, 22 March 2008 (UTC)
  • Well, Tony was there on Talk:MOSNUM too. You’re getting by on this one by the hair of your chinny chin chin Tony. But I agree; full-width spaces look too wide and I was wondering why it was only me with nagging doubts about it. We can’t offer an option to elliminate them entirely or even provide a toggle option without violating the spirit of the process. Nor do we want to for fear of pissing off the developer. So…

    All: We need to hustle if we’re to make this change. The hard part in all of this is ensuring something looks good on a variety of platforms. I personally work on a Mac using Safari and gaps tend to look too narrow. If I use FireFox, things look wider and that’s what many Windows users on IE and Firefox see. Before we badger the developer, please see this special sandbox section (the portion titled “Experiment with narrow spans alongside × sign”). Please advise, here on this forum, whether the gaps look acceptable on your system. Greg L (my talk) 00:59, 22 March 2008 (UTC)

  • Thin spaces would be ideal, but the problem has been that they tend not to display correctly on ... you guessed it, the great Internet Explorer 6. Perfect on Safari, of course. However, just because of stupid IE, I'm not in favour of squashing the notation together. Think of non-specialist readers, please. Tony (talk) 02:13, 22 March 2008 (UTC)
  • Tony, when you look at this value using IE 6: 6.02246479(30)×1023 kg, the spaces on each side of the × symbol has got to look wider than having no space at all, which is what a lot of other editors are pushing for. Please note that the BIPM’s approach is to use the same thin spaces as are used here for delimiting. If we don’t yield a little on this point and squash the gap a tad, this tool isn’t going to be as well received and widely adopted as it could if we insist on full-width, non-breaking spaces. If we don’t go with the flow on this and at least compromise with narrow gaps, this could end up in a big pissing match. I think thin spaces are the perfect compromise here. Given that this is the style used by the BIPM and (kinda sorta) by the NIST, is icing on the cake. Anyway, I’ve received your e-mail of your first screen shot of what you’re seeing and am awaiting your next one. Thanks. Cheers! Greg L (my talk) 02:59, 22 March 2008 (UTC)
  • P.S. The change has been advanced to the developer and there is no need for further input on thin-space appearance. I know how the spaces will look on everyone’s platforms (I’ve spent more time on this sort of thing than you can imagine). The tradeoffs are complex and greatly limit the options. For instance Safari, which uses anti-aliasing on its fonts (both Mac and Windows) makes em-based gaps appear narrower than other browsers. Also, Safari doesn’t resolve to 0.05 em, only to 0.1 em. But Safari rounds 0.25 em up to 0.3 em and this characteristic can be exploited to our advantage. Further, to keep a balanced visual appearance on both sides of the × symbol, one needs to specify the span gaps asymmetrically. In the end, there was only a single solution that came close to balancing all the different—and sometimes conflicting—criteria. The full-tilt use of the {{delimitnum}} when an editor types {{delimitnum:6.02246479|30|23|kg}} will appear as 6.02246479(30)×1023 kg Greg L (my talk) 01:58, 22 March 2008 (UTC)
EB, Encarta, and various online scientific journals all use something that is approximately one space, maybe a little narrower, when listing a single number in scientific notation, surrounded by text; probably everyone has seen this, but if not, search for "Avogadro's number" or "electron charge" in an online encyclopedia. I have no problem with the proposal to have our scientific notation template use a slightly smaller space. On the other hand, the practice is common among scientists and engineers to squash things together as an expression gets longer, including in journal articles, and spaces in scientific notation are some of the first things to go, in my experience. It's more difficult to demonstrate "tendencies" with links, but if anyone doubts this, I'll comb through a relevant journal and do some counting. We don't have so many Wikipedia pages filled with complex equations that this needs to be considered now, but I'm hopeful that we'll have to consider it in the future. - Dan Dank55 (talk) 04:40, 22 March 2008 (UTC)
  • Greg L, I'm very very happy with thin spaces. Tony (talk) 08:02, 22 March 2008 (UTC)
    • Me too. I advocated no spaces in the previous discussion on this, but I think that thin spaces are an excellent compromise.--Srleffler (talk) 14:39, 22 March 2008 (UTC)
    • Indeed, thin spaces are a good compromise; regarding the magic word, it using thin spaces would be great, although how thin is going to be a great recipe for prolonged debate. In terms of recommendations for hand coding, however, I think it would be awkward to prescribe them, and I have no problem with any of unspaced, narrow-spaced, and fully spaced being allowed. Perhaps it should be worded to indicate that thin spaces around × in scientific notation are recommended, but both unspaced and fully spaced are acceptable alternatives. SamBC(talk) 15:15, 22 March 2008 (UTC)
      • Thinking further, it's possibly worth noting that there are various reasons that different situations meriting different spacing. For example, narrow or full spacing is most appropriate when it's one number in scientific notation, especially in a body of text, while zero or narrow spacing are more appropriate in expressions as they get more complex, to clarify which are individual values. Some of this might be more appropriate in MOSNUM than in the main MOS, though. SamBC(talk) 15:21, 22 March 2008 (UTC)
        • How about Exponential notation can be spaced or unspaced, depending on circumstances. The magic word {{delimitnum}} will often be useful, adding thin spaces when the developers implement them? Septentrionalis PMAnderson 16:01, 22 March 2008 (UTC)
          • I don't think the MoS should mention the magic word until it is actually active. For now, how about just "Exponential notation can be spaced or unspaced, depending on circumstances."?--Srleffler (talk) 16:42, 22 March 2008 (UTC)
      • See above. I think "how thin" has already been resolved, and sent to the developer working on the magic word.--Srleffler (talk) 16:42, 22 March 2008 (UTC)
  • That’s right Srleffler. All: A magic word is being worked on by one of the behind-the-scenes developers that will give us a powerful new tool known as {{delimitnum}}. Its main reason for existence is to delimit significands using thin gaps that are not non-breaking spaces; it uses <span> character-placement techniques so you can copy the values and paste them into programs like Excel where they will be treated as numeric values. It does much more than that though; it is a full-featured tool that handles every common aspect of modern numeric equivalencies, spaces each piece properly, and keeps all parts from doing line-end word wraps. Coding {{delimitnum|6.02246479|30|23|kg}} yields 6.02246479(30)×1023 kg. It takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol.

    My stop here on Talk:MOS was valuable. I mentioned the upcoming availability of the magic word and quickly realized there were strong proponents of having no gaps at all in scientific notation for various reasons (e.g. 1.28×106). The function and appearance of the magic word had been extensively discussed on Talk:MOSNUM and the original intention was to put non-breaking spaces on both sides of the × symbol. That has changed now. The developer has been alerted to use thin gaps on both sides and I’m pleased everyone here is satisfied with that solution. The exact gap width varies from platform to platform, browser to browser, and the font preference you’ve set in Wikipedia preferences, but the magic word will produce results for you that are precisely as shown in these examples:

       {{delimitnum|2.718281||6|Hz}} → 2.718218×106 Hz

       {{delimitnum|1.2||6|Hz}} → 1.2×106 Hz

       {{nowrap|''e'' ≈ {{delimitnum|2.718281828459}}}} → e ≈ 2.718281828459

    Note that there is a template by the same name but it doesn’t reliably work with all numbers so be sure not to use it. Like the rest of you, I’m waiting anxiously for the new magic word to be delivered to us. Greg L (my talk) 22:13, 22 March 2008 (UTC)

  • I'm not comfortable with the mandating of the squashy version at all. Let's wait until the template is worked out before leaping in to change long-standing wording. Tony (talk) 01:26, 23 March 2008 (UTC)
    • Only one editor has suggested mandating the "squashy version", and the present text, incorporating the wording agreed above, does not mandate anything. (The previous text didn't either; it didn't mention exponential notation at all.) It may be more elegant to group the two cases in which we need not space as follows, but this is a style point:
      *For a multiplication sign between numbers, use ×, which is input by clicking on it in the edit toolbox under the edit window or by keying in &times; (however, the unspaced letter x is accepted as a substitute for by in such terms as "4x4", and exponential notation can be spaced or unspaced, depending on circumstances).
      Septentrionalis PMAnderson 01:44, 23 March 2008 (UTC)
  • No, your new wording does mandate the squashy version; the current wording forbids it. Consensus is not easy to judge, and here, too many users have expressed mild to strong opposition to the squashy version. To make a major change to the guideline while the delimitum template is nearing completion, and given that users such as Sleiffert have agreed to the thin-space solution, is inappropriate. I'm reverting. Tony (talk) 03:05, 23 March 2008 (UTC)
    • The current wording, depending on how you read it, can also be interpreted to say nothing on the issue. I don't believe it is unreasonable that this section should say something about exponential notation. If there is a strong consensus that it should be one way or the other, it can say so, but no such consensus is evident here. Barring such a consensus, best to say that either method is acceptable. Christopher Parham (talk) 03:29, 23 March 2008 (UTC)

Multiplication signs are multiplications signs, whether they occur in 20 × 60 or in exponential notation. I regard the view that such notation is unitary as compelling as the argument that 20 × 60 is unitary. Since several people have expressed opposition to the squashy version, I see no consensus that the wording should be changed to allow it. At the very least, it would require a formal vote, i.e., a formal opportunity to list support/opposition to proposed wording). Would you like to set this up? Tony (talk) 03:34, 23 March 2008 (UTC)

I disagree that this is needed; we don't require votes to edit guidelines and the lack of a consensus to mandate a particular style is evident from the discussion above. Therefore it should be made clear that no particular style is mandated for exponential notation. No change to the meaning of any existing text has been made, that I can see. Christopher Parham (talk) 03:39, 23 March 2008 (UTC)
Tony, are you familiar/experienced with the use of exponential notation (or Standard Form as we call it in the UK)? Read the article on it, and you might get the sense of the fact that writing 1.53×103 is considered equivalent to writing 1530, and that in both cases it's considered one number; 1.53×103 is a way of writing the number conventionally written as 1530. IME, thinking or talking about it in any other way seems very strange to anyone who does work in standard form on a regular basis. 6.022×1023 is Avogadro's number, not Avogadro's expression. I'm not sure how else to get this across... SamBC(talk) 13:30, 23 March 2008 (UTC)
  • Dispute tag added. Tony (talk) 03:40, 23 March 2008 (UTC)
    • Does anyone else dispute the present wording, which is (as will be seen above) Srleffler's suggestion? I and (if I read correctly) Christopher Parham support it. That's 3-1; does Tony's dispute have a second (parliamentary)?
    • Can anyone, including Tony, explain how Exponential notation can be spaced or unspaced, depending on circumstances mandates not spacing it?
    • As an alternative, can anyone suggest wording which says more clearly that we do not make a mandate on the subject?
      • Perhaps the dispute tag does that, since its effect is to cast doubt on the requirements the section does mandate. Since Hans does in fact object to them, this may be desirable, but I don't see why our prescriptivist wants it. Septentrionalis PMAnderson 20:44, 23 March 2008 (UTC)
        • Please note that "3-1" requires an en dash, not a hyphen. The mandate lies in the word "unspaced". Three people do not make a consensus. Tony (talk) 12:44, 24 March 2008 (UTC)
          • Hyphenation depends on the degree of formality; unlike spelling my name correctly, which would be civil at any level. A supermajority of 75% is often Wikipedia:Consensus in our idiosyncratic usage of the term, and I see SamBC agrees with the intent of the present wording also. But there's no rush in removing the tag; its presence accomplishes my ends here as well as any text would be likely to do. Septentrionalis PMAnderson 16:14, 24 March 2008 (UTC)
  • Where did you dredge that one up—this sudden link between punctuation and formality? Looking up at your signature in the edit box, it's hard not to see manderson. Tony (talk) 01:50, 25 March 2008 (UTC)
    • The same place Dank55 did: experience. This is an informal conversation, conducted by typewriting, not an act of publication, which article space would be.
    • And you do pique my curiosity; nobody else sees my user name as Manderson; does someone call you Ony? Septentrionalis PMAnderson 03:02, 25 March 2008 (UTC)
      • This is what I see: Pmanderson, as though "Peter Manderson", repeated just for emphasis. [[User:Pmanderson|Septentrionalis]] <small>[[User talk:Pmanderson|PMAnderson]]</small> 03:02, 25 March 2008 (UTC) Tony (talk) 12:19, 25 March 2008 (UTC)

I'm a little late here, and I think the present wording is fine, since obviously there's no consensus. But I'd like to weigh in with my opinion anyway, because I think some of the arguments here are a little silly. There's no precedent to the idea that when you combine two things, you have to spell them as one word. There can be several words to refer to a single item. Ice cream? That's one thing. The University of Pennsylvania? That's one thing. Two hundred and three? That's one thing. 1 × 1023? That's one thing. Even 2 + 2 is one thing. It's 4, and it's four, and it's 22, and it's 2 + 2, and it's 4 × 100, and it's 1 × 100.60206, and there are many different ways you can spell it. You could call it 1 × 110.57813 if you wanted to. Why be inconsistent just for scientific notation? Yes, scientific notation is the standard way to express large numbers. But scientific notation is just multiplication and exponentiation. It's not a special case, it's just as legitimate as any other expression. It's just the expression we agreed on.

My point, and my opinion, is: Scientific notation should be spaced exactly the same way that multiplication is. The beauty of math notation is that it's perfectly consistent and modular; it's not weirdly ambiguous and full of special cases the way English orthography is. Let's not ruin it. —Werson (talk) 02:24, 1 April 2008 (UTC)

Changing punctuation in direct quotes

I have seen editors making changes to direct quotes citing the MoS. For example I saw someone modify quoted text using a double-dash cut-and-pasted from the original, changing it to an em-dash with a comment citing WP:MOSDASH. Although this specific case is not a major issue, I think we need to remind people not to be editing direct quotes, regardless of good intentions. I have seen similar issues with people editing items from the 'quote=' field in {{cite}} templates as well. I have added preserving punctuation to the WP:MOSQUOTE section to cover this. Dhaluza (talk) 00:10, 22 March 2008 (UTC)

While I agree with not changing punctuation in direct quotes (unless the change is marked with square brackets), I'm not sure the same reasoning applies to mere changes in typography. A double-hyphen is not a different punctuation mark from a dash; they are different typographic representations of the same symbol.--Srleffler (talk) 04:28, 22 March 2008 (UTC)
Changing a double-hyphen to an em-dash is sort of like changing the font, or turning straight quotes into curly quotes. Strad (talk) 05:16, 22 March 2008 (UTC)
I agree regarding typographic changes (that they're fine), and I think we ought to make it clear in MOS that it is okay to make such changes, for example changing a hyphen (or double-hyphen) used as a dash into an actual dash. I'm sure there are other such examples, probably including simple spacing issues and so on. Otherwise, we'd have to argue that the quote appear in the same font (or at least font family), with line breaks in the same places, and so on. SamBC(talk) 15:05, 22 March 2008 (UTC)
The difference between "logical" and "aesthetic" punctuation of quotes is also typographic. Aesthetic punctuation treats ," in Smith wrote that "the Foolanders ran away," but Jones replied that this was a Barlander smear. as a single purely formal mark, which denotes both the end of the quote and a comma in the larger sentence. Septentrionalis PMAnderson 15:54, 22 March 2008 (UTC)
I'm not familiar with all the options on various search engines. If the order of a comma and quotation mark are reversed, or if two hyphens become a dash, how likely is it that someone will search for a quotation in Wikipedia and get no hits as a result of the fact that we changed the punctuation? Certainly "not usually" ... but will it happen? - Dan Dank55 (talk) 17:21, 22 March 2008 (UTC)
The reverse is apt to be a problem: if someone goes to a long source, cuts a quote from Wikipedia, and pastes it into the browser's search feature, any variation in punctuation will prevent the quote from being found. --Gerry Ashton (talk) 17:24, 22 March 2008 (UTC)
(edit conflict) I have no idea what the answer to Dank's question is; but changing double-hyphens to emdashes will probably have the same problem. A searcher who finds no results really should trim the quotation anyway, or (for Gerry's problem) consult our listed source. Septentrionalis PMAnderson 17:28, 22 March 2008 (UTC)
If there is a source, that is.
I did have the same question however, and I was rather hesitant to make any changes, although I wanted to. In my opinion, simple edits to quotation marks and dashes should be considered acceptable. Waltham, The Duke of 20:11, 22 March 2008 (UTC)
I believe most search engines ignore punctuation. I tried searching for the specific text with both the double hyphens and the em-dash and got the same results in Google. So that is probably not an issue. The issue is that if they are typographocally equivilant, then that is reason not to change, rather than reason to excuse the change. Making stylistic changes to direct quotes can do more harm than good, because what seems like a benign change, may not be. This is less like changing fonts, and more like changing spelling between British/American versions. We should respect the original author's choice of punctuation marks in quotes, and leave them alone. Dhaluza (talk) 09:03, 24 March 2008 (UTC)
The more I think about it, the more I agree with Dhaluza. Sure, I tend to try to fix punctuation to reflect what I think is the author's true intent, even in a quotation, and I will try to exercise enough self-awareness to keep my own biases from affecting my choices, and enough awareness of different punctuation practices to help me understand what was meant in the original and what might be understood in an alteration. But changing punctuation can easily change the meaning, and changing the meaning is unacceptable when you use quotation marks to attribute the words to someone else. Will every editor know the whole range of options in punctuation, not just the punctuation that they tend to use? I could see some limited exceptions if necessary, but in general, it seems to me it would be better to leave punctuation inside a quotation alone. If an editor thinks that the quotation might be misunderstood, because of punctuation or otherwise, they can explain that outside the quotation marks. - Dan Dank55 (talk) 20:32, 25 March 2008 (UTC)

Request for input

There a discussion about the use of italics in parenthetical disambiguating phrases at Wikipedia talk:Manual of Style (titles). The issue is something of gray area in the intersection between Wikipedia:Manual of Style (titles) and Wikipedia:Manual of Style (disambiguation pages). Input from editors familiar with stylistic issues is welcome. older ≠ wiser 14:34, 23 March 2008 (UTC)

Periods in captions

This page insists that sentence fragments in captions may not end in periods. We might do better to follow WP:Captions which says

Most captions are not real sentences, but extended nominal groups; for example, "The Conservatory during Macquarie Night Lights, a summer festival" (no final period), and "The Conservatory was spotlit during Macquarie Night Lights, a summer festival." (full sentence with final period).

an observation, not a mandate. This is another matter on which we should not rule, but permit: it is perfectly idiomatic to end a sentence fragment with a period, even when it is not necessary. We should not be encouraging FA opposes for a legitimate stylistic choice; it makes the whole process silly. (If anyone finds the edit summary for this present edit unidiomatic, please let me know, and be prepared to cite authority.) Septentrionalis PMAnderson 22:00, 23 March 2008 (UTC)

  • Our existing rule is also complicated: a sentence fragment by itself may not be punctuated; a sentence fragment with complete sentences must be punctuated. I'm sure this has resulted in opposes to captions which the rule actually supports. First, do no harm. Septentrionalis PMAnderson 22:25, 23 March 2008 (UTC)

I would propose, therefore, to change one word to nominal groups which need not end with a period. This should also dispel any illusion that fragments (even out of captions) never have periods, which would be regrettable. Septentrionalis PMAnderson 22:33, 23 March 2008 (UTC)

    • I don't find your dot unidiomatic, Manderson—merely silly. Like every character and character space, dots should be used stratagically. They are, inter alia, a grammatical device that flags the end of a clause complex. The caption cited above (BTW, the title is wrong—it's "Conservatorium") is merely a sentence fragment, and in no need of an. idle. dot. As for you claim that "we should not rule, but permit": rules do permit, and provide the scaffolding that hold together a cohesive body of text that might otherwise appear scrappy. I'm not debating this further, so write what you like. Tony (talk) 01:37, 24 March 2008 (UTC)
      • Just an observation: I have recently seen a caption where a full sentence ending in a full stop was succeeded by a sentence fragment without one. It is probably bad style in most cases, but in that example (which, unfortunately, eludes my memory) I remember that it was surprisingly fitting. Are we sure that there is no merit in that? Waltham, The Duke of 08:38, 24 March 2008 (UTC)
        • Good point, which came up a month or so ago, resulting in a change in the wording to point 3: "If a complete sentence occurs in a caption, it and also any sentence fragments in that caption should end with a period." BTW, who inserted the dispute template there? Wouldn't have been ... um ... Manderson, would it? Tony (talk) 08:43, 24 March 2008 (UTC)
A document confirming the surrender of deeds by Naomhán Mac Eóghainn and his wife, which Walter oversaw
A document confirming the surrender of deeds by Naomhán Mac Eóghainn and his wife, which Walter oversaw

This example is what brings it up: a long caption, containing a comma, in which a reviewer wishes to remove the terminal period, as at right. This seems clumsy to me, where say, "The document of 1365" would not be. Septentrionalis PMAnderson 16:35, 24 March 2008 (UTC)

Loanwords and the inclusion of original terms in parentheses

Hi all. We are having a bit of an issue over at Za'atar that I was hoping to find a solution to in the MoS, but it's not explicitly covered. The issue surrounds which languages should be included in the paratheses after the bolded term. It has been established, using reliable sources that the term Za'atar comes from the Arabic term زعتر. So the entry was composed to read Za'atar (Arabic: زعتر‎, also satar and zahatar). There are, however, a couple of editors, who though they do not dispute the Arabic etymology of the term, have been adding the Hebrew translation alongside the Arabic, claiming that this is standard practice at other pages and that many languages can be listed alongside the English one and that this distinction is not reserved to the language from which the term came. I was wondering what the thoughts of people here were on the general principle - i.e. Should other languages be listed even when they are not the language from whence the term derived? Or more generally-speaking, what are the guidelines governing the listing of languages after the bolded term? Thanks. Tiamuttalk 23:48, 23 March 2008 (UTC)

Thanks for raising this. For some time, I've been concerned at the common, apparently unthinking practice of inserting non-Roman transliterations of items, in parentheses in the main text. There are three disadvantages: (1) significant clutter and even damage to the visual appearance of the page, even where the non-Roman script has its own beauty; and (2) the fact that non-Roman scripts are meaningless for almost all English-speakers, and (3) the fact that even where a reader of en.WP does read a non-Roman script, only occasionally will the insertion be useful.
Take the article on Guqin, a beautiful Chinese musical instrument, as an example. Here's the lead uncluttered, assuming that all of the Chinese items appear at the bottom of the article in a glossary, for the use of specialists who may wish to verify or net-search them using the Chinese characters. Try reading the first paragraph of this: Uncluttered
and of this, the version as it is (or will be when one of the owners reverts it): Cluttered
Precisely for the same reason that we don't like bolded terms strewn throughout the normal text, I think this practice should be avoided, except in cases where it appears to be overwhelmingly useful. It's one thing to have the non-Roman script in the infobox, in references at the bottom, and in a Glossary at the bottom, but quite another to make the reading experience needlessly bumpy for almost all readers. You wonder sometimes whether the inclusion of non-Roman script is a habit—like a bodily twitch—born of the belief that it's ornamental. My advice is: "Please don't, not for that reason, anyway." I wonder what on Earth the editors had in mind here in inserting Greek and Hebrew lettering against the Roman transliteration; it's not as though either word is abstruse or likely to prompt a web-search using the original script, is it? Pretentious? It may well be.
Therefore, I advise Tiamut and colleagues at the article on Za'atar that both Arab and Hebrew scripts would be just fine in a glossary at the bottom. One original equivalent cluttering the opening would be regrettable; two would be just silly. Tony (talk) 07:07, 24 March 2008 (UTC)
I agree that the uncluttered version is much better; however, I will not accept banishing the native versions from the articles. (I am not saying that you have suggested as much; I am merely making a statement.) They are informative, interesting, and encyclopaedic, and they should definitely be accessible. Infoboxes and footnotes are good positions for them, although the name of the article's subject could, perhaps (if there is not too much stuff in the lead sentence already), be an exception. A single word is certainly not as disruptive as five or ten of them. Waltham, The Duke of 09:15, 24 March 2008 (UTC)
This would be ornamental, then? Tony (talk) 10:21, 24 March 2008 (UTC)
Thank you for your feedback everyone. Tony, I agree that more than non-romanized name can lead to to clutter. I tend to agree with Waltham that one original non-romanized name can be safely included without being disruptive to the reader. It's not merely ornamental since many Wikipedia readers do have knowledge of other languages and those who don't can benefit from seeing the script in its original form. However, I don't mind placing the romanized transliteration only in the introduction and moving the non-romanized name to an infobox. I never thought about that option and appreciate the idea.
I was wondering if editors were interested in formulating a guideline that is more explicit about this issue so that future problems such as this could be avoided. The same debate has plagued Falafel for example and gets worse when it involved place names like Jerusalem which are claimed by more than one national group (in which case the names appended have little to with etymology, and more to do with how the different national groups name the place). Again, thanks for the creative solutions and feedback. Tiamuttalk 11:36, 24 March 2008 (UTC)
One more thing, there is no appropriate infobox that can be used for Za'atar (I was hoping to find one and use it for the non-romanized original, per Guqin.) So I guess we are back to where we started. What non-romanized words would be appropriate for inclusion in the lead, or is there a consensus that there should be none at all? Sorry to harp on this, but we need to have some neutral outside feedback to resolve this issue and regular MoS editors seem to be as good a place as any. Thanks. Tiamuttalk 11:45, 24 March 2008 (UTC)
There is currently an RfC at Talk:Hummus including the statement, "To label this an Israeli food or Jewish food is an insult to Allah and all Muslims & Arabs everywhere." There's another NPOV discussion at Talk:Falafel#Israeli and Arab falafel. Za'atar says, "For Israeli Jews, zaatar used to be an exotic treat associated with visits to Arab bakeries." The question of whether to mention the Hebrew name in the lead, on these words at least, probably should be decided more on the basis of NPOV issues than style issues, but we can say (and do seem to be saying) that the non-roman script is a negative factor. - Dan Dank55 (talk) 12:53, 24 March 2008 (UTC)
I purposely avoided bringing Hummus into this discussion precisely because there is much disagreement over whether or not the term comes from Arabic alone, and it therefore is not a good example for the question I raised. In the case of Za'atar and Falafel, there is no serious source-based contestation regarding the words Arabic origins. And by the way, I don't think selectively highlighting the worst examples of POV soapboxing on the Hummus talk page is necessarily a constructive way to approach this issue. Tiamuttalk 16:57, 24 March 2008 (UTC)
  • I think it's a matter of balance; just a single item at the beginning, well, I guess it won't do much harm, and there's no point in a glossary for just one transliteration. But Guqin is over the top, and needs to be a smooth, attractive read for non-experts, with a glossary at the bottom for those countless items that are transliterated on the spot, and the wiktionary Chinese-character links (which are of questionable use). But I'd like editors to think twice about the way they manage non-Roman script in their articles, and not to automatically include in the run of the text as I see all too often. A MOS guidelines might be in order, just stating that where there is advantage to the readers of transliterating a significant number of items into a non-Roman script, consideration should be given to their listing in a glossary at the bottom rather than in parentheses after each item in the main text.
  • ____ Space for Anderson to launch his "Strong oppose".

Tony (talk) 12:40, 24 March 2008 (UTC)

In fact, I don't strongly oppose; although if we have more than two or three different names for the subject of the article, we probably have something interesting to say about its history or etymology, and should present the results in a full section, as at Bratislava or antimony. The rule of thumb that we should include the Fooish form if it is used in a tenth of the English sources on the subject of the article seems quite reasonable; it would take subject experts to see how it applies here. It may be that the underlying dispute is whether the seasoning was originally Arabic or not, and if so, that should be explained at greater length. Septentrionalis PMAnderson 16:25, 24 March 2008 (UTC)
It is preferable in cases where there is a complicated etymological history to describe it in full and avoid the insertion of a string of non-Romanized languages. However, as I just explained above, there is no serious source-based contestation to the Arabic origins of the words Za'atar and Falafel. In these cases where the original is clear, I take it from the comments here that it is appropriate for the non-Romanized original to be included in parantheses, but that some editors feel that the Romanized transliteration with didactic markings would be sufficient. If I have misunderstood, please set me right. And thanks to everyone for their feedback. Tiamuttalk 16:57, 24 March 2008 (UTC)
Well, for what purpose would you insert it? Ornamental? I can't see the point if not even the few Arabic–English bilinguals get anything out of it. If it's the sole word in the article that might be translated on the spot and that translation is not trivial or uncontested, maybe it's justified, just maybe. Tony (talk) 01:43, 25 March 2008 (UTC)
  • Information, as always: There are several transliteration systems for Arabic, and the English transliteration need not uniquely determine the original Arabic letters. (This is not the post Tony agrees with below.) Septentrionalis PMAnderson 02:56, 25 March 2008 (UTC)
Bingo. I was thinking primaily on people whose first language may not be English and who would be looking for the term in its native language in google. Because words can be transliterated a number of ways from non-Romanized languages into English, using the original would help those users find the terms in question. Tiamuttalk 06:03, 26 March 2008 (UTC)
Anderson—I agree. So shouldn't this be referred to in MOS (in a non-prescriptive way)? Tony (talk) 01:43, 25 March 2008 (UTC)
Would you care to suggest wording? Septentrionalis PMAnderson 03:34, 25 March 2008 (UTC)
First: Tiamut, you're absolutely right, I was careless. I should not be pulling out a single painful quote from one side of an RfC for any reason. And btw, thank you for attempting to find a way to deal with what is otherwise a nasty fight at the current Za'atar RfC (which I forgot to mention) by coming up with rational, consistent, stylistic reasons for exclusion or inclusion of the Hebrew script ... a nice example of Wikilove. On the other hand, aside from the ill-advised quote, I did the right thing: you brought us an issue without telling us about the current, high-volume, very relevant RfC at that article and other relevant RfC's, and my position is that that information is critically important to our decision. Before we figure out what language we should use in the style guideline, let's first agree among ourselves how we feel about this. I think my approach would be: policy always trumps style guidelines. Where the real issue is that people feel that an enemy is trying to appropriate words that they feel ownership over, the issue must primarily be decided by the kinds of arguments used at WT:NPOV rather than by a style guideline. However, to the extent that neutral, rational, consistent style guidelines can be helpful to that end, that's a very good thing, so absolutely, let's see if we can come up with a guideline that achieves that goal. - Dan Dank55 (talk) 20:12, 25 March 2008 (UTC)
I want to make it clear that I'm only defending what I said, I am not criticizing your introduction of the issue. You told us there was "a bit" of a problem, and perhaps it is better to be low-key, in general, about these issues. But I am hopeful that the information I introduced will help us come up with a sensitive and appropriate solution. - Dan Dank55 (talk) 21:43, 25 March 2008 (UTC)
Dan, do I sense a little sarcasm here ("Wikilove")? it's bad faith for you to assert that "the real issue is that people feel that an enemy is trying to appropriate words that they feel ownership over," as the basis for my intervention here. I don't think I "own" Za'atar or Falafel and my primary concern here is that we formulate a consistent guideline that will save me and others unneccessary conflict over which and how many words to place in the first sentence of an article. Plus, the RfC at Hummus is no longer active (the last post was at the end of February), and there is no RfC at Za'atar, though there is a debate over how to include the non-Romanized equivalents. I understand that you may be skeptical of intentions here, but that's not really fair, considering that rather than edit war over which non-Romanized languages to include, I thought I would ask here for input of style guidelines. Not ony because of these pages, but also because I notice the problem recurs often at pages that I edit related to the Israeli-Palestinian conflict. Is it wrong to seek some kind of outside input? If so, please forgive. Tiamuttalk 06:03, 26 March 2008 (UTC)

(outdent) As to the question at hand, regarding a suggested principle on this issue for the MoS, how about something along the lines of:

In determining how and where to include non-Romanized transcriptions of words that have non-English roots or equivalents, consideration should be given to producing a visually uncluttered text. In cases where there is only one, uncontested non-Romanized root word for the article in question, it is acceptable to place the non-Romanized text in parentheses after the first appearance of the English term in bold. If there is more than one non-Romanized term of equal import, (as is often the case with words whose etymology is unclear) is it preferable to place the many non-Romanized equivalent terms in an infobox or glossary, or alternatively to discuss them in an "Etymology" section.

Regarding place names in which there is more than one linguistic group and/or official language, editors are encouraged to forgo listing all the different non-Romanized names for the place in the parantheses after its first use as above. However, if the etymology of the place name is universally uncontested, it can be listed in a non-Romanized format in parantheses after the term.

What do people think of the general gist of this? Suggestions for improving the language and content are most welcome. Tiamuttalk 07:03, 26 March 2008 (UTC)

There seem to be two semi-related issues under discussion. One concerns a particular instance of Arab–Hebrew tension, which should probably be pursued elsewhere. The other is the broader issue of avoiding the clutter of inline parenthetical non-Roman script. When script is in an unobtrusive (but perfectly accessible) place as footnotes, it doesn't much matter. That is why Noetica and I propose this simple guideline:

Except when giving etymologies, place original, non-Roman script in a footnote to avoid clutter in the main text.

Tony (talk) 10:52, 26 March 2008 (UTC)

Sounds like a good general guideline from which to begin and much less wordy than my own. ;) A little less space for the inclusion of non-Romanized text in the body of the article than I might have suggested, but it's reasonable. Perhaps a caveat that infoboxes might be a good place for non-Romanized scripts as well? I'm thinking of cities with more than one official language or the like? Good succint start though. Tiamuttalk 19:47, 26 March 2008 (UTC)
WP:NCGN already covers cities; it's where the 10% rule of thumb comes from. It doesn't say anything about infoboxes, and probably should. Septentrionalis PMAnderson 16:33, 27 March 2008 (UTC)
Thanks for pointing that out. I was unaware of those guidelines and they will be useful to the chronic debates plaguing word order placement and which words to include on city name pages. Tiamuttalk 11:07, 28 March 2008 (UTC)
I disagree with placing non-Roman script in footnotes to address an issue which is (all things considered) quite rare. In Japan-related articles, the Japanese title and romanization are included along with the English title (if any) as people who read those articles are generally going to be interested in the original Japanese, and to provide insight and comparison into how words are romanized or changed when going from Japanese to English (or the reverse). WP:MOS-JA indicates that articles should generally try to use as little kanji or kana as possible, and kanji/kana should should not be used for words which are linked (as the linked article will have the appropriate kanji/kana). The characters are much less useful in footnotes as the vast majority of people don't actually read them unless looking something up. ···日本穣? · Talk to Nihonjoe 03:07, 27 March 2008 (UTC)
I'm sorry, Tiamut, and I assure you my comments about POV were not aimed at you, but at what I see on the talk page(s). I think you did the right thing to bring us this issue. - Dan Dank55 (talk) 04:22, 27 March 2008 (UTC)
No problem. I'm sorry that I misinterpreted to whom the comments were directed. Tiamuttalk 11:07, 28 March 2008 (UTC)
I see that Tony continues to simply HATE non-Roman script. This unfortunate attitude leads him to underestimate the numbers of readers who will in fact possess a relevant language, or the benefit to them of seeing the actual word: most transliteration systems lose information from the original; Arabic is particularly renowned for this. At the same time, we should not encourage the presence of Arabic — or Hebrew — for nationalist point-scoring; but this applies equally to transliterations. Septentrionalis PMAnderson 16:30, 27 March 2008 (UTC)
    • Wrong again, Anderson: it borders on a personal attack. I can transliterate Greek and Cyrillic scripts for basic purposes, and have no hate per se of non-Roman scripts; that would be ... racist. What I do hate (1) the use of non-Roman scripts as pretentious ornaments in English text; (2) the cluttering of English text with a lot of non-Roman conversions that could be easily placed in footnotes (e.g., Guqin), and (3) people like you who bandy about specious assumptions about me. Tony (talk) 12:27, 28 March 2008 (UTC)
      • As the link will show, I am simply quoting Tony's own words and emphasis. The issue that provoked his strong language was the inclusion of Chinese characters in the article on the guqin, the Chinese lute, especially in the sections on the various terms for the varieties of lute. This is perfectly standard scholarly practice, not decoration: it is the only practical way to distinguish between the large number of Chinese homophones.
      • It is not desirable to do this with footnotes; that would produce a large number of footnotes to the same paragraph, each containing a pair of characters; a slip of the eye will give the reader the wrong footnote, and so the wrong information; while the text will be equally interrupted by footnote markers. Those readers who do not read Chinese can readily skip the characters; no-one can tell if a footnote is irrelevant until xe looks at it. Septentrionalis PMAnderson 23:22, 1 April 2008 (UTC)
I agree that the inclusion of words shuld not be for nationalist point scoring reasons, which is why I'd like to see a guidelines in place that minimizes that tendency. After reading WP:NCGN, how about something along the lines of:

Original non-Romanized words that are related to the etymology of the term can be placed in parentheses after the original bolded English term. If there is more than one non-Romanized word whence the English term derives, they should be listed alphabetically. When there are more than three and/or the history of the word's introduction into English is complex or contested, an etymology section can be created where the non-Romanized words can be placed and discussed instead.

tweaking, comments, very much welcome. Tiamuttalk 11:07, 28 March 2008 (UTC)
We could use a wider, and yet more precise, expression, than related to the etymology. Nationalists will sweep everything under related; yet we may want, as in guqin, terms which are related to the subject of the article. When I have a suggestion, I'll post it.

... If you take the hyphen seriously, you will surely go mad

And that's about the only thing I'm sure of, that I got from starting to scan the archives. (this from somewhere south of WP:MOS/Archive_30#Hyphens_2) I keep really wanting to add hyphens, even though so many places seem to end their advice with "... resist." So... here's an example:

He also played with well-known artist and would be drummer A.R. Penck in 1990.

Since I keep seeing dumb grammar typos, and have gotten attuned to that, I find "would be" here jarring, very much wanting "would-be". Am I mad? Shenme (talk) 06:15, 24 March 2008 (UTC)

The purpose of the hyphen is to reduce ambiguity. As in "well, known artist and would be drummer" vs. "well known artist and would be drummer". There is no such ambiguity in "would be" (and arguably there isn't in well known either). Are you mad? I couldn't possibly comment. :-) --Malleus Fatuorum (talk) 06:47, 24 March 2008 (UTC)
Good points. My US dictionary says "well" and a huge list of just about everything that it might be coupled with should be hyphenated; it's a well-established pattern in all varieties of English, I think.
In general, AmEng uses fewer hyphens than other varieties; I've heard it said that AmEng uses hyphens to disambiguate, and other varieties use them where they make for easier reading (i.e., a wider scope). There's also a degree of latitude for personal preference within all varieties, although adherence to some principles is necessary for everyone who aspires to good style, and disambiguation is the bottom line in that respect. I have to disagree with Malleus: would-be seems to demand a hyphen in this case. But here's a better suggestion: aspiring. Tony (talk) 07:20, 24 March 2008 (UTC)
Ah-well. ;-) I don't see any credible confusion between "would, be drummer", and "would be drummer". --Malleus Fatuorum (talk) 07:31, 24 March 2008 (UTC)
True for those who ponder it in retrospect, but why leave open a fork in the meaning that has to be disambiguated (in the grammatical context—whereas I think you were thinking only in lexical terms):

Fork 1: He also played with well-known artist and would be [drummer for the lead band in the US within a year ...]

Fork 2: He also played with well-known artist and would be [drummer Jacob Smith ...]

No fork: He also played with well-known artist and would-be [drummer Jacob Smith ...]

The third example is easy; the first two are possible grammatical forks. It's the slight "bump" in the reading for most folk—even though they may not rationalise it this way—that concerns reading psychologists, and possibly linguists in collaboration with them. This is my take; I wonder whether I've convinced you. Tony (talk) 08:39, 24 March 2008 (UTC)

I actually had in mind "He also played with well, known artist and would be drummer, Jacob Smith". As opposed to the Jacob Smith who was not well, so I don't entirely accept your lexical vs. grammatical argument. Where you have convinced me though is that aspiring would be a better choice in this case. --Malleus Fatuorum (talk) 08:49, 24 March 2008 (UTC)
"Well-" wasn't my point, since the dictionaries insist on the hyphen (seems to be a special case). But the grammatical ambiguity of "would be" is clear, yes? I think most North American writers would prefer the hyphen, and almost all writers in other varieties would insist on it. Tony (talk) 08:55, 24 March 2008 (UTC)
I agree with Tony here. Using the hyphen makes reading easier and removes any potential confusion, while there is little gain to be made by omitting the hyphen. Good usage of hyphens can improve text significantly. Waltham, The Duke of 09:42, 24 March 2008 (UTC)
I really didn't expect you or anyone else to agree with me. I just thought that it might be worthwhile to consider the common sense pov, without any patronising references to "reading psychologists", a specialism with which I will freely admit I am quite unfamiliar in spite of having studied psychology at university for four years. --Malleus Fatuorum (talk) 10:09, 24 March 2008 (UTC)
Sorry, Malleus, the last thing I intended was to be patronising. Me, I know zit about psychology except for a narrow eye-movement working-memory angle. Tony (talk) 10:20, 24 March 2008 (UTC)
In the above example, well-known and would-be are both compound adjectives whose meaning breaks down if parsed separately; would be (without the hyphen) is even a different part of speech from would-be. While the intended meaning is clear to most readers, a hyphen adds greater clarity and certainly shouldn't be discouraged. - JasonAQuest (talk) 02:01, 26 March 2008 (UTC)

Erroneous quotation

In editing the Natalee Holloway article, we have the following quotation used from a CBS reporter: "There is criticism that it is only a story because she is a (sic) pretty, blonde and white–and it is criticism that journalists are taking to heart and looking elsewhere for other stories."

I inserted the sic based on the punctuation in the source. An editor has pointed out, fairly convincingly, that what was almost certainly said was: "she is a pretty blonde–and white–and it is ..."

I've looked at WP:MOSQUOTE, which dictates minimal change, and suggests that when we alter from the original, we put an explanation in square brackets. How would this situation be handled? Are the brackets and explanation only in the ref, or visible in the article? Thank you.--Wehwalt (talk) 17:52, 24 March 2008 (UTC)

Mon-Khmer

At WP:DASH, what does this mean: "...but a hyphen is used instead in Mon-Khmer languages, which lacks a relationship,..."? Khmer language#History mentions "...its divergence from Proto-Mon-Khmer...", so in what sense are the Mon language and Khmer language so unrelated that they can be used to illustrate a more general rule unrelated to linguistics? More generally, what is the relationship that requires an en dash? Previous discussion here. Art LaPella (talk) 18:23, 24 March 2008 (UTC)

I don't know, and I think your chances of getting an answer to that on this talk page are slim. I would suggest you try one or more of the following:
  1. If the articles in question are sufficiently referenced, go and look at the references they give.
  2. Ask on other, more specific talk pages (eg Talk:Mon language).
Sorry I can't be of more help, and sorry to be so pessimistic. SamBC(talk) 21:08, 24 March 2008 (UTC)
But he's asking what we mean by it. The answer is all too likely to be "Nothing; it was a pontification of a long-gone editor." Remove? Septentrionalis PMAnderson 22:13, 24 March 2008 (UTC)

I think the Mon and Khmer articles give enough clues to what the relationship is: some languages, such as English, Dutch and German, are more closely related than others. For our purpose here, that is enough to know. But that doesn't explain what the example means here, or how to generalize it into a rule about hyphens. That is, I agree with Septentrionalis. Art LaPella (talk) 01:41, 25 March 2008 (UTC)

Noetica came up with that example; I'm alerting him to this issue (he's just back in town now). Tony (talk) 02:07, 25 March 2008 (UTC)
(to Art) It would be preferable to encourage following the connective found in our sources, whatever that may be, than to try to invent guidance of our own. Septentrionalis PMAnderson 03:04, 25 March 2008 (UTC)
Note this caution at the end of the subsection on hyphens, and immediately before the subsection on dashes:

Hyphenation involves many subtleties that cannot be covered here; but the rules and examples presented above illustrate the sorts of broad principles that inform current usage.

The choice between en dash and hyphen is also subtle, and disputed. Even the best publishers are inconsistent with it – even when language is the topic. CMOS covers this very poorly, and uses the en dash in a way that is not documented in its own guidelines. The Routledge Dictionary of Language and Linguistics (1996) valiantly respects the distinction, but frequently slips up: stimulus–response but also stimulus-response, and speech–language but also speech-language, where in neither case can context justify the divergence.
But Routledge, along with all sources I have consulted, uses the hyphen in Mon-Khmer. Why not an en dash? Well, an en dash marks something beyond simple conjunction (beyond a mere dvandva combination): there must be a particular logical relation marked by the compound. No specific or unique relation is marked in the combination Mon-Khmer: it is just that Mon and Khmer are prominent members of a certain language family, to which they therefore give a name. Of course they are related, but only in a way that is underwritten by their membership of that family.
At the head of the Dash subsection we give this advice:

Two kinds of dash are used on Wikipedia. The article on dashes explains the technical differences, and shows common input methods for both kinds.

See especially Dash#Relationships_and_connections. That article could do with improvement, as I was just saying to someone the other day. But the matter is at least addressed there.
The wording could be expanded to make things clearer here at WP:MOS; but when Tony and I were rationalising the treatment of hyphens and dashes in mid-2007, we were working hard to keep things tight by showing important general principles, and pointing to details elsewhere.
–⊥¡ɐɔıʇǝoNoetica!T– 09:11, 25 March 2008 (UTC)
And am I right in thinking that the same rationale underpins the hyphen, rather than an en dash, in Lady Featherstonehaugh-Jones? As a point of interest, at the time we were overhauling the section, there was uncertainty about Sino-Russian diplomacy, in which some authorities insist on hyphenation because there's a parallel, harmonious sense in the compound; Sino–Russian war, I presume, is a different matter, demanding an en dash. Yes? Tony (talk) 11:42, 25 March 2008 (UTC)
Most authorities, though not all, require a hyphen after any element of the form Sino-, implicitly because it functions like a prefix, not as an independent element of equal status to the second.
As for surnames, the en dash is usually deemed appropriate, since they are indeed independent elements that can enter into a specific relation of the appropriate sort. And there is a practical consideration: a surname is often hyphenated, so an en dash is used to distinguish such a hyphenated surname from such a relational case.
–⊥¡ɐɔıʇǝoNoetica!T– 12:46, 25 March 2008 (UTC)
I agree with the first comment here that the rule is not clear. The way I see it, a dash is used in case of an opposition between two similar items, a hyphen otherwise. In that light I do not see how "Michelson–Morley experiment" could be any different than "Mon-Khmer languages". They are both a juxtaposition, not an opposition. All the other examples are understandable. So I would propose to remove the "Michelson–Morley" example. −Woodstone (talk) 13:33, 25 March 2008 (UTC)
I also doubt that it is usage; an endash or hyphen seem far more natural. Septentrionalis PMAnderson 18:23, 25 March 2008 (UTC)
Woodstone:
Please cite style guides that support a hyphen in such cases as Michelson–Morley. Britannica, New Hart's Rules, Oxford Guide to Style, SOED, OED (see "Sapir–Whorf hypothesis" entry), Routledge Dictionary of Language and Linguistics (1996; "Sapir–Whorf hypothesis" entry), and How to Punctuate (George Davidson, Penguin, 2005; Sapir–Whorf hypothesis, Feynman–Gell-Mann hypothesis examples on p. 165) are among authorities supporting an en dash in such cases. So are Burchfield's New Fowler's ("dash" entry) and The Cambridge Guide to English Usage (2004; "dashes" entry). CMOS does not appear to rule on the matter, and as I have pointed out is inconsistent in its own practice. In particular, CMOS is silent on cases such as Feynman–Gell-Mann hypothesis, which work strongly in favour of the consistent and rational practice currently promoted in our guidelines.
When you have found authorities that explicitly support the hyphen instead, please explain how the case they make is stronger than the case made by those I cite in favour of the en dash.
PMA:
¿Qué? Do you still doubt "that it is usage", after I cite those authorities above? Please do what I ask Woodstone to do, also. And please explain what you mean by this: "an endash or hyphen seem [sic] far more natural". The options under consideration are hyphen and en dash.
–⊥¡ɐɔıʇǝoNoetica!T– 22:11, 25 March 2008 (UTC)
What I doubt is what I see: "Michelson—Morley" with emdash. I do not trust my visual memory to decide the invisible difference between hyphens and endashes, which is fundamentally why I dispute bothering people about it. Septentrionalis PMAnderson 23:42, 26 March 2008 (UTC)
Well, please don't use your own ignorance as a new benchmark for WP. Tony (talk) 00:24, 27 March 2008 (UTC)
Ouch! How else could he have said that? How about, "But others have better visual memory, so the guideline is justifiable..."? Art LaPella (talk) 01:02, 27 March 2008 (UTC)
Perhaps Anderson's using a font/browser that renders hyphen and en dash almost the same; I've seen these. If so, xe xhould xhange xit. Tony (talk) 01:21, 27 March 2008 (UTC)
This is pointless to me (since what I meant was that I do not remember whether Michelson-Morley or Michelson–Morley occurs in printed text), and impertinent to our readers. To every problem there is a solution that is simple, direct, obvious, and wrong. Requiring our readers to change fonts (or browsers) for the convenience of MOS is one of these; many of them can't, and it is rude to the rest. Septentrionalis PMAnderson 17:21, 27 March 2008 (UTC)
Better (although I have never changed fonts for such a purpose). Art LaPella (talk) 01:37, 27 March 2008 (UTC)
While I have no compunction about being rude to you, Anderson, I'm certainly concerned about our readers. My advice to all users of the hopeless IE 6 and subsequent versions is to drop it (my techy friends say that Microsoft has no plans to improve IE significantly; that is the rudeness). It's so easy to change to one of the much better freeware browsers available for both platforms—unless you're Anderson and just want to make a point. The advantages of being able to distinguish between all symbols and characters are only one reason to do so. TONY (talk) 00:52, 1 April 2008 (UTC)
I regret that you take those attitudes, both toward our readers and toward myself. Many readers are not in a position to drop IE, which has worse problems than interfering with Wikipedia; as for your rudeness, you may justify it here. Septentrionalis PMAnderson 05:00, 1 April 2008 (UTC)

Using {{Cquote}} rather than just <blockquote>

Why not say that editors can use {{cquote}} as well as the <blockquote> tags?

I see the advantage of consistency with just one quotation method, but it tends to seem to me that people are using {{cquote}} quite a lot. In my opinion, it can make things easier to read.

Well, let me know what you think :)

Thanks, Drum guy (talk) 22:23, 25 March 2008 (UTC)

The cquote template uses a table to achieve the same format with the quotation mark images. It's not meant for block quotes, but for pull quotes. A lot of people are unaware of the difference between pull quotes (which are more for magazines than encyclopedias) and block quotes, and continue using the cquote template for block quotes simply because they don't know any better. :) — Omegatron 23:51, 25 March 2008 (UTC)
To emphasize what Omegatron just said: cquote is way overused. When cquote is used for block quotes, it should be converted to a blockquote. The {{quote}} template implements blockquotes in a template format compatible with cquotes, but the last time I looked at it it suffered from the limitation that it couldn't be indented by prefixing ":", while the <blockquote> tag works fine with ":" indenting.--Srleffler (talk) 19:57, 26 March 2008 (UTC)
Yes. {{quote}} used to work with indenting, until I added some tags to work around the new paragraph bug, which I think is a bigger problem. So:
  • Use HTML blockquote tags with p tags inside if you want to blockquote within a definition list (:)
  • Use quote template with plain newlines if you are in normal text.
In the far future, someone will fix the bug, and we can do both with both. It might be possible to work around both with the quote template, but I haven't looked into it too deeply. — Omegatron 23:25, 26 March 2008 (UTC)

UK/Britain versus England

Is there a guideline for which geographic nomenclature should be used? See [18] [19]where User:Givenarmyggg is changing to England or English where the article previously said UK or Britain/British. Is there a preferred usage where something is physically in England as opposed to Scotland, Wales, or Northern Ireland? Edison (talk) 23:19, 25 March 2008 (UTC)

The campaign continues to replace UK with England for entities in England, as per these edits by User:Nobletrips: [20] wherein "England" is placed on a parallel level with "United States" and subsequent similar edits [21]. In [22] a church is said to be in "St George, Bristol, England" replacing "St George, Bristol, United Kingdom." There needs to be some policy guidance. It is not an unreasonable usage to say something is in "Bristol, England" and omit the "UK" since the article on the Liberty Bell says it is in Philadelphia, Pennsylvania, omitting that the state is in the United States. I have no strong opinion one way or the other, but I am seeing a lot of similar edits on recent changes patrol. Edison (talk) 21:42, 26 March 2008 (UTC)
In short, no. There is an essay at Wikipedia:Nationality of people from the United Kingdom, that's about the best I know of. -mattbuck (Talk) 21:31, 26 March 2008 (UTC)
Bristol is in England; Bristol is in the UK. Both are correct, neither warrants hysteria, and neither should be pushed. Septentrionalis PMAnderson 23:49, 26 March 2008 (UTC)
Ddstretch asked a similar question here.

horilka quotation

Can someone replace this with a multi-paragraph quotation to demonstrate the indentation of a blockquote and the new paragraph bug and workaround? I'm not good at coming up with good quotations.  :) — Omegatron 23:47, 25 March 2008 (UTC)

Dashes again

I see that Noetica has overlooked Dank55's excellent suggestion that we rephrase our rules on dashes to say that if you place a punctuational dash between spaces, it should be an endash; and if you do not space, use an emdash. As he says, people may take more kindly to the implication that their intuition has failed about the length of dash. This was significantly discussed, with some support, and no objection. If Noetica actually has an objection, xe should state it, instead of reverting continually. Septentrionalis PMAnderson 23:17, 26 March 2008 (UTC)

Nobel prize image

I don't know if i've done this according to protocol, but the ongoing discussion pasted below from Wikipedia talk:WikiProject Infoboxes#Nobel prize image, most probably should have been opened here.

This may be related to the flag issue raised two sections above. I noticed some back-and-forth reverting on the Al Gore page as to whether the Nobel Prize image belonged there. Is there a policy or consensus regarding this? OhNoitsJamie Talk 17:46, 21 March 2008 (UTC)

I'm not sure where it goes but I think it's nice to have on there. I've been trying to ensure that all prize image placement is at least consistent within the prize field, and for Nobel Peace Prizes, which Al Gore was awarded, it appears to be next to the name in the infobox. --Eustress (talk) 18:02, 21 March 2008 (UTC)
as merely decoration, i don't believe the nobel tokens should be displayed in the infoboxes header. much like the flagicons, once permitted, editors tend to go wild and place any- and every-manner of decalcomania to highlight the slightest identifying characteristic. the practice has been deprecated in {{infobox musical artist}} for a plethora of reasons, and i think this one should be nipped before the genie is out of pandora's box. (how's that for a mixed metaphor trifecta!) --emerson7 01:38, 25 March 2008 (UTC)
I don't think placing an Nobel Prize image (not just any decorative icon) will underestimate one's other characteristics or overemphasize the value of prize. The Nobel Prize is one of the most recognized awards throughout the world and worth a space in the infobox. If we can have a collection of icons for other awards, we might need to consider a special section in the infobox. eDenE 02:13, 25 March 2008 (UTC)
then where does it end? if this is allowed to proliferate, i won't be long before little pics of medals of honour pop up, and olympic medals, and on and on in the same manner of the flagicons. --emerson7 02:13, 27 March 2008 (UTC)
I think the image is not helpful and thus it shouldn't be there (what is the reason for having it?). I don't know what a Nobel prize looks like, and I certainly can't recognize it from such a small picture (unlike some flags). I think that this is true for most people. I asked for opinions at Template talk:Infobox Scientist#Image:Nobel.svg but did not get any reactions. -- Jitse Niesen (talk) 13:59, 25 March 2008 (UTC)
I think it is a hasty generalization, although I don't know how many people can recognize the Nobel Prize medal. If you really don't know you might want to look it up. Notable awards are very helpful to know about a person fast. However, many infoboxes lack such section and it is not a small job to edit all those infoboxes. So, the question is how helpful placing the icon would be for readers. I don't know, but it will be helpful for me at least. eDenE 20:45, 25 March 2008 (UTC)
I don't have an opinion on keeping the graphic, but if you keep it, I think the addition of a "Nobel" or "Nobel Prize" caption would be preferable, since most people won't recognize the icon. - Dan Dank55 (talk) 04:30, 27 March 2008 (UTC)
I am in favor of keeping the Nobel image, as it is, and where it is. However, as is the case with actor boxes, a section on "awards received" that gives further information would be useful. I think a caption at the top would be unwieldy. However, I am fervently opposed to the removal of said images whilst this discussion is still ongoing, as has happened at the Seán McBride article. ---RepublicanJacobiteThe'FortyFive' 15:22, 30 March 2008 (UTC)

Future of the hard-space proposal

At the head of this page as it now stands, and ripe for archiving, is a discussion of markup for the hard space, along with a report from the working group that has developed the proposal so far. As secretary for that group, I have now modified the proposal in response to that discussion. Here is the new text, transcluded from User:Noetica/ActionMOSVP/StableWholeProposal:

Interested editors may like to take a look. Note that I have suggested that discussion continue at the new page WT:NOWRAP, which addresses a number of options for line-breaking and its prevention. This seems to be the best location for the time being. (Hosting the thing at a subpage of my userpage was always just an interim measure; and the proposal should itself be moved away from there.)

Editors may also like to note the discussions about when hard spaces ought to be used, and what guidelines ought to be offered here at WP:MOS and at WP:MOSNUM concerning them.

On a personal note, I would like to express my appreciation to those editors who have worked on this. I hope they will continue, at the new location! For myself, I'll take no further part in those discussions. Nor will I be taking part in any discussions at WT:MOS and WT:MOSNUM (except, at my discretion, to respond to criticism), for at least the next six months. If any editors would to know my reasons for this, they are welcome to email an enquiry to me. I may perhaps also make a statement at my talkpage.

–⊥¡ɐɔıʇǝoNoetica!T– 11:27, 27 March 2008 (UTC)

Sea of blue

The template name {{nowrap}} is linked four times (on every occurrence) in one paragraph in the section Non-breaking spaces. I would like that we do as we teach, so I would like to fix that. That is, only have the first occurrence linked and the other as normal text. Easy enough to do, just use {{tlf|nowrap}} instead of {{tl|nowrap}}, which will render like this: {{nowrap}}. Any one that disagrees?

--David Göthberg (talk) 18:37, 27 March 2008 (UTC)

The tlf template was news to me; thanks for that. - Dan Dank55 (talk) 19:15, 27 March 2008 (UTC)
Indeed, this is the first time I've ever heard of it as well (although I should have deduced its existence). Most useful; thanks. Waltham, The Duke of 16:26, 28 March 2008 (UTC)
Actually, {{tlc}}, {{tld}} and {{tlf}} are brand new, just one week old. They produce output that look like this: {{name|parameters}}, {{name|parameters}} and {{name|parameters}}. Oh, and I have done the update to the MOS to only link {{nowrap}} the first time.
--David Göthberg (talk) 18:00, 28 March 2008 (UTC)
That would explain it. I wonder what the difference between {{tlc}} and {{tld}} is, however, as the so-called "teletype" font looks identical to the one used in the edit box. Waltham, The Duke of 18:49, 28 March 2008 (UTC)
Well, if you look closely, then at least in the default Wikipedia skin monobook, then {{tlc}} uses "code colouring" and {{tld}} does not. That is, {{tlc}} uses <code> tags while {{tld}} uses <tt> tags around the text. The difference becomes much more visible when inside the green template doc boxes. For instance take a look at the docs here.
--David Göthberg (talk) 19:58, 28 March 2008 (UTC)
Ah, that stupid colour thing. I've always wondered why we had that. Anyway, I couldn't really discern the difference in the green background; I can see it better here as it is. It might be because of the monitor. Waltham, The Duke of 23:31, 28 March 2008 (UTC)

Templates for historically determined styles

Is there a template, and if not what do we think about establishing one, to post on an article the variety of English, dates, etc. that has evolved for the article? It seems that often unnecessary changes are made and when you go to revert you find that ten edits back someone had changed it the other way, etc. I often find that I have to go back to the oldest version in history and work through the diffs looking for the first distinguishing usage of a variety of English or a date form (particularly such things as A.D vs CE). It seems it would be nice to research the matter once and then tag the page noting the diff in the template.--Doug.(talk • contribs) 17:36, 28 March 2008 (UTC)

  • We recommend comments, because they will be seen by the Date Warrior even if he ignores the talk page, and yet not bother the reader.
  • Please remember that we prefer established stable usage, even if it is not the first contributor; that's a stopgap for when there has never been stability. Septentrionalis PMAnderson 17:44, 28 March 2008 (UTC)
Just in case: If you make such a template, then it should of course go on the top of the talk page, not into the article itself. And I am not aware of the existence of any such template at the moment, so you'll have to make a new one. (Personally I don't bother much about these language details since I am not a native English speakers.)
--David Göthberg (talk) 20:05, 28 March 2008 (UTC)

Archive 35 edit

Edited a link to correct a link to a disambiguation page. Doesn't interfere with content, and I assume uncontroversial. However, because there was the warning to not edit, I figured I'd post here to inform. Though an archive is important, I feel that the links may as well be correct and link to the intended target. Is this fine? Wjw0111 (talk) 05:49, 29 March 2008 (UTC)

Blank lines around headings

I find it interesting that when you add a section to a talk page with the '+' link at the top of the page (or via alt-shift-+), it surrounds the heading with blank lines, and put spaces around the headline (after and before the inner =s), yet the MOS uses a different style (no spaces, and only a blank line above headings). I know that style guides are just guides, not policy, but it's humourous that the code to generate sections uses a different style. Ciotog (talk) 22:24, 29 March 2008 (UTC)

From WP:HEAD (in WP:MOS): "Spaces between the == and the heading text are optional (==H2== versus == H2 ==) ... Blank lines above and below headings are optional; a single blank line above is recommended for readability in the edit window." No humor here that I can see, just lack of any consensus (and probably always will be, since it only affects the edit window, not the page layout) on ==H2== versus == H2 == and a space below the heading or not. FWIW, the more crowded a page is, the more spaces of all kinds are likely to vanish, but this is a personal observation, not a guideline. - Dan Dank55 (talk) 14:28, 30 March 2008 (UTC)
Actually, "at least one blank line" was probably meant there; I'll go make the fix, and please revert me if I'm missing something, guys. - Dan Dank55 (talk) 19:41, 30 March 2008 (UTC)
Strike that, "at least one blank line" sounds to some people like "the more the merrier"; I hope "one blank line above, or occasionally two" is clearer. - Dan Dank55 (talk) 19:49, 30 March 2008 (UTC)
User:Sunray reverted, and we've been talking about the best wording. I believe where we are in the conversation is a recommendation to change "Blank lines above and below headings are optional; a single blank line above is recommended for readability in the edit window" to "A blank line below the heading is optional. If there are no blank lines above the heading, one line should be added, for readability in the edit window." Thoughts? - Dan Dank55 (talk) 13:25, 1 April 2008 (UTC)
Okay, I'll make the change. - Dan Dank55 (talk) 13:54, 2 April 2008 (UTC)

The first sentence

Is it true that the Manual of Style doesn't require bolding of the title such as:The Manual of Style, often abbreviated... --WikiCats (talk) 11:16, 30 March 2008 (UTC)

See WP:Lead section#Bold title; also WP:Manual of Style (links) and its talk page; there's a relevant discussion on bolding there at the moment. - Dan Dank55 (talk) 13:57, 30 March 2008 (UTC)

Thank you. --WikiCats (talk) 23:18, 31 March 2008 (UTC)

Abuse of WP:ENGVAR

An editor I have run into User:Albanman, note the name, likes to run about altering American spellings to British ones. Sometimes he says, it's b/c he is changing something to "European English" because the topic touches on Europe. In the case of Oriental Orthodoxy, he did it simply b/c it's "non-US church matter". This is the sort of nonsense that the policy was designed to prevent. What is the appropriate course of action? Tb (talk) 14:10, 30 March 2008 (UTC)

I'm not sure, but the clause "impose one's own view of 'standards to apply' rather than those of the community" from WP:POINT leaps to mind. If you bring his actions up in this context on the relevant talk pages, you might get a win-win: he might become more careful, or it might become clear that he has no intention of following WP:POINT. - Dan Dank55 (talk) 15:23, 30 March 2008 (UTC)
P.S. I haven't read the talk pages in question and don't know the facts of the case, I'm making a point about POINT. - Dan Dank55 (talk) 17:34, 30 March 2008 (UTC)

Suggest addition recommendations for "float clear"

I wonder if we want to add some suggestions for the use of a float clearing element (aka {{-}}) for making sure tables and images don't disrupt too much of the page.

There is absolutely one suggestion we should have, in that : A float clear element should always be used before the "References" section if there's any likelihood of a floating element interfering with it. This is because, since the reflist does not wrap around floating elements, any intrusion of a floating element into the reflist will cause it to bunch up, which may not affect the widescreen monitor crowd but is very apparent on printing a page in standard portrait mode; the whitespace introduced by waiting until the float is clear will typically be much smaller than the white space placed to the right of the reflist if no float was clear.

I'd recommended, as a guideline, that float clears should be used before second-level headings if there's a likelihood of an image floating over it, particularly if the new second level section has a float element itself. Mind you, sometimes reorganizing pictures, using left vs right float, and the like, will help to avoid this problem, so this is not as strong as issue as the References section one. --MASEM 14:26, 30 March 2008 (UTC)

I agree that {{-}} should be used more often than it is, but the longer the style guidelines, the more readers we lose, per WP:CREEP, and there's more resistance to learning layout templates than to learning general principles of page layout that are applicable outside Wikipedia. Perhaps this should go in the general pile of layout issues to be standardized by style bots, so that this isn't one more thing that people have to learn; please consider adding it as a new section at WP:STYLE1.0. - Dan Dank55 (talk) 14:43, 30 March 2008 (UTC)
We should probably have a page on layout templates, linked to from here. We should be very careful about phrasing; the abuse of this page to serve several purposes simultaneously could result in articles failing FA if they have no float clears, even if they have no image likely to transgress at all. Some people prefer stupid Rules to no Rules at all. Septentrionalis PMAnderson 17:33, 30 March 2008 (UTC)

Sentences in parentheses

If I understand this section correctly, I think we could add an example:

Normally, if the words of a sentence begin within brackets, the sentence must also end within those brackets. (This sentence is an example.) There is an exception for...

If I don't understand it correctly, I definitely think it would be clearer with an example. —JerryFriedman (Talk) 03:11, 31 March 2008 (UTC)

You are correct, sir. - Dan Dank55 (talk) 03:21, 31 March 2008 (UTC)

header in italics?

Is there somewhere that says Subjects that are written in italics, when it becomes a title of a section, should be written in italices too? — Blue。 05:52, 31 March 2008 (UTC)

For page titles, it's a non-issue: I just created a test page in my user space, and '' and ''' did not wikify, they remained as single quotes. For section headings, there used to be a sentence here, but I don't see it now, that if a word or phrase is in italics as a "use-mention distinction" (that is, italics are being used to mention the words themselves, not to use the words), and you turn it into a link, then you can remove the italics, since the link itself is a big hint that there's something special about the word or phrase. I think you could make the same argument for a heading, and sometimes remove italics for that reason, but only for that reason; for the others uses of WP:MOS#Italics, I would think that the italics have to stay. Am I wrong? - Dan Dank55 (talk) 18:01, 31 March 2008 (UTC)

Well, let's see how it looks. Not bad. Septentrionalis PMAnderson 20:32, 31 March 2008 (UTC)

Tolstoy and War and Peace

This is a sample header for the section above.

Coconfused

all of Pma's edits are incoherent ("coconfused"), infelicitous ("despite this deprecation"; "can do best"), or badly styled ("emdash"); this IS the MoS

The edits in question are;

To remove wrongly from:

Hyphens are often wrongly used for disjunction in Wikipedia; this is especially common in sports scores.

This condemnation is neither justified nor likely to convince editors to go along.

To insert

Many editors prefer that a dash between spaces be a short endash; spaced emdashes are long. Conversely, a dash between spaces should be an endash so as not to be coconfused with a hyphen.

There is no consensus on the wording here; at least one editor believes there is no consensus to oppose.

And to simplify the instructions on captions to

Most captions are not complete sentences, but merely nominal groups (sentence fragments) that need not end with a period; short and unpunctuated groups can do best with no period.
If a complete sentence occurs in a caption, it and also any sentence fragments in that caption should end with a period.


These are at least as coherent, and as clear, as the edit summary above. Septentrionalis PMAnderson 05:13, 1 April 2008 (UTC)

No, not if you're fluent in English they're not. I'll take each bullet point in turn:
  • Hyphens are often wrongly used for disjunction in Wikipedia. (MoS)
This sentence is correct in every regard, and its meaning is clear and unambiguous: It is incorrect to use hyphens for disjunction. They are often used in this incorrect fashion in Wikipedia. They should not be.
  • Hyphens are often used for disjunction in Wikipedia despite this deprecation. (Pma)
This is a badly written sentence. It refers to a "deprecation" that apparently precedes the sentence ("this deprecation"), yet no such deprecation does. In addition, "despite this deprecation"—even if it were used correctly, which it is not—is an ungainly locution, especially in comparison to the concision and clarity of the word "wrongly" for which you wish to substitute it.
  • Em dashes should not be spaced at Wikipedia. (MoS)
This sentence is correct in every regard. It accurately reflects the consensus recently established on this page. Its meaning is clear and unambiguous. It is phrased as plainly and concisely as possible.
  • Many editors prefer that a dash between spaces be a short endash; spaced emdashes are long. Conversely, a dash between spaces should be an endash so as not to be coconfused with a hyphen. (Pma)
Where to begin? "Endash" is very bad style—for consistency with the rest of the MoS, the compound should be open ("en dash"). The hyphenated style is also acceptable ("en-dash"); "endash" is simply not a word. "Emdash" is, again, very bad style. "Coconfused" is not a word. The phrase "short endash" is confusing—the reader is invited to wonder if there are such things as long endashes. The clause "spaced emdashes are long" is entirely incoherent. Yes, I know what you mean to say—"many editors feel that spaced em dashes take up more space than is necessary or helpful"; no, that doesn't need to be said. "Conversely" is used both incorrectly and superfluously. Even if we eliminate that word and replace the nonword "coconfused" with "confused," the meaning of the sentence is less than clear; in any event, it serves no purpose, given the discussion of spaced en dashes just two paragraphs below.
  • Most captions are not complete sentences, but merely nominal groups (sentence fragments) that should not end with a period. If a complete sentence occurs in a caption, that sentence and any sentence fragments in that caption should end with a period. (MoS)
These two sentences are correct in every regard. Their meaning is clear and unambiguous. Any editor who reads them will know exactly when and where periods should appear in a caption, and when and where they should not.
  • Most captions are not complete sentences, but merely nominal groups (sentence fragments) that need not end with a period; short and unpunctuated groups can do best with no period. (Pma)
This is bad writing. It offers not guidance, but confusion. What is an editor to make of the observation that sentence fragments "need not end with a period"? That it doesn't matter whether they end in a period or not? And what is an editor to make of a Manual of Style that purports to guide with a phrase such as "can do best"? That clear, idiomatic English can be dispensed with in Wikipedia? That if awkward, unclear writing is acceptable on our leading style page, it must be acceptable—nay, even preferred—everywhere in the encyclopedia?
Yes, my friend, cocofused indeed are you.—DCGeist (talk) 06:07, 1 April 2008 (UTC)
Pma, unless you—or someone else—shortly contests my analysis above, I'll remove the dispute tags you added to the Dashes section later today. Best, Dan.—DCGeist (talk) 10:41, 2 April 2008 (UTC)
With no party contesting the analysis of the Dashes section above, I'm removing the recently added dispute tags. At the same time, I'm going to draw back a bit from my statement concerning caption punctuation. They are certainly many respectable reference works that follow yet another style: placing a period at the end of all captions, even if they consist of nothing more than a sentence fragment. And there are still others (like, historically, the Encyclopedia Britannica) that never end a caption with a period—even in the case of multisentence captions where a period appears part of the way along. In fact our United States article, which I help maintain, follows a version of this style: most, but not nearly all, of the captions are sentence fragments; for a consistent look, no captions end in periods; to avoid what strikes at least these eyes as the oddity of a period in the middle of a caption, but not at the end, all captions are kept to no more than a single sentence. I'll hang fire for a bit and see if the MoS stabilizes with the currently phrased directive.—DCGeist (talk) 04:47, 3 April 2008 (UTC)

Now the text reverted to:

  • Captions always start with a capital letter.
  • Most captions are not complete sentences, but merely nominal groups (sentence fragments) that should not end with a period. If a complete sentence occurs in a caption, that sentence and any sentence fragments in that caption should end with a period.
  • Captions should not be italicized, except for words that would otherwise be italicized.
  • Captions should be succinct; more information about the image can be included on its description page, or in the main text.

is both convoluted and incoherent.

The italics (added) mark portions which have nothing to do with format; they could readily be combined into a simpler sentence under usage.


There is no reason to say not italicized. Roman would be clearer.

The bullet point about fragments should be balanced with another bullet point about complete sentences.

Long sentence fragments, especially those which contain other punctuation, should probably have periods. Septentrionalis PMAnderson 05:33, 1 April 2008 (UTC)

Sept, I did some poking around at the time of the discussion about Romanization above, and non-italic isn't the usual meaning for "roman"; it usually means "in the roman alphabet, no matter what the font". - Dan Dank55 (talk) 17:52, 1 April 2008 (UTC)
Actually, on this rare occasion I agree with Anderson—roman is the term for non-italic text. My only concern is that most folk won't be familiar with the term. Maybe it needs a link if used? TONY (talk) 00:37, 2 April 2008 (UTC)
Two different senses of roman are involved.
  • OED 5. Of letters; Belonging to the modern type which most directly represents that used in ancient Roman inscriptions and manuscripts, esp. in contrast to Gothic (or black letter) and Italic.
  • 6. Of the alphabet or its characters: Employed by the Romans, and (with various modifications) by all the modern nations of Western Europe and their (former) colonies.
I agree with Tony here, that roman letters is now mostly lowercase, Roman alphabet mostly capped. Perhaps roman font. Septentrionalis PMAnderson 01:36, 2 April 2008 (UTC)
Right, I'm aware that OED gives that definition for romanize(-ise) and romanization(-sation). The problem is that in the first 3 screens of Google and Alltheweb results, there are no other dictionaries or sources that use it in that sense; they all use it in the sense of transliteration to the roman (latin) alphabet. Maybe the word roman has a different sense, but isn't there a general principle lurking around here that, since we can pick any word we want, we shouldn't pick one that is 95% likely to be misunderstood unless we force the meaning from the context? - Dan Dank55 (talk) 02:21, 2 April 2008 (UTC)
P.S. If I had known that it was this easy to get Sept and Tony to agree, I would have been giving lexicographic opinions all along! - Dan Dank55 (talk) 02:22, 2 April 2008 (UTC)
Those are the definitions of "Roman", adj1; please try that. That romanize and italicize are asymmetrical is curious, but unimportant; the reasons are not beyond conjecture. Septentrionalis PMAnderson 02:31, 2 April 2008 (UTC)
Yes I agree Sept, I was just checking in to say that I've poked around more and I'm basically fine with "roman" ... maybe it could be confused, but if the context is clear, the meaning of non-italic is fine. Romanize is another story; it looks like we're agreed on that. - Dan Dank55 (talk) 02:42, 2 April 2008 (UTC)
FWIW at this late date, I agree with DCGeist's analysis completely - the suggested revisions were ungainly and lost too much information - other than that we should keep "non-italic"; no one but people who are very familiar with typography know that "roman" means "non-italic", and as someone else pointed out, the word is operator-overloaded in other ways, e.g. to mean "in the Latinized alphabet as opposed to Cyrillic, etc." regardless of slant, and non-native English speakers are likely to think that it refers to the writing of ancient Rome, which was all upper-case and had no "U". — SMcCandlish [talk] [cont] ‹(-¿-)› 23:23, 6 April 2008 (UTC)