Template talk:Convert/Archive September 2010

Seems Convert is wrong

Seems to me 'Convert' is 'wrong' (inappropriate) most of the time - for instance we have items roughly 1 metre long (say 0.5 to 1.5 metres in actuality) converted to '3.3 ft' - just in case I need to explain why that's bad = 1/. Decimal feet is nasty, nasty, nasty 2/. 'roughly 1 metre' is 'roughly 3 ft'. The answer is simple DON'T USE CONVERT!!! - write it out explicitly! I vote for removing the Convert function from Wikipedia. 207.245.198.135 (talk) 11:42, 19 August 2010 (UTC)

• Read the doc page. To round to nearest foot, then append bar-zero "|0". For a range, use: {{convert|0.5|-|1.5|m|ft}} → 0.5–1.5 metres (1.6–4.9 ft). From that range, then write in words: "roughly 1 metre is roughly 2-5 ft" or "roughly 2, 3, 4 or 5 feet" to not be wrong. However, you might be thinking of "nearly" as "nearly 1 metre is nearly 3 ft". -Wikid77 (talk) 25 August 2010, revised 12:38, 4 September 2010 (UTC)

Default precision for miles to km

I appreciate it's difficult to come up with a "one size fits all" default precision, but I am irritated by the fact that, for example, {{convert|3|mi|km}} gives {{#ifeq:|on|<span style="display:none">{{padleft:{{FORMATNUM:3|R}}|16|0}}</span>}}{{convert/{{#if:1|mi}}|{{FORMATNUM:3|R}}|{{#ifeq:{{#expr:km*0}}|0|0}}|km||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LoffAoffDbSoff|s=}}; 3 miles has a precision of ±805 m whereas 4.8 km has a precision of ±50 m, which is inappropriate. I keep finding myself having to add "|0" to conversions that other editors have inserted, to correct for this. Would it be possible to have a more appropriate default precision without breaking anything else? -- Dr Greg  talk  20:00, 27 July 2010 (UTC)

I've been proposing that for years, but then I gave up. A. di M. (formerly Army1987) (talk) 21:25, 28 July 2010 (UTC)

• There will always be precision problems because of using a single number to represent a rounded measurement range. In the above example, "3 miles" is rounded for "2.5-3.49" and if a range-conversion is used, then the precision can be very accurate:

{convert|2.5|-|3.49|mi|km|1} → 2.5–3.49 miles (4.0–5.6 km)

Using a range, then people would not be mislead by seeing 4.8 km when the distance is actually between 4.0–5.6 km. Unfortunately, many people would find such precision irritating (such as Spock saying the time was "9:15 and 7.3451 seconds"). However, the use of ranges is one possibility to avoid the dangerous risk of people thinking 4.8 km as an accurate value for the specific 3 miles intended. Please consider using range-conversions where there is extreme risk of horrific consequences when rounding an amount. -Wikid77 (talk) 06:32, 15 August 2010 (UTC)

I appreciate everything you say. But it's not me having the problem, it's everyone else(!) I know I need to put a "|0" on the end to get a sensible answer, but it seems lots of other editors don't know that, and don't appreciate that there is a problem in the first place. I'm having to correct other editor's mistakes and it would be nice if I didn't have to! I still don't understand why the current default behaviour was chosen that way. Or maybe it just happened by accident and no-one noticed it was a poor choice? -- Dr Greg  talk  10:45, 15 August 2010 (UTC)

• Most people don't care beyond 4.8 km. Perhaps only 1 in 28,000 readers even fix a mangled article. The precision for miles & km has been debated, and I am in favor of using "number sense" to auto-adjust rounding the precision of numbers based on typical cultural usage. This led to having {{Gconvert}} to convert amounts for general-purpose text, whereas {Convert} is an {Econvert} or Engineering-Convert to round by counting the trailing zeroes. Some engineers want "100" to mean "50-149" but general readers think 100 is the "middle of 99-101". Yet, almost every article intends 500 to be a rounded number, from ~480-520. However, the whole subject becomes more complex due to the underlying difference in numeric precision: {{{1}}} Hence, each mile digit maps to 1.61 digits of kilometres, but the concept of 1.61 digits is awkward (like saying the average family has 2.3 children). In general, it might be best to consider each case as a hand-edited problem within each article, as you have done, while also editing articles for other issues, such as spellings and the placement of commas, plus correcting the titles and page numbers in source footnotes. Then, remember some people hate all conversions, because when they read "16 km" they don't want to see "(10 miles)" at all. There is no perfect answer, and any text written is a balancing act to try to satisfy all readers to some extent. -Wikid77 (talk) 12:38, 4 September 2010 (UTC)

Hanging hyphen with range of values and adjectival form

{{convert|18|and|19|in|mm|adj=mid|-diameter}} wheels   produces:   18-and-19-inch-diameter (460 and 480 mm) wheels

