Wikipedia talk:Manual of Style/Dates and numbers: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Line 1,542: Line 1,542:
:I take issue with it too. Tony's scripted [http://en.wikipedia.org/w/index.php?title=Battle_of_Arras_(1917)&diff=232862519&oldid=232758542 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. [[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 16:16, 19 August 2008 (UTC)
:I take issue with it too. Tony's scripted [http://en.wikipedia.org/w/index.php?title=Battle_of_Arras_(1917)&diff=232862519&oldid=232758542 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. [[User:LeadSongDog|LeadSongDog]] ([[User talk: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. [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User talk:Tony1|<font color="darkgreen">(talk)</font >]] 00:15, 20 August 2008 (UTC)
::I wasn't aware that an edit summary could link. Are you sure? If so, it's quite possible. [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User talk:Tony1|<font color="darkgreen">(talk)</font >]] 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 <u>99.9%</u> of Wikipedia’s readers (non-registered readers) see: the '''''[[Wikipedia:Manual_of_Style_(dates_and_numbers)#Date_autoformatting|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 <code><nowiki>[[2005-05-15]]</nowiki></code>), we might as well loose that one since 99.9% of Wikipedia’s readership sees only the ugly all-numeric, hand-coded input format. <span style="white-space:nowrap;">'''[[User:Greg L|Greg L]]''' ([[User_talk:Greg_L|talk]])</span> 03:18, 20 August 2008 (UTC)

Revision as of 03:18, 20 August 2008

Archive
Years and dates archives

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:

22:43, 25 May 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 [1] 0 0 0 4 0
Headomb [2] 4 1 0 0
Caerwine [3] 3 1 0 2
MJCdetroit [4] 4 0 0 0
Greg L [5] 3 4 0 1 0
User:Gerry Ashton [6] 4 2 0 2
Askari Mark [7] 2 4 0 2 0
EagleFalconn [8] 0 0 0 4 0
User:Itub [9] 4 1 0 3 −∞
Woodstone [10] 0 2 0 3 4
User:jnestorius [11] 0 0 2 2
User:RockyMtnGuy [12] 4 2 0 0
Jimp [13] 0 2 0 4 3
User:Dank55 [14] 1 4 0 0
User:Tony1 [15] 0 4 0 0
User:Flying Jazz [16] 0 1 0 2 4
User:LeadSongDog [17] 0 2 0 4 2
Teemu Leisti [18] 4 0 0 0 0
User:TimVickers [19] 0 0 4 0
User:Blank [20] 0 0 0 0
User:Blank [21] 0 0 0 0
User:Blank [22] 0 0 0 0
User:Blank [23] 0 0 0 0
User:Blank [24] 0 0 0 0
User:Blank [25] 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.
Votes Comments
  1. ^ L is simple and easily recognisable; I can see no advantage in a more complicated rule. EagleFalconn is right. If we can't agree on a simple rule, it's better to have no rule. Thunderbird2
  2. ^ See link. Also partial deprecation is unnecessarily convoluted in the face of a superior solution Headbomb 09:07, 3 August 2008 (UTC)
  3. ^ L only is my personal preference, but not so strong that I must have it entombed in MOSNUM. L or l (partial) seems like a complicated way of stating what is already covered by the unambiguousness principle. l only makes no sense. Silence is acceptable. Caerwine
  4. ^ I vote this way because if we are going to do it— do it all the way. Any half measure would probably be a waste of MOS space and is pretty much the "silent" way of doing things now. MJCdetroit
  5. ^ There’s no need to upset the apple cart to proscribe a common practice on Wikipedia. The use of ml is suitable for use with the SI according to the BIPM and is not confusing to read. We should be addressing only truly serious problems that cause ambiguity or are violations of common sense (mixing of ml and mL within an article, use of lowercase L for liter such as “2 l bottle”, and mixing of ml and L). Anything more intrusive than this requires that we first post messages on chemistry-related boards to solicit greater input.

    As regards the latest column, I simply think lowercase l (e.g., “It was 1 l less”) is too ambiguous and hard to read and interpret—impossible really. The U.S.’s adoption of uppercase L (and the BIPM’s endorsement of the symbol) were for a good reason and should be standard on an on-line encyclopedia that uses sans-serif typeface as a standard.Greg L (talk) 22:18, 4 August 2008 (UTC)

  6. ^ If we are afraid to adopt a style, we should just delete the entire Manual of Style and all of its related pages, such as the one for dates and numbers. My first choice is "L" only, my second choice is that if an article contains only prefixed forms of liter, either case may be used, but if an unprefixed liter symbol is present in an article, all instances, prefixed or not, should use capital "L".User:Gerry Ashton 23:08, 3 August 2008 (UTC)
  7. ^ It’s clear from the preceding discussion that several forms of usage are common, and Wikipedia has traditionally been open to use of a variety of preferences as long as they provide clarity and “look good.” Askari Mark 4 August 2008
  8. ^ My preference for the capital L in all occaisions is a readability issue. That said, there is no consensus for this outside the United States or in the scientific community. In fact, consensus in the scientific community states that abbreviations should only be capitalized when the unit is named after a person (Debye, Kelvin, Celsius, Tesla etc). In practice, in the United States at least, capital L has come to dominate the competition because of the difficulty of reading lowercase l. I am voting with my personal preference. Question: Should Wikipedia follow scientific consensus or popular use? Is there a guideline for that? Also, what is the convention in England? I won't like it, but if its the same as the scientific standard I'm tempted to say we should follow it, as much as I dislike reading "0.1 l." Outside of that, having read all the above comments and the revert war (which I had completely ignored before now), can we please not get our panties in a bunch? Its a unit abbreviation guys. 99.99% of Wikipedia doesn't even know this discussion is happening, nor will they care. Try and keep it in perspective. EagleFalconn 01:05, 4 August 2008 (UTC) In an attempt to be more consistent with this point and also in light of general feelings here, I am changing my vote to preferring silence only. EagleFalconn 18:50, 6 August 2008 (UTC)
  9. ^ Lowercase works well for many print publications, which were surely what the BIPM had in mind at the time, because print publications almost never use sans serif fonts. Wikipedia uses sans serif by default, so in the interest of readability and simplicity, let's just use L. If the alternative for this trivial issue is a multi-bulleted piece of legislation, I'd rather keep MoS silent and save the space for more important stuff. --User:Itub, 10:15, 4, August 2008 (UTC)
  10. ^ the BIPM allows both l and L; we should not be overprescriptive; only ask to be consistent within one article; I see no objection in mixing ml and L. User:Woodstone 4 August 2008 11:19 (UTC)
  11. ^ For those of us outside the USA, "2 L" is more problematic than "2 mL". Most people outside the USA never use L. While mL, kL can probably be deduced easily from the context, I think many readers will be puzzled by 2L and might think it's some US customary unit they've never heard of. In these parts, the usual way to avoid the ambiguity of the lowercase l is to write litre(s) in full. That gets my 4 points, though it's not on the ballot. I'll even allow liter(s). User:jnestorius
  12. ^ "L" is unambigous while "l" can be confused with "1" in sans-serif fonts. And one should avoid ml becase 1) it is actually the same as cm3 and 2) it looks like an m1 which is a US military rifle. User:RockyMtnGuy
  13. ^ Both "l" and "L" are accpetable according to BIPM let MOSNUM also accept both. We shouldn't have both in the same article but isn't common sense enough to tell us this? Certainly "2 l bottle" could be confusing but we'd generally spell the word out. Jimp
  14. ^ Warning: US-centric, a bit snobbish, and aimed at the more "mature" articles. AP Stylebook, "metric system", last paragraph, gives L and mL only and has for some time, which means "ml" is going to give the appearance to professional US writers that the data is more likely to come from a beer label than a professional source. Chicago agrees (section 15.66). AP Stylebook style is compulsory in most U.S. magazines and newspapers worth reading, especially when it's backed up by Chicago. But I almost never see the abbreviation in for instance Scientific American...it's "liter" here in the U.S. and AFAIK "litre" elsewhere, except in formulas.

    Update: great work providing sources and searches, guys...switching my vote. User:Dank55

  15. ^ I hope I've read the keys properly; L only, not l, plus either mL or ml consistently in an article. Tony
  16. ^ The World Health Organization house style guide gives a clear preference for the lower case. It says (p. 36) "litre l (spell out if confusion is possible)". Excluding either would be a mistake. Let's imagine that the US is only one of many nations in the world...there's got to be at least six or seven others, right? User:Flying Jazz
  17. ^ Unclear why we would proscribe the unicode script ell as used in the standard and the real world. User:LeadSongDog05:11, 6 August 2008 (UTC)
  18. ^ I agree with MJCdetroit above. "L" is allowed, it is clearer, and anything short of an all-the-way "L-only" usage is only going to create confusion. User:Teemu Leisti 04:42, 10 August 2008 (UTC)
  19. ^ The literature I read and contribute to uses L and ml, using l is too confusing for the partially-sighted and mL is non-standard for me. I'd just follow the literature. So I'd go for none of the above, with L only, ml or mL, Don’t mix ml and mL in same article User:TimVickers
  20. ^ Replace this text with your vote comment. Copy/Past your signature here
  21. ^ Replace this text with your vote comment. Copy/Past your signature here
  22. ^ Replace this text with your vote comment. Copy/Past your signature here
  23. ^ Replace this text with your vote comment. Copy/Past your signature here
  24. ^ Replace this text with your vote comment. Copy/Past your signature here
  25. ^ Replace this text with your vote comment. Copy/Past your signature here
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)[reply]

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

What's so damn special about chemists? I mean honestly? Headbomb {ταλκWP Physics: PotW} 00:05, 4 August 2008 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • I prefer dm3 instead of both L and l. Albmont (talk) 02:18, 4 August 2008 (UTC)[reply]
  • My unit of preference is the Smoot3. 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
Er, google searches are case-insensitive. This tells us nothing.LeadSongDog (talk) 07:48, 6 August 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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

I have no objection to an attempt at compromise between columns 1 & 2. Thunderbird2 (talk) 18:42, 10 August 2008 (UTC)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

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:

22:43, 25 May 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 [1] X -
Woodstone [2] - X
Itub [3] - X
EagleFalconn [4] - X
Thunderbird2 [5] - X
MJCdetroit [6] X -
Jimp [7] - X
Flying Jazz [8] - X
OwenBlacker [9] X -
Blank [10] - -
Blank [11] - -
Blank [12] - -


Votes Comments
  1. ^ I think instances of “2 l” are too hard to read. If editors remain consistent and don’t confusingly mix styles in articles, I think we’ve done enough without running roughshod on the SI-compliant styles. Greg L 18:57, 10 August 2008 (UTC)
  2. ^ I still object to banning ml in presence of L; ml is really a very common symbol. I could support: prefer liter, litre, can have L only, ml or mL, don't mix ml and mL. Woodstone 21:30, 10 August 2008 (UTC)
  3. ^ The more this drags on, the more I realize the wisdom of treating it as a WP:ENGVAR of sorts. The proposed rule is too complex for such a trivial issue. --Itub 05:09, 11 August 2008 (UTC)
  4. ^ To quote Lewis Black, "You people are NUTS!" No issue this simple should require rules this long. At this point, what you're proposing is exactly the same as simply bowing to common sense and allowing disciplinary standards take effect. EagleFalconn 12:22, 11 August 2008 (UTC)
  5. ^ There is a common ground to be found between columns 1 and 2, but this moves away from it. Thunderbird2 TIME:STAMP (UTC)
  6. ^ I said it in the first vote. MJCdetroit 12:31, 12 August 2008 (UTC)
  7. ^ The lower-case version is perfectly valid. Wherever it's hard to read I'm sure editors' common sense will find a solution. I'm all for not mixing upper- and lower-case versions regardless of prefix (e.g. not "ml" and "L" together). However, I'm not sure any of this is worth the clutter. Jimp 15:34, 12 August 2008 (UTC)
  8. ^ Excluding either "l" or "L" would be a mistake in my view. Flying Jazz 07:28, 14 August 2008 (UTC)
  9. ^ I'd also support just using the capital-ell symbol, partly as I find the lowercase a lot more difficult to read. OwenBlacker 16:24, 16 August 2008 (UTC)
  10. ^ Your vote comment. Blank TIME:STAMP (UTC)
  11. ^ Your vote comment. Blank TIME:STAMP (UTC)
  12. ^ Your vote comment. Blank TIME:STAMP (UTC)
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)[reply]

That expresses perfectly what I thought I'd voted for (second column "4"). Tony (talk) 00:40, 11 August 2008 (UTC)[reply]
  • 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)[reply]
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)[reply]

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:

22:43, 25 May 2024 (UTC)


Place an X on the option you support
User Link to
comment
L only
ml or mL
Remain
silent
Greg L [1] X -
Itub [2] - X
Woodstone [3] X -
EagleFalconn [4] - X
Thunderbird2 [5] - X
Gerry Ashton [6] - X
Tony [7] X -
Jimp [8] - X
Flying Jazz [9] - X
Askari Mark [10] X -
Blank [11] - -
Blank [12] - -
Blank [13] - -


Votes Comments
  1. ^ This option works for me too since it would also get rid of “2 l”. Greg L 01:25, 11 August 2008 (UTC)
  2. ^ I thought the goal of MOS was to promote professional writing standards in Wikipedia, preferrably by basing it on respected real-world style guides, and using quality publications as examples. We have seen examples of style guides that use L for the liter, and examples that use l, but I don't think we will ever find a respectable style guide that allows this inconsistent mixing of L with ml. Itub 05:12, 11 August 2008 (UTC)
  3. ^ The wording should mention the blanket preference for spelling out units in running text. Woodstone 09:36, 11 August 2008 (UTC)
  4. ^ To quote Lewis Black, "You people are NUTS!" No issue this simple should require rules this long. At this point, what you're proposing is exactly the same as simply bowing to common sense and allowing disciplinary standards take effect. EagleFalconn 12:22, 11 August 2008 (UTC)
  5. ^ per Itub. Thunderbird2 16:12, 11 August 2008 (UTC)
  6. ^ A strong consensus would be required to allow inconsistent case of a unit symbol in an article just because some instances are prefixed and some are not. Such strong consensus has not been demonstrated. Gerry Ashton 16:52, 11 August 2008 (UTC)
  7. ^ I strongly agree with Greg's proposal. This is a much-needed change. The text in the upper green box would be fine in MOSNUM, except that the third item in the list doesn't quite match. Tony] 05:03, 12 August 2008 (UTC)
  8. ^ Getting worse: if you use "L", use "mL". Jimp 15:50, 12 August 2008 (UTC)
  9. ^ Excluding either "l" or "L" would be a mistake in my view. Flying Jazz 07:28, 14 August 2008 (UTC)
  10. ^ Since the preceding discussion (itself nigh-encyclopedic in length, if not illumination) has revealed that many of these variations (ml and mL) are common in different technical areas (chemistry, medicine, etc.), this proposal allows room for common usage without imposing one’s style on all others. Since there is no uniform consensus on style, the most we should impose on WP editors is consistency of usage in a given article. Askari Mark 13:15, 16 August 2008
  11. ^ Your vote comment. Blank TIME:STAMP (UTC)
  12. ^ Your vote comment. Blank TIME:STAMP (UTC)
  13. ^ Your vote comment. Blank TIME:STAMP (UTC)
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)[reply]
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)[reply]

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

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

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


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:

22:43, 25 May 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 [1] X - -
Woodstone [2] X - X
Teemu Leisti [3] - X -
Kotniski [4] X XX -
Tony [5] - XX -
Blank [6] - - -
Blank [7] - - -
Blank [8] - - -
Blank [9] - - -
Blank [10] - - -
Blank [11] - - -
Blank [12] - -


Votes Comments
  1. ^ Since the preceding discussion (itself nigh-encyclopedic in length, if not illumination) has revealed that many of these variations (ml and mL) are common in different technical areas (chemistry, medicine, etc.), this proposal allows room for common usage without imposing one’s style on all others. Since there is no uniform consensus on style, the most we should impose on WP editors is consistency of usage in a given article. Askari Mark 18:58, 16 August 2008 (UTC)
  2. ^ Don't forget to point out preference for spelled out units in running text. Woodstone 19:52, 16 August 2008 (UTC)
  3. ^ I support the option of using L for litre consistently everywhere. Since there is no such option in this vote, I'll cast no vote. I didn't read through the whole preceding discussion, which might explain why there was no such option, but I protest against excluding it from the vote. Teemu Leisti 05:47, 17 August 2008 (UTC)
    OK, thanks to Kotniski for explaining this. I added my vote. Teemu Leisti 07:07, 17 August 2008 (UTC)
  4. ^ I think it should be made clear that "remaining silent" refers only to the controversial issue - whether to allow mixing of ml with L. Since there is apparently no ongoing dispute about the use of L only when unprefixed, there is no need for silence on that issue. Kotniski (Aug 17)
  5. ^ As before. Tony TIME:STAMP (UTC)
  6. ^ Your vote comment. Blank TIME:STAMP (UTC)
  7. ^ Your vote comment. Blank TIME:STAMP (UTC)
  8. ^ Your vote comment. Blank 00:55, 18 August 2008 (UTC)
  9. ^ Your vote comment. Blank TIME:STAMP (UTC)
  10. ^ Your vote comment. Blank TIME:STAMP (UTC)
  11. ^ Your vote comment. Blank TIME:STAMP (UTC)
  12. ^ Your vote comment. Blank TIME:STAMP (UTC)
Discussion

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Here's a shortlist to review.LeadSongDog (talk) 14:04, 11 August 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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).[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Sdsds, please see MOSNUM's deprecation of ISO 8601 dates. Tony (talk) 00:47, 11 August 2008 (UTC)[reply]
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)[reply]

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

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)[reply]
I've responded on Sdsds's talk page with the link to the notorious Bugzilla page. Tony (talk) 05:28, 12 August 2008 (UTC)[reply]

Date-format consistency: let's bring MOSNUM into line with reality

This arises from the discussion above, initiated by Lightmouse (although not with a title I'd have chosen). The debate is prompted by MOSNUM's statement: "The same format should be used in the main text, footnotes and references of each article". In that discussion, inter alia, Lighmouse says:

I started this debate [on the scope of within-article consistency in date formatting] 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.

This is a view that I find compelling, except that I take it Lightmouse also intended that date formats in citation-driven references should be internally consistent where they are different from date formats in the main text.

SandyGeorgia, the FA delegate, has been concerned about this "mismatch" between rules and practice for some time; she finds it most uncomfortable to pass FAs that are, technically speaking, in breach of the MoS guidelines. This occurs, for example, in all articles that use the popular cite web template for the references section, which displays ISO dates in contempt of MOSMUM's statement:

"ISO 8601 dates (1976-05-31) are uncommon in English prose, and are generally not used in Wikipedia.

Note, however, that there's a little loophole that might be construed as allowing ISO dates in citation lists:

However, they may be useful in long lists and tables for conciseness and ease of comparison."

even though this is at odds with the quote at the top of this section <clears throat loudly>.

Sandy commented in the discussion above:

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

[the main] text should use one, consistent style for date formatting and linking, and
references and footnotes should use one, consistent style ...

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 [in references].... 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.... In other words, I agree with the proposal, but disagree with the section heading here.

I believe that herding together the templates into a rationale, coordinated part of the project is impossible to do in the short term, and that we should go along with Lightmouse's and Sandy's call. In effect, the simplest way of acknowledging reality is to be strict about date formatting consistency within (1) the manually entered dates in an article, and separately (2) the citation-generated dates that are largely out of editors' control. We are aided in this proposal by the fact that the citations are neatly corralled at the bottom of articles, and the main text, with a few rare exceptions, contains manually entered dates.

At the moment, MOSNUM can say what it likes about whole-article consistency until it's blue in the face, but the developers of the citation templates have taken no notice, and we tag along. Tony (talk) 05:14, 12 August 2008 (UTC)[reply]

Tony, the discussion over date formats proceeded through WP:AVIATION PROJECT and the general consensus was to have an unambiguous, easy-to-understand, written out system. ISO Dating was specifically rejected as an overall project format. The problem remains that the citation templates are written in an arcane and confusing American Psychiatric Association convention, specifying the use of the ISO dating. New editors are directed to these templates although the APA guide is a university-based system that I remember being instituted because professors were tired of having to explain the then, more common Modern Language Association style guide that was the usual format for research papers. The APA guide is a simplified but yet less flexible system that ties date of publication not to the publication but the author because it was more closely associated with a Harvard citation style (APA also eliminated the place of publication for the same reason of simplifying the system). Any attempts to have the citation templates (which were provided as a means to assist writers with no formal research background or cataloging experience in providing verifiable sources of information to back up entries) reworked or even to provide an alternative in the form of the MLA system have been summarily rejected, often by the expedient of only one dissenting voice. After a number of efforts that were rebuffed, I resorted to "scratch cataloging" to introduce the MLA format to articles in which I was devoting some time. FWiW Bzuk (talk) 15:50, 12 August 2008 (UTC).[reply]
Bzuk: I agree entirely with what you say. I just loathe APA style; and I believe they make lots of money by selling their hard-copy manual, too. They change a few nuts and bolts every so often and bring out a new edition that everyone has to buy. Of course, it's not available online, is it ....
Dealing with the citation template mess is something the community might want to consider at some later stage. In the meantime, I encourage all editors to avoid citation templates and to retain proper control over their formatting by manually keying in their references. It's not rocket science, and produces a much better result than those templates. At the moment, the templates are quite a separate issue from weening ourselves off manually keyed-in DA. Tony (talk) 02:30, 13 August 2008 (UTC)[reply]

I do not understand this discussion, or what people still believe are the limitations in any of the various citation templates. There is currently a bug at {{citation}} where it won't accept delinked US-style date formats (it converts them to international style), but to my knowledge, this meme that x, y or z can't be done with a given template is simply wrong. With the exception of that bug, all of the templates can handle all combinations (linked, not linked, US-style or international-style), and that one bug can be dealt with manually by moving the date out of the template. I suspect that many editors are repeating these memes without having experimented with different methods. Again, there are three completely delinked samples in:

SandyGeorgia (Talk) 02:35, 13 August 2008 (UTC)[reply]

Thank God for a rational voice. There really is no problem that can't either be easily worked around, or hopefully quickly sorted out. --Malleus Fatuorum (talk) 02:41, 13 August 2008 (UTC)[reply]
Perhaps the problem is that, because different templates handle dates differently, one actually has to take the time to figure each one out. But it's not rocket science; even I can do it. SandyGeorgia (Talk) 02:44, 13 August 2008 (UTC)[reply]
That's a problem, and one that hopefully will soon be fixed. As a user of the {{citation}} template though, I feel somewhat insulted by the suggestion that it's "to assist writers with no formal research background or cataloging experience". I have a "formal research background", and I have no reason to doubt that others who choose to use the template do so as well. --Malleus Fatuorum (talk) 02:53, 13 August 2008 (UTC)[reply]

Date-format in regions

In American English the date is written as mm/dd/yy
In British English AKA European English the date is written as dd/mm/yy.
I suggest that on all American related articles we should use the American format and in European related articles, we use the European format. This makes sense. Also the same goes with articles related to South Africa, Australia ect. I believe this should be added to this wiki-page Ijanderson977 (talk) 18:24, 12 August 2008 (UTC)[reply]

A couple of judgement calls. Where would Grand Theft Auto IV fall? Created and designed in Britain owned by a US company and set in fictional American locations. Or Cary Grant born in UK but made his name in US. Laurel and Hardy will be a fun one as well. - X201 (talk) 10:31, 13 August 2008 (UTC)[reply]
I'm suprised to see that neither Wikipedia:Manual of Style nor [[Wikipedia:Manual of Style (dates and numbers) explicitly forbid the formants mentioned by Ijanderson977 (although they are not among the acceptable options given). In any case, there is no chance whatsoever that the community would tolarate an endorsement of either format because they are so confusing. Who is to say if an article is American or European oriented? How do we know if the editor who wrote the date was obeying the Manual of Style? --Gerry Ashton (talk) 19:25, 12 August 2008 (UTC)[reply]

Written out dates, 12 August 2008 and August 12, 2008 are confusing? What system are you advocating? FWiW Bzuk (talk) 19:45, 12 August 2008 (UTC).[reply]

Ijanderson977 is advocating that if an article relates to Europe, and needs to mention today's date, it would be 12/08/08, but if the article relates to America, it be written 08/12/08. That's what confusing; dates where the date is written in letters are not confusing. --Gerry Ashton (talk) 21:15, 12 August 2008 (UTC)[reply]

That's not what mm/dd/yy or dd/mm/yy advocates unless it is in ISO dating format. When I see dd/mm/yy, it is a code for writing out 12 August 2008 and mm/dd/yy means August 1, 2008 to me; that's why I was confused, as I didn't see an argument for using numerical equivalents, merely for the arrangement of the day or month sequence. FWiW Bzuk (talk) 21:30, 12 August 2008 (UTC).[reply]

Where on earth would dd/mm/yy mean 12 August 2008 format, as opposed to 12/08/08 ?? Perhaps you meant dd Month yyyy.LeadSongDog (talk) 05:43, 13 August 2008 (UTC)[reply]

Yep, numbers alone are dangerous—I have to think carefully to interpret them, and sometimes still can't determine which system. The advantage of spelling out the month is that (1) it instantly classifies all three components of a full date, and (2) it's more accessible to most readers. Tony (talk) 05:32, 13 August 2008 (UTC)[reply]

Guidance is only needed if there is a significant problem to solve *and* it would not be solved by the wiki. The format 'xx/yy' is not present in any significant amount and is quickly changed by the wiki. Thus guidance is not required. Lightmouse (talk) 10:01, 13 August 2008 (UTC)[reply]
I was just saying isn't it best to use the American style date format on American articles and European format on European articles. I thought that would be easy enough to understand and it makes sense. Ijanderson977 (talk) 23:26, 13 August 2008 (UTC)[reply]
We say that: Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation; articles related to Canada may use either format consistently.
That Ijanderson977 appears to have missed it while considering the subject should be a hint on how widely read, and hence how useful, our guidance is.</irony> Septentrionalis PMAnderson 21:14, 14 August 2008 (UTC)[reply]
"...articles related to Canada may use either format consistently" - There are at least four different date formats in common use in Canada, plus some uncommon ones, so you can't reasonably expect to decode dates unless you have some more information than a person's location. Since this is the English-language Wikipedia, you can at least avoid the French date formats (which Canadian residents cannot), leaving only the British, American, and ISO date formats to contend with (and the ISO format is in common use in Canada). However, if you see something like "10/11/12" in a Canadian article, you really don't what it is. To avoid confusion with mixed date formats you must:
  1. Always use a four-digit year
  2. Always spell the month
That makes it unambiguous, regardless of whether the author means:
  • 10 November 2012,
  • October 11, 2012, or
  • 2010 November 12.
Otherwise you can't avoid ambiguity. RockyMtnGuy (talk) 00:10, 15 August 2008 (UTC)[reply]

Autoformat quick-question

Can someone tell me why we don't auto-format dates for non-registered users? -- SatyrTN (talk / contribs) 02:10, 13 August 2008 (UTC)[reply]

Your question seems to embody a misunderstanding. Autoformatting was a quick and very dirty fix that nobody in their right mind ought to have agreed to. Non-registered users see the dates as they were written. If, on the other hand, your question is why didn't the developers come up with with a system that did what many were deceived into thinking that autoformatting did, then your guess is as good as mine. Laziness? Incompetence? Ignorance? --Malleus Fatuorum (talk) 02:19, 13 August 2008 (UTC)[reply]

No, I meant what I asked. Why is it that a visitor to our site that doesn't log in to any account will see 2008-08-23 when a logged in user will see it auto-formatted? Why don't we auto-format dates for users that aren't logged in? -- SatyrTN (talk / contribs) 03:00, 13 August 2008 (UTC)[reply]

I don't think there is universal agreement that we should present information in the same format that the reader is most accustomed to. Few other publications see any need to do that; the only series I can think of is the Harry Potter books. --Gerry Ashton (talk) 03:08, 13 August 2008 (UTC)[reply]

Wikipedia should end its addiction to tinkering with date formats and mandating date format consistency within articles. Ordinary people do not care much. Wikipedia clearly does not care much about what ordinary readers see. As an issue, date format is less of a concern than regional spelling (color vs colour). Spelling can be wrong for the region but unambiguous date formats are not wrong, merely less common. Lightmouse (talk) 09:47, 13 August 2008 (UTC)[reply]

I bet the reason why we don't auto-format dates for non-registered users is because we couldn't reach consensus on which format to convert them into! Basing the choice on something arbitrary and essentially random would be the only "fair" way to do it. (sdsds - talk) 16:15, 13 August 2008 (UTC)[reply]
Or perhaps basing it on the country of origin, as determined by their IP, which would at least be right most of the time - that would be much more fair, IMO. -- SatyrTN (talk / contribs) 16:25, 13 August 2008 (UTC)[reply]
  • SatyrTN: Regarding your 03:00, 13 August 2008 post (“Why is it that a visitor to our site that doesn't log in to any account will see 2008-08-23 when a logged in user will see it auto-formatted?”), exactly. Somewhere along the lines, some developers had a total brain-abortion and developed template tools that only benefit readers if A) they sign up as a registered editor, and B) go to their user preferences and adjust their default setting. As a result, if editors code [[2005-08-06]], we (the minority privileged registered editors) will see either August 6, 2005 or 6 August 2005 (after setting our users preferences). But the vast majority of readers see only  2005-08-06. How ugly and ambiguous is that? Is that June 8, 2005 or August 6, 2005? Although this is an ISO-standard, all-numeric format for consistently storing and retrieving data in computers, it is certainly not human-friendly. It’s not intuitively clear what date it is until the 13th day of the month. The proper thing to do is simply stop using all templates and tools that don’t benefit everyone equally.

    What would solve all of this is if Wikipedia developers made a parser function that looked to the requesting reader’s I.P. address so it knew what country they are from. This is routinely done on Web servers of all sorts so they can spoon-feed custom content to the reader and collect reader statistics. There could be certain parser function classifications and groupings of these classifications, such as “US/other” or “US/Commonwealth”, “NorthAmerica/Other”, “US/UK”. Then we could have templates like {{US/Commonwealth|trunk|boot}} so text for US readers would be “…he put the bomb in the trunk of the car…” and UK and Australian readers would see “…he put the bomb in the boot of the car…”. Similarly, editors could write {{US/Commonwealth|color|colour}}. For dates, (although I personally don’t have a problem looking at 2 August 2008), one could write {{US/other|July 4, 1776|4 July 1776}}.'

    The simple solution is for editors to stop using the formatting tools. That will also stop linking dates to mindless lists of historical trivia. If one is writing an article on an intrinsically historical subject, such as Napoleon Bonaparte, then linking “1799” can be topical. But for most articles, the resultant links to seemingly random trivia are not topical and just junk up articles with too many blue links, which discourages learning and exploration. If someone is reading up on Planck units, they don’t need to read that “Max Planck first proposed them in 1899”, and click on the link in hopes of learning more about his proposal, only to be faced with stuff like “July 17: The French Bretonnet-Braun mission is destroyed in the battle of Togbao, in Chad, by the warlord Rabih az-Zubayr.” (*aack*) Greg L (talk) 17:21, 13 August 2008 (UTC)[reply]

  • OK, we’ve discussed this more than long enough. See the endless threads, above, on this issue. It keeps coming up again and again and again. I simply don’t understand why there has been so much paralysis on action regarding discouraging the use of [[2005-08-06]]. It is beyond worthless. I added a footnote (∆ here) to the table of date formats, here. Given that this particular format produces (to quote O.J. Simpson) “ugly-ass” text for the majority of readers, this seems a common-sense thing to do. I guess we’ll just sit back and watch for who reverts it and why; that will at least clarify for me why this paralysis has gone on for so damned long. Greg L (talk) 17:38, 13 August 2008 (UTC)[reply]
Your simple solution is to get hundreds of editors to change thousands of articles.
My simple solution is to get a few developers to change a relatively insignificant amount of code.
Which is simpler? -- SatyrTN (talk / contribs) 17:47, 13 August 2008 (UTC)[reply]
I applaud you being bold, but since consensus has not been reached on discouraging the use, I've reverted your change until we do have consensus. -- SatyrTN (talk / contribs) 17:49, 13 August 2008 (UTC)[reply]
  • Good luck with the developers. I’m not holding my breath. Greg L (talk) 17:52, 13 August 2008 (UTC)[reply]

I can't work out where to comment, but my comment would be that I'd support dropping date formatting as long as we adopt the compromise we have for spelling, first contributor unless article subject indicates a national tie and consistency. Hiding T 18:12, 13 August 2008 (UTC)[reply]

  • Hiding, you know where I stand on linking of dates. As for formatting, I couldn’t care about this issue and am utterly baffled that there is so much conflict over it. I’m an American, where “February 14, 2007” is common but when I write articles that aren’t closely tied to the U.S., I use the fluid and ‘metropolitan’ “14 February 2007”. The Euro style progressively builds from small to big and saves a comma. More importantly, either method confuses absolutely no one.

    As to spelling, there is already a perfectly workable solution on WP:MOS:

(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. It also keeps authoring on Wikipedia a fun hobby for everyone by not discouraging editors who have invested a lot of time and energy into an article, only to see someone wade in later and change the spelling to someone else’s national convention. Is there some proposed change afoot being contemplated? To bad if it is; the current guideline seems to be one of the wisest policies I’ve seen on Wikipedia.

And finally, why do you perceive there is a link between the dropping of linked dates and spelling? Or is it that you are offering your support for one issue if you gain support for another? Greg L (talk) 20:05, 13 August 2008 (UTC)[reply]

  • You seem to be reading more into my comment than I wrote. I haven't mentioned linking of dates, but since you opened that can of worms, I prefer to link to dates when they are useful, and object to arbitrary removal of them, and support piped links of the type [[1938 in comics|1938]]. With regards formatting, I think we are in agreement, but I'm finding it hard to tell. Why do you think I perceive a link between the dropping of linked dates and spelling? To my best knowledge I'm not currently engaging in quid pro quo, but if it is on offer, I'll gladly take some. I just happened to follow a link on {{tl:Cent}}. Hiding T 23:11, 13 August 2008 (UTC)[reply]
  • I've asked this before and don't recall much of an answer. It would be fairly easy to have autoformatted/linked dates render without links. When links were desired they could still be created with pipes, since that circumvents autoformatting. This would require no changes to articles, would retain autoformatting for those who want it, and would remove a whole lot of unnecessary blue. What are the downsides to this solution to the datelink problem? Gimmetrow 18:50, 13 August 2008 (UTC)[reply]
  • Is there anyone here who thinks [[2005-08-06]] is a *good* thing? I’ve seen precious little support for it and thought there was a consensus to loose the thing. No editor would be required to wade back into their articles and deprecate all instances of it; deprecation can be left to those editors who give a darn. And if they do the task properly (not mix styles or use the opportunity to change the date style used in the article), it’s easy as pie. Greg L (talk) 20:10, 13 August 2008 (UTC)[reply]
  • Is this intended to be a response to me? Gimmetrow 20:15, 13 August 2008 (UTC)[reply]
  • Not necessarily. It’s directed to anyone who thinks [[2005-08-06]] is a *good* thing. If there are few (or even no) supporters, then it’s time to stop using a date format that messes things up for 99.9% of Wikipedia’s readership. P.S. I believe your question was provoked by how my post was seeming clueless to your position. Yes. I understand where you stand on the linking of dates. I would indeed be interested to know how you feel about that one particular date formatting tool. Greg L (talk) 20:19, 13 August 2008 (UTC)[reply]
  • Oh, Gimmetrow: In answer to your question as to whether there are any downsides; I think you have an outstanding idea. But I’ve read here that the formatting tools were the product of a developer who likes loves the links and doesn’t respond to requests to loose them. That’s about the only downside of your proposal that I can see. Greg L (talk) 20:26, 13 August 2008 (UTC)[reply]
  • Actually, GregL, I use 2008-08-13. Often. It's the quickest way to enter a date. Though, honestly, I usually do that in refs, not in the main body of the article. And Gimmetrow, I would totally support taking the links off of autoformatting. I'd also totally support auto-formatting for non-logged in readers. -- SatyrTN (talk / contribs) 21:06, 13 August 2008 (UTC)[reply]
  • I think a format like 2008-08-14 is by far the best way to render a clear and unambiguous date. If several dates are used, it is immediately obvious in which sequence they are. In a table they line up neatly. No confusion of meaning is possible. It is easily searchable. In my daily work in an international company we almost exclusively use that format. −Woodstone (talk) 09:32, 14 August 2008 (UTC)[reply]
  • Woodstone: It’s beside the point whether you use “2008-08-14” for such purposes. I’m talking about the use of “[[2008-08-14]]”, which editors are using for in-line prose and like the results because they don’t realize that it junks up in-line prose with ugly all-numeric dates for the vast majority of readers. Either that, or the do realize that it junks it up for most readers and don’t give a crap. It was unwise for the developers to have provided a tool that produces the intended effect only for registered editors. That decision was simply brain damaged. Greg L (talk) 15:19, 14 August 2008 (UTC)[reply]
  • I don't understand why it "junks up" the prose. It is just a notation. We don't write "August fourteen, twothousand eight" do we? People see a number and read words. After the first few times it becomes natural to just see a "date", not a "code". −Woodstone (talk) 19:46, 14 August 2008 (UTC)[reply]
  • I do write "August 14, 2008," routinely. Whenever I meet an ISO date from the first third of the month and context does not make the answer obvious, I have to stop and remember which one encodes the day and which the month. To us, ISO dates are obnoxious and confusing. That is sufficient reason to use them with extreme caution. Septentrionalis PMAnderson 21:27, 14 August 2008 (UTC)[reply]
  • I agree with Woodstone for the reasons he stated. Firstly, it is ironic that ISO8601 was created to solve the problem we are discussing, yet we want to ban it. Secondly (and perhaps more importantly to Greg) if we continue with the status quo libertarian view, we can delink dates throughout an article simply by removing the square brackets - if ISO is banned, we effectively ban delinking as a single action. Lightmouse (talk) 09:53, 14 August 2008 (UTC)[reply]
(ec)Yes, Greg, unambiguous dates in wikitext that do not need translation are a good thing because they are more often correct. No, Greg, dates wikilinked by default are not a good thing when they are badly rendered into ugly html which might be confusing to the few people reading wikipedia who have never used a computer before. There is no end run, we have got to get the developers to fix the code.LeadSongDog (talk) 21:14, 13 August 2008 (UTC) - addendum: Isn't it odd that the "search" function can render dates according to preference when logged in, or as "13 August 2008" when not logged in? Why is it so hard to accept the same thing elsewhere?LeadSongDog (talk) 21:39, 13 August 2008 (UTC)[reply]
  • I’d take advantage of a template that formated dates so they display as “13 August 2008” for I.P. users and as “August 13, 2008” for registered, logged-in editors, who set their user preferences setting to the U.S. style. That would be nice for readers. Except, all these tools currently link to trivia. Doing a bugzilla requires someone who is “tight” with the developer community and “hangs” in the relay chat rooms and all that. If anything is to be done, someone like this needs to step up to the plate. Greg L (talk) 22:40, 13 August 2008 (UTC)[reply]
Downside: Certain usage usually goes together. "Colour" goes with "13 August 2008". "Color" goes with "August 13, 2008". Writing styles typical of the U.S. military also go with "13 August 2008". If the date style does not match the style of the rest of the article, a certain dissonance is created, which may seem more disturbing than a slightly unfamiliar date style. --Gerry Ashton (talk) 22:56, 13 August 2008 (UTC)[reply]
The advocates of a clear, unambiguous "written out" date seem to have made some inroads here. ISO dating is not used in prose and its continued use as part of a citation template is the only reason for its continued use in Wikipedia although "dumping" it as a citation prerequisite should now be a primary concern. Despite a recent comment by an editor or two that claims to use ISO dating in normal correspondence, the problems still exist as to translation by a reader unfamiliar with the system. The "mix" of date styles or formats is especially jarring for a reader. If the majority of the information is in textual form, then a written out date, August 13, 2008 or 13 August 2008 should prevail. FWiW, the one benefit of Wikipedia editing is that it is a fluid and flexible medium that has evolved over time, and that changes such as the ones being proposed can eventually be incorporated. Bzuk (talk) 23:25, 13 August 2008 (UTC).[reply]

Some dates are part of reading flow (body text). Some dates are just reference data (citations). The obsession with date consistency got us into this autoformatting mess and readers really do not care that much. I am happy to read 'Fourth of July' in one paragraph and 'September the Eleventh' in the next and I am happy if citations have compact ISO formats. The formats that almost all readers see today are not the problem, just take all the square brackets away. Lightmouse (talk) 00:12, 14 August 2008 (UTC)[reply]

Responses from Tony1, from bottom upwards:

  • I go with Lightmouse's call to "just take all the square brackets away".
  • Bzuk: Whether to use ISO dates in cite web et al. is mostly a matter of current editor choice rather than a task for developers. However, because a few editors strongly prefer ISO, I'd be willing to merely recommend against using it in citation-generated dates, as well as the current deprecation of its use in the main text. Better still, I think users need to be educated that there are significant advantages in retaining local control over formats by dispensing with citation templates altogether. The priority, to me, is to ensure that where templates are used, editors have the ability to switch date autoformatting on or off—a simple "link on / link off" field; this includes commonly used templates in infoboxes.
  • Gerry's right on inbuilt dissonance. The worst example is the clutch of articles on September 11, 2001, which renders manually entered DA dates on my display as "11 September 2001", defying the iconic phrasing we all know, including the concomitant "9/11"; that's dissonance for you. This is an example of why we should give editors the power to choose one of the two standard date formats in relation to the topic, rather than delegating this to distant developers in cocoons.
  • I agree with everything Greg L says, except his penchant for the alternative of lobbying to spread the system to an IP-based one. I wonder why it's worth it? Who cares whether it's month–day or day–month, when the month is spelled out? It's soooo trivial and not worth the technical/editorial palahva. Simple and locally controlled is best, for us and for our readers.
  • LeadDogSong: "There is no end run, we have got to get the developers to fix the code" (also Gimmetrow "It would be fairly easy to have autoformatted/linked dates render without links"). I disagree on two grounds. First, the code is not worth fixing, for most of the reasons under the cap that has been promulgated here and elsewhere. Second, the developers at Bugzilla are notoriously resistant to calls for technical change. Witness the failed call for the decoupling of DA and linking at https://bugzilla.wikimedia.org/show_bug.cgi?id=4582 Bugzilla], including, after more than a year, an 88-person petition of WPians (Jan 07). Brion Vibber is on record at the start as dismissing calls for decoupling linking from autoformatting ("this was done in part to encourage linking of dates so they can be used as useful metadata."—12 Jan 06); hmmm ... shows insight—no wonder the attempt is still in abeyance two and a half years later. To take the developers' side, though, it doesn't help when there are multiple suggestions for syntax and technical solutions; as well, developers, especially volunteers, stand to lose if there are any problems, so they're cautious folk. We're also dealing with WikiMedia, not WP; do you know how many sites use WM software? It's not easy.

Again, I ask, why bother to go through so much angst in search of a solution to a non-problem? I can think of lots of better places to direct our programming and editorial talent. The "end run" LeadDogSong talks of is here now: drop it altogether. Simplicity wins, usually. Tony (talk) 00:53, 14 August 2008 (UTC)[reply]

Tony1, did I hear the sacrosanct citation templates could be done away with? My heart goes pitter-patter (LOL). In reality, a great number of new editors who have little or no experience with research writing still need to rely on a "system" although either the Modern Language Association or American Psychiatric Association or Chicago style guides can be taught/learned with ease. All of these style guides have a simple to follow format. FWiW Bzuk (talk) 01:56, 14 August 2008 (UTC).[reply]
<utters quietly:>Yep, those templates are problematic, and I don't think they save any typing, either (someone correct me if they do). They simply introduce different errors. All our new editors need are a few models to choose from. It's not rocket science.
To me, the citation templates operate in the worst tradition of "garbage in, garbage out" as the users who are unfamiliar with the premises and concepts of bibliographical referencing, simply stick in more errors. The templates were thought to be an aid, they now appear as a major hinderance. FWiW Bzuk (talk) 11:48, 14 August 2008 (UTC).[reply]
  • To all: Indeed, I am talking about using “2005-08-06” only in tables and other special-purposes uses where tabular data and tight spacing is important. But for regular prose, there should be no use of “[[2005-08-06]]” because it only benefits we editors, 99.9% of readers see computerese, which doesn’t look nice. Either editors should loose the brackets and write out the dates (“2 August 2001”, or “August 2, 2001”). Either that or the developers should provide us with a formatting tool that benefits all readers. It was unwise for the developers to have provided a tool that produces the intended effect only for registered editors. That decision was simply brain damaged. Greg L (talk) 15:19, 14 August 2008 (UTC)[reply]
  • P.S. What I am specifically saying is that even a non-linking formatting tool like {{formatdate|15 May 2005}}, which would yield “15 May 2005” for I.P. users, and “15 May 2005” for European editors, and “May 15, 2005” for U.S. editors, is no good either. All of us editors need to stop thinking Wikipedia is some sort of private preserve where we can employ formatting tools that benefit only us. Greg L (talk) 15:34, 14 August 2008 (UTC)[reply]
Agreed - I believe everyone recognizes a date no matter what the format. Do we really need to have "preferences" for date formatting? Are we that sensitive? —Mattisse (Talk) 17:19, 14 August 2008 (UTC)[reply]
Wait - explain that. Why isn't formatting the date there any good? Why does formatting the date benefit only us? -- SatyrTN (talk / contribs) 15:53, 14 August 2008 (UTC)[reply]
  • SatyrTN, Wikipedia’s date formating options includes a total abortion that should never have been dreamed of, let alone included as a tool for editors to use. Examine the below table and take note of who sees what.
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 --
[[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
Note how if we were to code [[2005-08-06]], we (the minority privileged registered editors) would see either August 6, 2005 or 6 August 2005. But the vast majority of readers see only  2005-08-06.

Most registered editors stay logged in. As soon as they don’t see their name up at the top (every 30 days now), we log in again. Very few of we editors ever peruse Wikipedia and look at articles as a regular I.P. user. But 99.9% of Wikipedia’s readers are I.P. users.

So editors *think* they’re doing something wonderful with this stupid format option and, in fact, all we give 99.9% of our readers is the worst of both worlds: they don’t get the written-out dates we privileged editors see, and they get the damned links to mindless trivia that has next to nothing to do with the subject the article is about.

So that is why I advocate that editors should not use this particular date *formatting* option. If editors want “2005-08-06” for a tabular or special use, they should simply write it out. If editors want proper dates with a month written out (which they should want to usually do), they should at least use one of the other date formatting options. Better yet, just choose a style (either “August 6, 2005” or “6 August 2005”) and don’t link it.

This is why I suggested adding a footnote (∆ here) to the table of date formats, to produce this. Greg L (talk) 17:22, 14 August 2008 (UTC)[reply]

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)
I have my preferences turned off, as I am beginning to understand many logged in readers do. I would very much resent "big brother" deciding what my format "should" be. —Mattisse (Talk) 20:36, 14 August 2008 (UTC)[reply]
  • SatyrTN: Like other editors here, autoformatting is getting more and more despised because its shortcomings are increasingly seen as overcoming its virtues. I don’t have a problem looking at “August 6, 2007” any more than “6 August 2007”. So the autoformatting tools—for me anyway—are fixing a problem that was trivial to begin with. I can only guess that there may have been an unreconcilable holy war here between a “UK camp” and a “US. camp” and that precipitated the date autoformatting tools. The “autoformatting” tools really do two things: they autoformat, and they link.

    On the subject of links: I just can’t see the wisdom of cluttering up articles with even more links if all they do is take readers to random lists of historical trivia that have nothing whatsoever to do with the subject matter at hand. If we’re going to start linking to trivia, that suggests we might as well link to every other possible word; and attitude of “if Wikipedia has a damned article on it, LINK TO IT!!!!” When we over‑link—like with links to trivia—we just turn articles into a giant blue turd. A properly linked article invites exploration and learning by properly anticipating what the typical reader might be interested in further exploring.

    If I were writing an article on the speed of light, I might link to meter, for instance. Such topical links properly invite exploration and learning. When articles are over‑linked, we’re just numbing readers to links, such as when we add a link within speed of light that takes the reader to an article that says…

Tokugawa Ieyasu and what the hell he did in 1600 is of no consequence to someone reading a science article. It certainly doesn’t have anything to do with speed of light. If readers want to read a mind‑numbing list of random trivia that occurred on October 21st, they can type it into the search field.

Now, I don’t care to try to impress this basic lesson on technical writing upon every damned 8th-grade editor who takes the time to register and become a Wikipedia editor™®©. They can knock themselves out with the power of wikilinking and link the living shit out of everything they touch their hands to. I don’t want linked dates in articles I’ve worked hard to expand and make professional. I’m happy as a clam as long as MOSNUM doesn’tencourage the use of date *formatting* or linking or permit other editors who like to link dates to wade into nice mature articles and junk them up with even more links.

Finally, I’m all for expanding the use of date formatting so it benefits all readers (I.P. readers too, even though they account for *only* 99.9% of Wikipedia’s readership). 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. And I simply think it was profoundly unwise for a developer to have made a date format like [[2005-08-06]] where registered edtiors are deluded into thinking they’re making some pretty-looking dates like August 6, 2005 or 6 August 2005 but pretty much the entire rest of the planet sees 2005-08-06. Whoever thought that was a keeno idea should, IMO, be blocked for a week for stupidity. With the use of [[2005-08-06]], not only does the rest of the world see the all-numeric date in in-line body text, but if they have the misfortune of clicking on the blue link, they’re taken to the nothing but random trivia. Greg L (talk) 21:56, 14 August 2008 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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? SeveroTC 19:57, 14 August 2008 (UTC)[reply]

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

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

Read and endorsed. --Elliskev 00:30, 15 August 2008 (UTC)[reply]
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)[reply]


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

Now I know; this “date stuff” makes people… nuts!
Well, that much is obviously true. Teemu Leisti (talk) 06:04, 15 August 2008 (UTC)[reply]
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).[reply]
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)[reply]
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)[reply]

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:

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

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)[reply]
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)[reply]
Predictably enough, I do. Waltham, The Duke of 13:42, 15 August 2008 (UTC)[reply]
Why? --Philip Baird Shearer (talk) 15:04, 15 August 2008 (UTC)[reply]
I have mentioned both ofs and thes, have I not? Waltham, The Duke of 21:59, 15 August 2008 (UTC)[reply]
  • #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 14th 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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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

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

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)[reply]
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)[reply]
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)[reply]
They certainly will, it's an absurd suggestion. --Malleus Fatuorum (talk) 21:56, 15 August 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
This proposal becomes a horrible mess for any date before 14 September 1752. --Gerry Ashton (talk) 18:27, 18 August 2008 (UTC)[reply]

Gregorian calendar

Template:RFCstyle

Dates like 1582-10-10 appear to be in ISO 8601 format. This is especially true for autoformatted dates, because the user preferences window indicates this format with the text "2001-01-15T16:12:34", which is unmistakably in the ISO 8601 format. The ISO 8601 format requires the use of the Gregorian calendar, and for dates before that calender was introduced, the proleptic Gregorian calendar. Browsing a few articles suggests that many editors do not understand this convention, and are therefore presenting incorrect dates to readers. Also, a date in a non-numeric format such as 10 October 1582 will generally be presumed to be in the Julian calendar (since it is before the introduction of the Gregorian calendar) so if it is autoformatted, the meaning of the date changes depending on the reader's preference setting.

Please note that discussions on this matter have been quite amicable and this RFC is only to attract a wider audience.

--Gerry Ashton (talk) 17:46, 18 August 2008 (UTC)[reply]

I have moved the recent addition:

Because readers who are logged in and have set a date and time preference to "2001-01-15T16:12:34" will see what seems to be an ISO 8601 format date, and because ISO 8601 format only uses the Gregorian calendar (or the proleptic Gregorian calendar before that calendar went into force in various areas), articles autoformatting any date before the adoption of the Gregorian calendar in the area discussed in the article should explicitly state that the proleptic Gregorian calendar is used in the article. A date in any calendar except the (proleptic) Gregorian calendar must not be autoformatted.

to here for further discussion, because it affects so many article and we should give careful consideration to whether this should be addressed separately from a general removal of links on dates --Philip Baird Shearer (talk) 11:55, 18 August 2008 (UTC)[reply]


The MOS contains the text:

  • A date in any calendar except the (proleptic) Gregorian calendar must not be autoformatted.

Does that mean that autoformatting is not safe for dates prior to 1583? Lightmouse (talk) 08:56, 17 August 2008 (UTC)[reply]

The proleptic Gregorian calendar means this very thing: that it is used for dates in areas which did not have the Gregorian calendar then. The guideline refers to different calendars. But yes, editors should be more careful for these dates.
I suppose this complication is yet another reason why we would be better off without auto-formatting. Waltham, The Duke of 09:14, 17 August 2008 (UTC)[reply]

Hmm. This is worrying. Are you saying that all the current links for dates prior to 1583 are safe? It is just editors that create new links that need to watch out? Lightmouse (talk) 09:26, 17 August 2008 (UTC)[reply]

No; I cannot possibly claim that the Manual of Style is adhered to in every single article. Quite the contrary. What I am saying is that, as long as we use auto-formatting, it is not restricted to dates after 1583. If by "safe" you mean "foolproof", then yes, it is unsafe to use auto-formatting for dates in a calendar other than the Gregorian. But again, I don't think anything is foolproof in Wikipedia. (And we're aiming to remove auto-formatting anyway; we might as well start from the more dubious dates.) Waltham, The Duke of 10:28, 17 August 2008 (UTC)[reply]

I agree. There are general problems with autoformatting that apply to all dates. I was not aware until now that dates prior to 1583 have a specific error condition that will almost certainly remain uncorrected. I propose that the current text:

  • Because readers who are logged in and have set a date and time preference to "2001-01-15T16:12:34" will see what seems to be an ISO 8601 format date, and because ISO 8601 format only uses the Gregorian calendar (or the proleptic Gregorian calendar before that calendar went into force in various areas), articles autoformatting any date before the adoption of the Gregorian calendar in the area discussed in the article should explicitly state that the proleptic Gregorian calendar is used in the article. A date in any calendar except the (proleptic) Gregorian calendar must not be autoformatted.

is changed to:

  • Dates prior to 1583 must not be autoformatted. This is because autoformatting of dates that are not Gregorian or proleptic Gregorian can cause an error that is almost impossible to detect.

Lightmouse (talk) 10:41, 17 August 2008 (UTC)[reply]

The guideline is wrong, as is the proposal. For example William Shakespeare died on April 23 1616. If what you are saying is true then nearly every date article on Wikipedia will need changing, and the dates of events in the general articles will have different dates from those in the date articles. It will also effect categories for births and deaths of those born around January 1. Indeed for some years Christmas day will not be in the right year let alone on the right day.--Philip Baird Shearer (talk) 11:02, 17 August 2008 (UTC)[reply]

I think it was Gerry Ashton who inserted this yesterday. Gerry, can you assist in this discussion? Tony (talk) 11:08, 17 August 2008 (UTC)[reply]
The problem, which is what I had in mind when I edited the guideline, is that a reader is apt to presume that a date that looks like 1582-10-04 is an ISO 8601 date, especially after reading this guideline and viewing the date and time preferences window. Since ISO 8601 dates by definition use the (proleptic) Gregorian calender, 1582-10-04 is 11 days before the introduction of the Gregorian calendar, and would have been designated 24 September 1582 on the Julian calender which was in use on that day. Because the potential for errors is so great, and because readers who have chosen the ISO format have a definite statement about the calendar just by the format of the date, which other readers lack, it is wise to confirm to the ISO format readers, and to inform the other readers, that the proleptic Gregorian calendar is in use.
I am not aware of any fault in the automatic formatting that causes dates before 15 October 1582 to be displayed incorrectly.
Since ISO 8601 only uses the Gregorian format, any attempt to use that format and at the same time state that some other calendar is in use is an unacceptable contradiction.
I'm cheap, so I have not purchased the official version of the ISO 8604 standard, but here is a quote from a version that is on the web:
The introduction of the Gregorian calendar included the cancellation of the accumulated inaccuracies of the Julian calendar. However, no dates shall be inserted or deleted when determining dates in the proleptic Gregorian calendar. NOTE In the proleptic Gregorian calendar, the calendar year [0000] is a leap year. EXAMPLE The Gregorian calendar was introduced on 15 October 1582. In the calendar set by this standard the calendar day preceding that calendar day is referred to as 14 October 1582. In the Julian calendar that calendar day is referred to as 4 October 1582.
--Gerry Ashton (talk) 18:06, 17 August 2008 (UTC)[reply]

Philip, I'm not sure what you mean by "if what you are saying is true then nearly every date article on Wikipedia will need changing". Could you explain? What is a "date article"? --Gerry Ashton (talk) 20:06, 17 August 2008 (UTC)[reply]

By date article I mean under the article "date day" things that happened on that day will need adjusting if we are to say that such and such an event happened on that day. For example what was the date of the Battle of Agincourt? The article says "25 October 1415", as does the day date of October 25. We should not adjust such a date to the Gregorian calendar --Philip Baird Shearer (talk) 22:18, 17 August 2008 (UTC)[reply]
More to the point, because there is ambiguity, articles should say which calendar dates are expressed in. We must not assume that readers are familiar with MOSNUM.LeadSongDog (talk) 13:16, 18 August 2008 (UTC)[reply]
a reader is apt to presume that a date that looks like 1582-10-04 is an ISO 8601 date, especially after reading this guideline and viewing the date and time preferences window - I'd say that less than 1 in 1000 readers knows what an ISO 8601 date is, and less than 1 in a million readers will have read this guideline. So let's not do anything based on what readers know about either of these things - in fact, I'd give long odds that the vast majority of readers have no idea what the difference is between Julian and Gregorian calendars (and yes, that is certainly covered in one or more classes in high school, or earlier, but that doesn't mean that people remember what was taught). -- John Broughton (♫♫) 20:01, 19 August 2008 (UTC)[reply]

Shakespeare: a particular error

When reading Wikipedia's William Shakespeare article with date/time preferences set to ISO 8601 format, we read:

William Shakespeare (baptised 1564-04-26 – died 1616-04-23)[a]
.
.
.
a. ^ Dates use the Julian calendar, used in England throughout Shakespeare's lifespan. Under the Gregorian calendar, which was adopted in Catholic countries in 1582, Shakespeare died on May 3.[187]

So the format of the date proclaims it is in the Gregorian proleptic calendar, but the footnote proclaims it is in the Julian calendar, so the article contradicts itself. --Gerry Ashton (talk) 18:17, 17 August 2008 (UTC)[reply]

The article does not use 1564-04-26 it uses "26 April 1564 – died 23 April 1616". If one sets date format in one's preferences one will see "baptised 1564-04-26 – died 1616-04-23" but there is nothing to say that that is a Gregorian date and the footnote makes it clear that Julian dates are being used -- as is the norm for dates in England before the Calendar (New Style) Act 1750 and the changes bought in in 1752.
Gerry Ashton, you are making the assumption that is not born out in fact of how dates are entered in Wikipeida. If an editor enters the date as 1616-04-23 and the event took place in England they are assuming the Julian calendar not the Gregorian calendar date, and the link goes to the common English events of that date one of which is the death of Shakespeare. This is made clear in this guideline in the section Calendars. There is nothing in the preferences that says that the style yyyy-mm-dd is an ISO 8601 format it only says:
  • No preference
  • 16:12, January 15, 2001
  • 16:12, 15 January 2001
  • 16:12, 2001 January 15
  • 2001-01-15T16:12:34
To alter dates would be very time consuming and complicated, for example Charles I executed on 30 January the articles Charles I of England, High Court of Justice for the trial of Charles I and the day say January 30? The Battle of Hastings says October 14, as does the article October 14. If we were to alter this Wikipeda would be at odds with just about every secondary source that is published on these topics. And No I see no problem with autoformatting to October 14 from the Battle of Hastings article any more than November 5 from the Glorious Revolution (An auspicious date for the landings because of the Gunpowder Plot):
  • 1605 - Gunpowder Plot: A plot led by Robert Catesby to blow up the English Houses of Parliament is thwarted when Sir Thomas Knyvet, a justice of the peace, finds Guy Fawkes in a cellar below the Parliament building.
  • 1688 - Glorious Revolution begins: William of Orange lands at Brixham.
Or October 25 to the 1917 October Revolution. Much easier to add a warning to those using the format YYY-MM-DD in this guideline --Philip Baird Shearer (talk) 22:18, 17 August 2008 (UTC)[reply]
The association between dates in the format 2001-01-15 and ISO 8601 is quite strong, and the association between the format 2001-01-15T16:12:34 and ISO 8601 is so strong as to be practically unbreakable. Furthermore, many editors and readers seem to think such an association within Wikipedia does exist. If Wikipedia made a futile attempt to break the association by posting some text somewhere, it would amount to a truly idiotic and uncalled for novel standard. I suggest going through all the date articles with a bot and removing all the autoformatting. --Gerry Ashton (talk) 22:42, 17 August 2008 (UTC)[reply]
Also, I take the view that a date in an article is entirely wrong if it is wrong for any possible presentation using any possible user preference. If it is right for a user using no preference, and autoformatted into an error for a user with the 2001-01-15T16:12:34 set, it is wrong. --Gerry Ashton (talk) 22:45, 17 August 2008 (UTC)[reply]

There seems to be a conflict of what is expected of autoformatting:
1 - That it correctly interprets and formats the date, which is NEVER going to happen. Any date from 1582 until the date of Gregorian switchover in the relevant locale, you'd also need to know which calendar (Gregorian or Julian), which implies a need to incorporate location into the date. And which date is being used for new year, 25 March or 1 January?
2 - That it formats a text string into the format preferred by the reader. While I can see the point that it's not going to help most readers, it will help registered users, those who are more likely to get into edit-wars over date format than casual readers. If autoformat forestalls edit wars I'm all for it. Bazj (talk) 23:57, 17 August 2008 (UTC)[reply]

Again, Bazj, you're promulgating this fear of edit-warring without evidence that it has already occurred or is likely to occur. Apart from the power of the ArbCom ruling, emblazoned at the top of MOSNUM and elsewhere, to lead to the quick, clean hosing down of any dispute that did occur, I put it to you that the community has moved on from such systemic edit wars. I hope this is not fearmongering! Tony (talk) 00:17, 18 August 2008 (UTC)[reply]
Bazj's post illustrates the danger of the passive voice when he writes "what is expected of autoformatting". Just who is doing the expecting? In the absence of an explicit statement, I assume that since we exist to serve the reader, the reader is doing the expecting. A reader who registers and sets a preference to 2001-01-15T16:12:34 will either not know what to expect (due to ignorance of ISO 8601, the finer points of the Gregorian calendar, or both) or will expect dates to be in the (proleptic) Gregorian calendar. Any date that does not satisfy that perfectly reasonable expectation is wrong. --Gerry Ashton (talk) 00:31, 18 August 2008 (UTC)[reply]
"Any date that does not satisfy that perfectly reasonable expectation is wrong." The date is not wrong -- it would be wrong (as it would not be supported by most reliable verifiable sources) to use Gregorian dates for British events that happened before 1752. Wikipedia is no alone in making such compromises. This NASA source say "All eclipse dates from 1582 Oct 15 onwards use the modern Gregorian calendar currently found throughout most of the world. The older Julian calendar is used for eclipse dates prior to 1582 Oct 04. Due to the Gregorian Calendar Reform, the day following 1582 Oct 04 (Julian calendar) is 1582 Oct 15 (Gregorian calendar). ... here are a number of ways to write the calendar date through variations in the order of day, month and year. The International Organization for Standardization's ISO 8601 advises a numeric date representation which organizes the elements from the largest to the smallest. The exact format is YYYY-MM-DD where YYYY is the calendar year, MM is the month of the year between 01 (January) and 12 (December), and DD is the day of the month between 01 and 31. For example, the 27th day of April in the year 1943 would then be expressed as 1943-04-27. We support the ISO convention but have replaced the month number with the 3-letter English abbreviation of the month name for additional clarity. From the previous example, we express the date as 1943 Apr 27." Which is similar to the wording we use in this guideline. BTW that NASA source links to a page called Calendar Dates that links to a Swiss site which includes this page that says: "The ISO 8601 date format may be used both with the Gregorian and with the Julian systems (and with many other calendar systems). Dates in the Julian calendar are marked with 'J', and those in the Gregorian calendar (when this is made explicit) are marked with 'G'." --Philip Baird Shearer (talk) 10:46, 18 August 2008 (UTC)[reply]
What I mean by Wikipedia had warnings about ISO is in this guideline:
  • Dates "ISO 8601 dates (1976-05-31) are uncommon in English prose, and are generally not used in Wikipedia. However, they may be useful in long lists and tables for conciseness and ease of comparison." (also given in WP:MOS#Dates
  • Calendar "Dates before the adoption of the Gregorian calendar on 15 October 1582 are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details). ... "Dates of events in countries using the Gregorian calendar are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see the Gregorian calendar article). ... The dating method used in a Wikipedia article should follow that used by reliable secondary sources. If the reliable secondary sources disagree, choose the most common used by reliable secondary sources and note the usage in a footnote."
I think that this gives sufficient warning (similar to the NASA eclipse web article above) that autoformatted ISO looking date strings will use both Julian and Gregorian date depending on what is the normal method of describing dates for a given topic. --Philip Baird Shearer (talk) 12:08, 18 August 2008 (UTC)[reply]

The Swiss web site mentioned by Philip is the personal web site of Peter Meyer. Ordinarily it would be considered unreliable, although I have seen it mentioned favorably in a number of places. In any case, he has no authority to change an ISO standard that explicitly says it uses only the Gregorian calendar. Furthermore, section 3.4 of the standard, "Characters used in the representations" does mention single letters with special meanings, like "T" and "Z", but does not mention Meyer's "J" or "G". The instant you put a "G" or a "J" onto what would otherwise be an ISO 8601 date, it becomes a Peter Meyer date.

Wikipedia does indeed say we should ordinarily use either the Julian or Gregorian calendar, whichever was in general use in the area described in the article. That's the right thing to do. (What to do in an area that used some other calendar is not so clear.) Wikipedia also strongly implies that dates in the YYYY-MM-DD format are ISO 8601 format, and even if we didn't imply it, readers would infer it anyway. Thus, every article that presents a date in the YYYY-MM-DD format is proclaiming that it is in the Gregorian calendar. If the article has a note to the contrary, the article contradicts itself.

We could attempt to create the "English Wikipedia Standard Date Format" and try to explain how it might be either Julian or Gregorian, depending on the country discussed, but that would be a terrible idea. It would be better to just not use the ISO 8601 format, or autoformatting, for any date preceeding 14 September 1725, as well as any date in the Julian calendar after that date. I'm starting to think this needs wider attention, perhaps at the Village Pump. --Gerry Ashton (talk) 17:25, 18 August 2008 (UTC)[reply]

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:

212

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-12 and 2 12). 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&frac12; 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)[reply]

Use {{frac}} (or unicode). {{Frac|2|1|2}} gives "2+12" 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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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).[reply]
I don't care. Good bye. -- llywrch (talk) 21:37, 19 August 2008 (UTC)[reply]

Again calling for date linking to be deprecated

Although the discussion always seems to go off at various tangents when the issue is raised (like when I raised it above), I still see no argument of any weight against deprecating the linking of dates (except in special cases), and plenty of arguments (and apparent consensus) in favour. If no-one can come up with a valid counterargument, I'm going to start feeling bold and editing the guideline accordingly.--Kotniski (talk) 10:57, 16 August 2008 (UTC)[reply]

I do not think we are anywhere near the stage of changing the guidelines as yet there is definitely no agreement as far as I can see to depreciate the use of date linking. It looks like from the arguments that we are heading for a do it on an article by article basis. I still think that the way forward is a software change that would enable dates in articles to be put in which ever format people want and then for them to be formatted for display according to user preference or according to browser preference for unregistered users. The constant changing of dates by people as has been noted above causes a significant number of history revisions on articles, this will continue as people will put the dating in in their normal manner no matter what we prescribe here. By changing the software to correctly do the actual formatting for the user means that the format in the article source is irrelevant. This will cut out the need for changes to articles where the only change is from '2 August' to 'August 2'. Those that want to use ISO dates can do as people will not see them as such unless they chose that preference or have a browser set for that preference. The software could also be changed to display or not display the links to the date articles and so solve the problem of too many blue links that some people have. Keith D (talk) 11:29, 16 August 2008 (UTC)[reply]
I see no earthly point in doing it on an article-by-article basis. I mean the linking; obviously the style of date will be consistent only at article level. But one we've decided (as I believe we have) that there is no virtue and much vice in linking dates for the sole purpose of making autoformatting work, then this surely applies to one article as much as to any other. So let's change the guidelines so that edits which remove date links (which nearly everyone agrees are improvements) are not detrimentally reverted on ENGVAR-type grounds. What the developers may do with the software in the future is not foreseeable enough to be of much concern to us - personally I hope they don't waste any of their valuable time over this issue when there are many far more significant improvements waiting to be done.--Kotniski (talk) 12:29, 16 August 2008 (UTC)[reply]
Well, predictably, I fully support Kotniski's call. However, I don't think reversions are on any rationale basis, let alone ENGVAR. Perhaps leave a little room for autoformatting while generally recommending it not be used? That might save angst in quarters where folk will become very upset at losing their blue-splotch dates. Tony (talk) 13:15, 16 August 2008 (UTC)[reply]

Excellent idea Keith! Please go ahead and change the software. We're not heading for an article-by-article basis: this is where we're at. The delinking being done on this basis has been generally met with a positive response. The arguments for it are strong. Those not in favour of depreciating autoformatting seem to think it can be fixed. If you've been following the issue, you'd understand why those in favour of depreciation have given up hope in having it fixed. We're everywhere near the stage of changing the guidelines. Let them be changed but heed Tony's call about allowing a little room to move (at least for now) for those who still think it's a good thing. JIMp talk·cont 14:00, 16 August 2008 (UTC)[reply]

Not sure I understand what is envisaged by this "a little room to move" - can you or Tony be more specific? --Kotniski (talk) 15:15, 16 August 2008 (UTC)[reply]
Well, that could be achieved in a number of wordings; for example, by including the word "generally", or "unless there is good reason to use it", or some such. This would soften what might otherwise be an imperative, and would avoid suddenly turning the vast majority of articles into MOS breaches while at the same time legitimising the change-over. Tony (talk) 15:33, 16 August 2008 (UTC)[reply]
Although there are still some "pockets of resistance", I wonder if Tony1's reasoned arguments behind the change can be posted somewhere as "pointer" to the direction being advocated. FWiW Bzuk (talk) 15:39, 16 August 2008 (UTC).[reply]
  • Jimp, Tony: I think you’ve got some inertia going here in identifying what needs to be done and are doing good work in finally fixing MOSNUM. Loose the links to random trivia that is usually beyond tangential to the articles. Formatting by itself (without linking) seems perfectly workable tool when employed properly under current guidelines—but with one caveat: Except for the [[2005-06-08]] method, which isn’t for producing ISO formats, but was intended to take an ISO-formatted input with which to output dates with spelled-out month names *but it only does so for registered edtiors* (terribly unwise since 99.9% of readers see numeric-only dates). I suggest a bot be made that goes in to articles, looks for any other hard-coded dates to see how they are formated (14 Feb or Feb, 14), and which then converts the ISO-input dates to hard-coded ones. Greg L (talk) 20:54, 16 August 2008 (UTC)[reply]
Earlier on this page SandyGeorgia had indicated some formatting problems in the citation template that precluded the use of any other format than ISO dating, which is still an prospect of take this information "with a grain of salt" as previous efforts to have the templates adjusted have not been well received. An attempt to have MLA-style templates was simarily rebuffed, so don't hold your breath. FWiW, now, have I mixed enough metaphors in one statement? Bzuk (talk) 21:48, 16 August 2008 (UTC).[reply]
  • Disagree - The work being done, albeit well intentioned, to remove markup that indicates some text may be automatically formated, is a step in the wrong direction. What wikipedia (enwiki, and elsewhere) needs is more markup indicating text which can be autoformatted, not less! (sdsds - talk) 00:43, 17 August 2008 (UTC)[reply]
Sd is concerned that meta-info will be lost forever if we say good-bye to double square brackets in dates; I've explained on his/her talk page that identifying raw dates is a piece of cake for a script if need be in the future. I don't know how this point was lost. I don't think there will be much enthusiasm for more markup in search of a problem that doesn't exist. Tony (talk) 00:54, 17 August 2008 (UTC)[reply]

Here's the text: I think this is the insertion we're looking for (in italics) in the "Date autoformatting" section. It will promote the simplification of wikitext, an increase in the salience of our high-value links, and the reduction of colour-clutter in our article text. It's a good example where a straight move towards simplicity in process immediately improves the product.

A combination of day-number and month can be autoformatted by adding square brackets ([[5 November]] or [[November 5]]; [[5 November]] [[1989]] or [[November 5]], [[1989]]). The square brackets instruct the MediaWiki software to format the item according to the date preferences for registered users who have chosen a setting and are logged in. This should not generally be used unless there is a particular reason to do so. Careful consideration of the advantages and disadvantages of the autoformatting mechanism should be made before applying it: the mechanism does not work for the vast majority of readers, such as unregistered users and registered users who have not made a setting, and can affect readability and appearance if there are already numerous high-value links in the text.

I've also inserted the US style into the example, for users who do have "a particular reason to do so"; I don't know why that was ever left out. Tony (talk) 00:51, 17 August 2008 (UTC)[reply]

Looks good. SandyGeorgia (Talk) 03:12, 17 August 2008 (UTC)[reply]
I would oppose this change. Aside from the addition being obviously false at the moment, since autoformatting is the current dominant practice, it is a step in the wrong direction to legislate personal preference in this manner. Providing the facts neutrally and leaving editors to use their best judgment is ideal. Christopher Parham (talk) 03:39, 17 August 2008 (UTC)[reply]
Christopher, I'm willing to change "is not generally used" to "should not generally be used" if people wish it. WRT your claim that the wording "legislate[s] personal preference", I, for one, am thinking only of our readers at large: if it's my personal preference to present the best formatting and linking environment for them, yep, I'm guilty as proven. I suspect that the "personal preferences" of the huge number of people forming a consensus here also place the needs of our IP readers uppermost. (I don't doubt that the opposition of such a skilled editor as you is well-intentioned, however.) Tony (talk) 05:58, 17 August 2008 (UTC)[reply]
Strongly support the change (though perhaps with additional information for the uninitiated to explain why legacy breaches of the rule are to be widely found - although hopefully bots will soon be getting to work eliminating these). It is not personal preference - it reflects widespread consensus reached on the basis of very strong arguments. And "providing the facts neutrally" is not what MoS is about - it's here specifically to make recommendations in matters where consistency across WP is desirable.--Kotniski (talk) 07:05, 17 August 2008 (UTC)[reply]
I also support the change. Opposers say that we could improve auto-formatting to a system acceptable by all; what we should be asking, however, is "Do we need it?" If you approach it as if auto-formatting were suggested now for the first time, you'd see that its benefits would not justify the trouble of applying it. As a proposal, it would sink. Features in Wikipedia should have a good reason for being there—let us not allow inertia to dictate our actions. Waltham, The Duke of 10:22, 17 August 2008 (UTC)[reply]
Moreover, those with the intrest to have it improved have not the power and those with the power have not the intrest. JIMp talk·cont 11:39, 17 August 2008 (UTC)[reply]

Support It's time to rid WP of these links to nothing of worth. JIMp talk·cont 11:39, 17 August 2008 (UTC)[reply]

Support Lightmouse (talk) 11:50, 17 August 2008 (UTC)[reply]

  • Harmful, unless... As Tony and others well know, there are many ways to use markup other than wikilinking that allow dates to be auto-formatted. Confusing the two is a convenient simplification that is simply unwarranted. MOS should indicate that if an editor wishes to unwikilink dates, that editor should use appropriate markup, such as <span class="wpAutoDate">17 August 2008</span> to allow the date to be appropriately formatted for presentation to readers. This kind of markup is automatically generated by e.g. {{date}}, isn't it? How can there be consensus when this hasn't been discussed? (sdsds - talk) 19:41, 17 August 2008 (UTC)[reply]
The Date template documentation says "dates between 1901 and 1969 will be displayed incorrectly (see bugzilla:11686). " Therefore this template is unfit for use. --Gerry Ashton (talk) 20:02, 17 August 2008 (UTC)[reply]

Support, if editors haven't read the comprehensive discourse already taken place, maybe they should familiarize themselves with the discussions on this page as well as the archived material. This discussion has now moved along, autodate formatting offers few advantages to the vast majority of readers/users who use wikipedia. The proposal, immediately above, of using markup such as <span class="wpAutoDate">17 August 2008</span> would put the onus on editors removing wikilinks although the case was not made for why we are keeping them in the first place. No one is advocating removal, merely deprecating the use of a format that is not that useful. FWiW, I would still favour the wikilinking of dates to lists such as the "year in film or "year in aviation." Bzuk (talk) 19:52, 17 August 2008 (UTC).[reply]

They are unlikely to familiarise themselves with any discussions unless there is a link to them. Would it be sufficient to take His Grace's list, make it into a subpage, and link to it, with a statement like Many editors find autoformatted date-links a net harm to Wikipedia. ? That's a deprecation. Septentrionalis PMAnderson 20:38, 17 August 2008 (UTC)[reply]
Bzuk: Piped links such as "year in film" and "year in baseball" are quite a separate issue from DA; this proposal will not impinge on them. Tony (talk) 00:10, 18 August 2008 (UTC)[reply]
On the contrary, it will affect them positively; not only will the removal of linked dates make the important links more visible, but the general de-linking will also expedite the removal of the remaining single-year links, and with it the confusion between them and the piped links you describe. Waltham, The Duke of 14:28, 18 August 2008 (UTC)[reply]
  • Strongly Oppose. Most of the arguments *against* auto-formatting are actually arguments against the blue-links, not the auto-formatting. As Sdsds says above, we're nowhere near consensus on changing the guideline. -- SatyrTN (talk / contribs) 22:02, 17 August 2008 (UTC)[reply]
Well, trivial blue links are bad, but there are at least six disadvantages, some of them highly significant. See His Grace's list. Tony (talk) 00:10, 18 August 2008 (UTC)[reply]
See also the talk page thereof for a few arguments against auto-formatting in general. Waltham, The Duke of 14:28, 18 August 2008 (UTC)[reply]
  • Oppose. The removal of auto-formatting is just inviting edit-wars. Bazj (talk) 23:29, 17 August 2008 (UTC)[reply]
Bazj: Can you point to a single instance of edit warring over date formats, even though autoformatting has been removed from many articles? Please provide a link to these instances here. Just as for the two basic varieties of spelling, WP has come to manage the selection and maintenance of one type very well indeed. What evidence do you have suggesting that the binary system for dates would spark wars whereas the binary system for spelling doesn't?Tony (talk) 00:02, 18 August 2008 (UTC)[reply]
Hasn't got there yet but the edits on the 14th & 16th Aug on Pope Leo XIII were heading that way. Autoformat at least lets User:Thomaq and User:Skyring see what they want to see. Bazj (talk) 11:10, 18 August 2008 (UTC)[reply]
Right, thank you for that, Bazj. I see that this article was a bit of a mess long before this debate ensued, with multiple MOSNUM breaches (mixture of US/international, autoformatted / not autoformatted, unspaced em dash in the dob/dod range, if you please, and wrong nav-box ranges at the bottom, still). And I'm afraid that in your attempts to reinstate autoformatting, you've got the syntax all wrong (e.g., 31 December, 1903). We go back to the first 12 months of the article history and see that there was a sole US-formatted date; I think that wins out, since any preference in Italy at that time seems irrelevant now. Either way, it should have been worked out at talk according to our long-established guideline "In the early stages of writing an article, the date format chosen by the first major contributor to the article should be used." I'll deal with all of these issues now, retaining DA for the moment, in US format. However, your comment "Autoformat at least lets [the two editors involved to] see what they want to see" I believe misses the entire point: our readers see the raw format, and it is they who matter, not what these two editors see! Tony (talk) 11:54, 18 August 2008 (UTC)[reply]
For the last month I have created a number of new articles within two of the most "strictly-adhere-by-the-letter-of-the-law" project groups, WP:FILM and WP:AVIATION. First of all, in the nature of full disclosure,I am not a neophyte editor. However, the articles have been the subject of interest to other editors, both new and from the ranks of veterans. I did not detect any sign of edit warring over the format of "no autodate links", much the opposite, the two project groups accepted the format without any visible reaction. I posted extensively to both project forums, to find mild interest in the direction I was taking but no real opposition, either. FWiW, I believe it is time for a change, and the majority of editors will accept this format adjustment without any problems. Bzuk (talk) 00:45, 18 August 2008 (UTC).[reply]

Support. Autoformatting doesn’t benefit the vast majority of readers. There was simply never any proper justification for creating a tool where only registered editors can see the editorial effect so 99.9% of Wikipedia’s readership see only a default style that could have been set in fixed text. Further, using the tool introduces the disadvantage of generating links to random irrelevant trivia. Even though the tool is widely used, that’s no reason whatsoever MOSNUM can’t call for editors no longer *adding* them to new articles and for explicitly allowing editors to change from autoformat to fixed text. Further, bots can later be made to do that drudgery for us. Greg L (talk) 03:56, 18 August 2008 (UTC)[reply]

Support. I have yet to see any compelling reasons for auto-formatting. So a few users can avoid seeing "16 November 2003" in some articles and "November 16, 2003" in others? They (or rather, we) still are the exact same users who think there are no problems with seeing "colour" in some articles and "color" in others, so what harm could date format differences do? Among the drawbacks of auto-formatting, the most serious is the hiding of inconsistencies from precisely those who would be most likely to fix them. My suggestion is to apply WP:ENGVAR to date formats while wikilinking only extremely relevant dates, and then the whole date (November 16, 2003), which would make for meaningful backlinks. -- Jao (talk) 13:04, 18 August 2008 (UTC)[reply]

Comment As I pointed out before without autoformatting there is no longer a reason, other than personal preference, why other alternative date styles can not be used within an article, providing of course they are used consistently within the article. So we can look forward to articles with "16th November 2003" in them. --Philip Baird Shearer (talk) 15:57, 18 August 2008 (UTC)[reply]
I don't see any reason why deprecating linking/autoformatting need affect what date formats are approved in the MoS.--Kotniski (talk) 16:49, 18 August 2008 (UTC)[reply]

Support - Agree completely with the rationale of Jao above, and others. There are no compelling reasons to continue autoformatting, to my knowledge. —Mattisse (Talk) 15:27, 18 August 2008 (UTC)[reply]

Support - Tony's proposal (with the "should" modification) states it clearly and benefits the greatest number of readers. If and when the developers decide to introduce coding to allow everyone to select a preference and to display so automatically, we can get by without. Askari Mark (Talk) 18:52, 18 August 2008 (UTC)[reply]

Proposal by Seddon

Having read through the various discussions I would like to offer a middle ground outcome when it comes to auto formatting. There is still the option of improving the auto formatting methods but this is a an option until that is worked upon. This may suffice until that time.

  • When using May 15 or 15 May no wiki linking is to be used as common sense prevails here that no matter where in the world you are you should be able to understand the date.
  • When using May 15, 2008 or 15 May, 2008 and other variations based on the same style for the same reasons as above, no wiki linking should be used.
  • When using ISO or US date standards in the format 2008-02-04 and 2008-04-02 and other integers between 1-12 used in this format, wiki linking should be used due to the easy confusion. For those who are not logged in, the link to the date will remain allowing this to be clarified.

This removes redundent wikilinking where it is not necessary but allows clarification where it is obviously needed. Seddσn talk Editor Review 01:51, 18 August 2008 (UTC)[reply]

I don't understand the third bullet. Are you suggest there is any standard anywhere in which the first group is the year and the last group is the month? I've never heard of such a standard. Are you suggesting there is a difference between the US and ISO interpretation of "2008-02-04"? I live in the US, and don't know of any difference in interpretation (except that some Americans might not know what to make of it).
Also, in the second bullet, I would not use a comma in "15 May, 2008" --Gerry Ashton (talk) 03:06, 18 August 2008 (UTC)[reply]
I don't think i quite understand your question in regards to the 3rd bullet. Could you clarify for me? Its a little late so my brain isn't working. Seddσn talk Editor Review 04:14, 18 August 2008 (UTC)[reply]
I understand your question now :) I also believe a mistake was made on my part as you have pointed out. There is no standard but i feel misinterpretation is possible. Seddσn talk Editor Review 05:03, 18 August 2008 (UTC)[reply]
The third bullet makes no sense to me at all. Also, please explain it from scratch. Please say what you think each example means, giving a spelled-out month. --Gerry Ashton (talk) 04:33, 18 August 2008 (UTC)[reply]
ISO dating should simply not even be in the question. Your first statements concur with others on the unnecessary need for autodate linking, leave it at that. FWiW, there is enough evidence that ISO dates cause too much confusion. Bzuk (talk) 05:07, 18 August 2008 (UTC).[reply]
So prehaps converting all ISO dates to some other format by the whatever it gets changed to first method, then leaving all other dates without formatting? Seddσn talk Editor Review 05:49, 18 August 2008 (UTC)[reply]


  • Support - This proposal as written is clear and understandable, and should be implemented, especially as regards ISO dates. That is, MoS should discourage editors from removing wikilinking around ISO dates. Moreover, per enwiki best practices, if the dates in an article (or table, or whatever) are already in ISO form, other editors should make their edits conform. (sdsds - talk) 03:46, 19 August 2008 (UTC)[reply]
  • Oppose - The date articles (for example, 18 August) are often very badly referenced; we should try to pretend they don't exist and avoid linking to them as much as possible. --Gerry Ashton (talk) 03:54, 19 August 2008 (UTC)[reply]
  • Oppose , it again brings in the conundrum of ISO dating. FWiW Bzuk (talk) 12:18, 19 August 2008 (UTC).[reply]
Basically, little or no support for this proposal, but moving it here to keep up the continuity of the discussion. FWiW [[[User:Bzuk|Bzuk]] (talk) 12:18, 19 August 2008 (UTC)).[reply]
  • Comment. For those who oppose autoformatting of ISO dates (or ISO dates altogether): how would you execute this edit? I believe it is warranted; it replaces a non-standard date format with a standard one. Automatically, with a (reasonably simple) regex. (Done through wikEd, incidentally.) I could have omitted the wiki links, but what purpose would that serve? In this way, editors can at least see their preferred date format, while the non-editors will see wikilinked ISO format, which is not a big problem. So, how would you do it? I'm interested. GregorB (talk) 12:48, 19 August 2008 (UTC)[reply]
Perhaps you have not seen the comments on this page about the confusion as to ISO dating. Those unfamiliar with the format will not be able to understand the sequence of mm/dd or dd/mm while the vast majority (one editor has estimated it at over 98% of Wikipedia users) do not have date preferences set on their browsers. What the autoformat date linking does, is accomodate the tiny proportion of experienced editors, but for the vast unwashed, it produces an undecipherable blob of numbers, or a blue link that gets them to date articles that often have no relation to the article context. FWiW, the entry that was provided as an example could have been written out in "clear" rather than ISO, sure it shows up properly on my browser but it won't on the typical user's browser who will shake their heads and wonder what is that? Bzuk (talk) 13:03, 19 August 2008 (UTC).[reply]
Once ISO dates are wikilinked, there is no confusion (i.e. the date is not ambiguous), which is true for both editors and non-editors. Other things being equal, marginally useful links are a small price to pay. You did not say what would you do instead. Leave it as it is? "01-02-2007" - that's a non-standard, ambiguous date. In this particular case it's February 1, 2007 - granted, this is the best solution. but I don't have a magic wand to change it, and I guess I'm not masochistic enough to do it by hand, introducing errors in the process. What to do with existing digits-only dates, ISO-style and non-standard ones? My position is that in these particular cases wikilinked ISO is the best temporary solution. GregorB (talk) 13:24, 19 August 2008 (UTC)[reply]
I did mention that I would have formatted the note in "clear" which is to say, written out as 1 February 2007. BTW, to someone unfamiliar with the format, reading "01-02-2007", is it "February 1, 2007" or "2 January, '07" and as a Polish editor pointed out in the WP"AVIATION PROJECT group as to the uncertain nature of determing the date, why have it all, and the entire project group now deprecates ISO dating. FWiW, digit only dates are very rare in English prose and look decidedly odd in Wiki text. At this point, wikilinking all dates into ISO would be as much a problem as simply writing out the dates in the first place, as to make the wikilinking work, all users would have to be reading the format accurately by having their preferences set. I'm not even going to bring up the differences in date format between regions. Bzuk (talk) 13:44, 19 August 2008 (UTC).[reply]
Yes, I'd write it in clear too, but as I said, I don't have a magic wand... I did not say that digit-only dates are not rare in English prose (they are) - they are not rare in Wikipedia articles, unfortunately. To summarize my point: 1) "clear" dates are better than 2) wikilinked ISO dates, which are in turn better then 3) non-wikilinked ISO dates, which are in turn better than 4) non-standard gunk (e.g. Kazushi_Sakuraba#Mixed_martial_arts_record). It's difficult to convert #4 to #1, but it should be reasonably easy to convert it to #2, with at least some benefit. GregorB (talk) 13:59, 19 August 2008 (UTC)[reply]
I would write your analysis as: 1) "clear" dates are better, use them. 2) See #1. There is no large-scale advantage to using a date system that the majority of users will not find as a benefit. Remember we are not writing for ourselves, and if readers do not use or need autoformat date linking, then we should not be using it. Bzuk (talk) 14:15, 19 August 2008 (UTC).[reply]
I have a feeling that we didn't understand each other. I got it, "clear" dates are the best, but are you actually volunteering to fix Kazushi_Sakuraba#Mixed_martial_arts_record with "clear" dates? I guess you're not, and I'm not volunteering either. Saying "don't use ISO for new stuff" is fine, but what about the old non-standard stuff? If the choice is leaving it as it is or converting it to wikilinked ISO - and let's face it, it is currently the only reasonable choice for countless existing tables in Wikipedia articles - then I'd opt for the latter. GregorB (talk) 14:48, 19 August 2008 (UTC)[reply]
Actually, I am at work right now in rewriting all dates in Wikipedia to a consistent style. I will get back to you in 20 years or so. No, of course, it's illogical to try to change everything that is in place but an effort to use common sense protocols will make a difference for the future. What is being advocated here is the deprecation of autodate linking as it is of limited (or dubious) benefit and a better system already exists. FWiW Bzuk (talk) 14:54, 19 August 2008 (UTC).[reply]

Oppose: If ISO dates are ambiguous, there's a better solution than linking: don't use them. There are only two advantages of ISO dates I can think of.

  1. They are short and of a standard length. With ordinary dates, however, if instead we abbreviate the month name to three letters, it's not much longer and a leading zero can be added where necessary to standardise the length.
  2. They sort chronologically. The only way to make use of this on WP is in a sort table. There are ways to get ordinary dates sorted correctly.

So don't link ISO dates, better just avoiding them. JIMp talk·cont 15:43, 19 August 2008 (UTC)[reply]

Datestyle citation template proposal

Following MOS decission that linking dates not automatically the prefered approach, discussion had at the Cite XXX family of templates about removing autowikilinking, but allowing the option of a per-article only-if-a-consensus basis of selecting US or International style of dates approapriate for article topic and so make references use a consistant style of dates as appears in the actual text of an article. Discussion centred on Template talk:Cite web to add a datestyle parameter, but with plan to then role-out across the citation templates.

First attempt had to be nearly instantly reverted, as others not using the templates as we (i.e. largely myself) had appreciated and actual implementation proved not quite what others had expected. So after some very helpful discussions and a number of alternative suggestions (and large number of examples set out), I think the proposal is ready for re-implementation. However we lack a breadth of other editors' input, so seems sensible for me to post a heads-up here, as the cite templates clearly must be subserviant to MOSDATE :-)

As a few quick sandbox examples for an updated cite web:

With current default with no datestyle set
{{User:davidruben/sandbox4|author=Author |title=Title |url=http://example.org |date=August 24, 2007 |publication=Pub |accessdate=2008-08-18 |datestyle=}}

Author (August 24, 2007). "Title". Retrieved on 2008-08-18.

Where datestyle=mdy
{{User:davidruben/sandbox4|author=Author |title=Title |url=http://example.org |date=August 24, 2007 |publication=Pub |accessdate=2008-08-18 |datestyle=mdy}}

Author (August 24, 2007). "Title". Retrieved on August 18, 2008.

Where datestyle=dmy
{{User:davidruben/sandbox4|author=Author |title=Title |url=http://example.org |date=August 24, 2007 |publication=Pub |accessdate=2008-08-18 |datestyle=dmy}}

Author (24 August 2007). "Title". Retrieved on 18 August 2008.

see Template talk:Cite web#Review of current and sandbox coding - examples and now Template talk:Cite web#Proposal to go #2 - thank you David Ruben Talk 23:14, 18 August 2008 (UTC)[reply]

David, thanks heaps for your work on this. It looks good, but only as far as my untrained eyes can see. I do wish we could drop the "on", which in a list of many is quite unnecessary. I see a lot of non-citation refs that have no "on". Tony (talk) 00:01, 19 August 2008 (UTC)[reply]
  • Thats all well and good for Cite web, since the publication date and especially the access date are very likely to be in the Gregorian calendar. It is not acceptable for Cite book, since a fair number of books will have publication dates before the Gregorian calendar was adopted. I believe your code should reject dates in the YYYY-MM-DD format prior to 14 September 1752, and require that any such date be in a format in which the month is written out in letters. --Gerry Ashton (talk) 00:14, 19 August 2008 (UTC)[reply]
    Sorry not an issue can address for time being as mediawiki can not format (using #time) dates outside of range 1970-2038. So for all dates outside of this range, all that any template can currently do is to leave the input unaltered. Hence we can process "|date=1984-10-24 |datestyle=dmy" as 24 October 1984 but for "|date=1884-10-24 |datestyle=dmy" just as 24 October 1884 and likewise if "|date=24 August 1884 |datestyle=dmy" this must be just shown "as is" i.e. as 24 August 1884, or even if an editor enters "|date=uncertain but after 1792 |datestyle=dmy" as uncertain but after 1792. David Ruben Talk 03:42, 19 August 2008 (UTC)[reply]
    So if 'datestyle' parameter was introduced at {{cite book}}, then for now the 'date' parameter will still be entered by editors in the suitable format for the article (US or International) as they currently do, and whether or not 'datestyle' parameter is set will make no difference if the date is before 1970 (hence "|date=12 January 1624 |datestyle=dmy" or "|date=January 12, 1624 |datestyle=dmy"). But {{cite book}}'s instructions do allow for 'date' to be entered in ISO format and so where this might be after 1970, then at least 'datestyle' might show in a style consistant to dates within the article text and with other references that might use {{cite web}} or perhaps {{cite journal}} etc. (hence "...<ref>{{cite book....|date=1981-12-20|datestyle=dmy}}</ref>....<ref>{{cite web ...|date=2008-07-26 |accessdate=2008-08-18 |datestyle=dmy}}</ref>" migh appear in a more uniform manner). If at some future time mediawiki gets improved, then dates within cite book that predate 1970 might be also be displayed in a fixed consistant style as set primarily by user preferences (if set) or else as a default style set by the article's editors. For now I agree cite book for older publications wont appear any different with 'datestyle' enabled, but it may at least nudge towards greater consistancy throughout an article and across different cite XXX templates appearing within an article. David Ruben Talk 04:02, 19 August 2008 (UTC)[reply]
  • David, consider also a template that is not in the American Psychological Association (APA) style, but uses the Modern Language Association (MLA) style widely used in referencing works in the social sciences. The style consists of: Author (last name, first name). Title. Place of publishing: Publisher, date. Or failing that, at least a Harvard style template of Author (last name only) date, page. With these templates we are perpetuating the American Psychological Association myth of most-in-use. As for the need for citation templates, a great number of editors do not favour their use, and if anything, an effort to completely discard them would not be out of place. FWiW, I would support a outright deprecating of citation templates as they represent the worst of the "garbage in, garbage out" axiom. Bzuk (talk) 00:19, 19 August 2008 (UTC).[reply]
    Citation templates are of course optional, users are equally justified in choosing to manually mark-up references. The proposed 'datestyle' parameter discussion therefore only applies where an editor is choosing to use a citation template and aims to offer greater flexibility for them. That said, in biomedical articles where I mostly contribute, the use of PubMed and User:Diberri's markup generator tool are extremely useful. Citation templates have, IMHO, two major advantages, firstly the ease of initial markup creation (using automated tools described) and secondly, as you point out, if we could all agree to change citation formats (dropping for example the "on" in "accessdate" parameters, or deciding that 'author' or perhaps the 'title' should be in italics) then a simple template tweak takes care of this for us. However, as I say, using a citation tenplate is optional, and the 'datestyle' is just an attempt to help give greater flexibility for editors who elect to use the templates (a mediawiki feature to set a per-article variable that might be read and used by all templates appearing in the article would be a simpler option, but that is just mediawiki wishful thinking for now).David Ruben Talk 03:42, 19 August 2008 (UTC)[reply]
    Bzuk, it's the American Psychological Association, not Psychiatric; I meant to point this out before. I HATE their reference formatting with a vengeance. It hasn't changed in a long time, and contains illogical quirks and lots of redundant punctuation. Moreover, they make packets of money by changing a nut and a bolt in their manual and forcing all of the institutions to buy their new edition every few years. Not happy.
    More generally, I remain to be convinced that any citation template is superior to plain old manual WYKIWYG: What You Key in Is What You Get. The great advantage is local editor control and stability (whereas templates can suddenly change remotely, in the shadows. Tony (talk) 07:55, 19 August 2008 (UTC)[reply]
Tony1, thanks for the correction, the Psychological typo may have been inadvertent or as a subliminal aspect of my bias. I know that the dominance of the APA style dates back from my University days when professors literally enforced the style on legions of unsuspecting students. At the time, the MLA guide was prevalent but as a number of profs explained it, they were tired of having to explain the format and APA was so much easier. BUT, the overall question of citation templates remains, what they were there for in Wickywacky land was as an aid, not as the "be all and end all" that some editors have claimed. FWiW Bzuk (talk) 12:14, 19 August 2008 (UTC).[reply]
Well, I flatly declined my psychology supervisor's advice to toe the line with APA; my primary supervisor was in music, so that gave me a freer reign. I have no reason to disbelieve the explanation I've heard somewhere recently that citation templates were originally devised for newbies, and for WPians who weren't used to the demans of research references. My line is that compared with learning how to write prose, choosing a (manual) format for references and applying it consistently is a doddle; in fact, the relatively clerical task of checking through a manually constructed reference list is a good sop to the intensity of writing article prose. Tony (talk) 13:07, 19 August 2008 (UTC)[reply]
And as SandyGeorgia offered in a previous statement, one other consideration for "trumpeting" citation templates was that it would be a time-saver, which she concluded was not the case. In trying out the citation templates when I first encountered the Wiki world, I found them not only cumbersome, but rife with "bugs" that made them less than useful. I agree with you, the cite templates are not "cost effective" and their use should be more than entirely optional, but that's another story... FWiW Bzuk (talk) 13:16, 19 August 2008 (UTC).[reply]

Date linking: User:Tony1

[[::User:Tony1|Tony1]] ([[::User talk:Tony1|talk]] · [[::Special:Contributions/Tony1|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)[reply]

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)[reply]
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)[reply]
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)[reply]
  • “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)[reply]
  1. ^ a b Siborne, pp. 775,776
  2. ^ a b Siborne, p. 776