Template talk:Convert

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Frequently Asked Questions (FAQ)
Q: When using {{convert}} why does the answer not seem right sometimes?
A: This template takes into account the precision of the supplied value and generally rounds the output to the same level of precision. If you need to change from the default output precision, see Help:Convert.
Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)?
A: See: Help:Convert units.
For more, see the FAQ.

Angle conversions[edit]

Can someone add Angular units to CONVERT? degrees, radians, gradians, hms, DMS; I suppose the overlapping names for seconds and minutes (and hours; days) would cause problems. -- (talk) 06:14, 2 September 2015 (UTC)

I suppose we could call them "minutes of arc"/arcminute/arcmin, etc... but hms and DMS conflict... -- (talk) 09:22, 2 September 2015 (UTC)
What are some examples where this would be useful in articles? Johnuniq (talk) 07:34, 2 September 2015 (UTC)
In many astronomical sources, there are differences in recorded units, depending on era, so converting them from the referenced source to the onpage value without hiding where a number appeared from is a good idea. Angles are used to establish where things are relative to others, how fast them move across the sky, and stellar parallax. -- (talk) 09:22, 2 September 2015 (UTC)
In Wikipedia articles (and the astronomy sources I've read) it is routine to convert a format that occurs in a source to a format that is consonant with the citing article, with no mention of the original format. Even if, in some unusual situation, we needed to quote the original format as well as provide the consonant format, we would put the original format in a footnote, and the "convert" template wouldn't help with that. Jc3s5h (talk) 12:19, 2 September 2015 (UTC)
Convert would show the original source's number, in source view, and display the number in a manner consistent with how the article should show things. As several sources use decimal degrees for right ascension and declination, while Wikipedia consistently uses hms±DMS, it would be good to actually show the reference's values in source view while displaying the expected consistency values in rendered view. This will save on people asking where some number appeared out of thin air from, or deleting numbers that aren't explicitly in the references used as original research. Non-astronomy editors also work on Wikipedia, and we cannot expect all of them to understand the implicit conversions used, instead of just flagging the numbers as unreferenced, or removing them outright because they don't appear as written. -- (talk) 04:42, 3 September 2015 (UTC)
Post by (talk · contribs) is factually incorrect. Convert shows both the unit converted from and the unit converted to; there is no "hidden value" that is only shown in source view. Also, Wikipedia has no preference as to whether hours-minutes-seconds, degrees-minutes-seconds, decimal degrees, or some other variation is displayed in articles, although consistency in articles is normally expected. Jc3s5h (talk) 09:26, 8 September 2015 (UTC)
I've commented at WT:WPM but I'll repeat the same sentiment here: I think this would be of little use, and possibly harmful, for pure mathematics articles. Of little use, because most of the time in mathematics articles one wants to express an angle as an exact formula (π/2 radians) not an approximate numeric value (1.5708 radians), and I doubt that getting symbolic mathematical manipulation right is within the scope of this template or the template system in general. Harmful, because if this exists then naive editors will start insisting that it needs to be used for all angle measurements in all articles, and apply it even in situations where it would be inappropriate. —David Eppstein (talk) 07:01, 7 September 2015 (UTC)
I'm sure you're right. I've asked for specific examples (mainly below) where the proposed new units would be useful, and it is very unlikely that anything will happen unless several are available. Johnuniq (talk) 10:30, 7 September 2015 (UTC)
As I've already stated, for angle conversions, they would be very useful, for consistency of display of units between articles, while displaying the originating source's values, for astronomy topics. Especially considering the differing values for the location in the sky of some astronomical objects being expressed in decimal degrees instead of the standard hms/DMS values for our articles for right ascension and declination. And for sources that use degrees of arc in expressing angular separation and parallax instead of milliarcseconds (mas) which is the usual measure used in our articles. -- (talk) 04:58, 8 September 2015 (UTC)
I don't think the template would be useful in the articles right ascension or declination. All of the conversions done there are exact. A template that does decimal manipulation would be inappropriate. In parallax, most of the conversions are done in displayed math, so a template wouldn't be useful. (Also, we wouldn't add to this template for the sake of a single article, even if the equations were converted from displaymath to html). Sławomir
15:39, 8 September 2015 (UTC)
Why are they 'exact' conversions? Right ascension and declination are measured quantities. They are only accurate to certain decimal places, and not beyond, because there is a limit to how precisely things can be measured depending on the limits of the instrument involved. -- (talk) 05:35, 15 September 2015 (UTC)
Here are the conversion that the article right ascension makes:

Any units of angular measure could have been chosen for right ascension, but it is customarily measured in hours ( h ), minutes ( m ), and seconds ( s ), with 24h being equivalent to a full circle. Astronomers have chosen this unit to measure right ascension because they measure a star's location by timing its passage through the highest point in the sky as the Earth rotates. The highest point in the sky, called meridian, is the projection of a longitude line onto the celestial sphere. Since a complete circle contains 24h of right ascension or 360 degrees of arc°, 124 of a circle is measured as 1h of right ascension or 15°; 1(24×60) of a circle is measured as 1m of right ascension or 15 minutes of arc (also written as 15'); and 1(24×60×60) of a circle contains 1s of right ascension or 15 seconds of arc (also written as 15"). A full circle, measured in right ascension units, contains 24×60×60 = 86,400s, or 24×60 = 1,440m, or 24h.

Let me get this straight. You're saying that the article shouldn't be doing exact conversions anyway, like between 1/24 of a circle and exactly 15°, because right ascension is a "measured quantity"? That's a bit baffling, but if that's the case, then it looks as though you are trying to use this template as a pretext for imposing an idiosyncratic view on article content. I am strongly opposed to this proposed usage of the template, to replace exact conversions by decimal approximations. Sławomir
11:32, 16 September 2015 (UTC)
Let's get this straight, the values presented in our articles for right ascension and declination are not exact because they are measured with a device, since they represent a measurement of an object in the sky. Any measurement by any device is inexact. The conversion of any real measured right ascension / declination can never be exact because we do not have perfect instruments from which to measure these quantities. Theoretically the conversion from inches to millimeters is exact but actual quantities measured with say a micrometer or a laser rangefinder, is not exact, because they are measured quantities, and thus can only be represented with an inexact value. CONVERT right now does significant figure calculations for conversion between units, because they are measured values. This is the same case with right ascension and declination. CONVERT does not produce exact conversions (which make no physical sense), it produces that to the level of precision provided by hte input value, or the significant figure parameter provided. (it makes no sense provide more precision that the original measurement has, since those decimal places represent illusionary non-physical precision that is not accurate) -- (talk) 05:18, 17 September 2015 (UTC)
"the values presented in our articles for right ascension and declination are not exact": Yes, I got that you believe this. I got that you don't believe that 1/24th of a circle is exactly 15°. This is why I am strongly opposed to adding angles to the template, because it seems like you are using the template as a pretext to impose some weird view on article content, in which we are not permitted to say that 1/24 of a circle is exactly \pi/12 radians. That's never going to happen. Sławomir
10:44, 17 September 2015 (UTC)
No, the values presented for "right ascension" and "declination" Just as you find at Mount Everest, the height is not exact; by analogy, how would you ever come to the conclusion that the conversion between metres and feet would be an exact figure, when there are error ranges for the initial value? This is exactly the same case. I don't see how you could ever think any value that is measured for any astronomical measurement would ever be exact since they are being measured by man and not God, for every single astronomical location ever measured -- (talk) 03:06, 18 September 2015 (UTC)
IP, you were asked to provide examples of articles where the template would be useful. The examples you gave were right ascension and declination, right? You've been arguing that these conversions are meaningless as exact values. That's just wrong. Mount Everest has no angle conversions, so it seems to be a red herring. Conversions from meters to feet are rather different, because they are not based on intrinsic geometric properties of circles. Sławomir
19:48, 18 September 2015 (UTC)
This whole line of argument makes no sense. Sometimes a value quoted in a WP article will be exact (a defined or nominal value, say) and sometimes it will be inexact (a measurement or an approximation). You need human intelligence to differentiate between those cases and adjust the conversions appropriately. Archon 2488 (talk) 11:52, 17 September 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── It seems to me that the request is rather garbled. I think that simple unit conversions amongst angle units are absolutely appropriate and should be in the template. eg
{{convert|30|arcmin|deg}} should output "30 arcmin (0.5°)"
{{convert|30|arcsec|arcmin|abbr=on}} should output 30" (0.5')
{{convert|20|deg|hms}} should output "20° (1h 20m)"
{{convert|20.5|deg|dms}} should output "20.5° (20° 30m)"
{{convert|20d30m|dms|deg}} should output "20° 30m (20.5°)"
The last one might be technically difficult to parse; I don't know templates well enough to know. I agree with others that converting to radians gets trickier because notation conventions involving pi exist for a very good reason and would be difficult to parse; editors would have to use it with considerable caution if the functionality were to exist in the convert template at all. However, the radians thing is a distraction; radians are essentially never used for the astronomical purpose mentioned by the IP. The main use of radians in this context would be for small angle approximations on the order of arcsec, for which the concern about exactness doesn't apply. (Not sure if that ever gets done on Wikipedia, though.) —Alex (Ashill | talk | contribs) 14:00, 17 September 2015 (UTC)

The examples of where this template would be deployed do not fill me with confidence that the template would be used wisely, if at all. WP:BEANS seems to apply here. Sławomir
14:54, 17 September 2015 (UTC)
The example you quoted above is just an example defining the term. So yes, when the article says as an example that 12h of right ascension corresponds to 180° or pi radians, that's exact. But a much more common usage is to say that the Andromeda Galaxy is at right ascension, declination of 00h 42m 44.3s, +41° 16′ 9″. It would be convenient to be able to plug that into convert and get out 10.68°, +41.27°. But researching this further, Template:HMS2Deg and Template:Deg2HMS may be part of what is looking for: {{HMS2Deg|00|42|44.3}}: 10.684583. But it would still be useful to have the convert template handle things like "The semi-major axis of the Andromeda Galaxy is 190' (3° 10')." —Alex (Ashill | talk | contribs) 13:23, 18 September 2015 (UTC)

Proposed new units[edit]

Angular change per unit time[edit]

With angle units, it would also be good to have change between angular change per unit time and Hertz (cycles per second), since one cycle is 360-degrees. So 90-degrees per second would be a quarter of a full cycle, so 0.25Hz -- (talk) 06:25, 2 September 2015 (UTC)

What are some examples where this would be useful in articles? Johnuniq (talk) 07:34, 2 September 2015 (UTC)
I was thinking the speed of a rotating vector should be able to be expressed in Hertz easily and back to radians to show what an electromagnetic field's rotation would result in a particular field signal, thus good for various EM descriptions. -- (talk) 09:30, 2 September 2015 (UTC)


Can revolutions per minute / r.p.m. ; and beats per minute / b.p.m. be integrated into the conversions for cycles per unit time? 60rpm would be 1Hz. Since rpm is a common measurement for recycling times, it should be available for conversion. -- (talk) 09:30, 2 September 2015 (UTC)


Can beats per minute / b.p.m. be integrated into the conversions for cycles per unit time? 60 bpm would be 1Hz. -- (talk) 09:30, 2 September 2015 (UTC)

The sentence "60 bpm would be 1Hz" is an exact conversion, so presumably not allowed on Wikipedia per the new "only decimal approximations allowed" regime. Sławomir
11:50, 16 September 2015 (UTC)

Discussion of proposed new units[edit]

My earlier comment was "What are some examples where this would be useful in articles?" This comment is an attempt to explain what I was getting at. More than a thousand units are defined in convert (not counting the many variations like SI prefixes), and hundreds of units are not used. I am very reluctant to add more units just because it's possible. Instead, please find an article with some text that could be improved with a new unit. If it's just one article, I would still think that there was no need for a new unit—something that is used just a couple of times does not need the complexity of automatic conversion. What gets fast attention on this page is when an editor is developing a series of article and finds that the text they are adding needs some unit unknown to convert. That hasn't happened for quite a while, but when it does, something is done. Extra units require documentation and maintenance, and add to the clutter of the list of all units, making it harder to find units that are actually useful. Johnuniq (talk) 07:59, 3 September 2015 (UTC)

long ton not abbreviated[edit]

Is this conversion doing the right thing?

1,120 t (1,100 long tons)

Shouldn't it render as:

1,120 t (1,100 LT)

Trappist the monk (talk) 12:51, 6 September 2015 (UTC)

In cases where there is not a standard symbol or abbreviation for a given unit (or where a unit name could not be contracted without risking widespread confusion or ambiguity), the template opts for the more conservative approach and spells out the unit name in full. The long ton and short ton do not have any standard abbreviations; same with some other units like the acre. Archon 2488 (talk) 15:13, 6 September 2015 (UTC)
Archon's answer is perfectly correct, and I find all the t/ton/tonne/LT/ST units a complete nightmare, however someone must have made a fuss about this particular case a long time ago because there is a kludge:
  • {{convert|1120|t|LT|abbr=on}} → 1,120 t (1,100 long tons)
  • {{convert|1120|t|lt|abbr=on}} → 1,120 t (1,100 LT)
This unit is in the full list and is used rarely in articles (around 80 times), with LT occuring over 21,000 times. Johnuniq (talk) 00:19, 7 September 2015 (UTC)
See also {{long ton}}. It does avoirdupois. -DePiep (talk) 21:19, 9 September 2015 (UTC)

Problem with hundredweight[edit]

I have a problem with the conversion of hundredweight. A hundredweight is 8 stone (110 lb) (WTF - 8 stone = 8 x 14 = 112 lb) but the template says 1 long hundredweight (110 lb; 51 kg). This is wrong. Can someone please fix this? Hawkeye7 (talk) 20:36, 8 September 2015 (UTC)

Oh I see. The problem is with the rounding. I need {{convert|8|st|lb|0}} (8 stone (112 lb) ) and {{convert|1|long cwt|0|lk=on}} (1 long hundredweight (112 lb; 51 kg)) Grrr. Hawkeye7 (talk) 20:41, 8 September 2015 (UTC)
Yes, I'm afraid rounding still trips me up occasionally. I don't think there is anything that can be done because the defaults works so well, mostly. Johnuniq (talk) 02:11, 9 September 2015 (UTC)
There exists dedicated conversion template {{long ton}} for this input:
100 long cwt (11,200 lb or 5,100 kg) → 100 long cwt (11,200 lb or 5,100 kg)
It mainly solves the four-number input option for long ton nicely. Maybe Jimp could consider adding stone. -DePiep (talk) 07:47, 9 September 2015 (UTC)
Thanks. I was not aware of this. Note however that it has the same problem with rounding: {{long ton||1}} → 1 long cwt (100 lb or 100 kg) Oops. I would need {{long ton||1||0}} → 1 long cwt 0 lb (112 lb or 51 kg) Hawkeye7 (talk) 21:02, 9 September 2015 (UTC)
Yes it has the same rounding issue ;-) In general, rounding is more stable & consistent in SI. {Convert} could have different rounding rules for non-SI units. And, as I said, {{long ton}} could cover stones & all of avoirdupois. But please remember where we came from, in this :-). -DePiep (talk) 21:15, 9 September 2015 (UTC)

The advantage of {{long ton}} is that it allows more than two sub units. I don't remember why I didn't include stones (perhaps I thought it might have been an overkill). Should they be added, do you think (how about ounces, drachms & grains)? Jimp 02:47, 10 September 2015 (UTC)

Yes, you should. Back in the day, you would not have said 1 cwt 16 lb; that would have been incorrect. You would have said 1 cwt 1 st 2 lb. This despite the fact that it would have been quite normal to say 16 lb or indeed 16 st. Baby boomers still measure their weight in stones, but us Gen X-ers grew up with metric. The rule anyway was that the highest could be used freely, but the rest follow in strict order. You don't have to say zero though; 1 cwt 0 st 2 lb would have been normal, but 1 cwt 2 lb would also have been acceptable. Hawkeye7 (talk) 06:37, 11 September 2015 (UTC)
For what it's worth, an old arithmetic book of mine (published 1899) didn't use stones but had exercises like (and I quote)
  • "From 137 tons 12 cwt. 1 qr. 18 lbs. take 47 tons 12 cwt. 0 qrs. 24 lbs."
We made us own fun in them days! --Boson (talk) 15:27, 11 September 2015 (UTC)
PS: I see an older book on arithmetic has

... 16 ounces = 1 pound, 28 pounds = 1 quarter of a hundred weight, 4 quarters, or 112 pounds = 1 hundred weight, 20 hundreds = 1 ton." The stone, in the greater number of places, is 14 pounds, or one eighth of the standard hundred, but in different parts of England it is found to be of various magnitudes, from 8 to 16 pounds. In Ireland, also, in the sale of some articles, the stone of 16 pounds, or one seventh of the standard hundred is used.

— James Thomson LL.D., Professor of Mathematics in the University of Glasgow, A Treatise on Arithmetic, in theory and practice
That might explain not using stones. --Boson (talk) 15:57, 11 September 2015 (UTC)
  • Another issue with these non-SI multiples is: how to represent 3 12 ft? Could be 3 12 ft and 42 in. -DePiep (talk) 21:19, 24 September 2015 (UTC)

Conversion from inches to millimeters[edit]

"convert|5.2|in|mm|abbr=on|disp=flip" is showing 130 mm for both 5.2 and 5.3 inches, which should equate to 132.08 mm and 134.62 mm respectively. --uKER (talk) 04:04, 11 September 2015 (UTC)

The following shows the issue:
  • {{convert|5.2|in|mm|abbr=on|disp=flip}} → 130 mm (5.2 in)
  • {{convert|5.3|in|mm|abbr=on|disp=flip}} → 130 mm (5.3 in)
Convert determines what default precision should apply in order to show the output that corresponds to the precision of the input. The precision can be specified:
  • {{convert|5.2|in|mm|0|abbr=on|disp=flip}} → 132 mm (5.2 in)
  • {{convert|5.3|in|mm|0|abbr=on|disp=flip}} → 135 mm (5.3 in)
  • {{convert|5.2|to|5.3|in|mm|0|abbr=on|disp=flip}} → 132 to 135 mm (5.2 to 5.3 in)
Johnuniq (talk) 04:20, 11 September 2015 (UTC)
I don't get whether that's supposed to mean that there's not a problem, or if it's a reaffirmation of my report. You editing my title makes me think it's the former. Care to clarify? I still don't think the default behaviour should be a conversion that's off by 4.62 mm in the case of 5.3 inches. --uKER (talk) 13:46, 11 September 2015 (UTC)
The template doesn't (and probably can't) have the intelligence to convert units to the appropriate precision in every instance. For example, if a source says that one town is about 60 kilometres away from another, you'd want to convert that as {{convert|60|km|mi|sigfig=1}} → 60 kilometres (40 mi) (providing an equivalent approximation in imperial), whereas if it was a course designed to be exactly 60 kilometres long, you'd probably convert it as {{convert|60|km|mi|sigfig=2}} → 60 kilometres (37 mi) (converting the nearest kilometre to the nearest mile). You need to provide some editorial oversight, using the template options to adjust significant figures and decimal places. There isn't a shortcut, to the best of my knowledge. Archon 2488 (talk) 14:31, 11 September 2015 (UTC)
The documentation says (confusingly) "Specify the desired precision with the fourth unnamed parameter (or third unnamed parameter if the "convert to" parameter is omitted; or fifth unnamed parameter if a range is specified;", Template data section says it's 4th unnamed parameter. The documentation for rounding is very near the top, and the documentation on parameters is very near the bottom. So I think of two changes when I read these repeating complaints (whose frequency is alarming): 1) Better documentation (probably won't help, but there's always hope and room for improvement). 2) Better practice. Could Convert default to maximum precision? i.e. make a user undo precision, instead of adding it. Err on the side of too much? Never err on the side of a mistaken reader-editor interpretation; i.e. zeroes are always significant, until otherwise stated in a parameter? — CpiralCpiral 19:52, 11 September 2015 (UTC)
All references to "unnamed" parameters should probably be removed and replaced with simple clear examples of |precision=nnn and |sigfig=nnn. —Sladen (talk) 20:29, 11 September 2015 (UTC)

