Template talk:Convert/Archive January to October 2007

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

Moved conversion table

It's now at the Template:Convert/doc subpage.+mwtoews 01:17, 29 January 2007 (UTC)

Suggestions

Nice little template Drum. A few changes I would make would be to have an option to abbreviated both units of measurement for use in tables and infoboxes (see: .30-06) and change some of the customary units' abbreviations to the traditional forms; eg mi²->sq mi. —MJCdetroit 17:59, 1 February 2007 (UTC)

Subst?

Any way to make this subst'able? Using subst on {{convert}} results in a massive amount of stuff. I'd use the template more, but I'm worried about server load etc. Is there a way to add the converted material without copy and paste? --Dual Freq 04:57, 18 February 2007 (UTC)

First of all you wouldn't want to make this substitutable. It is much more clear and obvious that the conversion was correctly performed to leave it as is. Moreover Wikipedia:Don't worry about performance. -- KelleyCook 14:02, 18 February 2007 (UTC)
Thanks for the response. I'll continue to use the template. --Dual Freq 04:21, 22 February 2007 (UTC)

Fathoms

What about a conversion of fathoms to feet and meters? Thanks in advance. --Dual Freq 04:21, 22 February 2007 (UTC)

NBSP Needed, "Square Feet" -> "ft²"

  • The convert template needs to make use of  . I'm trying to use square feet in my document but due to a normal space being used the 'square' and 'feet' frequently appear on different lines.

Use of NBSP is required by the Wikipedia:Manual of Style in the Units of Measurement section.

  • I would really like the option to display "ft²" for original unit instead of "square feet". Currently, when converting from 'sqft' to 'sqm' it shows "RedPoptarts square feet (RedPoptarts m²)" which is awkward because of inconsistency.

-- RedPoptarts 09:24, 24 February 2007 (UTC)

Gotcha.. the idea behind fully spelling out the first unit and abbreviating the one within the parentheses is because it goes along with the Manual of Style. I will, however, add & nbsp ; between words. -- drumguy8800 C T 08:34, 25 February 2007 (UTC)
Just kidding.. adding it in would mean that sometimes pages would link to thins like square foot .. which doesn't exist. I'm not sure how Wikis respond to <nobr>...</nobr> tags but they effectively function the same way. one could add |br=no to the end or something to prevent line breaking. -- drumguy8800 C T 08:38, 25 February 2007 (UTC)

Coding that needs to be done

There needs to be a way to work in whatever tense this is: "The 908-foot tall building".. currently unless the quantity is one, the unit will show up in its plural form. Also, there needs to be an option to abbreviate everything. This sounds like a disgusting lot of coding and if statements. -- drumguy8800 C T 08:38, 25 February 2007 (UTC)

Just to be clear, both of these issues have been resolved: adding |sing=on fixes the grammar/tense issue and adding |abbr=on fixes the abbreviation issue. -- drumguy8800 C T 06:51, 26 March 2007 (UTC)

Something's wrong..

Something's wrong with the display of a conversion where the base is a measurement of speed not equal to one:

mi/h

{{convert|215|mi/h|km/h|0|lk=on}}: 215 miles per hour (346 km/h)

{{convert|1|mi/h|km/h|2|lk=on}}: 1 mile per hour (1.61 km/h)

{{convert|120|mi/h|km/h|0|sing=on|lk=on}}: 120-mile-per-hour (193 km/h)

km/h

{{convert|215|km/h|mi/h|0|lk=on}}: 215 kilometres per hour (134 mph)

{{convert|1|km/h|mi/h|2|lk=on}}: 1 kilometre per hour (0.62 mph)

{{convert|120|km/h|mi/h|0|sing=on|lk=on}}: 120-kilometre-per-hour (75 mph)

ft/s

{{convert|215|ft/s|m/s|0|lk=on}}: 215 feet per second (66 m/s)

{{convert|1|ft/s|m/s|2|lk=on}}: 1 foot per second (0.30 m/s)

{{convert|120|ft/s|m/s|0|sing=on|lk=on}}: 120-foot-per-second (37 m/s)

m/s

{{convert|215|m/s|ft/s|0|lk=on}}: 215 metres per second (705 ft/s)

{{convert|1|m/s|ft/s|2|lk=on}}: 1 metre per second (3.28 ft/s)

{{convert|120|m/s|ft/s|0|sing=on|lk=on}}: 120-metre-per-second (394 ft/s)

You'll notice that the opposite of what's intended happens when you tack on the |sing=on tag.. instead of the unit displaying singularity it displays plurality. When you don't ask it to, it displays plurality instead of singularity. The coding appears to be inline with the other coding around it.. (find mile per hour using your browser's find feature (Ctrl+F) when editing) .. can't seem to figure out exactly where the coding is frayed. Anyone else? -- drumguy8800 C T 08:10, 3 April 2007 (UTC)

I noticed this too, and came to comment, but I see I'm not the first. I'm not expert enough to fix the coding, but on the bright side, we can just use the sing=on workaround for now... PaladinWhite 23:02, 17 May 2007 (UTC)

Wrapping

The wrapping issue has been fixed. Now all conversions are within {{nowrap|blahblahblah}}. -- drumguy8800 C T 00:40, 9 April 2007 (UTC)

:)

Just wanted to say what a fantastic job has been done on this template, I've begun applying it to some articles I'm working on and it makes my life a lot easier, not to mention that of my poor little solar calculator. Orderinchaos 11:51, 11 April 2007 (UTC)

Couple of odd ones

I noticed a couple of oddities seem to be appearing today, the problem appears to arise when lk=on is present:

  • 3.267 square kilometre|square kilometres (807 acre) from {{convert|3.267|sqkm|acre|0|lk=on}}
  • 208 metre (682 foot (unit of length)|ft) from {{convert|208|m|ft|0|lk=on}}

They did work before when I put them in, so probably just a recent change has done something unexpectedly drastic. Orderinchaos 22:21, 14 April 2007 (UTC)

Ah, think I found it. Sorry for bothering you guys :) Orderinchaos 22:23, 14 April 2007 (UTC)

Weight

Why doesn't this support weight? (i.e. pounds) ? --Ysangkok 11:31, 28 April 2007 (UTC)

  • Probably because the creator hasn't gotten around to it yet :). I would like to add my vote to that. Pounds <> kilograms, tons <> tonnes, ounces (avoirdupois) <> grams would all be nice. All in all, this is a very nice template and I'm very happy I found it. Thank you Drumguy. Fanra 11:44, 1 June 2007 (UTC)
  • Oh, yes, liquid would also be nice. U.S. only I think is needed, since the U.K is supposed to be on the metric system now. Fluid Ounce <> milliliter, gallon <> liter, etc. :) Fanra 11:54, 1 June 2007 (UTC)
  • Strangely enough, it seems that the U.S. gallon is technically a measurement of volume. So I would guess that gallon <> cubic meter is also a good idea. Fanra 12:24, 1 June 2007 (UTC)
Yeap, I buy my milk by the U.S. gallon and not by the pound. I would still include conversions for Imperial volumes for a few reasons. Not everyone in the UK, Canada, and elsewhere have abandoned the imperial system. Many people there still prefer the Imperial gallon to the liter. However, more importantly, there are going to be times when a source only provides the information in Imperial volumetric units and those units will need to be converted to U.S. Customary and metric units. Something to think about...—MJCdetroit 14:06, 1 June 2007 (UTC)
Based on your posting at Hanford Site, I now understand what you were getting at. —MJCdetroit 14:21, 1 June 2007 (UTC)
FYI... here in the UK we're rather confused about units. Some fluids are sold in litres (eg. fuel, milk from the supermarket), and some are sold in pints (eg. beer, milk delivered by the milkman) - milk is never in gallons unless you're a farmer. So, please add imperial units as well. Astronaut 13:04, 13 August 2007 (UTC)

Limitation

Is there any limitation of numer of use on one page? I tried use this template widely in list here User:Jklamo/List of the largest arch bridges and from 113th conversion it seems not work. --Jklamo 17:27, 29 May 2007 (UTC)

There are limitations to how many times templates can be transcluded in a single article. Currently it is limited to two megabytes, and the current usage can be located in the HTML source of an article page, like this from your article:
  • Pre-expand include size: 2043884 bytes
  • Post-expand include size: 197929 bytes
  • Template argument size: 80679 bytes
  • Maximum: 2048000 bytes
