Jump to content

Template talk:Convert/Archive October 2011

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Please change default double output to default single output: "1 carat (0.20 g; 3.1 gr)" to "1 carat (0.20 g)"

The default output for carats is:

  • "1 carat (0.20 g; 3.1 gr)"

please can we change it to

  • "1 carat (0.20 g)"

Regards Lightmouse (talk) 09:41, 28 July 2011 (UTC)

Why? ― A. di M.​plé​dréachtaí 12:02, 31 July 2011 (UTC)

Consider the following:

The grain value is only necessary if Americans understand neither the carat nor the gram values. Is it normal in America to say "a 160 grain sapphire ring"? Lightmouse (talk) 12:29, 31 July 2011 (UTC)

Any more comments? Lightmouse (talk) 16:35, 20 August 2011 (UTC)
I can't speak for Americans, but I don't see any reason to change the default here. I'm presuming the reason we default to two units is that none of the three unit is universally more commonly understood than the others. If for stylistic or other reasons two conversions are not appropriate in some circumstances then the default can be overridden for those pages without reducing the informativeness elsewhere. Thryduulf (talk) 21:44, 20 August 2011 (UTC)


i vote for removing the grain amount, and only showing gram. my reasoning is that people who use traditional units (carats, grains), use one unit for one purpose. they won't want to know a gem in grains, they want to know it in carats. one-unit-for-everything is the SI philosophy.Bewareircd (talk) 08:18, 29 August 2011 (UTC)

The default-default is one output only. Each case of non_default-default needs a strong case. Some, like this one, are just legacy that hasn't been challenged lately. This should be reset to the default single output unless anyone claims formats like "a large 52 carat (10 g) sapphire ring" need the value in grains. Lightmouse (talk) 13:07, 21 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

The default should be "a large 52 carat (10 g) sapphire ring". As far as I know, the grain value adds no value in that phrase. Can we make the change please? Lightmouse (talk) 11:54, 2 October 2011 (UTC)
Done. JIMp talk·cont 04:47, 3 October 2011 (UTC)

Thank you. Lightmouse (talk) 07:45, 3 October 2011 (UTC)

Please change US pint default output to suit majority need

  • 8 US pints (3.8 L; 6.7 imp pt)

The US pint is converted by default to ml and imp fl oz. The majority need for US pint conversion doesn't include imp fl oz. It may also be that litre is better than ml, but that's another issue. We have (or should have) a higher standard for multiple output defaults. In the few cases where the imp fl oz is needed, it can be specified. Please can the default be updated? Lightmouse (talk) 11:44, 31 July 2011 (UTC)

It should convert to litres and imperial pints, for consistency with the imperial pint which converts to litres and US pints (13 imperial pints (7 L)): in the situations where an American uses small pints, a Briton uses large pints and a continental European uses litres. ― A. di M. plé dréachtaí 12:01, 31 July 2011 (UTC)

You say there's 1:1 usage between Americans and British pints but the ratio is a *lot* more imbalanced. The pint commonplace in the US but legacy in the UK except for one notable exception: draught beer (bottles and cans are ml). The litre is the default unit in the UK. There's no need for Wikipedia to turn back the clock to the days of Empire and the colonies. Lightmouse (talk) 12:41, 31 July 2011 (UTC)

Don't they use (milli)litres and/or fluid ounces for bottles and cans in the US, too? Also, that “one notable exception” makes up for a sizeable fraction (if not the majority) of all the times I've ever used any unit of volume when speaking English. ― A. di M. plé dréachtaí 12:46, 31 July 2011 (UTC)

Yes, Americans use fluid ounces but it's the US one, not the old British Empire version. Yes, the pint of draught beer is a *notable* exception and your experience fits with that. It's great that the template permits multiple outputs by choice. But Wikipedia articles aren't dominated by beer usage. they add clutter and are only *default* as exceptions. In this case, we should reset it back to the normal convention of only a single default output. Lightmouse (talk) 13:20, 31 July 2011 (UTC)

My point is that even in American articles pints are much more likely to be beer or milk than petrol or Sprite (the latter would likely use gallons and litres/ounces respectively, instead), so converting to imperial pints seems reasonable to me. (Also, the difference between a US fluid ounce and an imperial one is quite small, so I wouldn't normally worry about that: if they are rounded to two sigfigs you can't even always see the difference (12 US fluid ounces (12 imp fl oz)) and more precise measurements than that are likely to come from technical contexts where it's unlikely they'd use ounces in the first place). ― A. di M. plé dréachtaí 14:34, 31 July 2011 (UTC)

As far as I can detect, the 'USpt' or 'U.S.pt' template option is only used as input in:

Article Default chosen? What was done Default imp fl oz output appropriate? imp pt output appropriate? L or ml only output appropriate?
Energy star No Chose to output in litres only No No Yes
Hypovolemia No. Chose to output in litres only No No Yes
Ink cartridge Yes No No Yes
Milk Yes No No Yes

In all cases here, the litre-only output was either chosen or would have been appropriate. It may only be four instances for this unit but it's an indication that other multi-output *defaults* are excessive. Lightmouse (talk) 11:38, 1 August 2011 (UTC)

How is the imperial pint inappropriate in Milk? According to *that same article*, in the UK “[m]ost stores stock imperial sizes: ... or a combination including both metric and imperial sizes. Glass milk bottles ... are typically pint-sized...” As for hypovolemia, I did heard about pints of blood in Ireland once (though I admit that a sample size of 1 is insufficient). (I have no idea of how dehumidifiers are rated in the UK and I didn't even know they sold printer ink in bulk, so I won't comment on the other two.) ― A. di M. plé dréachtaí 13:12, 1 August 2011 (UTC)

Let's look at each conversions within the article:

  • In the Milk article it has a section about *America* that says:
    • The .5 US pints (0.24 L; 0.42 imp pt) milk carton is the traditional unit as a component of school lunches, though some companies have replaced that unit size with a plastic bottle, which is also available at retail in 6 and 12-pack size.
    • It's describing an American carton of 0.5 US pint. The ml conversion as required by UK law is appropriate for British readers. The "8.3 imp fl oz" is weird and "0.42 imp pints" wouldn't be an improvement.
  • In the hypovolemia, the editor chose to convert US pints into litres. I would have done the same. British and Irish medicine uses litres to measure blood. Any mention of 'pints' is colloquial and just means an amount that could range from 400 to 600 ml. In any case, we're straying from the point - real conversions from US pints only need ml or litres.

I hope that helps Lightmouse (talk) 14:09, 1 August 2011 (UTC)

