Template talk:Convert/Archive May 2011

An unexpected problem

In the infobox in Flexity Swift 35 and 40 tonnes (34 and 39 long tons; 39 and 44 short tons) something is not going right, but it is doing OK here!? Peter Horn User talk 22:39, 29 April 2011 (UTC)

Short answer, just specify either (a) the precision or (b) the sigfig= and the problem goes away. The long answer is that there is a problem with the maximum depth allowed by nested parserfunctions/templates, and the automatic rounding branch has more complexity than the specified rounding branch. So, by specifying the rounding, you reduce the complexity, and solve the problem. A more robust solution would be to either (a) get the mediawiki devs to increase the maximum depth, (b) get the mediawiki devs to provide a parserfunction which automatically computes the precision of the converted number, or (c) do something very clever to reduce the complexity of the current code. Until that happens, the solution is to do what I just did (or use sigfig=xx). Frietjes (talk) 22:55, 29 April 2011 (UTC)

• I am planning to update Convert to use quicker rounding, with 5 fewer levels of expansion depth for most numbers, by invoking Template:Getprecision and Template:Rndpad. -Wikid77 13:49, 2 May 2011 (UTC)

Adding/editing units

I've been adding/editing units of measure for many years now. I've recently been running a bot (approved as Lightbot5) to add conversions to feet and miles, plus their squares or cubes. The current scope was deliberately limited but it is now time to address the limitations. In the following examples:

• It is 20 feet tall and 15 feet 6 inches wide
• he is taller than his opponent at 6 feet tall compared with 5 feet 10 inches
• she drove 10 miles at 120 mph
• she is only 5 ft tall and weighs 85 pounds

it will convert the former but not the latter in each case.

Back in October, I started the process to extend the scope to cover situations such as the above. The bot approval group has a high workload and is looking at a lot of other requests. Given the length of time that's passed and the domain knowledge that exists here, I'm asking for more editor eyes on the requests starting at Wikipedia:Bots/Requests for approval/Lightbot 6 upwards. The most help can be provided by commenting at:

• Wikipedia:Bots/Requests for approval/Lightbot 12 'units of temperature'
• Wikipedia:Bots/Requests for approval/Lightbot 13 'units of length, area, or volume'
• Wikipedia:Bots/Requests for approval/Lightbot 14 'units of mass'

In all cases, the functionality was approved as Lightbots3 but approval expired. Rather than spending more time debating theory, I think it's time for actual edits, even if only as a trial (in either the Lightmouse or the Lightbot account) with the 'save' button pressed for each one. Regards Lightmouse (talk) 17:57, 30 April 2011 (UTC)

• Partial conversions are often good enough: When readers see some of the numbers converted, then often, the readers can estimate the results for unconverted amounts. For example, with "11 m" converted: 11 metres (36 ft), then if "12.5 m" is not converted, the equivalent for "11 m" is often enough for the readers to estimate the value for 12.5 m. Also, once a conversion is coded inside the markup of an article, then other users could edit the article and add "copy-cat" conversions, by hand, to add the other conversions which a bot-edit overlooked. For those 2 reasons, having only partial conversions in an article is often good enough. -Wikid77 13:49, 2 May 2011 (UTC)

A fair point but possibly a separate issue. Automation is running efficiently with human oversight for the tedious work of adding conversions to just two units: 'feet' and 'miles'. It was scoped for any units but the permission expired. The requests are to re-add more units to the scope. Lightmouse (talk) 15:05, 2 May 2011 (UTC)

Reducing instances of 'abbr=off', 'lk=off'

I've come across quite a few instances where template switches are set at the default value e.g. 'abbr=off', 'lk=off'. I've never tracked back through the history of the article to see how it got there. I can think of a variety of ways. They add clutter so I delete them.

I plan to ask for this declutter task to be put in AWB general fixes and/or in unit gnoming codes used by myself and other editors. Has anybody else tackled these? Lightmouse (talk) 09:23, 6 May 2011 (UTC)

PS

In automotive articles, we often use sources that show power in PS (Pferdestärke), especially for Germany and Japan right up to the 1990s. We would like to use PS input for convert but to output only kW and hp as. I can do this by using convert twice:

• {{convert|100|PS|kW hp|1|disp=output only}} gives 73.5 kW; 98.6 hp (no brackets)
• {{convert|100|PS|1|disp=output number only}} gives 73.5
• {{convert|{{convert|100|PS|1|disp=output number only}}|kW|abbr=on|0}} gives 73.5 kW (99 hp)
• {{convert|{{convert|100|PS|1|disp=output number only}}|kW|abbr=on|0|disp=flip}} gives 99 hp (73.5 kW)

Is there a more elegant way to do this? Perhaps something like one of these ...

• {{convert|100|PS|kW hp only|1|abbr=on}} to give '73.5 kW (99 hp)'
• {{convert|100|PS|hp kW only|1|abbr=on}} to give '99 hp (73.5 kW)'
• {{convert|100|PS|kW hp|1|abbr=on|disp=hide input}} to give '73.5 kW (99 hp)'
• {{convert|100|PS|hp kW|1|abbr=on|disp=hide input}} to give '99 hp (73.5 kW)'

I'm also worried about excessive rounding.  Stepho  (talk) 07:41, 9 May 2011 (UTC)

There is a shorter option "disp=number" (same as "disp=output number only"):

• {{convert|{{convert|100|PS|1|disp=number}}|kW|abbr=on|0}} → 73.5 kW (99 hp)
• {{convert|{{convert|100|PS|1|disp=number}}|kW|abbr=on|0|disp=flip}} → 99 hp (73.5 kW)

If we added a new option as "disp=hide input" then I think everything would just get more complicated. An output-unit code such as "kW hp only" would still show "100 PS" because only options such as "abbr=none" or "disp=number" can alter the display of "100 PS"; an output unit cannot alter the input amount. As for rounding, any number with trailing zeroes (100, 200, 500, etc.) is most often a rough estimate in many articles, so that's why "100" triggers a rounded result: an exact number as "100" is a rare case needing rounding with "|0". Hence, the above formats seem to be the best choices. Not every case can have the shortest, most elegant format, and this is one of those cases. -Wikid77 01:11, 10 May 2011 (UTC)

I guess I can't expect a miracle every time but thanks for the reply anyway. The rounding issue was not the auto rounding (see the |1 and |0 in each double conversion). The first call to |PS converts PS to kW with rounding to 1 digit. This gets displayed as-is. The second call converts the newly calculated kW value (with its single digit after the decimal) into hp. But if I want to display whole units for kW then I am using a less precise value of kW to calculate hp. Its bearable as long as the precision is kept the same in both calls to convert but I was hoping to keep full precision in the calculations and then only round the final display. In rare cases, the imprecision of the calculated kW value may cause the hp value to round one up and one down but I guess I can live with that. For the rare cases that I need the full precision I will just have to use a triple call :(

• {{convert|{{convert|99|PS|5|disp=number}}|kW|abbr=on|2}} gives 72.81438 kW (97.65 hp)
• {{convert|{{convert|99|PS|2|disp=number}}|kW|abbr=on|2}} gives 72.81 kW (97.64 hp)
• {{convert|99|PS|2|disp=output only}} ({{convert|{{convert|99|PS|5|disp=number}}|kW|abbr=on|2|disp=output only}}) gives 72.81 kW (97.65 hp)

Thanks.  Stepho  (talk) 04:01, 10 May 2011 (UTC)

Using Template:Rndpad will affect x10-notation

To shorten the nesting depth 3-5 levels (for "expansion depth limit"), I am planning to use Template:Rndpad in Template:Convert/round, but more trailing zeroes will appear:

• {{convert|20,000,000,000|m|ft}} → 20,000,000,000 metres (6.6×10¹⁰ ft)
• {{rndpad|66000000100|-3}} → {{rndpad|66000000100|-3}}
• {{rnd|66000000100|-3}} → 6.6000000×10¹⁰
• {{rndpad|6.605E+10|0}} → {{rndpad|6.605E+10|0}}
• {{rnd|6.605E+10|0}} → 6.6050000000×10¹⁰

