Template talk:Convert

Template:Convert

... in conception

... and in reality

Request: Add support for Mlbf and similiar units

These units are often used in NASA documentation and similiar. For example: https://ntrs.nasa.gov/citations/20150016519 Right now there are no options besides "1.6 × 10⁶ lbf" and "1.6 million pound force". As for example rocket thrusts are never given in "× 10⁶ lbf"-type units and instead in things like "MN" for meganewtons and the similar "Mlbf", we need to default to using "1,600,000 lbf" formats instead which is decidedly ugly. (On a side note, they also use lbm for mass units to disambiguate it with lbf.)Ergzay (talk) 05:57, 17 August 2022 (UTC)

The examples from the NASA pdf are:

• Maximum sea level thrust 3.28 Mlbf
• Propellant mass 1.385 Mlbm

You could use

• {{convert|1.6|e6lbf|e6N|abbr=unit}} → 1.6 million lbf (7.1 million N)

The advantage of abbr=unit is that the intention is clear for general readers. If that is not adequate, has there been a discussion at a relevant wikiproject? What is the unit name if abbr=off is used? What happens if lk=on is used? What is the default output unit? Exactly what are the similar units? Please link to a couple of articles where the units would be used. Johnuniq (talk) 09:11, 17 August 2022 (UTC)

spell=in and WP:MOS

I think, |spell=in contradicts MOS:NUMNOTES, namely, the spirit of "Comparable values nearby one another should be all spelled out or all in figures" and "Similar guidance applies where 'mixed units' are used to represent a single value". Is there any legitimate reason to represent the same value using words when expressed in one units but digits in other units? — Mikhail Ryazanov (talk) 21:32, 21 August 2022 (UTC)

If I want to add a conversion to Southern screamer's "can be heard up to two miles away", must I change that to "2 miles (3 km)" or have "two miles (three kilometres)"? If I add a conversion to "the fleas can jump up to two feet", do I have to change that to "up to 2 feet (0.6m)"? I can see an argument for rigorously staying within the extended implied spirit, but not allowing editorial discretion would go well beyond merely avoiding ages were five, seven, and 32 and five feet 11 inches tall. NebY (talk) 22:04, 21 August 2022 (UTC)

I think the MOS means

• "ranges from five feet (1.5 m) to over nine feet (2.7 m)" is correct
• "ranges from five feet (1.5 m) to over 9 feet (2.7 m)" is not correct

This would look terrible:

• "ranges from five feet (one point five metres) to over nine feet (two point seven metres)"

MB 22:12, 21 August 2022 (UTC)

I don't see any reason to write anything except "ranges from 5 feet (1.5 m) to over 9 feet (2.7 m)".

5 feet = 60 inches = 1+2⁄3 yards = ... Writing numbers as words in continuous quantities is a very strange idea in general. — Mikhail Ryazanov (talk) 23:24, 21 August 2022 (UTC)

I see the feet values as being comparable and the metre values being comparable but the feet and metre values are not necessarily comparable (being in a different scale). Even more likely to be words for feet and digits for cm. Editor discretion. Although my personal preference is digits for practically everything.  Stepho  talk  01:04, 22 August 2022 (UTC)

What about "five feet, or 60 inches" / "five feet (60 in)" and "five feet, or 1.7 yards" / "five feet (1.7 yd)"? — Mikhail Ryazanov (talk) 01:29, 22 August 2022 (UTC)

Feet and inches are also different scales (as in the value inches are scaled 12 times the value in feet), so again they can be different because one side has small numbers and the other has larger numbers. If decimal points or fractions are involved then the spelt out versions are clumsy, so digits are the way to go. At least that is my interpretation - others may interpret it differently. 02:09, 22 August 2022 (UTC)

How about finding a couple of articles where a change would make a difference. Show what the article currently says and propose what it should say. Johnuniq (talk) 03:28, 22 August 2022 (UTC)

Output multiple conversion is inconsistent with single conversion

See here for the list of output multiples for which the problem will occur. Using mass as our example:

