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

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Colleagues, I've never been completely confident about the decimal-point consistency thing. I've raised it

The first is a clear case of false precision. JIMp _talk·cont 14:10, 8 July 2011 (UTC)

Yep. I might say something like "(about 1.5 to 4.5 inches)" and "(roughly half an inch)", and invite improvements in the edit summary. Wtmitchell (talk) (earlier Boracay Bill) 00:05, 9 July 2011 (UTC)

The article

Hemispheres}} suggests all lowercase (but the first letter is uppercase due to the template format). I suggest Wikipedia make a specific recommendation for the capitalizations of all four hemispheres to avoid edit wars (such as the ones for "The Beatles" vs. "the Beatles"). I suggest all lowercase. CuriousEric

20:36, 10 July 2011 (UTC)

The OED uses all lower-case letters so it seems that it the usual format. McLerristarr | Mclay1 04:29, 11 July 2011 (UTC)

I know we discussed year ranges, but what about page ranges and such? Do we drop digits, or not? Dicklyon (talk) 04:10, 11 July 2011 (UTC)

Many do, many don't. I hate dropping numbers in page ranges, others are fine with it. Basically stick with the dominant style of the article.

books

} 05:33, 11 July 2011 (UTC)

OK. Usually I don't see digits dropped, but an editor has been going around pruning out digits and calling it "cleanup"; I reverted some of those and advised him not to. Dicklyon (talk) 06:50, 11 July 2011 (UTC)

I have recently been made aware of some ambiguity in date formatting. Last night I ran across a proposal to make changes to the MOS on date formatting, but it did not appear to pass for lack of consensus. I have searched through the archives, but I cannot find any references to this question below. Maybe I did not search well enough, or maybe it is not there. I presume there are likely a number of editors who are passionate about this topic and can point directly to the thread.

In the section for

Here are the points I think need some clarification:

• The term reference format is not defined anywhere on this page. For new editors that can add to this confusion. An example like what is shown after that term YYYY-MM-DD is very clear.

> If it means how the reference lists the date, that would violate

MOS:DATEUNIFY

as not every source is likely to be the same.

> If it means how the entry is formatted listing the date of the article in the reference, then it should say that somewhere.

• The list of examples does not identify if Jones, J. (Sept 20, 2008)...Retrieved February 5, 2009 is acceptable or not. I assume it is, but I think some people may be confused this is not acceptable since it is not listed.

• The list of examples does not identify if Jones, J. (2008-09-20)...Retrieved 2008-09-20 is acceptable or not. I think some people may be confused this is not acceptable since it is not listed.

• The template Cite web instructions shows in sections 1.1 and 1.2 the examples for |accessdate=July 11, 2011 and |accessdate=11 July 2011 and then in the Examples section it only shows |accessdate=11 July 2011 format. There is no example or indication that YYYY-MM-DD is possible. Maybe that is controlled by the MOS. Maybe it should say that to be clear or point to the MOS section for clarification.

By looking at the prior MOSNUM debate linked above, I assume I will get a flood of replies to this question that says we cannot improve Wikipedia by making a decision on this topic. That is unfortunate for the readers. § Music Sorter § (talk) 08:50, 11 July 2011 (UTC)

"Reference format" is "the format used by references". Aka what is in the Reference section.

books

} 14:40, 11 July 2011 (UTC)

I think the way this has generally been understood, and which is not quite what the MOSNUM currently states, is that there are three groups of dates in the reference section:

1. Quotes, titles, proper names, etc., which must match the format in the source without respect to any other rule
2. Access dates, a.k.a. retrieval dates, which may follow the format of the group below, or may use the YYYY-MM-DD format, but which should be consistent among themselves. Since these are used for retrieval of sources in electronic form, issues with ancient dates cannot arise.
3. Other dates normally encountered in bibliographies, principally publication dates; these may follow the format of the article text, follow the format of the style guide used for the reference list, be a shortened form of the article text format (e.g. "4 Jul 2011" in an article that would use "4 July 2011" in the article text), or may follow the YYYY-MM-DD format. This entire group should be consistent within the group. Jc3s5h (talk) 15:33, 11 July 2011 (UTC)

• The examples actually confuse. From my understanding, only one format is acceptable within the body of text; two formats may currently coexist within reference sections – yyyy-mm-dd and one other. Then there are the abbreviations for dmy dates or mdy date which ostensibly ought not to coexist with their longhand versions. So while we can expect to see "|date =2010-11-31" and "|accessdate =1997-07-18" in reference sections under current guidelines, we ought not to to see 13 January 2011 and 31 Jan. 2011 within the same section. The examples seem to suggest it but do not make it adequately clear. The current disposition is in effect that we allow two date formats within the same citation. The wording also apparently allows the nonsensical situation where dmy dates may be used within the body and mdy dates used in the reference section (or vice versa). I feel that uniformity of date formats within reference section would be more aesthetically pleasing than what we have today; it would also be easier to maintain going forwards. Whilst I would have no problem in principle to seeing exclusively ISO 8601 (or yyyy-mm-dd) dates or mdy or dmy dates within reference sections, I also would have no problem in principle to seeing 13 January 2011 and 31 Jan. 2011 within the same section. In reality, that happens all too frequently but does not cause brain-freeze. The current state of affairs is not easy to explain – the number of formats and fields means there are a greater number of theoretical permutations to consider. That difficulty to understand makes it hard to implement. The mix of formats in the refs section also causes most brains to pause and require perhaps that extra split second to parse. The guideline should therefore seek to disallow dmy dates within the body and mdy dates within the reference section and limit the reference section to one format, yyyy-mm-dd or one of the others, depending on what is already used in the body. --Ohconfucius ^¡digame! 15:50, 11 July 2011 (UTC)

• An additional exception is if the references follow a published style guide, in which case the dates would be formatted however the style guide specifies, without respect to what is used in the article text. This is a consequence of the English Wikipedia's decision to create a MOS that only applies to the article text, not the citation system. Jc3s5h (talk) 16:13, 11 July 2011 (UTC)

• I think you meant something like "a MOS that only applies to the article text for dates". I don't think you meant that I shouldn't apply MOS to citation problems like inserting a dash into "pp. 14-17", or an nbsp into a book title like Thoughts on World War II. Art LaPella (talk) 20:54, 11 July 2011 (UTC)
• The MOS plainly allows any citation style. If a citation style has been adopted for a particular article, it should be followed in as much detail as the citation manual gives. (In theory, a style made up just for that article is allowed, but in practice, there would not be enough examples to know what to do when adding a new source, because of the wide diversity of sources that exist.) For areas where the citation manual is silent, there is no guidance in MOS about what to do. I would make the citations consistent with the rest of the article, or apply the MOS for these unspecified areas. Jc3s5h (talk) 22:04, 11 July 2011 (UTC)

