Template talk:Convert/Archive June 2009

Error in conversion?

When I put in 93 kg, it gives me 210 lbs, close, but not right: 93 kg (205 lb). Yet when I put in 93.0, it is correct: 93.0 kg (205.0 lb)? Can someone explain/fix?--2008Olympian^chitchat 23:25, 27 May 2009 (UTC)

No, it is correct. Because the source only has two significant figures (93), the output is displayed with only two significant digits (21). This can be overridden by using {{convert|93|kg|lb|0|abbr=on}}. Note the "0", which forces the output to display precisely to the decimal place. This can be changed to positive or negative numbers to adjust the level of precision. — Huntster (t • @ • c) 06:44, 28 May 2009 (UTC)

Or it can be controlled with sigfig= on a case-by-case basis. --ClickRick (talk) 11:15, 7 June 2009 (UTC)

triple converts

In the case of dimensioning an intermodal container, or such, the following might be usefull {{convert|8|x|8|x|20|ft|mm|0}}, {{convert|8|by|8|by|20|ft|mm|0}}, {{convert|8|x|8|x|20|ft|m|3}} or {{convert|8|by|8|by|20|ft|m|3}} etc. Peter Horn 01:50, 4 June 2009 (UTC)

For ease of reading, those are:

* {{convert|8|x|8|x|20|ft|mm|0}}

* {{convert|8|by|8|by|20|ft|mm|0}}

* {{convert|8|x|8|x|20|ft|m|3}}

* {{convert|8|by|8|by|20|ft|m|3}}

--ClickRick (talk) 11:27, 7 June 2009 (UTC)

Convert "or"

Can some one make the following work? 88 or 96 inches (2,235 or 2,438 mm) Peter Horn 01:02, 7 June 2009 (UTC)

You mean like this? {{convert|88|in|mm|disp=or}} 88 inches or 2,200 millimetres Ignore me, I misread what you were saying.

--ClickRick (talk) 11:29, 7 June 2009 (UTC)

I see you meant {{convert|88|or|96|in|mm|0}}. That'll need a variant on the Dual option. I'm sure it can be done, but in the meantime does the context not work well with 88 inches (2,235 mm) or 96 in (2,438 mm)? ClickRick (talk) 11:20, 11 June 2009 (UTC)

Can we have disp=comma?

Just as we have disp=s for slash-separated values, and disp=or to separate them with the word or, rather than the default of having the output value in parentheses, can we have the option of disp=comma for a comma-separated output? This would be useful in contexts where the first value is already in parentheses, so the second value should appear within the same parentheses but separated by a comma, e.g. in a geography-related table, where the height of a mountain might be given as "Mount Caubvik (1,652 m, 5,420 ft)" (see Labrador). I've used disp=or for that one for now but it's not ideal. --ClickRick (talk) 11:40, 7 June 2009 (UTC)

OK, I've added Template:Convert/LoffAoffDcommaSoff for this, and it seems to do what I wanted. If it looks ok, can it be extended for the cases which I've not covered? --ClickRick (talk) 12:06, 7 June 2009 (UTC)

{{convert|5420|ft|m|disp=comma|abbr=on}}--->5,420 ft, 1,650 m, There will be many many more combinations that would have to be completed. Template:Convert/Maintenance/outputs/standard used to show them but I don't know what happen (Jimp...do you know?) it doesn't show them anymore.

Personally, I think a semicolon would be better inside of parenthesis (1,652 m; 5,420 ft) because of the commas used as the numbers separator, but I was "know" english major (lol). So I could be wrong. And that's the way it is done it multiple conversions, e.g. 20 U.S. fluid ounces (590 mL; 21 imp fl oz) —MJCdetroit ^(yak) 20:05, 10 June 2009 (UTC)

As it turns out, my choice of a comma for that instance stems from a mis-remembered mis-reading from Wikipedia:Manual_of_Style#Brackets_and_parentheses where it talks about adjacent sets of parentheses. if disp=semic or disp=; would improve consistency, I think I've only used this new form in that one place (possibly two, I'll have to check) so it's not a big task to change. And yes, I know there'll be a lot more to do - I wanted to check that there was a consensus in favour of it before making yet more work.

—ClickRick (talk) 09:12, 12 June 2009 (UTC)

Yes, those maintenance templates don't show anything now. I did that to prevent the missing subtemplates from showing up on the broken templates lists. It's not hard to reverse. JIMp _talk·cont 14:04, 15 June 2009 (UTC)

temperature range