What I'm saying is that convert cannot handle all cases well. The current situation sometimes causes problems, but if convert gave extra precision on the assumption that editors could reduce the precision to what was appropriate, there would be complaints that convert was stupidly inventing precision not present in the input. Also, working out what is appropriate is not always straight forward. There is no precision=n parameter and introducing one now would not help because hundreds of editors are used to how convert works and they are not going to change, and there are well over 100,000 converts in articles that use the current method of specifying a precision just as a number. There are infrequent reports here of problems with rounding, but it's nothing like the debates that used to rage—for example, search October 2009 (and many other archive pages) for "rounding". What might help would be to brush up the documentation as suggested, but more importantly tweak the FAQ at the top of the page and introduce a brief page notice that is displayed when editing this page—it would point to the FAQ. For the particular case of converting a value of around 5 inches to mm, I've just single-stepped the code (function default_precision in Module:Convert) and I suppose it could be improved as a special case. However the trick would be working out how any change would impact other conversions—small tweaks can have unforeseen consequences. Johnuniq (talk) 01:25, 12 September 2015 (UTC)

Johnuniq, see Template:Convert/doc#Round to a given precision: use .7Cprecision.3D. —Sladen (talk) 10:48, 15 September 2015 (UTC)
Thanks for pointing that out. I have fixed the documentation so it no longer implies there is a parameter named precision. I decided to omit some of the complexity because people just want to know how to use convert, and there is no reason to try to explain how it works, particularly since there are various exceptions. Johnuniq (talk) 12:19, 15 September 2015 (UTC)
Johnuniq. Thank you, although I see this has now been reverted.[1]. Peter coxhead, you appear to have invoked WP:BRD, please could you help join the discussion so that we can get some corrected wording that also works for everyone? —Sladen (talk) 13:55, 15 September 2015 (UTC)
I just thought that removal was a step too far. I suggest moving the mathematical details to a footnote, and just showing, by examples, what the default is in some cases and how this can be changed. I only have limited internet access at present, so don't want to attempt this myself now. Peter coxhead (talk) 14:45, 15 September 2015 (UTC)
My edit briefly mentioned what default rounding does, and included several examples. If the details were in a footnote they would have to be correct, and there is more to it than the documentation stated. The result would be totally opaque. Please see the new section just below. Johnuniq (talk) 23:46, 15 September 2015 (UTC)