So as that shows, the pre-expanded include size maxed it out. Perhaps a way can be found to fix the problem by optimizing the code in the template, but I'd suggest a better solution is to not have all-in-one templates, but to sort them by type of measurement. That would allow for significantly more instances on a single page. -- Huntster T • @ • C 19:46, 29 May 2007 (UTC)
Or maybe break it up into functional groups - length, area, etc. (Actually, on a second read, I think you said the same thing - blame the early time of morning :)) Orderinchaos 20:57, 29 May 2007 (UTC)

Miles per hour and feet per second abbreviations

The proper abbreviations for these units is mph and fps respectfully, not mi/h and ft/s as the template produces. -- R'son-W (speak to me/breathe) 04:54, 30 May 2007 (UTC)

It may be better to say the most common abbreviations. The same can be said for some other customary units like square miles (sq mi), square feet (sq ft), and cubic yards (cu yd). Most common would be a better way to word it because NIST considers both the scientific method (mi²; mi/h) and the traditional method (sq mi; mph) as acceptable for customary units. —MJCdetroit 01:57, 31 May 2007 (UTC)
  • I would say that fps should not be used since it tends to be confused with frames per second, especially for people who are used to the metric system. Although I would guess the context might rule that out, still ft/s strikes me as much better. I will admit that mph looks more normal to me than mi/h though.  :) Fanra 11:59, 1 June 2007 (UTC)
    • mph looks like metres per hour (instinctively) to someone versed in metric, even though I doubt that it has ever been used anywhere in that context. Orderinchaos 11:56, 2 June 2007 (UTC)

You probably are more familiar with "fps" and "mph", but officially and per the WP:MoS (which this template is designed to satisfy), the correct abbreviations are mi/h and ft/s. It's designed to promote standards worldwide, not just what is familiar to a user living in the United States or a crown country. -- drumguy8800 C T 08:38, 11 June 2007 (UTC)

Please point out the specific part of the MOS that says this. —MJCdetroit 13:26, 11 June 2007 (UTC)
There's nothing about this issue in WP:UNITS that I can see. I would support a change from mi/h to mph, which is the most common UK abbreviation for this unit. Tevildo 10:26, 1 July 2007 (UTC)
I changed mi/h to mph but left ft/s alone. —MJCdetroit 19:32, 11 August 2007 (UTC)
Thanks, I was going to ask about that. The absence of an mph output worried me a little. I am quite happy with mi/h but my worry was that inconsistent formats on a page (due to 'mph' being used in manual conversions) might result in hostility to the template from others.
The term 'fps' is also used for 'first person shooter'. I certainly would deprecate 'fps' when it can be replaced with the unambiguous 'ft/s' or 'frame/s'. Lightmouse 21:05, 11 August 2007 (UTC)

unit ranges

Anybody have a suggestion for convention on converting a range of values? For example: 2 to 10 feet or 3-4 inches
--SB 03:05, 9 June 2007 (UTC)

It shouldn't be difficult to do, but I'd recommend creating a new template for it, to avoid enlarging this one any more than it already is. All it would take is the ability to write something like {{convert-range|8|10|mi|km|0}}, something similar to what we already use here. I might try my hand at it while I'm at work tomorrow. -- Huntster T • @ • C 04:14, 9 June 2007 (UTC)

Default to abbreviated form

When a number with conversion is supplied, wouldn't it generally be preferable to provide it the abbreviated form? With the default in the abbreviated form, it would make it easier to add the template to infoboxes. -- User:Docu

It defaults to standards set by the WP:MoS. Cheers! -- drumguy8800 C T 08:36, 11 June 2007 (UTC)

Bug?

How come this 

{{convert|6000|ft/s|m/s|0|sp=us|lk=on|sing=off|abbr=off}}

renders this:

6,000 feet per second (1,829 meters per second)

? Shouldn't it be "feet" if I say "sing=off"? And is this is same issue as above? --Ysangkok 09:50, 11 June 2007 (UTC)

Yes, it is the same issue as above. I'll take a look at it when I have some time, but it appears to be elusive. Thanks for the reminder. -- Huntster T • @ • C 09:57, 11 June 2007 (UTC)
I looked through the code to try to fix this but couldn't find an error. If you take out the lk=on part it will correct itself in the short term. I'll give it a look when my eyes are fresh and maybe I'll see the error. —MJCdetroit 19:24, 11 August 2007 (UTC)

Abbr

The table says that "km:h" is abbreviated to "km/hr". However, in usage it is in fact abbreviated to "km/h". Take a look yourself: 60 km/h (37 mph) --Ysangkok 14:06, 18 June 2007 (UTC)

Done. —MJCdetroit 19:32, 11 August 2007 (UTC)

acre needs to be acres

{{convert|200000|sqm|acre|0|lk=on}}--> 200,000 square metres (49 acres)
This should read 49 acres. Please fix. —MJCdetroit 14:16, 29 June 2007 (UTC)

I believe this error is the same as the reports discussed above. I haven't taken a look at the code yet, but thus far the error hasn't been found which causes this. -- Huntster T • @ • C 14:28, 29 June 2007 (UTC)

Power units

Could someone also add the conversion code for power units to the template? (like kW, hp, and PS) --MoRsE 22:13, 17 July 2007 (UTC)

Weight units too (lbs, kg, t) --MoRsE 22:44, 17 July 2007 (UTC)
This template is already way oversized, which causes problems when inserting large numbers of conversions in an article. Instead of having a all-in-one, this template needs to be broken down into component parts (I'll eventually work on this, though I'm acting-trainer at work, so free time is limited). -- Huntster T • @ • C 23:04, 17 July 2007 (UTC)

What am I doing wrong

Using {{convert|18|m/s|km/h|0}} gives 18 metres per second (65 km/h) when it should be 65 km/h and using {{convert|18|m/s|mi/h|0}} gives 18 metres per second (40 mph) whin it should be 40 mph. CambridgeBayWeather (Talk) 00:53, 18 July 2007 (UTC)

Wow... yeah the conversions were inexplicably wrong just for that one. The reverse ones worked correctly, as did m/s -> knots, but the other three needed to be fixed. Thanks for letting us know! Orderinchaos 02:58, 18 July 2007 (UTC)
Thanks, I thought I'd entered something wrong. A useful feature for conversions like that would be the ability to do multiple conversions at the same time something like {{convert|18|m/s|km/h|mi/h|0}}. Cheers. CambridgeBayWeather (Talk) 03:17, 18 July 2007 (UTC)

"Customary"?

Non-US people may well find this to be objectionably US-centric, even if it's an established usage among some Americans (I've never heard of it). Will someone change the instances in the table to simply "US"? Tony 08:24, 23 July 2007 (UTC)

You could always be bold and make the change yourself. The documentation isn't protected. --Holderca1 19:23, 3 August 2007 (UTC)
Perhaps, the letters U.S. should be added in front because technically that is what it is called US customary system. Here in America, we simply/informally called them 'English measurements', but that would be very incorrect outside of the U.S. because of the Imperial system. —MJCdetroit 19:33, 3 August 2007 (UTC)
Done. —MJCdetroit 20:09, 3 August 2007 (UTC)

Illustrative example please? and improved error message?

Would it be possible to include an example of how to use the template? And/or to tidy up the error messages?

I've struggled using {{convert|50|metres|yard|0}} because the error message said "unexpected rounding parameter" (or something like that) rather than "use the abbreviations for the units, dummy" which was what I needed! (No, not seriously suggesting templates should abuse editors, honest!). I got it right eventually, after trying lots of different rounding parameters with and without spaces etc, but if the lead example showed the code, I think I'd have got it right first time. Yes, I know the table is headed "use in coding", but it's easy to read things wrongly. Just: "Example: {{convert|32|m|ft|0}} displays as 32 metres (105 ft) " would do the trick.

Is there any chance that the error message can be improved, perhaps to something more general like "unrecognised input" rather than the red herring of mentioning the rounding figure? PamD 09:51, 23 July 2007 (UTC)

As no-one commented either for or against this, I've added examples myself. PamD 11:46, 13 August 2007 (UTC)

Speed

Change mi/hr to mph 199.125.109.25 17:00, 23 July 2007 (UTC)

