Template talk:Convert/Archive August 2010

Acre feet

Is there a conversion for "acre feet"? It is used often to describe reservoirs and I have to convert it to much longer numbers (m3, ft3, yd3)) in infoboxes and articles. If there isn't, can one be created--NortyNort (Holla) 08:20, 28 July 2010 (UTC)

Have you looked at the FAQs at the top of the page, followed the links and checked here? The default conversion is m³. If that is cumbersome, try megalitres or gigalitres, depending on the size of your puddle. BTW, I don't think wp:mosnum supports converting one non-metric unit to yet another (cubic feet or cubic yards). Bleakcomb (talk) 02:44, 30 July 2010 (UTC)

Yes, use acre.ft e.g. {{convert|1.00|acre.ft}} → "1.00 acre-foot (1,230 m³)". I don't think there's anything Mosnum says (nor should say) against converting from a non-metric unit to another as long as the appropriate metric conversion also exists. JIMp _talk·cont 19:37, 30 July 2010 (UTC)

According to NIST Special Publication 811 [1] page 45, The conversion to Acre Feet is 1.233 489 E+03 m3. Metricmike (talk) 01:52, 2 August 2010 (UTC)

Acre(s)

The acre in the United States is based on the original Survey Foot in use until 1959 [2] page 42. The correct conversion according to NIST is 4046,8726098 square meters to the Acre [3] page 45. It would be helpful if the conversion could be corrected. Presently there is an error of about 5 km2 for the area of Northern Virginia when using the Convert Template. Note that the Acre in other parts of the world might differ. Metricmike (talk) 01:46, 2 August 2010 (UTC)

In fact, the acre might differ in surveys in different parts of the US. According to Survey foot, Twenty-four states have legislated that surveying measures should be based on the U.S. survey foot, eight have legislated that they be made on the basis of the international foot, and eighteen have not specified the conversion factor from metric units, so by implication different American states could have different sizes of acres. The difference is between the survey foot and the international foot is around 2 parts per million, so it is not usually significant. The pre-1959 British imperial foot was different from the American survey foot by about 3.7 ppm. Fortunately, the square kilometre is the same in all surveys.RockyMtnGuy (talk) 05:45, 2 August 2010 (UTC)

Rounding to the nearest 5

An editor is saying that the convert template gives the "wrong conversion" on the basis that "85kts which equals 155km/h and not 160km/h". He has removed other instances of the template on that basis. Please see the discussion at User_talk:Jason_Rees#Arithmetic (and his previous discussion User_talk:Jason_Rees#Hurricane_Grace). Is it possible to make the template round to the nearest 5 km/h (which I think is his preferred precision)? Lightmouse (talk) 22:02, 2 August 2010 (UTC)

Yes, any typical conversion can be rounded to the nearest 5 by using new option "disp=5". For 85 knots (kn):

• {{convert|85|kn|km/h|disp=b}} → 85 knots (157 km/h)
• {{convert|85|kn|km/h|disp=5}} → 85 knots (155 km/h)
• {{convert|85|kn|km/h|disp=5|lk=in}} → 85 knots (155 km/h)
• {{convert|94|kn|km/h|disp=5|lk=on}} → 94 knots (175 km/h)

I need to have put disp=5 in the documentation because many people are thinking to use such an option, for general rounding to nearest 5, as in engineering data. -Wikid77 (talk) 06:23, 4 August, revised 07:12, 4 August 2010 (UTC)

Thanks. I hope that resolves the issue for the editor that wanted it. Lightmouse (talk) 15:33, 4 August 2010 (UTC)

A "round" parameter is needed with four specific values to change default rounding behavior

