Template talk:Convert

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Frequently asked questions (FAQ)
Q: When using {{convert}} why does the answer not seem right sometimes?
A: This template takes into account the precision of the supplied value and generally rounds the output to the same level of precision. If you need to change from the default output precision, see Help:Convert.
Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)?
A: See: Help:Convert units.
For more, see the FAQ.

Module version 18[edit]

Some changes to the convert modules are in the sandbox, and I intend switching the main modules to use the sandbox soon.

The examples use fixed wikitext for the output to show what the new version would produce so they will not change in the future.

  • Units
    • Fix bug in the scale for "per unit area" units due to their use of a conversion scale that broke conversions between defined units of that type and automatic per units of the same type. Discussed here. Comparing the following with the results in the discussion shows that the problem is fixed.
      • {{convert|1,000,000|/km2|/mi2|0|abbr=on}} → 1,000,000/km2 (2,589,988/sq mi)
      • {{convert|2,589,988|/mi2|/km2|0|abbr=on}} → 2,589,988/sq mi (1,000,000/km2)
    • Add unit cda (Cuerda) as it was added to Module:Convert/extra and is used in articles (1 + 2 + 3). Discussed here. See "to do" below.
      • {{convert|12,300|cda|abbr=off}} → 12,300 cuerdas (4,800 hectares; 11,900 acres)
      • {{convert|12,300|cda|abbr=on|lk=in}} → 12,300 cda (4,800 ha; 11,900 acres)
    • Add unit PSh (Pferdestärkenstunde) as it was added to Module:Convert/extra and is used in an article (1) in an automatic per unit: g/PSh. Discussed here. See "to do" below.
      • {{convert|12,300|PSh|abbr=off}} → 12,300 Pferdestärkenstundes (9,000 kilowatt-hours)
      • {{convert|12,300|PSh|abbr=on|lk=in}} → 12,300 PSh (9,000 kWh)
    • New output multiple unit mich (miles and chains) has been added per discussion here and here.
      • {{convert|55.3|km|mich}} → 55.3 kilometres (34 mi 29 ch)
      • {{convert|55.3|km|mich||abbr=on|lk=out}} → 55.3 km (34 mi 29 ch)
      • {{convert|55.3|km|mich|abbr=in|lk=out}} → 55.3 km (34 miles 29 chains)
  • Silent warnings
    • Currently, the warnings parameter is not specified in the wikitext of {{convert}}. That means convert ignores any invalid parameters that are used. That was done because there are thousands of old converts with invalid wikitext. Most cases were added before December 2013 when the module was introduced, but more converts with invalid parameters have been added since then.
    • Documentation for how warnings worked in previous versions is here.
    • With the old and new versions, the setting warnings=1 could be added to {{convert}}. That would cause a warning to be shown for all invalid parameters. However, those warnings would be visible in articles.
    • With the old and new versions, the setting warnings=0 would disable warnings.
    • The new version behaves differently if the warnings parameter is not specified in the wikitext of {{convert}} (discussion here):
      • An error gives the same result as previously, namely that a prominent error message is shown during preview, and a minor message is shown in a saved page.
      • A warning displays a prominent error message during preview, and an unobtrusive asterisk in a saved page. Holding the mouse over the asterisk (not easy) displays further information. The output for most converts ends with ) so searching a displayed page for )* would often find a convert with a warning.
      • Parameters that were marked as deprecated in the old version continue to operate as they did in the old version. For example, a convert with |abbr=comma would be regarded as an error although only an asterisk would be shown in a saved page. Currently, no articles have a convert with a deprecated parameter.
      • Errors in an article add the page to the hidden Category:Convert errors (same as old version).
      • Warnings in an article add the page to the new hidden Category:Convert invalid options.
      • Both error and warning categories use a category sort key. For example, |abbrev=on is an unknown parameter, and using it would add the following to an article: [[Category:Convert invalid options|abbrev=on]].

