Template talk:Convert/Archive 1

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

A discussion in July 2020 (permalink) gave the result:

  • The year/month archiving system for 2007 to 2019 will be retained.
  • The index for 2007 to 2019 will be moved to this page.
  • Archives starting in 2020 will use the more common "Archive 1" system.

The rationale was that the amount of discussion is greatly reduced from earlier years and it would be desirable for a year's worth of discussion to be archived on one page rather than twelve. Johnuniq (talk) 01:18, 21 July 2020 (UTC)


Typographic length units

It seems there is no support for points, picas etc. yet. Abbreviations can be a bit iffy, because pt can mean picoton or pint (different dimension) and pc (i.e. pica = 12 point) also stands for parsec (same dimension). Furthermore, pt means something different in Tex (100/7227 in) than in CSS (1/72 in; bp in Tex). Besides the Postscript or DTP point, 1 pt = 1/72 in, I would also add quarter-millimeter q = 0.25 mm, Didot point dd = 0.375 mm or 0.376065 mm or 1/2660 m or 254/675 mm, cicero cc = 12 dd, twip = 1/20 pt. — Christoph Päper 00:23, 29 December 2019 (UTC)

Isn't a quarter 0.2286 mm? Hawkeye7 (discuss) 00:43, 29 December 2019 (UTC)
That would be 1⁄4000 yard. Nothing I've ever seen being used. — Christoph Päper 13:02, 2 January 2020 (UTC)
and bp is a common abbreviation for basis point, 0.01%. So if these are to be done then it needs to require the whole word as input even if abbr=on is valid for output. --John Maynard Friedman (talk) 01:18, 29 December 2019 (UTC)
Since Tex's big point (bp) is now considered the default point sizes, the abbreviation should not be used anyway. — Christoph Päper 13:02, 2 January 2020 (UTC)
Please start by picking one or two of the proposed units and giving examples of how convert would be used with them. The examples should include a link to a section in an article and some text in the article where convert would be used. Johnuniq (talk) 04:27, 29 December 2019 (UTC)

"2 × 3 cm²" instead of "2 × 3 cm" (xx) and "2 cm × 3 cm" (x)

The documentation notes that |xx| (as in "2 × 3 in (5.1 × 7.6 cm)" vs. "2 in × 3 in (5.1 cm × 7.6 cm)") is deprecated because it does not conform to Wikipedia's Manual of Style (nor international standards). However, there does not seem to be an option to get the acceptable notation with area units: "2 × 3 in² (5.1 × 7.6 cm²)". I believe this should be added, but I'm not sure how. Another, less preferable variant would use parentheses: "(2 × 3) in×in ((5.1 × 7.6) cm×cm)". — Christoph Päper 13:13, 2 January 2020 (UTC)

Sort value for disp=table

When using |disp=table or |disp=tablecen with products like 2|x|3 or 2|by|3, the template should add an automatically calculated sort value in the data-sort-value attribute of the td table cell element. — Christoph Päper 13:22, 2 January 2020 (UTC)

No it shouldn't. I want to see compound sizes sorted on first value, then second value, not on their product. Compare:
  • 3 x 4
  • 3 x 5
  • 3 x 6
  • 4 x 4
  • 4 x 5
  • 4 x 6
with:
  • 3 x 4
  • 3 x 5
  • 4 x 4
  • 3 x 6
  • 4 x 5
  • 4 x 6
--RexxS (talk) 22:49, 2 January 2020 (UTC)
Well, then the exact sort key should depend on the value of the sortable parameter:
  • off: no explicit sort key
  • on: default sort key, same as either product or first
  • product: sort by the result of the multiplication of two or three numeric values
  • first, 1st, 1, 12, 123: sort key is the first numeric value, possibly followed by the other(s)
  • second, 2nd, 2, 21: sort key is the second numeric value, possibly followed by the other of two
  • third, 3rd, 3, 321: sort key is the third numeric value, possibly followed by the others of three
  • min: sort key is the smallest of up to three numeric values, perhaps secondary sort by the medium of three values
  • max: sort key is the largest of up to three numeric values, perhaps secondary sort by the medium of three values
  • avg, mid: sort key is the arithmetic mean, i.e. the average, of up to three numeric values; usually yielding the same sort order as product
— Christoph Päper 14:16, 3 January 2020 (UTC)
Templates are supposed to do reasonable things that mostly work as would be expected. Is there an example of a table in an article where any of these complications would be useful? Johnuniq (talk) 23:03, 3 January 2020 (UTC)
probably in the uses of Template:Size which generates its own sort key. Frietjes (talk) 15:50, 4 January 2020 (UTC)
None of the tables that use the "Size" template are currently set to sortable though. -- WOSlinker (talk) 16:14, 4 January 2020 (UTC)

Using double measurements in feet and inches

If you have, say, a rectangle 11 ft 8 in by 7 ft 4 in and want to put its dimensions into a single template, is there any way of doing what I would intuitively want to write as {{convert|11|ft|8|in|by|7|ft|4|in|m}}, or is this simply not supported by the template? Archon 2488 (talk) 12:40, 22 January 2020 (UTC)

Sorry, it's not supported. The syntax that is supported allows the input to mix numbers and ranges ("by", "x", and more) followed by one input unit, such as:
  • {{convert|2|by|3|by|12|ft|m}} → 2 by 3 by 12 feet (0.61 by 0.91 by 3.66 m)
I looked at handling ft/in but it's a nightmare and would require completely new syntax. Another limitation is that sometimes it would be convenient to say that something is 2 inches by 3 feet but that is not supported because it's two different units. Johnuniq (talk) 01:29, 23 January 2020 (UTC)

Photometry units

I haven't been able to find any documentation about support for photometry units (lumen, candela, etc). Is there any plan to add support for these? Archon 2488 (talk) 12:38, 22 January 2020 (UTC)

My memory of photometry units is rusty. Among the SI units, are there any units that can be converted amongst one another without making some assumption, such as assuming a light source emits equally in all directions?
Also, are there any non-SI units still in use, outside of historical documents? Jc3s5h (talk) 19:17, 22 January 2020 (UTC)
As with other SI units, you would not convert between them, because there is one unit per dimension (luminous intensity, luminous flux, etc). There are still non-SI units that I encounter occasionally, like the foot-Lambert and candlepower – it occurred to me that it would be useful to have standard conversions of these to SI, if possible. Archon 2488 (talk) 12:43, 23 January 2020 (UTC)

Rounding for decimal values

I would like to know whether there is a way to calculate to the nearest multiple of 5 in case of decimal numbers. For example {{convert|10|yd|m|2}} gives out 10 yards (9.14 m). Is it possible to get 9.15 m (as used by the International Football Association Board for the penalty kick arc)? In this case |round=5 doesn't work. Thanks in advance.--Carnby (talk) 13:24, 30 January 2020 (UTC)

Sorry, that can't be done in convert. 10 yards = 9.144 m exactly and you appear to need round=0.05. Is there an article explaining this and/or showing where it would be needed? Currently convert supports round=0.5 and I suppose it could do 0.05 if really needed. Johnuniq (talk) 22:48, 30 January 2020 (UTC)
Possible workaround, which may actually be what IFAB does anyhow: {{convert|9.15|m|yd|0|order=flip}} which gives out 10 yards (9.15 m).  Mr.choppers | ✎  02:26, 31 January 2020 (UTC)
Thanks Mr.choppers, that's a good idea. However, I changed the deprecated disp=flip to order=flip! We're trying to get rid of the former. Johnuniq (talk) 02:52, 31 January 2020 (UTC)
Update noted, thanks.  Mr.choppers | ✎  03:08, 31 January 2020 (UTC)
The article is Penalty kick (association football). I will try the workaround. Thanks anyway.--Carnby (talk) 07:30, 31 January 2020 (UTC)

Using conversions in a Table

Hi, I have been trying to use disp=table in cells that sit across several rows, and this is what happens:

  kilograms pounds stone and pounds
Why??? style="text-align:right;"|10 22 1 st 8 lb
some text here

Any way to get "rowspan" to also apply to the output? Thanks,  Mr.choppers | ✎  02:47, 30 January 2020 (UTC)

@Mr.choppers: The following is a very minor rearrangement of the above.
  kilograms pounds stone and pounds
Why???
10 22 1 st 8 lb
some text here
Is that what was wanted? The examples at Help:Convert#Tables might be useful. Also, to see exactly what the convert outputs, paste it into Special:ExpandTemplates. That would show why it gives the result in your example. Johnuniq (talk) 04:16, 30 January 2020 (UTC)