Single conversion: {{convert|20|lb|st|abbr=on}} produces 20 lb (1.4 st) (non-breaking spaces are used as the separator across an entire value and breaking spaces separate distinct values)

Multiple conversion: {{convert|20|lb|stlb|abbr=on}} produces 20 lb (1 st 6 lb) (there is a breaking space within the value measured in multiple units)

Consistent output would be 20 lb (1 st 6 lb) Quindraco (talk) 16:15, 22 August 2022 (UTC)

I would say that the status quo is correct. The line could break between the two output values without causing confusion to readers parsing them because the number and unit are still kept as a single unit each; there shouldn't be a need for them to be kept together as a pair. Imzadi 1979 → 22:06, 22 August 2022 (UTC)

Kilograms per square centimeter?

A reliable British reference work I use gives ground pressure for armored vehicles in kilograms per square centimeter (kg/cm), yet this is not a possible parameter with this template afaik.

I'm American. Is kg/cm just not a common measurement? Schierbecker (talk) 03:21, 23 August 2022 (UTC)

I think you mean kg/cm2, not kg/cm (needs the 2 at the end)

{{cvt|100|kg/cm2|0}} gives 100 kg/cm² (1,422 psi)

{{cvt|100|kg/cm2|0|order=flip}} gives 1,422 psi (100 kg/cm²)  Stepho  talk  04:24, 23 August 2022 (UTC)

Thanks, User:Stepho-wrs! Exactly what I needed. Should this be listed under Pressure? It's not even listed on the unabridged list of units. Schierbecker (talk) 04:48, 23 August 2022 (UTC)

Pressure is supposed to be force per unit area. The SI unit pascal is newtons per square meter. If you assume a standard g, you can do it in mass per unit area, though it is best not to do that. Gah4 (talk) 06:01, 23 August 2022 (UTC)

Agreed, technically it should be one of:

{{cvt|100|kg-f/cm2|0}} gives 100 kg_f/cm² (1,422 psi)

{{cvt|100|kgf/cm2|0}} gives 100 kgf/cm² (1,422 psi)

But since we don't have tanks in space yet, it's a safe bet that the tank is at ground level at 1 g with 1 kg = 1 kg-f  Stepho  talk  06:08, 23 August 2022 (UTC)

Yes. The f was often neglected, perhaps especially when only measuring pressure and not performing coherent calculations with it, just as lb/in2 or simply psi sufficed (or p.s.i. if you wanted to be fancy). Even Kaye and Laby had in 1911 "1 ton/sq.inch = 1.545 x 10⁸ dynes/cm.² = 1.575 k.gm./mm.²". Kg/cm2 is a useful and long-standing redirect to Kilogram-force per square centimetre. NebY (talk) 08:33, 23 August 2022 (UTC)

I do see kg-f/cm2, kg/cm2, kgf/cm2 and similar in the unabridged list. I've added a link to that full list of pressure units to the head of the Pressure section of the abridged list in {{Convert/list of units}}. NebY (talk) 11:16, 23 August 2022 (UTC)

I suppose it is unitism. Since lbm and lbf are both commonly used units, and often enough you know which one is meant, it doesn't bother me the same way. Some time ago at a museum, there was a display of jet engines with thrust in pounds and kg. Since engine thrust is never in lbm, it seems obviously lbf. When I asked, it turns out that there is an official document for museums, that jet engines are in pounds and newtons. But kgf is a fairly rarely used unit, so I expect it should be explicit when it is meant. Gah4 (talk) 11:21, 23 August 2022 (UTC)

