Wikipedia talk:Manual of Style/Archive 107

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 100 ← Archive 105 Archive 106 Archive 107 Archive 108 Archive 109 Archive 110

What is WP:MOS?

WP:MOS|WP:STYLE Despite the presence of the above box [archiver's note: I provided a link to the template instead of the template itself, so that this page doesn't get added to the cat - Dan Dank55 (push to talk)] at the very top of WP:MOS, several editors here have recently indicated a belief that MOS should be prescriptive, and thereby demonstrated a lack of understanding that it is a "guideline", the meaning of which is laid out in WP:POL. Please take a moment to review at least the nutshell. LeadSongDog (talk) 02:19, 15 November 2008 (UTC)

This, indeed, deserves wider discussion. Septentrionalis PMAnderson 02:56, 15 November 2008 (UTC)
Can you clarify what you're question is, because I'm not sure I'm getting what the problem is? The box repeats what is stated at POL for a guideline? -- AnmaFinotera (talk · contribs) 03:02, 15 November 2008 (UTC)
Certain editors regard anything less than than a command: Do this, Don't do that, as rendering MOS useless; see, for example, #Hyphens after -ly adverbs (rationalised section), above, where there are several objection to a proposal to change "a hyphen is not used" in certain circumstances, to "a hyphen is not normally used", on the grounds that to insert normally or generally weakens MOS to a nullity. (I hold that in the instant case, the claim is false without such qualification, but that should be discussed there.)
The question here is: Is this absolute language, in a guideline, which will have occasional exceptions and special cases, either helpful or appropriate? Some of us would prefer to describe what English does (often not always or never, and the cases where it is generally have not gotten into MOS, because we don't need to decide them). Septentrionalis PMAnderson 03:23, 15 November 2008 (UTC)
If we wanted to be genuinely descriptive, we would be neutrally describing all the errors that English speakers habitually make. We wouldn't be describing forms as "correct" or "incorrect" ([1],[2],[3],[4],etc), we wouldn't have at the top of the page "Editors should follow [this guideline]", and we wouldn't use a word like 'should' over a hundred times throughout the article.
You don't actually want the MoS to be descriptive, and you're confusing your case by suggesting that you do. What you want is for it to prescribe a range of possible styles, all approved by yourself, without expressing any strong preference. That's still prescription, it's just a much blander form. Until you understand what you're advocating, nobody's going to be able to convince you that it's a bad idea. Ilkali (talk) 03:44, 15 November 2008 (UTC)
I congratulate you on acquiring telepathy, but it seems to be wonky. I do indeed want MOS to be descriptive; that would in itself do most of the work of guidance we need. (We do not, of course, need to describe, still less to prescribe, all of English - including those actually occurring usages which are vulgar errors; that would require volumes, which already exist and are available elsewhere.) What would be useful is to describe what good writers actually do, and, as we do not, on what grounds they actually do it. That might even be persuasive, and obviate the bullying, bot usage, and name-calling. This would involve treating our fellow editors as adults, with minds to be persuaded; is that the obstacle?
I have no objection to the behavioural prescriptions, such as ENGVAR; they may indeed be the only really useful part of MOS.
Postulating what the other side are "really" saying has "all the advantages of theft over honest toil", to quote Bertrand Russell. When you get tired of arguing with straw men, do let us know. Septentrionalis PMAnderson 03:59, 15 November 2008 (UTC)
"I do indeed want MOS to be descriptive; that would in itself do most of the work of guidance we need. (We do not, of course, need to describe, still less to prescribe, all of English". As soon as you choose what to describe, you fall into prescription. You're trying to handwave that away by saying "no, we're just describing the language used by people we want our editors to copy". Can't that be said about virtually any prescription? Again, this isn't a matter of description vs prescription, it's a matter of how broad our prescriptions should be. Ilkali (talk) 13:15, 15 November 2008 (UTC)
As soon as you choose what to describe, you fall into prescription. Does anybody else believe this? Must we transcribe all of Jesperson (and he does not describe everything), or fall into prescription? (To say nothing of the fact that we are choosing to describe English, as opposed to French, or to chess.) This is another purely verbal argument, by a sophist, who, like Humpty Dumpty, makes words mean whatever he pleases. Septentrionalis PMAnderson 16:35, 15 November 2008 (UTC)
This is a meaningless question. For a guideline to guide, it must prescribe some options while advising against others. There is no way a manual of style could be anything but prescriptive. Ilkali (talk) 03:04, 15 November 2008 (UTC)

[Here is my own considered opinion of the role of MOS, and of the continuing attack on MOS. Please comment after, not within my post.–N]

Just as it is easy to support practically anything from a judiciously chosen Google search, it is possible to lend all manner of absurdities a veneer of credibility with a well-chosen quotation from Bertrand Russell. The one I would bring to the table is this:

It is a waste of energy to be angry with a man who behaves badly, just as it is to be angry with a car that won't go. (Collected papers of Bertrand Russell, volume 10, Routledge)

But now that I consider more closely, this one fits pretty well: Anderson both behaves badly and, usurping the prerogative of the car, won't go. For this reason we are perhaps doubly wise not to be angry. Rather, Anderson, we should view your campaign against MOS with stoic equanimity, and meet it as we might some mere natural calamity. Truly, that is why I retired from my engagement with MOS some months ago. Until now. Your persistent jackal-like despoiling of others' good work has drawn me back, at least for a short while.
I suppose we ought to feel relieved: The Chicago Manual of Style (CMOS) earns from you as little consideration as our MOS does. Is CMOS truly "a hasty piece of shorthand for writers and editors in a hurry", in your words recorded above? An odd judgement, concerning the major style guide for the publishing industry – all 984 pages of its fifteenth edition. Hasty? Shorthand? Come now. Even I don't say that, and I am one of its stern critics.
There is a general uncertainty and unease about prescriptiveness. But let me remind editors: to prescribe is not to command; to advise is not to browbeat; to guide is not to goad. As Ilkali and I have pointed out (as if it needed it!), style guides by their nature prescribe standards and touchstones in support of consistent high quality. They offer remedies for the difficulties writers and editors encounter. Worthwhile style guides anticipate a good proportion of the most thorny and most probable problems, though none can predict every conceivable eventuality. Any attempt to do this would end up not as guidance but as an offer to take over the task of composition itself.
Wikipedia's own MOS is a style guide, and unlike such farraginous compendia as Fowler's, it must aim to prescribe real solutions to the problems likely to be encountered in making and improving Wikipedia articles. Sometimes it can do this well by description of accepted practice elsewhere; but to insist that is all it can do is to be a fanatic. No style guide merely describes! And let's be clear about this: style guides, in prescribing for good style, do not always have to use the imperative mood ("Do this, and not that"). Nor do they have to employ modals of obligation ("You must capitalise a proper noun"). No, they commonly use ordinary indicative sentences ("In British usage a colon is not often followed by a full stop").
WP:MOS should be a rationally organised suite of guidelines that genuinely guide: not detailed to the point of mind-numbing prolixity, and not broad to the point of vacuity. Its language should be simple, confident, and unambiguous. It should make sound and useful recommendations based on the deliberations of committed, interested, knowledgeable editors, and thereby earn the broader Wikipedia community's respect. Exactly how obligatory the community wants to make those recommendations is not our concern here. We should simply make the best guidelines we can. We should not work to sabotage that endeavour, through a misguided and fanatical confusion of roles.
–⊥¡ɐɔıʇǝoNoetica!T– 06:06, 15 November 2008 (UTC)
From the above, I take it that Noetica interprets "prescribe" here by using one of its softer meanings. It has quite a range, and therein lies some of the discomfort. From my old Funk & Wagnall's:

prescribe v. 1.To set down as a direction or rule to be followed; ordain; enjoin. 2.Med. To order the use of (a medicine, treatment, etc.). 3.Law To render invalid by lapse of time. v.i. 4. To lay down laws or rules; give direction. 5.Med. To order a remedy; give prescriptions. 6.Law a To assert a title to something on the basis of prescription: with for or to. b To become invalid or unenforceable by lapse of time.

So there are several possible meanings, which makes for confusion when the term is used. LeadSongDog (talk) 08:45, 15 November 2008 (UTC)
  • Insofar as the MoS should be descriptive, it should be in that it forms a corpus of good practice taken from the prescriptions of authorities in the field. In this way, it documents what others have prescribed. We then go one step further and say "therefore, one should do X as this is what the authorities do". This is perfectly sensible as it allows editors the authority to unify the styling of different articles. Without any hint of prescription, every article is its own little fiefdom where local rules apply. I disagree strongly with this happening. Chris Cunningham (not at work) - talk 13:06, 15 November 2008 (UTC)
You (and PManderson) are concocting some weird ad-hoc meaning when prescription is already a well-defined term within linguistics. Ilkali (talk) 13:15, 15 November 2008 (UTC)
Yes, and LeadSongDog, please spare us the medical and legal definitions. Indeed, more than they are irrelevant in that comprehensive definition; fact is, "prescribe" has a range of meanings, and "enjoin" is one of them, as you point out. My Encarta Dictionary says of that word: "urge, encourage, admonish, press; instruct". But Anderson would have us dilute our style guide into nothingness—in the spirit of the political hard-right, he just can't abide centralised advice or direction for the good of a community (unless he quite likes it WRT a particular point). Tony (talk) 14:11, 15 November 2008 (UTC)
In my experience, orders, demands, and a system which all must follow, without exceptions, and independently of the evidence, are precisely characteristic of the hard right. Australian politics may differ. Septentrionalis PMAnderson 16:25, 15 November 2008 (UTC)
To clarify, Tony, I am not advocating the use of any one of those definitions (I simply quoted the entry entire), but rather pointing out that there is such a significant range of meanings as to effectively render the term useless for the purpose of this discussion. The link Ilkali kindly provided to Linguistic prescription was interesting. That article could benefit from some TLC to improve its inline citations and I have so tagged it, but it was still informative. Even so, we are not exactly talking about linguistics here, but about the WP House style guideline.LeadSongDog (talk) 19:23, 15 November 2008 (UTC)
Could somebody rewrite this question so that it actually asks the reader to do more than "review a nutshell". I've reviewed the nutshell, but since no actual comment is requested in this request for comment, I don't see anything else to do. Tim Vickers (talk) 17:50, 25 November 2008 (UTC)

Prescriptive, though somewhat less strict than a WP policy. --Goodmorningworld (talk) 21:16, 2 December 2008 (UTC)

Rather than continuing to use the word "descriptive," which might suggest neutrality toward the useage being described, or to use "prescriptive," which might suggest that there is only one "correct" usage, I would suggest the more useful, enlightened, less-judgmental, and commonly used terms: "conventional" and "unconventional." To describe a particular usage as "conventional" means that it is something less than foundationally and inherently and essentially "correct" but certainly more than completely arbitrary and open to casual revision. Generally, no one is harmed too much by unconventional choices in language usage; however, the person employing unconventional usage risks have his or her choice regarded as, well, unconventional. To be "conventional," use a common style guide, which is to say do what most people do; to be "unconventional," do something else and accept that your usage will be viewed for what it is: unconventional. That's all. Style guides will, of course, vary in small ways simply because there are few absolutes in something as dynamic and maleable and contingent as everyday language use. This change in terms won't stop people from arguing for or against a particular useage, but it might change the tone. You're arguing the changing conventions of language and not the immutable absolutes of math.

Jthepp (talk) 20:44, 5 December 2008 (UTC)

  • Anderson, I don't have to acquire telepathy to know that you thirst to dilute any centralised authority as far as style goes, except when it comes to points you happen to agree with. Tony (talk) 13:55, 14 December 2008 (UTC)
    • Thus happens to be wrong about my politics; more seriously, it is wrong about this page, which has no authority. The consensus of Wikipedians would have some authority, but this page does not reflect it; the testimony of reliable sources on English would have some, but this page does not cite them. Tony should really read the comments on this point, far below; I do not expect him to contemplate on why his will to power leads him to profanity and abuse. Septentrionalis PMAnderson 16:12, 14 December 2008 (UTC)

The MOS should be, in almost all situations, descriptive and not prescriptive. There will almost always be circumstances and situations where the MoS should not be applicable and should be safely ignored. It should also never be used in an automated fashion, especially when there's significant objection to portions of it. —Locke Cole • t • c 09:05, 15 December 2008 (UTC)

It's the wrong question, because it assumes a binary either/or frame. No guide or authority can hope to be anything but both prescriptive and descriptive. Tony (talk) 09:26, 15 December 2008 (UTC)
Yes, but by being prescriptive people accidentally assume these various MoS pages have some authority (which overall they do not) over common sense or an individual editors taste (or even a small collection of editors). Consistency is valuable, but not to the extent that a small number of editors (those willing to subject themselves to daily turmoil at the various MoS talkpages) manage to influence it. It would be far better if MoS weren't authoritarian in tone. —Locke Cole • t • c 05:08, 16 December 2008 (UTC)
Please add the apostrophe to "editors". Tony (talk) 05:33, 16 December 2008 (UTC)

Discussion about transcluded text

Here is the content of the section "First sentences":

== First sentences ==<!-- To edit this text go back to the article and click on the edit button for the "First sentence content" or "First sentence format" sub-section. For more about transclude text go to [[WP:Transclude text]] --> {{:Wikipedia:Lead section TT first sentence content|show=1}}{{:Wikipedia:Lead section TT first sentence format}}

This is how it now reads, after my extensive trial-and-error modifications, which ended with simply including "|show=1" in the first transclusion template. Why this should require it, and the second template fail when it is included, is one of life's mysteries.

I am not happy with my time being taken up like this: investigating the transclusion files themselves, finding how they were linked at articles where they did in fact work, fixing the incompatible and very poor text, formatting, and markup at the transclusion files themselves, and checking and rechecking MOS to see that it all fitted together.

If we must have such transclusions, I suggest that the instigators themselves check and recheck, instead of imposing an unfair burden on others because of their failure to do so. If this method must be used, let it be used uniformly and well. I can imagine that most of MOS and other articles could eventually consist of transcluded text; but it should be strenuously resisted if the technology is managed this badly.

–⊥¡ɐɔıʇǝoNoetica!T– 22:50, 15 December 2008 (UTC)

I believe I fall into the category of "instigator." You raise a number of issues and, I suggest, it would be best to take them one at a time. I propose to start with the question of whether transclusion (assuming it is "used uniformly and well" - another issue that can be discussed separately) is an experiment that should continue. With that issue in mind: Do you think that, in theory, transclusion is a meritorious solution the problem of conflicting style pages? If not, is there any solution you would propose instead? (Or, in this case, is the cure worse than the disease?) Butwhatdoiknow (talk) 23:07, 15 December 2008 (UTC)
Thanks for your rapid and thoughtful response, B. I appreciate that you had the best intentions in setting up these transclusions. It is interesting that the anomalous text they introduced was not corrected till I got to it; and it was damn hard to fix it, I can assure you! (Might look easier in hindsight.) To your first question: No, we are not ready for transclusion at MOS. It could eventually work well, as I suggest; but consistency of style is relevant in two ways:
  1. Consistent style recommendations, within and across MOS-pages. Transclusion would be great for that; but we are not ready. There is not enough expertise among MOS-editors to manage the transclusions; and we have no good way of coordinating dialogue and consensual decision-making between pages. Hell, it's hard enough even within a single MOS-page! Take WP:MOSNUM for example. Locked down, for good reasons.
  2. Consistent style in presenting the guidelines. We need a consistent style for setting out our guidelines. We have nothing like it, at present – even within a single MOS-page. I have held off from an all-out assault on this problem myself, for WP:MOS. It's too big, and again we'd need proper consultation, firmly established goodwill, and a common purpose. These are overarching issues to address first, and they are not addressed. Given that situation here at WT:MOS, we can see how much greater are the procedural problems for the whole ensemble of MOS-pages.
To your other questions: No, right now transclusion only makes a complex nest of problems less manageable. I'd undo it, until we're ready. What do I propose instead? I propose first addressing the overarching problems mentioned just now. They will rear their brutish heads again and again, if we don't act. In the end there is no escaping them, daunting though they appear. Meanwhile, the band-aid solution is worse than the disease that it masks.
–⊥¡ɐɔıʇǝoNoetica!T– 23:41, 15 December 2008 (UTC)
I'm a little slow on the uptake today. What are the "overarching problems" that we need to address? Butwhatdoiknow (talk) 23:54, 15 December 2008 (UTC)
These that I specified explicitly: "...we'd need proper consultation, firmly established goodwill, and a common purpose. These are overarching issues to address first, and they are not addressed."
See also Respect for MOS and its editors, above. No durable progress is possible with details until we are clear about the big picture.
–⊥¡ɐɔıʇǝoNoetica!T– 00:17, 16 December 2008 (UTC)
Those are certainly worthy issues to deal with and I hope that you and the other "big picture" thinkers can achieve them seasonably. Meanwhile, I suggest a better analogy to describe the transclude text solution is a pothole filler rather than a Band-Aid. People are consulting the style guides now and should be given non-conflicting guidance when they do so. Later we may completely resurface the road but, in the meantime, folks need to drive on it. So I respectfully disagree with you to the extent that you are saying that no solution to the conflict problem is better than a pothole fills (or, if you will, Band-Aids) pending progress on resolving the overarching problems. Accordingly, I'd like to keep this discussion focused on whether transclude text is the best pothole filler. Butwhatdoiknow (talk) 14:38, 16 December 2008 (UTC)
With respect, B: I am the editor who, not only concerned with the big picture but also working on the factory floor, in fact stepped in and diagnosed the problems with these transclusions. Those problems were serious and various, and it took considerable time.
Is transcluded text the best "pothole filler" (surely a useful analogy)? I am not convinced, from my direct experience. As far as I can determine, no one else has had such experience with fixing these transclusions, here at MOS. And there's another problem: we can't review changes, or see who's doing what, without trawling through records for the sources of the transcluded text. For example, people cannot readily review the changes I have recently made, or conveniently compare in one place my work on the two sections involved.
Even if things are just manageable now, they certainly would not be with expanded use of transcluded text. Not without radical innovations in our protocols. I'm therefore against transcluded text for now. Discuss it, experiment with it, but don't do it here until we have developed a workable system. We have enough chaos to contend with already.
Reluctantly, I now propose integrating the existing transcluded text as a normal part of MOS, for further improvement and transparent editing.
–⊥¡ɐɔıʇǝoNoetica!T– 22:06, 16 December 2008 (UTC)

Using color and typeface to set off example text on MOS and MOSNUM

Here on WT:MOSNUM (scroll down), Noetica and I have been discussing a better way to show example text.

By using a distinctive color and typeface in example text, we are liberated with very easy-to-distinguish example text that is no longer encumbered with italicizing and quote-mark problems. For instance, if we show example text in italics, Like this text, we are breaking our own guidelines and the rule of the SI when we write that a non-breaking space should separate the number and the unit symbol, like “15 kg” because the unit symbol is italicized. Further, when we write This  example text, wherein we say that variables are italic, like “T = 60 K”, we can’t “see” the variable and the unit symbol is screwed up too. Using quotes introduces its own set of issues when we are talking about the use of quote marks. So…

Noetica and I propose the use of both color and typeface to set off example text. Color, by itself, introduces the potential for violating accessibility guidelines on Wikipedia. Color alone is not supposed to convey important information. But…

I know a bit about color blindness. I worked with a color-blind engineer on fuel cells. One of his jobs was to look up at ceiling-mounted hydrogen sensors when they tripped a facility-wide hydrogen-safety system I had designed. There were a bunch of these sensors on the ceiling of the big, main testing room (as well as everywhere else in the building). For practical considerations, some of the sensors had to share a single channel on the control box. The sensors had a multi-color LED that went from green to red if it was the one that sensed the hydrogen. Like most color-blind individuals, this engineer had red/green blindness—most inconvenient. He had to ask for someone else’s assistance to look up and squint at LEDs twenty feet up. Once you knew which sensor went off, you knew which engineer’s experiment was leaky. (Don’t get me started about putting hydrogen-fueled, fuel cell-powered cars in the hands of the public.)

Anyway, my point is that setting aside a metric butt-load of political correctness (because a small, small percentage see no color whatsoever), and embrace a little bit of common sense, setting off example text in maroon (or some tweak of maroon that won’t be confused with red, and certainly not relying upon the use of both red and green to mean two, distinct things), should be fine. And when color is then combined with typeface, we have some nice-looking text with zero accessibility issues.

Let’s look at some example text…

I am refering to some example text containing quotes as exactly written on WT:MOSNUM by Army1987: for example, "2 m" means two metres, and "2m" usually means twice the mass."?

In this example there are no “quote mark” issues and it is also clear what text ‘owns’ the question mark at the end.

And then this example (which is currently on MOSNUM with italicized example text that sweeps up unit symbols with the italicizing):

  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

…Or this complex text:

Greg L wrote on WT:MOSNUM as follows: Unless there is a good typographical or communication-based reason otherwise, in numeric equivalencies, the unit symbol shall be in roman (non-italic) text. A non-breaking space “&nbsp;” almost always separates the value and the unit symbol (e.g., 2.4 GHz, 325 km, 25 °C). Exceptions are the degree, minute, and second for plane angle, °, ′, and ″, (e.g., 47° 38′ 8.8″), and the percent (%) symbol. Variables are always italicized, (e.g., T = 298 K, e = mc2).

This is coded as follows:

<font color=maroon face="times new roman" normal style="font-size: 107%;">Example text shown in the resultant font.</font>

The above could even be simplified with a template so {{hilight|Sample text here shown in resultant font}} could make the markup more convenient. However, we wouldn’t have to wait for such a template, since this markup would be limited primarily at first to MOS and MOSNUM.
Greg L (talk) 23:57, 10 December 2008 (UTC)

I have long thought this sort of thing necessary, and I endorse all that Greg says.
I commend the proposal to MOS editors; I hope we can quickly and harmoniously get discussion on this, closely followed by action. We do need a template, of course: there are so many examples at our MOS-pages that coding would be awfully cumbersome using the present raw resources. But a template should be easy to set up, in this case.
–⊥¡ɐɔıʇǝoNoetica!T– 02:56, 11 December 2008 (UTC)
I had thought about white background, but also changing the foreground color is even more visible. (I'd use a <span style="..."> rather than <font>, and serif rather than "times new roman", but I agree about the idea.
This is an example.
Maybe someone could also add style_example {color: maroon; background: white; font-family: serif;} to common.css, so that we'd just need <span class="style_example"> for each instance. -- Army1987 – Deeds, not words. 12:30, 11 December 2008 (UTC)
  • Army: Can the span tag be modified to also enlarge the text to 107%? On Safari and Firefox at least, the example text looks abruptly smaller. Let’s take the following example using span tags with no size adjustment:
  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).
To me, the results look awkward unless it is the same size by boosting Times New Roman 7%—like this…
  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).
