Template talk:Convert/Archive February 2013

Proposal for incompatible units

Consider the following perfectly valid conversion,

{{convert|3|mi|ft}}

following the expansion sequence we see that {{convert}} calls {{convert/mi}} which calls {{convert/LoffAoffDbSoff}} which calls {{convert/ft}}. if were to have {{convert/mi}} pass its output unit to {{convert/ft}} through {{convert/LoffAoffDbSoff}}, then {{convert/ft}} could check to see if the units make sense. I believe this is similar to what was proposed above by Wikid77, but using an auxiliary template.

Correct me if I am wrong, but I thought that all the length unit subtemplates use the same units for the "base unit", in this case meters. so, we could have {{convert/mi}} pass "m" as the output units to {{convert/ft}}. then, {{convert/ft}} could check to make sure the input units match the output units.

for example,

{{User:Frietjes/convert|3|mi|ft}}

{{User:Frietjes/convert|3|lbf|N}}

{{User:Frietjes/convert|3|kg|N}}

{{User:Frietjes/convert|3|kg|ft}}

is there anything I am missing here? Frietjes (talk) 00:36, 15 January 2013 (UTC)

• Passing an internal unit code "m" does sound like a simple way to check for mismatched units. However, currently, only a few combinations cause most trouble, so I recommend changing just those few for now, with a unit-lookup template. Long term, we could change all length-type subtemplates to check for "m" as the internal unit code. -Wikid77 (talk) 00:28, 5 February 2013 (UTC)

Using plurals with dimensions (convert/3)

Shouldn't {{convert/3|2.7|x|0.6|x|0.5|cm|in|sp=us}} be rendered with plurals, as in

2.7×0.6×0.5 centimeters (1.1×0.24×0.20 inches)

instead of

{{convert/3|2.7|x|0.6|x|0.5|cm|in|sp=us}} [sic]

Thanks in advance. 67.101.5.69 (talk) 04:35, 17 January 2013 (UTC) (P.S. I already searched the archives for an answer)

• See MOS:UNITS#Unit names and symbols. As I interpret this, fully spelt out unit names should be pluralized; abbreviated unit names should not. So it should render as "2.7×0.6×0.5 centimeters (1.1×0.24×0.20 in)", since the parenthesised part normally uses abbreviated unit names. Peter coxhead (talk) 06:06, 17 January 2013 (UTC)
• Convert/3 checks for amounts < 1 to use singular: It just seemed reasonable if an amount is one or less, then the unit name is singular, as with "one-half centimeter". So for amounts >1 then it uses plural. Compare amounts:

• {{convert/3|2|x|0.6|x|0.5|cm|in|sp=us}} → {{convert/3|2|x|0.6|x|0.5|cm|in|sp=us}}
• {{convert/3|2|x|0.6|x|5.5|cm|in|sp=us}} → {{convert/3|2|x|0.6|x|5.5|cm|in|sp=us}}
• {{convert/3|2|x|0.6|x|1.0|cm|in|sp=us}} → {{convert/3|2|x|0.6|x|1.0|cm|in|sp=us}}

For the vast majority of numbers, the unit name will be plural. Sorry for the confusion. -Wikid77 (talk) 00:28, 5 February 2013 (UTC)

Thousands/millions/billions of US gallons

Is it possible to add a function which in the case of US gallons will show instead of the full number (e.g. 210,000,000 USgal) the number in a format which includes a word "thousand", "million" or "billion" (e.g. 210 million US gallons). More precisely, the issue is with the Deepwater Horizon oil spill article. It supports formula {{convert|4.9|Moilbbl|USgal m3}}, but is it possible to make it supporting also {{convert|4.9|Moilbbl|MUSgal m3}} and {{convert|4.9|Moilbbl|e6USgal m3}}? Thank you in advance. Beagel (talk) 09:09, 4 February 2013 (UTC)

Beware that in some countries billion means 10⁹, in some countries it means 10¹² and in quite a lot of British Commonwealth countries it recently changed from 10¹² to 10⁹ (ie old people and young people think of different numbers). However, numbers like 1,000 million are universally understood.  Stepho  talk  11:30, 4 February 2013 (UTC)

