Wikipedia talk:Manual of Style/Dates and numbers

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Shortcuts:
WikiProject Manual of Style
WikiProject icon This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.
 

Nbsp only before symbols? (Eg, not for before byte?)[edit]

"Except as shown in the "Specific units" table below, a space appears between a numeric value and a unit name or symbol. In the case of unit symbols, <!--<<restriction of nobreak markup to symbols, not full unit names, seems to be implied by earlier text in this guideline--> &nbsp;". Just to be clear, MB for megabyte would be a symbol but megabyte isn't and should not be prefixed with nbsp? I can't see logic in that and was that just assumed? And if this is really the intention of the MOS, then it doesn't follow it here itself: "100,000,000,000&nbsp;byte) hard drive". [See also: "21{{nbsp}}million 21{{nbsp}}million".] Jeh reverted [my change to a page]. I will fix it if this is really the intention, but I took a long time the first time around and I would rather not spend more time on it if I was right all along. comp.arch (talk) 14:47, 30 May 2014 (UTC)

In the case of a long number followed by a long unit name, the total length of the text can get rather long and may have to be broken by the software in spite of the nbsp. If the nbsp is added, it might break in a place that is even worse than between the number and the unit name. If the software doesn't force a break, the large amount of white space at the end of the preceding line may be unsightly. Jc3s5h (talk) 15:00, 30 May 2014 (UTC)
Also, "100,000,000,000 byte) hard drive" should use a hyphen, not either sort of space, as it's a pair of words forming an adjective. This is spelled out elsewhere on this page. I think some fixes need to be made to the examples here. Jeh (talk) 17:40, 30 May 2014 (UTC)
btw, comp.arch: I didn't simply revert your change. I took rather a long time on it, finding every use of nbsp and correcting, or not. (There may yet be some uses of number-space-symbol that should be changed to nbsp, but I expect that in your zeal you got all of those.) I also fixed up the uses of "gaps" that included the full unit name in the parameters, changed spaces to hyphens where the use was an adjective, etc. So I don't think there's much left in that area for you to "fix." Jeh (talk) 22:11, 30 May 2014 (UTC)
"21{{nbsp}}million 21{{nbsp}}million" is not an exception because there is no unit there, symbol or spelled out; "21" and "million" are both part of the number, and we would not want a line break between them any more than we'd want one after any of the commas in "21,000,000". Jeh (talk) 22:27, 30 May 2014 (UTC)
{{convert}} has some detailed rules on this. See Help:Convert#Wrapping_and_line_breaking. -DePiep (talk) 07:23, 7 June 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Not commenting on any of the above specifically, but I want to say that there are many places where nbsp and such issues aren't addressed, though they should be. Absence of a statement re nbsp really means nothing. EEng (talk) 20:01, 8 June 2014 (UTC)

I have always understood that use of non-breaking spaces is to avoid the possibility of a line breaking at that point. We use a non-breaking space to avoid a line starting with a unit symbol since such symbols may be less easy to interpret when separated from their numerical value. For example a line commencing
  • l in size ...
is less intelligible than a line commencing:
  • litres in size ...
even if the preceding line ends with a number like "5". It makes sense then to put &nbsp; between "5" and "l", but doesn't provide a reason for having one between "5" and "litres". Non-breaking spaces, like other html entities, clog up the wikitext and attempting to over-control page rendering causes problems for display when rendered in browsers operating in narrow windows. I've seen an extension of the over-use of non-breaking spaces leading to nonsense like "twelve&nbsp;men, just and true". I'm certain that Wikipedia:Manual_of_Style#Controlling_line_breaks agrees with my interpretation.
I suggest that we should not only make it explicitly clear that non-breaking spaces are not needed between numerals and full unit names, but also correct those examples in Wikipedia:Manual of Style/Dates and numbers #Unit names and symbols that contain misleading markup like "25&nbsp;kilometres". --RexxS (talk) 19:01, 22 June 2014 (UTC)
Whether to use nbsp or nobreak or thinsp or zwsp or any number of other layout adjustments, beyond the places where MOS suggests they ought to be used, is a choice that depends on all kinds of specifics of the situation; attempts to apply rigid logic are pointless, because typesetting and layout are about how something looks overall. You apparently want to forbid any use not explicitly allowed, but MOS should not prescribe (or proscribe) such things unless there's a repetitive problem wasting editor time over and over in local debates. Your example
"twelve&nbsp;men, just and true"
is not nonsense if there's a good reason for it in context.

