Misplaced Pages

Revision as of 06:19, 18 August 2009

Manual of Style

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

Archives

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

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

Bot to unlink dates?

Why not have a bot to unlink dates, since that is the policy? Is it because a few should be linked and the bot can't decide which to keep? Bubba73 (talk), 19:46, 31 July 2009 (UTC)

Something like that. Powers 19:53, 31 July 2009 (UTC)

Actually, there is a bot in the works (approved by the community); see WP:DATEBOT. In a nutshell, only dates that are used for autoformatting will be delinked; date fragments (such as March 3 or 1999) will be left linked. There is an exclusion list, to which editors can add articles that they don't want to be delinked if they can explain why both the year and the month-day fragments are useful. Dabomb87 (talk) 19:55, 31 July 2009 (UTC)

What we actually need is another code to format dates (i.e. not link them). Then the bot could make the replacement. Bubba73 (talk), 22:58, 7 August 2009 (UTC)

Can we have a bot which works out which is the currently predominant date format in a particular article, and then converts any other dates in that article to that format? Alarics (talk) 16:07, 10 August 2009 (UTC)

There was discussion about that, but it was rejected as it was outside the scope of the bot task that was approved by the community. Dabomb87 (talk) 18:17, 10 August 2009 (UTC)

So how do we get something done about it? Alarics (talk) 18:41, 10 August 2009 (UTC)

Start another discussion about it, I assume. The bot can do it eventually, but the community has to approve that task first. Dabomb87 (talk) 18:48, 10 August 2009 (UTC)

Numero sign / Number sign

In reference to Archive 106, Question on #1 vs number one, should there be a section in MOSNUM outlining the proper usage of the numero sign versus number sign?

Another undiscussed usage is in a table header (where space is limited): Is it proper for one to write "№ of shows" or should one write "Number of shows"? See the example in the header of this table. —Preceding unsigned comment added by Gmoose1 (talk • contribs) 14:59, 7 August 2009 (UTC)

This is worth developing. The hash sign (#) or as it is often called in North America the pound sign is still somewhat of an annoyance to Europeans (and you can imagine my annoyance with calling it pound, being an english person). In England it is common to write N, and has been since at least my copy of Johnson's Dictionary which is er 1753? Somewhere like that. Considering the differences, for a worldwide, but English-reading, audience would it just be easiest and simplest to write "The number (or numbers)". But take e.g. house numbers should we write oh house 22 or number 22? Both I think would be acceptable in British English. (A children's programme in the late 70s hosted by Sandi Toksvig was called No. 73). I can fill in all the sources details etc later but just gave me pause for thought. SimonTrew (talk) 15:51, 7 August 2009 (UTC)

Number Ten, Downing Street, for example ("No. 10"). Keep in mind that on US keyboards, the # sign is usually present, but № (which I just pulled from the Symbols menu below the edit box) is usually not. Nor are superscript a and o (or for that matter superscript th). But as an Englishman who came to the States at age 11, I still think # is a bit unnnatural in some contexts. (It's also slightly ambiguous because in old-fashioned commercial shorthand in inventories, invoices, etc. @ can stand for "each" and # for "pounds", among other things.) —— Shakescene (talk) 21:40, 7 August 2009 (UTC)

Yeah exactly, I think it is never going to be pleasant to everyone to say #10 or N ten or whatever. Why don't we just reccommend saying e.g. Number 10 (for downing street?), of course if the context makes it clear it means the residence of the UK PM (or metaphorically his office or powers, as in say the White House, by analogy). I just think it would be the most simple and also more worldwide to say that. SimonTrew (talk) 12:00, 8 August 2009 (UTC)

I've never been a fan of the pound/hash symbol, except perhaps in tables and other environments where space is particularly tight (even then, I'd avoid if possible). I don't much like the squishy little "№" symbol from the edit-tools, as Shakescene has presented it above. Tony (talk) 12:59, 8 August 2009 (UTC)

So to form a rule for the manual of style and summarize the above, we could say "Number of shows" if there is enough space, but if space is tight (eg: in a table), then one should write "№ of shows"? Not sure if we're ready to form a rule for house numbering? As for the symbols that should be used: I think both N and No. should be avoided as № is readily available in the Symbols box and a wiki article is available to counter ambiguation. Furthermore, # should be strictly avoided in this context as it causes confusion for British English audiences. American English audiences recognize # and No. have the same meaning. Any disagreements? Lars (talk) 16:31, 10 August 2009 (UTC)

Two concerns with that. First, № appears archaic to most American eyes, like something you'd find on a 1910s-era cash register. Second, in fixed-width fonts such as that used in edit windows, № is so squished as to be nearly unreadable. Powers 17:50, 10 August 2009 (UTC)

I have never heard of "№". What we usually put is "No.". Alarics (talk) 18:40, 10 August 2009 (UTC)

"№" is indeed difficult to read in monospace, and may be enough to argue that we should go with "No." or "N". It is also not commonly used (like ‽), which may support the argument that it appears archaic. So, how about "No." versus "N"? Any thoughts? The latter is more specialized, and may improve readability as it does not appear to be the word "no" at first glance. Lars (talk) 19:33, 10 August 2009 (UTC)

The latter looks kludgy (i.e., unprofessional) to me, but maybe it's unsporting to argue when I also criticized the professional glyph. =) My gut feeling, though, is that in the cases in which we'd find an abbreviation necessary, "No." should not usually be ambiguous. Powers 01:33, 11 August 2009 (UTC)

Anomalies in the template for converting measurements.

I have discovered an anomaly with using the 'convert' template. Look at this:

4,700 square miles (12,000 km)

4,699 square miles (12,170 km)

When converted into square kilometres, 4699 sq miles comes out 170 km more than 4700 sq miles. Lose one square mile, gain 65.6 square miles!

I think the problem may occur because of rounding when a number ends in two zeros.

Therefore it is risky to rely blindly on the conversion template. It may give anomalous results.

Please let me know if this issue should be raised elsewhere. Michael Glass (talk) 06:45, 8 August 2009 (UTC)

{{convert|4700|mi2|sigfig=4}} gives 4,700 square miles (12,170 km). You just have to use the significant figures setting. For many articles that rounding is appropriate; if you write 4,700 nobody is going to expect it to be exactly that. If you write 4,699 they will expect it to be exactly that. SimonTrew (talk) 12:07, 8 August 2009 (UTC)

Well, in my humble view, this is another reason not to use a conversion template, but to allow fellow editors, including newbies, maximum control over all aspects of the construction. I'm all for keeping it simple, and if that means using a calculator, so be it. Tony (talk) 12:57, 8 August 2009 (UTC)

I disagree. If a newbie just throws the numbers in, a more experienced editor can use {{convert}} later. The thing about using the template, if e.g. something changes in MOS then EVERY article that uses it will get that change. SimonTrew (talk) 13:45, 8 August 2009 (UTC)

Well I do agree to the extent that it can be fiddly to get right and there are some things it simply can't do. But on the whole, if you can do it with the template, you should. SimonTrew (talk) 13:53, 8 August 2009 (UTC)

I think the trouble is that as the rounding cuts in automatically unless it is overriden. The default position can be a trap for the unwary. An over-precise conversion can be overridden; the opposite may not be noticed by the uninformed.Michael Glass (talk) 14:08, 8 August 2009 (UTC)

The template reads the precision of the input number and matches the precision of the output accordingly. This is in accord with the MoS and normal mathematical practice. There is no anomaly. An over-precise conversion can be overridden, sure, but are the uninformed any more likely to fix an over-precise than an under-precise one? In the majority of cases the template will not give the wrong precision. 4,700 sq mi ≈ 12,000 km is correct as is 4,699 sq mi ≈ 12,170 km. It is the conversion templates without this type of default rounding which are more prone to produce output with incorrect precision. To those unwary I can only say "Get wary." JIMp _talk·cont 15:11, 8 August 2009 (UTC)

It's a bit of a circular argument that it conforms with MoS since this is a discussion on a subpage of the MoS.

I do agree however that yeah if you put in 4,700 it is unlikely it is going to be exactly 4,700 (of whatever) and so misleading to a ridiculously over-precise value. If you pur in 4,699 presumably you mean that (and not 4,698 or 4.701) and should be converted more accurately. It comes down to common sense. My little book here gives logs and other things such as trig functions to 8 sig figs. Most floating point maths used in computers is at double-precision and has about 12 sig figs (decimal) in the mantissa. If it is good enough for rocket science and subatomic modelling (and it is cos I have programmed it) then I think it ridiculous to be more precise than that. There are all kinds of more precise representations but in real science and engineering that is plenty: in fact single precision (5 or 6 sig figs decimal) is usually good enough, but with modern processors using a double is as fast, if not faster, than a single. And the same applies to humans as computers. Of course propagation errors may occasionally require higher representations in intermediate results, but on Misplaced Pages that hardly applies, unless the underlying templates are so off that they preduce an obviously bizarre result such as 1 cm = 1.00001 cm or whatever.

