Template talk:Convert/Archive February 2015

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

Mach

Mach discussion 1

Mach number is a dimensionless quantity representing the ratio of speed of an object moving through a fluid and the local speed of sound. This template will convert Mach to speed:

  • {{convert|8|Mach|km/h mph km/s}} → Mach 8 (9,800 km/h; 6,100 mph; 2.7 km/s)

This is an incorrect conversion, as it presumes a constant velocity at all altitudes. Any missile that follows a ballistic trajectory will obviously travel at varying altitudes with an ever-changing real velocity.

I suggest that the altitude parameter be made required for this conversion. --  Gadget850 talk 12:47, 2 February 2015 (UTC)

Altitude? Mach number says , so I'd expect the need for a second velocity. (then, {convert} so far does not handle double-value inputs). -DePiep (talk) 14:34, 2 February 2015 (UTC)
... or something like: Mach 8 (9,800 km/h) @ v? = 1000 km/h. -DePiep (talk) 14:36, 2 February 2015 (UTC)
Mach is a built-in unit so it can do some magic things. However, it only emulates the old template (while fixing some bugs that it had) and an altitude can be entered when Mach is used an an input, but not when it is used as an output. There are 41 converts using Mach in articles—16 with an altitude and 25 without. I only studied the topic enough to write the code and if an active discussion at a wikiproject says that an altitude must be included it would probably be easy enough to require. However, having the altitude default to 0 (sea level) seems reasonable. What is the problem? Surely there is no altitude that would work for a ballistic trajectory, except if one were to say that at altitude X the speed was (convert with altitude=X).
Here are some examples of current behavior:
  • {{convert|3.5|Mach}} → Mach 3.5 (4,290 km/h; 2,660 mph)
  • {{convert|3.5|Mach|90,000|lk=in}} → Mach 3.5 (3,780 km/h; 2,350 mph)
  • {{convert|3.5|Mach|90,000|mph}} → Mach 3.5 (2,350 mph)
  • {{convert|3.5|Mach|90,000|-2}} → Mach 3.5 (3,800 km/h; 2,300 mph)
  • {{convert|3.5|Mach|90,000|mph|-2}} → Mach 3.5 (2,300 mph)
  • {{convert|3.5|Mach||-2}} → Mach 3.5 (4,300 km/h; 2,700 mph)
  • {{convert|3.5|Mach|mph|-2}} → Mach 3.5 (2,700 mph)
If work were done on Mach, it might be best to remove the ability to enter it in free-form as above (which is quite bizarre), and require syntax altitude=NUMBER. That would easily handle Mach as an output. Johnuniq (talk) 00:03, 3 February 2015 (UTC)
Mach numbers cannot be reliably converted to speeds; the speed of sound depends on temperature, and hardly at all on altitude (in and of itself). And obviously air temperature varies.
But there are empirical models of the average air temperatures with altitude however, and that's presumably what you're using. But the conversions are not exact. It might be a good idea to add a '~' in the outputs to indicate that they're not entirely reliable. So something like:
  • {{convert|3.5|Mach}} → Mach 3.5 (~2,664.2 mph; ~4,287.7 km/h) GliderMaven (talk) 00:12, 3 February 2015 (UTC)
The code uses the method here (details in Module:Convert at "speed_of_sound"). I would have to investigate why convert is showing so many significant figures in the above examples—they are bogus. Maybe later...my head is spinning from other stuff. Johnuniq (talk) 03:14, 3 February 2015 (UTC)
Yes, without checking that's probably one of the standard atmosphere models, but there's several slightly different ones.
This Mach number to speed conversion is different to normal unit conversions, in that it's an approximation, whereas the other converts are exact.GliderMaven (talk) 14:19, 3 February 2015 (UTC)
IMO the issue is not that it is an approximation or institute-specific (after all, we can/should correctly write "Machaerospaceweb..."). Point #1 is that it is dependent on the altitude when used this way, and so that altitude must be reported. Then #2, since Mach is dimensionless the conversion can not be "km/h". Current output is wrong in this.
A metrically correct notion would be (with fake numbers):
"I was flying Machaerospaceweb 8 at 12000ft, that's 8765 km/h! Eight Machs, you know!" Or, conversely (ouch), vsound at 12000ft = 317 m/s.
Also correct is look like: 2233 km/h at 12000 ft is Machaerospaceweb 2.
The aerospaceweb table itself says: speed of soundaerospaceweb at 10 km = 1078.3 km/h.
Wrong would be, again: Mach 1 at 10 km = 1078.3 km/h. (for those who are still here: Mach 1 is always Mach 1, at every height!). -DePiep (talk) 18:18, 3 February 2015 (UTC)
"Mach number depends on the condition of the surrounding medium, in particular the temperature and pressure." The template uses a model to determine the speed of sound from the altitude, which makes certain assumptions about temperature and pressure. With no altitude value, the template converts the Mach number at sea level. As can be seen, the conversion is very depended on altitude:
  • {{convert|8|Mach}} → Mach 8 (9,800 km/h; 6,100 mph)
  • {{convert|8|Mach|0}} → Mach 8 (9,800 km/h; 6,100 mph) @ sea level
  • {{convert|8|Mach|1000}} → Mach 8 (9,800 km/h; 6,100 mph) @ 1,000 ft
  • {{convert|8|Mach|5000}} → Mach 8 (9,600 km/h; 6,000 mph) @ 5,000 ft
  • {{convert|8|Mach|10000}} → Mach 8 (9,500 km/h; 5,900 mph) @ 10,000 ft
  • {{convert|8|Mach|100000}} → Mach 8 (8,700 km/h; 5,400 mph) @ 100,000 ft
  • {{convert|8|Mach|300000}} → Mach 8 (7,900 km/h; 4,900 mph) @ 300,000 ft
To reiterate and amplify my initial statement: Converting the Mach number without including and showing the altitude is incorrect. --  Gadget850 talk 18:43, 3 February 2015 (UTC)
Mach 8 is not a speed at any height, so one should not write "Mach 8 (1234 km/h)". And yes, if it is written correctly the alt could be required. (however, that is not needed in a description like "I was gaining speed slowly, so it took me 10 mins to go from Mach 0.9 to Mach 2.1" - correct without alt. Come to think of it, no {convert} either). -DePiep (talk) 19:13, 3 February 2015 (UTC)
Mach is used as an indication of speed—a Mach number is equivalent to a certain speed that depends on specific conditions. Johnuniq (talk) 00:08, 4 February 2015 (UTC)

