Template talk:Convert/Archive September 2013

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Default precision with composite inputs

I'm investigating some fiddly details regarding rounding for Module:Convert (see Module talk:Convert for explanation). There are various composite input units such as feet/inches in {{convert|6|ft|2|in|cm}}. Is there a typo in {{Convert/and/chain}}? I think the "-" in the following line should be "+":

|j=1.303558898-{{#expr:{{{3}}}1=101 or {{{3}}}1=1}}

The same issue occurs in the recently created {{Convert/and/yd}} (I think it also should have the minus changed to plus). For example, the first of each of the following pairs should have the same precision as the second:

  • {{convert|13|mi|10|chain|km}} → 13 miles 10 chains (21.1 km)
  • {{convert|13|mi|11|chain|km}} → 13 miles 11 chains (21.1 km)
  • {{convert|3|mi|10|yd|km}} → 3 miles 10 yards (4.837 km)
  • {{convert|3|mi|11|yd|km}} → 3 miles 11 yards (4.838 km)

Here are the same converts using the module:

  • {{convert/sandboxlua|13|mi|10|chain|km}} → 13 miles 10 chains (21.1 km)
  • {{convert/sandboxlua|13|mi|11|chain|km}} → 13 miles 11 chains (21.1 km)
  • {{convert/sandboxlua|3|mi|10|yd|km}} → 3 miles 10 yards (4.837 km)
  • {{convert/sandboxlua|3|mi|11|yd|km}} → 3 miles 11 yards (4.838 km)

Johnuniq (talk) 10:44, 2 June 2013 (UTC)

looks like you are correct, and the sign is flipped. Frietjes (talk) 17:46, 2 June 2013 (UTC)
j = 1.303558898+1+{{#ifexpr:{{{3|10}}} mod 10 = 0|1|0}}
That formula for j will give the reasonable default precision, where different numbers of chains yield different km amounts. Because 1 mi = 80 chains, then the chain number can range between 0-79.99, and multiples of 10 must add +1 to the precision, where the number sense of "30 chains" means whole number between 29.5-30.5 chains (not nearest 10's in 25-34.99). Testing of the sandbox is triggered by unit-code "mi/sandbox" in the following examples:
Thank you for spotting this serious rounding problem in precision of miles+chains conversions. With 1 mile = 80 chains, then 2-decimal output is needed. I am working to have reset the "yd" 2-unit conversions. -Wikid77 (talk) 20:45, 5 June, 11:10, 12 June, 09:42, 25 June, 12:35, 5 September 2013 (UTC)
  • Fixed precision for Convert/and/yd as +4 digits: I have fixed the default precision for Template:Convert/and/yd, which converts 2-unit amounts, such as miles and yards, to other units. The precision defaults now to 4-digit level, where 1 km = 1,094 yards. Some examples:
  • {convert|4|mi|0|yd|km} → 4 miles 0 yards (6.437 km)
  • {convert|4|mi|9|yd|km} → 4 miles 9 yards (6.446 km)
  • {convert|4|mi|10|yd|km} → 4 miles 10 yards (6.447 km)
  • {convert|4|mi|11|yd|km} → 4 miles 11 yards (6.447 km)
  • {convert|4|mi|12|yd|km} → 4 miles 12 yards (6.448 km)
  • {convert|1|mi|800|yd|km} → 1 mile 800 yards (2.341 km)
  • {convert|1|mi|801|yd|km} → 1 mile 801 yards (2.342 km)
  • {convert|1|mi|810|yd|km} → 1 mile 810 yards (2.350 km)
  • {convert|1|mi|811|yd|km} → 1 mile 811 yards (2.351 km)
Because "800 yards" is typical of a rounded amount, then the precision is 1 digit lower for multiples of 100 yards. In general, the precision has been too low because one-decimal precision seems typical for other conversions, whereas km-to-yard is actually a 4-digit difference. By comparison, chains are a 2-digit difference. So, Template:Convert/and/chain should reset the precision parameter j as:
j = 1.303558898+1+{{#ifexpr:{{{3|10}}} mod 10 = 0|1|0}}
Then chains would show the 2-digit precision. -Wikid77 (talk) 23:08, 8 June, 09:00, 8 July, 23:54, 18 July, 11:53, 31 July, 06:36, 20 August 2013 (UTC)

Added Convert/dual options r2 and r3

For years, we have needed to separately round the output amounts in the multi-2 and multi-3 conversions. Now, {{Convert/dual}} allows "r2=1" or "r3=4" to round the first output to 1 decimal digit or 2nd output (r3) to 4 digits, at the same time. Examples:

  • {{convert/dual |7|dunam|m2|acre|r3=4}}     → {{convert/dual |7|dunam|m2|acre|r3=4}}
  • {{convert/dual |7|dunam|m2|acre|r2=1|r3=4}} → {{convert/dual |7|dunam|m2|acre|r2=1|r3=4}}

This is a simple extension, to allow separate rounding of each amount. Already, "r1=" can round the input amount when displayed. For example:

  • {{convert/dual |1000*pi |m|ft|mi|r1=3}} → {{convert/dual |1000*pi |m|ft|mi|r1=3}}

The use of "r1=3" causes the "1000*pi" value to be displayed (but not alter the default precision), rather than show "pi" in the conversion. -Wikid77 07:26, 23 August, 12:35, 5 September 2013 (UTC)

Time conversion

This may be a stupid question, but is there a "convert" between 12-hour time and 24-hour time? Should there be? (I'm asking in regard a "recent" (within the last 2 months, anyway) edit to 2005 where the first YouTube upload was dated.) — Arthur Rubin (talk) 17:33, 2 September 2013 (UTC)

Meanwhile, I will expand {convert/time} for more conversion options to change one timestamp into another format. -Wikid77 12:35, 5 September 2013 (UTC)

Converting value

Is it possible, or even practical, to include syntax in this template for converting the value of an amount of currency from one era to its modern equivalent? Similar to what this inflation calculator accomplishes.—John Cline (talk) 06:57, 4 September 2013 (UTC)

{{USD}} and {{AUD}} have this built-in. They use {{Inflation}} to do the dirty work, which calculates inflation for Australia, Canada, Germany, UK and US.  Stepho  talk  08:37, 4 September 2013 (UTC)
...and Indian rupees. Jimp 08:47, 4 September 2013 (UTC)
Thank you for this information!—John Cline (talk) 08:57, 4 September 2013 (UTC)
  • Perhaps need Convert/USD as reminder to use {Inflation}: We could create a few new currency subtemplates to connect to Template:Inflation, for people who do not know how to search for the other related templates. -Wikid77 (talk) 12:35, 5 September 2013 (UTC)

convert/3 rounding issue

I can't get {{convert/3}} to round my figures. For example, {{convert/3|600|x|230|x|25|mm|in|0}} is giving me {{convert/3|600|x|230|x|25|mm|in|0}}, and {{convert/3|600|x|230|x|25|mm|in|sigfig=0}} is giving me {{convert/3|600|x|230|x|25|mm|in|sigfig=0}}. Curly Turkey (gobble) 01:41, 6 September 2013 (UTC)

Wikid77 may fix that soon, but for anyone interested, the following shows how the module that is under development handles this issue:
  • {{convert/sandboxlua|600|x|230|x|25|mm|in|0}} → 600 by 230 by 25 millimetres (24 in × 9 in × 1 in)
  • {{convert/sandboxlua|600|*|230|*|25|mm|in|0}} → 600×230×25 millimetres (24×9×1 in)
  • {{convert/sandboxlua|600|*|230|*|25|mm|in|sigfig=3}} → 600×230×25 millimetres (23.6×9.06×0.984 in)
I thought the module should use "x" consistently for all ranges, so "*" needs to be used if "×" is wanted throughout. Johnuniq (talk) 02:20, 6 September 2013 (UTC)
So should I just leave it as it is, and a fix will magically appear one of these days? Curly Turkey (gobble)
Yes, I think that's right. Much better to use the standard template and put up with temporary less-than-ideal output, than to put in some manual work-around. Johnuniq (talk) 04:02, 6 September 2013 (UTC)
  • Convert/3 has been edit-protected against improvements 2 years: In August 2011 (over 2 years ago), Template:Convert/3 was full-protected against user edits, and no improvements were installed. However, the sandbox version has been updated several times (Template:Convert/3/sandbox), to be installed as {convert/3}, one of these years. Note:
  • {{convert/3/sandbox |600|x|230|x|25|mm|in|0}} → {{convert/3/sandbox|600|x|230|x|25|mm|in|0}}
  • {{convert/3/sandbox |600|x|230|x|25|mm|in|sigfig=4}} → {{convert/3/sandbox|600|x|230|x|25|mm|in|sigfig=4}}
Many of the known problems were actually fixed, years ago, but the protected pages have shutdown progress to install the many upgrades. Numerous other fixes could be made within a few days, but the total lockup has halted years of improvements, and I tend to forget the exact details to change after 3 or 4 years. As several people have noted, with the current impact of page protections, "This isn't a wiki" and we have the typical multi-year bottlenecks as in any bureaucracy where changes must be pre-authorized by "hand-written forms submitted in triplicate (hand-copied, no xerox) by walking up to the 4th floor" then walking down, and back up to ask again each time. -Wikid77 (talk) 12:37, 6 September 2013 (UTC)

Would using {{editprotected}} or simply requesting unprotection solve the problem? If not how would you suggest improving the workflow? Thryduulf (talk) 13:58, 10 September 2013 (UTC)

Missing word in documentation text

in Usage section, first paragraph, "The can help..." should probably read "The template can help...", or somesuch? Grye (talk) 17:54, 9 September 2013 (UTC)

  • Thanks, corrected. That was a "new" sentence added on 11 February 2012 (see: dif890), but not proofread due to all the work on adjusting the various calculations and adding several new features instead. Thanks for checking that. -Wikid77 (talk) 01:50, 10 September 2013 (UTC)

Yet another dual

For Johnstown Inclined Plane: 22 short tons (20 metric tons; 20 long tons) instead of 22 short tons (20 t) so as to include long tons. Peter Horn User talk 17:57, 2 September 2013 (UTC)

Make that 22 short tons (20 metric tons) Peter Horn User talk 18:08, 2 September 2013 (UTC) Peter Horn User talk 18:23, 2 September 2013 (UTC)
  • Use Convert/dual for 2 output units: To reduce the need for special multi-output subtemplates, please use new Template:Convert/dual. We are trying to avoid more thousands of subtemplates for every combination of 2 output units. In this case:
  • {{convert/dual |22|ST|MT|LT}}        → {{convert/dual |22|ST|MT|LT}}
  • {{convert/dual |22|ST|MT|LT|r3=2}} → {{convert/dual |22|ST|MT|LT|r3=2}}
The optional parameter "r3=2" rounds the 3rd amount to 2 decimal digits. -Wikid77 12:35, 5 September 2013 (UTC)
Ah, but the "metric tons" for MT gets lost in {{Convert/dual|3|ST|MT|LT|2|adj=on}} and becomes a simple "t", and that was not the intention of the original template!! The following do not yet work properly: {{Convert/dual|3|ST|MT|LT|2|adj=on|lk=on}}, {{Convert/dual|22|ST|MT|LT|abbr=off}}, {{Convert/dual|15|ST|MT|LT|abbr=off}}, {{Convert/dual|15|ST|MT|LT|abbr=off|lk=on}}. Peter Horn User talk 15:08, 5 September 2013 (UTC)
  • FIXED. I have totally rewritten the internals of Template:Convert/show2 (convert/dual) in my spare time today, as double-nested dynamic templates to bypass the 900 combination subtemplates for "disp=unit" and "disp=u2" with options lk, abbr, or adj. Sorry for the delay, but I was unable to login with my http-mode username due to the forced-https protocol, which dropped all edit-preview screens & erased the new subtemplates upon browser-back. It took me longer to rewrite the massive dual-unit algorithms twice in the short time I had, while re-trying to login all morning. I have also rewritten Template:Convert/show3 to show any combination of 3 output units. -Wikid77 11:04/23:57, 6 September 2013 (UTC)
This then also works for {{convert/dual|1|USpt|L|imppt}}, {{convert/dual|1.2|L|USqt|impqt}} and {{convert/dual|0.6|L|USqt|impqt}} for German obsolete units of measurement#Nösel Peter Horn User talk 18:31, 13 September 2013 (UTC)
Just a minor problem or glitch, in {{convert/dual|1.2|L|USqt|impqt|sp=us}} The US spelling does not yet kick in. Peter Horn User talk 18:44, 13 September 2013 (UTC)
1.2 liters (1.3 U.S. qt; 1.1 imp qt) Frietjes (talk) 18:50, 13 September 2013 (UTC)

Frietjes has just created {{Convert/USqt impqt}}, but the module is also flexible. To add this unit to the module, you would search Module:Convert/data for a similar unit to see what format is required (a bit frightening, but with the advantage that everything is in one place), then you would add the following to Module:Convert/extra as a quick and low-overhead test: 

    ["USqt impqt"] = {
        combination = { "USqt", "impqt" },
        utype = "volume",
    },

Compare with the wikitext for the template: 

{{convert/multi2{{{d}}}|{{convert/{{{d}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}
|u=US qt
|n=US quart
|h=US-quart
|t=United States customary units#Fluid volume
|o=ml
|b=0.000946352946
|j=-3.023946862-{{{j}}}}}|{{convert/{{{d}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}
|u=imp qt
|n=imperial quart
|h=imperial-quart
|o=ml usoz
|b=0.0011365225
|j=-2.944421962-{{{j|0}}}}}}}<noinclude>
[[Category:Subtemplates of Template Convert]]
</noinclude>

Johnuniq (talk) 01:53, 14 September 2013 (UTC)

so, why are we not using the module? the common theme for this talk page is that, someone reports a bug, you extol the virtues of the lua module, and then, after noticing that there is no timetable to switching to the module, someone fixes the template. how about if we save some time by switching to the lua module so I can stop updating the templates? and, even worse, forking this template into more templates, like /dual, /flip, /2, /3, ... it's all pointless busy work if we can just switch over to the lua module and be done with it. Frietjes (talk) 14:40, 14 September 2013 (UTC)
The fixes for {convert} are needed to compare the before/after results with Lua, plus those /dual, /flip, /2, /3 are not forks, but rather extended wp:wrapper templates which already exceeded the options of the Lua module, months ago. -Wikid77 21:27, 28 September 2013 (UTC)
Good question. Rather than sniping from the sidelines, I should get on with it and make a concrete proposal. I'll do that in a day or two, and will post a new section here. As to why I haven't yet done that, a project like this is never really finished, so I've always had a reason to wait until another step was complete. It's just in the last few days that I've come to think that whereas the module will never be perfect, it's quite possible that the number of errors it would introduce is smaller than the number of errors in the templates that it would probably fix, and I think it would be more productive if some of the energy currently used for fixing templates were directed towards testing the module. Johnuniq (talk) 12:38, 15 September 2013 (UTC)
There are numerous problems, but perhaps start with "5+6/1000 km" should have the same default precision as "5.006 km". So Lua: {convert/sandboxlua |5+6/1000|km|mi}} → 5+6⁄1000 kilometres (3.111 mi) should have 3-decimal precision. -Wikid77 (talk) 21:27, 28 September 2013 (UTC)

Temperature

I got this 26 to 71 °C (79 to 160 °F)


by doing this {{convert|26|to|71|C}}. Not sure what significance that has? Jamesx12345 16:19, 7 September 2013 (UTC)

{{convert|26|to|71|C|F}} works - 26 to 71 °C (79 to 160 °F) - WOSlinker (talk) 16:43, 7 September 2013 (UTC)
Thanks - I got it working that way, but am surprised it didn't work like 10 kilometres (6.2 mi) ({{convert|10|km}}) where an option is set as default. It's nothing major, but it would be nice if it was a quick and simple fix. Jamesx12345 17:02, 7 September 2013 (UTC)
  • {convert|26|to|71|C | F }}      → 26 to 71 °C (79 to 160 °F)
  • {convert|26|to|71|C|lk=test}} → 26 to 71 °C (79 to 160 °F)*
  • {convert|42|to|51|F | C }}      → 42 to 51 °F (6 to 11 °C)
  • {convert|42|to|51|F|lk=test}} → 42 to 51 °F (6 to 11 °C)*
  • {convert|99|to|999|K | F }}      → 99 to 999 K (−281.5 to 1,338.5 °F)
The fix was very complex, to work with over 2,500 options, so that is why it has taken years to debug the problem and test the corrections. After testing, a protected update will be needed for Template:Convert/Dual/LoffAoffDxSoffT. -Wikid77 (talk)
  • INSTALLED. The fix was applied and {convert} will default the output temperature in ranges now. -Wikid77 14:13, 10 September 2013 (UTC)

The module correctly handles the above examples, and it outputs a Unicode minus for negative (see the hyphen in the last convert above).

  • {{convert/sandboxlua|26|to|71|C|F}} → 26 to 71 °C (79 to 160 °F)
  • {{convert/sandboxlua|26|to|71|C|lk=test}} → 26 to 71 °C (79 to 160 °F)*
  • {{convert/sandboxlua|42|to|51|F|C}} → 42 to 51 °F (6 to 11 °C)
  • {{convert/sandboxlua|42|to|51|F|lk=test}} → 42 to 51 °F (6 to 11 °C)*
  • {{convert/sandboxlua|99|to|999|K|F}} → 99 to 999 K (−281.5 to 1,338.5 °F)

Let's try some unusual options:

  • {{convert|41|to(-)|50|F|K}} → 41 to 50 °F (278–283 K)
  • {{convert|123|F|K|abbr=in}} → 123 °F (324 kelvins)
  • {{convert/sandboxlua|41|to(-)|50|F|K}} → 41 to 50 °F (278–283 K)
  • {{convert/sandboxlua|123|F|K|abbr=in}} → 123 °F (324 kelvins)

Johnuniq (talk) 03:06, 12 September 2013 (UTC)

The option for "abbr=in" was hacked and mangled last year, but it formerly worked well for 3 years. The recent {{convert|123|F|K|abbr=in}} which has been showing the incorrect "123 °F (51 degrees Celsius)" was formerly showing "123 °F (324 kelvins)" correctly for 3 years (see original version id=349187747 of Template:Convert/LoffAinDbSoffT). -Wikid77 16:49, 12 September 2013 (UTC)
A belated thank you for that fix and many others :-) Jamesx12345 09:05, 14 September 2013 (UTC)

acres and square brackets

It currently doesn't seem possible to get a conversion from acres to display using square brackets:

  • {{convert|61|acre|disp=sqbr}} → 61 acres [25 ha]

The reverse does work:

  • {{convert|61|ha|disp=sqbr}} → 61 hectares [150 acres]

It looks from the error that "Template:Convert/LoffAoffDsqbrSoffNa" needs creating. Thanks, Thryduulf (talk) 13:51, 10 September 2013 (UTC)

  • Try using plural "acres" with disp=sqbr: The plural unit-code "acres" allows more options than "acre" but has same calculation: {{convert|61|acres|disp=sqbr}} → 61 acres [25 ha].
    I will submitted a fix for "acre" to also allow disp=sqbr. -Wikid77 (talk) 14:13, 10 September, 17:03, 13 September 2013 (UTC)
It appears the above issue has been fixed, but per my below suggestion that the module should be used for problems like this, here are two examples using the template, and the same two using the module:
  • {{convert|61|acre|disp=sqbr}} → 61 acres [25 ha]
  • {{convert|61|or|71|acre|disp=sqbr}} → 61 or 71 acres [25 or 29 ha]
  • {{convert/sandboxlua|61|acre|disp=sqbr}} → 61 acres [25 ha]
  • {{convert/sandboxlua|61|or|71|acre|disp=sqbr}} → 61 or 71 acres [25 or 29 ha]
Output from the module should be consistent, as illustrated in the fact it works even with unusual inputs. Johnuniq (talk) 02:38, 12 September 2013 (UTC)
The options in Convert have been hacked over the past 2 years, and so that is why there are so many errors now. Formerly, the option "disp=sqbr" was named "disp=br" (which worked everywhere), and when it was renamed, it was not fully changed. -Wikid77 (talk) 16:49, 12 September 2013 (UTC)

Create subpage

Hello, would someone be able to create {{Convert/LoutAonDflipSoffNa}} for me? The situation is {{convert|463|ST|kg|disp=flip|abbr=on|lk=out}} (420,000 kg (463 short tons)). Also, is there a guide to creating these that I've not found, so I wouldnt' have to keep bugging yall in the future (I can't puzzle the code out, to be honest)? — Huntster (t @ c) 02:03, 12 September 2013 (UTC)

Use Convert/flip: There is a new Template:Convert/flip which allows any combination of other options:
· {{convert/flip |463|ST|kg|abbr=on|lk=out}} → User:Wikid77/Template:Convert/flip
· {{convert/flip |463|ST|kg|abbr=on|lk=in}}   → User:Wikid77/Template:Convert/flip
We are trying to reduce the various subtemplates for each option. Hence, we do not want people creating more of those subtemplates, if they can use {convert/flip} instead. These improvements have been delayed about 2 years but are ready now. -Wikid77 15:13, 12 September 2013 (UTC)
Thanks Wikid, I'll check it out. I wonder if there's any way, once things are all sorted out, that the |disp=flip parameter could simply call the new convert/flip template? — Huntster (t @ c) 21:57, 12 September 2013 (UTC)
Someone will fix that in the due course, but meanwhile please consider Module:Convert. Perhaps I should stop mucking around with that (I'm fiddling with stuff arising from making all output text and input parameters translatable for other wikis), and I should propose a stable version that could at least be used for issues like this that are regularly reported.
Here is the module with that example, and a demo of a new feature for user-defined output combinations:
  • {{convert/sandboxlua|463|ST|kg|disp=flip|abbr=on|lk=out}} → 420,000 kg (463 short tons)
  • {{convert/sandboxlua|463|ST|kg+lb+LT|disp=flip|abbr=on|lk=out}} → 420,000 kg; 926,000 lb; 413 long tons (463 short tons)
  • {{convert/sandboxlua|463|ST|kg+lb+LT|abbr=on|lk=out}} → 463 short tons (420,000 kg; 926,000 lb; 413 long tons)
  • {{convert/sandboxlua|463|ST|kg+lb+lt|abbr=on|lk=out}} → 463 short tons (420,000 kg; 926,000 lb; 413 LT)
The output unit can use "+" to join unit codes. Johnuniq (talk) 02:26, 12 September 2013 (UTC)

Hyphen instead of minus sign

The template currently gives out hyphens instead of minus signs for the syntax {{convert|-10|to|-20|C|F}}: −10 to −20 °C (14 to −4 °F). --JorisvS (talk) 14:58, 13 September 2013 (UTC)

  • Thanks for reminder, but use Convert/2: The minus-sign problem requires a major fix, so meanwhile use Template:Convert/2 as {{convert/2 |-10|to|-20|C|F}}: {{convert/2|-10|to|-20|C|F}}. -Wikid77 17:03, 13 September 2013 (UTC)

Weird rounding in ranges

{{convert|102|to|103|F|C}} gives "102 to 103 °F (39 to 39 °C)". That's mathematically correct as a conversion of each separate °F to °C at the given level of precision. But the result looks strange when put together as a range. When I first saw this result, I assumed that one of the temps was mis-converted, or else why would one have a non-zero range for one set of values and not the other? Maybe if the converted range results are equal (to the level of precision to be displayed), it could just say "ca. 39 °C" or something similar. DMacks (talk) 15:55, 13 September 2013 (UTC)

  • Will check 3-digit precision: Thank you for noting the 3-digit temperature shows 2-digit results. That might be an easy fix in Template:Convert/C. However, the range precisions are handled by Template:Convert/Dual/LoffAoffDxSoffT, which I am also testing for fixes with minus signs and the "to(-)" range, as follows:
  • {{convert|102|to|103|F|C|lk=test}} gives: 102 to 103 °F (39 to 39 °C)*
  • {{convert|-44|to|-55|F|C|lk=test}} gives: −44 to −55 °F (−42 to −48 °C)*
  • {{convert|-44|to(-)|-55|F|C|lk=test}} gives: −44 to −55 °F (−42 – −48 °C)*
For years, people have requested other fixes, so I think they are finally almost ready for release. -Wikid77 17:03/20:19, 13 September 2013 (UTC)
It can't come soon enough. I'm only here because I'm trying to force-fix some properly brain-damaged rounding in a particular table (in this case, the "Bed Sizes" one which swings wildly between nearest-1, nearest-5 and nearest-10 centimetres, without seemingly any particular logic or consistency behind it when all we need is for it to be to the nearest whole cm), and I simply can't get the sodding thing to play ball with me. Why is there not a simple tag that can be put in, other than the sig fig one (which in the case of, e.g. something that may be 86cm x 124cm, is a uselessly blunt tool which will end up with you having either "85.7 x 124" or "86 x 120" as the result), when it's such a basic convention that it's found in almost every programming language and spreadsheet ever?
I've tried the "round to nearest power of 10" thing, by the way, and it simply. does not. work. Or at least, I don't think it does. The text describing it on the template page is so convoluted, and the logic behind what you do so bizarre, that it's quite likely I've forgotten a step, like standing on one leg whistling Ave Maria between typing the first and second character or whatever.
EG, it would be very simple and easily understood to have either "roundto=1" or "roundto=e0" for integers, "roundto=e4" for nearest 10,000, "roundto=5" for nearest 5, "roundto=e-2" or "roundto=0.01" for nearest hundredth etc, which would also do away with the need for a separate numbers-after-the-decimal tag.
The current automatic determination of sig fig length is just an idiotic concept, even if it was properly implemented (which it definitely isn't), because it can't tell the difference between converting "about 70cm" to "(about 30 inches)" - which is still a touch inaccurate, but acceptable - and converting "achieved a record speed of 70mph" to "(113km/h)" in a sequence of entries that may cover 67, 69, 72, 76mph... and so bluntly cutting it off to 110km/h (i.e. 68mph) or even 100km/h (1 sig fig! - and the other 2sf ones to 110, 110, 120, 120...) is just no good. 193.63.174.211 (talk) 13:36, 4 October 2013 (UTC)
I think all that was needed was "|0" to round to the nearest whole number. I fixed the templates which also needed "|disp=br" (diff). Johnuniq (talk) 00:01, 5 October 2013 (UTC)

acre in convert is broken and displays abbreviation as {{{u}}} in certain cases

Status: Fixed "to(-)", for others use Template:Convert/2. -Wikid77 12:10, 14 September 2013 (UTC)

I have no idea how to fix this problem. For an example, 0.4 to 0.6 square kilometres (99–148 acres) but also on the template page e.g.

Abridged list of units supported by {{Convert}}
{convert/list of units/area/short list}

Fromthehill (talk) 09:40, 14 September 2013 (UTC)

I have fixed the format so page "Template:convert/list of units/area/short list" will default the symbol "{{{u}}}" as "(none)" such as for acre. -Wikid77 14:11, 14 September 2013 (UTC)
The convert used before the table is shown below, with the result from Module:Convert for comparison:
  • {{convert|0.4|to(-)|0.6|km2|acre}} → 0.4 to 0.6 square kilometres (99–148 acres)
  • {{convert/sandboxlua|0.4|to(-)|0.6|km2|acre}} → 0.4 to 0.6 square kilometres (99–148 acres)
The table is {{convert/list of units/area/short list}} and like the above convert, it currently displays "{{{u}}}" where it should show "acres".
The cause may be in the first note at User:Johnuniq/Convert notes#Issues.
For anyone wondering why the module uses "to" in the output range, the story is that "to(-)" gives "to" when unit names are used, and "–" when unit symbols are used. However, "acre" is defined so that it always uses a name, not a symbol, so it always uses "to". I guess that's a defect, but it's consistent! Some examples using units that have a name and a symbol follow:
  • {{convert|0.4|to(-)|0.6|km|yd}} → 0.4 to 0.6 kilometres (440–660 yd)
  • {{convert|0.4|to(-)|0.6|km|yd|abbr=on}} → 0.4 to 0.6 km (440–660 yd)
  • {{convert|0.4|to(-)|0.6|km|yd|abbr=off}} → 0.4 to 0.6 kilometres (440–660 yards)
Johnuniq (talk) 10:49, 14 September 2013 (UTC)
  • Use Convert/2 until fixed: The unit-code "acre" is currently being reworked to reduce 800-900 subtemplates, so there are some cases where "{{{u}}}" is displayed. Until fixed, use Template:Convert/2 as follows:
  • {convert/2 |0.4|to(-)|0.6|km2|acre}} → {{convert/2|0.4|to(-)|0.6|km2|acre}}
  • {convert/2 |7|to(-)|9|km2|acre|abbr=on}} → {{convert/2|7|to(-)|9|km2|acre|abbr=on}}
For years, {convert} has had too many peculiar options which has led to an intricate web of complex interactions, among over 74,000 possible options. -Wikid77 12:10, 14 September 2013 (UTC)

Thanks people that's great it's fixed where I noticed the bug at https://en.wikipedia.org/wiki/Pygmy_hippopotamus#Behavior . Whatever was changed has cleared the bug so I didn't have to use convert/2. Fromthehill (talk) 20:43, 14 September 2013 (UTC)

Problem converting hectares to acres?

I'm using {{convert|10|–|15|ha|acre}}, which outputs: 10–15 hectares (25–37 {{{u}}}). As far as I can tell, the syntax is correct—isn't it? Curly Turkey (gobble) 05:25, 16 September 2013 (UTC)

  • Fix submitted for "-" and "to" but use "to(-)": There has been a backlog which is delaying the release of the fixes for the range dash "-" with acres. Meanwhile use the range word "to(-)" or else {convert/2} as follows:
  • {convert|10|to(-)|15|ha|acre}} → 10 to 15 hectares (25–37 acres)
  • {convert/2 |10|–|15|ha|acre}}   → {{convert/2|10|–|15|ha|acre}}
  • {convert|10|–|15|ha|acre}}       → 10–15 hectares (25–37 acres)
Sorry for the 3-day delay. We might need to contact someone else in a few more hours. -Wikid77 06:00, 16 September 2013 (UTC)
Three-day delay? You replied in 35 minutes! ;) Curly Turkey (gobble) 06:38, 17 September 2013 (UTC)