I see no problem here. These templates are a bit fiddly and I am sure if we were starting from scratch we would change a lot of things, but we aren't and we can't. It is one of those things an editor just has to do. The {{cite}} templates are also trick but everyone expects those to be used. SimonTrew (talk) 04:55, 9 August 2009 (UTC)

If we put the template in question up against a statistically representative sample of typical editors with calculators, I'd put my money behind the template to give the most appropriate levels of precision for the typical measurements you find on Misplaced Pages. JIMp _talk·cont 08:06, 9 August 2009 (UTC)

The behaviour contradicts the principle of least surprise, but as a mathematician I think this is one of the situations where that is actually justified. Besides, I don't see how we can avoid it. Consider:

Notice that in the last column we always write 4,700, whether we mean 2, 3 or 4 significant digits. Similarly, in the penultimate column it's not clear whether 470 has 2 or 3 significant digits. The template needs to guess. We can't make it guess correctly in all situations, but if it makes sure to under-, rather than overestimate the number of significant digits in doubtful cases, then it's more likely to be wrong right than if it does the opposite. And even if the template gets the intended number of significant digits wrong, then except in situations where a human reader can infer it from the context it is usually correct and encyclopedic to round the numbers.

But there is an unrelated anomaly in the top right cell of the table. I am taking this to Template talk:Convert, because it's clearly a bug that needs fixing. Hans Adler 09:40, 9 August 2009 (UTC)

¶ I don't see the anomaly at first glance, Hans. If you're being so precise as to specify 4,700.0 square miles, then you are giving 5 significant digits, which are converted to 5 significant metric digits. The range is between 4,699.95 sq. miles and 4,700.05 sq. miles; otherwise the figure would be either no more than 4,699.9 square miles or no less than 4,700.1 square miles —— Shakescene (talk) 21:05, 10 August 2009 (UTC)

Do we really need this whole conversion business at all? As stated above, the conversion is not 100% reliable and it's not "official info" anyway. Maybe we should just use English units in American/British articles and metric units everywhere else. Offliner (talk) 10:29, 9 August 2009 (UTC)

But this is the English-LANGUAGE Misplaced Pages, not tied to any one country.

In the UK and Ireland metric is commonly mixed with Imperial units in everyday life; in the UK some things such as road distances and heights, and pints of beer served on draight, MUST be measured in Imperial; in Canada metric is most commonly used, with occasional use of US Customary simply because of the close ties with the US; in Australia and New Zealand exclusively metric and so on.

Last night I was talking to someone from mexico and said that Cambridge was about 80 km from London, whereas I would never say that to an English person (I would say about 50 miles). Yes, the conversions need to exist. Again, if using {{convert}} and the MoS then says "don't use conversions except in this or that circumstance" we can probably change the templates and 90% of articles will immediately conform (the remainder being for things like historical use of units, or quoted sources, etc). So, even if the conversion is not particularly useful in itself, simply as a marker that "this is a measurement" is. I know {{val}} also stands for that purpose but the same applies, mutatis mutandis. It is also extremely helpful for people translating across different Misplaced Pages (what am I supposed to do, for example, if I translate a French article about an American car?) SimonTrew (talk) 10:51, 9 August 2009 (UTC)

To Hans: I would not write 4,700 if only the first two digits are significant: instead, I'd write 4.7 thousand; likewise, I'd not write "50" if only the first digit is significant (third cell of bottom row): I'd write "fifty" (or even "about fifty", if appropriate). And I'd like the template to assume that the zero in "50" is significant, for this reason. I once read about an editor converting numbers such as 187, 190, 191, and 194 and being surprised that the second one was converted with less precision. --A. di M. 13:12, 9 August 2009 (UTC)

Just noticed a bug: {{convert|470.00|mi2|km2}} gives 470.00 square miles (1,217.3 km), with one 0 after the point instead of two. --A. di M. 13:25, 9 August 2009 (UTC)

I might say 4.7 thousand square metres too, though many don't, and the template has the capacity for a number of such constructions. However, if you see "4,700", the safest assumption is that it's precise to the nearest 100. As for the bug mentioned above, it should be fixed as soon as an admin puts in the new code. JIMp _talk·cont 17:48, 9 August 2009 (UTC)

Hum... maybe for 4,700 I agree, but in cases such as 5,000 I think that assuming that none of the zeroes is significant is excessive. When giving numbers with two sigfigs, there is a 1-in-10 chance that the second one is 0. So I'd assume that numbers such as 500,000 have two significant digits. What do you others think? --A. di M. 22:15, 9 August 2009 (UTC)

Which should generally boil down to giving an output of at least two significant figures which is just what the template does. So, yeah, I think that's just about right. JIMp _talk·cont 00:32, 10 August 2009 (UTC)

No, it should assume at least two significant digits in the input, not in the output. 14 kilometres (8.7 mi) is excess precision. --A.  di M. 23:48, 10 August 2009 (UTC)

I think a template that automatically treats a zero as not a significant figure is a bit of a worry. Take the areas of the states of the United States. it would be bizarre to think that the areas of the states of Washington and North Dakota were less accurately surveyed than the other 48 states simply because the areas in square miles happened to end in two zeros . Michael Glass (talk) 13:02, 10 August 2009 (UTC)

