Jump to content

Template talk:Convert/Archive March 2010

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


Better integer precision for Convert/ft

02-March-2010: Back on 30Oct09 plus 25Feb10, I started a proposed higher-precision for m-to-feet conversions, in Template:Convert/ft/sandbox. The basic problem has been Convert auto-rounding gives 32m=100ft rather than 105ft (and such). So far, the plan has become to increase the precision by 1 significant digit for whole numbers (also negative integers) but leave amounts with decimals/fractions as unchanged. Compare the increased precision of the ft/sandbox version:

  • {{convert|30|m|ft}} →   30 metres (98 ft) & ft/sandbox →   30 metres ([convert: unknown unit])
  • {{convert|31|m|ft}} →   31 metres (102 ft) & ft/sandbox →   31 metres ([convert: unknown unit])
  • {{convert|32|m|ft}} →   32 metres (105 ft) & ft/sandbox →   32 metres ([convert: unknown unit])
  • {{convert|64|m|ft}} →   64 metres (210 ft) & ft/sandbox →   64 metres ([convert: unknown unit])
  • {{convert|30.1|m|ft}} →   30.1 metres (99 ft) & ft/sandbox →   30.1 metres ([convert: unknown unit]) [unchanged]
  • {{convert|30.2|m|ft}} →   30.2 metres (99 ft) & ft/sandbox →   30.2 metres ([convert: unknown unit]) [unchanged]
  • {{convert|74.3|m|ft}} →   74.3 metres (244 ft) & ft/sandbox →   74.3 metres ([convert: unknown unit]) [unchanged]
  • {{convert|3000|m|ft}} →   3,000 metres (9,800 ft) & ft/sandbox →   3,000 metres ([convert: unknown unit])
  • {{convert|3100|m|ft}} →   3,100 metres (10,200 ft) & ft/sandbox →   3,100 metres ([convert: unknown unit])
  • {{convert|3200|m|ft}} →   3,200 metres (10,500 ft) & ft/sandbox →   3,200 metres ([convert: unknown unit])
  • {{convert|3200.5|m|ft}} →   3,200.5 metres (10,500 ft) & ft/sandbox →   3,200.5 metres ([convert: unknown unit]) [unchanged]
  • {{convert|6000|m|ft}} →   6,000 metres (20,000 ft) & ft/sandbox →   6,000 metres ([convert: unknown unit])
  • {{convert|6000|m|ft|0}} →   6,000 metres (19,685 ft) & ft/sandbox →   6,000 metres ([convert: unknown unit])
  • {{convert|7+1/2|m|ft|0}} →   7+1⁄2 metres (25 ft) & ft/sandbox →   7+1⁄2 metres ([convert: unknown unit])

Decimals would remain unchanged, and all amounts are still auto-rounded, such as 6000 m ~= 20,000 ft, but the rounding is better as giving 32m=105ft or 3200m=10500ft or similar amounts (for whole integers). Inside of Template:Convert/ft/sandbox, the default precision is set as j=-0-{{{j|0}}} only for integers, decided by floor(amount)=amount. It works, so I wonder if anyone still objects to submitting ft/sandbox for edit-protect update as the current version of Convert/ft. -Wikid77 (talk) 17:05, 2 March 2010 (UTC)

Problematic

1 gauge

1+17⁄32 inches (39 mm)
1+17⁄32 inches (38.89 mm)
  • 1+17⁄32 in (38.89 mm) vs 1+7⁄32 in or 30.96 mm or

1+17⁄32 in (38.89 mm)*, 1+17⁄32 in (38.89 mm)*. The latter 3 do not work when greater than 1 inch.

  • 19⁄64 in (7.54 mm) vs 19⁄64 in or 7.54 mm or

19⁄64 in (7.54 mm)*, 19⁄64 in (7.54 mm)*. The latter 3 only work when less than 1 inch.

Any way that this can be fixed?? Peter Horn User talk 21:58, 3 March 2010 (UTC)

  • 17/32 in = 0.53125 in
    • 1.53125 in (38.89 mm) vs 1.53125 in or 38.89 mm, 1.53125 in (38.89 mm)*, 1.53125 in (38.89 mm)*.

Peter Horn User talk 22:27, 3 March 2010 (UTC)

To be completely blunt, trying to allow fractions was a big mistake, not to mention it looks terrible when it doesn't work correctly. I've got no idea how this magic functions, but I would like to convince Wikid and whomever else works on the next iteration of the template to get rid of this. — Huntster (t @ c) 01:03, 4 March 2010 (UTC)
  • Done. Subtemplates should always use parentheses "( )" around {1}: ( {{{1}}} )*{{{b}}}:
         {{convert|1+17/32|in|mm|disp=comma|abbr=on}} gives:   {{convert|1+17/32|in|mm|disp=comma|abbr=on}}
    The changes have been submitted as edit-protect requests to 4 subtemplates for updates within the next few hours. -Wikid77 (talk) 05:41, 4 March 2010 (UTC)

Problems at Slovakia#Climate_of_lowlands

I tried figuring out what was wrong, but everything looks fine with the use of the template to me. Any idea? Headbomb {talk / contribs / physics / books} 05:38, 5 March 2010 (UTC)