Release notes for earlier versions are listed here.

Version 18 warning examples[edit]

The following examples illustrate the new "silent warnings" system. The asterisk seems prominent here, but it is very unobtrusive in an article.

  • {{convert|1|m|ft|1.5}} → 1 metre (3.3 ft)*
  • {{convert|1|m|ft|adj=on|sing=mid}} → 1-metre (3.3 ft)*
  • {{convert|1|m|ft|frac=1}} → 1 metre (3.3 ft)*
  • {{convert|1|m|ft|sigfig=0}} → 1 metre (3.3 ft)*
  • {{convert|1|m|ft|disp=/}} → 1 metre or 3.3 feet*
  • {{convert|1|m|ft|madeup=value}} → 1 metre (3.3 ft)*
  • {{convert|1|m|ft|madeup=}} → 1 metre (3.3 ft)*
  • {{convert|1|m|ft|disp=}} → 1 metre (3.3 ft) (it is not an error to specify a known parameter with an empty value)

When previewing an edit, the same converts show prominent messages.

  • {{convert|1|m|ft|1.5}} → 1 metre (3.3 ft)Error in convert: Precision "1.5" must be an integer (help)
  • {{convert|1|m|ft|adj=on|sing=mid}} → 1-metre (3.3 ft)Error in convert: Ignored invalid option "sing=mid" (help)
  • {{convert|1|m|ft|frac=1}} → 1 metre (3.3 ft)Error in convert: "frac=1" needs an integer above 1 (help)
  • {{convert|1|m|ft|sigfig=0}} → 1 metre (3.3 ft)Error in convert: "sigfig=0" needs a positive integer (help)
  • {{convert|1|m|ft|disp=/}} → 1 metre or 3.3 feetError in convert: Option "disp=/" is deprecated (help)
  • {{convert|1|m|ft|madeup=value}} → 1 metre (3.3 ft)Error in convert: Ignored invalid option "madeup=value" (help)
  • {{convert|1|m|ft|madeup=}} → 1 metre (3.3 ft)Error in convert: Ignored invalid option "madeup=" (help)
  • {{convert|1|m|ft|disp=}} → 1 metre (3.3 ft) (not an error)

Version 18 to do[edit]

  • Some help cleaning up Cuerda would be appreciated. It refers to {{convert}} which is a WP:SELFREF problem. I still think that defining cda in convert is dubious given that the article states that cuerda "refers to various units of measurement". However, the unit is used so it is included—it could be removed if consensus changes.
  • Unit PSh has link Pferdestärkenstunde so holding the mouse over PSh shows the name, despite it being a redirect to Horsepower-hour. Is that desirable? Or, would it be better to use the target of the redirect as the link to give result PSh?

Johnuniq (talk) 04:20, 27 June 2017 (UTC)

Regarding "Pferdestärkenstunde", I think it is fine leaving it as a redirect. That way, if down the line it somehow becomes an article on its own, there is no need to update this template. That's the beauty of the redirect system ;) Huntster (t @ c) 04:26, 27 June 2017 (UTC)
PSh and hph are not the same. Basically, redirecting PSh to horsepower-hour is not a smart idea since it leads to confusion, in fact, the confusion of hp and PS is a serious problem in a lot of Wikipedias. --Jojhnjoy (talk) 08:33, 27 June 2017 (UTC)

Oops, I had to edit this section to replace version 17 with 18 because I overlooked Version 17 from May 2017. Johnuniq (talk) 01:55, 1 July 2017 (UTC)

  • Done, the modules have been update. Johnuniq (talk) 03:14, 1 July 2017 (UTC)

Version 18 follow up[edit]

Category:Convert invalid options is starting to fill. As noted above, searching an article for )* often finds the problem, and holding the mouse over * displays a pop-up message. One problem I see is that {{height}} can call convert with |frac=1 and 1 is an invalid value (frac has to be 2 or more). My guess is that the 1 was intented to disable the use of fractions. A better solution would be to output nothing, that is, just |frac=. Would Frietjes please check that because I cannot handle it at the moment. An example from Alexander Wolf is:

  • {{height|m=1.91|precision=0}} → 1.91 m (6 ft 3 in)