So, your first step is to compare these with the areas of other states and base your rounding on that. Without this comparison how else could you justify assuming the zeros were significant? Zeros may or may not be significant whether you use the template, a calculator or do the conversion in your head, you have to deal with this. With nothing else to go on standard practice is to regard the zeros as not significant (and generally they aren't). JIMp _talk·cont 13:42, 10 August 2009 (UTC)

My 2003 Statistical Abstract of the United States (Table No. 359) converts North Dakota's 70,700 sq. mi. (yes MOSNUM fanatics: sq. mi. is their official U.S. Government statistical abbreviation, periods and all, not some archaic idiosyncrasy of mine) to 183,112 sq. km. (their usage again) and Washington's 71,300 as 184,665. (I might be able to dig out the actual acreage, square feet or square meters from somewhere in my desktop's archives.) Just as in the debate over what to introduce between quotation marks, sometimes there's no substitute for checking the source, nor for making your degree of precision clear to the ordinary, non-technical reader. —— Shakescene (talk) 21:05, 10 August 2009 (UTC)

Treating a number ending in a zero as being automatically less accurate than a number ending in any other numeral strikes me as some kind of magical thinking. Obviously there are times when the zero is not significant, but by taking it for granted that it is always non-significant is like some kind of superstition, where inaccuracies come in even tens and hundreds just as bad luck is supposed to come in threes. These things need to be judged on a case by case basis. Michael Glass (talk) 14:00, 12 August 2009 (UTC)

It may seem like magic but it's a pretty standard approach which in the vast majority of cases gives appropriate results. Of course there will be cases where the zero is significant but the template makes allowance for that. If you prefer the calculator, there's nothing wrong with that but you'll still have to know what you're doing. JIMp _talk·cont 15:30, 12 August 2009 (UTC)

I agree with Jimp. There is a clear difference in implied precision between using 4000 and 4000.0 when specifying a measurement. The default should be to use standard scientific convention for specification of precision. Any "anomalous behavior" can be corrected on a case-by-case basis. Often this is caused by the choice of units, e.g. 4 km vs. 4000 m. However, there are some cases where uniformity in units is desired and there can be unintended results. (For example, the areadisp in {{infobox settlement}}) Plastikspork (talk) 16:36, 12 August 2009 (UTC)

It's not magical thinking, it's user friendliness. The only reasonable alternative would be for the template not to guess a precision and simply print a red error message when no precision is provided explicitly. That wouldn't exactly encourage editors to use it.

A better example of magical thinking in this context is nonsense such as the claim in the article Vienna that the city had 1,680,266 inhabitants in the 1st quarter of 2009. I hope that's not true, because a completely constant number of inhabitants over 3 months can only be achieved with very rigorous methods that I would probably suffer from when I move there. The same editors who insist on writing out even the last digit in such a case (it happens in all the best encyclopedias, not just Misplaced Pages) would shy away in horror from the claim that when computed using a certain well-defined algorithm based on well-defined official data, the average population of a certain village in 2008 was "1680.266 inhabitants". Hans Adler 20:40, 12 August 2009 (UTC)

Truncating the year (not in a date range)?

Another user has questioned my copy-editing of an article in which I reformatted some two-digit dates into 4-digit format (for example, in "from 1930 until -54" I changed "-54" to "1954", and in the passage "...in 1954 XYZ bought the blah-blah-blah, then XYZ merged ZYX into the QRS, which in -55..." I changed "-55" to "1955"). He points out (correctly, as far as I can tell) that nothing in WP:MOSNUM expressly states that, except for the closing date in a date range such as "2005–06", all four digits should be included when expressing a four-digit year. Apparently this user has been expressing years in a two-digit format whenever a four-digit year had previously appeared in the same paragraph.

I have a hunch that this issue isn't addressed in MOSNUM because the question never arose earlier -- contributors have assumed that years should be expressed using all digits, with the notable exception of date ranges (which have been discussed several times). Now that the question has arisen, I think that MOSNUM needs to be revised to clarify that every stand-alone mention of a year should use all of the digits in that year. Accordingly, I would like to append the following to the second bullet in WP:YEAR: "When listing a year outside the context of a year range, use all digits (1954, not '54 or -54)."

Please comment on this proposal. --Orlady (talk) 03:29, 10 August 2009 (UTC)

I can't see really how this comes under WP:YEAR at all, but in my opinion "from 1930 until -54" can then only mean to the year -54, which there never was one of, so balderdash. Or it is supposed to mean a dash, then it is simply essentially repeating the word "until" (tautologically and ridiculously) and so it is a range, and does not conform to WP:YEAR. I think his argument boils to nonsense and you are correct. He is simply using a bizarre form of abbreviation for dates, which I don't think conforms. That's my opinion, and I would take all of those tacks to say his -54 etc is simply not conforming. SimonTrew (talk) 13:18, 10 August 2009 (UTC)

I agree. Legislating against this eccentric notation is about as necessary as legislating against a specific misspelling of a word. The relevant section is already too long, and we shouldn't make this worse because of a single editor. Hans Adler 14:03, 10 August 2009 (UTC)

"from 1930 to -54" is just eccentric, although it's easy to see how it was arrived at. If it were written "from 1930 to '54", it would be an unusual style, but would reflect common speech and common informal written abbreviations. However, it would still slow the reader down enough to justify changing it to 1954. —— Shakescene (talk) 21:16, 10 August 2009 (UTC)

I've never seen hyphens or dashes used for that; as for apostrophes, "from 1930 to '54" would be fine in principle, but given that we already forbid contractions such as "aren't", I wouldn't mind forbidding this, too, if there's consensus to do that. --A.  di M. 23:54, 10 August 2009 (UTC)

I just add my opinion to this as Orlady has left a note on my talk page to let me know about this discussion. Thanks for that note, Orlady! The original idea comes from an author who is convinced that this would reflect a personal style and expression of that very author. I disagree with that opinion and fully agree with Orlady and above other comments here. The topic is not worth discussing as the way to deal with years as outlined by Orlady above, and common use on Misplaced Pages, is satisfactory, widely accepted,easy to read and does not require change. Everything is fine and changing the satisfactory status quo would only produce more work and keep people busy with corrections. doxTxob \  00:41, 11 August 2009 (UTC)

WP:OTHERDATE

There is something flawed in the statement of this section. On one hand, "In the main text of articles, the form 1996– ... is preferred in infoboxes", and yet "The form since 1996 should be used in ... article text and infoboxes". Which is it? And also, I don't see anything wrong with using "xxxx-present" in an infobox or a list. It doesn't flow well in prose which is where I support "since xxxx", but otherwise it need not be so awkward-looking. The section argues against it because "'the present' is a constantly moving target", but using "since xxxx" uses "the present" as a reference point. BOVINEBOY2008 00:52, 12 August 2009 (UTC)

here's the text of WP:OTHERDATE as it now stands - i agree that it is weirdly unclear, as well as pretty unreasonable:

Dates that are given as ranges should follow the same patterns as given above for birth and death dates. Ranges that come up to the present (as of the time that the information was added to the article) should generally be given in ways that prevent their becoming counterfactually obsolete, e.g. from 1996 onward (as of October 2007), not from 1996 to the present; "the present" is a constantly moving target. In the main text of articles, the form 1996– (with no date after the en-dash) should not be used, though it is preferred in infoboxes and other crowded templates or lists, with the caveat that they may need to be examined by editors more frequently to see if they need to be updated; it is helpful to other editors to add an HTML comment immediately after such constructions, giving the as-of date, e.g.: <!--as of 10 October 2007-->. The form since 1996 should be used in favor of 1996–present in article text and infoboxes.

i understand that there are situations in which "to the present" can become obsolete faster than anyone will catch & update it, especially if it's buried somewhere in a text. but the prohibition of "YYYY-the present" in info boxes seems pretty outlandish, especially since that exact form is very widely used in infoboxes.

can we alter that bit to leave the phrasing of info boxes up to the relevant projects or template pages? and then can we try rephrasing this section so that it's comprehensible? Sssoul (talk) 20:35, 12 August 2009 (UTC)

I think it can simply be solved if "and infoboxes" is dropped from the last sentence. BOVINEBOY2008 12:39, 13 August 2009 (UTC)

Unknown birth year for living persons

The formats listed under Misplaced Pages:Manual_of_Style_(dates_and_numbers)#Dates_of_birth_and_death don't seem to include anything that would look good or make sense in the lead for a living person for whom the year of birth is in doubt. "Circa" and "floruit" are for ancient Athenians, and "before" is silly, especially when the day is known. The project page entry should allow the use of question marks in such cases, e.g., "Joanne Whalley (born 25 August 19?? in Salford, Greater Manchester) is an English actress." --Milkbreath (talk) 11:59, 12 August 2009 (UTC)

Indeed. One thing that is very common is that you can find out the age of a person at a given date. But if you don't know the birthday, that only gives the birth year up to a choice of two years. (The year gotten by subtraction and the previous year.) Came here for some guidance. Was trying to figure out Denis Halliday's year of birth; as a December 17, 1998 news story mentions he was 57, he was born between mid-December 1940 and mid-December, 1941 so it almost certainly is 1941. My solution was to say ca. 1941 in the body and put him in Category:1940s births. Looking at other pages there, there doesn't seem to be a precise standard, but ? marks, ca. , and "year1 or year2" are used frequently enough.John Z (talk) 01:33, 16 August 2009 (UTC)

Birthplace in opening

I have a question about the statement "Locations of birth and death are given subsequently rather than being entangled with the dates" in the "Dates of Birth and Death" section. I have deleted some instances of the birthplace when it is included in the opening parentheses alongside the birthdate, e.g. (born September 4, 1972 in Chicago, Illinois) becomes (born September 4, 1972). To me, this is what the indicated statement means. In some instances (primarily in shorter articles that don't have an "Early Life" section or somesuch), the birthplace information is subsequently only given in an infobox. I never delete the birthplace entirely from the article–only in the opening parentheses and only when the information is included elsewhere (including the infobox as "elsewhere"). I have had a disagreement with a couple people who state that the infobox doesn't count in this regard–that "subsequently" doesn't include the infobox. To me, the infobox is part of the article, and hence does count. Am I wrong on this? If so, I suggest that the statement be amended to include "(not including an infobox)" after "subsequently", because if that's the intended interpretation then right now it's misleading. GreenLocust (talk) 19:32, 12 August 2009 (UTC)

I think the infobox does not count, but I do think your interpretation of the rule is right otherwise. The user of Misplaced Pages shouldn't have to cast about poking into boxes for the information. Luckily, elegant writing is not mandatory here; you can always just add a sentence to the lead, like, "Doe was born in Farquardt, Indiana, and died in Blisterfoot, Arizona." --Milkbreath (talk) 22:44, 12 August 2009 (UTC)

For the full discussion in which three of us have taken the position (same as the fourth editor, Milkbreath, immediately above), contrary to GreenLocust's viewpoint, that he should not be deleting mention of birthplace from the text of dozens of articles on the basis that "it is already in the infobox", please see .--Epeefleche (talk) 22:34, 12 August 2009 (UTC)

For the hundredth time, the basis is what the style is as given in the MOS, not that "it is already in the infobox". I really wish you would stop misrepresenting my stated reason for the deletions. And I don't think you pulling in selected WikiBuddies counts as a "full discussion", which is why I brought it up here. GreenLocust (talk) 23:47, 12 August 2009 (UTC)

Let me put it this way: each of the deletions by GreenLocust of birthplace info from 60-odd bios, which were not accompanied by placement of the birthplace info elsewhere in the text of the article, bore the following explanatory edit summary: "(no birthplace in opening per MOS - already in infobox).--Epeefleche (talk) 00:42, 14 August 2009 (UTC)

I'm about to propose a change to the project page (which is edit-protected and requires the approval of an admin): Pursuant to discussions here and here, I'd like to change Misplaced Pages:Manual_of_Style_(dates_and_numbers)#Dates_of_birth_and_death, the last bullet point, "Locations of birth and death are given subsequently rather than being entangled with the dates." I would like it to read thus: "Locations of birth and death should appear in the text of the article rather than being entangled with the dates." What do you think? Will that do it? --Milkbreath (talk) 23:07, 12 August 2009 (UTC)

I favor tweaking it to "in the body of the article rather than being entangled with the dates in the opening." Chris the speller (talk) 00:20, 13 August 2009 (UTC)

This discussion should be taking place on WT:MOSBIO. Although this guideline (WP:DATE) asks editors to avoid entangling the locations of birth and death with the dates, its concern is with the dates, not with the eventual fate of the locations. WP:MOSBIO lays out what should be included in the opening; locations are not specified. I think that guideline should be changed to specify where the locations should appear. Chris the speller (talk) 00:17, 13 August 2009 (UTC)

I see a circle forming. Over at Misplaced Pages:Manual_of_Style_(biographies)#Opening_paragraph it says nothing about where the birth and death locations should go. It says only "Dates of birth and death, if known (see Misplaced Pages:Manual of Style (dates and numbers)#Dates of birth and death)", sending us right back here, which is right because an editor will look here to find out how to format the dates, and he will never look there for that. The locations should be in the lead if the article is short, and in the body in sensible chronological position otherwise. This should not be prescribed. The problem that I'm trying to solve is that it is possible to interpret "subsequently" in the guideline as it stands to mean "in the infobox or in the body of the article", leaving the information out of the article proper sometimes, which I and some others agree is undesirable. I don't want to use MOS Dates to prescribe a place for the locations to appear, but it seems that it will be an unavoidable by-product of clarifying the point in question. I'm fine with "body" if everyone thinks that the word will help the inquiring editor to not consider the infobox included better than "text" does. --Milkbreath (talk) 00:33, 13 August 2009 (UTC)

• Hi. I see a couple of issues (and defer to you as to where best to address (if at all).

1) Mr. Green believes that the current MOS language impels him to ensure that the place of birth reflected in the infobox only. With this belief as his guiding light, he has just deleted the textual references to individuals' places of birth from 60-odd articles.

Note: He has not moved the references to a later sentence withing the body of the article; rather, he has deleted the only reference to the person's place of birth in the text of each article.

He believes this is mandated by the MOS language that says: "Locations of birth and death are given subsequently rather than being entangled with the dates." He asserts that "subsequently" does not mean "subsequently within the text of the article," but rather in essence that it means "subsequently within the text of the article or alternatively in the infobox." As he puts it at , "The infobox is, in fact, part of the article." (emphasis added)

Everyone but Mr. Green who has commented on this point reads the MOS as meaning in effect: "subsequently within the text of the article -- but that doesn't refer to the summary infobox."

I fear that the change proposed above would not help Mr. Green and his ilk, because they would simply say that "the text of the article" includes the infobox.

I find the explanantion to be somewhat fatuous, because carried out to its logical lengths, one could delete the ballplayer's name, date of birth, and teams played for from the article itself -- as they are all reflected in the infobox as well.

2) The second issue, which is secondary, is whether the rule itself makes sense. While this is supposed to be encyclopaedic, Brittanica and other well-thought-of encyclopedias list the date and the place of birth together at the outset.

And logically, the fact that ballplayer A was born on March 2 may be of significantly less interest than the fact that he was born in the Dominican Republic -- the World Baseball Classic, for example, focuses on place of birth but not birthdate. And it is important for Olympic athletes, Davis Cup players, etc. -- much more so than for example the day and month of birth. I really see no overarching policy reason -- even in a non-prescriptive MOS -- to suggest that it is better to put it in the second sentence (or paragraph, or section) than the first. The sentence structure "X was born on Y in Z" is likely the most common you can find in biographies anywhere. Just my two cents, for what they are worth.--Epeefleche (talk) 03:03, 13 August 2009 (UTC)

Again, the purpose of this guideline is "to achieve consistency in the use and formatting of dates and numbers". The location of a person's birth is not a date, and not a number. By keeping the discussion here, you are shutting out editors who watch WP:MOSBIO and who know something about how to write biographical articles. This is completely wrong. Chris the speller (talk) 03:16, 13 August 2009 (UTC)

Then why don't we just delete the part of this WP that states: "Locations of birth and death are given subsequently rather than being entangled with the dates." It strikes me that if this issue is not relevant on this talk page, the issue is likewise not relevant to this WP. It is the language that is in this WP that is causing all the ruckus. It is the language in this WP that Mr. Green quoted as impelling him to make the deletions. Likewise (logicially) he started this discussion here.--Epeefleche (talk) 03:30, 13 August 2009 (UTC)

Just adding my two cents, but when I am writing a stub or start class article, especially ones where the birthplace is of key importance (usually athletes that have notability due to national representation), I will always include the birthplace in the opening paragraph, such as John Smith (born 26 January , 2000 in Sydney, Australia). Also can I add, that just because something is stated in an infobox, does not mean it can't be stated in the main article as the infobox should be a brief summary of the page. I think the deletion of a birthplace in the opening paragraph is stupid as it proves to be a key part (which is what the opening paragraph includes) in many high level amateur athlete articles. JRA_WestyQld2 09:11, 13 August 2009 (UTC)

(Indent depth has no meaning, just wanted to follow everything so far.) I've always liked and seen the sense in keeping the dates together and by themselves in parentheses right after the name. I won't go into why because it really doesn't matter as long as we all always do it the same way. Consistency throughout the encyclopedia is the reason for any such guideline, and the present formula is at least tidy and easy to understand and implement. The problems are two: editors often don't see the need to adhere to any formula, and the guideline as it stands is unclear. I don't see why we can't specify that information in an infobox is supplemental to an article and not part of it. I have made that suggestion over at Wikipedia_talk:Manual_of_Style_(infoboxes)#Discussion_at_Wikipedia_talk:Manual_of_Style_.28dates_and_numbers.29.23Birthplace_in_opening and invited them to discuss the point here. MoS Infoboxes is the right place to address the problem at the root, and whatever the guideline becomes there can be incorpoarted here and at MoS Bio (where I see that Sssoul has already invited them to join this discussion). --Milkbreath (talk) 10:29, 13 August 2009 (UTC)

I'm really hoping the issue isn't really associated with infoboxes per se, as with how to present information in general. My participation in the MoS Infoboxes area is mostly due to the way Certain Editors (no one here, as far as I know) feel that infoboxes are a blight on Misplaced Pages and should be eliminated (almost?) everywhere. I fight these people, as I've not seen many articles which wouldn't be improved with an infobox of some sort; everything could use a summary IMHO.

Anyway, while ideally all information in an infobox is present in the article's prose, and not every article, such as the ones I tend to work on, follow that ideal, I suspect biography articles are different from my regular domain of mostly "bridge" (as in crossing valleys/rivers/whatever) articles. Asking general infobox people to come up with a rule which mainly applies to biographies will likely get you a lot of confusion, rather than useful results. I suspect your best bet is to ask people interested in Biography articles specifically, as y'all know more about which makes more sense for such. For all of me, it might be more important for some bio articles to center around dates, and for others (subset: athletes) to center around places. I dunno. - Denimadept (talk) 20:01, 13 August 2009 (UTC)

The issue arose out of the edits of our friend GreenLocust. If you read his original question above, perhaps you'll agree with my thinking, that the propblem really arises out of the hazily defined role of the infobox in an article. Is it a supplementary summary, a fingertip compendium? Or can it actually be the whole article in and of itself? Or does its role always depend on the context? I think of it as nothing more than a handy way to organize the facts of an article for easy reference by the user, but not as a substitute for the text of the article, which text is the article per se. Me, I like infoboxes. --Milkbreath (talk) 21:20, 13 August 2009 (UTC)

to me the infobox is clearly a supplement to an article - one that can be skipped without losing any information; articles need to stand on their own, not rely on the infoboxes to fill in blanks. if that's been misunderstood, the guidelines need to be made clearer on that point.

but (like others have already asked): what is the rationale for the dictum that a biography shouldn't state something as plain and simple as "The subject was born on date in place" - does it mess up some template or something? Sssoul (talk) 21:47, 13 August 2009 (UTC)

This whole thing started when GreenLocust was going along taking the locations of birth and death out of the parentheses containing the dates of birth and death, in accordance with the MoS. Thing is, he would not restore that information to the text of the article if it was covered in an infobox, following the guideline on this project page that states under Misplaced Pages:Manual_of_Style_(dates_and_numbers)#Dates_of_birth_and_death, "Locations of birth and death are given subsequently rather than being entangled with the dates." He interpreted "subsequently" to include "in an infobox". I and others think that that is a misinterpretation that needs clearing up on some project page somewhere, I think on at least three: WP:MOSBIO, WP:MOSNUM, and WP:IBX. Locations of birth and death should appear in the running text whether they are in an infobox or not. --Milkbreath (talk) 22:22, 13 August 2009 (UTC)

Well said. I might add that GreenLocust's interpretation has so far been his alone. All others who have opined on that point here or at the discussion at do not read it the same way that GreenLocust reads it.--Epeefleche (talk) 00:39, 14 August 2009 (UTC)

And might I add that the fact that the people who you invited in (everyone but Milkbreath, Denimadept, and Sssoul), using a misrepresentation while doing so, happen to agree with you is not terribly surprising. You are so disingenuous as to be ridiculous. GreenLocust (talk) 01:35, 14 August 2009 (UTC)

I see an infobox for biography is likely a summary, but I don't claim to be definitive. An infobox for a bridge or ferry might contain information otherwise not in the article. My area of interest is in the latter, specifically {{infobox bridge}}. Y'all Bio people need to talk this one out. GreenLocust, you could always get people who agree with you to participate here, y'know. - Denimadept (talk) 04:38, 14 August 2009 (UTC)

Green--I don't believe I'm misrepresenting anything. I've pointed people to our discussion at , so that they can see it for themselves rather than rely on my characterization. And I've accurately quoted the edit summary that you used in your 60-odd deletions. To the extent that I've invited people, generally its only because I knew them to be involved in discussion of this issue/formation of the existing policy. Prior to this issue arising, I only had prior contact with one of all these people, and in that case only once, in passing.

I think that to the extent that people have spoken to the issue, they do not support your deleting the only textual reference to the location of birth from the article, without re-inserting it later into the article, with your edit summary explanation of "(no birthplace in opening per MOS - already in infobox)", as amplified by the discussion above and at --Epeefleche (talk) 06:00, 14 August 2009 (UTC)

There is no need for this dispute to become personal. I would agree that while the birthplace and deathplace should not be within the parenthetical that contains the dates, they do need to be in the article body somewhere. The infobox does not count for this purpose. Powers 18:02, 14 August 2009 (UTC)

slight diversion

¶ This is one of a whole host of areas where I think the Manual could be usefully shortened with little or no loss (perhaps even some gain), and thus able to concentrate on areas where there are genuine sources of possible confusion, error, ambiguity, obscurity or offensiveness (as well as become more likely to be read, remembered and heeded). I know that I'm in a distinct minority here, because most of those who spare the time and thought to contribute to this talk page are more likely to favour uniformity for its own sake.

But I really think that this is the kind of question (like whether one writes "4 April", "4th April", "4th of April", "April 4", "April 4th" or "April the 4th") that's best left to the context of a specific article and to its editors' own style and preferences. That Napoléon Bonaparte was born in Corsica and died on Saint Helena, that Adolf Hitler was born in Austria and died in Berlin, that Barack Obama was born in Hawai'i, or that Paul Gauguin died in the Marquesas Islands are probably just as important as, or more important than, the exact year of their births or deaths. That a random French writer was born and died in Paris, or a random English thinker in London, is probably less important than the years of his or her life, and could just as well be left to the following text.

Since many biographical articles are inevitably destined to be slightly-expanded stubs, let me note for whatever it's worth that, among my one-volume cyclopedias, Le Petit Larousse Illustré (2004) includes places as well as dates of birth & death within the initial parentheses (brackets), but the Merriam-Webster Collegiate Encyclopedia (2000, based on the Britannica) and the Concise Columbia Encyclopedia (1983) do not. The Cambridge Encyclopedia (2nd edition, 1994) gives just the dates within parentheses, but usually immediately followed by a comma and "born in "; however, the place of death is often not mentioned. —— Shakescene (talk) 22:23, 14 August 2009 (UTC)

Any loosening of the current rule would be beneficial. Again, I favor the deletion of the rule in this specific guidance for the reason raised by the editor above who says that this should be about numbers -- if the talk page discussion should not include a discussion about this issue because it is too far afield, certainly the proscription contained in the rule here should be deleted if for no other reason than it is in the wrong location. I, for one, for the reasons well-put in the above examples of Bonaparte and Hitler, etc., think that that we could do well with the rule being scrapped completely from any other guidance as well.--Epeefleche (talk) 05:03, 15 August 2009 (UTC)

So now ...

Given the above ample discussion, and the related discussion at that began eight days ago, unless a consensus is voiced against the following two propositions, I propose that within one week:

a) given that a clear consensus has been voiced of the seven editors who have spoken to the issue other than Green Locust (including me, JRA_WestyQld2, Septentrionalis PMAnderson, SMcCandlish, Milkbreath, Sssoul, and Powers T), Green Locust either: 1) roll back his 60-odd deletions of reference to place of birth, or 2) re-insert that information later in each of those articles; and

