Template talk:Convert/Archive July 2017
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
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.
- 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 allowmi
andchainlk
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 theparms
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)
- @Johnuniq: There are two easy options that shouldn't change things for old-time editors. One is to support comma delimited values (e.g.
- 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:
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
- ^ 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)
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 • different (diff)
- 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/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.
- 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.
- 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]].
- Currently, the
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)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
- 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)
{{convert|70|kg|lb}}
70 kilograms (150 lb)
{{convert|71|kg|lb}}
71 kilograms (157 lb)
{{convert|79|kg|lb}}
79 kilograms (174 lb)
{{convert|80|kg|lb}}
80 kilograms (180 lb)
{{convert|81|kg|lb}}
81 kilograms (179 lb)
--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)
- 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)
- 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)
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
@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
newoption 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)
- 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
- Johnuniq Yes, that would be great! (Picked up my struggle greatly :-) ) Could also help & enhance {{convinfobox}}. Side questions:
@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)