Template talk:Convert

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 because 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 42 days may be automatically archived by when more than 2 sections are present.

Template:Convert

... in conception

... and in reality

Linear feature density

At Transport in Switzerland#Railways I've found a need to convert 122 km/1000 km² into imperial (probably something like miles per 100 or 1000 sqmi). Is this something convert can handled? In the article I've gone with separate conversions to come up with 76 mi per 390 sq mi which is not ideal. Thryduulf (talk) 16:58, 19 July 2024 (UTC)[reply]

Best I can find is {{cvt|0.122|km/km2|mi/sqmi|3}} to display as 0.122 km/km² (0.196 mi/sq mi)

In theory we should be able to use e3km2 and e3sqmi but these don't work. Stepho talk 17:22, 19 July 2024 (UTC)[reply]

Similarly at List of prominent mountains of Switzerland#Distribution there is approximately 1.09 summits per 100 km² that I've just left as I can't work out anything sensible (I don't think 0.0109/km² (0.028/sq mi) is particularly useful). Thryduulf (talk) 17:36, 19 July 2024 (UTC)[reply]

Found a really clumsy and dirty technique: {{cvt|122|mi|km0|abbr=values|disp=preunit|km/1000 km<sup>2</sup>|mile/1000 sq mile}} displays as 122 km/1000 km² (196 mile/1000 sq mile)

This relies on km/km2 converting to mi/sqmi being the same ratio as mi to km - ie km/km2 is same as 1/km and 1/km -> 1/mi being the same ratio as mi -> km. Dirty, very dirty.

Sadly, this trick doesn't work for summits per area. Stepho talk 17:57, 19 July 2024 (UTC)[reply]

If there were a heap of these, new units for "1000 km2" and "100 sqmi" and "100 km2" could be defined. I'm not sure how clean the result would be but it might be reasonable. Johnuniq (talk) 03:20, 20 July 2024 (UTC)[reply]

A similar issue arises at Scandinavian mountains#Climate, permafrost and glaciers where there is a need to convert "1.17 °C /100 m" but the logical {{convert|1.17|C-change/e2m}} gives an error (1.17 C-change/e2m^{[convert: unknown unit]}). A quick search suggests that "°C /100m" (with that exact spacing) is used in at least three other articles. Thryduulf (talk) 11:30, 12 September 2024 (UTC)[reply]

Combining multiple components with ranges

Is it possible to combine the "multiple components" form, like {{convert|11|ft|2|in|m}} and {{convert|4|ft|5|in|m}}, with the "range" form? The only way that I've found that works is {{convert|11+2/12|x|4+5/12|ft|m|abbr=on}} - this gives 11+2⁄12 ft × 4+5⁄12 ft (3.4 m × 1.3 m) which is technically correct, but not ideal. --Redrose64 🌹 (talk) 15:23, 29 September 2024 (UTC)[reply]

Sorry, no. The multiple units like feet/inches can have several components (miles, chains, ...) and making them work with a range was beyond me. However, if desperate, there is a dirty trick which I can't really recommend but which gives a reasonable result in this case:

{{convert|3.40|x|1.35|m|ftin|order=flip}} → 11 feet 2 inches by 4 feet 5 inches (3.40 m × 1.35 m)
{{cvt|3.40|x|1.35|m|ftin|order=flip}} → 11 ft 2 in × 4 ft 5 in (3.40 m × 1.35 m)

Johnuniq (talk) 23:00, 29 September 2024 (UTC)[reply]

OK,

Thank you --Redrose64 🌹 (talk) 17:10, 30 September 2024 (UTC)[reply]

A new double conversion

For Reciprocating engine#History {{convert|2,300|metric ton|short ton long ton|lk=on}} and {{convert|2,300|metric ton|ST LT|lk=on}} 2,300 metric tons (^{[convert: unknown unit]}) and 2,300 metric tons (2,535 short tons; 2,264 long tons) instead of {{convert|2,300|metric ton|short ton|lk=on}} or {{convert|2,300|metric ton|long ton|lk=on|sigfig=4}} 2,300 metric tons (2,535 short tons) or 2,300 metric tons (2,264 long tons) Peter Horn User talk 01:54, 6 October 2024 (UTC)[reply]

