Template talk:Convert/Archive March 2011

suggested addition to convert USgal/d

I would like to see "gallons per day" added to the river templates because most information is given in that format instead of "cubic meters per second" and appropriate conversions to convert between these items. 21:39, 2 March 2011 (UTC) —Wheller007 (talk • contribs)

• When the "per-unit" text does not change (such as "per day"), then insert the phrase "per day" into the conversion using option "disp=x" as follows:
    • {{convert|55,000|USgal|L|disp=x| per day (}} per day)
                → 55,000 US gallons per day (210,000 L per day)
  Using that approach, any qualifier can be appended, such as "per hour" or "per week" or "per swimming pool". There is no need to wait to have a special conversion, just use "disp=x" to customize the output for a large variety of related conversions. -Wikid77 23:45, 2 March 2011 (UTC)

I believe that the desired conversion is between different denominators, however; AFAICT he wants something like 123,456,789 gal/day (234.567 m³/s), not gallons/second → cubic metres/second. Happy‑melon 00:03, 3 March 2011 (UTC)

2,400 US gallons per day (0.00011 m³/s) How's this? JIMp _talk·cont 04:43, 3 March 2011 (UTC)

• Thank you. I changed to allow sp=us, so "U.S." can be shown if preferred in each article:

• {{convert|2400|USgal/d|sp=us}} → 2,400 US gallons per day (0.00011 m³/s)

• {{convert|2400|USgal/d|sp=en}} → 2,400 US gallons per day (0.00011 m³/s)

• {{convert|123,456,789|USgal/d}} → 123,456,789 US gallons per day (5.4089674 m³/s)

Infobox_river: I have checked Template:Infobox_river to see where the internal change is needed, plus more doc text, to support the new "USgal/d" as a unit-code. At infobox row 9, "data9" allows using either parameter name "discharge_cuft/s" or "discharge_m3/s" to invoke {Convert}. I would recommend a new parameter "discharge_unit" to be whatever unit-code, such as new "USgal/d" and call the amount parameter "discharge" in that case. This would go to Template_talk:Infobox_river.

Mahoning: In article "Mahoning River", the discharge rate can be sourced to the USGS webpage "http://waterdata.usgs.gov/usa/nwis/uv?03094000" containing:
     Discharge, cubic feet per second
           Most recent instantaneous value: 1,840     03-03-2011   07:00 EST
           Daily discharge statistics, in cfs, for Mar 3 based on 43 years of record
On that webpage, the March 3 stats (combining 43 years) are: Median 545, Mean 834, Max 4870 (in 2007). Converting 834 cuft/s gives: 834 cubic feet per second (539,000,000 US gal/d). I'm not sure how common is abbreviation "cfs", but that is another issue to consider. More study is needed to see who uses gallons per day. -Wikid77 13:01, revised 13:56, 3 March 2011 (UTC)

• On the USGS webpage "http://waterdata.usgs.gov/usa/nwis/uv?03094000", the water level is at Leavittsburg Ohio, not the mouth which is 40 miles downstream. I found the data for the mouth measured at New Castle Pennsylvania and it was measured in gallons per day which was the reason for this request. Earlier checking, I saw other rivers and waterfalls measuring in different scales (gallons per day, gallons per hour, cubic feet, cubic meters, and so on). There doesn't appear to be a standard for showing this type of information which is the reason I asked for this change to both the template and the converter. 21:18, 3 March 2011 (UTC) Wheller007 (talk • contribs)

Thank you for responding with those details. I was thinking to allow a wider variety of discharge flow units, by having new parameter "discharge_unit" in Template:Infobox_river, where each unit would convert to the common-sense equivalent when displayed, but now I am thinking to have optional "discharge_unit2" to specify both units. It takes a while to adjust to the scope of the thousands of measurement units, used in the world at large, so we tend to oversimplify the true real-world complexity, in an effort to cope with the enormous extent of the diversity of units. However, I think we will be able to expand coverage, soon, to handle more river-data measurements. Thanks, again, for that data. -Wikid77 06:59, 4 March 2011 (UTC)

"U.S."

The usual way to put dots on the "US" is to use U.S., i.e. {{convert|10|U.S.gal/d}}. It's easier to type, simpler to code and more what-you-see-is-what-you-get than {{convert|10|USgal/d|sp=us}}. However, it's not a bad idea to have the sp=us option. Some US units do have it, e.g. {{convert|10|usgal|sp=us}}. These units use a lower-case "us". Let's make it consistant. JIMp _talk·cont 02:40, 5 March 2011 (UTC)

