Template talk:Convert/Archive May 2008

Non-breaking space

Probably an obvious answer, but does this template enter a non-breaking space [ ] between number and unit? I believe this is best practice.  — MapsMan [ talk | cont ] — 18:04, 3 May 2008 (UTC)

Yes it does. You can expand the template using Special:ExpandTemplates and see what the output (what is actually used by web browsers) looks like. — Huntster (t • @ • c) 18:21, 3 May 2008 (UTC)

I hope that it does not use nbsp when using names in full. Lightmouse (talk) 18:33, 3 May 2008 (UTC)

It shouldn't. I'll have to make sure it doesn't. JIMp _talk·cont 18:50, 3 May 2008 (UTC)

Thanks. Non-breaking spaces are a curse on small screens. Lightmouse (talk) 14:19, 4 May 2008 (UTC)

Pferdestärke (PS) and power-to-weight ratio

I believe Pferdestärke (PS) and power-to-weight ratios are absent from the list of conversions. I don't know what the policy was for these, but they are both used on most car articles, and other forms of transportation, too, I'm sure. —Mr. Grim Reaper at 23:37, 6 May 2008 (UTC)

Power-to-weight is absent. Use PS for metric horsepower, e.g. {{convert|1000|PS}} gives "1,000 metric horsepower (740 kW)". JIMp _talk·cont 23:54, 6 May 2008 (UTC)

What units do we want? I'm guessing we'll need horsepower per pound, metric horsepower (Pferdestärke) per kilogram and kilowatts per kilogram (or can we not just call it watts per gram?). Is there any other unit to convert? JIMp _talk·cont 01:23, 7 May 2008 (UTC)

I don't suppose you can convert to multiple units? I read the documentation a bit more throughly this time. As for power-to-weight, horsepower per [short] ton, metric horsepower per tonne, and kilowatts per tonne. The others don't seem to be useful for cars. Perhaps other things? —Mr. Grim Reaper at 01:44, 7 May 2008 (UTC)

Okay here are the numbers I'm going to use. Please check my maths.

1 hp/lb	= 33,000 ft·lbf/min·lb
	= 550 ft·lbf/lb·s
	= 550 × 0.3048 m × 9.80665 m/s²·s
	= 1643.986806 kW/t
1 hp/ST	= 1643.986806⁄2000 kW/t
	= 0.821993403 kW/t
1 hp/LT	= 1643.986806⁄2240 kW/t
	= 5.13745876875⁄7 kW/t
	≈ 0.733922681 kW/t
1 PS/t	= 75 kgf·m/s·t
	= 0.075 m·kgf/kg·s
	= 0.075 m × 9.80665 m/s²·s
	= 0.73549875 kW/t

JIMp _talk·cont 08:09, 7 May 2008 (UTC)

Okay kW/t, PS/t, hp/LT & hp/ST are all ready to go. I'll get working on the conversions to multiple units later. JIMp _talk·cont 08:39, 7 May 2008 (UTC)

Temperature conversion significance

To convert a medical temperature of 109 F, you want a 3 digit C figure: 42.7 C. However, to get this, you need to enter sigfig=4, not sigfig=3: thus: 109 °F (42.78 °C). I do not think this agrees with what the article page says should be happening:

Default rounding

If neither the desired precision nor the desired number of significant figures are specified, the conversion will be rounded either to a comparable precision as the input value (the number of decimals remains the same if the conversion is a multiplication by a number between 0.2 and 2, is decreased by 1 if the factor is between 2 and 20, etc.) or to two significant figures whichever is the most precise. An exception to this is temperature wherein the conversion will be rounded either to precision comparable to that of the input value or to that which would give three significant figures when expressed in kelvin, whichever is the most precise.

That's not what's happening, so far as I can tell.

SBHarris 02:12, 8 May 2008 (UTC)

The problem is with talking about significant figures when you've not got an absolute scale. Take 42.78 °C, can we really say that this has four significant figures? 42.78 °C is 315.93 K. You can sensibly count the number of significant figures in 315.93 K. It has five. What sense would it make to say that 42.78 °C has four significant figures whilst 315.93 K has five? This is an issue which has already been mentioned albeit very briefly. Thus you might call it 042.78 °C with a significant leading zero ... but that's not quite right either. So instead of trying to attach meaning to significant figures in non-absolute temperature scales, the template was designed such that for temperatures the sigfig parameter would give a rounding comparable/identical to that which would give the specified number of significant figures when the temperature is expressed in kelvin. So that's the explanation for the apparant error, not that is has to be this way. JIMp _talk·cont 06:47, 8 May 2008 (UTC)

Square kilometre, hectare, acre

Would it be possible to have km2, ha, and acre together? Lightmouse (talk) 19:58, 8 May 2008 (UTC)

Do you mean conversions like "25 square miles (64 km²/6,400 ha/16,000 acres)"? Sure but is there a use for conversions to both square kilometres and hectares? JIMp _talk·cont 00:10, 9 May 2008 (UTC)

Actually I had only considered two target units "4000 acres (16 km², 16,000 ha)" rather than three target units. If you provide ha only, dunam only, or quintal only, then it is not widely accessible to ordinary people (even though the arithmetic conversion is trivial if you know it). If you provide km² only, then that is usually ok, but there are one or two specialist domains where 'follow current literature' seems to be the model. Editors say things like km2 is not a relevant unit of measure for vineyards or professional wine literature does not use it etc. I know you are familiar with those sorts of claims. I was hoping that in certain circumstances, a compromise could be reached by providing both. Lightmouse (talk) 01:04, 9 May 2008 (UTC)

