Wikipedia talk:Manual of Style

From Wikipedia, the free encyclopedia

edit Archives and see also
Archives
Editors should feel free to summarize a discussion topic from the archive.
Archive Directory
See also
Wikipedia talk:Guide to writing better articles
Wikipedia talk:Naming conventions

[edit] Image question

Is it really necessary to place this image on the left? Do people really instinctively follow the eyes of praying mantises? And where is the mantis looking anyhow? Hesperian 00:28, 21 May 2008 (UTC)

It has come to my attention that the guidelines of Wikipedia:Manual_of_Style#Images can apply to animal articles in ways that make life a tad difficult and I'd love some clarification. How important is this rule Images of faces should be placed so that the face or eyes look toward the text..., and how should it be applied to images of entire animals? When it refers to portraits does that mean images only of a bird's (or other animal's) head, or does it mean any photo where the alignment of the image is portrait? I ask because I am currently working on two bird articles and image placement is somewhat tricky, particularly for trogon, which by virtue of being long, straight birds, tend to have long images that can often only really be situated on the right hand side of the page (thanks to the other new(?) rule about not pushing headings around). I don't want to have to stop using images because of the above rule, for example the image of the Black Throated Trogon, particularly as good images are hard to find for many species/genera/familes. How much digression do we have in these situations? (lots I hope). Sabine's Sunbird talk 00:07, 21 May 2008 (UTC)

I'm glad you brought this up, as this has been bothering me too. I hope this 'rule' is interpreted with a bit of flexibility. At the very least, I should think it would only be enforced for facial profiles, as opposed to full-body profiles; and then only for people, and perhaps animals that are easily anthropomorphised. Hesperian 00:28, 21 May 2008 (UTC)

Or, if anthropomorphism is a bit much to stomach, how about applying the rule only to animals that have forward-looking eyes. The mantis on the right appears to be looking straight out of the screen at you... because it is. Hesperian 00:30, 21 May 2008 (UTC)

The "face looks towards text" rule is a good one to follow when everything else is equal, but it really shouldn't be allowed to interfere with more serious layout issues. Having a portrait face away from the text is at worst slightly distracting — it's not going to make an article unreadable, whereas trying to force an image into a position where it just won't fit can indeed do that. Don't take it so seriously. —Ilmari Karonen (talk) 00:38, 21 May 2008 (UTC)

Cheers. I agree with Hesperian, incidentally, most birds don't have binocular vision quite like people do and a bird with a side on view is actually looking at the picture taker as a rule. Sabine's Sunbird talk 01:29, 21 May 2008 (UTC)

I agree with Mr Karonen's view on the matter; we need to put our priorities in the right order here. It matters little if an image looks away, it is disconcerting for our readers to change the entire standard page-top layout, and it is unencyclopaedic to reverse images or to use none at all. Waltham, The Duke of 02:13, 21 May 2008 (UTC)

Yes it's more of a guideline, it's fine to use "common sense" in my opinion. If it's a person for example, standing with the back turned towards the text/reader it looks kind of bad and it might be good to switch side. Or if it's a cheetah looking like it's running into the side ("wall") of the page it also might look a bit odd. It's usually clear when you look at it, Choose what makes most sense overall. Also it's much easier to see where a human is looking because of our clearly visible eye white. (I've heard that one possible reason why humans have such a clearly visible eye white is because there might be some evolutionary advantage to be able to see where others (in the group) are looking?).
— Apis (talk) 03:18, 21 May 2008 (UTC)

Interesting...

I've heard, on the other hand, that it makes us more expressive (although eyebrows would seem to be more effective in this respect, and they also have a practical utility). Waltham, The Duke of 03:32, 21 May 2008 (UTC)

That sounds plausible as well, maybe it's both? =)
—Apis (talk) 07:22, 30 May 2008 (UTC)

[edit] Using numerics that are not measurements

I always have used nbsp when I use a numeric, for example 23 kangeroos. (23&nbsp:kangeroos) My rationale is that nbsp is used to prevent the number appearing at the end of a wrapped line separated from its unit of measurement. In the example, kangeroos is arguably a unit of measurement.

A few of my nbsp have been removed in later edits so I am asking here. Is the nbsp to be used generally to prevent a number apearing at the end of a line, or does it only apply to recognised abbreviated units of measurements? MortimerCat (talk) 07:18, 22 May 2008 (UTC)

The MOS guideline is cast WAY too broadly; it was I who dreamt up the wording last year during a revamp of MOSNUM, and no one queried it. The intention was to mandate the use of hard-spaces for values and symbols (i.e., abbreviations of ISO units). I think His Grace has made a change recently.

The indiscriminate use of hard-spaces leads to the unnecessary "stretching" of interword spaces, especially when the text wraps up to an image. TONY (talk) 09:22, 22 May 2008 (UTC)