b) that we delete from this MOS guidance the following phrase: "Locations of birth and death are given subsequently rather than being entangled with the dates."

This change to this guidance would accord with my view.

It would also accord with the views of JRA_WestyQld2 ("when I am writing a stub or start class article, especially ones where the birthplace is of key importance (usually athletes that have notability due to national representation), I will always include the birthplace in the opening paragraph). It would appear as well to accord with the views of Septentrionalis PMAnderson ("not necessary in the first parenthesis - although giving them there is probably harmless for living persons").

The same with the comments of Milkbreath that "you can always just add a sentence to the lead, like, 'Doe was born in Farquardt, Indiana, and died in Blisterfoot, Arizona".

This would also comport with the observations of Shakescene: "That Napoléon Bonaparte was born in Corsica and died on Saint Helena, that Adolf Hitler was born in Austria and died in Berlin, that Barack Obama was born in Hawai'i, or that Paul Gauguin died in the Marquesas Islands are probably just as important as, or more important than, the exact year of their births or deaths. That a random French writer was born and died in Paris, or a random English thinker in London, is probably less important than the years of his or her life, and could just as well be left to the following text. Since many biographical articles are inevitably destined to be slightly-expanded stubs, let me note for whatever it's worth that, among my one-volume cyclopedias, Le Petit Larousse Illustré (2004) includes places as well as dates of birth & death within the initial parentheses (brackets), but the Merriam-Webster Collegiate Encyclopedia (2000, based on the Britannica) and the Concise Columbia Encyclopedia (1983) do not. The Cambridge Encyclopedia (2nd edition, 1994) gives just the dates within parentheses, but usually immediately followed by a comma and "born in "; however, the place of death is often not mentioned."

And Denimadept observes, "For all of me, it might be more important for some bio articles to center around dates, and for others (subset: athletes) to center around places. I dunno."

And Ssoul asks: "(like others have already asked): what is the rationale for the dictum that a biography shouldn't state something as plain and simple as "The subject was born on date in place" - does it mess up some template or something?."

Also with the views of SMcCandlish that at least there should not be a blanket rule of this sort ("If there is not enough material in the article for such a section, then it should be left as-is, because the article is a stub.").

It also comports with the views of Chris the Speller that this is the wrong place-- even on the talk page of this guidance--for a discussion of any such rule ("This discussion should be taking place on WT:MOSBIO. Although this guideline (WP:DATE) asks editors to avoid entangling the locations of birth and death with the dates, its concern is with the dates, not with the eventual fate of the locations. WP:MOSBIO lays out what should be included in the opening; locations are not specified."). If this guidance's talk page is not a place to discuss the issue, I would suggest that the guidance is not the place for such a proscription. If such a proscription should appear at all (and most of us it would seem don't believe that one should appear; certainly not a blanket one as exists now), then it should appear in WP:MOSBIO (which does not have such a proscription).