@Johnuniq: - No, I was looking for output to be displayed across two rows. I realize that my attempted example was non-functional (I didn't test it first, my bad), so here is what I want the table to look like (left) and what happens when I use the disp=table function (right):

Manual conversion
  kilograms pounds
  10 22
 
Using template
  kilograms pounds
  style="text-align:right;"|10 22
 

I can make it work manually, I was just hoping to be able to use the template (the automatic alignment is nice, for instance). Thanks.  Mr.choppers | ✎  04:43, 30 January 2020 (UTC)

Sorry, all you can do is the ugly business of repeating the convert, once to get the kilograms value and a second time for the pounds. Convert has a seldom-used trick from May 2015, namely stylein and styleout. As the example at that link shows, you can set the style for the input and output, but there is no equivalent for rowspan. Johnuniq (talk) 06:05, 30 January 2020 (UTC)
Figured, thanks. But stylein and styleout may prove useful in other ways. Cheers,  Mr.choppers | ✎  13:11, 30 January 2020 (UTC)
I think I see what is happening. |disp=table generates

10

|22

But what we really want in this case is

10 || 22

John, is it possible to add |disp=table2 that puts out double bars on the same line instead of single bars on separate lines?  Stepho  talk  21:47, 31 January 2020 (UTC)
When I translated the old template to the module I spent a long time wondering why convert outputs two lines rather than the one-line version with double pipes ||, and whether there was any difference. I decided to stick with what the old system did in case certain usages in tables required the two-line version. I have never noticed a difference and a quick test now does not show any difference.
I replaced {{convert|10|kg|lb|disp=table}} in the table above with what the one-line output would be, namely style="text-align:right;"|10||style="text-align:right;"|22. Preview shows no difference to the table. Johnuniq (talk) 22:42, 31 January 2020 (UTC)
Right. The issue here is not one- or two-line table syntax. What Mr.choppers want is the ability to output
rowspan="2" | 10
| rowspan="2" | 22
or the equivalent
rowspan="2" | 10 || rowspan="2" | 22
In both cases, table syntax requires a rowspan between the two values to set the rowspan for the second cell but this is currently not possible with convert. It would require a new parameter. PrimeHunter (talk) 01:27, 1 February 2020 (UTC)
Thanks, all! I'll survive, I guess...  Mr.choppers | ✎  06:58, 1 February 2020 (UTC)

Protect from conversion

Is there a template which protects numbers from being converted? Example: the Standard Ten is named after the tax horsepower rating, so one has to write "10 hp" a lot. But then well-meaning editors convert this to kilowatts, even though a tax hp ≠ actual horsepower. Similarly, car wheels are nearly always measured in inches (exception here), and are never expressed in millimetres. Is there a nifty template I can apply to this sort of data or should I just add hidden messages at all these instances? I feel that bots don't care much about my messages, so I was hoping for something similar to Template:Proper name. I am sure that these are not the only examples of nominal values which should not undergo conversion. Best,  Mr.choppers | ✎  06:57, 1 February 2020 (UTC)

Your solution of using {{text}} looks good and should slow them down. I don't think there is anything better. Johnuniq (talk) 08:28, 1 February 2020 (UTC)
I predict that will be too subtle to prevent human meddling, and suggest you use <! -- --> comments as well to explicitly explain the situation. EEng 08:54, 1 February 2020 (UTC)
Damned humans.  Mr.choppers | ✎  18:15, 1 February 2020 (UTC)
Human meddling. EEng 07:27, 2 February 2020 (UTC)

G-force

Would it be possible to add a conversion for g-force? It would essentially be the same as {{convert|1|g0}} but would display as g and link to the g-force article. Thanks! — Huntster (t @ c) 23:14, 2 February 2020 (UTC)

@Huntster: Sure but I'm not doing any thinking! It is customary to ask for an example of a convert that would be used in an article. Also, g is gram, so what unit code should be used? Perhaps g-force would be clearest? The name for g0 is standard gravity. What name (abbr=off) should be used? You're saying the symbol (abbr=on) should be g so perhaps g-force could be the name? Or gravitational force equivalent? Johnuniq (talk) 02:50, 3 February 2020 (UTC)
Johnuniq, I knew I forgot something. I'm currently working on cleaning up Genesis (spacecraft), which includes 3 g (29 m/s²) and 30 g (290 m/s²). g-force is the logical unit code, and g (with italics) is the abbreviation, but you never see this as anything but the abbreviation. The long form can be g-force/g-forces, but it would be really strange to see it written like that anywhere. Is there a way to make the abbreviation the default, requiring abbr=off to be used to see the long form?
Additionally, for the g0 unit, the abbreviation should use the code ''g''<sub>0</sub>. — Huntster (t @ c) 03:34, 3 February 2020 (UTC)
Doesn't the conversion template already do this? {{convert|3|g0|abbr=on}} givers 3 g0 (29 m/s2) Hawkeye7 (discuss) 03:41, 3 February 2020 (UTC)
Hawkeye7, the 0 in g0 should not be italicized. — Huntster (t @ c) 04:37, 3 February 2020 (UTC)

I added two temporary units for testing. g0-temp shows how g0 will work in the next release. g-force is the new unit. Re the latter, there is no way to default to abbr=on and only show a unit name if abbr=off is used so the new unit uses g for the symbol and name. Examples:

Let me know if this works. Assuming g-force is used it will be changed to a permanent unit in the next release. Johnuniq (talk) 06:12, 3 February 2020 (UTC)

Johnuniq, g-force has been applied to the Genesis article and looks great. g0 also now looks exactly as it should. Thanks! — Huntster (t @ c) 07:50, 3 February 2020 (UTC)

eXha

Appears to have problems. E.g., {{convert|1000000000|e6ha}} 1,000,000,000 million hectares (2.5×109×10^6 acres) Cheers. Lfstevens (talk) 20:50, 4 February 2020 (UTC)

That's an ugly side-effect of the fact that the default output for e6ha is e6acre. It works well for "reasonable" numbers:
  • {{convert|125|e6ha}} → 125 million hectares (310×10^6 acres)
  • {{convert|125|e6ha|abbr=off}} → 125 million hectares (310 million acres)
The output unit is e6acre which means the output is always expressed in terms of millions of acres. If the number of millions is too large, convert uses scientific notation with the unfortunate result shown above. The solution is to specify the wanted output unit, for example, e15acre or just acre:
  • {{convert|1000000000|e6ha|e15acre}} → 1,000,000,000 million hectares (2.5×10^15 acres)
  • {{convert|1000000000|e6ha|acre}} → 1,000,000,000 million hectares (2.5×1015 acres)
The difference between the last two is seen with abbr=off:
  • {{convert|1000000000|e6ha|e15acre|abbr=off}} → 1,000,000,000 million hectares (2.5 quadrillion acres)
  • {{convert|1000000000|e6ha|acre|abbr=off}} → 1,000,000,000 million hectares (2.5×1015 acres)
Johnuniq (talk) 22:19, 4 February 2020 (UTC)
Thanks! Lfstevens (talk) 02:31, 5 February 2020 (UTC)

Energy units linking to atmosphere

The module was last updated in May 2019 and I'm planning a new update soon to cover some unit changes discussed since then. The first issue is that several energy units link to Atmosphere (unit) (if lk=on is used) but that article is about pressure and seems irrelevant. No units currently link to Standard cubic foot which concerns a volume (actually, an amount) of gas.

The energy units that link to Atmosphere (unit) follow (full list is here). 

unitcode     default  symbol                  name1

ccatm        mJ       cc⋅atm                  cubic centimetre-atmosphere
cm3atm       mJ       cm<sup>3</sup>⋅atm      cubic centimetre-atmosphere
cufootatm    kJ       cu&nbsp;ft&nbsp;atm     cubic foot of atmosphere
cuftatm      kJ       cu&nbsp;ft&nbsp;atm     cubic foot of atmosphere
cuydatm      kJ       cu&nbsp;yd&nbsp;atm     cubic yard of atmosphere
GLatm        GJ       GL⋅atm                  gigalitre-atmosphere
Glatm        GJ       Gl⋅atm                  gigalitre-atmosphere
impgalatm    J        imp gal⋅atm             imperial gallon-atmosphere
kLatm        kJ       kL⋅atm                  kilolitre-atmosphere
klatm        kJ       kl⋅atm                  kilolitre-atmosphere
Latm         J        L⋅atm                   litre-atmosphere
latm         J        l⋅atm                   litre-atmosphere
m3atm        kJ       m<sup>3</sup>⋅atm       cubic metre-atmosphere
MLatm        MJ       ML⋅atm                  megalitre-atmosphere
Mlatm        MJ       Ml⋅atm                  megalitre-atmosphere
mLatm        mJ       L⋅atm                   millilitre-atmosphere
mlatm        mJ       l⋅atm                   millilitre-atmosphere
scc          mJ       scc                     standard cubic centimetre
scf          kJ       scf                     standard cubic foot
scfoot       kJ       scf                     standard cubic foot
scy          kJ       scy                     standard cubic yard
sl           J        sl                      standard litre
USgalatm     J        US&nbsp;gal⋅atm         US gallon-atmosphere

I think these units relate to how much energy can be obtained by burning a certain amount of a certain fuel. The issue was raised by Ws1920 for scf here.

What should the link be for the above energy units? Presumably Atmosphere (unit) is wrong? Should it be changed to Standard cubic foot? Johnuniq (talk) 08:37, 4 February 2020 (UTC)

Thanks for your efforts working on the highly valuable convert-template. Seeing the full list, I can understand Atmosphere was chosen as the link for all of them. As it seems to be quite some variation on what the standard is for pressure and temperature, also within the same unit and industry, a suggestion could be to link them all to Standard conditions for temperature and pressure. Not knowing the amount of work involved, I would also suggest to switch from treating them as energy units, and rather threat them as volume conversions as most people can agree on the standard volume of the units, but it is not as easy to agree on the (exact) pressure and temperature value for the units. -- Ws1920 (talk) 13:53, 4 February 2020 (UTC)
Maybe not easy to implement directly in the convert template, but as an example, I vote for the first example in the following. Example 1: 255 cubic feet (7.2 cubic metres) of gas per day at standard conditions rather than example 2: 255 standard cubic feet (730 kilojoules) of gas. -- Ws1920 (talk) 14:19, 4 February 2020 (UTC)
I just did a quick test and it is likely that none of these units are used in articles. So a more radical solution might be to remove all these units and add back any where the removal has caused a problem. Anyone wanting a unit added back would need to specify its details. Johnuniq (talk) 22:56, 4 February 2020 (UTC)
I like the idea of removing them all. Ambiguous jargon is better explained with prose rather than templates. Jc3s5h (talk) 23:13, 4 February 2020 (UTC)
I support the suggestion to remove them all. I replaced some articles using "standard cubic foot" conversion with the "standard conditions" suggestion above some time ago. -- Ws1920 (talk) 17:59, 7 February 2020 (UTC)

I plan to remove all the above listed units, along with scf2 and scfoot2 that were temporarily added on 9 December 2019 to Module:Convert/extra as tests (those units have not been used in articles). Johnuniq (talk) 06:57, 19 February 2020 (UTC)

Horizontal fraction bar in output rather than input unit?

This template's notes say (in the Output with horizontal fraction bar section) that using a double slash (//) returns a horizontal bar fraction: 

   {{convert|1//2|in|mm|1}}→ 1/2 inch (12.7 mm)
   {{convert|2+1//2|in|mm|1}} → 2+1/2 inches (63.5 mm)

That's lovely, but it only addresses the input value. What is to be done if the input value is metric (say, 12.7 mm) and what I want is the converted figure to be one-half inch expressed as a fraction with a horizontal divider bar? 173.180.13.37 (talk) 03:30, 20 February 2020 (UTC)

The trick is to use a negative number for frac (the dash sort-of suggesting a horizontal fraction bar):
  • {{convert|12.7|mm|frac=-2}} → 12.7 millimetres (1/2 in)
Johnuniq (talk) 04:20, 20 February 2020 (UTC)
Ah! Thank you. Is that in the documentation and I just didn't see it? Or should it perhaps be added? 173.180.13.37 (talk) 05:22, 21 February 2020 (UTC)
I can't see it there, and yes it should be added although I don't think any converts in articles use this feature. Johnuniq (talk) 06:22, 21 February 2020 (UTC)
 Done (there is at least one article using this feature) 173.180.13.37 (talk) 03:48, 22 February 2020 (UTC)

Speed isn't always a manifestation of energy waste

Speed isn't always a manifestation of energy waste

The conversion template page appears to be slanted towards fuel efficiency, ignoring rate of speed in favour of fuel consumption rate in examples of rates (x per y). This slant shouldn't be applied to wind speed. Note that wind is not a consumer of fossil fuels. Indeed, the wind is a manifestation of solar energy, and it will not be convinced to switch to a more politically correct fuel source, if such exists. Not everything fast causes climate change. Please add some speed examples to your conversion templates page (and, better yet, to your Help:Convert page, as well), so that other novice or occasional conversion templaters won't waste time as I did. Thanks--Quisqualis (talk) 01:00, 6 February 2020 (UTC)

Sorry, what? EEng 18:05, 7 February 2020 (UTC)
It appears the OP wanted more examples of converting speeds in this template's documentation. Presumably they jumped directly to the 'per' units: kg/hl, miles per gallon section, missing the All units section, in which speeds are discussed. - dcljr (talk) 05:29, 20 February 2020 (UTC)
OK, but what’s with the stuff about fossil fuels? EEng 10:25, 20 February 2020 (UTC)
Off-topic rambling, I assume. - dcljr (talk) 04:36, 22 February 2020 (UTC)

Display a flipped conversion in units excluding the input unit

I wondered if anyone can tell me if (and if so, how) this template can be used to display a speed which, from the source is known to be about 30 m/s, as "70 mph (110 km/h)". Thanks for any help. -- DeFacto (talk). 18:23, 22 February 2020 (UTC)

@DeFacto: The trick is order=out. Here are converts with various rounding options. The first line show the actual values.
  • {{convert|30|m/s|mph km/h|1|abbr=on}} → 30 m/s (67.1 mph; 108.0 km/h)
  • {{convert|30|m/s|mph km/h|abbr=on|order=out}} → 67 mph (110 km/h)
  • {{convert|30|m/s|mph km/h|abbr=on|order=out|round=5}} → 65 mph (110 km/h)
  • {{convert|30|m/s|mph km/h|abbr=on|order=out|round=10}} → 70 mph (110 km/h)
Johnuniq (talk) 23:22, 22 February 2020 (UTC)
Perfect - exactly what I wanted - thanks very much Johnuniq, what an incredibly versatile tool! -- DeFacto (talk). 23:29, 22 February 2020 (UTC)

Inconsistent abbreviation

A construction like {{convert| 8|km|0}} produces 8 kilometres (5 mi). What I would expect is either 8 km (5 mi) or 8 kilometres (5 miles), not this odd mixture of unabbreviated and abbreviated, which looks amateurish. Of course I know we can get round it using {{convert| 8|km|0|abbr=on}} [for 8 km (5 mi)], or {{convert| 8|km|0|abbr=off}} [for 8 kilometres (5 miles)], but that is really not the point, it requires extra work just to do the right thing. The default when abbr is not used should be one or the other, not somewhere in between. Comments? --Red King (talk) 00:01, 22 February 2020 (UTC)

Convert follows MOS:UNITNAMES and has been the way it is forever. Readers come from all over and all ages and some of them may not know what km and kg are. If wanted, use {{cvt}} for an equivalent to {{convert}} but where cvt uses abbr=on. Johnuniq (talk) 00:35, 22 February 2020 (UTC)
@Red King: When we write 8 kilometres on first use, we cater for the possibility that the reader may not be familiar with the abbreviation km if they only saw that – of course, this is far more likely with uncommon units like 8 millisiemens (abbreviation 8 mS).
When we add a unit conversion to an article – like 8 kilometres (5 mi) – the converted value is for the benefit of readers who are much more familiar with the converted unit than the original unit. But if they are familiar enough with the converted unit to need the value expressed in that converted unit, it is blindingly obvious that they will also be familiar with that unit's abbreviation. There is virtually no usage case for having converted units spelled out in full. Hope that makes clearer the logic behind our "amateurish" convention, and settles your mind about why we don't do the "right thing" by default. --RexxS (talk) 03:52, 22 February 2020 (UTC)
Ah, ok, I see. I approached it from a UK perspective, where there is still a culture war going on. Consequently, parity of esteem (or equality of misery!) must always be demonstrated. The context was an FAC peer review, so I wanted to be sure it was right. Request withdrawn. --Red King (talk) 12:56, 22 February 2020 (UTC)
I feel your pain, Red King. I spent from 1973 to 1997 teaching in Secondary schools in the West Midlands. We still had maths textbooks using £:s:d. --RexxS (talk) 03:13, 23 February 2020 (UTC)

Add an area unit: feddan

Hi, all. I would like to request the addition of the area unit feddan (or feddan masri lit. 'Egyptian feddan', for more details about the history of the unit, see this website). This is the last non-SI unit still used in Egypt. As an official source, this recent press release by the Egyptian CAPMAS (a government agency) lists the area of cultivated land in Egypt as 9.2 million feddans. The unit is also used in Sudan, Syria and Oman. (source1 and source2). The addition of this unit was approved in August 2015 but it appears that it was removed later. It should be added with the other non-SI area units to this table. Conversion:

The unit can be used on many articles such as: Economy of Egypt, Agriculture in Egypt, etc. Note also that Egypt was an important country when studying the history of agriculture. Thank you. --Meno25 (talk) 15:59, 4 March 2020 (UTC)

The article says: In Syria, the feddan ranges from 2295 square metres (m²) to 3443 square metres (m²). What value could be legitimately assigned for the conversion? Tarl N. (discuss) 23:50, 4 March 2020 (UTC)
Units like this are a problem. Your size.com link shows a feddan is 4,200.833 square meters in Egypt after 1830 (varying wildly before then), and from 2,295 to 3,443 square meters in Syria in the 20th century (varying wildly before then), and 4050 square meters in Yemen. Thanks for finding the previous discussion at the August 2015 archive. Our feddan article has the above claim that a feddan is exactly 4200 square metres, but ref 1 suggests it is the 4,200.833 square meters size.com value for Egypt.
Is convert needed for this unit? Why not do a manual conversion using what factor seems to be appropriate for the usage? The unit is only useful in convert if it will be useful in multiple articles. I can add it and see how it used later, but is it 4,200 or 4,200.833, and what about usage for areas outside modern Egypt? Johnuniq (talk) 01:13, 5 March 2020 (UTC)

Feet and Inches or Feet and a decimal

  1. {{convert|1.28|m}} 1.28 metres (4 ft 2 in)
  2. {{convert|4.22|m}} 4.22 metres (13.8 ft)

On my disply (1) returns 1.28 metres (4 ft 2 in) (2) returns 4.22 metres (13.8 ft) Why are they not consistent? -- PBS (talk) 18:10, 21 January 2020 (UTC)

OK I found the answer in Template talk:Convert/Archive February 2015#Convert metric to feet and inches?

"In fact, ftin is the default output for m for input values above 0 and below 3" Johnuniq (talk) 03:36, 24 February 2015 (UTC)

Indeed it is in the section Module:Convert/documentation/conversion_data#Length 24 lines down ten columns in.

Why the built in inconsistency? It is a real got-yer and not the behaviour of least surprise. -- PBS (talk) 18:20, 21 January 2020 (UTC)

I don't see any call for the use of decimals with the old measurements. The default should consistently be feet and inches. Hawkeye7 (discuss) 18:34, 21 January 2020 (UTC)
I do not know exactly why it is the case, but I would presume it's due to a person's height. Zero to three metres is the expected range for heights, in imperial they are always in feet and inches and not decimal feet.
Well, 'expected range' as in the upper and lower possible integer bounds for any expected input; its not as if you see a 2.99m or a 1cm person walking down the street. --Voello talk 18:46, 21 January 2020 (UTC)
Looking through the history it seems it was added here in 2009. --Voello talk 19:32, 21 January 2020 (UTC)
Yes, the background being that certain topics use m for a person's height and it was considered desirable to convert that to ftin by default. Of course it's the default that we talking about and the output can be whatever is wanted. The default is useful to do what works best in most cases if no output unit is specified. Johnuniq (talk) 22:00, 21 January 2020 (UTC)
I think WP should take out insurance on you to cover the costs of finding someone to care for and feed {convert} should something happen to you. EEng 22:16, 21 January 2020 (UTC)

I came across it in a new article I have created called Widebeam. There there are draft measurements of under 4 feet and lengths of about 70 feet. I will go through and fix then to be one or the other. However I agree with User:Hawkeye7 comment "I don't see any call for the use of decimals" with feet (ie the default ought to be ftin for all of them). However I think that either decimal feet or feet and inches for all is preferable to the current inconsistency. -- PBS (talk) 11:46, 22 January 2020 (UTC)

Here is another inconsistency (from the same article):
  • {{convert|2.16|to|3.24|m}} and those over {{convert|3.24|m}}
  • 2.16 to 3.24 metres (7 ft 1 in to 10 ft 8 in) and those over 3.24 metres (10.6 ft)
If I had chosen to write this the opposite way around then the result is more consistent:
  • {{convert|3.24|to|2.16|m}} and those under {{convert|3.24|m}}
  • 3.24 to 2.16 metres (10.6 to 7.1 ft) and those under 3.24 metres (10.6 ft)
-- PBS (talk) 11:56, 22 January 2020 (UTC)
For an subject whose roots are in the 18th or 19th century and using definitions based in imperial units, would it not make more sense to use imperial first and add the metric in parenthesis? {{convert|7|ft|1|in|m}} => 7 feet 1 inch (2.16 m) looks better IMHO. I know we are all being forced into SI these days, but this is a historic topic, not 21st C research! Martin of Sheffield (talk) 12:42, 22 January 2020 (UTC)
As it is off topic I have posted a reply on Talk:Widebeam -- PBS (talk) 14:55, 22 January 2020 (UTC)
While it might make sense, the MOS says to use metric first. See WP:UNITS. Hawkeye7 (discuss) 18:59, 22 January 2020 (UTC)
(edit conflict) One person's "inconsistency" is another person's "functionality", and I generally prefer to see metres converted to feet and inches for things that are the same size as me, and decimal feet for things that are much bigger. Nevertheless, if consistency is paramount, you can simply specify the output units you want:
  • {{convert|2.16|to|3.24|m|ftin}} → 2.16 to 3.24 metres (7 ft 1 in to 10 ft 8 in)
  • {{convert|3.24|m|ftin}} → 3.24 metres (10 ft 8 in)
  • {{convert|2.16|to|3.24|m|ftin|order=flip}} → 7 feet 1 inch to 10 feet 8 inches (2.16 to 3.24 m)
Doesn't that solve the issues? --RexxS (talk) 15:02, 22 January 2020 (UTC)
No it does not. The functionality is the ability to change something by using parameters like "ftin" and "order=flip" to change the output, its not have the template it changing the output on an arbitrary amount. The logic is that if the conversion is to {{convert|80|kg}} then it should display in stones and pounds because the weight is under 30 stones, or if something is 4 inches or higher and less than 81 inches it ought to be in hands and inches (because I measure horses that way). Why on earth do you "prefer to see metres converted to feet and inches for things that are the same size as me, and decimal feet for things that are much bigger"? Is it a cultural thing? -- PBS (talk) 16:46, 22 January 2020 (UTC)
Decimal feet vs ft & in is a cultural thing, but the amount of contextual information needed to decide when to use which is vastly beyond the scope of a unit conversion algorithm. Old British engineering (e.g. the Titanic) would have used feet and inches; a lot of US engineering uses decimal feet. Stones exist for older British people to talk about their body weight; the unit, in practice, serves no other purpose – because nobody talks about a piece of furniture's weight in stones (similar to hands for horses, but not other animals). Archon 2488 (talk) 17:29, 22 January 2020 (UTC)
That's the way the old measurements worked. Certain ones were preferred for different purposes. A good example is metals, where lead is in ounces, silver in troy ounces, and plutonium in grams. Hawkeye7 (discuss) 18:59, 22 January 2020 (UTC)
@PBS: I still often discuss body weights in stones and pounds, but I'm aware that my American cousins would use pounds only. That's a cultural thing and there is no obvious default in imperial units for weights that might represent human body weight. However, the functionality in the case of lengths is the ability for the template to switch defaults from ftin to ft at a predetermined value. Most uses of the template for lengths under about 3 metres will be heights of people, and for as long as I've been alive, imperial units have measured those in feet and inches. Once you start measuring larger objects such as the length of a ship, for example, it is fairly likely that you'll see a decimal representation if anything less than one foot is significant. I don't believe that is anything cultural. That's my preference and it depends on my perception of how I've seen measurements quoted, especially when I was younger. Why do prefer to see people's height measured in the same units as the length of a ship?.

I think this behavior is undesirable in a collaborative encyclopedia. Someone comes along to fix an article that they're not deeply involved with; perhaps they saw a change in some value in a reliable source, and are cleaning up places that link to that source. The editor isn't aware of the ins and outs of converting meters to feet, so isn't aware the format will change when updating a value from 2.9 m to 3.1 m. Jc3s5h (talk) 20:36, 22 January 2020 (UTC)

It was just a choice for default output unit made many years ago. It's easy to change the default to anything that's wanted. However, convert has been this way for years and changing it would be bound to upset those who like the current behavior. The idea of the default was to make convert do what people would probably want, in most cases. That way, they don't have to work out that ftin is the output unit they need. Johnuniq (talk) 01:22, 23 January 2020 (UTC)
  • This kind of surprise behavior by systems that want to reach out and wipe your butt for you is just the sort of thing you see in software-design textbooks under the heading "too-clever-by-half terrible ideas". The question is whether it's too late to fix it. EEng 21:20, 22 January 2020 (UTC)
    By too late, if you mean technically, it's a very easy change to set a new default. If you mean socially, I'm inclined to think that leaving the way it's been for ten years might be best. Johnuniq (talk) 01:22, 23 January 2020 (UTC)
    I meant socially of course. Of the cases where cm or m is the input and (currently) ft+in are the output, I'd guess that 90% are personal heights, and that almost all of those could be found by searching for {convert} with certain parameters close to words like tall or height. After inserting, into those cases, appropriate additional parameters to force ft+in output, the other 10% can be "wrong" (i.e. decimal feet where before they were ft+in) for a while until people notice and fix them. No big deal. EEng 04:05, 23 January 2020 (UTC)
    My tuppence (or 1⁄3 tanner, if you like) is that it's always best to specify the desired output format as explicitly as possible, to avoid such "surprises". The template should not, by design, make too many assumptions about what its users want, as these will quickly break down in a wide range of contexts. I find decimalised imperial units ugly and totally counterintuitive; it's not the way the units were traditionally used, and to the extent that my metric brain can process stuff like "3.15 lb", it just breaks at the stuff to the right of the decimal point – I know an ounce is about 30 grams, but WTF is 150 millipounds?. Archon 2488 (talk) 10:48, 23 January 2020 (UTC)

I don't mind which we use but the convert should avoid inconsistencie

  • {{convert|2.16|to|3.24|m}} and {{convert|3.24|m}}
  • 2.16 to 3.24 metres (7 ft 1 in to 10 ft 8 in) and 3.24 metres (10.6 ft)

I would prefer the default to be feet and inches, but would prefer feet and decimal feet to the current mix. The convert template should fail safe when using default values, so that the output displayed in an article is consistent. -- PBS (talk) 16:46, 27 January 2020 (UTC)

A "foolish consistency ..." isn't needed here. It's better to have defaults that vary with what is most likely when that is predictable: feet and inches for smaller lengths and decimal feet for longer ones. Any editor concerned with consistency above all else only has to specify the units they want:
  • {{convert|2.16|to|3.24|m|ftin}} and {{convert|3.24|m|ftin}}
  • 2.16 to 3.24 metres (7 ft 1 in to 10 ft 8 in) and 3.24 metres (10 ft 8 in)
Replace ftin with ft for decimal feet. If you don't like the defaults, you specify the units. What situation can't be catered for by that? --RexxS (talk) 23:33, 27 January 2020 (UTC)
If you don't like the defaults, you specify the units. – Sure, after you’ve spent an hour trying to understand why some rows in a table are coming out in ft+in while others, coded the same way, come out in decimal feet, all the time wondering if you’re losing your mind. Not worth it, not nearly. Is there anything else in {convert} that works this way? Does kg come out in decimal lbs for large masses, but lbs+oz for anything under 15 lb, because that might be the weight of a newborn? EEng 06:41, 28 January 2020 (UTC)
I agree with User:EEng, as that is precisely the problem I had. When ths number is only a little larger than a lenth in feet then the measurements look similar, (for example 2.16 metres (7 ft 1 in) and 3.07 metres (10.1 ft). If as User:EEng say they are entered by one editor in a table, then "after you’ve spent an hour trying to understand why some rows in a table are coming out in ft+in while others, coded the same way, come out in decimal feet, all the time wondering if you’re losing your mind. Not worth it" particularly as the template document page hides the information in an obscure place (I found it via this talk page archive) -- if it is to remain then it needs to be clearly described in its own section with an explanation as to why and examples.
However better documentation is only a sticking plaster, because if a measurement is only given in metric in an article, then someone will come along and copy-edit a section and use convert to add imperial (per MOS:CONVERSIONS). Then later another editor may come along to do some further copy-editing, read the article and see that a template called {{convert}} was used to add imperial measurements early on in the article, so not being really aware of how it works, (s)he will copy the original altering the number as appropriate. If the second {{convert}} is a scrollable distance down the article from the first, the chances are that a change to (or from) inches to decimal feet will not be noticed. This is why this template ought to fail safe, to protect the visual appearance of articles from editors who are not as familiar with the current quirks of this template as User:RexxS is. As EEng asked, I too would like to know "Is there anything else in {convert} that works this way?" -- PBS (talk) 12:56, 30 January 2020 (UTC)
As much as I love convert, it is hard enough to use for many people without it having quirky or hidden rules that make nearly identical usage come out quite different. This only makes people avoid it. The quote for 'foolish consistency' seems to decry any consistency as foolishness, as though randomness is a strength (try letting people individually choose which side of the road to drive on every morning and see how that works). The quote is more to do with stubbornness and being willing to re-evaluate.
I think people who use feet also tend to use inches in the majority of cases, so that makes for a good default. To have convert then arbitrarily (from the users viewpoint) choose decimal feet only confuses people. Far better for convert to default to feet inches but to allow the user to override it if they choose it explicitly .  Stepho  talk  22:05, 31 January 2020 (UTC)

I believe the majority view (I won't say consensus) is that the output should be consistently either ft+in or decimal feet (but not the second-guessing behavor) though there's disagreement as to which of those two is the better default, and it's unclear how much trouble it would be to change the behavior. Are we all together so far? EEng 03:56, 3 February 2020 (UTC)

I think EEng's summary is correct. As for which is more popular, it's hard to conduct a proper opinion poll, but it's easy to visit an American bricks & mortar hardware store or home center. In my experience, at a large home center, you will find around 50 rulers and tape measures calibrated in feet & inches, and one or two fiberglass tape measures, which will have inches & feet on one side, and decimal feet on the other. If you want to buy a steel tape measure with decimal feet, you will have to order it online. So product availability strongly suggests feet and inches are more popular. Jc3s5h (talk) 04:23, 3 February 2020 (UTC)
It looks like we're moving toward a consensus on making the default the same for all lengths, so I won't let my take on what's best get in the way of a consensus (i.e. something that may not be first-choice for each, but tolerable for all). Looking at where I'm most familiar with the use (infoboxes), I suggest that having feet and inches as default throughout would require less work in tidying than the other alternative. --RexxS (talk) 22:55, 3 February 2020 (UTC)
In my opinion, as someone who is British, when I see a measurement in feet (not a whole number) it is always qualified with inches, e.g. on road signs. Decimal feet, I never come across, and so I would support the mixed feet and inches units as the default. However, if it is decided to use decimal feet instead, I would definitely want all of the existing measurements of 3m and under (which default to a display of ft and in) to be converted to ftin by a bot. This is as heights of people are never expected in decimal feet, on either side of the Atlantic, and I do not believe an automated process could differentiate between a person's height and that, say, of a statue, for example. Quite frankly, in my mind, having a conversion to decimal feet is about as useful as not having one at all (for something under 3 metres). But, I do agree with the argument of having the template behave in consistent ways; especially for the sake of new and inexperienced users.--Voello talk 23:38, 3 February 2020 (UTC)

I have left it a few days to see if anyone else wished to add anything—it seems not.

@Jc3s5h your post was facinating for me. In Britain all length measures commonly sold in hardware haberdashery and stationary shops are sold with metric and imperial either on one side (eg steel measuring tapes and rulers) or metric on one side and imperial on the other (eg measuring tapes sold in habadasheries). They are always in [yards occasionally], feet and inches, I have never seen a decimal foot measure. The only place I have seen 10ths used with imperial measurements in Britain is in a road vehicle's odometer/Speedometer and Google maps which vacillates between yards and 10th of a mile. However because wood is cut in metric units, many timber merchants are unhappy selling short lengths of timber in imperial lengths (because they end up with unsellable offcuts) so some are willing to sell a colloquial "metric foot" which is 30cm or a "metric yard" (90cm) for those who can/will not think in metric measurements. The same is done with with width and bredth if the item is up to about 4x6", the merchants refer to the metric width and depth as "planed" so 2x1" planed is a actually manufactured as 50x25mm—ie about 1/64" per inch smaller than the old imperial size. With timber this works reasonably well, but is more problomatic with materials such as steel. However a similar rule of thumb is used for the length of wood screws, bolts etc.

In the pre-metric days of the '60s wood was sold in its sawn size, so that rough finished wood would indeed be 2"x3" for example, but planed wood was always undersize due to the wood removed in planing. Planed 2"x3" would be about 1+7⁄8"x2+7⁄8". The foregoing was for softwood, IIRC hardwood was finished to size. Martin of Sheffield (talk) 07:39, 15 February 2020 (UTC)

It seems to me that in this thread there is a consensus to use one consistent conversion for all lengths. Everyone who has expressed an opinion on the conversion of peoples heights favours using feet and inches, therefore that has to be the default. @Johnuniq can you and will you make the change? Further I suggest that if after the change is made if there are howles of anguish over the loss of decimal feet, then the change can be reverted and a bot can be run to make all the lenths that currently use decimal feet explicit, before remaking the change. -- PBS (talk) 18:33, 14 February 2020 (UTC)

I believe the reason long fiberglass tape measures (most often 30 m or 100 ft) are available in well-stocked home improvement centers in the US is that US land surveyors almost exclusively use decimal feet. Homeowners who wish to lay out on the ground distances contained in the survey plats or deeds of their property will find these tapes useful.
Occasionally the surveyors may use SI, since some federal and state GIS products are produced in SI. Perhaps, if threatened with sufficiently severe torture, they might produce a drawing dimensioned in feet & inches for tradesmen, but I've never seen it. Jc3s5h (talk) 19:49, 14 February 2020 (UTC)
I'm very slowly working through a list of things that need to be updated for convert (for example, see #Energy units linking to atmosphere below). Before changing the default output for m I would want to investigate how it is used. My attitude would depend on how big the impact would be. If not much, I'm happy to change it in the next update. If it's a lot I would want to at least alert appropriate wikiprojects. Johnuniq (talk) 22:39, 14 February 2020 (UTC)

Problems changing m default output to ftin

After enhancing some scripts I use, I have examined the converts that would be affected by a change in default output. I used the April 2019 database dump because that is the most recent I have.

  • As at April 2019, 128,777 converts in articles used input unit m with its default output.
  • Of those, 1,228 converts used disp=table or disp=tablecen.
  • A lot of klunkiness would result from changing the default output.
  • The converts could be fixed by inserting ft as the wanted output where needed, but that's a lot of effort.

For example, Auschwitz concentration camp#Auschwitz III-Monowitz uses the following, which would change to the second line:

  • it housed 60 barracks measuring 17.5 by 8 metres (57 ft × 26 ft)
  • it housed 60 barracks measuring 17.5 by 8 metres (57 ft 5 in × 26 ft 3 in)

Many "list" articles have tables that assume ft is the output unit. Examples:

I would be very reluctant to silently change how 128,777 converts behave without a widely advertised central discussion. By "silently", I mean that there would be no indication in an article's history that something had happened, and only a very observant page-watcher would notice that something needed to be fixed. Johnuniq (talk) 03:52, 19 February 2020 (UTC)

I'm afraid I don't feel it's settled that the right default is ft+in. In your abundant spare time, can you figure out how many uses currently give ft+in as their output? Also, I'm unclear how your stats interact with templates: there must be a zillion converts of athletes' heights in {infobox athlete} or whatever, so how would those be counted? (And there must be analogous cases for the stats you gave above.) EEng 03:20, 5 March 2020 (UTC)
Of the 128,777 converts in articles (in April 2019) that used input unit m with its default output, 12,872 give ftin as the output while 115,904 give ft. Is that what you wanted re "how many uses currently give ft+in as their output"? Re what was counted, my script looked only at {{convert}} templates in articles. I'm not sure why I didn't also consider {{cvt}}—perhaps I forgot. I can do that later. It's true that there are lots of height-like templates but I didn't worry about them because if any do the wrong thing, they can easily be edited to make the output do whatever is wanted. Moreover, I'm pretty sure that an infobox template I've seen specifies the wanted output unit, that is, the templates do not use the default. My point with the above was just to give an idea of what would need to be done (by someone else!) if the default output changes. Johnuniq (talk) 04:33, 5 March 2020 (UTC)
Yeah, my point was to not count uses within other templates, on the assumption that they're easily fixed. Any chance you can do another count (of direct uses in articles, where desired output is not explicitly forced) but distinguishing uses that within 5 words of the strings tall or height? EEng 06:09, 5 March 2020 (UTC)
There is no realistic way I can do that. My procedure is to use one set of scripts to list all converts in articles from the dump, the result being a file with article title followed by all the converts in that article (one per line). That was done in April 2019. Then a new script passes all the converts through a simulation of what Module:Convert does, patched to output results if the input unit is m and the default output needs to be looked up. I just counted the cvt templates from April 2019: 3606 use m and get ft as the default output, while 429 get ftin. In principle you could parse converts in wikitext and guess if it is one of interest but there are so many weird options that parsing is hard.
The Auschwitz example above shows the subtle nature of the problems that would arise if the default is changed from ft to ftin. The problem in that case is that someone thought "(57 ft × 26 ft)" was suitable and no one would notice the change to "(57 ft 5 in × 26 ft 3 in)" which might be unrealistically precise. Some of the list articles (examples above) would probably be ok if changed to ftin, while others wouldn't, but I would want the editors who maintain such articles to provide input on what should happen. Johnuniq (talk) 06:33, 5 March 2020 (UTC)

Taking the first measurement in the first list example List of longest runways

  • {{Convert|5500|m|disp=tablecen|0}}

removing the table parameter produces:

  • {{Convert|5500|m|0}} 5,500 metres (18,045 ft)

The 0 parameter controlling the rounding, which in this case AFAICT is the same as the default (Template:Convert#Default rounding):

  • {{Convert|5500|m}} 5,500 metres (18,000 ft)

I don't think anyone would want that changed that default to either decimal feet or feet and inches.

  • {{Convert|5500.5|m}} 5,500.5 metres (18,046 ft)

but if the default displays decimal feet then convert it:

  • {{Convert|5500.51|m}} 5,500.51 metres (18,046.3 ft) to 5,500.51 metres (18,046 ft 4 in)

I understood the consensus above was to change thoses entries that by default display "decimal feet" to "feet and inches" (without messing around with the default rounding — which is a seperate issue). Infact the default rounding affect makes this proposition less invasive as most longer lenths will not be alted unless greater presision has been explicitly requested. -- PBS (talk) 10:04, 5 March 2020 (UTC)

I see no such consensus. We're clearly still in the exploratory phase of evaluating the cost/benefit of any change (whether to decimal feet or ftin). EEng 05:07, 6 March 2020 (UTC)
I don't follow that. This shows how rounding works with the example:
  • {{convert|5500|m}} → 5,500 metres (18,000 ft)
  • {{convert|5500|m|0}} → 5,500 metres (18,045 ft)
  • {{convert|5500|m|ftin}} → 5,500 metres (18,044 ft 7 in)
  • {{convert|5500|m|ftin|0}} → 5,500 metres (18,044 ft 7 in)
  • {{convert|5500|m|ft|1}} → 5,500 metres (18,044.6 ft)
  • {{convert|5500|m|ftin|1}} → 5,500 metres (18,044 ft 7.4 in)
If the default output for m changed to ftin, convert would show "18,044 ft 7 in" instead of "18,045 ft"—that seems undesirable. Someone would need to look at the 128,777 converts and decide whether to insert "|ft" to keep the current output. I have no objection is there is a way to do that provided a widely notified central discussion occurs first. Johnuniq (talk) 04:29, 6 March 2020 (UTC)

I had a look for converts which might give rounding problems if the output is changed to ftin. There are quite a lot of them although I didn't do a count. Examples:

Article Convert Current output (ft) Output with ftin
MV Loch Sunart {{convert|13.87|m|1|abbr=on}} 13.87 m (45.5 ft) 13.87 m (45 ft 6.1 in)
Berlin Wall {{convert|3.6|m|1|abbr=on}} 3.6 m (11.8 ft) 3.6 m (11 ft 9.7 in)
Black Sea {{convert|2212|m|2|abbr=off}} 2,212 metres (7,257.22 feet) 2,212 metres (7,257 feet 2.61 inches)
Brasília {{convert|70|m|2|abbr=on}} 70 m (229.66 ft) 70 m (229 ft 7.91 in)
Frankfurt {{convert|660|m|2|abbr=on}} 660 m (2,165.35 ft) 660 m (2,165 ft 4.25 in)
Papua (province) {{convert|4000|m|-3}} 4,000 metres (13,000 ft) 4,000 metres (13,123 ft 4 in)
Mauritius {{Convert|300|-|800|m|abbr=on|round=50}} 300–800 m (1,000–2,600 ft) 300–800 m (984 ft 3 in–2,624 ft 8 in)

Several of the above (and a lot more not shown) are probably mistakes but they need to be handled somehow. Johnuniq (talk) 06:49, 6 March 2020 (UTC)

I've redone the table using |sigfig= rather than |round= or |(unnamed)=. I've also changed the output to be actual conversions, not cut-and-paste as well as adding an extra column with the number of significant figures reduced by one:
Article Convert Current output (ft) Output with ftin sigfig-1
MV Loch Sunart {{convert|13.87|m|abbr=on|sigfig=4}} 13.87 m (45.51 ft) 13.87 m (45 ft 6.1 in) 13.87 m (45 ft 6 in)
Berlin Wall {{convert|3.6|m|abbr=on|sigfig=2}} 3.6 m (12 ft) 3.6 m (11 ft 10 in) 3.6 m (11 ft 10 in)
Black Sea {{convert|2212|m|abbr=off|sigfig=4}} 2,212 metres (7,257 feet) 2,212 metres (7,257 feet 3 inches) 2,212 metres (7,257 feet 3 inches)
Brasília {{convert|70|m|abbr=on|sigfig=2}} 70 m (230 ft) 70 m (229 ft 8 in) 70 m (229 ft 8 in)
Frankfurt {{convert|660|m|abbr=on|sigfig=2}} 660 m (2,200 ft) 660 m (2,165 ft 4 in) 660 m (2,165 ft 4 in)
Papua (province) {{convert|4000|m|sigfig=2}} 4,000 metres (13,000 ft) 4,000 metres (13,123 ft 4 in) 4,000 metres (13,123 ft 4 in)
Mauritius {{Convert|300|-|800|m|abbr=on|sigfig=2}} 300–800 m (980–2,600 ft) 300–800 m (984 ft 3 in – 2,624 ft 8 in) 300–800 m (984 ft 3 in – 2,624 ft 8 in)
It's clear that using the precision number is applied to fractional inches which is why there is the ridiculous precision of 660 m (2,165.35 ft) for example. There is still a problem with the significant figures being applied to the inch value instead of to the overall feet: 800m to 2 sf is 2,600 ft. This is a problem with the implementation of precision, not with decimal feet vs inches. I must say that I've never come across decimal feet. What is needed is two fold: (1) editors to use sigfig rather than precision and (2) convert to apply the sf to the feet and then drop inches when there are none, otherwise convert the fraction to inches. Easy for me to dish out work I know, sorry! Martin of Sheffield (talk) 10:40, 6 March 2020 (UTC)

1/64th of an ounce

Is there a way to convert 1/64th of an ounce into metric units?--Carnby (talk) 17:43, 5 March 2020 (UTC)

What kind of ounce, there's avoirdupois ounce, troy ounce, and fluid ounce? The last comes in a US variety and a British variety. Jc3s5h (talk) 17:52, 5 March 2020 (UTC)
@Carnby: Once you figure out which sort of ounce, you can use something like {{convert|1/64|oz}} → 1⁄64 ounce (0.44 g) --RexxS (talk) 19:28, 5 March 2020 (UTC)
(edit conflict){{convert|1/64|oz}} -> 1⁄64 ounce (0.44 g). Ounce = avoirdupois unless you are dealing with precious metals (which is rare) and 1/64 is an odd way to handle liquid measure, so I assume this is some sort of a point you are making? Martin of Sheffield (talk) 19:35, 5 March 2020 (UTC)
It was an avoirdupois ounce. Anyway, is there a way to get "1⁄64 of an ounce" instead of "1⁄64 ounce"?--Carnby (talk) 20:46, 7 March 2020 (UTC)
{{convert|1/64|oz||adj=pre|of an}} -> 1⁄64 of an ounce (0.44 g). (watch the double pipe) Martin of Sheffield (talk) 21:19, 7 March 2020 (UTC)
It worked as well in this way {{convert|1/64|oz|g|abbr=off|adj=pre|of an}}. I do not like to abbreviate grains and grams because I find confusing their abbreviations.--Carnby (talk) 21:40, 7 March 2020 (UTC)
(In case anyone else is following this Carnby's example yields 1⁄64 of an ounce (0.44 grams)) Martin of Sheffield (talk) 21:51, 7 March 2020 (UTC)

5 grains of total arrow weight per pound

Is there a way to put some text after the first part and before the second part of the unit to convert?--Carnby (talk) 20:46, 7 March 2020 (UTC)

Some information is at Help:Convert#Extra words. Please provide an example of what the input is (what value is known) and what output is wanted (exactly what text should be displayed). Johnuniq (talk) 22:03, 7 March 2020 (UTC)
The original sentence is "IBO recommends at least 5 grains of total arrow weight per pound of draw weight as a safety buffer." I would like to convert "5 grains per pound" but there is "of total arrow weight" in the middle.--Carnby (talk) 22:17, 7 March 2020 (UTC)
Why not just: IBO recommends at least 5 grains (0.32 g) of total arrow weight per pound of draw weight as a safety buffer. Johnuniq (talk) 22:36, 7 March 2020 (UTC)
In my opinion, grams per pound is not a very sensible unit. I decided for the moment to ignore "of total arrow weight" and to write this: "IBO recommends at least 5 grains per pound (0.71 grams per kilogram) of draw weight as a safety buffer."--Carnby (talk) 23:22, 7 March 2020 (UTC)
I overlooked that problem. Good result. Johnuniq (talk) 01:33, 8 March 2020 (UTC)

Foot-pound per pound

Does this unit really exist?--Carnby (talk) 20:50, 7 March 2020 (UTC)

Why are you asking? Please give a clue. Johnuniq (talk) 22:04, 7 March 2020 (UTC)
In Compound bow there is this sentence: "This is usually around one foot-pound per pound / .3048 joules per meter (but can reach 1.4 ft·lbf/lbf / .42672 J/m)." I think the unit to convert is "1 foot-pound per pound."--Carnby (talk) 22:21, 7 March 2020 (UTC)
One opinion is at Talk:Compound bow#Incoherent units. There don't appear to be any references for that text and it might be worth investigating the history to see when it was added, and giving consideration to whether a reference can be found or whether the text should be removed. The opinion on talk might not be correct as the claim is "usually around one foot-pound per pound or 0.3048 joules per meter" and the links point out that it refers to the amount of potential energy in the drawn bow for the amount of force required to hold the drawn string. However, the purported equivalent (0.3048 joules per meter) is energy per length which is a mistake. I'm not sure how advisable it would be to add an "official" convert to an unreferenced claim but here it is:
Johnuniq (talk) 22:48, 7 March 2020 (UTC)
  • Obviously 1 ft·lbf/lbf = 1 ft; so in metric it would be J/N (=m in SI) not J/m (=N on SI) Hawkeye7 (discuss) 23:11, 7 March 2020 (UTC)
The original sentence was that: "This is usually around one foot-pound-force per pound / 3 joules per kilogram but can reach 1.4 ft·lbf/lbf / 4.2 J/kgf." Then an anonymous user on the 10th December 2014 changed it in this way.--Carnby (talk) 23:17, 7 March 2020 (UTC)

Payload-distance

Looking for a conversion of ton miles into kilometre-tonnes (kmt) tonne-kilometres. Hawkeye7 (discuss) 05:45, 9 March 2020 (UTC)

It appears that Units of transportation measurement is the article but are these units really needed for convert? Is there an example of an article (preferably a couple) where it would be used. The ton unit is a particular problem as it might be short or long, and usually that has to be guessed from context as the source is unlikely to make a distinction. The article confidently tells us that 1 ton-mile in the USA is 1 ton-mile × ( 0.907185 t / short ton) × ( 1.609344 km / mile ) = 1.460 tkm so I suppose it's doable. But is it kmt or tkm, and is there some authoritative source that might be used? Johnuniq (talk) 08:20, 9 March 2020 (UTC)
Short tons only. Examples [1][2][3] What I'm dealing with is a source for this article I'm working on that says: "shipments were averaging 2,000,000 ton-miles per day". Obviously there is no difference between a tonne kilometre and a kilometre tonne but searching online for an authorative source shows that tonne kilometres (tkm) is correct. [4][5] Hawkeye7 (discuss) 08:58, 9 March 2020 (UTC)
Units ST and LT show "short ton" and "long ton" respectively, although there is a shton unit which shows "ton". Please specify a unit code (what goes in convert), full name (abbr=off), symbol (abbr=on). Then a temporary unit can be added to try. Johnuniq (talk) 09:30, 9 March 2020 (UTC)

Units of information

I didn't find in Module:Convert/documentation/conversion data and any unit of information. I was looking for it for importing block size data from wikidata in hewiki, and before adding it to the Hebrew version of Module:Convert/documentation/conversion data I would like to raise it here. Eran (talk) 16:15, 6 March 2020 (UTC)

Are you aware about the battles concerning, for example, MB vs. MiB? What units are proposed, and what would they convert to? If such conversions were useful (I can't see how atm) perhaps there should be a dedicated template? Johnuniq (talk) 23:45, 6 March 2020
I didn't think about MB vs MiB battles but that's a good point. I thought about 8 bit => byte, kilobyte => 1024 byte etc. But taking into account different meanings of Mega/Mebi or usages as Data-rate units it may be better to not include it here to avoid confusion. Eran (talk) 10:36, 14 March 2020 (UTC)

time zone conversion

Is there any chance of a time-zone conversion for date and time? In particular, converting from an arbitrary time-zone to UTC would be handy for things like {{unsigned}} which require a time in UTC. It wouldn't be quite the same as the units conversions here, so perhaps this is not the right place to ask; but then where is? Zerotalk 04:47, 16 March 2020 (UTC)

I can tell you in advance that the answer's gonna be that times/timezones aren't a unit of measure and so out of scope for {convert}. Plus there are a zillion problems with the naming of timezones, their shifting boundaries, daylight time, oh my goodness. If we want a technology-assisted fix to the {unsigned} timestamp issue (and interested editors can visit WT:Talk page guidelines to see what this is all about) then it would be much easier to add a parameter to {unsigned} (or its confusing variants) which would accept the editor's timezone offset from UTC, together with the timestamp in that timezone; {unsigned} could then figure out what the UTC version of the timestamp would be. Aside from requiring the editor to remember his timezone offset (which shifts with daylight time), it just seems like this would be a big mess to explain on a page particularly important for beginners to absorb i.e. WP:TPG. This is why I've counseled, to no avail, just dropping the whole timestamp instruction as useless at best and counterproductive at worst, because fixing the current completely inadequate instructions would render them hopelessly complicated. EEng 05:39, 16 March 2020 (UTC)
EEng is right (except about WP:TPG!). Time calculations are out of scope for convert although there are some time-zone handling templates/modules—perhaps {{time}} could be useful. I thought the history page is unaffected by the local time zone gadget so can't that be used to find a UTC time? At any rate, viewing the talk page in another browser or a private window (where you are not logged on) would show the UTC info. If wanting to pursue this, ask for ideas at WP:VPT. Johnuniq (talk) 06:04, 16 March 2020 (UTC)
The gadget (which takes talk pages with UTC timestamps and, at the last moment, adjusts them to the reader's timezone) has nothing to do with it. That's "on the way out"; we're talking here about "on the way in" i.e. how to get the right timestamp to paste into {unsigned}. You can only get that timestamp from either a diff (for unsigned post) or the page history (listing that post), and those times are also adjusted away from UTC, though not by the gadget but rather by the editor's preference settings. (You may have forgotten this this if your preferences-timezone is UTC.) So no, we cannot just tell editors to copy the timestamp from a diff or page history. EEng 14:16, 16 March 2020 (UTC)
Good grief, I had no idea preferences could change the times in history and presumably contributions. A bizarre preference, given we live on a spherical world. A private window (where not logged in) would work but that's a bit much effort for most. Johnuniq (talk) 01:17, 17 March 2020 (UTC)

Tons

The units 'short ton', 'long ton', and 'metric ton' (not the unit 'tonne') are unrecognised as parameter entries in plural form: {{convert|2|short tons|}} returns as 2 short tons[convert: unknown unit]; {{convert|2|long tons|}} returns as 2 long tons[convert: unknown unit]; and {{convert|2|metric tons|}} returns as 2 metric tons[convert: unknown unit].

Can anyone fix this please, next time there's an update? WT79 The Engineer (talk) 18:12, 20 March 2020 (UTC)

@WT79 The Engineer: This is the page to discuss units. Are plurals really needed? I can see that it's irritating to get an error message but the plurals (like miles = mile and tonnes which paradoxically has a different default output than tonne) are kept for historical reasons. My feeling is that editors should use the one official unit code. Any thoughts? Johnuniq (talk) 23:13, 20 March 2020 (UTC)
@Johnuniq:Thanks for the move. I see the validity in your reasoning; I was mostly looking at it from a consistency point of view – I don't understand why miles should be pluralable and tons should not. If there are pre-existent reasons for this, I shall withdraw my objection. WT79 The Engineer (talk) 10:35, 21 March 2020 (UTC)

Missing in doc: simple ft in calculatins

I was looking for a conversion from "1 ft 11 5/8", a regular ft,in in writing. However, I could not find how to enter this, into a useful result. We shoud improve the /doc for this! -DePiep (talk) 23:09, 2 April 2020 (UTC)

@DePiep: Not sure what output you're looking for, but {{convert|1|ft|11+5/8|in}} → 1 foot 11+5⁄8 inches (0.600 m) --RexxS (talk) 23:37, 2 April 2020 (UTC)
Yes that's the stuff! So into the /doc I say. (not me, today) -DePiep (talk) 23:40, 2 April 2020 (UTC)
Does not section 8.4 cover this? Martin of Sheffield (talk) 09:13, 3 April 2020 (UTC)
It's not about the fraction, it is about using two units (ft, in) as input. -DePiep (talk) 10:47, 3 April 2020 (UTC)
Section 11.4 covers multiple units, combine with section 8.4 and you get the conversion RexxS showed you. Martin of Sheffield (talk) 11:31, 3 April 2020 (UTC)
Yes, 11.4 covers it, and has a clear sectiontitle. OK. -DePiep (talk) 11:56, 3 April 2020 (UTC)

way to get non-breaking space between ftin?

Is there a way to output ftin with a non-breaking space between the feet value and the inches value?

As in, 2 metres (6 ft 7 in) where the space between "ft" and "7" is non-breaking? —Joeyconnick (talk) 21:48, 12 April 2020 (UTC)

This should be part of WT:Manual_of_Style#Non-breaking_spaces_with_written_out_units. (That's going to be a difficult discussion but it needs to be had. Someday.) EEng 00:34, 13 April 2020 (UTC)
(edit conflict)I'm not sure what the need for it would be, as I don't see anything particularly wrong with reading:
  • ... 2 metres (6 ft
    7 in)
However, if it's needed in a rare case, why not simply subst the convert, and then add the desired &nbsp; to get 2 metres (6&nbsp;ft&nbsp;7&nbsp;in), or perhaps better:2 metres ({{nowrap|6 ft 7 in}})? Surely you wouldn't need to do it very often? --RexxS (talk) 00:37, 13 April 2020 (UTC)
I would not recommend using subst around convert. If I see plain text in the wiki markup like "7 feet (2.12 m)" then I am always suspicious of people's hand calculations - they are quite often wrong and need to be tediously tested every time I see them and then changed to convert anyway. But I trust {{convert|7|ft|m|2}} to give me the correct conversion of "7 feet (2.13 m)".
However, the {{nowrap}} suggestion is good.  Stepho  talk  11:34, 13 April 2020 (UTC)
  • While I still would like to see the need, I can think of this:
Use output in parts, to add a {{Nowrap}} (see doc):
1. Show input value only, {{Convert}}-formatted:
{{convert|2|m|m|disp=out}} → 2.0 m
2. To show output value only:
{{nowrap|1=({{convert|2|m|ftin|disp=out}})}} → (6 ft 7 in)
In there, it can use ~all {{Convert}} functions & options.
Probably more doable in templates, infoboxes, and tables. Have a nice edit. -DePiep (talk) 13:01, 13 April 2020 (UTC)
A use case might be: in tables and infoboxes, keep the ftin value together indeed. In this workout example, maybe the issue "only return input" could be addressed (add |disp=in?), current workaround even changes the value (.0 added in the example). I have no opinion on the usefullnes of these changes (vs. time spend). -DePiep (talk) 15:02, 18 April 2020 (UTC)
Yes, that is exactly the use case... in a table, where I want to list {{convert|2|m|ftin|abbr=on}} "2 m (6 ft 7 in)" and it would be fine to break as:
2 m
(6 ft 7 in)
but would look terrible as:
2 m (6 ft
7 in)
(which is what it is currently doing). —Joeyconnick (talk) 18:41, 18 April 2020 (UTC)

Enforced line break

|disp=br adds a line-break and omits brackets.

|disp=br() adds a line-break and does add brackets to the converted value. This may be useful in tables:

|disp=br |disp=br()
10 kilometres
6.2 miles 		10 kilometres
(6.2 miles) 		1 km
(0.62 mi) 		1 km
0.62 mi 		1 km
(0.62 mi)
sorry being this late :-( -DePiep (talk) 18:53, 18 April 2020 (UTC)
  • Thanks, I had found that. Not exactly what I'm looking for because it could still result in:
    • 2 m
      (6 ft
      7 in)
    [depending on the length of the unit names and various values and since the space between "ft" and "7" is still "regular"/not non-breaking]
The issue is that the output has two components and there isn't an easy way to keep those two components together as a single element. —Joeyconnick (talk) 19:12, 18 April 2020 (UTC)
  • Does that happen? I added some testing columns to the table. See code: "max-width:2em" forces a linebreak, but unwanted break does not occur. -DePiep (talk) 19:20, 18 April 2020 (UTC)
Happens here at the right browser width, as can be seen here. The output example you are using is just "miles/mi", it's not both "ft" and "in". —Joeyconnick (talk) 05:51, 19 April 2020 (UTC)

Convert Wikidata error

Resolved

Category:Convert errors now lists eight power station articles, eg Ace Embilipitiya Power Station. They use {{Infobox power station}}, which pulls all data from WikiData.

The error occurs in row data59, "Site area" (WD area (P2046)). The example article has WD value "44 acre", OK. Somehow the unit is read as "ac" by Convert, throwing the error. All articles have this property in "acre". I was unable to do more research. ;-) -DePiep (talk) 14:59, 18 April 2020 (UTC)

@DePiep: The problem arose because Germartin1 added "ac" on Wikidata as the value for unit symbol (P5061) to acre (Q81292) on 12 April. Since Module:WikidataIB reads the unit symbol that it supplies to convert from Wikidata, it needs to have 'acre' as the unit symbol there, otherwise convert throws the error. I've fixed the problem for now by changing the unit symbol for acre on Wikidata, but that error mechanism remains for any quantity sourced from Wikidata. --RexxS (talk) 15:45, 18 April 2020 (UTC)
Good works. -DePiep (talk) 15:57, 18 April 2020 (UTC)
Thanks RexxS. I've been too irritated to fix that myself. The article acre is said to show that "ac" is a valid symbol for acre, and indeed that article gives a reference. It's high-level nonsense to me, and is obviously the work of over-active pigeonholers who believe that because units like kilogram have a symbol, therefore acre must also have a symbol, so we'd better invent one. I was planning to wait until that irritation had subsided, then investigate adding ac to convert as a symbol but without displaying it in outputs. Johnuniq (talk) 22:53, 18 April 2020 (UTC)
Personally, I'm happy to work on keeping Wikidata clean. If anybody adds 'ac' again, I can always promote 'acre' to preferred rank, so we won't get a repeat error from that one. I find it a little irritating that Wikidata stores a fair amount of English monolingual text (that only applies to English applications such as English Wikipedia) without checking what the consequences are of using that text here. You won't believe the effort required to get en-gb versions of metre, litre, etc. in labels because 'en-us' wasn't recognised and somebody had made the assumption that 'en' therefore had to mean en-us by default. --RexxS (talk) 23:17, 18 April 2020 (UTC)
Slightly off, but I am still surprised that WD choose to require that a unit must be entered in (say) full en name, not its international unit. -DePiep (talk) 00:45, 19 April 2020 (UTC)
The point is that ac is not familiar to anyone other than people like us who might have noticed the claimed reference. In real life, and in convert templates, saving two characters by writing ac instead of acre is not worth the confusion caused for onlookers. Johnuniq (talk) 01:00, 19 April 2020 (UTC)
@DePiep: The interface you see when entering data manually into Wikidata is just a JavaScript layer to create the internationalisation. That means you enter a unit by matching a named entity using AJAX. So by the time you've typed 'ac' it's offering you acre (Q81292) and then actinium (Q1121) and so on. You have to pick something that already has an entity-id, but you pick it by using the labels in your own language. What is stored in Wikidata for area (P2046) of Embilipitiya Power Station (Q25056880) can be seen by examining the property:
table#1 {
    table#2 {
        ["id"] = "Q25056880$2034aad9-4077-8f80-64e2-494f403e607f",
        ["mainsnak"] = table#3 {
            ["datatype"] = "quantity",
            ["datavalue"] = table#4 {
                ["type"] = "quantity",
                ["value"] = table#5 {
                    ["amount"] = "+44",
                    ["unit"] = "http://www.wikidata.org/entity/Q81292",
                },
            },
            ["property"] = "P2046",
            ["snaktype"] = "value",
        },
        ["qualifiers"] = table#6 {
            ["P518"] = table#7 {
                table#8 {
                    ["datatype"] = "wikibase-item",
                    ["datavalue"] = table#9 {
                        ["type"] = "wikibase-entityid",
                        ["value"] = table#10 {
                            ["entity-type"] = "item",
                            ["id"] = "Q159719",
                            ["numeric-id"] = 159719,
                        },
                    },
                    ["hash"] = "92e50222d46cdef57f722b435fbab6b3e919014b",
                    ["property"] = "P518",
                    ["snaktype"] = "value",
                },
            },
        },
        ["qualifiers-order"] = table#11 {
            "P518",
        },
        ["rank"] = "normal",
        ["type"] = "statement",
    },
}
As you can see, the mainsnak.datavalue.value.amount is stored as "+44" and the mainsnak.datavalue.value.unit is stored as "http://www.wikidata.org/entity/Q81292", which is the url of acre (Q81292). Nothing directly about "acre" in there at all. --RexxS (talk) 01:43, 19 April 2020 (UTC)
I see. So the fetching turns out as i18n after all. thx. btw, I don't think I'll be this deep in WD soon. -DePiep (talk) 10:58, 19 April 2020 (UTC)