Fixed. —MJCdetroit 19:32, 11 August 2007 (UTC)

Modified version, to conform to WP::MOS

This is a really useful template, whoever slaved over it deserves to be congratulated. I've made one small modification, to help conform with the manual of style suggestion that numbers less than 10 should be written as text. I added a new parameter, mos. If it's set to on, and the number being converted is less than 10, then it will be output as text. As in {{convert|7|mi|km|1|mos=on}} displays as "User:Malleus Fatuarum/Sandbox". It's only designed to work for integer numbers, so decimal numbers are passed straight through. As in {{convert|2.4|mi|km|1|mos=on}} displays as "User:Malleus Fatuarum/Sandbox".

I've edited and tested this amended version here. I hope you think it's a worthwhile modification. --Malleus Fatuarum 04:03, 29 July 2007 (UTC)

While I'd initially agree, remember the caveat of Within a context or a list, style should be consistent. Example: There were 5 cats, 12 dogs, and 32 birds or There were five cats, twelve dogs, and thirty-two birds, not There were five cats, twelve dogs and 32 birds. This indicates to me that the current style may be the proper form. Still, since it is an added parameter rather than a requirement, allowing for this particular MOS agreement may be okay. -- Huntster T • @ • C 20:06, 29 July 2007 (UTC)
While I agree with your comment about consistency within lists, I don't think you'd very often be using the {{convert}} template for the kind of example you give. You'd just write the numbers/text out wouldn't you? But in any case, as you say, it's an additional option that doesn't change the present behaviour of the template. I think it would be useful for many articles. --Malleus Fatuarum 20:38, 29 July 2007 (UTC)
Not that particular example, no, but the situation holds for things like "nine miles (14.5 km)", in that these numbers are also directly related and in a kind of list format. It really isn't all proper to mix number words and characters. Of course, let's see what some others have to say on the issue, aye? -- Huntster T • @ • C 01:45, 30 July 2007 (UTC)
I don't think your example of "nine miles (14.5 km)" is valid either, because that's exactly how I believe it ought to appear. It's not any kind of a list, and "nine miles (fourteen point five km) would be absurd even if it was. As would "two miles (three km)". In truth, I'd have preferred to reverse the behaviour of this modified template, to default to the MOS, and have a parameter to switch it off for those cases where it might not be appropriate for whatever reason. But that would probably have been a step too far. --Malleus Fatuarum 13:53, 30 July 2007 (UTC)
We should try to follow the MOS. I personally prefer the numbers as opposed to spelling out the number of the main unit if less than ten. Although, I wouldn't oppose it being an option for the conversions within the main text. I am against making this a default instead of an option because this would change all the conversions that are already nestled within tables and infoboxes. —MJCdetroit 15:20, 30 July 2007 (UTC)
I pretty much share MJC's position here. Orderinchaos 13:08, 13 August 2007 (UTC)
  • So can we have this mos option added then? --Malleus Fatuarum 17:15, 13 August 2007 (UTC)
There is another Manual of Style issue with the template. The use of the 'sing=on' option to display something like "a 2-mile (3 km) road" does not conform to the manual on the use of dashes. What should be written is "a 2 mile-long road". Note that it isn't possible to convert units and have a dash. The only way to conform to the MOS is to reword the sentence so that the singular form (which has to have a dash) is not used. I cannot see any way around the dash and conversion problem, so perhaps it should be stated that the 'sing=on' option does not conform to MOS (but the singular form may be applicable in some cases). Rossenglish 16:15, 13 August 2007 (UTC)
Perhaps this is a case where the MOS ought to be changed/clarified? It doesn't seem to be entirely self-consistent in any case.
"Incorrect: 9-mm gap"
"Correct: 9 mm gap (rendered as 9 mm gap)"
"In the body of an article, single-digit whole numbers (from zero to nine) are spelled out"
But,in your example, the MOS would appear to be suggesting "2-mile wide road" wouldn't it? which shouldn't be too much of a problem for the template I wouldn't have thought. I'm not sure about "two-mile wide road" though. Is that how it ought to be written do you think? --Malleus Fatuarum 17:32, 13 August 2007 (UTC)
‘The hyphen has a number of uses, most of them confusing’ ‘If you take the hyphen seriously, you will surely go mad’
A hyphen is merely a tool to help resolve ambiguity. The phrases '9 mm gap', '2 mile long road', 'two mile long road' have no ambiguity to resolve. The reasonable reader knows exactly what the words mean. I can imagine circumstances in which I might want to use a hyphen, but so far I have not encountered any. If you add a hyphen option, please keep 'no hyphen' as the default.
Lightmouse 21:11, 13 August 2007 (UTC)
That's why I was musing about whether the MOS ought to be changed in this particular case, not the template. Taking your point about ambiguity, if there's no ambiguity about '9 mm gap', then why should there be ambiguity about '9 millimetre gap'? Why have the hyphen in one case but not the other? --Malleus Fatuarum 21:51, 13 August 2007 (UTC)
Ah yes, I see now. I think the MOS guidance is entirely wrong. Lightmouse 22:39, 13 August 2007 (UTC)
To be honest, I agree about the issues with MOS use of hyphens. I can't figure out why abbreviating removes the need for a hyphen either – '9 mm gap' and '9 millimetre gap' mean the same, so why does the latter need a hyphen?! Personally, I'd leave it out in my writing, especially when you get issues like converting and brackets etc. But for an FAC I did recently, all uses of this template couldn't use the sing=on option as then they would have needed a hyphen (a FA needs to fulfil criteria 1a, as listed at User:Tony1/How to satisfy Criterion 1a). The issue is a bit of a mess. Rossenglish 16:07, 18 August 2007 (UTC)
I think I understand the cause of the inconsistency, at least for SI units. The SI authority states that symbolic forms must use a space not a hyphen. This may be because SI symbols are language independent. For example: Portugese 'quilômetro por hora' would be 'qph' and Italian 'chilometro orario' would be 'co'. However, the correct SI form in those languages is 'km/h' as it is with all languages.
However, non-symbolic forms are language dependent and SI tolerates bizarre features of each language, including hyphenation. I default to 'no hyphen' and if the text passes the ambiguity test, I am happy. What were the examples in your FAC? Lightmouse 17:51, 18 August 2007 (UTC)
"Portland is a central part of the 95-mile (153 km) long Jurassic Coast World Heritage Site" was changed to "Portland situated approximately half-way along the UNESCO Jurassic Coast World Heritage Site. The site includes 95 miles (153 km) of the".... This removed the hyphen altogether. The original sentence wasn't ambiguous, but I just changed it anyway so that the issue was avoided completely. Rossenglish 11:53, 20 August 2007 (UTC)
As you say, both forms are unambiguous so I would not use a hyphen. However, as you have found, sometimes changes need to be done to satisfy others. Rewording to avoid issues can be good diplomacy. Thanks for the example. Lightmouse 12:29, 20 August 2007 (UTC)

Only need converted value

Would it be difficult to provide an option to suppress the first value? i.e. {{convert|1.0|mi|km|1|noinit}} = "1.6 km"? Thanks! —Rob (talk) 13:36, 1 August 2007 (UTC)

