Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 130←Archive 133Archive 134Archive 135Archive 136Archive 137→Archive 140

Precision: tomorrow's TFA

Colleagues, I've never been completely confident about the decimal-point consistency thing. I've raised it here. In particular, this one foxes me: "whose height varies between 4 and 12 cm (1.6 and 4.7 in), and which is typically between 1 and 1.5 cm (0.4 and 0.6 in) thick". Your advice? Tony (talk) 07:49, 8 July 2011 (UTC)

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)

Hemisphere

WP:SEASON was used here to justify uncapitalizing "Northern Hemisphere". So should we fix it? Art LaPella (talk) 19:45, 10 July 2011 (UTC)

The article Northern Hemisphere has a reference to Merriam Webster's Online Dictionary showing it as all lowercase which supports that change; the article uses all lowercase. But shouldn't the article be named "Northern hemisphere" to follow that recommendation? The article Southern Hemisphere has a reference to Merriam Webster's Online Dictionary, which supports the name as all lowercase, but yet that article capitalizes the first letter of both words throughout the article (inconsistent). And then there are the articles for the Eastern Hemisphere and Western Hemisphere, which have references for two different capitalizations, and the articles are inconsistent and both use various capitalizations! The template {{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)

Page ranges

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. Headbomb {talk / contribs / physics / 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)

Date format ambiguity

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 MOS:DATEUNIFY we have the section:

  • Access and archive dates in references should be in either the reference format, or YYYY-MM-DD
In the same article, do
  • Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009.

or
  • Jones, J. (20 Sep 2008) ... Retrieved 2009-02-05.

or
  • Jones, J. (September 20, 2008) ... Retrieved 2009-02-05.

but not
  • Jones, J. (20 Sep 2008) ... Retrieved February 5, 2009.

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. Headbomb {talk / contribs / physics / 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 "Wikipedia:Citing sources explains process and standards for citing references in articles." The 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)

Deleted an archive

Just wanted to let all of you know that I've deleted Wikipedia:Manual of Style/(dates and numbers)/Eras - Archive2 (created in 2005), because the creator blanked it just two minutes after creation, and since that time it's never had any content except deletion templates and a category. There's significant content on the talk page, so I didn't delete that. I don't know how this page's archiving is normally done, so I just wanted to make sure that people who do know were aware of this situation. Nyttend (talk) 13:04, 11 July 2011 (UTC)

Conversion of acres: can we write a bit more detail into the guideline?

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 m2 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^6 sq ft (1.0×10^6 m2) 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 ×106. (“The $6 billion project is projected to include 11 million square feet (about 1,000,000 m2) of space on 61 acres (25 ha). Plans call for 1,908 thousand square feet (177,300 m2) of office and medical space, 5,200 thousand square feet (483,100 m2) comprising 3,200 residential units, 3 hotels providing and estimated 1,800 to 2,300 rooms in 1,575 thousand square feet (146,300 m2) of space with 475 thousand square feet (44,100 m2) of retail. The area is also expected to include 60–100 thousand square feet (6,000–9,000 m2) 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.

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

Good examples. I'd be interested in what people think about the following similar sizes:
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 km2, acre to ha, sq ft to m2. Predictable output is important. The user can always override the default. −Woodstone (talk) 04:15, 14 July 2011 (UTC)

BC/BCE yearspan guideline issue

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)

Date template

Is there any reason this page doesn't mention {{date}}? This can be used to automatically format dates like the old system but doesn't link them. We ought to think about when it should or shouldn't be used.--Doug.(talk • contribs) 23:25, 15 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. {{date}} does what linked dates did but without the link (though it can do that too).--Doug.(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. --Doug.(talk • contribs) 04:59, 18 July 2011 (UTC)
Did you mean me? As I said, I've never used it. But the date template document (assuming it can be fixed) doesn't match your description, especially "it just may appear different for two different users". The document says the second parameter choices are dmy, mdy, ymd, iso, and blank which defaults to dmy. So if the second parameter is dmy for instance, then won't everyone see dmy regardless of their Wikipedia:Preferences?
If not, date preferences never made much sense anyway. They only work if you have an account, and if you have an account you're almost certainly an editor, and if you're an editor you should look at dates the way most readers see them on Wikipedia, not how your country sees dates off Wikipedia.
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. --Doug.(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.--Doug.(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.--Doug.(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.--Doug.(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)

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)

Contradictory guidance on the symbol for litre

The guidance says:

and

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: International Bureau of Weights and Measures (2006), The International System of Units (SI) (PDF) (8th ed.), 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)

circa

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:
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 WP:YEAR guideline already settles the question about "c.", and that it should be unitalicized. When the guideline uses italics for the spellings-out ("circa", etc.), I read that as an emphasis on those words, and not a recommendation that they be italicized. Similar to an earlier example (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)

Edit request from Jojotruth1, 20 July 2011

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)

Guidance on symbol for litre

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:

Permit 'l' without prefix Permit mix of 'L' and 'ml' in article Supporters Comment
No No Jimp, Jc3s5h
No Yes Current guidance
Follow guidance in BIPM SI brochure Woodstone
Martinvl		 SI guidance

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

Permanent compromise for BCE/CE vs. BC/AD wars?

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.--Doug.(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 Public Broadcasting System. I believe the documentary was about the Holy Land, though I don't recall exactly. :) --Doug.(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 Second coming. The catch is that we don't really know when will that happen, although every while a True Prophet™ makes a prediction. 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)

Considered joining WikiProject Measurement?

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

GiBberish

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

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

Section called 'Unnecessary vagueness'

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

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

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

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)

Units of measurement: TOTAL MESS

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)

Ref date formats

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)

Templates: height and convert

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:

Height template Convert template Comment
{{height|ft=5|in=6}}
5 ft 6 in (1.68 m)		 {{convert|5|ft|6|in|2|abbr=on}}
5 ft 6 in (1.68 m)		 Identical.
Height template actually uses the convert template
{{height|m=1.68|precision=0}}
1.68 m (5 ft 6 in)		 {{convert|1.68|m|0|abbr=on}}
1.68 m (5 ft 6 in)		 Identical.

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:

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...

Units which are familiar to all but a non-sizeable minority of readers from the corresponding part of the world
Quantity US UK and some∗ of the Commonwealth Most of the rest of the world
Length inch, foot, yard, mile inch, foot, yard, mile millimetre, centimetre, metre, kilometre
Mass ounce, pound, short ton ounce, pound, stone, long ton gram, kilogram, tonne (AKA “metric ton” in the US)
Time second, minute, hour, day, week, month, year, decade, century, millennium same as the US + fortnight same as the US
Speed mile per hour mile per hour kilometre per hour
Temperature °F °C °C
Currency US dollar pound sterling euro
Angle degree, full turn (and simple fractions thereof) degree, full turn (and simple fractions thereof) degree, full turn (and simple fractions thereof)
Power watt, kilowatt watt, kilowatt watt, kilowatt
Energy kilowatt-hour, calorie† kilowatt-hour, calorie† kilowatt-hour, calorie†
Voltage volt volt volt
Volume US fluid ounce, pint, quart, gallon, litre imperial fluid ounce, pint, quart, gallon, litre millilitre, centilitre
Frequency megahertz, gigahertz megahertz, gigahertz megahertz, gigahertz
Information bit, byte, kilobyte, megabyte, gigabyte, terabyte‡ (same) (same)
  • ∗ Not only space-wise but also time-wise – it's not inconceivable that in some areas 15-year-olds are familiar with different units than 70-year-olds are.
  • † The large one, also known as dietary calorie, kilocalorie, and Calorie.
  • ‡ Provided the context makes clear whether the small ones or the large ones are meant.

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

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 m2)"
  • "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 Wikipedia:Manual of Style (linking) so the advice that conversions are relevant isn't in a footnote. I've also added a table inspired by yours. If it needs amending, please go ahead. Lightmouse (talk) 20:27, 6 August 2011 (UTC)

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

Energy
The millijoule, the joule, the kilojoule & the megajoule. Plus in physics articles the electron-volt, kilo~, mega~, giga~ ... P.S. don't bother with capital "C" calorie it's relatively unused & it more likely to cause confusion than clarity (previously discussed).
Speed
The metre per second, the foot per second, in (aero)nautical contexts the knot & in physics c.
Angle
In maths and physics the radian.

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

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 Kaon and, while they will obviously not understand everything, we shouldn't artificially make them understand less than they could (WP:MTAA); in particular, they shouldn't have to copy and paste a technical term to look it up when we could provide a link to it (within reason, but I'm talking of linking only the first of however many instances of keV are in the article). (And I wouldn't link the joule in 12,345 kilojoules (2,951 kcal) in an Australia-related nutritional article or 1,945 kilocalories (8,140 kJ) in an Europe-related one, either, but I would link “1 joule” in a soft-air article where no conversion would be particularly useful.) ― A. di M.​plé​dréachtaí 10:05, 8 August 2011 (UTC)
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)

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

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

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

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

Quantity Not obscure in US Not obscure in UK Not obscure in rest of world
Length, area, volume Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes. Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes.
Length, area, volume Inch, foot, yard, mile. Plus square yard (based on comments by User:GregL but other editors suggest square foot may also be not-obscure to Americans) Inch, foot, yard, mile. Plus squares and cubes
Length, area, volume Litre Litre. Plus prefixes milli, centi, kilo, mega, giga. Litre. Plus prefixes milli, centi, kilo, mega, giga.
Length, area, volume US fluid ounce, pint, quart, gallon imperial fluid ounce, pint, quart, gallon
Mass Gram. Plus prefixes milli, centi, kilo, mega, giga. Gram. Plus prefixes milli, centi, kilo, mega, giga.
Mass Ounce, pound, short ton Ounce, pound, stone, tonne tonne
Time Second, minute, hour, day, week, month, year, decade, century, millennium second, minute, hour, day, week, fortnight, month, year, decade, century, millennium second, minute, hour, day, week, month, year, decade, century, millennium
Speed Mile per hour <not-obscure unit of length> divided by time <not-obscure unit of length> divided by time
Temperature °F °C °C
Power Watt, Plus prefix kilo Watt Plus prefixes milli, centi, kilo, mega, giga. Watt. Plus prefixes milli, centi, kilo, mega, giga.
Power Horsepower
Energy Kilowatt hour <not-obscure unit of power> divided multiplied by time <not-obscure unit of power> divided multiplied by time
Energy Calorie. Calorie. Calorie.
Voltage Volt Volt. Plus prefixes milli, centi, kilo, mega, giga. Volt Plus prefixes milli, centi, kilo, mega, giga.
Frequency Hertz. Plus prefixes milli, centi, kilo, mega, giga. Hertz. Plus prefixes milli, centi, kilo, mega, giga. Hertz. Plus prefixes milli, centi, kilo, mega, giga.
Information Bit. Plus prefixes milli, centi, kilo, mega, giga. Bit. Plus prefixes milli, centi, kilo, mega, giga. Bit. Plus prefixes milli, centi, kilo, mega, giga.
Information Byte. Plus prefixes milli, centi, kilo, mega, giga. Byte. Plus prefixes milli, centi, kilo, mega, giga. Byte. Plus prefixes milli, centi, kilo, mega, giga.
Others <not-obscure unit> divided by <not-obscure unit> <not-obscure unit> divided by <not-obscure unit>
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×10y metres/x×10y − 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, Kilometers per year, could be created and linked to. I agree that individual links to Kilometer and Year would not help. Jc3s5h (talk) 12:20, 8 August 2011 (UTC)

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)

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)

'Times' character

The template {{times}} is now available, to display a typographically correct 'times' character (&times; 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 &times; 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 &times; 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. Headbomb {talk / contribs / physics / 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 &times; 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)

Clarification needed on WP:DATESNO

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

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:

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

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)

Table of units that shouldn't be linked *in conversions*

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