The one in hypovolemia isn't about “medicine”, it's about a f***in' film, for heaven's sake. What would be wrong with using a “colloquial” unit there? I'm not sure the movie used US pints in the first place because that's what US medicine uses, either. (And the fact that UK law “requires” millilitres doesn't, by itself, mean that they're commonly used: for that matter, the EU requires energy values in kilojoules on food labels, but I don't think I've ever heard an European use kilojoules for that unless they were compelled to. ― A. di M. plé dréachtaí 15:14, 2 August 2011 (UTC)

The Hypovolemia article has a litre-only conversion. We don't know what you think it should say. Please can you show us? 15:46, 3 August 2011 (UTC)

Any response? We'd like to make progress. Lightmouse (talk) 15:24, 10 August 2011 (UTC)

Any response from anyone? Lightmouse (talk) 16:34, 20 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

This has been fully explored. Can we make the change please? Lightmouse (talk) 11:54, 2 October 2011 (UTC)
Done. JIMp talk·cont 04:48, 3 October 2011 (UTC)

Thank you. Lightmouse (talk) 07:45, 3 October 2011 (UTC)

US fluid ounce: default should be ml only

The current default for US fluid ounce is:

  • 1 US fluid ounce (30 ml)

I added the default template to "12 ounce beers" and received the following complaint:

  • "Changing 119 12-ounce beers in 6 hours to 119 12-US-fluid-ounce (350 ml; 12 imp fl oz) beers in 6 hours is not my idea of a sane conversion"

I agree. The ml value is sufficient, even in the UK. UK and US fluid ounce values are very close. They're identical in many instances, such as this. The reasoning is similar to that used for the change we've just made to US pints. We can increase support for 'sane conversion' and eliminate an anomalous double output by changing this. Lightmouse (talk) 08:24, 3 October 2011 (UTC)

  • The phrase "12-ounce" is part of the cultural language (as in "12 ounce curls"), and with beer being a liquid, I do not see the need to specify "12-US-fluid-ounce". So, the phrase "12-ounce beer" should be kept in that context. Similarly, the phrase "40-ounce malt liquor" should be kept, or "5-gallon gas can" likewise. Otherwise, there is a sense of excess precision, such as calling a "2-liter bottle" to be a "2.0-litre bottle" or "1.90–2.10-litre bottle" or whatever the precision of contents of such bottles. In cases of ambiguity, then prefix with "US" such as a "US 5-gallon gas can" or such. These cases are probably so rare that hand-coding of conversions would be fine. -Wikid77 (talk) 23:48, 3 October 2011 (UTC)

I have no real objection to defaulting to millilitres only. Pints were changed, it would make sense for fliud ounces to follow suit.

As for the example, as I mentioned last time I ran across this conversion, the real insanity here is converting the bottle size when what we're really interested in is the amount of beer drunk. The conversion really should have been something like "119 twelve-US-fluid-ounce bottles of beer (42 L) in 6 hours". We could include gallon conversions too to make it clearer to those of us who think in gallons: "119 twelve-US-fluid-ounce bottles of beer (42 L, 11 US gal or 9 imp gal) in 6 hours".

I do, though, see Wikid's point that it's undesirable to disturb the flow by adding the clarifiers "US" and/or "fluid". Context can make these unecessary, here, for example, we're talking about beer so it must be fluid ounces. If need be we could put the US in brackets ("119 twelve-ounce (US) bottles of beer (42 L) in 6 hours") or in a footnote. JIMp talk·cont 01:56, 4 October 2011 (UTC)

OK the example is a bit of a distraction. What's the next step in making the change to ml output only? Lightmouse (talk) 17:51, 4 October 2011 (UTC)

The next step is done. JIMp talk·cont 02:01, 6 October 2011 (UTC)

Thanks. Lightmouse (talk) 09:27, 6 October 2011 (UTC)

Degrees (angle/temperature)

{{convert|100|F|C}} generates "100 °F (38 °C)". As WP:MOS#Units of measurement (4th bullet from the end) states: "Units of degrees, minutes and seconds for angles and coordinates, and the percent sign, are unspaced.", please could it be changed to generate "100°F (38°C)"? --Stfg (talk) 17:58, 5 October 2011 (UTC)

This guideline applies to degrees of angle not temperature. Read it again "Units of degrees, minutes and seconds for angles and coordinates," (emphasis WP:MOS's but do note it well). For further detail see WP:MOSNUM#Unit symbols.
  • Values and unit symbols are separated by a non-breaking space. The {{nowrap}} template or the   character can be used for this purpose. For example, use 10 m or 29 kg, not 10m or 29kg.
    • Exceptions: Non-alphabetic symbols for degrees, minutes and seconds for angles and coordinates and the percent sign are unspaced (for example, 5° 24′ 21.12″ N for coordinates, 90° for an angle, 47% for a percentage, but 18 °C for a temperature). See also Manual of Style—Geographical Coordinates.
Note the "but 18 °C for a temperature". Thank you nonetheless for your concern. JIMp talk·cont 01:59, 6 October 2011 (UTC)
Thanks for taking the time, and apologies for my oversight. --Stfg (talk) 08:33, 6 October 2011 (UTC)

No worries. Perhaps we've uncovered a lack of clarity in the guidance. I wonder whether we should bring it up at WT:MOS. JIMp talk·cont 23:14, 6 October 2011 (UTC)

Possible validation of first number

Important: I think we need to validate the first number, despite the overhead, to reject a decimal comma, of the form "1,35" and require "1.35" because "1,35" is treated as "135" and quietly gives the wrong conversion:

• {{convert|1.35|m|ft}} → 1.35 metres (4.4 ft)
• {{convert|1,35|m|ft}} → 135 metres (443 ft) -- as of 7 Oct 2011

As you know, there are thousands of articles being translated from other languages where the "decimal point" is the comma, such as "4,73" meaning "4.73" and unfortunately, that gets accepted as 473 because, in recent years, we ran decomma by {FORMATNUM:|R} for readability of "20,000,000" (not 20000000). Note: these decimal commas had been rejected by Convert years ago, but then we used FORMATNUM and we did not create a "smart" {{Decomma}} to check for invalid use of commas. The overhead could be kept minimal by only validating input which contains commas:

  • {{#ifeq: z{{{1}}}|z{{FORMATNUM:{{{1}}}|R}}
         |<!--then no comma-->{{{1}}}
         |<!--else validate for commas-->{{Decomma|{{{1}}} }} }}

Then check for invalid-comma numbers, such as too short, when "55,6" or "1,35" (without commas) compares as less than 1000. That would even quickly reject "1,00.97" as invalid, rather than convert it as 100.97.

The validation by Template:Decomma would only be run on the first number, after a 2-depth-level check for commas. Due to all the interwiki translations, as well as many English-as-second-language editors, I think this might be a critical issue. In many German-based articles, the areas are given as 2-decimals, "xx,xx". The result for "1,35" (as 135) is off by a factor of 100x, not just a 5% error, but a 10,000% error in some articles. I try to focus on major issues of concern. There's no hurry on this, and we could create a temporary category (for Decomma) to log how often 1 or 2-place decimal commas are being used in Convert, to prove what size numbers are a common problem. -Wikid77 (talk) 10:34, 23 September, revised 12:55, 7 October 2011 (UTC)

I have the following comments:
  • It's a pity that we can't accept both the period and the comma as a decimal separator. Could we have an option?
  • It's common for Indians to express numbers as 1,00,000 because of they way their numbering system works. We need to be careful not to reject those as incorrect decimals.
Lightmouse (talk) 10:46, 23 September 2011 (UTC)
But how can you tell what 1.001 and 1,001 mean? Do they mean a number close to one or one thousand? Sadly, there is no way to tell in these cases and we must therefore default to the symbols used by native English speakers. Other languages Wikipedias should, of course, default to their own styles.  Stepho  talk  13:52, 23 September 2011 (UTC)
  • Limit within 4-digit numbers: If we restrict validation to comma-only numbers, I think we could also limit validation to at most 10,000, rejecting "xx,xx" or "xxx,x" or "x,xx" (etc.) by checking for "x," in 4-digit amounts or reject n < 1,000 as not valid with commas. So that would allow any large numbers, such as "1,00,000" to be valid. I favor rejecting only the troublesome amounts, and not accept "1,50" (as neither 1.50 nor 1500) but an invalid typo. Meanwhile, FORMATNUM in other-language Wikipedias removes dots "." and leaves the decimal-comma such as in "20.000.000,125". -Wikid77 14:23, 23 September 2011 (UTC)
This is a worthwhile idea. {{Decomma}} could place all those articles which have a number formatting problem into a special category. Editors could then go to these problem articles and fix them by hand. I'm afraid, Lightmouse, that I must respectfully disagree with what I read you as suggesting. We cannot and should not accept the comma as anything but a separator for positive integer powers of one thousand (when it comes to numbers, sentences are another story). "1,35" for 1+35⁄100 is not valid in English nor is "1,00,000". This is the English WP. We should be writing in English, not German, not French, not Hindi. JIMp talk·cont 00:22, 26 September 2011 (UTC)

This change is the first (that I'm aware of) that destroys international neutrality in the template. It's easy for the dominant cultural users to take international conveniences away in many small pieces, particularly if the programmers are in that culture. It's possible to require multiple regional interfaces but it's better if a universal high-quality interface has international scope.

I'm not convinced you're correct to say 1,00,000 isn't valid in English, although it may depend on your definition of 'valid'. I think that format is used in India, Bangladesh, Nepal, and Pakistan, some of those countries have English as an official language and it's not just used by Hindi speakers. I'm not sure about cause and effect but it's consistent with the use of crore and lakh. I'm not a big fan of crore and lakh or that format but I'm trying to make sure we don't add an inconvenience. I'm more concerned about resolving the decimal separator issue. Is the convert template really only used on en.wiki? Lightmouse (talk) 08:26, 26 September 2011 (UTC)

User:Jimp wrote "This is the English WP. We should be writing in English, not German, not French, not Hindi". Which variant of English should we be using? The variant used in the SI Brochure uses spaces as 1000's separators, not commas. South Africa, where English is an offical language, the mother tongue of a sizable minority and that country's lingua franca uses commas as a decimal separator. I think that we should take note of the conventions adopted by The Times of India regarding the use of the crore and the lakh in matters pertaining to the South Asian subcontinent - after all The Times of India is the world's largest English language newspaper. Martinvl (talk) 09:49, 26 September 2011 (UTC)
If you write things in Hindi style then only Hindi readers will understand it - leaving out the rest of the world. If you write it in US or UK style then all English readers will understand it. Aim for the wider audience. Aim for it to be unambiguous.  Stepho  talk  10:04, 26 September 2011 (UTC)

What is 'Hindi style'? Lightmouse (talk) 10:19, 26 September 2011 (UTC)

I meant the 1,00,000 style that you mentioned in the context of Hindi speakers. Apologies if I got the name wrong or offended anyone.  Stepho  talk  10:50, 26 September 2011 (UTC)

The 1,00,000 style isn't related to Hindi. It's used by English speakers. Lightmouse (talk) 11:01, 26 September 2011 (UTC)

I see the template is used directly or translated into at least 16 languages. It may be used on more than one wiki within each language. I suspect translation only involves unit names. If this is an important issue, could we:
  1. reject all 1000 separators in numbers with up to 5 digits. I think that would be equally inconvenient all numbering systems.
  2. reject all 1000 separators for up to 5 digits to the left of the decimal separator
  3. reject all 1000 separators for up to 5 digits to the right of the decimal separator
  4. provide a global setting for the separators which could be configured by the translators for each wiki
Would that resolve most of the issues raised in this thread? Lightmouse (talk) 11:46, 26 September 2011 (UTC)

Sorry for the multiple consecutive posts. The threshold of five digits is an inconvenience the forbids one 1000 separator. If the threshold is three, then that inconvenience disappears. If we have a global switch for template translators to define the meaning of comma and period (which I now accept may be required), then this issue becomes easier. We only need to look for invalid locations of the period and comma. Lightmouse (talk) 12:29, 26 September 2011 (UTC)

Which varient of English should we be using? Australian, of course ... no, it depends, it's best to follow WP:ENGVAR but WP:ENGVAR says nothing specific about this issue. MOSNUM, however, does. MOSNUM recomends grouping digits by threes (or fives in certain maths contexts). MOSNUM allows commas to the left of the decimal separator or gaps both sides (the style recommended by the SI). MOSNUM allows only a dot as the decimal separator. This is the norm in almost all varieties of English. The Indian style or the continental European style is bound to confuse the majority of English speakers. We must keep in mind that we're writing for an international audience. I'm all for encouraging the use of different varieties of English but we should avoid confusion. This template may have been copied into a dozen or so other languages but it would have to have been adjusted to accomodate them. Let {{decomma}} be adjusted similarly. JIMp talk·cont 00:34, 27 September 2011 (UTC)

OK. I think you've persuaded me. I only ask that we try to keep regional settings to the minimum and in a way that makes them easy to change at point of copy/translate. I'll leave the decision to you guys. Thanks. Lightmouse (talk) 09:40, 27 September 2011 (UTC)

  • I have noticed several uses of 2-digit comma style ("10,00,000") but not in conversions, so I think editors working on articles about India would not be affected much. However, I guess we should count the frequency in a sample of such cases. Meanwhile rejecting "1,35" as invalid should not be delayed, because such numbers are incorrect by a factor of 100x. -Wikid77 (talk) 12:55, 7 October 2011 (UTC)

US pint and quart: default should be single output

Current defaults are:

  • 1 US dry pint (550 ml)
  • 1 US quart (950 ml)
  • 1 US dry quart (1,100 ml)

Please can we make those single output to match the others? Lightmouse (talk) 09:38, 6 October 2011 (UTC)

What's good for the goose is good for the gander ... how about these ducks though ...
  • 1 imperial fluid ounce (28 ml; 0.96 US fl oz)
  • 1 imperial quart (1,100 ml; 38 US fl oz)
  • 1 imperial pint (0.57 L)
  • 1 imperial gallon (4.5 L; 1.2 US gal)
... or even these swans?
  • 1 millilitre (0.035 imp fl oz; 0.034 US fl oz)
  • 1 litre (0.22 imp gal; 0.26 US gal)
  • 1 kilolitre (35 cu ft)
JIMp talk·cont 23:19, 6 October 2011 (UTC)

Fair points. But (to change the metaphor) my last attempt at listing all dead trees in the wood ended up with no dead trees being removed. Can we cut the three dead trees on the edge of the wood first? Thus USdrypt, USqt, and USdryqt. Lightmouse (talk) 16:58, 8 October 2011 (UTC)

A bug or a feature

Is the following a bug or some feature I don't understand?

{{Convert|-18|C}}→−18 °C (0 °F)

Thanks.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 28, 2011; 15:58 (UTC)

Google converter says -18 degrees Celsius is -0.4 degrees Fahrenheit. It looks like the template is using integer precision. What do you think it should say? Lightmouse (talk) 16:02, 28 September 2011 (UTC)
I think it should say "0 °F", not "−0 °F". Normal people might have a problem with the latter :)—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 28, 2011; 16:10 (UTC)

Ah yes. I agree. Lightmouse (talk) 16:33, 28 September 2011 (UTC)

The problem is that the decision of whether or not the result is positive or negative is made using the unrounded number, in template:convert/LoffT. If the unrounded result is negative, this template calls template:convert/roundT1, but that template has no check to see what happens after rounding. So, one could either put in an additional check for zero after rounding in template:convert/roundT1, or one could put in an additional check for zero in template:convert/LoffT. In both cases, it looks like you are going to be increasing the complexity of the template. It might work to just nudge the value up by 0.5 where it is used in the check before branching to either template:convert/roundT0 or template:convert/roundT1, since {{rnd}} can technically handle negative numbers, but there must be a reason why we needed to branch to these two different templates? Frietjes (talk) 19:26, 28 September 2011 (UTC)
Yes, it's a bug all right. JIMp talk·cont 04:36, 29 September 2011 (UTC)
  • Some scientists think "-0" is a feature: Because the calculation is rounding a negative number, to zero, then "-0" has been interpreted by some scientists, for many years, to indicate a rounding towards zero from a negative number. Hence, it is somewhat of a feature (rather than just always a bug). Instead, a real bug is when "1,35" in a German-based article is treated as being "135" such as:
  • {{convert|1,35|m|ft}} → 135 metres (443 ft)
  • {{convert|1.35|m|ft}} → 1.35 metres (4.4 ft)
Because the result of converting "1,35" is off by a factor of 100, then it is a very real bug; however, we do not know how many times such numbers are being used in WP articles. That is why a {Convert/decomma} could categorize articles with numbers < 1,000 which have commas, as an estimate of how many articles have that bug. Hopefully, we could quickly edit to fix each of those articles. -Wikid77 (talk) 13:26, 29 September 2011 (UTC)
  • At the risk of sounding anti-elitist, Wikipedia is written for general populace, not for some scientists. Most regular people would have a real problem with seeing a negative zero—to the point of discarding the whole section which uses it as "bug-ridden"! If it could be fixed, I think it would only be an improvement. After all, in an article about some town does anyone really care that a temperature in a climate box has been rounded to zero from a negative number? This is an encyclopedia, after all, not a scientific paper.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 10, 2011; 13:51 (UTC)
  • Scientists were allowed to enter the general populace over 90 years ago: At the urging of world-famous physicist Albert Einstein in 1920, scientists were finally allowed to mingle in public and have become part of the general populace (just kidding) :-). Wikipedia has been reworded, over the past years, to describe topics in article text readable by the general public but also contain extra sections oriented towards scientists, specialists, or other experts, while remaining largely readable for laymen. The term "negative zero" redirects to article "Signed zero" which has noted, for more than 4 years, how "−0" can be used to "denote a small negative number that has been rounded to zero". I have been a math tutor for many years, and I have never heard of people seeing negative zero and deciding that all the nearby information was completely erroneous. Many people are not that judgmental. It might be surprising how many people will say, "Oh, I see, a small negative temperature can be rounded as −0, so what did you think about the final score in yesterday's game?" Thank you for helping to clarify how most people have a remarkable ability to learn, and tolerate ideas commonly used by scientists. -Wikid77 (talk) 16:57, 11 October 2011 (UTC)

Density

I notice there is a section on population denisty but I couldn't see if the convert template worked for the density of materials

I saw triton (on the main page) and it has this chunk density (2.061 g/cm3), which I tried to convert to {{convert|2.061|g/cm3|lb/in3)}

I'm not sure I applied the template correctly but if not can you explain how to get that in the documentation, and if I did get it correct then it appears not to be supported. I'll watchlist this page for a while Cheers EdwardLane (talk) 21:34, 8 October 2011 (UTC)

Is "{{convert|2.061|g/cm3|lb/in3)}" what you actually typed or was using a round bracket instead of a curly one done here on purpose. Otherwise it's fine & would give you "2.061 grams per cubic centimetre (0.0745 lb/cu in)". JIMp talk·cont 23:07, 8 October 2011 (UTC)
Dare I say 'doh' - thanks Jimp, the preview of tha page didn't flag up the erroneus bracket EdwardLane (talk) 15:32, 9 October 2011 (UTC)

Templates that duplicate the convert template

I've just seen 'Category:Geobox unit'. It looks to me like at least some of those templates duplicate the functions within the convert template. Is that true? Lightmouse (talk) 17:28, 11 October 2011 (UTC)

These should be all "subtemplates" of {{geobox}}, so they should not be called directly. If I recall, {{infobox settlement}} has a similar set of subtemplates, but it's more explicit, since they use a "/" to show that they are subtemplates (e.g., template:infobox_settlement/lengthdisp). One issue is the "expression depth" problem with this template, which is one of the reasons they still exist. There is also template:infobox islands/length and probably many many more of these. Frietjes (talk) 17:36, 11 October 2011 (UTC)

Dynamic conversion

Copied from by talk page: begin
I question the benefit of using {{convert}} to do dynamic conversion of (e.g.) km to miles (as you have done in various articles), especially where the equvialent has already been provided. Such conversions need to be done only once, not every time an article is generated. And if an editor feels a "round" number is appropriate then you should not be unilaterally replacing it without prior discussion. – J. Johnson (JJ) (talk) 22:38, 4 October 2011 (UTC)

Thanks for contacting me. I welcome feedback. Just on the technical side of things, can you clarify what you mean by:
  • "conversions need to be done only once, not every time an article is generated"
? Lightmouse (talk) 22:43, 4 October 2011 (UTC)

...the dynamic conversion is where the conversion is calculated everytime the article text is rendered for someone. As opposed to an editor -- or even a bot -- calculating the conversion once and inserting it into the article text. Dynamic calculations are useful where something is frequently changing, but although it is suspected that the kilogram bar is gaining weight it is not at a rate we need to be concerned about. _ J. Johnson (JJ) (talk) 21:29, 7 October 2011 (UTC) Copied from by talk page: end

It's an important question that deserves an answer. I know benefits but not cost. So I can't do a cost-benefit analysis. Please can somebody answer user:johnson? Lightmouse (talk) 15:51, 8 October 2011 (UTC)
IIRC, it's not exactly a dynamic conversion; internally, it's only redone when {{convert}} (or a subtemplate) is edited, and when the article is edited or purged. There are internal storage costs, but I think we've been directed by the developers not to consider those, unless we're hitting the maximum template expansion count in the article. In some cases, it's been strongly suggested that we substitute citation templates, because of that problem. — Arthur Rubin (talk) 16:11, 8 October 2011 (UTC)
I'll let Lightmouse talk about the benefits in more detail Although I believe his bots and semi-automated edits sometimes make serious mistakes, if the {{convert}} template is properly in place, it's much easier to maintain if the numbers do change or are corrected; and it shortens the editable article text. — Arthur Rubin (talk) 16:15, 8 October 2011 (UTC)
And how often do we expect the km/mile conversion to change? _ J. Johnson (JJ) (talk) 19:55, 8 October 2011 (UTC)
And how often do we expect someone to edit "1.5 km (0.9 mi)" and change "1.5" to "1.6", without changing the "0.9" to "1.0"? — Arthur Rubin (talk) 00:27, 9 October 2011 (UTC)
I prefer the use of 'convert' over manual conversions because I can trust it. If I see an instance of 'convert' then I know that I don't have to check its arithemetic (except perhaps to explicitly make the rounding factor to a certain number of digits). Whereas manual conversions often have mistakes. Also, many articles have mixes of miles first of km first. By adding 'disp=flip' to some of them I can make them consistent while keeping the input value true to the source reference.
  • Convert km/miles is actually lightning fast: I am a computer scientist and have developed or used text-formatting systems for decades. I cannot emphasize enough how quickly the conversion of km/miles actually runs these days (even though it can seem overly complex). I think speed analysis will show how using Convert is over 1000x (one thousand times) faster than formatting references by {{Cite web}} or {{Cite book}}, but those cite templates are widely used. Also, I have no objection to hand-coding some conversions, such as "80&nbsp;kilometers (50&nbsp;mi)" especially near the top of an article, but we really have seen several people change one amount and not hand-convert the equivalent unit. Of course, we try not to gunnysack the mistakes made by users, so we just remember that general users might change a speed limit of 50 to "70 mph" leaving "80&nbsp;km/h" rather than 70 miles per hour (110 km/h). As for rounding of amounts, we have discussed the rounding for years, and searching into articles will confirm that most people put whole hundreds when they mean "approximately 200" or "nearly 400" and it is rare when an amount is exactly 300, so feel free to put "300.0" (or round "300|0") to force the precision in those rare cases. Anyway, most of us share the same concerns, so rest assured that we also worry to avoid similar problems in writing and rendering of article pages. Meanwhile, over 80% of articles do not show any conversions, which can be viewed as "very wrong" for users who do understand amounts in only kilometres or miles. Every time you edit an article to update facts or fix grammar, look to also convert amounts that others might not understand. -Wikid77 (talk) 23:04, 9 October 2011 (UTC)
I think you missed my point. If a process takes any time to do (distinct from having negative speed, where it would take less time than not doing it all), it usually takes more time to repeat the operation than do it once and store the result.
Arthur says it is easier from the editor's point of view to use {{convert}}. Which is largely true, but why does it have to be embedded in the article? How about a converter tool available in the editor? Or at elast a link to such a tool? Or if you want to get real fancy, a function where you can highlight a conversion, click on a "check" (verify) button, and then (at the editor's discretion) a "replace" button? I can think of several alternatives, all of which are more efficient in speed, storage, and editor convenience than converting repeatedly. _ J. Johnson (JJ) (talk) 19:35, 10 October 2011 (UTC)
You can check with the developers, but I believe the result is stored; only reset when this template or a used subtemplate is edited. Hence there's only a small marginal cost, as opposed to the effort required to maintain two or more units. — Arthur Rubin (talk) 20:09, 10 October 2011 (UTC)
Taking any time is a bad metric. The real question is whether it takes significant time - ie does it adversely affect the reader or the server. Wikid77 has already said that it takes negligible time, so removing the use of convert for efficiency reasons is a gain that nobody will even notice.
As for your suggestion to embed the final result (ie not dynamic), this is indistinguishable from a manual conversion by an editor. If I see a manual conversion I can not automatically assume that it is correct because editors often make mistakes. As mentioned above, some editors will change the first figure but not change the second. Or they make a mistake in the conversion formula. Or they simple make a typo. Whereas 'convert' can be trusted because once the formula is worked out correctly it will continue to work correctly. And editors only have to change a single number, leaving 'convert' to correctly adjust the remaining number(s).
Also, source references are sometimes in one unit (eg km) and sometimes in the other unit (eg miles). If we find and error like '50 miles (90 km)' in the article then we don't know if the source was 50 miles or 90 km unless we go through the tedious process of following the source. By using 'convert', we only need the single value from the source and then we choose which unit is displayed first by insert '|disp=flip' or not. This is also handy when it is decided to swap the order, instead of doing tedious and error prone manual swapping of the unit order.
In short, 'convert' has no significant impact on timing and has a lot of advantages.  Stepho  talk  03:15, 11 October 2011 (UTC)
Your argument has a hidden assumption: if an editor uses 'convert' orginally he can specify which is source and which is derived. Your "can not automatically assume" which is which also applies to the original context of this discussion, about having a bot do mass insertions of 'convert'. In that case your confidence in seeing 'convert' used is misplaced, because the bot has no superior basis for automatically assuming which is which. The belief that "If I see an instance of 'convert' then I know that I don't have to check its arithemetic" is totally undercut if it has the wrong input (GIGO). There is more involved than arithmetically exact proportionality. _ J. Johnson (JJ) (talk) 17:37, 12 October 2011 (UTC)


  • Years of discussions have supported Convert: I was a computer-lab tutor as an undergrad, and you would be surprised the number of college sophomores who cannot use a computer to solve a partial differential equation within 3 minutes (just kidding). Bear in mind how the case of converting km/miles is just one example, among hundreds of different conversions. We had a highly intelligent developer who thought that Convert could be replaced by a built-in internal parser function to spit out "161" as kilometers for 100 miles (or hundreds of other units), until he realized that complex formatting of the results was also wanted by editors, such as numbers spelled out as words:
  • {{convert/spell|161|km|mi}} → one hundred and sixty-one kilometres (100 mi)