And MOS#Controlling_line_breaks does not agree with you: it mentions several places where linebreaks should be controlled, and nothing about where they shouldn't be controlled. See WP:CREEP. EEng (talk) 01:18, 2 July 2014 (UTC)

By that logic we might as well not have a MOS because anybody can claim exemption from what we usually do because their particular situation is a special case - "a choice that depends on all kinds of specifics of the situation". On the contrary, MOS is a guideline that documents what is normal practice. You seem to think that the purpose of MOS is to forbid things: it most emphatically is not. Policies and guidelines on Wikipedia are descriptive, not prescriptive and that's an important distinction. You only need to look at {{convert}} to see what is normal practice on Wikipedia: numerals and unit symbols are separated by a non-breaking space; numerals and unit names are separated by a normal space.
It is precisely because HTML is a markup language, not a layout language that we try to allow as much flexibility as we can for the browser to control layout, and that is why we keep the use of non-breaking spaces to a minimum. In infoboxes and anywhere where space is limited, it may be desirable to exercise tighter control of line-breaks, but in running prose there is never any need to have nonsense like "twelve&nbsp;men, just and true" and I see that you've conveniently avoided giving any examples of where it is could possibly be sensible markup.
You're plain wrong about Wikipedia:Manual of Style #Controlling line breaks. The examples given accord exactly with normal practice, i.e. numerals and unit symbols are separated by a non-breaking space; numerals and unit names are separated by a normal space - with exceptions only where space is limited such as in infoboxes.
Finally, CREEP is a useful essay and contains this valuable advice: "WP:CREEP" is not a substitute for actual arguments. Lengthy instruction can be appropriate if it represents a broad consensus and does more good than harm. I commend it to you. --RexxS (talk) 18:36, 2 July 2014 (UTC)
  • No, I'm right about MOS#Controlling line breaks. It lists a number of places nbsp should be used, but says nothing about not using it elsewhere. And that's what I said it says.
  • You're right I didn't give an example of a sensible use of "twelve&nbsp;men, just and true" -- I said there certainly are some. And then you supplied one -- an infobox or caption. Thanks.
  • Your talk of a layout versus markup language is just something you made up. Browsers do a very good layout job when left to themselves, but sometimes we step in to tweak. You want to forbid that.
  • The lesson of CREEP is that if we don't need a rule, we need to not have a rule. I'm not hearing any need for a rule.
I'd like hear what other editors thing. EEng (talk) 18:51, 2 July 2014 (UTC)
No, you're wrong about MOS#Controlling line breaks. You say "And MOS#Controlling_line_breaks does not agree with you" Yet anybody who reads it can see that's untrue: there's not one example of a numeral followed by a unit name that is separated by a non-breaking space. That's the sort of consistency with common practice that I've suggested the examples on this page should achieve.
No infobox or caption should contain "twelve&nbsp;men, just and true" - how would you justify that?
If you don't understand the difference between markup language such as html and a layout language such as PostScript, then you shouldn't be pontificating about "sometimes we step in to tweak" when you've demonstrated no understanding of when it's appropriate or desirable to attempt to control web page layout. Yes, browsers do a very good job of matching page layout to window size and that's exactly why we normally don't attempt to override the usual browser behaviour. Avoiding an orphaned unit symbol is one of those rare exceptions; an orphaned unit name is not.
Again, you're confused by thinking the MOS is prescriptive. When we document a common practice in a guideline, we expect there to be exceptions. See WP:PG. You would benefit from gaining some understanding about the purpose of guidelines on Wikipedia. The MOS, like any other Wikipedia guideline, is not a collection of rules, but exists as a repository of guidance on how the community normally does things. --RexxS (talk) 23:44, 2 July 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

  • If you don't think MOS is prescriptive, then you don't know the meaning of prescriptive.
  • My point about MOS#Controlling is that it doesn't say you shouldn't use nbsp in cases other than the ones it exemplifies. It therefore doesn't support your idea that, well, you shouldn't use nbsp in cases other than the ones it exemplifies.
  • A good example of an unusual situation where nbsp might be used (which arose in an actual article) is
