Wikipedia talk:Manual of Style/Dates and numbers/Archive 107

Archive 100

←

Archive 105

Archive 106

Archive 107

Archive 108

Archive 109

Archive 110

Downgrade consistency from mandatory to something less

The guidance currently says:

The same format should be used in the main text, footnotes and references of each article, except for:

However, a mismatch between body text and references is widespread and uncontroversial in Wikipedia. The people that control reference templates such as Cite web actually mandate formats that are inconsistent with body text. Note that dates in body text are often part of the reading flow and dates in references are not. I think this is an oversight in the guidance rather than an error in the real world. I propose to bring the guidance into line with reality by simply moving 'footnotes and references' into the exception bullets (one for each). Lightmouse (talk) 13:06, 27 July 2008 (UTC)

I've worked out that Lightmouse is referring to the "Full date formatting" subsection :-) . An associated clause in the "Date autoformatting" section further down refers back to it ("The full date formatting section requires consistency in the raw date format within an article"), and would need to be changed likewise.

I agree entirely with his proposal: most editors use one of the plethora of uncoordinated citation templates that can make it hard, sometimes impossible, to achieve consistency within all components of an article. While a more flexible, coordinated system of citation templates (and, indeed, infobox templates) is required, we must be realistic in accepting that this is not going to happen any time soon. We might live in hope of this, but in the meantime the guideline is clearly living in cuckoo-land in this respect and is internally contradictory in implication. I know that Sandy, as FAC Delegate, is painfully aware of this particular disjuncture between widespread practice and guidelines.

May I commend Lightmouse's suggestion as being a minimal, neat solution. I'm satisfied that editors have been aiming for just what he proposes, probably without realising it: consistency within the main text, and consistency within the citations/notes—not the universal within-article sameness that the rules currently assume. These components—the body of an article and the citations/notes at the bottom—are well separated visually, structurally, and in function. I don't blame the majority of editors for not having noticed that citation templates live in their own world, or if they have, for not regarding this as worth worrying about. It is a welcome proposal. Tony (talk) 13:59, 27 July 2008 (UTC)

However the wording change is done, please make sure that readers understand that:

article text should use one, consistent style for date formatting and linking, and

references and footnotes should use one, consistent style for date formatting and linking.

The aim is that article text and footnotes/references may differ in style because of citation template programming, but within the footnotes and references, we should still find consistency in both linking/delinking and style of dates used. That is, if ISO dates are used, they should be used consistently. If international dates are used, they should be used consistently. If dates are delinked or linked, that should be consistent, and so on. That is, we're not letting footnotes and references off the consistency hook; we're just recognizing that current template implementations on Wiki make it very hard to achieve consistenty between article text and citations. We can still achieve consistency within each. I suppose the "consistency dividing line" would be consistency above the See also section, and consistency below the See also section, in terms of WP:LAYOUT. SandyGeorgia (Talk) 16:20, 27 July 2008 (UTC)

In other words, I agree with the proposal, but disagree with the section heading here. We are not downgrading consistency as much as we are recognizing a dividing line between article text and everything below See also, but we should still recommend consistency in the "top" of the article and the "bottom" of the article. SandyGeorgia (Talk) 16:25, 27 July 2008 (UTC)

We should be striving for consistency throughout the entire article. It's a time consuming task to adjust templates but, eventually, it's a task that needs doing. Sure, we have a reality to deal with here in writing the MoS but the authors of these templates have a reality to deal with too. We'll do well to recognise this dividing line but let it be recognised as temporary. Nothing's changed since the templates were written: most viewers see the raw unautoformatted text, consistency in writing is generally a good thing and ISO dates are rare in English. JIMp _talk·cont 17:10, 27 July 2008 (UTC)

To what good? Uniformity between text and notes means that articles which use different styles in the text cannot use the same templates (or templates must have switches, which is another set of bells and whistles on templates which are already too complex). The fundamental reason for within-article consistency is not to jar the reader with unexplained switches; moving from text to notes already changes location on the page, font, type-size - changing date style is just another. Septentrionalis PMAnderson 17:22, 27 July 2008 (UTC)

To what ill? It may be just another switch but it's an unnecessary one. As for the extra bells and whistles, we'll just have to deal with them ... if they are needed. However, added complexity might not even be necessary. Indeed, the templates might loose a bell, whistle or two. {{Cite}} (with only four parameters—hardly complex), for example, could be adjusted simply by de-linking the {{{date}}} parameter within the template. JIMp _talk·cont 17:42, 27 July 2008 (UTC)

A mandate makes it measurably harder to write a well-sourced article with ENGVAR-compatible date formatting in the text. That's an ill. If you can get the citation templates changed, get back to us. Septentrionalis PMAnderson 17:58, 27 July 2008 (UTC)

As far as I know, all of the current templates can handle "normal" (non-ISO) dates, but many of them are designed to prefer ISO dates, so switching over articles will be a lot of work. Hence, I support this proposal to temporarily allow the "top" and "bottom" of the article to use different date formats, which should allow for a gradual switchover. SandyGeorgia (Talk) 20:01, 27 July 2008 (UTC)

From above: References and footnotes should use one, consistent style for date formatting and linking.

What does "consistent" mean here? Publication and accessdates have different purposes. In the recent discussion about accessdates and {{citation}}, someone argued that having two dates in a footnote potentially makes it difficult for readers to identify the publication date. If that's true, having them in the same "style" is more confusing. Documentation at one of the citation templates currently suggests publication dates match the article text, but there is a long history of using ISO for accessdates. If someone uses DMY for every publication date and ISO for every accessdate, for instance, is that really a problem? Gimmetrow 21:39, 27 July 2008 (UTC)

There's a point. What if we replace a temporary horizontal line with a permanent diagonal one?

Ok, I'll need to explain this. If there are strong arguments in favour of having ISO access dates, we could keep them (but unlinked) and use for publication dates the same format as with the rest of the text. It would also reduce confusion between the two dates in individual citations. On the other hand, any concept of consistency would be significantly complicated; we should essentially have citations matching the text except for the very last part (which is also, conveniently enough, a different sentence). So, it all boils down to this: what are the arguments for and against using the ISO format for access dates? We have already heard a couple. Waltham, The Duke of 16:07, 29 July 2008 (UTC)

Your Grace, I don't think ISO dates are going to disappear any time soon. Consistency within citations, and consistency in the main text, seems like a practical solution until heaven comes to earth. Tony (talk) 10:52, 30 July 2008 (UTC)

Actually, I am saying quite the opposite: If we are to retain ISO dates, then we could do this: use the International or US date format in both the article's text and the publication dates of citations, and use ISO format for the access dates. Minimal change from the status quo (regarding format, not linking), and minimal change for the templates as well. Consistency throughout, with the exception of the access dates (sort of a parenthesis, really, and not present in all citations), which will be in the preferred for them format and distinguished from the publication dates (thus reducing confusion).

This would be a permanent solution (provided that ISO dates are also de-linked) and would require no absolute separation line between text and citations.

Comments? Waltham, The Duke of 16:32, 30 July 2008 (UTC)

On second thought, I see that {{cite web}} and {{cite news}} use such a formatting for publication dates (namely parentheses) that anything but ISO looks exceptionally strange. Unless some more substantial changes happen to these two templates, the—now stricken—text above is out of place. In lack of a better solution, I support the separation of text and citations in date-formatting terms. And grudgingly accept that this story is far from over... Waltham, The Duke of 16:52, 30 July 2008 (UTC)

Are you saying a format like

J. Wales (31 July 2008). "Main Page". Retrieved 2008-08-01.

"looks exceptionally strange" and this guideline must forbid its use? Gimmetrow 19:06, 1 August 2008 (UTC)

To all commentators, please keep this simple and keep ISO and citation complexities out of it. I started this debate because there is a mismatch between guidance (demands consistency) and the reality (tolerates inconsistency). The debates about consistency have always been about the main text only. Date formatting must be one of the most talked about and most badly handled issues on Wikipedia. Yet three formats are widely seen on the same page without significant comment. Few editors care enough about date consistency to do much about it. It is not a big deal. For now, please, just cut the scope of guidance down from whole-article to main-text. Lightmouse (talk) 10:50, 9 August 2008 (UTC)

Time format

WP:MOSNUM#Times has been cited as the guideline for writing not just the time of day, but also the time it takes to do something. This occurs in tables when the time of a winner of a race is written beside their names. I had always come to the conclusion that no guideline applied on this and had typically been writing things in 0h 0' 0" style. I'm not fussed it 0:00:00 is preferred, but I think the guideline needs to be worded to be less ambiguous. Second, if I am to use the 0:00:00 format, how would I write a time when hours or seconds aren't included? Severo^TC 19:57, 14 August 2008 (UTC)

I don't think 00:00:00 is intended to be mandatory for race timings, although it's a perfectly acceptable method. Does anybody differ? Septentrionalis PMAnderson 00:53, 15 August 2008 (UTC)

Litre: l vs L

Relevant discussion at

→ WT:Manual of Style (dates and numbers)/Archive 106#Litre: l vs L

Straw poll on unit symbol usage for the liter

The following introduction / overview is for the benefit of new voters to quickly bring them up to speed. Thunderbird’s original post has been moved to “Discussion” below. Be it known to all that Headbomb created this voting table. Thank you Headbomb.

All: The below straw poll regards a proposed MOSNUM guideline for the unit symbol to use for the liter and its decimal multiples and submultiples like the milliliter and microliter. The issue that started this thread was concern over the use of lowercase L (l) for the un‑prefixed liter, such as “a 10 l tank”. It is widely felt that since lowercase L (l) can be easily confused with uppercase i (I) and the numeral 1 when using sans-serif typefaces, the un‑prefixed unit symbol for liter should be only the uppercase L, (e.g., editors should write "A 10 L tank" instead of "A 10 l tank").

The primary issue to decide here is whether to also require that only the uppercase L be used for the prefixed versions (such as mL and µL) and to prohibit the use of ml and µl. One school of thought supports this view since it will bring consistency and harmony to the unit symbol in all its forms. The other school of thought is that the lowercase L (l) is approved for use by the BIPM with the SI and is still widely used. This school of thought instead proposes that either ml or mL may be used (as is currently done on Wikipedia), but whichever one is chosen must used consistently within an article (or group of articles), and further holds that ml and L should not be awkwardly mixed (e.g., editors should not write “Add 20 ml of acid to 1 L of water”.

---

Note that the below chart does not allow ~~~~ signatures to be used. You must copy/paste or hand-edit your signature. For assistance in writing your signature, you may copy the time below in red from the preview window after refreshing while in edit mode:

16:17, 9 November 2024 (UTC)

---

L vs. l
4 = Total support, 0 = Complete opposition

User	Link to comment	Degree of comfort with option
		L only	L only ml or mL, Don’t mix ml and L	l only	Silence	l or L ml or mL don't mix same unit
Thunderbird2		0	0	0	4	0
Headomb		4	1	0	0
Caerwine		3	1	0	2
MJCdetroit		4	0	0	0
Greg L		3	4	0	1	0
User:Gerry Ashton		4	2	0	2
Askari Mark		2	4	0	2	0
EagleFalconn		0	0	0	4	0
User:Itub		4	1	0	3	−∞
Woodstone		0	2	0	3	4
User:jnestorius		0	0	2	2
User:RockyMtnGuy		4	2	0	0
Jimp		0	2	0	4	3
User:Dank55		1	4	0	0
User:Tony1		0	4	0	0
User:Flying Jazz		0	1	0	2	4
User:LeadSongDog		0	2	0	4	2
Teemu Leisti		4	0	0	0	0
User:TimVickers		0	0	4	0
User:Blank		0	0	0	0
User:Blank		0	0	0	0
User:Blank		0	0	0	0
User:Blank		0	0	0	0
User:Blank		0	0	0	0
User:Blank		0	0	0	0

L only: Most restrictive. This option would deprecate all lowercase l for the liter symbol; that is only forms like “2 L”, “2 mL” and “2 µL” would be permitted.

Liter = L only, ml or mL, don’t mix ml and L: Mid-restrictive. This option would deprecate lowercase l for the unprefixed liter (only “2 L”), would permit either ml or mL if done consistently, would not permit mixing of ml and L (for details, see the two greenbox examples shown in Discussion, below)

l only: Entirely different alternative: Deprecation of any and all uppercase L

Silence: Least restrictive. There would be no posted guideline

l or L, ml or mL, don't mix, same unit: No real “restrictions”: Specifies the common-sense requirement that articles should be consistent. “2 l bottle” would be permitted, and ml and L could be used in the same article.

Discussion

While we are discussing all these complicated alternatives, I have posted Ilmari Karonen’s widely supported version on the project page. Headbomb is right though that things would become much simpler if MOSNUM were to state a clear preference for L, and I know that at least three editors would prefer this (EagleFalconn, Headbomb and Thunderbird2). Jimp expressed a preference for silence. At an earlier stage in the discussion, I made this unsuccessful attempt at finding out how much support there is for the different possibilities. Before we tie ourselves in knots, I’d like to settle this point for once and for all. To this end, editors’ views are invited (see table above). Thunderbird2 (talk) 08:34, 3 August 2008 (UTC)

• For use with the SI, the BIPM formally says that lowercase L (l) is perfectly fine for all forms of the unit symbol for liter (l, ml, µl, etc.). So I see absolutely no need to proscribe all instances of lowercase L (l) so long as articles are unambiguous and easy to read and consistent. Does anyone know how many articles currently use ml? A lot and I just don’t see the necessity of trying to enforce wholesale change in all those articles as long as forms like ml are used consistently.
  We should focus our attentions only on fixing serious problems with readability, ambiguity, or violations of common sense. It’s clear enough and easy to read whenever lowercase l is paired with a prefix (e.g., 50 ml). We should be focusing our attentions only upon real problems here, such as addressing hard-to-read instances of un‑prefixed lowercase l (e.g., “10 l tank”) or mixing ml and mL in the same place. I think we need to withstand the temptation to proscribe and prescribe so much here on MOSNUM in an effort to gain fabulous consistency from article to article. Few readers notice such things. We need to stay out of style issues unless something is broken. Editors’ battles, like the above-mentioned “regional variation” that Itub wrote of (12:12, 24 July 2008 post) wouldn’t be properly addressed at all with a blanket rule. Why go and piss off other editors at WikiProject Chemistry for minor reasons? Those editors over at WikiProject Chemistry probably don’t even know about this discussion here.
  Here’s what I would recommend :

• The internationally accepted unit symbols for the liter are both the uppercase L and the lowercase form (l). However, since lowercase L ("l") can be easily confused with uppercase i ("I") and the numeral 1 when using sans-serif typefaces, editors should write the unit symbols for the liter and its decimal multiples and submultiples as follows:

1. The un‑prefixed unit symbol for liter (L) should be only the uppercase L, (e.g., editors should write "A 10 L tank" instead of "A 10 l tank").
2. Except as provided in point #3 below, prefixed versions of the liter (the decimal multiples and submultiples such as the milliliter and microliter) may be written with either the lowercase or uppercase L (e.g., either "A 200 ml bottle" or "A 500 mL glass of beer" is satisfactory), but the chosen style should be consistent so as to avoid the awkward mixing of styles.
3. Articles should not mix the uppercase "L" for the unprefixed liter with lowercase prefixed forms like ml. Do not write "This soft drink is availible in both 250 ml and 2 L bottles", but rather "This soft drink is availible in both 250 mL and 2 L bottles".
4. Do not use the unicode "script ell" character ℓ and its variants (㎕, ㎖, ㎗ and ㎘).

I’m not all transfixed on the above wording—wording such as that shown in the greenbox below…

• With the SI, the accepted unit symbols for the liter are both the uppercase L and the lowercase form (l). However, since lowercase L (l) can be easily confused with uppercase i (I) and the numeral 1 when using sans-serif typefaces, the un‑prefixed unit symbol for liter should be only the uppercase L. Prefixed versions of the unit symbol (the decimal multiples and submultiples such as the milliliter and microliter) may be written with either the lowercase or uppercase L but the chosen style should be used consistently. Articles should not mix the uppercase L for the un‑prefixed liter with lowercase prefixed forms like ml. Do not use the unicode "script ell" character ℓ and its variants (㎕, ㎖, ㎗ and ㎘).

…accomplishes the end and is fine by me—but it illustrates the essential elements of what I think is wisest here. We’re doing enough by prescribing uppercase L (2 L bottle) and further by suggesting that authors should also use only uppercase for the prefixed versions (like mL) if they are juxtaposed next to a L symbol.

We don’t need to go overboard and pretend as if we know what is best and tell everyone they have to change and do things a particular way now that they are on Wikipedia—particularly when the BIPM formally permits lowercase l with the SI, and when some countries and dialects customarily use ml. Believe it or not, Wikipedia often reflects real-world practices. I can see that uppercase L is used for mL and µL in U.S. medicine and I can certainly imagine that this is increasingly reflected on Wikipedia—I think that is a good thing. But trying to effect blanket changes via MOSNUM is not the way to go. Wikipedia should reflect the way the real world works and not be used as a tool to effect change in the way it works. Legislative bodies govern best when they legislate the least. Greg L (talk) 23:45, 3 August 2008 (UTC)

What's so damn special about chemists? I mean honestly? Headbomb {ταλκ – WP Physics: PotW} 00:05, 4 August 2008 (UTC)

• IMO, that’s the wrong question, Headbomb. Wikipedia is a reflection of the way the world works. Even though the U.S.’s NIST adopted the uppercase L for liter, the BIPM allows both lowercase and uppercase and this is the way it’s often done in the world and on Wikipedia. So the real question should be this: Should we handful of registered editors who frequent MOSNUM be trying to prohibit a common practice on Wikipedia because we think we’ve identified The Better Way®™©? I don’t think so. I think we need to limit ourselves to addressing only real problems, such as ambiguous text, like “1 l”, and inconsistent usage within articles. Wikipedia is not like some magazine or a professional print encyclopedia where there is one chief editor at the top who sets a manual of style and all the copy editors toe the line. We have to accept this reality and stop trying to treat MOSNUM as if it were. Wikipedia will never have the project-wide consistency those publications enjoy because it is a collaborative writing environment and the fact that it services multiple English-speaking peoples. I’m just not seeing a problem worth upsetting the apple cart here. There is nothing wrong with “ml” if it’s used properly and consistently in an article. Greg L (talk) 01:15, 4 August 2008 (UTC)

• P.S. Like EagleFalconn wrote above in his ref note on his vote, “99.99% of Wikipedia doesn't even know this discussion is happening, nor will they care. Try and keep it in perspective.” Unless there is a clear consensus here for the most restrictive guideline, we should always default to the least restrictive one. The nuanced approach I’m advocating here at least provides part of what you want; it just stops short of providing *everything* you want. Greg L (talk) 01:30, 4 August 2008 (UTC)

• I prefer dm³ instead of both L and l. Albmont (talk) 02:18, 4 August 2008 (UTC)

• My unit of preference is the Smoot³. Seriously though. I also mention in my note that consensus in the scientific community is to reserve capital lettered unit abbreviations for units named after people. Are we going to be upset about violating that convention? Engineers typically use imperial units. Are we going to worry about the fact that most articles that mention a volume don't follow the volume with something in fluid ounces, or gallons? You can't please everyone folks. I don't know if you've heard, but theres this encyclopedia that needs writing, and they're looking for volunteers. EagleFalconn (talk) 05:05, 4 August 2008 (UTC)

• • ROFL. I'd heard the bankrupt republic still had engineers using imperial, but I wouldn't believe it. I told my friends, "There's no way any self-respecting engineer would take those unnecessary conversion risks with public safety at stake. It must have been a marketing department's choice." Of course, I may have imagined that discussion.LeadSongDog (talk) 20:20, 4 August 2008 (UTC)

• • • You've clearly never heard of the Mars Climate Orbiter. EagleFalconn (talk) 13:02, 5 August 2008 (UTC)

• I don't follow the logic in the green boxes. Quote form the WP:MOS and WP:MOSNUM:
  • In the main text, give the main units as words

So the problem of difficult to read l hardly arises. An author should write "A 10 litre tank". Only in tables one would use l, which would then not be difficult to interpret.

−Woodstone (talk) 21:05, 4 August 2008 (UTC)

• Woodstone, I don’t buy into your premiss that the unit symbol isn’t often encountered in in-line text on Wikipedia. There must be thousands of instances. Indeed, the unit name should be spelled out in full on its first occurrence. But just like “kg” for kilogram, or any other unit of measure that will appear many many times throughout the article, it is customary and desirable to begin using the unit symbols. And writing a “2 l bottle” is really hard to interpret. The U.S. adopted uppercase L for a reason (and the BIPM formally recognized the practice) because of the trouble with reading lowercase l in the modern world of computing. Any on-line encyclopedia that uses a sans-serif font for body text should use only uppercase L for clarity. Greg L (talk) 22:31, 4 August 2008 (UTC)

In case anyone cares, the ACS Style Guide, used by the journals of the American Chemical Society, uses L. Chemists all over the world are very used to seeing L, even if they prefer l themselves at home. --Itub (talk) 05:43, 5 August 2008 (UTC)

I wonder how many people in this discussion are (a) not American (b) not chemists. I am neither. It's my understanding that SI eventually approved L as an alternative to the longer-established l simply to recognise the pre-existing American usage, and that, whatever its merits, L has not caught on outside America. Therefore stating that "L is SI approved and unambiguous" is not the whole story: L is unrecognizable for the majority of non-Americans. Which non-American style guides mention this issue? The online ones I see specify l and don't mention L:

• Times, also used by History UK "Some basic international units and their abbreviations are: metre (m); gram (g); litre (l); ampere (A); volt (V); watt (W); note also kilowatt-hour (kWh). Only abbreviate mile to m in mph and mpg; and gallon to g in mpg (otherwise gal). Beware of using m for million or for miles in any scientific context when it might be taken for metres."
• WHO, PDF pg 36 "litre l (spell out if confusion is possible)"

None of these even admit the existence of L as an option. In the spirit of "ensuring that you cannot be misunderstood", mandating L is therefore a non-starter. jnestorius^(talk) 11:22, 5 August 2008 (UTC)

I think you are overestimating the difficulties that readers would face for understanding L. In my experience, most people don't even know that unit symbols are case-sensitive; I often see Kg and KG when referring to kilograms, but I don't think anyone has any trouble figuring out what it means, especially in context. Similarly, I doubt that anyone will think that "2 L bottle" must be in a strange unit such as Lithuanian gallons instead of liters. --Itub (talk) 11:48, 5 August 2008 (UTC)

Perhaps most people you know are less familiar with the metric system than most people I know. Perhaps you are overestimating the difficulties that readers would face for understanding "2 l bottle" in context. jnestorius^(talk) 12:10, 5 August 2008 (UTC)

I believe that both are equally understandable, but the lowercase one looks hideous due to the sans-serif font. What most people here are overestimating is the importance of this issue! :) --Itub (talk) 12:55, 5 August 2008 (UTC)

