Template talk:Convert

Template:Convert

... in conception

... and in reality

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)

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)

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)

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)

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)

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)

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

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 9+1⁄2 furlongs (1+3⁄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)

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)

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)

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

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)

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)

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

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)

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)

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)

Things could go wrong. Sometimes editors go on a tear of adding {{Use American English}} to many articles inappropriately (seen it, rolled it back, got the T-shirt). If a bot adjusted the uses of Convert before any caught it, that'd survive rollback of the template additions and nothing would cause the bot to self-revert. NebY (talk) 14:10, 2 June 2026 (UTC)

A maintenance bot could look for the addition or removal of such templates and add/remove the sp=us parameter after a delay to allow for quick rollbacks, etc. There are multiple bots that work like this for other tasks. Thryduulf (talk) 14:17, 2 June 2026 (UTC)

I did not know (/think of) that. Thank you! NebY (talk) 14:19, 2 June 2026 (UTC)

It should be technically possible in the same way that {{cite web}}, et al., can figure out how to format dates in articles when there is {{use mdy dates}} or {{use dmy dates}} present. Imzadi 1979 → 01:11, 2 June 2026 (UTC)

There should not be wholesale changing of British English to the American variety with this template. See[]. I have just reversed an edit of an article that I started. This template was added, even though there were no American spellings in it. The American version of English has no automatic superiority. This template seems to be a way of imposing this imaginary superiority.JMcC (talk) 23:06, 6 June 2026 (UTC)

The template being incorrectly placed is a separate issue that is at best tangential to what is being discussed here. All articles with the {{Use American English}} tag should use American English, all articles with the {{Use British English}} tag should use British spellings - otherwise there would be no point in those templates existing. If you believe an article uses the wrong tag then correct it and/or discuss it like with any other change to the article. Thryduulf (talk) 00:21, 7 June 2026 (UTC)

Suggestion

I was thinking it would be helpful to modify the description of the Abbreviation field to a bulleted list, as follows. The purpose would be to make it easier for users to more quickly parse and understand the available options.

Display for the units:

• “on” to display all units using their unit symbols
• “off” to display all units in full words
• “in” to display the unit symbol for the input unit
• “out” to display the unit symbols for the output units
• “unit” to display unit symbols for both input and output units when using scientific notation
• “values” for no units at all (neither unit symbols nor full words of units)

It might be further modified for better appearance:

Display for the units:

• on – displays all units using their unit symbols
• off – displays all units in full words
• in – displays the unit symbol for the input unit
• out – displays the unit symbols for the output units
• unit – displays unit symbols for both input and output units when using scientific notation
• values – displays no units at all (neither unit symbols nor full words of units)

It could possibly be consolidated as follows, though I don't know if that's better; just brainstorming here.

Display for the units:

• on/off – displays all units using their unit symbols (on) or full words (off)
• in/out – displays the unit symbol for the input or output unit
• unit – displays unit symbols for both input and output units when using scientific notation
• values – displays no units at all (neither unit symbols nor full words of units)

Any thoughts? abcasada (talk) 19:36, 23 June 2026 (UTC)

Are you referring to the Template:Convert#TemplateData section with description starting "Display for the units"? I like the compact alternative (the last above) although I have no idea how it would look to editors. However, the description for abbr=unit is not right. The most accurate documentation is probably the comment "abbr=on but abbreviate units only: e6km → million km (not ×10⁶ km)" in Module:Convert/text. The release note is another reliable source: Template talk:Convert/Archive September 2016#Module version 15. Also, I would suggest "name" rather than "full words". Johnuniq (talk) 06:15, 24 June 2026 (UTC)

Accept units like ºC as an alias for °C

Description of suggested change: proposing adding support for informal homoglyph U+00BA º MASCULINE ORDINAL INDICATOR to automatically redirect to the typographically recommended U+00B0 ° DEGREE SIGN for the temperature units.

Diff:

−

+

["ºC"] = { target = "C", }, ["ºF"] = { target = "F", }, ["ºR"] = { target = "R", },

 Juwan  🕊️🌈 09:13, 24 June 2026 (UTC)

