Template talk:Convert

Template:Convert

... in conception

... and in reality

notice of RfC on Tmcft

Template:Convert has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you.

The RfC question is: Should the {{Convert}} template support the unit Tmcft? Joe vom Titan (talk) 20:31, 8 July 2025 (UTC)

Lumber boards

Wasn't there a way to convert 2 × 4 s lumber boards?-- Carnby (talk) 20:12, 27 July 2025 (UTC)

We have board feet as a measure of volume - n board feet is the volume of a board 12 inches wide by 1 inch thick, of length n feet. Therefore, 1 board foot is 144 cubic inches:

• {{convert|1|board foot|cuin|0}} → 1 board foot (144 cu in)

and 12 board feet is 1 cubic foot:

• {{convert|12|board foot|cuft}} → 12 board foot (1.0 cu ft)

But a nominal "two-by-four" might be as small as 1.5 x 3.5 inches, because of planing and other processing, so it's not an exact size, so I don't think including it as a conversion is useful. --Redrose64 🌹 (talk) 20:59, 27 July 2025 (UTC)

Not clear what you want. Volume? Area? Length? Can you give an example of what it would look like and how you would like to invoke it.  Stepho  talk  23:14, 27 July 2025 (UTC)

Sure: in Wall I had to use {{nowrap|2 × 3 s}} ({{cvt|1+1/2|x|2+1/2|in|mm|disp=comma}}) or {{nowrap|2 × 4 s}} ({{cvt|1+1/2|x|3+1/2|in|mm|disp=comma}}) yielding 2 × 3 s (1+1⁄2 in × 2+1⁄2 in, 38 mm × 64 mm) or 2 × 4 s (1+1⁄2 in × 3+1⁄2 in, 38 mm × 89 mm).-- Carnby (talk) 05:30, 28 July 2025 (UTC)

I saw your entry at Wall#Temporary_wall. I had to read it a few times before I understood it. I think many readers from outside America might never decipher it. I think it means that you build a frame with wooden posts of 2" x 4" cross section and cover it with plaster board. It assumes an American practice and this will differ in other parts of the world (eg, in China brick and mortar is cheaper even for temporary walls because wood is expensive). Sadly, the nominal 2" x 4" cross section might actually be only 1+1⁄2" × 3+1⁄2" (presumably lumbar companies cost cutting by making it thinner). I think we are asking convert too much - it falls into what men mean when they say "12 inches" (talking about fish of course :) . The nominal 2x4" can be almost any size the company thinks it can get away with, making a mockery of both economics and any attempt to nail down (pun not intended) a conversion factor to either real inches or mm.  Stepho  talk  06:24, 28 July 2025 (UTC)

Lumbar company

Stepho, AFAIK you're a sensible person, but everything you just said is nonsense. 2x4s cannot be "almost any size", but are a very specific size, for reasons that must surely be obvious. That that size isn't literally 2 inches by 4 inches is for historical reasons having nothing to do lumbar companies (or even lumber companies) cutting costs or getting away with something. See Lumber#North_American_softwoods. EEng 21:27, 28 July 2025 (UTC)

I stand corrected, 2x4 is apparently a standardised size in America. I'm interested to see what size (in mm) the rest of the world uses for a 2x4. I still think that entry at wall is a bit too Americanised for non-American readers to understand but that's outside of convert's scope.  Stepho  talk  01:54, 29 July 2025 (UTC)

Some measurement humour. https://xkcd.com/3138/  Stepho  talk  09:46, 8 September 2025 (UTC)

Nerd. EEng 14:53, 8 September 2025 (UTC)

Yep, card carrying and complete with anorak.  Stepho  talk  23:30, 8 September 2025 (UTC)

MeV to K?

Cosmology articles like Chronology of the universe use MeV and K interchangeably, but convert does not like energy -> temperature. Its just scale factor, 11.6K to 1eV. Is there another way to do this? Of course we can do it by hand but I thought I would check. Johnjbarton (talk) 23:44, 3 August 2025 (UTC)

Boltzmann constant, right? Hawkeye7 (discuss) 03:29, 4 August 2025 (UTC)

A previous discussion is at July 2018. For some historical reason, there is a keVT unit:

• {{convert|15|keVT}} → 15 kiloelectronvolts (170 MK)
• {{convert|15|keVT|MK|abbr=none}} → 15 kiloelectronvolts (170 megakelvins)
• {{convert|174|MK|abbr=none}} → 174 megakelvins (15.0 kiloelectronvolts)

The July 2018 discussion is over my head but the points raised by Quondum need thought. Johnuniq (talk) 04:15, 4 August 2025 (UTC)