Using the convert module

It is time to consider whether Module:Convert should be used to replace the convert templates. Please see my proposal. It is not necessary to decide whether the benefits from switching to the module would be outweighed by consequent problems because it would be easy to use the module for a week, and switch back if too many problems are encountered.

The main benefits of the module are consistency and flexibility. Consistency occurs because each unit is defined once only, and each rule (such as whether a unit name should be singular or plural) is in one place. Flexibility occurs because the module is not bound by template wikitext, as shown in these exaggerated examples:

  • {{convert/sandboxlua|1|mi|4|ch|3|yd|2|ft|9|in|m|lk=on}} → 1 mile 4 chains 3 yards 2 feet 9 inches (1,693.39 m)
  • {{convert/sandboxlua|123|m|fathom+ft+furlong+perch+royal cubit|abbr=on|lk=on}} → 123 m (67 fathoms; 404 ft; 0.61 furlongs; 24.5 perches; 235 cu)
  • {{convert/sandboxlua|2+3/8|xx|3+3/16|xx|1/2|in|mm}} → 2+3⁄8 × 3+3⁄16 × 1⁄2 inch (60 × 81 × 13 mm)

The module also has performance advantages as it is not restricted by template limits and is capable of performing thousands of converts on a single page, as shown in this demo. Johnuniq (talk) 01:47, 17 September 2013 (UTC)

