Template talk:Convert/Archive 2

This is an archive of past discussions about Template:Convert. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

Deadweight tonnage

Do the convert templates have any help for converting Deadweight tonnage into internationally recognized units of weight, or mass? tons and tonnes short tons and long tons plus others? are legend. I did a search and couldn't find anything. Cheers. N2e (talk) 04:09, 29 July 2020 (UTC)

There are DWton and DWtonne. There are too many units to list on any reasonable page. The full list is at Module:Convert/documentation/conversion data#Mass. Johnuniq (talk) 07:02, 29 July 2020 (UTC)

Thanks, Johnuniq! Will give it a shot with those. N2e (talk) 08:33, 29 July 2020 (UTC)

Proposal: Add angular units

Since {{convert}} supports almost every conceivable unit (except poorly defined historical/folk units), it seems puzzling that it does not support angular units. I propose to add the following units:

Code	Symbol	Name	Link	Comment
`°`	°	degree	Degree (angle)	The buttons for entering ° ′ ″ are right under the text input area.
`′`	′	arcminute	Minute of arc
`″`	″	arcsecond	Second of arc
`mas`	mas	milliarcsecond	Milliarcsecond
`µas`	µas	microarcsecond	Microarcsecond
`radian`	rad	radian	Radian	`rad` is already taken by radiation unit rad.
`mradian`	mrad	milliradian	Milliradian
`grad`	grad	gradian	Gradian	grad is non-standard, but instantly recognizable.
`turn`	turn	turn	Turn (angle)
Rotational speed:
`rpm`	rpm	revolution per minute	Revolutions per minute	Default output: `Hz`.
`radian/s`	rad/s	radian per second	Radian per second	Default output: `Hz`.
Aliases:
`arcmin`	arcmin	arcminute	Minute of arc
`arcsec`	arcsec	arcsecond	Second of arc
`gon`	gon	gradian	Gradian	gon is specified in ISO 31-1.
`r`	r	turn	Turn (angle)	r is specified in IEEE 260.1:2004 and ISO 80000-3:2006.
`MOA`	MOA	minute of angle	Minute of arc	Used in weapons aiming. Default output: `milr`.
`milr`	mil	milliradian	Milliradian	Used in weapons aiming. Default output: `MOA`. `mil` is already taken by thousandth of an inch.

The multiple units feature of {{convert}} can be used in input:

{{convert|2|°|47|′|19|″|radian|abbr=on}} → 2° 47′ 19″ (0.048670 rad)
{{convert|47|′|19|″|mradian|abbr=on}} → 47′ 19″ (13.764 mrad)

And output:

{{convert|0.50|mradian|′″}} → 0.50 milliradian (1′ 43″)
{{convert|0.50|mradian|′ ″}} → 0.50 milliradian (1.72′; 103″)

There are other angular units that may be added in the future, if a need arises:

Plane angle: compass point, binary degree (=binary radian, brad), diameter part, milliturn, microturn, NATO mil, Warsaw Pact mil (=Soviet mil, Russian mil, m.d.u.), Swedish streck;
Rotational speed: cycle per second (=c.p.s., c/s, cycle), kilocycle per second (=kilocycle, kc), megacycle (=Mc), kilomegacycle (=kMc);
Solid angle: steradian, square degree, spat.

— UnladenSwallow (talk) 05:16, 21 April 2020 (UTC)

Yes we need solid angle. It seems that the non-SI square degree is used in many places, which you can find as links to that page. The one I ran into this for is gravitational wave, but also at least Wide_Angle_Search_for_Planets, but maybe all the links to square degree. Gah4 (talk) 15:22, 8 July 2020 (UTC)

Any new unit needs a couple of examples of articles where convert would be useful. That is, what wikitext in an article would be replaced with a convert? Previous discussions (which I haven't looked at recently) are at September 2015 and February 2018 and October 2019. Convert already supports a hertz unit but it is rather unusual (Hz is a unit of length)—see March 2015. Johnuniq (talk) 06:52, 21 April 2020 (UTC)

{Slightly off-topic} Can I just pick you up on one point: Hz isn't a unit of length. If c is a velocity, then Hz is a unit of reciprocal time; If c is dimensionless, then Hz is a unit of reciprocal length. I understand that {convert} can be set up to make conversions from wavelength (length) to frequency (reciprocal time), but it's a mistake to assert that {convert} only converts quantities that have the same dimensions. As an example, it has been converting fuel consumption for years:

{{cvt|5|L/100 km}} → 5 L/100 km (56 mpg_‑imp; 47 mpg_‑US)
{{cvt|10|L/100 km}} → 10 L/100 km (28 mpg_‑imp; 24 mpg_‑US)

where the input unit has dimensions of volume/length (area) and the output units have dimensions of length/volume (reciprocal area!). --RexxS (talk) 19:19, 21 April 2020 (UTC)

@Johnuniq:

Article

Example

Pendulum

In the case of a typical grandfather clock whose pendulum has a swing of 6° and thus an amplitude of 3° (0.05 radians), the difference between the true period and the small angle approximation (1) amounts to about 15 seconds per day.

Angular diameter

The table shows that the angular diameter of Sun, when seen from Earth is approximately 32′ (1920″ or 0.53°), as illustrated above.

To put this in perspective, the full Moon as viewed from Earth is about 1⁄2°, or 30′ (or 1800″).

Globe

Usually a globe is mounted so that its spin axis is 23.5° (0.41 rad) from vertical, which is the angle the Earth's spin axis deviates from perpendicular to the plane of its orbit.

Telescopic sight

Some proprietary rails also offer the possibility to tilt the scope up to 1° (60 moa; 17.5 mrad) to the left or right.

Equation of time

The numerical values written here result from using the orbital parameter values,

e

= 0.016709,

ε

= 23.4393° = 0.409093 radians, and

λ p

= 282.9381° = 4.938201 radians that correspond to the epoch 1 January 2000 at 12 noon UT1.

Steradian

This angle corresponds to the plane aperture angle of 2θ ≈ 1.144 rad or 65.54°.

Faraday effect

By placing a rod of this material in a strong magnetic field, Faraday rotation angles of over 0.78 rad (45°) can be achieved.

JavaScript syntax

`Math.acos(Math.SQRT1_2)`	0.78540 rad. = 45°	Arccosine
`Math.asin(Math.SQRT1_2)`	0.78540 rad. = 45°	Arcsine
`Math.atan(1)`	0.78540 rad. = 45°	Half circle arctangent (- $π$ /2 to + $π$ /2)
`Math.atan2(-3.7, -3.7)`	-2.3562 rad. = -135°	Whole circle arctangent (- $π$ to + $π$ )

Young–Laplace equation

For a water-filled glass tube in air at sea level:

γ = 0.0728 J/m² at 20 °C	θ = 20° (0.35 rad)
ρ = 1000 kg/m³	g = 9.8 m/s²

Small-angle approximation

The angles at which the relative error exceeds 1% are as follows:

$tan θ \approx θ$ at about 0.176 radians (10°).
$sin θ \approx θ$ at about 0.244 radians (14°).
$cos θ ≈ 1 − .mw-parser-output .sfrac{white-space:nowrap}.mw-parser-output .sfrac.tion,.mw-parser-output .sfrac .tion{display:inline-block;vertical-align:-0.5em;font-size:85%;text-align:center}.mw-parser-output .sfrac .num{display:block;line-height:1em;margin:0.0em 0.1em;border-bottom:1px solid}.mw-parser-output .sfrac .den{display:block;line-height:1em;margin:0.1em 0.1em}.mw-parser-output .sr-only{border:0;clip:rect(0,0,0,0);clip-path:polygon(0px 0px,0px 0px,0px 0px);height:1px;margin:-1px;overflow:hidden;padding:0;position:absolute;width:1px}⁠θ2/2⁠$ at about 0.664 radians (38°).

— UnladenSwallow (talk) 11:02, 23 April 2020 (UTC)

Arcsec is commonly taken to be arcsecant. See Inverse_trigonometric_functions. Martin of Sheffield (talk) 19:34, 23 April 2020 (UTC)

@Martin of Sheffield: Not in astronomy:

Article	Example
Exoplanet	The data was obtained on 16 March 2003 with NACO on the VLT, using a 1.4 arcsec occulting mask on top of AB Pictoris.
Alpha Centauri	Viewed from Earth, the apparent orbit of A and B means that their separation and position angle (PA) are in continuous change throughout their projected orbit. Observed stellar positions in 2019 are separated by 4.92 arcsec through the PA of 337.1°, increasing to 5.49 arcsec through 345.3° in 2020. The closest recent approach was in February 2016, at 4.0 arcsec through the PA of 300°. The observed maximum separation of these stars is about 22 arcsec, while the minimum distance is 1.7 arcsec.
Alpha Centauri	Their apparent angular separation varies over about 80 years between 2 and 22 arcsec (the naked eye has a resolution of 60 arcsec), but through much of the orbit, both are easily resolved in binoculars or small telescopes.
Quasar	Image is 60 arcsec on a side.
New Horizons	The instrument is equipped with a 1024×1024 pixel by 12-bits-per-pixel monochromatic CCD imager giving a resolution of 5 μrad (~1 arcsec).
Parallax	The nearest star to the Sun (and thus the star with the largest parallax), Proxima Centauri, has a parallax of 0.7687 ± 0.0003 arcsec.
Cosmic distance ladder	It is, more precisely, the galaxy's angular diameter out to the surface brightness level of 20.75 B-mag arcsec⁻².
Panspermia	The probability of hitting the target zone can be calculated from $P({\text{target}})={\frac {A({\text{target}})}{\pi (dy)^{2}}}={\frac {ar({\text{target}})^{2}v^{2}}{(tp)^{2}d^{4}}}$ where A(target) is the cross-section of the target area, dy is the positional uncertainty at arrival; a – constant (depending on units), r(target) is the radius of the target area; v the velocity of the probe; (tp) the targeting precision (arcsec/yr); and d the distance to the target, guided by high-resolution astrometry of 1×10⁻⁵ arcsec/yr (all units in SIU).
Astrometry	In the 16th century, Tycho Brahe used improved instruments, including large mural instruments, to measure star positions more accurately than previously, with a precision of 15–35 arcsec.
	He made the first measurement of stellar parallax: 0.3 arcsec for the binary star 61 Cygni.
	During the past 50 years, 7,435 Schmidt camera plates were used to complete several sky surveys that make the data in USNO-B1.0 accurate to within 0.2 arcsec.
Proper motion	Of the stars visible to the naked eye (by convention, limiting visual magnitude of 6.0), 61 Cygni A (magnitude V=5.20) has the highest proper motion at 5.281 arcsec/a, although Groombridge 1830 (magnitude V=6.42), proper motion 7.058 arcsec/a, might be visible for an observer with exceptionally keen vision. A proper motion of 1 arcsec per year at a distance of 1 light-year corresponds to a relative transverse speed of 1.45 km/s.

Arcsecant is not a measurement unit anyway, so arcsec will be unambiguous when used with {{convert}}. — UnladenSwallow (talk) 11:38, 24 April 2020 (UTC)

Mach conversions are off

See Boom Overture. This template is translating Mach 2.2 as 2,300 km/h or 1,300 kn, the actual values (precision 2 s.f.) ought to be 2,700 km/h or 1,500 kn. Could someone please fix this?--Newbiepedian (talk · C · X! · L) 15:44, 2 August 2020 (UTC)

Newbiepedian, the template is showing the converted speeds at altitude (in this case, I believe 60,000 ft). 2700 km/h would be the speed at ground level, which the aircraft obviously would not be flying when at Mach speeds. Unfortunately I can't find where using Mach in the template is really documented anywhere. — Huntster (t @ c) 16:27, 2 August 2020 (UTC)

Search for Mach in Module:Convert. The unit that is supplied after the Mach is the altitude. So:

{{convert|2.2|Mach|0|kn km/h|-2}} gives Mach 2.2 (1,500 kn; 2,700 km/h)
{{convert|2.2|Mach|60000|kn km/h|-2}} gives Mach 2.2 (1,300 kn; 2,300 km/h)

-- WOSlinker (talk) 21:03, 2 August 2020 (UTC)

Hmm, I can't find where Mach was ever documented. Meanwhile, as explained above, a number following Mach as the input unit is the altitude in feet. There is no way to specify an altitude if using Mach as the output unit. Altitude is relevant because Mach number is relative to the speed of sound which varies with atmospheric conditions, mainly pressure which varies with altitude. Johnuniq (talk) 23:36, 2 August 2020 (UTC)

I remember Mach has an @-parameter, iow it is tabular/3D/third-dependence. -DePiep (talk) 00:26, 3 August 2020 (UTC)

g/PS/h fuel efficiency

Ikarus 55#Technical description
190 g·PS−1·h−1 (258 g·kW−1·h−1)
190 g·PS⁻¹·h⁻¹ (258 g·kW⁻¹·h⁻¹)
How was this calculated and how can this be done with convert? Peter Horn User talk 00:22, 4 August 2020 (UTC)

Johannes Maximilian wrote Ikarus 55 in May 2019 and may like to comment. I'm not familiar with measuring fuel consumption in that manner and the ⁻¹ stuff would be a puzzle for many readers, although obvious for anyone with a basic science education. Here is the article text and the closest convert can do (cvt = convert with abbr=on):

190 g·PS−1·h−1 (258 g·kW−1·h−1) → 190 g·PS⁻¹·h⁻¹ (258 g·kW⁻¹·h⁻¹)
{{cvt|190|g/PS/h|g/kW/h}} → 190 g/PS/h (260 g/kW/h)
{{cvt|190|g/PS/h|g/kW/h|0}} → 190 g/PS/h (258 g/kW/h)

Johnuniq (talk) 00:51, 4 August 2020 (UTC)

Different fuels have different densities, which is why in internal combustion engines, a "mass per energy" figure is used. For example, if an Akroyd engine has a 9 litre fuel consumption (and we're using Diesel fuel since it's cheaper), it has a higher(!) fuel consumption than an Otto engine that burns 10 litres of petrol: 9 litres of Diesel fuel is approx. 7.65 kg, whereas 10 litres of petrol is approx. 7.5 kg. Energy is the product of power and time, so if we're reversing this, we can have mass per power output per time. So for example, if a 100 kW engine runs for one hour at full load, and it has a rated fuel consumption of 200 g/kW/h, it burns 200×100 g = 20 kg of fuel. If one kilogramme of fuel holds 40 MJ of energy, 100 kWh of motion energy require 800 MJ or 222 kWh of chemical energy, so the engine's efficiency is 45 %. Now back in the 1960s, engineers used g/PS/h, since engines were often rated in PS. That is wht g/PS/h exists. Technically, g/kWh is incorrect, because it implies (g/kW)h "grammes per kilowatt times hour. What we say and mean is "grammes per kilowatthour, which would be g/(kWh), or g/kW/h, or g·kW⁻¹·h⁻¹. A common mistake with conversions is multiplying g/PS/h with 0.73549875 instead of dividing it by that figure for converting to g/kW/h. So 150 g/PS/h is actually 204 g/kW/h and not 110 g/kW/h. I hope I have convered all questions you might have had. Best regards, --Johannes (Talk) (Contribs) (Articles) 01:30, 4 August 2020 (UTC)

Bits and bytes

There seem to be no bit and byte unit conversions, e.g. between kilobytes and megabytes etc. Should we add them? I didn't find any discussions in the archive. I'd like to add them to Module:Convert/documentation/conversion data. Of course, we'll have to take care of binary prefixes and conversions between bits and bytes, and also make sure that unit names are unambiguous, but that shouldn't be a major problem. What do you think? -- Chrisahn (talk) 11:19, 13 October 2020 (UTC)

Template:Val has entries for kB, MB, GB, and TB (but none for or other multiples), as well as a couple of data rates, e.g. Mbit/s. Will we have to move them? I don't quite understand the relation between Val and Convert. -- Chrisahn (talk) 11:19, 13 October 2020 (UTC)

The biggest problem will be getting the MOS changed. As things currently stand binary prefixes are not to be used – daft, I know, but getting controversial changes through MOS is glacial. @Chrisahn, AIUI {{val}} is used for expressing a single value whereas {{convert}} is used for converting between different units. Martin of Sheffield (talk) 11:53, 13 October 2020 (UTC)

Oh, I see. That's indeed a nuisance. I can currently think of four ways to deal with this:

Always convert by powers of ten, always display SI prefixes.
- Examples:
  - {{convert|2,000,000|bytes|MB}} would display 2,000,000 bytes (2 MB)
  - {{convert|65536|bytes|KB|0|disp=out}} would display 66 KB
- Pro: Very simple to implement.
- Pro: Usually OK for disk drives etc.
- Con: Utterly wrong for RAM: the C64 doesn't have 66 KB of RAM.
Let users specify SI or IEC units, display SI prefix when converting to SI unit, display IEC prefix when converting to IEC unit.
- Examples:
  - {{convert|2,000,000|bytes|MB}} would display 2,000,000 bytes (2 MB)
  - {{convert|65536|bytes|KiB|0|disp=out}} would display 64 KiB
- Pro: Also simple to implement, I guess.
- Pro: Usually OK for disk drives etc. - just convert by powers of ten.
- Pro: Numerically correct for RAM - just convert by powers of two. The C64 has 64 KiB of RAM.
- Con: Violates MOS for powers of two. :-(
Let users specify SI or IEC units, always display SI prefixes, additionally display IEC prefixes when converting to IEC unit.
- Examples:
  - {{convert|2,000,000|bytes|MB}} would display 2,000,000 bytes (2 MB)
  - {{convert|65536|bytes|KiB|0|disp=out}} would display 64 KB (IEC: KiB)
- Pro: Also simple to implement, I guess.
- Pro: Usually OK for disk drives etc. - just convert by powers of ten.
- Pro: Also OK for RAM - just convert by powers of two. The C64 has 64 KB (IEC: KiB) of RAM. (That's exactly what its infobox currently shows.)
- Pro (?): I think it conforms to MOS. Or does it?
Let users specify SI or IEC units, display SI prefixes by default, let the user specify whether to display IEC prefixes instead / in addition.
- Examples:
  - {{convert|2,000,000|bytes|MB}} would display 2,000,000 bytes (2 MB)
  - {{convert|65536|bytes|KiB|0|disp=out} would display 64 KB
  - {{convert|65536|bytes|KiB|0|disp=out|binpre=IEC}} would display 64 KiB
  - {{convert|65536|bytes|KiB|0|disp=out|binpre=SI+IEC}} would display 64 KiB (IEC: KiB)
- Pro: Usually OK for disk drives etc. - just convert by powers of ten.
- Pro: Also OK for RAM - just convert by powers of two, choose most appropriate prefix:
  - By default, we would display 64 KB of RAM for the C64. Fine.
  - Or we could display 64 KB (IEC: KiB) of RAM for the C64. Also fine.
  - We could display 512 KiB to 4 MiB of L2 cache for the ARM Cortex-A72. Fine - that's exactly what its infobox currently shows.
- Pro: Definitely conforms to MOS.
- Con (?): Might be hard to implement. We'd have to modify Module:Convert and add a new parameter.
  - If we don't want to change Module:Convert, we could encode the display in the unit name, e.g. KiB-IEC. Not very intuitive for users.
  - Or is there a better way? One that lets users specify this with existing parameters in a way that's not too awkward?

(We should add explanatory links, e.g. 64 KiB (IEC: KiB), but I didn't want to clutter up the examples even more.)

Option 4 would be nice and flexible, but may be too much work. Maybe option 3 would do for now. If users want more flexibility, we can extend option 3 later.

Yeah, I'm overthinking this. But it's fun! :-) -- Chrisahn (talk) 15:52, 13 October 2020 (UTC)

Another point: Maybe the MOS isn't really that strict anymore and IEC units have become more common? The MOS says The IEC prefixes are generally not to be used except ... • when the majority of cited sources on the article topic use IEC prefixes ... • in articles in which both types of prefix are used with neither clearly primary ... Even CD-ROM (probably read by less technical readers than e.g. ARM Cortex-A72) uses lots of IEC units. -- Chrisahn (talk) 16:13, 13 October 2020 (UTC)

There have been many lengthy arguments about kibi/kilo and they cannot be resolved by a template. For example, I reverted this edit which was technically correct but IMHO unhelpful. Ambiguity worries some people but I think we have to accept it—anyone who cares about kibi/kilo understands the simple issue. On the technical question, if a conversion template was accepted by MOS, it should be separate from convert because kibi/kilo would need processing and options that don't apply to unit conversions. The first step would be a discussion at a wikiproject to identify the problem and what is needed. Johnuniq (talk) 22:56, 13 October 2020 (UTC)

My real point is that first there would need to be resolution with a wide discussion (including at MOS) concerning "this edit" that I linked. That is, what should an article like that say? Johnuniq (talk) 23:04, 13 October 2020 (UTC)

Yes. This is a great example of something {convert} should stay out of. E Eng 23:54, 13 October 2020 (UTC)

@Johnuniq: '"kilobytes" is widely understood and anyone who cares knows about 1000/1024' is itself unhelpful. Taking the position that we, as an encyclopaedia, should peddle falsehoods because readers might find it easier to be mislead is plain wrong. Your edit summary should have read "Reverted due to conflict with MOS", because frankly that is the only reason to keep up this abuse of the units in the face of categorical statements by the BIPM. Incidentally, this is why I warned the OP. Until senior editors like yourself can be persuaded then this whole conversation is pointless, it isn't going to happen. Martin of Sheffield (talk) 06:23, 14 October 2020 (UTC)

@Martin of Sheffield: Writing "2¹⁶ = 64 kilobytes" is not actually false, not unless read in a very literal manner. That's because, in this context, kilo is ambiguous and can mean 2¹⁶ or 10³. Eventually the ambiguity will be unacceptable in common usage and MOS will change. Even then, writing "2¹⁶ = 64 KiB" would not be helpful unless KiB were linked. I see that WP:COMPUNITS favors KB but says nothing about kilobyte. Johnuniq (talk) 06:57, 14 October 2020 (UTC)

The problem is that when working with computers you do need to be precise and literal so your example is false. Morally, we really should be using accurate SI approved terms and avoiding banned usages,^[1] but as a mere ordinary editor there's not much I can do about MOS except warn others of the minefield! Martin of Sheffield (talk) 07:44, 14 October 2020 (UTC)

Folks, let's stop this. This wasn't meant to be about WP:COMPUNITS at all. It was never my intention to address that question. I didn't even know about that MOS section. Please consider this thread closed. I'll archive it later. Maybe I'll start a new one when I have time. Thanks. -- Chrisahn (talk) 11:57, 14 October 2020 (UTC)

References

^ Bureau Internationaldes Poids et Mesures (2019), The InternationalSystem of Units(SI) (PDF) (9th ed.), p. 143, ISBN 978-92-822-2272-0, retrieved 14 October 2020

Post-closing thoughts

Regarding {{Convert}} the topic is closed, OK. However, I'd like to learn some more from this thread. Al lot of people put a lot of info in this. So, to consolidate, for when this is pulled from the archives, let's evaluate. -DePiep (talk) 23:44, 26 October 2020 (UTC)

Better wikilink needed

I notice at 2020 Beirut explosion that in an instance of this template, {{convert|1.2|ktonTNT|TJ|sigfig=2|lk=on}}, which renders as 1.2 kilotons of TNT (5.0 TJ), the link over TJ goes just to Joule, rather than to Terajoule, which redirects to Joule#Terajoule. I think it would be more useful for readers for the link to go to terajoule, since they may not know that the T stands for tera. Could a more specific link be adopted here for terajoules and other multiples of joules/other units as appropriate? {{u|Sdkb}} ^talk 02:45, 17 August 2020 (UTC)

Thanks, I added terajoule and gigajoule as links (megajoule and kilojoule already existed). That will go live when I next update the modules, which I'd better do in the next week or two. Johnuniq (talk) 03:02, 17 August 2020 (UTC)

Absolute temperature vs. temperature difference

The Convert template handles absolute temperatures just fine:

"The mean winter temperature in Smallville is {{convert|3|C|F}}." yields "The mean winter temperature in Smallville is 3 °C (37 °F)."

But Convert cannot handle temperature differences correctly:

"The mean annual temperature in Smallville has increased by {{convert|3|C|F}} in the last century." yields "The mean annual temperature in Smallville has increased by 3 °C (37 °F) in the last century." which is nonsense. The correct conversion would be: "The mean annual temperature in Smallville has increased by 3°C (5.4°F) in the last century."

I noticed this error in the article about Kuujjuaq. I fixed it there by simply removing the Convert template in cases where the temperature being referenced is a difference, and doing the conversion manually. I haven't searched, but I wouldn't be surprised if this mistake has come up in many articles, such as in coverage of global warming.

I can't think of an elegant way to fix this. Perhaps a mechanism like this could be implemented: {{convert|n|deltaC|deltaF). But that would require some serious work on the Convert help page, and would still probably confuse many editors. I have little experience with templates, maybe someone with more experience could suggest a better idea. STarry (talk) 07:22, 14 September 2020 (UTC)

@STarry: it already handles this (Template:Convert#Units of difference: Expressing a change or difference in temperature) :

{{convert|3|C-change|F-change}}: 3 °C (5.4 °F)
{{convert|3|C|F}}: 3 °C (37 °F)

Imzadi 1979 → 07:33, 14 September 2020 (UTC)

pounds of coal per indicated horsepower hour

Any idea how I should handle the following unit: Pounds of coal per indicated horsepower hour

This is a measure of the fuel efficiency of early steamships and appears in SS Carnatic. Carnatic and Agamemnon both achieved a massive stepwise improvement in efficiency (though the higher boiler pressure of SS Agamemnon (1865) became the model for immediate future development).However, in discussing this, the units look clumsy and are not friendly to anyone used to modern units.ThoughtIdRetired (talk) 20:01, 16 September 2020 (UTC)

I don't think convert can help with that—there are some strange energy and power units but nothing related to burning coal. All that could be done would be a manual conversion. I imagine the unit is a crude measure with no precise conversion available (for example, different samples of one pound of coal probably release different amounts of energy when burned). The "indicated horsepower-hour" could be converted with something like this:

{{convert|1|hph|kWh|adj=pre|indicated}} → 1 indicated horsepower-hour (0.75 kWh)
{{convert|1|hph|kWh|adj=pre|indicated|spell=in}} → one indicated horsepower-hour (0.75 kWh)
{{convert|1|hph|kWh|disp=out}} → 0.75 kWh

The last would allow something like "2 lbs of coal per indicated horsepower-hour (2 lbs of coal per 0.75 kWh)". Johnuniq (talk) 05:13, 17 September 2020 (UTC)

Long Ton to Ton conversion wrong

There are 2240 pounds in a Long Ton (LT). The convert macro does not convert LT-to-ton correctly.

Ex: {{convert|3900|LT|t}} incorrectly yields 4,000 tons, not 4,368 tons. Proof: 3,900 long tons (4,000 t)
Ex: {{convert|2100|LT|t}} incorrectly yields 2,100 tons, not 2,352 tons. Proof: 2,100 long tons (2,100 t)
See Propulsion section of the IJN aircraft carrier Akagi.

How to fix? Or can someone else correct the conversion? 50.107.153.113 (talk) 21:23, 17 September 2020 (UTC)

N/m. I see the authors in many pages are specifying an incorrect abbreviation, using "t" instead of "ST". Le sigh.

Ex: {{convert|3900|LT|ST}} more correctly yields 4,400 tons, not 4,368 tons. Proof: 3,900 long tons (4,400 short tons)
Ex: {{convert|2100|LT|ST}} more correctly yields 2,400 tons, not 2,352 tons. Proof: 2,100 long tons (2,400 short tons)

I guess the next question is if this "rounding" is desired?

50.107.153.113 (talk) 21:29, 17 September 2020 (UTC)

To be clear:

{{convert|3900|LT|ST|abbr=off|}} → 3,900 long tons (4,400 short tons)

{{convert|2100|LT|ST}} → 2,100 long tons (2,400 short tons)

→ 3,900 long tons (4,400 short tons)

-DePiep (talk) 21:33, 17 September 2020 (UTC)

Rounding can be controlled:

{{convert|3900|LT|ST|abbr=off|0}} → 3,900 long tons (4,368 short tons)

{{convert|2100|LT|ST|0}} → 2,100 long tons (2,352 short tons)

Or through the use of the sigfig or round options. Editors at the article in question should decide how much rounding is appropriate. Stepho talk 22:13, 17 September 2020 (UTC)

Thanks

Everyone who worked on this Temp really knows what they're doing. I'm very impressed. Invasive Spices (talk) 22:41, 2 October 2020 (UTC)

It's really true. People don't appreciate it until something goes wrong. E Eng 11:13, 28 November 2020 (UTC)

Long ton template

{{long ton|166| 6| 2}} 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t) does not work but this {{long ton|166| 6}} 166 long tons 6 cwt (372,500 lb or 169 t) does work. Talk:South Australian Railways 700 class (steam)#A flaw? Peter Horn User talk 00:43, 22 November 2020 (UTC)

That is due to how {{Long ton}} operates (it does not use convert). The fix appears to be to omit the spaces:

{{long ton|166|6|2}} → 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t)

Johnuniq (talk) 01:18, 22 November 2020 (UTC)

Fixed Added {{trim}} to all unnamed parameters. Demo example in OP does not show error anymore ;-) -DePiep (talk) 13:16, 28 November 2020 (UTC)

How far are we from being able to add a unit user preferences option?

I've been impressed with how developed and flexible this template is. Ultimately, I assume that the place we want to end up is with an option in user preferences that allows choosing a unit/currency/etc. system, so that a British reader could see meters even when reading a U.S. article and a U.S. reader feet even when reading a British one, without the clutter of the other unit. How far are we from making this a reality? Is it just a matter of doing some complicated programming, or are there particular obstacles from the way articles are written, or are there editorial concerns about e.g. fracturing the encyclopedia? {{u|Sdkb}} ^talk 18:49, 21 September 2020 (UTC)

I see issues:

The same issues arise as with the old date autoformatting system. Basically, the only people who can benefit are logged-in users. For readers without accounts, it is worse than the status quo because the logged-in editors will just use their preferred unit and assume it will autoformat. For the logged-out reader, this may end up with a hodgepodge of different units in the same contexts in the same sentence.
Some users are likely to prefer a set of units that does not consistently follow one system or the other. For example, they might measure their distance in miles but their temperature in Celsius (this is pretty standard in Britain). There's going to have to be a long list of preferences.
In some contexts it will be preferable to override the user preference because it does not make sense in context. It will not necessarily be easy to identify these cases.

Kahastok talk 20:14, 21 September 2020 (UTC)

Hugely contentious policy questions, hugely complicated design questions, huge investment of development resources desperately needed for other stuff. Besides, exposing readers to corresponding units in multiple systems, side by side, has educational value. E Eng 20:26, 21 September 2020 (UTC)

Another issue: I might use a meter to measure 5 metres! Martin of Sheffield (talk) 20:45, 21 September 2020 (UTC)

The reason this won't happen with the current MediaWiki software and server situation concerns caching of the results of rendering a page (converting the wikitext to HTML that is sent to the reader). There are "read only" servers dedicated to feeding HTML to people viewing pages. They have certain abilities that I know nothing about concerning customizing core features like the user links at the top right for a logged-in user, but the HTML of the page is essentially fixed. It would be possible for logged-in readers to run personal scripts that replaced words but that would have many flaws. Regarding the issue (the horror of showing meters/metres to someone who only wants to see feet, or vice versa), I think one of the charms of Wikipedia is that it demonstrates that the world is a big place and not everyone is same as you. In fact, some people spell words in a funny way and use crazy units. Johnuniq (talk) 23:44, 21 September 2020 (UTC)
That last bit is an expanded version of my last point above. Absolutely right. E Eng 02:56, 22 September 2020 (UTC)
And the number of people who spell words in a funny way and use crazy units is always one more than you think. --RexxS (talk) 19:49, 22 September 2020 (UTC)

I now see why the covert would write 1 mile (1.6 km) or 1 pound (0.5 kg). That is preferred behavior. De reverse is not 0.5 kilograms (2 lbs) or 1.6 kilometers (1 mi) is not the right way to do it. In the metric system, the number of unit is limited and known. So it should be 1.6 km (1 mi) or 0.5 kg (1 lbs). I know abbr=on will get this behavior (it should always be turned on, unless very limited decisions to turn it of when metric is the given value). Also, on purpose write the meter and the grams. Note that a lot of the other spelling concerns would be gone use the metric units only. Take a look at e.g., the German versions and see how the text flows with metric units abbreviated. — Preceding unsigned comment added by Frankk20168 (talk • contribs) 11:02, 9 November 2020 (UTC)
@Frankk20168:, we've been around this loop before. See Template talk:Convert/Archive 1#Inconsistent abbreviation. Looks like you have to remember to use abbr=on, I'm afraid. --John Maynard Friedman (talk) 16:21, 9 November 2020 (UTC)
@Frankk20168: Actually, 1.6 kilometres (1 mi) is exactly the right way to do it on first occurrence. We spell out the unit name, like "kilometre", on its first use in case the reader is not familiar with the abbreviation and therefore they have a full unit name to look up. We add a parenthetical conversion every time because a reader may be familiar with an imperial unit, but not the metric unit (or vice-versa). As we are providing the conversion specifically for those who are already familiar with the alternative unit, there's no point in spelling out its full name, as the abbreviation will clearly suffice. This probably needs writing into a FAQ. --RexxS (talk) 23:27, 9 November 2020 (UTC)

@RexxS I understand where you are coming from, but ISO and even the US dept. of commerce do not agree. I am just copying the text for simplicity

https://physics.nist.gov/cuu/pdf/sp811.pdf section 7.6 This Guide takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible . This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using — the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and — the symbols for the units, not the spelled-out names of the units. Examples:

the length of the laser is 5 m -- but not: the length of the laser is five meters
the sample was annealed at a temperature of 955 K for 12 h -- but not: the sample was annealed at a temperature of 955 kelvins for 12 hours

--end-quote -- Bold added by me.--
The bold should be enough to use the symbols, not the full text. A couple of points to add: We are not introducing a meter (m) as this is known and understood. However a concept like Performance Management (PM) would still be introduced in this manner. Also, I would like to just point out that saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m. If that m truly has to be introduced, then the first mention should be 5 meter (m). Note that I also changed the 5 meters into 5 meter (5 meters is not allowed for sure). Hence 5 m works easier and better, because you can read it the way you want even as five metres if you want. My only additional advice would be to avoid d(deci), D(Deka) and H(Hecto) at all cost to make the text readable. Stick to micro, milli, kilo and Mega. Note that I strategically forgot to mention centi. Should not be used in this logic, but is just to pervasive to ignore in the older UOMs. I am actually not trying to create a huge stir here. But abbr=on should be used and not using it the first time does not add value and so abbr=on should be used for all. Also keep text readable by not using 0.5 km (1,640.4 ft) however true this statement is. It creates an assumption of precision in the translated unit that was not there in the original UOM. So wiki does this almost correct with 0.5 km (1,600 ft); just don't add |0 or |1 as I see very often — Preceding unsigned comment added by Frankk20168 (talk • contribs) 07:03, 28 November 2020 (UTC)

Whether or not units should be abbreviated at Wikipedia is not a matter for this template. Instead, it's a manual of style issue: MOS:UNITS. Johnuniq (talk) 08:38, 28 November 2020 (UTC)

@Frankk20168: When the folks at ISO and the US dept. of commerce start writing encyclopedia articles for an audience that specifically consists of readers from many different countries who may or may not be familiar with metric or Imperial units, then we can start taking some notice of them. Their advice to always use unit symbols runs completely counter to their intent to "allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English". Do you seriously contend that someone who only uses metric units will understand what 63 ch means? Language independence is not the principal priority for the English Wikipedia, and there are 300 other language Wikipedias that use their own language. The Spanish Wikipedia can write la longitud del láser es de cinco metros without confusing any Spanish speaker because even those only familiar with Imperial units will be able to work out what cinco metros means. There is absolutely no reason whatsoever that we should not write "the length of the laser is five metres" on the English Wikipedia, although supplying a parenthetical conversion to feet, (16 ft), would be helpful.

I reject your assertion that saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m. because this is not a paper encyclopedia. For a common unit, it doesn't matter so much, but we could write "five metres" and more importantly, we will write "five chains" on first use, where the hyperlink for an uncommon unit allows the reader to establish the magnitude of the unit as well as its abbreviation if they are unfamiliar with it. That definitely helps a reader get to grips with 63 ch when they see that at the second mention.

Thanks for the rest of your advice, but grandmas and egg-sucking come to mind. In addition, you're completely wrong about the use of |abbr= for the reasons already rehearsed. When you've actually used Template:Convert, you'll find that it does a really good job of dealing with precision by default and {{convert|0.5|km|ft}} produces 0.5 kilometres (1,600 ft), which is as good a conversion as anyone will want most of the time. There are edge cases where the default precision isn't optimal, but the fixed decimal places option and rounding to a given number of significant figures functionality are available to improve the display in those cases. --RexxS (talk) 13:02, 28 November 2020 (UTC)

Johnuniq)

@Johnuniq: I agree with you that the template in most cases does a great job in convert and makes it at the right significant numbers. A lot of converts have |0 added or sometimes the intent of the statement is missed because of convert (e.g., the thing is about 500 m (1,640 ft) away. The conversion introduces a bit too much significant digits. And I agree that this is user error in this case)

On you ch example, I also agree. That should be introduced. My point is normal SI units should not be introduced. The meter being prime among them. This is what REUTERS has to say about it:

kilogram

Use kg (no full stop, same singular and plural) at all references. To convert to pounds multiply by 2.205.

kilometre

Use km (no full stop, same singular and plural) at all references, except in a phrase such as hundreds of kilometres.

km per hour

First reference, kph on second and subsequent references.

/quote Obviously I have problems with the last statements (the kph part). But I included it to get part of your point in, too. Again, I completely agree to introduce 5 feet and then followed by 10 ft (or even 10') later. or 63 chain and then 60 ch. My contentions was for the basic SI units (And I admit I added basic here for the first time), they should not be spelled out. Introducing 100 kilometer per hour is just a painful read. It also introduces at least two issues: Should it be: 100 kilometer per hour 100 kilometers per hour 100 kilometre per hour 100 kilometres per hour All these four variations get resolved by making it 100 km/h. Again, I agree with most of what you are saying. The above on Si unit L, m, km and kg we have different opinions. I would also like to point out that "15,000 pounds per square inch (100,000 kilopascals)" (An actual copy from a paste from a Wiki page) is a painful read that does not help (Americans know that PSI ha something to do with their tire pressure, it is never spelled out. The 100,000 kilopascals is too much. Both also have the problem of the added s. I realize we will never get on exactly the same page. So here is the summary of my advice (incorporating your feedback):

Don't introduce commonly known basic SI units (kg, m, km, L)
Introduce most non-SI units (feet, pound, etc.)
Don't introduce non-SI units that are solely used in their abbreviated form (PSI, ...)
for All SI Units, make sure they conform to the ISO standard (No plurals, no period(.) unless it is the end of a sentence)
If you use SI prefixes, stick to the multiples of 1000, unless strong convention makes the unit still viable (cm).
Few people will understand / know prefixes beyond giga or below micro

I hope this helps and also creates some reasonable guidelines that can help. — Preceding unsigned comment added by Frankk20168 (talk • contribs) 06:09, 30 November 2020 (UTC)

This is now at WT:Manual of Style/Dates and numbers#Exception for SI Weight and Length. Johnuniq (talk) 08:44, 30 November 2020 (UTC)

Usage question

Not really about the template itself, but I was reverted at General Electric GE9X when adding the template because "the source contained both values". WP:Integrity was cited, which doesn't say anything about this. Is there really a valid reason to not use the template? MB 16:31, 8 December 2020 (UTC)

You mean the source contained both, and one differed from the converted value? Gah4 (talk) 16:53, 8 December 2020 (UTC)

Normally it should be WP:CALC, but maybe not in every case. Gah4 (talk) 17:51, 8 December 2020 (UTC)

In a carefully written document, especially a technical document, the number of significant figures is meaningful. If the source gives both systems of measurement, the Wikipedia article should match not only the value, but the number of significant figures. In the case at hand, giving the principal length as 224.0 in (5689.6 mm) would be correct. Giving it as 5689.6 mm (224.0 in) also be correct, if the article is placing metric units first. Giving the length as 5689.6 mm (224 in) would be wrong because it would be a misrepresentation of what the source says. By the way, the OP totally bungled the invocation of the convert template. Jc3s5h (talk) 18:25, 8 December 2020 (UTC)

Assuming it is a carefully written document ... One should not give the convert value with excessive sigfigs compared to the original, though sometimes one more is needed. As above, sometimes the conversion gives too many digits. It would be usual in a technical document to get the number if digits right in the first value given, not necessarily in converted values. I didn't look at what the OP did, though. Better documents give uncertainties instead of depending on the number of digits. (Which is a somewhat rough indicator of precision.) Gah4 (talk) 18:45, 8 December 2020 (UTC)

Mach

As I noted in Help talk:Convert, it seems that {{convert|1.6|Mach}} Mach 1.6 (1,960 km/h; 1,220 mph) doesn't set sigfig based on the input value. It was suggested to ask here about it. I don't know if this is specific to Mach, though. I put sigfig=2 in the one case I found, and don't know how many others there might be. Is there a regexp search good enough to search for them? Gah4 (talk) 14:04, 8 December 2020 (UTC)

~300 mainspace uses (with some obvious false positives). It will be practically impossible to find cases split between a template page (as in an infobox). --Izno (talk) 14:14, 8 December 2020 (UTC)

It even found converted to maintenance and machine. Some have the word Mach after an actual template, so maybe should use the template. Gah4 (talk) 17:31, 8 December 2020 (UTC)

@Gah4: That was a lazy search up there. This one is probably more representative. About 200 cases. --Izno (talk) 19:32, 8 December 2020 (UTC)

visualhide removal

This template/module uses the visualhide class. It has a TemplateStyles solution and will accordingly be removed from Common.css soon. Your feedback regarding the timeline is requested at MediaWiki talk:Common.css § visualhide removal. Izno (talk) 17:10, 2 December 2020 (UTC)

The usage might be a code copy/paste from {{frac}}. -DePiep (talk) 18:09, 2 December 2020 (UTC)

Yes, I'm too lazy to have thought of that myself, and it was copied. Nothing about convert is simple. Examining an enwiki dump of articles from June 2020 shows:

Template	Total	Fractions	Percentage
convert	3,145,551	13,182	0.4
cvt	107,257	421	0.4

Should the 3 million convert usages output a template style that is used by only 0.4% of them? Where would that templatestyles be placed? Johnuniq (talk) 23:25, 2 December 2020 (UTC)

And what about |disp=table usages and possibly others? Would they work painlessly? Johnuniq (talk) 23:55, 2 December 2020 (UTC)

More info: the above numbers are counts of {{convert}} and {{cvt}} in article wikitext. Those templates are called many more times from infoboxes, for example for a person's height or weight. I'm hoping Izno or someone familiar with templatestyles can say whether adding around 43 bytes of output to every convert would be a problem. Can the module do something magic and only output it if needed?

The following shows a table example with the generated wikitext:

{{convert|47.5|kg|lb|disp=table}} → style="text-align:right;"|47.5\n|style="text-align:right;"|105

Johnuniq (talk) 02:18, 3 December 2020 (UTC)

I had hoped to centralize these questions to MediaWiki talk:Common.css, especially since, from what I could tell, every use of the class was for someone copy-pasting {{frac}}. I'll probably copy over this commentary to the MediaWiki talk page.

Since you are worried about the 10s of bytes, I assume you are worried about the Post‐expand include size; maybe you have a different limit in mind. AIUI, TemplateStyles comes out of the budget for Unstrip post‐expand size: N/5000000 (5.0 mega)bytes rather than the Post‐expand include size: M/2097152 (2.1 mega)bytes, which means you have a different budget you have to care about. (Anomie, am I right? Please say yes. :) You pay for emitting the classes, but that is almost always cheaper compared to the inline styles.

Secondly, what occurs with TemplateStyles is that one <style> tag is emitted with the content of the styles, and then any subsequent uses of the TemplateStyles tag emit a <link> tag indicating that the module does not need to emit the styles anymore. This is probably the second way in which it is cheaper.

Yes, the module should only add TemplateStyles for Template:sronly where it is needed (probably hooking in to Template:Screen reader-only/styles.css directly rather than the template, unless you want to add the full template as a dependency), which, from what I can see, is only in the context of the copy-paste from Template:Frac. If the expected frame:extensionTag were prepended to where  were output, I wouldn't expect there to be any fundamental issues.

In this regard, I have hacked the sandbox and the visual output as well as fundamental HTML of Template talk:Convert/testcases/sandbox1 looks okay; the test failures are because the module does not know how to deal with the strip tokens. I'm not sure where to go to review the other paths through the module since there seems to be a discrepancy in how fracfmt is handled between the two code paths where it is used versus its earlier definition: 1 definition has 3 replaced patterns with %s, the other three have 4; whereas the calling sites expect 4 patterns total. (And anyway, it's a hack in an unfamiliar codebase, so forgive me any sins. ;)

That said, I see opportunity in fracfmt to decrease the output regardless when displaying as a fraction by moving the inline styles there to TemplateStyles and/or from include to unstrip budgets (pending Anomie on the second part). This could either rely on {{frac}}'s TemplateStyles, or since we're here, a new Module:Convert/styles.css for the stuff unrelated to sr-only. (I see other places you might entertain a move as well; I count some 10-15 uses of style=.)

I don't really understand why {{frac}} is being forked here (frac is heavy? convert is heavy and accordingly dependency-averse? don't know how to call another template?), but this may be a good time to consider un-forking. I would suggest working on that after TemplateStyles are integrated for sronly (so I'm not blocked on removing visualhide ;).

Use in tables should be fine since it looks like Convert always emits a data-sort-value surrounding the contents when used in table form. I do not know how it will do as a naked convert in a sortable table with the style/link elements. TheDJ might have some knowledge there.

Common to the other places visualhide is used, I do not know how many uses of Convert with a fraction are internal to links. I would guess none, or sufficiently few as to be worked around if people have issues, but you probably know more than me about that.

(Aside: {{frac}} and any copies should probably use TemplateStyles rather than hackish and [which have a semantic meaning that {{frac}} does not match].)

--Izno (talk) 04:20, 3 December 2020 (UTC)

Thanks, I'll chew on that. If the module can output something if it thinks it is needed, a hack can certainly be added. Re forking frac, I was never sure that convert would actually work when developing it (because it does such a massive amount of work to replace the 4,000 templates formerly used). Therefore it was easier and much more efficient to include what was needed in the module rather than expanding other templates. One of the issues at the time was that convert sometimes hit template limits, and that's years ago when there were a lot less converts than now. Johnuniq (talk) 04:36, 3 December 2020 (UTC)

I had browsed WP:TemplateStyles before but not mw:Help:TemplateStyles which it points to. The latter makes it much clearer what is going on. I'll leave that link here for me and anyone else puzzled about what triggers recognition of a template style (answer: it's the right wikitext syntax and can come from anywhere; no template or module are needed). Johnuniq (talk) 06:51, 3 December 2020 (UTC)