• Jc3: Can I assume by your not refuting my observation that the guideline is not clear and is thus potentially problematic in the respects that I mentioned? Currently, the standard of date consistency appears to apply only to
  Featured Articles. While there is consensus that dates within quotes and titles should not be changed, I hope that 'rule' about following an external style guide is not something you imagined or want to apply, for there doesn't seem to be any such "exemption" explicit in MOSNUM. People already have problems following our own style guide. having reference to an external style guide that few would have free access to seems unreasonable. You also say that MOS only applies to the article text and not the citation system – this seems to conflict with the existence of examples listed (those in the quote box above). In any event, why would such "exemption" not be prominently noted somewhere within the guideline, if this were the case? Do you have a link to that authority? If this truly were the case, the community wouldn't frown upon date formats such as dd-mm-yyyy or mm/dd/yyyy which are used in the outside world but that we consider ambiguous.

  Also, I am one of a small handful of editors who work to keep date formats consistent within articles and across some article categories. This job is too tedious to perform manually on the scale that is required to ensure orderliness. Our task is rendered complicated by not stipulating the uniformity of dates in refs section (exceptions I noted aside). The consequence is that those of us who maintain dates either avoid aligning dates (in refs section) due to the complexity, or run the risk of complaints from those who want to see yyyy-mm-dd formats retained but do not ensure that articles 'under their wing' are compliant, the mix of many dates in reference sections will proliferate due to organic nature of growth of articles. I do not recall hearing any cogent argument why we must restrict yyyy-mm-dd dates to the 'accessdate' parameter (and not apply to the 'date' parameter within citations as well). If the oft-cited desire for "conciseness" is a true desire, allowing yyyy-mm-dd dates to be used uniformly throughout reference sections ought to be the standard. It isn't. Given that it is only a small handful of editors who care about date consistency and an equally small number in favour of retaining yyyy-mm-dd formats for access dates, it seems mighty unfair and tedious to have to bash it out on each article where the two groups of contributors would meet. It is a matter that needs to be more strictly defined and determined at MOS level. --Ohconfucius ^¡digame!

  02:13, 12 July 2011 (UTC)

• The MOS is silent about what citation style to use, except in the "See also" section which states "
  Citation styles and consistency section of that guideline makes it clear that any style, including published style manuals, are acceptable. Many proposals have come an gone to adopt a "house" reference style and all have failed. Jc3s5h (talk
  ) 02:34, 12 July 2011 (UTC)

There's been discussion about the conversion of acres (again), and I appears that there's no easy solution. I do believe editors need more detail in the guidelines about whether to convert to hectares or square metres or what. I have no idea what the solution is, but I find this, from Symphony Park very reader-unfriendly—both the originals and the conversions. Can't the rat of zeros be avoided? And can't we identify areas in which the ability of readers to visualise the quantities suggests how to express them?

Your input would be appreciated. Tony (talk) 10:12, 12 July 2011 (UTC)

From my experience, the floor area of buildings is seldom expresed in hectares, but the area of land is expressed in hectares once irt becomes convenient. I, personally, would use hectares for land areas of over 10,000 m² and display only the required number of significant digits. Martinvl (talk) 11:39, 12 July 2011 (UTC)

I'd go with the unit most closely matching the source one (i.e. convert square inches to square centimetres, square feet and square yards to square metres, acres to hectares, and square miles to square kilometres). ― A. di M.​_plé​^dréachtaí 11:49, 12 July 2011 (UTC)

I tend to agree, using different output units based on the resulting size would be confusing. So converting acres below 2.5 acres to use sqm and the others to use ha is confusing. Just use ha. For cases where the output unit is critical it can be specified, otherwise the default should just be used. In the example above, the lack of full implementation of million is the problem with the generated text, using e6 in the first case gives you 11×10^⁶ sq ft (1.0×10^⁶ m²) rather then the desired 11 million sq ft (1 million m2). Vegaswikian (talk) 18:53, 12 July 2011 (UTC)

Spelling out “million” before a unit symbol does look weird. I would either spell out the unit name as well or use ×10⁶. (“The $6 billion project is projected to include 11 million square feet (about 1,000,000 m²) of space on 61 acres (25 ha). Plans call for 1,908 thousand square feet (177,300 m²) of office and medical space, 5,200 thousand square feet (483,100 m²) comprising 3,200 residential units, 3 hotels providing and estimated 1,800 to 2,300 rooms in 1,575 thousand square feet (146,300 m²) of space with 475 thousand square feet (44,100 m²) of retail. The area is also expected to include 60–100 thousand square feet (6,000–9,000 m²) of casino space.”) ― A. di M.​_plé​^dréachtaí 19:54, 12 July 2011 (UTC)

No lack of implementation in {{convert}} in this respect. That it doesn't spell out "million"" before the abbreviation was quite deliberate. As A. di M. says that looks weird. That's why we have a guideline against this:

WP:MOSNUM#Unit symbols says "Units symbols are preceded by figures, not by spelled-out numbers: for example, 5 min, not five min." JIMp _talk·cont

20:04, 12 July 2011 (UTC)

Commercial office space in the US is leased by the square foot but this has no connection to a 12 by 12 inch square. Some times it is the actual carpeted floor space in your office suite and some times it is the percentage of the entire building including lobbies, rest rooms, hallways, elevators, and utility rooms. The same size office may be leased as 4000 square feet or 5000 square feet. (And a whole range in between.) Do not assign too much precision to commercial office space area. -- SWTPC6800 (talk) 22:51, 12 July 2011 (UTC)

Acres: a brief search found these examples. WP's treatment of acres looks like a real mess. I'm so glad I don't write articles that involve such areas. I wouldn't know where to go for guidance.

• 1/3 acre (1,300 m²)
• 0.02 acre (80 m²)
• less than 1 acre (0.40 ha)
• transforming Russia into a multiethnic and multiconfessional state spanning

almost one billion acres, approximately 4,046,856 km² (1,562,500 sq mi)

• .6-acre
• 0.12 acres (0.049 ha) 1/12 of an acre
• 101 million acres (410,000 km2)
• 1 acre (0.40 ha) of pavement
• half a hectare and a depth of four metres Tony (talk) 04:46, 13 July 2011 (UTC)

Good examples. I'd be interested in what people think about the following similar sizes:

• Grenville County area 272,261 acres (1,102 km2)
• the county has a total area of 426 square miles (1,104 km²)

Lightmouse (talk) 13:20, 13 July 2011 (UTC)