The proposal is that new units ºC and ºF and ºR be accepted as aliases for temperature units °C and °F and °R. I refactored your comment because proposals here are considered before moving to implementation. Another point is that the place to add trial units would be Module:Convert/extra which does not need an edit request. Any thoughts from others? I've never encountered º. Is there an article where someone tried to use that alternative? Johnuniq (talk) 09:26, 24 June 2026 (UTC)

that is correct. the ordinal symbol wouldn't be encountered too onwiki, often because it will be copyedited away, but it is certainly used elsewhere, especially for editors that speak Romance languages as many of them have the ordinal symbol on their keyboard but not the degree one (or not as easily accessible).  Juwan  🕊️🌈 09:32, 24 June 2026 (UTC)

Convert defines 750 units and another 296 aliases for units. That complexity makes people here reluctant to add more without good reason based on examples. Choice can be good but too much choice can cause confusion because someone trying to use convert is going to wonder "What should I do?". If someone uses the proposed unit code, others will end up copying it. What would be better would be to let editors know that they should use C if they want °C. They sooner they learn that, the better. Anyway, I'm going to wait to see if other people have an opinion. Johnuniq (talk) 09:57, 24 June 2026 (UTC)

It might be better to say that many primarily Portugese- or Spanish-speaking editors may have keyboards which have the symbol (Ordinal indicator#Typing tells us Portuguese and Spanish keyboard layouts are the only ones on which the characters are directly accessible through a dedicated key). I do rather agree that the simplicity of using C is to be encouraged, benefiting editors glancing over or correcting article source too. NebY (talk) 10:45, 24 June 2026 (UTC)

The ordinal indicator is different from the degree symbol. Their Unicode values are, respectively, 'MASCULINE ORDINAL INDICATOR' (U+00BA) and 'DEGREE SIGN' (U+00B0). These display as º and ° which, depending upon machine, operating system, installed fonts and browser, may display identically or differently. On my Dell/Windows/Firefox setup, they're noticeably different - º is oval and taller, ° is circular and smaller. --Redrose64 🌹 (talk) 20:03, 24 June 2026 (UTC)

On Apple ipad/ios/safari, they're only distinguishable when zoomed out. Curiously, when inside <code>...</code> tags, 00ba is underlined, 00b0 is not. --Redrose64 🌹 (talk) 20:15, 24 June 2026 (UTC)

As a side question, why is {{Text diff}} being used? These are not text changes; the sandbox should be used to show the desired change; this will also allow direct testing. --Redrose64 🌹 (talk) 20:21, 24 June 2026 (UTC)

short and boring answer: the template is part of the preloaded code and I didn't want to bother since it's just adding items to a list.  Juwan  🕊️🌈 20:55, 24 June 2026 (UTC)

"At three-quarter-inch centers"

I've never come across one like this before so unless someone has the solution ready to hand, please don't spend any time on it, it can be done manually. It certainly doesn't merit a development request.

I have tried (optimistically!)

• {{Convert|0.75|inch|mm|spell=in |adj=mid|centers}} = zero-point-seven-five-inch centers (19 mm)
• {{Convert|{{frac|3|4}}|inch|mm|spell=in|adj=mid|centers}}} =

Any other suggestions? 𝕁𝕄𝔽 (talk) 15:24, 9 July 2026 (UTC)

{{Convert|3/4|inch|mm|spell=in|adj=mid|centers}} = three-quarters-inch centers (19 mm) is close. The other option I can think of is a workaround:

three-quarter-inch ({{convert|3/4|inch|disp=out}}) centres. = three-quarter-inch (19 mm) centres. Thryduulf (talk) 15:55, 9 July 2026 (UTC)

tyvm. I was being "too clever by half" [] using {{frac}}. I almost had it. 𝕁𝕄𝔽 (talk) 16:42, 9 July 2026 (UTC)

Thinking about this a bit more, I'm not certain that "three-quarters-[unit]" is ever correct grammar (at least in British English) when used as an adjective, in a similar fashion to the way that the adjective is always "foot" not "feet", regardless of how many feet there are. If I'm right on this then there is a need for a change to the template. Thryduulf (talk) 10:29, 10 July 2026 (UTC)

