Misplaced Pages

Revision as of 19:03, 24 November 2008

Manual of Style

This page falls within the scope of the Misplaced Pages:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Misplaced Pages Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Misplaced Pages's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Misplaced Pages policies of Misplaced Pages's policy and guideline documents is available, offering valuable insights and recommendations.

Archives

General 1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161 Binary prefixes B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16, B17 Years and dates D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14 See also Misplaced Pages:WikiProject Dates Misplaced Pages talk:Date debate Misplaced Pages talk:Naming conventions (calendar dates) Misplaced Pages talk:Timeline standards Misplaced Pages:Measurements Debate Misplaced Pages talk:Manual of Style (dates and numbers)/Date autoformatting Complete rewrite of Units of Measurements (June 2008) Dec. 2008 RfC on Date linking/autoformatting (three proposals) Dec. 2008 RfC on Date linking/autoformatting (detailed)

This page has archives. Sections older than 5 days may be automatically archived by Lowercase sigmabot III.

Knots

The current wording of the MOS is as follows:

Use kn to abbreviate knot rather than kt (could be confused with kilotonne) or KN (could be confused with kilonewton).

I propose a new wording.

Use knot rather than kt, KT, kn or KN. The abbreviated forms are either ambiguous or opaque or both.

This issue has been discussed on User talk:Lightmouse at various times. (Lightmouse runs a bot that does mass edits.) The most recent discussion can be found at: User talk:Lightmouse#Knots. In summary, people like knots because they are clear. kn and KN are not generally used, and are therefore opaque. The traditional abbreviation kt is still widely used, but might be ambiguous. See Federation of American Scientists Military Acronyms, Initialisms, and Abbreviations--Toddy1 (talk) 08:58, 16 November 2008 (UTC)

I agree that what is there should be removed, but not with the solution. Let's just use the standard "kt" in contexts where that is used; perhaps in some contexts kn would be acceptable too; but stick to the lowercase versions. There is no serious ambiguity; nobody is likely to mistake a speed unit for a mass unit in the first case. Furthermore, we should never be using "kt" ALONE for kilotonne anyway; I never see anybody using that for the mass units, and the "tonne" is only acceptable for use with the international system of units as a unit of mass. Not as a unit of force, and not as a unit of energy. In fact, the term "kilotonne" is almost exclusively used in the latter context, as some kind of unit of energy. In those cases, we should identify it specifically, as a "kilotonne of TNT equivalent" or a "kilotonne of coal equivalent" or whatever. Furthermore, nobody should be using either "KN" or "kn" for kilonewtons, either; their symbol is "kN".

Note that all ambiguity will probably ever be eliminated. In fact, we have an SI unit and another unit still acceptable for use with SI which still share the same symbol: the symbol "rad' can mean either radians or rads, for example.

Use some common sense, of course; spell it out in cases where someone really might not know what it means, but there is no real need to do so in listing the cruising speed of a battleship; people will recognize either "kn" or "kt" as a symbol for knots in that context. All we should really do is to specify that, as we usually do in other contexts, we are using symbols rather than abbreviations. That's a distinction metrologists like to use when as a shorthand for the fact that symbols generally have most or all of these properties: They are case-sensitive, they remain unchanged in the plural (that's the one we should emphasize, that "kts" or "kns" are unacceptable), they are not italized even if surrounding text is, they can be used in non–Roman alphabet languages, they should be used only with numerals rather than spelled-out numbers, etc. Gene Nygaard (talk) 13:52, 16 November 2008 (UTC)

{{Convert}} only accepts kn or kt as input, but only produces kn as output. Naturally any conversion template will require unique abbreviations for input units. Although knot could be spelled out as a template input and abbreviated as an output, templates don't understand context and can't intelligently choose between kt and kn. --Gerry Ashton (talk) 15:15, 16 November 2008 (UTC) Revised 17:25 UTC.

Not true. The convert template accepts knot. {{convert|13.5|knot|km/h|1}} produces 13.5 knots (25.0 km/h)--Toddy1 (talk) 17:05, 16 November 2008 (UTC)

I meant it only accepts the abbreviation kn, but it turns out I was wrong, kt can be used as input, but not output. With your example, but giving the SI unit first, we get the following results:

• {{convert|25.0|km/h|knot|1}} displays as 25.0 kilometres per hour (13.5 kn)
• {{convert|25.0|km/h|kn|1}} displays as 25.0 kilometres per hour (13.5 kn)
• {{convert|25.0|km/h|kt|1}} displays as 25.0 kilometres per hour ()

--Gerry Ashton (talk) 17:31, 16 November 2008 (UTC) Fixed as suggested by Gene Nygaard 18 November 2008 22:34 UTC.

You overlooked

• {{convert|37|lb|kn}} displays as 37 pounds ()
• {{convert|37|lb|kt}} displays as 37 pounds (1.7×10 kt)

Gene Nygaard (talk) 20:55, 18 November 2008 (UTC)

When I just did this, I wondered why Gerry Ashton didn't get similar results. But he forgot to change the parts outside the nowiki to be the same as what is inside. His results should have been like this:

• {{convert|25.0|km/h|knot|1}} displays as 25.0 kilometres per hour (13.5 kn)
• {{convert|25.0|km/h|kn|1}} displays as 25.0 kilometres per hour (13.5 kn)
• {{convert|25.0|km/h|kt|1}} displays as 25.0 kilometres per hour ()

As it was, he was showing us the same one with the "knot" parameter three times. Likely just an oversight, using copy and paste and forgetting to modify both parts, so he didn't get the error message on the last one. Gene Nygaard (talk) 21:06, 18 November 2008 (UTC)

• I don’t know what the maritime-wide practice is regarding abbreviating nautical mile per hour. Sometimes there will be disciplines that use terminology and symbols that mean a different thing in other disciplines. Sometimes we can’t have project-wide consistency in units of measure. But we certainly should have consistency within a particular discipline and it is extremely  important that we follow what current literature says on the subject. If there is a particular most-common practice in the nautical/maritime world, then we should simply follow that practice so our readers can be properly conversant with mariners and others in the field. It is not our job to be advancing new proposals on abbreviations that might be used here. Just look to current literature. Conversion templates should also reflect what is the most common practice in the field. Greg L (talk) 23:13, 16 November 2008 (UTC)

Even "maritime-wide" is not determinative of anything. These units are also used in other context, most notably in aeronautics and in meteorology. But in almost all contexts, I'd say that "kt" is more common than "kn", but neither of them is so overwhelming as to preclude us from choosing to use one or the other in any particular context. And no, we don't necessarily need to look at current literature, and give that more importance in making our choice than for example what the experts in the field of metrology might use or recommend. Good heavens, that can often be a dumb idea. If we went by current literature, we use "ft/lbs" for automobile torque in foot-pounds force, even though there isn't any division in the units and therefore no good reason to make it look like there is with a slash, and even though symbols should remain unchanged in the plural, and it is indeed quite reasonable to make a choice to use symbols in that manner. Gene Nygaard (talk) 00:47, 17 November 2008 (UTC)

