Template:DocumentHistory

Manual of Style

This page falls within the scope of the Wikipedia: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 articles This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia 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 Wikipedia'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 Wikipedia policies of Wikipedia'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 Wikipedia:WikiProject Dates Wikipedia talk:Date debate Wikipedia talk:Naming conventions (calendar dates) Wikipedia talk:Timeline standards Wikipedia:Measurements Debate Wikipedia 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 14 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present.

We have two templates: 'height' and convert. Although they are written differently, they have overlapping capabilities. Each has its own discussion page but there isn't a forum for discussion relating to the overlap. If the output is the same, when should an article use one rather than the other? Lightmouse (talk) 10:56, 19 July 2011 (UTC)[reply]

Note - Lightmouse (talk · contribs) has, with his bot Lightbot (talk · contribs), introduced massive, un-discussed changes to articles using these templates at least twice in the past. GiantSnowman 11:13, 19 July 2011 (UTC)[reply]

This doesn't seem to be a helpful comment, given LM's attempts to ask for community input here. Tony (talk) 12:41, 19 July 2011 (UTC)[reply]

Perhaps a little, but in fainess, he only asked for community input after two editors wrote on his talk page, questioning his actions. GiantSnowman 12:44, 19 July 2011 (UTC)[reply]

As I understand it, {{height}} is for use in infoboxes, and abbreviations of units and precision default to settings appropriate to such use. This makes it quicker and easier to use than the {{convert}} equivalent. In addition, using a simple template called "height" for a person's height is more intuitive for inexperienced editors, who make a significant proportion of edits to sportspeople's infoboxes. Compare {{height|ft=6|in=2}} with {{convert|6|ft|2|in|m|2|abbr=on}}. Which is why I was disappointed when Lightbot started going round infoboxes changing {{height}} to its {{convert}} equivalent, but assumed this would have been discussed somewhere...

This discussion arose from a thread at Lightmouse's talk page, concerning bot edits adding a precision=0 parameter to usages of {{height}} where the default precision had produced half-inches in the output (displayed as a vulgar fraction). If there actually is agreement that nowadays people's heights are generally measured to the nearest whole inch, then it's fair enough to display at that precision as the result of a conversion from metric. But maybe this should be implemented by changing the output default at the template itself, rather than by complicating matters with the added precision parameter. cheers, Struway2 (talk) 12:57, 19 July 2011 (UTC)[reply]

Forgive me. I do many janitorial edits across the whole of WP. Some pass without comment. Some produce comments merely as a result of curiousity, alternative opinions, lack of awareness, local custom, or whatever. U can't always predict which are regarded as noteworthy by any one of the many editors on the millions of articles. In this case, I brought it here as soon as I saw that the issue is sufficiently important to require community input. I don't think many people are aware that we have two templates with major overlap. A good outcome of this dialog is that people will be able to decide what to do about it.

I agree with the analysis/suggestion of User:Struway2. Thanks. Lightmouse (talk) 13:06, 19 July 2011 (UTC)[reply]

As far as I can tell, the following is true:

What are the reasons for choosing one template over another? Lightmouse (talk) 17:28, 23 July 2011 (UTC)[reply]

I know of one reason for using {{height}}. {{Convert}} cannot produce fractional output ... yet. JIMp _talk·cont 04:01, 8 August 2011 (UTC)[reply]

You misunderstand the question. Let me try again:

• In cases where the two templates are *identical* in read mode, what are the reasons for choosing one template over the other?

See the table above for examples of *identical* read mode. Lightmouse (talk) 09:06, 8 August 2011 (UTC)[reply]

I'd say, if they have identical results it just doesn't matter which one you use. ({Convert} is consistent with any other conversion should be in the article and {height} is fewer keystrokes, so I consider the latter as some kind of shorthand for the former.) ― A. di M.​_plé​^dréachtaí 09:55, 8 August 2011 (UTC)[reply]

We have guidance that says:

• Avoid linking common units of measurement,

Some units are neither common nor uncommon. They're in a middle commonality zone (e.g. nautical mile) where a link isn't required if a conversion is present. Can anyone suggest appropriate wording? Lightmouse (talk) 11:56, 27 July 2011 (UTC)[reply]

Given what MOSLINK says in its footnote 2, and common logic, it seems that the existence of a conversion significantly lessens the utility of a wikilink. Tony (talk) 12:50, 27 July 2011 (UTC)[reply]

Sometimes a unit has more utility for a certain field than one would guess just from the conversion factor. For example, a nautical mile is also close enough, for most navigation purposes, to a minute of latitude, so the left or right margins of a nautical chart can be used to set dividers to the desired distance. Depending on the primary audience of a particular article, a link may be appropriate. Jc3s5h (talk) 12:58, 27 July 2011 (UTC)[reply]

Well, that applies pretty much to all units of measurement. If I'm writing that some guy weighs 89 kilograms (196 lb) I don't link kilogram, but if I'm writing that the kilogram is the only SI unit still defined by an artefact I do link it. ― A. di M.​_plé​^dréachtaí 17:53, 27 July 2011 (UTC)[reply]

How about adding an additional bullet:

• Avoid linking non-obscure units of measurement within conversions

Would that work? Lightmouse (talk) 11:14, 31 July 2011 (UTC)[reply]

Well... I think the footnote already covers it adequately. Also, it would be unclear whether within conversions refers only to the ‘target’ unit or also to the ‘source’ unit. ― A. di M.​_plé​^dréachtaí 11:29, 31 July 2011 (UTC)[reply]

BTW, aren't discussions about this supposed to be at WT:LINK, rather than here? ― A. di M.​_plé​^dréachtaí 11:41, 31 July 2011 (UTC)[reply]

Aha! I'm not the only editor that missed conversions being mentioned in the footnote. I don't care where the discussion takes place but I brought it here because I thought it was a matter for units of measurement people. The issue is that the threshold is different inside a conversion. I think source and target are covered by the phrase but I'd welcome alternative suggestions. Lightmouse (talk) 12:04, 31 July 2011 (UTC)[reply]

• I suggest we mention that editors should consider that what might be drop-dead common in one part of the world may not be common—or even obvious—in another part of the world. I’m talking specifically about older Americans and the metric system. Generally, I’ve seen that Europeans are taught about America's practices and are *ambidextrous*. An example of this is delimiting numbers; Swedes are taught four or five different systems, including the American system (e.g. 12,050.5). Americans are not taught multiple ways to delimit numbers and MOSNUM is written to acknowledge that reality and avoid confusion. The same thing can be handled on the issue of “common” units with a few extra words to acknowledge that many Americans still aren’t fluent in all-things SI. Greg L (talk) 18:37, 2 August 2011 (UTC)[reply]

A good point. It would be a *lot* simpler to have a list of:

• widespread units e.g. pound, kilogram, foot, metre.
• less widespread but still-well-known units

Widespread (aka 'common') units shouldn't be linked, less widespread but still-well-known units shouldn't be linked when in conversions. These two lists could be generated from a subset of the units in US NIST document. This would end frequent debates about whether <unit> should or should not be linked inside and outside a conversion. Lightmouse (talk) 19:06, 2 August 2011 (UTC)[reply]

In as much as Lightmouse is applying for approval for a bot that might/would automatically enforce "shouldn't", I ask Lightmouse to explain how bots would be prevented from enforcing "shouldn't" in exceptional cases where the link is appropriate in a particular article. Jc3s5h (talk) 20:50, 2 August 2011 (UTC)[reply]

To A. di M.: Which of these U.S. Customary units of measure are drop-dead obvious to most non-U.S. English-speaking readers to the extent that virtually no non-U.S. reader would ever bother to click it if it were linked(?):

Acceleration: (none, too obscure for many readers)

Length: mile, yard, foot, inch

Angle: degree

Area: square yard

Currency: US$

Density (none, too obscure for many readers)

Electricity: volt, (no others for being too obscure, also excluding any SI-prefixed forms of volt)

Force: pound (force)

Mass: pound, ounce

Speed & velocity: miles per hour (mph)

Temperature: degree Fahrenheit (°F)

Pressure (none, too obscure for many readers)

Volume: gallon, quart, pint, cup, tablespoon, teaspoon, fluid ounce

Time: century, decade, year, month, days of the week, dates, hours, minutes, seconds (excluding any SI prefixed forms of the second)

Viscosity (none, too obscure for many readers)

Let me know of your thoughts. Off the top of my head, the only SI unit of measure that is so exceedingly familiar that very few American readers would click a link is the liter, which is pretty common in grocery stores. Other than that one, I just can’t think of other units from the SI that should generally be considered as drop-dead obvious for many Americans (particularly older ones), including the kilogram and meter. Note that some of the above-listed units are already SI (but are essentially part of U.S. Customary) or are accepted for use with the SI; namely, the volt, degree of angle, and units of date and time. Greg L (talk) 21:26, 2 August 2011 (UTC)[reply]

I disagree strongly with the notion of linking to the full article on any but the most obscure, arcane, or obsolete units: all you want the reader to know, in the first instance, is the conversion rate, and that is just what is often hard to find at these elephant articles. We need to link to a single page that gives nice easy conversions (even graphically depicted in some cases). Tony (talk) 01:58, 3 August 2011 (UTC)[reply]

So, are you saying that the underlying principal should be Don’t link units of measure unless, considering the context of the article and the target readership, they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on.(?) Greg L (talk) 03:07, 3 August 2011 (UTC)[reply]

Sort of (different wording at the end). I'm saying we need a centralised page that gives conversions and where possible graphical, pictorial, even photographic depictions of the units. That would be much more useful in most contexts than the current articles on individual units. Tony (talk) 03:12, 3 August 2011 (UTC)[reply]

Maybe a set of articles like Length conversions and such? Dicklyon (talk) 04:45, 3 August 2011 (UTC)[reply]

There exists Conversion of units, Metric system, International System of Units, Imperial units, United States customary units, etc. JIMp _talk·cont 05:21, 3 August 2011 (UTC)[reply]

@Greg L: I strongly disagree wrt the degree Fahrenheit; I've met lots of native English speakers from Canada, Ireland, the UK and Australia who wouldn't have a clue of what 35 °F feels like (though they were in their late teens or early twenties; the situation might be different for older people). (Also, it's much harder to mentally convert degrees Fahrenheit than most other units, as one multiplication doesn't suffice.) I doubt think that the pound-force is much less obscure than all units of acceleration or pressure. As for the gallon, quart and pint, the imperial versions are about 20% than the US one, and I think most native English speakers outside the US don't even know that US pints are different, let alone how much they are. I agree that the rest of those units are quite commonly used by almost all native English speakers, at least in non-technical colloquial usage, but I don't think we should cater for native speakers alone to the exclusion of everybody else: there are lots of readers from India/Germany/the Philippines/Brazil/France/Italy/the Netherlands/Poland/etc. lots of whom, I suppose, wouldn't be able to guess how long one yard is within a factor of 2. (Though, in 90% of cases in-line conversions are a better way to handle that than links.) ― A. di M.​_plé​^dréachtaí 15:59, 3 August 2011 (UTC)[reply]