• Adding million should be reasonable: Although billions might be misunderstood, we could offer "million US gal" but I think the wp:MOSNUM distains the use of "million" with abbreviated unit symbols. We could allow:

• {{convert|4.9|Moilbbl|USgal m3}} → 4.9 million barrels (210,000,000 US gal; 780,000 m³)
• {{convert|4.9|Moilbbl|MUSgal m3}} → 4.9 million barrels (210 million US gal; 780,000 m³)

I think it seems reasonable. Any objections? -Wikid77 (talk) 13:11, 4 February 2013 (UTC)

• Using {{convert|9|e9USgal}} already produces 9 billion US gallons (34 Gl). The e3 (thousand), e6 (million) and e9 (billion) prefixes go before the usual unit as you can see. Imzadi 1979 → 13:39, 4 February 2013 (UTC)

"to(-)" does not work with abbr

An example in documentation shows that "to(-)" can be used to produce something like "60 to 170 kilograms (130–370 lb)", but it does not work with abbr=on: for example, {{convert|60|to(-)|170|kg|lb|abbr=on}} produces "60–170 kg (130–370 lb)" with both dashes and no "to" at all. — Mikhail Ryazanov (talk) 00:00, 29 January 2013 (UTC)

that's because Template:Convert/to(-)/AonSoff is a redirect to Template:Convert/-/AonSoff at the moment. it would be easy to fix this, but I am wondering if there is a reason in the MOS for not allowing this. it seems like a better choice is to just use {{convert|60|to|170|kg|lb|abbr=on}}, if there reason for not allowing it. Frietjes (talk) 00:21, 29 January 2013 (UTC)

I don't think there is any reason for not allowing "60 to 170 kg (130–370 lb)". As an aside, you can drop the brackets in the code & just use to- (with the same (less then satisfactory) results). JIMp _talk·cont 00:31, 29 January 2013 (UTC)

It should not only be allowed but is actually required in situations like "... from X to Y kg (X'–Y' lb)". Currently it produces "from X–Y kg", which is an incorrect (but for some reason quite common) notation. On the other hand, using "to" produces "... (X' to Y' lb)", which also is not good (should be better "... (from X' to Y' lb)"). I think, the template should be fixed to behave as the unabbreviated version does. — Mikhail Ryazanov (talk) 23:44, 29 January 2013 (UTC)

Any progress here? — Mikhail Ryazanov (talk) 20:17, 11 February 2013 (UTC)

I started working on it, but there are some issues that need to be resolved. Frietjes (talk) 21:50, 11 February 2013 (UTC)

the problem is that the same template is called for both the input and output range, but there is no check to see which is which, so you get the following pathology

{{convert|60|to(-)|170|kg|lb|abbr=on}}	60 to 170 kg (130–370 lb)
{{convert|60|to(-)|170|kg|lb|abbr=off}}	60 to 170 kilograms (130–370 pounds)
{{convert|60|to(-)|170|kg|lb|abbr=in}}	60 to 170 kg (130–370 pounds)
{{convert|60|to(-)|170|kg|lb|abbr=out}}	60 to 170 kilograms (130–370 lb)

with the "to" always associated with the un-abbreviated units, and the dash with the abbreviated units. this is fixable, but will require some more extensive changes. Frietjes (talk) 22:14, 11 February 2013 (UTC)

Template:Convert/LoffAoffDflipSmid missing

Template:Convert/LoffAoffDflipSmid is missing; it appears to have been moved to another specific conversion. This errors on stuff like {{convert|12.2|km|mi|adj=mid|disp=flip|-long|1}} and other similar combinations. —Sladen (talk) 01:16, 2 February 2013 (UTC)

• Re-added for now: I have recreated that subtemplate:

• {{convert|12.2|km|mi|adj=mid|disp=flip|-long|1}} → 7.6-mile-long (12.2 km)

However, long-term (or soon), we need to handle "=flip" in one of the {Convert/xx} wp:wrapper templates, rather than have so many "Dflip" subtemplates. I will work on this soon, to allow several more Convert options with just one new subtemplate, rather than thousands. -Wikid77 (talk) 13:11, 4 February 2013 (UTC)

