Template talk:Convert/Archive 3

Archive 1

Archive 2

Archive 3

Requested unit: lboz/

Hello and thank you for working on Convert. Although lb/acre does exist there is no lboz/ per unit. This is likely to not be too difficult. Invasive Spices (talk) 10 May 2022 (UTC)

Do you know any practical uses in wiki? Example article? -DePiep (talk) 17:55, 10 May 2022 (UTC)

In this edit I would have used {{convert|2–12|kg/ha|lboz/acre}} rather than the {{convert|2–12|kg/ha}} I did use. Invasive Spices (talk) 13 May 2022 (UTC)

a strange conversion

Deutschland-class_cruiser#Machinery has three conversions from t to LT of which one makes absolutely no sense. 2750t to 2710LT looks ok as does 2410t to 2370LT but 2500t = 2500LT ?!? --Denniss (talk) 21:49, 11 May 2022 (UTC)

See the very first Q & A at the top of this talk page. -- Dr Greg  talk  21:52, 11 May 2022 (UTC)

and again this not a good behaviour. If I want to convert soemthing I do not want to simply translate/change the unit but have a proper conversion. Especially for units with very limited difference, this problem is also seen with PS/hp conversions.--Denniss (talk)

It's due to rounding. Convert sees 2 zeroes at the end and thinks that you want the answer also rounded to 2 zeroes. Try adding |round=10, |-1, |sigfig=3 or similar. See Help:Convert#Rounding.  Stepho  talk  23:53, 11 May 2022 (UTC)

This is #Broken conversion all over again. --Redrose64 🌹 (talk) 22:03, 12 May 2022 (UTC)

I suspect in many cases people aren't reasonably considering Sigfigs. Often enough, values are intended to be approximate, and this is especially likely with the various ton units. Someone might say that their car weighs 3 tons, which does not mean that they believe 3.000 tons. And so, yes, 3LT converts to 3t. And, even more, showing it reminds people of this. Gah4 (talk) 07:16, 14 May 2022 (UTC)

Next to this sigfix point, there is also this:I assume that meter-converted-to-feet can not and should not reproduce the exact uncertainty limits similar to the measurement value: an uncertainty (0.5 m) should not be converted as "(0.5 m) .. (1.6 ft)". The derived value should not suggest same or even extra precision; a wider range is acceptable. -DePiep (talk) 10:44, 14 May 2022 (UTC)

The usual rules are explained in Sigfigs, but most often you are allowed one extra digit. I was in college not so long after electronic calculators became widely available. We liked to write all answers down with 10 digits and our TAs would mark them wrong with SIGFIGS in big red letters. We learned fast. But okay, 0.5m suggests an uncertainty of 0.05m, or 10%. 1.6ft suggests 0.05ft, or 3%, while 1.ft would suggest 50%. So 1.6ft doesn't lose precision, and isn't excessive. But if this is an actual uncertainty, then one normally doesn't need to be too precise. Decimal digits are a rough indicator, and often not perfect. Gah4 (talk) 18:08, 14 May 2022 (UTC)

I meant to say: "(0.5 m) is the imprecision eg of measurement 1 m" (meaningless to take a "0.05" imprecision of an imprecision). IOW: What is the converted imprecision (in ft) when the original measurement is "1(0.5) m"? -DePiep (talk) 18:57, 14 May 2022 (UTC)

Yes, it gets more complicated for that one. One rule is that you are allowed one extra digit for intermediate values, but that isn't especially helpful. It seems not unusual to have two digit uncertainty, but more than that seems like too much. Two digits especially if the left digit is a 1 or 2. I suspect, though, that these details are too much for {{convert}}. Gah4 (talk) 20:42, 14 May 2022 (UTC)

Quoted text

I know it's not standard, but in quoted text it could happen to find non-spaced units ymbols suc as 40kg and 10kg in this caption. Is it possible to suppress the automatic spacing in Convert to render the original text formatting?--Carnby (talk) 05:14, 9 May 2022 (UTC)

If you are doing exact quotes then surely you would not be using convert? And conversely, if you are using convert then you are not doing exact quotes. WP allows us to do simple mods to quotes for upper/lowercase, fonts, spacing, etc. And if a user does cut and paste from an article to form a web search, then the popular search engines automatically ignore spacing differences anyway.  Stepho  talk  06:11, 9 May 2022 (UTC)

A possible workaround would be this: "bringing an impressive 40kg [88 lb] reduction"—source:40kg <noinclude>[{{cvt|40|kg|lb|disp=out}}]</noinclude>.--Carnby (talk) 05:37, 10 May 2022 (UTC)

Normally we would express it in WP's own voice (with conversions) and then tack on a reference. Eg, reducing the weight by {{cvt|40|kg|0}}<ref>blah-blah-blah.com/waffle-waffle/</ref> No need for exact quotes in the majority of instances.  Stepho  talk  07:18, 10 May 2022 (UTC)

What Carnby is suggesting is exactly what WP:MOSNUM#Quotations,_titles,_etc. calls for. EEng 22:16, 10 May 2022 (UTC)

... and so then do c/p literally without {{Convert}}, maybe using the extras. -DePiep (talk) 23:07, 10 May 2022 (UTC)

@Carnby: I would say that no change is needed to the template. In the given example, we aren't beholden to omit the space between number and unit, even in a direct quote. That would be a matter of style, and we can and should conform our content to our house style as a minor change. I would even say the choice on spelling out vs. abbreviating the unit of measure ("kilogram" vs. "kg") is a minor change that we could make in a direct quotation. Now the converted value is not present in the original quotation, so it should be set off in square brackets, which one can do with |disp=sqbr in the template. Imzadi 1979 → 23:26, 10 May 2022 (UTC)

@Imzadi1979: Thank you, I decided to use in ‎this page {{convert}} ignoring the fact that in the original text there were no spaces; anyway the suggestion by @DePiep is worth mentioning.--Carnby (talk) 05:38, 17 May 2022 (UTC)

conversions using the frac parameter are not accessible with screen readers

the resulting output when frac is used either reads as "math", the formula or nothing at all depending on the screen reader used, not the actual text displayed visually. The same is true when a virtual assistant such as Siri tries to read frac output.

Because of this, I've taken to removing 'frac' when I come across it so it renders as decimals, which are of course accessible. My reason being is the information being readable by everyone is more important than how it looks.

I'm not sure how this could be fixed, but I'd suggest encouraging people not to use frac until this is sorted. KaraLG84 (talk) 13:32, 22 May 2022 (UTC)

I don't think removing frac this way & reason is not correct. -DePiep (talk) 13:48, 22 May 2022 (UTC)

(Please understand that my double negative is to strengthen not to nullify my point ;-). -DePiep (talk) 16:52, 23 May 2022 (UTC)

Systematically reverting accepted wikitext without first gaining clear consensus with a well publicized WP:RFC is disruptive. Johnuniq (talk) 23:47, 22 May 2022 (UTC)

I have only seen frac being used maybe 3 times so it seemed to me that using decimals was the more widely accepted wikitext. My intention was not to be disruptive, just to make the text more readable. KaraLG84 (talk) 08:33, 23 May 2022 (UTC)

The goal of making it readable by everyone (including sight impaired readers) is a good one. But this needs to be raised at the {{frac}} talk page at a minimum and (due to its wide-spread use) probably at one of the MOS talk pages. Since this is such a useful template, it would be better to fix the template than to try to wipe it out. By using a template, the output can be rendered in a manner that is safe (decimal if required, or possibly by detecting the screen reader or some variation of CSS that screen readers use that is ignored by normal browser usage) and as we find better ways to render it (or screen readers get better) then we can automatically make every article better. Your alternative of making every article do it manually is that every article will wind up dozens of variations of with hard-coded HTML/CSS (which is also hard for screen readers) and automatic improvements will be hard.  Stepho  talk  23:59, 22 May 2022 (UTC)

I had no idea that frac itself had it's own talk page so thanks for letting me know.

Yes, agree that it needs to be fixed at the template level rather than by folk like me upsetting the apple cart, so I will drop them a message. I was unaware how many articles use it as I've only come across maybe 3 instances, so It seemed to me like decimals was more common. KaraLG84 (talk) 08:40, 23 May 2022 (UTC)

Issue with 'adjective' and 'and'

From today's (22/05/22) FA, Mars, 2nd para 1st line from link.

which had 30 and 45 centimetres (12 and 18 in) telescopes.

wiki - which had {{convert|30|and|45|cm}} telescopes.

which should read "which had 30- and 45-centimetre (12- and 18-in) telescopes."

But when you use the adjectival form you get,

which had 30-and-45-centimetre (12 and 18 in) telescopes.

wiki - which had {{convert|30|and|45|cm|adj=on}} telescopes.

Too many hyphens in one set of measurements and not enough in the other. Is this the expected/desired output? Skullcinema (talk) 15:25, 22 May 2022 (UTC)

Yes, that's perfect except that the word "diameter" is missing. Readers are assumed to be smart enough to understand that the stuff in parentheses shows the conversions and does not have to be equivalent to the earlier text. Try this:

• {{convert|30|and|45|cm||-diameter|adj=mid}} telescopes → 30-and-45-centimetre-diameter (12 and 18 in) telescopes

Johnuniq (talk) 23:51, 22 May 2022 (UTC)

You don't need the word diameter when discussing telescopes, it is assumed (in the same way it is for guns). Even if you ignore the "stuff in parantheses" the earlier text is not correct the and isn't part of the measurement, which is what the template is implying by hyphenating it to the numbers. As this appears to have been an issue since 2010 I have just ripped out the template as it isn't doing its' job properly. Skullcinema (talk) 09:56, 24 May 2022 (UTC)

Non-breaking space for thousands separator

I noticed on the Mars Climate Orbiter page that 638 kg was converted to 1,407 lb--a correct conversion, for the most part, except the formatting is potentially ambiguous for people who are used to seeing a comma as a decimal separator rather than a dot. ISO standards, as well as SI guidelines, allow either a period or a comma as a decimal separator but require a non-breaking space for the thousands separator in order to prevent ambiguity. I have seen other Wikipedia articles follow this standard, but it would appear that the thousands-separator comma is built into the template. And yeah, I know that pounds are English units and English speakers never use a comma there, but clarity can't hurt, and there may be other conversions that also do this. Thank you! -136.56.31.46 (talk) 16:09, 25 May 2022 (UTC)

See Help:Convert#Thousands separator.

I notice you have also replaced commas in values at British thermal unit‎ with spaces using &nbsp;.[1] Please don't do that. Our Manual of Style covers this at Wikipedia:Manual of Style/Dates and numbers#Grouping of digits, explaining that non-breaking spaces are problematic for screen readers and that templates {{val}} or {{gaps}} may be used instead. (Another reason is that such values can't usefully be pasted into eg spreadsheets for processing.) Those templates will not leave us with results such as your 1 055.05585257348, in which the digits after the decimal point have not been grouped. NebY (talk) 17:14, 25 May 2022 (UTC)

Ah...I didn't even realize that last part. I guess I'll try using those templates, then. Thank you! -136.56.31.46 (talk) 13:13, 26 May 2022 (UTC)

Requested units USCWT and UKCWT

The American hundredweight is widely used in commodity foods and so USDA statistics use it. For example in this edit I would have used USCWT if it were available. Thank you. Invasive Spices (talk) 11 June 2022 (UTC)

lcwt & scwt units are available to use. 1 long hundredweight (110 lb) & 1 short hundredweight (100 lb) -- WOSlinker (talk) 19:34, 11 June 2022 (UTC)

Apologies for taking your time. I didn't know where to find it in the documentation. (Module:Convert/documentation/conversion data#Mass for anyone else with the same problem.) Invasive Spices (talk) 12 June 2022 (UTC)

"inches"

Would it be possible to add this as while it would seem like a rational input to use, it's apparently not currently supported by the template? If it isn't problematic in some way to add that to the template's list of accepted values, having a little more flexibility to that editors don't have to memorize exact parameters that are acceptable would be nice. Hog Farm _Talk 05:01, 12 June 2022 (UTC)

It would probably be a good idea to accept inches as well as the current in and inch. Convert already handles plurals for feet + meters/metres + miles + yards and accepting inches would finish the plurals for common lengths and masses. I added the unit, example:

• {{convert|6|inches}} → 6 inches (150 mm)

Johnuniq (talk) 05:20, 12 June 2022 (UTC)

(edit conflict) While writing this reply, the original error {{Convert|6|inches|cm}} N stopped reproducing... -DePiep (talk) 05:24, 12 June 2022 (UTC)

{{Convert|0.5|miles|km}} → 0.5 miles (0.80 km)

{{Convert|6|inches|cm}} → 6 inches (15 cm) N → Y

:-) DePiep (talk) 05:24, 12 June 2022 (UTC)

Thanks, y'all! Hog Farm _Talk 05:30, 12 June 2022 (UTC)

Temperature difference?

I don't see any way to make this display a conversion for a temperature difference. Where I saw the problem when someone else used the template was that they wanted to display the difference between record highs, but converting 1°C resulted in 34°F when the desired output would be 1.8°F. So am I missing something, or is this not a functionality of this template? --Gimmethegepgun (talk) 09:51, 19 June 2022 (UTC)

@Gimmethegepgun: It's documented, example:

• {{convert|1|C-change}} → 1 °C (1.8 °F)

Johnuniq (talk) 09:57, 19 June 2022 (UTC)

Requested units: solar mass, solar radius, solar luminosity

The {{val}} template supports these units,[2] but {{convert}} apparently does not. They can be of use in astronomy articles, such as close binaries where the stars are just a few solar radii apart and the source distances are given in 10⁶ km (i.e. Gm). Thank you. Praemonitus (talk) 12:45, 12 June 2022 (UTC)

Solar mass: 1 solar mass (2.0×1030 kg) & Solar radius: 1 solar radius (700,000 km) are already supported. Just luminosity that is not currently. -- WOSlinker (talk) 16:22, 12 June 2022 (UTC)

Is there nothing Convert can't do? EEng 16:30, 12 June 2022 (UTC)

SCFM, SCFH and all their illegitimate siblings and cousins, and quite right too! (It does have SCF but treats it as a unit of energy, presumably on the assumption that it's being used of a some particular flammable gas mixture and referenced to a particular choice of standard conditions; whereas it's often used of eg compressed air and referenced to a variety of "standard" temperatures and pressures, so that's a shame.) NebY (talk) 17:21, 12 June 2022 (UTC)

Well, I meant other than SCFM, naturally. EEng 17:08, 19 June 2022 (UTC)

And it is disgraceful that that article doesn't have a wp:short description. Which must not exceed 40 characters of course. I have left it "as an exercise for the reader". --John Maynard Friedman (talk) 21:48, 19 June 2022 (UTC)

A deprecable vague unit of measurement (38 characters) NebY (talk) 21:59, 19 June 2022 (UTC)

Crore

Any way to use crore, for measurements like xyz crore rupees? (Please ping) Ovinus (talk) 15:03, 27 June 2022 (UTC)

MOS:CRORE indicates that crore is discouraged in Wikipedia. I suggest that the convert template should not support notation that is discouraged in the "Manual of Style/Dates and Numbers". Jc3s5h (talk) 18:44, 27 June 2022 (UTC)

Fair enough. Ovinus (talk) 18:50, 27 June 2022 (UTC)

Crore isn't a unit any more than million is a unit. EEng 19:35, 27 June 2022 (UTC)

There is a template that you can use for some things though. {{crore}}. -- WOSlinker (talk) 20:23, 27 June 2022 (UTC)

Also, Ovinus wrote like xyz crore rupees - {{Convert}} does not (and is not intended to) handle currency conversions. --Redrose64 🌹 (talk) 08:08, 28 June 2022 (UTC)

Use User:Ohconfucius/script/formatgeneral.js to convert lakh and crore into other measurements such as millions. -- Ohc ^{revolution of our times} 19:50, 28 June 2022 (UTC)

grams or grains?

Default conversion unit for mg is gr,which is grains, not grams. This is almost certainly a mistake. —Soap— originally signed as Lollipop (talk) 23:57, 15 July 2022 (UTC)

This appears correct. 1 grain ≈ 65 mg. Compared to 1 ounce ≈ 28 g (28,000 mg). Nobody requires help converting from milligrams to grams (just times by 1000 or shift the decimal point 3 digits). What other unit would you use?  Stepho  talk  01:02, 16 July 2022 (UTC)

With all due respect, there's at least one person who has trouble with metrics [3]. EEng 01:16, 16 July 2022 (UTC)

Also with due respect, but I could never understand how Americans can't shift the decimal point by 3 digits yet are able to somehow convert 70 ounces to 4+3⁄8 pounds (I used a calculator for that). While the rest of the world has no trouble at all shifting that decimal point. Not disagreeing with you - I just don't understand it.  Stepho  talk  01:57, 16 July 2022 (UTC)

I'm guessing you didn't click on my link. EEng 02:27, 16 July 2022 (UTC)

Oops, I missed that link, my hind brain thought it was just part of your signature. Apologies for my rant.  Stepho  talk  04:26, 16 July 2022 (UTC)

Think nothing of it. My editing day's not complete unless I'm the target of at least one good rant. EEng 04:42, 16 July 2022 (UTC)

Why restrict the uses of the convert template based on a personal bias? If somebody has a reason to use the convert template to translate mg to g, just let them. It may be for a valid reason you haven't thought about. Praemonitus (talk) 02:16, 16 July 2022 (UTC)

No one's restricting any uses. The OP was talking about the default. EEng 02:27, 16 July 2022 (UTC)

The original post is about the default conversion. Here's an example of converting milligrams to grams by specifying both: 1 milligram (0.0010 g). Jc3s5h (talk) 02:27, 16 July 2022 (UTC)

Is there an echo in here? EEng 02:29, 16 July 2022 (UTC)

Well Im not embarrassed to admit that I was confused last night when I saw a fish described as being 1 milligram (0.015 gr). The grain is a very uncommon unit, and certainly not used in biology. I assumed gr was an abbreviation for gram and that there was a math error in the template until i looked more closely and saw that a math error was unlikely. Even someone who clearly understands that a milligram is 1/1000 of a gram might still make the same mistake I did, or not even think about the existence of a template and assume that two Wikipedia editors disagreed with each other. I just don't think the grain is the best choice of a default measurement if the input is in milligrams. —Soap— 08:58, 16 July 2022 (UTC)

A 1-milligram fish? That's one goddam tiny fish. EEng 02:18, 18 July 2022 (UTC)

Correct me if I'm wrong, but I was under the impression that anglers tended to overestimate the size of "the one that got away", as in "it was seven pounds, easily. No, eight. Possibly nine. Or ten. Might have been eleven". I've never heard them verifiably weighed smaller than a few ounces, anyway. --Redrose64 🌹 (talk) 19:56, 18 July 2022 (UTC)

Not all measurements need to be converted. In the case you described, nobody is more comfortable weighing tiny animals in grains than in milligrams, so the article should not give a conversion - it benefits no one. Conversions should only be supplied when more than one system is used worldwide in the field under discussion. Indefatigable (talk) 01:24, 18 July 2022 (UTC)

Grains were commonly used in medicines. The article should always provide a conversion to metric. If the source is already in metric then conversion is optional. Hawkeye7 (discuss) 03:23, 18 July 2022 (UTC)

• I guess there's a lack of real editing that needs doing because this is a colossal waste of time. The default conversion isn't going to be changed (if for no other reason than that would require a search-and-destroy mission for existing invocations that depend on the current default). The rules for when to provide conversions are carefully set out already. Our sovereign lord the King chargeth and commandeth all persons, being assembled, immediately to disperse themselves, and peaceably to depart to their habitations, or to their lawful business. EEng 03:47, 18 July 2022 (UTC)
  P.S. I'm pretty sure I've said this before: in retrospect, for convert to have defaults was probably a bad idea. It eases editing only the tiniest bit, but periodically causes surprises and confused discussions such as this one.

  The purpose of the default is to provide uniformity between articles so people don't have to wonder about what output unit would be appropriate for whatever input unit they are dealing with. The defaults certainly have problems, but the uniformity is useful. Johnuniq (talk) 07:17, 18 July 2022 (UTC)

  Except there isn't always one clear choice of output unit; if there was (were? -- I can never remember) then there'd be just one and only one rigid output unit for any given input unit, with no choices. I think the cases in which a choice needs to be consciously made outweigh the cases in which giving the editor a choice leads to a "bad" choice (which is essentially the uniformity argument). But let's not debate it, since the point is moot. EEng 13:35, 18 July 2022 (UTC)

  "just one and only one rigid output unit"?, "with no choices"? That's not how "default" is understood to be. As Johnuniq gently clarified: no need to wonder, and if one does have a preference -- free to use it. What is the problem? -DePiep (talk) 17:51, 18 July 2022 (UTC)

  The problem is that, as usual, you've misunderstood my comment and responded with nonsense. It's as if there's something in my signature that knocks 40 points off your IQ. EEng 20:32, 18 July 2022 (UTC)

  You have turned a content post into a personal attack. DePiep (talk) 19:56, 1 August 2022 (UTC)

  Still clueless after all these years [4]. EEng 20:07, 1 August 2022 (UTC)

Rounding

I reverted this edit at Help:Convert by MaxEnt with the suggestion that issues should first be raised here. The edit noted that the following give poor rounding results.

• {{convert|1/4|mi|ft m|0|abbr=on|lk=on}} → 1⁄4 mi (1,320 ft; 402 m)
• {{convert|1,000|ft|mi m|2|abbr=on}} → 1,000 ft (0.19 mi; 304.80 m)

Convert is not compulsory and if particular conventions apply to these measurements, it's ok to write them in normal wikitext. However, what is the problem with the following?

• {{convert|1/4|mi|ft m|round=5|abbr=on|lk=on}} → 1⁄4 mi (1,320 ft; 400 m)
• {{convert|1,000|ft|mi m|sigfig=2|abbr=on}} → 1,000 ft (0.19 mi; 300 m)

The help text might say a little more and might admit that convert cannot handle every situation. However, adding text can make a help page too long to be helpful. Johnuniq (talk) 02:03, 2 August 2022 (UTC)

His edit {{convert|1,000|ft |mi m|2 0|abbr=on}} had the rounding factor as 2 0, which might have caused some (all?) of his problem.  Stepho  talk  02:26, 2 August 2022 (UTC)

Breaking hyphen

I notice that in uses like {{convert|47|acre|adj=mid}}, which produces 47-acre (19 ha), this template generates a breaking hyphen rather than a non-breaking hyphen. Per MOS guidance, a non-breaking hyphen should be here instead. Could this be fixed? {{u|Sdkb}} ^talk 16:01, 1 August 2022 (UTC)

• @Sdkb: the MOS link leads to MOS:NBSP and describes how to handle non/breaking whitespace etc. However, it does not mention hyphen linebreaking. MOS:HYPHEN says {{nbhyph}} "does not linebreak", but there is no advice or guideline on preventing/allowing it. What situations do you think need linebreak prevention? -DePiep (talk) 20:05, 1 August 2022 (UTC)
• Unfortunately, the advice on linebreak handling when units are involved is a mess, and a talk thread on the subject has been in suspended animation for quite some time. However, as things stand the recommendation is that break be prevented where a unit symbol is involved (e.g. 47 ft), but allowed where a unit name is involved (47 feet). Those examples use spaces, of course, but when we switch context to hyphens an oddity arises, as seen in the example given in the OP: hyphens are only used with unit names, never with unit symbols, so if we translate the advice for spaces to hyphens, we'd allow a break -- in the only case in which hyphens appear i.e. with unit names. I hope that made sense. EEng 20:30, 1 August 2022 (UTC)
• @DePiep and EEng: Thanks both for weighing in, and thanks EEng for the background. Looking into it, I guess the MoS doesn't offer us a firm answer on this, which means we can decide here what to do. However, the MoS does say a bit about the spirit of when non-breaking is appropriate (where breaking across lines might be confusing or awkward), and it provides a bunch of examples. To me, it seems like if something like 11 billion should be kept on one line, then 47‑acre should be, too. What do the two of you (and anyone else watching) think? {{u|Sdkb}} ^talk 02:14, 3 August 2022 (UTC)

  Well don't read too much into that "where it might be confusing or awkward" stuff, because I'm pretty sure I wrote it (and the examples too), as a first stab at what was intended to grow into something more definitive, but which to date has just sat there.

  You mention 11 billion, but the example given is actually £11 billion, and there's a difference, because annual budget of £11
  billion reads as "annual budget of 11 pounds ... oops ... wait, 11 billion pounds ..." -- the brain has to back up and cancel the interpretation it's already made -- whereas that can't happen with as many as 11
  billion tweets are sent annually. (Admittedly, the annual number of tweets could be up to 11
  billion could be problematic, so you see how complicated it gets and why I've never got the nerve up to try and sort the whole matter out.) EEng 03:03, 3 August 2022 (UTC)

New unit?

Should Mu be available as an area; this article says it "is common" in South Asia. I found it being used in Guizhou Medical University, but haven't searched for more cases. MB 14:48, 5 August 2022 (UTC)

Britannica spells it Mou and says that is Chinese, not South Asian. "Mou". Britannica. --John Maynard Friedman (talk) 19:23, 5 August 2022 (UTC)

We have a redirect Mu (unit), which is also listed as an alt spelling of Mou on MOU (disambiguation). The target is a table that lists it as "mǔ". MB 19:34, 5 August 2022 (UTC)

Worth noting that Britannica says that it has had multiple definitions over time (our Chinese units of measurement#Area gives it as 614.4 m² in 1915, 6662/3 m² in 1930). Is it safe to provide automatic conversion? ----John Maynard Friedman (talk) 23:05, 5 August 2022 (UTC)

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)

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)

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)

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/Archive 3
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)

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)

