This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 |
This talk page uses amazing code to make month/year archives. That was highly desirable a long time ago when the old templates were used because maintaining 4,000 templates was a lot of effort. However, a more conventional system might be appropriate now. I suppose there could be a link to an index page with links to all the month/year archives—it would need a "search archives" box. Or, lazy people like me might just leave the current system working. If it's left as-is, should Template talk:Convert/Archive 1 be deleted and salted to prevent further accidental creation? That page was deleted in May 2015 and December 2015, and has just been created again (hi EEng!). Thoughts? Johnuniq ( talk) 01:34, 9 July 2020 (UTC)
|archive = Talk:Convert/Archive %(counter)d
; works with
Talk:Gold & with the manual Archive button - I experienced. We can then manually: Set counter to #2 right away; Use #1 for past months of 2020; Add numbered box. The monthly-box: fold into years-only showing. Possible issue to check: one search box works searching both two sets of pages having .../Archive? -
DePiep (
talk) 15:58, 9 July 2020 (UTC)Plan @ EEng, Stepho-wrs, and DePiep: Everyone went quiet but I'm warming to the following idea:
Thoughts? Johnuniq ( talk) 10:09, 17 July 2020 (UTC)
Done Please check the archive box that I put on this page. It would be desirable to add a note somewhere that the old archives are listed at Template talk:Convert/Archive 1. I made the 2020 archive pages redirect to Archive 1. Johnuniq ( talk) 01:46, 21 July 2020 (UTC)
What DePiep said looks good, although how the archives work doesn't affect me because I keep a single local file with all the archives concatenated so I can search it more easily. One search box will work (see #Search experiment below).
There are 153 archive pages totalling about 7MB. The six 2020 archives total about 132KB. I think the archives older than 2020 should be left alone, but those in 2020 should be consolidated in /Archive 1, and the 2020 archive pages deleted. EEng is right in that having, for example, one largish archive per year rather than 12 short archives per year would make finding recent discussions much easier.
Does anyone want to keep the current system for 2020 and the future? If we agree to change, it looks like it would be readily achievable except that there would need to be an index page listing the month/year archives, with a link to the index on this page, preferably in a new archive box, or at least near it. Or, we could put the index at the beginning of Archive 1. The index is currently at Template talk:Convert/Archives with some tricky wikitext. That could be replaced with the expansion from Special:ExpandTemplates so it would work on another page. Thoughts? Johnuniq ( talk) 05:23, 10 July 2020 (UTC)
This is the current search archives box. It works on all /Archive subpages so will handle
/Archive June 2020 as well as
/Archive 1. For example, typing curie
in the following finds both those pages because I moved text from the latter to the former so a section is currently duplicated.
Examining the URL generated by the search show something strange: It includes:
&fulltext=Search+archives &fulltext=Search
which seems wrong. I imagine only the first of these is used. The second is either a mistake or a lazy way of providing a default in case fulltext
is omitted.
Johnuniq (
talk) 05:23, 10 July 2020 (UTC)
It works on all /Archive subpages so will handle /Archive June 2020 as well as /Archive 1. That says it all. My thumb is up. Not for love, but from rational improvement I see. - DePiep ( talk) 20:46, 18 July 2020 (UTC)
Do the convert templates have any help for converting Deadweight tonnage into internationally recognized units of weight, or mass? tons and tonnes short tons and long tons plus others? are legend. I did a search and couldn't find anything. Cheers. N2e ( talk) 04:09, 29 July 2020 (UTC)
Since {{convert}} supports almost every conceivable unit (except poorly defined historical/folk units), it seems puzzling that it does not support angular units. I propose to add the following units:
Code | Symbol | Name | Link | Comment |
---|---|---|---|---|
° |
° | degree | Degree (angle) | The buttons for entering ° ′ ″ are right under the text input area. |
′ |
′ | arcminute | Minute of arc | |
″ |
″ | arcsecond | Second of arc | |
mas |
mas | milliarcsecond | Milliarcsecond | |
µas |
µas | microarcsecond | Microarcsecond | |
radian |
rad | radian | Radian | rad is already taken by radiation unit
rad.
|
mradian |
mrad | milliradian | Milliradian | |
grad |
grad | gradian | Gradian | grad is non-standard, but instantly recognizable. |
turn |
turn | turn | Turn (angle) | |
Rotational speed: | ||||
rpm |
rpm | revolution per minute | Revolutions per minute | Default output: Hz .
|
radian/s |
rad/s | radian per second | Radian per second | Default output: Hz .
|
Aliases: | ||||
arcmin |
arcmin | arcminute | Minute of arc | |
arcsec |
arcsec | arcsecond | Second of arc | |
gon |
gon | gradian | Gradian | gon is specified in ISO 31-1. |
r |
r | turn | Turn (angle) | r is specified in IEEE 260.1:2004 and ISO 80000-3:2006. |
MOA |
MOA | minute of angle | Minute of arc | Used in weapons aiming. Default output: milr .
|
milr |
mil | milliradian | Milliradian | Used in weapons aiming. Default output: MOA .mil is already taken by
thousandth of an inch.
|
The multiple units feature of {{convert}} can be used in input:
{{convert|2|°|47|′|19|″|radian|abbr=on}}
→ 2° 47′ 19″ (0.048670 rad){{convert|47|′|19|″|mradian|abbr=on}}
→ 47′ 19″ (13.764 mrad)And output:
{{convert|0.50|mradian|′″}}
→ 0.50 milliradian (1′ 43″){{convert|0.50|mradian|′ ″}}
→ 0.50 milliradian (1.72′; 103″)There are other angular units that may be added in the future, if a need arises:
— UnladenSwallow ( talk) 05:16, 21 April 2020 (UTC)
Hz
is a unit of length)—see
March 2015.
Johnuniq (
talk) 06:52, 21 April 2020 (UTC)
{{cvt|5|L/100 km}}
→ 5 L/100 km (56 mpg‑imp; 47 mpg‑US){{cvt|10|L/100 km}}
→ 10 L/100 km (28 mpg‑imp; 24 mpg‑US)Article | Example | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Pendulum | In the case of a typical grandfather clock whose pendulum has a swing of 6° and thus an amplitude of 3° (0.05 radians), the difference between the true period and the small angle approximation (1) amounts to about 15 seconds per day. | ||||||||||||
Angular diameter | The table shows that the angular diameter of Sun, when seen from Earth is approximately 32′ (1920″ or 0.53°), as illustrated above. | ||||||||||||
To put this in perspective, the full Moon as viewed from Earth is about 1⁄2°, or 30′ (or 1800″). | |||||||||||||
Globe | Usually a globe is mounted so that its spin axis is 23.5° (0.41 rad) from vertical, which is the angle the Earth's spin axis deviates from perpendicular to the plane of its orbit. | ||||||||||||
Telescopic sight | Some proprietary rails also offer the possibility to tilt the scope up to 1° (60 moa; 17.5 mrad) to the left or right. | ||||||||||||
Equation of time | The numerical values written here result from using the orbital parameter values, e = 0.016709, ε = 23.4393° = 0.409093 radians, and λp = 282.9381° = 4.938201 radians that correspond to the epoch 1 January 2000 at 12 noon UT1. | ||||||||||||
Steradian | This angle corresponds to the plane aperture angle of 2θ ≈ 1.144 rad or 65.54°. | ||||||||||||
Faraday effect | By placing a rod of this material in a strong magnetic field, Faraday rotation angles of over 0.78 rad (45°) can be achieved. | ||||||||||||
JavaScript syntax |
| ||||||||||||
Young–Laplace equation | For a water-filled glass tube in
air at
sea level:
| ||||||||||||
Small-angle approximation | The angles at which the relative error exceeds 1% are as follows:
|
Article | Example |
---|---|
Exoplanet | The data was obtained on 16 March 2003 with NACO on the VLT, using a 1.4 arcsec occulting mask on top of AB Pictoris. |
Alpha Centauri | Viewed from Earth, the apparent orbit of A and B means that their separation and position angle (PA) are in continuous change throughout their projected orbit. Observed stellar positions in 2019 are separated by 4.92 arcsec through the PA of 337.1°, increasing to 5.49 arcsec through 345.3° in 2020. The closest recent approach was in February 2016, at 4.0 arcsec through the PA of 300°. The observed maximum separation of these stars is about 22 arcsec, while the minimum distance is 1.7 arcsec. |
Their apparent angular separation varies over about 80 years between 2 and 22 arcsec (the naked eye has a resolution of 60 arcsec), but through much of the orbit, both are easily resolved in binoculars or small telescopes. | |
Quasar | Image is 60 arcsec on a side. |
New Horizons | The instrument is equipped with a 1024×1024 pixel by 12-bits-per-pixel monochromatic CCD imager giving a resolution of 5 μrad (~1 arcsec). |
Parallax | The nearest star to the Sun (and thus the star with the largest parallax), Proxima Centauri, has a parallax of 0.7687 ± 0.0003 arcsec. |
Cosmic distance ladder | It is, more precisely, the galaxy's angular diameter out to the surface brightness level of 20.75 B-mag arcsec−2. |
Panspermia | The probability of hitting the target zone can be calculated from where A(target) is the cross-section of the target area, dy is the positional uncertainty at arrival; a – constant (depending on units), r(target) is the radius of the target area; v the velocity of the probe; (tp) the targeting precision (arcsec/yr); and d the distance to the target, guided by high-resolution astrometry of 1×10−5 arcsec/yr (all units in SIU). |
Astrometry | In the 16th century, Tycho Brahe used improved instruments, including large mural instruments, to measure star positions more accurately than previously, with a precision of 15–35 arcsec. |
He made the first measurement of stellar parallax: 0.3 arcsec for the binary star 61 Cygni. | |
During the past 50 years, 7,435 Schmidt camera plates were used to complete several sky surveys that make the data in USNO-B1.0 accurate to within 0.2 arcsec. | |
Proper motion | Of the stars visible to the naked eye (by convention, limiting visual magnitude of 6.0),
61 Cygni A (magnitude V=5.20) has the highest proper motion at 5.281 arcsec/a, although
Groombridge 1830 (magnitude V=6.42), proper motion 7.058 arcsec/a, might be visible for an observer with exceptionally keen vision.
A proper motion of 1 arcsec per year at a distance of 1 light-year corresponds to a relative transverse speed of 1.45 km/s. |
arcsec
will be unambiguous when used with {{convert}}
. —
UnladenSwallow (
talk) 11:38, 24 April 2020 (UTC)See Boom Overture. This template is translating Mach 2.2 as 2,300 km/h or 1,300 kn, the actual values (precision 2 s.f.) ought to be 2,700 km/h or 1,500 kn. Could someone please fix this?-- Newbiepedian ( talk · C · X! · L) 15:44, 2 August 2020 (UTC)
Ikarus 55#Technical description
190 g·PS<sup>−1</sup>·h<sup>−1</sup> (258 g·kW<sup>−1</sup>·h<sup>−1</sup>)
190 g·PS−1·h−1 (258 g·kW−1·h−1)
How was this calculated and how can this be done with convert?
Peter Horn
User talk 00:22, 4 August 2020 (UTC)
190 g·PS<sup>−1</sup>·h<sup>−1</sup> (258 g·kW<sup>−1</sup>·h<sup>−1</sup>)
→ 190 g·PS−1·h−1 (258 g·kW−1·h−1){{cvt|190|g/PS/h|g/kW/h}}
→ 190 g/PS/h (260 g/kW/h){{cvt|190|g/PS/h|g/kW/h|0}}
→ 190 g/PS/h (258 g/kW/h)There seem to be no bit and byte unit conversions, e.g. between kilobytes and megabytes etc. Should we add them? I didn't find any discussions in the archive. I'd like to add them to Module:Convert/documentation/conversion data. Of course, we'll have to take care of binary prefixes and conversions between bits and bytes, and also make sure that unit names are unambiguous, but that shouldn't be a major problem. What do you think? -- Chrisahn ( talk) 11:19, 13 October 2020 (UTC)
{{
val}}
is used for expressing a single value whereas {{
convert}}
is used for converting between different units.
Martin of Sheffield (
talk) 11:53, 13 October 2020 (UTC)
{{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KB|0|disp=out}}
would display 66 KB{{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KiB|0|disp=out}}
would display 64 KiB{{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KiB|0|disp=out}}
would display 64 KB (IEC: KiB){{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KiB|0|disp=out}
would display 64 KB{{convert|65536|bytes|KiB|0|disp=out|binpre=IEC}}
would display 64 KiB{{convert|65536|bytes|KiB|0|disp=out|binpre=SI+IEC}}
would display 64 KiB (IEC: KiB)KiB-IEC
. Not very intuitive for users.Folks, let's stop this. This wasn't meant to be about WP:COMPUNITS at all. It was never my intention to address that question. I didn't even know about that MOS section. Please consider this thread closed. I'll archive it later. Maybe I'll start a new one when I have time. Thanks. -- Chrisahn ( talk) 11:57, 14 October 2020 (UTC)
References
I notice at
2020 Beirut explosion that in an instance of this template, {{convert|1.2|ktonTNT|TJ|sigfig=2|lk=on}}
, which renders as 1.2
kilotons of TNT (5.0
TJ)
, the link over TJ goes just to
Joule, rather than to
Terajoule, which redirects to
Joule#Terajoule. I think it would be more useful for readers for the link to go to terajoule, since they may not know that the T stands for tera. Could a more specific link be adopted here for terajoules and other multiples of joules/other units as appropriate? {{u|
Sdkb}}
talk 02:45, 17 August 2020 (UTC)
The Convert template handles absolute temperatures just fine:
"The mean winter temperature in Smallville is {{convert|3|C|F}}
."
yields
"The mean winter temperature in Smallville is 3 °C (37 °F)."
But Convert cannot handle temperature differences correctly:
"The mean annual temperature in Smallville has increased by {{convert|3|C|F}}
in the last century."
yields
"The mean annual temperature in Smallville has increased by 3 °C (37 °F) in the last century."
which is nonsense. The correct conversion would be:
"The mean annual temperature in Smallville has increased by 3°C (5.4°F) in the last century."
I noticed this error in the article about Kuujjuaq. I fixed it there by simply removing the Convert template in cases where the temperature being referenced is a difference, and doing the conversion manually. I haven't searched, but I wouldn't be surprised if this mistake has come up in many articles, such as in coverage of global warming.
I can't think of an elegant way to fix this. Perhaps a mechanism like this could be implemented: {{convert|n|deltaC|deltaF)
. But that would require some serious work on the Convert help page, and would still probably confuse many editors. I have little experience with templates, maybe someone with more experience could suggest a better idea.
STarry (
talk) 07:22, 14 September 2020 (UTC)
{{convert|3|C-change|F-change}}
: 3 °C (5.4 °F){{convert|3|C|F}}
: 3 °C (37 °F)Any idea how I should handle the following unit: Pounds of coal per indicated horsepower hour
This is a measure of the fuel efficiency of early steamships and appears in SS Carnatic. Carnatic and Agamemnon both achieved a massive stepwise improvement in efficiency (though the higher boiler pressure of SS Agamemnon (1865) became the model for immediate future development).However, in discussing this, the units look clumsy and are not friendly to anyone used to modern units. ThoughtIdRetired ( talk) 20:01, 16 September 2020 (UTC)
{{convert|1|hph|kWh|adj=pre|indicated}}
→ 1 indicated horsepower-hour (0.75 kWh){{convert|1|hph|kWh|adj=pre|indicated|spell=in}}
→ one indicated horsepower-hour (0.75 kWh){{convert|1|hph|kWh|disp=out}}
→ 0.75 kWhThere are 2240 pounds in a Long Ton (LT). The convert macro does not convert LT-to-ton correctly.
{{convert|3900|LT|t}}
incorrectly yields 4,000 tons, not 4,368 tons. Proof: 3,900 long tons (4,000 t){{convert|2100|LT|t}}
incorrectly yields 2,100 tons, not 2,352 tons. Proof: 2,100 long tons (2,100 t)How to fix? Or can someone else correct the conversion? 50.107.153.113 ( talk) 21:23, 17 September 2020 (UTC)
{{convert|3900|LT|ST}}
more correctly yields 4,400 tons, not 4,368 tons. Proof: 3,900 long tons (4,400 short tons){{convert|2100|LT|ST}}
more correctly yields 2,400 tons, not 2,352 tons. Proof: 2,100 long tons (2,400 short tons){{convert|3900|LT|ST|abbr=off|}}
→ 3,900 long tons (4,400 short tons){{convert|2100|LT|ST}}
→ 2,100 long tons (2,400 short tons){{convert|3900|LT|ST|abbr=off|0}}
→ 3,900 long tons (4,368 short tons){{convert|2100|LT|ST|0}}
→ 2,100 long tons (2,352 short tons)Everyone who worked on this Temp really knows what they're doing. I'm very impressed. Invasive Spices ( talk) 22:41, 2 October 2020 (UTC)
{{long ton|166| 6| 2}} 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t) does not work but this {{long ton|166| 6}} 166 long tons 6 cwt (372,500 lb or 169 t) does work. Talk:South Australian Railways 700 class (steam)#A flaw? Peter Horn User talk 00:43, 22 November 2020 (UTC)
{{long ton|166|6|2}}
→ 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t)I've been impressed with how developed and flexible this template is. Ultimately, I assume that the place we want to end up is with an option in user preferences that allows choosing a unit/currency/etc. system, so that a British reader could see meters even when reading a U.S. article and a U.S. reader feet even when reading a British one, without the clutter of the other unit. How far are we from making this a reality? Is it just a matter of doing some complicated programming, or are there particular obstacles from the way articles are written, or are there editorial concerns about e.g. fracturing the encyclopedia? {{u| Sdkb}} talk 18:49, 21 September 2020 (UTC)
Another issue: I might use a meter to measure 5 metres! Martin of Sheffield ( talk) 20:45, 21 September 2020 (UTC)
https://physics.nist.gov/cuu/pdf/sp811.pdf section 7.6 This Guide takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible . This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using — the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and — the symbols for the units, not the spelled-out names of the units. Examples:
--end-quote -- Bold added by me.--
The bold should be enough to use the symbols, not the full text. A couple of points to add:
We are not introducing a meter (m) as this is known and understood. However a concept like Performance Management (PM) would still be introduced in this manner.
Also, I would like to just point out that saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m. If that m truly has to be introduced, then the first mention should be 5 meter (m). Note that I also changed the 5 meters into 5 meter (5 meters is not allowed for sure). Hence 5 m works easier and better, because you can read it the way you want even as five metres if you want.
My only additional advice would be to avoid d(deci), D(Deka) and H(Hecto) at all cost to make the text readable. Stick to micro, milli, kilo and Mega. Note that I strategically forgot to mention centi. Should not be used in this logic, but is just to pervasive to ignore in the older UOMs.
I am actually not trying to create a huge stir here. But abbr=on should be used and not using it the first time does not add value and so abbr=on should be used for all. Also keep text readable by not using 0.5 km (1,640.4 ft) however true this statement is. It creates an assumption of precision in the translated unit that was not there in the original UOM. So wiki does this almost correct with 0.5 km (1,600 ft); just don't add |0 or |1 as I see very often — Preceding
unsigned comment added by
Frankk20168 (
talk •
contribs) 07:03, 28 November 2020 (UTC)
saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m.because this is not a paper encyclopedia. For a common unit, it doesn't matter so much, but we could write "five metres" and more importantly, we will write "five chains" on first use, where the hyperlink for an uncommon unit allows the reader to establish the magnitude of the unit as well as its abbreviation if they are unfamiliar with it. That definitely helps a reader get to grips with 63 ch when they see that at the second mention.
|abbr=
for the reasons already rehearsed. When you've actually used
Template:Convert, you'll find that it does a really good job of dealing with precision by default and {{convert|0.5|km|ft}}
produces 0.5 kilometres (1,600 ft)
, which is as good a conversion as anyone will want most of the time. There are edge cases where the default precision isn't optimal, but the fixed decimal places option and rounding to a given number of significant figures functionality are available to improve the display in those cases. --
RexxS (
talk) 13:02, 28 November 2020 (UTC)On you ch example, I also agree. That should be introduced. My point is normal SI units should not be introduced. The meter being prime among them. This is what REUTERS has to say about it:
kilogram
Use kg (no full stop, same singular and plural) at all references. To convert to pounds multiply by 2.205.
kilometre
Use km (no full stop, same singular and plural) at all references, except in a phrase such as hundreds of kilometres.
km per hour
First reference, kph on second and subsequent references.
/quote Obviously I have problems with the last statements (the kph part). But I included it to get part of your point in, too. Again, I completely agree to introduce 5 feet and then followed by 10 ft (or even 10') later. or 63 chain and then 60 ch. My contentions was for the basic SI units (And I admit I added basic here for the first time), they should not be spelled out. Introducing 100 kilometer per hour is just a painful read. It also introduces at least two issues: Should it be: 100 kilometer per hour 100 kilometers per hour 100 kilometre per hour 100 kilometres per hour All these four variations get resolved by making it 100 km/h. Again, I agree with most of what you are saying. The above on Si unit L, m, km and kg we have different opinions. I would also like to point out that "15,000 pounds per square inch (100,000 kilopascals)" (An actual copy from a paste from a Wiki page) is a painful read that does not help (Americans know that PSI ha something to do with their tire pressure, it is never spelled out. The 100,000 kilopascals is too much. Both also have the problem of the added s. I realize we will never get on exactly the same page. So here is the summary of my advice (incorporating your feedback):
I hope this helps and also creates some reasonable guidelines that can help. — Preceding unsigned comment added by Frankk20168 ( talk • contribs) 06:09, 30 November 2020 (UTC)
Not really about the template itself, but I was reverted at General Electric GE9X when adding the template because "the source contained both values". WP:Integrity was cited, which doesn't say anything about this. Is there really a valid reason to not use the template? MB 16:31, 8 December 2020 (UTC)
As I noted in
Help talk:Convert, it seems that {{convert|1.6|Mach}}
Mach 1.6 (1,960 km/h; 1,220 mph) doesn't set sigfig based on the input value. It was suggested to ask here about it. I don't know if this is specific to Mach, though. I put sigfig=2 in the one case I found, and don't know how many others there might be. Is there a regexp search good enough to search for them?
Gah4 (
talk) 14:04, 8 December 2020 (UTC)
This template/module uses the visualhide class. It has a TemplateStyles solution and will accordingly be removed from Common.css soon. Your feedback regarding the timeline is requested at MediaWiki talk:Common.css § visualhide removal. Izno ( talk) 17:10, 2 December 2020 (UTC)
Yes, I'm too lazy to have thought of that myself, and it was copied. Nothing about convert is simple. Examining an enwiki dump of articles from June 2020 shows:
Template | Total | Fractions | Percentage |
---|---|---|---|
convert | 3,145,551 | 13,182 | 0.4 |
cvt | 107,257 | 421 | 0.4 |
Should the 3 million convert usages output a template style that is used by only 0.4% of them? Where would that templatestyles be placed? Johnuniq ( talk) 23:25, 2 December 2020 (UTC)
|disp=table
usages and possibly others? Would they work painlessly?
Johnuniq (
talk) 23:55, 2 December 2020 (UTC){{convert|47.5|kg|lb|disp=table}}
→ style="text-align:right;"|47.5\n|style="text-align:right;"|105
frame:extensionTag
were prepended to where <span class="visualhidesr-only">
were output, I wouldn't expect there to be any fundamental issues.
fracfmt
is handled between the two code paths where it is used versus its earlier definition: 1 definition has 3 replaced patterns with %s, the other three have 4; whereas the calling sites expect 4 patterns total. (And anyway, it's a hack in an unfamiliar codebase, so forgive me any sins. ;)fracfmt
to decrease the output regardless when displaying as a fraction by moving the inline styles there to TemplateStyles and/or from include to unstrip budgets (pending Anomie on the second part). This could either rely on {{
frac}}'s TemplateStyles, or since we're here, a new
Module:Convert/styles.css for the stuff unrelated to sr-only. (I see other places you might entertain a move as well; I count some 10-15 uses of style=
.)data-sort-value
surrounding the contents when used in table form. I do not know how it will do as a naked convert in a sortable table with the style/link elements.
TheDJ might have some knowledge there.<style>
for every use and they're then deduplicated, and apparently the unstrip size is measured before deduplication.
Anomie
⚔ 17:02, 3 December 2020 (UTC)@ Izno: Re Module:Convert/sandbox: Sorry that I have ignored the issue due to normal turmoil. However, I think about what should be done and I have a plan for handling styles in convert. I should get around to it in the next couple of days. Another plan I've had for years is to fix Module:Convert/tester so it changes the unique number in strip markers to be, say, all zeroes so the comparisons won't break. Johnuniq ( talk) 23:40, 11 December 2020 (UTC)
I'll record here that I tweaked Module:Convert/tester to normalize strip markers but on checking the effect I realize that the method is broken. It probably would work as a comparison but it won't display the Expected results correctly because the strip markers have been replaced with fake ones. I'll contemplate what to do about that. Johnuniq ( talk) 09:02, 12 December 2020 (UTC)
...the "calculate" template ? EOLE79 ( Talk ?) 10:28, 12 December 2020 (UTC)
It would be useful if this template could be used to define the thousands separator differently for each converted unit. For instance, when using the template to convert AU to both km and mi, it would be nice to be able to specify gap for kilometers and comma for miles, as gaps are not usually used for miles but are for kilometers, especially for science-related articles like one using AU. Lexicon (talk) 19:51, 26 October 2020 (UTC)
The example from there (without the redundant |lk=off
) is:
{{convert|0.1|AU|km mi|abbr=on}}
→ 0.1 AU (15,000,000 km; 9,300,000 mi){{convert|0.1|AU|km mi|abbr=on|comma=gaps}}
→ 0.1 AU (15000000 km; 9300000 mi)The second convert shows how it would look with gaps, and here is how it is wanted:
I'm unsure whether that would be useful. Johnuniq ( talk) 23:09, 26 October 2020 (UTC)
gaps are not usually used for miles but are for kilometers. In my experience they're independent issues, and the mixed format above looks wretched. E Eng 23:42, 2 December 2020 (UTC)
The space separator is used in french !
The apos is used in calculators !
EX : 7786554443 is 77 866 554 443 (french) or 77'866'554'443 (calculators). EOLE79 ( Talk ?) 10:40, 12 December 2020 (UTC)
Hello, I ran into this (aesthetic) problem on Brick while editing the per-country dimensions of a brick in a table, partially reproduced here:
EXAMPLE TEMPORARILY DISABLED BECAUSE IT WAS SENDING THE RENDERING SOFTWARE INTO ORBIT
Using "lk=on|disp=table|abbr=on" (first row) gives me the unit on each of the measurements. Ideally, I'd like "25 × 50 × 75 mm (1 × 2 × 3 in)", but this doesn't quite work when I try it with other flags.
{{convert|225|×|112.5|×|75|mm|in}}
→ 225 by 112.5 by 75 millimetres (8.86 in × 4.43 in × 2.95 in){{convert|225|×|112.5|×|75|mm|in|abbr=on}}
→ 225 mm × 112.5 mm × 75 mm (8.86 in × 4.43 in × 2.95 in)It seems adding "abbr=on" forces the separation to use "×", but also displays the units on every number instead of the last one. I suspect "disp=table" hides the units altogether, but combining it with another flag like "lk=on" or "abbr=on" overrides that. Can we change "abbr=on" to only display units on the final number? This seems inconsistent.- Ich ( talk) 16:04, 11 December 2020 (UTC)
{{convert|230|×|110|×|76|mm|in|disp=table}}
like most other tables do? The units are in the heading and should not be repeated in each row. There is no need to link mm or inches, but if really needed, there is sure to be somewhere close by in the text (not in the table) where that could be done. Or, the unit names in the heading could be linked. However, convert retains two seldom-used features that are available if really really needed. There is no repeated unit symbol with *
or xx
. *
outputs × with no spacing, while xx
outputs × with a nonbreaking space on each side. You would use one of these in a table:
{{convert|230|*|110|*|76|mm|in|lk=on|disp=table|abbr=on}}
{{convert|230|xx|110|xx|76|mm|in|lk=on|disp=table|abbr=on}}
x
not ×
in convert. The former is easy to type and easy for other editors to emulate. It gives the same output as ×
.
Johnuniq (
talk) 23:11, 11 December 2020 (UTC)In the lead for Europe, I noticed the slightly jarring juxtaposition of 10,180,000 km2 (3,930,000 sq mi), where the kilometers uses "2" but the miles uses "sq". Looking at the documentation here, it seems to be a U.S. vs. UK thing, but from my experience, "2" is generally more popular in America, too. Have we considered just going to "2" for all uses? {{u| Sdkb}} talk 07:11, 13 December 2020 (UTC)
This sentence is not prescriptive (or, indeed, proscriptive), but it does explicitly permit the use of "sq" and "cu", and I don't feel that it's appropriate to make changes here that would arguably de facto amount to an MOS change. The Europe article mentioned above uses the style in question, I'd presume, because it is the default convert template style – and I'd argue that making something the default convert template style will almost always ipso facto make it the normal style used in the encyclopedia. This is simply because it's the style that the vast majority of editors will default to, even if unknowingly – I presume that most editors don't know there are so many options for customising the exact output of {{convert}}, as I use it extensively and wasn't aware that it was possible to get it to output e.g. "in2" until very recently.sq or cu may be used with US customary or imperial units, but not with SI units.
An IP user asks about a figure in an article: "Her steel hull had an overall length of 350 feet (110 m) (one source states 358 feet (109 m))" How can 350 feet be 110 m but 358 feet is 109 m?
And I say, great question. I look at the article and see that it's getting those values with {{
convert}}, videlicet: Her steel hull had an
overall length of {{convert|350|ft|m}} (one source states {{convert|358|ft|m}})
.
Now, the standard response to this is that precision can be specified when invoking the template, but I don't think this is proper, and especially it's not proper to arbitrarily and invisibly use different rounding based on if the figure ends in a zero. The obvious, and intuitive, use for this template is to do simple arithmetic and multiply feet into meters (indeed, this is how it is used in every article I've seen it). So I had a lively debate with my friend about this, and he pointed out that most uses of "350" or "300" or the like are probably approximate, and giving a precise meter conversion would mislead readers. However, I disagree with the way this has been implemented in the conversion template.
(As someone who's designed and machined parts with some dimensions measured in ten-thousandths of an inch and some dimensions measured in feet, and communicated with both PhDs and CEOs about these parts: when someone writes "350", in the vast majority of cases, it does not mean "350 ± 5" -- and if it does mean the former, they will say "about 350"; the word "about" doesn't have a standardized error bar on it, and I'd almost go so far as to call it WP:OR to imply so.)
But for concrete suggestions: first of all, my issue with this is not the rounding: 350.00 feet is 106.68 meters, which would be a silly amount of precision to give, and I'd be fine with presenting it as 107. I'd even be fine with the template rounding to significant figures whenever precision wasn't specified. However, the current state of affairs is that the template will round to the nearest meter, unless the number ends in a zero, in which case it will silently make the number ten times less precise, in a way that is never made apparent to the editor or the reader.
Exemplis grata:
The building was {{convert|345|ft|m}} tall
= "The building was 345 feet (105 m) tall"The building was {{convert|350|ft|m}} tall
= "The building was 350 feet (110 m) tall"The building was {{convert|355|ft|m}} tall
= "The building was 355 feet (108 m) tall"The building was {{convert|360|ft|m}} tall
= "The building was 360 feet (110 m) tall"If you were an editor and hadn't read five full screens of template documentation (or if you're a Wikipedia reader, who doesn't even know what templates are), would this make sense to you if you saw it in a page? Would it be immediately apparent, if you only saw one of these examples, that every other measurement was being rounded to the nearest 10m and not the nearest 1m?
I think that this is fairly counterintuitive; if the default behavior is to perform different conversions based on the last digit of the number, it should say "approx." or in some way indicate when it's using an alternative conversion scheme. A template should not be making blanket assumptions about the precision of numbers in articles and presenting them as fact. jp× g 01:54, 10 December 2020 (UTC)
{{convert|12000|mi}}
in the second paragraph which starts with "More than 12,000 miles (19,000 km) of roads". Rounding to the nearest km would give "More than 12,000 miles (19,312 km) of roads". While there are examples of convert's default behavior giving bad results, there are plenty more where the results are good. If someone unfamiliar with the template wonders why silly numbers are being shown (such as in the above), they can ask here or at
WP:HELPDESK for assistance.
Johnuniq (
talk) 03:52, 10 December 2020 (UTC)
The building was {{convert|358|ft|m}} tall
= "The building was 358 feet (109 m) tall"The building was {{convert|350.|ft|m}} tall
= "The building was 350 feet (107 m) tall"The model was {{convert|3.45|ft|m}} tall
= "The model was 3.45 feet (1.05 m) tall"The model was {{convert|3.50|ft|m}} tall
= "The model was 3.50 feet (1.07 m) tall"The model was {{convert|3.55|ft|m}} tall
= "The model was 3.55 feet (1.08 m) tall"The model was {{convert|3.60|ft|m}} tall
= "The model was 3.60 feet (1.10 m) tall"The model was {{convert|3.5|ft|m|sigfig=3}} tall
= "The model was 3.5 feet (1.07 m) tall"The model was {{convert|3.6|ft|m|sigfig=3}} tall
= "The model was 3.6 feet (1.10 m) tall"I've also struggled with this for years but it's not a simple problem to solve. My use of convert is mostly for cars - where 350 always means 350±1. But I also recognise that other subjects use bigger numbers where 35,000 often means 35,000±500. Solutions are:
|0
or |1
or |round=5
at the end of most conversions for car articles.My preference would be #2 but really both #2 and #3 are valid solutions with similar pros and cons. We can't make everybody happy and the current solution is a very good attempt at making as many people as happy as possible. The only improvement I can think of is to make the rounding issue more prominent in the documentation. Stepho talk 00:56, 13 December 2020 (UTC)
This was previously request ( Template talk:Convert/Archive October 2015#Ton-mile and passenger-mile) but, as far as I can tell, never implemented. 1 ton-mile = 1.459972 tonne-kilometers. (see Units of transportation measurement) Would it be possible to implement this conversion? Hawkeye7 (discuss) 19:42, 17 December 2020 (UTC)
I added the units at Module:Convert/documentation/conversion data#Transportation and included them in the module. If these are used in articles in the next couple of days (before the #Module version 25 release above), they will be included in the main data. Otherwise, they will be temporary. Examples (please check!):
{{convert|1|tkm|6|abbr=on}}
→ 1 tkm (0.684944 ton-miles){{convert|1|ton-mile|6|abbr=on}}
→ 1 ton-mile (1.459972 tkm){{convert|1|tkm|abbr=off}}
→ 1 tonne-kilometre (0.68 ton-miles){{convert|1|ton-mile|abbr=off}}
→ 1 ton-mile (1.5 tonne-kilometres){{convert|2|tkm|abbr=off|lk=on|sp=us}}
→ 2
tonne-kilometers (1.4
ton-miles){{convert|2|ton-mile|abbr=off|lk=on|sp=us}}
→ 2
ton-miles (2.9
tonne-kilometers)Johnuniq ( talk) 02:40, 18 December 2020 (UTC)
Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
{{convert|1+1/2|by|5+3/4|in}}
).gramme
from the
unit definitions. This is not a change to units as gramme
is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future.
MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at
MOS talk July 2019 following a request
here.mi/kWh
is retained in extra; it will be removed if not found to be used in articles.scf2
and scfoot2
in articles will be replaced with scf
and scfoot
which have had their link corrected to
standard cubic foot. Discussion
here.mw.wikibase.getLabel(X)
instead of deprecated mw.wikibase.label(X)
.Release notes for earlier versions are listed here. Johnuniq ( talk) 06:13, 14 December 2020 (UTC)
Thanks, good points. Re convert/text, I did wonder about that and I suppose I should be less lazy. I imagine "margin" should also be used here but the html is over my head. @ Izno: Any opinion on that?
Here are some results from Special:ExpandTemplates if anyone wants to compare the outputs.
{{convert/sandbox|1//2|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">1</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">2</span></span> foot (6.0 in)
{{sfrac|1|2}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac nowrap tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">1</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">2</span></span>
{{sfrac/sandbox|1|2}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac tion"><span class="num">1</span><span class="sr-only">/</span><span class="den">2</span></span>
{{convert/sandbox|1+2//3|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap">1<span class="sr-only"> </span><span style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">2</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">3</span></span></span> feet (20 in)
{{sfrac|1|2|3}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac nowrap"><span class="int">1</span><span class="plus sr-only">+</span><span class=" tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">2</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">3</span></span></span>
{{sfrac/sandbox|1|2|3}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac ">1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span></span>
Johnuniq ( talk) 09:43, 14 December 2020 (UTC)
I'm not sure whether you are hinting that Template:Frac/styles.css should be used by convert.Yes, I'm hinting that. It is by no means required of course, but it should dramatically reduce the implementation here (+- the futzing to make sfrac act as expected because I noticed how it is coded in the frac templates and how it is coded here is marginally different).
But it's extra pain for people trying to copy the current version of convert to another site.I've never really put a lot of stock in this as a rationale for anything on en.WP, and not often do I care too often when the module of interest already has a dozen pages to copy; what's one (two?) more? So long as the documentation is clear about all the used pages (as is usual for larger modules), it's rarely an issue.
is what it does ok at least for nowI have no great issues with the now. I do have some issue with the frac implementation, both live/sandbox here and at the template itself, using <sub> and <sup>, and that is why I suggested the sandbox version there to be implemented here now. If you want to play with it some more or want some help understanding what's going on, I wouldn't want to block version 25 on it. -- Izno ( talk) 18:44, 15 December 2020 (UTC)
+
(what should convert do)? For my curiosity, what is role="math"?
Johnuniq (
talk) 23:22, 15 December 2020 (UTC)
As I understand it, that would no longer be needed.Yes, that is correct.
In 1+2/3, why does convert output a hidden non-breaking space after 1, but sfrac outputs a hidden +
(what should convert do)?
I do not know why convert is doing that as a non-breaking space, which is superfluous with the whitespace nowrap CSS variously applied to the same. Regarding space versus plus, sfrac shifted to "+" approximately a year ago in
the same edit that added the classes and role. It was noted at the talk page at
Template talk:Frac#Integrity. I changed the frac sandbox recently to follow since I don't see a good reason for inconsistency. I could personally flip a coin on the pros and cons of + and space character, though I tend toward the semantic + rather than the unsemantic space as my decider. I generally agree with your 3 listed design criteria there.For my curiosity, what is role="math"?An "ARIA role" is a standardized way to assign an HTML element semantics that differ from its default semantics. For example, if you have a layout table, you can assign it
role="presentation"
to indicate that it is not a proper data table per the default HTML semantic assignment for <table>
elements (we have a lot of unfortunate legacy on that point, so we've bolted on a lot of role="presentation"
). It is primarily intended for enhanced accessibility. See also
MDN. role="math"
in particular is
described as Content that represents a mathematical expression.See the link for more details. Whether sfrac and frac should use it is a question mark to me. Given the context of sfrac, I think it may make sense for sfrac generally. For frac, I can probably buy into it when the fraction is marked up with a hidden +. I wouldn't add it without the + in frac. -- Izno ( talk) 21:34, 16 December 2020 (UTC)
{{convert/sandbox|1/2|ft|in}}
→ 1⁄2 foot (6.0 in){{convert/sandbox|1+2/3|ft|in}}
→ 1+2⁄3 feet (20 in){{convert/sandbox|1//2|ft|in}}
→ 1/2 foot (6.0 in){{convert/sandbox|1+2//3|ft|in}}
→ 1+2/3 feet (20 in){{frac/sandbox|1|2}}
→ 1⁄2{{frac/sandbox|1|2|3}}
→ 1+2⁄3{{sfrac/sandbox|1|2}}
→ 1/2{{sfrac/sandbox|1|2|3}}
→ 1+2/3@ Izno:: Please see the experiment in my sandbox ( permalink). That shows quite a large difference in the vertical space occupied by the old and new styles of formatting fractions. I'm wondering if using a fraction (with {{ convert}} or {{ frac}}) might introduce a visually unpleasant vertical gap in the line spacing. Any thoughts? Johnuniq ( talk) 09:49, 19 December 2020 (UTC)
<sup>...</sup>
and <sub>...</sub>
are setting line-height to 1em (which is rendered as 10.16px on my Monobook skin). The corresponding classes .num
and .den
in the sandbox leave the line-height at default, which is 1.5em (rendered as 19.05px on my Monobook skin because the em is also different for the two cases). The two parts of the fraction poke above and below the line of the rest of the text, so need a smaller line-height to prevent the gaps you are seeing. I don't want to fiddle with your stylesheets, but I think that reducing the line-height for the .num and .den classes by about 50% somehow will ease the problem for you. Cheers --
RexxS (
talk) 20:59, 19 December 2020 (UTC)
span class="cvt frac nowrap"
for four extra bytes, then you would create .cvt .frac .num { line-height: 0.5em; }
and .cvt .frac .denom { line-height: normal; }
in
Template:Frac/styles.css so that the adjusted line spacing would only apply to the output of convert. In any case, it's commendable to worry about the load on the servers, but we don't pay them on
piece-work rates, so it's not going to hurt if you put an extra job in the queue once in a while. --
RexxS (
talk) 01:33, 20 December 2020 (UTC)I edited the sandbox convert to use the sandbox styles and have used subst so they continue to use the styles shown.
Please compare these two pages. The latter is working perfectly, thanks RexxS. Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst. Another weirdness is that I see a small vertical gap after the first "It's a long way to the next town." (that gap was always there but I couldn't see a reason for it). Johnuniq ( talk) 02:54, 20 December 2020 (UTC)
Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst.Indeed, this is expected; see Rexx. There is a way to work around it that is kind of a pain (setting the sandbox templatestyles invocation to add the attribute
wrapper=".sandbox"
as in <templatestyles src="Example/sandbox/styles.css" wrapper=".sandbox"/>
and then wrapping some content in the same page as your other case with the sandbox class). See
mw:Extension:TemplateStyles#Usage. --
Izno (
talk) 17:13, 20 December 2020 (UTC)How may I combine conversion, range, and adjective? For example, I am attempting to write "300-by-500-foot-wide (984 to 1641 m)." CapeVerdeWave ( talk) 17:26, 19 December 2020 (UTC)
{{convert|300|by|500|ft|m|adj=on}}
→ 300-by-500-foot (91 by 152 m)300-by-500-foot-wideeven means, much less how by + wide somehow become to. E Eng 05:32, 20 December 2020 (UTC)
{{convert|300|to|500|ft|m|adj=on}}
→ 300-to-500-foot (91 to 152 m){{convert|300|to|500|ft|m|adj=mid|-wide}}
→ 300-to-500-foot-wide (91 to 152 m){{convert|300|to|500|m|ft|adj=on}}
→ 300-to-500-metre (980 to 1,640 ft){{convert|300|to|500|m|ft|adj=mid|-wide}}
→ 300-to-500-metre-wide (980 to 1,640 ft)
Module:Convert/helper does some pre-Convert input cleanups. For this it also replaces, for example, ⁄
with /
: good. This simplifies later string handling jobs like search&replace, etc. See this code:
text = text:gsub(' ', ' '):gsub(' +', ' '):gsub(' *%+ *', '+'):gsub('⁄', '/'):gsub('⁄', '/')
. All fine so far.
Now Lua has a function that replaces these &...;
html entities (character id's), all in one go:
mw.text.decode. (which is available through
Module:DecodeEncode; by me; pre-alpha).
So I'd ask you to consider: could this be an improvement? Sure it's only efficiency & systematic completeness, not squashing a bug. And maybe the pre-apha status is to be looked at. - DePiep ( talk) 23:44, 25 December 2020 (UTC)
to  
and does not change ⁄
. I put a test at
Module:Sandbox/Johnuniq/temp—see results at
its talk where a mid dot (·) is used to replace each space.
Johnuniq (
talk) 01:29, 26 December 2020 (UTC)
With most large areas, I'm used to seeing acres "traditionally" paired with hectares. Lately, however, I've been seeing more and more instances paired with square kilometers instead. Has there been a consensus reached (or changed) regarding which unit acres should be paired with? I just wondered; I'm not sure if this is the best place to ask, but I also don't know where else that would be.
Are there situations where one unit or the other is preferred? Or are hectares now considered "archaic"? :)
Thanks! 1980fast ( talk) 02:19, 24 December 2020 (UTC)
acre
is ha
. For example, {{convert|123|acre}}
shows 123 acres (50 ha). Where do you see km2 (square kilometers)? There is no preference or consensus adjustment at this page, but it's possible that people in one region are used to ha while those somewhere else see km2.
Johnuniq (
talk) 02:55, 24 December 2020 (UTC)
{{convert|67000|acre|km2}}
with different numbers. An editor has chosen to specify that the output should show the km2 value by specifying km2
as the output unit. That choice is an editorial matter which is outside convert's scope. If the area is wanted in hectares, replace km2
with ha
or omit |km2
. People have outlined the factors involved in making a choice in this section. All converts concerning area in that article (there are seven of them) show the output in km2.
Johnuniq (
talk) 03:59, 28 December 2020 (UTC)The proper counterpart of the acre is the hectare. Hawkeye7 (discuss) 04:13, 24 December 2020 (UTC)
When I was a kid, the fields were typically measured in Morgen (2500 m2; unit symbol Mg); I reckon this is what the metric (not SI!) counterpart of an acre would be. However, everyone understands what a hectare is, and Morgen is only used in rural areas nowadays. Best regards, -- Johannes ( Talk) ( Contribs) ( Articles) 22:00, 26 December 2020 (UTC)
everyone understands what a hectare is", don't make assumptions. I cannot visualise what a hectare is, and either mentally dismiss it as "several acres" or else go and look for a conversion. A square kilometer on the other hand is slightly larger than 1⁄4 square mile which is good enough. In passing it does rather amuse me that the SI enthusiasts react with horror at any mention of non-metric customary units and yet plead intensely for metric but non-SI customary units! Think of a sentance including "sauce", "goose" and "gander". :-) Martin of Sheffield ( talk) 22:32, 26 December 2020 (UTC)
How about the priority of SI units and non-SI units?
What to do if a existing table uses the non-SI values and calculates them into SI units? --
Angerdan (
talk) 14:53, 1 January 2021 (UTC)
|order=flip
or |order=out
.
WP:UNITS says SI first is used for most articles, with exceptions for some US and UK articles.
Stepho
talk 22:53, 1 January 2021 (UTC)In the US modern engine volumes are often in liters or cubic centimeters, which are often converted to cubic inches, but it does not appear that either is a allowed conversion. Can this be added to the template?-- Sturmvogel 66 ( talk) 14:05, 26 December 2020 (UTC)
{{convert|1300|cc|cuin}}
→ 1,300 cubic centimetres (79 cu in){{convert|95|cuin|L}}
→ 95 cubic inches (1.56 L){{convert|44|L|cuin}}
→ 44 litres (2,700 cu in)|sp=us
for "liter" spelling if appropriate for article.
Johnuniq (
talk) 22:16, 26 December 2020 (UTC)
The text actually output from {{
convert}} has a space in cu in
, of course. It might be best to think about the units used in convert
as having three forms: the "unit name", the "unit symbol", and what you might consider a "unit code" that is used as a parameter in the template to represent that unit. These unit codes generally don't have spaces in them, even if the unit name or symbol does, because the space is used to separate multiple outputs. The three forms may be identical, similar, or different:
Unit code to use as parameter | Unit symbol | Unit name |
---|---|---|
acre | acre | acre |
L | L | litre (liter if |sp=us )
|
cuin | cu in | cubic inch |
For example, {{convert|2500|cm3|cuin L|abbr=on}}
→ 2,500 cm3 (150 cu in; 2.5 L) and {{convert|2500|cm3|cuin L|abbr=off}}
→ 2,500 cubic centimetres (150 cubic inches; 2.5 litres). The unit codes in those don't have spaces, even though the unit names and symbols may do. If your guess at the unit code produces an error, then removing any spaces often fixes it. --
RexxS (
talk) 00:31, 2 January 2021 (UTC)
…but why does a unit code even exist? I guess this only causes confusion (this is a perfect example) – I'd recommend making all possible unit symbols work as "unit codes" Johannes ( Talk) ( Contribs) ( Articles) 02:56, 2 January 2021 (UTC)
{{convert|10|km|mi nm nmi}}
→ 10 kilometres (6.2 mi; 1.0×1013 nm; 5.4 nmi). -
DePiep (
talk) 13:12, 2 January 2021 (UTC)Can the template handle such conversions? I saw an option for multiple dimensions, but it doesn't seem to go beyond two dimensions, so I can't quite visualize how to do it. Thanks! 1980fast ( talk) 03:20, 7 January 2021 (UTC)
{{convert|3|x|4|x|24|in}}
→ 3 by 4 by 24 inches (76 mm × 102 mm × 610 mm){{convert|3|x|4|to|6+1/2|x|8+3/4|in}}
→ 3 by 4 to 6+1⁄2 by 8+3⁄4 inches (76 mm × 102 mm to 165 mm × 222 mm)Is there a way to convert scientific notation with a confidence interval using this template? What I would like to get is
but the template gives me either
or
Perhaps it's just a bad idea to do unit conversion in this case, even the "right" answer is rather cumbersome. Tercer ( talk) 07:38, 21 January 2021 (UTC)
Is it possible to format the conversion such that there are no extra parentheses added? A use case for this would be a conversion done within an existing parenthetical statement.
For example, say that someone has just mentioned a mountain, followed by "(elev. xxxx feet)". What if you wanted the conversion to read "(elev. xxxx feet; xxx meters)" in order to avoid the messiness that comes with nested parentheses? Thanks! 1980fast ( talk) 21:45, 22 January 2021 (UTC)
(elev. {{convert|10|m|ft|disp=comma}})
→ (elev. 10 metres, 33 ft)I was looking at the page for Darigold, a dairy cooperative, and it mentions their annual production of milk – a staggering 8.6 billion pounds a year. The template used is a simple conversion to kilograms, however, the metric output is given in scientific notation, which isn't exactly accessible for the average reader. Is there any way to make both values output a conversion that is more directly comparable, perhaps with the numbers reformatted, like "8.6 billion pounds (3.9 billion kg)" ?
If that's not possible, is it at least possible to suppress the scientific notation? I'm not even sure how it came into play, since the input value is displayed without problem. Thanks! 1980fast ( talk) 07:25, 26 January 2021 (UTC)
abbr=unit
or abbr=off
. You need one of these to get the word million/billion for the output. Unfortunately you can't have "pounds" (name) and "kg" (symbol) and number words.
{{convert|8,600|e6lb|e6kg|abbr=unit}}
→ 8,600 million lb (3,900 million kg){{convert|8,600|e6lb|e6kg|abbr=off}}
→ 8,600 million pounds (3,900 million kilograms){{convert|8.6|e9lb|e9kg|abbr=unit}}
→ 8.6 billion lb (3.9 billion kg){{convert|8.6|e9lb|e9kg|abbr=off}}
→ 8.6 billion pounds (3.9 billion kilograms)For Iztapalapa#Elevation and climate could we have disp=/ and/or disp=s? eg ({{cvt|2,400|m|ft|disp=/}} asl) (2,400 m (7,900 ft) convert: invalid option asl) instead of ({{cvt|2,400|m|ft|disp=or}} asl) (2,400 m or 7,900 ft asl) Peter Horn User talk 22:08, 4 February 2021 (UTC)
I was wondering if there should be "earth pounds" which can be useful on pages such as moon. Cause pound and kilograms are different. Pound is weight and kilograms is mass. Pound per kilogram depends on the gravity force. The Channel of Random ( talk) 00:45, 13 February 2021 (UTC)
For Low Light of the Hook of Holland#History and elsewhere would it be possible to have (a) conversion(s)? say for example {{convert|2,000|cp|lm}}. Peter Horn User talk 16:58, 19 February 2021 (UTC)
11:32, 7 May 2019 Anthony Appleyard moved page Millimeter of mercury to Millimetre of mercury: Requested by Getsnoopy at WP:RM/TR: WP:COMMONALITY and because "metre" is standardised across WP — Preceding unsigned comment added by 2001:8a0:5e58:9a00:e992:745b:11c:c2cd ( talk • contribs) 20:43, 3 March 2021 (UTC)
{{convert|12|mmHg|abbr=off|lk=on}}
→ 12
millimetres of mercury (1.6
kilopascals)For Straight-six engine#Australia 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz). Would it be possible to have {{cvt|6,000|rpm|Hz|lk=on}} 6,000 rpm (100 Hz) & {{cvt|2,750|rpm|Hz|lk=on}} 2,750 rpm (45.8 Hz)? rpm Hz Peter Horn User talk 00:44, 9 March 2021 (UTC)
{{convert|1|rpm}}
→ 1 revolution per minute (0.017 Hz){{convert|12|rpm|Hz|abbr=on}}
→ 12 rpm (0.20 Hz){{convert|12|rpm|Hz|abbr=off}}
→ 12 revolutions per minute (0.20 hertz){{convert|6000|rpm|furlong}}
6,000 revolutions per minute (15,000 furlongs)Folks, we're too trusting! My first example above gave "1 revolution per minute (60 Hz)" which is total junk! Ouch. I'll look at whether this is due to my blunder with the scale or whether the tricky invert stuff actually doesn't work. Johnuniq ( talk) 01:13, 11 March 2021 (UTC)
{{cvt|6000|rpm|Hz|lk=on}}
is currently giving me: 6,000 rpm (360,000 Hz)
GliderMaven (
talk) 01:16, 11 March 2021 (UTC)
@
Peter Horn: Thanks for reporting the discrepancy but it was convert that was wrong—now corrected. By the way, when you see |disp=flip
it would be good if you were to change that to |order=flip
. One of the edits you made changed the first of the following to the second:
{{Convert|9120|cc|cuin|0|disp=flip}}
→ 557 cubic inches (9,120 cc){{Convert|9120|cc|cuin L|0|disp=flip}}
→ 557 cubic inches; 9 litres (9,120 cc)You probably don't want to flip it like that. If you want both cuin and L with L as the input, you need:
{{cvt|9120|cc|L cc cuin|0|order=out}}
→ 9 L (9,120 cc; 557 cu in)Also, please have a look at
Straight-six engine#Displacement range which is showing L
as the second paragraph. It looks like a stray character was inserted.
Johnuniq (
talk) 02:28, 11 March 2021 (UTC)
Can the same conversion be mentioned twice or more in an article, or should this generally be avoided? Kind regards, Willbb234 Talk (please {{ ping}} me in replies) 23:15, 10 March 2021 (UTC)
touchtennis#Court originally had the sentence
However, variances of up to a metre are tolerated…
The convert template let me change it to
However, variances of up to 1 metre (3 ft 3 in) are tolerated…
but I think the original (with conversion) reads better:
However, variances of up to a metre (3 ft 3 in) are tolerated…
Is there an option to use "a"?
Thanks,
cmɢʟee⎆
τaʟκ 21:48, 17 March 2021 (UTC)
Editing this talk is now showing a ghastly edit notice from Template:Editnotices/Page/Template talk:Convert which contains {{ Wikipedia information pages talk page editnotice}}. The previous version was also not very helpful. Any suggestions on wording to fix it? Johnuniq ( talk) 08:51, 18 March 2021 (UTC)
It's just straight up wrong. I have noticed it in an article, Joe Biden may well be 6" tall but that is not 2 metres. I'm just under 6" 2" and I'm 1.85m.
The example given is also wrong, 124" is 37.7m, not 40m. If this has been standardised across all articles then all these conversions are wrong, plain and simple.
Who does one get this rectified? Stefanzi ( talk) 07:29, 18 March 2021 (UTC)
{{convert|5|ft|11+1/2|in|abbr=off|sp=us|cm|0}}
→ 5 feet 11+1⁄2 inches (182 centimeters){{convert|6|ft|0|in|abbr=off|sp=us||0}}
→ 6 feet 0 inches (2 meters)0
" in |0}}
tells convert to round the result to zero decimal places. No output unit was given (because the recent edits removed cm
) and convert used its default for that which is m
. The result was bad rounding due to bad parameters.
Johnuniq (
talk) 08:45, 18 March 2021 (UTC)
{{convert|6|ft|abbr=off|sp=us||2}}
(giving 6 feet (1.83 meters) or not removed the "cm". --
John Maynard Friedman (
talk) 12:38, 20 March 2021 (UTC)I found an article that said a plant's density is "commonly 30 species/m2".
I changed that to :*{{cvt|30|/sqm}}
which results in "commonly 30/m2 (2.8/sq ft)"
It would be clearer if it could still include "species", similar to the way PD/sqkm generates "inhabitants". What about a parameter to override "inhabitants" with another name? I'm sure the text could be just be rewritten in this case, but the existing language seems most succinct. (There is currently no pd/sqm, so that would need to be added also).
On more thing, although /sqm works, I don't see it in the documentation (/sqcm, /sqkm, /sqha, /sqin, /sqacre, /sqmi are all there). MB 16:28, 21 March 2021 (UTC)
{{cvt|30|/m2||disp=preunit|species}}
→ 30 species/m2 (2.8 species/sq ft)/sqm
works is that the unit sqm
is an alias for m2
and convert automatically handles "per" units if it can.
Johnuniq (
talk) 23:08, 21 March 2021 (UTC)
/sqm
and m2
seem to be missing. I'm not clear if you mean that this list is supposed to be complete or not.
MB 23:36, 21 March 2021 (UTC)
Parameter list for |abbr values in and out should list in the description that they are used for "input" and "output" units, respectively, for clarity (i.e. "Use symbol for first (left-hand side) unit (input unit)"). Any other parameters using these identical values should likewise be updated as well. Kehkou ( talk) 06:04, 29 March 2021 (UTC)
|order=flip
and |order=out
is used{{convert|100|mph|km/h|0|abbr=in}}
|
→ | 100 mph (161 kilometres per hour) |
{{convert|100|mph|km/h|0|abbr=in|order=flip}}
|
→ | 161 km/h (100 miles per hour) |
{{convert|100|mph|km/h m/h mph|0|abbr=in}}
|
→ | 100 mph (161 kilometres per hour; 160,934 metres per hour; 100 miles per hour) |
{{convert|100|mph|km/h m/h mph|0|abbr=in|order=out}}
|
→ | 161 km/h (160,934 metres per hour; 100 miles per hour) |
{{convert|100|mph|km/h m/h mph|0|abbr=out|order=out}}
|
→ | 161 kilometres per hour (160,934 m/h; 100 mph) |
For Nevada Northern Railway, how would one convert 40 million net ton-miles to net tonne-kilometers? Peter Horn User talk 13:28, 13 April 2021 (UTC)
With:
(million net ton-miles)
(million net tonne-kilometres)
(Mass of a ton in 10³ kg)
(Length of a mile in 10³ m)
Then:
Best regards, -- Johannes ( Talk) ( Contribs) ( Articles) 15:42, 13 April 2021 (UTC)
{{convert|40|e6ton-mile|e6tkm}}
→ 40 million ton-miles (58×10 6 tkm){{convert|40|e6ton-mile|e6tkm|abbr=off}}
→ 40 million ton-miles (58 million tonne-kilometres)"Learning" editor here! I am pretty sure the "adj" parameter is missing from the parameter list and that all its possible values are incorrectly included in the "abbr" section. I am pretty sure I know how to fix it (I messed around in my sandbox), but I've never edited a template doc or done much work with a wikitable before. Can someone more experienced either tell me it's ok to attempt a fix, fix it themselves, or tell me I'm wrong? Thanks in advance! Firefangledfeathers ( talk) 02:46, 12 April 2021 (UTC)
@ DePiep: Just a question – why would anybody want to sort the table by parameter value? And it doesn't effect the reader's ability to search for whatever they like, unless your web browser's search function is stuck in 'whole words only' mode. WT79 ( speak to me | editing patterns | what I been doing) 18:17, 13 April 2021 (UTC)
{{convert|100|ft|m|adj=mid|-deep}}
, then I want to look up what "|adj=mid|-deep
" means. I can see it is two parameters, and can guess what the final one is for because I saw it rendered in the article, Therefore what I'd search for would be "|adj=mid
". Since the parameter
column includes both parameter and value (due to a recent edit linked above) it doesn't make sense to have the values listed separately as well.
WT79 (
speak to me |
editing patterns |
what I been doing) 16:37, 14 April 2021 (UTC)There was recently an RFC that changed MOS:UNITSYMBOLS to require "L" for liter when standalone. (That is to say, "ml" for example is still accepted, though "mL" is allowed.) Presumably this template/module should be changed to output "L" in all standalone cases, including when the input unit is "l". For example, {{convert|123|impgal}} now-incorrectly renders as "123 imperial gallons (560 l; 148 US gal)". -- Beland ( talk) 03:49, 26 April 2021 (UTC)
Is it already possible to use lboz/
as a per unit? Or is that easily added? For example instead of {{convert|235|kg/ha|lb/acre|frac=16}}
in
[9].
Invasive Spices (
talk) 17:47, 29 April 2021 (UTC)
Total pounds of Atrazine applied must not exceed 2lb 8oz/acre per year., the ounces are vital. Invasive Spices ( talk) 19:10, 30 April 2021 (UTC)
This is unusual and rarely comes up, but I just saw something where PD/kg would be needed. I wanted to use {{convert||PD/kg|PD/lb}}, but no such units. You can see it by my <!--- ---> comment in
this edit. Thanks for working on this stuff.
Invasive Spices (
talk) 21:03, 3 May 2021 (UTC)
/kg
by itself wasn't listed in
Module:Convert/documentation/conversion data/doc so I never thought to try it.)
Invasive Spices (
talk) 15:28, 4 May 2021 (UTC)Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
{{convert|1+1/2|by|5+3/4|in}}
).titles
table.gramme
from the
unit definitions. This is not a change to units as gramme
is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future.
MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at
MOS talk July 2019 following a request
here.g0-force
added and unit g0
has symbol g0 with the 0 no longer in italics (
discussion).mi/kWh
is retained in extra; it will be removed if not found to be used in articles.scf2
and scfoot2
in articles will be replaced with scf
and scfoot
which have had their link corrected to
standard cubic foot (
discussion).mmHg
changed to
Millimetre of mercury with re not er spelling (
discussion).rpm
(
discussion).tkm
and ton-mile
(
discussion).mw.wikibase.getLabel(X)
instead of deprecated mw.wikibase.label(X)
.Release notes for earlier versions are listed here. Johnuniq ( talk) 01:16, 4 May 2021 (UTC)
@ Izno: Having convert use {{ fraction}} and {{ sfrac}} templatestyles was discussed in December 2020:
Part of that involved a demonstration that the vertical spacing was a problem:
{{convert/sandbox|1+2/3|ft|in}}
→ 1+2⁄3 feet (20 in) (uses
Template:Fraction/styles.css){{convert/sandbox|1+2/3|ft|in|test=stylesandbox}}
→ 1+2⁄3 feet (20 in) (uses
Template:Fraction/sandbox/styles.css)The vertical spacing problem was fixed by RexxS in Template:Fraction/sandbox/styles.css. However the fix was not used for {{fraction}}. What should convert do? That is, should convert not use templatestyles? Or, should it use the fraction style and ignore the vertical spacing problem? Or, should the style be tweaked somehow? Johnuniq ( talk) 04:38, 14 April 2021 (UTC)
add_style
, and to add an implementation for Sfrac having separate styles, where necessary.
Izno (
talk) 20:37, 27 April 2021 (UTC)
{{convert/sandbox|1+2/3|ft|in}}
→ 1+2⁄3 feet (20 in) (fraction style){{convert/sandbox|1+2//3|ft|in}}
→ 1+2/3 feet (20 in) (sfrac style){{convert/sandbox|18+1/2|in|ft|frac=-2}}
→ 18+1⁄2 inches (1+1/2 ft) (both!)Hi all, After a conversation last month with @ Colonies Chris:, I have started to use the convert template for windspeeds with the following configuration: {{convert|125|kn|km/h mph|round=5|disp=out}} , however, I noticed earlier that the template is not putting the output in brackets 230 km/h; 145 mph. Is there a way to ensure that the output goes into brackets? If so then I strongly suspect that the long running issues that the tropical cyclone project, has had with using the template for windspeeds might be over. Jason Rees ( talk) 02:41, 6 May 2021 (UTC)
{{convert|125|kn|km/h mph|round=5|disp=out}}
→ 230 km/h; 145 mph{{convert|125|kn|km/h mph|round=5|abbr=on|order=out}}
→ 230 km/h (145 mph)Why, when using disp=or
, is unit abbreviation an all-or-nothing proposition?
If I want the otherwise default behavior of "x inches or y mm", it seems that's not currently possible.
Instead, either both units are spelled, or both units are abbreviated, with the addition of abbr=on
. That behavior seems incredibly inconsistent. Thanks for any clarification!
1980fast (
talk) 04:04, 7 May 2021 (UTC)
disp=or
, the default is abbr=off. However abbr can also be specified as in
or out
.
{{convert|7|in|mm|abbr=out|disp=or}}
→ 7 inches or 180 mm
Sacramento, California#2010 census 4,660.0 people per square mile (1,799.2/km2) How was this calculated? It does not appear to be done by template convert.
{{convert|4,660.0|people/square mile}}
4,660.0 people/square mile
convert: unknown unit {{convert|4,660.0|density/square mile}}
4,660.0 density/square mile
convert: unknown unit
Peter Horn
User talk 23:38, 15 May 2021 (UTC)
Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
acre foot
+ acre feet
+ Nm
+ mN.m
.dtex
.A/m
+ kA/m
+ MA/m
.lb-mol
+ lbmol
+ lb-mol/d
+ lb-mol/h
+ lb-mol/min
+ lb-mol/s
+ lbmol/d
+ lbmol/h
+ lbmol/min
+ lbmol/s
.qtr
+ long qtr
.short qtr
.sqperch
.cuft/min
.cuyd/h
.ksi
+ psf
+ psi
.lbf/in2
.Release notes for earlier versions are listed here. Johnuniq ( talk) 03:27, 3 June 2021 (UTC)
I've come across a little grammar/definition problem while updating streamflow data in a river article.
The way I understand it, the unit acre-foot is spelled with a hyphen because it's defined by the product of an acre and a foot of thickness, just as the kilowatt-hour is the energy produced by one kilowatt of power for one hour.
So shouldn't {{
convert}}
display acre-feet
rather than acre feet
?
Let me add that I found a relevant discussion on this talk page from 2011,
Template_talk:Convert/Archive_September_2011#acre_foot. It appears that either no change was made to {{
convert}}
following that discussion, or that some possible helpful feature was eliminated.
Please forgive me if I am wrong or there already is some feature to display acre-feet
. If so, I would like to know.
--
Jsayre64
(talk) 02:35, 18 May 2021 (UTC)
acre⋅ft
as the symbol and acre foot
as the unit link and singular name. The two "foot" units have acre foot
as the plural name while the other units give acre feet
. What's needed is that the link and names are hyphenated. Thanks for reporting. The change will happen in due course but some thought about any other unit adjustments is needed first.
Johnuniq (
talk) 03:42, 18 May 2021 (UTC)|abbr=on}}
is an okay workaround method in the case of acre-feet, but even so, that dot indicating multiplication looks quite small to me.
Jsayre64
(talk) 20:41, 18 May 2021 (UTC)I have fixed many unit links in the sandbox (and have more to do). The fixed units include these:
{{convert/sandbox|1|acre-foot|lk=in}}
→ 1
acre-foot (1,200 m3){{convert/sandbox|1|acre-ft|lk=in}}
→ 1
acre-foot (1,200 m3){{convert/sandbox|2|acre-foot|lk=in}}
→ 2
acre-foot (2,500 m3){{convert/sandbox|2|acre-ft|lk=in}}
→ 2
acre-feet (2,500 m3)These are aliases for acre-foot
: acre foot
+ acre.foot
These are aliases for acre-ft
: acre feet
+ acre-feet
+ acre ft
+ acre.ft
+ acre·ft
Johnuniq (
talk) 10:19, 19 May 2021 (UTC)
{{convert/sandbox
in an article though?
Jsayre64
(talk) 17:41, 19 May 2021 (UTC)
Convert defines symbol Å and name ångström and link ångström for this unit. However I see the unit is now at Angstrom and energetic discussions at Talk:Angstrom assert that angstrom is the correct name. The article mentions the IUPAC Gold Book which says ångström (and searching for "angstrom" redirects to that page). I assume the official name has the diacrits and there is no need to change convert's name or link? Johnuniq ( talk) 07:48, 19 May 2021 (UTC)
Please add a conversion for Lakh, which is used in many citations from India. - Guy Macon ( talk) 12:18, 24 May 2021 (UTC)
400 [[lakh]] ({{lakh|400}})
= 400
lakh (40,000,000)400 [[crore]] ({{crore|400}})
= 400
crore (4,000,000,000)400 [[lakh crore]] ({{lakh crore|400}})
= 400
lakh crore ({{lakh crore|400}}){{cvt|400|mi|ft}}
= 400 mi (2,100,000 ft){{lakh|400}}
and it would display "40,000,000" which would be appropriate for the English Wikipedia. The fact that the reference said "400 lakh" does not need to be mentioned, per
WP:CALC, I think, although the lakh template would be used to allow easy verification.
Johnuniq (
talk) 05:02, 25 May 2021 (UTC)
In conversions such as {{convert|30|lt|MT}}, which renders as 30 long tons (30 t), I would like to have "tonnes" displayed instead of t: 30 long tons (30 tonnes). Can this be done? Cheers, Simon – SCHolar44 🇦🇺 💬 at 02:04, 9 June 2021 (UTC)
{{convert|30|lt|tonne|abbr=off}}
→ 30 long tons (30 tonnes){{convert|30|lt|tonne|2|abbr=off}}
→ 30 long tons (30.48 tonnes){{convert|30|lt|18|Lcwt|2|qtr|tonne|abbr=off}}
→ 30 long tons 18 hundredweight 2 quarters (31.42 tonnes)A way to convert hoppus to cubic feet and cubic metres. Peter Horn User talk 01:09, 12 May 2021 (UTC)
board feet
and board foot
exist. The difference is that the first give "board feet" as the plural name while the second is always "board foot".
{{convert|12|board feet}}
→ 12 board feet (0.028 m3){{cvt|12|bdft|lk=in}}
12
bd ft (0.028 m3)
Peter Horn
User talk 20:40, 12 May 2021 (UTC)
bdft
also exists and works as shown in your above comment.
Johnuniq (
talk) 02:07, 13 May 2021 (UTC)
Quick question - is there a way to convert from fraction of the speed of light to more conventional speed units? I note that {{
val}} recognizes "0.1
c0", but I haven't figured out a way to feed this into convert. This came up in an edit where a paper specified a speed in terms of fraction of speed of light, and an editor translated 10% of c into 30,000 kps/18,628.2 mps
which was wrong on several levels. After reverting (it turns out they misread the article), I also pointed to the convert template, suggesting that in the future they should use the units specified by their source and {{
convert}} to units they think are necessary. But articles in physics often do specify speeds in terms of "c", and that may be an issue. Is there an obvious way to handle this that I missed?
Tarl N. (
discuss) 05:17, 12 June 2021 (UTC)
I've noticed there is a slight inconsistency in how the template handles composite units featuring US/imperial gallons, which isn't really ideal in terms of disambiguation. I'll give some examples to illustrate the problem. With standalone volume units we observe the expected and desired behaviour:
but with composite units (such as volume per unit time):
You see: the composite units featuring the US gallon omit the disambiguating "US", so if this occurs in isolation, a reader will be unaware which gallon is meant (without relying on contextual information to disambiguate, which is not desirable). Is this a known issue? Archon 2488 ( talk) 20:01, 18 June 2021 (UTC)
{{convert|100|USgal/h}}
→ 100 gallons per hour (0.38 m3/h){{convert|100|U.S.gal/h}}
→ 100 gallons per hour (0.38 m3/h){{convert|100|USgal/h|lk=in}}
→ 100
US
gallons per hour (0.38 m3/h){{convert|100|U.S.gal/h|lk=in}}
→ 100
U.S.
gallons per hour (0.38 m3/h)+
and *
in the definitions). By contrast, the unit usgal/h
is not defined so convert handles it automatically as a "per" unit:
{{convert|100|usgal/h}}
→ 100 US gallons per hour (110 L/ks)USgal/h
was added to the template implementation of convert in
September 2009 and was copied by the module implementation in December 2013. Some significant refactoring could occur now after checking all similar units and having at least a brief look at how they are used in articles.
Johnuniq (
talk) 00:03, 19 June 2021 (UTC)OK, a different question related to the above: {{convert|100|usgal/h}}
→ 100 US gallons per hour (110 L/ks). What kind of unit is l/ks? Are there SI rules about prefixes in the denominator? Maybe ml/s would be better?
Gah4 (
talk) 00:26, 19 June 2021 (UTC)
usgal/h
so convert does an automatic conversion. Since the example did not provide an output unit, convert did all it could, namely it used the default output for usgal
(l impgal) and the default output for h
(ks). The default output unit is then constructed from (l impgal)/ks but since that doesn't make sense, convert uses the first unit (l) to conclude that the default output is l/ks
. The fix is to specify whatever unit is wanted for the output. That is, it is not a good idea to rely on the default output for automatic units.
Johnuniq (
talk) 02:29, 19 June 2021 (UTC)Using the Visual Editor, I was adding a garden-variety conversion from feet to meters using {{convert}}.
Clicking on the conversion after I made it (almost by accident), I happened to notice that the input value doesn't have a non-breaking space between the value and the unit, whereas the output value does. As you might already know, when you use the Visual Editor and click on a conversion, non-breaking spaces are shown by faint gray vertical bars.
I then found another (existing) feet-to-meters conversion on the same page, that happened to use {{cvt}}. I noticed that both the input and output values did have non-breaking spaces between the values and units.
Note that I say this happens "in some situations" because I also happened to notice that there seems to be no difference in behavior between the two templates when the conversion is from Fahrenheit to Celsius, for example. Both show non-breaking spaces between values and units, as they should. I discovered this by clicking around to various conversions just trying to get a sense of what was going on.
Thanks! 1980fast ( talk) 04:50, 20 June 2021 (UTC)
"It sold for 50 cents per one pound (0.45 kg)...." gives an undesirable result. What is needed is "It sold for 50 cents per pound...", but with the conversion to kg still shown. Is there a way of doing that? ThoughtIdRetired ( talk) 13:21, 28 June 2021 (UTC)
50 cents per pound ({{convert|1|lb|disp=out}})
-
DePiep (
talk) 17:00, 28 June 2021 (UTC)({{convert|50|$/lb|$=cent|disp=out}})
→ (110 ¢/kg) -
DePiep (
talk) 17:07, 28 June 2021 (UTC)
{{convert|50|¢/lb}}
could just be used to get "It sold for 50 cents per pound (110 ¢/kg))".There are two options already given with respect to abbr=unit
and abbr=off
when using an e6
prefix.
But what if you want something like:
100 million miles (160 million km)
...in order to mirror the default unit abbreviation behavior seen in other conversions?
Thanks! 1980fast ( talk) 20:05, 10 June 2021 (UTC)
{{convert|100|e6mile|e6km|abbr=unit}}
→ 100 million mi (160 million km)mile
or miles
as the input and currently they are aliases for mi
. I don't think adding yet another option is worthwhile so the alternative would be to either add a new unit or change the existing mile/miles so that the name is never abbreviated. That would need thought...
Johnuniq (
talk) 00:55, 11 June 2021 (UTC)
Mile
as the unit code for a miles unit which never abbreviates. Thoughts?
Johnuniq (
talk) 23:45, 19 June 2021 (UTC)
|abbr=in
to get km (miles). I would welcome a non-abbreviating alternative.
Stepho
talk 01:04, 20 June 2021 (UTC)
I overcame my inertia and added Mile
as a test:
{{convert|1|Mile}}
→ 1 Mile
convert: unknown unit{{convert|15|Mile|abbr=on}}
→ 15 Mile
convert: unknown unit{{convert|100|e6Mile|e6km|abbr=unit}}
→ 100 e6Mile
convert: unknown unit@ 1980fast: You might like to try this. Johnuniq ( talk) 01:30, 20 June 2021 (UTC)
From the 20 April 2021 dump of all articles, there were about 1460 unique {{
convert}} and 210 unique {{
cvt}} which used input unit mile
or miles
yet output mi
. Examples:
{{convert|93|mile|km|abbr=on}}
→ 93 mi (150 km){{convert|1.3|km|miles|adj=on}}
→ 1.3-kilometre (0.81 mi){{cvt|90|miles}}
→ 90 mi (140 km)As discussed above, displaying "mi" is rarely helpful compared with "miles"—the saving of space is inconsequential and it's likely that many readers who would understand miles would be puzzled by mi. Scientific topics (which might want units abbreviated) would rarely use miles. Why would an editor type mile
or miles
in a convert template if they want readers to see mi
? Changing mile/miles so the units never abbreviate would give the very natural result that miles would display miles and mi (if abbreviated) would display mi. In the unique converts, 93,500 use mi and 4,400 use mile or miles. Thoughts?
Johnuniq (
talk) 07:50, 29 June 2021 (UTC)
At
List of longest buildings#World there is a need to add the conversion for "3000+ m". The best I've found is {{convert|3000|m|ft|disp=table|sortable=on|adj=pre|+}}
but that shows only the + only in the first column:
m | ft |
---|---|
3,000+ | 9,800 |
Is there a way to get the + into both columns? Thryduulf ( talk) 20:07, 18 July 2021 (UTC)
>{{convert|3000|m|ft|disp=table|sortable=on}}
does not show the prefixed gt symbol at all?!m | ft |
---|---|
3,000 | 9,800 |
m | ft |
---|---|
3,000+ | 9,800+ |
Infoboxes are narrow and reading lists of items should be able to display as verticle lists or as a • bullet list.
Only the first conversion has a line break there should be a way to output as a list in a infobox.
disp=bl disp=li
? @ Mkouklis(2): This relates to Dixie Fire. You could use the following.
{{#invoke:string|replace|{{convert|192,849|acre|sqmi ha e6sqft|0|abbr=off|disp=br}}|; |<br>}}
→or
{{#invoke:string|replace|{{convert|192,849|acre|sqmi ha e6sqft|-1|abbr=on|disp=br}}|; |<br>}}
→Johnuniq ( talk) 07:22, 27 July 2021 (UTC)
I have 2 references that put a car's weight at 3559 lb (US) and 1580 kg (Australia). Is there a simple way to put this as a range so that it looks something like "1580-1614 kg (3,483-3,559 lb)" ? Stepho talk 10:28, 10 August 2021 (UTC)
Example: 100 t (98 long tons; 110 short tons) Could we have the output abbreviated as ltons and stons or even Ltons and Stons instead? Peter Horn User talk 00:33, 7 September 2021 (UTC)
lt
gives LT as a symbol but for some reason lost in history, there is no way to abbreviate ST. If there is not enough room for "long tons" and "short tons", consider omitting the convert altogether—does it really matter what the exact number of tons is? At any rate, it would not be desirable for us to invent abbreviations that are not widely recognized.
Johnuniq (
talk) 00:54, 7 September 2021 (UTC)For Dedicated Freight Corridor Corporation of India#Need for DFC 110 crore tonnes → {{cvt|110|crt|LT ST|lk=on}} 110 crt convert: unknown unit instead of (110,000,000 t [108,300,000 long tons; 121,300,000 short tons]) Peter Horn User talk 19:09, 6 September 2021 (UTC) Peter Horn User talk 19:12, 6 September 2021 (UTC) Peter Horn User talk 19:16, 6 September 2021 (UTC) Peter Horn User talk 19:29, 6 September 2021 (UTC)
{{convert|1.1|e9tonne|e9LT e9ST|sigfig=3|abbr=off}}
→ 1.1 billion tonnes (1.08 billion long tons; 1.21 billion short tons)Not sure where it would be best to mention this. Have noticed increasing use of the term "ton" to mean a metric ton (1000 kg), whereas the convert template spells it "tonne" for the metric ton, rather than the old US meaning of "ton" 1 ton = 1 short ton = 2000 lbs, or the former UK meaning 1 ton = 1 long ton.
SpaceX has been doing this for some time, and recently have seen Tesla doing this as well. Example, Tesla in their 2020 Tesla Impact Report says: "In the E.U., electric semi trucks are allowed to be 2 tons (~4,400 pounds) heavier than diesel equivalents, and in the U.S. the allowance is 0.9 tons (2,000 pounds)." (page 24)
The {convert} template seems to only use the full spelling of "tonne" for the spelled out units of the metric ton. I'm curious to know if there is a way to make the metric ton be spelled "ton" using the convert template, rather then "tonne"? Or how we might go about considering making changes in {convert} for spelling conventions that change over many years. Cheers. N2e ( talk) 11:06, 21 August 2021 (UTC)
|sp=us
.unitcode scale link default symbol name1 name1_us 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 ST 907.18474 Short ton t ~short ton short ton shtn 907.18474 Short ton t sh tn short ton shton 907.18474 Ton t ~ton ton LT 1016.0469088 Long ton t ~long ton long ton lt 1016.0469088 Long ton t LT long ton
ton
as an input ({{convert|1|ton}}
gives an error). As an output, "ton" can only occur with the unit shton. There are about 14 converts using shton in articles, examples:
{{convert|493|shton}}
→ 493 tons (447 t){{Convert|1|shton|kg}}
→ 1 ton (910 kg)ton
as an input. When I listen to US news media, I often hear "metric ton", so I infer that ton still means 2000 pounds in general US usage.ton
may not give a clue which is intended: I agree. Have seen that too. But that is a problem with a source to be resolved at the article level (or possibly with some input from a WikiProject on how the term is used in a particular industry.)ton
is used in a source, then what the source must mean is 'shton'. If the editor uses ton
= 'shton' via our template when the source is unclear, as many are in the 2020s, then we are furthering the misunderstanding, when the source was unclear in the first place.
N2e (
talk) 11:54, 24 August 2021 (UTC)
I was editing an article and realised Mach speed conversion is not supported. It is very common in aviation & aeronautics. Example: 15,345 miles per hour (24,695 km/h; Mach 20) would yield 15,345 mph (24,695 km/h; Mach 20) Crnorizec ( talk) 19:46, 7 September 2021 (UTC)
Just wondering, since the speed of sound varies with temperature, and fast jets normally fly at higher (cooler) altitude, which speed does it use? Gah4 ( talk) 22:11, 7 September 2021 (UTC)
{{convert|20|Mach}}
→ Mach 20 (24,500 km/h; 15,200 mph){{convert|20|Mach|mph km/h}}
→ Mach 20 (15,200 mph; 24,500 km/h){{convert|20|Mach|0|mph km/h}}
→ Mach 20 (15,200 mph; 24,500 km/h){{convert|20|Mach|50,000|mph km/h}}
→ Mach 20 (13,200 mph; 21,200 km/h)In April 2021, the Mach unit appeared in 101 {{ cvt}} and 245 {{ convert}} = 346 total. That is a reasonably small number so it would be possible to change convert by:
|altitude=
so the altitude could be specified for input and output.I'll slowly see what would be involved in the module. Johnuniq ( talk) 01:33, 12 October 2021 (UTC)
@ Gciriani: The problem you are reporting is that at Blue Origin a source ( example) might say "top speed of Mach 3" and an editor then puts {{cvt|3|Mach}} in the article without knowing that an altitude is required for the conversion to make sense. The source does not specify the altitude so a conversion is not possible without a bunch of original research, or a better source which does the conversion. They use "Mach 3" to mean "very fast" and the exact speed in km/h is not really the point. However, it will be an ongoing problem because wikignomes will return to that article every year and insert conversions.
Re convert, it uses the table from aerospaceweb.org although the website's table goes to 400,000 feet while convert's table stops at 300,000 feet (anything over that altitude is truncated to 300,000). I could extend the table and fix some other issues. Are you saying that using aerospaceweb's table with a mandatory altitude would be sufficient (although it wouldn't help at Blue Origin where the altitude is unknown)? Johnuniq ( talk) 01:07, 15 October 2021 (UTC)
I agree with John that temperatures are rarely given in sources - therefore any arguments requiring temperatures are a moot point in spite of being technically correct.
It would be very unusual for an aircraft going fast enough to be measured in Mach numbers to be at sea level. From the graph above, 10-20 km altitude seems to have a reasonably constant speed of sound, with only small deviations up to 30 km. 10-30 km is also where the majority of fast airplanes will be operating. I suggest we change the formula to use a default of 20 km altitude. In that way, conversions where no altitude is given are likely to be more accurate - at least to the level of precision suitable for a general audience. Worse case is for an altitude of 50 km giving an error of 10% (330 m/s vs 295 m/s). Since the conversion to km/h or mph is more of a general indication of a jet fighter doing 3000 km/h vs an airliner doing 1000 km/h, then this should be suitable. Luckily for us, the extreme cases (eg, jet fighters, record breakers) also tend to give altitude in the references, so we can be a bit more accurate anyway in those cases. Stepho talk 00:35, 16 October 2021 (UTC)
I put a list of all 153 unique converts in articles from April 2021 where Mach is used with an altitude in my sandbox ( permalink). I'm interested in far too many things and don't have time to examine the details of how Mach works. The issue for this page concerns what should happen with the Mach unit as far as convert is concerned. I'm inclined to think there should be no default altitude—omitting the altitude should result in an error—because it appears the value is meaningless without an altitude (or preferably, according to above, a temperature which is never going to happen). Are any of the values shown in the sandbox significantly wrong? What should convert do? Johnuniq ( talk) 06:53, 16 October 2021 (UTC)
I had a look at this page and had the typical frustration of the SI influenced engineer: tonnes are non-SI. But for some reason Wikipedia's convert function assumes that SI only goes up to kg, which is clearly incorrect. SI also has an equivalent for the tonne, the megagram (Mg). There also is the Gg for ships for instance. How can I lobby for the convert{} function to be adapted accordingly? — Preceding unsigned comment added by Lordarpad ( talk • contribs) 23:19, 16 October 2021 (UTC)
Mg
(and all other SI variations) works, but as Stepho-wrs says, using Mg would rarely be helpful because Wikipedia is supposed to be for general readers, not just engineering types who would recognize that unit.
Johnuniq (
talk) 02:36, 17 October 2021 (UTC)Infoboxes that automatically convert data retrieved with {{
PH wikidata|elevation_m}}
can't handle cases when WD has multiple values for this field. I really don't see how this has anything to do with {{
convert}}
. Since it would be wrong to do anything like arbitrarily uses the first value, or use an average, I think this problem lies at the source in WD. See
User talk:Mike Peel#Wikidata question for the background.
MB 20:37, 25 October 2021 (UTC)
{{convert|input=P2044|3=m|disp=number}}
, a preview will show that it retrieves the value you fixed at Wikidata. I forget what happens if there is more than one value, but it's probably not helpful. A difficulty is that I despise the model used for Wikidata—in brief, it's write-only data with no thought given for how a program could extract useful information and no promises about the future except that things will break.
Johnuniq (
talk) 02:58, 26 October 2021 (UTC)
I've finished investigating and the problems can be fixed now if you like (the fix would be to remove one of the duplicate elevation values in Wikidata). At Santo Tomas, Isabela, the infobox has
| elevation_m = {{PH wikidata|elevation_m}}
The result from {{PH wikidata|elevation_m}}
is the output from the following (this uses fixed wikitext to show what happens now):
{{convert|input=P2044|3=m|disp=number}}
→ 30, 33
{{
Infobox settlement}} then does its own calculation and tries to use 30, 33
as a single value. I haven't examined that code but it understandably fails. From my point of view, convert is working as advertised, and no doubt the Wikidata people would say the same, as would the infobox people. Not our problem. In principle there could be a new parameter to tell convert to return only the first value but I would be reluctant to bolt on another Wikidata band-aid. The reason convert is being used is that the Wikidata entry could specify the elevation in another unit, say feet. Convert would return that converted to metres.
Johnuniq (
talk) 09:30, 26 October 2021 (UTC)
|rank=
: the
WD-rank of a single property value can be "preferred", and selection by this would reduce the number of returned values (though WD does not limit Preferred to a single value).{{
infobox settlement}}
detect multiple values in the field, not display anything, and put the article in
Category:Articles using infobox settlement with invalid elevation data.
MB 01:20, 28 October 2021 (UTC)
Does convert handle rack units? It's a unit of length equal to 1.75 inches, commonly used in the electronics and computer industries. See Special:Diff/1052328533 for an example. -- RoySmith (talk) 15:42, 28 October 2021 (UTC)
I just noticed the template supports and(-) and to(-) as options (to display a range of / multiple values differently in the primary vs secondary) but not or(-). Is there a reason for this? Would it be straightforward to add it? Archon 2488 ( talk) 20:21, 6 November 2021 (UTC)
or(-)
mean to say, in {{Convert}} context? Did you meet it in an article or in a source? -
DePiep (
talk) 20:32, 6 November 2021 (UTC)It could be added but I'm not sure it would be useful. Per DePiep, is there somewhere this would help? For reference, the following shows examples. The last one (or(-)
) is not implemented and the output is simulated wikitext.
{{convert|12|to|18|kg}}
→ 12 to 18 kilograms (26 to 40 lb){{convert|12|and|18|kg}}
→ 12 and 18 kilograms (26 and 40 lb){{convert|12|or|18|kg}}
→ 12 or 18 kilograms (26 or 40 lb){{convert|12|to(-)|18|kg}}
→ 12 to 18 kilograms (26–40 lb){{convert|12|and(-)|18|kg}}
→ 12 and 18 kilograms (26–40 lb){{convert|12|or(-)|18|kg}}
→ 12 or 18 kilograms (26–40 lb)Johnuniq ( talk) 00:22, 7 November 2021 (UTC)
We need a Helper function that can read & feed regular source-&-keyboard value inputs for {{Convert}}.
IMO it is useful in an Infobox template (backoffice) that has like |height=
. So: the template editor uses it, and the article editor can enter simple and natural entries. For example, {{
Infobox person}} has |height=
, but with many prescriptions. Why not expect & parse simple |height=1.74m
and |height=5ft6 in
?
Many & most input for {{Convert}} is basic the quantity value: number × unit. (Allow me: ranges, sigfig input : sure, later more).
There is a discussion at Wikipedia talk:Manual of Style/Dates and numbers#Evidence? which includes the suggestion that {{ Convert}} support US liq pt and US liq qt (for US liquid pint and US liquid quart) rather than US pt and US qt. NebY ( talk) 18:25, 11 November 2021 (UTC)
Should this work?:
I was thinking it should give something like:
I figure the conversion should be valid if the dimensional units are exactly the same, but inverted (e.g. "area/power" to "power/area"), and then the value should units converted, but then inverted as well. It's a generalization of the mpg conversion.
I was thinking it could also work like:
These kinds of things are pretty common in the real world. I was thinking specifically about u-value/r-value and mpg, but I think it's much more common than that. GliderMaven ( talk) 05:23, 7 November 2021 (UTC)
Cannot convert "area/power" to "power/area". I think it would require the creation of four new units (m2/W, W/m2, ft2/W, W/ft2) and creative use of the "invert" option although I haven't looked at that for a long time (not since one of your last visits here!) and don't know if it would work. I take your word for it being used somewhere, but I find it hard to imagine that text like that appears in articles here? Johnuniq ( talk) 05:51, 7 November 2021 (UTC)
Like to conversions for these in various countries! Lfstevens ( talk) 20:13, 24 November 2021 (UTC)
Consider {{convert|0.1|km2|1|abbr=on}} (0.1 km2 (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on}} (0.1 km2 (0.039 sq mi)). I don't know why the first one works at all, but if there's a reason for it to produce square miles at all, I'd expect precision to be the same.
Consider also {{convert|0.1|km2|1|abbr=on|sigfig=20}} (0.1 km2 (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on|sigfig=20}} (0.1 km2 (0.038610215854245 sq mi)). This makes the weird behaviour even more apparent -- it seems that using 1 as units sets precision to a fixed, low, level and prevents it from being changed.
81.6.39.198 ( talk) 20:22, 26 November 2021 (UTC)
Hi, the link for deadweight ton (DWton) currently links to tonnage and not Deadweight tonnage; could this be fixed? Thanks. Iazyges Consermonor Opus meum 18:58, 29 November 2021 (UTC)
You can see the error just glancing at it. A kilometer is much less than a mile, and a square kilometer is even less when compared with a sq. mi. If you subtract a sq. mi. you have to subtract at least one sq km:
According to the U.S. Census Bureau, the county has a total area of 944 sq mi (2,440 km2), of which 943 sq mi (2,440 km2) are land and 0.3 sq mi (0.78 km2) (0.03%) is covered by water. [1]
My calculator says 942 sq mi is 2439.7 sq km, rounding up is OK, but 943 square miles are 2442.3 sq km. If you're interested, it's from Brooks County, Texas. deisenbe ( talk) 04:20, 8 December 2021 (UTC)
This makes the sqmi numbers add up as expected. Adding precision eliminates rounding in the sqkm:According to the U.S. Census Bureau, the county has a total area of 943.3 sq mi (2,443 km2), of which 943 sq mi (2,440 km2) are land and 0.3 sq mi (0.78 km2) (0.03%) is covered by water.
According to the U.S. Census Bureau, the county has a total area of 943.3 sq mi (2,443.136 km2), of which 943 sq mi (2,442.359 km2) are land and 0.3 sq mi (0.777 km2) (0.03%) is covered by water.
|0
like so:{{convert|944|sqmi|abbr=on|0}}, of which {{convert|943|sqmi|abbr=on|0}}
---> 944 sq mi (2,445 km2), of which 943 sq mi (2,442 km2)The county has a total area of 943.3 sq mi (2,443 km2), of which 0.3 sq mi (0.8 km2) (0.03%) is water. Then the issue wouldn't have come up in the first place.BTW, the article's discussion of immigrant deaths and so on is a complete mess.
Between 2009 and 2018, over 600 bodies were recovered, and according to sheriff's deputy Benny Martinez, the corpses never found are 5 to 10 times more numerous than those found– how stupid can you get? If they're not found, how do you know how many there are? E Eng 14:01, 8 December 2021 (UTC)
References
Can anyone advise please, how best to use the convert template to round one of the outputs but not the other. I've got this: {{convert|246|bhp|kW PS|order=flip|disp=x|; |abbr=on}}
, which produces this: "183 kW; 249 PS; 246 bhp", but I want the middle value to be rounded to the nearest 10, to look like this: "183 kW; 250 PS; 246 bhp". --
DeFacto (
talk). 06:57, 29 October 2021 (UTC)
{{convert|250|PS|kW PS bhp|order=out|abbr=on}}
→ 180 kW (250 PS; 250 bhp){{convert|250.|PS|kW PS bhp|order=out|abbr=on}}
→ 184 kW (250 PS; 247 bhp)250.
(with a dot) tells convert that the zero is a significant digit. The same effect could be achieved with |sigfig=3
.
Johnuniq (
talk) 08:38, 29 October 2021 (UTC)
{{convert|250.|PS|kW PS bhp|order=out|abbr=on}}
-> 184 kW (250 PS; 247 bhp) to give "183 kW (250 PS; 246 bhp)"? The values by hand are 183.8747 and 246.58002. --
DeFacto (
talk). 09:34, 29 October 2021 (UTC)
{{convert|249.5|PS|kW PS bhp|0|order=out|abbr=on|adj=ri0}}
→ 184 kW (250 PS; 246 bhp)Beware that the 250 PS may be only nominal - ie a marketing value that was rounded off to look better in advertising. We could use something like {{convert|246|hp|kW hp PS|order=out|round=5|abbr=on}}
→ 185 kW (246 hp; 250 PS). But sometimes it is better to use the actual PS value instead of the rounded marketing value: {{convert|246|hp|kW hp PS|order=out|0|abbr=on}}
→ 183 kW (246 hp; 249 PS). A similar thing happens with the Ford 302 cubic inch engine: we list it as 4.9 litres even though it was advertised as a 5.0 engine.
Stepho
talk 10:30, 29 October 2021 (UTC)
In an article I saw the template used like this:
276 bhp (206 kW; 280 PS)
I know what a kilowatt is, but I hadn't heard of
PS before. I want to add a link to PS for people like me who haven't heard of it, but I don't want to link kW and it seems like this template has no way to do that. I would like a way specify that I want a link for a unit individually, something like \{\{convert|276|bhp|kW \[\[PS]]|0|abbr=on}}
.
Akeosnhaoe (
talk) 23:59, 13 December 2021 (UTC)
Just a comment (not a complaint) on some unexpected functionality I've observed: setting the flag disp=or also seems to change the abbr flag to off, implicity:
but
I'm curious, is this behaviour intentional? Archon 2488 ( talk) 09:59, 23 December 2021 (UTC)
|abbr=on
:I just tried to convert 0.368° to arcminutes, but found {{ convert}} is lacking in that department. It's unfortunate that the template does not support angular units, such as degrees, radians, turns, arcminutes, and arcseconds. That could be useful, for example, on astronomy articles. Praemonitus ( talk) 16:54, 29 December 2021 (UTC)
Hi there, I can see why you decided to no write aj or julian years, despite thats what it converts into. So I am suggesting to at least link the "a" not " annum" but rather to "julian year" or what ever year calculation is used for the converting? (And then maybe use aj too?) Nsae Comp ( talk) 22:39, 7 January 2022 (UTC)
feet/year
and "annum" is used in that context.
Annum is a redirect to
year. The following links to annum where it might just be year:
The infobox at Earth uses the following:
{{convert|365.256363004|d|yr|comma=gaps|abbr=on|lk=out|disp=x|<ref name="IERS" /><br /><small>(|)</small>}}
Convert does the calculation using the definitions 1 day = 86,400 seconds and 1 year = 31,557,600 seconds = 365.25 days exactly. However, what should happen is way over my paygrade given 13 significant digits for the number of days. A discussion at Talk:Earth or WT:WikiProject Astronomy regarding what should happen would be best. Johnuniq ( talk) 23:00, 8 January 2022 (UTC)
A long ton (imperial ton) is defined as 2240 lb and a "long hundredweight" (imperial hundredweight, lcwt) is 112 lb or 8 stone. One stone is 14 lb.
But as of today, {{ convert}} appears to have an alternative definition. All these are wrong:
But these are correct
Aye, there's trouble at t'mill, lad! -- John Maynard Friedman ( talk) 17:14, 17 January 2022 (UTC)
|4}}
i.e., sigfig=4.Could someone please add a conversion for in. WC similar to inHg? Apparently HVAC compressors in the US are labeled with this unit of pressure. Thanks in advance! Facts707 ( talk) 15:52, 15 January 2022 (UTC)
From NIST:
They also have inches and centimeters Hg at 32°F, 60°F, and "conventional". Facts707 ( talk) 04:14, 19 January 2022 (UTC)
Consider this conversion, from Sisal:
{{convert|1.5|-|2|m|ftin|abbr=on}}
→ 1.5–2 m (4 ft 11 in – 6 ft 7 in)Per MOS:UNITNAMES I think this should generate a spaced en dash, but what we get is an unspaced en dash. GA-RT-22 ( talk) 03:14, 16 January 2022 (UTC)
{{convert|1.5|to|2|m|ftin|abbr=on}}
→ 1.5 to 2 m (4 ft 11 in to 6 ft 7 in)Consider using inches (but not in.) in place of in where the latter might be misread as a prepositionand I'm almost ready to suggest to Johnuniq that a special case be made of in to, changing it to inches to (on both sides of range). Now there would be some kludgy code for you, I'm guessing. E Eng 07:47, 17 January 2022 (UTC)
4 ft 11 in – 6 ft 7 indefinitely takes a spaced endash. That MOS gives no example using ft in isn't a problem -- the important point is that ft in has a space, so the endash has a space before it and a space after it. E Eng 05:09, 16 January 2022 (UTC)
Hmm, I wonder what "Rackets with smaller and larger head sizes, 85 and 120–137 square inches (550 and 770–880 cm2), are still produced" at Racket (sports equipment)#Tennis means. Should it have a spaced en dash? Johnuniq ( talk) 08:51, 16 January 2022 (UTC)
I'm looking at some changes so units like ftin use a spaced en dash in ranges. With a combination unit like ftin (feet and inches) or stlb (stones and pounds), convert shows the unit on each side of the dash. However, sometimes the major unit (feet or stones) is not needed as in these examples:
{{cvt|0.1|-|0.2|m|ftin}}
→ 0.1–0.2 m (3.9 in – 7.9 in){{cvt|3|-|5|kg|stlb}}
→ 3–5 kg (6.6 lb – 11.0 lb)I'm not going to try to make convert handle that special case. It occurs in perhaps half a dozen articles. The fix is to use the more appropriate output unit:
{{cvt|0.1|-|0.2|m|in}}
→ 0.1–0.2 m (3.9–7.9 in){{cvt|3|-|5|kg|lb}}
→ 3–5 kg (6.6–11.0 lb)Johnuniq ( talk) 06:40, 17 January 2022 (UTC)
I updated the sandbox to give a spaced en dash.
Current template (not spaced):
{{convert|2|-|3|Mach|20000}}
→ Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph){{convert|1.5|-|2|m|abbr=on}}
→ 1.5–2 m (4 ft 11 in – 6 ft 7 in){{convert|1346|-|1676|mm|ydftin|0}}
→ 1,346–1,676 millimetres (1 yd 1 ft 5 in – 1 yd 2 ft 6 in){{convert|81|-|89|kg|stlb}}
→ 81–89 kilograms (12 st 11 lb – 14 st 0 lb)Sandbox (spaced):
{{convert/sandbox|2|-|3|Mach|20000}}
→ Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph){{convert/sandbox|1.5|-|2|m|abbr=on}}
→ 1.5–2 m (4 ft 11 in – 6 ft 7 in){{convert/sandbox|1346|-|1676|mm|ydftin|0}}
→ 1,346–1,676 millimetres (1 yd 1 ft 5 in – 1 yd 2 ft 6 in){{convert/sandbox|81|-|89|kg|stlb}}
→ 81–89 kilograms (12 st 11 lb – 14 st 0 lb)Johnuniq ( talk) 01:32, 18 January 2022 (UTC)
"Default spelling of units is in the en (generic) locale. To show en-US spelling, use |sp=us"... true, except when the conversion is to a US-specific measure. On 2022 Hunga Tonga eruption and tsunami I'm trying to get the template to convert litres to US gallons, and there doesn't seem to be a way of stopping it from spelling the former as "liters". Is there any way to add a sp=uk or similar please, because at the moment that just generates an error. Grutness... wha? 22:35, 20 January 2022 (UTC)
{{convert|250000|L|U.S.gal|abbr=off}}
→ 250,000 liters (66,000 U.S. gallons)USgal
. Using U.S.gal
implies US spelling and sets sp=us
. Try this:
{{convert|250000|L|USgal|abbr=off}}
→ 250,000 litres (66,000 US gallons)Apollo Lunar Module uses {{cvt|290|isp}}, which displays as "290 s (2.8 km/s)". I couldn't find anything on "isp", but the value is for the LEM's Specific impulse, so I guess that stands for "impulse, specific". It should be measured in m/s, so why is Cvt using a time here? -- 84.189.84.17 ( talk) 00:58, 21 January 2022 (UTC)
I have updated the sandbox with some improvements regarding handling of the Mach unit. Using the old system, an altitude could be entered as a number (in feet) after the Mach unit, but that only worked for Mach as an input. It was not possible to specify an altitude for Mach as an ouput.
In the new system:
altitude_ft
and altitude_m
have been added.The following table compares the old and new systems using fixed wikitext so the results will not change.
Convert | Old output | New output |
---|---|---|
{{cvt|0.9|Mach}} | Mach 0.9 (1,102.5 km/h; 685.1 mph) | Mach 0.9 (1,100 km/h; 690 mph) |
{{cvt|1.6|Mach|20000}} | Mach 1.6 (1,820.5 km/h; 1,131.2 mph) | Mach 1.6 (1,820 km/h; 1,130 mph) |
{{cvt|1.6|Mach|altitude_ft=20,000|mph}} | (not supported) | Mach 1.6 (1,130 mph) |
{{cvt|1.6|Mach|altitude_m=6,096|mph}} | (not supported) | Mach 1.6 (1,130 mph) |
{{cvt|3|Mach}} | Mach 3 (3,675 km/h; 2,284 mph) | Mach 3 (3,700 km/h; 2,300 mph) |
{{cvt|5|-|7|Mach}} | Mach 5–Mach 7 (6,125–8,575 km/h; 3,806–5,328 mph) | Mach 5 – Mach 7 (6,100–8,600 km/h; 3,800–5,300 mph) |
{{cvt|9.8|Mach|98000}} | Mach 9.8 (10,655.3 km/h; 6,620.9 mph) | Mach 9.8 (10,700 km/h; 6,620 mph) |
Johnuniq ( talk) 08:43, 24 January 2022 (UTC)
Added:
|Mach|km/h mph|
(multiple value output).|20000
altitude input must be changed into |altitude_ft=20000
, in-article.row | Convert | Old output | New output | Inverse{{convert/sbox|123 |Mach |km/h |altitude_ft=..}}
|
---|---|---|---|---|
A | {{cvt|0.9|Mach}} | Mach 0.9 (1,102.5 km/h; 685.1 mph) | Mach 0.9 (1,100 km/h; 690 mph) | 1,100 kilometres per hour (Mach 0.90) 690 miles per hour (Mach 0.91) |
B | {{cvt|1.6|Mach|20000}} | Mach 1.6 (1,820.5 km/h; 1,131.2 mph) | Mach 1.6 (1,820 km/h; 1,130 mph) |
convert: precision too large |20000}} 1,820 kilometres per hour (Mach 1.6) → • |altitude_ft=20000}}
|
C | {{cvt|1.6|Mach|altitude_ft=20,000|mph}} | (not supported) | Mach 1.6 (1,130 mph) | 1,100 kilometres per hour (Mach 0.97) 1,130 miles per hour (Mach 1.6) |
D | {{cvt|1.6|Mach|altitude_m=6,096|mph}} | (not supported) | Mach 1.6 (1,130 mph) | 1,820 kilometres per hour (Mach 1.6) 1,130 miles per hour (Mach 1.6) |
E | {{cvt|3|Mach}} | Mach 3 (3,675 km/h; 2,284 mph) | Mach 3 (3,700 km/h; 2,300 mph) | 3,700 kilometres per hour (Mach 3.0) 2,300 miles per hour (Mach 3.0) |
F | {{cvt|5|-|7|Mach}} | Mach 5–Mach 7 (6,125–8,575 km/h; 3,806–5,328 mph) | Mach 5 – Mach 7 (6,100–8,600 km/h; 3,800–5,300 mph) | 6,100–8,600 kilometres per hour (Mach 5.0 – Mach 7.0) 3,800–5,300 miles per hour (Mach 5.0 – Mach 7.0) |
G | {{cvt|9.8|Mach|98000}} | Mach 9.8 (10,655.3 km/h; 6,620.9 mph) | Mach 9.8 (10,700 km/h; 6,620 mph) | • |altitude_ft=20000}} 10,700 kilometres per hour (Mach 9.8) 6,620 miles per hour (Mach 9.8) • |altitude_ft=20000}} 10,700 kilometres per hour (Mach 8.7) 6,620 miles per hour (Mach 8.7) |
H | {{cvt|9.8|Mach|km/h mph|altitude_ft=20000}} | {{cvt|9.8|Mach|<!--no units=defaults to |km/h mph|-->20000}} Mach 9.8 (11,200 km/h; 6,930 mph) |
.. | • |altitude_ft=20000}} Mach 9.8 (10,700 km/h; 6,620 mph) • |altitude_m=667}} Mach 9.8 (12,000 km/h; 7,460 mph) |
The nomenclature in "producing... 260 pound force-feet (350 N⋅m) of torque" is non-standard, and apparently is produced by a conversion template as invoked by: 260 pound force-feet (350 N⋅m)
Ref: /info/en/?search=Dodge_Charger
Standard usage would simply read "260 lb•ft (350 N•m)". There is no common specification for torque stated as "pound force-feet."
I contend the template should be modified to render the standard verbiage. 107.2.38.145 ( talk) 15:52, 30 January 2022 (UTC)
lb.ft
and lbft
:
{{convert|260|lb.ft}}
→ 260 pound force-feet (350 N⋅m){{convert|260|lbft}}
→ 260 pound-feet (350 N⋅m){{convert|260|lb.ft|abbr=on}}
→ 260 lb⋅ft (350 N⋅m){{convert|260|lbft|abbr=on}}
→ 260 lb⋅ft (350 N⋅m)abbr=on
gives the correct symbol. There was a previous and inconclusive discussion regarding the "force" terminology in
December 2011.
Johnuniq (
talk) 02:07, 31 January 2022 (UTC)This code ( found here):
{{convert|2|-|3|cm|0|abbr=on}}
results in this output:
Maybe the repetition is intentional but it looks a bit clumsy. Could we produce a neater output like this:
or would this be confusing? -- Heron ( talk) 14:42, 2 February 2022 (UTC)
Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
–
) now use a spaced en dash ( –
) with unit Mach and with composite units such as ftin (feet and inches) or stlb (stones and pounds).{{convert|2|-|3|Mach|altitude_ft=20000}}
→ Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph){{convert|0.1|-|0.2|m}}
→ 0.1–0.2 metres (3.9 in – 7.9 in){{convert|81|-|89|kg|stlb}}
→ 81–89 kilograms (12 st 11 lb – 14 st 0 lb)altitude_ft
and altitude_m
can be used to specify the altitude in feet or meters.DWton
and DWtonne
have been corrected to
Deadweight tonnage.Release notes for earlier versions are listed here. Johnuniq ( talk) 22:52, 4 February 2022 (UTC)
|3=
) to be used as alternative (synonym) next to |altitude_ft, _m=
then? Wouldn't it be preferable to not introduce non-semantic parameter usage, i.e., requiring dedicated parameters |altitude_ft, _m=
? I don't think ease of editing is helped. -
DePiep (
talk) 09:01, 11 February 2022 (UTC)
|altitude_ft=10,000
) or in metres (for example, |altitude_m=3,749
). The altitude cannot be determined accurately and only a whole number is accepted.Along with what I wrote above, I don't think any more is needed, although any documentation should not mention details such as aerospaceweb.org.
Johnuniq (
talk) 08:38, 12 February 2022 (UTC)Would someone who understands procedures regarding redirects please have a look at diff which added {{ WikiProject Measurement}} at Module talk:Convert/documentation/conversion data, which is a redirect to this page. Ping Awkwafaba. Johnuniq ( talk) 23:53, 14 February 2022 (UTC)
I've noticed that (for example) {{convert|2|to(-)|3|m|ft|0}} works as expected: 2 to 3 metres (7–10 ft). However, the near-identical {{convert|2|to(–)|3|m|ft|0}} does not: 2 to(–) convert: unknown unit (point being that in the latter case, we have an en dash rather than a hyphen). Archon 2488 ( talk) 10:13, 17 February 2022 (UTC)
-
(hyphen) and –
(en dash) for a simple range. However, no one should think that the hyphen in to(-)
should be changed to an en dash. Two others examples where only a hyphen is accepted are and(-)
and +/-
.
Johnuniq (
talk) 06:03, 18 February 2022 (UTC)I corrected a population density figure in the text of
Prince of Wales–Hyder Census Area, Alaska#Demographics, and 1.57 per square mile (0.61/km<sup>2</sup>)
should become 1.57 per square mile (0.61/km2) but instead is treated as 1 per square mile (0/km2). –
LaundryPizza03 (
d
c̄) 19:49, 19 February 2022 (UTC)
E.g.:
Thanks for considering, Facts707 ( talk) 00:19, 13 February 2022 (UTC)
It seems like when I try to use a different currency when using the "currency per unit" feature, it throws an error saying it doesn't recognize it. I figured using the "currency change" feature just uses a simple text replacement rather than an actual recognition of the various currency symbols. For example:
{{convert|1|$/acre|abbr=off}}
→ $1 per acre ($2.5 per hectare)
{{convert|1|$/acre|$=₹|abbr=off}}
→ ₹1 per acre (
convert: unknown unit)
It would be great if all the currency symbols could be supported. Getsnoopy ( talk) 18:29, 20 February 2022 (UTC)
{{convert|1|$/acre|$/ha|$=₹|abbr=off}}
→ ₹1 per acre (₹2.5 per hectare)Hey, J u: In a discussion over at Talk:MOS, the question has arisen: Which chain ? English, Scottish or US ? I'm not sure which one convert uses. Possibly convert might have to accept multiple chains.
E
Eng 13:48, 1 February 2022 (UTC)
{{convert|1|chain|feet|abbr=off|9}}
→ 1 chain (66.000000000 feet){{convert|1|foot|m|abbr=off|9}}
→ 1 foot (0.304800000 metres)I'm editing on Royce Clayton and wrote about how he trained by running 200-metre (660 ft) sprints. He's American though, so it should read "200-meter". I put {{ Use American English}} on the article, but it still shows up as "metre". Can we account for differences in English dialects? – Muboshgu ( talk) 04:32, 21 February 2022 (UTC)
Does this template always show X unit1 (Y unit2)? Or can it show Y unit2? I am using the Convert template to import Wikidata numbers into existing tables. For example, in tables we typically show one unit in each column, or only one unit. Tomastvivlaren ( talk) 14:20, 28 February 2022 (UTC)
Can you guys explain why {{ Convert}} shows different units for the area (P2046) of the cities of São Paulo (Q174) and Sundsvall (Q26476)? The São Paulo area is stored in km2 at wikidata and Sundsvall in hectares, but shouldn't Convert fix that? I always want km2 - is that possible?
@ MB and Johnuniq: Tomastvivlaren ( talk) 22:29, 28 February 2022 (UTC)
This is a weirdness in how convert works internally when dealing with Wikidata values/units. A workaround is to insert 3=
in {{
Area WD}} so its unit reads |3=km2
. I'd have to spend an hour studying it to remind myself of exactly what is happening but I believe that convert's code expects that it is being used to do a conversion, so there should be an input unit and an output unit. The input value and unit are read from Wikidata. They are inserted as parameters 1 and 2 to convert. The output unit is specified as a parameter to convert. The problem is that no one can predict what the input unit is and the input=
feature was initially used to do conversions which looked silly if the input unit and output unit were the same. Therefore convert removes the output unit if it duplicates the input, so it ends up using the default. Try the 3=
workaround.
Johnuniq (
talk) 23:54, 28 February 2022 (UTC)
Was editing some articles to use Convert when I came upon something in which I could use some help. Measurements for rectangular and cuboid figures are usually given as 10 x 10 cm or 30 cm x 10 cm x 20 cm, for example. What's the more appropriate way to use convert to handle those measurements? Zera/ talk 13:28, 23 February 2022 (UTC)
More: In the 'loose' format, "x" (ecks) and "×" (times) render the same ("×"), but the 'tight' format currently does not parse "×":
{{convert|30|x|10|x|20|cm|abbr=on}}
→ 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in){{convert|30|×|10|×|20|cm|abbr=on}}
→ 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in){{convert|30x10x20|cm|abbr=on}}
→ 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in){{convert|30×10×20|cm|abbr=on}}
→
convert: invalid number –
A876 (
talk) 18:24, 29 March 2022 (UTC)
It seems like there's a bug where if I try to show the unit name and the symbol with the order flipped, it does not show the unit symbol. For example:
{{convert|2|kPa|psi|abbr=~}}
→ 2 kilopascals [kPa] (0.29 psi)
{{convert|2|kPa|psi|abbr=~|order=flip}}
→ 0.29 pounds per square inch (2 kPa)
Could someone take a look at this or point me in the right direction? Getsnoopy ( talk) 16:17, 30 March 2022 (UTC)
option=flip
applies. I forget the details but studying the following would probably reveal the reasoning.
In Special:Diff/1080355341, I did two conversions from seconds; one to minutes, the other to hours. But, I had to make that choice manually. Is there some way to say, "Convert this many seconds into minutes or hours as appropriate?" -- RoySmith (talk) 19:39, 31 March 2022 (UTC)
sec
at
Module:Convert/extra. If less than 120 minutes, it defaults to minutes, otherwise hours. Examples:
{{convert|5700|sec}}
→ 5,700 seconds (95 min){{convert|7200|sec}}
→ 7,200 seconds (2.0 h)sec
would be removed and replaced with s
which would be updated to use the new default. It's ok to use sec
in articles now, if wanted. Any problems later will be noticed and fixed.
Johnuniq (
talk) 23:20, 31 March 2022 (UTC)
Where are the links to pre-2020 archived discussions? Judging by the text at the top of
Template talk:Convert/Archive 1,
Johnuniq (
talk ·
contribs) changed the naming system for archiving in July 2020, but I can't find where the older archives are listed even though it says The index for 2007 to 2019 will be moved to this page.
--
Redrose64 🌹 (
talk) 11:47, 5 April 2022 (UTC)
Template talk:Convert/Archive 1
displays the archive in its full glory. In other words, some change at {{
archives}} means that the parameters which worked in July 2020 now hide the old list. Does anyone feel like working out what has happened and how to rectify it. I would prefer that the old archive list is at Archive_1 and not cluttering up the top of this page.
Johnuniq (
talk) 03:12, 6 April 2022 (UTC)Take a look at the "Length" in the infobox on Arleigh Burke-class destroyer. 505 ft gets correctly converted to 154 m, 509 ft correctly becomes 155 m, and then 510 ft becomes 160 m?? That's not correct. Denvercoder9 ( talk) 16:42, 28 April 2022 (UTC)
|round=5
.
Denvercoder9 (
talk) 17:11, 28 April 2022 (UTC)
|0
to force convert to use 0 decimal places for rounding.
Stepho
talk 22:14, 29 April 2022 (UTC)
|0
- which determines the precision of the result - but to use |sigfig=3
, which specifies the precision of the input value: 510 ft (155 m). This is documented at
Template:Convert#Round to a given number of significant figures: |sigfig=.--
Redrose64 🌹 (
talk) 14:02, 30 April 2022 (UTC)
|0
affects significant digits from the decimal point (positive means more digits after decimal point, negative means spread zeroes from the decimal point). |sigfig=3
counts significant digits from the beginning. Both work in most cases, both have advantages/disadvantages in a minority of cases - usually where the output is close to a power of 10 that might or might not add an extra digit.
Stepho
talk 00:15, 1 May 2022 (UTC)Suggestion ... add a non-breaking space – – between the base units and their conversion to prevent confusing separation of the units, like this, at the end of a line:
Instead, it should look like this:
The inclusion on the non-breaking space would have no effect in the middle of a line, viz:
Further, this suggested change to the template would be benign; it would have no material effect on any of the many places where the template is used in existing articles, other than to eliminate the separation of base and converted units if they appear at the end of a line.
Thanks for considering such an improvement to this template. Truthanado ( talk) 23:58, 18 April 2022 (UTC)
Is there a way to denote a conversion from minutes and seconds to total seconds....or, similarly from hours/min/sec....or any such combination. I note that showing minutes and seconds in the template as a minutes-decimal value does work, but would prefer to be able to enter the actual seconds value, rather than its decimal equivalent. DonFB ( talk) 14:47, 6 May 2022 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 |
This talk page uses amazing code to make month/year archives. That was highly desirable a long time ago when the old templates were used because maintaining 4,000 templates was a lot of effort. However, a more conventional system might be appropriate now. I suppose there could be a link to an index page with links to all the month/year archives—it would need a "search archives" box. Or, lazy people like me might just leave the current system working. If it's left as-is, should Template talk:Convert/Archive 1 be deleted and salted to prevent further accidental creation? That page was deleted in May 2015 and December 2015, and has just been created again (hi EEng!). Thoughts? Johnuniq ( talk) 01:34, 9 July 2020 (UTC)
|archive = Talk:Convert/Archive %(counter)d
; works with
Talk:Gold & with the manual Archive button - I experienced. We can then manually: Set counter to #2 right away; Use #1 for past months of 2020; Add numbered box. The monthly-box: fold into years-only showing. Possible issue to check: one search box works searching both two sets of pages having .../Archive? -
DePiep (
talk) 15:58, 9 July 2020 (UTC)Plan @ EEng, Stepho-wrs, and DePiep: Everyone went quiet but I'm warming to the following idea:
Thoughts? Johnuniq ( talk) 10:09, 17 July 2020 (UTC)
Done Please check the archive box that I put on this page. It would be desirable to add a note somewhere that the old archives are listed at Template talk:Convert/Archive 1. I made the 2020 archive pages redirect to Archive 1. Johnuniq ( talk) 01:46, 21 July 2020 (UTC)
What DePiep said looks good, although how the archives work doesn't affect me because I keep a single local file with all the archives concatenated so I can search it more easily. One search box will work (see #Search experiment below).
There are 153 archive pages totalling about 7MB. The six 2020 archives total about 132KB. I think the archives older than 2020 should be left alone, but those in 2020 should be consolidated in /Archive 1, and the 2020 archive pages deleted. EEng is right in that having, for example, one largish archive per year rather than 12 short archives per year would make finding recent discussions much easier.
Does anyone want to keep the current system for 2020 and the future? If we agree to change, it looks like it would be readily achievable except that there would need to be an index page listing the month/year archives, with a link to the index on this page, preferably in a new archive box, or at least near it. Or, we could put the index at the beginning of Archive 1. The index is currently at Template talk:Convert/Archives with some tricky wikitext. That could be replaced with the expansion from Special:ExpandTemplates so it would work on another page. Thoughts? Johnuniq ( talk) 05:23, 10 July 2020 (UTC)
This is the current search archives box. It works on all /Archive subpages so will handle
/Archive June 2020 as well as
/Archive 1. For example, typing curie
in the following finds both those pages because I moved text from the latter to the former so a section is currently duplicated.
Examining the URL generated by the search show something strange: It includes:
&fulltext=Search+archives &fulltext=Search
which seems wrong. I imagine only the first of these is used. The second is either a mistake or a lazy way of providing a default in case fulltext
is omitted.
Johnuniq (
talk) 05:23, 10 July 2020 (UTC)
It works on all /Archive subpages so will handle /Archive June 2020 as well as /Archive 1. That says it all. My thumb is up. Not for love, but from rational improvement I see. - DePiep ( talk) 20:46, 18 July 2020 (UTC)
Do the convert templates have any help for converting Deadweight tonnage into internationally recognized units of weight, or mass? tons and tonnes short tons and long tons plus others? are legend. I did a search and couldn't find anything. Cheers. N2e ( talk) 04:09, 29 July 2020 (UTC)
Since {{convert}} supports almost every conceivable unit (except poorly defined historical/folk units), it seems puzzling that it does not support angular units. I propose to add the following units:
Code | Symbol | Name | Link | Comment |
---|---|---|---|---|
° |
° | degree | Degree (angle) | The buttons for entering ° ′ ″ are right under the text input area. |
′ |
′ | arcminute | Minute of arc | |
″ |
″ | arcsecond | Second of arc | |
mas |
mas | milliarcsecond | Milliarcsecond | |
µas |
µas | microarcsecond | Microarcsecond | |
radian |
rad | radian | Radian | rad is already taken by radiation unit
rad.
|
mradian |
mrad | milliradian | Milliradian | |
grad |
grad | gradian | Gradian | grad is non-standard, but instantly recognizable. |
turn |
turn | turn | Turn (angle) | |
Rotational speed: | ||||
rpm |
rpm | revolution per minute | Revolutions per minute | Default output: Hz .
|
radian/s |
rad/s | radian per second | Radian per second | Default output: Hz .
|
Aliases: | ||||
arcmin |
arcmin | arcminute | Minute of arc | |
arcsec |
arcsec | arcsecond | Second of arc | |
gon |
gon | gradian | Gradian | gon is specified in ISO 31-1. |
r |
r | turn | Turn (angle) | r is specified in IEEE 260.1:2004 and ISO 80000-3:2006. |
MOA |
MOA | minute of angle | Minute of arc | Used in weapons aiming. Default output: milr .
|
milr |
mil | milliradian | Milliradian | Used in weapons aiming. Default output: MOA .mil is already taken by
thousandth of an inch.
|
The multiple units feature of {{convert}} can be used in input:
{{convert|2|°|47|′|19|″|radian|abbr=on}}
→ 2° 47′ 19″ (0.048670 rad){{convert|47|′|19|″|mradian|abbr=on}}
→ 47′ 19″ (13.764 mrad)And output:
{{convert|0.50|mradian|′″}}
→ 0.50 milliradian (1′ 43″){{convert|0.50|mradian|′ ″}}
→ 0.50 milliradian (1.72′; 103″)There are other angular units that may be added in the future, if a need arises:
— UnladenSwallow ( talk) 05:16, 21 April 2020 (UTC)
Hz
is a unit of length)—see
March 2015.
Johnuniq (
talk) 06:52, 21 April 2020 (UTC)
{{cvt|5|L/100 km}}
→ 5 L/100 km (56 mpg‑imp; 47 mpg‑US){{cvt|10|L/100 km}}
→ 10 L/100 km (28 mpg‑imp; 24 mpg‑US)Article | Example | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Pendulum | In the case of a typical grandfather clock whose pendulum has a swing of 6° and thus an amplitude of 3° (0.05 radians), the difference between the true period and the small angle approximation (1) amounts to about 15 seconds per day. | ||||||||||||
Angular diameter | The table shows that the angular diameter of Sun, when seen from Earth is approximately 32′ (1920″ or 0.53°), as illustrated above. | ||||||||||||
To put this in perspective, the full Moon as viewed from Earth is about 1⁄2°, or 30′ (or 1800″). | |||||||||||||
Globe | Usually a globe is mounted so that its spin axis is 23.5° (0.41 rad) from vertical, which is the angle the Earth's spin axis deviates from perpendicular to the plane of its orbit. | ||||||||||||
Telescopic sight | Some proprietary rails also offer the possibility to tilt the scope up to 1° (60 moa; 17.5 mrad) to the left or right. | ||||||||||||
Equation of time | The numerical values written here result from using the orbital parameter values, e = 0.016709, ε = 23.4393° = 0.409093 radians, and λp = 282.9381° = 4.938201 radians that correspond to the epoch 1 January 2000 at 12 noon UT1. | ||||||||||||
Steradian | This angle corresponds to the plane aperture angle of 2θ ≈ 1.144 rad or 65.54°. | ||||||||||||
Faraday effect | By placing a rod of this material in a strong magnetic field, Faraday rotation angles of over 0.78 rad (45°) can be achieved. | ||||||||||||
JavaScript syntax |
| ||||||||||||
Young–Laplace equation | For a water-filled glass tube in
air at
sea level:
| ||||||||||||
Small-angle approximation | The angles at which the relative error exceeds 1% are as follows:
|
Article | Example |
---|---|
Exoplanet | The data was obtained on 16 March 2003 with NACO on the VLT, using a 1.4 arcsec occulting mask on top of AB Pictoris. |
Alpha Centauri | Viewed from Earth, the apparent orbit of A and B means that their separation and position angle (PA) are in continuous change throughout their projected orbit. Observed stellar positions in 2019 are separated by 4.92 arcsec through the PA of 337.1°, increasing to 5.49 arcsec through 345.3° in 2020. The closest recent approach was in February 2016, at 4.0 arcsec through the PA of 300°. The observed maximum separation of these stars is about 22 arcsec, while the minimum distance is 1.7 arcsec. |
Their apparent angular separation varies over about 80 years between 2 and 22 arcsec (the naked eye has a resolution of 60 arcsec), but through much of the orbit, both are easily resolved in binoculars or small telescopes. | |
Quasar | Image is 60 arcsec on a side. |
New Horizons | The instrument is equipped with a 1024×1024 pixel by 12-bits-per-pixel monochromatic CCD imager giving a resolution of 5 μrad (~1 arcsec). |
Parallax | The nearest star to the Sun (and thus the star with the largest parallax), Proxima Centauri, has a parallax of 0.7687 ± 0.0003 arcsec. |
Cosmic distance ladder | It is, more precisely, the galaxy's angular diameter out to the surface brightness level of 20.75 B-mag arcsec−2. |
Panspermia | The probability of hitting the target zone can be calculated from where A(target) is the cross-section of the target area, dy is the positional uncertainty at arrival; a – constant (depending on units), r(target) is the radius of the target area; v the velocity of the probe; (tp) the targeting precision (arcsec/yr); and d the distance to the target, guided by high-resolution astrometry of 1×10−5 arcsec/yr (all units in SIU). |
Astrometry | In the 16th century, Tycho Brahe used improved instruments, including large mural instruments, to measure star positions more accurately than previously, with a precision of 15–35 arcsec. |
He made the first measurement of stellar parallax: 0.3 arcsec for the binary star 61 Cygni. | |
During the past 50 years, 7,435 Schmidt camera plates were used to complete several sky surveys that make the data in USNO-B1.0 accurate to within 0.2 arcsec. | |
Proper motion | Of the stars visible to the naked eye (by convention, limiting visual magnitude of 6.0),
61 Cygni A (magnitude V=5.20) has the highest proper motion at 5.281 arcsec/a, although
Groombridge 1830 (magnitude V=6.42), proper motion 7.058 arcsec/a, might be visible for an observer with exceptionally keen vision.
A proper motion of 1 arcsec per year at a distance of 1 light-year corresponds to a relative transverse speed of 1.45 km/s. |
arcsec
will be unambiguous when used with {{convert}}
. —
UnladenSwallow (
talk) 11:38, 24 April 2020 (UTC)See Boom Overture. This template is translating Mach 2.2 as 2,300 km/h or 1,300 kn, the actual values (precision 2 s.f.) ought to be 2,700 km/h or 1,500 kn. Could someone please fix this?-- Newbiepedian ( talk · C · X! · L) 15:44, 2 August 2020 (UTC)
Ikarus 55#Technical description
190 g·PS<sup>−1</sup>·h<sup>−1</sup> (258 g·kW<sup>−1</sup>·h<sup>−1</sup>)
190 g·PS−1·h−1 (258 g·kW−1·h−1)
How was this calculated and how can this be done with convert?
Peter Horn
User talk 00:22, 4 August 2020 (UTC)
190 g·PS<sup>−1</sup>·h<sup>−1</sup> (258 g·kW<sup>−1</sup>·h<sup>−1</sup>)
→ 190 g·PS−1·h−1 (258 g·kW−1·h−1){{cvt|190|g/PS/h|g/kW/h}}
→ 190 g/PS/h (260 g/kW/h){{cvt|190|g/PS/h|g/kW/h|0}}
→ 190 g/PS/h (258 g/kW/h)There seem to be no bit and byte unit conversions, e.g. between kilobytes and megabytes etc. Should we add them? I didn't find any discussions in the archive. I'd like to add them to Module:Convert/documentation/conversion data. Of course, we'll have to take care of binary prefixes and conversions between bits and bytes, and also make sure that unit names are unambiguous, but that shouldn't be a major problem. What do you think? -- Chrisahn ( talk) 11:19, 13 October 2020 (UTC)
{{
val}}
is used for expressing a single value whereas {{
convert}}
is used for converting between different units.
Martin of Sheffield (
talk) 11:53, 13 October 2020 (UTC)
{{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KB|0|disp=out}}
would display 66 KB{{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KiB|0|disp=out}}
would display 64 KiB{{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KiB|0|disp=out}}
would display 64 KB (IEC: KiB){{convert|2,000,000|bytes|MB}}
would display 2,000,000 bytes (2 MB){{convert|65536|bytes|KiB|0|disp=out}
would display 64 KB{{convert|65536|bytes|KiB|0|disp=out|binpre=IEC}}
would display 64 KiB{{convert|65536|bytes|KiB|0|disp=out|binpre=SI+IEC}}
would display 64 KiB (IEC: KiB)KiB-IEC
. Not very intuitive for users.Folks, let's stop this. This wasn't meant to be about WP:COMPUNITS at all. It was never my intention to address that question. I didn't even know about that MOS section. Please consider this thread closed. I'll archive it later. Maybe I'll start a new one when I have time. Thanks. -- Chrisahn ( talk) 11:57, 14 October 2020 (UTC)
References
I notice at
2020 Beirut explosion that in an instance of this template, {{convert|1.2|ktonTNT|TJ|sigfig=2|lk=on}}
, which renders as 1.2
kilotons of TNT (5.0
TJ)
, the link over TJ goes just to
Joule, rather than to
Terajoule, which redirects to
Joule#Terajoule. I think it would be more useful for readers for the link to go to terajoule, since they may not know that the T stands for tera. Could a more specific link be adopted here for terajoules and other multiples of joules/other units as appropriate? {{u|
Sdkb}}
talk 02:45, 17 August 2020 (UTC)
The Convert template handles absolute temperatures just fine:
"The mean winter temperature in Smallville is {{convert|3|C|F}}
."
yields
"The mean winter temperature in Smallville is 3 °C (37 °F)."
But Convert cannot handle temperature differences correctly:
"The mean annual temperature in Smallville has increased by {{convert|3|C|F}}
in the last century."
yields
"The mean annual temperature in Smallville has increased by 3 °C (37 °F) in the last century."
which is nonsense. The correct conversion would be:
"The mean annual temperature in Smallville has increased by 3°C (5.4°F) in the last century."
I noticed this error in the article about Kuujjuaq. I fixed it there by simply removing the Convert template in cases where the temperature being referenced is a difference, and doing the conversion manually. I haven't searched, but I wouldn't be surprised if this mistake has come up in many articles, such as in coverage of global warming.
I can't think of an elegant way to fix this. Perhaps a mechanism like this could be implemented: {{convert|n|deltaC|deltaF)
. But that would require some serious work on the Convert help page, and would still probably confuse many editors. I have little experience with templates, maybe someone with more experience could suggest a better idea.
STarry (
talk) 07:22, 14 September 2020 (UTC)
{{convert|3|C-change|F-change}}
: 3 °C (5.4 °F){{convert|3|C|F}}
: 3 °C (37 °F)Any idea how I should handle the following unit: Pounds of coal per indicated horsepower hour
This is a measure of the fuel efficiency of early steamships and appears in SS Carnatic. Carnatic and Agamemnon both achieved a massive stepwise improvement in efficiency (though the higher boiler pressure of SS Agamemnon (1865) became the model for immediate future development).However, in discussing this, the units look clumsy and are not friendly to anyone used to modern units. ThoughtIdRetired ( talk) 20:01, 16 September 2020 (UTC)
{{convert|1|hph|kWh|adj=pre|indicated}}
→ 1 indicated horsepower-hour (0.75 kWh){{convert|1|hph|kWh|adj=pre|indicated|spell=in}}
→ one indicated horsepower-hour (0.75 kWh){{convert|1|hph|kWh|disp=out}}
→ 0.75 kWhThere are 2240 pounds in a Long Ton (LT). The convert macro does not convert LT-to-ton correctly.
{{convert|3900|LT|t}}
incorrectly yields 4,000 tons, not 4,368 tons. Proof: 3,900 long tons (4,000 t){{convert|2100|LT|t}}
incorrectly yields 2,100 tons, not 2,352 tons. Proof: 2,100 long tons (2,100 t)How to fix? Or can someone else correct the conversion? 50.107.153.113 ( talk) 21:23, 17 September 2020 (UTC)
{{convert|3900|LT|ST}}
more correctly yields 4,400 tons, not 4,368 tons. Proof: 3,900 long tons (4,400 short tons){{convert|2100|LT|ST}}
more correctly yields 2,400 tons, not 2,352 tons. Proof: 2,100 long tons (2,400 short tons){{convert|3900|LT|ST|abbr=off|}}
→ 3,900 long tons (4,400 short tons){{convert|2100|LT|ST}}
→ 2,100 long tons (2,400 short tons){{convert|3900|LT|ST|abbr=off|0}}
→ 3,900 long tons (4,368 short tons){{convert|2100|LT|ST|0}}
→ 2,100 long tons (2,352 short tons)Everyone who worked on this Temp really knows what they're doing. I'm very impressed. Invasive Spices ( talk) 22:41, 2 October 2020 (UTC)
{{long ton|166| 6| 2}} 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t) does not work but this {{long ton|166| 6}} 166 long tons 6 cwt (372,500 lb or 169 t) does work. Talk:South Australian Railways 700 class (steam)#A flaw? Peter Horn User talk 00:43, 22 November 2020 (UTC)
{{long ton|166|6|2}}
→ 166 long tons 6 cwt 2 qr (372,570 lb or 168.99 t)I've been impressed with how developed and flexible this template is. Ultimately, I assume that the place we want to end up is with an option in user preferences that allows choosing a unit/currency/etc. system, so that a British reader could see meters even when reading a U.S. article and a U.S. reader feet even when reading a British one, without the clutter of the other unit. How far are we from making this a reality? Is it just a matter of doing some complicated programming, or are there particular obstacles from the way articles are written, or are there editorial concerns about e.g. fracturing the encyclopedia? {{u| Sdkb}} talk 18:49, 21 September 2020 (UTC)
Another issue: I might use a meter to measure 5 metres! Martin of Sheffield ( talk) 20:45, 21 September 2020 (UTC)
https://physics.nist.gov/cuu/pdf/sp811.pdf section 7.6 This Guide takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible . This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using — the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and — the symbols for the units, not the spelled-out names of the units. Examples:
--end-quote -- Bold added by me.--
The bold should be enough to use the symbols, not the full text. A couple of points to add:
We are not introducing a meter (m) as this is known and understood. However a concept like Performance Management (PM) would still be introduced in this manner.
Also, I would like to just point out that saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m. If that m truly has to be introduced, then the first mention should be 5 meter (m). Note that I also changed the 5 meters into 5 meter (5 meters is not allowed for sure). Hence 5 m works easier and better, because you can read it the way you want even as five metres if you want.
My only additional advice would be to avoid d(deci), D(Deka) and H(Hecto) at all cost to make the text readable. Stick to micro, milli, kilo and Mega. Note that I strategically forgot to mention centi. Should not be used in this logic, but is just to pervasive to ignore in the older UOMs.
I am actually not trying to create a huge stir here. But abbr=on should be used and not using it the first time does not add value and so abbr=on should be used for all. Also keep text readable by not using 0.5 km (1,640.4 ft) however true this statement is. It creates an assumption of precision in the translated unit that was not there in the original UOM. So wiki does this almost correct with 0.5 km (1,600 ft); just don't add |0 or |1 as I see very often — Preceding
unsigned comment added by
Frankk20168 (
talk •
contribs) 07:03, 28 November 2020 (UTC)
saying 5 meters in the beginning of the text does not do anything to help understand a next sentence or a sentence a page away that mentions (e.g.) 10 m.because this is not a paper encyclopedia. For a common unit, it doesn't matter so much, but we could write "five metres" and more importantly, we will write "five chains" on first use, where the hyperlink for an uncommon unit allows the reader to establish the magnitude of the unit as well as its abbreviation if they are unfamiliar with it. That definitely helps a reader get to grips with 63 ch when they see that at the second mention.
|abbr=
for the reasons already rehearsed. When you've actually used
Template:Convert, you'll find that it does a really good job of dealing with precision by default and {{convert|0.5|km|ft}}
produces 0.5 kilometres (1,600 ft)
, which is as good a conversion as anyone will want most of the time. There are edge cases where the default precision isn't optimal, but the fixed decimal places option and rounding to a given number of significant figures functionality are available to improve the display in those cases. --
RexxS (
talk) 13:02, 28 November 2020 (UTC)On you ch example, I also agree. That should be introduced. My point is normal SI units should not be introduced. The meter being prime among them. This is what REUTERS has to say about it:
kilogram
Use kg (no full stop, same singular and plural) at all references. To convert to pounds multiply by 2.205.
kilometre
Use km (no full stop, same singular and plural) at all references, except in a phrase such as hundreds of kilometres.
km per hour
First reference, kph on second and subsequent references.
/quote Obviously I have problems with the last statements (the kph part). But I included it to get part of your point in, too. Again, I completely agree to introduce 5 feet and then followed by 10 ft (or even 10') later. or 63 chain and then 60 ch. My contentions was for the basic SI units (And I admit I added basic here for the first time), they should not be spelled out. Introducing 100 kilometer per hour is just a painful read. It also introduces at least two issues: Should it be: 100 kilometer per hour 100 kilometers per hour 100 kilometre per hour 100 kilometres per hour All these four variations get resolved by making it 100 km/h. Again, I agree with most of what you are saying. The above on Si unit L, m, km and kg we have different opinions. I would also like to point out that "15,000 pounds per square inch (100,000 kilopascals)" (An actual copy from a paste from a Wiki page) is a painful read that does not help (Americans know that PSI ha something to do with their tire pressure, it is never spelled out. The 100,000 kilopascals is too much. Both also have the problem of the added s. I realize we will never get on exactly the same page. So here is the summary of my advice (incorporating your feedback):
I hope this helps and also creates some reasonable guidelines that can help. — Preceding unsigned comment added by Frankk20168 ( talk • contribs) 06:09, 30 November 2020 (UTC)
Not really about the template itself, but I was reverted at General Electric GE9X when adding the template because "the source contained both values". WP:Integrity was cited, which doesn't say anything about this. Is there really a valid reason to not use the template? MB 16:31, 8 December 2020 (UTC)
As I noted in
Help talk:Convert, it seems that {{convert|1.6|Mach}}
Mach 1.6 (1,960 km/h; 1,220 mph) doesn't set sigfig based on the input value. It was suggested to ask here about it. I don't know if this is specific to Mach, though. I put sigfig=2 in the one case I found, and don't know how many others there might be. Is there a regexp search good enough to search for them?
Gah4 (
talk) 14:04, 8 December 2020 (UTC)
This template/module uses the visualhide class. It has a TemplateStyles solution and will accordingly be removed from Common.css soon. Your feedback regarding the timeline is requested at MediaWiki talk:Common.css § visualhide removal. Izno ( talk) 17:10, 2 December 2020 (UTC)
Yes, I'm too lazy to have thought of that myself, and it was copied. Nothing about convert is simple. Examining an enwiki dump of articles from June 2020 shows:
Template | Total | Fractions | Percentage |
---|---|---|---|
convert | 3,145,551 | 13,182 | 0.4 |
cvt | 107,257 | 421 | 0.4 |
Should the 3 million convert usages output a template style that is used by only 0.4% of them? Where would that templatestyles be placed? Johnuniq ( talk) 23:25, 2 December 2020 (UTC)
|disp=table
usages and possibly others? Would they work painlessly?
Johnuniq (
talk) 23:55, 2 December 2020 (UTC){{convert|47.5|kg|lb|disp=table}}
→ style="text-align:right;"|47.5\n|style="text-align:right;"|105
frame:extensionTag
were prepended to where <span class="visualhidesr-only">
were output, I wouldn't expect there to be any fundamental issues.
fracfmt
is handled between the two code paths where it is used versus its earlier definition: 1 definition has 3 replaced patterns with %s, the other three have 4; whereas the calling sites expect 4 patterns total. (And anyway, it's a hack in an unfamiliar codebase, so forgive me any sins. ;)fracfmt
to decrease the output regardless when displaying as a fraction by moving the inline styles there to TemplateStyles and/or from include to unstrip budgets (pending Anomie on the second part). This could either rely on {{
frac}}'s TemplateStyles, or since we're here, a new
Module:Convert/styles.css for the stuff unrelated to sr-only. (I see other places you might entertain a move as well; I count some 10-15 uses of style=
.)data-sort-value
surrounding the contents when used in table form. I do not know how it will do as a naked convert in a sortable table with the style/link elements.
TheDJ might have some knowledge there.<style>
for every use and they're then deduplicated, and apparently the unstrip size is measured before deduplication.
Anomie
⚔ 17:02, 3 December 2020 (UTC)@ Izno: Re Module:Convert/sandbox: Sorry that I have ignored the issue due to normal turmoil. However, I think about what should be done and I have a plan for handling styles in convert. I should get around to it in the next couple of days. Another plan I've had for years is to fix Module:Convert/tester so it changes the unique number in strip markers to be, say, all zeroes so the comparisons won't break. Johnuniq ( talk) 23:40, 11 December 2020 (UTC)
I'll record here that I tweaked Module:Convert/tester to normalize strip markers but on checking the effect I realize that the method is broken. It probably would work as a comparison but it won't display the Expected results correctly because the strip markers have been replaced with fake ones. I'll contemplate what to do about that. Johnuniq ( talk) 09:02, 12 December 2020 (UTC)
...the "calculate" template ? EOLE79 ( Talk ?) 10:28, 12 December 2020 (UTC)
It would be useful if this template could be used to define the thousands separator differently for each converted unit. For instance, when using the template to convert AU to both km and mi, it would be nice to be able to specify gap for kilometers and comma for miles, as gaps are not usually used for miles but are for kilometers, especially for science-related articles like one using AU. Lexicon (talk) 19:51, 26 October 2020 (UTC)
The example from there (without the redundant |lk=off
) is:
{{convert|0.1|AU|km mi|abbr=on}}
→ 0.1 AU (15,000,000 km; 9,300,000 mi){{convert|0.1|AU|km mi|abbr=on|comma=gaps}}
→ 0.1 AU (15000000 km; 9300000 mi)The second convert shows how it would look with gaps, and here is how it is wanted:
I'm unsure whether that would be useful. Johnuniq ( talk) 23:09, 26 October 2020 (UTC)
gaps are not usually used for miles but are for kilometers. In my experience they're independent issues, and the mixed format above looks wretched. E Eng 23:42, 2 December 2020 (UTC)
The space separator is used in french !
The apos is used in calculators !
EX : 7786554443 is 77 866 554 443 (french) or 77'866'554'443 (calculators). EOLE79 ( Talk ?) 10:40, 12 December 2020 (UTC)
Hello, I ran into this (aesthetic) problem on Brick while editing the per-country dimensions of a brick in a table, partially reproduced here:
EXAMPLE TEMPORARILY DISABLED BECAUSE IT WAS SENDING THE RENDERING SOFTWARE INTO ORBIT
Using "lk=on|disp=table|abbr=on" (first row) gives me the unit on each of the measurements. Ideally, I'd like "25 × 50 × 75 mm (1 × 2 × 3 in)", but this doesn't quite work when I try it with other flags.
{{convert|225|×|112.5|×|75|mm|in}}
→ 225 by 112.5 by 75 millimetres (8.86 in × 4.43 in × 2.95 in){{convert|225|×|112.5|×|75|mm|in|abbr=on}}
→ 225 mm × 112.5 mm × 75 mm (8.86 in × 4.43 in × 2.95 in)It seems adding "abbr=on" forces the separation to use "×", but also displays the units on every number instead of the last one. I suspect "disp=table" hides the units altogether, but combining it with another flag like "lk=on" or "abbr=on" overrides that. Can we change "abbr=on" to only display units on the final number? This seems inconsistent.- Ich ( talk) 16:04, 11 December 2020 (UTC)
{{convert|230|×|110|×|76|mm|in|disp=table}}
like most other tables do? The units are in the heading and should not be repeated in each row. There is no need to link mm or inches, but if really needed, there is sure to be somewhere close by in the text (not in the table) where that could be done. Or, the unit names in the heading could be linked. However, convert retains two seldom-used features that are available if really really needed. There is no repeated unit symbol with *
or xx
. *
outputs × with no spacing, while xx
outputs × with a nonbreaking space on each side. You would use one of these in a table:
{{convert|230|*|110|*|76|mm|in|lk=on|disp=table|abbr=on}}
{{convert|230|xx|110|xx|76|mm|in|lk=on|disp=table|abbr=on}}
x
not ×
in convert. The former is easy to type and easy for other editors to emulate. It gives the same output as ×
.
Johnuniq (
talk) 23:11, 11 December 2020 (UTC)In the lead for Europe, I noticed the slightly jarring juxtaposition of 10,180,000 km2 (3,930,000 sq mi), where the kilometers uses "2" but the miles uses "sq". Looking at the documentation here, it seems to be a U.S. vs. UK thing, but from my experience, "2" is generally more popular in America, too. Have we considered just going to "2" for all uses? {{u| Sdkb}} talk 07:11, 13 December 2020 (UTC)
This sentence is not prescriptive (or, indeed, proscriptive), but it does explicitly permit the use of "sq" and "cu", and I don't feel that it's appropriate to make changes here that would arguably de facto amount to an MOS change. The Europe article mentioned above uses the style in question, I'd presume, because it is the default convert template style – and I'd argue that making something the default convert template style will almost always ipso facto make it the normal style used in the encyclopedia. This is simply because it's the style that the vast majority of editors will default to, even if unknowingly – I presume that most editors don't know there are so many options for customising the exact output of {{convert}}, as I use it extensively and wasn't aware that it was possible to get it to output e.g. "in2" until very recently.sq or cu may be used with US customary or imperial units, but not with SI units.
An IP user asks about a figure in an article: "Her steel hull had an overall length of 350 feet (110 m) (one source states 358 feet (109 m))" How can 350 feet be 110 m but 358 feet is 109 m?
And I say, great question. I look at the article and see that it's getting those values with {{
convert}}, videlicet: Her steel hull had an
overall length of {{convert|350|ft|m}} (one source states {{convert|358|ft|m}})
.
Now, the standard response to this is that precision can be specified when invoking the template, but I don't think this is proper, and especially it's not proper to arbitrarily and invisibly use different rounding based on if the figure ends in a zero. The obvious, and intuitive, use for this template is to do simple arithmetic and multiply feet into meters (indeed, this is how it is used in every article I've seen it). So I had a lively debate with my friend about this, and he pointed out that most uses of "350" or "300" or the like are probably approximate, and giving a precise meter conversion would mislead readers. However, I disagree with the way this has been implemented in the conversion template.
(As someone who's designed and machined parts with some dimensions measured in ten-thousandths of an inch and some dimensions measured in feet, and communicated with both PhDs and CEOs about these parts: when someone writes "350", in the vast majority of cases, it does not mean "350 ± 5" -- and if it does mean the former, they will say "about 350"; the word "about" doesn't have a standardized error bar on it, and I'd almost go so far as to call it WP:OR to imply so.)
But for concrete suggestions: first of all, my issue with this is not the rounding: 350.00 feet is 106.68 meters, which would be a silly amount of precision to give, and I'd be fine with presenting it as 107. I'd even be fine with the template rounding to significant figures whenever precision wasn't specified. However, the current state of affairs is that the template will round to the nearest meter, unless the number ends in a zero, in which case it will silently make the number ten times less precise, in a way that is never made apparent to the editor or the reader.
Exemplis grata:
The building was {{convert|345|ft|m}} tall
= "The building was 345 feet (105 m) tall"The building was {{convert|350|ft|m}} tall
= "The building was 350 feet (110 m) tall"The building was {{convert|355|ft|m}} tall
= "The building was 355 feet (108 m) tall"The building was {{convert|360|ft|m}} tall
= "The building was 360 feet (110 m) tall"If you were an editor and hadn't read five full screens of template documentation (or if you're a Wikipedia reader, who doesn't even know what templates are), would this make sense to you if you saw it in a page? Would it be immediately apparent, if you only saw one of these examples, that every other measurement was being rounded to the nearest 10m and not the nearest 1m?
I think that this is fairly counterintuitive; if the default behavior is to perform different conversions based on the last digit of the number, it should say "approx." or in some way indicate when it's using an alternative conversion scheme. A template should not be making blanket assumptions about the precision of numbers in articles and presenting them as fact. jp× g 01:54, 10 December 2020 (UTC)
{{convert|12000|mi}}
in the second paragraph which starts with "More than 12,000 miles (19,000 km) of roads". Rounding to the nearest km would give "More than 12,000 miles (19,312 km) of roads". While there are examples of convert's default behavior giving bad results, there are plenty more where the results are good. If someone unfamiliar with the template wonders why silly numbers are being shown (such as in the above), they can ask here or at
WP:HELPDESK for assistance.
Johnuniq (
talk) 03:52, 10 December 2020 (UTC)
The building was {{convert|358|ft|m}} tall
= "The building was 358 feet (109 m) tall"The building was {{convert|350.|ft|m}} tall
= "The building was 350 feet (107 m) tall"The model was {{convert|3.45|ft|m}} tall
= "The model was 3.45 feet (1.05 m) tall"The model was {{convert|3.50|ft|m}} tall
= "The model was 3.50 feet (1.07 m) tall"The model was {{convert|3.55|ft|m}} tall
= "The model was 3.55 feet (1.08 m) tall"The model was {{convert|3.60|ft|m}} tall
= "The model was 3.60 feet (1.10 m) tall"The model was {{convert|3.5|ft|m|sigfig=3}} tall
= "The model was 3.5 feet (1.07 m) tall"The model was {{convert|3.6|ft|m|sigfig=3}} tall
= "The model was 3.6 feet (1.10 m) tall"I've also struggled with this for years but it's not a simple problem to solve. My use of convert is mostly for cars - where 350 always means 350±1. But I also recognise that other subjects use bigger numbers where 35,000 often means 35,000±500. Solutions are:
|0
or |1
or |round=5
at the end of most conversions for car articles.My preference would be #2 but really both #2 and #3 are valid solutions with similar pros and cons. We can't make everybody happy and the current solution is a very good attempt at making as many people as happy as possible. The only improvement I can think of is to make the rounding issue more prominent in the documentation. Stepho talk 00:56, 13 December 2020 (UTC)
This was previously request ( Template talk:Convert/Archive October 2015#Ton-mile and passenger-mile) but, as far as I can tell, never implemented. 1 ton-mile = 1.459972 tonne-kilometers. (see Units of transportation measurement) Would it be possible to implement this conversion? Hawkeye7 (discuss) 19:42, 17 December 2020 (UTC)
I added the units at Module:Convert/documentation/conversion data#Transportation and included them in the module. If these are used in articles in the next couple of days (before the #Module version 25 release above), they will be included in the main data. Otherwise, they will be temporary. Examples (please check!):
{{convert|1|tkm|6|abbr=on}}
→ 1 tkm (0.684944 ton-miles){{convert|1|ton-mile|6|abbr=on}}
→ 1 ton-mile (1.459972 tkm){{convert|1|tkm|abbr=off}}
→ 1 tonne-kilometre (0.68 ton-miles){{convert|1|ton-mile|abbr=off}}
→ 1 ton-mile (1.5 tonne-kilometres){{convert|2|tkm|abbr=off|lk=on|sp=us}}
→ 2
tonne-kilometers (1.4
ton-miles){{convert|2|ton-mile|abbr=off|lk=on|sp=us}}
→ 2
ton-miles (2.9
tonne-kilometers)Johnuniq ( talk) 02:40, 18 December 2020 (UTC)
Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
{{convert|1+1/2|by|5+3/4|in}}
).gramme
from the
unit definitions. This is not a change to units as gramme
is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future.
MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at
MOS talk July 2019 following a request
here.mi/kWh
is retained in extra; it will be removed if not found to be used in articles.scf2
and scfoot2
in articles will be replaced with scf
and scfoot
which have had their link corrected to
standard cubic foot. Discussion
here.mw.wikibase.getLabel(X)
instead of deprecated mw.wikibase.label(X)
.Release notes for earlier versions are listed here. Johnuniq ( talk) 06:13, 14 December 2020 (UTC)
Thanks, good points. Re convert/text, I did wonder about that and I suppose I should be less lazy. I imagine "margin" should also be used here but the html is over my head. @ Izno: Any opinion on that?
Here are some results from Special:ExpandTemplates if anyone wants to compare the outputs.
{{convert/sandbox|1//2|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">1</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">2</span></span> foot (6.0 in)
{{sfrac|1|2}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac nowrap tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">1</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">2</span></span>
{{sfrac/sandbox|1|2}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac tion"><span class="num">1</span><span class="sr-only">/</span><span class="den">2</span></span>
{{convert/sandbox|1+2//3|ft|in}}
<templatestyles src="Screen reader-only/styles.css"></templatestyles><span class="sfrac nowrap">1<span class="sr-only"> </span><span style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span style="display:block; line-height:1em; padding:0 0.1em;">2</span><span class="sr-only">/</span><span style="display:block; line-height:1em; padding:0 0.1em; border-top:1px solid;">3</span></span></span> feet (20 in)
{{sfrac|1|2|3}}
<templatestyles src="Screen reader-only/styles.css"/><span role="math" class="sfrac nowrap"><span class="int">1</span><span class="plus sr-only">+</span><span class=" tion" style="display:inline-block; vertical-align:-0.5em; font-size:85%; text-align:center;"><span class="num" style="display:block; line-height:1em; margin:0 0.1em;">2</span><span class="slash sr-only">/</span><span class="den" style="display:block; line-height:1em; margin:0 0.1em; border-top:1px solid;">3</span></span></span>
{{sfrac/sandbox|1|2|3}}
<templatestyles src="Frac/styles.css"/><span role="math" class="sfrac ">1<span class="sr-only">+</span><span class="tion"><span class="num">2</span><span class="sr-only">/</span><span class="den">3</span></span></span>
Johnuniq ( talk) 09:43, 14 December 2020 (UTC)
I'm not sure whether you are hinting that Template:Frac/styles.css should be used by convert.Yes, I'm hinting that. It is by no means required of course, but it should dramatically reduce the implementation here (+- the futzing to make sfrac act as expected because I noticed how it is coded in the frac templates and how it is coded here is marginally different).
But it's extra pain for people trying to copy the current version of convert to another site.I've never really put a lot of stock in this as a rationale for anything on en.WP, and not often do I care too often when the module of interest already has a dozen pages to copy; what's one (two?) more? So long as the documentation is clear about all the used pages (as is usual for larger modules), it's rarely an issue.
is what it does ok at least for nowI have no great issues with the now. I do have some issue with the frac implementation, both live/sandbox here and at the template itself, using <sub> and <sup>, and that is why I suggested the sandbox version there to be implemented here now. If you want to play with it some more or want some help understanding what's going on, I wouldn't want to block version 25 on it. -- Izno ( talk) 18:44, 15 December 2020 (UTC)
+
(what should convert do)? For my curiosity, what is role="math"?
Johnuniq (
talk) 23:22, 15 December 2020 (UTC)
As I understand it, that would no longer be needed.Yes, that is correct.
In 1+2/3, why does convert output a hidden non-breaking space after 1, but sfrac outputs a hidden +
(what should convert do)?
I do not know why convert is doing that as a non-breaking space, which is superfluous with the whitespace nowrap CSS variously applied to the same. Regarding space versus plus, sfrac shifted to "+" approximately a year ago in
the same edit that added the classes and role. It was noted at the talk page at
Template talk:Frac#Integrity. I changed the frac sandbox recently to follow since I don't see a good reason for inconsistency. I could personally flip a coin on the pros and cons of + and space character, though I tend toward the semantic + rather than the unsemantic space as my decider. I generally agree with your 3 listed design criteria there.For my curiosity, what is role="math"?An "ARIA role" is a standardized way to assign an HTML element semantics that differ from its default semantics. For example, if you have a layout table, you can assign it
role="presentation"
to indicate that it is not a proper data table per the default HTML semantic assignment for <table>
elements (we have a lot of unfortunate legacy on that point, so we've bolted on a lot of role="presentation"
). It is primarily intended for enhanced accessibility. See also
MDN. role="math"
in particular is
described as Content that represents a mathematical expression.See the link for more details. Whether sfrac and frac should use it is a question mark to me. Given the context of sfrac, I think it may make sense for sfrac generally. For frac, I can probably buy into it when the fraction is marked up with a hidden +. I wouldn't add it without the + in frac. -- Izno ( talk) 21:34, 16 December 2020 (UTC)
{{convert/sandbox|1/2|ft|in}}
→ 1⁄2 foot (6.0 in){{convert/sandbox|1+2/3|ft|in}}
→ 1+2⁄3 feet (20 in){{convert/sandbox|1//2|ft|in}}
→ 1/2 foot (6.0 in){{convert/sandbox|1+2//3|ft|in}}
→ 1+2/3 feet (20 in){{frac/sandbox|1|2}}
→ 1⁄2{{frac/sandbox|1|2|3}}
→ 1+2⁄3{{sfrac/sandbox|1|2}}
→ 1/2{{sfrac/sandbox|1|2|3}}
→ 1+2/3@ Izno:: Please see the experiment in my sandbox ( permalink). That shows quite a large difference in the vertical space occupied by the old and new styles of formatting fractions. I'm wondering if using a fraction (with {{ convert}} or {{ frac}}) might introduce a visually unpleasant vertical gap in the line spacing. Any thoughts? Johnuniq ( talk) 09:49, 19 December 2020 (UTC)
<sup>...</sup>
and <sub>...</sub>
are setting line-height to 1em (which is rendered as 10.16px on my Monobook skin). The corresponding classes .num
and .den
in the sandbox leave the line-height at default, which is 1.5em (rendered as 19.05px on my Monobook skin because the em is also different for the two cases). The two parts of the fraction poke above and below the line of the rest of the text, so need a smaller line-height to prevent the gaps you are seeing. I don't want to fiddle with your stylesheets, but I think that reducing the line-height for the .num and .den classes by about 50% somehow will ease the problem for you. Cheers --
RexxS (
talk) 20:59, 19 December 2020 (UTC)
span class="cvt frac nowrap"
for four extra bytes, then you would create .cvt .frac .num { line-height: 0.5em; }
and .cvt .frac .denom { line-height: normal; }
in
Template:Frac/styles.css so that the adjusted line spacing would only apply to the output of convert. In any case, it's commendable to worry about the load on the servers, but we don't pay them on
piece-work rates, so it's not going to hurt if you put an extra job in the queue once in a while. --
RexxS (
talk) 01:33, 20 December 2020 (UTC)I edited the sandbox convert to use the sandbox styles and have used subst so they continue to use the styles shown.
Please compare these two pages. The latter is working perfectly, thanks RexxS. Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst. Another weirdness is that I see a small vertical gap after the first "It's a long way to the next town." (that gap was always there but I couldn't see a reason for it). Johnuniq ( talk) 02:54, 20 December 2020 (UTC)
Interestingly, when I tried to show the two results on the one page, the latter style seemed to overrule the former even after I had used subst.Indeed, this is expected; see Rexx. There is a way to work around it that is kind of a pain (setting the sandbox templatestyles invocation to add the attribute
wrapper=".sandbox"
as in <templatestyles src="Example/sandbox/styles.css" wrapper=".sandbox"/>
and then wrapping some content in the same page as your other case with the sandbox class). See
mw:Extension:TemplateStyles#Usage. --
Izno (
talk) 17:13, 20 December 2020 (UTC)How may I combine conversion, range, and adjective? For example, I am attempting to write "300-by-500-foot-wide (984 to 1641 m)." CapeVerdeWave ( talk) 17:26, 19 December 2020 (UTC)
{{convert|300|by|500|ft|m|adj=on}}
→ 300-by-500-foot (91 by 152 m)300-by-500-foot-wideeven means, much less how by + wide somehow become to. E Eng 05:32, 20 December 2020 (UTC)
{{convert|300|to|500|ft|m|adj=on}}
→ 300-to-500-foot (91 to 152 m){{convert|300|to|500|ft|m|adj=mid|-wide}}
→ 300-to-500-foot-wide (91 to 152 m){{convert|300|to|500|m|ft|adj=on}}
→ 300-to-500-metre (980 to 1,640 ft){{convert|300|to|500|m|ft|adj=mid|-wide}}
→ 300-to-500-metre-wide (980 to 1,640 ft)
Module:Convert/helper does some pre-Convert input cleanups. For this it also replaces, for example, ⁄
with /
: good. This simplifies later string handling jobs like search&replace, etc. See this code:
text = text:gsub(' ', ' '):gsub(' +', ' '):gsub(' *%+ *', '+'):gsub('⁄', '/'):gsub('⁄', '/')
. All fine so far.
Now Lua has a function that replaces these &...;
html entities (character id's), all in one go:
mw.text.decode. (which is available through
Module:DecodeEncode; by me; pre-alpha).
So I'd ask you to consider: could this be an improvement? Sure it's only efficiency & systematic completeness, not squashing a bug. And maybe the pre-apha status is to be looked at. - DePiep ( talk) 23:44, 25 December 2020 (UTC)
to  
and does not change ⁄
. I put a test at
Module:Sandbox/Johnuniq/temp—see results at
its talk where a mid dot (·) is used to replace each space.
Johnuniq (
talk) 01:29, 26 December 2020 (UTC)
With most large areas, I'm used to seeing acres "traditionally" paired with hectares. Lately, however, I've been seeing more and more instances paired with square kilometers instead. Has there been a consensus reached (or changed) regarding which unit acres should be paired with? I just wondered; I'm not sure if this is the best place to ask, but I also don't know where else that would be.
Are there situations where one unit or the other is preferred? Or are hectares now considered "archaic"? :)
Thanks! 1980fast ( talk) 02:19, 24 December 2020 (UTC)
acre
is ha
. For example, {{convert|123|acre}}
shows 123 acres (50 ha). Where do you see km2 (square kilometers)? There is no preference or consensus adjustment at this page, but it's possible that people in one region are used to ha while those somewhere else see km2.
Johnuniq (
talk) 02:55, 24 December 2020 (UTC)
{{convert|67000|acre|km2}}
with different numbers. An editor has chosen to specify that the output should show the km2 value by specifying km2
as the output unit. That choice is an editorial matter which is outside convert's scope. If the area is wanted in hectares, replace km2
with ha
or omit |km2
. People have outlined the factors involved in making a choice in this section. All converts concerning area in that article (there are seven of them) show the output in km2.
Johnuniq (
talk) 03:59, 28 December 2020 (UTC)The proper counterpart of the acre is the hectare. Hawkeye7 (discuss) 04:13, 24 December 2020 (UTC)
When I was a kid, the fields were typically measured in Morgen (2500 m2; unit symbol Mg); I reckon this is what the metric (not SI!) counterpart of an acre would be. However, everyone understands what a hectare is, and Morgen is only used in rural areas nowadays. Best regards, -- Johannes ( Talk) ( Contribs) ( Articles) 22:00, 26 December 2020 (UTC)
everyone understands what a hectare is", don't make assumptions. I cannot visualise what a hectare is, and either mentally dismiss it as "several acres" or else go and look for a conversion. A square kilometer on the other hand is slightly larger than 1⁄4 square mile which is good enough. In passing it does rather amuse me that the SI enthusiasts react with horror at any mention of non-metric customary units and yet plead intensely for metric but non-SI customary units! Think of a sentance including "sauce", "goose" and "gander". :-) Martin of Sheffield ( talk) 22:32, 26 December 2020 (UTC)
How about the priority of SI units and non-SI units?
What to do if a existing table uses the non-SI values and calculates them into SI units? --
Angerdan (
talk) 14:53, 1 January 2021 (UTC)
|order=flip
or |order=out
.
WP:UNITS says SI first is used for most articles, with exceptions for some US and UK articles.
Stepho
talk 22:53, 1 January 2021 (UTC)In the US modern engine volumes are often in liters or cubic centimeters, which are often converted to cubic inches, but it does not appear that either is a allowed conversion. Can this be added to the template?-- Sturmvogel 66 ( talk) 14:05, 26 December 2020 (UTC)
{{convert|1300|cc|cuin}}
→ 1,300 cubic centimetres (79 cu in){{convert|95|cuin|L}}
→ 95 cubic inches (1.56 L){{convert|44|L|cuin}}
→ 44 litres (2,700 cu in)|sp=us
for "liter" spelling if appropriate for article.
Johnuniq (
talk) 22:16, 26 December 2020 (UTC)
The text actually output from {{
convert}} has a space in cu in
, of course. It might be best to think about the units used in convert
as having three forms: the "unit name", the "unit symbol", and what you might consider a "unit code" that is used as a parameter in the template to represent that unit. These unit codes generally don't have spaces in them, even if the unit name or symbol does, because the space is used to separate multiple outputs. The three forms may be identical, similar, or different:
Unit code to use as parameter | Unit symbol | Unit name |
---|---|---|
acre | acre | acre |
L | L | litre (liter if |sp=us )
|
cuin | cu in | cubic inch |
For example, {{convert|2500|cm3|cuin L|abbr=on}}
→ 2,500 cm3 (150 cu in; 2.5 L) and {{convert|2500|cm3|cuin L|abbr=off}}
→ 2,500 cubic centimetres (150 cubic inches; 2.5 litres). The unit codes in those don't have spaces, even though the unit names and symbols may do. If your guess at the unit code produces an error, then removing any spaces often fixes it. --
RexxS (
talk) 00:31, 2 January 2021 (UTC)
…but why does a unit code even exist? I guess this only causes confusion (this is a perfect example) – I'd recommend making all possible unit symbols work as "unit codes" Johannes ( Talk) ( Contribs) ( Articles) 02:56, 2 January 2021 (UTC)
{{convert|10|km|mi nm nmi}}
→ 10 kilometres (6.2 mi; 1.0×1013 nm; 5.4 nmi). -
DePiep (
talk) 13:12, 2 January 2021 (UTC)Can the template handle such conversions? I saw an option for multiple dimensions, but it doesn't seem to go beyond two dimensions, so I can't quite visualize how to do it. Thanks! 1980fast ( talk) 03:20, 7 January 2021 (UTC)
{{convert|3|x|4|x|24|in}}
→ 3 by 4 by 24 inches (76 mm × 102 mm × 610 mm){{convert|3|x|4|to|6+1/2|x|8+3/4|in}}
→ 3 by 4 to 6+1⁄2 by 8+3⁄4 inches (76 mm × 102 mm to 165 mm × 222 mm)Is there a way to convert scientific notation with a confidence interval using this template? What I would like to get is
but the template gives me either
or
Perhaps it's just a bad idea to do unit conversion in this case, even the "right" answer is rather cumbersome. Tercer ( talk) 07:38, 21 January 2021 (UTC)
Is it possible to format the conversion such that there are no extra parentheses added? A use case for this would be a conversion done within an existing parenthetical statement.
For example, say that someone has just mentioned a mountain, followed by "(elev. xxxx feet)". What if you wanted the conversion to read "(elev. xxxx feet; xxx meters)" in order to avoid the messiness that comes with nested parentheses? Thanks! 1980fast ( talk) 21:45, 22 January 2021 (UTC)
(elev. {{convert|10|m|ft|disp=comma}})
→ (elev. 10 metres, 33 ft)I was looking at the page for Darigold, a dairy cooperative, and it mentions their annual production of milk – a staggering 8.6 billion pounds a year. The template used is a simple conversion to kilograms, however, the metric output is given in scientific notation, which isn't exactly accessible for the average reader. Is there any way to make both values output a conversion that is more directly comparable, perhaps with the numbers reformatted, like "8.6 billion pounds (3.9 billion kg)" ?
If that's not possible, is it at least possible to suppress the scientific notation? I'm not even sure how it came into play, since the input value is displayed without problem. Thanks! 1980fast ( talk) 07:25, 26 January 2021 (UTC)
abbr=unit
or abbr=off
. You need one of these to get the word million/billion for the output. Unfortunately you can't have "pounds" (name) and "kg" (symbol) and number words.
{{convert|8,600|e6lb|e6kg|abbr=unit}}
→ 8,600 million lb (3,900 million kg){{convert|8,600|e6lb|e6kg|abbr=off}}
→ 8,600 million pounds (3,900 million kilograms){{convert|8.6|e9lb|e9kg|abbr=unit}}
→ 8.6 billion lb (3.9 billion kg){{convert|8.6|e9lb|e9kg|abbr=off}}
→ 8.6 billion pounds (3.9 billion kilograms)For Iztapalapa#Elevation and climate could we have disp=/ and/or disp=s? eg ({{cvt|2,400|m|ft|disp=/}} asl) (2,400 m (7,900 ft) convert: invalid option asl) instead of ({{cvt|2,400|m|ft|disp=or}} asl) (2,400 m or 7,900 ft asl) Peter Horn User talk 22:08, 4 February 2021 (UTC)
I was wondering if there should be "earth pounds" which can be useful on pages such as moon. Cause pound and kilograms are different. Pound is weight and kilograms is mass. Pound per kilogram depends on the gravity force. The Channel of Random ( talk) 00:45, 13 February 2021 (UTC)
For Low Light of the Hook of Holland#History and elsewhere would it be possible to have (a) conversion(s)? say for example {{convert|2,000|cp|lm}}. Peter Horn User talk 16:58, 19 February 2021 (UTC)
11:32, 7 May 2019 Anthony Appleyard moved page Millimeter of mercury to Millimetre of mercury: Requested by Getsnoopy at WP:RM/TR: WP:COMMONALITY and because "metre" is standardised across WP — Preceding unsigned comment added by 2001:8a0:5e58:9a00:e992:745b:11c:c2cd ( talk • contribs) 20:43, 3 March 2021 (UTC)
{{convert|12|mmHg|abbr=off|lk=on}}
→ 12
millimetres of mercury (1.6
kilopascals)For Straight-six engine#Australia 6,000 rpm (100 Hz) & 2,750 rpm (45.8 Hz). Would it be possible to have {{cvt|6,000|rpm|Hz|lk=on}} 6,000 rpm (100 Hz) & {{cvt|2,750|rpm|Hz|lk=on}} 2,750 rpm (45.8 Hz)? rpm Hz Peter Horn User talk 00:44, 9 March 2021 (UTC)
{{convert|1|rpm}}
→ 1 revolution per minute (0.017 Hz){{convert|12|rpm|Hz|abbr=on}}
→ 12 rpm (0.20 Hz){{convert|12|rpm|Hz|abbr=off}}
→ 12 revolutions per minute (0.20 hertz){{convert|6000|rpm|furlong}}
6,000 revolutions per minute (15,000 furlongs)Folks, we're too trusting! My first example above gave "1 revolution per minute (60 Hz)" which is total junk! Ouch. I'll look at whether this is due to my blunder with the scale or whether the tricky invert stuff actually doesn't work. Johnuniq ( talk) 01:13, 11 March 2021 (UTC)
{{cvt|6000|rpm|Hz|lk=on}}
is currently giving me: 6,000 rpm (360,000 Hz)
GliderMaven (
talk) 01:16, 11 March 2021 (UTC)
@
Peter Horn: Thanks for reporting the discrepancy but it was convert that was wrong—now corrected. By the way, when you see |disp=flip
it would be good if you were to change that to |order=flip
. One of the edits you made changed the first of the following to the second:
{{Convert|9120|cc|cuin|0|disp=flip}}
→ 557 cubic inches (9,120 cc){{Convert|9120|cc|cuin L|0|disp=flip}}
→ 557 cubic inches; 9 litres (9,120 cc)You probably don't want to flip it like that. If you want both cuin and L with L as the input, you need:
{{cvt|9120|cc|L cc cuin|0|order=out}}
→ 9 L (9,120 cc; 557 cu in)Also, please have a look at
Straight-six engine#Displacement range which is showing L
as the second paragraph. It looks like a stray character was inserted.
Johnuniq (
talk) 02:28, 11 March 2021 (UTC)
Can the same conversion be mentioned twice or more in an article, or should this generally be avoided? Kind regards, Willbb234 Talk (please {{ ping}} me in replies) 23:15, 10 March 2021 (UTC)
touchtennis#Court originally had the sentence
However, variances of up to a metre are tolerated…
The convert template let me change it to
However, variances of up to 1 metre (3 ft 3 in) are tolerated…
but I think the original (with conversion) reads better:
However, variances of up to a metre (3 ft 3 in) are tolerated…
Is there an option to use "a"?
Thanks,
cmɢʟee⎆
τaʟκ 21:48, 17 March 2021 (UTC)
Editing this talk is now showing a ghastly edit notice from Template:Editnotices/Page/Template talk:Convert which contains {{ Wikipedia information pages talk page editnotice}}. The previous version was also not very helpful. Any suggestions on wording to fix it? Johnuniq ( talk) 08:51, 18 March 2021 (UTC)
It's just straight up wrong. I have noticed it in an article, Joe Biden may well be 6" tall but that is not 2 metres. I'm just under 6" 2" and I'm 1.85m.
The example given is also wrong, 124" is 37.7m, not 40m. If this has been standardised across all articles then all these conversions are wrong, plain and simple.
Who does one get this rectified? Stefanzi ( talk) 07:29, 18 March 2021 (UTC)
{{convert|5|ft|11+1/2|in|abbr=off|sp=us|cm|0}}
→ 5 feet 11+1⁄2 inches (182 centimeters){{convert|6|ft|0|in|abbr=off|sp=us||0}}
→ 6 feet 0 inches (2 meters)0
" in |0}}
tells convert to round the result to zero decimal places. No output unit was given (because the recent edits removed cm
) and convert used its default for that which is m
. The result was bad rounding due to bad parameters.
Johnuniq (
talk) 08:45, 18 March 2021 (UTC)
{{convert|6|ft|abbr=off|sp=us||2}}
(giving 6 feet (1.83 meters) or not removed the "cm". --
John Maynard Friedman (
talk) 12:38, 20 March 2021 (UTC)I found an article that said a plant's density is "commonly 30 species/m2".
I changed that to :*{{cvt|30|/sqm}}
which results in "commonly 30/m2 (2.8/sq ft)"
It would be clearer if it could still include "species", similar to the way PD/sqkm generates "inhabitants". What about a parameter to override "inhabitants" with another name? I'm sure the text could be just be rewritten in this case, but the existing language seems most succinct. (There is currently no pd/sqm, so that would need to be added also).
On more thing, although /sqm works, I don't see it in the documentation (/sqcm, /sqkm, /sqha, /sqin, /sqacre, /sqmi are all there). MB 16:28, 21 March 2021 (UTC)
{{cvt|30|/m2||disp=preunit|species}}
→ 30 species/m2 (2.8 species/sq ft)/sqm
works is that the unit sqm
is an alias for m2
and convert automatically handles "per" units if it can.
Johnuniq (
talk) 23:08, 21 March 2021 (UTC)
/sqm
and m2
seem to be missing. I'm not clear if you mean that this list is supposed to be complete or not.
MB 23:36, 21 March 2021 (UTC)
Parameter list for |abbr values in and out should list in the description that they are used for "input" and "output" units, respectively, for clarity (i.e. "Use symbol for first (left-hand side) unit (input unit)"). Any other parameters using these identical values should likewise be updated as well. Kehkou ( talk) 06:04, 29 March 2021 (UTC)
|order=flip
and |order=out
is used{{convert|100|mph|km/h|0|abbr=in}}
|
→ | 100 mph (161 kilometres per hour) |
{{convert|100|mph|km/h|0|abbr=in|order=flip}}
|
→ | 161 km/h (100 miles per hour) |
{{convert|100|mph|km/h m/h mph|0|abbr=in}}
|
→ | 100 mph (161 kilometres per hour; 160,934 metres per hour; 100 miles per hour) |
{{convert|100|mph|km/h m/h mph|0|abbr=in|order=out}}
|
→ | 161 km/h (160,934 metres per hour; 100 miles per hour) |
{{convert|100|mph|km/h m/h mph|0|abbr=out|order=out}}
|
→ | 161 kilometres per hour (160,934 m/h; 100 mph) |
For Nevada Northern Railway, how would one convert 40 million net ton-miles to net tonne-kilometers? Peter Horn User talk 13:28, 13 April 2021 (UTC)
With:
(million net ton-miles)
(million net tonne-kilometres)
(Mass of a ton in 10³ kg)
(Length of a mile in 10³ m)
Then:
Best regards, -- Johannes ( Talk) ( Contribs) ( Articles) 15:42, 13 April 2021 (UTC)
{{convert|40|e6ton-mile|e6tkm}}
→ 40 million ton-miles (58×10 6 tkm){{convert|40|e6ton-mile|e6tkm|abbr=off}}
→ 40 million ton-miles (58 million tonne-kilometres)"Learning" editor here! I am pretty sure the "adj" parameter is missing from the parameter list and that all its possible values are incorrectly included in the "abbr" section. I am pretty sure I know how to fix it (I messed around in my sandbox), but I've never edited a template doc or done much work with a wikitable before. Can someone more experienced either tell me it's ok to attempt a fix, fix it themselves, or tell me I'm wrong? Thanks in advance! Firefangledfeathers ( talk) 02:46, 12 April 2021 (UTC)
@ DePiep: Just a question – why would anybody want to sort the table by parameter value? And it doesn't effect the reader's ability to search for whatever they like, unless your web browser's search function is stuck in 'whole words only' mode. WT79 ( speak to me | editing patterns | what I been doing) 18:17, 13 April 2021 (UTC)
{{convert|100|ft|m|adj=mid|-deep}}
, then I want to look up what "|adj=mid|-deep
" means. I can see it is two parameters, and can guess what the final one is for because I saw it rendered in the article, Therefore what I'd search for would be "|adj=mid
". Since the parameter
column includes both parameter and value (due to a recent edit linked above) it doesn't make sense to have the values listed separately as well.
WT79 (
speak to me |
editing patterns |
what I been doing) 16:37, 14 April 2021 (UTC)There was recently an RFC that changed MOS:UNITSYMBOLS to require "L" for liter when standalone. (That is to say, "ml" for example is still accepted, though "mL" is allowed.) Presumably this template/module should be changed to output "L" in all standalone cases, including when the input unit is "l". For example, {{convert|123|impgal}} now-incorrectly renders as "123 imperial gallons (560 l; 148 US gal)". -- Beland ( talk) 03:49, 26 April 2021 (UTC)
Is it already possible to use lboz/
as a per unit? Or is that easily added? For example instead of {{convert|235|kg/ha|lb/acre|frac=16}}
in
[9].
Invasive Spices (
talk) 17:47, 29 April 2021 (UTC)
Total pounds of Atrazine applied must not exceed 2lb 8oz/acre per year., the ounces are vital. Invasive Spices ( talk) 19:10, 30 April 2021 (UTC)
This is unusual and rarely comes up, but I just saw something where PD/kg would be needed. I wanted to use {{convert||PD/kg|PD/lb}}, but no such units. You can see it by my <!--- ---> comment in
this edit. Thanks for working on this stuff.
Invasive Spices (
talk) 21:03, 3 May 2021 (UTC)
/kg
by itself wasn't listed in
Module:Convert/documentation/conversion data/doc so I never thought to try it.)
Invasive Spices (
talk) 15:28, 4 May 2021 (UTC)Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
{{convert|1+1/2|by|5+3/4|in}}
).titles
table.gramme
from the
unit definitions. This is not a change to units as gramme
is not currently used in convert. However, I am recording the documentation change in case the issue arises in the future.
MOSNUM states that only gram or kilogram are to be used, not gramme or kilogramme. That was a result of a discussion at
MOS talk July 2019 following a request
here.g0-force
added and unit g0
has symbol g0 with the 0 no longer in italics (
discussion).mi/kWh
is retained in extra; it will be removed if not found to be used in articles.scf2
and scfoot2
in articles will be replaced with scf
and scfoot
which have had their link corrected to
standard cubic foot (
discussion).mmHg
changed to
Millimetre of mercury with re not er spelling (
discussion).rpm
(
discussion).tkm
and ton-mile
(
discussion).mw.wikibase.getLabel(X)
instead of deprecated mw.wikibase.label(X)
.Release notes for earlier versions are listed here. Johnuniq ( talk) 01:16, 4 May 2021 (UTC)
@ Izno: Having convert use {{ fraction}} and {{ sfrac}} templatestyles was discussed in December 2020:
Part of that involved a demonstration that the vertical spacing was a problem:
{{convert/sandbox|1+2/3|ft|in}}
→ 1+2⁄3 feet (20 in) (uses
Template:Fraction/styles.css){{convert/sandbox|1+2/3|ft|in|test=stylesandbox}}
→ 1+2⁄3 feet (20 in) (uses
Template:Fraction/sandbox/styles.css)The vertical spacing problem was fixed by RexxS in Template:Fraction/sandbox/styles.css. However the fix was not used for {{fraction}}. What should convert do? That is, should convert not use templatestyles? Or, should it use the fraction style and ignore the vertical spacing problem? Or, should the style be tweaked somehow? Johnuniq ( talk) 04:38, 14 April 2021 (UTC)
add_style
, and to add an implementation for Sfrac having separate styles, where necessary.
Izno (
talk) 20:37, 27 April 2021 (UTC)
{{convert/sandbox|1+2/3|ft|in}}
→ 1+2⁄3 feet (20 in) (fraction style){{convert/sandbox|1+2//3|ft|in}}
→ 1+2/3 feet (20 in) (sfrac style){{convert/sandbox|18+1/2|in|ft|frac=-2}}
→ 18+1⁄2 inches (1+1/2 ft) (both!)Hi all, After a conversation last month with @ Colonies Chris:, I have started to use the convert template for windspeeds with the following configuration: {{convert|125|kn|km/h mph|round=5|disp=out}} , however, I noticed earlier that the template is not putting the output in brackets 230 km/h; 145 mph. Is there a way to ensure that the output goes into brackets? If so then I strongly suspect that the long running issues that the tropical cyclone project, has had with using the template for windspeeds might be over. Jason Rees ( talk) 02:41, 6 May 2021 (UTC)
{{convert|125|kn|km/h mph|round=5|disp=out}}
→ 230 km/h; 145 mph{{convert|125|kn|km/h mph|round=5|abbr=on|order=out}}
→ 230 km/h (145 mph)Why, when using disp=or
, is unit abbreviation an all-or-nothing proposition?
If I want the otherwise default behavior of "x inches or y mm", it seems that's not currently possible.
Instead, either both units are spelled, or both units are abbreviated, with the addition of abbr=on
. That behavior seems incredibly inconsistent. Thanks for any clarification!
1980fast (
talk) 04:04, 7 May 2021 (UTC)
disp=or
, the default is abbr=off. However abbr can also be specified as in
or out
.
{{convert|7|in|mm|abbr=out|disp=or}}
→ 7 inches or 180 mm
Sacramento, California#2010 census 4,660.0 people per square mile (1,799.2/km2) How was this calculated? It does not appear to be done by template convert.
{{convert|4,660.0|people/square mile}}
4,660.0 people/square mile
convert: unknown unit {{convert|4,660.0|density/square mile}}
4,660.0 density/square mile
convert: unknown unit
Peter Horn
User talk 23:38, 15 May 2021 (UTC)
Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
acre foot
+ acre feet
+ Nm
+ mN.m
.dtex
.A/m
+ kA/m
+ MA/m
.lb-mol
+ lbmol
+ lb-mol/d
+ lb-mol/h
+ lb-mol/min
+ lb-mol/s
+ lbmol/d
+ lbmol/h
+ lbmol/min
+ lbmol/s
.qtr
+ long qtr
.short qtr
.sqperch
.cuft/min
.cuyd/h
.ksi
+ psf
+ psi
.lbf/in2
.Release notes for earlier versions are listed here. Johnuniq ( talk) 03:27, 3 June 2021 (UTC)
I've come across a little grammar/definition problem while updating streamflow data in a river article.
The way I understand it, the unit acre-foot is spelled with a hyphen because it's defined by the product of an acre and a foot of thickness, just as the kilowatt-hour is the energy produced by one kilowatt of power for one hour.
So shouldn't {{
convert}}
display acre-feet
rather than acre feet
?
Let me add that I found a relevant discussion on this talk page from 2011,
Template_talk:Convert/Archive_September_2011#acre_foot. It appears that either no change was made to {{
convert}}
following that discussion, or that some possible helpful feature was eliminated.
Please forgive me if I am wrong or there already is some feature to display acre-feet
. If so, I would like to know.
--
Jsayre64
(talk) 02:35, 18 May 2021 (UTC)
acre⋅ft
as the symbol and acre foot
as the unit link and singular name. The two "foot" units have acre foot
as the plural name while the other units give acre feet
. What's needed is that the link and names are hyphenated. Thanks for reporting. The change will happen in due course but some thought about any other unit adjustments is needed first.
Johnuniq (
talk) 03:42, 18 May 2021 (UTC)|abbr=on}}
is an okay workaround method in the case of acre-feet, but even so, that dot indicating multiplication looks quite small to me.
Jsayre64
(talk) 20:41, 18 May 2021 (UTC)I have fixed many unit links in the sandbox (and have more to do). The fixed units include these:
{{convert/sandbox|1|acre-foot|lk=in}}
→ 1
acre-foot (1,200 m3){{convert/sandbox|1|acre-ft|lk=in}}
→ 1
acre-foot (1,200 m3){{convert/sandbox|2|acre-foot|lk=in}}
→ 2
acre-foot (2,500 m3){{convert/sandbox|2|acre-ft|lk=in}}
→ 2
acre-feet (2,500 m3)These are aliases for acre-foot
: acre foot
+ acre.foot
These are aliases for acre-ft
: acre feet
+ acre-feet
+ acre ft
+ acre.ft
+ acre·ft
Johnuniq (
talk) 10:19, 19 May 2021 (UTC)
{{convert/sandbox
in an article though?
Jsayre64
(talk) 17:41, 19 May 2021 (UTC)
Convert defines symbol Å and name ångström and link ångström for this unit. However I see the unit is now at Angstrom and energetic discussions at Talk:Angstrom assert that angstrom is the correct name. The article mentions the IUPAC Gold Book which says ångström (and searching for "angstrom" redirects to that page). I assume the official name has the diacrits and there is no need to change convert's name or link? Johnuniq ( talk) 07:48, 19 May 2021 (UTC)
Please add a conversion for Lakh, which is used in many citations from India. - Guy Macon ( talk) 12:18, 24 May 2021 (UTC)
400 [[lakh]] ({{lakh|400}})
= 400
lakh (40,000,000)400 [[crore]] ({{crore|400}})
= 400
crore (4,000,000,000)400 [[lakh crore]] ({{lakh crore|400}})
= 400
lakh crore ({{lakh crore|400}}){{cvt|400|mi|ft}}
= 400 mi (2,100,000 ft){{lakh|400}}
and it would display "40,000,000" which would be appropriate for the English Wikipedia. The fact that the reference said "400 lakh" does not need to be mentioned, per
WP:CALC, I think, although the lakh template would be used to allow easy verification.
Johnuniq (
talk) 05:02, 25 May 2021 (UTC)
In conversions such as {{convert|30|lt|MT}}, which renders as 30 long tons (30 t), I would like to have "tonnes" displayed instead of t: 30 long tons (30 tonnes). Can this be done? Cheers, Simon – SCHolar44 🇦🇺 💬 at 02:04, 9 June 2021 (UTC)
{{convert|30|lt|tonne|abbr=off}}
→ 30 long tons (30 tonnes){{convert|30|lt|tonne|2|abbr=off}}
→ 30 long tons (30.48 tonnes){{convert|30|lt|18|Lcwt|2|qtr|tonne|abbr=off}}
→ 30 long tons 18 hundredweight 2 quarters (31.42 tonnes)A way to convert hoppus to cubic feet and cubic metres. Peter Horn User talk 01:09, 12 May 2021 (UTC)
board feet
and board foot
exist. The difference is that the first give "board feet" as the plural name while the second is always "board foot".
{{convert|12|board feet}}
→ 12 board feet (0.028 m3){{cvt|12|bdft|lk=in}}
12
bd ft (0.028 m3)
Peter Horn
User talk 20:40, 12 May 2021 (UTC)
bdft
also exists and works as shown in your above comment.
Johnuniq (
talk) 02:07, 13 May 2021 (UTC)
Quick question - is there a way to convert from fraction of the speed of light to more conventional speed units? I note that {{
val}} recognizes "0.1
c0", but I haven't figured out a way to feed this into convert. This came up in an edit where a paper specified a speed in terms of fraction of speed of light, and an editor translated 10% of c into 30,000 kps/18,628.2 mps
which was wrong on several levels. After reverting (it turns out they misread the article), I also pointed to the convert template, suggesting that in the future they should use the units specified by their source and {{
convert}} to units they think are necessary. But articles in physics often do specify speeds in terms of "c", and that may be an issue. Is there an obvious way to handle this that I missed?
Tarl N. (
discuss) 05:17, 12 June 2021 (UTC)
I've noticed there is a slight inconsistency in how the template handles composite units featuring US/imperial gallons, which isn't really ideal in terms of disambiguation. I'll give some examples to illustrate the problem. With standalone volume units we observe the expected and desired behaviour:
but with composite units (such as volume per unit time):
You see: the composite units featuring the US gallon omit the disambiguating "US", so if this occurs in isolation, a reader will be unaware which gallon is meant (without relying on contextual information to disambiguate, which is not desirable). Is this a known issue? Archon 2488 ( talk) 20:01, 18 June 2021 (UTC)
{{convert|100|USgal/h}}
→ 100 gallons per hour (0.38 m3/h){{convert|100|U.S.gal/h}}
→ 100 gallons per hour (0.38 m3/h){{convert|100|USgal/h|lk=in}}
→ 100
US
gallons per hour (0.38 m3/h){{convert|100|U.S.gal/h|lk=in}}
→ 100
U.S.
gallons per hour (0.38 m3/h)+
and *
in the definitions). By contrast, the unit usgal/h
is not defined so convert handles it automatically as a "per" unit:
{{convert|100|usgal/h}}
→ 100 US gallons per hour (110 L/ks)USgal/h
was added to the template implementation of convert in
September 2009 and was copied by the module implementation in December 2013. Some significant refactoring could occur now after checking all similar units and having at least a brief look at how they are used in articles.
Johnuniq (
talk) 00:03, 19 June 2021 (UTC)OK, a different question related to the above: {{convert|100|usgal/h}}
→ 100 US gallons per hour (110 L/ks). What kind of unit is l/ks? Are there SI rules about prefixes in the denominator? Maybe ml/s would be better?
Gah4 (
talk) 00:26, 19 June 2021 (UTC)
usgal/h
so convert does an automatic conversion. Since the example did not provide an output unit, convert did all it could, namely it used the default output for usgal
(l impgal) and the default output for h
(ks). The default output unit is then constructed from (l impgal)/ks but since that doesn't make sense, convert uses the first unit (l) to conclude that the default output is l/ks
. The fix is to specify whatever unit is wanted for the output. That is, it is not a good idea to rely on the default output for automatic units.
Johnuniq (
talk) 02:29, 19 June 2021 (UTC)Using the Visual Editor, I was adding a garden-variety conversion from feet to meters using {{convert}}.
Clicking on the conversion after I made it (almost by accident), I happened to notice that the input value doesn't have a non-breaking space between the value and the unit, whereas the output value does. As you might already know, when you use the Visual Editor and click on a conversion, non-breaking spaces are shown by faint gray vertical bars.
I then found another (existing) feet-to-meters conversion on the same page, that happened to use {{cvt}}. I noticed that both the input and output values did have non-breaking spaces between the values and units.
Note that I say this happens "in some situations" because I also happened to notice that there seems to be no difference in behavior between the two templates when the conversion is from Fahrenheit to Celsius, for example. Both show non-breaking spaces between values and units, as they should. I discovered this by clicking around to various conversions just trying to get a sense of what was going on.
Thanks! 1980fast ( talk) 04:50, 20 June 2021 (UTC)
"It sold for 50 cents per one pound (0.45 kg)...." gives an undesirable result. What is needed is "It sold for 50 cents per pound...", but with the conversion to kg still shown. Is there a way of doing that? ThoughtIdRetired ( talk) 13:21, 28 June 2021 (UTC)
50 cents per pound ({{convert|1|lb|disp=out}})
-
DePiep (
talk) 17:00, 28 June 2021 (UTC)({{convert|50|$/lb|$=cent|disp=out}})
→ (110 ¢/kg) -
DePiep (
talk) 17:07, 28 June 2021 (UTC)
{{convert|50|¢/lb}}
could just be used to get "It sold for 50 cents per pound (110 ¢/kg))".There are two options already given with respect to abbr=unit
and abbr=off
when using an e6
prefix.
But what if you want something like:
100 million miles (160 million km)
...in order to mirror the default unit abbreviation behavior seen in other conversions?
Thanks! 1980fast ( talk) 20:05, 10 June 2021 (UTC)
{{convert|100|e6mile|e6km|abbr=unit}}
→ 100 million mi (160 million km)mile
or miles
as the input and currently they are aliases for mi
. I don't think adding yet another option is worthwhile so the alternative would be to either add a new unit or change the existing mile/miles so that the name is never abbreviated. That would need thought...
Johnuniq (
talk) 00:55, 11 June 2021 (UTC)
Mile
as the unit code for a miles unit which never abbreviates. Thoughts?
Johnuniq (
talk) 23:45, 19 June 2021 (UTC)
|abbr=in
to get km (miles). I would welcome a non-abbreviating alternative.
Stepho
talk 01:04, 20 June 2021 (UTC)
I overcame my inertia and added Mile
as a test:
{{convert|1|Mile}}
→ 1 Mile
convert: unknown unit{{convert|15|Mile|abbr=on}}
→ 15 Mile
convert: unknown unit{{convert|100|e6Mile|e6km|abbr=unit}}
→ 100 e6Mile
convert: unknown unit@ 1980fast: You might like to try this. Johnuniq ( talk) 01:30, 20 June 2021 (UTC)
From the 20 April 2021 dump of all articles, there were about 1460 unique {{
convert}} and 210 unique {{
cvt}} which used input unit mile
or miles
yet output mi
. Examples:
{{convert|93|mile|km|abbr=on}}
→ 93 mi (150 km){{convert|1.3|km|miles|adj=on}}
→ 1.3-kilometre (0.81 mi){{cvt|90|miles}}
→ 90 mi (140 km)As discussed above, displaying "mi" is rarely helpful compared with "miles"—the saving of space is inconsequential and it's likely that many readers who would understand miles would be puzzled by mi. Scientific topics (which might want units abbreviated) would rarely use miles. Why would an editor type mile
or miles
in a convert template if they want readers to see mi
? Changing mile/miles so the units never abbreviate would give the very natural result that miles would display miles and mi (if abbreviated) would display mi. In the unique converts, 93,500 use mi and 4,400 use mile or miles. Thoughts?
Johnuniq (
talk) 07:50, 29 June 2021 (UTC)
At
List of longest buildings#World there is a need to add the conversion for "3000+ m". The best I've found is {{convert|3000|m|ft|disp=table|sortable=on|adj=pre|+}}
but that shows only the + only in the first column:
m | ft |
---|---|
3,000+ | 9,800 |
Is there a way to get the + into both columns? Thryduulf ( talk) 20:07, 18 July 2021 (UTC)
>{{convert|3000|m|ft|disp=table|sortable=on}}
does not show the prefixed gt symbol at all?!m | ft |
---|---|
3,000 | 9,800 |
m | ft |
---|---|
3,000+ | 9,800+ |
Infoboxes are narrow and reading lists of items should be able to display as verticle lists or as a • bullet list.
Only the first conversion has a line break there should be a way to output as a list in a infobox.
disp=bl disp=li
? @ Mkouklis(2): This relates to Dixie Fire. You could use the following.
{{#invoke:string|replace|{{convert|192,849|acre|sqmi ha e6sqft|0|abbr=off|disp=br}}|; |<br>}}
→or
{{#invoke:string|replace|{{convert|192,849|acre|sqmi ha e6sqft|-1|abbr=on|disp=br}}|; |<br>}}
→Johnuniq ( talk) 07:22, 27 July 2021 (UTC)
I have 2 references that put a car's weight at 3559 lb (US) and 1580 kg (Australia). Is there a simple way to put this as a range so that it looks something like "1580-1614 kg (3,483-3,559 lb)" ? Stepho talk 10:28, 10 August 2021 (UTC)
Example: 100 t (98 long tons; 110 short tons) Could we have the output abbreviated as ltons and stons or even Ltons and Stons instead? Peter Horn User talk 00:33, 7 September 2021 (UTC)
lt
gives LT as a symbol but for some reason lost in history, there is no way to abbreviate ST. If there is not enough room for "long tons" and "short tons", consider omitting the convert altogether—does it really matter what the exact number of tons is? At any rate, it would not be desirable for us to invent abbreviations that are not widely recognized.
Johnuniq (
talk) 00:54, 7 September 2021 (UTC)For Dedicated Freight Corridor Corporation of India#Need for DFC 110 crore tonnes → {{cvt|110|crt|LT ST|lk=on}} 110 crt convert: unknown unit instead of (110,000,000 t [108,300,000 long tons; 121,300,000 short tons]) Peter Horn User talk 19:09, 6 September 2021 (UTC) Peter Horn User talk 19:12, 6 September 2021 (UTC) Peter Horn User talk 19:16, 6 September 2021 (UTC) Peter Horn User talk 19:29, 6 September 2021 (UTC)
{{convert|1.1|e9tonne|e9LT e9ST|sigfig=3|abbr=off}}
→ 1.1 billion tonnes (1.08 billion long tons; 1.21 billion short tons)Not sure where it would be best to mention this. Have noticed increasing use of the term "ton" to mean a metric ton (1000 kg), whereas the convert template spells it "tonne" for the metric ton, rather than the old US meaning of "ton" 1 ton = 1 short ton = 2000 lbs, or the former UK meaning 1 ton = 1 long ton.
SpaceX has been doing this for some time, and recently have seen Tesla doing this as well. Example, Tesla in their 2020 Tesla Impact Report says: "In the E.U., electric semi trucks are allowed to be 2 tons (~4,400 pounds) heavier than diesel equivalents, and in the U.S. the allowance is 0.9 tons (2,000 pounds)." (page 24)
The {convert} template seems to only use the full spelling of "tonne" for the spelled out units of the metric ton. I'm curious to know if there is a way to make the metric ton be spelled "ton" using the convert template, rather then "tonne"? Or how we might go about considering making changes in {convert} for spelling conventions that change over many years. Cheers. N2e ( talk) 11:06, 21 August 2021 (UTC)
|sp=us
.unitcode scale link default symbol name1 name1_us 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 ST 907.18474 Short ton t ~short ton short ton shtn 907.18474 Short ton t sh tn short ton shton 907.18474 Ton t ~ton ton LT 1016.0469088 Long ton t ~long ton long ton lt 1016.0469088 Long ton t LT long ton
ton
as an input ({{convert|1|ton}}
gives an error). As an output, "ton" can only occur with the unit shton. There are about 14 converts using shton in articles, examples:
{{convert|493|shton}}
→ 493 tons (447 t){{Convert|1|shton|kg}}
→ 1 ton (910 kg)ton
as an input. When I listen to US news media, I often hear "metric ton", so I infer that ton still means 2000 pounds in general US usage.ton
may not give a clue which is intended: I agree. Have seen that too. But that is a problem with a source to be resolved at the article level (or possibly with some input from a WikiProject on how the term is used in a particular industry.)ton
is used in a source, then what the source must mean is 'shton'. If the editor uses ton
= 'shton' via our template when the source is unclear, as many are in the 2020s, then we are furthering the misunderstanding, when the source was unclear in the first place.
N2e (
talk) 11:54, 24 August 2021 (UTC)
I was editing an article and realised Mach speed conversion is not supported. It is very common in aviation & aeronautics. Example: 15,345 miles per hour (24,695 km/h; Mach 20) would yield 15,345 mph (24,695 km/h; Mach 20) Crnorizec ( talk) 19:46, 7 September 2021 (UTC)
Just wondering, since the speed of sound varies with temperature, and fast jets normally fly at higher (cooler) altitude, which speed does it use? Gah4 ( talk) 22:11, 7 September 2021 (UTC)
{{convert|20|Mach}}
→ Mach 20 (24,500 km/h; 15,200 mph){{convert|20|Mach|mph km/h}}
→ Mach 20 (15,200 mph; 24,500 km/h){{convert|20|Mach|0|mph km/h}}
→ Mach 20 (15,200 mph; 24,500 km/h){{convert|20|Mach|50,000|mph km/h}}
→ Mach 20 (13,200 mph; 21,200 km/h)In April 2021, the Mach unit appeared in 101 {{ cvt}} and 245 {{ convert}} = 346 total. That is a reasonably small number so it would be possible to change convert by:
|altitude=
so the altitude could be specified for input and output.I'll slowly see what would be involved in the module. Johnuniq ( talk) 01:33, 12 October 2021 (UTC)
@ Gciriani: The problem you are reporting is that at Blue Origin a source ( example) might say "top speed of Mach 3" and an editor then puts {{cvt|3|Mach}} in the article without knowing that an altitude is required for the conversion to make sense. The source does not specify the altitude so a conversion is not possible without a bunch of original research, or a better source which does the conversion. They use "Mach 3" to mean "very fast" and the exact speed in km/h is not really the point. However, it will be an ongoing problem because wikignomes will return to that article every year and insert conversions.
Re convert, it uses the table from aerospaceweb.org although the website's table goes to 400,000 feet while convert's table stops at 300,000 feet (anything over that altitude is truncated to 300,000). I could extend the table and fix some other issues. Are you saying that using aerospaceweb's table with a mandatory altitude would be sufficient (although it wouldn't help at Blue Origin where the altitude is unknown)? Johnuniq ( talk) 01:07, 15 October 2021 (UTC)
I agree with John that temperatures are rarely given in sources - therefore any arguments requiring temperatures are a moot point in spite of being technically correct.
It would be very unusual for an aircraft going fast enough to be measured in Mach numbers to be at sea level. From the graph above, 10-20 km altitude seems to have a reasonably constant speed of sound, with only small deviations up to 30 km. 10-30 km is also where the majority of fast airplanes will be operating. I suggest we change the formula to use a default of 20 km altitude. In that way, conversions where no altitude is given are likely to be more accurate - at least to the level of precision suitable for a general audience. Worse case is for an altitude of 50 km giving an error of 10% (330 m/s vs 295 m/s). Since the conversion to km/h or mph is more of a general indication of a jet fighter doing 3000 km/h vs an airliner doing 1000 km/h, then this should be suitable. Luckily for us, the extreme cases (eg, jet fighters, record breakers) also tend to give altitude in the references, so we can be a bit more accurate anyway in those cases. Stepho talk 00:35, 16 October 2021 (UTC)
I put a list of all 153 unique converts in articles from April 2021 where Mach is used with an altitude in my sandbox ( permalink). I'm interested in far too many things and don't have time to examine the details of how Mach works. The issue for this page concerns what should happen with the Mach unit as far as convert is concerned. I'm inclined to think there should be no default altitude—omitting the altitude should result in an error—because it appears the value is meaningless without an altitude (or preferably, according to above, a temperature which is never going to happen). Are any of the values shown in the sandbox significantly wrong? What should convert do? Johnuniq ( talk) 06:53, 16 October 2021 (UTC)
I had a look at this page and had the typical frustration of the SI influenced engineer: tonnes are non-SI. But for some reason Wikipedia's convert function assumes that SI only goes up to kg, which is clearly incorrect. SI also has an equivalent for the tonne, the megagram (Mg). There also is the Gg for ships for instance. How can I lobby for the convert{} function to be adapted accordingly? — Preceding unsigned comment added by Lordarpad ( talk • contribs) 23:19, 16 October 2021 (UTC)
Mg
(and all other SI variations) works, but as Stepho-wrs says, using Mg would rarely be helpful because Wikipedia is supposed to be for general readers, not just engineering types who would recognize that unit.
Johnuniq (
talk) 02:36, 17 October 2021 (UTC)Infoboxes that automatically convert data retrieved with {{
PH wikidata|elevation_m}}
can't handle cases when WD has multiple values for this field. I really don't see how this has anything to do with {{
convert}}
. Since it would be wrong to do anything like arbitrarily uses the first value, or use an average, I think this problem lies at the source in WD. See
User talk:Mike Peel#Wikidata question for the background.
MB 20:37, 25 October 2021 (UTC)
{{convert|input=P2044|3=m|disp=number}}
, a preview will show that it retrieves the value you fixed at Wikidata. I forget what happens if there is more than one value, but it's probably not helpful. A difficulty is that I despise the model used for Wikidata—in brief, it's write-only data with no thought given for how a program could extract useful information and no promises about the future except that things will break.
Johnuniq (
talk) 02:58, 26 October 2021 (UTC)
I've finished investigating and the problems can be fixed now if you like (the fix would be to remove one of the duplicate elevation values in Wikidata). At Santo Tomas, Isabela, the infobox has
| elevation_m = {{PH wikidata|elevation_m}}
The result from {{PH wikidata|elevation_m}}
is the output from the following (this uses fixed wikitext to show what happens now):
{{convert|input=P2044|3=m|disp=number}}
→ 30, 33
{{
Infobox settlement}} then does its own calculation and tries to use 30, 33
as a single value. I haven't examined that code but it understandably fails. From my point of view, convert is working as advertised, and no doubt the Wikidata people would say the same, as would the infobox people. Not our problem. In principle there could be a new parameter to tell convert to return only the first value but I would be reluctant to bolt on another Wikidata band-aid. The reason convert is being used is that the Wikidata entry could specify the elevation in another unit, say feet. Convert would return that converted to metres.
Johnuniq (
talk) 09:30, 26 October 2021 (UTC)
|rank=
: the
WD-rank of a single property value can be "preferred", and selection by this would reduce the number of returned values (though WD does not limit Preferred to a single value).{{
infobox settlement}}
detect multiple values in the field, not display anything, and put the article in
Category:Articles using infobox settlement with invalid elevation data.
MB 01:20, 28 October 2021 (UTC)
Does convert handle rack units? It's a unit of length equal to 1.75 inches, commonly used in the electronics and computer industries. See Special:Diff/1052328533 for an example. -- RoySmith (talk) 15:42, 28 October 2021 (UTC)
I just noticed the template supports and(-) and to(-) as options (to display a range of / multiple values differently in the primary vs secondary) but not or(-). Is there a reason for this? Would it be straightforward to add it? Archon 2488 ( talk) 20:21, 6 November 2021 (UTC)
or(-)
mean to say, in {{Convert}} context? Did you meet it in an article or in a source? -
DePiep (
talk) 20:32, 6 November 2021 (UTC)It could be added but I'm not sure it would be useful. Per DePiep, is there somewhere this would help? For reference, the following shows examples. The last one (or(-)
) is not implemented and the output is simulated wikitext.
{{convert|12|to|18|kg}}
→ 12 to 18 kilograms (26 to 40 lb){{convert|12|and|18|kg}}
→ 12 and 18 kilograms (26 and 40 lb){{convert|12|or|18|kg}}
→ 12 or 18 kilograms (26 or 40 lb){{convert|12|to(-)|18|kg}}
→ 12 to 18 kilograms (26–40 lb){{convert|12|and(-)|18|kg}}
→ 12 and 18 kilograms (26–40 lb){{convert|12|or(-)|18|kg}}
→ 12 or 18 kilograms (26–40 lb)Johnuniq ( talk) 00:22, 7 November 2021 (UTC)
We need a Helper function that can read & feed regular source-&-keyboard value inputs for {{Convert}}.
IMO it is useful in an Infobox template (backoffice) that has like |height=
. So: the template editor uses it, and the article editor can enter simple and natural entries. For example, {{
Infobox person}} has |height=
, but with many prescriptions. Why not expect & parse simple |height=1.74m
and |height=5ft6 in
?
Many & most input for {{Convert}} is basic the quantity value: number × unit. (Allow me: ranges, sigfig input : sure, later more).
There is a discussion at Wikipedia talk:Manual of Style/Dates and numbers#Evidence? which includes the suggestion that {{ Convert}} support US liq pt and US liq qt (for US liquid pint and US liquid quart) rather than US pt and US qt. NebY ( talk) 18:25, 11 November 2021 (UTC)
Should this work?:
I was thinking it should give something like:
I figure the conversion should be valid if the dimensional units are exactly the same, but inverted (e.g. "area/power" to "power/area"), and then the value should units converted, but then inverted as well. It's a generalization of the mpg conversion.
I was thinking it could also work like:
These kinds of things are pretty common in the real world. I was thinking specifically about u-value/r-value and mpg, but I think it's much more common than that. GliderMaven ( talk) 05:23, 7 November 2021 (UTC)
Cannot convert "area/power" to "power/area". I think it would require the creation of four new units (m2/W, W/m2, ft2/W, W/ft2) and creative use of the "invert" option although I haven't looked at that for a long time (not since one of your last visits here!) and don't know if it would work. I take your word for it being used somewhere, but I find it hard to imagine that text like that appears in articles here? Johnuniq ( talk) 05:51, 7 November 2021 (UTC)
Like to conversions for these in various countries! Lfstevens ( talk) 20:13, 24 November 2021 (UTC)
Consider {{convert|0.1|km2|1|abbr=on}} (0.1 km2 (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on}} (0.1 km2 (0.039 sq mi)). I don't know why the first one works at all, but if there's a reason for it to produce square miles at all, I'd expect precision to be the same.
Consider also {{convert|0.1|km2|1|abbr=on|sigfig=20}} (0.1 km2 (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on|sigfig=20}} (0.1 km2 (0.038610215854245 sq mi)). This makes the weird behaviour even more apparent -- it seems that using 1 as units sets precision to a fixed, low, level and prevents it from being changed.
81.6.39.198 ( talk) 20:22, 26 November 2021 (UTC)
Hi, the link for deadweight ton (DWton) currently links to tonnage and not Deadweight tonnage; could this be fixed? Thanks. Iazyges Consermonor Opus meum 18:58, 29 November 2021 (UTC)
You can see the error just glancing at it. A kilometer is much less than a mile, and a square kilometer is even less when compared with a sq. mi. If you subtract a sq. mi. you have to subtract at least one sq km:
According to the U.S. Census Bureau, the county has a total area of 944 sq mi (2,440 km2), of which 943 sq mi (2,440 km2) are land and 0.3 sq mi (0.78 km2) (0.03%) is covered by water. [1]
My calculator says 942 sq mi is 2439.7 sq km, rounding up is OK, but 943 square miles are 2442.3 sq km. If you're interested, it's from Brooks County, Texas. deisenbe ( talk) 04:20, 8 December 2021 (UTC)
This makes the sqmi numbers add up as expected. Adding precision eliminates rounding in the sqkm:According to the U.S. Census Bureau, the county has a total area of 943.3 sq mi (2,443 km2), of which 943 sq mi (2,440 km2) are land and 0.3 sq mi (0.78 km2) (0.03%) is covered by water.
According to the U.S. Census Bureau, the county has a total area of 943.3 sq mi (2,443.136 km2), of which 943 sq mi (2,442.359 km2) are land and 0.3 sq mi (0.777 km2) (0.03%) is covered by water.
|0
like so:{{convert|944|sqmi|abbr=on|0}}, of which {{convert|943|sqmi|abbr=on|0}}
---> 944 sq mi (2,445 km2), of which 943 sq mi (2,442 km2)The county has a total area of 943.3 sq mi (2,443 km2), of which 0.3 sq mi (0.8 km2) (0.03%) is water. Then the issue wouldn't have come up in the first place.BTW, the article's discussion of immigrant deaths and so on is a complete mess.
Between 2009 and 2018, over 600 bodies were recovered, and according to sheriff's deputy Benny Martinez, the corpses never found are 5 to 10 times more numerous than those found– how stupid can you get? If they're not found, how do you know how many there are? E Eng 14:01, 8 December 2021 (UTC)
References
Can anyone advise please, how best to use the convert template to round one of the outputs but not the other. I've got this: {{convert|246|bhp|kW PS|order=flip|disp=x|; |abbr=on}}
, which produces this: "183 kW; 249 PS; 246 bhp", but I want the middle value to be rounded to the nearest 10, to look like this: "183 kW; 250 PS; 246 bhp". --
DeFacto (
talk). 06:57, 29 October 2021 (UTC)
{{convert|250|PS|kW PS bhp|order=out|abbr=on}}
→ 180 kW (250 PS; 250 bhp){{convert|250.|PS|kW PS bhp|order=out|abbr=on}}
→ 184 kW (250 PS; 247 bhp)250.
(with a dot) tells convert that the zero is a significant digit. The same effect could be achieved with |sigfig=3
.
Johnuniq (
talk) 08:38, 29 October 2021 (UTC)
{{convert|250.|PS|kW PS bhp|order=out|abbr=on}}
-> 184 kW (250 PS; 247 bhp) to give "183 kW (250 PS; 246 bhp)"? The values by hand are 183.8747 and 246.58002. --
DeFacto (
talk). 09:34, 29 October 2021 (UTC)
{{convert|249.5|PS|kW PS bhp|0|order=out|abbr=on|adj=ri0}}
→ 184 kW (250 PS; 246 bhp)Beware that the 250 PS may be only nominal - ie a marketing value that was rounded off to look better in advertising. We could use something like {{convert|246|hp|kW hp PS|order=out|round=5|abbr=on}}
→ 185 kW (246 hp; 250 PS). But sometimes it is better to use the actual PS value instead of the rounded marketing value: {{convert|246|hp|kW hp PS|order=out|0|abbr=on}}
→ 183 kW (246 hp; 249 PS). A similar thing happens with the Ford 302 cubic inch engine: we list it as 4.9 litres even though it was advertised as a 5.0 engine.
Stepho
talk 10:30, 29 October 2021 (UTC)
In an article I saw the template used like this:
276 bhp (206 kW; 280 PS)
I know what a kilowatt is, but I hadn't heard of
PS before. I want to add a link to PS for people like me who haven't heard of it, but I don't want to link kW and it seems like this template has no way to do that. I would like a way specify that I want a link for a unit individually, something like \{\{convert|276|bhp|kW \[\[PS]]|0|abbr=on}}
.
Akeosnhaoe (
talk) 23:59, 13 December 2021 (UTC)
Just a comment (not a complaint) on some unexpected functionality I've observed: setting the flag disp=or also seems to change the abbr flag to off, implicity:
but
I'm curious, is this behaviour intentional? Archon 2488 ( talk) 09:59, 23 December 2021 (UTC)
|abbr=on
:I just tried to convert 0.368° to arcminutes, but found {{ convert}} is lacking in that department. It's unfortunate that the template does not support angular units, such as degrees, radians, turns, arcminutes, and arcseconds. That could be useful, for example, on astronomy articles. Praemonitus ( talk) 16:54, 29 December 2021 (UTC)
Hi there, I can see why you decided to no write aj or julian years, despite thats what it converts into. So I am suggesting to at least link the "a" not " annum" but rather to "julian year" or what ever year calculation is used for the converting? (And then maybe use aj too?) Nsae Comp ( talk) 22:39, 7 January 2022 (UTC)
feet/year
and "annum" is used in that context.
Annum is a redirect to
year. The following links to annum where it might just be year:
The infobox at Earth uses the following:
{{convert|365.256363004|d|yr|comma=gaps|abbr=on|lk=out|disp=x|<ref name="IERS" /><br /><small>(|)</small>}}
Convert does the calculation using the definitions 1 day = 86,400 seconds and 1 year = 31,557,600 seconds = 365.25 days exactly. However, what should happen is way over my paygrade given 13 significant digits for the number of days. A discussion at Talk:Earth or WT:WikiProject Astronomy regarding what should happen would be best. Johnuniq ( talk) 23:00, 8 January 2022 (UTC)
A long ton (imperial ton) is defined as 2240 lb and a "long hundredweight" (imperial hundredweight, lcwt) is 112 lb or 8 stone. One stone is 14 lb.
But as of today, {{ convert}} appears to have an alternative definition. All these are wrong:
But these are correct
Aye, there's trouble at t'mill, lad! -- John Maynard Friedman ( talk) 17:14, 17 January 2022 (UTC)
|4}}
i.e., sigfig=4.Could someone please add a conversion for in. WC similar to inHg? Apparently HVAC compressors in the US are labeled with this unit of pressure. Thanks in advance! Facts707 ( talk) 15:52, 15 January 2022 (UTC)
From NIST:
They also have inches and centimeters Hg at 32°F, 60°F, and "conventional". Facts707 ( talk) 04:14, 19 January 2022 (UTC)
Consider this conversion, from Sisal:
{{convert|1.5|-|2|m|ftin|abbr=on}}
→ 1.5–2 m (4 ft 11 in – 6 ft 7 in)Per MOS:UNITNAMES I think this should generate a spaced en dash, but what we get is an unspaced en dash. GA-RT-22 ( talk) 03:14, 16 January 2022 (UTC)
{{convert|1.5|to|2|m|ftin|abbr=on}}
→ 1.5 to 2 m (4 ft 11 in to 6 ft 7 in)Consider using inches (but not in.) in place of in where the latter might be misread as a prepositionand I'm almost ready to suggest to Johnuniq that a special case be made of in to, changing it to inches to (on both sides of range). Now there would be some kludgy code for you, I'm guessing. E Eng 07:47, 17 January 2022 (UTC)
4 ft 11 in – 6 ft 7 indefinitely takes a spaced endash. That MOS gives no example using ft in isn't a problem -- the important point is that ft in has a space, so the endash has a space before it and a space after it. E Eng 05:09, 16 January 2022 (UTC)
Hmm, I wonder what "Rackets with smaller and larger head sizes, 85 and 120–137 square inches (550 and 770–880 cm2), are still produced" at Racket (sports equipment)#Tennis means. Should it have a spaced en dash? Johnuniq ( talk) 08:51, 16 January 2022 (UTC)
I'm looking at some changes so units like ftin use a spaced en dash in ranges. With a combination unit like ftin (feet and inches) or stlb (stones and pounds), convert shows the unit on each side of the dash. However, sometimes the major unit (feet or stones) is not needed as in these examples:
{{cvt|0.1|-|0.2|m|ftin}}
→ 0.1–0.2 m (3.9 in – 7.9 in){{cvt|3|-|5|kg|stlb}}
→ 3–5 kg (6.6 lb – 11.0 lb)I'm not going to try to make convert handle that special case. It occurs in perhaps half a dozen articles. The fix is to use the more appropriate output unit:
{{cvt|0.1|-|0.2|m|in}}
→ 0.1–0.2 m (3.9–7.9 in){{cvt|3|-|5|kg|lb}}
→ 3–5 kg (6.6–11.0 lb)Johnuniq ( talk) 06:40, 17 January 2022 (UTC)
I updated the sandbox to give a spaced en dash.
Current template (not spaced):
{{convert|2|-|3|Mach|20000}}
→ Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph){{convert|1.5|-|2|m|abbr=on}}
→ 1.5–2 m (4 ft 11 in – 6 ft 7 in){{convert|1346|-|1676|mm|ydftin|0}}
→ 1,346–1,676 millimetres (1 yd 1 ft 5 in – 1 yd 2 ft 6 in){{convert|81|-|89|kg|stlb}}
→ 81–89 kilograms (12 st 11 lb – 14 st 0 lb)Sandbox (spaced):
{{convert/sandbox|2|-|3|Mach|20000}}
→ Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph){{convert/sandbox|1.5|-|2|m|abbr=on}}
→ 1.5–2 m (4 ft 11 in – 6 ft 7 in){{convert/sandbox|1346|-|1676|mm|ydftin|0}}
→ 1,346–1,676 millimetres (1 yd 1 ft 5 in – 1 yd 2 ft 6 in){{convert/sandbox|81|-|89|kg|stlb}}
→ 81–89 kilograms (12 st 11 lb – 14 st 0 lb)Johnuniq ( talk) 01:32, 18 January 2022 (UTC)
"Default spelling of units is in the en (generic) locale. To show en-US spelling, use |sp=us"... true, except when the conversion is to a US-specific measure. On 2022 Hunga Tonga eruption and tsunami I'm trying to get the template to convert litres to US gallons, and there doesn't seem to be a way of stopping it from spelling the former as "liters". Is there any way to add a sp=uk or similar please, because at the moment that just generates an error. Grutness... wha? 22:35, 20 January 2022 (UTC)
{{convert|250000|L|U.S.gal|abbr=off}}
→ 250,000 liters (66,000 U.S. gallons)USgal
. Using U.S.gal
implies US spelling and sets sp=us
. Try this:
{{convert|250000|L|USgal|abbr=off}}
→ 250,000 litres (66,000 US gallons)Apollo Lunar Module uses {{cvt|290|isp}}, which displays as "290 s (2.8 km/s)". I couldn't find anything on "isp", but the value is for the LEM's Specific impulse, so I guess that stands for "impulse, specific". It should be measured in m/s, so why is Cvt using a time here? -- 84.189.84.17 ( talk) 00:58, 21 January 2022 (UTC)
I have updated the sandbox with some improvements regarding handling of the Mach unit. Using the old system, an altitude could be entered as a number (in feet) after the Mach unit, but that only worked for Mach as an input. It was not possible to specify an altitude for Mach as an ouput.
In the new system:
altitude_ft
and altitude_m
have been added.The following table compares the old and new systems using fixed wikitext so the results will not change.
Convert | Old output | New output |
---|---|---|
{{cvt|0.9|Mach}} | Mach 0.9 (1,102.5 km/h; 685.1 mph) | Mach 0.9 (1,100 km/h; 690 mph) |
{{cvt|1.6|Mach|20000}} | Mach 1.6 (1,820.5 km/h; 1,131.2 mph) | Mach 1.6 (1,820 km/h; 1,130 mph) |
{{cvt|1.6|Mach|altitude_ft=20,000|mph}} | (not supported) | Mach 1.6 (1,130 mph) |
{{cvt|1.6|Mach|altitude_m=6,096|mph}} | (not supported) | Mach 1.6 (1,130 mph) |
{{cvt|3|Mach}} | Mach 3 (3,675 km/h; 2,284 mph) | Mach 3 (3,700 km/h; 2,300 mph) |
{{cvt|5|-|7|Mach}} | Mach 5–Mach 7 (6,125–8,575 km/h; 3,806–5,328 mph) | Mach 5 – Mach 7 (6,100–8,600 km/h; 3,800–5,300 mph) |
{{cvt|9.8|Mach|98000}} | Mach 9.8 (10,655.3 km/h; 6,620.9 mph) | Mach 9.8 (10,700 km/h; 6,620 mph) |
Johnuniq ( talk) 08:43, 24 January 2022 (UTC)
Added:
|Mach|km/h mph|
(multiple value output).|20000
altitude input must be changed into |altitude_ft=20000
, in-article.row | Convert | Old output | New output | Inverse{{convert/sbox|123 |Mach |km/h |altitude_ft=..}}
|
---|---|---|---|---|
A | {{cvt|0.9|Mach}} | Mach 0.9 (1,102.5 km/h; 685.1 mph) | Mach 0.9 (1,100 km/h; 690 mph) | 1,100 kilometres per hour (Mach 0.90) 690 miles per hour (Mach 0.91) |
B | {{cvt|1.6|Mach|20000}} | Mach 1.6 (1,820.5 km/h; 1,131.2 mph) | Mach 1.6 (1,820 km/h; 1,130 mph) |
convert: precision too large |20000}} 1,820 kilometres per hour (Mach 1.6) → • |altitude_ft=20000}}
|
C | {{cvt|1.6|Mach|altitude_ft=20,000|mph}} | (not supported) | Mach 1.6 (1,130 mph) | 1,100 kilometres per hour (Mach 0.97) 1,130 miles per hour (Mach 1.6) |
D | {{cvt|1.6|Mach|altitude_m=6,096|mph}} | (not supported) | Mach 1.6 (1,130 mph) | 1,820 kilometres per hour (Mach 1.6) 1,130 miles per hour (Mach 1.6) |
E | {{cvt|3|Mach}} | Mach 3 (3,675 km/h; 2,284 mph) | Mach 3 (3,700 km/h; 2,300 mph) | 3,700 kilometres per hour (Mach 3.0) 2,300 miles per hour (Mach 3.0) |
F | {{cvt|5|-|7|Mach}} | Mach 5–Mach 7 (6,125–8,575 km/h; 3,806–5,328 mph) | Mach 5 – Mach 7 (6,100–8,600 km/h; 3,800–5,300 mph) | 6,100–8,600 kilometres per hour (Mach 5.0 – Mach 7.0) 3,800–5,300 miles per hour (Mach 5.0 – Mach 7.0) |
G | {{cvt|9.8|Mach|98000}} | Mach 9.8 (10,655.3 km/h; 6,620.9 mph) | Mach 9.8 (10,700 km/h; 6,620 mph) | • |altitude_ft=20000}} 10,700 kilometres per hour (Mach 9.8) 6,620 miles per hour (Mach 9.8) • |altitude_ft=20000}} 10,700 kilometres per hour (Mach 8.7) 6,620 miles per hour (Mach 8.7) |
H | {{cvt|9.8|Mach|km/h mph|altitude_ft=20000}} | {{cvt|9.8|Mach|<!--no units=defaults to |km/h mph|-->20000}} Mach 9.8 (11,200 km/h; 6,930 mph) |
.. | • |altitude_ft=20000}} Mach 9.8 (10,700 km/h; 6,620 mph) • |altitude_m=667}} Mach 9.8 (12,000 km/h; 7,460 mph) |
The nomenclature in "producing... 260 pound force-feet (350 N⋅m) of torque" is non-standard, and apparently is produced by a conversion template as invoked by: 260 pound force-feet (350 N⋅m)
Ref: /info/en/?search=Dodge_Charger
Standard usage would simply read "260 lb•ft (350 N•m)". There is no common specification for torque stated as "pound force-feet."
I contend the template should be modified to render the standard verbiage. 107.2.38.145 ( talk) 15:52, 30 January 2022 (UTC)
lb.ft
and lbft
:
{{convert|260|lb.ft}}
→ 260 pound force-feet (350 N⋅m){{convert|260|lbft}}
→ 260 pound-feet (350 N⋅m){{convert|260|lb.ft|abbr=on}}
→ 260 lb⋅ft (350 N⋅m){{convert|260|lbft|abbr=on}}
→ 260 lb⋅ft (350 N⋅m)abbr=on
gives the correct symbol. There was a previous and inconclusive discussion regarding the "force" terminology in
December 2011.
Johnuniq (
talk) 02:07, 31 January 2022 (UTC)This code ( found here):
{{convert|2|-|3|cm|0|abbr=on}}
results in this output:
Maybe the repetition is intentional but it looks a bit clumsy. Could we produce a neater output like this:
or would this be confusing? -- Heron ( talk) 14:42, 2 February 2022 (UTC)
Some changes to the convert modules are in the sandbox and I intend switching the main modules to use the sandbox soon.
–
) now use a spaced en dash ( –
) with unit Mach and with composite units such as ftin (feet and inches) or stlb (stones and pounds).{{convert|2|-|3|Mach|altitude_ft=20000}}
→ Mach 2 – Mach 3 (2,300–3,400 km/h; 1,400–2,100 mph){{convert|0.1|-|0.2|m}}
→ 0.1–0.2 metres (3.9 in – 7.9 in){{convert|81|-|89|kg|stlb}}
→ 81–89 kilograms (12 st 11 lb – 14 st 0 lb)altitude_ft
and altitude_m
can be used to specify the altitude in feet or meters.DWton
and DWtonne
have been corrected to
Deadweight tonnage.Release notes for earlier versions are listed here. Johnuniq ( talk) 22:52, 4 February 2022 (UTC)
|3=
) to be used as alternative (synonym) next to |altitude_ft, _m=
then? Wouldn't it be preferable to not introduce non-semantic parameter usage, i.e., requiring dedicated parameters |altitude_ft, _m=
? I don't think ease of editing is helped. -
DePiep (
talk) 09:01, 11 February 2022 (UTC)
|altitude_ft=10,000
) or in metres (for example, |altitude_m=3,749
). The altitude cannot be determined accurately and only a whole number is accepted.Along with what I wrote above, I don't think any more is needed, although any documentation should not mention details such as aerospaceweb.org.
Johnuniq (
talk) 08:38, 12 February 2022 (UTC)Would someone who understands procedures regarding redirects please have a look at diff which added {{ WikiProject Measurement}} at Module talk:Convert/documentation/conversion data, which is a redirect to this page. Ping Awkwafaba. Johnuniq ( talk) 23:53, 14 February 2022 (UTC)
I've noticed that (for example) {{convert|2|to(-)|3|m|ft|0}} works as expected: 2 to 3 metres (7–10 ft). However, the near-identical {{convert|2|to(–)|3|m|ft|0}} does not: 2 to(–) convert: unknown unit (point being that in the latter case, we have an en dash rather than a hyphen). Archon 2488 ( talk) 10:13, 17 February 2022 (UTC)
-
(hyphen) and –
(en dash) for a simple range. However, no one should think that the hyphen in to(-)
should be changed to an en dash. Two others examples where only a hyphen is accepted are and(-)
and +/-
.
Johnuniq (
talk) 06:03, 18 February 2022 (UTC)I corrected a population density figure in the text of
Prince of Wales–Hyder Census Area, Alaska#Demographics, and 1.57 per square mile (0.61/km<sup>2</sup>)
should become 1.57 per square mile (0.61/km2) but instead is treated as 1 per square mile (0/km2). –
LaundryPizza03 (
d
c̄) 19:49, 19 February 2022 (UTC)
E.g.:
Thanks for considering, Facts707 ( talk) 00:19, 13 February 2022 (UTC)
It seems like when I try to use a different currency when using the "currency per unit" feature, it throws an error saying it doesn't recognize it. I figured using the "currency change" feature just uses a simple text replacement rather than an actual recognition of the various currency symbols. For example:
{{convert|1|$/acre|abbr=off}}
→ $1 per acre ($2.5 per hectare)
{{convert|1|$/acre|$=₹|abbr=off}}
→ ₹1 per acre (
convert: unknown unit)
It would be great if all the currency symbols could be supported. Getsnoopy ( talk) 18:29, 20 February 2022 (UTC)
{{convert|1|$/acre|$/ha|$=₹|abbr=off}}
→ ₹1 per acre (₹2.5 per hectare)Hey, J u: In a discussion over at Talk:MOS, the question has arisen: Which chain ? English, Scottish or US ? I'm not sure which one convert uses. Possibly convert might have to accept multiple chains.
E
Eng 13:48, 1 February 2022 (UTC)
{{convert|1|chain|feet|abbr=off|9}}
→ 1 chain (66.000000000 feet){{convert|1|foot|m|abbr=off|9}}
→ 1 foot (0.304800000 metres)I'm editing on Royce Clayton and wrote about how he trained by running 200-metre (660 ft) sprints. He's American though, so it should read "200-meter". I put {{ Use American English}} on the article, but it still shows up as "metre". Can we account for differences in English dialects? – Muboshgu ( talk) 04:32, 21 February 2022 (UTC)
Does this template always show X unit1 (Y unit2)? Or can it show Y unit2? I am using the Convert template to import Wikidata numbers into existing tables. For example, in tables we typically show one unit in each column, or only one unit. Tomastvivlaren ( talk) 14:20, 28 February 2022 (UTC)
Can you guys explain why {{ Convert}} shows different units for the area (P2046) of the cities of São Paulo (Q174) and Sundsvall (Q26476)? The São Paulo area is stored in km2 at wikidata and Sundsvall in hectares, but shouldn't Convert fix that? I always want km2 - is that possible?
@ MB and Johnuniq: Tomastvivlaren ( talk) 22:29, 28 February 2022 (UTC)
This is a weirdness in how convert works internally when dealing with Wikidata values/units. A workaround is to insert 3=
in {{
Area WD}} so its unit reads |3=km2
. I'd have to spend an hour studying it to remind myself of exactly what is happening but I believe that convert's code expects that it is being used to do a conversion, so there should be an input unit and an output unit. The input value and unit are read from Wikidata. They are inserted as parameters 1 and 2 to convert. The output unit is specified as a parameter to convert. The problem is that no one can predict what the input unit is and the input=
feature was initially used to do conversions which looked silly if the input unit and output unit were the same. Therefore convert removes the output unit if it duplicates the input, so it ends up using the default. Try the 3=
workaround.
Johnuniq (
talk) 23:54, 28 February 2022 (UTC)
Was editing some articles to use Convert when I came upon something in which I could use some help. Measurements for rectangular and cuboid figures are usually given as 10 x 10 cm or 30 cm x 10 cm x 20 cm, for example. What's the more appropriate way to use convert to handle those measurements? Zera/ talk 13:28, 23 February 2022 (UTC)
More: In the 'loose' format, "x" (ecks) and "×" (times) render the same ("×"), but the 'tight' format currently does not parse "×":
{{convert|30|x|10|x|20|cm|abbr=on}}
→ 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in){{convert|30|×|10|×|20|cm|abbr=on}}
→ 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in){{convert|30x10x20|cm|abbr=on}}
→ 30 cm × 10 cm × 20 cm (11.8 in × 3.9 in × 7.9 in){{convert|30×10×20|cm|abbr=on}}
→
convert: invalid number –
A876 (
talk) 18:24, 29 March 2022 (UTC)
It seems like there's a bug where if I try to show the unit name and the symbol with the order flipped, it does not show the unit symbol. For example:
{{convert|2|kPa|psi|abbr=~}}
→ 2 kilopascals [kPa] (0.29 psi)
{{convert|2|kPa|psi|abbr=~|order=flip}}
→ 0.29 pounds per square inch (2 kPa)
Could someone take a look at this or point me in the right direction? Getsnoopy ( talk) 16:17, 30 March 2022 (UTC)
option=flip
applies. I forget the details but studying the following would probably reveal the reasoning.
In Special:Diff/1080355341, I did two conversions from seconds; one to minutes, the other to hours. But, I had to make that choice manually. Is there some way to say, "Convert this many seconds into minutes or hours as appropriate?" -- RoySmith (talk) 19:39, 31 March 2022 (UTC)
sec
at
Module:Convert/extra. If less than 120 minutes, it defaults to minutes, otherwise hours. Examples:
{{convert|5700|sec}}
→ 5,700 seconds (95 min){{convert|7200|sec}}
→ 7,200 seconds (2.0 h)sec
would be removed and replaced with s
which would be updated to use the new default. It's ok to use sec
in articles now, if wanted. Any problems later will be noticed and fixed.
Johnuniq (
talk) 23:20, 31 March 2022 (UTC)
Where are the links to pre-2020 archived discussions? Judging by the text at the top of
Template talk:Convert/Archive 1,
Johnuniq (
talk ·
contribs) changed the naming system for archiving in July 2020, but I can't find where the older archives are listed even though it says The index for 2007 to 2019 will be moved to this page.
--
Redrose64 🌹 (
talk) 11:47, 5 April 2022 (UTC)
Template talk:Convert/Archive 1
displays the archive in its full glory. In other words, some change at {{
archives}} means that the parameters which worked in July 2020 now hide the old list. Does anyone feel like working out what has happened and how to rectify it. I would prefer that the old archive list is at Archive_1 and not cluttering up the top of this page.
Johnuniq (
talk) 03:12, 6 April 2022 (UTC)Take a look at the "Length" in the infobox on Arleigh Burke-class destroyer. 505 ft gets correctly converted to 154 m, 509 ft correctly becomes 155 m, and then 510 ft becomes 160 m?? That's not correct. Denvercoder9 ( talk) 16:42, 28 April 2022 (UTC)
|round=5
.
Denvercoder9 (
talk) 17:11, 28 April 2022 (UTC)
|0
to force convert to use 0 decimal places for rounding.
Stepho
talk 22:14, 29 April 2022 (UTC)
|0
- which determines the precision of the result - but to use |sigfig=3
, which specifies the precision of the input value: 510 ft (155 m). This is documented at
Template:Convert#Round to a given number of significant figures: |sigfig=.--
Redrose64 🌹 (
talk) 14:02, 30 April 2022 (UTC)
|0
affects significant digits from the decimal point (positive means more digits after decimal point, negative means spread zeroes from the decimal point). |sigfig=3
counts significant digits from the beginning. Both work in most cases, both have advantages/disadvantages in a minority of cases - usually where the output is close to a power of 10 that might or might not add an extra digit.
Stepho
talk 00:15, 1 May 2022 (UTC)Suggestion ... add a non-breaking space – – between the base units and their conversion to prevent confusing separation of the units, like this, at the end of a line:
Instead, it should look like this:
The inclusion on the non-breaking space would have no effect in the middle of a line, viz:
Further, this suggested change to the template would be benign; it would have no material effect on any of the many places where the template is used in existing articles, other than to eliminate the separation of base and converted units if they appear at the end of a line.
Thanks for considering such an improvement to this template. Truthanado ( talk) 23:58, 18 April 2022 (UTC)
Is there a way to denote a conversion from minutes and seconds to total seconds....or, similarly from hours/min/sec....or any such combination. I note that showing minutes and seconds in the template as a minutes-decimal value does work, but would prefer to be able to enter the actual seconds value, rather than its decimal equivalent. DonFB ( talk) 14:47, 6 May 2022 (UTC)