Johnuniq (talk) 03:33, 1 July 2017 (UTC)

It looked pretty simple so I edited {{height}} because a lot of articles use it, and many were being added to the category. The testcases were ok, but please check! Johnuniq (talk) 04:16, 1 July 2017 (UTC)
looks fine to me. thank you. Frietjes (talk) 13:31, 1 July 2017 (UTC)
  • Excellent work! I think WOSlinker fixed most of them (there were well over 1,000 articles in the category a couple of weeks ago). I did a hundred or so. The category will continue to fill as old pages are purged. Johnuniq (talk) 02:17, 23 July 2017 (UTC)

Plurals[edit]

In the following extract from the Gallaudet University page, the measurement should show the unit name (acre) in the singular instead of the plural that is actually displayed: "located in Washington, D.C., on a 99 acres (0.40 km2) campus." This is the same usage as saying "a 30 meter yacht" as opposed to "a yacht measuring 30 meters". Is there a way to fix this? --Khajidha (talk) 13:36, 28 June 2017 (UTC)

Found it. "adj=on". --Khajidha (talk) 13:43, 28 June 2017 (UTC)
@Khajidha: the other difference is that |adj=on also hyphenates the number to the unit name because "99-acre" is a compound adjective. There is also |adj=mid to allow something "a 30-metre-long (98 ft) yacht" to properly render the full compound adjective. Imzadi 1979  20:19, 28 June 2017 (UTC)

Kg to lb when kg are multiples of 10[edit]

Seems to produce an error converting kg to lb when kg are multiples of 10.

{{convert|69|kg|lb}} 69 kilograms (152 lb) Green tickY
{{convert|70|kg|lb}} 70 kilograms (150 lb) Red XN
{{convert|71|kg|lb}} 71 kilograms (157 lb) Green tickY
{{convert|79|kg|lb}} 79 kilograms (174 lb) Green tickY
{{convert|80|kg|lb}} 80 kilograms (180 lb) Red XN
{{convert|81|kg|lb}} 81 kilograms (179 lb) Green tickY
--S Philbrick(Talk) 19:04, 10 July 2017 (UTC)