--Epeefleche (talk) 22:59, 16 August 2009 (UTC)

I am now free to speak for myself. My understanding is that we had two reasons for generally supporting (birthdate, deathdate) in parentheses.

• The chief one is that four items (December 1, 1804, in Pressburg - June 15, 1848 in Constantinople) in a parenthesis is a little overstuffed.
• Secondarily, placenames are more likely to require some form of context than dates (Pressburg is now Bratislava, and no longer in the Austrian Empire; Constantinople is now Istanbul); whereas the difference between Old Style and New Style is smaller, matters less often, and is less controversial when it does.

Both these are minor - and neither should rule out (born 1968 in Toronto, Canada).

Leave this, as often, to the judgment of the writers of the article; and state our reasons in text so we don't have to go through this again. That's what guidelines are for. Septentrionalis PMAnderson 19:37, 17 August 2009 (UTC)

Non-breaking space for unit names?

Unit symbols and preceding numbers are separated by non-breaking spaces. Should the same convention be used for unit names? (e.g. 35 meters for "35 meters") — Nahum Reduta (talk|contribs) 06:55, 13 August 2009 (UTC)

No. Symbols, being usually short, should kept with their numbers. Whole words should wrap like whole words. JIMp _talk·cont 11:10, 13 August 2009 (UTC)

"Adopting suggestions from standards bodies"

I have put the two paragraphs under this heading in their own subsection. The reasons I did this are as follows:

• The original placement broke the style of what preceded and followed it.
• The original placement split two related subsections.

The passage was out of place where I found it. However, someone might be able to find a better place for it than where I have put it. Michael Glass (talk) 08:03, 15 August 2009 (UTC)