Thanks. I have used it on American services and supply in the Siegfried Line campaign with the expected results. This should keep the reviewers happy in preventing the appearance of the international spelling in an otherwise AmEng article. Hawkeye7 (discuss) 21:47, 23 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)

Again, EEng is transgressing from a content discussion to personal attacks in one reply. DePiep (talk) 09:30, 24 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)

  "Exactly half" has nothing to do with it; the question applies any time the final digit is 5 and you wish to round away just that digit. The examples in our rounding article are all x.5 simply for convenience; they could just as well have been 0.x5 or 0.xx5 or xxx500. EEng 10:06, 23 September 2022 (UTC)

  Maybe the wording wasn't so obvious, but yes it is the case where there is only one digit and it is 5. Now, consider lbm to kg: 0.45359237. If you multiply that by just about any number, and round to 2 or 3 or 4 digits, it won't end in just 5. More often, the problem is too many digits, or not enough rounding. But in any case, the important case is when you have thousand or millions of rounded values. The uncertainty of each one might be large enough, but the uncertainty in the mean is much less. Statistically it can matter. But not so much for just one value. Gah4 (talk) 21:01, 23 September 2022 (UTC)

  I was an expert witness in a gazillion-dollar lawsuit involving patents on (wait for it ...) machine arithmetic, so I really know what I'm talking about here. What you just said (yes it is the case where there is only one digit and it is 5) is incorrect, and what I said just above is correct. And this isn't about "uncertainty"; it's about the deliberate introduction of error. EEng 01:49, 24 September 2022 (UTC)

  "Exactly half" has nothing to do with it -- No, it is exactly what OP is about. If the input numbers are discrete (fixed number of decimals, like $cents), then rounding to even[/odd] cancels out large scale bias (because otherwise, all discrete 0.50 will be rounded up=systematic bias). This also has this point: to cancel the ('5 always-up') bias out, it requires many numbers to total. Doing so with {{Convert}} stand alone numbers, would not be an improvement (the canceling out is over the whole enwiki), nor scientifically meaningful.

  Then, I repeat: does not work with real numbers i.e. many decimals. Because (1) occurances of exactly -5- at your predefined decimal position is rare. Also, (2) rounding the number twice is statistically not acceptabele. Fore example, rounding a weight x.0506 first to x.05 and then "by odd/even rule" to x.00 would be wrong (x.0506 should go up).

  Finally, what I said just above is correct. DePiep (talk) 10:42, 25 September 2022 (UTC)

  Rounding must always be the last operation in a series of calculations: all intermediate steps must use as their input data the exact value yielded by the previous step. If hardware limitations might cause truncation or other loss of precision (usually because of a division), rearrange the calculation so that such loss happens as late as possible. A simple example: 1/3 = 0.333 recurring; 1/3 + 1/3 + 1/3 is therefore 0.999 recurring. But of course it isn't, so we rearrange to deal with integers where possible: (1 + 1 + 1) / 3 = 3/3 = 1.0 exactly. --Redrose64 🌹 (talk) 11:49, 25 September 2022 (UTC)

Perhaps we should back up to the original question. Say we have 74 kg (163.1 lb). Since 1 kg ≈ 2.2 lb, then it could be argued that single digit kg input should be rounded to multiples of 2 in the output. Would editors prefer to round it to 160 lb (round to 10), 165 (round to 5), 164 (round to 2) or 163 (round to 1)? For me, I think rounding to 1 and 5 (with suitable powers of 10) is enough for a general audience.  Stepho  talk  03:43, 24 September 2022 (UTC)

If you knew that much about computer arithmetic, you would know that 1kg = 2.2046226218488 lb, and that the user should specify the appropriate sigfig= value.

OK, there is something that is commonly called round to even, and only some of the discussion discusses that, and that is what I was trying to say. That is described in Rounding#Rounding_to_the_nearest_integer.

There is a separate question, which seems to be what you are asking about. The problem is that sigfig is sometimes too coarse. After trying out round, I don't understand it much at all, at least not in combination with sigfig. Especially I don't understand round=25. The more obvious answer is to allow fractions for sigfig, like 4.6 or 2.3. It is, in fact, rare that you know the answer well enough to do this, but I might agree with it. Fractional digits are commonly used in digital voltmeters, where a 3.5 digit meter goes up to 1999. Gah4 (talk) 09:30, 24 September 2022 (UTC)

Well, like so many of these discussions this has gotten rapidly out of control.

• "3.5 digits" for 0 to 1999 is loose terminology used in instrument sales. For God's sake, surely you should know that 3.5 digits (decimal digits, that is) would go to 10^3.5 = 3999 (roughly speaking).
• I think what we should do at the point is ask the OP, Justlettersandnumbers, for a concrete example of the use case he has in mind, and proceed from there. Otherwise I don't even know what problem we're trying to solve.

EEng 13:33, 24 September 2022 (UTC)

Yes, 3.3 is closer to 1999 and 3.7 closer to 4999. As far as I can tell, round= is broken, at least when used with sigfig. Gah4 (talk) 18:04, 24 September 2022 (UTC)

Thanks for replies, everyone – I had thought this was simple, but obviously not. EEng, the actual use case I had in mind was the one I specified, kg to lb; another might be in to cm. The problem, if there is one, is well explained by Stepho-wrs. In more general terms, where the conversion is to a unit smaller than the given unit, precision is too great without rounding (1 lb is more precise than 1 kg, 1 cm more precise than 1 inch), but rounding the last digit to 5 is often not precise enough. I thought that rounding to the nearest even last digit would in some cases come closer to a correct level of precision, but seem to have created mostly confusion – sorry about that!

Here's an alternative proposal: create an |about parameter that could be used as a prefix in cases where we want to specify that a conversion is approximate – such as where numbers have been over-rounded. Or of course we could just handle those cases manually ... Thanks for your patience, Justlettersandnumbers (talk) 17:13, 24 September 2022 (UTC)

All measurements are approximate, except whole number counts. It's one of my bugbears when people put "approximately" in front of all values: "approximately 08:30", "approximately 4 km", "approximately 60 men". "Some" and "about" may also be misused this way. There is an implied precision in values like "08:31", "4.09 km" and "61 men", and the main problem a convert template faces is falsely implying precision in the conversion "1 inch (2.54 cm)". The existing functionality of this template copes admirably with all these cases if used properly. John (talk) 11:53, 25 September 2022 (UTC)

round=

Does round= only work for integer values? Sometimes one might want to round the digits of a decimal fraction, with the also selected sigfig value. Actually, I don't know that anyone would want to do that, but it seems as useful as anything else I can think of rounding. Gah4 (talk) 06:10, 25 September 2022 (UTC)

Valid values for round are 0.5, 5, 10, 25 or 50. If the default rounding is not wanted, convert can be given a precision (a number), sigfig=n or round=n. What happens if more than one is specified (example {{convert|12.3|lb|g|2|sigfig=4|round=5}}) is not documented but convert currently uses the precision (2) if given, otherwise sigfig (4) if given, otherwise round (5). Johnuniq (talk) 06:43, 25 September 2022 (UTC)

Surely you're not saying that 0.5, 5, 10, 25 or 50 are the only valid values for round. EEng 14:47, 25 September 2022 (UTC)

That's what I'm saying—those are the only valid values of n in round=n. Using something like {{convert|12.3|lb|g|round=20}} gives "Ignored invalid option". Johnuniq (talk) 23:39, 25 September 2022 (UTC)

e6m3 or cubic hectometre

Some articles on dams and reservoirs were causing errors because the volume of the reservoir was measured in cubic hectometres, which this template did not understand. The data was drawn from Wikidata. User:MB advised that I could convert them to "e6m3" but Wikidata does not understand e6m3 (nor me). So what is the best option here? Thanks — Martin (MSGJ · talk) 06:57, 4 October 2022 (UTC)

Okay I'm silly. MB was advising that instead of using 4,918,000 cubic hectometres I could use 4,918,000,000,000 cubic metres. That is a very large number. — Martin (MSGJ · talk) 07:05, 4 October 2022 (UTC)

{{convert|4,918,000|hm3}} works fine: 4,918,000 cubic hectometres (1.737×10¹⁴ cu ft) So this is an issue with the module which passes the unit on to this template. I'll look further — Martin (MSGJ · talk) 07:09, 4 October 2022 (UTC)

The e6 prefix is often used as in the following.

• {{convert|12345|e6m3|e9m3|abbr=unit}} → 12,345 million m³ (12.345 billion m³)

I see the change at {{Infobox dam}} but I don't have an example of what article had a problem. Assuming convert displayed an error message in the affected article, holding the mouse over the message should show a pop-up with a longer message which would probably identify what convert is receiving and why it doesn't like it. If you have an article title, I'll work out what WikiData would have put in convert, although not necessarily quickly. Johnuniq (talk) 08:15, 4 October 2022 (UTC)

Here is an example. (Of course reservoirs should not really be using {{Infobox dam}} but there is a huge conflation problem, which is a separate issue.) — Martin (MSGJ · talk) 08:24, 4 October 2022 (UTC)

Convert/Archive 3

Module:WikidataIB passes the value unit symbol (P5061) to {{convert}} which for cubic hectometre (Q5195628) is hm³ rather than hm3 — Martin (MSGJ · talk) 08:35, 4 October 2022 (UTC)

I made an alias so hm³ is equivalent to hm3. Johnuniq (talk) 09:12, 4 October 2022 (UTC)

Thank you. Should we make aliases for all these units, or would it be better if the module removed the superscripts before passing to this template? — Martin (MSGJ · talk) 09:24, 4 October 2022 (UTC)

I try to avoid expanding convert's units because there are tons of them already and it's likely that many are never used, or should never be used. FYI there was a need to have convert work with some templates that produced strange numbers and Module:Convert/helper is used to massage those numbers into a format compatible with convert. It would be easy to add a function to change superscript numbers to normal numbers if that would help. Johnuniq (talk) 09:58, 4 October 2022 (UTC)

Sup/sub-script characters are the Wikidata standard though. DePiep (talk) 10:08, 4 October 2022 (UTC)

Conversion between binary and decimal bytes

Is byte a supported unit? Is there a parameter to convert between binary and decimal units, e.g., MB<->MiB? Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:34, 6 October 2022 (UTC)

KB, MB etc are sometimes used in a decimal sense and sometimes in a binary sense eg 1 KB = 1024 B, requiring an understanding of context if a precise conversion to bytes is desired. The benefits and disadvantages of providing such conversions have been strongly argued eg at Wikipedia talk:Manual of Style/Dates and numbers/Archive 161#WP:COMPUNITS. The MOS's WP:COMPUNITS itself shows some acceptable disambiguations but specifies that the IEC prefixes (kibi- etc) are only to be used in particular circumstances. NebY (talk) 13:07, 6 October 2022 (UTC)

I was just editing the talk page for significant figures. Often enough, such values don't have many significant figures, less than the difference between the decimal and binary values. I first remember wondering about this in the 8080 days, when it was claimed to address 65K bytes of memory. For cases where the value isn't a binary count, such as bytes on a tape, the uncertainty is often large enough, besides the tradition for using the larger decimal value. There are way too many values (mostly not bytes) in WP given to too many digits. In the case that a value is actually needed to byte resolution, best to just state it in bytes. Gah4 (talk) 19:14, 6 October 2022 (UTC)

At any rate, convert does not support MB/MiB conversions and it's hard to think of where such a conversion would be useful. Johnuniq (talk) 00:15, 7 October 2022 (UTC)

In the 1960s it was common to give storage sizes in decimal for, e.g., CDC 3600, CDC 6600, GE 635, Honeywell 800, IBM 7090, UNIVAC 1107 --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:27, 7 October 2022 (UTC)

You never know what marketing departments will do. There is also the IBM 1401 which came with up to 16,000 characters, using mixed radix addressing. When you get to 32K, it rounds to 33,000. 64K is more than 65,000, and I do remember the 8080 claiming either 65K or 65000 bytes. The difference between kB and kiB is 2%, and pretty much everyone knew which was which. For non-byte address storage, disk and tapes, there is the uncertainty of gap sizes, so within 2% or 4% is usually close enough. There might be some cases where someone was sued for claiming too much, but that isn't a problem here. Also, we aren't required to do the same rounding as the WP:RS does. Gah4 (talk) 19:19, 7 October 2022 (UTC)

There were a number of machines with mixed radix addressing, e.g., IBM 7080, RCA 301, RCA 3301. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:21, 8 October 2022 (UTC)

In the 1960s the concept of a "byte" as a group of 8 bits was by no means universal. The next unit larger than the bit was the word; and different computers had different word lengths, the exact number of bits per word would often be a compromise between cost and capability. --Redrose64 🌹 (talk) 08:37, 8 October 2022 (UTC)

Not like today, of course. EEng 14:31, 8 October 2022 (UTC)

Separator between unit and value

I suggest the use a narrow non-breaking space in the output of {{convert}}, based on Space_(punctuation)#Unit_symbols_and_numbers, thus:

1 pound (0.45 kg)

(with narrow non-breaking space, space, narrow non-breaking space)

instead of:

1 pound (0.45 kg)

(with space, space, non-breaking space)

which is what is currently generated by the convert template; see below:

1 pound (0.45 kg)

which I think is less elegant (and the NBSP renders significantly wider than a standard space on Firefox on Debian, which is ugly).

It's a small difference, but I think the thin-space version looks tigher on the page and is significantly more typographically elegant, with the narrower space subliminally visually binding the two parts more closely than a normal space, and renders more consistently across platforms.

— The Anome (talk) 15:16, 20 October 2022 (UTC)

The place to start discussing that would be at MOS, perhaps the talk of MOS:UNIT. Johnuniq (talk) 02:50, 21 October 2022 (UTC)

Adding radiation conversion from Gray to Rad

I was just looking at Elephant's Foot (Chernobyl) and a bunch of pages relating to the Chernobyl disaster and noticed that they use Gray (unit). Whilst the conversion to Rad (unit) is ridiculously easy (divide by 100) and the use of Rad is "strongly discouraged", it "is still used in the United States" and might be a useful addition for some pages especially as I suspect that most people don't know the relationship.

Equally happy for it not to happen. Gusfriend (talk) 06:38, 31 October 2022 (UTC)

Units Gy and rad exist, see Module:Convert/documentation/conversion data#Absorbed radiation dose. Johnuniq (talk) 08:15, 31 October 2022 (UTC)

kJ/mol to eV

I thought I added a a question about reaction energy such as kJ/mol, kcal/mol, eV such as {{convert|1|kJ/mol|eV}} or (as above reminds me) BTU/lb mol. Gah4 (talk) 01:56, 1 November 2022 (UTC)

OK, it seems that {{convert|1|kJ/mol|BTU/lbmol}} doesn't work either. Gah4 (talk) 02:08, 1 November 2022 (UTC)

Specific heat units