Also discuss below: #Adjustments for Lua Convert. -Wikid77 12:08, 19 September 2013 (UTC)
  • Bad timing this month: The users are not ready to have Convert derailed in thousands of pages, after the suffering for wp:VE in July/August, then on 26 August, the wp:CS1 Lua module began showing thousands of red cite messages, in over 60,000 pages. -Wikid77 (talk) 06:27, 17 September 2013 (UTC)
  • Support Will probably be early next month anyway rather than this month when it is deployed. There will be more pages showing errors but that's actually a good thing as it's better to show an error rather than displaying a bad conversion with incorrect figures, e.g. 10 kilograms ([convert: unit mismatch]) -- WOSlinker (talk) 11:53, 17 September 2013 (UTC)
  • support, agree that it's better to show an error message than an incorrect conversion. Frietjes (talk) 16:29, 17 September 2013 (UTC)
  • Support. We did the citation/CS1 conversion, with millions of pages, from the end of March (right when VE was introduced). It had some 15 (!) code changes in April, and only three since [1]. The only nogo should be when the programmers here do not oversee these consequences (do not know what about). -DePiep (talk) 13:18, 19 September 2013 (UTC)
Put on hold please. It has occurred to me that the options like for abbr= and lk= are not tested extensively. Testcases need to be build for these. -DePiep (talk) 23:59, 20 September 2013 (UTC)
It looks worse. I tried to document and test recently. I have not found a single piece of documentation that I can use for testing. No description of named param options, unnnamed params, testswitches, list of units. I had to trawl code for hints and guesses. The message, help and track system is only rudimentary present. I also get the impression that the module code is chaotic -- which may explain why documentation is hard to find or create. Anyway, I strongly suggest that these topics are fleshed out well before going live. This is not yet CS1 grade. Good points are, I should add, that many individual entries are tested well, and the core calculations look very fine. -DePiep (talk) 22:19, 21 September 2013 (UTC)
  • Support, I haven't seen any issues that would be a "show stopper". We can clearly phase in the error messages, by starting with tracking links (or categories), and then slowly turning them on once we have an idea of the scope. I recall there was a problem with tracking categories, so tracking links would probably be the way to go. Thanks! Plastikspork ―Œ(talk) 21:26, 21 September 2013 (UTC)