As for “units from the SI that should generally be considered as drop-dead obvious for many Americans”, what do you guys measure the power of electric appliances in? It would be hard for me to imagine many people who aren't familiar with watts and kilowatts. Also, those people who can use a computer, which I think make up for a large part of our readership ;-), are likely familiar with mega- and gigahertz. (So would those who can use an FM radio, for that matter.) ― A. di M.​_plé​^dréachtaí 16:27, 3 August 2011 (UTC)[reply]

Certainly link the truely obscure units so as to help understanding but we should avoid cluttering the place up with links to articles with very little relevance to the topic at hand. If you're suggesting that a significant number of Americans would find such units as the kilometre, metre, centimetre, millimetre, square metre, square kilometre, kilogram, gram and kilometre per hour obsure, I'd find that quite surprising (inspite of how the rest of us like poking fun at supposed American ignorance). Sure, such units as the tonne, hectare, newton, kilojoule and degree Celsius might be a little obscure to many Americans, as would be their US customary/imperial counterparts to most of us metricated folk. However, I'd suggest that even these are not yet approaching that grey area Lightmouse refers to, they're still only more-or-less off-white. The thing is that we have, to reverse the section title, conversions instead of links. An American (even an ignorant one, assuming they're at least literate) is going to read "20 hectares (49 acres)" and think something along the lines of "oh yeah, a hectare is an area unit" and, if they care enough, could easily figure out "... about 2+1⁄2 acres"; just as a metric-minded fellow (yes, we can be ignorant too) will read "20 pounds-force (89 N)" and think something like "right, a pound force is a unit of force ..." and, again, after a little mental maths, "... about 4+1⁄2 newtons". If it bugs them enough, let them copy and paste it into the search box. No, that grey area is occupied by such units as the micrometre, the parsec, the pascal, the troy ounce, the bushel, the oil barrel, the nautical mile, etc. but it still depends on context. The knot in an article about a certain boat should not be considered obscure nor should the picometre be in an article about a certain molecule. There may even be contexts in which such relatively obscure units as fathoms, furlongs, firkins or femtometres need not be linked. JIMp _talk·cont 05:17, 3 August 2011 (UTC)[reply]

So could we have a list of units that should not normally be linked without good reason? I'm struggling with the notion that "acceleration" and "density" are obscure enough to require a link, although possibly in some scientific articles they might be reasonable. Tony (talk) 13:23, 3 August 2011 (UTC)[reply]

Greg ask Tony if a principle should be:

• Don’t link units of measure unless, considering the context of the article and the target readership, they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on.

If that's fine with Tony and Greg, it's fine with me as a principle. Although it's worth mentioning explicitly that a converted unit is less in need of a link than an unconverted one.

Greg suggested the following units wouldn't need linking for US readers:

• inch, foot, yard, mile
• degree (angle)
• litre
• volt (unprefixed)
• pound (force)
• pound mass, ounce mass
• °F
• gallon, quart, pint, cup, tablespoon, teaspoon, fluid ounce
• century, decade, year, month, days of the week, dates, hours, minutes, seconds (excluding any SI prefixed forms of the second)

It might help to say:

• square, cubes, and combinations of listed units (e.g. square foot, mile per hour) shouldn't be linked.

I agree that those few units shouldn't be linked. But like Jimp, I'm surprised the list isn't longer. Anyway, even just that would be an improvement over the current guidance. Lightmouse (talk) 14:57, 3 August 2011 (UTC)[reply]

I disagree about “square, cubes, and combinations”. The fact that one is familiar with the foot as a unit of length, the pound-force as a unit of force and the second as a unit of time doesn't mean they're necessarily familiar with the foot pound-force per second as a unit of power or the pound-force second per square foot as a unit of dynamic viscosity. ― A. di M.​_plé​^dréachtaí 16:17, 3 August 2011 (UTC)[reply]

• Me too; I agree with A. di M. I’ve been an R&D engineer for decades now. I’ve had plenty of occasion to (try to) explain complex things in simple terms. I can tell you with great certainty that there are plenty of Americans who are infinitely familiar with what one linear foot is but have zero clue what a cubic foot is, much less a cubic yard. If A. di M. thinks that the above summary (14:57, 3 August 2011 post) listing common U.S. Customary units are all thoroughly familiar to the rest of the non-American English-speaking readership, then there is no need whatsoever to link them. Note too that in my original list, I included miles per hour (mph) as drop-dead obvious and well known to an American readership.

  I think there is an over-abundance of left-brained males represented in this venue. I can tell you that if WT:MOSNUM had an ocean of right-brained *wife-types* (verbal and reading skills, not so much insofar as spatial reasoning) participating here, we would receive earnest advise that calculating how many cubic yards or cubic meters of beauty bark to order from a landscaper is not a universal skill and the nature of the measure is not as intuitive as some here seem to assume. Greg L (talk) 22:46, 4 August 2011 (UTC)[reply]

  “If A. di M. thinks that the above summary (14:57, 3 August 2011 post) ...” I have already commented on it. ― A. di M.​_plé​^dréachtaí 12:50, 5 August 2011 (UTC)[reply]

Clearly one set of units is unfamiliar to one big part of the readership, while another set is unfamiliar to another big part of the readership. Therefore, instead of ubiquitous linked units, we often include conversions. In my view, only if both (all) of the units in a converted quantity are unfamiliar, a link should be considered. −Woodstone (talk) 17:00, 3 August 2011 (UTC)[reply]

I think a reasonable principle may well be that units should not be linked except where the link provides information that is relevant to the article, over and above that provided by simply converting. Practically all units that are common in one part of the English-speaking world but not in another should be converted anyway so that all readers can easily understand the article: there seems little need to routinely link "degrees Fahrenheit" or "kilograms", for example.

If, OTOH, we're discussing a distance in (for example) traditional Swedish or Norwegian miles, there is a good chance that the article Scandinavian mile will be worth linking because it's likely to be pretty relevant to the article concerned (there being few contexts in which you're actually likely to be using traditional Swedish or Norwegian miles). Equally, in some scientific articles, chances are that there are some units that are going to be difficult to explain concisely and where conversion won't leave the reader any the wiser: again, linking in those cases might be appropriate. Pfainuk talk 18:22, 3 August 2011 (UTC)[reply]

• In my above list, I am referring to the U.S. Customary statute mile. If an article has need to mention the Scandinavian mile in an “Oh… didn’t-cha know??”-fashion, it best be linked and parentheticals provided to both a statute mile (to make it more accessible to our American readership) and to kilometers (to make the measure more accessible to everyone else). Judging from the What Links Here for our “Scandinavian mile”, the only articles mentioning it are discussing the unit directly and the unit is already being linked. That’s not what we are talking about here, Pfainuk. Greg L (talk) 22:52, 4 August 2011 (UTC)[reply]

Well in that case, what are you talking about? This appears to be a discussion on what kinds of unit should be linked and what we shouldn't link. My comment is on topic in this context. If it is in fact another discussion on Gibibytes and whether dates should be round or square, then it's well disguised - and that's not a good thing in a discussion on Wikipedia.

You appear, for example, to be arguing that we routinely link kilometres in your list above because "the only SI unit of measure that is so exceedingly familiar that very few American readers would click a link is the liter". My comment disagrees with this, while noting that there are some units (such as the Scandinavian mile - and the idea that all references to a unit are necessarily linked seems a touch odd) that are more likely to be linked with good reason. Pfainuk talk 06:36, 5 August 2011 (UTC)[reply]

Sorry but you are going to have to simplify that for the layman. What on earth does "they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on." mean? Keith D (talk) 19:07, 3 August 2011 (UTC)[reply]

I would consider linking any unit that a student would not have heard of until taking the more rigorous version of high school physics. Even then, I wouldn't link it if anyone able to understand the article would already understand the unit. Jc3s5h (talk) 13:03, 5 August 2011 (UTC)[reply]

Just some brainstorming...

• ∗ Not only space-wise but also time-wise–it's not inconceivable that in some areas 15-year-olds are familiar with different units than 70-year-olds are.
• † The large one, also known as dietary calorie, kilocalorie, and Calorie.
• ‡ Provided the context makes clear whether the small ones or the large ones are meant.

Am I missing some/including some I shouldn't? My conjecture is that iff a quantity is shown in a set of units such that each cell of the relevant row of this table is represented, then the fraction of readers of en.wiki who would not understand the quantity is negligible. ― A. di M.​_plé​^dréachtaí 13:15, 5 August 2011 (UTC)[reply]

Obviously currencies are going to be more location-specific than everything else, and there are some measures that are very context-specific in the UK - stones for personal weights being the most obvious. Pfainuk talk 17:15, 5 August 2011 (UTC)[reply]

Well, it'd be very impractical if each amount of money had to be converted to a dozen different currencies, and sticking to the three most common ones in terms of numbers of en.wiki readers is a good compromise. (Also, I'd expect most Canadians to have at least a rough idea of how much one US dollar is, and most people from non-euro European countries to have at least a rough idea of how much one euro is. Why TF is my spell checker flagging euro?) ― A. di M.​_plé​^dréachtaí 21:17, 5 August 2011 (UTC)[reply]

• Familiarity and non-familiarity isn't the only guide to whether a unit should be linked. Linking to broad-scoped articles on these units isn't very useful for someone who isn't familiar with their relative size. Some people will be familiar with the name and what it's measuring, without easily being able to conceive how big it is (mile, kg). I'm not sure why a link is ever necessary if there's a conversion on the spot. Tony (talk) 14:02, 5 August 2011 (UTC)[reply]

  I mean familiar as in “being able to conceive how big it”, not just as in “having heard of”. Also, I've not yet said how this table is relevant about my ideas on linking, so far I've just been ‘thinking aloud’. (“I'm not sure why a link is ever necessary if there's a conversion on the spot.” Do you mean you would not link electron volts if there's a conversion to joules no matter how many readers have never heard of either?) ― A. di M.​_plé​^dréachtaí 15:39, 5 August 2011 (UTC)[reply]

Can we take some examples *within conversions*:

• "the player weighs 80 kilograms (180 lb)"
• "the player weighs 180 pounds (82 kg)"
• "the player is 6 feet (1.8 m) tall"
• "the player is 1.80 metres (5.9 ft) tall"
• "the house is 1,000 square feet (93 m²)"
• "the house is 100 square metres (1,100 sq ft)"
• "it's 80 miles (130 km) away"
• "it's 50 kilometres (31 mi) away"
• "the limit is 50 miles per hour (80 km/h)"
• "the limit is 80 kilometres per hour (50 mph)"

Do any of those need a link? Lightmouse (talk) 17:00, 5 August 2011 (UTC)[reply]

Many British people are going to have a problem with both "the player weighs 180 pounds (82 kg)" and "the player weighs 80 kilograms (180 lb)" because personal weight is near-universally measured in stones here. You only use pounds for babies and for fractions of a stone (e.g. "the player weighs 12 stone 7 pounds (79 kg; 175 lb)"). But that's a conversion issue, not a linking issue. Allowing for that, none need linking in my view. Pfainuk talk 17:15, 5 August 2011 (UTC)[reply]

No they don't; and I don't think anyone ever suggested that they do, so what's your point? The best practice for such common everyday measurements isn't necessarily as good for more technical units of measurement such as the teraelectronvolt or the inverse femtobarn. (Also, a unit can be everyday in a context and technical in another: the inch is a common everyday unit in the US and much of the Commonwealth, but is the technical unit in which guitar string gauges are measured throughout the world, even by people who seldom use inches for anything else.) ― A. di M.​_plé​^dréachtaí 21:17, 5 August 2011 (UTC)[reply]

User:AdiM's table is a good start. However, we still have the problem that some editors assert that units in the 'other system' are obscure and need linking. Can anyone propose guidance text that explains that although '9 millimetres' may be deemed obscure to Americans, it doesn't qualify for a link when in a conversion with the not-obscure '0.35 inches'? Lightmouse (talk) 17:54, 6 August 2011 (UTC)[reply]

Who is asserting that, exactly? BTW, what you say seems to be quite the same as what the footnote in WP:LINK says. If you want to move its text into the main text to make it more visible, go ahead. ― A. di M.​_plé​^dréachtaí 18:16, 6 August 2011 (UTC)[reply]

As I understand it, Greg was saying km and kg are obscure and require linking. If that's not the case, then I'm fine with that. Following your encouragement and updated Wikipedia:Manual of Style (linking) so the advice that conversions are relevant isn't in a footnote. I've also added a table inspired by yours. If it needs amending, please go ahead. Lightmouse (talk) 20:27, 6 August 2011 (UTC)[reply]

This looks like a nice beginning of a list but I'd say that there are more units to include. Also should the list be context dependant?

Energy

The millijoule, the joule, the kilojoule & the megajoule. Plus in physics articles the electron-volt, kilo~, mega~, giga~ ... P.S. don't bother with capital "C" calorie it's relatively unused & it more likely to cause confusion than clarity (previously discussed).

Speed

The metre per second, the foot per second, in (aero)nautical contexts the knot & in physics c.

Angle

In maths and physics the radian.

A problem with a list of "non-obscure units" is that it might seem to imply that whatever is not on the list is obscure and thus encourage overlinking rather than discourage it. There are so many units out there which are well enough known not to be linked (esp when there a conversion). Is this list the tip of a very big iceberg? ... miles per gallon, litres per 100 kilometres, cubic centimetre, mm of Hg, psi, pascal, foot pound, newton metre, calorie per ounce, kilojoule per gram, tonne of TNT, nauticle mile, hectare, light-year, pixel, megapixel, oil barrel, yen, Aussie dollar, German mark, teaspoon, cup, ... JIMp _talk·cont 11:20, 7 August 2011 (UTC)[reply]

I disagree with the joule and multiples: AFAICT, in the northern hemisphere the only people who actually use joules in everyday life outside high school/undergrad physics classes are soft-air players. The kilowatt-hour and kilocalorie (depending on what you're measuring) are way more common, regardless of the wishful thinking of EU legislation. Also, the electron volt is known only to physicists (I'm not sure whether I was ever taught it in high school), so IMO it should definitely be linked. The radian should be more widely known, but I bet my mum has no idea what it is. ― A. di M.​_plé​^dréachtaí 13:36, 7 August 2011 (UTC)[reply]

Yes, link the electron-volt if it appears in such a context where it would be obscure. For example, this unit appears in the Atom article, a general-interest introductory-level physics article, where it has to do with the topic at hand and is appropriately linked. However, the article Kaon uses "MeV" without a link and, I'm saying, without the necessity for a link since it's not obscure and does not have anything much to do with the particular topic at hand. The joule and multiples is just another of these your-system-my-system unit: the north may be lagging behind but we use them in the south. The point is that there should be conversions so you can go ahead and read the calorie value ignoring the kilojoules and let me ignore the calories and read only the kilojoules. I don't need a link to the Calorie article. Just like miles, feet, inches, pounds. ounces, etc.: even if I have no concept of what these are, it doesn't matter since there are conversions for me to read. JIMp _talk·cont 23:46, 7 August 2011 (UTC)[reply]

The MeV might not be oscure for you, but it is for lots of people. It's not like laymen should be forbidden from reading Kaon and, while they will obviously not understand everything, we shouldn't artificially make them understand less than they could (WP:MTAA); in particular, they shouldn't have to copy and paste a technical term to look it up when we could provide a link to it (within reason, but I'm talking of linking only the first of however many instances of keV are in the article). (And I wouldn't link the joule in 12,345 kilojoules (2,951 kcal) in an Australia-related nutritional article or 1,945 kilocalories (8,140 kJ) in an Europe-related one, either, but I would link “1 joule” in a soft-air article where no conversion would be particularly useful.) ― A. di M.​_plé​^dréachtaí 10:05, 8 August 2011 (UTC)[reply]

Let's not make the best the enemy of the good. Please note the 80-20 rule, most of the overlinking problem (say 80%) is due to a few units (say 20%). The 12-row table that User:AdiM proposed would address the majority of the problem. Lightmouse (talk) 10:13, 8 August 2011 (UTC)[reply]

A link is much less justified *within a conversion*. Above, Jimp highlighted two legitimate concerns:

• Fear: Potentially implies units not listed should be linked. Mitigation: Statement that the list of not-obscure units "includes but is not limited to ...".
• Fear: List could become very big. Assessment: At worst, the table would have about 50 rows. That isn't so much.

There is no need to list <not-obscure unit> divided by <not-obscure unit> or <not-obscure unit> squared. The benefit of a list of specific units is that it documents consensus of what the guidance actually means. Please note the 80-20 rule, most of the overlinking problem (say 80%) is due to a few units (say 20%). The 12-row table that User:AdiM proposed would address the majority of the problem.

I'd be fine with that of somebody else's table but for the record, here is mine:

The idea that “<not-obscure unit> divided by <not-obscure unit>” is always non-obscure is quite weird, as I said before. (Even if someone is familiar with furlongs and fortnights, they're still likely to go WTF when reading about furlongs per fortnight if they haven't heard that before.) Together with the fact that the metre, kilo, second and volt are not obscure, it would make pretty much any SI unit (non involving moles, kelvins or candelas) non-obscure, but I seriously doubt there's any country in the world where a significant fraction of the population is familiar with (say) the henry. (Also, pretty much no-one uses megametres and gigametres (my spelling checker even flags them); they're always thousand kilometres and million kilometres, and for larger stuff you either use astronomical units/light years/parsecs or x×10^y metres/x×10^{y − 3} kilometres. Likewise for many other suffix–unit combinations you listed. Millibit? Not only do I bet fewer than 10 people ever used it, I also bet that less than 0.1% of readers would realize that it even makes sense.) ― A. di M.​_plé​^dréachtaí 10:33, 8 August 2011 (UTC)[reply]

Furlong example. That unit isn't in the table. Can you provide an example division using units from the table that you think requires linking?

Mole, kelvin, candela, henry examples. Those units are not in the table. Can you provide an example SI unit from the table that you think requires linking?

Examples of units not used. A benefit of SI is <set of prefixes> and <set of units>. Any SI unit that doesn't require a link will also not require a link with known prefixes. If a combination isn't used, then it isn't a problem. If you want to remove it, that's fine by me.

I'm just keen that we get consensus on the worst 80% of overlinked units. It'll take us forever if we want to get the last 20% of units.

Lightmouse (talk) 10:59, 8 August 2011 (UTC)[reply]

Read my post again, I think you missed the point. ― A. di M.​_plé​^dréachtaí 11:08, 8 August 2011 (UTC)[reply]

It's possible. I was distracted by your examples of units that aren't proposed or aren't a problem. Can you try explaining a different way with examples that are proposed and are a problem? Lightmouse (talk) 11:13, 8 August 2011 (UTC)[reply]

Not with any of the things you listed explicitly, but the rule about divisions is potentially recursive so it could get much more complicated stuff than you realize. According to your rules, the joule (watt-second) is non-obscure, hence the coulomb (joule per volt) is non-obscure, hence the farad (coulomb per volt) is non-obscure, hence... Also, if I saw the speed of a snail expressed in kilometres per week, even though I was able to figure it out (with several seconds of mental maths), I'd still want an explanation of why the hell such a weird unit was chosen. ― A. di M.​_plé​^dréachtaí 11:43, 8 August 2011 (UTC)[reply]

In response to "Can you provide an example division using units from the table that you think requires linking?", some kind of explanation of "kilowatt per year" would be required if we used in the same sense as this PDF. (I'm not sure if that usage makes sense or not, but if it does an explanation is required). The explanation could be in the form of a link, although no "Kilowatt per year" article exists yet. Jc3s5h (talk) 11:19, 8 August 2011 (UTC)[reply]

That non-Wikipedia article says:

• "UD Reduces Kilowatt Usage. The installation of motion sensors for warehouse and office lighting has reduced electric consumption by 50% annually. This represents a reduction of 370,000 kilowatt per year."

If that were a Wikipedia article, I'd edit it to say 'reduces energy usage'. The instance of kilowatt doesn't need a link. Simples. Lightmouse (talk) 11:25, 8 August 2011 (UTC)[reply]

I don't think any link is required for <not-obscure unit> per <not-obscure unit of time>. Lightmouse (talk) 11:30, 8 August 2011 (UTC)[reply]

If it's so simple, maybe you can explain what it means. I don't know what it means. Jc3s5h (talk) 11:32, 8 August 2011 (UTC)[reply]

If it means what I guess I means, I'd just replace per with in one or every depending on what they're talking about exactly. ― A. di M.​_plé​^dréachtaí 13:26, 8 August 2011 (UTC)[reply]

I can't explain what the author means. However, I do know that reading the kilowatt article and the year article won't help. Lightmouse (talk) 11:44, 8 August 2011 (UTC)[reply]

If this kind of confusion occurs often enough to justify the effort, a new article, Kilometers per year, could be created and linked to. I agree that individual links to Kilometer and Year would not help. Jc3s5h (talk) 12:20, 8 August 2011 (UTC)[reply]

A good point. You may remember a recent discussion about 'BTU' versus 'BTU/h' (here and here). I think it's the same issue. Lightmouse (talk) 12:43, 8 August 2011 (UTC)[reply]

Link only that which pertains to the topic

Here we are deliberating as to what is to be considered obscure and what is not. Firstly all units which belong to the other system are obscure (the other system is an instrument of the Devil created to cause disharmony on Earth, but we have to put up with it on WP bacuse we can't find any reliable source to back this up ... or even to prove that the Devil exists). Feet are obscure to us, metres are obscure to them, but this is okay since we have conversions. The question is what's obscure to all of us. It depends on context. Now, suppose we have a unit which, in the particluar context, could be considered obscure. Now suppose this said unit has nothing in particular to do with the topic at hand. I must wonder what such a unit would be doing there at all.

Linking days of the week, dates, months, years, we're over it ... unless it has to do with the topic at hand. Linking countries ... we're over this too ... right ... unless it has to do with the topic at hand. What about applying the same rule to units? Obscurity, forget about it; is the unit relevant to the topic? Regardless of how obscure or well known the unit may or be, link it iff it is germane. Even non-obscure units should be linked when they relate to the context. JIMp _talk·cont 00:15, 8 August 2011 (UTC)[reply]

There's been an extensive discussion above. On the basis of the 80%/20% rule, it doesn't matter if we don't have the table complete and/or don't capture all units. It can be updated as required. But the most common 20% of units that are responsible for most of the overlinking and editors need specific guidance. In the absence of any other proposal, I propose the following table

I've tried to encapsulate all comments. I think it's time to document consensus for adding a table like that, or even a trimmed down version. Lightmouse (talk) 11:40, 10 August 2011 (UTC)[reply]

Support I don't mind if it's modified, as long as there is something where editors see *actual* units listed. Lightmouse (talk) 11:40, 10 August 2011 (UTC)[reply]

Conditional support We should target the list at reasonably educated users who have not done science. The user I have in mind is my wife, aged 60, started university but never studied science at school. In deference to her, and thousands like her, I think that we shoudl remove units of energy, power, frequency and information form the list. Martinvl (talk) 12:43, 10 August 2011 (UTC)[reply]

Doesn't your wife ever use domestic appliances or pay electricity bills? :-) I mostly agree with your point, though; also, I'd list compound units individually, as it wouldn't be immediately obvious to people like your wife how fast 12 m/s is, and some prefixes are really uncommon with some units. ― A. di M.​_plé​^dréachtaí 23:26, 10 August 2011 (UTC)[reply]

Oppose. This is complete rubbish; most UK youngsters have no idea about any of the Imperial Units and plenty of UK oldsters will never be conversant with the metric system. -- cheers, Michael C. Price ^talk 12:39, 14 August 2011 (UTC)[reply]

Not in my experience; even assuming that by any of the Imperial Units you actually mean ‘excluding miles and pints’, I've met plenty of people in their late teens/early twenties from the UK and Ireland who routinely use feet, inches and stone and have no idea of how tall someone 1.70-metres-tall is (or a 15-centimetre penis, or a 88-kilo person). ― A. di M.​_plé​^dréachtaí 14:55, 14 August 2011 (UTC)[reply]

MC Price, these are for conversions: why does a UK old person need a link (not helpful anyway, IMO) when they have two equivalents? And as for young people, if they don't know what basic units are, they should learn them before looking at WP, or type the unit into the search box (again, not much help the way our unit articles are framed). Tony (talk) 10:24, 16 August 2011 (UTC)[reply]

And yards? And Fahrenheit? -- cheers, Michael C. Price ^talk 16:15, 14 August 2011 (UTC)[reply]

Conditional support: I have no problem with the majority of units not being linked in general, so long as the first instance remains linked for those whom it would benefit. I see no reason to provide the maximum benefit to readers while still maintaining some measure of style, and I think that does it. — Huntster (t @ c) 23:51, 14 August 2011 (UTC)[reply]

Huntster, you saying that all units should be linked at least once per article, even routine units like "6 feet 3 inches (1.91 m) tall and weighs 220 pounds (100 kg)"? Lightmouse (talk) 18:32, 15 August 2011 (UTC)[reply]

• Support in principle, and probably in details. Which time units would need to be linked, then? Tony (talk) 10:27, 16 August 2011 (UTC)[reply]

I've not read through MOSNUM for some time. How did the units of measurement section get into such a mess? I can't understand most of it. Just how it's useful for editors is beyond me. Tony (talk) 13:02, 3 August 2011 (UTC)[reply]

And, after you, Colonies Chris, and I rolled up our sleeves and worked in good faith and in a collegial manner, I find it much improved. Thanks for kicking off the effort. Leadership by example. Greg L (talk) 17:36, 4 August 2011 (UTC)[reply]

It still needs a lot of work. I can't make much sense of it. The section needs to introduce the concepts nice and clearly, in the most logical order. It would be best to state general guidelines that affect most editorial decisions, followed by exceptions and special cases. The country thing is by far the most common decision. Why is it now submerged in what appears to be obscure science stuff? Tony (talk) 13:58, 5 August 2011 (UTC)[reply]

It’s just some reinforcement so that the section doesn’t read like Wikipedia is a big battleground for rahh-rahh-metric yahoos and pro-America yahoos. It’s some reinforcement to get their minds right that we follow the RSs whenever they are consistent on both sides of the pond and they mustn’t try to turn Wikipedia into a battleground over units (because one discipline or another ought to have adopted a *scientificy* unit years ago and Wikipedia will Lead The Way®™©). That’s a one-paragraph preamble, of sorts, before we get to the remainder of that section, which deals with how to address units when things do differ depending upon which side of the pond the RS is on. Greg L (talk) 22:33, 5 August 2011 (UTC)[reply]

I noticed that few of the “regulars” of this page are signed up as members of WP:MEASURE. Have you ever considered joining it? It's not terribly active at the moment, but that might be because it has so few members. ― A. di M.​_plé​^dréachtaí 21:36, 3 August 2011 (UTC)[reply]

GiBberish in articles I care about infuriates me: Almost anything remotely related to the octet variant of the byte known as B requires a binary interpretation, e.g., calculations with sectors might use sector size 512, 2048, or 4096, but certainly never the 1000 to justify say TiB. Please avoid marketing GiBberish trying to sell less than 4,000,000,000 bytes as 4 GB. ISO produces mainly non-free standards and is indirectly (via national bodies) dominated by the industry, not by consumers (incl. Wikipedia readers) or experts (incl. Wikipedia editors). –89.204.153.166 (talk) 10:22, 3 August 2011 (UTC)[reply]

Please consider registering and logging in. Can you expand on your comment, and can you make a few suggestions as to how you'd like to see the style guide change in this respect? Tony (talk) 06:22, 4 August 2011 (UTC)[reply]

To I.P. upset about GiBberish: MOSNUM proscribes the routine use of the IEC prefixes (“kibibyte”, “mebibyte”) to describe binary capacity. Please see MOSNUM’s Quantities of bytes and bits section. Unless it is an article directly discussing the subject of the IEC prefixes, terminology like “GiB” is not to be used. Feel free to fix any shortcomings in this regard yourself after having familiarized yourself with our guidelines on this issue. Greg L (talk) 17:34, 4 August 2011 (UTC)[reply]

There is a section called 'Unnecessary vagueness'. I think guidance can sometimes

• document the outcome of a dispute that may reoccur
• define how to fix a common and significant problem that wouldn't be fixed by the wiki
• make a difference to what editors actually do

That section doesn't appear to do any of the above. It seems to be just like saying 'use common sense', 'make appropriate edits', 'consult editors if there's a dispute' etc. I suspect the answer will be 'nothing' but what would happen if that section were deleted? Lightmouse (talk) 11:11, 4 August 2011 (UTC)[reply]

Ah, actually, I think you're right. Years ago, this section seemed like necessary advice; but perhaps the project has been sufficiently professionalised for us to remove this section (I never liked the tabular format, either). Nowadays, who wouldn't stamp on a statement that "The wallaby is small"? Tony (talk) 12:29, 4 August 2011 (UTC)[reply]

I noticed [1], which would have changed the guidance. Past discussions resulted in saying it was acceptable to have publication date format differing from accessdate format - or, said a different way, that there was no consensus to forbid it. I clarified this based on the examples. However, the phrasing would still restrict a form that exists in articles - yyyy-mm-dd for the publication date, and ymd or dmy for accessdate. I've rephrased again, but I can see this being more disputed, so I'm drawing attention here: [2] Gimmetoo (talk) 14:53, 5 August 2011 (UTC)[reply]

How is this different from the current guidance, aside from being wilfully difficult to understand? ("either"?) Tony (talk) 15:10, 5 August 2011 (UTC)[reply]

The examples make it appear that yyyy-mm-dd is acceptable only for access/archive dates, but not for publication dates. That's the problem. Gimmetoo (talk) 15:14, 5 August 2011 (UTC)[reply]

I interpreted the examples differently. Since one of the publication dates, "20 Sep 2008", did not match either of the two formats accepted for running text (because it is abbreviated), I inferred that any publication date format is allowed, (except "20/9/2008" or "9/20/2008"). There is one style guide, APA style, that would write "2008, September 30" in the references but "September 30, 2008," in the running text. Jc3s5h (talk) 15:32, 5 August 2011 (UTC)[reply]

What puzzled me most about this version:

Correct	Incorrect
Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009	Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009 Jones, J. (20 Sep 2008) ... Retrieved Feb 5, 2009

is that the first "Correct" example and the first "Incorrect" example are identical. Art LaPella (talk) 21:38, 5 August 2011 (UTC)[reply]

• OK... Now that the totality of my changes was judged unacceptable by one or other party, let's reopen that discussion again. The premise for my proposed change was that I felt:

1. there is no consensus to eliminate ISO 8601 date formats from articles, in particular the reference sections
2. a mix of date formats in the reference sections is aesthetically unattractive and difficult to parse
3. there is little reason to insist on ISO 8601 formats for access dates whilst leaving the publication date in dmy or mdy format
4. there is little reason to disallow ISO 8601 formats for publication dates whilst allowing this for the accessdates
5. there is little reason to insist on ISO 8601 formats for archive dates should be treated any differently from publication or access dates
6. dmy or mdy format using abbreviated months can be equally concise as the yyyy-mm-dd format; the only thing we care about is consistency
7. there is only one mention in the entire guideline of 'reference format'; it remains undefined and its meaning is unclear.
8. it has already been stated further above that the use of slash dates is ambiguous and therefore not to be used
9. tabular form of presentation where examples of dos and don'ts are juxtaposed is starker and more easily comprehended by the reader.
10. ALP spotted the deliberate error. ;-)

In summary, consistency was and is the primary consideration in this guideline, so either use the style prevailing in the article, or ISO 8601 throughout the refs section

--Ohconfucius ^¡digame! 15:37, 6 August 2011 (UTC)[reply]

I have no idea how you came to this change as "per talk", which normally implies an agreement. Your change to the guidance in that section was disputed. We have articles that were written using a contrasting style for the publication dates and the access dates. This converys information. That style was discussed at various times and found acceptable (or, at least, that there was no consensus to forbid it). You are trying to exclude an established style, without discussion and without consensus. Gimmetoo (talk) 05:08, 7 August 2011 (UTC)[reply]

• the 'per talk' is in relation to the rationale expressed above. You seem to be the only one opposing this change for now. You reverted without comment, and I ask you to start discussing the substance of my rationale, rather than a "it's always been this way" type comment. Please don't treat it is immutable. Of course, I'm not going to war with you if we can agree to talk sensibly about it. --Ohconfucius ^¡digame! 07:14, 7 August 2011 (UTC)[reply]

[3] OhCon, you are making a change to the current guidance. It is you who must get consensus for your changes point-by-point. The first point is that your change adds that every date in an article would have to be the same, simulatenously abolishing the long-standing distinction between article and reference formats, and between publication and accessdate formats, and at the same time rejecting multiple previous discussions and RFCs. Yes, alas, on wiki nothing is immutable, but when someone (you) has multiple previous failed attempts to change the guideline, yet repeatedly tries to make the change as if all previous consensus can be ignored, there really isn't much else to say. I expect you to self-revert here, and not make any related changes in articles, without a clear consensus. Gimmetoo (talk) 08:26, 7 August 2011 (UTC)[reply]

I am not sure this is the same. This is not a proposal to rid WP of the yyyy-mm-dd format, but to make them uniform within any given section where they are used.

Yes, this has been discussed before. Gimmetoo (talk) 09:34, 7 August 2011 (UTC)[reply]

Perceived problems of the current guideline as I understand it, excepting for dates within titles and quotations :

• the guideline permits the use of up to two different formats in the reference section in various permutations

1. dmy (i.e. 12 August 2011) or mdy (i.e. August 12, 2011) for publication, access and archive dates
2. dmy (i.e. 12 August 2011) or mdy (i.e. August 12, 2011) for publication and archive dates and yyyy-mm-dd (i.e. 2011-08-12) for access dates
3. dmy (i.e. 12 August 2011) or mdy (i.e. August 12, 2011) for publication dates and yyyy-mm-dd (i.e. 2011-08-12) for access and archive dates
4. yyyy-mm-dd (i.e. 2011-08-12) for for publication, access dates and archive dates

I propose that henceforth we stipulate that all dates in the reference sections are uniformly consistent, as provided in this version (click on "show" to see it):

Date formats may be the same as prevailing in the body of the text – and may be abbreviated if there are space concerns, or they may be in the yyyy-mm-dd format --Ohconfucius ^¡digame! 09:15, 7 August 2011 (UTC)[reply]

I would like to see if a new consensus exists based on the following premises:

1. there is no consensus to eliminate ISO 8601 or yyyy-mm-dd date formats from articles, in particular the reference sections
2. a mix of date formats in the reference sections is aesthetically unattractive and difficult to parse
3. there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for access dates whilst leaving the publication date in dmy or mdy format
4. there is little reason to disallow ISO 8601 or yyyy-mm-dd formats for publication dates whilst allowing this for the accessdates
5. there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for archive dates should be treated any differently from publication or access dates
6. dmy or mdy format using abbreviated months can be equally concise as the yyyy-mm-dd format; the only thing we care about is consistency
7. 'reference format' remains undefined and its meaning is unclear.
8. tabular form of presentation where examples of dos and don'ts are juxtaposed is starker and more easily comprehended by the reader.

• Should I make this into RfC? --Ohconfucius ^¡digame! 09:18, 7 August 2011 (UTC)[reply]

Support

1. as proposer. --Ohconfucius ^¡digame! 09:50, 7 August 2011 (UTC)[reply]
2. Making this consistent makes a lot of sense. We should be making things consistent for our readers and the scripts that run on our articles. GFHandel ♬  10:04, 7 August 2011 (UTC)[reply]
3. I'm all for consistency generally. Nearly always it helps readers, even if it's just a matter of not slowing them down. I see no reason for an exception here. Noetica^Tea? 00:03, 8 August 2011 (UTC)[reply]
4. Internal consistency within an article is important, but I do stress that the consistency in the article text should not be taken as the required date format for references. --MASEM (t) 13:47, 8 August 2011 (UTC)[reply]

   So, in other words, you oppose this "proposal", which would require that all dates in references match the article body, unless all dates in refs are done in yyyy-mm-dd. (And I put quotes around the word "proposal" because the user "proposing" has ensconced his text in the MOS and has refused to remove it.) Gimmetoo (talk) 19:07, 8 August 2011 (UTC)[reply]

   Your over-vivid imagination is getting the better of you. You want to see this proposal defeated, because you imagine that it amounts to removing all yyyy-mm-dd dates from reference sections. It doesn't, and Masem realised that his comment is spot on with the proposal. --Ohconfucius ^¡digame! 12:28, 12 August 2011 (UTC)[reply]

   Hmm, my imagination must be equally over-vivid. "all dates in references match the article body, unless all dates in refs are done in yyyy-mm-dd" does seem to match "Date formats may be the same as prevailing in the body of the text ... or they may be in the yyyy-mm-dd format" and the "Correct"/"Incorrect" table, better than it matches "removing all yyyy-mm-dd dates from reference sections". However, Masem's "consistency in the article text should not be taken as the required date format for references" is compatible with the proposal, which makes yyyy-mm-dd references the only allowed exception to that consistency. Art LaPella (talk) 18:06, 12 August 2011 (UTC)[reply]

   You're reading something into the proposal that's not there. It basically boils down to 4 cases: (assuming no pre Gregorian source dates are in player)

   1. Article body uses dmy, references use dmy
   2. Article body uses dmy, references use yyyy-mm-dd
   3. Article body uses mdy, references use mdy
   4. Article body uses mdy, references use yyyy-mm-dd

   The choice of dmy or mdy depends on the nationality of the topic and/or the decision of the first author, while the choice to use that format or the ISO-like one is left to first author. --MASEM (t) 12:06, 13 August 2011 (UTC)[reply]

5. Strong support. Logical, professional. Gimmetoo, your predilection seems to be for inconsistency and date formats that you find easy but our readers won't understand. Tony (talk) 12:16, 10 August 2011 (UTC)[reply]
6. Support. I think it's important that inconsistency in dates be eliminated. For example, in the case of 1996-7-4, an inconsistent Wikipedia could cause ambiguity as to whether or not the date was July 4 th or April 7 th. Even if this isn't the order that ends up being used, I support an effort to standardize the smaller things that have the potential to cause confusion, and can only echo Noetica and GFHandel. Tutleman (talk) 18:29, 11 August 2011 (UTC)[reply]
7. Support. As others have said: makes sense, logical, professional. Having ref dates consistent already comes up almost always as a condition for FAC/FLC. I would maybe just suggest toning it down a bit. Copy the line which reads, "Dates in article body text should all have the same format". If some people still think this is too much, you could even add "generally" to the proposed line...? Nightw 11:44, 12 August 2011 (UTC)[reply]
8. We should be using the same date system throughout the entire article, actually, but that's beside the point. I'm just not sure why some people insist on using YYYY-MM-DD in only part of it. Consistency is a minor detail but makes us look more professional in the long run, as opposed to a bunch of different pieces cobbled together. /ƒETCHCOMMS/ 15:39, 12 August 2011 (UTC)[reply]
9. Strong support Regardless of what format the rest of the article is using, all of the references should be using a single format. Ideally, the same format used in the body of the article should be used in the reference list. Using two, three or more date formats in the references alone is unprofessional and sloppy. Imzadi 1979 → 19:37, 12 August 2011 (UTC)[reply]
10. Support. I have no idea how we developed the trend of putting most of the dates in one format and all the access dates in another format. I'd hazard a guess that people only do this because they've seen it elsewhere. It's nonsensical, just as mixing British and American language would be. Any date format is fine, but there's no reason to use more than one within an article. The "Oppose" votes seem to boil down to "Our watchlists will be flooded with ugly edits" which isn't a rationale for leaving the articles in a weird state. Get a bot to do it so you can hide it. —Designate (talk) 06:34, 13 August 2011 (UTC)[reply]
11. Support It’s not about what makes wikipedians happiest (“I get to see my preferred date style salted throughout the bottom of this article!”); it’s about our readership. Consistent date formats within an article are better so consistency should be encouraged. Greg L (talk) 22:28, 14 August 2011 (UTC)[reply]

Oppose

1. Oppose. There is no real problem that needs to be solved. Nothing is wrong with a mix of date formats in the references and notes as long as each date is unambiguous. −Woodstone (talk) 10:21, 7 August 2011 (UTC)[reply]
2. oppose - although I follow the arguments I don't see this as a problem either: the reference sections I've seen look nothing like the above examples and tend to have so much formatting diversity that whether dates are consistent gets lost in the noise. Making this a guideline will lead to a series of trivial and inconsequential edits as editors 'fix' this. And what is the format that should be preferred? It's more than a simple binary like EngVar, there are a number of variations, so it can't be just the one in the majority. How to decide what to change them to? Looking at the article isn't enough as many articles have no dates in them.--JohnBlackburne^words_deeds 00:15, 8 August 2011 (UTC)[reply]
3. oppose - by indiscriminately referring to "yyyy-mm-dd" and "ISO-8601" the passage implies two falsehoods, that these are the same thing, and that Wikipedia has taken a position about the use of ISO-8601 in any part of articles. Jc3s5h (talk) 00:51, 8 August 2011 (UTC)[reply]
4. Oppose. This has been discussed before, and there has never been a consensus to either forbid different ref styles in the text and article (because APA style, for one, does that), nor to forbid putting different types of dates in the references in different styles. OhCon's proposal would result in articles like [4] (97 refs, almost entirely with publication dates in mdy and accessdates in yyyy-mm-dd) becoming [5] (all dates in refs changed to mdy, when AFACT no ref had mdy for both types of dates). These sort of changes are bad. They make it difficult for the article's regular editors to read diffs over the edit, and they make the references themselves harder to parse for at least some people. Gimmetoo (talk) 19:48, 8 August 2011 (UTC)[reply]
   1. Incredibly, OhCon made [6] just recently. Before, the 107 references were nearly all yyyy-mm-dd, but after, everything was changed to mdy. That sort of edit goes contrary not only to the MOS prior to OhCon's "proposal", but is even contrary to OhCon's own proposal here. Gimmetoo (talk) 20:40, 8 August 2011 (UTC)[reply]
      1. Yeah, he does that. This older gem also included a date format change to a quote from a printed source as an extra bonus. Quale (talk) 05:36, 9 August 2011 (UTC)[reply]
5. Oppose Per Woodstone, JohnBlackburne, Gimmetoo, et al. The current section does not lead to any problem, and reflects consensus. Headbomb {talk / contribs / physics / books} 20:55, 8 August 2011 (UTC)[reply]
6. Oppose  I'd go the opposite direction, I'd standardize on yyyy-mm-dd format for access dates, and discourage yyyy-mm-dd format elsewhere in the reference.  Unscintillating (talk) 01:36, 9 August 2011 (UTC)[reply]

   I don't know why you voted 'oppose', because the proposal is much closer to what you want than happens today. It doesn't preclude what you want to see, just does not insist upon it for every single article. The advantage is that all date formats will be consistent in the refs section, and they might just all be yyyy-mm-dd. --Ohconfucius ^¡digame! 12:31, 12 August 2011 (UTC)[reply]

   The proposal reads, "all dates in the reference sections are uniformly consistent".  I'm opposed to a consistency that in fact makes it harder to tell the difference between the access date and the publication date.  The access date is information about the citation rather than being a part of the citation itself.  For readability, I would prefer that access dates always use yyyy-mm-dd, and that publication dates never use yyyy-mm-dd.  Unscintillating (talk) 10:42, 13 August 2011 (UTC)[reply]

7. Oppose Proposal lacks guideline for a procedure for deciding what format to use when dates are not consistent. Existing scripts are being used to just remove yyyy-mm-dd whenever there is any discrepancy in date format, ignoring WP:DATERET. Proposer's script talk page says:

   "While I will do my best to comply with the minute detail of style guidelines, I will work with what is on the face of the article, and will target articles where I detect a misalignment of formats by a quick scan. I am unlikely, for reasons of productivity, to comb through each article's history to establish whether an article should be dmy or mdy, or whether a the first date included in a reference section was yyyy-mm-dd or not. If you want articles on your watchlist to retain any given format (or for it to have all yyyy-mm-dd dates in the accessdate field), you should ensure that the all of dates are in aligned in accordance with WP:MOSNUM, otherwise I consider them 'fair game'."

   YYYY-MM-DD is one of the three date formats used in Canada, as a Canadian I do not want it obliterated from wikipedia, and this proposal (+ scripts) seems to be a backdoor way of doing that. In the event that this proposal receives community support, no action should be taken on it without first obtaining agreement on a decision procedure in cases of inconsistency. --JimWae (talk) 09:02, 13 August 2011 (UTC)[reply]

8. I'd go with: The main article text, excluding tables, lists, and the section References, should use either 13 August 2011 or August 13, 2011, consistently; the section References, excluding access dates, should use either the format of the rest of the article or the same format with abbreviated months^{[Note 1]} consistently; access dates should use either the format of the rest of the section References or 2011-08-13 consistently. Each table/list should be handled on a per-case basis depending on column width, sortability etc. using the main article text format, the same with abbreviated months, or (provided all dates are Gregorian in the 1583–9999 ranges) 2011-08-13 (but don't mix them in the same table column). ― A. di M.​_plé​^dréachtaí 14:27, 13 August 2011 (UTC)[reply]
9. And stop changing articles with scripts. -- Jeandré, 2011-08-14t11:06z

   This is a request for comment. I don't think your entry can be taken seriously, since it contains only a veiled personal attack. Thank you. Tony (talk) 11:17, 14 August 2011 (UTC)[reply]

   Apologies if it looks like an attack, that wasn't my intention. I meant that I oppose the proposal, as explained on the linked talk page, and that date changes should not be done with scripts. -- Jeandré, 2011-08-15t12:50z

10. Bad idea. I'm not sure even the unification in the current guideline is appropriate. It would make sense for publication dates of weekly magazines, weekly newspapers, or daily newspapers to be MDY for US sources and DMY for UK sources (or with the abbreviations suggested by User:A. di M.. The access date format (and archive date format) should be consistently (1) the article date format, (2) the date format appropriate to the reference, or (3) YYYY-MM-DD. — Arthur Rubin (talk) 23:50, 14 August 2011 (UTC)[reply]

    I don't get... are you suggesting that for any given article, that publication dates for all US sources take up the mdy format while if there are citations to The Times or The Guardian that they be in dmy? --Ohconfucius ^¡digame! 03:36, 15 August 2011 (UTC)[reply]

    It seems to me to be a preferable style, but certainly should be an acceptable style; the format of the publication date (if dmy or mdy; my is the same in either case) should be set by the publication. — Arthur Rubin (talk) 18:23, 15 August 2011 (UTC)[reply]

11. Oppose - Don't think inconsistent date formats within the reference section are a problem. Especially accessdate versus publication date. Rlendog (talk) 15:32, 15 August 2011 (UTC)[reply]

Notes

Neutral

Discussion

• I notice you still have not reverted your change. Anyway, I reject your point #2 and also #3,4,5. You claim a mix of date formats is "asthetically displeasing and difficult to parse". For you, a "mix of formats" includes a reference section where all the publication dates are one format and all the accessdates are another - a quite common format on Wikipedia. So apparently, there are other people who do not find it "aesthetically displeasing". Likewise, when different types of information is represented in different formats, I would expect at least some people would find that easier to parse. And that is why publication and access dates are treated differently by some editors, and why we have to point this out during past attempts to change the guideline. But I don't need to convince you; you need to convince everyone else. You're the one making the change. Gimmetoo (talk) 09:34, 7 August 2011 (UTC)[reply]
  • I am not saying the yyyy-mm-dd format is uncommon; I say having such a mix makes the dates more difficult to parse. I am proposing that they should be a single format for all dates. --Ohconfucius ^¡digame! 09:48, 7 August 2011 (UTC)[reply]
• To the question of what format should be preferred, it should fall to standard of "first editor choice" as with nearly all other choices of which format to us. I would argue that if the article is tied to a specific nationality and thus has chosen to use US or Int-style dates in the body, then the opposite should be avoided in the reference text. --MASEM (t) 13:50, 8 August 2011 (UTC)[reply]

• The newly revised description of the background to the issue states "the guideline permits the use of up to two different formats in the reference section in various permutations". No. The guideline before Ohconfucius' bold change stated "Publication dates in article references should all have the same format." (An exception for archive and access dates followed.) This wording prevents a conflict with WP:CITE, which allows any citation format, and specifically mentions APA style, which uses YYYY, Mmmm DD for publication dates in the bibliography. Jc3s5h (talk) 15:01, 12 August 2011 (UTC)[reply]
  • I've been watching this page and am unaware that it had been changed. The state of affairs I mentioned above is attested to by this thread. --Ohconfucius ^¡digame! 15:28, 12 August 2011 (UTC)[reply]

• OK, now I see what you mean; any particular reference section may have up to two date formats, but collectively throughout all the guidelines-compliant articles in the encyclopedia, there may be many date formats, depending on which citation style was followed in each article. Theoretically there could be a citation style that calls for three different date formats, but that seems very unlikely. Jc3s5h (talk) 15:41, 12 August 2011 (UTC)[reply]

Suggested modification

I suggest modifying one bullet and adding a new one; additons are underlined:

Also, change all instances of ISO 8601 to yyyy-mm-dd.

Jc3s5h (talk) 22:26, 7 August 2011 (UTC), modified 23:57 UT[reply]

In answer to a question posed on my talk page, "the format specified in any style guide the reference section follows", the MOS does not address itself to references, except to refer to WP:CITE. That guideline indicates any style may be used for citations. At least one citation style, APA style, calls for one format in the body of articles (Mmmm DD, YYYY,) but a different format in the citations (YYYY, Mmmm DD). To disallow following an external style guide in the reference section would place this guideline in conflict with WP:CITE. Jc3s5h (talk) 01:45, 8 August 2011 (UTC)[reply]

• Still unsure. You seem to suggest allowing YYYY, Mmmm DD in the refs section, and not to do so would violate WP:CITE. While it is theoretically allowed, I have come across such use in less than a handful of articles, and even so, only one or two instances in each article. I have seen more instances of erroneously used formats – like 18-1-99, 18-1-1999, 18-01-1999, 18-Jan-1999 – than this, so I believe it is quite moot in practice. --Ohconfucius ^¡digame! 03:23, 8 August 2011 (UTC)--Ohconfucius ^¡digame! 03:23, 8 August 2011 (UTC)[reply]

I don't see how the second bullet point above can be enforced. Some countries use the Revised Julian calendar, which is identical to the Gregorian calendar from 1 March 1600 until at least 28 February 2400.

Isn't ISO 8601 itself unenforceable because some countries object to having the Gregorian calendar rammed down their throats when they have rejected it for something better? 92.24.110.78 (talk) 10:23, 8 August 2011 (UTC)[reply]

On further consideration, I withdraw my suggestion and instead offer a counter-proposal below. Jc3s5h (talk) 21:33, 8 August 2011 (UTC)[reply]

Counter-proposal

I suggest removing the text currently in the guideline:

• Except for titles and quotations, dates in each article's reference section should all have the same format, which may be the format prevailing in the body, or yyyy-mm-dd:

Correct	Incorrect
Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009	Jones, J. (20 September 2008) ... Retrieved 5 Feb 2009 Jones, J. (20 Sep 2008) ... Retrieved Feb 5, 2009
Jones, J. (20 September 2008) ... Retrieved 5 February 2009	Jones, J. (20 September 2008) ... Retrieved February 5, 2009
Jones, J. (2008-09-20) ... Retrieved 2009-02-05.	Jones, J. (20 Sep 2008) ... Retrieved 2009-02-05 Jones, J. (2008-09-20) ... Retrieved 5 February 2009

I would replace it with the following:

• As with all style issues concerning citations, see Citing sources.

Also, I would add a statement to "Citing sources" that all-numeric date formats in which the first element represents the day or month should not be used, regardless of any recommendation in an external style guide, and any article currently using such a system should be corrected. Jc3s5h (talk) 21:41, 8 August 2011 (UTC)[reply]

• Initial reaction: I'm not aware nor am I particularly interested in how the two guidelines evolved, but there's definitely a lot more than dynamic tension here. Wikipedia ought to have a house style for citations, and we should only be referring to external guidelines where we don't have one of our own. And when there is a house style, which we seem to have (more or less), we ought to marginalise external guidelines. The tolerance of other styles in WP:CITE appears counter-intuitive to me, and a recipe for a 'free for all'. The disadvantage, of course, is that same external guidelines are usually inaccessible to a majority of editors, as opposed to wide and full availability for in-house guidelines, thus imperfect information as to how they are to be interpreted and used. Arguments cannot be easily resolved by reference to same (due to said unavailability), thus enforcing the tendency to WP:OWN in some cases. --Ohconfucius ^¡digame! 02:02, 9 August 2011 (UTC)[reply]

• There are arguments for and against a house style, but adopting my counter-proposal would not promote or retard a house style, it would just prevent conflict between this guideline and WP:CITE. Jc3s5h (talk) 12:42, 9 August 2011 (UTC)[reply]

• Over here we have endless trouble with some printouts using d/m/y and others m/d/y. There should be a common standard - preferably d/m/y because it leads to the only sensible way of expressing time: time/d/m/y. 92.24.110.78 (talk) 11:36, 15 August 2011 (UTC)[reply]

Looking again at Jc's counter proposal, he says "all - numeric date formats in which the first element represents the day or month should not be used", i.e. the year must come first. So 99.9999% of all dates in Wikipedia would have to be changed. 92.24.110.78 (talk) 11:50, 15 August 2011 (UTC)[reply]

That's just wrong. Only 1-2-2003 (or 2/1/03) would be forbidden. 1 February 2003 or February 1, 2003 would not be restricted by that phrasing. — Arthur Rubin (talk) 18:34, 15 August 2011 (UTC)[reply]

The template {{times}} is now available, to display a typographically correct 'times' character (× in HTML); for eample 4{{times}}100m relay renders as 4×100m relay. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:11, 6 August 2011 (UTC)[reply]

What's the point? It's in the edit box. JIMp _talk·cont 01:55, 8 August 2011 (UTC)[reply]

Not only that, but &times; is fewer keystrokes. 76.113.124.50 (talk) 04:53, 8 August 2011 (UTC)[reply]

It's up for deletion. JIMp _talk·cont 05:50, 8 August 2011 (UTC)[reply]

The point is improved readability for novice editors and others not familiar with HTML. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:15, 8 August 2011 (UTC)[reply]

Use the tool box below. "2 × 2" is easier to read than either "2 {{times}} 2" or "2 × 2". JIMp _talk·cont 02:12, 9 August 2011 (UTC)[reply]

How do non-mouse users do that? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:16, 9 August 2011 (UTC)[reply]

Using the Tab button, yes, it's easier to type {{times}} than hit Tab umteen times but are mouseless users (who can't manage × either) that significant a group of people that we need this? JIMp _talk·cont 10:28, 10 August 2011 (UTC)[reply]