I modified the phrasing of the guideline yesterday to conform to the various discussions held here from time to time, the examples already included in said guideline, and common sense. A kangaroo is not a unit of measurement, because one does not count things with kangaroos (although I'd sure love to be proven wrong there :-D). In these cases, numbers are much like all other adjectives: two kangaroos is not that different from brown kangaroos. On the other hand, when we are talking about metres and kilograms, things change; precision is required, and having a number (often a long one) at the end of one line, a unit of measurement (often an abbreviated one) stranded at the beginning of the next line, and, in all, a compound which should be united yet is not, makes for a rather awkward situation. In technical articles and lists, especially, where measurements are more numerous and important, it is bad for easy, uninterrupted reading. But we shouldn't equate cases which are clearly different. As Tony says, over-using hard spaces creates problems. Therefore, we should use them only where we have to. Waltham, The Duke of 09:50, 22 May 2008 (UTC)

Is this the only discussion that led to the change in NBSP? The first time I read the 7 World Trade Center article, it was a wreck of hanging 7s. Same thing occurs at aircraft articles (for example Boeing 747) and spacecraft articles (Apollo 8). Please reinstate the previous wording which included "numerical and non-numerical elements"; this was much more logical and sensible.[1] SandyGeorgia (Talk) 04:58, 2 June 2008 (UTC)

[edit] Using graphics to display text

Premier of Western Australia
Ministry
Provincial/State
Incumbent: Alan Carpenter
Style:	The Honourable
Appointed by:	Ken Michael as Governor of Western Australia
First :	John Forrest
Formation:	December 29, 1890

Does the manual of style have anything to say about the use of graphics to display textual information? If not, should it? I would have thought this was an extreme no-no, for both accessibility and stylistic reasons. Hesperian 01:12, 27 May 2008 (UTC)

It is a no-no in almost all situations, though I don't know if the Manual of Style explicitly addresses it. —Remember the dot ^(talk) 01:20, 27 May 2008 (UTC)

I agree, the example is a no-no. Use css markup if it has to look fancy.
— Apis (talk) 02:00, 27 May 2008 (UTC)

I hate it. Unfortunately, there's a shrill infobox lobby we have to put up with. Infoboxes and such graphics typically repeat what is (or should be) in the main text, and standardise and typically oversimplify information. TONY (talk) 07:26, 28 May 2008 (UTC) PS A good example of the latter is the "Governor appoints premier" statement. Um ... that has to be taken in context, as does the fact that the premier appoints the governor. Many of our readers will justifiably interpret that text in a way that is in fact highly distorted. TONY (talk) 07:27, 28 May 2008 (UTC)

Yes, we're off-topic, but yes, I agree. You should read the Utgard Loki quote at User:Future Perfect at Sunrise. Hesperian 12:39, 29 May 2008 (UTC)

As often, Tony has let his own prejudices run away with him; the question here is not infoboxes, but whether images should be used to display texts, in infoboxes or out of them. There is one argument against it, which we should make: it is unlikely to be read as text by devices for the visually impaired, and therefore deprives some of them of information without necessity. It would take a truly extraordinary visual effect, and this example isn't one, to make up for that, if it can be done at all. All we need do is state the reason not to. Septentrionalis PMAnderson 13:43, 28 May 2008 (UTC)

I can think of numerous reasons why not to do it, but the one you mention is probably the most important one. It goes against the very idea of the html format, makes the page take much longer time to load, is not handled like other text by the browser (e.g. can't change text size), is not only inaccessible to those visually impaired but any device that do not render images (e.g. text-only browsers), not indexed by search engines, bla bla bla...

I guess it could be used to illustrate an old manuscript (although then the actual text, if intended to be read, should be entered as text in the article as well. It could also be useful to illustrate a visual effect of some sort (e.g. italics or subpixel rendering).
—Apis (talk) 06:40, 29 May 2008 (UTC)

As you can see, I think "not indexed" is more important, and have edited accordingly, although it will only apply if the info is not repeated elsewhere in the article. I think we should explain the problems, and leave it at that.

We do have MS images. If the precise text is important, it should be quoted in the caption anyway; we are written for general readers, not for palaeographers. Septentrionalis PMAnderson 14:15, 29 May 2008 (UTC)

I would think, since Wikipedias goal is to make knowledge available to everyone, that not making the articles unnecessarily inaccessible would be a priority. Although I have no problem with the order of mention in the text (to me it does not signify which is more important).
—Apis (talk) 03:45, 30 May 2008 (UTC)

As you can see from the example on the right, I have reverted to a version that uses textual headers. We'll have to wait and see if it sticks. The question now is, should the MOS have anything to say on this point? Hesperian 06:52, 29 May 2008 (UTC)

This discussion is based on a misleading premise: the graphics being discussed here are not textual headers; the infobox has a textual header completely apart from the graphics. The graphics are organisational tools colour coded to differentiate between ministers (silver), viceroys (light purple), and monarchs (purple), as well as between the federal (red) and provincial (blue) jurisdictions. There is a word on each, but it's merely as a graphic, not meant to impart any real information beyond what the colour code already does. See Monarchy of Canada, Governor General of Canada, Prime Minister of Canada, Monarchy in Ontario, Lieutenant Governor of Ontario, and Premier of Ontario for examples of each use. I'm sure everyone will note that there are clear textual headers in each case. --G2bambino (talk) 14:20, 29 May 2008 (UTC)

You heard it here first, folks; it is a header, and it has text, but it is ain't a textual header. Hesperian 01:55, 30 May 2008 (UTC)

My, my; you don't take getting called out on your bullshit very well at all, do you. --G2bambino (talk) 12:00, 30 May 2008 (UTC)

I find this very reasonable. The graphics serve more as colour-coding with stylish lettering rather than as real text. Personally, I like the system; it combines aesthetics with informativeness and organisation–standardisation. Waltham, The Duke of 16:58, 29 May 2008 (UTC)

Your Grace surprises me with your lack of charity towards those poor unfortunates with less sharp eyesight, lower bandwidth, or lower resolution devices than your good self. Those who require large print can easily increase the font size, but cannot increase the size of this image. Those with no eyesight at all must use a screen-reader, which cannot know that this image is intended to be parsed as text. Those with low bandwidth are forced to download 1,829 bytes where 30 bytes would suffice. Those with low resolution devices set their image thumb size defaults to something very small like 120px, only to be served up a redundant image that is locked to 253px. Must "stylish lettering" trump such key accessibility issues? Hesperian 03:07, 30 May 2008 (UTC)

So much harshness, Hesperian... :-) I did not consider eyesight much of a problem, having focused mostly on the colours and not so much upon the text; it is not as common for one to be unable to see both the text and the colour as it is for one to have problems with one of these two elements, is it? In any case, my basic point was that it is not crucial information which needs to be read, but a helpful addition. Furthermore, the images were rather small; how much could they possibly delay the loading of a page? There were problems, true, but perhaps their full extent escaped me.

All that said, the solution now applied to the boxes seems to have improved the situation, although the aesthetic aspect has been perceptibly compromised. If the visual effect could be closer to the original, that would certainly be preferable; the purpose of the intervention was to improve the lacking parts of the feature, not to be forced to remove it altogether.

PS: Although I believe it needs more work, I must say that Apis's solution is a significant improvement over the previous attempt. Sorry Hesperian. (evil grin) Waltham, The Duke of 15:11, 30 May 2008 (UTC)

I'm sorry, I'm strongly against this, there is no reason for using an image here? Just make templates using CSS markup to make them display identically to the images (kind of as it was a while ago, but you could make it almost identical to the images if you fiddle a bit with it), that would be a superior technical solution, and it's more accessible. I can see no disadvantage to using a text version here (except perhaps some work updating infoboxes)? And I would have thought accessibility would be a priority anyway.
—Apis (talk) 03:19, 30 May 2008 (UTC)

If the CSS text were encoded directly in the page, it'd be much more time-consuming to revise the style later (compared to simply replacing some image files). Presumably we could use templates for this, though. Ilkali (talk) 06:14, 30 May 2008 (UTC)

I changed the infobox to use text and CSS again, although tried to better match the previous images. It is much easier to change now than when it was an image. Now you only have to edit the template (e.g. change a color, add a new bar, change the text of the bar and so on).
—Apis (talk) 07:07, 30 May 2008 (UTC)

This is fine: it works with the original intent of the colour-coded bars, and looks much more professional than Hesperian's, er.. attempt. The other three templates need updated to match, however; I can try, but I'd prefer if someone who has more expertese with X11 color names could at least look over my shoulder. --G2bambino (talk) 12:00, 30 May 2008 (UTC)

Well, my version is based on Hesperian's, I just changed font and colors to match the images better :) I will take a look at the other templates later if no one beats me to it.
—Apis (talk) 13:48, 30 May 2008 (UTC)

Yes, I see that it uses the same basic technique, but you gave more consideration to the look and spirit of the system. --G2bambino (talk) 15:07, 30 May 2008 (UTC)

For the reasons given, I would agree that the use of graphics for text should be generally discouraged; guidelines on the subject would be useful. Any such guidelines should perhaps brifely discuss typical exceptions, as in articles like Sans-serif and International phonetic alphabet.--Boson (talk) 06:35, 30 May 2008 (UTC)

[edit] Capitalisation of common noun god in monotheistic contexts

I started a discussion on MOS:CAPS about capitalisation in cases like "three persons in one god", but it's been a couple of days and it hasn't seen much attention. Since the policy in question is also delivered (in reduced form) on the main MoS, I'm hoping it's okay to link to the discussion here and ask for input. Ilkali (talk) 08:14, 28 May 2008 (UTC)

Actually, one should post a note here anyway, because many editors watch this page but not the supplementary pages of the Manual. Waltham, The Duke of 16:48, 29 May 2008 (UTC)

If you use god as a common noun, then it's a small g(e.g., The Abrahamic god, Mars was the god of war', ...). If you use it in the sense of the "proper noun" of the Abrahamic god, then it's a capital g (e.g., God said "Kill them all.", The scent of burnt animal flesh is pleasing to God). If referring to some more or less defined supreme deity, then it also takes a capital g (What is God? God is the feeling you get when a baby cries). Headbomb (ταλκ · κοντριβς) 20:40, 6 June 2008 (UTC)

That is more or less my policy too. Unfortunately, it seems that you and I (and a good four other people listed in the discussion) do not exist. Ilkali (talk) 07:03, 7 June 2008 (UTC)

[edit] Full stops

Notice that in our subsection that was titled "Periods and spaces" two days ago, the name was recently changed to "Periods/full stops and spaces", and I just swapped in parens for the slash. The first sentence includes full stop and period, and even though the "official" language for WP:MOS is American English, I'm fine with the pre-existing first sentence if there are a fair number of non-Americans who will be looking for guidance on "full stops" in the MOS...and I think there are. Given that first sentence, I'm fine with the change to the subheading (or what will become the subheading if/when we ditch the leading semicolons). Does anyone want a change from the current version? - Dan Dank55 (talk)(mistakes) 13:58, 30 May 2008 (UTC)

It's fine. I was the one who originally changed it. Although this article is written in American English and it should be written that way throughout, there are some words, which need to be used in British English too. For example British Wikipedians understand color as colour; that's a spelling difference. The problem arises when this article uses entirely different words, especially when they're not recognised in the United Kingdom. Period is an example of this and in this case we should adhere to both the American word and British word. Meaty♠Weenies (talk) 14:03, 30 May 2008 (UTC)

Of course, there are more than two dialects in the language but, from an Australian perspective, no, period is not a well recognised name for a full stop down under either. JIMp _talk·cont 16:54, 1 June 2008 (UTC)

[edit] NBSP change

I have just become aware through User:Tony1/Monthly updates of styleguide and policy changes/May 2008 of an unfortunate change at WP:NBSP (thank goodness for Tony's updates).

The scope of the recommendation to use a non-breaking (i.e., "hard") space was narrowed from all instances where:

"numerical and non-numerical elements are separated by a space", to all instances where:

"measurements in which values and units are separated by a space".

Compound items such as "20 chairs" are thus excluded from the recommendation.

Not a good change. Why should we see 20 on one line and chairs on the next? And why should terms like Boeing 747, Apollo 7 or 7 World Trade Center have unnatural line breaks? I oppose this change; can someone point me to the discussion please? Thanks, SandyGeorgia (Talk) 16:05, 1 June 2008 (UTC)

Sandy, I think the rationale is that while the need to keep together values and units (especially symbols/abbreviations) is important, the need to avoid splitting "20" and "chairs" is somewhat less. On the other side, where hard spaces are used liberally—for almost every number in an article, they are more likely to slightly damage the appearance of the text by stretching interword spaces (where the default justification is used, which includes almost all readers) on many lines. It matters yet more when lines are shortened by the presence of an image or by the use of a small monitor. TONY (talk) 17:22, 1 June 2008 (UTC)

For comparison, we have no problem with putting The Twelve on one line and Chairs on the next, although The Twelve Chairs is more of a unit than most mentions of 20 chairs will be. Septentrionalis PMAnderson 20:05, 4 June 2008 (UTC)

I've changed my position from a few months ago, and maybe I'm alone in this, I don't know. Can anyone find a style manual or anything like a style manual that supports the idea that content editors of any kind should be inserting hard spaces? Chicago, AP Stylebook, and NYTM don't seem to even approach the issue. As I mentioned previously, I think the issue here is that there are some abbreviations (of units and otherwise) that cause a person skimming down the article to stop and go "Wha?" if they appear by themselves at the beginning of a line, so per the principle of least astonishment, IMO it would be nice if lines didn't wrap in the middle of "3 cm" or "Ames IA" (Iowa, USA). But I'm more interested these days in promoting collaborations between content experts and experienced Wikipedians, and I'm getting more and more nervous about being put in the position of having to defend orthography that none of the style manuals will touch; if a rule is considered too fussy even for academicians, authors and journalists, then it ought to be too fussy for us. If people in their roles as copyeditors want to agree on where to wrap the lines, that's fine, and if we want to follow up on the bugzilla thread to do some of it by software, that's even better, but it shouldn't be in WP:MOS or WP:MOSNUM and shouldn't be expected from editors, unless we can come up with support for the idea that this is expected outside of Wikipedia. - Dan Dank55 (talk)(mistakes) 17:39, 1 June 2008 (UTC)

The Chicago Manual of Style and The Oxford Guide to Style both advocate not separating numerals from the accompanying abbreviation (e.g. "15 kg or "300 BC") but don't seem to say anything about separating numerals from most other text (unless you count "Louis XIV").--Boson (talk) 19:01, 1 June 2008 (UTC)

I was still seeing it in Chicago 3 months ago, but now I can't find it...they've moved or deleted the recommendation. Now they say that a "word space" (which isn't an nbsp) should go between numbers and units. - Dan Dank55 (talk)(mistakes) 13:00, 2 June 2008 (UTC)

Where are you looking? Try looking for the treatment of the space between a number and a symbol/abbreviation; that might be different than the treatment of the space between a number and a spelled-out unit. --Gerry Ashton (talk) 16:52, 2 June 2008 (UTC)

Chicago 15.55: "A word space usually appears between a numeral and an abbreviation. [examples] 4 L [,] 13 Mc". By "word space" they mean: not nbsp, not the space between sentences, and not a half space...a normal space. A search on nbsp now comes up empty, and I couldn't find anything about line wrapping, word wrapping, or anything in the sections on punctuation, units or abbreviations. If they have moved it somewhere, I'd like to know where. - Dan Dank55 (talk)(mistakes) 18:44, 2 June 2008 (UTC)

I was looking in the 14th ed. (being too cheapskate to buy every edition). It was under "Word Division", "NUMERALS", 6.55: Abbreviations used with numerals should not be separated from the numerals:

345 mi. 24 kg 55 B.C. A.D. 1066 6:35 P.M.

I was also looking at an old edition of The Oxford Guide to Style (2nd ed.), under "Word division", p. 140: Do not break numerals at a decimal point, or separate them from their abbreviated units, as with 15 kg or 300 BC. The Oxford Guide to Style also has: Do not break place names or (especially) personal names, if possible. [. . .] Do not break between a name and a modifier: Louis XIV [...].

I can only speak semi-intelligently about American English. It's gone from Chicago now; I just read everything in Chapter 9 (Numbers), searched on "word division" (seems to only cover hyphens now), and searched on "numerals". - Dan Dank55 (talk)(mistakes) 22:46, 2 June 2008 (UTC)

Wait, I found it, although it's not much. It was, unhelpfully, under "spelling":

7.42 Abbreviations [:] Abbreviations used with numerals are best left intact; either the numeral should be carried over to the next line or the abbreviation should be moved up.

345 m

24 kg

55 BCE

6:35 p.m.

- Dan Dank55 (talk)(mistakes) 22:54, 2 June 2008 (UTC)

So should something like "State Route 9" or "SR 9" be allowed to wrap or not? --NE2 18:27, 1 June 2008 (UTC)

People have gone berserk with nbsp. I would like to say that line breaks are a *good thing*. One of the benefits of the modern world is that the internet is available regardless of screen size. Try it on a pocket device and you will see what I mean. Line breaks are needed to fit things on the screen. I would hardly notice a problem with a line break in '20 chairs' and 'Boeing 747'. As Dank55 said, I think it might be nice if '3 cm' and 'Ames IA' did not break but I think we have gone too far in mandating the use of nbsp. It used to be optional. Please think about limiting the scope of nbsp because line breaks are good. Lightmouse (talk) 19:40, 1 June 2008 (UTC)

Once again, where is the discussion that led to this change? SandyGeorgia (Talk) 04:52, 2 June 2008 (UTC)

I agree with Lightmouse. Apart from the visual appearance for our readers (the balance struck too far towards the risk of inter-word stretching), without a shortcut key-in for hard-spaces, and without even a button below the edit-box, will you believe, it's a pain to type them in; and it doesn't make the editing job any easier when the gobbledygood subsequently appears in the edit window. I, for one, have to slow down and think everytime I see it.

I'm happy with the new text, but here's a compromise that you may like to consider:

In compound measurements in which values and units are separated by a space, a non-breaking space (also known as a hard space) is recommended to avoid the displacement of those elements at the end of a line. Hard spaces may also be considered where line-end displacement might be disruptive to the reader (7 World Trade Center).

Sandy, the discussion was some months ago, and if you like I can try to locate it (MOSNUM and/or MOS talk); Noetica was involved, and agreed that the use of hard-spaces should be constrained in some ways. TONY (talk) 04:58, 2 June 2008 (UTC)

Actually, there is a button; it is amongst the first ones in the "Wiki markup" section. Waltham, The Duke of 00:21, 4 June 2008 (UTC)

What's so special about numbers? Is it really that much more jarring to the reader to have a number and a word in separate lines than having two words in separate lines? (If there is a study about that, I'd like to see it.) I don't see any rules for inserting non-breaking spaces between articles and nouns, between verbs and adverbs, or between given names and surnames. Or even in the middle of an infinitive. While I see the suggestion of some style guides to put a nonbreaking space between 15 and kg as not too unreasonable, it can be taken too far. At least in science, not all units and numbers are one or two characters long. I decided to take a look at a few recent articles in the Journal of the American Chemical Society and Science, and I noticed that they are not afraid of putting a number and a unit in separate lines. I also noticed that in some cases a full number plus unit can easily take half a line of text. Refusing to split such a monster would be as problematic as refusing to hyphenate supercalifragilisticexpialidocious. But these journals don't mind splitting even the short cases. If they don't mind, why should we? Or does one need to be a scientist to be able to put a number and a word or symbol together when they are on different lines? I don't buy it. --Itub (talk) 11:16, 2 June 2008 (UTC)

• I proposed the compromise above to give leeway to editors to insert hard-spaces in unusual or difficult compound items on a case-by-case basis; this seemed to satisfy Sandy's misgivings. What I (and others here, I think) definitely don't want is encouragement to insert that hedgehog string in 11 kangaroos, etc. I've been seeing a lot of this in FACs. TONY (talk) 17:07, 2 June 2008 (UTC)

• Well, I'm worried about Boeing 747 and Apollo 8; terms like that shouldn't be split. I'll have to try to track down the old conversations when I'm home (I hate automatic archiving because it makes it so hard to know where old threads end up; if you know where it is, help appreciated :-) SandyGeorgia (Talk) 18:18, 2 June 2008 (UTC)

I've gone back and checked now, and this seems to be another of those recent, not broadly discussed MoS changes, made only in the last few weeks (May 21 and May 26).[2][3] I disagree with this change, and suggest going back to the long-standing wording, "In compound items in which numerical and non-numerical elements are separated by a space ... " I'm glad we're now made aware of these changes via Tony's monthtly updates, but this weekly tweaks and changes continue to frustrate. SandyGeorgia (Talk) 08:46, 3 June 2008 (UTC)

I'm interested less in delving back into archives than producing the most desirable guideline. I totally disagree with the encouragement to glue together "20 chairs". Sandy, do you really want gobbledygook to be used in those places? Not happy, and there seems to be little support here for this reversion. TONY (talk) 08:52, 3 June 2008 (UTC)

No, I don't care about 20 chairs; I do care about the other issues I mentioned, which were previously covered. That people may be putting NBSPs before numbers of chairs seems to me a matter of rewriting a guideline to legislate common sense; you can't do it. Well, you can try, I guess :-) But losing Boeing 747 or Apollo 8 because people were stupidly putting NBSPs on 20 chairs is throwing out the baby with the bathwater. SandyGeorgia (Talk) 08:57, 3 June 2008 (UTC)

• As you've now made it, you have to put a hard-space in 20 chairs. It's a pain in the edit box when copy-editing articles that have a lot of them. And there's the slight stretching issue. I proposed a compromise above; however, it might require more detail. Please consider this (since updated on the basis of feedback below):

TONY (talk) 14:01, 3 June 2008 (UTC)

Your feedback is welcome:

• We can put Boeing 747 in with 7 World Trade Center. It may be worth saying (to avoid putting in unnecessary  s) that this recommendation applies where lines are likely to break (i.e. not in tables, not where the space is in the first few words of a paragraph, etc., although I don't think we need to spell this out.) Septentrionalis PMAnderson 21:27, 3 June 2008 (UTC)

Done, at least the 747 example. I think you're suggesting not to explicate the other stuff (I agree). The "such as" fifth point gives editors the leeway. TONY (talk) 08:26, 4 June 2008 (UTC)

I was going to insert your recommended "where lines are likely to break", but couldn't find a neat place for it—the lead is long enough already. And it seems obvious from the "to avoid disruption" phrase that you don't need it in tables, etc. TONY (talk) 03:19, 5 June 2008 (UTC)

We want to be careful with the last. For one thing, we will often want to link Louis XIV of France, which should mean no hard spaces. On the other hand, in such articles as History of France or War of the Spanish Succession, it will require an awful lot of hard spaces: does William III and Louis XIV agreed that the possessions of Charles II should pass to the Electoral Prince of Bavaria rather than to the eventual claimants, the later Philip V and Charles VI. really need all five? Septentrionalis PMAnderson 01:56, 4 June 2008 (UTC)

(edit conflict) I have capped my comments in order to take up less space. I have also modified a section; I had confused Tony's "either" for "both" in the fourth bullet about spaces around en dashes.

I saw the example of monarchs mentioned higher above and found it very reasonable; stray numerals at the beginning of lines will look bizarre, and first mentions of monarchs will be a little more confusing without the accompanying numerals. Note first mentions; most instances of these names will not repeat the numerals, so the hard spaces of this type will not be dozens in any given article, as it might initially appear, but rather ten or fewer; up to twenty in the worst cases. Waltham, The Duke of 02:13, 4 June 2008 (UTC)

That clarifies whether you want Scylla or Charybdis; but that still leaves the problem that the first mention is also the one we want to link with. Do we really want to require [[Louis XIV of France|Louis XIV of France]]? Septentrionalis PMAnderson 02:27, 4 June 2008 (UTC)

Not require... Except for FAs, I suppose, but even there the phrasing suggested above will not make it mandatory to follow these examples.

That said, forget not that some of these linked first mentions are pipe-linked anyway, so this takes away another little piece of the problem. :-)

And we need not worry about info- and succession boxes, for names in there, as you say, usually don't wrap anyway. Yet another piece gone. There's not that much left, is there?

Anyway, it's almost 6 am; I think it is time to sleep. I shall reply to anything that comes up tomorrow. Waltham, The Duke of 02:47, 4 June 2008 (UTC)

• Your Grace: I hope I've covered your suggestions (except for the full unit names, which I leave open for discussion). TONY (talk) 08:26, 4 June 2008 (UTC)

• So I guess now what we need people's opinion on is:

1. whether the list and the "such as" final point that gives editors leeway is acceptable;
2. whether it would be better to leave out the nowiki html hard-space codes in the instructions, since they make it pretty hard to read. TONY (talk) 08:26, 4 June 2008 (UTC)

• • They make it very hard to read, and the only place it now resolves an ambiguity is 7 World Trade Center; try the first space in for that, which will make the point more explicitly anyway.
    • On the machine I am currently using, my last post happens to have broken after the 7. Is 7

    World Trade Center really a serious problem? Septentrionalis PMAnderson 19:59, 4 June 2008 (UTC)

  • Mathematical examples should exclude <math> expressions. Septentrionalis PMAnderson 19:55, 4 June 2008 (UTC)

I'll repeat since we're voting: it's not very important to me, but I have concerns about going farther than American style manuals in American English articles, so I'd prefer a light touch. Also, I think there's a risk of losing content experts in sci/tech/math who read that they're supposed to write "2&nbsp;+&nbsp;2&nbsp;=&nbsp;4", regardless of any disclaimers or reasons we offer. This kind of thing is what the <math> tag is for. - Dan Dank55 (talk)(mistakes) 20:35, 4 June 2008 (UTC)

You mean there's a template for maths expressions that will avoid the gobbledygook? Better to exclude the example, then, and just say to use the math template, don't you think? Anderson, does that mean the non-breaking code doesn't work? How's the text now? TONY (talk) 02:54, 5 June 2008 (UTC)

I'm happy, if you add something like Boeing 747 or Apollo 7 to the last example; if people don't see it, they don't think of it. Thanks :-) SandyGeorgia (Talk) 02:59, 5 June 2008 (UTC)

Well, to reverse Anderson's point (he suggests not the 7WTC, but to include Boeing 747), I don't have a problem with Boeing

747, since "Boeing" at line's end prepares the reader for a number, we're so used to it. This is quite unlike having a "7" dangling at line's end, which doesn't at all prepare us for "World Trade Centre" (or "kg"), and thus requires reverse-disambiguation. But ... if you insist, hmmm. TONY (talk) 03:19, 5 June 2008 (UTC)

Actually I suggested both, to compromise between other people's suggestions, but I'm no longer convinced we need either, except when there is unusual likelihood of confusion. Septentrionalis PMAnderson 19:54, 5 June 2008 (UTC)

<math>, it's a tag not a template see Help:Displaying a formula. JIMp _talk·cont 03:51, 5 June 2008 (UTC) I'm pretty sure (I tested narrowing the help page I mention down) that that within the <math> tags does not wrap. It would be nice to have a word recommending that mixing these <math> expressions with regular text on the same line should be avoided wherever practical. I'm often finding stuff like 10⁷ spotted throughout prose, an unnecessary change in font. JIMp _talk·cont 04:12, 5 June 2008 (UTC)

All that should be in WP:MSM, which describe the tag. Septentrionalis PMAnderson 19:54, 5 June 2008 (UTC)

• On further thought, I doubt we want to encourage runs of non-breaking spaces in mathematical expressions at all. If they are likely to break, make them a separate line, with ordinary spaces; if they're too long for that, use <math>.
• Long non-breaking expressions can seriously screw up format; consider this edit of Omar Khayyam, which has (at least on my machine) a lake of white next to the infobox because somebody wanted to have the Farsi not break. Septentrionalis PMAnderson 17:21, 6 June 2008 (UTC)
  • I strongly agree. Do you mean I should remove the maths point altogether? TONY (talk) 02:45, 7 June 2008 (UTC)
    • I do not understand why there couldn't be a space after the colon, even if the Farsi part would be glued together. The visual effect of this is awful. In any case, I agree with the removal of the maths point, and would even support its conversion to a counter-point ("Do not use hard spaces for mathematical expressions..."). Waltham, The Duke of 15:08, 7 June 2008 (UTC)
    • Probably best to remove it, unless we recast the section into a discussion of solutions of badly breaking lines; in which case we would have two or three cases which are fixed by hard spaces, and a separate sentence on mathematical expressions, which are fixed otherwise. Septentrionalis PMAnderson 22:07, 7 June 2008 (UTC)

[edit] Double-barrelled surnames

Brought across from Wikipedia talk:Naming conventions (people)#Double-barrelled surnames

for Jane Watson-Smith, for instance, should we use a hyphen or ndash? Happy‑melon 20:18, 30 April 2008 (UTC)

Ahem! Cough cough! Happy‑melon 11:20, 1 June 2008 (UTC)

WP:MOS#Hyphens and WP:MOS#Dashes? Don't think this is a WP:NCP issue. --Francis Schonken (talk) 12:03, 1 June 2008 (UTC)

Moved as requested. What do you think? Happy‑melon 14:07, 3 June 2008 (UTC)

Definitely hyphen for proper surnames. I believe that there are some dubious cases for certain titles or title-derived surnames, but I know little about this, and it sounds quite uncommon anyway. Waltham, The Duke of 17:48, 3 June 2008 (UTC)

[edit] Caps controversy in the following series

{{tl:MedInst}}

These are lists of articles used in special branches of medicine. Thus they have been named, in general, as "Instruments used in Field". The F needs to be capitalised as it is a name of a subject. Any bureaucrats coming to mediate??sarindam7 (talk) 22:09, 3 June 2008 (UTC)

No. This is a job for administrators (although any editor could mediate, unless the situation has spiralled out of control to the extent that blocks are necessary). Waltham, The Duke of 00:30, 4 June 2008 (UTC)

Since when do we capitalise the names of subjects? Read botany, biology, physics, whatever. They all refer to their topic in lower case unless at the beginning of a sentence. Sarindam is wrong; there is no reason to capitalise the names of fields, and these should all be moved (or moved back) to the lower case title. P.S. don't go looking for the discussion; it was on Sarindam's talk page, but is now archived. This will need to be discussed here. Hesperian 01:53, 4 June 2008 (UTC)

Ok....understood. Just thought that subject name needed to be capitalised. Applying MOS discussion and correcting namessarindam7 (talk) 09:56, 4 June 2008 (UTC)

[edit] Language tags

I don't know if this is the right place for this discussion, if not, please kindly me point me to the right place.

I noticed another user recently adding the template lang to some titles in foreign languages (French in this case) in some articles (e.g. here[4]), and wondered what it was used for, as it has no visible effect on the page. It turns out after a friendly discussion with the user that it is supposedly useful for people and/or tools spell checking texts, so that they don't try to "correct" text which isn't in English.

I'm not really happy with these tags, as they seem to me to be a solution looking for a problem (since none of these articles or many others I have watchlisted seem to have the problem of erroneous spelling corrections in these cases), and a nuisance for editors (yet another level of tags around titles, which often already have double [ and double ' around them). I would like some discussion to see if other people feel we should encourage or discourage this in general, or if it should only be used in some cases but not in general. As is probably clear, at the moment I'm in favour of completely discouraging it since the perceived benefit of the tags is too small to outweigh the extra trouble it gives. Fram (talk) 19:02, 5 June 2008 (UTC)

A puzzlement. The quite useful tags {{Lang-fr}} and {{fr icon}} do label with reader useful information; but the Template talk page is the best place to ask. Septentrionalis PMAnderson 19:20, 5 June 2008 (UTC)

I'm the 'other user' in question, and after friendly discussion with Fram, I think that adding these language tags is appropriate, while (s)he disagrees. In the past I have made incorrect edits of foreign-language text using English typo lists, so was acting partly in a preventative manner and also because I understand that these language tags help browser encoding for more exotic languages, and finally that I think adding these tags enhances the quality of an article (clarity for future editors etc.). The fact that no error has been made on a particular page to date doesn't really interest me, as an ever-expanding list of English typos may catch a foreign word in the future and errors have certainly been made on other pages with the same foreign word. My interpretation of template:lang is that my actions are correct, Fram thinks otherwise. I am hoping for confirmation that I'm right ;) and would like template:lang to be clarified after resolution of the issue. Thanks Rjwilmsi (talk) 19:23, 5 June 2008 (UTC)

To be clear, I believe that what you did was a reasonable reading of what the template page describes. However, I also believe that use of the template should be discouraged, since its benefits are smaller than its disadvantages. Pages about foreign authors, musicians, awards, ... would be filled with these tags. A page like List of works by Johann Wolfgang von Goethe would have about 28 tags,and I'm not going to count it here: Rammstein discography. All tags and markup make editing by casual editors harder, and I don't believe that they provide clarity for future editors (in the examples I have seen, it was quite clear from the article what language the tagged titles had). Fram (talk) 07:02, 6 June 2008 (UTC)

Besides spellchecking, these tags can be used by screen readers to provide correctly audio output, and users can change their style sheets to display different languages using different fonts and styles. I say this is a significant benefit. Much greater than screwing up the wikitext to introduce unnecessary non-breaking spaces as per the latest fashion, IMHO. --Itub (talk) 08:55, 6 June 2008 (UTC)

Screen readers may indeed be a good reason. I don't see why people would want to display the French title of a book or the German title of an opera in a different font or colour, but to each his own, I presume. And I don't really understand what you are referencing with the "unnecessary non-breaking spaces" line, couldyou provide a diff with an example? Fram (talk) 11:18, 6 June 2008 (UTC)

I just saw the above discussion on NBSP and realised that this is the thing you were referring to, so you can ignore my question. Fram (talk) 11:24, 6 June 2008 (UTC)

Another (and, in my opinion, the most important) benefit is that these tags provide language metadata to search engines, allowing to search for, say, French terms, without confusing them for English or something else. Also, as correctly noted above, for non-Latin-based languages these tags allow for a selection of an appropriate font.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 14:25, 6 June 2008 (UTC)

[edit] Curly or straight?

Should one ever use “curly” inverted commas - or only ever use "straight" ones?
The MoS says that curly ones are dangerous because they're difficult to type and can affect search results (imagine wondering why you can't find Jane's Addiction because the article has been titled Jane’s Addiction) and "recommends" that only straight are used. On the other hand on the first line of insertable characters beneath the edit window we see

– — … ‘ “ ’ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · §

Are they there just to tease us? Or are there some circumstances when they're appropriate?
For example the Philip Larkin entry currently has a section entitled

1969 – 1985: “Beyond the light stand failure and remorse”

which to my mind looks good and is non-confusing almost-instinct 10:15, 7 June 2008 (UTC)

The same question has come up, without any good answer, at WT:WikiProject Hawaii/Manual_of_Style#It looks_like_you_guys_are_working_on_this_style_guideline:

"When the okina is used, which form to use. For instance: Keaweikekahiali`iokamoku uses what appears as %60 in the url; Kiwala‘o uses what appears as %E2%80%98 in the url; Kame'eiamoku uses what appears as %27 in the url; ʻIolani Palace uses what appears as %CA%BB in the url. [punctuation added]. Some of which don't always show up in all browsers. I don't know which should be preferred (if any at all). Mahalo. --Ali'i 14:32, 2 June 2008 (UTC)"

We also haven't resolved when to use a breath mark ("okina") at all; help would be appreciated. - Dan Dank55 (talk)(mistakes) 12:02, 7 June 2008 (UTC)

Compelling reasons not to use curly quotes were put when this came up about six months ago; perhaps we need to dig up that debate. Yes, I noticed only the other day that the curlies are there below the edit box; they should be removed. TONY (talk) 12:32, 7 June 2008 (UTC)

In that case I agree that they should be removed asap: currently they're far too pretty to be resisted. Should also the "recommended" in the MoS be changed to something stronger? almost-instinct 12:39, 7 June 2008 (UTC)

On the separate topic of deleting some of the characters on the panel, I think that a check should be made of where they are used before deleting them. Are the curly brackets needed for any foreign language words, pronunciation syntax, complex mathematical notation, or somewhere else? They may not be found on some keyboards. Is is useful to have a full set of characters to use when a particular language keyboard does not have the required keys? I often use the panel of characters (although not the curly brackets) and it may look odd with some missing. Perhaps, there should be a link at the bottom of the panel to a page on the suggested use of special characters, and for example; the use of straight brackets in preference to curly brackets could be easily found and explained. This may help to stop editors using the panel inappropriately, and make it easy to quote from. Snowman (talk) 12:48, 7 June 2008 (UTC)

I think the debate referred to in Tony's comment “this came up about six months ago” is section three of Wikipedia talk:Manual of Style/Archive 94 — though maybe the conversation continued on a later page? Certainly both sides put forward powerful arguments, but the discussion, as given here, frustratingly fell short of declaring a consensus. Is there another part of the archive we should be looking? almost-instinct 23:35, 7 June 2008 (UTC)

I couldn't find it on my first attempt. Noetica was a key proponent of straight-quotes-only. He's not around at the moment. TONY (talk) 13:34, 8 June 2008 (UTC)

[edit] Can we have wp:mosnum back?

The wp:mosnum policy page cannot be used for reference because it contains non-policy. Anyone that reads it could be mislead into thinking that non-policy is policy. This is acceptable to the people that are controlling wp:mosnum now. Anyone that tries to remove non-policy is just reverted.

The wp:mosnum talk page used to be active with discussions on a variety of topics. It is now dominated by the binary prefix war and its collateral damage. The binary prefix war was moved to a page called Wikipedia talk:Manual of Style (binary prefixes) but that lasted just a shortwhile before the page and the warfighting was moved back. It is a place for sockpuppets, puppetmasters and anonymous editors. They keep saying that the war will soon be over and then normal service will be resumed ...

The policy page and its talk page used to be worthwhile places. It had contributions on a variety of topics from many editors. Sadly, the policy page is not reliable and the talk page is scary. Does anybody have any suggestions as to how we can have a policy page and talk page where things other than binary prefixes matter? Lightmouse (talk) 15:47, 7 June 2008 (UTC)

My solution is less than ideal, but what I did was to leave it out of Category:General style guidelines, and I ignore the page. As I said on that talk page last month, not every policy and guidelines page needs more input from relevant sources, but that page does, to shed some light on how those matters are dealt with in professional English. What I aim for in Good Articles is something that wouldn't be out of place in Scientific American and other publications that popularize science for interested and literate readers. - Dan Dank55 (talk)(mistakes) 16:28, 7 June 2008 (UTC)

I agree with Lightmouse that MOSNUM has become an unpleasant place of doubtful authority since its takeover by an aggressive cabal, including members who quite clearly have created or countenance the creation of sockpuppets to get their way (a forensic analysis of the language of one of those socks indicates to me the owner). MOSNUM used to be a worthy page that attracted expertise such as that of Jimp and SMcCandlish, among quite a few. Now, I can't bear to have it on my watchlist.

At least we have the most important parts of MOSNUM duplicated here at MOS. TONY (talk) 17:13, 7 June 2008 (UTC)

I know that we want to limit sprawl in the Manual of Style, but there are other factors to consider as well... This is a serious situation that we facing here. I have done some thinking, and the idea occurred naturally to me. Perhaps it would be better to split MOSNUM.

The "dates" and "numbers" sections seem distinct enough, and could easily go their separate ways; there is even a difference in that the "dates" part is of significantly wider application. The only element holding this dipole together seems to be the part about hard spaces, and that is almost a duplicate of its counterpart in the main page, so removing it would actually save us some redundancy. I realise that the page does not suffer from a length problem, but I find that the density of debatable guidelines is too great, clogging the talk page with constant disagreements about unavoidably minor issues (in terms of overall impact). Splitting the page would separate the guidelines—removing at least some ownership problems—but most importantly, it would spread the relevant discussions and thus make the associated talk page(s) less hostile, and the resolution of the various issues easier. I know it is not a perfect solution, but given the lack of central co-ordination in the Manual, there seem to be few alternatives if we want an effective management of MOSNUM. Isolating it in any way or ignoring the problem will only make things worse. Waltham, The Duke of 19:21, 7 June 2008 (UTC)

All of these pages are non-policy. That's why they're called guidelines. MOSNUM may have more statements of some editor's opinion than most, but nor by much, and it would be hard to prove. Septentrionalis PMAnderson 23:12, 7 June 2008 (UTC)

I assume that Lightmouse merely uses "policy" and "guideline" interchangeably; many people use the generic term policy (uncountable) when referring to community-approved guidance as opposed to statements promoted by a handful of editors. Even unofficial practices may be referred to as "policy" in some cases, although rarely in Wikipedia. I request that we should eschew unnecessary repetition of the familiar arguments about the importance of the Manual of Style. Waltham, The Duke of 00:12, 8 June 2008 (UTC)

[edit] En dash or em dash in tables?

I'm finding it unclear whether ndashes (–) or mdashes (—) should be used in tables to mark "empty cells". For some reason I remember reading it somewhere, perhaps in an old version of the MOS, that mdashes should be used. This is also what a lot of WP:FLs use (though this may in part be because I always say they should be used in my WP:FLC reviews). A recent discussion at WT:FLC#hyphens in blank squares: why not en dashes? brought this issue up, and I just wanted to get a firm answer from the caretakers of MOS. Once this has been confirmed, could a line please be added to WP:DASH. Thanks! Matthewedwards (talk · contribs · count · email) 05:08, 8 June 2008 (UTC)

I propose that en dashes be formally recommended here. TONY (talk) 07:38, 8 June 2008 (UTC)

[edit] Names with proper given names and usual nicknames

I can't find guidance on how to write the name of someone called "Noel Hughes" who was always called "Josh". There could be many ways eg

1. Noel "Josh" Hughes (what I imagine WP will settle on)
2. Noel 'Josh' Hughes (what the index of the book I'm working from uses)
3. Josh Hughes (properly "Noel")
4. Noel Hughes (usually called Josh)
5. Josh (born Noel) Hughes

As a further issue, would James "Jim" Sutton just be called Jim Sutton, since Jim is a known nickname for James?
Apologies if this decision has already been taken and I've failed to find the policy almost-instinct 07:45, 8 June 2008 (UTC)

Wikipedia:Use common names. The article would be at Josh Hughes; the name within the article would say Noel "Josh" Hughes. Rebecca (talk) 09:25, 8 June 2008 (UTC)

Thank you! So within an article on someone else I could refer to him thus: Noel "Josh" Hughes? If this policy is non-contentious, could/should it be inserted into the MoS main page? almost-instinct 12:28, 8 June 2008 (UTC)