Template talk:Convert

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

For the Lua module see the Module:Convert.
Convert tagged articles are in Category:Convert error categories
For earlier technical talks, see Technical archives.

Range input by single parameter - tests[edit]

This earlier discussion pointed to the option to enter a rangne of values in by a single parameter:

  • {convert|10|to|20|km|mi}} → 10 to 20 kilometres (6.2 to 12.4 mi) -- classic Green tickY
  • {convert|10 to 20|km|mi}} → {convert|10 to 20|km|mi}} -- new: by single parameter Green tickY

Testpage Template:Convert/testcases/range now has test comparisions of these cases. All Help:Convert#Range options are tested. But not all parameters settings are cross-checked, not many units. Compare:

The next range indicators (separators) give issues:

test setup: {{Convert|5|and|12|kg}} vs {{Convert/sandbox|5 and 12|kg}}
  1. and 5 and 12 kilograms (11 and 26 lb) vs [convert: invalid number]
  2. and(-) 3 and 4 inches (76–102 mm) vs [convert: invalid number]
  3. to about 140 to about 160 km/h (87 to about 99 mph) vs [convert: invalid number]
  4. × 3 by 4 inches (76 mm × 102 mm) vs [convert: invalid number]
  5. ± 3 ± 4 inches (76 ± 102 mm) vs [convert: invalid number]
  6. & 3 and 4 inches (76 and 102 mm) vs [convert: invalid number]
  7. , 1.0, 0.8 metres (3.3, 2.6 ft) vs [convert: invalid number]
  8. , and 1.0, and 0.8 metres (3.3, and 2.6 ft) vs [convert: invalid number]
  9. , or 10, 25 , or 100[convert: unknown unit] -- (not all , or tests) vs [convert: invalid number]
  10. mixed
  1. 3.5, 3.0 and 2.0 m (11 ft 6 in, 9 ft 10 in and 6 ft 7 in) vs [convert: invalid number]
  2. 7.5–16 × 3.5–7.5 cm (3.0–6.3 × 1.4–3.0 in) vs [convert: invalid number]
  3. −7.5 – −16 × −3.5 – −7.5 cm (−3.0 – −6.3 × −1.4 – −3.0 in) vs [convert: invalid number]

Tests are against {convert/sandbox}. Covering all options alike (barred the impossible or contradicting situations) is the goal would be a great feature. Just think of the editos' ease! The simple documentation! -DePiep (talk) 13:01, 11 March 2014 (UTC)

I agree that natural language input would be desirable, but parsing it takes a significant time (and adds code complexity). The way convert currently handles simple ranges like "1 to 9" is that it tries to evaluate the input as a number, and when that fails it searches the input for certain range "words" such as "to" and "-". It takes the first found and splits the input into three components—in the above, that would be "1" and "to" and "9", and it tries again. A more logical approach would be to detect the first number ("1"), then examine what comes after it. However, convert accepts really weird stuff for numbers, and detecting the first number is not easy. We could agree that natural-language input would not work with weird numbers, and that would make parsing a lot easier. Examples of weird numbers are: 1.23e-6 and −12.5 (Unicode minus) and −12.5 (html entity) and +1+2/3 and -1-2/3 (and other, frankly absurd, values are also accepted for fractions). Johnuniq (talk) 04:36, 12 March 2014 (UTC)
If I understand you well, the weird numbers should be excluded from this service. And some symbols (that otherwise would work well in multi-parameter input). That would leave plain text on the could-do list, with en dash (range by MOS) on top. -DePiep (talk) 07:50, 2 April 2014 (UTC)
Yes, that can be in a longer-term to-do list. However, did I mention that en dash now works? However, it's only in the sandbox and is waiting for me to do the update I said I would. Example:
  • {{convert/sandbox|10–15|mm}} → 10–15 millimetres (0.39–0.59 in)
