Wikipedia talk:Manual of Style: Difference between revisions

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)[reply]

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)[reply]

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). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

• 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)[reply]

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).[1][2] 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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

• 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)[reply]

• • 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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

<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 ${\displaystyle 10^{7}}$ spotted throughout prose, an unnecessary change in font. JIMp _talk·cont 04:12, 5 June 2008 (UTC)[reply]

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

• 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)[reply]
  • I strongly agree. Do you mean I should remove the maths point altogether? TONY (talk) 02:45, 7 June 2008 (UTC)[reply]
    • 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)[reply]
    • 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)[reply]

Should we encourage the preemptive use of &nbsp;? It does make edit screens less readable, which is a cost; and it occurs to me that in most of our examples, it may be makework. Consider; when will Lorem ipsum dolor sit amet, consectetur adipisicing elit – sed do eiusmod tempor break before the dash?

• Lorem ipsum dolor sit amet, consectetur adipisicing elit must fit on one line
• Lorem ipsum dolor sit amet, consectetur adipisicing elit – must not fit
• and the display routine on the computer involved must fail to catch it.

For this reason, it is preferable to fix a bad break if it happens, but otherwise it is OK to leave well enough alone. Septentrionalis PMAnderson 17:20, 10 June 2008 (UTC)[reply]

But whether it occurs in the absence of a hard-space will depend on how large your window is and your font/font-size settings. Nice to use the Mac option-space, which does the job without the gobbledygook code—just looks like a normal space. The disadvantage, of course, is that you see only the result, not the mechanism, so subsequent editors can't be sure it's been done. All the more reason we should pursue an easy code such as double comma or the like to represent hard-spaces, not the ugly five-character duckling we are currently forced to use. TONY (talk) 01:38, 11 June 2008 (UTC)[reply]

But it will only happen for those window/font combinations in which the line is exactly the wrong length. This means it will occur (if at all) 1 or 2% of the time. Fix it if it cocurs, but why go hunting for it? the other 98% of us all have to put up with the &nbsp; goobledegook. Septentrionalis PMAnderson 19:38, 11 June 2008 (UTC)[reply]

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[3]), 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Allright, obviously enough benefits to keep on using them. I'll not add them myself (enough other things to pay attention to already), but I'll not discuss it if other people do so. Thanks everyone for patiently explaining. Fram (talk) 18:35, 8 June 2008 (UTC)[reply]

Okay, those tags could in theory be useful in various ways but is that actually the case? Can anyone point to a page where a tag like this makes the difference between text being correctly displayed or not? Do actual screen-readers pay attention to them? Do actual search engines use them? Can we have some examples where the tags are clearly doing some good? The original edit which sparked this discussion still seems confusing and crufty to me.[4] Why not mark all the French titles in the article? It looks to me like these templates are yet another thing which raises the bar for newbies and clutter page histories. These may be acceptable sacrifices but only if the benefits are clear and demonstrable. I don't feel the added convenience to typo checkers is enough of a benefit. Haukur (talk) 16:45, 10 June 2008 (UTC)[reply]

The right place for this is WP:TFD; if someone takes the initiative to move it there, please let us know.

• Ëzhiki's statistical point seems weak. This will never be applied to all the French text in WP; most editors don't know about it, and some will use italics or links for en passant anyway. Septentrionalis PMAnderson 16:57, 10 June 2008 (UTC)[reply]

Here is one example off the top of my head—Bashkortostan. In absence of {{lang-ba}}, the Bashkir name would not be displayed correctly. As for the statistical point, just because not enough editors are aware of these templates is not a reason to get rid of them, especially considering all of their benefits (even though those benefits are not immediately obvious). Case in point—Wikipedia did not support the div tags for quite a while, because, seemingly, there was no use for them. If we continued not to support these tags, then none of the existing navbox templates would have been possible, among many other things. The bottom line—if you find these templates too unwieldy or difficult to use, then just ignore them. Someone else will add them in places where they are useful (although not necessarily to you).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:03, 10 June 2008 (UTC)[reply]

• • {{lang-ba}} has never been in question. It is the {{lang}} template, which has no effect on text and which actually competes with {{lang-ba}}, which may be deletable. Septentrionalis PMAnderson 17:12, 10 June 2008 (UTC)[reply]

