Template talk:Convert

Fix for rounding - consensus forum

09-Oct-2009: Many people above have already expressed support for changing the default rounding, and others already append a round parameter "0" or "2" when using Convert. This forum here is just to log any concerns people have, before changing the default rounding. Note that this change would not be "set in stone" as the final change ever made to Template:Convert. Other changes will come in the future.

Proposal: Change the default rounding to increase precision by +1 for conversions over 2.0 times greater. This affects numbers that increase, such as: 32 m (105 ft) [from 100ft], 84 kg (185 lb) [from 190] or 16 ft 2 in (188 cm) [from 190], where the 2nd number is larger, but not 10-to-5 or other smaller conversions. Also, it does not affect miles-to-km because miles are only 1.61 km (or "1.609344"), below the factor of 2.0.

Consensus status 2009-10-30: By the end of October (3 weeks), there had been no formal oppose comments; however, the exact impact of the change was questioned by multiple people, and there was only one support comment.

Comments on proposed rounding

Add comments, about the above proposal, in the subsections below. The reasoning, behind changing the default rounding, is presented in the section above: "#Fix for rounding - rationale".

Support the proposed rounding

Strong support. Many people are concerned, and the fix will match world-standard amounts. Novice users or young teenagers will be able to just code "{{convert|32|m}}" or height "{{convert|6|ft|2|in}}" without concern for significant digits or metric precision. Meanwhile, any alternative rounding-tactics could be considered for future updates. This would not be mandated as somehow the final change for rounding in Template:Convert. -Wikid77 (talk) 13:56, 9 October 2009 (UTC)

Oppose the proposed rounding

Log any objections or major concerns in this section:

Oppose. (...followed by reason why...)

Other comments

I'm not 100% sure I understand the proposal. Now the template specification says:

If neither the desired precision nor the desired number of significant figures are specified, the conversion will be rounded either to a comparable precision as the input value (the number of decimals remains the same if the conversion is a multiplication by a number between 0.2 and 2, is decreased by 1 if the factor is between 2 and 20, etc.) or to two significant figures whichever is the most precise.

Is this a proposal to change “between 0.2 and 2” to between 1 and 10, “between 0.2 and 2” to between 10 and 100 and so on? And what would become of the two-significant-figure exception? And what about the exception for temperatures, whose purpose I've never understood? --___A. di M. 14:19, 9 October 2009 (UTC)

• The proposed change would stop the "decrease by 1" for factors over 2, of conversions going to higher counts. For example, the 3-digit "105ft" would still decrease to the 2-digit precision "32m" (not as a 3-digit "32.0m"). As you can see, there are some "man-made" shifts being made to avoid decimal-point "32.0", but the goal is to present rounded numbers as customary in general use, without 32 becoming "31". I will check the affect on temperatures, such as boiling point 100C as 212F (scale factor: 2.12). Thanks for the input & for adding the "Other comments" section. -Wikid77 (talk) 16:12, 9 October 2009 (UTC)

• Temperatures would be unaffected - The proposed change would only alter the subtemplate {{Convert/round}}, which is not used for temperature conversions, which instead use templates: Convert/roundT and Convert/roundT0 (plus Convert/proundT or Convert/proundT0) to handle either the default or user-specified rounding for more/less temperature precision. -Wikid77 17:15, 9 October 2009

We need more clarification. It is not at all clear what is being proposed. I would support a change to something like:

... the conversion will be rounded to one more significant figure than the input value ...

because that is a standard rule-of-thumb for doing unit conversions where the objective is not to lose any precision, and as a consequence produces results that people are familiar with (e.g. the conversion of 37°C to 96.8°F for human body temperature, or 8848 m to 29,029 ft for the height of Mount Everest). (BTW, if you use the ...one more significant figure... rule, the ...or to two significant figures whichever is the most precise clause is redundant.) RockyMtnGuy (talk) 16:29, 9 October 2009 (UTC)

• Okay, I think that wording is what would occur. However, temperatures are a separate rounding issue, which we could discuss as a major topic at bottom. -Wikid77 17:15, 9 October 2009