That range is using an en dash. Johnuniq (talk) 08:55, 2 April 2014 (UTC)
My sloppy reading again, sorry. En dash was not even in my error-list above. To complete, these are the tests with negatives. Test: {convert} vs {convert/sandbox}.
  1. −20 – −15 cm (−7.9 – −5.9 in) vs −20 – −15 cm (−7.9 – −5.9 in) -- ndash char used. Green tickY
  2. −20 to −15 cm (−7.9 to −5.9 in) vs −20 to −15 cm (−7.9 to −5.9 in) -- "to" range indicator. Green tickY
These pass OK, together with the other tested options (testpages linked above). -DePiep (talk) 09:25, 2 April 2014 (UTC)

Tonnes per acre ~ tonnes per hectare[edit]

Winemaking needs these units, e.g. in this article.
For example:

  • 3 tonnes per acre (7.5 tonnes/hectare)
  • 4 tonnes per acre (9 tonnes/hectare)

or with |disp=flip when the article does not deal directly with the US or UK.--Carnby (talk) 13:10, 31 March 2014 (UTC)

Done, examples:
  • {{convert|3|tonne/acre|abbr=off}} → 3 tonnes per acre (7.4 tonnes per hectare)
  • {{convert|4|tonne/acre|abbr=off}} → 4 tonnes per acre (9.9 tonnes per hectare)
  • {{convert|12.5|tonne/acre}} → 12.5 tonnes per acre (31 t/ha)
  • {{convert|12.5|tonne/ha}} → 12.5 tonnes per hectare (5.1 t/acre)
  • {{convert|30.9|tonne/acre|disp=flip|abbr=off}} → 76 tonnes per hectare (30.9 tonnes per acre)
The default is to abbreviate the output, so that has to be set to "off" if wanted. Johnuniq (talk) 23:50, 31 March 2014 (UTC)

@Carnby: I'm not sure if you have seen this, but the above units now work. The blunder I mention next does not affect how the units work.

Blunder fixed: When adding the above, I called the units "mass per unit area" as that is the most logical. I had this nagging feeling in the back of my mind that something was wrong because I was sure I had seen units of that type before (but could not find them), as well mention of "spread rate". Now I recall that all the mass/area units were redefined as pressure, with a trick (multiplier = 9.80665) to make the conversions work. That allows conversion between a larger number of units (the module only permits conversions between units of the same type, with a couple of exceptions). I fixed the units at Module:Convert/extra but for the record am putting this explanation here hoping it will help me or others understand this in the future. Search terms: "mass per area" and "mass per unit area" and "mass/area" and "pressure". Archives: Feb 2014 and Oct 2013. Johnuniq (talk) 06:06, 2 April 2014 (UTC)

Thank you, now they seem to work. I have already edited the page about Chianti wine.--Carnby (talk) 10:28, 2 April 2014 (UTC)

That's not ambiguous[edit]

I'm getting an error saying that my convert from feet to m is ambiguous. The help text tells me to use ft instead of feet.

Well, that's definitely not "ambiguous", so the error message is wrong.

Moreover, why am I even getting this error? If the system understands my intent, which it obviously does, why report anything? Do we expect another "feet" that might appear and cause a problem?

Maury Markowitz (talk) 11:14, 2 April 2014 (UTC)

Like in
{{convert|1|feet|m}} → 1 foot (0.30 m)
Well, units don't pluralize in measurements. Maybe the error message could better be "unknown unit", but I doubt if that would help you. -DePiep (talk) 11:32, 2 April 2014 (UTC)
However,
{{convert|1|ft|m}} → 1 foot (0.30 m)
{{convert|2|ft|m}} → 2 feet (0.61 m)
{{convert|2|feet|m}} → 2 feet (0.61 m)
With Maury Markowitz, I am confused. -DePiep (talk) 11:57, 2 April 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Thanks for raising this issue. The following unit codes generate "ambiguous unit" where the unit really is ambiguous and the message is reasonable:

  • gallon • Use "USgal" for US gallons or "impgal" for imperial gallons (not "gallon")
  • gallons • Use "USgal" for US gallons or "impgal" for imperial gallons (not "gallons")
  • pt • Use "USpt" for US pints or "imppt" for imperial pints (not "pt")
  • qt • Use "USqt" for US quarts or "impqt" for imperial quarts (not "qt")
  • mpg • Use "mpgus" for miles per US gallon or "mpgimp" for miles per imperial gallon (not "mpg")