Sphilbrick, those are the correct results, just rounded to a precision based on the number of significant figures in the input. you can override the precision using
{{convert|69|kg|lb|0}} 69 kilograms (152 lb)
{{convert|70|kg|lb|0}} 70 kilograms (154 lb)
{{convert|71|kg|lb|0}} 71 kilograms (157 lb)
{{convert|79|kg|lb|0}} 79 kilograms (174 lb)
{{convert|80|kg|lb|0}} 80 kilograms (176 lb)
{{convert|81|kg|lb|0}} 81 kilograms (179 lb)
or
{{convert|69|kg|lb|sigfig=3}} 69 kilograms (152 lb)
{{convert|70|kg|lb|sigfig=3}} 70 kilograms (154 lb)
{{convert|71|kg|lb|sigfig=3}} 71 kilograms (157 lb)
{{convert|79|kg|lb|sigfig=3}} 79 kilograms (174 lb)
{{convert|80|kg|lb|sigfig=3}} 80 kilograms (176 lb)
{{convert|81|kg|lb|sigfig=3}} 81 kilograms (179 lb)
or
{{convert|69.|kg|lb|0}} 69 kilograms (152 lb)
{{convert|70.|kg|lb|0}} 70 kilograms (154 lb)
{{convert|71.|kg|lb|0}} 71 kilograms (157 lb)
{{convert|79.|kg|lb|0}} 79 kilograms (174 lb)
{{convert|80.|kg|lb|0}} 80 kilograms (176 lb)
{{convert|81.|kg|lb|0}} 81 kilograms (179 lb)
or many other ways. Frietjes (talk) 19:14, 10 July 2017 (UTC)
Thanks, although I would not have established the defaults that way.--S Philbrick(Talk) 19:21, 10 July 2017 (UTC)
That is broken anyway. In science, 70.0 and 70.0000 have a different precision than 70 or 7x10^2, but that is for trained scientists who understand the rules. Splitting hairs over whether a decimal point is inserted in an encyclopedia is wrong, since this is casual usage, not science. Precision should be assumed to be at least one zero in, because regular users won't realize that 70 will be rounded wildly differently from 69 and realize that they need to follow arcane syntax rules. In casual usage, precision needs to either follow the actual number of zeros used, or at least one or two, because 70 or 700 can be just as precise a number of kilograms as 69 is. It would be better to default to extra sig figs, and allow scientific sig figs as an option, rather than the other way around. SilverbackNet talk 19:36, 22 July 2017 (UTC)
An argument could be made to support higher default precision for 70 kg because that is a common weight for humans (also 80 and more, I guess). However, any change would have to be after a long analysis of actual usage in articles. I have fixed many hundreds of converts in articles and have often found cases where an editor had inserted a false precision into the convert—removing the specified precision usually gave a better result. I have seen lots of cases where convert's defaults do not give the desired result, but I don't think the mechanism for choosing the default could be improved other than by making a small number of exceptions, such as for 70 kg. However, the simplicity of the current system (where numbers are converted based on their significant figures) has benefits. Some exceptions to how convert rounds already exist, although they are a bit too complex for me to summarize. Johnuniq (talk) 02:37, 23 July 2017 (UTC)

Prefixes for multiples of bits (bit) or bytes (B)[edit]

Hello,
I have started to add the Units of information within the Module:Val/units but I have made some mistakes because I am a beginner with the sandbox pages and because of the lack of IEC prefixes support. Therefore I propose to add this following variable. After this step, I or someone else can experiment new code in Module:Convert/sandbox. Please, see also my related questions on Module talk:Val/units#How to preview Template:Val/list while editing Module:Val/units ?
--Oliver H (talk) 23:24, 11 July 2017 (UTC)

-- Some units of information accept an IEC prefix before the unit code, such as "MiBit" for kilogram.
local IECprefixes = {
	['Yi'] = { power_of_two = 80, name = 'yobi', },
	['Zi'] = { power_of_two = 70, name = 'zebi', },
	['Ei'] = { power_of_two = 60, name = 'exbi', },
	['Pi'] = { power_of_two = 50, name = 'pebi', },
	['Ti'] = { power_of_two = 40, name = 'tebi', },
	['Gi'] = { power_of_two = 30, name = 'gibi', },
	['Mi'] = { power_of_two = 20, name = 'mebi', },
	['Ki'] = { power_of_two = 10, name = 'kibi', },
}

See Binary prefix:

Specific units of IEC 60027-2 A.2 and ISO/IEC 80000
IEC prefix Representations Customary prefix
Name Symbol Base 2 Base 1024 Value Base 10 Name Symbol
kibi Ki 210 10241 1024 1.02×103 kilo k[1] or K
mebi Mi 220 10242 1048576 1.05×106 mega M
gibi Gi 230 10243 1073741824 1.07×109 giga G
tebi Ti 240 10244 1099511627776 1.10×1012 tera T
pebi Pi 250 10245 1125899906842624 1.13×1015 peta P
exbi Ei 260 10246 1152921504606846976 1.15×1018 exa E
zebi Zi 270 10247 1180591620717411303424 1.18×1021 zetta Z
yobi Yi 280 10248 1208925819614629174706176 1.21×1024 yotta Y

See Template:Quantities of bits:

Value IEC JEDEC
1024 210 Kibit kibibit Kbit kilobit
10242 220 Mibit mebibit Mbit megabit
10243 230 Gibit gibibit Gbit gigabit
10244 240 Tibit tebibit -
10245 250 Pibit pebibit -
10246 260 Eibit exbibit -
10247 270 Zibit zebibit -
10248 280 Yibit yobibit -