Neither have I, Plastikpork. But that is because there is no documentation, no core tests, no description, no helppage. The error cats are rudimentary, and currently every error will splash orange alarm messages inline. Phasing in error cats is not "clearly" to be done (not by switch, so will require extra code). This is not fit for live. btw, johnuniq did find roadblocks. -DePiep (talk) 21:48, 21 September 2013 (UTC)
The documentation should be the same as it is now. As far as documentation for how the code works, that seems to be lacking for both versions. As far as core tests go, we do have Template:Convert/testcases, which is basically a set of consistency checks between the old and the new versions. Plastikspork ―Œ(talk) 23:56, 21 September 2013 (UTC)
As you write: should be. And really, some structural stuff is even better. But saying "but the old documentation was bad too" is no argument at all (is that really you talking Pspork, or has your account being hacked?). The testcase pages have many tests, and also many many messages -- undocumented misfit reds actually (what does a non-green "links" message mean? Why trust it is OK?). I am saying it straight and though: not good today. There are not enough tests. A minute ago I posted my analysis of the test options (test parameters) in module:convert. There are six. Six. Six test parameters that can be set, and they are as intertwined as octopusses in love (hexapusses then, but we get the image). What actually were we testing? Module_talk:Convert#Test_options. -DePiep (talk) 00:45, 22 September 2013 (UTC)
The non-green "links" message means that one of the links of the units if different between the two versions being tested. A lot of the current tests only check to see that all the different units are in the lua version and that the links are also sensible. What there is less of are tests for all the different parameter options. There are some but there could probably be some more extensive combinations tested. One problem you'll find with testing the combination though is that the current live convert doesn't do that well with a lot of the combinations anyway. I'll have a look at creating a set of these tests within the next 24 hours. -- WOSlinker (talk) 01:01, 22 September 2013 (UTC)
What will you test? Get rid of these crappy test code things first, then define beforehand what your test should test. There may be more code in for improvement. The non-green remark I have put into the documentation where it belongs (I am scraping the doc together!). Your other remarks I have responded to earlier. A 24h deadline I do not advise or applaud. -DePiep (talk) 01:47, 22 September 2013 (UTC)
It was just a personal deadline, which I've managed to comply with. I've created some further testcases for evaluation and have added a little more documentation at Module:ConvertTestcase on the different colour codes. -- WOSlinker (talk) 09:33, 22 September 2013 (UTC)
Type Notes
rounding There are some issues here to investigate
parametercombinations1 - No disp param
parametercombinations2 - disp=or Some differences
parametercombinations3 - disp=x|BEGIN|END
parametercombinations4 - disp=output only Some differences
parametercombinations5 - disp=output number only
parametercombinations6 - disp=flip Some differences
parametercombinations7 - disp=unit Some differences
parametercombinations8 - disp=br Some differences
parametercombinations9 - disp=sqbr
An impressive leap, WOSlinker! Hats off. -DePiep (talk) 10:37, 22 September 2013 (UTC)

