Template talk:Convert/Archive December 2008

Too many obscure conversions

This template has far too many obscure conversions, and often doesn't handle them well.

For example, why does it blithely convert

{{convert|14.3|hand}} giving us 14.3 hands (59 inches; 150 cm)

when in the real world, including parts of Wikipedia untainted by the convert template, a horse 14.3 hands high is almost always 1.50 m at the withers, rather than 1.45 m?

The solution I'd suggest is just to remove "hand" from the list of available parameters. Let the editors who know what is going on deal with it by hand. Gene Nygaard (talk) 13:38, 2 December 2008 (UTC)

Sorry, what problem does this fix, exactly? Insofar as this template has a modular design which means that individual conversions do not affect its complexity, I don't see that removing functionality is an improvement unless it's actively breaking something. Chris Cunningham (not at work) - talk 13:47, 2 December 2008 (UTC)

Funtionality? It isn't functioning properly, according to the conventions in this field.

• {{convert|14.3|hand|in|2}} gives us 14.3 hands (59.00 inches)

but in most, if not all, cases in which "14.3 hands" is used on Wikipedia (and it and similar numbers are used many, many times on Wikipedia), at least if the convert template is not involved, it actually means 59 inches, not 57.2 inches. The results are similar in the real world. Gene Nygaard (talk) 14:44, 2 December 2008 (UTC)

If I'm reading you right, you're saying that there's a bug in the calculation? Or is there more than unit unit of measurement known as a "hand", with this template only supporting the other (and presumably less common) one? Chris Cunningham (not at work) - talk 15:08, 2 December 2008 (UTC)

The problem stems from the fact that the number after a decimal point in a hands measurement may mean either tenths of a hand, as a decimal point would indicate with most units of measure (14.3 hands → 14 & ³/₁₀ hands), or may mean inches (14.3 → 14 hands and 3 inches [but read as "fourteen three hands"], and may be the more common usage). This atypical decimal point usage for measurements in hands has been discussed before, which is why the conversion:

• {{convert|14|hand|3|in|m}}

provides:

• 14 hands (56.000 inches; 142.240 cm).

Considering that Wikipedia is intended for a general audience, a measurement in "hands, inches" seems to me preferable to the potentially more ambiguous "hands.inches", though the latter may be the more common in specialized equestrian sources.

I'm not asking to be flippant and certainly mean no offense, Gene, but why the personal crusade against this template? If you personally don't like it, no one is forcing you to use it. I'm curious… — Bellhalla (talk) 15:19, 2 December 2008 (UTC)

How is it that you imagine that Joe Average Wikipedia Editor is unlikely to go to Castilian horse and add conversions like this one I just did?

• "The Castilian Horse is not a large horse, the very best specimens standing no more than 14.3 hands (59 inches; 150 cm) high, with the average being 14 to 14.2 hands (56.00 to 58.00 inches; 142.24 to 147.32 cm)."

That's the crux of the problem here.

It isn't the slightest bit of help whatsoever that using an incomprehensibly complex template with different parameters will give different results. Furthermore, those tweaks you suggested don't work in the second case:

• {{convert|14|hand|0|in|to|14|hand|2|in|m|2}} gives us 14 hands (56 inches; 142 cm)

Gene Nygaard (talk) 15:48, 2 December 2008 (UTC) fixed example 15:50, 2 December 2008 (UTC)

If I were Joe the Wikipedia Editor, I'd make sure that I understood a template I was using well enough to make sure it did what I intended, and conversely, would not use a template that I did not understand. Perhaps I'm in the minority on that point, but getting rid of functionality in a template because someone might misuse it seems a bit overprotective. I could, for example, take my automatic dishwasher outside and throw it on top of the squirrel that's eating seed out of my bird feeder. That, however, doesn't mean that dishwashers should be banned because someone might cause small mammals harm.

In regard to your second example, note that the documentation says that the "range functionality is not fully implemented for all units, so experimentation may be required". It looks like your experiment proves it has not been extended to measurements in hands. — Bellhalla (talk) 16:14, 2 December 2008 (UTC)

Your obscure workaround suffers from the additional problem of not handing the default precision well, something many editors come to rely too much on since it does work reasonably well in some other cases. In fact:

• {{convert|14|hand|2|in|m}} gives 14 hands (56.00 inches; 142.24 cm)
• {{convert|14|hand|3|in|m}} gives 14 hands (56.000 inches; 142.240 cm)
• {{convert|14|hand|4|in|m}} gives 14 hands (56.0000 inches; 142.2400 cm)
• {{convert|15|hand|0|in|m}} gives 15 hands (60 inches; 152 cm)
• {{convert|15|hand|1|in|m}} gives 15 hands (60.0 inches; 152.4 cm)

Do you see the problem here? You obviously didn't originally, since you didn't add a specification of the precision in your example. Just one more problem of an overwhelmingly complex black box; many editors won't even realize that they can do that, let alone what they need to do to accomplish it. Gene Nygaard (talk) 16:02, 2 December 2008 (UTC)

Please assume good faith here. I will also assume in good faith that you have read the FAQ question at the top of the page regarding precision. What I saw in your first example is that you had as an input the decimal value of "14.3" which the template treats as 14 & 3/10 hands and converts it as such, when the resultant value you expected was from converting 14 hands, three inches, or 14.75 hands. — Bellhalla (talk) 16:25, 2 December 2008 (UTC)

It is trivial to dumb the template down by subclassing it: have a look at the sheer simplicity of {{mpg}} for an example. This could easily be done with a {{hands}} template which only took a subset of common parameters. I'm not seeing what warrants the hyperbole here. Chris Cunningham (not at work) - talk 16:12, 2 December 2008 (UTC)

Combination request

Since aviation uses both knots and km/h, it would be really helpful if I could convert km/h to both kn and mph...there currently isn't such a combination available. Is this something we can request? Many thanks! AKRadecki^Speaketh 03:37, 3 December 2008 (UTC)

Apparently bad use of hyphen

I have always been uncomfortable with the template mandating the use of hyphens regardless of the wishes of the editor. Here is an example that I think is bad:

• Set in 1-acre (4,000 m²) of landscaped gardens
  • See Anglesey Model Village.
• conforming in every instance to the town's 2-acre (8,100 m²) per house zoning ordinance
  • See Applecrest Farm Orchards

What do others think? Lightmouse (talk) 12:32, 30 November 2008 (UTC)

That is because you used the sing=on parameter. Perhaps your script needs tweaking? Dabomb87 (talk) 18:00, 30 November 2008 (UTC)

I don't believe it is a script issue. Are you suggesting that those examples should be plural? Lightmouse (talk) 08:34, 1 December 2008 (UTC)

