Template talk:Convert

Frequently asked questions

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)?

A: See Help:Convert units for an introduction and Module:Convert/documentation/conversion data for the complete list.

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?

A: Almost certainly. Start with Help:Convert.

For more, see the FAQ.

Template:Convert is permanently protected from editing as 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.

Archives

Archive 1

Archive 2

Archive 3

This page has archives. Topics inactive for 90 days are automatically archived by if there are more than 2.

Template:Convert

... in conception

... and in reality

Turn off linking for count word prefixes

Currently, when using count word prefixes (e.g., e6) and unit name linking (e.g., lk=on), it seems to link the count word as well (though only in the input unit):

{{convert|3|e9BOE|e9GJ|lk=on|abbr=off}} → 3 billion barrels of oil equivalent (18 billion gigajoules)

Is there a way to turn off this behaviour? Otherwise, it should just remove it entirely, as linking common words like "thousand", "million", and "billion" doesn't really make sense. If the count word is a part of the unit name, that's another matter, but that's not what the case is here. Tstcikhthys1 (talk) 06:15, 12 January 2026 (UTC)[reply]

The quick answer is no, there is no way to turn that linking off. Going back ten or so years, "billion" was regarded as more ambiguous than now. There were once claims that billion meant million million (billion has more on that) but I haven't seen that raised for a long time. Currently, billion is defined as requiring a link if lk=on (see Module:Convert/text#L-49 which shows that million is not linked, but billion is). The abbr option had a similar problem in that abbr=on with, for example, e9km used to abbreviate e9 (showing 10⁹) as well as showing a symbol for the unit. Now abbr=unit can be used to only abbreviate the units. I could look at also doing that for lk if the proposal gets a bit more support. Bear in mind that lk=in and lk=out are supported and they would continue to link number names, if used. Any thoughts? Johnuniq (talk) 08:31, 12 January 2026 (UTC)[reply]

It might not matter often, but there's still a case for linking for clarity when our meaning of billion might differ from a source's, or from common usage at the time and place of the statistic or whatever. For the UK, that might be sources from pre mid-1970s, roughly; for India perhaps later (we speculated about that when discussing whether "tmcft" had been invented to avoid ambiguity), and maybe for other English-speaking countries too. NebY (talk) 13:55, 13 January 2026 (UTC)[reply]

Ah I see. With the growing prevalence of the words billion and billionaire in news media and elsewhere, I don't really think there's much confusing about the short scale and the long scale these days, so it can safely be removed.

Regardless, I think it's strange that "billion" is being linked because it's not the unit itself, but a count word used in conjunction with a unit. Since the documentation says that the unit will be linked, this behaviour seems strange, which is why I brought it up.

If it is going to be there for clarity, I think it'd be better to have linking it as an option (rather than the converse). Moreover, the article on Billion has either meaning as the definition of the word, so if clarity was what's important, then the reader would be left equally confused after visiting the article since the template doesn't make it clear which meaning of billion is being used in the current invocation. Tstcikhthys1 (talk) 12:09, 19 January 2026 (UTC)[reply]

In convert, billion links to 1000000000 (number) although that is a redirect to 1,000,000,000 and the latter might be a better target. My comment linked to billion to make it clear that there is (or was) confusion about what it means. NebY's comment mentioned tmcft which is a unit from India for "thousand million cubic feet" to avoid ambiguity. Options are good sometimes but they introduce complexity. Johnuniq (talk) 23:32, 19 January 2026 (UTC)[reply]

I see. I think I still stand by my previous comment: in this day and age, people are becoming more and more familiar with larger and larger numbers (e.g., learning what the giga- and now even tera- prefixes mean), and I think people are firmly aware of what a billion means, so it should be removed.

It's good that the template links to the number article. Agreed that it would add complexity, but I'd say if the link isn't removed completely, the template should have it off by default, and have an option to turn on linking for count words, but then it will do it for all of them (including million, for example) so that it becomes a "feature" rather than the case-by-case basis situation that exists currently. Tstcikhthys1 (talk) 07:10, 20 January 2026 (UTC)[reply]

Americans and younger people might think of a billion as 1000 million but older people in the British Commonwealth were taught that it means a million million. I'm a 60-year old Australian and I intuitively think of it as a million million. I know that this is no longer the main stream definition but it is still my intuitive thought and I need to remind myself that the meaning has changed since my school days. Some other countries are still in the process of changing. It costs little to keep it and it is a good reminder for countries (and individuals) that haven't fully internalised the change yet. Stepho talk 10:04, 20 January 2026 (UTC)[reply]

And France (and I think Italy too?) has milliard for one thousand million (with billion for million million). So allow at least another 25 years, I suggest. 𝕁𝕄𝔽 (talk) 12:21, 20 January 2026 (UTC) Not just France, pretty much all European languages have a cognate of milliard. --𝕁𝕄𝔽 (talk) 12:28, 20 January 2026 (UTC)[reply]

Also Germany. During the hyperinflation in the Weimar Republic, banknotes and even postage stamps appeared with the value expressed as e.g. "500 Milliard Mark", etc. --Redrose64 🌹 (talk) 23:47, 20 January 2026 (UTC)[reply]

Gradients?

Is there a function in convert for gradients, e.g. 1-in-X = y degrees or z%? Anothersignalman (talk) 19:28, 13 January 2026 (UTC)[reply]

Sorry, no. Convert can do, for example, inches/feet to mm/m, but not a slope to an angle. Johnuniq (talk) 22:02, 13 January 2026 (UTC)[reply]

Well why the HELL not? It slices, it dices, it leaps tall buildings in a single bound -- so why can't it do grads? Why do civil engineers get left out in the cold? E Eng 04:19, 14 January 2026 (UTC) P.S. Seriously: does it handle degrees and radians?[reply]