Documentation details[edit]

The above section started discussing Template:Convert/doc. What do people want? My edit (diff) did a bunch of things but apparently the edit to "Default rounding" or "Round to a given precision" was too much and it was reverted. The before-and-after are below:

Section Original Proposed
Rounding By default, the conversion result will be rounded either to precision comparable to that of the input value (the number of digits after the decimal point—or the negative of the number of non-significant zeroes before the point—is increased by one if the conversion is a multiplication by a number between 0.02 and 0.2, remains the same if the factor is between 0.2 and 2, is decreased by 1 if it is between 2 and 20, and so on) or to two significant figures, whichever is more precise. An exception to this is rounding temperatures (see below). By default, the conversion result is rounded to a precision comparable to that of the input value.
Precision Specify the desired precision with the fourth unnamed parameter (or third unnamed parameter if the "convert to" parameter is omitted; or fifth unnamed parameter if a range is specified; or fourth unnamed parameter again if a range is specified and the "convert to" parameter is omitted; needs to be replaced with a "precision" named parameter). The conversion is rounded off to the nearest power of 110 this number. For instance, if the result is 8621 and the round number is "-2", the result will be 8600. If the result is "234.0283043" and the round number is "0", the result will be 234. The precision is entered as an unnamed parameter after the units.

The precision is 0 (round to nearest whole number), or a positive integer (round to the specified number of decimal places), or a negative integer (round to a power of ten, so the result finishes with the specified number of 0s).

A few years ago very extensive discussions were held about how rounding should work, and whether it was possible to implement using templates. At that time, the docs were updated to reflect the different ways that default rounding worked while people developed ideas. The solution implemented by Jimp has been universally accepted and has worked well for years, with the implementation now in Module:Convert. The system of default rounding works so well that people are surprised when it does not do what they expect, and there are occasional issues like in #Possible Convert Problem? and the previous section. However, the details of how rounding works are no help with those queries because the point is that the default does not do what the editor wants.

What should be in the documentation? Johnuniq (talk) 23:40, 15 September 2015 (UTC)

Principally working examples are what should be in the documentation. Examples are self-evident to readers/users. Distracting paragraphs of text about unnamed parameters and syntax from five years ago aren't helpful.Sladen (talk) 00:24, 16 September 2015 (UTC)
Agreed. Learning Perl6 for example, at first I only want a REPL and examples. — CpiralCpiral 07:14, 16 September 2015 (UTC)
What should be in the documentation? Overall, better prose. Even the section titles have examples in them, and the examples are thick as bear hair. There's not enough prose balance for those who're looking to read the whole document in one sitting. I've read Convert only a few times. It was numbing, but I played the stalwart. I remember liking the many examples, and seeing a few style inconsistencies, and shuddering at the thought of editing them.
OK, if it were up to me, I'd take a few weeks, rework the overall arrangement (placement of section titles and their material), and add some new prose for lubrication.
==Rounding and precision == 100 ft is exactly 30.48 m. But 100 ft could call for a conversion to 30 m or 30.5 m, depending on the intended accuracy of the original call being cited. Template Convert uses roughly the number of significant digits, or you can change that with |sigfig= or ... and where conversions are required, the same accuracy must propogate to the conversion."
The TOC should flow like a narrative, like prose, and the prose take full advantage of hyperlinking and footnotes to reduce its size. Examples are primary and are what is needed, and there is no lack of this beneficial goodness, but section titles shouldn't have numbers or question marks or examples either. The entire TOC should have only subject matter phrases.
New, number-savvy, users will most likely also be in a big a hurry, and should be able to jump from the TOC subject to the given numerical examples (not at the given numerical example), and still be in and out in 10 seconds. In my tech-writing book, it's forbidden to force the reader to return there gaze back to the section title. In doing so, they'll likely be back for involvement later, and then they'll want to read the whole thing with good prose. But this means a new style for C/doc, and if one then all section titles must be purified.
CpiralCpiral 07:14, 16 September 2015 (UTC)