If the original measure has a very high or low value, that already may make the unit ill chosen. It is not the task of the conversion template to correct that. The choice of target unit should be determined only by the input unit, not the size of the quantity. So sq mi to km², acre to ha, sq ft to m². Predictable output is important. The user can always override the default. −Woodstone (talk) 04:15, 14 July 2011 (UTC)

I don't believe the guideline is very clear... is it best to use the notation BC/BCE for both years in a span contained before the Christian Era (i.e. 20 BC – 10 BC), or just after the latter year (i.e. 20 – 10 BCE)? I ask this because I am coming across several articles across the main article space that use either or, and it could be confusing for readers. Especially if they aren't aware that BC years count backward as time moves forward. Thoughts? Should we decide on and clarify this?. — CIS ^(talk | stalk) 03:16, 17 July 2011 (UTC)

WP:YEAR says: "A closing BCE or BC year is given in full (2590–2550 BCE). While one era signifier at the end of a date range requires an unspaced en dash (12–5 BC), a spaced en dash is required when a signifier is used after the opening and closing years (5 BC – AD 29)." It doesn't explicitly state that the answer is the unspaced 20–10 BC (or BCE; don't forget the nbsp). But that's how the first example is formatted, and the only example where a "signifier is used after the opening and closing years" is where one signifier is BC and the other is AD. Art LaPella (talk

) 05:17, 17 July 2011 (UTC)

We pick the appropriate format for the article. We don't attempt to present different versions of the article to different readers. So what reason would there be to use {{date}}?— Preceding unsigned comment added by Jc3s5h (talk • contribs) 02:58, 16 July 2011

Hmm, well we used to use linked dates just for that reason, so we could display dates as the user wanted to see them. We didn't get rid of that for the reasons you state, we got rid of it because linked dates are dumb and we were linking solely so we could get the date to auto-format. {{

talk • contribs

) 20:27, 17 July 2011 (UTC)

You are just wrong. We got rid of automatic formatting because automatic formatting is a bad idea. Jc3s5h (talk) 21:12, 17 July 2011 (UTC)

Ouch! Let's make that "I disagree. We actually ..." I've never used that template and can't imagine why I would, but if you click "What links here" and "transclusion count", it says the template has been transcluded 11475 times. Art LaPella (talk) 21:55, 17 July 2011 (UTC)

Could you try telling me why you think it's a bad idea? Even if you manage to get the date consistent and keep it that way in a single article, when I click on the next article it will inevitably look different if we don't auto-format (or set an across the wiki standard); however, with the template the date will always appear the same for each user, it just may appear different for two different users - but the information conveyed will be the same. Besides, my point wasn't why don't we tell everyone to use it all the time, it was why don't we address it. Auto formatting with wikilinks was a problem for years for many different reasons, it was easy to deprecate a process that didn't work. Notice that the current reference to autoformatting says that dates shouldn't be linked just for autoformatting but it doesn't say that they shouldn't be autoformatted. That's because it used to be the normal we did that. --

talk • contribs

) 04:59, 18 July 2011 (UTC)

Did you mean me? As I said, I've never used it. But the

Wikipedia:Preferences

?

As for "why don't we address it", I didn't rule that out. I said the template has been transcluded 11475 times. Therefore the template must be of interest to whoever is adding it to articles. Art LaPella (talk) 05:31, 18 July 2011 (UTC)

Not at all, I was responding to Jc3s5h's "You are just wrong . . . automatic formatting is a bad idea." (that's why I outdented). I want to know why is is automatic formatting such a bad idea? I do appreciate your further explanation of your position and you are right, I thought that the template was applying user preferences but that's apparently because it's default output is consistent with my user preferences ;). The question of mentioning the template is therefore less important. But the question of autoformatting remains. I don't see why it's so undesirable. No other encyclopedia has one article with one style and one article with another style depending on either 1) where or who the article is about or 2) who started the article and there is no really good reason to do that except that it's a good compromise for editors from different areas - it makes no sense for actual users of our Encyclopedia which editors often forget are really whom we are here for. --

talk • contribs

) 09:54, 18 July 2011 (UTC)

In addition to the reason stated by Art LaPella, that most of our readers wouldn't benefit from date autoformatting because they don't have accounts, it's too complex to get it right. Consider the example taken from the Associated Press Stylebook being discussed at

WT:MOS#Punctuation after date

:

Feb. 14, 1987, was the target date.

(Of course Wikipedia chooses to spell out dates and AP chooses to abbreviate them, but that does not matter.) If this were changed to the day-first format, the sentence should become 14 Feb. 1987 was the target date, but no one likes to start a sentence with a numeral, so a human editor would rewrite the sentence as The target date was 14 Feb. 1987.

You'll never get an automatic system to do that on the fly, and you'll never get editors to imagine all the ways their writing might be presented and structure their writing so it will look right with any date format. Jc3s5h (talk) 12:33, 18 July 2011 (UTC)

This makes sense, thanks for the response.--

talk • contribs

) 13:05, 18 July 2011 (UTC)

Transclusions: The template isn't used often. It only looks like that because it's embedded in several templates. Lightmouse (talk) 10:18, 18 July 2011 (UTC)

• Is there any reason this template shouldn't be listed for deletion? It goes in the opposite direction to the community consensus established in 2008 and 2009 that dates shouldn't be auto-formatted. Please let's not introduce yet another hurdle for the new editors we really need to attract to en.WP; and the simple what-you-see-is-what-you-get has turned out to work very well. Tony (talk) 11:01, 18 July 2011 (UTC)

• This should be addressed by a group consisting of (1) template authors who have used the date template and (2) expert template writers, to see if it actually provides any benefit in templates. I do not belong to either group. Jc3s5h (talk) 12:33, 18 July 2011 (UTC)

'Template:Infobox poker player' appears to be responsible for 60% of the transclusions. The date template was embedded in 2009. Its only function is to accept '2011-07-07' or '7 July 2011' in edit mode to get '7 July 2011' in read mode. Lightmouse (talk) 12:47, 18 July 2011 (UTC)

• (ec response to Tony1) Because the template is largely intended for nesting in other templates as mentioned by Lightmouse. I brought it up here because I thought it did something it doesn't. It does autoformat, it doesn't autoformat according to user preferences, as Art LaPella pointed out to me.--
  talk • contribs
  ) 13:05, 18 July 2011 (UTC)