The following unit codes generate "ambiguous unit" where it is not ambiguous:

  • L100km • Use "L/100 km" (not "L100km")
  • feet • Use "ft" (not "feet")
  • light-year • Use "ly" (not "light-year")
  • light-years • Use "ly" (not "light-years")
  • meter • Use "m" (not "meter")
  • meters • Use "m" (not "meters")
  • metre • Use "m" (not "metre")
  • metres • Use "m" (not "metres")
  • kilogram • Use "kg" (not "kilogram")
  • sq feet • Use "sqft" (not "sq feet")

The module is doing something similar to what the old templates did, although the "ambiguous unit" text is my addition—I must have got lazy regarding the second set of units above and not made a separate error code for them. What to do? I'm from the old school where editors should use the "right" unit code because it's confusing if some converts use "ft" while others use "feet" as anyone noticing that is going to wonder what the difference is, and which one they should use. However, we already have aliases like sqm being the same as m2. How about we split the difference and make the following units aliases:

  • feet • Same as "ft"
  • light-year • Same as "ly"
  • meter • Same as "m"
  • metre • Same as "m"
  • kilogram • Same as "kg"

But, remove the following unit codes. If someone uses one of these, the result would be "unknown unit":

  • light-years
  • meters
  • metres
  • L100km
  • sq feet

There is no reason to support plural names for the first three, and no reason to support "sq feet" but not "sq. feet" or "square feet" for the last. Also, I don't see why "L100km" would be needed—it would be very rare that an editor would type that? Thoughts? Johnuniq (talk) 05:37, 3 April 2014 (UTC)

L100km is wrong and so not acceptable.
m and ft: hell, the plural is in the outcome! How could it be unacceptable for the input?
5 metres (16 feet)
5 square feet (0.46 square metres)
light-years not commonly used, but the plural seems not confusing. -DePiep (talk) 06:54, 3 April 2014 (UTC)
I don't see the point in adding aliases unless they really are needed. Each alias is inconsequential, but taken together they add complexity. Johnuniq (talk) 08:46, 3 April 2014 (UTC)
Hard to argue against that, but I'd thought once one alias is in, it's only more of the same. -DePiep (talk) 20:23, 3 April 2014 (UTC)

Johnuniq, I will not belittle your point about redundancy, but let me offer a personal take on this… HyperTalk was easy to program because they deliberately added such redundant terms, specifically so that people using it would be able to write code their way instead of the programmers. The Wiki, one might argue, should be easier to use than a programming language, so I vote in favour of making your life harder if that makes mine easier. See, so easy! :-) More to the point, I think "gotchas" like this one are precisely the sort of thing we should avoid if possible, and I'd much prefer to have "feet" work. But I leave it to you to decide whether this would complicate the back end too much. Maury Markowitz (talk) 22:55, 3 April 2014 (UTC)

OK, I have updated my files with the changes I proposed above, except I made "meters" and "metres" an alias for "m" rather than removing them. That will go live in the next release...not sure when that will be. Thanks again for pointing out the inappropriate message. Johnuniq (talk) 23:48, 3 April 2014 (UTC)
  • Convert/old was overly restrictive about full names: As noted, the prior rejection of "feet" as a unit-code was started with {convert/old}, but there was no technical reason, perhaps only a fear of people using full names mixed for any unit "miles per hour" or "mi per hour" or hundreds of other combinations. In fact, unit-code "miles" and "acres" were used to test new features in {convert/old}:
  • {convert/old |4|feet|m}} →
    ERROR {{Convert}}: Use "ft" (not "feet") as the unit code. Try:{{convert|4|ft|m|...}}.
    For other unit codes, see: Template:Convert/list of units.
  • {convert/old |7|miles|km}} → 7 miles (11 km)
  • {convert/old |9|acres|ha}} → 9 acres (3.6 ha)
  • {convert/old |9|acres|hect}} → 9 acres (3.6 ha)[fix unit]
