Template talk:Convert/Archive 2

Archives discussion
This talk page uses amazing code to make month/year archives. That was highly desirable a long time ago when the old templates were used because maintaining 4,000 templates was a lot of effort. However, a more conventional system might be appropriate now. I suppose there could be a link to an index page with links to all the month/year archives—it would need a "search archives" box. Or, lazy people like me might just leave the current system working. If it's left as-is, should Template talk:Convert/Archive 1 be deleted and salted to prevent further accidental creation? That page was deleted in May 2015 and December 2015, and has just been created again (hi !). Thoughts? Johnuniq (talk) 01:34, 9 July 2020 (UTC)
 * My pleasure. EEng 02:51, 9 July 2020 (UTC)
 * Seriously, the whole per-month archive thing just makes it hard to find something dimly remembered, or to review related discussions over time. Can it all be junked and the threads aggregated onto a few big pages? EEng 02:53, 9 July 2020 (UTC)
 * Go for it, but that was the reason for my post, namely to highlight that some issues will need work. I don't think mucking around with the old archives would be desirable, but those back to a certain date (perhaps all of 2020?) might be consolidated to Archive 1. A new system needs: an index showing the old archive links; a search box that works on the old archives; a new auto index for Archive 1, 2 etc.; a search box for the new archives. By the way, I copied /Archive 1 into /Archive June 2020 but did not blank the former pending discussion here. Johnuniq (talk) 03:36, 9 July 2020 (UTC)
 * Don't look at me. I'm not getting into the ring with some angry bot. You're the technical wizard. EEng 14:53, 9 July 2020 (UTC)
 * I find the year/month archives useful for finding old discussions to show new people the reasons why we chose something. This helps avoid endlessly rehashing the same topics (well, at least it helps a bit, even it it doesn't completely stop it). I use Google to search based on a few keywords and sometimes the year if my memory is good enough. Losing all the previous years means no longer knowing why we chose something.  Stepho  talk 14:10, 9 July 2020 (UTC)
 * No one's talking about losing anything, merely gathering all threads into a relatively small number of large-ish archive pages instead of a zillion archive pages, one for each month and each with just two or three threads on it. At least that's what I'm talking about. EEng 14:53, 9 July 2020 (UTC)
 * Switching to numbered pages is easy, by parameter (works with Talk:Gold & with the manual Archive button - I experienced. We can then manually: Set counter to #2 right away; Use #1 for past months of 2020; Add numbered box. The monthly-box: fold into years-only showing. Possible issue to check: one search box works searching both two sets of pages having .../Archive? -DePiep (talk) 15:58, 9 July 2020 (UTC)
 * Would this solve the point, Johnuniq? -DePiep (talk) 15:58, 9 July 2020 (UTC)

Plan Everyone went quiet but I'm warming to the following idea: Thoughts? Johnuniq (talk) 10:09, 17 July 2020 (UTC)
 * Keep all archive pages unchanged for 2019 and earlier.
 * Merge all the archive pages for 2020 to a single /Archive 1 page.
 * Put the current index of year/month links at the top of /Archive 1.
 * Switch archiving of this page to use the common Archive 1/2/3... procedure, with a fairly large number of bytes as the maximum for each archive. That should fit at least a year into a single archive instead of twelve.
 * Put the standard archive box on this page with a search box. That search will find discussions on all archive pages (numbered and year/month).
 * As I think I mentioned I'm very partial to large archive pages so that you don't have jump from page to page when reviewing some complicated set of related threads. However, there's also something to be said, with moderately active to very active talk pages, for each archive page to carry chronological info in its title. Is there a way for the pages to be called 2020a, 2020b, and so on? (Actually, if the size limit is, say, 700k then I don't think we'd ever get to 2020b, but we have to be be prepared.) <b style="color: red;">E</b><b style="color: blue;">Eng</b> 11:46, 17 July 2020 (UTC)
 * I support this plan. -DePiep (talk) 16:07, 17 July 2020 (UTC)
 * Archive 1/2/3 with roughly a year's worth in each works best for me. But as long as the old history is still around, I'm happy to follow the pack. Apologies for late reply, I was camping for a few days.  Stepho  talk 03:43, 19 July 2020 (UTC)

Done Please check the archive box that I put on this page. It would be desirable to add a note somewhere that the old archives are listed at Template talk:Convert/Archive 1. I made the 2020 archive pages redirect to Archive 1. Johnuniq (talk) 01:46, 21 July 2020 (UTC)

Archive proposal
What DePiep said looks good, although how the archives work doesn't affect me because I keep a single local file with all the archives concatenated so I can search it more easily. One search box will work (see below).

There are 153 archive pages totalling about 7MB. The six 2020 archives total about 132KB. I think the archives older than 2020 should be left alone, but those in 2020 should be consolidated in /Archive 1, and the 2020 archive pages deleted. EEng is right in that having, for example, one largish archive per year rather than 12 short archives per year would make finding recent discussions much easier.

Does anyone want to keep the current system for 2020 and the future? If we agree to change, it looks like it would be readily achievable except that there would need to be an index page listing the month/year archives, with a link to the index on this page, preferably in a new archive box, or at least near it. Or, we could put the index at the beginning of Archive 1. The index is currently at Template talk:Convert/Archives with some tricky wikitext. That could be replaced with the expansion from Special:ExpandTemplates so it would work on another page. Thoughts? Johnuniq (talk) 05:23, 10 July 2020 (UTC)

Search experiment
This is the current search archives box. It works on all /Archive subpages so will handle /Archive June 2020 as well as /Archive 1. For example, typing  in the following finds both those pages because I moved text from the latter to the former so a section is currently duplicated. Examining the URL generated by the search show something strange: It includes: &fulltext=Search+archives &fulltext=Search which seems wrong. I imagine only the first of these is used. The second is either a mistake or a lazy way of providing a default in case  is omitted. Johnuniq (talk) 05:23, 10 July 2020 (UTC)
 * You write: It works on all /Archive subpages so will handle /Archive June 2020 as well as /Archive 1. That says it all. My thumb is up. Not for love, but from rational improvement I see. -DePiep (talk) 20:46, 18 July 2020 (UTC)

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

The multiple units feature of can be used in input:


 * → 2° 47′ 19″ (0.048670 rad)
 * → 47′ 19″ (13.764 mrad)

And output:


 * → 0.50 milliradian (1′ 43″)
 * → 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 ( 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:
 * → 5 L/100 km
 * → 10 L/100 km
 * 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)
 * → 10 L/100 km
 * 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)




 * — 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)
 * Not in astronomy:


 * Arcsecant is not a measurement unit anyway, so  will be unambiguous when used with  . — 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?--<span style="font-family: Lucida Handwriting, Lucida Calligraphy, Bradley Hand ITC, cursive; font-size:90%;">Newbiepedian (talk · C · X! · L) 15:44, 2 August 2020 (UTC)


 * , 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:
 * 2.2 Mach gives 2.2 Mach
 * 2.2 Mach gives 2.2 Mach
 * -- 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 190 g·PS&minus;1·h&minus;1 (258 g·kW&minus;1·h&minus;1) 190 g·PS&minus;1·h&minus;1 (258 g·kW&minus;1·h&minus;1) How was this calculated and how can this be  done with convert? Peter Horn User talk 00:22, 4 August 2020 (UTC)
 * wrote Ikarus 55 in May 2019 and may like to comment. I'm not familiar with measuring fuel consumption in that manner and the &minus;1 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&minus;1·h&minus;1 (258 g·kW&minus;1·h&minus;1)
 * → 190 g/PS/h
 * → 190 g/PS/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&minus;1·h&minus;1. 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  is used for expressing a single value whereas  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:
 * would display 2,000,000 bytes (2 MB)
 * 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:
 * would display 2,000,000 bytes (2 MB)
 * 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:
 * would display 2,000,000 bytes (2 MB)
 * 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:
 * would display 2,000,000 bytes (2 MB)
 * would display 64 KB
 * would display 64 KiB
 * 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. . 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 23:54, 13 October 2020 (UTC)
 * '"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)
 * Writing "216 = 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 216 or 103. Eventually the ambiguity will be unacceptable in common usage and MOS will change. Even then, writing "216 = 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, 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)