• See below: #New Convert/f allows new options". -Wikid77 08:40, 10 February 2013 (UTC)

Minus sign for negative temperature range

Hi, came across what seems like an inconsistency on Nissan Leaf: it has {{Convert|20|to|30|F|C}} ... {{Convert|10|F|C}} which renders as 20 to 30 °F (−7 to −1 °C) ... 10 °F (−12 °C), so it looks to me that the Unicode minus for the negative temperature is correctly shown in the second, but in the first (the range), the Unicode negative is not used. This doesn't seem correct to me. Thanks Rjwilmsi 21:38, 11 February 2013 (UTC)

• Use Convert/2 to avoid problems in ranges: The short minus signs in negative temperature ranges are yet another problem in the old Convert range subtemplates. Just use Template:Convert/2, which is more flexible and matches the single-unit formats:

• {{Convert |20|to|30|F|C}}    → 20 to 30 °F (−7 to −1 °C)
• {{Convert/2 |20|to|30|F|C}} → {{convert/2|20|to|30|F|C}}

Originally, Template:Convert did not provide enough output options to support wp:wrapper templates, such as {convert/2}, but now, there is even a {convert/4} which converts 4 amounts at once:

• {{Convert/4 |5|to|10|or|15|to|20|F|C}} → {{convert/4|5|to|10|or|15|to|20|F|C}}

We are trying to offer more features, rather than just perfect old forms which have been surpassed by new wrapper templates. However, thanks for the reminder that old temperature ranges show short minus signs. -Wikid77 (talk) 00:36, 14 February 2013 (UTC)

Tons

According to the ton article a ton is 2,000 lb (910 kg). But when I convert a ton to pounds it equals to 2,200 pounds. Is this an error? If not is there a way to use the American/Canadian ton of 2,000 pounds? Volcanoguy 11:20, 16 February 2013 (UTC)

(edit conflict) There are three different meanings for "ton" and there is often confusion.

• in Britain, the ton (known as the "long ton" in the USA) is defined as 2,240 lb which is equivalent to 1,016.047 kg
• in the USA, the ton (known as the "short ton" in Britain) is defined as 2,000 lb which is equivalent to 907.185 kg
• in Europe, the ton (known as the "metric ton" in Britain and the USA) is defined as 1,000 kg which is equivalent to 2,204.623 lb

Use the unit codes LT ST t for long, short and metric tons respectively. --Redrose64 (talk) 11:46, 16 February 2013 (UTC)

Yes I figured it out, which is why I reverted by my edit. Volcanoguy 13:09, 16 February 2013 (UTC)

New Convert/f allows new options

After years of discussing new features, I have finally created Template:Convert/f as a Convert-format wp:wrapper template to allow rounding the input amount, to round by near=n to the nearest 'n' units, or to insert unit modifiers. There are special options with Convert/f, such as r1=2 to round the input amount to 2 decimals, comma=out to show commas only in the output amount, near=25 (or 50) to round to nearest 25, and x1 to x5 to insert text before/after the units. Some examples:

• {{convert/f |3.1415926|km|mi|r1=2}}   → 3.14 kilometres (1.9520951 mi)
• {{convert/f |9564|km|mi|comma=out}}   → 9564 kilometres (5,943 mi)
• {{convert/f |9564|km|mi|lk=in|near=5}}   → 9,564 kilometres (5,945 mi)
• {{convert/f |10.5|L|usgal|4|x3=exactly}} → 10.5 litres (exactly 2.7738 US gal)

There might be some bugs still, but we have waited years to have these new options. The overall concept is to reduce {Convert} to a simpler tool, with a few basic options, and then add layers of complex features by using wrapper templates, such as Template:Convert/spell or Template:Convert/3, to extend the simple functionality. For example, a Template:Convert/flip would allow any options to be used in a flipped (reverse-order) conversion, without needing 540 subtemplates named "/Dual/L*A*DflipS*". Then {Convert} could be translated into the other-language Wikipedias, where the language cultures deal with U.S. units versus metric, such as descriptions of U.S. towns with road signs labelled in "miles". Currently, "disp=flip" has been widely used with other default options, but all rare options are not supported with "disp=flip", and most other languages cannot cite a source with miles and show it flipped with "kilometres" in their language. -Wikid77 08:40, 10 February 2013 (UTC)