Commas will be added after rounding. Numbers > 85 billion will still display in the "x10" notation:

• {{rndpad|8.605E+10|0}} → {{rndpad|8.605E+10|0}}
• {{rnd|8.605E+10|0}} → 8.6050000000×10¹⁰
• {{formatnum: {{rndpad|4.975E+10|0}} }} → {{formatnum: {{rndpad|4.975E+10|0}} }}

The reason to delay commas (the commas will be added after the rounding) is to allow checking the size of the rounded result for wrapping the unit (after large numbers). -Wikid77 21:05, 4 May 2011 (UTC)

I can't say I'm looking forward to seeing more zeros. 85 thousand million seems a percular number ... what's the signficance of 85? JIMp _talk·cont 00:04, 11 May 2011 (UTC)

disp=5

For Hurricane Rick (2009) 180 mph (290 km/h; 155 kn). Peter Horn User talk 17:36, 12 May 2011 (UTC)

I can't quite fathom what happens here. Peter Horn User talk 23:38, 12 May 2011 (UTC)

Looks like something's missing. JIMp _talk·cont 00:37, 13 May 2011 (UTC)

I think the problem is that {{convert|180|mph|km/h kn|disp=number}} produces 290; 160, and the rounding to "5" is done after this first conversion. Does "disp=5" work for any dual conversions? Plastikspork _―Œ^(talk) 01:00, 13 May 2011 (UTC)

I'd guess it doesn't. I've tried it without the linking & without the abbrivation & that doesn't work.

• 18 US gallons (68 L; 15 imp gal)
• 480 K (207 °C; 404 °F)
• 23 stone (320 lb; 145 kg)
• 223 torrs (30 kPa; 10 inHg)

It looks like it's working for capacity & temperature but actually in these cases the disp=5 is just being ignored. Otherwise, no, it seems not to be working at all for any dual conversions. JIMp _talk·cont 01:14, 13 May 2011 (UTC)

• Avoid using Convert for hurricane wind speeds: In this case, I am glad the dual conversion failed: we really want to discourage using Convert for hurricane data, such as in "Hurricane Rick (2009)". As you might recall, the reported hurricane wind speeds do not always match with text-book conversions between mph & km/h, because they originate from wind speed in knots, as rounded to nearest 5's in mph and km/h, separately. In those cases, the actual data is not correct if re-converted from a rounded amount: when a hurricane wind speed is noted as "120 mph" that result has already been rounded to the nearest 5 mph, so the speed in km/h should be based on converting from the original measurements in knots, rather than trying to convert an amount rounded to 5's of mph to be rounded to 5's of km/h. When I added disp=5, I was afraid it might be misused to try to retro-convert mph in 5's back to knots. It is analogous to creating a circular saw without a blade guard, and having people complain of the saw cutting other stuff, or spinning along the ground, after a board is cut through and the saw drops down. The option "disp=5" should be used with caution, and beware that hurricane wind speed in km/h, when mph=120, must be converted from original speed in knots, rather than converting mph in 5's to km/h in 5's. Hurricane-article editors will go ballistic if they find people using convert to "correct" the wind speeds being quoted from official hurricane reports. More later. -Wikid77 03:50, 13 May 2011 (UTC)

Nevertheless disp=5 is broken. It is analogous to creating a rifle that doesn't actually work and telling the customer who complains that functional rifles are dangerous so he's better off with the malfunctioning one. What if our source isn't already rounded? Nor is the problem limited to wind speeds. disp=5 doesn't work for any multiple conversions. JIMp _talk·cont 05:06, 13 May 2011 (UTC)

Abbr=off only affects input units

Hi, I'm trying to get the input and output units to display in full, but abbr=off only does it for the input units. Output units remain abbreviated no matter what I try. Examples:
6 long tons (6.1 tonnes)
2,600 imperial gallons (12,000 litres)
57 inches (1,450 millimetres)
200 pounds per square inch (1,380 kilopascals)
22,170 pounds-force (98.617 kilonewtons)
Please help! André Kritzinger (talk) 15:18, 6 May 2011 (UTC)

Use option "abbr=none" to show full unit names for input/output:

• {{convert|6|LT|t|abbr=none}} → 6 long tons (6.1 tonnes)
• {{convert|2600|impgal|l|abbr=none}} → 2,600 imperial gallons (12,000 litres)

The option "abbr=none" has been available since 2009, so it works with most other options. -Wikid77 01:11, 10 May 2011 (UTC)