Well said. In any case, if we're really going to continue on this somewhat absurd process, we might as well adopt something useful and consistent. Regarding the argument of familiarity with the metric system: Not everyone who reads these articles will be familiar with the metric system. It is in our best interest, if we're really worried about it, to make sure units are specified clearly. EagleFalconn (talk) 13:02, 5 August 2008 (UTC)

Indeed. Few polls bother with an "I don't care" option due to self-selection bias. While I interpret "straw poll" on Wikipedia to mean "no pressure, tentative first step, probably nothing more will happen" I am sometimes annoyed to find Decisions Being Made based on them. I still say litre is clearer than either l or L. That is all. jnestorius^(talk) 14:42, 5 August 2008 (UTC)

• Seeing Dank55’s ref comment regarding U.S. manuals of style, I’ve upgraded my vote from a 2 to a 3 for the most restrictive option. I’ll keep my vote for the mid-restrictive option at a 4. I see no reason to mandate more substantial change than is truly required; “ml” is clear as to what it means. We’ve degenerated here in our posts, I think, to arguments about whether one way is *better* than another. I suggest that all we should do is try to fix truly broken things and leave the rest untouched given that Wikipedia is a collaborative writing environment and there are different practices out in the wide world. Whereas project-wide consistency would be nice, consistency is really only needed within individual articles or highly related articles. The mid-restrictive option only proscribes the hard-to-read “2 l” and common-sense admonitions against confusing mixing. I see no reason to go beyond this even though it can be argued that “L”-only is a better way that the U.S. has largely standardized upon. Greg L (talk) 19:00, 5 August 2008 (UTC)

• Some google results illustrating the scale of the issue and current relative frequencies: site:enbaike.710302.xyz "l bottle" site:enbaike.710302.xyz "ml bottle". Now let's all get back to some real work. jnestorius^(talk) 20:15, 5 August 2008 (UTC)

Er, google searches are case-insensitive. This tells us nothing.LeadSongDog (talk) 07:48, 6 August 2008 (UTC)

Er, I know google searches are case-insensitive. This means you get 2 searches for the price of one. Scan the results. jnestorius^(talk) 09:27, 6 August 2008 (UTC)

Gotcha. Don't you miss the days when you could control what search engine queries did? Query "ml assay" is also exemplary with a different basis group of subject matter. Even selecting major publishers (Nature, Lancet, SciAm) leads to mixed usage of upper and lower. More reason not to be proscriptive.LeadSongDog (talk) 16:23, 6 August 2008 (UTC)

Thanks for the excellent references to style guides showing that "ml" is an option, guys. I found "ml" at one of the Sciam articles, http://www.sciam.com/article.cfm?id=blood-cells-for-sale. Given all that, I changed my vote to "be consistent on ml vs. mL in an article"...although I suppose I really mean, aim for consistency among groups of similar articles, say from one wikiproject. - Dan Dank55 (talk)(mistakes) 18:28, 6 August 2008 (UTC)

You know what the problem is? The entire discussion here seems to be framed around finding a consensus, but no one is quite sure how to define it. Its become clear to me that no one is really happy that this discussion is taking place. My take is that whoever started it (I don't even know) just wanted to know if there was an opinion for this, a couple people objected in all sorts of different ways. Since we can't agree on anything here, everyone has different reasons for their choice, and because this has become a demonstrable non-issue, I would advocate that everyone change their vote to "4" for silence and let common sense and the standards for a given discipline dictate this incredible non-issue. EagleFalconn (talk) 18:54, 6 August 2008 (UTC)

• I don’t think there needs to be an attitude here of “it’s gotta be entirely my way or the highway.” The objectives of column 1 and column 2 are not mutually exclusive; the #2 option is a subset of #1 as regards restrictions. Among other things, the first (most restrictive) option addresses the following:

1. it gets rid of “2 l” and requires only “2 L”
2. it would not permit “10 ml” along with “2 L” in the same article
3. There would be no script ell (ℓ)

…and so too does the mid-restrictive option (#2). The only difference between the two is the #2 option would permit the continued use of “ml” (in addition to “mL”, which is the only style permited by optioni #1) as long as A) the chosen style is used consistently, and B) the “ml” form is not used alongside the unprefixed unit symbol for liter (“2 L”). If a consensus for the most restrictive option doesn’t develop here, we just default down to the less restrictive one. Alternatively, we can opt for the “be silent” option. We can not, however, default to one of the other options since they have little support and call for practices that are diametrically in opposition to the more widely supported options in column #1 and #2. I see MOSNUM being silent on this as unwise since there currently are instances on Wikipedia of “ml” and “mL” mixed in the same articles, and there are also instances of “L” and “ml” being mixed. And, of course, there are instances of “2 l”, which most editors here clearly want to fix. If we can’t all agree on the option to fix everything, we might as well adopt one that addresses most. Greg L (talk) 19:53, 6 August 2008 (UTC))

• Of course there should not be an attitude here of "it's gotta be entirely my way or the highway." That's not what Wikipedia is about. It's rather ironic that you follow that statement by advocating limiting the debate to options #1 and #2, both of which deprecate a way that is so popular internationally that it is required by the WHO manual of style. Why should Wikipedia tell the World Health Organization to hit the highway? Instances of internal inconsistency in an article don't need an MOS statement to be repaired. Why not have the same accepting attitude in the manual that you advocate here in this talk page? Flying Jazz (talk) 14:38, 7 August 2008 (UTC)

• No, I don’t think my suggestion above is “ironic” at all. If we are to arrive at a consensus view, it is unrealistic to think that a poorly supported option that is in diametric opposition to the majority view can be reconciled with a compromise solution; it simply falls to the wayside. What seems to have you all animated here is your advocacy (a “4” vote) on the last option, which would permit the continued use of lowercase ell (l) for the non-prefixed liter (e.g. “2 l”). If you desire that a guideline be adopted that permits this, make a reasoned argument here that changes editors’ mind. But as it currently stands, that option can’t be reconciled with the majority view and doesn’t have much support. And please cut down on the hyperbole. We wouldn’t be telling the World Health Organization to “hit the highway”; they can do whatever they want. But we would be choosing to not follow the advise of their style guide because the lowercase ell is ambiguous when displayed here on Wikipedia due to our use of a sans-serif font.
  You have to remember that most of the PDF publications the WHO produces are published in a serif typeface like Times so instances like “2 l” (which I set here in Times) aren’t at all ambiguous to read. So what can work satisfactorily enough for them doesn’t work very well here, where “32 l” and “32 I” appear nearly identical. Further, it is clear that not all WHO authors really elect to follow the guideline. Why? Well, I went to WHO’s publications database and searched on “water quality”. The very first hit I landed on (Water Quality Interventions to Prevent Diarrhoea: Cost and Cost-Effectiveness) uses the uppercase L for the unit symbol of liter—even though the body text is set in Times in that document too.
  I would also submit that we really shouldn’t be looking towards WHO for guidance as to what we should do here on Wikipedia. We have our own set of circumstances and needs here. I am advocating that we permit “ml” because it is SI-compliant and is easy enough to read. I know of no way to further accommodate your desires without producing very ambiguous looking text (e.g., 1 l) here on Wikipedia Greg L (talk) 16:37, 7 August 2008 (UTC)
• (ec) I agree with Greg_L. The purpose of MOSNUM (and more widely MOS) is to provide guidelines for standardisation. We can choose to follow WHO or not, depending on what's best for Wikipedia, and there are good reasons not to follow WHO here, because 1.1 L is so much clearer than 1.1 l. I also agree with a couple of other editors who have expressed a preference for spelling out "two litre bottle" in full. A simple rule coupling this "in full" preference with either one of "L only" or "L or l, consistently , but never bare l" for the symbol, would get my support. Thunderbird2 (talk) 16:47, 7 August 2008 (UTC)

• Isn’t there already a blanket MOSNUM guideline saying that the first instances of units of measure should always be spelled out.? If not, there should be. Greg L (talk) 17:00, 7 August 2008 (UTC)

I'm not sure if there's a blanket rule like that, but here's a proposal for the litre. It is based on the most widely supported option (L only), with an attempt to gain additional support from those advocating spelling out the name in full:

• The symbol for litre is L (not l). Link to its definition on first use (L) and consider writing out the name in full (3 two litre bottles).

Reactions? Thunderbird2 (talk) 07:17, 8 August 2008 (UTC)

• My reaction, T-bird to this: “It is based on the most widely supported option (L only)”, is that you seem to be jumping at the solution that has the virtue of satisfying your personal desire (L-only) but isn’t remotely supported by an honest appraisal of the facts: the option you support simply isn’t the consensus view.
  Your math and logic baffles me. As of this writing, I count 7 votes that place a greater value on L-only than for the middle-ground approach (the second column). I also count 8 votes that place a greater value on the middle-ground approach than for the L-only approach. Nice try, but anyone here can read the vote table and count on their fingers. And even if several more votes come in for the strictest option here, that would clearly be insufficient to declare that there is a consensus for anything.
  So how about identifying some common ground? This is how votes are conducted in races where there are multiple candidates: you winnow down to the two best-supported candidates and re-vote.
  Both “L-preferred” approaches call for L-only for the unprefixed liter. They also call for not using the script ell. With both approaches, one would only see “mL” when “L” is in the same article, and you’d never see inconsistent usage within an article (or group of articles) with prefixed forms of the liter. So the simple solution in my mind is to consolidate those two columns into the one option that has at least some of the “L-friendly” elements that both camps camps can support, and to conduct a final vote. This new vote would be a two-option one: A) support the nuanced approach, or B) do nothing and remain silent. The other “l-friendly” options in the current table have insufficient support to warrant inclusion in what would be a final up-or-down vote to settle on what to do.
  I’ll begin work on posting a two-option table so we can settle this and move on to other things. Greg L (talk) 20:16, 8 August 2008 (UTC)

There's no need to get uptight. By my reckoning, column 1 (L only) is even stephens with 8 supporters and 8 detractors. I agree that's not a consensus, which is why I was attempting to gain support from the "spell out in full" voters, but it's better than 5-6 against (column 4 = silence) or 5-7 against (column 2 = L or l consistently). By all means include other options if you think that will help, but make sure that "L only" is of them Thunderbird2 (talk) 20:33, 8 August 2008 (UTC)

• I have no idea what your “intentions” were; I can know only what you wrote: “It is based on the most widely supported option (L only)’, which was an untrue statement of the current status. Like I said, there are, as of the moment you wrote the above, and as I write this, seven votes that *place a greater value* on L-only than for the middle-ground approach (the second column) and there are 8 votes that *place a greater value* on the middle-ground approach than for the L-only approach. That is a fact. I can not control how you do your “reckoning.”
  And whether it’s your 8/8 or my 7/8, by no stretch of the imagination is there—or was there—a consensus for anything, let alone a consensus to adopt what you are advocating. And that’s what’s need here: a consensus, not a fallacious conclusion from you that what you desire is “most widely supported”.
  As to your “…but make sure that "L only" is of them”, the L-only option is in the current table. To develop a consensus, we need to winnow down the options. When there have been no new votes for a period of time on the current options (where L-only is one of them), it’s time to consolidate. If we don’t do that, we’re just spinning our wheels and going nowhere. Greg L (talk) 20:58, 8 August 2008 (UTC)

Greg L's statement "with both approaches, one would only see 'mL' when 'L' is in the same article" is wrong. The form "mL" is allowed under all options except the "l" only option, even if there is no "L" in the article, provided that all other instances of prefixed forms of the liter symbol are also capitalized. --Gerry Ashton (talk) 21:09, 8 August 2008 (UTC)

• No, it’s not wrong. Read what I wrote in my 20:16, 8 August 2008 post. I used the word “both.” I was talking about the first two options. In both those options (as currently written), “one would see only ‘mL’ when ‘L’ is in the same article.” The difference is that the most restrictive option (the first column rule) would have only ‘mL’ period. But then, we’re exploring the possibility of modifying the second-column rule to permit ml and L in the same article (see below). Greg L (talk) 22:04, 8 August 2008 (UTC)

Greg L's post didn't say "see only", it said "only see", which changes the meaning completely. --Gerry Ashton (talk) 22:30, 8 August 2008 (UTC)

• I don’t understand what the problem is. It says, and I repeat: “Both “L-preferred” approaches call for L-only for the unprefixed liter. They also call for not using the script ell. With both approaches, one would only see “mL” when “L” is in the same article…” It’s clear enough to me. If L is in the article, readers would only see the prefixed version of milliliter as “mL”. Sorry if you thought it wasn’t written clearly enough. But that’s what I intended it to mean. Greg L (talk) 23:23, 8 August 2008 (UTC)

• I fail to see what the problem would be with using both ml and L in the same article. Mixing ml and mL in one article would be sloppy as would be l and L. My proposal would be: by preference write out "litre" in full, when there are many occurrences write L in running text and l or L in tables; ml and mL should not be mixed in one article. −Woodstone (talk) 21:28, 8 August 2008 (UTC)

• Me too; I don’t have a problem with mixing ml and L in the same article. If one stares at it long enough, it might not seem *consistent* but it confuses no one and—in the real world with real readers—reads smoothly enough. Question to all: Among those who voted for the middle-ground pro-L approach (the second column), who opposes allowing ml when L is in the same article? The rule would be L only, ml or mL, no ℓ, be consistent. Woodstone, would so modifying it this way get your support? Greg L (talk) 22:04, 8 August 2008 (UTC)

• I hesitate to ban l in tables or infoboxes and we should not negate the existing blanket requirement for spelling out most units in running text. Otherwise I tend to support. −Woodstone (talk) 22:10, 8 August 2008 (UTC)

I think we’ve identified what part of current articles we don’t think should be messed with. I hesitate to ban ml in tables or infoboxes (or elsewhere) just because L appears in the body text. Greg L (talk) 22:14, 8 August 2008 (UTC)

Mixing L with ml on the same article is sloppy. Using two different symbols for the same unit depending on the presence of a prefix is madness IMHO. --Itub (talk) 09:12, 9 August 2008 (UTC)

• And a lot of other editors feel that way too Itub (even though I personally don’t). I think, realistically, the only way to properly and fairly get milage in a two-option vote is to not attempt to tinker with the options; otherwise, we set ourselves back a whole bunch. We certainly have a consensus with the first two columns to require uppercase L for the unprefixed liter and have common ground on other details as well. The other options that would take affirmative actions of some sort aren’t supported well enough to prevent identifying a consensus. With the #1 & #2 column votes nearly evenly divided, there clearly is no consensus to ban ml. So the up-or-down vote can be quite simple. Greg L (talk) 18:22, 9 August 2008 (UTC)

Current state

l only: 1 user chose this as his/her prefered option

L or l, ml or mL, consitent use: 2 users chose this as their prefered option

Silence: 4 users chose this as their prefered option

L only, ml or mL, consistent use: 4 Users chose this as their prefered option

L only: 7 users chose this as their prefered options

Recasting "votes" until we gain majority:

Recasting l only: (nothing change since user gave a 2 on two options)

L or l, ml or mL, consitent use: 2 users chose this as their prefered option

Silence: 4 users chose this as their prefered option

L only, ml or mL, consistent use: 4 Users chose this as their prefered option

L only: 7 users chose this as their prefered options

Recasting L or l, ml or mL, consitent use:

Silence: 6 users chose this as their prefered option

L only, ml or mL, consistent use: 4 Users chose this as their prefered option

L only: 7 users chose this as their prefered options

Recasting silence votes:

L only, ml or mL, consistent use: 8 users chose this as their prefered option

L only: 7 users chose this as their prefered options

Alternatively, numbers of "points":

l only: 2

L or l, ml or mL, consistent use: 13

Silence: 31

L only, ml or mL, consitent use: 33

L only: 32

Headbomb {ταλκ – WP Physics: PotW} 22:09, 9 August 2008 (UTC)

Looks like the convoluted option is the favored option (altough not by much). I say either we ask from feedbacks of more wikiprojects or that we go with it. Headbomb {ταλκ – WP Physics: PotW} 22:09, 9 August 2008 (UTC)

• I’ve been busy this weekend so far (and will be so on Sunday too). And I agree, the second (“convoluted”) option does logically seem to be where the most common ground is found if a guideline of any sort is to be written. I would propose that we might conduct an up or down vote to ensure there truly is a consensus for such a guideline (either that, or remain silent). Do you have time to post a “convoluted/stay silent” vote Headbomb? If you don’t, I might get to it Sunday evening or Monday. Greg L (talk) 04:41, 10 August 2008 (UTC)

I don’t understand this logic - adding points is meaningless, and recasting the votes of others involves too much interpretation of their views for my liking. I also dislike Greg_L’s dismissive attitude - he may choose to do his accounting in a different way, but there is nothing fallacious about my arguments, which I will flesh out a little here. The lack of consensus applies to all of the options presented so far (so perhaps it’s time to follow EagleFalconn’s lead and drop this discussion, but having got this far it seems worth one last attempt). It seems sensible to try to rally around the one most likely to achieve consensus, so let’s consider which one that is:

• Including the latest vote of Teemu Leisti, column 1 (L only) is supported explicitly by 9 editors and opposed by 8. Looking at the reasons given by EagleFalconn, jnestorius and Jimp, I have the impression that their opposition can be addressed by careful wording, which would reduce the opposition to 5 with at least 9 still in favour. Further support from those opposing a ban on ml (which it could never be anyway, because it's only a guideline) might be achieved by expressing the rule as a preference rather than a requirement (eg, the preferred symbol for litre is L)
• Now let’s look at column 2 (L or l, consistently), which is supported by 5 editors and opposed by 8. You can gain the support from column 5 by making the rule more flexible, but I believe that in so doing you will lose the support of column 1, because the main reason for preferring L only is simplicity.

In conclusion, there is no justification for excluding the L only option from any further voting, and I oppose any attempt to do so. Thunderbird2 (talk) 09:06, 10 August 2008 (UTC)

Afterthought: between them, columns 1 and 2 carry the support of 12 editors, with only 3 opposed to both. That is where the consensus lies. Thunderbird2 (talk) 09:21, 10 August 2008 (UTC)

I'm merely reporting the current state of the debate. I presented results according several clear and unbiased way of doing things which are a) Simple "prefered option" counting b) Vote recast until 50%+1 majority is found. This is done according to what people voted. There is nothing to be interpreted or reinterpreted here. There is a name for this procedure but I forgot what it was. c) Weighed voting (counting "points"). If you don't like it, then I can't help you since all I wrote is simply reality. Note that I did not say that what I wrote was only way of interpreting reality, nor that debate was over, nor that things were settled, nor that anything other than at the time of writing, the convoluted option had a majority support (albeit not a clear majority), and that if this was not a clear enough majority, that we should contact some Wikiprojects for additional comments. Clearly you think that this is not a clear majority, so I suggest contacting some Wikiprojects. And please try to keep discussion about the merits and flaws of each option in the discussion section. Headbomb {ταλκ – WP Physics: PotW} 09:36, 10 August 2008 (UTC)

The vote transfer procedure may be unbiased. So is flipping a coin, but that does not make it representative of voters' views. The fact is I don't understand it (what is the justification of transferring 4 silence votes to column 2 in the last step?) More to the point, what is your objection to seeking the middle ground between columns 1 and 2? Thunderbird2 (talk) 10:08, 10 August 2008 (UTC)

• T-bird, I just don’t understand why you are trying to make a case here for continuing to advocate for the “L-only” option. Isn’t it clear as glass to you yet that A) it doesn’t have wide support, and B) with five options and the current division of votes, there is absolutely no way a proper, Wikipedia-style consensus can be discerned? The objectives of column 1 and column 2 are not at all mutually exclusive; the #2 option is a subset of #1 as regards restrictions. Both call for reducing the use of lowercase ell to eliminate ambiguity; it’s just that the option in the #2 column doesn’t go as far as the #1 column (which is what you want).
  But there is a lot of common ground between the two. Among other things, the first (most restrictive) option addresses the following:

