Template talk:Convert/Archive August 2011

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

Bot needed

T need a means to change quickly say 300 acres (1.2 km2) to 300 acres (120 ha) etc. wherever it occurs. Peter Horn User talk 21:58, 20 July 2011 (UTC)

What upper and lower limits would you use? See the following
Metric people don't think in non-metric units. So there's no need to match units. Look at the two metric sizes indicated consistently in large units. There's no need to introduce metric inconsistency just because of the whim of a non-metric person:
Lightmouse (talk) 09:29, 21 July 2011 (UTC)
I am not a "non metric person", far from it, and I am not acting on a whim. this is a question of a convention and a discussion about this is also "buried in the archives". The convention would be to convert square feet and square yards to square metres and square metres to either one, except in the case of shopping centres where square metres would be converted to sqauare feet. Acres to hectares and vice versa no limits. Square miles to square kilomtres and vice versa. So
I would be reluctant to have a bot indiscriminately change articles to show hectares. Australia changed to metric when I was 7 years old but hectares have never been in common use here - I have to look up the definition on the rare occasions that I come across it. Also, hectares were withdrawn from SI in 1960 (before Australia went metric). Square km or square metres make more sense for most articles. If hectares are desired then it should be done explicitly by an editor in context - not by a bot.  Stepho  talk  23:42, 21 July 2011 (UTC)
A cautionary note: the ha measure is widely used in Europe for amounts less than 1 km2, exceptionally > 10 sq km. Historic documents in the UK and Ireland use Acre quantities but again are typically less than 1 sq mile, exceptionally > 10 sq mi. So, accepting that it has dropped out of SI, I really don't think we can expect to drop it out of Wikipedia while it is a unit still in widespread use. In the meantime, we really must leave it to editors' judgement to decide which is the appropriate conversion scale. If other editors think it is silly, they will change it. --Red King (talk) 01:38, 22 July 2011 (UTC)
Indeed, when I worked at Defra a few years ago, everything at the farm scale was measured in hectares. Most cumulative measurements were also in hectares, even when the areas involved were many hundreds of square kilometres or greater. Natural England appear to have carried on with this, for example [1] starts with the following: "Land Area: 26,340 hectares (0.2% of the total land area of England, 13,050,388 ha). Total area of all Green Belts in England: 1.6 million ha (13% of England’s total land area).". [2], an EU report, includes on page 28 "Grasslands cover, in France, 13 million hectares". So hectares are still widely used at least in an agricultural context. Thryduulf (talk) 01:58, 22 July 2011 (UTC)
In contrast to what an editor writes above, the hectare is also used in Australia. See for example Australia National Parks, having numbers of millions of hectares. −Woodstone (talk) 05:31, 22 July 2011 (UTC)

Non-specialist readers are more likely to understand 4 km2 than 400 ha. Lightmouse (talk) 09:46, 22 July 2011 (UTC)

Not quite true, outside the English speaking world, the hectare continues to be used as a land area measure. The fact that it is not part of the SI system is immaterial. Besides, the use of the hectare is getting a foothold in Canada.
As I noted in the same discussion at MOSNUM, if the original measure has a very high or low value, that probably makes the unit ill chosen. It is however not the task of the conversion template to correct that. The choice of target unit should be determined only by the input unit, not the size of the quantity. So sq mi to km2, acre to ha, sq ft to m2. Predictable output is important. If the ha is skipped from the list, awkward amounts result in many cases, typically less than 1 km2. The user can always override the default. −Woodstone (talk) 11:04, 22 July 2011 (UTC)
And they are more likely to understand 1.5 sq mi than 1000 acres, too. So, when there's a good reason to use acres, there is likely a good reason to use hectares as well. (And, while the hectare is not a SI unit, it is “accepted for use with the SI” the way the hour, the day and the litre are, so if that's a reason to avoid hectares we should avoid days as well.) ― A. di M.​plé​dréachtaí 19:55, 23 July 2011 (UTC)

You make a fair point about template default and area size as a criterion. I agree with you that it's permissable to override the default word-for-word matching but some people say it isn't. Please look at the area size examples above and comment. Lightmouse (talk) 11:05, 23 July 2011 (UTC)

I have looked at the examples above and I have applied {{convert}} to all of them. In one case I have noted both the input and the ouput as being absurd. Peter Horn User talk 18:16, 23 July 2011 (UTC)

A couple of adjusments above. Peter Horn User talk 18:29, 23 July 2011 (UTC)

A little excessive precision in a couple of cases (especially almost one billion converted to eight sigfigs), otherwise that's what I would have done as well. ― A. di M.​plé​dréachtaí 19:55, 23 July 2011 (UTC)

Interesting, thanks. You both proposed/accepted:

  • 101,000,000 acres (410,000 km2)
  • one billion acres approximately 4,046,856 km2 (1,562,500 sq mi)

What led to that? Lightmouse (talk) 20:38, 23 July 2011 (UTC)

Well, giving the area of an entire country in acres is weird in the first place, so any conversion is going to be weird (per the GIGO principle). ― A. di M.​plé​dréachtaí 10:34, 24 July 2011 (UTC)

Some towns and counties are bigger than some countries. If we are to have guidance, is it just countries? Lightmouse (talk) 11:56, 24 July 2011 (UTC)

I'm still curious as to what's the feature that makes it weird for you. If it's a country, can it also apply to counties? Lightmouse (talk) 11:23, 31 July 2011 (UTC)
Depends on how big it is... Generally speaking, I'd use square feet and square meters for buildings, acres and hectares for landed properties, and square miles and square kilometres for entire countries or administrative divisions thereof, though I might make an exception for very small ones. But when there is a good reason to use acres, there also is a good reason to use hectares. ― A. di M.​plé​dréachtaí 11:54, 31 July 2011 (UTC)

Non-specialist readers are more likely to understand 4 km2 than 400 ha. Metric people shouldn't have to check with an American before choosing the most understandable unit. Large unit for large areas. Small unit for small areas. Wikipedia isn't an in-house magazine for farmers or civil servants. Lightmouse (talk) 12:58, 31 July 2011 (UTC)

So what? They are more likely to understand square miles than acres, too (or miles than parsecs, for that matter). And some areas are too big for square metres but too small for square kilometres: 30,000 m2? 0.03 km2? ― A. di M.​plé​dréachtaí 13:17, 31 July 2011 (UTC)

Can we address points one at a time. If the area is around km2 or greater, the most understandable unit is km2. If the area is around 10,000 m2 or smaller, the most understandable unit is m2. Understandability and area size are criteria as you've indicated. It's only the sizes inbetween as in your example, that we need to worry about. Lightmouse (talk) 13:29, 31 July 2011 (UTC)

That leaves a gap for sizes between 10,000 and 1,000,000 m2, which is nicely filled by using hectare as a unit. −Woodstone (talk) 14:08, 31 July 2011 (UTC)
Also, I don't think the choice of unit should depend only on the magnitude of the measurement, but also on what you're measuring. Writing that Vatican City is 0.44 km2 and the Pentagon is 604,000 m2 rightly emphasizes how small the former is for a country and how big the latter is for a building. ― A. di M.​plé​dréachtaí 14:41, 31 July 2011 (UTC)

Yes, we may be able to get a compromise agreement based on understandable units km2 above and m2 below, leaving that range free for obscure units. Lightmouse (talk) 14:39, 31 July 2011 (UTC)