I made some changes to the tone and phrasing of that paragraph—it was almost aggressive, and belaboured the idea of 'the real world', without adequately referring to the role of consensus. I also managed to simplify things a little bit. Do the changes look reasonable? TheFeds 20:42, 15 August 2009 (UTC)

The "real world" was use to emphasize that the overnight consensus of 20 people should not force an obscure standard into the Manual Of Style. The consensus has to reflect the writing style of the real world not some ideal dream world. It took 3 years to rid Misplaced Pages of the Kibibytes and Mebibytes crusade. -- SWTPC6800 (talk) 20:58, 15 August 2009 (UTC)

Definitions needed?

One of the first pieces of advice in the section on units of measurement says:

• Aim to write so you cannot be misunderstood.

Unfortunately this section undermines this aim by using two terms that may defy understanding. These are

• region-specific topics, and
• internationally accepted units.

To clear up confusion we need to define what we mean by region-specific topics and internationally accepted units.

In plain English, a region-specific topic, for example, may refer to any region and any topic, e.g., the Pavillon_de_Breteuil, the home of the International Bureau of Weights and Measures. But of course it is referring in a roundabout way to US and UK based articles that happen to use Imperial or US Customary units. In this case it may be better to find some other term that won't be so ambiguous or confusing or simply write US-specific articles and some UK-based articles.

Internationally accepted units may need explanaion, perhaps like this:

Internationally accepted units are:

• SI base and derived units
• Non-SI units accepted for use with the SI
• Units based on fundamental constants
• other non-SI units that are used internationally

What do others think?Michael Glass (talk) 08:48, 15 August 2009 (UTC)

That all sounds pretty reasonable to me. I certainly agree about region-specific topic. My only minor comment there is that, I imagine, some US-specific articles may also use metric/SI, e.g. those that are writing about science or engineering projects that are based in the US, but use metric/SI units (e.g. NASA projects, and, in theory, all US government projects). So perhaps "most US-specific articles and some UK-specific articles". And why "specifc" for one but "based" for the other?

Cut "base and derived" - just put "SI units"

"other non-SI units that are used internationally; I think you could cut "non-SI" here as it is implied (it is more appropriate for the ones "accepted for use with (the?) SI"). Perhaps give examples, e.g. the degree (angle), nauticl mile? And for constants e.g. Planck's constant (physics), Pi (mathematics), etc. For other non-SI units perhaps carat (gemology). No need for an exhaustive list, just a couple of examples for each.

Since in a sense US Customary/Imperial units are also accepted internationally, perhaps anyway this term is inappropriate. Suggest "widely used worldwide" but that is not brilliant either. SimonTrew (talk) 21:10, 15 August 2009 (UTC)