By the way, the altitude can be negative (flying in a canyon, below sea level): values from −17,499 to 302,499 feet are in convert's table.

  • {{convert|8|Mach|-5000|mph}} → Mach 8 (6,200 mph)
  • {{convert|8|Mach|mph}} → Mach 8 (6,100 mph)
  • {{convert|8|Mach|5000|mph}} → Mach 8 (6,000 mph)

Johnuniq (talk) 00:16, 4 February 2015 (UTC)

Mach examples

All converts in articles at 12 January 2015 that use Mach, starting with those that have no altitude:

  • Boeing Ground-to-Air Pilotless Aircraft ∙ {{convert|1500|mph|Mach|abbr=on}} → 1,500 mph (Mach 2.0)
  • Boeing Small Launch Vehicle ∙ {{convert|10|Mach}} → Mach 10 (12,300 km/h; 7,610 mph)
  • Boeing Small Launch Vehicle ∙ {{convert|4.5|Mach}} → Mach 4.5 (5,510 km/h; 3,430 mph)
  • CAC/PAC JF-17 Thunder ∙ {{convert|1.8|Mach}} → Mach 1.8 (2,210 km/h; 1,370 mph)
  • Exocet ∙ {{convert|1134|km/h|mi/h|mach}} → 1,134 kilometres per hour (705 mph)*
  • HAL Tejas ∙ {{convert|1.1|Mach}} → Mach 1.1 (1,350 km/h; 837 mph)
  • IAR 111 ∙ {{convert|2.6|Mach|sigfig=2}} → Mach 2.6 (3,200 km/h; 2,000 mph)
  • MIM-3 Nike Ajax ∙ {{convert|2.25|Mach|sigfig=3}} → Mach 2.25 (2,760 km/h; 1,710 mph)
  • Mach number ∙ {{convert|13|Mach}} → Mach 13 (15,900 km/h; 9,900 mph)
  • Railgun ∙ {{convert|2.4|km/s|Mach|disp=output only|sigfig=1}} → Mach 7
  • Ramjet ∙ {{convert|0.5|Mach|m/s km/h}} → Mach 0.5 (170 m/s; 610 km/h)
  • Ramjet ∙ {{convert|2.19|Mach|m/s km/h}} → Mach 2.19 (745.2 m/s; 2,683 km/h)
  • Ramjet ∙ {{convert|2|-|3|Mach|m/s km/h|disp=sqbr}} → Mach 2 – Mach 3 [680–1,000 m/s; 2,500–3,700 km/h]
  • Ramjet ∙ {{convert|3|Mach|lk=in}} → Mach 3 (3,700 km/h; 2,300 mph)
  • Ramjet ∙ {{convert|5|Mach|m/s km/h}} → Mach 5 (1,700 m/s; 6,100 km/h)
  • Ramjet ∙ {{convert|6|Mach|m/s km/h}} → Mach 6 (2,000 m/s; 7,400 km/h)
  • Sea Wolf (missile) ∙ {{convert|3|Mach}} → Mach 3 (3,700 km/h; 2,300 mph)
  • Terminal velocity ∙ {{convert|2900|mph|Mach}} → 2,900 miles per hour (Mach 3.8)
  • UGM-133 Trident II ∙ {{convert|18030|mph|Mach|abbr=on|disp=output only}} → Mach 24
  • Western Range ∙ {{convert|10|Mach|sigfig=2}} → Mach 10 (12,000 km/h; 7,600 mph)
  • XCOR Lynx ∙ {{convert|2|Mach|mph}} → Mach 2 (1,500 mph)
  • XS-1 (spacecraft) ∙ {{convert|10|Mach|km/h|lk=in}} → Mach 10 (12,300 km/h)

Converts with an altitude:

Johnuniq (talk) 00:08, 4 February 2015 (UTC)

Mach discussion 2

In general, I would not think convert should dictate how text is written. What if someone wanted a table of Mach conversions where each entry in the table is for a particular altitude? Bear in mind also that Mach can be used as an output and in combinations ({{convert|1234|mph|Mach km/s|abbr=on}} → 1,234 mph (Mach 1.6; 0.552 km/s)) and with all the standard options to display only the input or only the output, etc. That would make standard text like "@ 10,000 ft" difficult. Also, what if 10,000 ft is wanted in metres or km? At any rate, the first step should be to examine how Mach is used in articles and decide whether some change to convert would help. The second step would be to have a wikiproject discussion concerning how Mach should be used—please add a link to the discussion here. It's really a MOS issue because people do not have to use convert to say "the rocket reached Mach 8 (5,400 mph)", and editors can always add "@ 10,000 ft" after the convert template. Johnuniq (talk) 00:08, 4 February 2015 (UTC)

Yes, I agree, but I also don't think convert should be making the conversion from Mach to speed. The two are dimensionally incompatible, and the conversion cannot be made exactly, whereas convert is based on dimensional analysis. I also agree that how it appears is an MOS issue. It seems better that there should be a special script or two for this, which can call convert if the speeds need to be produced in km/h, knots or whatever.GliderMaven (talk) 02:57, 4 February 2015 (UTC)
"convert should not dictate how text is written" - I do not understand. It is not about how to write it, but about what to write. My point below in short: if an altitude is required to perform the Mach calculation, it must be reported (and note that it is a calculation not conversion primarily; a tabular lookup in this case).
re Johnuniq (ec?). Convert should not write things wrong. Of course the editor can write "Mach 8 ({{convert|5400|mph|km/h}}))". That is about editing quality. The speed itself in there, {convert} should do correctly. Then apart from the speed, we can not control this whole writing from {convert}, nor do we have to, nor want to.
But when convert does do a Mach conversion, then it must write it correct & complete. Correct includes: do not confuse dimensions (dim speed vs. dim 1), not even by suggestion or elusion. Complete includes: when the altitude is required to get anywhere, that altitude must be reported in the output. Also when that is the assumed default of zero sealevel altitude (which is then used just as well in for table lookup).
My background with this. Up until this thread, I never looked at Mach calculations: it was described as some magic in science. Now I know why: it is rarely written correct (Mach number + two values). When the altitude is left out, the information is plain incomplete. I wonder if any aeronautic source does so. Reminds me of the spoken habit of a length: "6 foot six". Does not belong in an encyclopedia, it's basic science (in lyrics it is OK of course, sometimes great even ;-) ). In writing we do not leave out the inch unit. So, to provide A Reader (like me) correct information the quantity must be written complete.
(rewritten a bit for clarity:)
Now some non-core remarks.
This requires two input values for one core Mach conversion. That is for {convert} to solve. Maybe the foot-inch input gives a hint. Technically, an alternative input option is the set of Mach number and speed (look up altitude then); I'll leave that for now for simplicity reasons — as long as convert does not get involved in formatting that whole sting (as in covering my whole example, before).
Remember this is a function too: a calculation (in this case a table lookup). That is not {convert} core business, there is no unit-conversion at the heart. Another example of calculation-not-conversion is: "From circle radius to area". See, no unit conversion in there.
I think for us, the problem we are wrestling with stems from this triple-step action: use two input param, do the calculate/table-lookup, and convert quantities into several units. Only one is familiar.
In an article, it might be convenient to mention the assumption once (eg, altitude for all Mach mentionings). That's output formatting for {convert} then, a bit like our link-at-first-mentioning rule. Adding to & leaving out from the output is not core of this discussion. -DePiep (talk) 08:20, 4 February 2015 (UTC) rewritten last part: -DePiep (talk) 08:43, 4 February 2015 (UTC)