Yes. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits

No. Headbomb {talk / contribs / physics / books} 23:48, 11 August 2011 (UTC)[reply]

Please explain why blind Wikipedia editors (for example) are not "significant". Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:16, 12 August 2011 (UTC)[reply]

Please explain why blind Wikipedia editors (for example) would find {{times}} any easier than &times;. ― A. di M.​_plé​^dréachtaí 15:01, 12 August 2011 (UTC)[reply]

For the same reason, given above, as sighted people. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:23, 12 August 2011 (UTC)[reply]

I can't find one, unless you count merely asserting that it “improve[s] readability for novice editors and others not familiar with HTML” as a reason why it does. ― A. di M.​_plé​^dréachtaí 22:53, 12 August 2011 (UTC)[reply]

What? Is the set of people who can't manage × but can {{times}} even non-empty? ― A. di M.​_plé​^dréachtaí 00:30, 12 August 2011 (UTC)[reply]

For a value of "manage" which means "never heard of" or "can't remember"; yes. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:16, 12 August 2011 (UTC)[reply]

How the hell are they supposed to have heard of {{times}} before? ― A. di M.​_plé​^dréachtaí 14:58, 12 August 2011 (UTC)[reply]

Where did I say they were? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:23, 12 August 2011 (UTC)[reply]

