Template talk:Convert/Archive March 2012

This is an archive of past discussions about Template:Convert. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Download as PDF fault?

Unresolved

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 {{convert|114|lb|kg}} 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#Bug: convert template error message. -- 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 adj=on and abbr=on are specified:

{{convert|3/8|in|cm}}
{{convert|3/8|in|cm|adj=on}}
{{convert|3/8|in|cm|abbr=on}}
{{convert|3/8|in|cm|abbr=on|adj=on}}
{{convert|3/8|in|cm|2}}
{{convert|3/8|in|cm|2|adj=on}}
{{convert|3/8|in|cm|2|abbr=on}}
{{convert|3/8|in|cm|2|abbr=on|adj=on}}

Gives: 3⁄8 inch (0.95 cm)
3⁄8-inch (0.95 cm)
3⁄8 in (0.95 cm)
3⁄8 in (0.95 cm)
3⁄8 inch (0.95 cm)
3⁄8-inch (0.95 cm)
3⁄8 in (0.95 cm)
3⁄8 in (0.95 cm)

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 {{convert}} seems longer and puts in more space than that used by {{frac}}. Personally I prefer the output of {{frac}}. 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:

{{convert|2+3/8|in|cm|adj=on}} → 2+3⁄8-inch (6.0 cm)
{{convert|2+3/8|in|cm|adj=on|abbr=on}} → 2+3⁄8 in (6.0 cm)
{{convert|2+3/8|in|cm|adj=on/sandbox|abbr=on}} → 2+3⁄8 in (6.0 cm)^*

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: {{convert|2+3/8|acre|adj=on|abbr=on}} → 2+3⁄8-acre (0.96 ha)

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 Nas (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 {{frac}}. However, changes to {{frac}} can leave {{convert}} lagging behind. The slash used by {{frac}} was changed in December; we're 21⁄2 months (6.6 Ms) behind. JIMp_talk·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 {{convert}} puts in </big>/</big> around the large oblique whereas {{frac}} does not. Personally I prefer the more condensed style that {{frac}} 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:

{{convert|3/8|mi|km}}

{{convert|3/8|mi|km|adj=on}}

{{convert|3/8|mi|km|abbr=on}}

{{convert|3/8|mi|km|abbr=on|adj=on}}

{{convert|3/8|mi|km|2}}

{{convert|3/8|mi|km|2|adj=on}}

{{convert|3/8|mi|km|2|abbr=on}}

{{convert|3/8|mi|km|2|abbr=on|adj=on}}

Gives:

3⁄8 mile (0.60 km)

3⁄8-mile (0.60 km)

3⁄8 mi (0.60 km)

3⁄8 mile (0.60 km)

3⁄8-mile (0.60 km)

3⁄8 mi (0.60 km)

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:

{{convert|2+3/8|in|cm|adj=on|abbr=on}} → 2+3⁄8 in (6.0 cm)
{{convert|1+1/4|m2|sqft|adj=on|abbr=on}} → 1+1⁄4 m² (13 sq ft)
{{convert|9+5/32|acre|ha|adj=on|abbr=on}} → 9+5⁄32-acre (3.71 ha)
{{convert|1+1/4|-|2+5/8|m3|cuft|adj=on|abbr=on}} → 1+1⁄4–2+5⁄8 m³ (44–93 cu ft)
{{convert|50+9/16|°C|F|adj=on|abbr=on}} → 50+9⁄16 °C (123.0 °F)
{{convert|50+9/16|C|F}} → 50+9⁄16 °C (123.0 °F)
{{convert|50.5625|C|F}} → 50.5625 °C (123.0125 °F) = 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 {{frac}}. 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 doc= 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#Fractions and it says to use {{frac}}, 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 {{xt|5 <sup>1</sup>/<sub>4</sub> mm}}. 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 <math> 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 {{convert}}}, definitely self-contradictory. Si Trew (talk) 23:10, 4 March 2012 (UTC)

Format error

North American river otter#Social structure. 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 the template to recognise mile 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 mile 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. JIMp_talk·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:

{{convert|45|km|mile}} → 45 kilometres (28 miles)

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 {{convert|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

{{Convert|15.5|kgm|Nm ftlbf|0|abbr=on}} this could/should be changed to {{Convert|15.5|kgm|Nm lbft|0|abbr=on}} or make it possible to ouput lbft -->Typ932 ^T·C 07:53, 11 March 2012 (UTC)

Here are those 2 separate units, currently:

· {{convert|9|ftlbf}} → 9 foot-pounds force (12 J)

· {{convert|9|lbft}} → 9 pound-feet (12 N⋅m)

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·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).

{{Convert}} has a bit of catching up to do. I'll make the suggested change and delete Nm lbft and N.m lbft 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. JIMp_talk·cont 00:46, 12 March 2012 (UTC)

Done. Nm ftlbf (and its variants) are gone, moved to Nm lbft. Though there had been Nm lb.ft which did the same but I got rid of it in favour of Nm lbft (it never made sense to have a dot between the lb and ft but not between the N and m). 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 ftlbf and ftlb to m.N ("metre-newtons" a dumby code redirecting to N.m). 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. JIMp_talk·cont 05:08, 12 March 2012 (UTC)

thanks, I ll try check those when and if I have time... -->Typ932 ^T·C 14:20, 14 March 2012 (UTC)

Strange addition

Hello,

On "Cars Land", this template is used:

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. JIMp_talk·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 (522,720 to be precise) which begs the question why use {{Infobox Disney ride}} for a Disney land. Well, there is no Disney land infobox ... JIMp_talk·cont 14:03, 16 March 2012 (UTC)

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

{{Infobox Disney ride}} has been replaced with {{Infobox Disney attraction}}. The new template does not assume that area is always input as a number of square feet. JIMp_talk·cont 00:36, 19 March 2012 (UTC)

Winecase conversion multiplies by a factor 10 when using more than one unit

I noticed that {{convert|1|winecase|hl}} gives correctly "1 case (0.090 hl)" (there are 12 bottles in a case). However {{convert|1|winecase|hl USgal}} 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 {{convert|1|l|hl}} "1 litre (0.010 hl)" vs. {{convert|1|l|hl USgal}} "1 litre (0.010 hl; 0.26 US gal)". 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. JIMp_talk·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, {{convert|1|sm|ftin|abbr=off}} = 1 smoot (5 feet 7 inches), 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 feet (84 m) and 275 ft (84 m) and 275 feet (84 metres). 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 feet (84 m)^*. 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 "<such and such road> 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 {{convert|11|mi|km|adj=mid|-long highway|abbr=out}} which gives "<such and such road> is an 11-mile-long highway (18 km)". Note the output units must be specified or the template breaks ({{convert|11|mi|adj=mid|-long highway|abbr=out}} → 11-mile (^{[convert: unknown unit]})) Thryduulf (talk) 14:04, 31 March 2012 (UTC)