Template talk:Convert

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:ACONVERT)
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.

comma=gaps isn't working correctly[edit]

Thanks for adding the much anticipated |comma=gaps but it's not quite working properly. It puts gaps on the right but they're missing from the left of the decimal. So we've got, for example,

<span style="white-space: nowrap">12<span style="margin-left: 0.25em">345</span>.678901</span> metres (<span style="white-space: nowrap">40<span style="margin-left: 0.25em">504</span>.19587</span> ft)
12345.678901 metres (40504.19587 ft)

instead of

<span style="white-space: nowrap">12<span style="margin-left: 0.25em">345.678</span><span style="margin-left: 0.25em">901</span></span> metres (<span style="white-space: nowrap">40<span style="margin-left: 0.25em">504.195</span><span style="margin-left: 0.25em">87</span></span> ft)
12345.678901 metres (40504.19587 ft)

Jimp 13:28, 16 May 2015 (UTC)

Convert puts gaps on the left of the decimal mark but not on the right, as with commas. It's complex code, but I'll have a look. There is also comma=gaps5 which puts gaps (on the LHS) only if the LHS has 5 or more digits. I agree with what I think I have seen you make elsewhere, namely that if the RHS ends with a group of one digit, that digit should not be preceded with a gap. Using a comma to represent a gap, examples would be:
1,234.123,45 (comma=gaps)
1234.123,45 (comma=gaps5)
1,234.1234 (comma=gaps; no gap on RHS)
Is that right? I hope we won't need any more options. Johnuniq (talk) 02:43, 17 May 2015 (UTC)
Grouping digits is something which has recently been under discussion at WT:MOSNUM which resulted in a pretty thorough revision/clarification of WP:DIGITS. After a little toing and froing, the consensus reached was that a single digit to the right of the decimal point should not usually be preceded by a space but that this was not totally prohibited.

Right of the decimal point, usual practice is to have a final group of four instead of a lone digit (e.g.  99.1234567  or  99.1234567).

A case where you might want to break with usual practice might be where you have a table and would like to align digits in a column. Whether it be worth accommodating this in {{convert}} is another question (it may be easier to do the conversion and then use {{gaps}}).
As for the |comma=gaps5 option, WP:DIGITS doesn't currently allow for it. I don't believe that there ever was a consensus to allow it. I seems to me that it was just another of those formats that, through its former lack of clarity, a literal interpretation of WP:DIGITS seemed to allow (like 12,345,678.901234567890). So, rather than needing more options, perhaps we need fewer.
Jimp 09:36, 17 May 2015 (UTC)
Yep, I support what Jimp's saying here. The template needs to be updated to reflect WP:DIGITS. In particular:
  • Commas: "When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string)."
  • Thin spaces: "Digits are grouped both sides of the decimal point"; "Digits are generally grouped into threes ... In mathematics-oriented articles long strings may be grouped into fives ..."