Strictly speaking, you said that you manage something if you never heard of it or can't remember. Since that is absurd, you probably meant the opposite. But translating from mathematics, that does imply that some people have heard of {{times}} but not &times;. That is also absurd since you just invented {{times}}, so what you really really meant is that people have heard of templates but not HTML. In my case, I had heard of neither before Wikipedia, but I had at least seen HTML without knowing what it was called. Both templates and HTML are widespread throughout Wikipedia. Art LaPella (talk) 18:25, 12 August 2011 (UTC)[reply]

My brain must have auto-corrected the misnegation because I didn't even notice it. The part from “But translating” to “invented {{times}}” in your comment is exactly what I was thinking of. Anyway, even having “heard of templates” is not enough; you must have heard of templates which expand to one single character, which is not their most typical usage. Conversely, whoever is familiar with HTML entities (whether or not they know they're called “HTML entities”) knows what they do, and even if they haven't encountered a particular one (say, &infin;) they'll be likely able to guess what it stands for. ― A. di M.​_plé​^dréachtaí 22:53, 12 August 2011 (UTC)[reply]

BTW, your tabbing method doesn't work (in Chrome, at least). Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:17, 12 August 2011 (UTC)[reply]

I have observed a number of editors convert date ranges in the form "1990 to 1991" to 1990–1991, claiming that WP:DATESNO requires that all date ranges use an endash. Specifically, the form "1990 to 1991" is used in some tables where an endash in a date range impedes sorting. Is this a case where the MOS requires a particular form even if it results in broken functionality? Or may date ranges be written in other ways (excluding a hyphen)? Gimmetoo (talk) 21:39, 6 August 2011 (UTC)[reply]

