Q: When using {{convert}} why does the answer sometimes seem a bit off?
A: This template takes into account the precision of the supplied value and generally rounds the output to the same level of precision. If you need to change from the default output precision, see rounding.
Note: This can cause whole numbers that end in one or more zeroes to be converted less accurately than expected.
Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)?
Q: I've been using Convert for some time and am pretty comfortable with its basic features. Does it have other features which it would be worth my while to learn about?
Template:Convert is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.
There are a multitude of different kinds of cups, depending on which country the measurement is being made in, and even within a country. I'm not sure we want to mess with all that. Jc3s5h (talk) 17:09, 7 February 2025 (UTC)[reply]
The same is true for gallon and ton. We handle those in a way that causes the editor to realize the distinction and explicitly pick which one they need. I have found this very helpful when introducing the required metric conversions to articles based on US sources. -- Beland (talk) 20:38, 7 February 2025 (UTC)[reply]
Would you like to name them all? Just think of the joy of having 19 names for 12 unique sizes to choose from. Would you trust random editors to choose the right cup name? Remember that this is an international encyclopedia and we can't just say to use the US definition (or any other country's). Even within one country do you trust people to know the difference between an official modern cup, a traditional cup, a coffee cup and tea cup? Remember that we still editors confusing imperial/US gallons, metric/long/short tons and hp/PS. Stepho talk00:32, 8 February 2025 (UTC)[reply]
Well, according to MOS:CONVERSIONS we have to do metric conversions in most cases whether the module supports them or not. Without them, most people in the world won't be able to understand the volume being described or won't be able to use it in calculations. We need to either correctly resolve any uncertainty over which cup is being used, or express metric units in a way that indicates that uncertainty.
When there are multiple definitions of the same unit, using the template means that it's clear which definition is being used, and it's easy to verify from article context that this is correct. It also means there's no need to check that the math has been done correctly. If there is no template support, editors still have to pick a definition and do a metric conversion; it seems to me they are just less likely to do so correctly.
I agree with Johnuniq and Martin of Sheffield who said we only need to support conversion for the units that are actually used in articles. I assume Vitamin D is using the US legal definition of 240 mL. This is pretty close to the 237 mL US customary definition and the 250 mL "metric cup" used by several English-speaking countries. One idea would be to simply have the module reduce the number of significant digits in the metric output so a single "cup" or e.g. "cupApprox" value could cover all these, which are most or all use cases. Or just have "cupUS" to cover 237/240 (given it'll be hard to tell the difference between those from context) and "cup250" to cover other countries with a common definition.
It's possible that the coffee cup definitions are also used in articles somewhere, but I'm skeptical all 19 values are actually needed; the analysis by Ich indicates the others are rare or historical only. I will do a database scan and find out for sure. -- Beland (talk) 01:19, 8 February 2025 (UTC)[reply]
A problem is that adding a template to an article somehow looks like an official assurance that the numbers are correct. It may well be that your edit at Vitamin D which interpreted a cup as 240 mL is correct, but in general sources are silent on what kind of cup they are referring to. That is pretty reasonable because the values are very rough. In this case, the issue concerns 1⁄2 a cup of mushrooms which, IMHO, could mean anything from 150 to 300 mL as, unless they are talking about finely chopped mushrooms, there would be a lot of empty space in such a cup, and a lot of wriggle room in how carefully the mushrooms are packed, and how far they exceed the height of the cup. In a situation like this, it may be that 1 cup is the best that can be done. Johnuniq (talk) 04:21, 8 February 2025 (UTC)[reply]
OK, the database scan was very informative. To limit the number of results I had to sift though manually, I searched for "1 cup". There are hundreds of articles that use fractional or multiple cups. After eliminating hundreds of articles about sports and 2 Girls 1 Cup, I found 77 general articles that use "1 cup" as a unit of measure (see the collapsed list below).
One important lesson is that recipes in the US are often measured by volume, whereas the rest of the world generally uses weight, to avoid exactly the sort of accuracy problems that happen when measuring the volume of a pile of irregular objects (like "1 cup of mushrooms"). The template cannot do volume-to-weight conversion because that depends on the material. This accounts for about a third of the 77 articles.
Some articles do explicitly convert to mL, which means an adequate definition of "cup" was available from the source or context. Eyeballing the whole list, I think it would be safe to always assume that unless an explicit mL conversion is given (as happens in our coffee-related content), the cup being referenced is one of the three main choices identified above (237, 240, or 250 mL). Given the imprecision of food prep, treating 1 cup as a quarter-liter is probably fine, and displaying "~250 mL" seems to me a sensible default behavior for "cup". I'm also happy to only have three options like "cup237", "cup240", and "cup250" out of accuracy paranoia, and maybe tell editors in the documentation to specify a low number of significant digits if they are uncertain from context? We definitely do not need the module to support all 19 definitions.
Fractional cups are used, so we'd need to handle a half, quarter, and third of a cup with satisfactory uncertainty, but I couldn't find an instance of an eighth-cup in our content. A quarter cup is 59.1-62.5, so ~60 mL, and a third is ~80 mL. A sampling of articles that use fractions:
Thanks for the ping and the exhaustive research. Honestly, after my foray into the world of cups after my post above, my takeaway was that Convert probably shouldn't bother supporting it, unless some completionists want to stop using hardcoded values on the pages discussing measurement units. I've used the convention 1 cup ({{convert|240|ml|ml|disp=out}}) for tricky unsupported units, e.g. "teaspoons" on laudanum. Things like nutrition values are better executed as a calories/100 grams anyway (and it's possible to find authoritative sources that use grams to begin with, like this FDA table). Wikipedia doesn't have too many recipes in it – they're better in grams anyway – and as you mentioned, the volume/mass conversion should remain out-of-scope for convert templates.-Ich(talk)15:50, 8 February 2025 (UTC)[reply]
OK, as an alternative to integration here, I have created {{cups}}, {{tbspUS}}, and {{tspUS}}, and I'm working through the hundreds of unconverted instances of these units.. -- Beland (talk) 03:10, 6 March 2025 (UTC)[reply]
hello, I've just discovered a good deal of cigars (e.g. Cuban ones) are not metric: diameter is measured in sixty-fourths of an inch and length is in inches. is there a way to add the weird unit "sixty-fourths of an inch" to the template in order to convert directly the measures in Cohiba?-- Carnby (talk) 11:43, 9 March 2025 (UTC)[reply]
Yes, but cigar aficionados do not use the +⁄64 thing; for them a cigar is 5+1⁄8″ × 42. Perhaps a workaround would be to suppres both units, e.g. 5+1⁄8 × 42.-- Carnby (talk) 13:09, 9 March 2025 (UTC)[reply]
Not quite 100% sure I follow you. Does the 5+1⁄8 represent the length and 42 represents 42⁄64 inches diameter?
{{cvt|5+1/8|xx|42/64|in|mm|0}} → 5+1⁄8 × 42⁄64 in (130 × 17 mm)
A really complicated expression could be used to get the formatting better (ie, to drop the "/64") or we could use a custom template to get all the formatting right. Kind of marginal whether it is worth the effort for a single article.
Anybody know why these give slightly different abbreviated forms for the mile side? The first form displays "kWh/mi" but "kW⋅h/km" (notice the middot). {{cvt|1.7|kWh/mile|kWh/km}} -> 1.7 kWh/mi (1.1 kW⋅h/km) {{cvt|1.7|kW.h/mile|kWh/km}} -> 1.7 kW⋅h/mi (1.1 kW⋅h/km) Stepho talk03:36, 16 March 2025 (UTC)[reply]
I haven't checked this particular unit but the general rule is that unit codes that include a dot (period) display a middot. I guess that years ago someone decided that kWh should display like that (no middot) because that is how it is commonly written. Johnuniq (talk) 04:16, 16 March 2025 (UTC)[reply]
When I was small, I only encountered the term "kWh" on the electricity meter in our house. I had heard of "kilowatts" when my parents were buying domestic appliances like heaters and kettles, and the box would sometimes show "1 kW" etc. which I knew to be an abbreviation for kilowatt. So I assumed that kWh was an alternative abbreviation for the same unit, until I was a teenager and a science teacher was explaining units like volts, amps, watts and joules - pointing out that the joule includes a time component and that 3,600 kJ could also be expressed as 1 kWh and that therefore, electricity meters should all be reconfigured to read out in either kJ or MJ. Forty-some years on, that's only just happening. So it would have been useful to me waaay back if there had been some kind of multiplication symbol. But of course, SI doesn't use a multiplication symbol for combined unit abbreviations, since the few two-letter unit abbreviations (like Hz and Pa) are usually chosen to avoid ambiguity (except lm (lumen) which might be mistaken for litre·meter). --Redrose64 🌹 (talk) 09:08, 16 March 2025 (UTC)[reply]
Johnuniq: Ah yes, I had forgotten about the kWh middot wars from a few years ago.
Found that {{cvt|1.7|kWh/100miles|kWh/100km}} correctly formats as 1.7 kWh/100 miles (1.1 kWh/100 km) . Any chance of removing the middot for |kWh/km= in the next general cleanup? No rush of course. Stepho talk11:35, 16 March 2025 (UTC)[reply]
kW.h is a unit with symbol kW⋅h and link Kilowatt-hour.
-kW.h is an alias for kW.h with link Kilowatt hour (which is a redirect to the hyphenated name).
kWh/km is a per unit (==) defined as -kW.h/km.
I do not recall why -kW.h was defined with that link as an exception but it was several months before the module went live in December 2013. Therefore, it is likely that I was just making the module compatible with the old templates. It might be better to remove -kW.h which would involve changing the definitions for kWh/km and kWh/mi. To remove the middot, use kWh in the two definitions. Can you see anything else in that section that should be cleaned up? Johnuniq (talk) 05:37, 17 March 2025 (UTC)[reply]
It's more magic than it might appear. First, the conversion doc page gets updated. Then the script mentioned at the top of the doc page gets run (to do that, view the associated talk page). I can use its output to update the convert data module. I'm hoping you will examine that section (or more if you feel inclined) and think about how everything should work together. If you do edit it, please bear in mind that it is read by a script so don't adjust the wikitext other than to edit the unit definitions. If wanted, you can examine the output at Module talk:Convert/makeunits (it says to purge and you might need to do that but MediaWiki has sped up in recent times and often it is not needed). Alternatively, just confirm that what I wrote above about what needs to be changed is correct, and that nothing else needs to be done. I have a simpler way to update the doc file using a script I run locally. Johnuniq (talk) 03:44, 18 March 2025 (UTC)[reply]
Convert applies conversion factors, and occasionally offsets, to continuous values expressed in different units of measurement. No such conversions exist for the discrete AWG designations, a series of nominal sizes which are not units of measurement. NebY (talk) 12:03, 22 March 2025 (UTC)[reply]
Agree. Many current WP:RS about Indian dams and related subjects use this unit. See e.g. Google news. Using a different unit in our articles would be confusing for our editors and readers. It's a trivial change. The list of volume units already contains Mcuft, Pcuft, Gcuft, kcuft, Mft3 (since 2013). It also contains dozens of US-specific volume units. — Chrisahn (talk) 16:06, 23 March 2025 (UTC)[reply]
The discussion at WT:Manual of Style/Dates and numbers#Tmcft does not seem to conclude that Tmcft is useful. Per WP:CALC, it is ok to say that something is 12.3 Tmcft (12.3 billion cubic feet or 350 million cubic metres). It would be better to have a footnote indicating what Tmcft is, although a link to the article should do. After that, don't mention it. Instead, use e9cuft or billion cubic feet. Johnuniq (talk) 01:49, 24 March 2025 (UTC)[reply]
That discussion is far from concluded. :-) "After that, don't mention it" – That's not going to work. Tmcft is currently used in 118 articles, often multiple times. Example quote: "...permitted Goa to use 24 tmcft (excluding the 9.395 tmcft prevailing uses), Karnataka to use 5.4 tmcft (including 3.9 tmcft for export outside the basin) and Maharashtra to use 1.33 tmcft..." Tmcft is the unit in the sources for these articles. Using a different unit on Wikipedia wouldn't make sense. — Chrisahn (talk) 02:08, 24 March 2025 (UTC)[reply]
is there an error converting LT -> t for values over 199,000?
I must be doing something wrong, but I can't see what it is. Converting long tons to tonnes works fine up thru 199,000 but at 200,000 it just returns the input value unchanged (220,000 LT => 220,000 t). Herostratus (talk) 02:19, 27 March 2025 (UTC)[reply]
That is the default rounding. 220,000 has two significant figures and that is applied to the output. You could use something like one of the following although the first is probably wrong because it shows false precision.
{{convert|220,000|LT|t|0}} → 220,000 long tons (223,530 t)
{{convert|220,000|LT|t|sigfig=3}} → 220,000 long tons (224,000 t)
If I understand correctly, it is not large numbers that are affected vs small ones, but numbers starting with a 1 (or in this case a 2) vs numbers starting with an 8 or a 9. Can numbers starting with a 1 (or 2) be assigned one extra significant figure? Dondervogel 2 (talk) 07:16, 28 March 2025 (UTC)[reply]
Not quite, It's not the starting digit but how many zeroes are at the end.
218,000 has 3 significant digits and 3 rounded digits.
219,000 has 3 significant digits and 3 rounded digits.
220,000 has 2 significant digits and 4 rounded digits.
221,000 has 3 significant digits and 3 rounded digits.
...
899,000 has 3 significant digits and 3 rounded digits.
900,000 has 1 significant digit and 5 rounded digits.
901,000 has 3 significant digits and 3 rounded digits.
...
918,000 has 3 significant digits and 3 rounded digits.
919,000 has 3 significant digits and 3 rounded digits.
920,000 has 2 significant digits and 4 rounded digits.
921,000 has 3 significant digits and 3 rounded digits.
The default rounding of the output depends on how many zeroes it finds at the end of the input. This works good for generic large numbers in isolation (eg, Hoover Dam is 3,250,000 cu yd) but fails when listing through ranges like I just did. Use Johnuniq's solution to override the default. Stepho talk09:00, 28 March 2025 (UTC)[reply]
{{convert|0.2|sqmi|km2}} produces 0.2 square miles (0.52 km2). It makes little sense that 0.2 square miles should be converted to 0.52 km2. Even 0.5 km2 would be a higher precision than the input, so why increase the false precision even more? Player001eliminated (talk) 01:19, 1 April 2025 (UTC)[reply]
I don't see the problem. On the assumption the area is precisely 0.2 sq mi, the conversion is correct. If the area is rounded, your computer has no way of knowing this unless you specify that with {{convert|0.2|sqmi|km2|1}}, resulting in "0.2 square miles (0.5 km2)". Dondervogel 2 (talk) 05:35, 1 April 2025 (UTC)[reply]
But why would someone write 0.2 if the area was precisely 0.2? If the number had more precision, they should write 0.20 or 0.200 instead. In the real world, it is almost never assumed that data values have more precision than the number of decimal places. Player001eliminated (talk) 14:56, 1 April 2025 (UTC)[reply]
It occurs to me that neither the convert template nor typical technical writing has a standard way of communicating to the reader that a value is exact. Sometimes the reader has to figure this out from context, other times the publication invents a syntax and announces the syntax somewhere in the publication. Jc3s5h (talk) 16:36, 1 April 2025 (UTC)[reply]
By {{Convert}} default, the conversion result will be rounded either to precision comparable to that of the input value (the number of digits after the decimal point—or the negative of the number of non-significant zeroes before the point—is increased by one if the conversion is a multiplication by a number between 0.02 and 0.2, remains the same if the factor is between 0.2 and 2, is decreased by 1 if it is between 2 and 20, and so on) or to two significant digits, whichever is more precise. An exception to this is rounding temperatures (see below).
There's more below that and at Help:Convert#Rounding. Myself, I think it's a good general-purpose algorithm and defaulting to 1 sf could give very poor results. Convert's rounding can easily be adjusted if we're not satisfied (and as editors we're responsible for our tool use). NebY (talk) 18:04, 1 April 2025 (UTC)[reply]
It makes little sense to round it to 2 sig figs the input is 1 sig fig, when it's a decimal value. Especially with decimals, the last digit always gives the precision. Also rounding 0.9 mile to 1.4 km makes a bit of sense, because it's a similar relative level of precision, but increasing the precision by more than a factor of 10 (0.2 -> 0.52) makes no sense at all. Has there been any instance where this was useful? Player001eliminated (talk) 18:26, 1 April 2025 (UTC)[reply]
So there's a bit more sense to that; even though it does increase the precision spuriously, the alternative would be to decrease it. Perhaps we could modify this to NOT increase the sig figs if keeping them the same would already increase precision. Player001eliminated (talk) 18:47, 1 April 2025 (UTC)[reply]
Would you like {{convert|0.6|km2|sqmi}} -> 0.6 square kilometres (0.2 sq mi) and {{convert|0.2|sqmi|km2}} -> 0.2 square miles (0.5 km2)? NebY (talk) 21:51, 1 April 2025 (UTC)[reply]
Remember that the algorithm has to handle hundreds of different cases (many different scales and units). What seems obvious for 0.2 sqmi is not obvious for 2000 sqmi.
0.2 sq mi (0.52 km2)
2 sq mi (5.2 km2)
2,000 sq mi (5,200 km2)
You can see that rounding 2000 sqmi to 5000 km2 would not be right. The rounding algorithm chooses what works best in the majority of cases. If it doesn't work in your case then you override it. Stepho talk23:11, 1 April 2025 (UTC)[reply]
In some cases, rounding 2000 sqmi to 5000 km2 would be right. However, to avoid this, the function can be set to add an additional sig fig if the input is an integer, but not if the input is a decimal. I don't think increasing precision when the input is a decimal makes sense. One possibility is to also use the condition I described above: to NOT increase the sig figs if keeping them the same would ALREADY increase precision. Player001eliminated (talk) 23:18, 1 April 2025 (UTC)[reply]
But what about the case of converting sq inches to sq mm for computer chip dies. 0.02 sq in (13 mm2) In that case you do want to keep the precision. Which is why a generic algorithm cannot possibly cope with every situation. Which is why it makes a good estimate at rounding but allows for an override if the editor thinks the rounding isn't quite right. Stepho talk23:29, 1 April 2025 (UTC)[reply]
A case where a single sig fig input is actually meant to be exact is very rare. THAT CASE should be accomplished by using the rounding parameter. Most of the time, the input is just an estimate that is accurate to its decimal precision. Player001eliminated (talk) 23:40, 1 April 2025 (UTC)[reply]
@NebY: I do think that would be better than it is currently, but if someone this that 0.6 -> 0.2 is too imprecise, you could use the condition I described in my previous response to you: to NOT increase the sig figs if keeping them the same would ALREADY increase precision, but if keeping them the same would decrease precision (e.g. 0.6 -> 0.2) then set it to 2 sig figs. Player001eliminated (talk) 23:20, 1 April 2025 (UTC)[reply]
You think 0.6=0.5 and conversion factors lurching from 2.5 to 3 would be better than it is currently? Well, that's not something I could see as being good practice and I would expect it to cause far more objections than the current approach. NebY (talk) 08:00, 2 April 2025 (UTC)[reply]
@NebY If all you mean is 0.6 square kilometres (0.23 sq mi) -> 0.6 square kilometres (0.2 sq mi) and 0.2 square miles (0.52 km2) -> 0.2 square miles (0.5 km2)
then that doesn't mean 0.6 = 0.5... That's just how calculations work. There's no reason to go back and forth, you just go one direction. Also, in which way is it helpful to round 0.47 or 0.60 to 0.52? It goes completely against the idea of significant figures. Player001eliminated (talk) 16:26, 2 April 2025 (UTC)[reply]
Of course reversibilty and consistency matter, especially in a tool that supports a wide variety of editors and readers variously fluent in one or the other system of units or both, employing a similar variety of sources (including with |order=flip). The default behaviour of the tool strikes a suitable balance beyond the mere "idea of significant figures". NebY (talk) 13:02, 3 April 2025 (UTC)[reply]
Are you asking me? If so, no the order does not affect the precision. Rather, what I was saying is that I would put the second parameter first, and then use order=flip to make both numbers accurate when they otherwise would not be. Player001eliminated (talk) 23:49, 3 April 2025 (UTC)[reply]
I'm still not sure what you mean. Can you give a concrete example to explain what you mean? Stepho talk
It may be hard to find one. I just think that the fact that people use order=flip is not a reason that the calculations should be exactly the same when reversed. My original point still stands; taking a single digit input and increasing precision by more than 10-fold is not useful. Player001eliminated (talk) 00:03, 4 April 2025 (UTC)[reply]
Here's some examples of rounding single digit input using the algorithm's choice of rounding:
100 km (62 mi)
200 km (120 mi)
300 km (190 mi)
400 km (250 mi)
500 km (310 mi)
600 km (370 mi)
700 km (430 mi)
800 km (500 mi)
900 km (560 mi)
1,000 km (620 mi)
And here it is with your proposal of single digit input rounding to single digit output
_en_Ajax-speler_Piet_Keizer_met_de_cup_i,_Bestanddeelnr_925-6437.jpg?lang=en)
: Ah yes, I had forgotten about the kWh middot wars from a few years ago.