first edition of Poems written by Wil. Shakespeare.
which might easily confuse the reader momentarily if rendered as
first edition of Poems written by Wil.
Shakespeare.
It's therefore reasonable to code this as
first edition of ''Poems written by Wil.{{nbsp}}Shakespeare.''
  • I agree that usually there's no need for nbsp between a quantity and a spelled-out unit name. I just don't think we need a rule on this, because I don't see a pattern of overuse, or a problem caused by such a pattern. Can you point to such?

I'm still hoping other editors will opine, assuming they can figure out what we're talking about. EEng (talk) 04:40, 5 July 2014 (UTC)

STRONGNAT questions for biographies[edit]

It seems that STRONGNAT has not considered biographies for its explanation and examples, so questions should be answered to gain some consensus that can be used for bios.

  • Are the person's ties to non-English countries relevant for STRONGNAT?
  • Does STRONGNAT really mean "stronger ties," when a person had strong ties to more than one English-language country?
  • Should citizenship be a major or minor factor for STRONGNAT?
  • Should their career notability and place where they became most notable be a major or minor factor for STRONGNAT?

In general, for biographies, what are the key details that should be used? --Light show (talk) 21:52, 30 May 2014 (UTC)

WP:STRONGNAT and MOS:TIES are for selecting which variety of English to use. Ties to non-English countries are therefore irrelevant. For any remaining ties to multiple countries with different varieties you will have to make a judgement call about which one dominated that person's life. E.g if they were born in England but migrated to the US when they were 2 years old then US English would be used. But if they were born in England, did lots of notable work in England and then migrated to the US when they were 69 years old, then UK English would be better. There will probably be cases where it is hard to choose - in which case toss a coin and stick to it. WP:RETAIN says that once a variety has been chosen then we should stick to it unless there is consensus to change. STRONGNAT would have to overwhelming (ie not a 50/50 case) to override RETAIN.  Stepho  talk  23:52, 30 May 2014 (UTC)
Can that explanation be added to the MOS, since there are countless examples of people who have clearly stronger ties to one English country than another? It might help avoid disputes such as for Einstein's DRN. --Light show (talk) 01:35, 31 May 2014 (UTC)
We could add to the MOS, "Articles on topics with strong ties to a particular English-speaking country should generally use the more common date format for that nation. For biographies, citizenship to an English speaking country denotes a strong national tie, over citizenship to a non English speaking country."--JOJ Hutton 17:04, 31 May 2014 (UTC)
WP:STRONGNAT is a section of MOS:NUM (this subpage). It concerns date format, not variety of English.
WP:TIES or MOS:TIES is a section of WP:MOS (parent of this page). It concerns varieties of English, not date format. --P64 (talk) 17:20, 31 May 2014 (UTC)