Small correction on the above. It impedes sortability on an outdated browser used by 0.07% users. Nymf _hideliho! 21:46, 6 August 2011 (UTC)[reply]

Hi, Gimmetoo. I just tested this out, and the table sorts properly with the endashes, which do not impede the sorting whatsoever. I am using Firefox, version 5 --Dianna (talk) 21:49, 6 August 2011 (UTC)[reply]

So, because in the browser you happen to use, it may work OK, that's enough reason for you to make a function behave incorrectly in another browser that other readers might use? My request for clarification here is directly prompted by your claim [7] that the MOS requires that form. If so, then we may need to either change the MOS or find another solution to this issue. It's a ACCESSibility issue, afterall - something you ought to know quite well, right, Diannaa? And Nymf, I think you mis-stated that stat by a factor of 5 to 10. Gimmetoo (talk) 22:00, 6 August 2011 (UTC)[reply]

For people previously uninvolved, here's some background information on the issue of dashes/sorting:

• User talk:Gimmetoo#Edit warring
• User talk:Gimmetoo#Sortable tables
• Talk:Yvonne Strahovski#Sortable table
• Wikipedia:Administrators' noticeboard/IncidentArchive641#RexxS behaviour
• User:Boing! said Zebedee/Sandbox/RFC
• User:RexxS/Sorting