From the context, the first example should be:

• Set in 1 acre (4,000 m²) of landscaped gardens

obtained by removing the sing=on from the call to {{convert}}

The second example is more complicated. Without a conversion the punctuation should be:

• conforming in every instance to the town's 2-acre-per-house zoning ordinance

since the phrase "2-acre-per-house", as a unit, modifies "zoning ordinance". Where the conversion would go in this case is not clear to me, but would probably be best made manually. But the better solution would be to recast the sentence so as to avoid the conversion-in-a-hyphenated-compound-adjective, like:

• conforming in every instance to the town's zoning ordinance that [mandates a minimum/maximum] of 2 acres (8,100 m²) per house.

As far as the template is concerned, does the sing parameter behave exactly like the adj parameter? If so, why this true? — Bellhalla (talk) 11:56, 1 December 2008 (UTC)

It is true, yes. It is just one of many ways the template is broken, and nobody will fix it even though it has been discussed above, too. There is absolutely no reason whatsoever why removing the "sing=on" tag will give you the correct, singular results (when the number is exactly +1, but not when it is -1 or some other absolute value greater than zero and less than one), while including it gives you incorrect results . Gene Nygaard (talk) 17:14, 1 December 2008 (UTC)

(1) MOSNUM (following, in this case, ISO) says that when value and unit are coupled as a double adjective, follow the normal practice of hyphenating them when the unit is named (i.e., spelled out in full, such as "acre"), but do not use a hyphen when a symbol is used (i.e., when the unit is abbreviated, such as "m²"). "Set in 1-acre (4,000 m2) of landscaped gardens" is wrong, since "1" and "acre" are not a double adjective ("1" is the adjective ... well, the numerator, which is kind of the same; "acre" is the noun). "2-acre-per-house zoning ordinance" is correctly hyphenated, although we avoid such multimonsters where possible (can't see how to here). The conversion will have to be written out completely: "2-acre-per-house (0.8-hectare-per-house) zoning ordinance". But Bellhalla's solution looks better. I inserted into MoS on hyphens (not MOSNUM) advice to reword multimonsters where possible, which you've prompted me to add to. See the examples?

(2) Why on earth are we still converting acres to square metres: acres and hectares, please; square feet and square metres, please.

(3) I really don't understand why people put up with these convert templates. Are editors so incompetent that they can't convert using a calculator. We really need to own the conversion and all of the bells and whistles it entails, such as hyphens, abbreviations, decimal points, and not linking. When you see how much you have to learn to use the damned template, you wonder why people just don't do it manually. I wouldn't allow this template in ANY article I was collaborating on. Tony (talk) 12:52, 1 December 2008 (UTC)

My learned and gallant colleague is correct: we don't need this template, and should really convert as is most helpful to the reader, depending on context. If editors need conversion factors, they have an encyclopedia to hand; if they can't multiply, on-line calculators are readily available. Templates cannot supply an absence of judgment. Septentrionalis PMAnderson 17:54, 1 December 2008 (UTC)

I agree that no one needs this template, just like no one needs ice cream. But like the frozen dessert, many people like it. But with that said, it's important to remember that this template is merely a tool to be used by editors, who should—even though they often may not—apply common sense to its use and its output. — Bellhalla (talk) 18:08, 1 December 2008 (UTC)

Part of the problem is that this is a dangerous weapon in the hands of the average Wikipedia editor.

Some of the problems include:

• It is so overwhelmingly complex. There are things to admire in being so complex, but there is such a very steep learning curve in dealing with all its intricacies that few if any editors will understand it.
• OTOH, it is nowhere near complex enough. It will never be able to deal with all the ambiguities in usage, for one thing. Perhaps he biggest problem along those lines is a complete lack of dimensional analysis, which can lead to problems such as
  • "a <nowiki>{{convert|12|oz|ml|adj=on}} bottle of soda" which gives the result "a 12-ounce () bottle of soda"
  • "the ship traveled <nowiki>{{convert|1300|nm|km}}" bottle of soda" which gives the result "the ship traveled 1,300 nanometres (1.3×10⁻⁹ km)"

It imposes the designers' improper preference for British English, contrary to the national varieties of English rules of Wikipedia:

• To be able to get American English, you need to know that you need to jump through hoops to get it, and you need to know how to do that:
• "a {{convert|6|m|in|adj=on|sp=us}} telescope" which gives the result "a 6-meter (240 in) telescope"

But even if you do jump through the hoops and try to get U.S. spellings, it doesn't always work:

• "sold {{convert|20000|t|lb|sp=us}} of durum to Algeria" which gives the result sold 20,000 metric tons (44,000,000 lb) of durum to Algeria", using a spelling almost completely foreign to U.S. usage, despite the "sp=us" parameter.
  • Of course, I would convert this by hand to "sold 20,000 tons (730,000 bu) of durum to Algeria"—the way you are quite likely to see these quantities expressed in U.S. newspapers or farm magazines—but "sold {{convert|20000|t|USbu|sp=us}} of durum to Algeria" gives the result "sold 20,000 metric tons () of durum to Algeria, not handing the commodity-specific units of mass which is what bushels almost always are in contexts such as this, and not having the dimensional analysis which should give an error message rather than converting to what it uses as volume units.

Gene Nygaard (talk) 19:07, 1 December 2008 (UTC)

Returning to the question at hand; yes, the entire phrase 2-acre-per-house would be the adjective and thus should be all hyphenated or, if possible, reworded as Anderson has pointed out.

sing=on does the same as adj=on. I'd be happy to see the former eliminated.

I agree with Tony that we should be converting acres to hectares (at least for areas between 1 and 100 ha). They're not SI but litres and millilitres are not either.

Of course, we don't need this template but it can save time and effort. There is a lot to digest if you want to know everything that the template does ... and fails to do ... but the basics are simple enough.

JIMp _talk·cont 22:28, 1 December 2008 (UTC)

So you'd "be happy to see the former eliminated" because its broken and you don't want to fix it to work like it should. I'd say that continuing to refuse to fix it so that it does work only increases the chances that this ends up at WP:TFD. Gene Nygaard (talk) 04:20, 2 December 2008 (UTC)

Slow down there, Gene. I want to be sure I'm getting what you're saying... so because someone (i.e., not you) hasn't fixed it means they never will and, thus, the template will likely be deleted? Quite the zero-tolerance stance, if I've interpreted that correctly. — Bellhalla (talk) 05:17, 2 December 2008 (UTC)

Your edit summary said "TFD? Really? For a template that has over 30,000 transclusions?"

Yes, really. It is precisely because of those 30,000 transclusions, assuming your number is accurate, that the problems of a broken, possibly unworkable and unfixable template, need to be dealt with. This issue about sing=on was raised way back ages ago, when I was the first to point out that what they were trying to accomplish was to get the adjective form, not a "singular" form. Adjectives don't have "number" in English grammar; they don't have singular and plural forms. But that doesn't mean there isn't a need to fix the "sing=on" parameter so that it works right, but nobody has done anything many months after the issue was first raised. Gene Nygaard (talk) 14:11, 2 December 2008 (UTC)

I raised this issue back on 12 November 2007 here

Checking back further, I see that User:Three-quarter-ten had already suggested "adj=on" a month earlier on 12 October 2007 here. Gene Nygaard (talk) 14:24, 2 December 2008 (UTC)

As of 16 September 2008, it actually has over 105,000 transclusions. — Bellhalla (talk) 19:40, 4 December 2008 (UTC)

Back to the original topic of hyphens. I expected to see:

• Set in 1 acre (4,000 m²) of landscaped gardens
• the town's 2 acre (8,100 m²) per house zoning ordinance

I used 'sing=on' parameter because I didn't want an 's'. That seems reasonable to me. I don't mind if there is a 'hyph=on' parameter and I don't mind if there is a combined singular/hyphen parameter such as 'adj'. Lightmouse (talk) 09:36, 2 December 2008 (UTC)

As far as I'm aware sing=on was always intended as a way of getting the adjective form. The adjective form (when the unit is spelt out) is hyphenated so we need to do more than just use the singular. Thus it made sense to replace the old sing=on with something more explicit.

You, Gene, are asking for sing=on to simply produce the singular. I say we don't need it. The template checks whether the number is one. Your point is that the test should be 0 < |x| ≤ 1 not {{{1}}}. If you are right, sing=on is not the solution. However; I've got nothing but your word that this is the rule and whilst by no means do I think you're making it up; my gut feeling is that such a rule is akin to "Don't split the infinitive.", "Don't end a sentence with a preposition.", "Don't use which as a restrictive pronoun." etc. i.e. a prescribed rule.

I'm not refusing to fix anything. If something doesn't work properly & it's causing problems, I'd be happy to fix it (if I could spare the time). As for the likelihood of ending up at WP:TFD ... well, anyone can bring it there but putting forth a sufficiently strong case for its deletion is another thing.

Tonne vs metric ton is more a question of vocabulary than spelling but, no, I not so stubborn as to let this detail get in the way of what would be a simplification of the template's use.

So, Gene, it's "improper" to have a preference for British English? How is that so? Of course, by "designer" here you must mean Drumguy not me since I just carried the default from what he had ... my preference is for Australian English. Do tell us what dialect it would be proper to have a preference for. There is no WP:ENGVAR violation here someone's going to have to jump through these "hoops".

Dimensional analysis could be worked in to the template. It wouldn't be easy but not impossible. Are we seeing problems out there with this?

JIMp _talk·cont 09:58, 2 December 2008 (UTC)

You will note that the possessive apostrophe is after the s in the plural designers. Anyone involved is included.

The solution might be that everybody needs to jump through those hoops. No preference; it needs to be specified. As it is, we are getting articles improperly changed to British English or Australian English or whatever.

Rather than dimensional analysis, a sensible alternative to have one template for each "dimension", a group of similar templates having a similar look and feel and using the same subroutine templates to handle the input and the formatting of the output.

Gene Nygaard (talk) 14:02, 2 December 2008 (UTC)

If the sing parameter presently does exactly the same thing as the adj parameter, perhaps a bot run (Lightbot?) could cycle through and convert all uses of it and the sing and the resultant confusion over its meaning, usage, etc. could be eliminated. — Bellhalla (talk) 15:26, 2 December 2008 (UTC)

That would fix half of the problem, and clear the way to accomplish the second half: making "sing" work like it should work. Gene Nygaard (talk) 06:28, 3 December 2008 (UTC)

But a bot probably won't be able to distinguish those cases where it should have been an adjective from those cases where it should have been singular, can it? What convert does with it--that it does the same for either parameter--is immaterial--because what really matters is why the parameter was put there. The conversions using it need to be fixed according to the usage in the article, which depends on whether it is dealing with adjectives or not--it is quite reasonable to assume that a goodly number of people who used "sing=on" did it because they wanted a singular form, not because they wanted an adjective form. Gene Nygaard (talk) 06:33, 3 December 2008 (UTC)

In Wikipedia (and elsewhere) many original authors fail to use a hyphen and many subsequent editors fail to add one. This is consistent with use of the hyphen as a tool to resolve a reasonable ambiguity. The hyphen has other uses but I think hyphen-free [little joke there] forms are perfectly acceptable, and indeed preferable. I have raised this issue on several occasions but I have not managed to persuade others. You and I are in a minority on this issue. Lightmouse (talk) 10:00, 3 December 2008 (UTC)

Actually, I don't have much problem with "adj=on"; it is that hanger-on called "sing=on", a parameter originally misnamed for what it was intended to do, but used by some editors for the purpose implied by its name, which is most in need of fixing. Insisting on hyphens in adjective combinations of measured quantities does indeed clash with the minimalist use of hyphens in other adjective combinations not involving number-unit combinations. But the Wikipedia usage is in fact too extreme towards the non-use of hyphens in the other cases; there are too many of you leaving out hyphens which would make our articles more readable and more easily understood. Gene Nygaard (talk) 14:17, 3 December 2008 (UTC)

Can you give some examples of number-unit combinations where you, personally, would not use a hyphen? Lightmouse (talk) 14:37, 3 December 2008 (UTC)

It is an ideal Lightbot task. Lightmouse (talk) 15:30, 2 December 2008 (UTC)

Suppression

Is it possible to suppress everything except the output figure? What I am looking for is for {{convert|150|ft}} to give 46. CambridgeBayWeather Have a gorilla 16:40, 2 December 2008 (UTC)

No. If in a table they can be displayed as numbers only. I'm not sure what the reasoning would be for only 46 but not displaying the 150 would go against the MOS anyway. —MJCdetroit ^(yak) 01:00, 3 December 2008 (UTC)

I asked for something similar earlier: having a switch to turn off the units. But I would still want it to show both values, with the converted value in parens. I would still like it, if its not too much work. Wizard191 (talk) 02:06, 3 December 2008 (UTC)

That was a bit silly forgetting to say where I wanted to use it. Look at Template:Infobox Airport. The metres/feet are on different lines and have to be manually calculated each time. CambridgeBayWeather Have a gorilla 02:36, 3 December 2008 (UTC)

There's no particular reason why convert should be further complicated to handle that. You are using a template, with incoming named parameters; it should be pretty simple to code in a *.3048 into that template. You don't need to worry about what you use for units symbols or using scientific notation to express the length of those runways or other formatting of the units, just about the right-justification in the tables, etc. Gene Nygaard (talk) 05:45, 3 December 2008 (UTC)

I have no clue how to even begin doing that. Also I wan't sure if convert could do what I was asking already. You have to remember that there are quite a few things it will do that are not covered in the documentation. CambridgeBayWeather Have a gorilla 14:40, 3 December 2008 (UTC)

It could be done & there might be some use for it but in the mean time go with Gene's idea; to do this use elevation-m={{#expr:1234*0.3048round0}} (which gives "376") for 1234 feet rounded to the nearest metre, change the "1234" for a different number of feet change the "0" for a different number of decimal places in the rounding. The best thing to do, though, would be to get the infobox edited so it can do the conversion automatically. JIMp _talk·cont 00:51, 4 December 2008 (UTC)

And then I remembered this. CambridgeBayWeather Have a gorilla 02:59, 4 December 2008 (UTC)

That's right. I'm afraid I just don't have time these days. JIMp _talk·cont 00:15, 5 December 2008 (UTC)

No problem. I figured it was something like that. Anyway I forgot about it so it couldn't have been that urgent. CambridgeBayWeather Have a gorilla 00:32, 5 December 2008 (UTC)

Parameter to spell out single-digit numbers

Would it be possible to add a parameter ("spell=on"?) to spell out single digit numbers? For example {{convert|six|mi|spell=on}} to result in "six miles (ten km)" instead of "6 miles (10 km)"? Note that this would also have to spell out "negative", IE: {{convert|-6|mi|spell=on}} to "negative six miles (ten km) vs. −6-mile (−10 km). I understand that this might be overly complicated, but I thought I should at least ask. Would this ever even be appropriate given MOS:NUM#Numbers? ~ Paul^T+/_C 08:16, 6 December 2008 (UTC)

It is okay to use figures with spelled out unit names (10 kilometers), or to use spelled out numbers with spelled out unit names (ten kilometers), but we should never permit "ten km". Spelled out numbers with unit symbols are unacceptable. Gene Nygaard (talk) 18:21, 6 December 2008 (UTC)

Indeed. Beyond the extraordinary complexity of creating such a setup, I'm afraid you would too often run into a situation where one of the numbers is a single digit and the other is greater than ten, in which case both would have to be either numerical or spelled out (further adding to the complexity). We must not mix formats, so the easiest way to avoid this is keep everything in numerical form. — Huntster (t • @ • c) 23:33, 6 December 2008 (UTC)

There is no real problem with mixing formats for the original number and its conversion; in fact, we routinely do that. Too often, in fact. Gene Nygaard (talk) 00:39, 7 December 2008 (UTC)

Hmm, I recall there previously being a line about not mixing formats in there somewhere. Bah, things change too fast :D — Huntster (t • @ • c) 03:32, 7 December 2008 (UTC)

Mixing formats is only an issue when the two are on an equal footing which is not the case when one is in brackets. JIMp _talk·cont 00:49, 9 December 2008 (UTC)

Trouble with simple range

According to the documentation, this simple example should be correct:

{{convert|6|range|20|ft|m|0}}

That follows the documented example:

{{convert|orig_val1|range|orig_val2|original_unit|conversion_unit|round_to|...}}

But it instead yields Template:Convert/range. Here it is again w/o the nowiki tags, so it should yield something like conversions to 2-7 meters:

6 range

Of course I fear that someone will point out a glaring error in my usage of the template. In that case I'll claim if it's not the macro it's the doco that needs fixin'. Thx. --Kbh3^rdtalk 19:44, 10 December 2008 (UTC)

Looks like the documentation may need some tweaking. These examples demonstrate the range functionality

• {{convert|6|to|20|ft|m|0}} → 6 to 20 feet (2 to 6 m)
• {{convert|6|-|20|ft|m|0}} → 6–20 feet (2–6 m)
• {{convert|6|&|20|ft|m|0}} → 6 &

— Bellhalla (talk) 20:18, 10 December 2008 (UTC)

There's a table a little farther down the doc page that lists the possible values for range in the example, but I added a note to the doc nonetheless. — Bellhalla (talk) 20:23, 10 December 2008 (UTC)

Ah, that makes good sense but wasn't apparent when I read the template page. Thanks! --Kbh3^rdtalk 23:07, 10 December 2008 (UTC)

No problem! — Bellhalla (talk) 00:09, 11 December 2008 (UTC)

Converison request

How do I convert the following?--Nvvchar (talk) 02:52, 8 December 2008 (UTC)

Million cubic metre (MCM) to million acrefeet MAcft)

