Template talk:Convert

Template:Convert

... in conception

... and in reality

Feature request: Default rounding, but never reduce sigfigs

Template:Infobox firearm cartridge currently defaults to the default rounding behavior of Template:convert. With cartridge dimensions it behaves adequately when converting from mm to inches, but it has the bad habit of turning 3-sigfig inch dimensions (.300) into 2-sigfig mm dimensions (7.6), which is not exactly customary (7.62). I would like to have a switch to enable a modification of "comparable precision" rule that never allows a reduction in the number of sigfigs. Artoria2e5 🌉 13:40, 28 April 2025 (UTC)

Alright, I think I have a bit of an XY problem here. On second thought the issue might not be in the reduction of sig figs, but the threshold used for "comparable precision". Why was "2" picked? Why not something closer to the square root of 10, like "3"? That would avoid this particular problem. --Artoria2e5 🌉 13:49, 28 April 2025 (UTC)

mpg-us

Is it right?

0.8 mpg_‑US (290 L/100 km; 0.96 mpg_‑imp)

290 L/100 km?-- Carnby (talk) 09:11, 4 May 2025 (UTC)

I can't easily investigate at the moment but this is likely to be a rounding problem. See the FAQ at the top of this page. Johnuniq (talk) 09:18, 4 May 2025 (UTC)

{{cvt|0.8|mpgus|km/L L/km L/100km|3}} -> 0.8 mpg_‑US (0.340 km/L; 2.940 L/km; 294.018 L/100 km)

It's approximately right. 0.8 mpg-imp is 0.340 km/L

0.340 km/L is 2.940 L/km (on your calculator press the 1/n button)

2.940 L/km is 294.018 L/100 km

So, 290 L/100km is correct to 2 digits. Add |3 for 3 digit precision.  Stepho  talk  09:31, 4 May 2025 (UTC)

I see you got there before me. LoL Dondervogel 2 (talk) 09:33, 4 May 2025 (UTC)

0.96 miles per gallon converts to 0.34 km/L or 2.94 L/km. That's 294 litres per 100 km, which is rounded to 290 L/(100 km). Where is the problem? Dondervogel 2 (talk) 09:32, 4 May 2025 (UTC)

Yep, I'm a fully paid up member of anoraks-R-us. ;)  Stepho  talk  09:38, 4 May 2025 (UTC)

@Dondervogel 2 I probably asked it the wrong way. In daylight running lamp there's

{{cvt|0.5|mpgus|L/100km mpgus mpgimp|order=out}}

yielding:

Fuel consumption reductions of up to 470 L/100 km (0.5 mpg_‑US; 0.60 mpg_‑imp).-- Carnby (talk) 11:54, 4 May 2025 (UTC)

The problem is quite simple: In the US, a length over volume metric is used, whereas in (most of) Europe, it's volume over length, i.e., the inverse. This means that the delta between two miles per gallon figures (say, we got 50 miles per gallon and 60 miles per gallon → Delta = 10 miles per gallon) cannot be converted into a L/100 km delta (and also not the other way around) using the template. The convert template works correctly – it's just that the source information is "dumb" and that whoever cited the source failed to understand it. The source assumes a typical fuel consumption in a certain range (e.g., 40–45 miles per gallon). Its information is only sensible if the average fuel consumption is within that range. It stops making sense as soon as cars become more (or less) fuel efficient. To illustrate the point, let's pretend a fuel consumption figure of 1 mile per gallon, i.e. 282.5 L/100 km. Increasing the "fuel efficiency" by .5 miles to 1.5 miles per gallon yields 188.3 L/100 km, a reduction of 94.2 L/100 km. Any 15-year old, low cdA large family passenger car can do 80 miles per gallon (3.53 L/100 km). Increasing this to 80.5 miles per gallon results in 3.51 L/100 km, which is negligible. Since the source dates back to 1998, prior to the advent of the passenger car CR Turbodiesel, I reckon it's safe to assume that its information is no longer valid, and that the claim should be removed from the article. Best, --Johannes (Talk) (Contribs) (Articles) 13:01, 4 May 2025 (UTC)

Looks like it would make more sense to find a reference that states a "xx percent increase in gas mileage".  Mr.choppers | ✎  16:19, 4 May 2025 (UTC)

Perhaps also: {{cvt|0.5|mpgus|km/L mpgus mpgimp|order=out}}

yielding:

Fuel consumption reductions of up to 0.21 km/L (0.5 mpg_‑US; 0.60 mpg_‑imp--Carnby (talk) 03:43, 5 May 2025 (UTC)

Like Johannes and Mr Choppers said, its really a proportional thing.

0.5 mpg improvement out of 40 mpg is about 1.25%.
But 0.5 mpg improvement out of 20 mpg is about 2.5%.
And 0.5 mpg improvement out of 10 mpg is about 5%.

Without knowing the original range then the 0.5 number is essentially meaningless.

If we knew that the original vehicle was about 40 mpg then 0.5 improvement is 1.25% .
Applied to newer cars of about 5 mpg we get 5 mpg x (1.25/100) = 0.0625 mpg improvement.
Which is peanuts but still 1.25% improvement.  Stepho  talk  04:52, 5 May 2025 (UTC)

@Carnby: What is the precise (verbatim) wording from the original source? Dondervogel 2 (talk) 07:29, 5 May 2025 (UTC)

I was not able to find it in the linked document. Johannes was right, the claim must be removed.-- Carnby (talk) 11:06, 5 May 2025 (UTC)

On page 42357 I read "Additional, nonsafety benefits are that turn signal DRLs offer a fuel economy benefit of up to 0.5 m.p.g. compared to headlamp DRLs (according to 1990 test data), lower cost of replacement bulbs (compared with replacement costs for headlamps or headlamp bulbs), and lower costs than the reduced intensity lower beam headlamp according to the 1995 Economic Evaluation of DRLs performed by Transport Canada.". I think it's OK to convert 0.5 mpg to 0.2 km/L (though not to 500 L/(100 km)). Dondervogel 2 (talk) 11:37, 5 May 2025 (UTC)

 Done-- Carnby (talk) 12:52, 5 May 2025 (UTC)

Visual editor: "precision OR suffix"?

When you are doing a conversion, what if you need to specify precision AND have a suffix (due to adj=mid)?

If there's a way to do it, the visual editor doesn't make it obvious, and I'm not sure how to do it in wikitext, either. I don't know why these options should be mutually exclusive.

Thanks! 1980fast (talk) 20:47, 20 May 2025 (UTC)

I don't use the visual editor, so I won't comment on that. But in wikitext the precision and adj forms are not linked in any way.

Eg: use the |3 option for 3 digit precision {{convert|10|mi|km|adj=on|3}} displays as 10-mile (16.093 km)  Stepho  talk  23:59, 20 May 2025 (UTC)

Or, for adj=mid:

• {{convert|10|mi|km|long|3|adj=mid}} → 10-mile long (16.093 km)
• {{convert|10|mi||long|3|adj=mid}} → 10-mile long (16.093 km)

You can even use this (not recommended):

• {{convert|10|mi|3|long|adj=mid}} → 10-mile long (16.093 km)

Johnuniq (talk) 10:48, 21 May 2025 (UTC)

Mu, or 'Chinese acres'

For this conversion, see provisional template {{Convert mu}}. Thanks, Mathglot (talk) 06:47, 26 May 2025 (UTC)

From Mu (land), "One mu equals 666.67 square meters in mainland China, 761.4 square meters in Hong Kong and Macau, and 99.17 square meters in Taiwan and Japan." So there needs to be something to choose between the 3 values. Or at least to be very clear in the documentation that only a specific one is supported - although I see endless issues with people doing a conversion with the wrong one in mind.  Stepho  talk  06:57, 26 May 2025 (UTC)

Thank you, already handled in the doc. I am examining the usage in articles here, and have not so far encountered any cases of the non-Chinese version, but haven't looked at all of them. As the provisional template is slated to disappear when the module is updated, I don't currently see a reason to update the template to add variants which are edge cases (or non-existent cases) that may never be used. If someone turns up some actual cases of them, then I will. The variants could (and probably should) be added to the module when the template function is merged, with the Chinese one being the default, and maybe different unit specifiers for the others, e.g., hkmu, twmu, jpmu, etc. Thanks, Mathglot (talk) 19:11, 26 May 2025 (UTC)

Or better the other way round, i.e.: muzh, mutw, mujp, and mu, the last being an alias of muzh. Mathglot (talk) 23:56, 27 May 2025 (UTC)

Maybe with a separator, e.g. "mu-zh" or "mu_zh"? Or even "mu (zh)"? I first read "muzh" as a single word. — Chrisahn (talk) 00:21, 28 May 2025 (UTC)

Those are details that the module writer regulars can work out to remain consistent with existing usage. Mathglot (talk) 00:38, 28 May 2025 (UTC)

Can confirm that "mu" is commonly used in contemporary zh_CN and rarer in (a limited selection of) zh_TW and zh_HK that I have seen. Traditional units like Jin (catty) and Mu generally have a bit more use in China than in other places due to the Chinese "market units" definition having relatively simple SI conversion factors. Artoria2e5 🌉 16:35, 29 May 2025 (UTC)

Artoria2e5, that is really useful, thanks. Your comment led me to try an advanced search which finds these eleven articles which use catty. (That's a lower bound, because Cirrus search is weird. For example, that search link should turn up Clyde Terrace Market as well, but it doesn't; don't ask me why.) Do you think catty (and/or jin) should be added to the module as well? As a side issue: I've raised a possible merge issue at Talk:Catty. Thanks, Mathglot (talk) 23:10, 29 May 2025 (UTC)

Meta collapsed

Redaction notice: At this point in the discussion (see this edit of 23:10, 27 May 2025) several images were removed from this section which may have been encumbering the discussion. (It is easier to follow the flow, now.) As the removed content had already been responded to below, this left the discussion in an incoherent state (see TPO). Adding this redaction notice on behalf of User:Chrisahn to restore a coherent narrative. Thanks, Mathglot (talk) 00:36, 28 May 2025 (UTC) (edit conflict) Off-topic discussion regarding redaction I feel that this redaction notice only adds to the confusion. Can we delete it? Your note at the end is fine and sufficient, isn't it? When I deleted the images, I just wanted to keep the discussion on topic and easily readable, but now it's gone meta and off topic again... — Chrisahn (talk) 00:55, 28 May 2025 (UTC) It is meta and it is off-topic, so I am collapsing this, per TPO. I would have had no problem with the image removal had it been accompanied by an explanation despite the TPO issue involved, and it all would have been fine with no follow-up comment necessary by me or anyone else if you had explained your original image removal edit in the discussion itself, instead of only in the edit summary. I realize you were only trying to help, but the way it was left after your edit made it worse for third-party readers of this discussion due to follow-up already in the discussion referring to things higher up that were not there. The redaction notice was an attempt to remedy that, and imho should not be removed to avoid reintroducing the confusion. This is kind of why the WP:TPO guideline exists in the first place, to avoid getting into a confusing situation like this. Asking for removal of the images would have avoided the confusion, and even removing it yourself contra TPO and saying why you were doing it inline in the text would have also avoided it, but you chose silent removal, which unfortunately kicked off the confusion. So at this point, sorry, no, I don't think the redaction notice should be removed. As far as where to at this point, I'm happy with the status quo and don't really have anything else to add, but as you said, this side-discussion is meta and it is off-topic, so if you want to discuss further, may I suggest we pick a different venue? Mathglot (talk) 01:30, 28 May 2025 (UTC) Have it your way; collapsed the edit notice, and everything else that isn't about the template. Better now? Mathglot (talk) 17:23, 28 May 2025 (UTC) Circling back: just to be clear to any and all users, despite an occasional digression into sanity-protecting hilarity or what to some will perhaps see as a mysterious sidetrack or editors having lost their senses, there is a serious core here about adopting a new land area unit into the module, and your feedback is welcome.

Regarding the provisional template {{convert mu}}, it was designed to mimic param names and behavior of {{convert}}, so that after the new unit is added to the module, conversion of articles using the new template is trivial, by simply dropping the 'mu' in the name. That is: currently, we have:

• {{convert mu|47,531|mu|ha|lk=in|sf=3}} → 47,531 mu (3,170 hectares)

with equivalent positional params, and three available equivalent named params (two shown in the example). To convert it after the module is updated, just change {{convert mu| to {{convert| and it will just work. Mathglot (talk) 18:41, 27 May 2025 (UTC)

Off-topic distraction about off-topicness

Note: redacted a portion of my previous comment which no longer makes sense after images previously present in this section were removed. Mathglot (talk) 00:47, 28 May 2025 (UTC) A monk asked Master Chao-chou, "Has the discussion about the removal of images from the discussion about mu the Buddha-nature or not?" Chao-chou said, "Mu!" — Chrisahn (talk) 07:43, 28 May 2025 (UTC) To restore this discussion to a Zen-like state of clarity and focus, everything off-topic should be removed. Clear your mind! Remove the images and all mentions of them. Remove this very comment first. If you feel the need to punish me for violating WP:TPO, please go ahead and do so. Slap me with a trout. Report me at ANI. Whatever. Jo Joza asked Rinzai, “What is the essence of a talk page?” Rinzai, getting up from his seat, seized him, slapped him, and pushed him away. Jo Joza stood still. A monk standing by said, “ Jo Joza, why don’t you bow?” When Jo Joza bowed, he suddenly became enlightened. Once that's done, let's help this discussion achieve its Buddha-nature. Let's remove all the false idols, the images, and any mention of them. The meta-discussion. The redaction notice. Even the half sentence mentioning the occasional digression into sanity. Let's throw out all the garbage, the distractions, and focus on our true purpose: to achieve enlightenment about the true nature of Mu and how to convert it to square meters. — Chrisahn (talk) 08:00, 28 May 2025 (UTC) And I really mean delete. Don't just strike it or hide it. Remove it. The great mind of Wikipedia will remember the images and the discussion about them forever, and true disciples of Mu will be able to find them if necessary. But the uninitiated who simply want to discuss a somewhat obscure unit of area measurement will be best served if all of this nonsense, e.g. this comment, is simply condemned to history. — Chrisahn (talk) 08:05, 28 May 2025 (UTC) That was truly not helpful. In a last attempt to keep this on track, everything that isn't about the template is collapsed; hopefully we can just get on with it. Mathglot (talk) 17:23, 28 May 2025 (UTC) Wikipedia at its best. EEng 20:09, 28 May 2025 (UTC)

Not sure if I should formalize it with an edit request, or add it to a list of new units to be considered next time someone updates the module? Thanks, Mathglot (talk) 17:23, 28 May 2025 (UTC)

Previous discussions were: April 2017 + August 2022 + August 2023. As mentioned in these discussions and above, there is no standard definition for mu—it's value apparently varies with time and location. Adding a unit to convert gives it an official status and people will assume that convert magically works. That's unwise when a unit has no standard meaning. A problem with convert is that it is hard (apart from relying on dubious searches) to find where a unit is used to check if the usage is correct. At any rate, what is the proposal? A unit needs a code (what goes in the template), a symbol (abbr=on), a name (abbr=off), a link (link=on), and a scale (number of square meters in a mu). See Module:Convert/extra for adding a new unit for testing. Johnuniq (talk) 03:09, 30 May 2025 (UTC)

Thanks. The specific proposal is this:

["mu"] = {
  _name1   = "mu",
  _symbol  = "mu",
  utype    = "area",
  scale    = 0.06666666,
  prefixes = 1,
  default  = "ha",
  link     = "Mu (land)",
},
["mu-zh"] = {
  target = "mu",
}

Note that this definition defaults to number of hectares in a mu (1/15), not sq meters. I presume that is permissible? This seems to be the more usual conversion unit when referring to land (the majority of cases), although m² is seen more often with buildings. I take the point about uncertainty of units by location, and this was addressed above by Artoria2e5. Searching for uses of mu in articles yields results that seem to correspond to the mu unit. Two other units are well-defined, and I would call those mu-hk and mu-vn if any article uses them (so far, I have not seen any) and then differentiate the Chinese one by targeting from mu-zh. I have probably looked at about 1/3 to 1/2 of the cases from that Cirrus link, roughly these, but the true number is likely larger due to the restrictive search query designed to avoid excessive false positives.

The main question seems to be whether it is appropriate to add a unit that has different meanings in different places, and I can't answer that. But it seems to me to be more of a difference in degree rather than kind, as we have "acres" and "Irish acres", "tonnes" and "tons", and so on. Is it always certain which ton or acre is being used in sources cited in an article? No doubt there are some tricky cases with Irish emigrants to Australia, but Irish farmers in Ireland are presumably using Irish acres, even when the sources do not explicitly say so, and by the same token, it seems that we can say Chinese farmers in China can be presumed to be using Chinese mu, unless there is some reason to challenge that (like maybe a returning ex-pat Chinese-Vietnamese community in Yunnan at an Overseas Chinese Farm) or similar edge cases. I think we should just deal with uncertainty the same way we deal with uncertainty in any assertions in articles. There will be some edge cases where we should hedge our bets and not use {{convert}}. But this could be a let's-not-throw-out-the-baby-with-the-bathwater situation, as many cases may be quite straightforward. That said, I am very far from being a domain expert, and I would like to hear more from users like Artoria2e5 and Ctxz2323 who may be able to lend their expertise. Thanks, Mathglot (talk) 06:38, 30 May 2025 (UTC)

I would not support a conversion that excludes the SI unit of area. I don't know what a hectare is. I know I can look it up, but why make it hard for readers? Dondervogel 2 (talk) 07:47, 30 May 2025 (UTC)

If that's the only hang-up, then sure. Hectares are more common for land area, as they are 10,000 m² and probably would be easier for most readers but I have no preference if that's more the standard way of doing things in the module. Mathglot (talk) 08:09, 30 May 2025 (UTC)

We should let the writer or editor to decide whether to use, and to use which Convert Templat according to the meaning of the mu used. And have the "mu" unit word linked to the article when first appears in the text. Ctxz2323 (talk) 10:01, 30 May 2025 (UTC)

Yes, that ability already exists in this template using parameter |lk=in, and if mu is added to the module, it will be available to link mu. See config item 'link' above (and below). Mathglot (talk) 17:46, 1 June 2025 (UTC)

Thanks. Ctxz2323 (talk) 01:55, 2 June 2025 (UTC)

A good place for unit information is sizes.com, see mu. Normally something with mu's diversity would not be a convert unit but you seem confident. By all means add it to Convert/extra and see how it goes. Some fixes would be needed: the scale should be the number of square meters in a mu; I doubt SI prefixes are wanted (kmu for kilomu), and if they were wanted it should be prefixes = 2; the unit should probably be "singular" (is it 2 mu or 2 mus?). Accordingly, you could try:

["mu"] = {
    name2    = "mu",
    symbol   = "mu",
    utype    = "area",
    scale    = 666.6666666666667,
    default  = "ha",
    link     = "Mu (land)",
},
["mu-zh"] = {
    target   = "mu",
},

Johnuniq (talk) 10:17, 30 May 2025 (UTC)

Feature Request: add conversions for bit, byte, kilobit, kilobyte, kibibyte, etc.

• Interpret lowercase 'b' as bit, uppercase 'B' as byte.
• Byte multiples; KiB for Kibibyte, KB for Kilobyte.
• Bit multiples; Kib for Kibibit, Kb for Kilobit (commonly used in networking).
• Transfer rates between bits/s and bytes/s, and their respective multiples (e.g. 8 Gb/s (1 GB/s8 Gib/s (1 GiB/s))

Also handling of 2^n (No idea if already present), these can be used outside of bits and bytes too. Example conversion: 2³² bytes (4 GiB)

2^n is a commonly used to denote maximum (or minimum in case of negative) values. For signed integers (2^n)-1 is used to indicate the maximum.

edit 17:45, 28 May 2025 (UTC): removed GB,Gb like units from request, as it's ambiguous wether these are 1000^n based units, or 1024^n based units. Doerakpoes (talk) 15:46, 28 May 2025 (UTC)

There are two definitions of each of kilobyte, gigabyte and the rest. It is often unclear which is meant, or we can only determine it from fine print or indications elsewhere of which convention might apply. This can be so uncertain or verging on WP:OR that we very often don't provide conversions (and there have been very strong opinions expressed as to which convention Wikipedia should use). Conversions such as kilobyte to kibibite or gigabyte need RS support for that instance; facilitating them in Convert would open up a great risk of them being done wrongly. NebY (talk) 16:32, 28 May 2025 (UTC)

I can see how the ambiguity issues of GB, Gb, etc. would make conversion prone to being done erroneously. I'll remove them from the request. Doerakpoes (talk) 17:20, 28 May 2025 (UTC)

There's no ambiguity in data rates. The symbols would be bit/s, kbit/s, Mbit/s ..., B/s, kB/s, MB/s, ... Kibit/s, Mibit/s, ..., KiB/s, MiB/s, ... Conversions for those would be helpful. Dondervogel 2 (talk) 17:42, 28 May 2025 (UTC)

I don't know of anybody that uses binary units for transfer rates: (e.g. 8 Gib/s (1 GiB/s)) should be (e.g., 8 Gb/s (1 GB/s)). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:16, 28 May 2025 (UTC)

I agree MiB/s is rare, but here's one example. The symbol used on Wikipedia for gigabit per second is Gbit/s, not Gb/s. Dondervogel 2 (talk) 19:20, 28 May 2025 (UTC)

Another example of MiB/s, this time by Toshiba. A conversion from MiB/s to MB/s would be helpful for Toshiba products. Dondervogel 2 (talk) 22:55, 28 May 2025 (UTC)

I've personally never seen GiB/s either, it's just that GB/s could be 1024^3 bytes per second, instead of 1000^3 bytes per second. Doerakpoes (talk) 20:11, 28 May 2025 (UTC)

I don't buy that. In the communications world there is no ambiguity. 1 GB/s might more commonly be written 8 Gbit/s, but where used it means one billion bytes per second. Dondervogel 2 (talk) 21:21, 28 May 2025 (UTC)

The MOS does state: "while the decimal meanings are more common for data transmission rates". Doerakpoes (talk) 21:27, 28 May 2025 (UTC)

According to Data-rate units there is no overlap. Doerakpoes (talk) 21:48, 28 May 2025 (UTC)

Such conversions would be useful. A previous discussion didn't get far. Hopefully, we'll make progress this time. — Chrisahn (talk) 18:27, 28 May 2025 (UTC)

Don't hold your breath. EEng 16:14, 30 May 2025 (UTC)