In older German language sources, the kilopond force per area, (typically square centimeters) is used almost exclusively for specific pressure: 100 kp/cm² (9.8 MPa);. Only very old (prior to the 1960s) sources may use kg/cm², but that is not very common; late 19th century engineers rather used technical atmospheres (at); 1 at = 1 kp·cm⁻². Technical atmospheres can also be specified (i. e. whether they are referring to absolute pressure (ata), higher pressure than the surrounding air, Überdruck (atü), or lower pressure than the surrounding air, Unterdruck (atu)). One must not confuse kp·cm⁻² (pressure) with kg·cm⁻² (area density). The latter is used in various technical contexts, for instance paper or steam production. In paper production, the area density is used to determine the mass of a sheet of paper with a certain area. That is because the thickness of a piece of paper cannot be determined easily, which is why a specific mass wouldn't be a useful figure to use. In steam boilers, area density is used to determine how much steam the boiler can produce per surface area that it has. This is a useful figure in tank engines that have to be compact to be usful for shunting, but also cannot have enourmous dimensions because of regular tracks' clearance diagrams. Simply said, a small tank engine with a good area density boiler is going to produce more steam and thus more power using a compact design. Best regards, --Johannes (Talk) (Contribs) (Articles) 11:33, 25 August 2022 (UTC)

Is there a gallons to acre-ft conversion?

I think this would be useful to be able to include in articles so that readers can start to understand this number, since people talk in gallons while water resource managers talk to journalists in acre-feet. Thanks!! ---Avatar317^(talk) 21:55, 24 August 2022 (UTC)

This is supported: 1,000,000 US gallons (3.1 acre⋅ft) MB 22:25, 24 August 2022 (UTC)

Thanks! I couldn't find it in the chart of documentation, which is why I asked. ---Avatar317^(talk) 23:02, 24 August 2022 (UTC)

Adjectives of measurement in English

Adjectives of measurement in English, such as foot, gallon, hour and other types of measurements are always in the singular. Brief examples include:

• He wore a 10 gallon hat.
• The 5 foot long snake was scary.
• and of course, from the Ballad of Gilligan's Island: "A three hour tour. A three hour tour"

Notice that none of these have a hyphen (-) included in them. The hyphen is not usual in English adjectives of measurement. If you enter {convert|3|ft|m|adj=on} (with duplicate braces) you will get "3-foot (0.91 m)" as the result. Without adj=on you will get "3 feet (0.91 m)" neither of which is the proper method of writing an adjective of measurement in English.

There is only one measurement in the Convert template that allows this type of adjective to be properly entered without abbreviating it, that is foot. You can use {convert|3|foot|m} (with duplicate braces) to get "3 foot (0.91 m)" as an answer. This is because you can spell out "foot." This is not the case with any other adjective of measurement and should be fixed in the template.

One other thing of note that I don't believe is included in this template is the case of 1 of a measurement. When there is only one, the 1 is not normally included, though as an exception it is included to emphasize it is one of the measurement.

• A foot long...
• The mile wide...
• A 1 pint measuring cup. (measuring cups often come in packages with several sized cups)

and so forth. Mike32065 (talk) 04:44, 28 August 2022 (UTC)

• @Mike32065: Convert follows the Manual of Style and MOS:UNITNAMES says to use a hyphen ("To form a value and a unit name into a compound adjective use a hyphen or hyphens"). It's true that convert always outputs a number (although that number can be give in words with |spell=in) so tricks may be needed if convert is wanted. For example:

A foot-long ({{convert|1|ft|cm|disp=out}}) hot dog → A foot-long (30 cm) hot dog

Johnuniq (talk) 05:25, 28 August 2022 (UTC)

• The hyphen is not usual in English adjectives of measurement. EEng 08:25, 28 August 2022 (UTC)

My copy of the 16th edition of the Chicago Manual of Style would disagree with you. On pp. 469–469 in § 9.13 under "Physical quantities in general contexts", it gives a set of examples, specifically:

• "a 40-watt light bulb"
• "a size 14 dress"
• "a 32-inch inseam"
• "a fuel efficiency of 80 miles per gallon (or 3 liters per 100 kilometers)"

In the text immediately before, it describes the second example as an exception to the hyphen rule and points to another section of the book for the reasoning. Various sections of the book discuss compound adjectives, and they all specify hyphens (or in rare cases, en dashes). Our MOS follows CMOS.

In short: the template is correctly formatting these. Imzadi 1979 → 09:09, 28 August 2022 (UTC)