Conversion between rpm and Hz ?

The convert template seems to not support a conversion between a frequency in revolutions per minute (rpm) and in hertz (Hz), see Revolutions per minute#International System of Units.

Is that correct?

If so, then that would be a useful extension of the convert template.

Thanks. Lklundin (talk) 13:22, 4 February 2015 (UTC)

There is a very large number of units, so while many more could be added it is generally preferred that a few articles be identified where a new unit would help. If a conversion is only needed in one or two places, particularly a rather strange one like this, using plain text is fine and I don't think convert is needed. Are there examples of where this would this be used? Johnuniq (talk) 00:34, 6 February 2015 (UTC)

Imperial (non-metric) water volume

I believe a common unit for describing large volumes of water is acre-foot. Convert cubic metres to cubic feet gives mind-blowingly large incomprehensible numbers. As does gallons. I guess an acre-foot is about 4400 cubic feet (484 X 9), which brings it down to something imaginable.--Unbuttered parsnip (talk) mytime= Fri 08:03, wikitime= 00:03, 6 February 2015 (UTC)

Any article or source link where this is shown? -DePiep (talk) 00:30, 6 February 2015 (UTC)
Engineering notation (for example, e6cuft for million cubic feet) can be used. Here are examples using gallons:
  • Audenshaw Reservoirs {{convert|5500|m3|e6impgal}} → 5,500 cubic metres (1.2×10^6 imp gal)
  • Chingaza Dam {{convert|223000000|m3|e9USgal}} → 223,000,000 cubic metres (59×10^9 US gal)
  • Gasoline {{convert|510|GL|e9USgal+e9impgal|abbr=off|sp=us}} → 510 gigaliters (130 billion U.S. gallons; 110 billion imperial gallons)
Are you aware that units acre ft and acre foot are defined, and there are several aliases equivalent to these two (see the full list of units). Example:
  • Mackenzie River {{convert|150|km3|acre feet|abbr=on}} → 150 km3 (120,000,000 acre⋅ft)
That could be:
  • {{convert|150|km3|e6acre feet|abbr=on}} → 150 km3 (120×10^6 acre⋅ft)
  • {{convert|150|km3|e6acre feet|abbr=in}} → 150 km3 (120 million acre-feet)
As DePiep says, an example of a problem would help. Johnuniq (talk) 00:48, 6 February 2015 (UTC)

Module version 8

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

The changes are:

  • Automatic per units (discussion here:
    • A unit code of the form x/y can be used to mean "x per y". For example, the unit code kg/hl is not defined but is automatically recognized as kilograms per hectolitre and can be converted with other mass/volume units.
    • The type of automatic per units can be specified. For example, mass/volume can be defined to mean density; that allows mass/volume automatic per units to be converted with existing density units.
  • When the input uses e-notation such as 12.3e4, the input value is displayed as a power of ten, and the output is displayed in scientific notation, except that an output value satisfying 0.01 <= v < 1000 is shown as a normal number. In addition, if the output value is 1000 and sigfig=4 is used, the value is displayed as a normal number (discussion here).
  • Option disp=br outputs <br /> instead of <br/> per an authoritative-looking discussion I saw somewhere recently; can't recall where.
  • New option disp=br() outputs <br /> and encloses the output in parentheses (discussion here).
  • Unit changes (discussions here and here):
    • in2 now has symbol in2 instead of sq in (use sqin if sq in is wanted).
    • in3 now has symbol in3 instead of cu in (use cuin if cu in is wanted).
    • fathom now has symbol ftm instead of fathom (use abbr=off if fathom is wanted).

Module version history

Examples of the changes are at the discussions links above. Johnuniq (talk) 07:08, 4 February 2015 (UTC)

Minor note about this list, not about code. Bullet "Option disp=br outputs ..." links to the topic of obsolete html: using style="text-align: center;" not align="center" (all fine). The space in <br />, mentioned, may be a change but is not about obsolete html I think. -DePiep (talk) 09:42, 4 February 2015 (UTC)
Oops, thanks, I completely misremembered that. I replaced the misleading link with a confession that I don't know where I got the idea (the removed link was for the version 7 release). I can't find a recent mention at WP:VPT or its archives, but it was within the last few weeks and I must have been impressed because I hate the space in <br />. Google shows a lot of confusion. I guess we can go with the space until someone has a better idea. Johnuniq (talk) 10:30, 4 February 2015 (UTC)
Glad you didn't find the rule to add that hated space. Now I can go on without it (and you can't ;-) ). -DePiep (talk) 11:47, 4 February 2015 (UTC)
  • Done: The module has been updated. Johnuniq (talk) 02:49, 6 February 2015 (UTC)
Dripped some notes in the documentation. The description "The type of automatic per units can be specified" above, is that to be in /doc? Looks like an internal note to me. -DePiep (talk) 16:00, 7 February 2015 (UTC)
Agreed; that note is not for users of the template. An explanation of what it is saying is here where, for example, the table translates mass/volume units to have type density. By the way, a detail I haven't mentioned is that automatic per units work only with units defined in Module:Convert/data; any units defined in Module:Convert/extra will not work in an automatic per unit. Johnuniq (talk) 09:42, 9 February 2015 (UTC)