Ah, I see. {{Lang|ba}}, however, is supposed to do exactly the same as {{lang-ba}}, except it would omit the "Bashkir language: " specifier, which is useful when several Bashkir terms are listed in the same article (as to not clutter the page). As for the language markup, it does help in search engines. Can't say anything about French, but it is, for example, possible to google Wikipedia for just Russian words without having to see identically spelled Ukrainian, Belarusian, or Bulgarian ones. This, of course, only works when the words being looked for are properly tagged with the lang template.

In any case, if you feel so strongly about this template, feel free to list it on TfD. I expect the outcome be the same as before—the template will survive (exactly because it is useful), but it is your right to do whatever you feel is the right thing. Best,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:24, 10 June 2008 (UTC)[reply]

This is still fairly vague. Can you give an examples of a specific Google search which you feel yields more useful results due to these tags? Haukur (talk) 23:23, 10 June 2008 (UTC)[reply]

No, sorry, I can't—it did not occur to me to keep track of them!

Consider, however, the following. The {{Lang}} template does not use magic fairies to mark a passage as written in a certain language; the effect is achieved via the "lang" attribute of the (X)HTML <span> tag. Both the tag and the attribute are a part of the (X)HTML specification, which was devised so it could be used in practice. One can imagine that tags/attributes which do not have practical value did not make it into the specification, right? Granted, support for some such tags/attribute is still lacking in the real world, but it does not mean we should ignore them just because some editors are too lazy to learn about them. If we get rid of the {{lang}} template, perhaps next we should also do away with non-breaking spaces, tables, templates, or even the whole transclusion concept? Why not, they all are concepts which may be difficult for an average Joe Shmoe to grasp—certainly they alienate a good chunk of otherwise brilliant editors?

All in all, this discussion very much reminds me one regarding putting accent marks indicating stress in Russian words. Normally, such stress marks are only shown in dictionaries and in the texts targeting children and learners of the language. At the time (about 3-4 years ago), not only no search engine was capable of processing these stress marks, but they actually interfered with searches (a stressed word no longer showed up in the search results). Fortunately, common sense prevailed—just because the search engines were flawed at the moment did not lead to Wikipedians withholding this valuable piece of information. Now all major search engines are capable of processing accented Russian words—who knows, maybe in part because we actually started to use them on large scale? I don't see the language markup any differently—if it is implemented in Wikipedia on the scale large enough, it's only going to be a matter of time until the search engines start utilizing these metadata more actively. And like I said before—if anyone is not willing to add the lang template to the list of things to keep in mind when editing, then just ignore the damn thing! Those who do care will fix it for you.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 15:55, 11 June 2008 (UTC)[reply]

If we get rid of the {{lang}} template, perhaps next we should also do away with non-breaking spaces, Yes, now you're catching on. Non-breaking spaces are almost always unnecessary clutter, your signature is a good example. ,tables, templates, or even the whole transclusion concept? We should indeed avoid these things except in cases where there is great benefit in using them. Your condescending attitude to editors less well versed than you are in the niceties of code and web-standards is disappointing. Those people are not "lazy" "Joe Shmoes" - most intelligent people in the universe are not familiar with wiki-code and do not have any great incentive to learn it. We should keep it as simple as possible in order to make the wiki more attractive to a broader spectrum of people. People can be very intelligent and non-lazy and still be overwhelmed when they click the "edit this page" button and are confronted with a smörgåsbord of esoteric tables and templates. I agree with your point that early adaption of standards, even before widespread support, sometimes makes sense. I still don't see that a compelling case for {{lang}} has been made and I still would like to see an actual case - or at least a plausible made-up example - where it helps someone find something. Haukur (talk) 23:50, 11 June 2008 (UTC)[reply]

Yes, now you're catching on. Well, I see you have a larger problem than this template alone. Sorry, I can't help you—it is not my place to force my views on you, and we obviously disagree on a number of things.

most intelligent people in the universe are not familiar with wiki-code and do not have any great incentive to learn it. My point exactly. If those intelligent people (and, I suspect, a good portion of Joes Shmoes as well) are not willing to learn the intricacies of the wiki-code, by all means let them ignore them. If someone is capable of contributing high-quality information but is not willing to learn anything more complicated than linking, bolding, and italics, I, for one, is more than willing to do the grunt work of formatting for them. Content, not presentation, was the emphasis of Wikipedia from the early days, and it should stay that way.