• Gene, you can do better than blow an example like ft/lbs out of your butt. There is a perfectly good SI-compliant measure of torque (N-m) that should generally go as the primary unit of measure. However, if one was talking to an American audience on a subject of an American car and were talking about torquing lug nuts, on, then one would indeed use ft/lbs.

  In this case however, we’re talking about aviation and maritime practices. We can’t have Misplaced Pages look like our editors have once again donned our Spock ears and run off to a Star Trek convention by trying to invent some new abbreviation for nautical mile per hour if (that’s a big IF), the vast majority of authoritative sources make it abundantly clear that such disciplines already have a standard they abide by. Your rah-rah promote-the-SI tact is tiresome. If aviators are used to seeing “wind at 23 kts”, then that’s what we should do here on not have some sort of “meters per second” crap that you might push. Greg L (talk) 01:52, 17 November 2008 (UTC)

No, we should generally be using the original measurement as the "primary" measurement. No no, "ft/lbs" should never be acceptable here. And there is absolutely no invention of a new abbreviation involved in this discussion. Let's just stick to the real issues, okay? Gene Nygaard (talk) 16:41, 18 November 2008 (UTC)

• P.S. having just posted the above, I looked and see that the U.S. Coast Guard uses “kt” as the symbol for nautical mile per hour. What do you wanna bet that this is the world-wide convention? We have absolutely no business pretending that Misplaced Pages is magically entitled to invent some sort of house convention that varies from this standard. The {{convert}} template needs to get fixed, pronto if it outputs “kn”. Greg L (talk) 23:21, 16 November 2008 (UTC)

• Actually, the link provided by Greg L is to the U.S. Naval Historical Center. On that same page, they have KC for kilocycle, but no KHz for kilohertz. The page also lists Kn(s) for knot(s). I'd say the page is both out of date and inconclusive. --Gerry Ashton (talk) 00:52, 17 November 2008 (UTC)

• The online version of Bowditch's American Practical Navigator on page 5 abbreviates knot as kn. --Gerry Ashton (talk) 00:59, 17 November 2008 (UTC)

• Gerry, you know as well as I do that we don’t standardize on something just because one can find some instances of it. We go with what the majority of reliable sources use. I don’t know with certainty what the true facts are as I am neither a mariner nor aviator. However, my brother is an aviator and I just spoke with him. The first thing off his lips was that for aviation, it is “kts”. And, in support of what he told me a few minutes ago, I note that NOAA’s Aviation Digital Data Service (ADDS) (that’s the Federal Government here) gives wind speed in “kts”.

  As for maritime use, Naval Maritime Forecast Center/Joint Typhoon Warning Center gives wind speeds in “kt”. I really don’t care what Uncle Fester’s almanac says.

  So maybe aviation articles should use “kts” and maybe maritime-related articles should use “kt”. Hopefully, editors with experience in both these fields will weigh in here and explain, with confidence, what the standard practices are in each field.

  And maybe, Misplaced Pages shouldn’t once again look like “mebibyte” foolishness. We have far too much input on MOSNUM from editors who have no expertise whatsoever in various disciplines but have tons of experience out-wikilawyering others here on WT:MOSNUM and who think that somehow makes them an expert in everything and somehow think they’ve found The Better Way To a Brighter Future©™®. No wonder “Follow Current Literature” has been so gutted out of MOSNUM, too many regulars here really think they really are changing the world, one idiotic template at a time. Greg L (talk) 01:34, 17 November 2008 (UTC)

• The American Practical Navigator (1995), generally called Bowditch, is not Uncle Fester's almanac. It is published by the United States National Ocean Service. My maritime knowledge is quite limited, but I've seen Bowditch mentioned favorably in several other publications. Its use of kn basically means Misplaced Pages should not settle on kt as the only option. --Gerry Ashton (talk) 03:09, 17 November 2008 (UTC)

• So… by your logic, even if most reliable sources used “kt” and “kts” in maritime and aeronautical purposes (still to be determined for certain), if some usage of “kn” can be found on this pale blue dot, then any editor should just go ahead and do whatever the wanna and templates masquerading as proper tools can use just one of the options—the one that appears to be least standard of all. Is that what you’re suggesting? If the U.S. Coast Guard and the U.S. Navy and the NOAA use kt and kts, that doesn’t hold much sway with you. You know what? I just realized I have a Garmin GPS 45 XL out in my car. The device is optimized for nautical purposes. I went out and got it and went to System Setup. Its symbol for nautical miles per hour is “kt”. You’re not persuaded yet, are you? Are your arguments not falsifiable? Please tell, is there any evidence that any human could present to you here that would cause you to change your mind(?) or is that utterly impossible? Greg L (talk) 04:45, 17 November 2008 (UTC)

In regards to the assertions on the NOAA position, please see their glossary (with attention to the irregular use of capitals), wherein we find these entries:

Knot
(abbrev. Kt) Unit of speed used in navigation, equal to 1 nautical mile (the length of 1 minute latitude) per hour or about 1.15 statute miles per hour, or 0.5 meters/sec).
KT
(Knot)- Unit of speed used in navigation, equal to 1 nautical mile (the length of 1 minute latitude) per hour or about 1.15 statue miles per hour, or 0.5 meters/sec).
KTS
Knots

Please note that much of NOAA's work is done by means of uppercase-only messages (e.g.), much like the military. Attaching great significance to their selection of capitals in a specific document instance would be a mistake unless they were explicitly discussing capitalization. General usage does indeed seem to be widely mixed between kt, KT, kn, KN, and even KTS, but knot is unambiguous and understood by anyone who understands the various abbreviations. Except under extreme space constraints, I hold that we should spell it out.-LeadSongDog (talk) 15:02, 17 November 2008 (UTC)

Yes, Greg, it is indeed perfectly legitimate for us to set house rules for our own use on Misplaced Pages;l and no, it isn't necessarily left to the whim of each editor. Nobody is inventing anything new here; there has been significant use of both "kt" and "kn" for this purpose. We can choose how we want our encyclopedia to look, however. We can try to give it some consistency, and that includes following more general rules such as using "symbols" rather than "abbreviations" for units of measure, and the associated notions about the distinction between the two. We can legitimately choose to standardize on "kn" as the MoS has, or to standardize on "kt", or to allow those two but no other symbols, or to say that it should always be spelled out.

The only real question is what we should do from among those options. Gene Nygaard (talk) 16:53, 17 November 2008 (UTC)

