Template talk:Convert/Archive August 2014

Scientific notation

Is there any way to force both input and output figures to be displayed in scientific notation, preferably tied to a specified significant figure using sigfig? Something like {{convert|93000|mph|km/h|sci=on|sigfig=4}} --> 9.300 × 10⁴ miles per hour (1.497 × 10⁵ km/h). This would be very useful in the astronomy articles I'm currently working in. I looked in the code and the module seems capable of something like this based on the documentation, but Lua is beyond me. — Huntster (t @ c) 03:08, 7 August 2014 (UTC)

Scientific notation is automatically used if the value is very big or very small (value >= 1×10⁹ or value < 1×10⁻⁴). There is no way to specify that scientific notation be used. Engineering notation is available for nearly all units, but the only available exponents are 3, 6, 9, 12, and 15, and it has a quirk: it uses words if abbreviations are off. A little more information is at Help:Convert units#Engineering notation. Here are examples (e6km/h is probably not the correct choice here, but I used it to show some variety):

• {{convert|93.00|e3mph|e6km/h|sigfig=4}} → 93.00 thousand miles per hour (0.1497×10^⁶ km/h)
• {{convert|93.00|e3mph|e6km/h|sigfig=4|abbr=on}} → 93.00×10^³ mph (0.1497×10^⁶ km/h)

That might help a little? Johnuniq (talk) 03:46, 7 August 2014 (UTC)

Unfortunately no, the articles would need more flexibility than that, as the scientific notation used in them always uses a single digit to the left of the decimal point. But thanks for the response. — Huntster (t @ c) 14:19, 7 August 2014 (UTC)

As you saw, the module is pretty big and ugly. Frankly I wasn't really sure that all that code would run (Scribunto was brand new when I started in September 2012), and I mostly did the minimum to emulate the previously used set of templates. Therefore, the code is not as modular as it should be, and making it "proper code" would bloat it out quite a lot, extending it's complexity. What I'm trying to say is that there is no code to format the input number (it's only the converted outputs which can be in scientific notation if very small or large). I could look at what would be involved in adding something, but I'm on a bit of break from convert coding and wouldn't do anything quickly. Meanwhile, it would help if you could show a couple of articles where such features would be useful. Johnuniq (talk) 11:19, 8 August 2014 (UTC)

Dashes

In the second paragraph of Quagga, {{convert}} produces the text

"4 ft 1 in–4 ft 5 in". Per WP:ENDASH this should read

"4 ft 1 in – 4 ft 5 in" (with a spaced en dash)

because dashes in ranges should be spaced "when at least one endpoint of the range includes at least one space" (in this case both endpoints include three spaces). The problem doesn't seem to be easily fixable (putting spaces around the dash in the template has no effect and putting non-breaking spaces around it produces an error), but it's very possible there's some intricacy in this template that I've missed. Any thoughts? – Arms & Hearts (talk) 14:00, 13 August 2014 (UTC)

• Let's change MOS:ENDASH for this. End of problem. -DePiep (talk) 21:24, 13 August 2014 (UTC)
• Question: how did you produce that outcome by {{convert}}? (as it is now, it is hard-code entered)-DePiep (talk) 21:29, 13 August 2014 (UTC)
• What about {{convert|1-2|m|ft}} →

1–2 metres (3.3–6.6 ft) (spaces in this too) -DePiep (talk) 21:29, 13 August 2014 (UTC)

I guess A&H is correct that a spaced en dash would be better with output multiples like ftin. The quick fix is to use "to" instead. Examples of current behavior:

1. {{convert|1|-|2|m|ft}} → 1–2 metres (3.3–6.6 ft) {{convert|1|-|2|m|ftin}} 1–2 metres (3 ft 3 in – 6 ft 7 in)
2. {{convert|125|-|135|cm|ftin|abbr=on}} → 125–135 cm (4 ft 1 in – 4 ft 5 in)
3. {{convert|125|to|135|cm|ftin|abbr=on}} → 125 to 135 cm (4 ft 1 in to 4 ft 5 in)

Result 1 is good—the dash is saying the range is from 1 to 2, and the unit is not part of that so the space before the unit is not relevant. Result 2 is not good because there are spaces in the output range. Result 3 shows the workaround. I'll think about how much overhead would be involved in having the module automatically add a space because it looks like there are over 80 such converts in articles. That won't be fast. Johnuniq (talk) 02:56, 14 August 2014 (UTC)

Using "to" in place of the dash is a sensible workaround I hadn't considered. – Arms & Hearts (talk) 16:44, 16 August 2014 (UTC)

New volume

For Track ballast#Quantities {{convert|1700|cuyd/mi|m3/km|abbr=on}} 1,700 cu yd/mi (810 m³/km) Peter Horn User talk 01:57, 16 August 2014 (UTC)

Done; that should work now. Johnuniq (talk) 03:01, 16 August 2014 (UTC)

Thanks a million. Peter Horn User talk 00:40, 17 August 2014 (UTC)

More Protection