I agree that "three-quarters-inch centres" is not colloquial BrEn. Ditto "two-feet-six centres" sb "two-foot-six centres". What an antediluvian system of measure! 𝕁𝕄𝔽 (talk) 10:45, 10 July 2026 (UTC)

@JMF and Thryduulf: Might we write

at centres of {{convert|3/4|in|mm|of an|spell=in|adj=pre}}

which emits "at centres of three-quarters of an inch (19 mm)"? --Redrose64 🌹 (talk) 12:45, 11 July 2026 (UTC)

Hmm, yeah, the "of an" does change the correct usage from singular to plural, but that formulation isn't always going to be possible. And thinking further both "at seven-eighth inch centres" and "at seven-eights inch centre" feel colloquially fine. I'm wondering if the simplest thing might be a parameter to force singular or plural? Thryduulf (talk) 12:54, 11 July 2026 (UTC)

Stones

I don't know if there is an issue with this template and the UK-specific measurement of the stone. If you look at Rod Stewart and in particular the second footnote, it uses {{convert|9|st}} for his weight when he was young, but the output displays 9 stone (130lb; 57kg). As there are 14 pounds in a stone, 9 stone is 126 pounds, not 130........... -- ChrisTheDude (talk) 09:07, 10 July 2026 (UTC)

It's a rounding problem. Since a stone is so big, it rounds off the last digit. Force it to round to 0 digits using |0 .

{{convert|9|st|0}} gives 9 stone (126 lb; 57 kg)  Stepho  talk  09:25, 10 July 2026 (UTC)

@Stepho-wrs: - perfect, thank you! -- ChrisTheDude (talk) 10:19, 10 July 2026 (UTC)

False positives for punctuation errors

I am told that this template must contain formatting like {{convert|6 , 8 , 12 or 18|in|mm|0}} in order to produce the correct results. I am wondering, can this be adjusted so that it does not require creation of a false positive for a common kind of punctuation error? BD2412 T 02:56, 26 July 2026 (UTC)

Examples:

• {{convert|6 , 8 , 12 or 18|in|mm|0}} → 6, 8, 12 or 18 inches (152, 203, 305 or 457 mm)
• {{convert|6, 8, 12 or 18|in|mm|0}} →

I agree that this needs a better solution. Zackmann (^{Talk to me}/_{What I been doing}) 03:06, 26 July 2026 (UTC)

I'm guessing that false positive is referring to the space-before-comma syntax, and some tool is finding that issue inside template parameters (ideally, it should skip checking wikitext inside a template). The actual syntax that convert wants is:

• {{convert|6|,|8|,|12|or|18|in|mm|0}} → 6, 8, 12 or 18 inches (152, 203, 305 or 457 mm)

That is, each component should be in a separate argument. The first parameter in the above is 6 , 8 , 12 or 18. Convert expects that to be a number. When it finds that it isn't, it looks for various commonly used patterns such as 2+3/4 for a fraction or 2-4 for a range. It finishes by splitting the argument on whitespace, then looking for a range. That's why it wants each comma surrounded by a space. It would be unnecessary overhead for convert to specifically look for commas with no leading space particularly since there are other range specifiers. Johnuniq (talk) 04:19, 26 July 2026 (UTC)

@Johnuniq: Unfortunately, reader-facing spacing errors can occur inside template parameters as readily as in running text (just consider a template with a parameter for listing corporate officers, or languages spoken in a region, or genres for a movie, or associated acts for a band), and extraneous spaces or missing spaces around punctuation will be found as ubiquitously as anywhere else. Normally, where an extra space or missing space intentionally occurs in some text, we use hidden text to denote this, e.g., SILVERDALE,<!-- -->LANCASHIRE or SILVERDALE <!-- -->, LANCASHIRE (or, with an explanation, SILVERDALE,<!-- no space -->LANCASHIRE or SILVERDALE <!-- extra space -->, LANCASHIRE). I don't know whether that would work in this template, but the text you have provided works fine. BD2412 T 17:44, 26 July 2026 (UTC)