Cubicmeter/sec (cumecs) to cubicfeet/sec Cusecs)

Billion Cum (BCM) to Trillion cuft (Tcft)

• There's no capacity currently to handle millions of acre feet.
• {{convert|123|m3/s|cuft/s}} → "123 cubic metres per second (4,300 cu ft/s)"
• {{convert|123|e9m3|e9cuft}} → "123 billion cubic metres (4,300×10^⁹ cu ft)"

JIMp _talk·cont 00:55, 9 December 2008 (UTC)

You can even do it better and {{convert|123|km3|e9cuft}} → "123 cubic kilometres (4,300×10^⁹ cu ft)"

Then, when you see that the engineering notation result has a mantissa greater than 1000, you can tweak it to 123 cubic kilometres (4.3×10^¹² cu ft). Gene Nygaard (talk) 06:11, 9 December 2008 (UTC)

As we all know, 1 ha = 2.5 acres. But the following conversions give erroneous results.

1.0 ha (2 acres)

24 ha (59 acres)

Where is the fallacy?--Nvvchar (talk) 06:53, 11 December 2008 (UTC)

{{convert|1.0|ha|acres|0|abbr=on}} -->1.0 ha (2 acres)

{{convert|24|ha|acres|0|abbr=on}} -->24 ha (59 acres)

