view · edit 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, seerounding. 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: SeeHelp:Convert units for an introduction andModule: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 withHelp:Convert. For more, see theFAQ.

Template:Convert ispermanentlyprotected from editing as it is aheavily 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 byconsensus, 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'sdocumentation to add usage notes orcategories. Any contributor may edit the template'ssandbox. Functionality of the template can be checked usingtest cases.

Archives

Archive 1 Archive 2 Archive 3

This page has archives. Sections older than90 days may be auto-archived byLowercase sigmabot III if there are more than 2.

Template:Convert

... in conception

... and in reality

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

We haveboard feet as a measure of volume -n board feet is the volume of a board 12 inches wide by 1 inch thick, of lengthn 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)[reply]

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)[reply]

Sure: inWall 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}}) yielding2 × 3 s (1+1⁄2 in × 2+1⁄2 in, 38 mm × 64 mm) or2 × 4 s (1+1⁄2 in × 3+1⁄2 in, 38 mm × 89 mm).--Carnby (talk)05:30, 28 July 2025 (UTC)[reply]

I saw your entry atWall#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. Ithink 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)[reply]

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. SeeLumber#North_American_softwoods.EEng21:27, 28 July 2025 (UTC)[reply]

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 atwall 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)[reply]

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

Nerd.EEng14:53, 8 September 2025 (UTC)[reply]

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

Village Pump referred me here. Have run into this issue on several articles, one example occurring in the lead forChula, 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)[reply]

This seems to do it:

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

—Quondum00:53, 5 August 2025 (UTC)[reply]

Quondum has provided a good solution but the reason convert works as it does is thatWikipedia: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)[reply]

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)[reply]

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)[reply]

Do noteMOS:NBSP:It is desirable to prevent line breaks where breaking across lines might be confusing or awkward. The first example provided by that guideline is19 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)[reply]

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 linkHelp:Convert § Wrapping and line breaking. —Quondum13:14, 5 August 2025 (UTC)[reply]

The bottom line is that convert follows MOS and proposed changes should be discussed there. Convert puts nbsp in19 kg but a space in19 kilograms because that is whatMOS:UNITNAMES specifies. Thanks Quondum for pointing out that there is no "Wrapping and line breaking" section atHelp:Convert despite there being a link to it atTemplate:Convert#Wrapping and line breaking. It turns out that I removed the section. The original is atOctober 2023. I hoped Help:Convert would focus on common usage examples—how do you doX. 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)[reply]

• Historical note: During a major overhaul ofWP:MOSNUM some ten years ago, the textGuidance 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.EEng15:38, 8 September 2025 (UTC)[reply]

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)[reply]

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

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)[reply]

I'm a stickler for precise wording, but in this case I'd say the current wording is fine. In a sense, a feature that doesn't work or doesn't exist isn't really a feature, but it's common to call Xs that don't quite exist Xs. For example, a film that wasn't finished is still called a film. The latest suggestion "commonly-expected features" would be OK as well, but I think the current wording is a bit easier to understand. —Chrisahn (talk)11:52, 22 October 2025 (UTC)[reply]

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 onModule: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)[reply]

New units are added atModule: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 atModule: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)[reply]

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)[reply]

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)[reply]

It is atHelp:Convert#Ranges. The background is that the MOS requires the behavior thatx implements. (I seem to recall some recent MOS discussions where quite a few people suggested that should be relaxed?) I retainedxx 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)[reply]

So basically I stared right at the documentation and just didn’t see it…. :-( WOW. Thanks for keeping that inJohnuniq! 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)[reply]

How irritating. Another retained but not-standard range is*. I faced a lot of pushback for keeping* andxx and it appears that somewhere the documentation atHelp:Convert was "fixed" to remove what were considered to be deprecated features. I think I must have restoredxx 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)[reply]

An RfC regardingTmcft is atWT:Manual of Style/Dates and numbers#RfC Tmcft in convert template? while previous discussions are atWT:Manual of Style/Dates and numbers/Archive 163#Tmcft andTemplate 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 unitstmcft andTmcft inModule:Convert/extra. The other units in the following table already existed.

Examples:

• {{convert|178.74|tmcft}} → 178.74 tmcft (5.061 km³)
• {{convert|178.74|tmcft|lk=in}} → 178.74tmcft (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)[reply]

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)[reply]