I feel that in Wikipedia, we gain by avoiding units that are not interpretable to the average reader. Supporting conversions such as this unfortunately encourages this use. —Quondum 13:58, 4 August 2025 (UTC)

I agree that consistent use of non-exotic units is a good goal. But which unit do you consider not interpretable by the average reader, 10¹⁵ K or 150 GeV? I don't really view these as things users try to make sense of so much as a kind of index between cosmology and particle physics data.

The issue in my case is that different sources use one or the other, sometimes both. Effective comparison across sources requires conversion. Johnjbarton (talk) 16:21, 4 August 2025 (UTC)

My inclination would be to present temperatures with the unit kelvin, as the average reader knows that this is a unit of temperature, even when the value is huge, whereas the eV is not obviously a unit of temperature, and often gets used as a unit of mass, wavenumber, you name it. I expect any reader at least being able to interpret 10¹⁵ K as "oh, that is an exponentially large temperature", versus "150 GeV", which many might just gloss over as a non-understandable physics-y thing. As to sources, these are to allow verification (or further study), but we do not need to make it that similar to the source. The reader who does not know how to convert "150 GeV" in the source to a temperature has no idea what "150 GeV" means in the context, anyway. It would be perfectly reasonable to put a footnote in an article to the effect that "Particle physics texts often the use the quantity kT to represent temperature, with the unit electronvolt (eV). A temperature of 1 eV corresponds to 11604 K.", which would ease their encounters with units in use elsewhere. —Quondum 17:10, 4 August 2025 (UTC)

With reference to your comment about indexing, I see the time being the primary index. Devoting a column to indexing on another parameter such as temperature seems too special-purpose and redundant. —Quondum 18:54, 4 August 2025 (UTC)

nbsp capability

