Template talk:Convert/Archive June 2015

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Update link?

I notice {{val|123|ul=mpgimp}} produces 123 mpg‑imp through {{convert}}. This has a link to Imperial unit. It should be updated to Imperial units. Headbomb {talk / contribs / physics / books} 02:23, 27 May 2015 (UTC)

Thanks, I have updated my copy of the master list of units. The next release of convert will fix that in a few weeks. Johnuniq (talk) 05:45, 27 May 2015 (UTC)
Also, along similar lines, {{convert|12|USgal|impgal|lk=on}} is giving "12 US gallons (10.0 imp gal)" with both links redirecting to Gallon. It used to give "12 US gallons (10.0 imp gal)". The old version was obviously a whole lot more useful; it was switched a few years back in the midst of an attempt to simplify what was becoming a bit of an unwieldy template; the intention, though, had been to return to the former style. I wonder whether this would still be a possibility. Of course, though, although the old style is better, it's not perfect still linking twice to Gallon. "12 US gallons (10.0 imp gal)" would be best. Jimp 06:22, 27 May 2015 (UTC)
Customary units are easily handled so long as the link documentation covers the need. That's in the full list of units, and the volume units are later on that page. As an example, they show unit impqt with link "@Imperial quart", and USqt with link "+Quart". The "@" and "+" codes invoke special "customary" processing with the following results.
  • {{convert|12|USqt|impqt|abbr=on|lk=on}} → 12 US qt (10.0 imp qt)

    12 [[United States customary units|US]] [[Quart|qt]] (10.0 [[Imperial unit|imp]] [[imperial quart|qt]])

  • {{convert|12|USqt|impqt|abbr=off|lk=on}} → 12 US quarts (10.0 imperial quarts)

    12 [[United States customary units|US]] [[quart]]s (10.0 [[Imperial unit|imperial]] [[imperial quart|quarts]])

In other words, inserting "@" or "+" where needed will give results similar to above.
I'm not convinced having "US" linked to one thing and "qt" to another is helpful (who is going to notice that US links somewhere useful?), but am happy if the units work that way. If you feel in the mood, please do what is needed on the units page. There is another place needing an edit to fix the "Imperial units" issue. We could do that in the sandbox and see how it works. BTW, I started on the comma=gaps enhancement as above two days ago, and will be ready to test it soon, although RL is still hectic. Johnuniq (talk) 10:28, 27 May 2015 (UTC)

I have put fixes in the sandbox so links will use Imperial units with an "s". I have too many other things to do at the moment and so won't look at the other issues raised by Jimp but they could be fixed as I outlined above. Examples:

Johnuniq (talk) 11:00, 1 June 2015 (UTC)

1 × 2 × 3 cm

{{convert|1|x|2|x|3|cm|abbr=on}} is giving "1 × 2 × 3 cm (0.39 × 0.79 × 1.18 in)". It should give "1 cm × 2 cm × 3 cm (0.39 in × 0.79 in × 1.18 in)" in line with {{convert|2|x|3|cm|abbr=on}} and long-standing consensus at MOS. Jimp 08:10, 28 May 2015 (UTC)