Quantity Not obscure in US Not obscure in UK Not obscure in rest of world
Length, area, volume Metre/meter Metre/meter
Length, area, volume Inch, foot, yard, mile. Square yard Inch, foot, yard, mile.
Length, area, volume Litre/liter Litre/liter Litre/liter
Length, area, volume US fluid ounce, pint, quart, gallon imperial fluid ounce, pint, quart, gallon
Mass Gram Gram
Mass Ounce, pound, short ton Ounce, pound, stone, tonne tonne
Time Second, minute, hour, day, week, month, year, decade, century, millennium second, minute, hour, day, week, fortnight, month, year, decade, century, millennium second, minute, hour, day, week, month, year, decade, century, millennium
Speed Mile per hour <not-obscure unit of length> divided by time <not-obscure unit of length> divided by time
Temperature °F °C °C
Power Watt, Plus prefix kilo Watt Watt.
Power Horsepower
Energy Kilowatt hour <not-obscure unit of power> multiplied by time <not-obscure unit of power> multiplied by time
Energy Calorie. Calorie. Calorie.
Voltage Volt Volt Volt
Frequency Hertz Hertz Hertz
Information Bit, byte. Bit, byte. Bit, byte
Other Prefixes milli, centi, kilo, mega, giga applied to <not obscure SI units> Prefixes milli, centi, kilo, mega, giga applied to <not obscure SI units>
Other Square and cubes of <not obscure units> Square and cubes of <not obscure units>

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. 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. NoeticaTea? 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 instruction creep. The decision on linking should be made on a case-by-case basis in each individual article, based on factors that can't be distilled as simply as this proposal implies, by editors that are situationally aware of the effect of that link. If there's a disagreement about whether a term should be linked, it should be dealt with via 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. TechnoSymbiosis (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. TechnoSymbiosis (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? TechnoSymbiosis (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)

Proposal: date formats in reference sections

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

  • the guideline permits the use of up to two different formats in the reference section in various permutations
  1. dmy (i.e. 12 August 2011) or mdy (i.e. August 12, 2011) for publication, access and archive dates
  2. dmy (i.e. 12 August 2011) or mdy (i.e. August 12, 2011) for publication and archive dates and yyyy-mm-dd (i.e. 2011-08-12) for access dates
  3. dmy (i.e. 12 August 2011) or mdy (i.e. August 12, 2011) for publication dates and yyyy-mm-dd (i.e. 2011-08-12) for access and archive dates
  4. yyyy-mm-dd (i.e. 2011-08-12) for for publication, access dates and archive dates

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

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

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

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

Support

  1. as proposer. --Ohconfucius ¡digame! 09:50, 7 August 2011 (UTC)
  2. Making this consistent makes a lot of sense. We should be making things consistent for our readers and the scripts that run on our articles. GFHandel ♬  10:04, 7 August 2011 (UTC)
  3. I'm all for consistency generally. Nearly always it helps readers, even if it's just a matter of not slowing them down. I see no reason for an exception here. NoeticaTea? 00:03, 8 August 2011 (UTC)
  4. Internal consistency within an article is important, but I do stress that the consistency in the article text should not be taken as the required date format for references. --MASEM (t) 13:47, 8 August 2011 (UTC)
    So, in other words, you oppose this "proposal", which would require that all dates in references match the article body, unless all dates in refs are done in yyyy-mm-dd. (And I put quotes around the word "proposal" because the user "proposing" has ensconced his text in the MOS and has refused to remove it.) Gimmetoo (talk) 19:07, 8 August 2011 (UTC)
    Your over-vivid imagination is getting the better of you. You want to see this proposal defeated, because you imagine that it amounts to removing all yyyy-mm-dd dates from reference sections. It doesn't, and Masem realised that his comment is spot on with the proposal. --Ohconfucius ¡digame! 12:28, 12 August 2011 (UTC)
    Hmm, my imagination must be equally over-vivid. "all dates in references match the article body, unless all dates in refs are done in yyyy-mm-dd" does seem to match "Date formats may be the same as prevailing in the body of the text ... or they may be in the yyyy-mm-dd format" and the "Correct"/"Incorrect" table, better than it matches "removing all yyyy-mm-dd dates from reference sections". However, Masem's "consistency in the article text should not be taken as the required date format for references" is compatible with the proposal, which makes yyyy-mm-dd references the only allowed exception to that consistency. Art LaPella (talk) 18:06, 12 August 2011 (UTC)
    You're reading something into the proposal that's not there. It basically boils down to 4 cases: (assuming no pre Gregorian source dates are in player)
    1. Article body uses dmy, references use dmy
    2. Article body uses dmy, references use yyyy-mm-dd
    3. Article body uses mdy, references use mdy
    4. Article body uses mdy, references use yyyy-mm-dd
    The choice of dmy or mdy depends on the nationality of the topic and/or the decision of the first author, while the choice to use that format or the ISO-like one is left to first author. --MASEM (t) 12:06, 13 August 2011 (UTC)
  5. Strong support. Logical, professional. Gimmetoo, your predilection seems to be for inconsistency and date formats that you find easy but our readers won't understand. Tony (talk) 12:16, 10 August 2011 (UTC)
  6. Support. I think it's important that inconsistency in dates be eliminated. For example, in the case of 1996-7-4, an inconsistent Wikipedia could cause ambiguity as to whether or not the date was July 4 th or April 7 th. Even if this isn't the order that ends up being used, I support an effort to standardize the smaller things that have the potential to cause confusion, and can only echo Noetica and GFHandel. Tutleman (talk) 18:29, 11 August 2011 (UTC)
  7. Support. As others have said: makes sense, logical, professional. Having ref dates consistent already comes up almost always as a condition for FAC/FLC. I would maybe just suggest toning it down a bit. Copy the line which reads, "Dates in article body text should all have the same format". If some people still think this is too much, you could even add "generally" to the proposed line...? Nightw 11:44, 12 August 2011 (UTC)
  8. We should be using the same date system throughout the entire article, actually, but that's beside the point. I'm just not sure why some people insist on using YYYY-MM-DD in only part of it. Consistency is a minor detail but makes us look more professional in the long run, as opposed to a bunch of different pieces cobbled together. /ƒETCHCOMMS/ 15:39, 12 August 2011 (UTC)
  9. Strong support Regardless of what format the rest of the article is using, all of the references should be using a single format. Ideally, the same format used in the body of the article should be used in the reference list. Using two, three or more date formats in the references alone is unprofessional and sloppy. Imzadi 1979 → 19:37, 12 August 2011 (UTC)
  10. Support. I have no idea how we developed the trend of putting most of the dates in one format and all the access dates in another format. I'd hazard a guess that people only do this because they've seen it elsewhere. It's nonsensical, just as mixing British and American language would be. Any date format is fine, but there's no reason to use more than one within an article. The "Oppose" votes seem to boil down to "Our watchlists will be flooded with ugly edits" which isn't a rationale for leaving the articles in a weird state. Get a bot to do it so you can hide it. —Designate (talk) 06:34, 13 August 2011 (UTC)
  11. Support It’s not about what makes wikipedians happiest (“I get to see my preferred date style salted throughout the bottom of this article!”); it’s about our readership. Consistent date formats within an article are better so consistency should be encouraged. Greg L (talk) 22:28, 14 August 2011 (UTC)
  12. Support. Consistency is as key in an encyclopaedia as the information it presents. 21655 T/01 22:05, 16 August 2011 (UTC)
  13. Support. It looks more professional to have a consistent date format in the references section. Jenks24 (talk) 22:21, 16 August 2011 (UTC)
  14. A reference section that is inconsistent on something as simple as date format, and looks as if it was cobbled together by various people who did not take the time to check what others had done, appears unprofessional. And while many articles are written by multiple editors acting separately, this fact should not be so blatantly apparent in the product that we present to readers. I care little which date format is used in a reference section, but I abhor those which alternate between date formats like drunken square dancers. -- Black Falcon (talk) 18:50, 19 August 2011 (UTC)
  15. Support. Full support to ISO format. --Dch (talk) 10:27, 23 August 2011 (UTC)
  16. Support. I thought this was already the guideline, to be honest. Certainly inconsistency across the references sections of articles just looks untidy and gives the impression that Wikipedia is disorganised and less trustworthy. Ideally, of course, software would be handling date preferences properly, but that seems to be surprisingly complicated (for reasons I've never quite bothered to understand). Whilst it would be good for the references section to have a consistent date format with the article, I think itnernal consistency across the references would at least be a good start. — OwenBlacker (Talk) 12:08, 23 August 2011 (UTC)
  17. At the risk of supporting another date/MOS war I'd say that consistency in dates is generally a good thing. Protonk (talk) 20:41, 28 August 2011 (UTC)
  18. Support. Standardization doesn't confuse readers any more than non-standardization. WikiPuppies! (bark) 00:56, 31 August 2011 (UTC)
  19. Support, no reason I can think of why we should be inconsistent (excluding titles and quotations, as the proposal does), but as this is a guideline then if there is a reason on a specific article to be different then that's fine. As long as nobody goes overboard with enforcement then there wont be any downsides to this. For example, other than perhaps featured articles, there should be no reason to edit a page solely to change the formatting of dates in a reference section. Thryduulf (talk) 17:12, 6 September 2011 (UTC)
  20. Support Consistency is desirable, æsthetically pleasing and logical. Inconsistency is not, it's jarring and serves no purpose. I'd like this to be taken further and have a consistent style throughout the article. JIMp talk·cont 20:14, 6 September 2011 (UTC)
  21. Support Consistency is desirable. I would support the use of YYYY-MM-DD for access dates, and DMY for everything else. — Kudu ~I/O~ 23:00, 8 September 2011 (UTC)

Oppose

  1. Oppose. There is no real problem that needs to be solved. Nothing is wrong with a mix of date formats in the references and notes as long as each date is unambiguous. −Woodstone (talk) 10:21, 7 August 2011 (UTC)
  2. oppose - although I follow the arguments I don't see this as a problem either: the reference sections I've seen look nothing like the above examples and tend to have so much formatting diversity that whether dates are consistent gets lost in the noise. Making this a guideline will lead to a series of trivial and inconsequential edits as editors 'fix' this. And what is the format that should be preferred? It's more than a simple binary like EngVar, there are a number of variations, so it can't be just the one in the majority. How to decide what to change them to? Looking at the article isn't enough as many articles have no dates in them.--JohnBlackburnewordsdeeds 00:15, 8 August 2011 (UTC)
  3. oppose - by indiscriminately referring to "yyyy-mm-dd" and "ISO-8601" the passage implies two falsehoods, that these are the same thing, and that Wikipedia has taken a position about the use of ISO-8601 in any part of articles. Jc3s5h (talk) 00:51, 8 August 2011 (UTC)
    In addition, one format, APA Style, calls for publication dates to be in the format YYYY, Mmmmm DD and for the inline parenthetical citation to be (Surname, YYYY). Note that the month and day are omitted, even if they are present in the publication date. If the article does not add some form of hyperlink between the citation and the bibliography, or if the article has been printed, having the year first in the date format makes it easier to find the bibliography entry. This illustrates that style guides may use a peculiar date format for a functional reason, not just a preference. Jc3s5h (talk) 15:34, 17 August 2011 (UTC)
    Actually, the proposed guideline text doesn't mention ISO at all. ― A. di M.​plé​dréachtaí 09:37, 23 August 2011 (UTC)
    It did at the time I made the comment. Jc3s5h (talk) 15:31, 23 August 2011 (UTC)
  4. Oppose. This has been discussed before, and there has never been a consensus to either forbid different ref styles in the text and article (because APA style, for one, does that), nor to forbid putting different types of dates in the references in different styles. OhCon's proposal would result in articles like [5] (97 refs, almost entirely with publication dates in mdy and accessdates in yyyy-mm-dd) becoming [6] (all dates in refs changed to mdy, when AFACT no ref had mdy for both types of dates). These sort of changes are bad. They make it difficult for the article's regular editors to read diffs over the edit, and they make the references themselves harder to parse for at least some people. Gimmetoo (talk) 19:48, 8 August 2011 (UTC)
    Incredibly, OhCon made [7] just recently. Before, the 107 references were nearly all yyyy-mm-dd, but after, everything was changed to mdy. That sort of edit goes contrary not only to the MOS prior to OhCon's "proposal", but is even contrary to OhCon's own proposal here. Gimmetoo (talk) 20:40, 8 August 2011 (UTC)
    Yeah, he does that. This older gem also included a date format change to a quote from a printed source as an extra bonus. Quale (talk) 05:36, 9 August 2011 (UTC)
  5. Oppose Per Woodstone, JohnBlackburne, Gimmetoo, et al. The current section does not lead to any problem, and reflects consensus. Headbomb {talk / contribs / physics / books} 20:55, 8 August 2011 (UTC)
  6. Oppose  I'd go the opposite direction, I'd standardize on yyyy-mm-dd format for access dates, and discourage yyyy-mm-dd format elsewhere in the reference.  Unscintillating (talk) 01:36, 9 August 2011 (UTC)
    I don't know why you voted 'oppose', because the proposal is much closer to what you want than happens today. It doesn't preclude what you want to see, just does not insist upon it for every single article. The advantage is that all date formats will be consistent in the refs section, and they might just all be yyyy-mm-dd. --Ohconfucius ¡digame! 12:31, 12 August 2011 (UTC)
    The proposal reads, "all dates in the reference sections are uniformly consistent".  I'm opposed to a consistency that in fact makes it harder to tell the difference between the access date and the publication date.  The access date is information about the citation rather than being a part of the citation itself.  For readability, I would prefer that access dates always use yyyy-mm-dd, and that publication dates never use yyyy-mm-dd.  Unscintillating (talk) 10:42, 13 August 2011 (UTC)
  7. Oppose Proposal lacks guideline for a procedure for deciding what format to use when dates are not consistent. Existing scripts are being used to just remove yyyy-mm-dd whenever there is any discrepancy in date format, ignoring WP:DATERET. Proposer's script talk page says:
    "While I will do my best to comply with the minute detail of style guidelines, I will work with what is on the face of the article, and will target articles where I detect a misalignment of formats by a quick scan. I am unlikely, for reasons of productivity, to comb through each article's history to establish whether an article should be dmy or mdy, or whether a the first date included in a reference section was yyyy-mm-dd or not. If you want articles on your watchlist to retain any given format (or for it to have all yyyy-mm-dd dates in the accessdate field), you should ensure that the all of dates are in aligned in accordance with WP:MOSNUM, otherwise I consider them 'fair game'."
    YYYY-MM-DD is one of the three date formats used in Canada, as a Canadian I do not want it obliterated from wikipedia, and this proposal (+ scripts) seems to be a backdoor way of doing that. In the event that this proposal receives community support, no action should be taken on it without first obtaining agreement on a decision procedure in cases of inconsistency. --JimWae (talk) 09:02, 13 August 2011 (UTC)
  8. I'd go with: The main article text, excluding tables, lists, and the section References, should use either 13 August 2011 or August 13, 2011, consistently; the section References, excluding access dates, should use either the format of the rest of the article or the same format with abbreviated months[Note 1] consistently; access dates should use either the format of the rest of the section References or 2011-08-13 consistently. Each table/list should be handled on a per-case basis depending on column width, sortability etc. using the main article text format, the same with abbreviated months, or (provided all dates are Gregorian in the 1583–9999 ranges) 2011-08-13 (but don't mix them in the same table column). ― A. di M.​plé​dréachtaí 14:27, 13 August 2011 (UTC)
  9. And stop changing articles with scripts. -- Jeandré, 2011-08-14t11:06z
    This is a request for comment. I don't think your entry can be taken seriously, since it contains only a veiled personal attack. Thank you. Tony (talk) 11:17, 14 August 2011 (UTC)
    Apologies if it looks like an attack, that wasn't my intention. I meant that I oppose the proposal, as explained on the linked talk page, and that date changes should not be done with scripts. -- Jeandré, 2011-08-15t12:50z
  10. Bad idea. I'm not sure even the unification in the current guideline is appropriate. It would make sense for publication dates of weekly magazines, weekly newspapers, or daily newspapers to be MDY for US sources and DMY for UK sources (or with the abbreviations suggested by User:A. di M.. The access date format (and archive date format) should be consistently (1) the article date format, (2) the date format appropriate to the reference, or (3) YYYY-MM-DD. — Arthur Rubin (talk) 23:50, 14 August 2011 (UTC)
    I don't get... are you suggesting that for any given article, that publication dates for all US sources take up the mdy format while if there are citations to The Times or The Guardian that they be in dmy? --Ohconfucius ¡digame! 03:36, 15 August 2011 (UTC)
    It seems to me to be a preferable style, but certainly should be an acceptable style; the format of the publication date (if dmy or mdy; my is the same in either case) should be set by the publication. — Arthur Rubin (talk) 18:23, 15 August 2011 (UTC)
    Just curious... If you were citing an article in a Russian journal, would you write the publication date in Russian? ― A. di M.​plé​dréachtaí 09:37, 23 August 2011 (UTC)
  11. Oppose - Don't think inconsistent date formats within the reference section are a problem. Especially accessdate versus publication date. Rlendog (talk) 15:32, 15 August 2011 (UTC)
  12. Oppose. CITE says that editors may use any citation style they want, including styles that use different date formats to signal different styles of information. WhatamIdoing (talk) 17:58, 17 August 2011 (UTC)
  13. Oppose - I think decisions on date formatting in references should be done by humans on an article-by-article basis, with the degree of uniformity needed decided by humans, not scripts or bots. There are valid arguments for the accessdate and publication date to be different formats for readability and for readers to be able to visually distinguish them, and there is also a valid argument that it is best to use the publication's own style for publication date (if necessary, a hidden conversion to Wikipedia publication date style can be included, but the original "untranslated" date style should be recorded somewhere to allow checking for errors in transcription). Carcharoth (talk) 23:58, 20 August 2011 (UTC)
  14. Oppose There is no real, demonstrable ill effect from this inconsistency, just more MOS nit-picking. Beeblebrox (talk) 18:00, 26 August 2011 (UTC)
  15. Oppose. Per Headbomb and JimWae. Nanobear (talk) 19:47, 28 August 2011 (UTC)
  16. Oppose Solution in search of a problem. yyyy-mm-dd is often preferable for the accessdate and archivedate due to its brevity and the fact that those fields are often edited programmatically; most readers don't care about them anyway. User:A. di M.'s comment accurately represents my understanding of what the current consensus is, and I would support his comment as a proposal. --Cybercobra (talk) 05:10, 30 August 2011 (UTC)
  17. Oppose Current policy is adequate. Perhaps this could become FA criteria, but not a site wide imposition. My76Strat (talk) 20:19, 1 September 2011 (UTC)
  18. Oppose The MOS is a style guideline, not a style enforcement rulebook. It would be impossible to ignore the intention behind this RfC, to justify mass, scripted, bike-shed, changes to tens of thousands of articles, steamrolling the inevitable per-article opposition to this that will arise. Gigs (talk) 14:25, 13 September 2011 (UTC)
    That really is the lamest reasoning I've heard for a long long time. Tony (talk) 14:51, 13 September 2011 (UTC)
  19. Oppose Utter waste of time. Toohool (talk) 06:56, 14 September 2011 (UTC)
  20. Oppose, rulemaking for the sake of having a rule. Stifle (talk) 13:04, 14 September 2011 (UTC)

Notes

  1. ^ Typically Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec in BrE and Jan. Feb. Mar. Apr. May June July Aug. Sept. Oct. Nov. Dec. in AmE}}