I don't see the conclusion drifting that way. There seems to be good support for consistent conversion of unit names, disregarding numerical value. If the input has very small or large numbers, so should the output. It is not the task of the template to make judgements. A simple table should define a fixed default output unit for every input unit. And there is nothing obscure about the hectare. It is widely used for farms, cities and parks. −Woodstone (talk) 16:17, 31 July 2011 (UTC)
Indeed. If someone gives the template a ludicrous input, such as 0.00487 acres, they shouldn't be surprised to get a ludicrous output, like 0.00487 acres (0.00197 ha); that's the GIGO principle, pure and simple; if they want a sane output, like 19.7 m2, they should use a sane input, like 212 sq ft. In the extraordinary cases where there is genuinely a good reason to use two units which differ by four orders of magnitude, you can always specify that via a parameter. ― A. di M.​plé​dréachtaí 16:39, 31 July 2011 (UTC)
I completely agree with Woodstone and A. di. M. - {{convert}} should by default output hectares when given acres and vice versa. The template has the ability to convert between non-default pairs of units for situations where there is a reason to use something other than the default. It is not the job of convert to police sanity in input or output units nor magnitude of valuse; nor should it attempt to second-guess what the user wanted when the enter something that doesn't seem logical to us in an abstract discussion. Thryduulf (talk) 17:47, 31 July 2011 (UTC)
I agree. We're not talking about the default. Lightmouse (talk) 09:51, 1 August 2011 (UTC)
Then what are we talking about? A bot should not change units or values used in articles. Thryduulf (talk) 14:10, 1 August 2011 (UTC)
Peter Horn asked for a bot to do exactly that. Lightmouse (talk) 14:45, 1 August 2011 (UTC)
When non-default units are used, they are used for a reason. If anyone disagrees with the choice used on an article, then it should be discussed - usually on the talk page, but I can see that discussion at Wikiproject level could be appropriate in some cases. Wholesale change after discussion only of technical matters here would be worse than the dashes and date delinking episodes - at least manual of style pages have arguable legitimacy to make such decisions. Thryduulf (talk) 16:14, 1 August 2011 (UTC)
IIRC, many of those instances of conversions from acres to square kilometres were introduced by your own bot, Lightmouse. <g,d&r> ― A. di M.​plé​dréachtaí 16:41, 2 August 2011 (UTC)

Template:Convert/3

Something seems to have broken Template:Convert/3, and it now generates links to non-existent templates. For example, {{convert/3 |5|by|6|by|7|m|ft}} now gives 5 by 6 by 7 Template:Convert/LoffAnoneDunitSoff (Template:Convert/LoffAnoneDoutput number onlySoff by Template:Convert/LoffAnoneDoutput number onlySoff by 23 ft). I have a feeling that it has something to do with this edit, as it only seems to have happened since then, but I could be wrong; I don't have the privileges to edit the page, so can't undo the edit to make sure. Could someone who does have the privileges please fix it. Thanks, Alphathon /'æl.f'æ.θɒn/ (talk) 00:33, 3 August 2011 (UTC)

It's now working: {{convert/3|5|by|6|by|7|m|ft}}. Yes, it did have to do with the edit mentioned above. The said edit was made to replace abbr=none with abbr=off (as discussed above). Convert/3 had to be adjusted to deal with this. JIMp talk·cont 03:30, 3 August 2011 (UTC)

Canadian/Australian spellings

Currently, Convert allows sp=us, but editors have requested Canadian English and Australian spellings, as new options. In particular, for Convert/spell (which is easy to change to allow sp=ca), the word "naught" (zero) as a UK/Irish variant of "nought" is considered archaic/obsolete in Canada. However, does Canada prefer word "zero" or "nought" when saying digit "0"? The U.S. seems to definitely prefer "zero". I cannot remember the Australian issues about spelling preferences. Perhaps some clues can be found by reading the large article "Australian English". Also, there could be 2 options: sp=au or sp=au19 for 19th century Australian spellings, if that would help readers sort out differences. Similar to the German language changing the number abbreviation from "No." to "Nr." in the 20th century, Australian English returned from "labor" to "labour" since 1920. Most cases could default to "sp=en" as ignoring sp=ca or sp=au. Inside Convert, the unusual spellings could be handled by passing a 2nd internal spelling option "{{{sp}}}" as "ca" because r=re is used in a zillion places to set spellings, such as "met(re)". Every time we create a new unit-code subtemplate, then pass {{{sp}}}. -Wikid77 12:26, 12 July 2011 (UTC)

I would say it's "zero" in Australia & Canada. I'd also forget about 19th century Australian English until the issue arises if ever it does. One interesting point though is the "a half hour" vs "half an hour". I'd say the latter but I believe the former is the North American norm. JIMp talk·cont 14:22, 12 July 2011 (UTC)
As an Australian, I prefer 'zero'. But we get so much British and American TV that we are comfortable with both conventions - as long as there are lots of 'u's :)  Stepho  talk  23:06, 12 July 2011 (UTC)
Australia it's definitely "zero" (many people say "oh" :P). Orderinchaos 02:32, 15 July 2011 (UTC)

For 'metre' and 'meter', can we migrate to sp=re and sp=er? Compare these two:

  • 1 kilometer (0.62 mi) - {convert|1|km|sp=us} -> 1 kilometer (0.62 mi)
  • one kilometer (0.62 mi) - {convert/spell|1|km|sp=us} -> one kilometre (0.62 mi)

Lightmouse (talk) 13:55, 13 July 2011 (UTC)

I Would prefer to keep it as sp=uk, sp=us because most people can figure out what it means. I think most people would have a hard time figuring out what sp=re or sp=er means without having to look up the template doc page. If they have to look it up then you may as well make it sp=199887 or sp=1999887.  Stepho  talk  14:10, 13 July 2011 (UTC)

That would be fine if it's a small set with known boundaries. Once you have sp=uk, you have to have sp=ca, sp=au, sp=nz, sp=sa. I'd be happy to have that as a solution but I've seen people put sp=us on all conversions (e.g lb|kg) just to play safe. With something explicit and near-wysiwyg, the initial and subsequent editors have more chance of being aware of the consequences. Can we have a list of the spelling variations so we can make an informed decision? e.g.

  • 'metre' (non-US, Canada?), 'meter' (US, Canada?)
  • 'quarter' (non-US), 'fourth' (US, Canada)

Lightmouse (talk) 14:19, 13 July 2011 (UTC)

  • Oh please, metre im Canada, like in the rest of the commonwealth. The 25 cent coin is called "a quarter" both in Canada and the US. Peter Horn User talk 22:36, 3 August 2011 (UTC)