Problem I missed reading some details in the Scribunto documentation. It turns out finding the length of a table (#value in the doc) does not work when the table is in the data module, and that causes some automatic per units to fail. Testing on my computer missed the problem because I am not using Scribunto. I've put a fix in the sandbox—I'm not sure whether to release that in a few days or wait until next month. The problem is not likely to cause trouble until automatic per units start being freely used, so there is no rush. Johnuniq (talk) 09:42, 9 February 2015 (UTC)

"|abbr=on alters the punctuation"

What is the purpose of {{convert|3|to(-)|6|ft|abbr=on}} producing dashes on both sides? Everybody who wants that could just write {{convert|3|-|6|ft|abbr=on}} without "to". But the current behavior prevents writing something like "from 3 to 6 ft (0.91–1.83 m)", producing instead "from 3–6 ft (0.91–1.83 m)", which is ungrammatical (or has a different meaning). Even if we think that abbreviated units must not be separated from numbers, the template should produce "from 3 ft to 6 ft (0.91–1.83 m)" but preserve the conjunction or preposition. — Mikhail Ryazanov (talk) 00:24, 8 February 2015 (UTC)

That's:
  • {{convert|3|to(-)|6|ft|abbr=on}} → 3 to 6 ft (0.91–1.83 m)
  • {{convert|3|-|6|ft|abbr=on}} → 3–6 ft (0.91–1.83 m)
  • {{convert|3|to(-)|6|ft|abbr=off}} → 3 to 6 feet (0.91–1.83 metres)
  • {{convert|3|-|6|ft|abbr=off}} → 3–6 feet (0.91–1.83 metres)
  • {{convert|3|to(-)|6|ft}} → 3 to 6 feet (0.91–1.83 m) -- default
  • {{convert|3|-|6|ft}} → 3–6 feet (0.91–1.83 m) -- default
My opinion: why would you expect a different range-indicator at all? -DePiep (talk) 00:36, 8 February 2015 (UTC)
Technically, because the very appearance of parameters like "to(-)" suggests that different indicators are requested. ;–) Stylistically, because "from 3 to 6 ft (from 0.91 to 1.83 m)" is too wordy (plus, the "from" on the right is currently impossible). And, in your opinion, why would you expect different range indicators without |abbr=on, but not with it? — Mikhail Ryazanov (talk) 01:15, 8 February 2015 (UTC)
re part #2 "And, in ..": no I don't expect that diff. That is not what you asked about; off-topic.
re #1: when you ask {{convert}} a format, you get it. Both sides same. Switches could be set by parameters. -DePiep (talk)
When I ask to(-) and abbr=on, I expect to get "to" on the left, "–" on the right, and abbreviated units. Why the parameter that controls abbreviation of units should affect the handling of range indicators? How to get different indicators with abbreviated units? — Mikhail Ryazanov (talk) 02:33, 8 February 2015 (UTC)
I do not know the original reasoning behind the way to(-) works, and the module merely emulates the old templates for that. It's complex because so many options are available, for example, order=flip, and the old templates had quite a bit of exceptional behavior, which the module generally emulates. I've put it on my to-do list to at least examine the issue, and might get a chance to report back in a few days. Johnuniq (talk) 10:33, 8 February 2015 (UTC)
I've added some non-abbr options. Mikhail, I was primarily posting to get the issue more clear. Because often on this page, multiple separate issues are together in one question. A re-description then can help to sort things out. -DePiep (talk) 16:29, 8 February 2015 (UTC)
OK, sorry for misunderstanding. I have looked at Module:Convert/text (namely, the range_types table), and it seems that the meaning of the range parameter is in fact "full(abbreviated)" instead of "left(right)" as I supposed. In my opinion, this is quite confusing and needs to be at least documented clearly. But I also think that "left(right)" notation would be much more user-friendly. As Johnuniq said, current code just follows the old behavior, so the question is whether it was intentional, and if yes, why. Also, is there any way to examine how this feature is used now? Maybe, the meaning can be changed without affecting the current usage. — Mikhail Ryazanov (talk) 16:58, 8 February 2015 (UTC)

Done I have updated the sandbox so range "to(-)" gives "to" for input and "–" for output. Also, range "and(-)" gives "and" for input and "–" for output. On thinking about the issue I decided the original design was probably based on the fact that handling order=flip would automatically work as wanted if the range was based on abbr. However, a module can add yet another line of code to handle that.

  • {{convert/sandbox|3|to(-)|8|kg}} → 3 to 8 kilograms (6.6–17.6 lb)
  • {{convert/sandbox|3|to(-)|8|kg|abbr=off}} → 3 to 8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3|to(-)|8|kg|abbr=on}} → 3 to 8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3|to(-)|8|kg|order=flip}} → 6.6 to 17.6 pounds (3–8 kg)
  • {{convert/sandbox|3|to(-)|8|kg|abbr=off|order=flip}} → 6.6 to 17.6 pounds (3–8 kilograms)
  • {{convert/sandbox|3|to(-)|8|kg|abbr=on|order=flip}} → 6.6 to 17.6 lb (3–8 kg)
  • {{convert/sandbox|3|to|8|kg}} → 3 to 8 kilograms (6.6 to 17.6 lb)
  • {{convert/sandbox|3|to|8|kg|abbr=off}} → 3 to 8 kilograms (6.6 to 17.6 pounds)
  • {{convert/sandbox|3|to|8|kg|abbr=on}} → 3 to 8 kg (6.6 to 17.6 lb)
  • {{convert/sandbox|3|to|8|kg|abbr=off|order=flip}} → 6.6 to 17.6 pounds (3 to 8 kilograms)
  • {{convert/sandbox|3|to|8|kg|abbr=on|order=flip}} → 6.6 to 17.6 lb (3 to 8 kg)
  • {{convert/sandbox|3|-|8|kg}} → 3–8 kilograms (6.6–17.6 lb)
  • {{convert/sandbox|3|-|8|kg|abbr=off}} → 3–8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3|-|8|kg|abbr=on}} → 3–8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3|-|8|kg|abbr=off|order=flip}} → 6.6–17.6 pounds (3–8 kilograms)
  • {{convert/sandbox|3|-|8|kg|abbr=on|order=flip}} → 6.6–17.6 lb (3–8 kg)
  • {{convert/sandbox|3|and(-)|8|kg}} → 3 and 8 kilograms (6.6–17.6 lb)
  • {{convert/sandbox|3|and(-)|8|kg|abbr=off}} → 3 and 8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3|and(-)|8|kg|abbr=on}} → 3 and 8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3|and(-)|8|kg|order=flip}} → 6.6 and 17.6 pounds (3–8 kg)
  • {{convert/sandbox|3|and(-)|8|kg|abbr=off|order=flip}} → 6.6 and 17.6 pounds (3–8 kilograms)
  • {{convert/sandbox|3|and(-)|8|kg|abbr=on|order=flip}} → 6.6 and 17.6 lb (3–8 kg)

I have not fully tested the changes, but they appear good. Johnuniq (talk) 09:48, 9 February 2015 (UTC)

Two quests:
Is there a general rule working for |order=flip: "first calc & format all individual values (measurements), then flip the order" or like "flip is done after abbr-effects but before punctuation is added"?
Self-reply: obviously, abbr and change of punctuation works after-flip (works with 'lefthand of output', not input). -DePiep (talk) 12:36, 9 February 2015 (UTC)
I just repeat my old, related note: input |3 and(-) 8, should be recognized & handled just as as input |3 to(-) 8.
  • {{convert/sandbox|3 and(-) 8|kg|abbr=on}} → 3 and 8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3 to(-) 8|kg|abbr=on}} → 3 to 8 kg (6.6–17.6 lb)