I asked for more protection [1]. Reasoning:

Full protection please. Current is TE level (with 650k transc's). I request this for self-protection (I have TE access). I am editing heavily in the support pages: /doc, subpages, examples, old versions. This could easily lead to a save-by-mistake (throwing 650k pages in the WP:JQ, and not bug-free knowing me). While we are at it and for the very same reason, one could protect Module:Convert (edit | talk | history | links | watch | logs) and its /data subpages (but not module:Convert/extra).

-DePiep (talk) 19:47, 17 August 2014 (UTC)

Ampere-hour

Template is missing Ampere-hour / Electric charge units. SkywalkerPL (talk) 11:01, 17 August 2014 (UTC)

The full list of units includes A.h, but there's not much to convert it to. Examples:

• {{convert|2|A.h|coulomb}} → 2 ampere hours (7,200 C)
• {{convert|2|A.h|coulomb|abbr=on}} → 2 A⋅h (7,200 C)
• {{convert|2|A.h|coulomb|abbr=off}} → 2 ampere hours (7,200 coulombs)

Johnuniq (talk) 11:50, 17 August 2014 (UTC)

Oh... so how come I can't find it in documentation? Do CTRL+F and search for Ampere or Ah or A.h - can't find anything. SkywalkerPL (talk) 10:37, 18 August 2014 (UTC)

There are 1100 units so it's not really possible to list them all on the documentation visible at Template:Convert. That documentation includes "See also: complete Convert/list of units" and I just added a link at that list to the really full list that I mentioned above. Another way to find that is with the "See Help:Convert for up-to-date and more complete information" note at the top—that page links to a units page which also links to the full list. Any ideas on improving the docs are welcome. Johnuniq (talk) 12:26, 18 August 2014 (UTC)

Converting multiple input values in feet and inches to metres

The subject line says it all, I guess; I can't figure out how to cleanly use the template to convert multiple output values of feet and inches into metres. This functionality is needed at List of works by Oldenburg and van Bruggen; the only way I've figured out how to do it is by using metres as the input unit and disp=flip to swap the input and output units, which (a) is incredibly tedious and (b) produces monstrosities ike 37 ft 0 in. Any help would be appreciated. Graham87 02:49, 27 August 2014 (UTC)

Sorry, but ranges of input multiple units are not supported. One reason is that much more than feet and inches can occur (for example, a length might use miles, yards, feet, inches). However, I'm just looking at convert and I'll remind myself of how difficult a fix would be. I'll ping you if anything good happens. One ghastly workaround would be as follows (I am not recommending this!):

• {{convert|23+6/12|x|24+11/12|x|10+11/12|ft|m|abbr=on}} → 23+6⁄12 ft × 24+11⁄12 ft × 10+11⁄12 ft (7.2 m × 7.6 m × 3.3 m)

Johnuniq (talk) 03:36, 27 August 2014 (UTC)

Wow! Yeah, that's probably not the best, either. :-) Graham87 04:04, 27 August 2014 (UTC)

I'm thinking about what would be involved in implementing ranges of input multiple units. There's quite a bit of complexity, so I'm not sure how far I'll go. One problem is that the normal syntax of convert would become unmanageable for the user and also for convert. If someone can write {{convert|2|ft|3|in|x|4|ft|6|in}} they might expect a mixture of units to work, such as {{convert|2|ft|3|in|x|4|yd}} and the latter is definitely not going to happen for a long time.

Therefore, I was contemplating a new syntax using colons and spaces as delimiters. The idea of the colon is that it is a character that should not occur in an input value, so convert can easily detect when the new syntax is used. Any views on the following?

• {{convert|3:6+1/2 x 4:11 x 9:8 ft:in|m}}

The colons and spaces must be exactly as shown. The meaning is

3 ft 6+1⁄2 in by

4 ft 11 in by

9 ft 8 in

This feature would be rarely used, and the proposed syntax is pretty disconcerting, so I'm not sure if it's worthwhile. Another complication is that people might want a measurement with no feet or with no inches. I was thinking of the following syntax (both these would give the same result; not sure how hard implementation would be):

• {{convert|3:6+1/2 x :11 x 9: ft:in|m}}
• {{convert|3:6+1/2 x :11 x 9 ft:in|m}}

That is 3 ft 6+1⁄2 in by 11 in by 9 ft. Any thoughts? Johnuniq (talk) 03:51, 29 August 2014 (UTC)

A nice feature is that spaces are used, not pipes. That makes the input format more editor friendly! (because: more into write-what-you-expect-to-see). Might be nice for single-unit input too. -DePiep (talk) 16:25, 29 August 2014 (UTC)

Adding: why not add a parameter? Like |input_has_multiple_units=yes → treat number as doubles (triples). Still requires the colon separator, but I have the feeling it fits the grander scheme. (Maybe even, wasn't it old English writing "12/5" for 12 ft 5 in? That could allow the slash, given that the parameter is set). -DePiep (talk) 19:41, 30 August 2014 (UTC)