Template talk:Convert#Correcting mi/d unit name

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, see rounding. Note: This can cause whole numbers that end in one or more zeroes to be converted less accurately than expected. Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)? A: See Help:Convert units for an introduction and Module:Convert/documentation/conversion data for the complete list. Q: I've been using Convert for some time and am pretty comfortable with its basic features. Does it have other features which it would be worth my while to learn about? A: Almost certainly. Start with Help:Convert. For more, see the FAQ.

Template:Convert is permanently protected from editing as it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories. Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

Archives

Archive 1 Archive 2 Archive 3

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

Related pages
Template (talk) Template sandbox Template testcases Template doc Template subpages Module (talk) Module sandbox Module testcases Module doc Module subpages

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 to Help: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]

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

Search the text link in Template:Convert/doc. EEng 02: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. EEng 07: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 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)[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? 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)[reply]

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

• Option error=x is new. The value x is any text which may be empty. If no error occurs in the conversion, this option has no effect. Otherwise, the result is x (no error occurs).
• Some projects such as Ukrainian 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 as 1+3/4).

The error=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, the calories 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 at Module: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 at Module:Convert/documentation/conversion data. At the time that you posted above, grain was not listed in column 1 of Module:Convert/documentation/conversion data#Mass, so I added it as an alias for gr. We now need to wait for a bot to pass by. --Redrose64 🌹 (talk) 21:12, 12 October 2025 (UTC)[reply]

Or do 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 "Unit code <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 some radio 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 either dBm or some value of watts. Typically, as shown in dBm § 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 the megawatt 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 in January 2024. Please link to a couple of examples where dBm 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 of milliwatts 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 other logarithmic 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 some wire gauges, but very rarely for the Richter scale or pH. — 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 decibels unless 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 of decibel: 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. See decibel#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 (like this 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, 1 atm = 101,325 pascals while 1 bar = 100,000 pascals. Is atm used correctly in that example? If so, it needs Matm which doesn't sound right (name "mega atmosphere"?). Another detail is that convert has units dbar and mbar (millibar and decibar) so the unit code should be Mbar (lowercase b). That agrees with a couple of the references which mention Mbar. Johnuniq (talk) 08:31, 22 October 2025 (UTC)[reply]

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

The SI brochure, despite previously mentioning the bar,^[1] now omits any mention of it.^[2] The bar has been legally recognised in countries of the European Union since 2004.^[3] The US National Institute of Standards and Technology (NIST) deprecates its use except for "limited use in meteorology" and lists it as one of several units that "must not be introduced in fields where they are not presently used".^[4] The International 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 that bar is not a meaningfully important unit; the problem is not being able to prefix atm 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 at Module: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 of this 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 the 3 version will produce exactly the same result as the cubic 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 in AN/ALQ-126 § Characteristics. Looking around in the Category: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 the Forecast 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 that ft3, when abbreviated, would display ft³ instead of cu ft. What about about yd3 and mi3? 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 by MOS: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]

I gotta wonder, has this conversation died on the vine? Only one supporting comment more than a couple weeks ago… Is there any suggestion to stir more discussion? — TadgStirkland⁴⁰¹(Tadg^Talk-Email) 05:37, 15 December 2025 (UTC)[reply]

Investigating my above 05:22, 18 November 2025 comment regarding Columbia River would be a good start. Johnuniq (talk) 06:11, 15 December 2025 (UTC)[reply]

What sort of "investigation" of Columbia River did you need to happen? The article is already inconsistent because someone wrote "ft³/s" directly in wikitext. I changed all the "cuft" instances in the convert template calls to "ft3" so things would match, but of course they don't because we haven't made the proposed change. -- Beland (talk) 06:34, 15 December 2025 (UTC)[reply]

Looking at the 2025-12-01 database dump, I find 9657 articles using {{cvt}} or {{convert}} and "cuft" or "ft3" in the wikitext. Of those, 7717 use "cuft", 2140 use "ft3", and 208 use both (overlapping counts).

I find 293 articles that use "cu ft" or "cu. ft" without a template, and 343 that use "ft³" without a template. 7 articles do both. 16 of the articles that use "cu ft" or "cu. ft" without a template also use "ft3" in a template.

If we are concerned about mixed usage in the same article looking weird, I could easily take a day and use JWB to make those (208 + 7 + 16 = 231 -> uniq -> 227) articles use only one format or the other (though I guess it would only matter for abbreviated formats since "cubic feet" is the correct translation of "ft³" into words). If we want to 100% change over to ft³, I'd be happy to instead spend that day with JWB to convert the 293 articles that would otherwise be mismatched to use a template. -- Beland (talk) 09:33, 15 December 2025 (UTC)[reply]

