Template talk:Convert/Archive December 2011

Missing & improperly-formatted torque units

In Wikiproject: Automobiles, after extensive thoroughgoing and productive discussion, we developed conventions for the expression of torque in automotive contexts. These conventions are based on formal structure and usage throughout the Anglosphere; please see the conventions at WP:AUN. Formerly, these were generally handled by special {{Auto}} templates which no longer exist; their functions were incorporated into {{convert}}. However, a couple of important units were lost or damaged in translation. Firstly, {{convert}} offers "ft-lb", which is an unencyclopædic (informal/colloquial) rendition of what is properly, formally (and therefore encyclopædically) rendered lb·ft ("pound-feet"), with elements separated by a middot and presented in the correct order. ("Correct" may seem a high-handed assertion; in fact, it's been thoroughly investigated and hashed out; some of many links to related discussion are here and here. Check any physics text; torque is invariably defined as "force times the length of the lever arm" (paraphrased), never "length of the lever arm times force".) Moreover, {{convert}} seems to lack the analogous unit for smaller torque values, which is lb·in ("pound-inch").

Will somebody more knowledgeable than I in the making and maintenance of template additions kindly please repair "ft-lb" to lb·ft and add lb·in? Thanks much. —Scheinwerfermann ^T·_C22:42, 4 December 2011 (UTC)

This is the resurection of last month's unfinished business. Sorry it's taken so long to address this. As I noted then:

• The template does not offer "ft-lb" (except as an input code).
• In physics the distinction between torque & energy is that one is a vector & the other a scalar.
  • I don't mean to call you wrong but torque is actually normally defined as τ = l × F (our article does the same) ... i.e. displacement by force.
  • Inspite of this definition, though, we have newton-metres (as opposed to metre-newtons).
  • I don't believe that the order in which physical quantities are defined determines the order in which their units are defined.
  • It's more a matter of convention.

I consider myself fortunate not to have grown up with the imperial/US system of units but this means that I'm not completely familiar with the foot-pound-second (... or foot-pound-g) system of units all I know is what I read ... mostly. According to our articles, yes, foot-pounds are energy and pound-feet are torque ... usually but not always. It seems (according to our article) that this convention was "apparently first proposed by British physicist Arthur Mason Worthington". However, it seems that the convention is not completely adhered to out there ... should it be adhered to here? I can't see the harm in sticking to it but the advantages are pretty clear. Up till now the template had assumed that foot-pounds and pound-feet could each be either energy or torque this is in accordance with the apparant ambiguity in the world out there coupled with the silence of our guidelines here. I'd be happy to change this however, this is not the place for such discussion we should bring it up at WT:MOSNUM. Last time you noted that the energy unit should be "foot-pounds force" rather than just "foot-pounds", I agree that the former is better, why, though is "pound-feet" as opposed to "pound force-feet" okay? This is another thing worth bringing up at WT:MOSNUM. Whilst we're at it we might discuss whether the "f" should be subscripted or not. Last time you also noted that some clean up is in order to replace hyphens with middots and to make spellings uniform ... yes, this should be done; no, you won't break anything if you fix these lists. Anything with "Convert/list of units" should not be transcluded onto the article space, should be unprotected and is fair game to be edited. You also suggested that the input code ftlb should give the unit pound-feet. This is something we need discuss thoroughly. JIMp _talk·cont 01:28, 5 December 2011 (UTC)

Pound-inches

I added pound-inches (lb·in) a month ago but, I'm sorry, I didn't announce the fact.

{{convert|1.00|lb.in}} → "1.00 pound force-inch (113 mN⋅m)"

Do we need any others, ounce-inches, ton-miles, stone-furlongs ... (I'm getting carried away.)? JIMp _talk·cont 08:02, 5 December 2011 (UTC)

... barley corn-grains ... JIMp _talk·cont 00:47, 6 December 2011 (UTC)

I doubt that it makes sense to add all these obscure units. A unit that is only used in at most half a dozen places is just not worth the complexity and maintenance overhead that it causes for the template. Hans Adler 01:20, 6 December 2011 (UTC)

There is very little maintence overhead involved actually but, that said, no, I wasn't actually serious with most of these. The ounce-inch may have half a dozen uses but the others are there for humour (especially barley corn-grains) ... stone-rods ... JIMp _talk·cont 01:49, 6 December 2011 (UTC)

MOSNUM discussion

I've started a discussion at MOSNUM talk regarding

1. whether we should follow Worthington or allow the foot-pound for torque
2. whether "force" should be consisdered necessary, undesirable or optional and
3. whether "f" should be subscripted in the abbreviations.

JIMp _talk·cont 07:44, 5 December 2011 (UTC)

Should ftlb give pound-feet?

Scheinwerfermann suggests that "it might be a good idea to provide syntactic permissiveness so that {{convert|ftlb|Nm}}, {{convert|lbft|Nm}}, {{convert|Nm|lbft}} and {{convert|Nm|ftlb}} all render the English/Customary unit as lb·ft".

Now, {{convert|lbft|Nm}} and {{convert|Nm|lbft}} already do give pound-feet but {{convert|ftlb|Nm}} and {{convert|Nm|ftlb}} currently give foot-pounds. ... JIMp _talk·cont 01:28, 5 December 2011 (UTC)

The argument is that "foot-pounds" is "ungrammatical and ambiguous", that the energy unit should be "foot-pounds force". Why, I wonder, is "pound-feet" (as opposed to "pound force-feet") okay and "foot-pounds" wrong? Logic would suggest either both are correct or both are wrong ... but since when are things logical? ... but this is a MOSNUM question.

If "foot-pounds" is wrong, then should ftlb give "pound-feet" instead ... or "foot-pounds force"? The latter would seem more sensible but I note that the what links here for {{convert/ftlb}} is mostly car articles but that ftlb converts to newton-metres by default could have some influence here.

More specifically, {{convert/ftlb}} is transcluded on thirty-three car articles & two gun articles. If "foot-pounds" gets the thumbs down at MOSNUM, it wouldn't be out of the question to make ftlb give a message instructing editors to choose one of the grammatical and unambiguous units. JIMp _talk·cont 05:21, 5 December 2011 (UTC)

Foot-pound force ought to be abbreviated Ft·lb_f. The abbreviated forms for all the expressions under discussion need middots, not dashes, so whatever we decide on foot-pound, pound-foot, etc., this template ought to be spitting out lb·ft, not "lb-ft" or "lb/ft" or "lb•ft"; ft·lb and not "ft-lb" or "ft/lb" or "ft•lb", etc. As for "Pound-foot (force)", expanded or abbreviated, I cannot find any evidence of its usage as a unit of torque, and I think it probably doesn't merit prolonged consideration in this present discussion.

As for the choice between ft·lb and lb·ft, we are sort of between a prescriptive rock and a descriptive hard place here. Both "Pound-foot" and "Foot-pound" can be found referring to torque in reliable sources. I have a wall of shelves full of service and engineering manuals published by the US, UK, South African, and Australian offices of a great many manufacturers of automobiles, engines, and other equipment, as well as basic tool and tech texts such as Stockel and various SAE publications; these are all but uniform in their preference for Lb·ft as the torque unit. I have another wall full of shelves containing mostly popular literature (Popular Mechanics, Popular Science, etc.) which appears to use the two unit expressions interchangeably.

Using "Pound-foot" for torque and "Foot-pound" or "Foot-pound force" for energy is less ambiguous than using "Foot-pound" for both. It would be overstating the case to assert, as I might have, that one is right and the other is wrong, and it might be overstating the case to argue that "Pound-foot" is the proper torque unit, and "Foot-pound" or "Foot-pound (force)" is the proper energy unit, but it might be understating the case to argue that they are fully and freely interchangeable with no preference either way. Given that we are writing an encyclopædia the purpose of which is to edify, illuminate, clarify, and educate, we appear to have an opportunity to further that purpose by disambiguating the units we use for torque and for energy. This appears to be a zero-cost opportunity in that if we disambiguate the units by preferring Pound-foot for torque and Foot-pound for energy, we aren't doing anything that could be called wrong, arbitrary, or otherwise problematic. On the other hand, there's something to squawk about if we ambiguate the units by using "Foot-pound" for both torque and energy. I don't know that the options before us are polar enough to warrant stringent mandates, but I think we ought to nudge and channel our usage convention towards the clearer and less ambiguous usage: Pound-foot for torque and Foot-pound (force) for energy, as for example by using those units for those purposes in this template. If consensus cannot be reached to do so, then I would drop back to advocating for the disambiguative usage as default, with the ambiguous usage still permitted. —Scheinwerfermann ^T·_C23:14, 5 December 2011 (UTC)

I have answered at length at the MOSNUM discussion but here are the highlights.

• Yes, it should be a middle dot; no hyphen, no bullet & no slash (the worst of the lot). I believe {{convert}} is in compliance. If not, it should be.
• These abbreviations should contain no capital letters ("lb·ft" not "Lb·ft").
• Scheinwerfermann, you seem to prefer subscript "f" (for "force"). I wonder whether MOSNUM should offer guidance here.
• I think we have a good case for adopting the convention of "foot-pounds (force)" for energy and "pound (force)-feet" for torque. It makes sense that the sources we follow be scholarly ones especially when umabiguity is the result.
• I'd like clarity with respect to "foot-pounds" verses "foot-pounds force" and "pound-feet" verses "pound force-feet". Which do we prefer, mandate, ban or make optional?

JIMp _talk·cont 01:06, 6 December 2011 (UTC)

I oppose the inclusion of "force" in the torque unit. I am not omniliterate, but in my extensive collection and reading of relevant literature, "pound force foot", whether expanded or abbreviated, is not in formal, popular, or colloquial use as an expression of the torque unit. I don't espouse an I've-never-seen-it-so-it-doesn't-exist stance, but I will be very surprised if substantial evidence could be provided for the existence of lb_f·ft except perhaps as a very recherché term nobody actually uses.

I lean somewhat less fervently towards mandatory inclusion of "force" in the energy unit (to further distinguish it from the torque unit, since "foot-pound" is in popular use as a torque unit). I support ft·lb_f, per se, for the abbreviation of the energy unit.

I agree with all lowercase. —Scheinwerfermann ^T·_C01:28, 6 December 2011 (UTC)

Request for conversion from inches per second to cm/second

Could somebody possibly add in/s to cm/s. An editor has made a large number of incorrect edits to the metric equivalents of audio tape speeds across a number of articles and, if I am going to start correcting these it would be nice to do it properly.

Many thanks,

FrankFlanagan (talk) 22:01, 5 December 2011 (UTC) 22:02, 5 December 2011 (UTC)

Done. {{convert|10|in/s}} → "10 inches per second (25 cm/s)" JIMp _talk·cont 01:16, 6 December 2011 (UTC)

Many thanks,

FrankFlanagan (talk) 04:34, 6 December 2011 (UTC)

Adding new features by using wrapper templates

04-Dec-2011: Year-end is a busy time of the year for many Wikipedians, but I wanted to note again that extra functionality can be added to Template:Convert by creating more wrapper templates in the future, which add the needed complexity, but only to be used in the relatively few hundred cases where extra formatting is needed. Using wrapper templates avoids expanding the underlying Template:Convert with complex combinations of rare features. For example, several people have requested minor rounding of the input amount, while displaying extra precision of the output amount, and that could be handled by a new parameter "inround=3" to show 3 decimals on the input amount but use all decimals for the output amount. Obviously, that situation would be rare, and could be abused to show incorrect amounts, but it could be one type of option added to a wrapper template. I am working on creating such a wrapper template, similar to the extensions for spelled-out numbers, gaps, and E-notation:

• {{convert/spell|3045|mi|km|0}} → three thousand and forty-five miles (4,900 km)
• {{convert/gaps|3400.50123|mi|km}} → {{convert/gaps|3400.50123|mi|km}}
• {{convert/E|3.400E9|mi|km}} → 3.400E9 miles (5.472×10⁹ kilometres)

Again, this is a busy time for many users, so this is just a reminder notice that the issue is being worked this week for future use. -Wikid77 (talk) 16:48, 4 December 2011 (UTC)

Always busy extending the template beyond what anyone else had ever imagined, nice job, Wikid ... but ... sorry to always throw a spanner in your works ... but do we really want to display E notation? Perhaps this is a MOSNUM question but I thought it was pretty much decided that E notation is for machines ... or am I imagining that? JIMp _talk·cont 07:22, 8 December 2011 (UTC)

Hectares to acres malfunctioning

On the page Pando (tree), this template is converting 43 hectares to 110 acres. It should be 106 acres. Nadiatalent (talk) 18:12, 7 December 2011 (UTC)

it's rounding to two significant figures, use "sigfig=3" if you want more digits. Frietjes (talk) 18:16, 7 December 2011 (UTC)

Thanks! Nadiatalent (talk) 18:23, 7 December 2011 (UTC)

pound-moles to gram-moles to kilomoles

Could someone please add pound-moles to gram-mole to kilomole conversions. They're used mostly in chemical engineering.

Here's an exact conversion table:

Unit	lbmol	gmol	kmol
lbmol	1	453.59237	0.45359237
gmol	0.0022046226218	1	0.001
kmol	2.2046226218	1000	1

Yes, the conversions are exactly the same as between lbs, g and kg; the difference would be the names and abbreviations.

Molar flow rate conversions, such as lbmol/min to kmol/hr, would be an awesome addition as well.

thanks, Dude2288 (talk) 21:14, 7 December 2011 (UTC)

The gram-mole is the standard mole, right, so do we need to call it a "gram-mole" ("gmol") or would just "mole" ("mol") suffice? This it the norm in chemistry as far as I know but I'm not any expert on chemical engineering. Also hour is abbreviated "h" not "hr" (I'm sure there's something about this at MOSNUM but I've no time to look it up now) so it'll be "kmol/h". Have you a specific list of molar flow units you're after?

According to Mole (unit)#Other units called "mole" the term "gram-mole" is obsolete.

In the metric system, chemical engineers once used the kilogram-mole (noted kg-mol), which is defined as the number of entities in 12 kg of ¹²C, and often referred to the mole as the gram-mole (noted g-mol), when dealing with laboratory data. However modern chemical engineering practice is to use the kilomole (kmol), which is identical to the kilogram-mole, but whose name and symbol adopt the SI convention for standard multiples of metric units.

May I suggest that we drop the redundant "gram" and simply call the unit a "mole" (unless we're quoting)?

Another question: the section mentioned above gives "lb-mol", "g-mol" and "kg-mol", it gives "lbmol" but doesn't give "gmol", so what do we want here: "lb-mol", "lbmol" or both? I think it would be best to standardise on one or the other and since the mole article uses "lb-mol" why not go with that?

I have added mol, kmol, lbmol, mol/s, kmol/h and lbmol/min but I'm thinking of moving lbmol and lbmol/min to lb-mol and lb-mol/min. Are there any others we need?

I've brought the "lb-mol"-vs-"lbmol" question up at MOS Chem. JIMp _talk·cont 03:14, 8 December 2011 (UTC)

Wow that was faster than I expected. In response to the lbmol vs. lb-mol issue: I've seen it both ways in my textbooks (even lb mol). It's possible there's no "official" standard. I would recommend including both lbmol and lb-mol if you can. If not, my personal preference is for lbmol (similar to lbf (pound force) and lbm (pound mass)).

Secondly, in regards to mol vs. gmol: in chemical engineering contexts it's often important to distinguish gmol from lbmol, because just mol can sometimes be ambiguous (like problems that use customary units and metric). So once again if it's possible to use both, I'd recommend it (with gmol being the same as mol, naturally). Kilogram moles (same as kmol) are also used but this is now officially discouraged so it probably shouldn't be added.

Thirdly, flow rates in seconds, minutes and hours should cover the vast majority of situations. Although there may be a few situations where moles per day (mol and lbmol) might be needed for extremely slow reactions. Lastly, Thanks. -Dude2288 (talk) 06:08, 8 December 2011 (UTC)

A search of WP turned up about a dozen or so instances of the unit with both "lbmol" and "lb-mol" appearing sort of equally (perhaps a slight preference of the hyphenated version), Google gave similar results (about 39 kilohits of "lbmol" vs 46 kilohits for "lb-mol", i.e. rare & leaning towards hyphens). So, "lbmol" is similar to "lbf" and "lbm" ... yeah ... but ... there are dissimilarities ... the pound-mole is more similar to the pound-calorie (a unit like the calorie but defined using the pound instead of the (kilo)gram, "lbf" and "lbm" are the pound as a unit of weight and of mass), which I found one current instance of on WP abbreviated "lb-cal" (and another on old revisions of Calorie (e.g. 30 Jun 2010). Also in favour of the hyphenated version, it seems clearer (to me at least). Just because there is no standard out there doesn't mean we can't make our own ... anyhow, let's not make a mountain out of a mole hill ... let's go with both at least for now and see how things evolve (we can always turn the undersireable one into a redirect).

Okay, I'll add gmol (& g-mol) but, no, I don't see the point of adding the kilogram-mole since surely "kilomole" or "kmol" won't be mistaken for a kilopound-mole.

I'll have a go at those other flow-rate units. JIMp _talk·cont 07:14, 8 December 2011 (UTC)

These should all be working now: mol, gmol, g-mol, kmol, lbmol, lb-mol, mol/s, gmol/s, g-mol/s, lbmol/s, lb-mol/s, mol/min, gmol/min, g-mol/min, lbmol/min, lb-mol/min, mol/h, gmol/h, g-mol/h, kmol/h, lbmol/h, lb-mol/h, mol/d, gmol/d, g-mol/d, kmol/d lbmol/d and lb-mol/d. JIMp _talk·cont 08:19, 8 December 2011 (UTC)

That is the mole, kilomole & pound-mole with each of the discussed symbols (with & without the "g", with and without the hyphen) plus the flow rates derived by dividing these by seconds, minutes, hours and days (I've just added the missing kmol/s and kmol/min). I've also just added SI units appropriate for the very slow kilomole per day, pound-mole per day, mole per hour and the extremely slow mole per day, i.e. millimoles per second (code: mmol/s) and micromoles per second (μmol/s or for ease of input umol/s the output is the same). JIMp _talk·cont 14:24, 8 December 2011 (UTC)

Bug with foot to metre conversion

871 feet (265 m) < 870 feet (270 m) < 890 feet (270 m)

I'm guessing this has to do with the number of significant figures but would suggest that the conversion should always have one more significant figure than the starting value. Longwayround (talk) 12:31, 9 December 2011 (UTC)

Sorry, just read the FAQ on rounding. This does, however, seem to flag up a significant problem (if you will excuse the pun). Longwayround (talk) 12:47, 9 December 2011 (UTC)

Yes, it's due to rounding. The best solution is to specify the precision you're after. Putting one more sig fig than the input would, in general, mean introducing false precision (and would actually solve the "problem" mentioned above). JIMp _talk·cont 23:59, 9 December 2011 (UTC)

Request for gross register tonnage

Would it be possible to add gross register tonnage? In historical ship related articles, like Battle of the Bismarck Sea, my sources quote merchant shipping in gross registered tons. Like nearly all of the old imperial measurements, most readers have no idea what we are talking about. A common confusion is with deadweight tonnage, or displacement, which is the weight of water displaced by the ship in long tons or tonnes, and is used for warships. Gross tonnage is a measure of volume, so it needs to be converted to cubic metres. A gross register ton (grt) is 2.83 m³. At the moment I have to do the calculations and markup by hand. Hawkeye7 (talk) 18:55, 9 December 2011 (UTC)

Done: use grt: {{convert|100|grt|0}} → "100 gross register tons (283 m³)" JIMp _talk·cont 23:51, 9 December 2011 (UTC)

Modification requested ot get rid of zeros

For Victoria, British Columbia#Infrastructure, {{convert|129|eL|cuft}} and/or {{convert|129|eL|cuft|abbr=off}} instead of 129,000,000 litres (4,600,000 cubic feet) similar to 3.355 billion US gallons (12,700,000 m³) or 3.355 billion US gallons (12,700,000 cubic metres) Peter Horn User talk 19:05, 13 December 2011 (UTC)

They already exist. You're missing the sixes (you want to get rid of six zeros) {{convert|129|e6L|cuft}} and {{convert|129|e6L|cuft|abbr=off}} give "129 million litres (4,600,000 cu ft)" and "129 million litres (4,600,000 cubic feet)". JIMp _talk·cont 09:11, 14 December 2011 (UTC)

You might prefer {{convert|129|e6L|e6cuft|abbr=off}}, which gives "129 million litres (4.6 million cubic feet)". JIMp _talk·cont 09:16, 14 December 2011 (UTC)

Thanks, now I see. Peter Horn User talk 22:03, 16 December 2011 (UTC)

Singular "inch"

I'm using this template, in prose, thus: "a 36 inches (91 cm) water main". how can I get it to render as "a 36 inch (91 cm) water main"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 16 December 2011 (UTC)

in this case, it looks like you are using the measurement as an adjective, so try a {{convert|36|in|cm|adj=on}}. Frietjes (talk) 18:06, 16 December 2011 (UTC)

Just so. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:09, 16 December 2011 (UTC)

'Archives' template

The complexities of this page's one-off talk archives template are beyond me; could somebody please modify it to use list markup per WP:HLIST instead of bullet templates? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:33, 16 December 2011 (UTC)

so modified. Frietjes (talk) 18:05, 16 December 2011 (UTC)

Nicely done. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:11, 16 December 2011 (UTC)

Is there a way to specify a range to convert to a range?

For example, what if I want to say 5-10 metres shown in both metres and feet? Shown as something like "5-10 metres (16-33 ft)", or "5 to 10 metres (16 to 33 ft)"?
I have found a number of articles that use ranges like this (such as how tall a plant grows, or a wind speed being described as, say, from 30-40 knots) and require conversion. Is there a way to do it other than having to say convert|5|m|ft to convert|10|m|ft (curly brackets removed so that it will display) - which gives me 5 metres (16 ft) to 10 metres (33 ft)?
I tried putting "5-10" or "5 to 10" in the number parameter but both just came up with errors.
Sorry if this is not the correct place to ask about this :-) -MsBatfish (talk) 11:33, 17 December 2011 (UTC)

Try {{convert|5|-|10|m|ft}} or {{convert|5|to|10|m|ft}}. 174.56.57.138 (talk) 14:17, 17 December 2011 (UTC)

Road salt

For Winter service vehicle#Gritter would it be possible to have the output in lb/1000sqft instead of lb/sqft? What there is now is 10 g/m² (2 lb/1000 ft²) & 40 g/m² (8 lb/1000 ft²). 10 g/m² (0.0020 lb/sq ft) & 40 g/m² (0.0082 lb/sq ft) is not elegant. 10 g/m² (0.018 lb/sq yd) & 40 g/m² (0.074 lb/sq yd) might be workeable but does not yet exist. Peter Horn User talk 21:16, 26 December 2011 (UTC)

Done: lb/sqyd & lb/1000sqft are up & running e.g. "40 g/m² (8.2 lb/1000 sq ft)". JIMp _talk·cont 02:28, 27 December 2011 (UTC)

"Merci buckets" (merci beaucoup) Peter Horn User talk 22:19, 27 December 2011 (UTC)

For "good measure": 10 g/m² (0.29 oz/sq yd) & 10 g/m² (0.033 oz/sq ft) Peter Horn User talk 17:00, 28 December 2011 (UTC)

Capital required at the beginning of a sentence

Winter storm#Snow two inches (5 cm) needs to be capitalized because it is at the beginning of a sentence. Peter Horn User talk 17:03, 28 December 2011 (UTC)

• Use: {{convert/spell |2|in|cm|case=u}} → Two inches (5.1 cm). -Wikid77 19:43, 28 December 2011 (UTC)
• Thanks. Peter Horn User talk 02:13, 29 December 2011 (UTC)

Serious rounding error

Over on Twenty-foot equivalent unit, ""convert|1360|cuft|m3|abbr=on"" gives a value of 39 m³, while ""convert|3604|cuft|m3|abbr=on"" returns 102.1 m³. Correct values (to 3 dp) would be 38.511 m³ and 102.054 m³ respectively. No matter how I look at it, it seems that either the conversion factor in the template is incorrect, or the two calculations are using different rounding criteria (either 0 and 1 dp, or 2 and 4 sf, respectively), which is not explained. Can anyone shed light on this mystery? Rhialto (talk) 08:17, 12 December 2011 (UTC)

The template decides which rounding factor to use based on the number of 0's at the end of the input value. Thus, it rounds to 10's in the first example but to 1's in the second. This is to allow for values like 1,000,000 and 3 to automatically get correct rounding. To force the level of rounding you want, specify the number of digits.

{{convert|3604|cuft|m3|0}} gives 3,604 cu ft (102 m³)

{{convert|1360|cuft|m3|0}} gives 1,360 cu ft (39 m³)

{{convert|3604|cuft|m3|3}} gives 3,604 cu ft (102.054 m³)

{{convert|1360|cuft|m3|3}} gives 1,360 cu ft (38.511 m³)

{{convert|3604|cuft|m3|-1}} gives 3,604 cu ft (100 m³)

{{convert|1360|cuft|m3|-1}} gives 1,360 cu ft (40 m³)  Stepho  talk  09:22, 12 December 2011 (UTC)

What about: {{convert|3604|cuft|m3}} ("sigfig=2" does not show) gives 3,604 cu ft (100 m³)? Peter Horn User talk 17:08, 30 December 2011 (UTC)

As well as {{convert|1360|cuft|m3}} ("sigfig=2" does not show) gives 1,360 cu ft (39 m³), 40 m³ is a tad too high by more than 1 m³. Peter Horn User talk 17:18, 30 December 2011 (UTC)

Convert/spell

For Cold wave#Modern cold waves (2001-date) eight °F (4.4 °C), but spelling Fahrenheit out in full instead of 8 °F (4.4 °C) Peter Horn User talk 18:51, 28 December 2011 (UTC)

eight degrees Fahrenheit change (4.4 degrees Celsius change) does not quite cut it. Peter Horn User talk 19:13, 28 December 2011 (UTC)

• Also omits "Fahrenheit" in: {{convert/spell|8|F-change|1|abbr=out}} → eight degrees Fahrenheit change (4.4 °C). I will check for the missing options. - Wikid77 19:43, 28 December 2011 (UTC)

USE /sandbox versions: I have put corrections in the /sandbox versions (such as "F-change/sandbox") to give the unit name in words. For example:

• {{convert/spell |8|F-change/sandbox|1|abbr=out}} → eight F-change/sandbox
• {{convert/spell |8|F-change/sandbox|1|abbr=off}} → eight F-change/sandbox
• {{convert/spell |1.8|F-change/sandbox|1|abbr=off}} → one point eight F-change/sandbox

The problem, for over 3 years, has been the omission of the unit-code parameters "n=" and plural "l=" in those Convert-unit subtemplates: Template:Convert/C-change, and Template:Convert/F-change. For now, the /sandbox versions have the correct text in the plural "l=" parameters, until the fully-protected templates can be updated. -Wikid77 04:42, 29 December 2011 (UTC)

Have fun. Peter Horn User talk 18:18, 29 December 2011 (UTC)

Capital L required for liter/litre in Convert

For De-ice#Fluid types would now show a lower case "l" 1,500 to 2,000 US gallons (5,680 to 7,570 L; 1,250 to 1,670 imp gal), it should show "L". so I used 1,500 to 2,000 U.S. gallons (5,680 to 7,570 liters; 1,250 to 1,670 imperial gallons) instead for now. Peter Horn User talk 17:18, 29 December 2011 (UTC)

• Specifically use the output combination unit-code as "L impgal" (rather than the defaults), as in the following:

• {{convert|1500|to|2000|USgal|L impgal|sigfig=3|lk=on}} →

1,500 to 2,000 US gallons (5,680 to 7,570 L; 1,250 to 1,670 imp gal).

Both unit-codes, "L" and lower-case "l" are supported. -Wikid77 22:16, 29 December 2011 (UTC)

{{convert|1500|to|2000|USgal|sigfig=3|lk=on}} --> 1,500 to 2,000 US gallons (5,680 to 7,570 L; 1,250 to 1,670 imp gal) gives, by default, only the lower case "l" in the output. Peter Horn User talk 15:54, 30 December 2011 (UTC)

Inches per hour to cm/h or mm/h

For Whiteout (weather): {{convert|1|or|2|in/h|cm/h}} or {{convert|1|or|2|inph|cm/h}} as well as {{convert|1|or|2|in/h|mm/h}} or {{convert|1|or|2|inph|mm/h}} Peter Horn User talk 17:51, 29 December 2011 (UTC) Peter Horn User talk 17:56, 29 December 2011 (UTC)

• The per-hour or "/h" can simulated by inserting mid-text parameters:

• {{convert|1|or|2|in|cm|disp=x| per hour (|}}/h) → 1 or 2 inches per hour (2.5 or 5.1 cm/h)

As long as both units are per-same unit, then just insert the option "disp=x" and text. -Wikid77 22:16, 29 December 2011 (UTC)

Thanks. Peter Horn User talk 15:50, 30 December 2011 (UTC)

How to get rid of a plural if a fraction is less than one unit

Ice storm warning originally read 1/4 inch (6 mm) & 1/2 inch (13 mm) which I changed to {{convert|1/4|in|mm|abbr=on}} {{convert|1/2|in|mm|abbr=on}}, 1⁄4 in (6.4 mm) 1⁄2 in (13 mm) because {{convert|1/4|in|mm}} {{convert|1/2|in|mm}}, 1⁄4 inch (6.4 mm) 1⁄2 inch (13 mm) give an undesired plural and {{convert|1/4|in|mm|sing=on}} {{convert|1/2|in|mm|sing=on}} 1⁄4-inch (6.4 mm) 1⁄2-inch (13 mm) give an, in these cases, undesired "-". Peter Horn User talk 19:05, 29 December 2011 (UTC)

• The new trick is option "adj=1" as in the following:

• {{convert|1/4|in|mm|adj=1}} → 1⁄4 inch (6.4 mm)
• {{convert|15/16|in|mm|adj=1}} → 15⁄16 inch (24 mm)
• {{convert|2+15/16|in|cm|adj=1}} → 2+15⁄16 inches (7.5 cm)

That option "sing=1" (or "adj=1") was added new in recent months because detecting the auto-plural of fractions might exceed the MediaWiki template-nesting limits. -Wikid77 22:16, 29 December 2011 (UTC)

Thanks. Does this also work for other measurements such as "foot" etc? Peter Horn User talk 15:44, 30 December 2011 (UTC)

Use "adj=1" for any unit. -Wikid77 18:01, 30 December 2011 (UTC)

There is a bit more to it: For Freezing rain advisory {{convert|1/4|in|mm|adj=1|disp=s}} --> 1⁄4 inch (6.4 mm) or/and {{convert|1/4|in|mm|adj=1|disp=or}} --> 1⁄4 inch or 6.4 millimetres. -<unsigned> (Peter Horn User talk 18:46, 30 December 2011 (UTC))

• DONE. I have implemented "disp=or" and "disp=s" and the general-case customized "disp=x" to work when "adj=1". -Wikid77 18:01, 30 December 2011 (UTC)

Thanks, it was I who forgot to sign my previous posting. Peter Horn User talk 18:46, 30 December 2011 (UTC)

Common fractions in the output

In Blizzard it now reads 400 meters or ¼ mile. {{convert|400|m|mi|sp=us}} --> 400 meters (0.25 mi) does not give the output as {{frac|1|4} mi --> 1⁄4 mi. Is this possible? Peter Horn User talk 19:21, 29 December 2011 (UTC) Peter Horn User talk 17:55, 30 December 2011 (UTC)

• No result fractions. Template:Convert cannot show output-unit fractions, so far, as the additional complexity has been too much for the template-nesting limits (WP:Expansion depth limit). Perhaps a wrapper template could be created to handle that complexity. -Wikid77 22:16, 29 December 2011 (UTC)
• A lot to chew on. Peter Horn User talk 15:46, 30 December 2011 (UTC)
• This issue was sort of touched on in Template talk:Convert#Range conversion issue above in connection with a proposed converting of millimetres to fractions if inches. Peter Horn User talk 17:55, 30 December 2011 (UTC)

Strange

Supercell#Features of a supercell, {{convert|40,000|-|60,000|ft|m|sigfig=3}} --> 40,000–60,000 feet (12,200 ). What gives? Peter Horn User talk 20:41, 30 December 2011 (UTC)

• The 2nd amount in Convert cannot have a comma, so use Convert/2:

• {{convert/2 |40,000|-|60,000|ft|m|sigfig=3}} → {{convert/2|40,000|-|60,000|ft|m|sigfig=3}}

Any commas in the 1st amount are removed for calculations, but not from the 2nd amount unless using Convert/2. -Wikid77 16:21, 31 December 2011 (UTC)