Greg L (talk) 05:40, 12 December 2008 (UTC)
Huh? Yes. Like this? (Epiphany does the right thing, showing this at the right size and this a bit larger, but more people are using Firefox than Epiphany, and, in any event, too large is less awkward than too small.) -- Army1987 – Deeds, not words. 15:54, 12 December 2008 (UTC)

I don't have a position. If people start adding color and special fonts to pages in the General style guidelines, then I'll reflect that style at WP:Update. - Dan Dank55 (send/receive) 17:37, 12 December 2008 (UTC)

  • Yes, like that Army1987. Coding <span style="color: maroon; background: white; font-family: serif; font-size:107%">Produces this example text shown here its rendered, clear-as-glass glory.</span> Wundervoll. Please explain in plain-speak: what are the benefits of <span> v.s. <font>? After all, this: <font color=maroon face="times new roman" normal style="font-size: 107%;">Example text produced with “<font>-based” HTML code</font>, looks the same. I had suggested that the <font>-based method could be implemented via a template like {{hilight|Sample text here showing product of template}}. Does a span-based technique similarly make things as (or more) convenient? Greg L (talk) 21:42, 12 December 2008 (UTC)
    • Font tags are not valid HTML and haven't been since about 1972. Use the span version. Kaldari (talk) 22:00, 12 December 2008 (UTC)
      (2nd e.c. in a row) They are valid in HTML 3.2 and earlier, as well as in the "Transitional" flavor of HTML 4.0 and XHTML 1.0 (Wikipedia uses XHTML 1.0 Transitional), although it is deprecated in the latter ones, because of the separation of style and content. (Transitional means more-or-less "in which deprecated elements haven't been removed" in this context.) But, on more practical grounds, the style could actually be separated, by adding style_example { color: maroon; background: white; font-family: serif; font-size:107% } to MediaWiki:common.css, and <span class="style_example"> around text to be marked. (Of course, if a template is used, this issue is less relevant.)
      Also, I won't be very comfortable in using the proper name of a proprietary font; using serif causes whatever serif font the reader chooses in his/her browser preferences to be used. (Most browsers are smart enough to choose a serif font as a replacement for Times New Roman when it's unavailabe, but we should avoid depending on that, given that we can.) -- Army1987 – Deeds, not words. 22:14, 12 December 2008 (UTC)
  • Question - Why would we need to change the font and the color? Wouldn't using one or the other suffice? Are there really that many people who are red/black color blind? Kaldari (talk) 22:04, 12 December 2008 (UTC)
    • Accord to our article on color blindness, only 0.00001% of males and 0.00001% of females would be unable to distinguish red from black, so I think the accessibility issue is moot. Why don't we just go forward with using color and dispense with the typeface change (especially since it causes size inconsistencies). Kaldari (talk) 22:16, 12 December 2008 (UTC)
      • According to another source, as long as you stick to black, white, yellow, blue, and red, you won't cause any problems for people who are color blind (unless they are the 0.00001% who are monochromatic). Kaldari (talk) 22:23, 12 December 2008 (UTC)
  • If those of you who are raising “accessibility” issues had read my initial post on this thread, you will see that using color alone is not a real problem here and doesn’t create an accessibility issue. Most color-blind people have red/green color blindness. For these people, you don’t want to use, for instance, both red and green to denote two, important, different things. If there is someone who has absolute color blindness, they can just set their bit depth and gamma so maroon is a very distinctly different shade of grey to discern the difference. Getting back to real-world problems, Noetica’s suggestion to also change the typeface makes it even easier to visually identify the example text than would be realized using color alone. Greg L (talk) 00:38, 13 December 2008 (UTC)
    • I agree it would make it even easier to identify, but so would using the blink tag (not that I'm actually suggesting that). Isn't changing the color sufficient, though? It's pretty hard to miss the fact that the text is in a different color. Using both color and typeface seems to be overdoing it, IMO. Kaldari (talk) 00:44, 13 December 2008 (UTC)
  • There is no right or wrong answer here, Kaldari; it’s simply a matter of whether adding some more distinction might be even better. You be the judge:
  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).
v.s.
  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).
Note that my initial proposal was to use only color. But I think Noetica’s suggestion to also use typeface makes it even easier to distinguish example text. I see no downside; particularly when we have copy/paste to simplify editing and, further, templates can implement our bidding easier yet.
Greg L (talk) 00:54, 13 December 2008 (UTC)

I'm opening a RfC for this, since there has been little input from editors on this. -- Army1987 – Deeds, not words. 21:22, 12 December 2008 (UTC)

Thanks Army. (But what's the markup problem, above? Couldn't get your text onto a new line, on Firefox at least.) This is easily important enough for an RfC. (Come on, MOS-editors: this is a big one. It can make the MOS-pages far more usable.)
–⊥¡ɐɔıʇǝoNoetica!T– 21:49, 12 December 2008 (UTC)
  • Noetica: The inability to create a new paragraph without an explicit <p> seems to be a rendering problem left over from my complex <font>-based techniques. I noted it before on WT:MOSNUM after I had complex paragraphs. I’ve noted it elsewhere in fact, when I’ve been busy doing exotic formatting like this. This may well speak to the virtues of using the <span>-based technique Army1987 says are better. Greg L (talk) 01:15, 13 December 2008 (UTC)
    I think it's more likely to be due to the fact that some of the <p> aren't closed. -- Army1987 – Deeds, not words. 02:20, 13 December 2008 (UTC)
    Fixed. (I also moved my 21:22 comment and the following subthread to the bottom, I can't even recall why I had placed it in that absurd place—between a question of mine and your answer—in the first place.) -- Army1987 – Deeds, not words. 02:31, 13 December 2008 (UTC)
A note on using distinctive colour and typeface

Kaldari asks above why both should be implemented. Wouldn't colour alone be enough? Greg points out that the highlighting is even clearer, using both. Certainly true; but there are other reasons:

  1. Our text may be quoted online, outside or inside Wikipedia. It may lose attributes in ill-managed transfers, so two attributes are safer than one.
  2. Our text is cited in print, and this healthy trend can be expected to gather strength. (In Australia excerpts from our music articles are often read out on ABC Classic FM, by the way. Just had to tell you!) But most commercial print does not use colour in text. Let's set an example of sound practice for Wikipedia articles, so we don't discourage such use.
  3. Users may print our text, and many will not have a color printer; or like me they may prefer monochrome print, or prefer not to waste expensive toner.

–⊥¡ɐɔıʇǝoNoetica!T– 03:20, 13 December 2008 (UTC)

A note about background and transparency

[Here are some points that arose in a thread below. They belong here for consideration, with all the other points about attributes for example text.–⊥¡ɐɔıʇǝoNoetica!T– 07:36, 13 December 2008 (UTC)]

Greg L: To PMAnderson [who had not liked a white background] and Army1987: A) do we have to prescribe a background color? And B) If we want to use this on MOS and MOSNUM, do we really have to worry about non-white backgrounds? Answering my own question to “B,” I suppose if one wanted to use maroon-highlighted text in a {{quotation}} template or within a green-div box, specifying a background color would be as ugly-ass as Bruno Magli shoes on O.J. So, Army1987: can we de-specify (leave transparent) the backround in your <span> technique?

Noetica:...Background colour needs to be considered. In my opinion, yes: keep it transparent. People have different local setups affecting background and the like; and in any case three attribute changes is going a bit far. WP already uses two attributes changes for links: colour and underlining. I like underlining, as I explained in the discussion at WT:MOSNUM; but since links use it already, I guess it should be set aside as an option for our purposes.

Wider consultation?

Couldn't find where anyone had linked to Using colours in articles. While I see people referring to the issue, and with good regard to, say, "which colors?" to minimize problems, the fact that there are references elsewhere means you should consider soliciting wider comment. Just how I don't know, but it should be done. Shenme (talk) 05:16, 13 December 2008 (UTC)

I’ll respond to that…

I read WP:Using colours in articles just now, Shenme. Twarn’t nothin’ there but a steaming pile of plain ol’ common sense; all stuff that has already been discussed above. The article you cite does have some examples of text with other colors, such as red text, (which I think looks like a broken link), and blue text, (which I think obviously looks like a link), and green text, (which I think has rather low contrast). I’ve personally used color to denote quoted complex text for about a year now. With the possible exception of a custom color, #721F01; brown, which looks rather similar to named “maroon” in many browsers, I haven’t found anything much better.

And this is not for failing to actually look into the subject of color with some measure of due diligence. I’ve explored other color combinations, which have been on my user page for a long time. They are:

This is an example of using Red text via RGB manipulation.
Here's a custom brown color with RGB values manipulated: custom brown
This is an example of using a named color “maroon” to change the color of text.
Here are more colors:
This is an example of using one of the widely supported named colors to make AQUA text.
This is an example of using one of the widely supported named colors to make BLACK text.
This is an example of using one of the widely supported named colors to make BLUE text.
This is Wikipedia link-blue, which is in <font color="#002BB8"> text.
This is an example of using one of the widely supported named colors to make BROWN text.
This is an example of using one of the widely supported named colors to make CHARTREUSE text.
This is an example of using one of the widely supported named colors to make FUCHSIA text.
This is an example of using one of the widely supported named colors to make GRAY text.
This is an example of using one of the widely supported named colors to make GREEN text.
This is an example of using one of the widely supported named colors to make LIME text.
This is an example of using one of the widely supported named colors to make MAROON text.
This is an example of using one of the widely supported named colors to make NAVY text.
This is an example of using one of the widely supported named colors to make OLIVE text.
This is an example of using one of the widely supported named colors to make ORANGE text.
This is an example of using one of the widely supported named colors to make PURPLE text.
This is an example of using one of the widely supported named colors to make RED text.
This is an example of using one of the widely supported named colors to make SILVER text.
This is an example of using one of the widely supported named colors to make TEAL text.
This is an example of using one of the widely supported named colors to make VIOLET text.
This is an example of using one of the widely supported named colors to make WHITE (white) text.
This is an example of using one of the widely supported named colors to make YELLOW text.

I think all we pretty much need here is just to dish out our own pile of common sense. If the text is easy on the eye and effectively sets off example text in a manner in which the method of doing so doesn’t get in the way of the message point, then it’s a good thing and we can stop wondering if the color gods somewhere will make the volcano overhead rumble tonight. Greg L (talk) 05:39, 13 December 2008 (UTC)

Take a look at the colours I chose in in the solutions here; I bolded them in each case, because it seemed to make them stand out better. I found anything but the darkest colours was unsuitable. Tony (talk) 07:13, 13 December 2008 (UTC)

Span-based with transparent background on different backgrounds:

Here are some examples of maroon with transparent background (no specification), imbedded in some popular themes used on MOS and MOSNUM. The span tag is as follows: <span style="color: maroon font-family: serif; font-size:107%">:

Here is <div style> (“green box” or “green div”):

  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

Here is the quotation. Note that I could make neither <span> nor <font>-based techniques work.

Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

I don’t see this inability to use this typestyle in a quotation template as a deal-breaker myself. But it would be nice if someone could show me A) what I’m doing wrong here, or B) figure out what is wrong with the quotation template. Greg L (talk) 08:19, 13 December 2008 (UTC)

As for the background, I think we should specify one, in case someone uses a style like this one as the default one in their stylesheet. (Yes, some would argue that such people would deserve having invisible text.) To minimize ugliness, we could specify a color identical to the default one on MOS, like this. -- Army1987 – Deeds, not words. 12:23, 13 December 2008 (UTC)
I don't think specifying the background is a good idea. It's much more likely that users will have specified an alternate light background colour (e.g. yellow) than that they will have set a dark colour against which maroon would be invisible. In the former case, forcing the background of example text to be white would be ugly and distracting. In the latter case, I don't think it's our problem. Someone who sets their page background to a dark colour should expect to find some things unreadable. It's up to them to figure out how to handle colour changes in body text.--Srleffler (talk) 16:18, 13 December 2008 (UTC)

(edit conflict; but what I had written is still valid[1], so I just copy&paste it.) On the other hand, If we added style_example { color: maroon; font-family: serif; font-size:107% } to MediaWiki:common.css, without specifying any background color, then we could simply use <span class="style_example"> to mark-up examples; someone perverse enough to use styles such as the one above could then add style_example { background: white } or whatever to their own stylesheet.
As for templates, replace = to {{=}}. Templates, when they see foo bar = baz quux, believe you're passing them a named argument foo bar with a value of baz quux. More simply, you can add 1= immediately after the first pipe, telling that everything after the = and before the next | or the }} is the content of argument 1.
This is what you get when you replace =s with {{=}}s in the example above:

Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

[1] Except that "you" refers to Greg L. (Something very weird is going on with indentation levels, too. Maybe unclosed <p> tags confuse MediaWiki.)-- Army1987 – Deeds, not words. 16:38, 13 December 2008 (UTC)
  • Srleffler is right, Army. The vast majority of uses of this highlighted text will be on white. A subset of use on WT:MOSNUM and WT:MOS will find highlighted text set against pastels (where not having white text background will look much better). It is better and easier to not specify the background color so the text looks nice on white, and in quotation boxes, and in pastel div-boxes. For those quite rare occasions on MOS or MOSNUM where highlighted text must go over a blood-red field like you showed above, one can easily hand-code the span tag. We can always stash a copy of the code on our user pages.

    And the reason for my above use of <p> tags is because of the paragraph weirdness, Army. I can’t figure it out.

    Finally, thanks for figuring out how to get this into a quotation box. You da man. Greg L (talk) 20:18, 13 December 2008 (UTC)

Memorializing where we are to this point: Army1987 figured out how to make the span tag work within quotation boxes. It is as follows: <span style{{=}}"color: #721F01; font-family: serif; font-size:107%">Example text set in highlighted style.</span>.

This text looks like this in a quotation box:

Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

and like this in a green-div box:

Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

and like this as regular text:

  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

Here is a more complex double check (it has several imbedded {{nowrap|text}} in it) and a little bit of just about everything else:

The following appears on WT:MOSNUM: Unless there is a good typographical or communication-based reason otherwise, in numeric equivalencies, the unit symbol shall be in roman (non-italic) text. A non-breaking space “&nbsp;” almost always separates the value and the unit symbol (e.g., 2.4 GHz, 325 km, 25 °C). Exceptions are the degree, minute, and second for plane angle, °, ′, and ″, (e.g., 47° 38′ 8.8″), and the percent (%) symbol. Variables are always italicized, (e.g., T = 298 K, e = mc2). Further, when quoting the Captain in Cool Hand Luke, one does as as follows: The Captain said “What we’ve got here is ‘failure to communicate.’ ”

And this:

But the most important thing is being consistent in each context: 5 cats and 32 dogs or five cats and thirty-two dogs, not five cats and 32 dogs.)