As of now, the template works in terms of the position of the significant digits, not in terms of their number, which is entirely reasonable: for example, there's no obvious reason to suppose that 98.7 is any more or any less precise than 101.2; now they convert to 98.7 kilometres (61.3 mi) and 101.2 kilometres (62.9 mi), which is entirely reasonable. You two want to make it work in terms of the number of significant digits instead, but I don't see the point of this change. Also, you draw a distinction between "conversions going to higher counts" and "conversions going to lower counts" whose point I don't get. If 2.34 yards (214 cm) rounds to the nearest centimetre, 2.34 yards (2.14 m) should (and does) round to the nearest centimetre, too; I don't see the point to make this distinction. (However, I'm not 100% sure I understand your proposal completely correctly.) In other words, I think that the general idea of the template as it works now is fine, only that the thresholds should be increased. FYI, the scale factor between Celsius and Fahrenheit is 1.8 not 2.12, because the difference between 100.0 °C and 101.0 °C equals that between 212.0 °F and 213.8 °F; so a value given to within ±1.0 °C corresponds to one given to within ±1.8 °F. The obvious way to deal with temperatures would be to drop the current exception, so that values given to within a tenth of a degree Celsius convert to within a tenth of a degree Fahrenheit and vice versa, those given to within one degree Celsius convert to within one degree Fahrenheit and vice versa, and so on. ___A. di M. 19:32, 9 October 2009 (UTC)

• Look. [192.5 yd, 193.5 yd] equals [176.022 m 176.9364 m], and 176 m isn't contained in this interval. Do you seriously suggest that "193 yards" should convert to "176.5 m", even if it's very unlikely that the precision of the original measurement was anywhere near 10 centimetres, making the final "5" essentially a random digit? --___A. di M. 18:55, 10 October 2009 (UTC)

I agree there needs to be a clarification of wording, perhaps: "The displayed amount needs to be within the bound limits when similarly rounded: if the bounds are 176.2-176.3, then the only rounded choice would be 176." -Wikid77 (talk) 21:18, 10 October 2009 (UTC)

You'd need to more precisely explain what you mean by "similarly rounded"; I think the current system is generally fine except that the thresholds should be increased so that 185 lb is considered to have "comparable precision" to 84 kg rather than to 80 kg. ___A. di M. 14:40, 11 October 2009 (UTC)

• By the end of October 2009, the proposal-consensus was still uncertain; see "Consensus status" above at: #Fix for rounding - consensus forum. -Wikid77 (talk) 15:02, 30 October 2009 (UTC)

Problems when applied to firearms data

Is it necessary to apply this template to firearms caliber data? The output is just awful-looking (and many calibers are not exact measurements anyway but are used out of tradition in reference to an earlier cartridge or gun).

an example: two .30 inches (7.62 mm) and two .50 inches (12.7 mm) machine guns

This is just plain awful. Anyone who actually wrote like this would be showing a complete lack of familiarity of firearm nomenclature. It would be fine to use the template for measurements like barrel length or weight but applied to caliber, it makes the text unwieldy. The metric units are abbreviated, why aren't the imperial units abbreviated?SEWalk (talk) 00:08, 29 October 2009 (UTC)

Well, the functionality issues are explained in the documentation, but in short, you would use "sing=on" to make the input units singular, or "|abbr=on" to make both input and output units abbreviated. Also, this template has to be applied intelligently. There are some measurements that just aren't meant to be converted (in my opinion), and firearm calibre data is one of those. One alternative is to present the calibre data, then provide the conversions in parentheses. For example: "two .30 inch and two .50 inch machine guns (7.62 mm and 12.7 mm)". — Huntster (t @ c) 02:30, 29 October 2009 (UTC)

• About singular/plural inches, I noticed that fractions should be singular (a half inch is 0.5 inch), but zero is plural (as "0 inches"). So the output should be ".30 inch (7.62 mm)" and such. There might be 70 subtemplates that choose plural/singular. -Wikid77 (talk) 05:49, 29 October 2009 (UTC)

• Well, anything x<1<x would be "inches" so long as it is in decimal format (as this is). Fractions would indeed be read as, for example, 1/2 inch. But in this specific situation, the measurement is an adjective of "machine guns", so ".30 inch" is correct. Again, this firearm situation is a good example of where Convert (or any other template) shouldn't be used. For general situations, I'm not sure additional detection and processing is needed when "sing=on" or "adj=on" fixes the problem. — Huntster (t @ c) 07:00, 29 October 2009 (UTC)

Okay, using the current operation of Convert:
                {{convert|1/2|in|cm}}          gives: 1⁄2 inch (1.3 cm)
                {{convert|1/2|in|cm|abbr=out}}   gives: 1⁄2 inch (1.3 cm)
I guess we could allow "abbr=out" to display singular-fractions until we decide how to handle this. Many people use plural "0.5 inches" and most people also say "email" when the correct spelling was "e-mail". Perhaps there should be a new option "singfrac=on" when users prefer the singular form. -Wikid77 (talk) 12:53, 29 October 2009 (UTC)

As far as I can see, there are several issues here. The first is that it should say "calibre" (US "caliber") instead of "inches". The second is that many designations are nominal calibres rather than actual calibres. For instance, a ".38 calibre" bullet is actually 0.357 calibre.

• .38 inches (9.7 mm)
• .357 inches (9.1 mm)
• .50 inches (13 mm)
• .30 inches (7.6 mm)

The third is that default precisions give conversions that are not the traditional ones. You can handle this by adjusting the precision:

• .38 inches (10 mm)
• .357 inches (9 mm)
• .50 inches (12.7 mm)
• .30 inches (7.62 mm)

But this still doesn't correct for the fact that a .38 is really .357 calibre. (This is similar to the fact that a new "2x4" piece of wood is really a 1.5 by 3.5 inches (38 by 89 mm) piece of wood). You also have a bunch of nominal calibres such as the .303, .306, and .308 that are actually all .30 calibre. You might have to handle these conversions manually. RockyMtnGuy (talk) 18:50, 30 October 2009 (UTC)

• That is a good reason to have a special template to "map" rather than calculate the conversions of unit name "caliber" ("calibre"), as discussed below. -Wikid77 (talk) 00:50, 31 October 2009 (UTC)

Smart conversion templates for special subjects

A new, special template (named {{Convert/calibre}} ) has been created now to "map" rather than multiply/calculate the conversions of unit name "caliber" ("calibre"). It uses a lookup table to display the equivalent(s) for a .38 (feel free to edit & add others):

• {{Convert|.38|calibre|mm|sp=us}}   gives:   .38 calibre

A similar situation would be the mapping of wrench sizes: as {{Convert|9/16|wrench|mm}}. Internally, the main Template:Convert would invoke a subtemplate named "Convert/wrench" which does not have to use a multiply, but instead, could simply display the equivalent metric-size wrench (from an internal list). Also, in music, {{Convert|c#|note|hertz}}, could map the major musical notes named among C-B, c-b (etc.) into the equivalent standard frequencies, such as A=440 Hz. Those are examples of what I call smart templates:

• {{Convert/calibre}} - displays the mm equivalents for weapon calibre
• {{Convert/wrench}} - displays equivalents for inch or mm wrenches
• {{Convert/note}} - displays Hertz for musical notes
• Convert/board - displays actual (typical) dimensions of boards

Within just a few hours, a new conversion subtemplate could be created to avoid the repeated research to find what frequency is a "high C# ". Once we wrote the first such map-lookup subtemplates, other users could create copycat variations for each special field. Each special subtemplate (such as "Convert/calibre") does NOT need to invoke any other templates: just use parameters {{{1}}} & {{{2}}} (or {{{3}}}) and display the calibre and mm values from inside that one template. Each subtemplate can be a self-contained unit, and they do not need to look like copies of the weight Template:Convert/kg or such. -Wikid77 01:32, 31 October 2009

• For piano keys, now use: {{convert|high C# |note}} for:   . -Wikid77 (talk) 02:06, 16 November 2009 (UTC)

New abbreviation options: abbr=in or abbr=out

29-Oct-09: I have begun implementing options to control the input versus the output-abbreviations (similar to linking as options lk=in or lk=out). There are now 5 settings for abbreviation:

• abbr=off, abbr=on, abbr=in, abbr=out & abbr=none.

This is the first time it has been possible to abbreviate just the input units, using abbr=in, and leave full-word form as the output: such as "xx km (xx miles)":

{{convert|16|cm|in|abbr=in}}   gives: 16 cm (6.3 inches)

{{convert|4|kg|lb|abbr=in}}       gives: 4 kg (8.8 pounds)

{{convert|6|ft|3|in|cm}}                 gives: 6 feet 3 inches (191 cm)

{{convert|6|ft|7|in|cm|abbr=in}}      gives: 6 ft 7 in (201 centimetres)

For many conversions, the default has been "abbr=out" so that the km/mi conversions have stated "xx kilometres (xx mi)". I added the options (in/out) for completeness, to allow anything: in, out, both or none. However, I see the logical preference as abbr=in, because for most articles where the culture is metric, then "km" would be obvious, but other readers might wonder about "mi". The use of abbr=in gives "xx km (xx miles)" and also avoids the end-spelling of -metre/meter which has been irritating to some readers. Anyway, this is the first time for users to have a choice of abbreviating just the input unit-names. -Wikid77 (talk) 12:53, 29 October 2009 (UTC)

Change to default rounding ft-inches

30-Oct-2009: Following the discussion above at "#More unhelpful default conversions", the default rounding for ft&in will has been changed to match world-standard conversions, such as "6 feet 1 inch (185 cm)" rather than 190 cm. (Installed: 1-Nov-2009 at 14:36).

Proposed conversion	Current conversion
5 ft/sandbox	5 feet 11 inches (180 cm)
6 ft/sandbox	6 feet 0 inches (183 cm)
6 ft/sandbox	6 feet 1 inch (185 cm)
6 ft/sandbox	6 feet 2 inches (188 cm)
6 ft/sandbox	6 feet 3 inches (191 cm)
6 ft/sandbox	6 feet 4 inches (193 cm)
6 ft/sandbox	6 feet 5 inches (196 cm)
6 ft/sandbox	6 feet 6 inches (198 cm)
9 ft/sandbox	9 feet 0 inches (274 cm)
9 ft/sandbox	9 feet 11 inches (302 cm)
10 ft/sandbox	10 feet 0 inches (305 cm)
10 ft/sandbox	10 feet 1 inch (307 cm)
10.0 ft/sandbox	10.0 feet 0 inches (305 cm)
5 ft/sandbox	5 feet 11 inches (1.80 m)
6 ft/sandbox	6 feet 0 inches (1.83 m)
6 ft/sandbox	6 feet 1 inch (1.85 m)
500 ft/sandbox	500 feet 0 inches (152.40 m)
500 ft/sandbox	500 feet 1 inch (152.43 m)
600 ft/sandbox	600 feet 0 inches (182.88 m)
600 ft/sandbox	600 feet 1 inch (182.91 m)
601 ft/sandbox	601 feet 0 inches (183.18 m)
New: Convert/and/in/sandbox	Current: Convert/and/in

The new display will show "x.xx m" as 2-decimal places, for precision to the inch-level, because 1-decimal ("0.1 m") gives only about 4-inch precision (1 decimetre = 3.937 inches). Comments by 4 people confirmed that the change will be an improvement. The comparison of old-versus-new is listed in the table (at right). The proposed new coding is in sandbox-area subtemplate {{Convert/and/in/sandbox}}, with testing triggered from subtemplate {{Convert/ft/sandbox}}.

The change will affect only the conversions of ft-inches, so other conversions, such as km-to-miles, will NOT change, and feet-only conversions of ft-to-m or ft-to-cm will not change.
A prior forum, above, discussed a proposed change to all default-rounding values, but the overall change was considered too confusing, so only ft&inches will be changed at this time. The table is intended to show a cross-section of examples, but more could be added to that table, using "ft/sandbox" rather than "ft" as the 1st unit.
This change has taken months to diagnose, implement, and test, due to the time needed to ensure that no other conversions would be affected. Other rounding should be discussed as a separate talk-topic. -Wikid77 17:00, 30 October 2009 (UTC)

• The change was installed on Sunday, at 14:36, 1 November 2009 (UTC), to begin reformatting over 19,250 articles. Currently, many basketball players are growing (or shrinking) by an inch or 2! (or 0.05 m). Despite all the talk of putting the round-parameter ("0"), many users, naturally, had used the default precision; see infobox in the ship article "USS Charleston (PG-51)" as one example of improvement in those 19,250 articles. -Wikid77 (talk) 17:18, 1 November 2009 (UTC)
  • Good, but I would have just increased the thresholds from 2 to √10 so that (for example) kilograms-to-pounds conversions, or "plain" inches to centimetres, would have increased precision as well. Having ad hoc tweaks for a particular conversion feels kludgy to me, and should only be done when there's strong precedent in the "real world" to do so (e.g. metres-to-feet, which with the √10 rule would round whole metres to tens of feet, whereas they are usually rounded to whole feet). ___A. di M. 20:35, 1 November 2009 (UTC)

New conversion available

I'm not sure if you folks usually announce new templates, but per my question above (Template talk:Convert#Guide to creating a new subtemplate) I created two new sub-templates: Template:Convert/lb/sqft and Template:Convert/kg/m2. - Trevor MacInnis ^contribs 01:00, 31 October 2009 (UTC)

• Thanks. So far, this talk-page had been our only notice. Using a separate category, then we could list it, to see new subtemplates. I have created "Category:2009 Convert unit subtemplates", so insert that category-link at the bottom of new templates. -Wikid77 (talk) 06:31, 31 October 2009 (UTC)

New Template:Convert/wrench

31-Oct-2009: I have created another smart-conversion template, as {{Convert/wrench}} and {{Convert/spanner}} to display the related wrench (spanner) sizes. For sizes that don't quite fit, I have used the term "(loose 3/4)" or "(loose 1/8)" (etc.) because sometimes, bolts have odd sizes (or outer deposits) that allow a loose wrench to fit. Some examples:

{{convert|3/4|wrench|mm}}              gives:   3⁄4 wrench

{{convert|1/8|wrench|mm}}              gives:   1⁄8 wrench

{{convert|17|wrench|inch}}              gives:   17 wrench

{{convert|22|wrench|inch|sp=us}}    gives:   22 wrench

If anyone has some extra time, please proofread that template, and add other metric sizes. I have listed from 1-26mm so far, in #switch-blocks, so just add the other official sizes. (When the size is 1mm less, I put "loose 17/16" etc.) I just guessed at most sizes, putting 26mm as a "1-inch" size. Anyway, Template:Convert/wrench is another example of the next-generation smart templates. Thanks, to everyone, for suggesting these new templates and docpages. -Wikid77 (talk) 06:31, 31 October 2009 (UTC)

Bug in sorting: Breaks for negative numbers

This template uses "padleft" to generate sort keys, which is ignorant of minus signs (e.g. "-1" gets padded to "00000000000000-1", which is not a valid number). This breaks table sorting for negative values, such as temperatures. Example:

Substance	Freezing point (C)	(F)
Water	0	32
Bromine	−7.1	19.2
Mercury	−38.72	−37.70
Cesium	28.55	83.39

(The (F) column actually cycles through four different states as you click the sort button rather than two, for a reason I don't understand because the negative number is interpreted as text and the positive ones are interpreted correctly as numbers.)

I'm not sure of the best way to pad a number that handles minus signs correctly, but if I did this should be pretty easy to fix. —Keenan Pepper 09:08, 1 November 2009 (UTC)

• Thank you for reporting that problem of minus-signs with sortable=on. For now, try using new option "disp=output only" (rather than "disp=table") in a separate, hand-coded column with align=right. For example, {{convert|0|C|F|disp=output only}} to give "32 °F":

Substance	Freezing point (C)	(F)
Water	0	32 °F
Bromine	-7.1	19.2 °F
Mercury	-38.72	−37.70 °F
Cesium	28.55	83.39 °F

For simplicity, set each entire row as "|- align=right" and then prefix each word-column as "| align=left| Water" (etc.). Numbers can be padded by adding spaces "28.55{{in5}}" for 5-space right-side padding. Perhaps we can fix the sorting inside "disp=table" to handle the minus-sign problem. -Wikid77 13:51, 1 November 2009

Maybe you can take a look at Talk:Critical point (thermodynamics)#Table sorting broken and suggest how to fix that table. —Keenan Pepper 18:42, 1 November 2009 (UTC)

• I changed the table in article "Critical point (thermodynamics)" to become 2 tables, with an upper table for the top headings, and the lower table to have sortable columns. Then, I used a different Convert subtemplate by "abbr=none" to put real hyphen-minus signs in the temperatures to allow numeric sorting of the temperatures. Sorry I don't have more time now. -Wikid77 (talk) 13:12, 3 November 2009 (UTC)

Temperature range dash is wrong

See the converted range at Carbon_steel#Higher_carbon_steels. There shouldn't be any spaces and it should be a – dash not a - dash. Wizard191 (talk) 21:18, 2 November 2009 (UTC)

• Thanks for reporting that. I changed subtemplate Template:Convert/Dual/LoffAoffDxSoffT to display an &ndash when the range is a hyphen-style separator "-" as in {{convert|1426|–|1538|C|F}} which displays: 1,426–1,538 °C (2,599–2,800 °F). -Wikid77 (talk) 13:12, 3 November 2009 (UTC)

Thanks! Wizard191 (talk) 13:53, 3 November 2009 (UTC)

Suppressing commas in temperatures

04-Nov-2009: For temperature conversions (only), I am using "abbr=comma" to abbreviate (remove) commas from extreme temperatures. So, the results are as follows:

• {{convert|1426|C|F}}                       gives: 1,426 °C (2,599 °F)
• {{convert|1426|C|F|abbr=comma}}   gives: 1,426 °C (2,599 °F)
• {{convert|3500|F|C}}                       gives: 3,500 °F (1,930 °C)
• {{convert|3500|F|C|abbr=comma}}   gives: 3,500 °F (1,930 °C)

The option "abbr=comma" can also be used when comma is the separator ("disp=comma") to simplify the results: 3,500 °F, 1,930 °C. -Wikid77 (talk) 16:38, 4 November 2009 (UTC)

Surrounding conversions to round by 5

04-Nov-2009: In some instances, a converted result should be rounded to the nearest 5 units, rather than the nearest 1 unit. For now, this can be done by using a math-expression outside a conversion. The algorithm is:  round5 = (n/5 round 0) * 5. For example, in metres-to-feet:

• Precise:  80.0 metres (262.467 ft) and 93.0 metres (305.118 ft)
• Round 80 m, {{#expr:({{convert|80|m|ft|3|disp=output number only}}/5 round 0)*5}} for: 260 ft
• Round 93 m, {{#expr:({{convert|93|m|ft|3|disp=output number only}}/5 round 0)*5}} for: 305 ft

In general, for any number rounded to the nearest 5:

• Rounding 13.11 by 5: {{#expr: (13.11/5 round 0) * 5}} gives: 15
• Rounding 15.34 by 5: {{#expr: (15.34/5 round 0) * 5}} gives: 15
• Rounding 19.44 by 5: {{#expr: (19.44/5 round 0) * 5}} gives: 20
• Rounding 32.48 by 5: {{#expr: (32.48/5 round 0) * 5}} gives: 30
• Rounding 32.51 by 5: {{#expr: (32.51/5 round 0) * 5}} gives: 35

Larger numbers will require removing commas by {{formatnum: 1,234|R}}:

• Round 967 m, {{#expr:({{formatnum: {{convert|967|m|ft|3|disp=output number only}}|R}}/5 round 0)*5}} for: 3175 ft

Although the need to round by 5's is rare, similar coding can be used to adjust the results in other ways. -Wikid77 (talk) 16:38, 4 November 2009 (UTC)

Cubic conversions x x x

Please see Template talk:Convert/x#Cubic conversions x x x. Peter Horn User talk 18:14, 4 November 2009 (UTC)

New Template:Convert/3 for cubic or 3 amounts

06-Nov-2009: Today, I have created a new subtemplate Template:Convert/3 for 3-amount conversions, allowing any mixture of "to" or "by" or "x" or "-" or "and" (etc.) as the range-words; plus the separator can also be semicolon, disp=semi:

• {{convert/3 |5|by|6|by|7|m|ft}}     gives: Template:Convert/3
• {{convert/3 |5|x|6|x|7|m|ft}}        gives: Template:Convert/3
• {{convert/3 |7|to|8|to|9|km|mi|abbr=on}}    gives: Template:Convert/3
• {{convert/3 |7|to|8|to|9|km|mi|adj=on}}      gives: Template:Convert/3
• {{convert/3 |5|to|6|by|7|m|ft}}     gives: Template:Convert/3
• {{convert/3 |5|by|6|x|7|m|ft}}      gives: Template:Convert/3
• {{convert/3 |11|-|22|-|33|°C|F|disp=semi|lk=on}}     gives: Template:Convert/3

Input units (like "m") cannot be expanded/linked. -Wikid77 16:14, 6 November 2009

Displaying unit name by disp=unit

08-Nov-2009: To finish Template:Convert/3 (for 3-amount conversions), I had to implement a new display type, as disp=unit, to display just the unit name (as singular, plural or hyphenated) for an input-unit symbol:

• {{convert|1 |ft|disp=unit}}           gives: foot
• {{convert|9 |ft|disp=unit}}           gives: feet
• {{convert|7 |m3|disp=unit|abbr=on}}       gives: m³
• {{convert|7 |m3|disp=unit|abbr=off}}       gives: cubic metres
• {{convert|1 |cuyd|disp=unit|lk=on}}       gives: cubic yard
• {{convert|1 |cuyd|disp=unit|adj=on}}      gives: cubic-yard

The option disp=unit can also be used, during article writing, as a means to display a unit name or symbol for a specific unit-code when writing an article. -Wikid77 10:31, 8 November 2009

Listed new options on docpage

08-Nov-2009: The docpage {{Convert/doc}} now lists new options abbr=in & abbr=out:

attach |abbr=on       to show unit symbols            (default: abbr=off)
attach |abbr=none   to show all units in full words
attach |abbr=in       to abbreviate input units
attach |abbr=out     to abbreviate output units.

For under-construction, option "abbr=comma" is explained:

abbr=comma - Abbreviates (removes) commas. This is a limited, temporary option, until comma=off can be implemented. For ranges, trying abbr=comma conflicts with internal options, so instead, append "nocomma" to a range-word: tonocomma, bynocomma, andnocomma, -nocomma & xnocomma.

For brevity, I reduced the repeated text about "This example is for illustration only, common units of measurement should not be linked." That does not apply to examples with rare units, so I used rare unit "cu yd" in an example. -Wikid77 10:31, 8 November 2009

New Convert/date gives ISO date or day for: date

08-Nov-2009: The unit name "date" triggers the new (huge) subtemplate {{Convert/date}} to convert a date into ISO format or the day-of-the-year:

• {{convert|8 November|date|day}}       gives:
• {{convert|Nov 19|date|ISO}}             gives:
• {{convert|April 31|date|ISO}}            gives:

That template was purposely designed (to be gigantic) to show that Wikipedia's MediaWiki preprocessor can handle at least 2,928 switch-branches in a single subtemplate, plus internal documentation and category-links. See page: Template:Convert/date. -Wikid77 10:31, 8 November 2009

New Convert/note gives pitch for piano key: note

08-Nov-2009: The unit name "note" triggers the new subtemplate {{Convert/note}} to convert a piano key note-name into the equivalent pitch (frequency) in hertz:

• {{convert|middle C|note}}       gives:
• {{convert|A-440|note}}           gives:
• {{convert|f#|note}}                 gives:

That template was developed to also demonstrate the use of non-numeric conversions, converting a name into a musical pitch (frequency). See page: Template:Convert/note. -Wikid77 10:31, 8 November 2009

Plan to reduce subtemplates

08-Nov-2009: It is becoming far more difficult to implement new options, as the number of Convert-subtemplates grows by hundreds each time. I have added over 650 new subtemplates, but we should prepare to reduce those in the next few months. See essay: "Wikipedia:A plan to reduce Convert subtemplates". It would be easier to control commas by: comma=off, comma=in, comma=out, comma=on. Plus, some people want to round the input amount, such as round=in, round=out (current default), or round=on. Unless the current design is condensed, those new options could require modifying hundreds of subtemplates. -Wikid77 (talk) 10:30, 8 November 2009 (UTC)

Dealing with articles that have both US customary and Metric units

When writing a single article, I often deal with references that express values in either U.S. customary units or metric/SI units. But, per MOS, each article should consistently use one unit system as the primary and the other as secondary. It would therefore be very nice if the convert template could store the actual value used in the cited reference but display another unit as the primary. Are there plans for this? In the meantime, I'll have to fudge the template by swapping values and leaving hidden notes in the wikitext to tell editors what the actual cited value was. Inelegant, but this helps avoid error creep due to converting back and forth. --mav (talk) 19:00, 8 November 2009 (UTC)

• Okay, we can add "disp=flip" for now, but that will prevent also using any other "disp=xxx" when the result is flipped and displayed first. Meanwhile, we can plan for the new Convertx subsystem to eventually allow a new option as "order=reverse" to handle that while also allowing any "disp=xxx" option, as well. -Wikid77 (talk) 04:24, 10 November 2009 (UTC)
  • Yes, disp=flip would work nicely until an order=reverse is added. --mav (talk) 19:31, 14 November 2009 (UTC)

Question about the output

Is it possible for the template to output the converted unit first, and the unit being converted second. For example:

• {{convert|36|ft|6|in|m|abbr=on}} giving an output of "11.13 m (36 ft 6 in)". - Trevor MacInnis ^contribs 03:17, 9 November 2009 (UTC)

I figured out that I could do it by using:

• {{convert|{{{length ft|}}}|ft|{{{length in|}}}|in|m|abbr=on||disp=output only}} ({{{length ft|}}} ft {{{length in|}}} in) but I'm hoping the template can do it easier. -Trevor MacInnis ^contribs 03:29, 9 November 2009 (UTC)

• Yes, I am adding a new option "disp=flip" to flip the result as first in order:
             {{convert|36|ft|6|in |m|abbr=on|disp=flip}}      gives: 11.13 m (36 ft 6 in)
             {{convert|12|lb|8|oz |kg|abbr=on|disp=flip}}   gives: 5.7 kg (12 lb 8 oz)
             {{convert|10|m|ft|abbr=on|disp=flip}}   gives: 33 ft (10 m)

So, new option "disp=flip" will flip the order of the output, putting the result as first in the text and the input unit as last. -Wikid77 (talk) 04:24, 10 November 2009 (UTC)

"disp=output only" error

The convert {{convert|1|m|ftin|abbr=on|disp=output only}} produces an error:

3 ft 3 in. Can it be fixed? - Trevor MacInnis ^contribs 02:50, 10 November 2009 (UTC)

I see that is now works. Thanks for that. - Trevor MacInnis ^contribs 03:26, 11 November 2009 (UTC)

Problem

1.8 m × 2.6 m (5 ft 11 in × 8 ft 6 in) Am I doing something wrong? bamse (talk) 17:17, 14 November 2009 (UTC)

• For now, an output unit (such as "ft") must be specified after the "m" (metres); otherwise, some dual conversions fail:

{{Convert|1.8|x|2.6|m|abbr=on}}      gives:1.8 m × 2.6 m (5 ft 11 in × 8 ft 6 in)

{{Convert|1.8|x|2.6|m|ft|abbr=on}}    gives: 1.8 m × 2.6 m (5.9 ft × 8.5 ft)

I haven't checked to see how to fix for omitted units. There have been just too many hundreds of problems: I think I've created over 680 Convert subtemplates recently, but thanks for reminding us that omitted units are a problem in dual-conversions. -Wikid77 (talk) 01:45, 15 November 2009 (UTC)

Thanks for the fix. I have no idea what dual conversions are. bamse (talk) 08:04, 15 November 2009 (UTC)

"Metric" tonne

The word metric is only used as a spoken prefix due to the identical pronunciation of the words tonne and ton, it is needlessly verbose to have it read "X metric tons (X short tons)" when it could just as well read 12 tonnes (X tons) and be linked by default. I just read a article where "X metric tons (X short tons)" appeared no less then three times under one heading, surrounded by other metric units which would have made which unit was being used obvious anyway. This seems like an extravagance targeted at American users, and a needless one at that. —what a crazy random happenstance 03:56, 15 November 2009 (UTC)

If it doesn't say "metric tons" or "tonnnneeeeess" or however you crazy Brits spell it, we'll think it's a normal short ton. Leave it alone. It's working fine as it is. - Denimadept (talk) 04:05, 15 November 2009 (UTC)

What about the vast number of users who don't suffer from this problem? I would suggest making "tonnes (tons)" default, which in itself should be a sufficient differentiation, with an option to use "metric tonnes (short tons)" in a topic where even the former may lead to confusion, like an article on trucks in South Carolina or something. And mate, a crazy British spelling over a lazy American spelling any day. :) —what a crazy random happenstance 04:39, 15 November 2009 (UTC)

We get rid of excess vowels at times, sure. It's well known that we're not as formal as you Stuffy Brits. I understand the stuffiness, though. Consider your climate. Everyone's blowing their nose at all times other than your 5 minute summer. :-> Anyway, generally speaking, we go with American spellings in American-related articles. Be grateful that the default "ton" is your weird metric tounne. :-p - Denimadept (talk) 18:15, 15 November 2009 (UTC)

• There could be is a new template using unit-name "tonne" to display the shorter wording:

{{Convert|2|tonne}} gives: 2 tonnes (2.2 tons), using Convert/tonne which invokes a Convert/shton by setting parameter "o=shton" for default output as a short ton, coded inside the Template:Convert/tonne.

Although, generally, having many templates is considered excessive, the Convert set of subtemplates already numbers over 3,050, and I have a plan to condense/remove thousands of minor subtemplates, in favor of having more unit-name subtemplates, even if some are redundant, such as Template:Convert/L and Template:Convert/litre. I'd rather have a Convert/yd & Convert/yard, with some variety of output, rather than have people being forced into one viewpoint about the wording. -Wikid77 (talk) 18:03, 15 November 2009 (UTC)

It seems like a good idea to provide options as to wording, I agree. I'll leave it to you to determine which name is more suitable to be the default, but I would suggest "tonne" (metric) and "ton" (Imperial short). The wording as-is kind of caught me by surprise because I'm used to seeing Imperial/metric tonnes differentiated through spelling - in fact that's what I was taught in school. Oh, and PS: Denimadept, I'm Australian and currently sitting through a balmy 39˚C day (102 in your crazy nonsense units) and still a month and a half away from the heart of summer. Check mate. :) —what a crazy random happenstance 06:06, 16 November 2009 (UTC)

The largest unit is called "ton" or "long ton" in the UK and "long ton" in the US; the middle unit is called "tonne" in the UK and "metric ton" in the US; the smallest unit is called "short ton" in the UK and "ton" or "short ton" in the US. So my proposal would be to refer to them as "(short) ton", "tonne" and "long ton" by default and "short ton", "metric ton", and "(long) ton" when |sp=us is used, where parentheses mean "I'm not sure about whether to include this". ___A. di M. 16:31, 16 November 2009 (UTC)

I'm assuming you mean "short ton, tonne, (long) ton" by default and "(short) ton, metric ton, long ton" in AmE? Or have I misunderstood? —what a crazy random happenstance 02:10, 17 November 2009 (UTC)

Er... Yeah. Swap "short" with "long" and vice versa everywhere in the last sentence of my post above. ___A. di M. 21:55, 17 November 2009 (UTC)

• I agree, all across the U.S., "ton" usually means a short ton and "tonne" is rare, so I set the sp=us to show "metric ton": {{Convert|2|tonne|sp=us}} gives: 2 metric tons (2.2 tons). Also, sp=us sets symbol to "MT" (otherwise "t" unless anyone objects). -Wikid77 21:15, 17 November 2009

The US standard spelling is "metric ton", and the Commonwealth standard spelling is "tonne". The phrase "metric tonne" is standard in neither. The word "ton" is somewhat ambiguous because in the US it usually means the short ton and in Britain the long ton, although in either country it could mean the reverse, depending on the industry involved. You would be better off to convert tonnes to pounds and tons to kilograms to keep it clear what units are being used.RockyMtnGuy (talk) 04:43, 19 November 2009 (UTC)

I add my support to persisting with the "short" and "long" labels when using ton, as ton on its own is ambiguous, even when we know what country it is being used in. One other point: I'm from Australia too and I thought there was a difference in pronunciation between tonne and ton - tonne rhymes with con and ton rhymes with sun. Wcp07 (talk) 05:04, 19 November 2009 (UTC)

Thank you for patience in making fixes

15-Nov-2009: Many people have helped to pinpoint all the problems needing to be fixed in the various Convert subtemplates. I didn't realize there were hundreds of issues, until I starting making changes in October (2009). I suppose if I had known how many problems existed, then I never would have started making any fixes: it seems like a bottomless pit of problems. I figure that if Convert were a professional product, then 4 full-time employees would have been needed to develop all the current subtemplates, because 3 full-time workers could not have finished Convert in only 2 years. Hence, as a volunteer project, there have been hundreds of unfinished problems. It will take a few more months, but I think most issues can be resolved by then. Thank you, to all who have patiently described the various issues needing to be fixed. -Wikid77 (talk) 17:28, 15 November 2009 (UTC)

Temperature in electron volts

Can we have conversion from kelvins to KeV and MeV as described in Electron volt#As a unit of temperature? --JWB (talk) 20:23, 15 November 2009 (UTC)

• I had to create a separate subtemplate {{Convert/keVT}} for code "keVT" as a temperature, because currently, code "keV" is based as a measurement with femtojoules, rather than being converted to megakelvins (MK):

{{Convert|15|keV}}                             gives: 15 kiloelectronvolts (2.4 fJ)

{{Convert|15|keVT}}                           gives: 15 kiloelectronvolts (170 MK)

{{Convert|15|keVT|MK|abbr=none}}     gives: 15 kiloelectronvolts (170 megakelvins)

{{Convert|174|MK|abbr=none}}            gives: 174 megakelvins (15.0 kiloelectronvolts)

This use of keV is a good example of the need to have multiple basis scales inside a Convert unit-subtemplate, rather than assume a unit is only used for one type of measurement, such as excluding usage as a temperature. Currently, most unit-subtemplates are based on a single scale-factor b=... without the ability to also shift (such as temperatures by "+32"). Hence, temperatures are handled by a massive collection of hundreds of special subtemplates (because there was no ability to have "9/5*C+32"). Similarly, the initial use of keV was with femtojoules, so use as a temperature was not possible because there was no factor "btemp=" as a 2nd conversion factor for converting temperatures. More about this later. -Wikid77 (talk) 01:50, 16 November 2009 (UTC)