Then, there are people who want to convert huge numbers of kilometres into astronomical units, not just miles, and so the variations become almost unlimited, but Convert handles some very extreme cases, such as gaps instead of commas:
  • {{convert |651,000,000|km|AU}}       → 651,000,000 kilometres (4.35 AU)
  • {{convert/spell|651,000,000|km|AU}} → six hundred fifty-one million kilometres (4.35 AU)
  • {{convert/gaps |651,000,000|km|AU}} → {{convert/gaps |651,000,000|km|AU}}
  • {{convert/spell |7.35|km|in}} → seven point three five kilometres (289,000 in)
Consequently, over the years, when hundreds of issues have been considered, we have recommended to continue using Convert, and avoid any attempts to create built-in functions, or converter tools, which typically focus on only a tiny subset of the issues which have been raised over the past several years. For experimenting with converter tools, then users could try using Google Search conversions, such as "51 km in mi" to give "51 kilometers = 31.6899308 mi" but then much discussion can occur when people want to type precisely "31.6899308 miles" as the result in an article. Hence, considering all the viewpoints, over the years, the decision has been to continue using Convert, for overall convenience. -Wikid77 (talk) 05:47, 11 October 2011 (UTC)

Gill, US quart, US pint, US peck

Lower case 'us' in template:

  • 1 gill (120 ml; 4.2 imp fl oz)
  • 1 US pint (0.47 L; 0.83 imp pt)
  • 1 US dry pint (550 ml)
  • 1 US quart (950 ml)
  • 1 US dry quart (1,100 ml)
  • 1 US peck (8.8 L; 1.9 imp gal)


