Template talk:Convert

Template:Convert

... in conception

... and in reality

Cubic notations

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)

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)

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

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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

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)

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)

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

Test cases

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)

Square and cubic US unit test cases

These should all have exponents instead of "sq" or "cu":

• 1 in² (6.5 cm²)
• 1 ft² (0.093 m²)
• 1 yd² (0.84 m²)
• 1 mi² (2.6 km²)
• 1 in³ (16 cm³)
• 1 ft³ (0.028 m³)
• 1 yd³ (0.76 m³)
• 1 mi³ (4.2 km³)
• 1×10^³ in² (6,500 cm²)
• 1×10^⁶ in² (6,500,000 cm²)
• 1×10^⁹ in² (6.5×10⁹ cm²)
• 1×10^¹² in² (6.5×10¹² cm²)
• 1×10^³ ft² (93 m²)
• 1×10^⁶ ft² (93,000 m²)
• 1×10^⁹ ft² (93,000,000 m²)
• 1×10^¹² ft² (9.3×10¹⁰ m²)
• 1×10^³ yd² (840 m²)
• 1×10^⁶ yd² (840,000 m²)
• 1×10^⁹ yd² (840,000,000 m²)
• 1×10^¹² yd² (8.4×10¹¹ m²)
• 1×10^³ mi² (2,600 km²)
• 1×10^⁶ mi² (2,600,000 km²)
• 1×10^⁹ mi² (2.6×10⁹ km²)
• 1×10^¹² mi² (2.6×10¹² km²)
• 1×10^³ in³ (16,000 cm³)
• 1×10^⁶ in³ (16,000,000 cm³)
• 1×10^⁹ in³ (1.6×10¹⁰ cm³)
• 1×10^¹² in³ (1.6×10¹³ cm³)
• 1×10^³ ft³ (28 m³)
• 1×10^⁶ ft³ (28,000 m³)
• 1×10^⁹ ft³ (28,000,000 m³)
• 1×10^¹² ft³ (2.8×10¹⁰ m³)
• 1×10^³ yd³ (760 m³)
• 1×10^⁶ yd³ (760,000 m³)
• 1×10^⁹ yd³ (760,000,000 m³)
• 1×10^¹² yd³ (7.6×10¹¹ m³)
• 1×10^³ mi³ (4,200 km³)
• 1×10^⁶ mi³ (4,200,000 km³)
• 1×10^⁹ mi³ (4.2×10⁹ km³)
• 1×10^¹² mi³ (4.2×10¹² km³)

These were never and should not be implemented (metric prefixes):

• 1 kin2
• 1 kin3
• 1 Min2
• 1 Min3
• 1 Gin2
• 1 Gin3
• 1 Tin2
• 1 Tin3

• 1 kft2
• 1 kft3
• 1 Mft2

• 1 Gft2
• 1 Gft3
• 1 Tft2
• 1 Pft3

• 1 kyd2
• 1 kyd3
• 1 Myd2
• 1 Myd3
• 1 Gyd2
• 1 Gyd3
• 1 Tyd2
• 1 Tyd3

• 1 kmi2
• 1 kmi3
• 1 Mmi2
• 1 Mmi3
• 1 Gmi2
• 1 Gmi3
• 1 Tmi2
• 1 Tmi3

• 1 kcuin
• 1 kcuin
• 1 Mcuin
• 1 Mcuin
• 1 Gcuin
• 1 Gcuin
• 1 Tcuin
• 1 Tcuin
• 1 kcuyd
• 1 kcuyd
• 1 Mcuyd
• 1 Mcuyd
• 1 Gcuyd
• 1 Gcuyd
• 1 Tcuyd
• 1 Tcuyd
• 1 kcumi
• 1 kcumi
• 1 Mcumi
• 1 Mcumi
• 1 Gcumi
• 1 Gcumi
• 1 Tcumi
• 1 Tcumi
• 1 ksqft
• 1 Msqft
• 1 Gsqft
• 1 Tsqft
• 1 Psqft

These are proposed for deprecation (metric prefixes):

• 1×10^⁶ cu ft (28×10^³ m³)
• 1×10^¹² cu ft (28×10^⁹ m³)
• 1×10^³ cu ft (28 m³)
• 1×10^⁶ cu ft (28×10^³ m³)
• 1×10^⁹ cu ft (28×10^⁶ m³)
• 1×10^¹² cu ft (28×10^⁹ m³)
• 1×10^¹⁵ cu ft (28×10^¹² m³)

Square notations

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)

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)

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)

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

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)

Looks good across the test cases above! Sounds like we're keeping the mixed metric prefixes + US units for the benefit of old revisions? -- Beland (talk) 16:46, 18 December 2025 (UTC)

I believe you mean the "proposed for deprecation" examples in #Test cases. That has {{cvt|1|Mft3}} but my recollection is that Mft3 was intended for not abbreviated cases where it shows "million": {{convert|1|Mft3}} → 1 million cubic feet (28×10^³ m³). That works well. I don't think it's worth the potential hassle both here and at other projects that use convert to remove that small handful. There are sure to be some uses on some pages, even if not in current revisions of articles. Johnuniq (talk) 23:29, 18 December 2025 (UTC)

Inches to cm vs. mm

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)

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)

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)

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)

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)

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)

TemplateData

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)

Foot-pounds of energy (ftlbf) don't convert properly

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)

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)

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)

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)

24-hour time to am-pm

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:

• 765 at 8pm, 4 at 8p.m.– even hour, no space (with and without periods)
• 166 at 8pm, 3 at 8p.m. – even hour, no space (non-television context)
• 237 at 8:30pm, 1 at 8:30p.m. – half hour, no space
• 40 at 8:30pm, 0 at 8:30p.m. – half hour, no space (non-tv)
• 341 at 8 pm, 675 at 8 p.m. – even hour, space
• 106 at 8pm, 187 at 8 p.m. – even hour, space (non-tv)
• 231 at 8:30 pm, 75 at 8:30 p.m. – half hour, space
• 34 at 8:30 pm, 13 at 8:30 p.m. – half hour, space (non-tv)

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

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)

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)

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)

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)

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)

Spelling

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)

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

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

It would be awesome if {{convert}} honoured {{Use American English}}. Elrondil (talk) 06:53, 11 January 2026 (UTC)