Neutral

Discussion

  • I notice you still have not reverted your change. Anyway, I reject your point #2 and also #3,4,5. You claim a mix of date formats is "asthetically displeasing and difficult to parse". For you, a "mix of formats" includes a reference section where all the publication dates are one format and all the accessdates are another - a quite common format on Wikipedia. So apparently, there are other people who do not find it "aesthetically displeasing". Likewise, when different types of information is represented in different formats, I would expect at least some people would find that easier to parse. And that is why publication and access dates are treated differently by some editors, and why we have to point this out during past attempts to change the guideline. But I don't need to convince you; you need to convince everyone else. You're the one making the change. Gimmetoo (talk) 09:34, 7 August 2011 (UTC)
    • I am not saying the yyyy-mm-dd format is uncommon; I say having such a mix makes the dates more difficult to parse. I am proposing that they should be a single format for all dates. --Ohconfucius ¡digame! 09:48, 7 August 2011 (UTC)
  • To the question of what format should be preferred, it should fall to standard of "first editor choice" as with nearly all other choices of which format to us. I would argue that if the article is tied to a specific nationality and thus has chosen to use US or Int-style dates in the body, then the opposite should be avoided in the reference text. --MASEM (t) 13:50, 8 August 2011 (UTC)
  • The newly revised description of the background to the issue states "the guideline permits the use of up to two different formats in the reference section in various permutations". No. The guideline before Ohconfucius' bold change stated "Publication dates in article references should all have the same format." (An exception for archive and access dates followed.) This wording prevents a conflict with WP:CITE, which allows any citation format, and specifically mentions APA style, which uses YYYY, Mmmm DD for publication dates in the bibliography. Jc3s5h (talk) 15:01, 12 August 2011 (UTC)
  • OK, now I see what you mean; any particular reference section may have up to two date formats, but collectively throughout all the guidelines-compliant articles in the encyclopedia, there may be many date formats, depending on which citation style was followed in each article. Theoretically there could be a citation style that calls for three different date formats, but that seems very unlikely. Jc3s5h (talk) 15:41, 12 August 2011 (UTC)
  • Question: do the automated citation bots use the style of the publication or do they "translate" it into a preferred Wikipedia style? It would seem silly to have one bot bring in the data and another to tweak it after it arrives here. Carcharoth (talk) 00:02, 21 August 2011 (UTC)
As illustrated by this edit, User:Citation bot adds dates without respect to what format is already in use in the article. Jc3s5h (talk) 00:54, 21 August 2011 (UTC)
Dates without a written-out month are just plain inconsiderate to our international readership. Reference sections with inconsistent date formats are unprofessional. Tony (talk) 01:16, 27 August 2011 (UTC)
Agree, except it's inconsiderate to all our readership. What does 7-9-1981 mean? September 7 or July 9? There's no way to know. Dates like this should never be used. Everything else is secondary compared to this -- whether it should be August or Aug, or whether it should or must be consistent within the article, or whether it should always be 8 June or always June 8 or vary from article to article. It's important and useful to work all that out (or decide to go with laissez faire), but for God's sake we must never use numbers for months outside of quotations or like exceptions. Herostratus (talk) 03:12, 27 August 2011 (UTC)
This "proposal" has nothing to do with dates like 7-9-1981, and nothing to do with reference sections where different references are in different formats. It's mostly about a couple points, really. It's about abbreviations in references, and it's about whether reference sections consistently using date formats such as
  • Last, First (29 July 2011). Main Page. WP. Accessed 2011-08-28.
(where the publication date and accessdate are consistently rendered in distinct formats) are to be forbidden. Gimmetoo (talk) 15:58, 28 August 2011 (UTC)

Suggested modification

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

  • Except for titles and quotations, dates in each article's reference section should all have the same format, which may be the format prevailing in the body, the format specified in any style guide the reference section follows, or yyyy-mm-dd:
  • The yyyy-mm-dd format shall not be used in any article that is likely to contain dates before 1583 or dates in a non-Gregorian calendar.

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

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

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

  • Still unsure. You seem to suggest allowing YYYY, Mmmm DD in the refs section, and not to do so would violate WP:CITE. While it is theoretically allowed, I have come across such use in less than a handful of articles, and even so, only one or two instances in each article. I have seen more instances of erroneously used formats – like 18-1-99, 18-1-1999, 18-01-1999, 18-Jan-1999 – than this, so I believe it is quite moot in practice. --Ohconfucius ¡digame! 03:23, 8 August 2011 (UTC)--Ohconfucius ¡digame! 03:23, 8 August 2011 (UTC)
I don't see how the second bullet point above can be enforced. Some countries use the Revised Julian calendar, which is identical to the Gregorian calendar from 1 March 1600 until at least 28 February 2400.
Isn't ISO 8601 itself unenforceable because some countries object to having the Gregorian calendar rammed down their throats when they have rejected it for something better? 92.24.110.78 (talk) 10:23, 8 August 2011 (UTC

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

Counter-proposal

I suggest removing the text currently in the guideline:

  • Except for titles and quotations, dates in each article's reference section should all have the same format, which may be the format prevailing in the body, or yyyy-mm-dd:
Correct Incorrect
Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009 Jones, J. (20 September 2008) ... Retrieved 5 Feb 2009
Jones, J. (20 Sep 2008) ... Retrieved Feb 5, 2009
Jones, J. (20 September 2008) ... Retrieved 5 February 2009 Jones, J. (20 September 2008) ... Retrieved February 5, 2009
Jones, J. (2008-09-20) ... Retrieved 2009-02-05. Jones, J. (20 Sep 2008) ... Retrieved 2009-02-05
Jones, J. (2008-09-20) ... Retrieved 5 February 2009

I would replace it with the following:

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

  • Initial reaction: I'm not aware nor am I particularly interested in how the two guidelines evolved, but there's definitely a lot more than dynamic tension here. Wikipedia ought to have a house style for citations, and we should only be referring to external guidelines where we don't have one of our own. And when there is a house style, which we seem to have (more or less), we ought to marginalise external guidelines. The tolerance of other styles in WP:CITE appears counter-intuitive to me, and a recipe for a 'free for all'. The disadvantage, of course, is that same external guidelines are usually inaccessible to a majority of editors, as opposed to wide and full availability for in-house guidelines, thus imperfect information as to how they are to be interpreted and used. Arguments cannot be easily resolved by reference to same (due to said unavailability), thus enforcing the tendency to WP:OWN in some cases. --Ohconfucius ¡digame! 02:02, 9 August 2011 (UTC)
  • There are arguments for and against a house style, but adopting my counter-proposal would not promote or retard a house style, it would just prevent conflict between this guideline and WP:CITE. Jc3s5h (talk) 12:42, 9 August 2011 (UTC)
I'm in favor of a house style, or limited set of choices, and agree that for citations it would be better at WP:Citing sources#Dates. Dicklyon (talk) 03:15, 27 August 2011 (UTC)


Would an admin close this discussion? Thanks, Cunard (talk) 05:20, 28 September 2011 (UTC)

Would an admin close this discussion? Thanks, Cunard (talk) 20:25, 14 October 2011 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Conversions of ratios embedded in prose

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

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

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

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

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

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

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

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

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

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

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

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

I think guidance can:
  • document the outcome of a dispute that may reoccur
  • define how to fix a common and significant problem that wouldn't be fixed by the wiki
  • make a difference to what editors actually do
Unfortunately, I think guidance on this issue would fail on the last bullet. Lightmouse (talk) 18:39, 15 August 2011 (UTC)
I think you're probably right. JIMp talk·cont 02:55, 16 August 2011 (UTC)

Request for Comment: date ranges

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