Note that Bowditch is written by the National Geospatial-Intelligence Agency (formerly the National Imagery and Mapping Agency) and sold by the National Ocean Service, which is an office within the very same NOAA mentioned by Greg L and LeadSongDog. It strikes me as being just as official and reliable as the other sources mentioned. At this point there is no documentary evidence that one abbreviation is overwhelmingly preferred to the other. The {{convert}} template is built on the premise that there is one correct abbreviation for any given unit, so it can't handle this situation well. --Gerry Ashton (talk) 16:35, 17 November 2008 (UTC)

See Bowditch's American Practical Navigator for some history on that document. The 1826 version is online here but it goes back much further. Suffice to say that it carries with it a great deal of tradition but perhaps is not the most current usage.LeadSongDog (talk) 17:20, 17 November 2008 (UTC)

That's just one of the problems of that overwhelmingly complicated black box {{convert}}, one with thousands of subtemplates and subpages, one which cannot possibly be edited by more than one person who thereby gains undue control over how Misplaced Pages looks. It can and does sometimes handle different options; a bigger problem is that no Misplaced Pages editor knows all the nuances necessary to use it properly. There is always, even when options are available, a built-in bias in favor of one of those options, a default option--for example, in favor of British spellings, requiring an explicit command to override that. Gene Nygaard (talk) 17:32, 17 November 2008 (UTC)

Just checked Webster's Third New International Dictionary (1986) ISBN 0877792011, and found that it shows (abbr: kt., kn., k.), but it also reveals a deeper problem in that knot represents two different distances. The famiiar usage of knot to mean nautical mile will not come as much surprise, but it also is used as 47 feet 3 inches in the original context of a knotted log line. Counting these knots for 28 seconds of ship motion is the equivalent of counting nautical miles for one hour. It may be that the correct thing for {{convert}} to do is simply return an error message so that editors hand convert. LeadSongDog (talk) 18:26, 17 November 2008 (UTC)