Nymf _hideliho! 22:23, 6 August 2011 (UTC)[reply]

Mostly beside the point here, which is a MOS question. In short summary - it is indisputable that there is an issue with endashes, sortable tables, and Safari 4. The only debatable issue on that front is whether the technical issue and user base justifies a fix. But the only issue in this clarification request is whether one particular fix is forbidden by the MOS. That is all. Gimmetoo (talk) 22:29, 6 August 2011 (UTC)[reply]

I don't understand a MoS objection (not a Safari 4 vs. the world objection, but a strictly MoS objection) to "1990 to 1991". The relevant DATESNO guideline is "If a date range is abbreviated, use the formats 5–7 January 1979 or January 5–7, 1979". If it were intended to outlaw "1990 to 1991", then why doesn't it say "In a date range, use the formats ..."? What does "abbreviated" mean if it isn't intended to exclude "1990 to 1991"? Art LaPella (talk) 23:32, 6 August 2011 (UTC)[reply]

The manual calls for endashes: "Year ranges, like all ranges, are normally separated by an en dash ..." The only exception I can see is where a preposition is used, such as in a phrase like "from 1881 to 1886". I think "abbreviated", in this instance, means that the preposition has been eliminated. Obviously the tables do not use prepositions, so en dashes should be used. That's my reasoning --Dianna (talk) 00:01, 7 August 2011 (UTC)[reply]