This also applies to this paragraph: "Year ranges, like all ranges, are normally separated by an en dash, not a hyphen or slash: 2005–06 is a two-year range, whereas 2005/06 is a period of twelve months or less, such as a sports season or a financial year."
In my opinion, years should always be expressed in full, that is, with four digits (no leading zeros) for years after year 999. This is in accordance with "Write out the full year string instead of using the apostrophe (') to abbreviate the first two digits of the year."
A form such as "2005–06" is highly conflictive, since this is also a valid form in the international date format according to ISO 8601, which is the more or less "official" standard date format in many European countries. Many people would simply interpret this as "June 2005", not as "2005–2006". While this cannot happen with "1881–86", it looks odd (to me) and is in conflict with the rule to express years in full. We should change that accordingly. --Matthiaspaul (talk) 10:38, 12 August 2011 (UTC)
As an aside the bit you quote is not what happens in practice as sports seasons use the en-dash and not the slash as implied by the quote. Keith D (talk) 11:38, 12 August 2011 (UTC)
I agree that date ranges should be written in full, especially given the potential for confusion with ISO 8601 dates. I'm frankly surprised we don't already recommend this. Kaldari (talk) 16:00, 12 August 2011 (UTC)
Two digits are definitely preferable in most AD/CE instances. Tony (talk) 10:29, 16 August 2011 (UTC)
See above, not a requirement nor preferable in most research and academic work. FWiW Bzuk (talk) 11:56, 16 August 2011 (UTC).
In the hundreds of articles I have checked or edited the dates have always been expressed in full, ie, four digits. This is also what I was used to in years of technical writing. Only recently have I come across an editor who was engaged in changing the four-digit format back to two digits in a great many biographical articles. I commented on this on his talk page (no response, and the practice continued). However, the MoS seems to say that both forms are OK, and I feel that this is inadequate. Hohenloh + 14:38, 18 August 2011 (UTC)
Google Books searches don't support the claim above. 1941–45, 132,000 hits. 1941–1945, 215,000 hits, not "always", and certainly not always out of "hundreds of articles". 1982–84, 114,000 hits. 1982–1984, 123,000 hits. Again, not always. Art LaPella (talk) 21:51, 18 August 2011 (UTC)

I brought this up recently. The resulting discussion is probably in the archives somewhere. My position is that short date ranges are more commonly written with two closing digits (e.g. 1914-18 and 1939-45), but that writing it out in full is also common. I think that when writing out a person's birth and death years, it is vital to write the death year out in full no matter what the context. This is because these years are so central to identifying people, especially those with the same or similar names. It is also a matter of style. Aesthetically, it looks better if the closing year is uniformly written the same way, not varying depending on the context, so the full closing year is best. Finally, as a reader, when looking for information in an article or list, I often know the year something happened and search for that to find it in the article (often I find people have neglected to name the year and that is something that can be corrected). Similarly, when trying to identify people (often relatively obscure 19th century naturalists) when I have a name and no birth or death year, I sometimes find what might be the birth or death year, and then do a new search including that year, and get the results I need. For obvious reasons, it is best to be able to search on the full year, not an abbreviated version. Carcharoth (talk) 15:55, 29 August 2011 (UTC)

Please see RfC on citation style

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

Where it's being asserted, indirectly, that the advice on this page under Full date formatting insofar as it refers to references, does not represent current consensus. Does anyone have anything to say about that?--Kotniski (talk) 18:16, 13 August 2011 (UTC)
Hello? Is there any further interest in this question? We need to resolve it - it makes no sense to have two guidelines saying apparently different things and not even acknowledging each other's existence.--Kotniski (talk) 07:07, 17 August 2011 (UTC)

year range in lede

Per MOS biographies, I added a note that if the full dates are provided by an infobox or in the text of the article, a simple span of years is sufficient in the lede. This follows the general principle of reducing clutter in the lede. Although I have added quite a few pronunciations to biography articles, I would encourage those to be moved to an infobox as well. (This has been done systematically with astronomical bodies.) — kwami (talk) 23:24, 21 August 2011 (UTC)