If I were to write an article about someone notable who was born in, active in the government of, and died in, the Belgian Congo (now the Democratic Republic of the Congo, a former Belgian colony, in which English is a second or third language at best), which guideline tells me which variety of English and which date format to use? To anyone that has spent time there, the correct result is obviously en-GB (really en-BE, if we had such a thing) and DMY, but how do we get there, hampered by the seemingly-incorrect modifier "English-speaking" at WP:STRONGNAT? The guideline makes sense without this modifier (with a couple of minor exceptions). (also being questioned at Talk:Albert Einstein) —[AlanM1(talk)]— 06:47, 12 June 2014 (UTC)
Followup:Same scenario, except give the person a tie to an "English-speaking country" by making his mother a U.S. citizen living in the Belgian Congo. Now we have a tie that STRONGNAT would seem to want to use to force MDY, regardless of how wrong it would be for everything related to the article. —[AlanM1(talk)]— 08:20, 16 June 2014 (UTC)
I appreciate that people are tired of this subject, but I honestly do not see an answer to the question I posed above – I'm not trolling for a war. —[AlanM1(talk)]— 03:15, 21 June 2014 (UTC)
You seem to have a very broad interpretation of "English Speaking Country". One that has never been accepted in any discussion that I am aware of.JOJ Hutton 18:40, 2 July 2014 (UTC)
I'm going to amend the section and see how it looks.--JOJ Hutton 17:48, 11 July 2014 (UTC)
You failed to get your way at Albert Einstein ([1]), and now you come here to make a change to a guideline that wasn't applicaple in order to force it to be applicable. Sounds like a bad idea. - DVdm (talk) 17:58, 11 July 2014 (UTC)
Let's see -- what is it they say Einstein said? "If relativity turns out to be right, the Germans will say I'm a German, the Swiss will say I'm Swiss, and the French will say I'm a citizen of the world. If relativity turns out to be wrong, The French will say I'm Swiss, the Swiss will say I'm German, and the Germans will say I'm a Jew." EEng (talk) 18:10, 11 July 2014 (UTC)
Right. - DVdm (talk) 18:13, 11 July 2014 (UTC)
Its obvious that you want the article to continue to use DMY, despite a majority that went against you in the discussion. There just needs to be clarification in the MOS about when and when not to consider strong national tie. Thats all this discussion is addressing. An admin determined that the RFC was no consensus, but as it turns out, a previous ARBCOM, determined that in the case of a disputed date format, the format the article should revert back to the first date format used. In the case of Einstein, that is MDY. And an ARBCOM decision trumps a single admins opinion at a local discussion.--JOJ Hutton 18:08, 11 July 2014 (UTC)
Do have a look at wp:DEADHORSE. - DVdm (talk) 18:11, 11 July 2014 (UTC)
What is your justification for your revert. Despite the fact that this discussion has been open for a while and you decided to not participate until now? You are still in the minority on this issue.--JOJ Hutton 18:14, 11 July 2014 (UTC)
Read the replies. Lack of consensus to make that change. See wp:NOCONSENSUS, a policy. - DVdm (talk) 18:19, 11 July 2014 (UTC)
WP:NOTVOTE. EEng (talk) 22:09, 11 July 2014 (UTC)
But what is YOUR justification? What is wrong with making it clear that the English Wikipedia should use the date format of the English speaking countries? Why do you feel that the MOS should not make that more clear and precise?--JOJ Hutton 18:22, 11 July 2014 (UTC)
In short, read the replies, both here and at the RFC. - DVdm (talk) 18:36, 11 July 2014 (UTC)
I want to hear YOUR reply about why this MOS should not make it more precise and remove the confusion. I've read your opinion on "current wording" of this MOS, but so far you have yet to give your opinion on why the MOS should not be amended so as to remove the ambiguity and create a more precisely worded guideline.--JOJ Hutton 18:52, 11 July 2014 (UTC)
WP:CREEP. EEng (talk) 22:09, 11 July 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────The change by Jojhutton is not in accord with the guideline, because it said " strong national tie to an English speaking country takes precedent over non English speaking countries." But it isn't about taking precedent, for purposes of date format, a tie to a non-English speaking country doesn't count at all. Jc3s5h (talk) 18:54, 11 July 2014 (UTC)

Yes, I did struggle a bit over the wording, especially the word "precedent". But I believe that the point was that on the English Wikipedia, we should use the date format of the English speaking country that the subject has strong national ties to, over non English speaking countries. Why this isn't clear to some people, I don't know. We need to make it more clear.--JOJ Hutton 19:00, 11 July 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I've let this rattle around in the back of my head and I think I have a solution. The real issue is whether the date format matches one of the common formats used in predominantly English speaking countries and whether it uses one of the calenders used in those countries. This rules out things like ISO 8601 order (common in Asian countries), Japanese calendars (based on the reign on the current emperor), etc. In practice, it limits it to the Gregorian calendar expressed as 12 July 2014 or July 12, 2014. Minor formatting issues of whether it uses periods, commas, spaces, dashes, slashes, etc can be ignored to fit one of those two acceptable formats. For a concrete example, Germany traditionally used d.m.yyyy and this is an easy match to 12 July 2014. So I propose that we change MOS to state that strong national ties to a country that uses a date format closely matching one of 'd mmmm yyyy' or 'mmm dd, yyyy' shall be preferred. In the case of Einstein above, he realistically has two countries to be associated with: Germany using 'd mmm yyyy' and the US using 'mmm d, yyyy'. There might still be an issue over which country has has stronger ties to (his native Germany or the adopted US) but either format is otherwise acceptable and neither would be ruled out. For other people emigrating from say Japan to the US, the Japanese format would be ruled out and the US format would be used. Comments?  Stepho  talk  02:52, 12 July 2014 (UTC)

