Template talk:Convert/Archive November 2009

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)

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: {{convert|1426|C|F|abbr=comma}}
• {{convert|3500|F|C}}                       gives: 3,500 °F (1,930 °C)
• {{convert|3500|F|C|abbr=comma}}   gives: {{convert|3500|F|C|abbr=comma}}

The option "abbr=comma" can also be used when comma is the separator ("disp=comma") to simplify the results: {{convert|3500|F|C|abbr=comma|disp=comma}}. -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: {{convert/3|5|by|6|by|7|m|ft}}
• {{convert/3 |5|x|6|x|7|m|ft}}        gives: {{convert/3|5|x|6|x|7|m|ft}}
• {{convert/3 |7|to|8|to|9|km|mi|abbr=on}}    gives: {{convert/3|7|to|8|to|9|km|mi|abbr=on}}
• {{convert/3 |7|to|8|to|9|km|mi|adj=on}}      gives: {{convert/3|7|to|8|to|9|km|mi|adj=on}}
• {{convert/3 |5|to|6|by|7|m|ft}}     gives: {{convert/3|5|to|6|by|7|m|ft}}
• {{convert/3 |5|by|6|x|7|m|ft}}      gives: {{convert/3|5|by|6|x|7|m|ft}}
• {{convert/3 |11|-|22|-|33|°C|F|disp=semi|lk=on}}     gives: {{convert/3|11|-|22|-|33|°C|F|disp=semi|lk=on}}

Input units (like "m") cannot be expanded/linked. -Wikid77 16:14, 6 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)

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)

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)

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)

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)

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)

• 29-Nov-09: Along with fixes, new features will be added also. -Wikid77 13:45, 29 November 2009

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)

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

You're right, in Commonwealth English tonne and ton are usually pronounced differently. In British English, the difference can be very apparent, depending on the dialect used. The point is generally missed by most Americans, who don't use tonne at all and thus don't know how it is pronounced.RockyMtnGuy (talk) 17:39, 19 November 2009 (UTC)

I have never heard "tonne" pronounced with a long O. Or indeed ever heard it pronounced differently from "ton". Commonwealth English is usually considered to be a spelling term rather than a pronunciation term too IMO. Chris Cunningham (not at work) - talk 18:41, 19 November 2009 (UTC)

I'm not aware of a pronunciation difference between tonne and ton either, which part of the country are you originally from Wcp07? It seems very British to say "tonne" to rhyme with "con" (though the only Brit here disagrees), but I suppose it could be regional (SA?), or maybe Cultivated AuE. I would personally support keeping the "short" and "long" in at all times, as RockyMtnGuy pointed out it's an industry-specific thing, which means there's a whole subset of articles where our determination of the more common ton would be incorrect. —what a crazy random happenstance 05:02, 20 November 2009 (UTC)

I've just checked my copy of the Macquarie Dictionary and it does indeed list tonne with a pronunciation rhyming with "con". But perhaps the phonetic spelling in a dictionary follows a cultivated Australian accent and broader varieties veer towards a "ton" pronunciation? Still, coming from Sydney, I've never considered my accent to be cultivated :) Wcp07 (talk) 06:17, 21 November 2009 (UTC)

I did a quick Google search on the subject and discovered that when Australia originally converted to metric, the authorities recommended a pronunciation of "tonne" rhyming with "con", but due to linguistic drift the pronunciation "tun" has become more common. This may be because the imperial ton is no longer commonly used in Australia, so it doesn't matter how it is pronounced. Other countries may vary.RockyMtnGuy (talk) 07:22, 21 November 2009 (UTC)

I'm from Sydney too, and my accent does skim the border between general and cultivated but this distinction is new to me. Wiktionary:tonne#Pronunciation lists is as a specifically Australian pronunciation, and one typically usually used when emphasising tonnes over tons. It could be archaic, I don't think I've ever heard an Australian discuss things in terms of Imperial tons, so maybe there's no longer a need to differentiate between the two? PS: RockyMtnGuy beat me to it, but his research would seem to support what I have suggested. —what a crazy random happenstance 07:27, 21 November 2009 (UTC)

Ranges in numbers problems

According to Wikipedia:MOSNUM#Conventions, "[w]hen dimensions are given, each number should be followed by a unit name or symbol (e.g., write 1 m × 3 m × 6 m, not 1 × 3 × 6 m or 1 × 3 × 6 m³)." However, the convert template violates this rule. For example, {{convert|1|x|3|m}} gives 1 by 3 metres (3 ft 3 in × 9 ft 10 in) instead of the stylistically correct "1 metre by 3 metre (3 ft 3 in × 9 ft 10 in)". Can anyone fix this? Dabomb87 (talk) 16:49, 22 November 2009 (UTC)

• That would require a change to many subtemplates; however, for now, use "abbr=on" or "abbr=mos" to display the units in WP:MOS style:

{{convert|1|x|3|m}}                  gives: 1 by 3 metres (3 ft 3 in × 9 ft 10 in)

{{convert|1|x|3|m|abbr=on}}      gives: 1 m × 3 m (3 ft 3 in × 9 ft 10 in)

{{convert|1|x|3|m|abbr=mos}}   gives: 1 by 3 metres (3 ft 3 in × 9 ft 10 in)

By adding parameter "abbr=mos" then the repetition of full unit-names can be designated wherever needed. -Wikid77 13:45, 29 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 09:31, 8 November 2009 (UTC)

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 09:31, 8 November 2009 (UTC)