Upper case 'US' in template:

  • 1 gill (120 ml; 4.2 imp fl oz)
  • 1 US pint (0.47 L; 0.83 imp pt)
  • 1 US dry pint (550 ml)
  • 1 US quart (950 ml)
  • 1 US dry quart (1,100 ml)
  • 1 US peck (8.8 L; 1.9 imp gal)


Dotted upper case 'U.S.' in template:

  • 1 gill (120 ml; 4.2 imp fl oz)
  • 1 U.S. pint (0.47 L; 0.83 imp pt)
  • 1 U.S. dry pint (550 ml)
  • 1 U.S. quart (0.95 L; 0.83 imp qt)
  • 1 U.S. dry quart (1,100 ml)
  • 1 U.S. peck (8.8 L; 1.9 imp gal)


Full spelling in template:

  • 1 US quart (950 ml; 33 imp fl oz)
  • 1 US dry quart (1,100 ml)

Wouldn't it be more efficient to use redirects rather than one template for each code option? Anyway, please can they all be set to single default output. Lightmouse (talk) 15:00, 10 October 2011 (UTC)

  • Those are 3 different styles of display, where unit-codes (such as "usqt") with the lower-case "us" will allow changing the spelling by "sp=us":
• {{convert|1|usqt|sp=us}} → 1 U.S. quart (950 ml)
• {{convert|1|usqt|sp=en}} → 1 US quart (950 ml)*
• {{convert|1|USqt|sp=us}} → 1 U.S. quart (950 ml)
• {{convert|1|U.S.qt|sp=en}} → 1 U.S. quart (0.95 L; 0.83 imp qt)*
Note how the uppercase unit-codes (with "US" or "U.S.") always force the spelling to match the unit-code and ignore "sp=xx". For that reason, the 3 styles ("us" or "US" or "U.S.") were developed as fully separate templates which do not use redirection. However, all of the upper-case "US" unit-codes could be redirected to the lower-case "us" unit-codes, because the default results use the same capital letters, in showing "1 US". On the other hand, the lower-case "us" unit-codes could be kept separate to list 2 default outputs for each amount. As always, this is part of the 20,000 issues to consider in modifying Convert, and we should prioritize which among the 20,000 issues to change first. -Wikid77 (talk) 09:01, 11 October 2011 (UTC)