When {convert/old} displayed the large, orange error messages, people still left errors in pages for months, and so small superscript notes "[fix cite]" were used instead. The unit-code "acres" was the first to autofix invalid "hect" as being "ha" with a warning. After years of allowing full name "|miles" for the "|mi" unit-code, no drawbacks were found, and nobody complained likewise that "|kilopascals" should be allowed now as a unit-code. -Wikid77 11:25, 4 April 2014 (UTC)

Protected edit request on 5 April 2014[edit]

Under "Range of 2 values" one of the examples appears to be wrong. It says that

{{convert|60|by|120|ft}}

displays as

60 by 120 metres (200 by 390 ft)

but it actually displays as

60 by 120 feet (18 by 37 m)

(which is what I would expect - the specified unit is the "from" unit, not the "to" unit.)

Could someone fix it please. (Or explain what I'm doing wrong.)

Mitch Ames (talk) 07:48, 5 April 2014 (UTC)

The error was on the unprotected Template:Convert/doc, which could be edited by anyone. I have fixed the error. Imzadi 1979  07:59, 5 April 2014 (UTC)
Thanks for reporting this, but in case you did not notice, be sure to look at Help:Convert which has some more up-to-date information. All the documentation (here and at Help:Convert) needs fixing, and is on my to-do list. Johnuniq (talk) 09:48, 5 April 2014 (UTC)

st changed from 'short tons' to 'stone'[edit]

Hello all - 'st' in the template seems to have been changed from 'short tons' to 'stone' at some point in the past... few months? This has thrown out lots of articles, like HMS Richard Bacon, where short tons are now reporting as stone. Could this be fixed somehow please? Chase me ladies, I'm the Cavalry (Message me) 18:31, 5 April 2014 (UTC)

No, I think st has been stone for a long time (see the history of the old template, now unused, at Template:Convert/st). Both LT and lt are long tons with a tiny difference (see mass units), but ST is short tons while st is stone. After checking that it makes no difference for how lt is used in the article, I changed all lt to LT and all st to ST (diff). Johnuniq (talk) 22:22, 5 April 2014 (UTC)
Thankyou Johnuniq! Chase me ladies, I'm the Cavalry (Message me) 22:06, 8 April 2014 (UTC)

ktTNT[edit]

The ktTNT parameter should probably output as kiloton and not kilotonne is what is used on the main page, TNT equivalent. This is not the unit of mass, so it is unclear that the current spelling is in any way correct. If it is determined that the current spelling is correct, the template should respect the sp=us parameter. Vegaswikian (talk) 22:45, 5 April 2014 (UTC)

The system of units grew over several years as people asked for different things; the result is a bit confusing. The following units are available (the full list is here):
unitcode   link             default   symbol              name1              name1_us
kt(TNT)    TNT equivalent   TJ        kt                  kilotonne          kiloton
ktonTNT    TNT equivalent   TJ        kt                  kiloton of TNT     --
ktTNT      TNT equivalent   TJ        kilotonne of TNT    kilotonne of TNT   --
That means that kt(TNT) changes its name with sp=us, but the others don't. I do not know what is correct, and am just reporting what I know about convert. Johnuniq (talk) 23:32, 5 April 2014 (UTC)
Thanks. These probably need to be reduced to one with a bot cleaning up the other options and then dropping support. Vegaswikian (talk) 18:25, 7 April 2014 (UTC)

Module version 3[edit]

Quite a lot of changes to the module have occurred, and I have updated the sandbox modules to the latest versions. I intend switching the main modules to use the sandbox soon.

Following is an overview of the changes.

  • Move units from Module:Convert/extra to main data.
  • Adjust some "should be" units, for example "feet" will be the same as "ft" rather than an incorrect "ambiguous unit" error message (see discussion).
  • Range and(-) now gives "and" for input and "–" (en dash) for output, instead of "and" for both.
  • More range words are possible in a "simple range" like {{convert|1–5|ft}} (a range using en dash).
  • Fix problem introduced in version 2 whereby a convert using a range loaded Module:Convert/extra because it looked the range word up as a unit.
  • Fix glitch in processing some unknown input units.
  • Fix some singular/plural issues, mainly for output multiples like ftin which could produce "1 12 inch" (incorrect singular) instead of "1 12 inches" (correct plural).
  • Adjust processing of adj=mid option so other wikis can disable hyphenation.
  • Make decimal mark and thousand separator more versatile for other wikis; also, can specify values in convert/text.
  • Template:Convert/sandbox now uses |sandbox=sandbox instead of |sandbox=on so the sandbox name can be specified at other wikis.
  • Remove assumptions regarding position of SI prefixes in SI units for more flexibility at other wikis.
  • For other wikis, can set abbr to be "on always" or "off always" or "on default" or "off default".
  • For fawiki, if looking up a unit fails, try again after translating any digits from the local language (they run a script to translate all English digits which, for example, changes "km2" to "km۲").

By the way, I have updated the transwiki guide which includes a link to a new translate page. Johnuniq (talk) 03:50, 6 April 2014 (UTC)

Looks good! Thanks! Plastikspork ―Œ(talk) 14:15, 6 April 2014 (UTC)
I second that. Both the module/template and the development process are a pleasure to work with. -DePiep (talk) 14:55, 6 April 2014 (UTC)
  • Done, the modules have been updated. Thanks for the encouragement! Johnuniq (talk) 00:26, 8 April 2014 (UTC)

Some missing units[edit]

Some missing units: I have noticed "e6ST" had been missing "million": {convert/old |9|e6t|e6ST}} as "9 million tonnes (9.9 million short tons)" not as "9 million tonnes (9.9×10^6 short tons)" and might need others not copied from {convert/old}. -Wikid77 (talk) 17:56, 10 April 2014 (UTC)