The reason for using a date format popular in, for example, the United Kingdom, when writing about a person with strong ties to that country is that we anticipate that more people from the United Kingdom will be reading the article than people from other countries. In the case of an article about a German, we would expect most Germans would read German-language articles about the person, not the English Wikipedia article. There is no way to guess what variety of English the readers of the article about the German will be most comfortable with, so there is no reason to prefer one date format over another. Jc3s5h (talk) 03:24, 12 July 2014 (UTC)

No. 10 Downing Street and so on[edit]

Right now we've got

Proper names, technical terms, and the like are never altered: 5 Channel Street;   Channel 5;  Chanel No. 5;  Fourth Judicial District;   Fourth Amendment;   Fourth Estate;   Fourth Republic

-- and that's fine. But what about certain conventional situations that aren't proper names e.g.

Along the south side of X street are No. 123, where Historical Personage died, and No. 137, where Infamous Killer lured his victims.

-- ? In English usage, at least, reference to Number. 123 or No. 123 are conventional -- do we require the text to say Number 123 every time, or is No. 123 OK here?

In older American usage you see that some time, but nowadays (it is my impression) it's more common to write "at 123 was This, and at nearby 137 was That."

Anyway... thoughts on writing "No. 123"? EEng (talk) 10:13, 29 June 2014 (UTC) Bump EEng (talk) 04:08, 5 July 2014 (UTC)

What's happened to all the MOS warriors?[edit]

has the fire gone out? Can't I get a peep re the above? EEng (talk) 18:11, 11 July 2014 (UTC)