I still would like to see an actual case... where it helps someone find something. I'll keep my eyes open. As for this particular discussion—how about we wrap it? I'd much rather spend my time providing comments where they would matter (in this case it would be TfD) rather than shouting things I deem to be patently obvious into the void. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 14:06, 12 June 2008 (UTC)[reply]

You aren't allowing people to ignore the wiki-code, they get it right in the face whenever they click the edit button. Haukur (talk) 17:54, 12 June 2008 (UTC)[reply]

I am sorry, but I don't find this argument very convincing. Wiki-code, no matter how complicated it gets, still allows seeing what the actual content is. It is also much more readable than, say, straight HTML. You, on the other hand, make it sound as if we are trying to make people decipher binary codes!—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:03, 12 June 2008 (UTC)[reply]

Go to, say, Belgium and click the edit button. Is what you get more readable than straight HTML? Only barely, in my opinion. If you go to a version of the article from 2002 you will find the code much more readable and easier to get into. Of course the current article is much more readable in read-mode but large sacrifices have been made when it comes to ease of editing. Haukur (talk) 20:24, 12 June 2008 (UTC)[reply]

Like I previously said, your comments show that your issue is far greater than with this single template. As for the Belgium article, I see no problem there whatsoever. The only thing the person who is not willing to learn all of the intricacies of the wiki-code needs to know is that curly brackets signify templates. This single piece of information enables pretty much anyone to edit the actual content without becoming confused.

In any case, are you not finding it ironic that a person with non-technical education (me) is trying to sell the benefits of new technologies to a person with technical education (you)?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 20:50, 12 June 2008 (UTC)[reply]

I wouldn't personally have any problem editing the Belgium article if I wanted to and it's not surprising to me that you don't find it problematic either. But it's not me or you I'm worried about - we've both been Wikipedians for years, we've long ago learned the basics and we've assimilated new stuff as it comes along. I'm sure you are generally a technically proficient person even if you don't have a technical education. I still think you're seriously underestimating how intimidating the templates and tables are to the uninitiated. If someone wants to edit the lede of Belgium they have to do quite a few page-downs before they even get to it, and then hopefully they won't get lost in the flurry of citation templates. There's a world of difference between this and the state of the article in 2002 - or even 2003 and 2004 when you and I signed up. You're right, of course, that this is a much larger issue than the lang template. But in my opinion that's just one more small well-intentioned step down the road towards ever more opaque code and it's hard to really see the problem with it until you step back and look at the larger picture. There's certainly ample opportunity to use the lang template in the Belgium article. Right at the top you can enclose Koninkrijk België and Eendracht maakt macht with it. Would that improve the article? It's hard to tell, isn't it? It may have some tiny advantage for some hypothetical searches, bot runs, statistics collection etc. and it has the tiny cost of making the article ever so slightly less accessible for editing. It can be hard to see that tiny cost which is why I suggest looking back at the accumulation over the years of all the costs of increased complexity. I'm personally fine with all this code. As you point out I write code for a living. I'm just concerned that we are making it ever harder for Wikipedia to get new editors. Haukur (talk) 23:58, 12 June 2008 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

While we await further installments of past discussions, may I ask a purely theoretical question, hoping upon hope that I'm not restarting the debate: would we be able to ask the developers to change the WP search engines so that “ and ” and " are treated as one and the same? almost-instinct 18:51, 8 June 2008 (UTC)[reply]

That is a good question. Waltham, The Duke of 22:25, 10 June 2008 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Fine; most of these pages vontain a lot of stuff that isn't community-approved guidance, or community-approved anything; downgrade my comment accordingly. MOSNUM may be the worst, but I wouldn't bet on it. Septentrionalis PMAnderson 23:11, 8 June 2008 (UTC)[reply]

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)[reply]

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

I like one or even two em-dashes. Otherwise the cell looks too empty. Strad (talk) 18:29, 8 June 2008 (UTC)[reply]

I would propose one em dash since it's "fuller" than the en dash. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 16:51, 9 June 2008 (UTC)