Adjustments for Lua Convert

After seeing numerous complaints about non-compatible changes to templates, I think we should ensure a high level of quality in the Lua-based convert. Some issues:

  • Precision of fractions should match decimal digits: The following examples show how "5+4/1000" should have 3-digit precision, but "5+9/100" should have 2-decimal precision. Note below:
  • {{convert|5.004|ft|m}}         → 5.004 feet (1.525 m)
  • {{convert|5+4/1000|ft|m}} → 5+4⁄1000 feet (1.525 m)
  • {{convert|5+9/100|ft|m}}   → 5+9⁄100 feet (1.55 m)
  • {{convert/sandboxlua |5+4/1000|ft|m}} → 5+4⁄1000 feet (1.525 m)
  • {{convert/sandboxlua |5+9/100|ft|m}}   → 5+9⁄100 feet (1.55 m)

Use of fractions is relatively rare, so only a few conversions use them, but the precision of 4/1000 should be 3 decimal digits. -Wikid77 (talk) 12:08, 19 September 2013 (UTC)

How about non-decimal fractions and precision? In lengths, imperial unit fractions like 1⁄16 inch are common notation.
Actually, this is in play in {{RailGauge}}, where defined rail gauges are presented in both metric and imperial. So far the mm-to-1⁄32 is resolved based on the coincidence that they are same order of magnitude (whole mm's can be expressed in 1⁄32 inches always and v.v.; we did not dive into the 1⁄64 order). At the moment {{convert}} is not used, both lengths are hardcoded.
AFAIK, this is a feature request (if at all), so it can wait till after the Lua switchover of {{convert}}. -DePiep (talk) 13:01, 19 September 2013 (UTC)
Nevertheless I had noticed some rounding issues with fractions in my tests, and I have just updated the module to handle the precision of fractions (I think the module used to match the templates, but something changed in the templates, possibly the use of Module:Math). Johnuniq (talk) 10:32, 30 September 2013 (UTC)

Edit request on 20 September 2013

Before I fixed it, there was a mistake in Sutlej Yamuna link canal using:

{{convert|3500000|acre|km3}} → 3,500,000 acres ([convert: unit mismatch])

(wrong because acres are units of area and km3 are units of volume). It would be nice if the template threw an error instead of just converting it (to a meaningless result). —[AlanM1(talk)]— 14:47, 20 September 2013 (UTC)

see {{convert/sandboxlua|3500000|acre|km3}} → 3,500,000 acres ([convert: unit mismatch])
this will be fixed when we switch over to the LUA module, until then, I believe it would be a waste of effort to try to fix all possible variants of this problem in the non-LUA version. Frietjes (talk) 15:25, 20 September 2013 (UTC)
  • Perhaps link maintenance category and show superscript note: We could put such cases into a warning maintenance category, in a split second, with no further template expansion depth, and perhaps set the conversion to append "[fix unit]" after the incorrect amount. Otherwise, I fear more complaints about new "red-error messages" which had upset readers of the wp:CS1 cite messages in 60,000 pages. I will work to show a prototype; give me about 3 hours (busy now) ...Okay, here's the prototype, where the result will auto-correct "km3" to use "km2" but put reminder to "fix unit" as follows:
Thereby, the conversion is valid, as acres-to-km2; the related text is sensible, and if the user does not have time to fix the conversion unit, then the "km2" provides a valid conversion for thousands of readers who view the page, without scarring the text with a large error message which "35,000" readers will never fix (they mostly think, "wow, another bad error in Wikipedia's sloppy text"). Instead, by auto-correcting invalid units, then conversions can be quietly adjusted and the overall quality of the text is elevated to an upper level of competence. The overhead is perhaps 1/200th second to check for invalid unit-code, at the same expansion depth. -Wikid77 (talk) 23:49/01:05, 21 September 2013 (UTC)
    • better an error than a completely nonsensical conversion. Frietjes (talk) 00:04, 21 September 2013 (UTC)
      • Yes, but now there is a 3rd alternative:  auto-correction of invalid units, with a curious reminder "[fix unit]" to whomever has time to adjust the unit-code. Now, we have entered the era of "live typesetting" where text, displayed to thousands of readers, is almost always correct, even when invalid codes are present. -Wikid77 (talk) 01:05, 21 September 2013 (UTC)
I prefer the Wikid77 proposal.
First of all, the new warning ("Conversion warning: Ignored invalid option "adj=junk"") is not an error. It does not need coloring and can be a simple [maint link] and the maintenance category. The maint link can even be omitted too. The maintenance category is there for editors who want to clean up.
Then, the errors Frietjes mentions are there already, possibly for months or years. There is no reason to require instant correction. Adding the alarming color+inline text spoils the page, while 99 out of 100 visitors do not know what to do about it. Let's just add the superscript link mentioned (there are three error categories defined, so one of three links can occur). Once this lua is live, interested editors (like you and me) can clean up working from these categories. We all know we will look for these pages. These errors can stay there for some more weeks. The superscript text cold be explicit in mentioning some 'error' or caveat. -DePiep (talk) 11:39, 21 September 2013 (UTC)
Adding: how about this. The warnings should add the maintenance category only, no superscript link. The note of an "unknown option" is legitimite maintenance fact (check what was meant & do cleanup). If we do this, we can remove the complicating |warnings=on option. Another one variant less to be tested. -DePiep (talk) 11:48, 21 September 2013 (UTC)
Please see Module_talk:Convert#Maintenance_category_names for a proposed superscript text, its help page link, and the maintenance category. -DePiep (talk) 13:27, 21 September 2013 (UTC)
I don't have a dog in this race. Because the purpose of any warning or error messages (regardless of how they are annotated) is to help editors correctly use {{convert}}, I would recommend that the same help text that exists in Help:Convert should be duplicated on the various category pages. An example of how this might be done is at Help:CS1 errors and in the CS1 tracking category pages. This mechanism transcludes the help text from Help:CS1 errors into the individual category pages so that help text changes are made in only one place making maintenance of the help text much easier. I think that the help text on the category pages benefits editors who are cleaning up the categories.
—Trappist the monk (talk) 14:02, 21 September 2013 (UTC)
Yep. But at the moment we have dozens of error situations (User:Johnuniq/Convert messages), leading to just four categories. -DePiep (talk) 15:08, 21 September 2013 (UTC)
@Wikid77: As far as auto-correction, I'm not sure there's a reasonable solution. In the subject case, for example, the correct correction was to change acre to acre.ft, not km3 to km2. While the "from" unit might be somewhat more likely to be correct, I don't think it's often enough to justify possibly compounding the error. —[AlanM1(talk)]— 18:09, 27 September 2013 (UTC)
  • Output unit more often wrong: Over the years, we have found that the output unit is much more likely to be in error (but still rare), and an auto-corrected conversion at least shows partial information with "3,500,000 acres", rather than a hollow error message "3,500,000 acres ([convert: unit mismatch])" to instead show "3,500,000 acres ([convert: unit mismatch])". The deciding factor is the presence of conversions in talk-pages and archives, where a retro-displayed fatal error message is an alarming sight in a page which is expected to remain in a "sealed" archive, so therefore the auto-correction with reminder "[fix unit]" is the overall best solution, to keep both live pages and archives readable, even if the autocorrection sometimes leaves partial information. As you noted, the "from" unit is typically valid, and so auto-correction might exceed 90% proper results. -Wikid77 (talk) 18:38, 27 September 2013 (UTC)

Edit request on 20 September 2013

Request new unit of volume acre-ft (acre-foot/acre-feet), equal to 1233.48183754752 m3 (exactly).

Example:

{{convert|3500000|acre-ft|km3}} → 3,500,000 acre-feet (4.3 km3)

—[AlanM1(talk)]— 14:59, 20 September 2013 (UTC)

@AlanM1: use {{convert|3500000|acre.ft|km3}} Frietjes (talk) 15:27, 20 September 2013 (UTC)
or {{convert|3.5|e6acre.ft|km3}} Frietjes (talk) 15:29, 20 September 2013 (UTC)
  • @Frietjes: Cool. I also see now that it is documented – I just had to remember to click on the Full list link to see it . Might it not belong in the short list as well, given that it's apparently common in water engineering?
  • The code is documented as "acre ft", but "acre.ft" works as well. I did try "acre-ft" before posting, based on seeing "ft-lb", so it might be worth allowing "acre-ft" as a synonym.
  • The resulting un-abbreviated units (acre foot, acre feet) are (I believe incorrectly) not hyphenated, which is inconsistent with the article acre-foot and other "product" units.
—[AlanM1(talk)]— 19:14, 20 September 2013 (UTC)
I added a redirect. I have no real opinion concerning the proper abbreviation, but changing it would be trivial if it is indeed incorrect. if you use 3,500,000 acre⋅ft (4.3 km3), you get a dot separator. Frietjes (talk) 20:07, 20 September 2013 (UTC)
Thanks. WP:MOSNUM#Unit names (bullet 2) says that either a hyphen or space are correct for multiplied unit names, but linking the units together visually leaves less room for ambiguity in prose, it's correct per scientific norms to do so, and our relevant article (acre-foot) is hyphenated (as are those for other similar units, e.g. foot-pound).
WP:MOSNUM#Unit symbols (bullet 6) says to use a &middot; or &nbsp; for the abbreviated units, but again, it's a scientific norm, and it seems the dot leaves less room for ambiguity in prose. —[AlanM1(talk)]— 18:40, 27 September 2013 (UTC)

Converting long tons to kg

One long ton is approximately 1,016 kg. So 1000 LT should be 1,016,000 kg. However, the convert template returns the following: 1,000 long tons (1,000,000 kg). This is probably insignificant for small tonnages, but larger ones show a definite discrepancy. Can the template be fixed please? Thanks, Bazonka (talk) 08:23, 22 September 2013 (UTC)

The template tries to choose the rounding according to the number of zeroes in the input. In your case it choose 6 (an extra 3 to allow for 1000 kg=1 metric ton). Add |sigfig=7 to see precision to 7 digits (or choose less, according to your desire) <code>{{convert|1000|LT|kg|sigfig=7}}</code> → 1,000 long tons (1,016,047 kg)  Stepho  talk  08:50, 22 September 2013 (UTC)
  • Numbers with zeroes above 100 treated as rounded: Currently, the Convert template has been set to auto-round, to trim the result amount, as if the input amount was a rounded "1,000 approximately". To get more-precise results, use option "sigfig=4" to see 4 significant digits. For example:
  • {convert|1000|LT|kg|sigfig=4}} → 1,000 long tons (1,016,000 kg)