MOS:ENDASH describes the role of the endash primarily to distinguish from the hyphen. I agree with Art that it never meant to say that there's aren't situations where using the word "to" is appropriate. You need to decide what works best in the context. I am not aware of technical issues with en dashes, but if there are some, then this would be a potential workaround. Dicklyon (talk) 00:11, 7 August 2011 (UTC)[reply]

Perhaps he means WP:YEAR, where the "Year ranges ..." quote occurs, instead of MOS:ENDASH. Art LaPella (talk) 04:14, 7 August 2011 (UTC)[reply]

• Support endash. Use the {{Hs}} template to get sorting working in all browsers. GFHandel ♬  07:53, 7 August 2011 (UTC)[reply]
  • It seems that this is quite a complicated/cumbersome way of making dates sortable in tables. If yyyy-mm-yy date format is not used, what advantages does this template's usage have over simply using template such as {{date}}, {{date sortable}} or {{start date}} (e.g. {{start date|yyyy|mm|dd|df=y}}), which would allow for output in a number of date formats? --Ohconfucius ^¡digame! 09:25, 7 August 2011 (UTC)[reply]

The problem with this solution is that adding templates to a page increases the load time of a page. Filmography tables have a lot of dates in them and thus a lot of templates would be required. --Dianna (talk) 13:11, 7 August 2011 (UTC)[reply]

• Just use a proper endash (–). It works on all commonly used browsers. Use of buggy old browsers that are barely in use will only decline. The endash use is common and deviations should be fixed. --168.122.165.145 (talk) 18:57, 8 August 2011 (UTC)[reply]
  • Again, I must reiterate the focus of this question. This is a MOS page, and the only issue on point is whether or not the MOS forbids writing "1995 to 1996" and requires "1995–1996". Everything else is distraction. Gimmetoo (talk) 19:02, 8 August 2011 (UTC)[reply]
    • Fine; it should be clarified that the endashes *should* be used and that /your/ 'to' should not. --168.122.165.145 (talk) 19:06, 8 August 2011 (UTC)[reply]

This website shows all versions of Safari accounting for 5.17% of users in July 2011. Of this, Safari 5 accounts for 3.52%, leaving only 1.65% of Internet traffic is using all other versions of Safari. It hardly seems worth our while to convert our filmography tables to a style that does not follow our own Manual of Style to accommodate such a tiny percentage of internet traffic; Safari 4 came out two years ago and even Safari 5 is over a year old and is being replaced with 5.1. This stuff is little used, and Safari 4 is obsolete, antique in internet terms.--Dianna (talk) 22:31, 8 August 2011 (UTC)[reply]

Yep. Even Google is dropping support for Internet Explorer 7 and Safari 3, for example. Browsers that account for 9% of the browser market according to the news article, essentially forcing people to upgrade. I suspect Safari 4 is next. And a small note in this whole issue with dashes: Safari 4.0 has the bug. The free 4.1 update doesn't! Nymf _hideliho! 18:18, 9 August 2011 (UTC)[reply]