It's intended to refer to the unit in most common use worldwide for the type of measurement being mentioned. For example, the diagonals of cathode-ray tube displays are by far most commonly measured in inches around the world; exceptions are South Africa and Australia where centimetres are used. So, the diagonal of a CRT display should be given in inches and followed by a parenthetical conversion to centimetres; but an article specifically about South African CRTs would use centimetres, with a conversion to inches between parentheses. I'd use "for a given measurement, use the unit which is most commonly used worldwide for that type of measurement", or some less wordy equivalent thereof if anybody can find one. The "for that type of measurement" part is essential, both in non-regional and in regional articles: the unit commonly used for the energy of airsoft pellets is not the same used for ultra-high energy cosmic rays, despite being measurements with the same dimension and roughly the same magnitude; likewise, as Trew said, the units commonly used in US engineering are not the same units commonly used in US household items. (As for "Non-SI units accepted for use with the SI", that's the name the SI uses verbatim, so I'd keep the "non-SI" even if it's redundant. And a list of internationally accepted units including "SI units" and "other non-SI internationally accepted units" looks tautological to me.) As for "region-specific topic", that's as in WP:ENGVAR. --   A. di M. 22:05, 15 August 2009 (UTC)

I agree.

We clearly need some units that are not accepted by SI at all for use throughout Misplaced Pages per the principle you brought up above. Obviously, we aren't going to do away with the month or the year, even though neither is recognised by SI for the very good reason that neither is of consistent length. There is also clear benefit in using units such as inches, feet and nautical miles in contexts where they are common internationally, even if they are not defined by SI (I think the nautical mile is, but not the other two). On region-specific topics where there are region-specific deviations from these units (and this is not just in the US and UK), we should adopt the region-specific deviations. Pfainuk talk 22:51, 15 August 2009 (UTC)

Non-SI units accepted for use with SI lists the minute, hour, day, degree of arc, minute of arc, second of arc, hectare, litre and tonne as non-SI units accepted for use with SI. It doesn't seem to mention multiples of the litre (millilitre, kilolitre, megalitre, etc.). It doesn't mention the week, month, year, decade, century, annum, kiloannum, megaannum, etc. It doesn't mention the kilometre per hour, litre per hundred kilometres, etc. These should be allowed without SI coversions.

The electronvolt (kiloelectronvolt, megaelectronvolt, etc.) is not SI nor is it based on fundamental constants but a hybrid of both but these should be allowed and we generally won't need to convert them to SI.

What about the kilowatt-hour, debye, astronomical unit, lightyear and parsec? I'd be inclined to convert them to SI depending on context.

"other non-SI units that are used internationally" is a little vague. Certainly we'd want the nautical mile and knot in certain contexts but a conversion to kilometres and miles (per hour) would be desirable. As noted above, we could agrue that imperial/US units are used internationally but we'd want these converted. Many units (e.g. the carat, calorie, ton of TNT, oil barrel, millimetre of mercury, atmosphere and Troy ounce) are used internationally but should be converted to SI.

We'd be better of ditching the ångström, bar, millibar, etc. entirely but there probably is little hope of that; however, we don't really need to convert these to SI (since it's just a matter of moving the decimal point). JIMp _talk·cont 23:02, 15 August 2009 (UTC)

Surely millimetre, kilolitre, kilometre per hour etc are SI derived units (or, at least for the latter, a non-SI derived unit accepted within SI, by transitivity)? I suggested butting "base and derived units" but surely e.g. millimetre is a dervied unit and thus SI.

As for angstrom, you will never get rid of this; in the field I work for (molecular modeling) it is pretty much a standard unit, and to write as tenths (or tenths?) of nanometres would be just odd. By the way my dictionary lists it as "angstrom" with no ring above, though of course its symbol is Å.

calorie poses a unique problem in that of course it should be kilocalorie, and using calorie in the convert template (for typical values for foods) puts the result in joules, not kilojoules i.e. it takes a calorie to be a calorie, not a kilocalorie. Yet the main text may use calorie and it looks clumsy or unduly pedantic to write kilocalorie. I almost had this problem with Bacon today; I used the convert template (with kcal) but elsewhere in the text it used "calorie" and it would have seemed pedantic to change it. Fortunately I escaped that one first as it was quoted (aw "zero calorie") and second since zero calories = zero kilocalories I could avoid the issue.

bar and millibar I would have more support for ditching, although certainly for weather forecasts in the UK the pascal is unheard of, and lines of the same pressure are isobars not isopascals.

Gravity is probably another one to add to the list e.g. defining things as zero G, 1 G, etc. Obviously gravity does vary slightly with longitude, latitude, various geophysical effects and altitude, but for all practical purposes 9.81 m/s is good enough, and to again a conversion is useful but simply to abandon giving it in G at all would be odd. And since, obviously, standard atmospheric pressure has rather a lot to do with gravity then those, by extension, could be argued to come under that wing.

i've rather rambled off the point. But I suppose what I am arguing is that the list of internationally accepted units in various fields is almost limitless, and really the context of the article should drive what is appropriate, not some more-or-less arbitrary rule. SimonTrew (talk) 14:36, 16 August 2009 (UTC)

SimonTrew asked, by way of a question mark, "surely millimetre, kilolitre, kilometre per hour etc are SI derived units (or, at least for the latter, a non-SI derived unit accepted within SI, by transitivity)?" Meter is a base unit; adding an SI prefix does not change the status of a unit among base, derived, or accepted for use with SI. Litre is a special name for cubic decimeter, which is a derived unit. Kilometer per hour is a unit accepted for use with SI. --Jc3s5h (talk) 15:38, 16 August 2009 (UTC)

Regarding which are base units, which derived, and which non-SI, I suggest a study of the official BIPM document on that. See section 2; prefixes (as multipliers) are in section 3; the litre (or liter) is in section 4 being "a non-SI unit accepted for use with the International System of Units".

A derived unit is the product of base units: whilst the metre is a base unit, the square metre is a derived unit. Metre per second is a derived unit; but since the hour is "a non-SI unit accepted for use with the International System of Units", the kilometre per hour is also.

It's not a good idea to encourage the use of "litre". Whilst the literal definitions of virtually all SI units have changed over the years, they have all retained their practical values - except for the litre. The 1901 definition was 'the volume occupied by a mass of 1 kilogram of pure water, at its maximum density and at standard atmospheric pressure'; in 1960 they noted 'the cubic decimetre and the litre are unequal and differ by about 28 parts in 10', whilst in 1964 they declared 'that the word "litre" may be employed as a special name for the cubic decimetre' and recommended that 'the name litre should not be employed to give the results of high-accuracy volume measurements'. See p.141 of the PDF doc linked earlier. According to my physics teacher, they made a mistake when cutting the original prototype kilogramme. --Redrose64 (talk) 17:04, 16 August 2009 (UTC)

"It's not a good idea to encourage the use of 'litre'." That's nonsense. This depends entirely on the purpose. Litres (cubic decimetres) and millilitres (cubic centimetres) are absolutely standard units throughout most of the metrised world. I have never heard anyone use "kilolitres", though. It's clear what is meant, but everybody calls it cubic metres. But a 2-litre bottle is a 2-litre bottle, not a 2-cubic-decimetre bottle. Trying to forbid such standard units as the litre looks to me like an attempt to introduce a problem that otherwise exists only in the minds of proponents of pre-metric systems: that the metric system is "unpractical" because it doesn't have all the necessary "natural" units such as the pint. We already have the litre and as the UK is slowly crawling towards full metrication I predict that use of the "metric pint" of 1/2 litre = 0.88 Imperial pt = 1.06 US pt will become standard in the same way that the metric pound of 1/2 kg = 1.1 lbs avdp has been standard in large parts of Europe for a hundred years. It's probably as easy as the pubs beginning to call a pint of beer 1.136 metric pints once they are allowed to do this.

In science and technology, cubic centimetres and cubic decimetres are also used under these names. But only very rarely in normal life. Hans Adler 18:28, 16 August 2009 (UTC)

I can't imagine that we actually ever do use the litre for high-accuracy volume measurements. And for most applications, an inaccuracy of 28 parts per million is so much smaller than the margin for error inherent in the measurement that it's totally irrelevant. To put it into perspective, that's a difference of nearly 16 litres when measuring the amount of water in Sydney Harbour. I see very little reason to avoid the litre normal (non-scientific) circumstances. Pfainuk talk 18:21, 16 August 2009 (UTC)

Besides, it's a problem stemming from an error that was corrected more than 40 years ago. For more than 40 years litre has been an exact synonym for cubic decimetre. We would only ever have to worry about this problem should we encounter pre-1964 sources with high-precision litre-based measurements. They would have to be converted into modern litres. But exactly the same problem exists with inches and whatnot, since very roughly around the same time the inch was defined as precisely 2.54 cm, etc., after it was previously slightly different in various parts of the world. Hans Adler 18:35, 16 August 2009 (UTC)

28 parts in 10 ain't that bad for two centuries ago and greater accuracy than you mostly find here. We surely shouldn't discourage the use of the litre and millilitre in cases where they are used in the world out there. Ask for a pint of beer in the pub & you shouldn't expect a 28-parts-per-million accuracy. JIMp _talk·cont 18:32, 16 August 2009 (UTC)

OK, OK, maybe I overstressed one tiny aspect which doesn't really matter. It began with my possible misreading of what had gone earlier. There appeared to be disagreement concerning which are base SI units, and which derived SI units, and somebody mentioned litre (or kilolitre, or something like that).

My intended point was that the BIPM document has already done all the categorisation, and that based on what it has on page 124 "Table 6. Non-SI units accepted for use with the International System of Units", litres are not SI units (base or derived). --Redrose64 (talk) 20:00, 16 August 2009 (UTC)

I would argue that there are some units that are not accepted by the BIPM but that we still have to accept, depending on context. The most obvious are the month and year, which are not defined by the BIPM for the very good reasons that they are not of consistent length. In other contexts, there are units that are generally used internationally - the barrel of oil, the inch for measuring the sizes of television screens (as cited above) - that are specifically not accepted by the BIPM.

We should generally use the most commonly used unit in a given context (and I would suggest that may well include using different units in different regional contexts). Pfainuk talk 20:25, 16 August 2009 (UTC)

I don't know why Michael Glass is continuously starting this kind of discussion. The intent of the rules about use of units is absolutely clear: Use those units that will be expected in this context by the greatest fraction of the expected readership. If some readers will need a conversion to understand a measurement properly, provide it.

The metric system in the sense of SI units + units accepted for use with SI is a useful first approximation for the practical result of this rule. It's not quite correct for a number of reasons

• SI does not give sufficient guidance to choose, e.g., between millilitre and cubiccentimetre.
• In specific contexts, certain units that are explicitly not approved are dominant and must normally be used, e.g.:
  • Years for longer periods of time.
  • Light years for distances between stars.
  • Inches for TV and computer screens.
  • Gallons for raw oil.
  • Typographic points in printing.
  • Metric carat for jewels.
  • Kilometres per hour for car speeds.
  • Litres per 100 kilometres for car fuel consumption.
  • Nautical miles for distances at sea, especially for the definition of territorial waters etc.
• In some regions – especially, but not only, the not yet fully metric countries – the usage patterns for units diverge from the international ones. This must also be taken into account whenever we have reason to believe that most readers will be from a specific region:
  • Inches for TV and computer screens in Australia. (It's hard to see how that might become relevant, though.)
  • Miles for road distances in the US and the UK.
  • Miles per hour for car speeds in the US and the UK.
  • Miles per gallon for car fuel consumption in the US and the UK.
  • Kilocalories instead of kilojoules for food energy in some countries.
  • Dekagrammes instead of grammes for cold cuts in Austria. (Again, this is more theoretical. I am sure one can find better examples.)

I see no need to change the current text. Hans Adler 21:06, 16 August 2009 (UTC)

In some countries, such as Italy (and, I think, most of the EU), food energy is "officially" measured in kilojoules, but about 99% of people would normally use kilocalories for that (calling them "calories" in casual speech, except when they want to make the quantity sound bigger, as in a TV ad claiming that their product can help you burn "up to 1000 kilocalories"). (And cold cuts are measured in hectograms in Italy.) --   A. di M. 21:20, 16 August 2009 (UTC)

My aim is the clarify the wording, not change the policy. If the intent of the wording is clear, then it might be possible to have the wording equally clear. For example, 'some regional topics' might be preferable to 'region-specific topics', and I can't see the problem of defining 'internationally accepted units'. For example:

Internationally accepted units are:

• SI units
• Non-SI units accepted for use with SI (e.g., the nautical mile)
• Units based on fundamental constants (e.g. Planck's constant)
• other units that are widely used internationally.

The basic problem is that we have the metric system that is used in most countries of the world, the US Customary system that is widely used in the US and the Imperial System, parts of which are still used in the UK and to a lesser extent in other English-speaking countries, and also in aviation and some specialised measurements such as computer screens. To cater for the needs of an English-speaking readership we need to provide both metric and traditional measures in a wide range of contexts. I think if we concentrate on the needs of readers we might make more progress. Michael Glass (talk) 23:39, 16 August 2009 (UTC)

According to the article the nautical mile is not accepted for use with SI. The phrase "other units that are widely used internationally" is pretty vague, in contrast to the narrowness of the three preceding points. Yes, that some of us use the metric system and others use either the US or imperial system is a problem. How does the change you're suggesting solve this? JIMp _talk·cont 00:29, 17 August 2009 (UTC)

The knot ant the nautical mile are listed here . Table 8 is appended to Chapter 4 of the BIPM brochure which is entitled, "Non-SI units accepted for use with the SI, and units based on fundamental constants". However, I do agree that "other units that are widely used internationally" is too vague. It could be rephrased as "other units that are widely used internationally for specific purposes" but if we tried to be more specific than that, someone is sure to come up with some measure that isn't covered. That said, I would welcome a better phrase, if anyone could come up with it. Finally, Misplaced Pages can't solve the issue of English-speaking people using different weights and measures; what we might be able to do is work out how to cater for these differences and how to express the guidelines in a way that is clear and helpful. Perhaps something like this would be the way to go:

Internationally accepted units are:

• SI units
• Non-SI units accepted for use with SI (e.g., the nautical mile)
• Units based on fundamental constants (e.g. Planck's constant)
• other units that are widely used internationally for specific purposes.

Michael Glass (talk) 01:40, 17 August 2009 (UTC)

If we're talking about the introduction of the section (the three-bullet list immediately under the header "Units of measurement"), you might replace "internationally accepted units for the topic at hand" with "the units in most widespread use worldwide for the type of measurement in question". As for the first bullet of "Which units to use", I don't think it's broken and doesn't need fixing. (As for your list, it'd be close to tautological if all SI units were "internationally accepted", and even that isn't the case: the megasecond isn't internationally accepted—and my browser's spell-checker even underlines it in red.) If something should be fixed, I'd replace "region-specific" with "regional and historical" (you might want to use cubits first in Noah's Ark), and the point about conversion should be added to the general principles (first three bullets), too. --   A. di M. 10:47, 17 August 2009 (UTC)

Cubits at Noah's Ark is a good example for a problem I was always sure must exist. For history/archaeology articles historical units are sometimes the best choice. In history because we may know the precise number in an obsolete unit but have no certainty about the conversion factor. In archaeology because measures may be exact integer multiples of a well known obsolete unit. In such situations the obsolete units are internationally the most accepted ones. Hans Adler 12:42, 17 August 2009 (UTC)

Yes, and indeed for Goliath's height etc (four cubits and a span wasn't it?) I forget how many spans there are in a cubit but it is well-defined, but nobody really knows how big a span was. A similar problem occurs with Roman stadia and for that matter inches/ounces (uncia); obviously we have a rough idea but not an exact one, which doesn't stop maths working but if quoting Latin mathematics that gives an example in these units, it is pretty pointless to convert them (e.g. one might say – I make this up – "if a right triangle has sides by the right angle of three uncia and four uncia, the the third side will be five uncia" and that is good regardless of how big the inch is.) SimonTrew (talk) 14:51, 17 August 2009 (UTC)

Date template

Why is {{date}} not mentioned at #Dates? Is it deprecated? It would save a lot of the which-order-do-we-put-it-in argument, if the <date formatting style> parameter be omitted. Consider: whether I use {{date|15 August 2009}}, {{date|August 15, 2009}} or {{date|2009-08-15}} these are all displayed the same, ie 15 August 2009, 15 August 2009 or 15 August 2009 - I personally see 15 August 2009, but you might not. If every date be wrapped in that template, editors could use any format they liked and users would see whatever format they liked. --Redrose64 (talk) 21:29, 15 August 2009 (UTC)

Currently the template doesn't work like that (i.e. it doesn't autoformat the date). Furthermore it uses {{#time:}} and so is limited to what the parser function can handle (e.g. it won't go beyond 100 AD). We'd be relying on having every date wrapped in it, which is a big ask. It would be a whole lot of work for the benifit of a few, i.e. those logged in users with prefs set. And, worst of all, we'd be ignoring the inherent problems of autoformatting, e.g. "a 15 August 2009 decision" autoformats to "a August 15, 2009 decision" (if your prefs are set to muddled) which is grammatically incorrect. JIMp _talk·cont 22:08, 15 August 2009 (UTC)

Besides, except for one brief mention ("{{convert}} can be used"...) there is no mention of that template either, and it is neither recommended nor deprecated, just says it can be used. I presume it is the intention not to link MoS guidelines to specific templates: if I wrote another set of conversion templates to "compete" with {{convert}}, that also met MOSNUM, they would be equally valid to use; as is doing the conversions longhand. SimonTrew (talk) 14:41, 16 August 2009 (UTC)

Is this consistent?

It says "5 kg (11 lb) bag of carrots", but it also says "(When they form a compound adjective, values and spelled out units should be separated by a hyphen.)" Which is right? Art LaPella (talk) 22:04, 16 August 2009 (UTC)

"kg" and "lb" are not "spelled out" units; "kilogram" and "pound" are. --   A. di M. 22:42, 16 August 2009 (UTC)

See WP:HYPHEN. JIMp _talk·cont 22:48, 16 August 2009 (UTC)

Hyphenation is more frequent in British than American English; the advice in question is misguided anglicization. In the sentence quoted, even the British might not hyphenate, since the grouping is made clear by the parentheses. So the sentence is right. Septentrionalis PMAnderson 05:45, 18 August 2009 (UTC)

Automatic currency converter button idea

Wondering if someone's smart enough to write a template to do automatic currency conversions? I'd love to be able to put in something from which Misplaced Pages readers automatically choose what currencies they want the data in. Suppose NZ GDP is $42,052 (NZ$). And I put this in an article. Is there some way a user could click on a button next to the amount to switch the currency? Like, click, and it's $28K USD. Or, click, it's $42K NZD. Or, click some other currency? It would be really cool to have. Simpler variant: assume no inflation and its easier but less accurate. A simple template that translates NZ$ to US$ or vice versa based on today's exchange rate, and ignores inflation considerations or the passage of time. Complex variant: Suppose a fact about money was added on date X. But today it's date Y. So, information needed would be: money amount in NZ$ on date X; conversion rate NZ$ to US$ on date X; inflation (or deflation) of US currency between date X and date Y; lastly, date Y. Boom -- up-to-date accurate amount information. No way Encyclopedia Brittanica could ever do that. That would be really cool! As far as I can tell, Village Pump doesn't have any converter tools for inflation or currency conversions. Tomwsulcer (talk) 01:03, 17 August 2009 (UTC)tomwsulcer

There are good reasons why not. It depends so much on whether you are quoting an historical price at its historical value or current value: and, if at its current value, how you adjust for inflation (which inflationary index you use, e.g. retail price index, consumer price index, inflation based on the rise in cost of houses or mars bars or bread or any particular item); second, that since most currencies are on floating exchange rates the article will constantly change every time it is accessed, or, in the alternate, will need to state when and where the rate was taken from; third, that it would require use of a currency conversion site, and (assuming permission was granted to do that on a grand scale) which to choose?; fourth, that many currencies are not widely traded and so, for example, to convert danish krone into kenyan shillings is almost entirely meaningless; fifth, that even freely traded currencies such as US dollars have a variety of exchange rates: the spot rate given for today is not what you will get at a bureau de change, so which do you choose?

It is best to have the editor make those decisions, adding references to where the conversion came from if necessary, rather than make WP do it. In general prices are quoted ether in US dollars or in the prevailing currency of the article's subject (e.g. the local currency or historical currency). If a reader really wants a currency conversion not provided, they can look up a conversion site themselves, surely; and if they can't find it, then an automated tool is not likely to either. SimonTrew (talk) 14:45, 17 August 2009 (UTC)

I agree there can be problems with a currency converter template, particularly as time span lengthens from date of entry to date of readership. A time span of twenty to fifty years can seriously begin distorting values as you say, and any calculator would be problematic. But I still think a currency converter toggle switch, next to money figures, is a good idea, particularly for relatively-recent information (ie time between info added and info read), to convert currencies. Then inflation is miniscule. I see it primarily as an aid to readers. Some readers think in terms of US$ or a commonly used currency like the Euro; others will think in terms of their native currency. Why not permit readers the option to choose which figure they'd prefer? (And I don't think anybody would seriously want to convert a rarely-traded currency with another rarely-traded currency -- I doubt readers would expect Misplaced Pages to even try that). Stick to a pure currency converter (forget inflation). For example, in the article on New Zealand, there are many references to dollar amounts -- sometimes US$, sometimes NZ$ (technically, the policy is to use native currency like you say, but I bet many New Zealanders think in terms of US dollars, and foreigners won't know which is being referred to -- since NZ calls their money "dollars" too). I think there is consensus about particular exchange rates -- there's some variation, but not much. For example, $1 New Zealand dollar is worth about $.67 US dollars, and there are different rates today which vary only slightly from that amount, and I don't think such variation is a good excuse to ditch a good idea. At first, when I read the New Zealand article, I thought the figure $28,000 average GDP of New Zealanders was in New Zealand dollars -- it happened to be in US dollars so it threw me off -- the actual GDP figure is closer to $42,000 NZD, or about $28K US (numbers slightly off here -- I'm working from memory). But I'm saying that a simple toggle button next to money amounts, letting a reader a choice to switch from a native currency to a commonly traded currency (USD, Euros, pounds, yen perhaps) would be a (1) helpful (2) more accurate than letting readers mentally guess the exchange rate (3) easy to program (4) a nice extra which differentiates Misplaced Pages from book-bound static encyclopedias which has (5) numerous applications.Tomwsulcer (talk) 04:16, 18 August 2009 (UTC)tomwsulcer

Querying "nineteenth-century painting"

The guideline for naming centuries (here and at WP:MOS) has been hotly contested, and I do not think we are ready to go back to that topic yet. But I am interested in just one provision:

Centuries are named in figures: (the 5th century CE; 19th-century painting); when the adjective is hyphenated, consider nineteenth-century painting, but not when contrasted with painting in the 20th century.

I would like to change the provision to this, to remove what I regard as an unsourced and probably unprecedented invitation to inconsistency:

Centuries are named in figures: the 5th century CE; 19th-century painting.

Can anyone cite a reputable guide that allows for nineteenth-century painting even in the same text (let alone contrasted with) as painting in the 20th century? If no one does, I will proceed with the change. (Even if someone does, I would invoke more major guides that do not support such an inconsistency.)

–_⊥Noetica!– 06:19, 18 August 2009 (UTC)