I've been impressed and made good use of the range capability, such as 186,272 to 186,273 miles (299,776 to 299,777 km). However, when I try to do that with Fahrenheit temperatures, I get this: 101 to 109 °F (38 to 43 °C).

It kind of looks like additional support for the "to" is needed somewhere. —EncMstr (talk) 00:58, 11 June 2009 (UTC)

This is a known, documented restriction. I might get some time today to take a fresh look to try to determine the scale of the job. ClickRick (talk) 09:19, 12 June 2009 (UTC)

WP to CZ import problems

Hi, I am a dual contibutor to WP and CZ, and have recently begun importing the Conversion Templates. However I am getting an error message on any pages that use the conversion templates. This can be seen here. I know there are a lot of templates behind this function, and obviously I am nowhere near done, but I want to know what specific templates I a m missing that would fix this. If that's not possible, then can someone at least show me the general area to look for the missing templates?

I was only wanting to convert those measurements on the article. I began importing and suddenly I realied the job wasn't going to be quite so simple. Now I just want to get the ones in use working, and worry about the rest later.

Thanks!Drew Smith What I've done 03:14, 14 June 2009 (UTC)

It'll be difficult to give you any specific pointers without knowing what you've already got in the way of a) wiki software and b) templates that you've copied across so far, but I'd suggest looking at these lists to see what's "obviously" missing and then try to work from there:

• Category:Subtemplates_of_Template_Convert
• Category:Subtemplates_of_Template_Rnd
• Category:Mathematical_function_templates

ClickRick (talk) 06:53, 14 June 2009 (UTC)

A list of the templates I've already copied so far can be found at this link, this link and there are a few not covered by those categories here. I've mostly only copied templates that fall under Convert and Rnd, though I did grab some of the Precise templates as well. Like I said, I'm not even halfway through getting them all. I just want to get the ones needed to make inches to centimeters working. I'll get the rest as I need it.Drew Smith What I've done 07:43, 14 June 2009 (UTC)

This template could have been better built

Take a look at this. This is Citizendiums entire convert template. Very simple, quick, and to the point. We have a second template that does ranges, using convert. As you can see, the code in our template is very simple, very easy to add to, and not prone to problems, as yours is.

I am not meaning to criticise, but to encourage cross-wiki collaboration. We think we have a better way, and we want to share it.Drew Smith What I've done 03:42, 17 June 2009 (UTC)

Two reasons this template is the way it is: scalability and tiny transclusion size. Because of the use of subtemplates, the servers don't have to work nearly as hard to process instances of the template, and given that Wikipedia has a transclusion limit in articles (limits how many templates can be included based on the size of the total transclusion), this allows for vastly more instances of Convert in a single article (most useful in large lists). This small footprint and configuration, in turn, allows for an almost unlimited ability to expand on how many units that can be converted, and various method of output. Yes, CZ's version is simpler, but it is far less capable in the long run. To each their own...perhaps we can convince Jimp to write an editing guide for this template? :) — Huntster (t • @ • c) 04:13, 17 June 2009 (UTC)

It seems to me that all the thousands of templates this one relys on would slow things down much more than one large template would. I've tried importing just the templates needed for inches to centimeters, and it didn't even show the first number until I had imported more than a thousand different templates. And I don't think a guide would help either, these templates rely to heavily on each other that I don't think anything else could be added.Drew Smith What I've done 04:51, 17 June 2009 (UTC)

That's the point of the templates...while the inherent complexity does making editing them more difficult, it is actually easier on the servers, because it deals with lots of tiny templates, rather than one really big one (remember, with a large template, the server has to parse every if-then-else and other function before displaying). Jimp would have to explain the ins and outs, but it does work. — Huntster (t • @ • c) 07:33, 17 June 2009 (UTC)