The Stetson Hat Company does not agree with you. NebY (talk) 10:09, 28 August 2022 (UTC)

Are there era conversions (e.g., BP to AD, BCE to YBP)?

At MOS:ERA, the stated default calendar eras are Anno Domini (BC and AD) and Common Era (BCE and CE). Before Present (BP or YBP) is highlighted there as well. Are there era conversions, such as BP to AD or BCE to YBP? If not, could these conversions be developed? Additionally, could these conversions be developed in such a way that they work with dates ranges, as highlighted in MOS:DATERANGE? Daniel Power of God (talk) 01:00, 1 September 2022 (UTC)

Reading Before Present, BP and YBP are meant for long scales of time and take the "current" time as fixed at 1950. Which makes it a) not use to convert to an AD year and b) not possible to convert to an AD year. Eg, something that is 1500 BP will still be 1500 BP in 1950, 2000, 2022 and 2030. Any conversion between AD/BC/CE/BCE and BP/YBP would require some judgement by the editor.  Stepho  talk  01:13, 1 September 2022 (UTC)

Formatting error: invalid input when rounding

I'm trying to use Infobox settlement on my private wiki. However, I get "Formatting error: invalid input when rounding" when I attempt to use the area_total_km2 parameter. This happens with all the parameters related to area size, such as area_land_km2. There are no separators in the numbers. I've tried reimporting the Convert module and template, I've even asked for help in the MediaWiki Discord and Wikimedia Community Discord.

From my observations, the error happens when the template attempts to convert the km2 parameter to sq mi. I'm running Lua 5.1.5 on my wiki, which as of 5 September 2022 is the same version as what's running on Wikipedia. A diehard editor (talk | edits) 05:12, 5 September 2022 (UTC)

That message does not come from convert. It looks like it comes from Module:Math#L-456 so something (not convert) is rounding the infobox wikitext entry before convert is used. Johnuniq (talk) 06:46, 5 September 2022 (UTC)

What should I do to fix this, then? Should I modify Module:Math? A diehard editor (talk | edits) 07:06, 5 September 2022 (UTC)

Convert
Area
• Land	99 km2 (38 sq mi)

{{Infobox settlement|area_land_km2=99}} seems to work on WP (see right).

Can you give an example of it broken?  Stepho  talk  07:37, 5 September 2022 (UTC)

{{Infobox settlement|area_land_km2=99}} does not work on my wiki. Strangely enough, the sandbox page has the Category:Pages with non-numeric formatnum arguments category on it. A diehard editor (talk | edits) 08:12, 5 September 2022 (UTC)

Hmm, like John said, sounds like your local copy of {{Infobox settlement}} (or something it calls) is broken. To test convert itself, you can invoke convert directly (outside of Infobox settlement) and see what it does. At least it will tell you whether the blame is convert or something else. Unfortunately, I've already reached my level of competence.  Stepho  talk  08:30, 5 September 2022 (UTC)

Or could you post the Special:ExpandTemplates expanded code here? DePiep (talk) 08:42, 5 September 2022 (UTC)

With pagename "Anytown" and the code {{Infobox settlement|area_land_km2=99}}, I get this:

<div class="shortdescription nomobile noexcerpt noprint searchaux" style="display:none">Place</div>[[Category:articles with short description]]<table class="infobox ib-settlement vcard"><tr><th colspan="2" class="infobox-above"><div class="fn org">Anytown</div></th></tr><tr class="mergedtoprow"><th colspan="2" class="infobox-header">Area<div class="ib-settlement-fn"></div></th></tr><tr class="mergedrow"><th scope="row" class="infobox-label"> • Land</th><td class="infobox-data">99 km<sup>2</sup> ([[Category:Pages with bad rounding precision]]<span data-sort-value="Bad rounding here"></span><strong class="error">Formatting error: invalid input when rounding</strong> sq mi)</td></tr></table>[[Category:Pages using infobox settlement with missing country]][[Category:Pages using infobox settlement with no map]][[Category:Pages using infobox settlement with no coordinates]]