Thanks for the ideas but the perfect is the enemy of the good.

  • Any thoughts on whether the docs should have the Original text in the table above, or the Proposed text?
  • Any thoughts on whether this edit (the one that was reverted) should be restored?

After that, other edits can be considered. Johnuniq (talk) 07:41, 16 September 2015 (UTC)

I would hope that we could start by restoring the edit, and that when other editors have internet access again those editors can work forward to improve the edit rather than stepping us backwards by performing a wholesale revert. As for wording, perhaps we could tighten it even more. "Rounding to a specific number of decimal places is performed by adding an extra positive integer parameter. If the rounding is zero or negative there will be no digits after the decimal place, and the result will be rounded to the nearest power of ten. Otherwise, a suitable precision and rounding will be chosen based on the input value." And then 3–4 examples. —Sladen (talk) 10:59, 16 September 2015 (UTC)
re Cpiral: I have put the examples in the /doc section headers, and still think that they belong in there. /doc is not for "reading the whole stuff before using the template", it is about finding the detail you are looking for. Is what TOC is helping in. So I'm with Sladen here. btw, {{this template}} has the samenot any more. (Or would you like having to read all the technically extended options?) -DePiep (talk) 15:45, 16 September 2015 (UTC)
The TOC top level probably won't provide what must be "remembered on the way through the hyperlink" to a whole 'nother environment. They'll expect the actual numbers and questions to pop up where they land. No one should notice or complain if the numbers were different, because it's just a TOC. Therefore, except for highly refined subtopics, say level ==== headings, having example material in the headings is unnecessary clutter where subject descriptions are readily available. Although 99% of users need quick examples and be gone, our most prized users will settle down here and read it all, looking for that structure I claim is missing. — CpiralCpiral 18:02, 16 September 2015 (UTC)
I don't understand. The reader looks in the TOC to find their detail of question (helped by a sharp example in there). Then clicking a TOC line brings the reader to the topic, with description, demos & more. -DePiep (talk) 15:11, 17 September 2015 (UTC)
Yes, to guide a seeking newcomer better where terminology in the heading is new, like Adjective, but it's not a style. It is apparently needed here in some cases, but for headings, shorter is better. Readers should know the terms "rounding" and "fraction", and "symbol" for example, if shorter headings were pursued. — CpiralCpiral 18:18, 18 September 2015 (UTC)
The MOS you link to is for content. Documentation may have other requirements. Also, using single word headers may be too short. Most doc topics have two or more elements (e.g., input and output, or 'multiple units' can be m,ft-in or km, mi, nmi). A word image (example) is very strong, and it skips the mental step having to read descriptions. -DePiep (talk) 19:24, 20 September 2015 (UTC)
Oops, my other example is gone for unclear reasons. The appearance is still here. -DePiep (talk) 15:25, 17 September 2015 (UTC)
Revert back but with tweaked prose and footnoting "how convert works", else someone will have to experiment to find out that 0.2 and 2 and 20 are magic. — CpiralCpiral 18:02, 16 September 2015 (UTC)


I agree with Wolfram and the this redirect that the term "precision" is synonymous with "significant figures", and that it might better be termed "accuracy" instead. But because "precision" may be "established", and because it seems to be advertised as a future parameter name, I thought it deserved a subsection.

Alternative terms to this colloquial and imprecise use of "precision" are "|trueness=" and "|scale=".

There are two attributes of numbers, the length and the scale. The length is the total number of significant decimal digits in a number and the scale is the total number of decimal digits after the decimal point. For example:

.000001 has a length of 6 and scale of 6.

1935.000 has a length of 7 and a scale of 3.
— The man page.

CpiralCpiral 02:55, 17 September 2015 (UTC)

Is this correct for non-SI units too? -DePiep (talk) 20:12, 17 September 2015 (UTC)
I don't peruse the units literature. It was just a math thing. It's a good question, and I assume, a rhetorical one. — CpiralCpiral 22:00, 17 September 2015 (UTC)

Another alternative is to just write it out, and not make up a term for it, as I have done in an edit of Template:Convert#In temperatures: rounding °C, °F and K (Man, those section titles are scary.)

Lose precision. That edit shows the worst of Convert behavior. It does so on purpose. I think the behavior is wrong, and should rely only on significant digits, and just lose "precision" and any focus on decimal points, and the hidden side-effect. — CpiralCpiral 22:00, 17 September 2015 (UTC)

Alternatives to "precision" (because of the Wolfram complaint noted and linked-to above)

  • radix=-1 or radix=0 or radix=2
  • scale

CpiralCpiral 17:35, 24 September 2015 (UTC)

Energy units for chemistry and physics[edit]

eV discussion[edit]

Is it possible to include a conversion from electronvolt (used in physics) to kilojoules per mole (used in chemistry)? We can convert from eV into kJ currently, which is 6.02 X 1023 times too little. --John (talk) 11:31, 20 September 2015 (UTC)

I suppose we should have a kcal/mol option as well for the recalcitrant non-SI contingent. --John (talk) 11:41, 20 September 2015 (UTC)
It's traditional for me to ask for a couple of articles where the conversion would be helpful (see #Angle conversions and #Proposed new units above for why that is needed).
There are two "Energy per chemical amount" units: kcal/mol + kJ/mol. The reason they cannot be converted to eV is that the latter is just "Energy". Would any energy units other than eV be wanted for similar conversions? I guess the simplest would be to make a new unit which means eV as used in this case—it would also be an "Energy per chemical amount" unit.
I don't really have to understand the use case, but is there a brief explanation of how energy (eV) can be converted to energy/amount (kJ/mol)? I guess the new unit is some kind of energy per molecule?
What is needed is the unit code of the new unit (the text used in a convert), and the symbol to be displayed, and the name to be displayed if abbreviations are off, and the article for a link, if links are on. I guess the conversion factor is like eV to kJ, but also multiply by the Avogadro constant? Johnuniq (talk) 12:35, 20 September 2015 (UTC)
It's an issue at flerovium and I am confident (without actually having checked) that there will be other articles on exotic elements that kludge the units like this. Electronvolts is per particle, and chemistry typically talks about per mole, so yes, the Avogadro constant is the conversion factor here. --John (talk) 13:35, 20 September 2015 (UTC)
If the statement John made for flerovium [2] is sound, it may be used in most chemical & element articles, possibly by infobox too. -DePiep (talk) 23:42, 20 September 2015 (UTC)
Traditionally convert has only converted between different units for the same quantity. This would be a "conversion" of a different nature, between different kinds of units. It's similar to trying to convert mass to density. I would hope that people writing or reading about energy per mole would be proficient at conversions, and not need a template. If there is to be a template, I suggest a different template. Otherwise we will be going down a slippery slope, and people will be asking the convert template to convert between the American Democratic Party and the corresponding party in Australia. Jc3s5h (talk) 17:09, 20 September 2015 (UTC)
(ec) I'm a physicist, not a chemist (and thus don't know chemistry conventions), but electronvolt is just an energy unit. eV/particle is per particle (and can thus be converted to kJ/mole), but eV can't be converted to kJ/mole. Of course, "particle" is dimensionless, so eV/particle is in some sense equal to eV, but to me, dropping the "per particle" and converting straight to kJ/mole would be very confusing notation. In any use of eV outside of energy levels in a particle, converting eV to kJ/mole would be wrong. So it seems to me that adding eV/particle and kJ/mole (and, why not, eV/mole and kJ/particle) to convert would be a better approach. —Alex (Ashill | talk | contribs) 17:17, 20 September 2015 (UTC)
I've thought about this quite a lot. Both "per particle" and "per mole" are dimensionless, because a mole is a number unit like a dozen or a million. Physicists generally use the energy unit eV without specifying "per particle", whereas chemists are usually more punctilious about saying "per mole". So these are indeed different units for the same quantity, @Jc3s5h:, and not like your example of political parties from different countries, even though that might not be apparent at first glance. Blame lazy scientists who write "eV" when they mean "eV per particle". If this is a one-off thing, of course there is no problem, but I suspect it is fairly prevalent. I will look some more and think some more. --John (talk) 19:32, 20 September 2015 (UTC)
The more I think about it, the more I think that @Ashill:'s suggestion is the right one; I just worry that if the conversion {{convert|x|eV/particle|kJ/mol}} defaults to display x electron volts per particle (y kJ/mol), it might look rather odd in articles where a particular type of particle is being discussed, say a nucleus. As I say, I don't often recall the "per particle" being stated as I guess physicists take it as read in a way that chemists don't. Any thoughts? --John (talk) 23:25, 20 September 2015 (UTC)
We could define "/particle" and "/mole" be included and be omitted. Of course, then it is up to the page editor to pick a style. Infoboxes might need a standard. -DePiep (talk) 23:36, 20 September 2015 (UTC)
... but I missed the common but imperfect desire to write "x eV (y kJ/mol)". Worth discussing at WT:CHEMISTRY and WP:PHYSICS? (meanwhile preliminary options could be added). -DePiep (talk) 08:42, 21 September 2015 (UTC)
  • Opposed Reading through Flerovium, the instances where eV is used are accurate, as are the instances where kJ/mol are used. It makes no sense to talk about decay energy in anything except eV, and likewise decomposition in anything other than kJ/mol. Each unit has a specific usage, and unless it's being used incorrectly there is no reason to state them otherwise. It would be like converting a cup of flour in a recipe into mL; both units are used in cooking but only one makes sense to measure flour. Primefac (talk) 22:37, 21 September 2015 (UTC)