If I understand this date template correctly, it is an abortion that should never have been made. It only affects how the dates appear for A) registered editors, B) who change their date preferences from “No preference.” Well over 99% of our readership will just see a default format (18 July). The use of this template just allows registered editors (those responsible for ensuring text is consistent and appropriate) from seeing that there might be a hodge-podge of different date formats in an article because the template effectively says “Here crybaby, we won’t darken your doorstep with a date format you don’t like to be exposed to.” My recommendation is to discourage use of the {date} format and for all editors who actually care about what our readership is seeing to set their date preferences to “No preference.” Greg L (talk) 15:40, 18 July 2011 (UTC)

Actually, I'm not so sure now that it doesn't actually override user preferences and output 18 July 2011 no matter what format you prefer, which would make that 100% of readership. But, as it's intended for use inside of another template, it isn't really MOS issue in my opinion. I've learned a lot about the template and I no longer think it needs to be mentioned here. Whether the template should be canned (and I'm starting to lean in favor) is really a question for the template's talk page and/ort TfD.--

talk • contribs

) 17:22, 18 July 2011 (UTC)

• It’s right in its documentation that it formats dates per user preferences. The important thing to remember here is that regular visitors to Wikipedia don’t have user preferences. Making a tool like the {date} template was a way to appease editwarring editors years ago. The realization now is that any tool that gives some registered editors a different view of mainspace body text than what the rest of the world sees is bad ‘cess. I am in general agreement with you that it the tool isn’t worth a bucket of warm spit. But since this is a manual of style, and the use of that template affects how articles read, it is not at all wrong to *mention* the {date} template; but in this case, “mentioning” it would be to suggest that best practices is for editors to not use it (for the above-mentioned reasons). That might speed the thing to the grave, which is belated. Greg L (talk) 19:43, 18 July 2011 (UTC)

• I didn't find formatting dates per user preferences, in either the document or direct experiment. 8 July 2011 says "8 July 2011" on my computer, even after setting my preference to mdy. Art LaPella (talk) 20:12, 18 July 2011 (UTC)
• And even after exiting my browser and coming back. Art LaPella (talk) 20:15, 18 July 2011 (UTC)

OK, Experiment time. This date: July 18, 2011 was coded as {{date|2011-07-18|mdy}}. Let me try this… (one moment, I’m in “Show preview” mode)…

With “No preference” in my date preferences, I see “July 18, 2011”. With my prefs set to “20:33, 18 July 2011”, I see the same thing. So…

Why would someone want to learn to use this template? What good is it? If I wanted a date to read July 18, 2011, why would I type {{date|2011-07-18|mdy}}?? Someone explain this to me, please. Greg L (talk) 20:38, 18 July 2011 (UTC)

P.S. Apparently, it has utility somewhere in obscure practices with dates in highly structured sections, such as tables and other templates. I agree with Doug; it doesn’t need to be mentioned here. Greg L (talk) 20:48, 18 July 2011 (UTC)

Yes, Greg is right. The template does not autoformat dates at all. It just formats them. It can be useful within another template to standardise output format when given varying input format. Also if you're converting the format of a date (say for consistency), using the template is quick and might be less prone to errors. JIMp _talk·cont 00:27, 19 July 2011 (UTC)

The majority of cases are not useful. For an example of trivial use, see: 'Template:Infobox poker player'. If it has non-trivial uses, that's fine but trivial uses should be removed to simplify things for readers. Lightmouse (talk) 12:26, 19 July 2011 (UTC)

The guidance says:

• The symbol for the litre may be either "L" or "l".

and

• The solitary lower case l is avoided to reduce confusion with the digit 1.

These appear to contradict each other. What should it say? Lightmouse (talk) 18:55, 17 July 2011 (UTC)

• This means that the MOSNUM would consider these entries correct, if they were in a table or another location where space was at a premium (and no conversions were appropriate): "15 ml", 2 L. The idea if using two symbols for the same unit in the same article seems like a bad idea to me. Jc3s5h (talk) 18:59, 17 July 2011 (UTC)

Ah yes. I see now. I'll delete the first phrase as a contradiction. For the second phrase in 'Specific units' I propose changing:

• Symbol:Use upper case L when not preceded by a prefix. to Symbol: l or L when preceded by a prefix. L when not preceded by a prefix.
• Comment: The solitary lower case l is avoided to reduce confusion with the digit 1. to Comment: The symbol l can look like the digit 1 when without prefix.

Does that make the meaning clearer? Lightmouse (talk) 19:25, 17 July 2011 (UTC)

That does make it clearer, but the bigger question is, should we allow different symbols for the same unit in the same article? I would change Use upper case L when not preceded by a prefix. to "Use upper case L when the symbol is not preceded by a prefix anywhere in the article.

I acknowledge my change would change the intent, not just clarify. Jc3s5h (talk) 13:10, 18 July 2011 (UTC)

A fair point. We have two issues:

1. The existing guidance isn't clear. I'll update the text as described above, unless there's any objection.
2. We need a debate to consider whether the guidance is what we want.

Lightmouse (talk) 13:30, 18 July 2011 (UTC)

Support I support this guidance. A solitary "l" can be mistaken for a "1", so it's fair that we disallow them. Consistency demands that we use "mL", "cL", "kL", etc. if we're using "L". JIMp _talk·cont 00:38, 19 July 2011 (UTC)

Oppose. The capital in prefixed units "mL" and "cL" is relatively rare. We should not adopt it as the only approved version. In "ml" and "cl" no confusion is likely. Even the "l" by itself is not really confusing, because a single digit "1" cannot occur in a similar position. We should not deviate from the advice given by the official SI documentation. −Woodstone (talk) 05:18, 19 July 2011 (UTC)

Seems to be a solution looking for a problem. The only commonly used derived units are µL, mL, and L. Centiliters seem to be more common in Europe. Larger volumes are given in liters or cubic meters. --Rifleman 82 (talk) 05:51, 19 July 2011 (UTC)

Oppose - The current Wikipedia guidance is a rahash of the SI brouchure. In the United Kingdom millilitres are usually written "ml" rather than "mL" (at any rate the items in my fridge and store cupboard). I agree with User:Woodstone that we should not deviate from the SI Brochure unless there is good cause.

Ref:

ISBN 92-822-2213-6, archived

(PDF) from the original on 2021-06-04, retrieved 2021-12-16

Martinvl (talk) 06:38, 19 July 2011 (UTC)

Comment I prefer the lower-case versions and would oppose banning them. I just would want to see "ml" alongside "L". Woodstone raises a good point that the "1" wouldn't appear in the same position. JIMp _talk·cont 07:40, 19 July 2011 (UTC)

Stop voting. Nobody has presented proposed text to change the intent of the guidance. This thread is only about whether we need to eliminate a contradiction and failure of clarity in *existing* guidance. User:Jc3s5h suggested changing the intent of the guidance but before a vote, please take it to another thread. In the meantime, I'll update the *existing guidance* to make clarify (as far as I can) the *existing intent*. 10:25, 19 July 2011 (UTC)