The hanging hyphen should be employed: 18- and 19-inch-diameter (460 and 480 mm) wheels

This applies to "adj=on" and "adj=mid" with "and", "or", "to" and "x".

WP:HYPHEN states: A hanging hyphen is used when two compound adjectives are separated (two- and three-digit numbers, a ten-car or -truck convoy)

I know this is asking a lot, but I'm one of your best customers. ;-)   Chris the speller (talk) 21:28, 4 September 2010 (UTC)

Foot, inches, ultra-short

{{Convert|6|ft|5|in|m|2|abbr=on|lk=off}} produces 6 ft 5 in (1.96 m). Now can we add a parameter so that the template produces 6′ 5″ (1.96 m)? —bender235 (talk) 14:22, 10 September 2010 (UTC)

But WP:MOSNUM says to use standard abbreviations, "in for the inch (not in., the quotation mark ", or the double prime ″), and ft for foot (not ft., the apostrophe ', or the prime ′)".

We shouldn't provide tools that run contrary to the MOS. Chris the speller (talk) 18:01, 10 September 2010 (UTC)

Okay. I didn't know MOS said that. Never mind. —bender235 (talk) 20:32, 10 September 2010 (UTC)

Flow conversion

Where are the flow conversions for this? Ideas would be like cubic meters ber second to gallons per minute or vice versa. Any thoughts or ideas as well. Chris (talk) 14:28, 10 September 2010 (UTC)

Template:Height versus Template:Convert

I was comparing the two templates. The half inch precision in template:Height seems to me to be excessive.

• {height|m=1.82} -> 1.82 m (5 ft 11+1⁄2 in) but {convert|1.82|m|abbr=on} -> 1.82 m (6 ft 0 in)

Template:height also seems to have a basic error:

• {height|m=1.52} -> 1.52 m (5 ft 0 in) but {convert|1.52|m|abbr=on} -> 1.52 m (5 ft 0 in)

I think template:Height predates template:convert. I think the convert template is better. Perhaps we could reduce the number of unit templates, particularly if the outcomes can be improved. What do others think? Lightmouse (talk) 10:41, 23 August 2010 (UTC)

The difference in precision has been pointed out before. The complexity of this template is also problematic in that it often breaks when used in conjunction with other templates. I can see the point about the height template being a bit too precise, but many have commented that the convert template is, by default, not precise enough when used for heights. I can point you to the earlier discussion on this issue if you want, but you can probably find them by searching the archives. The fact that the complexity of the convert template often breaks transclusions is probably the most serious. I know Wikid77 has been working on reducing the transclusion depth to try to address this issue. Plastikspork _―Œ^(talk) 19:32, 23 August 2010 (UTC)

By the way, the precision problem in {{height}} can be controlled by the |precision=. For example, precision=0. There is also |frac=, which specifies the denominator for fractional components. The default is 2. Plastikspork _―Œ^(talk) 19:39, 23 August 2010 (UTC)

Thanks for the precision tip. Taking the more generic point, I think it's time to reduce the number and variety of conversion templates. Could we go through Category:Conversion_templates and migrate non-transclusions to {{convert}}? Lightmouse (talk) 13:17, 29 August 2010 (UTC)

I believe the "4 ft 12 in" and "5 ft 12 in" problem has been fixed in {{height}} by fixing the algorithm used in {{m to ft in}}. I agree with your point about reducing the variety and number. Now, if we could just get this template to stop producing parser function errors (see templates in Category:ParserFunction errors). I believe this has something to do with the complexity of this template, as was alluded to below. Plastikspork _―Œ^(talk) 18:39, 12 September 2010 (UTC)

Category: ParserFunction errors

Does anyone have any idea why this template fails in simple cases? For example, I had to make this edit to pull this out of Category: ParserFunction errors. If you look at a random sample of pages in that category, many are due to this template throwing errors. I am guessing it may have something due to the complexity and the mediawiki backend not expanding things in the correct order or something. I have seen references to this problem in the archives of this page and the various village pumps for years. 64.128.201.49 (talk) 19:58, 10 September 2010 (UTC)

The question has to be, what has been changed recently that would so completely fubar the conversion of inches? Why would {{convert|200|in|cm}} work fine here (200 inches (510 cm)) but not in that article? When I have some free time I'll play around with that article and see what's going on. I suspect it may be some kind of interaction between the convert template and the infobox templates. Very odd. — Huntster (t @ c) 18:51, 12 September 2010 (UTC)

Why different characters for ½?

{{Convert|5|ft|10+1/2|in|cm|0}} produces 5 feet 10+1⁄2 inches (179 cm), while {{Convert|70+1/2|in|cm|0}} produces 70+1⁄2 inches (179 cm). Why does this template use different "ways" to display one half? Maybe there's a reason I don't see right now, somebody please explain. —bender235 (talk) 01:11, 13 September 2010 (UTC)

I believe it is because the first uses Template:Convert/and/frn1 (which outputs proper fractions) and the second uses Template:Convert/numdisp/frac1 (which manually outputs fractions), but I have no idea how to resolve the issue. — Huntster (t @ c) 04:45, 13 September 2010 (UTC)

Nbsp?

I'd expect the template to use nbsp between the figure and the unit, but it doesn't. (At least e.g. when converting acres to square meters.) Is this a some kind of omission, or it's by design? GregorB (talk) 12:56, 28 August 2010 (UTC)

• It's an omission (or lack of following the design in some cases). Ideally, Convert should wrap only between large numbers and long unit names. This is the current wrapping:

23 acres (93,000 m2)	23,000 acres (93,000,000 m2)	45 kilometres (28 mi)	45,000,000 kilometres (28,000,000 mi)
Nowrap whole conversion:			23 acres (93,000 m2)

If possible just nowrap the whole conversion as {{nowrap|{{convert...}} }} until the wrapping problem can be fixed. Thanks. -Wikid77 (talk) 20:43, 28 August 2010 (UTC)

I was about to question the lack of nbsp as well, when GregorB did so first. The MOS says to use them "in expressions in which figures and abbreviations (or symbols) are separated by a space". So I advise doing it on the output side first, e.g. after '28' in '45 kilometres (28 mi)'. On the input side, we needn't bother except when using 'abbr=on' and 'abbr=in', and I'm guessing that they are heavily used in tables, less so in running text, which is what the MOS is more concerned with. Chris the speller (talk) 22:36, 28 August 2010 (UTC)

Unfortunately, it looks like the input side will not wrap. This makes the table disappear off the right of the screen. Wrapping can be a good thing, particularly when the table/screen ratio is high and/or the user is using a portable device with a small screen. The aesthetic concern is always a trade off against a requirement to to scroll right, or worse losing part of the table. Lightmouse (talk) 22:26, 31 August 2010 (UTC)

I am modifying the Convert subtemplates for "abbr=mos" to match the WP:MOS style for not wrapping numbers with symbols. Some examples using "abbr=mos":

23 acres (93,000 m2)

23,000 acres (93,000,000 m2)

45 kilometres (28 mi)

3,400 kilometres (2,100 mi)

45,000,000 kilometres (28,000,000 mi)

For amounts above 999, the unit name ("kilometres") will wrap after a long number, but the symbol "mi" will not wrap, when using "abbr=mos". The subtemplates to handle abbr=mos are intended to be changed to match the current text style defined by WP:MOS. After abbr=mos seems to be working for most cases, then the other subtemplates can be updated to match. These subtemplates have reached the complexity level where an initial improvement in one area often causes equivalent or worse problems in another area, so that is why "abbr=mos" should be developed (and tested) further, before updating the other options. -Wikid77 (talk) 13:21, 4 September 2010 (UTC)

Template:Convert/doc#Parameters still under construction says: "abbr=mos For ranges, abbreviates as in WP:MOS, with the input unit repeated, twice." But that isn't what WP:MOS says. WP:MOS does require &nbsp; as discussed above, but MOS:#Units of measurement now refers questions like "input unit repeated, twice" to MOS:NUM, which says: "Numerical ranges use unspaced en dashes if only one unit symbol is used at the end (e.g. 5.9–6.3 kg), and spaced en dashes if two symbols are used (e.g., 3 μm – 1 mm); ranges in prose can be specified using either unit symbol or unit names, and units can be stated either after both numerical values or after the last (e.g., from 5.9 to 6.3 kilograms, from 5.9 kilograms to 6.3 kilograms, from 5.9 to 6.3 kg and from 5.9 kg to 6.3 kg are all acceptable)." Art LaPella (talk) 16:50, 10 September 2010 (UTC)

So I rephrased it. Art LaPella (talk) 21:49, 14 September 2010 (UTC)

Energy - documentation

Experiments show that tera and peta joules (TJ, PJ) are supported, but the documentation doesn't mention this. Can it be updated please. (ok so it does say it's the abridged list - but I can't find anyother lists...) Sf5xeplus (talk) 19:42, 14 September 2010 (UTC)

Unit request

I don't know how hard it is to add another type of unit, but in the mechanical engineering field surface finishes are often measured in microinches (μin) in the US. The metric conversion is the micrometer {μm). 1 μin = 0.025 μm. So if its not to hard to implement I would greatly appreciate it. Thanks! Wizard191 (talk) 14:08, 18 September 2010 (UTC)

You meant 0.0254 μm, exactly. Art LaPella (talk) 22:18, 18 September 2010 (UTC)

Oops...yeah, that's what I meant. Wizard191 (talk) 12:40, 20 September 2010 (UTC)

1 microinch (25 nm) JIMp _talk·cont 10:59, 21 September 2010 (UTC)

Sweet! Thanks again! Wizard191 (talk) 13:31, 21 September 2010 (UTC)