Template talk:Convert

For the technical discussion of template design see Template talk:Convert/Technical

"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)

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}}   → Template:Convert/f
• {{convert/f |9564|km|mi|comma=out}}   → Template:Convert/f
• {{convert/f |9564|km|mi|lk=in|near=5}}   → Template:Convert/f
• {{convert/f |10.5|L|usgal|4|x3=exactly}} → Template:Convert/f

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 "Template:Convert/f", is there any way to get the template to show the input as "100 klbf"? Cheers. N2e (talk) 23:29, 19 February 2013 (UTC)

Help in porting to Gujarati Wikipedia

I am trying to port this convert template to Gujarati Wikipedia. When template handles with plural units, it converts but it puts 's' after. To understand, what i am telling see this. Can somebody point me out which template should be manpiluated for plural changes? Thanks!-- Samkit ^{(Talk/Contributions)} 09:10, 10 February 2013 (UTC)

There are basicly two parts to pluralising. For some units pluralising in English simply means adding an "s" ("metre" → "metres", "mile" → "miles", etc.). For others it's more tricky (e.g. "foot" → "feet", "inch" → "inches", "kilometre per hour" → "kilometres per hour", etc.). For these more tricky ones there is the parameter l on the unit subtemplates (e.g. {{convert/ft}}, {{convert/in}}, {{convert/km/h}}, etc.). The second part comes with the display subtemplates (e.g. {{convert/LoffAoffDbSoff}}, {{convert/LoffAonSoff}}, etc.). These check whether the numerical value is one and if it is use the parameter n (from the unit subtemplates) if not then they use l if it is given or, if not, n with an added "s". I've gone and deleted this code from the Gujarati convert/LoffAoffDbSoff and convert/LoffAonSoff so the "s"s aren't appearing on the page in question but that won't fix things for every option (i.e. various linking, display, abbreviating, range, etc. options). I don't know how plurals are handled in Gujarati (nor whether they even exist) so I don't want to go to far. JIMp _talk·cont 00:09, 19 February 2013 (UTC)

Sorry for late reply. Actually, in gujratati language, units are used in singular form only, they are not used in plural form. I want to localize whole Template, are there any other things to watch out for?? Samkit ^{(Talk/Contributions)} 19:55, 1 March 2013 (UTC)

See #Lua Module:Convert below (the link in that post is obsolete, see here instead). The module, which is a month or more away from full implementation, is useful for localization because all messages are in one module, and all units are defined on one wiki page. Johnuniq (talk) 23:17, 1 March 2013 (UTC)

But I am not sure that whether scribunto extension is deployed on gu.wikipedia. Thaks! Samkit ^{(Talk/Contributions)} 16:32, 4 March 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}} → Template:Convert/2

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}} → Template:Convert/4

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)

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)

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)

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)

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)

Need Radiation doses

I would like to see some of these:

• 100 rems (1.0 Sv) (rem)
• 100 sieverts (10,000 rem) or 100 sievert (sievert)
• 100 grays (10,000 rad) or 100 gray (gray)
• 100 rads (1.0 Gy) (rad)
• But please stay away from this 100 roentgen (roentgen) because there is no simple conversion for roentgens, and there are quite a few different meanings for it. People would misuse this one. I almost would like this one flagged so that no one decides later it would be a good idea to convert it. It has to be manually converted.
• 100 curies (3,700 GBq) (Yea, this works) or 100 microcuries (3,700 kBq) (doesn't work) or 100 Curie (Curie)
• 100 gigabecquerels (2,700 mCi) (Yea, this works)

These are commonly-encountered, and quite confusing units. I know most of the idiosyncrasies of these, so I can help if needed. Basically, the USA uses the non-SI units to a great extent, so many publications now list both to be readable by large audiences. The other issue is all of the SI prefixes. Take the curie, for example. I have seen μμCi used for some things (very tiny) and the typical sievert measurements can be pretty small, while the becqueral is just crazy large with GBq. I like to saw logs! (talk) 08:52, 23 February 2013 (UTC)

{{Convert|100|μCi}} 100 microcuries (3,700 kBq) (doesn't work) but {{Convert|100|µCi}} 100 microcuries (3,700 kBq) does. Due to different characters for μ & µ -- WOSlinker (talk) 10:46, 23 February 2013 (UTC)

• Units limited by use in articles: Typically, conversion units have not been added unless they were used in several articles. For that reason, {Convert} did not even convert tablespoons "tbsp" after 12 years of Wikipedia: 10 US tablespoons = 147.867648 ml. However, I think we should add the expected conversions, even if not used in several articles yet. Hence, now I have added "UStbsp" and "AUtbsp":

• {{convert|1.00000|UStbsp|ml}} → 1.00000 US tablespoon (14.7868 ml)
• {{convert|1.00000|AUtbsp|ml}} → 1.00000 Australian tablespoon (20.0000 ml)

For radiation, the following exist:

• {{convert|1.000000|Bq|Ci|abbr=off}} → 1.000000 becquerel (2.70270×10⁻¹¹ curies)
• {{convert|1.000000|Bq|abbr=off}}   → 1.000000 becquerel (27.0270 picocuries)
• {{convert|1.000000|kBq|abbr=off}}} → 1.000000 kilobecquerel (27.0270 nanocuries)}
• {{convert|1.000000|GBq|abbr=off}} → 1.000000 gigabecquerel (27.0270 millicuries)

I will try to add the other unit-codes to {Convert} to handle sievert, rad (unit), and gray (unit) later. -Wikid77 (talk) 14:04, 25 February 2013 (UTC)

Thanks a lot! When a new radiation emergency comes along, it would be great to offer these. Imagine if an emergency happened in the USA, which uses the rem, mrem, and the µCi a lot. Other folks will want to see the more familiar units. I like to saw logs! (talk) 08:37, 4 March 2013 (UTC)

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)

Developing Convert/validate to warn errors

I have begun to experiment with a possible quick parameter validation subtemplate, Template:Convert/validate, which could be run, as a sideshow, to report invalid parameters without increasing the nesting to hit the wp:expansion depth limit. For example:

• {{convert/validate|34|lb|kg|2|sp=us|lk=out}} → Template:Convert/validate
• {{convert/validate|34|lb|kg|zz|sigfig=3}} → Template:Convert/validate
• {{convert/validate|21|ft|1|in|m|2|abbr=on}} → Template:Convert/validate
• {{convert/validate|2L|ft|1|in|m|2|abbr=on}} → Template:Convert/validate

Tests have shown {Convert/validate} can validate conversions at over 500 per second, adding just 1/100 of a second to an article edit-preview, for each 5 uses of {Convert} on a page. The new subtemplate is just for experimentation, at this point, to determine what parameters can be validated without rejecting valid options. The plan is to check for major problems, while not slowing the performance of {Convert}. -Wikid77 (talk) 15:29, 25 February 2013 (UTC)

Watch out for disp=x params -- WOSlinker (talk) 19:16, 25 February 2013 (UTC)

• {{convert|1|ft|disp=x|"|"}}
• 1 foot "0.30 m"
• Template:Convert/validate

• Good catch there, and "adj=mid" or "adj=pre" would use parameter 4 as well. I have added those exceptions as valid, but the typical validation speed remains as 500 conversions/second. Hopefully, those are all the exceptions. It will be good to detect the 3-unit errors (such as "|lb|kg|lb"), which can happen often when reversing "kg|lb" to become "lb|kg" but forgetting to change parameter 4. -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)