Yes, I would have to admit that the template could have been better designed. I'd originally thought it'd take a couple of weeks ... but a couple of years later there is still work to be done. So it could have been better designed but, with due respect, a switch monster like you have at Citizendium is by no means better. Such a thing was what the current design replaced. One of the purposes for the replacement was, as noted by Huntster, to reduce the load on the servers ... and yes, it is a reduction, a significant reduction. Another was versatility—the current design allows for so many different options and units. Being so open to expansion, I don't suppose it'll ever be finished. Excuse my being so brief but to explain the ins & outs would probably take all day, however, yes, it does work ... and a whole lot better than a {{#switch}} (or an array of them), which, as my own testing has shown, are particularly taxing with respect to the template limits Huntster mentions. Try and do all that {{convert}} does with a one-page template & I doubt you'd manage a single transclusion ... you probably couldn't even save the page. JIMp _talk·cont 13:55, 17 June 2009 (UTC)

Text wrapping

Could the template be modified so that a non-breaking space is used between each number and its unit?

An option that also puts a non-breaking space between the original measurement and the converted measurement would also be nice, but less critical. —MJBurrage^(T•C) 15:25, 16 June 2009 (UTC)

The first of those is meant to happen already; a quick glance at Template:Convert/check_area shows that it does in most cases, with converted acres being an exception. Which case did you find without one?

The second is less desirable IMO as that could make a significant piece of text which would fail to wrap, potentially making a table datum uncomfortably wide or leaving an unusually large white space at the end of a line.

—ClickRick (talk) 16:43, 16 June 2009 (UTC)

It was in fact a conversion to acres that was wrapping badly, I ended up forcing the column to a certain width to prevent the bad wrapping. —MJBurrage^(T•C) 11:24, 20 June 2009 (UTC)

You could put the whole thing within a {{nowrap}} but, of course, that would usually not be desireable. As for a nbsp between number & unit, per MOSNUM this is to be done only when the unit is written in abbreviated/symbolic form. JIMp _talk·cont 19:28, 16 June 2009 (UTC)

I agree that a nbsp between the original measurement and the converted measurement should not be standard, but it would be a nice option. I.E. an option to add "|nowrap" to get the whole conversion formatted as such. —MJBurrage^(T•C) 11:24, 20 June 2009 (UTC)

Please fix this template's incorrect arithmetic

....and also warn people against trusting it.

Look at this edit. And at the TOP of the article's talk page.

How come both 73 and 76 inches are 190 centimeters?

73 inches (190 cm) inches), while almost all men (about 95%) have a height within 6 inches of the mean (64 inches (160 cm) – 76 inches (190 cm)

It was essential to the point of mentioning these numbers that the reader notice the DIFFERENCE BETWEEN the two DIFFERENT numbers: 190 cm and 190 cm.

Apparently someone programming this template decided to round to the nearest 10 cm.

Whether and when rounding is appropriate depends on the context.

It is true that simply trusting a calculator is always stupid and irresponsible, but that's no excuse for designing a calculator as bad as this. Michael Hardy (talk) 17:09, 20 June 2009 (UTC)

Seems to be working OK, 73 inches (185 cm), 76 inches (193 cm) Enter CambridgeBayWeather, waits for audience applause, not a sausage 19:05, 20 June 2009 (UTC)

Fixed the conversions. Sorry the above was supposed to have read; Seems to be working OK, 73 inches (185 cm), 76 inches (193 cm) {{convert|73|in|cm|0}}, {{convert|76|in|cm|0}} when you add the |0. Enter CambridgeBayWeather, waits for audience applause, not a sausage 19:15, 20 June 2009 (UTC)

Michael, please act as an admin and assume good faith before making accusations (as it sounds like) of incompetence. If you would read the documentation, or check out the multiple talk page convos regarding this topic, you might have understood this was intentional and appropriate, and extremely easy to bypass. Please calm yourself down.

This template works on the principle of significant figures, so if you convert 76 inches (which has two significant figures), you get 190 cm (also two significant figures, since zero isn't counted). This is countered by appending "|0" to the end, as CBW shows above, which converts to the decimal place. — Huntster (t • @ • c) 23:28, 20 June 2009 (UTC)

Scientific notation?

Take a look at Orion Assembly. For the square footage of the plant this template was added but it turned "4.1 million" into "4.1E+6".

How can this be fixed? Scientific notation is probably going to confuse some people. --Olds 403 (talk) 02:13, 22 June 2009 (UTC)

Hmm, when was this implemented into the code Jimp? This is definitely not a good idea, as most people (I would wager) have no clue how to read scientific notation, and a large number wouldn't even know it is called "scientific notation". Suggest going back to straight digits, regardless of the number of zeros. — Huntster (t • @ • c) 03:30, 22 June 2009 (UTC)

Granted the underlying problem probably should be addressed. I've applied the obvious fix: specify the size of the plant in acres, not as bazillions of square feet. —EncMstr (talk) 06:23, 22 June 2009 (UTC)

Adjective-form conversion should have dash, too

First, let me say that this is an incredible template! I saw it in use somewhere recently and thought, "that'd be nice, but I want to make sure my conversions strictly follow precision rules". I discovered to my delight that it does indeed do this, very well in fact. Then I was going to skip using it because I wanted an adjectival version, but when I thought to look again, I found that, as the Prego commercial goes, "it's in there, it's in there!". Kudos to all the hard work you folks have done on this.

One minor tweak I'd like to see, though, is to have the adjectival form of the converted measurement include the dash (or hyphen or whatever you use), as in:

8-pound (4-kg) baby

Could you consider adding this when you get a chance? Thanks. ~ Jeff Q (talk) 07:26, 22 June 2009 (UTC)

There should not be a hyphen when the unit is in abbreviated or symbolic form according to the Manual of Style. JIMp _talk·cont 08:15, 22 June 2009 (UTC)

Acre feet

I did not see this as an option. In the US, acre feet is a common measure of a volume of water. Did I miss this in the documentation? If not there, can it be added? Vegaswikian (talk) 20:59, 23 June 2009 (UTC)

You missed it: it's in the full list of units of volume at Template:Convert/list_of_units/volume. Qwfp (talk) 22:08, 23 June 2009 (UTC)

Error

There's an error showing in Carrizo Plain when converting from acres to hectares. Can someone take a look into this? Thanks. howcheng {chat} 17:25, 24 June 2009 (UTC)

I looked for a recently changed template relating to acres, but quickly was stymied by the call chain. Somewhere a comma is being inappropriately used. I tried using km2 instead of hectares—same result. Oddly, the same calls work fine here: 250,000 acres (100,000 ha) and 250,000 acres (1,000 km²). —EncMstr (talk) 17:43, 24 June 2009 (UTC)

Found it! The area parameter to {{geobox}} expects raw km2 and applies the conversion within the template. Someone fixed it while I was looking and reset the default raw units to acres. —EncMstr (talk) 17:47, 24 June 2009 (UTC)

Thanks for checking. howcheng {chat} 18:02, 24 June 2009 (UTC)

Error mm for cm

This convert: {{convert|4+1/4|in|0|cm|abbr=on}} gives 4+1⁄4 in (108 mm). That is, it converts to millimeters rather than the requested centimetres. Is that intentional? Gaius Cornelius (talk) 18:48, 26 June 2009 (UTC)

Without delving into the depths of this template code, my first hunch is that you need to swap the "cm" and "0"; like this→{{convert|4+1/4|in|cm|0|abbr=on}}, which will produce the desired centimeters→4+1⁄4 in (11 cm). With your version, you are probably passing "0" as the name of the unit to which the conversion is to be made, and since it's obviously invalid, the template uses the default unit (which is millimeters).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 19:13, June 26, 2009 (UTC)

Your hunch is correct. It sees the zero and assumes that's it (ignoring the "cm"). JIMp _talk·cont 00:14, 27 June 2009 (UTC)

I see. Thanks. Gaius Cornelius (talk) 08:34, 27 June 2009 (UTC)

Sorting English heights

I'm trying to make some English heights sortable.

My first attempt isn't worth recounting. My second attempt was to convert English to metric, use the metric as the sort, but use the Height template to display the English. However, that template fails with a 5 ft 0 in person. (English to metric yields 1.524 meters, I round to 1.52 so the display will be two positions, but {height|m=1.52|precision=0}} renders as 1.52 m (5 ft 0 in). As an aside, if there is a way to control the number of digits displayed in the input metric, I could pass 1.524, have it display as 1.52, and it would work. However, 1.83 meters also displays incorrectly {{height|m=1.82|precision=0}} 1.82 m (6 ft 0 in).

Someone pointed me to Convert, which even has an option to include a hidden sort key. Exactly what I'm looking for except that is generates it using the input, not the output. Is there a way to add an option so that the sort key is generated from the output? Or am I missing someone silly?

I created a test table here, confirming it doesn't sort the way I want, but perhaps I didn't use it correctly.--SPhilbrickT 14:59, 29 June 2009 (UTC)
Addendum - I looked into {{m to ft in}}, but {{m to ft in|1.82|precision=0}} produces the not acceptable 1.82 m (6 ft 0 in) --SPhilbrickT 15:10, 29 June 2009 (UTC)

You could use Template:hs to add a hidden sort key with the height in inches (rather than feet & inches), e.g. |{{hs|60}}5 ft 0 in , or |{{hs|60}}{{convert|5|ft|0|in|m|abbr=on}} if you want to display it converted to metres too. Is that any use? Qwfp (talk) 16:39, 29 June 2009 (UTC)

Very helpful. I wish I had known about that template before I spent hours writing an Excel macro, but if I had thought more clearly, I would have searched for such a template. Yes, inches works - I was thinking of showing both metric and English in my occasional windmill tilt, but not necessary. I hope someone will still look into the errors produced by the other templates, but your suggestion will solve my problem - thanks much.--SPhilbrickT 00:53, 30 June 2009 (UTC)