The guideline exemplifies the preferred abbreviation in roman face, c., although italicises the spellings-out. I've often wondered which is correct for the single-letter abbreviation. A recently promoted article, Deusdedit of Canterbury, has the italics. Tony (talk) 10:18, 10 July 2011 (UTC)

According to one source:

• Foreign words and phrases which have passed into regular English usage should not be italicized, though the decision between italic and roman type may sometimes be a fine one. In doubtful instances it is usually best to use roman. ... Certain Latin words and abbreviations which are in common English usage are also no longer italicized.

It does suggest that circa is an exception to that rule. However, there's no point in Wikipedia having a guideline of such small detail that will be ignored frequently. Thus for consistency and pragmatic reasons, I think Wikipedia shouldn't make that exception i.e. it should be roman just like 'etc' and 'i.e.' Lightmouse (talk) 10:44, 10 July 2011 (UTC)

It's my gut reaction too; but other opinions are needed, I think. Tony (talk) 13:32, 10 July 2011 (UTC)

Parts of this discussion seem unaware of the existing

WP:YEAR guideline: "the unitalicised abbreviation c. is preferred over circa". That is, we already specify unitalicized "c.", and deprecate "circa", so it doesn't matter whether the wrong way ("circa") should be italicized or not. Art LaPella (talk

) 18:05, 10 July 2011 (UTC)

I agree that the

MOS:TIME) that uses italics to emphasize "a.m." and "p.m.", but it is not a recommendation to italicize them, as the examples show "a.m." and "p.m." as unitalicized. CuriousEric

19:44, 10 July 2011 (UTC)

The OED italicises circa in an example, plus the two quotations it gives that use circa also italicise it. If anyone can access the online OED, the link is this. McLerristarr | Mclay1 04:35, 11 July 2011 (UTC)

For whatever it might be worth, c. (unitalicized) is the accepted U.S. & Canadian (and perhaps Mexican) abbreviation for "cent" (or centavo) when the symbol ¢ is unavailable or hard to create (I just had to look it up in Windows' character map because it's not on computer keyboards as it was on American typewriter keyboards). But unlike $ and c. for circa, c. for "cents" comes after the numbers. I sometimes lean towards using ca without a full stop/period for circa, but that raises the British/American quandary about non-terminal periods/full stops. —— Shakescene (talk) 06:11, 21 July 2011 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

please change AD and BC to a more accurate scientific dating system

Jojotruth1 (talk) 17:36, 20 July 2011 (UTC)

That's a perennial issue, not something we forgot.

Here's its most recent repetition. Art LaPella (talk

) 21:33, 20 July 2011 (UTC)

No, we will not make this change in the foreseeable future. Jc3s5h (talk) 21:37, 20 July 2011 (UTC)

Which more scientific dating system are you referring to? Your edits at Israel seem to suggest that you aren't talking about BCE and CE?. — Steven Evens ^(contribs) 02:55, 22 July 2011 (UTC)

I think we've now resolved contradiction and clarity problems with current guidance on litre. Several people wanted to discuss changes in guidance. The following table summarises what I think people meant:

If I've misunderstood, please make the appropriate changes. Lightmouse (talk) 15:14, 19 July 2011 (UTC)

There is a difference between "permitting XXXX" and "conselling against, but not prohibitting XXX". The SI brochure says that either "L" or "l" may be used as a symbol for the litre, but gives no further guidance. I usually use "L" and "ml" but am not dogmatic about it - this is the norm in the UK, I don't know what the norm is in the US. Martinvl (talk) 15:46, 19 July 2011 (UTC)

Since the brochure is not primarily a style manual, I would not expect it to give general writing advice, such as keeping symbols consistent within an article. Thus I wouldn't interpret silence on this topic as permission to be inconsistent. Jc3s5h (talk) 15:52, 19 July 2011 (UTC)

Looking at some products in my kitchen, I find 5 uses of "L", 4 uses of "ml", 5 uses of "mL", no uses of "l", and no units spelled out. This is in the USA. Jc3s5h (talk) 16:01, 19 July 2011 (UTC)

Interesting, thanks. Does the mosnum guidance over and above the SI brochure have any effect? Guidance that has no effect is probably a waste. Lightmouse (talk) 14:26, 20 July 2011 (UTC)

From a regulatory standpoint, weights and measures authorities only regulate goods in commerce, so Wikipedia has no obligation to pay any attention to any weights-and-measures standard-setting body.

Given that, I observe that both MOS and MOSNUM make suggestions that are widely available in grammar and style guides. So there is nothing to stop us from repeating information that is in the BIPM brochure, if we think editors are unlikely to bother reading the brochure but would read the suggestions if they are reproduced here.

If MOSNUM specifically endorses, through a hyperlink, the guidance in the BIPM brochure, that would disallow the script lower-case l which would otherwise be acceptable. Jc3s5h (talk) 15:33, 20 July 2011 (UTC)

Yes, I agree. WP mosnum repeats, contradicts, and goes beyond SI as we choose. I was merely suggesting that we look critically at the value of each repetition.

• You appear to be suggesting that SI forbids the lower case 'l' for litre. But that's not true. See the official SI website and the footnote.
• The current guidance in mosnum is that some of SI applies and some does not. I don't see any reason for that to change.

Forgive me for not understanding you. I agree with you that we can and should choose to repeat some of SI. We just need to ensure repetition adds value. Lightmouse (talk) 16:44, 20 July 2011 (UTC)

The liter symbol that is sometimes seen, but not endorsed by the BIPM brochure, is "ℓ". Jc3s5h (talk) 19:58, 20 July 2011 (UTC)

Ah. I seem to remember seeing "ℓ" mentioned somewhere before. But I don't think I've ever encountered it in Wikipedia. Forgive me for not following you, can we take it step by step. Are you saying mosnum should have guidance on "ℓ"? Lightmouse (talk) 20:58, 20 July 2011 (UTC)

I think the difficulty in typing "ℓ" is sufficient to protect us from it, but I would have no problem endorsing a guide that either says to avoid it, or implies it should be avoided by not listing it among the acceptable symbols. Jc3s5h (talk) 21:40, 20 July 2011 (UTC)

Your wish appears to be granted. Mosnum says:

• Non-SI units in tables 6, 7, 8, and 9 of the SI brochure are written according to the SI standard unless otherwise specified in this Manual of Style (dates and numbers). For example see guidance on litre.

Table 6 of the SI brochure says:

• "The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one)."

