Template talk:Convert

Template:Convert

... in conception

... and in reality

Multiple values in Wikidata

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 has limited syntax for retrieving values from Wikidata, see Template:Convert#Using convert inside templates. If you edit any section at Mendez, Cavite and replace its contents with {{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)

So you agree that this has nothing to do with convert, and that the problem with multiple elevations in WD should/cannot be addressed by converts' "built-in Wikidata support"? When there is more than one value, the article is in Category:Pages with bad rounding precision - where you will see four new articles today with this problem (and look at one of the articles to see how ugly this looks). MB 03:26, 26 October 2021 (UTC)

Thanks for the example. Please do not fix Santo Tomas, Isabela for a couple of days so I have a chance to investigate. That's another annoyance of Wikidata, namely that there is (I think) no way to test what happens here if certain properties are set there. I imagine it's very much to do with convert, but I'll look at it later. Johnuniq (talk) 04:25, 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)

• Different approach: en:Module:WikidataIB (ie, IB=infobox-aimed). This wd-data reader has multiple parameters to tweak the result. For example, |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).

See also Module:WikidataIB § Limiting the returned values, Module:WikidataIB § Parameter sets: clues to returning single values. (end of my current research) -DePiep (talk) 12:16, 26 October 2021 (UTC)

The root problem is the data in WD is unreliable. I don't think there is a basis to expect that the first value in WD is likely to be the "most correct" value. I agree this is the wrong place to discuss this, I just came here reluctantly after Mike Peel pointed this way. Maybe the best we can do on this end is have {{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)

The more general question is what should an infobox do if a parameter should be a number but is not. It's hard using template wikitext to make everything handle all inputs so the current situation (whereby the infobox displays a misleading message and outputs a tracking category) may be the best achievable. Johnuniq (talk) 01:40, 28 October 2021 (UTC)

Rack units?

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)

No, that unit is not supported. I could look at if really needed but the lack of a space in "9U" would be a first for convert and might require a fair bit of stress. Convert does have provision to omit the space for things like $2/ha and for some units at zhwiki so it would just need some serious thought. However, it's more than adding a normal unit. Johnuniq (talk) 23:14, 28 October 2021 (UTC)

Might be easier to develop a new template {{rack unit}} that deconstructs something like {{rack unit|9U}} into a real number of inches that it feeds in turn into convert. --John Maynard Friedman (talk) 00:03, 29 October 2021 (UTC)

In conjunction with Roy, I have developed a new template, {{rackunit}}, which provides this function. For example "This is a {{rackunit|9}} rack-mounted server". produces "This is a 9U (15.75 in, 40 cm) rack-mounted server". This is my first such template so critical appraisal is welcome. --John Maynard Friedman (talk) 19:48, 29 October 2021 (UTC)

Thanks, that's good. You might surround the wikitext with includeonly tags so it doesn't look ugly on the template page. Johnuniq (talk) 23:29, 29 October 2021 (UTC)

Help with rounding please

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)

Sorry, can't do that. If the reference gives 250 PS as the unit but the order shown above is wanted, you can do this:

• {{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)

The second example uses the trick that 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)

Ah ok, thanks for the info. I'm trying to reconcile the reference used (and many others) which gives 246 bhp, with the engine designation as a nominal 250 PS and the preference to put metric first. -- DeFacto (talk). 08:51, 29 October 2021 (UTC)

Looking at it again, it seems the manufacturer gives the power in PS, and the kW and bhp values are calculated as rounded-down values from that (rounding up would exaggerate the value!). Can this be forced to round down: {{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)

No, I'm afraid that can't be done. In case it is of interest, it is possible to round the input value using the following strange syntax. However, the smallest PS that is going to round to 250 is 249.5 and that gives a kW value that is too large.

• {{convert|249.5|PS|kW PS bhp|0|order=out|abbr=on|adj=ri0}} → 184 kW (250 PS; 246 bhp)

Johnuniq (talk) 09:59, 29 October 2021 (UTC)

Fair enough. Thanks for your time. -- DeFacto (talk). 10:06, 29 October 2021 (UTC)

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)

• You know, it is possible to just give the text manually instead of trying to torture {convert} into giving the output you already know you want. EEng 20:49, 29 October 2021 (UTC)