-DePiep (talk) 10:07, 9 February 2015 (UTC)
These are the same tests, but with single-parameter input: |3 to(-) 8|
Single-parameter input
  • {{convert/sandbox|3 to(-) 8|kg}} → 3 to 8 kilograms (6.6–17.6 lb)
  • {{convert/sandbox|3 to(-) 8|kg|abbr=off}} → 3 to 8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3 to(-) 8|kg|abbr=on}} → 3 to 8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3 to(-) 8|kg|order=flip}} → 6.6 to 17.6 pounds (3–8 kg)
  • {{convert/sandbox|3 to(-) 8|kg|abbr=off|order=flip}} → 6.6 to 17.6 pounds (3–8 kilograms)
  • {{convert/sandbox|3 to(-) 8|kg|abbr=on|order=flip}} → 6.6 to 17.6 lb (3–8 kg)
  • {{convert/sandbox|3 to 8|kg}} → 3 to 8 kilograms (6.6 to 17.6 lb)
  • {{convert/sandbox|3 to 8|kg|abbr=off}} → 3 to 8 kilograms (6.6 to 17.6 pounds)
  • {{convert/sandbox|3 to 8|kg|abbr=on}} → 3 to 8 kg (6.6 to 17.6 lb)
  • {{convert/sandbox|3 to 8|kg|abbr=off|order=flip}} → 6.6 to 17.6 pounds (3 to 8 kilograms)
  • {{convert/sandbox|3 to 8|kg|abbr=on|order=flip}} → 6.6 to 17.6 lb (3 to 8 kg)
  • {{convert/sandbox|3 - 8|kg}} → 3–8 kilograms (6.6–17.6 lb)
  • {{convert/sandbox|3 - 8|kg|abbr=off}} → 3–8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3 - 8|kg|abbr=on}} → 3–8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3 - 8|kg|abbr=off|order=flip}} → 6.6–17.6 pounds (3–8 kilograms)
  • {{convert/sandbox|3 - 8|kg|abbr=on|order=flip}} → 6.6–17.6 lb (3–8 kg)
  • {{convert/sandbox|3 and(-) 8|kg}} → 3 and 8 kilograms (6.6–17.6 lb)
  • {{convert/sandbox|3 and(-) 8|kg|abbr=off}} → 3 and 8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3 and(-) 8|kg|abbr=on}} → 3 and 8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3 and(-) 8|kg|order=flip}} → 6.6 and 17.6 pounds (3–8 kg)
  • {{convert/sandbox|3 and(-) 8|kg|abbr=off|order=flip}} → 6.6 and 17.6 pounds (3–8 kilograms)
  • {{convert/sandbox|3 and(-) 8|kg|abbr=on|order=flip}} → 6.6 and 17.6 lb (3–8 kg)
-DePiep (talk) 10:10, 9 February 2015 (UTC)
Thanks a lot! The tests you show appear good to me as well.
I tried to look how "to(-)" and "and(-)" are currently used with "abbr" by searching insource: convert insource:/\{\{convert[^}]+(to|and)\(-\)[^}]+abbr[^}]+\}\}/. It found only 35 pages, and their examination shows that the new behavior should be more correct than the old one (mostly for "from ... to(-) ..."; in the process I have also corrected some "between ... to(-) ..." to "between ... and(-) ...").
Do you need anything else before moving it from the sandbox? — Mikhail Ryazanov (talk) 23:03, 9 February 2015 (UTC)
About grammar, does this addition of 'from' or 'between' alter the factual meaning? Not in science I think. -DePiep (talk) 04:26, 10 February 2015 (UTC)
Formally, ranges are indicated as "from A to B" or "between A and B". The construction "between A to B" is meaningless, so I changed such occurrences to "...and..." (this is what they supposed to mean according to the context). Some people also write "from A–B" and "between A–B", but style guides (at least, Chicago and our MOS) say that this is a bad practice. (My comment: the dash already indicates a range, so "from A–B" would mean "starting in the range A–B", which can be meaningful in something like "different cameras can focus from 10–30 cm to infinity" or "existed from 200–100 BCE (exact date unknown)", but not just as "we have a meeting from 1–3pm" in the sense "from 1pm to 3pm".) The construction "from A to B" is often reduced to "A to B" (when it cannot cause confusion), which has the same meaning. — Mikhail Ryazanov (talk) 11:29, 10 February 2015 (UTC)

Enhanced single-parameter ranges

The system to magically handle single-parameter ranges was not efficient and I did not want to add more junk to it. Instead, I have put a new version in the sandbox which handles single-parameter ranges like this (referring to tables in Module:Convert/text):

  • Each range in range_types and range_aliases works if used with a space before and after (at least one space, but any amount of whitespace is accepted).
  • Each range in range_words (-, –, xx, x, *) can be used with any number of spaces, including none.
  • No fraction is accepted after a hyphen (-). That is to avoid interpreting 3-1/2 (which is sometimes incorrectly entered for 3+1⁄2 instead of 3+1/2) as a range from 3 to 1⁄2.

I'm not sure I would encourage the use of single-parameter ranges because editors are used to pipes and the magic of not using them might cause unnecessary confusion. However, here are just a few examples:

  • {{convert/sandbox|3 to(-) 8|kg|abbr=off}} → 3 to 8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3 to(-) 8|kg|abbr=on}} → 3 to 8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3 and(-) 8|kg|abbr=off}} → 3 and 8 kilograms (6.6–17.6 pounds)
  • {{convert/sandbox|3 and(-) 8|kg|abbr=on}} → 3 and 8 kg (6.6–17.6 lb)
  • {{convert/sandbox|3 and(-) 8|kg|abbr=on|order=flip}} → 6.6 and 17.6 lb (3–8 kg)
  • {{convert/sandbox|1x2x3 to 4x5x6|ft|in}} → 1 by 2 by 3 to 4 by 5 by 6 feet (12 in × 24 in × 36 in to 48 in × 60 in × 72 in)

An hilarious side effect is that some converts work with only one parameter. This is not supported! I'm going to think about what might go wrong with this feature and I don't think it should be documented at the moment—it's just an accident from the way the new code looks for "value range remainder". Examples:

  • {{convert/sandbox|123 m}} → [convert: invalid number] same as current convert
  • {{convert/sandbox|123 m yd}} → 123 metres (135 yd)