Aha. Thanks for explaining the 'force spelling' issue. Where you say:

  • "all of the upper-case "US" unit-codes could be redirected to the lower-case "us" unit-codes

that seems like a good idea. I know you guys are spinning lots of plates and I appreciate it. I hope Jimp will be along shortly to comment on this section too. Lightmouse (talk) 11:10, 11 October 2011 (UTC)

Note that the "US" in the US gills is missing because the subtemplate is currently part of an experiment. JIMp talk·cont 00:31, 12 October 2011 (UTC)
There are two ways of getting "US" and two ways of getting "U.S.":
  • For "U.S." use U.S.gal, U.S.pt, U.S.oz etc. or use usgal, uspt, usoz with sp=us.
  • For "US" use USgal, USpt, USoz etc. or use usgal, uspt, usoz with sp set to anything else (or nothing at all).
Is this an overkill? Probably. Do we need two ways of choosing between dots and no dots? Probably not. Are users in general even aware of this? I really doubt it.
I'd be quite happy to forget about this option & disconnect the dotting from sp altogether. JIMp talk·cont 02:46, 12 October 2011 (UTC)

The following template codes appear to be used:

  • 'us_unit': 452 articles
  • 'US_unit': 986 articles
  • 'U.S._unit': 79 articles
  • 'us_unit', sp=us: 5 articles