I'm not a fan of the hacks that read the wikitext of the whole page, then try to parse it looking for some template. If Scribunto (the MediaWiki software that supports modules) had a way of storing per-page information that any template/module could quickly read, I would be glad to make convert use that system. Or (more achievable), there could be an agreed single module that does nothing except generate a table of page information (such as US or UK spelling), and any template/module wanting page information could use that module. If that were available, I would have convert use it. But the current fashion of having a handful of "invented here" solutions is peak madness. An advantage of a central module is that a single table could be created when all templates/modules are invoked to display a page, and a module could access the table with loadData which would mean the wikitext would be read and parsed once per page. Convert is different from most other templates in that it is sometimes used over a hundred times on one page and loadData would be required to make that work. Johnuniq (talk) 07:57, 11 January 2026 (UTC)

Module version 32

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 • same content
• 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)

Is there a way to make per-units use negative exponents (like "kg m s⁻²")? — COArSe D1RTxxx (talk) 23:23, 18 December 2025 (UTC)

Convert can do funky things like this:

• {{cvt|2|L/m2/s}} → 2 L/m²/s (2.5 imp gal/sq ft/min)

However, there are no units which display like your example due to two factors. First, such units would not be useful (and would be too mysterious) in general articles. Second, where such units are wanted in scientific topics, they don't want a conversion to other units. Science topics can use {{val}} which can display values/units with no conversion. Johnuniq (talk) 23:37, 18 December 2025 (UTC)

Modules have been updated. Johnuniq (talk) 03:51, 19 December 2025 (UTC)

round=1

Supporting |round=1 would be nice. For an infrequent user of the {{convert}} template, the gap in the supported values of |round= is conspicuous and frustrating. The currently supported values are 0.5 or 5 or 10 or 25 or 50, but not 1. Rounding the output to an integer is a very natural thing to want to do, and it took me a while to figure out that I could accomplish {{convert|19|x|15|km|round=1}} by using {{convert|19|x|15|km|0}}. I see that |round=10 is supported although it seems arguably unnecessary, so why not also support |round=1? —⁠ ⁠BarrelProof (talk) 15:43, 5 January 2026 (UTC)

Seeing as that convert will be updated soon, I think this proposal may as well be implemented. Any thoughts? Johnuniq (talk) 06:04, 12 January 2026 (UTC)

I don't want to distract from my basic suggestion, but since you asked, I have two further comments: 1) I don't really understand the special usefulness of |round=0.5, and 2) Why not let arbitrary values of |round= be used? For example, |round=0.25, |round=0.125, |round=0.03125, |round=0.1, |round=0.01, |round=0.001, and |round=0.2. Perhaps any value that can be multiplied by an integer to become equal to 1 and any value that is a multiple of 1? I realize that's a bit adventurous, but there you have it. —⁠ ⁠BarrelProof (talk) 07:35, 12 January 2026 (UTC)

Someone else might like to take that on but convert has been the way it is for over 15 years and this is the first I recall seeing a suggestion for an arbitrary round. That is, there would need to be a strong demonstrated need to justify the time/complexity to implement that scheme. Johnuniq (talk) 08:36, 12 January 2026 (UTC)

Like |round=1 and |round=10, |round=0.1, |round=0.01, |round=0.001, |round=100, etc., would be alternative ways of expressing existing cases. For example, {{convert|19|x|15|km|round=0.001}} would be equivalent to {{convert|19|x|15|km|3}}. In my personal opinion, |round=0.001 is more intuitive. —⁠ ⁠BarrelProof (talk) 16:37, 12 January 2026 (UTC)

It was a while ago so don't remember the exact context, but I have encountered a least one situation where round=50 would have been good to have. Thryduulf (talk) 21:07, 17 January 2026 (UTC)

round=50 has been supported for a while. Johnuniq (talk) 03:05, 18 January 2026 (UTC)

Convert from multiple formats to a single one

Hi, I have this code - 66 by 10 by 5 inches (1.68 m × 0.25 m × 0.13 m) - in an article, how do I change it so the first term is "5ft 6in" but the second and third are just inches? Thanks, Anothersignalman (talk) 09:33, 8 January 2026 (UTC)

Template:Convert#About feet, inch in ranges and multiples. --Redrose64 🌹 (talk) 22:19, 8 January 2026 (UTC)

Ah OK, so if I wanted something with mixed units I'd need to use mm then flip it. That basically works, thanks :) Anothersignalman (talk) 02:03, 9 January 2026 (UTC)

Electronvolt eV scale changed

Posted an edit request for Module:Convert/data to that module's talk page, per Wikipedia policy, requesting that the data value for "scale" under "eV" be corrected to its correct value. Johnuniq requested that I crosspost to here, so I am doing so. Original edit request is here: Module_talk:Convert#Template-protected_edit_request_on_10_January_2026 Note that this is not an edit request for this template. As of this post, the edit to eV's scale in Module:Convert/data was done, but it did not propagate to additional eV-based units, because the Module tracks them independently in its data, which I did not know when I made the request. Since Johnuniq wants the discussion to happen here, I will post the list of still-broken scales here. Values are case sensitive and listed in the order they appear in the data.

These units are the same unit to a different power of 10, so the exact same change in the 3 least significant digits needs to be propagated:

• feV
• GeV
• keV
• MeV
• meV
• neV
• PeV
• peV
• TeV
• μeV

There are additional units which confuse me, so here are my best guesses:

• eVpar: This unit has no discussion on its linked article page, which is the one for the electronvolt. I think this is eV per atom or molecule and hence is doubly incorrect, as it is currently using 1.602176565e-19 * 6.022140857e23, which is an incorrect value for eV (it matches neither the correct value nor the value eV just had that the list above still mimics) multiplied by an incorrect value for Avogadro's constant. If I am right, the current value of 96485.329522144166 should be replaced with 1.602176634e−19 × 6.02214076×10e23 = 96485.3321233100184.
• keVT: I have no idea why the eVT is absent but the keVT is present, but thankfully the electronvolt article seems to discuss this mysterious unit, which for keVT is keV scale divided by the Boltzmann constant and is for using the word "electronvolt" to refer to temperature. This unit currently has the scale 11.604505e6, which contradicts the article (that it links to!). The correct value should be 11604518.12155008260607873544, as I understand it.

I did not see any other units with the word "electronvolt" anywhere in their name, so I don't know what other units that depend on the eV for their value are hard-coded in and hence need to be changed as well.

In terms of how this template behaves, I believe I should point out that the above list of SI prefixed eV values contradicts the current documentation here, Template:Convert/doc#Numbers, which specifies that all SI prefixes should automatically work by applying a simple multiplication. For example, right now you can't convert EeV because it's not hardcoded in as anything, even though the documentation claims you can. Perhaps the documentation should be modified, unless someone really wants to hardcode in every prefix from quecto to quetta for every unit, which will make this problem and ones like it worse now and in the future.Quindraco (talk) 21:27, 11 January 2026 (UTC)

