Jump to content

Template talk:Convert/Archive November 2010

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Documentation garbled

Is it just me (system Windows7, browser Chrome) or is the documentation page garbled, showing lots of curly brackets { and }.

I came there to look for the option of inverted units, like "per square meter". Could not see any.

−Woodstone (talk) 12:07, 2 November 2010 (UTC)

Garbling solved. It was caused by Emausbot messing up the used template {{in5}}. −Woodstone (talk) 13:58, 2 November 2010 (UTC)
Question now answered by being able to read documentation. −Woodstone (talk) 13:58, 2 November 2010 (UTC)

Problem?

At Jack Swagger, the convert template is used twice for his weights - one his actual weight (260 lbs) and one his 'billed' weight, which is slightly higher at 263 lbs. However, according to the template 260 lbs = 120 kg and 263 is 119 kg. Demomstration: 260 lb (120 kg) and 263 lb (119 kg). Maybe it's just me, but I'd expect the value that's higher in lbs to be higher in kg, not lower. Is this a problem with the template or what? NiciVampireHeart 18:58, 7 November 2010 (UTC)

The template assumes that 260 lb is rounded to the nearest ten pounds, and rounds the output to the nearest ten kilos accordingly. Try 260 pounds (118 kg). A. di M. (talk) 19:30, 7 November 2010 (UTC)
Great. Thank you. NiciVampireHeart 19:38, 7 November 2010 (UTC)

Inquiry

Is anyone interested in re-writing {{pop density km2 to mi2}} to utilize the functionality of {{convert}}? The former is used in a number of infoboxes, and could really benefit from the significant figures logic which {{convert}} provides. Anyone up to this task?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 8, 2010; 15:52 (UTC)

Why not just replace it with convert?
*{{convert|123|PD/km2}}
*{{convert|123|/km2}}
*{{convert|123|PD/km2|abbr=on}}
*{{convert|123|/km2|abbr=on}}
*{{convert|123|PD/km2|abbr=none}}
*{{convert|123|/km2|abbr=none}}
  • 123 inhabitants per square kilometre (320/sq mi)
  • 123 per square kilometre (320/sq mi)
  • 123/km2 (320/sq mi)
  • 123/km2 (320/sq mi)
  • 123 inhabitants per square kilometre (320 inhabitants per square mile)
  • 123 per square kilometre (320 per square mile)
JIMp talk·cont 19:26, 8 November 2010 (UTC)
Ah, I did not know that {{Convert}} already supports this. Thanks!—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 8, 2010; 19:28 (UTC)

There are under 1500 transclusions but here's a rewrite if you want something in the mean time. 