See Template:Quantities of bytes:

Value IEC JEDEC
1024 KiB kibibyte KB kilobyte
10242 MiB mebibyte MB megabyte
10243 GiB gibibyte GB gigabyte
10244 TiB tebibyte
10245 PiB pebibyte
10246 EiB exbibyte
10247 ZiB zebibyte
10248 YiB yobibyte

References

  1. ^ Ray Horak (2008). Webster's New World Telecom Dictionary. John Wiley & Sons. p. 271. ISBN 9780471774570. In computing and storage systems, a kB (kiloByte) is actually 1,024 (2^10) bytes, since the measurement is based on a base 2, or binary, number system. The term kB comes from the fact that 1,024 is nominally, or approximately, 1,000. 
I don't think this is a convert issue because there is nothing useful convert can do. Be aware that an a large amount of discussion/disruption has occurred over stuff like megabyte/mebibyte and a WP:MOS discussion should be undertaken if planning some significant change. I will look at Module talk:Val/units later. Johnuniq (talk) 00:05, 12 July 2017 (UTC)
The -bi- units are one of the most hated, or at least polarizing, names in the history of measurement. Be very careful with unilaterally introducing them. SilverbackNet talk 19:40, 22 July 2017 (UTC)

Linking only one left-hand unit[edit]

In the lede of Brighton railway station it would be nice to be able to link chain without also having to link mile (which seems too common a term to be linked). As far as I can tell though the template doesn't provide that option; i.e., it's possible to link both "miles" and "chains" with lk=in but not only one or the other. Can anyone help? – Arms & Hearts (talk) 14:17, 15 July 2017 (UTC)

  • Hand-code custom conversions or use disp=out: In general, the top lede paragraph should use hand-coded conversions, and then special wikilinks can be inserted anywhere: "50 miles 49 [[chain (unit) #length|chains]] (81.5 [[kilometres|km]])" to show "50 miles 49 chains (81.5 km)". The mouse-over text for "chains" will show bottom status line "Chain (unit)#length" where "#length" is an extra comment added for further clarity. For custom conversions added into quotations, then use "disp=out" with square brackets "[_]" such as American horsefeed sacks are often marked "50# [22.7 kg]" with the conversion displayed by "{{convert|50|lb|kg|1|disp=out}}". -Wikid77 (talk) 17:57, 15 July 2017 (UTC)
    • @Wikid77: Thanks, but I'm not sure I fully understand. Are you saying that the best thing to do would be to simply not use the template? – Arms & Hearts (talk) 21:09, 15 July 2017 (UTC)
As noted above, the best convert can do is link both units. However, {{miles-chains}} can be used.
  • {{convert|50|mi|49|chain|km|lk=in}} → 50 miles 49 chains (81.5 km)
  • {{miles-chains|50|mi|49|chain|km}} → 50 miles 49 chains (81.45 km)
There was an unsatisfactory discussion at #Miles and chains above where a way to output miles/chains was requested. That's not relevant to this request, but for the record I added mich because my request here produced an example where it would be useful.
  • {{convert|81.45|km|mich}} → 81.45 kilometres (50 mi 49 ch)
It would be possible to make a special unit, say chainlk, and have it always link the unit. That would require a new release of the module for a new definition to allow mi and chainlk to be used together. Given that {{miles-chains}} is available, tweaking convert may not be warranted. Johnuniq (talk) 04:23, 16 July 2017 (UTC)
Thanks! I've replaced {{convert}} with {{miles-chains}} at Brighton railway station. – Arms & Hearts (talk) 20:31, 16 July 2017 (UTC)

Selecting multiple disp= options[edit]