There are over 380 converts in articles using to(-) or to- (and 4 using and(-)) where the convert also uses abbr=on. These converts will behave differently when the new version is released.

I'm happy to do quick experiments and put them in the sandbox, but generally I like to leave it for a few days before checking everything, then perhaps leave it again for more thought, and contemplate whether to look at a couple of other items I had hoped to do. At any rate, this will not be live for a couple of weeks. There will be a notice here when that happens. Johnuniq (talk) 03:32, 10 February 2015 (UTC)

Thanks. No hurries. Indeed the hilarious effect must not be documented (not a feature - status). The single-parameter range input comes extra handy in infoboxes. E.g. {{Chembox}} uses |MeltingPtC=50 to 60 input happily. (I think different about "editors are used to pipes" being a positive thing. Typing input-as-read (copy/paste) is an earlier option that comes to mind). Glad it could be made systematically. I see even the trickier ones like "*" are covered. -DePiep (talk) 04:40, 10 February 2015 (UTC)

Module version 9

I have updated the modules to a new release with some minor fixes, as below.

  • Workaround problem in version 8 where I overlooked the Scribunto documentation which states that the standard Lua method of finding the length of a table does not work when the table is in the data module (accessed via mw.loadData()), and that caused some automatic per units to fail. For example, before the fix, the following failed with "unit mismatch, cannot convert length/mass to /mass":
    • {{convert|1|m/g}} → 1 metre per gram (93 ft/oz)
    That occurred because 1 m has default output ftin (feet and inches) and the module needs to find the length of the table holding that combination.
  • Refactored the code that handles single-parameter ranges so any range item can be used if it is surrounded with whitespace ({{convert|1 to 2|ft}}) while the ranges using symbols can be used with no whitespace ({{convert|1-2|ft}}). In the previous version, the rather ugly {{convert|1to2|ft}} was accepted, but that no longer works as spaces are now required. The effect is that all items can be used in a single-parameter range, whereas the previous version, using a less efficient procedure, only worked with some range items.
  • Adjusted range to(-) so "to" is used for the input and "–" for the output (previously, "to" was used with abbr=off and "–" with abbr=on). Discussion above.
  • Adjusted range and(-) in a similar fashion: "and" is used for the input and "–" for the output.
  • Changed disp=comma so output combinations are separated by a comma, not a semicolon:
    • {{convert|99|km|mi nmi|abbr=on|disp=comma}} → 99 km, 62 mi, 53 nmi

I normally would have waited before making this release but some issues arose that made me want to put it away for now. Johnuniq (talk) 09:05, 11 February 2015 (UTC)

Oops, I had to edit Template:Infobox drug (diff) because the previous infobox was outputting lines like this:
Melting point: {{convert|80to 90|C}} (no space before "to")
The new convert requires a space before "to" but "{{#if:x| to x|}}" does not provide that space because the #if helpfully strips it (which is different from how templates handle numbered arguments). I worked around that by always outputting a space after the first value (80 in the above example), so the output will be like one of the following:
Melting point: {{convert|80 |C}} (a single value)
Melting point: {{convert|80 to 90|C}} (a range)
Johnuniq (talk) 09:40, 11 February 2015 (UTC)

Convert metric to feet and inches?

Is there a functionality to convert metric (mm or m) to feet and inches or is it only capable of converting to decimal feet? In my experience, decimal feet can be confusing and would appear to be non-standard from my experience of my counties former usage of the imperial system - 4.9 ft might be easily misinterpreted as 4ft 9in. Certainly, in the case of hands, the decimal is used to indicate inches. How is this addressed? Cinderella157 (talk) 02:11, 24 February 2015 (UTC)

Some output units are defined for that, including ftin and ydftin, see the full list. In fact, ftin is the default output for m for input values above 0 and below 3:
  • {{convert|2|m}} → 2 metres (6 ft 7 in)
  • {{convert|3|m}} → 3 metres (9.8 ft)
  • {{convert|3|m|ftin}} → 3 metres (9 ft 10 in)
  • {{convert|121.2|cm|ftin|frac=4}} → 121.2 centimetres (3 ft 11+3⁄4 in)
  • {{convert|123|km|miydftin}} → 123 kilometres (76 mi 754 yd 1 ft 4 in)
Johnuniq (talk) 03:36, 24 February 2015 (UTC)
So it is:
  • {{convert|2|m}} → 2 metres (6 ft 7 in) -- the default
  • {{convert|2|m|ftin}} → 2 metres (6 ft 7 in)
  • {{convert|2|m|_ft_in}} → 2 metres (6.6 ft; 79 in) -- decimal point
  • {{convert|2|m|ft in}} → 2 metres (6.6 ft; 79 in) -- a spoace is used, returns decimal point
-DePiep (talk) 08:37, 24 February 2015 (UTC)

Unless I missed something, all of the examples on the page (except the fraction ones) appear to be going the other way. Would there be any value in recording some of the reverse examples? I think there would. Stop smucks like me asking dumb questions. Thanks all. Cinderella157 (talk) 09:48, 24 February 2015 (UTC)

Your questions are not dumb and no need to even say so. -DePiep (talk) 09:56, 24 February 2015 (UTC)
Reverse: from ft,in into meter

Base document #Input_multiples lists options for multiple unit input (like ft,in). It can catch predefined sets only (units that can be subdivided, e.g. yd into ft):

  • {{convert|1|yd|2|ft|3|in}} → 1 yard 2 feet 3 inches (1.60 m)
  • {{convert|2|ft|3|in|cm}} → 2 feet 3 inches (69 cm)
  • {{convert|1|lb|5|oz|g}} → 1 pound 5 ounces (600 g)
Will add this to the documentation page. -DePiep (talk) 10:06, 24 February 2015 (UTC)

@DePiep: The _ft_in in the example above is exploiting a weird trick that I suggest should not be documented. The full list has a note, "To simplify processing by the script which extracts data from this wikitext, a unit code is required in the first column; that unit code is not used." Consider the following results using the old templates:

  • {{convert/old|300|cm|ft m}} →
  • {{convert/old|300|cm|ft_m}} →
  • {{convert/old|300|cm|ft ___ _m _}} →

In each case, the results are identical, that is, multiple underscore and space characters are compressed to be equivalent to a single space (compare hello world and hello ___ _world _). The module emulates that, so the underscores in _ft_in are replaced with spaces, and the module then removes the leading space. That means the following are equivalent:

  • {{convert|2|m|_ft_in}} → 2 metres (6.6 ft; 79 in)
  • {{convert|2|m|ft in}} → 2 metres (6.6 ft; 79 in)

Each of the above converts 2 m to feet and to inches. Johnuniq (talk) 11:23, 24 February 2015 (UTC)