I would appreciate some work on deciding if anything needs to be done as a consequence of a change like this. It doesn't have to be more than a bit of thought. There is a proposal at Module talk:Convert to modify how the Mach conversions are done. That's just a tweak which won't have any significant changes other than making the numbers a little more accurate. At the moment, it needs more work (see my comments at the bottom of the page). However, it's likely we'll sort that out in a week and that would be a good time to change units like ft3 to show exponents. Unit in3 already shows an exponent so the proposal is to change ft3, yd3 and mi3 to also show exponents for the abbreviated unit. I'll do some work on that soon. Johnuniq (talk) 10:01, 15 December 2025 (UTC)[reply]

Are you asking what needs to be done as a consequence in articles, or in module code? -- Beland (talk) 10:11, 15 December 2025 (UTC)[reply]

Articles: can anyone see cases where this change would give a bad result. I would think the answer is no, but it's good to look. Johnuniq (talk) 10:52, 15 December 2025 (UTC)[reply]

I will go through the articles I identified, make preparatory changes to avoid mismatches, and watch out for any unexpected issues. I assume the conversion output in general has no problems with Wikipedia:COinS#Pollution? -- Beland (talk) 22:37, 15 December 2025 (UTC)[reply]

I see that Template:Val has similar behavior for cubic units, so it would be good to update that at the same time. I also realized I should go through and scan pages that use cubic inches, yards, and miles. -- Beland (talk) 00:03, 16 December 2025 (UTC)[reply]

Ah, also e6cuft, e9cuft, e12cuft, etc. -- Beland (talk) 00:04, 16 December 2025 (UTC)[reply]

And Gft3 etc. -- Beland (talk) 00:07, 16 December 2025 (UTC)[reply]

OK, it turns out kft3, Mft3, Gft3, and Tft3 codes aren't implemented in the template, but the _cuft equivalents are. Metric prefixes aren't used with US customary units, both by the Wikipedia style guide and in general. Maybe it would be best to drop them; I can convert articles to use e_cuft or e_ft3 equivalents (and same for in, yd, and mi)? -- Beland (talk) 04:55, 16 December 2025 (UTC)[reply]

Re the "proposed for deprecation" units in the collapsed list below, Mft3 is an alias for e6cuft. I can only find one usage of Mft3, namely at Anaconda Smelter Stack#Construction which has {{convert|3-4|Mft3|m3}} → 3–4 million cubic feet (85,000–113,000 m³). That works well. A lot of digging would be needed to investigate properly. One thing that makes me avoid large refactoring of units is that significant changes give broken displays for anyone investigating old revisions of articles. That's not of much importance but it is something to consider. I think that the proposal is to change ft3 + yd3 + mi3 to show superscripts rather than "cu" in the symbols. That's all? Johnuniq (talk) 04:49, 17 December 2025 (UTC)[reply]

How do you feel about also doing ft2, yd2, and mi2? -- Beland (talk) 04:55, 17 December 2025 (UTC)[reply]

I stand corrected on some of what I said above; some of the things I thought needed fixing are already working correctly, and some of the things I thought are working are actually unimplemented. Below is a long list showing the status of everything that seems relevant.

Also, some square units have the same problem as cubic units. -- Beland (talk) 05:17, 16 December 2025 (UTC)[reply]

When abbreviated, in2 shows in². For consistency with the above cubic discussion, I propose changing units ft2, yd2, mi2 to similarly show superscripts. They currently show sq ft, sq yd, sq mi. Any problems with that? Johnuniq (talk) 06:17, 17 December 2025 (UTC)[reply]

If I have a vote, I certainly like the proposal. Squares of the units are very typically expressed with exponent notation, unless discussing construction industry activity. When discussing the area of a city or town, the notation is normally with the exponent. For some reason, construction engineering typically seems to use the abbreviated “sq” instead of — TadgStirkland⁴⁰¹(Tadg^Talk-Email) 00:50, 18 December 2025 (UTC)[reply]

I've finished converting articles that have a mix of styles for cubic units to use the exponent style in convert/cvt template parameters, so they will be consistent when the change goes live.

There are 10,507 articles which use an inconsistent style for square units, which is not feasible to fix in a day or two. I think it's fine if the change goes live for square units now; maybe editors seeing inconsistent notation will pitch in to help. Most likely, no one will notice, because both notations are valid. I'm sure there are also articles that are currently only inconsistent because the templates are not generating the exponent format when expected, so it's unclear how much of a downside there really even is. I'll probably have things completely consistent for the first time in a few weeks either way. -- Beland (talk) 04:20, 18 December 2025 (UTC)[reply]