1. it gets rid of “2 l” and requires only “2 L”
2. there would be no mixing of styles
3. it would not permit “10 ml” along with “2 L” in the same article
4. There would be no script ell (ℓ)

…and so too does the mid-restrictive option (#2). The only difference between the two is the #2 option would permit the continued use of “ml” (in addition to “mL”, which is the only style permited by option #1) but only if A) the chosen style is used consistently, and B) the “ml” form is not used alongside the unprefixed unit symbol for liter (“2 L”). A consensus for the most restrictive option you desire didn’t develop here and it is unrealistic to hope that it might. This issue isn’t important enough that we need to drag this out with intermediate votes and endless discussion; for one thing, no one has the stomach for dragging this out forever and we want to get on with it.

So the next required step is obvious: consolidate columns #1 and #2 into the one option that has all the “L-friendly” elements in common to both and then we’ll conduct a final vote. A combination of these two columns has the widest possible support by editors here. This new vote would be a two-option one: A) support the nuanced approach, or B) do nothing and remain silent. If you want to support this combined approach with your vote, you may. If you want to vote “remain silent” because the common-ground option isn’t to your liking, you may. But the other “l-friendly” options in the current table have insufficient support to warrant inclusion in what would be a final two-option, up-or-down vote to finally settle this issue. Note further, that this is precisely how votes are conducted in electoral races where there are multiple candidates in a field: you winnow down to the two best-supported candidates and re-vote. Greg L (talk) 18:11, 10 August 2008 (UTC)

I have no objection to an attempt at compromise between columns 1 & 2. Thunderbird2 (talk) 18:42, 10 August 2008 (UTC)

• I don’t know where you are going with “an attempt at compromise”, but if what you are angling for means it would flat prohibit the consistent use of ml in articles (where it’s not awkwardly juxtaposed with L and isn’t mixed with L), then that wouldn’t be “compromise”, would it? It would mean that the “compromise” wording would effectively become column #1, wouldn’t it? What I mean, by compromise, is that all the common, proactive elements of column #1 and #2 would be adopted into wording for all editors to consider and vote upon. And any proactive elements that aren’t in common to both would not be adopted. If that’s what you mean, then we are in complete agreement on how to go forward to settle this and move on to other matters. Greg L (talk) 19:18, 10 August 2008 (UTC)

I see no attempt at compromise. I don't see how this helps. To gain support (for column 2) from column 1 you need to make the text simpler, not more complicated. The alternative would be to seek support from column 2 with a more flexible version of column 1. I see neither of these. Thunderbird2 (talk) 19:30, 10 August 2008 (UTC)

There is no attempt at compromise for the simple reason that there can be no compromise. Either it's L all across or it's the convoluted option (L only, ml and mL, consistent use) (the other options were ruled out). If you compromise "L only" it becomes the convoluted option. If you compromise the convoluted option, it becomes "L only". And right now it's not a matter of having a simpler text or not, we all know what the option are and what they mean. If the convoluted option is chosen, the text will be longer and more complicated than with the L only option for the simple reason that things would not be simple as in the "L only" option nor could they be summed as concisely. That the text is complicated is not the issue, it's the complicatedness of the rule that is the issue. But you cannot make that rule simple, because if you did, it would cease to be that rule and become either the "L only" option, or the "l or L, ml or mL, consistent use" option. Headbomb {ταλκ – WP Physics: PotW} 01:00, 11 August 2008 (UTC)

• No, that is faulty logic Headbomb. We can too get rid of “2 l” and still permit prefixed forms like “ml” as long as they are used consistently. Your “there can be no compromise” statement just comes across to me that if you can’t get your entire way and get rid of all lowercase ells, then you don’t want to even consider a guideline that would accomplish part of your goal (getting rid of “2 l”) and you would prefer to vote to “remain silent.” That’s your prerogative. And the guideline being contemplated isn’t “convoluted” in the least. Any old sixth-grader could figure it out. Many of us here feel that “ml” is clear enough. Given that it is fully SI-compliant and is a common form gives many of us reason to not try to deprecate its use on Wikipedia; we feel that is simply unnecessary. In fact, to address the desires of a couple of other editors here, I’ve added an option that is even less restrictive. This is the nature of compromise. I can live with either of the options being voted on below. Greg L (talk) 01:40, 11 August 2008 (UTC)

Two-option vote

All: What has become clear from the above five-option vote is there is no clear consensus. Among those editors who would have a guideline of some sort, there is a clear majority of editors who desire to promote the use of uppercase L for the unprefixed liter (e.g., “2 L”) and to be consistent with usage and not mix styles within articles. Those desires are expressed in columns #1 and #2. Both call for reducing the use of lowercase ell to eliminate ambiguity; it’s just that the option in the #2 column doesn’t go as far as the #1 column.

But there is a lot of common ground between the two. Among other things, the first (most restrictive) option addresses the following:

1. it gets rid of “2 l” and requires only “2 L”
2. there would be no mixing of styles
3. it would not permit “10 ml” along with “2 L” in the same article
4. There would be no script ell (ℓ)

…and so too does the mid-restrictive option (#2). The only difference between the two is the #2 option would permit the continued use of “ml” (in addition to “mL”, which is the only style permited by option #1) but only if A) the chosen style is used consistently, and B) the “ml” form is not used alongside the unprefixed unit symbol for liter (“2 L”).

There are also a significant number of editors, faced with conflicting options for a proactive guideline, who voted for MOSNUM to remain silent on this issue.

So the next required step is to consolidate columns #1 and #2 into the one option that has all the “L-friendly” elements in common to both and then we’ll conduct a final vote where we are either have a guideline, or not. In the above vote, the other options that would promote the use of the lowercase ell are diametrically opposed to the objectives of the more widely supported column #1 and #2 votes and can not be reconciled with a hybrid rule.

Accordingly, the below vote is a simple up or down vote: At issue is whether to support wording that would accomplish the following:

• The internationally accepted unit symbols for the liter are both the uppercase L and the lowercase form (l). However, since lowercase L ("l") can be easily confused with uppercase i ("I") and the numeral 1 when using sans-serif typefaces, editors should write the unit symbols for the liter and its decimal multiples and submultiples as follows:

1. The un‑prefixed unit symbol for liter (L) should be only the uppercase L, (e.g., editors should write "A 10 L tank" instead of "A 10 l tank").
2. Except as provided in point #3 below, prefixed versions of the liter (the decimal multiples and submultiples such as the milliliter and microliter) may be written with either the lowercase or uppercase L (e.g., either "A 200 ml bottle" or "A 500 mL glass of beer" is satisfactory), but the chosen style should be consistent so as to avoid the awkward mixing of styles.
3. Articles should not awkwardly mix the uppercase "L" for the unprefixed liter with lowercase prefixed forms like ml. Do not write "This soft drink is availible in both 250 ml and 2 L bottles", but rather "This soft drink is availible in both 250 mL and 2 L bottles".
4. Do not use the unicode "script ell" character ℓ and its variants (㎕, ㎖, ㎗ and ㎘).

The above rule-set clearly delineates the objectives of the guideline but does not have to be the actual wording of the guideline; wording such as as shown in the greenbox below could be used (as could any other wording that accomplishes the above objectives):

• With the SI, the accepted unit symbols for the liter are both the uppercase L and the lowercase form (l). However, since lowercase L (l) can be easily confused with uppercase i (I) and the numeral 1 when using sans-serif typefaces, the un‑prefixed unit symbol for liter should be only the uppercase L. Prefixed versions of the unit symbol (the decimal multiples and submultiples such as the milliliter and microliter) may be written with either the lowercase or uppercase L but the chosen style should be used consistently. Articles should not awkwardly mix the uppercase L for the un‑prefixed liter with lowercase prefixed forms like ml. Do not use the unicode "script ell" character ℓ and its variants (㎕, ㎖, ㎗ and ㎘).

---

Note that the below chart does not allow ~~~~ signatures to be used. You must copy/paste or hand-edit your signature. For assistance in writing your signature, you may copy the time below in red from the preview window after refreshing while in edit mode:

16:17, 9 November 2024 (UTC)

---

Place an X on the option you support

User	Link to comment	L only ml or mL, Don’t mix ml and L	Remain silent
Greg L		X	-
Woodstone		-	X
Itub		-	X
EagleFalconn		-	X
Thunderbird2		-	X
MJCdetroit		X	-
Jimp		-	X
Flying Jazz		-	X
OwenBlacker		X	-
Blank		-	-
Blank		-	-
Blank		-	-

Discussion

I’ve decided not to vote in this particular poll because it derives from the five-option which leaves out a reasonable option that would also suffice as a compromise candidate here. This is the less-restrictive variation Woodstone refers to and which I support: that uppercase ell should always be used for liter, with either ml or mL being chosen and consistently used within the article (i.e., no mixing of ml and mL), as is traditional for the subject. The option being offered for a vote is essentially a mandate for “all L” since any use of liter as a measure drives mL as the sole choice. Given the wider real-world usage of both types of fractionals, the more lenient Woodstone and I prefer is IMHO likely to garner broader support – or at least we should test for it. Askari Mark (Talk) 00:01, 11 August 2008 (UTC)

That expresses perfectly what I thought I'd voted for (second column "4"). Tony (talk) 00:40, 11 August 2008 (UTC)

• Are you guys saying that if we leave off point #3 from the top greenbox, then you would like it? We can always add a whole ‘nother voting section. Greg L (talk) 01:14, 11 August 2008 (UTC)

Yes. That’s essentially what I thought we were originally agreeing to. (See my variant proposal on Ilmari Karonen’s suggestion above.) Askari Mark (Talk) 18:02, 16 August 2008 (UTC)

Alternative two-option vote

All: Based on the following two comments above, starting with Askari Mark’s 00:01, 11 August 2008 post, I’ve posted an alternative vote that also accomplishes the widely supported objective of getting rid of “2 l”. As a “2 L”-only guideline, it would be less restrictive than all previous options considered so far; specifically, the following guideline would allow “ml” in articles that feature instances such as “2.5 L”.

• The internationally accepted unit symbols for the liter are both the uppercase L and the lowercase form (l). However, since lowercase L ("l") can be easily confused with uppercase i ("I") and the numeral 1 when using sans-serif typefaces, editors should write the unit symbols for the liter and its decimal multiples and submultiples as follows:

1. The un‑prefixed unit symbol for liter (L) should be only the uppercase L, (e.g., editors should write "A 10 L tank" instead of "A 10 l tank").
2. Prefixed versions of the liter (the decimal multiples and submultiples such as the milliliter and microliter) may be written with either the lowercase or uppercase L (e.g., either "A 200 ml bottle" or "A 500 mL glass of beer" is satisfactory), but the chosen style should be consistent so as to avoid the awkward mixing of styles.
3. Do not use the unicode "script ell" character ℓ and its variants (㎕, ㎖, ㎗ and ㎘).

The above rule-set clearly delineates the objectives of the guideline but does not have to be the actual wording of the guideline; wording such as as shown in the greenbox below could be used (as could any other wording that accomplishes the above objectives):

• With the SI, the accepted unit symbols for the liter are both the uppercase L and the lowercase form (l). However, since lowercase L (l) can be easily confused with uppercase i (I) and the numeral 1 when using sans-serif typefaces, the un‑prefixed unit symbol for liter should be only the uppercase L. Prefixed versions of the unit symbol (the decimal multiples and submultiples such as the milliliter and microliter) may be written with either the lowercase or uppercase L but the chosen style should be used consistently. Do not use the unicode "script ell" character ℓ and its variants (㎕, ㎖, ㎗ and ㎘).

---

Note that the below chart does not allow ~~~~ signatures to be used. You must copy/paste or hand-edit your signature. For assistance in writing your signature, you may copy the time below in red from the preview window after refreshing while in edit mode:

16:17, 9 November 2024 (UTC)

---

Place an X on the option you support

User	Link to comment	L only ml or mL	Remain silent
Greg L		X	-
Itub		-	X
Woodstone		X	-
EagleFalconn		-	X
Thunderbird2		-	X
Gerry Ashton		-	X
Tony		X	-
Jimp		-	X
Flying Jazz		-	X
Askari Mark		X	-
Blank		-	-
Blank		-	-
Blank		-	-

Discussion

• Woodstone: MOSNUM already has a blanket guideline that the first instance of units of measures should be spelled out: here. There is no reason to repeat that for every single unit of measure. Greg L (talk) 19:00, 11 August 2008 (UTC)

I know that—that's why I called it "blanket"—but I feared the wording was going to bypass that. And it does not only apply to the first instance. Abbreviations or symbols are only called for when a unit is used often. But anyway, the vote seems to go towards "silence". −Woodstone (talk) 19:20, 11 August 2008 (UTC)

Two 2-option votes: 3 options. I rank them thus:

1. remain silent
2. L only ml or mL, Don’t mix ml and L
3. L only ml or mL

JIMp _talk·cont 15:55, 12 August 2008 (UTC)

I support what seemed to be undisputed when this was being discussed before my break - L only; ml or mL; don’t mix ml and L. Remaining silent is totally unhelpful and ignores the whole point of the Manual of Style - people come here looking for answers, and we should provide them, even if it's only to say "either form is acceptable" I don't have time right now to go through the whole vast debate above, but can someone confirm that there is at least consensus for preferring L over l for unprefixed litre? If so, then that much at least can go back in the guideline.--Kotniski (talk) 09:01, 14 August 2008 (UTC)

Three-option vote

All: Kotniski and Jimp are correct in that there has been no clarification of preference between “L and no ml” and “L and either mL or ml” since the former was not included in the original mega-option poll. Accordingly, I’m expanding GregL’s alternate two-option poll to a three-option poll so that we can have a little more perspective. Askari Mark (Talk) 18:58, 16 August 2008 (UTC)

---

Note that the below chart does not allow ~~~~ signatures to be used. You must copy/paste or hand-edit your signature. For assistance in writing your signature, you may copy the time below in red from the preview window after refreshing while in edit mode:

16:17, 9 November 2024 (UTC)

---

Place an X on the option you support

User	Link to comment	L only ml or mL	L only no ml with L	Remain silent
Askari Mark		X	-	-
Woodstone		X	-	X
Teemu Leisti		-	X	-
Kotniski		X	XX	-
Tony		-	XX	-
Blank		-	-	-
Blank		-	-	-
Blank		-	-	-
Blank		-	-	-
Blank		-	-	-
Blank		-	-	-
Blank		-	-

Date autoformatting and blanket change

There is currently at least one editor removing date autoformatting from articles that have used it for a long time, so I am being bold and adding to date autoformatting section a paragraph that explicitly states:

Edit warring over the date autoformatting is unacceptable. If an article, that in not a stub, has evolved with or without date autoformatting, the whole article should conform to that method unless there is a consensus to change it.

Note the phrase "that is not a stub". I addwd this as a work around the valid problem raised by Greg L"(My emphasis.) That guideline encourages real contributions from editors rather than encouraging them to run out and start a near-worthless little stub of an article. ...".

Also I think this explicit exclusion of stubs should be added to all similar prescriptions in this guideline to discourage the formation of stubs just to work around these prescriptions. We added it several years ago to WP:MOS#National varieties of English for the same reason, because not everyone understands that the term "first major contributor" implies changing a stub to an article. Besides it may have the beneficial side effect of encouraging those with a passion for this issue to expand existing stubs to win the war. --Philip Baird Shearer (talk) 09:13, 14 August 2008 (UTC)

I've just reverted this sudden insertion. First, do you have any evidence of edit warring over this issue? Please point to it. Second, do you have even weak evidence that it's likely to occur? Certainly there's the direct opposite of any intention my part, which I've expressed in writing at least once. Third, to single out one issue for this guideline seems a little WP:POINTY; since ArbCom's distaste for "edit warring over optional styles" is already emblazoned at the top of MOSNUM. It seems redundant.

If this is simply an "I don't like it" pointy reaction to the popularity of the move away from mandatory DA, please join the debate on this page rather than pursuing unilateral legislative action without consensus. Tony (talk) 10:28, 14 August 2008 (UTC)

Again, I haven't been following the debates in detail, but from what I've read it seems there is almost total agreement that regular date linking is a bad idea. I would propose we acknowledge this consensus and simply state in the guideline that we don't link dates except in special cases where the link is likely to be useful. Edit wars would be even more effectively averted in this way, and we could all begin to enjoy the benefits of the reduced sea of blue.--Kotniski (talk) 10:45, 14 August 2008 (UTC)

Although I am in agreement that the move toward deprecating autodate formatting in an article seems to be reaching a consensus, that certainly hasn't been achieved as of yet. One of the primary reasons is that the original process/method/system is a long-standing one and the information has not yet filtered down through various project groups in order to achieve a consensus on this new direction. You may be right in seeing a consensus develop in the various comments on this page, but there is still considerable "resistance to change" evidenced in various project groups, notable the history sub-groups. FWiW Bzuk (talk) 10:52, 14 August 2008 (UTC).

I agree that we need a bold statement deprecating linking of

• date fragments
• full dates

Many articles have already had delinking of full dates. In the vast majority of cases, it stays that way. That seems to me to be de-facto consensus. It is the same with date fragments. I propose that autoformatting is given a separate page and we take the current phrase:Date elements that do not contain both a day number and a month should not generally be linked and change it to: Date elements should not generally be linked. Lightmouse (talk) 11:18, 14 August 2008 (UTC)

As implied by my above comments, I would strongly support this (maybe "dates and date elements..." would make it even clearer). Can someone give a link to the projects where this change is being resisted?--Kotniski (talk) 12:33, 14 August 2008 (UTC)

Ask Tony1, he seems to have taken the brunt of the criticism. I can give some particulars of one project group not in favour of change but he can elucidate on the overall contentious issues that have been brought up. FWiW Bzuk (talk) 12:43, 14 August 2008 (UTC)

Where is this supposed consensus that "regular date linking is bad" or that there is a move towards de-linking? There are a few vocal editors on this page that have said so, but reading through the reams of material on this page, there is no consensus.

Furthermore, there's an explicit statement on this guideline that already says don't link date fragments. And I for one would strongly object to deprecating linking of full dates. -- SatyrTN (talk / contribs) 15:34, 14 August 2008 (UTC)

Why? Full dates are just pairs of date fragments. As far as I can see the only argument for linking is that it allows this autoformatting tool to work. But since that benefits only a tiny minority of readers, and the benefit to them is negligible anyway, this argument hardly holds water IMHO. Are there any other arguments in favour of linking that I've missed?--Kotniski (talk) 17:02, 14 August 2008 (UTC)

• Question - What about the case of mixed formatting - some of this and some of that? This is true of most of the articles I come across of any length or age. As people add to an article, the formatting becomes mixed. How to decide? Go back through years of article history to see what formatting the beginning stub had and change all formatting to that? Allow the formatting to remain a hodge podge of mixtures? Even articles that start out with autoformatting often lose the consistency of formatting as the article continues. At least delinking allows a quick fix for the jumble of different auto formats. It also allows the jumble to be seen by editors, as the autoformatting disguises much of the inconsistency that the vast majority of unlogged in readers see. —Mattisse (Talk) 17:29, 14 August 2008 (UTC)
  • At that point I see no problem in using WP:BOLD and having an editor review the article and choose one method for everything except citations, which should use ISO format. Of course the editors changes need to be based on either the first date format, which may not be the right choice say when it is a US article with European date formatting. Or to the format used by the country in which the article is about. I don't have date conversions turned on and don't have a problem adjusting. I do dislike the variations within an article since in my opinion that hurts the perceived quality of the encyclopedia and I will fix them by hand if there are not too many. Vegaswikian (talk) 18:16, 14 August 2008 (UTC)

But is the date inconsistencies within an article that Wikipedia editors do not see with autoformatting. So they are oblivious to what the vast majority of readers see. —Mattisse (Talk) 19:27, 14 August 2008 (UTC)

Expand autoformatting

I'm still confused why every argument on this page is between "leave it the way it is" and "get rid of auto-formatting". Does no one see the benefits of expanding auto-formatting? So that all readers benefit from it? -- SatyrTN (talk / contribs) 19:48, 14 August 2008 (UTC)

Considering 99% of the readers of Wikipedia do not see autoformatting anyway, what would be the point? And how do you mean "expand"? Do you mean have more "preferences" and therefore more choices for the special Wikipedia editors to see and fight over? —Mattisse (Talk) 20:03, 14 August 2008 (UTC)

P.S. As I understand it, date autoformatting does not work as advertised anyway, and it is only recently that Wikipedia editors are beginning to realize this, as most of them do not see what the average reader sees. —Mattisse (Talk) 20:06, 14 August 2008 (UTC)

No, not more preferences. It would be trivial to expand the code so that readers who are not logged in see auto-formatted dates. And just as simple to determine what country the reader is in and present them with the date formatted in the standard for that country. It wouldn't be perfect, of course, but auto-formatting would then work for all readers, and would work correctly for a guestimate of 90% of readers. A much better figure than the current situation, and *far* easier to do than either removing auto-date links on millions of articles or convincing thousands of editors to change. -- SatyrTN (talk / contribs) 20:23, 14 August 2008 (UTC)

• Again, I fail to see the problem that this would save in the first place: the month–day, day–month order is so trivial. Why expand a function that hardly anyone wants? Tony (talk) 23:31, 14 August 2008 (UTC)

Again, I fail to see the problem that this would supposedly address: the month–day, day–month order is so trivial. Why expand a function that hardly anyone wants? Next, we'll be inventing tools for tweaking "colour/color" and "travelling/traveling". We should rejoice in the fact that this huge, big, baggy, widespread language of ours is extraordinarily cohesive, and has only minor variations in formatting and language that do not affect our reading (with the possible exception of a few lexical couplets such as "lift/elevator", but ... who's foxed by that, even?). Our month–day, day–month couple is a good demonstration of this triviality. By the way, you are all aware that the US military uses international date-formatting, aren't you. There were no complaints coming from that quarter, last time I looked. Canada uses both formats. I'm just pointing out that English is a big, supple beast, and we should not bother ourselves in trying to impose one format or another on IP regions. Satyr's query above: "Where is this supposed consensus that "regular date linking is bad" or that there is a move towards de-linking?". Um ... read a few gems here? Tony (talk) 23:47, 14 August 2008 (UTC)

The "problem that this would address" is consistency. You yourself argue vehemently against the YYYY-MM-DD format, and don't care about "Month day, YYYY" vs "day Month YYYY". But if all of those were auto-formatted, then all of them would be the same. Which, incidentally, also addresses the "reading flow" that Lightmouse mentioned above. And Tony1, "a few gems" does not make consensus.

You all are advocating a relatively major change - de-linking dates and "turning off" auto-formatting. As far as I can tell, the reasons you want those changes are two-fold: ugly links, and inconsistencies for non-logged in readers. What I'm proposing is a much easier solution to your issues: expand auto-formatting, and add a <div> around auto-formatted dates.

The advantage to expanding auto-formatting I've outlined above - consistency for all readers. If we then add a div around the auto-formatted dates, a CSS rule can be put in place to remove the blue underline. That addresses both your major concerns in an efficient and easy way. -- SatyrTN (talk / contribs) 02:20, 15 August 2008 (UTC)

SatyrTN I think that discussing an expansion (or contraction) of autoformatting is a discussion best held in another section. Can we please keep this discussion focused on whether the prescription at the top of this article about editwarring over styles applies to autoformatting or not and if it does whether we need a specific expression of it in this section.

SatyrTN's is an interesting idea but we (ordinary editors, including admins) are powerless to implement it. JIMp _talk·cont 04:08, 16 August 2008 (UTC)

Tony1 you seem to want your cake and eat it. If as you point out "since ArbCom's distaste for 'edit warring over optional styles' is already emblazoned at the top of MOSNUM. It seems redundant." Then it does not harm to add it if it applies and it is not clear to everyone that the ArbCom decision also applies to this issue as well as other date changes. An editor who has been changing a lot of pages is user:Colonies Chris (about 40 pages yesterday). CC has changed the date style of the article minor campaigns of 1815 twice (17:54, 20 July 2008,22:50, 13 August 2008) without discussing the change to date format on the article's talk page before changing them for a second time.

Kotniski. If a page has had linked dates and some editors wish to keep them (or vice versa) why not make it clear that the current style has precedence if there is a disagreement between editors over the linking issue, or do you want to force people to accept you point of view? --Philip Baird Shearer (talk) 09:13, 15 August 2008 (UTC)

Mr Shearer, consensus does not work like voting: real arguments are needed to support either side, and "I like it" and "I don't like it" are not such arguments. A decision should be made in each case based on the merits and shortcomings of keeping or discarding date links; there is no such thing as "we disagree, so the previous mess has precedence". People disagree for very specific reasons, or at least they should. And considering that there are few real benefits that auto-formatting can pride of, and many more problems surrounding it (see my essay for details), it will take some good reasoning to retain auto-formatting in an article. Waltham, The Duke of 09:57, 15 August 2008 (UTC)

RESPONSE by Tony1: I thank Philip Baird Shearer for drawing to our attention a prime example of why date autoformatting should be removed more generally. The diffs he has supplied above for Minor campaigns of 1815 show that User:Colonies Chris not only removed numerous low-value bright-blue dates that were diluting the useful links, but manually fixed spelling and MoS breaches such as “March 15th, the use of title case in a section heading, and the use of curly glyphs. Chris's attempts to audit and improve the article were no quick and dirty fix using a script: they were script management at its best, with a significant element of skilled human oversight.

Let's compare the opening and a subsequent phrase of the original autoformatted version with Chris's DA-free version. The article uses the international date format preferred by some Canadians, the US military, and most English-speakers in other countries. I've arranged it so the we all see what almost all of our readers have always viewed: the raw date in linked blue.

Original

On 1 March 1815 Napoleon Bonaparte escaped from his imprisonment on the isle of Elba,... the destruction of the power of Napoleon Bonapart and the restoration of the Bourbon Dynasty under King Louis XVIII on 8 July 1815 ...

Chris’s DA-free version

On 1 March 1815 Napoleon Bonaparte escaped from his imprisonment on the isle of Elba,... the destruction of the power of Napoleon Bonapart and the restoration of the Bourbon Dynasty under King Louis XVIII on 8 July 1815 ...

By reverting back to the original, Philip has damaged the article, making it harder to read and significantly reducing the visual clarity of the high-value links.

The article contains many high-value links, in which the advantages of avoiding dilution and colour distractions of low-value blue is manifest. Here are two examples that Philip has degraded by reversion. I've capped them to save space.

Example 1 comparison

Original

Marshal Suchet had received orders from Napoleon to commence operations on 14 June; and by rapid marches to secure the mountain passes in the Valais and in Savoy (then part of the Kingdom of Sardinia), and close them against the Austrians. On 15 June, his troops advanced at all points for the purpose of gaining the frontier from Montmeilian, as far as Geneva; which he invested. Thence he purposed to obtain possession of the important passes of Meillerie and St. Maurice; and in this way to check the advance of the Austrian columns from the Valais. At Meillerie the French were met and driven back by the advanced guard of the Austrian right column, on 21 June. By means of forced marches the whole of this column, which Baron Frimont himself accompanied, reached the Arve on 27 June. The left column, under Count Bubna, crossed Mount Cenis on 24 June and 25 June. On 28 June, the column was sharply opposed by the French at Conflans; of which place, however, the Austrians succeeded in gaining possession.

To secure the passage of the river Arve the advanced guard of the right column detached, on 27 June, to Bonneville, on its left; but the French, who had already fortified this place, maintained a stout resistance. In the mean time, however, the Austrians gained possession of the passage at Carrouge; by which means the French were placed under the necessity of evacuating Bonneville, and abandoning the valley of the Arve. The Austrian column now passed Geneva, and drove the French from the heights of Grand Saconex and from St. Genix. On 29 June, this part of the Austrian army moved towards the Jura; and, on 21 July, it ...

Chris's DA-free version

Marshal Suchet had received orders from Napoleon to commence operations on 14 June; and by rapid marches to secure the mountain passes in the Valais and in Savoy (then part of the Kingdom of Sardinia), and close them against the Austrians. On 15 June, his troops advanced at all points for the purpose of gaining the frontier from Montmeilian, as far as Geneva; which he invested. Thence he purposed to obtain possession of the important passes of Meillerie and St. Maurice; and in this way to check the advance of the Austrian columns from the Valais. At Meillerie the French were met and driven back by the advanced guard of the Austrian right column, on 21 June. By means of forced marches the whole of this column, which Baron Frimont himself accompanied, reached the Arve on 27 June. The left column, under Count Bubna, crossed Mount Cenis on 24 and 25 June. On 28 June, the column was sharply opposed by the French at Conflans; of which place, however, the Austrians succeeded in gaining possession.

To secure the passage of the river Arve the advanced guard of the right column detached, on 27 June, to Bonneville, on its left; but the French, who had already fortified this place, maintained a stout resistance. In the mean time, however, the Austrians gained possession of the passage at Carrouge; by which means the French were placed under the necessity of evacuating Bonneville, and abandoning the valley of the Arve. The Austrian column now passed Geneva, and drove the French from the heights of Grand Saconex and from St. Genix. On 29 June, this part of the Austrian army moved towards the Jura; and, on 21 July, it ...

Example 2 comparison

Original

On 5 July the main body of the Bavarian Army reached Chalons; in the vicinity of which it remained during 6 June. On this day, its advanced posts communicated, by Epernay, with the Prussian Army. On 7 July Prince Wrede received intelligence of the Convention of Paris, and at the same time, directions to move towards the Loire. On 8 July Lieutenant General Czernitscheff fell in with the French between St. Prix and Montmirail; and drove him across the Morin, towards the Seine. Previously to the arrival of the IV (Bavarian) Corps at Château-Thierry; the French garrison had abandoned the place, leaving behind it several pieces of cannon, with ammunition. On 10 July of July, the Bavarian Army took up a position between the Seine and the Marne; and Prince Wrede's Headquarters were at La Ferté-sous-Jouarre.

Chris's DA-free version

On 5 July the main body of the Bavarian Army reached Chalons; in the vicinity of which it remained during 6 June. On this day, its advanced posts communicated, by Epernay, with the Prussian Army. On 7 July Prince Wrede received intelligence of the Convention of Paris, and at the same time, directions to move towards the Loire. On 8 July Lieutenant General Czernitscheff fell in with the French between St. Prix and Montmirail; and drove him across the Morin, towards the Seine. Previously to the arrival of the IV (Bavarian) Corps at Château-Thierry; the French garrison had abandoned the place, leaving behind it several pieces of cannon, with ammunition. On 10 July, the Bavarian Army took up a position between the Seine and the Marne; and Prince Wrede's Headquarters were at La Ferté-sous-Jouarre.

Now, I respect Philip as an editor: he makes a valuable contribution to the project, and I've seen his work at "Naming conventions" and "WikiProject MilHist". However, I'm disappointed to see aggressive posts at Chris's talk page in which Philip threatens Chris with blocking over the matter; I trust that this could never be interpreted as an attempt to use administrator status to prosecute a political agenda. In particular, I'm concerned that Philip has erroneously cited MOSNUM's "prohibition on changing date formats" to support his threat. "Date formats" in that MOSNUM section clearly refers to US vs. international date formats, not to whether autoformatting is used or not used. As an admin, we look to Philip to encourage a calm, equitable environment in which to conduct business, and to cite guidelines with honesty. On a final note, I wonder whether he might be persuaded to support the cause. Tony (talk) 14:22, 15 August 2008 (UTC)

Tony1 I did not say I would block an editor with whom I am having such dispute, not I would not block an editor which whom I am having such a dispute. But if a person alters a page (not once but several times) just to make a change to dates, (or spellings, or refe tags etc) and I am not an involved editor, I would probably block their account for a while, if they had not engaged in a conversation about the changes on the article's talk page. Equally in a case where I am involved in such a dispute, I would ask an uninvolved administrator at ANI to look at such a behaviour. Generally edit warring over such issues is seen as disruptive to wikipedia. As to your point

Tony1, I am confused you wrote earlier in this article "since ArbCom's distaste for 'edit warring over optional styles' is already emblazoned at the top of MOSNUM. It seems redundant." Yet now you seem to be arguing that it does not apply to this section. Which is it? --Philip Baird Shearer (talk) 15:29, 15 August 2008 (UTC)

Indeed, you haven't addressed my accusations above, which are serious. WRT this "edit warring" frenzy you've got yourself into, changing a page once, twice, even three times, if it were to occur, is suddenly edit warring because you decide to define it as such. You have no right to bandy about threats as you've done, let alone take action. You'd find yourself the subject of a complaint if you ever did. Tony (talk) 15:48, 15 August 2008 (UTC)

Philip, don't be confused. Edit warring is prohibited, everywhere. You know that and I know that. Again, please point to edit warring over the DA. This appears to be an emergency you've concocted to support your "I don't like it" argument. But on a positive note, I'd like to know your reactions to the comparisons above, of the opening of Minor campaigns of 1815 and the two longer examples under the caps. How do you feel about the contention that the high-value links are better served in the company of plain black dates, and the look and readability of the page are better with less colour-clutter? Tony (talk) 23:59, 15 August 2008 (UTC)

Unlike some readers, I am not fussed over the number of links in an article, I have read enough web pages, for it not to bother me, and I realise that under-linking or over-linking is like so much else about the appearance of a Web page a matter of opinion. In general I do not support re-linking a name or phrase when it already has a link higher up the page, not for the sake of the reader, but because it make edit maintenance easier. As an editor I do not like large trivial changes to pages as it makes checking the edit history for substantial more difficult than it needs to be. For example some editors like to go through an article and change all the section headings ("== Section ==" to "==Section==" with or with out a blank line afterwards or vice versa) and remove double spacing at the start of sentences in paragraphs. Such changes have no visible effect for the people reading the page, but they mess up the history of articles. If the edit history was not important, we (editors) would not care if two editors were to edit war over such an issue until doomsday as it would not effect the reader's perception of the article. But editors do care about such issues because it affects the edit history of the article. --Philip Baird Shearer (talk) 09:19, 16 August 2008 (UTC)

In response to the hysterical suggestions that have been made that I've been edit-warring over date linking, I'd like to make clear exactly what I did, when and why. I first edited Minor campaigns of 1815 on 20 July; my primary purpose was to correct Luneville to Lunéville (this was clearly stated in the edit summary). I also made a number of other small fixes, and I unlinked the dates, using the regexes I've set up within AWB. Several weeks later, on 13 August, I returned to this article while I was in the process of fixing the typo "Coprs" for "Corps" in all the articles in which it occurred (this too was clearly stated in the edit summary). I also made some more small corrections and, as a matter of course, unlinked the dates (I didn't remember that I'd ever worked on that article before, so it didn't occur to me that they had since been relinked.) So it was an unpleasant surprise to me to find myself the target of some extraordinary hostility and insinuations of edit warring. I have stated on several talk pages that if there is a consensus that the readers of any particular article would be better served by having its dates linked, I would respect that. I have no absolutely no intention of edit warring over this. And I'm pretty annoyed at the churlish attitude of editors who are willing to complain and even to threaten me over my date link changes, whilst failing to acknowledge my other improvements to the articles, which they have retained. Colonies Chris (talk) 23:59, 15 August 2008 (UTC)