The only remaining issue is whether there's a problem in WIkipedia that needs mosnum to say more than SI. User:Woodstone and User:Martinvl are happy with a one-to-one match between mosnum and SI guidance. If you are too, then so am I. Lightmouse (talk) 09:43, 22 July 2011 (UTC)

• My first choice would be to adopt American usage in all cases, and always capitalize the "L". But I don't think I can persuade the community do that. My second choice would be to follow the BIPM brochure. However, retain the guidance that the spelling "liter" is allowed. Jc3s5h (talk) 11:31, 22 July 2011 (UTC)

I sympathise with your first choice but agree it's unlikely to succeed. Your second choice means keeping the 'Name' and 'Comment' columns the same and changing the 'Symbol' column to:

• l or L

I'm ok with that. Lightmouse (talk) 15:25, 22 July 2011 (UTC)

I've updated the guidance accordingly. The 'Symbol' column now simply says

• l or L

and matches BIPM. Lightmouse (talk) 10:39, 28 July 2011 (UTC)

How about, instead of just allowing either notation in any given article, we take one of each and make it the standard. Most who complain about BC/AD being offensive cite the "Year of Our Lord" in AD, and most who complain about BCE/CE cite the 3 digits found in "BCE".

How about we make the new standard BC and CE? We will use "BC" all throughout Wikipedia for years before Year One, and we will use "CE" all throughout Wikipedia for years from 1 onward. For example, the contentious Jesus article would read, under this new Wikipedia system:

"Jesus of Nazareth, Yeshua in Hebrew or Aramaic (7-2 BC — 30-36 CE)"

Well, why not? I know that BC and CE are rarely paired in external sources, but why can't Wikipedia make a compromise to be as neutral as possible without also being as frustrating as possible by allowing both and having edit wars and reversions constantly? What's bad about this idea? Thoughts?. — Steven Evens ^(contribs) 02:52, 22 July 2011 (UTC)

It cannot be denied that the proposal has a certain elegance. Although it makes an unusual pair, it has a nicely balanced feel. I would support it. −Woodstone (talk) 05:37, 22 July 2011 (UTC)

There is already a fairly commonly used system that does not have any problem with bulky abbreviations or explicit religious references: astronomical year numbering. Jc3s5h (talk) 11:38, 22 July 2011 (UTC)

But with astronomical year numbering, Julius Caesar dies in –44 instead of 45 BC, which would change every established BC year we know, and the minus sign (–) would wreak havoc on date ranges. Imagine, if you will: ""Jesus of Nazareth, Yeshua in Hebrew or Aramaic (–6 - –1 — 30-36)". — Steven Evens ^(contribs) 21:02, 22 July 2011 (UTC)

What Steven Evens views as a disadvantage, I view as an advantage. It would be too complicated for someone to even think about using a bot to make the "correction". Bots never get it right, they always mess up on things like quotes and titles. Jc3s5h (talk) 21:38, 22 July 2011 (UTC)

Also, I think it's quite unfamiliar to most readers, so even if we get it right they might not realize the negative years are off by one wrt the more commonly used systems. ― A. di M.​_plé​^dréachtaí 20:02, 23 July 2011 (UTC)

Right, and it's not really commonly used at all. It's commonly used in some technical/academic fields, this is a general purpose, albeit highly detailed, encyclopedia. It's certainly no where near as common as BCE/CE. The BC/CE solution is interesting and possible because the BC/AD and BCE/CE systems are just different naming conventions for the same system. I'm not sure that this is the best solution but it deserves consideration. I'm not really sure why BCE is so disliked just for an extra letter, everyone knows the C in BC is "Christ" which makes the system remain problematic, though I suppose we could break new ground and suggest that it now is simply a shorter form of BCE.--

talk • contribs

) 13:01, 24 July 2011 (UTC)

It seems a little strange but I see no reason why Wikipedia cannot invent its own system. Change has to start somewhere. Someone invented the BCE/CE system. Although I still don't understand why we use BC/AD seeing as how Christian articles use BCE/CE. All that being said, I have no problem with the extra letter in BCE. McLerristarr | Mclay1 13:06, 24 July 2011 (UTC)

The biggest obstacle to inventing our own system would be getting anyone to notice. The Manual of Style puts most editors to sleep long before they find out about its subpages. Art LaPella (talk) 15:39, 24 July 2011 (UTC)

We can't create our "own system", it's not notable or from reliable sources. It would be like creating an in-wiki alternative to the metric system instead of using either metric or imperial. The difference here is, we can mix a usage of BCE/CE and BC/AD without causing any problems. As for the "Christ" in BC making it problematic, I don't see why. It's educational. "

Christ

", despite its apparent religiosity, is widely used as a secular means of referring to Jesus of Nazareth anyway, as confirmed by its Wiki article. How many times have you heard non-Christians call Jesus simply "Christ" without implying he is a messiah? Look, it's simply a fact that the Dionysian era system is based on the (erroneously calculated) birth of Jesus, so as an encyclopedia dedicated to information, I don't understand the obsession with completely covering that up. Sure, "in the year of our Lord" is a bit icky, even for me as an atheist, but it's all the same mythology as Thor's Day, Woden's Day, etc. Plus, they're just initialisms, it's not like they're spelled out or anything.

I think the BC & CE combo proposal conveniently rids of the overtly religious "AD" proclamation (as well as the pesky way that it can be placed either before or after a year) as well as not going too PC in the other direction by keeping the reference to Jesus (Christ) for years before the Dionysian era, and keeping both initialisms at 2 letters. I don't see why this compromise shouldn't satisfy most people. Even for those who prefer BCE/CE, this proposal would promote the Common Era system even more on Wikipedia as it would be used in every article that spans the years 1—999 — Steven Evens ^(contribs) 16:16, 24 July 2011 (UTC)

I don't understand. First you said we can't create our own system, then you said you support it. I've never really noticed non-Christians refer to the purely historical Jesus as "Christ". I wouldn't. But that point is that, as an encyclopaedia, dedicated to factual information, basing a dating system on one religion and an inaccurate guess at a person's date of birth seem silly. McLerristarr | Mclay1 06:53, 28 July 2011 (UTC)

I said we can use one aspect of the BCE system and another aspect of the BC system. That's not inventing a new system, it is taking different aspects from two existing systems. As for an encylopedia dedicated to factual information basing a dating system on one religion, what else do you suggest? BCE/CE terminology doesn't change the fact that it's the Christian system. And using another era system altogether is not notable. The Gregorian calendar is the international standard, that's why we use it. Is it "accurate" that Janus is the god of doorways and therefore we should support naming the first month "January"? No, but does that mean we should create a new name for January within Wikipedia? Of course not. Wikipedia uses what's notable in the English language, and that includes the January, Wednesday, BC/AD/BCE/CE, etc.. — Steven Evens ^(contribs) 07:42, 28 July 2011 (UTC)