<includeonly>{{convert|{{{1|{{{num}}}}}}|PD/km2|PD/sqmi|{{{precision|}}}
|lk={{#ifeq:{{lc:{{{wiki}}}}}|yes|on|off}}
|abbr={{#switch:{{lc:{{{abbr}}}}}|yes=on|no=none|off}}
|sp={{#switch:{{lc:{{{spell}}}}}|uk|commonwealth=com|us}}}}</includeonly>

JIMp talk·cont 19:37, 8 November 2010 (UTC)

Nah, I just replaced the whole template call with Convert. Works just fine. Thanks!—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 8, 2010; 19:52 (UTC)
I agree that replacing is probably a better idea, since this template frequently breaks due to transclusion depth problems. Adding one more level to the transclusion depth will not help. Plastikspork ―Œ(talk) 21:09, 8 November 2010 (UTC)
I only replaced it in one infobox, however. It should probably be purged from all other infoboxes which utilize it and then deprecated. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 8, 2010; 21:16 (UTC)
Sounds good. If you find that the implementation shows red errors on the transclusion of the doc page, then it's due to the transclusion depth problem. The reason is that the {{documentation}} template adds 3 to the transclusion depth, and the infobox may add 1 or 2, which is enough to hit the limit in many cases. Plastikspork ―Œ(talk) 21:20, 8 November 2010 (UTC)

no default for spelling

I don't want to get into a huge argument here (I don't have the time or desire to participate in one, regardless), and I realize that this is probably just re-opening a large can of worms, but...

That damn spelling parameter is just annoying. Why can't the default be taken away, so that the parameter must be supplied? That would at least blunt arguments about spelling, and this template imposing a style on articles.

That's all I wanted to suggest. Thanks!
— V = IR (Talk • Contribs) 22:18, 8 November 2010 (UTC)

I would be very much against forcing the spelling parameter. I am hoping that one day {{convert}} will take its default from the user's preferences. That would mean that any conversion not explicitly forced to US or UK will follow my spelling. If we force editors to always provide the spelling parameter then that hope will never come true.  Stepho  (talk) 10:03, 11 November 2010 (UTC)
  1. That would break tons of existing articles;
  2. there are only a couple units with several spellings (metre, litre and compounds); forcing the spelling parameter only for those two could be confusing and forcing it everywhere would be silly;
  3. the current default of using Commonwealth spellings in the absence of the spelling parameter makes sense, as most US-related articles would use US customary units as inputs so that the metre and the litre would only appear in the conversions, and hence the symbol rather than the name would be used. A. di M. (talk) 13:51, 11 November 2010 (UTC)

Torque not working

How come I can't get this to work: {{convert|11.3|kg-m|Nm ft-lb|abbr=on}}: 11.3 kg-m[convert: unknown unit] I have tried all sorts of different combinations and spellings (kgm, kg.m, kg-m) but nothing helps.  ⊂| Mr.choppers |⊃  (talk) 17:42, 9 November 2010 (UTC)

Try kgf.m: 11.3 kilogram force-metres (111 N⋅m; 82 lbf⋅ft) JIMp talk·cont 18:28, 9 November 2010 (UTC)
Thanks, but sadly the automobile project doesn't like kgf.m (as it isn't ever used by car manufacturers), meaning that {{convert|11.3|kgm}}   11.3 kilogram metres (111 N⋅m; 82 lbf⋅ft) also doesn't work, since the output is in ft-lb.ftlfbt. Meanwhile, I did figure out that this combination works: {{convert|11.3|kgm|Nm lb.ft|abbr=on}}   11.3 kg⋅m (111 N⋅m; 82 lb⋅ft)
It's a bit like casting a spell, one has to be very precise. The newts' tails must be cut with a silver blade for the torque figures to appear.  ⊂| Mr.choppers |⊃  (talk) 04:14, 11 November 2010 (UTC)

M3 to FT3

Hi. Whats up with the conversion from m3 to ft3? Rehman 09:42, 11 November 2010 (UTC)

I fixed it for you by adding the rounding parameter. Not sure why it needed it though. Also, it probably requires less precision (the input is rounded to the 6th digit, so the output should be similar).  Stepho  (talk) 09:56, 11 November 2010 (UTC)
Thats weird; I've worked with a large number of similar articles and it never needed that before. Wonder if all those articles are displaying an error now; probably due to a recent edit at T:Convert? Anyways, thanks for fixing. Kind regards. Rehman 10:05, 11 November 2010 (UTC)

Update: Hey something is definitely wrong with this template. Nearly all articles I know which uses this template now shows this error, example. Rehman 10:08, 11 November 2010 (UTC)

Update: Could someone take a look at this issue please? This is pretty serious and is effecting many articles. Rehman 14:26, 11 November 2010 (UTC)

{{Rnd}} is broken ({{rnd|4123456|-5}} → 4,100,000). JIMp talk·cont 07:40, 12 November 2010 (UTC)
Actually it's {{#ifexpr: }} which is broken. These should both give "true".
{{#ifexpr:4.1E+6/10^5round0=4.1E+6*10^-5|true|false}}
{{#ifexpr:4.1E+6/10^5round0=4.1E+6/10^5|true|false}}
The first (used by {{rnd}}) is not working properly (giving "false"). Luckily the second is working. JIMp talk·cont 09:14, 12 November 2010 (UTC)

{{Infobox power station |name = Template talk:Convert | installed_capacity = {{convert|12344|m3}} }}

Actually, the first is true, the second is false. This is normal, intermediate results are rounded to representable floating-point numbers. 4.1*1000000*(1/100000) happens to be exactly 41, while 4.1*1000000/100000 happens to be 1 bit less:
  • "{{#expr:4.1*1000000*(1/100000)-41}}" gives "0"
  • "{{#expr:4.1*1000000/100000-41}}" gives "-7.105427357601E-15"
Patrick (talk) 23:26, 12 November 2010 (UTC)
See also my comment at Template talk:Rnd#Ifexpr error causing strife.--Patrick (talk) 00:59, 14 November 2010 (UTC)

According to Plastikspork, it is to do with the transclusion depth. Rehman 10:45, 12 November 2010 (UTC)

You are talking about the E notation, right? (You haven't actually stated what the problem is & I can't see anything else.) JIMp talk·cont 11:44, 12 November 2010 (UTC)
Ah well, I have no clue what E notation is my friend. ;) You have to ask Plastikspork that. Oh and I forgot to mention, he fixed the issue yesterday at Infobox Dam, but the issue is apparantely still existing at Infobox Power Station. You may also want to see here. Kind regards. Rehman 12:34, 12 November 2010 (UTC)
The infobox on Three Gorges Dam has "116,000 m3/s (4.1E+6 cu ft/s)" for the discharge capacity of the spillway. There're your E notation. "4.1E+6" means 4.1×106 i.e. 4.1 million. I looked at the power station infobox and didn't see anything. I've also looked at the pre-fix dam one too, nothing out of the ordinary. Are you seeing great big red error messages? I've seen them before but only when convert was used in a transclusion of the infobox onto itself through a doc page (never in an article). I haven't been able to figure out what was wrong. Transclusion depth is an interesting hypothesis but wouldn't we expect to see it elsewhere? But then you say you have. But I look and see nothing wrong but an instance of e notation ... odd. JIMp talk·cont 13:13, 12 November 2010 (UTC)

P.S. Take a look at {{convinfobox}} for a similar template which is geared for use as an autoconverter in infoboxes. JIMp talk·cont 13:22, 12 November 2010 (UTC)

All articles using the dam infobox are error-free now, since the subclassing is now removed (see my diff above). The power station box doesn't use any convert so far, but if it does, it'll show the same red errors I saw, according to Plastikspork. Rehman 13:47, 12 November 2010 (UTC)
You know, he's right, as we can see. This is pretty bad. How did he fix it? Still, I'm not sure it's a depth thing since the error occurs at the same place. JIMp talk·cont 14:00, 12 November 2010 (UTC)
He did it by simply removing the subclasses. I hope something will be done to fix this soon, its pretty annoying. Thanks for going through it. Kind regards. Rehman 15:53, 12 November 2010 (UTC)
I've had an idea. It might work. It involves an edit to {{rnd}}. JIMp talk·cont 17:15, 12 November 2010 (UTC)

Great, that's just what I was going to suggest. Basically, we need to reduce the total transclusion depth, and the "rnd" template has quite a few branches. I believe {{Infobox}} adds two, and you add two more if you embed an infobox inside an infobox (as is done at {{Infobox power station}}. If you put the template on a talk page, that adds three. Of course, if you force a particular rounding, then this circumvents the precision calculations, and the depth is dramatically reduced. If I recall, someone wrote a template that tests the transclusion depth of templates (found it see {{Edt}}). I plan to reduce the depth of {{documentation}}, but the better solution would be the reduce the depth of this template. Plastikspork ―Œ(talk) 07:47, 13 November 2010 (UTC)

nbsp

Is it worth replacing the space before the unit symbol with a non-breaking space (&nbsp;)? I'm surprised this hasn't been done already; it seems to be fairly normal in professionally formatted texts, and would presumably not be too hard for someone who actually understood the template syntax… —me_and 23:22, 11 November 2010 (UTC)

It should have the nbsps. It used to have them. I've noticed some missing recently though. JIMp talk·cont 07:43, 12 November 2010 (UTC)
The last couple of examples I've seen didn't; in Transport in the Bahamas for example. —me_and 11:16, 12 November 2010 (UTC)
There's been a few changes made to the template lately. This problem I think is due to this one. JIMp talk·cont 11:37, 12 November 2010 (UTC)
That does indeed look likely. I'm frankly terrified of the syntax here, though, so I'm not going to propose a fix… —me_and 12:28, 12 November 2010 (UTC)
I'd propose a revert unless there is some reason to believe that the subtemplate would really ever be passed an empty {{{u}}} parameter (i.e. if some other changes had been made further up the chain since it wouldn't happen with the original structure). JIMp talk·cont 13:16, 12 November 2010 (UTC)

Allowing wrap not nbsp

15-Nov-2010: Wrapping of units depends on both the size of the number and unit name. The specialization to handle an empty {{{u}}} comes from the "Na" (non-abbreviated) units, such as acre, when used in multi2 templates, mixing the abbreviated and non-abbreviated units. The underlying problem is a conflict of designs: the multi2 subtemplates want to allow any units to be shown as 2 outputs for 1 input, but when "acre" is one of the 2 outputs, then it requires smart-sense about {{{u}}} being empty for acre, so that multi2 could remain a general mix-and-match template able to also handle any Na units. If all templates checked for empty {{{u}}}, then we could eliminate all "Na" variations of templates, but empty {{{u}}} requires knowing the plural/singular size of the output amount as {n} or "{n}s", and hence that requires another level of nesting as {Convert/out} to both display and check the value of each output amount, allowing more than 1 output and checking for plurality of each output (not equal 1). The common solution seems to be to pass {{{u}}} as both the singular and plural "name" of the unit. The complexity comes from the attempted simplicity of segmenting Convert into another group of "Na" subtemplates, when perhaps all templates should use {Convert/out} to check an output value for being the singular {n} or plural {n}s, and allow acre or acres. I suspect we should change the design to detect empty {{{u}}}, and we then handle units whose abbreviation stubbornly refuses to ignore singular outputs, where acre is spotted as needing plural "acres" even when abbreviated, and then (wait for it...) the use of nowrap &nbsp depends on the size of the abbreviated name. So, "acre" would allow wrapping, but "m" would stick at the end of a number:

  • {Convert/out} - chooses if an amount is singular/plural {n} or {l}.
  • {Convert/out} - can decide "180 acres" wraps but "1 acre" won't wrap.

Both the plurality and "wrap-ability" of units depends on the size of the amount: "1 unit" never wraps, but "1,200 x" wraps if x is a large word. I would wrap "1,200 sqft" but not "400 cm" but wrap "2,134.009 cm" rather than leave a 9-letter gap where 2,134.009 would have fit. See the problems? These problems can be solved by Truth Tables, by looking at many cases before forcing a rule. Hence, we can no longer hard-code "&nbsp" to force no-wrap. Meanwhile, tell people to use "disp=output only" (or hard-code the numbers) to specially format the wrapping of output. -Wikid77 (talk) 12:06, 15 November 2010 (UTC)

Convert fails when used inside an Infobox inside a doc subpage

Take a look please at the documentation for Infobox building. If you look at {{Infobox building/doc#Example}} the conversions in the "Law Courts of Brussels" look fine, but when you go to {{Infobox building#Example}} they give expression errors. --Stepheng3 (talk) 22:40, 12 November 2010 (UTC)

Yes, this is a problem with the "documentation" template adding 3 to the transclusion depth, and that this template is basically at the transclusion depth limit. See Template talk:Documentation and the threads above. Plastikspork ―Œ(talk) 07:43, 13 November 2010 (UTC)
Any chance of getting the transclusion depth limit raised? That would probably be the easiest fix of all. --Stepheng3 (talk) 20:48, 13 November 2010 (UTC)
It's possible, that would be under control of the wikimedia devs. However, I still think we should asking if is absolutely necessary to have the transclusion tree over 20 deep 40 deep. I believe most of the problem is in the precision/rounding part of the template, which contains lots of small templates that call each other. By the way, you can test the depth with {{Edt}}. Plastikspork ―Œ(talk) 21:53, 13 November 2010 (UTC)
By the way, here is another example, the following works: test, but the following fails:
{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|{{1x|test }}}}}}}}}}}}}}}}}}}} }}}}}}}}}}}}}}}}}}}} }}}}}}}}}}}}}}}}}}}} }}}}}}}}}}}}}}}}}}}} = {{Expansion depth limit exceeded|test}}. Now to get the depth, just check the number of 1x in the code. It looks like 40 works, but 41 fails, so the depth limit is 40. Do we really need this template to have a depth of over 20? If you go into edit mode, it lists all the subtemplates being called, including things like precision, rnd, ordomagnitude, ... Plastikspork ―Œ(talk) 22:01, 13 November 2010 (UTC)
Okay, I have effectively reduced the depth of {{documentation}}, or at least how much it adds to the depth of the doc page, so this problem should be mostly fixed. Now, that doesn't mean the problems are completely fixed, since there are still problems when this template is used at "depths" more than around three. However, at least "documentation" will only add a minimal number to the depth. Plastikspork ―Œ(talk) 00:27, 14 November 2010 (UTC)