Ah, how have I not found this thread earlier? Lightmouse, I disagree with most of your line of thought. In order, 4000 acres is 1,600 ha not 16,000 ha. It seems you may not be too familiar with the hectare? Please allow input from those who are. The hectare is not at the same level of usage and acceptance as the dunam or quintal and it is misleading to suggest so. The hectare is widely used and accepted for most land area measurement needs in most metricated countries and is fully accessible to ordinary people. Providing km² is usually ok, but usually for land area hectares are the source unit, commonly used and understood, and closer in value to the acre (if the acre is the unit being converted from) than the km². The model is not one or two specialist domains. In Australia for example, most land area measurements are in provided in hectares. Not only is it 'follow current literature', it is usually the source unit and the commonly used unit. New Zealand is the same. I don't understand why you want to use units that are usually not the source, not commonly used in that context and not used in current literature.

Yes, you may correctly sense, I have issues with the use and abuse of the hectare in Wikipedia. Many articles have been written using hectares as the natural unit of land measure only to be subsequently changed to km² without any consideration or justification, often with loss of precision in the conversion. Yes, it was one particular editor. With great generosity these edits could be described as unhelpful. I describe it as the "excision of hectares from Wikipedia". It has left a large number of articles looking awkward and less accessible. The work of excision by this one editor does not reflect common usage.

Try this - If the area is expressed in acres the most acceptable metric conversion is usually hectares.

I agree with JimP; Sure but is there a use for conversions to both square kilometres and hectares? I can't imagine a need for both km² and hectares. Hectares are usually sufficient. Bleakcomb (talk) 00:50, 12 May 2008 (UTC)

I see where you're coming from Lightmouse and if people do think a conversion to both square kilometres and hectares would be useful, I'm not going to be so stubborn as to refuse to write the subtemplate. However, I'm of the opinion that if there exists two units where the conversion between them is merely a multiplication by an integer power of ten (bytes, kilobytes, megabytes, etc. excluded) we should generally not include both. Having both seems to me to be unnecessary clutter. If hectares are unfamiliar, then we should use square kilometres (or square metres) instead. However, I don't believe that they are ... but Bleakcomb and I are both Sydneysiders so it might be helpful to have a perspective from other parts of the metricated English-speaking world. JIMp _talk·cont 01:18, 12 May 2008 (UTC)

A suggestion

I notice that conversion options are becoming more complicated with things like 'ft|in'. I have been thinking about making things more wysiwyg. What do you think of migrating to following grammar:

• parentheses around the target unit i.e. (m) would do the same as |m}}
• square brackets around the target unit i.e. [m] would give square brackets in the output
• a space would separate a combined unit such as 'ft in' or 'st lb'
• multiple target units could be handled by using commas i.e. (m,yd) and [m,yd,ft in]
• ranges could be handled by 'range=' with valid terms such as 'to', '-' etc

What do you think? Lightmouse (talk) 20:59, 8 May 2008 (UTC)

I like your idea for a more human-friendly grammar for the conversion functions. I'm not sure I understand your proposal completely, so could you knock up a couple of examples? I think this would be a good test of whether your proposed grammar is consistent and intuitive: Can a working understanding of how to construct conversion markup be had by looking briefly at a couple of examples? —Scheinwerfermann (talk) 21:17, 8 May 2008 (UTC)

I was deliberately vague because I had a concept but was not sure of the detail. It could be something like:

• {{convert|160|ft (m)}} would produce '160 feet (49 m)'
• {{convert|160|ft [m]}} would produce '160 feet [49 m]'
• {{convert|160|ft (m, yd)}} would produce '160 feet (49 m, 53 yd)'

Not sure about the rest, but I hope that is a start. Lightmouse (talk) 22:26, 8 May 2008 (UTC)

Thanks for the examples. On the one hand, I like the parity between the markup and the result. On the other hand, there are always problems with a stackup of opening or closing parentheses/braces/brackets. So I'm not sure this what you're proposing in its current form would necessarily be an improvement. We can't get around the }} closer at the end of the structure, which means with your proposal we can't get around the )}} at the end of the structure, which means there would — mark my words — be a lot of cleanup required by people who get the closing punctuation wrong. This is not to shoot down the idea wholesale, but I don't think this particular implementation solves more problems than it creates. —Scheinwerfermann (talk) 23:38, 8 May 2008 (UTC)

I can see what you mean about )}}. Well never mind. Perhaps I will move on to my next bright idea. Lightmouse (talk) 23:45, 8 May 2008 (UTC)