Great work, Wikid77. Thanks for your efforts on this! Question: is there any way to use convert/f to modify input units to kunits or Munits. For example, in this conversion, {{convert/f|100000|lbf|kN|x3=about|lk=out}}, which translates to "100,000 pounds-force (about 440 kN)", is there any way to get the template to show the input as "100 klbf"? Cheers. N2e (talk) 23:29, 19 February 2013 (UTC)

Miles and yards

I'm trying to convert a distance in miles and yards to metric - I've tried {{Convert|1|mi|656|yd|km}}, but this gives 1 mile 656 yards (2.209 km). What am I doing wrong?  An optimist on the run! 12:46, 20 February 2013 (UTC)

Partly answering my own question - there doesn't seem to be a subtemplate template:convert/and/yd, unlike template:convert/and/chain which is what I'd been thinking of. Is this something that could be introduced?  An optimist on the run! 13:32, 20 February 2013 (UTC)

right, if you look at Template:convert/mi, it only recognises chain as the second unit, so while {{convert|1|mi|57|chain|km}} works, {{Convert|1|mi|656|yd|km}} does not at the moment. we would have to change template:convert/mi to make this work. creating template:convert/and/yd doesn't require an admin, so I have done so. Frietjes (talk) 16:56, 20 February 2013 (UTC)

You could hack it like this: 1+656⁄1760 miles (2.209 km) --Redrose64 (talk) 18:03, 20 February 2013 (UTC)

Template:Convert/mi has been updated to work with Template:Convert/and/yd -- WOSlinker (talk) 18:59, 20 February 2013 (UTC)

Thanks guys.  An optimist on the run! 23:26, 20 February 2013 (UTC)

Lua Module:Convert

I have been working on Module:Convert for several months here. The module is a Lua script that (if finished) could be used to implement {{convert}} for wikis that do not have the series of templates used at enwiki, and which may possibly be considered as a replacement for those templates at enwiki. I say "if finished" because studying the templates shows Jimp's extraordinary achievements in designing and implementing the existing templates—their complexity, yet extremely efficient divide-and-conquer approach, would be hard to duplicate. Replacement is therefore only a possibility since Module:Convert may never fully implement the required features, and even if it did implement them, it would be difficult to prove that the implementation was correct. Nevertheless, I feel I should alert people that mw:Extension:Scribunto may be implemented (perhaps within a couple of months), and that Module:Lua may be reasonably complete by that time.

Compared with template wikitext, Lua scripting has several advantages:

• Maintainability. Module:Convert has only two properly-formatted scripts, rather than thousands of convert templates with complex syntax.
• Efficiency. In many applications, a Lua script is much faster than template code, and Lua modules will not have problems with template limits. However, for convert, the templates have been carefully designed to invoke only the small amount of code required for each conversion, and that gives the templates a head start. By contrast, the two Lua convert scripts (one is the code while the other holds the unit data) are enormous since they have to implement all possible conversions.
• Consistency. It is much easier for a Lua script to produce consistent results.
• Error checking. It is much easier for a Lua script to check inputs to avoid common problems. For example, if Module:Convert is given input {{convert|1200|ft|kg}}, it produces an error message as the result: Conversion error: Cannot convert "length" to "mass".

While working on the module, I have noticed some issues with the existing templates which I have documented here to avoid cluttering this talk page.

This is just advance notice for anyone interested, and I'm not anticipating much discussion at the moment because Module:Convert, and indeed Scribunto, are only possibilities at this stage. However, I'm available if anyone wants to discuss anything. Johnuniq (talk) 03:21, 13 February 2013 (UTC)

Looks very good what you have done so far. I added more testcases way back in September 2012 to compare the live template to the sandbox version. Just a case of waiting for Lua to make it onto en.wiki so that some proper testing can be done. Still got more testcases to produce though. -- WOSlinker (talk) 07:36, 13 February 2013 (UTC)