I don't know if this will be much help, but as a Briton, I can tell you what I do myself. I personally use the numero sign, as in № 10 Downing Street. I do speak the "number" allowed. I personally would advocate for using the numero sign, as opposed to "number", which is never written out as far as I know. However, I wouldn't be surprised if the American usage of "123 Such and Such Road" started seeping in, and I've certainly heard "10 Downing Street" being used occasionally on BBC News reports in recent years, whereas they would've previously said "№ 10". RGloucester 22:16, 11 July 2014 (UTC)
If "No." is the common usage, I'd say keep it unaltered. For a Canadian example (though not related to a street), Leduc No. 1. Resolute 22:48, 11 July 2014 (UTC)
  • If it's the world according to MOS you seek, your answer is here: MOS:NUMBERSIGN. Oddly, it's not found or referenced on the "Manual of Style/Dates and Numbers," but on the first page of "Wikipedia:Manual of Style." I edit a lot of sports articles and the number abbreviation rules come up a lot as many sports fans want to insert the number sign symbol (#) directly into text, which is a no-no. I had to go looking for the specific MOS section, and was a little surprised to find it elsewhere than on the MOS numbers subpage. Cheers. Dirtlawyer1 (talk) 23:45, 11 July 2014 (UTC)
I was aware of NUMBERSIGN though I couldn't remember where it was. Leduc No. 1 is covered under the proper names rule. I guess what I was wondering was whether the flat prohibition on No. might be relaxed in this situation where convention strongly endorses it i.e. "house numbers", such as in the examples above, for times and places where that was the convention. The weird thing is I had an actual article situation when I posed the question, but I can't even remember what it is now! I don't know... I do think this usage should be allowed. Anyone want to propose text? EEng (talk) 02:55, 23 July 2014 (UTC)

WP:DATED[edit]

...gives the example "Humans diverged from apes long ago, but only recently developed fire." One plausible theory is that cooking developed first, then homo erectus and eventually humans. See Catching Fire: How Cooking Made Us Human. There must be a better analogy. Aymatth2 (talk) 01:36, 19 July 2014 (UTC)

I changed the example to Humans diverged from apes long ago, but only recently developed state legislatures. EEng (talk) 04:18, 19 July 2014 (UTC)
Good one. Aymatth2 (talk) 11:19, 19 July 2014 (UTC)
Southern Chivalry.jpg
Yes, though there's evidence that legislatures developed first, before man split from apes. EEng (talk) 14:17, 19 July 2014 (UTC)
We didn't split from apes. We are apes. We split from chimp/bonobos. Jimp 03:36, 24 July 2014 (UTC)
OK, smartypants. Please fix the example. ("Diverged from other apes"?) EEng (talk) 04:14, 24 July 2014 (UTC)

Fractions vs decimals in imperial units[edit]

Many moons ago I wrote articles converting cm to inches with fractions - such as in Banksia ericifolia - and felt more comfortable doing this. Somewhere along the way I passively and not unhappily went along with using decimals of inches, such as in current FAC Epacris impressa. Someone else has stated they prefer the fractions. I can't see anything in MOS or MOS archives about this...has this been discussed before and do we have a consensus? Cas Liber (talk · contribs) 08:44, 23 July 2014 (UTC)

The "moons" is not a MOS-conpliant chronological unit, so you'll need to repost before we can start arguing about this.
For years, a strict reading of MOSNUM did not allow any standard time measurement longer than a day, so think yourself lucky. Kahastok talk 21:55, 23 July 2014 (UTC)
I don't have information on that, but have some observations. Banksia ericifolia has:
9–20 mm (⅓–¾ in)
MOS:FRAC says to use {{frac}}:
9–20 mm (1334 in)
Ideally {{convert}} should be used so future editors don't have to wonder if the conversions are correct or have been changed. However, convert can only handle one value of fraction in the output, although it will reduce the fraction if appropriate:
  • {{convert|9-20|mm|abbr=on}} → 9–20 mm (0.35–0.79 in) (this line is to show the values)
  • {{convert|9-20|mm|abbr=on|frac=4}} → 9–20 mm (1434 in)
  • {{convert|9-20|mm|abbr=on|frac=8}} → 9–20 mm (3834 in)
A problem with fractions is that they are pretty crude as far as conveying information regarding precision, although for this context precision is not appropriate. I find going from 13 to 34 to require too much mental effort—it's hard to compare the values. Johnuniq (talk) 11:01, 23 July 2014 (UTC)
Defending the fractional way of life against creeping decimalization
The benefit of fractions with imperial units is that the units themselves are not decimally-based, so the subdivisions are very often give awkward decimals. 4.1 feet is not a nice number of inches. 5.2 pounds is not a convenient number of ounces. But in those situations the best solution is to use the subdivision explicitly (e.g. 4 ft 2 in).
As to divisions of units like inches, ounces, that don't have a standard subdivisions, fractions are probably more traditional and decimals may look wrong to some - but may be clearer to others. Personally, I don't have a strong preference either way. Kahastok talk 21:55, 23 July 2014 (UTC)
  • If you read WP:UNIT, you'll see that mixed units are preferred for the imperial system. Fractions should be used, as the system is not a decimal system. Mixed units, like "5ft 2in", should be preferred. In instances where there is no commonly used smaller unit, like with the ounce, use fractions. Imperial units don't make sense, frankly, when put into decimals. That's not how they were meant to be used. RGloucester 22:00, 23 July 2014 (UTC)
  • I'm not sure about all cases of this question, but if the inches (as in the example) are a parenthetical conversion from a measurement given in the source in decimal (obviously) millimeters, then I think the inches should be in decimal as well. I certainly see decimal inches in some engineering contexts (though sometimes they're obviously modernizations of fractions, as e.g. a 1.125-inch bolt) and for the scientific context of the OP that seems right too. But I don't have this clearly thought out. EEng (talk) 22:13, 23 July 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Are we using : or * for each comment? It started out as colons.

Some readers like imperial measurements and these readers nearly always think fractions are quite natural. Other readers prefer metric measurements and these readers nearly always prefer decimals. I don't come across many people who like imperial measurements with decimals and I don't come across many people who like metric measurements with fractions. Also, when we use a measurement on WP we should make it agree with the source reference. Some fractions like 9 1/2 can easily be converted to a decimal like 9.5 but some like 9 1/3 either lose precision by converting to a shortened decimal like 9.3 or gain unwarranted precision as 9.3333333333333 (typically measured with a tool that is accurate to only a few decimal places). Luckily we {{convert}} which is happy to deal with imperial fractions and decimal metric units. Readers who have trouble with imperial fractions can just ignore them and look at the decimal metric units. Similarly, readers who never quite made the transition to metric can ignore the metric units and just read the familiar imperial fractions. Both sides are happy and can ignore the other side.  Stepho  talk  01:55, 24 July 2014 (UTC)

Peaceful coexistence is for pussies. There should be a fight to submission, so that one approach becomes the glorified master and the other the despised slave. EEng (talk) 02:59, 24 July 2014 (UTC) P.S. I've been spending time at Did You Know, where for some reason they all use * on everything. I'm afraid I've become infected.