Post-closing thoughts

 * Regarding  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,, which renders as 1.2 ktonTNT, the link over TJ goes just to Joule, rather than to Terajoule, which redirects to Joule. 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? &#123;{u&#124; Sdkb  }&#125;  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 ." yields "The mean winter temperature in Smallville is 3 C."

But Convert cannot handle temperature differences correctly:

"The mean annual temperature in Smallville has increased by  in the last century." yields "The mean annual temperature in Smallville has increased by 3 C 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:. 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)
 * it already handles this (Template:Convert) :
 * : 3 C-change
 * : 3 C
 *  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:
 * → 1 hph
 * → 1 hph
 * → 1 hph
 * The last would allow something like "2 lbs of coal per indicated horsepower-hour (2 lbs of coal per 1 hph)". 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. How to fix? Or can someone else correct the conversion? 50.107.153.113 (talk) 21:23, 17 September 2020 (UTC)
 * Ex:  incorrectly yields 4,000 tons, not 4,368 tons.  Proof: 3900 LT
 * Ex:  incorrectly yields 2,100 tons, not 2,352 tons.  Proof: 2100 LT
 * See Propulsion section of the IJN aircraft carrier Akagi.
 * N/m. I see the authors in many pages are specifying an incorrect abbreviation, using "t" instead of "ST".  Le sigh.
 * Ex:  more correctly yields 4,400 tons, not 4,368 tons.  Proof: 3900 LT
 * Ex:  more correctly yields 2,400 tons, not 2,352 tons.  Proof: 2100 LT
 * 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:
 * &rarr; 3900 LT
 * &rarr; 2100 LT
 * &rarr; 3900 LT
 * -DePiep (talk) 21:33, 17 September 2020 (UTC)


 * Rounding can be controlled:
 * &rarr; 3900 LT
 * &rarr; 2100 LT
 * 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 11:13, 28 November 2020 (UTC)

Long ton template
does not work but this  does work. Talk:South Australian Railways 700 class (steam) 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:
 * Johnuniq (talk) 01:18, 22 November 2020 (UTC)
 * Added trim to all unnamed parameters. Demo example in OP does not show error anymore ;-) -DePiep (talk) 13:16, 28 November 2020 (UTC)
 * 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? &#123;{u&#124; Sdkb  }&#125;  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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 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)
 * , we've been around this loop before. See Template talk:Convert/Archive 1. Looks like you have to remember to use abbr=on, I'm afraid. --John Maynard Friedman (talk) 16:21, 9 November 2020 (UTC)
 * Actually, 1.6 km 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: --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 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; 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)
 * 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
 * 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)
 * 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, (5 m), 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  produces , 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)
 * 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 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): 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)
 * 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
 * This is now at WT:Manual of Style/Dates and numbers. 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? <b style="color:#00FF00">MB</b> 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)
 * 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)
 * 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 1.6 Mach 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)
 * That was a lazy search up there. This one is probably more representative. About 200 cases. --Izno (talk) 19:32, 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)
 * 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. 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: 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  usages and possibly others? Would they work painlessly? Johnuniq (talk) 23:55, 2 December 2020 (UTC)
 * More info: the above numbers are counts of and  in article wikitext. Those templates are called many more times from infoboxes, for example for a person's height or weight. I'm hoping  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:
 * 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 ; maybe you have a different limit in mind. AIUI, TemplateStyles comes out of the budget for rather than the, which means you have a different budget you have to care about. (, 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 &lt;style> tag is emitted with the content of the styles, and then any subsequent uses of the TemplateStyles tag emit a &lt;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  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  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. ;)
 * , I see opportunity in  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  .)
 * 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  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.  might have some knowledge there.
 * Common to the other places 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 &lt;sub> and &lt;sup> [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)
 * , "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. —Th e DJ (talk • contribs) 09:11, 3 December 2020 (UTC)
 * re "why 1/undefined is being forked here" . Don't know about, but in Track gauge I did so to remove the nowrap tag, since nowrap was needed only once enveloping all of "$1/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)
 * 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 for every use and they're then deduplicated, and apparently the unstrip size is measured before deduplication. Anomie⚔ 17:02, 3 December 2020 (UTC)
 * 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 for every use and they're then deduplicated, and apparently the unstrip size is measured before deduplication. Anomie⚔ 17:02, 3 December 2020 (UTC)

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 ? EO LE 79  ( 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 ) is: The second convert shows how it would look with gaps, and here is how it is wanted:
 * → 0.1 AU
 * → 0.1 AU
 * 0.1 AU ( 15 000 000 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 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). EO LE 79  ( 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)
 * 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. 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.


 * → 225 ×
 * → 225 ×

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.-<b style="background:#00ffff">Ich</b> (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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:47, 12 December 2020 (UTC)
 * No need to WP:SHOUT at us, . -DePiep (talk) 22:31, 12 December 2020 (UTC)
 * I wasn't addressing you so please butt out. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 01:42, 13 December 2020 (UTC)
 * Why not use  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  .   outputs × with no spacing, while   outputs × with a nonbreaking space on each side. You would use one of these in a table:
 * You can add "mm" after each convert if really wanted.
 * By the way, use  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)
 * You can add "mm" after each convert if really wanted.
 * By the way, use  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. "2"