Thanks for all that work. I'll make it all live soon. Johnuniq (talk) 04:29, 18 December 2025 (UTC)[reply]

These changes are now in the sandbox and will be live soon. Examples:

• {{cvt/sandbox|1|in2}} → 1 in² (6.5 cm²)
• {{cvt/sandbox|1|ft2}} → 1 ft² (0.093 m²)
• {{cvt/sandbox|1|yd2}} → 1 yd² (0.84 m²)
• {{cvt/sandbox|1|mi2}} → 1 mi² (2.6 km²)
• {{cvt/sandbox|1|in3}} → 1 in³ (16 cm³)
• {{cvt/sandbox|1|ft3}} → 1 ft³ (0.028 m³)
• {{cvt/sandbox|1|yd3}} → 1 yd³ (0.76 m³)
• {{cvt/sandbox|1|mi3}} → 1 mi³ (4.2 km³)

Johnuniq (talk) 06:34, 18 December 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 as 1812: 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 to in but in defaults to mm. It would be easy to make in default to cm if the inch input value is between certain limits, or to mm 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 that lengths 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]

I've moved the TemplateData from Template:Convert/doc to a dedicated subpage, Template:Convert/TemplateData, so that it can be transcluded to Template:Convert abbreviated/doc as well. Let me know if I messed anything up :) YuniToumei (talk) 12:46, 11 December 2025 (UTC)[reply]

As you can see here, the plural 0 foot-pounds force (0 J) doesn't convert correctly - "foot-pound" is not being treated as an adjective modifying force and is instead being treated as a countable noun. The correct term should theoretically be 0 foot-pound force, but foot-pound force is not a term actually used by anyone. If the module's assumption is going to hold that ftlbf means the unit that converts to Joules rather than the unit that converts to Newton-meters, the most common terms in actual use are either the unambiguous "foot-pounds of energy" or the extremely ambiguous "foot-pounds" and leaving it up to the reader to figure out which kind of foot-pound is meant. I am not well-versed enough in proper WP style to recommend foot-pound force vs. foot-pounds of energy, but food-pounds force as it currently works is right out. Note that this is a particularly messy case if you go to fix the module: 0 foot-pounds (0 J) is correct, because without the word "force", "foot-pound" is a countable noun. Quindraco (talk) 19:11, 13 December 2025 (UTC)[reply]

The full list of units is here. Relevant units (not counting aliases) are:

Energy: ftlb, ftlb-f, ftlbf.

Torque: lb-fft, lb.ft, lbfft, lbft.

Example values with the units mentioned in the OP:

• {{convert|0|ftlbf}} → 0 foot-pounds force (0 J)
• {{convert|0|ftlb}} → 0 foot-pounds (0 J)
• {{convert|1|ftlbf}} → 1 foot-pound force (1.4 J)
• {{convert|1|ftlb}} → 1 foot-pound (1.4 J)
• {{convert|2|ftlbf}} → 2 foot-pounds force (2.7 J)
• {{convert|2|ftlb}} → 2 foot-pounds (2.7 J)

I'm not sure if convert can really cope with all quirks. Is there an article where the current behavior is a problem? Johnuniq (talk) 04:38, 14 December 2025 (UTC)[reply]

I see Foot-pound (energy) uses both "foot-pound force" and "foot pound-force" and also mentions "foot-pounds of energy" as a way to clarify "foot-pounds". Since the definition is a displacement of one foot against the force of one pound (one pound-force), "foot pound-force" or "foot-pound-force" makes sense. Searching on Duck Duck Go, it looks like "foot pound-force" is a typo for "foot-pound force". I don't quite understand the grammatical point being made. If it's not pluralized as "2 feet pound-force" or "2 foot-pound forces", then it seems foot-pound is a countable noun. Something has to be, or else we wouldn't be able to specify a number and we wouldn't have a unit of measure.

It does seem like "foot-pound" is the more common term, though I never encounter this personally. If it were to be changed, I think "of energy" would be clear from the fact that the quantity is being converted to (or from) joules, so "force" could just be dropped. -- Beland (talk) 10:00, 15 December 2025 (UTC)[reply]

If someone doesn't want "force", they should not use the units with "f" at the end (there are several of them). Those variations were created 15 or more years ago to accommodate people who wanted different styles and I don't think it's worth worrying about now unless the OP can identify an article where there is a clear problem with no easy work around (you don't really need a template to convert a zero value). Johnuniq (talk) 01:07, 16 December 2025 (UTC)[reply]