It would be possible, of course, but also consider this. Each unit expression you input as a parameter has to be treated as a seperate string. Let's say you want conversions between kilojoules, calories, watt-hours, British thermal units and foot pounds-force. With the current set up this can be achieved using five unit subtemplates. The way you're suggesting will take twenty. The situation gets worse as the number of units increases ... n² - n verses n to be exact. Of course, you might not want conversions from foot pounds-force to calories. Going back to the example, if we only want conversions to or from kilojoules, that's still eight subtemplates. Note that this is not simply a product of using subtemplates, you'll run into similar problems if you try using switches (like in Drum Guy's version). Things become much worse if you want to throw output formatting (i.e. square brackets verses round brackets verses slashes etc.) into the input unit codes. I hate to say "No." but this seems to be a lot of work for not that great a gain ... {{convert|160|ft (m)}} is actually two characters longer than {{convert|160|ft|m}}. As for ranges, I think I've got something in the works that might even be more human-friendly than introducing a new parameter called range ... it will be using the dreaded pipes though. JIMp _talk·cont 00:05, 9 May 2008 (UTC)

I don't understand it all but I have understood that it is too complicated. Thanks for the response. (alternating indents to make page legible on small screens) Lightmouse (talk) 00:21, 9 May 2008 (UTC)

Who decided that the indents should just keep growing in the first place? Small screens, yeah, good point but if that were no concern, having each editor have a fixed indentation per thread would have been a good way of going about things ... I'd have a double intent, being the third in this thread ... difficult, of course, when you've got more than half a dozen editors on a thread. JIMp _talk·cont 00:52, 9 May 2008 (UTC)

Display suggestion

It would be cool to have "disp=or" and "disp=;" as options in addition to disp=/. For example, (25 sq mi or 65 km²) or with disp=; (25 sq mi; 65 km²). Although, truthfully, I don't know if the second semi-colon one is grammatically correct. There seem to be occasions when the word or would be better than a slash /. —MJCdetroit ^(yak) 00:38, 9 May 2008 (UTC)

That would be cool, yes. It's on the to-do list ... somewhere. JIMp _talk·cont 00:45, 9 May 2008 (UTC)

I just use a comma. I do not like the slash because it is part of the lexicon of units. You can get unwanted examples like this: (92 ft/s/28 m/s). Lightmouse (talk) 01:16, 9 May 2008 (UTC)

Yeah, that's an unfortunate hang-over from the old version. JIMp _talk·cont 01:21, 12 May 2008 (UTC)

Square brackets

Is it possible to do square brackets? For example, I might want to produce '160 feet [49 m]'. Lightmouse (talk) 23:47, 8 May 2008 (UTC)

It's possible. Consider it on the to do list. JIMp _talk·cont 00:05, 9 May 2008 (UTC)

Thanks. (alternating indents to make page legible on small screens) Lightmouse (talk) 00:22, 9 May 2008 (UTC)

The nmi -> mi conversion seems to be way off

200 nmi = ~245 mi, not ~230 mi, unless I'm losing my mind can can't work a calculator tonight.

No, 200 nautical miles does equal approximately 230 miles. —Mr. Grim Reaper at 16:55, 10 May 2008 (UTC)

Seconded: 200 nmi = 230.15589 mi. — Huntster (t • @ • c) 22:30, 10 May 2008 (UTC)

Please make nmi conversion match all other conversions

The nmi conversion produces two target units by default. All the other conversions produce only one target unit. Please can nmi match the rest. Lightmouse (talk) 11:31, 10 May 2008 (UTC)

And so which unit would you convert to...just miles...just kilometres? Nautical miles are fairly unknown to everyone, so I see it as a need for better clarification and translation into units everyone can relate to. — Huntster (t • @ • c) 23:07, 10 May 2008 (UTC)

It should match all the other conversions.

• Non-metric source -> metric target.
• Metric sources -> non-metric target.
• The template permits multiple target units and nmi should not be an exception. Lightmouse (talk) 23:22, 10 May 2008 (UTC)

So you find it irrelevant that most people won't have a clue what a nautical mile is in relation to a regular mile? Sure, you might link to the article for it, but that still doesn't provide a ready context for the numbers (the common reader will have to find some other, likely external, means to convert nmi to mi if it isn't done here), and many people, including yourself, choose to not link to "common" units (and some editors may have a significantly different view of what "common" is). — Huntster (t • @ • c) 00:00, 11 May 2008 (UTC)

No, I think you misunderstand me. I did not answer your point directly and I think that has frustrated you.

I agree with you that nautical miles are fairly unknown to everyone. It is indeed relevant whether a unit is common, uncommon or even obscure. If wp:mosnum policy is that conversions of units (such as ice-tons and furlongs) should generally be double target, that is fine by me. The template already has a mechanism for double target that can do it.

Personally, I tend to prefer not to build business rules into technical tools. Either way, I just want the template to be consistent. Your point about obscure-to-all units is well made. I would like one mechanism to address the issue, not two mechanisms. Each time we make an exception or duplication of mechanisms, we make the tool less predictable and less transparent. Lightmouse (talk) 00:15, 11 May 2008 (UTC)

I see where you're coming from Lightmouse and think you've got a good point. However, there are others which have multiple conversions as the default. For example, tonnes goes to long and short tons, and litres to imperial and US gallons. It wouldn't be so simple to bring those in line without introducing some sort of bias. JIMp _talk·cont 01:49, 12 May 2008 (UTC)

I did not know that mandatory multiple conversions existed elsewhere. Oh dear, I am disappointed. Let us just take the litre-to-gallon conversion: the imperial gallon is used in history and in a couple of current domains but elsewhere it has almost vanished. What do I do if I want to convert the litre to US gallons without imperial gallons? A similar point applies to long and short tons. We cannot assume that each time a conversion is made, the old imperial version is needed in the article. I appreciate all the work that you do and I would just ask for the following item to be put on the wishlist:

• Where a multiple mandatory conversion exists, please provide a single conversion option.

Thanks. I hope my disappointment has come across clearly :) Lightmouse (talk) 19:10, 12 May 2008 (UTC)

Lightmouse, oh, I wasn't frustrated, but simply wasn't able to properly express my thoughts, I guess. Jimp said it better than I could: if we try to limit, by default, each non-standard conversion to a single unit, I'm concerned that it would appear that a bias of sort is being introduced...either to those who are used to U.S. units, or to those who prefer Metric units. While it would be preferable for the world-community to adopt Metric as a whole, I think we can all agree this won't happen any time soon, so I don't believe forcing what may appear to be a viewpoint would be beneficial. I agree you bring a good point, but I still hold that having the dual conversions helps clarity, which I feel should always be the goal of an encyclopedia. — Huntster (t • @ • c) 19:18, 12 May 2008 (UTC)

Thanks for your further comment. I think I had just become so used to the convert template that it had not even entered my head that it would do anything other than convert to km. I was quite surprised that this dual conversion was being done and possibly also surprised at myself for not having seen any discussion about it. I am sure that somebody somewhere might suggest it is bias but I think the concept of non-metric -> metric predates the nautical mile conversion. Plus the nautical mile is a natural pairing with the statute mile.

I have no objection to the goal. Perhaps I might have liked to have been involved in crafting the solution to achieve the goal.

I agree with you that 'clarity' is a good goal. Other good goals include 'accessibility' and 'understandability'. I believe that these rank much higher than 'familiarity', 'official' and 'used by specialists'. Thus I think it is more accessible if a Wikipedia article says that the atlantic is 'x statute miles wide' or 'y kilometres wide'. This is better than saying 'z nautical miles wide'. Lightmouse (talk) 19:40, 12 May 2008 (UTC)

I absolutely agree that where you can easily use another unit besides the non-standard one, you should, but there will remain many circumstances where the cited figure is in nautical miles (or whatever), or that unit is the one primarily used in a particular application (I see nmi a lot in space-related material, and think about the specialist oil units that have been discussed at length on this page, not that those particularly needed a dual conversion). — Huntster (t • @ • c) 20:10, 12 May 2008 (UTC)

Yes. Lightmouse (talk) 20:20, 12 May 2008 (UTC)

Actually, I think only NASA uses nautical miles for space, everybody else is metric I think. For some reason, NASA uses nmi for *vertical* distances and frequently it gets quoted just as 'miles'. As you might expect, these get mistaken for statute miles. Lightmouse (talk) 20:30, 12 May 2008 (UTC)

I think part of the confusion here is that people assume that the nautical mile is not a metric unit. In fact, it is one of the non-SI metric units. It is not in general use by landlubbers, but it is the unit most commonly used in marine and aircraft navigation. One nautical mile is one minute of latitude, making it quite easy to measure from the latitude scale on a nautical chart with dividers. It used to vary slightly since the earth is not perfectly round, from 1851 metres to 1853 metres, but it is now defined as 1852 metres, exactly. People in the U.S. assume that if a unit is not metric it must be a U.S. unit, but in fact different countries all used to have their own unit systems. The Norwegian mile, for instance, was about 6.2 English miles long. Some of these non-metric non-US units are still in use. If someone orders a pint of beer in an English pub he will get one about 20% bigger than a pint in an American bar. However, if someone talks about a mile, he could mean the U.S. statute mile (same as the English mile), or the universal nautical mile. Kilometres are much less ambiguous. RockyMtnGuy (talk) 20:55, 12 May 2008 (UTC)

The nautical mile is a non-metric unit but as you say, it is defined as 1852 metres. As I understand it, the minute of arc on our aspherical earth can vary by many tens of metres. The UK adopted 1852 m in the 1970s, I understand. The US adopted 1852 m in 1954, and also changed the size of the inch, foot and yard and became aligned with the UK. See the official document at: [http://www.ngs.noaa.gov/PUBS_LIB/FedRegister/FRdoc59-5442.pdf

http://www.ngs.noaa.gov/PUBS_LIB/FedRegister/FRdoc59-5442.pdf] Lightmouse (talk) 18:41, 13 May 2008 (UTC)

Symbol for acre foot

I note that there is no symbol provided for acre feet. A web search reveals that 'af', 'ac-ft' and 'acre-ft' are in use. There may be others. I would suggest that matching ft.lbf would be a good idea. Thus 'acre.ft' or the middot equivalent. What do people think? Lightmouse (talk) 00:29, 11 May 2008 (UTC)

I think that the period/dot is incorrect in ft.lbf. It should should be a mid dot (ft·lbf). Therefore, acre feet = acre·ft, would be ok with me. —MJCdetroit ^(yak) 01:10, 12 May 2008 (UTC)

The dot (full stop) is only the input code, the output is the mid dot. I agree, let it be "acre·ft". JIMp _talk·cont 01:53, 12 May 2008 (UTC)

Done. I've also added the codes acre.ft, acre.foot, acre·ft and acre·foot in keeping with the other such units. JIMp _talk·cont 02:02, 12 May 2008 (UTC)

Thanks. You are a star, Jimp. I have not commented on the middot debate but I have read some of the stuff that has been said. Gene Nygaard seems very keen on it but I can't get excited about it. The middot is easy to do in a script but the period is easier when doing things by hand. There is a parallel with the 'sq unit' versus m² issue. Anything that is available on a single button press on a keyboard has an advantage. I will try to give the middot a higher priority when writing something visible to the reader. Lightmouse (talk) 19:21, 12 May 2008 (UTC)

Fractional miles

The fractional value feature is cool. Is there any chance of extending the functionality to miles? That would be miles to km and miles to metres. For example {{convert|0+3/8|mi|m}} or {{convert|1+1/4|mi}}. Bleakcomb (talk) 00:26, 13 May 2008 (UTC)

Will look into it. JIMp _talk·cont 08:19, 14 May 2008 (UTC)

A request to remove the output precision exception for 1 sig fig

The default for the template is that it matches significant figures. That is a good design concept. However, there is an exception for 1 input values of 1 sig fig where the output is 2 sig fig. Exceptions to good design concept should only be done if there is a very strong reason. I have always considered that this 1 sig fig exception does not have a strong enough reason. The reason has been given as 'to maintain accuracy' or something like that. But the accuracy or precision in 1 sig fig is no more constant than it is in 2 sig fig or n sig fig.

Here is a good example from my talk page of where the exception is not working:

• When you add the {{convert}} template to articles, please consider the appropriate precision. For example, converting 100 yards to 91 metres (e.g. Bay Horse railway station and many others) is appropriate only if the original measurement was accurate to the nearest yard. In most cases like this the appropriate conversion would be "100m" (which hardly seems worth including at all). --Dr Greg (talk) 12:32, 12 May 2008 (UTC)

• You are quite right. The precision inherent in that '100 yards' conversion is better as '100 m' than as '91 m'.

• It is worth including because there are many people that do not know what '100 yards' means. There are thousands of unconverted values in need of conversion. Precision can always be tweaked once the conversion template is included. Thanks for fixing that. Regards Lightmouse (talk) 17:57, 12 May 2008 (UTC)

• What I am suggesting is that, in the future when you add the template, in the absence of any contrary indication, you should assume that "200 yards" (e.g.) is accurate only to the nearest 100 yd and put the appropriate precision specifier (-2 in this case) yourself. --Dr Greg (talk) 11:43, 13 May 2008 (UTC)

I happen to agree with Dr Greg. I did that '100 yard' conversion using my script. Now my script is pretty dumb and cannot always get the most appropriate precision (precision is always part-art and part-science). So this problem will not ever go away, but I think it would be easier for others to accept if it were consistent sig fig matching as per the good design concept. I can recode my script to undo the exception but code to negate code seems wasteful. I would much prefer it if the good design concept was applied without exception. Please can this be considered? Lightmouse (talk) 17:33, 13 May 2008 (UTC)

I'm not opposed to such a change. The exception was put in in an attempt to avoid inaccuracy but I've got to admit that false precision is no less a concern. It seems to me that no algorithm could truely be expected to balance these fairly. I've often found myself manually reducing the number of significant figures in {{convert}}'s output to one to avoid this inbuilt feature. However, I can easily imagine myself doing the opposite if the feature is removed. What are other's thoughts on this? JIMp _talk·cont 08:18, 14 May 2008 (UTC)

This wan't quite making sense so I mapped some of the values in question and put them in a table. Apologies in advance for the table clogging up a talk page.

default		avoid		sigfig=1		0		-1		-2
yds	m	yds	m	yds	m	yds	m	yds	m	yds	m
99	91	99	91	99	90	99	91	99	90	99	100
100	91	100	90	100	90	100	91	100	90	100	100
101	92	101	92
102	93
103	94
104	95
110	100
200	180			200	200	200	183	200	180	200	200

I can understand now the inconsistency that the template tweak is trying to avoid (the "avoid" column). With (91 m) or without the tweak (90 m) seems OK, but I think the tweak adds some value in some situations. So, slightly in favour of the tweak. Removing the tweak, as far as I can tell, won't give what Dr Greg is talking about (100 m). He is talking about situations and only certain situations, rounding to one less significant digit. To do this he asks that the editor place a precision modifier of "-2" in the template call. Fair enough. Lightmouse, I don't think it is reasonable to make an additional change to the template beyond just removing the tweak to accommodate this as the default case. I don't know that 100 yds or 200 yds is most likely to have a precision to the nearest 100 yds in cases where the precision is not stated. Others have said before that determining appropriate precision almost always requires judgement and in some cases consensus. It is unreasonable at this point to envisage a script doing this, so inserting a conversion via the convert template using a script will require human follow-up. Although, if a problem is found, just fix it, it is probably polite for those who use the scripts to organise the checking. Bleakcomb (talk) 04:33, 15 May 2008 (UTC)

Thank you, Bleakcomb. I see now that you are quite right. The 'tweak' as you call it, changes 10 metre precision into 1 metre precision. That would not be enough for Dr Greg because he wants 100 metre precision. I am not calling for anything to resolve that problem. So I withdraw my suggestion that Dr Greg's complaint is an identical issue. However, I think if the conversion had said 90 metres instead of 91 metres, it would have been less brutal for him. Furthermore, it is often easier to defend the limitations of a tool that is simple yet consistent than one that has carefully crafted inconsistencies that sometimes make things worse. Thus I am still asking for removal of the 'tweak'. Warts and all, I still think the template has helped Wikipedia become much more accessible. Lightmouse (talk) 15:10, 15 May 2008 (UTC)

An exceedingly angry user: note citation of enforced dual target units

My unhappiness with enforced dual target units (see section above about nmi) is shared by another user. Please see Wikipedia_talk:Templates_for_deletion#Automotive_templates:_Template:Auto_hp_and_others. His unhappiness extends well beyond that issue. Please take a look. I think we all need to. Lightmouse (talk) 18:10, 13 May 2008 (UTC)

You're trying to piggy-back your issue of having nmi converted into km or mi but not both onto this guy's tirade. If you read his tirade, it sounds like he says the complete opposite of your enforced dual target argument. He wants miles per gallon-US to convert to mpg-UK and km/L. The whole reason for his tirade is because someone TfD'd one of his "auto" convert templates a month ago and Lightmouse and myself voted in favor of it being deleted. He is afraid that someone, in his words may "convert miles per hour into lightyears per teaspoon" using this template. Whatever... —MJCdetroit ^(yak) 20:57, 13 May 2008 (UTC)

Indeed I was trying to use his comments in support of a point I made. I did not understand the detail of what he was saying (although I think his main point was clear). Thus it is entirely possible that I misunderstood it to be the opposite and he is actually citing single unit target as a bad feature of convert template. However now that you have made me think about it, I looked at just one auto template at Lamborghini Murciélago and saw the use of {{auto mpg|8}}. The produces '8 miles per US gallon (29 L/100 km; 9.6 mpg_‑imp)' so it would be bizarre for him to say that auto does dual and convert does single. I have not investigated the fuel efficiency templates further. What do you think?

Incidentally, fuel efficiency is an area where I would think that dual target would be appropriate in many cases. I just object to dual target being an inconsistent and a mandated exception that applies to all instances regardless of what any editor actually wants in a particular article. Of course, his main point is rather larger than that. Lightmouse (talk) 21:27, 13 May 2008 (UTC)

Sorry LM, I agree with sometimes but I don't this time. I agree with Huntster, nmi is fine how it is. BTW {{mpg|12}}-->12 miles per US gallon (20 L/100 km; 14 mpg_‑imp) that's my average mileage in my one SUV:( but it's paid for :). —MJCdetroit ^(yak) 01:15, 14 May 2008 (UTC)

This is certainly a concern but, no, I don't read Steve Baker as being concerned with the dual default outputs on {{convert}}. JIMp _talk·cont 08:04, 14 May 2008 (UTC)

I have reread it. I agree now that he was complaining (incorrectly) that convert does not have an option for dual target units. I have no problem with the *option*. I see that there are {{auto mpg|12}} and {{mpg|12}} templates. MJC, I would be horrified if that is what I was consuming. Lightmouse (talk) 21:22, 14 May 2008 (UTC)

By the way, is there any interest in a conversion to and from lightyears per teaspoon ... it could be added? JIMp _talk·cont 00:52, 15 May 2008 (UTC)

I'm not even going to ask how such a conversion would work, but as a bit of an easter egg, might as well have some fun with it :) — Huntster (t • @ • c) 02:16, 15 May 2008 (UTC)

And while you're at it, how about converting the post-Star-Trek megaparsecs per microsecond to the British snail-friendly furlongs per fortnight. But only after converting pecks of Polish pickled peppers to billions of British beer barrels. And don't forget the metric myrametre (most people do). RockyMtnGuy (talk) 02:43, 15 May 2008 (UTC)

1 megaparsec per microsecond = 1.85538397×10^32 furlongs per fortnight and 1 peck = 0.0750740156 beer barrels. Oh, how I love thy esotericness, Google. Thou art my friend. As is {{convert}}. But I think you are joshing about the myrametre...only seven ghits using both British and American spellings, and they don't convert it, lol. However, this says 1 myrametre = 10 km, so who knows. Need moar citation! — Huntster (t • @ • c) 04:50, 15 May 2008 (UTC)

Unfortunately I (and the reference you cited) misspelled it. It should be the myriametre, which is 10,000 metres. (See non-SI unit prefix#obsolete prefixes). Sorry about that. Now, the myriametre is only of modern significance because it is still in use as the Norwegian mile. I personally flew to Norway, found two milestones, paced off the distance between them, and confirmed it was 10 kilometres, but I can't use that in a Wikipedia article because that would be considered original research. However, they often do measure fuel economy in litres per mile (L/mil) so we may need another conversion for our friends in Scandinavia. (Just kidding - I think furlongs per firkin is more important).RockyMtnGuy (talk) 16:27, 15 May 2008 (UTC)

I did note that the joke unit 'lightyears per teaspoon' is a direct comparision with miles per gallon as length/volume. He could have chosen the usual joke unit 'furlongs per fortnight' but the extra trouble he took made the joke a bit funnier. On a more serious note, see what others have said about the deletion of auto templates at: Wikipedia_talk:WikiProject_Automobiles#Auto_Templates_Deletion. Lightmouse (talk) 09:13, 15 May 2008 (UTC)

On a more serious note, there are a few issues here that I can see here:

• The Auto templates have some problems. For instance, the standard abbreviation for metric fuel economy is L/100 km. Some templates return l/100 km which was depreciated because it is hard to distinguish a lower case l from the numeral 1. And the proper abbreviation for cubic centimetres is cm³, not the depreciated cc. We won't even talk about CID for cubic inch displacement.
• Nobody in the world sells fuel in imperial gallons any more, that I know of. It's an obsolete unit, like cubits. The U.K. and all of its former colonies (except the U.S.) have converted to metric. So why does anyone want to calculate fuel economy in imperial gallons per mile? It should be miles per gallon (U.S.), or litres per 100 km (the rest of the world). MPG should mean American miles per American gallons.

From Gallon definitions subheading:

The Imperial gallon continues to be used as a unit of measure for fuel in Antigua and Barbuda, Belize, Burma, Grenada, Guyana, Sierra Leone and the United Arab Emirates.

I also found this from the Antigua Sun last month stating the following:

WIOC recently informed APUA that the price of diesel had moved from $9.31 to $10.25 per imperial gallon and fuel oil from $6.12 to $6.35 per imperial gallon.

Somehow, I don't think it's as obsolete as you belive. :-)Beachgrinch (talk) 19:59, 16 May 2008 (UTC)

• All automobile companies now design their cars in metric and then soft-convert them to U.S. units in the brochures for the U.S. market. They all have international operations, and don't want to connect their German transmission to their U.S. engine in their British automobile to find that the bolt holes don't match up. But if someone wants to know how big the engine is in cubic inches, and has the money to buy the car, they're willing to convert the numbers.

The British Empire is dead and the American Empire is dying. Get used to it.RockyMtnGuy (talk) 19:07, 16 May 2008 (UTC)

I nominate User:Lightmouse to be banned along with his metric "conversions"

I am sick of fixing the messes left behind by Lightmouse and his brainless metric conversions, e.g. involving WWI British ordnance. An example :
Originally on page Artillery :
[[Image:Gasmasked artillerymen.jpg|thumb|325px|Australian gunners, wearing [[gas mask]]s, operate a [[BL 9.2 inch Howitzer|9.2 inch howitzer]] during [[World War I]].]]
After change using AWB on 12th March :
[[Image:Gasmasked artillerymen.jpg|thumb|325px|Australian gunners, wearing [[gas mask]]s, operate a [[BL {{convert|9.2|in|mm|sing=on}} Howitzer|9.2 inch howitzer]] during [[World War I]].]]

Spot the mistake ?. There are four things wrong about this : First, such a sensitive and potentially complicated update should be done manually, not via automation - the potential to damage many pages is big. Nobody bothered to check results after this example. Secondly, the choice of appropriate conversion parameters requires some thought and familiarity with the subject of the page. Converting an approximate gun range of say 25000 yards to metres requires sigfig=3; converting a gun's calibre e.g. 9.2-inch, requires sigfig=4 or even 5 as 9.2 inch here is an exact measurement. Likewise converting a 100lb artillery shell to kg requires sigfig=4, as again 100lb here is an exact measurement, not an approximation. Thirdly, these conversions do not add any content to Wikipedia, they just clutter up the page. Any idiot who is really interested in the topic can whip out his calculator to do the conversion himself. Fourthly, it is traditional in historical writing to use the units of measurement in use by the subject under discussion at that time. If the subject dealt in imperial units, that is the correct unit for the discussion i.e. the Wikipedia page content. British gunners in WWI did not talk about a 100 lb (45kg) shell or a 9.2 inch (233.68mm) gun. To introduce metric conversions, and badly done conversions at that, is ahistorical. Rcbutcher (talk) 15:38, 16 May 2008 (UTC)

And kudos for spending the time to "ban a user" and not bothering to fix the error you noticed from March. It took less than 30 seconds. -- KelleyCook (talk) 20:20, 16 May 2008 (UTC)

This is not the forum to ban users. Lightmouse hasn't done anything ban-worthy. I don't see that he's even done anything harmful at all.

1. There is potential for error if the conversion is done manually too.
2. The number of significant figures is easy to change using the template (had the conversion been done manually, it'd have to be redone).
3. I'd prefer a little clutter to being forced to whip out my calculator every time a measurement is given.
4. The original units remain the prime units. The conversions are added for the benifit of today's reader. British gunners in WWI didn't talk that way, no, but we are writing now not talking then.

JIMp _talk·cont 17:43, 16 May 2008 (UTC)

It's been my experience that young people in the former British colonies which have converted to the metric system no longer understand the imperial system, since they no longer learn it in school. Hence, when you talk about a "9.2 inch howitzer", they say "What?" But if you tell them it's a 9.2 inches (230 mm) howitzer, they realize it's almost the equivalent of the French 240 mm howitzer of the same period. As far as accuracy is concerned, more decimal places don't help. The ubiquitous (in the U.S.) .38 caliber handgun shoots a bullet that is actually 0.357 inches in diameter (and the .357 magnum shoots the same size bullet with a lot more gunpowder.) Calling it a .357 inches (9.1 mm) conveys the fact that it is almost the same size as the ubiquitous (in the rest of the world) 9 mm parabellum. However, all these gun sizes are nominal sizes rather than actual ones so a conversion template really can't handle it. RockyMtnGuy (talk) 18:12, 16 May 2008 (UTC)

I'm from a fromer colony. I don't call myself young but that's a relative term. I didn't learn the imperial system at school. I've got a fair idea of imperial quarts, pints, ¾ pints, ½ pints and ounces form drinking beer and scotch in the pub but otherwise I think in metric. Good point about the sizes' being nominal though. JIMp _talk·cont 18:20, 16 May 2008 (UTC)

Case in point. However (and this is totally off topic but why stop now), I was ordering beer in a pub in Canada, and the menu said, "We serve an 18-ounce pint of beer". Now, since the American pint is 16 ounces, the British pint is 20 ounces, and there were large numbers of Americans and Brits in the restaurant, I came to the conclusion that this was kind of a "world average pint" of beer. However, it left open the question, "American ounces or British ounces?" because the British ounce is 0.96 American ounces. Since Canada is on the metric system, I'm betting it was a half-litre pint of beer, on the principle that "you can call it whatever you want as long as you pay for it with hard currency".RockyMtnGuy (talk) 19:49, 16 May 2008 (UTC)

What the OP was probably so steamed about, but didn't express well was that the conversion was made to the name of a weapon and actually to the name of the linked article in the link, not on the piped side of the link. This of course broke the link, which is not a completely useful edit. Not a hanging offence though, I would have thought. RockyMtnGuy raises the point that some weapon sizes are nominal measurements not necessarily accurate measurements of anything to do with the weapon or its ammunition. Because of this I have (very clumsily) removed the conversion from the link altogether along with some unrelated apparent vandalism. The target article for the 9.2 inch Howitzer thingy is probably the best place for any conversions.
I agree with KelleyCook; if ya don't like it - revert it and perhaps leave a polite message on the user's talk. I am sure it wasn't the template's fault. Apart from article names not being appropriate places for unit conversions, JimP's 4 points says it well. Bleakcomb (talk) 03:43, 17 May 2008 (UTC)

The problem with unit conversions not giving the real picture is pervasive with all kinds of guns. If you take the 7.62 mm Nato round, that would convert to 7.62 millimetres (0.300 in). That's misleading, because it actually has the same dimensions as the .308 Winchester. Similarly, converting the 5.56 mm Nato, the standard M16 round, gives 5.56 millimetres (0.219 in) which gives no indication that it is the same size as the .223 Remington. The difference occurs because in one case they're measuring the diameter of the barrel, and in the other case the diameter of the bullet. And some of these British guns are just untranslatable. For instance, converting the WWII British 17 pounder to metric - 17 pounds (7.7 kg) - gives no indication whatever that it is an antiaircraft/antitank gun in the same class as the dreaded German 88 mm gun.RockyMtnGuy (talk) 16:03, 17 May 2008 (UTC)

Kilo-, Mega-Parsec

Could you please add kiloparsec (kpc), megaparsec (Mpc) and maybe gigaparsec (Gpc) for distances to galaxies and stars? And something similar for lightyears as well. Because things like 57,000,000 parsecs (190,000,000 light-years) don't look well. —Bender235 (talk) 10:52, 22 May 2008 (UTC)

Done. JIMp _talk·cont 14:09, 23 May 2008 (UTC)

Thanks. Now I might add this to Template:Convert/list of units/length. —Bender235 (talk) 15:09, 23 May 2008 (UTC)

Stone (weight)

Please change Stone (weight) to Stone (mass). --Zimbabweed (talk) 21:23, 22 May 2008 (UTC)

Done. JIMp _talk·cont 14:09, 23 May 2008 (UTC)

Parenthesese, right and wrong

A few users have complained that conversions are wrong because they do not agree with the precision. If a unit is in parentheses or brackets, it is merely an interpretation. I propose that we should get that documented somewhere. I would not like us to be forced to use 'approximately', 'c', 'ca', or '~' in each conversion and I think it is frustrating to get complaints that conversions are wrong. What do others think? Lightmouse (talk) 11:40, 26 May 2008 (UTC)

Yes, politely document the fact that it is they who are wrong. Do we want that here, at WP:MOSNUM or both? Coincidentally the use of "~" has just come up at WT:MOSNUM. JIMp _talk·cont 19:57, 26 May 2008 (UTC)

If we add something here, we could point out that WP:MOSNUM says

Converted values should use a level of precision similar to that of the source value; for example, the Moon is 380,000 kilometres (240,000 mi) from Earth, not ... (236,121 mi).

JIMp _talk·cont 20:02, 26 May 2008 (UTC)

As you have seen, we have had complaints about excessive precision e.g. 'about 100 yards away' should be converted to 'about 100 metres away' rather than 'about 91 metres away'. Then we have had complaints about inadequate precision in specifications. As you say, we should point them at that text but I also think that we should have a safety net that says the conversion *regardless of precision* is not to be relied upon. Or something to that effect. The first person to add the conversion template should not be criticised just because the precision in parentheses is not exactly how another (and possibly anti-conversion) editor demands it should be. Lightmouse (talk) 20:10, 26 May 2008 (UTC)

No, if you don't like it, change it or remove it, as long as you've got decent reason. A safety net would be good but let's not have the wording "not to be relied upon", it's not to be taken as exact but that doesn't make it unreliable. JIMp _talk·cont 20:24, 26 May 2008 (UTC)

I agree with you. However, I just saw a growing mass of people unhappy with conversions just because they did not happen to agree with the precision. Some of them are calling for a ban on conversions. Some of them are suggesting that conversions are only permitted if the precision happens to be what they think is the right level (I have seen millimetre precision being used for things like marathon distance). Some of them are demanding that extra caveats are put in the parentheses (e.g. '~'). Perhaps you are right, we just need more Wikipedia editors to learn that precision is part-art and part-science and the template can always be updated easier than a manual conversion. Lightmouse (talk) 20:35, 26 May 2008 (UTC)

This is a difficult one. What seems just so plain obvious to you & me is escaping these editors. You don't want to end up sounding as if you think you know better than they do but ... there must be a way. JIMp _talk·cont 23:37, 26 May 2008 (UTC)

Alternate primary units

Hello,

I have a request that a template argument be added here so that you can designate the alternate units to be primary. The place I would like to use this is in astronomy articles. Most literature is in parsecs but most of the wiki articles use light-years as the primary unit. Therefore, I would like to convert from the literature's parsecs to laymen oriented light-years, but show light-years (laymen oriented) as the primary unit something like this:

Today's usage:

{{convert | 27 | Mpc | Mly | abbr = on | lk = on }}

Becomes:

{{convert/Mpc|27|{{#ifeq:{{#expr:Mly*0}}|0|0}}|Mly||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LonAonDbSoff|s=}}

Requested usage:

{{convert | 27 | Mpc | Mly | abbr = on | lk = on | primary = Mly }}

Becomes:

88 Mly (27 Mpc)

Thanks.

WilliamKF (talk) 20:56, 27 May 2008 (UTC)

This has come up before. The feature is coming ... sometime. There is, of course, the problem that by putting the conversion first you potentially mislead the reader into thinking that this was the original measurement. This problem whilst (in my view) serious is not difficult to overcome. Another advantage of this feature would be to maintain consistency when the sources use differing systems, somewhat desireable in prose but necessary in tables. So, it's coming but, yeah, so is Christmas. JIMp _talk·cont 04:58, 28 May 2008 (UTC)

intrusive space before inverse units

In the templates for population density, such as Convert//sqkm (and likely other inverse-only templates), the usual non-breaking space is intrusive:

{{convert|100|/sqkm}}

yields

{{convert//sqkm|100|{{#ifeq:{{#expr:0*0}}|0|0}}|||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LoffAoffDbSoff|s=}}

and

{{convert|100|/sqkm|abbr=on}}

yields

{{convert//sqkm|100|{{#ifeq:{{#expr:0*0}}|0|0}}|||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LoffAonDbSoff|s=}}

Can this be easily remedied, or is it a deep assumption of the Convert template that there should always be a non-breaking space between the number and the unit?

In addition to the templates I mentioned above, this problem would affect the (needed but not-yet-coded) conversions of units of inverse time (RPM, Hz, s⁻¹, "daily").

Stephan Leeds (talk) 13:04, 29 May 2008 (UTC)

It can be fixed but it'll take a little time. JIMp _talk·cont 16:33, 29 May 2008 (UTC)