@Peter Horn: When a unit code such as short ton contains a space, use + to separate units:

{{convert|2,300|metric ton|short ton+long ton|lk=on}} → 2,300 metric tons (2,500 short tons; 2,300 long tons)

Johnuniq (talk) 02:09, 6 October 2024 (UTC) Peter Horn User talk 02:41, 6 October 2024 (UTC)[reply]

Thanks. Peter Horn User talk 02:49, 6 October 2024 (UTC)[reply]

Possible bug report re: temperature units

Input:

{{Convert|1|K|C F|abbr=~}}
{{Convert|1|C|F|abbr=~}}
{{Convert|1|C|F|abbr=off}}
{{Convert|1|K|C F|abbr=off}}
{{Convert|1|Celsius|F|abbr=~}}
{{Convert|1|Fahrenheit|Celsius}}
{{Convert|1|C|kelvin|abbr=~}}

Output:
1 K [K] (−272.15 °C; −457.87 °F)
1 °C [°C] (34 °F)
1 degree Celsius (34 degrees Fahrenheit)
1 kelvin (−272.15 degrees Celsius; −457.87 degrees Fahrenheit)
1 °C [°C] (34 °F)
1 Fahrenheit^{[convert: unknown unit]}
1 °C [°C] (^{[convert: unknown unit]})

Semi-expected output:
1: 1 kelvin [K]
2: 1 degree Celsius [°C]
3 & 4: N/A, working
5: 1 degree Celsius [°C]

And last 2, certainly slightly surprising behavior that it outputs the unit names but doesn't recognize some as input. But it does for Celsius. If that's known/intended behavior, ought to be documented somewhere. (There, then it's not a bug, b/c you documented it—now it's a feature )

Contrasted:
1 inch [in] (0.083 ft; 2.5 cm)
1 inch (2.5 cm)
1 kilometre (5.0 furlongs)
Slowking Man (talk) 23:14, 7 October 2024 (UTC)[reply]

Convert has a lot of quirks due to its long history. The proper documentation is at Module:Convert/documentation/conversion data#Temperature. Various summaries of the units are available but I don't like the advice they give for temperature because they suggest that {{convert|30|°C}} is the approved method whereas it should actually be {{convert|30|C}} on the basis that unit codes are intended to be easy to type and it is not necessary to remember that it is K (kelvin) but °C (degrees Celsius). At any rate, for obscure historical reasons, Celsius was defined as an alias for C but the other names were not defined. If anything, I would recommend removing Celsius. Johnuniq (talk) 01:05, 8 October 2024 (UTC)[reply]

I started wondering if the OP was more concerned about the fact that abbr=~ produces °C [°C]. That option is rarely used. Most units default to showing the name for the input (for example, 30 kilograms). Using abbr=~ would display 30 kilograms [kg]). That is, it shows the symbol as well as the name. It turns out that temperature units default to showing the symbol and you have to use abbr=off to make them show the name. That means you cannot also use abbr=~ so it is not possible to show the name and symbol for a temperature unit. That is not ideal but probably is not worth fixing. See Template talk:Convert/Archive December 2014#What happened with abbr=~ ? for a discussion of whether the option should be deprecated. Johnuniq (talk) 02:08, 8 October 2024 (UTC)[reply]

WMF needs to determine your IRL identity and insure your life for $10,000,000 -- the conservative cost of hiring a staff of coders to take over maintenance of convert, should the worst happen. E Eng 03:24, 8 October 2024 (UTC)[reply]

I would take you up on that great idea if it were not for my nervousness regarding giving someone a $10,000,000 reason for me to disappear! Johnuniq (talk) 03:55, 8 October 2024 (UTC)[reply]

With the right paperwork, a "reported" death and a new life in Cuba, you could have a rather nice retirement plan :)

On an unrelated note, I'd completely forgotten that I had commented on this 10 years ago. But having never used it even once, I'm in favour of removing it. Is it used much?

Sounds like the OP's gripe is that Fahrenheit and kelvin are valid outputs but not valid inputs. Considering we also have meters, miles, feet, inches, etc as inputs, I tend to agree with him. Stepho talk 07:08, 8 October 2024 (UTC)[reply]