Is there a problem? Consider:
  • {{convert|9|e6t|e6ST}} → 9 million tonnes (9.9×10^6 short tons)
  • {{convert|9|e6t|e6ST|abbr=off}} → 9 million tonnes (9.9 million short tons)
  • {{convert|9|e6t|e6ST|abbr=on}} → 9×10^6 t (9.9×10^6 short tons)
  • {{convert/old|9|e6t|e6ST}} → 9 million tonnes (9.9 million short tons)
  • {{convert/old|9|e6t|e6ST|abbr=off}} → 9 million tonnes (9.9 million short tons)
  • {{convert/old|9|e6t|e6ST|abbr=on}} → 9×10^6 t (9.9 million short tons)
That seems ok? Johnuniq (talk) 23:10, 10 April 2014 (UTC)
yes, seems to be fine, and actually an improvement over the old version. Frietjes (talk) 23:46, 10 April 2014 (UTC)
  • Johnuniq Has it been considered to allow the "e6" notation into the number input (in some form), not the unit input? search for "e6 e9" in archives -DePiep (talk) 12:29, 13 April 2014 (UTC)
    • could be useful, considering that 9e6 t (9,900,000 short tons) sort of works. Frietjes (talk) 18:59, 13 April 2014 (UTC)
Well, that is a bit small. Some "e6" in some form notation is common and general numeric notation, so for a Grand Convert module it should be target functionality. I know it might imply a big redesign of the module, but now that we are freed of the old wikicode templates, we could aim for that. -DePiep (talk) 20:38, 13 April 2014 (UTC)
Yes, I have wondered about the fact that input like 12.5e6 is accepted and does not give a good result (it shows the input as 12.5e6). I'll probably need to be reminded/prodded in a couple of months. Johnuniq (talk) 02:56, 14 April 2014 (UTC)

For Chaldron#Coal please add 52 12 cwt[convert: unknown unit] {{convert|52+1/2|cwt|lb kg|abbr=on|lk=on|disp=or}} Peter Horn User talk 01:30, 14 April 2014 (UTC)