Add Radiation Related Quantities?

Ionizing radiation related quantities
Quantity Unit Symbol Derivation Year SI equivalent
Activity (A) becquerel Bq s−1 1974 SI unit
curie Ci 3.7 × 1010 s−1 1953 3.7×1010 Bq
rutherford Rd 106 s−1 1946 1,000,000 Bq
Exposure (X) coulomb per kilogram C/kg C⋅kg−1 of air 1974 SI unit
röntgen R esu / 0.001293 g of air 1928 2.58 × 10−4 C/kg
Absorbed dose (D) gray Gy J⋅kg−1 1974 SI unit
erg per gram erg/g erg⋅g−1 1950 1.0 × 10−4 Gy
rad rad 100 erg⋅g−1 1953 0.010 Gy
Equivalent dose (H) sievert Sv J⋅kg−1 × WR 1977 SI unit
röntgen equivalent man rem 100 erg⋅g−1 × WR 1971 0.010 Sv
Effective dose (E) sievert Sv J⋅kg−1 × WR × WT 1977 SI unit
röntgen equivalent man rem 100 erg⋅g−1 × WR × WT 1971 0.010 Sv

https://en.wikipedia.org/wiki/Template:Radiation_related_quantities — Preceding unsigned comment added by 2001:a62:1570:301:4449:56ee:9d2b:e309 (talk) 12:23, 21 April 2020 (UTC)