In physical chemistry it is very common to go back and forth between eV and kcal/mol, see for example this or any other similar google search. --Steve (talk) 23:00, 21 September 2015 (UTC)
Absolutely. It was seeing ionization energy given in eV that raised my eyebrows; while I can see why it makes sense if you are only dealing with one or two nuclei these are nearly always given in kJ/mol and it makes sense to be able to compare them with other elements. --John (talk) 06:02, 22 September 2015 (UTC)
  • Support kcal/mol, kJ/mol as straightforward energy quantities, convertible to any other type of energy (though in practice eV is most common). For example: "The molecule's ionization energy is 2eV (46 kcal/mol)". I just don't see how there's any problem or risk of confusion here. The "2eV" is obviously and unambiguously "2eV per molecule".
You almost never hear anyone refer to just energy, it's usually the energy of something (a molecule, a photon, a sandwich, whatever). If someone tells me that "the energy in this sandwich is 2 MJ", I would not respond "You have the units wrong, you should have said "the energy in this sandwich is 2 MJ per sandwich!" No, it is perfectly appropriate to treat "per sandwich" as implicit in the sentence and context, rather than part of the physical unit. Likewise, I think it is perfectly appropriate to treat "per particle" or "per molecule" or whatever as implicit in the sentence and context, rather than part of the physical unit. :-D --Steve (talk) 23:00, 21 September 2015 (UTC)

eV details[edit]

The suggestion to Google for "eV 4 kcal/mol" above makes a convincing case so I have put an experiment in Module:Convert/extra. That is a temporary area where units can be tried; if they are not used after a month or so they can be removed. I had to make a new unit that is compatible with kcal/mol and kJ/mol. The unit code is what is used in the convert template, and I picked eVpar to suggest electronvolts/particle. That is easily changed if wanted. Convert is not configured for scientific usage because most science articles use standard units and don't need conversions. At any rate, the new unit defaults to showing the unit name, and abbr=on is needed to make it show the symbol that is probably wanted. I made it accept metric prefixes—is that wanted? Please study the following examples and identify any problems:

  • {{convert|1|eV|J|sigfig=15|abbr=on}} → 1 eV (1.6021764870000×10−19 J)
  • {{convert|1|eV|kcal|sigfig=15|abbr=on}} → 1 eV (3.8292937069790×10−23 kcal)
  • {{convert|1|eVpar|sigfig=15}} → 1 electronvolt (96.485329522144 kJ/mol)
  • {{convert|2|eVpar}} → 2 electronvolts (190 kJ/mol)
  • {{convert|2|eVpar|abbr=on}} → 2 eV (190 kJ/mol)
  • {{convert|2|eVpar|abbr=off}} → 2 electronvolts (190 kilojoules per mole)
  • {{convert|2|eVpar|abbr=on|lk=on}} → 2 eV (190 kJ/mol)
  • {{convert|2|eVpar|abbr=off|lk=on}} → 2 electronvolts (190 kilojoules per mole)
  • {{convert|2|eVpar|kJ/mol|abbr=on}} → 2 eV (190 kJ/mol)
  • {{convert|2e6|ueVpar|abbr=on}} → 2×106 µeV (190 kJ/mol)
  • {{convert|2|keVpar|abbr=on}} → 2 keV (190,000 kJ/mol)
  • {{convert|2|MeVpar|e6kcal/mol|abbr=on}} → 2 MeV (46×10^6 kcal/mol)

The first two examples show the existing eV unit, and the rest are the new eVpar. The sigfig=15 examples are to show all the digits used in the calculation—I know that is not a plausible setting. The last example shows that what we call engineering notation can be used ("e6" as a prefix for kcal/mol). However, it's not true scientific notation.

