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 indefinitely 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

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_🜨 [1], 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_🜨[2]. 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 ))"[3] 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]

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 [4] but my opponent don`t agree, and we had [5], then [6] with my detailed explanations, and then simply [7] 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 ~~sound~~look 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]

Multiple output

Right now many Canadian airports contain something like {{convert|1.5|NM||lk=in}} giving 1.5 nautical miles (2.8 km; 1.7 mi). But when using |order=flip, like this {{convert|1.5|NM||lk=out|order=flip}} you get 2.8 kilometres; 1.7 miles (1.5 NM). Is there any way to get either the kilometres or miles, depending on the article, inside the brackets? CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 04:31, 17 May 2026 (UTC)[reply]

Not really. You can use order=out to do what you want, but also linking NM is a problem. The closest is:

{{convert|1.5|NM|mi km NM|lk=out|order=out}} → 1.7 miles (2.8 km; 1.5 NM)

With order=out, the input is used for the conversion but is then ignored. The displayed input is the first unit in the output. If really needed, there could be a new unit NMlk which was the same as NM but had a link built in to the symbol and name. That is done for unit chain which also has chainlk. Johnuniq (talk) 06:02, 17 May 2026 (UTC)[reply]

Thanks. I figured that there was some way to do it but I just couldn't see it. Linking the nautical miles is important because most people don't use it. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 06:08, 17 May 2026 (UTC)[reply]

Please link to, say, three articles where NMlk would be useful and the unit can be added. That is, if linking km as above is a problem. Johnuniq (talk) 06:15, 17 May 2026 (UTC)[reply]

Cambridge Bay Airport, Inuvik (Mike Zubko) Airport, Dawson City Airport, and there's 100's more Canadian airports that will have it. I'm not sure that linking kilometres is a problem but it probably falls under Wikipedia:Manual of Style/Linking#What generally should not be linked item 3 "Common units of measurement". CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 06:23, 17 May 2026 (UTC)[reply]

I added NMlk:

{{convert|1.5|NM|mi km NMlk|order=out}} → 1.7 miles (2.8 km; 1.5 NM)

Johnuniq (talk) 06:35, 17 May 2026 (UTC)[reply]

Thanks. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 06:46, 17 May 2026 (UTC)[reply]

Pinging @10mmsocket

Surely the question is "what is the relevance of nautical miles?". I understand that in aeronautical publications, this is the preferred unit of measure, but Wikipedia is not an aeronautical publication. It would be the same as identifying the Belair Stud as being 91⁄2 furlongs (13⁄16 mi; 1.9 km) from the nearest 7-Eleven store. A case of horses for courses? As I have also observed, if it was anything other than an airfield, such as a parkland, or a large town, we wouldn't hesitate to unload a unit of measure that is alien to most readers of Wikipedia. However I do recognise that the original data often comes in the form of NM, so I looked for a solution that included that aspect.

My solution, as already described in this discussion is a variant of the convert template as follows...

{{convert|5|NM|mi km|0|order=out}} starts with 5 NM but outputs 6 miles (9 km)
or, with a little bit of tweaking
{{convert|5|NM|0|abbr=in|order=out}} outputs metric first i.e. 9 km (6 miles)

The other bonus here is that everybody recognises both miles and km, and we no longer need a link to explain "NM".

WendlingCrusader (talk) 13:15, 17 May 2026 (UTC)[reply]

Yup. I'm 100% with you. Distance in NM can be sourced if necessary, but displaying it is just not needed. 10mmsocket (talk) 20:02, 17 May 2026 (UTC)[reply]

Not playing nice with visual editor?

If I edit:

{{convert|12.75|±|0.02|km2|sigfig=3}}

with the Visual Editor I get a mess. It comes up with From unit = "±", To units = "0.02", and Precision of suffix = "km2". Is this a problem with VE, or a problem with the template? RoySmith (talk) 17:17, 24 May 2026 (UTC)[reply]

@RoySmith: Neither, it's a problem with the definitions at Template:Convert#TemplateData, which presumes that the first four positional parameters will only take on certain roles. In other words, it's not flexible. --Redrose64 🌹 (talk) 21:15, 24 May 2026 (UTC)[reply]

English variety

Would it be possible for this template to use American English spellings by default in articles with {{Use American English}}? A Wondrous Raven (talk) 19:29, 31 May 2026 (UTC)[reply]

This has been suggested before, see August 2023 and December 2025. As can be seen in my replies, I do not think individual modules should roll their own method of detecting page-wide options such as "Use X English". Convert could do what was wanted If there were a way for a module to read such data efficiently and reliably. Preferably, the method would work, or at least not cause problems, on Wikipedias in other languages because dozens of sites use convert. The issue should be raised as a wishlist request for the WMF to resolve, but see WP:COMMTECHGATE. Johnuniq (talk) 01:49, 1 June 2026 (UTC)[reply]

Ah, okay. A Wondrous Raven (talk) 02:12, 1 June 2026 (UTC)[reply]

Technically I suspect it would be easy for a bot to set convert to use sp=us on articles that are tagged with {{Use American English}}, however whether there would be consensus for that task is a different question I would not like to predict the answer to. Thryduulf (talk) 09:39, 1 June 2026 (UTC)[reply]

That's an interesting thought. A bot could use Category:Use American English which would work well (modules cannot access page categories). At one point, WP:AWB was set to include certain changes to convert when doing its routine changes. I haven't noticed that in recent years and don't know if it is still used. If not done with other edits, a bot might hit a lot of articles. It should avoid changing converts with abbr=on for simplicity and to reduce the number of changes. Johnuniq (talk) 10:27, 1 June 2026 (UTC)[reply]

For the same reasons a bot also shouldn't add the parameter when British and US English are the same, e.g. lbs ↔ kg, ft → m when abbreviation is not "in" or "off". That could get quite complicated though. Thryduulf (talk) 23:43, 1 June 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]