• So… eschewing the RSs isn’t enough, we would completely eschew both conventions used on this
  pale blue dot and instead invent our own hybrid house style that nobody else is using?? (♬♩“A little bit country! …And a little bit Rock and Roll!”♩♬). It’s been proven over and over again that Wikipedia does not have the power to Lead By Example To Change The World For A New And Brighter Future®™© and always manages to do nothing more than just looks foolish whenever it attempts to do so (witness the three-year-long “kilobyte” / “kibibyte” fiasco).

  It is common for many publications to use BCE/CE when trying to be politically correct and trip all over oneself to be as inoffensive as possible. However, I’ve yet to hear narrators on TV and film documentaries (like on Egyptian pyramids) use this new terminology; instead, they stick to the “BC” and “AD” forms. I assume this is because the customary terms are less distracting in audible form because saying “This pyramid was thought to have been built in 2500 bee see eee” would leave the viewer in “WTF-land” for 15 seconds.

  At risk of ticking off some of the 16-year-old wikipedians who might be looking in on this and who are all smitten with how wise and knowledgeable they have become in only two short years and who are trying to change the world; and in order to make peace on this issue using actual policy that underlies important principals of Wikipedia, I am all for just following the RSs for each particular article. For those articles where there is no guidance by the RSs, or the usage is mixed or unclear by the RSs, my personal preference is to use the BC/AD since I believe it least draws attention to itself for those who hear the words in their heads as they read. This philosophy comes from Technical Writing 101, which states that Thou shalt not use a writing style that draws undo attention to itself for the target readership.

  But, since the above might make too much sense and deprive people of their God-given entitlement to wikidrama, I suspect the best thing to do here on this issue is the standard solution for deadlocks: “Do whatever ya’ want.” Greg L (talk

  ) 16:29, 27 July 2011 (UTC)

Fwiw, I first heard the usage BCE/CE (actually it was not the initialisms but the full words) nearly 30 years ago on a documentary on the US

talk • contribs

) 17:07, 27 July 2011 (UTC)

It's still quite a minority usage (though their frequencies are the same order of magnitude now, so that I think the current “pick-one-and-leave-it-alone” way is appropriate): http://ngrams.googlelabs.com/graph?content=753+BC%2C753+BCE&year_start=1970&year_end=2008&corpus=0&smoothing=3. ― A. di M.​_plé​^dréachtaí 17:50, 27 July 2011 (UTC)

Meh, whatever, I wasn't actually expecting this to go anywhere, just sparking discussion on it. In my perfect world, "BCE" could be meant to represent "Before Christian Epoch", and "CE" could be switched to "ACE" and mean "After Christian Epoch"; getting rid of the nonsense terms "Common" and "Era" and stripping it down to exactly what it really is, and also giving both notations 3 letters. Saying we're in the year 2011 CE ("Common Era") sounds stupid, but 2011 ACE ("After Christian Epoch") makes perfect sense, because that's exactly what it is. Two thousand and eleven years since the Christian epoch, without needing to get all religious about it. The main objection I have with "Common Era" is how vague and nonsensical it is. But "Christian Era" doesn't work either, because it sounds as if everything that the era itself since 1 AD is somehow Christian in nature. The term "epoch" only refers to the reference date, not the years following or preceding. I hate euphemisms and eschewing history, and so CE/BCE rub me the wrong way. — Steven Evens ^(contribs) 03:03, 28 July 2011 (UTC)

I’m not making fun of you, Steven, but I can’t resist: Since we are inventing house styles unique on this planet, why not “BYMRTCBCSETLEAFS”, which would stand for “Before Years Measured Relative To Christ But CALLED Something Else To Look Enlightened And Feel Smug”. Then “AYMRTCBCSETLEAFS” could mean the “after” version of all that. We’ll stand on a hilltop, join hands, and Change The World©™® with Coca-Cola. Or we could just follow the RSs where possible. Greg L (talk) 03:20, 28 July 2011 (UTC)

Don't worry, I understand what you're saying. I wasn't saying that I'd prefer this "perfect world" BCE/ACE over the traditional AD/BC, because that's not the case at all. If it were up to me, we'd use AD/BC exclusively. But we're not. It's the constant edit warring, reverting, time wasting and accusations of "Christian bias" that I can't stand with the current "use both systems wherever" compromise. People are constantly changing BC/AD to BCE/CE arbitrarily all 'round the encyclopedia for spurious politically correct reasons, and if you don't revert them "in time", it is considered that the silence has established consensus for BCE/CE. All sorts of ugly political and religious debates and shouting matches have resulted from fighting over this terminology. With my BC/CE compromise I was just offering an idea that might help quell that a bit. I knew it was unlikely to succeed, but it's worth throwing out there. — Steven Evens ^(contribs) 03:31, 28 July 2011 (UTC)

ACE doesn't make any sense. If BCE is before something and ACE is after something, when was the something? McLerristarr | Mclay1 06:53, 28 July 2011 (UTC)

Some OR on my part: Well, the "After Common Era" will apply when the Common Era (where we are now) ends. That will supposedly be on the

No such user (talk

) 07:27, 28 July 2011 (UTC)

Did you read my post immediately prior? I explained that ACE in a "perfect world" system would represent "After the Christian Epoch", not "After the Common Era". The "something" is the Christian

epoch—Dionysius Exiguus' estimate of the birth year of Jesus. Unlike "Era" which suggests a continuous time period after a certain point, "epoch" is that point itself. — Steven Evens ⁽contribs

) 07:42, 28 July 2011 (UTC)

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)

To I.P. upset about

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

• 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)

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)

• 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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• 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)

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)

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)

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)

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)

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)

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)

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

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)

@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)

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)

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)

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)

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)

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)

• 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)

  “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)

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)

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)

• 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)

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)

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)

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)

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

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)

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)

• 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)

  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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

If this kind of confusion occurs often enough to justify the effort, a new article,

Kilometer and Year would not help. Jc3s5h (talk

) 12:20, 8 August 2011 (UTC)

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)

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)

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)

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

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

It's up for

deletion. JIMp _talk·cont

05:50, 8 August 2011 (UTC)

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)

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)

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

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)

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

No.

books

} 23:48, 11 August 2011 (UTC)

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)

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)

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

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)

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)

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)

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

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

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)

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)

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)

I have observed a number of editors convert date ranges in the form "1990 to 1991" to 1990–1991, claiming that

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)

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)

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

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)

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)

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)

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)

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)