Please use "long hundredweight" or "short hundredweight", see hundredweight.
The list of all units is disconcertingly large, but useful for searching. See Help:Convert which links to Help:Convert units which has the full list. Johnuniq (talk) 02:56, 14 April 2014 (UTC)
Thanks Peter Horn User talk 02:58, 15 April 2014 (UTC)

Again for Chaldron#Coal, how does one convert the likes of 36 bushels Winchester bushel? Peter Horn User talk 03:32, 15 April 2014 (UTC)

That's pretty obscure, and I don't think it's worth adding to {{convert}}. Following Winchester bushel shows that it is a redirect to bushel, and the only mention of "winchester" on that page is a "see also" link to Winchester measure. It looks like there were several historical usages of that measure, with differing details. The reference in Chaldron is this page at Google books, and it gives a very unclear statement of what is meant. It appears a London chaldron was specified as a volume equal to 36 somethings, where each something is a "Winchester bushel and a quart", being 19.5 inches diameter externally (no height specified). Winchester measure suggests that one kind of Winchester bushel was a cylinder 18.5 inches diameter internally, with 8-inch height. Quite a bit of research/thinking would be required to sort all that out, and ultimately the exact value would depend on which variation was being referred to. Google shows some interesting hits, but not much clarity. Johnuniq (talk) 11:18, 15 April 2014 (UTC)

fraction slash[edit]

{Convert} now accepts the slash in fractions.

  • {{convert|3+1/2|m|in}} → 3 12 metres (140 in)

This is the keyboard slash U+002F / slash (HTML: /). In typography, and in our {{frac}}, another character is used: 3 12. That is U+2044 fraction slash (HTML: ⁄ ⁄).

We could consider that if it is correct in typography, {convert} should accept it as correct number input.

I met this when I did a copy-paste with a frac number. There also exists U+2215 division slash (HTML: ∕), which I have not researched yet. I note that with fractions input, the ambivalent "3-1/2" input is still accepted: 3 −12 metres (2,500 mm). -DePiep (talk) 10:22, 13 April 2014 (UTC)

Sorry to be a wet blanket, but unpicking the code that parses input numbers, including fractions, still is unappealing. One problem is that there are several alternatives that might be useful once or twice—if supporting fraction slash, why not support ⁄ and ⁄ because they look the same when viewing wikitext? I would have thought that using fractions for input was fairly rare, and since an editor has to insert a + before the numerator, they may as well also use a plain slash. I agree that accepting 3-1/2 to mean 2+1/2 is a bad idea. I'll put that on my to-do list. Johnuniq (talk) 02:29, 14 April 2014 (UTC)
  • Fractions are more rare than dash ranges: Indeed, fractions are extremely rare in conversions, when compared to dash-ranges, although ironically, in real-world text, the text-slashes are 3x times more common than dashes (as in "April/May"). Consequently, {convert} has needed to handle unicode en dash "–" in several pages. So rather than support &frasl input, the higher priority is for dash-ranges or wp:non-breaking hyphen (&8209), as follows:
Currently, when people request unusual formats, we suggest they hand-code the conversion with whatever slashes or other characters are needed in the output. -Wikid77 (talk) 05:29, 14 April 2014 (UTC)
No priority or tradeoff was claimed here. It is just that the (higher) aim should be to accept accepted numbers. -DePiep (talk) 17:18, 14 April 2014 (UTC)

Spelling[edit]

For Chaldron#Coal {{convert/spell|1|impqt|L USqt|lk=on}} one imperial quart (1.1; 1.2 L; US qt) as compared to {{convert|1|impqt|L USqt|lk=on}} 1 imperial quart (1.1 L; 1.2 US qt). Something is going wrong in the former. Peter Horn User talk 03:25, 15 April 2014 (UTC)

Please see Help:Convert#Spell for how spelling is handled now (all templates of form convert/xxx are from the old system and have been replaced by {{convert}}). Example:
I changed the section name from "A bug" to "Spelling" which might help others find this in the future. Johnuniq (talk) 07:35, 15 April 2014 (UTC)