sroc 💬 10:27, 17 May 2015 (UTC)
OK, no one wants commas on RHS—my above example used commas on both sides to easily show where a gap would go. When I look at the module (unlikely to be soon I'm afraid) I'll probably end up doing whatever is easier with regard to the trailing single digit, although I'm inclined to think Jimp's above example with a gap before "7" looks fine, and might give the most consistent results in a table. Looking at converts in all articles as at 3 April 2015 shows that only four of them use comma=gaps (no comma=gaps5) so it's not worth agonizing over the trailing single digit issue. Johnuniq (talk) 11:50, 17 May 2015 (UTC)
Indeed, mathematics-oriented articles are unlikely to use this template in this context, so the grouping by five digits wouldn't be needed. There should at least be an option allowing a final group of four digits on the RHS if it isn't too much trouble, and it should probably be the default; WP:DIGITS says it is the default when thin spaces are used (following discussion at Wikipedia talk:Manual of Style/Dates and numbers/Archive 151 § Grouping of digits §§ Discussion §§§ Four-digit grouping on the right). sroc 💬 12:44, 17 May 2015 (UTC)
(edit conflict) For the sake of clarity, I suggest the following proposed examples:
{{convert|12345.67891|m}}  → 12,345.67891 metres (40,504.1959 ft)
{{convert|12345.67891|m|comma=gaps}}  → 12345.67891 metres (40504.1959 ft)
{{convert|12345.67891|m|comma=gaps4}}  → 12345.67891 metres (40504.1959 ft)
sroc 💬 13:06, 17 May 2015 (UTC)
Perhaps the code at Module:Gapnum (used by {{val}}), which conforms to what MOSNUM specifies as usual practice (i.e.  99.1234567  rather than  99.1234567), might be useful. Jimp 13:01, 17 May 2015 (UTC)

I hope to update the sandbox with some new code in a couple of days. The options it currently supports are:

Option Result
(none) Group with commas, if there are 4 or more digits before the decimal point (dp).
comma=5 Group with commas, if there are 5 or more digits before the dp.
comma=gaps Use gaps to separate groups of digits before and after the dp.
comma=gaps5 comma=gaps + comma=5
comma=off No grouping.
  • The default is grouping with commas; grouping is only before the dp.
  • When gaps are requested, they occur before and after the dp. By default, if there is more than one digit after the dp, the last group will have 2, 3, or 4 digits (never 1).
  • If wanted, I could change comma=gaps5 to be the same as comma=gaps, and to give a deprecated warning (and remove it at some future time).
  • These options also apply if convert is used on other Wikipedias where grouping may be 3-then-2 (only before the dp), and where the digits/decimal mark/group separator may be translated.


  1. Should comma=gaps5 be deprecated (it appears to be unused)?
  2. Should comma=gaps default to not give a gap before a single digit (that's what the new code does)?
  3. What option should allow a gap before a single digit? Perhaps comma=gaps1?

Johnuniq (talk) 12:23, 27 May 2015 (UTC)

Pinging Jimp + sroc. Johnuniq (talk) 12:24, 27 May 2015 (UTC)


... Yes, that's right: here are the definitive answers ...
  1. I'd be inclined to get rid of comma=gaps5 (it seems to be a confusion of two different styles).
  2. Not giving a single digit after a space is described by MOSNUM as the "usual practice" & it's what {{val}} does, so I'd say that this should be the norm.
  3. I s'pose comma=gaps1 would work fine. How about comma=gaps-a (to emphasise that it might be useful for aligning digits in a table)?

Jimp 12:43, 27 May 2015 (UTC)

(edit conflict)
Question 4: With comma=gaps5, will the digits on the right still be grouped even if there are less than five digits left of the decimal point (e.g., 1234.56789)? Would this ever be appropriate? Perhaps it should be deprecated since this does not seem to be a valid option. So that's my answer to 1.
2. Yes, comma=gaps should default to having a final group of four digits after the decimal point (e.g., 0.1234567), as MOS:DIGITS calls this "usual practice".
3. What about comma=gaps3 to reflect that the groups are never more than three digits (e.g., 0.1234567)? This would also make sense if we ever decided to implement an alternative of comma=gaps5 as the grouping of five digits for mathematics topics (e.g., 1234567.890123456789) in the future.
sroc 💬 12:51, 27 May 2015 (UTC)
Thanks. We agree for Q1 to deprecate comma=gaps5, and for Q2 that gaps should default to no gap before a single digit. For Q3 we have suggestions: comma=gaps1, comma=gaps-a, comma=gaps3. I'll ponder that more, but at the moment I think sroc's rationale works best, and gaps3 describes the fact that the digits are grouped by 3 (or fewer if there aren't 3 digits). Johnuniq (talk) 11:36, 28 May 2015 (UTC)

I've finished the gaps code, and it's very nice even I say so myself! However, final testing revealed an issue. Very big or small outputs are shown in scientific notation, and it is possible to enter a number with e-notation. Convert does not bother inserting separators in such numbers because in the old system they should never be necessary since commas never appear after the decimal point, and the same for gaps in the existing version. Bearing in mind that comma=gaps is almost never used, I'm reluctant to spend much more time on this, but am posting in case anyone wants to express an opinion. Following are examples of the output from the new version using fixed wikitext (not yet uploaded to the module). The first line is good; the others not so.

  • {{convert|1234.56789|m|m|comma=gaps}}1234.56789 metres (1234.56789 m)
  • {{convert|1234567890|m|m|comma=gaps}}1234567890 metres (1.23456789×109 m)
  • {{convert|123456|nm|km|comma=gaps}}123456 nanometres (1.23456×10−7 km)
  • {{convert|1.23456e-6|m|m|comma=gaps}} → 1.23456×10−6 metres (1.23456×10−6 m)
  • {{convert|1.2345678e10|m|m|comma=gaps}} → 1.2345678×1010 metres (1.2345678×1010 m)

Johnuniq (talk) 08:08, 29 May 2015 (UTC)

Put it on the to-do list. It probably isn't the most urgent issue. Jimp 09:55, 29 May 2015 (UTC)
Is there an argument that gaps are unnecessary (and potentially confusing) in exponentials because they do not (necessarily) represent "thousands" separators? To borrow from the last example:
  • 1.2345678×1010 m = 12345678000
If gaps were included in the exponential figure, they would not appear in the same places as the integer and thus the gaps do not represent "thousands", "millions", etc.:
  • 1.2345678×1010 m = 12345678000
So maybe it's better to leave that "bug" as is? sroc 💬 17:29, 29 May 2015 (UTC)
I found a simple way to group digits when displaying scientific notation, so I have included it. I agree it looks a bit odd, but if people use comma=gaps, convert may as well insert gaps. Johnuniq (talk) 10:49, 1 June 2015 (UTC)
Just a note on the "Is there an argument that gaps are unnecessary [...] because they do not (necessarily) represent "thousands" separators", one may note that (a) the function of spaces is to aid the eye, not to mark "thousands" (b) in engineering notation they would correspond. —Quondum 13:22, 1 June 2015 (UTC)

I have uploaded a new version to the sandbox with what I hope is the final code for handling gaps.

  • comma=gaps5 (probably unused) is now equivalent to comma=gaps and is deprecated (previously, it was similar to comma=5 using gaps).
  • comma=gaps now inserts gaps before and after decimal mark; there is no gap before a trailing single digit (after the decimal mark).
  • comma=gaps3 is new; it is like comma=gaps, but if there are sufficient digits there are always three digits per group so there may be a gap before a trailing single digit.


  • {{convert/sandbox|1234.1234|m|ft|4|abbr=on|comma=gaps}}1234.1234 m (4048.9613 ft)
  • {{convert/sandbox|1234.1234|m|ft|4|abbr=on|comma=gaps3}}1234.1234 m (4048.9613 ft)
  • {{convert/sandbox|12345678.1234567|m|cm|abbr=on|comma=gaps}}12345678.1234567 m (1.2345678123456×109 cm)
  • {{convert/sandbox|12345678.12345678|m|cm|abbr=on|comma=gaps}}12345678.12345678 m (1.2345678123456×109 cm)
  • {{convert/sandbox|1234567890|m|m|comma=gaps}}1234567890 metres (1.23456789×109 m)
  • {{convert/sandbox|123456|nm|km|comma=gaps}}123456 nanometres (1.23456×10−7 km)
  • {{convert/sandbox|1.23456e-6|m|mm|comma=gaps}}1.23456×10−6 metres (1.23456×10−3 mm)

Johnuniq (talk) 10:49, 1 June 2015 (UTC)

Looks good! sroc 💬 11:51, 1 June 2015 (UTC)
Note: I have not followed this topic in any way. 'Till now, I have not adjusted {{template documentation}} and its subpages for this, so it might be outdated wrt gaps & commas. -DePiep (talk) 21:22, 13 June 2015 (UTC)

MOS ranges[edit]

Recent discussions (for example, 1 × 2 × 3 cm above) have concerned WP:UNIT which specifies that the unit should be repeated in a "times" range that uses ×. For historical reasons that currently occurs for 1x2 ranges, but not for 1x2x3 or higher. Another consideration is that 1x2 uses "by" when abbr=off and "×" when abbr=on. The following illustrates these issues, using fixed wikitext so the results won't change:

  • {{convert|1x2|m|cm}} → 1 by 2 metres (100 cm × 200 cm)
  • {{convert|1x2|m|cm|abbr=off}} → 1 by 2 metres (100 by 200 centimetres)
  • {{convert|1x2|m|cm|abbr=on}} → 1 m × 2 m (100 cm × 200 cm)
  • {{convert|1x2x3|m|cm|abbr=on}} → 1 × 2 × 3 m (100 × 200 × 300 cm)

Displaying "by" may not be expected above, but it's purpose is to use natural language when unit names are shown and is the way convert has worked for many years.

I've done far too much work on this in the last week, and have some new code which is not yet uploaded. The following illustrates some results (again using fixed wikitext) from the new code:

  • {{convert|1x2x3|m|cm|abbr=on}} → 1 m × 2 m × 3 m (100 cm × 200 cm × 300 cm)
  • {{convert|1|by(x)|2|m|cm}} → 1 by 2 metres (100 cm × 200 cm)
  • {{convert|1|by(x)|2|m|cm|abbr=on}} → 1 by 2 m (100 cm × 200 cm)
  • {{convert|1|by(x)|2|m|cm|order=flip}} → 100 by 200 centimetres (1 m × 2 m)

The new code gives the same results for the 1x2 cases shown above—it shows "by" when abbr=off. The new code supports a new method of defining "times" ranges and it would now be easy to make 1x2 always use "×". The new by(x) range is in anticipation of that change—it works like and(-) and to(-) in that by(x) always uses "by" on the left, and "×" on the right (the left side is normally the input, but is the output if order=flip is used). The behavior of 1x2 has not yet been changed because it occurs over 6,000 times in articles and I would prefer to have the new code running for a few weeks before considering whether to change 1x2. Apart from my hesitation about imposing such a significant change without wide discussion, it's good to check that new versions produce reasonable results in the converts used in articles, and the changes are already very complex, so I don't want to deal with checking what happens with 1x2 changes yet. The changed results are in my sandbox2 (permalink). Please have a look! One change I'm unsure about is in the "Thousand million billion trillion" section where the number words are repeated. That is a side effect of a fix to correct the currency/length bug shown in the previous section ("1–$2 per kilometer"). Johnuniq (talk) 08:06, 8 June 2015 (UTC)

I'm chewing on this (like 1 and 2). -DePiep (talk) 19:34, 10 June 2015 (UTC)
I am *very* charmed by the argument: it's purpose is to use natural language when unit names are shown (i.e. to write "1 by 2 metres" for the first value). Coming from my "It must be MOS and must be scientifically right", for me this opens a nice improvement into readability (still MOS and scientifically legal! ;-). (Five stomacs to go). -DePiep (talk) 19:31, 13 June 2015 (UTC)
Note 3/n. Johnuniq, your OP does not say so explicitly, but is the explicit aim that all dimensions (dimension: 1 x 2 = 2 dim; 1 x 2 x 3 = 3 dim) all will be treated the same, as in: "there will be one MOSCONVERT (lol) in this"? -DePiep (talk) 19:48, 28 June 2015 (UTC)
My plan is that 1x2 and 1x2x3 (and similar such as "1x2 to 3x4") would repeat the unit symbol when the unit is abbreviated so it will be MOS compliant. I finished the code for that a couple of weeks ago but off-wiki events have interfered with final testing. The sandbox2 links above give more examples, however I decided that the simplified code which repeated numbers such as in "3 million to 8 million US gallons" was ugly, so I added a little more with the result "3 to 8 million US gallons" as currently occurs. I should get the code uploaded to the sandbox with a summary soonish. Johnuniq (talk) 02:23, 29 June 2015 (UTC)
OK, your answer is fine. (I'm reading your intentions, not the sandbox & code issues). -DePiep (talk) 21:31, 30 June 2015 (UTC)
Note 4/n. So the principle is: Per output value (that's those two per convert, basically) 1: determine whether the unit is shown as name or as symbol, whatever the reason. 2: the "by" or "x" follows this outcome, whatever the input in this. (In other words: an editor entering "x" while the unit must show the unit name for whatever reason, {{Convert}} turns that "x" into "by" format. Unit name says so! -DePiep (talk) 23:04, 2 July 2015 (UTC)


To ease talkpage communication, I'd like to strive to a clear simple set of wordings we use here. One gets tired of explaining "Input, unless order=flip is used because then ...". I start from SI, the BIPM site and their brochure.

Quantity and its value

What we measure is a quantity like length or area. What we write down is a value.

The speed is: 100 km/h; the area is: 1 sq mi

"100 km/h" is the value, "1 sq mi" is the value. We can perfectly write down two values: The speed is: 100 km/h or 62 mph.

Value = number × unit

A value like "100 km/h" is composed of a number and a unit. Actually, we can legally write:

value = number × unit. It's pure maths. This is not limited to SI.

Sometimes the notation differs, but not the principle: "Cost = $25" (reads like: 'Cost = 25 × $'. See, that's a value too).


The number may be an expression: "1 × 2" or "7 14" or 7 × 104. The numbewr can be spelled out: "Ten miles".


Clearly the unit can be composed from more basic units. A unit may be written by unit name(s) or by unit symbol(s) (in this template called 'abbr').

{{Convert}} additions

The template adds extra formatting issues. In a simple form:

{{convert|10|km|mi}} → 10 kilometres (6.2 mi)

It shows two values (!). The input value is mentioned first, the outcome value is second.

{Convert} input, output, result

By talkpage habit, with {{Convert}} output refers to the calculated value from the input value, not the visible, formatted total result (it's the calculation output, not the template output). For now, I use result for the full template result as is shown.

{{convert|10|km|mi}} → 10 kilometres (6.2 mi)
{Convert} separator

With {{Convert}} the values are always separated by brackets or otherwise. The separator (e.g. bracket set) is not part of a value!

{{convert|10|km|mi}} → 10 kilometres (6.2 mi)
{{convert|10|km|mi nmi}} → 10 kilometres (6.2 mi; 5.4 nmi)
{Convert} result, first and second

When we flip the order of input/output values, their resulting position changes, but not first and second (third, ...) value position in the result. First = first always.

{{convert|10|km|mi nmi}} → 10 kilometres (6.2 mi; 5.4 nmi)
{{convert|10|km|mi nmi|order=flip}} → 6.2 miles; 5.4 nautical miles (10 km)
More details

For now I'll skip some details, like prefixes ('mili'), SI base units, derived units, special unit names like Newton, and dimension.

To quote the SI Brochure: "The value of a quantity is generally expressed as the product of a number and a unit." -DePiep (talk) 18:42, 9 June 2015 (UTC)

Thanks, and please remind me if I misuse terms, but converting me to "value = number + unit" will be difficult. A standards body has to use language to suit their purpose and they define terms accordingly, but I'm used to value (computer science) and value (mathematics). Johnuniq (talk) 03:38, 10 June 2015 (UTC)
Times, not plus: "value = number × unit".
  • TL;DR shortcut: Johnuniq, how else would you name that 'textual unit' like "10 km" in {Convert}'s result?
  • Background: SI notes that it is an algebraic equation (the unit may be read as 'one u' if that helps). See the dollar example: cost = $25 is a value too (non-SI format, but just as algebraic and very familiar as a value). Another illustration, from SI: by being algebra one can write equally correct: value/unit = number. This may be used in a vertical scale of a graph: "Temperature/°C".
  • We deerly need a word for that textual unit, ouch (the things we flip around, we separate, we want to point to, that outcome of a calculation). Exactly like we need easy words for {Convert}'s result, first [value], second [value], ... (vs existing: input, output), and separator for all added punctuation (btw I know you did not oppose these, just drawing a parallel). It does not change anything wrt {Convert}, except easy & clarity in talkpage addressing.
  • You mention two concepts of value (note that SI thoroughly defines the value as maths #2 definition, so it's in there already), why not three or four? In physics, where most of {Convert}'s are about, it is treated as a value too. Can you agree this is a value? What about costs: value = $25? Not in your set of two but really produced by {Convert} and a very common and intuitive usage of 'value'. Your two definitions do limit you too much, I hope you can convince yourself. Or do you have an alternative word? (I used to write 'measurement' for this SI-defined value, but that is less correct).
  • A question forward would be: how do you or would you name that 'textual unit' in {Convert}'s result? -DePiep (talk) 09:06, 10 June 2015 (UTC). Added the opening TL;DR shortcut question. -DePiep (talk) 19:10, 10 June 2015 (UTC)
note: what I name separating here is called join earlier (eg the basic brackets). -DePiep (talk) 21:21, 10 June 2015 (UTC)
  • To build completeness, some additions:
WP:UNIT (a MOS) writes: "primary unit", displayed first, followed by a conversion in parentheses. i.e., primary for first (OK). However, "primary unit" is used to mean "primary value" (this MOS does not use any word for 'value' ...).
Useful unit specifiers: "products", "ratios" (per, /), "mixed units" (ft in or h m s).
SI uses "derived units" for the product of base units, (possibly powered). (Deeper: "coherent units" (Jimp used for the sort application!), "Units with special names"). -DePiep (talk) 10:30, 13 June 2015 (UTC)
By SI, a derived unit like km/h or m2 is a unit (singular), not units. -DePiep (talk) 10:32, 13 June 2015 (UTC)

Link more automatic per units[edit]

What are the reasons for the hesitation in adding more links to the /doc#Automatic per units conversion data? Is it because, for expressions like "erg/s" it is better to link erg than power? I ask the same of pressure, gradient, speed and others in that table.

At {{val}} when the unit code has a per unit, one link is preferred over two links because there users have four parameters to control "unit", "per unit", "link" or "not link". For Val it's just as easy to link |ul=erg/s to Power as the rule, as it is to link |ul=erg|up=s for the exception when erg is the context and "seconds" are not the context, and so seconds are not WP:overlinked.

I would like Automatic per units to link as frequently as possible, if only from the perspective that users who want individual links can use Val's |ul= and |upl=. But more to the point here, it is the whole unit that is converted, scaled, typed, and, I should think, linked as a general rule. — CpiralCpiral 21:16, 10 June 2015 (UTC)

{{val}} does some things very very good, but it's not a MOS. What do you ask about, can you give examples? We just discovered that {Convert} finds its way out of a weird unit, not pre-defined, like L/d (see Template_talk:Convert#Million_litres_per_day). -DePiep (talk) 00:04, 11 June 2015 (UTC)
For example, I want to put Power in the 3rd column of "/doc#Automatic per units", so we'll get a blue slash for erg/s like we do with m/s2 (because "Acceleration" is in the 3rd column already). Why not make as many as possible blue slashes? After all, what is converted includes that slash. I mean, it is not "erg" or "s" that is converted, rather Power is converted: {{convert|1|erg/s|disp=or|abbr=on|lk=on}}→1 erg/s or 6.0 µJ/min. — CpiralCpiral 03:15, 11 June 2015 (UTC)
Not my home turf any more. Can't reply. -DePiep (talk) 03:33, 11 June 2015 (UTC)
There are too many things happening in RL for me to be sure of anything, but my recollection is that there are existing units which link to Acceleration and Density (presumably because those articles are helpful as unit links), so it made sense to link equivalents to those articles. The idea of automatic per units arose because of a request which involved defining some Power density units, and that is the reason power/volume has that link, despite no other units using it. I can't think of any reason to not define links for other automatic per units, if an article is available that would be more helpful than linking the individual units. Is the proposal to add the following so these automatic per units have the indicated links?
When I have some time, I'll think more about that, but it seems reasonable. There are always downsides, and someone might want erg/s to have erg linked somewhere useful, whereas power would probably be unhelpful. That would require defining the specific erg/s unit, if it would really be used. Johnuniq (talk) 04:18, 11 June 2015 (UTC)
Mass/area isn't pressure. There are a few customary units like psi but they're supported already; surely we don't need to provide a general facility for that error? NebY (talk) 22:54, 11 June 2015 (UTC)
Yes, I agree that it's ugly. The problem is that people use units in traditional ways that make sense. Some examples of my back-and-forth views are at wikitrains and here in October 2013. Convert uses a trick to make kg/m2 usable both in its correct sense (mass/area, for example spreading a mass of fertilizer over an area of ground), and as a pressure (traditionally used, I think, to describe the steam pressure in some locomotives). We could omit the link to pressure for mass/area as a compromise. Johnuniq (talk) 01:10, 12 June 2015 (UTC)
Rather force the use of kg-f/m2; this is in line with silent modification of quotations for minor typographic issues. If consistency is desired, areal density would be the natural target; the existence of the mass-related force per area should have no influence on this. —Quondum 01:57, 13 June 2015 (UTC)
I wouldn't dare suggest refusing to recognise kg/cm2, kg/m2, lb/in2 and psi as units of pressure! I'm just hoping we can avoid providing a general-purpose facility to make more units of pressure with a general automatic-per facility for mass/area. From experience, I would have said those four were enough though I suppose I should be honest and admit that Kaye and Laby did list "ton/sq.inch", "gm.cm.2" and "kg.mm.2" back in 1911. NebY (talk) 16:47, 13 June 2015 (UTC)


Unit au might go to Atomic units. Currently its a dab page. — CpiralCpiral 21:34, 12 June 2015 (UTC)

However, an au is an astronomical unit.GliderMaven (talk) 00:14, 13 June 2015 (UTC)
I disagree with it being regarded as either. The MoS indicates that the astronomical unit is written "AU" in WP (and I think that we should not diversify to many forms), and we should not threat "au" as a unit at all, since it does not refer to any specific unit.Quondum 01:42, 13 June 2015 (UTC)
A lot of the internal symbols are also lower case though. And having a lowercase au meaning one thing and uppercase AU symbol meaning a different thing could be confusing for the editors.GliderMaven (talk) 09:44, 13 June 2015 (UTC)
I don't follow that because au is not accepted by convert as a unit code (convert requires AU). What is an example that produces a link to a dab page? Johnuniq (talk) 03:49, 13 June 2015 (UTC)
"Atomic units" can not be a unit, it is a set of units for a working area. Note it is plural.
The "astronomical unit" (or, earlier?, 'astronomical unit of length') is well defined by the IAU (See Astronomical unit reference 6 = [1]). IAU also states: "5. that the unique symbol “au” be used for the astronomical unit" (see the pdf, final sentence).
I think this also implies that {{Convert}} should change this to lowercase?
{{Convert|1|AU|km|lk=in|sigfig=12}} → 1 astronomical unit (149,597,870.700 km)
{{Convert|1|au|km|lk=in|sigfig=12}} → 1 astronomical unit (149,597,870.700 km)
-DePiep (talk) 10:51, 13 June 2015 (UTC)
We're not obliged to strictly follow the IAU. "AU" has been used on Wiki and elsewhere far more frequently than lowercase. This has been discussed on various places ad nauseum. Huntster (t @ c) 11:00, 13 June 2015 (UTC)
I understand those discussions ad nauseum also took place in the scientific domain of astronomy. But recently, both IAU (2012) and BIMP (2014 [2]) have decided on this one. The fact that this wiki writes 'AU' often is not a decider (and of course only reflects the use of variants in sources). The usage of 'AU' elsewhere as you note would be in RS's then. In general, RS's usage can be decisive, but in this case this is from the period before that decision was made. We now have a definition made by the authority, and supported by BIPM (SI). 'AU' lost, {{Convert}} should comply. -DePiep (talk) 11:20, 13 June 2015 (UTC)
WP has a long history of not automatically following the conventions determined by authorities/standards. The (lack of) spacing before the % symbol is an example. The symbol for the astronomical unit is also very recently "decided" by the IAU, and BIPM has not apparently updated its position consistently, even though there is a brochure mentioning au. So saying that {{convert}} (and by implication the MoS) should comply has no basis. This (au) is also an example of an ambiguous notation adopted by the BIPM (if indeed this is their official position), and should thus be avoided in WP, and especially in templates that rely on automated matching of unit symbols. AU works, but au could be the atto- prefix and the unit u, which has a longer-standing status with the BIPM as a non-SI unit for use with the SI (though I find the need to have both the u and Da obscure). In all, I think that there is a strong case to settle on AU in WP, notwithstanding the IAU and BIPM.Quondum 16:45, 13 June 2015 (UTC)
WP history is not a RS. And as I noted, of course many instances of AU (in WP and in the sources) date from before the current valid decision. Today, IAU has decided (btw including the specific number, which was different before. {{Convert}} uses that latest number, so it does use that definition in this respect).
I provided sources from both IAU and BIPM that define what I claim. These are not just RS, they are authority controls. You are only muddying the waters by casting doubt and fudge on the sources, none substantiated. Four. You added quotes in "decided" without base — it is a plain decision (1). BIPM has not apparently updated its position consistently you did not source, nor did you explain what 'consistency' we need or expect (2). You write (if indeed this is their official position) without starting a base for that statement (3). About "au" being an ambivalent symbol: if the unit "attounified atomic mass unit" exists (atto is the 10-18 prefix; see atomic mass unit for symbol u), as you introduce (symbol then would be au by SI prefix, a double meaning indeed), please help us here by linking to the BIPM considerations with this. Or else ask them why the forgot this aspect (4).
It appears to me by RS that the decision was in favor of symbol au. If there are compelling arguments to maintain the historical pre-status-quo, I am open to hear sourced arguments for that. What I read here, looks like a rear-fight. So far, it's au. -DePiep (talk) 19:16, 13 June 2015 (UTC)
This is perhaps a debate that should be had at WP:MOSNUM, rather than here. Whatever the external position, WP (and RS) style does not necessarily immediately follow the choices of bodies; I'll substantiate that by referring to MOSNUM's very ginger attitude to IEC binary prefixes. The remainder of my points need not be clarified or substantiated; I'll withdraw them (and I'll add that I withdraw any expressed preference for specific units).
I guess that we should limit the discussion here to what {{convert}} should support in the absence of MOSNUM guidance. Until we have that, this template could support various units if the conflict between them can be managed. (For clarity, what I'm envisioning is potentially allowing the editor to choose between AU and au until a MOSNUM choice is made; automatic forcing to one in the template might give rise to arguments.) —Quondum 19:59, 13 June 2015 (UTC)
(ec) I disagree, except for the part when you say 'withdraw' ;-) ;-). Re I guess .. limit .. the discussion: no.
You write: WP (and RS) style does not necessarily immediately follow the choices of bodies (5): Sources please. Er, your 'bodies' are my 'authority controls' and 'RS's? To be short: if you don't substantiate you opinion with background, it's useless to continue. -DePiep (talk) 20:16, 13 June 2015 (UTC)
Interestingly, in your very first post here at 01:42, you wrote: The MoS indicates that the astronomical unit is written "AU" in WP (6). Could you provide a link or quote for that WP:MOS claim? -DePiep (talk) 21:12, 13 June 2015 (UTC)
Rereading this, I saw you statement Whatever the external position .. about WP:RS. I add this as  (6). -DePiep (talk) 21:46, 13 June 2015 (UTC)
Just what is it that you want? In case you haven't figured it out, I am no longer opposing anything relating to {{convert}} (other than making MoS decisions on a template talk page). —Quondum 23:23, 13 June 2015 (UTC)
Quite non-symphatic to ask this while only now you corrected yourself [3]. -DePiep (talk) 01:03, 14 June 2015 (UTC)
Quite hostile, and incorrect. I withdrew what I'd said on in the post before that; I struck it on my last post when it became clear from your response that you had not properly taken that on board. —Quondum 04:12, 14 June 2015 (UTC)
OK, then for now, lets alias things so au doesn't go to a dab page, and so that u doesn't go to the letter of the alphabet, but to Atomic mass unit.
{{Convert|1|au|km|lk=in|sigfig=12}} → 1 astronomical unit (149,597,870.700 km)
{{Convert|1|u|km|lk=in|sigfig=12}} → 1 unified atomic mass unit ([convert: unit mismatch])
CpiralCpiral 17:10, 14 June 2015 (UTC)
Let's not. There is no 'atomic unit' that convert could ever work for. The conversion is invalid.GliderMaven (talk) 17:15, 14 June 2015 (UTC)
Can you explain that? On 'au', it would be the astronomical unit, and on 'u', both Atomic mass unit and BIPM would seem to contradict you. —Quondum 17:38, 14 June 2015 (UTC)
Cpiral seems to want 'au' to link to 'atomic unit' but 'au' does not stand for any atomic unit; au is used only for astronomical unit, and that's not an atomic unit in any sense at all.GliderMaven (talk) 18:28, 14 June 2015 (UTC)
As for 'u' we could just create that as a unit rather than messing about with disambiguation pages; it seems like a total waste of time.GliderMaven (talk) 18:28, 14 June 2015 (UTC)
There are a ton of conversions for u we don't offer yet. As for au, now I just ask for it to alias to AU, (now that the discussion has taken place, and I, as the originator of the discussion, know better.) Thanks. — CpiralCpiral 20:17, 14 June 2015 (UTC)
As I sourced by IAU and BIPM, 'au' is astronomical unit, a unit of length. 'AU' is outdated. {{Convert}} must comply ('AU' instanced to be edited). -DePiep (talk) 20:42, 14 June 2015 (UTC)
AU is outdated, long live au. But we still must alias au to AU at convert/extra_units. Eventually perhaps AU will become alias to au instead. It doesn't matter all that much to us, right? It just an every day need to add another unit to convert and link. There's very likely hundreds more to do. I've made a first attempt at Module:Convert/extra for aliasing au and dalton to AU, and adding u. I'll be back for other units on other days. — CpiralCpiral 23:27, 14 June 2015 (UTC)
  • au to be be added to {{Convert}}. AU to be be removed from the {{Convert}} data set, offending articles will be listed automatically for edit (up for change 'AU' into 'au'). -DePiep (talk) 00:19, 15 June 2015 (UTC) Sources: IAU (2012 [4] and BIMP (2014 [5]) -DePiep (talk) 10:38, 16 June 2015 (UTC)
No, you will not remove "AU" from Convert without finding consensus. At this time, there is no consensus to do so. Huntster (t @ c) 00:28, 15 June 2015 (UTC)
Don't need consensus. RS (authorities even) are presented. -DePiep (talk) 01:06, 15 June 2015 (UTC)
Excuse me? WP:V doesn't even apply to style matters, so reliable sources aren't decisive anyway. And it's not at all clear that the IAU resolution is decisive anyway; many reliable sources, including most astronomical journals, continue to use AU. And even if reliable sources did determine style matters and reliable sources conclusively supported au over AU, the template would not be the proper way to effectively enforce a style guideline. And WP:CONSENSUS always applies. This should e discussed as part of the ongoing discussion at WT:MOSNUM, not here. —Alex (Ashill | talk | contribs) 06:46, 15 June 2015 (UTC)
Never wrote that "I" will remove it. Spelling AU or au is not a style matter, it's a definition matter. It's not by just an RS, it's by Authority-s. WP:Consensus may be skipped being bold, which is what I propose. Please show me where MOS allows this deviation (contradiction) of BIPM/SI (you may want to start that proposal, though). We only use historical spellings when it is relevant as a word (e.g. in book titles), not to maintain old habits. Anyway, au (lc) now added which is correct (see the 10:51 convert demo). -DePiep (talk) 10:51, 16 June 2015 (UTC)
Come to think of it: the number for AU/au has changed too over the years. Of course, a source from say 1990 might require using the contemporary number in {convert}, not today's number. -DePiep (talk) 10:56, 16 June 2015 (UTC)
You're getting into the substance of AU vs au, which should be done at WT:MOSNUM, where your points have all been refuted. (Specifically, it's not an authority that most astronomical publications or pretty much any other writers or publishers follow, so why should Wikipedia?) The styling of "AU" or "au" is absolutely a style matter, since different publications style the symbol definitely (though the great majority use AU). The MOS is a guideline; it never trumps consensus. Sure, consensus at first may be skipped by being bold, but then the revert and discuss parts of WP:BRD kick in, and consensus ultimately is the decider anyway. And making a bold change which the editor knows is contrary to consensus is simply disruptive editing. —Alex (Ashill | talk | contribs) 13:51, 16 June 2015 (UTC)
No. -DePiep (talk) 14:11, 16 June 2015 (UTC)

The only "authority" for weights and measures are officials who enforce weights and measures laws. If you use the wrong conversion factor between avoirdupois ounces and kilograms, and thus display for sale cans of carrots labeled with the wrong mass, weights and measures officials might very well come to your store, seize your inventory, and issue a summons to appear in court. But since astronomical units are not used in commerce, there is no one in authority to enforce anything.

As I mentioned at WT:MOSNUM in a parallel discussion, an example of a core astronomy journal, Astronomy and Astrophysics, using AU is the paper "Search for satellites near comet 67P/Churyumov-Gerasimenko using Rosetta/OSIRIS images" (I. Bertini et al., A & A manuscript no. 25979_ap_final_printer) which says "The images were taken when the comet was at 3.69 AU from the Sun." (emphasis added). Jc3s5h (talk) 20:51, 16 June 2015 (UTC)

Interesting. How many km is that, do you know? I mean, which number do they use? A new one? The 2004 one? The BIPM one? (i.e. the SI Authority; btw why do you "quote" that word?). -DePiep (talk) 21:31, 16 June 2015 (UTC)
The convention in science and engineering is that if there is no explicit statement about the uncertainty of a measurement, it is understood that there is some uncertainty in the last digit stated. Since the most precise value give by Bertini et al. is only stated to three significant figures, there is no way to distinguish among any of the values used for the astronomical unit in the last century or so.
I quoted the word "authority" to suggest it might not have its usual meaning in this discussion. By the way, SI is a system, not an organization. The organizations are the CGPM which meets every few years, and the BIPM, which carries on the affairs of the CGPM in between meetings. They have authority only to the extent that nations use their pronouncements as the basis of their weights and measures laws. Nations normally only enforce weights and measures laws with respect to goods or services sold in commerce, not to publications such as Wikipedia or astronomy journals. Jc3s5h (talk) 21:59, 16 June 2015 (UTC)
"SI is a system, not an organization". Oh. Thanks for telling me. But hey, your statement about precision says that the actual value {{Convert}} uses is not right? Tell IAU, not me. But, I was not asking you what you know (II), I was asking what the A & A position is in this. -DePiep (talk) 22:26, 16 June 2015 (UTC)
All I can say about the A & A position is that the "Astronomy & Astrophysics - Author’s guide" (April 2015) doesn't address it, but they let authors of a forthcoming paper get away with AU. The Convert template uses the value adopted by the IAU and latest (2014) BIPM brochure. As stated in the IAU's Resolution B2, the new defined value agrees with Table 1 of the IAU 2009 System (149 597 870 700 m ±3 m), for Barycentric Dynamical Time (TDB). There is the distinction that the IAU 2009 System regards the au as an experimentally derived value that varies according to the time scale, while the new version is defined and is the same for all time scales. Jc3s5h (talk) 23:17, 16 June 2015 (UTC)
As noted in the style discussion at WT:MOSNUM, four of the five major astronomy journals (Astrophysical Journal, Astronomical Journal, Astronomy & Astrophysics, and Publications of the Astronomical Society of the Pacific, the one exception being Monthly Notices of the Royal Astronomical Society, which I believe used au both before and after the 2012 IAU resolution) continue to use AU as the symbol for astronomical unit. That's pretty unambiguous evidence of the influence of the IAU resolution over reliable sources: none of the major journals changed their symbol usage as a result of the resolution, and I'm not aware of anyone who has.
The very few papers for which the 7×107% change in the value of 1 AU matters (mostly high-precision Solar System dynamics stuff and general relativity) normally define the unit system being used explicitly rather than assuming that readers will know which definition is being used or, more likely, just use cm or m (Gaussian cgs units being far more common in astronomy than MKS). (And, by the way, Wikipedia should and does do the same whenever it matters, which is probably only where the definition of an AU is defined at astronomical unit.) Journals are very unlikely to care which value of AU is used as long as it's clearly defined. Much as you might like there to be, there is no "authority" that controls what unit values or symbols astronomers use; it's all convention. (And I speak as a member of the IAU who is eligible to vote on these things, for the very little that's worth.) At the end of the day, the AU is a unit of convenience for problems on certain scales that come up reasonably often in astronomy, but only rarely in measurements with more than two or three significant figures, let alone the nine significant figures for which the exact defined value matters. —Alex (Ashill | talk | contribs) 06:53, 17 June 2015 (UTC)
I expect Ashill is right, but the discussion Ashill mentions only contains up-to-date citations to articles or author instructions for Astronomy & Astrophysics and Monthly Notices of the Royal Astronomical Society. Also, not being a professional astronomer, I don't know how long it takes for these journals to react to style matters. If they did decide to follow the IAU, I wonder how long it would take to show up in their publications. (The world at large is still trying to digest the 1928 recommendation from the IAU that GMT not be used.) Jc3s5h (talk) 11:33, 17 June 2015 (UTC)
I just added examples from all five astro journals plus Science and Nature. All except MNRAS use AU. I don't know how long journals take to react to style changes, but it is overwhelmingly clear that AU is the most common variant and therefore the variant that will be most clear to readers. —Alex (Ashill | talk | contribs) 12:45, 17 June 2015 (UTC)
I agree that "AU" is in widespread use and is therefore more familiar than "au". I disagree strongly with the statement that "familiarity brings clarity". What familiarity brings is the illusion of clarity. Clarity itself is brought by a clear and unambiguous definition, which has been provided by the IAU, now backed up by the BIPM. Dondervogel 2 (talk) 09:46, 22 June 2015 (UTC)
It is clear that both "au" and "AU" (meaning "astronomical unit") should be accepted for both input and output units. If "aliased" means that if the editor writes "AU", it will appear "au", that is the wrong approach. This template should always generate WP:MOSNUM-compliant code (as soon as reasonable after any changes in MOSNUM), regardless of any "standards" not accepted by Wikipedia. — Arthur Rubin (talk) 19:55, 26 June 2015 (UTC)
AU and au are symbolized their own way, but converted and linked the same way. The unit code usually has its own symbol. It is the other half-dozen attributes of the target unit code that aliases can share or override. Convert is very flexible. — Cp<font:color="#80C000">iralCpiral 23:56, 26 June 2015 (UTC)
Sorry; I haven't learned LUA. I have enough trouble with {{dr-make}} and its subtemplates. — Arthur Rubin (talk) 01:04, 27 June 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────The current situation is that editors can choose what a particular article needs:

  • {{convert|1|au|km|0|lk=in|abbr=on}} → 1 au (149,597,871 km) (lowercase "au" in output)
  • {{convert|1|AU|km|0|lk=in|abbr=on}} → 1 AU (149,597,871 km) (uppercase "AU" in output)

Johnuniq (talk) 01:42, 27 June 2015 (UTC)

Should {{convert}} be expected to understand the unit name? {{convert|1|astronomical unit|lk=on|abbr=on}} → 1 astronomical unit[convert: unknown unit]Quondum 01:59, 27 June 2015 (UTC)
That's possible of course, but adding each possible alias bloats the units and their documentation. I doubt anyone would want to use "astronomical unit" rather than "au" to identify which unit they wanted, and "au" would be sufficiently clear for anyone who should be editing an article using that term. Johnuniq (talk) 03:29, 27 June 2015 (UTC)

Proposed new units[edit]

I am preparing for a new release of the module and that involves consideration of three units added to Module:Convert/extra:

  1. au: like AU but using au displays "au" as the symbol, while AU displays "AU"
  2. u: unified atomic mass unit
  3. dalton: same as u but displays "Da" for the symbol and "dalton" for the name

I support the addition of au because recent MOS discussions show there is no ruling on whether "au" or "AU" is preferred and in some contexts "au" is wanted while others need "AU". If anyone has a link showing my understanding of the MOS discussions is incorrect, please provide it, however, let's not debate the merits of each symbol here.

I do not support u or dalton unless someone can show a couple of articles where conversions of these units would be useful. Cpiral may have had {{val}} in mind because val uses convert for some units, however I think val has a different application than convert and the latter is too complex already without adding units specifically for val. Thoughts please. Johnuniq (talk) 03:24, 30 June 2015 (UTC)

Since val can very easily take care of u separately, val gives no a reason to include a unit that is not needed in convert. —Quondum 03:35, 30 June 2015 (UTC)
Any page about units that also has a conversion chart (: hastemplate:"infobox unit" insource:inunits1) should be here ready and waiting, including those three. — CpiralCpiral 04:01, 30 June 2015 (UTC)
Do you mean the infobox table, for example, at the top of Atomic mass unit? I would not expect convert to always be useful there because precise definitions are involved and mucking around with convert to display exactly what is wanted might not be warranted. In particular, that example uses uncertainty notation which convert can't handle. There are zillions of units (examples), and adding them all to convert for one or two occurrences does not seem desirable. Johnuniq (talk) 04:19, 30 June 2015 (UTC)
OP proposal sounds reasonable to me. -DePiep (talk) 08:31, 30 June 2015 (UTC)
No. Please let me answer the original question again. Add auu because its Wikipedia page rightly states that it is commonly and notably converted. Consider the alternative process: that other person is bothered because the commonly converted standard unit is missing from Convert, and is bothered to come to the talk page, and no one would then delay. So why aren't all 27 units in that search link? Because that search link is new information. There is no more reasonable, honest, objective justification for adding au or any other unit missing from that particular search. Thank you. — CpiralCpiral 21:43, 2 July 2015 (UTC)
Yup, your understanding of the MOS discussion re au and AU jibes with mine. And I think that even if the MOS does recommend one symbol or the other, it will remain best to include both in the convert template since it's just a tool for editors (not an MOS enforcement mechanism) and both choices are at least arguably reasonable. I do not care at all about the implementation; as far as I know as a dumb end user, it works perfectly well now and there is no need to change it. —Alex (Ashill | talk | contribs) 14:29, 30 June 2015 (UTC)
re (not an MOS enforcement mechanism) - well, it should follow MOS truly & really. That is also what it is about, over here. -DePiep (talk) 02:26, 1 July 2015 (UTC) (did rm distracting typo)

@Cpiral: I don't follow your comment. Please show an example of a val and/or convert that would be useful in an article and which needs units 2 and 3 above (u and dalton). If there are 27 articles (like Watt?) that need some fix, why not just add the required definition to val? One of the items on my todo list is to remove a lot of strange units from convert because they add clutter and are never used, and that makes me doubly reluctant to add new units unless there is a demonstrated need for them. Johnuniq (talk) 01:25, 3 July 2015 (UTC)

I can appreciate your sentiment about units being clutter, I'm interested in that effort too and concede that it might be the case that daltons are clutter. I only had in mind to humbly vote and proudly advertize my wares, so forgive me if I sound repetitive, but I'm confident that my reasoning, given above, has weight: Those pages are most likely to need template convert, themselves, somewhere on there own page with convert because, by virtue of each of them having a Infobox Unit with conversions in it. That. Plus they say they convert themselves. Make sure the 26 others are there to, and for the same reason. Don't wait for them to ask or for me to exemplify in time. As for your examples, I humbly submit on behalf of u, alias Da, alias amu, the word "OR" as appended to Atomic mass unit#Examples, plus the very telling Infobox Units. — CpiralCpiral 07:35, 3 July 2015 (UTC)
That example uses val like this:
  • {{val|1.0078250|u=u}} ({{val|1.0078250|u=Da}})1.0078250 u (1.0078250 Da)
It seems pretty pointless to define those units in convert when they are equivalent, and given it is unlikely the units would be used for anything else. Convert could be used instead of val in the infobox at, for example, Kilometre, but no new units are needed for that. I don't see how convert could be expected to help at, for example, Watt. It is normal here for people to be asked to provide examples of how proposed units would be used. Johnuniq (talk) 10:29, 3 July 2015 (UTC)

Units which set sp=us[edit]

Some units are defined like this:

meter  =m  sp=us

That makes meter an alias for m and also sets sp=us (US spelling of "meter"). Currently, convert gives these results (using fixed wikitext so the results will not change):

  • {{convert|1.23|meter|cm|abbr=off}} → 1.23 meters (123 centimetres)
  • {{convert|123|cm|meter}} → 123 centimetres (1.23 m)

That uses sp=us for "meters" but not "centimetres". As part of some recent developments, I plan to make sp=us apply to both sides which will give these results:

  • {{convert|1.23|meter|cm|abbr=off}} → 1.23 meters (123 centimeters)
  • {{convert|123|cm|meter}} → 123 centimeters (1.23 m)

There are about 110 converts in articles where this will make a small difference. For example, {{convert|44,000|liters}} will change from the first of the following to the second:

44,000 liters (9,700 imp gal; 12,000 US gal)
44,000 liters (9,700 imp gal; 12,000 U.S. gal)

and {{convert|4.4|to|5|L|U.S.qt}} will change like this:

4.4 to 5 litres (4.6 to 5.3 U.S. qt)
4.4 to 5 liters (4.6 to 5.3 U.S. qt)

I'm posting this to document my planned change to convert, but I don't think the subtle difference is worth documenting for users. Johnuniq (talk) 04:29, 3 July 2015 (UTC)