Hi, not sure I understand how to use this template correctly. Is there a way to convert "compund" units on the fly, for example specific heat: [J/(g*delta°C] or do these units need to be baked in. If they need to be baked in, can we please add in the units for specific heat as mentioned above? would be useful for material info boxes. Leav (talk) 04:18, 25 October 2022 (UTC)

There are some vaguely related units at Module:Convert/documentation/conversion data#Energy per unit mass. However, these are not what you are looking for. Convert can handle a "per" unit of the form x/y where x and y are units known to convert. However, there is no way to handle anything more tricky such as your unit. Adding a unit is not so easy—we would need to know the correct names (singular and plural) and the correct symbol. What would the unit be converted to? What are the rules for the conversion? Please provide links to a couple of articles where a new unit would help. Also, provide an example of the input (convert wikitext) and the wanted output. Are you sure conversions would be helpful? No one has asked for this before. Johnuniq (talk) 09:28, 25 October 2022 (UTC)

Hi Johnuniq, it is a useful component as part of {{Infobox material}}, and I'd like it too. Many articles for alloys and similar industrial materials have specific heat values in their data sheets. If you look at Inconel 625, Leav has already done a nice tidy up of the specific heat section. That should give you an example of the convert wikitext. As for some articles, do you mean Wikipedia articles? There are several that could benefit highly, like those aforementioned alloy articles. Articles such as Nimonic, AL-6XN, René 41, Nitinol 60, you get the gist of it. You can see it here: Special:Diff/1118089086. Cheers John. I didn't ask for this before as I was under the impression that the existing formula was correct, clearly I was mistaken. X750. Spin a yarn? _{Articles I've screwed over?} 20:52, 25 October 2022 (UTC)

It seems {{infobox material}} is used in only 35 articles.[5] Several of those I checked don't have that parameter filled (eg Buckram!), and all the ones I found that do have quantitative entries stick to metric units, except for Inconel 625 That article's infobox seems quite unusual in showing so many values and in displaying so many in two systems of units, so much so that the infobox (for me at any rate) no longer shows key features at a glance. Is there really a demand for specific heat capacities to be shown in multiple systems of units in many articles? NebY (talk) 21:15, 25 October 2022 (UTC)

{{Infobox material}} has met little content development. Recently, we merged {{Infobox alloy}} (FWIW, see TPU for parameters used).

That said, looks like specific heat is more common than just 35 transclusions. Specific heat capacity has example "2093 J⋅kg⁻¹⋅K⁻¹" (which is SI btw, as is OP: [J/(g*delta°C)]). And: {{Chembox}} has |HeatCapacity= in section template {{Chembox Thermochemistry}} ([6], TPU, check |HeatCapacity=). ~400 usage in mainspace.

I have not researched the units used in those 400+35 nor how/if any conversion, intra-SI or SI-imperial, is done/useful. HTH DePiep (talk) 21:44, 25 October 2022 (UTC)

I can add: the 100 or so elements have molar heat capacity like copper's "24.440 J/(mol·K)". (see Category:Infobox element templates by element (124); Heat capacities of the chemical elements). Here, too, I must leave the convert-need-analysis for now. HTH -DePiep (talk) 21:53, 25 October 2022 (UTC)

{{Infobox material}} can be used on several articles, I'll give it a whirl on several articles once I get home. It is only used on a minor amount of articles because Wikipedia lacks the depth of coverage on these articles. Nimonic, for example, is actually the trademark name. Nimonic alloys have a number identifier, such as Nimonic 75 which is a European Union creep reference material. I used both metric and imperial units for Inconel 625 because Inconel is manufactured by an American company and the data sheet actually gave both units. I can trim it down, if need be, for readability. X750. Spin a yarn? _{Articles I've screwed over?} 22:36, 25 October 2022 (UTC)

That's great, e.g. for the alloys. I'm following {{Infobox material}} (talk), we will find thoughts of improvements there.

This {{Convert}} talk recap: This {{Convert}} post could investigate whether heat capacity needs conversion option in the wiki ([J/(g*delta°C)], [J⋅kg⁻¹⋅K⁻¹], [BTU/lb⋅°R]). Note that it is temperature-dependent (image:water heating, wl), similar to Mach number & altitude. "specific" relates to "per unit of mass", an optional variant in RL. There are ~550 in TPU Chembox, ~40 in TPU IB material, ~100 in chemical elements; the need for wiki-wise conversion option is unclear. DePiep (talk) 06:05, 1 November 2022 (UTC)

BTU/lb

Is the BTU/lb conversion inverted or am I suffering from sleep deprivation? Or both? British Standard BS350:Part 1:1974 Conversion factors and tables uses the BTU corresponding to the International Table calorie, saying it is "defined by the equation 1 BTU/lb = 2.326 J/g". If you search for "1 btu/lb in J/g", Bing and Google agree it's 2.326 J/g. But {{convert|1|BTU/lb|J/g|15}} gives 1 British thermal unit per pound (2.3260000000000 J/g), the reciprocal of 2.326. What am I missing? NebY (talk) 23:04, 25 October 2022 (UTC)

I may have found the root cause... if you use lowercase btu it gives 1 BTU/lb (2.3260000000000 J/g)... but if you use uppercase BTU, it gives you 1 BTU/lb (2.3260000000000 J/g). Wow. X750. Spin a yarn? _{Articles I've screwed over?} 23:09, 25 October 2022 (UTC)

Oh good, it's not just me. I see Module:Convert/data has an explicit conversion factor for BTU/lb of 429.92261414790346. Perhaps Convert finds that if we use upper-case but calculates from btu and lb if we use lower-case.

I stumbled on this while wondering how Convert would handle BTU/lb/R. Sadly, {{convert|1|BTU/lb/R|4}} gives 1 British thermal unit per pound per degree Rankine (4.1868 kJ/kg/K). But with your lower-case approach, {{convert|1|btu/lb/R|4|abbr=on}} gives 1 BTU/lb/°R (4.1868 kJ/kg/K); which is even arguably better than using degrees F and C. Can you work with that? NebY (talk) 23:45, 25 October 2022 (UTC)

I'll wait for a reply from Leav, to see what they say. For the meantime though, that looks good. I would like a unit more familiar to readers though, Rakine is not new to me but may be confusing for the average reader. Cheers for this though, I had no idea it existed either. X750. Spin a yarn? _{Articles I've screwed over?} 00:19, 26 October 2022 (UTC)

I reckon the average reader that's interested in specific heat capacity and finds values for it meaningful isn't quite Wikipedia's general average reader! There's a good chance they'd grasp that the value's the same whether expressed in Rankine of Fahrenheit, especially given that it's a change of a degree that's meant, rather than the actual temperature. Still, Convert does support F-change, C-change and even (undocumented at Template:Convert/list of units) K-change, so we can have

{{convert|1|btu/lb/F-change|4|abbr=on}} giving 1 BTU/lb/°F (4.1868 kJ/kg/°C) and

{{convert|1|btu/lb/F-change|J/kg/K-change|1|abbr=on}} for conversion to SI, 1 BTU/lb/°F (4,186.8 J/kg/K). NebY (talk) 14:41, 27 October 2022 (UTC)

Why is BTU/lb [J/g] a subsection of [J/(g*delta°C)]? AFAIK, since dimensions differ there is no connection. -DePiep (talk) 18:00, 27 October 2022 (UTC)

Where is BTU/lb [J/g] said to be a subsection of [J/(g*delta°C)]? NebY (talk) 18:56, 27 October 2022 (UTC)

In Table of CoOntent: it has level-3 (===). Level-2 (==) would make it independent. I think such a change would be ok. DePiep (talk) 19:04, 27 October 2022 (UTC)

Oh, I see - you mean on this talk page, why is Btu/lb a subsection of Specific heat units. If you look at Inconel 625, you'll see OP had had to convert 0.096-0.160 BTU/(lb⋅°F) manually. Part of the problem is that convert's BTU/lb factor is wrong NebY (talk) 00:58, 28 October 2022 (UTC)

I'll be in off-wiki turmoil for a while and haven't investigated the details yet. However, as pointed out above, there is a bug (these currently give 0.42992261414790 J/g for the first and 2.3260000000000 J/g for the second):

• {{cvt|1|BTU/lb|J/g|15}} → 1 BTU/lb (2.3260000000000 J/g)
• {{cvt|1|btu/lb|J/g|15}} → 1 BTU/lb (2.3260000000000 J/g)

Also, as pointed out above, the different results are due to the fact that the second conversion is an "automatic per" where convert converts btu (which is an alias for BTU) and lb and combines them, apparently correctly. However, in the first conversion, BTU/lb is defined to have a scale of (0.947817120/2.20462262)*1000 = 429.92261414790346. The expression is from Module:Convert/documentation/conversion data#Energy per unit mass and the resulting value is as shown in Module:Convert/data. Would someone please work out what the numbers in the expression were supposed to mean and what they are missing. If confident, you can edit the conversion data and I'll update the module in due course (there are a couple of other units to be tweaked at the same time). Johnuniq (talk) 02:50, 28 October 2022 (UTC)

Thanks! I've changed Module:Convert/documentation/conversion data#Energy per unit mass to 2.326*1000.

2.326 is the value given by BS350: "The most important British thermal unit (Btu), and the one used throughout this standard, is the one corresponding to thc International Table calorie and is defined by the equation: t Btu/lb = 2.326 J/g"

and in BS350's Specific energy section, "1 BTU/lb = 2326 J/kg".

That (0.947817120/2.20462262)*1000 was using reciprocals of the correct values for the first two terms. (1055.055853/0.45359237) would give the right result but it's unnecessarily indirect; the 1055.055853 value's derived from 2.326. NebY (talk) 14:39, 28 October 2022 (UTC)

Sounds good, thank you Johnuniq & NebY. X750. Spin a yarn? _{Articles I've screwed over?} 01:24, 30 October 2022 (UTC)

References

Dessiatines

Would anyone be opposed to adding an obsolete (widely used in the Russian Empire) unit called the Dessiatin to the convert template? It's equivalent to 10,926.512 square meters and was used in an agricultural context (i.e. arable lands of a village). For example it's used on the Hayanist village article whereby the village's agricultural statistics in the early 20th century are presented in a table in Dessiatines (which had to be manually converted to square kilometres by the editor who added them). – Olympian ^loquere 11:48, 11 November 2022 (UTC)

We could temporarily add a unit as an experiment and see how it is used. However, I'm a bit negative about units like this because they seldom have a clear definition that apply at all times and all places. If a conversion factor is put into a template, the results it produces are unlikely to be questioned. However, the original source might have been referring to a unit with a different definition and {{convert}} would be giving a false impression by blessing one particular conversion factor. I have found sizes.com to be very good at summarizing what is known about units. At https://www.sizes.com/units/desiatina.htm they show 2,500 square sazheni but also 2,400 and some other strange numbers that I don't follow, including 3,200 and 3,600. Our Dessiatin shows, without references, 2,400 and 3,200. Any other opinions on adding this unit? Johnuniq (talk) 01:34, 12 November 2022 (UTC)

It seems there are only 44 articles which link to Dessiatin[7], several of them via redirects: Desyatina, Dessiatina, Desyatinas, Dessiatine. If that's any indication, those comparatively few manual conversions might be less work yet more reliable than creating and maintaining it clearly in Convert. I do wonder too how exact any of the variants of Dessiatin were. Unless Convert's used with sensitivity, a precise conversion can give the impression the original unit and measurement were precise, but our description of Dessiatin is "archaic, rudimentary". NebY (talk) 21:13, 13 November 2022 (UTC)

List of adjectival units

I came across this sentence "There are three passing lanes, at the {{convert|2200|foot|meter|adj=mid}} level, the {{convert|4000|foot|meter|adj=mid}} level, and the {{convert|5600|foot|meter|adj=mid}} level." and I wanted to edit it so the three conversions would be together There are three passing lanes at the {{convert|2200|,|4000|, and|5600|foot|meter|adj=mid}} levels. Unfortunately, it does not output as I'd expect.

Template: 2,200,-4,000,-and-5,600-foot (670, 1,220, and 1,710 m)

Expected: 2,200-, 4,000-, and 5,600-foot (670, 1,220, and 1,710 m)

Is there another way? Am I missing something? –Fredddie™ 02:47, 17 November 2022 (UTC)

Here is one way:

2,200-, 4,000-, and 5,600-foot ({{convert|2200|,|4000|, and|5600|foot|meter|disp=out}}) that will accomplish this. MB 04:31, 17 November 2022 (UTC)

Thanks, I've been wondering what to say about this problem. The OP demonstrates that adj=on merely replaces spaces with hyphens and that can give dumb results. There are quite a lot of cases where the simple replacement works, but it does not work with ranges. Johnuniq (talk) 06:31, 17 November 2022 (UTC)

Help talk:Convert now redirects here

During the development of Module:Convert many subpages were created and some of them had useful discussions about the subpage. Help talk:Convert had minor use for discussion related to Help:Convert but having the various talk pages leads to confusion about where people should ask questions. Therefore I have redirected the help talk to here. That should be done for more similar pages. I think there was a recent comment added to the talk of one of the pages documenting units and such pages should be redirects. Johnuniq (talk) 00:14, 25 November 2022 (UTC)

Multiple units in a X by Y conversion

Moved from Help talk:Convert#Multiple units in a X by Y conversion

 – Johnuniq (talk) 00:05, 25 November 2022 (UTC)

I'm trying to convert the units in this expression: consists of a chancel 29 ft. 6 in. by 13 ft., south chapel 29 ft. 6 in. by 11 ft., nave 38 ft. by 18 ft. 6 in., north aisle 7 ft. wide, south aisle 8 ft. wide, west tower 11 ft. square and a south porch. and have fallen at the first fence. Would someone tell me what's wrong with {{cvt|29|ft|6|in|x|13|ft|m}} (gives 29 ft 6 in ()) I can't believe that I'm the first to have encountered this but I can't see it the help article. Apologies in advance if I just haven't tried hard enough. 𝕁𝕄𝔽 (talk) 17:53, 24 November 2022 (UTC)

@𝕁𝕄𝔽: I've moved the question to here because this is the place to discuss all convert issues. Sorry but ranges of multiple units (such as feet and inches) are not supported. See Template:Convert#About feet, inch in ranges and multiples. For posterity I'll mention that this issue was mentioned at Template talk:Convert/Archive August 2014#Converting multiple input values in feet and inches to metres and Template talk:Convert/Archive September 2016#Can this be made to work?. Johnuniq (talk) 00:05, 25 November 2022 (UTC)

OK, I thought template talk:convert was the page for feature requests, "bugs" and the like, with help:convert being for "first aid" requests that one of your page watchers might answer. Thank you for taking the time to respond.

The possibility that it might be considered a range didn't occur to me. I did to a search for "area" but found nothing relevant.

I could use {{cvt|29.5|x|13|ft|m}} [which works: 29.5 ft × 13 ft (9.0 m × 4.0 m)] but I would cause an epidemic of apoplexy among the imperialists. I'll do the conversions off-line and append it as a footnote or similar. Thank you again. --𝕁𝕄𝔽 (talk) 00:44, 25 November 2022 (UTC)

Pood, a medieval–19thC. Russian unit of mass

Started a discussion on the Template talk:Convert/list of units/mass page last week, but have now figured out that is the wrong place to discuss the topic of a potentially missing convert unit. So, adding the question here.

What would be involved in adding the Pood, a medieval-to-19th C. Russian unit of mass, to the {convert} template? Found this unit used in the prose of the article Port of Novorossiysk, without any conversion into more recognizable mass units for our global readership. Cheers. N2e (talk) 13:09, 22 November 2022 (UTC)

The first question is whether it had a consistent weight throughout. Other questions and issues raised above at #Dessiatines might also be relevant. NebY (talk) 17:35, 22 November 2022 (UTC)

As the proposer of adding the Dessiatines unit, I agree. I think there should exist a reliable source that covers these old Imperial Russian units and provides consistent and precise conversion formulas/ratios – if anyone knows of such a source, please share it. – Olympian ^loquere 02:55, 23 November 2022 (UTC)

I get that these ancient and medieval units often had imprecise values. I just figured that the amazing Wikipedia {convert} templates, after all the evolution of them over the years from the super work put in by a lot of technically-minded editors, had developed a some sort of consensus on a semi-standard way of dealing with those rough values. E.g., I figured the convert template might just do the conversion to a rough- or weighted- average of what historical sources have shown what the unit was.

In other words, if an article quoted the accurate source in some obscure unit like "poods" (or whatever ancient/medieval unit we are talking about) and the {convert} template turned it into an approximation (or range) in more modern and recognizable units, that'd be good enough. In any case, it would massively help editors who certainly are gonna do something even worse, with random usage of various conversions in different articles, and would be much better for readers than leaving it with only the esoteric obscure unit stated. YMMV. —N2e (talk) 04:26, 26 November 2022 (UTC)

"A rough- or weighted- average" indicates one of the cans of worms (others include the rewriting of Convert to enforce use of "about" and low precision). Do we weight for region, period, frequency of use in surviving texts or what? For example, ancient Greek/Hellenic texts often measured in stadia (singular stadion, often translated as stades, singular stade). of which our article rightly says "the length of the stadion has been the subject of argument and hypothesis for hundreds of years". It would be fun to know if Eratosthenes was right to 10%, 5% or better than 1%, but we never will know and it's not what matters about his achievement. Modern writers and translators often stick to stadia/stades, perhaps with a glossary entry or initial footnote, because converting is so contentious and potentially misleading. If someone were to go through our articles changing stadia to {{Convert|x|stadia}}, editors would be reverting and objecting that it required knowledge of context and gave a false impression not only to readers but also to future editors of that article. Yet this is one of the most familiar and well-studied ancient units! I understand what you're saying about "various conversions in different articles" but that's editors trying to do their best for the subject, place, time and text and (broadly speaking) not over-egg it. NebY (talk) 17:20, 26 November 2022 (UTC)

• Pood sounds like something Woody Allen might have made up for Love and Death. EEng 21:01, 26 November 2022 (UTC)

"Adj=on" problems

I don't know what I'm doing wrong, but I know this used to work and in recent months can't seem to get the hyphen to appear. Why is wrong there no hyphen in "a 600 m (2,000 ft) long road", for instance? Laterthanyouthink (talk) 09:51, 26 November 2022 (UTC)

Don't use {{cvt}}, use {{convert}}. -- WOSlinker (talk) 13:33, 26 November 2022 (UTC)

Oh, okay, thanks WOSlinker. I had assumed that the abbreviated form would act in the same way as the full form, but I'll remember this tip in future. Laterthanyouthink (talk) 20:55, 26 November 2022 (UTC)

Cvt automatically adds the abbr=on option. -- WOSlinker (talk) 22:35, 26 November 2022 (UTC)

ktTNT

Shouldn't "{{convert|1200|ktTNT|lk=in|sp=us}}" (with sp=us) produce "kilotons" instead of "1,200 kilotonnes of TNT (5,000 TJ)"? GA-RT-22 (talk) 17:26, 22 November 2022 (UTC)

Examining Module:Convert/documentation/conversion data#Energy shows many creative units including the following three: ktTNT, kt(TNT), ktonTNT. For some historical reason, kt(TNT) gives "kiloton" if sp=us is used, but the others don't. I don't see why a US (short) kiloton would ever be correct because TNT equivalent tells us that the convention is the energy equivalent to a kilo metric tons, and that is the conversion factor used for each of these units. Using sp=us might change the name displayed, but it does not affect the conversion factor. Johnuniq (talk) 02:34, 23 November 2022 (UTC)

No, they are the same. US spelling only. It has nothing to do with long or short tons. No conversion factor. And it allows for US spelling because I asked for it. Americans spell it "tons". Check the logs. Hawkeye7 (discuss) 03:44, 23 November 2022 (UTC)

Thanks for the clarification. What I had in mind was that (I think) there are no mass units that allow you to change the spelling between tonne and plain "ton". Instead, it's "short ton" or "long ton" or "metric ton". I'm not objecting to the following particularly since the difference between the different tons is immaterial, but it's unusual for convert to switch the spelling to something that could be misleading although I suppose WP:ENGVAR could be invoked.

• {{convert|1200|kt(TNT)|lk=in}} → 1,200 kilotonnes (5,000 TJ)
• {{convert|1200|kt(TNT)|lk=in|sp=us}} → 1,200 kilotons (5,000 TJ)

Johnuniq (talk) 06:17, 23 November 2022 (UTC)

So is this an engvar issue or are these different units? I had assumed it was engvar, but then wouldn't an article on a US weapon, like B83 nuclear bomb, use "kilotons"? GA-RT-22 (talk) 01:04, 24 November 2022 (UTC)

Yes, it is a WP:ENGVAR issue, but there is no issue with the usage. There is only one unit, with two spellings. Do not confuse it with mass units; kilotonnes of TNT is a unit of energy, not mass. Hawkeye7 (discuss) 02:02, 30 November 2022 (UTC)

As I noted in the tonnes discussion below, when there is only one sigfig then there isn't enough difference. As well as I know, bomb measurement to 1 digit is pretty good. Gah4 (talk) 03:19, 30 November 2022 (UTC)

From TNT equivalent the actual yield from large amounts of actual TNT can vary over about a factor of 3. (Depending on how much atmospheric oxygen gets into the reaction.) So, it was defined as a power of 10 multiple of the calorie. The uncertainty is enough to include short, metric, or long, ton. That is in addition to the uncertainty in measuring what it is being compared to. Gah4 (talk) 03:35, 30 November 2022 (UTC)

Advice requested for converting tonnes

If I see a measurement in tonnes, is it recommended that long tons always be included alongside short tons? In other words, is it considered "poor form" to go directly from tonnes to short tons? Thanks! 1980fast (talk) 07:23, 28 November 2022 (UTC)

The general principle is covered at MOS:CONVERSIONS. Many of our readers understand only one of short ton, long ton or metric ton - therefore we need all 3. Think of it this way - if you were an average run-of-the-mill Brit (long ton), American (short ton) or Swede (metric ton), how would you feel if an article showed every weight in 2 units but not yours? You might also want to enable linking for the first conversion in the article to help those not familiar with the differences of each "ton".  Stepho  talk  07:51, 28 November 2022 (UTC)

While I agree, a complication is that often a measurement in tons of any variety does not have many significant digits and conversion to other varieties shows the same number which looks strange. I don't know what to do about that. Johnuniq (talk) 08:27, 28 November 2022 (UTC)

The edit that prompted my question can be found at Southern Ocean#Economy. I noticed the relative proximity between tonnes and long tons, and thought I would ask here. Fortunately, this particular conversion has enough significant digits to show the difference between tonnes and long tons. 1980fast (talk) 23:05, 29 November 2022 (UTC)

Do they really measure to six sigfigs? Is that before or after draining the water out? Krill says 150,000-200,000 tonnes, so a more reasonable 1 significant figure. I suspect Southern Ocean#Economy has too many. Gah4 (talk) 00:03, 30 November 2022 (UTC)

Yes, it seems a case of undue precision. What's more, there's no source given for any of it. 1980fast (talk) 07:20, 30 November 2022 (UTC)

Wondering about this, I Google for "119,898 tonnes" and all the hits seem to be this sentence, though without the conversion. More interesting, though, Google for "119,898 tons" find some others, such as this one on the production of coke. (That is, not Coca-Cola.) It seems unlikely that the same exact number comes up in both places by coincidence. Gah4 (talk) 00:26, 30 November 2022 (UTC)

The conversion does highlight that 119,898 tonnes might be a poor conversion from 118,000 (long) tons. Those 1999 fisheries figures were added, unsourced, in 2001. Krill fishery#Antarctic krill shows 158 MT in 2008 and 125 MT in 2009, suggesting total fishery tonnage may be much higher than ~120 MT but so variable that precision is futile. NebY (talk) 13:21, 30 November 2022 (UTC)

The difference between long tons and metric tonnes is slightly over 1.6%, not great enough for the casual reader to worry about. The two are equivalent for most practical purposes: a crane having a safe working load of 75 (long) tons will also be safe at 75 (and indeed 76.204) metric tonnes. I think that including all three is overdoing it, and that the selection should be short tons plus either one of the other two. --Redrose64 🌹 (talk) 10:31, 28 November 2022 (UTC)

In a large fraction of uses for these units, the uncertainty is more than 10% or 20%. Those cases should have sigfig=1, and the results will often be, as noted, the same for two or three of the different tons. Some might have an uncertainty much higher than 20%. I remember driving by a gym with a sign tons of equipment, and realizing that it probably was not exaggerating. But also likely closer to sigfig=0. Can we make the conversions sigfig dependent? Gah4 (talk) 16:40, 28 November 2022 (UTC)

True, true - I hadn't considered that if the accuracy of the amount is less than the accuracy of the conversion then the conversion is useless.  Stepho  talk  00:20, 30 November 2022 (UTC)

The purpose of the conversion template is to convert old measurements found in the sources to metric, thereby preserving verifiability. In the old imperial measurements, certain units were used for certain purposes. Thus short tons for shipping on US roads and railways, but long tons when loaded on a ship. Which one was meant was context sensitive. Which is why it was recommended that in metric we use "tonnes" but this seems to be on the decline as the old measurements are increasingly forgotten and it is understood that "tonnes" is meant. There is seldom a need for all three. If the reader wants to understand how the measurements work, they can consult the article. Beware! Short and long are not the only "tons"; often the source will mean measurement tons. Make sure you have the right sort of tons before you convert. Hawkeye7 (discuss) 01:52, 30 November 2022 (UTC)

Finding HELP about Scientific notation with the Convert template

Per this discussion on the WP Help Desk— Scientific notation with the {Convert} template—I really feel that this page (Help:Convert) should definitely have a link to this helpful page—Template:Convert#Scientific notation: 1.23 × 10−14—on the use of scientific notation with the Convert template.

As the page exists today, I was simply unable to find if it was possible, and if so, where one would go to learn about it. Cheers. N2e (talk) 15:55, 8 December 2022 (UTC)

Convert is a problem because it has a lot of options many of which take significant effort to understand. I added "See the documentation at Template:Convert for further details." at the top of Help:Convert and don't think we can do better. Johnuniq (talk) 09:53, 9 December 2022 (UTC)

Japanese unit kan

Is it possible to add the Japanese unit kan (there's already shaku)? I was editing Umibōzu and I "solved" the problem using 60–70 kan ({{convert|225|-|262.5|kg|lb|abbr=on|disp=comma}}). Not very elegant, though. Carnby (talk) 21:32, 11 December 2022 (UTC)

Pressure units: bars

In an article I recently visited, I noticed that the pressure was stated as "1,987 bars". This is not according to convention: the proper way to specify a pressure would be "1,987 bar": pressure units are not countable, so just as we don't say 1500 psigs, we shouldn't say 100 bars. When I went to edit the page to correct this, I found that this page text was produced by the code "convert|1086|bar|psi" - so I can't fix this, and it appears that this odd unit convention is probably present on many other pages that use the convert tag. I suggest that the code producing this be modified. Lushgardener (talk) 18:49, 10 December 2022 (UTC)

You can fix that instance by using {{convert|1086|bar|psi|abbr=on}} or {{cvt|1086|bar|psi}} to produce 1,086 bar (15,750 psi). That forces Convert to use the symbol "bar" instead of the plural of the word "bar", just as {{convert|2|ft|m}} produces 2 feet (0.61 m) but {{cvt|2|ft|m}} produces 2 ft (0.61 m).

It's arguable whether we'd say "bars". I think it's generally avoided but I'd like to see a style guide or other WP:RS. A quick Google ngram shows "millibars" to be more common than "millibar".[8] We don't say or write "psigs", true, but that's because it's an abbreviation; we do say pounds per square inch, and also millimetres Hg, feet head and so on. Bar and millibar are is a little unusual in having a symbol that's the same as the word. NebY (talk) 20:04, 10 December 2022 (UTC)

@Lushgardener, is that entirely correct? We might not write psigs, just like we don't write gs for grams, but when we spell it out, we certainly do write pounds per square inch gauge, in the plural. Bar (unit) uses the plural ("bars"), and bar does not seem to be an abbreviation. WhatamIdoing (talk) 20:05, 10 December 2022 (UTC)

I am an engineer who routinely reads scientific literature. I have never seen "bars" used in this way (it reminds me of saying "I have three bars on my phone"), and I would argue that using "bar" is inherently scientific: it is not a unit that occurs in casual communication. NebY is correct that it is difficult to compare this to other units because bar is not abbreviated. Since there is an easy fix (using abbr/cvt), I guess it's not terribly important. But given the choice, I'd still advocate that any use of the convert template renders "bar", regardless of abbreviation status. Lushgardener (talk) 17:32, 11 December 2022 (UTC)

https://doi.org/10.1016/j.scitotenv.2022.159718 says the equipment was "operated under 3 bars (H3) and 6 bars (H6)". https://doi.org/10.1016/j.jwpe.2022.103195 names a "rate at 3 bars and 15 C". https://doi.org/10.1038/s41598-019-48693-1 says they collected data "at 1 bar, 100 bars, and 200 bars". So it happens, but overall I think it is the less common form, appearing in maybe 20% of recent papers, assuming the Ghits in Google Search are at all comparable. WhatamIdoing (talk) 17:43, 11 December 2022 (UTC)

Note that all three papers linked above are from non-English-speaking countries/authors. Lushgardener (talk) 22:15, 11 December 2022 (UTC)

Like, you know, the United States. NASANISTNOAA Hawkeye7 (discuss) 22:28, 11 December 2022 (UTC)

The bar is the unit. It is not an abbreviation, and doesn't have one. It is used in casual conversation about air pressure, and is referred in plural the same as other metric units eg 1014 millibars. Hawkeye7 (discuss) 22:18, 11 December 2022 (UTC)

Millibars, yes, but in my experience bar more often than bars, maybe out of some automatic aversion to ambiguity / tedious jokes. NebY (talk) 22:31, 11 December 2022 (UTC)

Document frequency conversion?

It would be good to note the usage like

{{convert|1|cm|GHz}}

to 1 centimetre (30 GHz) somewhere - I keep forgetting how to do this. :-) Thanks. Mike Peel (talk) 08:44, 8 January 2023 (UTC)

Request: option to abbreviate years as "yr" instead of "a"

I would like to have an option that would change the abbreviation of years into "yr" instead of "a". This only happens when you convert into years, like 365 days (1.00 a) and 1 a (370 days) for example. I particularly need this for astronomical object articles like Saturn, which conventionally use "yr" as an abbreviation. Nrco0e (talk) 03:33, 10 January 2023 (UTC)

I don't understand yet. If Saturn uses "yr", why change to "a"? And, for clarity, do you mean "abbreviation" to mean the same as "unit" (as {{Convert}} does)? DePiep (talk) 06:44, 10 January 2023 (UTC)

His example of Saturn already has "yr" for the orbital period in the infobox but that is by hand. I suspect he wants to use convert for that figure but convert currently outputs "a" when he really wants "yr".

Eg Currently {{cvt|29.4571|yr|d}} displays 29.4571 a (10,759.2 d) but he really wants 29.4571 yr (10,759.2 d) . Stepho  talk  06:59, 10 January 2023 (UTC)

Examining Module:Convert/documentation/conversion data#Time shows the unintuitive situation that the unit year gives a as the symbol, while the unit years gives the symbol yr. For example:

• {{cvt|29.4571|years|d}} → 29.4571 yr (10,759.2 d)

Johnuniq (talk) 07:10, 10 January 2023 (UTC)

(OK,. Confusion was by myself) DePiep (talk) 08:08, 10 January 2023 (UTC)

Acre (noun) v. acre (adjective)

Is there a way to use convert with acre that will produce an adjectival form? Example:

• (with convert) A 3 acres (1.2 ha) farm
• (wanted) A 3 acre (1.2 ha) farm

I was thinking maybe there's some flag I could use so it would keep the singular form of "acre"? Haven't been able to find one, so asking here. Schazjmd (talk) 01:09, 16 January 2023 (UTC)

A {{convert|3|acre|adj=on}} farm → A 3-acre (1.2 ha) farm  Dr Greg  talk  01:41, 16 January 2023 (UTC)

Brilliant! Thanks, @Dr Greg:! Schazjmd (talk) 15:11, 16 January 2023 (UTC)

Check arithmetic for MPGe conversion

When I convert from MPGe to kWh/100 mi, I expect the following computation, based on the stated values in gasoline gallon equivalent:

${\frac {kWh}{100mi}}=100*\left({\frac {MPGe}{33.41{\frac {kWh}{gal}}}}\right)^{-1}$

The EPA uses a slightly different value of 33.7 for kWh/gal to compute MPGe. Based on this, the expectation is that a car with 89 MPGe would get 37.5 (using 33.41 kWh/gal) or 37.9 (using 33.7 kWh/gal) kW⋅h/100 mi. Instead, {{convert}} gives 38 kW⋅h/100 mi, which implies that a gasoline gallon equivalent value of 33.8 kWh/gal is being used in the conversion instead. Can someone check the source and update it, if necessary? Thanks, Mliu92 (talk) 20:38, 13 January 2023 (UTC)

The reason I mention this is because the values for MPGe, when converted to kWh/100mi, are not consistent with Fuel Economy Guide, Model Year 2023 (PDF) (Report). United States Environmental Protection Agency. 2022. pp. 34–38. Retrieved 9 May 2024. For example, The Chevrolet Bolt EV is rated at 120 MPGe combined, which is stated to be 28 kW⋅h/100 mi, but the conversion gives 120 mpg‑e (28 kW⋅h/100 mi); the EPA is using 33.7 kWh/gal to give 28.1 kW⋅h/100 mi.

Also, if it helps, a reasonable workaround for mi/kWh (the unit preferred by Tesla and some EV sites, for example https://insideevs.com/news/597460/tesla-efficiency-depends-on-driver/) to MPGe can be implemented manually by using #expr:

[mi/kWh] ({{cvt|{{#expr:1/[mi/kWh] round 1}}|kWh/mi|mpge|disp=out}})

At some point it may be nice to implement mi/kWh and km/kWh into the convert template. Cheers, Mliu92 (talk) 22:55, 13 January 2023 (UTC)

@GliderMaven: You added mpge in May 2015. Please consider the above (which is a bit too complex for me at the moment) and say what should happen. Johnuniq (talk) 02:25, 14 January 2023 (UTC)

OK I think I've found the problem. The second conversion has:

scale = 13.00e-6

I don't recall at all, but it would make sense if I got that from Miles_per_gallon_gasoline_equivalent#Description where it says 1 MPGe ≈ 0.013km/MJ

In these conversion they're all referred back to J/m or m/J for inverse units such as MPGe.

That's 13 m/MJ = 13.00e-6 m/J which is the number in the scale above. I'd misread the '≈' as an equality symbol.

But let's calculate the exact number.

It's exactly 1 mile / (33.7 kWh) = 1609.344 m / (33.7 * 3.6e6 J) = 13.26528189910e-6 m/J .

So I think it should read (depending on the rounding level we use for convert):

scale = 13.26528e-6

GliderMaven (talk) 04:01, 14 January 2023 (UTC)

Thanks. I try to put the expression in the unit definitions so the value is calculated by the servers to their limit of precision and so we can later get a clue where the number came from. I'm not going to try to understand to above at the moment but will change the scale for mpge at Module:Convert/documentation/conversion data#Energy per unit length from 13e-6 to 1609.344/(33.7 * 3.6e6). Since I batch changes to convert that will take a while. I'll ping the OP when it is done. Johnuniq (talk) 07:47, 14 January 2023 (UTC)

A side-note from a different perspective: Does the EPA "define" the energy density $w$ of American gasoline as $33.7\,kW\cdot h\cdot gal^{-1}$? In case the EPA doesn't, the kW·h/gal to mi/gal_e conversion cannot be made with significant precision, because the energy content $H_{i}$ of automotive fuel varies. One of the lowest figures that I found for petrol was $40.1\,MJ\cdot kg^{-1}$, and one of the highest figures for petrol was $44\,MJ\cdot kg^{-1}$ Given that the density $\rho$ of automotive petrol according to the DIN EN 228 standard is in the $720\,-\,775\,kg\cdot m^{-3}$ range at a temperature of 15 °C, then the energy density $w$ of automotive petrol/gasoline/fuel can be in the range of $28.9\,-\,34.1\,MJ\cdot dm^{-3}$, which according to the convert template is 28.9–34.1 MJ/dm³ (30.4–35.9 kWh/US gal). I reckon that a conversion with $w=33.7\,kW\cdot h\cdot gal^{-1}$ yields results precise enough for the average consumer, but unless "exact" figures are known, an "exact" conversion cannot be made. Best regards, --Johannes (Talk) (Contribs) (Articles) 09:10, 14 January 2023 (UTC)

Hi and thanks for the quick actions on this request. The US government considers one gallon of gasoline to contain the equivalent of 33.705 kWh/gal, per 65 FR 36985 (June 2000). Subsequent rule making has reduced the precision to 33.7 kWh/gal, e.g. 75 FR 58078 (Sept 2010), but I suggest 33.705 should be used in the calculation. I agree the density and energy content of gasoline can vary widely due to formulations; I assume the 33.705 kWh/gal value used by the EPA, which has been remarkably consistent for more than twenty years, are intended to reflect typical tested values. Cheers, Mliu92 (talk) 15:54, 14 January 2023 (UTC)

That is an interesting piece of information! I'd say that the convert template should use the FR figure of 33.705 kW·h/gal then. The extra precision won't hurt, I guess. Best regards, --Johannes (Talk) (Contribs) (Articles) 17:34, 14 January 2023 (UTC)

References

Thanks for the follow-up above. As a test of how this will work, I have updated Module:Convert/extra with a new temporary unit (MPGE in uppercase) with a scale equivalent to 1609.344/(33.705*3.6e6). The following tests the current unit (mpge) and the new unit. The ||9 is telling convert to use the default output unit (due to the empty parameter 3) and a precision of 9 (way more than useful but this demonstrates the calculation).

• {{cvt|89|mpge||9}} → 89 mpg‑e (37.870723742 kW⋅h/100 mi)
• {{cvt|89|MPGE||9}} → 89 MPGE

Please check the above and perhaps some other conversions and confirm that this is what is wanted. It would be better to not use MPGE in articles yet—it will work but I plan to remove MPGE after updating the current mpge unit in due course. Johnuniq (talk) 04:24, 15 January 2023 (UTC)

Thanks for the update -- this matches the expected behavior. Going back to the Fuel Economy Guide, we come up with the following values for a few spot checks:

• BMW i4 eDrive40 rated at 109 MPGe (EPA says this is 34 kW⋅h/100 mi):
  • using MPGE
  • 30.9 kW⋅h/100 mi using mpge
  • Possibly an arithmetic error on the part of the EPA (new model)
• Porsche Taycan GTS rated at 83 MPGe (EPA says this is 41 kW⋅h/100 mi):
  • using MPGE
  • 40.6 kW⋅h/100 mi using mpge
  • Both units give pretty good agreement
• Tesla Model 3 RWD rated at 132 MPGe (EPA says 25 kW⋅h/100 mi):
  • using MPGE
  • 25.5 kW⋅h/100 mi using mpge
  • MPGE gives a better conversion here
• Kia Niro Electric rated at 113 MPGe (EPA says 29 kW⋅h/100 mi):
  • using MPGE
  • 29.8 kW⋅h/100 mi using mpge
  • MPGE gives a better conversion here

Cheers, Mliu92 (talk) 17:13, 16 January 2023 (UTC)

Am I reading this correctly?

There's no current ability to convert gross tonnage to cubic meters? — LlywelynII 16:49, 22 January 2023 (UTC)

According to our article, that's a non-linear conversion,

$V={\frac {50\times \ln 10\times GT}{W(5\times 10^{11}\times \ln 10\times GT)}}$

where $ln$ is the natural logarithm and $W$ is the Lambert W function.

That would seem to be well beyond Convert's algorithms. NebY (talk) 17:06, 22 January 2023 (UTC)

Potential error in certain mph to km/h conversion

Hi, I've spotted a bit of an oddity: {{cvt|90|mph}} is erroneously producing 140 km/h, but {{cvt|90|mph|0}} correctly produces 145 km/h. It doesn't seem to affect other input speeds; {{cvt|75|mph}} and {{cvt|75|mph|0}} both produce 121 km/h, and similarly 45, 60, and 100 mph all also produce the correct figure either way. Is there something I've overlooked? Thanks in advance. XAM2175 ^(T) 17:10, 26 January 2023 (UTC)

@XAM2175: from the FAQ at the top of the page:

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.

60 mph and 90 mph have one significant figure each, while 45 mph and 75 mph have two each. (Trailing zeros before a decimal place are not significant by default.) The template will add an extra sig fig in some default calculations, so the output with 60 mph and 90 mph each have two sig figs. The difference is that while 60 mph becomes 97 km/h with those two sig figs, when you round off 144.8 km/h to two sig figs, you get 140 km/h because the result has a digit in the hundreds place. You'd have to increase the output there to three sig figs to get 145 km/h, which is two more than the input of 90 mph.

When you add |0 to the template, you're overriding this default behavior and telling it to round the output to 0 decimal places regardless of the number of sig figs in the input. Imzadi 1979 → 19:41, 26 January 2023 (UTC)

Thank you for answering @Imzadi1979, but with respect, I don't view this as a "behaving as expected" situation – a casual user of the template will be expecting to see 90 mph converted to 145 km/h without needing any special configuration. I discovered this because I found a casual user manually replacing numerous applications of this template in an article with hard-coded conversions, presumably on the basis that the template was unreliable. XAM2175 ^(T) 20:26, 26 January 2023 (UTC)

I don't know about others, but we studied significant figures in my high school and college science courses, and it was drilled into us that you never give an answer more precise than your given input values. Strictly speaking, converting "90 mph" with 1 sig fig should give "100 km/h", also with 1 sig fig, but as a compromise, the template supplies an addition sig fig in certain cases based on the scaling factors involved, thus giving "140 km/h" as the result. The template won't add a second additional sig fig to give you "145 km/h" without the user taking an affirmative step to do so, like specifying the level of rounding or specifying the number of sig figs in the output, like adding |sigfig=2. This is all explained in the rounding explanation linked from the FAQ.

So for this template to do as it does is the expected behavior to me and many others. Imzadi 1979 → 20:56, 26 January 2023 (UTC)

I know way more cases where results have too many digits. I believe in this case, 140 is better than 100. 90+/-5 goes to 144.8+/-8, and so 140. 100 is closer to zero significant digits. Most often you should have one extra digit for intermediate results, to avoid over rounding. Gah4 (talk) 22:16, 26 January 2023 (UTC)

Convert has to handle a wide range of conversion of different units of values. So it has to handle things like converting 3000 miles to an equivalent km. More often than not, the 3000 mile input figure is hugely rounded, so it makes no sense to give an output as 3,000 mi (4,828 km). Instead, it estimates the rounding required from the number of zeroes at the end of the input figure to show 3,000 mi (4,800 km). The rounding of 90 mph works from the same generic principle. For a generic tool, there is no other course of action that won't cause more problems than it solves. So, convert has extra parameters so that you can specify how much rounding you want. You can specify significant digits, or how many digits before/after the decimal point or rounding by 5 or 50. The only 2 realistic choices that convert could have chosen for its default is to be ultra precise (knowing that the majority of users will convert 3000 miles to 4,828 km with far more precision than the input deserves) or to estimate the rounding from the trailing zeroes by default (as above, knowing that some values like 90 round a bit too much in some circumstances). Users will make mistakes no matter which default we choose.  Stepho  talk  22:41, 26 January 2023 (UTC)

I can see your point about having to handle a wide variety of inputs, but I'm still deeply troubled to find that the default behaviour across all applications is to actively produce a conversion less precise than the input because some of those applications might involve pre-rounded inputs. XAM2175 ^(T) 17:36, 27 January 2023 (UTC)

Defaulting to increases of precision such as from 90 to 145 would be yet more troubling. NebY (talk) 17:43, 27 January 2023 (UTC)

@NebY and @Imzadi1979: I'll freely admit to not having continued with mathematics after I finished high school, so I apologise if I'm stumbling over something that college students are expected to find easy – but I'm genuinely still unconvinced. This discrepancy popped up in describing a railway locomotive's maximum speed, which is given by the manufacturer as "90 mph". Now, obviously, giving "144.84096 km/h" as the equivalent is needlessly over-precise, but in my view "140 km/h" is not much better, and worse is counter-intuitive. That same manufacturer has similarly built locomotives with maximum speeds of 75, 100, and 125 mph, all of which are given with neither no more nor no less precision than when they specify 90 mph – but as the user of the template I'm expected to know that whole numbers ending in zero are converted differently, and that the degree of difference can vary depending on the relative 'size' of the result? Looking more closely I can see that the same behaviour affects the conversion of 100 mph, but it's much less egregious because "160 km/h" verses "160.9344 km/h" verses "161 km/h" looks like a much-more-simple choice of truncation or rounding. At the very very least this should be made much more clear in the template documentation. XAM2175 ^(T) 18:18, 27 January 2023 (UTC)

@XAM2175: put another way, "90 mph" is only precise to the tens place, unless notated differently. The default output of "140 km/h" is also only precise to the tens place. So looking at it that way, the input and output are equally precise. If "90 mph" is precise to the ones place, it needs to be notated differently because that 0 in the ones place is ambiguous: could the device measure in increments of 1 mph, or only in increments of 10 mph? There are a few ways to express intended precision unambiguously, like "90. mph" or "90 mph". The template can handle the former as an input, or a rounding factor can be used like |0.

{{cvt|90.|mph}} ➡️ 90 mph (145 km/h)

{{cvt|90|mph|0}} ➡️ 90 mph (145 km/h)

When converting 75 mph, the default output is 121 km/h; both are equally precise to the ones place. Because the last digit is not a 0, it is assumed that the measurement device can measure in increments of 1 mph.

Now, viewed in line with other stated measurements, a reader could assume that the "90 mph" is precise to the ones place because the other measurements in a series are also precise to the once place. The template cannot make that assumption because it only sees the individual input it's acting upon. If it's given a grouping of inputs, it can use all of them to figure a default precision:

{{cvt|75|,|90|,|100|and|125|mph}} ➡️ 75, 90, 100 and 125 mph (121, 145, 161 and 201 km/h)

That example uses precision from the "75 mph" and "125 mph" inputs for consistency.

As to the documentation, there's an entire section that explains how the template handles rounding, and it's the first FAQ at the top of this talk page. Imzadi 1979 → 18:30, 27 January 2023 (UTC)

Thank you for the explanation; it's helped me understand things better.

As to the documentation, there's an entire section that explains how the template handles rounding, and it's the first FAQ at the top of this talk page – this is part of the problem, though: without the better understanding I now have, neither of those explanations appeared to relate to the circumstances I was describing. Template:Convert § Default rounding (the first part of the "entire section" you mention) doesn't address the significant figures issue because the first example used is 123 ft; both {{convert|123|ft|m}} and {{convert|123|ft|m|0}} produce 37 m. The second example, 500 ft, does – I grant – illustrate the issue, but with the explanation same output as with -1 (above), because the conversion factor is between 0.2 and 2 (hence, it should produce same [sic] double-zero precision (−2) as in the input value), but the conversion must produce two significant digits at a minimum (hence, a higher single-zero precision (−1) is used)... which, to tell you the truth, I still don't really understand, and which appears to presuppose that users of the template already know the conversion factor of the conversion they're intending to perform. Remember, this is meant to be the standard guidance; the hatnote says that the "more mathematical description" is at Help:Convert § Rounding.

As for the the first FAQ on this talk page, 1) the discrepancy about which I was concerned seemed to be more than just a bit off, 2) it assumes that the reader's understanding of precision extends to significant figures before the decimal, and 3) it's only at the end of the linked Help:Convert § Rounding section that An input value such as 5000 is assumed to have one significant figure, while 5001 has four finally appears.

Neither of these, however, address my central concern: I'm only here because I know that 90 mph shouldn't convert to 140 km/h in practical applications. What happens for users who don't? XAM2175 ^(T) 19:30, 27 January 2023 (UTC)

I hesitate to add anything for fear of detracting from Imzadi's excellent account. Still, to be exact about this specific case, our article doesn't say it's the manufacturer's advertised top speed. It's a train unit specification which, without being able to see the paywalled journal describing the specification, may be more of a classification than a test speed, and certainly wasn't something like a speed record which would require precision. That specification was abandoned and replaced with one described as "75 mph (121 km/h)", also using Convert's default but in this case producing, to my eyes, excessive precision and thus an illustration that somehow reprogramming Convert to default to higher precision would have distinct disadvantages. It is disturbing that our article confuses speed and acceleration, calling for a maximum speed of 90 mph (145 km/h), acceleration comparable to contemporary EMUs. NebY (talk) 19:28, 27 January 2023 (UTC)

Re It is disturbing that our article confuses speed and acceleration..., this was accidentally introduced in this very recent edit where the editor removed five items from a seven-item list but failed to convert the comma between the remaining two items into "and". Thanks for pointing it out, and I've now corrected it.

Re It's a train unit specification which, without being able to see the paywalled journal describing the specification..., the exact quote from the source is

For the longest spacing, as typified by Birmingham–Norwich (17 miles station spacing), a 7 h.p./tonne unit geared for 90 mile/h is 0.5 per cent slower than a unit geared for 75 mile/h. 75 mile/h was, therefore, selected as this would show benefits in journey time on the vast majority of routes with shorter station spacing.

Additionally, in different places in the journal, the specifications are given as: 90 mile/h top speed (145 km/h) and 75 mile/h top speed (120 km/h). While I concede the difference between 120 and 121 km/h, I think it's reasonably evident that the descriptions intentionally include a level of precision higher than just "in the ballpark" (if I'm understanding your may be more of a classification correctly). XAM2175 ^(T) 19:50, 27 January 2023 (UTC) ETA: the journal is available via the Wikipedia Library, should you wish to view it yourself.

We may be getting a bit deep into the weeds here, but I do notice that quote refers to gearing for a higher speed actually achieving a lower overall speed, rather reinforcing my sense that these were to some extent nominal ratings. I'm reminded of the imperial series of pipe and flange sizes based on nominal bores, ½", ¾", 1", 1¼", 1½", 2", 2½", 3" etc which are now commonly designated as 15, 20, 25, 32, 40, 50, 65, 80 etc, many of which are values that Convert would not and should not produce by default. In that way, using equivalents taken from the source doesn't seem such a bad thing here. NebY (talk) 15:10, 28 January 2023 (UTC)

References

It's a basic question of significant figures. 9000, 900, 90, 9, and .9 all have one significant figure. 7500, 750, 75, 7.5, and .75 all have two significant figures. The default rounding behavior operates based on the number of significant figures in the input number (with the conversion adding one sigfig for most conversions). Frankly, it would be much more surprising if some conversions gave you additional precision. To write 90mph as having two significant figures, you would have to write 90. mph. This is not specific to WP, this is universal practice. Similarly, 90.0 has three significant figures.

Below see what conversion template does with one, two, and three sigfigs in the input:

{{cvt|90|mph}} 90 mph (140 km/h)

{{cvt|90.|mph}} 90 mph (145 km/h)

{{cvt|90.0|mph}} 90.0 mph (144.8 km/h)

But in the end, I would say that the numbers provided in the reference are actually rounded to fives and not to either one or two significant figures - which is actually another option: {{cvt|75|to|90|mph|round=5}} 75 to 90 mph (120 to 145 km/h). (this result may seem counterintuitive, as the more precise input number has a more rounded output and vice versa.) It is often up to the editor to figure out what level of precision is provided in the original source; the default converter cannot possibly know the context. Best,  Mr.choppers | ✎  01:58, 12 February 2023 (UTC)

Rounding for multiple units

I want to have an input of 1991 cc display as 2.0 L (1991 cc; 121 cu in) - ie L to 1 digit and cc and cuin to 0 digits. I was hoping that something like {{cvt|1991|cc|L cc cuin|order=out|adj=ri1|0}} would do it, based on |abbr=in abbreviating the first displayed param rather than the actual first. But it rounds the actual first param and shows as 2 L (1,991.0 cc; 121 cu in). Any clues?  Stepho  talk  09:42, 12 February 2023 (UTC)

Have you considered using {{Convert}} twice? (§ doc) DePiep (talk) 09:49, 12 February 2023 (UTC)

I did. It's my fall-back but it's kind of clumsy and I was hoping for something shorter and more elegant. And anything complex is harder for future (possibly novice) editors to replicate for new bits of info they want to add.  Stepho  talk  11:06, 12 February 2023 (UTC)

Yes. I did not research deeply, so maybe that more elegant solution exists. DePiep (talk) 11:55, 12 February 2023 (UTC)

I have been banging my head against this wall for a long time. In general, I just omit cubic inches since they are largely disused, even in the US. A better workaround is {{cvt|1.991|L|cc cuin|adj=ri1|0}} which produces:

• 2.0 L (1,991 cc; 121 cu in). Best,  Mr.choppers | ✎  13:35, 15 February 2023 (UTC)

Yes, that looks like a good work-around. Thanks.  Stepho  talk  21:45, 15 February 2023 (UTC)

Hundredweight

For Adler (locomotive), how does one convert 177 hundredweight (long) to pounds and kilograms? Peter Horn User talk 21:37, 10 March 2023 (UTC)

{{convert|177|Lcwt|lbs kg}} should do the trick: 177 long hundredweight (19,800 lb; 9,000 kg). XAM2175 ^(T) 21:58, 10 March 2023 (UTC)

@XAM2175: Thanks Peter Horn User talk 01:35, 11 March 2023 (UTC)

Special adjective

Most of the articles I write are related to 19th century military history, when cannon were generally known by the weight of the projectile they fired, so the general names for these guns are often things like 32-pounder, 12-pounder, 100-pounder, etc. Is there a way to make this template spit out the -pounder adjective, or will I just need to manually perform conversions of these weights into kilograms? Hog Farm _Talk 02:56, 15 March 2023 (UTC)

How about an example of what you would like displayed in an article? Help:Convert#Extra words shows some suggestions but convert shows the name of the unit so it will show "pound" which would look silly next to "pounder". If you explain what is wanted, we may have some ideas. Don't perform manual calculations. How many articles (roughly: 10? 1000?). Johnuniq (talk) 03:58, 15 March 2023 (UTC)

An example would be in the text at Battle of Grand Gulf - This fort mounted a 100-pounder Blakely rifle, another 8-inch Dahlgren piece, and two more 32-pounders., with pounds to kg for the gun sizes, or USS Marmora (1862) - Initially, Marmora was armed with two 12-pounder rifled cannons and two 24-pounder guns. (a change I've specifically been asked to make at the FAC). I'm unclear how many articles this could potentially be used in, but see Caliber#Pounds as a measure of cannon bore for a better explanation of the situation. Hog Farm _Talk 13:34, 15 March 2023 (UTC)

How about {{convert|100|lb|kg|disp=x|er (|)|0|sing=on}} to give "The fort mounted a 100-pounder (45 kg) Blakely rifle."

And {{convert|32|lb|kg|disp=x|ers (|)|0|sing=on}} to give "two more 32-pounders (15 kg)."  Stepho  talk  13:53, 15 March 2023 (UTC)

This usage will appear in a very large number of milhist articles even in the Cold War era. I've also seen it abbreviated as "pdr", though I'm not sure if that's considered acceptable. The form suggested by @Stepho-wrs seems to satisfy the request, but I wonder if perhaps it would be worth creating a new template employing the Convert module especially for this purpose? XAM2175 ^(T) 13:58, 15 March 2023 (UTC)

I don't think it's appropriate to supply kg conversions for x-pounder guns. Conversions are to help people who are more familiar with the other units in the field under discussion. If there were a tradition of rating guns in terms of kg, then we should give conversions, but there is no such kg tradition, only a pounder tradition. And for most of the guns that are described as x-pounder, there is no object with a mass of x pounds that is used with them. A bore diameter in mm is helpful to readers, but not a conversion to kg. Indefatigable (talk) 16:03, 15 March 2023 (UTC)

I agree with Indefatigable. Stepho's solution is very elegant (still trying to figure out what some of it does exactly), but I do not think there is a reason to convert these to metric as it is not how guns are measured. If anything, these would best be manually converted to cm or whatever unit of length is most suitable.  Mr.choppers | ✎  19:59, 15 March 2023 (UTC)

That's true for the specific case of weights. However, metric units of length are used for the caliber of artillery; even in the US, artillery intended for use in NATO has a metric caliber, e.g., 105 mm, 155 mm. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:17, 16 March 2023 (UTC)

I agree, that's why I suggested manually converting the weight into diameter, if that is even possible. Is there a clear conversion method from, say a 12-pounder to millimeters?  Mr.choppers | ✎  12:41, 16 March 2023 (UTC)

For modern US artillery, there's the millimeter caliber, but in Mexican War/Civil War/etc., the cannon were generally known by either an inch bore-diameter: see, for instance, 3-inch ordnance rifle or M1841 6-pounder field gun. I don't think I've ever seen a source refer to a Civil War cannon by a mm designation. Hog Farm _Talk 14:16, 16 March 2023 (UTC)

I'm not aware of a US metric caliber weapon prior to NATO. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:49, 17 March 2023 (UTC)

There's the 105mm M2/M101 to start. Orange Suede Sofa (talk) 18:46, 17 March 2023 (UTC)

They likely did not use mm, but a conversion is in order to explain obsolete units that would otherwise be meaningless to the majority of readers.  Mr.choppers | ✎  20:32, 17 March 2023 (UTC)

They did use mm, as can be seen from the technical manual from the time. Orange Suede Sofa (talk) 20:38, 17 March 2023 (UTC)

We've shown that convert can translate from pounder to kg (although it is a bit long to call it elegant). The question of whether it should be used, in what context and whether it should have a wrapper template is a question that belongs at WP:WEAPON. And of course we can't convert from pounder to mm but the question of converting inches to mm for cannons also belongs there.  Stepho  talk  20:55, 17 March 2023 (UTC)

Li unit

I was editing Heaven and I discovered the measure in the Theravada Buddhism is the lǐ. Is it possible to add it? Thanks.--Carnby (talk) 17:28, 24 March 2023 (UTC)

It seems to me the most appropriate units to support in the Convert template are ones that have a generally agreed value in SI units. The article about the li unit seems to indicate there are a variety of different values. It might be more appropriate to expect any editor who mentions this unit to explain what value is intended in the article where it is used, rather than rely on a conversion template. Jc3s5h (talk) 17:35, 24 March 2023 (UTC)

Well, I'm not sure SI is the touchstone, but in general {convert} should restrict itself to units that have been reasonably stable over time. EEng 20:09, 24 March 2023 (UTC)

If added it then we would have to be able to distinguish between the various values used over time - in much the same way that we distinguish between imperial and US gallons. Possibly we could have the units called "gongli", "li-xia", "li-qin", etc.  Stepho  talk  01:32, 25 March 2023 (UTC)

Convert Fractional Inches to Decimal Inches and Centimeters

I recently contributed a large table of lengths corresponding to shoe sizes measured with the Brannock device to Shoe_size#Brannock_Device. All the calculations behind the table values are in inches. Hopwever, one column in particular, of arch lengths, uses a gradation in fiftieths of an inch. That produces some lengths, like 5+69/100, that aren't very intuitive, even for those familiar with more common fractions, like quarters, eighths, and sixteenths.

Can convert be used to display inch lengths in decimal inches, as well as centimeters? kemitchell (talk) 04:49, 26 March 2023 (UTC)

Slightly clumsy but {{convert|{{#expr:5+29/50}}|in|0}} displays 5.58 inches (142 mm)  Stepho  talk  05:00, 26 March 2023 (UTC)

I have no idea what would be best for that article but in general, if the value in the source is 5+69/100 then it might be best to use that in convert and have it display the unusual fraction. If using Stepho's workaround, you might need to add |adj=ri2 to round the display of the input value. That uses the full precision of the calculation for convert (to get the correct output), but rounds the input to two decimal places. Johnuniq (talk) 07:50, 26 March 2023 (UTC)

incorrect use of "change"

The use of this template produces incorrect use of the word "change", for example in the James A. Garfield article. --Espoo (talk) 09:47, 26 March 2023 (UTC)

It seems like the long name always has "change" as part of the displayed unit name. But using the abbreviated unit names on both sides (ie change |abbr=out to |abbr=on) solves it: {{convert|20|F-change|C-change|abbr=on}} gives 20 °F (11 °C)  Stepho  talk  10:01, 26 March 2023 (UTC)

Well it doesn't solve the problem, but thanks for the workaround! --Espoo (talk) 11:39, 26 March 2023 (UTC)

Just to make sure I understand the issue. This was the code used in the article:

{{convert|20|F-change|C-change|abbr=out}} → 20 degrees Fahrenheit change (11 °C)

And the result of this should be 20 degrees Fahrenheit (11 °C) without the word "change"? Gonnym (talk) 12:00, 26 March 2023 (UTC)

Yes, but due to abbr=out, Celsius should of course not be abbreviated. BTW, is there a reason why the toggles are the weird on/out instead of the normal English on/off? --Espoo (talk) 20:34, 26 March 2023 (UTC)

|abbr= has values off (full names everywhere), in (abbreviate input only), out (abbreviate putput only) and on (abbreviate everything). For your example, |abbr=out means display the full input (Fahrenheit) name but abbreviate the output (Celcius) name.  Stepho  talk  21:13, 26 March 2023 (UTC)

Can convert template be used for this?

On 2022 New York City Marathon, I would like to use conversions for where it says "at mile 14" so it says "at mile 14 (kilomtere X)". If you use {{convert|14|mi|km}}, then this says 14 miles, not mile 14. Is this something the template can do? Or if not, any suggestions on the best way to re-word the text to use the functionality available in the template? Joseph2302 (talk) 16:01, 27 March 2023 (UTC)

If you're using it in the sense of distance from start – that is, mile 14 is the point 14 miles from the start – the most straightforward way is probably going to be to use mile 14 ({{cvt|14.0|mi|km|disp=out}}), which will produce mile 14 (22.5 km). The decimal zero is deliberately included to avoid the default behaviour of rounding the output figure to the nearest whole kilometre. As to the line The runners cross the Willis Avenue Bridge, where they enter The Bronx for miles 19 and 20; I would re-write that to use the same "run in x direction for y miles" style as the portions of description on either side of it, in order to avoid ambiguity and spare having to devise an awkwardly worded conversion. XAM2175 ^(T) 19:55, 27 March 2023 (UTC)

XAM2175 perfect, thank you. Joseph2302 (talk) 09:52, 29 March 2023 (UTC)

Line wrapping

On an article I have been working on, I have just seen an instance of this template wrap a line, with the effect:

Lorem ipsum dolor sit amet, consectetur adipiscing 1

metre (1.1 yd) Lorem ipsum dolor sit amet...

Equally bad would be:

Lorem ipsum dolor sit amet, consectetur adipiscing 1 metre (1.1

yd) Lorem ipsum dolor sit amet...

I don't want to {{nowrap}} the whole thing; but can we make it so that each component ("1 metre"; "(1.1 yd)") does not wrap? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:34, 9 April 2023 (UTC)

As I understand the principle, "metre" can have a newline because it is a word (not an abbr/symbol). In-sentence numbers do not require NBSP. Per the same rule, "1.1 yd": indeed, a newline would be bad — and may not occur (If you see it happen, that would be a bug). DePiep (talk) 18:03, 9 April 2023 (UTC)

That's a MOS:UNIT thing. See "a normal space is used between a number and a unit name". In the MOS example, the result looks reasonable but I agree that with a short number such as in "1 metre", a line break would look odd. However, convert isn't clever enough to judge when MOS:UNIT should be ignored. Johnuniq (talk) 05:47, 10 April 2023 (UTC)

Mistake in "Currency per unit: $/mi → $/km" output

In Template:Convert#Currency per unit: $/mi → $/km, the output for ranges violates MOS:CURRENCY#Formatting of monetary values, specifically that the currency symbol should only be used at the beginning of the range. Example:

{{Convert|10|-|15|$/mi|$/km}} yields "$10–$15 per mile ($6.2–$9.3/km)" [included for historical purposes: "$10–$15 per mile ($6.2–$9.3/km)"], but should instead display "$10–15 per mile ($6.2–9.3/km)". — DocWatson42 (talk) 22:52, 9 April 2023 (UTC)

Yuck, that's ugly. Somehow the MOS example ($250–300 million) looks ok, but the OP example ($10–15 per mile) is decidedly unattractive IMHO. We need an enthusiast to take on the MOS and get that changed. Johnuniq (talk) 03:40, 10 April 2023 (UTC)

The MOS example looks fine to me. <shrug> — DocWatson42 (talk) 05:24, 10 April 2023 (UTC)

I can live with either. But I can also appreciate that this could form a splinter in your brain.  Mr.choppers | ✎  14:21, 10 April 2023 (UTC)

Parenthesis

There should be an option to change parenthesis to brackets, so we can use these in parenthesis. – Illegitimate Barrister (talk • contribs), 19:33, 6 April 2023 (UTC)

{{convert|99|psi|disp=sqbr}}: 99 pounds per square inch [680 kPa] Indefatigable (talk) 19:37, 6 April 2023 (UTC)

Some other alternatives for use inside parenthesis are comma or "or":

{{convert|99|psi|disp=comma|abbr=on}}: 99 psi, 680 kPa

{{convert|99|psi|disp=or|abbr=on}}: 99 psi or 680 kPa  Stepho  talk  02:55, 7 April 2023 (UTC)

Merci merci. – Illegitimate Barrister (talk • contribs), 22:03, 11 April 2023 (UTC)

disp=semi

Could |disp=semi be added to insert a semicolon between values in the same way the |disp=comma works? I realise that it is possible to use |disp=x|; | but that is unnecessarily ugly way to do something that is quite commonly required. Gaius Cornelius (talk) 07:15, 11 April 2023 (UTC)

• That's:

{{convert|1|km|mi}} → 1 kilometre (0.62 mi) -- default

{{convert|1|km|mi|disp=comma}} → 1 kilometre, 0.62 mi -- comma

{{convert|1|km|mi|disp=x|; }} → 1 kilometre; 0.62 mi -- using ..=x|; |, the space is relevant

doc: § Brackets and separators

-DePiep (talk) 07:35, 11 April 2023 (UTC)

• Propose using |disp=semicolon not 'semi' (if at all). No help in introducing uncommon codeword. -DePiep (talk) 07:37, 11 April 2023 (UTC)

  Yes, |disp=semicolon would be better. Gaius Cornelius (talk) 07:42, 11 April 2023 (UTC)

• It would be a simple change. However, convert has been around a long time and I don't recall anyone requesting this so please show a couple of examples where a semicolon is helpful and let's get other opinions. Johnuniq (talk) 07:46, 11 April 2023 (UTC)

  There was my mistake that you corrected a few days ago. I did look for a |disp=semi option but had to settle for |disp=or.  Stepho  talk  08:15, 11 April 2023 (UTC)

• I am not sure that there are any specific rules of grammar for these cases but whereas using a comma as a separator seems entirely natural in a list of values of the same unit, the semicolon seems natural in a list of values with different units. In fact, convert already does this when converting to multiple units. For example:

{{convert|30|,|40|,|50|or|60|mi|km}} → 30, 40, 50 or 60 miles (48, 64, 80 or 97 km)

and:

{{convert|1000|K|F C}} → 1,000 K (1,340 °F; 730 °C)

Contributors frequently write measurements inside parentheses and choose to represent different units separated by semicolons. Examples from the wild:

Transport in Myanmar: The railway trip from Bagan to Mandalay takes about 7.5 hours (111 miles; 179 km).

Richmond Park: most of Richmond Park (856 hectares; 2115 acres) is a Site of Special Scientific Interest

Morocco–Spain border: ...around the Spanish territories of Ceuta (8 km; 5 miles), Peñón de Vélez de la Gomera (75 metres; 80 yards) and Melilla (10.5 km; 6½ miles).

Mount Bingham: South Hill is a hill (48 meters; 157 feet) in St. Helier

This format is very common indeed and could be readily supported by |disp=semicolon. The contributor will supply the enclosing parentheses.

Gaius Cornelius (talk) 04:34, 12 April 2023 (UTC)

Indeed convert already uses semicolon for some responses (correctly, IMO): {{convert|5.67|mi|ch km}} yields 5.67 miles (454 ch; 9.12 km). --𝕁𝕄𝔽 (talk) 10:57, 12 April 2023 (UTC)

If I read this correct, GC says: "numbers for same unit => use comma separator for the numbers; when different units => separate values by semicolon". (Makes sense, and the examples --even by {{Convert}} e.g. C; F-- are clear).

Interestingly, this would imply to deprecate the existing |disp=comma usage ... DePiep (talk) 12:25, 12 April 2023 (UTC)

I'll add disp=semicolon soonish. Johnuniq (talk) 05:00, 13 April 2023 (UTC)

Great! Thank you! Gaius Cornelius (talk) 22:22, 13 April 2023 (UTC)

Johnuniq, you think we should (discuss to) change default, MOS or advise for preferred usage of semicolon instead of current comma (in situation: separator for multiple, complete values)? Examples throughout this thread. DePiep (talk) 06:35, 16 April 2023 (UTC)

It would be a bit of a shock for disp=comma to show anything other than a comma. I think we would have to leave people to use what they want for several months before proposing to replace commas. There are about 1050 converts in articles with disp=comma, for example, "(19.1 °C, 66.4 °F)" at the end of the lead in Andalusia. It's likely that semicolon would be a more correct choice but frankly I don't think it would make much practical difference, for example, "(19.1 °C; 66.4 °F)". I can't find any previous discussion about wanting semicolons rather than commas so it is not something that people have noticed. Johnuniq (talk) 07:33, 16 April 2023 (UTC)

One thing at a time, I think. It would not be helpful to change the behaviour of |disp=comma and, rather, to give contributors a straightforward choice of comma or semicolon for now. In time however, changing the MOS (which would have affects beyond the way {{convert... works) would be small but welcome enhancement to readability and internal consistency in WP. I suspect that many editors resorted to |disp=comma on finding that |disp=semicolon was not an option. Gaius Cornelius (talk) 08:12, 16 April 2023 (UTC)

Stupid me. I meant to point at default, but that's semicolon already.

{{convert|100|K|C F}} → 100 K (−173 °C; −280 °F) Y

Struck. Consider closed pls. -DePiep (talk) 08:37, 16 April 2023 (UTC)

I have put the changes for the next release in the sandbox so {{convert/sandbox}} can be used for testing. For example,

• {{convert/sandbox|123|kg|lb stlb|disp=semicolon}} → 123 kilograms; 271 lb; 19 st 5 lb

Johnuniq (talk) 09:57, 16 April 2023 (UTC)

Bits and bytes

At Module:Convert/extra, Kavuldra added units bit and B (byte) on 11 August 2022. Unit B is not used and I plan to remove it. Unit bit is used in one article only, namely Patterned media in two converts (this uses fixed wikitext to show the outputs as they occur now):

• {{cvt|20|-|300|Tbit/in2|Tbit/cm2}} → 20–300 Tbit/in² (3.1–46.5 Tbit/cm²)
• {{cvt|1|Tbit/in2|Gbit/cm2}} → 1 Tbit/in² (160 Gbit/cm²)

That is a good way of showing useful information but it would be unusual for convert to support a unit that is used in only one place. Any thoughts on bit or byte units? I'm asking because I will be releasing a new version of convert soon and want to get a few old issues sorted out first. Should bit be retained? What about B? Johnuniq (talk) 04:48, 16 April 2023 (UTC)

I'm for ditching both of them. Can't think of many situations where they would be useful - perhaps CDs, tapes and hard drives as bits/cm vs bits/inch (bytes/inch for paper tape).

If they are kept, then I would use the keywords "bits" (displays as "bits" or "b") and "byte" (display as "bytes" or "B") and avoid the keywords "B".  Stepho  talk  05:27, 16 April 2023 (UTC)

Support removal. The "B=Byte, b=bit" convention is so widely misunderstood as to be unusable (fortunately it is a while since I have seen a "100 millibit" [sic] SD card advertised). --𝕁𝕄𝔽 (talk) 09:22, 16 April 2023 (UTC)

Remove. The potential for confusion is higher than the potential for useful conversion. Tarl N. (discuss) 17:10, 16 April 2023 (UTC)

Remove. How to make a useful conversion between bits and bytes is context specific, so should not be done with a template. For example, one might know that 1 million bytes per second of content are being transferred, and want to know how many bits per second are moving over the communications channel. Calculating this would require an allowance for overhead, so unsuitable for a template. Jc3s5h (talk) 17:26, 16 April 2023 (UTC)

Module version 28

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

• Four new SI prefixes were added by WOSlinker: Q quetta, R ronna, r ronto, q quecto.
• Option spell=in spells the input number in words while sp=us displays the US name for units (for example, "liter" instead of "litre"). To reduce confusion, spell=us is now an alias for sp=us. Examples:
  • {{convert|123|km|sp=us}} → 123 kilometers (76 mi)
  • {{convert|123|km|spell=us}} → 123 kilometers (76 mi)
• Option disp=semicolon can be used to separate items with a semicolon. Discussion here.
  • {{convert|123|kg|lb stlb}} → 123 kilograms (271 lb; 19 st 5 lb)
  • {{convert|123|kg|lb stlb|disp=comma}} → 123 kilograms, 271 lb, 19 st 5 lb
  • {{convert|123|kg|lb stlb|disp=semicolon}} → 123 kilograms; 271 lb; 19 st 5 lb
• Unit changes:
  • The default for s is changed from minutes to hours if the seconds value is 7200 or more (two hours or more). The default remains as minutes otherwise. In addition, sec is an alias for s because sec has been used since an experiment was added following a discussion in March 2022.
  • Added hm³ as an alias for hm3 to suit Wikidata (discussion here).
  • Added inches as an alias for in to complete allowing plurals for common lengths and masses (discussion here).
  • Fixed scale for unit BTU/lb (done in diff by NebY on 28 October 2022; discussion here).
  • Fixed scale for unit mpge (discussion here).
  • Fixed US name and symbol (deadweight metric ton) for unit DWtonne (discussion here).

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

Litre/liter and L/l
A discussion above has raised the issue that MOS:UNIT recommends L rather than l for litres/liters and there is a MOS discussion here. I have been wondering what convert can do regarding this and was contemplating incorporating changes in this release. However, I have decided that it would be better to get the current adjustments done and have another release purely for L/l later. I have added my current inclination as a subsection of the above discussion, namely here. Johnuniq (talk) 08:27, 17 April 2023 (UTC)

• This version is now live. @Mliu92: I said I would notify you when mpge works—that's now. Johnuniq (talk) 05:13, 19 April 2023 (UTC)

Minor message

Johnuniq FYI, Module:Convert/tester has an error at Line 38. Could be unnneeded escaping \+? mw:man. Here to learn, DePiep (talk) 06:02, 19 April 2023 (UTC).

Thanks, that is a bug. I have worked with a variety of strange systems with different regex styles and must have confused myself. It looks as though the backslash does not make any difference—I think Lua interprets \+ as just + and then applies the regex. However, it is a bug and I will fix it although I don't want to do any extra thinking at the moment so I'll wait until I get a chance to review the whole thing. Johnuniq (talk) 08:47, 19 April 2023 (UTC)

Yes, is my thought too. Met same here (L237): unneeded but trivial escape. Not urgent. DePiep (talk) 14:52, 19 April 2023 (UTC)

Ranges

I know that this template handles ranges, but I can't see where in Module:Convert/documentation/conversion data it is documented? --𝕁𝕄𝔽 (talk) 10:07, 1 May 2023 (UTC)

At Template:Convert/doc#Ranges_of_values  Stepho  talk  10:57, 1 May 2023 (UTC)

Thanks Stepho, I knew I had seen it somewhere. Now would anyone like to add this third source of information to the FAQ at the top of this page? Where it reads:

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.

(which I guess is not the right question so I shouldn't complain about not getting the right answer. ) --𝕁𝕄𝔽 (talk) 00:04, 2 May 2023 (UTC)

Liter

Hi, the template appears to still be outputting "l" for liter, eg. 42 US gallons (160 L; 35 imp gal). Can this be updated to output "L" instead, per the MOS? Thanks. BilCat (talk) 18:14, 25 March 2023 (UTC)

Support this change, for what it's worth. The relevant section of the MOS is roughly half-way through the table at MOS:INCH. XAM2175 ^(T) 21:30, 25 March 2023 (UTC)

Unit USgal has a default output of l impgal. Use L to display uppercase:

• {{convert|42|USgal|L impgal}} → 42 US gallons (160 L; 35 imp gal)

Johnuniq (talk) 23:28, 25 March 2023 (UTC)

@Johnuniq, with respect, the entire point of the requested change is that the use of l rather than L as the symbol for litres is inconsistent with the Manual of Style. Changing the default output accordingly – for all relevant conversions, not just USgal – achieves greater MOS compliance.
I would in fact go further and say that the upper-case symbol should be used even where the lower-case symbol has been specified in the template arguments, but I appreciate that that might be considered too far for the "should not be used" wording found in the MOS. XAM2175 ^(T) 23:53, 25 March 2023 (UTC)

Concur. Yes, I know how to make it display the uppercase, but I shouldn't have to, as the uppercase is recommended, not just optional. BilCat (talk) 00:09, 26 March 2023 (UTC)

So, what is the proposal? That every l be replaced with L for the outputs at Module:Convert/documentation/conversion data? It's messy. Should it be possible to output 12.3 ml? The problem there is that the SI prefixes are determined by software and convert has no provision for sometimes outputting L and sometimes l. A fairly quick fix would be to change all default outputs to use L rather than l. In principle, Module:Convert could be modified to do something special that would work at enwiki and presumably not cause too much disruption at other Wikipedias. However, coding an exception is a lot more complicated than first appears. Johnuniq (talk) 01:57, 26 March 2023 (UTC)

So you're saying the software, as currently written, can't distinguish between an default output for L for liter and ml for mililiter? Well, I guess we'll have to change the MOS again. Can't inconvenience the software for the sake of human rules. BilCat (talk) 04:14, 26 March 2023 (UTC)

Johnuniq mentions the situation "12.3 ml" (SI prefixes), which requires handling different from "7.5 L". MOS is not clear about this a priori. Changing MOS to say so (i.e., outside of {{Convert}} area) would create an enwiki code variant (hard & complicated to code & maintain & internationalise), so we should think before. DePiep (talk) 06:11, 26 March 2023 (UTC)

So basically the answer is, "Screw the MoS, we're not going to try to follow it because it's too difficult, and how dare you try to make more work for me." John should have just said that up front, and I'd have stopped wasting my time here right then. BilCat (talk) 06:35, 26 March 2023 (UTC)

Umm, that's not exactly what was said! If you want an interpretation, please ask. The point is that changing a unit (say from l to L) is simple/fast but it would be tricky/slow to build an exception into the module so ml (or any other SI prefix) can be lowercase (but not must be), while a single l must be converted to L. I'm trying to clarify what the proposal is. Given that it would change a lot of the existing outputs, I suspect it might be worth having a wider discussion. Hey EEng, you probably recall the MOS discussion. Do you have a feeling for what the mood is? Should convert make it not possible to output l but make it possible to output ml? Johnuniq (talk) 07:39, 26 March 2023 (UTC)

• That's how your comments came across to me. I'm sorry I misinterpreted them. BilCat (talk) 18:16, 27 March 2023 (UTC)

First I think we need to address a weirdness in the MOSNUM units table -- see the thread I just opened over there. EEng 05:48, 27 March 2023 (UTC)

If I strike out your unhelpful talk BilCat (pls do so yourself next time), you are supposed to point/quote the MOS lines that say so. I read: "should not be used" and "may use": not prescriptive. (Incidentally, don't see why ENGVAR is mentioned in this). DePiep (talk) 08:20, 26 March 2023 (UTC)

• I'm sorry, but if your comment was addressed. to me, I have no clue what you're talking about. BilCat (talk) 18:16, 27 March 2023 (UTC)

The fact that ml v. mL is an ENGVAR issue is was news to me before I read the full MOS table earlier. Personally I would prefer to switch all uses to the upper-case variant, especially if that is a more-simple change to make, but Johnuniq is correct to note that that would probably require a wider discussion. XAM2175 ^(T) 11:22, 26 March 2023 (UTC), 14:10, 26 March 2023 (UTC)

See #MOS:LITRE below. It appears that sole lowercase "l" is discouraged (or prohibited?), and mL/ml is optional; depending on ENGVAR (?).

Before we can ask or require changes to {{Convert}}, we should cleanup this MOS. (1) remove ENGVAR. (2) require "xL" enwikiwide (not ml). Note that we're talking SI units, not language. (Meanwhile, to cheer us up: enjoy Another nice MOSS you got me into.) -DePiep (talk) 13:42, 26 March 2023 (UTC)

MOS

From MOS:INCH, as of 12:00 26 March 2023. Two rows relate to litre:

• The following table lists only units that need special attention.
• The SI Brochure should be consulted for guidance on use of other SI and non-SI units.

Guidelines on specific units

Group	Unit name	Unit symbol	Comment
Volume, flow	litre liter (US)	L (not l or ℓ)	The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye") and should not be used.
	millilitre milliliter (US)	ml or mL	Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.

-DePiep (talk) 13:26, 26 March 2023 (UTC)

Yes, that's the table I linked to in my initial reply to BilCat. I apologise for any confusion; I meant to say that I was unaware of the potential ENGVAR issue until that point, rather than now. I've edited my comment accordingly. XAM2175 ^(T) 14:14, 26 March 2023 (UTC)

• The "according to ENGVAR" bit seems problematic, and that needs to be resolved first, methinks. Stand by and I'll open a thread at Talk:MOSNUM. EEng 05:22, 27 March 2023 (UTC)

  Yes good plan, that's an isolated issue. (Looks like it was originally misguided by the wording part of litre/liter; untouched here). DePiep (talk) 06:12, 27 March 2023 (UTC)

Liter plans

There will be a new release of convert soon (see below). Since fixes for L/l will involve a lot of units I have decided to delay those fixes for a future release. My current thoughts are that it would be unusual for convert to prevent editors from generating output that is not prohibited. Therefore, my current view is that the defaults for all units related to volume should use uppercase L but if a convert explicitly uses, for example, ml as an output unit, lowercase l should be used. Gnomes would be welcome to change converts using ml to mL if wanted and if it didn't cause too much disruption. I have a list of articles using that kind of output and can post it somewhere if needed. There are over 4000 converts in articles that output a lowercase l and changing unit defaults would cause a majority of them to switch to uppercase. Johnuniq (talk) 08:29, 17 April 2023 (UTC)

Thank you, Johnuniq. I agree with your suggestion, but can I ask for clarity's sake how you plan to handle conversions that explicitly call l for litres? In my view this should still be forced to L, but explicit calls for the lowercase symbol in derived units would continue to be supported as-is. XAM2175 ^(T) 11:30, 17 April 2023 (UTC)

FWIW, WP:MOSNUM says

litre; liter (US): L (not l or ℓ) The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye") and should not be used.

which is a real pity because U+2113 ℓ SCRIPT SMALL L is unambiguous and is commonly used in at least Germany. But ⟨L⟩ is what the MOS says it must be. Stand by to repel boarders. --𝕁𝕄𝔽 (talk) 16:14, 17 April 2023 (UTC)

re JMF: the SI brochure #9 says: "l" or "L" for liter full stop. -DePiep (talk) 20:09, 17 April 2023 (UTC)

Here is some information extracted from an all-articles dump from 1 April 2023. The articles have 806 converts that display xl with lowercase l. The units are ml, cl, hl, kl, Ml, Gl. Examples:

• Hamas • {{convert|15|kl|abbr=on}} → 15 kl (530 cu ft)
• Rickets • {{convert|17|USfloz|ml}} → 17 US fluid ounces (500 ml)
• Coca-Cola formula • {{convert|1|USqt|0|abbr=on}} → 1 US qt (946 ml)

These could be fixed by changing kl to kL in the first, changing ml to mL in the second, and inserting |mL in the last. Actually, the last fix would not be needed because the plan is to change the default output for USqt from ml to mL.

The same dump has 3364 converts that display l with lowercase l. Examples:

• Ford Model A engine • {{convert|177|CID|l|1|abbr=on}} → 177 cu in (2.9 l)
• Odd Fellows Windmill • {{convert|4000|gal}} → 4,000 US gallons (15,000 l; 3,300 imp gal)

These could be fixed by changing l to L in the first and inserting |mL in the last. As before, the last fix would not be needed when the default outputs are changed.

I have not yet examined {{cvt}} usage but it would be similar to the above. A simple approach would be start by changing all default outputs to use uppercase L then think about the next step. An easy second step would be to change the definition of the lowercase l unit so it is the same as L but I think there should be a significant RfC before that happened as it would prevent convert being used to output ml. Another solution would be for me to work out a trick so convert allows output of xl but always changes plain l to L. We can think about that in due course. Johnuniq (talk) 08:38, 18 April 2023 (UTC)

Just asking, worth waiting for MOS talk § ENGVAR controls big L or little L for litres/liters? to conclude? Could be a single letter (default then), although the quest does not look clean. Or maybe the options are fewer/simpler. DePiep (talk) 09:28, 18 April 2023 (UTC)

Yes, I didn't mention it but I looked at that discussion and whereas it does not seem to be going anywhere conclusive, we definitely should wait for it to conclude. Johnuniq (talk) 09:57, 18 April 2023 (UTC)

Actually, although the discussion has not been 'officially' closed, Dondervogel 2 boldly removed the ENGVAR qualifier from the actual MOS table just shy of two weeks ago now. XAM2175 ^(T) 10:31, 18 April 2023 (UTC)

Did not see that, nice. Hope it stabilises (and the l/L discussion can follow afterwards, correctly). DePiep (talk) 10:46, 18 April 2023 (UTC)

@Johnuniq: As the OP of that discussion, and one who got quite irritated with you responses, and unwarrantedly so, I thank you for working on this. Hopefully it will be able to be implemented in the near future. Your suggestions below about it look good to me. BilCat (talk) 06:09, 19 April 2023 (UTC)

Thanks, and I hope to get some results re L/l soon. However, as I've mentioned a couple of times although not recently, I have had a few off-wiki issues to deal with and things are even slower than normal. Johnuniq (talk) 08:31, 19 April 2023 (UTC)

See Template talk:Convert/Archive 3#Litre/liter symbol fix below to discuss plans for a new release. Johnuniq (talk) 08:18, 2 May 2023 (UTC)

sigfig=0

OK, I already wrote this in help talk:convert messages but maybe it goes here. Why can't we have sigfig=0? That is, rounded to the power of 10. When a value is already uncertain to a power of 10 or 100 or 100, it doesn't make sense to show more significance. Specifically, 7.5×10⁻⁸ Torr in vacuum tube. Gah4 (talk) 06:24, 2 May 2023 (UTC)

Simplified, the example concerns:

• {{convert|10|uPa|Torr}} → 10 micropascals (7.5×10⁻⁸ Torr)
• {{convert|10|uPa|Torr|sigfig=1}} → 10 micropascals (8×10⁻⁸ Torr)

You would like an option to show just 10⁻⁷ as the rounded value. I see the point but I'm afraid that is beyond what convert can manage. Does anyone know of a rounding template that can do this? Johnuniq (talk) 06:57, 2 May 2023 (UTC)

The actual context is: Historically, vacuum levels in production vacuum tubes typically ranged from 10 µPa down to 10 nPa (8×10⁻⁸ Torr down to 8×10⁻¹¹ Torr). It could be SIGFIG=-1, but I didn't try to ask for that. I never looked at the internals of the template, so don't know how hard this is to do. Gah4 (talk) 09:54, 2 May 2023 (UTC)

The first step would be to work out the mathematics for the needed calculation. There may be some method already available. Perhaps someone here or someone at WP:VPT might have an idea. You only need the output number so convert could supply the value (although the format of the number might need adjustment somehow), and another template might round that in the way wanted. No idea, sorry. Johnuniq (talk) 10:57, 2 May 2023 (UTC)

This is going to be more tantalizing than helpful but useful templates would be {{Order of magnitude}} and {{10^}}. For example:

• {{10^|{{Order of magnitude|1.23e-8}}}} → 10⁻⁸

Unfortunately convert has no way of outputting a raw value without formatting. It sounds simple but the code is horrendous as it handles rounding and fractions and other weird things. Johnuniq (talk) 03:35, 3 May 2023 (UTC)

{{10^}} is probably not so bad. I sometimes, (not all that often) change or add sigfig= when needed. In this case, it seemed easy to add, and then surprised me when it didn't work! In case anyone feels like changing it, it could be useful. But I do know about the complications, even though I never actually looked inside. Gah4 (talk) 22:50, 3 May 2023 (UTC)

Litre/liter symbol fix

There is a discussion above but I'm putting this in a new section to make it more visible.

I have updated the sandbox and am looking for opinions on whether anything should be changed before releasing it. Test with {{convert/sandbox}}.

The updates apply the MOS:UNIT recommendation to use L rather than l as the symbol for litre/liter. When an SI prefix is used, convert can output a lowercase l or uppercase L (for example, ml or mL). Examples:

Convert	Output	Notes
{{convert|3.4|l|cuin|abbr=on}}	3.4 L (210 cu in)
{{convert/sandbox|3.4|l|cuin|abbr=on}}	3.4 L (210 cu in)	l is now L
{{convert|16|usgal|abbr=on}}	16 US gal (61 L; 13 imp gal)
{{convert/sandbox|16|usgal|abbr=on}}	16 US gal (61 L; 13 imp gal)
{{convert|16|usoz|abbr=on}}	16 US fl oz (470 ml)
{{convert/sandbox|16|usoz|abbr=on}}	16 US fl oz (470 ml)	usoz default is ml
{{convert|16|usoz|mL|abbr=on}}	16 US fl oz (470 mL)
{{convert/sandbox|16|usoz|mL|abbr=on}}	16 US fl oz (470 mL)	can specify mL

Johnuniq (talk) 08:16, 2 May 2023 (UTC)

The symbol L was adopted by the GCWM in 1979, so it's official. I think this is a good idea for clarity purposes. There doesn't appear to be a conflicting usage. Praemonitus (talk) 15:12, 2 May 2023 (UTC)

Looking good. Hoping that MOS will soon decide to use L, mL, kL, etc for everything but your recent changes are a good step towards that.  Stepho  talk  23:32, 2 May 2023 (UTC)

Based on this sentiment, and the permissiveness of the MOS, my first preference would be to make L the default output not just for the litre but also for all derivative units. This could be overridden by user input for derivative units, so, for example, {{convert|16|usoz|abbr=on}} would produce 16 US fl oz (470 mL) but {{convert|16|usoz|ml|abbr=on}} would produce 16 US fl oz (470 ml). Of course, if this is not adopted, I still support the change as proposed by Johnuniq. Cheers. XAM2175 ^(T) 10:45, 3 May 2023 (UTC)

That's just a matter of changing the default output unit for usoz. I changed all the defaults using l to L. If someone wants to think about Module:Convert/documentation/conversion data#Volume they might recommend also changing ml to mL. Don't bother actually doing that because I have an easy and reliable way of changing the unit data. We just need a decision. MUSgal uses Ml and AUtbsp USdrypt USdryqt USgi USmin USoz USqt USquart UStbsp impgi impoz impqt use ml. Should these default to ML and mL? That would change a lot of articles and given that ml is not wrong I chose to not do it but it would be easy to do. Johnuniq (talk) 23:09, 3 May 2023 (UTC)

If I was king for a day then I would make all defaults as L, mL, etc. But others may not see it that way and give kick back (seeing as ml is still valid). Better to leave the defaults as they are. We can always revisit them later, check to see which way the explicit options are trending (ml vs mL) and change the default to match. Even better when/if MOS makes everything L, mL, etc but my crystal ball is cloudy.  Stepho  talk  00:07, 4 May 2023 (UTC)

I don't see a problem with setting L, mL, ML, etc etc, as the default for everything because that's the most consistent with the MOS and with the recommendations of standards agencies in the US, Canada, Australia, New Zealand, and probably others too. Editors who are strongly committed to the lower-case usage would have the option to explicitly force output of ml and Ml and the like should they wish to use it.

As a compromise position, the "as recommended by standards agencies" argument would be grounds in my mind for setting upper-case output as default on US__ inputs even if imp__ inputs were left with lower-case output as default. XAM2175 ^(T) 11:04, 4 May 2023 (UTC). Struck as poorly-considered given subsequent discussion. 09:42, 5 May 2023 (UTC).

The MOS calls for consistency in an article. So the choice of using "l" or "L" after a prefix should be consistent throughout an article. This is not just a MOS issue; it is the way any careful writer would approach writing an article anywhere. Having a different behaviour when the input to a conversion is a US customary unit, imperial unit, or other unit is making the choice at the wrong level, quantity-by-quantity rather than at the article level. There is no way to make different defaults for different inputs work. Jc3s5h (talk) 13:41, 4 May 2023 (UTC)

I made that suggestion on the assumption, quite possibly unfounded, that most articles would not mix US customary and imperial input units. This consistency argument would appear to support my original proposal – if {{convert}} will always produce L for an output in litres, as the MOS requires, the default symbol for outputs of all derivative units of the litre should also be upper-cased, so that 1) the template's behaviour going forward will be consistent, and 2) the effect on articles already using the template with default outputs will be consistent. Then let editors manually invoke lower-case outputs on a use-by-use basis when they judge it appropriate. XAM2175 ^(T) 16:54, 4 May 2023 (UTC)

Maybe articles that mix units that are different between imperial and US customary are uncommon. But I think it would be common for articles to mix volume units that are the same in both systems (in³ for example) with units that differ (pints, for example). Jc3s5h (talk) 19:23, 4 May 2023 (UTC)

Regarding mixing units within the same article: At litre it says that Fluid ounces are different in the US and imperial (ie, UK and older citizens of the Commonwealth) systems. If I was writing an article that dealt in fluid ounces then I might consider it important to convert to the other fluid ounce as well as to metric. Eg, if I wrote that 5 mL of snake oil additive per litre of fuel would halve your fuel consumption then I would probably convert to fluids ounces per gallon in both imperial and US units. Likewise, if this was US snake oil then I might convert US fluid ounces per US gallon to both mL/L and imperial fluid ounces per imperial gallon. And so on.  Stepho  talk  23:52, 4 May 2023 (UTC)

Thanks, that's a circumstance I'd not considered. I've struck the mixed-behaviour proposal from my earlier reply. XAM2175 ^(T) 09:44, 5 May 2023 (UTC)

Module version 29

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 • same content
• 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 changes:
  • Unit L is unchanged. It accepts SI prefixes and displays uppercase L for the unit symbol with no prefix or when prefixed, for example mL.
  • Unit l also accepts SI prefixes and, as before, displays lowercase l in prefixed symbols such as ml. However, if no prefix is used, uppercase L is displayed as the unit symbol.
  • Units with an output default of l have been changed to use L as the default.

Discussions:

• WT:Manual of Style/Dates and numbers#ENGVAR controls big L or little L for litres/liters?
• Template talk:Convert/Archive 3#Liter
• Template talk:Convert/Archive 3#Litre/liter symbol fix

These changes follow the standard convert procedure of following WP:MOS while allowing editorial judgement to be applied for individual articles. That is, since MOS does not currently rule out ml, neither does convert. Johnuniq (talk) 02:04, 9 May 2023 (UTC)

• This version is now live. Johnuniq (talk) 03:21, 10 May 2023 (UTC)

Miles->kilometers error?

From Bermuda Triangle - "The squadron's flight plan was scheduled to take them due east from Fort Lauderdale for 141 mi (227 km), north for 73 mi (117 km), and then back over a final 140 mi (230 km) leg to complete the exercise."

Obviously it makes no sense that 140 miles should be more kilometers than 141 miles. I checked, and the convert template is used throughout. Hoping there's a quick fix here? DonIago (talk) 00:49, 28 May 2023 (UTC)

@Doniago: the answer is in FAQ #1 at the top of the page. More specifically, 140 miles is considered to be only precise to the 10s digit, while 141 is precise to the ones digit. Thus, convert rounds 140 miles to 230 km by default. If instead the template specified precision to the ones place, it would round the answer to 225 km:

• {{convert|140|mi|km|0}} → 140 miles (225 km)

Imzadi 1979 → 01:09, 28 May 2023 (UTC)

Well, don't I feel like an idiot for not reading thoroughly. :p Thank you! DonIago (talk) 01:12, 28 May 2023 (UTC)

It's to do with the default rounding the template applies. The precision of the output is tied to the precision of the input, but with certain conversions this has the effect of making whole numbers that end with zero – like your 140 miles – convert in a manner that's less precise than might be expected. The behaviour is accepted on the grounds that numbers like that are more often then not being used imprecisely in articles anyway; for instance, it's probably more common that somebody would use a construction like our small town is about 140 miles from the big city then they would I drove exactly 140 miles to visit my family There's more on the topic at Help:Convert § Rounding, but all you need to do is to set {{convert|140|mi|km|0}} so that the template matches the level of precision being used for your conversions of 141 and 73 miles. XAM2175 ^(T) 01:12, 28 May 2023 (UTC)

You were ninja'ed, but thank you too! DonIago (talk) 01:13, 28 May 2023 (UTC)

Proposal: Convert msw ↔ fsw

Such a conversion would be useful in diving.

1 msw → 3.26336 fsw, 1 fsw → 0.30643 msw

What do you think? Alfie↑↓© 12:51, 22 June 2023 (UTC)

This was attempted in March 2017, see Template talk:Convert/Archive March 2017#Additional units: msw, fsw but the units were removed in May 2017 because they were not used, see Template talk:Convert/Archive May 2017#Module version 17. The issue was raised with no feedback at WT:WikiProject Scuba diving#Metres sea water and feet sea water - RfC. A problem with this kind of unit is that there is no global standard and it is unclear exactly what conversion {{convert}} should apply. According to Metre sea water, the US Navy Diving Manual says 1 fsw = 0.30643 msw = 0.44444 psi though elsewhere it states that 33 fsw is 14.7 psi (one atmosphere), which gives 1 fsw ≈ 0.445 psi. See also the first link in this comment with further confusion such as "10 msw would normally be converted to 2 bar (absolute)" and "which used to say that 1 msw = 10.0518 kPa". Perhaps there is no way to sort out the confusion because the values used are very approximate and are different in different places. That is awkward for this template because if the units exist, people will assume the conversions are precise for all contexts. Johnuniq (talk) 09:22, 23 June 2023 (UTC)

THX Johnuniq! I wasn't aware of the previous discussion. My bad. This “elsewhere it states…“ at msw is wrong (just checked my copy of in the Navy Diving Manual). However, msw/fsw (and mfw/ffw) are units of pressure – not depth. Unfortunately in many references about diving they are used as if they are interchangeable. You are right that a conversion to depth would require information about the water's density (dependent on temperature and – if applicable – salinity). Practically impossible. Case closed. Alfie↑↓© 11:53, 23 June 2023 (UTC)

oddly enough i just came here looking for the "MSW" unit for use on DSV_Limiting_Factor. it's not critical, but it'd be nice to have the PSI and kPa conversions inline for easy reference. mcpusc (talk) 18:43, 23 June 2023 (UTC)

The questions raised above need to be resolved and there should be a discussion with some feedback from people in a related wikiproject to show that there is general agreement on what conversion factors should apply and when they do and do not apply. Johnuniq (talk) 03:01, 24 June 2023 (UTC)

Insertion of extra words before number

Is it possible to put additional, user-specified words that are before the number value? I am not talking about words before the units; you can do that with adj=pre or disp=preunit. I also want the parentheses to be retained around the converted quantities, so using disp=x and then putting an opening parenthesis as a separator won't work (because I can't put an ending paranthesis at the end, after the unit).

Example:

<text to be inserted> 2 kilometres (<text to be inserted> 1.2 mi)

This could be useful for adding words such as "about" or "approximately" before the number value (while still using parentheses). Purplemountainman^talk contribs 01:26, 22 July 2023 (UTC)

The options are at Help:Convert#Extra words but it sounds like you are familiar with that. The text-before can be part of normal wikitext before convert and the clumsy disp=x can be used to control the text before and after the output. Is this ok?

prefixed text {{convert|2|km||disp=x| (more text |)}} → prefixed text 2 kilometres (more text 1.2 mi)

Johnuniq (talk) 02:31, 22 July 2023 (UTC)

I think that most readers would understand that "about 2km (1.2 miles)" means that both units are approximate.  Stepho  talk  03:07, 22 July 2023 (UTC)

Agreed, and those that think something is approximately 2 km but exactly 1.2 miles can't really be helped. Johnuniq (talk) 03:20, 22 July 2023 (UTC)

Well, I suspect they can be helped, just not by Wikipedia. EEng 08:01, 22 July 2023 (UTC)

Yes, but in some cases (like in my use case, on this revision of the article Nautical mile, where I want to use the Convert template instead of plain wikitext in the introduction to convert values, the input value has the word "exactly" before it, but the converted value(s) have the word "about" before it), the input value may be exact, but you may need to signify that the converted value(s) are only approximate(s). Purplemountainman^talk contribs 15:06, 22 July 2023 (UTC)

Fair enough.  Stepho  talk  22:29, 22 July 2023 (UTC)

Yes, that would solve my problem. Thanks for the solution! Purplemountainman^talk contribs 14:47, 22 July 2023 (UTC)

Difficult conversion

In Earth's mantle I'm not able to convert this:

10¹⁹ and 10²⁴ Pa·s

I tried with:

{{cvt|1e19|and|1e24|pa·s|lk=on}}-- Carnby (talk) 20:09, 28 July 2023 (UTC)

Pascal seconds (or any units for dynamic viscosity) aren't supported by the template. Which unit were you trying to convert it to, the reyn maybe? You could just do it manually if you want but at those levels of significant figures it's a little bit redundant. --Voello _talk 00:37, 29 July 2023 (UTC)

But as far as 10^x is concerned? How can I use it in the template?-- Carnby (talk) 04:54, 29 July 2023 (UTC)

Big numbers are shown as given:

• {{cvt|1e19|and|1e24|Pa}} → 1×10¹⁹ and 1×10²⁴ Pa (1.5×10¹⁵ and 1.450377×10²⁰ psi)

Engineering multiples upto a billion can be spelled out:

• {{convert|1|e9Pa}} → 1 billion pascals (150,000 psi)
• {{convert|1|e9Pa|e3psi|abbr=unit}} → 1 billion Pa (150 thousand psi)

Johnuniq (talk) 05:25, 29 July 2023 (UTC)

Is there any chance pascal second will be added in the future?-- Carnby (talk) 07:27, 29 July 2023 (UTC)

But what would it convert to? Do reliable sources use another unit? Johnuniq (talk) 08:18, 29 July 2023 (UTC)

Well, just beacuse I find it useful instead of using clumsy , &nbsp; and so on. Don't mind.-- Carnby (talk) 15:18, 30 July 2023 (UTC)

If all you want is some formatting rather than actually converting then perhaps {{val}} will do what you want. Eg {{val|e=19}} [[pascal second|Pa·s]] gives 10¹⁹ Pa·s .  Stepho  talk  21:59, 30 July 2023 (UTC)

K-change

I noticed that K-change yields only °F

{{convert|70|K-change}}

70 K (130 °F)

Is there a way to force the template to yield °C or both?-- Carnby (talk) 17:30, 1 August 2023 (UTC)

{{convert|70|K-change|C-change}} 70 K (70 °C) and {{convert|70|K-change|C-change F-change}} 70 K (70 °C; 130 °F) do the trick. Indefatigable (talk) 17:50, 1 August 2023 (UTC)

Thanks!-- Carnby (talk) 18:09, 1 August 2023 (UTC)

• Wait... are we seriously converting a change in Kelvin degrees to a change in Celsius degrees??? But if so, then shouldn't the above example output not only C-change and F-change, but Rankine change as well? I mean, maybe readers need both F-change and R-change spelled out for them. EEng 01:57, 2 August 2023 (UTC)

Yep I missed it. It would be more sensible something like that:

{{convert|70|K-change|disp=°c}}

yielding

70 K/°C (130 °F)

--Carnby (talk) 05:10, 2 August 2023 (UTC)

What about Rankine? EEng 09:58, 2 August 2023 (UTC)

{{convert|70|K-change|disp=both}}

70 K/°C (130 °F/°R)?--Carnby (talk) 11:24, 2 August 2023 (UTC)

Reminding us once again that there's nothing the {Convert} can't do. It's the EMACS of Wikipedia. I wonder if it can execute Lisp. EEng 00:51, 3 August 2023 (UTC)

international thousands separator should be supported

can we please support internationally standardized thousands separators? examples are thin space (U+2009, international), full stop (U+002E), apostrophe (U+0027), arabic thousands separator (U+066C). instead of value "on" a character could be passed. https://www.compart.com/en/unicode/U+002E may be used to type a character and get is encoding or name. ThurnerRupert (talk) 04:18, 30 July 2023 (UTC)

The comma= options are listed at Help:Convert#Thousands separator. That includes the following example showing that gaps are supported in a way that allows the actual number (without gaps/spaces) to be copied from the displayed text:

• {{convert|1234567|m|ft|comma=gaps}} → 1234567 metres (4050417 ft)

The translate guide outlines the complex details about how convert can be customized for a particular wiki. Module:Convert#Configuration shows how Template:Convert (or another template with a similar name) can be customized with numdot and numsep. However, convert follows the MOS and MOS:DIGITS specifies commas or gaps to group digits. It is less clear about the decimal mark although MOS:MONEY says that $6.57 (with a dot) is correct and that a comma must not be used. Johnuniq (talk) 04:54, 30 July 2023 (UTC)

MOS:DECIMAL seems pretty clear: Use a period/full point (.) as the decimal separator, never a comma: 6.57, not 6,57. Or am I misreading what you wrote, which is a different situation? BilCat (talk) 05:12, 30 July 2023 (UTC)

Thanks, I missed that and it is very clear. Johnuniq (talk) 07:32, 30 July 2023 (UTC)

No worries. BilCat (talk) 08:37, 30 July 2023 (UTC)

what triggers convert to display "meters" with a space and not "m" with a nonbreaking space, vs "ft" with a nonbreaking space, and not "feet"? --ThurnerRupert (talk) 05:47, 3 August 2023 (UTC)

thanks for clarification. manual of style references that {{val}} and {{gaps}} prints the number spaced. copy and pasting does not copy any character, so seems perfect for screen readers. what is the HTML behind this behaviour? ThurnerRupert (talk) 00:24, 1 August 2023 (UTC)

The above 1234567 becomes HTML+CSS as <span style="white-space: nowrap">1<span style="margin-left: 0.25em">234</span><span style="margin-left: 0.25em">567</span></span> It uses CSS to display each thousands group as a small chunk of text with a left hand margin. There is literally nothing between them - just margins.  Stepho  talk  11:43, 1 August 2023 (UTC)

Feature request: respect {Use...English}

Forgive me if this has been brought up. I've searched the archives and I know there has been a lot of discussion of meter vs. metre. Would it be possible or desireable to key the {{Convert}} template's default spelling behavior (when no |sp= is present) from {{Use American English}}, {{Use British English}}, etc. if present in the article? ~Kvng (talk) 21:58, 16 August 2023 (UTC)

In principle, convert could read and parse the wikitext for the entire current page and attempt to determine whether a particular spelling style has been specified. I think some widely used template does that but I can't find it at the moment—and I forget why it parses the whole page. However, I would not recommend kludging Module:Convert to do the same as the duplication, overhead and maintenance burden would be absurd. IMHO there should be a way to have some core data such as spelling style coded into a globally available section of a page that any module could read (not write). However, that is blue sky and I've never seen it even proposed. Johnuniq (talk) 02:24, 17 August 2023 (UTC)

The cite templates can pull information from the {{Use dmy dates}} and {{Use mdy dates}} templates. I have no idea how they do this, nor how much pain it would be to implement here, but Trappist the monk (talk · contribs) may be able to tell you how he did it.  Stepho  talk  10:09, 17 August 2023 (UTC)

Module:Citation/CS1/Configuration which is mw.loadData'd into the main module. Look for get_date_format ().

—Trappist the monk (talk) 10:53, 17 August 2023 (UTC)

I have commented (more accurately, whined) about some modules reading and parsing a whole page in the past. All I can find is this February 2022 similar request regarding {{Birth date and age}}. Johnuniq (talk) 10:55, 17 August 2023 (UTC)

Yep, except that cs1|2 doesn't do any guessing about date format. If there is a {{use xxx dates}} template (or known redirect) cs1|2 extracts that template and is done with the wikitext reading. It is the same for {{CS1 config}}; using the same wikitext, cs1|2 finds and extracts that template to get global configuration settings; page content fetched only once and never 'parsed'.

—Trappist the monk (talk) 11:19, 17 August 2023 (UTC)

{{Use American English}} puts articles in Category:All Wikipedia articles written in American English. Is that of any help in implementing this? ~Kvng (talk) 16:59, 17 August 2023 (UTC)

No, because Lua does not have access to categories and the things that they contain.

—Trappist the monk (talk) 17:14, 17 August 2023 (UTC)

I haven't been able to find the specific discussions yet, but this comes up all the time. The specific purpose of {{Use American English}} is to denote that articles use American English, so from a design perspective, it seems obvious that we should want to be able to respect that in other templates. I think I've heard that there was support for that at some point that was removed; I'd be curious to hear more about why that was and what technical obstacles might be preventing us from bringing it back, @Trappist the monk. But @Kvng's request seems like an obvious improvement that's part of a class of many obvious improvements we should be able to entertain. {{u|Sdkb}} ^talk 15:29, 29 August 2023 (UTC)

Adding support for the Chinese acre

Could supoprt for mu (unit), the Chinese acre, be added? (I encountered it in the lead of Qingpu Prison). {{u|Sdkb}} ^talk 15:17, 29 August 2023 (UTC)

In the article that you linked, the 1915 and 1930 tables give different sizes for the mu. And I'm guessing that pre-1915 its size varied by region and era. Units like this that don't have a single dominant conversion factor can't be handled by this template. Indefatigable (talk) 15:44, 29 August 2023 (UTC)

Ah, I missed that, but you're right. Oh well; that's too bad. {{u|Sdkb}} ^talk 15:56, 29 August 2023 (UTC)

Two conversions

In Malpighia emarginata I wasn't able to use {{cvt}} for two conversions:

• 300–4600 mg/100 g;
• 47 kg/per plant.

Is it possible? -- Carnby (talk) 09:24, 3 September 2023 (UTC)

I can't see an answer for the first one unless you change to mg/g or mg/kg.

For the second one try {{cvt|47|kg|lb|adj=mid|/ plant|0}} to display as 47 kg / plant (104 lb)

or {{cvt|47|kg|lb|0}} / plant to display as 47 kg (104 lb) / plant  Stepho  talk  10:34, 3 September 2023 (UTC)

Likewise, I don't think convert can help with the first one. For the second, my workaround would be "47 kg (104 lb) per plant" on the principle that / is redundant with per. Johnuniq (talk) 10:38, 3 September 2023 (UTC)

Thank you, I worked that way.-- Carnby (talk) 14:31, 3 September 2023 (UTC)

Greater than

Hello, is there a way to use > directly in the template? Or the only way is to use >{{sp}}{{convert}}? -- Carnby (talk) 20:20, 8 September 2023 (UTC)

Not sure what you mean. Can you give an example of what you want the output text to look like?  Stepho  talk  21:32, 8 September 2023 (UTC)

> 50 km/s [110,000 mph; 180,000 km/h] >{{sp}}{{cvt|50|km/s|mph km/h|disp=sqbr}} in electric sail.-- Carnby (talk) 04:09, 9 September 2023 (UTC)

Agreeing with John, that's the best way.  Stepho  talk  04:22, 9 September 2023 (UTC)

The examples at Help:Convert#Extra words show what is possible. If you want text such as > before the input number, you have to put it before the convert. Johnuniq (talk) 23:25, 8 September 2023 (UTC)

Lakh and crore

Would it be possible to add lakh and crore for conversion? I have trouble with the math, and avoid that by linking to the relevant articles (as in the previous sentence). Thanks and all the best, Miniapolis 15:37, 16 September 2023 (UTC)

As far as I can recall, convert supports converting one unit of measure to another, for example 75 feet (23 m). It appears lakh and crore are not units of measure, but rather ways of formatting numbers. These methods of formatting numbers are not usually used in Wikipedia. Jc3s5h (talk) 15:48, 16 September 2023 (UTC)

That is definitely not true; lakh and crore are units. C.f. this news article where the headlines notes that Rs 19 crore have been spent on infrastructure. Orange Suede Sofa (talk) 04:37, 17 September 2023 (UTC)

They are not units in the sense used by convert. For example, in "Rs 19 crore", the unit is Rs and the number is 19 crore which can also be written as 190 million. Johnuniq (talk) 05:08, 17 September 2023 (UTC)

I see; thank you. To simplify things, let's disregard currency and look at text like this— Cities with populations of 1 lakh (100,000) are categorized... where people are counted using lakh. In that case, it sounds like {{lakh}} is the right solution. This might be worth documenting somewhere, because I think that average editors (like myself) might not grasp that distinction, and I definitely disagree with the notion that lakh and crore are not used in the English Wikipedia, per WP:ENGVAR. Orange Suede Sofa (talk) 05:26, 17 September 2023 (UTC)

See MOS:LAKH which states in part

• Sometimes, the variety of English used in an article may suggest the use of a numbering system other than the Western thousands-based system. For example, the Indian numbering system is conventionally used for certain things (especially monetary amounts) in South Asian English. This is discouraged in Wikipedia articles by WP:Manual of Style § Opportunities for commonality.

Jc3s5h (talk) 09:55, 17 September 2023 (UTC)

I've never tried them, but see {{lakh}} and {{crore}}. Johnuniq (talk) 02:20, 17 September 2023 (UTC)

Thanks, Johnuniq (and Jc3s5h and Orange Suede Sofa); I didn't know about the lakh and crore templates, which seem to do what I need. All the best, Miniapolis 13:08, 17 September 2023 (UTC)

mpg order

Does anybody know how I can make ({{convert|17|mpgus|L/100 km mpgimp|abbr=on}} display metric first? Normally I would just add mpgus to the end of the output units and add |order=out but that gives errors. And just adding | does weird stuff with brackets and semicolons. I could simply drop the mpgimp part (tough luck to the Brits) but fairness implies I should drop the mpgus part too and display metric only (tempting, oh so tempting).  Stepho  talk  03:32, 23 September 2023 (UTC)

Try either of the following:

• {{convert|17|mpgus|L/100 km+mpgimp+mpgus|abbr=on|order=out}} → 14 L/100 km (20 mpg_‑imp; 17 mpg_‑US)
• {{convert|17|mpgus|L/100km mpgimp mpgus|abbr=on|order=out}} → 14 L/100 km (20 mpg_‑imp; 17 mpg_‑US)

The error is due to convert's confusion when trying to deal with a unit code that contains a space, as well as spaces used to separate output units. The + tells convert to separate the units at the plus locations, rather than guessing about the spaces. Alternatively, L/100km can be used because it is an alias. Johnuniq (talk) 05:34, 23 September 2023 (UTC)

Excellent. L/100km worked a treat at Lexus GX. Thanks.  Stepho  talk  07:45, 23 September 2023 (UTC)

Request: semicolon as separator option

There are times when I want to avoid nested parentheses, but I don't want to use disp=or. I notice that when one specifies multiple output units, a semicolon is used. I would like to be able to select a semicolon as my separator, without additional parentheses, allowing for something like: (10° C; 50° F), without having to resort to disp=x gymnastics. That seems much better to me than using a comma. Thanks! 1980fast (talk) 23:36, 6 October 2023 (UTC)

Try |disp=semicolon. Eg: {{cvt|10|C|disp=semicolon|0}} → 10 °C; 50 °F  Stepho  talk  01:20, 7 October 2023 (UTC)

Thanks, that worked! It never dawned on me to try that because disp=semicolon does not appear in the documentation, nor does it appear among the options listed in the Visual Editor interface.

I hereby request that it be added to the documentation, and (if possible) the Visual Editor. Is it a separate team that works on the Visual Editor UI? 1980fast (talk) 17:37, 7 October 2023 (UTC)

Done. Johnuniq (talk) 00:22, 8 October 2023 (UTC)

Thank you! 1980fast (talk) 05:08, 9 October 2023 (UTC)

Change the converted result to show SI/metric units first, since it's the most widely used (or specific unit first for specific use cases (like nautical miles/knots in aviation and shipping))

Often when reading articles they'll be missing metric units (fx. Flammable liquid which I just edited to include ºC for all ºF temperatures) or they'll have the temp. stated in ºF and ºC in a parenthesis (often using this converter). Since most of the world (including USA when doing science) uses the metric system, it seems odd to me that metric units aren't presented first with the less common unit stated in parenthesis. This would make it more understandable for most people.

A bot for auto-conversions would also make sense, since most people around the world (me included) have no reference for what temperatures in ºF means.

Thank you. S4a4 (talk) 15:53, 9 October 2023 (UTC)

• See MOS:UNITS. Making it so SI units always first isn't feasible, but I suspect that that particular article should do it that way. EEng 16:11, 9 October 2023 (UTC)

Read and obey MOS:UNIT. People have been banned from Wikipedia for engaging in campaigns to change articles to their favored spelling/units/era notation etc. Jc3s5h (talk) 16:12, 9 October 2023 (UTC)

Adj=on while rounding input

Is there any way to round the input number while also having the adjective on? My goal is this output: 1.8-litre (1,798 cc; 107.9 cu in). I was hoping that {{convert|1.798|L|cc cuin|adj=ri1|adj=on}} but two adj= fields won't work. Thanks,  Mr.choppers | ✎  14:41, 10 October 2023 (UTC)

{{convert|1798|cc|L cc cuin|1|adj=on|order=out}} gives 1.8-litre (1,798 cc; 109.7 cu in)

Although I question the need to display both L and cc since they are trivially calculable from each other.  Stepho  talk  22:06, 10 October 2023 (UTC)

Million tonnes per annum

How do I represent million tonnes per annum (Mtpa)? It's come up on Cobre mine, Panama and seems to be used for natural gas, ore and other extractive industries. Lordgilman (talk) 18:55, 28 November 2023 (UTC)

{{cvt|85|t/years|ST/years|disp=preunit|M|M }} → 85 Mt/yr (94 M short ton/yr)

{{cvt|85|t/yr|ST/yr|disp=preunit|M|M }} → 85 Mt/a (94 M short ton/a)

Not sure how useful that is.  Stepho  talk  21:54, 28 November 2023 (UTC)

fps

I have, literally, hundreds of physics and engineering texts, and not one of them uses the unit "foot/s". They may spell it out as "feet per second", but only to explain the meaning of the unit they will use, "fps" or "ft/s", the majority being the former. Yes, I'm perfectly aware of the overlap for "frames per second", but is there no way to have an alternative format for these situations? Maury Markowitz (talk) 13:23, 5 December 2023 (UTC)

Convert has a long history and tries to accommodate significant usage differences. There is no unit with fps or with feet/s. What works are unit codes foot/s (plural name is foot per second) and ft/s (plural name is feet per second) so both flavors are handled. If you want the symbol and not the name, use abbr=on. If there is still a problem, please post a link to an article and an example convert. Johnuniq (talk) 00:52, 6 December 2023 (UTC)

disp=tableleft please

Needed for List of tallest buildings

The table lists numbers with or without a decimal, but always have three digits before (luckily). Best bodge right now is disp=tablecen but tableleft would be more elegant. Wizmut (talk) 04:24, 2 January 2024 (UTC)

A possible solution is to always provide the same number of digits for each line.

Eg, replace {{cvt|828|m|disp=tablecen}} with {{cvt|828.0|m|disp=table|0}} . Notice the ".0" and also the "|0" added. Changing "tablecen" to just "table" is optional. Stepho  talk  05:03, 2 January 2024 (UTC)

Could work for now. The MoS seems to be okay with it: Wikipedia:Manual_of_Style/Dates_and_numbers

The number of decimal places should be consistent within a list or context (The response rates were 41.0 and 47.4 percent, respectively, not 41 and 47.4 percent), unless different precisions are actually intended.

Wizmut (talk) 05:14, 2 January 2024 (UTC)

Is disp=tableleft needed or something like disp=tabledef which would use the alignment default (left) and not output any alignment style? For completeness, I'll mention Template talk:Convert/Archive 3#Decimal-point alignment for disp=table? where {{0}} was mentioned as a good way to align numbers. Johnuniq (talk) 08:26, 2 January 2024 (UTC)

Yes, I wanted finer control over alignment without putting {left} and {right} tags everywhere, necessary because of all the rowspan tags. Really wish those rowspans made hidden blank cells, they break {table alignment}. Wizmut (talk) 12:24, 2 January 2024 (UTC)

Dropping the number one?

This is pretty minor, but is there any way to drop the "one" for cases such as "meter-long cake" or "foot-long sandwich" where the "one" is not idiomatic? I intended to edit the "thousand-acre (4 km²) farm" seen here. Thanks. —  AjaxSmack  02:06, 11 January 2024 (UTC)

Somewhere in the archives I recall something that could be used around a convert to use (I think) "a" or "an" instead of "1". I don't know if it would drop 1 altogether. At any rate, it's cheating but the usual way of dealing with your issue is as follows:

• thousand-acre ({{convert|1000|acre|km2|0|disp=out}}) → thousand-acre (4 km²)

Johnuniq (talk) 02:35, 11 January 2024 (UTC)

Thanks. —  AjaxSmack  17:55, 14 January 2024 (UTC)

Discussion at Wikipedia:Village pump (technical) § Let's make Template:convert go away.

 You are invited to join the discussion at Wikipedia:Village pump (technical) § Let's make Template:convert go away.. –Novem Linguae (talk) 07:37, 15 January 2024 (UTC)

Thanks for the heads up. Seems like a solid WP:SNOWBALL, but nonetheless.  Mr.choppers | ✎  21:31, 15 January 2024 (UTC)

Decibels

Would it be useful to add (deci)bels? And/or normalized sound units like dB(A)? Doesn't look like this supports them unless I'm missing something. Actually ran into this while poking at {{val}}. Slowking Man (talk) 01:09, 29 January 2024 (UTC)

The decibel units are a mystery to most people. I don't know of anything useful they could be converted to. Johnuniq (talk) 05:36, 29 January 2024 (UTC)

Plain dB is probably not that useful, but there are ones like dBm, which is a power unit, dB relative to 1 milliwatt. It would need to know how to do log conversions, though. Gah4 (talk) 21:39, 20 February 2024 (UTC)

Bogus unit "kiloare"

The code "ka" is supposed to give "kiloannum" or "millennium", but on a few pages like Ojos del Salado it gives "kiloare". Jo-Jo Eumerus (talk) 16:16, 24 January 2024 (UTC)

NIST Special Publication 811 in the conversion tables does list "a" as a symbol for are. In this article, providing a conversion to a mixed unit, cubic miles per are, seems wrong. I think it would be better to just not give conversions. Jc3s5h (talk) 17:03, 24 January 2024 (UTC)

Problem is that even as a legitimate unit, "ka" is already specified as "kiloannum" or "millennium" in the code so it should be converted to that and not "kiloare". Jo-Jo Eumerus (talk) 07:54, 25 January 2024 (UTC)

Kiloare (10 hectares) is not a bogus unit, although I've never seen it used. Hawkeye7 (discuss) 23:05, 24 January 2024 (UTC)

At https://iopscience.iop.org/article/10.1088/1681-7575/ac979f it nicely describes "the unit are, symbol a (for 100 m2) and the hectare, symbol ha (for 10 000 m2)". Later it mentions "centiare, ca (equal to 1 m2) or kiloare, ka (equal to 105 m2)". Personally, I have only ever seen hectare in the real world.

Similarly, I've never seen kiloannum in the real world but some web searching shows it being used on geology sites to mean millennium.  Stepho  talk  23:18, 24 January 2024 (UTC)

The second quote given by Stepho-wrs (talk · contribs) should be "centiare, ca (equal to 1 m² or kiloare, ka (equal to 10⁵ m²)." The author indicates the meaning of prefixed versions of the are are ambiguous, and the qoute given is one of four possible options. The author's recommendation is to add the hectare to the list of non-SI units with which SI prefixes may not be used, on the grounds that the are and multiples of that are rarely used, other than the hectare.Jc3s5h (talk) 02:39, 25 January 2024 (UTC)

I remember seeing kilohectares when a very large estate was described (presumably by someone who thought in acres). But at that level, square kilometer is more likely to be used. Tarl N. (discuss) 08:23, 25 January 2024 (UTC)

Example of such usage: Fuel characteristics and emissions from biomass burning and land-use change in Nigeria. Tarl N. (discuss) 08:29, 25 January 2024 (UTC)

Hawkeye7, it may not be exactly 'bogus', but it doesn't exist and is never used – it would have a side of 100√10 m, not a decimal measurement. The are is a measure of area, so possible/useable prefixes are in multiples of 100, not 10. Hectare, are, and centiare are used in cadastral measurement where I live; the next-largest (100 times greater) unit after the hectare would be the "myria-are" – more commonly known as the square kilometre. Justlettersandnumbers (talk) 21:24, 20 February 2024 (UTC)

Ping fail, sorry, missed the 7, Hawkeye7. Justlettersandnumbers (talk) 21:27, 20 February 2024 (UTC)

A possible improvement for the article would be to use one of the following which keeps the original input but does not display it:

• {{convert|0.03|-|0.04|km3/ka|km3/km2 mi3/mi2|order=out}} → 0.30–0.40 cubic kilometres per square kilometre (0.19–0.25 cu mi/sq mi)
• {{convert|0.03|-|0.04|km3/ka|km3/km2 mi3/mi2|abbr=on|order=out}} → 0.30–0.40 km³/km² (0.19–0.25 cu mi/sq mi)

Johnuniq (talk) 00:46, 26 January 2024 (UTC)

No, because it's supposed to be kiloyear (->time) not kiloare (-> area). Jo-Jo Eumerus (talk) 16:33, 20 February 2024 (UTC)

I think the convert template has gotten out of control. I don't know what {{convert|0.03|-|0.04|km3/ka|km3/km2 mi3/mi2|order=out}} means, and I refuse to learn.

One of the purposes of the template is to eliminate the need for editors to look up conversion factors and calculate the conversion with a calculator. But in the case of this monstrosity, one would have to look up the conversion factors, calculate the conversion, and then try the convert template in a sandbox to see if the syntax is right and if indeed the template is right. This last step would probably take several tries. So using the template would be about five times harder than a manual calculation. Jc3s5h (talk) 16:33, 28 February 2024 (UTC)

Messy output for ranges mixing positive and negative values

In the Climate section for Pasadena, California, one can see the following text, which immediately struck me as difficult to read:

"...with the occasional reading in the 30s (−1–4 °C)."

The underlying conversion (which was not my work) is {{convert|30|-|39|F|C|disp=out}}

Shouldn't there be some sort of non-breaking space, or a spaced en dash? I suppose it could be reformatted to use "to", although that seems like it would be much less compact when compared to a simple spacing tweak, not to mention inelegant, having to reformat neighboring conversions (that otherwise look just fine) for the sake of consistency.

I'm not sure what the best approach is for this situation. Thanks! 1980fast (talk) 20:13, 27 January 2024 (UTC)

I don't think there is a good workaround other than using "to". The problem with that are the adjacent converts which use the same procedure but work with a dash. Johnuniq (talk) 00:57, 28 January 2024 (UTC)

Thanks! If anyone would know, it would be you. :) I will use "to" and not worry about it. 1980fast (talk) 03:46, 30 January 2024 (UTC)

I feel like this is a general range which is then converted with too much precision. I recommend writing ...with the occasional reading in the 30s (below 5 °C). instead, to convey the correct meaning. I like conversion templates as much as anyone here (except Johnuniq, perhaps), but there are times when they ought not to be used.  Mr.choppers | ✎  17:22, 28 February 2024 (UTC)

Typo in documentation?

There is a line that says:

"Remember that the spelling of the units (ft, m) is independently set by |abbr=."

Shouldn't that be:

"Remember that the spelling of the units (ft, m) is independently set by |sp=." ? 1980fast (talk) 22:25, 10 February 2024 (UTC)

That was added on 17 August 2014. Perhaps convert did not set abbr=on when spelling numbers at that time, so abbr=off would have made a difference? I could check that but it would take a while. Unless someone can think of what might have been intended, the simplest would be to delete the two lines. Johnuniq (talk) 02:49, 11 February 2024 (UTC)

I removed the old text at Template:Convert#Spell out numbers: ten miles so that is done. Johnuniq (talk) 02:19, 29 February 2024 (UTC)

Another mass unit

As British designations for truck/lorry capacities were often in hundredweight (cwt), could that be added as a unit? GraemeLeggett (talk) 09:51, 3 March 2024 (UTC)

Already there. {{convert|30|Lcwt|lb kg}} 30 long hundredweight (3,400 lb; 1,500 kg) -- WOSlinker (talk) 10:17, 3 March 2024 (UTC)

Thanks, couldn't see it in list, think I must have followed link to old documentation. Though doesn't seem to abbreviate {{convert|15|Lcwt|kg|abbr=on}} giving 15 long hundredweight (760 kg) rather than 15 cwt (660760 kg). GraemeLeggett (talk) 21:31, 3 March 2024 (UTC)

The full list at Module:Convert/documentation/conversion data#Mass includes -Lcwt and -Scwt (long and short hundredweight). The dash indicates that the unit is intended to be "internal", that is, used by convert for something involving cwt. Both these have cwt as the symbol and you can use them if really desirable. The point is that there is a difference between long and short and that is why it is included in the standard unit. Johnuniq (talk) 02:10, 4 March 2024 (UTC)

Fractional person?

Can this syntax be improved to avoid a fractional person?

• {{convert|10|/m2|/ft2|spell=in|adj=pre|people}} (produces ten people per square metre (0.93/sq ft) )

Perhaps an option order=invert so that it produces 1.1 sqft/person? 𝕁𝕄𝔽 (talk) 20:47, 3 March 2024 (UTC)

In general there is nothing wrong, on the average, with a fractional person. That one is wrong because of SigFigs, not because of fractional persons. It should round to 1, and 10 has one significant digit. ten people per square metre (one per square foot) rounds to 1, which is probably about right. Also with spell=on so both get spelled out. (Seems fair to me.) Gah4 (talk) 00:34, 4 March 2024 (UTC)

Brothers and sisters! We should be uniting people, not dividing them! EEng 00:36, 4 March 2024 (UTC)

Yes, let us not be fractious. Hawkeye7 (discuss) 02:33, 4 March 2024 (UTC)

Did you mean facetious?

In this case, the issue can be ducked by using rounding but the general issue remains. 𝕁𝕄𝔽 (talk) 09:04, 4 March 2024 (UTC)

What general issue? EEng 13:06, 4 March 2024 (UTC)

Bug report: error in converting liters to US fl oz

The tool reports incorrect values:

4.0 litres (140 imp fl oz; 140 US fl oz)

This should be 135 US fl oz.

A conversion from 4 should be less than 4.05:

4.05 litres (143 imp fl oz; 137 US fl oz)

I'm not sure where else to report this. kslays (talk • contribs) 09:36, 7 March 2024 (UTC)

That is unfortunate but it happens because convert is guessing the number of significant figures in the input value. Convert does a good job most of the time but it fails in situations like this and the only cure is to specify the wanted precision. That is most easily done with a number that specifies the number of fractional digits after rounding, but sigfig and round are also options: see the rounding documentation on the template page and the first question in the FAQ at the top of this page. Johnuniq (talk) 10:29, 7 March 2024 (UTC)

That's very helpful, thanks. I was able to fix the article I was working on with sigfig, since I don't think round accepts a value to round to whole numbers. kslays (talk • contribs) 21:13, 7 March 2024 (UTC)

• Too late now, but in retrospect a better design would have been to require specification of sigfigs or something. The guessing / default just causes too many headaches. EEng 22:02, 7 March 2024 (UTC)

Unitless numbers; %, ‰, ppm, ppb, etc.

I'd like to add unitless scales (%, ppm, ppb, etc.). Mostly this would be for thermal expansion coefficients. Sometimes people write "10.5 μin/(in⋅°F)", and I'd like to be able to convert it to

• "18.9 ppm/°C" (preferentially)
• "18.9 × 10⁻⁶/°C"
• "18.9 μm/(m⋅°C)".

The latter one is actually pretty straightforward to add, I think. But the 1st two outputs don't seem possible at the moment. From what I can tell, {{convert}} needs an input unit and an output unit. Unit cancellation doesn't seem to be able to produce (or even consume) unitless values.

How can I specify 'ppm', 'ppb', etc., as unitless scale values (i.e., essentially equal to 10⁻⁶, 10⁻⁹, ...)?  — sbb (talk) 20:13, 24 March 2024 (UTC)

The trick is to think in terms of what convert does know - in this case it's the /F and /C. The rest is just ornamentation.

{{cvt|10.5|/F|/C||adj=pre|ppm|disp=preunit|ppm}} → 10.5 ppm/°F (18.9 ppm/°C)

{{cvt|10.5|/F|/C||adj=pre|ppm|disp=preunit|× 10<sup>−6</sup>}} → 10.5 ppm/°F (18.9 × 10⁻⁶/°C)

Not sure how to do the last one.  Stepho  talk  23:14, 24 March 2024 (UTC)