Greg L (talk) 03:24, 14 December 2008 (UTC)

  • What I’m wondering now, is this: Can Army1987’s above span statement be captured in a sweet little template such as {{ExampleText|Text goes here}}? Greg L (talk) 03:45, 14 December 2008 (UTC)
    Like this one? (I don't like CamelCase so I called it Example text rather than ExampleText, but you can make a redirect from the latter to the former if you prefer so. I also like to Keep It Simple, but {{Example}} is already used for a different purpose.) -- Army1987 – Deeds, not words. 17:53, 14 December 2008 (UTC)
  • Damn Army! {{Example text}} Cool. When I look at the code of some of our templates (like this “Val” code,) it almost makes my head hurt. Writing templates is certainly not something I think I would learn easily nor enjoy. Thanks. Greg L (talk) 18:36, 15 December 2008 (UTC)
That's great, Army. You are a hero of the Revolution. Two things:
  1. More consultation is needed concerning the exact increase in size, and the exact colour.
  2. The name of the template needs to be shorter, or it needs a short alias like {{In lang|et}}. Examples are often profusely peppered in our text, and this sort of thing is painful:

Use {{Example text|0.1 kg}}, not for example {{Example text|.1 kg}}, {{Example text|0.1kg}}, or {{Example text|0.1 Kg}}.

Yielding this:

Use 0.1 kg, not for example .1 kg, 0.1kg, or 0.1 Kg.

Better would be:

Use {{xt|0.1 kg}}, not for example {{xt|.1 kg}}, {{xt|0.1kg}}, or {{xt|0.1 Kg}}.

–⊥¡ɐɔıʇǝoNoetica!T– 00:05, 16 December 2008 (UTC)
  • Noetica: How are we to interpret You are a hero of the Revolution. that you wrote to Army? Is that congratulatory? Ambiguously deprecating? I just can’t tell since I am getting to know you. What did you mean?

    Thanks again Army.

    I don’t see the need to open debate on atomic-level details like exact size and color. Once you head down that path in a forum like this, nothing will get done. I think it is better to start using the darn thing and see if very many Wikipedians and readers pop up in “real life” (if you can call actual use on Wikipedia “real life”) who write posts like “On my Phing Thang-brand 640 × 480 CRT monitor, using MS-Barbarian OS and the Andromeda Strain browser, maroon looks indistinguishable from broken-link red.” If a pattern develops, you tweak. Same for size. I see no need to get an RfC started on WT:MOS on the details of the recipe for vegetable beef soup. For the moment, soup it is. I can, however simulate a PC (I use a Mac) by running GammaToggleX. I can tell that maroon can likely not go any darker. I had explored all this a year ago.

    I do agree that it would be nice to have an abbreviated alias that works in place of the full expression “Example text” I note that {{xt|Thanks Army}} produces Thanks Army. So perhaps {{xt|Thanks Army}}? I see it is not taken ({{xt}}). Greg L (talk) 05:44, 16 December 2008 (UTC)

I'll code the template. Colors and fonts can be agreed upon later.Headbomb {ταλκκοντριβς – WP Physics} 05:49, 16 December 2008 (UTC)
  • So, this is where Greg shows how “new” he is: If you are going to code the template, then what is {{Example text}}? Greg L (talk) 05:57, 16 December 2008 (UTC)

Yeah well I skipped right at the end of all this text, I thought people were debating what name to use and where to code things. Nevermind my last post then.Headbomb {ταλκκοντριβς – WP Physics} 06:07, 16 December 2008 (UTC)

(*Phew*) I’m not that new. We were discussing the alias nickname to use. I think {{xt}} works fine. And, as you can see from the red color, it’s available. I’m using {{Example text}} now in my posts. I haven’t encountered any complaints about readability or confusion about what it means. Greg L (talk) 06:16, 16 December 2008 (UTC)
Greg:
This is what I said to Army: "That's great, Army. You are a hero of the Revolution." I am surprised that you see in this any ironic deprecation, any more than we should see your colourful exclamation as involving any deprecation or irony: "Damn Army! Cool!" I appreciate what he has done, and I say so.
Given the plethora of details above, I certainly do not see anything strange or untoward in adding a couple more details, as we forge forward with this. Colour needs to be talked about, and so does size. Again, I am surprised that you think two such basic parameters unworthy of some brief final consultation, before we implement the thing. I did not call for an RfC! It's a simple, local matter, and it can be dealt with briskly. For what it's worth, the example text comes up slightly too small for my liking, using {{Example text}}.
As for the precise form of the abbreviation, I only gave an example; I did not explore what already exists. {{xt}} looks fine to me! Better than {{In lang|et}}, in fact.
I propose as follows:
  1. We make the text a little larger: perhaps one further percentage point, or whatever it takes to get the height of the example text exactly equal with the surrounding text.
  2. We settle on the present colour, because it contrasts with the most likely backgrounds, and is quite distinct from the other colours in standard use: the blue and red of bluelinks and redlinks.
  3. We grab {{xt}} immediately. (Army or someone can do that without any consultation, of course.)
I now call for comments on these details, from any MOS-editors who are interested.
Then we should call for implementation: for WP:MOS in the first instance, which will require some small procedural discussion and some care in the doing. (Why WP:MOS first? Because it's central, not locked, and a little simpler than WP:MOSNUM for this sort of alteration.)
–⊥¡ɐɔıʇǝoNoetica!T– 06:15, 16 December 2008 (UTC)
Exploring size
  • OK. Sorry, I thought you might be employing over-the-top praise in a facetious manner. I couldn’t tell. My apologies (all I did was ask…). As for color, I agree; it works and I see no need to work that issue. As for size, perhaps it could be enlarged a tad.
  1. Here is an example at 100%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  1. Here is an example at 107%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  1. Here is an example at 110%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  1. Here is an example at 113%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  1. Here is an example at 116%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  1. Here is an example at 120%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
  1. Here is an example at 125%: 5 cats and 32 dogs or five cats and thirty-two dogs, but do not write five cats and 32 dogs
On my platform combo (G4 iMac running OS X 10.5.6, which was just released today), 107% through 120% are the same thing; I examined blow-ups of screen-shots. A setting of 100% is clearly too small for my taste. The 107–120 option seems a bit smallish, but has worked for me all along. A jump to 125% seems to be required to perceive any difference but then it looks too big and clunky to me. How say you all? Do you see more size gradation than I do? Or do you see The Three Bears? I think the 107% command is binned to the equivalent of a “+1” size change. The 125% is a +2. I think we need +1. The 100% clearly looks to small. The 107–113% look identical. The 116–120% appear are very slightly larger, which, on my Mac, I could only see by blowing up screen shots to 400% and look at the way it aliased the text. The 125% looks way too big to me. I know it will look very different to other editors; particularly those using browsers that don’t have anti-aliasing font technology. I would say that if we want to enlarge a tad, that we might try 114%. Greg L (talk) 07:37, 16 December 2008 (UTC)
I changed the color to International orange, as it constrasts well with everything. Headbomb {ταλκκοντριβς – WP Physics} 06:40, 16 December 2008 (UTC)
  • Uhg! Like Tony said in his 06:42, 16 December 2008 (UTC) post above I found anything but the darkest colours was unsuitable. And I wholeheartedly agree with him. Back to maroon! Please. Greg L (talk) 06:45, 16 December 2008 (UTC)
  • Do these colors render the same in all browsers? I know in some articles, the color in the infobox title, for example, obscures the text so that I cannot read it. —Mattisse (Talk) 06:51, 16 December 2008 (UTC)
Okay, I switch it to carmine, which is darker, but still contrasts with black way better than maroon does. And yes this is the same in all browsers.Headbomb {ταλκκοντριβς – WP Physics} 06:59, 16 December 2008 (UTC)
  • Never heard of it (which might explain why I hadn’t been using it all along). Works for me. I agree, it looks better with PC Gamma on my Mac. Very good from my point of view. Greg L (talk) 07:11, 16 December 2008 (UTC)
Headbomb, please stop implementing xt without clearance first here! We are discussing the details, and you rush to implementation even while you make changes in the colour. Don't. It won't be long now, and we'll agree to go ahead. As I pointed out above, implementation "will require some small procedural discussion and some care in the doing".
Greg, all sorted out now concerning irony and its absence. Thanks for showing the various sizes. Can others now give their opinion, for their systems? On mine (latest Firefox under Windows XP, running at a medium level of zoom on a 22 in wide monitor), 113% looks best.
–⊥¡ɐɔıʇǝoNoetica!T– 07:29, 16 December 2008 (UTC)
Cross you Ts and dot your Is. There's no sense in delaying implementation. Whatever details is decided on will automatically be by updating the template.Headbomb {ταλκκοντριβς – WP Physics} 07:48, 16 December 2008 (UTC)
  • That’s my feeling. The template isn’t locked down. Now that it’s being used on MOS, we will get more feedback. And now that it has a nice “xt” alias, more editors will be prone to trying it out. Greg L (talk) 08:01, 16 December 2008 (UTC)

Here is an example at 114% using hex-specified carmine: Editors should write Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi). Greg L (talk) 07:37, 16 December 2008 (UTC)

  • I changed the size to 114% in the template so more editors see the effect. Greg L (talk) 07:37, 16 December 2008 (UTC)
  • What? xt now works? Let’s see… Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi). Yup. Works. Saves finger wear. Faster. Easier. Greg L (talk) 07:45, 16 December 2008 (UTC)
  • And here is hard-coded 114% maroon: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi). Greg L (talk) 07:50, 16 December 2008 (UTC)
  • To me, carmine (#960018;) looks better than maroon with PC gamma (maroon is too dark on PCs). Carmine, while very slightly garish, is acceptable with Mac gamma. For some reason though, when I look at all of it on MOS, it looks like it could be tweaked just a bit darker. I really wonder how others feel about what they see on MOS. I have no problem at all with the size at 114. How’s that too? Greg L (talk) 08:08, 16 December 2008 (UTC)
Dark than carmine is too dark for my tastes. I went through the list of colors and it's the only one that evidently contrasts with black that is not eye-raping red. Carmine looks good to me no matter where I read it from (tested on multiple monitors and browsers, but not on Macs).Headbomb {ταλκκοντριβς – WP Physics} 08:13, 16 December 2008 (UTC)

How about #900012;? Here is an example at 114% using hex-specified #900012;: Editors should write Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi). I tried it just now on the template. If you think it is an abomination in the eyes of all good Wikipedians, by my guest; I thought I’d look at it on MOS for a bit here… Greg L (talk) 08:21, 16 December 2008 (UTC)

  • I’m going to bed. I’ve had enough input on this tonight. Others can have a chance to voice their opinion after I shut the hell up for a bit here. Greg L (talk) 08:30, 16 December 2008 (UTC)
    • I do like the slightly darker. We need to check with those who use different browsers. Anyone got Safari for Windows? It was released within the past year, and might need to be surveyed. But the problems are likely to lie with the spiteful Internet Express, whether Version 6 or 7. Tony (talk) 10:38, 16 December 2008 (UTC)
Greg:
It is important for editors to understand that the appearance of the different sizes, relative and absolute, is different on different systems, browsers, and zoom settings. I find that 113% is a good compromise for me. We now need to hear from others.
Greg and Headbomb:
MOSNUM is locked down. If you rush to make radical changes when just two editors favour such action, you jeopardise things here at MOS as well. I have asked for a few final points to be refined: a reasonable starting determination of the size, and then some brief discussion of how to implement this thing. As one of the two prime movers behind this (Greg being the other), perhaps my caution can be given some respect. Please hold off until a few more have contributed their ideas. We are watched closely at places like WP:FAC, and they quite rightly detest a flickering and unstable MOS. If you want a sandbox, here's one you can use:
  • I don’t quite see the concern for a disastrous setback if Headbomb goes ahead and implements the use of {{Example text}} font on MOS. It is the biggest sandbox there is. And as you, Noetica, have readily demonstrated, it is extraordinarily easy to simply revert. I was appreciative that Headbomb volunteered to do the heavy lifting in implementing the idea on MOS; it provides the perfect sandbox, with many different kinds of text set in the largest imaginable variety of contexts. Before Headbomb had set off and done that, I was considering copying large swaths of MOS to a sandbox of my own. Headbomb’s approach (give it a whirl and see how it looks), while WP:BOLD, seemed a sensible solution. He seemed to assume editors won’t act like children over something that doesn’t affect policy content. Your controlling nature here, out of an abundance of caution, is over an issue that doesn’t change the meaning of a single guideline—only the manner in which the information is presented—is stifling and makes me loose interest in this. Wikipedia is supposed to be a fun hobby. But having to dance around another editor who insists on doing it this way and that is no fun at all. I wish you would lighten up. If Headbomb reverts your reversion, please, just go with the flow. If exhibiting the idea there on MOS for lots of editors to inspect later proves to have been a fiasco, you will look like a God-damned genius.

    I also think we need to recognize that there are clearly four prime movers here on this: you (Noetica), me, Army1987, and Headbomb. Army figured out how to make the text display in quotation boxes and made the template. Headbomb is enthusiastically doing the heavy lifting here, and is clearly being very meticulous about it to ensure nothing gets messed up. You and I did the easy part. Greg L (talk) 19:42, 16 December 2008 (UTC)

Of course I appreciate the fine work that Army and Headbomb are doing. In calling you and me "prime movers" I simply meant that we were the sponsors and initiators of this action, and continue our oversight of it. Is that the "easy part"? Yes and no: the big picture is not so easy to discern, as we see demonstrated again and again in these forums. We both have credentials at the coalface also, and where we are competent we labour over the hard details, editing here and at MOSNUM. The statistics amply demonstrate this.
Meanwhile, there is a clear norm at Wikipedia: don't use the articles and project pages as sandboxes. I don't want to quarrel about this, or to dwell any more on the dismal course of things at MOSNUM. I simply appeal to that reasonable norm, and call on editors to respect it. We have made great progress with this markup for examples; and we can easily continue it without compromising the stability of MOS, or its reputation with those who depend on it.
–⊥¡ɐɔıʇǝoNoetica!T– 21:48, 16 December 2008 (UTC)

arbitrary section break

I'm coming to this late, and I admittedly haven't read all the comments, so maybe this has been covered. I see nothing in the markup of the tests (either in MOS or the sandbox) that would provide any indication to a user of a screen reader or a user without CSS support that there has been any change to the text. The US federal government and some states (including California) are required to follow Section 508 Amendment to the Rehabilitation Act of 1973 on their web pages, which states, "Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup." <span> is unfortunately not adequate markup. I'm not saying that Wikipedia has to meet any accessibility guidelines, but I wanted you to be aware that if you think {{xt}} is accessible, it isn't.--Curtis Clark (talk) 04:25, 17 December 2008 (UTC)

  • Thank you so much for your diligent efforts to look out for the welfare of the handicapped, Curtis, and for pointing us towards Section 508 Amendment to the Rehabilitation Act of 1973. Do tell: how do you think screen readers handled the italicized text that was previously used on MOS and MOSNUM to set off example text? I have a screen reader on Mac OS X. I just used it. The following sound identical to me; maybe you have better ears than I do:
  1. Converted values should use a level of precision similar to that of the source value; for example, the Moon is 380,000 kilometres (240,000 mi) from Earth, not…
  2. Converted values should use a level of precision similar to that of the source value; for example, the Moon is 380,000 kilometres (240,000 mi) from Earth, not…
Are you aware of any screen readers that rather parenthetically say “and the following is in italic text” or “and the following is in a serif typeface”? Greg L (talk) 07:25, 17 December 2008 (UTC)
I'm sorry, but the sarcasm doesn't enhance your attractiveness.
Although it would appear that no common screen reader out-of-the-box designates italics differently from ordinary text, it is my impression that many allow it as an optional setting (I'll check the situation with JAWS when I get to work). It is possible that JAWS could even designate <span>s, but <em> (and even <i>, by association) has a semantic meaning (which may or may not be observed), while <span> does not. For someone whose job it is to ensure accessibility, one doesn't have to deal with broken assistive technology so much as provide the semantics so that properly working assistive technology can do its job.
It turns out that JAWS can indeed be configured rather extensively for that sort of thing.--Curtis Clark (talk) 15:22, 17 December 2008 (UTC)
If one gave a rat's ass, one might mark the text up as <code> rather than <span> (I haven't checked to see whether there are other uses of <code> that conflict), which would give screen readers a semantic handle (whether they used it or not), and would provide a basis for a visual distinction for users without CSS support.
As I said (contrary to your sarcasm), it doesn't matter to me whether Wikipedia is accessible or not, since it's not my job to make it so (and I can profitably use it as an example, either way), but the discussions about color-blindness only scratch the surface.--Curtis Clark (talk) 15:08, 17 December 2008 (UTC)
I just have to say that I see the argument for the colors from a practical point of view, orthogonal to the accessibility issues on which I take no stand for the moment. But from an aesthetic point of view I really can't stand them. Greg's habit of using colors in talk-page discussions has frankly annoyed me before this, though not enough to bother saying anything about, but to have them seep into guidelines is something I find more than a little unpleasant.
My real nightmare is that this will somehow get into mainspace. If it can be confined to the MoS I suppose the harm is minimal; I still don't like it but I don't care enough to raise a huge stink. But newish editors might be tempted to "follow the MoS's example", even when writing articles, and that would be a truly bad outcome. --Trovatore (talk) 04:41, 17 December 2008 (UTC)
My experience is that many people see color as an additional level of emphasis. One of my duties is management of an announcement space on a corporate portal, and I actually get "their headline is in red, and ours is more important, so ours needs to be red with a yellow background".--Curtis Clark (talk) 15:08, 17 December 2008 (UTC)
  • Ok, you’re right Curtis. I don’t wear sarcasm well; particularly when an editor is well-meaning. I fall back on sarcasm whenever I detect absurdity. And in this case, that absurdity—to me—was over your faulting the template over accessibility issues when what it is replacing (italicized text) has zero virtues whatsoever in this regard.

    Also, (and this is me falling back onto another “shortcoming”: plain-speak of what I think is truth), people who are legally blind but still have some sight can still read by having their OS present truly gargantuan text on screen. I’ve seen it on TV: a legally blind person with her nose about 10 cm (4 inches) from the screen. Who wants to listen to a synthetic computer voice if they can read it themselves? No one. So screen readers are used by whom? By the totally or near-totally blind; that’s who. Screen readers allow these individuals access to important Wikipedia content. We can thank companies like Apple for producing a screen reader that properly pronounces text like “I project you will be done with that project Jan. 21st.” Not only does OS X recognize the transitive verb and noun forms of “project”, it pronounces the end as “January twenty-first.” Smart stuff.

    Now, what we are discussing here is the use of {{xt}} on MOS and MOSNUM to highlight example text and make it visually distinctive from the prose describing it. MOS and MOSNUM are unique venues where users learn about style guidelines expected for authoring content. I’m not quite buying it here that the totally blind are going to be authoring Wikipedia content; it’s not passing my *grin test* here. To me, this is like faulting the concrete workers as they are putting in a wheelchair ramp at a corner crosswalk because they are using concrete-laying tools that permit only the able-bodied to be concrete workers. I’m thinking we’ve addressed the issue of accessibility sufficiently well with the fact that the totally blind can read our articles.

    As for color blindness, that’s all be discussed above and I won’t repeat it here. Suffice to say though, having the example text also in a serif typeface addresses this issue just fine. Greg L (talk) 22:50, 17 December 2008 (UTC)

I'm quite aware of screen magnifiers; a colleague uses one in conjunction with a screen reader to take notes. I have worked with a totally blind student who is a JAWS expert. And there is a Wikipedia editor, Graham87, who uses a screen reader, I presume because he requires it (few people use screen readers just for the challenge). Accessibility isn't some sort of bleeding-heart political correctness; it's a technology, like any other, and it is a maturing technology. If no one wants to explore the use of <code> instead of <span>, like I said, it's no big deal to me, but it doesn't pass my "duh!" test.--Curtis Clark (talk) 04:55, 18 December 2008 (UTC)
  • Yes, I use my OS X screen reader too for important work. I can miss double words like “and and” and “the the” and other goofs that really jump out when you hear it. Greg L (talk) 06:07, 18 December 2008 (UTC)
  • Trovatore , MOS and MOSNUM present unique circumstances where the formatting of text and methods for properly quoting text are being discussed and illustrated; thus presenting a need for some other way to highlight example text without relying upon the very markup techniques being discussed. Further, we need a way of highlighting text that doesn’t entail violating our very own guidelines, such as putting unit symbols in italic, or which makes it impossible to show a sentence where both unit symbols and variables are in the same sentence, such as these two:
  1. When quoting a statement which included a period, put the period inside of the quote mark, like this:
    He wrote that “Einstein didn’t really create the formula E = mc2.”
  2. Unit symbols are in roman text, variables are italicized: T = 295 K
The premiss for all of this is outlined at the very top of this thread. Greg L (talk) 07:25, 17 December 2008 (UTC)
As I said, I understand the practical argument. I just can't get the fact that (to me) it looks purely awful. Really, really, really, really terrible. Sorry, that's the way I see it. --Trovatore (talk) 09:33, 17 December 2008 (UTC)
  • Understood. If this proves to be a widely held view, I think we should certainly try to modify {{xt}} rather than get rid of it (which should be reserved as a method of last resort). As I expand upon later in this post, if we want to, (because ugliness proves to be a widely shared view) we can revise the {{xt}} template to set off example text in italic-only. Anything, really can be done in the template and all example text will instantly and globally follow suit.

    Army1987 and Noetica pointed out (and I completely agree) that showing instructions like “It is 1.8 m and not 1.8m” not only violates the rule of SI, it also violates our own guidelines. In order to handle “It is 1.8 m and not 1.8m” and things like T = 295 K, MOS had to suddenly jump to the use of a different technique to set off text being spoken of, like quotation marks. When I look at the older versions of MOS with italic example text, it looked horrid to me (this speaks to the difference between our “eyes”); the reliance upon italics didn’t distinguish example text very well from the prose text and it was hard for my eye to parse what was this and what was that. Very hard. You hate it, and oddly, I think {{xt}} makes it really, really, really, easy to parse the MOS page. I really like it. Clearly Noetica, Headbomb and Army1987 feel the same way. You might find this hard to believe, but Army1987 used {{xt}} when illustrating some example text in a post on WT:MOSNUM and, initially, I didn’t even notice the technique he had used to set off text being discussed—the method didn’t call attention to itself and interfere or compete with his message point. It clearly does call attention to itself in your case and I’m hoping that this isn’t common and, further, that it will prove to be an issue of just getting use to it.

    I’d like to point out that I perceive no need whatsoever for others to have a sense of urgency nor for worries about this technique being effectively grandfathered as a consequence of it ‘sending down tap roots’ and being hard to extricate due to intervening edits to the content of guidelines. It is ultra easy to change the color on {{xt}}, or any other attribute for that matter. We could always set xt to simply generate italic text, or generate 107% black serif in bold style. If we want to preserve, for archival purposes, existing discussion text already marked up with xt, we could even create {{xt2}} and do a seach & replace on MOS. Having example text flagged with xt gives us all sorts of options and flexibility that we never had before. 19:07, 17 December 2008 (UTC)

  • The present setting (at 114%) is painful to me on IE, a widely used platform; it's an abrupt change in size, combined with a change in typeface and color. I think 100% would be uniform size for IE, which would be preferable to me. Septentrionalis PMAnderson 17:32, 18 December 2008 (UTC)

Fleshing out details

(Moved to Template talk:Xt.)

For italic quotations

I find text with italicized quotations easier to read, especially with longer quotations; different styling helps understand what belongs to the main text and what is an illustration. The need to scan several lines of text backward and forward to find a tiny quotation mark is a serious impediment. I reserve quotation marks for short quotations (e.g. of proper names) where both of them are in sight while reading, and I use straight quotation marks for them. In addition, wikisyntax itself uses apostrophes, which can be viewed as primitive quotation marks, for italic. Of course, these remarks do not apply to literary prose because it is usually read rather than scanned as a source of information so the reader does not need to determine the character of the text being read from from within.

Wikipedia:Manual of Style/Archive 107 should allow italic quotations when they are longer, e.g. contain sentences, but singling them out with a block would break exposition. --Yecril (talk) 10:36, 16 December 2008 (UTC)

How will the reader know that the italics signify a quotation, when italics are likely to mean emphasis in other articles? (Not that I'm a fan of putting a whole sentence in italics.) - Dan Dank55 (send/receive) 04:10, 17 December 2008 (UTC)
Because quotations are attributed: "As Somewiseman said: Lorem ipsum...". Septentrionalis PMAnderson 16:26, 17 December 2008 (UTC)

The quotation can be both italic and in marks, where the marks can be suppressed for browsers that support CSS. The current situation is that the reader finds himself in the middle of something and it is hard to figure out what exactly it is. Of course, it would be best to style quotations with Q, but we would have to get Brion allow Q first. --Yecril (talk) 17:54, 18 December 2008 (UTC)

Italics have too many other uses - emphasis, book / story / magazine titles, ships' names, etc. For long quotes I'd prefer one of: indentation (..), <blockquote> or {{cquote}} --Philcha (talk) 21:28, 18 December 2008 (UTC)

I understand that; however, several authors, for various reasons, prefer inline quotations. We are not discussing block quotations here as they do not present usability problems. And besides, all italic things Philcha brought into our attention are significantly shorter, so there is no risk of ambigüity, and, moreover, they are better served by EM and CITE. --Yecril (talk) 21:41, 18 December 2008 (UTC)

I have to agree with Philcha. As italics are employed to set off text for a variety of purposes (titles of books and films, foreign words and phrases, emphasis, etc.), putting inline quotations entirely in italics would cause problems with this and would require existing guidelines relating to the use of italics to be changed. — Cheers, JackLee –talk– 05:12, 19 December 2008 (UTC)
Not a problem in practice. Emphasis and titles in in italic text are reversed to non-italic, exactly what our '' control characters do by default; any prose that is not clear what is emphasis and what a quote needs to be clarified anyway. Septentrionalis PMAnderson 16:15, 19 December 2008 (UTC)

Highlighting in colour—Template:xT

I find the green colour much less intrusive and messy on the page than the rusty red colour that was previously tried—thanks to Greg L for that. However, there are several problems—two visual and two procedural:

  1. On different browsers / operating systems / monitors, the colour is different, so that what is almost black for some readers is a distinct green for others (like me). The previous reddish colour required sunglasses, even though I normally keep my monitor on minimum brightness for WP.
  2. The unserifed normal text and the serifed example text respond differently to zoom. Many readers vary their zoom for different conditions; there is no guarantee that "default" settings are consistent across seeminly similar systems.
  3. I wish the experiments weren't being conducted on the page itself.
  4. The documentation for {{xt}} does not report the exact actions, let alone the values of the parameters affected: size, typeface, nothing. It merely shows the current state of the template using examples. Where is the link to the code? Why is a template that makes an overwhelming difference to the appearance of the MoS page inaccessible to all but Headbomb? Army87? Perhaps I'm being techo-dumb here. Tony (talk) 04:45, 20 December 2008 (UTC)
  • Tony, here’s the code to the template. And when that link isn’t available, all you need to do is go to {{xt}} and click on “edit this page”. It’s main code is as follows: <span style="color: #006400; font-family: 'Times New Roman', Times, serif; font-size: 110%;">, which parses as hex 64 green (dark “Tony” green, or decimal 100); Times New Roman (or Times if you don”t have that, or your browser’s “serif” typeface per its preferences setting if it has neither font installed); and 110%, which boosts the size proportionally irrespective of the zoom level. But at zero zoom (actual, 12 pt text), 110% is equivalent to boosting Times New Roman from 12 pt text to 13 pt text.

    Our discussions are at Template talk:Xt. I’ve been waiting for your input there because I know that you see colors as being particularly bright on your Mac. Headbomb sees things the opposite way. So far, Army1987, Headbomb, Kaldari, and I have all had a hand in modifying the template to make it better; join on in. And, BTW, here’s a sandbox: Template:Xt/Sandbox featuring high-precision color and size examples. Greg L (talk) 06:18, 20 December 2008 (UTC)

Delete First sentence text from this article?

Above I respond to Noetica's general posting regarding the use of transclusion. Here I ask a non-transclusion question: Should we remove the discussion of First sentence content and format from this page altogether? It doesn't seem to fit with the other issues talked about on this page. And it does fit in wp:lead (where it already appears). So perhaps we should just remove it from this page. Your thoughts? Butwhatdoiknow (talk) 23:07, 15 December 2008 (UTC)

And that, B, is properly dealt with as a general matter – one of the overarching questions I refer to in the section above. It is a matter of coordination of content across MOS-pages, which happens only sporadically and adversarially as things stand. Specifically, though, I have no objection to this material being at MOS-central. I don't like the style, with footnotes. Other sections of the page don't do that, and it fragments a guideline so that it can't be perused as a whole. Yet again: that use of footnotes is a general issue, and it needs addressing as such.
–⊥¡ɐɔıʇǝoNoetica!T– 23:49, 15 December 2008 (UTC)
I am afraid that I was not clear: I am proposing that we remove the First sentences section from this article. Butwhatdoiknow (talk) 19:09, 16 December 2008 (UTC)
You were clear enough for me, B. And I gave a clear answer, surrounded by relevant context: "Specifically, though, I have no objection to this material being at MOS-central."
–⊥¡ɐɔıʇǝoNoetica!T– 22:15, 16 December 2008 (UTC)
I do. It is Wikipedia:Lead section material. If there is any transclusion, it should be from there to here, but there is no good reason for it to be here in the first place. Gene Nygaard (talk) 03:44, 23 December 2008 (UTC)
It looks like you, N, and I are the only two folks who are particularly interested in this issue. So let me put the question to you this way: Would you have an objection to removing this material from MOS-central? Butwhatdoiknow (talk) 19:05, 20 December 2008 (UTC)
I have no problem with removing it from WP:MOS. - Dan Dank55 (send/receive) 02:56, 23 December 2008 (UTC)

Last call. I'll delete it in a couple of days unless there is a meaningful objection to removing it. Butwhatdoiknow (talk) 23:43, 25 December 2008 (UTC)

Input methods for hard-to-distinguish characters

Could we please edit the MOS to specify that, where possible, the HTML entities &nbsp; and so on are used instead of their Unicode equivalents? Given that the 'insert' box at the bottom of the edit window puts in the Unicode characters for — and so on, it is not possible to say that this is mandatory, but when editing an article, particularly with a view to the GA or FA criteria, it is extremely annoying with standard fonts to tell the hyphens and dashes apart, and virtually impossible with the spaces. It is mainly the space and dash characters where this is a problem, and short of using a font like DPCustomMono2 (which still has problems with dashes), this can sometimes be a real nuisance. What are people's thoughts?— Kan8eDie (talk) 17:45, 22 December 2008 (UTC)

I used to use "&ndash;", then along came a bot and replaced all of them with "–", so I figured that the practice was to use symbols. — Cheers, JackLee –talk– 18:10, 22 December 2008 (UTC)
Precisely, and I find this very annoying. I am asking whether we could edit this policy, or if not perhaps someone could produce a custom font (along the lines of DPCustomMono2) to help distinguish these cases?— Kan8eDie (talk) 23:34, 22 December 2008 (UTC)
Couldn't you simply read the article on the screen to tell the difference between -, – and —? Physchim62 (talk) 23:55, 22 December 2008 (UTC)
  • I agree entirely with Kan8eDie here. Any time there is a special character—whether “Friendly”, Numerical, or Hex code—that not be easily distinguished from its regular counterpart when rendered in edit view, it should remain as code. This applies to non-breaking hyphen (hex = &#x2011;), non-breaking space (friendly = &nbsp;), as well as en-dash, and em-dash (which have vague differences). The virtues of saving (literally) 0.07 µ¢ of hard drive space for each occurrence and the advantage of making the edit view less visually cluttered is outweighed by the disadvantages. And what are those disadvantages? If a less experienced editor goes to our F-15 Eagle article intent on adding something, it helps if they can see many instances of F&#x2011;15 rather than F‑15. While the later hyphen is a non-breaking one, no one can tell. And when this happens, even experienced editors will often just pound out a regular hyphen on their keyboard rather than take a clue and copy/paste. Greg L (talk) 02:30, 23 December 2008 (UTC)
Look, Physchim62. I can't tell − from - from – on my edit screen. If they are juxtaposed with each other on the article page I can often tell them apart, if I look hard enough or blow up the font size far enough—remembering which is which is a different story. And I'll be damned if I'm going to do a preview and try to locate the place where it is on that page, and then go back to the edit screen and waste a bunch of time there looking for it again, every time I run across one of these characters on my edit screen. I doubt if many other editors will, either.
Strangely enough, contrary to what Greg says, I can easily tell ‑ from - on my edit screen (and with more difficulty after I save it, but only if they are both there and close to each other); now can anybody tell me why a non-breaking hyphen should look different from a regular hyphen?
But then, many of our prescriptions for one or the other, and accompanying spacing, are hogwash in the first place. In many cases "just pounding out a regular hyphen" is the proper thing to do. Gene Nygaard (talk) 04:24, 23 December 2008 (UTC)
  • What you're actually saying is that "[you]'ll be damned" to actually read the article to see where the problems are. If there are serious problems with dashes, you can see them on a first reading: if you can't do that, leave the job to somebody else as you're obviously not adapted for it. You can expect your 'comments' at various candidacies and reviews to be treated with the same contempt as you treat those who work to make things easier for real-life readers and editors. Physchim62 (talk) 19:51, 23 December 2008 (UTC)
  • I agree Gene; most of the time, a regular hyphen is the right thing to type. All I’m saying is that when it isn’t the right thing, or when a non-breaking space is the proper space to use—such as between the value and unit symbol in 25 kg, the special character should simply remain as code so editors following on our heels can see their special nature and emulate the technique. Saves effort. Makes the article better. That sort of thing. Greg L (talk) 06:33, 23 December 2008 (UTC)
If the reader can't actually see the difference between various hyphens and/or dashes, does the difference actually matter at all? In fact as far as the reader is concerned, does the difference even exist? I really think a case could be made that some of these "invisible" minutiae are not worth the effort, even discussing them is a waste of electricity and only serves to exacerbate global warming. Roger (talk) 15:45, 23 December 2008 (UTC)

(outdent)
No, that’s not the issue, Roger. Here’s the issue in a nutshell: It’s about being able to see the difference while in edit view (and you can’t see the difference when the actual rendered non-breaking space and non-breaking hyphen are used instead of their code). It’s not the difference in the appearance of these characters; it’s the difference in their behavior, which is substantial since they prevent line-end word wraps like these:

Faced with costly development period, the aircraft was variously designated F-
22 and F/A-22 during the three years before formally entering US Air Force…

and this one…

Initially introduce 2⁄3 of the quantity of water to the mixing container, then add 25
kg of KEIM Concretal ® -Mörtel and mix for 4 minutes to form…

So to ensure that other editors see that these special characters are used, we don’t want a bot replacing 25&nbsp;kg with 25 kg. The code for these hard-to-distinguish characters to show so other editors to take a clue to copy & paste. This part of my response is addresses the polite part of your post.

As for your final, impolite parting comment (the part where you put your foot in your mouth voluntarily: (“I really think a case could be made that some of these "invisible" minutiae are not worth the effort, even discussing them is a waste of electricity and only serves to exacerbate global warming”), these details we’re discussing are those that other editors here routinely take the time to get right so Wikipedia reads well as a high-quality product for the world to enjoy—you too, as you clearly aren’t tending to these details yourself. You’re welcome anyway. And if you *really* felt that even discussing this “minutiae” isn’t worth the effort, then why in the world would you ignore your own expressed value and choose to weigh in on the subject??? It seems that parting shot of yours was just an effort to demonstrate that you are some sort of *big picture* guy who can’t be bothered with trivial little points. Instead, all I gathered is that you don’t understand details that others are quietly taking care of behind the scenes and you only demonstrated your cluelessness about fine typography.

P.S. I’m an engineer; we tend to details. If anything works in this world, it is because engineers somewhere gave a crap to sweat the details and get something right. Your post reminds me of some managers I’ve met. Management sounds like a splendid career path for you. Next time, try checking your attitude at the door before entering. Greg L (talk) 21:29, 23 December 2008 (UTC)

I strongly disagree with this line of thinking. For an average editor, – and — are far easier to identify than &endash; or &emdash; For non-breaking spaces, it's not worth cluttering up the text with HTML code for the tiny bit of formatting niceness that the character delivers. This whole debate seems rather absurd to me. For example, why are we so scarred of – and —, but not I, |, and l or O and 0 (those are all different characters)? We don't need HTML to save us from the English language. Kaldari (talk) 21:59, 23 December 2008 (UTC)
  • Oh come-on Kaldari; you make no point at all when you rely upon hyperbole. No one said we need HTML to save us from the English language. To have fine looking typography and well laid-out pages, we need HTML and similar code. Until someone makes a text editor that understands intent better, typing “F hyphen 22” results in text that word-wraps in the middle of the expression. So one uses a non-breaking hyphen. This whole discussion thread is just about whether or not these special hex codes should be converted to the actual character. I’m not going to make a stink about it because the work I do on Wikipedia consistently uses these techniques. I just thought it would be nice if we didn’t hide these techniques from less experienced editors. Wikipedia would be better off when more editors adopt these techniques. Greg L (talk) 00:58, 24 December 2008 (UTC)
Simple. A good monospace font can easily tell I, |, 1, and l appart (if yours doesn't, get yourself a good programmers' font). By nature of being monospaced however it is not easy, if indeed possible in most fonts, to distinguish the dashes. I don't know what you are seeing when you edit, but this 'average editor' cannot spot that – is an en dash in the edit window. Either we should not waste time on the small differences, or be good and be consistent (i.e. consistently use some representation of the proper character instead of a plain hyphen). Since being good is 'right', we should do all we can to make it easy to see what has been entered, hence my call to use entities. The visual mess of reference templates makes editing articles tough, but we accept that it is needed, and the trouble of seeing entities in the wikitext we edit is so minor that I feel the benefits outweigh the advantages. Failing that, I suggest we whip up a version of DejaVu Mono with a couple of customised trouble characters and embed it on the edit page so that at least those 'in the know' trying to jump through the hoops for GA and FA criteria can see what is going on.— Kan8eDie (talk) 23:32, 23 December 2008 (UTC)
The trouble is that to most users and editors, HTML will be meaningless clutter - if you force people to use HTML markup to meet the intracacies of MOS, then most editors will feel its not worth the effort, thus reducing the chances of actually meeting MOS (even if much of MOS's requirements are irrelavant to 90% of readers).Nigel Ish (talk) 23:59, 23 December 2008 (UTC)
  • No one is *forced* to use it. MOS and MOSNUM don’t require the use of non-breaking spaces and hyphens. But by not having a bot change them from one of the three or four codes to the rendered character, we make it far more likely that other editors will copy the technique. This means that articles read better rather than looking broken up until a cleanup editor fixes it. Greg L (talk) 00:49, 24 December 2008 (UTC)

The original problems (specific and general)

I was led to this page because of objections to my removal of hyphens after -ly adverbs.
(See User talk:Wavelength#Hyphens - thanks for the ref.)
After several weeks of discussion, followed by a short respite, I have these questions:

  • Specifically, if I were now to correct again the hyphenated expression in Electric guitar#Sound and effects, paragraph 4, to "specially designed sound cards", would I have the support of the Manual of Style?
  • Generally, what exactly is necessary before the tag "under discussion" can be removed from Wikipedia:Manual of Style#Hyphens, subsection 3, point 4?

-- Wavelength (talk) 02:19, 23 December 2008 (UTC)

This section was previously the fifth subsection of another section, now archived at
Wikipedia talk:Manual of Style/Archive 106, section 16: "Hyphens after -ly adverbs (rationalised section)".
My questions have been answered at User talk:Wavelength#Your questions about MOS and hyphens
(permanent link: http://en.wikipedia.org/w/index.php?title=User_talk:Wavelength&oldid=260226642,
section 13, "Your questions about MOS and hyphens").
-- Wavelength (talk) 22:11, 26 December 2008 (UTC)

Article tone

There doesn't seem to be a section here on the appropriate tone for articles, and who the target audience is. I think those things ought to be defined. Is that included elsewhere? Some editors write as for a scientific journal. Their style is ultra-formal, argumentative, and beyond the comprehension of the average reader. I take the approach that someone who knows nothing about the subject should be able to understand every word of the article (assuming that person is high school age or above). Am I way off base here? ThreeOfCups (talk) 03:38, 29 December 2008 (UTC)

There's WP:MTAA, but I agree that mentioning those points here, too, could be useful. -- Army1987 – Deeds, not words. 11:10, 29 December 2008 (UTC)
That's a good guideline, and WP:JARGON is short and useful. I generally see article reviewers complain if it looks like you didn't even make the attempt to make it accessible, or if they couldn't get through the first paragraph, even if you did try. - Dan Dank55 (send/receive) 17:22, 31 December 2008 (UTC)

St. Louis-San Francisco Railway

Was the move of this to St. Louis–San Francisco Railway correct? It seems kind of silly, since it reads fine with the normal dash, and as far as I know the company just used a normal dash. (They usually called themselves the Frisco though, so it's hard to find, for instance, a map where they use the full name.) --NE2 20:15, 29 December 2008 (UTC)

It's still wrong: St. Louis – San Francisco Railway (there are internal spaces in the items, so the dash needs to be spaced too. Tony (talk) 02:38, 1 January 2009 (UTC)

Foreign words & Eng. trans.

MOS correctly suggests using italics for phrases etc., but in what order? Should we use "Syndicat des instituteurs du Dahomey (Teachers' Union of Dahomey)" or "Teachers' Union of Dahomey (Syndicat des instituteurs du Dahomey)"? I was taught the former, but that may be a Linguistics thing. Tks Ling.Nut (talk—WP:3IAR) 21:47, 29 December 2008 (UTC)

I see both, a lot, on and off Wikipedia, and my sense has always been that the first phrase is the one you want your readers to focus on. There's no guidance on this in American style guides that I'm aware of. - Dan Dank55 (send/receive) 17:15, 31 December 2008 (UTC)

A sentence that needs revising

In the Subsection Wikipedia:ENGVAR#Formatting the sentence following sentence 'Do not place a currency symbol after the value (123$, 123£, 123€), unless the symbol is normally written as such. Do not write $US123 or $123 (US)' should be changed to Do not place a currency symbol after the value (123$, 123£), unless the symbol is normally or in some nations written as such (123€). Do not write $US123 or $123 (US) dues to the fact that the Euro in some nations is placed after the number in others it is before it is therefore not a suitable exampled of not what to do . Any thoughts ?安東尼 TALK 圣诞快乐 22:50, 30 December 2008 (UTC)

This is the English Wikipedia, so we should be use the format used in English. I looked up, and according to our article Linguistic issues concerning the euro English uses €1.23 (and so do Irish and Maltese, so it is the only format used in English-speaking countries). I don't like that (it's inconsistent with 1.23 m for metres), but c'est la vie. -- Army1987 – Deeds, not words. 01:37, 31 December 2008 (UTC)
Okay I just thought it needed brining up. D'accord et Merci 安東尼 TALK 圣诞快乐 13:33, 31 December 2008 (UTC)

(Italian sucks in many other respects, but at least you can write "Sono alto 1,88 m e ho pagato questo 1,88 €" without any useless inconsistency. Now I've discovered that in English one must remember which symbols go before and which go after, too. -- Army1987 – Deeds, not words. 13:49, 31 December 2008 (UTC))

Display prefences for coordinates

Please be aware of an attempt to change the way coordinates are displayed by {{Coord}} (and thus in other templates which call it). This is being falsely presented as a bug in that template, used in around a quarter of a million instances, apparently in order to circumvent the need to obtain consensus to make such a change. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:44, 1 January 2009 (UTC)

Adding 2 policy pages to WP:Update

Please see WP:VPP#Adding 2 policy pages to WP:Update. - Dan Dank55 (send/receive) 15:09, 3 January 2009 (UTC)

Eyes needed

...at WT:PERFECT. I reverted Andy's edits, and I'm pretty sure he thinks I was acting improperly in a number of ways. Footnote: even though we get a fair amount of traffic in WT:MOS, we can go for months with no discussion and with no one but me checking the diffs in many of the other general style guidelines. Andy is claiming, quite correctly, that if it's just me arguing one side, that's OWNership, at least in appearance if not in fact, so I need to step back. - Dan Dank55 (send/receive) 02:44, 4 January 2009 (UTC)

Per Andy's talk page, I've redeemed myself, but we still need someone to argue the case. If we can't get at least 2 people involved when there's a challenge to a general style guideline, then it would be better to delete the cat than to let pages change without comment. (And this isn't just a style problem, even major changes to policy sometimes go undiscussed for months ... did you know that WP:BOLD doesn't apply to policy any more, and hasn't since July? Wikipedia is doing better with content these days, but where have all policy fans gone?) - Dan Dank55 (send/receive) 19:14, 5 January 2009 (UTC)

I notice that the collapsed "Support Wikipedia: a non-profit project. — Donate Now" header at the top of all Wikipedia pages uses a spaced em dash, even though WP:DASH outlaws this. Is that odd? —TedPavlic | (talk) 18:14, 5 January 2009 (UTC)

So does the bloody {{mdash}} template. Of course it's a non-breaking space, which doesn't make any difference when a regular space appears before the template half the time, just creates a wider gap. By 2010 you'll be able to drive a compact car between the nearest words. — CharlotteWebb 21:32, 5 January 2009 (UTC)
I'm a fan of having a template that places an NBSP before an en dash, but that template should be called {{mdash}}. That is, nowhere on wikipedia should there be examples of spaced em dashes (except for examples of what not to do). So maybe {{ndash}} should be renamed {{mdash}} and people can decide whether they want to use an &mdash; or a {{ndash}} (which are functionally equivalent). —TedPavlic | (talk) 01:34, 6 January 2009 (UTC)

RfC for WP:BOOSTER

There is a request for comment about whether or not WP:BOOSTER documents a standard consensus and good practice that all editors and school/college/university articles should follow as an official policy or guideline. Madcoverboy (talk) 18:59, 31 December 2008 (UTC)

I'd like to wait on the results from your RfC and poll going at WT:UNI first; those are the people I would turn to on this. - Dan Dank55 (send/receive) 02:33, 1 January 2009 (UTC)

For me it seems superfluous. There is already a policy about neutrality, and another about articles being based on verifiable references. Perhaps I am missing something? Stealthaxe (talk) 05:25, 7 January 2009 (UTC)

Web Content Accessibility Guidelines

Should Wikipedia be working towards meeting the W3C's Web Content Accessibility Guidelines? Please join discussion at Wikipedia talk:Accessibility#WCAG 2.0. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:24, 6 January 2009 (UTC)

Ongoing hidden content discussion

Talk:Alexander Alekhine#Hidden solutions in diagrams: a number of articles on chess players and chess tactics include 'problems', where a chessboard is shown midway through a game, there being an optimal set of moves for one or other side thereafter. The captions on these pseudo-images include the sequence of moves, but hidden inside collapsible sections (eg). I removed the hidden styling citing both accessibility and 'not censored' concerns, but was reverted. Comments are appreciated. Happy‑melon 21:35, 6 January 2009 (UTC)

Possessives of proper names

According to most style manuals (Chicago, Prentice Hall, McGraw-Hill), proper names take 's in the possessive, even when they end in sibilants. So it's Brahms's, Glass's, and so on.

There has been some contention about this on a number of pages recently (see discussion here, so, if no one makes any suggestions in the next couple of days to the contrary, I will update the MOS section on possessives. Regards, --Ravpapa (talk) 07:05, 5 January 2009 (UTC)

just for convenience, here's a link to the pertinent section of the MoS: WP:Manual_of_Style#Possessives. the part about the possessive form of nouns ending in sibilants is currently extremely unclear and in need of rewriting, no matter what the consensus is on what form is preferred on wikipedia.

:*i support the suggestion that the apostrophe-s form should be adopted (including for "classical/Biblical" names): Jones's, Moses's etc are clearer than the apostrophe-only forms. Sssoul (talk) 07:29, 5 January 2009 (UTC) edit: in light of the discussion below, i'm suspending my "vote" until Ravpapa clarifies whether he/she's retracting the proposal to make the apostrophe-s form the wikipedia-wide standard. Sssoul (talk) 21:13, 5 January 2009 (UTC)

  • I was taught in school that no s needed to be added after the apostrophe for the possessives of nouns ending in the letter s. For instance Jones' was preferred and not Jones's. Then again, I graduated from high school in 1976!--jeanne (talk) 12:51, 5 January 2009 (UTC)

jeanne, you are still a mere babe in arms compared to some of us. We all, I think, learned in high school that there is no 's for words ending in sibilants. But there is unanimity among style manuals today (well, at least those I know) that proper nouns take the 's no matter what. --Ravpapa (talk) 13:09, 5 January 2009 (UTC)

Do you have a current online subscription to Chicago, Ravpapa? 7.17 says "The possessive of most singular nouns is formed by adding an apostrophe and an s", and 7.19-7.22 give 4 classes of exceptions to that rule, roughly: 1. it looks like a plural (politics'), 2. two or more syllables that ends in an eez sound (Euripides'), it ends in an unpronounced s (Descartes') (that one's optional), and "For ... sake" expressions. An alternative to these rules in 7.23 is to omit "the possessive s on all words ending in s". - Dan Dank55 (send/receive) 14:21, 5 January 2009 (UTC)

I don't have an online subscription, and I am probably hopelessly out of date on these matters. My copy of Chicago is from 1993, my McGraw-Hill is from 1989, my Words into Type (does anyone use that anymore?) is from 1974. I have a bunch of others (Turabian, Strunk and White, Microsoft), but all at least 15 years old. Back in those days, we all wrote 's after proper names, but times change. I have no strong feelings about it one way or another, I just think we should be consistent. Even a statement that "you can do it this way or that way, just do it the same way throughout the article" would be fine with me. Age has mellowed me a lot. --Ravpapa (talk) 16:56, 5 January 2009 (UTC)

"you can do it this way or that way, just do it the same way throughout the article" is what the WP MoS currently says, albeit not at all clearly. Ravpapa, do i understand properly that you're no longer advocating changing the MoS to a clear preference for the apostrophe-s form? (and by the way: as long as the choice is up to the editors of a given article, there was no justification for the Richards/Watts/Jones edits that prompted this discussion. but anyway.)
meanwhile: thank you Dan for posting that clause from Chicago - that seems way overelaborate for wikipedia purposes! it seems like the viable options are:
  • 1] adopt apostrophe-s as the possessive for all nouns, whether or not they end in s: Jones's dog, Descartes's birthday, Euripides's wife
  • 2] adopt apostrophe-alone as the possessive for nouns that end in s: Jones' dog, Descartes' birthday, Euripides' wife
  • 3] accept either of the above as long as they're used consistently throughout a given article (ie, the current policy, but formulated way more clearly)
i personally prefer 1; until yesterday i was sure 2 was the wikipedia policy, so obviously i can live with that; and 3 is fine with me as long as it isn't misread as a basis for making arbitrary changes to articles. Sssoul (talk) 17:45, 5 January 2009 (UTC)
Me too :) [My comment got pushed down; "me too" was in response to "Age has mellowed me a lot."] I don't have much intelligent to say here, just a caution that we not let threads about punctuation (I suppose including apostrophe-s) predominate, because people grumble and stop reading, and also because we can't fix on Wikipedia what isn't fixed in the world. We're in a time of transition to more and more self-publishing, a trend in which Wikipedia is front-and-center. Editors sitting around copydesks like nuance, for instance the nuance of using apostrophe-s in cases where people are most likely to actually pronounce the s; that kind of thinking shows to their peers and their readers that they're on the ball, that they have a fine sensitivity for language. Self-publishing writers generally take the attitude: nuance be damned, I want to express myself without getting a PhD in punctuation-ology. So we've got a majority of writers now insisting on and following simple rules, for instance for whether singular possessive proper names ending in a sibilant sound take apostrophe-s. The problem is that half are insisting on a simple rule of "always" and half are insisting on a simple rule of "never"! It will be a little while before one side or the other wins, so I don't think a hard rule on Wikipedia is useful; either will turn off a significant number of skilled writers. - Dan Dank55 (send/receive) 17:14, 5 January 2009 (UTC)
so Dan, could you propose a clear wording for what you feel the wikipedia MoS ought to say about it? thanks Sssoul (talk) 17:45, 5 January 2009 (UTC)
ps: if Ravpapa is indeed retracting the proposal to make apostrophe-s the standard for wikipedia, the RfC can probably be closed - all that's really needed is a clearer formulation of the existing policy of "either way is okay". Sssoul (talk) 17:59, 5 January 2009 (UTC)
Let's aim for consensus among style manuals and Wikipedians. Unfortunately, in this case, there are a lot of links (and now there's one more!) I'll re-read them all if one or two others will read them with me. Apostrophe, WP:MOS#Possessives, WT:Manual_of_Style/Archive_92#Possessives of proper names ending in "s", WT:Manual_of_Style/Archive_100#Singular possessives ending in "s", WT:Manual_of_Style/Archive_102#Possessives, WT:Manual_of_Style/Archive_104#Possessive, and WT:Manual_of_Style/Archive_105#Possessives of common nouns in s. - Dan Dank55 (send/receive) 03:50, 6 January 2009 (UTC)

(outdent) thank you Dan - i'll try to help out. WT:Manual_of_Style/Archive_92#Possessives of proper names ending in "s" concludes with a recommendation to accept both versions, as long as consistency is maintained within a given article; i'll try to find time to wade through some more of those later today. meanwhile, should we close the RfC, at least until it's clear whether any radical change to the MoS is really being proposed? Sssoul (talk) 06:02, 6 January 2009 (UTC)

Thank you Dank55 for the enlightening references. The article on Apostrophe was particularly helpful: it clarified just how muddled the picture is. In light of all this, I suggest we add something like the following to the section on possessives:
Kilometers of verbiage have been written on the proper way to write the possessive form of proper nouns ending in s. See, for example, Apostrophe. Here at the Wikipedia, we tend to agree with the majority of style manuals that the possessive form of proper nouns ending in a sibilant should be written with an 's; for example, "Jones's", "Glass's", and so on. But we are by no means autocratic on the matter. The main thing is, make sure you use a form consistently throughout an article; don't write "Glass'" the first time and "Glass's" the second.
--Ravpapa (talk) 06:15, 6 January 2009 (UTC)
Ravpapa, I'm sympathetic to the reasoning behind "kilometers of verbiage", but that won't work. I could go with "When to include the s after the apostrophe is an unsettled question, even in widely-followed style guides. Most style guides at least agree on ...; otherwise, aim for consistency within each article." - Dan Dank55 (send/receive) 15:37, 6 January 2009 (UTC)
in light of that, i'm closing the RfC - it doesn't seem necessary, since no radical alterations to the guidelines are now being proposed. the wording of the clause in the MoS should be simple and direct. i'll try to come up with a proposal later today. Sssoul (talk) 07:15, 6 January 2009 (UTC)
okay, here's a first try at what i would consider clear, simple and direct wording:
The possessive of a singular noun is formed by adding an apostrophe and an s (my daughter's achievement, the boss's wife). For a singular noun ending in s, there are two schools of thought:
  • add just an apostrophe: James' house, Euripedes' plays, Moses' early life, Brahms' music
  • add an apostrophe and an s: James's house, Euripedes's plays, Moses's early life, Brahms's music
Either of those forms is acceptable in Wikipedia articles, as long as consistency is maintained within a given article.
i'd put a footnote after "two schools of thought" to point out the relevant links that Dan dug up; there's no need to go into all the gory details in the MoS itself.
is it also worth adding a short statement to the effect that once an article consistently uses one or the other of these forms, it's not appropriate to change it without making sure first that there's a consensus among editors who work on/watch over the article to support such a change? that should go without saying for *any* style points where there are two correct/accepted options, but maybe it's worth stating it anyway. Sssoul (talk) 16:17, 6 January 2009 (UTC)

Sounds good to me. --Ravpapa (talk) 17:12, 6 January 2009 (UTC)

I would like to reiterate my gentle plea for common sense: all singular names, whether it is John or Charles or what have you, should end with an apostrophe s to denote the possessive case. Somewhere in a time, long long ago, long before Wikipedia was founded, someone began a meme in which it was decreed that Charles (for example) should not get an apostrophe s simply on aesthetic grounds. But it seems to me that the issue here shouldn't be aesthetics, but whether or not Charles possesses something. If he does, such as a book, then it's Charles's book. Incidentally, and I could be mistaken, I think there's no quarrel about this with the Brits. I subscribe to The London Review of Books and The Times Literary Supplement, and they regularly use the apostrophe s. In the meantime, I see that Roland Burris's claim to take his seat in the senate was rejected today. Mysloop (talk) 18:52, 6 January 2009 (UTC)

Mysloop, have you looked at any of the archived discussions that Dan provided links to (above)? i think you'll find them enlightening: an individual personal preference isn't sufficient grounds to make the apostrophe-s form the only acceptable one on wikipedia; you need a good wide community consensus to make that kind of change to the MoS. if you want to see if you can get a consensus on it, i suggest re-launching an RfC on this discussion. or you can agree to leave the choice up to the editors of individual articles, and make your "gentle plea for common sense" on the talk pages of articles that you contribute to. Sssoul (talk) 19:09, 6 January 2009 (UTC)

Ssoul, no, I haven't looked at those discussions yet. I ought to. In the meantime, do you recommend that I continue my edits (I'd like to call up some other entries) and just take the responses I might get on a case-by-case basis? Thanks for your advice. Mysloop (talk) 23:28, 6 January 2009 (UTC)

Mysloop, i've replied to your question on your talk page; this page is for discussion of the MoS.
one further bit of finetuning might be: i don't see anyone recommending the apostrophe-only form for words ending in ss - Glass's music is the only correct form. so the wording of the MoS might be:
The possessive of a singular noun is formed by adding an apostrophe and an s (my daughter's achievement, the boss's wife, Glass's music). For a singular noun ending in one s, there are two accepted forms:[1]
  • add just an apostrophe: James' house, Euripedes' plays, Moses' early life, Brahms' music
  • add an apostrophe and an s: James's house, Euripedes's plays, Moses's early life, Brahms's music
Either of those forms is acceptable in Wikipedia articles, as long as consistency is maintained within a given article. Once an article consistently uses one of these forms, it should be changed only on the basis of a clear consensus among the article's editors.
[1] For details on these two forms and the rationale for their use, see Apostrophe, WT:Manual_of_Style/Archive_92#Possessives of proper names ending in "s", WT:Manual_of_Style/Archive_100#Singular possessives ending in "s", WT:Manual_of_Style/Archive_102#Possessives, WT:Manual_of_Style/Archive_104#Possessive, and WT:Manual_of_Style/Archive_105#Possessives of common nouns in s.
does that cover it, and is it clear and straighforward enough for MoS purposes? Sssoul (talk) 07:36, 7 January 2009 (UTC)

The horse is dead. Enough discussion. Sssoul, go ahead and make the change. Try to keep it pithy. --Ravpapa (talk) 12:29, 7 January 2009 (UTC)

There's no one answer that's going to make everyone happy. Some people will have problems with footnotes that point to archives, but only because we don't generally do that; we would usually point to the links that were pointed to in the archives. I don't see any harm in it. - Dan Dank55 (send/receive) 15:38, 7 January 2009 (UTC)
all right - hope it looks okay now. thanks for the help clarifying this point. Sssoul (talk) 16:32, 7 January 2009 (UTC)

Well done. --Ravpapa (talk) 17:54, 7 January 2009 (UTC)

I tweaked to "For details on these two forms and the rationale for their use, see Apostrophe. Evidence that this issue is largely unsettled among professional style guides and among Wikipedians can be found in the archives at ...". It wouldn't bother me at all if anyone wants to fiddle with this footnote. - Dan Dank55 (send/receive) 00:04, 8 January 2009 (UTC)

RfC: Small grammatical error - quote vs. quotation

This is a commentary on the MoS page itself.

There seems to be an error on the MoS page where the word quote is used and the word quotation is what should be used. The page also says to make sure that there is consensus on the matter before changing anything here. There are actually a couple of places where this word is misused. The first example noticed starts like this: 

    Attribution 
    The author of a quote of a full sentence or more should be named;

Does anyone care to comment on that please ? Stealthaxe (talk) 05:21, 7 January 2009 (UTC)

I couldn't verify that distinction at dictionary.com, which defines the noun sense of the word "quote" as "a quotation". Perhaps you know something I don't. Art LaPella (talk) 05:41, 7 January 2009 (UTC)
Perhaps I've been out of school too long :-). I suppose if quote can now mean a quotation then there is no error. However I do still feel that there is an inconsistancy where sometimes quotation is used and sometimes quote is used. Also I noticed that quotes was used instead of quotation marks. Now I'm wondering if that is also allowed in standard usage these days. Online Merriam-Webster says it's ok. Ah, the dynamic of language. (graduated 1981)

Stealthaxe (talk) 07:00, 7 January 2009 (UTC)

Green text color can't be seen by the color-blind

For readers that have color blindness, using a green colored font is not a good idea, for emphasizing text. Can someone change this? Thanks --Funandtrvl (talk) 20:32, 6 January 2009 (UTC)

See Color Vision - by Cal Henderson and Colors for the Color Blind.
-- Wavelength (talk) 21:41, 6 January 2009 (UTC)
  • The accompanying change in typeface to a serif typestyle, (example text) is to make it fully accessible for those with red/green color blindness. Actually, the change in typeface works for those with total color blindness, which makes it more accessible than the blue text that Wikipedia uses as the only clue that something is a link. The important point to remember about color blindness and accessibility is that editors must not use color alone—especially red and/or green—to convey an important distinction, like “this is good” but “this is bad” or “GOOD/BAD”. Verboten.

    The color is to provide yet another way to distinguish example text for normal-sighted individuals. This is similar to the way chemistry wash bottles are in wet labs (where I once spent some time in a ‘former life’): the isopropanol wash bottle has a blue top, ethanol = orange top, methanol = green top, acetone = red top. There is a big difference between acetone and methanol (red/green). If one is color blind, you read the wording on the bottle. If you have normal color vision, you have both indicators, where color is the quicker one. To this day, I still see “red” when I think of acetone. It’s the same for cylinders of compressed hydrogen; they come in red cylinders. Oxygen (big difference) is green. Of course, they are labeled with their contents too. Color is simply assistive. Same here. Greg L (talk) 22:30, 9 January 2009 (UTC)

Weather templates

There's a discussion at Template talk:Infobox Weather#This template or template:Climate_chart about the use of {{Infobox Weather}} vs. {{Climate chart}} which both present the same kind of data but in completely different formats (one is a table of numbers with different color backgrounds to indicate coldness to hotness where the other is a bar chart). If anyone here has MoS reasons one of these should be preferred over the other please comment (there, not here). Thanks. -- Rick Block (talk) 03:33, 9 January 2009 (UTC)

Other English-language style guides

Editors of the English-language Wikipedia may be interested in examining other English-language style guides, and possibly adding some of them to their collections. Comments are welcome.






At Citizendium, there is CZ:Manual of Style - Citizendium,
but what seems more like a style guide is CZ:Article Mechanics - Citizendium.


At Knol, the closest thing to a style guide that I could find is
Best Practices: Writing Good Knols - a knol by Knol Help.
-- Wavelength (talk) 07:00, 15 December 2008 (UTC)

Here are some more.

-- Wavelength (talk) 19:56, 15 December 2008 (UTC)

Expression of interest, more links

Valuable work, Wavelength. I intend to look through those when I have time. Earlier you wanted to discuss the idea of documenting sources for MOS. I thought at the time that it was not a bad idea. Myself, I'd have little trouble doing so: I have an extensive collection of guides to punctuation and style in general. But in fact the task is special, here at MOS. It isn't like an article; other guidelines, and even Wikipedia polices, don't provide such documentation. We ought to be able to justify here on the talkpage what we say in MOS. Quite often, though, that justification will go beyond existing guides and have more to do with discovering solutions tailored for the online WP environment. No existing guide does that. We are doing it! I'm the last person to advocate setting aside the major or even lesser guides as respectable precedents. But they don't address what we must. I may have more to say when I've looked through these online resources.
–⊥¡ɐɔıʇǝoNoetica!T– 22:50, 15 December 2008 (UTC)
Thank you, Noetica, for your interest. The section on documenting sources is now archived at
Wikipedia talk:Manual of Style/Archive 105 (section 35: "Guideline-by-guideline citation of sources").
Also, here is another link.
-- Wavelength (talk) 01:15, 16 December 2008 (UTC)
One can see previous versions of http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style
at http://web.archive.org/web/*/http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style.
-- Wavelength (talk) 00:05, 27 December 2008 (UTC)

Style guide abbreviations, spoken article guidelines, future representation guidelines

  • Beside each guideline in the English Wikipedia's Manual of Style, there can be one or more abbreviations indicating the style guide(s) supporting the Wikipedia guideline. For each guideline tailored for Wikipedia, there can be the abbreviation "WP".
  • One area where guidelines can be tailored for Wikipedia is that of Wikipedia:Spoken articles (Category:Spoken articles).
  1. Have any guidelines been established so far? (If handwriting is to typing as speaking is to speech synthesis, then speech synthesis may be easier to analyze and manage than natural speaking.)
  2. Should a speaker observe American and British English pronunciation differences or other pronunciation differences at the time of recording an article?
  3. Should revisions be made by the original speaker of an article?
  4. Is it acceptable for an addition to be spliced onto/into a previous version, or for portions (corresponding to deletions in the text) to be erased from the recording; or should the entire article be spoken again?
  5. Are there guidelines for speed, pitch, intonation, volume, pausing, or other features of discourse?
  6. Does someone "proofread" ("proof-listen to"?) spoken articles?
  7. Is Wikipedia prepared for vandalism of spoken articles?
Additional ideas and information might be available from the organization Toastmasters International.
-- Wavelength (talk) 20:45, 2 January 2009 (UTC)
[I re-organized my message and changed a few words. -- Wavelength (talk) 00:41, 5 January 2009 (UTC)]
I have just found the page Wikipedia:WikiProject Spoken Wikipedia/Recording guidelines.
-- Wavelength (talk) 05:29, 6 January 2009 (UTC)

Some non-Wikimedia wiki style guides

Here are style guides for some of the wikis listed at List of wikis.

-- Wavelength (talk) 04:55, 9 January 2009 (UTC)

Links for more style guide information and some university style guides

-- Wavelength (talk) 17:13, 13 January 2009 (UTC)

Mixed and non-capitalization in personal names

A request for comment has been opened at the talk page of WP:MOSCL, on how the Manual of Style should handle mixed and non-capitalization in personal names. – Cyrus XIII (talk) 20:20, 12 January 2009 (UTC)

American (and Canadian) geographic name MoS

What is the MoS for names of cities in the US. Would it be Lansing, Michigan or Lansing, Michigan, USA. For the longest time I've included the USA in the biographical data of hockey players, vaguely on the memory that MoS required it to a provide a less NA-centric view. I got someone removing them now. There's no edit war or anything, I just trying to find an existing MoS on the subject. Can someone provide a link if there is one on the subject? ccwaters (talk) 16:24, 13 January 2009 (UTC)

There isn't one. Lansing, Michigan would be fine unless a reader needs clarification, which we will find out about if somebody asks a question. (Unlikely on hockey articles, I should think.) Septentrionalis PMAnderson 21:58, 14 January 2009 (UTC)
Ok, i don't think there very many hockey players from either Georgia, so I guess its not a problem. ccwaters (talk) 13:37, 15 January 2009 (UTC)
Oh... how about Lansing, Michigan vs Lansing, Michigan? ccwaters (talk) 13:38, 15 January 2009 (UTC)
My rule of thumb is to avoid the country-name unless you really think many anglophone readers wouldn't know. I expect anglophones who are literate enough to read a WP article to know that Michigan is in the US. They can find that out mighty quickly by linking to the town, anyway. And you certainly don't link to "US" or (the old-fashioned) "USA". Tony (talk) 14:27, 15 January 2009 (UTC)
I agree with Tony with regard to not including US. I prefer the single link Lansing, Michigan; the alternative is pointless, since Lansing is a redirect to Lansing, Michigan anyway. Following Tony's lead, I wouldn't normally link very well known places like US or Canada, even if the presence of the country name were justified. jimfbleak (talk) 15:29, 15 January 2009 (UTC)

Which has precedence?

Whichever it is, surely Wikipedia:Mos#Images and Wikipedia:Layout#Images ought to be saying the same thing?

One says: "Where it is appropriate to force size, images should generally be no more than 550 pixels wide, so that they can be comfortably displayed on 800x600 monitors."

The other says: "An image should not overwhelm the screen; 300px may be considered a limit, as this is approximately half Wikipedia's text space's width on a 800x600 screen."

--Malleus Fatuorum 13:59, 14 January 2009 (UTC)

Wikipedia:Layout#Images cites Wikipedia:Mos#Images as a "main" article, which suggests Wikipedia:Mos#Images is the top authority. Wikipedia:Mos#Images is not quite as clear as it should be, as it assumes that the "thumb" option will be used to provide a caption and, in most cases, a default size. As a result, its comments are preceded by "Where it is appropriate to force size ...". I think it would be clearer if it stated separate max output sizes for lead and other images up-front, so that the comments on forced sizes are subject to that. Considering how controversial size forcing has been and how changing techs make us re-examine such guidelines frequently (e.g. wide screens, hand-helds), it might be best for Wikipedia:Layout#Images so say nothing about sizes except "see Wikipedia:Mos#Images". --Philcha (talk) 15:09, 14 January 2009 (UTC)
I think that would be sensible, for the layout page to discuss image layout only. What isn't sensible, IMO, is for information on sizing to be duplicated, because these kinds of discrepancies then become inevitable. But this is wikipedia; can anything be changed? --Malleus Fatuorum 15:18, 14 January 2009 (UTC)
Well yes, surprisingly enough it can (sometimes, and with a lot of effort...) I'd be in favour of putting everything about images on one page, and having MoS just link to there (or summarise it, as it does with some other pages). I don't think people instinctively come to the MoS when they want to know what to do about images.--Kotniski (talk) 15:59, 14 January 2009 (UTC)
Presumably we can agree though that the information they're given ought not to depend in which page they see first? --Malleus Fatuorum 16:22, 14 January 2009 (UTC)
We seem to agree that a single source of info for editors would be good, to minimise searching and maximise consistency. I've been struck before by the difficulty of finding good info about how to use images - Help is useless, it returns one page that's mainly about avoiding copyright violations (from Meta, so we can't even edit it to point to useful info) and then lots about specific techniques. Does anyone have any ideas on how to make the type of guidance we've just been discussing appear high in the Help results for image? Then whatever page that is, we can incorporate or link to other relevant material. --Philcha (talk) 16:34, 14 January 2009 (UTC)
Yes, you can; edit the meta-version with meta accounts. Septentrionalis PMAnderson 22:06, 14 January 2009 (UTC)
Can we make the Meta's text link to en.Wikipedia guidance on images? If so, it's an obvious portal for all things image, as it comes top of a Help search. --Philcha (talk) 22:32, 14 January 2009 (UTC)
Should be able to; I don't edit meta much, but [[:en:Wikipedia:Layout#Images]] ought to work. Septentrionalis PMAnderson 05:31, 15 January 2009 (UTC)
Are the managers of Meta likely to object?
If it's OK, all we have to do(!) is work out how we structure the actual info, and thne link it into the Meta page. --Philcha (talk) 09:04, 15 January 2009 (UTC)

(unindent) Not sure about this suggestion. If we're talking about a page with en.Wikipedia's guidelines on images, then it has to be on en.Wikipedia and not at meta. Anything we say at meta has to be applicable to all projects, so basically it's software documentation only.--Kotniski (talk) 12:12, 15 January 2009 (UTC)

That's what I was concerned about. So it looks like the Meta page cannot be the "all about images portal".
I think the next question is how to ensure whatever we put together gets high placement in the search results at Help. By "high" I mean 1st 3 items, and above all more specfic topics (in the results I'm seeing right now, #2 is Help:Navigational image).
Help:Contents/Images and media looks like a portal page already, and appears as #3 in the results.
Would this be a good time to start thinking about the range of topics to be included, what info should be on what page, and what page(s) shoud appear in the "portal"? --Philcha (talk) 12:33, 15 January 2009 (UTC)

Evidence of a dialectical process in the text of articles -- to be discouraged?

The dialectical process whereby an article evolves in Wikipedia can often be seen, fossilized in the text of an article. I wish to discuss this, and in doing so bring to light what I believe should be an important style guideline for editors, that in seeking to improve an article, contributors should aim to produce a text which is insofar as possible independent of that dialectical process by which it is reached.

I will introduce my point by a trivial example. The article on Peter and the Wolf contains a brief list of the instruments associated with the various characters in the story. A side-by-side view of my edit and a prior version, shows, I believe, the type of editing I am discussing. The earlier and latter lines are reproduced below.

The first version is suggestive of an early contributor having stated that the hunters are represented by percussion, and a second contributor expanding on this. It suggests that the second contributor has added the two parenthetic items of text, rather than replacing the existing text with a new one that includes both pieces of information. I would contend that this is not desirable, as it is not concise, and it distracts from the informative value of the article, by shifting the readers focus to the process by which the text has evolved. The purpose of my edit is fairly obvious, in seeking to eliminate this.

I would like to invite comments, then, on the following: firstly, the assertion that the second style is preferable, for the reasons of brevity, and of focusing on the information that the article seeks to convey, rather than the process by which the article evolved; secondly, that a style policy be enacted to this effect, such that editors wishing to improve the text can simply refer to it in their edit descriptions. I realise that where subject matter is contentious, this process will become all the more difficult, but I would contend that it is in these circumstance in particular that it is important that the article reflects both the consensus, and disputed viewpoints in a clear editorial narrative, rather than reflecting the, perhaps heated, process whereby the views have been reached.

Should a conclusion be reached that such a policy is desirable, I would be happy to draft such a policy, or not, as the community sees fit. I open the matter to the floor.

--Che Gannarelli (talk) 12:20, 15 January 2009 (UTC)

I agree that the second version is desirable. Actually this is quite a common phenomenon I've noticed on occasion too. I don't thinnk we need a new policy for this though, just mention it at the appropriate place in one or more existing policies/guidelines. --Kotniski (talk) 12:35, 15 January 2009 (UTC)
I dont' think a separate guideline is required - we already have too many guidelines! Re the "Hunter's theme" used as an example by Che Gannarelli, its main problem, and that of the whole Peter and the Wolf article, is non-compliance with WP:V. Both versions of the "Hunter" text imply that the woodwinds and percussion play the same theme (which is a little surprising), and claim that these pieces of music represent the hunter. WP:RS must be cited to support both of these points. If there is any debate among musical experts about either of these, the article would have to point this out, naming the sources on each side of the dedbate, and this would introduce "dialectical" elements - but from the sources, not from the opinions of editors. OTOH if it's gnerally agreed that they represent the hunter, you just say "Theme X represents the Hunter" and cite a bunch of sources. All of this follows from WP:V and WP:NPOV, and is not really a matter for WP:MOS. --Philcha (talk) 12:47, 15 January 2009 (UTC)
I'm not sure that there aren't separate issues at work here. In matters of contention it is especially important to produce a text that presents all verifiably held and significant views on the subject within a concise, cohesive, subject-focused narrative. A text which instead reflects not a narrative on the subject, but the process by which individuals introduce their contributions may just as easily be produced, and should be avoided. While this is most likely to occur in contentious areas, it need not only occur in such, it does not necessarily arise from a lack of verifiability in individual contributions, nor does it necessarily reflect a bias, but perhaps a limited area of knowledge from which to contribute. I will happily accept that there is no need to introduce a guideline here, but I don't believe that it's at all correct to say that the concerns I raise arise from non-application of WP:V, or WP:NPOV.--Che Gannarelli (talk) 16:01, 15 January 2009 (UTC)
IMHO the Talk page is where the dialectical process should happen. But there is a tag - {{Cleanup}} - for situations like this. Roger (talk) 07:07, 16 January 2009 (UTC)
Or even better - actually clean it up yourself;)--Kotniski (talk) 07:04, 16 January 2009 (UTC)
Certainly it should happen on the talk page. That much is clear. What is also clear, is that the text of an article nonetheless sometimes reflects this process. As shown in the above example, my response is indeed to clean up such articles when I see them. I just wondered whether there ought to be a policy one could point to in doing so. The consensus appears to be 'not', and I'm content with that. --Che Gannarelli (talk) 10:37, 16 January 2009 (UTC)

Abbreviation of large number ranges

I've search the Manual of Style, and I cannot find anything about how (or whether) to abbreviate large number ranges. For example, from the Saltholm article: "10-12,000 ducks breed and graze on Saltholm during autumn and late winter/spring."

Now, in this case, an educated person can guess that that "10–12,000" probably doesn't mean between 10 ducks and 12,000 ducks. But in cases where there is less certainty about variability, there could be ambiguity.

A little guidance would be useful.

Misha Vargas (talk) 08:40, 16 January 2009 (UTC)

Don't encourage the would-be legislators, we have enough already! In the example you gave, I think "10,000 to 12,000" is probably best - "between ten and twelve thousand" is longer but has the same ambiguity you mentioned. Hope this helps. --Philcha (talk) 09:08, 16 January 2009 (UTC)
How 'bout 10–12 thousand ducks? -- Army1987 – Deeds, not words. 12:01, 16 January 2009 (UTC)
I'd not thought about that option: it seems perfectly clear to me, both intuitively and through the rule that the en dash would be spaced if either or both items had internal spaces (since it's unspaced, the two items are "10" and "12", not "10" and "12 thousand"; cf. "10 – 12 thousand", which is wrong or at least confusing). Tony (talk) 12:06, 16 January 2009 (UTC)

Dispute at WP:MOSICON

MOSICON has been marked disputed , can you have a look please Wikipedia_talk:Manual_of_Style_(icons)#Consensus.3F Gnevin (talk) 15:56, 17 January 2009 (UTC)

Gender neutrality: actress vs actor

Over recent months an edit war of sorts is developing in the articles relating to female members of the acting profession, both living and deceased. An increasing number of editors feel that the term actress is demeaning and alter it to actor, when it will immediately be reversed. I have no particular preference but feel that it is approaching a time where a consensus would clarify the matter. The wiki article for 'actor' currently says:

The word actor refers to a person who acts regardless of gender, while actress refers specifically to a female who acts, therefore a female can be both. The Oxford English Dictionary states that originally "'actor' was used for both sexes". The English word actress does not derive from the Latin actrix, probably not even by way of French actrice; according to the Oxford English Dictionary, actress was "probably formed independently" in English. As actress is a specifically feminine word, some feminists assert that the word is sexist. Gender-neutral usage of actor has re-emerged in modern English,[1] especially when referring to male and female performers collectively, but actress remains a commonly used word.

Is a MOS consensus possible or desirable to reduce the level of edit reversals? 21stCenturyGreenstuff (talk) 20:02, 13 January 2009 (UTC)

Does Wikipedia_talk:Manual_of_Style/Archive_101#"actor" vs. "actress" help? - Dan Dank55 (send/receive) 02:53, 14 January 2009 (UTC)

Erm well, many thanks for the steer...but quite frankly no it did not help one little bit. As I said before I have no personal preference either way, but I have a few dozen female thespians in my watch list and there is a daily parade of warring changes between actor and actress. It is a nuisance and a nonsense and will only get worse until some kind of firmer guideline is established that editors can work to. As many others will do I came to the manual of style for that guidance and have come away empty handed. Frankly the discussion you referred me to was nothing much more than a head in the sand "if we ignore it, it does not exist" attitude. Disappointing to say the least, but Oh well...which patch of sand is free for me to insert my head into? 21stCenturyGreenstuff (talk) 03:21, 14 January 2009 (UTC)

As a retired theatrical worker I know that many female performers have a strong personal preference for one word or the other (and have been on the receiving end of an earwigging or two if I used the wrong word in a publicity proof.)
I would suggest therefore that it is wrong to make an absolute policy one way or the other, so I'd propose the following guideline:
  1. If there is a source which demonstrates that an individual uses one or other word to descibe themself, we should use that in the article on them. It is the standard level of respect due in biographical articles.
  2. If an individual was active in an era when usage of one term was near-universal, then we should use that term. e.g. to refer to a 19th century actrss as an actor is anachronistic. (I'm aware that this argument doesn't hold for all period words - some have become completely unacceptable, and you couldn't justify the use of, say, nigger by such means). No one has offered sources that indicate that actress is considered offensive by a majority.
  3. Otherwise we should stick to first major usage in the article, as we do with spelling differences.

dramatic (talk) 03:53, 14 January 2009 (UTC)

Suggestions 1 and 2 are excellent, eg Helen Mirren who has never referred to herself as anything but an actor. But 3 would not stop the endless changes back and fore....but I am off to reinsert my head in this handy bucket of sand. 21stCenturyGreenstuff (talk) 03:59, 14 January 2009 (UTC)

Dramatic's suggestion actually sounds sort of reasonable. I would suggest notifying Wikipedia:WikiProject Films and Wikipedia:WikiProject Theatre to get a range of informed opinion. As for the fact that it won't stop all edit wars, too bad. It won't cure cancer either. The capabilities of the MoS are what they are. In any case the first-major-version solution works reasonably well for the Yank–Brit thing so I don't know why it can't work here. --Trovatore (talk) 04:07, 14 January 2009 (UTC)
  • I have a personal distaste for marked female terms, especially when they are morphologically converted from male form—which is thus cast as the default, the natural form. However, I suppose WP needs to respect the wishes of the subjects, if some women insist/insisted on referring to themselves as "an actress". If I had a magic wand, MoS would encourage the use of "actor" regardless of gender, thereby avoiding the implication that the male form is the natural form. However, I don't at this stage want to bother doing battle with people who feel more comfortable in a gender-unequal world, and who are happy for lexical forms to do their bidding. Tony (talk) 12:40, 14 January 2009 (UTC)
    • Good; of course Ellen Terry was an actress. (For what it's worth, very early Restoration English used actor for both sexes, as in Latin.) The assumption that differentiation requires inequality is imaginary; we don't need any magic wands here, just plain English. The correct guide, therefore, is to call the thespian what our sources call her; when she has a marked preference, they will usually follow. Septentrionalis PMAnderson 22:05, 14 January 2009 (UTC)

And of course there is the Academy Award "Best Actress", isn't there?--Jchthys (talk) 18:15, 20 January 2009 (UTC)

I think dramatic's idea-or at least the first two points-is fantastic. And i'm a woman and a feminist who would rather be called actress 'cause it sounds nicer! I don't think just because it separates us it automatically implies inferiority! It's the people who have the problem with the word that demonise it. But that's just my opinion. That was my first serious discussion post-scary! I'm not used to this yet! Deadlego (talk) 17:50, 25 January 2009 (UTC)

Second opinion

Difference of opinion on Romy Schneider about where she is born. Germany, Nazy Germany, or Austria. (1938 anschluss etc). All of them are correct, in a way. Is there any official guideline/MOS regarding this. Garion96 (talk) 20:21, 15 January 2009 (UTC)

Her birthplace is now in Austria. That is what I would use - I'm not aware of a policy relating to such matters so its just my opinion. Roger (talk) 14:39, 24 January 2009 (UTC)
MOS:PN#Place names says:

Many place names have a historical context that should be preserved, but common sense should prevail. There can be few places that have not been parts of more than one culture or have had only one name. An article about Junipero Serra should say he lived in Alta Mexico not the U.S. state of California because the latter entity did not exist at the time of Junipero Serra. The Romans invaded Gaul, not France, and Thabo Mbeki is the president of the Republic of South Africa, not of the Cape Colony. To be clear, you may sometimes need to mention the current name of the area (for example "what is now France"), especially if no English name exists for that area in the relevant historical period.

So it should be Germany, not Austria. -- Army1987 – Deeds, not words. 15:00, 24 January 2009 (UTC)

When should an article say "then-Senator Obama"?

The 2008 Barack Obama assassination scare in Denver refers to news reports of an alleged plot by Shawn Robert Adolf, Tharin Robert Gartrell and Nathan Dwaine Johnson to assassinate then-Senator Barack Obama, then the 2008 Democratic Party presidential nominee...

When should an article contain "then-title" for a past title. It seems obvious to me that without "then", it refers to when the person had those titles, but I couldn't find a Wiki MOS guideline and am unfamiliar with other MOS guidelines. Galatee (talk) 17:52, 22 January 2009 (UTC)

The man's name is, was, and (probably) always will be Barack Obama, which is also the location of the article. I cannot envisage any circumstance in which it is less clumsy to say an alleged plot by Shawn Robert Adolf, Tharin Robert Gartrell and Nathan Dwaine Johnson to assassinate Barack Obama, then a senator and the 2008 Democratic Party presidential nominee, ... Kevin McE (talk) 20:55, 22 January 2009 (UTC)
Right. As a general rule we don't use pre-nominal titles at all. No Mr., no Dr., no Senator, no Her Majesty. Common-sense exceptions when justified by circumstance, but I can't think just what those circumstances might be. --Trovatore (talk) 21:24, 22 January 2009 (UTC)
It's helpful to understanding the article to note in the lead that Obama was a senator and the Democratic presidential nominee then. I'm just arguing against the "then"s. For another example, John McCain has "Starting in 1994, he worked with Democratic Wisconsin Senator Russ Feingold on campaign finance reform". I think that's fine, but that it's unnecessary to say "then-Senator Russ Feingold" after he leaves office. Galatee (talk) 21:56, 22 January 2009 (UTC)
Hmm, I don't object to that particularly strongly, but it seems like a description rather than a title, so I'd prefer to use the lowercase senator. When Feingold leaves office, it would be somewhat preferable to rephrase it ... he worked with Russ Feingold, at the time a Democratic senator from Wisconsin, on.... --Trovatore (talk) 00:32, 23 January 2009 (UTC)
This would imply that references to Henry Clay (1777-1852) should mostly say "at the time a Senator from Kentucky"; surely "Senator Henry Clay" is preferable? Septentrionalis PMAnderson 04:36, 26 January 2009 (UTC)
Well his article managed to give plenty of detail about him without using the title more than twice (in a photo caption and a trivial factoid, both of which I have corrected. In another article, his name linked will allow a reader to know what his role was, if it is relevant, and if it is essential, then the word senator, with a lower-case s to make it clear that it is not a title, should suffice. If the context is clear that we are talking about a timescale in which the politicians are no longer alive/active, then former would be superfluous. Kevin McE (talk) 07:23, 26 January 2009 (UTC)

Notable People In A City

Hey, is there a standardized style fot this? Spinach Monster (talk) 04:45, 28 January 2009 (UTC)

Yes, i think it's "Notable residents" or "notable past residents". :) RingtailedFox • Talk • Contribs 20:28, 28 January 2009 (UTC)

contextless wikimapia links considered harmful...

Okay, so, not to put too much of a point on it, but do we have an MoS decision on random drive-by wikimapia linking? I, as should be obvious from the section head, suffer from POV. I find myself increasingly annoyed by seeing bots or persons with bot-like minds come through and shotgun a bunch of irrelevant links into articles I edit. The name of a town where event X occurred is not notable unless that town is widely known for its association with X. The wikilinking of a street where event X occurred 80 years ago, an event with no specifically geographical interest, is a sin against humanity and God, in my view. Yes, of course, in a story about JFK's assasination I should certainly expect to see a map of the grassy knoll, but in a story about, say, Eisenhower's presidency, a map of Abilene, Kansas is just plain pathetic. I want so very badly to assume good faith, but instead I find myself theorizing dumb-assed indifference. Please, yell at me or something so I know what to do. GPa Hill (talk) 00:19, 20 January 2009 (UTC)

I agree with you. I don't like random linking. What can be done about it, do you know? --Jchthys (talk) 18:18, 20 January 2009 (UTC)
How about Wikimapia links in External links? - Dan Dank55 (send/receive) 00:30, 22 January 2009 (UTC)
Dan, that would not bother me in the least, especially if they were clearly id'd as wikimapia. I mean, I realize there are plenty of situations where a map is just the thing. It's not maps per se, or links to them, it's bot-esque mapia. And for Jchthys, a) cool name, and b) I am bereft of a clue. Part of me wants to write an app to just check the articles on my list and remove all the bot-made dates and maps and links to the main article about East Bunsqueeze and its four malls automagically. --GPa Hill (talk) 00:51, 1 February 2009 (UTC)

Using self links as bold reiteration

At the moment, AWB is stripping all self links that it finds. However, it is the convention of some editors to use self links to implement the bold reiteration in the first sentence of each article (because self links are rendered as bold by Mediawiki). The AWB behavior causes those editors to have to do an additional edit to re-add the bold. It has been suggested that AWB replace first-sentence self links with bold (rather than stripping all mark-up entirely).

There is a need for clarification on whether it is bad practice to use self links to implement bold reiteration. According to Help:Self link,

Self links are usually not recommended. One exception is within a text that is transcluded between several pages. Per the Wikipedia:Manual of Style#Article titles, you should not use self-links to make the article name bold in the first paragraph.

However, nowhere in Wikipedia:Manual of Style#Article titles is this topic discussed (and so that entry should probably be removed from Help:Self link). This topic is also not discussed in Wikipedia:Manual of Style (links).

It does follow the WPMOS to wikify all relevant keywords in an article the first time they are used. It is also good web policy to use content-based tags rather than explicit style-based tags. So it seems like implementing the bold reiteration with a wikification makes sense. Comment? Thanks. —TedPavlic (talk) 15:48, 29 January 2009 (UTC)

As I opined at WT:AWB, self-links are a poor way to bold something for stylistic reasons. Just seems rather clumsy. –xeno (talk) 16:19, 29 January 2009 (UTC)
I don't view the self links as a method for bolding. I view the Wikipedia convention of wikifying relevant words the first time they are used as implying that the subject of an article should be wikified as well. I don't view double square brackets purely as a link; I view them as an identifier of a word that is so relevant and important that it deserves its own page. Hence, if that relevant keywords is on its own page, it gets bolded, and if it's on a different page, it gets linked. The wikification isn't a link itself; it's an identification of an important word. —TedPavlic (talk) 16:48, 29 January 2009 (UTC)
Another (perhaps bad) example... "Huey, Dooey, and Louie" might each have a page describing them, but all three pages might start with the same sentence involving their three names. If that first sentence was included from a common source, each name could be wikified. Then the names would get linked/bolded as appropriate based on wherever they were being included. —TedPavlic (talk) 16:50, 29 January 2009 (UTC)
I just clicked thru to 10 random articles and none of them wikilinked the first mention of the article's title. It just seems counter-intuitive to me. –xeno (talk) 16:52, 29 January 2009 (UTC)
agreed that this use is wrong. Links have the purpose of linking, and wikmarkup for bold has the purpose of bolding. that links are shown in bold is not a fixed function not of the markup, but the skin, and is in principle controllable by users. It should not be relied on. Using tags intended for other purposes purely for their visual effect is among the worst sins of the first generation of nonstandard html. DGG (talk) 05:47, 30 January 2009 (UTC)
According to Help:Self link, all self links are rendered in bold unconditionally. Nevertheless, my point is that relevant terms on a page should be wikified, and wikification just happens to lead to linking when on other pages and bolding when on the same page. In fact, this is the purpose of Mediawiki's "self link feature." I'm just trying to use the software as it's designed. —TedPavlic (talk) 13:31, 30 January 2009 (UTC)
Whole-heartedly agree. Confusing means and ends is not helpful to new users. There is no reason to use linking when markup is just as available for the purpose. —Mattisse (Talk) 06:00, 30 January 2009 (UTC)
I think the only instance where this feature should be used is within navigation templates, where it is useful to see the current article in a series highlighted in bold (and without the link colour). The feature should not be exploited within article prose. — Andrwsc (talk · contribs) 06:43, 30 January 2009 (UTC)
OK. That matches the "Huey, Dooey, and Louie" example. So I guess the only remaining issue is to fix AWB so that it replaces initial self links with bold (right now if they come after an infobox it gets confused and replace them with normal text). Otherwise, I'll just accept that Wikipedia convention trumps Mediawiki design. —TedPavlic (talk) 13:31, 30 January 2009 (UTC)

It was fixed in the latest release, see WT:AWB. §hep • Talk 03:56, 31 January 2009 (UTC)

WP:WHERE?

Is there a stylature guide for when describing (not naming) places? Should it be "shot in Vancouver, British Columbia, Canada" or what? Should it be "performed in California, USA" or what? Do we have any guidelines/guidance on this somewhere? — pd_THOR | =/\= | 19:01, 30 January 2009 (UTC)

Nweither is idiomatic, but the closest thing we have on the subject is WP:NC (settlements), which is not directly helpful on mentions in text. Septentrionalis PMAnderson 22:24, 30 January 2009 (UTC)
Overspecification can be tiresome, so if a large majority of anglophones know, say, that California is in the US (they do), I'd be inclined not to specify the country, especially if the state-name is linked, and more so if it's a town in California (to avoid a triple unit). "Los Angeles" may need neither hierarchical unit. "Sacramento" may need the state, or instead the country depending on context. Tony (talk) 07:23, 31 January 2009 (UTC)
Sacramento, United States is not American idiom, because of the high likelihood that it would be ambiguous (as it is - Sacramento, Kentucky.) Whether this is relevant to the rare article in a Commonwealth English which mentions the capital of California is another question. Septentrionalis PMAnderson 22:01, 31 January 2009 (UTC)

National spelling variation: Retaining the existing variety

I completely disagree with the Retaining the existing variety policy of the manual. In short, it says that the spelling of the "first major contributor" will stand as the Wikipedia spelling unless a specific reason to change it comes up. This is ridiculous. If a fringe spelling used by the "first major contributor" does not cross dialects, the more common one will naturally replace it. Why then would a spelling that does cross this boundary be exempt from this common sense rule?

For the purposes of this argument, we can ignore smaller English variations to focus on the two largest ones, American English and British English. According to Alexa[5], Wikipedia has more than five times as many American users (23.1%) than British users (4.1%). If India (5.4%) is added to British users, Americans still more than double the number. More over, approximately two thirds of native speakers of English live in the United States,[6] and therefore speak American English.

American English is by far the most common English variant both on Wikipedia and in the world, therefore unless contradicted by the other three guidelines, American English should be standard on Wikipedia.--Marcus Brute (talk) 06:35, 24 January 2009 (UTC)

British English is not just used in the United Kingdom and India, but throughout the Commonwealth as well. The present guideline is a good compromise that avoids fruitless warring over the variety of English to be used in articles, and I, for one, see no reason for it to be changed. — Cheers, JackLee –talk– 06:49, 24 January 2009 (UTC)
Yes, the existing procedures work reasonably well, which is about the best that can be hoped for. There is no way that either American or Commonwealth speakers are going to accept the other dialect being privileged. The remaining imaginable possibility is to have separate wikis for the two dialects, which would be a massive waste of talent on both sides and a win for no one. The coexistence will lead to occasional annoyances (for me in particular it's aluminium that sets my teeth on edge) but it's a good opportunity to practice serenity of mind, and as a practical matter is very much preferable to any available alternative. --Trovatore (talk) 08:20, 24 January 2009 (UTC)
(What's wrong with aluminium? The -ium suffix indicates it's a metal. :-) — Cheers, JackLee –talk– 08:42, 24 January 2009 (UTC))
Oh, you mean like platinium, and tantalium ? Not to mention ironium. --Trovatore (talk) 09:48, 24 January 2009 (UTC)
(Also, what's wrong with spelling it the way it's pronounced? :-P ) --Hans Adler (talk) 09:26, 24 January 2009 (UTC)
We pronounce it aluminium as well.--Kotniski (talk) 09:30, 24 January 2009 (UTC)
So do I. Sorry I wasn't clear. --Hans Adler (talk) 10:23, 24 January 2009 (UTC)
We South Africans pronounce it "Al-loo-min-yum" and spell it "Aluminium". Roger (talk) 13:57, 24 January 2009 (UTC)

I would absolutely reject the idea that Wikipedia should be entirely in US English, and take the chance to remind anyone happening across this discussion of the element of ENGVAR that is perhaps both most overlooked and most valuable, opportunities for commonality, Version-neutral English as I prefer to call it. Of course it is not always possible, as when one needs to refer to the metal with the atomic number 13, but a little thoughtfulness can bear much fruit in terms of providing that which is equally acceptable to all readers. Kevin McE (talk) 10:09, 24 January 2009 (UTC)

Good point. When I have a choice, I personally follow the principle of using the spelling variant that is closest to other European languages, especially French. So many of my verbs end in -ise, not -ize. But in article space I (follow the established convention of the article, and when there is none) use "Oxford style" spelling, i.e. in most cases -ize (with the notable exception of "analyse", which is wrong in the BE). --Hans Adler (talk) 10:21, 24 January 2009 (UTC)
But English isn't French. English speakers don't say organ-ice. And indeed organize is a valid British spelling. It is a real pity that nationalism has got involved in a debate about spelling which should be about which form is most logical.Dejvid (talk) 12:00, 24 January 2009 (UTC)
Too bad that neither format is "logical". DirkvdM made a list which is worth reading, at User:DirkvdM#EE vs AE. -- Army1987 – Deeds, not words. 13:10, 24 January 2009 (UTC)
I use Canadian spelling out of a (somewhat geeky) sense of loyalty to my country, but I'll be the first to admit that if it's a matter of whose spellings are most logical, the Americans will win every time. Most of the differences arose from Noah Webster's reforms, whose express purpose was to remedy some of the irregularities that existed in the spelling system. One would have to be very brave to argue that anybody with a brain setting out to fix illogical English spellings could possibly fail. And within the limited scope of the changes that were made, he succeeded.
The Americans made the changes in part to declare their linguistic independence from Britain. The irony is, the rest of us know deep down that they had the right idea but now we're too concerned about our own independence from them ever to follow them. That doesn't mean we're wrong, though - identity is an important part of language. Joeldl (talk) 20:59, 24 January 2009 (UTC)

To respond directly to the question asked, say two-thirds of people use American spelling, and one-third British spelling, and assume further for the sake of argument that there are no other kinds. Then the result of the "retaining the existing variety" rule is that two-thirds of the spellings on Wikipedia will be American, and one-third British, albeit not coexisting in the same article. Since that reflects the actual balance in the English-speaking world, what's wrong with that? If a spelling is a fringe one in the real world, it will remain a fringe spelling on Wikipedia to the same extent, unless the adherents of that spelling are unusually prolific contributors. Joeldl (talk) 10:36, 24 January 2009 (UTC)

  • ENGVAR as currently constructed is one of the most successful of all of WP's practices. I think we should be rejoicing the acceptance of our sort-of binary system on a within-article basis, just as the largely binary date formats have become accepted. Tony (talk) 13:39, 24 January 2009 (UTC)
Don't fix what ain't broke! One of my "pet peeves" is when someone changes the spelling against the rule that says that an article relating to a specific (English speaking) country should use the engvar of that country. I have reverted Americanized spelling changes in South African related articles too many times to mention. (I am South African so I have many such articles on my watchlist.) It is also interesting to note that I have never seen the opposite happen - someone changing an American related article's spelling to an other than US engvar - that simply never happens. This can be taken as "evidence" to support accusations of "Yank arrogance" that one sometimes sees here. Roger (talk) 14:54, 24 January 2009 (UTC)
I don't think that's true. I think it's usually an honest mistake. Americans are simply less often exposed to Commonwealth/Irish spellings than the other way round, in part because of their greater weight within the English-speaking world, and in part because of the practice of Americanizing spellings for U.S. editions of books by foreign authors. Joeldl (talk) 15:13, 24 January 2009 (UTC)
I am not saying it is objectively true. I am simply reporting that I have seen such accusations on talk pages and in edit notes. Roger (talk) 20:35, 24 January 2009 (UTC)
FWIW, the New Scientist recently had an article[citation needed] on the future of the English language which said that a majority of English speakers are not native-born speakers, and the proportion will increase. Nbauman (talk) 21:46, 28 January 2009 (UTC)
Not the article Nbauman was referring to, but in case anyone's interested:
  • Dave Graddol (1997), The Future of English? A Guide to Forecasting the Popularity of English in the 21st Century (PDF), London: British Council.
  • Eric A. Anchimbe (2006), "World Englishes and the American Tongue", English Today, 22 (4): 3–9, doi:10.1017/S0266078406004020.
— Cheers, JackLee –talk– 14:37, 30 January 2009 (UTC)
I personally would suggest to would-be dialect-changers that they concentrate their frustrated sexuality onto the much more significant issue of "coherent thought well-expressed" than the "presence or absence of 'u' in the word whose synonyms include 'hue'". That is to say, I am vastly more concerned by atrocious writing (in any dialect) than by orthographic uniformity. -- GPa Hill (talk) 00:59, 1 February 2009 (UTC)

If the English language version of Wikipedia were to standardise on American-English, there would then be a need for a non-American English language version of Wikipedia in the same way that there is a German language version and a French language version, etc. I think most people can see that this would be absurd.--Toddy1 (talk) 15:04, 1 February 2009 (UTC)

RfC on WT:MOSNUM

There is an ongoing RfC here on WT:MOSNUM that could use more input from Wikipedians on its three propositions. Greg L (talk) 23:51, 1 February 2009 (UTC)

Propose adding to Wikipedia:Avoid weasel words to Category:General style guidelines

Any objections? OlEnglish (talk) 22:16, 28 January 2009 (UTC)

I'll update the page at WP:Update if people here decide to add the page, but based on what I see at WP:Weasel and its talk page, it has much more in common with guidelines intended to explain and support content policy than it does with style pages, to me. Although generalizations are always wrong (including this one), style page discussions are usually boring and geeky. When I see a talk page that talks about terrorism and how changing the text would be like "punching someone in the face", rather than boring discussions of why we should or shouldn't follow this or that style guide, I get worried that adding the page to CAT:GEN will only fan the flames and result in louder arguments, without adding a lot of stylistic content. But I'm not the judge. - Dan Dank55 (send/receive) 19:10, 29 January 2009 (UTC)
  • No objections from me. —Mattisse (Talk) 19:16, 29 January 2009 (UTC)
Btw, it hasn't been a style guideline for half a year, and everything that's a general style guideline is also a style guideline. Previous consensus, starting roughly at WT:Avoid weasel words#recent insertion, was that it wasn't a style guideline. We settled on making it a nondescript "guideline". - Dan Dank55 (send/receive) 19:33, 29 January 2009 (UTC)
  • Fine by me as well. I've always believed that this is more closely aligned with style (i.e. how we write) than content (i.e. what we write). Warren -talk- 20:09, 29 January 2009 (UTC)
Why can't WP:Weasel be both a style guideline AND policy/content guideline? I just thought it should be included in WP:Update; that was my main reason for wanting to add it to CAT:GEN. Also, I thought it's closely related to Wikipedia:Avoid peacock terms and should be in there next to it, but maybe it should also be edited to sound more "boring and geeky" to give it more credibility? :) -- OlEnglish (talk) 01:13, 30 January 2009 (UTC)
Absolutely, a page can be both a content guideline and a general style guideline if you like. - Dan Dank55 (send/receive) 02:18, 30 January 2009 (UTC)

 Done OlEnglish (talk) 19:56, 2 February 2009 (UTC)

TOC input request

I've been revising some articles that I've worked on exensively to experiment with different TOC arrangements. It's a subjective issue, and some like the TOC in the default layout (with white space to the right.) The question is more relevant when the TOC is long and creates a large block of white space before your can read the body text. An example of a before and after are included in case anyone wants to offer an opinion.

default look
revised look

Thanks in advance. -- Wikiwatcher1 (talk) 21:52, 4 February 2009 (UTC)

I've always been a little bothered by the unprofessional look of the large white space next to uncollapsed TOCs. I have assumed that the devs were trying to avoid display bugs that might arise from complex templates. See if you can get the devs to buy what you want to do at WP:VPT. - Dan Dank55 (send/receive) 22:04, 4 February 2009 (UTC)
The whitespace caused by a misplaced image I hate (see example). But this one I actually prefer. Perhaps I am simply used to it, but I prefer a little bit of a border between the lead and the rest of the article. The revised look of the Lee Strasberg is too messy. Garion96 (talk) 22:16, 4 February 2009 (UTC)
I'm sure moving the Lincoln image down to the bottom of that section (keeping the full image within the section) would fix that one easily with the text then automatically back-filling the white space. -- Wikiwatcher1 (talk) 23:07, 4 February 2009 (UTC)
I already fixed it a couple of months ago. It was just an example where I do mind whitespace. Garion96 (talk) 07:30, 5 February 2009 (UTC)
In the simple skin, the "revised look" results in the horizontal rule below the title "Early years" extending to the left directly through the text "Contents". In general it's better not to try to micromanage layout in this way, but if you do you need to remember to try it in all the supported skins. — Carl (CBM · talk) 22:31, 4 February 2009 (UTC)
That's for sure! Same line problem in all other skins. -- Wikiwatcher1 (talk) 23:25, 4 February 2009 (UTC)

Alphabetization and collation

Recently, I made some editing decisions involving alphabetization in the article Esperantist, and I discovered that Wikipedia has few or no guidelines for this process, which is probably important enough and comprehensive enough to deserve its own subpage. Here is a permanent link to a discussion of the topic: User talk:Noetica - Wikipedia, the free encyclopedia [section 4: "Alphabetization (given names, surnames, domestic name order, thorn)"].

-- Wavelength (talk) 00:09, 25 January 2009 (UTC)

As for Icelandic names, my impresson by taking a look on Iceland, Icelandic name, Icelandic language etc. is that most articles about people with Þ or Ð in their name are titled that way. And the redirect Thortharson is quite pointless: Icelanders aren't usually referred to by their patronymic alone (e.g. Björk, not "Guðmundsdóttir"); so a redirect from Thorbergur might be more useful. I won't insist on this as I'm not an Icelander, but if you want to do a large-scale renaming of articles with þorns and eðs in their names I suggest you ask the opinion of people at WP:ICELAND first. (More generally, articles should be at the name the person is most commonly referred to as by in English, even if this leads to inconsistences as Strauss rather than Strauß but Schrödinger rather than Schroedinger; as a rule of thumb, modern names tend to be translitterated less often than old ones.)
As for surnames beginning with prepositions, at least in Italy they are considered part of the surname (and in more than 90% of them they start with a capital, mine being one of the few exceptions), i.e. nobody would alphabetize De Felice under F, or even de André under A, nor would anyone ever refer to them as Felice and André, either. So conventionally treated as an essential part of the surname is a good advice, but it should provide at least one example containing a space, such as De Felice. The point is, alphabetize under the surname the person is most commonly referred to, e.g. Ludwig van Beethoven under B because he's usually referred to as Beethoven, but Vincent van Gogh under V as he's usually referred to as van Gogh; spacing and capitals should be irrelevant to this.
As for numbers, I think they should be sorted by value (e.g. 10 BC before AD 10 before 100 before 1492 before 2009), it would be awkward to have to spell out each number mentally in order to locate 1492 in a list of years. -- Army1987 – Deeds, not words. 02:40, 25 January 2009 (UTC)

To add to Noetica's nice list above, St. and Mt. should be alphabetized as Saint and Mount, right? Reywas92Talk 19:08, 25 January 2009 (UTC)

From the archives, here are 23 related discussions, of which seven of the most relevant are in boldface italics.

-- Wavelength (talk) 23:10, 25 January 2009 (UTC)

Wikipedia has the article Collation, which discusses alphabetization. One definition of alphabetize is "to express by or furnish with an alphabet" [7], hence, there is Alphabetization.org - Easily fighting illiteracy!

Besides those two examples, five of the leading results of my Google search for "alphabetization" are as follows.

-- Wavelength (talk) 04:19, 26 January 2009 (UTC)

From the five external links listed above, I have learned that there are two major methods of alphabetization: word-by-word alphabetization and letter-by-letter alphabetization. In the former method (my preference of the two), word in print precedes wording, whereas, in the latter method, wording precedes word in print.


Besides that "major" distinction, methods of alphabetization differ in various other respects, involving: abbreviations (such as St. and Mt.), surnames (with Mc, Mac, and M' ; and with da, de, di, do, du, van, von, and so forth); name order (of given name and surname), capitalization (A to Z before a to z, or A before a to Z before z), punctuation, numerals, and other features.


At this moment, I am inclined to favor a system of collation based on the very thorough outline at
Martin Tulic, Book indexing - About indexing (with its list of linked pages), and supplemented by the following.

-- Wavelength (talk) 23:50, 27 January 2009 (UTC)

I would favor the word-by-word method also, as humans tend to think in word units rather than letter units. The Martin Tulic resource looks like a good reference. As for the diacritics, as a mostly-English cataloger, I have no opinion, although the use of redirects on WP is a life-saving procedure for instances with spelling variants. My 2¢. Pegship (talk) 20:05, 28 January 2009 (UTC)

I agree with what has been said so far, namely that word by word is best as is using the commonly found form. I also think that some names (Walter de la Mare) might be better off alphabetized in natural language order instead of an inverted form that is difficult for users to remember. If you wanted to have the inverted form you could use redirects. This is especially true of medieval names (e.g. Willam of Occam).--FeanorStar7 (talk) 00:32, 29 January 2009 (UTC)
Word by word, each abbreviation should be spelled out when alphabetizing, no opinion on diacritics. Nowimnthing (talk) 13:44, 29 January 2009 (UTC)
I also vote for word by word, for NOT putting numbers alphabetically as if they were spelled out (e.g. 14 under "f") but rather in numeric or chronological (BCE before AD) order as appropriate, and for treating abbreviations as though they were the full word (e.g. "St." would be alpha'ed as "Saint"). As for the perplexing questions of Mac and Mc (do we put them at the front of the M's? do we pretend Mc is actually spelt Mac?), I vote that we not do either as it does nothing but confuse the average person. I mean really, who's going to think to look for "McDonald" between "MacDaniel" and "MacElhenie" ?? The original purpose of this was to simplify locating a name when the reader couldn't be sure whether it was spelt Mac or Mc, but in these days of ctrl-f and search, it seems an unnecessary and artificial refinement. I vote we simply alpha those exactly as spelt. So for example: ... Mabon... MacDuff... Maddox... Mbutu... McDuff... Merrill... and so on. --Bookgrrl holler/lookee here 04:24, 7 February 2009 (UTC)

The standard alphabetization methodology in the Anglo-American library industry is 'word by word', otherwise known as 'nothing before something'. I favour this on the basis of my own professional experience in the information industry. The American Library Association Code (Rule 6), follows this methodology, and further notes 'abbreviated words should be filed as if they were spelled out in full, with one exception, that is, the abbreviation Mrs. St. is therefore filed as if it were spelled Saint, and Mc... as Mac'. --Taiwan boi (talk) 14:11, 29 January 2009 (UTC)

I adhere to the ALA's word by word rule (Rule 1) in ALA Rules for Filing Catalog Cards. Rule 6 covers abbreviations. Here's a link to a preview of the book:http://books.google.com/books?id=mCg-ZNG2llUC&dq=american+library+association+alphabetization+rules&printsec=frontcover&source=bl&ots=4_QnGRcepx&sig=VVGIQmIRFvK6uL2xzYKRXRP131c&hl=en&sa=X&oi=book_result&resnum=2&ct=result#PPP1,M1

Kmzundel (talk) 17:08, 29 January 2009 (UTC)

Noetica’s suggested protocol, and other editors, may have alluded to the following issue, but the examples don’t address it explicitly. I’m concerned about (usually French) names starting with Le and La. Some Le s and La s are separated from the next part of the name – Le Boucher, La Roch, etc. Others are not – Leboucher, Laroche, etc. Currently, all the names that have a space after La/Le appear earlier on in a category, and the names without spaces appear later. Hence, Maurice Leroux could be at quite some distance from Maurice Le Roux. In this particular case, these turned out to be the same person, so they have to be merged (I have no idea which is the correct spelling). This would have been picked up much more quickly if they’d appeared together in the first place. My intuitive way of ordering names in the real world does not just focus on the first element of a multi-part surname, but ignores spaces utterly and considers all the letters as if they were contiguous. I know that WP has decided to use only the first element for sorting purposes, but that has always seemed an odd decision to me. It feels like a decision made by a computer whizkid who's all tied up with primary and secondary sorting keys. That's good in theory, except that that's just not the way names work. We don’t think that the principal part of Maurice Le Roux’s surname is merely "Le", with some less important letters appended merely to distinguish him from Pierre Le Roy. No, Roux and Roy are, if anything, more important than Le, so they deserve to be fully taken into account as integral parts of name. There should be no "primary and secondary sorting key" idea with surnames. The whole surname is the primary - and sole - sorting key. The only real issue is deciding what exactly is the surname - and cases like Charles De Gaulle and Vincent van Gogh are classic examples. Is it "De Gaulle" and "van Gogh", or merely "Gaulle" and "Gogh"? But that's a completely separate issue. Once we decide that Vincent was Herr "van Gogh" and not Herr "Gogh", then he would be listed as a V name, after a putative Vangoff and before a Van Goit. See the discussion here that brought me to this page. -- JackofOz (talk) 21:46, 8 February 2009 (UTC)

Most indexing systems I use regularly ignore spaces, so Le Roux and Leroux would be found together under LER. I find this easy to remember (no need to remember an exhaustive list of strings to ignore or spacing conventions) and leads to a fairly logical ordering. I've also noticed a growing convention not to spell out abbreviations, which I find also improves accessibility. Knepflerle (talk) 11:03, 9 February 2009 (UTC)
This is a very odd discussion, since in France "de Gaulle" would be under "g" and "le Roux" under "r". −Woodstone (talk) 11:13, 9 February 2009 (UTC)
Of course that is true - in French. It's asking rather a lot of our readers to know which particles are ignored in languages they may not have any acquaintance with. Our readers also shouldn't have to know what language a name stems from in order to find it in an index. It's a lot easier to remember the simple rule that we alphabetise every letter, rather than try and remember a list of exceptions on top of that. Knepflerle (talk) 15:33, 9 February 2009 (UTC)
  1. ^ dictionary.com actor retrieved 13 November 2007
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Archive_107&oldid=1160821897"