Your usage looks correct to me but the template has a bug with °F as the output (which is the default). Also, you should have either 'to' or '-' but not 'to(-)'. Try it with C and F instead of °C and °F like this {{convert|9|to|10|C|F|0}} to give 9 to 10 °C (48 to 50 °F) .  Stepho  (talk) 07:55, 5 March 2010 (UTC)
Great, that fixed it. Also {{convert|9|to|10|C|F|0|abbr=on}} is buggy, although that may not be a valid input. Anyway, thanks a bunch. Headbomb {talk / contribs / physics / books} 08:30, 5 March 2010 (UTC)
Why should Headbomb "have either 'to' or '-' but not 'to(-)'"? The "to(-)" is a documented option that should work. Fix it, too! It is supposed to put "to" in the input units, and an en dash in the output units, according to the documentation. But it is not only broken here, but elsewhere as I will point out in a separate section. Gene Nygaard (talk) 02:21, 6 March 2010 (UTC)
  • Okay, I changed to allow the "°" symbol with "°C|°F" in ranges, as in the example:
{convert|9|to|10|°C|°F} → 9 to 10 °C (48 to 50 °F)
The bug for "abbr=on" has remained from years ago in Template:Convert/Dual/LoffAonDbSoffT (another subtemplate), but I will submit an edit-protected request to have it fixed as well. Thanks for taking the time to note those problems -Wikid77 (talk) 18:54, 5 March 2010 (UTC)
Okay--now how about the same problem using a degree sign in in {{convert|27|°F-change}} → 27 °F (15 °C) and the like which I pointed out above on 14 February? Can you fix that, too? It part of the same rampant look-and-feel problems with this template. Gene Nygaard (talk) 09:03, 6 March 2010 (UTC)
Also, did you try to fix the problem that "abbr=on" doesn't make any difference in those temperature conversions? It never did do anything in
  • {{convert|9|C|F|0}} to give 9 °C (48 °F)
  • {{convert|9|C|F|0|abbr=on}} to give 9 °C (48 °F)
It gives the same results, with or without "abbr=on".
Furthermore, it looks like your change has been implemented because it doesn't give error messages any more when used with the ranges, and that also gives the same results either way:
  • {{convert|9|to|10|C|F|0}} to give 9 to 10 °C (48 to 50 °F)
  • {{convert|9|to|10|C|F|0|abbr=on}} to give 9 to 10 °C (48 to 50 °F)
Just more look and feel problems. Even if you want to default to abbr=on, you could make "abbr=off" work, but that is useless too:
  • {{convert|9|C|F|0|abbr=off}} to give 9 degrees Celsius (48 degrees Fahrenheit)
  • {{convert|9|to|10|C|F|0|abbr=off}} to give 9 to 10 degrees Celsius (48 to 50 degrees Fahrenheit)
Obviously, the problem hasn't yet been "fixed"; ameliorated a bit maybe, but that's all. A crude patch that serves to hide its brokenness when the abbr=on parameter is used, so that people who do use it won't find out that leaving it off doesn't work. Gene Nygaard (talk) 09:03, 6 March 2010 (UTC)
  • The current option to show non-abbreviated "degrees" or "kelvins" is "abbr=none":
  • {{convert|9|to|10|C|F|0|abbr=none}} to give 9 to 10 degrees Celsius (48 to 50 degrees Fahrenheit)
  • {{convert|119|to|135|K|C|0|abbr=none}} to give 119 to 135 kelvins (−154 to −138 degrees Celsius)
However, I will try to get abbr=off to function as expected, which has been forced to become abbr=on. -Wikid77 (talk) 13:40, 6 March 2010 (UTC)
But that spells out both sides, giving 9 to 10 degrees Celsius (48 to 50 degrees Fahrenheit); there isn't any way to spell out just the input units. The standard template:convert usage is to use symbols for the converted result, and spell out the input units, when abbr is not set to on.
Note also that when you don't have a range of temperatures but only a single reading, it works differently. Then it gives you what it should give you when abbr= is empty (not used) or off; it doesn't give you both units spelled out, as it should when we use abbr=none.
  • 33 degrees Celsius (306 kelvins)
  • 33 kelvins (−240.2 degrees Celsius)
Of course, this exposes one more humungous bug. Can somebody fix the improper capitalization and the plural form of kelvins? Gene Nygaard (talk) 19:30, 6 March 2010 (UTC)

Broken "to(-)" option

As I was coming to complain about this range option not working right in other articles, I noticed above that it also did not working the temperature ranges. This is a documented option that should work. Sometimes it does. Often it does not.

Input Displays as
Example from the documentation
{{convert|60|to(-)|170|kg|lb}} 60 to 170 kilograms (130–370 lb)
But screwy template is kaput in another article
{{convert|14|to(-)|15|cm|in|abbr=on}} 14 to 15 cm (5.5–5.9 in)