Looking at this unit shows a problem. The current eV unit is defined so that 1 eV = 1.602176487e-19 J. But that value seems to be wrong? Where would it have come from? Has some unit definition changed? Electronvolt says 1 eV = 1.602176565e-19 J and Avogadro constant says there are 6.022140857e23 particles/mol. Multiplying the last two values gives 96485.329522144162 (yes, it's more sigfig than justified but computers have to be told something), and that is the scale I used for eVpar. Johnuniq (talk) 04:00, 22 September 2015 (UTC)

@GliderMaven: Any thoughts on the above? Why does convert (and lots of websites) use 1.602176487, but Electronvolt use 1.602176565 as the sigfigs for eV? Johnuniq (talk) 04:07, 22 September 2015 (UTC)

I've looked into it a bit, and looks completely fine. It's just a unit of energy. It's actually energy per unit charge, which dimensionally, which is all convert cares about, is just energy. I'm not sure why there would be minor differences in the value, perhaps somebody vandalised wikipedia or somebody redid a measurement in a standards body and it has officially changed, I'll look into it slightly more. But it's unlikely to make any practical difference, given the way convert rounds.GliderMaven (talk) 14:36, 22 September 2015 (UTC)
@Johnuniq: The Wikipedia "Electronvolt" article states the value, and refers to the Elementary charge article. The "Elementary charge" article does not contain the value directly, but obtains it from {{Physconst}}. The documentation for the Physconst template claims values are obtained from CODATA 2010 recommended values, which do not seem to agree with the value currently listed at the NIST website, which are 2014 CODATA recommended values. Jc3s5h (talk) 15:34, 22 September 2015 (UTC)
electronvolt says 1 eV = 1.602176565(35)e-19 C in the lede, uncited. this source, which claims to be based on CODATA 2006 (which is cited but only for the name, not the value) says 1.602176487(40)e-19 C, which is the number the convert template uses. Those values differ by about 2 sigma, so not a huge issue (and consistent with an updated measurement). For the convert template, I wouldn't worry about a disagreement at that level; for purposes where that many significant figures matter, editors should be checking numbers explicitly anyway. —Alex (Ashill | talk | contribs) 16:34, 22 September 2015 (UTC)
As a minor note, the {{physconst}} value for eV has been updated to the 2014 numbers, and I'll update the rest of the numbers in the near future. Thanks for bringing it up Jc3s5h. Primefac (talk) 21:24, 22 September 2015 (UTC)
  • I object to the construct name eVpar. At least it should be

eVperpar or eV/par. The wp editor who actually uses this shortcut, should know this. -DePiep (talk) 22:29, 24 September 2015 (UTC)

  • Thank you, Johnuniq, that seems to work and I have added it to Flerovium. One quibble: I think the default conversion should be to kJ/mol rather than kcal/mol, as per WP:UNIT. --John (talk) 01:04, 26 September 2015 (UTC)
    • @John: OK, that's done. What do you think about the unit code? The examples above use "eVpar". Should that be eV/par or something else? Johnuniq (talk) 03:22, 26 September 2015 (UTC)
      • I think eVpar is fine. It looks good. Thanks for your quick and diligent work on this. --John (talk) 00:35, 27 September 2015 (UTC)

Documentation: Unified nomenclature[edit]

Carrying on from this and this above:

Apologies for the long post. Since my last post here, I have been thinking hard about these docs and examples etc., and I find that many of my ideas/worries/thoughts have been simultaneously expressed here by others; so it appears I'm not alone. NB I am not a mathematician/scientist/expert at markup or coding in any way.

It seems to me that a number of problems arise from the somewhat vague and inconsistently-applied terminology to describe the various unnamed/named parameters/options etc., such as terms like abbreviation, left-hand side, the word 'unit' used by itself, 'output value', 'round number' etc. I believe that all these similar equivalent terms can be dispensed with by the adoption of single, unambiguous terms which should be used consistently and meaningfully throughout the template (eg 'Input/output options' to describe 'un-/named parameters', etc.

Samples of current equivalent nomenclature
  • input value = value to be converted
  • unit-code for the unit to be converted from    = left-hand side = input parameter = 2nd unnamed parameter
  • unit-code(s) for the unit(s) to be converted to = right-hand side = output parameter(s) = 3rd, 4th etc. unnamed parameter
  • 3rd-6th 'input unit-codes' = units etc
  • 'unit name' (column 2) = full name = unit =
  • 'unit-symbol' (column 4) = abbreviation = symbol
  • rounding-value = last named parameter = round value

Here are some of the same offenders, from a slightly different angle:

  • Input options or "Unnamed parameters" - mostly input
    • Conversion-value /Value for conversion / Number to be converted / 'input value'
      • Rounding generally
      • Fractions - using fractions both in input values ('conversion-value') and the output (named parameter/option) |frac=
    • 'Range separator' / identifier, for converting two 'input-values': 3 x/by/to 4 feet, etc.
    • Input-codes ("2nd & 3rd unnamed parameters") / 'input unit-code' and 'output unit-code' / left/right -hand side / unit to be converted from/to
    • 'Rounding-value' / 'last unnamed parameter' / 'round value' / 'precision' - are |sigfig= and |round= named or unnamed parameters?
  • Output options or "Named parameters" - mostly output
    • |abbr=| adj= |comma= |debug= |disp= |frac= |lk= |order= (possibly not |round= |sigfig= if they are input options?) |sortable= |sp=us |spell= ( what exactly is meant by 'input number' in any context - it may be obvious to some, but it's confusing for a non-scientist/mathematician. Some terms are mutually exclusive, but it's often to see which ones, and why. Each option should be treated in exactly the same way, with the same terms and layout, like any decent printed manual for OS commands or applications.
  1. How about agreeing on a list of unique 'master terms' to describe most things in C/doc, for use by anyone who uses and/or maintains the Convert template and documentation (with a list of equivalent terms which will eventually all be replaced by the 'master term')
  2. Agree on a general format for all the documentation - I think it's fairly evident that something needs doing.
  3. Then, how about attempting to create a 'proper' manual in the manner of a Unix man page, or other OS (even MS-DOS...), in which the master terms are used consistently to describe each aspect of using (and maintaining) the template.

<aside> As someone who hasn't studied any science or maths subject academically since age 16, I find the concept of 'decimal places' relatively easy to understand, and 'significant places' somewhat daunting. </aside>

I think that a wide range of well-chosen examples is very important; I agree that a flowing, consistent prose style is very useful: but there are so many possible combinations that examples can be more helpful than prose.

Proposed manual

  • Intro
  • Terminology - defining the unique terms to be used consistently and passim in the documentation
  • Basic operation for first-timers/non-mathematicians/etc., including rounding etc.
  • Detailed, consistent, uniform sections like man pages etc.
    • input options (for calculation)
    • output options (for tweaking/customising the displayed output/result)
      • (could incorporate improved general layout of Template data table)
      • list of all default/silent options/parameters used by {{convert}} for a simple {{convert|1|kg}} (eg |disp=b, max. number of digits in 'number to be converted'/'conversion-value', etc.
  • Trouble-shooting

I have started a page User:MinorProphet/Draft subpages/man convert laying out and addressing some ideas for a manual, although I haven't got very far. It's not at all polished and may not be helpful, although I have learned a whole load just from constructing what is there so far. MinorProphet (talk) 11:04, 22 September 2015 (UTC)

I don't have time to digest this at the moment, but did you see #Documentation details above? In particular, what do you think of my edit? The edit does not address many of the points above, but I'm wondering if you think it was a step in the right or the wrong direction. I agree that terminology should be consistent, but I think the documentation should mainly be a list of examples, with minimal explanation and I cannot imagine any part of a man page that would be helpful here. Johnuniq (talk) 12:00, 22 September 2015 (UTC)
Man page#Layout applies, whereas man page#Manual sections doesn't. — CpiralCpiral 17:28, 24 September 2015 (UTC)
Convert is great for the MoS, for it's active and responsive talk page, and for its interesting units forum. It should be easy to satisfy these three with one terminology for the newcomers and entrenched alike. How Convert seems to newcomers is invaluable information.
Wikipedia is great for collaboration, but here's how it seems to me to work: single editor creates a draft. Then other editors modify it. When two or more editors try to work at the same time, I've yet to see that work efficiently, as much as I would like to try. — CpiralCpiral 17:28, 24 September 2015 (UTC)

U.S. survey foot and mile[edit]

I believe the U.S. statute foot (1200/3937 meter) and the U.S. statute mile (6336/3937 kilometers) should be added to the units of length. The United States National Geodetic Survey and United States Geologic Survey use these units for legal purposes. While the difference between these units and the International foot and the International mile is only 0.0002%, there inclusion would help to clarify the source of U.S. measurements. Yours aye,  Buaidh  20:16, 23 September 2015 (UTC)

I think it would be rare for lengths to be shown to sufficient precision for it to make any difference whether the conversion factors for the international or survey versions of these units were used. In those rare cases, I think the difference would have to be explained in the text; using a template would not be sufficient. I don't see the need for the convert template to cover every conceivable rare situation. Jc3s5h (talk) 20:59, 23 September 2015 (UTC)
I agree with Jc3s5h: it is not likely that a template can help with the confusion surrounding the different versions of mile that once were in use, or which are used now. The difference is too subtle for a mere conversion—if there were a difference, the article text would have to add a suitable explanation. However, convert has grown over the years and units smi (statute mile) and rtmi (route mile) are defined, although each has exactly the same scale as mi (a plain mile), namely 1 mi = 1 smi = 1 rtmi = 1609.344 m. I guess that is a UK definition. A US statute mile is approximately 1609.347218694 m. There is no statute foot in convert, and we would need to see examples in two or three articles of where convert would be useful before a new unit is defined. Johnuniq (talk) 02:35, 24 September 2015 (UTC)
In the US, the National Institute of Standards and Technology uses (on page C-2) the term "statute mile" to describe a mile consisting of 5280 US survey feet. Other sources disagree; for example the American Practical Navigator modifies "mile" with either "statute" or "nautical" and does not make any distinction between US survey and international miles. So the term "statute mile" does not have a precise definition. The term "statute foot" does not exist. Also, since the US survey foot is only used in surveying and related fields, clearly commonly used derived units used in surveying also exist. I believe the US survey square foot, rod and acre exist. Since surveyors do not use then, I doubt the existence of a US survey inch, yard, mile, square inch, square yard, or square mile. Jc3s5h (talk) 12:36, 24 September 2015 (UTC)

Some confusion arose when the USGS announced on September 2, 2015, that the new elevation measurement for the summit of Denali was 20310 U.S. statute feet.  Buaidh  14:16, 24 September 2015 (UTC)

I do not accept Buaidh's assertion. The word "statute" is not present in our "Denali" article nor is it present in the USGS press release which the Wikipedia article cites to support the elevation claim. Jc3s5h (talk) 14:29, 24 September 2015 (UTC)

Sorry I used the term U.S. statute foot in lieu of the more modern U.S. survey foot. They are identical in value. I am old.

Please see my private e-mail conversation with Dr. Childers of the NGS quoted at Talk:Denali#Precise metric elevation. All NGS and USGS elevations and distances are now calculated first in meters and kilometers and then converted to U.S. survey feet and U.S. survey miles. I am asking that the definition of the U.S. survey mile (smi) be updated to equal 6336/3937 kilometers and that a U.S. survey foot (sft) be added equal to 1200/3937 meter. Yours aye,  Buaidh  16:28, 24 September 2015 (UTC)

I object to the terms "statute foot"; I do not believe there is any such thing. I do not believe any well-edited reliable source has ever used the term. Also, one could infer that a U.S. survey mile must be 5280 U.S. survey feet, but surveyors don't use any kind of miles for precise work (sure, they might use them when giving road directions to a geodetic mark, e.g. "Drive 2.3 miles from the post office in East Bumpkin to the mark on the left" but not for precise stuff) so I'm not convinced the U.S. survey mile exists either. Jc3s5h (talk) 16:55, 24 September 2015 (UTC)
I question the need to support the US survey foot. I object to the presence of smi as a supported symbol. It is currently described as "statute mile". Because of conflicting uses in various parts of the world, and even by different agencies of the US government, I consider the term "statute mile" to be hopelessly ambiguous and the use of the term should be strongly discouraged in Wikipedia, starting by deleting it from this template. Jc3s5h (talk) 17:07, 24 September 2015 (UTC)

Please see the Measurement, Instrumentation, and Sensors Handbook for one. Yours aye,  Buaidh  17:04, 24 September 2015 (UTC)

Since the NGS and USGS use meters, kilometers, U.S. survey feet, and U.S. survey miles exclusively, I think all four of these units bear inclusion. Yours aye,  Buaidh  17:15, 24 September 2015 (UTC)

NGS and USGS, as far as I know, do not use U.S. survey miles at all, or at least, they use miles for imprecise measurements where you can't tell which kind of mile they are using. I don't know the USGS policy on what kind of feet they use, but the NGS provides data converted from meters into either US survey feet or international feet, depending on which kind of foot an individual state requests (or they just provide meters if a state makes no request). See their FAQ, search on "What & Why". Jc3s5h (talk) 18:11, 24 September 2015 (UTC)

Your reference above states:

For most of the years surveying has been undertaken in the United States, surveyors have used the U.S. Survey Foot.


The only other instance where NGS publishes linear values in feet is for elevations, i.e., orthometric heights. All computations are still done in meters, but for publication purposes we convert meters to feet. That conversion is done using the U.S. Survey Foot conversion factor. We publish elevations in meters to the nearest millimeter (3 decimal places) and in feet to hundredths of a foot (2 decimal places). For elevations above 5,000 feet (1,524 meters), the conversion factor will change the foot value by one in the second place.

Please see the NGS Pikes Peak Datasheet for an example.

Most published USGS topographic maps show elevations in U.S. Survey Feet based on the National Geodetic Vertical Datum of 1929 (NGVD 29). To convert these elevations to SI meters based on the North American Vertical Datum of 1988 (NAVD 88), you must first multiply by 1200/3937 to convert to meters based on NGVD 29 and then add the NGVD 29 to NAVD 88 conversion factor from VERTCON. This conversion may alter elevations by as much as 2.4 meters. For example, the USGS topographic map for Pikes Peak indicates an elevation of 14,110 U.S. Survey Feet based on NGVD 29, 1.57 meters less than the NAVD 88 value. We typically input U.S. NAVD 88 elevations in meters to the nearest millimeter to reduce rounding errors. See Template:Epi and the List of mountain peaks of North America for examples.

While millimeter accuracy is not required for elevation display values, its use reduces rounding errors. This recently became an issue when the USGS issued a report stating that the elevation of Denali was 20,310 feet. The report did not indicate whether this value was in U.S. survey feet or International feet. An elevation of 20,310 U.S. survey feet rounds to 6191 meters, while 20,310 International feet rounds to 6190 meters. I asked Dr. Childers of the NGS for more information and she replied that the actual elevation measurement was 6190.5 meters, so we increased the Denali elevation display accuracy to 0.1 meters and 0.1 feet.

While the U.S. Survey Foot and U.S. Survey Mile are interesting from a historical perspective, we avoid publishing any values in these units and instead display International feet and International miles. Our primary use of the U.S. Survey Foot is for converting published U.S. elevations in U.S. Survey Feet to meters and International feet based on NAVD 88. We need to be able to explain to users (and elevation editors) why the Wikipedia elevations usually do not match the published USGS elevations. Thanks for your input. Yours aye,  Buaidh  21:39, 24 September 2015 (UTC)

Protected edit request on 25 September 2015[edit]

Please change the value of the U.S. survey foot (sft) to 1200/3937 meter (m) and update documentation. This is the correct value. Please see the discussion above.

 Buaidh  20:08, 25 September 2015 (UTC)

Please add the U.S. survey foot (sft) (1200/3937 meter) to the length units and update all documentation. Please see the discussion above.  Buaidh  21:36, 25 September 2015 (UTC)

Oppose. There is no unit code sft, and there is no support for the US survey foot. Thus it is incorrect to describe this as changing a conversion factor to the correct value. Discussion above indicates considerable opposition to supporting the US survey foot. Jc3s5h (talk) 20:41, 25 September 2015 (UTC)
All elevations in the United States are expressed in U.S. survey feet. The 2 ppm difference between the U.S. survey foot and the International foot makes no appreciable difference in the foot values displayed on Wikipedia. The difference does sometimes make a difference in how elevations are rounded to meters. The inclusion of the U.S. survey foot may eliminate confusion.  Buaidh  21:22, 26 September 2015 (UTC)
Red information icon with gradient background.svg Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Painius  06:32, 27 September 2015 (UTC)

No problem. WikiProject Mountains will just stop using Template:Convert for U.S. elevations. Yours aye,  Buaidh  18:43, 27 September 2015 (UTC)

I see no reason for WikiProject Mountains to abandon the template. Most precise elevations stated by a reliable source in US survey feet would come from the National Geodetic Survey. Ordinarily they provide meters as their primary unit, with US survey feet as a convenience for some readers. So using Mount Elbert as an example, rather than using {{convert|14440|ft|m|0|adj=on}} (which renders as 14,440-foot (4,401 m)), use {{convert|4401.2|m|ft|0|adj=on|order=flip}} which renders as 14,440-foot (4,401.2 m). Jc3s5h (talk) 15:22, 28 September 2015 (UTC)
That is what we do for U.S. summits that have an NGS datasheet. However, most U.S. summits do not have an NGS datasheet. The elevation for these summits must be converted from U.S. survey feet to meters and then from NGVD 29 to NAVD 88. We currently do this manually. Yours aye,  Buaidh  16:02, 28 September 2015 (UTC)
If you have to convert from NGVD 29 to NAVD 88, that for sure isn't going into the convert template, so I still see no need for the convert template to support US survey feet. Jc3s5h (talk) 16:45, 28 September 2015 (UTC)

Protected edit request on 25 September 2015[edit]

Please update the U.S. survey mile (smi) to its correct value of 6336000/3937 meters (m) and update all documentation. Please see the discussion above.  Buaidh  21:41, 25 September 2015 (UTC)

Please do not pad out this page unnecessarily. Things here are done slowly and by agreement. Before considering a proposal for a new unit, it is necessary to examine how it would be used. Please provide links to at least two articles and indicate which text would benefit from a conversion. If the examples show a trend—in other words, if it is likely the unit would be needed elsewhere—we can discuss the details of adding it, such as the unit code to identify the unit. Johnuniq (talk) 23:16, 25 September 2015 (UTC)
This is merely a request for the correction of an existing unit. Yours aye,  Buaidh  16:40, 26 September 2015 (UTC)
Red question icon with gradient background.svg Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. The data presents as follows:
    ["smi"] = {
        name1    = "statute mile",
        symbol   = "mi",
        utype    = "length",
        scale    = 1609.344,
        default  = "km",
        subdivs  = { ["chain"] = { 80, default = "km" } },
The abbreviation "smi" appears to refer to "statute mile", not to US "survey mile". Please be more explicit in your request. Painius  06:51, 27 September 2015 (UTC)
  • Requests to change units need examination and consensus. The discussions earlier on this page show there is no consensus for a change. I referred to "new unit" above because changing the definition of smi effectively changes it to a new unit since there is no evidence that the current definition is wrong. I do not recall any units needing a fundamental correction like this. An explanation of "statute mile" as defined in convert is here. See mile#name for information about the UK/US difference. Johnuniq (talk) 07:31, 27 September 2015 (UTC)
  • I believe there is clear evidence that "statute mile" can either be 1609.347219 m (accurate to 10 significant figures) or 1609.344 m exactly, depending on which definition one prefers, the definition used by the National Institute of Standards and Technology or the definition used by the rest of the world. In view of the conflicting definitions, I suggest the unit should be eliminated entirely. Jc3s5h (talk) 13:19, 27 September 2015 (UTC)

I believe we should either correct this unit or eliminate it. If U.S. survey foot is not included, there is no need for U.S. survey mile. Yours aye,  Buaidh  18:39, 27 September 2015 (UTC)

I forget if I asked for examples for survey foot/mile; I have done that for several other recently proposed new units. At any rate, let's start again. Please link to sections on at least two articles where a change to how convert operates would be useful. What would convert do differently that would affect the articles? I agree that "statute mile" is a poorly defined term in an encyclopedia with worldwide scope, but smi is used in many articles; we would need to investigate what they do before thinking about a change to smi. Johnuniq (talk) 01:55, 28 September 2015 (UTC)


Why can't the Lua module handle proper unicode fraction symbols like ½ ? Using -1⁄2 is odd. John Vandenberg (chat) 13:44, 3 October 2015 (UTC)

I'm not involved in the coding of templates, but my guess would be that an article that contains one fraction is likely to contain others. Unicode fractions are only available for a few possible fractions. An article that contains 12 is likely to also contain 716 or other fractions for which no Unicode is available. It would both complicate the programming, and provide inconsistent appearance in the article, to use different approaches depending on whether a Unicode character happened to be available for a particular fraction. Jc3s5h (talk) 15:31, 3 October 2015 (UTC)
Well I ask because I was working on Phineas Gage (most are {{Convert}}ed, but some are pending discussion here or on the talk page), which only uses fractions that can be expressed using unicode's provided vulgar fractions. I very strongly suspect there is a very large cohort of similar articles that would be able to use only unicode provided symbols, as it contains the most commonly fractions used in normal situations, as 1/8 is about as much accuracy as a person typically would need to describe something sufficiently accurately for historical records using equipment they have and can competently wield. It is these historical topics which would benefit from supporting the simple unicode fractions.
Of course you are right Jc3s5h, for articles where present-day accurate technical descriptions are needed, greater precision is appropriate, and appropriate equipment was used correctly to obtain said greater precision. 716 isnt easily expressed using unicode symbols, except by using the magic numerator to advantage, such as ⅜+⅟16 or ½-⅟16 , but using calculation symbols like that suffers the same legibility problem as it means the source code is subtly different from the rendered text (which for example means 'copy & page text search' fails). John Vandenberg (chat) 21:36, 3 October 2015 (UTC)
MOS:FRAC says to not use special characters such as ½. Convert allows a fraction in the input and/or output, see Help:Convert#Fractions. Examples:
  • {{convert|2+1/2|in|mm}}2 12 inches (64 mm)
  • {{convert|3+7/8|in|mm}}3 78 inches (98 mm)
  • {{convert|48|mm|in|frac=8}} → 48 millimetres (1 78 in)
  • {{convert|44|mm|in|frac=8}} → 44 millimetres (1 34 in) (frac=4 or frac=8 give the same result here)
  • {{convert|70|mm|in|frac=128}} → 70 millimetres (2 97128 in)
Does this cover what is wanted? Johnuniq (talk) 00:59, 4 October 2015 (UTC)
Hi John, I wouldnt want to contradict MOS:FRAC with regards to what is output, but I can see a small usability gain in allowing 2½ as an input. I'd be happy to try implementing that, but only if there was a general feeling it was appropriate. John Vandenberg (chat) 04:42, 5 October 2015 (UTC)
The input code is monstrous already, although it would be pretty easy to special case a half with text = text:gsub('½', '+1/2') but in general I don't think that offering multiple ways of doing things is always desirable because too many options leads to confusion with people wondering why 2½ works but 2¼ doesn't. There are around 3000 converts in articles with input numbers using "1/2" (half), and another 3000 using other fractions like 1/4 or 3/8, and it's probably better that people get used to the fact they have to enter fractions like that. Johnuniq (talk) 05:27, 5 October 2015 (UTC)

One vs A and An[edit]



one ounce (28 g)

I believe it should be possible to use 'an ounce' rather than 'one ounce'. Is there some hidden option for that?! John Vandenberg (chat) 14:16, 3 October 2015 (UTC)

No, sorry that's not possible. There are several quirky points about spelling numbers that made me give up when contemplating the issue. I can't recall what they are now, but Module:ConvertNumeric (which does the spelling) is able to handle "two and one half" or "two and a half" or "two and an eighth", although convert does not expose that option. The workaround is:
  • an ounce ({{convert|1|oz|g|disp=out}}) → an ounce (28 g)
Johnuniq (talk) 01:13, 4 October 2015 (UTC)
Thanks for saving me dig around in the code to find something that doesnt exist.
Would there be any reason why offering articles (i.e. an ounce) as an option would be bad for the user/reader/someone? (i.e. ignoring the complexity of implementing the beast) John Vandenberg (chat) 04:48, 5 October 2015 (UTC)
There are two aspects: (1) what reasonable syntax could be used?; (2) how often would it be used [is the effort/complexity worthwhile]? It was (2) that persuadaed me to not worry about it when implementing spelling. I might search my notes sometime and see if I left any clues about what options might also be wanted—I vaguely recall there being a few corner cases, particularly for UK/US differences, where people might not be happy with how numbers are spelled. There are about 2300 converts in articles which spell a number, and 150 of those involve fractions, and when I looked at some samples of usage I think I decided the way it was done was ok. That would need more thought because I haven't looked at spelling for two years. It is true that "an ounce" would be better in some cases, but the workaround exists. Johnuniq (talk) 05:52, 5 October 2015 (UTC)

An option to suppress conversion[edit]

When user's preferred system is Si, multiple imperial equivalents, automatically inserted by conversion, clutter majority of the articles, really ruining their readability. I suspect it is the same for the users accustomed to imperial units. It would be perfect if user could make wikipedia display all measurements, presented through conversion templates, in only one, preferred, system. I've been searching through the wikipedia user settings for related options and through the wikimedia RFCs for their discussions, but found only discussion of the preferred order here and old/abandoned discussion of "Auto unit conversion" which, as I understand, is different template and, even if finished, won't affect the behavior of Convert templates. Does anything like this already exist? Right now it seems to me it does not and I'm considering creating an RFC at mediawiki project, but feature seems so obvious that I wanted to double-check for the case I missed it. Thanks Darkdiatel (talk) 10:13, 5 October 2015 (UTC)

I can't recall anything precise, but there have been occasional suggestions that an editor should be able to specify a preferred method of spelling (most commonly, UK/US for colour/color), or preferred method of dates (1 April 2015 or April 1, 2015 or 2015/04/01, and so on), or preferred system of units, and that articles would then be displayed accordingly. Apart from the complexity of how such a system would work, there is the issue that readers see a cached copy of pages because it takes a significant amount of computer effort and time to translate from the wikitext used on a page to the HTML required by the user's browser. The caching system would be much more difficult if people could request different versions. At any rate, I don't think the idea has ever got anywhere. There was a very early attempt to automatically convert between units (with, for example, both miles and km being displayed for a distance specified only in miles or only in km), but it also got nowhere when the complexity of the project was considered. Johnuniq (talk) 10:54, 5 October 2015 (UTC)
Since date format is largely a US vs. rest of the English-speaking world, like SI, I think a proposal to change units based on reader preference will be met with outright hostility. One of the reasons this capability was opposed was that only logged-in users could express a preference, and logged-in users are mostly editors. Thus, editors were seeing something different than most readers, so were not motivated to make articles look right for the majority of readers. These are some of the discussions on the issue:
Jc3s5h (talk) 12:57, 5 October 2015 (UTC)
thanks a lot for both replies, you brought the aspects I wasn't aware of.
There're several ways to solve it without altering page content, to satisfy caching constraints:
1) output inline javascript that displays either version based on preferences, e.g:
Fossils of very large dragonfly ancestors ... these had wingspans of up to about <script>document.write((userPrefs.system == 'si')?'750 mm':'30 in');</script>
2) output several versions one after another, wrapped in inline elements with measurement system specified in an attribute of each, e.g.:
... these had wingspans of up to about <span msystem='si'>750 mm</span><span msystem='imperial'>30 in</span><span msystem='si(imperial)'>750 mm (30 in)</span>
and have single CSS of user preferences for entire wikipedia, which would make only one of those three visible
Yes, most readers are not registered. And I dislike the idea of such basic option requiring a site-specific account setting. In ideal future preferred measurement system would be detected from the respective http header. For now, using cookies could be a solution. The very last minimalistic resort, that requires nearly 0 development efforts, is to at least format output similar to:
750 mm<span class='imperial-equivalent'> (30 in)</span>
30 in<span class='si-equivalent'> (750 mm)</span>
and let geeks suppress it with custom CSS / grease-/tampermonkey etc.
Date issue, I believe, is not as severe. Yes, it must be a pain when you are focused on specific dates. But the issue with alternate version of the measurement is that you get extra unneeded information all the time, and this is distracting.Darkdiatel (talk) 16:24, 5 October 2015 (UTC)
Custom CSS maybe- has Visual Editor got anything under their sleeve? But I don't see much of a problem being delivered a full page and then refreshing to clear the cache to get a newly regenerated page with options. The spelling issue is more pertinent- particularly page name, some artificial fibres have the word fibre in their name- indeed the fibre page- this desperately needs a {{convert|fiber|fibre|EN-US|EN-Other}} template. -- Clem Rutter (talk) 17:58, 5 October 2015 (UTC)

Darkdiatel, a user preference would need to be added to the MediaWiki software or a MediaWiki extension, so that makes many parts of this suggestion largely beyond the scope of this template. However, this template could easily add some CSS classes which could allow WP:User CSS and WP:Gadgets to provide users with some level of control. We might even go further and implement parts of http://microformats.org/wiki/measure , which may also have some accessibility benefits. ;-) John Vandenberg (chat) 00:38, 6 October 2015 (UTC)