Are you saying that Google's practice is WP policy? Or that it should be? Would you support dropping support for browsers 2 versions old? What about 1 version old? What about current browsers, if they have less than 10% share? Would you say WP should just design the entire site around whichever one browser happens to have the largest browser share at the time, and add a "Best viewed in Browser 6.7" site notice? Gimmetoo (talk) 01:21, 11 August 2011 (UTC)[reply]

Request for comments: Sortable tables and Safari 4

I tried to just ask the MOS question here, but people keep bringing in other issues. So here is an overview of the problem and solutions identified so far.

• There is an issue with Safari 4, sortable tables, and sortable elements that contain dashes. When a reader using Safari 4 clicks the sort button on a sortable table, items with dashes do not end up in the right spot. They either get grouped together at the end, or appear in other places out-of-order in the list. This became an issue about a year ago when a number of filmographies were changed to be sortable, and many filmography tables have year ranges with dashes. The prior version of these tables was not sortable, so the Safari 4 issue was irrelevant. Readers using Safari 4 account for at most 1.65% of WP pageviews. (The last time I added up the various affected versions of Safari 4, I got about 0.7% of WP pageviews - using statistics from WP, not general web stats.)

There are a number of ways to deal with this issue. Some of them are:

1. Do nothing - the issue will go away in a few years as readers change browsers, but until then some subset of readers would be confused by this feature
2. Replace the dashes with hyphens - but bots would replace the hyphens with dashes unless reprogrammed
3. Replace the dashes with the word "to" - the main objection seems to be that this is contrary to the MOS
4. Add a sortkey to the columns affects - for this to work the sortkey must be added to every element to be sorted - just adding it to the elements with dashes was not sufficient to fix the issue in prior testing
5. Restructure the table to use years and avoid year ranges - typically this means putting date range info in a "note" column
6. Remove the "sortable" feature as broken, at least for now

So I would like answers to a few questions:

1. Do you think any fix for this issue is justified or warranted?
2. If so, what approach or approaches do you think would be appropriate?
3. Which of the approaches listed above are contrary to Wikipedia policies?
4. Under what circumstances would it be appropriate to actively impede other editors who attempt to fix this issue?

Comments below. Gimmetoo (talk) 01:31, 10 August 2011 (UTC)[reply]

Comments

I believe the user base is large enough to justify some form of fix. I don't think it's appropriate to intentionally make a technical feature misbehave for a significant subset of readers when there are very simple fixes available. To my recollection, WP has supported browsers up to 5 years old. Among the options listed, most editors who are familiar with the issue think the templated sortkey approach is too complex for the scope of this issue. I tend to agree, since much simpler fixes are available. I think the "to" option is appropriately simple for the scope of this issue. (Even if it were against the MOS - and I don't agree it is - I think this would justify a MOS exception.) I'm also fine with a different table structure that avoids the issue, or with reverting to the non-sortable form of the table. Gimmetoo (talk) 01:31, 10 August 2011 (UTC)[reply]

The usage of Safari 4.0 is trivial and will be effectively zero in next to no time, certainly before a significant number of /fixes/ could be deployed. Removing sorting functionality, as Gimmetoo has done, over this tiny issue with a tiny number of readers is flat-out disruptive. I'm amazed at the insistent argumentation over this non-issue. I noticed an odd 'to' in a date range and looked at why, and days later, the insipid argument continues. Use normal endashes and any common browser and all is fine. --168.122.165.145 (talk) 02:23, 10 August 2011 (UTC)[reply]

Support dashes. Gimmetoo, you appear to have taken on a dynamic push to stop WP from continually adapting, and to underpin your arguments by appealing to the notion that fringe or out-dated OSs be the benchmark. Please lighten up. Tony (talk) 02:34, 11 August 2011 (UTC)[reply]

I just want to understand what you're saying. By "support dashes", you mean to say that year ranges must always be written with dashes, never with "to"? Is that correct? Gimmetoo (talk) 03:18, 11 August 2011 (UTC)[reply]

I am neutral on 'endash' vs 'to' whenever it is in prose; I feel that when it comes to tables, it should be endashes between two dates. --Ohconfucius ^¡digame! 04:38, 11 August 2011 (UTC)[reply]

Support the use of en-dashes in tables. Sometimes I spell it out with words in prose, as permitted by the MoS. --Dianna (talk) 04:47, 11 August 2011 (UTC)[reply]

The word to for date ranges is obviously allowed in prose. It's not forbidden to use to in tables, but it's certainly the less common choice. —Designate (talk) 16:49, 14 August 2011 (UTC)[reply]

I recently came across a fine example of what I like to call "misconversions". The Gallons per mile section of Fuel economy in automobiles used to read as follows (with a minor typo fixed, the reference removed and the {{convert}} call written out explicitely).

For example, replacing a car that gets 14 mpg_-US (17 mpg_-imp; 17 L/100 km) with a car that gets 25 mpg_-US (30 mpg_-imp; 9.4 L/100 km) saves 3 US gallons (2.5 imp gal; 11 L) of fuel every 100 miles (160 km). Because 1 US gallon (0.83 imp gal; 3.8 L) of fuel emits 20 pounds (9.1 kg) of carbon dioxide, saving 3 US gallons (11 L) of fuel every 100 miles (160 km) saves 3 short tons (2.7 t) of carbon dioxide every 10,000 miles (16,000 km) of driving.

I took a look at this through a couple of "filters". Firstly my imperial filter yeilded this.

For example, replacing a car that gets 17 mpg_-imp with a car that gets 30 mpg_-imp saves 2.5 imp gal of fuel every 100 miles. Because 0.83 imperial gallon of fuel emits 20 pounds of carbon dioxide, saving 2.5 imperial gallons of fuel every 100 miles saves ??? of carbon dioxide every 10,000 miles of driving.

It made me wonder what kind of measure 20 pounds of carbon dioxide per 0.83 imperial gal was. 20 pounds per 0.83 imperial gallon. What fancy number is 0.83?

Then I tried on my metric filter. Here's what I got.

For example, replacing a car that uses 17 L/100 km with a car that uses 9.4 L/100 km saves 11 litres of fuel every 160 kilometres. Because 3.8 litres of fuel emits 9.1 kilograms of carbon dioxide, saving 11 litres of fuel every 160 kilometres saves 2.7 tonnes of carbon dioxide every 16,000 kilometres of driving.

"Wow!" though I. Even more fancy numbers. 11 litres per 160 kilometres times 9.1 kilograms per 3.8 litres equals 2.7 tonnes per 16,000 kilometres. Now, I'm feeling much enlightened. 'Cause here in metricland we always measure things by the 3.8 litre and the 1.6 kilometre.

Another thing we tend to to, here in metricland, is measure food energy density in kilojoules per 450 grams. For example, I like to eat Foobars but I'm getting fat because they contain 420 kJ (100 Cal) per 450 grams (1 lb). I also drink Foozypop which contains 630 kJ (150 Cal) per 355 ml (12 US fl oz).

Well, I rewrote the example to give litres per 100 kilometres, pounds per imperial gallon, kilograms per litre, long tons per 10,000 miles and tonnes per 10,000 kilometres. I also tweaked the numbers for accuracy, tweaked the wording for flow and came up with this.

For example, replacing a car that gets 16 mpg_-US (19 mpg_-imp or 15 L/100 km) with a car that gets 30 mpg_-US (36 mpg_-imp or 8 L/100 km) saves 3 US gallons (2.5 imp gal) of fuel every 100 miles (7 L/100 km). Because the combustion of 1 US gallon of fuel emits 20 pounds of carbon dioxide (burning 1 imp gal emits 24 lb and burning 1 L emits 2.4 kg), this saves 3 short tons (2.7 long tons) of carbon dioxide every 10,000 miles (1.7 t every 10,000 km) of driving.

This might well be the worst I've see but it's not the first. I wonder whether it's worth adding guidance regarding the conversion of such ratios imbedded in text. Converting the ratio as a whole rather than converting its parts individually seems such common sense to me but I guess it's not so for everyone. What might be a good way to phrase it? JIMp _talk·cont 10:19, 7 August 2011 (UTC)[reply]

I think guidance can:

• document the outcome of a dispute that may reoccur
• define how to fix a common and significant problem that wouldn't be fixed by the wiki
• make a difference to what editors actually do

Unfortunately, I think guidance on this issue would fail on the last bullet. Lightmouse (talk) 18:39, 15 August 2011 (UTC)[reply]

I think you're probably right. JIMp _talk·cont 02:55, 16 August 2011 (UTC)[reply]

At present, the following is given: A closing CE or AD year is normally written with two digits (1881–86) unless it is in a different century from that of the opening year, in which case the full closing year is given (1881–1986). Given that I have never seen this requirement in academic works, in fact, the opposite exists, years are normally expressed in full. FWiW Bzuk (talk) 17:46, 11 August 2011 (UTC).[reply]

This also applies to this paragraph: "Year ranges, like all ranges, are normally separated by an en dash, not a hyphen or slash: 2005–06 is a two-year range, whereas 2005/06 is a period of twelve months or less, such as a sports season or a financial year."

In my opinion, years should always be expressed in full, that is, with four digits (no leading zeros) for years after year 999. This is in accordance with "Write out the full year string instead of using the apostrophe (') to abbreviate the first two digits of the year."

A form such as "2005–06" is highly conflictive, since this is also a valid form in the international date format according to ISO 8601, which is the more or less "official" standard date format in many European countries. Many people would simply interpret this as "June 2005", not as "2005–2006". While this cannot happen with "1881–86", it looks odd (to me) and is in conflict with the rule to express years in full. We should change that accordingly. --Matthiaspaul (talk) 10:38, 12 August 2011 (UTC)[reply]

As an aside the bit you quote is not what happens in practice as sports seasons use the en-dash and not the slash as implied by the quote. Keith D (talk) 11:38, 12 August 2011 (UTC)[reply]

I agree that date ranges should be written in full, especially given the potential for confusion with ISO 8601 dates. I'm frankly surprised we don't already recommend this. Kaldari (talk) 16:00, 12 August 2011 (UTC)[reply]

Two digits are definitely preferable in most AD/CE instances. Tony (talk) 10:29, 16 August 2011 (UTC)[reply]

Please see WT:CITE#Which Wikipedia guideline(s) should establish citation format? Jc3s5h (talk) 16:59, 13 August 2011 (UTC)[reply]

Where it's being asserted, indirectly, that the advice on this page under Full date formatting insofar as it refers to references, does not represent current consensus. Does anyone have anything to say about that?--Kotniski (talk) 18:16, 13 August 2011 (UTC)[reply]