Good solution. For example, I just added{{convert}} for all occurrences of tmfct inSrisailam Dam. Looks good to me. Thanks! —Chrisahn (talk)17:29, 6 October 2025 (UTC)[reply]

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

Search the textlink inTemplate:Convert/doc.EEng02:03, 26 September 2025 (UTC)[reply]

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)[reply]

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

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

I am planning to release a new version soon. The motivation is to introduce parametererror=x which means that convert would either work (anderror=x would have no effect), or would displayx 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 callsModule: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 as1+3/4). The name of a unit can be different if a fractional value is used.

TheOctober 2024 release changed unitsmile andmiles to includeabbr=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)[reply]

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)[reply]

Good points. But why would someone write "liter" if they wanted "l" to be displayed? Maybeliter 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)[reply]

Following the discussion atTemplate talk:Convert#Plans for new version just above, I have updated the module. The changes are:

• Optionerror=x is new. The valuex is any text which may be empty. If no error occurs in the conversion, this option has no effect. Otherwise, the result isx (no error occurs).
• Some projects such asUkrainian Wikipedia use variable names where the unit name can vary depending on the value. That feature now accepts a fraction slash as well as a plain slash in the wikitext for the input value of a fraction (such as1+3/4).

Theerror=x option will be tried at{{Infobox food}} to replace:

{{#iferror:{{convert|{{{calories|}}}|kcal}}|{{{calories|}}}|{{convert|{{{calories|}}}|kcal|lk=on|abbr=on}}}}

with:

{{convert|{{{calories|}}}|kcal|lk=on|abbr=on|error={{{calories|}}}}}

The result of the convert will be displayed if the conversion is successful. Otherwise, thecalories value entered in the infobox will be displayed.

The following examples use fixed wikitext so the outputs won't change in the future.

• {{convert|123|kcal|error=This text has no effect because the conversion works.}} → 123 kilocalories (510 kJ)
• {{convert|123 calories (per biscuit)|kcal|error=This text is displayed instead of an error.}} → This text is displayed instead of an error.
• {{convert|123 calories (per biscuit)|kcal|error=}} →(nothing is displayed)

Johnuniq (talk)07:17, 5 October 2025 (UTC)[reply]

Hello all, I am trying to convert from grams to grains for the biathlon wikipedia page since the governing body uses grams for bullet weight but manufactures use grains. I don't see a grain option. Am I missing something?Jboy Hanny (talk)16:35, 12 October 2025 (UTC)[reply]

The grain is listed atModule:Convert/documentation/conversion data#Mass as having symbol "gr" and name "grain". Is that not working for you?{{convert|1|g|gr}} → 1 gram (15 gr) and{{convert|1|gr|order=flip}} → 0.065 grams (1 gr) seem OK here.NebY (talk)16:43, 12 October 2025 (UTC)[reply]

But {{convert|1|grain|g}} produces

• 1 grainError in convert: Unit name "grain" is not known(help).

So it is real.𝕁𝕄𝔽 (talk)19:38, 12 October 2025 (UTC)[reply]

You can only use units that are explicitly mentioned in the first column of the tables atModule:Convert/documentation/conversion data. At the time that you posted above,grain was not listed in column 1 ofModule:Convert/documentation/conversion data#Mass, so Iadded it as an alias forgr. We now need to wait for a bot to pass by. --Redrose64 🌹 (talk)21:12, 12 October 2025 (UTC)[reply]

Ordo it manually.{{convert|1|grain|g}} → 1 grain (0.065 g). --Redrose64 🌹 (talk)21:23, 12 October 2025 (UTC)[reply]

Aha! My description was sloppy; it's the unit code that matters. But would it be better if the error message was "Unitcode <aaa> is not known"?NebY (talk)21:21, 12 October 2025 (UTC)[reply]

I've checked as much of the conversion template documents as I can find, and maybe I missed it. But, I'm trying to express the sensitivity of someradio frequency receiver systems, but the use of this conversion could easily apply as well to RF transmission systems. Typically, measurements of RF power (received or transmitted) are expressed in eitherdBm or some value ofwatts. Typically, as shown indBm § Table of examples, the two figures can often be found within the same document.

Am I (again) just dense, and the functionality already exists in the template, or would this need new separate code-work to be implemented? If the latter, I'd like to suggest a very wide set of available conversion factors. Some receivers work below −150 dBm, while some transmitters work in themegawatt range (see what I did there?). —TadgStirkland⁴⁰¹(Tadg^Talk-Email)02:50, 20 October 2025 (UTC)[reply]

There is no dB unit in convert. The issue was briefly discussed inJanuary 2024. Please link to a couple of examples wheredBm conversions would be useful (apart from that table). Because the conversion to watts is not a linear scale, convert would need special-case code. Is a conversion template really needed?Johnuniq (talk)03:32, 20 October 2025 (UTC)[reply]

I guess it was wishful thinking. I know the math is not simple. I'm creating an entry on an article where a specific receiver is documented as having sensitivities between −101 to −73 dBm. Rather than having to explain at length the number ofmilliwatts that correlates to, I thought it would be much simpler to use the conversion template. Alas, I'll go the manual route. —TadgStirkland⁴⁰¹(Tadg^Talk-Email)03:47, 20 October 2025 (UTC)[reply]

If a special case is ever added, it would probably make sense to make it work not just for the various dB scales, but also for otherlogarithmic units. I think the configuration for such a unit conversion would have to specify the base of the logarithm and an offset. (Or maybe the base should be split into the base and a factor.) Anyway, I don't know how often such conversions are needed. I guess occasionally for dB and maybe for somewire gauges, but very rarely for theRichter scale orpH. —Chrisahn (talk)04:43, 20 October 2025 (UTC)[reply]

The decibel is not a unit but a ratio; originally a way of expressing the loss (or gain) in the strength of a signal. If you have two signals of different power, both expressed in watts, you can describe the difference in their levels using either watts or decibels. A telephone line might be fed with a 100 W signal, and down the line the power might be measured as 10 W. This is a loss of 90 W, and it is also an attenuation of 10 dB. But that does not mean that 90 watts is equal to 10 decibelsunless you know the initial power level. The watt is an absolute measure; the decibel is a relative measure. There is no direct conversion that is sensible. --Redrose64 🌹 (talk)19:59, 20 October 2025 (UTC)[reply]

That's correct, but there are various special kinds of decibel that measure absolute values on a logarithmic scale, and converting them to/from a linear scale wouldn't be difficult. See the second paragraph ofdecibel:The strict original usage above only expresses a relative change. However, the word decibel has since also been used for expressing an absolute value that is relative to some fixed reference value, in which case the dB symbol is often suffixed with letter codes that indicate the reference value. For example, for the reference value of 1 volt, a common suffix is "V" (e.g., "20 dBV"). dBm is another example. Seedecibel#List of suffixes for more details. —Chrisahn (talk)20:10, 20 October 2025 (UTC)[reply]

As title states, sometimes we'll encounter texts with frequent references to very high, GigaPascal levels of pressure (likethis one on metallic hydrogen), of which a conversion to atmospheric pressure usually consists of bunch of zeros.It might be a good idea to have some multiples of atm / bar to convert to, so the numbers wouldn't hinder one's reading of the text. I suggested MBar simply because it's a unit somewhat frequently used in literature. iris 7:39 (utc+8), edited 7:56海盐沙冰 _{/ aka irisChronomia / Talk}07:39, 22 October 2025 (UTC)[reply]

I suspect that many readers will find the article's 2,500,000 atm far more readable than 2.5 Mbar, an unfamiliar unit which requires more mental gymnastics.NebY (talk)08:12, 22 October 2025 (UTC)[reply]

I agree with NebY but made some notes before seeing that reply. The convert in that article is{{convert|1000000|atm|GPa atm psi|order=out|lk=on|abbr=on}}. According to convert, 1atm = 101,325 pascals while 1bar = 100,000 pascals. Isatm used correctly in that example? If so, it needs Matm which doesn't sound right (name "mega atmosphere"?). Another detail is that convert has unitsdbar andmbar (millibar and decibar) so the unit code should beMbar (lowercaseb). That agrees with a couple of the references which mentionMbar.Johnuniq (talk)08:31, 22 October 2025 (UTC)[reply]

Do we really want to do anything to suggest that thebar is something to be facilitated, that it is a reasonable conversion to add? Asbar (unit) article says:

TheSI brochure, despite previously mentioning the bar,^[1] now omits any mention of it.^[2] The bar has been legally recognised in countries of theEuropean Union since 2004.^[3] The USNational Institute of Standards and Technology (NIST)deprecates its use except for "limited use inmeteorology" and lists it as one of several units that "must not be introduced in fields where they are not presently used".^[4] TheInternational Astronomical Union (IAU) also lists it under "Non-SI units and symbols whose continued use is deprecated".^[5]

(That said, the article does acknowledge that "Mbar" has provenance.)

How does it help readers to introduce a term that is not meaningful in any practical sense at very high pressures?

In summary, how is the requested conversion going to be of help to anyone? The scientific literature doesn't use it. --𝕁𝕄𝔽 (talk) 11:18, 22 October 2025 (UTC)Revised to cut my sidetrack about Jupiter, just distracting and not particularly illuminating. --𝕁𝕄𝔽 (talk)12:04, 22 October 2025 (UTC)[reply]

I agree thatbar is not a meaningfully important unit; the problem is not being able to prefixatm with K/M/G, etc.. I'm thinking of using "spell numbers = on" to write out bi/trillions in plain text, but this seems even less smooth to read so...

I suppose we should just copyedit the text to place all the values into a easier-on-the-eyes format (e.g., table) then.海盐沙冰 _{/ aka irisChronomia / Talk}15:44, 22 October 2025 (UTC)[reply]

When converting from cubic inches to cubic centimetres (or vice-versa), why is the 3 superscripted for cm³ but cubic inches is a simple "cu in" abbreviation? Shouldn't it be consistently in³ instead? —TadgStirkland⁴⁰¹(Tadg^Talk-Email)05:25, 15 November 2025 (UTC)[reply]

A cubic inch is traditionally abbreviated to cu in and that's the convert default. As people become more familiar with scientific notation, in³ gains popularity. Both are available:

• {{cvt|123|cuin}} → 123 cu in (2,020 cm³)
• {{cvt|123|cm3}} → 123 cm³ (7.5 cu in)
• {{cvt|123|in3}} → 123 in³ (2,020 cm³)
• {{cvt|123|cm3|in3}} → 123 cm³ (7.5 in³)

Johnuniq (talk)05:37, 15 November 2025 (UTC)[reply]

Thank you. I didn’t see “in3” in the documentation; musta missed it. —TadgStirkland⁴⁰¹(Tadg^Talk-Email)05:47, 15 November 2025 (UTC)[reply]

Somewhere the doc mentions that the full list of units is atModule:Convert/documentation/conversion data.Johnuniq (talk)08:17, 15 November 2025 (UTC)[reply]

@Johnuniq, thank you for all your help. I've done some more digging through the docs hoping to find similar treatment of ft³, but no such luck. So, I tried experimenting. When I try{{cvt|123|ft3}}, I'm not seeing the desired result. Instead, I see → 123 cu ft (3.5 m³). When you made the comment "A cubic inch is traditionally abbreviated to cu in", I didn't challenge that. But, if you take a look at the second page ofthis technical document, it is very common in similar documents to see the ft³ annotation style. I'm not sure if it is an American/British thing, or sceintific/engineering thing, or what... But in my many years of electrical/electronic engineering, it is the most common I've ever seen. You've been very helpful and patient. Is there some trick I am missing to get the desired affect? —TadgStirkland⁴⁰¹(Tadg^Talk-Email)03:28, 18 November 2025 (UTC)[reply]

No, there is no trick. Convert defines these aliases:ft3 =cuft,yd3 =cuyd,mi3 =cumi. That means the3 version will produce exactly the same result as thecubic version. Convert has been around a long time and these units are more than 13 years old. One or all of them could be changed but someone would need to first try to find a couple of cases where they are used in articles and see what result should occur in those articles. For example,Columbia River has dozens of converts such as{{cvt|550,000|cuft/s|m3/s|abbr=on}} but also three like{{cvt|12,100|ft3/s|m3/s|abbr=on}} (the|abbr=on is pointless and should be removed, see{{cvt}}). It would look odd if the article suddenly started showing ft³ for three results. However, Wikipedia thrives on change and a discussion here and maybe somewhere else would agree that ft3 and possibly the others should be changed. Is there a particular article where the current behavior is undesirable?Johnuniq (talk)05:22, 18 November 2025 (UTC)[reply]

Thanks for the quick reply and validation. There are several military electronic system articles that state volume measurements for the device/system. Referring to the technical document I described above, you can see its application inAN/ALQ-126 § Characteristics. Looking around in theCategory:Military electronics of the United States listings, I've run across several with varying degrees of use (some simply type it out without using the{{convert}} template). But, specifically using technical documents found on theForecast International listing, many if not most of the documents there use the same kind of notations. Like I said before, it is very common especially in technical manuals and other documents (not just on Forecast International). I'd love to see a hardy conversation about it. Is this the right venue, or is the one better? —TadgStirkland⁴⁰¹(Tadg^Talk-Email)06:16, 18 November 2025 (UTC)[reply]

OK. Let's see if anyone here wants to add thoughts. The proposal is thatft3, when abbreviated, would display ft³ instead of cu ft. What about aboutyd3 andmi3?Johnuniq (talk)07:09, 18 November 2025 (UTC)[reply]

I would advocate allowing if not defaulting to the superscript numeral for inches, feet, and yards. This notation is taught in secondary school, and I think Americans should generally know what it means, even if everyday vendors like Home Depot often use the more old-fashioned "sq. ft." and "cu. yd." Square and cubic US units are always used right next to metric units, and the different notation is a bit awkward. The superscripts are more compact, which I think would be good for infoboxes and tables and other places where space is limited. The "sq" and "cu" notation is allowed but not required byMOS:UNITSYMBOLS, which means we already have both on English Wikipedia. If US readers were too confused by the superscript notation, it would probably have been banned. --Beland (talk)00:57, 19 November 2025 (UTC)[reply]

Guinness323 points out that lengths between 1 cm and 1 m are typically given in cm, but the conversion from inches defaults to mm. This has come up in articles about board games (such as1812: The Campaign of Napoleon in Russia, where they added the "cm" parameter), though I have also added the "cm" parameter while doing conversions for paintings, plants, magnetic tape, and possibly other topics. I might prefer millimeters when fractions of an inch are given and the conversion actually does need tenth-of-centimeter precision, but when distances are going to be rounded to the nearest centimeter anyway, centimeters are more natural, take up less space, and more clearly show the number of significant digits. Would it be possible to make cm the default for lengths 1 cm to 1 m which are rounded to the nearest cm? --Beland (talk)03:46, 20 November 2025 (UTC)[reply]

And higher than 1-2 meters should probably be in meters if rounded to the nearest meter or tenth of a meter; decimeters are not generally used. --Beland (talk)03:49, 20 November 2025 (UTC)[reply]

Currently,cm defaults toin butin defaults tomm. It would be easy to makein default tocm if the inch input value is between certain limits, or tomm otherwise. The limits might be between 0.393 and 39.4 inches (1 cm = 0.3937 in and 1 m = 39.37 in). However, there is no way to do that if the value rounds to an integer number of cm. Also, there is no way to have more than two defaults. The change might be desirable for particular articles but it's hard to say whether it would be helpful more widely. I think a few thousand articles have conversions from inches to the default so working out what would be best would be tricky.Johnuniq (talk)05:12, 20 November 2025 (UTC)[reply]

I'm sceptical thatlengths between 1 cm and 1 m are typically given in cm. In UK engineering, at any rate, the "recommended multiples and submultiples are the kilometre (m), the millimetre (mm) and the micrometre (μm). The centimetre (cm) and decimetre (dm) should be used only when the recommended prefixes are inconvenient."(Kempe's Engineers Year-Book, 1991, pA1/3).NebY (talk)10:30, 20 November 2025 (UTC)[reply]

It varies wildly according to country and application. For example, in Australia were measure our height and belt size in cm but cars and building floor plans are in mm. You will never find a universal solution but the current defaults are good enough for many applications. Articles can override it if they don't like the default. Stepho  talk 12:56, 20 November 2025 (UTC)[reply]

I was curious and so did a database scan for template instances converting from inches to the default units. It looks like there's about 1,500 template instances where inches are specified to the tenth or finer, and about 10,000 to the nearest inch (of which only about 200 are 100 inches or more).

I was going to say inches aren't generally used in engineering, but for our articles we have them for military artifacts, railroads, vehicles, and weather (which is scienced instead of engineeered).

I'm sure we could add code to the module that changes the default selectively, but it sounds like the easier and more reliable thing to do is add "|cm" as needed. Thanks for helping me think this through! --Beland (talk)04:09, 21 November 2025 (UTC)[reply]

• Lua-based templates