Use rounding to avoid nest-limit

Reminder: When any rounding precision number is specified (such as ending "|0}"), then many of those multi-nested {precision} templates are skipped, and the nesting will no longer be fatal. The good news: in practice, the precision can be specified in most cases, so that is typically the best answer ("Hey I'm getting nesting problems... Well, round by "0" to avoid"). Convert requires deep nesting to handle any astronomically huge numbers (this is the "astro-Convert" aspect: huge numbers are almost never needed, but Convert always expects them, and hence nests the subtemplates to count precision as "60" digits).
Plus, in terms of computing, I would have imagined the template-nesting limit should be 100 (or more, but 40 has been the limit in 2009-2010), hence, I don't think "efficiency" is the reason the nesting-limit has been 40. It is time to ask the developers to allow nesting as 100 (or 60 or such). Nota Bene: The main reason Convert cannot be super-clever is this friggin' nesting-limit of if-else logic. We know many algorithms to detect and warn users about likely problems, or to warn users when using wrong parameters, but any if-else logic nested beyond 40 is fatal. Common tactic: when errors occur, invoke a clever error-message template which invokes subtemplates for each situation. Reality: when an error occurs, the nesting-limit freaks, Wikipedia craters, and we get wiki-puke messages, not clever messages. We have people writing other super-clever templates, such as dynamic equations with sine/cosine transforms to place markers on curved maps (bending the latitude & longitude lines), so our math/IT experts are hindered by the neophyte level of template nesting (plus no user-defined variables!). Bottom line: MediaWiki's limited template technology acts like it was developed by beginner high-school students, rather than degreed professionals, and the glamour of college-dropout wizkids has tarnished (like ya, rusted away). We don't need more Bill Gates, no, we need to empower intelligent people to fix this crap. Everyone, please expect or request better MediaWiki software settings. Anyway, to avoid nesting problems: tell people to round by "0" (or such) as the quick fix now. -Wikid77 (talk) 10:21, 15 November 2010 (UTC)