I've seen so many manual conversions done wrong that when I find them I check each one by hand. This is laborious. Whereas the convert template is trustworthy, with most mistakes being rather obvious and easy to fix (usually rounding or order).  Stepho  talk  23:28, 29 October 2021 (UTC)

I do tend to agree with this, especially when it comes to weird units like the rack unit (as mentioned previously here), but personally I've seen so many people who have absorbed bad practices (like people who think a source saying "5000 feet" somehow means precisely "1524 metres") as well as just plain wrong conversions, that I am somewhat wary of over-reliance on automated conversion, at least without the assurance that a competent human is at the helm. It's actually a little disturbing to me to see that someone might have so profoundly internalized the clunkiness and context-obliviousness of automated conversions that they will type stuff like "2 miles (3.2 km)" manually, without pausing to consider commonsense criteria like how such a value might naturally be given in a source using metric units. In this case, someone giving a distance as "about two miles" is virtually never intending it to be understood as having a precision of half a furlong.

I think we should probably clarify somewhere that templates such as {{convert}}, while near-indecently helpful, are not mandatory, that they cannot reasonably be expected to anticipate every use case, and that ultimately it is the text the reader is confronted with that we are concerned with, not the markup or other things that happen behind the scenes. Archon 2488 (talk) 00:18, 30 October 2021 (UTC)

Helper function: accept basic value input

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).

-DePiep (talk) 21:10, 4 November 2021 (UTC) (Module:Convert/helper)

Many infobox person templates already accept free form input. I've never investigated how it works but it seems very effective. Johnuniq (talk) 00:25, 7 November 2021 (UTC)

or(-)

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)

What would 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)

u-value (mpg redux)

Should this work?:

{{convert|2|m2/W|W/m2|abbr=on}} = 2 m²/W ()

I was thinking it should give something like:

{{convert|2|m2/W|W/m2|abbr=on}} = 2 m²/W (0.5 W/m²)

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:

{{convert|2|W/m2|ft2/W|abbr=on}} = 2 W/m² (5 ft²/W)

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)

No, convert is not that clever. The error message it gives (on mouse-over) is 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)

Related discussion at WT:MOSNUM

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)

Quintal

Like to conversions for these in various countries! Lfstevens (talk) 20:13, 24 November 2021 (UTC)

What is a qunital? I think it has never been mentioned here. Is it a well-defined unit? Please give some examples where a conversion would be used in articles. Johnuniq (talk) 01:22, 25 November 2021 (UTC)

Do you mean quintal ?  Stepho  talk  10:29, 25 November 2021 (UTC)

Sorry. Quintal. Lfstevens (talk) 00:02, 26 November 2021 (UTC)

Our quintal article indicates there are many different historic and modern definitions, with some traditional uses still co-existing with modernised ones, varying between countries and even within particular countries. I fear drive-by additions of {{Convert}} by editors that don't know which definition of quintal the source used. NebY (talk) 11:20, 25 November 2021 (UTC)

Good point. The unit is used in our corpus, so some effort may be warranted. Lfstevens (talk) 00:02, 26 November 2021 (UTC)

I predict this will cause tons of trouble. EEng 04:01, 26 November 2021 (UTC)

Or even tonnes. --John Maynard Friedman (talk) 21:55, 26 November 2021 (UTC)

My point exactly. EEng 01:18, 27 November 2021 (UTC)

Weird behaviour when target unit is specified as 1