We need a |round= option with values of normal (the default: round 1-4 down, 5-9 up), down (always round down), up (always round up), and split (round 1-4 down, 6-9 up, and add 5 explicitly, regardless of precision and sigfig settings. One obvious use of this would be to prevent giving blatantly false information because of rounding: The tournament's minimum cue stick length is {{convert|41|inch|cm|sigfig=4}} results in "The tournament's minimum cue stick length is 41 inches (104.1 cm)", a mathematically rather precise, and completely normally rounded, but factually incorrect statement (104.140 cm is the completely accurate equivalent of 41 inches; but the rounded result of 104.1 is actually slightly smaller than the minimum of 41 inches, and thus an illegal value). Any Wikipedian relying upon this information (say, flying to Vegas to compete in a pool tournament) could be in for a nasty and expensive real-world disqualification surprise. Adding the proposed |round=up would force a just-over-legal-minimum value of 104.2 to appear here, at the cost of a tiny amount of mathematical precision. Similar cases exists, of course, for forcing the rounding down, to fit within a maximum rather than a minimum. In contexts in which things are counted/measured in halves, the |round=split option would, for values of 4.4, 4.5, and 4.6, respectively, produce output of 4, 4.5, and 5. It should work with precision/sigfig down into the decimals such that .44, .45 and .46 would yield .4, .45, .5, without padding the .4 and .5 with trailing zeros. That is, the .05 would be forcibly added to the .4 at a precision that normally would have called only for .4 or .5. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 07:03, 27 July 2010 (UTC)

No. Any Wikipedian deliberately putting in four significant figures to a value that has only two, and then rounding that figure, deserves to have his cue stick broken in twain, it hung around his neck and he be cast into the deepest ocean. The same Wikipedian could just as easily write "41 inches (37 cm)" straight out in the article and cause the same confusion. The template should guard against foolishness, but damnfoolishness isn't a concern. Si Trew (talk) 07:33, 27 July 2010 (UTC)

Thanks for the civility. Calling other editors damn[ed] fools isn't constructive. Please re-read what I wrote; you totally missed the point. And "use it my way or don't use the template" is a non-helpful attitude. The problem is not that "fool" editors are putting 4 sigfigs to a value they know has two, it's that we don't generally know what the result will be until the template has been used, it is ridiculously tedious to give a bunch of different sigfigs for a series of, say, 20 numbers a few of which will end up with pointless zeros trailing the right-hand side of the decimal, and worst yet, the results can be factually incorrect in subtle ways in the context. Not a case of operator error (it generally is not at all appropriate (per WP:MOSNUM) to do something like {{41|inch|cm|sigfig=7}}), but of template limitations. And if the template is so brittle that a "don't use the template, and write stuff out manually instead" position is your default response, then the template needs work even more than I initially thought it did. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 12:01, 27 July 2010 (UTC)

Sorry, I meant "foolishness" and "damfoolishness" somewhat tongue in cheek and was (mis)quoting someone, but I forget whom. I kinda agree with you that the "suck it and see" approach is unfortunate. That being said, it is incumbent on editors to ensure that the content on articles is correct, and I check that the output of {{convert}} seems sensible just as I check the output of any other template I use (which is not to say that I always get it right, but I don't just blindly assume that I get the template transclusion right first time). While I do tend to use {{convert}} by "default", if there are formatting issues and so on that it can't do, then there's nothing to stop the conversion being written longhand. I could see the point of a kinda {{convert needed}} template working a little like the {{lang}} template in marking text into a hidden category. Although "needed" might not be the right word: {{could convert}} or something like that. What do you think? Si Trew (talk) 04:33, 10 August 2010 (UTC)

Comma should be replaced by space as thousands separator

In a lot of places, comma is the decimal separator. 1,234.567 can mean either ~1 or ~1 235. A better way of writing that number is like this: 1 234.567 or 1.234 567. See Decimal separator for more info. --Potatis invalido (talk) 00:43, 10 August 2010 (UTC)

In most of the Englsish-speaking world, commas are used as thousands separators, as listed in that article in section Decimal separator#Countries using Arabic numerals with decimal point. I see little confusion, then, with it being taken to mean the decimal separator/radix point, in the English Wikipedia. It is unambiguous in your example 1,234.567 because it's rare to write thousands separators after the decimal point (whatever the SI or other style guides say). Si Trew (talk) 04:20, 10 August 2010 (UTC)

In any case, the place to discuss this would be WT:MOSNUM, not this specific template. Si Trew (talk) 04:23, 10 August 2010 (UTC)

Indeed, changing the template to what is perceived as a completely neutral solution is one of those periodical requests, but as Simon points out, it is neither truly neutral nor reasonable, considering 1,234.567 is the primary style in the English language. — Huntster (t @ c) 04:30, 10 August 2010 (UTC)

lb/gal

When I try

• {convert|19.6|lb/USgal|kg/L}

I get

• 19.6 pounds per US gallon (2.348598 kg/L)

Have I misunderstood or is there a particular reason why 3 significant figures on the input produces 7 significant figures on the output? Regards Lightmouse (talk) 12:15, 30 July 2010 (UTC)

I see that somebody must have fixed this. It works fine now. Thanks. Lightmouse (talk) 17:14, 13 August 2010 (UTC)

New option disp=x to customize output

After years of considering other options, I have begun implementing new option "disp=x" (such as "disp=x| << | >>") to insert custom text/separators around the output amount. Here are some live examples (but other units must be changed to support the text parameters 4&5):

• {convert|5|mi|km|disp=x| [ | ] } → 5 miles [ 8.0 km ]
• {convert|5|mi|km|disp=x|; } → 5 miles; 8.0 km
• {convert|88|m|ft|disp=x| {equals |} } → 88 metres {equals 289 ft}
• {convert|3|mi|km|disp=x| (equals |, others likewise) } → 3 miles (equals 4.8 km, others likewise)

Any spaces in those parameters will appear in the output. This new option disp=x will allow editors to vary the wording, to avoid monotonous repetitions, and perhaps combine live conversions with other hand-coded numbers as the customized text.

More subtemplates must be created to allow the option disp=x to work in ranges or non-abbreviated units. The concept of customizing the output format has been considered for years, but the former stumbling block had been the end-round parameter "|1" which is treated here as parameter 6 when disp=x, and that allows customization to proceed. I have been studying this issue for years, so I don't forsee any major complications, for general usage of disp=x. However, more unit-subtemplates will need to be updated to pass parameters 5/6/7 so that the ending text can be specified for any unit, not just for miles, feet, or metres. Also, we might be able to replace disp=s using disp=x and reduce perhaps a few hundred other subtemplates that are not used very much, as being deprecated, in favor of using disp=x. More later. -Wikid77 (talk) 00:09, 13 August 2010 (UTC)

• There seems to be a bug where a leading semicolon ";" is being treated as the bolded-header option: a semicolon starting a line is parsed by the MediaWiki markup parser as meaning "treat text after semicolon as a bolded header". Apparently, this bug stems from the MediaWiki pre-formatting of text within an if-expression (such as "{{#if:{{{4|}}}|...}}") to remove leading or trailing spaces within the then/else clauses of the if-logic, even though parameters can pass leading/trailing spaces as long as not within a markup if-expression. However, I am not sure if the obsession with semicolon-headers is triggered somewhere else in the nested Convert subtemplates. Note, these issues, about handling spaces, had been carefully decided over 30 years ago by hundreds of computer scientists; however, each generation of people must re-learn the technical gotchas, and such learning seems faster in friendly collaboration with older experts, not likely these days. Anyway, avoiding the use of if-expressions to display parameters will allow those parameters to pass leading/trailing spaces, such as for customizing the separators around the converted output amount. More later. -Wikid77 (talk) 15:47, 13 August 2010 (UTC)

Not abbreviating output

Is there a way of NOT abbreviating the output? E.g. 100 kilometres (62 mi) so that the output reads 62 miles. Peter Horn User talk 02:39, 13 August 2010 (UTC)

• Reminder: Use abbr=none (because the default, abbr=off means abbr=out); abbr=none works with almost all other options:

{convert|100|km|mi|abbr=none} → 100 kilometres (62 miles)

{convert|100|km|mi|abbr=none|adj=on} → 100-kilometre (62-mile)

{convert|100|km|mi|abbr=none|lk=out} → 100 kilometres (62 miles)

The limitation is abbr=comma, which blocks using abbr=none.

{convert|4321|km|mi|abbr=comma} → {{convert|4321|km|mi|abbr=comma}}

{convert|4321|km|mi|abbr=none|lk=in} → 4,321 kilometres (2,685 miles)

Again, abbr=off has been the default (for years), but generates abbr=out as being the original style, even though abbr=off sounds the same as "none", internally, the "off" means to "use the default style" which is abbr=out. -Wikid77 (talk) 12:54, 13 August 2010 (UTC)

New adj=nocomma to omit commas

13-Aug-2010: I have begun implementing new option "adj=nocomma" to omit commas from numbers, while allowing any abbr=xx. This option is needed because the prior option, "abbr=comma" (to suppress commas in numbers) has blocked the use of abbr=none or abbr=on (etc.). Now:

• {convert|4300|km|mi|abbr=none}              → 4,300 kilometres (2,700 miles)
• {convert|4300|km|mi|abbr=none|adj=nocomma} → {{convert|4300|km|mi|abbr=none|adj=nocomma}}
• {convert|4300|km|mi|abbr=on}                → 4,300 km (2,700 mi)
• {convert|4300|km|mi|abbr=on|adj=nocomma} → {{convert|4300|km|mi|abbr=on|adj=nocomma}}

Perhaps the use of abbr=comma should be deprecated, then those subtemplates could be deleted. We cannot yet have a dedicated option "comma=no" due to the complexity of updating Template:Convert to pass a new parameter (named "comma") into the ~3,300 current Convert-subtemplates. Consequently, other parameters are being "over-loaded" to handle multiple functions, with the intention to not block the most typical uses of a parameter while giving it a new function. This has resulted in playing Convert-Chess, to plan several moves ahead to imagine the impact when multiple options are used in various ways, and try to predict which possible option "moves" should be anticipated in the long-term Chess game of maintaining the thousands of Convert subtemplates. Due to that complexity, using an option such as "adj=nocomma" might be a better move than using "abbr=comma" in the long term. Many people have asked for simpler parameters; however, due to the current complexity, it would take multiple man-years (40 hours per week) to rewrite (and document) Convert to provide most of the clear options that people have requested. Meanwhile, people are encouraged to hand-code special conversions until more features (for customization) can be added to Convert. -Wikid77 (talk) 14:59, 13 August 2010 (UTC)

Fractional output options are needed

We need an option for fractional output. The vast majority of uses of non-whole-integer inches are in fractional values (e.g. 7/16"), not decimal. Very few regular users of inches would even recognize something like 5/8" expressed as a decimal value. We'd need some kind of rubric for this, like maybe using rounding math to push the number to the closet fraction, with 32nds being the smallest by default, but it could be manually allowed to go smaller (128ths or whatever). It should reduce the fraction automatically, but have an option to not do so (e.g. for a context where everything is specified in 16ths or whatever). So, this is probably three parameters: |fracout=yes (default = no), |fracdepth=a positive power of 2 (default = 32), |fracreduce=no (default = yes). — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 07:03, 27 July 2010 (UTC)

There's a discussion at WT:MOSNUM#Fractions you may wish to contribute to. Si Trew (talk) 07:39, 27 July 2010 (UTC)

I'll take a look at it. I'll warn that if it has something to do with banning fractions on Wikipedia, I'm not interested. MOSNUM and other WP:MOS progeny see plenty of "let's pretend reality doesn't exist" arguments all the time. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 12:25, 27 July 2010 (UTC)

• Currently, Template:Height displays fractions of an inch, as output:

{Height|m=2.345} → 2.345 m (7 ft 8+1⁄2 in)

{Height|m=2.341} → 2.341 m (7 ft 8 in)

{Height|m=2.326} → 2.326 m (7 ft 7+1⁄2 in)

Also, we can convert spanners (wrenches):

{convert|11|spanner} → 11 spanner

{convert|15|spanner} → 15 spanner

{convert|3/4|spanner|mm} → 3⁄4 spanner

{convert|1/8|spanner|mm} → 1⁄8 spanner

Otherwise, a separate template should be developed, as a proof of concept, to determine potential pitfalls, before including such functionality into Convert. By counting the what-links-here links to the new template, we could estimate the predicted usage of those features. I agree that it makes sense, in the real world, however, many articles written here tend to be as unreal as some restrictions in the policies. For example: WP:BATTLE has been used to condemn an isolated person for "battleground-mentality" as though the others in the "battle" aren't battling, but there is no policy WP:GETREAL to condemn a person for imagining 1-person battles. Also, consider for example, if an article written in English is translated to German (French or Swedish) but only 99.9% correctly, then German (French or Swedish) Wikipedia users might complain it wasn't perfect and request such articles be refused. -Wikid77 (talk) 04:51, 15 August 2010 (UTC)

Error

Hi. I know you're thinking on reminding me of "rounding", but this is a slightly different error.

{{Convert|5|ft|10|in|cm}} tells me that it is equal to 170cm. However, {{Convert|178|cm|ft}} tells me that it is 5' 8.4". Is there any way to get the metric measurement to display the correct imperial equivalent?-- OsirisV (talk) 14:55, 11 August 2010 (UTC)

No it doesn't {{convert|5|ft|10|in|cm}} says that it's 178 cm, and {{convert|178|cm|ft}} says that it is 178 centimetres (5.84 ft), which it is (not 170).

If you want it in feet and inches, use {{convert|178|cm|ftin}}, which produces 178 cm (5 ft 10 in). Si Trew (talk) 15:01, 11 August 2010 (UTC)

Sorry, that was itself an error. I meant 178 always.-- OsirisV (talk) 15:08, 11 August 2010 (UTC)

Based on that, I would assume that ".84" is 84% of a foot and not 8.4 inches. Sorry to waste your time if it is.-- OsirisV (talk) 15:09, 11 August 2010 (UTC)

Yes, it is. DOn't worry, not timewasting – I myself only discovered ftin a couple of months ago. I did imagine 170 was a typo, but was just making that clear in my response. Si Trew (talk) 06:27, 15 August 2010 (UTC)

Updated doc for disp=x and disp=flip

I have begun updating the doc subpage (Template:Convert/doc) to show other options, which had been omitted since November 2009 or later. -Wikid77 (talk) 06:08, 15 August 2010 (UTC)

Order of entries

It should be possible to request an inverted order, the conversion first and the convertee second. This is often useful for the conversion of american english units to international standard ones. —Preceding unsigned comment added by Tomdo08 (talk • contribs) 11:18, 14 August 2010 (UTC)

This would be useful for me too in automobile articles. Quite often I get figures from different parts of the world (eg length of sedan from US, length of coupe from Japan) and I would love to make a table or infobox with SI units consistently on the left side.  Stepho  (talk) 00:02, 15 August 2010 (UTC)

• That option is "disp=flip" to flip-and-reverse the order:

{convert|6|km|mi}                  → 6 kilometres (3.7 mi)

{convert|6|km|mi|disp=flip}     → 3.7 miles (6 km)

{convert|6|km|mi|disp=flip|abbr=in} → 3.7 mi (6 kilometres)

Because disp=flip is overloading the use of option "disp=" then it blocks the use of "disp=x" at the same time. -Wikid77 (talk) 03:07, 15 August 2010 (UTC)

Thank you.  Stepho  (talk) 07:02, 16 August 2010 (UTC)

temperatures

There is an inconsistency with temperatures. Positive temperatures default to integers. Negative temperatures default to one decimal place.

• {convert|-1|F|C} -> −1 °F (−18.3 °C)
• {convert|1|F|C} -> 1 °F (−17 °C)
• {convert|-1|C|F} -> −1 °C (30.2 °F)
• {convert|1|C|F} -> 1 °C (34 °F)

Can we make integer the default for them all? Regards Lightmouse (talk) 20:21, 1 August 2010 (UTC)

Update: That complex problem was fixed on 17Aug2010:

• {convert|-1|F|C} → −1 °F (−18 °C)

Other examples are further below. -Wikid77 (talk) 23:10, 17 August 2010 (UTC)

I had proposed that too and that too was unanswered. (More specifically, I had proposed that the conversion should have the same number of digits after the decimal point as the input value.) A. di M. (talk) 15:42, 4 August 2010 (UTC)

Remind me, what is the change of temperature template. A change of 10° C or 18° F. Peter Horn User talk 00:50, 13 August 2010 (UTC)

Never mind, I found it. For Mud volcano#Azerbaijan, 2–3 °C (3.6–5.4 °F) instead of 2 °C (3.6 °F) - 3 °C (5.4 °F) Peter Horn User talk 02:17, 13 August 2010 (UTC)

Does anyone else have a comment on the original issue? Lightmouse (talk) 17:16, 13 August 2010 (UTC)

• There seems to be a major bug inside the Convert subtemplates, where negative numbers generate the wrong precision. I have created a new Template:Getprecision which will correctly handle negative numbers (such as negative temperatures).

• {precision/+ | -1450.25} → {{precision/+| -1450.25}}
• {getprecision| -1450.25} → {{getprecision| -1450.25}}

However, it could require days (or weeks) to get that new template {getprecision} used inside the Convert subtemplates, specifically inside Template:Convert/roundT1, and check that the template-nesting limits are not exceeded. I don't want to seem "slow-moving" but there are multiple changes happening at the same time, and it takes all of us working together to make progress. Thanks for reporting these issues: the task of numerical conversions is so vast, such an extensive project, that Convert could only exist, at this point, with unfinished sections and ongoing improvements: it would have taken years to develop a fully-tested Convert, so the recent problems are the tradeoff, to have Convert working part-way, in less than 5 years.-Wikid77 (talk) 06:17, 16 August 2010 (UTC)

Update: That complex problem was mostly fixed on 17Aug2010, except for negative integer as C-to-F degrees:

• {convert|-1|F|C} → −1 °F (−18 °C)
• {convert|-1|C|F} → −1 °C (30 °F)
• {convert|-5.25|F|C} → −5.25 °F (−20.69 °C)
• {convert|-212.0|F|C} → −212.0 °F (−135.6 °C)
• {convert|-150.5|C|F} → −150.5 °C (−238.9 °F)

The rounding (for precision) is an extremely complex issue, but fortunately, the cause was detected (as being an internal precision error) and is being corrected rapidly. -Wikid77 (talk) 23:10, 17 August 2010 (UTC)

Thanks. I appreciate the work that goes on, even if not visible to most of us. Lightmouse (talk) 12:28, 20 August 2010 (UTC)

Arpent

In Timeline of Montreal history: 1 Arpent#Unit of area & 1 Arpent#Unit of area. 1 Arpent#Unit of length or 1 Arpent Peter Horn User talk 00:20, 6 August 2010 (UTC)

I have created Template:Convert/arpent for area units, as arpents in Canada:

• {convert|1.00|arpent|ha} → 1.00 arpent (0.34 ha)
• {convert|1.00|arpent|acre} → 1.00 arpent (0.84 acres)
• {convert|1.00|ha|arpent} → 1.00 hectare (2.9 arpents)

Using "arpent" for units of area, I'm not sure what to name the arpent unit of length, or whether to use "square arpent" for the area unit code, instead. -Wikid77 (talk) 11:54, 9 August 2010 (UTC)

use sq. arpent for the area unit code. Peter Horn User talk 00:44, 13 August 2010 (UTC) Or rather sq arp. Peter Horn User talk 02:31, 13 August 2010 (UTC)

Okay, use "sq_arp" - {convert|1.0|sq_arp|acre} → 1.0 arpent (0.84 acres). -Wikid77 (talk) 02:59, 14 August 2010 (UTC)

What about dual conversions, say 1 arpent (0.8 acres; 0.3 ha) 1 acre (1.2 arpents; 0.4 ha)? etc. Peter Horn User talk 02:31, 13 August 2010 (UTC) See also Arpent#Unit of area as well as Arpent#Arpents in U.S. land descriptions (Louisiana) & French units of measurement#Area Peter Horn User talk 20:19, 13 August 2010 (UTC)

I will work on fixing the internal typo "mulit" (should be "multi2") in the 2-unit "acre ha" but already, the reverse units as "ha acre" are working:

• {convert|1|sq_arp|ha acre|1} → 1 arpent (0.3 ha; 0.8 acres)

However, some special cases might be better if written as hand-coded text, due to all the slight differences in arpent sizes; also, I think Rome used an arpent, which would become Template:Convert/Roman_arpent, if there are enough instances where it would be used. Most of the enwiki WP articles consider "arpent" to be the small acre of area, rather than a unit of length of about 192 ft. -Wikid77 (talk) 02:59, 14 August 2010 (UTC)

Thanks. Peter Horn User talk 21:18, 16 August 2010 (UTC)

'Munit' versus 'e6unit'

If I want to show 320 m³ in US units, I can use 'k' for 'thousand barrels':

• {convert|2|koilbbl|m3} 2 thousand barrels (320 m³)

or 'e3' for 'thousand gallons'

• {convert|84|e3USgal|m3} 84 thousand US gallons (320 m³)

But I can't use 'e3' for 'thousand barrels' or 'k' for 'thousand gallons'.

• {convert|2|e3oilbbl|m3} 2 thousand barrels (320 m³)
• {convert|84|kUSgal|m3} 84 kUSgal

I know this is something that has grown over time and it isn't a big deal but I'm just raising the inconsistency. Lightmouse (talk) 16:28, 4 August 2010 (UTC)

Does anyone have an opinion on how to resolve this inconsistency? Lightmouse (talk) 17:11, 13 August 2010 (UTC)

I'd welcome a discussion on this issue. Is it possible or desirable to roll these options out to all units? Lightmouse (talk) 19:30, 25 August 2010 (UTC)

Full list of all units

It's been suggested that my bot application (Wikipedia:Bots/Requests for approval/Lightbot 4) be constrained to units handled by the convert template. The page 'Template:Convert/list of units' has a list and refers to sublists. Is it automatically updated and comprehensive? Lightmouse (talk) 16:14, 15 August 2010 (UTC)

Keeping a comprehensive list is difficult. One way to generate such a list would be to parse the list of subpages with some regular expressions. Then there is a list of all the possible unit conversion combinations. I know Wikid77 once came up with an estimate on the total possible number at one point, it was very large. Are you just looking for the list of recognized units, or the list of possible conversion combinations? Plastikspork _―Œ^(talk) 15:10, 25 August 2010 (UTC)

Well, some have asked for a simple list of units, then some have asked for a list of all conversion permutations. I can see that it would be easier to do the former than the latter, so could we start with the simple list? I can't predict what will be asked for next, the original application (link above) got too crazy so I closed it and started a much simpler one just to convert feet and miles. Feel free to look in at the bot application at Wikipedia:Bots/Requests for approval/Lightbot 5. I'd welcome input there. Regards Lightmouse (talk) 19:28, 25 August 2010 (UTC)

Support for short forms of numbers (e.g. k/m/bn)

It would be good if this template could handle short forms of numbers - such as £1.5m for 1.5 million etc. -- Eraserhead1 <talk> 09:48, 21 August 2010 (UTC)

Mysterious 'sized' shows up in output

{{convert|2|to|3|ft|m|adj=mid|-wide}} produces "2-to-3-foot-wide (0.61 to 0.91 m)" – that's OK.

{{convert|2|to|3|in|mm|adj=mid|-wide}} produces "2-to-3-inch-sized (51 to 76 mm)" – huh?

What's good for feet should be good for inches, no? Chris the speller (talk) 17:36, 21 August 2010 (UTC)

• I will submit an update to fix {Convert/in} for adj=mid. For now, use "inch" as the unit:

{convert|2|to|3|inch|mm|adj=mid|-wide} → 2-to-3-inch-wide (51 to 76 mm)

The subtemplates need to pass 7 numbered parameters to allow adj=mid. -Wikid77 (talk) 11:27, 25 August 2010 (UTC)

Your fix worked. Thanks much. Chris the speller (talk) 00:12, 26 August 2010 (UTC)

Parameter adj=mid fails with two input values in feet and inches

{{convert|6|ft|5|in|m}}   works OK:   6 feet 5 inches (1.96 m)

{{convert|6|ft|m|adj=mid|-wide}}   works OK:   6-foot-wide (1.8 m)

{{convert|6|ft|5|in|m|adj=mid|-wide}}  fails:   Template:Convert/LoffAoffDbSmid2

I am almost certain that this used to work. Well, maybe I'm nuts. If so, would this be hard to fix? Chris the speller (talk) 17:40, 22 August 2010 (UTC)

• I am working to allow adj=mid in 2-unit input:

{convert|6|ft|5|in|m|adj=mid|-wide} → 6-foot-5-inch-wide (1.96 m)

This 2-unit adj=mid has not been possible before. -Wikid77 (talk) 11:27, 25 August 2010 (UTC)

C-change still broken?

It looks like this dual conversion problem from 2008 is still occurring. {{convert|74|+/-|18|C-change}} produces:

74 ± 18 °C (133 ± 32 °F)

If I try to explicitly request F-change as the output type, it doesn't fail, but no conversion is done and the units are C-change and F-change:

74 ± 18 °C (133 ± 32 °F)

-- Autopilot (talk) 23:44, 22 August 2010 (UTC)

• I am working on a fix for C-change ranges. -Wikid77 (talk) 11:27, 25 August 2010 (UTC)

Bq (bequerel) and ranges

Looks like there's something wrong with simple (10⁰) bequerels and ranges:

1. {{convert|5500|Ci|Bq}}: 5,500 curies (2.0×10¹⁴ Bq)
2. {{convert|12000|Ci|Bq}}: 12,000 curies (4.4×10¹⁴ Bq)
3. {{convert|5500|to|12000|Ci|Bq}}: 5,500 to 12,000 curies (2.0×10¹⁴ to 4.4×10¹⁴ Bq)
4. {{convert|5500|to|12000|Ci|TBq}}: 5,500 to 12,000 curies (200 to 440 TBq)

If only i can see a problem: 1, 2 and 4 work fine, 3 give an error, output is : ' 5,500 to 12,000 curies (Expression error: Unrecognised word "span" to Expression error: Unrecognised word "span" Bq)' with lots of red. (values from Green Run.)--ospalh (talk) 11:42, 26 August 2010 (UTC)

Now my suspicion is that it's use of a small unit that's shown as "X × 10^y together with a range that causes a problem. For example converting tens of thousands of tonnes to microgrammes fails in the same way:

5.{{convert|34000|to|50000|tonne|µg}}: 34,000 to 50,000 tonnes (3.4×10¹⁶ to 5.0×10¹⁶ μg)

ospalh (talk) 19:59, 26 August 2010 (UTC)

• I agree that very large numbers in ranges seem to cause the error. Examples:

{convert|5500|to|1200|Ci} → 5,500 to 1,200 curies (204,000 to 44,000 GBq)

{convert|5500|to|1200|tonne} → 5,500 to 1,200 tonnes (6,100 to 1,300 tons)

{convert|5500|to|1200|tonne|ST} → 5,500 to 1,200 tonnes (6,100 to 1,300 short tons)

{convert|5500|to|1200|tonne|lb} → 5,500 to 1,200 tonnes (12,100,000 to 2,600,000 lb)

{convert|5500|to|1200|tonne|µg} → 5,500 to 1,200 tonnes (5.5×10¹⁵ to 1.2×10¹⁵ μg)

{convert|11|to|9|tonne|g} → 11 to 9 tonnes (11,000,000 to 9,000,000 g)

{convert|999|to|1|tonne|g} → 999 to 1 tonne (999,000,000 to 1,000,000 g)

For now, try to rewrite conversions to use larger units, with smaller amounts less than 999 million, or split ranges as separate conversions? I think it might take a long time to fix this problem. -Wikid77 (talk) 16:43, 28 August 2010 (UTC)

disp=tablecen for acre / hectare

Would someone be so kind as to allow tablecen to convert ha to acre and acre to ha? disp=table is a bit of a hassle to use in a table I'm working on. Much appreciated. _EricLeb⁰¹ (Page | Talk) 21:03, 27 August 2010 (UTC)

I have fixed it. Examples using "disp=tablecen" with acre:

*{{convert|9|ha|acre|disp=b}} → 9 hectares (22 acres)

*{{convert|9|ha|acre|disp=tablecen}} → style="text-align:center;"|9

|style="text-align:center;"|22

*{{convert|7|acre|ha|disp=b}} → 7 acres (2.8 ha)

*{{convert|7|acre|ha|disp=tablecen}} → style="text-align:center;"|7

|style="text-align:center;"|2.8

Thanks for noting "disp=tablecen" did not allow acres. -Wikid77 (talk) 20:06, 28 August 2010 (UTC)

A thank you for fixing it is much more required! Very quickly, as well. _EricLeb⁰¹ (Page | Talk) 20:29, 28 August 2010 (UTC)