Template talk:Convert/Archive March 2012

Download as PDF fault?
There seems to be a problem with spurious text " unknown operator: u'strong' " which appears in the middle of the convert output when using the Download as PDF facility on an article. Oosoom Talk 22:12, 24 February 2012 (UTC)

eg: It weighs 114 lb today. gives: It weighs 114 pounds (unknown operator: u'strong' kg) today. Oosoom Talk 20:09, 25 February 2012 (UTC)
 * Also reported at Help:Books/Feedback. -- John of Reading (talk) 08:07, 11 March 2012 (UTC)

Fractions when adj=on, abbr=on do not display as fractions
There seems to be an odd case where fractions are not converted to fractional form when  and   are specified:

Gives: 3/8 in 3/8 in 3/8 in 3/8 in 3/8 in 3/8 in 3/8 in 3/8 in

That is, rather than displaying $3/8$, the text "3/8" is displayed instead. Of course 3/8 is just an example, any values will do.

Si Trew (talk) 08:46, 26 February 2012 (UTC)


 * I note also that the fraction line used by seems longer and puts in more space than that used by . Personally I prefer the output of . Si Trew (talk) 08:53, 26 February 2012 (UTC)


 * Proposed fix to allow mixed fractions: I have edited the sandbox version, Template:Convert/LoffAonDbSon/sandbox, to properly handle fractions. That case, for abbr=on and adj=on, is one of hundreds of cases which had not been updated to handle the latest options of Convert. In fact, the calculation has been wrong for mixed numbers with fractions when abbr=on and adj=on:
 * {&#123;convert|2+3/8|in|cm|adj=on}}      &rarr; 2+3/8 in
 * {&#123;convert|2+3/8|in|cm|adj=on|abbr=on}} &rarr; 2+3/8 in
 * {&#123;convert|2+3/8|in|cm|adj=on/sandbox|abbr=on}} &rarr; 2+3/8 in
 * The sandbox version shows the correct result "6.0 cm" (rather than "201 cm"). In actual use, the option "adj=on" is rare because unit symbols such as "cm" do not show the hyphen "-" as adjectives, and hence, the option "abbr=on" is equivalent to "abbr=on|adj=on" for cm. The need for this rare case would be in non-abbreviated units (such as "acre") which could use the combined option "abbr=on|adj=on" because the adjective form for acre always shows hyphen "-acre". Example:
 * Acres: {&#123;convert|2+3/8|acre|adj=on|abbr=on}} &rarr; 2+3/8 acre
 * The long-term plan was to allow non-abbreviated units, such as "acre" to reuse all the same subtemplates as "cm" and allow deleting hundreds of similar subtemplates named with suffix "Na" as in "Convert/L...Na". This proposed fix to Template:Convert/LoffAonDbSon, to correctly calculate a mixed-number fraction, would also be needed to properly display "-acre" if the Na subtemplates are removed. -Wikid77 (talk) 22:42, 26 February 2012 (UTC)
 * I've moved Wikid's sandbox onto the live subtemplate so it's now working. Removing the s (along with a whole lot of other excess) still is the long term plan.  As for the slash, the idea has always been to give the same output as .  However, changes to  can leave  lagging behind.  The slash used by  was changed in December; we're 2+1/2 month behind. J IM ptalk·cont 00:08, 27 February 2012 (UTC)


 * Thanks Wikid77, Jimp. Of course the example now above is invalid because I used the template itself which you fixed. I never know whether to do that or hard code it. With the long oblique in the fraction, I looked at the HTML output for the examples I gave above on this talk page itself and it seems that  puts in   around the large oblique whereas  does not. Personally I prefer the more condensed style that  now uses but I am on a relatively large screen  (1600x1024 pixels I think) and perhaps the larger oblique c omes out better on small devices e.g. mobile   phones? I guess WP:MATH and WP:MOS will have something to say on how it should be, but would not at all surprise me if they are contradictory: I shall try and hunt it down. Thanks again for the fix on that edge case. Si Trew (talk) 16:11, 4 March 2012 (UTC)

Regression testing for fractions
For the purposes of regression test, I am giving the same example but with miles to kilometres instead. To try to show whether or not it is specifically for centimetres  (as fixed) or is more general:




 * Gives:
 * 3/8 mi
 * 3/8 mi
 * 3/8 mi
 * 3/8 mi
 * 3/8 mi
 * 3/8 mi
 * 3/8 mi
 * 3/8 mi

Of course I could multiply examples ad nauseam. I am just interested, Wikd77 if you are convinced, as it seems to come across, that it was a specific fault of the centimetre conversion or a more fundamental fault.

I disagree with you they are not used together in practice. I use them a lot together, as part of my gnoming, to get the correct adjectival form and still retain the abbreviation.

It seems to work correctly for miles to kilometres, as written. As I say, this is more in the nature of a regression test, and ideally should be in the template's testcases. However for the combinatorial explosion of units by dimensions by taking off the number you first thought of, I do understand it is hard to get a set of testcases that add any real value, and the approach of treating bugs case by case as you have is probably wiser. Si Trew (talk) 16:27, 4 March 2012 (UTC)
 * Fix was for fundamental flaw of typical-unit fractions with abbr=on & adj=on: The problem was in the fundamental handling of the rare combination of options abbr=on and adj=on (for all typical unit codes: cm, km, ft, lb, kg, km2, sqmi, m3). The regression testing has been handled by special test-case page, but again, combining of adj=on with abbr=on has been very rare because "abbr=on" displays the same with "adj=on" or not. Compare a wider variety of conversions:
 * {&#123;convert|2+3/8|in|cm|adj=on|abbr=on}} &rarr; 2+3/8 in
 * {&#123;convert|1+1/4|m2|sqft|adj=on|abbr=on}} &rarr; 1+1/4 m2
 * {&#123;convert|9+5/32|acre|ha|adj=on|abbr=on}} &rarr; 9+5/32 acre
 * {&#123;convert|1+1/4|-|2+5/8|m3|cuft|adj=on|abbr=on}} &rarr; 1+1/4 - 2+5/8 m3
 * {&#123;convert|50+9/16|°C|F|adj=on|abbr=on}} &rarr; 50+9/16 °C
 * {&#123;convert|50+9/16|C|F}} &rarr; 50+9/16 C
 * {&#123;convert|50.5625|C|F}} &rarr; 50.5625 C = 50+9/16
 * Hence, a wider variety shows problems with temperatures, but those options are very rare and not used in articles. -Wikid77 (talk) 16:01, 9 March 2012 (UTC)


 * I am still a bit confused about the 14 December change to . I can't see that it took out the large oblique at that time (e.g. with this change or this change on that date. As far as I can see from the discussion page, and from the changes, it is more to do with non-breaking spaces and how things can be copied and pasted (the  named parameter I think, which is mentioned on the template talk page  but not on the documentation at Template:Frac/doc,  so I was not aware of it before now). I still don't see any consensus or discussion of  changing the large oblique to small oblique. I wonder if it would be a good idea to tie this topic  to the talk at Frac i.e. cross ref them ? User:Arthur Rubin might have a good view since he seems to have been involved in the discussion and of course is an old regular here, but I don't want to "canvass" him before getting others' views from here. Not that I would WP:CANVASS of course but I would not like it to seem that I was. Si Trew (talk) 16:42, 4 March 2012 (UTC)


 * I looked up MOS:NUMBER and it says to use, and gives an example which itself uses frac, so ipso facto will produce the "right" result, i.e. it is specification by definition, and frac of course uses the smaller (standard sized) oblique. In the next sentence it has an example to my eye as a large oblique and the Wikimedia code behind is . So as I imagined, prima facie, the MOS is itself inconsistent in whether to use smaller or larger oblique. Th e same section goes on to say usage in science and mathematical articles should always be written using a horizontal fraction bar: this makes  no sense to me. There is   to do that, and I think that is outside the remit of this section (MOS:MATH covers that). While I feel that  what a "mathematical article" is, is fairly common sense, what a "science article" is, is not, For example would loading gauge  be thought of as a science article? It has numerous conversions and technicalities. I would say it is an engineering article and a science article. The whole section seems inconsistent and ill thought through, but anyway for the purposes of }, definitely self-contradictory. Si Trew (talk) 23:10, 4 March 2012 (UTC)

Format error
North American river otter. Can someone tell me why the convert template is broken there? I don't see anything wrong in the formatting. Ten Pound Hammer • (What did I screw up now?) 21:50, 7 February 2012 (UTC)


 * Changing |mile| to |mi| made it work but we should probably fix the template to recognise |mile|  Stepho  talk 08:57, 8 February 2012 (UTC)


 * Changing the template to recognise  is not so hard (even the unlogged-in can do it), just make Template:Convert/mile redirect to Template:Convert/mi.  The question is should we?  If   becomes an option, might users not expect that spelling units out in general should work?  Might editors not start spelling everything out and not check whether this or that particular unit actually does work?  Why not just allow everything to be spelt out?  Who's up for creating umpteen hundred redirects?  Not I. J IM ptalk·cont 00:27, 27 February 2012 (UTC)


 * Created Convert/mile to remind user of "mi": As Jimp noted, supporting more full words will likely give the false impression that all full words are supported as unit-codes (when they are not). Hence, I have created Template:Convert/mile to show a dark-orange message to remind the editor to use unit-code "mi" instead. For example:
 * {&#123;convert|45|km|mile}} &rarr; 45 km
 * Already, the support for the plural full name unit-code "miles" has led to Template:Convert/miles being used over 350 times, and those 350 pages could be misleading to many users who might expect full-word codes for all units. Instead, by showing orange reminders for the most-common full-word names, we can avoid misleading more users to expect that all full-words are allowed and emphasize reading of Template:Convert/list_of_units. -Wikid77 (talk) 15:03, 11 March 2012 (UTC)

Request for "temperature difference"
When you want to say that X ˚C equals Y ˚F Convert is perfect, but if you want to say that the temperature increased by X˚ from 1990 to 2010, all of a sudden the template doesn't work. This is evidenced by this diff from an article that repeatedly gets changed because people don't realize this problem: Permafrost diff — JmaJeremy  talk contribs  16:27, 8 March 2012 (UTC)
 * Use X C-change or F-change for farenheit. SkepticalRaptor (talk) 17:08, 8 March 2012 (UTC)
 * Thanks, SkepticalRaptor! I overlooked this feature before. — JmaJeremy  talk contribs  19:42, 8 March 2012 (UTC)
 * Amusingly, I missed it a few years ago, and some nice editor showed me what I did wrong. My turn to pay it forward! SkepticalRaptor (talk) 21:28, 8 March 2012 (UTC)
 * Hm, only a brief mention of this feature in Template:Convert/list_of_units with no actual description of what it does. Perhaps this should be added to the documentation. — JmaJeremy  talk contribs  21:45, 8 March 2012 (UTC)


 * I've added some notes in to the table, with these changes. Si Trew (talk) 11:49, 13 March 2012 (UTC)

torque
15.5 kgm this could/should be changed to 15.5 kgm or make it possible to ouput lbft -- >Typ932 T&middot;C 07:53, 11 March 2012 (UTC)
 * Here are those 2 separate units, currently:
 * &middot; {&#123;convert|9|ftlbf}} &rarr; 9 ftlbf
 * &middot; {&#123;convert|9|lbft}} &rarr; 9 lbft
 * I suppose various users prefer one unit name or the other. -Wikid77 (talk) 15:10, 11 March 2012 (UTC)
 * The lbft unit is agreed to be used eg. WP:CARS WP:WPAC, this is only template that outputs ftlbf  -- >Typ932 T&middot;C 16:15, 11 March 2012 (UTC)

This was discussed at length in December. It was concluded that force-length units would be torque and length-force units would be energy. The following was added to MOSNUM. "When units of torque or energy are formed by multiplication of a unit of force with a unit of length, distinguish these by putting the force unit first for torque (e.g., newton-metres or pound-feet) and the length unit first for energy (e.g., foot-pounds or foot-pounds force)." has a bit of catching up to do. I'll make the suggested change and delete  and   once the calls to them have been fixed in articles. If there are users who prefer foot-pounds for torque, they're always welcome to challenge the guidance at WT:MOSNUM. J IM ptalk·cont 00:46, 12 March 2012 (UTC)

Done. (and its variants) are gone, moved to. Though there had been  which did the same but I got rid of it in favour of   (it never made sense to have a dot between the   and   but not between the   and  ). Well, that's the easy part ... now we've still got pages converting foot-pounds to newton-metres. I've found some of them by changing the default output of  and   to   ("metre-newtons" a dumby code redirecting to  ). I've fixed up about a dozen of these but there are still about two or three score left and this list could get longer ("What links here" sometmes lags). Of course, this only catches the foot-pounds using the default conversion. There may be others explicitely converting to torque units. J IM ptalk·cont 05:08, 12 March 2012 (UTC)
 * thanks, I ll try check those when and if I have time... -- >Typ932 T&middot;C 14:20, 14 March 2012 (UTC)

Strange addition
Hello,

On "Cars Land", this template is used:

12 acre

But it gives the result "12 acres (4.9 ha) sq ft". Is there a way to keep it from accidentally printing "sq ft"? --98.112.156.6 (talk) 05:21, 16 March 2012 (UTC)


 * There is a way. J IM ptalk·cont 13:35, 16 March 2012 (UTC)


 * The problem is with the infobox. It's assuming you're inputting square feet. Of course, twelve acres are a lot of square feet (12 acre to be precise) which begs the question why use for a Disney land.  Well, there is no Disney land infobox ... J IM ptalk·cont 14:03, 16 March 2012 (UTC)


 * Fixed, no, not very elegant but it'll do for now. J IM ptalk·cont 14:09, 16 March 2012 (UTC)


 * has been replaced with . The new template does not assume that area is always input as a number of square feet. J IM ptalk·cont 00:36, 19 March 2012 (UTC)

Winecase conversion multiplies by a factor 10 when using more than one unit
I noticed that 1 winecase gives correctly "1 case (0.090 hl)" (there are 12 bottles in a case). However 1 winecase produces "1 case (0.90 hl; 2.4 US gal)". Furthermore, I could not find winecase in the list of units. Any idea?
 * The problem is in possibly in Template:Convert/hl USgal? Check 1 l "1 l" vs. 1 l "1 l". I will see if I can track it down. Frietjes (talk) 16:25, 18 March 2012 (UTC)
 * I found the bug and requested a fix in Template talk:Convert/hl USgal. thank you. Frietjes (talk) 16:44, 18 March 2012 (UTC)
 * Fixed. J IM ptalk·cont 16:59, 18 March 2012 (UTC)
 * Thanks, great job. — Preceding unsigned comment added by Toniok (talk • contribs) 20:07, 18 March 2012 (UTC)

Length unit request
Length unit "smoots". I want to be able to convert between meters/feet/smoots, where 1 smoot = 67in/1.70180 m/5.58333 ft. I don't know how to modify the template, and figure I probably should leave it to people more familiar with the syntax. - Denimadept (talk) 23:27, 23 March 2012 (UTC)
 * Hm, I looked it all over, copied the convert/ft template and created a convert/smoot one, using 1.70180m as the basis, and "sm" as the unit designator... but it's not working. More research needed. - 23:37, 23 March 2012 (UTC)
 * I fixed it for you, 1 sm = 1 sm, you need to "view source" before cutting and pasting, which caused you to miss some parameters. Frietjes (talk) 17:05, 25 March 2012 (UTC)

Non breaking spaces
Is convert no longer placing a non-breaking space between the value and the unit in measurements? Such a thing is required by MOS:NUM, so if this template isn't going to do that anymore, that's going to be an issue.  Imzadi 1979  →   08:52, 24 March 2012 (UTC)
 * I believe it typically does, but may not in some cases. can you provide an example?  If I view source on the smoot example above, there are non-breaking spaces. Frietjes (talk) 17:07, 25 March 2012 (UTC)
 * H-58 (Michigan county highway)... I can get the feet-to-meters conversion to break between the number and unit in the sentence "These dunes reach heights of up to 275 feet (84 m) at a 35° incline." I could also get the mileages to break between number and unit when I changed the window width to force some to fall at the end of the line.  Imzadi 1979  →   22:40, 25 March 2012 (UTC)
 * it appears the difference is between 275 ft and 275 ft and 275 ft. if you check the html source for these three, you will see there are variations in the placement of the non-breaking spaces.  there is probably a thread about this in the archives. Frietjes (talk) 15:32, 26 March 2012 (UTC)
 * by the way, you can always use "abbr=mos" which results in 275 ft. Frietjes (talk) 15:34, 26 March 2012 (UTC)
 * This template, though, has been advertised to comply with the MOS by default. I noticed that you changed the one conversion with feet, but I'm getting the breaking issues on all of the mileages too depending on the width of the window. I think that non-breaking spaces between number and unit should be the default though; we shouldn't have to add an option to turn on something that's required by the MOS  Imzadi 1979  →   17:48, 26 March 2012 (UTC)


 * WP:MOS advises non-breaking space for symbol not name: Users often think WP:MOS directs editors to put non-breaking spaces before all units, but in reality, the wording mentions only the abbreviated "unit symbols" rather than the full "unit names". Note the exact wording in WP:MOS: "Values and unit symbols are separated by a non-breaking space." That rule does not apply to unit names (such as "metres" or "feet"), only to "unit symbols" (such as "m" or "ft"). The option "abbr=mos" is intended to match the latest rewrite of WP:MOS. Remember how WP:MOS is constantly being revised by a few people, and if the rules change, then Convert is not automatically updated to match WP:MOS. Instead, the option "abbr=mos" can be used, with the notion that it would be updated, faster, to match the current text of WP:MOS. Many other options of Convert were written years ago and are not tied to the latest rules given in WP:MOS. Across all of the English Wikipedia, many templates are not kept current with the latest 10,000 suggested rules specified within the 50 major pages of WP:MOS. Fortunately, the parts of WP:MOSNUM about unit-name or unit-symbol formatting have been relatively constant, but the implications of the rest of the 10,000 rules in WP:MOS are difficult to assess for most of the part-time volunteers here. I hope that explains why option "abbr=mos" is used where compliance with WP:MOS is considered crucial, rather than trying to match all the 10,000 MOS rules everywhere they might apply. -Wikid77 (talk) 09:16, 27 March 2012 (UTC)

Format
If I add the template to an article, and it originally said " is an 11-mile-long highway", how do I get the template's result to either say "mile" (not "miles") or the abbreviation "mi"? Allen (talk) 13:19, 31 March 2012 (UTC)
 * Use 11 mi which gives " is an 11 mi". Note the output units must be specified or the template breaks ( 11 mi → 11 mi) Thryduulf (talk) 14:04, 31 March 2012 (UTC)