Those conversions above give those results because you are forcing the template to round to 0 (that's the |0| part shown above). The template is going to do what it is asked to do. As with many tools, it is up to the user to make sure that the outcome makes sense. However, if you are unsure how precise to be, this template (thanks to JimP) has a built-in default rounding function. Exempli gratia:

{{convert|1.0|ha|acre|abbr=on}} -->1.0 ha (2.5 acres)

Notice that the "|0|" part was dropped. Regards,—MJCdetroit ^(yak) 15:16, 11 December 2008 (UTC)

Disambiguation of "miles"

Why do I get disambiguation when I do this?

• {{convert|47|nmi}} → 47 nautical miles (87 km; 54 mi)

Yet I don't appear to even have an option to get disambiguation when I use this?

• {{convert|47|mi}} → 47 miles (76 km)

Or am I just missing some "undocumented feature" (i.e., bug) that will let me do that?

Like common sense says (and for once WP:MOSNUM agrees), we should Use nautical mile or statute mile rather than mile in nautical and aeronautical contexts. Gene Nygaard (talk) 09:04, 12 December 2008 (UTC)

Second point: Why the inconsistencies in usage, where here I need to go to the trouble of specifying a particular unit to avoid getting a multiple conversion to two different units, whereas in most cases I'd need to specify two units in order to conversions to more than one unit?

• {{convert|47|nmi|km}} → 47 nautical miles (87 km)

Things like that make for a really steep learning curve, for an out-of-control behemoth which is already a dangerous weapon in the hands of the typical Wikipedia editor. Gene Nygaard (talk) 09:10, 12 December 2008 (UTC)

I guess the rules are that the MOS is important when it agrees with the viewpoint of the owners of this template, but not otherwise? Gene Nygaard (talk) 10:26, 16 December 2008 (UTC)

Using this template when commas are present.

Here's something that I didn't realize and learned from a discussion that evolved over at Infobox Settlement's talk page. At this point, it is probably only useful for using {{convert}} within the code of other templates, but it is worth repeating here. If formatnum: is used in the code with a |R after the value, it will ignore the comma. So to the convert code's "eye", 1,000 becomes 1000 and convert will reformat the calculated value to have the commas back in the display. The example will probably make more sense than what I just typed.

Example:

In the infobox template code:

{{convert|{{formatnum:{{{area_ha}}}|R}}|ha|acre|abbr=on}}

On some article someone inputs: |area_ha=1,012

This is what the code would do:

{{convert|{{formatnum:1,012|R}}|ha|acre|abbr=on}}--->1,012 ha (2,500 acres)

I don't know if this would be helpful within the convert code itself or not, i.e. {{convert|1,000|acre|ha}} won't spit out an error.

—MJCdetroit ^(yak) 03:07, 17 December 2008 (UTC)

I had realised it before but just fixed it by removing the commas. I don't honestly know how, with the limited Wikicode available, one would strip out the comma (it would be a sinch with a proper scripting language). Orderinchaos 10:40, 17 December 2008 (UTC)

I think MJCdetroit already answered that: there's a formatnum: parser function which can do the job. The request was whether or not it's sensible to suggest moving this check into the template logic itself. This would be a win usability-wise, but I'm not sure whether an ever-increasing amount of hair like that will do the various templates' readability any good. Chris Cunningham (not at work) - talk 11:13, 17 December 2008 (UTC)

Request for conversion units

I have been using {{convert|6|ft|7|in|m|3|abbr=on}}, and I find it very useful.

Could it be possible to do something similar for long tons and hundredweight?

I am editing articles on British steam locomotives, and at the moment in the infobox I have to use {{convert|15.45|LT}}, which could lead another editor into thinking that the precision is greater than my source indicates (i.e. 0.01 long tons, when it is 0.05 long tons).

What I would like is something like {{convert|15|LT|9|cwt|1|abbr=on}} to give an output of "15 long tons 9 cwt (15.7 t)". What I would like to avoid would be the tautology of "15 long tons 9 long cwt (15.7 t)".

I don't think a short ton/hundredweight would be needed, since the short hundredweight was/is hardly used.

Thanks in advance. Iain Bell (talk) 13:19, 17 December 2008 (UTC)

I agree with your points; it's not that the short hundredweight isn't used, but it is rarely used in conjunction with short tons. A conversion from short hundredweight would be useful, but not a combination conversion from short tons and hundredweight. Gene Nygaard (talk) 14:12, 17 December 2008 (UTC)

What to do?

I wish to show metres first followed by feet (for example in the Raung article. I know both without using convert. The altitude of the summit of the volcano is 3,332 metres (10,932 ft) but if I use the template I get 3,332 metres (10,932 ft). Of course the problem is that the measurement in feet implies more precision. This problem comes up often in my editing. I know the value in feet but I wish to show metres first. Is there a way to get the template to behave this way. For example a switch which will force the display order. --DRoll (talk)

Try increasing the precision, as in 3,332 metres (10,932 ft), by using sigfig=5. Otherwise it defaults to the same precision as the input (4 significant figures). However, I would point out that mountaineers can't actually measure elevation to five significant figures, and if it is in Indonesia, they probably measured it in metres in the first place.RockyMtnGuy (talk) 16:34, 25 December 2008 (UTC)

conversion of mpg

why is mpgus being converted to kilometres per litre and not litres per 100 km (or both)? Litres per 100 km seems far more standard measure than kilometres per litre ever has been. I am sure this has been discussed before and am unsure why it has changed? —Preceding unsigned comment added by 121.72.241.142 (talk) 23:41, 17 December 2008 (UTC)

Yeah, what ↑ ↑ he ↑ ↑ said. km/L is not in general use anywhere I'm aware of. L/100 km seems the standard Metric expression of vehicular fuel consumption, and probably ought to be used in this template. —Scheinwerfermann ^T·_C01:09, 18 December 2008 (UTC)

{{convert|18|mpgU.S.}}--->18 miles per U.S. gallon (13 L/100 km; 22 mpg_‑imp)

{{convert|18|mpgUS}}--->18 miles per US gallon (13 L/100 km; 22 mpg_‑imp)

{{convert|20|mpgimp}}--->20 miles per imperial gallon (14 L/100 km; 17 mpg_‑US)

Ought to be and now is. I did the imperial gallon one too. Merry Christmas. —MJCdetroit ^(yak) 01:38, 18 December 2008 (UTC)

So, just what the hell is 13 liters per 100 kilometers per 22 miles per imperial gallon ? It is one, just the plain, dimensionless number, isn't it? Why don't you just say so?

The point is that putting in two conversions separated by a slash is asinine in any case, and especially so when one or both of the units already has another slash indicating division.

Who dreams up this stuff? Gene Nygaard (talk) 04:43, 18 December 2008 (UTC)

Gene, please tone it down a couple notches. Instead of ranting, why not just ask for the problem to be fixed?

MJCdetroit, this needs fixed right away, please. Use &nbsp;&bull;&nbsp; to separate the two converted outputs to yield 18 miles per US gallon (13 L/100 km • 22 mpg_-imp), or as a second preference use &nbsp;&mdash;&nbsp; to yield 18 miles per US gallon (13 L/100 km — 22 mpg_-imp). Either way, the slash as separator has to go away in a hurry. Also, if there is a way to have the initial unit abbreviated in accord with the output units to yield 18 mpg_-US (13 L/100 km • 22 mpg_-imp), please state it. Thanks! —Scheinwerfermann ^T·_C06:09, 18 December 2008 (UTC)

True, slashes were probably a bad choice. They'll be on my list of things to fix when I have the kind of spare time I used to list. Thanks for fixing the defaults up MJCdetroit. JIMp _talk·cont 08:42, 18 December 2008 (UTC)

Well, duh!!!

If you interpret the slashes to mean separation of conversions, you have the three-way conversion

18 miles per U.S. gallon = 13 L

18 miles per U.S. gallon = 100 km

18 miles per U.S. gallon = 22 mpg_-imp

In this case, you not only have a slash indicating division, but also a number in the denominator of one of the units, which always make a mess of things.

Part of it, of course, isn't your problem. Sensible unit-designers would have used L/Mm and generally expressed these measurements without any fractional parts because they wouldn't be significant.Gene Nygaard (talk) 10:44, 18 December 2008 (UTC)

Separator punctuation in multiple conversions e.g. x nmi (x km/x mi)

I think we all agree that something should be done about slashes. The question is what would replace it.

• Little short line. I don't like any little short line because they all look like minus to me.
• Bullet. I don't like a bullet because people wouldn't use the same format when writing raw text. The format must also be practical for non-template conversions.
• Period. I don't like a period because that looks like a multiplier.
• Comma. I use this format myself in raw text and I propose a comma.

Lightmouse (talk) 12:28, 18 December 2008 (UTC)

I like the bullet or the comma. —MJCdetroit ^(yak) 15:07, 18 December 2008 (UTC)

Lightmouse, I agree with your distaste for any horizontal line — I presented it as a second-preference option because despite its looking like a minus, it's better than a slash. I also agree that we can do better than a period, and for the same reason I wouldn't want to see a mid-dot ·

I do not agree with your distaste for the bullet. You're arguably right that people might not write a bullet in raw text, though I have seen many do just that. Nevertheless, we do a great deal of formatting here on Wikipedia, whether automagically by template or manually by plain old edits, that nobody would ever write with a pencil, a typewriter, or a word processor. I can live with the comma, but I prefer the bullet. I'm not sure what you mean in suggesting the bullet isn't practical for non-template usage. Anybody can type &bull; just as easily as anyone can type &nbsp; or &mdash; or <sup> or any of the many other bits of markup used to create special characters regularly used on Wikipedia. —Scheinwerfermann ^T·_C15:37, 18 December 2008 (UTC)

We have nice little English words which will work fine. Use or; it is a lot better than any of the unconventional punctuation suggestions. Gene Nygaard (talk) 15:41, 18 December 2008 (UTC)

I do not support the use of or or any other word for this purpose. An appropriately-selected punctuation mark will do fine. —Scheinwerfermann ^T·_C16:36, 18 December 2008 (UTC)

Well, what do we want to do? It looks as if it would take about 6 edits to change this for the whole template. Bullet or comma: 10 U.S. gallons (8.3 imp gal • 38 L) or 10 U.S. gallons (8.3 imp gal, 38 L)? —MJCdetroit ^(yak) 17:48, 22 December 2008 (UTC)

Since no pages were linking to the "multi3" subtemplates, I changed those to see how it would look:

{{convert|18|C|K F R}}------------->18 °C (291 K • 64 °F • 524 °R)

Thoughts? —MJCdetroit ^(yak)

Comma please. But please don't add code to prevent line wrap between units. Line wrapping is a good thing.

quantity	value
volume	10 U.S. gal (8.3 imp gal, 38 L)
length	10 nmi (19 km, 12 mi)

Lightmouse (talk) 18:20, 22 December 2008 (UTC)

That can be done if others agree. At this point we agree that the slashes gotta go. —MJCdetroit ^(yak) 18:34, 22 December 2008 (UTC)

Slashes gotta go; use "or". Replacing a division sign with a multiplication sign or a subtraction sign is no improvement. Gene Nygaard (talk) 20:09, 22 December 2008 (UTC)

Using a word like "or" is a nonstarter, and nobody's proposing the use of a multiplication sign. Lightmouse' visual example of the box convinces me that the comma is a better choice than the bullet — let's go that way. —Scheinwerfermann ^T·_C20:21, 22 December 2008 (UTC)

MJCdetroit objected to a period, saying "I don't like a period because that looks like a multiplier." Well, a period does not look like a multiplier in any standard usage in mathematics. A bullet, on the other hand, does. Gene Nygaard (talk) 01:43, 23 December 2008 (UTC)

Bullet (from before): {{convert|18|C|K F R}}------------->18 °C (291 K • 64 °F • 524 °R)

Commas (now): {{convert|18|C|K F R}}------------->18 °C (291 K; 64 °F; 524 °R)

Let's see if anyone else has any other thoughts before we make the leap with the "multi2" conversions. Give it say 24 hours. —MJCdetroit ^(yak) 21:02, 22 December 2008 (UTC)

Commas seem visually cleaner in this instance, and have a wider variety of applications. — Huntster (t • @ • c) 03:45, 23 December 2008 (UTC)

I stated what about a period? Where? Ummmmmmm no I didn't. That was Lightmouse. —MJCdetroit ^(yak) 04:19, 23 December 2008 (UTC)

Guess I just couldn't imagine that you would have been brief enough so that the box full of big flashy colors didn't go with the paragraph to which it was attached, but only with a half-line comment. One of the hazards of your vanity, I guess. Gene Nygaard (talk) 10:37, 23 December 2008 (UTC)

And ladies and gentlemen, that's Classic Gene Nygaard! A disposition and a personality that ensures that the next generation is safe! And that things stay "interesting" around here with the stuff that he rants about. Merry Christmas to all, even to you GN. —MJCdetroit ^(yak) 14:33, 23 December 2008 (UTC)

Commas or semicolons should be used to separate conversions. The other punctuation marks (slash, bullet, hyphen, period, etc.) can appear as part of the unit abbreviations.RockyMtnGuy (talk) 15:46, 23 December 2008 (UTC)

 Done, but not set in stone.----->19.5 miles per imperial gallon (14.5 L/100 km; 16.2 mpg_‑US)

It takes about 5 minutes to change, so if we want to debate whether a semicolon would be better and decide it is— we can change it.

Or course this will make some odd looking combination if someone tries to use the |disp=or [19.5 nautical miles or 22.4 miles or 36.1 kilometres] or the |disp=s [19.5 nautical miles (22.4 mi; 36.1 km)] with multiple conversions. Merry Christmas, Y'all, —MJCdetroit ^(yak) 05:44, 24 December 2008 (UTC)

Thanks. I think comma is definitely better than a colon. I think comma is marginally better than a semi-colon but User:Tony1 might be a good person to consult on this usage, I will contact him. I have never used the 'disp' option but it seems to me that it should apply to both separator locations. Lightmouse (talk) 11:25, 24 December 2008 (UTC)

I think a semicolon looks and functions best; a comma is OK. Both would need to be followed by a space (therefore one of those pesky non-breaking spaces - nice if the template does it automatically). The bullet is unspeakable. A period is no good. "Or" is ambiguous in English - is it an equative or (yes) or an either or? The slash has to go, especially as it works poorly unspaced when the items it breaks themselves contain internal spaces. Tony (talk) 14:15, 24 December 2008 (UTC)

There is absolutely no justification whatsoever for a nonbreaking space between separate conversions. Gene Nygaard (talk) 14:48, 24 December 2008 (UTC)

And are you being serious? Would you actually think that if you saw an "or" that it might be 58 km or it might be 36 mi, but it couldn't be both? Or even that there is a single reader of Wikipedia who'd be that bone-headed? Gene Nygaard (talk) 14:59, 24 December 2008 (UTC)

Gene, you've been blocked for incivility numerous times before. You've been asked to keep it civil; your mealymouthed behaviour will not remain consequence-free much longer. If you don't want to get another time-out, I suggest you start minding your manners more carefully now. If you have input into the topic at hand, provide it in a grownup manner, without the editorialising and judgemental vitriol. If you are unable to do so, you may as well be quiet — this thread demonstrates I'm not the only one disinclined to pay attention to what you're saying because of your bellicose tone. —Scheinwerfermann ^T·_C16:13, 24 December 2008 (UTC)

Switch to a semicolon

Using a semicolon was brought up by R.M.G. and Tony1 above. So I asked over at Reference desk/Language which would be preferred: a comma or a semicolon in the multiple conversion. There was a preference for the semicolon in something like 750,000 Imperial gallons (3,400,000 L; 900,000 US gal). Given the outside input, has anyone fallen in love with the comma that we switched to before Christmas? Otherwise we should switch over R.M.G. and Tony1's suggestion of using a semicolon. —MJCdetroit ^(yak) 04:28, 30 December 2008 (UTC)

Switching to the semicolon is fine by me. Lightmouse (talk) 07:25, 30 December 2008 (UTC)

Something seems to be wonky

Can anyone explain why {{convert|64|in|cm}} looks like 64 inches (160 cm) i.e. is coming out 160 cm instead of 162.56 or 163 cm the way it does in other online calculators??? Examples include Arabian_horse#Size and weight and Thoroughbred. There are several articles where we are having problems. Montanabw^(talk) 01:18, 18 December 2008 (UTC)

I started to type out an explanation for how the template does the default rounding, but I know I'll F' up the explanation. It involves heavy-duty math. I know how to calculate the math but I can't give a good enough explanation of it. Maybe Jimp can give an acceptable answer.

Try forcing the rounding {{convert|64|in|cm|0}} looks like 64 inches (163 cm)

—MJCdetroit ^(yak) 02:40, 18 December 2008 (UTC)

See the FAQ at the top of this talk page page, which points you to the place in the documentation where this is discussed. — Bellhalla (talk) 04:29, 18 December 2008 (UTC)

The precision of the input number can be expressed as an interger, p_i, where p_i is the order of magnitude of the last significant digit (i.e. the number of decimal places or, for whole numbers, the negative of the number of zeros at the end of the number; e.g. the presision of 64 is 0, for 6.40 it's 2 & for 6400 it's −2). The template calculates this interger. This, of course is the precision of the input number whereas we want a measure of the precision of the input value (1.234 is more precise than 1234 but 1.234 km and 1234 m have the same degree of precision). Thus we need to take the input unit into account. To do this the template subtracts a factor, j_i, where j_i = log₁₀(1 u_i⁄1 u_b) and u_i is the input unit and u_b the (multiples of) SI unit(s) for measuring that quantity. The template then adds a similarly defined j_o for the output unit to give the desired precision for the output number. Of course, this is generally not an interger so has to be rounded, which is done according to the rule p_o + log₁₀(2) ≈> p_i − p_i + p_i ≈> p_o + log₁₀(2) – 1 (using "≈>" to indicate a sort of fuzziness around the border, as can't really be helped, nor need it be). Well, there's the maths. The link should probably explain things in more plain English but, breifly, since an inch is more than two centimetres the template automatically rounds up to the nearest 10 cm. JIMp _talk·cont 09:58, 18 December 2008 (UTC)

OK, so in plain English, the bottom line is that when a calculation is off by a good two centermeters, that is a problem! I'm afraid I lack the expertise to even think about ME fixing the template. And we use this template on hundreds of articles, so myself going in and changing the template is not really feasable. Why is it not set up to convert based on 2.54 or whatever makes these things be a bit more accurate? Long story short, this is about to start an edit war over on some articles on my watchlist, someone is VERY upset at the inaccuracies in the template and is manually changing several articles. For the sake of peace at wikiproject Equine, can anyone fix this? Montanabw^(talk) 03:02, 21 December 2008 (UTC)

Try the false precision article, or a good mathematics textbook, physics textbook, Wikipedia article, whatever discussing precision and accuracy of measurements. Then come back here and admit that you were wrong, and for once this template was right. Gene Nygaard (talk) 05:28, 21 December 2008 (UTC)

Let me revise that; right much of the time, and in particular in the example Montanabw gave. It does, however, get wonky in other cases—for example, if you try something like:

{{convert|11/16|in|Å}} → 11⁄16 inch (170,000,000 Å)

The default result of 174,625,000.0000000 Å certainly isn't reasonable in this case; and it is a problem I pointed out ages ago. Gene Nygaard (talk) 05:34, 21 December 2008 (UTC)

(edit conficted) Stopping just short of calling Montanabw retarded...nice. Way to be civil there Dr. Kaczynski.

(edit conficted) Montanabw, add the "|0" to the input parameters (as I showed above) and that should help with the VERY upset person. —MJCdetroit ^(yak) 05:50, 21 December 2008 (UTC)

(after many, many ECs) Montanabw, this is not an error, really. It is a matter of precision. "64" has two significant digits, and so the output by default also has two significant digits...thus turning 162.56 (five significant digits) to 160 (two significant digits) through rounding. It's a math thing...the calculations in this case are exact, but they are outputted to a rounded form which accurately matches the precision of the input. For example, if the input had been 64.29 inches, the output would have been (by default) 163.3 cm...four significant digits. If you want to have a higher level of accuracy, simply use this form, {{convert|64|in|cm|0}}, to render "163". If even greater accuracy is desired (though it really should not be used in my opinion), change the "|0" to "|-1" or "|-2". Is that clearer?

Also, I should point out, if editors want to manually add conversions rather than use this template, so long as all the information is correct, there is no reason why they should not do so. {{Convert}} is not mandatory by any means.

And Gene, may I ask that you please remain civil? If an editor is confused as to why a template does something the talk page is without reservation the correct place to ask questions. It seems readily apparent to me that Montanabw simply wasn't aware of the maths involved...he needn't admit to being right or wrong. Simple misunderstanding. Though the inches-Angstrom case is a bit...ahem...wonky :P — Huntster (t • @ • c) 05:39, 21 December 2008 (UTC)

Yes, I probably did go a bit overboard. Sorry, Montanabw. Others have had more patience and explained it better. Though Hunster seems to be going in the wrong direction. Instead of 0, -1 etc. to get less precision, try using 1 or 2 or 3 to get the more precision you desire, Montanabw. But don't actually use too much precision if you put the template in an article.

Conversions like

{{convert|11/16|in}} → 11⁄16 inch (17 mm)

are wonky not only because of the precision involved, but also because of the refusal to fix the "inches" part to read "inch", not only in refusing to fix the default but also by refusing to make "sing=on", a longstanding but broken parameter for this template, actually work so we could do it manually. Gene Nygaard (talk) 09:28, 21 December 2008 (UTC)

Re the last:

{{convert|11/16|in|sing=on}} → 11⁄16-inch (17 mm)

does give you "inch", granted—but it also gives you a hyphen which doesn't belong there. It is broken. Gene Nygaard (talk) 09:32, 21 December 2008 (UTC)

Oops, thanks for the correction, I did mean 0, 1, 2. — Huntster (t • @ • c) 11:02, 21 December 2008 (UTC)

OK, my head just exploded. And Gene, that first remark wasn't nice but I accept your apology--I wasn't attempting to destroy your template, and please be grateful that I felt no urge to go in there and try to tweak it! =:-O LOL! As a non-mathematician, silly me, I thought it was a simple 1 inch = 2.54 cm rounded to the nearest whole number. If the |0 thing solves the problem, then that's what I shall do. And thanks. However, it still seems totally weird to me that a template can't round a whole number to produce another whole number...though I suppose when we are talking miles and km instead of cm and inches, I guess it does become more of an issue...? And in the meantime, I must say that stumbling into this little corner of wiki is making equine coat color genetics seem as simple as Candyland (where minimal counting ability is required! LOL!). Montanabw^(talk) 05:30, 22 December 2008 (UTC)

Yeah it's simply using significant figures instead of decimal places. The |0 overrides that behaviour. And yes I know the feeling well, although I did maths and science at university level about 10 years ago my major field is social sciences these days, so a lot of it flies way above my head :) Orderinchaos 08:20, 22 December 2008 (UTC)

Now, for the higher-math-impaired amongst us, is this " |0 " parameter something that we should be always using on other convert templates, such as kg to lb or mi to km, etc...? Or will these larger sizes come out OK enough for the purposes of things like weighing horses (in the 800-200 lb range) or measuring racetracks and speed (as in between 4 and 40 mph or 1/4 mile to 100 mile distances)? Most of the time, whole numbers are acceptable, and we don't usually need decimal precision more than in tenths, and that only in distances, as a rule. (i.e. 1-1/4 mi to X.X km). Thanks... Montanabw^(talk) 07:11, 24 December 2008 (UTC)

Yes, it works like that for other units, too. Being as you admit to being math-impaired, you are probably best off leaving it where the default puts you; it's likely to be better than whatever you might change it to. Most importantly, "whole numbers" is at best a minor consideration when the choice is between that and tenths—many of the conversions we use should be rounded off far to the left or far to the right of the decimal point. Leave the precision blank, unless you are sure that it should have more or less precision than the default gives you. If you aren't sure, ask on the article's talk page how precisely the conversion would reasonably be stated; there'll likely be someone who understands the precision of numbers better who can help you out. One of the nuances they will understand is the difference between a measured quantity (like the weight of a horse) and a designed or defined quantity (like the length of a racetrack). That affects how precisely it is reasonable to express the conversion; it is usually only in those design/definition cases where more precision should be added than what the default gives you, other than the randomness of a number with a final zero or zeros that are actually significant but not obvious from the measurement itself (this can sometimes be identified when there are a series of similar measurements in the article. Gene Nygaard (talk) 13:39, 24 December 2008 (UTC)

So, for someone such as myself, If I want to convert inches to cm in terms of the height of horses (roughly 38 inches for really little ponies to 72 in for a really big draft horse), adding the "|0" to the convert template seems to generate a more "accurate" result, but for everything else, I'll be better off to just use convert template as is without any modifiers like "|0" until someone complains that it isn't converting accurately (??), at which point I can come here and ask for help again? (grin) Montanabw^(talk) 00:06, 30 December 2008 (UTC)

I would suggest always using the default output until someone complains, and then adjust the precision to "|0" or whatever to render the desired appearance. You are always welcome to ask for assistance, but if you just manipulate that one parameter to the desired output, you're likely to not need any help. — Huntster (t • @ • c) 00:30, 30 December 2008 (UTC)

Can't convert more than 2 inputs

{{convert|12|by|34|in|mm|1|abbr=on}} yields 12 by 34 in (304.8 by 863.6 mm), but {{convert|12|by|34|by|5|in|mm|1|abbr=on}} doesn't work; it yields a template loop. Can it be fixed? —Scheinwerfermann ^T·_C18:28, 25 December 2008 (UTC)

Everything can be fixed but this is not going to be easy (it was tricky enough getting two working). I will look into it. JIMp _talk·cont 10:49, 29 December 2008 (UTC)

Thanks — I appreciate your work! —Scheinwerfermann ^T·_C19:53, 29 December 2008 (UTC)

miles and chains

I'm trying to use {{convert|4|mi|72|chain|km}} to convert miles and chains into km, which gives the result 4 miles 72 chains (7.9 km) (see Dolgoch railway station). Is it possible to link chains to Chain (length) as per WP:CONTEXT, without linking miles? —  Tivedshambo  _(t/c) 23:40, 29 December 2008 (UTC)

Range of values

Is it possible (easy) to get the word "or" as an alternate in the range, {{convert|250|or|500|abb=on}}? So that "carrying two 250 or 500 pound bombs" can become "carrying two 250 or 500 lb (110 or 230 kg) bombs". CambridgeBayWeather Have a gorilla 17:36, 30 December 2008 (UTC)