Can somebody fix this? Gene Nygaard (talk) 02:27, 6 March 2010 (UTC)

  • It's not really broken. Apparently, the result of "to(-)" is intended to put "-" between abbreviated amounts rather than always put "to" on the left and "-" on the right. Note, in examples below, how they show "-" between symbol amounts but "to" with full unit-names:
  • {{convert|14|to(-)|15|cm|in|abbr=on}} → 14 to 15 cm (5.5–5.9 in)
  • {{convert|14|to(-)|15|cm|in|abbr=off}} → 14 to 15 centimetres (5.5–5.9 inches)
  • {{convert|14|to(-)|15|cm|in|abbr=in}} → 14 to 15 cm (5.5–5.9 inches)
  • {{convert|14|to(-)|15|cm|in|abbr=out}} → 14 to 15 centimetres (5.5–5.9 in)
I understand the use of dash "-" between all symbol amounts can be confusing, but the option as "to(-)" doesn't have a world-standard meaning, so it became to put "to" only between the full unit-name amounts. This option seems to be a case of too much specialization, as an example of creeping featurism. That's why we recommend hand-tailoring some conversions (with "disp=output only"), instead of requesting new options for every special case of separators (such as wanting "through" or "up to" or "down to"). -Wikid77 12:00, 6 March 2010
Yes, it is broken. There's no reason why anybody would assume such a strange intent from the documentation. I didn't read it that way, and I wouldn't do so even after your claims above. The editor of the article I took the example from obviously didn't intend it that way.
Even if it was intended that way by this template's editors, it doesn't make any sense to do it that way. Why in the world would some editor put a "to" in this parameter's options, and not want to get a "to" in either of the results? Duh! Nobody's going to do that. We use "to(-)" expecting to get a "to" in one place and a dash in the other. Editors put the "to" into the parameter for a reason. I don't care if it is broken in the planning, or broken in the implementation. It's broken.
What we need is something that works with "from ... to" constructions and the like. That's something specifically prescribed in the Manual of Style: "Ranges expressed using prepositions (from 450 to 500 people or between 450 and 500 people should not use dashes (not from 450–500 people or between 450–500 people)." This doesn't comply with that rule. Gene Nygaard (talk) 15:15, 6 March 2010 (UTC)

Broken "lk=" parameter

Can somebody fix this problem with the "lk=" parameter, please?

49,000 square kilometres (19,000 sq mi)
49,000 square kilometres (19,000 sq mi)
49,000 square kilometres (19,000 sq mi)
49,000 square kilometres (19,000 sq mi)
49,000 yards (45,000 m)
49,000 yards (45,000 m)
49,000 yards (45,000 m)
49,000 yards (45,000 m)

The first two in each set work fine, leaving off the "lk" parameter or having "lk=on" or "lk=off". But it is broken and messes up the other formatting of the input numbers when "lk=in" or "lk=out" is used. Gene Nygaard (talk) 08:24, 6 March 2010 (UTC)