Focus on nesting of if-else and templates

15-Nov-2010: Currently, the improvements to Convert are being hampered by the severely tiny limit of 40 nested expressions, of if-else logic and templates being limited to no more than 40 deep. As months go by, people tend to forget the details and oversimplify problems. The true problem is the combined nesting of templates plus if-else logic. Although Convert only nests the templates to perhaps 20-deep nesting, the combined nesting of if-else logic, plus templates, plus default parameters causes some uses of Convert to generate the reddish message "Expression error: Unexpected < operator|Expression error: Unexpected < operator" (in conversions which omit the round "0" or "sigfig=4" options). The quick fix is to determine what number to put as a valid round "0" or "sigfig=5" (or such) and bypass the logic which counts digits to set the default precision.

Within a week, we could probably modify the {Precision} templates to just give simple results for moderate-sized amounts, but invoke the full, nested {Precision} logic for extreme numbers, when extremely large or extremely small. In many cases, there is usually a simple "safety-net" solution to bypass a problem, and that is an option in this case.

Long term, we need to cut the nesting or increase MediaWiki's current tiny expression-nest limit, so that additional if-else logic can be added to some templates to check for errors and display readable error messages (not the cryptic internal parser errors, "Expression error: Unexpected < operator"). The reason the nesting-limit has remained a problem, even though the template-nesting has been decreased over the past several months, is that new features in Convert have offset recent reductions with equivalent increases. There is evidence to suggest that even setting a default on a parameter, such as {x|2.5}, can subtract 1 from the 40-deep limit. In an emergency, consider removing such defaults (as {x|2.5} would be changed to just "{x}") as a desperate attempt to offset the psycho-stingey limit of 40, which we have no idea where such a miniscule number was chosen for that crucial limit in template operation. I guess the WP:Village_pump would be a good place to check the status of increasing the 40 limit, to become 100 deep or a similar number which normal people would expect. -Wikid77 (talk) 15:45, 15 November 2010 (UTC)

Revising mosnum. Your comments needed at wp:mosnum/symbols for metric units

There's a discussion going on at wp:mosnum about a revision. We've had a few notable cases where editors get angry and claim (correctly) that there's no documented proof of consensus that SI guidance applies. For example somebody suggested that 'km/h' wasn't an acceptable format and 'kph' had to be used.

I wrote the following:

Mosnum has grown like coral and has a lot of fuzziness and too much trivia. It's time for a rewrite. There are three principles that seem to have agreement:
1. Wikipedia uses official SI guidance.
2. Wikipedia has a list of acceptable deviations from SI guidance.
3. Wikipedia has a method of changing the list of acceptable deviations.
Unfortunately the current mosnum text suggests that SI guidance is merely an option. I think this opt-in system is why we have such long rambling mosnum text and lengthy discussion outside mosnum. Anyone can demand proof of consensus that normal metric formats apply for any edit. We need to state that SI guidance applies by default, and the list of acceptable deviations are available as opt-outs. We can then purge a lot of the metric trivia. It'll be shorter, clearer, and more usable in article talk pages.

Please don't start a discussion here. Please comment on the revision at: wp:mosnum/symbols for metric units.
Regards Lightmouse (talk) 17:32, 16 November 2010 (UTC)

Convert uses 17-to-30 of 40 nest limit

Subpage: Template_talk:Convert/nesting#Convert uses 17-30 of 40 limit.

17-Nov-2010: While it is true that the complexity of Convert's if-logic and nested subtemplates uses about half of the MediaWiki (1.6) expression-nest limit of 40 levels, Convert is NEVER "near" the transclusion depth limit, by itself. When precision is specified as "sigfig=3" or round "0" then Convert uses only 17 nest-levels, leaving 23 available (see examples on subpage). Instead, some of the {Infobox} plus {Documentation} templates have been using more than 11(!) nest levels, of nested subtemplates or if-else logic, before invoking Convert. Although Convert of 77 inches to "ft m" (feet-and-metres), by using 29 levels of nested logic, might seem excessive, the concept of any {Infobox} template using 8 or 11 levels, of nested logic, totally baffles me. I have run tests which prove that an infobox-table (class=infobox), of couse, causes no nesting, at all. The 8-to-11 levels are caused by complex {Infobox} templates. This is another reason why the current transclusion depth limit of 40 is just too small for the real world: people are creating generalized infoboxes which nest 8-to-11 levels deep, before invoking Convert inside them. Again, the good news is that people can typically specify sigfig=3 or round "0" in many cases, and reduce Convert by the 11 nest-levels used to determine the precision of the input number. See subpage "/nesting" for detailed examples.

In general, to revisit the details about template-nesting, always go to that talk-subpage, "Template_talk:Convert/nesting" (as a reminder about the levels of Convert nesting). -Wikid77 (talk) 05:40, 17 November 2010 (UTC)

Rounding mode

Just noticed that the template is using Rounding#Round half to even rather than the more typical Rounding#Round half up

  • 9.525 to 3dp 3⁄8 inch (9.525 mm)
  • 9.525 to 2dp 3⁄8 inch (9.53 mm) rounded down [now rounded up--Patrick (talk) 07:48, 18 November 2010 (UTC)]
  • 15.875 to 3dp 5⁄8 inch (15.875 mm)
  • 15.875 to 2dp 5⁄8 inch (15.88 mm) rounded up

Don't know if this counts as a bug or not. --Salix (talk): 22:46, 15 November 2010 (UTC)