In the lead for Europe, I noticed the slightly jarring juxtaposition of 10,180,000 km2, where the kilometers uses "2" but the miles uses "sq". Looking at the documentation here, it seems to be a U.S. vs. UK thing, but from my experience, "2" is generally more popular in America, too. Have we considered just going to "2" for all uses? &#123;{u&#124; Sdkb  }&#125;  talk 07:11, 13 December 2020 (UTC) 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 undefined undefined, as I use it extensively and wasn't aware that it was possible to get it to output e.g. "in2" until very recently.
 * For a contrasting view, see Template talk:Convert/Archive 1 by . 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."
 * 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:.

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:


 * 1)   = "The building was 345 ft tall"
 * 2)   = "The building was 350 ft tall"
 * 3)   = "The building was 355 ft tall"
 * 4)   = "The building was 360 ft 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 uses  in the second paragraph which starts with "More than 12000 mi of roads". Rounding to the nearest km would give "More than 12000 mi 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)
 * 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 358 ft tall"
 * = "The building was 350. ft tall"
 * Specifying a decimal value sets the full precision.
 * Then consider decimal fractions:
 * = "The model was 3.45 ft tall"
 * = "The model was 3.50 ft tall"
 * = "The model was 3.55 ft tall"
 * = "The model was 3.60 ft tall"
 * = "The model was 3.5 ft tall"
 * = "The model was 3.6 ft 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 "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)
 * 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:
 * 1) 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.
 * 2) Take it as exact and allow specific instances to choose larger rounding. Awkward for articles dealing with big numbers.
 * 3) 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  or   or   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)
 * 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) 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. 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.   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 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) . Tonne kilometer is a redirect to Units of transportation measurement. Hawkeye7   (discuss)  00:59, 18 December 2020 (UTC)

I added the units at Module:Convert/documentation/conversion data and included them in the module. If these are used in articles in the next couple of days (before the release above), they will be included in the main data. Otherwise, they will be temporary. Examples (please check!): Johnuniq (talk) 02:40, 18 December 2020 (UTC)
 * → 1 tkm
 * → 1 ton-mile
 * → 1 tkm
 * → 1 ton-mile
 * → 2 tkm
 * → 2 ton-mile
 * 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.

Release notes for earlier versions are listed here. Johnuniq (talk) 06:13, 14 December 2020 (UTC)
 * 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, ).
 * Unit changes:
 * Remove  from the unit definitions. This is not a change to units as   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.
 * is retained in extra; it will be removed if not found to be used in articles.
 * Occurrences of  and   in articles will be replaced with   and   which have had their link corrected to standard cubic foot. Discussion here.
 * Tweaks:
 * Module:Convert/wikidata will use  instead of deprecated.
 * 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 [//en.wikipedia.org/w/index.php?title=Template:Sfrac&diff=659287868&oldid=643190924] 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. 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 &lt;sub> and &lt;sup>, 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 $0.017$, 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: $23.439$ &rarr; c/p gives:
 * sfrac: $0.409$ &rarr; c/p gives:
 * -DePiep (talk) 00:22, 16 December 2020 (UTC)
 * Ping User:Izno because of . -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 $282.938$, 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. 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  to indicate that it is not a proper data table per the default HTML semantic assignment for   elements (we have a lot of unfortunate legacy on that point, so we've bolted on a lot of  ) . It is primarily intended for enhanced accessibility. See also MDN.   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)



Vertical spacing

 * 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 14:37, 19 December 2020 (UTC)
 * The problem is that <sup ></sup> and <sub ></sub> are setting line-height to 1em (which is rendered as 10.16px on my Monobook skin). The corresponding classes  and   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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 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 would know best. Optionally, if you wanted to make sure that "" 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   for four extra bytes, then you would create   and   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'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 would know best. Optionally, if you wanted to make sure that "" 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   for four extra bytes, then you would create   and   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)
 * User:Johnuniq/sandbox2 uses Template:Frac/styles.css
 * User:Johnuniq/sandbox uses Template:Frac/sandbox/styles.css
 * 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  as in   and then wrapping some content in the same page as your other case with the sandbox class). See mw:Extension:TemplateStyles. --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:
 * → 300 by
 * 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. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 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:
 * 300 to 500 ft &rarr; 300 to 500 ft
 * 300 to 500 ft &rarr; 300 to 500 ft
 * 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 m (and here we encounter the rounding conundrum once again). <b style="color: red;">E</b><b style="color: blue;">Eng</b> 18:04, 20 December 2020 (UTC)
 * Would explain the numbers :-). Who's gonna build the demo? -DePiep (talk) 18:31, 20 December 2020 (UTC)
 * in case you have swapped the units inadvertedly, as your numbers indicate (manual input), here is the reverse version:
 * 300 to 500 m &rarr; 300 to 500 m
 * 300 to 500 m &rarr; 300 to 500 m
 * -DePiep (talk) 06:59, 24 December 2020 (UTC)

Module:Convert/helper: use Lua decode (&amp;copy; &rarr; ©)?
Module:Convert/helper does some pre-Convert input cleanups. For this it also replaces, for example,  with  : good. This simplifies later string handling jobs like search&replace, etc. See this code:

. 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  . 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  is  . For example,   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)
 * 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 contains four converts, three of which concern areas and are like  with different numbers. An editor has chosen to specify that the output should show the km2 value by specifying   as the output unit. That choice is an editorial matter which is outside convert's scope. If the area is wanted in hectares, replace   with   or omit  . 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 km2. 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)
 * 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 km2 –  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 . 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 m2 for the small stuff (eg, my house and immediate surroundings of 700 m2) or km2 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 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&mdash;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 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 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 10000 acre = 10000 acre v 10000 acre = 10000 acre. 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)
 * 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 km2 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 km2 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)
 * Exactly! And that's why the SI pedants insist that it is all wrong. A km2 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 km2 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)
 * But all SI units of area (or volume) work like that consistently, without exception. A km2 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 m2; 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 $4.938$ 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)
 * 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 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 flip or 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: cuin, cc, L. Will this do?
 * &rarr; 1300 cc
 * &rarr; 95 cuin
 * -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 workings:
 * &rarr; 44 L
 * OK? (or else, linking to an article would help). -DePiep (talk) 16:29, 26 December 2020 (UTC)
 * And add  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, of course. It might be best to think about the units used in  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: For example,  → 2500 cm3 and   → 2500 cm3. 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, uses the space with different meaning (as unit-separator):   &rarr; 10 km. -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:
 * → 3 x
 * → 3 x
 * 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 but the template gives me either or 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)
 * (5.4 ± 0.5) kg [(1.2 ± 0.1) lb]
 * 5.4e17 +/-
 * 5.4e17 +/-
 * 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)
 * Sure – see Template:Convert . For example:
 * → (elev. 10 m)
 * 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. 10 m) <b style="color:#00FF00">MB</b> 02:11, 23 January 2021 (UTC)
 * That's even better! Thanks! 1980fast (talk) 07:27, 26 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  or  . 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.
 * → 8,600 e6lb
 * → 8,600 e6lb
 * → 8.6 e9lb
 * → 8.6 e9lb
 * Johnuniq (talk) 08:14, 26 January 2021 (UTC)

Add disp=/ and/or disp=s
For Iztapalapa could we have disp=/ and/or disp=s? eg ( 2,400 m asl) (2,400 m asl) instead of ( 2,400 m asl) (2,400 m 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 (lbm is an alternative) and pound (force) has the symbol lbf. 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)
 * 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).
 * 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 and elsewhere would it be possible to have (a) conversion(s)? say for example 2,000 cp. 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 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". 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.
 * → 12 mmHg
 * Johnuniq (talk) 03:04, 9 March 2021 (UTC)

Rpm & Hz
For Straight-six engine 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz). Would it be possible to have 6,000 rpm 6,000 rpm & 2,750 rpm 2,750 rpm? 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.
 * → 1 rpm
 * → 12 rpm
 * → 12 rpm
 * Johnuniq (talk) 02:54, 9 March 2021 (UTC)


 * 6000 rpm
 * (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)
 * 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)
 * What was shown is 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz) the conversions became 6,000 rpm & 2,750 rpm. 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:  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:
 * → 6,000 rpm
 * → 2,750 rpm
 * Johnuniq (talk) 02:28, 11 March 2021 (UTC)
 * Looks much better, thanks! GliderMaven (talk) 04:40, 11 March 2021 (UTC)

Thanks for reporting the discrepancy but it was convert that was wrong—now corrected. By the way, when you see  it would be good if you were to change that to. One of the edits you made changed the first of the following to the second: You probably don't want to flip it like that. If you want both cuin and L with L as the input, you need: Also, please have a look at Straight-six engine which is showing  as the second paragraph. It looks like a stray character was inserted. Johnuniq (talk) 02:28, 11 March 2021 (UTC)
 * → 9120 cc
 * → 9120 cc
 * → 9120 cc
 * 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, Willbb234Talk (please &#123;&#123;ping&#125;&#125; me in replies) 23:15, 10 March 2021 (UTC)
 * 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, Willbb234Talk (please &#123;&#123;ping&#125;&#125; 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, Willbb234Talk (please &#123;&#123;ping&#125;&#125; me in replies) 17:10, 11 March 2021 (UTC)

Use "a" or "an" instead of "1" or "one"
touchtennis originally had the sentence However, variances of up to a metre are tolerated&hellip; The convert template let me change it to However, variances of up to 1 metre (3 ft 3 in) are tolerated&hellip; but I think the original (with conversion) reads better: However, variances of up to a metre (3 ft 3 in) are tolerated&hellip; Is there an option to use "a"?

Thanks, cm&#610;&#671;ee&#9094;&#964;a&#671;&#954; 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 ( 1 m ) are tolerated
 * However, variances of up to a metre (1 m) 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 are tolerated". Giving you: "However, variances of up to  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&#610;&#671;ee&#9094;&#964;a&#671;&#954; 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? <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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:
 * → 5 ft
 * It had been recently changed to:
 * → 6 ft
 * The " " in  tells convert to round the result to zero decimal places. No output unit was given (because the recent edits removed  ) and convert used its default for that which is  . 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  (giving 6 ft 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 :* which results in "commonly 30 /sqm"

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). <b style="color:#00FF00">MB</b> 16:28, 21 March 2021 (UTC)
 * The following should be ok.
 * → 30 /m2
 * 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  works is that the unit   is an alias for   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 is where  and   seem to be missing. I'm not clear if you mean that this list is supposed to be complete or not. <b style="color:#00FF00">MB</b> 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 flip and out is used


 * So, 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 \and 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:
 * → 40 e6ton-mile
 * → 40 e6ton-mile
 * 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)
 * 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
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 &#124; [//xtools.wmflabs.org/ec/en.wikipedia/WT79 editing patterns] &#124; [//xtools.wmflabs.org/globalcontribs/WT79 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, then I want to look up what " " 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 " ". Since the   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 &#124; [//xtools.wmflabs.org/ec/en.wikipedia/WT79 editing patterns] &#124; [//xtools.wmflabs.org/globalcontribs/WT79 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, 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 in. 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 - "(20911&#8260;16lb/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, 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 undefined PD/kg, 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 2000000 /kg 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
Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
 * This version was discussed in December 2020 but the release was stalled while the template styles were finalized.

Release notes for earlier versions are listed here. Johnuniq (talk) 01:16, 4 May 2021 (UTC)
 * 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, ).
 * For localization, the template styles are in Module:Convert/text which now exports the  table.
 * Unit changes:
 * Remove  from the unit definitions. This is not a change to units as   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  added and unit   has symbol g0 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.
 * is retained in extra; it will be removed if not found to be used in articles.
 * Occurrences of  and   in articles will be replaced with   and   which have had their link corrected to standard cubic foot (discussion).
 * Link for unit  changed to Millimetre of mercury with re not er spelling (discussion).
 * New unit  (discussion).
 * New units  and   (discussion).
 * Tweaks:
 * Module:Convert/wikidata will use  instead of deprecated.
 * Done, the new version is live. Johnuniq (talk) 05:21, 6 May 2021 (UTC)