The value of the electronvolt published in SI Brochures[1] - and I presume in CODATA - has changed every few years. Can we reasonably expect it to change again, and are there any consequences for the integrity of our articles if old values in them are converted to or from eV differently from the conversions when the values were added to the articles? NebY (talk) 21:53, 11 January 2026 (UTC)

That's an interesting point. I'm happy to leave it for the future. Johnuniq (talk) 01:29, 12 January 2026 (UTC)

In summary, the scale of eV has been changed from 1.602176487e-19 to 1.602176634e-19 (changed digits are underlined) per CODATA and discussed in 2019 revision of the SI. Thanks Quindraco for reporting the issue (now at Module talk:Convert/Archive 2#Template-protected edit request on 10 January 2026). The SI multiples such as keV were defined manually for historical reasons (the current convert system was developed in 2013 from the old system with over 4,000 templates). I will fix eV to use SI prefixes automatically and will remove the hard-coded multiples (self-reminder: need to define their defaults). I will also change the scale of unit eVpar to the value given by Quindraco above, and change the scale of unit e (elementary charge; same scale as eV). I guess that's all ok? Johnuniq (talk) 01:29, 12 January 2026 (UTC)

And change the scale for keVT as below. Johnuniq (talk) 04:06, 12 January 2026 (UTC)

Some history: unit keVT exists because it was requested but then kept because MK was wanted and the default output for MK is keVT (convert requires each unit to have a default). I don't know if these units are used now. keVT was added after a discussion in November 2009. MK was removed in August 2015 because it was then redundant (that is, MK works although it is not directly defined).

The scale for keVT given by Quindraco above is explained at Electronvolt#Temperature which states that 1 temperature electronvolt is the value of 1 energy electronvolt (joules) divided by the Boltzmann constant (joules per kelvin). Both values are exact by definition. That means the scale of unit keVT (1000 times larger) is defined as 1.602176634e-16 / 1.380649e-23 (using floating point notation which I will copy/paste into convert to show the value's origin, and so a Wikipedia server will calculate the scale using its best precision). Johnuniq (talk) 04:06, 12 January 2026 (UTC)

That's some fascinating history. There's a unit I've been meaning to request be added to convert, the dalton (mass, scale 1.66053906892(52)×10−27), but I was avoiding doing so since I assumed asking for new units was a big no-no. Should I make a new talk section on here requesting it? Quindraco (talk) 05:16, 12 January 2026 (UTC)

Dalton

Quindraco mentioned the possible addition of Dalton (unit) above. New units are fine but proposals should include a link to one or two articles where a convert would be useful. Dalton was discussed at Template talk:Convert/Archive July 2015#Proposed new units. I started that section in response to an edit in June 2015. No one explained how the unit would be used so it was eventually removed. Johnuniq (talk) 05:32, 12 January 2026 (UTC)

The Dalton is referenced on a significant number of Chemistry-related articles; in particular, every single article about an element that has a standard atomic weight mentions the dalton, because the infobox for that element will list its standard atomic weight in daltons. If you load up the page for e.g. uranium, you will see its weight listed. Scroll down and you will see its specific heat capacity, which I added, but right now it's very kludgey because I am manually converting daltons (and I made at least one mistake while doing it and had to go back and fix it). Automatic conversion would be very helpful. Quindraco (talk) 06:19, 12 January 2026 (UTC)

Please link to an example article and quote some exact text showing what you mean (exact text so it could be used to search for the text on the page). Johnuniq (talk) 06:24, 12 January 2026 (UTC)

@Quindraco: I need at least one clear example soon please. A unit needs a code, type (mass), scale, symbol, name, link, and a default output unit. The code is what you type in a convert template, presumably "dalton". See my above "edit in June 2015" link. Johnuniq (talk) 01:59, 13 January 2026 (UTC)

Uranium lists a specific heat capacity of 116.225 J/(kg·K), which is done inside Template:Infobox uranium, which supplies uranium's standard atomic weight (seen at the top of the infobox, Standard atomic weight Ar°(U) = 238.02891±0.00003) to Template:Infobox element, which has to manually convert daltons because convert hasn't got the dalton built in.

I've never written anything for a Lua module, so I copied the unit entry for mph/s to try and get you what you need. I don't see a "code" listed, but just like I expect {{cvt|1|kg}} to work, I would expect {{cvt|1|Da}} to work.

["dalton"] = {

name1 = "dalton",

name2 = "daltons",

symbol = "Da",

utype = "mass",

scale = 1.66053906892e−27,

default = "kg",

link = "dalton (unit)",

},

Quindraco (talk) 02:22, 13 January 2026 (UTC)

@Quindraco: Are you talking about data62 in the wikitext of Template:Infobox element? And convert would replace something there? Before units are added, there should be an indication of where the convert would be used, with an example. Can you post <code><nowiki>{{convert|...}}</nowiki></code> with ... replaced with actual values. Where would that be placed? By the way, if you ever propose another unit, we don't need Lua code, just the things I mentioned such as code=Da, type=mass (not needed now because the above includes it). Johnuniq (talk) 05:50, 13 January 2026 (UTC)

I'm thinking the unit should accept SI prefixes (kDa)? Johnuniq (talk) 05:56, 13 January 2026 (UTC)

Yes, {{#expr:{{{heat capacity}}} * 1000 / {{Infobox element/symbol-to-saw/formal-short-rounded|symbol={{{symbol|}}}}} round 3}} is a (slightly incorrect, but extremely close heuristic in practice) replacement for {{cvt|{{#expr:{{{heat capacity}}}/({{Infobox element/symbol-to-saw/formal-short-rounded|symbol={{{symbol|}}}}}*6.02214076*10^23)}}|Da|kg|disp=number}}.

Daltons are in the same list as electronvolts of non-SI units accepted for use with SI, so I agree, accepting SI prefixes makes sense. Quindraco (talk) 14:48, 13 January 2026 (UTC)

That is weird! Dalton will be live soonish. You probably should include |sigfig=3 in the convert. The expression for the input value could generate a lot of digits which convert would interpret as significant figures. Also, think about whether |error=x should be included. Replace x with what should appear (or an empty string) if the conversion fails. Otherwise, convert will display a hard-to-interpret error if something goes wrong with the expr calculation. Johnuniq (talk) 02:29, 14 January 2026 (UTC)

Turn off linking for count word prefixes

Currently, when using count word prefixes (e.g., e6) and unit name linking (e.g., lk=on), it seems to link the count word as well (though only in the input unit):

{{convert|3|e9BOE|e9GJ|lk=on|abbr=off}} → 3 billion barrels of oil equivalent (18 billion gigajoules)

Is there a way to turn off this behaviour? Otherwise, it should just remove it entirely, as linking common words like "thousand", "million", and "billion" doesn't really make sense. If the count word is a part of the unit name, that's another matter, but that's not what the case is here. Tstcikhthys1 (talk) 06:15, 12 January 2026 (UTC)

The quick answer is no, there is no way to turn that linking off. Going back ten or so years, "billion" was regarded as more ambiguous than now. There were once claims that billion meant million million (billion has more on that) but I haven't seen that raised for a long time. Currently, billion is defined as requiring a link if lk=on (see Module:Convert/text#L-49 which shows that million is not linked, but billion is). The abbr option had a similar problem in that abbr=on with, for example, e9km used to abbreviate e9 (showing 10⁹) as well as showing a symbol for the unit. Now abbr=unit can be used to only abbreviate the units. I could look at also doing that for lk if the proposal gets a bit more support. Bear in mind that lk=in and lk=out are supported and they would continue to link number names, if used. Any thoughts? Johnuniq (talk) 08:31, 12 January 2026 (UTC)

It might not matter often, but there's still a case for linking for clarity when our meaning of billion might differ from a source's, or from common usage at the time and place of the statistic or whatever. For the UK, that might be sources from pre mid-1970s, roughly; for India perhaps later (we speculated about that when discussing whether "tmcft" had been invented to avoid ambiguity), and maybe for other English-speaking countries too. NebY (talk) 13:55, 13 January 2026 (UTC)

Ah I see. With the growing prevalence of the words billion and billionaire in news media and elsewhere, I don't really think there's much confusing about the short scale and the long scale these days, so it can safely be removed.

Regardless, I think it's strange that "billion" is being linked because it's not the unit itself, but a count word used in conjunction with a unit. Since the documentation says that the unit will be linked, this behaviour seems strange, which is why I brought it up.

If it is going to be there for clarity, I think it'd be better to have linking it as an option (rather than the converse). Moreover, the article on Billion has either meaning as the definition of the word, so if clarity was what's important, then the reader would be left equally confused after visiting the article since the template doesn't make it clear which meaning of billion is being used in the current invocation. Tstcikhthys1 (talk) 12:09, 19 January 2026 (UTC)

In convert, billion links to 1000000000 (number) although that is a redirect to 1,000,000,000 and the latter might be a better target. My comment linked to billion to make it clear that there is (or was) confusion about what it means. NebY's comment mentioned tmcft which is a unit from India for "thousand million cubic feet" to avoid ambiguity. Options are good sometimes but they introduce complexity. Johnuniq (talk) 23:32, 19 January 2026 (UTC)

I see. I think I still stand by my previous comment: in this day and age, people are becoming more and more familiar with larger and larger numbers (e.g., learning what the giga- and now even tera- prefixes mean), and I think people are firmly aware of what a billion means, so it should be removed.

It's good that the template links to the number article. Agreed that it would add complexity, but I'd say if the link isn't removed completely, the template should have it off by default, and have an option to turn on linking for count words, but then it will do it for all of them (including million, for example) so that it becomes a "feature" rather than the case-by-case basis situation that exists currently. Tstcikhthys1 (talk) 07:10, 20 January 2026 (UTC)

Americans and younger people might think of a billion as 1000 million but older people in the British Commonwealth were taught that it means a million million. I'm a 60-year old Australian and I intuitively think of it as a million million. I know that this is no longer the main stream definition but it is still my intuitive thought and I need to remind myself that the meaning has changed since my school days. Some other countries are still in the process of changing. It costs little to keep it and it is a good reminder for countries (and individuals) that haven't fully internalised the change yet.  Stepho  talk  10:04, 20 January 2026 (UTC)

And France (and I think Italy too?) has milliard for one thousand million (with billion for million million). So allow at least another 25 years, I suggest. 𝕁𝕄𝔽 (talk) 12:21, 20 January 2026 (UTC) Not just France, pretty much all European languages have a cognate of milliard. --𝕁𝕄𝔽 (talk) 12:28, 20 January 2026 (UTC)

Also Germany. During the hyperinflation in the Weimar Republic, banknotes and even postage stamps appeared with the value expressed as e.g. "500 Milliard Mark", etc. --Redrose64 🌹 (talk) 23:47, 20 January 2026 (UTC)

Gradients?

Is there a function in convert for gradients, e.g. 1-in-X = y degrees or z%? Anothersignalman (talk) 19:28, 13 January 2026 (UTC)

Sorry, no. Convert can do, for example, inches/feet to mm/m, but not a slope to an angle. Johnuniq (talk) 22:02, 13 January 2026 (UTC)

Well why the HELL not? It slices, it dices, it leaps tall buildings in a single bound -- so why can't it do grads? Why do civil engineers get left out in the cold? EEng 04:19, 14 January 2026 (UTC) P.S. Seriously: does it handle degrees and radians?

You're right. Convert and I share many failings. Johnuniq (talk) 05:18, 14 January 2026 (UTC)

Civil engineers - aren't ;)  Stepho  talk  06:53, 14 January 2026 (UTC)

Is there a process for starting a discussion about adding the function? Anothersignalman (talk) 07:19, 14 January 2026 (UTC)

Here is a good start. First step is to link a couple of articles and identify what text in each would benefit from a conversion. There is no need to go into details: a big-picture concept would be good. Assuming there was a template doing what you wanted, what would the input be, and what output would it produce. What units might be used? For the input, all length units? Or just a few (what)? Johnuniq (talk) 07:53, 14 January 2026 (UTC)

Well, here's the project I'm working on that made me ask the question in the first place: Walhalla railway line. This 1927 diagram [2] shows the gradients of the railway line expressed as 1 in X, e.g. a slope marked "30" is 1 in 30. I don't know whether expression of those numbers in percentage or degrees would be useful; locally we almost always referred to grades as 1 in X, but that's not always true internationally. I know percentage gradients are common terminology in USA, and degrees (or radians?) would be good for anything discussing, say, a bridge span with a steep slope between the end abutments. (This diagram shows 21 bridges under the railway, as upward-pointing arrows, and two bridges over the railway with the symbol "T".) For inputs, I think a code chain of {{convert|30|x|%dr}} might work, where the user inputs any one value, x for 1 in X, % (or pc?) for percentage, d for degrees or r for radians, and it provides outputs for all other terms, in this case %, d, and r, but fewer if not all three are specified in the final convert term. There'd also need to be something for rounding, e.g. maximum 2 decimals on percentage. A more complicated version might want to account for swapping from downhill to uphill, e.g. downhill 1 in 30 changes to uphill 1 in 30, net difference 1 in 60. Anothersignalman (talk) 08:07, 14 January 2026 (UTC)

There will be a way to get all that in a template but it might be a new one dedicated to the task. Convert is massive and it would not be a good place to add code for a specific function (convert generally just multiplies an input value by a scale with formatted unit names). I suggest starting a discussion at WT:TRAINS. Keep it simple by starting from scratch without a preliminary about how you tried here. The question to raise is whether others think a gradient template of some kind would be helpful. Give your example but be a bit more specific—what text in the current article would be replaced (or enhanced) with a template, and what would the output be. If there is some support with a reasonably concrete plan, it will happen. Redrose64 has been active here and might help discuss some details at TRAINS. Johnuniq (talk) 08:25, 14 January 2026 (UTC)

Thanks for the advice. My use-case is for a railway so I'll shift over to there, but there are probably other, non-railway applications for this sort of code e.g. highways, walking/hiking tracks, cycling corridors etc., but also maybe for bridge discussions and maybe some generic engineering articles? Anothersignalman (talk) 08:31, 14 January 2026 (UTC)

Done, link here - Wikipedia talk:WikiProject Trains#Gradient template?. Anothersignalman (talk) 08:40, 14 January 2026 (UTC)

I'm about two days behind on my watchlist, so only just seen this. {{railway gradient|30}} → 1 in 30 (33.3 ‰). --Redrose64 🌹 (talk) 21:12, 15 January 2026 (UTC)

Crosspost response from the other thread - Is the per mille symbol standard in some other jurisdictions? I've only ever seen gradients expressed as 1 in x or percent e.g. 3.33%, not 33.3‰. Anothersignalman (talk) 16:30, 16 January 2026 (UTC)

It's not something I've come across either, but a quick google finds a few forum posts and similar sources stating that per mille is used on continental European railways and one implying that it's used in India. List of steepest gradients on adhesion railways uses 1 in x and % consistently, as does the only non-English Wikipedia to have an equivalent article (es:Anexo:Pendientes ferroviarias más pronunciadas) - but that was translated from the English article in 2019. Looking at the articles for a couple of the systems near the top of that list:

• Pöstlingbergbahn (Germany) uses %, as does the source. de:Pöstlingbergbahn uses ‰ in the infobox and prose but there isn't an inline source in either place.
• Gmunden Tramway uses % but it's German-language source [3] uses ‰ as does the German Wikipedia article (I couldn't immediately spot a figure in the other language editions).
• de:Straßenbahn Mainz uses ‰, none of the other language editions (including English) seem to mention the gradient in the article.

Thryduulf (talk) 19:54, 16 January 2026 (UTC)

Module version 33

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 • same content
• 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
• New option round=1 rounds the output to the nearest integer (same as but clearer than |0), (discussion).
• Fixed old problem: a unit alias with a default could have that default overridden by the target's default exception. For example, {{convert|1|micron}} will give 1 micrometre (39 μin) rather than 1 micrometre (3.9×10⁻⁵ in).
• Unit changes:
  • Add unit Da (dalton) (discussion).
  • Change scales for units e (charge) and eV (energy) from 1.602176487e-19 to 1.602176634e-19.
  • Change scale for unit eVpar from 1.602176565e-19 * 6.022140857e23 to 1.602176634e-19 * 6.02214076e23.
  • Change scale for unit keVT from 11.604505e6 to 1.602176634e-16 / 1.380649e-23.
  • Change unit eV to accept SI prefixes and remove old hard-coded multiples: feV GeV keV MeV meV neV PeV peV TeV μeV.
    • Discussion for above.

I am documenting a mysterious change in case it needs to be understood in the future. Unit keVT has had its symbol changed from keV to *keV. That was needed because unit eV has been changed to accept SI prefixes, meaning that keV is a defined symbol which is used in Module:Convert/documentation/conversion data#Defaults. That means keV has a different default from its base, eV. Adding the asterisk to the symbol of keVT causes its default to not be changed by the conflicting keV entry (documentation). Johnuniq (talk) 05:35, 14 January 2026 (UTC)

Modules have been updated. Johnuniq (talk) 02:23, 15 January 2026 (UTC)

I had to make another change: unit eVpar symbol changed from eV to *eV (same issue as keVT mentioned above). Johnuniq (talk) 09:47, 15 January 2026 (UTC)

Custom, single-use conversion units?

Is there a way to set the convert template to go from x to y, but also to custom unit z? In my case, x is imperial distance (feet), y is metric distance (m), but I also want an output z = x divided by 27.5, rounded down. For example, if I use this code {{convert|300|ft|m|?|abbr=on}}, what do I place in the "?" slot to generate an output 300 ft (91m or 10 trucks)? This is for a specific railway where nearly the entire fleet of trucks/wagons/vans was standardised at 27ft6in long; an adjacent network standardised on 25ft, and if I were writing about a passenger carriage yard I might want to divide by 62ft or 75ft etc. The code would need to allow for plural vs singular units, e.g. "truck" vs "trucks" if the output quantity is not one. Anothersignalman (talk) 16:28, 16 January 2026 (UTC)

No custom conversions are available but various templates such as {{rounddown}} and expressions (Help:Calculation) can be used.

• {{convert|300|ft|disp=x|| (| or {{rounddown|300/27.5}} trucks)}} → 300 feet (91 m or 10 trucks)

Johnuniq (talk) 01:42, 17 January 2026 (UTC)

As John said, convert cannot do it directly. But this comes close:

{{#expr:300/27.5 round 0}} trucks ({{cvt|300|ft|m|disp=comma}}) displays as 11 trucks (300 ft, 91 m)

This relies on |disp=comma to stop the normal brackets, and you then provide brackets by hand.

Or this:

{{cvt|300|ft|m|disp=x| (}}, {{#expr:300/27.5 round 0}} trucks) displays as 300 ft (91 m, 11 trucks)

This relies on |disp=x| ( to display only an open bracket and then you fill in the rest by hand with #expr and a closing bracket by hand.

If you are using that often then I would wrap it inside another template so that the article wiki markup will be simpler to understand.  Stepho  talk  02:04, 17 January 2026 (UTC)

Thanks for that. In the second term, how would you change it from round-off to round-down? Anothersignalman (talk) 10:55, 18 January 2026 (UTC)

You can use {{cvt|300|ft|m|disp=x| (}}, {{#expr:trunc(300/27.5)}} trucks) to display as 300 ft (91 m, 10 trucks)

This uses the trunc function to truncate (ie round down) the result of the division.  Stepho  talk  13:18, 18 January 2026 (UTC)

Is there a way to combine that code with {{convert|...|disp=table}}, if I wanted the three figures 300, 91 and 10 to appear in separate columns of a table?

Anothersignalman (talk) 22:00, 18 January 2026 (UTC)

Try this:

{{Table alignment}}
{| class="wikitable col4right"
! Blah blah !! Feet !! Metres !! Trucks
|-
| Midnight train to Georgia || {{cvt|300|ft|m|disp=table}} || {{#expr:trunc(300/27.5)}}
|}

Blah blah	Feet	Metres	Trucks
Midnight train to Georgia	300	91	10

Brought to you by the magic of convert and its |disp=table option, which disables brackets and outputs || instead.  Stepho  talk  02:31, 19 January 2026 (UTC)

The first reply in this thread was from me and included {{rounddown|300/27.5}} with a demonstration that it works. Johnuniq (talk) 02:52, 19 January 2026 (UTC)

As John said, this also works:

{{Table alignment}}
{| class="wikitable col4right"
! Blah blah !! Feet !! Metres !! Trucks
|-
| Midnight train to Georgia || {{cvt|300|ft|m|disp=table}} || {{rounddown|300/27.5}}}}
|}

Blah blah	Feet	Metres	Trucks
Midnight train to Georgia	300	91	10

 Stepho  talk  04:53, 19 January 2026 (UTC)

Additional unit requests

I'd like convert to be able to handle angles. Radians are a special case, so I want to be very clear that rads already exist in convert. I am assuming the module can't handle polymorphic overloading, i.e. we can't have two "rad" units that are distinguished by the to-unit, in this request. I will also make other assumptions about how the code works, but remember I am not fluent in how the module's guts work, so please check to make sure my input is valid.

Emphatic note: arc minutes and seconds have special symbols used which look like single and double quotation marks, but aren't. I pasted in the actual symbols rather than their html codes, but in html they're ′ and ″ - ′ and ″.

Assumptions I know are questionable:

• Polymorphic overloading is not possible: we can't specify a second rad to be radians and have the angle unit and the radiation unit be distinguished by the to-unit.
• There's no good way to handle SI prefixed units where some SI prefixes have their own article link, which is why I have radians set to use prefixes but then milliradians are listed separately, which will confusingly have "mradian" and "milliradian" link to different articles. I would love an expert to take a look at how to better handle this.
• rev and cyc assume "target" commutes intelligently, so I can target a targeter and have it count as the targeted targeter, rather than copying over values such that changes don't propagate.
• Scales have to be static values - many of these are relative to π, so I used the expr parser function to specify them. If scales can be dynamically calculated, you'll see the appropriate formulae in the expr calls.
• This is a big one: the "subdivs" values in the module data are dictionaries whose keys are lists, so I think the current module data is written incorrectly, because there's only one reason for the keys to be lists: if the keys can hold multiple valid values. That is, I assume this part of the specification for the "mi" unit is incorrect, ["chain"] = { 80, default = "km" }, ["chainlk"] = { 80, default = "km" }, and instead should be ["chain", "chainlk"] = { 80, default = "km" }. If I am wrong, my subdivs need to be modified to duplicate text in the same way.
• I copied the existing module data slavishly for the handling multiples, but it also seems to be buggy, because combination and multiple are both sets (unordered collections) seemingly used as if their orders have to match, which can't possibly be right. I obeyed the current data, but I am 99% certain this is broken behaviour and they should be lists or tuples, which are ordered.
  • Example from ydftin, which I copied for °′″: combination= { "in", "ft", "yd" } and multiple = { 12, 3 } should not be be trusted to maintain those relative orders, even though those relative orders must be maintained for convert to work; I am 99% certain they ought to be combination= [ "in", "ft", "yd" ] and multiple = [ 12, 3 ], but rather than stick with this assumption as I did with subdivs, I stuck to the current, seemingly broken method.

List of units being requested:

• radian
• milliradian
• gradian
• turn, cycle, and revolution
• degree
  • arc minute
  • arc second

Specific articles that could use this: anything discussing angles, but some low-hanging fruit are the articles linked above in the list of units, all of which have symbol legend tables showing the conversion values, which are currently hard-coded rather than calling convert.

["radian"] = { name1 = "radian", symbol = "rad", utype = "angle", scale = 1, prefixes=1, default = "radian", link = "radian", },
["milliradian"] = { name1 = "milliradian", symbol = "mrad", utype = "angle", scale = .001, default = "radian", link = "milliradian", },
["gradian"] = { name1 = "gradian", symbol = "grad", utype = "angle", scale = 0.015707963267949, default = "radian", link = "gradian", },
["tr"] = { name1 = "turn", symbol = "tr", utype = "angle", scale = 0.1591549430919, default = "radian", link = "turn (angle)", },
["r"] = { name1 = "revolution", symbol = "r", target = "tr" },
["rev"] = { target = "r", symbol = "rev", },
["c"] = { name1 = "cycle", symbol = "c", target = "tr", },
["cyc"] = { target = "c", symbol = "cyc", },
["°"] = { name1 = "degree", symbol = "°", utype = "angle", scale = 0.017453292519943, default = "radian", link = "degree (angle)", subdivs = { ["′","arcmin"] = { 60, default = "radian" } }, },
["deg"] = { target = "°" },
["′"] = { name1 = "arc minute", symbol = "′", utype = "angle", scale = 0.00029088820866572, default = "radian", link = "minute and second of arc", subdivs = { ["″","arcsec"] = { 60, default = "radian" } }, },
["arcmin"] = { target = "′" },
["″"] = { name1 = "arc second", symbol = "″", utype = "angle", scale = 4.8481368110954E-6, default = "radian", link = "minute and second of arc", },
["arcsec"] = { target = "″" },
["°′″"] = { combination= { "″", "′", "°" }, multiple = { 60, 60 }, utype = "angle", },
["°′"] = { combination= { "′", "°" }, multiple = { 60 }, utype = "angle", },
["degarcmin"] = { target = "°′", },
["degarcminarcsec"] = { target = ""°′″"", },

Quindraco (talk) 18:38, 17 January 2026 (UTC)

Yikes, that's a lot of text. Please don't think about code. Instead, clearly list any wanted units giving brief usage examples (wanted inputs and wanted outputs). Convert has existed for 19 of the 25 years of Wikipedia's existence (although the module has only been used for 12 years). Therefore it is very rare for there to be missing useful units. Angles have been discussed several times (see July 2024). Any thoughts from others? Johnuniq (talk) 04:49, 18 January 2026 (UTC)

I personally probably wouldn't have much use for this, but I wonder if some of the code would overlap / interface with the discussion a few days ago about railway gradients and slopes? Anothersignalman (talk) 10:57, 18 January 2026 (UTC)

Gradients, angles and slopes all seem to (my very unmathematically inclined mind) be very closely related and so seems sensible for them to be handled together. Either as part of {{convert}} or separately (cf. Wikipedia talk:WikiProject Trains#Gradient template?). That there have been at least 7 previous discussions about this over the years relating to multiple different contexts suggests that there is actually a strong usecase here. Thryduulf (talk) 11:41, 18 January 2026 (UTC)

I don't understand the compelling argument against including, at a minimum, all of the SI units, of which the radian is one.Quindraco (talk) 16:17, 19 January 2026 (UTC)

@Quindraco: Please tidy up this section and the one preceding it. With this edit you dropped a new section into the middle of the existing section; worse, you dropped it inside the existing <blockquote>...</blockquote> structure causing a foulup of the layout for both. --Redrose64 🌹 (talk) 07:08, 19 January 2026 (UTC)

Thank you, Redrose64 - I only wrote one section and had no idea Wikipedia decided to duplicate my request for no apparent reason. Pretty sure I've handled it now.Quindraco (talk) 16:14, 19 January 2026 (UTC)

There is no need to look at the July 2024 link I gave above but it shows several cases where people have suggested adding angles but when asked for details, they disappear. What text in what article would have what convert with what result? Is there more than one such article where a new unit would really be helpful (as opposed to displaying degrees in radians or vice versa because it could be done)? Johnuniq (talk) 23:41, 19 January 2026 (UTC)

I don't know about radians, but converting between percentages and 1 in x gradients would be useful on the majority of articles about funicular railways (over 100) just for starters. Thryduulf (talk) 00:02, 20 January 2026 (UTC)

OK, but details are needed for each unit: type, code, symbol, name, default, link. For example, see the length units. Don't edit anything—it's best to propose the details here for discussion. I guess type would be "Angle". A link to an article with some quoted text would also be nice to see how a convert would be used. Johnuniq (talk) 04:00, 20 January 2026 (UTC)

Miles, chains and links?

Hi all,

Convert has Miles and Chains, is there any chance of adding Links as well? At the moment I have to use {{convert|83|mi|48.44|chain|km|abbr=on}}, with the output 83 mi 48.44 chains (134.550 km).

I'd prefer the more accurate {{convert|83|mi|48|chain|44|lks|km|abbr=on}} for the output 83 mi 48 ch 44 lk (134.550 km).

Yes the "links" term would go back and reduce "chains" to "ch", it already looks strange to have "mi" and "chains" next to each other.

I've used "lks" instead of "links" in the proposed code because I figure that has less chance of getting broken if someone was editing and CTRL+H'd a block of text. Not sure if the output should be "X mi Y ch Z lk" or "X M Y C Z L", the latter would be more accurate for local railway practice but that's only one jurisdiction.

Anothersignalman (talk) 19:44, 17 January 2026 (UTC)

Note that |miles shows the full "miles" even when abbreviation is on: {{convert|83|miles|48|chain|km|abbr=on}} for the output 83 miles 48 chains (134.5 km) .  Stepho  talk  21:01, 17 January 2026 (UTC)

I believe the proposal is to add a new unit with code lks for Link (unit) which is one hundredth of a Chain (unit). This is the first mention of that unit that I can find in 19 years! Normally I would make a lot of fuss about creating a unit with as little love as that but it seems odd that convert doesn't support what appears to be, at least, a significant part of history. The code and name would cause a lot of confusion but we might have to live with that. Convert accepts these codes for a chain: ch chlk chain chainlk. The lk varieties link the unit, while chain never abbreviates. Only ch and chain accept multiple inputs like {{convert|2|ch|3|yd}} → 2 chains 3 yards (43 m).

• {{convert|83|MI|48|CH|44|li|km}} → 83 miles 48 chains 44 links (134.550 km)
• {{convert|83|MI|48|CH|44|li|km|lk=in}} → 83 miles 48 chains 44 links (134.550 km)
• {{convert|83|MI|48|CH|44|li|km|abbr=on}} → 83 mi 48 ch 44 li (134.550 km)

I have put an experiment in Module:Convert/extra. The uppercase MI and CH are necessary for testing with the proposed li. Conversions to li like {{convert|79|in|li}} → 79 inches (10.0 li) would work but there is no multiple output such as converting a distance to chains and links. Thoughts please. Johnuniq (talk) 01:38, 18 January 2026 (UTC)

Thanks for that, and yes you're right, that's what I was proposing. With that said, if we're using capitalised MI and CH for this, maybe go with capitalised LI, LK or LS for links? And/or, is lowercase "li" available? Re multiple outputs, I'm normally all for complexity and detail but in the short term, would it be easier to instruct users to do a flip trick like this code - {{convert|1.676|x|0.229|x|0.114|m|ftin|1|order=flip}} instead? Or alternatively, have a popup whenever a convert outputs decimal-chains explaining that 100 links = 1 chain? Anothersignalman (talk) 03:32, 18 January 2026 (UTC)

The uppercase MI and CH are only a temporary measure to test the proposal. Because ch is already defined without reference to lks, it was necessary to temporarily define CH so it would accept a sub-division of lks. Then it was necessary to temporarily define MI to accept CH. If you need this in an article, use it with uppercase and I'll fix it later when updating this trial to something more permanent. It's too hard and complex to include every nice-to-have feature so tradition is to wait for clear usage requirements before adding something, for example, to convert to chains and links. People haven't been able to use links at all ever since Wikipedia started 25 years ago and it is rare for there to be a missing unit. Unit li is unused and could be the code for link, instead of lks. It would be better to avoid the plural "s" so reply here if there should be a change. Use this link to see articles using the temporary unit. Johnuniq (talk) 03:59, 18 January 2026 (UTC)

Walhalla railway line is the article I'm working on at the moment that would use the code. Using the route map as a guide, I'd expect at least 20 instances of "links" as measurements in text (extracted from sources) by the time I finish. Then the same again for the Whitfield railway line and Gembrook railway line when I get around to creating the latter, and possibly twice as many on Crowes railway line. All up, that's something like 100-150 uses. Will you have a bot of some sort convert things like {{convert|83|MI|48|CH|44|lks|km|abbr=on}}, or will you be doing it manually? If manual, I'm happy to do it myself in a day or two, once I finish everything else.

I'd prefer "li" to maintain the pattern after "mi" and "ch", but open to other people's preferences/advice. Do we need to consider background usability elements like "lk" could be typo'd as "kl" and therefore produce convert errors trying to mix volume and distance, which "li" would avoid?

Anothersignalman (talk) 10:53, 18 January 2026 (UTC)

I changed lks to li and lks no longer works (therefore I also edited the examples above). Your point about abbreviation consistency is good, plus the fact that convert has a "link" parameter written as lk which means lks would invite confusion. I also changed the symbol for the unit to be li (not lk). Is that ok? Link (unit) suggests it is and it would be better for the unit code to match the unit symbol. Johnuniq (talk) 03:04, 19 January 2026 (UTC)

Seems like "li" is the correct solution then. I think the code will work now, should I start rolling out capital MI, CH, lowercase li into my article now, or wait for the goahead with lowercase all three? Anothersignalman (talk) 04:49, 19 January 2026 (UTC)

Do it now. It might be quite a while before the main module is updated (it's used on 1.4 million pages) and I will easily fix whatever is needed. Johnuniq (talk) 05:08, 19 January 2026 (UTC)

Suggestion

There should be an option to not display the first unit in adjectival form when using |adj=mid. For example, {{convert|123|kcal|kJ|adj=mid|(per biscuit)}} should produce: 123 kilocalories (per biscuit) (510 kJ), but now it produces: 123-kilocalorie (per biscuit) (510 kJ). --40bus (talk) 20:08, 20 January 2026 (UTC)

The point of |adj=pre is that it displays it in adjective form, ie with a hyphen.

How about {{convert|123|kcal|kJ|disp=x| (per biscuit) (|)}} -> 123 kilocalories (per biscuit) (510 kJ)  Stepho  talk  23:51, 20 January 2026 (UTC)

This illustrates the purpose of adj (adjectival for singular unit):

I ate a {{convert|123|kcal|kJ|adj=on}} cake. → I ate a 123-kilocalorie (510 kJ) cake.

Johnuniq (talk) 01:07, 21 January 2026 (UTC)

Super-feet

Is there a way to display the unit "board feet" as "super feet"? As far as I can tell they're the same thing, but the latter term is/was used to measure timber volume. I haven't seen the former in my research/references. Anothersignalman (talk) 18:01, 21 January 2026 (UTC)

Well the relevant article is Board foot, which mentions in passing that superfoot was used in AUNZ until the 1970s. Pipe? 𝕁𝕄𝔽 (talk) 18:23, 21 January 2026 (UTC)

No, convert has no "super" in its units. Johnuniq (talk) 01:39, 22 January 2026 (UTC)

Furlong symbol

Description of suggested change: Currently with this template, there is no abbreviation designated for furlong. Especially in horseracing where furlongs are still widely used in reports and race results, it is common to shorten this to either fur or f (this is just one area for an example, I'm sure such an abbreviation wouldn't be objectionable in other areas!). As such, I think it would be useful to add this to the table.

Diff:

−

(none) [for the "symbol or abbrev." cell for "Furlong" in Length's Imperial & US customary section]

+

fur

RandomEditsForWhenIRemember (talk) 20:01, 23 January 2026 (UTC)

I removed the edit request and gave this section a heading to make it easier to find in the future. This page works by starting with a discussion. If consensus, units will be changed. Where would fur be useful as an abbreviation (link to article and section please)? It's likely that whoever uses this unit (horse racing) finds fur understandable but it might not be so useful for a general audience in 2026. I hope others will comment once examples are shown. Johnuniq (talk) 22:32, 23 January 2026 (UTC)

Most horse race reports that I come across use "f", as for example the 2:05 at Doncaster today - shown as 2m7f214y (2 miles, 7 furlongs, 214 yards) - this comes out as six yards short of three miles. --Redrose64 🌹 (talk) 15:48, 24 January 2026 (UTC)

Thanks for the edit Johnuiq, I wasn't aware there was a difference when it came to making requests on this page.

Furlongs these days mostly get used for horseracing, so it'd be mainly used for articles related to various tracks. Redrose64 gives a perfect example above; a lot of races run over x miles and furlongs rather than x metres for historical reasons. As such any race or track of that kind with a wikipedia page would benefit from this, especially when using it to convert distances from one measurement to another. For some examples:

St Leger Stakes - Infobox already manually uses f for furlong.

Japan Cup - A rare race measured in metres, so being able to use Convert on the page to show the equivalent is handy throughout the page is useful and having an abbreviation for furlong would match the abbreviated style for miles used (see opening lede and race course details). Tennō Shō is another race that is metre based, so an abbreviation for furlongs would be useful for the convert uses.

Ayr_Racecourse - See the Notable races table, which already manually uses "mi" and "f" for distances

Spectacular Bid - Most horse bios could use it, but for a specific example, it would be useful to have an abbreviated use of furlong in parts like "1980: four-year-old season" where the writing suddenly switches to using a different measurement for distance e.g. "covering the 1+1⁄4 mi (2.0 km) in 2:02.4."

"f" is probably a safer pick than fur to be honest, I think looking at more recent sources it seems to be more common in race reports these days than fur. RandomEditsForWhenIRemember (talk) 17:04, 24 January 2026 (UTC)

Speaking of house bios, does WP:BLP (biography of living Phillies) apply in such cases? EEng 17:12, 24 January 2026 (UTC)

2025 Belmont Stakes has "Distance {{convert|1+1/4|mi|furlong m|0|abbr=on}}" in the infobox which displays as "Distance 1+1⁄4 mi (10 furlongs; 2,012 m)". The proposal is to change "10 furlongs" to "10 f". Any opinions on that? Johnuniq (talk) 06:25, 25 January 2026 (UTC)

Makes sense to me since miles and metres are already shortened - this also goes for the ~40 Belmont Stakes with articles. RandomEditsForWhenIRemember (talk) 20:42, 27 January 2026 (UTC)