I was setting up a unit convert inside of a parenthetical, at which point I generally use the disp=comma option so as to avoid nested parentheticals. However, this particular convert needs a different disp=option, namely the disp=preunit option. It appears multiple disp= options are not supported, unfortunately, which means I'll need to come up with a different way of doing things.

More generally, though, I would have thought things like parentheses/brackets/commas/or should be completely orthogonal from options like pre-unit and displaying part of the result. Or am I totally missing how to do this?

Perhaps there should be a separate parameter for joins vs. the other disp= options, with backward compatibility? Cthomas3 (talk) 05:08, 17 July 2017 (UTC)

Please post what input the convert would have and what output you would like displayed. Then we can see if there is a method to achieve it. The issue of parameter names has been discussed but no one has yet come up with a good solution. The reason that many different options were added to disp=... is that it was very hard to code any alternative when convert was implemented purely with templates. Now that a module is used, it would be possible to have different parameter names, but that has at least two problems. First, there are lots of old-time editors who are used to adding converts in a certain way, so stopping an old option from working would need careful thought. Second, having just a couple of paramenter names makes it a lot easier to remember what is needed. Johnuniq (talk) 05:58, 17 July 2017 (UTC)
@Johnuniq: There are two easy options that shouldn't change things for old-time editors. One is to support comma delimited values (e.g. |disp=comma,preunit), the other is to support |disp1=, |disp2=, |disp3=, etc. The magic of Lua is that it can easily parse delimited text and it can support an indefinite number of parameters without having to manually specify them in advance. The first option is probably the cleanest. The module already reads the value of |disp= and sets it as a key in the parms table, so all it would have to do is parse the delimited text into separate keys in table instead.--Ahecht (TALK
PAGE
) 17:31, 21 July 2017 (UTC)
  • Flexible custom options were x1, x2, x3 etc. Back in early 2013 (5 years ago), the option "disp=preunit" was generalized as separate (orthogonal) custom option "x1=xxx" to insert text 'xxx' before the first unit name, while "x2=yyy" would insert text 'yyy' after that unit; x3 inserted text before the output amount, etc. Those custom options were in the Convert wp:wrapper templates {{convert/2}}, {{convert/show2}} or {{convert/show3}} (all now deleted). Meanwhile, the Lua fork of Convert, instead, did implement the alternate adjective option "adj=pre" to avoid disp=preunit and allow "disp=or" as good enough for many cases. See example:
  • {{convert|4|mi|km|adj=pre|statute|disp=or}} → 4 statute miles or 6.4 kilometres
The problem with options x1,x2, x3 (etc.) is that the location of inserted text around units would change depending on single-amount versus a range of converted values, and so separate templates for 2-value range versus 3-value range were used to simplify custom formats for users (with specific examples for ranges rather than single-value conversions). The Lua fork of Convert did not provide all those flexible custom options, and hence many sophisticated format options after 2012 were lost in the Lua version of Convert over 5 years ago, such as loss of custom words in ranges, or loss of "r=2" to round to 2 digits with custom text, loss of auto-adjusted precision, or loss of near=3 to round metres to nearest 3 feet, or near=30 to round 10-metre precision to nearest 30 feet as closer equivalents. The wrapper templates provided so many excellent features or rapid improvements, quickly added within days of user requests, without triggering the current reformat of a half-million pages for each new feature, and so the Convert wrapper templates are still the easy solution for simple custom conversions. -Wikid77 (talk) 08:17, 18 July 2017 (UTC)

Kilopondmetres per second[edit]

The template lacks kilopondmetres per second; 1 kp·m/s = 9.80665 W. --Jojhnjoy (talk) 20:34, 18 July 2017 (UTC)

In case anyone is tempted to respond, first read Template talk:Convert/Archive May 2017#Kilopondmetre and note that nothing has changed since then. I don't think any response is required. Kendall-K1 (talk) 22:03, 18 July 2017 (UTC)

Add <span class="error"></span> to cvt_format and cvt_format2[edit]