Thanks! (Don't know how I missed that....) André Kritzinger (talk) 11:12, 10 May 2011 (UTC)

Me again. Came across one that does not work so good.
{{convert|250|impgal|l|abbr=on|lk=on}} gives 250 imp gal (1,100 L), works fine.
{{convert|250|impgal|l|abbr=none|lk=on}} gives 250 imperial gallons (1,100 litres)
André Kritzinger (talk) 11:26, 13 May 2011 (UTC)

I added the missing template. Frietjes (talk) 16:00, 13 May 2011 (UTC)

Thanks, works fine now! André Kritzinger (talk) 16:13, 13 May 2011 (UTC)

km3 to cubic miles

I'm working on a few geology articles, where a lot of the reliable sources describe km3 of ash or lava. I was wondering if someone could create a quick and dirty template so I can easily place a km3 to cubic mile (not sure what the abbreviation should be, but cu mi seems appropriate, since it follows cu ft). Any help would be greatly appreciated. OrangeMarlin ^{Talk• Contributions} 20:19, 15 May 2011 (UTC)

It already exists.

{{convert|123|km3}} → 123 cubic kilometres (30 cu mi)

{{convert|123|cumi}} → 123 cubic miles (510 km³)

JIMp _talk·cont 23:50, 15 May 2011 (UTC)

Sorry, I didn't see it listed. Thanks so much! OrangeMarlin ^{Talk• Contributions} 06:50, 16 May 2011 (UTC)

Grains, troy ounces and grams or milligrams, two way & three way converts

451 Troy grains 451 tgr for Spanish dollar#Etymology of dollar Peter Horn User talk 21:12, 4 May 2011 (UTC)

Is there a difference between a grain and a troy grain? {{convert|451|gr|g}} works. Frietjes (talk) 23:38, 4 May 2011 (UTC)

The avoirdupois and Troy systems use the same grain. JIMp _talk·cont 00:07, 11 May 2011 (UTC)

So 451 grains (29.2 g)? Peter Horn User talk 01:52, 12 May 2011 (UTC)

Or 451 grains (0.94 ozt), 451 grains (1.03 oz) and 451 grains (0.94 ozt; 29.2 g), 451 grains ()(?), 451 grains (1.03 oz; 29.2 g). But also 451 gross register tons () So that the unabbreviated input will either read troy ounces or ounces according to the original wording in the pre convert context. Peter Horn User talk 18:11, 12 May 2011 (UTC)

I'm still waiting for 451 grains (0.94 ozt; 29.2 g) Peter Horn User talk 23:33, 12 May 2011 (UTC)

ozt g is done but I'm not quite sure what you mean by "So that the unabbreviated input will either read troy ounces or ounces according to the original wording in the pre convert context." JIMp _talk·cont 05:14, 13 May 2011 (UTC)

Spanish dollar#Etymology of dollar now reads "The Joachimsthalers weighed 451 Troy grains of silver". After conversion it would now read "The Joachimsthalers weighed 451 grains (0.94 ozt; 29.2 g)". The word "troy" gets lost and only "grains" remains. Hence 451 gross register tons () so as to keep the input troy grains. Peter Horn User talk 02:24, 15 May 2011 (UTC) Peter Horn User talk 22:37, 15 May 2011 (UTC)

One "minor" detail. Methinks the "ozt" in the templates should really be linked to "troy ounce" rather than to "troy weight" as is now the case. Peter Horn User talk 22:51, 15 May 2011 (UTC)

Troy grains done. Regarding the link I agree.

As noted above Troy ounce would be a better link than Troy weight. The following line of code on {{convert/ozt}} is redirecting the link.

|t=troy weight

Please remove it. JIMp _talk·cont 00:07, 16 May 2011 (UTC)

 Done — Martin (MSGJ · talk) 13:43, 16 May 2011 (UTC)

Now you have me confused, "ozt" still redirects to "troy weight" rather than to "troy ounce". I'm skratching my head. What is the reaon for this? Peter Horn User talk 00:09, 18 May 2011 (UTC)

Are you sure? Try this. 12 troy ounces (13 oz; 370 g) JIMp _talk·cont 00:30, 18 May 2011 (UTC)

Well, it appears that someone made the adjustment after my last post. Peter Horn User talk 01:29, 19 May 2011 (UTC)

Big numbers again

I just used the following template: 4×10¹⁴ gigajoules (9.6×10⁴ gigatons of TNT). Is there anyway to have the output for GJ be automatically converted from 4e14 to 4X10¹⁴? I'm not sure if 4e14 is very user friendly. OrangeMarlin ^{Talk• Contributions} 05:30, 17 May 2011 (UTC)

I'm sure it's not user friendly at all. There's something for us to work on. It should be automatically converted. But, in the mean time, how about this instead?

4×10¹⁴ GJ = 4×10²³ J = 400 ZJ

so 400 zettajoules (96 teratons of TNT)

JIMp _talk·cont 05:47, 17 May 2011 (UTC)

• I fear the extra logic to display "4e14" in x10 notation will again hit the expansion-depth limit, just as showing the Unicode &minus ("−") was a nightmare of added complexity to preserve any trailing zeroes:

• {{convert/numdisp|-5.000}} → −5.000
• {{convert/numdisp|-5340.0700}} → −5,340.0700
• {{convert/numdisp|-4e6}} → −4,000,000
• {{convert/numdisp|-4e14}} → −400,000,000,000,000

The solution might be to create a wrapper {{convert/E}}, similar to {{convert/spell}} or {{convert/gaps}} which separately displays parameter {{{1}}} for huge numbers, then uses "disp=out" to handle the remainder of the conversion. Otherwise, if all conversions are changed to handle "4e14" as x10 notation, then I am fairly certain "everyone" will say they cannot use Convert any longer, due to "Expansion depth limit exceeded" in many infobox templates. Computer scientists had developed the E-notation ("6.5E24"), many decades ago, as a dual interface, where E-notation can be read by either humans or computers, but "6.5x10²⁴" cannot be read easily by computers. Computers like "6.5E24" when they are "texting" with humans. Graphical typesetting and numerous special icons have really hindered the computer's ability to talk with humans. Computers can translate most Greek to Chinese, but they cannot easily "read" a smiley-face or "®" icon. Perhaps there might be a way to reduce template nesting, as discussed under Template_talk:Convert/nesting. -Wikid77 16:01, 18 May 2011 (UTC)

New Template:Convert/E for x10 notation

As discussed earlier, I have created a wrapper {{convert/E}} to handle formatting scientific notation E-format (4E14) as superscript x10 notation (4×10¹⁴), without affecting other conversions:

• {{convert/E |4E14|m|ft}}     → 4×10¹⁴ metres (1.3×10¹⁵ feet)
• {{convert/E |4.22E14|m|ft}} → 4.22×10¹⁴ metres (1.385×10¹⁵ feet)
• {{convert/E |1.23550E33|mi|km}} → 1.2550×10³³ miles (2.0197×10³³ kilometres)

This {Convert/E} template is similar to {{convert/spell}} or {{convert/gaps}} which separately displays parameter {{{1}}} for huge numbers, then uses "disp=out" to handle the remainder of the conversion. Otherwise, if all conversions are changed to handle "4e14" as x10 notation, then I am fairly certain "everyone" would say they cannot use Convert any longer, due to "Expansion depth limit exceeded" in many infobox templates. Another complex problem, handled inside {Convert/E} is to determine the precision of the scientific-notation amounts, which is not done in the original Convert; precision is based on the truncated logarithm of the input amount:

• floor (log 4E14) = 14
• floor (log 1.88E17) = 17

So far, some numbers appear to format correctly, but the handling of E-notation numbers has been very complicated, so there are likely to be more problems to fix in new Template:Convert/E. Due to slow response-time on English WP, today, with numerous time-outs showing "WP:Wikimedia Foundation errors" all day, then the Simple English Wikipedia was used, instead, to develop this new template. Feel free to improve the template for better precision (it is used in few or no articles), and we can discuss if the original Convert could be changed to display these huge numbers in x10 notation. -Wikid77 00:11, 19 May 2011 (UTC)

New Convert/spell shows amount in words

14-Apr-2011: As promised, there is finally a Template:Convert/spell to show the amount(s) in words ("twenty-five feet" rather than "25 feet"). It can handle up to 19 million, but try to just use it for smaller amounts. Examples:

• {{convert/spell |25|ft|m}}            → twenty-five feet (7.6 m)
• {{convert/spell |25|ft|m|case=u}} → Twenty-five feet (7.6 m)
• {{convert/spell |62|ft|m|words=out|abbr=none}} → sixty-two feet (nineteen metres)

The default is upper-case first word (else use "case=L"). Also, for adj=on, it doesn't yet put hyphens in large numbers, but I expect that would be rare. Anyway, this is a start, and it provides the ability to have quotations of stated numbers:

• {{convert/spell |245|km|mi|case=l|disp=br}} → two hundred and forty-five kilometres
  152 miles

Sorry for the delay; it was very complicated (although not as impossibly difficult as it might seem). I think the British spelling "sp=en" should show "and" as in "two hundred and twenty". Does that seem logical? -Wikid77 12:03, 14 April 2011 (UTC)

Just passing through, but I hope the "and" can be included. On the other hand, I think it is probably pretty rare the times people would want to write "two hundred (and) twenty", instead of 220 [not so for cases < 100 and especially < 20; I've often missed this ability but been pleased for the rest of the functionality of convert. —Felix the Cassowary 17:25, 30 April 2011 (UTC)

DONE. Already, the option "sp=en" to show "and" is working for hundreds, up to 99 thousand, but not all larger numbers:

• {{convert/spell |220|m|ft|sp=en}} → two hundred and twenty metres (720 ft)
• {{convert/spell |931|m|ft|sp=en}} → nine hundred and thirty-one metres (3,054 ft)
• {{convert/spell |2003|ft|m|sp=en}} → two thousand and three feet (611 m)
• {{convert/spell |13000088|ft|m|sp=en}} → thirteen million and eighty-eight feet (3,962,427 m)

I will try to expand inserting "and" for multiple 100s of thousands. -Wikid77 13:49, 2 May 2011 (UTC)

For Tilden Regional Park#Attractions please provide {{convert/spell|4|mi|km|adj=on}}, which does not yet work, so as to replace four miles (6.4 km) in that section. Peter Horn User talk 19:26, 14 May 2011 (UTC)

 Done. Currently gives {{convert/spell|4|mi|km|adj=on}} → four-mile (6.4 km). -Wikid77 20:07, 14 May 2011 (UTC)

Thanks. Peter Horn User talk 22:48, 14 May 2011 (UTC)

Strange, Chain (unit)#North American agriculture (one-half mile (0.80 km)) (one-quarter mile (0.40 km)) Peter Horn User talk 02:47, 20 May 2011 (UTC)

• DONE: will handle 23 simple fractions: 1/2, 1/3, 2/3, 1/4, 3/4, 1/5, 2/5, 3/5, 4/5, 1/6, 5/6, 1/8, 3/8, 5/8, 7/8, 1/16, ... However, mixed numbers+fractions will be spelled as decimal amounts, not fractions. -Wikid77 06:13, 20 May 2011 (UTC)

Yet another three way conversion

For Hurricane Rick (2009), 906 mbar (hPa; 26.75 inHg) vs 906 mbar (906 hPa; 26.8 inHg) and/or 906 mbar (90.6 kPa; 26.8 inHg) Peter Horn User talk 02:00, 12 May 2011 (UTC)

Thanks to the one who solved this anonymously. Peter Horn User talk 23:39, 12 May 2011 (UTC)

You're welcome. JIMp _talk·cont 00:35, 13 May 2011 (UTC)

And yet another

For Perch (unit)#Volume 24.75 cubic feet (0.916667 cubic yards; 0.700842 cubic metres)

27 cubic feet (1.000000 cubic yard; 0.764555 cubic metres) Howzat? JIMp _talk·cont 06:19, 19 May 2011 (UTC)

Splendid. Peter Horn User talk 02:08, 20 May 2011 (UTC)

Oddity

Norwegian units of measurement, 60-foot-long (18 m) Kvalsund boat or 60-foot-long Kvalsund boat (18 m) work, 60-foot-long (18.29 m) Kvalsund boat or 60-foot-long Kvalsund boat (18.29 m) do not work. Peter Horn User talk 17:46, 20 May 2011 (UTC)

Eureka! 60-foot-long (18.29 m) Kvalsund boat or 60-foot-long Kvalsund boat (18.29 m) do work. Peter Horn User talk 01:03, 21 May 2011 (UTC)

Another template needed

I need a km/sec → miles/sec conversion. A lot of astronomical measurements are in the km/sec. Thanks for the help! OrangeMarlin ^{Talk• Contributions} 03:11, 21 May 2011 (UTC)

That one already exists as well:

100 kilometres per second (62 mi/s)

100 miles per second (160 km/s)

Cheers, LittleMountain5 04:57, 21 May 2011 (UTC)

unsuported fraction and not abbreviating input

At London Underground F Stock I've got two problems with convert in the infobox:

1. {{convert|24.50|LT|abbr=on}} is not abbreviating the input units: 24.50 long tons (24.89 t)
2. {{convert|9|ft|6+15/16|in|mm}} is giving an error for the fraction: 9 feet 6+15⁄16 inches (2,919 mm). Fair enough there isn't a glyph for 15/16, but it should fall back to how I've written it here. Thryduulf (talk) 19:18, 20 May 2011 (UTC)

Make that 24.50 long tons (24.89 t; 27.44 short tons). Peter Horn User talk 20:57, 20 May 2011 (UTC)

That still isn't abbreviating "long tons" though. Thryduulf (talk) 02:25, 21 May 2011 (UTC)

Well, someone fixed that. But when everything is abbreviated, I would prefer to see 24.50 long tons (24.89 t; 27.44 short tons). Peter Horn User talk 01:37, 22 May 2011 (UTC)

• IN REWORK. Subtemplates are being changed to show abbreviation symbol "LT" when abbr=on (or abbr=in, abbr=out):

{{convert|24.50|LT|abbr=on}} → 24.50 long tons (24.89 t)

However, the "15/16" will require more study to fix:

{{convert|9|ft|6+15/16|in|mm}} → 9 feet 6+15⁄16 inches (2,919 mm)

{{convert|9|ft|6+5/8|in|mm}} → 9 feet 6+5⁄8 inches (2,911 mm)

{{convert|4|ft|3+69/100|in|mm}} → 4 feet 3+69⁄100 inches (1,312.9 mm)

These changes take time. -Wikid77 18:48, revised 01:07, 22 May 2011 (UTC)

The abbreviation part is now fixed per Wikid77's editrequest. Thanks! Plastikspork _―Œ^(talk) 18:58, 21 May 2011 (UTC)

Thank you. Thryduulf (talk) 19:24, 21 May 2011 (UTC)

I added some code for 1/16, ..., 15/16. I don't know if this is the best solution, so let me know if I should change it to something else (or revert the changes). For example, I could stick an "and" between the whole part and fractional part. Thanks! Plastikspork _―Œ^(talk) 20:06, 21 May 2011 (UTC)

Regardless of anything else, that's much better than was there before, thank you. I personally think the ¹⁵/₁₆ is better than 15/16, so I'd stick with that. Certainly in a fully abbreviated environment "and" would be wrong, and I think it would look odd in most other cases. If the coding is relatively straightforward then you could add it as an option if you desired, called by something like {{convert|9|ft|6&15/16|in|mm}} or {{convert|9|ft|6and15/16|in|mm}}. Thryduulf (talk) 22:48, 21 May 2011 (UTC)

The current output is almost identical to {{frac}}, which is recommended by WP:MOSNUM, so we are probably doing okay here. The only minor difference is that {{frac}} wraps the entire number inside of a <span class="frac"></span>, which might be good idea to do here as well. In any event, as you said, this is probably a step in the right direction. Thanks! Plastikspork _―Œ^(talk) 23:05, 21 May 2011 (UTC)

Inconsistency between range of 2 & range of 3

Using the following code:

...taking up to twenty-three {{convert|220|x|320|cm|in|abbr=on}} side-by-side pallets, or an optional single-row (SR) loading of sixteen {{convert/3 |240|x|240|x|320|cm|in|abbr=on}} SR pallets

produces:

...taking up to twenty-three 220 × 320 cm (87 × 130 in) side-by-side pallets, or an optional single-row (SR) loading of sixteen 240×240×320 cm (94×94×130 in) SR pallets

Which looks daft because one has spaces between the numbers and multiplication signs, and the other doesn't.

Can this be made consistent? On a personal note, I tend to prefer it with the spaces. --jjron (talk) 08:16, 21 May 2011 (UTC)

• ALREADY ALLOWED. Just code the Convert/3 with the spaced-x symbols, as:

{{convert/3 |240| × |240| × |320|cm|in|abbr=on}} → {{convert/3|240| × |240| × |320|cm|in|abbr=on}}.

The {Convert/3} form has no restrictions to the range-word text between the numbers, so anything can be used as the separator text. -Wikid77 16:05, 21 May 2011 (UTC)

Hmmm, tried that before posting and it didn't work; just left it with no spaces. I'll give it another shot. --jjron (talk) 17:06, 21 May 2011 (UTC)

Ahh, thanks. Found the problem. I had tried {{convert/3 |240| x |240| x |320|cm|in|abbr=on}} which gives the result with no spaces: {{convert/3|240| x |240| x |320|cm|in|abbr=on}}. To get the spacing to work you need to use the × symbol rather than an x in the source code. A little fussy perhaps. Cheers, --jjron (talk) 17:14, 21 May 2011 (UTC)

Request from Nnemo: non-breaking space for typography

Hello,

I encountered several ugly occurrences this template producing soft line breaks between the digital number and its unit, whether abbreviated or not.

Please correct that typography: it will be nicer. :-)

To do so, please replace the space between the digital number and its unit with a non-breaking space :  .

Thanks,

--Nnemo (talk) 11:32, 24 April 2011 (UTC)

The template should already be doing that; could you give specific examples of uses of {{convert}} that do not produce non-breaking spaces when they should? Ucucha 11:40, 24 April 2011 (UTC)

 Not done for now; specific examples are needed, as admins aren't going to pore through several dozen sub-templates looking for the bug here without at least a pointer to the problem. Chris Cunningham (user:thumperward: not at work) - talk 12:24, 24 April 2011 (UTC)

Of course. Here are the problem cases I noticed:

1. In this Climate section:
   1. The °C when in a range; like {{convert|-3|to|4|C|F}} → -3 to 4 °C (27 to 39 °F). When not in a range, it is OK; like {{convert|-10|°C|°F|abbr=on}} → −10 °C (14.0 °F).
2. In Template:Convert/check area:
   1. Sample row 4, all columns: I see sq ft beginning a line.
   2. Sample row 7, all columns: I see m² beginning a line.
   3. Sample row 8, non-linked singular and US non-linked plural: I see acres beginning a line.
   4. Sample row 10, all columns: I see sq ft beginning a line.
   5. Sample row 31, all columns: I see m² beginning a line.
   6. Sample row 35, all columns: I see sq ft beginning a line.
   7. Sample row 37, last column: I see m² beginning a line.
   8. Sample row 39, non-linked singular and US non-linked plural: I see acres beginning a line.

--Nnemo (talk) 01:50, 26 April 2011 (UTC)

A non-breaking space :  .

--Nnemo (talk) 01:50, 26 April 2011 (UTC)

Hi, if you can find the specific subtemplate which is causing the problem, it would make this more likely to get fixed. — Martin (MSGJ · talk) 08:43, 26 April 2011 (UTC)

You probably want to change the first {{{1}}} to {{convert/numdisp|{{{1}}}}} inside Template:Convert/to/AonSoff (and others). My guess is based on the fact that the non-range version uses this template, and that if I do a {{convert|-3+-1/2|to|4+1/2|C|F}}, then this flips the first conditional to fractions, which use this numdisp template, which results in . I don't know about the other typography requests. — Preceding unsigned comment added by Frietjes (talk • contribs)

You may be right, but I'd prefer to leave this to someone who understands these templates. Let's see if anyone else can confirm your "guess". — Martin (MSGJ · talk) 08:22, 27 April 2011 (UTC)

I am almost certain that it would work, but we might be able to simplify if both sides of the conditional do the same thing. I would have to look at it closer (or just have Wikid77 do it). Frietjes (talk) 21:07, 27 April 2011 (UTC)

I had a look: there are a myriad of candidates. I don't know which one(s).

--Nnemo (talk) 23:15, 27 April 2011 (UTC)

• The conversion of temperature ranges uses different formatting subtemplates (than conversion of other unit ranges), so I will check to see how to make the wrapping seem more logical. Also, beware that support for fractions requires 2 operations: first, to use {convert/numdisp}, and second, to ensure the fraction is converted to decimal, so that 14+1/2 gives the same result as 14.5: {{convert|14+1/2|C|F}}, compared to 14.5 °C (58.1 °F). -Wikid77 13:49, 2 May 2011 (UTC)

I have come across the same breaking problem mentioned above. Unfortunately I did not keep track of them. I simply "br" (between "<>" of course) before the conversion so as to force it onto the next line. Peter Horn User talk 20:02, 14 May 2011 (UTC)

• The temperature-conversion subtemplates should be changed using {nowrap} to stop wrap of "°" separate from "C". Currently:

• {{convert|3+1/2|C|F}}     → {{convert|3+1/2|C|F}}

The nowrap of parameter {1} would be

• {{nowrap|{{convert/numdisp|{{{1|3+1/2}}} }} {{{u|°C}}}}}

I think adding {nowrap} inside those subtemplates should be ok. -Wikid77 08:18, 20 May 2011 (UTC)

Applying nowrap is less effective than true non-breaking character, as nowrap does his job via some CSS, which is not enforced in all environments.

--Nnemo (talk) 14:10, 23 May 2011 (UTC)

Hello,

I encountered {{convert|3926|ha|acre|abbr=on}} → 3,926 ha (9,700 acres) here wrongly wrapping between the digital number and its unit.

--Nnemo (talk) 14:10, 23 May 2011 (UTC)

Request disabled for now. Please reactivate when there is consensus for a specific change. — Martin (MSGJ · talk) 08:36, 27 May 2011 (UTC)

Edit request from Nnemo, 4 May 2011 - non-breaking hyphen for correct typography

{{edit protected}}

Hello,

I saw a problem in usage of this template with parameter adj:

{{convert|86|m|ft|adj=on}} → 86-metre (282 ft)

At the end of a line was 86- poor and alone. A soft line break between the digital number and its unit. This is ugly.

Probably the problem occurs too with adj=mid.

I tried to find the hyphen(s) in order to replace them with correct ones, to no avail. It's too complicated to find them. But I bet that once found, replacing them is easy for me.

Please correct that typography: it will be nicer. :-)