Consider {{convert|0.1|km2|1|abbr=on}} (0.1 km² (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on}} (0.1 km² (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 km² (0.0 sq mi)) and {{convert|0.1|km2|mi2|abbr=on|sigfig=20}} (0.1 km² (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)

Read section Round to a given precision: use a precision number in the template. The "1" in your examples is specifying a precision (one digit). Tarl N. (discuss) 20:26, 26 November 2021 (UTC)

Thanks. I can't find anything in documentation that would indicate that the target unit is optional. Could you point me at a something that specifies what happens when the target unit is missing? 81.6.39.198 (talk) 20:35, 26 November 2021 (UTC)

Is this what you are asking? Help:Convert units#Default output. The actual defaults are listed at Module:Convert/documentation/conversion data. MB 23:52, 26 November 2021 (UTC)

Convert knows that "1" is a number and not a unit. Therefore it uses 1 for the output value precision, and regards the output unit (the target) as unspecified. Convert then uses the default output unit—see the full list of units. Help:Convert#Quick start is useful. Johnuniq (talk) 23:57, 26 November 2021 (UTC)

Convert is an amazing piece of machinery, but there are places where a less terse input interface might have been better. EEng 01:26, 27 November 2021 (UTC)

Agreed. See https://en.wikipedia.org/w/index.php?title=Vananui&diff=1057305451&oldid=986493280 for a case where someone obviously didn't intend what they wrote (which produced "0.0 sq mi" conversion), but it was unclear what was actually intended. 81.6.39.198 (talk) 02:17, 27 November 2021 (UTC)

Out of interest, what are people expecting |1 to do?  Stepho  talk  03:16, 27 November 2021 (UTC)

I don't know. It was like that since the page was created, with the obviously broken result of saying "0.0 sq mi", so clearly restricting precision was not what was intended. An issue was that e.g. I couldn't easily figure out what that expression meant, so I expect that some people before me were similarly confused and didn't fix the obvious brokennness. 81.6.39.198 (talk) 03:34, 27 November 2021 (UTC)

People are in the habit of putting "|1" because they think otherwise convert might show too many significant figures and the editor hopes their habit is better than what convert can do. Sometimes they are right, but often they are not. Clearly they don't notice the bad results that occur such as in this case. Johnuniq (talk) 03:47, 27 November 2021 (UTC)

I suspect a lot of people are doing Voodoo programming, where they copy an example from somewhere, without knowing what most of the parameters do but maybe get it somewhat close by editing the main input number and the unit. Sadly, we can't really simplify convert without also giving up lots of its benefits. Thankfully, it does a good job with defaults when minimal parameters are used.  Stepho  talk  04:09, 27 November 2021 (UTC)

Good point. I used to do a lot of cleaning of converts to reduce the number of bad examples that might be copied elsewhere but I got a bit tired of it... Johnuniq (talk) 04:26, 27 November 2021 (UTC)

Couldn't we make the "number of digits" precision a keyword argument? Obviuosly we can't remove the positional argument (at least without a large amount of semiautomated edits), but if we added a possibility to use it as a keyword argument and changed the documentation to suggest that in the first place, we'd eventually make the kind of confusion I had when I thought "1" represented units less common. — Preceding unsigned comment added by 81.6.39.198 (talk) 11:31, 27 November 2021 (UTC)

Yes, thank you. 81.6.39.198 (talk) 02:17, 27 November 2021 (UTC)

Link for deadweight ton

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)

Thanks for the report. I have made a note to change the link from Tonnage to Deadweight tonnage for units DWton and DWtonne. That won't happen for a while—I'll need to do another check of the other units. Johnuniq (talk) 09:51, 30 November 2021 (UTC)

An error in miles to km conversion

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 km²), of which 943 sq mi (2,440 km²) are land and 0.3 sq mi (0.78 km²) (0.03%) is covered by water.

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)

The article passed 944 to convert, when the actual number in the source is 943.3. The article now reads:

According to the U.S. Census Bureau, the county has a total area of 943.3 sq mi (2,443 km²), of which 943 sq mi (2,440 km²) are land and 0.3 sq mi (0.78 km²) (0.03%) is covered by water.

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.136 km²), of which 943 sq mi (2,442.359 km²) are land and 0.3 sq mi (0.777 km²) (0.03%) is covered by water.

which shows convert is correct.MB 05:14, 8 December 2021 (UTC)

• This example really goes straight to the heart of the overprecision problems so rampant on the project. EEng 06:06, 8 December 2021 (UTC)

Looks like it automatically rounded km to 3 digits (same as the 3 digit input). So we tell it to round to units (ie 0 digits after the decimal point) by adding |0 like so:

{{convert|944|sqmi|abbr=on|0}}, of which {{convert|943|sqmi|abbr=on|0}} ---> 944 sq mi (2,445 km²), of which 943 sq mi (2,442 km²)

Convert does the right thing most of the time, so we get confused when it gets it wrong.  Stepho  talk  10:57, 8 December 2021 (UTC)

@EEng: please read the post that is right above & before yours (05:14, by MB). Your post does not respond. Or, more precise: you are denying/ignoring the wellbased claim stated. Also, one wonders how your contribution actually tries to forward the discussion. -DePiep (talk) 11:35, 8 December 2021 (UTC)

References