Fraction templatestyles
Having convert use fraction and sfrac templatestyles was discussed in December 2020: Part of that involved a demonstration that the vertical spacing was a problem: The vertical spacing problem was fixed by in Template:Fraction/sandbox/styles.css. However the fix was not used for. 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)
 * Template talk:Convert/Archive 2
 * Template talk:Convert/Archive 2
 * Template talk:Convert/Archive 2
 * User:Johnuniq/sandbox2 uses Template:Fraction/styles.css
 * User:Johnuniq/sandbox uses Template:Fraction/sandbox/styles.css
 * I removed the temporary  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, 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.
 * 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)
 * The new version is now live. Johnuniq (talk) 05:24, 6 May 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)
 * The new version is now live. Johnuniq (talk) 05:24, 6 May 2021 (UTC)

Brackets
Hi all, After a conversation last month with, I have started to use the convert template for windspeeds with the following configuration: 125 kn , however, I noticed earlier that the template is not putting the output in brackets 125 kn. 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)
 * I think you want the second of these:
 * → 125 kn
 * → 125 kn
 * Johnuniq (talk) 03:26, 6 May 2021 (UTC)
 * Thanks .Jason Rees (talk) 13:20, 6 May 2021 (UTC)

disp=or question
Why, when using, 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. That behavior seems incredibly inconsistent. Thanks for any clarification! 1980fast (talk) 04:04, 7 May 2021 (UTC)
 * With, the default is abbr=off. However abbr can also be specified as   or.
 * → 7 in
 * Johnuniq (talk) 07:18, 7 May 2021 (UTC)
 * Thanks! Because the  option is not mentioned at all in the section on , 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 4,660.0 people per square mile (1,799.2/km2) How was this calculated? It does not appear to be done by template convert. 4,660.0 people/square mile  4,660.0 density/square mile Peter Horn User talk 23:38, 15 May 2021 (UTC)


 * 4,660.0 /sqmi → 4,660.0 /sqmi  Stepho  talk 00:09, 16 May 2021 (UTC)
 * Convert options:
 * → 4,660.0 /sqmi
 * → 4,660.0 PD/sqmi
 * → 4,660.0 /sqmi
 * 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.

Release notes for earlier versions are listed here. Johnuniq (talk) 03:27, 3 June 2021 (UTC)
 * Unit changes:
 * Link and name have been hyphenated for units:  +   +   +.
 * Link changed to Units of textile measurement for unit:.
 * Link changed to Ampere per metre which redirects to Magnetic field for units:  +   +.
 * Link changed to Pound-mole which redirects to Mole (unit) for units:  +   +   +   +   +   +   +   +   +.
 * Link changed to long quarter which redirects to Avoirdupois system for units:  +.
 * Link changed to short quarter which redirects to Avoirdupois system for unit:.
 * Link changed to Rod (unit) for unit:.
 * Link changed to Cubic foot per minute which redirects to Cubic foot for unit:.
 * Link changed to Cubic yard per second which redirects to Cubic yard for unit:.
 * Link changed to Pound per square inch for units:  +   +.
 * Link changed to Pound-force per square inch which redirects to Pound per square inch for unit:.
 * Module:Convert/wikidata/data updated to match some changes to units on Wikidata (comparison of sandbox units with those in Wikidata is here).
 * Done, the new version is live. Johnuniq (talk) 03:21, 6 June 2021 (UTC)

Acre-feet vs. acre feet
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  display   rather than  ?

Let me add that I found a relevant discussion on this talk page from 2011, Template_talk:Convert/Archive_September_2011. It appears that either no change was made to  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. If so, I would like to know. --<b style="font-family:Rockwell">Jsayre64</b> <b style="font-family:Rockwell">(talk)</b> 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  as the symbol and   as the unit link and singular name. The two "foot" units have   as the plural name while the other units give  . 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   is an okay workaround method in the case of acre-feet, but even so, that dot indicating multiplication looks quite small to me. <b style="font-family:Rockwell">Jsayre64</b> <b style="font-family:Rockwell">(talk)</b> 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: These are aliases for :   +

These are aliases for :   +   +   +   +  Johnuniq (talk) 10:19, 19 May 2021 (UTC)


 * Those look great! Is it okay to use  in an article though? <b style="font-family:Rockwell">Jsayre64</b> <b style="font-family:Rockwell">(talk)</b> 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. <b style="font-family:Rockwell">Jsayre64</b> <b style="font-family:Rockwell">(talk)</b> 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 which points to lakh and crore. Johnuniq (talk) 00:00, 25 May 2021 (UTC)
 * Testing...
 * = 400 lakh
 * = 400 crore
 * = 400 lakh crore
 * = 400 mi
 * 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, 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  and it would display "" 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). --Guy Macon (talk) 06:15, 25 May 2021 (UTC)