• Not another attempted rewrite: I am glad that more people are learning how {convert} works, but prior total rewrites of the template have failed to handle the issues. Perhaps there should have been an essay, "wp:Rewriting Convert - don't try" because Convert gains power by the staggering multitude of conversion units, not by running faster. When speed is an issue (used hundreds of conversions per page), then other templates have been used. As you might know, there was a prior gargantuan effort to rewrite Convert as a parser function, until it was realized that conversions involve numerous format details, which are best performed by templates. For other-language Wikipedias, we need a simple core set of conversions, with options which are obvious in other languages (which do not speak "off/on"). Then for scientific measurements, we need hundreds of units for cultures which handle US customary units; however, most physical science personnel have learned to speak metric, so even then, the conversions are not much needed, and I am thinking to only put conversions in part of science articles, where US customary units might make sense. What would help to improve Convert would be the following Lua-based templates:

• {getprecision} - count precision of 3.56 or 3+56/100 as "2" or 67,000 as "-3"
• {shownum} - format a minus sign, so -4.500 shows "−4.500" with 2 zeroes
• {roundnum} - round -4.3 by 3 as "−4.300"

Meanwhile, all the other formatting options could be handled by templates, or wp:wrapper templates. There is no need to create a Lua module to act as a harness for the whole of Convert. However, having those {getprecision}, {shownum} and {roundnum} as Lua-based templates could reduce the nesting of Convert by many levels (as well as improving speed). I hope that makes sense, and just consider the attempted rewrite, rewrite, rewrite, and rewrite again, as learning experiences. -Wikid77 (talk) 01:25, 14 February 2013 (UTC)

Let's not debate those points here, but I will make some comments. First, as mentioned in my OP, replacing the enwiki template is only a possibility (however, the deployment is a lot sooner than I anticipated; this VPT comment says that Scribunto will be here on February 18). Second, it is very hard to have complete consistency in a large number of templates, whereas the Lua module already fixes three issues mentioned on this talk page (incompatible units, to(-), minus). Third (and my main motivation), it would be much easier for another wiki if they could install two modules and a tiny template, rather than hundreds of templates. The module makes it easy to customize error messages for a particular language because all messages are in one place. Also, to customize units (for example, to select which units are supported, or to change the article titles used with 'lk=on'), you only have to edit a single page of wikitext (here), then run a script to extract the data from the new wikitext. Johnuniq (talk) 10:34, 14 February 2013 (UTC)

• Module:Convert has an interesting subset of Convert: It is good to explore alternative procedures for calculating conversions. For example, the use of Module:Convert could create a quick-fork template ("Convert/L") to be used several hundred times in a large wp:wikitable. I encourage others to read the Lua script code (test2:Module:Convert). Also, using a Lua module might lead to a "hybrid-form" of Convert, where miles and kilometres would be handled by pass-through in {Convert} then invoking the Lua Module:Convert (for "mi" and "km"), but most of the hundreds of units would be kept in the current add-on-the-fly subtemplates, which allow changing or adding a few units without requiring continual reformatting of all the half-million articles using Convert. Perhaps Template:Convert could be modified to run with a base set of 50 subtemplates, allowing other units as future add-on subtemplates, but also invoke Module:Convert to streamline the "big five" most-common units, without limiting future units to precompiling the Lua module for every new unit added. Long term, the other-language wikipedias which run Convert with "700" scientific units should be allowed to add more units as done now. Anyway, those are some other possibilities for mixed use of Module:Convert along with numerous markup subtemplates to add more of the typical 400 measurement units to deal with other cultural topics, such as teaspoons: {{convert|65|ml|tsp}} → 65 millilitres (). -Wikid77 (talk) 15:44, 18 February 2013 (UTC)

  There are several questions on my mind about how Scribunto (the MediaWiki extension that interfaces to Lua scripts) will operate. What will happen if a widely used template is replaced by a call to a Lua module—will the servers melt? And what would be the consequence of an update to the module—would all associated page caches be invalidated? I have never seen any mention of those issues, but I'm sure the devs have pondered them, so they must think it's ok (so adding a new unit to the existing table of units would be easy, and should not have bad consequences). BTW, Scribunto just went live on enwiki, although it will be quite a while before I'm ready to do any serious testing of Module:Convert as there is still a lot of work I need to do. Johnuniq (talk) 00:23, 19 February 2013 (UTC)