Option disp=u2 shows output unit 2

As requested for months, I have added new option "disp=u2" to show just the unit symbol, or name, of unit 2. The name varies by the actual conversion result, with the actual singular or plural spelling. This also answers the question, "What is the default output unit?" Some examples:

• {{convert|3|lb|disp=u2}}           → 3 pounds (1.4 kg)
• {{convert|3|lb|disp=u2|abbr=none}} → 3 pounds (1.4 kilograms)
• {{convert|3|lb|disp=u2|lk=on|abbr=none}} → 3 pounds (1.4 kilograms)
• {{convert|2.2046|lb|disp=u2|lk=on|abbr=none}}   → 2.2046 pounds (1.0000 kilogram)
• {{convert|3|m3/s|disp=u2}}     → 3 cubic metres per second (110 cu ft/s)

When the result is 1.0, then the unit name is "kilogram" singular. The display-code as "u2" (rather than "unit2") was chosen to help internationalize the options in Convert, to avoid so many English-based words (for example, in Spanish, "unit2" would be expected as "unidad2", where "u2" would be more universal for Latin alphabets). This follows from "disp=output only" becoming "disp=2" and "disp=output number only" becoming "disp=#" in the other-language wikipedias. Perhaps the reluctance to use Convert in other languages is partly due to the English bias in the option names. More later. -Wikid77 06:59, 4 March 2011 (UTC)

Pferdestärke

This unit conversion seems to default to (SAE?) horsepower. This unit is a former DIN standard and is familiar to many "older" Europeans since we aren't as familiar hands-on with the EG units mandates. Also, for the sake of accuracy it should be corrected. The section in the template of convert should list explicit units of power allowed and abbreviations expected for input not just the 'common units etc...' as is in place now. That's how we find this problem.

SirDeath (talk) 1901, 22 April 2010 (UTC)

Well, {{convert|100|kW|hp-metric}} or such should work well in these cases. Explicitely listing all different power unit codes would, of course, be helpful (I searched quite some minutes until I found this option). --:bdk: 00:13, 9 March 2011 (UTC)

Calories v. calories

The template improperly displays Calories as calories. For example, if the input unit is Cal, and the output unit is kJ, the template displays "calories". It needs to preserve the capitalization, since 1 Calorie = 1 kilocalorie = 1,000 calories. Kilocalories (Calories) are used primarily in computation of energy content of foods. Although we often see it printed in lowercase in publications, the proper form is to capitalize it in order to distinguish it from the ordinary calorie. —Quicksilver^{T @} 20:00, 5 March 2011 (UTC)

• I will submit an edit-request to fix Convert/Cal:
    • {{convert|1|cal}} → 1 calorie (4.2 J)
    • {{convert|1|Cal}} → 1 calorie (4.2 kJ)
  The large calorie will be fixed to show cap "Calorie" rather than the lower-case name "calorie" used for the gram calorie. Thanks for reporting that problem. -Wikid77 00:21, 6 March 2011 (UTC)

This is a non-problem. From what I'd read this convention was not generally followed. A couple of weeks ago I decided to check out how well followed it was here on WP. I searched hundreds of instances of the word "calorie". Almost all of these instances were in reference to the large calorie and very few of them capitalised the word. The rule makes no gramatical sense. We don't rely on this alone to make the distinction, context and/or conversions to SI are sufficient. You've noted that we often see the word in lower-case but you suggest that this is not "proper". How do we take a convention hardly followed and call it proper? How do we detemine what is proper? Let's take this to WT:MOSNUM. JIMp _talk·cont 23:52, 10 March 2011 (UTC)

Template usage

Dear Wikipedians, As a matter of server load and consistency, I was wondering what the common rule of usage is for this template? Is it preferred to use this template or to write directly the conversion in an article? In other words, is it preferred to write in an article { {convert|1|cm|m } } or 1 centimetre (0.01 m)? Thanks in advance for clearing this up! Xionbox^₪ 11:35, 6 March 2011 (UTC)