In any event, using two dashes, be them en or em dashes, is probably not an option. A single character ought to be used. Waltham, The Duke of 20:50, 9 June 2008 (UTC)[reply]

I agree with His Grace. And it's a matter of balancing the too small and the too large. To me, the en dash is just right: big enough to be unambiguous; not so big as to draw attention to itself, away from the substantive information in other squares. TONY (talk) 02:30, 10 June 2008 (UTC)[reply]

I also agree that only one should be used, rather than two. WP:HYPHEN states not to do --, so it would be odd to advocate –– or ——. Whether – or — is used, I don't mind. My only concern is consistency, and many lists use a dash to identify "N/A" information. Matthewedwards (talk · contribs · count · email) 02:40, 10 June 2008 (UTC)[reply]

I prefer em-dashes, but in the grand scheme of things I don't think it's that big of a deal. The important thing is that we're consistent. Drewcifer (talk) 09:51, 11 June 2008 (UTC)[reply]

Why? Why does it matter? We have dozens of ways of making tables; why does this one variation matter any more than the variation between all dashes and "N/A"? Septentrionalis PMAnderson 18:37, 11 June 2008 (UTC)[reply]

If you're going to ask that, you might as well ask "What's the point of the MOS at all?". There are many many different ways of doing anything, and the MOS is here to standardise it. There is already a section on WP:HYPHEN and WP:DASH which explain which and how they should be used in prose, this will just explain which and how they will be used in tables. Matthewedwards (talk • contribs • email) 18:59, 11 June 2008 (UTC)[reply]

What's the point of the MOS at all? To provide advice where useful, reasons for the various positions that literate English can take, and rules where there is project-wide consensus. Most of this page does not satisfy any of those criteria, but that's its fourth value: to show what a guideline page should not be. Septentrionalis PMAnderson 19:13, 11 June 2008 (UTC)[reply]

• Yes, Anderson, we all know your contrarian views on MOS. Thank you for restating them again in case we'd forgotten them. IMO, en dashes should be the standard; ems are just too large and unnecessary draw attention from the substantive information in the table. TONY (talk) 02:17, 12 June 2008 (UTC)[reply]
  • Yes, I have just stated three functions this page could have, which would be actually useful to the Wikipedian community at large. Would you care to explain at length why you disagree with them? Septentrionalis PMAnderson 02:52, 12 June 2008 (UTC)[reply]
    • I have too many things to do to get bogged down in another fruitless argument with you. TONY (talk) 03:36, 12 June 2008 (UTC)[reply]

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
3. Noel ('Josh') Hughes (what the index of the book I'm working from uses)
4. Josh Hughes (properly "Noel")
5. Noel Hughes (usually called Josh)
6. 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)[reply]

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)[reply]

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)[reply]

To clarify, my guess is that in the lead of Josh Hughes it would say Noel "Josh" Hughes, while within the article and all other articles Josh Hughes followed by Hughes would be more likely. It would depend on the context of the other article if you wished to expand his name to Noel "Josh" Hughes in the link. Oakwillow (talk) 19:09, 8 June 2008 (UTC)[reply]

I understand you. I don't think he's in any danger of getting his own page yet ... but it's good to have the groundrules made explicit, thank you. almost-instinct 15:45, 9 June 2008 (UTC)[reply]

Please see the proposal at Wikipedia talk:Article size to update the article size guidelines, in particular to use industry standard word count instead of character count. Oakwillow (talk) 18:31, 8 June 2008 (UTC)[reply]

Word count correlates to readable prose size, we already have Dr pda's prose size script that measures readable prose, so I see no need to reinvent the wheel. (And I'm not sure what's up with Oakwillow, since these proposals have garnered no support at size.) SandyGeorgia (Talk) 18:33, 8 June 2008 (UTC)[reply]

See discussion there. The wheel is broken, and non-standard. Oakwillow (talk) 18:53, 8 June 2008 (UTC)[reply]

Could someone update the units of measurements section to reflect the update of MOSNUM? I'd do it myself, but I don't have a lot of time for that this week. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 10:28, 9 June 2008 (UTC)

I'm unsure whether there should be a comma before "as well" in the following:

The election will coincide with the 2008 Senate elections in thirty-three states, House of Representatives elections in all states, and gubernatorial elections in eleven states, as well as various state referendums and local elections.

Theshibboleth (talk) 08:18, 10 June 2008 (UTC)[reply]

For me the comma makes it that little bit clearer. --Kotniski (talk) 08:53, 10 June 2008 (UTC)[reply]

Yeah, I think it is clearer. My understanding of grammar though is that since it isn't a clause it wouldn't take a comma. But I know the serial comma may complicate things. Theshibboleth (talk) 09:45, 10 June 2008 (UTC)[reply]

I've never heard of that rule. Use a comma if it makes things clearer is my view on the matter.--Kotniski (talk) 13:41, 10 June 2008 (UTC)[reply]

The comma is better. A comma is virtually mandatory in some locations, and should not be used in others; but there is wide scope for the use or non-use of what might be called "optional" commas. Optional commas are more likely to be used in formal registers (such as an encyclopedic one) and longer sentences. Here, it's a question of whether a comma is required as a boundary between the last and second-last items in a list. The list is sufficiently elaborate for a comma to be helpful, IMO. TONY (talk) 14:02, 10 June 2008 (UTC)[reply]

And the construction changes. Formally, the list ends with the gubernatorial elections, as the and shows; the as well as phrase is a parenthesis, which needs punctuation. We could change that, replacing as well as with and and taking out the other and, but that would change the emphasis of the sentence, probably not to its benefit. Septentrionalis PMAnderson 16:00, 10 June 2008 (UTC)[reply]

And there is also the more amateurish way to make a decision: do you pause before as well? I think most people would. Waltham, The Duke of 22:21, 10 June 2008 (UTC)[reply]

In English, commas are grammatical as well as phonological. TONY (talk) 02:18, 12 June 2008 (UTC)[reply]

And in this case, as usual, they are both. Septentrionalis PMAnderson 02:49, 12 June 2008 (UTC)[reply]

Certainly. I am only maintaining that if one is unaware of the specific grammatical rules, one could trust the phonetic aspect of commas in order to avoid a construct which would look awkward; this applies particularly on native speakers. Waltham, The Duke of 17:14, 12 June 2008 (UTC)[reply]

How much do you love the image on Geometric Tortoise? If you don't know what I'm talking about, stare at it for ten seconds. Does the MOS need to address this? Hesperian 06:03, 11 June 2008 (UTC)[reply]

No, unless somebody is going to claim it induces epilepsy. Having the two images separately might be preferable in a non-stub, but that would be crowded here. For a more substantive instance of shifting images, see Macedonia (terminology). Septentrionalis PMAnderson 18:41, 11 June 2008 (UTC)[reply]

Interesting way to deal with the lack of space. I have certainly seen worse strategies aiming at the inclusion of more images. Waltham, The Duke of 08:38, 12 June 2008 (UTC)[reply]

WP:MOSQUOTE recommends using <p>...</p> paragraph tags around each paragraph in a block quotation. An easier workaround is to nest a single div, then wikitext respects the line breaks correctly. So the example becomes:

<blockquote><div>
And bring us a lot of horilka, but not of that fancy kind with raisins, or with any other such things—bring us horilka of the purest kind, give us that demon drink that makes us merry, playful and wild!

—Nikolai Gogol, Taras Bulba
</div></blockquote>

Result:

And bring us a lot of horilka, but not of that fancy kind with raisins, or with any other such things—bring us horilka of the purest kind, give us that demon drink that makes us merry, playful and wild!

—Nikolai Gogol, Taras Bulba

 —Michael Z. 2008-06-12 04:33 z

WP:Captions doesn't get as much attention as some pages. This was just inserted in a new section last night: "Unless relevant to the subject, do not credit the image author or copyright holder in the article. It is not necessary to fulfill attribution requirements of the GFDL or Creative Commons licenses as long as the appropriate credit is on the image description page, and it implies ownership of free content, which contradicts Wikipedia policy." Thoughts?

Also, an editor wants to largely rewrite WP:PERFECT, and we haven't attracted any discussion there. Please see the talk page. - Dan Dank55 (talk)(mistakes) 12:28, 13 June 2008 (UTC)[reply]