Hope that helps. Lightmouse (talk) 17:35, 12 October 2011 (UTC)

Subtemplate request

Could one of you template wizards create Template:Convert/LoffAoffDbSmidNa which seems to be needed to allow the speedy repair of several hundred of Lightbot's recent edits similar to this, please? At least if I amend the Convert template in that edit to append |adj=mid|free (per Template:Convert#Parameters), that's the redlink I see when previewing. This section from the 2010 Tech archive is obviously relevant, and there's a bit of surrounding detail at User_talk:Lightmouse#Which_is_right.3F (from the bullet "But much more dramatic"). Thanks in anticipation!  —SMALLJIM  23:21, 11 October 2011 (UTC)

I redirected it to Template:Convert/LoffAoffDbSmid in the same way that Template:Convert/LoffAoffNa is a redirect, but I don't think this is going to give you what you had before Lightbot's edit, since the "free" will come after the "acre", not before it. Frietjes (talk) 23:37, 11 October 2011 (UTC)
I speak English very good, no? :) Ah well, many thanks for the quick reply - I think it may help with some of the edits, and I'm glad it was a simple fix, at least. I don't suppose there's any way Convert can be made to change "107 free acres of land" to "107 free acres (0.43 km2) of land", is there?  —SMALLJIM  00:05, 12 October 2011 (UTC)
Pure magic. Have a nebula :)  —SMALLJIM  11:38, 12 October 2011 (UTC)

New option adj=pre for prefix text

I have created subtemplates to allow adj=pre to specify the prefix text before the first unit name:

  • {{convert|4.0|m|ft|adj=pre|exact}} → 4.0 exact metres (13.1 ft)
  • {{convert|1|mi|km|adj=pre|statute}} → 1 statute mile (1.6 km)
  • {{convert|155|acre|m2|adj=pre|free}} → 155 free acres (630,000 m2)
  • {{convert|107|acre|km2|adj=pre|free}} → 107 free acres (0.43 km2)
  • {{convert|107|acre|km2|adj=pre|[[green space|green-space]]}} → 107 green-space acres (0.43 km2)

This option should have been created years ago, but there has been a tendency to avoid new features because there are so many subtemplates. However, I think it would be unfair to deny new features to users, at this point, and we can find ways to simplify the subtemplates in the future, as a separate concern. -Wikid77 11:01, revised 11:12, 12 October 2011 (UTC)

I think

  • "107 free acres of land"

really means

  • "107 acres of free land"

A word between the number and unit looks odd to me. Similarly with "a hillside of 12 wooded acres", it's the hillside that's wooded, not the acres. Some cases use words that add little value e.g. "the lake is 2 surface square miles", "the length increased by 20 additional feet".

I've done a lot of edits by hand to move or rephrase the sentence prior to adding a conversion. With automation-assisted editing, there's a few things that can be done to recast sentences and perhaps I'll investigate this issue further. But the above option will avoid the need to recast the sentence at the same time as adding the conversion. As user:smalljim says, thank you very much. Lightmouse (talk) 14:40, 12 October 2011 (UTC)

I can probably create a bot task to work on intervening words, including those that were moved by Lightbot. Smalljim, will you support such a bot task? Lightmouse (talk) 18:04, 12 October 2011 (UTC)
No, I would not. These cases are not amenable to being reliably processed by a bot. Of the 500 or so dubious Lightbot edits that I mentioned on your talk page, I've manually checked the last 90-odd using AWB and about half of them needed repair, see list here. Rather than thinking about starting more conversions, you ought to repair the rest of these first, in accordance with WP:BOTACC: "the bot operator is responsible for the repair of any damage caused by a bot which operates incorrectly."  —SMALLJIM  19:36, 12 October 2011 (UTC)
That's what I meant. The first action would be to work on intervening words that were moved by Lightbot. Would you support such a bot task? Lightmouse (talk) 20:58, 12 October 2011 (UTC)
Sigh. No, I would not. In case what I wrote above wasn't clear - you should repair the outstanding bad edits manually, using AWB if you want. And to be honest, I should do it quickly if I was you, else consensus might turn against you being allowed to run a bot again.  —SMALLJIM  22:00, 12 October 2011 (UTC)
In case it helps, I've created a list of the outstanding edits, in AWB format. (E&OE!)  —SMALLJIM  22:16, 12 October 2011 (UTC)
SMALL, the first one I looked at in your list of bad edits was bad. "A permanent home came in December 1948 when the college purchased 26 acres (110,000 m2) hilltop in Sugarloaf Township which, for". It should, of course, be "A permanent home came in December 1948 when the college purchased 26 hilltop acres (110,000 m2) in Sugarloaf Township which, for". LM, I think, has undertaken to fix this aspect of the bot, and to fix the bad edits. But whether he does it manually or via auto is neither here nor there. This sounds like a good outcome to me. Is there still a problem? Tony (talk) 09:53, 13 October 2011 (UTC)
Tony, I've replied to both your messages on my talk page.  —SMALLJIM  16:24, 13 October 2011 (UTC)