You're right. Convert and I share many failings. Johnuniq (talk) 05:18, 14 January 2026 (UTC)[reply]

Civil engineers - aren't ;) Stepho talk 06:53, 14 January 2026 (UTC)[reply]

Is there a process for starting a discussion about adding the function? Anothersignalman (talk) 07:19, 14 January 2026 (UTC)[reply]

Here is a good start. First step is to link a couple of articles and identify what text in each would benefit from a conversion. There is no need to go into details: a big-picture concept would be good. Assuming there was a template doing what you wanted, what would the input be, and what output would it produce. What units might be used? For the input, all length units? Or just a few (what)? Johnuniq (talk) 07:53, 14 January 2026 (UTC)[reply]

Well, here's the project I'm working on that made me ask the question in the first place: Walhalla railway line. This 1927 diagram [1] shows the gradients of the railway line expressed as 1 in X, e.g. a slope marked "30" is 1 in 30. I don't know whether expression of those numbers in percentage or degrees would be useful; locally we almost always referred to grades as 1 in X, but that's not always true internationally. I know percentage gradients are common terminology in USA, and degrees (or radians?) would be good for anything discussing, say, a bridge span with a steep slope between the end abutments. (This diagram shows 21 bridges under the railway, as upward-pointing arrows, and two bridges over the railway with the symbol "T".) For inputs, I think a code chain of {{convert|30|x|%dr}} might work, where the user inputs any one value, x for 1 in X, % (or pc?) for percentage, d for degrees or r for radians, and it provides outputs for all other terms, in this case %, d, and r, but fewer if not all three are specified in the final convert term. There'd also need to be something for rounding, e.g. maximum 2 decimals on percentage. A more complicated version might want to account for swapping from downhill to uphill, e.g. downhill 1 in 30 changes to uphill 1 in 30, net difference 1 in 60. Anothersignalman (talk) 08:07, 14 January 2026 (UTC)[reply]

There will be a way to get all that in a template but it might be a new one dedicated to the task. Convert is massive and it would not be a good place to add code for a specific function (convert generally just multiplies an input value by a scale with formatted unit names). I suggest starting a discussion at WT:TRAINS. Keep it simple by starting from scratch without a preliminary about how you tried here. The question to raise is whether others think a gradient template of some kind would be helpful. Give your example but be a bit more specific—what text in the current article would be replaced (or enhanced) with a template, and what would the output be. If there is some support with a reasonably concrete plan, it will happen. Redrose64 has been active here and might help discuss some details at TRAINS. Johnuniq (talk) 08:25, 14 January 2026 (UTC)[reply]

Thanks for the advice. My use-case is for a railway so I'll shift over to there, but there are probably other, non-railway applications for this sort of code e.g. highways, walking/hiking tracks, cycling corridors etc., but also maybe for bridge discussions and maybe some generic engineering articles? Anothersignalman (talk) 08:31, 14 January 2026 (UTC)[reply]

Done, link here - Wikipedia talk:WikiProject Trains#Gradient template?. Anothersignalman (talk) 08:40, 14 January 2026 (UTC)[reply]

I'm about two days behind on my watchlist, so only just seen this. {{railway gradient|30}} → 1 in 30 (33.3 ‰). --Redrose64 🌹 (talk) 21:12, 15 January 2026 (UTC)[reply]

Crosspost response from the other thread - Is the per mille symbol standard in some other jurisdictions? I've only ever seen gradients expressed as 1 in x or percent e.g. 3.33%, not 33.3‰. Anothersignalman (talk) 16:30, 16 January 2026 (UTC)[reply]

It's not something I've come across either, but a quick google finds a few forum posts and similar sources stating that per mille is used on continental European railways and one implying that it's used in India. List of steepest gradients on adhesion railways uses 1 in x and % consistently, as does the only non-English Wikipedia to have an equivalent article (es:Anexo:Pendientes ferroviarias más pronunciadas) - but that was translated from the English article in 2019. Looking at the articles for a couple of the systems near the top of that list:

Pöstlingbergbahn (Germany) uses %, as does the source. de:Pöstlingbergbahn uses ‰ in the infobox and prose but there isn't an inline source in either place.
Gmunden Tramway uses % but it's German-language source [2] uses ‰ as does the German Wikipedia article (I couldn't immediately spot a figure in the other language editions).
de:Straßenbahn Mainz uses ‰, none of the other language editions (including English) seem to mention the gradient in the article.

Thryduulf (talk) 19:54, 16 January 2026 (UTC)[reply]

For the record, my response way back the the beginning of this thread was based on a misreading. I thought the OP was talking about gradians, when in fact he was talking about the grade grade (slope) (sometimes known to Brits as gradient -- not to be confused with gradient!) E Eng 18:57, 7 February 2026 (UTC)[reply]
Worth it for the laughs between you and the following two responses :) Anothersignalman (talk) 19:46, 7 February 2026 (UTC)[reply]

It's none of those, but actually Grade (slope). --Redrose64 🌹 (talk) 20:14, 7 February 2026 (UTC)[reply]

Additional unit requests

I'd like convert to be able to handle angles. Radians are a special case, so I want to be very clear that rads already exist in convert. I am assuming the module can't handle polymorphic overloading, i.e. we can't have two "rad" units that are distinguished by the to-unit, in this request. I will also make other assumptions about how the code works, but remember I am not fluent in how the module's guts work, so please check to make sure my input is valid.

Emphatic note: arc minutes and seconds have special symbols used which look like single and double quotation marks, but aren't. I pasted in the actual symbols rather than their html codes, but in html they're ′ and ″ - ′ and ″.

Assumptions I know are questionable:

Polymorphic overloading is not possible: we can't specify a second rad to be radians and have the angle unit and the radiation unit be distinguished by the to-unit.
There's no good way to handle SI prefixed units where some SI prefixes have their own article link, which is why I have radians set to use prefixes but then milliradians are listed separately, which will confusingly have "mradian" and "milliradian" link to different articles. I would love an expert to take a look at how to better handle this.
rev and cyc assume "target" commutes intelligently, so I can target a targeter and have it count as the targeted targeter, rather than copying over values such that changes don't propagate.
Scales have to be static values - many of these are relative to π, so I used the expr parser function to specify them. If scales can be dynamically calculated, you'll see the appropriate formulae in the expr calls.
This is a big one: the "subdivs" values in the module data are dictionaries whose keys are lists, so I think the current module data is written incorrectly, because there's only one reason for the keys to be lists: if the keys can hold multiple valid values. That is, I assume this part of the specification for the "mi" unit is incorrect, ["chain"] = { 80, default = "km" }, ["chainlk"] = { 80, default = "km" }, and instead should be ["chain", "chainlk"] = { 80, default = "km" }. If I am wrong, my subdivs need to be modified to duplicate text in the same way.
I copied the existing module data slavishly for the handling multiples, but it also seems to be buggy, because combination and multiple are both sets (unordered collections) seemingly used as if their orders have to match, which can't possibly be right. I obeyed the current data, but I am 99% certain this is broken behaviour and they should be lists or tuples, which are ordered.
- Example from ydftin, which I copied for °′″: combination= { "in", "ft", "yd" } and multiple = { 12, 3 } should not be be trusted to maintain those relative orders, even though those relative orders must be maintained for convert to work; I am 99% certain they ought to be combination= [ "in", "ft", "yd" ] and multiple = [ 12, 3 ], but rather than stick with this assumption as I did with subdivs, I stuck to the current, seemingly broken method.

List of units being requested:

Specific articles that could use this: anything discussing angles, but some low-hanging fruit are the articles linked above in the list of units, all of which have symbol legend tables showing the conversion values, which are currently hard-coded rather than calling convert.

["radian"] = { name1 = "radian", symbol = "rad", utype = "angle", scale = 1, prefixes=1, default = "radian", link = "radian", },
["milliradian"] = { name1 = "milliradian", symbol = "mrad", utype = "angle", scale = .001, default = "radian", link = "milliradian", },
["gradian"] = { name1 = "gradian", symbol = "grad", utype = "angle", scale = 0.015707963267949, default = "radian", link = "gradian", },
["tr"] = { name1 = "turn", symbol = "tr", utype = "angle", scale = 0.1591549430919, default = "radian", link = "turn (angle)", },
["r"] = { name1 = "revolution", symbol = "r", target = "tr" },
["rev"] = { target = "r", symbol = "rev", },
["c"] = { name1 = "cycle", symbol = "c", target = "tr", },
["cyc"] = { target = "c", symbol = "cyc", },
["°"] = { name1 = "degree", symbol = "°", utype = "angle", scale = 0.017453292519943, default = "radian", link = "degree (angle)", subdivs = { ["′","arcmin"] = { 60, default = "radian" } }, },
["deg"] = { target = "°" },
["′"] = { name1 = "arc minute", symbol = "′", utype = "angle", scale = 0.00029088820866572, default = "radian", link = "minute and second of arc", subdivs = { ["″","arcsec"] = { 60, default = "radian" } }, },
["arcmin"] = { target = "′" },
["″"] = { name1 = "arc second", symbol = "″", utype = "angle", scale = 4.8481368110954E-6, default = "radian", link = "minute and second of arc", },
["arcsec"] = { target = "″" },
["°′″"] = { combination= { "″", "′", "°" }, multiple = { 60, 60 }, utype = "angle", },
["°′"] = { combination= { "′", "°" }, multiple = { 60 }, utype = "angle", },
["degarcmin"] = { target = "°′", },
["degarcminarcsec"] = { target = ""°′″"", },

Quindraco (talk) 18:38, 17 January 2026 (UTC)[reply]

Yikes, that's a lot of text. Please don't think about code. Instead, clearly list any wanted units giving brief usage examples (wanted inputs and wanted outputs). Convert has existed for 19 of the 25 years of Wikipedia's existence (although the module has only been used for 12 years). Therefore it is very rare for there to be missing useful units. Angles have been discussed several times (see July 2024). Any thoughts from others? Johnuniq (talk) 04:49, 18 January 2026 (UTC)[reply]

I personally probably wouldn't have much use for this, but I wonder if some of the code would overlap / interface with the discussion a few days ago about railway gradients and slopes? Anothersignalman (talk) 10:57, 18 January 2026 (UTC)[reply]