Becquerel, curie, rutherford, gray, rad, sievert, rem are already supported (see Module:Convert/documentation/conversion data). — UnladenSwallow (talk) 11:13, 23 April 2020 (UTC)

Varying sigfigs within the same template

This source gives the maximum elevation of the Ansel Adams Wilderness as 13,157 ft, and the minimum elevation as 3,500 feet. Let's say I want to convert that range to meters:

{{convert|3,500|–|13,157|feet|m|0|abbr=on|sortable=on}} outputs this: 3,500–13,157 ft (1,067–4,010 m)

I can't figure out how to specify different sigfig values for the two elevations. I'd like -2 sigfigs for the first number, and 0 sigfigs for the second number. CJK09 (talk) 00:25, 30 April 2020 (UTC)

@CJK09: I'm afraid convert's syntax is too complex already yet does not have a way of specifying the rounding for each value in a range. One minor point, your example uses an en dash (–) instead of a plain hyphen (-). I suggest using a hyphen because it is easier to type, and for consistency with the vast majority of converts. Convert always uses the correct dash in the output.
If |0 is used, each output number is rounded to the nearest integer. In this example, that gives "(1,067–4,010 m)". If no rounding is specified, convert uses the highest precision of each item in the range on each item. Use |round=each to have convert calculate the precision for each item separately. Fortunately that achieves what you want but it sometimes gives bad results.
  • {{convert|3,500|-|13,157|feet|m|abbr=on|round=each}} → 3,500–13,157 ft (1,100–4,010 m)