As for server load, see WP:DWAP. As for consistency, I don't think it is an issue so long as readers cannot tell whether or not a conversion template is being used without looking at the page source. I've heard that using the templates is preferred so that there's no need for future editors to check whether a given conversion is correct (as, without the template, a vandal could tamper with the converted value but not the original one and that could go undetected for months), though this obviously doesn't matter with such trivial conversions as your example. I generally prefer using the template, except when I want a very specific output format I can't get with it. --A. di M. (talk) 15:39, 6 March 2011 (UTC)

• A few people write conversions by hand, but they should use "&nbsp" to control text-wrapping: "1 centimetre (0.01 m)" and such. Many people have complained if a unit symbol is allowed to wrap in parentheses "(45 ft)" and Template:Convert can be used to ensure a more-consistent style when typesetting the conversions. As for performance, Convert is so ultra-efficient, there is basically zero effect on the server load. In using less than 280 bytes of the post-expand include size limit, Convert can be used over 7,000x times per page. If an article needs a table to list many conversions, then feel free to use Convert thousands of times in a wikitable. -Wikid77 12:20, 11 March 2011 (UTC)

Template bug - scientific notation

There is a problem with the convert template that you can see at Economy of Texas#Energy. I wasn't able to fix it myself. It looks like the problem only appears when the output is in scientific notation. Foobaz·o< 20:37, 9 March 2011 (UTC)

The following is the crux of the problem

{{convert/outsep| 1={{formatnum:{{formatnum:{{rnd/e+|4.35|10}}}}}}| sep= |2=m<sup>3</sup>|3=m<sup>3</sup>}}

which currently produces ...×10^{{{3}}} m³

I have fixed it in the sandbox, but need an admin to copy it over (see Template talk:Convert/outsep). Thank you. Frietjes (talk) 23:07, 9 March 2011 (UTC)

Now fixed. Thank you! Frietjes (talk) 00:40, 10 March 2011 (UTC)

• Looks good. The engineering units (e9km, e6km, e6mi, e6cuft, etc.) often use scientific notation. Also, I have implemented the options "disp=x" and "disp=flip" and "abbr=none" for those e-format engineering units:

• {{convert|10|e6mi}}                → 10 million miles (16×10^⁶ km)

• {{convert|10|e6mi|abbr=none}} → 10 million miles (16 million kilometres)

• {{convert|10|e6mi|disp=flip}} → 16 million kilometres (10×10^⁶ mi)

Currently, use of those engineering units has been mostly in oil/gas articles, so perhaps 600 articles were affected for less than 1 day. -Wikid77 12:20, 11 March 2011 (UTC)

Convert to decimal feet

Article currently refers to "2.5 to 3 meters" -- the default output from {{convert}} renders this as "(8 ft 2 in to 9 ft 10 in)", which seems unwieldy. Is there a way to get "(8 to 10 ft)" instead (other than writing it out manually)? Thanks, NapoliRoma (talk) 00:38, 17 March 2011 (UTC)

Try adding the rounding parameter (0 digits) like this:

• {{convert|2.5|to|3|m|ft}} to give 2.5 to 3 m (8.2 to 9.8 ft)
• {{convert|2.5|to|3|m|ft|0}} to give 2.5 to 3 m (8 to 10 ft)  Stepho  (talk) 00:42, 17 March 2011 (UTC)

Thanks! Thanks especially for understanding what I really was asking, which was to not have the remainder given in inches. In mid-writing of my question I realized I also wanted to round, so I changed my example output to whole feet, which obscured my original thought. Oops.

So the key things I learned are that A) the default conversion from m is to ftin, and B) to do what I want I need to explicitly specify conversion to decimal feet, which is ft.