Could we get a conversion added between 24-hour time and am-pm time? I don't see anything at Module:Convert/documentation/conversion data#Time that handles conversion of hour of the day between these two time units.

Here is an example sentence, from the lead of France Télévisions:

When advertising after 20:00 was abolished on France Télévisions in 2009, the French government initially planned to extend the ban to all daytime advertising. However, this measure was never implemented.

I would like to see this displayed as:

When advertising after 20:00 (8 p.m.) was abolished...

Notes:

• MOS:TIME (alias: MOS:AMPM) supports both 24-hour time and am-pm for use in articles. For am-pm style, periods are optional: '8 pm' or '8 p.m.' are both okay.
• as the output is short, I think nowrapping it would be beneficial (or use no-break space).
• some ideas for units: 24hr, am-pm; and aliases: 24hour, ampm. Note that this is not a time zone issue, so terms like zulu and UTC are not appropriate here.
• 0-minute reduction: when minutes value is 00, then drop minutes by default when converting to am-pm; i.e., 20:00 ⟶ 8 p.m., but 20:05 ⟶ 8:05 p.m. (maybe with a param to force the long version, as some contexts with multiple conversions may require this).

Data:

Some data on current usage patterns:

Thanks, Mathglot (talk) 20:11, 15 December 2025 (UTC)[reply]

Not a conversion of one unit to another; feet to meters, for example. 12-hour time to 24-hour time is merely a formatting issue.

—Trappist the monk (talk) 01:16, 16 December 2025 (UTC)[reply]

Convert's time units are really for rates (something per second converted to something else per hour). Converting 24-hour to/from am-pm would require a bunch of special code in convert—code that would be unrelated to other functions. I think that code should be in a dedicated template/module. I have some date/time modules (User:Johnuniq/index#Age/date) and maybe they could help although at first thought I don't see how. Maybe WT:Lua or WP:Requested templates? I have to do a bunch of stuff I have been putting off but could help later. Johnuniq (talk) 01:17, 16 December 2025 (UTC)[reply]

The {{#Time}} parser function 12 → 24:

{{#time:H:i|8 PM}} ({{#time:g:ia|8 PM}}) → 20:00 (8:00pm)

{{#time:g:ia|8 PM}} ({{#time:H:i|8 PM}}) → 8:00pm (20:00)

and similarly 24 → 12 (HH:MM format required):

{{#time:H:i|20:00}} ({{#time:g:ia|20:00}}) → 20:00 (8:00pm)

{{#time:g:ia|20:00}} ({{#time:H:i|20:00}}) → 8:00pm (20:00)

—Trappist the monk (talk) 01:44, 16 December 2025 (UTC)[reply]

Thanks, that's perfect; that could be easily copied into a template. Now we just have to think of a good name for the template(s). The parameter can probably just be unnamed. What about, {{Clock to military}} and {{Military to clock}}? Mathglot (talk) 06:09, 16 December 2025 (UTC)[reply]

Calling 24-hour time "military time" would be americentric - it's simply "time" in most of the world. {{24h to 12h}} and vice versa would be better.  Mr.choppers | ✎  05:45, 17 December 2025 (UTC)[reply]

Is there a way to set the spelling to American English? There are some articles that are written using American spelling but also use metric units. In such cases, it would be helpful to have the template output "kilometers" or "meters" rather than "kilometres" and "metres". Krisgabwoosh (talk) 21:59, 16 December 2025 (UTC)[reply]

See Template:Convert#Words. Indefatigable (talk) 23:17, 16 December 2025 (UTC)[reply]

Evidently, I cannot read. Cheers! Krisgabwoosh (talk) 02:47, 17 December 2025 (UTC)[reply]

Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.

• Module:Convert • Module:Convert/sandbox • different (diff)
• Module:Convert/data • Module:Convert/data/sandbox • different (diff)
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • different (diff)
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content
• Unit grain was added as an alias for gr in October 2025 (discussion).
• Currently, when abbreviated, unit cuin shows cu in and unit in3 shows in³.
• Units ft3, yd3, mi3 will similarly show superscripts when abbreviated (discussion).
• Similarly, when abbreviated, in2 shows in²; units ft2, yd2, mi2 will change to show superscripts.
• Module:Convert/extra includes units tmcft and Tmcft which will be moved to Module:Convert/data (discussion).
• The extra unit per-km2 is unused and will be removed discussion.
• Module:Convert will include code for interpolation when reading from a table of altitude/speed. That will give a minor improvement for conversion accuracy with the Mach unit (by COArSe D1RTxxx; discussion).

Johnuniq (talk) 06:04, 18 December 2025 (UTC)[reply]