Had just put the following in, when there was an edit conflict.
Would suggest showing conversions in each direction. I thought this info from Johnuniq was pretty important (and certainly a link to find out more: "Some output units are defined for that, including ftin and ydftin, see the full list. In fact, ftin is the default output for m for input values above 0 and below 3." Two columns could show some notes in second and save on space? Can already see lots of examples going imperial to metric but not so much the other way. The example I saw that caused me to ask must have had the default over-ridden for it to come up as 1.5 m = 4.9 ft ? Thanks
Don't know if I understood all that @Johnuniq said but I gather it is a reason for negating the suggestion I was just making. Is increasing the default range an option then? I am guessing that turning down the precision would cause the inches to be omitted so you would see just X ft not X ft 0 in? Cinderella157 (talk) 11:59, 24 February 2015 (UTC)
re Johnuniq: got it. Adjusted. Crude edit in the /doc, no time to refine all this now. -DePiep (talk) 12:16, 24 February 2015 (UTC)

I have absolutely no idea about this particular code but here is a suggestion for what it is worth. For outputs of imperial units, I would have an argument/code that toggled between decimal and sub-units - much like the DMS/decimal degrees function on a calculator. If the su code was used with the output for 'ft', it would report ft and in. {{convert|5|m|ft|su}} would report 5 metres (16 ft 5 in). The su code could then work with any unit/sub-unit sequence, such as pound and ounces. It could even work with yds/ft/in (or similar) if sufficient precision were specified (just like the DMS function). Just some thoughts. I might not have understood the discussion, so I might be right off beam and i certainly have no idea if the coding is practical. Cinderella157 (talk) 12:32, 24 February 2015 (UTC)

Do I understand this correct: you want to be able to ask for the decimal point in ft,in output, even it the number is outside of the 0-3 ft range? (the opposite output option is: always integer ft and the fraction in the inch value. That is the default). -DePiep (talk)
Decimal output for 0–3 m is easy enough.
  • {{convert|2|m|ft}} → 2 metres (6.6 ft)
It seems that what's being suggested is to have this su (also) give output as arbitrary unit/sub-unit strings as an alternative to ftin, ydftin, stlb, lboz, etc. I don't believe that using the fourth unnamed parameter in this way would be a good idea, instead, I'd suggest imp as a third unnamed parameter which would convert the input to whatever string of unit and sub-unit(s) is appropriate (determined by the size and precision). Of course, you'd want to have US as well for gallons, pints, short tons, etc. ... and U.S. for the same but with dots. Then you'd probably want combinations like imp US etc. If we really wanted to go all-out, we could also include USdry for dry measures, but that's probably be more trouble than it's worth.
  • {{convert|5.23|m|imp}} → 5.23 metres (5 yd 2 ft 2 in)
  • {{convert|5.23|kg|imp}} → 15.23 kilograms (2 st 5 lb 9 oz)
  • {{convert|5.23|kg|US}} → 15.23 kilograms (33 lb 9 oz)
  • {{convert|35.8|t|imp}} → 35.8 tonnes (35 long tons 4 cwt)
  • {{convert|13.87|l|US}} → 13.87 litres (3 US gal 2 qt 1 pt 5 oz)
  • {{convert|12.34|l|US imp}} → 12.34 litres (2 imp gal 2 qt 1 pt 14 oz or 3 US gal 1 qt 1 oz)
Might it be worth the effort? Jimp 14:21, 24 February 2015 (UTC)

Just wrote a reply with an edit conflict and it is now redundant (mainly).

I was more, providing an outsiders perspective than a 'want'. From my usage perspective, many conventional imperial units are reported on a unit/sub-unit basis and not a decimal basis. The decimal reporting is (in many cases) quite anomalous until you get to the smallest 'normal' unit. Measurements are routinely reported to an accuracy of inches well beyond 3 ft (take for example, human height and tapes in feet and inches to 50 m [shoot me for mixing units]). Take this observation for what it is worth. I was mainly suggesting a different perspective for how to deal with the unit/sub-unit vs decimal output 'dilemma'. Rater than having a different set of arguments/codes for each physical quantity range (eg ft/in, yds/ft, yds/ft/in, lb/oz etc), I was suggesting an argument/code to toggle between decimal and sub-units and, if related to precision, the precision specified would determine if yds/ft/in was reported, rater than yds/ft or just yards. Incidentally, I would say, 'accuracy', but I believe precision is the usage here, to reflect the number of decimal places (but that is a different story). Anyhow, I was just throwing an idea out there. It might be all too hard or just not worth it. Does the US use decimal feet much???

Long and the short, Jimp has pretty much got it right. Would only say:

  • {{convert|5.23|m|ft|imp}} → 5.23 metres (17 ft 2 in)

and similar, as an option. I see that 'imp' and 'us' certainly have advantages. Cinderella157 (talk) 15:05, 24 February 2015 (UTC)

re Jimp's idea: looks great. My approach to evaluate: a single list in the /documentation could & should show this all. Great (because I say: if it is simple in the /doc, it is good for the editor). Now here are my party-spoilers ;-). Know that I am not familiar with imp/US measurements.
1. If "imp" and "US" woulds cover them all, that's great. We can understand two. 2. Already noted by Jimp: "USdry" as an exception. I hope Johnuniq has numbers to show that these are underused (like '10 times only in total'). In that case: the editor indeed should go to the /doc page, because of rareness. But if usage of USdry is substantial, that is a minus. More exceptions in sight? (Long ton? glad I understand that one at last). 3. Now this is a big thing: we would like to use it for input too! Would that work? {{convert|12|imp|m}} ??? I don't think it could. So there the editor still must lookup. (for this reason, maybe we'd better have unit-codes that are the same left and right: input_unit=ftin, output_unit=ftin). 4. The issue of decimals, precision, and value range to be added.
My next step, writing is thinking so I progressed: we could have a double input-set: "imp, US" and "ftin, ..." work as long as they are unambiguous, both for input and output unit. (What I do not want, is exceptions in these. No editor will ever understand that or use that). -DePiep (talk) 19:55, 24 February 2015 (UTC)

I think we might be going down a different path, which is fine, just that I don't think that is where I was pointing. My idea was to provide a toggle between a decimal output and sub-units. You would still specify the output unit but the toggle would common (ie it would be used for weight, length etc).

  • {{convert|5.23|m|yds|su}} → 5.23 metres (5 yd 2 ft 2 in)
  • {{convert|5.23|m|ft|su}} → 5.23 m (17 ft 2 in)
  • {{convert|5.23|m|ft}} → 5.23 metres (17.2 ft)


  • {{convert|5.23|kg|st|su}} → 15.23 kilograms (2 st 5 lb 9 oz)
  • {{convert|5.23|kg|lb|su}} → 15.23 kilograms (33 lb 9 oz)
  • {{convert|5.23|kg|lb}} → 15.23 kilograms (33.6 lb)

Note how the su code interacts with the nominal output unit and how the absence of the code defaults to a decimal output. I have assumed that decimal is the default output and the switch code turns the sub-unit output on. The alternative is for sub-units to be the default and the switch code to turn on decimal output. The alternative is probably better from a user perspective. In the examples, I went back to the su code, because I think that the imp and us codes are being used to do different things (in similar but different ways). At present, ftin, ydftin, ft and yds all have different meanings. There is a similar array for mass and volume. I suggest that ft and yds with a switch code for sub-units is much more intuitive, particularly when the switch code is common across physical quantities (length, mass volume etc). Looking at things more closely, I realised that Jimp's idea was probably going somewhere else from mine but they could be convergent. Anyhow, it appear I have given you something to think about. Cinderella157 (talk) 22:53, 24 February 2015 (UTC)

So |st|su would be stone + subunits, and |ft|su would be ft and its subunits. -DePiep (talk) 01:01, 25 February 2015 (UTC)
Yes. As would |yds|su be yards + subunits. In this example, whether you get Yds/ft or yds/ft/in in the output would be a function of the accuracy of the inputed measurement. I 'believe' it works this way already. Alternatively, the output could also be manually limited by the precision number. As I believe it operates now. You could specify a precision number so you only get yds/ft and not yds/ft/in, regardless of the input precision. Cinderella157 (talk) 01:33, 25 February 2015 (UTC)
I don't think adding an unnamed parameter would be helpful—the template already has an amazing set of complex options, and adding more will just cause confusion. That is particularly true for unnamed parameters because they would be expected to work in strange combinations:
  • {{convert|5.23|m|ft|su}}
  • {{convert|5.23|m|ft|su|1}} (precision = 1)
  • {{convert|5.23|m||su|1}} (use default output)
  • {{convert|5.23|m|1|su}} (can put precision after input unit)
Jimp's idea would be feasible using the following scheme: there would be a new table in the unit definitions that shows what imp means for each input unit where it might make sense—that would make imp a "variable alias". However, what is wanted is some magic that also takes into account the value—sometimes ftin would be wanted, and other times ydftin, and more. I suppose the table could include the input value.
While these ideas are useful, the reality is that editors have already voted because I don't think that even ydftin is used. A couple of articles use ydft and lots use ftin, but I don't think any other output multiple units are used. Johnuniq (talk) 01:11, 25 February 2015 (UTC)
I leave this thread, unless someone gives me a good hint to improve {{Convert/doc}}. -DePiep (talk) 01:41, 25 February 2015 (UTC)
I did start out think of an argument that turned on the subunit function but I did realise (see above) that it might be better if subunits was the default. You would then need to insert an argument to 'turn on' decimals if decimals and not subunits was desired. To me, it makes more sense since (in my experience) decimals are not common and can be misleading - it is 6 ft 3 in not 6.25 ft and 7 lb 12 oz not 7.75 lb. Again, just my thoughts. Cinderella157 (talk) 01:46, 25 February 2015 (UTC)

Again, just a thought. I am assuming the su approach here just because that is what we have been talking about. rather than having a separate argument, just change the names of the output unit variable so it 'appears' to operate the same way so:

  • |ydft = |yds|su = |ydssu or |ydsd if subunits were made the default output.
  • |ftin = |ft|su = |ftsu or |ftd
  • |stlb = |st|su = |stsu or |std

I am suggesting that appending a standard suffix to the output unit name is more intuitive than 'remembering' the different combination names, which aren't always just co-joining the names of two units. Cinderella157 (talk) 02:00, 25 February 2015 (UTC)

Regarding long verses short tons, these had crossed my mind, but for simplicity imp could give the long version (with stones) and US the short (without stones). I do agree with Johnuniq, though, that we may be fixing a problem that doesn't exist. Another idea could be to introduce su as a parameter (rather than a value of a parameter) so {{convert|5.23|m|ft|su=on}} would give feet and inches (or {{convert|5.23|m|ft|su=off}} decimal if the default is to use feet and inches). There may be a problem of which set of subunits to choose, though, for example, would we want {miles, furlongs, chains, rods, yards, feet, inches, barleycorns and poppyseeds} or something simpler like {miles, yards, feet, inches} (or even get rid of yards as well) and what about quarts, gills, firkins, etc.?

{{convert|5.23|m|ft|su=off}} sounds good. As does miles, yards, feet, inches. My experience is that floz is generally used for smaller volumes and pint or quart are usually measures of convenience but pint may be a convenient intermediate volume. Stone is usually confined to weighing people so ton lb and oz would be more customary cwt was often used but often omitted. Would suggest t/lb/oz and perhaps gal/pt/floz but usage is probably a better indicator. If that is any help? Cinderella157 (talk) 05:21, 26 February 2015 (UTC)

PS would it be easier to make it work by linking it to existing unit pairs/triplets so ft in the output would link to ftin, yds in the output would link to ydftin, lb in the output would link to lboz, st to stlboz(?) and so on. Cinderella157 (talk) 05:32, 26 February 2015 (UTC)

Choose "primary" quantity from several possibilities

Is it possible to choose the "primary" unit in the case of, say, being given a number in mph, and wanting the display order to be "knots (mph km/h)" or similar? A simple "order=flip" won't do because it isn't binary. At present all I know how to do is to convert to the primary unit manually, which is less than ideal. Archon 2488 (talk) 21:15, 26 February 2015 (UTC)

I can think of this. Regular:
{{convert|10|mph|kn km/h}} → 10 miles per hour (8.7 kn; 16 km/h)
You free choice output order:
{{convert|10|mph|kn km/h mph|disp=output only}} → 8.7 kn; 16 km/h; 10 mph
I could not re-introduce the brackets. -DePiep (talk) 22:31, 26 February 2015 (UTC)
I was fiddling around with this recently (I think because I ran into some glitches during my current project which is to consider removing almost all of the output combinations), and the best I could come up with was what DePiep shows. It is possible to use an ugly hack, but there is no good way to get the rounding right. I am not recommending this!
  • {{convert|{{convert|10|mph|kn|6|disp=number}}|kn|km/h mph|1|adj=ri2}} → 8.69 knots (16.1 km/h; 10.0 mph)
In short, there is no reasonable way, sorry. I think the solution would involve a major innovation in the syntax which won't happen soon. Johnuniq (talk) 03:09, 27 February 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_February_2015&oldid=864984985"