e6cuft/d

As I write this, there are 14 articles showing the redlink Template:Convert/e6cuft/d instead of a conversion. They were all added on 26 Sept (example) - could someone have a look, please?  —SMALLJIM  17:04, 14 October 2011 (UTC)

I have added the missing template, so hopefully no more redlinks (or new bugs):
  • 60 million cubic feet per day (1,700,000 m3/d)
  • 60×10^6 cu ft/d (1,700,000 m3/d)
  • 60 million cubic feet per day (1,700,000 cubic metres per day)
  • 60 million cubic feet per day (1.7 million cubic metres per day)
Frietjes (talk) 17:12, 14 October 2011 (UTC)
I have also created ones for e3
  • 200 thousand cubic feet per day (5,700 m3/d)
  • 200×10^3 cu ft/d (5,700 m3/d)
  • 200 thousand cubic feet per day (5,700 cubic metres per day)
  • 200 thousand cubic feet per day (5.7 thousand cubic metres per day)
and e9, so hopefully no more redlinks (or new bugs):
  • 3 billion cubic feet per day (85,000,000 m3/d)
  • 3×10^9 cu ft/d (85,000,000 m3/d)
  • 3 billion cubic feet per day (85,000,000 cubic metres per day)
  • 3 billion cubic feet per day (85 million cubic metres per day)
Frietjes (talk) 17:57, 14 October 2011 (UTC)
Thanks again, Master of the Curly Brackets.  —SMALLJIM  18:42, 14 October 2011 (UTC)

Numbers greater than 0 but less than or equal to 1 should use singluar nouns

I'm noticing that this template is printing things like "0.52 miles" or "0.739 kilograms" when I think the singular should be used there. — Preceding unsigned comment added by 99.4.166.31 (talk) 00:28, 22 October 2011 (UTC)

I don't agree but could it be a matter of dialect? JIMp talk·cont 17:40, 23 October 2011 (UTC)
That's my impression too (even though I have never seen any source directly addressing this issue), as the singular ‘sounds wrong’ to me but I've seen it in AmE texts quite a few times. (Anyway, I asked that on WP:RD/L a while ago and IIRC I was answered something to the effect that normal people use the plural and pedants use the singular.) ― A. di M.​  18:15, 23 October 2011 (UTC)
I agree with Jimp and A. di M., for decimals between 0 and 1, plural units sounds correct (but it would be a singular unit with a fraction such as 1⁄2). -- Dr Greg  talk  18:22, 23 October 2011 (UTC)
PS. Google Ngrams[1][2] appear to confirm my impression that there is a dialect difference, though a slight one. ― A. di M.​  20:15, 23 October 2011 (UTC)
  • This issue has been discussed for years, with no clear consensus, so I am creating an option "adj=1" to show the singular unit name for decimals (or fractions) less than 1:
• {{convert|0.5|mi|km|adj=1}}   → 0.5 miles (0.80 km)*
• {{convert|1.5|mi|km|adj=1}}   → 1.5 miles (2.4 km)*
• {{convert|1/2|mi|km|adj=1}} → 1⁄2 mile (0.80 km)*
• {{convert|1/2|mi|km}} → 1⁄2 mile (0.80 km)
In some cultures, the singular "0.5 mile" can be used to emphasize the amount (0.5) as being within 1 mile, just as a fraction less than 1 should always be singular, as in "1⁄2 mile (0.80 km)*". I think the easiest solution is to have new option "adj=1" to allow for singular decimal amounts less than 1. Otherwise, we would continue to debate the format for more years, and change the template operation back and forth in future months. -Wikid77 (talk) 18:24, 23 October 2011 (UTC)

Fractions between +1 & −1 definitely should go with the singular but although 1⁄2 and 0.5 are mathematically equivalent they are two different beasts in grammar. I haven't got any solid proof but my hunch is that this is ... or at least started out as a hypercorrection: an extension of the fraction rule into the decimal numbers. But the thing, of course, is that if enough people follow the grammatically incorrect pattern, it ain't wrong no more. JIMp talk·cont 03:58, 24 October 2011 (UTC)

Looking at Google Ngrams, the singular appears to be the older form and the plural a British innovation,[3][4][5] which kinda surprises me. ― A. di M.​  15:43, 24 October 2011 (UTC)

Plural starts from 2. But people are strange.

--Nnemo (talk) 06:24, 24 October 2011 (UTC)