Yes and if possible doing so would in most circumstances be in violation of the WP:MOSNUM. —`MJCdetroit 19:35, 11 August 2007 (UTC)
It's a special circumstance - there is a table cell separator between the two units. But other editors have created {{Mi-km}} to deal with the situation. Thanks! —Rob (talk) 17:53, 13 August 2007 (UTC)

Incorrect guidance notes say 'mi/hr' and 'km/hr'

The guidance notes say it will print: 'mi/hr' and 'km/hr'. It actually prints: 'mi/h' and 'km/h'. Can somebody change the guidance please? Lightmouse 17:22, 11 August 2007 (UTC)

Done. —MJCdetroit 19:32, 11 August 2007 (UTC)
Thanks. Lightmouse 19:51, 11 August 2007 (UTC)

Confusion over period in guidance

I was confused over the use of a period in the guidance. In the 'Tricks' section, it mentions:

  • 'abbr=on.'

I did not know whether the trailing period was required. It took me a little digging around to find out that the code should actually be:

  • 'abbr=on'

Could you eliminate the period to make it clearer please? Thanks for great code. Lightmouse 20:19, 11 August 2007 (UTC)

I did, but actually I think that the "docs" are not protected so you should be able to edit them. —MJCdetroit 20:28, 11 August 2007 (UTC)
Thanks for doing that. I did not realise I could do it myself. I was a little confused by the 'docs' being somewhere other than where I was reading. I think I have worked it out now. In future, I will try to make such changes myself. Lightmouse 21:11, 11 August 2007 (UTC)

Inconsistent abbreviation

This syntax {{convert|100|km|mi|0}} produces 100 kilometres (62 mi) - kilometres is spelt out in full, but miles is abbreviated. Either both should be spelt out or both should be abbreviated. Even then, "km" is conventional, "mi" is not. --Red King 20:48, 29 August 2007 (UTC)

This is based on the Manual of Style and is not likely to change. If you need to abbreviate both then insert abbr=on {{convert|100|km|mi|0|abbr=on}} for 100 km (62 mi) —MJCdetroit 00:58, 30 August 2007 (UTC)

What wrapping problem?

As a copyeditor, I used to hate this template because most people use it naively, without a thought for appropriate precision or idiom. Now that I've gotten to know it, though, I love it.

Item 8 in the table of contents on this page mentions that a wrapping problem has been fixed by nowrapping the whole thing. Puzzling. I came here to suggest that the template not nowrap indiscriminately, because it recently played hob with a page I was editing by making the previous line ridiculously short (it was next to an image). I'm not exactly sure how it's set up right now, but I'd like to see it nowrap only between value and unit, between value and degree sign and abbreviation, and other places that would be good that I haven't thought of yet. Maybe a switch for that? By the way, what was the wrapping problem before? --Milkbreath 13:29, 30 August 2007 (UTC)

I see what you mean. It would be an improvement if it allowed a line break between the unconverted and converted units. Lightmouse 17:26, 30 August 2007 (UTC)

unabbreviated converted units?

"mi" for miles is ugly and unnatural. I would like to produce "8 kilometers (5 miles)". But the template allows only:

8 kilometres (5 mi) or 8 km (5 mi) or 5 miles (8 km) or 5 mi (8 km).
(from {{convert|8|km|mi|0}} or {{convert|8|km|mi|0|abbr=on}} or {{convert|5|mi|km|0}} or {{convert|5|mi|km|0|abbr=on}}.

I'd much appreciate an option allowing me to non-abbreviate the second measurement (or someone pointing out how I can do so already!). PamD 13:56, 30 August 2007 (UTC)

Just noticed this is answered above. I think the problem is that "mi" is never usually used, unlike "km"! PamD 14:20, 30 August 2007 (UTC)

Bot running

I noticed that there is a BOT removing this template from articles (such as Airway Beacon). Does anyone know why it's running? Are there appropriate and inappropriate place to use "convert"?--Appraiser 13:10, 31 August 2007 (UTC)

It was being discussed at User_talk:Mets501#Out_of_curiosity.... The reasons being stated that it causes the page to load slower. I don't see much of a difference (couple seconds) but then it maybe different for a dial-up user. In any case, at the moment, I not in favor of the bot's edits. I don't think there is any place where it would be inappropriate use this or any other template. —MJCdetroit 13:29, 31 August 2007 (UTC)
The discussion that you're referencing at User_talk:Mets501#Out_of_curiosity... is growing beyond the immediate issue of the bot, and discussion template issues now. Interested folks should probably make themselves aware of the discussion and then continue it here. AKRadeckiSpeaketh 15:16, 31 August 2007 (UTC)

Using the code in monobooks

Would I be able to use the code in my monobook? I have quite an extensive monobook for metrication but I have never been able to take a numerical value from an article and do arithmetic with it. Lightmouse 10:47, 4 September 2007 (UTC)

Error encountered

On Project Excelsior, I tried to use {{convert|714|m:h|m/s|0}}, but it generates "714 (Expression error: Unexpected round operator m/s)". Is there an error in my usage or in the template? Thanks. -- JHunterJ 11:15, 4 September 2007 (UTC)

Assuming you're trying to convert from mph to metres/second, then it should be {{convert|714|mi/h|m/s|0}}. --Malleus Fatuarum 11:38, 4 September 2007 (UTC)
(edit conflict) The error occurred because you tried to use "m:h" instead of "mi:h". I've fixed this in the article. Something I didn't fix in the article, however, was the lack of links to terms. Remember to use "lk=on" for the first instance of any conversion type (as I did with this particular conversion in the article), so that readers unfamiliar with a specific measurement can learn more. -- Huntster T • @ • C 11:40, 4 September 2007 (UTC)
Wow, my eyes may finally be going -- the little i and the : ran together when I looked it up. Thanks for the fix. As for "lk=on", WP:UNITS doesn't seem to specify (or prohibit) linking them when first used, and the links don't seem all that necessary to the subject -- the article is about the project, but not about the record-setting speeds or heights reached in particular. -- JHunterJ 23:26, 4 September 2007 (UTC)
Heh, well that's the wiki way. I recall when they were specified, but I suppose that was contested and overturned at some point, perhaps! In any case, I simply find those links to be useful occasionally, regardless of article focus, though admittedly not so much for common measurements like miles and km's. Cheers! -- Huntster T • @ • C 00:12, 5 September 2007 (UTC)

Request for an option to match input and output significant figures

I would like to request an option to match input and output significant figures. This would permit a single format to handle:

  • 3,426,000 square feet
  • 100,000 square feet
  • 950 square feet

It would be very convenient for handling precision.
Thus: {convert|3,426,000|sqft|sqm|sigfig=on} would convert to 318,300 m².

It would be even better if the user could adjust the number of significant figures.
Thus: {convert|3,426,000|sqft|sqm|sigfig=-1} would convert to 318,000 m².

Just a thought. Lightmouse 17:55, 11 August 2007 (UTC)

Try this:
{{convert|3426000|sqft|sqm|-3}}----> 3,426,000 square feet (318,000 m2)
—MJCdetroit 19:40, 11 August 2007 (UTC)
Thanks, It is useful and I am using it already. However, the value still needs to be examined to work out that it is '-3' in one case (e.g. 3,426,000 square feet) and '0' in another (e.g. 950 square feet). I was asking if it could be automated so search and replace scripts would be simpler. I hope you understand what I mean. Lightmouse 20:11, 11 August 2007 (UTC)
To do that you'd have to first count the number of sig figs in the input. It's doable & I think it would be worth adding to the template ... not merely as an option but as the default. Of course, care must be taken so as not to convert the likes of 1 mi to 1 2 km. Jɪmp 08:30, 3 September 2007 (UTC)
Thanks. Precision matching is part-art and part-science but sig fig matching is a very good start. Then adjustment up or down is the next most useful. Decimal control (i.e. the current functionality) is probably third most useful. I would prefer to keep it simple and not have a requirement to design out converting 1 mile to 1 km. This function would allow me to simplify my monobook metrication code.
Lightmouse 18:23, 3 September 2007 (UTC)
Part art and part science it is but p'haps part of that art part could be satifactorily be mimicked by a sufficiently sophisticated algorithm. Matching sig figs is good but not perfect, however, it's generally predictable where sig fig matching is about to break down ... for example, conversions between yards & metres with only one sig fig are always going to be trouble. Jɪmp 03:27, 6 September 2007 (UTC)
The yard/metre example is a good one for debate. I might be inclined to convert 200 yards into 200 metres in: Setrock Creek Falls, Second Battle of Trenton, Indiana Toll Road, July 2006 Java earthquake. But convert it to 180 or 183 metres for 1930 British Empire Games, Benchrest shooting. Lightmouse 15:28, 6 September 2007 (UTC)

Requested display changes part 2

I inserted a requested change from above (dated July 15th) to have a slash instead of parenthesis option. That request also included a request for a table display, but I'm sorry, I couldn't figure that part out; it never looked right when I tested it. Maybe someone else can. Therefore, I changed the code to accept a slash function. Here's how it can be done: include the line |disp=slash (or these two for shorthand: |disp=s or |disp=/):

{{convert|100|ft|m|0|disp=slash}}-->100 feet (30 m)*
{{convert|100|ft|m|0|disp=s}}-->100 feet (30 m)*
{{convert|100|ft|m|0|disp=/}} -->100 feet (30 m)*

This should help some of you. —MJCdetroit 20:22, 10 September 2007 (UTC)

Possible replacement of auto templates by this one

Could we replace all the auto templates by this one? Lightmouse 19:49, 7 September 2007 (UTC)

Where possible, i.e. Auto in, auto mm, auto mph... Yes, I'd support that. —MJCdetroit 20:21, 7 September 2007 (UTC)
I'll be honest, I love this template, but its size makes it unmanageable. I'd suggest the reverse, and break it into its component parts and into separate templates (Template:Convert-distance, Template:Convert-temp, etc). More templates can be transcluded into individual articles that way, which is a perennial complaint of all-in-one type templates. -- Huntster T • @ • C 06:43, 8 September 2007 (UTC)
I like this code and have the following comments:
  • There are always ways of making code more efficient, either by being smarter or by reducing features. It does seem to repeat each unit at least 3 times. Perhaps we could drop the linking feature to get more units. I wish I understood the code bettter.
  • If we are to break it up, perhaps we could simply move the source unit into the name. That is the solution used by 'Category:Automobile conversion templates' and 'Category:Unit display'. It would mean more templates but it would be more wysiwyg for the user.
  • The template is useful in my metrication script because all I need to do is detect that a numerical value is present. I regard the template merely as an interim calculator. The template has many other advantages (correct formats etc) but in many cases I would prefer the article to have the raw text rather than the template. Is there a good way of getting to that end point?
  • Currently the commands do not match the units (e.g. the command for 'km/h' is 'km:h'). I presume that is because the software does not like the '/' character in variable names. Is there any other way to make the command match the unit? Lightmouse 12:28, 8 September 2007 (UTC)
See the response below in #More flexiable inputs. 16:38, 12 September 2007 (UTC)

Possible bug: unwanted use of scientific notation

Please see: Hampton Roads. The template makes it show '1.0E+5 m²' but I wanted it to show '1,000,000 m²'. Is this a bug? Lightmouse 15:46, 6 September 2007 (UTC)

That's a product of the Wikimedia calculation software (e.g. {{#expr:100000round-1}} gives you 100000). It's not a bug in the template per se ... well, it kind of is, in the sense that this type of thing had not been forseen and accommodated for. By the by 1.0E+5 m² = 100,000 m² ≠ 1,000,000 m² ... you wanted it to show 100,000 m² ... 1.1×106 sq ft ≈ 105 m². Jɪmp 07:44, 11 September 2007 (UTC)
It seems to be working now (e.g. {{#expr:100000round-1}} is too): 1,100,000 sq ft (100,000 m2). Jɪmp 17:37, 13 September 2007 (UTC) ...
Things aren't always as they seem. It works in preview mode but not after you hit [Save]. However, I think I might have found a solution: 1,100,000 sq ft (100,000 m2)
Now this is strange: it's working again (& not just in preview mode). Jɪmp 17:43, 13 September 2007 (UTC)
Interesting. Could it be something to do with the cache? Lightmouse 17:54, 13 September 2007 (UTC)
Maybe. Here's my workaround though, which may, may not or may sometimes and other times not be necessary. I found that when negative numbers are rounded it worked okay even when the same magnitude positive number was turning into E notation. So I threw a minus sign into the calculation and then mulitplied by −1. I was trying to test it here but the unmodified version is working fine now anyway. Jɪmp 18:03, 13 September 2007 (UTC)
No, it doesn't work: Es everywhere. Jɪmp 18:06, 13 September 2007 (UTC)

Wishlist item: request for separators to be valid in value field

I would like to request a feature whereby the value can include separators (comma, space, period). For example,

  • {{convert|3,426,000|sqft|sqm|-3}}
  • {{convert|3.426.000|sqft|sqm|-3}}
  • {{convert|3 426 000|sqft|sqm|-3}}

This would make search and replace strings simpler. Lightmouse 21:17, 11 August 2007 (UTC)

As far as I know the {{#expr: }} logic will not allow this. That is why the number must be entered in a raw format then it is formated by the template before being displayed. —MJCdetroit 21:43, 11 August 2007 (UTC)
That is a pity. Thanks anyway.
I have been creating scripts using these templates. You can see how complicated it can get if you look at User:Lightmouse/monobook.js (search for 'sqft'). Feel free to copy code. Is anyone else doing this? Lightmouse 22:38, 11 August 2007 (UTC)
It's a little tedious but you could use <!---->.
  • {{convert|3<!---->426<!---->000|sqft|sqm|-3}} gives 3,426,000 square feet (318,000 m2).
Jɪmp 01:00, 21 September 2007 (UTC)

Grammar problem

In the example for "singular" it says "(ex: "The 190 foot (58 m) bridge" as opposed to "feet")." There has to be a hyphen in there: "190-foot bridge." It's not optional. Ask anybody. This property of the template makes it a hazard in this instance. An example of a correct use is "The man was six foot tall," English idiom bizarrely employing what looks like the singular for human height. But the template isn't so good there because convention demands the word "six" and not a numeral "6." --Milkbreath 23:04, 10 September 2007 (UTC)

Did anyone fix this?.. This is Drumguy8800, btw, I just don't feel like signing in. -- 71.164.157.89 21:25, 15 September 2007 (UTC)
I started fixing it – (#Modified version, to conform to WP::MOS) – but nobody seemed to be interested. --Malleus Fatuarum 00:30, 16 September 2007 (UTC)

I hadn't realized I was exhuming a dead horse. The problem remains, though. The MoS is an imperfect document to be sure, but we copyeditor types try to adhere to what little guidance it provides. Besides, there are good rules outside it. Many of the conventions regarding hyphens are meant to make text look good, others are meant to conform to grammar, and others at least incidentally help resolve ambiguity. The rules regarding hyphens in number expressions cover all three. The one missing in "12 mm wingspan" is missing to make it look good. The one in "12-millimeter wingspan" is grammatical. The one in "one-foot leg" is grammatical and a mercy to the reader. The ones in "two-foot-long feet" are grammatical, but indispensable in any event. I'm surprised that code-writing programmer types would be so easily put off by a little bit of syntax. --Milkbreath 01:22, 16 September 2007 (UTC)

I wasn't. But I can't change the template; all I can do is to offer my code modifications back to those who are the guardians of the template. --Malleus Fatuarum 01:43, 16 September 2007 (UTC)
‘The hyphen has a number of uses, most of them confusing’ ‘If you take the hyphen seriously, you will surely go mad’
I only use a hyphen as a tool to resolve an ambiguity. I do not regard it as part of grammar or spelling. You will see plenty of examples constructed like '12 millimeter wingspan' without a hyphen. Lightmouse 12:20, 16 September 2007 (UTC)

We don't get to use our own judgement in such matters. Each publisher prescribes a style, and we must adhere to it. This at the very least makes for consistency. The reader is our ultimate boss, though, and we have to fix it so that he isn't for one instant distracted from what he's reading by the inkmarks on the page. Generally accepted practice, which can be seen in any professionally produced book, demands a hyphen in your example, as does Wikipedia. --Milkbreath 16:02, 16 September 2007 (UTC)

Regardless of any styleguide, authors sometimes use a hyphen and sometimes do not. Confining the search to Wikipedia, Google found no examples of 'millimeter wingspan' but did find:
  • 'x-metre/meter/foot wingspan' 20 total hits
  • 'x metre/meter/foot wingspan' 29 total hits
I am sure that in other cases, the hyphenated format is the majority. Lightmouse 21:03, 17 September 2007 (UTC)
Milkbreath's well-made point must surely have priority. It isn't for individual editors of this body of work – regardless of what authors may do in general – to distract the reader with inconsistencies in any personal stylistic preferences. --Malleus Fatuarum 21:16, 17 September 2007 (UTC)
I have no measure of 'reader distraction'. If we here are not individual editors like the 49 in the example cited, what are we? Lightmouse 21:50, 17 September 2007 (UTC)
A good measure of "reader distraction" is "editor inconsistency". If you were to submit your work to a publisher you would be expected to conform to their style guide. Why should wikipedia be any different? --Malleus Fatuarum 22:18, 17 September 2007 (UTC)
Lets leave the inconsistency/distraction point to one side. On the other issues, we seem to have covered several debating points here:
  • the style guide is right
  • the style guide should be followed
  • you believe that editors are wrong to leave hyphens out, even if there is no ambiguity to resolve, I don't.
Lightmouse 23:02, 17 September 2007 (UTC)
  • You have, for whatever reason, chosen to misrepresent what I actually said. I have stated elsewhere that I do not believe that the style guide is "right" with respect to the use of hyphens, but I don't see the issue as one of "right" or "wrong". It's simply one of conforming to the style guide of the publication that you're contributing to. --Malleus Fatuarum 23:40, 17 September 2007 (UTC)
I was not trying to represent what you said. I am sorry if it looked like that. Those bullets were my own opinion. I agree with you that there are too many inconsistencies on Wikipedia. If all articles conformed to the house style, that would improve consistency. Lightmouse 09:10, 18 September 2007 (UTC)
  • You said - presumably addressing me - that "you believe that editors are wrong to leave hyphens out, even if there is no ambiguity to resolve ...". That is not my position. My position is that editors are wrong to ignore the style guide; whether the guide is "right" or "wrong" is immaterial. As it happens, I don't think that you or I would disagree about the use of hyphens. --Malleus Fatuarum 02:48, 21 September 2007 (UTC)

Feature request: commas in numeric value

I would like to be able to put a comma in the numeric value. For example: {{convert‎|123,456,789|mi/h|km/h}}. Is such a feature possible? Note that we often assume the comma appears after groups of 3 digits but Indian numbers sometimes have groups of 2 digits. Lightmouse 19:16, 15 September 2007 (UTC)

Sorry, It's not possible. —MJCdetroit 16:08, 16 September 2007 (UTC)
OK. Thanks for responding. Lightmouse 09:00, 18 September 2007 (UTC)
Commas won't work but see my suggestion above. Jɪmp 01:56, 21 September 2007 (UTC)

Advise "metre" into "meter"

According to the Google search and many main search engine, the word of "meter" than "metre" more commonly used. Whether has to alter to "meter"?
59.115.152.177 11:00, 22 September 2007 (UTC)

The short answer is 'do not change it'. The longer answer is:
  • Furthermore the template is transcluded on something like nine thousand pages. Who's going to check all of them for spelling?
Google turns up more hits for US spelling so this should be the default ... sorry, it doesn't work like that. Jɪmp 14:33, 24 September 2007 (UTC)

The spelling of the word is "metre" - it's French in origin. Only the US uses the non-standard spelling. If you really must use US spelling, put "|sp=us" at the end of the template reference. e.g. 75 meters (246 ft) Orderinchaos 14:54, 24 September 2007 (UTC)

Volume units

Moved from user talk page (begin)
Thanks for your conversion of acres to square kilometres in the petroleum history article. Ididn't know that function was available.

A question: I'd like to use the same kind of conversion formula to convert my references of crude oil (1 cubic metre = 6.29 barrels) and natural gas (1 cubic metre = 35.49 cubic feet), and I'd like to do it both ways. Is there a way to do this? I'd appreciate your thoughts.

Thanks. Peter
Moved from user talk page (end)

The above question was posted on my talk page. I do not believe there is such a function. I wish there was. Can anyone help? Lightmouse 16:02, 17 August 2007 (UTC)
I've created {{bbl to t}}; the rest will follow.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:24, 4 October 2007 (UTC)

Degree symbol

Is this template ever going to be expanded to include the coulomb, rayleigh or farad? Yeah, hard to say but supposing it isn't, it might be helpful to make it such that plain C, R and F could be used for Celsius, Rankine & Fahrenheit respectively as an alternative to the more tedious-to-type °C, °R and °F ... or perhaps we'd be safer with degC, degR and degF. Jɪmp 07:30, 11 September 2007 (UTC)

That's easy to do. We can have the template recognize both °C, °R, °F and C, R, F. I'll experiment with it and make the appropriate changes in the near future. —MJCdetroit 16:12, 11 September 2007 (UTC)

More flexiable inputs

I made a test version (viewable at Template:Convert/sandbox‎) to fulfill the requests made by Jimp and LightMouse (above) to be able to use C,R,and F without the degree symbol and to be able to use a slash in the input coding with entries such as: ft/s, m/s, km/h, etc. This will allow more flexiablity with the inputing of the code. However, the abbreviation/symbol will always be the same. For example {{convert|100|mi/h|km/h|0|abbr=on}} will still result in 100 mph (161 km/h). You can see some other examples at Template:Convert/check. The old km:h and °F style will still be available to use as well.

I've tested it and I haven't found any problems, but I am asking that others (esp. Jimp and LM) to test the sandbox version. If everything is clean, we'll go live. —MJCdetroit 16:38, 12 September 2007 (UTC)

I found problems. I tested it on 1964 Isle of Man TT. I converted of 92.14 mph into {{convert|92.14|mi/h|km/h|2|abbr=on}}. I did a 'Show Preview' on the page and it gave '92.14 (Expression error: Unexpected round operator )'. Lightmouse 08:04, 13 September 2007 (UTC)
Lightmouse,
The problem is that you're using the unmodified version. Try {{convert/sandbox‎|92.14|mi/h|km/h|2|abbr=on}}. It gives 92.14 mph (148.28 km/h). Jɪmp 08:56, 13 September 2007 (UTC)
More tests
{{convert/sandbox‎|789|km/h|mph|2|abbr=on}}  gives  789 km/h (490.26 mph)
{{convert/sandbox‎|1800|K|R|abbr=on}}  gives  1,800 K (3,240 °R)
{{convert/sandbox‎|34|C|F|2|abbr=on}}  gives  34 °C (93.20 °F)
{{convert/sandbox‎|57|F|C|2}}  gives  57 °F (13.89 °C)
{{convert/sandbox‎|10|ft/s|m/s}}  gives  10 feet per second (3.0 m/s)
Looks good ... Jɪmp 09:08, 13 September 2007 (UTC)
Thanks Jimp. I added 'convert/sandbox' and it worked correctly on 1964 Isle of Man TT. I also tested it on K class ferry and it worked correctly ('10 knots' -> {{convert/sandbox|10|knot|km/h|0}} which shows 10 knots (19 km/h)). Lightmouse 11:24, 13 September 2007 (UTC)

Thanks, MJCdetroit for updating the code. I have two further requests:

  • Now that the slash formats ('km/h' etc) will work, I would like to simplify the instructions by taking out references to the colon formats ('km:h' etc). The colon formats must remain in the code itself for now.
  • I would like to remove 'kph' from the code. I have the strong opinion that formats like that and 'kmph', 'km/hr', 'kmp/h', 'kmh' should not succeed when the correct format 'km/h' is available.

I will try making these changes myself. Unfortunately, I don't think I have the correct permission to amend the code. Lightmouse 08:44, 4 October 2007 (UTC)

I removed the colon formats from the instructions (which you would have permission to edit), however they need to stay in the code itself. —MJCdetroit 12:26, 4 October 2007 (UTC)
Thanks for updating the instructions to encourage the correct formats. I know that the previous formats need to stay in the code to support existing pages (perhaps a bot could revise these at some point). You recently added 'kph', can that be removed too? Lightmouse 15:35, 4 October 2007 (UTC)
Probably, but I have seen that abbreviation used before and as long as the output is corrected to km/h, does it really matter? —MJCdetroit 17:15, 4 October 2007 (UTC)
That abbreviation (kph) is indeed common amongst english speakers that use 'mph'. It is also common to use other forms such as kmph, km/hr and kmh. For all I know, Italians will make similar errors and use the abbreviation 'cao'. I think it does matter that people use the correct symbol. The whole point of SI is standardisation to a single form in all regions and all languages. As you say, the output is always correct but I would prefer not to build in support for a format that people should not be using. Signed 'Arch-pedant'. Lightmouse 17:30, 4 October 2007 (UTC)

Suggestion to simplify the code and its effect on articles

We have been worried by the size of the code and it has been criticised for its effect on articles. I notice that when this code was expanded, it produced things like:

  • <span style="white-space:nowrap">10&nbspmiles&nbsp(16&nbspkm)</span>

That expression seems to me to be more than is strictly necessary.
Firstly, there should not be a non-breaking space between the unconverted and converted units. Please the code be amended so that it does not add it?
Secondly, can the code be amended to stop adding 'span style' stuff?
Lightmouse 09:58, 22 September 2007 (UTC)

The "span style stuff" is a direct result of the {{nowrap}} template that is used. It looks as if this was added to the template code on the 9th of April with this discussion and probably was based on an earlier discussion. It can be very easily removed. If removed it looks like the the template code could have a possible break between the last letter of the first unit (the 's' in miles) and the parenthesis of the next conversion; (16...) in your example. Expand your example and you should see 10&nbsp;miles&#32;(16&nbsp;km). The &#32; allows for a normal breaking space. If we remove the automatic "nowrap" function of the template code, there is no reason why anyone can not just manually use the nowrap template when it is desired by entering something like {{nowrap|{{convert|1000|m|yd|0}}}}. I know removing this would allow {{convert}} to be more "infobox friendly". Any objections to removing this automatic feature? —MJCdetroit 01:11, 1 October 2007 (UTC)
Thanks for doing that. Lightmouse 08:25, 4 October 2007 (UTC)

ConvertWeight

For converting weights—please check out {{ConvertWeight}} (aka {{convertW}}. —MJCdetroit 21:59, 6 October 2007 (UTC)

Can't the functionality of {{ConvertWeight}} be put into this template so that there is only one conversion template? Chris_huhtalk 19:30, 9 October 2007 (UTC)
Yes and No. It could but for performance reasons it is not. Including the weights would make {{convert}} blog down. In fact it has been proposed to break up convert in to smaller templates. —MJCdetroit 20:30, 9 October 2007 (UTC)
In its current form this is true but the problem can be solved. There is a way that weight ... and mass, volume, energy, angular acceleration and whatever else you like can be added to this template without blowing it up. It's in the works. As for smashing {{convert}} into little pieces ... well the little pieces do exist and likely will continue to co-exist with this considering that some of them have features (e.g. {{ft to m}}'s two- and three-dimensional options) which don't seem to be a priority to include here. Jɪmp 17:09, 11 October 2007 (UTC)
In my mind, the idea is to split this up into standardised groups, such as {{Convert area}}, {{Convert speed}}, etc. Smaller, thus being able to be used more times within any given article, but still versatile enough to avoid having to look up or memorise the huge number of micro templates like your example of {{ft to m}}. -- Huntster T • @ • C 19:52, 11 October 2007 (UTC)
These templates are (or at least should be) all categorised together saving the memory strain (which isn't really that great since they are generally named {{original unit abbreviation to converted unit abbreviation}} ... those few which differ should probably be moved or deleted). This template can be reduced and extended at the same time. It is possible to reduce it in size (i.e. pre-expand size) whilst at the same time increasing its scope. The need to churn out the likes of {{ConvertWeight}}, {{ConvertArea}} & {{ConvertSpeed}} would be eliminated. This is what I have in mind though it'll take an overhaul of the template. Jɪmp 23:37, 11 October 2007 (UTC)
Yeah, it would be fantastic if this template could be rewritten to optimise its code, but I just don't see how much that can be done. I love this template's functionality and ultimate simplicity in use, I just think it would simplify matters dramatically to split into distinct measurement types. -- Huntster T • @ • C 23:43, 11 October 2007 (UTC)
As I see it, there's a lot that can be done in terms of code optimising (where by "optimising" I pretty much refer to reduction of pre-expand size). What I have in mind should allow us to add units to our heart's content without affecting the pre-expand size. If I'm right, then splitting the thing up into "measurement types" (i.e. length, speed, etc.) would complicate rather than simplify matters requiring editors to specify the "measurement type" they are converting. Instead, I'd rather see things like {{ConvertRange}} & {{Convert3D}} to incorporate some of the special features you find on some of those single-purpose templates. Jɪmp 02:04, 12 October 2007 (UTC)

← Like I said, I'd love to see the template conserved so long as these certain issues can be addressed (primarily the very limited number of times it can be used on articles). If this can be done, all be better to keep it around and expand it to include the various other measurement types (weight, volume, etc). -- Huntster T • @ • C 02:09, 12 October 2007 (UTC)

I say it's very much doable but will involve a complete rewrite. I'm working on it. Jɪmp 03:30, 12 October 2007 (UTC)

Template use limit?

On the List of tallest buildings in Dubai page the "Unit m" template is used 131 times, and after the 114th time it fails, showing Template:Convert instead. From the 123rd time on it shows Template:Unit m instead. It does not appear to be a bug in the article's code, because if you edit just the Approved section (where it begins failing) and do a preview, the "Unit m" function works perfectly. This appears to be a deeper bug of some sort. Perhaps the function is timing out or something after so many calls to it? Any ideas on what is going wrong and/or how to fix it? -- HiEv 10:39, 6 October 2007 (UTC)

Well, first off, that article used {{Unit m}}, not this template, but to answer your question: yes, the problem was the number of calls to the template; specifically, the template was called so many times that it overran the number of bytes Wikipedia allows for template transclusion (two megabytes). However, it appears someone went through and solved the problem by removing the templates entirely, so problem solved. -- Huntster T • @ • C 23:15, 6 October 2007 (UTC)
{{Unit m}} uses {{Convert}}, so the article was using this template indirectly. MJCdetroit went through and substituted the templates which fixed the article, so thanks goes to him.  :-) -- HiEv 01:45, 7 October 2007 (UTC)
I didn't notice that re: "Unit m" using "Convert"...wow, no wonder the limit was reached. Double transclusion is a very very bad thing. -- Huntster T • @ • C 02:21, 7 October 2007 (UTC)
We should probably goes through Category:Conversion templates and TfD some of the redundant templates like "Unit m". —MJCdetroit 02:30, 7 October 2007 (UTC)
Personally, I believe the opposite, in that this template should be split apart due the problems its size presents to any number of articles. Sure, there are quite a few that can be disposed of as redundant, but not if such a deletion will favour this template over any others. We need some standardisation, badly. -- Huntster T • @ • C 03:11, 7 October 2007 (UTC)
I don't believe {{Unit m}} is redundant. {{Convert}} gives editors who are familiar with different systems of units the power to pick the secondary unit. The {{Unit *}} templates don't take that approach. One of the big benefits of these templates is that editors don't have to know what is the appropriate secondary unit.
I converted {{Unit m}} and similar templates to use {{Convert}} to simplify their implementation when adding lk and sing options. If there is a performance problem with this double transclusion then {{Unit m}} could be rewritten with all the implementation internally.
{{Convert}} does not provide an alternative for all the {{Unit *}} templates so if you delete some but not others you may give editors a more inconsistent experience. Adding more unit types to {{Convert}} doesn't appear to be an option due to its bloat.
Before people start deleting templates we need to answer the question:
  • should {{Convert}} be broken up?
  • if so, how small should the pieces be?
Depending on the answers these templates may stay around. If you are going to delete the {{Unit m}} and its friends then convert should provide a default output unit for each input.
-- PatLeahy (talk) 19:32, 11 October 2007 (UTC)
{{Unit m}} and {{Unit metre}} no longer use {{Convert}}. I will work on modifying the other templates in this family. -- PatLeahy (talk) 20:54, 12 October 2007 (UTC)
Much as I really like the idea of having a one-stop-shop template, the bloat is an issue, and seems to be unavoidable unless the template is divided out into sections. One idea may be to use the base unit, eg Convert-m converts from metres into other things. Really don't know. Orderinchaos 22:18, 12 October 2007 (UTC)
It's not unavoidable. Yes, using the base unit saves lot of space but, of course, this is only part of the solution. "should {{Convert}} be broken up?" definetly not. Jɪmp 13:59, 15 October 2007 (UTC)

/ instead of () for converted result

In some cases, the result of this template is put into a set of parantheses, resulting in )) in the end, looking sub-optimal. In those cases I would prefer an option to separate, say, meters and feet with a slash. Have a look at Hinnøya and see how the elevation of the mountain in the right infobox looks. --Berland 19:16, 10 July 2007 (UTC)

Requested display changes

{{editprotected}} the line:

}}}}}} ({{formatnum:{{ #expr: {{{1}}} * {{ #switch: {{{2|}}}

needs to be changed to:

}}}}}{{ #switch: {{{disp|}}}|table={{!}}{{!}}|slash=/|=} (}}{{formatnum:{{ #expr: {{{1}}} * {{ #switch: {{{2|}}}

and the line:

}}}})}}</includeonly><noinclude>{{pp-template|small=yes}}{{esoteric}}

needs to be changed to:

}}}}{{ #switch: {{{disp|}}}|table=|slash=|=)}}}}</includeonly><noinclude>{{pp-template|small=yes}}{{esoteric}}

at least I think. Of course coding is typically a process, this may not work perfectly, though here is the desired effect:

Code Effect why?
{{convert|24|m|ft|0}} 24 metres (79 ft) standard
{{convert|24|m|ft|0|disp=table}} 24 metres 79 ft for using template within tables
{{convert|24|m|ft|0|disp=slash}} 24 metres/79 ft a different display option that has been requested

Thanks so much. -- drumguy8800 C T 14:22, 15 July 2007 (UTC)

Please copy the template to a sandbox, make the changes there, and test them. Then add a new request to copy the changed code back here. — Carl (CBM · talk) 20:02, 15 July 2007 (UTC)
I played with this in one of my sandboxs and I couldn't get the disp=table to work correctly. All I keep getting was a single pipe (|) in between the values. The slashes worked well. Drum could you take a second look at this table display thing? —MJCdetroit 15:52, 4 September 2007 (UTC)
You don't want the unit name/abbreviation in the table, right? Normally you'd just want numbers—the units go at the top of the column.
Code Effect/ft Effect/m Why?
{{convert|24|m|ft|0|disp=table}} 24 79 Because it gets
{{convert|24|m|ft|0|disp=table}} 24 79 tedious seeing metres & ft
{{convert|24|m|ft|0|disp=table}} 24 79 over and over.
Jɪmp 17:09, 18 October 2007 (UTC)

RfT: ConvertVolume; more votes for other misc features

Request for template: I'd like to have {{ConvertVolume}}. I searched around [[Category:Unit display]] and [[Category:Conversion templates]], but I can't find a simple L-to-gal and gal-to-L conversion template. Can someone build that, or even better, a general ConvertVolume template with all major volume units? I may give it a shot sometime just by copying the syntax of another conversion template and then sandboxing my way via trial-and-error. But if anyone with more skills than I have is willing, it'd be great if you beat me to it.

Also, I read the earlier discussions about:

  • nobreak between value and unit but break between first and second expressions—I vote for that too!
  • capability to hyphenate between value and unit when using the expression adjectivally. That discussion deteriorated into a spat, but the idea is still a very good one if any coders are up to the technical challenge of adding an attribute such as | adj="on".

— ¾-10 23:29, 12 October 2007 (UTC)

I'm working on volumes. The nobreak nobreak between value and unit but break between first and second expressions thing has already been taken care. —MJCdetroit 01:33, 13 October 2007 (UTC)
We don't need | adj="on". Taking care of adjectives was the purpose of | sing="on". The only other reason I can think of to use | sing="on" would be to hack around the problem of feet when you want foot (e.g. "He's six foot tall."). Jɪmp 16:59, 18 October 2007 (UTC)
For review: {{ConvertVolume}} —MJCdetroit 17:08, 18 October 2007 (UTC)
  • ConvertVolume is looking great.
  • Re "sing=on": Well, what I meant by suggesting "adj=on" is hyphenation. For example, see Spray (sailing vessel) where it says "The Spray was a 36-foot-nine-inch (11.2-metre) sloop-rigged fishing boat refitted as an ocean cruiser". As far as I know, there is no way to get the hyphens in there if using any unit conversion template. (If anyone knows how, do let me know.) The feature I'm suggesting is that if someone uses a template and inserts "adj=on", then there would be a hyphen between the value and the unit, instead of a nbsp character. — ¾-10 23:47, 18 October 2007 (UTC)
Ah! "attributive". That's the word that I already knew but could not remember lately. (Refers to when the adjective or adjectival phrase is before the noun, rather than being predicative.) Thanks for the link to WP:HYPHEN. — ¾-10 02:11, 19 October 2007 (UTC)

Request: link one unit but not the other

The lk=on feature links both units. In some cases, I want to link one unit but not the other. For example, a previous editor might have linked 'nautical mile' and 'knots'. I might want to retain those links but do not want to link the unremarkable units 'km' and 'km/h'.

Would it be possible to modify the lk=on feature (e.g. 'lk=1' links the first unit and 'lk=2' links the second unit)? Lightmouse 16:49, 18 October 2007 (UTC)

Bot needed to clean up after bot?

A while back, a bot was expanding the convert template. This resulted in a discussion and the bot was stopped. However, a lot of articles now contain things like:

  • <span style="white-space:nowrap">10&nbsp:miles&nbsp:(20&nbsp:km)</span>

For example, see Central Europe Campaign and other articles in the User:MetsBot's contribution list. Would it be possible to clean these up? Lightmouse 17:01, 18 October 2007 (UTC)

I'd start by asking User:Mets501, since it was his bot and since his bot already has the approval for that task. —MJCdetroit 17:25, 18 October 2007 (UTC)
Thanks for the suggestion. I have left a note on his talk page. For the record, I had no problem with the concept of the expansions. It is the 'span', 'nowrap' and unnecessary 'nbsp' clutter in the edit page that I want removed. It is hard to read and it makes further search and replace more complicated. Lightmouse 18:09, 18 October 2007 (UTC)
I don't really think that such a reverse change is necessary. The edits to change it are not worth the potential benefits, I think. —METS501 (talk) 01:40, 19 October 2007 (UTC)
I am willing to add code to my script to eliminate these. Any tips on how I might do it? Can you see any problems if I simply deleted all instances of <span style="white-space:nowrap"> and </span>? Lightmouse 19:20, 19 October 2007 (UTC)

2nd convert term?

Is there a way to expand this to add a second convert term? For instance, it would be nice to be able to convert acres into both sq mi and sq km, but right now {{convert|20000|acre|sqmi|sqkm|1}} produces an error: 20,000 acres (31 sq mi)* AKRadeckiSpeaketh 17:15, 30 August 2007 (UTC)

It's doable but perhaps this should be saved for a {{convert2}} so as not to make an already quite large template biggger. Jɪmp 02:00, 21 September 2007 (UTC) There are a couple of ways of doing this. Jɪmp 14:49, 18 October 2007 (UTC)
I've done this at {{convertWeight}}, and {{convertVolume}}, but it does increase the pre-expand size. That change can be very easily done here, but would require consensus to do so. Of course, if there is a better way to build this mousetrap—I'm all for it!—MJCdetroit 16:33, 18 October 2007 (UTC)
I do have something in mind which might catch mice. Jɪmp 16:51, 18 October 2007 (UTC)
I caught this mouse. Replace the pipe between sqmi and sqkm with a space:
  • {{convert|20000|acre|sqmi sqkm|1}} now produces 20,000 acres (31.3 sq mi; 80.9 km2)
It doesn't work with just any combination but I think I've got most of the useful ones. Jɪmp 08:25, 20 November 2007 (UTC)

Knots (kts) not working

Example: 

{{convert|100|mph|kt|0}}

yields 100 miles per hour ([convert: unit mismatch]). The inverse also fails. Most useful for hurricane pages. Thanks! —Rob (talk) 16:17, 6 October 2007 (UTC)

You should have been entering {{convert|100|mph|knot|0}}. The code only accepted an input of knot and not kt. Therefore, I adjusted the code to also accept kt. That's why your sentence above now converts after the word yeild.
Also, in the future I think I'll add an optional third unit so that 100 mph could be converted into 100 mph (87 kt/161 km/h). I've been working on something similar for {{ConvertW}} and it seems to being working well. —MJCdetroit 18:03, 6 October 2007 (UTC)
Nice idea. The slash character '/' indicates division as in 'km/h'. I suggest that it might be better avoided as a separator as in 'kt/161'. Perhaps there might be a better way of indicating separation.
In addition, the discussions on wp:mosnum about kn versus kt are relevant here. Lightmouse 10:03, 11 October 2007 (UTC)
MOS:NUM#Unit symbols and abbreviations says "Use kn to abbreviate knot rather than kt or kts". I've changed the one use of kt to kn (as input code in transclusions of the template). The template now accepts kn as input. It's time to depreciate kt as an acceptable code. Jɪmp 23:32, 15 November 2007 (UTC)
Next archive→
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_January_to_October_2007&oldid=1115555527"