Perhaps he means

WP:YEAR, where the "Year ranges ..." quote occurs, instead of MOS:ENDASH. Art LaPella (talk

) 04:14, 7 August 2011 (UTC)

• Support endash. Use the {{
  Hs}} template to get sorting working in all browsers. GFHandel ♬
    07:53, 7 August 2011 (UTC)
  • 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)

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)

• 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)
  • 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)
    • 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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

• Support. Something definite has to be done, and Lightmouse's scheme looks rational to me. There have to be limits. In Australia we might have a sense of "6 ft tall", and be less sure about "183 cm tall"; but we generally get by with unaided metric really well. I struggle to picture how big a man of 168 lb (12 stone) would be. Metric gets easier year by year. If people didn't move on we'd still be talking cubits, furlongs, and pennyweights. Imagine if those had continued to be "linked" or converted, in an earlier technology. We'd eventually have multiple expressions for every measurement, and never achieve the sort of clarity that an encyclopedia should aspire to. Noetica^Tea? 11:22, 16 August 2011 (UTC)
• Support. I agree with the principle and idea of a table such as this; I more or less agree with the classifications. --Ohconfucius ^¡digame! 13:04, 16 August 2011 (UTC)
• Oppose as textbook
  WP:BRD
  and consensus at the article in question like any other content dispute. If editors find that they're becoming frustrated at 'having to rehash the same arguments over and over' on whether or not a term should be linked, it might be valuable for these editors to reconsider whether the presence of a link on a unit of measurement in an article is worth getting into disputes over, and whether removing the link is going to have a noticeable impact on the quality of the article for the general reader. If it won't, why expend such effort on it?

Frankly, this seems to be a case of attempting to legislate to fix an extremely minor issue that some editors perceive to be bigger than it really is. This kind of prescriptive language isn't necessary and is likely to be used as ammunition to try to win a dispute, rather than assessing the merits of the individual case. I'm generally opposed to this kind of overuse of rules and guidelines.

talk

) 07:01, 17 August 2011 (UTC)

This is a guideline, and editors want guidance. Making decisions on a case-by-case basis is possible, but general guidelines are essential, or we're all in the dark. Tony (talk) 07:09, 17 August 2011 (UTC)

As I said, I don't believe that this issue is generic enough for a broad guideline to be of any value. There are a lot of factors influencing the decision to link something and oversimplifying things in a table like this will only lead to it being pointed to in a dispute, instead of being discussed normally. As far as I know, we don't have a guide on specifics of when to use new paragraphs or what threshold of topic difference to use to create new subsections, because these things similarly can't be encapsulated effectively in a general sense. Instead we use very broad language like 'not too long, not too short' and so on. I think a table of this nature is on the 'too specific' side to be useful.

talk

) 23:41, 18 August 2011 (UTC)

I agree with you that we need to consider whether guidance is needed. I think guidance should:

• document consensus on a wikipedia wide issue that gets discussed frequently at local level
• 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

On the basis of at least one of those bullets, if not more, specific guidance is needed. Over the years, well-meaning editors add excessive links due to their own personal interpretation of what 'obscure' means. These rarely get challenged until the article gets put up for review at FA or something like that. If anyone else challenges an excessive link, the generic guidance is inadequate to resolve a difference of opinion between two editors. You can see here that it has taken many days and many comments and we still haven't documented consensus whether there should be links in:

• "6 feet 3 inches (1.91 m) tall and weighs 220 pounds (100 kg)"

This isn't a new thing. Sample specific units have existed in the guidance for years. We just haven't discussed it at length. Lightmouse (talk) 09:47, 19 August 2011 (UTC)

I don't believe that linking the first instance of a unit of measurement, as our other guidelines recommend, could be considered excessive. If units are being linked repeatedly throughout the article then we already have guidelines for how to deal with overlinking. I don't see any fundamental benefit in removing informative links on the basis that a subset of the intended audience believes their meaning should be obvious. I agree that the current reference to 'obscure' is vague, but I'd prefer to remove that reference and link the first instance of any unit of measurement (subject to context), rather than to simply not link certain units at all.

The link being present on the first instance provides a benefit to people interested in learning more about that unit. What benefit is gained from removing that link?

talk

) 00:06, 23 August 2011 (UTC)

The benefit of removing irrelevant links is that the relevant links become more prominent. If the unit is relevant, I'm all for linking it. JIMp _talk·cont 00:18, 23 August 2011 (UTC)

Frankly, I don't think that we'll get a consensus as we each have our own different ideas as to what units are commonly know and which aren't. I think that we should respect the individual editor's decisions on this issue unless they're overlinking, but I will say that I'm inclined to link more often than not to remove any ambiguities.--Sturmvogel 66 (talk) 03:26, 23 August 2011 (UTC)

People are talking as if this is a new thing. It isn't. The following units were specified previously:

• 18 °C (64 °F)
• 12 oz (355 mL)
• millisecond, second, minute, hour, day, week, month, year
• metric units of mass (milligram, gram, kilogram), length (millimetre, centimetre, metre, kilometre), area (mm², etc.) and volume (millilitre, litre, mm³)
• inch, foot, yard, mile
• m/s, ft/s

The table doesn't have to be complete. It just has to name the top 20% units responsible for 80% of excessive linking e.g. "6 feet 3 inches (1.91 m) tall and weighs 220 pounds (100 kg)". Lightmouse (talk) 19:50, 23 August 2011 (UTC)

=====In references=====
{{See also|Wikipedia:Citing sources#Citation style |l1="Citation style " section in "Citing Sources"}}
* Publication dates in article references should all have the same format.
:In the same article, write
:{{xt|
:*Jones, J. (20 September 2008)
:*Smith, H. (August 2002)
:*Garcia, M. (4 May 1999}
}}
:or
:{{xt|
:*Jones, J. (September 20, 2008)
:*Smith, H. (August 2002)
:*Garcia, M. (May 4, 1999}
}}
:but not
:{{!xt|
:*Jones, J. (20 September 2008)
:*Smith, H. (August 2008)
:*Garcia, M. (May 4, 1999}
}}
*Access and archive dates in references should be in either the format used for publication dates, or YYYY-MM-DD.
:In the same article, write
:{{xt|
:*Jones, J. (20 September 2008) ... Retrieved 5 February 2009.
}}
:or
:{{xt|
:*Jones, J. (September 20, 2008) ... Retrieved 2009-02-05.
}}
:but not
:{{!xt|
:*Jones, J. (20 September 2008) ... Retrieved February 5, 2009.
}}

These requirements do not apply to dates in quotations or titles.
}}