Template talk:Convert/Archive July 2017

Linking only one left-hand unit

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 (50.61 miles, 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)

Kilopondmetres per second

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)

Selecting multiple disp= options

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)

Prefixes for multiples of bits (bit) or bytes (B)

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

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)

Module version 18

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

• Module:Convert • Module:Convert/sandbox • same content
• Module:Convert/data • Module:Convert/data/sandbox • same content
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • same content
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

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/km² (2,589,988/sq mi)
    • {{convert|2,589,988|/mi2|/km2|0|abbr=on}} → 2,589,988/sq mi (1,000,000/km²)
  • 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

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)
• {{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) (not an error)

Version 18 to do

• 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

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)

• Emptied current Category:Convert invalid options (~110 P), mostly spellings of |adj, abbr= and their options. Parameter analysis per August 1 should look better then. -DePiep (talk) 01:49, 23 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)

Kg to lb when kg are multiples of 10

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

{{convert|69|kg|lb}} 69 kilograms (152 lb) Y
{{convert|70|kg|lb}} 70 kilograms (150 lb) N
{{convert|71|kg|lb}} 71 kilograms (157 lb) Y
{{convert|79|kg|lb}} 79 kilograms (174 lb) Y
{{convert|80|kg|lb}} 80 kilograms (180 lb) N
{{convert|81|kg|lb}} 81 kilograms (179 lb) Y
--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)

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

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)

I updated the sandbox with Ahecht's code. Some related housekeeping issues slowed this down. Example:

• {{#iferror:{{convert/sandbox|24+1/2|in|cm|abbr=on}}|bad|good}} → good
• {{#iferror:{{convert/sandbox|24½|in|cm|abbr=on}}|bad|good}} → bad

Johnuniq (talk) 10:18, 27 July 2017 (UTC)

ft, in input

From here, the topic shifted into the compound ft, in input form.

@DePiep + Spike: DePiep is working at {{NFL predraft/sandbox}}. Convert has a mechanism to either do a convert (if the input is understood), or to show the input as given. For example:

• {{convert|input=24½ in|cm|abbr=on}} → 24½ in
• {{convert|input=24{{frac|1|2}} in|cm|abbr=on}} → 241⁄2 in
• {{convert|input=24+1/2 in|cm|abbr=on}} → 24+1⁄2 in (62 cm)

The problem is handling ft+in. I could add a small amount of code to convert to handle ftin as a special case with |input=. That would allow the following to work:

• {{convert|input=5 9+1/2 ftin|cm|abbr=on}} → 5 ft 9+1⁄2 in (176.5 cm) (simulated output; this does not currently work)

Do you want to try using input=? Should I add the ftin idea to the sandbox? Johnuniq (talk) 04:03, 27 July 2017 (UTC)

Johnuniq Yes, that would be great! (Picked up my struggle greatly :-) ) Could also help & enhance {{convinfobox}}. Side questions:

Recognising {{frac|1|2}} would be great to, but can be prevented through template /doc. (So should not be a blocker).

Fraction input requires the "+" as in "2+1/2". However, in natural input that is omitted: "2 1/2". Could the new option cover this (add the "+" sign for imperial units)?

For situations where input is not recognised (=returned unedited), is there a error-status or something like that? For example, when input is "circa 2 ft", I'd like to have it categorised, (like in a dedicated category "Category:Using Template:MyTemplate with non-numeric input"). Note that it is not an error per se ("circa" might be OK), but we'd like to maintain & check those situations.

I add: even if it can be tracked (e.g. by #iserror), it would require two similar passes I guess: "if iserror {convert|input=ABC} then categorise else return {convert|input=ABC}". Category name as input option?

Didn't know this |input= option existed. Add to Convert/doc? -DePiep (talk) 09:55, 27 July 2017 (UTC)

I don't want to further complicate convert with code to detect strange inputs, and interpreting "21/2" as 2+1⁄2 is a bit dubious because it would hide garbage input (where the slash was a typo intended as ".", for example). What I could do is write a function in some module specifically for the NFL template and have it do all the ugly interpreting of numbers. I'm not sure how to have a tracking category...that would require code in convert that does not appeal. There is no way to detect if convert decided to return the input unchanged, or if it did a conversion. In principle, the result could be searched to guess whether there was an output such as (62 cm) in the above example. Re documentation: Yes, input=xxx should be documented but it's hard to know how much detail to show. I go to a lot of trouble to write the release notes so they accurately describe changes and new features, but along with the testcases I never get round to updating the doc. I listed the release notes at Module:Convert#Module version history to make them easier to find. Version 18 is a red link because the July archive has not been created yet. Johnuniq (talk) 10:18, 27 July 2017 (UTC)

OK. (btw, the example is corrected into "2 1/2", which requires the "+". Agree, "21/2" should not be read to mean "2+1/2" ever). -DePiep (talk) 10:28, 27 July 2017 (UTC)

Since category adding is not feasible, it would be helpful to add "class=error" to the situation "input not recognised, returned as is". But not convert-categorisation. -DePiep (talk) 11:11, 27 July 2017 (UTC)

@DePiep + Spike: See #input = value1 value2 ftin below. That should make it a lot easier to use convert in {{NFL predraft/sandbox}}. Johnuniq (talk) 09:47, 29 July 2017 (UTC)