The suggestion was not hysterical -- Please note that I did not draw this to your attention until you did it for a second time on the same article. How many times should you automatically change an article from one style to another without discussing the changes on the talk page before you behaviour become disruptive? "so it didn't occur to me that they had since been relinked", why not? Are you suggesting that every time you edit an article you will strip the date links whether or not such a change by you (or someone else) has been reverted, and that you will not discuss such changes on the talk page? I would suggest that the better cause of action would be to look through the history of an article and its talk page before making universal changes such as these. --Philip Baird Shearer (talk) 09:19, 16 August 2008 (UTC)

The relevant guidance is that "If an article has been stable in a given style, it should not be converted without a reason that goes beyond mere choice of style." I think Tony's method is fine (generally, posting on the talk page to present reasons for the change and invite comment, and converting only a few pages per day), but converting "as a matter of course" using AWB is probably undesirable. I think you are probably on the wrong side of the general guidance on these matters, so I don't think it makes sense to be annoyed that people are complaining. As the person seeking to convert an article from one stable style choice to another, the burden is on you to establish consensus if the change is disputed. Christopher Parham (talk) 01:01, 16 August 2008 (UTC)

No unwarrented changing to and from international and US formatting is one thing but to say those articles which had till now had their dates linked should keep them linked overlooks an important detail: in the past date linking was mistaken for a good thing encouraged by the MOS. No surprise that it was done—it was the done thing. Now comes the realisation that it should never have been dreamt of. It's no long the done thing. Allowance need be made for it and the damage it brought to be undone. JIMp _talk·cont 04:08, 16 August 2008 (UTC)

Your statements don't reflect the current guidelines, however, which indicate no preference between autoformatted and non-autoformatted dates. If a consensus is established that autoformatting is harmful, then removing it systematically will be a different matter, but at the moment your preference is a personal one rather than one that has been established by the community as a whole. Christopher Parham (talk) 05:56, 16 August 2008 (UTC)

It still falls into BRD and if anything, this forum has brought that discussion to the fore. As more and more discourse is taking place, editors are beginning to see the advantages of a clear and unambiguous style/format. FWiW, after extensive anecdotal evidence, there is an understanding that ISO dating does not even come close to meeting that standard. Bzuk (talk) 06:12, 16 August 2008 (UTC).

Christopher, your statement "the burden is on you to establish consensus if the change is disputed" [my italics] is perfectly reasonable, since edit-warring is globally disparaged, and no one wants it. But User:Colonies Chris has been doing anything but edit warring (he's explained his revisit to the article at issue and his error in assuming it was for the first time). I know of no one removing DA who has ever taken a resistant approach, once there's a single person objecting on a talk page; if that has ever occurred, please let me know and I'll pay them a visit: to be combative would undermine our primary objective of persuading the community; politeness and a willingness to give way is of the essence. I appreciate your cautious approach, and stability is certainly a virtue, but so is being bold—otherwise WP would be a petrified tree trunk, unable or unwilling to adapt to the fluid environment of the Internet. On this issue, the consensus for change is overwhelming. Tony (talk) 06:43, 16 August 2008 (UTC)

No, my statements don't reflect the current guidelines. Those guidelines neither encourage nor discourage, neither prescribe nor forbid, the linking or delinking of dates. The absence of any preference between autoformatted and non-autoformatted does not entail a ban on the switch from one to the other. I'm not really attempting to reflect what the guidelines are but give my view on what they should and should not be. I'm stepping beyond the current guidelines. This section began with such a step: a notification that a certain change to the guideline had been made. The change was reverted by Tony. I'm coming out in support of Tony's move. Autoformatting is harmful, no, not all agree ... not yet ... but the word is out and the realisation of the truth of this is growing. The consensus is strong and ever strengthening. JIMp _talk·cont 07:10, 16 August 2008 (UTC)

Jimp no reasonable editor objects to someone being bold and removing all the date links in an article (or for that matter adding them to an article), but if those changes are then reverted, then before a change made again it is better if a consensus is reached on the talk page. That this is being discussed here shows that such guidance is needed in this section. --Philip Baird Shearer (talk) 09:19, 16 August 2008 (UTC)

PBS, you aren't listening to me. I very clearly stated above "I didn't remember that I'd ever worked on that article before". I was not consciously going against your preference, it was an honest mistake. Assume good faith. My practice in this matter is clear and can be seen from my edits and from my talk page. If an editor objects to the de-linking, I explain my reasoning. If they still object, I let it go. It's not important enough to get onto a war about. There's something about this subject that seems to drive some editors into a frenzy - their attachment to date linking goes well beyond rational consideration of the merits and demerits of the technique. I've been publicly accused of disruptive behaviour and vandalism, and had my work described as 'trash' over this - see the discussion (if you can call it that) with User:BillCJ on my talk page, for example. I can say with some pride that I've made a lot of valuable (mostly gnoming) contributions to WP over the last couple of years, and I'm pretty sick of being treated as though I were just some random vandal or troll. Colonies Chris (talk) 10:02, 16 August 2008 (UTC)

Philip, no, no reasonable editor would object to the removal of all the date links in an article. So how does that fit with this?

If an article, that in [sic] not a stub, has evolved with or without date autoformatting, the whole article should conform to that method unless there is a consensus to change it.

Is this not intended to be a deterrent against delinking? It's clear enough that most articles with dates have them linked. It's no secret why this is the case. This clause would unfairly put the burden of gaining consensus on those who would have dates delinked—it could even be interpreted as requiring that that consensus should be obtained before the change is made (of course this would be a misinterpretation but an easy one to make if you're unfamiliar with what consensus refers to around here).

Edit warring over the date autoformatting is unacceptable.

Edit warring is unacceptable. If an edit is reverted, take it to talk. If you can't get consensus, leave it alone. General rules need not be respelt for each instance and should not be respelt in such a way as to tip the balance in favour one position over another—not that this was necessarily the intent but it's how it reads to me. JIMp _talk·cont 15:06, 16 August 2008 (UTC)

As it is ambiguous whether linking is a style, and we are agreed that edit warring is unacceptable, then what is the harm in adding it as at least one and possibly more editors? The argument that it is covered by a general prohibition on edit warring would suggest that we ought to remove all statements in all the guidelines warning of this as it is not needed, is that your position? Please explain why "This clause would unfairly put the burden of gaining consensus on those who would have dates delinked—it" surly that is the current position if as you agree that "Edit warring is unacceptable". The clause would emphasise that if a bold edit is made (to link or unlink dates) and it is objected to (usually by a revert) the emphasis is on the person wishing to make the change to gain consensus on the talk page. --Philip Baird Shearer (talk) 10:42, 17 August 2008 (UTC)

By style I take it that you refer to style in the sense duscussed here as mentioned on this page ...

In June 2005, the Arbitration Committee ruled that when either of two styles such as 14 February or February 14 is acceptable, it is inappropriate for an editor to change an article from one style to another unless there is a substantial reason to do so. Edit warring over optional styles is unacceptable. If an article has been stable in a given style, it should not be converted without a style-independent reason. Where in doubt, defer to the style used by the first major contributor.

... and the main MoS page.

It is inappropriate for an editor to change an article from one style to another unless there is a substantial reason to do so; for example, it is unacceptable to change from British to American spelling unless the article concerns an American topic. Edit warring over optional styles is unacceptable. If an article has been stable in a given style, it should not be converted without a reason that goes beyond mere choice of style. When it is unclear whether an article has been stable, defer to the style used by the first major contributor.

The examples found there (e.g. AD vs CE, 14 February vs February 14, colour vs color) dispell any doubt in my mind that the intended sense of style implied here did not cover linking.

You write "as at least one and possibly more editors ..." There's a fragment missing from this clause. The argument that it is covered by a general prohibition on edit warring would only suggest that we ought not go overboard with such statements.

You ask "what is the harm in adding it ... ?" What is the good? I have argued that this addition is an unnecessary discouragement against delinking. The emphasis placed here, although you may argue that it goes not further than the current guidelines, tips the balance in favour of the status quo. Those unfamiliar with WP's ins and outs could well read this as MOSNUM's taking a stand in favour of keeping things are they are, which they'll generally find to be retaining a bunch of useless links. Is this not your intention?

In any case, you made a bold edit, it was reverted, you tried to gain consensus on the talk page and it looks to me like you didn't quite manage. Shall we not move on? JIMp _talk·cont 17:32, 17 August 2008 (UTC)

So you oppose stating the obvious because the obvious might be "an unnecessary discouragement against delinking", surly that is an indicator that it ought to be added if indeed it is not obvious, which your opposition would seem to support. --Philip Baird Shearer (talk) 00:17, 18 August 2008 (UTC)

Essay on the evils of date auto-formatting

I haven't partaken in the fun here for quite some time; I have only just caught up, actually. I've been busy, instead, mountain-hiking, beach-going, television-watching, and...

...writing User:The Duke of Waltham/Auto-formatting is evil. There is now a centralised location where the arguments against this controversial practice can be found. I hope you'll find it interesting. Waltham, The Duke of 22:25, 14 August 2008 (UTC)

Read and endorsed. --Elliskev 00:30, 15 August 2008 (UTC)

Read as far as "Useless to most readers" 2008-08-15, and saw it didn't address the issue fairly. Stopped reading. (sdsds - talk) 16:05, 15 August 2008 (UTC)

• This is why—at the very least—I suggested adding a footnote (∆ here) to the table of date formats, to produce this.
  This is not saying that dates in the ISO format should not be used; you wouldn’t even want this tool for producing an ISO-formatted date. If an editor wants a date formatted like 2008-08-14, then just type it in. I’m just baffled that this tool even exists. There is no justification for having a *formatting* tool where one codes [[2005-08-06]] so that we (the 0.1% minority privileged registered editors) can see something nice, like either August 6, 2005 or 6 August 2005, whereas the vast majority of regular readers throughout the English-speaking planet see nothing at all so nice; they see only  2005-08-06 in body text.
  I just don’t think some editors here are “getting” this. Let’s say an editor codes as follows:
  Two airplanes were deliberately flown into the [[World Trade Center]] on [[2001-09-11]].
  …we registered editors, the privileged Eloi see this if we’re A) registered editors, and B) have set our user preferences setting, and C set it to the U.S. customary date format:

Two airplanes were deliberately flown into the World Trade Center on September 11, 2001.

And other privileged editors see this if we’re we’re A) registered editors, and B) have set our user preferences setting, and C set it to the UK/European customary date format:

Two airplanes were deliberately flown into the World Trade Center on 11 September 2001.

But… if you are 99.9% of the rest of the planet (regular I.P. users), they see the following:

Two airplanes were deliberately flown into the World Trade Center on 2001-09-11.

I wasn’t aware that Wikipedia existed so editors and developers here could optimize it to produce gorgeous looking articles just for us editors and someone around here decided that everyone else (99.9% of Wikipedia’s readership) can just put up with poorly crafted text. Who blew this tool out their butt and declared it gold?!? 02:20, 15 August 2008 (UTC)

Speaking of not getting it, Greg L, you're not hearing what I've said above. Instead of abolishing the tool, convincing thousands of editors to change their ways, and changing millions of articles...

Expand the tool. Make it so those 99.9% of Wikipedia's readership are shown the autoformatted dates. That totally addresses your point, "fixes" the system, and does so with the minimum effort. -- SatyrTN (talk / contribs) 02:31, 15 August 2008 (UTC)

• What the hell are you talking about? How about a big healthy dose of climbing down from out of my butt? I heard what you said about expanding the tool. And I answered you twice on that very issue. So, yes, I heard you, and yes, I answered you. Twice (17:52, 13 August 2008 post and 21:56, 14 August 2008 post), where I said “don’t hold your breath”. And the second time I starting out by addressing you by name. And my response now is the same as before:

But such tools currently don’t exist and the developer who ‘rules’ on this likes his damned blue links to trivia and seems to be entirely pleased with what they do so long as he sees what he likes when he’s logged in. So I’m not holding my breath waiting for properly conceived tools that will truly benefit the vast majority readers.

That wording comes from my 21:56, 14 August 2008 post and very similar wording can be found in my 20:26, 13 August 2008 post.

Again, the developer who created the tool *likes* it just fine. He or she has been asked on other occasions to fix it, but hasn’t. The developer *likes* the linking. Further, to make that tool work “equally for everyone”, that means it would have to work for non-registered I.P. users and that would require looking at the user’s I.P. address and using it to spoon-feed custom content. Such a radical, low-level feature is probably not a trivial task and would certainly require much internal discussion by the developers. So for the third time, there’s my response after “hearing” you. Got it?

So instead of fallaciously claiming I’m “not hearing what” you’ve written, why don’t you A) reciprocate by actually reading my response, and B) if you still feel that “someone should fix it”, why don’t you go do the bugzilla report and see how far you get?

Now the simple fact is that it is unlikely this tool will be repaired and upgraded to your liking anytime soon. In the mean time, it thoroughly junks up Wikipedia for the vast majority of users. Accordingly, editors shouldn’t be using it anymore until it is fixed.

And also—in the mean time—it is clear from your above post that absolutely no one is reading and understanding what others are writing here and it is an utter and total waste of my time and effort to reason with you. You can use whatever the hell tools you want and muck up Wikipedia with useless blue links to mindless trivia to your hearts content. I’m not going to link to trivia and the articles I have a hand in will actually be better off for it. Further, if editors want to use an *autoformatting* tool such as [[2005-08-06]], mistakenly thinking it produces formatted text for anyone but us editors, I can’t help it.

Just don’t put rules here on MOSNUM that let’s 8th graders loose with tools that allow them to format dates (read: sometimes *formatted* poorly and always linked to mindless trivia) on professionally written articles without giving me full and proper justification for me to revert that garbage and make the reversion stick per guidelines. With that much done, I don’t give a rip what you do when you write articles.

Like I said, if you want the tool fixed, please stop waiving your arms about how no one is listening to you (I did but apparently didn’t give you the response you hoped for). Just be quiet and go get the tool fixed by yourself; you’ll see first-hand just how long that will take (forever). Now I know why this forum is for dates and numbers. I couldn’t initially understand why there would be an entire forum with so much space devoted to dates? Now I know; this “date stuff” makes people… nuts!

Anyway, I am thoroughly disgusted with place. So goodbye. I will absolutely no longer deal with this issue and people like you. Greg L (talk) 03:57, 15 August 2008 (UTC)

Now I know; this “date stuff” makes people… nuts!

Well, that much is obviously true. Teemu Leisti (talk) 06:04, 15 August 2008 (UTC)

The proposition to expand autodate linking is inconsistent with the sentiments of the majority of editors who have responded on the topic of autoformatting of dates. Most see no advantage to the present system for the project as a whole, and that is very close to a consensus, while a sole vote on expansion is, IMHO, "whistling in the wind." FWiW Bzuk (talk) 06:16, 15 August 2008 (UTC).

I think that the expansion is effectively what I was advocating earlier on this page. That there should be a formatting of dates for all users regardless of logged in or not and if they have chosen a format or not. That way there is consistency of full date format throughout an article regardless of the format that the individual dates in an article are in. Then there is no argument about which format the date should be in the text of an article as it does not matter and it does not have to be consistent either. Keith D (talk) 10:41, 15 August 2008 (UTC)

I am against any expansion of auto-formatting. Please see here for some of my reasons for this opinion. Basically, we should have consistency so that people can see it, instead of promoting inconsistency and then hiding it under the rug. This proposal, Keith, sounds as if there are people who want to avoid their responsibilities (solving problems instead of running away from them), which is bizarre, given that we are all volunteers here. Besides, WP:ENGVAR works just fine. The situation is not as black as some people might paint it. Waltham, The Duke of 21:46, 15 August 2008 (UTC)

Fractions - serious problem

We have a serious problem here. A lot of editor, for stylistic reasons, like to do this:

2<sup>1</sup>⁄<sub>2</sub>

which renders as:

2¹⁄₂

This is non-workable, because a copy-paste of this results in:

21⁄2

which is obviously counterfactual.

MOSNUM has to recommend that fractions be formatted one of the four following ways only:

• Plain text, with a hyphen between the whole number and the fraction (2-1/12)
• HTML, with a hyphen or non-breaking space between the whole number and the fraction (2-<sup>1</sup>⁄<sub>2</sub> or 2 <sup>1</sup>⁄<sub>2</sub> which render respectively as 2-¹⁄₂ and 2 ¹⁄₂). Furthermore, using the Unicode character for the fraction-slash instead of the character entity code is discouraged, because it makes it very difficult for many editors to tell whether the correct slash character is being used.
• Plain text using character entities or their Unicode equivalents, where these exist – these are only available for 1/4, 1/2 and 3/4 – with no hyphen or space (2½ which renders as 2½). Furthermore, these should not be used at all in articles that use other fractions, or in which it is plausible that future editors will use other fractions, than these three, since these will appear inconsistent with those others.
• A <math>...</math> contruct (I don't know enough about that stuff to give an example here; I've never touched it).

Templates that format fractions will have to be adjusted to compensate. — SMcCandlish [talk] [cont] ‹(-¿-)› 11:02, 17 August 2008 (UTC)

Use {{frac}} (or unicode). {{Frac|2|1|2}} gives "2+1⁄2" which copies and pastes as "2+1⁄2". Using spaces is not really how we write fractions and we certainly don't use hyphens, which look like minus signs. JIMp _talk·cont 11:30, 17 August 2008 (UTC)

This information seems to have been missing from the manual. I've just added it (please reword as appropriate).--Kotniski (talk) 12:46, 17 August 2008 (UTC)

The problem here is people who cut and paste without looking at the result. That's their fault, not ours — nor the templates'. Attempting to forestall it by a sentence here enormously exaggerates the attention paid to this page; the {{frac}} should be mentioned, and with luck will actually do some good. Septentrionalis PMAnderson 20:41, 17 August 2008 (UTC)

Clarity on auto-formatting dates?

Relevant discussion at

→ WT:Manual of Style (dates and numbers)/Archive 106#Clarity on auto-formatting dates?

Centralized discussion

As suggested above, this discussion has been added to the {{Cent}} template in order to gather a wider consensus. This has been on ongoing issue for a long time now, and there have been several discussions on the matter which have been archived. I support the proposal to discourage the auto-formatting of dates, and in my experience when people have been given the explanations of the disadvantages of auto-formatting, they tend to side with discouraging its use. In my experience people only tend to be in favour of keeping auto-formatting when they are not fully aware of all the disadvantages. I do hope this proposal is carried forward and MOSNUM is re-written to clearly discourage the use of auto-formatting. SilkTork *^YES! 12:34, 9 August 2008 (UTC)

I also came here via notice from the {{Cent}} template. I've always used DA, as I figured it was the best way to avoid the wrong date format, because the dates would be displayed according to user preferences. However, I had not heard the valid argument that very few readers are actually registered users, or if they are registered users than they have not set their preferences (come to think of it, I waited well over one year to set it). Now, looking at the disadvantages (and embarassed that this thought escaped me: most readers of this encyclopedia are actually readers), I have to support the deprecation of DA. Lazulilasher (talk) 16:20, 9 August 2008 (UTC)

I must say that I am against the removal of links from articles and would be against the removal of the DA or any weakening of this in the MOS. Some articles that have had the links removed that I have looked I would put the links back on but that would I am sure would end in edit wars.

I would rather that we seek to have a software solution implemented that allows for users to see dates in the format they wish and that a default wiki-wide or a localised format be used to present dates to those who are not registered or those who are registered and have not set their preferences. Also the display of a link or not should be controlled by user-preference, and a link to the corresponding article only made when explicitly required. May-be this could be achieved by the use of extra mark-up. It would be good if a proposal could be put together for a software change that would satisfy all camps and that could be presented to the devs with a large backing that may get them to act. Keith D (talk) 17:30, 9 August 2008 (UTC)

I agree that the wanton removal of date links wouldn't be best. If it were possible to have the devs work on something that could automatically format dates according to a user's location, that would be fantastic (but, I know nothing about that aspect of the project). Maybe there's something that could be implemented based on a user's ip address (again, I don't know what I'm talking about -- just an idea). My point above was that requiring of auto-format dates is not something I support. I would support their deprecation for the time being, with the caveat that we not wholesale reformat articles (as you are correct, I could forsee many edit wars). Lazulilasher (talk) 18:01, 9 August 2008 (UTC)

The problem we run into is that there are two kinds of changes that can be made in Wikipedia: editor changes and developer changes – and there is no way to force the developers to make changes they’re disinclined to implement. A number of proposals have been made that would require developer implementation, but these have not been successful. That leaves editors with only the tools at their disposal: encouragement or deprecation of usages via MOS.

I think what would satisfy most editors in this issue would be for autodates to be displayed highlighted as “links” – whether by boldface, underlining, coloration or any combination of those. It would also be great if the date display format option could be added to the menu (under “Toolbox” perhaps) for both non-registered and registered users to choose from. Registered users would retain a default preference, but then they could switch back and forth more easily – which would remedy the problem that registered editors using a preference currently miss, namely, the ability to readily see what an article looks like to those selecting no preference. I don't know how easy or difficult this would be to implement, though. Askari Mark (Talk) 00:30, 10 August 2008 (UTC)

It may be useful if you could give links to the failed proposals so that we can see what has previously been proposed and why the developers declined to implement them. Keith D (talk) 17:45, 10 August 2008 (UTC)

It would indeed – and I would try to do it if I had several days to waste going back through several pages’ archives full of mile-long threads full of contentious (and often vicious) discussion like those currently on this page, going back some 3 years. Sorry. Askari Mark (Talk) 23:18, 10 August 2008 (UTC)

Here's a shortlist to review.LeadSongDog (talk) 14:04, 11 August 2008 (UTC)

Thanks, LeadSongDog! Just for reference, there have also been discussions on the VP, the main MOS, and elsewhere, as I recall. Askari Mark (Talk) 19:04, 16 August 2008 (UTC)

I think the changes to date have been positive but would oppose discouraging the use of autoformatting. This choice should be left to the editors of individual articles, who are in the best position to assess the pros/cons in specific cases. I would prefer MOS to remain silent on the issue and leave it as an optional style choice. Christopher Parham (talk) 05:23, 10 August 2008 (UTC)

I hope that date autoformatting will eventually go away. Scripts or bots that strip out autoformatting will probably cause ill will. So I suggest that autoformatting be handled like citation templates currently are. If an article has been systematically laid out using one style, don't change it without local consensus. I would not mind if WP:MOS discouraged date autoformatting, but any removal should be gradual and should respect local sensitivities. EdJohnston (talk) 20:14, 19 August 2008 (UTC)

No consensus

The main advantage of seeking consensus regarding any issue is that in doing so, many alternatives get discussed. Have many alternatives to date-linking as a means of automatic date formatting been discussed? Where? Straw arguments like, "IP users or users who haven't set their prefs see a mish-mash" should be countered with, "Let's assign (even at random) a pref for these users so they see consistent dates." If that discussion hasn't already taken place, there can't be a true consensus on de-linking dates. (sdsds - talk) 18:07, 9 August 2008 (UTC)

Tony, I think this is now the right approach, as the topic has generated a lot of interest. I agree with you that a straight forward easy to read date system makes the most sense, that is why I also favour a written out date rather than the ISO dating presently in use. FWiW, I have now begun to re-edit some of the older articles I have authored and then lack of autoformatting of dates is seen in all of my newest efforts So far, no one has complained. Bzuk (talk) 18:16, 9 August 2008 (UTC).

FWIW, as a result of this discussion I have now redoubled my efforts to use only wikilinked ISO dates in articles which I start or to which I contribute. (sdsds - talk) 23:16, 9 August 2008 (UTC)

On Wikipedia, "no consensus" usually means "no change from status quo", so since linking all full dates has a long history of being the de facto date formatting standard on Wikipedia, this discussion doesn't seem to give anyone justification to start (especially wholsesale) de-linking full dates. Shawisland (talk) 00:38, 10 August 2008 (UTC)

On wikipedia "no consensus" usually means "let's put up up with the current shit because I don't understand why anyone would want to change this best of all possible worlds". As in this case of date autoformatting. --Malleus Fatuorum (talk) 00:47, 10 August 2008 (UTC)

Exactly: Shawisland assumes that "be bold" consensus is necessarily inferior to "keep it this way forever" consensus. Tony (talk) 00:45, 11 August 2008 (UTC)

Sdsds, please see MOSNUM's deprecation of ISO 8601 dates. Tony (talk) 00:47, 11 August 2008 (UTC)

Tony, is that an invitation to begin a discussion about why wikilinked ISO dates should become the new standard for the English language wikipedia? The guideline's assertion that they are "uncommon" in English prose assumes they will be presented to readers in that format. So perhaps un-wikilinked use of ISO dates might currently be "deprecated," although that term isn't used in the guideline. It is clear when they are wikilinked, it is only because enwiki chooses it to be so that they are shown in that format to readers who haven't expressed a preference for it. The obvious solution is to choose a format into which wikilinked dates are consistently transformed for readers who have no expressed preference, but allow readers with a preference to have them consistently transformed into the format that makes sense to them. You are of course correct that some dates shouldn't be autoformatted. Those are the only ones that shouldn't be wikilinked. (sdsds - talk) 20:01, 11 August 2008 (UTC)

Consensus

My understanding of the situation, taking into account previous discussions on this and other talkpages, is that there is a consensus to discourage and or change the auto-formatting of dates - but there is no consensus to keep the existing situation. What we are looking for here is both a wider consensus and for that consensus to be grouped in one place so that there are no objections when the MOS is changed. Objections above turn to agreement when the matter is fully considered. I do recall some kind of list of signatures which it might be useful to find, which indicated concern with the autoformating system. To say that there is no consensus here is to misdirect people arriving to take part in the discussion. SilkTork *^YES! 09:31, 11 August 2008 (UTC)