Display tonnes, not t?
In conversions such as 30 lt, which renders as 30 lt, I would like to have "tonnes" displayed instead of t: 30 long tons (30 tonnes). Can this be done? Cheers, Simon – <b style="color:#7F007F; font-size:medium">SCHolar44 🇦🇺</b> 💬 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.
 * → 30 lt
 * → 30 lt
 * For all units, see here. Johnuniq (talk) 04:02, 9 June 2021 (UTC)
 * Many thanks, Johnuniq! <b style="color:#7F007F; font-size:medium">SCHolar44 🇦🇺</b> 💬 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. <b style="color:#7F007F; font-size:medium">SCHolar44 🇦🇺</b> 💬 at 05:55, 11 June 2021 (UTC)
 * Use Lcwt (long hundredweight) which can optionally be followed with qtr (quarter).
 * → 30 lt
 * 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 Johnuniq -- no?) SCHolar44 (talk) 05:59, 12 June 2021 (UTC)
 * 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. <b style="color:green">Tarl N.</b> ( discuss ) 06:49, 12 June 2021 (UTC)
 * Ah! The scales fall from my eyes! Many thanks for taking the time to educate me,  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  and   exist. The difference is that the first give "board feet" as the plural name while the second is always "board foot".
 * → 12 board feet
 * 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   12 bdft  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  also exists and works as shown in your above comment. Johnuniq (talk) 02:07, 13 May 2021 (UTC)
 * Not so fast. Hoppus and Hoppus 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)
 * 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 "$7 1/2$", 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? <b style="color:green">Tarl N.</b> ( discuss ) 05:17, 12 June 2021 (UTC)
 * Hmm. 0.1 light-year/year yields 0.1 light-year/year. <b style="color:green">Tarl N.</b> ( 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)
 * 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)
 * 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 USgal and 100 impgal
 * 100 USgal and 100 impgal

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


 * 100 USgal/h vs 100 impgal/h
 * 100 USgal/h vs 100 impgal/h

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.
 * → 100 USgal/h
 * → 100 U.S.gal/h
 * → 100 USgal/h
 * → 100 U.S.gal/h
 * Those units behave like that due to the definitions in Module:Convert/documentation/conversion data (see Module:Convert/documentation/conversion data regarding  and   in the definitions). By contrast, the unit   is not defined so convert handles it automatically as a "per" unit:
 * → 100 usgal/h
 * For historians,  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:  → 100 usgal/h. 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  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   (l impgal) and the default output for   (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  . 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 undefined undefined.

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 undefined undefined. 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 1 lb...." 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 (1 lb)... will do it. Someone else may have a better way. <b style="color:#034503">MB</b> 16:13, 28 June 2021 (UTC)
 * That is, in code  -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:
 * &rarr; (50 $/lb) -DePiep (talk) 17:07, 28 June 2021 (UTC)
 * For a bit more elegance  could just be used to get "It sold for 50 ¢/lb)".
 * 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  and   when using an   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.
 * → 100 e6mile
 * There are lots of converts in articles that use  or   as the input and currently they are aliases for  . 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  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 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  as a test: You might like to try this. Johnuniq (talk) 01:30, 20 June 2021 (UTC)
 * → 1 Mile
 * → 15 Mile
 * → 100 e6Mile
 * 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  or   yet output. Examples: 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  or   in a convert template if they want readers to see  ? 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)
 * Sur, Oman:  → 93 mile
 * Kovan MRT station:  → 1.3 km
 * Cuban Missile Crisis:  → 90 miles


 * 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" 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 there is a need to add the conversion for "3000+ m". The best I've found is  but that shows only the + only in the first column: Is there a way to get the + into both columns? Thryduulf (talk) 20:07, 18 July 2021 (UTC)
 * lol, just trying  does not show the prefixed gt symbol at all?!
 * {|class="wikitable sortable"

!m!!ft
 * &gt;3000 m
 * }
 * -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)
 * {|class="wikitable sortable"
 * {|class="wikitable sortable"

!m!!ft
 * 3000 m+
 * }
 * 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)
 * 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 acre
 * maybe add a new option   ?
 * GSMC(Chief Mike) Kouklis U.S.NAVY Ret. ⛮🇺🇸 / 🇵🇭🌴⍨talk 12:21, 26 July 2021 (UTC)

This relates to Dixie Fire. You could use the following.

or

Johnuniq (talk) 07:22, 27 July 2021 (UTC)
 * Thanx 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 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 above. That shows unitcode   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 110 crore tonnes → 110 crt 110 crt instead of (110,000,000 t) 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:
 * → 1.1 e9tonne
 * 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 &#x1f4ac; 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.

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&amp;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  as an input (  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 •  → 493 shton
 * Liberty Bell (Portland, Oregon) •  → 1 shton
 * 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  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  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   is used in a source, then what the source must mean is 'shton'.  If the editor uses   = '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)
 * 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 mph would yield 15,345 mph (24,695 km/h; Mach 20) Crnorizec (talk) 19:46, 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)
 * OK, it does now... Crnorizec (talk) 19:49, 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.
 * → 20 Mach
 * → 20 Mach
 * → 20 Mach
 * → 20 Mach
 * 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: I'll slowly see what would be involved in the module. Johnuniq (talk) 01:33, 12 October 2021 (UTC)
 * Creating a new parameter  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 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 -> Comparison_US_standard_atmosphere_1962.svg -DePiep (talk) 20:51, 14 October 2021 (UTC)

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 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 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 is to help articles, not to reproduce physical calculations. Since sources commonly use "@alt" as a specifier, it is perfectly allright the  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)
 * 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)
 * 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 1 is not a good plan. -DePiep (talk) 06:41, 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 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 Mg
 * 1 Mg
 * What is your question? -DePiep (talk) 23:35, 16 October 2021 (UTC)
 * This? 10000000 lb or this 100 lt? Then why not specify the output thus 10000000 lb or thus 100 lt? 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)
 * 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  (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 can't handle cases when WD has multiple values for this field. I really don't see how this has anything to do with. 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 for the background. <b style="color:#034503">MB</b> 20:37, 25 October 2021 (UTC)
 * Convert has limited syntax for retrieving values from Wikidata, see Template:Convert. If you edit any section at Mendez, Cavite and replace its contents with, 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). <b style="color:#034503">MB</b> 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 The result from  is the output from the following (this uses fixed wikitext to show what happens now): Infobox settlement then does its own calculation and tries to use  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)
 * elevation_m =


 * 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, : 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 pointed this way. Maybe the best we can do on this end is have  detect multiple values in the field, not display anything, and put the article in Category:Articles using infobox settlement with invalid elevation data. <b style="color:#034503">MB</b> 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 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 rack-mounted server". produces "This is a  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 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 is not implemented and the output is simulated wikitext. Johnuniq (talk) 00:22, 7 November 2021 (UTC)
 * → 12 to 18 kg
 * → 12 and 18 kg
 * → 12 or
 * → 12 to(-)
 * → 12 and(-)
 * → 12 or 18 kilograms (26–40 lb)