Johnuniq (talk) 02:01, 30 April 2020 (UTC)

"A/an" instead of "one" using spell parameter

Is there a way to render "an inch"/"a feetfoot"/"a mile" instead of "one inch"/"one feetfoot"/"one mile" when using |spell=on parameter? It would be useful when in a text caption there's "an inch"/"a feetfoot"/"a mile."--Carnby (talk) 14:15, 18 April 2020 (UTC)

Err, that's "a foot", not "a feet"! Martin of Sheffield (talk) 14:23, 18 April 2020 (UTC)
I should downgrade my English knowledge to EN-1.--Carnby (talk) 14:35, 18 April 2020 (UTC)
As this is something that might be useful anywhere that a module returns a string, I've added a function to Module:String2 called "one2a" that scans through a string, passed as either the first unnamed parameter or |txt=, and replaces One/one with A/An/a/an as appropriate. Here are some examples:
  • {{one2a |one foot. One mile. One inch.One amp. one foot. one mile. one inch. Alone at last.}} → a foot. A mile. An inch.An amp. a foot. a mile. an inch. Alone at last.
  • {{convert|1|ft|spell=on}} → one foot (zero point three zero metres)
  • {{one2a|{{convert|1|ft|spell=on}}}} → a foot (zero point three zero metres)
  • {{convert|2.54|cm|0|disp=out|spell=on}} → one inch
  • {{one2a|{{convert|2.54|cm|0|disp=out|spell=on}}}} → an inch