• Modules trigger reformatting but slowly: The developers have stated that changing a Lua module will trigger reformatting of all related pages, stretched over a period of hours. In a sense, changing modules can be considered similar to changing templates, to trigger reformatting of related pages. -Wikid77 (talk) 23:11, 22 February 2013 (UTC)

• Also see: [[#Convert using Lua {rnd} and Lua {str_len}]]. -Wikid77 23:11, 22 February 2013 (UTC)

Complex conversion?

Does convert handle more complex conversions? Right now, it appears that the helper template only uses a multiplicative conversion factor for one unit to another. What if the conversion requires some other method (such as logarithmic, etc) ? If that can be accomplished, I'd like to get another unit onto convert. -- 65.92.180.137 (talk) 06:46, 22 February 2013 (UTC)

conversion from C to F is not simple multiplication, and there is no fundamental reason why other non-multiplicative conversions could not be included as well. Frietjes (talk) 22:13, 22 February 2013 (UTC)

• There is no limit to adding complex conversions: To demonstrate how "Convert can convert anything", I added conversions of piano notes, dates, and wrench sizes (spanners) nearly 4 years ago:

• {{convert|middle C|note}} →
• {{convert|1 February|date|day}} →
• {{convert|9/16|wrench|mm|sp=en}} → 9⁄16 wrench

However, the editors who write each conversion must be willing to work out the formula, or algorithm, and to test several cases. Currently, a whole subset of Convert handles inverse conversions, such as mpgUS to L/100 km, which inverts the distance to be the 2nd quantity:

• {{convert|27|mpgUS|L/100km}} → 27 miles per US gallon (8.7 L/100 km)

If you expect to have several logarithmic conversions, then creating a Convert subsystem could be better, long-term. See internal details: Template:Convert/mpgUS and Template:Convert/L/100km -Wikid77 (talk) 23:11, 22 February 2013 (UTC)

Convert using Lua {rnd} and Lua {str_len}

Days ago, someone changed {rnd} and {str_len} to use Lua script, across all of Wikipedia. Hence, Convert uses the shorter {rnd} (with Lua Module:Math) and nests only 26 expansion levels deep (formerly 28?). For negative numbers, {Convert/numdisp} uses {str_len} with the Lua Module:String. I had thought there would be a small-scale test to alert other editors beforehand, to discuss impacts of changing Template:Rnd to use Lua script, but the change was installed instantly.

In related Lua plans, the wp:CS1 cite templates are being transitioned to use Lua-based templates, but there has been much prior discussion this week, to avoid surprises. See plans: Module_talk:Citation/CS1 and Lua topics at wp:PUMPTECH. -Wikid77 (talk) 23:11, 22 February 2013 (UTC)

• 1.000000 becquerel (2.70270×10⁻¹¹ curies)
• 1.000000 becquerel (27.0270 picocuries)
• 1.000000 kilobecquerel (27.0270 nanocuries)}
• 1.000000 gigabecquerel (27.0270 millicuries)

Bad rounding in pound / kilogram conversion

{{convert|175|lb|kg|lb|abbr=on}} = 175 lb (79 kg)

Expands as:

{{convert/{{#ifeq:lb|oz|and/oz|LoffAonDbSoff}}|{{FORMATNUM:175|R}}||kg|lb|||||s=|r=re|d=LoffAonDbSoff |u=lb |n=pound |t=pound (mass) |o=kg |b=0.45359237 |j=-0.343334259-0}}<!--testing code follows-->

Which eventually expands to contain, in part:

{{rnd|{{#expr:( ( {{FORMATNUM:175|R}} )*0.45359237 )/1}}|lb}}

Note the "lb" in the second parameter spot where it ought to contain an integer indicating the precision that one wants the result rounding to. Due to a historical fluke {{rnd}} essentially ignored such bad precision values (resulting in default rounding to about two sig figs). However, this is still an error and ought to be corrected.

Another way to see this, is that the precision of the kg term is unrelated to the precision of the pound term:

• 12,345,678 lb (5,599,905 kg)
• 1,234,567 lb (559,990 kg)
• 123,456 lb (55,999 kg)
• 12,345 lb (5,600 kg)
• 1,234 lb (560 kg)
• 123 lb (56 kg)
• 12 lb (5.4 kg)
• 1 lb (0.45 kg)
• 0.123456 lb (0.055999 kg)

Dragons flight (talk) 18:35, 23 February 2013 (UTC)

• Can check parameters now: Using 'lb' as a rounding figure is completely invalid, after "|lb|kg" then putting another "|lb", but perhaps an error message could be issued to warn the user, how "lb" is not a rounding number. For years, we had feared adding any parameter checks which might deepen the nesting of expansion depth beyond the pitiful, miserly, 41-level wp:expansion depth limit, which we have suffered all these years. Modern computer software has nesting of, what, 500? levels, and Wikipedia has needed perhaps 80 levels and could not even get 45 levels allowed. For that reason, Convert has been severely hampered all these years. However, now, we could invoke a Lua-based side function to check the {Convert} parameters, and even pinpoint an invalid character in a numeral such as "34.i55" without increasing the expansion depth at all. -Wikid77 (talk) 00:41, 25 February 2013 (UTC)

• It's funny, I took that example from the coding of an infobox template. It didn't occur to me that the template coding might have been wrong. Thanks. Dragons flight (talk) 06:12, 25 February 2013 (UTC)

• Convert ignored invalid parameters for years: Expect other infoboxes to still have invalid parameters with {Convert}, even though this is in fact the 21st century, because we were terrified to add parameter validation into {Convert} for fear of again nearing the severe, tiny 41-level wp:expansion depth limit, which has hindered other templates for numerous years of suffering, despite desperate discussions to raise the limit from 41 to even 45 or 50 levels deep. {Convert} sometimes could not even be used in its own documentation page, due to fatal expansion depth errors. Computer programmers have known, for over 20-30 years, that nested logic, such as for decision trees, needed to run well over 200 levels deep, and in practice, modern software has used unlimited stacks of nested levels. With the plan to speed the wp:CS1 citation templates, we can "slow" {Convert} somewhat to run a basic "sanity check" and warn of invalid parameters. I apologize that the primitive level of parameter validation has misled people into thinking the use of {Convert} was correctly validated inside infoboxes or articles, but parameter errors have been ignored for over 6 years now. Hopefully, we can add the needed warnings (tracked by maintenance categories), because we have learned the trick to show error messages while allowing the conversion to continue so the expansion depth will not be increased by the parameter-validation logic, which can run as a sideshow, rather than a nested precondition to stop invalid conversions. See below: "#Developing Convert/validate to warn errors". -Wikid77 (talk) 14:32/15:29, 25 February 2013 (UTC)

  If you're curious, {{rnd}} is now trapping errors to Category:Pages with bad rounding precision. However, that cat is absolutely flooded due to a unrelated calculation error in the widely used {{infobox settlement}}, so it isn't much use right now. The issue with the settlement template has been raised at the corresponding talk page, and hopefully after it is cleared up the tracking cat will be more useful. Dragons flight (talk) 18:36, 25 February 2013 (UTC)

Great news, and I will scan that large category to spot any obvious bad conversions. I am glad you spotted this internal problem, because imagine the time which some editors might burn when puzzling over the wrong precision of 3-unit errors (such as "|lb|kg|lb"), which I have seen several times. -Wikid77 23:23, 25 February 2013 (UTC)

Fine tuning

For SNCF Class BB 9200#History 10×10⁶ kilometers (6.2×10⁶ mi) (1 million kilometers) instead of 10,000,000 kilometers (6,200,000 mi) Peter Horn User talk 16:05, 27 February 2013 (UTC)

how about 10 million kilometers (6.2 million miles) or 10×10^⁶ km (6.2×10^⁶ mi)? Frietjes (talk) 17:40, 27 February 2013 (UTC)

Sounds good. Peter Horn User talk 15:28, 28 February 2013 (UTC)