I strongly agree with moving pronunciation to the infobox. Did you start a thread about that somewhere? —Designate (talk) 15:53, 22 August 2011 (UTC)
The idea that the pronunciation should be moved out of the lede has been in WP:PRON for months. But a thread has been reopened here. — kwami (talk) 22:01, 24 August 2011 (UTC)
Yes, I keep arguing to have biographies comply with the same style guidelines as other articles with respect to lead sections only giving context and a notability summary. It was already implied by the "...or days and months would be irrelevant detail" clause but I agree your proposal makes it more explicit. Other editors still often revert to full dates in the lead, alas. My related pet peave is people who put details into the lead or infobox to avoid a citation. Not sure if it needs to be stated here explicitly, every detail in a lead or infobox should be mentioned in the body with a citation. Perhaps not critical for pronunciations, not sure about those, but dates should be in the body too. W Nowicki (talk) 17:57, 22 August 2011 (UTC)
I often see details ref'd in an info box. I mean, as you say, do we really need to repeat the pronunciation in the text? I'm accustomed to astronomy articles, where there are all sorts of orbital and physical details (eccentricity, inclination, semimajor and semiminor axis, major & minor radius, volume, gravitational field) which, if not remarkable, are not mentioned in the text. They're simply sourced in the info box. I know the box is supposed to only summarize what's in the text, but we completely ignore that in linguistics and astronomy articles. For stubs, the box often is the article: A lede to summarize the topic, and a box for all of the actual data. Only when the article is expanded beyond a stub will some of the infobox data appear in the text, but then only if it's noteworthy. It's a lot harder to access it in the text.
I can see leaving in the birth date of, say, Barack Obama, as, although it's not exactly notable, I expect there may be a fair number of people looking for that datum. But it's probably only relevant for living people, and very few of those. Similarly, if someone important just died, I could see leaving the full date in the lead for maybe a year. But once everyone knows they're dead, or in any case it's been more than a year, I can't see how the month and day are particularly relevant. Most of the time, anyway. There will always be exceptions, but IMO we should argue for an exception before adding what amounts to trivia immediately after the bold title phrase in the lede. — kwami (talk) 06:05, 23 August 2011 (UTC)
Yes, sure, but I think in general we should avoid people writing unreferenced stubs, as well as stubs with just infoboxes and one sentence. There are way too many already. Assuming "someone else" will expand it in the futureis a bit inconsiderate. If you have the source hand, add the source and type a sentence with the information. Otherwise the source will not be known by the future editor. But of course ened to be practical. W Nowicki (talk) 23:05, 24 August 2011 (UTC)
We're talking at cross purposes. Of course we need to ref things. But that has nothing to do with whether they should go in the lede or in the info box. There's no way most people are going to create a text that is just a string of statistics. That's much more accessible in an info box, even if there's hardly anything left for the text itself. — kwami (talk) 23:41, 24 August 2011 (UTC)
I've been very concerned at the amount of clutter at the very opening of some bio articles; it's chiefly pronunciation, alternative names, and non-roman script equivalents. When I visit such articles, I tend to put ref tags around this information so the rest of the sentence (after the first-give name) isn't four lines down. Any practice of shifting some or all of this secondary information to the infobox is a great idea. Without an infobox, I'll still ref it. Tony (talk) 02:33, 25 August 2011 (UTC)
Yes, very rarely do we need foreign transcriptions in the lede either. Take Genghis Khan as I found it:
Genghis Khan (English pronunciation:/ˈɡɛŋɡɪs ˈkɑːn/ or /ˈdʒɛŋɡɪs ˈkɑːn/;[1][2]; Cyrillic: Чингис Хаан, Chingis Khaan, IPA: [tʃiŋɡɪs xaːŋ] ⓘ; Mongol script: , Činggis Qaɣan; Chinese: 成吉思汗; pinyin: Chéng Jí Sī Hán; probably May 31, 1162[3] – August 25, 1227), born Temujin (English pronunciation: /təˈmuːdʒɪn/; Mongolian: Тэмүжин, Temüjin IPA: [tʰemutʃiŋ] ⓘ; [Temüjin] Error: {{Langx}}: text has italic markup (help);[4] traditional Chinese: 鐵木真; simplified Chinese: 铁木真; pinyin: Tiě mù zhēn) and also known by the temple name Taizu (Chinese: 元太祖; pinyin: Yuán Tàizǔ; Wade–Giles: T'ai-Tsu), was the founder and Great Khan (emperor) of the Mongol Empire, which became the largest contiguous empire in history after his death.
How do we expect anyone to read that? Compare the actual lede text:
Genghis Khan (1162?–1227), born Temujin and also known by the temple name Taizu, was the founder and Great Khan (emperor) of the Mongol Empire, which became the largest contiguous empire in history after his death.
Now, the info box of that article is currently overcrowded with all that stuff, but that's because allowance hasn't been made for such things (i.e., no place for birth name, temple name, posthumous name). — kwami (talk) 02:57, 25 August 2011 (UTC)
Exactly. If the first sentence doesn't fit into a Google search result, it's unacceptable. —Designate (talk) 03:20, 25 August 2011 (UTC)
@Tony: I think putting stuff between plain vanilla <ref> tags is a very bad idea, as it's impossible for readers to anticipate that the footnote contains stuff other than a citation of a source. With <ref group="Note">, on the other hand... ― A. di M.​plé​dréachtaí 10:01, 25 August 2011 (UTC)
Yes, that's often a very good way to do it. Also, refs are often in a small font, which we probably don't want to do with notes. However, anything in the infobox will be near the top of the article, whereas the notes will be at the bottom. So IMO full dates belong in the info box (where we currently have them), but Chinese transcriptions of a Mongol name can probably be safely relegated to the notes. IMO the pronunciation of the name used in the article should be in the box, since it may be difficult to read the article without it, whereas you don't need to know the Chinese (or the Mongol, for that matter).
BTW, some time ago I added {{#tag:ref||group="note"}} to the 'Wiki markup' edit window for just these situations. Unlike <ref group="Note">, #tag:ref allows you to place <ref> tags in the notes themselves. — kwami (talk) 10:23, 25 August 2011 (UTC)

A couple of points. Firstly, all the discussion about pronunciation and non-MOSNUM stuff should either be discussed at a different location or unified in a single discussion. In other words, if sweeping changes are to be made to the way biographical articles are written on Wikipedia, a discussion should be opened at WT:BIOGRAPHY and possibly notification left at WP:CENT given the massive number of biography articles on Wikipedia. Also, it would help if a preliminary audit gave an idea of the number of articles this would affect, and how many use the current style? A further point is that many biography articles don't use infoboxes, so it is best to leave infoboxes out of the discussion, or state what should be done where there is no infobox. My view is that a discussion should be undertaken to settle on the style used on biographical articles, rather than piecemeal discussion of different aspects in different places (year range in lede at MOSNUM and pronunciation at PRON is a classic example of splitting up a discussion that should be done altogether in one place). But that discussion should take place at the Biography WikiProject pages, not at MOSNUM. Possibly Wikipedia talk:Manual of Style (biographies) is a another venue, but it is vital that input is obtained from those who write biography articles on Wikipedia, rather than those who write manuals of style. My view is that having the birth and death dates in the lead is fine, but everything else should be seen as clutter and relocated. The reason I think birth and death dates should stay in the lead? Because if you remove them, the lamest edit wars you can imagine will break out between people who want to write 1832-1895 and those who want to write 1832-95. Seriously (and that is on-topic for this page!). Carcharoth (talk) 01:00, 29 August 2011 (UTC)

  • Maybe. But let's not conflate the two issues here... firstly, we have the date, place of birth/death, new-/old-style dates, IPA pronunciation clutter; secondly, we have the hieroglyphics, birth/second/courtesy/alternate names and related pinyin most seen mainly in articles about Chinese subjects. --Ohconfucius ¡digame! 01:50, 29 August 2011 (UTC)
    • When I first started editing biographical articles, I think it was commonplace to include place of birth and death in the lead sentence. That has lessened over time. The standard now seems to be: 'Some version of name (birth date and year - death date and year)' followed by varying amounts of other stuff. The standard now seems to be to mention the nationality (if not too complicated) and profession in the lead, but to wait until the first paragraph of the main body of the article before going into details such as place of birth. The full name and date of birth and date of death tend to be repeated in both the lead and the main article, both because the main article should stand independently from the lead section, and because the main body of the article is often a more convenient place to source things like full name and exact dates and locations. The key is not to remove information if it is not located elsewhere in the article. It would help to survey biographical dictionaries to see what different styles exist, though we can't copy the style used by others, we should use or develop our existing style while avoiding clutter. And please can we move this discussion to Wikipedia talk:Manual of Style (biographies)? I see several earlier comments over there from people who state that they are opposed to removing dates of birth and death from the lead section. So the discussion should really be over there. Carcharoth (talk) 13:33, 29 August 2011 (UTC)
Notes
  1. ^ "Genghis Khan". Webster's New World College Dictionary. Wiley Publishing. 2004. Retrieved July 29, 2011.
  2. ^ "Genghis Khan". Oxford Dictionaries Online. Oxford University Press. 2011. Retrieved July 29, 2011.
  3. ^ Rashid al-Din asserts that Genghis Khan lived to the age of 72, placing his year of birth at 1155. The Yuanshi (元史, History of the Yuan dynasty records his year of birth as 1162. According to Ratchnevsky, accepting a birth in 1155 would render Genghis Khan a father at the age of 30 and would imply that he personally commanded the expedition against the Tanguts at the age of 72. Also, according to the Altan Tobci, Genghis Khan's sister, Temülin, was nine years younger than he; but the Secret History relates that Temülin was an infant during the attack by the Merkits, during which Genghis Khan would have been 18, had he been born in 1155. Zhao Hong reports in his travelogue that the Mongols he questioned did not know and had never known their ages.
  4. ^ Central Asiatic Journal. 5. O. Harrassowitz: 239. 1959 http://books.google.com/books?id=PjjjAAAAMAAJ. Retrieved July 29, 2011. {{cite journal}}: Missing or empty |title= (help)

Abbreviating the word "number"

Is there a policy on abbreviating the word "number"? In articles concerning rail transport, I often see text concerning individual locomotives. Rail locomotives are normally identified by number, and so this text is usually like "No. 123 was built in ..." but sometimes I see text like "Nº 123 was built in ...". Do we have a policy on whether one of these forms is preferable to the other? --Redrose64 (talk) 18:48, 24 August 2011 (UTC)

See: Wikipedia:Manual_of_Style#Number_signs. Regards Lightmouse (talk) 19:02, 24 August 2011 (UTC)
Thanks, but although that explicitly forbids # and № it doesn't mention Nº - it might help if the MoS explicitly stated that the only permitted abbreviation was "No." --Redrose64 (talk) 21:29, 24 August 2011 (UTC)

Perhaps opinions vary, but I usually avoid all abbreviations. My pet peave is "aka" which slips in too many times. Unlike other encyclopedias that are limited by paper, we should have no constraints. On the other hand, there might be some domain-specific styles that use certain well-known abbreviations almost exclusively, the one I think of is HMS or USS for ship names- these are almost never spelled out. You might also discuss at a relevant project page. But when in doubt, spell it out. W Nowicki (talk) 23:01, 24 August 2011 (UTC)

Renaming the page

We're informed that it was agreed to move MoS pages to subpage format, which means this page ought to be called Wikipedia:Manual of Style/Dates and numbers. I can't move it since it's move protected - can someone with admin rights do it (or does someone want to object?)--Kotniski (talk) 11:25, 30 August 2011 (UTC)

Thanks for prompting this, Kotniski. Yep, this has consensus at the MoS project, and is being gradually rolled out. Tony (talk) 11:49, 30 August 2011 (UTC)
 Done Art LaPella (talk) 01:27, 31 August 2011 (UTC)
“Done” you say?! Was there any decision about talk archives? Maybe I should look through the archives, but currently they appear as a pile of red links :P. I guess it would be less trouble to fix the references on this page rather than move all the existing talk archives, judging by WhatLinksHere/WT:Manual of Style (dates and numbers)/Archive 135 versus WhatLinksHere/WT:Manual of Style/Dates and numbers/Archive 135. Or perhaps this is a bot’s work? Vadmium (talk) 13:32, 3 September 2011 (UTC).

No need to worry about numerical pages. Most talk pages deem a search box sufficient for access to archives. Lightmouse (talk) 15:21, 3 September 2011 (UTC)

"When days and months [of birth and death] would be irrelevant detail"

I was puzzled by this guidance: When only the years are known, or days and months would be irrelevant detail: "Socrates (470–399 BC) was..."

Under what circumstances would days and months be an irrelevant detail? I assume we omit the exact dates of Socrates' life because we don't know them, not because they're irrelevant. Why would they be irrelevant? Because dates of people who lived long ago are automatically not relevant, and dates of people who live or lived more recently are automatically relevant? Now that I think about it, if we're making determinations based on relevance, it's hard for me to see the relevance of including the birthdates (beyond the year) of the vast majority of living people who are the subject of Wikipedia articles.

I suggest deleting the phrase about "irrelevant detail," but if there is some meaning to it that I'm missing, I suggest the guideline be clarified to explain the distinction between relevance and irrelevance. Theoldsparkle (talk) 15:23, 6 September 2011 (UTC)

Upon further investigation, I appear to have isolated the discussion that led to this statement being added (under "Full vital dates vs. years"). My understanding is that the main prompt for the change is that editors wanted (for some reason) to include the exact date of birth in the body of the article, and thought it redundant to include the date in the lead, the body, and an infobox, so this change was made to allow them to omit the date from the lead. But isn't that clearly an issue for the MOS on biography articles, not the MOS on how to write the dates? And MOSBIO still says the dates should be included if known, not if they're known and determined relevant. Theoldsparkle (talk) 15:43, 6 September 2011 (UTC)
Removing that is fine with me. There is a minor BLP concern with low profile individuals and identity theft. I could write a full page rant about why we shouldn't have notability guidelines that allow us to have articles on individuals so low profile that their birth date might be secret, but that's an argument for another page. Gigs (talk) 17:39, 20 September 2011 (UTC)
Keep Well, at least in the USA exact dates are often considered private even for high profile individuals. For example, birth cirtificates are considered confidential health documents, so releasing one to the press is illegal as I understand. For those who have not been following the story, one certain somewhat high-profile individual was involved. But even if the dates are known, for the vast majority of articles they are a detail that does not belong in the lead or each mention of a person. Not sure why you claim "for some reason" since the reason was openly discussed before I made the change. Wikipedia:Manual of Style/Lead section is the best guideline. For example, "The emphasis given to material in the lead should roughly reflect its importance to the topic, according to reliable, published sources...." The lead section should summarize the body, so details not in the body should not be allowed in lead sections by that guideline. Certainly the birthdate of someone is important to themselves and their close family, but rarely is it the reason they are notable. We have rehashed this several times, and some people cling to the claim that birthdates always must be important enough for the lead. Certainly some people believe in astrology which should be respected. But unless someone gives a scientific survey that shows most general Wikipedia readers think vital dates are what makes people notable, it is only an assertion of opinion. W Nowicki (talk) 19:30, 20 September 2011 (UTC)
I'm kinda surprised there's suddenly interest in discussing this two weeks after I raised the issue and amended the MOS. Anyway, I believe my main objection still stands: whether to include the dates should be an issue at WP:MOSBIO, not here, and that MOS says the dates of birth should be included, if known. However, I just looked again at the current text of this MOS, and noticed that, at some point since it was altered to add that confusing "irrelevant detail" bit that I removed, someone else added this to the end of the first paragraph of that section: "When full dates are provided in the text or in an infobox, year-pairs can be sufficient for the lede in some cases". So if that's what you're going for, it looks like the MOS already does allow it, and I have no objection to keeping that statement. Theoldsparkle (talk) 21:06, 20 September 2011 (UTC)
This discussion belongs at Wikipedia_talk:Manual_of_Style/Biographies#Style_of_lead_sections. Designate (talk) 21:25, 20 September 2011 (UTC)

Well, it's not that simple. The statement "Joe Shmoe (birth - death) was..." is at the intersection of WP:MOSBIO and WP:MOSDATE.

There have been a lot of discussions regarding the parenthesized vital information traditionally following a person's name in biographical articles. There was a huge discussion on this last year: Wikipedia talk:Manual of Style (dates and numbers)/Archive 132#So what IS the deal with birth/death locations in the opening? (ignore the section title and opening section and jump down to the "Staw Poll" subsection). Over 80 editors participated so this is the operative discussion in my opinion.

Anyway... Some people feel it should be "Charles Robert Darwin (12 February 1809 – 19 April 1882) was..." and some that it should be "Charles Robert Darwin (1809 – 1882) was...". And there's no agreement on this, so people do what they they think best. The problem is, one might infer from the example used in MOSDOB that there's a prescription to give the day and month, and that's not true. But if you changed the example to give only the year, that would possibly imply that there's a prescription to not give the day and month, and that's not true either.

It's confusing. There is absolutely not a consensus to use the day and month in the parenthesized vital information. The examples show this, but only because the examples have to show something.

MOSBIO handles this much better, but MOSBIO also has a failing: it says nothing about the parenthesized vital information. It only talks about the lede paragraph as a whole. (The examples there show parenthesized vital information, leaving one to possibly infer that they're at least recommended, but that's it.) If you go by MOSBIO -- what's written, not the examples -- the following lede would be perfectly within the MOS:

Charles Robert Darwin FRS was an English naturalist. He established that all species of life have descended over time from common ancestry, and proposed the scientific theory that this branching pattern of evolution resulted from a process that he called natural selection. He was born in England on February 12, 1809 and died there on April 19th, 1882.

We need to combine the strengths of this two complementary sections, in one place. Here's what I think: MOSDATE should get out of the biography business. (Either that, or MOSBIO should get out of the date business (which would be a lot harder, I think).) MOSDATE's job is telling what kind of dash should separate two dates when they appear in succession, and what kind of punctuation should separate the day from the month and the month of from the year when a full date is given, and so forth. And that's it. It should not saying, or even implying through examples, what level of detail is to be given to the parenthesized vital information at the start of of an article, or whether biographical articles should have the death date in the lede or at the end, and so forth. That's MOSBIOS's job.

It's certainly not a good idea to have two different MOS's talking about the same thing and not agreeing, which is the case now, at least arguably (depending on whether you think examples imply prescription, which I think a lot of people think they do unless this is overtly disclaimed).

This has been a headache for years, and a constant source of confusion. It's time to put paid to this. I propose to work up an RfC on this presently. Herostratus (talk) 06:11, 21 September 2011 (UTC)

An excellent proposal! I would add that a living person's DOB should not be divulged — to avoid making identity theft easier — and that exact dates be used in the lede if — and only if — they are not to be found elsewhere an article (I do not see how they can ever be irrelevant.) — Robert Greer (talk) 15:44, 27 September 2011 (UTC)

Use of the word "present" when representing dates in headers

Maybe I've missed it somewhere, but I see no direct information regarding the use of the word "present" in section headers. For example, I see many headers that list an event that occurred over a series of time and listed as (1980-present). I'm thinking that the same train of thought that applies to use of the word "currently" would also apply here but I'd like to be sure. Would that same rule apply that applies to the article body also apply to the section headers? NJZombie (talk) 18:23, 8 September 2011 (UTC)

logon page

Note that, contrary to the dates section of this manual, the logon screen today reads:

"The Wikimedia Foundation's 2nd steward election in 2011 has started. Please vote."

With superscript. — Robert Greer (talk) 16:52, 18 September 2011 (UTC)

I made this edit, which apparently needs to be approved by somebody in meta-Wikipedia land, where I seldom edit. The relevant guideline is MOS:NUM#Typography not MOS:NUM#Dates, but it does say 2nd not 2nd. Art LaPella (talk) 19:52, 18 September 2011 (UTC)

Euros again, again.

The plural of euros has been discussed so many times (see the archives of this talk page). Following the latest edit[8] we are now being told the plural is euro. But is the fragment "it is easier to pay for eggs in euro" really in the preferred form? Linguistic issues concerning the euro is sympathetic with "euros" and A handbook for authors and translators in the European Commission (at 20.9) is definite. Also, although I can imagine someone writing "a two-euros pen", English adjectives are not inflected and people do not need to be told this here. Could we not delete this whole bullet point as being far more bother than it is worth? Thincat (talk) 17:09, 2 October 2011 (UTC)

The natural, non-legislative plurals are the preferred form. The article now states this again. Best to leave the bit about adjectival use, however, in the context of this word. -- Evertype·✆ 20:50, 2 October 2011 (UTC)
I am a bit confused here, I think you are stating the you think 'Euros' is an acceptable way to pluralise euro. As far as I am aware, the 'correct' form is just 'Euro'. Thecoshman (talk) 11:28, 1 December 2011 (UTC)

Use of South Asian numbering system in articles

I would like to see a statement here regarding the use of the South Asian numbering system in articles. For example the article Ajay Kumar, it says he won by "1.55 lakh votes", is acceptable style? Kevink707 (talk) 17:03, 10 October 2011 (UTC)

On Indian-language Wikipedias, yes; on this (English-language) Wikipedia, no, unless in an historical or literary context (XIX-century Russian novels, for example). — Robert Greer (talk) 17:44, 10 October 2011 (UTC)
I agree, we can't expect readers to know what lakhs and crores are. Use English. JIMp talk·cont 17:48, 18 October 2011 (UTC)

Coordinates vs Lat Long in infoboxes

I'm not sure how (or where) to address this concern. Basically, I'm asking if infoboxes such as "{Infobox cemetery}" need lines for both Lat/Long entries and coordinates. (I've posted a comment on the particular infobox discussion page Template talk:Infobox cemetery.) Comments welcome. --S. Rich (talk) 04:56, 11 October 2011 (UTC)

WP:DATERET

Hey all.

I wonder if there is anyone who agrees with me, when I question the current DATERET guidelines. I regularly come across articles that have absolutely no relation to US or Canada, and still have a date format that is distinctly North American (or even US, as Canada have both formats). These articles – on topics that are Russian, German, Spanish, Japanese, Danish, or whatever – were probably once created by an American wikipedian, using his/her own habitual date format. That is no reason for those articles to have a US-centric date format, but the current guidelines seem to prevent changing the articles to a more appropriate format.

Wouldn't it be better if the "Strong national ties" section of the guidelines was altered so that it was permissible to alter the date format to a more appropriate one? (Changes could obviously go both ways.) I mean, just because the first major editor, probably unknowingly, made a poor choice of format, should the article for ever be doomed to keep that? If I had started the article on Tiger Woods or Bill Clinton using the international date format, would that be right?

HandsomeFella (talk) 19:48, 14 October 2011 (UTC)

The format that expresses today as "October 14, 2011," is as suitable for an article that is not tied to any particular English-speaking country as any others. The idea that "14 October 2011" is some how more suitable for untied articles is incorrect. Jc3s5h (talk) 20:24, 14 October 2011 (UTC)
Yes, that is what the current guidelines say. I'm questioning that. HandsomeFella (talk) 20:28, 14 October 2011 (UTC)
Many of the guidelines on Wikipedia have been developed under discussions dominated by editors more oriented to computing than to natural language; "14 October 2011' is near and dear to their hearts. — Robert Greer (talk) 15:50, 16 October 2011 (UTC)
It's no more “distinctly North American” than 17 October is “distinctly” British.[9][10][11] Hence, I'd leave the existing guideline the hell alone. ― A. di M.​plé​dréachtaí 23:29, 16 October 2011 (UTC)
I agree with A di M. And Robert Greer, sadly, techs seem to prefer the gobbledy ISO numeral-only version. The US armed forces use ddmmyy: what's British about that? Tony (talk) 02:10, 17 October 2011 (UTC)
I'm not saying it's British, I'm saying it's international. Use of the mdy format is isolated to North America in essence (in Canada both formats are used). Why the American military have chosen the international date format over the normal US format is a question they must answer. HandsomeFella (talk) 07:46, 17 October 2011 (UTC)
These are the current guidelines: Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation. For the US this is month before day; for most others it is day before month. Articles related to Canada may use either format consistently.
The proposition in short is that we strike the English-speaking part, i.e. the new guidelines would read: Articles on topics with strong ties to a particular country other than the United States or Canada should generally use the international date format, which is day before month. Articles with strong ties to the US should generally use the US format, which is month before day. Articles related to Canada may use either format consistently.
There is absolutely no reason for articles relating to Argentina, Nigeria or Austria to have a US-centric format. HandsomeFella (talk) 08:12, 17 October 2011 (UTC)
That format is not one of those used in the English-speaking world. HandsomeFella (talk) 09:41, 17 October 2011 (UTC)
Following A. di M.'s line of reasoning, "the Germanophone, Francophone, Espanophone and Slavonic" Wikipedias should use M-D-Y format for articles that have to do with American subjects (they do not.) — Robert Greer (talk) 14:49, 17 October 2011 (UTC)
Oh I wish. We cobbled together this patchwork called ENGVAR because consensus could not be reached over a single date or language format. Such is the deficiency of the consensus model. It's a problem unique to en.wp. Unlike French, German, Spanish where there is only one spelling and one date format and the issue never arises – mdy dates would look too weird in any of those languages. Unfortunately, there's no possibility of a single date or spelling system here. --Ohconfucius ¡digame! 15:49, 17 October 2011 (UTC)
Oppose. This idea conflicts directly with WP:ENGVAR. It amounts to effectively restricting mdy to only US and Canadian subjects regardless of the variety of English the article is written in. It's absurd to force an article about a Romanian politician written in American English to use dmy. Roger (talk) 09:44, 17 October 2011 (UTC)
I would say that it works together with WP:ENGVAR. Why should an article about a Romanian politician be written in American English? The obvious choice (to me) is to write in an as "neutral" as possible variety of English. HandsomeFella (talk) 10:00, 17 October 2011 (UTC)
You now seen to be proposing the complete overthrow of ENGVAR - fuhgeddaboudit! Roger (talk) 10:45, 17 October 2011 (UTC)
Yes, using “neutral” English is all what WP:COMMONALITY is about, but unless you want to avoid all the words for which there is no spelling which is correct everywhere (flavo[u]r, travel[l]ing, etc.), you still have to pick an English variety for those words to be written in. ― A. di M.​plé​dréachtaí 12:38, 17 October 2011 (UTC)

Compatability of date-stamp guidelines

Questions are in regard to WP:ASOF. It doesn't look like that page sees much traffic, so posting here instead.

  • Is this guideline compatable with templated data (like {{Kosovorecognition}}), which is intended to simultaneously update a range of articles? Presumably, it'd defeat the purpose of having such a template, since in each article it's transcluded in the date-stamp would have to be updated separately.
  • Should this guideline apply to such data in the first place? Surely, given the above, it would result in a lot of incorrect date-stamps because they weren't updated.

Any responses are appreciated. Thanks, Nightw 14:30, 17 October 2011 (UTC)

Ordinal suffix

In Wikipedia:DATESNO it states that the ordinal suffix is never used, but I was told here that there is an exception when the date is preceeded by the day of the week. Is there an exception to this rule? If so, we should cover it here. Thank you. Frietjes (talk) 15:13, 18 October 2011 (UTC)

I've never heard of that nor does it seem to make any sense. Preceded by a day of the week, what's the difference? You might as well make it that the suffix is used when followed by a word starting with "b". The only exception that seems valid to me is when the month is omitted (e.g. when you're many things which went on on different days in the same month). JIMp talk·cont 17:25, 18 October 2011 (UTC)

When giving just the month and year...

Which of these is correct:

  • ...in September 1944, the..."
  • ...in September of 1944, the..."
  • Whatever, no preference

The only guidance given is that "September, 1944" is wrong and "September 1944" (no comma) should be used instead. This tells me to remove the comma in that case, but doesn't tell me to remove the "of" if it exists.

I'm fine with "whatever". I think that "...in September of 1944, the..." sounds better and is more idiomatic, but I don't much care. Am I correct in believing that there is no guidance and editors are free to do as they prefer, right? (In which case other editors shouldn't correct whatever the previous editor decided, generally.)

If there should be a standard, it should be added as an entry in the table in the "Dates" section - Incorrect = June of 2001, Correct = June 2001. Herostratus (talk) 18:35, 21 October 2011 (UTC)

Just to clarify, I don't think there needs to be a standard. I don't believe in getting down to the level of detail where the MOS is telling editors they can never write "One of the many..." and must always write "Among the many..." instead, and so forth. (It might be nice to make a notation to the effect of "There is no preference between 'September 1944' and 'September of 1944', do as you wish", to clarify the situation.) But is editors think it should be specified that'd be OK I guess. Herostratus (talk) 18:51, 21 October 2011 (UTC)

The first is correct, there is no need for the "of". Frietjes (talk) 19:27, 21 October 2011 (UTC)
No need, but it's idiomatic. Not seeing any other objection, I've added it to the table of allowed usages. Herostratus (talk) 15:56, 23 October 2011 (UTC)
  • 'of' is specifically prohibited at WP:MONTH Hmains (talk) 16:54, 23 October 2011 (UTC)
    • Oh yeah, didn't see that. Well, that's overspecification (WP:CREEP if you will). Somebody added it at sometime in the past, but let's get rid of it, for a couple of reasons.
      • Overspecification, as I said. We don't want to get down to the level where we are telling editors stuff like "You must never write 'One of the few...', you must always write 'Among the few...' and like that. When a rule is not called for, let our writers write.
      • It's idiomatic, as I say. This is how people communicate information about months ("We were married in June of 2009" not "We were married in June 2009" -- both are used, but the former quite often). If this was overly informal, or an archaism, or a verbal tic ("Nineteen Hundred and Seventy-three") ("Two hundred and seventeen"), fine. But it's not. It's both common and acceptable in formal writing. Herostratus (talk) 19:53, 23 October 2011 (UTC)
  • Everything you write here is personal opinion. If see no backup for your statements from any formal writing manuals--which is what a great deal of the MOS is based on. You do not reference and quote anything for or against your opinion--which is required for honest evaluation of changes. Hmains (talk) 03:35, 24 October 2011 (UTC)
I haven't time to check, but I was sure MOSNUM said no "of" and no comma. That's best practice everywhere. Tony (talk) 08:13, 24 October 2011 (UTC)

0.1 seconds or 0.1 second?

You are invited to join the discussion at Template talk:Convert#Numbers greater than 0 but less than or equal to 1 should use singluar nouns. ― A. di M.​  19:12, 24 October 2011 (UTC)

Use of inconsistent date formats within an article's refs

The discussion here may interest some of you. The question is whether it is appropriate to revert an editor who used a consistent date format in refs in an article. So that instead, inconsistent date formats exist (even within the same refs).

Some guidelines at issue are WP:DATESNO, WP:STRONGNAT, and Wikipedia:Citing sources.--Epeefleche (talk) 06:44, 28 October 2011 (UTC)

Month abbreviations

Where the refs section, for example, of an article uses 3-letter abbreviation for the month:

Citation style is a matter for WP:CITE, which in essence says, follow the style guide that has been chosen for the article. If it happens that the article uses Citation templates or Cite xxx templates, follow the style guide for those templates. Oh. There isn't one. I guess some supporter of those templates will have to write one.
I have no objection to summarizing what WP:CITE says in this guideline, but where that guideline is silent, this guideline should be silent too. Jc3s5h (talk) 15:32, 12 November 2011 (UTC)
(edit conflict) There are at least two schemes in use: Jan Feb Mar Apr May Jun Jul Aug SeptSep Oct Nov Dec (mainly British) and Jan. Feb. Mar. Apr. May June July Aug. Sept. Oct. Nov. Dec. (mainly American), as far as I can tell. ― A. di M.​  15:39, 12 November 2011 (UTC)18:49, 13 November 2011 (UTC)
So if I read you correctly, whatever the abbreviated form, there should be no full stop after 'May', then... --Ohconfucius ¡digame! 16:07, 12 November 2011 (UTC)
The full stop in "Feb." indicates that "February" has been abbreviated. It is not some weird separator that is only used with month abbreviations; it might be used with any abbreviation. Since "May" is not an abbreviation, no full stop is used. The trend in English usage over the last 50 years or so is toward omitting the full stop from abbreviations, but this trend is still a work in progress. Jc3s5h (talk) 16:15, 12 November 2011 (UTC)
Strictly speaking, in British English, an abbreviation is only given a full stop if the last letter of the abbreviation is different from the last letter of the word or phrase being abbreviated. However, it's quite normal to omit the full stop from all month abbreviations, even though nine of them should have them. There are actually two patterns in British English: the mixture of three- and four-letter forms as above, and a consistent three-letter form (... Jun Jul Aug Sep ...). --Redrose64 (talk) 22:46, 12 November 2011 (UTC)
Actually the Sept above was a typo of mine. Do people actually do that? ― A. di M.​  18:49, 13 November 2011 (UTC)
Yes indeed. The date "Sept 9" appears in my (British) newspaper, which omits the full stop from all month and weekday abbreviations. I don't think you can generalise about this. 109.156.59.2 (talk) 20:28, 14 November 2011 (UTC)
  • While I don't use abbreviations these days, the one point I would weigh in on is that I agree with those who have indicated that under no circumstance should "May." be used. For the reasons indicated by others.--Epeefleche (talk) 08:46, 19 November 2011 (UTC)

Comma after year

An editor inserted this:

When a date in mdy format appears in the middle of text, include a comma after the year (The weather on September 11, 2001, was clear and warm).

I think this is probably correct but I'm not certain and just wanted to see if there was any objection. If anyone objects to this here would be the place to so state. Herostratus (talk) 20:09, 19 November 2011 (UTC)

Seems valid. We merely need to compare The weather on September 11, 2001, was clear and warm with The weather on September 11, 2001 was clear and warm - in the second one the comma seems somehow misplaced, and some well-meaning editor might amend to The weather on September 11 2001, was clear and warm or The weather on September 11 2001 was clear and warm both of which violate established MOSDATE practice. --Redrose64 (talk) 20:21, 19 November 2011 (UTC)
This rule is also listed at WP:COPYEDIT#Common edits (search for 1947). I am in the habit of ignoring it if there isn't enough text afterwards: "The weather was clear and warm during the September 11, 2001 attacks." A more extreme example: Not During the September 11, 2001, attacks, the weather was clear and warm. Art LaPella (talk) 22:17, 19 November 2011 (UTC)
I'm glad you provided the WP:COPYEDIT link; I was sure I had seen the rule mentioned somewhere on WP, but didn't know where (and I'm still not sure it was there, either). The reason for the commas fore and aft is, as it says, that the year is a parenthetical, and could be safely left out on a purely grammatical basis (we might still wonder what year, but the sentence would survive.
As for your bad example (IYKWIM), I'd probably try to avoid it, too, but I'd try to rewrite it as During the attacks on September 11, 2001, the weather was clear and warm. Of course, that also happens to just use (or share) the comma that ought to be there anyway, so it reads extra smoothly and doesn't support my point very well.  :-(   — JohnFromPinckney (talk) 03:41, 20 November 2011 (UTC)
Yes, my understanding is that that is indeed the rule. I'm not aware of any exception along the lines of what Art indicates he for his own part ignores -- a common example would be including it in "born January 1, 1999, in Berlin, Germany." I think the rule is that it should be included even there.--Epeefleche (talk) 03:50, 20 November 2011 (UTC)
The distinction is that in "the September 11, 2001 attacks" the date serves to modify the following noun, whereas in "born January 1, 1999, in Berlin, Germany" the date serves to modify the preceeding verb, and the comma seperates the preceeding words from the following "in Berlin, Germany" (which could in fact be omitted and the statement would still make sense.) One needs to look at the sense and meaning of the words to determine the punctuation unfortunately. — Robert Greer (talk) 08:41, 20 November 2011 (UTC)
But in either case, the year is modifying the rest of the date, and so needs to be enclosed in commas either way. Don't you agree? We also need a trailing comma after Germany when the sentence continues, as in He was born January 1, 1999, in Berlin, Germany, where his father was the U.S. ambassador. Same principle, AFAICT. — JohnFromPinckney (talk) 17:11, 20 November 2011 (UTC)
I agree: "the September 11, 2001, attacks" but I don't see the need for a comma after "attacks" in "During the September 11, 2001, attacks the weather was clear and warm." Wouldn't we write "During summer the weather is warm." rather than "During summer, the weather is warm."? JIMp talk·cont 02:17, 22 November 2011 (UTC)

Well, it'd be good to ask Art LaPella on that one, since it's his example, and because I'm not 100% confident on that usage. However, I believe I would employ the comma (in his as well as in your simplified example), as I'd wish to communicate to the reader that the usual word order (subject-verb-object(s)) is being changed. — JohnFromPinckney (talk) 22:53, 22 November 2011 (UTC)

  • Personal view: I hate it in some contexts, including the Sept one exemplified. Bumpety bump. Not all Americans use it, and many do it inconsistently. I'm against making this mandatory or even recommended. It could be an option, but only for US variety in mdy, of course. That's my take. Tony (talk) 02:02, 23 November 2011 (UTC)
Not all Americans use "its" and "it's" properly, or can spell "receive".  ;-)  If Americans (broadly construed, so as to include some fraction of Canadians) are the only ones to use mdy format, then yes, I guess it would be only in US ENGVAR, by default. But then, we'd only have to recommend it for mdy dates, and that's what we're doing now. Is that still too much for you? It is a standard English rule. — JohnFromPinckney (talk) 02:19, 23 November 2011 (UTC)
Quite a few newspapers in the UK and Australia, for example, use mdy; but they don't use that comma unless it's unavoidable in a context. Tony (talk) 12:18, 23 November 2011 (UTC)

Clarifying era convention

A bit of a conflagration at Neolithic Revolution has made me realise that the current wording of WP:ERA:

  • Do not arbitrarily change from one style to the other on any given article. Instead, attempt to establish a consensus for change at the talk page.

Is slightly ambiguous about what reasons there can be for changing from one style to the other, especially for new editors who aren't totally familiar with our nuanced definition of "consensus" (i.e., it isn't a vote, it's limited, and it should be based on policy). I understand why the wording was changed early this year from a version that was slightly more clear in that regard, but User:Cynwolfe has already suggested a version that gives us the best of both worlds (w/ some slight alterations):

  • Do not arbitrarily change from one style to the other on any given article. Instead, attempt to establish a consensus for change at the talk page. Reasons for the proposed change should be specific to the content of the article; a general preference for one style over another is not a valid reason.

Can we go ahead and add this? joe•roet•c 12:07, 1 December 2011 (UTC)

Sorry for incorporating the change before replying here, but believe it or not, I didn't even see your comments here before I decided to make the change! I agree with your points here, it's a good change — FoxCE (talk | contribs) 12:33, 1 December 2011 (UTC)
I'd forgotten I suggested this. I do think the reasons should be specific to the article. Debate over whether there should be a general style guideline should be at MOS talk, not individual article pages. Cynwolfe (talk) 12:39, 1 December 2011 (UTC)
Indeed, and that's an important distinction. Too often we see pointless paragraphs-long debates about the pros and cons of BC/BCE at the talk page of various random articles, when the discussion should be limited to why BCE or BC is more appropriate for the particular subject matter of the article. All discussion about the merits of Common Era or Anno Domini should be directed here. One problem we'll run into, however, is the question of what particular type of subject matter BC or BCE should be used for, and why. Judaism-related articles are typically a given, but what about Hinduism, paganism, Buddhism, etc.? How can we possibly objectively determine that one notation is more appropriate at one given article if Wikipedia considers BC and BCE to be equally valid? — FoxCE (talk | contribs) 12:48, 1 December 2011 (UTC)
I'm pretty "live and let live" about this. I don't think we should dictate the convention by topic area; I think that with sane guidelines, usage will evolve naturally to what's appropriate for the subject, article by article. In some subject areas, modern secondary scholarship will show a clear preference for one convention over the other. If the article is well-written and balanced, I don't have a problem with the lead editors having made the choice through the normal collaborative process. What I find disruptive is someone who hasn't contributed to the article (and has no intention of doing so) swooping in and demanding an era change. That's where "specific to the article" comes into play. Cynwolfe (talk) 13:14, 1 December 2011 (UTC)

Foot-pounds and pound-feet

There is a discussion at convert regarding foot-pounds and pound-feet. A number of points raised there deserve a broader consensus that convert's talk page provides.

  1. There is a convention (according to Pound-foot (torque) which suggests that it was "apparently first proposed by British physicist Arthur Mason Worthington") that the foot-pound is a unit of energy and the pound-foot is a unit of torque but this convention is not universally followed with the foot-pound sometimes being used for torque (according to Pound-foot (torque) and Foot-pound (energy)). Should WP insist on adherence to this convention or allow foot-pounds for torque?
  2. It was suggested that "foot-pound" is incorrect and that the energy unit should be the foot-pound force but that the torque unit is the pound-foot. If "pound-foot" (as opposed to "pound force-foot") is okay, why not "foot-pound" (as opposed to "foot-pound force")? On the other hand, if "foot-pound" is incorrect why is "pound-foot" okay? So, do we allow both "pound-foot" and "pound force-foot" or insist on only one or the other? Likewise, do we allow both "foot-pound" and "foot-pound force" or insist on only one or the other? What influence, if any, should our decision with regards to "pound-foot" verses "pound force-foot" have on our decision with respect to "foot-pound" verses "foot-pound force" and vice-versa?
  3. Should the "f" for "force" in "pound force-foot" and "foot-pound force" be subscripted? Is it "lbf·ft" & "ft·lbf" or "lbf·ft" & "ft·lbf"? Should we always use a subscript, should we never use it or should we decide on an article-by-article (or project-by-project) basis?

What're your thoughts? JIMp talk·cont 06:21, 5 December 2011 (UTC)

We are sort of between a prescriptive rock and a descriptive hard place here. Both "Pound-foot" and "Foot-pound" can be found referring to torque, though using "Pound-foot" for torque and "Foot-pound" or "Foot-pound force" for energy is less ambiguous than using "Foot-pound" for both. It would be overstating the case to assert that one is right and the other is wrong, and it might be overstating the case to argue that "Pound-foot" is the proper torque unit, and "Foot-pound" or "Foot-pound (force)" is the proper energy unit, but it might be understating the case to argue that they are fully and freely interchangeable with no preference either way. I have a wall of shelves full of service and engineering manuals published by the US, UK, South African, and Australian offices of a great many manufacturers of automobiles, engines, and other equipment, as well as basic tool and tech texts such as Stockel and various SAE publications; these are all but uniform in their preference for Lb·ft as the torque unit. I have another wall full of shelves containing mostly popular literature (Popular Mechanics, Popular Science, etc.) which appears to use the two unit expressions interchangeably.
So, given that we are writing an encyclopædia the purpose of which is to edify, illuminate, clarify, and educate, we appear to have an opportunity to further that purpose by disambiguating the units we use for torque and for energy. This appears to be a zero-cost opportunity in that if we disambiguate the units by preferring Pound-foot for torque and Foot-pound for energy, we aren't doing anything that could be called wrong, arbitrary, or otherwise problematic. On the other hand, there's something to squawk about if we ambiguate the units by using "Foot-pound" for both torque and energy. I don't know that the options before us are polar enough to warrant stringent mandates, but I think we ought to nudge and channel our usage convention towards the clearer and less ambiguous usage: Pound-foot for torque and Foot-pound (force) for energy, as for example by using those units for those purposes in {{convert}}. If consensus cannot be reached to do so, then I would drop back to advocating for the disambiguative usage as default, with the ambiguous usage still permitted.
Foot-pound force ought to be abbreviated Ft·lbf. As for "Pound-foot (force)", expanded or abbreviated, I cannot find any evidence of its usage as a unit of torque, and I think it probably doesn't merit prolonged consideration in this present discussion. —Scheinwerfermann T·C23:07, 5 December 2011 (UTC)

I agree absolutely that it should be a middle dot separating "ft" and "lb", not a hyphen, not a bullet and definitely not a slash (lb/ft is pounds per foot and ft/lb is feet per pound). However, none of these should be capitalised. Thus it's "ft·lbf" or "ft·lb" and "lb·ftf" or "lb·ft" (or "ft·lbf" and "lbf·ft"). This is in accordance with MOSNUM.

  • When unit symbols are combined by multiplication, use a middle dot (&middot;) or a non-breaking space (&nbsp;) to separate the symbols. ...
  • Unit symbols/abbreviations, apart from those listed below, are written in either non-alphabetic characters or in lower-case letters unless they are derived from a proper name, in which case the first letter is a capital letter. ...

Scheinwerfermann, it would seem you prefer "lbf" over "lbf" or am I misreading you? Should we insist on one? Should we insist on the other?

It has become established practice that we follow the sources. As it is an encyclopædia we're cobbling together, our preference ought to be for the more scholarly source. Assuming that your collection, Scheinwerfermann, is representative of current literature, it seems we have a solid case for adopting Worthington's convention here. Much less the harm if we err in favour of unambiguity. I support restricting "foot-pounds (force)" to energy and "pound (force)-feet" to torque on WP. Further, I support the general case of restricting length-force units to energy and force-length units (e.g. newton-metres) to torque. I propose adding this to the guideline.

How about the "force" in "foot-pounds (force)" and "pound (force)-feet"? Is it manditory, preferable, context dependant,, completely optional, undersirable or to be banned entirely? Is the "force" in "foot-pounds (force)" to be given equal weight as that in "pound (force)-feet" or are they to be given unequal footing? Scheinwerfermann, do I read you wrong that you'd accept "pound-feet" ("lb·ft") but not "pound force-feet" ("lb·ftf") but you find both "foot-pounds force" ("ft·lbf") and "foot-pounds" ("ft·lb") acceptable? JIMp talk·cont 00:46, 6 December 2011 (UTC)

I oppose the inclusion of "force" in the torque unit. I am not omniliterate, but in my extensive collection and reading of relevant literature, "pound force foot", whether expanded or abbreviated, is not in formal, popular, or colloquial use as an expression of the torque unit. I don't espouse an I've-never-seen-it-so-it-doesn't-exist stance, but I will be very surprised if substantial evidence could be provided for the existence of lbf·ft except perhaps as a very recherché term nobody actually uses.
I lean somewhat less fervently towards mandatory inclusion of "force" in the energy unit (to further distinguish it from the torque unit, since "foot-pound" is in popular use as a torque unit). I support ft·lbf, per se, for the abbreviation of the energy unit.
I agree with all lowercase. —Scheinwerfermann T·C01:27, 6 December 2011 (UTC)

I have proposed adopting the convention that a unit written as length times force is a unit of energy and a unit written as force times length is a unit of torque. There being no opposition to and clear advantages in so doing let us add this to the guideline. JIMp talk·cont 02:51, 9 December 2011 (UTC)

I have added the following to WP:MOSNUM#Unit names.

When units of torque or energy are formed by multiplication of a unit of force with a unit of length, distinguish these by putting the force unit first for torque (e.g., newton-metres or pound-feet) and the length unit first for energy (e.g., foot-pounds or foot-pounds force).

JIMp talk·cont 08:19, 9 December 2011 (UTC)

Pound-mole abbreviation

Having just added pound-moles to {{convert}} and wondering whether we abbreviate it as "lbmol", "lb-mol" or either, I brought the question up at MOS Chem. JIMp talk·cont 03:18, 8 December 2011 (UTC)

ArbCom election reminder: voting closes soon

All editors are reminded that voting closes for ACE2011 in just over a day's time (Saturday 10 December at 23:59 UTC). To avoid last-minute technical logjams, editors are asked to vote at least an hour before the close, that is, by:

  • Saturday 15:00 (3 pm) on the west coast of North America;
  • Saturday 18:00 (6 pm) on the east coast of North America;
  • Saturday 23:00 (11 pm) in the UK and Ireland;
  • Sunday 01:00 (1 am) in South Africa;
  • Sunday 06:00 (6 am) on the west coast of Australia; and
  • Sunday 10:00 (10 am) on the east coast of Australia; and
  • Sunday 12:00 (12 noon) in New Zealand.

For the election coordinators. Tony (talk) 13:05, 9 December 2011 (UTC)

Is the implication that people from (say) continental Europe are smart enough to figure out the time themselves? :-) ― A. di M.​  15:56, 9 December 2011 (UTC)
This seems to be yet another good example of anglophone bias in Wikipedia. I wonder when people will learn that English Wikipedia is global and there are editors here from all countries, not just from anglophone ones. Nanobear (talk) 16:03, 9 December 2011 (UTC)

Decades: two digits: 1960s and 70s?

Minor question regarding WP:DECADE: It says that four digits (1960s) are preferred over two digits (60s), which makes sense. I've got an article that has "1960s and 70s". That seems superior to "1960s and 1970s". Should WP:DECADE identify that as a permissible use of 2 digits, or is that too obscure? --Noleander (talk) 17:49, 9 December 2011 (UTC)

How does using 70s help someone searching for the 1970s? If you search for 70s, you get hits for the 1970s, 1870s and so on. So besides the way this is displayed, there is the question of searching. I had many problems doing updates that needed searches for years because of this type of shorthand issue. Vegaswikian (talk) 19:24, 9 December 2011 (UTC)
Good point. Okay, I'll just leave it as-is. --Noleander (talk) 19:40, 9 December 2011 (UTC)
Thoughtful point. Agree.--Epeefleche (talk) 21:02, 14 December 2011 (UTC)

first decade of any century

Section 2.5 states: "Forms such as the 1700s are normally best avoided since it may be unclear whether a 10- or 100-year period is meant (i.e. 1700–1709 or 1700–1799).". I agree, but no alternative form that should be used is provided. I have been using, for example, 'first decade of the 21st century'; I imagine others might use something else. An agreed upon alternative to 2000s would be helpful if stated here in the MOS. Thanks Hmains (talk) 20:51, 12 December 2011 (UTC)

There really isn't one, and it's not our business to go inventing one; we, the editors of Wikipedia, have the task of recording things as they really are, not as we wish they were. 1700s means 1700–1799, and there is no way to say 1700–1709 other than "first decade of the XVIII century". — Robert Greer (talk) 21:16, 13 December 2011 (UTC)
Which is 1701-1710! Vegaswikian (talk) 21:36, 13 December 2011 (UTC)
Our WP decade articles such as 2000s (decade) indicate that the first decade of a century is 2000 through 2009 so I was going by that in asking my question. Hmains (talk) 03:41, 14 December 2011 (UTC)
If you need to pinpoint a period so precisely that the one-year difference between the two definitions matters at all, you'd better say from 19XX to 19YY than in the early 20th century anyway. The latter ought to be for vague-ish ranges where whether the 20th century began in 1900 or 1901 is pretty much irrelevant. ― A. di M.​  18:14, 14 December 2011 (UTC)
I think I've seen WP articles using 2000–09 for that, even though that might be excess precisions in some contexts. ― A. di M.​  00:13, 14 December 2011 (UTC)
The articles now seem to be of the form 1700s (decade), rather than 1700–1709. — Arthur Rubin (talk) 00:47, 14 December 2011 (UTC)
That's good enough for article titles, but it's not suitable for use in running text, I think. ― A. di M.​  17:59, 14 December 2011 (UTC)
  • Unfortunately, I have to complicate things. The articles also contain 'early 2000s', 'mid 2000s' and 'late 2000s' phrases. So I end up writing the wordy and awkward 'early years of the first decade of the 21st century', 'middle years of the...', 'late years of the ...' or maybe 'early years of the 2000s (decade)', etc. Help us all! Hmains (talk) 04:19, 14 December 2011 (UTC)
    • I see your point. If obviously historical, 'mid 2000s' and 'late 2000s' are unambiguous. Otherwise, you'll have to talk to a grammarian. — Arthur Rubin (talk) 04:31, 14 December 2011 (UTC)
      • I beg to differ — ever so slightly. "Late 1700s" and "early 1800s" are perfectly clear; "mid 1900s", though commonly used, is not quite. — Robert Greer (talk) 17:27, 15 December 2011 (UTC)
      • What I find in WP articles is that editors are writing 'early 2000s' to mean the first few years of 2000 to 2009 NOT the first years (2, 10, 20, whatever) of the 21st century most of which have not occurred yet; likewise for 'late 2000s' to mean the last few years of 2000 to 2009, not the last years of the 21st century which definitely have not occurred yet. With prior centuries, the reader must go to the effort of trying to figure out what is meant since writers fail to use xx century for the 100 year period regardless that the this MOS says they should do so. So is century or decade meant when you see 1700s or early 1700s or whatever. Hmains (talk) 03:59, 16 December 2011 (UTC)

Reichsmarks

I see no guidance on abbreviating this currency, but have always seen it as RM. Ulf Heinsohn has made a series of edits changing it to script ℛℳ, in this edit to Nibelungen Bridge (Regensburg) with the edit summary "typo", elsewhere, (for example this edit to Festhalle Viersen) also replacing Reichsmark with German gold mark and referring only to that change in the edit summary. I believe he's right to regard Reichsmark as anachronistic in those cases, but what is the policy on the script rather than plain text abbreviation? I wanted to determine whether there was one before raising the issue with the editor. Yngvadottir (talk) 19:01, 13 December 2011 (UTC)

It seems that RM is the common term used for Ringgit Malaysia (the Malaysian currency). So RM is ambiguous and the meaning has to be gleaned from the context. HumphreyW (talk) 06:03, 16 December 2011 (UTC)

Inconsistent case in abbreviations for millions and billions

According to Wikipedia:MOSNUM#Large_numbers, millions is abbreviated to upper case M, but billions is abbreviated to lower case bn. This strikes me as being inconsistent (and thus contrary to one of the general rules of MOS). Should we use consistent case? Is there a specific reason why the case is different here? Mitch Ames (talk) 13:28, 14 December 2011 (UTC)

M is short for Mega, not million, and is in upper case because that is the SI prefix. Lower case m means milli. Upper case M is frequently used to mean million and MOS seems to approve the usage. MOS worries that G for billion would scare the horses (except in scientific contexts). Thincat (talk) 16:25, 14 December 2011 (UTC)
The Manual of Style rule for millions is "M", but in actual practice it's "m" about half the time. Art LaPella (talk) 02:30, 15 December 2011 (UTC)
I'd also prefer to use "m" rather than "M", at least in contexts where we're also using "bn". It doesn't stand for "mega" and can't possibly be confused with any SI prefix, so I don't really see this objection.--Kotniski (talk) 08:36, 15 December 2011 (UTC)

For what it's worth, I was thinking about currency, eg $20m or $20M, when I raised the matter. Here are the relevant edit, comment and revert. Mitch Ames (talk) 12:02, 16 December 2011 (UTC)

I'd echo the words of both you (presumably) and the reverter - I too have always used "m" in such situations.--Kotniski (talk) 12:16, 16 December 2011 (UTC)
For the edit in question, I believe it would be more appropriate to spell out "million" since the numbers are not located in an area where space is constrained, such as a graph label or a table. Jc3s5h (talk) 15:03, 16 December 2011 (UTC)

Discussion re application of strongnat

There is a discussion of the application of STRONGNAT here, which may interest some readers of this page.--Epeefleche (talk) 16:41, 14 December 2011 (UTC)

Rewrite sloppy "In references" section

I've never seen any real consensus to accept sloppy, lazy crap like "30 Sep 2009" and "Sep 30 2009". Not here, not at WP:MOSABBR, not in years and years of debates about date formatting and autoformatting. I correct this mess to proper date formatting every time I encounter it, and this is getting increasingly tedious. Now I know why: Some joker added this to WP:DATESNO on a whim, and it's consequently attracting lazy editors to follow its bad advice. Even the allowance of ISO dates for accessdates is a bad idea with a lot of negative consequences (everyone and their dog has been using them for publication dates in citations, too. Often enough to be worrisome, non-technical non-Americans, used to day-month order in prose wrongly put 2009-30-09, which is "fatally" problematic for any day number under 13.

But this month abbreviation garbage is going to far. For one thing, there's no universal standard. Some people like any of "Sep", "Sep.", "Sept" and "Sept." among probably others. It's a total nightmare for reusability (e.g. parsing by bots). It's even worse for non-native English speakers who don't automatically recognize inconsistent abbreviations through long familiarity. And it's just sloppy, and lazy. It's going to spread to article prose (already is - I've undone it in articles many, many times). There are already too many date formats here. Even being American, I'd prefer we standardized on 30 September 2009 format and deprecated ALL others. At least clean up this particular mess: 

=====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.
}}

Made the examples a bit clearer in the process.

I would (severably) also prose elimination of ISO dates as acceptable for anything, including tables if the current table sorting code can work around the need for being able to sort by date, which appears to be the case. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 15:15, 16 December 2011 (UTC)

Three reasons to keep ISO dates are (1) that it is (or should be) uniquely understandable, going from most general (year) to most specific (day), (2) there are so damn many instances of it, and (3) it's great for sorting, if not necessarily for reading. If you want to pro[po]se eliminating the format completely, you'll probably want to investigate the possibility of bot conversion of refs and table uses; I have no idea how widespread the format actually is, but I see an awful lot of it. Presumably, some percentage of the ISO usages should be preserved as is, or transformed in a different way (e.g., table sorting).
I think a good approach (at least for now) would be to allow but discourage its use. Editors use that format because other articles have used the format. And when I'm faced with an old article from 2006 where refs with dates were first added in oh, around 2008, I'd rather not trawl through the edit history to determine which of yyyy-mm-dd or mdy to use. This would allow me to just standardize on the mdy (or standardise on the dmy, as the case may be) and save a bunch of time. — JohnFromPinckney (talk) 17:58, 16 December 2011 (UTC)
This RfC to ban YYYY-MM-DD dates from footnotes failed. Jc3s5h (talk) 18:05, 16 December 2011 (UTC)
Perhaps the answer is to use a template, like (but not actually) {{Start date}} which has YYYY-MM-DD input (fewer characters to type) and outputs both machine-readable metadata and human readable dates in whatever format the reader prefers. Or even to have a date-picker in citation template entry forms. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 16 December 2011 (UTC)
Date picker? Oh, sweet Jeebus; like in Reflinks, for starters. That thing automatically uses only yyyy-mm-dd format and has no option to select anything else. It'll be a great day when I can see an edit summary "(Filling in 23 references using Reflinks)" on a mdy page and not want to slash my wrists. — JohnFromPinckney (talk) 19:02, 16 December 2011 (UTC)
Date autoformatting has been rejected after extensive debate. See User:Dabomb87/Summary of the Date Linking RFCs. — Preceding unsigned comment added by Jc3s5h (talk • contribs) 19:05, 16 December 2011 (UTC)
You seem to be responding to me, although you use the term "autoformatting", and I did not. I know I didn't use the term because I did not know what it means. Having read a bit (here, for instance), I now take it to mean enabling the ability for (registered) users to see dates according to their personal formatting preferences. Maybe you meant to be responding to Andy, then?
In any case, I'm not asking for any such thing. I was just fantasizing about Reflinks beink more useful by letting its users throw a use-this-format switch for its dates. It'd also be cool to have something which automates the conversion of dates in a page. — JohnFromPinckney (talk) 20:23, 16 December 2011 (UTC)
In that case, a template, like (but not actually) {{Start date}} which has YYYY-MM-DD input (fewer characters to type) and outputs both machine-readable metadata and human readable dates in whatever format the editor specifies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 16 December 2011 (UTC)
(P.S. and anyway, those debates seem more concerned with date-linking than date-formatting per se. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:46, 16 December 2011 (UTC))
A bad implementation in one tool shouldn't preclude us from using a well-implemented version elsewhere. If we use a template as I suggest above, the date picker could populate that. Have you raised your concerns about Reflinks with its author? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 16 December 2011 (UTC)
User:Dispenser hasn't edited the User talk:Dispenser/Reflinks page since 23 July. My (our) questions about bug status and the like continue to be ignored. Dispenser still edits regularly but appears to have lost interest in Reflinks, which is an awful shame; it's a useful tool which could be much better, but now requires too much manual correction (which most users seem unprepared to provide). — JohnFromPinckney (talk) 16:53, 18 December 2011 (UTC)

RFC on coordinates in highway articles

There is currently a discussion taking place at WT:HWY regarding the potential use of coordinates in highway articles. Your input is welcomed. --Rschen7754 01:30, 26 December 2011 (UTC)

The proposal would change the MoS to prohibit the use of coordinates in articles about highways (aka roads/ motorways). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 26 December 2011 (UTC)
As has been explained elsewhere, one of the proposals on the table would "change the MoS to prohibit the use of coordinates in articles about highways (aka roads/ motorways)". --Rschen7754 06:09, 29 December 2011 (UTC)

Centuries and hyphens

I have been editing quite a few articles about English villages recently, and a question has arisen in my mind regarding the use of hyphens in centuries. Am I right in thinking that when a century is used as a noun, there is no hyphen between the number denoting which century it is, and the actual word "century", whereas a hyphen is required when the century is used as an adjective (e.g. "the church was built in the 15th century" [used as a noun], contrasting with "a 15th-century church" [used as an adjective])? I could find no mention of this issue in the MoS. PaleCloudedWhite (talk) 01:27, 28 December 2011 (UTC)

WP:ORDINAL, sixth bullet: "Centuries are given in figures or words using adjectival hyphenation where appropriate: the 5th century BCE; nineteenth-century painting." I have interpreted that to mean hyphenate "nth-century" as an adjective but not as a noun. Art LaPella (talk) 02:40, 28 December 2011 (UTC)
Per Art. It's like compound-adjective usage in general. Although there's a significant grey area in English at the moment, some examples just can't do without a hyphen in any variety of the language; 19th-century art is one of them. BTW, note MOSNUM's agreement with the ISO's prescription on values and units: 3 mm gap (when the symbol/abbreviation is used), but 3-millimetre gap (when expanded). Tony (talk) 07:17, 28 December 2011 (UTC)

Thanks. I didn't look at that section; I didn't read far enough down the page (I just looked at the bits about calendars etc.) That'll teach me to draw rushed conclusions about a topic not being in the MoS (although finding the required information isn't always easy!) Still, it does back up my own deduction... PaleCloudedWhite (talk) 08:57, 28 December 2011 (UTC)

Retrieved from "http://en.wiki.x.io/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_135&oldid=1256388825"