Village Pump referred me here. Have run into this issue on several articles, one example occurring in the lead for Chula, Virginia (at least with the screen resolution that I'm using): Is there a way to force the template to put a nonbreaking space between numeral and units displayed in the article text, so as to reliably generate "7 miles (11 km)"? A single good example of the correct syntax might suffice. — HelpMyUnbelief (talk) 00:14, 5 August 2025 (UTC)

This seems to do it:

{{convert|2|mi|km|disp=preunit| }} → 2 miles (3.2 km)

—Quondum 00:53, 5 August 2025 (UTC)

Quondum has provided a good solution but the reason convert works as it does is that Wikipedia:Manual of Style/Dates and numbers says "a normal space is used between a number and a unit name". Johnuniq (talk) 04:24, 5 August 2025 (UTC)

Indeed that's what the MOS says...but we've got to be overlooking something. Surely the intention of that rule was not that article text like this should be acceptable:

The area is served by the post office 7
miles (11 km) southwest.

— HelpMyUnbelief (talk) 05:52, 5 August 2025 (UTC)

That's exactly the intent of MOS. A line break can occur between any 2 words. There is no special case for between numbers and units. E.g, this is also acceptable:

The man was John
Doe from the United
States. He lived 7
miles out of town.

 Stepho  talk  06:23, 5 August 2025 (UTC)

Do note MOS:NBSP: It is desirable to prevent line breaks where breaking across lines might be confusing or awkward. The first example provided by that guideline is 19 kg. The guideline also provides a good case where {{convert}} might be used but preventing a break is undesirable, specifically tables, since horizontal space is precious. – Daℤyzzos (✉️ • 📤) 10:00, 5 August 2025 (UTC)

The idea that editors should be able to override line break defaults on a case-by-case basis seems good, and I agree with HelpMyUnbelief for the need in this example.

Tangential: This template's doc page has a broken link Help:Convert § Wrapping and line breaking. —Quondum 13:14, 5 August 2025 (UTC)

The bottom line is that convert follows MOS and proposed changes should be discussed there. Convert puts nbsp in 19 kg but a space in 19 kilograms because that is what MOS:UNITNAMES specifies. Thanks Quondum for pointing out that there is no "Wrapping and line breaking" section at Help:Convert despite there being a link to it at Template:Convert#Wrapping and line breaking. It turns out that I removed the section. The original is at October 2023. I hoped Help:Convert would focus on common usage examples—how do you do X. But people started expanding the docs here (Template:Convert/doc), then moved stuff to Help:Convert when this page became too bloated. I don't think there is anything in the section I removed that should be retained because it can be summed up as "convert follows MOS". The details bloat whatever page they are on. If someone wants to restore it, please put it here rather than using Help:Convert as an overflow page. Or maybe make another doc page for techo details. Johnuniq (talk) 03:50, 6 August 2025 (UTC)

• Historical note: During a major overhaul of WP:MOSNUM some ten years ago, the text Guidance on the use of non-breaking spaces ("hard spaces") is given in some sections below, but not all situations in which hard spaces (  or  ) or {{{1}}} may be appropriate are described was added (by me, I think). It has long been my intent to add specific guidance at each point in MOSNUM it's needed, but every time I think of actually doing that I get a headache. EEng 15:38, 8 September 2025 (UTC)

"Limitations" section

I propose a change to the first sentence of "Limitations".

Instead of this:

This is a list of features that the module may be expected to support, but which will not work.

I recommend this:

The following strategies may seem right for this module, but they will not work.

I think "a list of features" is exactly the wrong thing to say - isn't it really a list of non-features, but ones that people are likely to try anyway?

TooManyFingers (talk) 05:26, 30 August 2025 (UTC)

This refers to Help:Convert#Limitations (its talk page redirects to here). Strategies is not the right word. Johnuniq (talk) 06:19, 30 August 2025 (UTC)

Then maybe this:

This is a list of commonly-expected features that the module does not have.

Perhaps it's by an effort to be face-saving or polite or positive, but the existing sentence does not mean what its writer thought it meant. TooManyFingers (talk) 20:34, 30 August 2025 (UTC)

Alias hectares

So I just found that {{cvt|5|hectares}} does’t work which is weird because {{cvt|5|acres}} does. So I would love to get that alias setup. I believe all that is needed is to insert the snippet below at line 326 on Module:Convert/data.

    ["hectares"] = {
	target   = "hectare",
    },

Any objection to me adding this? Zackmann (^{Talk to me}/_{What I been doing}) 01:16, 11 September 2025 (UTC)

New units are added at Module:Convert/extra first. Changes to convert are bundled and done together (overhead of changes affecting 1.25 million transclusions + sanity checking). The issue concerns whether plurals for all common units should be defined, and what is a common unit. Have a look at Module:Convert/documentation/conversion data to see that there are too many strange units. I see the point that "hectares" is a natural way of speaking about that unit so maybe it is a good candidate, but are there others that should be done. Johnuniq (talk) 03:10, 11 September 2025 (UTC)

3 dimensional measurements

Is there a way that I’m not seeing to only have the units printed one time when displaying 3 unit measurements? For example:

• {{cvt|3 x 5 x 6|in|cm}} → 3 in × 5 in × 6 in (7.6 cm × 12.7 cm × 15.2 cm)

What I was hoping to achieve is:

• {{cvt|3 x 5 x 6|in|cm}} → 3 × 5 × 6 in (7.6 × 12.7 × 15.2 cm)

Am I missing something? I’ve looked though the documentation pretty thoroughly… — Zackmann (^{Talk to me}/_{What I been doing}) 07:33, 16 September 2025 (UTC)

So I just figured out that you can do {{cvt|3xx4xx5|in|cm}} and it does what I want! Is that documented anywhere?! — Zackmann (^{Talk to me}/_{What I been doing}) 08:00, 16 September 2025 (UTC)

It is at Help:Convert#Ranges. The background is that the MOS requires the behavior that x implements. (I seem to recall some recent MOS discussions where quite a few people suggested that should be relaxed?) I retained xx in convert as a workaround for the occasional cases where the MOS guideline may not give a good result. Johnuniq (talk) 08:51, 16 September 2025 (UTC)

So basically I stared right at the documentation and just didn’t see it…. :-( WOW. Thanks for keeping that in Johnuniq! It is coming in VERY handy with a module I’m writing. —Zackmann (^{Talk to me}/_{What I been doing}) 09:00, 16 September 2025 (UTC)

How irritating. Another retained but not-standard range is *. I faced a lot of pushback for keeping * and xx and it appears that somewhere the documentation at Help:Convert was "fixed" to remove what were considered to be deprecated features. I think I must have restored xx to Help:Convert but failed on *. Using * gives no spacing:

• {{convert|3|*|6|ft}} → 3×6 feet (0.91×1.83 m)

Johnuniq (talk) 09:04, 16 September 2025 (UTC)

Tmcft

An RfC regarding Tmcft is at WT:Manual of Style/Dates and numbers#RfC Tmcft in convert template? while previous discussions are at WT:Manual of Style/Dates and numbers/Archive 163#Tmcft and Template talk:Convert/Archive 3#Tmcft. The discussions are all over the place with no agreement that I can see. As a trial, I have put units tmcft and Tmcft in Module:Convert/extra. The other units in the following table already existed.

Code	Symbol	Name
tmcft	tmcft	tmcft
Tmcft	tmcft	thousand million cubic feet
Bcuft	billion cu ft	billion cubic feet
Gcuft	×10^9 cu ft	billion cubic feet

Examples:

• {{convert|178.74|tmcft}} → 178.74 tmcft (5.061 km³)
• {{convert|178.74|tmcft|lk=in}} → 178.74 tmcft (5.061 km³)
• {{convert|178.74|Tmcft}} → 178.74 thousand million cubic feet (5.061 km³)
• {{convert|178.74|tmcft|abbr=on|lk=out|order=flip}} → 5.061 km³ (178.74 tmcft)
• {{convert|178.74|Tmcft|abbr=in|order=flip}} → 5.061 km³ (178.74 thousand million cubic feet)
• {{convert|178.74|Tmcft|abbr=on|order=flip}} → 5.061 km³ (178.74 tmcft)
• {{convert|123|Bcuft|km3}} → 123 billion cubic feet (3.5 km³)
• {{convert|123|Bcuft|km3|abbr=on}} → 123 billion cu ft (3.5 km³)
• {{convert|123|Gcuft|km3|abbr=on}} → 123×10^⁹ cu ft (3.5 km³)

Johnuniq (talk) 06:47, 22 September 2025 (UTC)

Looks good to me. I have no use for this, but it seems some people do, so thanks! Gawaon (talk) 07:15, 22 September 2025 (UTC)

Unit link

Is it possible to have the unit of measure link similar to the “US$” wikilink in Template:US$? Could be useful for uncommon measure units like frequencies (Hz, MHz, GHz, etc). — TadgStirkland⁴⁰¹(Tadg^Talk-Email) 01:59, 26 September 2025 (UTC)

Search the text link in Template:Convert/doc. EEng 02:03, 26 September 2025 (UTC)

Oh, good grief! It was right there… I completely missed it! Thank you so much, and a quick reply at that! — TadgStirkland⁴⁰¹(Tadg^Talk-Email) 02:08, 26 September 2025 (UTC)

Generally speaking, if your question is "Can Convert do X?", you can bet the answer is Yes. Convert is like a Swiss Army Knife. EEng 07:27, 26 September 2025 (UTC)

Swiss army chainsaw.  Stepho  talk  16:37, 26 September 2025 (UTC)

Plans for new version

I am planning to release a new version soon. The motivation is to introduce parameter error=x which means that convert would either work (and error=x would have no effect), or would display x instead of the usual convert error. I want this for at least one infobox (Template:Infobox food) which calls convert with text that is often a number, but which can be anything. For example, the infobox might call {{convert|123|kcal}} (which would work), or it might call {{convert|123 (per biscuit)|kcal}} (which would cause convert to return an error which the infobox would hide using #iferror). In the latter case, convert calls Module:Convert/extra to determine if the extraneous text is an "extra" unit. That means that many of the "what links here" entries for that module are false hits. I periodically check that list to see what problems have occurred, and to see what units defined in the extra module are being used.

Using the new parameter, the infobox would not need #iferror. Instead, it would call {{convert|123 (per biscuit)|kcal|error=123 (per biscuit)}} which would display "123 (per biscuit)" instead of an error. The change is in the sandbox, examples:

• {{convert/sandbox|123|kcal|error=123}} → 123 kilocalories (510 kJ)
• {{convert/sandbox|123 (per biscuit)|kcal|error=123 (per biscuit)}} → 123 (per biscuit)

Another minor change in the module is for projects that use variable names where the unit name can vary depending on the value. At ukwiki, they want a fraction slash to be detected as an alternative to a plain slash when used in a value with a fraction (such as 1+3/4). The name of a unit can be different if a fractional value is used.

The October 2024 release changed units mile and miles to include abbr=off on the principle that if someone wants to display the symbol "mi", they can use that as the input. If "mile" is used, the wanted output is probably "mile" or "miles". Any thoughts on doing the same for the following?

feet inch inches meter meters metre metres yard yards liter liters litre litres

Unit foot is not in that list because it has a special purpose, namely its plural form is "foot", not "feet". The singular form is currently "1 ft" if abbreviated. That could be changed to "1 foot". Thoughts? Johnuniq (talk) 07:23, 2 October 2025 (UTC)

For me, I find "mi" an unusual abbreviation not often used in the wild, so I like the full spelling of "mile" and "miles".

The others listed have well known and well used abbreviations of ft, in, m, yd, L. So I would continue using the short form for them.  Stepho  talk  23:17, 2 October 2025 (UTC)

Good points. But why would someone write "liter" if they wanted "l" to be displayed? Maybe liter is unambiguous in the wikitext and they hope convert will display the wanted symbol? Anyway, I'm always happy to avoid changes! Johnuniq (talk) 00:38, 3 October 2025 (UTC)