A diehard editor (talk | edits) 08:45, 5 September 2022 (UTC)

Editng {{Infobox settlement|area_land_km2=99}}, on a new page and a "Show Preview" and you'll see that in the Templates used section, there is no convert. So you are looking in the wrong place. You need to check all the temlates and modules listed in the Templates used section and compare the enwiki version with your version. -- WOSlinker (talk) 09:23, 5 September 2022 (UTC)

It seems like Template:Max and Template:Order of magnitude were missing from my wiki. After importing them, I'm glad to say that it now works properly! A diehard editor (talk | edits) 09:34, 5 September 2022 (UTC)

Decimal-point alignment for disp=table?

Is it possible to implement decimal-point alignment in the template? I'm surprised that {{Decimal-align}} is not even mentioned in the documentation, but it would be much more convenient to have similar functionality built in. Especially if instead of specifying the point position in percent of the cell width (and leaving to the user to ensure that the cell width is sufficient) it will add the necessary amount of {{0}} padding before of after (for left/right cell alignment) the output value. — Mikhail Ryazanov (talk) 14:27, 5 September 2022 (UTC)

That's a lot of bloat but I guess it's fair for how the internet is these days. You would have to spell out a specification for any wanted parameters and exactly what the output should be. Special:ExpandTemplates shows that {{decimal-align|{{convert|1|usoz|uspt usqt usgal|disp=tablecen}}}} generates the following wikitext (see first example in documentation at Template:Decimal-align).

style="text-align:center;"%|<span style="float: left; text-align: right; width: 50%;">1</span>
|style="text-align:center;"%|<span style="float: left; text-align: right; width: 50%;">0</span><span style="float: right; text-align: left; width: 50%;">.063</span>
|style="text-align:center;"%|<span style="float: left; text-align: right; width: 50%;">0</span><span style="float: right; text-align: left; width: 50%;">.031</span>
|style="text-align:center;"%|<span style="float: left; text-align: right; width: 50%;">0</span><span style="float: right; text-align: left; width: 50%;">.0078</span>

Johnuniq (talk) 01:04, 6 September 2022 (UTC)

I actually don't like how {{Decimal-align}} works and think that the {{0}} approach would be better. That is, after calculating the output string, count the number of digits before/after the decimal point, and if it's less than desired number of places (something like |leftfig=/|rightfig=, in line with |sigfig=), pad it with invisible missing zeros. If this idea is interesting at all, we can discuss the details... — Mikhail Ryazanov (talk) 01:23, 6 September 2022 (UTC)

Rounding to nearest even number/digit

It's quite usual to want to round to an even last digit – an example is in kg to lb conversion where (for integer kg) |0 is excessively precise, and |round=5 not precise enough. Any reason not to add 2 (and perhaps some 2·10ⁿ?) to the allowable values for |round? Thanks, Justlettersandnumbers (talk) 09:48, 15 September 2022 (UTC)

I haven't come across that. I think the proposal is that, with an extra option, if converting kg to lb gave 3.1 lb, the displayed value would be 4 lb? And 2.9 lb would show as 2 lb? Why? Is there an example article where that would help? Johnuniq (talk) 11:03, 15 September 2022 (UTC)

Possibly the OP is thinking of Rounding#Round_half_to_even. EEng 16:25, 15 September 2022 (UTC)