Here in Australia, generally all units are metric (most people under about 30 wouldn't even comprehend non-metric measurements, we officially completely switched in 1972), but we use the British spellings of them. "Meter" here would refer to a measurement device (e.g. "a heart rate meter", "a parking meter") rather than a unit of measurement. As this is solely about spelling, I don't think we're so different in that sense that we'd need our own specific variety as we can simply use British English. NZ would fall into the same category. Orderinchaos 02:32, 15 July 2011 (UTC)
Have enquired with friends and South Africa is exactly the same as Australia and NZ. Orderinchaos 18:45, 15 July 2011 (UTC)
I agree with Orderinchaos. All countries that I know of (much of Asia/Oceania, S.Africa) follow either the UK or the US for spelling English and are quite used to saying 'UK spelling' or 'US spelling'. There is no need for sp=ca, sp=au, sp=nz, sp=sa, etc.  Stepho  talk  23:56, 15 July 2011 (UTC)

I think the only unit affected by sp=us is the metre (plus prefixes). What other units are affected? Lightmouse (talk) 10:47, 18 July 2011 (UTC)

Litre. Justlettersandnumbers (talk) 11:06, 18 July 2011 (UTC)

Ah yes. We can see that in:

It doesn't mention any others so I assume that sp=us means sp=er. Lightmouse (talk) 11:34, 18 July 2011 (UTC)

Mosnum gives 'litre' and 'metre' as examples but not neccessarily as a complete list. The US uses deka as a prefix while the UK uses deca. The UK can also use gramme but it's considered archaic and can probably be ignored. There are also the variant forms of tonne but they are treated in another discussion above. If we output values in word form then we need to know that the US and UK also have different values for billion (10e9 or 10e12) and trillion (10e12 and 10e18). I can't think of any more.  Stepho  talk  15:00, 18 July 2011 (UTC)
Gram: The UK migrated from 'gramme' to 'gram' over several decades and passed the midpoint about 30 years ago (compare the law in 1976 with the law in 1985). The spelling 'gram' now dominates.
Deca: I didn't know that the US uses 'deka'. It's not mentioned at mosnum and I don't think it's used in WP. I wonder why anyone cared enough to make the exception. Interesting.
Billion and trillion: My impression is that the UK and US are now in agreement on these. Mosnum is clear about it and I think the convert template is compliant with mosnum.
I think it would be useful for us to have a list of what sp=us does. Using mosnum as documention, we see it affect two words. With extended debate here, we've found a third word. Can we update mosnum and the convert documentation accordingly? Lightmouse (talk) 18:49, 18 July 2011 (UTC)
I found deka on a number of metric articles but this one suits us best - but its so rarely used that we will probably never use it. Billion and trillion have indeed swapped over to US usage but not everyone agrees and there is still much confusion among the 40+ crowd (including me) - best to avoid it if possible. Agreed that archaic forms like gramme can be dropped. Just trying to find as many variations as I can rather than find out about them after making a major change. I definitely agree that we should document what sp=us does.  Stepho  talk  00:07, 19 July 2011 (UTC)

sp=us

  1. changes "metre", "litre" and related units to "meter", "liter", etc.,
  2. changes "deca~" to "deka~",
  3. changes "tonne" to "metric ton" (this might not be working yet in all cases) and
  4. changes "US" to "U.S." when the unit code is lower-case (this is pretty useless & might as well be eliminated)

JIMp talk·cont 00:52, 19 July 2011 (UTC)

Three of those (meter, liter, metric ton) are already in wp:mosnum. If any others are still to be maintained, where would they go (in mosnum or the template documentation)? Lightmouse (talk) 10:34, 19 July 2011 (UTC)

Problems with convert/spell

Please see Template talk:Convert#A problem above. Peter Horn User talk 16:20, 27 July 2011 (UTC)

  • DONE. There are so many possible options, I had to think a while when creating those missing subtemplates. Thanks for reporting those cases. -Wikid77 02:40, 30 July 2011 (UTC)
Please see Template talk:Convert#A problem above for yet another. Peter Horn User talk 18:55, 1 August 2011 (UTC)
Make that yet more. Peter Horn User talk 22:45, 3 August 2011 (UTC)

What's the opposite of 'on'? Is it 'off' or 'none' ?

What's the opposite of 'on' when in parameters? I see 'none' in the above section. Many users think it's 'off'. For example, see: Scanning electron microscope. Lightmouse (talk) 12:43, 19 July 2011 (UTC)

If it is technically possible, then either should be valid. I don't know if it is though? Thryduulf (talk) 13:38, 19 July 2011 (UTC)
The opposite of abbr=on would be abbr=none. It would make more sense if it were abbr=off but it's not. The template just evolved that way. Originally this parameter only applied to the input value with the output always abbreviated so abbr=off was became the default but, in hinesight, it's turned out to be a poor name. abbr=off really should do what it seems to promise which is what abbr=none does. I'd be in favour of making it so & eliminating abbr=none. JIMp talk·cont 00:09, 20 July 2011 (UTC)
Internally, the default is "abbr=off" yet it acts like "abbr=out" or "off-on" (with the input non-abbreviated but the output abbreviated). People have recommended many new options, to format the results, so the whole design has been considered limited. In particular, there has been a request to variably default the abbr=xx option, as being different depending on each unit, rather than always as "abbr=off" for any unit. Juggling all the possible features has slowed the overall progress in handling each particular option. Technically, allowing abbr=off could be done by checking inside Template:Convert, to see if "abbr=off" has been specified, and then treating it as "none" but that would assume abbr=off is not used currently, which could be a big mistake. So, anywhere "abbr=off" is specified, those cases should be replaced with "abbr=out" and then abbr=off could mean "abbr=none". -Wikid77 08:57, revised 10:49, 20 July 2011 (UTC)

Several current options that have no effect in read mode. As far as I know these are:

  • abbr=off
  • sing=off
  • lk=off
  • sp=us for units that have no variation e.g. kg, lb.

They add no value but add clutter. Value-free settings should be removed as part of housekeeping anyway. I think the steps should be:

  1. Create 'abbr=out' as equal to the current 'abbr=off'
  2. Do a housekeeping run as I described above.
  3. Make 'abbr=out' the default
  4. Make 'abbr=off' mean input in full, output in full
  5. Apply any variations to the per unit default as required

Lightmouse (talk) 13:52, 20 July 2011 (UTC)

The default abbreviation, now unfortunately called off (when it would be better named off(on)), is not the same as what out would do. For example, with disp=or both input & output are spelt in full (as you might expect). As Wikid says, the coding to replace abbr=none with abbr=off is trivial but assuming that there are no abbr=offs out there now is mistaken. I count about 300. The real question is what the editors really meant. We could send a bot through and delete these abbr=offs only to find that this is better anyway. Nonetheless I intend to press ahead with this. abbr=none is to go and abbr=off will take its place. Here are the steps:

  1. remove the unwanted abbr=offs (externally),
  2. code in a switch to replace external abbr=off with internal abbr=none &
  3. replace abbr=none with abbr=off (externally).

Step 3 is a bot job. I can do step 2. Step 1, though, could be done by a bot but keep an eye on it to judge whether the abbr=off should stay. Of course, you mention other house cleaning too. Yes, there's a lot of work to be done. We're barely scratching the surface. JIMp talk·cont 17:14, 31 July 2011 (UTC)

I 've removed all instances of 'abbr=off' I can find. All seemed unnecessary. If you can find more, let me know. Lightmouse (talk) 12:26, 1 August 2011 (UTC)
I believe you've got them all. Now for step two. JIMp talk·cont 23:32, 2 August 2011 (UTC)

That's done now let's do step three. JIMp talk·cont 23:58, 2 August 2011 (UTC)

I've started but I won't be able to finish without a scope extension. Can you comment at Wikipedia:Bots/Requests for approval/Lightbot 17 please? Lightmouse (talk) 15:26, 3 August 2011 (UTC)
About the statement "I've removed all instances of 'abbr=off' I can find. All seemed unnecessary."
Not quite. I think you're going through this process too fast.
Example: When abbr=off was deleted, in South African Class 21 2-10-4 under The aborted Class 22 2-10-4 went from
"a larger 80 square feet (7.432 square metres) grate" to
"a larger 80 square feet (7.432 m2) grate". There will be more. Not good. André Kritzinger (talk) 17:11, 3 August 2011 (UTC)
You alarmed me with "a larger 80 square feet (7.432 m2) grate". It was actually "a larger 80 square feet (7.432 m2) grate". An insignificant detail to one is a sore thumb to another. Not good? Why not? That's pretty much the norm ... well actually "a larger 80-square-foot (7.432 m2) grate" would be ... yeah, not good, neither the before nor the after. If you want "a larger 80-square-feet (7.432-square-metre) grate" back again put abbr=off in. JIMp talk·cont 17:56, 3 August 2011 (UTC)

I understood that 'abbr=off' was the (invisible) old default. Thus a visible parameter of 'abbr=off' had no effect at the time it was added. Am I mistaken? Lightmouse (talk) 18:23, 3 August 2011 (UTC)

That's what I was in the middle of saying when you edit conflicted me. Lightbot actually changed nothing in spite of what the old version of the page seems to look like now (as seen through the page history). When you look at old versions of a page they're displayed using current versions of templates. When Lightbot removed abbr=off it was actually doing nothing. It does something now (as of this morning). So the page never did have "a larger 80 square feet (7.432 square metres) grate" the current version of convert is producing that. JIMp talk·cont 18:36, 3 August 2011 (UTC)
OK, got that, and you're right. It's in one of the articles I've not gotten to in my current revision process and that I would have changed to "abbr=none" until now. All the revised ones were already on "none" and for the rest I'll now use "off", so, no problem. André Kritzinger (talk) 19:05, 3 August 2011 (UTC)

I've now done step 3 and replaced 'abbr=none' with 'abbr=off'. If there are any left, let me know. Lightmouse (talk) 18:18, 7 August 2011 (UTC)

There are still a few left. JIMp talk·cont 00:43, 8 August 2011 (UTC)

Done. Let me know if there are any more. Lightmouse (talk) 11:58, 8 August 2011 (UTC)

Updated Template:Convert/doc

I have updated some parts of the doc subpage, Template:Convert/doc, to reflect the current operation of Convert. In particular, remember:

  • {Convert/3} was changed to allow any text as separators between amounts. Convert/3 formerly limited the 1st separator (as being: to, and, or, -, +/-, by, or x), but that was considered too restrictive, so any text is allowed.
  • For disp=flip, {{convert|67|km|disp=flip}} shows "42 miles (67 km)" with unit symbol "km" although it formerly would display "kilometres" rather than "km".
  • For disp=br, the description mentions "[ ]" as "square brackets" (which is the common British term, sometimes used in the U.S.). It also now notes the use of "disp=br" in direct quotes, to show conversions in editorial brackets.

Other options should be checked, and updated, to ensure that the documentation accurately describes the current options, after months of recent changes. -Wikid77 05:14, 11 August 2011 (UTC)

I was thinking that disp=sqbr (for "square brackets") might be better since outside North America "brackets" is the general term (then you've got round ones, square one and curly ones) and this would also leave room for disp=br to mean "break", i.e. a line break (<br/>), which can be useful in some tables (namely those without much room for extra columns). JIMp talk·cont 23:34, 11 August 2011 (UTC)

Burried in the archives

What was the "disp=?" used to make the input read alpa rather than digital, i.e. ten feet (3.05 m)? Peter Horn User talk 19:02, 11 July 2011 (UTC)

OK, it is "convert/spell" ten feet (3.05 m) How does one get rid of the capital T when it is not needed? Peter Horn User talk 19:23, 11 July 2011 (UTC)
Why not lower case by default? JIMp talk·cont 20:37, 11 July 2011 (UTC)
  • There is long-term grammar issue about not starting a sentence with a numeral, hence not "2 Gentlemen of Verona" but rather "Two Gentlemen of Verona" and hence the default uppercase for spelling numbers. -Wikid77 01:01, 12 July 2011 (UTC)
Inelegant but {{lc:{{convert/spell|10|ft|m}}}} would also do the trick. JIMp talk·cont 01:26, 12 July 2011 (UTC)

So there is a reason ... no offense, though, but it does seem tad topsy-turvy. Numbers at the beginings of sentences should be spelt out but this, of course, doesn't entail that spelt out numbers will be at the beginings of sentences. That's pretty obvious but maybe they're mostly going to be at the beginings of sentences, right? If the current uses of {{convert/spell}} are any indication, then the actual case is quite the opposite. In fact we could just change the default right away because none of them are at the begining of a sentence. Note also that words=out is capitalising the output too ({{convert/spell|10|ft|m}}, for example, is giving us "Ten feet (Three m)" ... yuck). JIMp talk·cont 01:58, 12 July 2011 (UTC)

  • Template:Convert/spell now defaults to lower-case numbers, so use case=u for an upper-case letter: {convert/spell|24|m|words=out} → twenty-four metres (seventy-nine feet). Most instances of spelled-out numbers have been in mid-sentence, as in quoted text, whereas very few editors are writing "new text" with numbers starting a sentence. Initially, Convert/spell was written to start sentences, but actually used more in mid-sentence. -Wikid77 12:26, 12 July 2011 (UTC)

A problem

For Algoma University #Algoma Univerity College: thirty-seven acres (15 ha) Peter Horn User talk 22:13, 21 July 2011 (UTC)

For Christian IV's Arsenal: zero point five ha (1.2 acres). Peter Horn User talk 18:35, 23 July 2011 (UTC)
For Climate of Alaska#Extremes: one °F (0.56 °C) Peter Horn User talk 20:45, 23 July 2011 (UTC)
For Stephens College#Historic Senior Hall: eight-acre (3.24 ha) Peter Horn User talk 18:44, 1 August 2011 (UTC)
Something went wrong here. Peter Horn User talk 18:58, 13 August 2011 (UTC)
For Christian IV's Arsenal: four metres (13 ft 1 in) Peter Horn User talk 19:18, 1 August 2011 (UTC)
For St. Louis College of Pharmacy five-acre (2.02 ha). Peter Horn User talk 22:23, 3 August 2011 (UTC)
For Rush University: eight-acre (3.24 ha). Peter Horn User talk 02:49, 12 August 2011 (UTC)
There are still problems. Peter Horn User talk 19:17, 13 August 2011 (UTC)

Bug for zero metres

This is a bug? 0 metres (0 in) (currently shows 0 metres (1 ft 0 in), but should show 0 metres (0 ft 0 in)). 198.102.153.2 (talk) 20:05, 11 August 2011 (UTC)

Yes it is a bug. JIMp talk·cont 23:25, 11 August 2011 (UTC)
It was a bug. JIMp talk·cont 00:08, 12 August 2011 (UTC)
is JIMp talk·cont 07:13, 12 August 2011 (UTC)
  • I have created a test version, as Template:Convert/ftin/sandbox2. Internally, "0 m" gets incorrectly calculated as "0 ft 12 in" (same as 0.3 m) and hence, 1 ft 0 inches. The results are:
  • {{convert|0|m}} → 0 metres (0 ft)
  • {{convert|.3|m|ftin}} → .3 metres (1 ft 0 in)
  • {{convert|0|m|ftin}} → 0 metres (0 in)
  • {{convert|0|m|ftin/sandbox2}}   → 0 metres ([convert: unknown unit])
  • {{convert|0.0|km|ftin/sandbox2}} → 0.0 kilometres ([convert: unknown unit])
  • {{convert|0.0|km|ftin/sandbox2|abbr=off}} → 0.0 kilometres ([convert: unknown unit])
A patch could be placed into Template:Convert/ftin (based on Template:Convert/ftin/sandbox2), with markup text to force a result as "0 in" but that might cause other problems. -Wikid77 (talk) 11:05, 12 August 2011 (UTC)
It might ... but it looks okay. I added a switch to allow linking & spelt-out noun & adjective forms. Shall we give it a go? JIMp talk·cont 08:12, 13 August 2011 (UTC)
I have put he new code in for a trial run. The page is temporarily unprotected to allow anyone to revert in case there is a problem. JIMp talk·cont 08:27, 13 August 2011 (UTC)
Unprotection has expired. There was a problem mentioned below but I think it's working fine now. JIMp talk·cont 02:27, 14 August 2011 (UTC)

Conversion from metres to feet and inches

Isn't working!

{{convert|49.99|m|ftin}} gives 49.99 metres (164 ft 0 in). Mjroots (talk) 05:36, 12 August 2011 (UTC)

  • The "m" conversion is broken, perhaps in Template:Convert/outAnd, and many athletes are showing heights of just 11 or 8 inches:
  • {{convert|1.80|m}} → 1.80 metres (5 ft 11 in)     ←showed "(11 in)" at 06:35, 12 August.
  • {{convert|1.73|m}} → 1.73 metres (5 ft 8 in)
  • {{convert|2|m}} → 2 metres (6 ft 7 in)
  • {{convert|2|m|ftin}} → 2 metres (6 ft 7 in)
  • {{convert|2|m|ft}} → 2 metres (6.6 ft)
  • {{convert|2|m/sandbox}} → 2 m/sandbox[convert: unknown unit]
We might need an emergency admin fix. -Wikid77 (talk) 06:52, 12 August 2011 (UTC)

Fixed. JIMp talk·cont 07:12, 12 August 2011 (UTC)


Popular missing cases

Browsing attempts to transclude missing templates under Template:Convert/, I see that the two cases below have each been used in more than 20 articles each:

  • {{convert|1|to|6|m}} (returns "1 to 6 metres (3 ft 3 in to 19 ft 8 in)" - the single case {{convert|1|m}} works fine)
  • {{convert|1|to|6|m|ftin}} (returns "1 to 6 metres (3 ft 3 in to 19 ft 8 in)" - plain old feet {{convert|1|to|6|m|ft}} works though)

Correcting the template is far beyond my own wikisyntax ability; best to correct each article by hand to use a closely matching case that *is* handled ? - TB (talk) 20:43, 13 August 2011 (UTC)

I believe I've fixed it. JIMp talk·cont 02:25, 14 August 2011 (UTC)
Wow - good job! Ta. - TB (talk) 07:53, 14 August 2011 (UTC)
No worries. JIMp talk·cont 08:58, 14 August 2011 (UTC)

Don't use the template in the lead section?

What is this about?

Because gadget Navigation popups suppresses the contents of templates in tool tip preview when the user hovers the pointer over a Wikilink, one should avoid using the Convert template in an article's lead section. Using the template will cause a confusing blank space to appear in the tool tip preview instead of vital information, such as the height of a mountain peak or distance between geographic features. In such instances, insert the template into the text, show the preview of your edit, then cut-and-paste the unit and its conversion into the code in place of the template. For example, {{Convert|3006|m|ft}} should be replaced with 3,006 metres (9,862 ft) before saving your edits.

{{Convert|3006|m|ft}} produces plain text that does what plain text does when you hover over it, i.e. nothing. {{Convert|3006|m|ft|lk=on}} produces links which, when hovered over, previews as normal. Is this advice mistaken? It seems to be. We can't use the template in the lead? How inconvienent. This is going unless someone can justify it. JIMp talk·cont 02:46, 14 August 2011 (UTC)

  • At some point, article text needs to be about article text, rather than an excuse to activate popup-gadgets or other compu-toys. This occurred with Google Search, several months ago, where the Google menu would slowly fade-in every time millions of users displayed the Google window. This has been a problem with computers for decades: some people lose touch with the end-user issues and instead, start thinking about the computer system as a playground for new forms of tech-toys, without a cost-benefit analysis to see if the expensive new gadgets actually generate a justified, vast improvement in the end-user's "value-added results". For justifying Convert, it only takes a few examples to prove the value-added benefits, such as converting mpg (mpgus) "26 miles per US gallon highway (9.0 L/100 km))" and then showing an article where the fuel-efficiency numbers are a range, such as "26–32 miles per US gallon (9.0–7.4 L/100 km; 31–38 mpg‑imp) for city/highway" where most editors would suffer to convert mpg range numbers by hand-coded conversions. Hence, the need for Convert is easily justified, by a few difficult conversions. However, it would be much harder to justify why popups for wikilinks are a crucial need in article text. The lack of focus on articles is a major reason why some organizations state official TQM goals which include concerns of the end-user readers; otherwise, there is too much risk that people will venture into wild, unfocused tangent activities or compu-gadgets, where there is no way to ensure that articles will still be readable, for most users, in the next update to the system. Historically, it is common for some people to "contemplate their own navels" and sub-optimize their gadgets, rather than focus on improvements for writing the article text. Plus, they should not be blamed because "no one wrote a rule which states readers are important". There is no rule which says articles must actually display text, rather than simply activate extravagant gadgets on a page. -Wikid77 (talk) 04:53, 14 August 2011 (UTC)
Sounds to me like you have an issue with some browser or other that shows pop-ups where links exist. The rest of us don't see them. I agree that they're often a PITA. - Denimadept (talk) 04:56, 14 August 2011 (UTC)

Looks like I misread the point, woops. I thought it was about links produced by the template, which are fine. It's actually about links to articles with the template on them. So this then applies to all templates. Thus should it be part of the doc for this one? Doesn't this belong at WP:MOS instead? Shouldn't we be weighing the merits of templates vs popups at WT:MOS or WT:VP (or some other venue more general than this)? JIMp talk·cont 08:57, 14 August 2011 (UTC)

For Christ's sake. If navigational popups are broken, fix them, but only a tiny minority of WP readers are logged-in users, let alone ones who know what navigational popups are and have enabled them, so their needs should be given a tiny weight compared to those of everyone else. ― A. di M.​plé​dréachtaí 10:41, 14 August 2011 (UTC)

Which part of this was done "for Christ's sake" ?  Stepho  talk  16:35, 14 August 2011 (UTC)
Didn't you know that Christ uses Wikipedia too? It's a hard job keeping omniscient these days. JIMp talk·cont 00:43, 15 August 2011 (UTC)

If there is a problem with the way navigation popups display convert templates, then change navigation popups. I speak here as a very long time user of navigation popups, and the person who requested that popups display the wikicode of templates rather than just ignore them so you see, e.g. {{Copy to WikiBooks}} {{Globalize/USA|date=September 2010}} at the top of the popups preview of Fuel economy-maximizing behaviors. Indeed, this is how the convert template currently appears, see for example 20 Bank Street (London) which includes the sentence "It is {{convert|68|m|ft}} tall with a floorspace of {{convert|47565|m2|sqft}}.", so I don't see that there actually is a problem. If you want the popups to display the output of {{convert}} ratherthan the wikicode, you'll need to ask at wherever the popups are maintained these days - I can see the benefits for a template like this that is used inline and produces plain text, but it wouldn't be useful for templates that output extensive or complex text/graphics. Finally, preview works on links to sections of articles (e.g. Portugal#Transport), and the "more" links allow you to preview extended sections of the article. We should not be adjusting the encyclopaedia to work with tools, we should be adjusting tools to work with the encyclopaedia. Thryduulf (talk) 19:31, 14 August 2011 (UTC)

I agree.
  1. We have here a broken tool. It needs fixing.
  2. The tool is broken for all templates. Not just this one.
Should there be guidance against using templates in the lead? That's not a topic for this page. But if there should be, the guidance doesn't belong here but at a more general location. I propose to remove the advice from this doc and bring the topic up at whichever location those who fix broken tools go chatting. JIMp talk·cont 00:43, 15 August 2011 (UTC)
The tool's page appears to be at WP:POPUPS. The "Preview options" section there appears to show that the behaviour of popups regarding templates is configurable to show output, wikicode or nothing. The tool is almost certainly therefore not broken. I agree with the rest of your comment though and suggest you remove the offending text. Thryduulf (talk) 01:11, 15 August 2011 (UTC)
It's gone. JIMp talk·cont 11:39, 15 August 2011 (UTC)

Unnecessary link

Would someone pleae unlink "Abridged" in "Abridged list of units supported by {{Convert}}" which leads to a Wiktionary defintion of what "abridged" means. It's unecessary, and also deceptive, since it appeared to me at first to lead to the list of units I was looking for. This is not Simple English Wikipedia, I think we can trust that our editors know what "abridged" neans. Thanks, Beyond My Ken (talk) 06:06, 14 August 2011 (UTC)

Done. Actually the link was at Template:Convert/list of units which is only semiprotected (so you could have deleted it yourself) ... but I don't blame you if what was a bit trick to figure out. JIMp talk·cont 08:32, 14 August 2011 (UTC)
Ah! Thanks, didn't realize it was transcluded. Beyond My Ken (talk) 11:58, 14 August 2011 (UTC)
Template documentation usually is (usually in a green box like it is here) & should generally not be protected. If the doc is not transcluded from an unprotected doc page, it probably should be & you could ask that it be so. JIMp talk·cont 13:30, 14 August 2011 (UTC)

Missing templates: Convert/LonAnoneDbSoffNa and Convert/LoffAoffDcommaSoffNa

Please can someone do the necessary magic to create Template:Convert/LonAnoneDbSoffNa and Template:Convert/LoffAoffDcommaSoffNa.

  • {{convert|11.5|long ton|lk=on|abbr=off}} → 11.5 long tons (11.7 tonnes)
  • {{convert|5.4|long ton|disp=comma}} → 5.4 long tons, 5.5 t

Both are needed at Bridgnorth Cliff Railway

Thanks, Thryduulf (talk) 22:50, 15 August 2011 (UTC)

How's that's? JIMp talk·cont 01:28, 16 August 2011 (UTC)
Excellent, thank you. Thryduulf (talk) 09:56, 16 August 2011 (UTC)

Sortable key with both positive and negative numbers

I'm trying to make the tables on List of volcanoes in Indonesia sortable, but the Sulawesi and Sangihe Islands table isn't sorting properly because some of the volcano elevations are negative (ie. submarine). The elevations all employ the "Convert" template and have "sortable" switched on, but when the table is sorted by elevation, -5 displays as a lower number than -5000. Does anyone know how to fix the "Covert" template to make negative numbers sort consistently with positive numbers? Neelix (talk) 15:40, 16 August 2011 (UTC)

We have been slowly working on this issue (see above). It was actually even worse before. You might try to ping Droll if you don't hear from anyone else soon. Thanks! Plastikspork ―Œ(talk) 01:29, 17 August 2011 (UTC)

Temperature range conversions break unless exactly one output unit is specified

Temperature range conversions are broken when no output units are specified (" - Invalid output type {4}="def", in {{Convert|26|to|32|def|...}}.)"):

  1. {{convert|26|to|32|C}} → 26 to 32 °C (79 to 90 °F)
  2. {{convert|26|to|32|F}} → 26 to 32 °F (−3 to 0 °C)
  3. {{convert|26|to|32|K}} → 26 to 32 K (−247.2 to −241.2 °C; −412.9 to −402.1 °F)

They work when one output unit is explicitly specified

  1. {{convert|26|to|32|C|F}} → 26 to 32 °C (79 to 90 °F)
  2. {{convert|26|to|32|C|K}} → 26 to 32 °C (299 to 305 K)
  3. {{convert|26|to|32|F|C}} → 26 to 32 °F (−3 to 0 °C)
  4. {{convert|26|to|32|F|K}} → 26 to 32 °F (270 to 273 K)
  5. {{convert|26|to|32|K|C}} → 26 to 32 K (−247.2 to −241.2 °C)
  6. {{convert|26|to|32|K|F}} → 26 to 32 K (−412.9 to −402.1 °F)

But break when two or three output units are specified ("- Invalid output type {4}="F K", in {{Convert|26|to|32|F K|...}}. )")

  1. {{convert|26|to|32|C|F K}} → 26 to 32 °C (79 to 90 °F; 299 to 305 K)
  2. {{convert|26|to|32|F|C K}} → 26 to 32 °F (−3 to 0 °C; 270 to 273 K)
  3. {{convert|26|to|32|K|C F}} → 26 to 32 K (−247.2 to −241.2 °C; −412.9 to −402.1 °F)
  4. {{convert|26|to|32|R|C F}} → 26 to 32 °R (−258.7 to −255.4 °C; −433.7 to −427.7 °F)
  5. {{convert|26|to|32|R|C K F}} → 26 to 32 °R (−258.7 to −255.4 °C; 14.4 to 17.8 K; −433.7 to −427.7 °F)

In all cases it appears to be Template:Convert/Dual/LoffAoffDxSoffT where the problem manifests. Thryduulf (talk) 15:50, 19 August 2011 (UTC)

  • For those reasons, the new {Convert/2} is recommended to provide more of the "74,000" different possible conversion options, with abbr=out, disp=br, etc. Try, for example:
  • {{convert/2 |26|to|32|C|F K}}   → {{convert/2|26|to|32|C|F K}}
  • {{convert/2 |21|to|42|F|C K}}   → {{convert/2|21|to|42|F|C K}}
  • {{convert/2 |21|to|49|F|C K|disp=br}} → {{convert/2|21|to|49|F|C K|disp=br}}
  • {{convert/2 |70|to|90|R|C K F}} → {{convert/2|70|to|90|R|C K F}}
We can discuss showing more '°F' or '°C' in the multiple results. It was becoming very difficult to update all the hundreds of related subtemplates. -Wikid77 05:53, revised 06:16, 20 August 2011 (UTC)
I think that a sensible default when no units are specified would be for C input to give F output, F → C, K → C and F. I don't know about R though. At the very least if this is not going to be fixed the documentation needs updating to reflect this. Thryduulf (talk) 21:39, 20 August 2011 (UTC)
I agree that C → F and F → C by default. With K, it's likely to be used in scientific articles where a default to C makes sense. Lightmouse (talk) 10:54, 21 August 2011 (UTC)

Link to redirect. Please change 'knot (speed)' to 'knot (unit)'

Please change 'knot (speed)' to 'knot (unit)'. I found this in 'Template:Convert/kn mph' but there may be more. Lightmouse (talk) 21:18, 20 August 2011 (UTC)

I changed several. Hopefully I got them all. Thanks! Plastikspork ―Œ(talk) 06:00, 21 August 2011 (UTC)

Thanks. Also:

  • Template:Convert/mph kn
  • Template:Convert/km/h kn

Lightmouse (talk) 12:24, 21 August 2011 (UTC)

Done. Plastikspork ―Œ(talk) 01:03, 22 August 2011 (UTC)

Reciprocal conversions

As an example, {{convert|32|-|35.5|mpgus|L/100km|abbr=on}} displays 32–35.5 mpg‑US (7.35–6.63 L/100 km) . Shouldn't the order be reversed? If so, how? — Arthur Rubin (talk) 14:57, 2 August 2011 (UTC)

Yes, good point. This will take a while but I'll be working on it. PS I've taken the liberty to fix up your post. JIMp talk·cont 15:27, 2 August 2011 (UTC)
Good point. I just copied it from fuel economy-maximizing behaviors, which is on my watchlist for some reason. I honestly don't know whether it's US gallons or imperial gallons; England reports road distances in miles, but I don't know what units they commonly use for automobile fuel economy. — Arthur Rubin (talk) 15:37, 2 August 2011 (UTC)
Miles per imperial gallon. US measures of volume are never used in Britain without them being explicitly highlighted as such. Thryduulf (talk) 00:21, 3 August 2011 (UTC)

This is also an issue at Talk:Ford Model T/Archive 1#Fuel economy units and Wikipedia talk:WikiProject Automobiles#Your mileage may vary .  Stepho  talk  07:17, 9 August 2011 (UTC)

It's the same issue. I started this thread, unaware of the discussion here, in response to an editor here wishing the template could do it...& got a result that looked really odd to me. Had I known about this first... TREKphiler any time you're ready, Uhura 07:28, 9 August 2011 (UTC)

The template isn't yet able to cope with all permutations:

  • Efficiency improved from 13 to 40 mpg‑US (18.1 to 5.9 L/100 km)
  • Efficiency improved from 18 to 5.9 L/100 km (13 to 40 mpg‑US)

Efficient engines use less volume per unit range or more range per unit volume. We can't change that. Lightmouse (talk) 09:36, 9 August 2011 (UTC)

I tracked down one issue, and that is some very small (exponential notation) number is being passed in the conversion. While we probably want to fix that, there is definitely a bug in the conversion, check this out 18 to 59 L/100 km (13.1 to 4.0 mpg‑US). I will see if I can track it down. Frietjes (talk) 15:49, 9 August 2011 (UTC)
On second thought, I will let Jimp figure it out. It should be fixable, since the non-range versions work: 18 L/100 km (13 mpg‑US) and 5.9 L/100 km (40 mpg‑US). Frietjes (talk) 16:13, 9 August 2011 (UTC)
  • Also use Convert/2 for mpg ranges: Although some mpg or fuel-efficiency ranges have been fixed, consider using {Convert/2|...} for other ranges. Currently:
  • {{convert|13|-|40|mpgus|L/100km|abbr=on}} → 13–40 mpg‑US (18.1–5.9 L/100 km)
  • {{convert|32|-|35.5|mpgus|L/100km|abbr=on}}     → 32–35.5 mpg‑US (7.35–6.63 L/100 km)
  • {{convert/2 |32|-|35.5|mpgus|L/100km|abbr=on}} → {{convert/2|32|-|35.5|mpgus|L/100km|abbr=on}}
  • {{convert/2 |32|-|35.5|mpgus|L/100km}} → {{convert/2|32|-|35.5|mpgus|L/100km}}
Compare for huge number:
  • {{convert|32|-|590000000000000|mpgus|L/100km|abbr=on}}   → 32–590,000,000,000,000 mpg‑US (7.3504557291666–4.0×10−13 L/100 km)
  • {{convert/2 |32|-|590000000000000|mpgus|L/100km|abbr=on}} → {{convert/2|32|-|590000000000000|mpgus|L/100km|abbr=on}}
Although huge numbers are rare, the intent is for {Convert/2} to allow any values. So, it handles some ranges which are not supported unless using "convert/2":
  • {{convert |20|-|25|L/100km|mpgus}} → 20–25 litres per 100 kilometres (11.8–9.4 mpg‑US)
  • {{convert/2 |20|-|25|L/100km|mpgus}} → {{convert/2|20|-|25|L/100km|mpgus}}
  • {{convert/2 |7.4|-|6.63|L/100km|mpgus}} → {{convert/2|7.4|-|6.63|L/100km|mpgus}}
By having 2 range-conversion templates, there is a better chance for supporting more of the various options. -Wikid77 (talk) 15:25, 10 August 2011 (UTC)
Jimp fixed the earlier error with this edit. Before the fix, that conversion was generating numbers on the order of 10-13 for numbers on the order of 10, which was clearly a bug. Frietjes (talk) 21:26, 26 August 2011 (UTC)

Most articles lack conversions

 90% of articles     are lacking   conversions. is located in 100x100
 90% of articles     are lacking   conversions.
 90% of articles 
   are lacking 
 conversions.
class=notpageimage|
Over 90% of articles lack measurement conversions.

I did some quick wikisearches and counted the conversions, such as hunting for "120 km" or "120 kilometres" and counting how many also have "75" miles. The result was: very few have conversions of amounts, only 45 out of 500 (9%). Results are similar for other numbers, averaging 10%, such as 3% for 110 km, but 17% for 80 km, etc. Hence, the updated articles which do have conversions are just the "tip of the iceberg".

This is just a reminder that very few people are using Convert (or any other conversions), yet, so there is still more time to consider additional features in Convert, and welcome more comments about the documentation. Based on the wikisearches for km/miles, there might be another 18 million conversions to add to the current articles. I have no objection to people adding a conversion for 120 km as "(75 mi)" but the search-results show that 90% of articles are not showing the expected conversions. This is NOT a call to start throwing Convert into more articles, but when updating articles for new text, or copy-edit, or better sources, then check to add conversions at that time.

Also, remember that Spanish is the "other language" for the U.S., so conversions made in the Spanish Wikipedia (eswiki) should also show miles/km, because Spanish readers will see most of the American road signs (or webpages) labeled in "miles" (not "km"). The lessons learned in updating Convert on enwiki will help to update the similar template es:Plantilla:Convert on eswiki. -Wikid77 16:28, 15 August 2011 (UTC)

I suspect that the real reason conversions are not used very often is because editors are thinking primarily about 120 km (assuming a metric country). They then think about how they normally convert to foreign units - which for most people is to either look it up or to use some conversion calculator/tool/program/website. They then copy that value into the article. For most people, having a little macro that does the conversion is something they would never even think of. If they happen to come across an example then all the options and weird syntax frightens them. And if they happen to try it anyway it is likely to break as it manifests a bug from time to time. So on the one hand they have something which is simple to understand and on the other hand they have something complex, awkward, scary and error prone. I don't agree with this reasoning but I am quite confident this is how many (most) people see it. Something like {{convert|120|mi|km|abbr=on|0}} is effectively voodoo incantations. However, simple macros like {{km|120}} are more acceptable. They still won't think of using macros when creating articles but at least they won't be scared off when they see it in existing articles.
Also, remember that Spanish is the "first language" for Spain, so conversions made in the Spanish Wikipedia (eswiki) should also show km/miles, because Spanish readers will see most of the European road signs (or webpages) labeled in "km" (not "miles").  Stepho  talk  12:28, 16 August 2011 (UTC)
Mexico and Central/South America (which contain the majority of Spanish speakers; Mexico alone has over twice that of the United States) use the metric system also. Orderinchaos 15:05, 16 August 2011 (UTC)
  • Those 90% lack even hand-conversions: When I noted that articles containing "120 kilometres" (or "120 km") do not show "75" mi/miles, then I was referring to all conversions, even those hand-coded as "75 miles". Perhaps 8% of those articles use {Convert|120|km...}, and another 3% have a literal "75" mi/miles, but that means about 89%-90% of articles which state "120" km/kilometres (or "kilometers") do not show any conversion of that amount. -Wikid77 20:18, 26 August 2011 (UTC)

"C-change" and "F-change"

The way I was taught—if I understand the intent of these conversions correctly—the conventional way of writing them is C° and F°. In words, “Celsius degrees” is a temperature difference, as distinct from a temperature in ”degrees Celsius”. For example, “The temperature decreased by 30 C° after the brine froze, stabilizing at −48 °C.” (Since kelvins are an absolute measure, no distinction need be made between temperatures and temperature differences, but in the latter context 1 K = 1 C° = 1.8 F°.)—Odysseus1479 (talk) 01:09, 17 August 2011 (UTC)

  • I like the idea, and we need to cite some sources about this. Meanwhile, Google Search is still unable to match punctuated terms such as "C°" so we cannot just use Google to quickly search for that. Google still has a word-in-letters bias slant, and it cannot yet search for "C°" versus "°C" or, I guess, anything that is not words written in letters ignoring diacritical marks. I have tried to find other search-engines, which could search for "C°" or "3+4" but they are all stuck in the primitive cannot-search-symbols mode of the current "computer dark ages" trying to rediscover text which has punctuation, or those new-fangled arithmetic signs "x=14-5/6" used for hundreds of years. Yes, Virginia, your phone can rotate 3-D pictures in transparent mode but still cannot search "x=67" after 10-15 years of trying. Anyway, I digress, so thanks for the idea and perhaps we'll find sources. -Wikid77 13:54, 17 August 2011 (UTC)
There is a textbook cited in the Celsius article, but it apparently considers the usage non-standard—and moreover the article has an example using “degrees C” for an interval (which I have always considered technically incorrect).—Odysseus1479 (talk) 22:46, 17 August 2011 (UTC)
It makes sense but if nobody recognises it, it's no use. Perhpas we should bring it up at WT:MOSNUM. JIMp talk·cont 23:03, 17 August 2011 (UTC)

The SI authority decided in 1968 that:

Lightmouse (talk) 16:32, 20 August 2011 (UTC)

That refers to kelvins, but the decision premised on it does say “a temperature interval may also be expressed in degrees Celsius”. I guess I had old-fashioned teachers …
Jimp, “nobody” is an exaggeration, but point taken.—Odysseus1479 (talk) 08:58, 30 August 2011 (UTC)

Nominal horsepower?

I see 'nominal horsepower' being used. I can't work out from Horsepower#Nominal_horsepower whether a conversion is possible. What do people think? Lightmouse (talk) 11:02, 22 August 2011 (UTC)

My non-expert gut feeling is that there are just too many variables, not all of which are always going to be known, for this to be feasible, at least currently. I'm happy to be proved wrong though. Thryduulf (talk) 11:34, 22 August 2011 (UTC)
If nominal horsepower is speed times area (as indicated by the formula on the page), it's not a power at all. The power generated by a piston is its speed times its area times the pressure differential. However, I wonder whether this formula is accurate in the first place. Perhaps the 7⁄33,000 is not really meant to be a numerical factor at all but is really a coefficient with the dimension of pressure (e.g. 7⁄33,000 horsepower-seconds per cubic foot). Assuming this to be the case, we still would have trouble converting it since implicit in this would be estimated pressure differential which may not be valid for the particular engine in question. JIMp talk·cont 04:49, 23 August 2011 (UTC)
It seems a bit like the RAC HP used for taxing cars in Commonwealth countries (used bore but ignored stroke). When it was first introduced it matched the real HP close enough but as efficiency got better it started to deviate. We could make a conversion that generated a real world HP but it would only be valid on engines with roughly the same efficiency, stroke, pressure and piston speed as those old engines. If nominal HP was only used on those older engines, and assuming the earliest and latest of those engines were roughly equivalent in efficiency, then we might be able to get away with it. But these caveats make unlikely for me.  Stepho  talk  06:48, 23 August 2011 (UTC)
Aha, caveats belongs to the quantity, not the unit symbol. We don't say:
  • "100 bhp (75 bkW)""
  • "120 shp (89 skW)"
  • "100 psia (690 kPaa)
The SI authority says information on the nature of the quantity should be attached to the quantity symbol and not to the unit symbol...For example: The maximum electric potential difference is Umax = 1000 V but not U = 1000 Vmax..
I've always been uncomfortable with: WP:watt article "Argentina uses a fission reactor to generate 2109 MWt of heat, which creates steam to drive a turbine, which generates 648 MWe of electricity". Now I know why.
We should write:
  • power(nominal|static|brake|indicated) = 100 hp (75 kW).
but we usually see:
  • power = 100 (s|b|i)hp (75 kW)
thus I think we should also write:
  • power = 100 nhp (75 kW)
My conclusion is that the convert template should treat nhp just like all the other versions of hp. Lightmouse (talk) 08:27, 23 August 2011 (UTC)
How can it, when there is no conversion between the arbitrary nhp and any actual measurement of power? You can't just pretend one nhp is 33,000 ft.lb/min. From A Century of Traction Engines, W.J.Hughes, David & Charles, 1970:
"The term nominal horsepower (n.h.p) is really a hangover from early days, probably deriving from the 'horse power' machines or horse works devised to use horses for driving threshing machines or other barn machinery. One type of horse works was a kind of treadmill, where one, two, or three horses, side-by-side, walked on inclined endless belts which moved beneath them, the power thus generated being taken off through a shaft, gearing and universal joints. Another kind was a sort of windlass, the horses being harnessed to the arms, and walking round in a circle. ... Thus the manufacturer of a 4 h.p. portable would intend to purvey to non-technically minded farmers that his engine developed the same power as a 'horse power' in which four horses were used. In actual practice, the term was quite wrongly used, one nominal horse power being deemed to be equal to '10 circular inches of piston area'. To work out what this meant, or was supposed to mean, take the square of the cylinder bore and divide by ten to obtain the n.h.p. Example: a cylinder of 9-in. bore: 9 x 9 = 81: 8 n.h.p. engine! Or cylinder 6¼ bore: 6¼ x 6¼ = 40 nearly: 4 n.h.p. engine. This system, of course, took no account of the boiler pressure or even the stroke," (or speed) "but it did serve as a rough and ready measurement, in early days when the usual pressure was about 45 lb."
I don't see how any attempt at a conversion to, say, kW, would be other than misleading. Better, perhaps, to break the normal MoS guidance and link to n.h.p, where, to add to the problem, a calculation quite different to Hughes' is given. Globbet (talk) 23:07, 23 August 2011 (UTC)

Oh dear. This 'unit' is used in quite a few places. I see several suggestions that it's unsatisfactory, ambiguous, or misleading. Is there nothing that can be done? Lightmouse (talk) 17:41, 25 August 2011 (UTC)

If a contemporary source describes an engine as so many nhp, I don't see any problem with using that, especially if nhp is linked to Horsepower#Nominal_horsepower, as I have suggested, and if that section is improved. The nhp rating is a valid historical description applied to historical engines and as such its use in articles relating to history of technology is perfectly valid too. In the case of a traction engine, for example, the nhp rating is the indicator of its size that everybody understood: it is a fundamental part of the contemporary description of the thing, eg here. If there is source for an actual power output, then so much the better, use that as well, but not usually instead of the nhp rating. That nhp may offend a modern desire for encyclopedic precision is just tough. If you think of it as just a rough comparative guide to overall size, rather than as a measure of power output, it may help you to feel less discomfort. Globbet (talk) 23:59, 25 August 2011 (UTC)
It's not so much size (from what I can make out) but rate of expansion (piston area times speed). We thus could work back from nhp to cubic feet per second and convert that. Note also that assuming a certian pressure this equated to so much horsepower which we then convert to kW. Put it all in a footnote. JIMp talk·cont 00:40, 26 August 2011 (UTC)
If you read the definition I have quoted above you will see that one is based on nothing of the kind. We have two completely different definitions to make sense of. Neither of these provides any reliable way of getting to the actual power output of any engine, and to attempt to do so would be OR. I like the footnote suggestion. Perhaps we could provide one as a template? Globbet (talk) 08:47, 26 August 2011 (UTC)
Sorry, no, I didn't read it as carefully as I might have. In that case, the definition you have is at odds with the one quoted in the article.

nhp = 7 x area of piston x equivalent piston speed/33,000

Either way, no it doesn't really translate to a power output. I think that the best we can do is explain what nhp means and convert that. JIMp talk·cont 15:05, 26 August 2011 (UTC)
JIMp, I don't understand why remain hell-bent on having some sort of conversion, however bogus, when it is quite clearly not practicable. You appear to be focused on the dimensions of the quantity, and to think that if you can get a clear handle on those, then a valid conversion is possible. I think that is the wrong perspective, and that you should forget about the formulae and grasp that nhp is really little more than an arbitrary comparative designation. Your footnote might say something like this: An nhp rating was a rough guide to power or size. The actual horsepower output may typically have been anywhere between about one and five or more times the stated nhp. See Nominal horsepower for a fuller explanation. Globbet (talk) 20:51, 26 August 2011 (UTC)
I'd be perfectly fine with a statement as vague as that if that's the best we can do but if we can say as much as 4 nhp indicates an actual power of anything between 4 and 20 hp, then isn't it valid to also say that this is equal to anything between 3 and 15 kW? We don't have to convert nhp to something precise but it would be nice, where possible, to convert it to something intelligible. JIMp talk·cont 21:47, 26 August 2011 (UTC)
  • There's no way to do this conversion (similarly the tax horsepowers) without an impractical amount of context. I like the idea of generating a wl to the nhp article instead. Andy Dingley (talk) 21:55, 26 August 2011 (UTC)
No, it's a bit like the stone's throw {{convert|12.764|stone's throw|m|sigfig=4}} ... JIMp talk·cont 13:27, 28 August 2011 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_August_2011&oldid=1134862402"