Each unit has its own level of rounding, depending on the cultural number sense for the unit. In general, when people say "500" it is often an approximate amount (as "nearly 500"); however, Convert perhaps could/should be changed to treat 1,000 long tons as one more than 999, rather than roughly between 900-1,099. Previously, people have recommended to consider one trailing zero as being precise:
  • {convert|1000|LT|kg|sigfig=1}} → 1,000 long tons (1,000,000 kg)
  • {convert|1000|LT|kg|sigfig=3}} → 1,000 long tons (1,020,000 kg)
  • {convert|1000|LT|kg|sigfig=4}} → 1,000 long tons (1,016,000 kg)
Again, each unit has its own rules for the default precision, and we need to review how often "1,000" is considered a rough amount for tonnage. In general, whole hundreds, above 100, such as "200" or "400" are typically approximate amounts in numerous Wikipedia articles. -Wikid77 (talk) 09:52, 22 September 2013 (UTC)
I really can't understand the reasoning behind -automatically- truncating the accuracy of converted figures when the converter has only very limited context with which to work from, and most situations where you want to use the converter involve calculations other than strict powers of 10 (ie between two metric units, quite rare) which is the only case where you can sort of guarantee that this won't accidentally lose significant precision - especially as neither the audience nor the person using the converter in the first place may have no idea of the actual conversion factor, and therefore whether the output is actually precise, or excessively rounded. Surely the convention, as followed in other situations like calculators, spreadsheets etc, should be to give it to a particular precision as befits the size of the input figure (and, for small figures, the number of decimals after the point), up to, say, 8, 9 ... maybe 12sf (as per a typical calculator) and if the user wants to truncate it (or, rarely, extend it) from there, they have to do so explicitly? If you're writing out an approximate figure in school or scientific work you have to put the sig figs after it in brackets, after all, lest your audience assumes it's exact. Leave the burden of decision on the intelligent agent who's gone to the trouble of making the edit in the first place, with a responsibility to follow the MoS there just the same as for the rest of the encyclopaedia (and mods rolling around the pages making corrective tweaks where they haven't - as for everything else), not on some relatively simple and often quite dumb piece of code which has to guess at the author's intent a lot of the time, and typically ends up getting it glaringly wrong in corner cases... and is dreadfully difficult to "force" into giving figures to a sensible precision. I've had to give up entirely and manually write in the conversions on several occasions before, because it wasn't worth the aggro of trying to bludgeon the converter into doing things in the correct manner; any new version seriously has to fix that problem. 193.63.174.211 (talk) 14:26, 4 October 2013 (UTC)
(Obviously a small amount of logic should remain in there, as converting "2 miles" to "3.2186km" is generally a bit silly, just as bad as writing it "3km" when those last 219 metres could be quite important... even though it hasn't been definitely specified as "2.00 miles" in order to get "3.22km"; maybe some consideration of the complexity of the conversion, and the typically accepted accuracy of a particular conversion also needs to be included? EG you may expect miles->km to be accurate down to about 0.1 of either unit (as that's what a typical odometer reads in), but miles/yards->metres, or metres/km->yards would, even with a single sig fig and a bunch of trailing zeroes, be expected to be accurate to at least 10m/10yd, if not 1m/1yd - so "2 miles" would be written as "3220" or even "3219m" by default (but maybe not 3218.6m unless that was deliberately specified). I realise I am myself probably oversimplifying the difficulties in this complex issue, but if I see one more case where both "70 inches" and "71 inches" have been rounded to "180cm", but "72 inches" comes out as "183cm"... augggh! And, certainly, it seems ludicrous to ever assume less than 2sf input accuracy - along with, in that particular case, the supposedly already-in-place convention of extending the output accuracy by 1sf for figures which are between 1 and 2 MSF range, so the output will be assured of coming out as 3sf - as hardly anything is ever measured in such a rough manner.)193.63.174.211 (talk) 14:36, 4 October 2013 (UTC)