Now there's a red herring. Whether or not that 47¼ ft is a "meaning" of knot in the first place is probably debatable, but even if it is, it is never going to be used outside of the article knot (speed). And in any case, we are only going to be using symbols for cases in which it is a unit of measurement, and that isn't a unit of measurement (it might be a standard length, but it isn't used to express measurements of length). Webster's Third, of course, is basically a 1961 work, even if you newer version has an addenda in the front. Gene Nygaard (talk) 16:52, 18 November 2008 (UTC)

Yup, it's a fish. Sailors like fish :/) Since Bowditch was on the table, page 88 in the 1826 version speaks to the minor variations in the "length of a knot". LeadSongDog (talk) 18:58, 18 November 2008 (UTC)

First, the symptom. We have our nautical mile per hour article doing POV pushing with this:

The knot is a unit of speed equal to one nautical mile per hour. Its kn abbreviation is preferred by American and Canadian maritime authorities, the Institute of Electrical and Electronics Engineers, and the International Bureau of Weights and Measures, however, the kt (knot) and kts (knots) abbreviations also are used.

Then, the reality is that the vast  majority of aviators and sailors use kt or kts. NOAA, Navy, Coast Guard, FAA, the airspeed indicators on Cessna 172s (I’ve ridden in one many times), Garmin GPS devices, all say “kts” or “kt”. It’s “We’re seeing 25 kt winds from the SE” and “We were making 17 kts and keeping up with the carrier.” Go hop onto any airplane—commercial or GA—and try to find kn; you won’t find it. But compare this reality to what it says in the above quotebox. It quotes the IEEE recommendations and other “I-wish-it-would-be” sources like the BIPM. Who gives a damn? Is the quote “correct” because it implies that “oh, and you will also find some occasional usage of kt and kts if you look hard enough”? That is misleading to the point of being flat out incorrect. The real world doesn’t work that way and it’s obvious that any mariner or aviator who tried to edit any affected articles would be shouted down by Spock ear-wearing, SI nuts who can out-wikilawyer someone who actually knew what they were talking about. The last sentence in the above quotebox should read “however, in the real world, the abbreviations are kt (knot) and kts (knots).”

And finally, the greater problem: regulars to WT:MOSNUM having far  too much voice and giving them the ability to use procedural tools to get their way even though they don’t know anything about the subject at hand other than they can find an Uncle Festers Almanac that uses an obscure symbol (kn) that no one in the real world follows. Deep down, these idealists are thinking to themselves “that symbol is wrong; there are better ways and I can find some recommendations from some alphabet-soup organizations.” That attitude is bankrupt and naïve. We simply reflect the way the world works; not the way it ought to work. We need to be more cognizant of this phenomenon here on WT:MOSNUM and invite comment from experts in the effected fields before once again running off with “mebibyte” nonsense because the “the IEC says so” and its the New World Order and the path to the Future. No it isn’t. It makes Misplaced Pages look (once again) like we’re run by idealistic 8th graders and it does our readers a disservice.

Do I give a shit about nautical mile per hour? No. I didn’t touch it so I’m not responsible. I’m going to leave it just as it is in all it’s profoundly naïve ‘mebibyte’ glory. My axe to grind is with this god-damned venue that lets practices like this continue and doesn’t have the balls to get real. There. I said what I believe. So shoot me. Greg L (talk) 21:05, 17 November 2008 (UTC)

(ec)Sorry Greg, I'm fresh out of the slow bullets. Will a Thuggee noose do ;/?

Looking at the collection of airspeed indicators on commons, they all seem to spell out "knots", "neuds", or "KNOTS". The FAA "Instrument Flight Handbook" (2008) uses "KNOTS" on all the airspeed indicators shown and "knots" in the text, never abbreviated. But wtf does the FAA know about aviation? Really, what does the abbreviation do for WP? Just leave it as knots and be done.LeadSongDog (talk) 21:55, 17 November 2008 (UTC)

Let's not lose sight of the forest for the trees. Just include a conversion to m/s or km/h as appropriate, so that the 90% of the readers who don't have the foggiest idea that a "knot" really is will understand it, and according to our general rules, those knots should then be spelled out. The most common usage of a symbol, whether "kt" or "kn", would be in tables where it might be good to use symbols even if a conversion is included. Gene Nygaard (talk) 16:45, 18 November 2008 (UTC)

Lest my unstated corollary isn't clear, I'd bet there aren't a handful of cases in Misplaced Pages where some editor has bothered to convert some measurement in other units of speed to knots. We only really need to worry about conversions in one direction; the other way can be dealt with on a case by case basis. Gene Nygaard (talk) 16:58, 18 November 2008 (UTC)

• My problem is with a culture here that permits blatant POV-pushing as shown in the above quotebox, which is clearly misleading, isn’t it? Gotta go. Real world calls. Greg L (talk) 21:57, 17 November 2008 (UTC)

Gibibytes versus Gigabytes

Discussion moved to /IEC.

disputedtag

There should be a difference between {{underdiscussion|section}} and {{disputedtag}}. The documentation suggests that the difference is that the former is for the case where there is general agreement that the current wording has been agreed on, and the latter is for the contrary case. Not only is the interpretation under dispute, but there is a real dispute as to whether the deprecation of autolinking is a real consensus. Furthermore, WP:BRD suggest that {{disputedtag}} should remain while this discussion is proceding. — Arthur Rubin (talk) 13:55, 18 November 2008 (UTC)

Arthur, a style guide page is not your private playground in which you are free to vent your personal peeves. Dispute tags should be used only as a last resort. Tony (talk) 15:52, 18 November 2008 (UTC)

No, that would be full protection of the page Tony. Woody (talk) 15:55, 18 November 2008 (UTC)

There is a dispute over the section; several editors are actively engaging in it. For that matter, there is plainly a dispute over the tag - although if that continues, I will be tempted to submit it to WP:LAME. Septentrionalis PMAnderson 17:50, 18 November 2008 (UTC)

Actually, dispute tags seem to me to be the appropriate first step if there really is a dispute as to whether the text reflected consensus at the time it added. But it is pretty WP:LAME. — Arthur Rubin (talk) 19:43, 18 November 2008 (UTC)

<sarcasm>Anyone have a tag for the tag being in dispute? {{disputed disputedtag}}? </sarcasm> — Arthur Rubin (talk) 19:44, 18 November 2008 (UTC)

I'm thinking of changing that to {{underdiscussion disputedtag}} ;) Franamax (talk) 00:46, 19 November 2008 (UTC)

The first step (or joint first, at any rate) should be for someone to set out explicitly what claim they are making, with evidence, under a new section title. Then a tag can be added with a link to that section.--Kotniski (talk) 04:32, 19 November 2008 (UTC)

Yes, well now we've seen a totally unreasonable exercise of punitive power by this person who calls himself an admin—User talk:Rjd0060, abetted by his friend User talk:How do you turn this on#top—I'm frightened to make any edits to MOSNUM, for fear of having them labelled "slow" edit-warring. This is an appalling situation. Just what is the boundary between "slow" edit-warring and being bold? One of the key aspects of fascism is to impose arbitrary punishment on the populace; then everyone's too nervous to blink, and the costs of exercising power come down significantly. There was a chilling rationale to Stalin's random murders, for example. I'm not likening anyone's behaviour to that in extent, but in a key way, there's an apparent similarity. Tony (talk) 04:59, 19 November 2008 (UTC)

Please make sure you read the ANI thread on this, in which the actions of Rjd were rather inexcused (if you have not read this already). --MASEM 05:26, 19 November 2008 (UTC)

• Whatever happened to having a new wave of debate and voting to finally and definitively identify the true consensus? Not that doing so would necessarily settle anything, because if the consensus still calls for making those precious blue date links black, an endless stream of editors will come scurrying out from under the refrigerator to come here and complain about how they weren’t consulted. Oh… joy. Greg L (talk) 06:38, 19 November 2008 (UTC)

Well, Shereth was working on a RFC at User:Shereth/MOSNUM, but he doesn't seem to have been around the past few days, and in any case the proposed wording ended up being fundamentally criticised by people on all sides, so I suspect that might not be going anywhere. I think the next step should be a concrete proposal by someone who doesn't like the existing wording - either a reasoned claim that it was introduced without consensus (which ought to be a fairly short disucssion, with the facts on both sides being presented and a decision made by a disinterested user - a respected admin, preferably), or a proposal to change the wording (which would need to be argued through and gain consensus in the normal manner). In any case we should keep on topic - keeping the issue of the underlying guidance separate from the issues about bots and scripts, which are nothing to do with this page (in fact links themselves are primarily the topics of pages other than this one, although this talk page seems to have become the traditional interface for date warriors, so we may as well keep the discussion here).--Kotniski (talk) 09:24, 19 November 2008 (UTC)

• That's how it has always worked, so it's a good reason to do it that way. I'm fed up that the only thing which is changing is whether the tag says 'disputed' or 'under discussion', while the discussion is going around in circles. Let's archive the entire preceding discussion and start from scratch. Ohconfucius (talk) 09:40, 19 November 2008 (UTC)

Restarting the RFC

(See above section)

Given the issues on the current RFC draft, I propose a simpler version, that is a !voting straw poll, with five questions (will be reworded)

1. Should WP aim to have a date autoformatting system in place?
   • Sections for support, oppose, neutral
2. Should dates (including month-day, and full month-day-year dates) be linked to solely invoke WP's current version of date autoformatting, even where there is no other reason to linkignoring all other impacts of that result?
   • This would be a support, oppose, neutral outcome. A brief intro would have the general pros and cons on DA to avoid having to reiterate these in the discussion
3. How often should month-day dates be linked to the appropriate "month-day" articles?
   • This would have answers of "always", "sometimes", and "never".
4. How often should year-only dates be linked to the approach year articles?
   • This would have answers of "always", "sometimes", and "never".
5. When using "year in X" links, should this be in context ("blah in (1900 in x|1900)",), inline ("blah in 1900 (other x in 1900)"), or seealsos?
   • Answers of "context", "inline", "seealso", and neutral.

Getting the answers to these four will clearly tell us how DA is taken, and how the readers would want to see dates links. The date linking questions (last 3) will include points to the arguments already laid down (Greg L's sewer cover challenge, etc.) so that if people agree with that, they can simple !vote "per arguments given". Nothing about bots or all that. Once we have this, then it will be clear how to rewrite MOSNUM. --MASEM 13:27, 19 November 2008 (UTC)

OK, that looks more promising than the previous proposed RfC, but I still don't quite see it. Question 1 is out of our hands. Question 2 probably needs rewording, since I don't entirely understand it. The remaining questions are gross oversimplifications as they stand.--Kotniski (talk) 14:01, 19 November 2008 (UTC)

On Q1, it is not out of our hands in the sense that the devs will only be motivated to fix the problems with the current DA if there is sufficient demand for the feature - it makes no sense to correct if we decide not to use it. Q2 is trying to separate the problems of current DA (what anon/non-pref editors see) from the date linking/overlinking issue altogether, and yes, probably can be rewritten to reflect that - I just don't want to confluence the two different issues, and keep when dates are linked as a separate factor. The other questions are meant to be simple as we need to gauge where consensus is for when dates are to be linked - once that is know we can then craft the language needed for MOSNUM to reflect that as well as consider specific cases if the responses call for only partial date linking. --MASEM 14:09, 19 November 2008 (UTC)

Masem, I'm not being perverse or contrarian, but I don't understand any of the proposals. Can you reword them? (1) Logical issue, since we do have a DA system in place (it's just not used now). (2) I'm confused. (3 and 4) "How often"? (5) Needs rewording. Tony (talk) 14:19, 19 November 2008 (UTC)

Rewording is fine, whatever is needed to make these clearer - I'm trying to get the spirit of the questions down, but making sure to have the right questions that are direct as possible. specifically:

• On 1, the question is "should we be using "any" DA system on WP? Is it a crutch? Is it useful? That's a variable I see in the talk here. The question presumes that a DA "works perfectly" to meet all needs and avoids any issues.
• On 2, the question is specifically on the current DA system if we should keep using it or not, strictly focusing on what date output it produces in various cases (and the problems arising from that) and ignoring the fact that it produces links.
• For the "sometimes" responses of 3 and 4, the RFC would encourage uses to explain when in their responses.

If others are satisfied that there are no other questions, I'll draft the RFC up after a while, and then we can edit the exact nature of the questions to be clear as possible. This RFC should be designed to allow editors to quickly get to speed, supply responses, and go on with other things, which is why I have no qualms editing for clarity. --MASEM 14:39, 19 November 2008 (UTC)

I have copy-edited to invoke. I think I know what ignoring all other impacts of that result is intended to mean, but it will be clear as mud to anyone who hasn't followed this discussion. I would recommend solely and even where there is no other reason to link. Septentrionalis PMAnderson 17:40, 19 November 2008 (UTC)

That's what I mean but better - changed to make the convo easier. --MASEM 17:47, 19 November 2008 (UTC)

This looks great (especially with the proposed changes to question #1). I agree with Septentrionalis that more options might make sense for the final question, but in general this is a step in the right direction. —Locke Cole • t • c 19:18, 19 November 2008 (UTC)

• More options on the last question - that really may need discussion, not voting; for example, I would link to Sports in 1900 with that title, or ]. Septentrionalis PMAnderson 18:08, 19 November 2008 (UTC)

Based on the above input, I've created Misplaced Pages:Manual of Style (dates and numbers)/Date Linking RFC. Please feel free edit to improve the language or add more choices or whatever, but please do not use it yet to state your opinions on the matters at hand. If you have pre-loaded essays you'd like to link to, please do so (if they are to the contrary, .. uh, we'll figure a way to link them in) --MASEM 19:31, 19 November 2008 (UTC)

Thanks, Masem, for starting this. Should we add an additional question on whether dates should be mass-delinked if consensus says that datelinking should be deprecated? Some people may support changing the guideline without changing all the articles at once. Karanacs (talk) 19:46, 19 November 2008 (UTC)

I'd rather not ask that question - it's mixing up matters. The way I see this going forward is that we run the RFC, get the input, and then figure out what are the next steps. A bot may be necessary then, and if we've shown (for example) DA is depreciate with wide support and only a handful of dates should be linked, I see no reason why a date stripping bot would be problematic - Lightbot et al are only in the crosshairs because there are those that felt no consensus was present on the fundamental date linking issues to proceed forward. We'll have some consensus and thus the task at hand should go smoothly. --MASEM 20:08, 19 November 2008 (UTC)

• Tony, if I’m not around when voting starts, you may vote on my behalf. Let me know via e-mail and I’ll drop in to add the vote comments. Greg L (talk) 01:03, 20 November 2008 (UTC)

Thanks, Greg. Now, Masem, I'm still in the dark about No. 1. Do you mean "Should the current proscription on date autoformatting be removed from MOSNUM?"? Tony (talk) 06:34, 20 November 2008 (UTC)

No, whichever way #1 goes does not directly influence the MOS, it only should be reflected back to the devteam to let them know if they should actively pursue a different DA approach, or if their efforts will go to naught here (though if they still want to make it, hey, they can). Basically, almost to a point, this is essentially determining if we should close that one bugzilla bug about DA. The MOS, specifically removing the proscription on DA being deprecated, would only occur if point #2 shows consensus towards keeping the DA as it stands. Now, if #1 shows we want the devteam to provide a better DA, and they do come back and provide that, then we'll change it, but that's not a direct result of the RFC. Again, the removal of "DA is deprecated" will only occur in the immediate future if #2 shows support to keep it around. Hope that helps explain it (and feel free to rewrite as needed if this is confusing) --MASEM 06:53, 20 November 2008 (UTC)

smile: "if this is confusing" - yeah you bet it is confusing! edit: i've transplanted my comment to here. Sssoul (talk) 11:20, 20 November 2008 (UTC)

• One thing which gets mentioned but never has a proposed independent solution: DA was introduced to provide uniform formats via preferences; preferences are only available to registered editors; use of this preference (is claimed to make/makes) editors blind to format discrepancies within articles. I've never seen any actual stat's on how many editors have the pref turned on, nor on exactly how much impact that pref has on article quality, as opposed to laziness. It would be really great to see that claim substantiated ("editors turn date pref on and miss problems OMG") - but would another approach be to just turn date prefs off (as in, remove the clickbuttons from u-prefs)? That would de-link date-links from date-formats. Franamax (talk) 07:02, 20 November 2008 (UTC)

That option controls the display of time and date in article histories, watchlists, and other Misplaced Pages listings; it isn't just for autoformatting. --Ckatz_spy 07:09, 20 November 2008 (UTC)

Time to break that link then, isn't it? I've always made sure that the dtm's I see are as raw as possible. History and watchlists ("personal presentation of editing-relevant data") are one thing - but the notion that this would obscure our presentation to our readership is just intolerable. Editors have no privilege over anonymous readers, in fact they are one level below. That is the first link to sever. Franamax (talk) 08:02, 20 November 2008 (UTC)

It's hardly a "privilege", given that anyone can sign up; editors certainly aren't the only ones who have access. Furthermore, why is there so much disdain for the idea of interface customization? If it causes problems for IPs, we should be looking to improve their access to a feature, not stripping it away from everyone else. This is the 21st century, and every other level of technology is moving forward to make Internet access seamless and personalized. (Just look at operating systems, phones, music players, and so on.) --Ckatz_spy 08:19, 20 November 2008 (UTC)

No arguments, really. What I'm saying is that if registered editors can set a preference that makes them blind to article problems that our general readership (the great unwashed who only come here to learn something) will definitely see - that is the problem we should solve first. In this case, this is Tony's repeated assertion that date preferences keep our editors from seeing mismatched date formats in our articles and correcting them. I've seen no evidence this is true, beyond the bald assertion - and laziness is an equally valid explanation. Nevertheless, I'm quite willing to concede the point, in which case, let's turn off date formatting within articles so that particular point becomes moot.

And in general, if there is any little bitty thing that gives registered editors an edge over my grandma when it comes to just viewing an article - our general readership comes first and always, all they have to do is click once. You're right, it would be great to have datepref's autoset by the incoming IP address or by local cookies, but that's quite unlikely in the near future. (It's probably on the list, just after "finish the other stuff") In fact, that's one of the reasons I'm hesitant about mass stripping of date links altogether. I don't really buy the "sea-of-blue" argument against (people know what to expect when they click a date-link) and I'm concerned about all the loss of future potential of those existing links (the meta-data argument). As far as the parser goes, it's likely pretty darn easy to uncouple date prefs from the in-article presentation. That's the first place to start, since it also uncouples the various arguments here. Franamax (talk) 08:55, 20 November 2008 (UTC)

I agree with the wording of the draft and look forward to the vote. More should be done to encourage users to create accounts, but that's another discussion. Us defining one date format over the other defeats the purpose of the date preferences. By formatting the dates with links the system will honour user preferences. If that user doesn't have an account or preferences set then they'll see it however the editor formatted it. This way at least those with accounts see formatting according to their preferences. Otherwise NO ONE is likely to see the date in the way they're accustomed. I think it'd be fine to pick a specific format, such as U.S., i.e. MONTH and DAY, however do it with links to honour preferences. I'm not supporting U.S. format or another, but if one needs selected then by all means do so, but I'd specify in the MOS to do it with links, because again not doing so ensures that no one is satisfied. Nja247 (talk • contribs) 12:32, 20 November 2008 (UTC)

Why does the order of the day and the month matter? I am American, yet I can understand 12 July just as well as July 12. I don't see editors clamoring to autoformat words like honor (honour) or organize (organise) so that Americans can see their preferred spellings and everybody else in the world sees theirs. Dabomb87 (talk) 13:32, 20 November 2008 (UTC)

I'm sorry but arguments like 'it doesn't matter' are irrelevant especially when Misplaced Pages offers a date preference option. Surely it matters when people use dates like 3/11. It causes un-due confusion as some people see that as the 3rd of November versus the 11th of March. Editors may end up un-necessarily go through articles to 'fix' the date formats, whilst another may go back and fix them again. If the MOS says use U.S. formats fine, but do so in links that way preferences are honoured. It makes no sense to have the preference option only to overlook it. My question is how does it hurt for anons to see a date formatted inside links? Nja247 (talk • contribs) 13:51, 20 November 2008 (UTC)

The MOS says don't use dates like 3/11. Use 3 November or March 11. Jheald (talk) 14:19, 20 November 2008 (UTC)

True, but it goes on to say they may be used in tables. I understand this is a limited area, but confusion is still possible. Formatting them avoids the confusion per user preferences. Further, it avoids possible un-needed edits by users who prefer one style over another. I still haven't seen convincing arguments as to why linking is bad. Nja247 (talk • contribs) 14:45, 20 November 2008 (UTC)

We're not talking about dates like 3/11 here, that's irrelevant. All these are arguments that have been gone over and over and over. Editors are more likely to make mistakes if they have date preferences set (since they can't see what readers see), so serious editors should not set them, and are therefore deprived of the "benefit" of seeing dates the way they prefer them in watchlists etc. If you follow the strange logic that if we have something, we must find a way to make it useful, then you should certainly support removing the autoformatting links (or switching off autoformatting), so that all responsible editors can take "advantage" of the date preference option (I put "benefit" and "advantage" in quotes, since the actual benefit is negligible). Too many links hurt (or at least inconvenience) "anons" (99.99% of our readership) because it makes it more difficult for them to identify and follow the links that are likely to be relevant to their understanding of the topic (see WP:OVERLINK). Dabomb gets it exactly right - if anyone really cared about this sort of thing (as opposed to just opposing change in principle because it makes them feel uneasy) they would be - and would for a long time have been - making similar proposals about spelling and about words that have different meanings in US and UK English. As I keep saying, this whole discussion is motivated by people trying to find solutions to a complete non-problem.--Kotniski (talk) 14:30, 20 November 2008 (UTC)

That makes absolutely no sense to me, sorry. If the date is linked it'll appear to anons in exactly the format the editor made it (either DD MM or MM DD per MoS). The same is also true if it's not linked, i.e. it'll show up exactly as formatted whether linked or not to anons. The only difference in the former instance is that editor's with preferences set see the date how they prefer. I definitely require an example of how having it otherwise robs me of any benefit or advantage. (Note: I've received an example, though I believe non-lazy and careful editors will ensure article consistency and not overlook these things -- I do). Also I'd enjoy reading the details of whatever survey/report you're citing where anon's, et al, have complained that date links cause confusion. Nja247 (talk • contribs) 14:45, 20 November 2008 (UTC)

You've apparently missed the point about 99.99% of Misplaced Pages users not having preferences set. From their point of view, all that date linking does is make for a flood of meaningless links. It doesn't help at all, it just confuses our readership. --Pete (talk) 23:13, 20 November 2008 (UTC)

• Looks like it's time to make available the list of problems with DA, as put about for the past few months. Perhaps you missed this, Nja.

• (1) In-house only

• (a) It works only for registered (Wikipedian) users who have set their date preferences and are logged in.
• (b) To our readers out there, it displays all-too-common inconsistencies in raw formatting in bright-blue underlined text, yet conceals them from WPians who are logged in and have chosen preferences.

• (2) Avoids what are merely trivial differences

• (a) It is trivial whether the order is day–month or month–day. It is more trivial than color/colour and realise/realize, yet our consistency-within-article policy on spelling (WP:ENGVAR) has worked very well. English-speakers readily recognise both date formats; all dates after our signatures are international, and no one objects.

• (3) Colour-clutter: the bright-blue underlining of all dates

• (a) It dilutes the impact of high-value links.
• (b) It makes the text slightly harder to read.
• (c) It doesn't improve the appearance of the page.

• (4) Typos and misunderstood coding

• (a) There's a disappointing error-rate in keying in the auto-function; not bracketing the year, and enclosing the whole date in one set of brackets, are examples.
• (b) Once autoformatting is removed, mixtures of US and international formats are revealed in display mode, where they are much easier for WPians to pick up than in edit mode; so is the use of the wrong format in country-related articles.
• (c) Many WPians don't understand date-autoformatting—in particular, how it differs from ordinary linking; often it's applied simply because it's part of the furniture.

• (5) Edit-mode clutter

• (a) It's more work to enter an autoformatted date, and it doesn't make the edit-mode text any easier to read for subsequent editors.

• (6) Limited application

• (a) It's incompatible with date ranges ("January 3–9, 1998", or "3–9 January 1998", and "February–April 2006") and slashed dates ("the night of May 21/22", or "... 21/22 May").
• (b) By policy, we avoid date autoformatting in such places as quotations; the removal of autoformatting avoids this inconsistency.

Tony (talk) 15:01, 20 November 2008 (UTC)

Tony, is this in your userspace or essayified anywhere? It would be good to include a link to this in the RFC as to avoid having to rehash this points in discussion. --MASEM 15:07, 20 November 2008 (UTC)

Masem, it's all over the place. This might be useful, and contains the capped "disadvantages", but as you can imagine, it's completely POV: User:Tony1/Information_on_the_removal_of_DA. Tony (talk) 15:12, 20 November 2008 (UTC)

That's fine that it's POV - if you see the RFC, we are presenting the statement as to add the language "DA is deprecated for various reasons" to MOSNUM and asking people to support or oppose that statement. Your reasoning highlights most of the issues even if POV-ish, and makes complete sense since you're the largest proponent of removing DA. --MASEM 17:52, 20 November 2008 (UTC)

My advocacy has since been overtaken by the voices of many others. Tony (talk) 10:08, 22 November 2008 (UTC)

• Can we please keep points in discussions clear regarding whether they are about DA or DL? The Aug/Sep decision was made with most headings being about DL, and barely a mention of DA --JimWae (talk) 10:31, 22 November 2008 (UTC)

Time to vote on something

• KISS: Enough arguing about the shape of the negotiating table. Maybe we’re being overly ambitious by trying to agree upon the wording of too many points at once. How about we just vote on one point at a time (and keep it simple too). The wording of other questions will likely become clearer as we progress through this. How about this one:

Should “this date throughout history” articles such as April 1 be routinely linked to within articles?

Who’s up for this? Let’s settle something and move on. Greg L (talk) 02:43, 21 November 2008 (UTC)

• Don’t link (I’ll start the voting). Why? Because rambling lists of trivia throughout the ages, all pulled straight out of Professor Marvel’s crystal ball are very rarely germane and topical to the subject matter of our articles. Just like the sewer cover in the road outside of my house, none of this stuff is ever relevant. There are better ways to let readers know this stuff is available, as outlined at WP:Why dates should not be linked. Greg L (talk) 02:50, 21 November 2008 (UTC)

• • Since we are looking to evoke mechanisms to get as many eyes as possible onto the issue at hand, addressing issues one at a time would be slow and wasteful. The RFC as is now seems to be in shape to bring it to wide announcement in a few days barring any major objections. --MASEM 03:02, 21 November 2008 (UTC)

• Ha. Slower and more wasteful than all the monkeying around above?!? Not possible, Masem. All we have is a bunch of gaming and brinkmanship going on; nothing really productive. If you don’t want to vote, that is you’re right. In the mean time, my above proposal stays active and I encourage others to help finally put this one, drop-dead-simple issue to rest once and for all. Greg L (talk) 03:18, 21 November 2008 (UTC)

• The point of doing the RFC properly is to get consensus to put an end to all the issues that have been raised in the past month or so. Doing it this way will not achieve the same means; that's why the whole RFC process was put in place to begin with. --MASEM 03:28, 21 November 2008 (UTC)

• Very well. And this doesn’t prevent any of that. It allows people to (*shudder*) express their opinion. Do what you want, but stop pretending to dictate where, how, and when others may express their opinions here. I believe, this is where you shout “Greg L is asking others about their opinions on something! Shut him up. Shut him up!” Greg L (talk) 03:31, 21 November 2008 (UTC)

• I'm not trying to prevent anyone commenting. I do however want to make sure that a proper RFC is completed so that we aren't coming back here after a month of whatever decision is made with people saying "I don't like that!" and not having anything to point them to that said consensus at a wide scale was reached. Otherwise, you have a process that repeats over and over again. Go ahead and comment here, I absolutely can't stop you, but this issue needs a calm, rationale approach to resolve appropriately. --MASEM 03:41, 21 November 2008 (UTC)

(undent)"... not having anything to point them to that said consensus at a wide scale was reached." er ... is the RfC meant as a poll or as a consensus-reaching process? those are two different things, and i believe when you started the draft you were talking about a "straw poll" (or maybe that was Shereth, sorry); to me it's a major difference that needs to be kept in mind. a poll might show widespread disagreement, but that doesn't mean that no consensus can be reached; whether it's "wide-scale" or not depends on how many people stick around for that part. the RfC on birth/death-date links, for example: of course "there's no consensus", since it was treated merely as a poll; even the person who launched it ignored attempts to reach a consensus. obviously you can't make large numbers of poll "voters" stick around en masse for the consensus-forging part; only a few will stick around, and then people can later complain that whatever was decided wasn't a "community-wide consensus". which isn't the point, is it. Sssoul (talk) 09:36, 21 November 2008 (UTC)

• "I do however want to make sure that a proper RFC is completed so that we aren't coming back here after a month of whatever decision is made with people saying: 'I don't like that!' " Well, you are opening up a can of worms here - nothing, but nothing will prevent what you fear, because it has happened already, and there's every chance it will happen again. Whichever way this RfC goes, I am prepared to wager that the 'losing side' will mount an even more powerful 'I don't agree with it' campaign, so you had better be ready for that. Ohconfucius (talk) 15:08, 21 November 2008 (UTC)

• What Ohconfucius said. Greg L (talk) 15:22, 21 November 2008 (UTC)

• Conditional agreement that

1. This consensus is dependent on other consensus related to dates, so it might need to be revisted after the RfC
2. Provided that autoformatting is deprecated (which has been claimed, but not yet established), dates should not be routinely linked. This does not, however, necessarily discourage certain dates in an article being linked. If you want to extend "routinely" to "ever", this is a strong oppose.
3. As the term is "routinely", bots should not be used to unlink dates.
4. Even if agreed to, this would not reduce edit wars, because of the term "routinely".
5. Even if agreed to, this page doesn't have sufficient visibility, so that it would need to be revisited in the RfC.

— Arthur Rubin (talk) 15:45, 21 November 2008 (UTC)

(to Ohconfucius and Greg L) - Sure, no one can pretend that even if a thousand editors showed up to voice a clear consensus (more that 90% !votes in one director), that people will come back to challenge it again. However, compared to what can be shown now about consensus for removing date links, which is based on conversation limited to WT:MOSNUM and to the indirect fact that FAs and other articles have been stripped of dates without complaints, at least this provides a strong consensus that can be directly linked to, and those that disagree will have to realize what's been stated already. Of course, consensus can change, and maybe in a year we're revisiting this; that's better than having to argue the point month after month for the same period. It is, of course, expected, that those participating in the current discussion will accept the consensus, as this is a dispute resolution pathway and the RFC is aimed to mediate that. Those that refuse to accept the results if they clearly are against their opinion and still argue against it can be handled by other means (WQA, for example). --MASEM 16:13, 21 November 2008 (UTC)

I don't agree with that assertion. I suspect many of the editors who object to the removal of dates from FAs are willing to abide by the claimed consensus that dates are to be removed, or are objecting here (even though Tony claims the discussion is supposed to be in regard WP:CONTEXT). All that can be realistically said is that there's a weak consensus among MOSNUM regulars. — Arthur Rubin (talk) 17:29, 21 November 2008 (UTC)

My possition is that this !vote cannot establish a Misplaced Pages-wide consensus, while a formal RfC, properly advertised, can. It's not clear from the phrasing above rather you agree or disagree. — Arthur Rubin (talk) 17:30, 21 November 2008 (UTC)

I think you are agreeing - I'm hoping all those presently aware and that will be aware via the formal RFC notices will understand this should conclude the matter and should accept whatever outcome results. --MASEM 17:33, 21 November 2008 (UTC)

• All we can do is hold a big RfC, publicize it well, invite lots of comment, identify where the consensus is on various points, and align MOSNUM guidelines with that consensus. There certainly will be editors scurrying out from under the refrigerator a certain percentage of time when articles somewhere are affected. With 48,466,431 users, we’re just playing the odds. And if Lightbot is busy implementing (enforcing) MOSNUM guidelines, a small army of editors will come scurrying here. We will simply have to tell them “sorry, it’s been (thoroughly) discussed and you missed out, and here’s proof of those discussions and that the consensus is valid.” We had better do a good job of documenting this and ensuring we’ve done everything reasonably expected of us to be inclusive because there will always be editors who are more passionate than most who are willing to climb the Reichstag over the issue. (*sigh*) Greg L (talk) 23:05, 21 November 2008 (UTC)

• This wouldn't even be an issue if twelve editors hadn't decided they could decide for the rest of the community whether date autoformatting was good or bad. The arrogance there is just astonishing. Even something as simple and benign as semi-protection took something over one hundred editors supporting it to implement... (and that was in December of 2005; Misplaced Pages has obviously grown since then). —Locke Cole • t • c 01:07, 22 November 2008 (UTC)

• Back to what Kotniski and I were saying in the section above. The onus must be on those who object to the current wording to propose alternative wording for us to discuss on. As the RFC is only a request for comment, fellow editors should not treat this as the 'be all and end all'. Even if there is some consensus on the wider issues, the open-ended nature of some of the questions being asked (such as "when should dates be linked") and the range of acceptable answers will more or less guarantee that the outcome will be similarly open-ended. A proper discussion needs to be held on the exact wording of each outcome. Why doesn't someone just move to a wording when this is possible? To give an obvious example, in the 'Deprecating the current date autoformatting' section, we should move to a unambiguous proposal worded: "It is proposed that the the following text be deleted from the Linking and autoformatting of dates section of the guideline: "Autoformatting: Dates should not be linked purely for the purpose of autoformatting (even though in the past this was considered desirable)"Ohconfucius (talk) 22:45, 22 November 2008 (UTC)

This following comment and its discussion has been copied to Misplaced Pages talk:Manual of Style (dates and numbers)/Date Linking RFC please comment there.

As for Number 4 on the proposed RfC, I would note that WP:EGG advises to:

"void piping links from "year" to "year something" or "something year" (e.g., ]) in the main prose of an article in most cases. Use an explicit cross-reference, e.g., ''(see ])'', if it is appropriate to link a year to such an article at all. However, piped links may be useful:

• in places where compact presentation is important (some tables, infoboxes and lists); and
• in the main prose of articles in which such links are used heavily, as is often the case with sports biographies that link to numerous season articles."

I think these are pretty good guidelines for those type of date links that no one has disputed. I would suggest removing number four because it is not really at issue. Lightbot nor his script currently removes these type of links.--User:2008Olympian_chitchat 01:52, 22 November 2008 (UTC)

• I believe you mean #5 (Year in Field), which true, the linking MOS says to avoid hidden links, but this is not about just the piped version but any version of "year in field" links, which that MOS doesn't give the full answer to. Thus #5 seeks to get the clarity needed for that, which might result in rewording of that section there. --MASEM 12:51, 22 November 2008 (UTC)
  • Leave #5 out for now. This boxed quote is a reasonable interim rule, and is clearer than the question.
  • Alternatively, we can quote the boxed language, and ask if it should hold always, sometimes or never. Septentrionalis PMAnderson 16:16, 22 November 2008 (UTC)

This above comment and its discussion has been copied to Misplaced Pages talk:Manual of Style (dates and numbers)/Date Linking RFC please comment there.

Split proposal

I am proposing to split this MOS into two pages. One for the chronological items and one for the rest of the numbers (which possibly could include merging in the formula page mentioned at the top, but that is orthogonal discussion). The split makes sense as they really are two separate topics.

However, unlike the typical reasons for splitting an article, this one is not only an issue of space (though it is approaching 70KB/KiB) but of discussion of the article. Ignoring the political and religious discussions, there are a score or so editorial topics in Misplaced Pages that consensus has been difficult to reach even after years and years of discussion. Unfortunately, two of them are on this page:

• The IEC binary prefixes.
• Date Linking and automatic formatting.

These two discussions dominate the discussions so much and are responsible for so many edits that nothing else ever gets a chance to be discussed. Separating the pages should fix part of this.

So I propose that the Chronological items article to be split to Misplaced Pages:Manual of Style (time and dates) while renaming the main article Misplaced Pages:Manual of Style (numbers) Please comment on this proposal. -- KelleyCook (talk) 15:05, 20 November 2008 (UTC)

It does go in the opposite direction of the trend to rationalise the style guides. Tony (talk) 15:08, 20 November 2008 (UTC)

It would be sufficient simply to create separate discussion pages for these two topics. We seem to have succeeded with the IEC thing; maybe it's time to have another go with the date linking (I tried recently but someone objected). The latter subject is likely to move to a dedicated RFC page soon anyway, so that might be a good moment to officially declare this talk page a date-linking-free zone. --Kotniski (talk) 17:42, 20 November 2008 (UTC)

Full protection

As per a request on WP:RFPP and from noticing the ridiculous amounts of drama on WP:ANI and other locations, I have enacted a full protection on the Wrong Version of this page. I strongly encourage all involved editors to stick to discussion pages regarding this matter, and to immediately cease all large-scale reversions of each other, with bots or otherwise. GlassCobra 20:12, 20 November 2008 (UTC)

• “Drama”. Yes. Thanks. Greg L (talk) 00:34, 22 November 2008 (UTC)

units and their definitions

Moved to Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/IEC#units_and_their_definitions

There was a request for comment that was removed because of the participants' inability to assume good faith, comment with civility, or act at all productively

No more.--Tznkai (talk) 19:03, 24 November 2008 (UTC)

1. Positions, Distances, Directions, Compass; Office of Coastal Survey, NOAA, USA
2. Positions, Distances, Directions, Compass, Ministry of Fisheries and Oceans, Canada
3. See BIPM website on accepted non-SI units, in particular note f.
4. Guidelines for authors (PDF file) IEEE