Per this discussion at VPT, I am proposing changing the following lines in Module:Convert/text:

cvt_format = '<sup class="noprint Inline-Template" style="white-space:nowrap;">[<i>[[Help:Convert messages#$4|<span title="Convert: $1">convert: $2</span>]]</i>]</sup>$3',
cvt_format2 = '<sup class="noprint Inline-Template" style="white-space:nowrap;">[[Help:Convert messages#$4|<span title="Convert: $1">$2</span>]]</sup>$3',

to

cvt_format = '<sup class="noprint Inline-Template" style="white-space:nowrap;">[<i>[[Help:Convert messages#$4|<span title="Convert: $1">convert: $2</span>]]</i>]</sup>$3<span class="error"></span>',
cvt_format2 = '<sup class="noprint Inline-Template" style="white-space:nowrap;">[[Help:Convert messages#$4|<span title="Convert: $1">$2</span>]]</sup>$3<span class="error"></span>',

This won't change the visible output of the template, but it will allow errors produced by the template to be detected by {{#iferror}}. --Ahecht (TALK
PAGE
) 17:17, 21 July 2017 (UTC)

I removed {{edit protected}} because things happen slowly here. First, the problem at VPT needs to be considered. Then a discussion should occur. Then a change to the sandbox and testing. Then, a change can be incorporated in the next release.
The proposal is to insert <span class="error"></span> in two places. That means the error class would be present when a convert error or deprecated warning is displayed. The error class is already used when an invalid convert is previewed.
A lot of discussion about the error messages is spread over Module talk:Convert/Archive 1, but that's historical and I don't think it's relevant. The proposal seems good to me, but let's see if anyone has some other ideas. It's strange that no one has wanted this feature before, and I'm wondering how similar issues are handled and whether iferror is the best way to handle whatever is the underlying issue. Johnuniq (talk) 00:58, 22 July 2017 (UTC)
One of those blindingly obvious things in retrospect that makes you wonder how it wasn't done years ago. Good use for anyone building on Convert. SilverbackNet talk 20:05, 22 July 2017 (UTC)
As I added to the VPT thread: "preview()" usage is not the issue. Especially since "class=error" does not change the output (article rendering; visuals), the logical solution is to add it. Reading Johnuniq here, it is clear that this proposal is well received and will go into the development pipeline. -DePiep (talk) 20:26, 22 July 2017 (UTC)
Thanks for this proposal which will happen soon...I got sidetracked and later have to make an ANI report (see User:Johnuniq/ccTLD), and tomorrow will be processing this. The original motivation might not proceed, but the change is desirable, although I'm still puzzled about why no one raised it before. Johnuniq (talk) 00:03, 25 July 2017 (UTC)
Could it be that the "original motivation" link is leading to an unrelated discussion? (also interesting BTW). -DePiep (talk) 07:54, 25 July 2017 (UTC)
Well, it's not totally unrelated. It was like that: I wanted to add template:convert to template:NFL predraft (this is the linked discussion). But there are many uses of NFL predraft already and many given parameters are in a form which convert does not understand. So I asked for a bot which would rewrite the parameters (Wikipedia:Bot_requests#Rewriting_arguments_of_template:NFL_predraft_so_they_can_be_used_with_template:convert). There, User:Anomie suggested that I use iferror as a fallback mechanism to not disrupt the display of NFL predraft as long as the parameters are not rewritten. I tried his suggestion out, it didn't work as expected, and I asked a question in VPT. From there, User:Ahecht came here to make this request, and here we are... Spike (talk) 09:23, 25 July 2017 (UTC)
I see. -DePiep (talk) 13:11, 25 July 2017 (UTC)
I'll be thinking about a clean way to achieve what you want when I get a chance...might not be for a few days. The problem is the feet-and-inches entry which has two numbers. The others can be handled by convert with no error; I'll show you how later. I would suggest getting better support before investing too much effort. Johnuniq (talk) 23:08, 25 July 2017 (UTC)