Written extensively, now in archive. -DePiep (talk) 10:55, 28 May 2015 (UTC)
I'm confused. Why is this?
{{convert|1|x|2|cm|abbr=on}} → 1 cm × 2 cm (0.39 in × 0.79 in) checkY MOS compliant
{{convert|1|x|2|x|3|cm|abbr=on}} → 1 cm × 2 cm × 3 cm (0.39 in × 0.79 in × 1.18 in) ☒N non-compliant
The discussion at Template talk:Convert/Archive November 2014 § Proposal: " by "and " × " to follow MOS doesn't say anything about complying with MOS with two-dimension conversions but non-complying with three-dimension conversions. —sroc 💬 16:53, 28 May 2015 (UTC)
You are questioning the Green tickY/Red XN statement I understand? Well, the link opens with a blockquote from MOS:UNITS. It says that when using the × symbol, each number must have its unit or the unit is mentioned once outside of brackets. That is done correctly in the 2-dim example, and not in the 3-dim example. The archived version was a proposal, not accepted, for what Jimp mentions here now. -DePiep (talk) 17:05, 28 May 2015 (UTC)
I'm confused. Is there any reason this template doesn't (or shouldn't) follow the provision of MOS that says how to format 3-dim measurements? It doesn't look like that archive discussion mentioned 3-dim measurements at all, much less reach consensus on an exception. —sroc 💬 17:14, 28 May 2015 (UTC)
No need to be confused: {{Convert}} does not confirm MOS in situations. -DePiep (talk) 23:47, 28 May 2015 (UTC)
I mean: why doesn't {{convert}} follow MOS when converting three-dimensional figures? Is MOS wrong OR does this template need to be fixed to output consistent with MOS OR is there a reason why the template intentionally departs from MOS on this point? —sroc 💬 17:37, 29 May 2015 (UTC)
I don't know why. I wrote the point-outs and improvement proposal in November 2014, and it did not take effect. Clearly it did not convince chief programmer Johnuniq. I am a bit reluctant to re-write the same over again. -DePiep (talk) 18:02, 29 May 2015 (UTC)
@Johnuniq: Could you fill us in? —sroc 💬 02:52, 30 May 2015 (UTC)

Background

Generally it's not desirable to apply rules simply because they are the rules without considering the effect of changes on article content. Therefore I listed articles I think are affected by this discussion in my sandbox (permalink), but I won't have time to ponder that for a day or two. I had a quick look at a couple of links and it seems there are plenty of places which would benefit from MOS compliance, but some tables (example) might be a problem if the unit was repeated—or should be done a different way.

I went to a lot of trouble to infer the rules followed by the old templates, then make the module emulate them as closely as reasonable, so why-is-it-so? questions about the module are usually answered with "because it's always been done that way". I would like to clean out many of the compatibility quirks that are built in to the module, but they are immensely complicated with behavior that depends on abbr + adj + lk + range and probably other stuff, with various exceptions. Life is too hectic here at the moment for me to want to dive that deeply, but some time later this year I would like to take that on.

As noted above, 1x2 ranges work differently from 1x2x3. The simple reason is that the old template had a bunch of quirky rules for 1x2 and did not support 1x2x3 (Template:Convert/3 was used for that, and I see it is still used, as is Template:Convert/2, see [1] + [2]). When I looked at the possibility of supporting 1x2x3, I knew it would be best to use a loop so the same code would handle the first and second ranges. I found that possible, and then I thought, well, why stop at two? Therefore, convert can do bizarre things:

  • {{convert|1|x|2|x|3|to|5|x|10|x|15|cm|abbr=on}} → 1 cm × 2 cm × 3 cm to 5 cm × 10 cm × 15 cm (0.39 in × 0.79 in × 1.18 in to 1.97 in × 3.94 in × 5.91 in)

I did not want to support the complexity and quirkiness of the 1x2 exceptions in 1x2x3 or higher ranges, and just implemented a basic system without concern for MOS, particularly because programs have to do something when presented with bizarre input, and I did not want to repeat the units in the above example. At the time, emulating the old templates was the primary goal, and convert did not support 1x2x3 while convert/3 did not repeat the units.

The reason x gives "by" when the unit is not abbreviated (apart from because that's what the old templates did) is to provide a range which is more formal (using English) for the input, such as "1 by 2 centimetres" but a more compact form for the output, such as "0.39 in × 0.79 in". That is the default with x if abbr=on is not used. We would need to look at what is really needed before making changes. I am suprised to see that quite a lot of 1x2x3 ranges are used, and I can probably find a simple way to make them MOS compliant although I would like to clean out some of the quirks at the same time, such as removing abbr=mos and some exceptions. I won't be able to do that soon, but it should be within a couple of months. I doubt 1x2x3x4 will ever be used, but I would not plan on repeating units for more than 1x2x3. Johnuniq (talk) 11:00, 30 May 2015 (UTC)

@Johnuniq: Thanks for the very detailed reply. Good to know there isn't a specific decision that convert shouldn't follow MOS, but understand that it's not an overnight thing and there are kinks to be carefully considered before rolling out something that will affect many instances—with tables, for instance, I wonder whether there is value in having an option to specify the units in the column heading to conserve space (or simply use |abbr=values):
Illustrating table
Product SKU Announced SIM card Processor RAM/Flash Resolution Display Weight Dimensions
inches (mm)		 Battery
mAh		 OS BT WLAN Cell GPS NFC Wireless Charging
Samsung Galaxy Gear[1] SM-V700 4 September 2013 no Single-Core 800 MHz (Dual-Core 1.6GHz with unlocked Kernel/.null rom) Exynos4212[2] 512MB/4GB 320x320 1.63 in
(41 mm)		 2.6 oz
(74 g)		 1.45 × 2.23 × 0.44
(37 × 57 × 11)		 315 Android / Tizen Update 4.0 LE
Samsung Gear 2[3] SM-R380 22 February 2014 no Dual-Core 1 GHz Exynos3250 512MB/4GB 320x320 1.63 in
(41 mm)		 2.4 oz
(68 g)		 1.45 × 2.30 × 0.39
(36.8 × 58.4 × 9.9)		 300 Tizen 4.0 LE
Samsung Gear 2 Neo[4] SM-R381 22 February 2014 no Dual-Core 1 GHz Exynos3250 512MB/4GB 320x320 1.63 in
(41 mm)		 1.94 oz
(55 g)		 1.49 × 2.31 × 0.39
(37.8 × 58.7 × 9.9)		 300 Tizen 4.0 LE
Samsung Gear Live[5] SM-R382 25 June 2014 no Single-Core 1.2 GHz MSM8226 512MB/4GB 320x320 1.63 in
(41 mm)		 2.12 oz
(60 g)		 1.49 × 2.57 × 0.54
(38 × 65 × 14)		 300 Android Wear 4.0 LE
Samsung Gear Fit[6] SM-R350 11 April 2014 no STM32F439[7] 160 MHz 16MB 128x432 1.84 in
(47 mm)		 0.95 oz
(27 g)		 0.92 × 2.26 × 0.47
(23 × 57 × 12)		 210 Tizen/Samsung 4.0
Samsung Gear S SM-R750 28 August 2014 nano-SIM Dual-Core 1 GHz 512MB/4GB 360x480 2 in
(51 mm)		 2.36 oz
(67 g)		 1.57 × 2.23 × 0.49
(40 × 57 × 12)		 300 Tizen 4.1 bgn 2G/3G Yes
LG G Watch W100 25 June 2014 no Quad-Core 1.2 GHz MSM8226 512MB/4GB 280x280 1.65 in
(42 mm)		 2.22 oz
(63 g)		 1.57 × 1.83 × 0.39
(39.9 × 46.5 × 9.9)		 400 Android Wear 4.0 LE
LG G Watch R[8] W110 4 September 2014 no Quad-Core 1.2 GHz MSM8226 512MB/4GB 320x320 1.3 in
(33 mm)		 2.19 oz
(62 g)		 1.83 × 1.83 × 0.43
(46 × 46 × 11)		 410 Android Wear 4.0 LE
LG G Watch R2[9] 7 January 2015 WebOs Yes
Asus ZenWatch WI500Q 3 September 2014 no Quad-Core 1.2 GHz MSM8226 512MB/4GB 320x320 1.63 in
(41 mm)		 2.67 oz
(76 g)		 1.57 × 1.99 × 0.37
(39.9 × 50.5 × 9.4)		 410 Android Wear 4.0 LE
Sony SmartWatch 2 SW2 25 June 2013 no Single-Core 180 MHz CM4 220x176 1.6 in
(41 mm)		 4.3 oz
(120 g)		 1.65 × 1.61 × 0.35
(41.9 × 40.9 × 8.9)		 140 MicroC/OS-II 3.0 Yes
Sony SmartWatch 3[8] SWR50 3 September 2014 no Quad-Core 1.2 GHz BCM23550 512MB/4GB 320x320 1.6 in
(41 mm)		 1.59 oz
(45 g)		 1.42 × 2.0 × 0.39
(36.1 × 50.8 × 9.9)		 420 Android Wear 4.0 LE Yes Yes
Motorola Moto 360[10] Moto 360 18 March 2014 no Single-Core 1 GHz TI OMAP 3 512MB/4GB 320x290 1.56 in
(40 mm)		 1.7 oz
(48 g)		 1.81 × 1.81 × 0.45
(46 × 46 × 11)		 320 Android Wear 4.0 LE Qi
Apple Watch 38mm: Watch1,1
42mm:
Watch1,2		 9 September 2014 no Apple S1 512MB/8GB 38mm:
272×340
42mm:
312×390		 38mm:
1.32 in (34 mm)
42mm:
1.5 in (38 mm)		 38mm:
1.52 × 1.31 × 0.41
(39 × 33 × 10)
42mm:
1.65 × 1.41 × 0.41
(42 × 36 × 10)		 38mm: 205 Watch OS 4.0 LE bgn Yes Inductive
Pebble Watch 11 April 2012 no Single-Core STM32F205RE 120 MHz CM3 128KB/4MB 144x168 1.5 in
(38 mm)		 1.34 oz
(38 g)		 2.45 × 1.42 × 0.45
(62 × 36 × 11)		 140 Pebble OS 4.0 LE
Qualcomm Toq 4 September 2013 no 200 MHz CM3 288x192 1.55 in
(39 mm)		 3.2 oz
(91 g)		 1.7 × 1.87 × 0.39
(43.2 × 47.5 × 9.9)		 240 QCOM OS 3.0 WiPower
Exetech XS3[11] XS3 1 November 2013 Yes MTK 6577 512MB/32GB 240x240 1.54 in
(39 mm)		 2.4 oz
(68 g)		 1.45 × 2.30 × 0.39
(36.8 × 58.4 × 9.9)		 420 Android 4.0 4.0
Just a thought.
Also, in the example you gave, I would rather have the units repeat after each dimension, or at least after each end in the range, otherwise there are too many numbers before you get to the end to find out the proper context of what unit you've been reading numbers in:
  • {{convert|1|x|2|x|3|to|5|x|10|x|15|cm|abbr=on}}
    → 1 cm × 2 cm × 3 cm to 5 cm × 10 cm × 15 cm (0.39 in × 0.79 in × 1.18 in to 1.97 in × 3.94 in × 5.91 in)
    OR
    → 1 × 2 × 3 cm to 5 × 10 × 15 cm (0.39 × 0.79 × 1.18 in to 1.97 × 3.94 × 5.91 in)
—sroc 💬 12:08, 30 May 2015 (UTC)
@Sroc: this is proposing non-MOS formats and so will not be honored. The point is that we inherited non-MOS formats, and Johnuniq has explained that it is difficult to get rid of those situation. (But we will pursue that). You are now asking for exceptions, and things like that are what brought us into this trouble in the first place.
If you do have a serious request to deviate from MOS, then start a new thread. -DePiep (talk) 21:23, 30 May 2015 (UTC)
@DePiep: I didn't mean to propose deviating from MOS; I support updating the template to comply follow MOS. I was simply offering a suggestion in response to Johnuniq's comment: "some tables ... might be a problem if the unit was repeated—or should be done a different way." Besides, that guidance WP:UNITS arguably doesn't apply in cases where the units are not specified with the numbers, and there is an argument that use in tables with insufficient space would justify making an exception—but I'm not pushing for that particular solution, merely throwing a suggestion out there. Do you have any alternative suggestions how to overcome the problem? —sroc 💬 11:05, 31 May 2015 (UTC)
The example after you "OR" is non-MOS. What now is needed is a will to push forward into using MOS, not using exceptional situations as a proof that MOS cannot be used. Unless there is an explicit "let's go there", I find prolonging this exceptions-discussion useless. I understand that Johnuniq might be back on this in months not days. -DePiep (talk) 11:26, 31 May 2015 (UTC)
So now it is within days: [3]. As I said, not worth spending time discussing. The satellite drifts, out of communication. -DePiep (talk) 22:59, 2 June 2015 (UTC)

References

  1. ^ http://www.samsung.com/us/mobile/wearable-tech/SM-V7000ZKAXAR
  2. ^ http://www.anandtech.com/show/7273/the-galaxy-gear-preview-samsungs-first-wearable
  3. ^ http://www.samsung.com/us/mobile/wearable-tech/SM-R3800VSAXAR
  4. ^ http://www.samsung.com/us/mobile/wearable-tech/SM-R3810ZAAXAR
  5. ^ http://www.samsung.com/us/mobile/wearable-tech/SM-R3820ZKAXAR
  6. ^ http://www.samsung.com/us/mobile/wearable-tech/SM-R3500ZKAXAR
  7. ^ http://www.phonearena.com/reviews/Samsung-Gear-Fit-Review_id3650/page/3
  8. ^ a b http://blog.gsmarena.com/smartwatch-bonanza-hottest-smartwatches-ifa-compared/#more-73189
  9. ^ http://www.digitaltrends.com/mobile/lg-g-watch-r2-news/
  10. ^ https://www.ifixit.com/Teardown/Motorola+Moto+360+Teardown/28891
  11. ^ http://www.exetech-smartwatches.com/index.php/en/2014-03-01-13-22-40/watches/xs-3black-silver-detail

Module version 11

Some changes to the convert modules are in the sandbox, and I intend switching the main modules to use the sandbox soon.

The changes are:

  • Units:
    • New "energy per unit length" units currently in Module:Convert/extra: kWh/100 mi and mpg and alias mpg-e (discussed here).
    • Some unit symbols which contained a space now use   for the space, for example, "kW·h/100 km".
    • The link for some customary units changed from Imperial unit to Imperial units with 's' (discussed here).
  • Using gaps for thousand separators (discussed here):
    • comma=gaps Gaps are used to separate groups of digits before and after the decimal mark; there is no gap before a trailing single digit. Previously, gaps were like commas and only occurred before the decimal mark.
    • comma=gaps3 Like comma=gaps, but where there are sufficient digits, there are always three digits per group so there may be a gap before a trailing single digit.
    • comma=gaps5 Is now equivalent to comma=gaps and is deprecated (previously, it was similar to comma=5 using gaps).
  • References:
    • More than one reference is accepted after an input value. This is for use in infoboxes where a value can be entered for a field which is passed to convert. It is convenient for the field to include a reference. It would be better for a separate field to be used for that purpose, but editors sometimes add a reference to the value, so convert handles it. Occasionally, more than one reference is provided. Previously, only one reference was accepted.
    • The method of checking for a reference strip marker has been changed because MediaWiki has recently changed some details, and that is causing errors with the version 10 convert.

Module version history 1 (Dec 2013) • 2 (Jan 2014) • 3 (April 2014) • 4 (July 2014) • 5 (Sep 2014) • 6 (Nov 2014) • 7 (Dec 2014) • 8 (Feb 2015) • 9 (Feb 2015) • 10 (May 2015)

I had hoped to include some changes for the recent discussion regarding MOS compliance for ranges with ×, but the references change is needed soon because a recent MediaWiki change is causing some infoboxes to show convert errors due to a reference being included with the value. Johnuniq (talk) 11:20, 2 June 2015 (UTC)

some changes [...] regarding MOS compliance for ranges with ×. Let me guess. I'd prefer you come forward with a compliance-route. I don't blame anyone for time delay. I do object to undeclared or uncommitted moves. -DePiep (talk) 22:30, 2 June 2015 (UTC)
  • Done: the modules have been updated and the error tracking categories are empty again. Johnuniq (talk) 03:41, 7 June 2015 (UTC)

The mm to inch converter used on Wikipedia is pathetically inaccurate

As far as I can see the mm to inch converter rounds up to the nearest whole inch! This is unbelievable, it is so inaccurate as to be useless; for example a battleship (Bismarck class) main-belt armour of 320mm is given as 13 in, not the correct 12.6 inches. Can you imagine the difference in weight that would ensue if 0.4 inches thickness of hardened steel was added over the whole side of something as large as a battleship. This needs urgent attention. Urselius (talk) 13:50, 7 June 2015 (UTC)

Urselius, the output has the same precision as the input. in this case, two significant figures. if you want to increase the precision, try {{convert|320|mm|in|sigfig=3}} or set the number of decimal places in the output with {{convert|320|mm|in|1}}. unless we know the precision of the instrument used to measure the 320 mm, we are just guessing here. if you said you wanted to convert 320.0mm or 320.00mm, then it's clear which precision to use, namely 320.0 millimetres (12.60 in) or 320.00 millimetres (12.598 in). Frietjes (talk) 14:03, 7 June 2015 (UTC)
Thanks for pointing this out. The situation in many articles on Wikipedia is dire because people are applying these conversion templates all over the place without any knowledge of how to make them appropriately accurate. I hate templates in general, I prefer using a brain. Urselius (talk) 17:26, 7 June 2015 (UTC)

Convert/spell

Refresh my memory: What replaced "Convert/spell"? PRR S1#Service history Peter Horn User talk 16:05, 9 June 2015 (UTC)

The |spell=on parameter. -- WOSlinker (talk) 16:10, 9 June 2015 (UTC)
(ec) I don't know what it did, but documentation has Template:Convert#Spell out numbers: ten miles. (in #Words). OK? -DePiep (talk) 16:12, 9 June 2015 (UTC)
Thanks, "spell=in" |spell=in worked just fine. {{convert|19|ft|m|2|spell=in}} (over {{convert|6|yd|m|2|spell=in|disp=or|sp=us}}) nineteen feet (5.79 m) (over six yards or 5.49 meters) Peter Horn User talk 01:01, 10 June 2015 (UTC)

Million litres per day

I've looked on this page and the full list of units but I'm still unsure what units and abbreviations to use when a source says the flow of water in a river is 411 million units per day on average. Any help appreciated.— Rod talk 17:17, 10 June 2015 (UTC)

I think I've worked it out by using {{convert|411000000|L/d}} but I have no concept of whether the conversion 411,000,000 litres per day (1,050,000 imp gal/ks) is right.— Rod talk 17:30, 10 June 2015 (UTC)
You've outhelped yourself, above the documentation! L/d is not even listed (but composed on the fly, by {{Convert}}, from L and day).
I agree right away the unit list#Flow is not well accessible for such a search. btw to change that number notation see /doc#Numbers. Any remaining questions? -DePiep (talk) 19:26, 10 June 2015 (UTC)
Thanks. I saw another unit had per day so guessed. This is now in River Tone (1st line of Geography section) and there are lots of other conversions in the article so any checking of how I've used it would be appreciated.— Rod talk 19:43, 10 June 2015 (UTC)
Don't worry. If the article would contain nonsense convert input (erroneous, can not handle), it will be listed in Category:Convert error categories. For example: "L/d to km/h" LOL.
About numbers: Your {{convert|411000000|L/d}} could be entered
{{convert|411|m3/d}} → 411 cubic metres per day (14,500 cu ft/d)
Note that the default unit for "L/d" is "imp gal/ks", but for "m3/d" it is "cu ft/d" (has to do with that 'on the fly')
About units: your input uses, left to the template, some default return unit 'imp gal/ks' (ks=kiloseconds!). You can set that yourself more conveniently in the 3rd parameter:
{{convert|411000000|L/d|cuft/d km3/a}} → 411,000,000 litres per day (14,500,000 cu ft/d; 0.150 km3/a)
Have a nice edit. -DePiep (talk) 20:07, 10 June 2015 (UTC)
Thanks - I will not claim to understand all of that (including the reference to "kiloseconds" which I'd never heard of before) but have gone with your final example as it hopefully covers all options.— Rod talk 20:16, 10 June 2015 (UTC)
Looking at this again what does "/a" in the final conversion represent ? per annum.— Rod talk 20:21, 10 June 2015 (UTC)
Yes, per annum. kiloseconds is formally a correct time period, by SI even. (Again, {Convert} does not have "L/d" at hand but can deduct it nicely on the fly, but as a consequence it might use weird units - correct still).
General law: if {{Convert}} eats it, it is calculated correctly. Next step for the editor: tweaking units, number formats, wording. Did I say the calculation is correct? No? Let me say it again: if {{Convert}} does not add a maintenance note in the saved article like: "L/d to km/h[wrong unit]" then you're safe in the values. Upp to the editor to know the units, numbers, etcetera. -DePiep (talk) 20:39, 10 June 2015 (UTC)

DemoTemplate

There is this new Module:DemoTemplate

{{#invoke:DemoTemplate|Convert|10|km|nmi|abbr=off}} that produces the full line:
{{Convert|10|km|nmi|abbr=off}} → 10 kilometres (5.4 nautical miles)

To type diff (manually add the red text):

{{#invoke:DemoTemplate|Convert|10|km|nmi|abbr=off}}

See Wikipedia_talk:Lua#Template_demo. -DePiep (talk) 21:07, 10 June 2015 (UTC)

Parlance

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

Number

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

Unit

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

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)

comma=gaps isn't working correctly

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,

{{convert|12345.678901|m|comma=gaps}}
→ <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

{{convert|12345.678901|m|comma=gaps}}
→ <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.

Questions

  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)

Answers

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

Examples:

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

au

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 = [4]). 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 [5]) 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 [6]. -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 u[convert: unknown unit]
— 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 [7] and BIMP (2014 [8]) -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×10−7% 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. — CpiralCpiral 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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_June_2015&oldid=1053465430"