The editor can try as much as they want; the page will never reach perfection. :-D

The captions addition looks reasonable. Waltham, The Duke of 23:40, 13 June 2008 (UTC)[reply]

Please can I have permission to write 'there is a 9 mm gap' and 'there is a 9 millimetre gap'. Currently the former is permitted but the latter is forbidden. Both are identical except that one is symbolic. Both are unambiguous. Lightmouse (talk) 12:34, 13 June 2008 (UTC)[reply]

In this respect, ISO has identical requirements with those of our MOS, I believe. How sage of them to take us as the standard. TONY (talk) 12:38, 13 June 2008 (UTC)[reply]

NIST's Special Publication 811 (page 16) takes the same position described by Tony1. They say it is because "the value of a quantity should be expressed in a way that is as independent of language as possible". On pages 17 and 18 the same guide says that "key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible" and that using symbols rather than spelled-out units promotes language independence. They go on to say

Occasionally, a value is used in a descriptive or literary manner and it is fitting to use the spelled-out name of the unit rather than its symbol. Thus, this Guide considers acceptable statements such as “the reading lamp was designed to take two 60-watt light bulbs,” or “the rocket journeyed uneventfully across 380 000 kilometers of space,” or “they bought a roll of 35-millimeter film for their camera.”

Even though the MOS suggests more extensive use of spelled-out units than NIST does, I think that a person with limited ability to read English is more apt to pay attention to the parts of an article that does uses symbols (such as tables), so when using symbols, we should follow NIST's lead and try to be as language-independent as possible.

I am not familiar with the customs of other languages as far as whether or not numerals used as adjectives are separated from the noun with a hyphen. Since I don't know any better, I will suppose NIST knows what they are talking about and that it does indeed vary from language to language. --Gerry Ashton (talk) 13:21, 13 June 2008 (UTC)[reply]

Indeed. Consider the following statements:

• "they bought a roll of 35 mm film for their camera"
• "they bought a roll of 35-mm film for their camera"
• "they bought a roll of 35-millimetre film for their camera"
• "they bought a roll of 35 millimetre film for their camera"
• "they bought a roll of 35-millimeter film for their camera"
• "they bought a roll of 35 millimeter film for their camera"
• as above but with thirty five, thirty-five, thirty-five-mm, thirty-five-millimetre, thirty-five-millimeter

The first one is language independent and compliant with international standards. So I that is a *good thing* and the international nature of Wikipedia would imply that it should be more positive about such a version than regionally biased publications. All are unambiguous in English. I like the fact that I am permitted to write 'of 35 mm film' but I do not like the fact that if the unambiguous '35 mm' is expanded to the unambiguous '35 millimeter', it is forbidden without a hyphen. Lightmouse (talk) 13:58, 13 June 2008 (UTC)[reply]

Your example might be the most unambiguous of the lot; there are many cases much more confusing. Compare, for example:

• "The fountain was lit for one hour."
• "The fountain was lit for one-hour periods."