Hi, thanks for this summary of previous discussions. Could you please indicate where those discussions can be read? I have no desire to "misdirect", and certainly apologize if I have inadvertently done so. I share the general concern about the current autoformatting system. Is there someplace a proposal like the one I have floated (choosing a format arbitrarily for readers who haven't expressed a preference) has been discussed. If that discussion hasn't taken place yet, it may be premature to assert a well-reasoned consensus has been reached on the question! (sdsds - talk) 20:06, 11 August 2008 (UTC)

I've responded on Sdsds's talk page with the link to the notorious Bugzilla page. Tony (talk) 05:28, 12 August 2008 (UTC)

Proposal

As I have pointed out many times in the past, in spelled out dates, the distinction between the order being labelled by nationalities is at best weak, at worst fallacious. It has been suggested that the simplest solution is to adopt one preferred format fro spelled out dates, NN Month YYYY, or Month NN Year, it would be trivial to adopt this, and simple to impelment and probably not cause anyone any concern. Therefor in the next section I make such a proposal. Rich Farmbrough, 21:26 15 August 2008 (GMT).

Proposal

While any unambiguous date is acceptable fromeditors at large, the MoS should recommend either

NN month YYYY or where space is limited, the ISO format YYYY-MM-DD

Rich Farmbrough, 21:26 15 August 2008 (GMT).

No, we should not. We have already decided against this; it violates WP:ENGVAR. Septentrionalis PMAnderson 21:42, 15 August 2008 (UTC)

Why should it do that? To prevent American editors being confused by the international format? I think Tony has said many times that we're all quite able to understand either April 29, or 29 April. But what does 2008-03-04 mean? --Malleus Fatuorum (talk) 21:32, 15 August 2008 (UTC)

More likely to ensure that American readers are confused. Both will stand out like a sore thumb in a passage of idiomatic American. Septentrionalis PMAnderson 21:52, 15 August 2008 (UTC)

They certainly will, it's an absurd suggestion. --Malleus Fatuorum (talk) 21:56, 15 August 2008 (UTC)

Americans constitute an important part of our readership (and editing body), and their primary date format, unusual as it otherwise is, should be respected. (Besides, it's as clear as the international one, so there are no readability problems there.) I oppose this proposal. Waltham, The Duke of 22:05, 15 August 2008 (UTC)

I'm opposed to this idea. WP has matured to manage the largely binary system of spelling superbly well, with robust and workable guidelines. There is absolutely no reason that our guidelines for the (raw formatting of) binary date-formatting system don't work equally well. In both cases—lexicogrammatical and date formats—management of the binary system requires a little planning and checking. We should be planning and checking everything. Tony (talk) 23:53, 15 August 2008 (UTC)

I'm not sure that this an ideal solution. I agree with Tony that the dual spelling system works well. However, it should be pointed out that the US military uses dd Month yyyy. I'm also pretty sure that not even one US reader would be "confused" by that format. --Elliskev 01:13, 16 August 2008 (UTC)

Oppose—The adoption of one preferred format would by no means be trivial, simple to impelment or cause no concern. The fact is that there'll never be agreement over which this preferred format should be ... we might as well wait for the autoformatting to be fixed. JIMp _talk·cont 03:01, 16 August 2008 (UTC)

Thanks for your comment, Jim. May I point out that your last clause was intended to be ironic (cf, wait till the cows come home)? I had to read it twice to work it out. Tony (talk) 04:09, 16 August 2008 (UTC)

... home to the icy wastelands of Hades. JIMp _talk·cont 05:05, 16 August 2008 (UTC) ... singin' Dixie. JIMp _talk·cont 05:08, 16 August 2008 (UTC)

I think it should be as it is now - American subjects (or those where American date format is used, such as Canada, the Philippines, Taiwan etc) use American dates, subjects in countries which use international date format use international format, and with others where either is possible, consistency is to be observed regardless of the format adopted. As long as the full variety of the month is used, this should never be ambiguous, and should keep most readers happy. Orderinchaos 08:17, 16 August 2008 (UTC)

Whilst either format is acceptable - newspapers around the world tend to use American Dating and the world hasn't fallen apart (well, maybe it has, but not because of date formats) - editors are going to prefer one format over another and we would get some bitter disputes. As we have had in the past. The current system works, we manage inernationalisation issues in other things such as spelling and units of measurement well, and unless there's some technical solution on the horizon, we should keep things as they are. --Pete (talk) 11:33, 16 August 2008 (UTC)

The present arrangement is almost perfect and should not changed including the dualistic co-habitation of both date styles: In June 2005, the Arbitration Committee ruled that when either of two styles such as 14 February or February 14 is acceptable, it is inappropriate for an editor to change an article from one style to another unless there is a substantial reason to do so. Edit warring over optional styles is unacceptable. If an article has been stable in a given style, it should not be converted without a style-independent reason. Where in doubt, defer to the style used by the first major contributor. See: Wikipedia:Manual of Style (dates and numbers)--Thomaq (talk) 16:03, 16 August 2008 (UTC)

No, I disagree with this proposal. Long-standing convention on this page in this respect is fine. SandyGeorgia (Talk) 03:11, 17 August 2008 (UTC)

I'd like to point out that the problem would not lie with just American users being disconcerted with reading them. After all, they'll be inputting dates as well, and ISO or no ISO, it will be a natural habit for them to mistakenly enter the numerical digits in American date order, which will cause problems all around. Askari Mark (Talk) 18:19, 18 August 2008 (UTC)

It doesn't matter if people input dates in any format. The MoS is not a constraint on editors, it is designed to be something to which WP can move, giving a better result for all the reasons a MoS is usually used. Let me stress both formats are extensively used in most places, this has been portrayed as US vs international - it is not. Similarly with spelling and punctuation, we don't castigate editors or have flame wars over such things, just quietly and quickly bring them into line with the WP way. Rich Farmbrough, 15:37 20 August 2008 (GMT).

Another proposal

Reading the discussion above, it seems that some people think that (a) producing links from auto-formatted dates is bad because it results in lots of unneeded links from dates, and that (b) defaulting the autoformatting to ISO-standard is bad because that format is confusing to most readers.

I agree with both of these points. However, I think autoformatting dates is useful, so that people can see the dates in the format they prefer; and that for inputting the dates, the ISO standard is the best solution, since it makes dates easily searchable in articles.

Therefore I propose the following solution, which would (1) deprecate date-linking while (2) preserving auto-formatting and (3) making the default formatting understandable to the average person.

If the year is unnecessary or repetitive, it would also be possible for users to input only the month and the day-of-month. The output would, again, depend on the user's settings, and the default output for the non-logged-in would be readable.

However, it would be mandatory to input dates in ISO format, either as [[yyyy-mm-dd]] or as [[mm-dd]], depending on whether the year is specified or not.

What you must type	What logged-in registered users will see (settings on first row; other settings could also be available)						What others (i.e., not-logged-in and non-registered users) will see
	1999-12-31	1999 December 31	December 31, 1999	31 Dec 1999	31 December 1999	No preference
[[2012-02-29]]	2012-02-29	2012 February 29	February 29, 2012	29 Feb 2012	29 February 2012
[[02-29]]	02-29	February 29		29 Feb	29 February

(Table inspired by the one by Greg L in section "Autoformat quick-question" above.) Teemu Leisti (talk) 06:40, 17 August 2008 (UTC)

I don't think this would work... First of all, the ISO format is confusing for many people, and the fact that it would only be visible in the edit window does not help things. We call on our readers to be bold and edit, don't we? We don't want to confuse them even more than they already are. :-) And, in any case, much of our readership resides in the United States, and they wouldn't like seeing a default international date format.

All that said, even if it gains consensus as an idea, it remains unlikely to be applied. Apart from the clearly undesirable links, there are several issues with auto-formatting, including its inability to handle date ranges and slashed dates. We need more sophistication for anything like this to work. Waltham, The Duke of 09:05, 17 August 2008 (UTC)

I see your point. Just one quibble: the default display format in my proposal would be 29 December 2012, which should be understandable to everybody. Teemu Leisti (talk) 07:33, 18 August 2008 (UTC)

There's much talk of extending/improving the system. Here's the sorry truth. We can't fix the autoformatting. We've tried asking for it to be fixed on several occasions. The requests have been ignored. It appears that the creators of this mess believe it to be good. Here's a notion: if you want it fixed, why not boycot this autoformatting; that might get their attention? JIMp _talk·cont 11:56, 17 August 2008 (UTC)

Well, in that case there's really no sense in expending any more energy on this question. Teemu Leisti (talk) 07:33, 18 August 2008 (UTC)

Hey Teemu, thanks for your good work in preparing that case (I'll be needing to learn how to construct exactly that type of table, so this will be a model for me). As for the content, I'm sorry to say that I think it's too complicated and not intuitive—imagine having to teach every existing WP and every newbie how to key in and what is rendered. And again, there's no problem in the first place. Nothing beats WYKIWYG: What You Key in Is What You Get. Plain, intuitive, and simple, both for us and all of our readers. Tony (talk) 12:29, 17 August 2008 (UTC)

You're welcome. Perhaps you and Jimp are right, and we should just give up linking dates altogether. Teemu Leisti (talk) 07:33, 18 August 2008 (UTC)

As I've mentioned before, during the several times I've seen this debate rage, the general consensus has been that the best solution is one which the only the developers can implement. It sure would be informative to have one of them explain here why they cannot or will not. Askari Mark (Talk) 18:14, 18 August 2008 (UTC)

This proposal becomes a horrible mess for any date before 14 September 1752. --Gerry Ashton (talk) 18:27, 18 August 2008 (UTC)

Large numbers

According to Wikipedia:Manual_of_Style_(dates_and_numbers)#Large_numbers, commas are used to break the sequence every three places left of the decimal point; spaces or dots are never used in this role (2,900,000, not 2 900 000).

However, according to

• AIP [1],
• NIST [2],
• English Style Guide. A handbook for authors and translators in the European Commission [3] (page 26),

three−digit groups in numbers with more than four digits are separated by thin spaces instead of commas (for example, 299 792 458, not 299,792,458) to avoid confusion with the decimal marker in European literature.

Taking into account inherently international character of Wikipedia, should this rule be applied to MoS as well? --texnic (talk) 16:28, 17 August 2008 (UTC)

ISO 31-0 also refers to a 'small space' for that purpose. Lightmouse (talk) 16:58, 17 August 2008 (UTC)

I prefer the thin space but only if it vanishes on copy & paste, doesn't wrap, can be produced with a parser function, appears properly on the vast majority of machines and would be applied WP-wide. As for European literature, though, just about the only subset we need worry about is that from the British Isles, ie.e that in English, where we never use the dot as a thousands marker nor the comma as a decimal point. JIMp _talk·cont 17:44, 17 August 2008 (UTC)

This has been discussed at length in the past. No consensus coud be raised to use thin spaces. Even if there was the illusion of a consensus among the editors of this page, it would be unenforceable. --Gerry Ashton (talk) 18:23, 17 August 2008 (UTC)

Can we allow use of spaces as decimal separators without making it a strict rule? The point is that if one writes a new article and knows that there are the above mentioned recommendations and is accustomed to them, why should s/he still use the old-style notation? --texnic (talk) 15:13, 19 August 2008 (UTC)

Linking to years, again

I am having a disagreement with another editor over the implementation of the de-linking years in articles, in one specific context: in the lead of a biographical article, where the practice has been -- & AFAIK still is -- to link the years of the subject's birth & death. Even if the month & day are not known. As in this fictitious example:

Harvey J. Wallbanger (1940 - 1995) was an American activist for Alcoholics Anonymous.

Now I've looked through the MoS, & it does not offer any guidance about this specific use of link. Then again, I can't imagine that no one has considered this specific use of linking to years, & that a consensus has been stated somewhere. (My hope, obviously, is that the consensus is one that I would agree with.) Thanks for the pointer. -- llywrch (talk) 06:14, 18 August 2008 (UTC)

[WP:CONTEXT makes it quite clear: "In general, do not create links to [low added-value items] such as, 1995, 1980s, and 20th century." WP:MOSLINK and WP:MOS are consonant with this. Tony (talk) 09:03, 18 August 2008 (UTC) PS I can't locate this article you refer to. Tony (talk) 09:09, 18 August 2008 (UTC)

Either this person is fictitious, or there is an interesting story to find here; my search has yielded a cocktail with that name. :-) Waltham, The Duke of 11:54, 18 August 2008 (UTC)

I seem to remember this issue as partly about 'aesthetic linking'. People sometimes like to link date fragments because there is an associated full date with a link. I think some people like 'aesthetic linking' in tables and lists too.

• Harvey J. Wallbanger (1940 - 12 March 1995) was an American activist for Alcoholics Anonymous.
• Harvey J. Wallbanger (1940 - 12 March 1995) was an American activist for Alcoholics Anonymous.

I am not aware of any other reason and I think I would know if there were. Lightmouse (talk) 13:04, 18 August 2008 (UTC)

Perhaps a more interesting story is that of Harvey Wallbanger Jr, the famous racing buffalo. But we digress. Biographies normally use Template:Infobox Person with a nested template for tombstone dates. See Template:Infobox_Person#Example. They should be and usually are templated, so autoformat shouldn't kick in. LeadSongDog (talk) 15:38, 18 August 2008 (UTC)

Well, the templates produce autoformatted (i.e linked) dates, so I guess it does kick in. When date linking is finally deprecated, these date templates will hopefully be changed to remove the linking.--Kotniski (talk) 16:44, 18 August 2008 (UTC)

The above was meant only as an example, not as the article in question. (Please note my words "as in this fictitious example". I am amazed none of you noticed those words, & will refrain from any further observation or comments on it.) Either the practice of linking birth & death dates -- even if only the year is known -- is permitted in all lead paragraphs, nor none. -- llywrch (talk) 16:08, 18 August 2008 (UTC)

llywrch, please note that the comments above were intended as jests, not to be taken seriously. FWiW Bzuk (talk) 16:23, 18 August 2008 (UTC).

I don't care. Good bye. -- llywrch (talk) 21:37, 19 August 2008 (UTC)

Full date formatting

The major reason for insisting on two date formats is for compliance with autoformatting. If autoformatting is not going to be used then providing editors are consistent in an article, most of the other prescriptions on dates can go as well:

For example there is no reason why one should not write:

• The Battle of Hastings was fought on the 14th of October 1066.
• The Battle of Hastings was fought on October the 14th, 1066.
• The Battle of Hastings was fought on the 14^th of October 1066.
• The Battle of Hastings was fought on October the 14^th, 1066.
• The Battle of Hastings was fought on 1066-10-14.
• The Battle of Hastings was fought on 14/10/1066.

After all the arguments recently expressed on this page for removing autoformatting that readers can understand both the format "October 14, 1066" and the format "14 October, 1066" is equally true for the other formats. To accommodate the concerns those editors who do not agree, it could be suggested in this guideline, that a footnote explaining the format should be inserted next to the first date -- as is done with Old Style dates. --Philip Baird Shearer (talk) 10:01, 15 August 2008 (UTC)

The first ones to strike are #3 and #4; unnecessary superscripted text is discouraged because it makes reading harder and poses accessibility concerns. We then move on to Nos. 5 and 6, which are highly ambiguous because they do not spell out the month, causing confusion to European and North American readers alike (and yes, that includes the ISO format, with which not all readers are familiar—far from it). That leaves us with the first two, which constitute sloppy writing for reasons I am sure the honourable colleagues here can analyse better than I can. Even so, it's more or less common knowledge that these little words (the and of) fell in disuse quite a long time ago, and are hardly anywhere to be seen in written text, less so in a formal register like the one we use in an encyclopaedia. This doesn't apply exclusively to dates, but can also be seen in offices and titles like Director, Royal College, London. The ofs and thes are added mentally while reading such a title, but they don't have to be written, and are routinely omitted in text.

In any case, I don't find getting rid of auto-formatting a reason to abandon consistency in date-writing. Such consistency is one of the elements of good writing, and contributes to a more professional appearance for articles. Compromising this in order to introduce a needlessly complicated system, involving such additional clutter for intros like footnotes we could do without, does not sound like a good idea.

PS: You've slipped up: 14 October, 1066 is not a format—not with the comma, anyway. Waltham, The Duke of 10:22, 15 August 2008 (UTC)

So do you also object to "The Battle of Hastings was fought on 14th October 1066"? --Philip Baird Shearer (talk) 11:29, 15 August 2008 (UTC)

Predictably enough, I do. Waltham, The Duke of 13:42, 15 August 2008 (UTC)

Why? --Philip Baird Shearer (talk) 15:04, 15 August 2008 (UTC)

I have mentioned both ofs and thes, have I not? Waltham, The Duke of 21:59, 15 August 2008 (UTC)

• #1 and #2 are highly formal; but that may be desirable on occasion: either would do well in the lead, and the form works well in the colophon ("The chief effect of Harald Hardraadi's long and turbulent life was felt after his death in a place he had never been: the Battle of Hastings, on the 14th of October 1066.") We do not, and should not, adhere to a single monotonous level, imitating the worst of the Britannica's writing.
• We are not going to be consistent in date-writing. To say nothing of the practical matter that most articles will not comply with this page or care about it, we will encourage the use of two styles, radically and obviously different. Why jib at four?
• It would be worth warning editors that 14^th is often seen as old-fashioned; that "14th of October" is highly formal, and should only be used where the effect is intended; and that ISO can be confusing. Having deprecated them thus, is there any point to a prohibition? Septentrionalis PMAnderson 13:08, 15 August 2008 (UTC)

There are many ways to make an article boring, Mr Anderson, from which no variation in date formats can save it. There is engaging text, and there is annoying inconsistency; the former makes reading an article more worthwhile, while the latter simply distracts readers.

That we have not achieved consistency does not mean that we should not pursue it. We use two date formats because it is the minimum that can be achieved; each is the principal format for one of the two main components of our readership, and the two formats combined cover all English-speaking readers. We need no more formats.

Any style-related guidance of this kind is still a part of the Manual of Style, which is a guideline. It's optional to follow it, and using terms like "prohibition" creates the erroneous impression that it isn't. We don't block editors for using superscripted numbers. Waltham, The Duke of 13:42, 15 August 2008 (UTC)

I have always agreed that we should be consistent within an article. We will not be consistent between articles, and I would be surprised if a reader would be disconcerted by the change. He is not left with an unexplained inconsistency; she knows why it happened; xe clicked on a link. Septentrionalis PMAnderson 21:40, 15 August 2008 (UTC)

Let's drop the "little words" like "on" entirely:

• The Battle of Hastings was fought 1066-10-14.

Or alternately, let's allow editors to choose the number of "little words" as they see fit:

• The Battle of Hastings was fought on the fourteenth day of October in A.D. 1066.

These suggestions are not attempts at being silly. As we think about deprecating autoformatting, we really ought to think through the variations in formatting that will naturally arise (and be the subject of disputes). (sdsds - talk) 16:14, 15 August 2008 (UTC)

I support the latter. We are a collaboration; we should not go to enormous and fruitless effort to read like we aren't one. The wording of WP:ENGVAR could be usefully adapted, or we could just say leave well enough alone. Septentrionalis PMAnderson 21:40, 15 August 2008 (UTC)

We are a collaboration with the aim of taking articles to a specific standard of quality; the community has everything to do with the effort of taking the articles there, but this does not mean that the community should make its presence felt in the finished product. A featured article should avoid, if possible, every reference to itself, Wikipedia, and its community. Using writing formats incompatible with crisp, formal, encyclopaedic register just for the sake of doing so is ridiculous. And there need be no disputes if the guidelines of the Manual of Style are followed, guidelines the validity of which some people insist on undermining despite the need for them and the consensus upholding them. Waltham, The Duke of 21:59, 15 August 2008 (UTC)

I agree with the principle stated. None of these (first four, or ^th), however, is incompatible with a "crisp, formal, encyclopaedic register", and banning Ye Fourteeneth of Octobre is WP:BEANS. ;-> Septentrionalis PMAnderson 22:08, 15 August 2008 (UTC)

Hehe, good one. :-D But if all that the story's mother had said to her child was "behave yourself", he'd have fewer ideas to work with in the first place. We just need to state which styles we accept; leave it to the others to consider whether their own little ideas contradict the guideline or not. Waltham, The Duke of 22:30, 15 August 2008 (UTC)

No, what we need to do is treat our fellow editors like adults; say that this style and that one have disadvantages, and let them decide, based on what they happen to be writing, whether euphony or emphasis warrant the dangers. No one died and left us Jimbo's inheritance; to accept or refuse styles, or to belittle other editors' ideas. Septentrionalis PMAnderson 22:38, 15 August 2008 (UTC)

An orchestra cannot work without someone conducting, even with the mots experienced musicians. The same goes here: adults still need to be directed, and the greater the numbers, the more intense this need is. No matter how intelligent our editors are, without direction, chaos will ensue. (Actually, the more intelligent they are, the more bikesheds we'll end up quarrelling over.) Waltham, The Duke of 16:01, 18 August 2008 (UTC)

The first four examples above all seem quite compatible with crisp, formal, encyclopedic register. Depending on context, the two examples you disdain will often permit better-reading parallel structure. The example you give ("Director, Royal College, London") would be rather unusual in normal written prose; it would be "He was director of the Royal College" not "He was director, Royal College". Christopher Parham (talk) 22:42, 15 August 2008 (UTC)

It's so simple: "DD Month YYYY" or "Month DD, YYYY" (and maybe "YYYY-MM-DD" in certain specific cases) with the choice determined by ENGVAR-like rules. Nobody's belittling anyone: those who'd rather see "The Battle of Hastings was fought on the fourteenth day of October in the one thousand and sixty-sixth year of our LORD." are just as free as anyone else to come and see how their argument stands against the very reasonable call for consistancy such as that we see from Waltham. JIMp _talk·cont 02:50, 16 August 2008 (UTC)

Most solutions which begin with "it's so simple" are overlooking a large part of the problem. This is no exception. The four formats PBS began with are largely useful for special purposes; but they are useful for those purposes, and should not be deprecated for a spurious "consistancy". (Even ISO is sometimes useful; that's why it exists.) We should normally use the two formats Jimp prefers, but there is no reason to forbid the others. Septentrionalis PMAnderson 16:33, 16 August 2008 (UTC)

I don't understand this proposal; I thought we don't use ordinal suffixes on dates at all, so what is the proposal? SandyGeorgia (Talk) 03:08, 17 August 2008 (UTC)

Well, starting from the premise that consistancy is worth striving for where feasible it does become simple. Is the premise spurious? If so, much of the MOS can be deleted. JIMp _talk·cont 10:42, 17 August 2008 (UTC)

As I said at the start of this section: "The major reason for insisting on two date formats is for compliance with autoformatting. If autoformatting is not going to be used then providing editors are consistent in an article, most of the other prescriptions on dates can go as well." Your argument Jimp leads to total consistence across the project because it is feasible to implement such a style and spelling policy, but many would ague it is not desirable. --Philip Baird Shearer (talk) 10:48, 17 August 2008 (UTC)

Yeah, saw the claim at the top, repeated here ("The major reason for insisting on two date formats is for compliance with autoformatting.") I question that this was the case, Philip. And which came first, the chicken or the egg—the autoformatting mechanism that some developer cooked up or the rationale that the minimum number of formats the project needed to avoid significant disgruntlement was the big two, US and international? In any case, I think the project has moved on from whatever happened then. Dates, like spelling, seem to have happily evolved as a largely binary system in the main text. (Sure, the use of ISO dates in reference lists probably needs to be talked through over the next six to 12 months as we review the cohesion of the citation and other templates). But I think almost all WPians are content with US vs international dates, and would see no reason to engineer chaos in the absence of the double square brackets. Why would anything need to change? Tony (talk) 11:05, 17 August 2008 (UTC)

I don't see any advantage in letting loose and allowing whatever format whoever wants. Dates stripped of the thes, sts/nds/rds/ths and ofs are working fine. An argument for ISO dates is that they save space and are of consistant number of characters. An alternative we could use in lists/tables/etc. would be ordinar dates with the month abbreviated to three letters. Even the creators of autoformatting thought of this. JIMp _talk·cont 16:21, 17 August 2008 (UTC)

It is not our business to allow or disallow what our fellow editors choose to do; it is our business to advise what the consensus does do. If it were our business, it would be silly to issue an (unenforceable) blanket prohibition, ignoring all consideration of tone or euphony. Septentrionalis PMAnderson 20:29, 17 August 2008 (UTC)

Our business is to provide advice to those who should request it. If editors ask us "Should we use superscripted ths in text?", we advise them not to. If they don't like this advice, they shouldn't have asked for it, but they are free to ignore it. If they are unaware of the guideline, they are still free to continue their blissful ignorance. Terms like "blanket prohibition" are meaningless when a guideline is concerned, especially considering that "ignore all rules" is policy. Of course the individual needs of an article should be taken into account, but consistency has undeniable merits. This might be an international encyclopaedia, but it's still one encyclopaedia. It should also look like one. Waltham, The Duke of 16:01, 18 August 2008 (UTC)

Has anyone noticed how Wiki dates our contributions after the signature? Let's see... Saintmesmin (talk) 19:13, 21 August 2008 (UTC)

Date linking: User:Tony1

Tony1 (talk · contribs) is going through articles and using some sort of script to unlink all full dates in the article. He includes WP:MOSNUM in his edit summary, yet as far as I can see, there is nothing to say dates should no longer be linked. In addition, the usual guideline is not to change the format of dates except to make an aticle consistent, and I would have thought linking is covered by this policy too. Any comments or suggestions of how to proceed would be welcome. JRawle (Talk) 09:29, 19 August 2008 (UTC)

The user has replied to me and explained why he feels dates should no longer be linked. It seems reasonable to me. JRawle (Talk) 11:18, 19 August 2008 (UTC)

I take issue with it too. Tony's scripted changes today to Battle of Arras (1917) (a WP:FA) were rather abrupt to say the least. At a minimum, if he's going to do this, I'd expect edit summaries that link directly to an explanation without requiring a degree in forensics. LeadSongDog (talk) 16:16, 19 August 2008 (UTC)

I wasn't aware that an edit summary could link. Are you sure? If so, it's quite possible. Tony (talk) 00:15, 20 August 2008 (UTC)

• “Change” on Wikipedia, is never easy. Thank God for Tony1’s efforts in seeing this issue through to its natural conclusion. Auto-formatted dates should not be linked. And in my opinion, everyone should just forget worrying about what registered editors see and simply hard-code these *formats* straight to the default view that 99.9% of Wikipedia’s readers (non-registered readers) see: the last column in this table, which backhands the vast majority of our readership with the label “What *others* will see”. And as for that bottom option (coded [[2005-05-15]]), we might as well loose that one since 99.9% of Wikipedia’s readership sees only the ugly all-numeric, hand-coded input format. Greg L (talk) 03:18, 20 August 2008 (UTC)

• GregL, we should change what 99.9% of Wikipedia’s readership sees; we should not change the underlying coding of the dates. (sdsds - talk) 03:29, 20 August 2008 (UTC)

Sd, I appreciate your desire to retain a programming functionality, but I think you're way too optimistic in your expectations of technical improvements over at WikiMedia, especially something as major as the introduction of some IP-based system; in any case, geographical IP regions don't precisely map onto date-formatting usage.

Also, I don't think you've addressed the most basic issue: is the month–day/day–month order worth giving more than five seconds of your talent and energy to? Was it ever a problem in the first place? Let's rejoice in the amazing degree of homogeneity in our language, despite its geographical dispersion and the lack of a centralised authority such as the French language endures.

WYKIWYG (What You Key in Is What You Get) is the safest, simplest solution, allowing editors to retain local control and most easily check for inconsistencies and inappropriate choices (surprisingly common); on its side is the convenient fact that it takes less work, scrutiny and induction of newbies, not more. I'm all for templates and toys where their advantages clearly outweigh their disadvantages, but DA is not one of them. Let's allow (high-value) wikilinking to breath a little easier in our text displays. Tony (talk) 04:25, 20 August 2008 (UTC)

Tony, we both know we disagree on this. There is only a small change required to show arbitrarily formated dates to the "99.9%" who don't see them now. (We don't need to attempt to guess at an anon reader's preference. Any consistent format would be fine.)

You think WYKIWYG is "safest", and I'm willing to let you key in (new) dates without the wikilinking you dislike. I am among the many, however, who object to your script-based wholesale rewriting of dates that strips them of the markup that allows them to be auto-formatted. If you were to do this to articles where I had used wikilinked ISO dates, I would feel justified reverting your changes, because there is no consensus about this.

To address your "most basic issue": yes, enabling wikipedia content to be viewed in ways that match per-user or per-article style preferences is worth much more than five seconds of my effort. For example, I would be overjoyed to extend this mechanism to include pounds versus kilograms, as I grow weary of seeing {{convert}} everywhere. Heck, I would like to extend it to allow kilometer or kilometre, at the user's preference! Enwiki should move forward with this kind of functionality, not backwards! (sdsds - talk) 04:45, 20 August 2008 (UTC)

Question for sdsds: How would you prefer to write, in the wiki edit box, the following dates from Gregorian Reform of the Calendar published by the Vatican Observatory in 1983 and edited by Coyne, Hoskin, and Pedersen (p. 219):

On 11 February, 1582 Sirleto sent Antonio Giglio to Mondragone, the villa outside Rome where the Rome preferred to stay whenever he could, and there the Pope signed the bull on 24 February, 1582.

Please assume you are paraphrasing the sentence and so are not obliged to keep the same format as the original. What, if any, remarks would you include about the dates? --Gerry Ashton (talk) 05:39, 20 August 2008 (UTC)

Another question for sdsds: how is it possible to deduce from a reader's IP what preference he has for pounds over kilograms? Kilometre vs. kilometer possibly, to some extent, but is there really any benefit compared with the complications involved? And in any case, the main issue is the mass linking of dates - there seems to be clear consensus against that. If the developers want to spend time working on autoformatting for IP users, then at the same time they can make it independent of the linking. As it is, removing the linking affects autoformatting only for an infinitesimal percentage of readers, while improving the presentation for everyone, so I still see no valid argument against doing it.--Kotniski (talk) 06:36, 20 August 2008 (UTC)

Tony, going back to edit summaries, I agree that it should link to an explanation of why you are unlinking dates, rather than to WP:MOSNUM. The latter doesn't have anything about proposals to unlink dates, which was that threw me in the first place yesterday. If you link to one of the excellent, detailed explanations you have written about the issue, that woud be much more helpful. Some people will still disagree, but others may well be persuaded by your arguments. It would do more to promote what you are doing. At present, editors who have never seen the debates on this talk page will see you've stripped all the links from an article they contribute to, and to them it may seem to be some sort of unilateral action without any discussion.

Edit summaries can certainly be linked. I use linked summaries quite often. See this one from today: [4]. Also, tools such as navigation popups often include a link to themselves in the edit summary. The (fairly recently added) edit summary preview also shows whether the link is going to work properly. JRawle (Talk) 11:29, 20 August 2008 (UTC)

JRawle—very good advice, which I shall heed. Tony (talk) 11:55, 20 August 2008 (UTC)

Responding to User:Gerry Ashton: MOSNUM is a guideline, so the advice that, "Editors should follow it, except where common sense and the occasional exception will improve an article" is likely applicable in the test case you mention. In this case, or in any case where dates might be "special", the specific advice in MOSNUM simply does not apply. MOSNUM should give advice for the "standard" case of a date that involves no particular trickery. (Had the dates not related to this special case of the Gregorian calendar, MOSNUM should advise you to code the sentence as, "Sirleto sent Giglio to Mondragone [[1582-02-11]], and the Pope signed the bull [[1582-02-24]]." This would be rendered: "Sirleto sent Giglio to Mondragone 1582-02-11, and the Pope signed the bull 1582-02-24." Even in this tricky test case any user clicking on a linked 1582 learns about the, "Gregorian Calendar switch" which is mentioned at the top of the page for that year.)

Responding to User:Kotniski: You perhaps have me confused with some other contributor to this discussion. I do not advocate trying to guess at what format might be preferable to a non-logged-in user. Except for logged-in users who have specified a date format preference, I advocate choosing an arbitrary format, and consistently presenting all dates marked for autoformatting to that chosen format. Same for spelling, or any other variation based on user preference: if the user hasn't specified one, enwiki should arbitrarily choose a varition so as to present a consistent article. (sdsds - talk) 21:37, 21 August 2008 (UTC)

date-mess uncovered

The removal of autoformatting in Plug-in hybrid, which is featured article and a good read, uncovered an unholy mess of international and US raw formats that our readers have been viewing for who knows how long. The diff also shows a mistake in the syntax of the autoformating of an ISO date in the refs (2008-6-16).

I've left a note on the article talk page asking editors to decide which format is most appropriate using our guidelines at MOSNUM as a basis, and offering to assist if required. Tony (talk) 11:50, 20 August 2008 (UTC)

Would it not make sense before undertaking a larger effort to strip date linking as to have a bot/script attempt to convert dates to a specific format (would need a manual input to select between "Month Day, Year", and "Day Month Year") such that what are inconsistencies from older FAC articles would be convert automagically, but dropping warnings on the talk page when a date is in a format it cannot parse? I understand requesting manual help for these testing-the-waters cases, but if taken to a mass level, leaving a large number of articles with inconsistent dates that need to be fixed is going to take a lot more effort. --MASEM 13:33, 20 August 2008 (UTC)

Your question has two parts:

• Part 1: Is it possible for automated support to assist with the conversion of all dates in an article to one format?
  • Answer = Yes. The code is fairly simple. False positives and misses are foreseeable so it would be best with human oversight.
• Part 2: Would such automated support be needed before date links are stripped?
  • Answer = No. It is an entirely independent issue.

Regards Lightmouse (talk) 15:34, 20 August 2008 (UTC)

RFC on September 11, 2001 attacks

Talk:September 11, 2001 attacks#RFC on page title and comma - We need outside opinions on what the appropriate grammar is here. Should the page title and the article start out with "September 11, 2001 attacks" (no comma) or "September 11, 2001, attacks"? A third option is to rename the page to something like "September 11 attacks". We would appreciate comments on the article talk page. Thanks. --Aude (talk) 20:13, 20 August 2008 (UTC)

• With regard to “The September 11, 2001 attacks…”, it’s clear what it means without the comma before the word “attacks”. It seems terribly awkward and improper to me to write “The September 11, 2001, attacks…”. As for what the *formal* rule is, by daughter could answer that (she’s damned good), but she’s not here now. I see no reason to rename the article. Greg L (talk) 20:21, 20 August 2008 (UTC)
  • It's clumsy with or without the comma. I would follow idiom: September 11 attacks, if the various forms of 9-11 aren't dignified enough for us. Septentrionalis PMAnderson 20:25, 20 August 2008 (UTC)

Comma after "attack" is awful. Either "September 11, 2001 attacks" or Anderson's option. Tony (talk) 00:32, 21 August 2008 (UTC)

Unfortunately, the term "9-11" has entered the lexicon of the event and at least some acknowledgment of this date name is necessary, although I would put it in quotation marks once and then use an appropriate written out date convention thereafter, e.g. "September 11, 2001". FWiW Bzuk (talk) 12:10, 21 August 2008 (UTC).

The first words of the 9/11 Commission's report (500+ page PDF) are "THE 9/11 COMMISSION REPORT" so 9/11 must be regarded as an official term for the attack. Although I cannot find a reliable source to confirm my memory, I recall that the air pirates were reported to have chosen the date of the attack because of the similarity of the numeric date to the phone number used in the US to summon emergency help (911). So it is not a matter of having entered the lexicon, it was a deliberate choice of the air pirates from the very beginning. --Gerry Ashton (talk) 18:18, 21 August 2008 (UTC)

Is that the actual origin of the 9-11 use? It's certainly an interesting historical footnote if it's true and should be mentioned somewhere in the article. My point is that the use of the date has been morphed into "9-11" rather than the actual date. FWiW Bzuk (talk) 18:24, 21 August 2008 (UTC).

It's one of several theories. Septentrionalis PMAnderson 18:48, 21 August 2008 (UTC)

Date formatting: why isn't this done with a template?

I've wondered for years: why is date formatting accomplished entirely by "smart" code rather than by a template? For example, if we had something like {{format date|year=1776|month=July|day=4}} which could also recognize forms like {{format date|ISO=1776-07-04}} and {{format date|year=1776|month=07|day=4}}, then format (as now) based on user preference, but which would provide one single format as the default for everybody not logged in (e.g. "4 July 1776") it would seem infinitely more straightforward than the present magic. It could also deal well with year being optional, and could even be made smart enough to deal with date ranges (e.g. {{format date|year=1776|month=July|start-day=4|end-day=7}} could be shown, depending on preferences, as "4-7 July 1776" or "July 4-7, 1776"). - Jmabel | Talk 17:10, 20 August 2008 (UTC)

• Jmabel, with regard to this: “[the template would] then format (as now) based on user preference, but which would provide one single format as the default for everybody not logged”, that’s the way it currently works—there is one single default for *common folk* (99.9% of Wikipedia’s readership). And one format in particular, [[2005-05-15]], defaults to 2005-05-15 for 99.9% of our readership instead of showing the pretty May 15, 2005 some of us privileged editors like to see.
  I think it’s best if all us editors get over this notion that we are doing any measure of good by creating and using tools that are intended to improve the user experience for us editors (0.1% of Wikipedia’s readership), and which just gives a default view for “everybody else”. We editors should always be looking at precisely what everyone else is seeing.
  Many editors have suggested we simply improve the templates and magic words so they can benefit I.P. users too. But this would require parser functions and wholesale changes to the way Wikipedia’s servers work in the background to gather the requesting readers’ I.P. address, then match those to a database to determine which country they reside in, and spoon-feed content based on their country’s customary practices. That might happen (or maybe not), but it would likely be a year or more before we saw such a radical change. I wouldn’t hold my breath.
  In the mean time, to paraphrase Donald Rumsfeld, we must make do with the editing tools currently available to us. The current tools A) produce Easter-egg links to mindless trivia that is almost always unrelated to the topic, and B) delude editors here into thinking pretty looking date formats are being produced for our readership. It is high time these tools be abandoned. If we’ve got a crappy-ass Mark 14 torpedo that circles around and blows up the person who shot it, you simply avoid using that tool until you are provided something better. Greg L (talk) 19:50, 20 August 2008 (UT

• There already is the template {{Date}} that can take any format and emit it as e.g. "20 August 2008". Should the automatic date formatting be fixed at some point so that IP users will get a consistant formatting (no matter wich), the template could be changed accordingly without much ado. If Tony1 keeps unlinking dates though, which I oppose, then a change like that will mean that all those dates will have to be manually tagged again (can't be an automatic process due to ambiguity). I could live with all dates being wrapped into the aforementioned template though. --Amalthea^Talk 20:31, 20 August 2008 (UTC)

• Amalthea, {{Date}} is still another tool (that thankfully doesn’t link to trivia), that seems intended only to stop editwarring between editors by pacifying them with a format they are pleased to look at. That strikes me as nothing more than an attitude of “I don’t give a dump what 99.9% of our readership sees just as long as I don’t have to look at some other asshole’s method of writing out dates.” I reject that attitude as childish. It also condemns Wikipedia’s current policies for determining when a consensus has been arrived at and how to resolve conflict. To placate editors in the face of these dispute-resolution shortcomings, silly tools for just us were developed.
  We editors should always be looking at precisely what unregistered readers see.
  Further, as far as I can see, hand-coding dates produces better results than the template.
  Why? Check this out: if I use the template to code {{date|Jan 15, 2001}} in order to generate 15 January 2001, the template-generated version currently word-wraps between the “Jan” and the “15” (something I assumed it wouldn’t). My hand-generated dates don’t do this because I use a non-breaking space. Yes, I know that detail could be fixed in the code for the template, but that’s a secondary issue. It is utterly beyond me how anyone around here got it into their heads that we are making Wikipedia a better place by making tools that produce what we registered editors enjoy seeing but just provide a standard default for *others* (read: pretty much everyone); editors should just write out dates. This {{Date}} tool reminds me of putting horse blinders on two fourth-grade boys who can’t get along when they are sitting next to each other in class.
  MOSNUM has plenty or rules for the date formats that would be most suitable for various articles; we editors don’t have to be so damned intolerant that we make tools just so we get to see precisely what we want to see. Greg L (talk) 21:18, 20 August 2008 (UTC)

• You are wrong.
  If you had taken a look at {{date}} you'd know that it *always* emits dates in the format "20 August 2008" at the moment, but is prepared to display it formatted by user preferences or "using some sane and human-friendly default when a user is not-logged-in or when no date-style preference has been set" once MediaWiki has the capabilities to do so.
  I repeat, users that are not logged in or don't have a preference set will at the moment see the same as any other logged in user, and once a better date autoformatting feature is implemented it can be changed so that those 99.9% you mention will still see consistant dates (of whichever format is decided upon, I doubt that there'll be IP based guesses soon).
  Concerning the non breaking space: I agree that this should be fixed. I am also sure that wrapping dates into some kind of automatic formatting (the date template, for lack of a better one) can make sure that dates will *consistently* get those nbsps.
  Again, I'm convinced that the script assisted edits Tony is making right now are among the worst solutions for this problem (and I have yet to find the consensus he mentions) since all he accomplishes is to loose the meta information that makes a fix for it easier in the future, and he leaves the articles in just the inconsistent state he encountered them. If it stays wrapped in a template, a bot can implement a better solution should there ever come one to pass.
  Cheers, Amalthea^Talk 21:41, 20 August 2008 (UTC)

• I did too take a look at {{date}} Amalthea. And I understand exactly what it does. You seem to be missing my point (or refuse to see it). I’ll repeat what I wrote above again: We editors should always be looking at precisely what unregistered readers see. Whatever the Date template shows for non-registered editors, that is all we need to type in hard-coded text. We don’t need tools that are simply designed to placate stubborn editors who insist on viewing dates in a *special* format that regular readers (99.9% of Wikipedia’s readership) can’t see. Where’d you get the idea that tools that provide a special benefit for only us registered editors was a wise thing to do? The very premiss behind making these tools was arrogant and patently absurd for an on-line encyclopedia. Greg L (talk) 04:39, 21 August 2008 (UTC)

• Sorry, I did misunderstand you then, I thought you were still arguing about the inconsistent dates on one page that users will see - I think almost anybody agrees that this inconsistency is very bad.
  I do not see however the harm in giving registered editors the choice to see the date in whichever format they want. There are only 4 different date formats - whatever the default format is for anons, I'm sure that a very high percentage of the registered editors will see the article in just the same way as anons do.
  Furthermore, as sdsds said, a user preference to show metric or imperial units would be even nicer. I agree with him that MediaWiki should go forward with this, not backward.
  Lastly, why don't you propose to get rid of the skinning system as well? All your arguments apply there, too. --Amalthea^Talk 13:00, 21 August 2008 (UTC)

• Good point. Skinning is the root of the entire problem here. The only skinning allowed should have been limited strictly to issues unique to the editing experience, such as looking at the UTC time offset of edits in the history view. The first skinning options and editing tools (templates) that allowed editors to see article content that was different from that which the vast majority of our readership saw was a bad idea.
  The problem with giving editors a “choice” is we are masking editorial problems from the very people who are creating content. If there is a problem with date formatting that is *shocking* to people in the UK, for instance, then we need to develop a consensus amongst editors that a new way for dates must be developed, or decide that the problem isn’t a problem, or decide on an easy-to-follow set of rules to use article-appropriate date formating (my favorite). Simply masking the problem from the people who write articles and participate in establishing MOSNUM guidelines simply perpetuates problems for the vast majority of our readership. And in the case of the [[2005-06-06]] date tool, the problems we’ve been masking are significant. Greg L (talk) 16:32, 21 August 2008 (UTC)

• The Date template only works for dates between 1970 and 2038, because it relies upon programming tools intended for internal use in the Unix operating system. As such, it is only fit for use to time events that occur internally within a computer that was placed in service after 1970 and will be junked before 2038. It is unfit for any other use. --Gerry Ashton (talk) 21:47, 20 August 2008 (UTC)

• That's not good. Obviously I haven't taken a very thorough look at it either. :| I'm not sure if there's a feasible parser-functions way to take in all those date formats, since I wouldn't want to make entering dates difficult by using several template parameters, or relying on editors not to use it for dates outside the supported range.
  Can those unsupported date ranges be somehow identified, to just route them through? --Amalthea^Talk 22:07, 20 August 2008 (UTC)

Why would anyone want a tool that acts differently depending on what date is fed into it? Such a tool is what lawyers like to call an attractive nuisance. --Gerry Ashton (talk) 22:20, 20 August 2008 (UTC)

{{date}} does not handle dates prior to 1970 or 1901 well, hence my attempt at {{Date style}} metatemplate (see there for comparison, but shortly to be tweaked to less wikilinking code of my sandbox User:Davidruben/sandbox3, see Template talk:Cite web#Review of current and sandbox coding - examples for comparison table). A major problem is that one can't in mediawiki directly read whether an editor has set a personal preference (only direct wikilinking an ISO-style date responds to a user's perference, but then if no user preference was set this always then shows just as the ISO style... i.e no best of both worlds of follow a user's preference if set else an editor's preference) David Ruben ^Talk 00:07, 21 August 2008 (UTC)

All of these tools: we just don't need them. Tony (talk) 00:35, 21 August 2008 (UTC)

• What Tony said. Exactly. Editors should write out the damned dates and should choose a format most suitable for the subject matter. If it’s a coin toss, no big deal; there is no “wrong guess” since no one is confused by any date format that has the name of the month spelled out. If any editor thinks that dates should somehow look *better* for just us editors, then don a pair of x-ray glasses. Other than that, please, try to accept the fundamental concept that it is wrong wrong, wrong, to use tools that produce pretty (or prettier) output that only registered editors can see. If some date formatting tool produces a format that you think is good enough for “regular I.P. readers” to see, then fixed text in that same format is good enough for us registered editors to have to look at too. If any editor here disagrees with this premiss, then please produce your “I am really, really *special* license” for inspection.
  Junking these tools will also reduce the link clutter—to mind-numbing trivia no less—that has turned too many Wikipedia articles into seas of blue spaghetti. Way too much effort and keyboard pounding has been devoted to an issue that is just a problem of our own making. Greg L (talk) 04:31, 21 August 2008 (UTC)

I have to agree with the argument that a presentation tool which does not work for anyone except wiki editors is pretty pointless, and worse, potentially misleading to those editors trying to set up a page. I never saw the point of using date formatting and in 3 years have never set it for myself. I don't care how the date comes, though I would naturally write 13 June 1844. I can live with wierd transatlantic eccentricities, but it was my understanding that some editors could not: thus the compromise of introducing date formatting. Which, it has now been pointed out, really achieves nothing for purists in either camp if the effect is simply to pass on the text as written to most readers. Of course, if a template was introduced which defaulted to one style or another for every reader, then the war would no doubt break out again with great force. The fact that date autoformatting doesn't work except ofr die-hards may well have been its greatest attraction. Sandpiper (talk) 08:10, 21 August 2008 (UTC)

Earlier in this "string", Amalthea referred to a "skinning system". What is that? FWiW Bzuk (talk) 13:15, 21 August 2008 (UTC).

See WP:SKIN - you can set it in your preferences, and it changes the stylesheet you get. --Amalthea^Talk 13:23, 21 August 2008 (UTC)

• Which states as follows: “…the presentational style of the pages can be changed, provided you have a Wikipedia account.” Who cares? Probably greater than 99.9% of Wikipedia’s readership doesn’t have an account. We need to be looking at what they’re seeing—not providing a *special* view of pages designed just for us. Greg L (talk) 16:20, 21 August 2008 (UTC)

• Unless there is a plan afoot to go even further than this and completely remove this table from MOSNUM, can we agree that to avoid really junking up articles for the vast majority of readers, that the bottom tool should at least have the double-asterisked caveat shown below?

What you type	What logged-in registered users see (settings on first row)					What others will see*
--	January 15, 2001	15 January 2001	2001 January 15	2001-01-15	No preference	--
[[May 15]]	May 15	15 May	May 15	May 15	May 15	May 15
[[15 May]]	May 15	15 May	15 May	15 May	15 May	15 May
[[May 15]], [[2005]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	May 15, 2005	May 15, 2005
[[15 May]] [[2005]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	15 May 2005	15 May 2005
[[2005-05-15]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	2005-05-15	2005-05-15 **
* Non-registered users and registered users not logged in ** Editors are discouraged from using this format since the vast majority of readers  (non-registered I.P. users) will see a hard-to-read date format.

Is there anyone who thinks that having pretty looking dates for just we editors justifies having MOSNUM tacitly recommend the use of this tool, which A) looks like crap for 99.9% of readers, and B) links to mindless trivia that is almost always entirely unrelated to the article’s content? To save you all the time necessary to wade through previous posts on this page, waiting around for developers to fix this tool so it works equally as well for regular I.P. users would require very substantial changes to the way Wikipedia’s inner workings work and just isn’t a realistic option. So as a practical matter, we need to limit the discussion here to what should be done with the current tools until such time that a better one is provided.

Having said all that, I do see one reasonable alternative: Is there a way to revise the bottom format so it defaults to “15 May 2005” for I.P users? And while we’re at it, we might as well get a non-breaking space between the month and date; the current one word-wraps. If this can’t reasonably be expected to be accomplished in the very near future, let’s get the asterisks in. If not that, then I’m perfectly happy to sit this one out on the sidelines as the realization better propagates throughout the editing community that all these tools, which benefit only we editors (and make links to trivia to boot), were a bad idea from the beginning, and this entire table is finally deleted. Greg L (talk) 19:02, 21 August 2008 (UTC)

• I agree to adding the disclaimer, but would recommend moving the double asterisks to the leftmost "What you type" column (and hope that no one will then actually type those).
  I'm not sure what this will do to e.g. the citation templates which ATM rely on the ISO format for the access date. I could imagine going either way here, remove the wikilinking or still allow ISO dates there (since 99% of our readers won't read the references anyway). --Amalthea^Talk 21:56, 21 August 2008 (UTC)

Here's a thought- why not get rid of the citation templates, since they remain "buggy" and are almost impossible to figure out for the new editor? FWiW, authors routinely "key" in information for editing purposes, it's not an impossible task. It then reverts to WYSIWYG. Bzuk (talk) 22:05, 21 August 2008 (UTC).

• -Amalthea, I was thinking about putting the double-asterisk in the “what you type” column, but I thought people would think you should type the asterisks. Unjustified concern? To address this, how about this way?

What you type	What logged-in registered users see (settings on first row)					What others will see [A]
--	January 15, 2001	15 January 2001	2001 January 15	2001-01-15	No preference	--
[[May 15]]	May 15	15 May	May 15	May 15	May 15	May 15
[[15 May]]	May 15	15 May	15 May	15 May	15 May	15 May
[[May 15]], [[2005]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	May 15, 2005	May 15, 2005
[[15 May]] [[2005]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	15 May 2005	15 May 2005
[[2005-05-15]] [B]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	2005-05-15	2005-05-15

Greg L (talk) 23:25, 21 August 2008 (UTC)

I allowed myself to convert your footnoted table above to proper, working footnotes. --Amalthea^Talk 23:47, 21 August 2008 (UTC)

If DA is to be deprecated, I'm unsure whether this table belongs at all in MOSNUM. Tony (talk) 04:45, 22 August 2008 (UTC)

• One step at a time, I think, would be best here Tony. If you toss a frog into hot water, it will hop out. But if you put it into cool water and turn up the heat, it will stay in the water and swim around until it dies. Since editors around here are so emotional about anything being “D-worded,” moving the table off of MOSNUM will help prevent editors from thinking it is a “tool of good standing.” And by keeping the table available somewhere else, we can refer to it for reference as we further debate our options. Greg L (talk) 14:57, 22 August 2008 (UTC)
  • Autoformatting should be documented somewhere as long as it exists; otherwise we will have bug reports by people who don't understand that they accidentally set their preferences. Introductory text of the form: This is what autoformatting does; many editors feel that it should not be used. would solve any problem. Septentrionalis PMAnderson 17:39, 22 August 2008 (UTC)
    • I completely agree with Pmanderson. Greg L (talk) 23:03, 22 August 2008 (UTC)

Units and readability

An editor has raised an interesting point about the balance between readability and availability of metric units. Marcia Wright said on my talk page (selected quoting):

• I believe that this is much easier to read:
  • Lassen National Forest is a 1.1 million-acre national forest located in northeastern California.
• as opposed to this:
  • Lassen National Forest is a 1,100,000-acre (4,500 km2) national forest located in northeastern California.
  • with the metric units:
• The readability should not be reduced just to have conversions added to the article.

I believe that Marcia is acting in good faith and from her contributions I believe her to be a good Wikipedian. However, she has raised an important issue that comes up from time to time on an international publication. I happen to think that metric units should be provided even if this looks unfamiliar (compared with other specialist or regional publications) or if it degrades readability (by whatever measure we might use). If you look at her contributions, you will see that she helps improve articles about American geography. Please look at those articles and see what you think about this issue of metric units vs readability. Lightmouse (talk) 15:13, 21 August 2008 (UTC)

I agree that in the above example the first version is preferable. But I take this to be an introductory sentence - I presume somewhere later on in the article the area of the forest will be addressed in a separate sentence or paragraph, and there both imperial and metric units should be given.--Kotniski (talk) 15:34, 21 August 2008 (UTC)

Please look at the article and see. Lightmouse (talk) 15:38, 21 August 2008 (UTC)

Following up on the article Lassen National Forest, the version used there, "Lassen National Forest is a 1.1 million-acre (4,500 km2) national forest located in northeastern California." seems to be the best choice. What am I not understanding? is this a case of deprecating metric systems? FWiW Bzuk (talk) 15:55, 21 August 2008 (UTC).

I originally added two metric conversions and they were both removed. Marcia asked for a means of preventing the template being in the article because of page load time. See our conversation. So I suggested that she made manual edits but also started a thread about load time statistics at Template_talk:Convert. I now see that she has added one of the two conversions in a manual form and says that issue is about the readability of '1.1 million <units>' versus '1,100,000 <units>' (which I have some sympathy with). The story is a bit confusing for me. I am not sure where we were, and where we went along the way, but I think that we are almost where we want to be i.e. with both non-metric values having a metric equivalent visible to the reader. Lightmouse (talk) 16:06, 21 August 2008 (UTC)

Americans have to realize that theirs is a rather parochial attitude to the world. There are approximately 2,000,000,000 people in the world who can read English and who might potentially read that article. Of those, about 15% live in the United States. Most of the rest do not know what an acre is, and you can't seriously expect them to go and look it up in the midst of reading it. Even in Britain and its former colonies, most children do not study the Imperial system any more and do not really know what the units mean. Aesthetic differences aside, would it be more readable if I said something was 1.1 million arpents or 1,100,000 arpents in area?RockyMtnGuy (talk) 16:28, 21 August 2008 (UTC)

Which is why to link acre here; but this article is unlikely to read, and extremely unlikely to be written, by non-Americans - so WP:ENGVAR applies. Septentrionalis PMAnderson 16:54, 21 August 2008 (UTC)

I am not sure what you mean by the above comment, but I see that you have edited the article to move the conversion to a footnote. Taking conversions out of running text is another barrier to accessibility for metric readers. Lightmouse (talk) 17:08, 21 August 2008 (UTC)

RockyMtnGuy seems not to understand that this article is, and should be, written in American, so I cited our guidance.

WP:ENGVAR applies to the article, but WP:ENGVAR does *not* say anything about how to write units—WP:UNITS does, and it says that both units units should be given (main unit being US in this case). --Amalthea^Talk 18:09, 21 August 2008 (UTC)

• Parentheses are clumsy writing, a barrier to accessibility to all readers, metric or not. The exact acreage, and a conversion, are in the infobox for anyone who wants them. A link to acre remains in the text, and the footnote to the rough conversion for anyone who cannot recognize that more than a million of any plausible unit is likely to be a big area. Septentrionalis PMAnderson 17:21, 21 August 2008 (UTC)

That looks pretty goofy. What was wrong with "1.1 million acres (4,500 km²)"? That's a pretty standard presentation, isn't it? And why link to "acre"? It's pretty obvious with the conversion that it's a unit of area. --Elliskev 17:29, 21 August 2008 (UTC)

I believe you stretch ENGVAR too far here, Anderson, or is writing such that everyone can understand un-American? 1.1 million-acre national forest vs 1,100,000-acre (4,500 km2) is unfair. Either 1.1-million-acre national forest vs 1.1-million-acre (4,500 km²) or 1,100,000-acre national forest vs 1,100,000-acre (4,500 km²). Let Marcia call it as she will but as a metricated mo I see the readability significantly reduced by the removal of square kilometres. JIMp _talk·cont 17:32, 21 August 2008 (UTC)

I call it significantly (and pointlessly) reduced by the parenthesis; but I will change to million-acre to make clear this is a round figure. WP:MOS (and MOSNUM, especially) should not be used to enforce bad writing; doing so is a disservice to Wikipedia. It would be better to delete them than have them subserve the semi-literate version of political correctness. Septentrionalis PMAnderson 17:46, 21 August 2008 (UTC)

How about this? I added a new unit called "e6acre" (million acres) to Template:Convert. Now we can use it whenever we need to talk about millions of acres. with adj=on it gives 1.1-million-acre (4,500 km²). --Random832 (contribs) 18:00, 21 August 2008 (UTC)

e3acre might also be good ... no, don't panic we're not about to insert {{ucfirst:{{convert|1|e2acre|adj=on}}}} Wood into Winnie the Pooh. JIMp _talk·cont 18:24, 21 August 2008 (UTC)

It really doesn't matter how we get an unreadable parenthesized lump; it's still abominable writing. Septentrionalis PMAnderson 18:40, 21 August 2008 (UTC)

In an introductory paragraph, the goal is to give the reader a general concept of how large the forest is. Neither 1.1 million acres nor 4300 square kilometers really gives me a good concept, but at least with the metric figure, I can mentally note that if it were square, each edge would be between 60 and 70 kilometers. Doing any equivalent mental arithmetic with the customary figure is beyond me. So for me, the 4300 square kilometers figure is more useful. A corresponding customary description would be "a 1700 square mile national forest." --Gerry Ashton (talk) 18:54, 21 August 2008 (UTC)

I agree the 1.1 doesn't serve much purpose; which is why it now reads million-acre forest. "1700 square mile" would be fine too; the whole thing belongs under our clause about four minute mile. Septentrionalis PMAnderson 19:02, 21 August 2008 (UTC)

No, it doesn't matter and yes, parenthesized-lumpless writing is preferable, but it's better than writing something that just doesn't make sense (i.e. imperial/US units to a metric minded reader or metric units to an imperial/US system minded reader). JIMp _talk·cont 18:58, 21 August 2008 (UTC)

I fail to see that four-minute-mile connexion. JIMp _talk·cont 19:04, 21 August 2008 (UTC)

Idiomatic expressions should not be spoiled by reflex conversion. Septentrionalis PMAnderson 19:07, 21 August 2008 (UTC)

Absolutely but a measurement of an actual park out there in the world is not an idiomatic expression ... inspite of any rewording to make it look like one. JIMp _talk·cont 19:16, 21 August 2008 (UTC)

The four-minute mile clause applies to common expressions, not common forms of expression. It would not apply, for example, to "the 0 to 60 time of the Jeep Cherokee was 11 seconds" because the next time the form of expression was found, the vehicle and time would most likely be different. This makes sense, because if it is a common idiom in the English language, even readers who don't use the system of units in the expression as their first choice will learn the meaning of the idiom once and for all, so won't need to do calculate a conversion to familiar units each time the expression is encountered. --Gerry Ashton (talk) 19:19, 21 August 2008 (UTC)

I second what Gerry wrote. JIMp _talk·cont 19:29, 21 August 2008 (UTC)

I agree with Lightmouse's edit. I don't think in terms of square kilometers, but I know that there are people (like Lightmouse) that do. The reverse, adding imperial units, can and should be applied to say a National Park in South Africa that is 450000 hectares—i.e. 450,000 hectares (1,100,000 acres). Sorry, but Marcia Wright is not right on this one. Since I don't think in terms of km2, I just skip over the (4,500 km²) part anyway when reading. Therefore, the readability is not affected for me. —MJCdetroit ^(yak) 20:42, 21 August 2008 (UTC)

Notwithstanding the aesthetics of the four-minute mile, whether it's the statute mile, the metric mile, or the 1500 metres, the fact is that if you put something out on the World Wide Web, everybody on the planet can read it. Case in point - I led a hike in the Canadian Rockies recently. The club I belong to posted it on our Web site. Of the people who contacted me about it, one was from the Netherlands, one was from Israel, two were from France, two were from Japan and only one was from Canada. Since most of them didn't understand feet or miles, we calibrated our altimeters in metres and our GPS units in kilometres. So, if you put something out on the World Wide Web, be aware that anyone on the planet can read it, and not everybody has the same standards as you.RockyMtnGuy (talk) 21:20, 21 August 2008 (UTC)

I am about to invoke the "too many cooks" clause (LOL) as the "improvements" are not there; putting information in a reference note is not a good solution. FWiW Bzuk (talk) 21:28, 21 August 2008 (UTC).

• Lightmouse: I think your first instinct was spot on (but with a modification): That particular article should be written as follows:

“ Lassen National Forest is a 1.1 million-acre (4,300 km²) national forest located in northeastern California. ”

Why? Well…

1. The text you propose is much more fluid and natural to read and is the way one would find such information in a U.S. National Parks’ brochure.
2. The existing text here (“is a million-acre national forest”) seems unduly informal and non-encyclopedic. Since the value is known to high precision (at 1,070,344 acres), going to two significant digits is entirely appropriate for readers interested in the relative sizes of national parks.
3. The article is about a U.S. National Forest and is therefore U.S.-centric. So it should have acres first for that audience.
4. The parenthetical should be provided for the benefit of other English-speaking peoples of the world and in the unit of measure most common for SI-using countries. The style I chose for my example here is, I believe, in accordance with existing guidelines on MOSNUM.
5. It conforms with other MOSNUM guidelines, which calls for the first instances of the primary units of measure to be linked, and for the first instance(s) of the primary measure to be spelled out. The unit of measure in the parenthetical conversion doesn’t need to be linked because it’s magnitude is obvious when juxtaposed next to the primary measure.

P.S. I don’t see the value of the footnote since the exact size is shown in the sidebar infobox.

PPS I did my own conversion and the actual size is 4331.5 square kilometers, so it’s “4,300”, not “4,500”.

Greg L (talk) 21:45, 21 August 2008 (UTC)

I absolutely agree, see comments I made a zillion spaces up. FWiW Bzuk (talk) 21:50, 21 August 2008 (UTC).

I unconditionally disagree. Bad writing is bad writing; and we don't need to convert an intentionally approximate wording when there is a precise statement and conversion on the other side of the page. Septentrionalis PMAnderson 00:07, 22 August 2008 (UTC)

If this is turning into a poll: I agree with Greg L, but can also live with the current version per Gerry Ashton. Square miles gives me (as a metric) a rough estimate that I can grasp, compared to acres which means nothing to me, but I would always prefer the real deal, per MOS:CONVERSIONS. --Amalthea^Talk 00:29, 22 August 2008 (UTC)

So what is wrong with this rewording to avoid the awkward triple item:

Lassen National Forest is a national forest of 1.1 million acres (4,500 km2) in northeastern California

The example wasn't helped by a redundant word. I increasingly see a tendency to resort to multiple hyphenated units, but there's always a more striaghtforward alternative. With conversion, they are better avoided. Another point: how many American readers will be able to conceptualise a million acres? What is wrong with square miles? Tony (talk) 04:41, 22 August 2008 (UTC)

PPS I did my own conversion and the actual size is 4331.5 square kilometers, so it’s “4,300”, not “4,500”. Unfortunately, this problem is due to the double rounding inherent in use of the convert template: the input is given as 1.1 (2 significant figures) and then it converts 1,100,000 acres to km2 (4,451) and then rounds _that_ to 2 significant figures. --Random832 (contribs) 14:23, 22 August 2008 (UTC)

A reason to be careful with {{convert}}. But Marcia was right to begin with: Lassen National Forest is a national forest of 1.1 million acres (4,500 km2) in northeastern California is clumsy and difficult to read; as an opening sentence, it offers metric raaders very little, all of it available elsewhere. If there is a Siberian reserve somewhere notable because it is over a million hectares, a rational American reader will accept that as a summary, and if xe wants an exact area, look further in the article. Septentrionalis PMAnderson 14:32, 22 August 2008 (UTC)

I'm rather surprised by this long discussion on a single example. I thought the issue had been decided once and for all a long time ago. There is a clear guideline to always provide conversions for non-SI units. Readability is not determined by style only, but also by presenting comprehensible information to the reader (and outside the U.S.A. nobody knows what an acre is). −Woodstone (talk) 14:53, 22 August 2008 (UTC)

Please quote the wording which would apply such a mandate to this situation, so that I may dispute it. Any guidance which makes this encyclopedia less readable without making it more clear should be ignored. Septentrionalis PMAnderson 15:47, 22 August 2008 (UTC)

See Wikipedia:Manual of Style (dates_and_numbers)#Unit_conversions. There are a few exceptions, but none apply here. In your opinion it may reduce readably in mine it enhances it. No need to start scolding. −Woodstone (talk) 18:01, 22 August 2008 (UTC)

At the risk of getting pointy, I believe Lassen is in Northern Paiute territory, so perhaps the local unit should be square rabbit-skins per Harry W. Gilmore "Hunting Habits of the Early Nevada Paiutes" American Anthropologist, New Series, Vol. 55, No. 1 (Jan. - Mar., 1953), pp. 148-153

But seriously, if all the fuss is about the parentheses, perhaps we should consider more verbose ways of presenting the conversion. One might suggest something of the form: Lassen National Forest is a US national forest in northeastern California occupying 4331.5 km², locally described as 1,070,344 acres. LeadSongDog (talk) 19:28, 22 August 2008 (UTC)

I haven't read the whole discussion, but conversions should stay in one form or another. I managed to master the languages in all the places I've lived, but never the conversions. My entire household loves them; I can simultaneously read a number on Wiki that I understand, and a number the rest of the family understands. It's one of our strengths; let's not lose it. I can't really relate to complaining about reading around one set of parentheses. SandyGeorgia (Talk) 02:49, 23 August 2008 (UTC)

Archive 100

←

Archive 105

Archive 106

Archive 107

Archive 108

Archive 109

Archive 110