Edit request on 24 September 2013 -- hyphenation of adjectival forms

The adjectival form (using the "|adj=on" parameter) properly hyphenates the main word, but neglects to hyphenate the parenthesized adjectival conversion.

Example usage from the IKAROS article:

  • {{convert|0.5|kg|lb|adj=on}} tip masses → 0.5-kilogram (1.1 lb) tip masses

Because the parenthesized value is also an adjective, the proper template result should be as follows::

  • {{convert|0.5|kg|lb|adj=on}} tip masses → 0.5-kilogram (1.1-lb) tip masses

I request that the template be updated to properly hyphenate the parenthesized values when "|adj=on".

OhioFred (talk) 19:39, 24 September 2013 (UTC)

  • Omitting hyphen with abbreviations is a quirk of English punctuation: Many people have noted the same frustration, to request hyphenated "1.1-lb" (or "35-mm"), but we have studied the issue extensively, and omitting the hyphen "-" is the preferred style for English grammar and punctuation (although illogical). However, feel free to hand-code the "-" in cases where it might seem easier to read, and there are some people who hyphenate unit symbols, such as "5-km fun run" but rarely. -Wikid77 (talk) 20:15, 24 September 2013 (UTC)
How does this apply to the projected lua module? -DePiep (talk) 21:56, 24 September 2013 (UTC)
The module tries to emulate what most of the templates do, and therefore does not hyphenate when using symbols. However, some units like acre have a rule that "acre" is a name and not a symbol. Examples:
  • {{convert/sandboxlua|0.5|kg|lb|adj=on}} → 0.5-kilogram (1.1 lb)
  • {{convert/sandboxlua|0.5|kg|lb|adj=on|abbr=on}} → 0.5 kg (1.1 lb)
  • {{convert/sandboxlua|0.5|kg|lb|adj=on|abbr=in}} → 0.5 kg (1.1-pound)
  • {{convert/sandboxlua|0.5|kg|lb|adj=on|abbr=off}} → 0.5-kilogram (1.1-pound)
  • {{convert/sandboxlua|12|ha|acre|adj=on}} → 12-hectare (30-acre)
  • {{convert/sandboxlua|12|ha|acre|adj=on|abbr=on}} → 12 ha (30-acre)
  • {{convert/sandboxlua|12|ha|acre|adj=on|abbr=in}} → 12 ha (30-acre)
  • {{convert/sandboxlua|12|ha|acre|adj=on|abbr=off}} → 12-hectare (30-acre)
Johnuniq (talk) 02:08, 25 September 2013 (UTC)

Multiple spaces

I've noticed a MediaWiki trick: the link Template:Convert/ft m goes to a certain page, and so does Template:Convert/ft __ _ m (with 4 spaces and 3 underscores). This trick means each of the following work (the second has two spaces, and the third has three, although html only displays one space here)):

  • {{convert|3|mi|ft m}} → 3 miles (16,000 ft; 4,800 m)
  • {{convert|3|mi|ft m}} → 3 miles (16,000 ft; 4,800 m)
  • {{convert|3|mi|ft m}} → 3 miles (16,000 ft; 4,800 m)