Helper function: accept basic value input
We need a Helper function that can read & feed regular source-&-keyboard value inputs for.

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 1.74m and 5ft6 in?

Many & most input for is basic the quantity value: number &times; 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 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?:


 *  2 m2/W =  2 m2/W

I was thinking it should give something like:


 *  2 m2/W =  2 m2/W (0.5 W/m2)

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:


 *  2 W/m2 =  2 W/m2 (5 ft2/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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 04:01, 26 November 2021 (UTC)
 * Or even tonnes. --John Maynard Friedman (talk) 21:55, 26 November 2021 (UTC)
 * My point exactly. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 01:18, 27 November 2021 (UTC)

Weird behaviour when target unit is specified as 1
Consider 0.1 km2 (0.1 km2) and 0.1 km2 (0.1 km2). 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 0.1 km2 (0.1 km2) and 0.1 km2 (0.1 km2). 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). <b style="color:green">Tarl N.</b> ( 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. The actual defaults are listed at Module:Convert/documentation/conversion data. <b style="color:#034503">MB</b> 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 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 01:26, 27 November 2021 (UTC)
 * Agreed. See https://en.wikipedia.org/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 sqmi, of which 943 sqmi are land and 0.3 sqmi (0.03%) is covered by water."

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 sqmi, of which 943 sqmi are land and 0.3 sqmi (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 sqmi, of which 943 sqmi are land and 0.3 sqmi (0.03%) is covered by water."
 * which shows convert is correct.<b style="color:#034503">MB</b> 05:14, 8 December 2021 (UTC)


 * This example really goes straight to the heart of the overprecision problems so rampant on the project. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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  like so:
 * ---> 944 sqmi, of which 943 sqmi
 * 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)
 * 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 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? <b style="color:red;">E</b><b style="color:blue;">Eng</b> 14:01, 8 December 2021 (UTC)
 * Apart from anything possibly helpful, this reply is a personal attack and sign of harassment. 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) and whining that you're being harassed? <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 03:12, 9 December 2021 (UTC)
 * to recap: at 11:35 I asked a question  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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 15:58, 9 December 2021 (UTC)
 * I knew frogs had coffins. But bluebottles too? Who knew! Martinevans123 (talk) 16:09, 9 December 2021 (UTC)

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:, which produces this: "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:
 * → 250 PS
 * → 250. PS
 * The second example uses the trick that  (with a dot) tells convert that the zero is a significant digit. The same effect could be achieved with  . 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:  -> 250. PS 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.
 * → 249.5 PS
 * 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  → 246 hp. But sometimes it is better to use the actual PS value instead of the rounded marketing value:   → 246 hp. 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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 undefined undefined, 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)
 * 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)
 * 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. Akeosnhaoe (talk) 23:59, 13 December 2021 (UTC)


 * You can specify linking only the output units in these ways:


 * 276 bhp
 * 276 bhp
 * 276 bhp
 * 276 bhp, 276 bhp
 * 276 bhp (276 bhp, 276 bhp) <b style="color:#034503">MB</b> 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:


 * 100 acre &rarr; 100 acre

but


 * 100 acre &rarr; 100 acre

I'm curious, is this behaviour intentional? Archon 2488 (talk) 09:59, 23 December 2021 (UTC)
 * To make the demo complete, this is with on:


 * 100 acre &rarr; 100 acre


 * 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. 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:
 * Template talk:Convert/Archive September 2015
 * Template talk:Convert/Archive October 2019
 * Template talk:Convert/Archive 2
 * 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 (R50), and I wanted to display it in arc minutes. (I.e. for NGC 5822: " 0.368 degrees " -> 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  and "annum" is used in that context. Annum is a redirect to year. The following links to annum where it might just be year:
 * → 1 year
 * 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)

The infobox at Earth uses the following:
 * 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 20:05, 8 January 2022 (UTC)

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:
 * 1 long ton => 1 long ton Should be 2240 lb.
 * 1 lcwt => 1 lcwt Should be 112 lb.
 * 40 lcwt =>  40 lcwt Should be 2240 lb.
 * 8 stone => 8 stone Should be 112 lb.

But these are correct
 * 1 stone => 1 stone (so 8 stone => 112 lb, so correct)
 * 112 lb => 112 lb 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)


 * 1 long ton => 1 long ton Should be 2240 lb.
 * 1 lcwt => 1 lcwt Should be 112 lb.
 * 40 lcwt =>  40 lcwt Should be 2240 lb. [??]
 * 8 stone => 8 stone Should be 112 lb.
 * 8 stone => 8 stone Should be 112 lb.


 * But these are correct
 * 1 stone => 1 stone (so 8 stone => 112 lb, so correct)
 * 112 lb => 112 lb Should be 1 lcwt exactly, 50.80 kg, so correct.
 * You can remove the rounding this way without adding precision: 1 long ton. <b style="color:#034503">MB</b> 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 1 long ton would have shown my error, so I couldn't have tested it. Sigh. --John Maynard Friedman (talk) 23:03, 17 January 2022 (UTC)
 * And an extra forty for false memory. Even 1 long ton 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 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 "inH2O". 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:


 * → 1.5 - 2 m

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:
 * → 1.5 to 2 m
 * 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. <b style="color:#034503">MB</b> 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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. <b style="color:#034503">MB</b> 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. <b style="color:#034503">MB</b> 03:30, 17 January 2022 (UTC)
 * Fixed <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 07:47, 17 January 2022 (UTC)

Hmm, I wonder what "Rackets with smaller and larger head sizes, 85 and 120 -, are still produced" at Racket (sports equipment) means. Should it have a spaced en dash? Johnuniq (talk) 08:51, 16 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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)
 * It should not, because the beginning of the range is a single number with no spaces. Parse it like this: (550) and (770–880 cm2). 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 sqin and larger heads of 120 - 137 sqin" 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: 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: Johnuniq (talk) 06:40, 17 January 2022 (UTC)
 * → 0.1 - 0.2 m
 * → 3 - 5 kg
 * → 0.1 - 0.2 m
 * → 3 - 5 kg

Spaced en dash test
I updated the sandbox to give a spaced en dash.