Gotta watch out for that template mafia. Extremely groan-worthy memeing attempt:

{{that's|how={{{mafia|{{{works}}}}}}}}

(for those not getting it) --Slowking Man (talk) 23:14, 8 October 2024 (UTC)[reply]

Hah, not surprising (I've seen scarier corner cases in old code for sure). Wanted to be helpful mainly and ensure this was known. Certainly understand if people aren't rushing in to overhaul the template code. Would be good to document the behavior somewhere I think. Where do people think is the best place to put that? Wouldn't mind writing up a note in the docs. Thanks for the expert knowledge!

--Slowking Man (talk) 23:14, 8 October 2024 (UTC)[reply]

Ranges of ranges of values

In technical plant descriptions (e.g. floras), dimensions of plant parts are often given in ranges of ranges: "5-15 x 4-8 mm". Is there a way to get {{convert}} to handle that appropriately, i.e. "5-15 x 4-8 mm (0.2-0.6 x 0.2-0.3 in)"? At the moment, {{convert|5|–|15|×|4|-|8|mm|1|abbr=on}} gives "5 mm–15 mm × 4 mm–8 mm (0.2 in–0.6 in × 0.2 in–0.3 in)", which is far too repetitive for readability.

{{convert|5|–|15|mm|1|abbr=on}} x {{convert|4|–|8|mm|1|abbr=on}} is a little better, giving "5–15 mm (0.2–0.6 in) x 4–8 mm (0.2–0.3 in)", but that's still needlessly repetitive. {{convert|5|–|4|mm|1|abbr=on}} x {{convert|15|–|8|mm|1|abbr=on}} gives "5–4 mm (0.2–0.2 in) x 15–8 mm (0.6–0.3 in)", which is also still repetitive, and also incorrectly formatted.

Any advice?

-- Photosynthetic430 ❧ 15:37, 11 October 2024 (UTC)[reply]

According to the documentation, |x| and |abbr=on| combine to output the unit symbol multiple times, as per MOS:UNITSYMBOLS. Replace |x| with |xx| so that {{convert|5|–|15|xx|4|-|8|mm|1|abbr=on}} outputs 5–15 × 4–8 mm (0.2–0.6 × 0.2–0.3 in). Downside is that xx is deprecated and you will be violating MOS:UNITSYMBOLS. Perhaps you should raise the question of whether this format should be used at Wikipedia talk:Manual of Style/Dates and numbers. Stepho talk 15:54, 11 October 2024 (UTC)[reply]

There must be some way in which{{convert|5|–|15|×|4|-|8|mm|1|abbr=values|disp=preunit|mm|in}} giving "5–15 × 4–8 mm (0.2–0.6 × 0.2–0.3 in)" is risky but I haven't figured that out yet. NebY (talk) 16:00, 11 October 2024 (UTC) Ah - anyone using it for anything but mm would have to take care to change both "mm" - otherwise e.g. changing only the first mm to m as {{convert|5|–|15|×|4|-|8|m|1|abbr=values|disp=preunit|mm|in}} gives "5–15 × 4–8 mm (16.4–49.2 × 13.1–26.2 in)". NebY (talk) 16:09, 11 October 2024 (UTC)[reply]

Discussions here about MOS:UNITNAMES resulted in the situation shown above where unit symbols are duplicated. There was a fair bit of pressure to remove a workaround which I retained on the principle that a template should not prevent an editor from exercising judgment. The trick is to use xx instead of x.

{{convert|5|-|15|x|4|-|8|mm|1|abbr=on}} → 5 mm–15 mm × 4 mm–8 mm (0.2 in–0.6 in × 0.2 in–0.3 in)
{{convert|5|-|15|xx|4|-|8|mm|1|abbr=on}} → 5–15 × 4–8 mm (0.2–0.6 × 0.2–0.3 in)

Note that it is better to use a letter x and a hyphen - in the input because they are easier to type and easier for others to copy. Johnuniq (talk) 22:47, 11 October 2024 (UTC)[reply]

Thank you! That's exactly what I needed. -- Photosynthetic430 ❧ 08:12, 13 October 2024 (UTC)[reply]