To do so, please replace the hyphen between the digital number and its unit with a non-breaking hyphen : ‑.

Thanks,

--Nnemo (talk) 02:30, 4 May 2011 (UTC)

• There are several problems with trying to use a non-breaking hyphen everywhere, so use "{{nowrap|86-metre}}" when preferable. For larger numbers, the lack of wrapping, at the hyphen, would cause gaps at end-of-line, such as for the conversion "3,320-pound (1,510 kg)" in the weapons article "BL 18 inch Mk I naval gun". The non-breaking hyphen is unicode &#2011 (appears here in "XߛY"), and fails to match a search for hyphen in some browsers. Plus, changing all the related subtemplates would be a lot of work. However, I like the general concept of using the non-breaking hyphen, so perhaps next year, we could consider adding conditional logic of hyphens for use with small numbers. I am hoping the developers will increase the "expansion depth limit" (to higher than 40 levels), although unlikely. Meanwhile, special typesetting should be done as hand-coded, in various articles, and keep editing. -Wikid77 21:05, 4 May 2011 (UTC)

Thank you for your analysis, Wikid77.

Applying nowrap is less effective than true non-breaking character, as nowrap does his job via some CSS, which is not enforced in all environments. I understand the gap issue; I prefer the gaps; so there can be an off-by-default facultative option to allow wrapping. The browser who does not find non-breaking hyphen when searching hyphen is, in my humble opinion, too picky.