Izno, "I don't really understand why {{frac}} is being forked here" probably to save on transclusion count. Templates like convert are sometimes used hundreds of times on long pages. "Use in tables should be fine since it looks like Convert always emits a data-sort-value surrounding the contents when used in table form." yeah... probably... My biggest worry would be the extra inline tag and how some other templates/modules deal with that. But hard to know those before making a change that surfaces those. —TheDJ (talk • contribs) 09:11, 3 December 2020 (UTC)

re "why ⁄ is being forked here" (TheDJ). Don't know about {{Convert}}, but in {{Track gauge}} I did so to remove the nowrap tag, since nowrap was needed only once enveloping all of "71⁄2 ft".

While I am here: {{frac}} is in view, but please note that {{sfrac}} uses the "+" not a space. -DePiep (talk) 14:20, 3 December 2020 (UTC)

@Izno: I did a little experimenting, it looks like TemplateStyles counts towards 42 bytes of the post-expand include size (for the strip marker). Unstripped, every use counts the whole size of the (minified) stylesheet; TemplateStyles itself emits a <style> for every use and they're then deduplicated, and apparently the unstrip size is measured before deduplication. Anomie ⚔ 17:02, 3 December 2020 (UTC)

@Izno: Re Module:Convert/sandbox: Sorry that I have ignored the issue due to normal turmoil. However, I think about what should be done and I have a plan for handling styles in convert. I should get around to it in the next couple of days. Another plan I've had for years is to fix Module:Convert/tester so it changes the unique number in strip markers to be, say, all zeroes so the comparisons won't break. Johnuniq (talk) 23:40, 11 December 2020 (UTC)

Johnuniq, no worries. I was just looking at ignoring templatestyles strip markers before I was called away, like is done in module:UnitTests, since they're of trivial interest even when they are expanded from strip marker. --Izno (talk) 00:32, 12 December 2020 (UTC)

As of now though, this is the only template I'm waiting on; I spent a couple hours today moving the other templates of interest away from depending on visualhide. --Izno (talk) 00:34, 12 December 2020 (UTC)

I'll record here that I tweaked Module:Convert/tester to normalize strip markers but on checking the effect I realize that the method is broken. It probably would work as a comparison but it won't display the Expected results correctly because the strip markers have been replaced with fake ones. I'll contemplate what to do about that. Johnuniq (talk) 09:02, 12 December 2020 (UTC)

And...

...the "calculate" template ? EOLE79 (Talk ?) 10:28, 12 December 2020 (UTC)

More than one thousands separator

It would be useful if this template could be used to define the thousands separator differently for each converted unit. For instance, when using the template to convert AU to both km and mi, it would be nice to be able to specify gap for kilometers and comma for miles, as gaps are not usually used for miles but are for kilometers, especially for science-related articles like one using AU. Lexicon (talk) 19:51, 26 October 2020 (UTC)

Could you provide exemplary articles with this? -DePiep (talk) 20:02, 26 October 2020 (UTC)

The use in the third paragraph here is what got me thinking about this. There must be many uses of the template converting AU to km and mi in astronomy articles (there are two more in that one article). How many uses other than for AU there are, though, I'm unsure. Lexicon (talk) 20:15, 26 October 2020 (UTC)

The example from there (without the redundant |lk=off) is:

{{convert|0.1|AU|km mi|abbr=on}} → 0.1 AU (15,000,000 km; 9,300,000 mi)
{{convert|0.1|AU|km mi|abbr=on|comma=gaps}} → 0.1 AU (15000000 km; 9300000 mi)

The second convert shows how it would look with gaps, and here is how it is wanted:

0.1 AU (15000000 km; 9,300,000 mi)

I'm unsure whether that would be useful. Johnuniq (talk) 23:09, 26 October 2020 (UTC)

I question the assertion that gaps are not usually used for miles but are for kilometers. In my experience they're independent issues, and the mixed format above looks wretched. E Eng 23:42, 2 December 2020 (UTC)

The space separator is used in french !

The apos is used in calculators !

EX : 7786554443 is 77 866 554 443 (french) or 77'866'554'443 (calculators). EOLE79 (Talk ?) 10:40, 12 December 2020 (UTC)

That's one of the problems with buying cheap foreign calculators. --RexxS (talk) 22:25, 12 December 2020 (UTC)

The space separator is also used in Australian English.[1] Which shows that it is not an English vs French thing. Stepho talk 23:39, 12 December 2020 (UTC)

I suspect it is not really a miles uses commas vs km uses spaces thing but rather a timing thing. Many countries (such as Australia) changed thousands separators from comma to space about the same time that they change from imperial to metric. Thus, older books used miles with commas and no km at all, while newer books used km with spaces and no miles at all. So, false dichotomy. Stepho talk 23:49, 12 December 2020 (UTC)

"abbr=on" adds units to each number.

Hello, I ran into this (aesthetic) problem on Brick while editing the per-country dimensions of a brick in a table, partially reproduced here:

EXAMPLE TEMPORARILY DISABLED BECAUSE IT WAS SENDING THE RENDERING SOFTWARE INTO ORBIT

Using "lk=on|disp=table|abbr=on" (first row) gives me the unit on each of the measurements. Ideally, I'd like "25 × 50 × 75 mm (1 × 2 × 3 in)", but this doesn't quite work when I try it with other flags.

{{convert|225|×|112.5|×|75|mm|in}} → 225 by 112.5 by 75 millimetres (8.86 in × 4.43 in × 2.95 in)
{{convert|225|×|112.5|×|75|mm|in|abbr=on}} → 225 mm × 112.5 mm × 75 mm (8.86 in × 4.43 in × 2.95 in)

It seems adding "abbr=on" forces the separation to use "×", but also displays the units on every number instead of the last one. I suspect "disp=table" hides the units altogether, but combining it with another flag like "lk=on" or "abbr=on" overrides that. Can we change "abbr=on" to only display units on the final number? This seems inconsistent.-Ich (talk) 16:04, 11 December 2020 (UTC)

MOS:UNITNAMES has some fussy provisions on this which I'm not sure are for the best. In particular, I don't know why it's OK to write 8 by 6 by 4 millimeters but not 8 x 6 x 4 millimeters -- MOS wants you to write, instead, 8 millimeters x 6 millimeters x 4 millimeters, which seems excessive. E Eng 17:05, 11 December 2020 (UTC)
Isn't that only with unit symbols (mm)? Johnuniq (talk) 23:11, 11 December 2020 (UTC)
No, for some reason the guideline wants it to depend not on mm vs. millimeters but rather on x vs. by. With by you're allowed to just say the unit (whether mm or millimeters) once at the end (or every time, if you want), but with x you're supposed to append the unit to every value. Like I said, not sure why it's that way or whether it really needs to be that way. So before changing {convert} to conform (if that's what's your nimble little coding fingers are itching to do) let's be sure the guideline is really what we want. E Eng 23:49, 11 December 2020 (UTC)
Oh. It looks like convert avoids that issue by switching to "by" when the unit name is used. And I'm far too lazy to want to change code that's been stable for eras. Johnuniq (talk) 00:29, 12 December 2020 (UTC)
FOR GOODNESS' SAKE DON'T SAY ERAS. YOU'LL HAVE THE BC/BCE WARRIORS COMING OUT OF THE WOODWORK. E Eng 00:47, 12 December 2020 (UTC)
No need to WP:SHOUT at us, EEng. -DePiep (talk) 22:31, 12 December 2020 (UTC)
I wasn't addressing you so please butt out. [2] E Eng 01:42, 13 December 2020 (UTC)
Why not use {{convert|230|×|110|×|76|mm|in|disp=table}} like most other tables do? The units are in the heading and should not be repeated in each row. There is no need to link mm or inches, but if really needed, there is sure to be somewhere close by in the text (not in the table) where that could be done. Or, the unit names in the heading could be linked. However, convert retains two seldom-used features that are available if really really needed. There is no repeated unit symbol with * or xx. * outputs × with no spacing, while xx outputs × with a nonbreaking space on each side. You would use one of these in a table:
{{convert|230|*|110|*|76|mm|in|lk=on|disp=table|abbr=on}}

{{convert|230|xx|110|xx|76|mm|in|lk=on|disp=table|abbr=on}}

You can add "mm" after each convert if really wanted.

By the way, use x not × in convert. The former is easy to type and easy for other editors to emulate. It gives the same output as ×. Johnuniq (talk) 23:11, 11 December 2020 (UTC)

"sq" vs. "²"

In the lead for Europe, I noticed the slightly jarring juxtaposition of 10,180,000 km² (3,930,000 sq mi), where the kilometers uses "²" but the miles uses "sq". Looking at the documentation here, it seems to be a U.S. vs. UK thing, but from my experience, "²" is generally more popular in America, too. Have we considered just going to "²" for all uses? {{u|Sdkb}} ^talk 07:11, 13 December 2020 (UTC)

For a contrasting view, see Template talk:Convert/Archive 1#The unspeakable criminality of in2 by Archon 2488. Johnuniq (talk) 08:47, 13 December 2020 (UTC)

I'd also make the point that there are slight MOS implications, specifically,

sq or cu may be used with US customary or imperial units, but not with SI units.

This sentence is not prescriptive (or, indeed, proscriptive), but it does explicitly permit the use of "sq" and "cu", and I don't feel that it's appropriate to make changes here that would arguably de facto amount to an MOS change. The Europe article mentioned above uses the style in question, I'd presume, because it is the default convert template style – and I'd argue that making something the default convert template style will almost always ipso facto make it the normal style used in the encyclopedia. This is simply because it's the style that the vast majority of editors will default to, even if unknowingly – I presume that most editors don't know there are so many options for customising the exact output of {{convert}}, as I use it extensively and wasn't aware that it was possible to get it to output e.g. "in²" until very recently.

Obviously this is totally subjective, but I don't personally see this juxtaposition as jarring, mainly because it is the style already used in the vast majority of such cases on WP – as for the historical reasons why the template defaults to that style for presenting square and cubic units, I can't comment. In short, if Sdkb wants to formally discourage the use of "sq" and "cu" in all instances, MOSNUM is the place for them to discuss it. Archon 2488 (talk) 11:48, 13 December 2020 (UTC)

Significant figures, opaque template behavior, and simple arithmetic

An IP user asks about a figure in an article: "Her steel hull had an overall length of 350 feet (110 m) (one source states 358 feet (109 m))" How can 350 feet be 110 m but 358 feet is 109 m? And I say, great question. I look at the article and see that it's getting those values with {{convert}}, videlicet: Her steel hull had an overall length of {{convert|350|ft|m}} (one source states {{convert|358|ft|m}}).

Now, the standard response to this is that precision can be specified when invoking the template, but I don't think this is proper, and especially it's not proper to arbitrarily and invisibly use different rounding based on if the figure ends in a zero. The obvious, and intuitive, use for this template is to do simple arithmetic and multiply feet into meters (indeed, this is how it is used in every article I've seen it). So I had a lively debate with my friend about this, and he pointed out that most uses of "350" or "300" or the like are probably approximate, and giving a precise meter conversion would mislead readers. However, I disagree with the way this has been implemented in the conversion template.

(As someone who's designed and machined parts with some dimensions measured in ten-thousandths of an inch and some dimensions measured in feet, and communicated with both PhDs and CEOs about these parts: when someone writes "350", in the vast majority of cases, it does not mean "350 ± 5" -- and if it does mean the former, they will say "about 350"; the word "about" doesn't have a standardized error bar on it, and I'd almost go so far as to call it WP:OR to imply so.)

But for concrete suggestions: first of all, my issue with this is not the rounding: 350.00 feet is 106.68 meters, which would be a silly amount of precision to give, and I'd be fine with presenting it as 107. I'd even be fine with the template rounding to significant figures whenever precision wasn't specified. However, the current state of affairs is that the template will round to the nearest meter, unless the number ends in a zero, in which case it will silently make the number ten times less precise, in a way that is never made apparent to the editor or the reader.

Exemplis grata:

The building was {{convert|345|ft|m}} tall = "The building was 345 feet (105 m) tall"
The building was {{convert|350|ft|m}} tall = "The building was 350 feet (110 m) tall"
The building was {{convert|355|ft|m}} tall = "The building was 355 feet (108 m) tall"
The building was {{convert|360|ft|m}} tall = "The building was 360 feet (110 m) tall"

If you were an editor and hadn't read five full screens of template documentation (or if you're a Wikipedia reader, who doesn't even know what templates are), would this make sense to you if you saw it in a page? Would it be immediately apparent, if you only saw one of these examples, that every other measurement was being rounded to the nearest 10m and not the nearest 1m?

I think that this is fairly counterintuitive; if the default behavior is to perform different conversions based on the last digit of the number, it should say "approx." or in some way indicate when it's using an alternative conversion scheme. A template should not be making blanket assumptions about the precision of numbers in articles and presenting them as fact. jp×g 01:54, 10 December 2020 (UTC)

It's not an easy problem. For example, Oklahoma#Transportation uses {{convert|12000|mi}} in the second paragraph which starts with "More than 12,000 miles (19,000 km) of roads". Rounding to the nearest km would give "More than 12,000 miles (19,312 km) of roads". While there are examples of convert's default behavior giving bad results, there are plenty more where the results are good. If someone unfamiliar with the template wonders why silly numbers are being shown (such as in the above), they can ask here or at WP:HELPDESK for assistance. Johnuniq (talk) 03:52, 10 December 2020 (UTC)

@JPxG: You've criticised the way the template handles a problem, but your solution is even worse. Almost all conversions are approximate and scattering "approx" about written prose is very poor style. if you assert that 350 ft has three significant figures and should be treated as 350±1 ft by default, then what should be the default precision for 3500 ft? for 35000 ft? and so on. If you are willing to accept that 35,000,000 ft doesn't imply 35,000,000±1 ft by default, but you still insist that 350 ft has three significant figures, then at what point are you willing to concede that one of those decade multiples has only two significant figures? If you can find an algorithm for determining significant figures that is more robust than "trailing zeros are not significant in integer values", it would useful to hear it. Note that:

The building was {{convert|358|ft|m}} tall = "The building was 358 feet (109 m) tall"
The building was {{convert|350.|ft|m}} tall = "The building was 350 feet (107 m) tall"

Specifying a decimal value sets the full precision.

Then consider decimal fractions:

The model was {{convert|3.45|ft|m}} tall = "The model was 3.45 feet (1.05 m) tall"
The model was {{convert|3.50|ft|m}} tall = "The model was 3.50 feet (1.07 m) tall"
The model was {{convert|3.55|ft|m}} tall = "The model was 3.55 feet (1.08 m) tall"
The model was {{convert|3.60|ft|m}} tall = "The model was 3.60 feet (1.10 m) tall"
The model was {{convert|3.5|ft|m|sigfig=3}} tall = "The model was 3.5 feet (1.07 m) tall"
The model was {{convert|3.6|ft|m|sigfig=3}} tall = "The model was 3.6 feet (1.10 m) tall"

The default does a pretty good job most of the time, but it's not difficult to set the precision when the default doesn't give the result you want. --RexxS (talk) 15:39, 10 December 2020 (UTC)

I can add, re your post @JPxG: "designed and machined parts" -- yes, basically but a) why would your shop use two unit sets (metric and ft,in) at all? Isn't that installing Murphy's law? (warn your CEO, now). And b) this is an encyclopedia, not a WP:HOWTO manufacture parts. That is: don't build your rockets from this webside. -DePiep (talk) 18:06, 10 December 2020 (UTC)

For many years, if not today, the US auto industry used both. You had to have both sets of wrenches, as you didn't know which one would be needed. If I remember the story, the Chevette was the first US car to be all metric. If some president decides to convert the US to metric, we might be in better shape in not so many years. I was recently working on Turbofan, which has tables of engine thrust to five digits. How could that be? I asked the EASA who produced the document. It turns out that they take the numbers in lbf, round to a multiple of 10, and convert to daN. (That is dekanewton, in case you didn't guess.) After the conversion, four digits isn't enough and five is too many, but in any case they go to five. 10lbf is about 4.4 daN. There is no easy answer when using sigfigs. Gah4 (talk) 00:26, 13 December 2020 (UTC)

I've also struggled with this for years but it's not a simple problem to solve. My use of convert is mostly for cars - where 350 always means 350±1. But I also recognise that other subjects use bigger numbers where 35,000 often means 35,000±500. Solutions are:

Let convert figure it out by how many zeroes are at the end (eg, 1 or 2 zeroes means treat it as exact, otherwise heavy rounding). A daunting task. There is no way for the template to handle the grey areas without making somebody unhappy. Unworkable.
Take it as exact and allow specific instances to choose larger rounding. Awkward for articles dealing with big numbers.
Always do heavy rounding according to zeroes at the end and allow specific instances to choose the precise level of rounding. Personally, I habitually put |0 or |1 or |round=5 at the end of most conversions for car articles.

My preference would be #2 but really both #2 and #3 are valid solutions with similar pros and cons. We can't make everybody happy and the current solution is a very good attempt at making as many people as happy as possible. The only improvement I can think of is to make the rounding issue more prominent in the documentation. Stepho talk 00:56, 13 December 2020 (UTC)

But my personal use of convert is likely to be in scuba-related articles, where 350 bar means 350±5 bar and 350 feet means 350±5 feet. If we stick with the current algorithm, the conversions work well for me, and you only need write "350." to force unit precision. If we adopt an algorithm that treats 350 as 350±1 to suit your preference, the conversions work well for you, but I don't have anywhere near as simple a means of getting the precision I need. It's not a symmetrical gain-loss. --RexxS (talk) 01:27, 14 December 2020 (UTC)