The Template:One2a is just a convenience wrapper for the function call. --RexxS (talk) 20:52, 18 April 2020 (UTC)
Very nice! May I note this, in small print: shouldn't it be "an hour" and "a hospital" (silent/not silent h). OTOH, in the unit list, I found h-units only being hecto-, so it's safe for {{Convert}}. -DePiep (talk) 21:37, 18 April 2020 (UTC)
@RexxS: Sorry for the delay, I would like to thank you for your work.--Carnby (talk) 13:04, 3 May 2020 (UTC)
@DePiep: Thank you. You're right about the silent 'h', but I'd need to write a lookup list of exceptions, which could never be comprehensive for natural language applications – things like "a unique value", "a/an eunuch", "an yttrium-based magnet", and so on. Fortunately, the set of unit names is small enough to use a lookup table for many purposes: I was able to write Module:UnitPlural to present the correct plurals for a string containing a number and unit name (which is what is stored on Wikidata). --RexxS (talk) 22:33, 18 April 2020 (UTC)
All fine, I was just looking at your code for myself, and did some trying. Just interested, I have no need to perfecticise this. Have a nice edit. -DePiep (talk) 22:41, 18 April 2020 (UTC)
Beware that in some varieties of English (eg Australian), we pronounce the "h" in hour, therefore we have "a hour", not "an hour". Although we're so used to the rest of the world getting it wrong that we don't make much of a fuss about it :)  Stepho  talk  10:37, 19 April 2020 (UTC)

Forbid fractional output of metric units

I appreciate that a template can't enforce MOS requirements in every instance, but if there is a style that is clearly proscribed in every context then (providing there is no good reason not to) it seems reasonable to me to disallow output such as 7+1⁄4 miles (11+5⁄8 km). Either raising an exception or ignoring the frac option would seem sensible. What say? Archon 2488 (talk) 11:58, 1 May 2020 (UTC)