If by strange you mean “unlike the French”, then [self-censoring myself because if I spoke my heart I'd deserve an indefinite ban for incivility]. ― A. di M.​  23:44, 24 October 2011 (UTC)

Definitely plural (with all decimals) for me. That's British English, and despite years spent in Poland where it's the singular with all decimals (as you might expect logically - 23.4 miles is 23 and four tenths of a mile - but these things aren't governed by logic). I think I would even write (and say) "1.0 miles".--Kotniski (talk) 16:38, 24 October 2011 (UTC)

This unemployed linguist from Britain says “one point zero seconds” too, which for some reason doesn't sound that weird to me, either. ― A. di M.​  23:44, 24 October 2011 (UTC)
Australians do the same as the Brits: 0 gallons, half a gallon, 0.5 gallons, 1 gallon, 1.5 gallons, one and a half gallons. I presume many other Commonwealth countries do the same.  Stepho  talk  04:46, 25 October 2011 (UTC)
What do Australians do? I say "0.5 litres" but Tony seems to reckon it'd have to be "0.5 litre" (though "0.5 of a litre" seem to have a different ring to me). "Half a gallon" doesn't count (if you ask me) since "half" is a fraction & fractions are different to decimals. JIMp talk·cont 05:43, 25 October 2011 (UTC)
I think Tony's comment concerned logic rather than idiom? --Kotniski (talk) 08:41, 25 October 2011 (UTC)
Excuse me... I thought this was the English Wikipedia, not the Lojban one. (And I guess Lojban has likely no grammatical number – what's the point of it, when you can just say "several sheep"?) ― A. di M.​  12:34, 25 October 2011 (UTC)
"zero point five of a liter" does not sound right to my ear. — Carl (CBM · talk) 10:35, 25 October 2011 (UTC)
There is only one singular decimal number, and that's 1. No other number is singular, and thus cannot take the singular form. And 1.0 is not equal to 1, nor is 1.00 or 1.000. Even though 0.99999... IS equal to 1, I would still use the non-singular form with it, basically for consitency's sake more than anything else. And because some wise ass is bound to mouth of that 0.99999... can't be equal to one, it's just common sense, and I'd have to explain to them that they're wrong, which usually ends up being a waste of my time. Dominus Vobisdu (talk) 14:30, 25 October 2011 (UTC)
I suppose there's no point in my telling you all that I am an expert in the English language, because you would demand proof, which I'm not about to give you; and even if I did, you would all then declare that it gives me no status whatsoever in Wikipedia. But guys - half of a single unit is still half a unit, not a half a units. What you young'uns don't realize is that this kind of verbal monstrosity, among many others, has arisen only since the spread of computing in its early forms, with its rigid programming requirements and lackadaisical, don't-give-a-damn-about-English programmers. Half a unit, fifty percent of a unit, five-tenths of a unit, or .5 unit - any way you slice it, fellas, the correct form here is singular. If you don't want to be correct, well that's your choice, I guess, but there you have it. Textorus (talk) 14:58, 25 October 2011 (UTC)
The count on Google for "0.5 miles" outnumbers the count for "0.5 mile" by a factor of 20, which seems to argue against the idea that the former is correct and the latter is unilaterally wrong. The key point, I think, is there is no "of" when I read "0.5 miles", and the plural is present to agree with the 5. That's my reading as a native speaker. PS The ratio of "0.3 miles" to "0.3 mile" is 83:1. — Carl (CBM · talk) 15:14, 25 October 2011 (UTC)
I think you've hit the nail on the head with noting the missing "of" ... but to drive it further in do allow me to rephrase (shifting the emphasis a little): half a unit, fifty percent of a unit, five-tenths of a unit ... now we can talk and talk about whether 1.0, 0.9 or 2⁄2 is the same as one mathematically, conceptually and grammatically but one thing that's clear as mud, one thing we'd believe even if a proven expert tells us, is that "a" and "an" are the same as "1". The "a" is making those singular, omit "of a" and you're not slicing the same beast any longer. JIMp talk·cont 16:29, 25 October 2011 (UTC)
Yes. I believe that in present-day British English the plural is kind-of “default” for count nouns and the singular is only used after a finite set of determiners including a(n), one, this etc. (and there are some determiners such as the which can use both, depending on semantics). (As for half in a half mile, I'd analyse it as an adjective, as in a big man, even though it's semantically weird as a half mile is not a type of mile. Note also the (old-fashioned, but still occasionally found) construction many a time. As for a million miles, er..., uhm... Whatever. Natural languages are weird. Maybe it's a single determiner in spite of the space in the spelling?) ― A. di M.​  17:05, 25 October 2011 (UTC)
Google doesn't actually count hits, they estimate their number (hence the About) with an algorithm which for large numbers (more than a few thousands) can easily be off by orders of magnitude. Google Ngrams is much better for this kind of stuff, even though the sample size is much smaller so for very uncommon phrases you got large statistical errors. ― A. di M.​  17:05, 25 October 2011 (UTC)
“"0.5 miles", and the plural is present to agree with the 5”
So, to agree with the 1, we say 24.1 gram ?
--Nnemo (talk) 20:40, 25 October 2011 (UTC)
Of course not. But we do say "zero point five miles" to agree with the five. Language usage is not a simple thing. — Carl (CBM · talk) 23:11, 25 October 2011 (UTC)
Is it even that simple? If we say "zero point five miles" to agree with the "five", how about "zero point one mile(s)"? JIMp talk·cont 23:48, 25 October 2011 (UTC)
That is a good point. I think the plural sounds better there. For comparison, "zero point one feet" also sounds better than "zero point one foot" to me. — Carl (CBM · talk) 01:34, 26 October 2011 (UTC)
Would you say one point zero foot, or one point zero feet. Remember that 1.0 is not equal to 1 . Personally, I'd use feet for any decimal number except 1 . Dominus Vobisdu (talk) 01:59, 26 October 2011 (UTC)

"1.0 feet" seems to sound better to me. What about minus one? JIMp talk·cont 07:48, 26 October 2011 (UTC)

Both "−1 foot" and "−1 feet" sound kind of OK to me, though I would read them with different stress patterns. ("Minus | one foot" with the same rhythm as "over one foot" or similar, and "minus one | feet" with the same rhythm as "twenty-one feet", if that makes sense.) But then again, I'm not a native speaker. ― A. di M.​  10:45, 26 October 2011 (UTC)
So it sounds like we're on the same page. Singular with 1 . Plural with all other numbers greater or less than 1 , including all negative numbers and 1.0 1.00 1.000 etc. I can't think of any exceptions. Can you? (Please don't mention 0.9999... as it's highly unlikely that we're ever going to write 1 that way.) Dominus Vobisdu (talk) 11:02, 26 October 2011 (UTC)

Frankley Reservoir

Could someone take a look at the broken instance in Frankley Reservoir, please? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:35, 24 October 2011 (UTC)

non-breaking spaces

Apologies if this has been raised ad nauseam.

Although it has never bothered me much, I note from other editors' comments that some are unhappy with the appearance of a number, then the units to which that number refers on a different line. This would usually be avoided by a non breaking space, so I wonder whether the automatic insertion of this is something that this template could benefit from, if the software allows for it. I'm afraid I would almost certainly break code if I tried, so I'd rather leave it to those more expert. Kevin McE (talk) 18:42, 16 October 2011 (UTC)

Not only a benefit, but even recommended: the Manual of Style says to use them "in expressions in which figures and abbreviations (or symbols) are separated by a space". But there are issues, and automatic insertion itself could be an issue. – J. Johnson (JJ) (talk) 20:03, 16 October 2011 (UTC)
I'm pretty sure this template did use non-breaking spaces before unit symbols at some point. ― A. di M.​plé​dréachtaí 23:22, 16 October 2011 (UTC)
  • The unit symbols are usually tied after numbers, by using a non-breaking space; however, very large numbers were allowed to wrap at end-of-line (and place the unit symbol on the next line) to avoid a large text-gap at end-of-line.
Expected Actual Actual Actual Expected Actual
2 kilometres
(1.2 miles) 		2 kilometres (1.2 miles). 2,000 kilometres (1,200 miles). 2,000,000 kilometres (1,200,000 miles). 2 km
(1.2 miles) 		2 km (1.2 miles)
We have discussed this issue for years, but it is always good to consider if new bugs have affected the spacing, and reconsider whether the style is appropriate in combination with other issues which have arisen. Compared to spelling errors and grammar, the wrapping after numbers is a minor issue, but can be frustrating. If the wrapping appears bizarre, then hard-code the conversion: "2&nbsp;kilometres (1.2&nbsp;miles)" as is done in many articles. -Wikid77 (talk) 17:13, 23 October 2011 (UTC)
Originally the intention was to wrap when the unit is spelt out and not to when a symbol/abbreviation is used (per MOSNUM). As noted by Wikid, edits have been made to allow wrapping after large numbers. Should we continue with that approach? Is it desirable? Is it worth the extra coding? Is avoiding a large text-gap at end-of-line a strong enough reason to ignore MOSNUM? Note that those convert calls which allow this (number-dependant) wrapping take no account of the length of the unit symbol (e.g. "100,000 m" but "10,000 cu ft/s" won't). JIMp talk·cont 18:07, 23 October 2011 (UTC)
It can also wrap with ranges of small numbers. For example, {{convert|4|-|5|cm|in|abbr=on}} can wrap before the "cm". --Stfg (talk) 08:45, 28 October 2011 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_October_2011&oldid=1134886594"