Sounds like half-to-even indeed. It is called "Bankers rounding", and this is why: if a banker has to round say 1000 random $-amounts that are in whole cents ($0.01) into whole $ ($1.00), common rounding says "0.50 -> round upwards". But this would systematically round middle-numbers upwards (in 1000 random amounts, 10 could an x.50, all going up. OTOH, with "round to even", ~5 of those 10 would be rounded downwards -> systemaic bias cancelled. Only relevant with descrete digits (like cents), not e.g. log-numbers (where exact x.50 would be rare). HTH -DePiep (talk) 19:36, 15 September 2022 (UTC)

Well, rounding half to odd would have all the same advantages. Why not call that "banker's rounding"? EEng 21:20, 15 September 2022 (UTC)

Bankers like to be even handed. Hawkeye7 (discuss) 00:57, 16 September 2022 (UTC)

Odd you should say that. EEng 02:09, 16 September 2022 (UTC)

"half to odd" is "bankers rounding" (see the link in your post). DePiep (talk) 06:27, 16 September 2022 (UTC)

Um, no it's not. EEng 07:54, 16 September 2022 (UTC)

It is. As described, and in the link you provided yourself. So far for irrelevancies. Crucial is the discreteness of the .5 value (as opposed to real numbers which can have endless decimals). DePiep (talk) 07:15, 23 September 2022 (UTC)

Nope. I just re-read EEng's link to Rounding#Round_half_to_even. It explicitly says Banker's rounding is another name for rounding to even. Then the next section says rounding to odd is similar and has most of the same properties (in terms of bias). They are variations on a theme, share many properties but are not quite the same thing.  Stepho  talk  07:56, 23 September 2022 (UTC)

Rabbit hole. DePiep (talk) 08:34, 23 September 2022 (UTC)

We'll take that as shorthand for, "As usual, I've been arguing with multiple people while firmly grasping the wrong end of the stick." EEng 09:57, 23 September 2022 (UTC)

Statistically, if you have a large number of numbers, you do this to make sure that there is no systematic error. For the small number, often one, used here, that isn't likely. In most cases, the conversion constant will have enough digits not to come out exactly half. Gah4 (talk) 09:00, 23 September 2022 (UTC)

Deadweight tonnage

Deadweight tonnage was historically expressed in long tons but is now usually given internationally in tonnes (metric tons). Because Americans spell metric measurements differently to the rest of the world, we have the sp=us card. But

{{convert|23,000|DWton|sp=us}} gives 23,000 deadweight tons (23,000 deadweight metric tons)

and not "deadweight metric tons" as I expected. Hawkeye7 (discuss) 00:54, 16 September 2022 (UTC)

I can't think at the moment so I'm dumping some relevant units and hoping that someone can work what should happen. |sp=us will only affect t and tonne because they are the only units with a name1_us value.

unitcode	scale	link	default	symbol	name1	name1_us
DWton	1016.0469088	Deadweight tonnage	DWtonne	~deadweight ton	deadweight ton	–
DWtonne	1000	Deadweight tonnage	DWton	~deadweight tonne	deadweight tonne	–
metric ton	1000	Tonne	long ton	~metric ton	metric ton	–
MT	1000	Tonne	LT ST	t	metric ton	–
t	1000	Tonne	LT ST	t	tonne	metric ton
tonne	1000	Tonne	shton	t	tonne	metric ton

Johnuniq (talk) 04:30, 16 September 2022 (UTC)

Explanation: The 'scale' means DWton is defined as 1016.0469088 kg (like "long ton") and DWtonne is defined as 1000 kg (like "metric ton"). The tilde in 'symbol' means s is appended to the symbol for plural values. Johnuniq (talk) 07:22, 16 September 2022 (UTC)

So what we need to do is add a name1_us to DW_tonne that says deadweight metric ton? Hawkeye7 (discuss) 19:43, 22 September 2022 (UTC)

@Hawkeye7: No problem to me, but is that long name really wanted? I guess the answer is yes in which case the symbol (for when abbr=on is used) should also show that long name. As an experiment, I have added a new unit called DW-tonne which is the same as DWtonne above except that DW-tonne defines sym_us and name1_us. Examples:

• {{convert|2|DW-tonne|kg}} → 2 DW-tonne
• {{convert|2|DW-tonne|kg|sp=us}} → 2 DW-tonne
• {{convert|2|DW-tonne|kg|abbr=on|sp=us}} → 2 DW-tonne

Please try DW-tonne. If it ends up being used I will eventually upgrade convert by replacing DWtonne with DW-tonne. When I do that I will also fix any articles using the new unit by replacing "DW-tonne" with "DWtonne". Johnuniq (talk) 00:05, 23 September 2022 (UTC)