Should the module emulate this phenomenon, or should a combination unit with multiples spaces be rejected as unknown, requiring a wikignome to fix? It's easy enough to put this in the module, but I'm inclined towards thinking that accepting broken inputs leads to confusion (what if someone notices the two spaces while looking for an example to use in another article, then wonders how many spaces they should use?). (I noticed this at Ford C-Max which has six converts with unit kW  PS with two spaces.) Johnuniq (talk) 04:54, 25 September 2013 (UTC)

Ugh, as well as multiple spaces and underscores, you can have one or more of "&nbsp;". I just noticed "L/100&nbsp;km" at Toyota Auris#Environment. Should the module accept those as well? Johnuniq (talk) 05:24, 25 September 2013 (UTC)

  • Condense multiple spaces and allow commas in 2nd amount: In general, allow people to put spaces around/between parameters. Also, continue to allow commas in the 2nd number of the range, which has become a problem in {convert/old}:
  • {convert/old |2,300|-|3,400|ft|m}} → 2,300–3,400 feet (700Expression error: Unexpected < operatorExpression error: Unrecognized punctuation character ",". m)
  • {convert/sandboxlua |2,300|-|3,400|ft|m}} → 2,300–3,400 feet (700–1,040 m)
I think some people like to put double-blank spacing between symbols, so just treat those cases as one blank. I would not accept underscore "ft_m" (because I think that would get confused with "ftin"), and I think the gnomes should edit pages and replace any "|ft_m" with "|ft m" if an error arises. I am not sure about allowing "&nbsp;" yet.  ...okay, yes allow &nbsp because we have severe editors who global-edit all " km" to become "&nbsp;km" and then people would complain how the "Lua Convert" is broken. I suspect Lua's "text=text:gsub('&nbsp;',' ')" is very fast, so do not lament using it where applicable. -Wikid77 (talk) 05:51/06:04, 25 September 2013 (UTC)
I think it would be easy enough to get a bot to run through and remove any underscores and nonbreaking spaces found. — Huntster (t @ c) 06:01, 25 September 2013 (UTC)
Yes, that's true, but I think Wikid77 has made a strong point, namely that wikignomes are likely to "fix" things, and it's pretty simple for the module to accept the variations. I have adjusted the module to accept the variety, although I haven't yet uploaded it. Johnuniq (talk) 09:52, 25 September 2013 (UTC)

Two subpage edits

I've retargeted Template:Convert/LoffAoffDoutput number onlySoffUSre and Template:Convert/LoffAoffDoutput number onlySoffNa, because they were double redirects. If you find a problem, please revert (or ask an admin to revert, if you're not one) my edits immediately, without taking the time to let me know. Nyttend (talk) 01:22, 27 September 2013 (UTC)

Calorie confusion

MOSNUM states that the symbol cal refers to a gram calorie, whereas Cal refers to a kilogram calorie.

Following is a comparison between the current template and the module. 

[Following gives errors 7 March 2019]
{{#invoke:ConvertTestcase|ConvertTestcaseHeader}}
{{#invoke:ConvertTestcase|ConvertTestcase|type=energy|fromonly=yes|unit=Cal}}
{{#invoke:ConvertTestcase|ConvertTestcase|type=energy|fromonly=yes|unit=cal}}
{{#invoke:ConvertTestcase|ConvertTestcase|type=power|unit=Cal/d}}
{{#invoke:ConvertTestcase|ConvertTestcase|type=power|unit=cal/h}}
{{#invoke:ConvertTestcase|ConvertTestcase|type=power|unit=Cal/h}}
{{#invoke:ConvertTestcase|ConvertTestcase|type=power|unit=kcal/h}}
{{#invoke:ConvertTestcase|ConvertTestcaseFooter}}

What is correct? I'm not concerned about the "Link" differences (indicating that the results are the same except for the links), but the values are a problem, and I'm unsure about the "calorie" vs. "large calorie" name difference. Johnuniq (talk) 03:59, 27 September 2013 (UTC)

Was it working fine until a few hours ago? I made some code changes; see the previous section. Nyttend (talk) 05:06, 27 September 2013 (UTC)
No, it's been the same for ages. I'm just going through my todo list. Johnuniq (talk) 06:01, 27 September 2013 (UTC)
  • Lua version seems correct, fixing markup version: There is a mix-up in conversion factors in Template:Convert/kcal/h, as the expected result would be: 1 kilocalorie per hour = 0.00116222222 kilowatts. I have a corrected version in the sandbox, ready to be installed:
{convert|1|kcal/h/sandbox|kW}}              → 1 kcal/h/sandbox[convert: unknown unit]
{convert|1.0000000|kcal/h/sandbox|kW}} → 1.0000000 kcal/h/sandbox[convert: unknown unit]
I will check {convert/cal/h} also. -Wikid77 (talk) 18:52/22:21, 27 September 2013 (UTC)
Thanks! Johnuniq (talk) 02:04, 28 September 2013 (UTC)

Using in other languages

Hi. Where is the lsit of words to translate, please. The template produces the english word 'miles', as seen here. It needs to be changed to 'milltir'. Many thanks. Llywelyn2000 (talk) 05:29, 28 September 2013 (UTC)

It is possible to edit the templates to change how names appear, but it's tricky. One good procedure would be to copy the convert template with the example you want to work on ({{convert|10|mi|0}} in this case), then paste that into a sandbox somewhere (just a section in a talk page will do). When you preview how the template appears, you can see which templates are involved in a list at the bottom of the page. Re the problem of getting convert to work properly on another wiki, the best thing would be to wait until some work going on here finishes in a couple of weeks, then look at using the module that is being developed. See this page at Bengali Wikipedia for an example of a wiki using the module. Johnuniq (talk) 06:22, 28 September 2013 (UTC)
Many thanks for such a quick reply. Llywelyn2000 (talk) 06:42, 28 September 2013 (UTC)
  • FIXED in Welsh Wikipedia: I checked the dictionary spelling for plural "milltiroedd" and updated cy:Nodyn:Convert/mi to use the proper translation for "mile/miles". If any other questions, just ask again. -Wikid77 (talk) 20:36, 28 September 2013 (UTC)
Brilliant stuff! Many thanks.... and diolch! Llywelyn2000 (talk) 22:28, 28 September 2013 (UTC)

Side-by-side tests of Convert/dual with Lua module

To help verify operation of the Lua module, it was been suggested to focus more on testing the Lua options, along with the original {convert}. For "sp=us" with a dual output, multi-2 result:

  • {convert|9,900|m|mi km|sp=us}}         → 9,900 meters (6.2 mi; 9.9 km)
  • {convert/dual |9,900|m|mi|km|sp=us}} → {{convert/dual |9,900|m|mi|km|sp=us}}
  • {convert/sandboxlua |9,900|m|mi km|sp=us}} → 9,900 meters (6.2 mi; 9.9 km)
  • {convert/dual |9+3/100|m|in|cm|lk=out|sep=,}} → {{convert/dual |9+3/100 |m|in|cm|lk=out|sep=,}}
  • {convert/sandboxlua |9+3/100|m|in cm|lk=out}} → 9+3⁄100 metres (356 in; 903 cm)
  • {convert/sandboxlua |9+3/100|m|in cm|lk=out|sep=,}} → 9+3⁄100 metres (356 in; 903 cm)*

The new option "sep=," to separate the output amounts by comma, was not part of the Lua design. Anyway, by including the Lua results, along with other results, then there will be more times when the Lua operation can be confirmed, in preparation to be used in the scary transition to 560,000(!) pages. -Wikid77 22:03, 28 September 2013 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_September_2013&oldid=1113941303"