Interesting. Round to even introduces less systematic bias. The actual choice of rounding method is controlled by the mediawiki software, which is probably being selected by the OS. I believe the IEEE standard is round to even. Thanks! Plastikspork ―Œ(talk) 01:52, 16 November 2010 (UTC)
For the implicit rounding to a number of type float tie-to-even is applied, while the round function rounds 5 away from zero. However, in this case we have (3/8)*0.0254/0.001, which happens to be 9.524999999999999, which the round function rounds to the nearest value, 9.52.--Patrick (talk) 00:18, 17 November 2010 (UTC)
This could be fixed with an extra rounding, for example by applying {{#expr:(3/8)*0.0254/0.001}} → 9.525 before applying the rounding to 2 decimals. This could be done in Template:Convert/LoffAonSoff, by replacing {{{2}}}/{{{b}}} by {{#expr:{{{2}}}/{{{b}}}}}. The drawback is that for an accurate result like 1234567.84499996 we would get {{#expr:1234567.84499996}} → 1234567.845, so rounding to 2 decimals would give 1234567.85, but this may be less important than fixing the rounding direction in common borderline cases.--Patrick (talk) 08:03, 17 November 2010 (UTC)
I made the change.--Patrick (talk) 07:48, 18 November 2010 (UTC)

Arpent

I just had a need for convert to support arpent, a French units of measurement which depending upon context is either a unit of length or of area. I worked around its absence by using an arpent-to-acre conversion that another editor had done, and having convert do the math for the metric equivalent. If obscure units such as the arpent are within convert's charter, consider this a request that support for it be added. Thanks. 67.100.127.81 (talk) 20:50, 18 November 2010 (UTC)

  • The "arpent" was already requested & added (but not in the documentation), months ago, as the Canadian arpent (of area), used from the French Lousiana colony, which I think might be the same unit:
  • {convert|45|arpent} → 45 arpents (15 ha)
  • {convert|1|arpent} → 1 arpent (0.34 ha)
As for obscure units, we are also considering the "Egyptian cubit" as {convert|30|Egyptian cubit} → 30 Egyptian cubit[convert: unknown unit]. That's what I remember so far. -Wikid77 (talk) 14:59, 19 November 2010 (UTC)

Overcoming the Wikipedia 40-nest limit

19-Nov-2010: Now that we are getting more details about Wikipedia's severely poor support for conditional logic inside Convert, we are ready to formalize plans to circumvent the limitations. For example:

  • We are counting the nest-levels of common utility templates, such as {{Precision}} currently using 8 levels of nesting, and even simple {{Str_len}} using 9-levels deep(!), because people, who wrote those templates, did not realize which performance resources to optimize. They can be modified to be more efficient.
  • There is a plan to streamline {{Rnd}} for reduced nesting.
  • New Template:Convert/numdisp/sandbox will use 1 less level.
  • Template:Getprecision might be able to use fewer nest levels than the 8 levels which {Precision} has used in 2009-2010.
  • Error checking can be added as parallel if-statements (not nested):
{if#error: 1/{{{1}}} | ERROR: Invalid amount {{{1}}} causes division by 0 or numeric overflow.|<!--else continue-->}

We can create an essay describing techniques to keep the template-level, or if-else nesting, to a minimum for common utility templates.

Meanwhile, everyone needs to realize "we shall overcome" Wikipedia's current limited technology, just as in every-day matters. Some cars can get 50 mpg[convert: ambiguous unit], but not travel more than 20 miles (32 km) on an emergency spare. However, if people plan to bypass limited automobiles, they can keep real, full spare tires or pre-plan to call for a ride, so they won't be stranded on a motorway with a spare-tube that burned out in 15 miles (24 km). Wikipedia is not alone in having severely bad problems, but if we face these worries, directly, we can plan to overcome the limits, such as a pitiful 40-levels of conditional logic. Certainly, some police groups want tires to go flat, because ruining tires is a common tactic in chasing suspects down crowded, busy streets with children. Hence, Wikipedia's performance problems are just typical of other world affairs, instead of being issues to bemoan, but instead, as problems to circumvent by plans to be better prepared. -Wikid77 (talk) 15:38, 19 November 2010 (UTC)

Unexpected behaviour from template

Please look at Agriculture in the United Kingdom#Overview. The {{convert}} template is working as expected for the first conversion, where it gives traditional numbers, but on my screen the second conversion (for a smaller unit) is yielding a number in exponential notation. Have I misused the template?—S Marshall T/C 20:13, 19 November 2010 (UTC)

  • Those annoying scientific-notation numbers are coming from the internal MediaWiki rounding function "round" in {convert|6,200,000|ha} → 6,200,000 hectares (15,000,000 acres) for the number 15,300,000. I am working on a new rounding routine {Rndpad} which, perhaps, I can change to overcome that limit of 8-digit numbers, as with {Rndpad|15300001|-5} → {{Rndpad|15300001|-5}}. Thanks for letting us know of a current example which shows that rounding problem. -Wikid77 (talk) 23:03, 19 November 2010 (UTC)
  • The result is caused by 15300000round(-5) giving an internal result that is 1 bit less than 15300000: {{#expr:15300000-(15300000round(-5))}} → 0. Strange.--Patrick (talk) 23:39, 19 November 2010 (UTC)
Okay, {#expr: 15300000-(15300000 round-5)} = 0, as slightly off, so that is why rounding cannot be used, alone, to determine precision. I have changed {{Getprecision}} to use a new algorithm to handle multi-millions with zeroes. -Wikid77 (talk) 17:44, 20 November 2010 (UTC)
There are good reason for going to exponential notation when the number of digits get too high in this example the unexpanded result would be "15,300,000 acres" with many zeros. An arguable better result would be "15.3 million acres". I had though of using {{convert|6.2|ha|disp=output number only}} million acres , so the template was just used to convert the number/1,000,000 with the units written by hand, but that gave a redlink for a sub-template: 15. --Salix (talk): 00:07, 20 November 2010 (UTC)
  • I have added Template:Convert/NumoutNa, so your idea will work now. That's a good idea, which we can add to the doc-page, as an example to avoid too many zeroes. Example:
    Use: "6.2 million hectares, or" {convert|6.2|ha|acre|1|disp=output number only}... → to get "...or 15.3 million acres".
    Meanwhile, I have changed {{Rndpad}} to allow showing 15,300,000:
               {Rndpad|15300001|-5} → {{Rndpad|15300001|-5}}
    So, I will check the {Rndpad} resource usage and, perhaps, plan for release of {Rndpad} inside Convert next week. -Wikid77 (talk) 01:47, 20 November 2010 (UTC)
Anyway, now {{convert|6200000|ha|acre}} → 6,200,000 hectares (15,000,000 acres).--Patrick (talk) 09:52, 20 November 2010 (UTC)
Good, I see you have fixed protected Template:Rnd to allow some larger amounts:
  • {Rnd|82111000|-5} → 82,100,000.
  • {Rnd|82111000|-6} → 82,000,000.
  • {Rnd|2000111000|-9} → 2×109.
With {Rnd} fixed, then:
  • {convert|6200000|ha|acre} → 6,200,000 hectares (15,000,000 acres)
  • Some large scientific notation can be expanded by appending "round 0", {#expr: 15300000 round-5} → 15300000, while {#expr: 15300000 round-5 round0} → 15300000 but {#expr: 23400000 round-5 round0} → 23400000. Only some values go to E+7 form, so "round 0" corrects some. Hopefully, template {Rnd} will be more reliable (up to -6):
  • {Rnd|23400000|-5}      → 23,400,000
  • {Rnd|23400000|-6}      → 23,000,000
That might work as a better solution. -Wikid77 (talk) 18:04, 20 November 2010 (UTC)

New concept for common millions of units

20-Nov-10: After recent discussions for showing "x.x million" rather than x,x00,000, I have created 2 new units: "million hectares" and "million acres" to directly show "million" in amounts:

  • {convert|6.2|million hectares} → 6.2 million hectares (15×10^6 acres)
  • {convert|15.3|million acres}                 → 15.3 million acres (62,000 km2)
  • {convert|15.3|million acres|abbr=none} → 15.3 million acres (62,000 square kilometres)

This concept would only be used, for common amounts, which are often used in millions (not for "million cm" or "million feet" etc.). Hopefully, this high-level option to show "million" will make it simpler for those who wish to avoid the zeroes x,x00,000 and such. In general, to create a template for "million x" copy Template:Convert/x, then shift the value of b=x.1234567 plus 6 places larger, "b=x123456.7" (as times a million), and set precision j=x as 6? higher (not lower). We should only add such "million x" units for the most common cases. Use of "million x" does not affect Convert's if-else/template nesting (40-nest limit), so this is a new feature where we didn't have to penny-pinch resources to allow it. -Wikid77 (talk) 02:55, 20 November 2010 (UTC)

Some already exist using the e6 form (thousands (e3), thousand millions (e9), etc. also) e.g.
  • {{convert|123|e6acre}} → 123 million acres (500,000 km2)
  • {{convert|123|e9USgal|lk=on}} → 123 billion US gallons (470 Gl)
  • {{convert|15.3|e6acre|lk=on}} → 15.3 million acres (62,000 km2)
  • {{convert|100|e15m3|cuft|lk=on}} → 100 quadrillion cubic metres (3.5×1018 cu ft)
Be careful of "million ha" etc. I wouldn't use "million", "billion", etc. before a symbol/abbreviation. MOSNUM says "Units symbols are preceded by figures, not by spelled-out numbers: for example, 5 min, not five min." Yeah the number isn't fully spelt out but still. I noticed something else: e6acre defaults to square kilometres whereas million acres defaults to million hectares ... actually I'd avoid millions ... pretty much thousands ... even hundreds of hectares (except for when there are other hectare values for comparison). JIMp talk·cont 04:46, 20 November 2010 (UTC)
  • I had forgotten those e3/e6/e9 units. Google matches 2,134 pages with "million acres" on searching: site:wiki.riteme.site "million acres", but what-links-here lists only 10 articles using Convert/e6acre, so far. Generally, I think people were trying to avoid all the zeroes in million amounts, but "thousands" might be common in other documents, as a similar issue. -Wikid77 (talk) 11:57, 20 November 2010 (UTC)

I agree with Jimp (as I've said before), there's a case for being sensitive to size of output i.e. large output units with large values. Even if you replace six zeros with the word 'million', it's much easier to understand a value when expressed as few large units than expressed as many small units. I'm not sure how the template can solve it, but the issue exists. On the subject of the convert code formats, we also have the 'prefix' format versus 'e' format. See:

  • {convert|10|Mcuft} -> 10 million cubic feet (280×10^3 m3)
  • {convert|10|e6cuft} -> 10 million cubic feet (280×10^3 m3)

It would be good to review how those work across all units and sizes to ensure that we're doing the right thing. Lightmouse (talk) 13:32, 20 November 2010 (UTC)

Yes, if there is a "test-cases" page for e3/e6/e9, then having large tables on that page, with ample variety, would be a good review of the various options. Meanwhile, we just wait for people to spot problems, in live articles, to focus updates in those areas. Many options are not used, at all, in actual articles, only in test-cases. So, we rely on the patience of users to pinpoint problems in the options that are needed for actual use. Most problems are one-time cases, but when Convert is nested inside infoboxes, then those cases have affected a larger number of articles. -Wikid77 (talk) 18:20, 20 November 2010 (UTC)

Changing Convert to use more Getprecision

20-Nov-2010: I am still modifying Template:Getprecision to use as few nest levels as possible, compared to the 8 levels of nesting used by {{Precision}}. Because {Precision} could not handle negative numbers and fails on some large numbers, then {Getprecision} has been used for those cases, but had lacked support for negative rounding (-1=2430, -2=2400, -3=2000, etc.). The use will depend on the total levels of nesting, now that we see so many complaints about Convert, mixed with complex nested infoboxes. Note that people are saying how some infoboxes exceed the 40 nesting levels all by themselves in doc subpages, so in some cases, using Convert could require modifying a particular infobox to be more streamlined, rather than squeeze Convert any further. Meanwhile, when setting precision sigfig=3 or round "0" (or such), users can still bypass 11 levels of Convert nesting. -Wikid77 (talk) 11:57, 20 November 2010 (UTC)

  • Status 21-Nov-2010: The new Template:Getprecision/sandbox seems to use only 5 levels of expression nesting, which would free another 3 levels, of the 40-nest limit. That would reduce the default Convert resource usage to 23 of 40 levels, making any other combined template, which exceeds the limit, to be "half-guilty" of the problem. Unfortunately, the nest-limit danger is insideous: during testing of {Getprecision}, I discovered that some overruns of the 40-nest limit do NOT issue an error message: instead, they just return the wrong calculated results(!) when the 40-nest limit has been exceeded. Hence, not only is the 40-limit severely small for computer usage, but also, the limit is not checked internally to ensure templates can continue running correctly, else warn the user. Instead, templates just "go over the cliff" like a trailer that dumps half it's cargo down the hillside because there was no guardrail as protection. The "truck" still arrives, but the cargo isn't quite the expected lot.
I was able to reduce {Getprecision}, to only 5 levels of nested if-logic, by totally omitting all other templates, and coding the logic on "the bare metal" of the wiki-servers: that is, using only the Help:Parser_functions in hyper-efficient ways to squeeze every gram of performance from the MediaWiki software. I cannot stress enough: in terms of computer systems, 40 levels of if-logic is severely cramped, and the Convert template is a total miracle of performance (despite whatever bugs): Convert has handled all those various format options, in a shallow puddle of computing resources.
The MediaWiki software group seems to be utterly distracted by a horde of tangent issues, keenly focused on formatting 150 rare languages, while unable to see the "elephant in the room" of providing ample text-formatting templates and clever tools for the major languages of the world. Convert is one of the top 100 templates, among many thousands. Yet, this resource limit has continued for such a long time, for so many years, that we should prepare to live with limited resources for Convert, and always view new features as staying within the confines of this wiki-cage of limitations. A good, healthy fear of these performance issues will save us a lot of headaches, in the future, as other templates grow to compete for the cramped resources. Those issues can be described in Convert talk-pages. At some point, the flood gates of capability will open, because a 40-nest limit is a totally bizarre, microscopic, artificial barrier, while it gives a hint that other restrictions are also easy to lift. -Wikid77 (talk) 06:46, 21 November 2010 (UTC)

New FAQ page: Template:Convert/FAQ

We didn't have a real, full FAQ page yet. I have created the most-likely FAQ name as "Template:Convert/FAQ" for frequently asked questions (FAQ). However, the 2 FAQ questions at the top of this talk-page are still inside the FAQ's talk-page Template_talk:Convert/FAQ, using "<noinclude>" to hide real discussions inside that page. Anyway, there are 4 new questions listed (and answered):

Q: Can a conversion say "million" rather than use zeroes "000,000"?
Q: How are extra words shown within a conversion?
Q: Convert seems big, but can Convert run faster as used?
Q: Convert seems to cause some red error messages, why?

I put some of those phrases in bold-italics because they emphasize the heart of each question, in the sea of text on the full FAQ page (where the numerous examples add to the clutter). The new FAQ page is just an initial, polished draft version, of how questions/answers could be listed. Feel free to discuss format changes, or just add more Q/A entries inside that page: Template:Convert/FAQ. I didn't take the time to think what are actually the most-common ("frequent") questions, but I also included some simple examples of rounding. To me, most user questions have seemed like, "How do I change ancient kittens into house cats?" So, long-term, we need to tally, somehow, a rough count of the actual repeated, most-common questions. Any thoughts? -Wikid77 (talk) 13:23, 22 November 2010 (UTC)

New use for "disp=/"

Can someone make the following work 0.318 (8.077)*? Needed for Nominal Pipe Size#NPS tables for selected sizes and could be useful elsewhere. Peter Horn User talk 18:29, 23 November 2010 (UTC)

  • I have activated "disp=x" to allow putting a slash "/" or whatever separator text, between the amounts, when using option "disp=x|/" as follows:
                - {convert|0.318|in|mm|abbr=values|disp=x| / ||3} → 0.318 / 8.077

    Long term, I would like to deprecate use of old "disp=/" (in favor of using option "disp=x| / ") to start reducing Convert's 3,100 subtemplates. Please use the new option "disp=x|/" in such cases, unless there are other concerns. Thanks for identifying that case of using abbr=values. -Wikid77 (talk) 19:57, 23 November 2010 (UTC)
  • I'll give it a try in my Sandbox.

Meters per day and feet per day

For Reinforced thermoplastic pipe 1,000 m/d (3,281 ft/d) or 1,000 m/d (3,281 ft/d) instead of 1,000 m (3,281 ft)/day . Peter Horn User talk 01:24, 23 November 2010 (UTC)

  • Perhaps use option "disp=x" with 2 inserted text phrases as "/day (" and then "/day)":
         - {convert|1000|m|ft|disp=x|/day (|/day)|0}}     → 1,000 metres/day (3,281 ft/day)
         - {convert|1000|m|ft|disp=x|/week (|/week)|0}} → 1,000 metres/week (3,281 ft/week)
         - {convert|4321|m|ft|disp=x|/weekday (|/weekday)|1}} → 4,321 metres/weekday (14,176.5 ft/weekday)
    I realize it might take some time for people to realize the new "power of customized output" when using disp=x. However, we are trying to avoid creating too many subtemplates, if we can use a generalized option to handle a "thousand-and-one" various cases. Note: the rounding parameter becomes the 6th parameter when using disp=x. -Wikid77 (talk) 20:20, revised 20:25, 23 November 2010 (UTC)
  • I'll give it a try in my Sandbox. Peter Horn User talk 01:03, 26 November 2010 (UTC)

MT/LT mos

Following on from this which was resolved with |abbr=mos, wpuld it be possible to have the MOS option for the conversion from MT to LT (which I beleive would be at Template:Convert/LoffAmonSoffNa). I'd do it myself if I understood what the hell goes on in these templates (I thought I was reasonable with syntax). Thanks, Rambo's Revenge (talk) 23:57, 23 November 2010 (UTC)

  • {convert|23|MT|ST|abbr=mos} → 23 metric tons (25 short tons)*
Cases for wrapping units, with abbr=mos
mode  width
25px		 width
50px		 width
90px		 width
125px
abbr=off 23 metric tons (25 short tons) 23 metric tons (25 short tons) 23 metric tons (25 short tons) 23 metric tons (25 short tons)
abbr=mos 23 metric tons (25 short tons)* 23 metric tons (25 short tons)* 23 metric tons (25 short tons)* 23 metric tons (25 short tons)*
mode  width
25px		 width
50px		 width
90px		 width
125px
abbr=mos 2,300 metric tons (2,500 short tons)* 2,300 metric tons (2,500 short tons)* 2,300 metric tons (2,500 short tons)* 2,300 metric tons (2,500 short tons)*
The option "abbr=mos" will NOT wrap after small numbers (<1000), so that "123 cm" will not wrap, but "1,250 cm" could wrap. Due to efficiency concerns (nest limit 40), the decimal places are not counted, so "66.12345 acres" will not wrap (yet). The reason wrapping above 999 seems to work is: a number with comma "1,000" tends to wrap when space is limited, so the unit name does not need to be connected to a large number. These concepts are just the initial strategy, so let me know if different wrapping of text would be better.
NOTE: This smart-wrapping of units is still efficient. We want Convert to be super-smart about typesetting, or spot unit-mismatch, plus detect input errors, without consuming the limited template resources. -Wikid77 (talk) 15:00, 25 November 2010 (UTC)

abbr=none does not always work

Example: 40 acres (16 ha) vs 40 acres (16 hectares). It would be nice and useful to be able to spell hectare out in full in the second instance as is possible with 4 square miles (10 square kilometres) or 10 square kilometres (4 square miles) Peter Horn User talk 18:02, 30 October 2010 (UTC)

I attemted it at Prince of Wales Island (Alaska)#Logging with 400,000 acres (160,000 ha) vs 400,000 acres (160,000 hectares). Peter Horn User talk 18:14, 30 October 2010 (UTC)
I'd prefer to see such conversions made to m² or km² (depending on the area), not hectare. hectare is not SI, and it is one of those "metric traditional units", like the bar is another. It's "an extra unit specialized to a field". like horsepower is for vehicles/motors, hectare is for land. Bewareircd (talk) 23:54, 2 November 2010 (UTC)
Well, so is the acre. Also, all the zeroes in 4 acres (16,000 m2) or 4 acres (0.016 km2) are distracting. A. di M. (talk) 00:34, 3 November 2010 (UTC)
the zeroes argument does not work: i can equally well say the zeroes in 160,000 ha are distracting. and that's still more zeroes than in your example of 16,000 m². as for the acre: convert was introduced to satisfy both the native english speakers, and the rest of the world, at once. if it were up to me, i'd abolish english units, including the acre. with convert, we can show both an english unit and an SI unit in a consistent way. Bewareircd (talk) 01:39, 3 November 2010 (UTC)
The acre, for which there is no abbreviation, is still in common use in both Canada and the USA. In Canada, the hectare is making inroads in usage (never mind SI). The USA will probably stick with acres as a land measure for eons to come. Most Americans are probably taught little, if anything, about any aspect of the metric system and thus know "balls" (nothing) about it. A goodly number of Americans probably suffer from a bad case of metrophobia. Peter Horn User talk 23:52, 3 November 2010 (UTC)
Make that metric phoebia. Peter Horn User talk 21:59, 4 November 2010 (UTC)
"160,000 ha", "16,000 m2" and "0.016 km2" are all distracting "1,600 km2" and "16 ha" are better. What is a "metric traditional unit"? JIMp talk·cont 00:53, 5 November 2010 (UTC)
I do believe there should be a guideline that takes into account the value, when deciding whether to convert acres into hectares or square metres or square kilometers. Tony (talk) 12:40, 5 November 2010 (UTC)
The conversion factor from acres to hectares is of order unity (and so are the one from square yards to square metres and the one from square miles to square kilometres), so if a measure is too large or too small for hectares it's very likely to be too large or too small for acres, too (ditto for square yards and square metres, and for square miles and square kilometres). A. di M. (talk) 14:22, 5 November 2010 (UTC)
Starting with 400,000 acres (161,874 hectares) (I added |0| here) in the article we then do 400,000 acres (625 square miles). After that we do 625 square miles (1,619 km2) and substitute that in the afore mentioned article. A minor problem here is that the original source really gives 400,000 acres. Peter Horn User talk 16:19, 5 November 2010 (UTC)
Would we need square miles? If so, then how about "400,000 acres (620 sq mi; 1,600 km2)"? JIMp talk·cont 19:49, 5 November 2010 (UTC)

It certainly would be better to have 1600 km2 rather than 160000 ha. It doesn't seem dependent on having sqmi but if that's what it takes, then so be it. Would Peter or anyone else be able to try it in Prince of Wales Island (Alaska)#Logging? Lightmouse (talk) 10:43, 28 November 2010 (UTC)

Flipping

Can we get the convert template to allow flipping when rounding to the nearest 5 please.Jason Rees (talk) 05:12, 25 November 2010 (UTC)

  • DONE: Since the options conflict as disp=5 v. disp=flip, we can use disp=flip5 as the combination:
  • {convert|42|ft|m|disp=b} → 42 feet (13 m)
  • {convert|42|ft|m|disp=5} → 42 feet (15 m)*
  • {convert|42|ft|m|disp=flip} → 13 metres (42 ft)
  • {convert|42|ft|m|disp=flip5} → 42 feet (13 m)*
  • {convert|42|ft|m|disp=flip5|abbr=in} → 42 ft (13 metres)*
  • {convert|38|km|mi|disp=flip5} → 38 kilometres (24 mi)*              usual: 38 kilometres (24 mi)
The combination (as disp=flip5) will be workable, with limited use of other options, so the "m" cannot display as "metres" yet. -Wikid77 (talk) 15:41, 25 November 2010 (UTC)
    • Umm, Thanks but it aint working when im trying to flip windspeeds around, which is what i need it for as otherwise the template is showing up with an amount that is wrong. Sorry if i wasnt clear earlier.Jason Rees (talk) 15:49, 25 November 2010 (UTC)

So far, only 1-unit speeds work, but unit names will appear now:

  • {convert|65|mph|disp=flip5} → 65 miles per hour (105 km/h)*
  • {convert|95|km/h|disp=flip5} → 95 kilometres per hour (59 mph)*
  • {convert|95|km/h|disp=flip5|abbr=none} → 95 kilometres per hour (59 miles per hour)*
  • {convert|115|kn|km/h|disp=flip5} → 115 knots (213 km/h)*

Converting to 2 output units is more complex, so there have been problems in the results:

  • {convert|115|kn|disp=flip} → 213 kilometres per hour; 132 miles per hour (115 kn)
  • {convert|115|kn|disp=flip5} → 115 knots (213 km/h; 132 mph)*

I am still checking to improve the results for 2-unit output. -Wikid77 (talk) 13:18, 26 November 2010 (UTC)

"abbr=values" does not always work

Can someone make 3 to 6.5 (0.118 to 0.256) instead of 3 (0.118) to 6.5 (0.256) for User:Peter Horn/Sandbox#Panzergewinde? Peter Horn User talk 19:50, 26 November 2010 (UTC) Peter Horn User talk 19:54, 26 November 2010 (UTC)

DONE. I have created subtemplates for "abbr=values" with ranges, to put spaces for the unit names:
  • {convert|3|to|6.5|mm|in|3|abbr=values} → 3 to 6.5 (0.118 to 0.256)
  • {convert|4|-|18|mm|in|3|abbr=values} → 4–18 (0.157–0.709)
The typical range words (including: to, and, or, -, x, xx) are supported. -Wikid77 (talk) 02:44, 27 November 2010 (UTC)
Thanks. Peter Horn User talk 17:42, 30 November 2010 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_November_2010&oldid=1125416432"