These new codes should fix it.
Template:Convert/LinAoffDbSoff (edit | talk | history | links | watch | logs)
<includeonly>{{convert/numdisp|{{{1}}}}} [[{{{t|{{{n}}}}}}|{{#ifeq:{{{1}}}|1|{{{n}}}|{{{l|{{{n}}}s}}}}}]] ({{convert/{{#if:{{{2|}}}|{{{o}}}|{{{3}}}}}|{{{1}}}|({{{1}}})*{{{b}}}|{{#if:{{{2|}}}|{{{3|}}}|{{{4|}}}}}|{{{s|}}}|r={{{r}}}|j={{{j}}}|d=LoffAonSoff}})</includeonly><noinclude>
{{pp-template|small=yes}}
[[Category:Subtemplates of Template Convert]]
Template:Convert/LoutAoffDbSoff (edit | talk | history | links | watch | logs)
<includeonly>{{convert/numdisp|{{{1}}}}} {{#ifeq:{{{1}}}|1|{{{n}}}|{{{l|{{{n}}}s}}}}} ({{convert/{{#if:{{{2|}}}|{{{o}}}|{{{3}}}}}|{{{1}}}|({{{1}}})*{{{b}}}|{{#if:{{{2|}}}|{{{3|}}}|{{{4|}}}}}|{{{s|}}}|r={{{r}}}|j={{{j}}}|d=LonAonSoff}})</includeonly><noinclude>
{{pp-template|small=yes}}
[[Category:Subtemplates of Template Convert]]
JIMp talk·cont 10:03, 6 March 2010 (UTC)
Sure, it might. But so what? You can't fix it, I can't fix it, Wikid77 can't fix it. Part of the problem here is rampant abuse of the page protection process. There might be some justification for protecting the main template page and a couple of subpages, but the is no good reason for page protection on a zillion pages here. Gene Nygaard (talk) 17:40, 6 March 2010 (UTC)
  • I understand it is frustrating to request admins to handle these edits, but some open Convert subtemplates have been attacked by vandals, several times, and it is not worth the risk of someone spamming their hacked comment into a set of articles read 3,000-150,000 times a day, just because Convert currently omits a comma, only for some options, only for amounts > 999. In my analysis, I have seen vandalism quips left for 11 months, or viewed 28,000 times, before someone was able to remove them. Far more people read articles than fix them. Always consider: if the cure might be worse than the disease; can we deal with numbers lacking commas while the updates for commas are delayed a few hours longer. Those updates have been done. -Wikid77 00:12, 7 March 2010

Requesting fixes within /updates

06-March-10: At the suggestion of admin User:Huntster, I have created another talk-subpage to list edit-protected requests, Template talk:Convert/updates. That page can list several {{editprotected}} requests, for the subtemplates, to keep them all together on a single page, and reduce clutter by avoiding updates on this talk-page. It should make updates 10x-20x times easier, since some problems require changes to 24-40 subtemplates at a time, and the test-cases can be easily copied from other edit-requests in the total list. See subpage "/updates" for more details. -Wikid77 (talk) 17:57, 6 March 2010 (UTC)

New bug

Something happened recently. Compare this and this. The first version uses the syntax {{convert|1131|m|ft}} and the second uses {{convert|1131|m|ft|0}}. The first version displays errors. –droll [chat] 08:50, 8 March 2010 (UTC)

  • That problem currrently has a solution, being reviewed, as a new update proposed in {{Convert/ft/sandbox}}:
{{convert|1131|m|ft|0}} → 1,131 metres (3,711 ft)
{{convert|1131|m|ft}}           → 1,131 metres (3,711 ft)
{{convert|1131|m|ft/sandbox}} → 1,131 metres ([convert: unknown unit])
See topic above: #Better integer precision for Convert/ft. Thanks for letting us know that the error with the 4-digit "1131" because we were planning the fix for other errors, unaware the problem was so wide-spread as to include 1131. -Wikid77 (talk) 15:51, 8 March 2010 (UTC)
Other bug below: #Possible template-nesting limit. -Wikid77 13:28, 9 March 2010

Use abbr=out to get: degrees Celsius

08-March-10: This is a reminder, for temperature conversions, use option "abbr=out" to get the full unit names as "1 degree Celsius" or "32 degrees Fahrenheit" or "267 kelvins" etc. -Wikid77 (talk) 15:51, 8 March 2010 (UTC)

A reminder, too, of all the look and feel problems in this template.

abbr= temperature normal
[empty] 2,369 K (3,805 °F) 2,369 kilograms (5,223 lb) different
off 2,369 kelvins (3,805 degrees Fahrenheit) 2,369 kilograms (5,223 pounds) different
on 2,369 K (3,805 °F) 2,369 kg (5,223 lb) same
in 2,369 K (3,805 degrees Fahrenheit) 2,369 kg (5,223 pounds) broken
out 2,369 kelvins (3,805 °F) 2,369 kilograms (5,223 lb) same
none 2,369 kelvins (3,805 degrees Fahrenheit) 2,369 kilograms (5,223 pounds) different plus broken unit name and broken plural
comma {{convert|2369|K|°F|abbr=comma}} {{convert|2369|kg|lb|abbr=comma}} different
mos 369 to 411 K (205 to 280 °F)* 369 to 411 kilograms (814 to 906 lb)* broken

Only two work the same in both. It might be, if arrived at by consensus and well explained in the documentation, acceptable to have different defaults when abbr= isn't there. Note that we can get pounds as output units spelled out (with either kilograms spelled out or kg symbol), but we can never get degrees Fahrenheit as output units spelled out. Gene Nygaard (talk) 01:11, 9 March 2010 (UTC)

  • Thanks for the list. I'll try to fix "abbr=none" & "abbr=in" soon. -Wikid77 12:03, 9 March 2010

Hyphen vs. minus sign

There seems to be a problem with the use of hyphens (-) on conversions that should be minus signs (−). Or it's my eyesight. See Mono-Inyo Craters#Climate and ecology. SandyGeorgia (Talk) 22:08, 20 February 2010 (UTC)

  • Wikipedia uses standard computers to calculate conversions, so the negative numbers have hyphens, as typical in computers for at least 50 years. The unicode minus sign has to be inserted by Convert after the calculations. However, the hyphens are still readable: just about any solitary dash preceding a digit has been considered a "negative number" for hundreds of years. Meanwhile, a wikisearch still cannot match "-4" nor can Google Search, nor Bing.com. I'm still waiting for a search-engine that could hunt "-4", like perhaps a Google Duh, or Ba-Duh-Bing, but they can't even find "Y=X+2" in webpages. It's so utterly pathetic. Hence, there is a real need for "−4" to be coded as "negative 4" so that searches could match it. That is one of many trivial problems with computers: HTML allows "<center>" but not "<left>" or "<right>". How clueless is that? So, if anyone asks about the word "nerd" just give them the example of billion-dollar search-engines that can't match a "-4" in a webpage, even after 10 years. -Wikid77 12:03, 21 February 2010
    • WP:MOS calls for negative signs, the convert template is causing Featured articles to be out of compliance. We should be able to fix this; it's wrong. SandyGeorgia (Talk) 16:50, 21 February 2010 (UTC)
        • Template:Convert causes a lot more featured articles to be out of compliance with WP:ENGVAR. Why don't you worry about that, Sandy? But it almost never uses a hyphen when a minus sign would work; that isn't Wikid77's complaint here. Most of our negative signs in conversions using this template result in the scaled conversions on various non-absolute temperature scales. And in {{Convert|-40|°C}}, what do we get? We get minus signs in −40 °C (−40 °F), for both the Fahrenheit and Celsius temperature readings. Gene Nygaard (talk) 22:30, 21 February 2010 (UTC)
      • Is there a way to text substitute a hyphen for a minus in the output stage? Orderinchaos 17:27, 21 February 2010 (UTC)
        • Until this is fixed, we can just use manual conversions in the article. Dabomb87 (talk) 18:17, 21 February 2010 (UTC)
        • Fixed in the crater article, anyway. Dabomb87 (talk) 18:19, 21 February 2010 (UTC)
          • That's a solution that should be used more often; the difference in handling the output of temperature ranges, using hyphens for negative signs in the converted results (yet strangely using minus signs in the original units), compared with the handling of individual temperatures, where we always get minus signs for negative signs, is one of many little glitches in the convert template. It results from a near-total lack of concern for a consistent look and feel in the template's actions. (The use of a minus sign here is, I think, proper--there isn't a separate sign for negative numbers; it should be unspaced when used as a negative sign, and it is normally spaced when used as a minus sign indicating subtraction.)
          • Note also that dashes are extremely confusing when used to indicate a range, yet Template:convert also does this:
            {{convert|-8|-|-3|F|C}}→−8 – −3 °F (−22 – −19 °C)
          • In that case, with a hyphen to indicate ranges in the input and a hyphen to indicate negative numbers in the input (which is the correct way to do it), it uses the en dash to indicate both ranges in the output, it uses a minus sign for the negative temperature in the original temperatures put into the template, and it uses the hyphen as a negative sign for temperatures resulting from the conversion. It would be no better if it used the minus sign for all the negatives:
            −8–−3 °F (−22–−19 °C)
          • That option of using dashes should simply be disabled for temperature conversions, the most common case in which members of the range might be negative. Gene Nygaard (talk) 23:03, 21 February 2010 (UTC)

Of course, a similar problem also occurs in conversions other than temperatures. Here's an example from a featured article:

  • {{convert|-6700|cuft/s|m3/s|0}} → −6,700 cubic feet per second (−190 m3/s)

giving a hyphen for the first negative sign, and a minus sign for the second negative sign. It works the same way for any non-temperature conversion, I think. That mixture is worse than using hyphens across the board for this. Gene Nygaard (talk) 14:12, 23 February 2010 (UTC)

Yes, consistency should have higher priority than getting any one of the signs "correct." As for the range problem, I always write it as "−8 to −3 °F (−22 to −19 °C)." Rees11 (talk) 16:07, 13 March 2010 (UTC)

No units

I want to fill in a table of kW/hp figures without the units showing at Toyota Prius#Comparison of models. I.e. given an input value of 43, I would like it to show 43/58. I've tried everything on the doc page but all them either show a unit name or an error. I can do 43/{{convert|43|kW|bhp|disp=output number only}} to give 43/58 but that requires typing the input value twice - which is error prone when somebody updates one copy of the input without also updating the other copy. Am I missing something?  Stepho  (talk) 09:26, 8 March 2010 (UTC)

Perhaps "disp=table" is what you're looking for? See an example at Phnom Penh#Highways. It doesn't do exactly what you want, as it displays the units, but it works perfectly for tables. Nothing currently exists for exactly what you're wanting, but this may be an acceptable alternative. — Huntster (t @ c) 13:02, 8 March 2010 (UTC)
  • Consider inserting a nearby comment "<!--NOTE: update kW in both places-->" (or similar). Often, the best solution is not a single-entry format, but instead, the values should be repeated but with a warning to update both (or "all 4") values. This is a very common issue called the "dual-update problem" in information science and has led to the typical solution to use comments to the next person editing the data (assuming hand-edited). Many times, the complexity of computerizing a single-entry solution, which propagates the repeated values, could be far more confusing, to the next editor, than just warn them to update both duplicate entries. A second very-important tactic is to repeat the warning later, as with comment "<!--NOTE: above, update kW for both display & conversion-->" (or similar). Repeating information is key to communication: contrary to the newsreporter "myth" to tell people details only one time, it is far better to repeat major details with an altered flair, to emphasize facts but not bore readers. Repeat: tell 'em, then tell 'em what you told 'em, as both top & bottom warnings. -Wikid77 (talk) 15:51, 8 March 2010 (UTC)
Thanks for the suggestions but neither really work. The combined values (43/58) need to go in a single cell that isn't the first on the row, both of which conflict with disp=table. I also considered double entry (aka dual update problem) but experience from 20+ years of professional programming has taught me that the two inputs will eventually disagree no matter how many warning comments are added. People are lazy and update the first value that they find and understand. If they are looking to change 43 kW to 45 kW then they will do that and totally ignore the seemingly unrelated 58 hp and the seemingly unrelated comment right next to it. Their thoughts are on the kW value, so the comment is not even read because the task is to change the 43, not to change other values or to read comments. It sucks but that's what people do - even programmers. My job is to create something that not only works but that is also robust. Double entry is too fragile to be considered unless there is no other choice. I could create a wrapper template that takes a single value, displays it, then calls convert but I'm loathe to create special purpose templates for such a specific and isolated use. I could do the double entry like in my example above but that has the problems I've just outlined. Or I could just leave the table as it is since it ain't actually broke. Or, if the other editors agree, I could wade in the deep end and add something like 'disp=values only'. Not sure how much work that would be. Thanks anyway.  Stepho  (talk) 01:58, 9 March 2010 (UTC)
Yeah, I think for your situation just leaving it as-is will probably be the easiest solution. The "values only" idea could be implemented, but I don't know how long that might take to bring about. — Huntster (t @ c) 02:39, 9 March 2010 (UTC)
  • Okay, I've implemented "abbr=values" to allow slash by disp=s:
{{convert|43|kW|bhp|abbr=values|disp=s}} → 43 (58)*
It's a sad state when people can't read comments explaining dual updates, and I'm not sure how often that would happen. However, having new subtemplates for "values-only" is easy, but not as "disp=" but rather as "abbr=values" because the slash ("/") comes from required disp=s. The simplicity of abbr=values comes from having omitted the unit names, which are responsible for all the typical complexity of lk=on (links), abbr=on (symbols), and adj=on (name hyphens). Hence, allowing abbr=values for kW (or similar, not temperatures) requires only:
Just those few subtemplates are needed, rather than the typical "150" subtemplates required for all options when unit names are shown. -Wikid77 12:03, 9 March 2010
Excellent! I tried it with |abbr=values|disp=s and it works exactly as advertised. Looking back at the actual article, I decided that parenthesise would be better and found they worked perfectly too. I'm very happy and very impressed at the speed at which you figured out the solution and implemented it. Thank you very much.  Stepho  (talk) 13:23, 9 March 2010 (UTC)
Indeed, very nice work Wikid. — Huntster (t @ c) 16:28, 13 March 2010 (UTC)

The missing 74,000 subtemplates

26-Feb-2010: Currently, the widespread use and proliferation of Convert subtemplates has become a "runaway train" of growing complexity. Initially, I had thought that Convert could be improved by creating perhaps 200 more subtemplates, then 300, then 500, then 800 more, etc. However, I eventually calculated the simple figure as 77,800 subtemplates are needed to handle every option (such as "disp=output only" for all measurements). Hence, consider the long-term solution as explained in the essay:

There is a major risk of extreme psychological burnout when facing the reality of needing thousands more of the total 74,000 missing subtemplates to get Convert "fixed" in the manner which many people would expect. I recommend: Do not become demoralized by all the problems, but try to sort out which issues need to be fixed before the others. The wounded Goliath seems be getting gangrene by endless infections in its appendages, and the best course of action, long-term, might be complete amputations (of those subtemplates). -Wikid77 (talk) 19:07, 26 February 2010 (UTC)

Just as Jimp took the previous Convert system and revamped it to make it better than it was, if you think you can do the same, by all means do so. Figure out a way to seamlessly transfer over to a new system, then work on it in your userspace. Remember, up to 100 subpages can be moved at a single time, so eventually moving everything to the Template space won't be that big of a deal. — Huntster (t @ c) 19:14, 26 February 2010 (UTC)
  • Yes, but I would still like a hybrid approach, with some old and some improved, in perhaps 15 stages. I estimate that Jimp has done the work of 9 professional software programmers (or even more since he hasn't quit WP yet!), so I am scared of trying to "rework everything" as one massive improvement. Because: we are ethically bound to test all changes before release to the editors and readers, so the 15 stages would reduce the overall workload and dangers. -Wikid77 (talk) 17:05, 2 March 2010 (UTC)
    • I'm semi-retired, but it is challenges like this that may get me re-invigorated. If you come up with a plan of attack and need a pair of hands, please let me know on my talk page. (I don't check my watchlist often, but the orange banner will get my attention)- Trevor MacInnis contribs 01:21, 15 March 2010 (UTC)

Possible template-nesting limit

09-March-2010: There appears to be a limit to nesting templates and if-expressions which use Convert, because of the "19-nested subtemplates" issue. Articles using Template:Infobox mountain were getting parser-errors for elevation={{convert|97|m|ft}} but NOT when adding precision "|0" which uses 3 fewer subtemplates to determine the precision rounding (using Ordomag, Ordomag/x, etc.). I fixed that parser-error problem by simplifying a 3-nested if-expression, inside the triple-nested infobox Template:Infobox mountain/main. That 3-nested if had been:

| data2 = {{#if:{{{elevation_ft|}}} | {{convert|{{formatnum:{{{elevation_ft|}}}|R}}|ft|m|0|abbr=on}} | {{#if:{{{elevation_m|}}} | {{convert|{{formatnum:{{{elevation_m|}}}|R}}|m|ft|0|abbr=on}} | {{#if:{{{elevation|}}} | {{{elevation|}}} }} }} }}<!-- -->{{#if:{{{elevation_ref|}}} |  {{{elevation_ref}}} }}

Which had the nesting logic as:

if elevation_ft passed then convert(elevation_ft)
else if elevation_m passed then convert(elevation_m)
else if elevation passed then show elevation.   <--error here
if elevation_ref passed then show x2005 elevation_ref.

Instead, the "fixed" logic moved "elevation" outside the nested-if:

if elevation_ft passed then convert(elevation_ft)
else if elevation_m passed then convert(elevation_m).
if elevation passed then show elevation.   <--this now works
if elevation_ref passed then show x2005 elevation_ref.

With that change, then typical Convert worked as {{convert|97|m|ft}}. Also, tests would work when bypassing the top-nested infobox, and instead calling the inner {{Infobox mountain/main}} as one less level of template-nesting. However, we shouldn't request users to stop using nested infoboxes, so the quick fix is to avoid using Convert in 3-nested-if expressions inside nested infoboxes. Long term, we need to see if we could combine some of the "19-nested subtemplates" which Convert uses to compute {{convert|97|m|ft}}. -Wikid77 13:28, 9 March 2010

  • When the limit is exceeded, then nested if-expressions might still work, but perhaps the parameters passed into a template will lose their default values. -Wikid77 09:04, 19 March 2010 (UTC)

Range of temperature conversion

Geography of Austria#Climate ...raising temperatures up to 10°C... How does one convert this to °F? The answer to this is probably buried in the archives of this talk page, problem is to find that. I will be monitoring this page for the answer. Peter Horn User talk 14:26, 21 March 2010 (UTC)

Eureka! By search of the archives: 10 °C (18 °F) Peter Horn User talk 14:34, 21 March 2010 (UTC)

A new conversion?

Geography of Belarus#Environmental concerns Does there exist a template for 1 Ci/km² (37 GBq/km²)? Peter Horn User talk 22:39, 21 March 2010 (UTC) Peter Horn User talk 22:41, 21 March 2010 (UTC)

How often does it occur with that denominator? Is it enough to warrant having a conversion?
There is (I don't know if it is documented) 123 curies (4,600 GBq), which of course will give you the same results as long as you use the same denominator for both. A complex workaround would be
123 Ci/km² ({{convert|123|Ci}}/km²|disp=output only) → 123 Ci/km² (4,600 GBq/km²)
Or 123 Ci/km² ({{convert|123|Ci|TBq|disp=output only}}/km² → 123 Ci/km² (4.6 TBq/km²)
Or even 123 curies per square kilometer ({{convert|123|Ci|TBq|disp=output only|abbr=none|lk=on}}/km² → 123 curies per square kilometer (4.6 terabecquerels per square kilometer)
Of course, one of the conversions automatically choose the prefixes of the output for you based on the size of the number resulting from the conversion. Like any others, you need to tweak the parameters if the units of the default result don't quite fit what you'd like.
But if we have that, somebody's going to want becquerels per square mile or per acre, too.
I doubt that the square kilometers denominator would be encountered often enough to warrant an addition to convert. There are a whole lot of other measurements quite commonly used on Wikipedia which don't have conversions, such as 2.1×1032 ergs per second (1.3×1033 μJ/min). Gene Nygaard (talk) 01:08, 22 March 2010 (UTC)

Setting default conversions by number sense

21-March-10: I have been thinking about speed, again, as related to "number sense" for cultural norms about mph. In a car traveling 64.9 mph in a 60-mph speed zone, it doesn't work to tell the police officer, "I wasn't speeding, but rather going only 60 mph to 1 significant digit". That is an example of "number sense" in tying measurements into cultural norms, such as typically treating 60 mph as between 59-61 mph. The Convert template is no longer limited to pure algebraic conversions, and instead, a conversion can use conditional logic, not just a math formula. Today, conversions can include dates, horse years, and wrenches (spanners):

Similarly, the use of "mph" could be defaulted to include speeds of automobiles, to the nearest 1 mph, where 70 mph would no longer be considered an estimate between 65-75 mph, but rather 69-71 mph.

  • {convert|70|mph|km/h}   → 70 miles per hour (110 km/h) → 70 miles per hour (113 km/h)

Hence, the default precision of each measurement would vary according to typical cultural norms, but always be exactly controlled by sigfig=3 or rounding by parameter "|2" (etc.). People writing articles would just use the typical numbers, as defaulted, and get the typical conversions, depending on the cultural norm. -Wikid77 02:25, 21 March 2010 (UTC)

No. It's simply that the 0 in a 60 mile per hour speed limit is a significant digit. Period. Or more than that, really. To be more precise, it is a definition, like the foot being defined so there are 3 feet in a yard. That is an exact number, not a measured quantity; it has as many significant digits as you want. It isn't anything we should be trying to deal with by fiddling with the default rounding. We have two ways we can deal with the rounding in cases such as that where the trailing zeros are significant. Gene Nygaard (talk) 03:38, 21 March 2010 (UTC)
  • We can't treat the speed-limit number as exactly 60.000000, in Convert, because it would generate too many digits for "number sense" about speed limits: {convert|60.000000|mph|km/h}   → 60.000000 mph (96.560640 km/h). The main concept about number sense is that the typical precision of numbers depends on cultural norms. In the U.S. there have been jokes like Star Trek's Spock saying, "The time is 12:45 and 23.56734 seconds" as humour about disregarding number sense of the precision when reading clocks for time-of-day. By treating 60 mph as a measurement rounded within 59.5-60.5, then both speed-limit signs and speeds of automobiles will, by default, generate conversions appropriate to the specific number sense. In unusual circumstances, users could emphasize the extreme precision as 70.000000 mph (112.654080 km/h); however, police officers will treat 70mph as a rounded limit applied to rounded speed, perhaps allowing up to 73mph (rounded) before issuing a speeding ticket. For those reasons, the default precision of 70 mph should be considered as rounded within 69.5-70.5, and that is the basis of the proposed change to Template:Convert/mph. -Wikid77 12:07, 23 March 2010 (UTC)
But this template can't tell whether a speed is a speed limit or being used in some other sense. For example, if we say "the accident occurred at 60 mph", that is probably only to ±5 mph. The template can't second-guess the meaning and ought to behave consistently across all measurements. Users override the default behaviour if that isn't what they want. Changing the established default behaviour will introduce hundreds of unintended conversions into existing articles. -- Dr Greg  talk  20:29, 23 March 2010 (UTC)
I agree with Greg and Gene, for numbers below 1000 the template can't know the context, so rounding/precision should default to units (ie |0 ). If the user wants something different then the user should select rounding/precision explicitly.  Stepho  (talk) 22:40, 23 March 2010 (UTC)
No, it shouldn't default to rounding at the decimal point—not even if you clarify a greater than one as well as less than 1000. It works much better than that as it is now (which includes some rounding to the left of the decimal point and some rounding to the right of the decimal point, even for numbers in that range that don't have any fractional parts expressed.
Wikid77 still doesn't get it. His idiosyncratic notions of a "number sense" have no place here. It isn't quantifiable, and unpredictable rounding that depends on which units are being used makes no sense. Furthermore, most of our measurements using kilometers per hour or miles per hour not only don't have anything to do with speed limits on our roads. We get a lot of acceleration times for fixed speed ranges 0 to 60 mi/h or 100 km/h, and some automobile races with very precise (often more precise than really warranted) average speeds. But most of these speeds don't even have anything to do with cars; we're more likely to see them in articles dealing with aviation and with shipping and with wind speeds, often with knots as well. And cheetahs and the like don't have speed limits.
Stick with consistent rules. Even the extra digit added for single-significant-digit conversions is acceptable; especially when you factor in the desire for consistency—it has been here a while and is known by some of the editors using the template. Nonetheless, at least half of the conversions of 1 mile should be to 2 km rather than 1.6, most of the conversions of 2 miles should be to 3 km rather than 3.2, and 90% or more all of the conversions of 3 miles should be to 5 km rather than 4.8 km.
But in general, as someone who has tinkered with the precision of the numbers in thousands of Wikipedia articles, I can say with confidence that we have far more problems with conversions giving excess precision than with those not giving enough precision. Probably about a 10:1 ratio, I'd guess. That may be a bigger problem with conversions not using this template, but with this template it is still very common, especially in most of the measurements qualified as "approximately" or "roughly" or "about" and the like. Gene Nygaard (talk) 14:57, 24 March 2010 (UTC)

Technical atmosphere

I'd like to see the technical atmosphere, 1 at = 1 kgf/cm2 added. (I came along it because the FIFA used it to give the pressure of a football.) Or did i just miss the at?--ospalh (talk) 12:48, 29 March 2010 (UTC)

That's the symbol for a metric attoton—certainly a more reasonable concern than the ones used to preclude the normal symbol for knots here.
It isn't going to be used often enough to warrant an addition here. It isn't in common enough usage to warrant use in an article without further explanation or linking, including spelling out at first use, in any case. But if you run across it, use it with 0.6 to 1.1 kilograms-force per square centimeter (59 to 108 kPa; 8.5 to 15.6 psi). If for some strange reason you think it would be appropriate to suppress kgf/cm2 and still use technical atmosphere, you could use "0.6 to 1.1 technical atmospheres (59 to 108 kPa; 8.5 to 15.6 psi)". Gene Nygaard (talk) 16:06, 31 March 2010 (UTC)

If you add 3lb it drops by 1 kg

Look at the billed weight and the weight entries at Jake Hager. They are using {{convert|260|lb|kg|abbr=on}} 260 lb (120 kg) and {{convert|263|lb|kg|abbr=on}} 263 lb (119 kg). something lame from CBW 14:15, 31 March 2010 (UTC)

There's nothing "lame" about it. The problem lies with the editor using the template. If you want the 0 in 260 to be significant, you need to tell it so. Use either
  • {{convert|260|lb|kg|sigfig=3|abbr=on}} → 260 lb (118 kg)
  • {{convert|260|lb|kg|0|abbr=on}} → 260 lb (118 kg)
Then adding 3 lb adds 1 kg. Gene Nygaard (talk) 14:55, 31 March 2010 (UTC)
Thanks. I never said it was lame. I was at the end of my shift at work and came across it by accident and didn't have time to look at it further. Plus I was tired or I might have thought about that. Thanks. something lame from CBW 22:41, 31 March 2010 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_March_2010&oldid=1147424731"