I'm not sure where either of these points are documented. Clearly this is an enormous project—over 3,000 subtemplates??—and documenting it all can be challenging. If you can think of any place where someone not intimately familiar with the intricacies of the project can help out on the doc, I'd be glad to pitch in. (It may be that my main contribution can be as a confused reader pointing out where stuff isn't clear to the layman.) Regards, NapoliRoma (talk) 20:08, 19 March 2011 (UTC)

convert board feet directly to cubic meters

For Cass Scenic Railroad State Park#History and perhaps elsewhere convert board feet directly to m3. 1.25 billion board feet (2,900,000 m³) or 104,166,666 cubic feet (2,949,672 m³) Peter Horn User talk 01:34, 24 March 2011 (UTC) Peter Horn User talk 01:42, 24 March 2011 (UTC)

That would perhaps be 1,250,000,000 board feet (104,166,667 cu ft; 2,949,672 m³)? Peter Horn User talk 19:05, 25 March 2011 (UTC)

How about that? Frietjes (talk) 20:52, 25 March 2011 (UTC)

Or this 1.25 billion board feet (104,000,000 cu ft; 2,950,000 m³). Frietjes (talk) 20:59, 25 March 2011 (UTC)

I'm not sure why {{convert|1.25|e9bdft|cuft m3|sigfig=3}} works, {{convert|1.25|e9bdft|cuft m3|sigfig=3|lk=on}} works, but {{convert|1.25|e9bdft|cuft m3|sigfig=3|lk=in}} doesn't work. It's not a problem with bdft, since {{convert|1.25|e9cuft|m3|sigfig=3|lk=in}} is also currently broken. Frietjes (talk) 21:13, 25 March 2011 (UTC)

Update, now fixed, by fixing a bug in Template:Convert/LinAoffDbSoffEng, so 1.25 billion board feet (104,000,000 cu ft; 2,950,000 m³) now works. Frietjes (talk) 21:45, 25 March 2011 (UTC)

Splendid, all of them, but I'll go with the last one. Bedankt en groetjes. Peter Horn User talk 01:41, 26 March 2011 (UTC)

Error formatting

Is there a reason why this template's error messages don't use the from across MediaWiki? If it was changed to use <span class="error"> instead of the coloured font tag, it would be better for accessibility and would also allow error messages to be identified by the {{#iferror:...}} parser function. Happy‑melon 11:26, 25 March 2011 (UTC)

...Well, most problems appear as missing template names, from misspelled unit-codes, such as putting "sqtf" (for "sqft") as: {{convert|2|m2|sqtf}} → 2 square metres (Template:Convert/sqtf). The red color of "Template:Convert/sqtf" looks like a red-link (well, it is a red-link). So, to avoid confusing the messages with other red-linked text, some darker orange colors have been tried, such as: "{{convert|3|$/lb|$/oz}} for fried green tomatoes". With other issues, several different message styles have been used to explore alternatives, in seeking potential improvements. Currently, there are so many hundreds of other problems in conversions, that the color of messages has been a low priority. Basically, with the edit-protection set to full protection, on most subtemplates, the improvements have ground to a crawl for the past few years. Most volunteers just do not work well in requesting bureaucratic updates to thousands pages. Gee, I wonder why. -Wikid77 08:39, 26 March 2011 (UTC)

disp=x| [|]}} acting odd...

{{convert|32|m|ft|disp=x| [|]}} works. It produces 32 metres [105 ft].

{{convert|250|km2|sqmi|disp=x| [|]}} doesn't work. It produces 250 square kilometres [97 sq mi. (missing end bracket) 76.226.56.64 (talk) 02:23, 26 March 2011 (UTC)

Should work now. Thanks! Plastikspork _―Œ^(talk) 02:39, 26 March 2011 (UTC)

Measurement tons

Is there a conversion template for converting measurement tons to cubic metres? Hawkeye7 (talk) 09:47, 20 March 2011 (UTC)

• DONE. The new unit-code is "MTON" (where "MT" would be for metric tonne), as follows:
       • {{convert|10|MTON|m3|2}} → 10 measurement tons (11.33 m³)
  Sorry for the delaying in supporting that unit. -Wikid77 03:28, 21 March 2011 (UTC)
  • Thankyou! Much appreciated. Hawkeye7 (talk) 05:52, 21 March 2011 (UTC)

Should this unit be mentioned in the mosnum table at: mosnum:specific units? Regards Lightmouse (talk) 16:17, 26 March 2011 (UTC)

SI temperatures

The template currently outputs temperatures as, for example, "30 °C (112 °F)" (with a space), whereas it is my understanding that SI units for temperature do not employ spaces. Also, does the template currently use non-breaking spaces where necessary? eg, "50&nbsp;kg (110&nbsp;lb)" nagualdesign (talk) 21:53, 23 March 2011 (UTC)

• In webpages for the National Institute for Standards and Technology (NIST), there is, in fact, a space before the degree symbol " °C" as follows:
    • "water freezes at 0 °C and boils at about 100 °C" - note the space after each numeral.
  Plus, yes, for temperatures, and other units, a non-breaking space is inserted (as &#160;) after each number is displayed. -Wikid77 07:44, 25 March 2011 (UTC)

Okay, thank you for looking into that. :) nagualdesign (talk) 17:55, 25 March 2011 (UTC)

Note that for questions about SI, the primary source is the official SI website: It says "The numerical value always precedes the unit, and a space is always used to separate the unit from the number. ... This rule means that the symbol °C for the degree Celsius is preceded by a space ...". Wikipedia guidance at wp:mosnum is similar. There is, of course, no space before the degree symbol and the 'C', perhaps that's what prompted your previous understanding. Lightmouse (talk) 16:11, 26 March 2011 (UTC)

Template:Convert/benefits to list reasons for use

After prior discussions where some users have forgotten why to use Convert for various types of calculations, I have created another information template:

• {{Convert/benefits}} - introduces reasons to use Convert

When that template is placed on someone's talk-page, it shows just a very short, 1-paragraph explanation for using Convert, as follows:

{{Convert/benefits}}

When a user goes to the page for {Convert/benefits}, then a larger explanation is displayed for the reader. We can add more examples on that page, to help remind users for when Convert would really help simplify the conversions in various articles. In a sense, the new page provides a "marketing brochure" or "executive summary" to help remember the features which Convert provides. The current page is just an initial draft version, so please feel free to expand that page and explain more reasons for using Convert, while we continue to expand the improvements in Convert to support dozens of other features. -Wikid77 13:59, 18 March 2011 (UTC)

"Loverly", I'll post this next time on the talk page of any user who reverts my {{convert}} edit(s). Peter Horn User talk 17:13, 18 March 2011 (UTC)

Good, and as more objections are refuted, then we can add any other major explanations into that template. Also, viewing a what-links-here of {Convert/benefits} will quickly track who has been reminded of the benefits, rather than having to search in talk-page archives. -Wikid77 20:27, 18 March 2011 (UTC)

Wikid, for a starter you might correct, refute, Ucucha"s argument at the end of Template talk:Convert#Some editors dislike conversion templates, part 2 above. Peter Horn User talk 22:28, 27 March 2011 (UTC) Peter Horn User talk 22:30, 27 March 2011 (UTC)

How do I get this to work

I'd like to get both units spelled out in full, in adjectival form, to get an output that looks like "60-acre (24-hectare)". However, using

{{convert|60|acre|ha|0|adj=on|abbr=none}} gives an error:

60-acre (24-hectare)

What am I doing wrong? Sasata (talk) 15:45, 27 March 2011 (UTC)

I created the missing template. Thanks! Plastikspork _―Œ^(talk) 16:04, 27 March 2011 (UTC)

Another threesome

For Tank car#"Whale Belly" cars 33,000 US gallons (120 m³; 27,000 imp gal) instead of just 33,000 US gallons (120 m³) Peter Horn User talk 22:34, 27 March 2011 (UTC)

And yet another

For Intermodal container#Non-shipping uses what would be the the customary unit and/or imperial unit to make/turn 8,000 kWh (28,800 MJ) into a threesome? Peter Horn User talk 21:29, 30 March 2011 (UTC)

Three dimensional

For Twistlock 7 in × 7 in (180 mm × 180 mm)×4+1⁄2 in (110 mm) into a single convert. Peter Horn User talk 22:42, 27 March 2011 (UTC)

Use Template:Convert/3 (there's also a Convert/4) as follows:

• {{convert/3 |7|x|7|x|4+1/2|in|mm}}           → {{convert/3|7|x|7|x|4+1/2|in|mm}}
• {{convert/3 |7|x|7|x|4+1/2|in|mm|abbr=on}} → {{convert/3|7|x|7|x|4+1/2|in|mm|abbr=on}}
• {{convert/4 |2|-|3|-|4|-|5|C|F}}       → {{convert/4|2|-|3|-|4|-|5|C|F}}

If the suffix "/3" is omitted in "convert/3" then it might say "Template loop detected" or missing "Template:Convert/def" so beware of that mistake. -Wikid77 (talk) 09:59, 29 March 2011 (UTC)

"Template loop detected" did indeed happen. Thanks for the enlightening suggestion. Peter Horn User talk 19:55, 30 March 2011 (UTC)

Use for converting blood sugar values

A convert template would be very useful in the Glycated hemoglobin article for converting the older percentage unit (DCCT) into the newer mmol/mol (IFCC). I think they should both be given, such as 20 mmol/mol (4.0%). Does anyone know how to create such a template (or integrate it into the function of this one)? The conversion equation is: IFCC-HbA1c (mmol/mol) = [DCCT-HbA1c (%) - 2.15] × 10.929. Mikael Häggström (talk) 13:27, 28 March 2011 (UTC)

New Template:Convert/scale can be used to calculate a custom scale formula, such as for the above formula:

• {{convert/scale|33|% DCCT-HbA1c|IFCC-HbA1c|a=10.929|offset= -2.15}} →

See Template:Convert/scale for description of parameters and other examples. Otherwise, a specific unit can be supported, with the offset factored as -2.15 × 10.929 = -23.49735, but what unit names would be used? -Wikid77 12:04, 29 March 2011 (UTC)

Thanks! This will work fine for the glycated hemoglobin article. If it would use specific units, then it would probably be preferred to use mmol/mol to %. Mikael Häggström (talk) 13:08, 29 March 2011 (UTC)

I tried to reverse the equation, so that it converts mmol/mol into %, and use the example in my introduction of 20 mmol/mol (4.0%):

(20 * 0,091500) + 2,15 = 3,98

This works fine when pasting it in Google, but here, I tried the following template:

{{convert/scale|20|mmol/mol|%|a=0.0915|b=2.15}}

, but it turns out like:

It should say (4%), not (0%). What am I doing wrong here? Mikael Häggström (talk) 13:18, 29 March 2011 (UTC)

• There was a rounding problem, where the result 3.98 was rounded to the nearest 10, which rounded 3.98 to 0. I have fixed it:

{{convert/scale|20|mmol/mol|%|a=0.0915|b=2.15}}       →

{{convert/scale|20|mmol/mol|%|a=0.0915|b=2.15|r=2}} →

The rounding can be set by "r=2" (or such). -Wikid77 (talk) 17:56, 29 March 2011 (UTC)

Thanks! Mikael Häggström (talk) 05:38, 30 March 2011 (UTC)

disp=x and abbr=on with to(-)

I have a range of measurements that I want to convert. The measurements must be in parentheses (), so I want to have the the conversion results enclosed by in square brackets []. In the examples, I've replaced the { and } with periods, to show the coding before the result.

This works: (..convert|2|to(-)|5|mm|in|sigfig=1|disp=x|[|]..)

gives the result (2 to 5 millimetres[0.08–0.2 in])

and this works: (..convert|2|to(-)|5|mm|in|abbr=off|sigfig=1|disp=x|[|]..)

gives the result (2 to 5 millimetres[0.08–0.2 inches])

But (..convert|2|to(-)|5|mm|in|abbr=on|sigfig=1|disp=x|[|]..) does not work and gives the result

(2 to 5 mm[0.08–0.2 in])

I've replicated the problem with other units, and the problem only arises when I set abbr=on, but I must use it if I want to avoid cumbersome repetition of unit names in favor of their abbreviations.

Can anyone help, please? Twistlethrop (talk) 01:20, 30 March 2011 (UTC)

Not sure if I completely got it right, but your example seems to be working (someone should check Template:Convert/Dual/LoffAonDxSoff). Thanks! Plastikspork _―Œ^(talk) 01:32, 30 March 2011 (UTC)

• I have seen this problem before and I think I understand the issue: the dash in "2–5" is considered the abbreviation for the range-word "to" (from the original "2 to 5"). When using option "abbr=on" with "to(-)" then Convert invokes the same subtemplate to format the abbreviated input range, with dash, as in the output range "0.08–0.2 in" (with dash). This is a frustrating issue to fix (hence, it has not been fixed yet), as preserving the word "to" for the input range, while using "–" in the output range, when both ranges are displayed by the same subtemplate which only puts "–" between the amounts. All of those range conversions are designed, for when abbr=on, to format both the input & output ranges the same way. If one has a dash, they both have a dash. I will try again to pass some parameter to show "to" when the input range is abbreviated. I realize the option "to(-)" should always show word "to" as the logical result. -Wikid77 03:51, 30 March 2011 (UTC)

  Interesting, I didn't notice the missing "to" part. When the issue was originally reported, it was showing a big redlink to "Template:Convert/Dual/LoffAonDxSoff", so I created it. This is certainly better than it was before, but not exactly correct as you have pointed out. Thanks! Plastikspork _―Œ^(talk) 01:27, 31 March 2011 (UTC)

Error in conversion to stones + pounds

Copied from Template talk:Infobox ice hockey player

I was just looking at this page Kārlis Skrastiņš and noticed an error in weight in stones. I was going to correct the error but it seems only the weight pounds is entered and it is then converted. I have looked at a few other pages using the same infobox and the stone weight appears to be correct in those. What code is used for the convesrion? For teh record 210lb is most certainly 15st, not the 14st displayed. --LiamE (talk) 22:16, 30 March 2011 (UTC)

This template uses {{convert}}. In this case {{convert|210|lb|kg stlb|abbr=on}} which results in 210 lb (95 kg; 14 st 0 lb). I will bring up the issue there and/or possibly fix it myself. Thanks! Plastikspork _―Œ^(talk) 01:20, 31 March 2011 (UTC)

Note that not all the conversions to stones in that template are broken, since {{convert|210|lb|st|abbr=on}} results in 210 lb (15 st). But, {{convert|210|lb|stlb|abbr=on}} results in 210 lb (14 st 0 lb), so this should help isolate the problem. Plastikspork _―Œ^(talk) 01:27, 31 March 2011 (UTC)

I will see if I can figure out what is going on, but it may take me some time. Thanks! Plastikspork _―Œ^(talk) 01:27, 31 March 2011 (UTC)

Okay, here is the basic problem. To perform the conversion to stlb, it first converts to kg, then converts back to lbs. If you expand out the conversion for 210 lbs, you find a part which calculates floor(( 210 )*0.45359237/14/0.45359237), which you would think is equivalent to floor(( 210 )/14), but it's not here for some reason. The strange thing is that {{#expr:( 210 )*0.45359237/14/0.45359237}} results in 15, but {{#expr:floor(( 210 )*0.45359237/14/0.45359237)}} results in 14. So, suddenly, the floor of 15 is 14 :( We could add a very small amount to nudge it up, but this is very odd. Plastikspork _―Œ^(talk) 01:50, 31 March 2011 (UTC)

Note that, if I insert another expr, then {{#expr:floor({{#expr:( 210 )*0.45359237/14/0.45359237}})}} results in 15, which is what we want. I just fear increasing the expression depth. Also, {{#expr:floor( (210*1.000000000000001)*0.45359237/14/0.45359237 ) }} works, but it seems like a crude hack. Plastikspork _―Œ^(talk) 01:52, 31 March 2011 (UTC)

Currently conversions for multiples of 15 stone are incorrect
1×14 lb (1.0 lb×1 st 0 lb) 2×14 lb (2.0 lb×1 st 0 lb) 3×14 lb (3.0 lb×1 st 0 lb) 4×14 lb (4.0 lb×1 st 0 lb) 5×14 lb (5.0 lb×1 st 0 lb) 6×14 lb (6.0 lb×1 st 0 lb) 7×14 lb (7.0 lb×1 st 0 lb) 8×14 lb (8.0 lb×1 st 0 lb) 9×14 lb (9.0 lb×1 st 0 lb) 10×14 lb (10 lb×1 st 0 lb)	11×14 lb (11 lb×1 st 0 lb) 12×14 lb (12 lb×1 st 0 lb) 13×14 lb (13 lb×1 st 0 lb) 14×14 lb (1 st 0 lb×1 st 0 lb) 15×14 lb (1 st 1 lb×1 st 0 lb) 16×14 lb (1 st 2 lb×1 st 0 lb) 17×14 lb (1 st 3 lb×1 st 0 lb) 18×14 lb (1 st 4 lb×1 st 0 lb) 19×14 lb (1 st 5 lb×1 st 0 lb) 20×14 lb (1 st 6 lb×1 st 0 lb)	21×14 lb (1 st 7 lb×1 st 0 lb) 22×14 lb (1 st 8 lb×1 st 0 lb) 23×14 lb (1 st 9 lb×1 st 0 lb) 24×14 lb (1 st 10 lb×1 st 0 lb) 25×14 lb (1 st 11 lb×1 st 0 lb) 26×14 lb (1 st 12 lb×1 st 0 lb) 27×14 lb (1 st 13 lb×1 st 0 lb) 28×14 lb (2 st 0 lb×1 st 0 lb) 29×14 lb (2 st 1 lb×1 st 0 lb) 30×14 lb (2 st 2 lb×1 st 0 lb)

Okay, I made this change. Given the 17,000 or so transclusions, someone should revert this if it causes other problems. However, it appears to fix this particular bug. Thanks! Plastikspork _―Œ^(talk) 02:32, 31 March 2011 (UTC)