Ton-miles

This was previously request (Template talk:Convert/Archive October 2015#Ton-mile and passenger-mile) but, as far as I can tell, never implemented. 1 ton-mile = 1.459972 tonne-kilometers. (see Units of transportation measurement) Would it be possible to implement this conversion? Hawkeye7 (discuss) 19:42, 17 December 2020 (UTC)

My comment in the linked October 2015 discussion still applies—quite a lot of confusion is possible with short/long/metric tons. A firm proposal is needed: unit codes (wikitext entered in convert); full names of units (abbr=off); symbols of units (abbr=on); links (lk=on). Is there more than one or two articles where they would be used? The references used at Units of transportation measurement appear to be dime-a-dozen unit converter websites which are happy to make up names and symbols. Is it just short-ton-miles to tonne-kilometers that is wanted? If so, we could add a temporary unit and see if it is used, but details are needed. Johnuniq (talk) 22:22, 17 December 2020 (UTC)

Just ton-miles to tonne-kilometres. When dealing with road, rail, air or IWT, ton miles are always short tons per statute mile. It is not used in the UK. [3] A Google search restricted to Wikipedia turned up 190 pages. All are related to railways. I got my conversion from the Bureau of Transportation Statistics. In the rare cases when one is dealing solely with shipping, they used deadweight (long) tons per nautical mile. [4] But I haven't observed any instances of this on wikipedia. Hawkeye7 (discuss) 23:17, 17 December 2020 (UTC)

OK, let's do that. But, please propose unit code, symbol, name, link for each. I can handle the kilometre/kilometer issue, and you have specified names. Should there be a symbol (abbr=on)? There does not have to be, but if one is wanted, please specify it. Same for the unit code that would be entered in convert. Is Units of transportation measurement#Freight the link? I wouldn't try to make the section link more specific because it's title is likely to change every month. Johnuniq (talk) 23:25, 17 December 2020 (UTC)

There is a stub article gross ton mile. The olde abbreviation seems to be TM. (I would go without it, as none of the articles use it, and it isn't well known.) The metric is tonne-kilometre (abbreviation tkm) [5]. Tonne kilometer is a redirect to Units of transportation measurement#Transportation quantity. Hawkeye7 (discuss) 00:59, 18 December 2020 (UTC)

I added the units at Module:Convert/documentation/conversion data#Transportation and included them in the module. If these are used in articles in the next couple of days (before the #Module version 25 release above), they will be included in the main data. Otherwise, they will be temporary. Examples (please check!):

{{convert|1|tkm|6|abbr=on}} → 1 tkm (0.684944 ton-miles)
{{convert|1|ton-mile|6|abbr=on}} → 1 ton-mile (1.459972 tkm)
{{convert|1|tkm|abbr=off}} → 1 tonne-kilometre (0.68 ton-miles)
{{convert|1|ton-mile|abbr=off}} → 1 ton-mile (1.5 tonne-kilometres)
{{convert|2|tkm|abbr=off|lk=on|sp=us}} → 2 tonne-kilometers (1.4 ton-miles)
{{convert|2|ton-mile|abbr=off|lk=on|sp=us}} → 2 ton-miles (2.9 tonne-kilometers)

Johnuniq (talk) 02:40, 18 December 2020 (UTC)

@Hawkeye7: I'm hoping to update convert soon and would prefer to include the new unit, but first it needs to be checked, and it needs to be used in an article. Do you have time for that? Johnuniq (talk) 23:02, 18 December 2020 (UTC)

Sure. I have used it in American logistics in the Northern France campaign. It performed the conversion and the rounding correctly. Very nice.

Hawkeye7 (discuss) 05:54, 19 December 2020 (UTC)

Module version 25 (see May 2021 for release)

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

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

Template styles (work by Izno):
- When convert displays fractions, a certain style is used that make it easier for a screen reader to provide informative text. That style is now in Template:Screen reader-only/styles.css.
- The implementation inserts the templatestyles 42-byte strip marker at the start of the convert output, but only if required for the fraction being displayed and only once per convert even if more than one fraction is displayed (for example, {{convert|1+1/2|by|5+3/4|in}}).
Unit changes:
- Remove gramme from the unit definitions. This is not a change to units as gramme is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future. MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at MOS talk July 2019 following a request here.
- Remove 23 apparently unused energy units linking to Atmosphere (unit) per discussion here.
- Some units from Module:Convert/extra that are used in articles have been copied to the main module.
  - mi/kWh is retained in extra; it will be removed if not found to be used in articles.
  - Occurrences of scf2 and scfoot2 in articles will be replaced with scf and scfoot which have had their link corrected to standard cubic foot. Discussion here.
Tweaks:
- Module:Convert/wikidata will use mw.wikibase.getLabel(X) instead of deprecated mw.wikibase.label(X).

Release notes for earlier versions are listed here. Johnuniq (talk) 06:13, 14 December 2020 (UTC)

A couple of questions: Just wondering if the 'Screen reader-only/styles.css' should be stored in a variable in Module:Convert/text to help with use on another wiki? Also, "padding" was changed to "margin" a while ago [6] in {{Sfrac}}. Should it be changed in convert as well? -- WOSlinker (talk) 08:50, 14 December 2020 (UTC)

Thanks, good points. Re convert/text, I did wonder about that and I suppose I should be less lazy. I imagine "margin" should also be used here but the html is over my head. @Izno: Any opinion on that?

Here are some results from Special:ExpandTemplates if anyone wants to compare the outputs.

{{convert/sandbox|1//2|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">1</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">2</span></span> foot (6.0&nbsp;in)

{{sfrac|1|2}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac  nowrap tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">1</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">2</span></span>

{{sfrac/sandbox|1|2}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac tion"><span class="num">1</span><span class="sr-only">/</span><span class="den">2</span></span>

{{convert/sandbox|1+2//3|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap">1<span class="sr-only">&nbsp;</span><span style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">2</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">3</span></span></span> feet (20&nbsp;in)

{{sfrac|1|2|3}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac  nowrap"><span class="int">1</span><span class="plus sr-only">+</span><span class=" tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">2</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">3</span></span></span>

{{sfrac/sandbox|1|2|3}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac ">1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span></span>

Johnuniq (talk) 09:43, 14 December 2020 (UTC)

I have updated the modules to get the templatestyles title from convert/text for localization at other Wikipedias. The style issue is tricky. The output from {{sfrac}} is roughly 64 bytes longer than for convert: it's got more stuff. I have no idea if there is a good reason for that. I'd better delay release while thinking about that, and should check {{frac}} also. Johnuniq (talk) 23:35, 14 December 2020 (UTC)

As a result of your delay here (thanks :D) I've lately been futzing with moving the styles in frac and sfrac fully into TemplateStyles, which are combined in Template:Frac/styles.css with direct implementations in Template:Sfrac/sandbox and Template:Frac/sandbox. (I've coincidentally removed sub/sup in frac; their use there is not really that appropriate from an HTML perspective.)

Given the domains of the two templates seem exclusive, I have not decided if it makes sense to have one style sheet for them rather than two, but I only simplified what was there, since someone had started taking a look a year ago and seems to have given up on the point for some reason. (It was a rather complex implementation to boot since it assumed the templates were needed for more than they are.)

Consider taking a look. I am not per se minded to make them live immediately, but... I kind of am. :^) --Izno (talk) 03:40, 15 December 2020 (UTC)

I've just spent over half an hour staring in bewilderment at those pages (including your drastic pruning). Experiment found that the output from sfrac was 80 bytes longer than the corresponding output from convert and the need for all those classes is way beyond my comprehension. I decided that Edokter knew what he was doing so replaced "padding" with "margin". I couldn't see any reason for further changes in convert. I'm not sure whether you are hinting that Template:Frac/styles.css should be used by convert. I suppose there aren't that many converts using fractions (although there are a lot) so the templatestyles bloat might not be a problem. But it's extra pain for people trying to copy the current version of convert to another site. Are you wanting more changes to Module:Convert/sandbox or is what it does ok at least for now? That is, should the live convert modules be updated now? Johnuniq (talk) 04:28, 15 December 2020 (UTC)

You can save a little more space by removing the spaces after the semi-colons in the styles, so I've done that in the sandbox. -- WOSlinker (talk) 08:12, 15 December 2020 (UTC)

I'm not sure whether you are hinting that Template:Frac/styles.css should be used by convert. Yes, I'm hinting that. It is by no means required of course, but it should dramatically reduce the implementation here (+- the futzing to make sfrac act as expected because I noticed how it is coded in the frac templates and how it is coded here is marginally different).

But it's extra pain for people trying to copy the current version of convert to another site. I've never really put a lot of stock in this as a rationale for anything on en.WP, and not often do I care too often when the module of interest already has a dozen pages to copy; what's one (two?) more? So long as the documentation is clear about all the used pages (as is usual for larger modules), it's rarely an issue.

is what it does ok at least for now I have no great issues with the now. I do have some issue with the frac implementation, both live/sandbox here and at the template itself, using and , and that is why I suggested the sandbox version there to be implemented here now. If you want to play with it some more or want some help understanding what's going on, I wouldn't want to block version 25 on it. --Izno (talk) 18:44, 15 December 2020 (UTC)

As for all the classes, each of them has a reason and it can be seen in the stylesheet itself. They were added a year ago by the user aforementioned in preparation for templatestyling but the templatestyles were never implemented for whatever reason. I did remove two in the sandbox as being essentially immaterial ("plus" and "slash") and then the styles followed into the stylesheet, hence the 'dramatic' reduction. For comparison, I've added the sfrac/sandbox expansion above. --Izno (talk)

I would far prefer to get convert right before releasing a new version. Indeed, the only substantial reason for this release is to clean up fraction handling so let's take a bit more time. Currently, convert/sandbox is using Template:Screen reader-only/styles.css for class sr-only. As I understand it, that would no longer be needed. Instead, Template:Frac/styles.css would be used and much of the HTML in convert would be replaced with css. I'll have a go at that in a few hours or you may like to do it. In ⁠123⁠, why does convert output a hidden non-breaking space after 1, but sfrac outputs a hidden + (what should convert do)? For my curiosity, what is role="math"? Johnuniq (talk) 23:22, 15 December 2020 (UTC)

About the "+" in sfrac -- only. I don't know about screenreaders ("sr"), but the copy/paste function ("A c/p must produce the same and correct number") should be (ob)served too.

{{frac}}: 1+11⁄19 → c/p gives: 1 11⁄19
{{sfrac}}: ⁠1+11/19⁠ → c/p gives: 1+11/19

-DePiep (talk) 00:22, 16 December 2020 (UTC)

Ping User:Izno because of [7]. -DePiep (talk) 00:33, 16 December 2020 (UTC)

CSS is not my area so I'm hoping Izno will either fix convert/sandbox or tell me what is wanted. There are three factors: (1) want reasonably short wikitext with a consistent and good displayed result; (2) want it to make sense with screen readers; (3) want copy/paste to give a sensible result. The new Template:Frac/styles.css looks good to me. The generated HTML is a bit long for the first usage on a page, but is not a problem because subsequent usages on that page are short. I can see an argument for space or plus in a copy/paste and I don't see it as a concern, although consistency would be good. Johnuniq (talk) 10:22, 16 December 2020 (UTC)

As I understand it, that would no longer be needed. Yes, that is correct.

In ⁠123⁠, why does convert output a hidden non-breaking space after 1, but sfrac outputs a hidden + (what should convert do)? I do not know why convert is doing that as a non-breaking space, which is superfluous with the whitespace nowrap CSS variously applied to the same. Regarding space versus plus, sfrac shifted to "+" approximately a year ago in the same edit that added the classes and role. It was noted at the talk page at Template talk:Frac#Integrity. I changed the frac sandbox recently to follow since I don't see a good reason for inconsistency. I could personally flip a coin on the pros and cons of + and space character, though I tend toward the semantic + rather than the unsemantic space as my decider. I generally agree with your 3 listed design criteria there.

For my curiosity, what is role="math"? An "ARIA role" is a standardized way to assign an HTML element semantics that differ from its default semantics. For example, if you have a layout table, you can assign it role="presentation" to indicate that it is not a proper data table per the default HTML semantic assignment for <table> elements (we have a lot of unfortunate legacy on that point, so we've bolted on a lot of role="presentation"). It is primarily intended for enhanced accessibility. See also MDN. role="math" in particular is described as Content that represents a mathematical expression. See the link for more details. Whether sfrac and frac should use it is a question mark to me. Given the context of sfrac, I think it may make sense for sfrac generally. For frac, I can probably buy into it when the fraction is marked up with a hidden +. I wouldn't add it without the + in frac. --Izno (talk) 21:34, 16 December 2020 (UTC)

Thanks for the explanation. That encouraged me to read a bit more about css and I now have an idea of what Template:Frac/styles.css is doing. I updated Module:Convert/sandbox to output the same as {{frac/sandbox}} and {{sfrac/sandbox}}. However, I haven't tested it and need to have at least 24 hours of clear time to ponder how the new code will work with all the strange situations here and at other languages. Following is a test. Johnuniq (talk) 09:29, 17 December 2020 (UTC)

{{convert/sandbox|1/2|ft|in}} → 1⁄2 foot (6.0 in)
{{convert/sandbox|1+2/3|ft|in}} → 1+2⁄3 feet (20 in)
{{convert/sandbox|1//2|ft|in}} → 1/2 foot (6.0 in)
{{convert/sandbox|1+2//3|ft|in}} → 1+2/3 feet (20 in)
{{frac/sandbox|1|2}} → 1⁄2
{{frac/sandbox|1|2|3}} → 1+2⁄3
{{sfrac/sandbox|1|2}} → ⁠1/2⁠
{{sfrac/sandbox|1|2|3}} → ⁠1+2/3⁠

Vertical spacing

@Izno:: Please see the experiment in my sandbox (permalink). That shows quite a large difference in the vertical space occupied by the old and new styles of formatting fractions. I'm wondering if using a fraction (with {{convert}} or {{frac}}) might introduce a visually unpleasant vertical gap in the line spacing. Any thoughts? Johnuniq (talk) 09:49, 19 December 2020 (UTC)

Oh dear. E Eng 14:37, 19 December 2020 (UTC)

The problem is that ... and ... are setting line-height to 1em (which is rendered as 10.16px on my Monobook skin). The corresponding classes .num and .den in the sandbox leave the line-height at default, which is 1.5em (rendered as 19.05px on my Monobook skin because the em is also different for the two cases). The two parts of the fraction poke above and below the line of the rest of the text, so need a smaller line-height to prevent the gaps you are seeing. I don't want to fiddle with your stylesheets, but I think that reducing the line-height for the .num and .den classes by about 50% somehow will ease the problem for you. Cheers --RexxS (talk) 20:59, 19 December 2020 (UTC)

Thanks EEng and RexxS but I can't quite interpret your responses. Let me clarify that I'm wanting to wrap this up and so was doing various tests when I noticed the spacing issue. It looks a little odd to me but perhaps it's unavoidable (or, avoiding it would introduce other problems). Do you think the vertical spacing is a problem that needs to be fixed? The point is that if the new convert is released, over a million pages will be put on the job queue. Then if Template:Frac/styles.css is tweaked a week later to fix the spacing, the same pages will be processed again which seems unkind. Johnuniq (talk) 00:55, 20 December 2020 (UTC)

Oh, dear = How unfortunate, unsightly, and best remedied if possible. E Eng 05:28, 20 December 2020 (UTC)

The Reading Eye is very sensitive to lineheight. It can and will surely notice the height diff in running lines when one has this fraction applied. The demo provided says it is a notable (visible) enheightening. So IMO, it is worth improving (e.g., using Rexx's post) over early rollout. -DePiep (talk) 01:16, 20 December 2020 (UTC)

I've created Template:Frac/sandbox/styles.css with the two changes needed to make the two columns in User:Johnuniq/sandbox2 display the same. I don't know whether that change would be acceptable to Template:Frac/styles.css as I don't know where else it is in use. I guess Izno would know best. Optionally, if you wanted to make sure that "12⁄3 feet (20 in)" doesn't increase the line spacing in running prose (as it does here), you could wrap convert's fractional outputs in a custom class like "cvt" so you would code span class="cvt frac nowrap" for four extra bytes, then you would create .cvt .frac .num { line-height: 0.5em; } and .cvt .frac .denom { line-height: normal; } in Template:Frac/styles.css so that the adjusted line spacing would only apply to the output of convert. In any case, it's commendable to worry about the load on the servers, but we don't pay them on piece-work rates, so it's not going to hurt if you put an extra job in the queue once in a while. --RexxS (talk) 01:33, 20 December 2020 (UTC)

I edited the sandbox convert to use the sandbox styles and have used subst so they continue to use the styles shown.

Please compare these two pages. The latter is working perfectly, thanks RexxS. Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst. Another weirdness is that I see a small vertical gap after the first "It's a long way to the next town." (that gap was always there but I couldn't see a reason for it). Johnuniq (talk) 02:54, 20 December 2020 (UTC)

Hmm, obviously the latter will overrule the former because the styles have the same name. I'm beginning to understand... Johnuniq (talk) 03:09, 20 December 2020 (UTC)

The gap between the first and second items in any table cell occurs because the MediaWiki software renders the first item as a bare span inside the td, but then wraps the rest of the content of the td inside a paragraph. The spans have no margin, but the paragraph has a top and bottom margin of a few pixels; hence the gap. That's exactly right about the styles (they are cascading, i.e. later definitions override earlier ones). Cheers --RexxS (talk) 09:59, 20 December 2020 (UTC)

Ah, ye old paragraph wrapping. --Izno (talk) 17:13, 20 December 2020 (UTC)

Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst. Indeed, this is expected; see Rexx. There is a way to work around it that is kind of a pain (setting the sandbox templatestyles invocation to add the attribute wrapper=".sandbox" as in <templatestyles src="Example/sandbox/styles.css" wrapper=".sandbox"/> and then wrapping some content in the same page as your other case with the sandbox class). See mw:Extension:TemplateStyles#Usage. --Izno (talk) 17:13, 20 December 2020 (UTC)

I was away from a PC yesterday. I'm not surprised this was a line height issue; I was seeing it in some of the default style sheets out there for browsers for sub/sup and wasn't strictly certain why. Thank you for testing!

I am still thinking I'd like to break up the frac and sfrac stylesheets into two since I do not anticipate it often being the case that someone will use them both on a page, given the use instructions for both. The costs for two sheets where they are used on the same page are negligible, and there will be a savings in the relevant budget for the vast majority where they are not.

RexxS, it is in use nowhere else at this time, so no sandbox page was required. :) It is nice for comparison by multiple people though. --Izno (talk) 17:13, 20 December 2020 (UTC)

It now becomes a splitter vs. lumper debate. Splitting gives a smaller style sheet focused on a single issue (frac or sfrac, not both). There would be duplication with .sr-only in each (if that was split out as well, each fraction usage would need to output two strip markers). Someone editing one split page might not get around to making corresponding adjustments in the other. On the other hand, lumping puts everything together with the cognitive load of staring at a page trying to do two different things and the slightly increased HTML output if only one is needed (a frac-only style would be around 300 bytes, while a frac-and-sfrac style would be about 560). Johnuniq (talk) 02:49, 21 December 2020 (UTC)

Range and adjective

How may I combine conversion, range, and adjective? For example, I am attempting to write "300-by-500-foot-wide (984 to 1641 m)." CapeVerdeWave (talk) 17:26, 19 December 2020 (UTC)

Do you really want by...to? Convert can do this:

{{convert|300|by|500|ft|m|adj=on}} → 300-by-500-foot (91 by 152 m)

Johnuniq (talk) 22:30, 19 December 2020 (UTC)

I'm trying to imagine what 300-by-500-foot-wide even means, much less how by + wide somehow become to. E Eng 05:32, 20 December 2020 (UTC)

I apologize. I meant 300-to-500-foot-wide (984 to 1641 m), with "-wide" attached to the end. CapeVerdeWave (talk) 08:35, 20 December 2020 (UTC)

(984 m?). Then:

{{convert|300|to|500|ft|m|adj=on}} → 300-to-500-foot (91 to 152 m)

{{convert|300|to|500|ft|m|adj=mid|-wide}} → 300-to-500-foot-wide (91 to 152 m)

from doc: A_10-foot-long_corridor. -DePiep (talk) 09:35, 20 December 2020 (UTC)

FTR I wonder if the example was meant to be 300-to-500-metre (980 to 1,640 ft) (and here we encounter the rounding conundrum once again). E Eng 18:04, 20 December 2020 (UTC)

Would explain the numbers :-). Who's gonna build the demo? -DePiep (talk) 18:31, 20 December 2020 (UTC)

@CapeVerdeWave: in case you have swapped the units inadvertedly, as your numbers indicate (manual input), here is the reverse version:

{{convert|300|to|500|m|ft|adj=on}} → 300-to-500-metre (980 to 1,640 ft)

{{convert|300|to|500|m|ft|adj=mid|-wide}} → 300-to-500-metre-wide (980 to 1,640 ft)

-DePiep (talk) 06:59, 24 December 2020 (UTC)

Module:Convert/helper: use Lua decode (© → ©)?

Module:Convert/helper does some pre-Convert input cleanups. For this it also replaces, for example, &frasl; with /: good. This simplifies later string handling jobs like search&replace, etc. See this code:

text = text:gsub(' ', ' '):gsub(' +', ' '):gsub(' *%+ *', '+'):gsub('⁄', '/'):gsub('⁄', '/'). All fine so far.

Now Lua has a function that replaces these &...; html entities (character id's), all in one go: mw.text.decode. (which is available through Module:DecodeEncode; by me; pre-alpha).

So I'd ask you to consider: could this be an improvement? Sure it's only efficiency & systematic completeness, not squashing a bug. And maybe the pre-apha status is to be looked at. -DePiep (talk) 23:44, 25 December 2020 (UTC)

If something is needed it can be added. However I'm not sure mw.text.decode would give good results. It changes   to   and does not change &frasl;. I put a test at Module:Sandbox/Johnuniq/temp—see results at its talk where a mid dot (·) is used to replace each space. Johnuniq (talk) 01:29, 26 December 2020 (UTC)

(removed, my bad text) -DePiep (talk) 01:36, 26 December 2020 (UTC)

Very strange, & does not fit with mw:doc AFAIK. More research needed. Later more. -DePiep (talk) 02:10, 26 December 2020 (UTC)

Proper counterpart unit for acres: is there a consensus?

With most large areas, I'm used to seeing acres "traditionally" paired with hectares. Lately, however, I've been seeing more and more instances paired with square kilometers instead. Has there been a consensus reached (or changed) regarding which unit acres should be paired with? I just wondered; I'm not sure if this is the best place to ask, but I also don't know where else that would be.

Are there situations where one unit or the other is preferred? Or are hectares now considered "archaic"? :)

Thanks! 1980fast (talk) 02:19, 24 December 2020 (UTC)

The default output unit for acre is ha. For example, {{convert|123|acre}} shows 123 acres (50 ha). Where do you see km2 (square kilometers)? There is no preference or consensus adjustment at this page, but it's possible that people in one region are used to ha while those somewhere else see km2. Johnuniq (talk) 02:55, 24 December 2020 (UTC)

@Johnuniq: To answer your question, and to provide context for others as to what prompted me to ask the question, an example of what I'm talking about can be seen here, in the "Notable wildfires" subsection (I'm not sure why I can't link directly to it, but that's a question for somewhere else). There are several uses of km2, where I would have expected hectares. 1980fast (talk) 03:42, 28 December 2020 (UTC)

Santa Barbara, California#Notable wildfires contains four converts, three of which concern areas and are like {{convert|67000|acre|km2}} with different numbers. An editor has chosen to specify that the output should show the km² value by specifying km2 as the output unit. That choice is an editorial matter which is outside convert's scope. If the area is wanted in hectares, replace km2 with ha or omit |km2. People have outlined the factors involved in making a choice in this section. All converts concerning area in that article (there are seven of them) show the output in km². Johnuniq (talk) 03:59, 28 December 2020 (UTC)

Seems to me that one might use square kilometers for larger areas, at least double digit square kilometers. But some large farms might be that big. For areas of countries, I think US would use square miles not acres. Gah4 (talk) 03:54, 24 December 2020 (UTC)

The proper counterpart of the acre is the hectare. Hawkeye7 (discuss) 04:13, 24 December 2020 (UTC)

The hectare is not an SI unit, of course; the SI unit of area is the square metre. However, SI units of length don't favour decametre and hectometre, so the jump from square metres to square kilometres is a factor of 1,000,000 to 1. That means that common parcels of land are either a tiny fraction of a square kilometre or a large multiple of square metres. So there is a need for a simple unit for those sort of sizes of area and the acre in imperial or hectare in metric found common use (the same reason why we commonly use the litre for volume). Since they are about the same order of magnitude – compare: 1 square kilometre (100 ha; 250 acres; 1,000,000 m²) – it makes sense to pair acre with hectare because they will find common usage for the same sort of area. Any SI pedants will naturally prefer to restrict conversions to SI units, and that may be the effect seen by 1980fast. Cheers --RexxS (talk) 20:13, 24 December 2020 (UTC)

Speaking only for my own personal experience (as a middle age, city born, Australian), we either use m² for the small stuff (eg, my house and immediate surroundings of 700 m²) or km² for the big stuff (eg, an entire city, a cattle station or a country). Middle stuff chooses whichever looks more manageable. I can never remember how big a hectare is because I never see anything listed that way. Stepho talk 21:54, 24 December 2020 (UTC)

A 15-acre (0.061 km²; 61,000 m²) farm must be awkward to deal with (extreme middle aged, urban, English). --RexxS (talk) 23:52, 24 December 2020 (UTC)

True, that's an awkward size for me. I can only say that us city-slickers rarely deal with small farms. Or if we do then we drop back to ancient units like acres. Stepho talk 00:45, 25 December 2020 (UTC)

The question is what is the preferred default counterpart for 'acre'?. Full stop. (not: what unit are you familiar with?). AFAIK, 'acre' is used in the very same circumstances as 'hectare' is: farming and real estate, and not geography. Anyway: similar in most cultural regions.

We are to *falsify* this by naming situations (culture, professions, habits, ...) where acre is used, but not hectare in parallel culture—and vice versa. And then again: even if these situations exist, meaningful & convincingly, it's just a default so what's the problem? IOW, if in profession X 'acre' translates to 'm2', then skip the default by entering m2. -DePiep (talk) 00:31, 26 December 2020 (UTC)

The Commonwealth Style Guide says to use hectares, and we always do. It is very common. As DePiep says, it is used for real estate like farms. eg [8] It is a metric unit but not an SI unit. Note that square kilometres is not an SI unit either. We use hectares to describe a 15-acre (6.1 ha) property. The acre was a measurement of area equal to a furlong times a chain; hence 640 acres to the square mile. It has not been used in Australia for half a century. Hawkeye7 (discuss)

If it matters, editors may add "km2" when the occasion demands: compare {{convert|10000|acre}} = 10,000 acres (4,000 ha) v {{convert|10000|acre|km2}} = 10,000 acres (40 km²). Retain the current behaviour as being the most common requirement for the template (outside Texas, of course). --John Maynard Friedman (talk) 12:02, 26 December 2020 (UTC)

@Hawkeye7: In what sense is the square kilometre not an SI unit? Of course it is, just as any other SI unit with a multiplier prefix. See SI prefix. --RexxS (talk) 21:23, 26 December 2020 (UTC)

Exactly! And that's why the SI pedants insist that it is all wrong. A km² is not a thousand square metres as is implied by the notation (k always being 1,000) but a million. Hawkeye7 (discuss) 23:05, 26 December 2020 (UTC)

But all SI units of area (or volume) work like that consistently, without exception. A km² is a thousand metres by a thousand metres, and nobody has ever claimed it was anything else. --RexxS (talk) 01:13, 27 December 2020 (UTC)

When I was a kid, the fields were typically measured in Morgen (2500 m²; unit symbol Mg); I reckon this is what the metric (not SI!) counterpart of an acre would be. However, everyone understands what a hectare is, and Morgen is only used in rural areas nowadays. Best regards, --Johannes (Talk) (Contribs) (Articles) 22:00, 26 December 2020 (UTC)

"everyone understands what a hectare is", don't make assumptions. I cannot visualise what a hectare is, and either mentally dismiss it as "several acres" or else go and look for a conversion. A square kilometer on the other hand is slightly larger than 1⁄4 square mile which is good enough. In passing it does rather amuse me that the SI enthusiasts react with horror at any mention of non-metric customary units and yet plead intensely for metric but non-SI customary units! Think of a sentance including "sauce", "goose" and "gander". :-) Martin of Sheffield (talk) 22:32, 26 December 2020 (UTC)

A hectare is 100 metres x 100 metres. That's easy to visualise. A cricket oval like the MCG is two hectares. A square kilometre is much larger. I visualise it as 100 hectares. In the case of the acre (because I'm a military historian, I often come across the old measurements) I remember that a chain is a cricket pitch and that a furlong is ten of them. An acre is then easy to visualise. In the UK they still measure road distances in miles, which is probably why you can remember them but here the mile has become a figurative term for an immense distance. Hawkeye7 (discuss) 23:05, 26 December 2020 (UTC)

…I meant where I was raised everyone understands what a hectare is, and people typically use it. The "core message" though was that I believe that a Morgen is the "metric equivalent" to an acre if used for a field, but that people usually don't use it. But to answer the initial question: Where I live, as a rule of thumb, a hectare or square hectometre (hm²) is used for areas the size of a typical field, and anything larger than a typical field is expressed in square kilometres (km²). For example, fields, airfields, football fields, small woods and so on are expressed in hm², whereas large forests, settlements, huge areas of land, countries, continents, and planet surfaces are expressed in km². Best regards, --Johannes (Talk) (Contribs) (Articles) 03:43, 27 December 2020 (UTC)

@Hawkeye7: and interestingly, in the UK, distances along railway lines are measured in miles and chains. Convenient units still find a use. --RexxS (talk) 17:27, 27 December 2020 (UTC)

... and even more interestingly, all railway engineering in the UK for at least the past 20 years, probably nearer 50, measures everything in km, metres, tonnes, cubic metres etc. --John Maynard Friedman (talk) 19:54, 27 December 2020 (UTC)

When I was a kid, railway track was measured in miles and chains. However, where I live now, people don't know chains, and the mile is used exactly as Hawkeye7 described. In German-speaking countries, railway track is measured in hectometres (hm); this way, the train drivers can see very conveniently where they are (there is a hectometre post every hectometre). Howver, in the signaller language (both written and spoken), kilometres (km) with three digits after the decimal separator are used. Track length in stations (for shunting etc.) may also be given in metres (m). Best regards, --Johannes (Talk) (Contribs) (Articles) 23:57, 27 December 2020 (UTC)

Display order priority of SI units and non-SI units

How about the priority of SI units and non-SI units?
What to do if a existing table uses the non-SI values and calculates them into SI units? --Angerdan (talk) 14:53, 1 January 2021 (UTC)

As I understand it, the order displayed by this template depends on how the editor writes the template invocation. What the order should be is a matter for Wikipedia:Manual of Style/Dates and numbers. Jc3s5h (talk) 15:05, 1 January 2021 (UTC)

The input value and unit should always match that given in the reference, in order to help verification. But the order in which they are displayed can be changed using |order=flip or |order=out. WP:UNITS says SI first is used for most articles, with exceptions for some US and UK articles. Stepho talk 22:53, 1 January 2021 (UTC)

Engine volumes

In the US modern engine volumes are often in liters or cubic centimeters, which are often converted to cubic inches, but it does not appear that either is a allowed conversion. Can this be added to the template?--Sturmvogel 66 (talk) 14:05, 26 December 2020 (UTC)

From Help:Convert units#Volume: cuin, cc, L. Will this do?

{{convert|1300|cc|cuin}} → 1,300 cubic centimetres (79 cu in)

{{convert|95|cuin|L}} → 95 cubic inches (1.56 L)

-DePiep (talk) 14:14, 26 December 2020 (UTC)

I should have been more specific in that I need a liters to cubic inches conversion as WWII-era propeller engines have volumes up to 40-odd liters and nobody uses cc for them.--Sturmvogel 66 (talk) 14:55, 26 December 2020 (UTC)

Litres to cubic inches then would be, by basic {{Convert}} workings:

{{convert|44|L|cuin}} → 44 litres (2,700 cu in)

OK? (or else, linking to an article would help). -DePiep (talk) 16:29, 26 December 2020 (UTC)

And add |sp=us for "liter" spelling if appropriate for article. Johnuniq (talk) 22:16, 26 December 2020 (UTC)

Right, IIRC, the chart listing the various units spelled it cu in with a space between. Of course, it's entirely possible that I misread the format ;-) Sturmvogel 66 (talk) 05:29, 27 December 2020 (UTC)

The text actually output from {{convert}} has a space in cu in, of course. It might be best to think about the units used in convert as having three forms: the "unit name", the "unit symbol", and what you might consider a "unit code" that is used as a parameter in the template to represent that unit. These unit codes generally don't have spaces in them, even if the unit name or symbol does, because the space is used to separate multiple outputs. The three forms may be identical, similar, or different:

Three forms of units associated with {{convert}}
Unit code to use as parameter	Unit symbol	Unit name
acre	acre	acre
L	L	litre (liter if `\|sp=us`)
cuin	cu in	cubic inch

For example, {{convert|2500|cm3|cuin L|abbr=on}} → 2,500 cm³ (150 cu in; 2.5 L) and {{convert|2500|cm3|cuin L|abbr=off}} → 2,500 cubic centimetres (150 cubic inches; 2.5 litres). The unit codes in those don't have spaces, even though the unit names and symbols may do. If your guess at the unit code produces an error, then removing any spaces often fixes it. --RexxS (talk) 00:31, 2 January 2021 (UTC)

…but why does a unit code even exist? I guess this only causes confusion (this is a perfect example) – I'd recommend making all possible unit symbols work as "unit codes" Johannes (Talk) (Contribs) (Articles) 02:56, 2 January 2021 (UTC)

Unit code is editor-friendly (think: writing the input). It solves these situations:

m2, impoz, C, C-change (no symbol for this at all), t (is metric or long?), mpg_‑US

Given this, {{convert}} uses the space with different meaning (as unit-separator): {{convert|10|km|mi nm nmi}} → 10 kilometres (6.2 mi; 1.0×10¹³ nm; 5.4 nmi). -DePiep (talk) 13:12, 2 January 2021 (UTC)

Multiple dimensions: (height x width x depth)

Can the template handle such conversions? I saw an option for multiple dimensions, but it doesn't seem to go beyond two dimensions, so I can't quite visualize how to do it. Thanks! 1980fast (talk) 03:20, 7 January 2021 (UTC)

Here are two examples:

{{convert|3|x|4|x|24|in}} → 3 by 4 by 24 inches (76 mm × 102 mm × 610 mm)
{{convert|3|x|4|to|6+1/2|x|8+3/4|in}} → 3 by 4 to 6+1⁄2 by 8+3⁄4 inches (76 mm × 102 mm to 165 mm × 222 mm)

More than three is supported, just keep adding numbers and range symbols. 03:52, 7 January 2021 (UTC)

Thank you! 1980fast (talk) 04:22, 7 January 2021 (UTC)

Scientific notation with range

Is there a way to convert scientific notation with a confidence interval using this template? What I would like to get is

(5.4 ± 0.5)×10¹⁷ kg [(1.2 ± 0.1)×10¹⁸ lb]

but the template gives me either

5.4×10¹⁷ ± 0.5 kg (1.1904962157983×10¹⁸ ± 1.1 lb)

or

5.4×10¹⁷ ± 0.5×10¹⁷ kg (1.19×10¹⁸ ± 1.1×10¹⁷ lb)

Perhaps it's just a bad idea to do unit conversion in this case, even the "right" answer is rather cumbersome. Tercer (talk) 07:38, 21 January 2021 (UTC)

No, you would have to use {{val}} for confidence intervals and could not have an automatic conversion. You could use convert to kludge the output number but you may as well do it all manually because there is no template that handles conversion of the confidence level. I think your suspicion that a conversion might not be desirable is correct. Anyone who understands what an error interval is will want kg, and the conversion doesn't really add anything—the point is that it is a very large number of pounds. Johnuniq (talk) 08:34, 21 January 2021 (UTC)

Conversion without parentheses?

Is it possible to format the conversion such that there are no extra parentheses added? A use case for this would be a conversion done within an existing parenthetical statement.

For example, say that someone has just mentioned a mountain, followed by "(elev. xxxx feet)". What if you wanted the conversion to read "(elev. xxxx feet; xxx meters)" in order to avoid the messiness that comes with nested parentheses? Thanks! 1980fast (talk) 21:45, 22 January 2021 (UTC)

@1980fast: Sure – see Template:Convert #Output manipulation. For example:

(elev. {{convert|10|m|ft|disp=comma}}) → (elev. 10 metres, 33 ft)

The documentation is lengthy, but pretty comprehensive. --RexxS (talk) 22:10, 22 January 2021 (UTC)

Thanks! I'm not sure how I missed that, but I clearly did. :) 1980fast (talk) 22:20, 22 January 2021 (UTC)

There is also (elev. {{convert|10|m|ft|disp=sqbr}}) → (elev. 10 metres [33 ft]) MB 02:11, 23 January 2021 (UTC)

That's even better! Thanks! 1980fast (talk) 07:27, 26 January 2021 (UTC)

Handling an unwieldy conversion

I was looking at the page for Darigold, a dairy cooperative, and it mentions their annual production of milk – a staggering 8.6 billion pounds a year. The template used is a simple conversion to kilograms, however, the metric output is given in scientific notation, which isn't exactly accessible for the average reader. Is there any way to make both values output a conversion that is more directly comparable, perhaps with the numbers reformatted, like "8.6 billion pounds (3.9 billion kg)" ?

If that's not possible, is it at least possible to suppress the scientific notation? I'm not even sure how it came into play, since the input value is displayed without problem. Thanks! 1980fast (talk) 07:25, 26 January 2021 (UTC)

Use engineering notation and abbr=unit or abbr=off. You need one of these to get the word million/billion for the output. Unfortunately you can't have "pounds" (name) and "kg" (symbol) and number words.

{{convert|8,600|e6lb|e6kg|abbr=unit}} → 8,600 million lb (3,900 million kg)
{{convert|8,600|e6lb|e6kg|abbr=off}} → 8,600 million pounds (3,900 million kilograms)
{{convert|8.6|e9lb|e9kg|abbr=unit}} → 8.6 billion lb (3.9 billion kg)
{{convert|8.6|e9lb|e9kg|abbr=off}} → 8.6 billion pounds (3.9 billion kilograms)

Johnuniq (talk) 08:14, 26 January 2021 (UTC)

Add disp=/ and/or disp=s

For Iztapalapa#Elevation and climate could we have disp=/ and/or disp=s? eg ({{cvt|2,400|m|ft|disp=/}} asl) (2,400 m (7,900 ft)^{[convert: invalid option]} asl) instead of ({{cvt|2,400|m|ft|disp=or}} asl) (2,400 m or 7,900 ft asl) Peter Horn User talk 22:08, 4 February 2021 (UTC)

Sorry, disp=slash (and its equivalents disp=s and disp=/) was removed in January 2018. Johnuniq (talk) 22:51, 4 February 2021 (UTC)

And the reasons or pretexts were? I'm sure this caused a mess in many articles. Peter Horn User talk 23:28, 4 February 2021 (UTC)

Sorry but I have driven out memory of the very long and tedious discussions which can be traced in the archives. Perhaps some MOS page deprecated slash? There was no mess as the deprecated options were removed from articles before removing them from convert. Johnuniq (talk) 02:26, 5 February 2021 (UTC)

MOS:SLASH, no doubt. --Izno (talk) 02:39, 5 February 2021 (UTC)

Earth pounds

I was wondering if there should be "earth pounds" which can be useful on pages such as moon. Cause pound and kilograms are different. Pound is weight and kilograms is mass. Pound per kilogram depends on the gravity force. The Channel of Random (talk) 00:45, 13 February 2021 (UTC)

Pound (mass) has the symbol lb (lb_m is an alternative) and pound (force) has the symbol lb_f. It is easy to confuse the two but pound (lb) without a qualifier is always mass, same as kg. Stepho talk 01:11, 13 February 2021 (UTC)

@Stepho-wrs: In what context do you claim the symbol lb always means pound mass? In the context of the convert template, or some other context? Jc3s5h (talk) 01:29, 13 February 2021 (UTC)

In the context of the UK, the Weights and Measures Act 1963 defines the pound like this: "… the pound or the kilogram shall be the unit of measurement of mass by reference to which any measurement involving a measurement of … mass shall be made in the United Kingdom; and … the pound shall be 0.45359237 kilogram exactly." See Pound (mass) #Current use.

I'm pretty certain nobody is debating whether the kilogram is a unit of mass, and the pound is defined as an exact fraction of a kilogram, so it makes it pretty much impossible for the pound to be a unit of force in the UK. It may be different in other jurisdictions. --RexxS (talk) 01:51, 13 February 2021 (UTC)

In the US the same definition applies, although the federal and state laws enacting it are different. So the context is commerce. The definition only applies to places where weights and measures inspectors can raid and seize scales that do not conform. It does necessarily apply in, for example, physics classes or physics textbooks. Jc3s5h (talk) 01:57, 13 February 2021 (UTC)

My claim was based on information from the 2 articles I linked. International yard and pound also backs up that the pound (unqualified) is a defined in terms of the kg. If I am wrong then those articles will need updating. Perhaps I should have said "correct usage of pound without a qualifier is always mass". Of course, incorrect usage can claim anything from it being a unit of force to a unit of self esteem. Stepho talk 02:12, 13 February 2021 (UTC)

Pound (mass) and pound (force) acknowledge that various definitions exist. For the symbols they make reference to various non-goverment publications. Such publications can disagree. And as I indicated, governments are usually interested in enforcing their definitions in commerce (including the government acquiring goods). I just am nit convinced we can rely on "lb" always referring to the unit of mass. Jc3s5h (talk) 02:42, 13 February 2021 (UTC)

Perhaps so, but convert cannot help. There is no conventional way of writing "earth pound" ("Earth pound"?) that would be understood by someone unfamiliar with the concept, and there certainly is no symbol. Moon has no mention of "pound" but has text like "100 kg (220 lb) of water". That is referring to a certain amount of water specified with its mass, as defined in the way RexxS described above. Johnuniq (talk) 03:08, 13 February 2021 (UTC)

Candlepower

For Low Light of the Hook of Holland#History and elsewhere would it be possible to have (a) conversion(s)? say for example {{convert|2,000|cp|lm}}. Peter Horn User talk 16:58, 19 February 2021 (UTC)

The situation is not very clear. There are no related units in convert. Template talk:Convert/Archive 1#Photometry units is the only previous discussion. The candela is the SI unit for Luminous intensity, while lumen is the SI unit for Luminous flux. There are also Lux and Foot-candle, units for Illuminance. Candlepower is an "obsolete unit of measurement for luminous intensity" but apparently also has a modern definition measuring "the intensity of the light on a target". @Archon 2488 and GliderMaven: and anyone else with thoughts: Is there a useful and unambiguous conversion for candlepower? Johnuniq (talk) 23:34, 19 February 2021 (UTC)

Another rename: mmHg

11:32, 7 May 2019‎ Anthony Appleyard moved page Millimeter of mercury to Millimetre of mercury: Requested by Getsnoopy at WP:RM/TR: WP:COMMONALITY and because "metre" is standardised across WP — Preceding unsigned comment added by 2001:8a0:5e58:9a00:e992:745b:11c:c2cd (talk • contribs) 20:43, 3 March 2021 (UTC)

The problem being reported is that the following links to Millimeter of mercury whereas for consistency and in accord with the current article name, it shold be Millimetre of mercury. I made a note to do that for the next release.

{{convert|12|mmHg|abbr=off|lk=on}} → 12 millimetres of mercury (1.6 kilopascals)

Johnuniq (talk) 03:04, 9 March 2021 (UTC)

Rpm & Hz

For Straight-six engine#Australia 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz). Would it be possible to have {{cvt|6,000|rpm|Hz|lk=on}} 6,000 rpm (100 Hz) & {{cvt|2,750|rpm|Hz|lk=on}} 2,750 rpm (45.8 Hz)? rpm Hz Peter Horn User talk 00:44, 9 March 2021 (UTC)

Convert has an interesting way of handling Hz (see March 2015). I added rpm as a trial to see how it goes and whether there are any bad side effects.

{{convert|1|rpm}} → 1 revolution per minute (0.017 Hz)
{{convert|12|rpm|Hz|abbr=on}} → 12 rpm (0.20 Hz)
{{convert|12|rpm|Hz|abbr=off}} → 12 revolutions per minute (0.20 hertz)

Johnuniq (talk) 02:54, 9 March 2021 (UTC)

{{convert|6000|rpm|furlong}}6,000 revolutions per minute (15,000 furlongs)

(It's treating it like a radio wave. I don't think it's a problem exactly it's just strange looking.) GliderMaven (talk) 03:15, 9 March 2021 (UTC)

I was trying to avoid mentioning that, groan. Given the definition for Hz, it would be challenging to convert Hz to rpm without allowing other unlikely conversions. Johnuniq (talk) 03:33, 9 March 2021 (UTC)

I think with these kinds of dimensional conversion systems, stopping people doing weird conversions is much, much, much less of an issue than allowing people do the kinds of conversions they need to. GliderMaven (talk) 03:58, 9 March 2021 (UTC)

Surprise! the Hz values given now are totally different from those originally given in the article, showing the original figures to be wild guesses. Peter Horn User talk 21:30, 10 March 2021 (UTC)

@Peter Horn: you are chaotic. Could you just post:

1. "Expected: abc" (because: ...)

2. "But it shows: xyz"

Thanks. -DePiep (talk) 22:17, 10 March 2021 (UTC)

@DePiep: What was shown is 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz) the conversions became 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz). The original conversions were confirmed. Peter Horn User talk 05:28, 11 March 2021 (UTC)

Folks, we're too trusting! My first example above gave "1 revolution per minute (60 Hz)" which is total junk! Ouch. I'll look at whether this is due to my blunder with the scale or whether the tricky invert stuff actually doesn't work. Johnuniq (talk) 01:13, 11 March 2021 (UTC)

Um. Something's wrong: {{cvt|6000|rpm|Hz|lk=on}} is currently giving me: 6,000 rpm (360,000 Hz) GliderMaven (talk) 01:16, 11 March 2021 (UTC)

I think I've fixed it—the problem was just my confusion over the rpm scale. The relevant two converts from the article are:

{{cvt|6,000|rpm|Hz|lk=on}} → 6,000 rpm (100 Hz)
{{cvt|2,750|rpm|Hz|lk=on}} → 2,750 rpm (45.8 Hz)

Johnuniq (talk) 02:28, 11 March 2021 (UTC)

Looks much better, thanks! GliderMaven (talk) 04:40, 11 March 2021 (UTC)

@Peter Horn: Thanks for reporting the discrepancy but it was convert that was wrong—now corrected. By the way, when you see |disp=flip it would be good if you were to change that to |order=flip. One of the edits you made changed the first of the following to the second:

{{Convert|9120|cc|cuin|0|disp=flip}} → 557 cubic inches (9,120 cc)
{{Convert|9120|cc|cuin L|0|disp=flip}} → 557 cubic inches; 9 litres (9,120 cc)

You probably don't want to flip it like that. If you want both cuin and L with L as the input, you need:

{{cvt|9120|cc|L cc cuin|0|order=out}} → 9 L (9,120 cc; 557 cu in)

Also, please have a look at Straight-six engine#Displacement range which is showing L as the second paragraph. It looks like a stray character was inserted. Johnuniq (talk) 02:28, 11 March 2021 (UTC)

@Johnuniq: I removed the stray L. Peter Horn User talk 05:37, 11 March 2021 (UTC)

Twice in an article

Can the same conversion be mentioned twice or more in an article, or should this generally be avoided? Kind regards, Willbb234^Talk (please {{ping}} me in replies) 23:15, 10 March 2021 (UTC)

@Willbb234: Yes, lots of articles have the same conversion twice or more. That particularly applies if a value is mentioned in the WP:LEAD and then again later in the body of the article. If the page is short, repeating the conversion becomes less desirable but ultimately it is a matter of judgment. If you want an opinion on a particular article, you might mention it here or at WP:Teahouse. Johnuniq (talk) 01:00, 11 March 2021 (UTC)

Okay, thanks. The article is K-63 (Kansas highway). The article repeats the conversion of one mile and 1.2 miles two times each. Kind regards, Willbb234^Talk (please {{ping}} me in replies) 09:01, 11 March 2021 (UTC)

That is a bit repetitive but it could be argued that someone familiar only with km would want every instance converted. Ultimately it's a matter for discussion on the talk page of the article concerned, or perhaps at a related WikiProject. Here (at talk convert) we don't really have an opinion—the guideline is MOS:CONVERSIONS but it doesn't have a clear statement on that point. You could ask for opinions there but people generally say that the MOS can't cover every detail and it's up to common sense with discussion. Johnuniq (talk) 09:27, 11 March 2021 (UTC)

Thanks for the reply. I don't think it does anyone harm to leave it how it is and, as you say, it helps to clarify even if repeated. Kind regards, Willbb234^Talk (please {{ping}} me in replies) 17:10, 11 March 2021 (UTC)

Use "a" or "an" instead of "1" or "one"

touchtennis#Court originally had the sentence

However, variances of up to a metre are tolerated…

The convert template let me change it to

However, variances of up to 1 metre (3 ft 3 in) are tolerated…

but I think the original (with conversion) reads better:

However, variances of up to a metre (3 ft 3 in) are tolerated…

Is there an option to use "a"?

Thanks,
cmɢʟee⎆τaʟκ 21:48, 17 March 2021 (UTC)

There is no good way to do that. For one thing, there are too many variations (although I can't think of them at the moment), and the syntax for specifying what is wanted would be clumsy. You can kludge it:

However, variances of up to a metre ({{convert|1|m|ftin|disp=out}}) are tolerated

However, variances of up to a metre (3 ft 3 in) are tolerated

Johnuniq (talk) 22:59, 17 March 2021 (UTC)

Alternatively, you could encase it with a wrapper using the one2a template and put: "However, variances of up to {{one2a|{{convert|1|m|ftin|spell=in}}}} are tolerated". Giving you: "However, variances of up to a metre (3 ft 3 in) are tolerated". --Voello _talk 00:05, 18 March 2021 (UTC)

Very nice. I must have seen that but had forgotten. Johnuniq (talk) 01:06, 18 March 2021 (UTC)

That's brilliant. Thank you very much, Johnuniq and Voello. cmɢʟee⎆τaʟκ 12:28, 18 March 2021 (UTC)

Edit notice

Editing this talk is now showing a ghastly edit notice from Template:Editnotices/Page/Template talk:Convert which contains {{Wikipedia information pages talk page editnotice}}. The previous version was also not very helpful. Any suggestions on wording to fix it? Johnuniq (talk) 08:51, 18 March 2021 (UTC)

I have replaced the standard notice (which looked like this) with something shorter and more appropriate. I contemplated deleting the edit notice and wouldn't mind that as a solution as I don't recall any off-topic posts in several years. Johnuniq (talk) 06:16, 20 March 2021 (UTC)

Feet to metres conversion

It's just straight up wrong. I have noticed it in an article, Joe Biden may well be 6" tall but that is not 2 metres. I'm just under 6" 2" and I'm 1.85m.

The example given is also wrong, 124" is 37.7m, not 40m. If this has been standardised across all articles then all these conversions are wrong, plain and simple.

Who does one get this rectified? Stefanzi (talk) 07:29, 18 March 2021 (UTC)

Joe Biden is six inches tall? He looks bigger on TV. Beyond that I can't tell what you're talking about. What example? Where? E Eng 07:39, 18 March 2021 (UTC)

I reverted the recent edits at Heights of presidents and presidential candidates of the United States and the height is now:

{{convert|5|ft|11+1/2|in|abbr=off|sp=us|cm|0}} → 5 feet 11+1⁄2 inches (182 centimeters)

It had been recently changed to:

{{convert|6|ft|0|in|abbr=off|sp=us||0}} → 6 feet 0 inches (2 meters)

The "0" in |0}} tells convert to round the result to zero decimal places. No output unit was given (because the recent edits removed cm) and convert used its default for that which is m. The result was bad rounding due to bad parameters. Johnuniq (talk) 08:45, 18 March 2021 (UTC)

Meaning that it should have been written as {{convert|6|ft|abbr=off|sp=us||2}} (giving 6 feet (1.83 meters) or not removed the "cm". --John Maynard Friedman (talk) 12:38, 20 March 2021 (UTC)

Density question

I found an article that said a plant's density is "commonly 30 species/m2".

I changed that to :*{{cvt|30|/sqm}} which results in "commonly 30/m² (2.8/sq ft)"

It would be clearer if it could still include "species", similar to the way PD/sqkm generates "inhabitants". What about a parameter to override "inhabitants" with another name? I'm sure the text could be just be rewritten in this case, but the existing language seems most succinct. (There is currently no pd/sqm, so that would need to be added also).

On more thing, although /sqm works, I don't see it in the documentation (/sqcm, /sqkm, /sqha, /sqin, /sqacre, /sqmi are all there). MB 16:28, 21 March 2021 (UTC)

The following should be ok.

{{cvt|30|/m2||disp=preunit|species}} → 30 species/m² (2.8 species/sq ft)

Re the documentation: there are many hundreds of units and only some of them are listed for users. The full list (including sqm) is Module:Convert/documentation/conversion data. The reason that /sqm works is that the unit sqm is an alias for m2 and convert automatically handles "per" units if it can. Johnuniq (talk) 23:08, 21 March 2021 (UTC)

Great, I was unaware of disp=preunit. It worked fine. Regarding the documentation, I was looking at the full list - Module:Convert/documentation/conversion data#Per unit area is where /sqm and m2 seem to be missing. I'm not clear if you mean that this list is supposed to be complete or not. MB 23:36, 21 March 2021 (UTC)

The full list only includes the defined units. Convert can handle certain cases automatically even though no unit is defined. The "per" units (x/y meaning x units per y units) are part of that. Johnuniq (talk) 02:03, 22 March 2021 (UTC)

I/O

Parameter list for |abbr values in and out should list in the description that they are used for "input" and "output" units, respectively, for clarity (i.e. "Use symbol for first (left-hand side) unit (input unit)"). Any other parameters using these identical values should likewise be updated as well. Kehkou (talk) 06:04, 29 March 2021 (UTC)

Do you want to try editing that? On the template page, at the top next to "Template documentation", you can click "View" to see the documentation page, or "Edit" to directly edit it. Or, you can edit the "Parameter list" section with its edit link. Johnuniq (talk) 06:22, 29 March 2021 (UTC)

Beware that it also changes when |order=flip and |order=out is used

`{{convert\|100\|mph\|km/h\|0\|abbr=in}}`	→	100 mph (161 kilometres per hour)
`{{convert\|100\|mph\|km/h\|0\|abbr=in\|order=flip}}`	→	161 km/h (100 miles per hour)
`{{convert\|100\|mph\|km/h m/h mph\|0\|abbr=in}}`	→	100 mph (161 kilometres per hour; 160,934 metres per hour; 100 miles per hour)
`{{convert\|100\|mph\|km/h m/h mph\|0\|abbr=in\|order=out}}`	→	161 km/h (160,934 metres per hour; 100 miles per hour)
`{{convert\|100\|mph\|km/h m/h mph\|0\|abbr=out\|order=out}}`	→	161 kilometres per hour (160,934 m/h; 100 mph)

So, |abbr=in really means abbreviate the first displayed value, rather than the input value. Stepho talk 21:53, 29 March 2021 (UTC)

Thanks, that reminds me as to why the documentation uses its current language. We could think about adding some explanation like displayed input, but more words might mean more confusion. Johnuniq (talk) 22:27, 29 March 2021 (UTC)

How to convert

For Nevada Northern Railway, how would one convert 40 million net ton-miles to net tonne-kilometers? Peter Horn User talk 13:28, 13 April 2021 (UTC)

$y=x\cdot m\cdot L$
With:
$x\land y\in \mathbb {N}$
$x=40$ (million net ton-miles)
$y...$ (million net tonne-kilometres)
$m=0.90718474$ (Mass of a ton in 10³ kg)
$L=1.609344$ (Length of a mile in 10³ m)
Then:
$40\cdot 0.90718474\cdot 1.609344=58.4\rightarrow y=58$

Best regards, --Johannes (Talk) (Contribs) (Articles) 15:42, 13 April 2021 (UTC)

Much to my surprise, convert has that unit:

{{convert|40|e6ton-mile|e6tkm}} → 40 million ton-miles (58×10^⁶ tkm)
{{convert|40|e6ton-mile|e6tkm|abbr=off}} → 40 million ton-miles (58 million tonne-kilometres)

Johnuniq (talk) 00:01, 14 April 2021 (UTC)

Parameter list - adj. is stuck in abbr.

"Learning" editor here! I am pretty sure the "adj" parameter is missing from the parameter list and that all its possible values are incorrectly included in the "abbr" section. I am pretty sure I know how to fix it (I messed around in my sandbox), but I've never edited a template doc or done much work with a wikitable before. Can someone more experienced either tell me it's ok to attempt a fix, fix it themselves, or tell me I'm wrong? Thanks in advance! Firefangledfeathers (talk) 02:46, 12 April 2021 (UTC)

@Firefangledfeathers: Thanks for pointing that out. Often inspecting the history of a page with a problem can throw light on what happened. I reverted a recent edit (diff) at that page and I believe it is back to normal. Johnuniq (talk) 05:10, 12 April 2021 (UTC)

Parameter value

@DePiep: Just a question – why would anybody want to sort the table by parameter value? And it doesn't effect the reader's ability to search for whatever they like, unless your web browser's search function is stuck in 'whole words only' mode. WT79 ^{(speak to me | editing patterns | what I been doing)} 18:17, 13 April 2021 (UTC)

Because: when an editor wants to learn what an existing (used in-article) {{Convert}} setup is. Say, reverse-editing. IOW, what does an input value do? Seeing this talkpage with recurring questions, Convert is complicated. I do not understand "'whole words only' mode". -DePiep (talk) 18:36, 13 April 2021 (UTC)

You'd want to look up which parameter is used just as much you want to look up its value. If, for example, I come across {{convert|100|ft|m|adj=mid|-deep}}, then I want to look up what "|adj=mid|-deep" means. I can see it is two parameters, and can guess what the final one is for because I saw it rendered in the article, Therefore what I'd search for would be "|adj=mid". Since the parameter column includes both parameter and value (due to a recent edit linked above) it doesn't make sense to have the values listed separately as well. WT79 ^{(speak to me | editing patterns | what I been doing)} 16:37, 14 April 2021 (UTC)

L for liter

There was recently an RFC that changed MOS:UNITSYMBOLS to require "L" for liter when standalone. (That is to say, "ml" for example is still accepted, though "mL" is allowed.) Presumably this template/module should be changed to output "L" in all standalone cases, including when the input unit is "l". For example, {{convert|123|impgal}} now-incorrectly renders as "123 imperial gallons (560 l; 148 US gal)". -- Beland (talk) 03:49, 26 April 2021 (UTC)

lboz as a per unit

Is it already possible to use lboz/ as a per unit? Or is that easily added? For example instead of {{convert|235|kg/ha|lb/acre|frac=16}} in [9]. Invasive Spices (talk) 17:47, 29 April 2021 (UTC)

No, sorry. Convert gives up if given a combination like lb + oz. For one thing, the output (209 lb 11 oz/acre) would look strange. Also, it's unlikely that the resulting number of ounces is meaningful; that is, the output should be rounded to the number of pounds to avoid false precision. Johnuniq (talk) 01:15, 30 April 2021 (UTC)

That's unfortunate. I think it's needed. 1) In the case I just used it - "(209 ¹¹⁄₁₆ lb/acre)" - the alternative is strange looking also. 2) Although in that case I'm not sure such precision is needed either, certainly if we were outputting the text Total pounds of Atrazine applied must not exceed 2lb 8oz/acre per year., the ounces are vital. Invasive Spices (talk) 19:10, 30 April 2021 (UTC)

And another new unit request

This is unusual and rarely comes up, but I just saw something where PD/kg would be needed. I wanted to use {{convert||PD/kg|PD/lb}}, but no such units. You can see it by my  comment in this edit. Thanks for working on this stuff. Invasive Spices (talk) 21:03, 3 May 2021 (UTC)

What unit does PD stand for? Convert without PD works: "The density of spat varies from 200 to 2,000,000 per kilogram (91 to 907,185 per pound) of seaweed." -- WOSlinker (talk) 21:38, 3 May 2021 (UTC)

Thanks WOSlinker. That's perfect. (PD is "population density" for humans/living things. Just /kg by itself wasn't listed in Module:Convert/documentation/conversion data/doc so I never thought to try it.) Invasive Spices (talk) 15:28, 4 May 2021 (UTC)

Module version 25

This version was discussed in December 2020 but the release was stalled while the template styles were finalized.

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

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

Template styles (by Izno and RexxS):
- Fractions are displayed using Template:Fraction/styles.css (fractions with a slash) or Template:Sfrac/styles.css (stacked fractions with a horizontal bar).
- The implementation inserts the templatestyles 42-byte strip marker at the start of the convert output, but only if required for the fraction being displayed and only once per convert even if more than one fraction is displayed (for example, {{convert|1+1/2|by|5+3/4|in}}).
- For localization, the template styles are in Module:Convert/text which now exports the titles table.
Unit changes:
- Remove gramme from the unit definitions. This is not a change to units as gramme is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future. MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at MOS talk July 2019 following a request here.
- Remove 23 apparently unused energy units linking to Atmosphere (unit) per discussion here.
- New unit g0-force added and unit g0 has symbol g₀ with the 0 no longer in italics (discussion).
- Some units from Module:Convert/extra that are used in articles have been copied to the main module.
  - mi/kWh is retained in extra; it will be removed if not found to be used in articles.
  - Occurrences of scf2 and scfoot2 in articles will be replaced with scf and scfoot which have had their link corrected to standard cubic foot (discussion).
- Link for unit mmHg changed to Millimetre of mercury with re not er spelling (discussion).
- New unit rpm (discussion).
- New units tkm and ton-mile (discussion).
Tweaks:
- Module:Convert/wikidata will use mw.wikibase.getLabel(X) instead of deprecated mw.wikibase.label(X).

Release notes for earlier versions are listed here. Johnuniq (talk) 01:16, 4 May 2021 (UTC)

Done, the new version is live. Johnuniq (talk) 05:21, 6 May 2021 (UTC)

Fraction templatestyles

@Izno: Having convert use {{fraction}} and {{sfrac}} templatestyles was discussed in December 2020:

Template talk:Convert/Archive 2#visualhide removal
Template talk:Convert/Archive 2#Module version 25 (see May 2021 for release)
Template talk:Convert/Archive 2#Vertical spacing

Part of that involved a demonstration that the vertical spacing was a problem:

User:Johnuniq/sandbox2 uses Template:Fraction/styles.css
User:Johnuniq/sandbox uses Template:Fraction/sandbox/styles.css
{{convert/sandbox|1+2/3|ft|in}} → 1+2⁄3 feet (20 in) (uses Template:Fraction/styles.css)
{{convert/sandbox|1+2/3|ft|in|test=stylesandbox}} → 1+2⁄3 feet (20 in) (uses Template:Fraction/sandbox/styles.css)

The vertical spacing problem was fixed by RexxS in Template:Fraction/sandbox/styles.css. However the fix was not used for {{fraction}}. What should convert do? That is, should convert not use templatestyles? Or, should it use the fraction style and ignore the vertical spacing problem? Or, should the style be tweaked somehow? Johnuniq (talk) 04:38, 14 April 2021 (UTC)

I removed the temporary test=stylesandbox code so the above no longer applies. Johnuniq (talk) 10:09, 28 April 2021 (UTC)

Just now (thank you for continuing to poke me), I moved RexxS's changes to the main fraction styles, moved sfrac's styles out to its own sheet (per related discussion), and made Template:Frac's sandbox live. I'll be moving stuff live for Sfrac shortly.

I did get lost in your implementation here in convert when I went to look at it the first time, but I think I get the gist of what it is doing now. (I am not a fan of the string processing that I can see that selects whether to add the templatestyles, but I'm not going to hassle about it.) I think the remaining effort in the convert module is to remove some temporary code in the sandbox regarding style sandboxing in add_style, and to add an implementation for Sfrac having separate styles, where necessary. Izno (talk) 20:37, 27 April 2021 (UTC)

While on the subject of fans, I'm not a fan of splitting everything into micro-files (Template:Fraction/styles.css and Template:Sfrac/styles.css) but purism has its place. I updated convert/sandbox so both styles work. I'll need to check what I've done and slowly test it later.

{{convert/sandbox|1+2/3|ft|in}} → 1+2⁄3 feet (20 in) (fraction style)
{{convert/sandbox|1+2//3|ft|in}} → 1+2/3 feet (20 in) (sfrac style)
{{convert/sandbox|18+1/2|in|ft|frac=-2}} → 18+1⁄2 inches (1+1/2 ft) (both!)

Johnuniq (talk) 10:09, 28 April 2021 (UTC)

I am not per se a fan of micro-files either but made the decision that on the greater proportion of pages (probably much larger proportion) one should expect that only one or the other will be used rather than both given both documented template use and documented number of transclusions (24k use fraction, 4k use sfrac).

If your implementation works for you, just ping me when you merge so I know to start the clock on removal of visualhide in Common.css (the original reason for all this :^). Izno (talk) 19:20, 28 April 2021 (UTC)

@Izno: The new version is now live. Johnuniq (talk) 05:24, 6 May 2021 (UTC)

Brackets

Hi all, After a conversation last month with @Colonies Chris:, I have started to use the convert template for windspeeds with the following configuration: {{convert|125|kn|km/h mph|round=5|disp=out}} , however, I noticed earlier that the template is not putting the output in brackets 230 km/h; 145 mph. Is there a way to ensure that the output goes into brackets? If so then I strongly suspect that the long running issues that the tropical cyclone project, has had with using the template for windspeeds might be over.Jason Rees (talk) 02:41, 6 May 2021 (UTC)

@Jason Rees: I think you want the second of these:

{{convert|125|kn|km/h mph|round=5|disp=out}} → 230 km/h; 145 mph
{{convert|125|kn|km/h mph|round=5|abbr=on|order=out}} → 230 km/h (145 mph)

Johnuniq (talk) 03:26, 6 May 2021 (UTC)

Thanks @Johnuniq:.Jason Rees (talk) 13:20, 6 May 2021 (UTC)

disp=or question

Why, when using disp=or, is unit abbreviation an all-or-nothing proposition?

If I want the otherwise default behavior of "x inches or y mm", it seems that's not currently possible.

Instead, either both units are spelled, or both units are abbreviated, with the addition of abbr=on. That behavior seems incredibly inconsistent. Thanks for any clarification! 1980fast (talk) 04:04, 7 May 2021 (UTC)

@1980fast: With disp=or, the default is abbr=off. However abbr can also be specified as in or out.

{{convert|7|in|mm|abbr=out|disp=or}} → 7 inches or 180 mm

Johnuniq (talk) 07:18, 7 May 2021 (UTC)

@Johnuniq: Thanks! Because the out option is not mentioned at all in the section on abbr, it never even crossed my mind that it would be possible. Now I know: check the tables! 1980fast (talk) 22:57, 9 May 2021 (UTC)

People per square mile

Sacramento, California#2010 census 4,660.0 people per square mile (1,799.2/km²) How was this calculated? It does not appear to be done by template convert. {{convert|4,660.0|people/square mile}} 4,660.0 people/square mile^{[convert: unknown unit]} {{convert|4,660.0|density/square mile}} 4,660.0 density/square mile^{[convert: unknown unit]} Peter Horn User talk 23:38, 15 May 2021 (UTC)

{{convert|4,660.0|/sqmi}} → 4,660.0 per square mile (1,799.2/km²) Stepho talk 00:09, 16 May 2021 (UTC)

Convert options:

{{convert|4,660.0|/sqmi}} → 4,660.0 per square mile (1,799.2/km²)
{{convert|4,660.0|PD/sqmi}} → 4,660.0 inhabitants per square mile (1,799.2/km²)
{{convert|4,660.0|/sqmi||adj=pre|people}} → 4,660.0 people per square mile (1,799.2/km²)

Johnuniq (talk) 00:22, 16 May 2021 (UTC)

Module version 26

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

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

Unit changes:
- Link and name have been hyphenated for units: acre foot + acre feet + Nm + mN.m.
- Link changed to Units of textile measurement#Units for unit: dtex.
- Link changed to Ampere per metre which redirects to Magnetic field#The H-field for units: A/m + kA/m + MA/m.
- Link changed to Pound-mole which redirects to Mole (unit)#Similar units for units: lb-mol + lbmol + lb-mol/d + lb-mol/h + lb-mol/min + lb-mol/s + lbmol/d + lbmol/h + lbmol/min + lbmol/s.
- Link changed to long quarter which redirects to Avoirdupois system#long quarter for units: qtr + long qtr.
- Link changed to short quarter which redirects to Avoirdupois system#short quarter for unit: short qtr.
- Link changed to Rod (unit)#Area and volume for unit: sqperch.
- Link changed to Cubic foot per minute which redirects to Cubic foot#Cubic foot per minute for unit: cuft/min.
- Link changed to Cubic yard per second which redirects to Cubic yard#Cubic yard per second for unit: cuyd/h.
- Link changed to Pound per square inch for units: ksi + psf + psi.
- Link changed to Pound-force per square inch which redirects to Pound per square inch for unit: lbf/in2.
Module:Convert/wikidata/data updated to match some changes to units on Wikidata (comparison of sandbox units with those in Wikidata is here).

Release notes for earlier versions are listed here. Johnuniq (talk) 03:27, 3 June 2021 (UTC)

Done, the new version is live. Johnuniq (talk) 03:21, 6 June 2021 (UTC)

Unit fixes

Acre-feet vs. acre feet

Resolved

I've come across a little grammar/definition problem while updating streamflow data in a river article.

The way I understand it, the unit acre-foot is spelled with a hyphen because it's defined by the product of an acre and a foot of thickness, just as the kilowatt-hour is the energy produced by one kilowatt of power for one hour.

So shouldn't {{convert}} display acre-feet rather than acre feet?

Let me add that I found a relevant discussion on this talk page from 2011, Template_talk:Convert/Archive_September_2011#acre_foot. It appears that either no change was made to {{convert}} following that discussion, or that some possible helpful feature was eliminated.

Please forgive me if I am wrong or there already is some feature to display acre-feet. If so, I would like to know. --Jsayre64 (talk) 02:35, 18 May 2021 (UTC)

You seem to be the first to note here that acre-feet has had a hyphen for a long time, apart from the 2011 discussion you linked which focused on what had to be typed as the unit code for convert's input. The current situation seems wrong and needs fixing but we'd better take some time to check other units as well. I'll have to remind myself whether Module talk:Convert/show still works but it probably does. That page lists all the unique links that convert can generate. And maybe examine the full list of units.

The current situation is that these unit codes (input to convert) exist:

acre.foot = acre foot

acre feet = acre-feet = acre ft

They all have acre⋅ft as the symbol and acre foot as the unit link and singular name. The two "foot" units have acre foot as the plural name while the other units give acre feet. What's needed is that the link and names are hyphenated. Thanks for reporting. The change will happen in due course but some thought about any other unit adjustments is needed first. Johnuniq (talk) 03:42, 18 May 2021 (UTC)

Ok, hopefully someone who knows more about the intricacies of {{convert}} will come along and help. Those documentation pages usually confuse me, and I know very, very little about how to change the template code.

In the meantime, however, I've tested different ways of using {{convert}} for acre-feet and for kilowatt-hours, mostly for reference, I guess. Have a look. It appears that setting |abbr=on}} is an okay workaround method in the case of acre-feet, but even so, that dot indicating multiplication looks quite small to me. Jsayre64 (talk) 20:41, 18 May 2021 (UTC)

I have fixed many unit links in the sandbox (and have more to do). The fixed units include these:

{{convert/sandbox|1|acre-foot|lk=in}} → 1 acre-foot (1,200 m³)
{{convert/sandbox|1|acre-ft|lk=in}} → 1 acre-foot (1,200 m³)
{{convert/sandbox|2|acre-foot|lk=in}} → 2 acre-foot (2,500 m³)
{{convert/sandbox|2|acre-ft|lk=in}} → 2 acre-feet (2,500 m³)

These are aliases for acre-foot: acre foot + acre.foot

These are aliases for acre-ft: acre feet + acre-feet + acre ft + acre.ft + acre·ft
Johnuniq (talk) 10:19, 19 May 2021 (UTC)

Those look great! Is it okay to use {{convert/sandbox in an article though? Jsayre64 (talk) 17:41, 19 May 2021 (UTC)

Yes, you can use it but one of us has to remember to remove it later when the main template is updated. Frankly I would just leave it alone. Lots of articles use this unit and they have been displaying the unhyphenated text for years so a few more weeks won't be a problem. Johnuniq (talk) 01:55, 20 May 2021 (UTC)

Agreed. Jsayre64 (talk) 20:28, 20 May 2021 (UTC)

Angstrom

Convert defines symbol Å and name ångström and link ångström for this unit. However I see the unit is now at Angstrom and energetic discussions at Talk:Angstrom assert that angstrom is the correct name. The article mentions the IUPAC Gold Book which says ångström (and searching for "angstrom" redirects to that page). I assume the official name has the diacrits and there is no need to change convert's name or link? Johnuniq (talk) 07:48, 19 May 2021 (UTC)

Lakh

Please add a conversion for Lakh, which is used in many citations from India. -Guy Macon (talk) 12:18, 24 May 2021 (UTC)

@Guy Macon: I moved the above from the module talk page because this is where proposed changes are discussed. A lakh is not a unit in the sense used by convert (which is designed for converting between, say, kilograms and pounds). I think a specialty template would be more appropriate for lakhs—someone here might know if there already is one. Johnuniq (talk) 23:55, 24 May 2021 (UTC)

I see some info at Template talk:Convert/Archive December 2018#Lakh and crore which points to {{lakh}} and {{crore}}. Johnuniq (talk) 00:00, 25 May 2021 (UTC)

Testing...

400 [[lakh]] ({{lakh|400}}) = 400 lakh (40,000,000)
400 [[crore]] ({{crore|400}}) = 400 crore (4,000,000,000)
400 [[lakh crore]] ({{lakh crore|400}}) = 400 lakh crore ({{lakh crore|400}})
{{cvt|400|mi|ft}} = 400 mi (2,100,000 ft)

Not really useful. The miles are automatically converted to feet, which is good; they never get out of sync. I have to enter the number twice for lakhs; I might as well just add "(40,000,000)" at the end. :(

Example of a reference that is confusing to non-Indian readers: second paragraph of [10], cited at Unani medicine. --Guy Macon (talk) 04:10, 25 May 2021 (UTC)

I can't interpret MOS:LAKH. Is it saying that you should specify "400 lakh (English number here)"? Or is it saying to do that only if you really need to and to just put the English number for most cases? In other words, you would write {{lakh|400}} and it would display "40,000,000" which would be appropriate for the English Wikipedia. The fact that the reference said "400 lakh" does not need to be mentioned, per WP:CALC, I think, although the lakh template would be used to allow easy verification. Johnuniq (talk) 05:02, 25 May 2021 (UTC)

That's a good solution. I would hope that anyone in India would be able to read 40,000,000 or forty million and know that it is the same as 400 lakh, 4 crore, or 4,00,00,000 (See Indian numbering system#Use of separators). --Guy Macon (talk) 06:15, 25 May 2021 (UTC)

Display tonnes, not t?

In conversions such as {{convert|30|lt|MT}}, which renders as 30 long tons (30 t), I would like to have "tonnes" displayed instead of t: 30 long tons (30 tonnes). Can this be done? Cheers, Simon – SCHolar44 🇦🇺 💬 at 02:04, 9 June 2021 (UTC)

MT is metric ton so if you want tonne, use t or tonne and use abbr=off. The second of the following displays 2 decimal places to show the values are different but they round to the same number.

{{convert|30|lt|tonne|abbr=off}} → 30 long tons (30 tonnes)
{{convert|30|lt|tonne|2|abbr=off}} → 30 long tons (30.48 tonnes)

For all units, see here. Johnuniq (talk) 04:02, 9 June 2021 (UTC)

Many thanks, Johnuniq! SCHolar44 🇦🇺 💬 at 07:32, 9 June 2021 (UTC)

Johnuniq, what's needed, please, to include hundredweights and quarters? I've only succeeded with whole numbers of long tons so far. SCHolar44 🇦🇺 💬 at 05:55, 11 June 2021 (UTC)

Use Lcwt (long hundredweight) which can optionally be followed with qtr (quarter).

{{convert|30|lt|18|Lcwt|2|qtr|tonne|abbr=off}} → 30 long tons 18 hundredweight 2 quarters (31.42 tonnes)

I fixed the timestamp in your signature. Please use four tildes to sign so a new signature is created. For example, the copy/pasted signature you used did not ping me. Johnuniq (talk) 06:57, 11 June 2021 (UTC)

Many thanks again, Johnuniq. (Probably I pasted the previous signature. I thought you would be pinged by [[User:Johnuniq|Johnuniq]] -- no?) SCHolar44 (talk) 05:59, 12 June 2021 (UTC)

@SCHolar44: The ping occurs in the process of Wiki translating the tildes into a signature. If you pasted a signature rather than the tildes, the paragraph would not have been searched for pingable constructs, and thus no ping would have occurred. Tarl N. (discuss) 06:49, 12 June 2021 (UTC)

Ah! The scales fall from my eyes! Many thanks for taking the time to educate me, @Tarl N.: SCHolar44 (talk) 12:40, 14 June 2021 (UTC)

Hoppus

A way to convert hoppus to cubic feet and cubic metres. Peter Horn User talk 01:09, 12 May 2021 (UTC)

AS well as board feet since this is a volume of timber Peter Horn User talk 01:18, 12 May 2021 (UTC)

Units board feet and board foot exist. The difference is that the first give "board feet" as the plural name while the second is always "board foot".

{{convert|12|board feet}} → 12 board feet (0.028 m³)

No hoppus I'm afraid. You'll have to make do with a manual conversion. Johnuniq (talk) 03:23, 12 May 2021 (UTC)

Would it be that difficult to add hoppus? Manual conversions are a pain. Also I forgot {{cvt|12|bdft|lk=in}} 12 bd ft (0.028 m³) Peter Horn User talk 20:40, 12 May 2021 (UTC)

Sorry but this is the first time in convert's long history that hoppus has been mentioned and it's not worth adding every unit that might appear in one or two articles. Hoppus suggests the unit was used for very rough estimates and that means a precise conversion is unlikely to be useful. Re board foot: I overlooked the fact that bdft also exists and works as shown in your above comment. Johnuniq (talk) 02:07, 13 May 2021 (UTC)

Not so fast. Hoppus#Calculation of timber volume in round logs and Hoppus#Equivalents appear to indicate that reasonable conversions are possible. No worse and no better than board foot. Peter Horn User talk 00:44, 14 May 2021 (UTC)

@Johnuniq: Your input please on my last remark. Peter Horn User talk 20:31, 16 June 2021 (UTC)

It's standard here that not every unit is included in convert. If hoppus was needed for a dozen articles, it's likely it would be added. However, given that no one has mentioned hoppus in a dozen years, it is unlikely that the unit is needed. Other people might like to give their opinion, but they would possibly want to see examples of where the unit would be used. Johnuniq (talk) 07:27, 17 June 2021 (UTC)

Conversion from fraction of c

Quick question - is there a way to convert from fraction of the speed of light to more conventional speed units? I note that {{val}} recognizes "0.1 c₀", but I haven't figured out a way to feed this into convert. This came up in an edit where a paper specified a speed in terms of fraction of speed of light, and an editor translated 10% of c into 30,000 kps/18,628.2 mps which was wrong on several levels. After reverting (it turns out they misread the article), I also pointed to the convert template, suggesting that in the future they should use the units specified by their source and {{convert}} to units they think are necessary. But articles in physics often do specify speeds in terms of "c", and that may be an issue. Is there an obvious way to handle this that I missed? Tarl N. (discuss) 05:17, 12 June 2021 (UTC)

Hmm. {{convert|0.1|light-year/year|km/s|disp=out}} yields 30,000 km/s. Tarl N. (discuss) 05:26, 12 June 2021 (UTC)

Yes, 30,000 km/s seems right, with one significant digits. There were cases in the past where too many digits came out, and this seems to be be another one, in the mps base. Besides mps not being a normal unit abbreviation. Gah4 (talk) 20:54, 18 June 2021 (UTC)

Inconsistency in denoting US vs imperial gallon in composite units

I've noticed there is a slight inconsistency in how the template handles composite units featuring US/imperial gallons, which isn't really ideal in terms of disambiguation. I'll give some examples to illustrate the problem. With standalone volume units we observe the expected and desired behaviour:

100 US gal (380 L) and 100 imp gal (450 L)
100 US gallons (380 litres) and 100 imperial gallons (450 litres)

but with composite units (such as volume per unit time):

100 gal/h (380 L/h) vs 100 imp gal/h (450 L/h)
100 gallons per hour (380 litres per hour) vs 100 imperial gallons per hour (450 litres per hour)

You see: the composite units featuring the US gallon omit the disambiguating "US", so if this occurs in isolation, a reader will be unaware which gallon is meant (without relying on contextual information to disambiguate, which is not desirable). Is this a known issue? Archon 2488 (talk) 20:01, 18 June 2021 (UTC)

In addition to the cases where "US units" and "Imperial units" are, wrongly, used interchangeably. (That is, the phrase itself, though maybe also the actual units.) Gah4 (talk) 20:55, 18 June 2021 (UTC)

Indeed, this is a perennial source of confusion which has plagued innumerable articles (alongside the inevitable confusion of nautical and statue miles – often variously converted to kilometres by different editors making incompatible assumptions about which of the two was meant – in articles related to aviation and ships) – this is a major reason why I am concerned about this behaviour of the template. Archon 2488 (talk) 22:02, 18 June 2021 (UTC)

This is an esoteric feature of convert illustrated in the following. Observe that the second two examples link US/U.S. to one article and gallons per hour to another.

{{convert|100|USgal/h}} → 100 gallons per hour (0.38 m³/h)
{{convert|100|U.S.gal/h}} → 100 gallons per hour (0.38 m³/h)
{{convert|100|USgal/h|lk=in}} → 100 US gallons per hour (0.38 m³/h)
{{convert|100|U.S.gal/h|lk=in}} → 100 U.S. gallons per hour (0.38 m³/h)

Those units behave like that due to the definitions in Module:Convert/documentation/conversion data#Flow (see Module:Convert/documentation/conversion data#Link regarding + and * in the definitions). By contrast, the unit usgal/h is not defined so convert handles it automatically as a "per" unit:

{{convert|100|usgal/h}} → 100 US gallons per hour (110 L/ks)

For historians, USgal/h was added to the template implementation of convert in September 2009 and was copied by the module implementation in December 2013. Some significant refactoring could occur now after checking all similar units and having at least a brief look at how they are used in articles. Johnuniq (talk) 00:03, 19 June 2021 (UTC)

l/ks?

OK, a different question related to the above: {{convert|100|usgal/h}} → 100 US gallons per hour (110 L/ks). What kind of unit is l/ks? Are there SI rules about prefixes in the denominator? Maybe ml/s would be better? Gah4 (talk) 00:26, 19 June 2021 (UTC)

That's because there is no definition for usgal/h so convert does an automatic conversion. Since the example did not provide an output unit, convert did all it could, namely it used the default output for usgal (l impgal) and the default output for h (ks). The default output unit is then constructed from (l impgal)/ks but since that doesn't make sense, convert uses the first unit (l) to conclude that the default output is l/ks. The fix is to specify whatever unit is wanted for the output. That is, it is not a good idea to rely on the default output for automatic units. Johnuniq (talk) 02:29, 19 June 2021 (UTC)

Inconsistency between convert and cvt (in some situations) with regard to non-breaking space placement

Using the Visual Editor, I was adding a garden-variety conversion from feet to meters using {{convert}}.

Clicking on the conversion after I made it (almost by accident), I happened to notice that the input value doesn't have a non-breaking space between the value and the unit, whereas the output value does. As you might already know, when you use the Visual Editor and click on a conversion, non-breaking spaces are shown by faint gray vertical bars.

I then found another (existing) feet-to-meters conversion on the same page, that happened to use {{cvt}}. I noticed that both the input and output values did have non-breaking spaces between the values and units.

Note that I say this happens "in some situations" because I also happened to notice that there seems to be no difference in behavior between the two templates when the conversion is from Fahrenheit to Celsius, for example. Both show non-breaking spaces between values and units, as they should. I discovered this by clicking around to various conversions just trying to get a sense of what was going on.

Thanks! 1980fast (talk) 04:50, 20 June 2021 (UTC)

That's in MOS somewhere: use a normal space before a name, as in "12 feet", but a non-breaking space before a symbol, like "12 ft". Johnuniq (talk) 05:24, 20 June 2021 (UTC)

See MOS:UNITNAMES, search for "between a number and a unit symbol" in the table. -DePiep (talk) 12:05, 20 June 2021 (UTC)

Price per pound: suppress the "1"

"It sold for 50 cents per one pound (0.45 kg)...." gives an undesirable result. What is needed is "It sold for 50 cents per pound...", but with the conversion to kg still shown. Is there a way of doing that? ThoughtIdRetired (talk) 13:21, 28 June 2021 (UTC)

It sold for 50 cents per pound (0.45 kg)... will do it. Someone else may have a better way. MB 16:13, 28 June 2021 (UTC)

That is, in code 50 cents per pound ({{convert|1|lb|disp=out}}) -DePiep (talk) 17:00, 28 June 2021 (UTC)

Or, see #Currency per unit: $/mi → $/km, but maybe less elegant and note the $-cent in the output:

({{convert|50|$/lb|$=cent|disp=out}}) → (110 ¢/kg) -DePiep (talk) 17:07, 28 June 2021 (UTC)

For a bit more elegance {{convert|50|¢/lb}} could just be used to get "It sold for 50 cents per pound (110 ¢/kg))".

To be honest, the units list should be amended to note all the working per currency units rather than saying "The module recognizes "$" and "£" as currency symbols and shows them appropriately" as it works with quite a lot more than just those (¢, ¥, € etc.) without needing the "$=" parameter. --Voello _talk 18:35, 28 June 2021 (UTC)

A third output option for spelling out thousands, etc.?

There are two options already given with respect to abbr=unit and abbr=off when using an e6 prefix.

But what if you want something like:

100 million miles (160 million km)

...in order to mirror the default unit abbreviation behavior seen in other conversions?

Thanks! 1980fast (talk) 20:05, 10 June 2021 (UTC)

The problem being reported is that the following gives output mi rather than miles.

{{convert|100|e6mile|e6km|abbr=unit}} → 100 million miles (160 million km)

There are lots of converts in articles that use mile or miles as the input and currently they are aliases for mi. I don't think adding yet another option is worthwhile so the alternative would be to either add a new unit or change the existing mile/miles so that the name is never abbreviated. That would need thought... Johnuniq (talk) 00:55, 11 June 2021 (UTC)

Thanks! Either of those sounds good to me, with perhaps a slight personal preference for the first approach. Do let me know if you come to a decision. 1980fast (talk) 23:37, 19 June 2021 (UTC)

A new unit needs a new name and that won't be pretty. We could use Mile as the unit code for a miles unit which never abbreviates. Thoughts? Johnuniq (talk) 23:45, 19 June 2021 (UTC)

I've always thought the abbreviation "mi" is quite awkward and usually resort to |abbr=in to get km (miles). I would welcome a non-abbreviating alternative. Stepho talk 01:04, 20 June 2021 (UTC)

OK, that's the easy bit. But do we agree with Mile as the new unit, while keeping mi + mile + miles working as they do now. You might notice I'm hoping to just add Mile and not its plural. That might help people notice that the name has a special meaning, namely that it won't abbreviate, while avoiding the creep of adding every possible alias. Johnuniq (talk) 01:16, 20 June 2021 (UTC)

I overcame my inertia and added Mile as a test:

{{convert|1|Mile}} → 1 Mile^{[convert: unknown unit]}
{{convert|15|Mile|abbr=on}} → 15 Mile^{[convert: unknown unit]}
{{convert|100|e6Mile|e6km|abbr=unit}} → 100 e6Mile^{[convert: unknown unit]}

@1980fast: You might like to try this. Johnuniq (talk) 01:30, 20 June 2021 (UTC)

My preference would be for "mi" to abbreviate and "mile"/"miles" to not abbreviate. That, of course, would change thousands of article (for the better in my opinion but others may differ).

But I can live with "Miles" as the non-abbreviating version if the above raises too many problems. Stepho talk 02:00, 20 June 2021 (UTC)

I agree that having mile/miles not abbreviate would be a better solution and much more natural. If someone complains that they wanted "mi" displayed but wrote "miles" we can point the inherent logical dissonance and ask them to fix it. Johnuniq (talk) 02:11, 20 June 2021 (UTC)

Proposal: unit miles will always output "miles"

From the 20 April 2021 dump of all articles, there were about 1460 unique {{convert}} and 210 unique {{cvt}} which used input unit mile or miles yet output mi. Examples:

Sur, Oman: {{convert|93|mile|km|abbr=on}} → 93 miles (150 km)
Kovan MRT station#History: {{convert|1.3|km|miles|adj=on}} → 1.3-kilometre (0.81-mile)
Cuban Missile Crisis: {{cvt|90|miles}} → 90 miles (140 km)

As discussed above, displaying "mi" is rarely helpful compared with "miles"—the saving of space is inconsequential and it's likely that many readers who would understand miles would be puzzled by mi. Scientific topics (which might want units abbreviated) would rarely use miles. Why would an editor type mile or miles in a convert template if they want readers to see mi? Changing mile/miles so the units never abbreviate would give the very natural result that miles would display miles and mi (if abbreviated) would display mi. In the unique converts, 93,500 use mi and 4,400 use mile or miles. Thoughts? Johnuniq (talk) 07:50, 29 June 2021 (UTC)

I suspect many of the 93,500 uses of "mi" are just because editors copied it from the units list. Never-the-less, I think your proposal is the right way to go. Stepho talk 08:51, 29 June 2021 (UTC)

I am not sure about the wisdom of duplicating functionality, i.e. offering multiple means of getting the same effect. My feeling is that this is best done explicitly, by passing appropriate arguments (e.g. abbr=whatever) to the template, not by the template trying to infer what the user wants by the way in which the unit names/symbols/abbreviations are written. Not least because you'd then have to define a hierarchy of what overrides what, e.g. "miles" with "abbr=on" (or "cvt" with "miles"). And this might not be intuitive to everyone. Moreover, I do not see the contexts in which "mi" occurs as likely to be ambiguous: nobody is likely to see "80 km (50 mi)" and think "mi" means "millinches" or some such. Archon 2488 (talk) 08:56, 29 June 2021 (UTC)

To those of us familiar with units, it's obvious what mi means. I guess that readers from many parts of the world would not be familiar with miles (they would use km) and would stumble when seeing "mi". They could probably work it out, but have a look at the three examples I gave above: the article would be better if "miles" were shown. This proposal follows from the question in the original section, namely how to make e6mile display something better than "million mi". Johnuniq (talk) 09:07, 29 June 2021 (UTC)

+ in tables

At List of longest buildings#World there is a need to add the conversion for "3000+ m". The best I've found is {{convert|3000|m|ft|disp=table|sortable=on|adj=pre|+}} but that shows only the + only in the first column:

m	ft
3,000+	9,800

Is there a way to get the + into both columns? Thryduulf (talk) 20:07, 18 July 2021 (UTC)

lol, just trying >{{convert|3000|m|ft|disp=table|sortable=on}} does not show the prefixed gt symbol at all?!

m	ft
3,000	9,800

-DePiep (talk) 20:36, 18 July 2021 (UTC)

Could a simple, immune |p, s= (prefix, suffix) be a helpful? -DePiep (talk) 20:39, 18 July 2021 (UTC)

Here's a bodge. -- WOSlinker (talk) 21:01, 18 July 2021 (UTC)

m	ft
3,000+	9,800+

@DePiep: simple p= and s= prefix and suffix parameters would be useful, especially if they were ignored for sorting purposes. Things like "~750" and "3000+" are not uncommon, when it prose it's easy to adjust the phrasing to accomodate the conversion but not so much when in tables. Thryduulf (talk) 13:27, 19 July 2021 (UTC)

Multi line breaks info-box output

Infoboxes are narrow and reading lists of items should be able to display as verticle lists or as a • bullet list.

Only the first conversion has a line break there should be a way to output as a list in a infobox.

This as an example should display as four lines and not only two lines with disp=br.

192,849 acres
301 square miles; 78,043 hectares; 8.400502440×10⁹ square feet

maybe add a new option disp=bl disp=li ?

GSMC(Chief Mike) Kouklis U.S.NAVY Ret. ⛮🇺🇸 / 🇵🇭🌴^⍨talk 12:21, 26 July 2021 (UTC)

@Mkouklis(2): This relates to Dixie Fire. You could use the following.

{{#invoke:string|replace|{{convert|192,849|acre|sqmi ha e6sqft|0|abbr=off|disp=br}}|; | }} →

192,849 acres
301 square miles
78,043 hectares
8,401 million square feet

or

{{#invoke:string|replace|{{convert|192,849|acre|sqmi ha e6sqft|-1|abbr=on|disp=br}}|; | }} →

192,849 acres
300 sq mi
78,040 ha
8,400×10⁶ sq ft

Johnuniq (talk) 07:22, 27 July 2021 (UTC)

Thanx @Johnuniq: several very-large fires CA, OR SPAIN... needing this trick most people can't relate to size parameter "ha" so i'm adding sq kilometers + miles to a few current pages ...also need to add this to this template's documentation l8r ಠ_ಠ
:GSMC(Chief Mike) Kouklis U.S.NAVY Ret. ⛮🇺🇸 / 🇵🇭🌴^⍨talk 11:08, 28 July 2021 (UTC)

Mixed ranges

I have 2 references that put a car's weight at 3559 lb (US) and 1580 kg (Australia). Is there a simple way to put this as a range so that it looks something like "1580-1614 kg (3,483-3,559 lb)" ? Stepho talk 10:28, 10 August 2021 (UTC)

No. I think you would have to rely on WP:CALC to allow using the correct kg input value for the US ref. However, the difference is pretty small and it's possible a US car and an Australian car are somewhat different? Johnuniq (talk) 10:48, 10 August 2021 (UTC)

Yeah, I thought I was asking too much. I guess I got used to convert continuously doing miracles. Thanks anyway. :)

The difference is probably due to little things like slightly different installed options. Stepho talk 12:36, 10 August 2021 (UTC)

Abbreviations

Example: 100 t (98 long tons; 110 short tons) Could we have the output abbreviated as ltons and stons or even Ltons and Stons instead? Peter Horn User talk 00:33, 7 September 2021 (UTC)

There is a useful summary of the ton units at #Changes in spelling of units over time above. That shows unitcode lt gives LT as a symbol but for some reason lost in history, there is no way to abbreviate ST. If there is not enough room for "long tons" and "short tons", consider omitting the convert altogether—does it really matter what the exact number of tons is? At any rate, it would not be desirable for us to invent abbreviations that are not widely recognized. Johnuniq (talk) 00:54, 7 September 2021 (UTC)

110 crore tonnes

For Dedicated Freight Corridor Corporation of India#Need for DFC 110 crore tonnes → {{cvt|110|crt|LT ST|lk=on}} 110 crt^{[convert: unknown unit]} instead of (110,000,000 t [108,300,000 long tons; 121,300,000 short tons]) Peter Horn User talk 19:09, 6 September 2021 (UTC) Peter Horn User talk 19:12, 6 September 2021 (UTC) Peter Horn User talk 19:16, 6 September 2021 (UTC) Peter Horn User talk 19:29, 6 September 2021 (UTC)

Convert only converts units. It does not convert between different number systems. There may be no need to mention "crore" in that article because WP:CALC allows a simple calculation from what a reliable source says. From crore,

110 crore = 110 * 10e6 = 1,100,000,000 = 1.1e9 (1.1 billion)

Assuming a source verifies 110 crore, I would not mention crore in the article and would use:

{{convert|1.1|e9tonne|e9LT e9ST|sigfig=3|abbr=off}} → 1.1 billion tonnes (1.08 billion long tons; 1.21 billion short tons)

Actually (see section immediately above this), this is another example where it is not very useful to convert a large number of tons and the article could simply say "1.1 billion tonnes". Johnuniq (talk) 00:23, 7 September 2021 (UTC)

If I'm not mistaken, "crore" and the #,##,###.## numbering system are used routinely in Indian English, which would be a reasonable choice of dialect for that article. However, "crt" seems like an ad-hoc abbreviation rather than a standard abbreviation that this template could support. Perhaps we should wait until {{Format price}} supports crore before trying to introduce it into this much more complex template system. Minh Nguyễn ^💬 05:26, 3 October 2021 (UTC)

Changes in spelling of units over time

Not sure where it would be best to mention this. Have noticed increasing use of the term "ton" to mean a metric ton (1000 kg), whereas the convert template spells it "tonne" for the metric ton, rather than the old US meaning of "ton" 1 ton = 1 short ton = 2000 lbs, or the former UK meaning 1 ton = 1 long ton.

SpaceX has been doing this for some time, and recently have seen Tesla doing this as well. Example, Tesla in their 2020 Tesla Impact Report says: "In the E.U., electric semi trucks are allowed to be 2 tons (~4,400 pounds) heavier than diesel equivalents, and in the U.S. the allowance is 0.9 tons (2,000 pounds)." (page 24)

The {convert} template seems to only use the full spelling of "tonne" for the spelled out units of the metric ton. I'm curious to know if there is a way to make the metric ton be spelled "ton" using the convert template, rather then "tonne"? Or how we might go about considering making changes in {convert} for spelling conventions that change over many years. Cheers. N2e (talk) 11:06, 21 August 2021 (UTC)

No. I don't think there has ever been a proposal along those lines although it could be discussed now. The problem is consistency because it would be a bit weird if "ton" meant one thing in one article and a different thing in a different article. The situation is a mess. Following is a summary of the mass units for the various forms of tons. The tilde in the symbol column means the symbol is treated as a name and will be plural if the value is not 1. The name1_us value applies if |sp=us.

unitcode    scale          link         default    symbol        name1        name1_us
metric ton  1000           Tonne        long ton   ~metric ton   metric ton
MT          1000           Tonne        LT ST      t             metric ton
t           1000           Tonne        LT ST      t             tonne        metric ton
tonne       1000           Tonne        shton      t             tonne        metric ton
ST          907.18474      Short ton    t          ~short ton    short ton
shtn        907.18474      Short ton    t          sh&nbsp;tn    short ton
shton       907.18474      Ton          t          ~ton          ton
LT          1016.0469088   Long ton     t          ~long ton     long ton
lt          1016.0469088   Long ton     t          LT            long ton

Johnuniq (talk) 23:42, 21 August 2021 (UTC)

Don't know that I have gathered enough data on the use of "ton" for a metric ton in US English, but it is certainly common in a subset of descriptive English use as I see it. (but then, I do read a lot in the spaceflight arena, environmental emmisions, and electric vehicle technology advancement).

It does seem to me like a spelling option could be given in the {convert} template that would allow alternatively used spellings, while at the same time, since it is the excellent WP:CONVERT amazingness, the units would always be available in at least two, and perhaps three, units to make the quantitative tonnage grokable by our article readers.

The US short ton and UK long ton already seem quite deprecated to me; but perhaps it will take more years and more WP:COMMON usage in English language evolution relative to the "mess" (I agree with you!) of ton-related weights before this makes sense. I really don't know. But very interested to see if other editors weigh in. Cheers. N2e (talk) 11:51, 22 August 2021 (UTC)

It would be a brave soul who chose this hill to die on because the traditionalists will fight to the death over it. But it might be a good idea to discontinue support for the ambiguous word 'ton' first; it someone tries to use it, the template would demand that they disambiguate. Any support for that idea? --John Maynard Friedman (talk) 16:05, 22 August 2021 (UTC)

Convert does not accept ton as an input ({{convert|1|ton}} gives an error). As an output, "ton" can only occur with the unit shton. There are about 14 converts using shton in articles, examples:

Big Sur • {{convert|493|shton}} → 493 tons (447 t)
Liberty Bell (Portland, Oregon) • {{Convert|1|shton|kg}} → 1 ton (910 kg)

I don't know if there is a good way to handle this. Johnuniq (talk) 05:22, 23 August 2021 (UTC)

I think it's good that the template does not accept ton as an input. When I listen to US news media, I often hear "metric ton", so I infer that ton still means 2000 pounds in general US usage.

If I'm the one choosing which unit name to use for a measurement in the appropriate range, I'll choose Mg. Jc3s5h (talk) 08:26, 23 August 2021 (UTC)

I really like the idea of John Maynard Friedman who suggested we might want to start the conversation on deprecating, or not using, the ambiguous term "ton". It sounds like it already is deprecated on the input (to {convert}) side (per Johnuniq); perhaps we could do the same on the output side, and have the template output only unambiguous "short ton" "long ton" or "metric ton" or "tonne". Makes the implicit (and ambiguous), explicit.

Both "short ton" in the US and "long ton" in the UK were traditionally called "ton" historically. And I can produce multiple modern instances in journalism and websites that use "ton" today to mean "metric ton" (1000 kg), from the disciplines of spaceflight, environmental pollution emissions, and electric vehicles. Net, "ton" is just an ambiguous term, both in past history, and today. So making the term deprecated in Wikipedia via the {convert} template seems a potentially quite useful path. (especially if it is only used 14 times today in the shton way). N2e (talk) 15:35, 23 August 2021 (UTC)

A problem that I have faced is that sources usually give no clue what "ton" is intended—they assume everyone knows what they mean, or that it simply does not matter since, for example, "120 tons" means a "very large amount" in common English and knowing what kind of ton would usually be pointless. We can often guess what was intended but that's not exactly what WP:RS had in mind. As an indication of the scale of the problem, consider a search for "0 tons". Johnuniq (talk) 00:18, 24 August 2021 (UTC)

By the way, this search seems to work to find where the shton unit is used. Johnuniq (talk) 00:28, 24 August 2021 (UTC)

Thanks for that search link, Johnuniq.

On your observation that sources that use ton may not give a clue which is intended: I agree. Have seen that too. But that is a problem with a source to be resolved at the article level (or possibly with some input from a WikiProject on how the term is used in a particular industry.)

I do not think that observation is a good rationale for us to not consider John Maynard Friedman's idea: "discontinue support for the ambiguous word 'ton' first [on the output side of {convert}; since it already is on the input side]; if someone tries to use it, the template would demand that they disambiguate." In other words, just because a media source is unclear, there is no reason for the {convert} template to lead template users to wrongly presume that if ton is used in a source, then what the source must mean is 'shton'. If the editor uses ton = 'shton' via our template when the source is unclear, as many are in the 2020s, then we are furthering the misunderstanding, when the source was unclear in the first place. N2e (talk) 11:54, 24 August 2021 (UTC)

"I cannot tell a lie", I failed to appreciate (aka check) that the template already refuses unqualified 'ton' on input (and, if the editor specifies 'ton' as output, gives both short and long tons). No case to answer. --John Maynard Friedman (talk) 12:38, 24 August 2021 (UTC)

I don't know if this is possible, but it would be interesting to check for sigfig=1, in which case all the different ton are close enough. There are times when ton is used for a large, but not all that well specified mass. (My favorite is a gym that advertises tons of equipment.) Gah4 (talk) 17:33, 12 October 2021 (UTC)

Mach Speed

I was editing an article and realised Mach speed conversion is not supported. It is very common in aviation & aeronautics. Example: 15,345 miles per hour (24,695 km/h; Mach 20) would yield 15,345 mph (24,695 km/h; Mach 20) Crnorizec (talk) 19:46, 7 September 2021 (UTC)

OK, it does now... Crnorizec (talk) 19:49, 7 September 2021 (UTC)

Just wondering, since the speed of sound varies with temperature, and fast jets normally fly at higher (cooler) altitude, which speed does it use? Gah4 (talk) 22:11, 7 September 2021 (UTC)

Mach is not fully documented and it doesn't work well when used as an output. As an input, an additional number following Mach is the altitude in feet (default 0 = sea level). Negative altitudes (in a valley below sea level) are allowed. However, as an output, there is no way to specify the altitude so the number given is for sea level. The following illustrates use as input.

{{convert|20|Mach}} → Mach 20 (24,500 km/h; 15,200 mph)
{{convert|20|Mach|mph km/h}} → Mach 20 (15,200 mph; 24,500 km/h)
{{convert|20|Mach|0|mph km/h}} → Mach 20 (15,200 mph; 24,500 km/h)
{{convert|20|Mach|50,000|mph km/h}} → Mach 20 (13,200 mph; 21,200 km/h)

Johnuniq (talk) 23:50, 7 September 2021 (UTC)

Because of the altitude and temperature thing, I don't think this should be supported, unless you want to do something like Mach_sl. GliderMaven (talk) 18:35, 11 October 2021 (UTC)

Deserves a dedicated template/module (ie, with multiple output values, like @-values). Then, this can be done well-defined, right? -DePiep (talk) 20:22, 11 October 2021 (UTC)

In April 2021, the Mach unit appeared in 101 {{cvt}} and 245 {{convert}} = 346 total. That is a reasonably small number so it would be possible to change convert by:

Creating a new parameter |altitude= so the altitude could be specified for input and output.
Editing articles to replace current usage with the new parameter.
Giving an error if Mach is used without an altitude (that is, the new parameter would be mandatory).

I'll slowly see what would be involved in the module. Johnuniq (talk) 01:33, 12 October 2021 (UTC)

I think that what is being done right now is incorrect, since thee speed of sound varies with the square root of the the air temperature, not with the altitude (the relationship with the altitude is only indirect). The formula that should be used is the one based on the practical formula for the speed of sound, :

c_{\mathrm {air} }=20.05~{\sqrt {T}}~~~~\mathrm {m/s}

, which gives results accurate within 0.02%. If you'll want to use the tables at http://www.aerospaceweb.org/question/atmosphere/q0112.shtml, the template for the conversion should force the user to input the altitude. There are editors using the current conversion formula indiscriminately, because there is no warning on its use, and as a result conversions used in the articles are vastly incorrect. See for instance the article on Blue Origin, which before my corrections showed results that were presumably off by 13%.--Gciriani (talk) 20:21, 14 October 2021 (UTC)

Sure, temp related. In RL, that temp is overwhelmed by (& defined by) the stratospheric heigth. IOW: above ~5km, Mach is stable per temp, dependent on alt. See ->

-DePiep (talk) 20:51, 14 October 2021 (UTC)

@Gciriani: The problem you are reporting is that at Blue Origin a source (example) might say "top speed of Mach 3" and an editor then puts {{cvt|3|Mach}} in the article without knowing that an altitude is required for the conversion to make sense. The source does not specify the altitude so a conversion is not possible without a bunch of original research, or a better source which does the conversion. They use "Mach 3" to mean "very fast" and the exact speed in km/h is not really the point. However, it will be an ongoing problem because wikignomes will return to that article every year and insert conversions.

Re convert, it uses the table from aerospaceweb.org although the website's table goes to 400,000 feet while convert's table stops at 300,000 feet (anything over that altitude is truncated to 300,000). I could extend the table and fix some other issues. Are you saying that using aerospaceweb's table with a mandatory altitude would be sufficient (although it wouldn't help at Blue Origin where the altitude is unknown)? Johnuniq (talk) 01:07, 15 October 2021 (UTC)

I'm not sure what DePiep meant by above 5 km. In standard atmosphere, which is the graph he posted, temperature keeps decreasing up to 11 km to -55 C, then it stays constant up to 20 km, and then it increases again. But that's beside the point I made. Temperature is an accurate predictor of speed of sound, while altitude is not, because depending on the atmospheric conditions the speed of sound varies much more, depending on the atmospheric pressure; instead given a certain temperature, no matter what the altitude or the pressure are, the speed of sound is determined. Therefore either the user of the conversion enters the temperature, or the conversion should not be performed.

Regarding the example I gave of the Mach numbers described in the article for Blue Origin, it suffices to say that journalists are fed Mach numbers by the PR people, because that impresses them; so they always try to give the largest Mach number hit during the flight. In this specific case the rocket hit Mach 3 at 2,228 mph (about 3,575 km/h)and 150,519 ft, which you can see in this video at 1:43:50; at that altitude (46 km) the graph you provided gives for standard atmosphere a temperature of 263 K, which equates to a speed of sound of 1,170.6 km/h or 729 mph, which would equate to Mach 3.05, well within the approximation provided by the citation provided in the article. However, the conversion formula before I deleted it from the article provided 3,675 Km/h, which is 3% more than the correct value.

I hope this helps explain the physics of the Mach number, and the problems the conversion creates. Regarding Johnuniq reply, I will have to get back to it tomorrow.--Gciriani (talk) 03:11, 15 October 2021 (UTC)

Take your time, I certainly will. The convert you removed from the article had no altitude so it defaulted to zero (sea level). I think you are saying there should be a temperature parameter and not an altitude parameter. I don't see how that could work because it's very likely that sources will say something like "Mach 3 at 25,000 feet" and will never mention the temperature (whatever that means: the temperature 1 cm behind the engine exhaust? the temperature 1 cm from the side of the vehicle? the average temperature of the air that sound would have to travel through to reach the observer?). Johnuniq (talk) 04:16, 15 October 2021 (UTC)

Speed_of_sound#Mach_number explains the use of altitude for airplanes. They use altitude as a substitute for temperature, so, at least in the case of airplanes, we should be able to. Most often, for the common use for airplanes it should be close enough. I suspect that in most cases sigfig=1 would be a good choice. (When it says Mach 3, it has one sigfig.) This one explains the temperature vs. altitude relation in more detail. It varies as the square root of absolute temperature. From 0C to 40C it changes by about 7%. At higher altitudes, temperature changes less. At much higher altitudes, it gets more complicated as the mean free path for molecules is much longer, approaching the wavelength of sound(s). Gah4 (talk) 08:04, 15 October 2021 (UTC)

The more I think about it, the more I come to the conclusion that Mach should not be in the conversion table. As we are exposing in this talk, it is a formula with more than one variable, and it is not a conversion of one unit to another.--Gciriani (talk) 12:32, 15 October 2021 (UTC)

The aim of {{Convert}} is to help articles, not to reproduce physical calculations. Since sources commonly use "@alt" as a specifier, it is perfectly allright the {{Convert}} handles this. If there is a need to use "@temp" wihin the convert aim in articles (is there?), we can ask for inclusion of this variable. -DePiep (talk) 19:14, 15 October 2021 (UTC)

Between about Mach 0.95 and 1.05, you probably want to be at least a little bit close. Otherwise, sigfig=1 is probably about right. With air mixing and adiabatic cooling, the temperature of the air at important altitudes is likely close enough. There are sill many conversions that are done without {{convert}}, and making it harder to use will increase that. In this case, likely someone will just use the sea level value. Can we force sigfig=1? (I suspect it should be for many other conversions, too.) Gah4 (talk) 20:28, 15 October 2021 (UTC)

I agree with John that temperatures are rarely given in sources - therefore any arguments requiring temperatures are a moot point in spite of being technically correct.

It would be very unusual for an aircraft going fast enough to be measured in Mach numbers to be at sea level. From the graph above, 10-20 km altitude seems to have a reasonably constant speed of sound, with only small deviations up to 30 km. 10-30 km is also where the majority of fast airplanes will be operating. I suggest we change the formula to use a default of 20 km altitude. In that way, conversions where no altitude is given are likely to be more accurate - at least to the level of precision suitable for a general audience. Worse case is for an altitude of 50 km giving an error of 10% (330 m/s vs 295 m/s). Since the conversion to km/h or mph is more of a general indication of a jet fighter doing 3000 km/h vs an airliner doing 1000 km/h, then this should be suitable. Luckily for us, the extreme cases (eg, jet fighters, record breakers) also tend to give altitude in the references, so we can be a bit more accurate anyway in those cases. Stepho talk 00:35, 16 October 2021 (UTC)

The bottom line is that if a conversion gives a result with an approximation of 3%, as I've proven in my comment above, it shouldn't be used. So what is the alternative?--Gciriani (talk) 00:49, 16 October 2021 (UTC)

If the Mach number has one significant digit, then 3% is plenty close enough. If it has two, it is probably close enough, especially if the first digit is 1 through 3. Without using this, people are likely to use some worse choice, and three or four digits. Gah4 (talk) 02:32, 16 October 2021 (UTC)

Then the mph and the km/h should not have four signigficant digits either.--Gciriani (talk) 02:52, 16 October 2021 (UTC)

If the source has one sigfig, we cannot improve that (even near 1.00). In general, a conversion should not suggest more precision tthan the source has. (so forcing |sigfig=1 is not a good plan. -DePiep (talk) 06:41, 16 October 2021 (UTC)

I put a list of all 153 unique converts in articles from April 2021 where Mach is used with an altitude in my sandbox (permalink). I'm interested in far too many things and don't have time to examine the details of how Mach works. The issue for this page concerns what should happen with the Mach unit as far as convert is concerned. I'm inclined to think there should be no default altitude—omitting the altitude should result in an error—because it appears the value is meaningless without an altitude (or preferably, according to above, a temperature which is never going to happen). Are any of the values shown in the sandbox significantly wrong? What should convert do? Johnuniq (talk) 06:53, 16 October 2021 (UTC)

Unless I missed some, all the entries in your sandbox have an altitude. Your proposal to make it an error to have no altitude puts the issue in the hands of the editor and makes it obvious that something needs to be done. The editor is often the only entity that can make a rational choice. If the source has no altitude then Mach cannot be converted - which is the correct thing. So I'm happy. Stepho talk 07:06, 16 October 2021 (UTC)

Thanks but what I hoped was that people would check a few of the converts. The list is intended for those saying that temperature is needed. What I'm wondering is whether that would make a significant difference to the results shown. Johnuniq (talk) 09:15, 16 October 2021 (UTC)

Mg vs tonne

I had a look at this page and had the typical frustration of the SI influenced engineer: tonnes are non-SI. But for some reason Wikipedia's convert function assumes that SI only goes up to kg, which is clearly incorrect. SI also has an equivalent for the tonne, the megagram (Mg). There also is the Gg for ships for instance. How can I lobby for the convert{} function to be adapted accordingly? — Preceding unsigned comment added by Lordarpad (talk • contribs) 23:19, 16 October 2021 (UTC)

1 megagram (1,000 kilograms)

1 megagram (1.0 tonne)

What is your question? -DePiep (talk) 23:35, 16 October 2021 (UTC)

This? 10,000,000 pounds (4,500,000 kg) or this 100 long tons (100 t)? Then why not specify the output thus 10,000,000 pounds (4,500 Mg) or thus 100 long tons (100 Mg)? Is that you don't like the default action? --John Maynard Friedman (talk) 23:53, 16 October 2021 (UTC)

I would recommend to avoid Mg or Gg. Engineers will know what they are and how much they represent but the average reader will not understand them at all or possibly understand them merely as "big". Stepho talk 00:04, 17 October 2021 (UTC)

@Lordarpad: Convert supports the use of all SI prefixes with appropriate units. The documentation is long and it can be hard to find things, but searching Template:Convert for "SI" using a case-sensitive search (often called "match case") will find the documentation. As DePiep points out above, the unit Mg (and all other SI variations) works, but as Stepho-wrs says, using Mg would rarely be helpful because Wikipedia is supposed to be for general readers, not just engineering types who would recognize that unit. Johnuniq (talk) 02:36, 17 October 2021 (UTC)

Multiple values in Wikidata

Infoboxes that automatically convert data retrieved with {{PH wikidata|elevation_m}} can't handle cases when WD has multiple values for this field. I really don't see how this has anything to do with {{convert}}. Since it would be wrong to do anything like arbitrarily uses the first value, or use an average, I think this problem lies at the source in WD. See User talk:Mike Peel#Wikidata question for the background. MB 20:37, 25 October 2021 (UTC)

Convert has limited syntax for retrieving values from Wikidata, see Template:Convert#Using convert inside templates. If you edit any section at Mendez, Cavite and replace its contents with {{convert|input=P2044|3=m|disp=number}}, a preview will show that it retrieves the value you fixed at Wikidata. I forget what happens if there is more than one value, but it's probably not helpful. A difficulty is that I despise the model used for Wikidata—in brief, it's write-only data with no thought given for how a program could extract useful information and no promises about the future except that things will break. Johnuniq (talk) 02:58, 26 October 2021 (UTC)

So you agree that this has nothing to do with convert, and that the problem with multiple elevations in WD should/cannot be addressed by converts' "built-in Wikidata support"? When there is more than one value, the article is in Category:Pages with bad rounding precision - where you will see four new articles today with this problem (and look at one of the articles to see how ugly this looks). MB 03:26, 26 October 2021 (UTC)

Thanks for the example. Please do not fix Santo Tomas, Isabela for a couple of days so I have a chance to investigate. That's another annoyance of Wikidata, namely that there is (I think) no way to test what happens here if certain properties are set there. I imagine it's very much to do with convert, but I'll look at it later. Johnuniq (talk) 04:25, 26 October 2021 (UTC)

I've finished investigating and the problems can be fixed now if you like (the fix would be to remove one of the duplicate elevation values in Wikidata). At Santo Tomas, Isabela, the infobox has

| elevation_m = {{PH wikidata|elevation_m}}

The result from {{PH wikidata|elevation_m}} is the output from the following (this uses fixed wikitext to show what happens now):

{{convert|input=P2044|3=m|disp=number}} → 30, 33

{{Infobox settlement}} then does its own calculation and tries to use 30, 33 as a single value. I haven't examined that code but it understandably fails. From my point of view, convert is working as advertised, and no doubt the Wikidata people would say the same, as would the infobox people. Not our problem. In principle there could be a new parameter to tell convert to return only the first value but I would be reluctant to bolt on another Wikidata band-aid. The reason convert is being used is that the Wikidata entry could specify the elevation in another unit, say feet. Convert would return that converted to metres. Johnuniq (talk) 09:30, 26 October 2021 (UTC)

Different approach: en:Module:WikidataIB (ie, IB=infobox-aimed). This wd-data reader has multiple parameters to tweak the result. For example, |rank=: the WD-rank of a single property value can be "preferred", and selection by this would reduce the number of returned values (though WD does not limit Preferred to a single value).

See also Module:WikidataIB § Limiting the returned values, Module:WikidataIB § Parameter sets: clues to returning single values. (end of my current research) -DePiep (talk) 12:16, 26 October 2021 (UTC)

The root problem is the data in WD is unreliable. I don't think there is a basis to expect that the first value in WD is likely to be the "most correct" value. I agree this is the wrong place to discuss this, I just came here reluctantly after Mike Peel pointed this way. Maybe the best we can do on this end is have {{infobox settlement}} detect multiple values in the field, not display anything, and put the article in Category:Articles using infobox settlement with invalid elevation data. MB 01:20, 28 October 2021 (UTC)

The more general question is what should an infobox do if a parameter should be a number but is not. It's hard using template wikitext to make everything handle all inputs so the current situation (whereby the infobox displays a misleading message and outputs a tracking category) may be the best achievable. Johnuniq (talk) 01:40, 28 October 2021 (UTC)

Rack units?

Does convert handle rack units? It's a unit of length equal to 1.75 inches, commonly used in the electronics and computer industries. See Special:Diff/1052328533 for an example. -- RoySmith (talk) 15:42, 28 October 2021 (UTC)

No, that unit is not supported. I could look at if really needed but the lack of a space in "9U" would be a first for convert and might require a fair bit of stress. Convert does have provision to omit the space for things like $2/ha and for some units at zhwiki so it would just need some serious thought. However, it's more than adding a normal unit. Johnuniq (talk) 23:14, 28 October 2021 (UTC)

Might be easier to develop a new template {{rack unit}} that deconstructs something like {{rack unit|9U}} into a real number of inches that it feeds in turn into convert. --John Maynard Friedman (talk) 00:03, 29 October 2021 (UTC)

In conjunction with Roy, I have developed a new template, {{rackunit}}, which provides this function. For example "This is a {{rackunit|9}} rack-mounted server". produces "This is a 9U (15.75 in, 40 cm) rack-mounted server". This is my first such template so critical appraisal is welcome. --John Maynard Friedman (talk) 19:48, 29 October 2021 (UTC)

Thanks, that's good. You might surround the wikitext with includeonly tags so it doesn't look ugly on the template page. Johnuniq (talk) 23:29, 29 October 2021 (UTC)

or(-)

I just noticed the template supports and(-) and to(-) as options (to display a range of / multiple values differently in the primary vs secondary) but not or(-). Is there a reason for this? Would it be straightforward to add it? Archon 2488 (talk) 20:21, 6 November 2021 (UTC)

What would or(-) mean to say, in {{Convert}} context? Did you meet it in an article or in a source? -DePiep (talk) 20:32, 6 November 2021 (UTC)

It could be added but I'm not sure it would be useful. Per DePiep, is there somewhere this would help? For reference, the following shows examples. The last one (or(-)) is not implemented and the output is simulated wikitext.

{{convert|12|to|18|kg}} → 12 to 18 kilograms (26 to 40 lb)
{{convert|12|and|18|kg}} → 12 and 18 kilograms (26 and 40 lb)
{{convert|12|or|18|kg}} → 12 or 18 kilograms (26 or 40 lb)
{{convert|12|to(-)|18|kg}} → 12 to 18 kilograms (26–40 lb)
{{convert|12|and(-)|18|kg}} → 12 and 18 kilograms (26–40 lb)
{{convert|12|or(-)|18|kg}} → 12 or 18 kilograms (26–40 lb)

Johnuniq (talk) 00:22, 7 November 2021 (UTC)

Helper function: accept basic value input

We need a Helper function that can read & feed regular source-&-keyboard value inputs for {{Convert}}.

IMO it is useful in an Infobox template (backoffice) that has like |height=. So: the template editor uses it, and the article editor can enter simple and natural entries. For example, {{Infobox person}} has |height=, but with many prescriptions. Why not expect & parse simple |height=1.74m and |height=5ft6 in?

Many & most input for {{Convert}} is basic the quantity value: number × unit. (Allow me: ranges, sigfig input : sure, later more).

-DePiep (talk) 21:10, 4 November 2021 (UTC) (Module:Convert/helper)

Many infobox person templates already accept free form input. I've never investigated how it works but it seems very effective. Johnuniq (talk) 00:25, 7 November 2021 (UTC)

Related discussion at WT:MOSNUM

There is a discussion at Wikipedia talk:Manual of Style/Dates and numbers#Evidence? which includes the suggestion that {{Convert}} support US liq pt and US liq qt (for US liquid pint and US liquid quart) rather than US pt and US qt. NebY (talk) 18:25, 11 November 2021 (UTC)

u-value (mpg redux)

Should this work?:

{{convert|2|m2/W|W/m2|abbr=on}} = 2 m²/W (^{[convert: unit mismatch]})

I was thinking it should give something like:

{{convert|2|m2/W|W/m2|abbr=on}} = 2 m²/W (0.5 W/m²)

I figure the conversion should be valid if the dimensional units are exactly the same, but inverted (e.g. "area/power" to "power/area"), and then the value should units converted, but then inverted as well. It's a generalization of the mpg conversion.

I was thinking it could also work like:

{{convert|2|W/m2|ft2/W|abbr=on}} = 2 W/m² (5 ft²/W)

These kinds of things are pretty common in the real world. I was thinking specifically about u-value/r-value and mpg, but I think it's much more common than that. GliderMaven (talk) 05:23, 7 November 2021 (UTC)

No, convert is not that clever. The error message it gives (on mouse-over) is Cannot convert "area/power" to "power/area". I think it would require the creation of four new units (m2/W, W/m2, ft2/W, W/ft2) and creative use of the "invert" option although I haven't looked at that for a long time (not since one of your last visits here!) and don't know if it would work. I take your word for it being used somewhere, but I find it hard to imagine that text like that appears in articles here? Johnuniq (talk) 05:51, 7 November 2021 (UTC)

Quintal

Like to conversions for these in various countries! Lfstevens (talk) 20:13, 24 November 2021 (UTC)

What is a qunital? I think it has never been mentioned here. Is it a well-defined unit? Please give some examples where a conversion would be used in articles. Johnuniq (talk) 01:22, 25 November 2021 (UTC)

Do you mean quintal ? Stepho talk 10:29, 25 November 2021 (UTC)

Sorry. Quintal. Lfstevens (talk) 00:02, 26 November 2021 (UTC)

Our quintal article indicates there are many different historic and modern definitions, with some traditional uses still co-existing with modernised ones, varying between countries and even within particular countries. I fear drive-by additions of {{Convert}} by editors that don't know which definition of quintal the source used. NebY (talk) 11:20, 25 November 2021 (UTC)

Good point. The unit is used in our corpus, so some effort may be warranted. Lfstevens (talk) 00:02, 26 November 2021 (UTC)

I predict this will cause tons of trouble. E Eng 04:01, 26 November 2021 (UTC)

Or even tonnes. --John Maynard Friedman (talk) 21:55, 26 November 2021 (UTC)

My point exactly. E Eng 01:18, 27 November 2021 (UTC)

Weird behaviour when target unit is specified as 1

Consider {{convert|0.1|km2|1|abbr=on}} (0.1 km² (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on}} (0.1 km² (0.039 sq mi)). I don't know why the first one works at all, but if there's a reason for it to produce square miles at all, I'd expect precision to be the same.

Consider also {{convert|0.1|km2|1|abbr=on|sigfig=20}} (0.1 km² (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on|sigfig=20}} (0.1 km² (0.038610215854245 sq mi)). This makes the weird behaviour even more apparent -- it seems that using 1 as units sets precision to a fixed, low, level and prevents it from being changed.

81.6.39.198 (talk) 20:22, 26 November 2021 (UTC)

Read section Round to a given precision: use a precision number in the template. The "1" in your examples is specifying a precision (one digit). Tarl N. (discuss) 20:26, 26 November 2021 (UTC)

Thanks. I can't find anything in documentation that would indicate that the target unit is optional. Could you point me at a something that specifies what happens when the target unit is missing? 81.6.39.198 (talk) 20:35, 26 November 2021 (UTC)

Is this what you are asking? Help:Convert units#Default output. The actual defaults are listed at Module:Convert/documentation/conversion data. MB 23:52, 26 November 2021 (UTC)

Convert knows that "1" is a number and not a unit. Therefore it uses 1 for the output value precision, and regards the output unit (the target) as unspecified. Convert then uses the default output unit—see the full list of units. Help:Convert#Quick start is useful. Johnuniq (talk) 23:57, 26 November 2021 (UTC)

Convert is an amazing piece of machinery, but there are places where a less terse input interface might have been better. E Eng 01:26, 27 November 2021 (UTC)

Agreed. See http://en.wiki.x.io/w/index.php?title=Vananui&diff=1057305451&oldid=986493280 for a case where someone obviously didn't intend what they wrote (which produced "0.0 sq mi" conversion), but it was unclear what was actually intended. 81.6.39.198 (talk) 02:17, 27 November 2021 (UTC)

Out of interest, what are people expecting |1 to do? Stepho talk 03:16, 27 November 2021 (UTC)

I don't know. It was like that since the page was created, with the obviously broken result of saying "0.0 sq mi", so clearly restricting precision was not what was intended. An issue was that e.g. I couldn't easily figure out what that expression meant, so I expect that some people before me were similarly confused and didn't fix the obvious brokennness. 81.6.39.198 (talk) 03:34, 27 November 2021 (UTC)

People are in the habit of putting "|1" because they think otherwise convert might show too many significant figures and the editor hopes their habit is better than what convert can do. Sometimes they are right, but often they are not. Clearly they don't notice the bad results that occur such as in this case. Johnuniq (talk) 03:47, 27 November 2021 (UTC)

I suspect a lot of people are doing Voodoo programming, where they copy an example from somewhere, without knowing what most of the parameters do but maybe get it somewhat close by editing the main input number and the unit. Sadly, we can't really simplify convert without also giving up lots of its benefits. Thankfully, it does a good job with defaults when minimal parameters are used. Stepho talk 04:09, 27 November 2021 (UTC)

Good point. I used to do a lot of cleaning of converts to reduce the number of bad examples that might be copied elsewhere but I got a bit tired of it... Johnuniq (talk) 04:26, 27 November 2021 (UTC)

Couldn't we make the "number of digits" precision a keyword argument? Obviuosly we can't remove the positional argument (at least without a large amount of semiautomated edits), but if we added a possibility to use it as a keyword argument and changed the documentation to suggest that in the first place, we'd eventually make the kind of confusion I had when I thought "1" represented units less common. — Preceding unsigned comment added by 81.6.39.198 (talk) 11:31, 27 November 2021 (UTC)

Yes, thank you. 81.6.39.198 (talk) 02:17, 27 November 2021 (UTC)

Link for deadweight ton

Hi, the link for deadweight ton (DWton) currently links to tonnage and not Deadweight tonnage; could this be fixed? Thanks. Iazyges Consermonor Opus meum 18:58, 29 November 2021 (UTC)

Thanks for the report. I have made a note to change the link from Tonnage to Deadweight tonnage for units DWton and DWtonne. That won't happen for a while—I'll need to do another check of the other units. Johnuniq (talk) 09:51, 30 November 2021 (UTC)

An error in miles to km conversion

You can see the error just glancing at it. A kilometer is much less than a mile, and a square kilometer is even less when compared with a sq. mi. If you subtract a sq. mi. you have to subtract at least one sq km:

According to the U.S. Census Bureau, the county has a total area of 944 sq mi (2,440 km²), of which 943 sq mi (2,440 km²) are land and 0.3 sq mi (0.78 km²) (0.03%) is covered by water.^[1]

My calculator says 942 sq mi is 2439.7 sq km, rounding up is OK, but 943 square miles are 2442.3 sq km. If you're interested, it's from Brooks County, Texas. deisenbe (talk) 04:20, 8 December 2021 (UTC)

The article passed 944 to convert, when the actual number in the source is 943.3. The article now reads:

According to the U.S. Census Bureau, the county has a total area of 943.3 sq mi (2,443 km²), of which 943 sq mi (2,440 km²) are land and 0.3 sq mi (0.78 km²) (0.03%) is covered by water.

This makes the sqmi numbers add up as expected. Adding precision eliminates rounding in the sqkm:

According to the U.S. Census Bureau, the county has a total area of 943.3 sq mi (2,443.136 km²), of which 943 sq mi (2,442.359 km²) are land and 0.3 sq mi (0.777 km²) (0.03%) is covered by water.

which shows convert is correct.MB 05:14, 8 December 2021 (UTC)

This example really goes straight to the heart of the overprecision problems so rampant on the project. E Eng 06:06, 8 December 2021 (UTC)

Looks like it automatically rounded km to 3 digits (same as the 3 digit input). So we tell it to round to units (ie 0 digits after the decimal point) by adding |0 like so:

{{convert|944|sqmi|abbr=on|0}}, of which {{convert|943|sqmi|abbr=on|0}} ---> 944 sq mi (2,445 km²), of which 943 sq mi (2,442 km²)

Convert does the right thing most of the time, so we get confused when it gets it wrong. Stepho talk 10:57, 8 December 2021 (UTC)

@EEng: please read the post that is right above & before yours (05:14, by MB). Your post does not respond. Or, more precise: you are denying/ignoring the wellbased claim stated. Also, one wonders how your contribution actually tries to forward the discussion. -DePiep (talk) 11:35, 8 December 2021 (UTC)

My almanac says it's a full moon, and sure enough De Piep has risen from his coffin^[2] to huff and puff and take umbrage at things he doesn't understand. My point is that mindlessly barfing out a Venn diagram of every sum, difference, and percentage doesn't serve the reader. In this case, it would have made more sense to write simply The county has a total area of 943.3 sq mi (2,443 km2), of which 0.3 sq mi (0.8 km2) (0.03%) is water. Then the issue wouldn't have come up in the first place.

BTW, the article's discussion of immigrant deaths and so on is a complete mess. Between 2009 and 2018, over 600 bodies were recovered, and according to sheriff's deputy Benny Martinez, the corpses never found are 5 to 10 times more numerous than those found – how stupid can you get? If they're not found, how do you know how many there are? E Eng 14:01, 8 December 2021 (UTC)

Apart from anything possibly helpful, this reply is a personal attack and sign of harassment. EEng please redact. -DePiep (talk) 14:33, 8 December 2021 (UTC)

Whatever. Do you have anything to say about {convert}, or precision, or how to present the land and water areas of political divisions, or anything else remotely connected to article writing, or will you instead continue parading your apparently congenital incomprehension (see, for example WP:Administrators'_noticeboard/IncidentArchive1018#EEng_agression) and whining that you're being harassed? E Eng 19:24, 8 December 2021 (UTC)

Gentle(!)men, this discussion does neither of you credit. It just shows kneejerk reactions and shouting past each other and competition for the silliness award. If this escalates much further, you know what sanctions to expect. Just take a voluntary 24 hour topic ban each, please. --John Maynard Friedman (talk) 20:35, 8 December 2021 (UTC)

Kneejerk reactions? I've made a salient point about the presentation of land and water areas in the subject article, and I look forward to continuing discussion of that point with anyone interested. That meanwhile DePiep keeps buzzing about like an annoying bluebottle is an unrelated and unimportant matter; he's had this weird preoccupation with me for some years now (see my link just above) so I'm used to it. E Eng 03:12, 9 December 2021 (UTC)

to recap: EEng at 11:35 I asked a question [11] about the relevance & relatedness of your 06:06 post. Your reply then broke the #1 WP:PA guideline Comment on content, not on the contributor. -DePiep (talk) 07:27, 9 December 2021 (UTC)

You are truly a marvel of the universe. E Eng 15:58, 9 December 2021 (UTC)

I knew frogs had coffins. But bluebottles too? Who knew! Martinevans123 (talk) 16:09, 9 December 2021 (UTC)

References

^ "2010 Census Gazetteer Files". United States Census Bureau. August 22, 2012. Archived from the original on April 19, 2015. Retrieved April 19, 2015.
^ Mixing werewolf and vampire imagery here.

Help with rounding please

Can anyone advise please, how best to use the convert template to round one of the outputs but not the other. I've got this: {{convert|246|bhp|kW PS|order=flip|disp=x|; |abbr=on}}, which produces this: "183 kW; 249 PS; 246 bhp", but I want the middle value to be rounded to the nearest 10, to look like this: "183 kW; 250 PS; 246 bhp". -- DeFacto (talk). 06:57, 29 October 2021 (UTC)

Sorry, can't do that. If the reference gives 250 PS as the unit but the order shown above is wanted, you can do this:

{{convert|250|PS|kW PS bhp|order=out|abbr=on}} → 180 kW (250 PS; 250 bhp)
{{convert|250.|PS|kW PS bhp|order=out|abbr=on}} → 184 kW (250 PS; 247 bhp)

The second example uses the trick that 250. (with a dot) tells convert that the zero is a significant digit. The same effect could be achieved with |sigfig=3. Johnuniq (talk) 08:38, 29 October 2021 (UTC)

Ah ok, thanks for the info. I'm trying to reconcile the reference used (and many others) which gives 246 bhp, with the engine designation as a nominal 250 PS and the preference to put metric first. -- DeFacto (talk). 08:51, 29 October 2021 (UTC)

Looking at it again, it seems the manufacturer gives the power in PS, and the kW and bhp values are calculated as rounded-down values from that (rounding up would exaggerate the value!). Can this be forced to round down: {{convert|250.|PS|kW PS bhp|order=out|abbr=on}} -> 184 kW (250 PS; 247 bhp) to give "183 kW (250 PS; 246 bhp)"? The values by hand are 183.8747 and 246.58002. -- DeFacto (talk). 09:34, 29 October 2021 (UTC)

No, I'm afraid that can't be done. In case it is of interest, it is possible to round the input value using the following strange syntax. However, the smallest PS that is going to round to 250 is 249.5 and that gives a kW value that is too large.

{{convert|249.5|PS|kW PS bhp|0|order=out|abbr=on|adj=ri0}} → 184 kW (250 PS; 246 bhp)

Johnuniq (talk) 09:59, 29 October 2021 (UTC)

Fair enough. Thanks for your time. -- DeFacto (talk). 10:06, 29 October 2021 (UTC)

Beware that the 250 PS may be only nominal - ie a marketing value that was rounded off to look better in advertising. We could use something like {{convert|246|hp|kW hp PS|order=out|round=5|abbr=on}} → 185 kW (246 hp; 250 PS). But sometimes it is better to use the actual PS value instead of the rounded marketing value: {{convert|246|hp|kW hp PS|order=out|0|abbr=on}} → 183 kW (246 hp; 249 PS). A similar thing happens with the Ford 302 cubic inch engine: we list it as 4.9 litres even though it was advertised as a 5.0 engine. Stepho talk 10:30, 29 October 2021 (UTC)

You know, it is possible to just give the text manually instead of trying to torture {convert} into giving the output you already know you want. E Eng 20:49, 29 October 2021 (UTC)

I've seen so many manual conversions done wrong that when I find them I check each one by hand. This is laborious. Whereas the convert template is trustworthy, with most mistakes being rather obvious and easy to fix (usually rounding or order). Stepho talk 23:28, 29 October 2021 (UTC)

I do tend to agree with this, especially when it comes to weird units like the rack unit (as mentioned previously here), but personally I've seen so many people who have absorbed bad practices (like people who think a source saying "5000 feet" somehow means precisely "1524 metres") as well as just plain wrong conversions, that I am somewhat wary of over-reliance on automated conversion, at least without the assurance that a competent human is at the helm. It's actually a little disturbing to me to see that someone might have so profoundly internalized the clunkiness and context-obliviousness of automated conversions that they will type stuff like "2 miles (3.2 km)" manually, without pausing to consider commonsense criteria like how such a value might naturally be given in a source using metric units. In this case, someone giving a distance as "about two miles" is virtually never intending it to be understood as having a precision of half a furlong.

I think we should probably clarify somewhere that templates such as {{convert}}, while near-indecently helpful, are not mandatory, that they cannot reasonably be expected to anticipate every use case, and that ultimately it is the text the reader is confronted with that we are concerned with, not the markup or other things that happen behind the scenes. Archon 2488 (talk) 00:18, 30 October 2021 (UTC)

Note that (even though I forget where it says it) we are not required to round the same way a source does. Sometimes it seems nice, but isn't required. Gah4 (talk) 09:19, 10 December 2021 (UTC)

Link only one of the output units

In an article I saw the template used like this:

276 bhp (206 kW; 280 PS)

I know what a kilowatt is, but I hadn't heard of PS before. I want to add a link to PS for people like me who haven't heard of it, but I don't want to link kW and it seems like this template has no way to do that. I would like a way specify that I want a link for a unit individually, something like \{\{convert|276|bhp|kW \[\[PS]]|0|abbr=on}}. Akeosnhaoe (talk) 23:59, 13 December 2021 (UTC)

You can specify linking only the output units in these ways:

276 bhp (280 PS)

276 bhp (206 kW)

276 bhp (206 kW; 280 PS)

276 bhp, 206 kW, 280 PS

276 bhp (206 kW, 280 PS) MB 00:50, 14 December 2021 (UTC)

Abbr behaviour changed by disp=or

Just a comment (not a complaint) on some unexpected functionality I've observed: setting the flag disp=or also seems to change the abbr flag to off, implicity:

{{convert|100|acre}} → 100 acres (40 ha)

but

{{convert|100|acre|disp=or}} → 100 acres or 40 hectares

I'm curious, is this behaviour intentional? Archon 2488 (talk) 09:59, 23 December 2021 (UTC)

To make the demo complete, this is with |abbr=on:

{{convert|100|acre|abbr=on|disp=or}} → 100 acres or 40 ha

Doesn't this answer the question? -DePiep (talk) 10:19, 23 December 2021 (UTC)

It is intentional although I haven't been able to find where it was discussed/announced. The same thing happens with disp=br due to "wantname = true" at Module:Convert/text#L-107. That option changes the default for abbr so, as DePiep shows above, abbr=on still works. Johnuniq (talk) 23:59, 23 December 2021 (UTC)

Ok, yes, this answers my question, thanks! Archon 2488 (talk) 23:02, 25 December 2021 (UTC)

Angle conversion

I just tried to convert 0.368° to arcminutes, but found {{convert}} is lacking in that department. It's unfortunate that the template does not support angular units, such as degrees, radians, turns, arcminutes, and arcseconds. That could be useful, for example, on astronomy articles. Praemonitus (talk) 16:54, 29 December 2021 (UTC)

Is turns actually a thing? I see we've got an article on it, but are there actually fields of study which use it? -- RoySmith (talk) 17:12, 29 December 2021 (UTC)

I'm not aware of its use in a science field. The article itself suggests it was used for artillery tables. Hmm. Praemonitus (talk) 20:45, 29 December 2021 (UTC)

Angles have been discussed in the past but generally without precise examples of what articles need conversions, and how convert would help. Everyone understands, for example, what a weight is, and English speakers at least know that some like pounds and other kilograms. Convert is useful for cases like that. By contrast, very few general readers would be helped by knowing what 73.2° is in radians or turns. Previous discussions:

Johnuniq (talk) 01:13, 30 December 2021 (UTC)

In my case I was using a VizieR data source that provided an angular radius in degrees (R₅₀), and I wanted to display it in arc minutes. (I.e. for NGC 5822: "{{convert|0.368|degrees|arcminutes|disp=out}}" -> 22′.1.) The template didn't recognize the units, so I ended up computing it manually. I prefer to use the template so I can stick with the referenced value for convenient lookup or update. Praemonitus (talk) 03:01, 1 January 2022 (UTC)

yr = "a" or "years" VS "aj" or "julian years"?

Hi there, I can see why you decided to no write aj or julian years, despite thats what it converts into. So I am suggesting to at least link the "a" not "annum" but rather to "julian year" or what ever year calculation is used for the converting? (And then maybe use aj too?) Nsae Comp (talk) 22:39, 7 January 2022 (UTC)

Julian year is a disambiguation page. Linking to a disambiguation page is usually a bad idea. Since it wouldn't be obvious which of the two links with in the disambiguation page, Julian year (astronomy) or Julian year (calendar), was intended, it would definitely a bad idea in this case.

It would be a terrible idea to change the titles of our articles to accommodate the convert template, and I would vigorously oppose any such effort. Jc3s5h (talk) 23:02, 7 January 2022 (UTC)

I think you got me wrong. Sorry foe linking to the disambiguation page, I of course ment the Julian year (astronomy) page, because thats what the converter converts time into if you choose years. Simply put it is not clear into which rype of year the converter converts time into, linking to the correct type of year instead of the general page "annum" wich in fact redirects to "year". One could of cours just redirect annum to the Julian year (astronomy) article. Nsae Comp (talk) 07:10, 8 January 2022 (UTC)

I do not know where "julian" comes from—there is no such thing in convert. The main usage of time units in convert is for things like feet/year and "annum" is used in that context. Annum is a redirect to year. The following links to annum where it might just be year:

{{convert|1|year|d|0|lk=on}} → 1 year (365 d)

If there is a problem in convert, it is best to give an example. Johnuniq (talk) 08:09, 8 January 2022 (UTC)

Astronomy uses JD (Julian Day), MJD (Modified Julian Day), HJD (Heliocentric Julian Day), and TJD (Truncated Julian Date). It's not so much a unit as a digital date. Praemonitus (talk) 17:07, 8 January 2022 (UTC)

To give an example that caused me also to rais the issue: the infobox of Earth has the value "Orbital period" given in days and is converted using the convert template into years aswell. Here the converter clearly uses 365,25 days to convert into years, which is then linked to annum/year. So here again my issue: it is not clear by clicking the unit which type of year is applied and you have to recalculate the conversion to find out which type of year was applied, which defests the purpose of the template. Nsae Comp (talk) 20:01, 8 January 2022 (UTC)
If defests isn't a word that's a shame, because it really ought to be one. E Eng 20:05, 8 January 2022 (UTC)

The infobox at Earth uses the following:

{{convert|365.256363004|d|yr|comma=gaps|abbr=on|lk=out|disp=x|<ref name="IERS" /> (|)}}

Convert does the calculation using the definitions 1 day = 86,400 seconds and 1 year = 31,557,600 seconds = 365.25 days exactly. However, what should happen is way over my paygrade given 13 significant digits for the number of days. A discussion at Talk:Earth or WT:WikiProject Astronomy regarding what should happen would be best. Johnuniq (talk) 23:00, 8 January 2022 (UTC)

Apparently Earth has the orbital period set equal to the sidereal year, but the term "orbital period", if you believe our article, normally means tropical orbital period when dealing with a planet. Of course the infobox planet documentation does not explain this in a way most readers would understand. Jc3s5h (talk) 23:49, 8 January 2022 (UTC)

Long ton conversion error?

A long ton (imperial ton) is defined as 2240 lb and a "long hundredweight" (imperial hundredweight, lcwt) is 112 lb or 8 stone. One stone is 14 lb.

But as of today, {{convert}} appears to have an alternative definition. All these are wrong:

{{convert|1|long ton|lb kg}} => 1 long ton (2,200 lb; 1,000 kg) Should be 2240 lb.
{{convert|1|lcwt|lb kg}} => 1 long hundredweight (110 lb; 51 kg) Should be 112 lb.
{{convert|40|lcwt|lb kg}} => 40 long hundredweight (4,500 lb; 2,000 kg) Should be 2240 lb.
{{convert|8|stone|lb lcwt}} => 8 stone (110 lb; 1.0 long hundredweight) Should be 112 lb.

But these are correct

{{convert|1|stone|lb kg}} => 1 stone (14 lb; 6.4 kg) (so 8 stone => 112 lb, so correct)
{{convert|112|lb|lcwt kg}} => 112 pounds (1.00 long hundredweight; 50.80 kg) Should be 1 lcwt exactly, 50.80 kg, so correct.

Aye, there's trouble at t'mill, lad! --John Maynard Friedman (talk) 17:14, 17 January 2022 (UTC)

It's the rounding. I'll add |4}} i.e., sigfig=4.

{{convert|1|long ton|lb kg|4}} => 1 long ton (2,240.0000 lb; 1,016.0469 kg) Should be 2240 lb.

{{convert|1|lcwt|lb kg|4}} => 1 long hundredweight (112.0000 lb; 50.8023 kg) Should be 112 lb.

{{convert|40|lcwt|lb kg|4}} => 40 long hundredweight (4,480.0000 lb; 2,032.0938 kg) Should be 2240 lb. [??]

{{convert|8|stone|lb lcwt|4}} => 8 stone (112.0000 lb; 1.0000 long hundredweight) Should be 112 lb.

~~But these are correct~~ here you are going fishy in the pond, m'lad. You yourself added sigfig to the RH calc only.

{{convert|1|stone|lb kg|4}} => 1 stone (14.0000 lb; 6.3503 kg) (so 8 stone => 112 lb, so correct)

{{convert|112|lb|lcwt kg|2}} => 112 pounds (1.00 long hundredweight; 50.80 kg) Should be 1 lcwt exactly, 50.80 kg, so correct.

-DePiep (talk) 17:47, 17 January 2022 (UTC)

You can remove the rounding this way without adding precision: 1 long ton (2,240 lb; 1,016 kg). MB 17:51, 17 January 2022 (UTC)

Oh rats! I even thought of the possibility of rounding but didn't have enough precision in my test.

Fifty lashes, Mr Christian. --John Maynard Friedman (talk) 22:54, 17 January 2022 (UTC)

And an extra forty for false memory. Even {{convert|1|long ton|lb kg|1}} would have shown my error, so I couldn't have tested it. Sigh. --John Maynard Friedman (talk) 23:03, 17 January 2022 (UTC)

Pressure: Inch of water ?

Could someone please add a conversion for in. WC similar to inHg? Apparently HVAC compressors in the US are labeled with this unit of pressure. Thanks in advance! Facts707 (talk) 15:52, 15 January 2022 (UTC)

This was discussed at Template talk:Convert/Archive October 2009#Please add this pressure unit which seemed to conclude that the unit was a bit ill-defined for convert. At any rate, it is conventional that a couple of examples of where such a unit would be used are investigated before a new unit is added. Is there an agreed symbol and name? Johnuniq (talk) 23:18, 15 January 2022 (UTC)

Since it seems to be mostly a North American thing, I found the conversion factors at NIST – search in page for "inch of water"; they also have "centimeter of water" and "foot of water". The only "symbol" I could find is "inH₂O". It comes with a footnote "12" saying more significant digits aren't justified due to fluid compression, etc. Facts707 (talk) 04:40, 17 January 2022 (UTC)

I'm not sure it's any more or less well-defined than the millimetre of mercury? Implicitly I guess there is a temperature in there (i.e. it refers to the maximum height of a column of water at, say, 20 °C; I seem to recall that mmHg is conventionally defined at 0 °C but do not wish to be quoted on this). But this shouldn't really matter as AFAIK all pressure units are presently defined as multiples of the pascal. And while I personally find the multiplicity of pressure units quite irritating and pointless, it's handy to be able to convert them readily into something more meaningful without having to look up abstruse conversion factors oneself (and then running the risk of compounding the irritation by getting it wrong). Archon 2488 (talk) 10:47, 17 January 2022 (UTC)

From NIST:

inch of water (39.2 °F) pascal (Pa) 2.49082 E+02
inch of water (60 °F) pascal (Pa) 2.4884 E+02
inch of water, conventional (inH2O) pascal (Pa) 2.490889 E+02

They also have inches and centimeters Hg at 32°F, 60°F, and "conventional". Facts707 (talk) 04:14, 19 January 2022 (UTC)

Typography in ranges

Consider this conversion, from Sisal:

{{convert|1.5|-|2|m|ftin|abbr=on}} → 1.5–2 m (4 ft 11 in – 6 ft 7 in)

Per MOS:UNITNAMES I think this should generate a spaced en dash, but what we get is an unspaced en dash. GA-RT-22 (talk) 03:14, 16 January 2022 (UTC)

The first unspaced en dash agrees with MOS:UNITNAMES. The second is unclear because the MOS example is "3 μm – 1 mm" with two different units. I don't see a MOS example of how ft in should be treated. It's a rather esoteric case that could be resolved with:

{{convert|1.5|to|2|m|ftin|abbr=on}} → 1.5 to 2 m (4 ft 11 in to 6 ft 7 in)

Johnuniq (talk) 04:20, 16 January 2022 (UTC)

MOS:DASH covers this also. It says a range is unspaced, except when either or both elements contain a space... By that, both en dashes should be spaced. That does seem to contradict MOS:UNITNAMES. MB 04:36, 16 January 2022 (UTC)

Sorry, can you be clear what in DASH you think contradicts UNITNAMES? I'd like to resolve any issue on this if possible. E Eng 05:09, 16 January 2022 (UTC)

UNITNAMES says spacing is based on number of unit symbols and gives this example: (e.g. 5.9–6.3 kg). That same example would be a spaced en dash according to MOS:DASH because of the space before kg. MB 06:58, 16 January 2022 (UTC)

No, because the second element isn't "6.3 kg", it's "6.3". The range is 5.9–6.3, and the range is followed by a unit. See also this example at MOS:DASH: "6:00–9:30 p.m." GA-RT-22 (talk) 21:03, 16 January 2022 (UTC)

"Element" isn't defined, but I inferred that the element was everything on one side of the dash (month/day/year, number/unit), etc. This is not clear to others; the same point is being discussed at the MOS TP also. MB 03:30, 17 January 2022 (UTC)

Fixed [12] E Eng 07:42, 17 January 2022 (UTC)

I'm not crazy about "4 ft 11 in to 6 ft 7 in". It's too busy and hard to see what the two ends of the range are. "11 in to 6" sounds like an arithmetic problem. GA-RT-22 (talk) 05:58, 16 January 2022 (UTC)

The problem there is that in is easily taken as a preposition at first glance, particularly given that it's followed by to. MOS:UNITNAMES suggests Consider using inches (but not in.) in place of in where the latter might be misread as a preposition‍ and I'm almost ready to suggest to Johnuniq that a special case be made of in to, changing it to inches to (on both sides of range). Now there would be some kludgy code for you, I'm guessing. E Eng 07:47, 17 January 2022 (UTC)

4 ft 11 in – 6 ft 7 in definitely takes a spaced endash. That MOS gives no example using ft in isn't a problem -- the important point is that ft in has a space, so the endash has a space before it and a space after it. EEng 05:09, 16 January 2022 (UTC)
- OK, I'll look at it. The fix for ft/in is simple (output spaced en dash if LHS or RHS contains a space) but I'd want to investigate the effect on existing converts. Johnuniq (talk) 06:19, 16 January 2022 (UTC)

Hmm, I wonder what "Rackets with smaller and larger head sizes, 85 and 120–137 square inches (550 and 770–880 cm²), are still produced" at Racket (sports equipment)#Tennis means. Should it have a spaced en dash? Johnuniq (talk) 08:51, 16 January 2022 (UTC)

It should not, because the beginning of the range is a single number with no spaces. Parse it like this: (550) and (770–880 cm²). Personally I find that whole paragraph confusing, and it's an impressive wall of text. I would re-word the sentence to something like "Rackets with smaller heads of 85 square inches (550 cm²) and larger heads of 120–137 square inches (770–880 cm²)" GA-RT-22 (talk) 20:57, 16 January 2022 (UTC)

Spaced en dash complications

I'm looking at some changes so units like ftin use a spaced en dash in ranges. With a combination unit like ftin (feet and inches) or stlb (stones and pounds), convert shows the unit on each side of the dash. However, sometimes the major unit (feet or stones) is not needed as in these examples:

{{cvt|0.1|-|0.2|m|ftin}} → 0.1–0.2 m (3.9 in – 7.9 in)
{{cvt|3|-|5|kg|stlb}} → 3–5 kg (6.6 lb – 11.0 lb)

I'm not going to try to make convert handle that special case. It occurs in perhaps half a dozen articles. The fix is to use the more appropriate output unit:

{{cvt|0.1|-|0.2|m|in}} → 0.1–0.2 m (3.9–7.9 in)
{{cvt|3|-|5|kg|lb}} → 3–5 kg (6.6–11.0 lb)

Johnuniq (talk) 06:40, 17 January 2022 (UTC)

Spaced en dash test

I updated the sandbox to give a spaced en dash.

Current template (not spaced):

{{convert|2|-|3|Mach|20000}} → Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph)
{{convert|1.5|-|2|m|abbr=on}} → 1.5–2 m (4 ft 11 in – 6 ft 7 in)
{{convert|1346|-|1676|mm|ydftin|0}} → 1,346–1,676 millimetres (1 yd 1 ft 5 in – 1 yd 2 ft 6 in)
{{convert|81|-|89|kg|stlb}} → 81–89 kilograms (12 st 11 lb – 14 st 0 lb)

Sandbox (spaced):

{{convert/sandbox|2|-|3|Mach|20000}} → Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph)
{{convert/sandbox|1.5|-|2|m|abbr=on}} → 1.5–2 m (4 ft 11 in – 6 ft 7 in)
{{convert/sandbox|1346|-|1676|mm|ydftin|0}} → 1,346–1,676 millimetres (1 yd 1 ft 5 in – 1 yd 2 ft 6 in)
{{convert/sandbox|81|-|89|kg|stlb}} → 81–89 kilograms (12 st 11 lb – 14 st 0 lb)

Johnuniq (talk) 01:32, 18 January 2022 (UTC)

The spaced version looks much better to my eye. And thanks much for the great work! Facts707 (talk) 04:28, 19 January 2022 (UTC)

Commonwealth/US spelling

"Default spelling of units is in the en (generic) locale. To show en-US spelling, use |sp=us"... true, except when the conversion is to a US-specific measure. On 2022 Hunga Tonga eruption and tsunami I'm trying to get the template to convert litres to US gallons, and there doesn't seem to be a way of stopping it from spelling the former as "liters". Is there any way to add a sp=uk or similar please, because at the moment that just generates an error. Grutness...wha? 22:35, 20 January 2022 (UTC)

One possibility is to side-step the issue and use the "L" abbreviation.

I would also provide both US gallons and imperial gallons, even though it doesn't change the spelling issue. Stepho talk 22:54, 20 January 2022 (UTC)

@Grutness: That's this example of the template being clever:

{{convert|250000|L|U.S.gal|abbr=off}} → 250,000 liters (66,000 U.S. gallons)

The recommended unit is USgal. Using U.S.gal implies US spelling and sets sp=us. Try this:

{{convert|250000|L|USgal|abbr=off}} → 250,000 litres (66,000 US gallons)

Johnuniq (talk) 23:01, 20 January 2022 (UTC)

Nice - I didn't know that trick! Thanks. Grutness...wha? 23:18, 20 January 2022 (UTC)

Unit isp

Moved from Template talk:Cvt. Johnuniq (talk) 02:05, 21 January 2022 (UTC)

Apollo Lunar Module uses {{cvt|290|isp}}, which displays as "290 s (2.8 km/s)". I couldn't find anything on "isp", but the value is for the LEM's Specific impulse, so I guess that stands for "impulse, specific". It should be measured in m/s, so why is Cvt using a time here? --84.189.84.17 (talk) 00:58, 21 January 2022 (UTC)

The unit isp is Specific impulse and was discussed at Template talk:Convert/Archive January 2014#Inverted units and is documented at Module:Convert/documentation/conversion data#Speed. I am assured that the unit is correct but convincing others about that is over my pay grade. Johnuniq (talk) 02:05, 21 January 2022 (UTC)

Mach speed enhancements

I have updated the sandbox with some improvements regarding handling of the Mach unit. Using the old system, an altitude could be entered as a number (in feet) after the Mach unit, but that only worked for Mach as an input. It was not possible to specify an altitude for Mach as an ouput.

In the new system:

Parameters altitude_ft and altitude_m have been added.
These can be used to specify the Mach number altitude in feet or meters.
The altitude works with either Mach as an input unit or as an output unit.
The built-in table of altitudes from aerospaceweb.org has been extended, now covering −17,499 to 402,499 feet (negative altitudes can occur in a valley below sea level).
The default precision when a Mach number is used as an input is improved (previously it used far too many significant digits).

The following table compares the old and new systems using fixed wikitext so the results will not change.

Convert	Old output	New output
{{cvt\|0.9\|Mach}}	Mach 0.9 (1,102.5 km/h; 685.1 mph)	Mach 0.9 (1,100 km/h; 690 mph)
{{cvt\|1.6\|Mach\|20000}}	Mach 1.6 (1,820.5 km/h; 1,131.2 mph)	Mach 1.6 (1,820 km/h; 1,130 mph)
{{cvt\|1.6\|Mach\|altitude_ft=20,000\|mph}}	(not supported)	Mach 1.6 (1,130 mph)
{{cvt\|1.6\|Mach\|altitude_m=6,096\|mph}}	(not supported)	Mach 1.6 (1,130 mph)
{{cvt\|3\|Mach}}	Mach 3 (3,675 km/h; 2,284 mph)	Mach 3 (3,700 km/h; 2,300 mph)
{{cvt\|5\|-\|7\|Mach}}	Mach 5–Mach 7 (6,125–8,575 km/h; 3,806–5,328 mph)	Mach 5 – Mach 7 (6,100–8,600 km/h; 3,800–5,300 mph)
{{cvt\|9.8\|Mach\|98000}}	Mach 9.8 (10,655.3 km/h; 6,620.9 mph)	Mach 9.8 (10,700 km/h; 6,620 mph)

Johnuniq (talk) 08:43, 24 January 2022 (UTC)

A wonderful new feature! I have extended the illustrations table below. BTW Johnuniq, have you considered outputting the altitude? -DePiep (talk) 09:53, 24 January 2022 (UTC)

I don't think there is any good way convert could output altitude text because what would work in a particular place is unlikely to work in other places where the same template might be used. I should mention that it is my hope that the current acceptance of an altitude number after an input Mach unit can be deprecated and removed in the future, and that use of Mach without an altitude parameter would result in an error. Johnuniq (talk) 22:54, 24 January 2022 (UTC)

Extended examples

Added:

column inverse, for Mach → km/h mph (Mach to regular speed)

row H, for input |Mach|km/h mph| (multiple value output).

row-id, A-H

Note that old |20000 altitude input must be changed into |altitude_ft=20000, in-article.

row	Convert	Old output	New output	Inverse `{{convert/sbox\|123 \|Mach \|km/h \|altitude_ft=..}}`
A	{{cvt\|0.9\|Mach}}	Mach 0.9 (1,102.5 km/h; 685.1 mph)	Mach 0.9 (1,100 km/h; 690 mph)	1,100 kilometres per hour (Mach 0.90) 690 miles per hour (Mach 0.91)
B	{{cvt\|1.6\|Mach\|20000}}	Mach 1.6 (1,820.5 km/h; 1,131.2 mph)	Mach 1.6 (1,820 km/h; 1,130 mph)	^{[convert: precision too large]} `\|20000}}` N 1,820 kilometres per hour (Mach 1.6) → • `\|altitude_ft=20000}}` Y
C	{{cvt\|1.6\|Mach\|altitude_ft=20,000\|mph}}	(not supported)	Mach 1.6 (1,130 mph)	1,100 kilometres per hour (Mach 0.97) 1,130 miles per hour (Mach 1.6)
D	{{cvt\|1.6\|Mach\|altitude_m=6,096\|mph}}	(not supported)	Mach 1.6 (1,130 mph)	1,820 kilometres per hour (Mach 1.6) 1,130 miles per hour (Mach 1.6)
E	{{cvt\|3\|Mach}}	Mach 3 (3,675 km/h; 2,284 mph)	Mach 3 (3,700 km/h; 2,300 mph)	3,700 kilometres per hour (Mach 3.0) 2,300 miles per hour (Mach 3.0)
F	{{cvt\|5\|-\|7\|Mach}}	Mach 5–Mach 7 (6,125–8,575 km/h; 3,806–5,328 mph)	Mach 5 – Mach 7 (6,100–8,600 km/h; 3,800–5,300 mph)	6,100–8,600 kilometres per hour (Mach 5.0 – Mach 7.0) 3,800–5,300 miles per hour (Mach 5.0 – Mach 7.0)
G	{{cvt\|9.8\|Mach\|98000}}	Mach 9.8 (10,655.3 km/h; 6,620.9 mph)	Mach 9.8 (10,700 km/h; 6,620 mph)	• `\|altitude_ft=20000}}` Y 10,700 kilometres per hour (Mach 9.8) 6,620 miles per hour (Mach 9.8) • `\|altitude_ft=20000}}` Y 10,700 kilometres per hour (Mach 8.7) 6,620 miles per hour (Mach 8.7)
H	{{cvt\|9.8\|Mach\|km/h mph\|altitude_ft=20000}}	`{{cvt\|9.8\|Mach\|<!--no units=defaults to \|km/h mph\|-->20000}}` Mach 9.8 (11,200 km/h; 6,930 mph)	..	• `\|altitude_ft=20000}}` Mach 9.8 (10,700 km/h; 6,620 mph) • `\|altitude_m=667}}` Mach 9.8 (12,000 km/h; 7,460 mph)

Extended example table. Johnuniq & others: free to edit/improve this table as deemed helpful. This includes deletion when incorrect/unhelpful. -DePiep (talk) 09:51, 24 January 2022 (UTC)

Torque nomenclature

The nomenclature in "producing... 260 pound force-feet (350 N⋅m) of torque" is non-standard, and apparently is produced by a conversion template as invoked by: 260 pound force-feet (350 N⋅m)

Ref: http://en.wiki.x.io/wiki/Dodge_Charger

Standard usage would simply read "260 lb•ft (350 N•m)". There is no common specification for torque stated as "pound force-feet."

I contend the template should be modified to render the standard verbiage. 107.2.38.145 (talk) 15:52, 30 January 2022 (UTC)

Convert provides various torque units with slight differences in output, see the full list of units. The main contenders are lb.ft and lbft:

{{convert|260|lb.ft}} → 260 pound force-feet (350 N⋅m)
{{convert|260|lbft}} → 260 pound-feet (350 N⋅m)
{{convert|260|lb.ft|abbr=on}} → 260 lb⋅ft (350 N⋅m)
{{convert|260|lbft|abbr=on}} → 260 lb⋅ft (350 N⋅m)

As seen above, using abbr=on gives the correct symbol. There was a previous and inconclusive discussion regarding the "force" terminology in December 2011. Johnuniq (talk) 02:07, 31 January 2022 (UTC)

Ranges when both output values are the same due to rounding

This code (found here):

{{convert|2|-|3|cm|0|abbr=on}}

results in this output:

2–3 cm (1–1 in)

Maybe the repetition is intentional but it looks a bit clumsy. Could we produce a neater output like this:

2–3 cm (1 in)

or would this be confusing? --Heron (talk) 14:42, 2 February 2022 (UTC)

If there was a range in the input, I would expect a range in the output, I think rounding this is inappropriate: 2–3 cm (0.8–1.2 in) or 2–3 cm (3⁄4–11⁄4 in) MB 15:14, 2 February 2022 (UTC)

Yeah, I'm afraid this is a known problem of convert whereby some ranges default to a bad result. The solution is to manually add a precision or fraction, as MB shows. Johnuniq (talk) 00:38, 3 February 2022 (UTC)

I have found more often that {{convert}} is used with too much precision, and rarely not enough. In the case of 2-3cm, the suggestion is that it is uncertain to about +/- 0.5cm. So it is roughly "about 1 inch". Saying roughly 2.5cm is implying more precision than might be intended. (Or specified with other arguments.) Say there is a recipe for cookies that says to roll the dough into about 1in balls. Saying roll in to 2.54cm balls or even 2.5cm balls suggests more precision that is needed for cookie making, but 2-3cm balls is about right. This suggests that in this case, the converted value should just be 1in, without a range, even though the source has a range. I don't know if that is too hard to do. Gah4 (talk) 23:08, 3 February 2022 (UTC)

Sometimes we just have to rely on the user to user intelligent rounding values. Eg {{convert|2|-|3|cm|mile|0|abbr=on}} → 2–3 cm (0–0 miles) isn't useful. Stepho talk 11:11, 4 February 2022 (UTC)

Module version 27

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

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

Ranges that would use an en dash (–) now use a spaced en dash ( – ) with unit Mach and with composite units such as ftin (feet and inches) or stlb (stones and pounds).
Examples using fixed wikitext to show what will occur with this release:
- {{convert|2|-|3|Mach|altitude_ft=20000}} → Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph)
- {{convert|0.1|-|0.2|m}} → 0.1–0.2 metres (3.9 in – 7.9 in)
- {{convert|81|-|89|kg|stlb}} → 81–89 kilograms (12 st 11 lb – 14 st 0 lb)
Handling of the Mach unit has been enhanced (discussion here):
- Parameters altitude_ft and altitude_m can be used to specify the altitude in feet or meters.
- The altitude works with Mach as an input unit or as an output unit.
- The built-in table of altitudes from aerospaceweb.org has been extended, now covering −17,499 to 402,499 feet (negative altitudes can occur in a valley below sea level).
- The default precision when a Mach number is used as an input is improved (previously it used far too many significant digits).
Unit changes:
- Links for units DWton and DWtonne have been corrected to Deadweight tonnage.
- Links for various energy units have been changed to Kilowatt-hour due to Watt-hour being moved.

Release notes for earlier versions are listed here. Johnuniq (talk) 22:52, 4 February 2022 (UTC)

About Mach: this also allows sigfig (|3=) to be used as alternative (synonym) next to |altitude_ft, _m= then? Wouldn't it be preferable to not introduce non-semantic parameter usage, i.e., requiring dedicated parameters |altitude_ft, _m=? I don't think ease of editing is helped. -DePiep (talk) 09:01, 11 February 2022 (UTC)

There are roughly 350 convert/cvt in articles using Mach. About half specify an altitude. Where Mach is used as an output, none specify an altitude because that won't be possible until this version is released. It will not be easy to find an altitude value that should be inserted in the converts that don't have one because sources often are vague on that point. Accordingly, it's not feasible at this stage to change convert to make the lack of an altitude an error. That might happen later, after gnoming fixes the existing converts. Re sigfig, all the normal options still apply so sigfig will work. Johnuniq (talk) 09:43, 11 February 2022 (UTC)

I see. What shall we write in documentation? "... deprecated; preferably use ..."? i.e., phasing out & clarity in editors new input. -DePiep (talk) 11:17, 11 February 2022 (UTC)

The good news is that, as far as I can see, Mach is not documented so we don't have to do anything! However, while doing some last-minute testing a short while ago I decided I had to add a better message to handle invalid altitude values and I added the following at Help:Convert messages for when it goes live: Conversion of the Mach unit of speed depends on the altitude at which the speed is measured. That altitude should be specified either in feet (for example, |altitude_ft=10,000) or in metres (for example, |altitude_m=3,749). The altitude cannot be determined accurately and only a whole number is accepted.

Along with what I wrote above, I don't think any more is needed, although any documentation should not mention details such as aerospaceweb.org. Johnuniq (talk) 08:38, 12 February 2022 (UTC)

This version is now live. Johnuniq (talk) 04:13, 13 February 2022 (UTC)
I added some brief documentation at Help:Convert units#Mach (unit of speed). Johnuniq (talk) 22:49, 14 February 2022 (UTC)

WikiProject Measurement on a redirect

Would someone who understands procedures regarding redirects please have a look at diff which added {{WikiProject Measurement}} at Module talk:Convert/documentation/conversion data, which is a redirect to this page. Ping Awkwafaba. Johnuniq (talk) 23:53, 14 February 2022 (UTC)

It's common to add redirects to projects and/or cats. But generally we don't add talk pages to the project and/or cat. And why would we want to add it to a defunct project? Stepho talk 12:09, 15 February 2022 (UTC)

Bug/oversight in to(-) option

I've noticed that (for example) {{convert|2|to(-)|3|m|ft|0}} works as expected: 2 to 3 metres (7–10 ft). However, the near-identical {{convert|2|to(–)|3|m|ft|0}} does not: 2 to(–)^{[convert: unknown unit]} (point being that in the latter case, we have an en dash rather than a hyphen). Archon 2488 (talk) 10:13, 17 February 2022 (UTC)

That's a feature! Wikignomes should learn that it is not a good idea to change parameters inside a template without an understanding of what is required. Because convert is often added to existing wikitext which might already include an en dash, convert accepts - (hyphen) and – (en dash) for a simple range. However, no one should think that the hyphen in to(-) should be changed to an en dash. Two others examples where only a hyphen is accepted are and(-) and +/-. Johnuniq (talk) 06:03, 18 February 2022 (UTC)

Rounding bug in Prince of Wales–Hyder Census Area, Alaska

I corrected a population density figure in the text of Prince of Wales–Hyder Census Area, Alaska#Demographics, and 1.57 per square mile (0.61/km2) should become 1.57 per square mile (0.61/km²) but instead is treated as 1 per square mile (0/km²). –LaundryPizza03 (d c̄) 19:49, 19 February 2022 (UTC)

Population density wasn't using convert. It was just some manual text. See if this edit give you what you want. -- WOSlinker (talk) 20:29, 19 February 2022 (UTC)

Can plural be singural when amount < 1; e.g. "0.5 inch" instead of "0.5 inches"

E.g.:

{{convert|1.2|cm|1|abbr=in}} → 1.2 cm (0.5 inches)
{{cvt|0.3|km|1|abbr=in}} → 0.3 km (0.2 mi)

Thanks for considering, Facts707 (talk) 00:19, 13 February 2022 (UTC)

The second example is not working because cvt forces abbr=on. If the request concerned a single unit such as "inch", there might be a way to achieve what is wanted, if others agree that it would be desirable. But if it's a general request for all units, I think that is very unlikely to succeed because, for example, "0.5 miles" is natural English. It might be nice to say "half a mile" but convert only supports a one-size-fits-all approach to spelling fractions, and that gives "one-half mile". Regarding the inch unit, there are roughly 500 converts in articles that use "inch" and abbr=on, so the output currently is "in". There are another roughly 500 where inch is used as the output unit and is abbreviated, again resulting in "in". The problem is that changing "inch" to never be abbreviated would therefore change how a lot of articles appear, and that would need a lot of investigation. Johnuniq (talk) 02:34, 13 February 2022 (UTC)

I'd just add that per MOSNUM we do not consider numbers 0 ≤ x < 1 to be grammatically singular when written in decimal notation. Use of the singular is reserved for simple vulgar fractions and the integer digit 1 (or "one") only. Archon 2488 (talk) 10:20, 17 February 2022 (UTC)

Personally, I've never understood what it is that's vulgar about (for example) 1⁄3. What seems vulgar to me is 0.3333333333333333333333333333333333333333333333333333333333333333333333. E Eng 14:47, 20 February 2022 (UTC)

Currency per unit doesn't support multiple currencies

It seems like when I try to use a different currency when using the "currency per unit" feature, it throws an error saying it doesn't recognize it. I figured using the "currency change" feature just uses a simple text replacement rather than an actual recognition of the various currency symbols. For example:

{{convert|1|$/acre|abbr=off}} → $1 per acre ($2.5 per hectare)

{{convert|1|$/acre|$=₹|abbr=off}} → ₹1 per acre (^{[convert: unknown unit]})

It would be great if all the currency symbols could be supported. Getsnoopy (talk) 18:29, 20 February 2022 (UTC)

I see there are quite a lot of currency symbols. The fix for this particular issue is to specify the output unit:

{{convert|1|$/acre|$/ha|$=₹|abbr=off}} → ₹1 per acre (₹2.5 per hectare)

Johnuniq (talk) 22:26, 20 February 2022 (UTC)

My baby's got me locked up in chains

Hey, J u: In a discussion over at Talk:MOS, the question has arisen: Which chain ? English, Scottish or US ? I'm not sure which one convert uses. Possibly convert might have to accept multiple chains. E Eng 13:48, 1 February 2022 (UTC)

I love MoS. I think it's great. Martinevans123 (talk) 14:07, 1 February 2022 (UTC)

I think that reply qualifies you as Humpty Dumpty of the week.

--John Maynard Friedman (talk) 16:34, 1 February 2022 (UTC)

I claim my prize. Martinevans123 (talk) 11:13, 2 February 2022 (UTC)

I try to avoid getting tied up in knots and would prefer to hang out here rather than debate how many chains fit on the head of a foot. I doubt if anyone is seriously asking but for the mathematically inclined:

{{convert|1|chain|feet|abbr=off|9}} → 1 chain (66.000000000 feet)
{{convert|1|foot|m|abbr=off|9}} → 1 foot (0.304800000 metres)

Johnuniq (talk) 23:07, 1 February 2022 (UTC)

Thanks for the info -- we may need it later. E Eng 00:28, 3 February 2022 (UTC) P.S. If you change your mind and do want to get tied up in knots, there's WT:Manual of Style/Dates and numbers#Propose_additions_to_unit-specific_guidance_for_knots.

As I read it, all the conversions between any multiple or fraction of the foot (including the chain and inch) to meters is based on the international foot. Which is a good choice for most fields or low precision, but questionable for high-precision mapping in the US. Jc3s5h (talk) 02:47, 2 February 2022 (UTC)

Somehow I doubt that the USGS is using chains (physical or otherwise) for high-precision mapping. In fact I'm willing to bet that they do it in SI and convert the result to USCU for public consumption, which is what happens in the UK. Take these chains from mah hort 'n' set me free... --John Maynard Friedman (talk) 11:08, 2 February 2022 (UTC)

See WT:Manual_of_Style/Dates_and_numbers/Archive_158#Distances_measured_in_chains (and be sure to scroll through). E Eng 04:40, 21 February 2022 (UTC)

English language variations

I'm editing on Royce Clayton and wrote about how he trained by running 200-metre (660 ft) sprints. He's American though, so it should read "200-meter". I put {{Use American English}} on the article, but it still shows up as "metre". Can we account for differences in English dialects? – Muboshgu (talk) 04:32, 21 February 2022 (UTC)

I added "sp=us" to the convert. MB 05:27, 21 February 2022 (UTC)

MB, thanks, did not see that that was a supported parameter. – Muboshgu (talk) 17:22, 21 February 2022 (UTC)

How to only show one number?

Does this template always show X unit1 (Y unit2)? Or can it show Y unit2? I am using the Convert template to import Wikidata numbers into existing tables. For example, in tables we typically show one unit in each column, or only one unit. Tomastvivlaren (talk) 14:20, 28 February 2022 (UTC)

See Help:Convert#Displaying parts of a conversion. MB 15:06, 28 February 2022 (UTC)

Thankyou - great! Tomastvivlaren (talk) 22:29, 28 February 2022 (UTC)

Wikidata conversion?

Can you guys explain why {{Convert}} shows different units for the area (P2046) of the cities of São Paulo (Q174) and Sundsvall (Q26476)? The São Paulo area is stored in km² at wikidata and Sundsvall in hectares, but shouldn't Convert fix that? I always want km² - is that possible?

{{convert|input=P2046|qid={{Get QID|São Paulo}}|km2|disp=out}} -> 588 sq mi
{{convert|input=P2046|qid={{Get QID|Sundsvall}}|km2|disp=out}} -> 41.44 km²
{{convert|input=P2046|qid={{Get QID|São Paulo}}|km2}} -> 1,523 square kilometres (588 sq mi)
{{convert|input=P2046|qid={{Get QID|Sundsvall}}|km2}} -> 4,144 hectares (41.44 km²)

@MB and Johnuniq: Tomastvivlaren (talk) 22:29, 28 February 2022 (UTC)

This seems to be a problem in the QID system not liking km2 for São Paulo:

{{area WD|qid=Q174}} → 377,972.28
{{area WD|qid=Q26476}} → 41.44
{{area WD|São Paulo|km2}} → 1,523
{{area WD|Sundsvall|km2}} → 41.44
{{area WD|São Paulo|acre}} → 376,000
{{area WD|Sundsvall|acre}} → 10,240 Stepho talk 22:45, 28 February 2022 (UTC)

(Yes I made {{Area WD}} by using Convert, and that's why I ask. Area WD also utilizes {{Get QID}}, which I further developed to accept Wikipedia page titles as argument, and also Wikipedia redirect pages. Because I think QID:s make article wikicode uggly and incomprehensible. The "Get QID" template is not what causes this problem.)

For example the area of Africa (Q15) gives the same problem as São Paulo, because it is stored in km2 at Wikidata:

{{convert|input=P2046|qid={{Get QID|Africa}}|km2|disp=out}} -> 11,688,000 sq mi

Perhaps the problem is in the otherwize so nice module:Convert/wikidata? Tomastvivlaren (talk) 23:38, 28 February 2022 (UTC)

I don't know why this makes a difference, but adding a space gives the result you want:

{{convert|input=P2046|qid={{Get QID|São Paulo}}|km2|disp=out}} -> 588 sq mi
{{convert|input=P2046|qid={{Get QID|São Paulo}}| km2|disp=out}} -> 1,523 km²
{{convert|input=P2046|qid={{Get QID|Africa}}|km2|disp=out}} -> 11,688,000 sq mi
{{convert|input=P2046|qid={{Get QID|Africa}}| km2|disp=out}} -> 30,271,000 km²

Will need Jonuniq to explain that. MB 23:41, 28 February 2022 (UTC)

This is a weirdness in how convert works internally when dealing with Wikidata values/units. A workaround is to insert 3= in {{Area WD}} so its unit reads |3=km2. I'd have to spend an hour studying it to remind myself of exactly what is happening but I believe that convert's code expects that it is being used to do a conversion, so there should be an input unit and an output unit. The input value and unit are read from Wikidata. They are inserted as parameters 1 and 2 to convert. The output unit is specified as a parameter to convert. The problem is that no one can predict what the input unit is and the input= feature was initially used to do conversions which looked silly if the input unit and output unit were the same. Therefore convert removes the output unit if it duplicates the input, so it ends up using the default. Try the 3= workaround. Johnuniq (talk) 23:54, 28 February 2022 (UTC)

Thnx again MB! This workaround solved the problem for now (Steph:s example code above now works), but I notice if you change abbr parameter, the result is different. Jouhnuniq, your workaround would also work.

Anyway, I hope we soon can start introducing {{Area WD}} and {{Population WD}} in existing tables that need updates. Tomastvivlaren (talk) 00:00, 1 March 2022 (UTC)

Rectangle and cuboid conversions

Was editing some articles to use Convert when I came upon something in which I could use some help. Measurements for rectangular and cuboid figures are usually given as 10 x 10 cm or 30 cm x 10 cm x 20 cm, for example. What's the more appropriate way to use convert to handle those measurements? ^Zera/_talk 13:28, 23 February 2022 (UTC)

30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in)
30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in)

There's two options which both work. -- WOSlinker (talk) 13:44, 23 February 2022 (UTC)

Wonderful! Thanks for the quick answer! ^Zera/_talk 13:48, 23 February 2022 (UTC)

More: In the 'loose' format, "x" (ecks) and "×" (times) render the same ("×"), but the 'tight' format currently does not parse "×":

{{convert|30|x|10|x|20|cm|abbr=on}} → 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in)
{{convert|30|×|10|×|20|cm|abbr=on}} → 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in)
{{convert|30x10x20|cm|abbr=on}} → 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in)
{{convert|30×10×20|cm|abbr=on}} → ^{[convert: invalid number]} –A876 (talk) 18:24, 29 March 2022 (UTC)
Yes. I've gone a bit off that tricky syntax and recommend that it be replaced with pipes except possibly in articles that need a lot of 30x10 conversions. Convert expects a number where 30×10×20 appears and when that doesn't work it tries a small number of range separators. That is, not all of them in order to avoid excessive overhead. At any rate, please use simple input parameters (30x10x20 using ecks) to encourage others to do the same so people don't come to expect that they are "supposed" to enter the more tricky times symbol. Johnuniq (talk) 22:15, 29 March 2022 (UTC)

Name + unit symbol doesn't work when order is flipped

It seems like there's a bug where if I try to show the unit name and the symbol with the order flipped, it does not show the unit symbol. For example:

{{convert|2|kPa|psi|abbr=~}} → 2 kilopascals [kPa] (0.29 psi)

{{convert|2|kPa|psi|abbr=~|order=flip}} → 0.29 pounds per square inch (2 kPa)

Could someone take a look at this or point me in the right direction? Getsnoopy (talk) 16:17, 30 March 2022 (UTC)

That is a rarely used option—in April 2021 there were around 30 instances in over 3 million converts. The option is intentionally disabled when option=flip applies. I forget the details but studying the following would probably reveal the reasoning.

Johnuniq (talk) 02:42, 31 March 2022 (UTC)

Auto-select time unit?

In Special:Diff/1080355341, I did two conversions from seconds; one to minutes, the other to hours. But, I had to make that choice manually. Is there some way to say, "Convert this many seconds into minutes or hours as appropriate?" -- RoySmith (talk) 19:39, 31 March 2022 (UTC)

@RoySmith: I put an experiment for a new unit called sec at Module:Convert/extra. If less than 120 minutes, it defaults to minutes, otherwise hours. Examples:

{{convert|5700|sec}} → 5,700 seconds (95 min)
{{convert|7200|sec}} → 7,200 seconds (2.0 h)

I'm not sure how useful that is but if wanted it could be incorporated in the main set of units when the module is next updated. Assuming that happened, sec would be removed and replaced with s which would be updated to use the new default. It's ok to use sec in articles now, if wanted. Any problems later will be noticed and fixed. Johnuniq (talk) 23:20, 31 March 2022 (UTC)

Interesting, thanks! I changed to using sec (Special:Diff/1080387020). It looks like the break-over from minutes to hours is 120 minutes, which I guess makes sense. -- RoySmith (talk) 23:59, 31 March 2022 (UTC)

Older archives

Where are the links to pre-2020 archived discussions? Judging by the text at the top of Template talk:Convert/Archive 1, Johnuniq (talk · contribs) changed the naming system for archiving in July 2020, but I can't find where the older archives are listed even though it says The index for 2007 to 2019 will be moved to this page. --Redrose64 🌹 (talk) 11:47, 5 April 2022 (UTC)

You add {{Template talk:Convert/Archives}} to the top of this page to show them. -- WOSlinker (talk) 12:42, 5 April 2022 (UTC)

Thank you --Redrose64 🌹 (talk) 15:42, 5 April 2022 (UTC)

I don't have the energy right now to work out why my 00:56, 21 July 2020 edit at Template talk:Convert/Archive 1 is not showing the old monthly index. I am fairly sure that the aim was to not show the long and not very useful list on Template talk:Convert. Instead, it was at Template talk:Convert/Archive 1. It's a while since I've done it, but I believe that clicking "Archive 1" at the top of this page went to archive 1 and used to show the 2007 to 2019 list. That is a better location. Johnuniq (talk) 23:13, 5 April 2022 (UTC)

The history at {{archives}} shows a revision at 09:58, 17 July 2020 which is shortly before I placed an archives box at Template talk:Convert/Archive 1 with the old 2007 to 2019 archives. Previewing an edit of that July 2020 template with target Template talk:Convert/Archive 1 displays the archive in its full glory. In other words, some change at {{archives}} means that the parameters which worked in July 2020 now hide the old list. Does anyone feel like working out what has happened and how to rectify it. I would prefer that the old archive list is at Archive_1 and not cluttering up the top of this page. Johnuniq (talk) 03:12, 6 April 2022 (UTC)

Broken conversion

Take a look at the "Length" in the infobox on Arleigh Burke-class destroyer. 505 ft gets correctly converted to 154 m, 509 ft correctly becomes 155 m, and then 510 ft becomes 160 m?? That's not correct. Denvercoder9 (talk) 16:42, 28 April 2022 (UTC)

You need to specify the precision of conversion, which I have now done, otherwise the template assumes that 510 has been rounded to the nearest multiple of 10 and refers to an approximate value between 505 and 515. Dr Greg talk 17:05, 28 April 2022 (UTC)

Even if it assumes that 510 ft is rounded, the conversion to 160 m doesn't make sense. The range of 505 ft - 515 ft corresponds to (approximately) 154 - 157 m. 160 meters is not a sensible answer. I think it's better if by default it uses something similar to |round=5. Denvercoder9 (talk) 17:11, 28 April 2022 (UTC)

The output had been rounded to a multiple of 10 metres, so the output of 160 m refers to an approximate value between 155 m and 165 m. If you don't like the default rounding, you can modify it, like I already have done in the article you referred to. -- Dr Greg talk 17:24, 28 April 2022 (UTC)

FAQ #1 at the top of this page has the answer to your question, Denvercoder9. Imzadi 1979 → 17:06, 28 April 2022 (UTC)

@Denvercoder9: It's all about significant figures. 505 and 509 both have 3 sig fig; 510 has 2. It is an error to give the result of a calculation to a greater precision than any of its operands. --Redrose64 🌹 (talk) 21:14, 29 April 2022 (UTC)

"510 has 2" is not quite true. We don't know if 510 means 510±0.5 (the intent) or 510±5 (what convert treated it as, based on the number of 0's at the end). Either one could be correct in different circumstances and convert has no way to decide on it's own. Some numbers like 51,000,000 are very unlikely to be intended as 51,000,000±0.5 and convert would correctly treat it as 51,000,000±500,000. In tricky cases like 510 we have to add |0 to force convert to use 0 decimal places for rounding. Stepho talk 22:14, 29 April 2022 (UTC)

The convert template, by default, treats trailing zeros as non-significant figures. The way to force 510 to be treated as having three significant figures is not to use |0 - which determines the precision of the result - but to use |sigfig=3, which specifies the precision of the input value: 510 ft (155 m). This is documented at Template:Convert#Round to a given number of significant figures: |sigfig=.--Redrose64 🌹 (talk) 14:02, 30 April 2022 (UTC)

Correct. Either option works for 510. |0 affects significant digits from the decimal point (positive means more digits after decimal point, negative means spread zeroes from the decimal point). |sigfig=3 counts significant digits from the beginning. Both work in most cases, both have advantages/disadvantages in a minority of cases - usually where the output is close to a power of 10 that might or might not add an extra digit. Stepho talk 00:15, 1 May 2022 (UTC)

Suggested format improvement

Suggestion ... add a non-breaking space –&nbsp– between the base units and their conversion to prevent confusing separation of the units, like this, at the end of a line:

...text... 100 kilometres

(62 mi) ...

Instead, it should look like this:

...text...

100 kilometres (62 mi) ...

The inclusion on the non-breaking space would have no effect in the middle of a line, viz:

... 100 kilometres (62 mi) ...

Further, this suggested change to the template would be benign; it would have no material effect on any of the many places where the template is used in existing articles, other than to eliminate the separation of base and converted units if they appear at the end of a line.

Thanks for considering such an improvement to this template. Truthanado (talk) 23:58, 18 April 2022 (UTC)

There are places where that would be helpful but there are others where non-breaking spaces are a problem, particularly on a mobile device with a narrow screen. At any rate, it's a manual-of-style issue and convert follows the advice at MOS:UNITNAMES: "a normal space is used between a number and a unit name". Johnuniq (talk) 00:48, 19 April 2022 (UTC)

Adding the nbsp before the opening paren would make a somewhat-longer-than-desirable unbreakable block which would often break like this:

... 100

kilometers (62 miles)

-- which, while technically compliant with the rulez, is certainly less desirable than the thing the OP wants to avoid in the first place. To solve that we'd need to make the whole 100 kilometres (62 mi) unbreakable, and that's way too big an unbreakable block, unless you're in some impossible situation. E Eng 02:20, 1 May 2022 (UTC)

Time conversion

Is there a way to denote a conversion from minutes and seconds to total seconds....or, similarly from hours/min/sec....or any such combination. I note that showing minutes and seconds in the template as a minutes-decimal value does work, but would prefer to be able to enter the actual seconds value, rather than its decimal equivalent. DonFB (talk) 14:47, 6 May 2022 (UTC)

No, convert does not handle combinations like that. Does anyone know of a template dedicated to this? What is the usage? The parser #time function can do many clever things (Help:Magic words). Johnuniq (talk) 23:59, 6 May 2022 (UTC)

[1] Bureau Internationaldes Poids et Mesures (2019), The InternationalSystem of Units(SI) (PDF) (9th ed.), p. 143, ISBN 978-92-822-2272-0, retrieved 14 October 2020

[GR1-2] "2010 Census Gazetteer Files". United States Census Bureau. August 22, 2012. Archived from the original on April 19, 2015. Retrieved April 19, 2015.

[3] Mixing werewolf and vampire imagery here.

[1]

[1]

[2]

Archives

Archives discussion

Archive proposal

Search experiment

Deadweight tonnage

Proposal: Add angular units

Mach conversions are off

g/PS/h fuel efficiency

Bits and bytes

Post-closing thoughts

Better wikilink needed

Absolute temperature vs. temperature difference

pounds of coal per indicated horsepower hour

Long Ton to Ton conversion wrong

Thanks

Long ton template

How far are we from being able to add a unit user preferences option?

Usage question

Mach

visualhide removal

And...

More than one thousands separator

"abbr=on" adds units to each number.

"sq" vs. "2"

Significant figures, opaque template behavior, and simple arithmetic

Ton-miles

Module version 25 (see May 2021 for release)

Vertical spacing

Range and adjective

Module:Convert/helper: use Lua decode (&copy; → ©)?

Proper counterpart unit for acres: is there a consensus?

Display order priority of SI units and non-SI units

Engine volumes

Multiple dimensions: (height x width x depth)

Scientific notation with range

Conversion without parentheses?

Handling an unwieldy conversion

Add disp=/ and/or disp=s

Earth pounds

Candlepower

Another rename: mmHg

Rpm & Hz

Twice in an article

Use "a" or "an" instead of "1" or "one"

Edit notice

Feet to metres conversion

Density question

I/O

How to convert

Parameter list - adj. is stuck in abbr.

Parameter value

L for liter

lboz as a per unit

And another new unit request

Module version 25

Fraction templatestyles

Brackets

disp=or question

People per square mile

Module version 26

Unit fixes

Acre-feet vs. acre feet

Angstrom

Lakh

Display tonnes, not t?

Hoppus

Conversion from fraction of c

Inconsistency in denoting US vs imperial gallon in composite units

l/ks?

Inconsistency between convert and cvt (in some situations) with regard to non-breaking space placement

Price per pound: suppress the "1"

A third output option for spelling out thousands, etc.?

Proposal: unit miles will always output "miles"

+ in tables

Multi line breaks info-box output

Mixed ranges

Abbreviations

110 crore tonnes

Changes in spelling of units over time

Mach Speed

"sq" vs. "²"

Module:Convert/helper: use Lua decode (© → ©)?