--Nnemo (talk) 14:12, 23 May 2011 (UTC)

Default target unit for inch conversions

Currently, the template converts inches to millimetres by default: 12 inches (300 mm). I hereby propose to change this default to centimetres, so that it gives 12 inches (30 cm) instead. (I'm going to advertise this discussion to Wikipedia:Bots/Requests for approval/Lightbot 10 where the issue came out most recently, to WT:MOSNUM, and to the village pump. The most recent discussion about this appears to be /Archive January 2010#Default for inches conversion changed?) ― A. di M.​_plé​^dréachtaí 20:03, 23 May 2011 (UTC)

• Support as nominator. Centimetres are way more common than millimetres outside technical contexts. While the proper choice of unit would depend on the context, I think that using 5.25 inches (13.3 cm) rather than the ideal 5.25 inches (133 mm) (e.g. in discussing some technical specification) is a much lesser evil than using 12 inches (300 mm) rather than the ideal 12 inches (30 cm) (e.g. in giving the typical size of some kind of animal), even because of the misleading rounding in the latter (12 inches equals 304.8 millimetres exactly); more importantly, I think that the situation of the latter kind are way more common than those of the former, so it's better to use centimetres by default and to manually specify millimetres in situations which warrant it. ― A. di M.​_plé​^dréachtaí 20:03, 23 May 2011 (UTC)
• Oppose - There are arguments both ways as to which is the better unit to use. However, now that the template has millimetres as its default, there are probably hundreds, if not thousands of articles that use this default. Changing the default is likely to have many more knock-on effects than the proposer envisages. Martinvl (talk) 20:40, 23 May 2011 (UTC)
• Oppose - I vote for stability i.e. no change. I'd rather not take sides but now the question has been raised, I think it's easiest to leave things as they are. The topic was raised at a Lightbot discussion page. Please read it. But note that Lightbot has no dependency on the convert template default for inches. It will operate within a different set of constraints. The current proposal is to apply:
  • mm up to 100 mm, fractional inches, rainfall, architecture, cameras, engineering and technical specifications, cars, trains, aircraft, modern ammunition and weapons, and instances where the article already contains mm

The use of an 'x mm' threshold is an arbitrary compromise only suited to bot code where it's adding *new* conversions, not template code for existing conversions. If a threshold is used for the template and set too low, it'll mix too many short integer inches with fractional inches. Lightmouse (talk) 21:06, 23 May 2011 (UTC)

• Oppose - Little if any merit to justify substantial disruption of existing uses. In the few cases where cm is desired, it can easily be explicitly invoked as new uses are added. LeadSongDog come howl! 22:03, 23 May 2011 (UTC)
• Support - It conforms to the general principle of choosing the closest unit to convert to. In daily use cm are much more common. Using cm is less likely to introduce false accuracy. The guideline mentioned above for the bot can still be applied, forcing mm in technical contexts, and it could do so in places that have a conversion already. −Woodstone (talk) 02:45, 24 May 2011 (UTC)
• Oppose - Most of the subjects I care about use mm (cars, engineering, architecture). Across all subjects I estimate its 50/50 which one is more common and we'd go through a lot of pain changing it for no real gain. Let editors override it if they really want cm.  Stepho  (talk) 05:14, 24 May 2011 (UTC)
• Neutral. The status quo may suggest a spurious precision, but I don't know if the disruption is worth changing it now. Rd232 ^talk 18:09, 24 May 2011 (UTC)

  Anyway, if we must have millimetres by default, I'd very much prefer 14 inches (356 mm) than 14 inches (360 mm). The former is excessively precise, but the latter is seriously misleading. ― A. di M.​_plé​^dréachtaí 19:43, 24 May 2011 (UTC)

  I don't think we must have this as the default but we mustn't have false precision. The template calculates the precision of the output according to a simple rule which takes into account the input precision. Let us not screw around with that. "360 mm" implies "360±5 mm", it's not misleading to one who can read numbers. There is a fair argument for centimetres over millimetres. The reason I made it millimetres in the first place was that these just seemed the preferable unit (powers of 1000) but the centimetre is closer to the inch so that makes good sense. How about we send a bot through and add |mm to all the inch conversions (perhaps not those where centimetres would be preferable anyway but someone would have to watch the bot) so that we don't rock the boat when the default is changed? JIMp _talk·cont 00:20, 25 May 2011 (UTC)

  I agree with the current rule for rounding, I just don't like the way it interacts with the choice of default units. “360 mm” doesn't imply “360±5 mm” that strongly because people who mean the latter would normally write “36 cm”; matter of fact, “360 mm” is more likely to mean “360 mm exactly by definition” or “as close as 360 mm as practically feasible by design”. (Another idea would be to add a tilde or “approx.” before the converted value whenever it ends with non-significant zeroes and the input value doesn't.) ― A. di M.​_plé​^dréachtaí 09:29, 25 May 2011 (UTC)

  The hypothesis is 'cm is more common than mm'. We have opinions for and against. But is there evidence to help the debate? Lightmouse (talk) 07:01, 25 May 2011 (UTC)

  In Google Books, apparently “centimeters” is about twice as common as “millimeters”[1] but “mm” is slightly more common than “cm”[2], confirming the impression that millimetres are more common in technical usage and centimetres elsewhere. ― A. di M.​_plé​^dréachtaí 09:29, 25 May 2011 (UTC)

• Oppose. I think the conversion of inches/mm for weather precipitation is a common issue where the default should be "mm" for users writing about weather patterns, whereas technology editors can specify "cm" when needed. A major goal of the defaults is to help editors who are unsure of the appropriate conversion, rather than default to the most common measurement in all notable subjects. The impact might be minor, but the concept is to be consistent in defaulting to help the editors who are most likely to be unsure of the typical conversion. -Wikid77 06:04, 26 May 2011 (UTC)

  I think that using centimetres instead than millimetres is not as bad as vice versa as far as the conveying of precision is concerned (see examples in my comment of 20:03, 23 May 2011), so it's better if someone unsure uses centimetres: the precision of 12 inches (30 cm), 12.3 inches (31.2 cm), 12.34 inches (31.34 cm), etc. are all obvious (as are those of 12.3 inches (312 mm), 12.34 inches (313.4 mm)), but that of 12 inches (300 mm) isn't. Also, most rainfall conversions are done within templates such as {{Infobox weather}}, so one just needs to specify the unit in them (if they don't already do; also, millimetres are used for rain but centimetres for snow). ― A. di M.​_plé​^dréachtaí 18:37, 26 May 2011 (UTC)

  BTW, did someone mess around with the default precisions? ― A. di M.​_plé​^dréachtaí 18:45, 26 May 2011 (UTC) Messing around with the examples above also reminded me about the over-zealous default rounding, where an input value given to within 10⁻ⁿ inches corresponds to an output rounded to the nearest 10⁻ⁿ × 10 cm = 10⁻ⁿ × 100 mm (except when the output would then have only one significant digit); IMO, an input to within 10⁻ⁿ inches should give an output rounded to the nearest 10⁻ⁿ cm = 10⁻ⁿ × 10 mm regardless of the number of significant digits. The choice of millimetres is even worse in this situation, IMO, as it's weird to give vague values while using a unit typically used for precise values. ― A. di M.​_plé​^dréachtaí 19:30, 26 May 2011 (UTC)

Template:College athlete recruit entry

I tried to add the convert template into Template:College athlete recruit entry. It didn't work for me. Does anyone else know how to do it? Lightmouse (talk) 17:20, 26 May 2011 (UTC)

There was a missing pipe between ft and {{{inches}}}. I also added defaults so it wouldn't mess up the template page but this is not the best of course. JIMp _talk·cont 17:52, 26 May 2011 (UTC) Got rid of those defaults and did some tidying. JIMp _talk·cont 17:59, 26 May 2011 (UTC)

Ah the missing pipe. Thanks for that and the other edits. Lightmouse (talk) 18:53, 26 May 2011 (UTC)

sigfig=1 inconsistent

Why, oh why does the template {{convert|0.2|mm|mil|lk=out|abbr=on|sigfig=1}} correctly produce "0.2 mm (8 mils)", while the template {{convert|0.025|mm|mil|lk=out|abbr=on|sigfig=1}} produces "0.025 mm (1.0 mil)"? Why "1.0 mil" instead of "1 mil"? You can see these in action in the article Aluminium foil. HairyWombat 21:30, 25 May 2011 (UTC)

Odd. And check {{convert|0.026|mm|mil|lk=out|abbr=on|sigfig=1}}, which does give "1 mil". Also, if you use {{convert|0.025|mm|mil|lk=out|abbr=on|sigfig=0}}, you get "1 mil". Frietjes (talk) 22:25, 25 May 2011 (UTC)\

The root of the problem is with template:Order of magnitude. For 0.025, it computes {{order of magnitude|( 0.025 )*0.001/0.0000254}} = -1. But for 0.026, it computes {{order of magnitude|( 0.026 )*0.001/0.0000254}} = 0. I don't see an easy fix. Frietjes (talk) 22:49, 25 May 2011 (UTC)

Sorry. We can only tell these computers what to do. Whether they do it or not is another question. JIMp _talk·cont 01:12, 26 May 2011 (UTC)

• At some point, the results of precision settings become unreal for amounts found in articles, and recent improvements have been focused on providing logical results to typical measurements, rather than for all extreme cases. Currently:

• {{convert|0.025|mm|mil|lk=out|abbr=on}} → 0.025 mm (0.98 mils)
• {{convert|0.025|mm|mil|lk=out|abbr=on|sigfig=1}} → 0.025 mm (1 mil)

The default results seem acceptable for most articles. However, thanks for asking the question, which might help uncover better algorithms for some conversions. To handle some extreme cases, I have had to add the tiny "fudge factor" 1E-9, to overcome internal rounding errors in the wiki-server math software, and a similar shift might be needed in this case. The reason {order of magnitude} is used, in all conversions, is to prevent a result of "0.048" from showing as "0" when the precision is 1 digit. Meanwhile, compare each formula, below, against the equivalent evaluated number:

• {{order of magnitude|( 0.025 )*0.001/0.0000254}} → -1
• {{order of magnitude|( 0.026 )*0.001/0.0000254}} → 0
• {{order of magnitude|0.98425196850394 }} → -1
• {{order of magnitude|1.0236220472441 }} → 0

Then, consider shifting the results by 2% higher (internally) to yield "1 mil":

• {{convert|0.025 * 1.02|mm|mil|lk=out|abbr=on|sigfig=1}} → 0.0255 mm (1 mil)
• {{convert|0.026 * 1.02|mm|mil|lk=out|abbr=on|sigfig=1}} → 0.02652 mm (1 mil)

When we refine an algorithm to handle extreme cases, some of which activate wiki-server system bugs, then we need to be sure not to overpower the handling of tiny amounts. Plus, the added complexity is difficult to explain to other editors, who might need to update the Convert subtemplates. So, it becomes an n-way problem: handle extreme cases, without upsetting typical amounts, and keep the Convert template within a reasonable level of complexity for newer editors. -Wikid77 06:04, 26 May 2011 (UTC)

I don't understand this. User Wikid77 writes "The reason {order of magnitude} is used, in all conversions, is to prevent a result of '0.048' from showing as '0' when the precision is 1 digit." With a precision of sigfig=1 then "0.048" should be displayed as "0.05". This doesn't look to me to be an extreme case. If the algorithm used does anything else then that is a bug. If the template {{Order of magnitude}} is being used to get around a bug then why not, instead, just fix the bug. (Also, sigfig=0 is meaningless, so I will change the doc page to discourage this.) HairyWombat 18:48, 27 May 2011 (UTC)

Delimiting comma

Is it possible to turn off the delimiting comma in four figure numbers, as per MOS? It's not a big deal, but I find the commas in something like 1,780 kg (3,920 lb) more of a distraction than anything else.
Justlettersandnumbers (talk) 11:25, 26 May 2011 (UTC)

I agree. The comma per se is too strong for such delimiting. French language uses nothing, a space or — in fine typography — a thin space.

--Nnemo (talk) 13:08, 26 May 2011 (UTC)

• Currently, the removal of commas is an option which must be specified (by "abbr=comma" or "disp=nocomma") in each conversion:

• {{convert|1780|kg|lb|-1|abbr=on}} → 1,780 kg (3,920 lb)
• {{convert|1780|kg|lb|-1|abbr=comma}} → {{convert|1780|kg|lb|-1|abbr=comma}}
• {{convert|1780|kg|lb|-1|abbr=on|disp=nocomma}} → {{convert|1780|kg|lb|-1|abbr=on|disp=nocomma}}

Because commas are often added to the whole conversion, as a string of text with numerals, it would be difficult to automatically remove commas from only the 4-digit numbers in all conversions. -Wikid77 (talk) 15:27, 26 May 2011 (UTC)

Brilliant, that is what I was looking for, that disp=nocomma. And no, I wasn't suggesting that the template should be specifically redesigned for the special case of four-digit numbers, that would really be asking too much! Many thanks again, Justlettersandnumbers (talk) 20:07, 26 May 2011 (UTC)

Back again. So am I using it wrong, or does it not work for ranges? I'm writing {{convert|800|–|900|kg|lb|abbr=on|disp=nocomma}} and getting 800–900 kg (1,800–2,000 lb) (some stuff in red). Any thoughts? Justlettersandnumbers (talk) 20:20, 26 May 2011 (UTC)

I created the missing template, but we need to remove the "formatnum" from template:convert/- to make it work properly. I will make an edit request. Frietjes (talk) 23:12, 26 May 2011 (UTC)

Great, many thanks to all for this. Justlettersandnumbers (talk) 23:17, 26 May 2011 (UTC)

I see that this has now been fixed for "to", "by" etc., for which many thanks, and which are now in use. Would it be possible for the future to fix it for the emdash also, such that {{convert|800|–nocomma|900|kg|lb|abbr=on}} does not give 800–900 kg (1800–2000 lb) (Template:Convert/–nocomma in red)? Thank you all again! Justlettersandnumbers (talk) 12:51, 27 May 2011 (UTC)

• Use a lead hyphen (as "-nocomma") in the range-word for the dash option, which has been allowed since November 2009:

• {{convert|800|-nocomma|900|kg|lb|abbr=on}} → 800–900 kg (1800–2000 lb)

• {{convert|800|-nocomma|900|kg|lb|abbr=on|lk=on}} → 800–900 kg (1800–2000 lb)

Note how all other options work with the -nocomma, such as "lk=on" to trigger wikilinks. -Wikid77 16:10, 27 May 2011 (UTC)

Noted indeed. Many, many thanks for the quick and complete response to this essentially rather trivial request. Justlettersandnumbers (talk) 16:48, 27 May 2011 (UTC)

Crippling Convert to police MOSNUM ideas

27-May-2011: I disagree with the notion to cripple options in Convert subtemplates to absolutely force users to follow the styles in the WP:MOSNUM guideline, as if they were mandated by voice-of-God decisions. In particular, some editors are purposely forcing Convert to totally ignore the option "abbr=on" for the unit-codes "LT" and "ST" so that, under no circumstances whatsoever, would a user ever be allowed to use Convert options to show the symbol "LT" for "long ton" or "ST" for short ton, even though those symbols have been used in the real world for more than 120 years. Instead, the option "abbr=none" can be used avoid the display of symbols in particular conversions. I will try to find a way to allow Convert to show the LT/ST symbols. Meanwhile, just hand-code some conversions to show the "LT" and "ST" symbols in articles, where needed for real-world concerns. Wikipedia allows WP:IAR to ignore all rules which are out-of-touch with reality. -Wikid77 09:12, 27 May 2011 (UTC)

• I have created new unit-code "lt" (lower-case for "LT") to allow showing symbol "LT" by using option "abbr=on". That lower-case "lt" can be used to convert short tons [ST] to long:
      • {{convert|23|ST|lt}} → 23 short tons (21 LT)
  Using lowercase unit-code "lt" allows the symbol "LT" to appear where needed for real-world concerns, such as in shipping of cargo. -Wikid77 10:03, 27 May 2011 (UTC)

If MOSNUM is out of touch with reality, change MOSNUM. It's not us verses them. MOSNUM is not an outside authority but represents Wikipedia consensus ... or should. There is a definite feeling at MOSNUM that we should follow reality.

There's also been a feeling here that convert should follow MOSNUM. This debate goes beyond the "LT" and "ST" subtemplates, beyond this template altogether. Should general-purpose templates adhere to WP guidelines in principle? Ignoring rules is great where in the specific case this would be best but here we have a general-use template. JIMp _talk·cont 15:46, 27 May 2011 (UTC)

• Need dynamic standards with Convert: The broader debate, for any template with MOSNUM, should be continued at WT:MOSNUM; however, history has notorious examples of standards causing trouble, as with Convert following MOSNUM standards. A classic example is the R.M.S. Titanic with limited lifeboats, which met the old standard of 16 boats for "any large ship" plus Titanic also had 4 collapsible lifeboats, but the ship's architects had designed for even more lifeboats, yet the 16 boats met the standard, and that was the limitation. Hence, the architects knew the standard was insufficient, but the unrealistic, outdated standard won. The standards were changed, and many dynamic standards were added (not just a static standard of "16 boats"), but it took time (and disasters) to align the standards with real-world concerns. Wikipedia still has WP:IAR to ignore all rules, such as standards out-of-touch with reality, and allows Convert to be more versatile. Meanwhile, when expanding to dynamic standards, the standard rules will attempt to "model reality" with more cause-effect wording in the rules. For example, after Titanic, a dynamic standard was defined to always require a response to an ice warning (or iceberg warning), with an entry in the ship's log, to show either a course change or speed change upon receiving an ice-flow warning, as evidence of a wide-awake response to danger. Titanic had received several ice warnings that night, but continued on course. Although the ship wasn't travelling at "full speed" at impact, it was going 96% of full speed, reportedly 22 of 23 knots (43 km/h; 26 mph) top speed. The shipping standards were changed to consider modelling the motion of ships through the ocean, to reduce dangers. In a similar manner, Wikipedia standards should involve dynamic standards, for how the issues change as an article is edited, or greatly expanded, or read by thousands of people each day. Unless the WP rules change with the size of the article, then is like "16 lifeboats" regardless of the size of the crew and passengers. If the standards are not dynamic, such as not varying with article size (or with ancient sources for a topic), then I think the WP:MOS guidelines are too simplistic to be followed, for all real-world concerns. Realistic standards are very difficult to write, so I advocate that Convert retain a focus on real-world use of measurements, with a loose connection to WP:MOSNUM, in these early years of WP standards. -Wikid77 02:41, 28 May 2011 (UTC)

Debating WP:MOSNUM to allow LT/ST symbols

27-May-2011: I have been debating the WP:MOSNUM (the numeric guideline in the WP:MOS) to show "LT" as the symbol for long ton and "ST" for short ton. See discussion:

• WT:Manual_of_Style_(dates_and_numbers)#LT and ST symbols for long ton and short ton

Because the abbreviation "LT" has been used for "long ton" for more than 120 years, people have been finding it in many source documents. This usage requires a change to WP:MOSNUM. The following extensive list of 23 sources, below, shows books in each decade, for the past 124 years, using "LT" to indicate long tons:

• 1887, Die Chemische Industrie, p.376, "LT = long ton = 2,24 Pfund.".
• 1908, Walton & Holmes's arithmetics, p.105, "2240 pounds = 1 long ton (LT)".
• 1909, Harper's machinery book for boys, p.354, "2240 pounds - 1 long ton (LT)".
• 1916, A community arithmetic, P.108, "1 long ton or gross ton (LT)".
• 1917, Arithmetic by grades: book, "2240 pounds = 1 long ton (LT)"
• 1929, Woman's Institute library of cookery, "2240 pounds make 1 long ton (LT)".
• 1932, Wirtschaftliche Mitteilungen, Deutsche Bank (1870-1945)
  "1 engl, long ton (lt) - 1016,047 kg. 1 engl. (USA) pound (Ib.)".
• 1938, Journal of world forestry,
  "long ton = 1,01605 t lt 2,2046 lb (pounds) 2,2046 centals 1968 cwt".
• 1940, The output of manufacturing industries, 1899-1937, "gr. gross t. ton lt long ton".
• 1942, Modern ship stowage: including methods of handling cargo at ocean, "the long ton, ...indicated by the letters "LT."
• 1955, The Dock and harbour authority, "An additional 507 LT were ... tons i Total long ton".
• 1960, Journal of the Institute of Petroleum, "pounds sterling per long ton (£/LT)".
• 1963, Inland and maritime transportation of unitized cargo, "cu. ft. per long ton (LT)".
• 1964, The great Alaska earthquake of 1964, p.271, "0.9842 long ton (LT)".
• 1976, Solar thermal and ocean thermal: joint conference, "57-long-ton (LT) heat exchanger modules".
• 1977, A screening for potentially critical materials..., p.49, "TrOz - Troy Ounce LT Long Ton".
• 1980, The impact of overseas troop reductions on the U.S.-flag merchant..., p.86, "factor of 76 cu ft per long ton (LT) of 2240 lb."
• 1981, Department of Defense appropriations, "2000 long ton (LT) elevator lift system".
• 1985, Webster's guide to abbreviations, "long-term memory LTM long ton lt long wave LW".
• 1993, Naval engineers journal, "A 36.7 long ton (LT)".
• 2005, Webster's two new college dictionary, p.1325, "LT ... 2. local time. 3. long ton".
• 2006, Amelia's Notebook, "droo +M 1 long ton (LT.)".
• 2011, Department of Defense Dictionary of Military and Associated Terms, p.SL1-90, "LT large tug...; long ton".

Those are some published books which show an abbreviation for "long ton" as a measurement for more than 124 years. I could list a dozen more books; however, I think the use of "LT" to indicate "long ton" has been established since, at least, the year 1887, with continual use through 2011. Based on historical use of "LT" then "ST" naturally follows. (Also see related topic: "#Crippling Convert to police MOSNUM ideas" as a general issue). -Wikid77 (talk) 09:12, 27 May 2011 (UTC)

• I have had changed WP:MOSNUM, but it was reverted, to try showing symbol "LT" for long ton and "ST" for short ton, based on the 23 sources above. I apologize that I did not address this issue, years ago, when it first arose. Dozens of sources have been available, for years, to verify the historical usage, but other issues distracted the focus away from specifying the LT/ST symbols. The debate at WP:MOSNUM, for years, has been the concern of several different symbols for "long ton" (including: LT, lt, L/T and Lt.) and trying to avoid choosing a specific symbol, by not allowing any symbol. Instead, there are now 2 unit-codes for long ton: the current default as upper-case unit-code "LT" will always show the full name ("long ton"), while the unit-code lower-case "lt" will allow symbol "LT" when the full name would be tedious. By having those 2 different unit-codes, then each editor can decide when to abbreviate to symbol "LT" for brevity, while still having Convert to calculate the conversion amounts for long tons. There is a similar concern in American-English articles, to avoid repeating "short ton" and "short ton" by using the word "ton" later in an article, but this is not certain yet. More later. -Wikid77 (talk) 13:14, revised 15:24, 27 May 2011 (UTC)

ST/LT conversions

Short and long ton range conversions appear to be broken when using the abbreviations ST and LT. Replacing them with "short ton" and "long ton" apparently fixes the problem; see here. mgiganteus1 (talk) 09:37, 27 May 2011 (UTC)

• Thanks for the note. Currently, the results are:

• {{convert|7|to|20.9|t|ST}} → 7 to 20.9 tonnes (7.7 to 23.0 short tons)

• {{convert|7|to|20.9|t|short ton}} → 7 to 20.9 tonnes (7.7 to 23.0 short tons)

Use lowercase "lt" to show symbol "LT" as in:

• {{convert|7|to|20.9|t|LT}} → 7 to 20.9 tonnes (6.9 to 20.6 long tons)

• {{convert|7|to|20.9|t|lt}} → 7 to 20.9 tonnes (6.9 to 20.6 LT)

There have been recent changes to purposely cripple the unit-codes "LT" and "ST" so that users would be forced, regardless of any real-world circumstances, and insist that Convert never, ever be allowed to show symbol "LT" (or "ST"), which has led, now, to the current problems. Thanks again for notifying about those problems. -Wikid77 10:17, 27 May 2011 (UTC)

This is an interesting way to explain what's been going on. The problem is the missing Na see the updates subpage. JIMp _talk·cont 12:03, 27 May 2011 (UTC)

The change to use no abbreviation occurred about three years ago. This was recently reverted. The revert was then reverted pending a decision at MOSNUM but there was a missing piece of code.

The first lines of Template:Convert/ST (edit | talk | history | links | watch | logs) and Template:Convert/LT (edit | talk | history | links | watch | logs) should be (for now at least)

{{convert/{{{d}}}Na|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}|s={{{s|}}}|r={{{r}}}

JIMp _talk·cont 12:35, 27 May 2011 (UTC)

Wikid77 here. I concur with Jimp's requested fix, above. We also have new Template:Convert/lt to show symbol "LT" and so the above fix will always show "long ton" while editors can use "lt" when they want the option to show the symbol (as: 21.5 LT). -Wikid77 15:45, 27 May 2011 (UTC)

Done. Plastikspork _―Œ^(talk) 20:33, 27 May 2011 (UTC)

Template:Convert/shtn for short ton symbol

Sources show many symbols for "short ton" but a common one is "sh tn". The Template:Convert/shtn, invoked by unit-code "shtn", can be used for converting short tons with other units. It will display the unit symbol "sh tn" in abbreviated mode (such as for "abbr=on"); however, the full unit name "short ton" is preferred for the first 1 or 2 cases in an article, as displayed when using upper-case unit-code "ST" which always shows "short ton" in measurement conversions.
The article "Conversion of units" currently uses symbol "sh tn" in tables. Other unit symbols, for short ton, include: TN, tn, T, stn, st or ST (but I have not studied the frequency of use for those other symbols). If editors show a wide-ranging need for another symbol, such as "TN" in commercial farming, then I would think a similar template could be created to support many articles in an industry which uses a specific symbol as the common jargon. The symbol "tn" is used ambiguously, in several sources, to also denote a "long ton" and hence, some symbols (such as "tn") should be avoided for professions where both units are used in the same articles. More later. -Wikid77 06:32, 28 May 2011 (UTC)