Gradients, angles and slopes all seem to (my very unmathematically inclined mind) be very closely related and so seems sensible for them to be handled together. Either as part of {{convert}} or separately (cf. Wikipedia talk:WikiProject Trains#Gradient template?). That there have been at least 7 previous discussions about this over the years relating to multiple different contexts suggests that there is actually a strong usecase here. Thryduulf (talk) 11:41, 18 January 2026 (UTC)[reply]

I don't understand the compelling argument against including, at a minimum, all of the SI units, of which the radian is one.Quindraco (talk) 16:17, 19 January 2026 (UTC)[reply]

@Quindraco: Please tidy up this section and the one preceding it. With this edit you dropped a new section into the middle of the existing section; worse, you dropped it inside the existing <blockquote>...</blockquote> structure causing a foulup of the layout for both. --Redrose64 🌹 (talk) 07:08, 19 January 2026 (UTC)[reply]

Thank you, Redrose64 - I only wrote one section and had no idea Wikipedia decided to duplicate my request for no apparent reason. Pretty sure I've handled it now.Quindraco (talk) 16:14, 19 January 2026 (UTC)[reply]

There is no need to look at the July 2024 link I gave above but it shows several cases where people have suggested adding angles but when asked for details, they disappear. What text in what article would have what convert with what result? Is there more than one such article where a new unit would really be helpful (as opposed to displaying degrees in radians or vice versa because it could be done)? Johnuniq (talk) 23:41, 19 January 2026 (UTC)[reply]

I don't know about radians, but converting between percentages and 1 in x gradients would be useful on the majority of articles about funicular railways (over 100) just for starters. Thryduulf (talk) 00:02, 20 January 2026 (UTC)[reply]

OK, but details are needed for each unit: type, code, symbol, name, default, link. For example, see the length units. Don't edit anything—it's best to propose the details here for discussion. I guess type would be "Angle". A link to an article with some quoted text would also be nice to see how a convert would be used. Johnuniq (talk) 04:00, 20 January 2026 (UTC)[reply]

Suggestion

There should be an option to not display the first unit in adjectival form when using |adj=mid. For example, {{convert|123|kcal|kJ|adj=mid|(per biscuit)}} should produce: 123 kilocalories (per biscuit) (510 kJ), but now it produces: 123-kilocalorie (per biscuit) (510 kJ). --40bus (talk) 20:08, 20 January 2026 (UTC)[reply]

The point of |adj=pre is that it displays it in adjective form, ie with a hyphen.

How about {{convert|123|kcal|kJ|disp=x| (per biscuit) (|)}} -> 123 kilocalories (per biscuit) (510 kJ) Stepho talk 23:51, 20 January 2026 (UTC)[reply]

This illustrates the purpose of adj (adjectival for singular unit):

I ate a {{convert|123|kcal|kJ|adj=on}} cake. → I ate a 123-kilocalorie (510 kJ) cake.

Johnuniq (talk) 01:07, 21 January 2026 (UTC)[reply]

Super-feet

Is there a way to display the unit "board feet" as "super feet"? As far as I can tell they're the same thing, but the latter term is/was used to measure timber volume. I haven't seen the former in my research/references. Anothersignalman (talk) 18:01, 21 January 2026 (UTC)[reply]

Well the relevant article is Board foot, which mentions in passing that superfoot was used in AUNZ until the 1970s. Pipe? 𝕁𝕄𝔽 (talk) 18:23, 21 January 2026 (UTC)[reply]

No, convert has no "super" in its units. Johnuniq (talk) 01:39, 22 January 2026 (UTC)[reply]

Furlong symbol

Description of suggested change: Currently with this template, there is no abbreviation designated for furlong. Especially in horseracing where furlongs are still widely used in reports and race results, it is common to shorten this to either fur or f (this is just one area for an example, I'm sure such an abbreviation wouldn't be objectionable in other areas!). As such, I think it would be useful to add this to the table.

Diff:

RandomEditsForWhenIRemember (talk) 20:01, 23 January 2026 (UTC)[reply]

I removed the edit request and gave this section a heading to make it easier to find in the future. This page works by starting with a discussion. If consensus, units will be changed. Where would fur be useful as an abbreviation (link to article and section please)? It's likely that whoever uses this unit (horse racing) finds fur understandable but it might not be so useful for a general audience in 2026. I hope others will comment once examples are shown. Johnuniq (talk) 22:32, 23 January 2026 (UTC)[reply]

Most horse race reports that I come across use "f", as for example the 2:05 at Doncaster today - shown as 2m7f214y (2 miles, 7 furlongs, 214 yards) - this comes out as six yards short of three miles. --Redrose64 🌹 (talk) 15:48, 24 January 2026 (UTC)[reply]

Thanks for the edit Johnuiq, I wasn't aware there was a difference when it came to making requests on this page.

Furlongs these days mostly get used for horseracing, so it'd be mainly used for articles related to various tracks. Redrose64 gives a perfect example above; a lot of races run over x miles and furlongs rather than x metres for historical reasons. As such any race or track of that kind with a wikipedia page would benefit from this, especially when using it to convert distances from one measurement to another. For some examples:

St Leger Stakes - Infobox already manually uses f for furlong.

Japan Cup - A rare race measured in metres, so being able to use Convert on the page to show the equivalent is handy throughout the page is useful and having an abbreviation for furlong would match the abbreviated style for miles used (see opening lede and race course details). Tennō Shō is another race that is metre based, so an abbreviation for furlongs would be useful for the convert uses.

Ayr_Racecourse - See the Notable races table, which already manually uses "mi" and "f" for distances

Spectacular Bid - Most horse bios could use it, but for a specific example, it would be useful to have an abbreviated use of furlong in parts like "1980: four-year-old season" where the writing suddenly switches to using a different measurement for distance e.g. "covering the 1+1⁄4 mi (2.0 km) in 2:02.4."

"f" is probably a safer pick than fur to be honest, I think looking at more recent sources it seems to be more common in race reports these days than fur. RandomEditsForWhenIRemember (talk) 17:04, 24 January 2026 (UTC)[reply]

Speaking of house bios, does WP:BLP (biography of living Phillies) apply in such cases? E Eng 17:12, 24 January 2026 (UTC)[reply]

2025 Belmont Stakes has "Distance {{convert|1+1/4|mi|furlong m|0|abbr=on}}" in the infobox which displays as "Distance 1+1⁄4 mi (10 furlongs; 2,012 m)". The proposal is to change "10 furlongs" to "10 f". Any opinions on that? Johnuniq (talk) 06:25, 25 January 2026 (UTC)[reply]

Makes sense to me since miles and metres are already shortened - this also goes for the ~40 Belmont Stakes with articles. RandomEditsForWhenIRemember (talk) 20:42, 27 January 2026 (UTC)[reply]

Astronomical system of units

Astronomical units

There are some units in common use in astronomy publications which would be useful to have implemented in this module (in addition to the parsecs, light-years, AUs, which are already added as units of length).

Papers on stars and exoplanets typically express radii and masses of stars and planets compared to Sun, Jupiter, or the Earth. The standard values of those parameters are defined in the IAU 2015 Resolution B3. As those are nominal values (like the AU), they are not supposed to change in the future with more precise measurements. For Jupiter and Earth, both polar and equatorial radius are defined, by convention the equatorial radius is assumed if not explicitly specified. The masses are defined as values of the product GM, thus the conversion depends on the uncertainty of the gravitational constant, the resolution itself suggests using the 2014 CODATA value of 6.67408(31)×10⁻¹¹ m³⋅kg^-1⋅s^-2. Current best value is 6.67430(15)×10⁻¹¹ m³⋅kg⁻¹⋅s⁻²‍^[1]. I'm not sure what's the best choice here, I'll leave that to implementation. The following conversion factors would be needed:

Length
system	unit	code	symbol or abbrev.	notes	conversion factor	combinations
Astronomical system of units	Solar radius	R_Solar	R_☉		6.957×10⁸ m
	Jupiter radius	R_Jupiter	R_J	= equatorial R_J_e	7.1492×10⁷ m	R_J R_🜨
	polar Jupiter radius		R_J_p		6.6854×10⁷ m
	Earth radius	R_Earth	R_🜨	= equatorial R_🜨_e	6.3781×10⁶ m	R_🜨 R_J
	polar Earth radius		R_🜨_p		6.3568×10⁶ m

Mass
system	unit	code	symbol or abbrev.	notes	conversion factor	combinations
Astronomical system of units	Solar mass	M_Solar	M_☉		1.3271244×10²⁰ m³⋅s^-2/ $G$
	Jupiter mass	M_Jupiter	M_J		1.2668653×10¹⁷ m³⋅s^-2/ $G$	M_J M_🜨
	Earth mass	M_Earth	M_🜨		3.986004×10¹⁴ m³⋅s^-2/ $G$	M_🜨 M_J

The resolution suggest also that the corresponding nominal volumes can be used, according to the ellipsoid volume formula V = 4πR_e²R_p/3. From further derived units I've also seen Earth and Solar density used as units in some papers, not sure about Jupiter.

Lunar mass M_☾ and Lunar radius R_☾ may also be sometimes used, but to my knowledge they don't have an IAU-approved standard value, so let's leave them out for now.

In addition the resolution also defines the nominal effective temperature and luminosity for the Sun, and the nominal total solar irradiance (that is, at Earth). Those can be considered as units of temperature, power, and power per unit area (I'm not sure if we support the last unit group?) Those are not as important for the module, I don't see much use converting between them and SI-units, but listing nonetheless:

system	unit	code	symbol or abbrev.	notes	conversion factor
Astronomical system of units	Luminosity (=Power)
	Solar luminosity	L_Solar	L_☉		3.828×10²⁶ W
	Temperature
	Solar temperature	T_Solar	T_☉		5772 K
	Irradiance (= Surface power density)
	Total solar irradiance	S_Solar	S_☉	= insolation	1361 W⋅m^-2

Most of those units (radii except polar, masses, and luminosity) are also already integrated into Module:Val.

The astronomical system of units also contains the day and the Julian year as units of time, and the standard gravity. All of those are already included.

Astronomical implementation

I want to use this subsection to focus on what convert has to do. Please keep responses here minimal because I can't find pertinent stuff in the above. You gave List of exoplanets discovered in 2026 as an example of where convert would be used. That article points to other articles with similar formatting. Which columns in the table would use convert? Anywhere else outside the table? I need a collection of samples which represent all different usages that may occur. I'm hoping you can briefly describe what's wanted rather than give formatted examples: what input units need to be converted to what output units, and is there an example in that table? I understand that rounding and optional +/− uncertainties are needed and I don't need examples of that. In convert, each unit has to have a type such as mass. Each unit of a given type can be converted to any other unit of that type, but no others (with some weird exceptions). Can your proposed units have these types: mass • length • power • temperature • power per unit area? I will need to think about how numbers would be formatted with gaps in the way that val does (different from convert). Re uncertainties, optional +/− for super/sub-scripts are needed. I'm hoping none of the other tricks at Template:Val are needed, such as output 11(22). Johnuniq (talk) 01:43, 8 February 2026 (UTC)[reply]

Ok.

In List of exoplanets discovered in 2026 (& other tables for other years), the columns which would need to use convert are Mass (M_🜨 to M_J) and Radius (R_🜨 to R_J), as well as Period (years to days – no new units, but also need the same +/- formatting). Similarly, in List of brown dwarfs, the relevant columns are Mass (M_☉ to M_J), Radius (R_☉ to R_J), and Orbital period (years to days). In List of nearest exoplanets, Mass (M_J to M_🜨) and Radius (R_J to R_🜨) – same thing in the opposite direction. Those tables require numeric conversion which does not break sorting (Template:Val I noticed can't be used together with bare numerical values, because its call of {{ntsh}} sortkey breaks the sort) and +/- to match source values.
Articles about planets and moons would benefit from automatic conversion in the Physical characteristics fields of Template:Infobox planet: Radius (km to R_🜨), Mass (kg to M_🜨). See example Mars. The unit conversion is already done using Template:Convert in other fields, such as: Aphelion / Perihelion / Semi-major axis (km to AU), Orbital period (d to yr), Surface gravity (m/s² to g₀).
- Actually, looking at the example, the Surface area and Volume would also benefit from conversions to Earth-equivalent units of area and volume. That would also require definition of units of A_🜨 and V_🜨 according to the IAU prescribed equatorial and polar radii and formulae for spheroids.
  - I even remember now a case where I already needed a conversion from Earth density ρ_🜨 to g/cm³. The source paper for the TOI-421 system reported densities in Earth-equivalents, which I recalculated myself for the article. Automatic conversion would have allowed me to input the reported values & get the conversion done by template.
Some exoplanet articles – e.g. TRAPPIST-1e – could use conversion in the opposite direction (R_🜨 to km and M_🜨 to kg). Both in the infobox and in-text.
I notice there's also some cases where M_☾ and R_☾ would be needed, e.g. Pluto's infobox also lists mass in units of Moon, and Enceladus' infobox lists radius in units of Moon. The IAU doesn't define their nominal values, but gives the best known value of M_☾ in terms of M_🜨, as 1.23000371×10⁻² M_🜨 [3], so I guess this conversion should be used. For R_☾, I'm not sure, eclipse prediction apparently uses a value defined by IAU in 1982 in terms of R_🜨, as 0.2725076 R_🜨[4]. On other hand the values listed on Moon for the equatorial and polar radius (1738.1 km and 1736.0 km) seem to be widely used by informal convention. If I had to choose, I vote for the IAU 1982 value.
The Van Allen radiation belt article calls for in-text conversion between R_🜨 and both km and mi at once, currently inputted manually. The Magnetosphere of Jupiter article would also benefit from the same conversion from R_J to both km and mi at once (currently the values are written only in terms of R_J).
For conversions involving L_☉, I can't find many examples in existing articles. There's some cases where conversion from erg/s to L_☉ is invoked, such as M51-ULS-1 (see footnote [c]) or PSR J0952−0607 (see footnote [b]). In both cases, in-text.
I can't think of any examples where I would actually need to convert from T_☉, or S_☉ into SI-values. I guess this can be skipped.
I don't think the uncertainty-in-bracket formatting would ever be needed.

So, what I actually need is units of mass • length • power, perhaps also area • volume • density, for conversion between each other and to SI-units. The required units would be:

M_J, M_🜨, M_☾
R_J, R_🜨, R_☾
L_☉
A_🜨
V_🜨
ρ_🜨

(I don't see much utility in also defining area, volume, density for Sun, Jupiter, and the Moon). And formatting for +/- could be done by calling Template:sup sub? Slovborg (talk) 01:09, 10 February 2026 (UTC)[reply]

I'll take a few days to think about this. Johnuniq (talk) 10:03, 10 February 2026 (UTC)[reply]

I have one point to add. While writing the page for LHS 1903 I noticed that the discovery paper not only lists the planets' densities in ρ_🜨, but also the star's density in ρ_☉: "stellar density (𝜌★) = 3.44±0.35 Solar density (𝜌⊙) (4850±490 kilogram per cubic metre (kg m−3 ))"[5] Perhaps I underestimated the utility of Solar density as a unit. Slovborg (talk) 12:38, 13 February 2026 (UTC)[reply]

I noticed that List of largest exoplanets also extensively uses conversion between units of Jupiter to units of Sun, together with asymmetric uncertainties. Slovborg (talk) 09:16, 20 February 2026 (UTC)[reply]

Sorry, I haven't had time to look yet. Johnuniq (talk) 09:46, 20 February 2026 (UTC)[reply]

No problem. Fyi I'm also thinking of setting up the templates for ρ_🜨 and ρ_☉. Likewise S_☉ could be standardized, but there's currently great variety in how it's written, both here and in the literature (S_🜨 e.g. on TOI-715, I_🜨 e.g. on HD 137010, F_🜨 e.g. on List of Kepler exoplanet candidates in the habitable zone), there's no Wikipedia MoS on it. Also Mamajek et al. proposed recently to call it "solirad" & use the unit symbol of So (there's more relevant discussion in that paper). Also {{So}} which would be the most convenient is already taken. I need to figure out what would be the best way to proceed. Slovborg (talk) 11:07, 20 February 2026 (UTC)[reply]

Astronomical syntax

I'm pondering new syntax. Would something like the following work?

{{cvt|999~111|m}} → 999±111 [units and conversion go here]
{{cvt|999~111~222|m}} → 999+111
−222 [units and conversion go here]

That is, if two values are given use plus/minus, or if three values are given use + and − uncertainty values. I'm wondering if there can ever be a case where two values should be interpreted as + uncertainty and not-specified − uncertainty like 999⁺¹¹¹. Johnuniq (talk) 07:55, 21 February 2026 (UTC)[reply]

Possibly:

{{cvt|999|delta=111|m}} → 999±111 [units and conversion go here]
{{cvt|999|pos=111|neg=222|m}} → 999+111
−222 [units and conversion go here] Stepho talk 10:07, 21 February 2026 (UTC)[reply]

Good, but I was hoping to the use the existing code that handles ranges. Perhaps there would be a simple trick to have the module transform new parameters (delta, pos, neg) into a range. I'll think about that. Johnuniq (talk) 10:29, 21 February 2026 (UTC)[reply]

This should work. Strictly one-sided uncertainties are possible from systematic biases e.g. sin i degeneracy, or when the measured value is 0 or 100% and uncertainty is the upper/lower bound. But those are afaik never expressed like this. Slovborg (talk) 11:51, 21 February 2026 (UTC)[reply]

Astronomical sandbox

I have implemented the unintuitive syntax above. It has the advantage of being easy to enter and only requiring minimal changes to the complex modules. Please try how it works. I suspect it will give strange results with some of convert's weird options but any bad results should be fixed.

Slovborg proposed unit codes like M_Solar. Convert does some preprocessing to match how MediaWiki works in some situations. That involves replacing underscores with a space. Accordingly, I have used a hyphen dash. Please examine what I did in Module:Convert/documentation/conversion data. An easy way to see the new units is to search that page for -Solar. The conversion factors cannot be precise (mass of the Sun in kilograms!) but please report any problems.

Examples:

{{cvt/sandbox|10|M-Solar}} → 10 M_☉ (2.0×10³¹ kg)
{{cvt/sandbox|10~2|M-Solar}} → 10±2 M_☉ (1.99×10³¹±4.0×10³⁰ kg)
{{cvt/sandbox|10~2~3|M-Solar}} → 10+2
−3 M_☉ (1.99×10³¹+4.0×10³⁰
−6.0×10³⁰ kg)
{{cvt/sandbox|999~111~222|M-Solar|M-Jupiter}} → 999+111
−222 M_☉ (1,047,000+116,000
−233,000 M_J)
{{cvt/sandbox|999~111~222|M-Jupiter|M-Earth}} → 999+111
−222 M_J (318,000+35,000
−71,000 M_🜨)
{{cvt/sandbox|999~111~222|M-Earth|M-Lunar}} → 999+111
−222 M_🜨 (81,200+9,000
−18,000 M_☾)
{{cvt/sandbox|999~111~222|R-Solar|R-Jupiter}} → 999+111
−222 R_☉ (9,720+1,080
−2,160 R_J)
{{cvt/sandbox|999~111~222|R-Jupiter|R-Earth}} → 999+111
−222 R_J (11,200+1,240
−2,490 R_🜨)
{{cvt/sandbox|999~111~222|R-Earth|R-Lunar}} → 999+111
−222 R_🜨 (3,670+410
−810 R_☾)
{{cvt/sandbox|999~111~222|L-Solar}} → 999+111
−222 L_☉ (3.82×10²⁹+4.2×10²⁸
−8.5×10²⁸ W)
{{cvt/sandbox|999~111~222|M-Solar|M-Jupiter M-Earth M-Lunar}} → 999+111
−222 M_☉ (1,047,000+116,000
−233,000 M_J; 333,000,000+37,000,000
−74,000,000 M_🜨; 2.70×10¹⁰+3.0×10⁹
−6.0×10⁹ M_☾)
{{cvt/sandbox|999~111|year|day}} → 999±111 a (365,000±41,000 d)
{{cvt/sandbox|999~111~222|year|day}} → 999+111
−222 a (365,000+41,000
−81,000 d)

Here are some funky examples which are entertaining even if not particularly helpful. Units that don't support uncertainties, such as feet and inches, ignore it.

{{convert/sandbox|10+1/2~3/4|ft|in}} → 10+1⁄2±3⁄4 feet (126.0±9.0 in)
{{convert/sandbox|10+1/2~3/4~2/3|ft|in}} → 10+1⁄2+3⁄4
−2⁄3 feet (126.0+9.0
−8.0 in)
{{convert/sandbox|10+1/2~3/4|ft|in}} → 10+1⁄2±3⁄4 feet (126.0±9.0 in)
{{convert/sandbox|138~12|in|ftin}} → 138±12 inches (11 ft 6 in)

Parameter test=clean can be used to simplify the output wikitext when testing.

{{convert/sandbox|138~12|in|ft}} → 138±12 inches (11.5±1.0 ft)
{{convert/sandbox|138~12|in|ft|test=clean}} → <~138><±12> inches (<~11.5><±1.0> ft)
{{convert/sandbox|138~12~3|in|ft|test=clean}} → <~138><+12><-3> inches (<~11.50><+1.00><-0.25> ft)

Some of the examples show commas as thousand separators. I haven't tried the gaps option yet...

Module:Convert • Module:Convert/sandbox • different (diff)
Module:Convert/data • Module:Convert/data/sandbox • different (diff)
Module:Convert/text • Module:Convert/text/sandbox • different (diff)

Johnuniq (talk) 04:29, 2 March 2026 (UTC)[reply]

And what about this (lol):

{{convert/sandbox|10~2~3|ft|in|spell=on}} → ten+two
−three feet (one hundred and twenty+twenty-four
−thirty-six inches)

Johnuniq (talk) 09:46, 2 March 2026 (UTC)[reply]

Nice! I think this got us covered. Two things I notice:

Re: unit codes: the proposed e.g. M_Solar I intended to match the codes used by {{val}} but I'm wondering if we can do even shorter – in the meanwhile I also created template shortcuts e.g. {{MSun}}, {{MJup}}; {{M+}} was in place for Earth earlier already – do you think those would be even better? (Or is the + for Earth going to be a problem here?) I just don't have a good idea how to abbreviate the Moon / Lunar...
One issue I see are the exponents in errors; normally the exponent would be grouped with the unit, e.g. 10±2 M_☉ (1.99×10³¹±4.0×10³⁰ kg) should normally be ((1.99±0.40)×10³¹ kg) but I can see why this is a technical issue. Not sure if it is that important...

I'll check it out how this behaves in the various examples I found around Wikipedia. Slovborg (talk) 21:24, 2 March 2026 (UTC)[reply]

I have been distracted with an irritating problem in the convert test cases which I have been wanting to fix for a long time. I'll get back to the above in due course. The units I added for testing are M-Earth + M-Jupiter + M-Lunar + M-Solar and R-Earth + R-Lunar + R-Jupiter + R-Solar and L-Solar. I don't really mind what codes are used but these names follow a consistent pattern and are understandable for non-specialists who wonder what's going on in the wikitext. A minor advantage is that can search for, say, "M-" to find all such units. Johnuniq (talk) 05:32, 4 March 2026 (UTC)[reply]

Ok. I've been kinda busy irl myself, so I haven't managed to check out any special cases yet. Good point about the searchability. Consistency across different templates is not really that important. Slovborg (talk) 09:41, 5 March 2026 (UTC)[reply]

abbreviations and first-instances

MOS:ACRO1STUSE says,

Unless specified in the "Exceptions" section below, an acronym should be written out in full for the first time, followed by the abbreviation in parentheses, e.g. maximum transmission unit (MTU) if it is used again in the article. Common exceptions are post-nominal initials, because writing them out in full would cause clutter, or for something most commonly known by its acronym, in which case the expansion can be omitted (except in the lead of its own article) or be in parentheses—e.g. according to the CIA (Central Intelligence Agency).

Would it be possible to add a parameter to {{convert}} that adds the unit abbreviation in parentheses after it's spelled out?

For example, say we've an article that's going to use US car speeds many times. We want to use {{convert}} because otherwise SI readers won't have context for the speeds. However, when we use the template repeatedly, it spells out "miles per hour" every time (e.g. {{convert|180|mph}}). We could just use the |abbr= parameter… but we haven't yet defined the abbreviation IAW MOS:ACRO1STUSE.

180 miles per hour (mph; 290 km/h)

Currently, the only way to both use {{convert}} and include the abbreviation upon first use would be 180 miles per hour (mph; {{convert|180|mph|disp=out}}). That works, I suppose, but it's a bit clunky and would still need non-breaking spaces manually added that I didn't. This is also just one example; there're many other units which are handled by this template which are both wordier and far less common. Could some functionality be added to the template code that does something similar more automatically? — Fourthords | =Λ= | 12:31, 21 February 2026 (UTC)[reply]

Is this what is wanted?

{{convert|180|mph|adj=~}} → 180 miles per hour [mph] (290 km/h)
{{cvt|180|mph}} → 180 mph (290 km/h)

Johnuniq (talk) 00:56, 22 February 2026 (UTC)[reply]

Dammit. Please tell me you somehow just sneakily added that functionality w/o leaving an edit history, and that I didn't spend 20 minutes yesterday scouring the page just to miss it. ::sigh of shame:: Thank you very much for your help and patience, kind contributor. — Fourthords | =Λ= | 01:33, 22 February 2026 (UTC)[reply]

@Fourthords: I was just working on something which reminded me that, while adj=~ works and is fine, the preferred parameter is abbr=~ which does the same thing. The option adj=~ is available in case abbr is being used for something else.

{{convert|180|mph|abbr=~}} → 180 miles per hour [mph] (290 km/h)

Johnuniq (talk) 03:27, 22 February 2026 (UTC)[reply]

Template:Convert/doc#Default rounding

In this section are mentioned four types of rounding, and afterwards each of they has a section for itself. Obviously they should be subsections of #Default rounding, in which mentioned in general. And #Rounding temperatures goes afterwards of this four types, i.e. isn't already no subsection. I made [6] but my opponent don`t agree, and we had [7], then [8] with my detailed explanations, and then simply [9] without such. Therefore, I ask other participants to settle the dispute... I consider it important because a reader mistakenly considers #Rounding temperatures one of the types of rounding and doesn't understand why are mentioned four types while he/she sees six equivalent sections Unikalinho (talk) 10:32, 27 February 2026 (UTC)[reply]

No, those options are not the default and should not be described under that heading. (Also, Johnuniq is not your opponent; Wikipedia is a collaborative project.) NebY (talk) 13:14, 27 February 2026 (UTC)[reply]

Then maybe we need to add an additional section: "Four types of rounding", or "Types of rounding" or something like this, between #Default rounding and #Round to a given precision: use a precision number. And then make this four subsections of it, i.e #Round to a given precision: use a precision number, #Round to a given number of significant figures: |sigfig=, #Round to a multiple of 5: 15, 20, 25, ..., #Round to a multiple of a given fraction: 2+3⁄16 inch subsections of this new section--Unikalinho (talk) 13:52, 27 February 2026 (UTC)[reply]

In "Convert supports four types of rounding:", I'll change "four" to "several". I don't think we need to do anything else or that even that is essential, not being convinced that our wording has caused any problems for editors actually using {{Convert}} in an article. NebY (talk) 16:51, 27 February 2026 (UTC)[reply]

1 g of something from each m²

In dust devil I've found this statement: 1 gram of dust per second from each square metre (10 lb/s from each acre). Is there a workaround to use {{convert}} in this case?-- Carnby (talk) 13:44, 11 April 2026 (UTC)[reply]

How about {{convert|1|g/s/m2|lb/s/acre}} : 1 gram per second per square metre (8.9 lb/s/acre) -- WOSlinker (talk) 17:30, 11 April 2026 (UTC)[reply]

If you want to keep the verbose version of the SI value (probably a good idea in this case), you could use "|disp=out |abbr=off": 1 gram of dust per second from each square metre (8.9 pounds per second per acre). Indefatigable (talk) 17:50, 11 April 2026 (UTC)[reply]

{{convert|1|g/s/m2|lb/s/acre|abbr=off}} displays as: 1 gram per second per square metre (8.9 pounds per second per acre) Stepho talk 05:36, 12 April 2026 (UTC)[reply]

I wrote this: {{convert|1|g/s/m2|lb/s/acre|-1|abbr=off}} yielding "Field experiments indicate that a dust devil can lift 1 gram per second per square metre (10 pounds per second per acre) of dust on the ground over which it passes." Does it soundlook good?-- Carnby (talk) 13:09, 13 April 2026 (UTC)[reply]

Looks good. Although I think the correct grammar is "off the ground". Stepho talk 21:52, 13 April 2026 (UTC)[reply]

Right, thank you.-- Carnby (talk) 04:01, 14 April 2026 (UTC)[reply]

Rounding method

Which rounding method does the template/module implement? Is it PHP's round? (In that case, which RoundingMode?) I imagine there might be some special cases. Could this be documented at Help:Convert? TheFeds 22:13, 15 April 2026 (UTC)[reply]

Convert rounds half away from zero using custom code (not PHP). The convert system is the common usage meaning of "round" so I think documenting it would just bloat the already over-sized page and cause confusion because many people would be unaware that other methods existed. Johnuniq (talk) 06:48, 16 April 2026 (UTC)[reply]

[physconst-G-1] "2022 CODATA Value: Newtonian constant of gravitation". The NIST Reference on Constants, Units, and Uncertainty. NIST. May 2024. Retrieved 2024-05-18.

[1]