Interestingly, it's handled when we have multiple outputs like {{convert|7600|ft|mi km|frac=8}} → 7,600 feet (1+1⁄2 mi; 2.3 km). --RexxS (talk) 22:27, 1 May 2020 (UTC)
Convert has a special case for multiple outputs to allow examples like yours so that imperial units can be shown with a fraction while using decimals for SI. If there is an example of people abusing frac=8 with SI units, the normal procedure would be to discuss the issue with the editor involved and convince them to follow MOS. After all, more than convert could be used to write a number of km in fractions. If using frac=8 is bad, the solution is to not use frac=8. Johnuniq (talk) 00:30, 2 May 2020 (UTC)
Possibly silly question: why does the template allow output of metric units in a format that is never allowed, as you describe? I agree ofc that using the option as you describe is not a good idea, but why allow it at all if the only consequence of it is violating the MOS? Discussing with the editor is fine, but what is the benefit if it's in relation to a style that WP doesn't allow? Archon 2488 (talk) 02:37, 2 May 2020 (UTC)
MOS is not absolute. Has there been a rash of inappropriate usage that enforcement via the template would prevent? EEng 03:44, 2 May 2020 (UTC)
I'm not so confident to say that no one would ever find a need to say, for example, 1+1⁄2 km rather than 1.5 km. Yes, the latter is preferable in all ways that I can conceive, but the former might, for example, arise if discussing exactly what a quote said. At any rate, adding code to prevent something that possibly never arises doesn't seem worthwhile. Also, the only way convert can guess that a unit should not have fractional values is to look in the Prefix column of the units data. That would work for the vast majority of cases, but it would fail for example with A.h which does not accept prefixes:
  • {{cvt|9876.5|coulomb|A.h|frac=8}} → 9,876.5 C (2+3⁄4 A⋅h)
Finally, we can't stop people from finding a way to misuse convert, such as:
  • {{cvt|2+7/8|km}} → 2+7⁄8 km (1.8 mi)
  • {{cvt|2+7/8|km|frac=8}} → 2+7⁄8 km (1+3⁄4 mi)