Current template (not spaced):
 * → 2 - 3 Mach
 * → 1.5 - 2 m
 * → 1346 - 1676 mm
 * → 81 - 89 kg

Sandbox (spaced): 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)
 * That's this example of the template being clever:
 * → 250000 L
 * The recommended unit is . Using   implies US spelling and sets  . Try this:
 * → 250000 L
 * 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
Apollo Lunar Module uses 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)
 * Moved from Template talk:Cvt. Johnuniq (talk) 02:05, 21 January 2022 (UTC)
 * The unit isp is Specific impulse and was discussed at Template talk:Convert/Archive January 2014 and is documented at Module:Convert/documentation/conversion data. 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  and   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. 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 &rarr; km/h mph (Mach to regular speed)
 * row H, for input  (multiple value output).
 * row-id, A-H
 * Note that old 20000 altitude input must be changed into 20000, in-article.


 * Extended example table. & 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 lb·ft

Ref: https://en.wikipedia.org/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  and  :
 * → 260 lb.ft
 * → 260 lbft
 * → 260 lb.ft
 * → 260 lbft
 * As seen above, using  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):

2 - 3 cm

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 or 2 - 3 cm <b style="color:#034503">MB</b> 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 2 - 3 cm → 2 - 3 cm isn't useful.  Stepho  talk 11:11, 4 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 2 - 3 cm → 2 - 3 cm 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.

Release notes for earlier versions are listed here. Johnuniq (talk) 22:52, 4 February 2022 (UTC)
 * 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:
 * → Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph)
 * → 0.1–0.2 metres (3.9 in – 7.9 in)
 * → 81–89 kilograms (12 st 11 lb – 14 st 0 lb)
 * Handling of the Mach unit has been enhanced (discussion here):
 * Parameters  and   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  and   have been corrected to Deadweight tonnage.
 * Links for various energy units have been changed to Kilowatt-hour due to Watt-hour being moved.
 * 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, 10,000) or in metres (for example, 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. 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. 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) 2 to(-) works as expected: 2 to(-). However, the near-identical 2 to(–) does not: 2 to(–) (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   should be changed to an en dash. Two others examples where only a hyphen is accepted are   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, and should become 1.57 /mi2 but instead is treated as 1 /mi2. –<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b> ( 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.:


 * 1.2 cm → 1.2 cm
 * 0.3 km → 0.3 km

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⁄2$. What seems vulgar to me is 0.3333333333333333333333333333333333333333333333333333333333333333333333. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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:

→ 1 $/acre

→ 1 $/acre

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:
 * → 1 $/acre
 * 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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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:
 * → 1 chain
 * → 1 foot
 * Johnuniq (talk) 23:07, 1 February 2022 (UTC)
 * Thanks for the info -- we may need it later. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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.
 * 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. [[file:Treble clef.svg|15px]]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 (and be sure to scroll through). <b style="color:red;">E</b><b style="color:blue;">Eng</b> 04:40, 21 February 2022 (UTC)

English language variations
I'm editing on Royce Clayton and wrote about how he trained by running 200 m 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. <b style="color:#034503">MB</b> 05:27, 21 February 2022 (UTC)
 * , 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. <b style="color:#034503">MB</b> 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 of the cities of  and ? The São Paulo area is stored in km2 at wikidata and Sundsvall in hectares, but shouldn't Convert fix that? I always want km2 - is that possible?

Tomastvivlaren (talk) 22:29, 28 February 2022 (UTC)
 * km2 undefined -> km2 undefined
 * km2 undefined -> km2 undefined
 * km2 undefined -> km2 undefined
 * km2 undefined -> km2 undefined


 * This seems to be a problem in the QID system not liking km2 for São Paulo:
 * →  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 gives the same problem as São Paulo, because it is stored in km2 at Wikidata:
 * km2 undefined -> km2 undefined
 * Perhaps the problem is in the otherwize so nice module:Convert/wikidata? Tomastvivlaren (talk) 23:38, 28 February 2022 (UTC)
 * →  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 gives the same problem as São Paulo, because it is stored in km2 at Wikidata:
 * km2 undefined -> km2 undefined
 * 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:


 * km2 undefined -> km2 undefined
 * km2 undefined -> km2 undefined
 * km2 undefined -> km2 undefined
 * km2 undefined -> km2 undefined
 * Will need Jonuniq to explain that. <b style="color:#034503">MB</b> 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  in Area WD so its unit reads. 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  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  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)
 * 30x10x20 cm
 * 30 x
 * 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 "×":
 * → 30 x
 * → 30 ×
 * → 30x10x20 cm
 * → 30×10×20 cm –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:

→ 2 kPa

→ 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  applies. I forget the details but studying the following would probably reveal the reasoning.
 * Template talk:Convert/Archive November 2012
 * Template talk:Convert/Archive December 2014
 * Template talk:Convert/Archive February 2018
 * Template talk:Convert/Archive June 2018
 * 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)
 * I put an experiment for a new unit called  at Module:Convert/extra. If less than 120 minutes, it defaults to minutes, otherwise hours. Examples:
 * → 5700 sec
 * → 7200 sec
 * 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,  would be removed and replaced with   which would be updated to use the new default. It's ok to use   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, 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. -- Red rose64 &#x1f339; (talk) 11:47, 5 April 2022 (UTC)
 * You add to the top of this page to show them. -- WOSlinker (talk) 12:42, 5 April 2022 (UTC)
 * -- Red rose64 &#x1f339; (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  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. <b style="color:#FFF8C0;background:#494"> Dr Greg </b> 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 . 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. -- <b style="color:#FFF8C0;background:#494"> Dr Greg </b> talk 17:24, 28 April 2022 (UTC)
 * FAQ #1 at the top of this page has the answer to your question, .  Imzadi 1979  →   17:06, 28 April 2022 (UTC)
 * 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. -- Red rose64 &#x1f339; (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  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 3, which specifies the precision of the input value: 510 ft. This is documented at Template:Convert.-- Red rose64 &#x1f339; (talk) 14:02, 30 April 2022 (UTC)
 * Correct. Either option works for 510.  affects significant digits from the decimal point (positive means more digits after decimal point, negative means spread zeroes from the decimal point).   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. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 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)