The sentence must make sense as a person reads it; omitting the hyphen from the second sentence will cause a person to read it as the first, only realising their mistake (or, rather, the writer's) when reaching periods. I'd give you a better example—preferably one with millimetres—but I am not inspired enough at the moment. You get the point, though. Waltham, The Duke of 00:28, 14 June 2008 (UTC)[reply]

His Grace is right: good writing eliminates the need for readers to reverse-disambiguate, even if it would take only a fraction of a second. Here, the preceding "a" does make it clear, but try the plural: "9 millimetre gaps [should be avoided]". Not nine gaps of a millimetre each, so "9-millimetre gaps [should be avoided]". Easiest for readers, then, if it's consistently applied whether or not there's preceding deictic ("a", "the", "these"). The appearance of a symbol rather than a name for the units is enough to signal that single millimetre gaps are not intended: you can't refer to mm (meaning "a single millimetre") using a symbol. TONY (talk) 04:01, 14 June 2008 (UTC)[reply]

I take the point about mm adding a useful layer of context.
On the point about amibiguity, I agree that it is possible for ambiguous phrases to exist. That is my entire point. The hyphen is a very useful tool to disambiguate values. I will argue strongly for them in values with ambiguity, and against them in values where there is no ambiguity. Many editors use hyphens for disambiguation and not otherwise, yet this mandatory rule for mandatory use of hyphens in all cases turns such writing into a crime without a victim. Quotes about hyphens include "If you take the hyphen seriously, you will surely go mad" and Churchill's "One must regard the hyphen as a blemish to be avoided as far as possible". Please think carefully about what I am suggesting: I am lobbying for an end to the mandatory use of hyphens where values and units are unambiguous. If you interpret that as lobbying for a ban on hyphens, then you misunderstand my point. Lightmouse (talk) 10:22, 14 June 2008 (UTC)[reply]

To quote the English major sitting next to me: "Why do we care"? Language independence is a spurious issue; we are in English. Accessibility in multiple languages. which is what MIT means, is handled by having multiple Wikipedias. On hyphenation, we should follow usage, which has always been less hyphenated in American; therefore this is an ENGVAR issue. Delaying the reader by an unexpected huphen is as bad as causing him to hesitate over the absence of an expected one. Septentrionalis PMAnderson 22:44, 15 June 2008 (UTC)[reply]

"Many editors use hyphens for disambiguation and not otherwise, yet this mandatory rule for mandatory use of hyphens in all cases turns such writing into a crime without a victim." No, Anderson: you're the victim. TONY (talk) 03:39, 16 June 2008 (UTC)[reply]

Lightmouse and I have been discussing this issue elsewhere. As I noted there, I've always taken the hyphenation of adjective phrases to be standard grammar. I feel it would be simpler to just follow that rule than to have to judge whether the hyphen is needed for disambiguation. Allow unhyphenated adjectives when they aren't needed for disambiguation and you're likely to find the same when they are needed, simply through editors' mistakenly following the examples they see.

As for its being an ENGVAR issue, less hyphenation in general in some dialect group does not equal less hyphenation of adjectives in that dialect group. The argument is making a slight logical jump.

Regarding language independance; if others use this argument to base their standards on, good for them; but I agree with Anderson, this is the English WP. That said though, hyphens still should not be used with abbreviations/symbols, since it's just not done that way in English (whatever the reason be).

JIMp _talk·cont 04:39, 16 June 2008 (UTC)[reply]

I have no statistics but my belief is that ambiguous unit values are rare. I cannot think of a single instance where I have come across a need to disambiguate a unit value with a hyphen. There are cases where I use hyphens as part of grammar but this is not one of them. I frequently read adjectival unit values freely written on Wikipedia and elsewhere that do not have hyphens. It makes no difference to the readability and unlike many grammar issues, it does not look odd. I would not be making such a fuss if it were not hard-coded into the widely used convert template. It is not opt-in, it is not opt-out, it is enforced. Anyway, it seems that I am the only one speaking out against this and I hate to disagree with some of the respected editors here. I have stated my opinion and I have not convinced you. Lightmouse (talk) 19:12, 16 June 2008 (UTC)[reply]

I have been informed that the article Edmonton municipal election, 1963 contains a quote. Now that I know it is a quote, I can see it. However, I have mistaken it more than once for ordinary text and converted a unit in the text. This has unintentionally annoyed the most frequent editor (User:Sarcasticidealist). I think that there is something unusual about unflagged quotes. There must be some way in which that article can flag quote text to the uninitiated user. Can anyone suggest what needs to be done? Lightmouse (talk) 11:05, 15 June 2008 (UTC)[reply]

If it's a direct quote, the editors inserting it should make that clear. Personally, I either use regular double-quotes "like this," or the {{cquote}} tag (though that tag can get distracting for large numbers of quotes). — The Hand That Feeds You:^Bite 12:03, 15 June 2008 (UTC)[reply]

I hope you don't do it like that: MOS clearly states that the comma needs to be after the closing quotation, no matter how Anderson would like it to be. TONY (talk) 03:34, 16 June 2008 (UTC)[reply]

The tag would make it easier for a bot to avoid. I am in the bad books of the principle editor, having failed to see the unflagged quote on three occasions. Can you take a look at the article? Lightmouse (talk) 12:34, 15 June 2008 (UTC)[reply]

Yeah, I took a look. I can see why the editor doesn't want the quoted material converted. And quoting could interfere with the flow of the article (most of the text outside the tables would be quotes). However, as you point out, it causes confusion for other editors, who don't realize it's direct quotes.

I suggest bringing this up on the article's talk page for discussion. See if Sarcasticidealist would be willing to place quotes himself, or allow you to place quotes. My personal suggestion would be to quote the actual ballot questions themselves, individually, and leave the result numbers unquoted. — The Hand That Feeds You:^Bite 12:59, 15 June 2008 (UTC)[reply]

We should not write for the convenience of bots. !!!!— Preceding unsigned comment added by Pmanderson (talk • contribs) 22:59, June 15, 2008 (UTC)

Has anyone ever created a bot that successfully avoids quotes? That would be quite suprising, considering the may ways quote marks are used. --Gerry Ashton (talk) 17:13, 15 June 2008 (UTC)[reply]

A bot could avoid an entire page containing the string 'quote'. If the option exists, some bot tasks would make use of it. Lightmouse (talk) 21:52, 15 June 2008 (UTC)[reply]

Edmonton municipal election, 1963 doesn't contain it. A comment could be added, but that's a one-time solution. Septentrionalis PMAnderson 22:59, 15 June 2008 (UTC)[reply]

An article might not contain the <blockquote> tag, it might only have quotation marks. These are tough for a bot to keep track of, since they are also used for other purposes, such as a symbol for arcseconds. --Gerry Ashton (talk) 05:03, 16 June 2008 (UTC)[reply]

This is why commenting on the talk page is a good idea. Bots can do that; they can even be programmed to avoid doing a page twice. Septentrionalis PMAnderson 22:56, 15 June 2008 (UTC)[reply]

What is wrong with double quotes around the referendum texts? TONY (talk) 03:37, 16 June 2008 (UTC)[reply]

Double quotes would be fine too. I don't care how it is done. Something needs to be done to that article. Lightmouse (talk) 04:46, 16 June 2008 (UTC)[reply]

I have no problem with one time solutions; the one I would propose here is an "avoided articles" list for the bot, such that after one (reported) false positive, the bot is told to avoid that page. I have no problem with occasional false positives, since these are the price you pay for having bots, and I think the price is well worth it. My concern in this case was that this was a four-time false positive, and I was beginning to become irritated (though you're not in my "bad books", Lightmouse, and I'm sorry if my message was too harsh). If you could just add the article to an avoid list for your bot, and agree to do the same with any future false positives reported to you, I'd be quite satisfied. Failing that, I don't object to having quotes put in the article, but, as I'm no MOS-guru, I'll leave it to somebody else to determine the appropriate way of doing so. Sarcasticidealist (talk) 04:52, 16 June 2008 (UTC)[reply]

I'm no kind of guru either but I've had a go at the article. I put the excerpts in blockquotes, hope that this sorts things out nicely for all concerned. With respect to conversions to metric, perhaps some could be provided as footnotes. JIMp _talk·cont 05:04, 16 June 2008 (UTC)[reply]

Your work looks good to me (including the footnote). Sarcasticidealist (talk) 06:25, 16 June 2008 (UTC)[reply]

I've gone ahead and added the footnote. JIMp _talk·cont 07:30, 16 June 2008 (UTC)[reply]

Thanks. That should make it easier to avoid in future. I hope!

I do go to great lengths to avoid false positives. By their nature, false positives are visible and frustrating to the victims. They damage the reputation of the bot.

PS to Sarcasticidealist, your message was not harsh, in fact I think you have been very reasonable. I hope we have got a good solution. Thanks. Lightmouse (talk) 19:26, 16 June 2008 (UTC)[reply]

The "section management" subsection says: "The standard order for optional appendix sections at the end of an article is See also, Notes (or Footnotes), References, Further reading (or Bibliography), and External links; the order of Notes and References can be reversed."? Does anyone know why footnotes are not at the foot? Butwhatdoiknow (talk) 19:01, 16 June 2008 (UTC)[reply]

Sure they are References, Further reading (or Bibliography) and External links are under-foot. Why's a hot dog not a dog? ... But seriously, though, it's because the notes are meant to be more closely tied to the text, they are more or less an addition to the text so should go with the text. JIMp _talk·cont 19:11, 16 June 2008 (UTC)[reply]