Johnuniq (talk) 03:52, 2 May 2020 (UTC)
Being devil's advocate, I'm suggesting something like a veto on output of fractions with metric units. So if the code is given 2+7⁄8 km as an input, it would simply display that as 2.875 km (modulo rounding); I'm guessing that that level of abstraction of output from input is allowed by the template? Indeed, MOS isn't absolute, but I am enough of a dogmatic fanatic to want to ban every occurrence of an abomination like 25⁄32 kilometre (0.49 mi), just because one system is decimal and the other isn't. If someone being quoted wrote such an abomination, one could always handle it outside of the template (and it's definitely not reasonable to expect a template to deal with every such fringe misuse of units). Archon 2488 (talk) 02:06, 3 May 2020 (UTC)
As Wikipedia content is based on the NPOV principle, and article content relies on collegiate and collaborative consensus, it is not appropriate to code such dogma into the templates though. -- DeFacto (talk). 17:21, 3 May 2020 (UTC)
Perhaps another way to look at it, Archon 2488, is that we're very grateful to Johnuniq who has done all of the work in creating and maintaining Module:Convert, with over 3,700 lines of code, as a volunteer – and we don't say "thank you" often enough. No module of that complexity expects to be perfect, and somebody will probably always be able to find another new feature that they would like to see. It's only fair that John asks the question "is this a solution looking for a problem?", because that gives him a chance to weigh the amount of effort he has to put into enabling and testing fresh functionality against the benefit that the changes would bring. The point that it would be nice if the code forced MoS-adherence is reasonable, but in my experience breaches of MoS are often the target of so many wiki-gnomes that they really don't pose a great problem. Cheers --RexxS (talk) 22:30, 2 May 2020 (UTC)
I don't want to sound ungrateful; I'm definitely not averse to changing the code myself, but Lua is not my thing and learning a language to edit one piece of code is usually not a great idea. If the suggestion is gratuitous then I'm happy to can it. Archon 2488 (talk) 01:37, 3 May 2020 (UTC)
There are some cases where fractional outputs are needed, for example, the Chi (unit) is defined as exactly one-third of a metre. Its article uses the convert template multiple times, and if its usage was changed to only output decimal values it could cause confusion, as it's a definition not an exact value. I think it's more productive for copy editors to have to amend the small number of non‐MOS uses than have the template behave in unexpected ways if someone wants to use it correctly for the small number of edge-cases like this. ‐‐Voello talk 07:27, 3 May 2020 (UTC)
Indeed. Facilities that want to reach out and wipe your butt for you always turn out to be bad ideas in the end. Witness the trouble caused by the automatic and unexpected output of ft+in vs. decimal feet, based on whether or not the quantity was guessed to be someone's height. EEng 15:09, 3 May 2020 (UTC)
This is way too generic about software supporting error-prevention—and way too negative. For example, we have Category:Unknown parameters, {{2}}, Module:Preview warning. In this {{Convert}} case, as RexxS has described (and Johnuniq throughout this module's history), there is a tradeoff between effort required and practical gain. -DePiep (talk) 17:27, 3 May 2020 (UTC)
40 years as software engineer tells me otherwise. And they may not be errors. And no one's answered my request for real-life examples of bad things this would have prevented. So for the moment this is a potentially annoying and surprising solution to a hypothetical problem which might not be occurring and might not even be an error if it is. None of the links you give has any relevance to this discussion. EEng 21:28, 3 May 2020 (UTC)
40 years as software engineer and you have not met the idea of debugging? I note you wrote "always [sic] turn out to be bad ideas". -DePiep (talk) 21:45, 3 May 2020 (UTC)
As has so often been the case, it's impossible to discern what you're talking about or its relevance to the discussion at hand. EEng 22:07, 3 May 2020 (UTC)
OP is about software-supporting style maintenance. You write: "... always turn out to be bad ideas". I write: no, there are counterexamples. You write: "40 years as software engineer tells me ..." (an ab auctoritate btw). I reply: never met "debugging"?. You: Ididnothearthat. Maybe the pattern you repeatedly experience is with the beholder. -DePiep (talk) 16:39, 4 May 2020 (UTC)
Still unintelligible, and still no examples of actual problems in articles this would solve. Also, you need to review how to use hyphens. I don't think I'll be responding further. EEng 17:42, 4 May 2020 (UTC)
This is not Twitter. -DePiep (talk) 18:56, 5 May 2020 (UTC)
Well, no one's going to disagree with you there. EEng 02:25, 6 May 2020 (UTC)

Positional parameters

Can I use positional parameters from another template (for example, {{{1}}}). Imagine a template calle kcal and it is used in the same way in a page : {{kcal|1}} . The {{kcal}} code is: {{convert|{{{1}}}|kcal|kJ}} . Why does not it work?. It ask for a number (perhaps instead of a positional parameter as {{{1}}}}. But this type of functionality is also needed. --BoldLuis (talk) 18:40, 8 May 2020 (UTC)

That should work. Perhaps you are seeing a problem at the template page where {{{1}}} is not defined? The traditional way of avoiding such errors is to use <includeonly> but with convert you could use:
{{convert|{{{1|NNNN}}}|kcal|kJ}}
Convert interprets NNNN as "someone should fill-in this number later" and convert outputs nothing. I added that to convert because several templates or documentation pages (I forget which) resulted in NNNN being used with convert in many articles and I got tired of commenting them out. If there is a problem, please post a link to where the problem can be seen. Johnuniq (talk) 00:16, 9 May 2020 (UTC)

Can it output "a" instead of "one"?

Is there a modifier to get {{convert|1|m|ft|0|spell=in|abbr=off}} to output "a" rather than "one", as in "about a metre (3 feet)" rather than "about one metre (3 feet)"? -- DeFacto (talk). 15:59, 8 May 2020 (UTC)

about {{one2a|{{convert|1|m|ft|0|spell=in|abbr=off}}}} → about a metre (3 feet)
See #"A/an" instead of "one" using spell parameter above. It's not perfect but should do the job most of the time. Cheers --RexxS (talk) 20:02, 8 May 2020 (UTC)
That's amazing. I edited your example because one2a was missing from the right-hand side. I hope that's what was intended. Johnuniq (talk) 00:10, 9 May 2020 (UTC)
Yes, John. Thanks for fixing my faux-pas. --RexxS (talk) 00:30, 9 May 2020 (UTC)
Thanks RexxS, that sounds perfect! -- DeFacto (talk). 09:50, 9 May 2020 (UTC)

How do I set the comma thing to both "gaps" and "5"?

How do I set the comma thing to both "gaps" and "5"?

{{convert|5000|ft||abbr=|order=flip|comma=5|comma=gaps}} didn't work. 146.255.181.208 (talk) 21:04, 25 April 2020 (UTC)

Sorry, convert cannot do that. The option comma=gaps5 used to do what you want (use gaps, but only if 5 or more digits before decimal point). However, it was disabled in June 2015 and later removed. That followed a couple of discussions, at least one of which can be found by searching that archive for "gaps5". I believe that no converts used that option at the time—if there were any, it was a very small number. Johnuniq (talk) 01:19, 26 April 2020 (UTC)
Thanks for answering! Is there another way to do that? Also, why do I have to change the URL manually to use visualeditor? 146.255.182.147 (talk) 22:57, 1 May 2020 (UTC)
No one has asked for that functionality in years, and I'm not sure it was every used more than a couple of times. That suggests that using comma=gaps might not be desirable wherever your intended use is. You could investigate {{gaps}} and see if it helps. Regarding visual editor, try asking at WP:VPT. Johnuniq (talk) 00:25, 2 May 2020 (UTC)
Found a solution: {{replace|{{convert|25000|ft||abbr=|order=flip|comma=5}}|,| }}
7600 metres (25 000 ft) 146.255.180.241 (talk) 15:54, 18 May 2020 (UTC)

The unspeakable criminality of in2

My dear MOS warriors. In my travels I have realised that a despicable heresy, namely the abuse of imperial unit abbreviations as if they were SI symbols, is permitted by the template: 150 cm2 (23 in2). Compare, however, 150 cm2 (23 sq in), and 150 km2 (58 sq mi) – in the last case, the user's request for "mi2" is rejected in favour of the MOS-sanctioned abbreviation "sq mi". Is there a reason why "in2" is permitted? I appreciate that my pedantry is extreme, but it is in the name of a righteous cause. Archon 2488 (talk) 22:22, 17 May 2020 (UTC)

Let's start with: Is there a reason mi2 is rejected? (I'm not saying it should be the default, but are you saying it's not possible to get that output?) EEng 23:07, 17 May 2020 (UTC)
Less poetically, the problem is that the following unit codes give these unit symbols (abbr=on):
in2 → in2
sqin → sq in
mi2 → sq mi
sqmi → sq mi
I don't know the reason for the discrepancy—I think it's from before the module's time (December 2013). It's mentioned once in the archives: Template talk:Convert/Archive April 2011#mi2?. My guess is that scientists talk about small areas and might have used square inches, and being scientists they would like in2. That is, sources would have used that terminology. However, I'm guessing, not many sources would have referred to mi2. Hmm, looking at a few of the places where in2 is used in articles, it seems to be mostly in lbf/in2 (example) although, for example, Pump action#Rifles has two in2. If mi2 is needed (example?), it's easy to add. Johnuniq (talk) 23:54, 17 May 2020 (UTC)
What about lb/□" (as seen on a steam loco's pressure gauge)? :-) Martin of Sheffield (talk) 11:33, 18 May 2020 (UTC)
Very nice and sort-of understandable. Johnuniq (talk) 00:06, 19 May 2020 (UTC)
Of course, every article that trespasses this MOS rule may be edited, and then simply refer to MOS in the es. It could be that a source uses "in2" (think: literal quote), then we re fine too (=allowed imo). -DePiep (talk) 18:36, 21 May 2020 (UTC)
What MOS rule? EEng 21:58, 21 May 2020 (UTC)

Convert does not handle exponents with decimal points

Hi, noting that this:

  • {{convert|10e33|erg|J}}

produces this:

  • 10×1033 ergs (1.0×1027 J)

but this:

  • {{convert|10e33.5|erg|J}}

As of 21 May 2020, it gets this error:

When I preview, this is an approximation in HTML of what I am seeing:

  • Error in convert: Value "10e33.5" must be a number (help)

Please let me know if this gets fixed. There is a use for a corrected version at Proxima Centauri b.

Peaceray (talk) 18:11, 21 May 2020 (UTC)

Sidenote: I see that {{Val}} handles this all-right: {{val|10e33.5|u=erg}} → 10×1033.5 erg
I note this here because I would enjoy value-handling by {{Val}} and {{Convert}} ultimately being the same (value = number × unit, per SI). --DePiep (talk) 18:43, 21 May 2020 (UTC)
The source used in Proxima Centauri b states "The superflare had a bolometric energy of 10^33.5 erg". That's a rather odd way of stating a value of energy to my eye, but perhaps it's common in astronomy. Our article on Scientific notation suggests that the exponent is expected to be an integer, which matches my experience. Nevertheless 1e33.5 erg is trivially the same as 3.2×1033 ergs (3.2×1026 J). Why not just use that? --RexxS (talk) 21:34, 21 May 2020 (UTC)
Thanks, RexxS! The problem is that the source specifically says 10^33.5 erg, so readers may not know that 10^33.5 equates to 3.2^33. I will play with that but have not yet had exactly the result that I would like.
I am not knowledgeable about astronomy or exceptional scientific notation, but I do like to read about exoplanets. I will edit when & where I perceive an opportunity for improvement.
I may (or may not) arrive at a proper workaround, but ultimately DePiep's idea would work best.
Peaceray (talk) 22:32, 21 May 2020 (UTC)
Just for completeness, the e (exponent) notation is not identical to ^ (power) notation: 10^33.5 means "ten to the power 33.5", which is 1 × 1033.5 (optionally written as 1e33.5) – which is the same as 3.2 × 1033 (optionally written as 3.2e33). Hope that helps avoid any confusion. Cheers --RexxS (talk) 23:37, 21 May 2020 (UTC)
I would guess that people dealing with very big numbers express them as powers of 10, and use fractional powers when they have sufficient significant figures. However, convert is correct to say that 10e33.5 is not a number because e notation requires an integer exponent. As RexxS says, e is not the same as 10^. For example, 10e2 = 1000 but 10^2 = 100. The following klunky convert could be used but it copies whatever sign the exponent has, which is why "+" ends up in the output:
  • {{convert|{{#expr:10^33.5}}|erg|J|adj=ri1|sigfig=2}} → 3.2×10+33 ergs (3.2×1026 J)
The convert uses the full precision of 10^33.5 but adj=ri1 rounds the input display to 1 decimal place. Johnuniq (talk) 00:20, 22 May 2020 (UTC)

Handling "to", "and", etc., in VisualEditor

The documentation says:

"Value ranges can be entered using |to|... or |-|...:

{{convert|2|to|5|km|mi}} → 2 to 5 kilometres (1.2 to 3.1 mi)
{{convert|2|-|5|km|mi}} → 2–5 kilometres (1.2–3.1 mi)"

which is useful in situations such as "from 1 to 3 meters (3 to 10 ft)" or "between 1 and 3 meters (3 and 10 ft)", which are rather common.

The problem is, I can't find the way to do that in VisualEditor. The feature seems to rely on position and doesn't seem to have a named parameter (or rather, I couldn't find it). If there is a named parameter for the "-", "to", "and" and perhaps other indicators, what is it called? And if not, could we have such a named parameter, please? --Jhertel (talk) 10:32, 5 June 2020 (UTC)

I can now see that the template is a mess because there is no direct mapping between positional arguments and parameter names. That makes it impossible to map to the VisualEditor template editor, and it's evident when you try to edit in VisualEditor; the values don't match the named parameters. It looks like a new template should be made, a template which is straight and doesn't mess with the positions of arguments. Then the 'convert' template can call the new template as soon as it straightens out the messy positional arguments, and we can transition towards using only the new template which does not mess up the positional arguments.
Or is that already how it works behind the scene? If that is the case, what is the name of the straight template that uses only named parameters without messing with the positional arguments? --Jhertel (talk) 10:58, 5 June 2020 (UTC)
Sorry but there are no named parameters to specify a range, and there is no other template. The free syntax of convert is a problem but it's quite natural and is second nature for many editors. There are over 30,000 converts in articles using - for a range, another 10,000 using x, and 34,000 using to. There are 600 like {{convert|28|x|34|x|15|cm|in|abbr=on}} (in Enigma machine). No one has devised a better syntax. Johnuniq (talk) 23:39, 5 June 2020 (UTC)
My God, is there nothing {convert} can't do? It's like EMACS. Can you play Space Invaders on it? EEng 23:59, 5 June 2020 (UTC)

Bug when rounding using sigfig

This example:

{{convert|1|to|3|m|ftin|abbr=on|sigfig=1}} should render as "1 to 3 m (3 to 10 feet)", but renders as "1 to 3 m (3 ft 3 in to 9 ft 10 in)", which of course is more than 1 significant digit.

The documentation doesn't mention this bug.

--Jhertel (talk) 10:43, 5 June 2020 (UTC)

To follow up, even though "ftin" is used, it shouldn't use inches when there are no significant digits left after calculating the feet. The template user shouldn't be required to change the unit according to the result of the conversion. --Jhertel (talk) 11:01, 5 June 2020 (UTC)
{{convert|1|to|3|m|ft|abbr=on|sigfig=1}} → 1 to 3 m (3 to 10 ft)
If you don't want inches, don't specify "ftin". That's not a bug, it's the template working as intended. It's not a matter of the template user changing the unit according to the result, it's a matter of the template user wanting a particular display. When multiple units are specified, the |sigfig= parameter applies to the smallest unit, because it wouldn't make sense to apply it to the larger units. Specifying a single unit allows the |sigfig= parameter to apply to that unit, allowing any display desired. --RexxS (talk) 19:36, 5 June 2020 (UTC)
On a minor note: the sigfig pertains to the input value, i.e., the metres in your example. It aims to specitfy a precision (uncertainty) thereof. It's not just counting digits.
Also, sigfig is based on the decimal system (where digit counting *is* relevant), and wants to define a precision. Recalculating that precision to ftin can be done, but not the way you wrote in the OP.
BTW, your example being "1 to 3 m" does not help. Just input like "3 m" would be great for the same Q. (even eliminatring the range-issue: actually the input you gave says "(1 to 3 m) +/- 0.5 m". -DePiep (talk) 00:29, 6 June 2020 (UTC)

Curie got renamed to Curie (unit)

Convert now links to a disambig — Preceding unsigned comment added by 85.242.253.165 (talk) 17:37, 21 June 2020 (UTC)

Example: 1 curie (37 GBq) --RexxS (talk) 23:30, 21 June 2020 (UTC)
Thanks. I'll handle this and really must extract my finger as there are some other minor items to clean up. Johnuniq (talk) 00:01, 22 June 2020 (UTC)
Not sure what you're talking about but it sounds quite unsanitary. EEng 00:14, 22 June 2020 (UTC)


 Done [6] (not by me, DePiep) -DePiep (talk) 02:46, 22 June 2020 (UTC)

Improper linking of nautical miles

I was recently reading Naval Air Station Joint Reserve Base Fort Worth, and I noticed that the “s” in “nautical miles” was not linked like the rest of the unit. The article appears to be using this template, so I believe this is a bug. Olea Capita (talk) 07:04, 16 June 2020 (UTC)

This problem seems to occur only on the Wikipedia iOS app. Olea Capita (talk) 07:30, 16 June 2020 (UTC)

The convert is
{{convert|5|NM|0|lk=in}} → 5 nautical miles (9 km; 6 mi)
and the wikitext which convert outputs is:
5 [[nautical mile]]s (9&nbsp;km; 6&nbsp;mi) = 5 nautical miles (9 km; 6 mi)
That's interesting about the Wikipedia iOS app. It must be working differently in however it renders wikitext. In principle, you could ask about this at WP:VPT but you might be told to report it at WP:Phabricator which is quite an effort unless used to the process. Johnuniq (talk) 09:11, 16 June 2020 (UTC)
That's one way of reducing bugs, you see. EEng 09:46, 16 June 2020 (UTC)
 Done I have reported it on Phabricator. Olea Capita (talk) 16:53, 16 June 2020 (UTC)
Thanks, that's at phab:T255584. Johnuniq (talk) 23:58, 16 June 2020 (UTC)

Space before degrees symbol

Hi - the template puts a space before the units, which is usually correct, but in the case of degrees symbols there should not be a space (as outlined in the table at MOS:UNITSYMBOLS). Example: 120 °C (248 °F). Is there any way this can be rectified? Cheers GirthSummit (blether) 14:27, 27 June 2020 (UTC)

I've just looked at Wikipedia:Manual of Style/Dates and numbers#Specific units. According to that, °F and °C (temperature) should have a (non-breaking) space in front, but ° (angle) should have no space. -- Dr Greg  talk  14:47, 27 June 2020 (UTC)
I don't believe {{convert}} does conversions of angles, so that part shouldn't be relevant. It handles temperature as the MoS specifies. --RexxS (talk) 16:19, 27 June 2020 (UTC)
Thanks for the comment - sorry, misread the MOS. GirthSummit (blether) 20:39, 27 June 2020 (UTC)

Shaku

I was using Shaku (unit) and it works in the conversion template, although it is nowhere listed in the units available. Should be added, I think. Thanks,  Mr.choppers | ✎  03:09, 3 July 2020 (UTC)

There are too many units to list on the template page. The full list is at Module:Convert/documentation/conversion data and it contains shaku. Johnuniq (talk) 04:06, 3 July 2020 (UTC)
Thanks. And yes, there are lots of fun units: 1 pc (1.02×1017 shaku).  Mr.choppers | ✎  17:14, 3 July 2020 (UTC)

310 tonnes

An oddity:

  • {{cvt|309|t|LT}} gives: 309 t (304 long tons)
  • {{cvt|311|t|LT}} gives: 311 t (306 long tons)
which are correct, but
  • {{cvt|310|t|LT}} gives: 310 t (310 long tons)

Have I failed to understand something? Same for

  • {{convert|310|t|LT}} which gives: 310 tonnes (310 long tons)
Ben MacDui 09:55, 2 June 2020 (UTC)
When there is a trailing "0", then cvt rounds the answer to also have a trailing "0". Try specifying rounding of 0 decimal places: {{cvt|310|t|LT|0}} to give 310 t (305 long tons), or rounding to nearest 5: {{cvt|310|t|LT|round=5}} to give 310 t (305 long tons)  Stepho  talk  10:14, 2 June 2020 (UTC)
As above, but you can also add a decimal point as a clue to convert that the zero is significant:
  • {{cvt|310.|t|LT}} gives: 310 t (305 long tons)
Johnuniq (talk) 10:21, 2 June 2020 (UTC)
Many thanks for your help.
I see that there is reference to this in the instructions but I don't believe it is spelled out very clearly. I had assumed that this was what 'sigfig' (which I have never used) did but was otherwise not part of the system. The text says "By {Convert} default, the conversion result will be rounded either to precision comparable to that of the input value (the number of digits after the decimal point)" - but that is not really true for one number in every ten. If it wasn't for the fact that it is obvious that 310 tonnes are not equal to 310 tons I would not have noticed. I wonder how many similar errors there are out there and indeed what the point of this. Thanks again for your prompt replies. Ben MacDui 12:40, 2 June 2020 (UTC)
It is not an error, as others note. 310 has two significant figures, so the result is given to two significant figures. There are way too many cases not using convert where values are given with excessive digits. Gah4 (talk) 16:36, 8 July 2020 (UTC)
  • Creffett, I feel a Burma-shave may be needed here, perhaps riffing off "16 Tons":
Three-ten tons
and whaddayou get?
Something something
sigfigs yet
Burma-shave

EEng 17:35, 2 June 2020 (UTC) EEng 17:35, 2 June 2020 (UTC)

  • (snooty voice) Oh, sorry, did you say something? I simply don't have the time for you commoners these days. (and it's definitely not that I saw it but forgot to respond). Yeah, this one's eluding me too...got nothing for you after a few minutes of staring at it. creffett (talk) 01:58, 7 June 2020 (UTC)
    Creffett's an admin now so I guess he's too busy. EEng 00:15, 6 June 2020 (UTC)

solid angle

There is a tiny note above regarding angle units, but solid angle is needed too, and deserves its own discussion. There are many links to (non-SI) square degree which should have conversions to SI steradian. Gah4 (talk) 00:52, 10 July 2020 (UTC)

Possible discrepancy in reciprocal units

I have noticed this in my travels:

{{convert|10|/L|/USgal|abbr=off}} → 10 per litre (38 per gallon) [i.e. the output does not disambiguate which gallon is meant]

but

{{convert|10|/L|/impgal|abbr=off}} → 10 per litre (45 per imperial gallon).

This issue seems to arise only with the reciprocal units – 10 litres (2.6 US gallons). Is this a known bug? Archon 2488 (talk) 09:49, 15 July 2020 (UTC)

Probalby needs fixing at Module:Convert/documentation/conversion_data#Per_unit_volume. /gal seems fine though. Only /USgal that has the issue. -- WOSlinker (talk) 10:17, 15 July 2020 (UTC)
10 per litre (38 per US gallon)
I'll contemplate that (I'm wondering why that exception occurs—it was in the original template). It appears the only usage of /USgal (or /usgal) is at Wrightspeed X1#Performance where this tricky wikitext is used:
  • Energy consumption {{convert|200|/mi|/km|abbr=on|order=flip|round=5|disp=preunit|Wh}} in urban use, equivalent to {{convert|170|mpgus|l/100 km mpgimp|abbr=on|round=5}} or {{convert|33705|/USgal|/L /impgal|abbr=on|round=5|disp=preunit|Wh}}
which displays as
  • Energy consumption 125 Wh/km (200 Wh/mi) in urban use, equivalent to 170 mpg‑US (0 l/100 km; 205 mpg‑imp) or 33,705 Wh/gal (8,905 Wh/L; 40,480 Wh/imp gal)
That could probably be cleaned up (and the horrific "0 l/100 km" fixed). Johnuniq (talk) 10:58, 15 July 2020 (UTC)

{{inflation}}

It seems that {{inflation}} doesn't have a sigfig option, only a -r, and often enough gives numbers with too much precision. I mentioned it in the talk page for {{inflation}}, but thought I should mention it here, too, especially since people here know how it works. Gah4 (talk) 18:24, 17 July 2020 (UTC)

In case it hasn't been noticed, {{sigfig}} is available. Johnuniq (talk) 00:07, 18 July 2020 (UTC)
Is that what this one uses to do it? And so {{inflation}} should add that? Gah4 (talk) 00:28, 18 July 2020 (UTC)
No, Module:Convert has some extremely complex code written specifically for what convert needs (based on what the original convert templates used to do). I would not advise looking at the convert code; use the newer templates. If wanted, you might ask for assistance at WT:WPT or WP:VPT. Johnuniq (talk) 01:32, 18 July 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_1&oldid=1160361576"