Template talk:Convert/Archive June 2011

3 values

Hi, I'm trying to make the Voyager 1 article convert to 2 different units, i.e. miles to kilometres and light-years, however the template doesn't seem to work:

{{convert|10877000000|mi|km ly}} results in "10,877,000,000 miles (1.7505×10¹⁰ km; 0.0018503 ly)"

help? :)

--Lord Aro (talk) 19:39, 30 May 2011 (UTC)

That's not just the only issue. NASA sources use nautical miles for some data and statute miles for others. Consequently the plain term 'mile' in a spacecraft article needs to be supported by 'nautical' or 'statute'. Lightmouse (talk) 20:58, 30 May 2011 (UTC)

How about {{convert|10.877|e9mi|km ly}} to give "10.877 billion miles (1.7505×10¹⁰ km; 0.0018503 ly)". JIMp _talk·cont 01:07, 31 May 2011 (UTC)

On the other hand, why light-years rather than AU? JIMp _talk·cont 05:49, 1 June 2011 (UTC)

I don't know, I was just going on what was already there. I have since switched to AU/km anyway, since thats all i could find referenced: http://voyager.jpl.nasa.gov/where/index.html
Thanks for your other edits :)
--Lord Aro (talk) 11:59, 1 June 2011 (UTC)

Fraction convert problems

Resolved

Please see Shackleford_(horse)#Racing_statistics where 1+1/4 mile is showing as shorter than 7/8 mile when converted.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 22:18, 2 June 2011 (UTC)

The option abbr=none combined with adj=on doesn't seem to agree with fractions.

• 1+1⁄4-mile (2.01-kilometer) wrong

I can only think of these four solutions

1. 1+1⁄4-mile (2.01 km) get rid of abbr=none
2. 1+1⁄4 miles (2.01 kilometers) get rid of adj=on
3. 1.25-mile (2.01-kilometer) get rid of the fractions
4. 1+1⁄4-mile (2.01-kilometer) write it out long hand until we can fix it.

My preference would be for option 1. Why do you want the "kilometers" spelt out anyway? I'd suggest abbreviating "miles" too (especially in the table) but I'm afraid that seems to need work too. JIMp _talk·cont 23:35, 2 June 2011 (UTC)

I'll go with option 1. Optimally, there would be a "furlong|mi km" option since furlong is such an important distance in horseracing. This option might be written to solve any issues.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 23:44, 2 June 2011 (UTC)

I just fixed the page. I am no longer watching here.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 23:54, 2 June 2011 (UTC)

There is: 9 furlongs (1.1 mi; 1.8 km). I hadn't suggested it because it wasn't going to preserve the fractions for the mile conversions but turn them into decimals instead. Come to think of it though, if you've got furlongs, do you really need miles? JIMp _talk·cont 02:23, 3 June 2011 (UTC)

Yes. Horse races (in the UK at least) have their distances quoted in miles and furlongs (and, where necessary, yards). Tomorrow is The Derby, possibly the biggest flat race of the year, and that is officially described as "1m 4f" - one mile, four furlongs. Not 1.5 miles or even 1+1⁄2 miles. See the Epsom schedule for 3-4 June 2011 which gives that and other race distances. --Redrose64 (talk) 22:23, 3 June 2011 (UTC)

Curious fraction anomaly

The |abbr=on option affects how fractions are displayed.

Code	Result	HTML generated for the "half"
{{convert|1|ft|4+1/2|in}}	1 foot 4+1⁄2 inches (0.419 m)	<sup>1</sup><big>⁄</big><sub>2</sub>
{{convert|1|ft|4+1/2|in|abbr=on}}	1 ft 4+1⁄2 in (0.419 m)	½

Is this difference in the representation of the fraction intentional? --Redrose64 (talk) 22:23, 3 June 2011 (UTC)

This probably happened after the changes spawned by the "Template talk:Convert#unsuported fraction and not abbreviating input" thread above. I say we change them to both use the "sup/sub" stuff, since that is what is advocated by MOSNUM. Frietjes (talk) 22:36, 3 June 2011 (UTC)

Calories again

When I created {{convert/Cal}} I followed the convention of capitalising the kilogram calorie as a means of distinguishing it from the gram calorie. During a number of discussions on various talk pages (e.g. the Calorie and MOSNUM talk pages) over the years I have come to realise that this convention, far from being standard practice, is hardly followed in the real world.

I put in a request to correct my mistake. It was fixed. Along came Quicksilver claiming that this was improper and that the capitilisation needed to be preserved "since 1 Calorie = 1 kilocalorie = 1,000 calories". An edit request was put forth (on a seperate page) and it was changed back to Calorie.

"Although we often see it printed in lowercase in publications," argues Quicksilver "the proper form is to capitalize it in order to distinguish it from the ordinary calorie." On what grounds can we claim the capitalised form to be "proper"? Is this a BIPM standard? We "often" see it ... we usually see the large calorie printed in lower case in publications. This is the norm. This is standard practice in the world.

At Wikipedia we generally strive to follow normal practice. We should not latch onto this or that convention just because it seems like a good idea. So I challenged the change and requested that it be changed back but this was denied. "If it was reverted it was for a reason and it is evidently a controversial change." writes Woody "Please provide evidence of consensus for the change."

So I went looking for evidence of consensus. What I didn't find was a whole lot of controversy. It was basically Quicksilver's claim of impropriety which was pretty-much taken on face value and thence followed through with. My counter argument somehow must have been overlooked, perhaps I came too late, perhaps noone cares. Where, though, is the evidence of consensus for the capitalisation?

I took a look around for other evidence. I did a search for the word calorie (case insensitive) on WP. Picking through about two and a half thousand pages I found only about a couple of dozen articles which followed the convention as opposed to hundreds (perhaps thousands) which didn't. This, it seems to me, is fairly good evidence that Wikipedians in general are not followers of the convention, i.e., evidence against capitalisation.

I'd suggested we take the question up at MOSNUM and so I did. The practice of our deferring to MOSNUM has recently been brought into question so perhaps I'll be frowned upon for moving the discussion over there when it started here as if I were asking the other parent ... or Big Brother. But that's how we've been doing things here for years, the rationale being that MOSNUM is supposed to be the place for general discussions of how to treat units, the place with the broader base of consensus. MOSNUM, as I've pointed out in a previous discussion, is not an outside authority, we're all invited.

At MOSNUM I argued that it was unsatisfactory, indeed confusing, to continue with the current situation whereby a handful of pages follow the capitalisation convention whereas the vast majority do not, that we should make a decision one way or the other. I further argued that the decision we make should be along the lines of standard practice at WP and outside, that we should not capitalise the food calorie.

For for a fortnight the topic has sat there attracting few comments (two editors agree that we don't need to capitalise the word and one who just wants us to switch to joules). At this stage I believe I'd be justified in amending the guideline to depreciate the practice; however, I don't want to be too hasty. Perhaps someone else would like to have their say.

There would seem to be three possible outcomes of the MOSNUM discussion.

1. We decide to continue to leave capitalisation up to the editor.
2. We decide to depreciate the capitalisation.
3. We decide to insist on the capitalisation after all.

The first option is in keeping with WP's tolerance of of variations in style but, as I point out, is likely to cause confusion. The discussion so far is headed in the direction of the second option, which conforms with the idea that guidelines should reflect reality. The third option, I believe, is unlikely and would entail style changes in several hundred pages.

What does all this mean for us at {{convert}}? If it turns out we go with option three, we should leave the capitalisation in {{convert/Cal}}. If we go with option two, we should get rid of it. Option one is interesting, though, and worth careful consideration as it is the current status quo, there being as yet no guidance as to whether we should use Calorie or calorie.

A template should not be used to switch between two optional styles. So until such guidance is in place the template should allow either. Presently {{convert}} only allows Calorie not (the more commonly-found-on-WP) calorie. Until (or unless) we get such guidance the template should allow either but one of these will inevitably be given preference.

What I mean by preference is perhaps best explained through examples. Let's suppose we give preference to the capitalised form. In this case {{convert|123|Cal}} would give "123 Calories (510 kJ)". For "123 calories (510 kJ)" you'd have to do something more complex e.g. {{convert|123|(kg)Cal}} or {{convert|123|Cal|sp=lc}}.

Considering, however, that there are hundreds (probably thousands) of lower-cased food calories (as opposed to a few dozen upper-case ones) to be converted, we should be able to do so without having to go to extra trouble. I propose that {{convert|123|Cal}} give "123 calories (510 kJ)" and a new subtemplate, {{convert/Calorie}}, be created such that {{convert|123|Calorie}} would give "123 Calories (510 kJ)". This is quite what-you-see-is-what-you-get.

Let's say we adopt the proposal described above. If through the MOSNUM discussion we decide to go with option one (as described above), we just leave things like this and all's well. If we end up going for option two (given that we still care about MOSNUM anyway), we simply redirect {{convert/Calorie}} to {{convert/Cal}}, we could then (once the dust settles ... if it ever does) go through and change the few dozen Calories to Cals and finally dispose of {{convert/Calorie}}. If, by some chance, we end up with option three, we edit {{convert/Cal}} first (to have it give Calorie) and then do as with option two.

One final thought, though: what's the big deal about distinguishing the big and small anyhow? It's pretty much as simple as this. If it's got the prefix "kilo-", it's a small one, otherwise, it's a big one. The gram calorie is too small for most foods so those who like this one have to stick a "kilo-" onto it whereas kilogram calorie is just about right. Oh but what about in science? Scientists use the gram calorie, don't they? This is something of a misconception. The unit is pretty-much obsolete outside of nutrition (science has switched to SI). Capitalisation is not needed to distinguish the two calories, (in the rare science/technology cases) context is sufficient. Moreover, if there is a conversion to SI, it will be obvious which calorie you mean ... and this is {{convert}}.

JIMp _talk·cont 00:35, 30 May 2011 (UTC)

• U.S. English/Spanish food labels: Because many snack food nutrition labels are used also in Spanish-language cultures, this issue also affects the Spanish WP, where "sp=en" would show "Calories" for the Spanish "Calorías" and perhaps in other languages using Convert option "sp=en" (or "sp=us"). For foods made in the U.S., all nutrition labels are in capitals, so quoted nutrition information could be expected (as English/Spanish):

• Calories/Calorías: 220, Sodium/Sodio: 100 mg, Protein/Proteína: 13 g (etc.).

Hence, when the Calories are sourced to food labeling, the upper-case "Calories" should be typical. Personally, I like the idea that either spelling, "calorie" or "Calorie" means the big Calorie, by default. So, an article should specify when lower-case "calorie" means the small calorie, and I guess that would solve the confusion. Should we have yet another "Convert/cal" (lower-case) which shows "2.65 calories [small]" or with a similar end-note? -Wikid77 19:09, 30 May 2011 (UTC)

Notice how "Sodium" and "Protein" are capitalised too ... this isn't big sodium and big protein, a thousand times the regular kind. It's just because they've chosen to capitalise the row headers (whether we ought to follow that is another question). This kind of thing is reproduced here in some of the food infoboxes but note that it's "Calories: 123" not "123 Calories" (it should be "Energy: 123 Cal (510 kJ)" ... better still "Energy: 510 kJ (123 Cal)"). But, of course, we don't keep the capitalisation in the text (e.g we don't write "Scram Foods Inc reduced the Sodium in its tinned ham by 12%.")

Yes, it would be better if Calorie/calorie were taken to mean the big ones & in the few instances where the small ones are intended, we specify so. This is pretty-much how things are in nutrition articles & the unit is rarely found anywhere else. I mean very rarely ... it might not even be worth the effort to create the {{convert/cal(small)}} you suggest above (not that's it's a bad idea, just that it would hardly be used). JIMp _talk·cont 01:02, 31 May 2011 (UTC)

Proposal

To capitalise or not to capitalise that is the question. Well that the question I posed at MOSNUM. What I talking about here is related but is more concerned with what we are going to do here at {{convert}}. I have proposed a certain plan of attack but perhaps it has got somewhat lost in the essay above. Let me just bring out the highlights.

Point A

Whether we should use Calorie　or calorie for the large calorie (~4.2 kJ) is currently optional at WP.

This point is under discussion at MOSNUM presently but there is no guidance as yet. The relevant international organisations (BIPM, ISO) have nothing to say about it. Usage in the world out there is varied but favours calorie. Usage here currently reflects this.

Point B

A template shouldn't be used to switch between two optional styles.

If a page currently uses meter, using {{convert}} shouldn't force a switch to metre. Thus we have sp=us. Similarly for Calorie　or calorie (until a decision is made at MOSNUM).

Point C

The instances of calorie outnumber those of Calorie by something like fifty to one.

I recently searched WP and found a couple of dozen pages using Calorie for the large calorie as opposed to several hundred (seems like more than a thousand but it was hard to count since in many instances they really mean "food energy").

Point D

It seems reasonable to favour the most common option.

One {{convert|123|Cal(uppercase)}} for every fifty {{convert|123|Cal}}s makes more sense than one {{convert|123|Cal}} for every fifty {{convert|123|Cal(lowercase)}}s.

The plan

So it seems to me be the best plan of attack involves a few edits.

• Edit #1

  Edit {{convert/Cal}} so that it shows calorie (it currently shows Calorie).

• Edit #2

  Edit {{convert/Calorie}} to show Calorie (it currently redirects to {{convert/Cal}}).

• Edits #3, 4, 5 ...

  Use Cal on pages currently using calorie and use Calorie to deal with those 2% of instances where Calorie is used.

Then if a decision is made at MOSNUM, make the appropriate adjustments as follows.

1. If we leave capitalisation optional, leave the edits as described above.
2. If we depreciate capitalisation, leave Edit #1 but revert Edit #2.
3. If we insist on capitalisation, revert Edits #1 and #2.

Note

This plan will involve a couple of edits to protected pages. Edit #1 I had already asked for but was knocked back since it was "controvercial" but by the looks of things noone really seems to care. Moreover Edit #2 would give the capitalisers an option (at least until the decision is made at MOSNUM but they're invited there too).

JIMp _talk·cont 05:47, 1 June 2011 (UTC)

Impact

There are eleven articles using the subtemplates I propose to adjust. Two of them, Bugles and Marshmallow Mateys only uses the abbreviation so they won't be affected at all. One of them, Weight Watchers, uses calories, Calories and even kCal (should be kcal); this article really needs a clean up anyway. Five of them, Bacon, Juicy Fruit, Ranger School, Individual Meal Pack and The Biggest Loser Australia: Couples 2, used to use lower case calorie before {{convert}} was added so this would return things to how they were. Energy bar didn't have anything prior so perhaps a discussion should be made on the talk page. Luther Burger and Heart Attack Grill both have interesting and similar histories. They both started life with calories which were changed for kilocalories before finally ending up with Calories. I brought these goings on up on the talk pages and I also changed from Cal to Calorie so that there would be no immediate change to these articles.

details of Luther Burger history

6:38 am 10 Apr 2006	lower case calories introduced in a merge from Doughnut burger
8:33 pm 26 Feb 2007	this was removed as uncited by Fourthords
8:39 pm 14 May 2009	lower case calories are back again
8:45 pm 19 Oct 2010	Fourthords changed to kilocalories using convert
3:09 pm 20 Oct 2010	VermillionHeavy changes kilocalories to back to calories (in one instance)
8:38 pm 20 Oct 2010	Fourthords reverts VermillionHeavy
2:06 pm 22 Oct 2010	VermillionHeavy reinstates the edit
2:15 pm 22 Oct 2010	VermillionHeavy reverts self (third and final WP action of the user)
4:01 am 30 Oct 2010	Fourthords adds more kilocalories with convert
6:19 pm 31 Oct 2010	Fourthords adds more still in the infobox
3:28 am 20 Dec 2010	Anon reverts back to calories removing convert in the process (but only in one instance)
6:08 am 20 Dec 2010	Anon is reverted by Fourthords
11:21 pm 2 Apr 2011	Anon deletes k in convert call (not realising that it's now the gram calorie)
11:22 pm 2 Apr 2011	The same anon finishes the job
3:27 am 3 Apr 2011	Fourtholds introduces (upper case) Calories
9:18 am 10 Apr 2011	Coppersquare cleans up removing the capitalisation (but not in convert)
7:02 pm 10 Apr 2011	reverted by Fourtholds "for clarity"

details of Heart Attack Grill history

1:15 am 27 Feb 2009	Gargaj introduces lower-case calories
1:08 pm 27 Jul 2009	Lmotter1 deletes the paragraph which has the calories
10:48 pm 27 Jul 2009	After a six-hour edit war Lmotter (who claims to be working for the restaurant, and is later blocked) is reverted.
7:36 pm 16 May 2010	Anon changes calories to kilocalories.
11:19 pm 19 May 2010	Gerrit uses {{convert}} to convert kilocalories.
6:37 pm 3 Jun 2010	Freakshownerd adds another calories (the same numerical value as before) but now we have calories and kilocalories.
2:01 am 25 Jul 2010	Anon changes this 2nd calories to Calories. Now we have Calories and kilocalories.
4:05 am 13 Aug 2010	Anon changes convert code kcal to cal puting the conversion out by a factor of 1000.
4:13 pm 8 Nov 2010	Anon changes cal to Cal. At least the conversion is correct & matches the second mention of the unit.
4:53 pm 9 Dec 2010	Areaseven converts the 2nd "8000 Calories".
7:50 pm 5 Mar 2011	Quicksilver switches from calories with a conversion using {{convert}} (the template was giving calories at the time) to unconverted Calories; he also removes the {{convert}} call for pounds to kilograms but leaving a conversion as text. He must have missed the second calories in the section below. This happens about 10 minutes before coming here asking for this template to be fixed.

JIMp _talk·cont 15:34, 5 June 2011 (UTC)

Request

As I have explained above, there is a problem with how this template deals with kilogram calories. Currently MOSNUM gives no guidance as to whether or not to capitalise calories in the case of the food calorie nor is there anything recomended by any relevant international organisation. Practice in the world is mixed (some capitalise the word & some don't) with preference not to capitalise. Practice on WP reflects this. The question is under discussion at MOSNUM but unitl there is a decision capitalisation should be considered optional. This template only allows capitalisation. I have proposed a solution to this. The solution initially involves edits to two protected subtemplates. Please see the details of these edits below. (I'd numbered the edits #1 & #2 above but it would make sense to do them in the opposite order so I'm listing them backwards.)

Edit #2

Template:Convert/Calorie (edit | talk | history | links | watch | logs)

Copy the code of {{convert/Cal}} and paste it onto {{convert/Calorie}} .

Edit #1

Template:Convert/Cal (edit | talk | history | links | watch | logs)

On {{convert/Cal}} replace the line n=Calorie with n=calorie.

Depending on the decision at MOSNUM, reversions may be necessary.

1. If we decide to keep capitalisation optional, we leave both in place.
2. If we phase capitalisation out, we revert Edit #2.
3. If we insist on capitalisation, we revert both.

JIMp _talk·cont 01:08, 6 June 2011 (UTC)

 Done — Martin (MSGJ · talk) 12:25, 6 June 2011 (UTC)

Ambiguity in documentation

Somebody thought the default settings were US English and the symbolic form. They said they'd read it in the documentation. I know it's wrong but the documentation is somewhat ambiguous and I can see how a brief look could be misleading. The defaults are mentioned for some parameters but not for spelling and full/symbolic formats. How should it be updated? Lightmouse (talk) 16:03, 5 June 2011 (UTC)

How about a section specifically about default settings? I would be repeating what's already there but that's okay. JIMp _talk·cont 16:08, 5 June 2011 (UTC)

Sounds good to me. I can't find a way to describe the default spelling. Other templates call it 'commonwealth' but that isn't the converse of US. Could we have a setting of 'sp=nonUS' and say that's the default? Lightmouse (talk) 16:48, 5 June 2011 (UTC)

Editors choose from 2 unit-codes: LT and lt

• I have had changed WP:MOSNUM (but it was reverted), based on those 23 source books, to show "LT" and "ST" as symbols, so Wikipedia will begin catching up with the 124 years of real-world usage of LT. The missing {u} only occurred for 2-unit ranges (due to smart subtemplates substituting {n}), so other conversions have been displaying correctly this week. Currently:

• {{convert|20.9|t|LT}} → 20.9 tonnes (20.6 long tons)

• {{convert|7|to|20.9|t|LT}} → 7 to 20.9 tonnes (6.9 to 20.6 long tons)

• {{convert|33.9|t|ST}} → 33.9 tonnes (37.4 short tons)

• {{convert|30|or|33.9|t|ST}} → 30 or 33.9 tonnes (33.1 or 37.4 short tons)

Also, another issue is the current default output of Convert/ST as unit-code "t" rather than "t LT" which, I assume, was to focus on "tonne" as the alternative unit. However, I see some infoboxes using long-ton conversions, which is a reason to keep the conversion short to fit infobox widths. There were other related issues, but at least focus on these now, with dozens of other units to consider later. We have to move fast to keep ahead of the problems. -Wikid77 (talk) 13:55, 27 May 2011 (UTC)

I have agreed with Jimp's change, above, to have "LT" always show full name ("long ton"), but an editor can use lowercase "lt" to show symbol "LT" when an article gets tedious in repeating "long ton" and "long ton" when "LT" would be obvious. That satisfies the initial WP:MOSNUM decision to force tons as full names first, and then ("magically") allow symbols when the repeated text gets tedious. Per WP:IAR, the options of Convert can allow greater freedom until WP:MOSNUM is updated, at some point. -Wikid77 15:45, 27 May 2011 (UTC)

Approximate conversions
Metric Customary/ Imperial 1 tonne 1000 kg 1 tonne 0.98 long tons 1 tonne 1.10 short tons

If conversions become tedious, would it not be better to have a conversion box such as the one shown alongside? Not only would this educate readers as to the diffrences between long tons, short tons and tonnes, but would also remove make the text more readable as is shown by considering these three variant of the same sentence taken from Economy of the Falkland Islands:

• "The levels of rock cod taken in the whole of the South Atlantic dropped from 399,700 tonnes in 1969-70, to 101,560 tonnes the following year and 2,740 tonnes in 1971/72"
• "The levels of rock cod taken in the whole of the South Atlantic dropped from 399,700 tonnes (393,400 LT; 440,600 ST) in 1969-70, to 101,560 tonnes (99,960 LT; 111,950 ST) the following year and 2,740 tonnes (2,700 LT; 3,020 ST) in 1971/72"
• "The levels of rock cod taken in the whole of the South Atlantic dropped from 399,700 tonnes (393,400 long tons; 440,600 short tons) in 1969-70, to 101,560 tonnes (99,960 long tons; 111,950 short tons) the following year and 2,740 tonnes (2,700 long tons; 3,020 short tons) in 1971/72"

Martinvl (talk) 15:01, 7 June 2011 (UTC)

Long tons, missing templates when disp=flipped

It seems there are missing templates that deal with combinations of disp=flipped and one or both of adj=on and abbr=none when used with long tons:

• {{convert|150|LT}} -> 150 long tons (150 t)
• {{convert|150|LT|abbr=none}} -> 150 long tons (150 tonnes)
• {{convert|150|LT|disp=flip}} -> 150 tonnes (150 long tons)
• {{convert|150|LT|disp=flip|abbr=none}} -> 150 tonnes (150 long tons)
• {{convert|150|LT|disp=flip|adj=on}} -> 150-tonne (150-long-ton)
• {{convert|150|LT|adj=on}} -> 150-long-ton (150 t)
• {{convert|150|LT|adj=on|abbr=none}} -> 150-long-ton (150-tonne)
• {{convert|150|LT|adj=on|abbr=none|disp=flip}} -> 150-tonne (150-long-ton)

The final one is needed at List of bridge failures. Thryduulf (talk) 12:14, 7 June 2011 (UTC)

I created two redirects. Hope there are no errors. Frietjes (talk) 15:41, 7 June 2011 (UTC)

Acres to hectares

I noticed that:

{{convert|2219791|acres}} → 2,219,791 acres (898,318 ha)

{{convert|49|acres}} → 49 acres (20 ha)

The first example allows a line wrap before ha. –droll [chat] 22:42, 6 June 2011 (UTC)

This appears to be on purpose, see Template:Convert/LoffAonSoff. Frietjes (talk) 23:50, 6 June 2011 (UTC)

I'm not sure why. It seems to me that the simple rule of wrapping if & only if the unit is spelt out in full is best. That's how it was but this new idea is to have things depend on the size of the number. I can see some sense in that but were're not considering the length of the unit symbol/name so "2,000 t" is going to wrap whereas "888 horsepower" is not. Shall we weigh the merits of each? Should we consider adding code to measure the length of the name/symbol? JIMp _talk·cont 00:10, 7 June 2011 (UTC)

It seems to me that code cannot fit every situation and in general the general case should take precedence. I think a line wrap should never be allowed between a the numeric value and the unit name. That's just my opinion. The example is form the infobox in the Yellowstone National Park article. The link is to an archived version. Anyway, I used the {{nowrap}} template to place it in a span block with white-space:nowrap. Thanks for looking into it for me. –droll [chat] 01:21, 7 June 2011 (UTC)

The primary purpose of the template is conversion. It needs to be conservative when preventing local control of secondary issues. Line wrap isn't just a good thing, it's often necessary even within units. If a local editor wants to prevent wrapping, it's easy to add. If we enforce it within the template, it's impossible for a local editor to remove. Lightmouse (talk) 12:48, 7 June 2011 (UTC)

True, however, the editor would only be able to nowrap the entire thing whereas we'd generally want wrapping between input(s) and output(s). JIMp _talk·cont 13:43, 7 June 2011 (UTC)

Indeed. We also need to retain wrapping:

• within a unit name

1,000,000 pounds per square inch (6,900 MPa)

6 miles per hour (9.7 km/h)

• between a spelt out numeric and the unit name

16 billion barrels (2.5 km3)

I suggest we allow wrapping after large numeric values and within the 'x' notation. Compare template version 'A' with the more permissive non-template version 'B'.

A	B
3,000 million barrels (480×10^6 m3)	3,000 million barrels (0.95 × 106 m3)

Lightmouse (talk) 17:57, 8 June 2011 (UTC)

Problems with disp=x and fluid ounces

I've come across some problems trying to use disp=x:

1. Missing template

• {{convert|16|USfloz|ml|0|disp=x|, approximately |0|lk=on}} → 16 US fluid ounces, approximately 470 ml0.

2. rounding parameter errors

At least for conversions from imperial fluid ounces to ml (the above error means I can't see the result for US fluid ounces and I've not tried other combinations), the unnamed rounding parameter is apparently ignored. The output of both these conversions should be 568 ml:

• {{convert|20|impfloz|ml|disp=x|, approximately |sigfig=3|lk=on}} → 20 imperial fluid ounces, approximately 568 ml
• {{convert|20|impfloz|ml|disp=x|, approximately |0|lk=on}} → 20 imperial fluid ounces, approximately 570 ml0
• {{convert|20|USfloz|ml|disp=x|, approximately |sigfig=3|lk=on}} → 20 US fluid ounces, approximately 591 ml
• {{convert|20|USfloz|ml|disp=x|, approximately |0|lk=on}} → 20 floz

Leaving the target units unspecified gives different errors:

• {{convert|20|impfloz|disp=x|, approximately |sigfig=3|lk=on}} → 20 imperial fluid ounces [  ]
• {{convert|20|impfloz|disp=x|, approximately |0|lk=on}} → 20 imperial fluid ounces [  ]
• {{convert|20|USfloz|disp=x|, approximately |sigfig=3|lk=on}} → 20 US fluid ounces [  ]
• {{convert|20|USfloz|disp=x|, approximately |0|lk=on}} → 20 US fluid ounces [  ]

Contrary to the documentation, moving the rounding parameter before the disp=x works/nearly works when the target units are not specified

• {{convert|20|impfloz|sigfig=3|disp=x|, approximately lk=on}} → 20 imperial fluid ounces [ 568 ml; 19.2 US fl oz ]
• {{convert|20|impfloz|0|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces, approximately 568 ml; 19 US fl oz
• {{convert|20|USfloz|sigfig=3|disp=x|, approximately lk=on}} → 20 US fluid ounces [ 591 ml ]
• {{convert|20|USfloz|0|disp=x|, approximately |lk=on}} → 20 US fluid ounces, approximately 591 ml

But doesn't work when they are specified

• {{convert|20|impfloz|ml|sigfig=3|disp=x|, approximately lk=on}} → 20 imperial fluid ounces [ 568 ml ]
• {{convert|20|impfloz|ml|0|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces, approximately 568 ml
• {{convert|20|USfloz|ml|sigfig=3|disp=x|, approximately lk=on}} → 20 US fluid ounces [ 591 ml ]
• {{convert|20|USfloz|ml|0|disp=x|, approximately |lk=on}} → 20 US fluid ounces, approximately 591 ml

In all the cases I've tested, the link being set to on, off or left unspecified links (or not) the units as expected, but does not affect anything else.

3 Link target

There is no article at imperial fluid ounce, just a redirect to imperial units. Like the US units, I think it would be best to link to imperial units and fluid ounce separately. Thryduulf (talk) 02:46, 16 June 2011 (UTC)

Let me try sorting this out. First I'm copying and pasting your list with a couple of changes. I'm labelling each entry, I'm inserting the missing pipe (between "approximately" and "lk=on", C_s & D_s), I'm summarising and I'm converting the errors into text so after they're fixed this section will still make sense.

1. Missing template

1 {{convert|16|USfloz|ml|disp=x|, approximately |0|lk=on}} → Template:Convert/LonAoffDxSoffUSre.

2. rounding parameter errors

A The unnamed rounding parameter is ignored.

2 A_is {{convert|20|impfloz|ml|disp=x|, approximately |sigfig=3|lk=on}} → 20 imperial fluid ounces, approximately 568 ml

2 A_ip {{convert|20|impfloz|ml|disp=x|, approximately |0|lk=on}} → 20 imperial fluid ounces, approximately 570 ml

2 A_us {{convert|20|USfloz|ml|disp=x|, approximately |sigfig=3|lk=on}} → Template:Convert/LonAoffDxSoffUSre

2 A_up {{convert|20|USfloz|ml|disp=x|, approximately |0|lk=on}} → Template:Convert/multi2LonAoffDxSoff

B Leaving the target units unspecified gives different errors:

2 B_is {{convert|20|impfloz|disp=x|, approximately |sigfig=3|lk=on}} → 20 imperial fluid ounces [ Template:Convert/, approximately ]

2 B_ip {{convert|20|impfloz|disp=x|, approximately |0|lk=on}} → 20 imperial fluid ounces0Template:Convert/, approximately

2 B_us {{convert|20|USfloz|disp=x|, approximately |sigfig=3|lk=on}} → Template:Convert/LonAoffDxSoffUSre

2 B_up {{convert|20|USfloz|disp=x|, approximately |0|lk=on}} → Template:Convert/LonAoffDxSoffUSre

C Moving the rounding parameter

2 C_is {{convert|20|impfloz|sigfig=3|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces [ Template:Convert/, approximately ]

2 C_ip {{convert|20|impfloz|0|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces, approximately 568 ml; 19 US fl oz

2 C_us {{convert|20|USfloz|sigfig=3|disp=x|, approximately |lk=on}} → Template:Convert/LonAoffDxSoffUSre

2 C_up {{convert|20|USfloz|0|disp=x|, approximately |lk=on}} → Template:Convert/LonAoffDxSoffUSre

D But doesn't work when they are specified

2 D_is {{convert|20|impfloz|ml|sigfig=3|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces, approximately 568 ml

2 D_ip {{convert|20|impfloz|ml|0|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces0570 ml

2 D_us {{convert|20|USfloz|ml|sigfig=3|disp=x|, approximately |lk=on}} → Template:Convert/LonAoffDxSoffUSre

2 D_up {{convert|20|USfloz|ml|0|disp=x|, approximately |lk=on}} → Template:Convert/LonAoffDxSoffUSre

3. It would be better to link to the system & the unit seperately.

I'll be back JIMp _talk·cont 06:35, 16 June 2011 (UTC)

There are a number of things going on here.

• Firstly, no, |disp=x doesn't yet work for gallon-based units (fluid ounce, pint, etc. i.e. US or imperial units of volume not including the cubes of length units ei. cubic inch, cubic foot, etc.).
• It seems to be working for the imperial fluid ounce ... yes, the template has ... let's say "forgotten" that the impfloz is an imperial unit (note that it remembers what the impoz is) and treats it like any ordinary unit.
• An adverse effect of this forgetting is that the linking has gone awry. Compare impfloz → 20 imperial fluid ounces (570 ml) to impoz → 20 imperial fluid ounces (570 ml).
• Without getting bogged down with technical details, let me say that I've got a plan to help the template remember ... but it'll take a little time.

More later. JIMp _talk·cont 20:58, 16 June 2011 (UTC)

Let's then have a closer look at point 2. Let me try wittle away at these sixteen points.

• Let's ignore the US fluid ounce inputs since, as noted above, |disp=x doesn't yet work for gallon-based units. So let's consider only the eight ordinary input units (the imperial fluid ounces).
• The position of named parameters doesn't matter. Unnamed parameters are numbered according to where they appear with respect to each other. Thus moving |sigfig=3 around has no effect. 2 A_is is therefore identical to 2 D_is, {{convert|disp=x|sigfig=3|lk=on|20|impfloz|ml|, approximately }} would likewise be the same (unnamed parameter 1 is "20", unnamed parameter 2 is "impfloz", etc.). Similarly 2 B_is is identical to 2 C_is. So now we're down to six: two (include "ml" or not) times three ("|0" before "|, approximately ", "|0" after "|, approximately " or "|sigfig=3" instead of "|0").

So here's what we've got left.

A The unnamed rounding parameter is ignored.

2 A_is {{convert|20|impfloz|ml|disp=x|, approximately |sigfig=3|lk=on}} → 20 imperial fluid ounces, approximately 568 ml

2 A_ip {{convert|20|impfloz|ml|disp=x|, approximately |0|lk=on}} → 20 imperial fluid ounces, approximately 570 ml

B Leaving the target units unspecified gives different errors:

2 B_is {{convert|20|impfloz|disp=x|, approximately |sigfig=3|lk=on}} → 20 imperial fluid ounces [ Template:Convert/, approximately ]

2 B_ip {{convert|20|impfloz|disp=x|, approximately |0|lk=on}} → 20 imperial fluid ounces0Template:Convert/, approximately

C Moving the rounding parameter

2 C_ip {{convert|20|impfloz|0|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces, approximately 568 ml; 19 US fl oz

D But doesn't work when they are specified

2 D_ip {{convert|20|impfloz|ml|0|disp=x|, approximately |lk=on}} → 20 imperial fluid ounces0570 ml

I've noted that the positions of named parameters doesn't matter, so let's move all of them to the end.

2 A'_is {{convert|20|impfloz|ml|, approximately |sigfig=3|disp=x|lk=on}} → 20 imperial fluid ounces, approximately 568 ml

2 A'_ip {{convert|20|impfloz|ml|, approximately |0|disp=x|lk=on}} → 20 imperial fluid ounces, approximately 570 ml

2 B'_is {{convert|20|impfloz|, approximately |sigfig=3|disp=x|lk=on}} → 20 imperial fluid ounces [ Template:Convert/, approximately ]

2 B'_ip {{convert|20|impfloz|, approximately |0|disp=x|lk=on}} → 20 imperial fluid ounces0Template:Convert/, approximately

2 C'_ip {{convert|20|impfloz|0|, approximately |disp=x|lk=on}} → 20 imperial fluid ounces, approximately 568 ml; 19 US fl oz

2 D'_ip {{convert|20|impfloz|ml|0|, approximately |disp=x|lk=on}} → 20 imperial fluid ounces0570 ml

Now let's arrange these according to the kind of error we find.

No error.

2 A'_is {{convert|20|impfloz|ml|, approximately |sigfig=3|disp=x|lk=on}} → 20 imperial fluid ounces, approximately 568 ml

2 C'_ip {{convert|20|impfloz|0|, approximately |disp=x|lk=on}} → 20 imperial fluid ounces, approximately 568 ml; 19 US fl oz

These are working fine.

The template is trying to call the non-existant page "Template:Convert/, approximately ".

2 B'_is {{convert|20|impfloz|, approximately |sigfig=3|disp=x|lk=on}} → 20 imperial fluid ounces [ Template:Convert/, approximately ]

2 B'_ip {{convert|20|impfloz|, approximately |0|disp=x|lk=on}} → 20 imperial fluid ounces0Template:Convert/, approximately

We note that the software can distinguish between a number and a piece of non-numerical text but not between a unit and ordinary text. The template is treating ", approximately " as a unit to convert to.

The fifth unnamed parameter has gone missing.

2 A'_ip {{convert|20|impfloz|ml|, approximately |0|disp=x|lk=on}} → 20 imperial fluid ounces, approximately 570 ml

2 D'_ip {{convert|20|impfloz|ml|0|, approximately |disp=x|lk=on}} → 20 imperial fluid ounces0570 ml

The template is rounding according to the default, inserting unnamed parameter four as text and ignoring the fifth unnamed parameter.

So, where are we? With |disp=x the fourth unnamed parameter is the text which gets inserted and the third is either the unit to convert to or the precision to round to ... we cannot, however, specify both. JIMp _talk·cont 03:36, 17 June 2011 (UTC)

What's a good solution to this problem? What if we made it such that with |disp=x the last two unnamed parameters are always the text to insert (before & after), then after picking this one off treat the rest of the unnamed parameters as usual? How's that grab ya? JIMp _talk·cont 05:03, 17 June 2011 (UTC)

Another problem is that not all units are ready for disp=x (impfloz wasn't). JIMp _talk·cont 06:24, 17 June 2011 (UTC)

Thank you for your work on this. The documentation states that "Any rounding-parameter should follow the mid-text: "text|0".", but this is in the context of using mid text with an adjectival form. It should logically follow that the rounding parameter should follow the midtext when not using the adjectival form also (I included it both before and after for testing purposes only really) but there is no documentation for this condition. I don't know whether this fits your proposal or not.

The most obvious alternative solution to my mind is making the rounding parameter optionally named. I recall reading somewhere though that this would be a massive amount of work. Thryduulf (talk) 08:27, 17 June 2011 (UTC)

spelling parameter

One thing that's bothered me for ages is that the spelling parameter uses "US". The problem is that calling out the alternate spelling as being of nationalistic origin is bound to bring up antagonism, and it's apparent that it has over the years (based on talk page comments here and on article talk pages). Can we please provide a more neutral alternative parameter value to use? Thanks.
— V = IR (Talk • Contribs) 23:23, 16 June 2011 (UTC)

Do you have any suggestions for an alternative name? The variety of English called by the "US" parameter is usually called "US English" or "American English", so it isn't wrong. This doesn't mean it can't be improved though. Thryduulf (talk) 00:27, 17 June 2011 (UTC)

But ... Ohms ... with respect, it is of US origin ... right? The antagonism, as I recall it, was not over calling this spade a spade but over the fact the template defaults to the shovel ... and spades ... are ... better ... or something ... What should we do? How about sp=Webster? JIMp _talk·cont 00:41, 17 June 2011 (UTC)

Not really (English spelling reform has a long and varied history), but that's beside the point. One option might be to use "alt". Anything to avoid an nationalistic designator, though.
— V = IR (Talk • Contribs) 00:49, 17 June 2011 (UTC)

Yes, true enough, there's a long history of variation in English history. But these days American's write "meter" & the rest of us write "metre" ... pretty consistantly. Using alt would be less descriptive (thus unintuitive) &, if you ask me, more contentious: suggesting that American spelling is the alternative whereas Commonwealth spelling is the standard, better just call your spadish thing a thing which resembles a spade. JIMp _talk·cont 01:29, 17 June 2011 (UTC)

Meh, whatever. It's not that important.
— V = IR (Talk • Contribs) 03:10, 17 June 2011 (UTC)

I suggest 'sp=er'. That would have several advantages:

• It's nearer to a description of what it does. There is another parameter that is one step removed from doing what it says: the 'adj' parameter and I've always disliked that name.
• It'll reduce the chance of invalid use. As far as I know, it's only valid on 'er/re' terms. Users sometimes put it on other terms like 'lb'. Understandably, not all users know the scope of US/nonUS spelling variation.
• It has a logical inverse 'sp=re' which will allow us to describe the default. The documentation doesn't describe the default and at least one user thought the template default is US (as the case the 'ft to m' templates).

Lightmouse (talk) 08:07, 17 June 2011 (UTC)

lb to kN

There appears to be something wrong with lb to kN (kilonewton) and vice versa. Take a look at the following two uses of the template:

• {{convert|1|lb|kN}} yields: {{#ifeq:|on|<span style="display:none">{{padleft:{{FORMATNUM:1|R}}|16|0}}{{#ifeq:{{#expr:(kN)*0}}|0|{{padleft:{{FORMATNUM:kN|R}}|16|0}}}}</span>}}{{convert/{{#if:1|lb}}|{{FORMATNUM:1|R}}|{{#ifeq:{{#expr:kN*0}}|0|0}}|kN||||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LoffAoffDbSoff|s=}}; but should be 1 pound = 0.00444822162 kilonewtons
• {{convert|1|kN|lb}} yields: {{#ifeq:|on|<span style="display:none">{{padleft:{{FORMATNUM:1|R}}|16|0}}{{#ifeq:{{#expr:(lb)*0}}|0|{{padleft:{{FORMATNUM:lb|R}}|16|0}}}}</span>}}{{convert/{{#if:1|kN}}|{{FORMATNUM:1|R}}|{{#ifeq:{{#expr:lb*0}}|0|0}}|lb||||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LoffAoffDbSoff|s=}}; but should be 1 kilonewton = 224.808943 pounds

Does anyone know where the problem is? Thanks. WTucker (talk) 00:47, 17 June 2011 (UTC)

The template assumes you mean pounds mass. You want pounds force, lbf:

• {{convert|1|lbf|kN}} → "1 pound-force (0.0044 kN)"
• {{convert|1|kN|lbf}} → "1 kilonewton (220 lbf)"

JIMp _talk·cont 01:21, 17 June 2011 (UTC)

O.K. The problem is with me -- I should have known. Thanks. WTucker (talk) 03:42, 17 June 2011 (UTC)

Whole units

Is there a way to avoid decimal fractions in this template's distance results, so that instead of providing 76 kilometres (47.224 miles), it would give something like 76 kilometres (47 miles, 1,182 feet)? (I did intentionally manipulate this example to provide a decimal fraction, but I wanted to illustrate the question).
— V = IR (Talk • Contribs) 23:35, 16 June 2011 (UTC)

So, you want something analogous to 10 metres (32 ft 10 in) instead of 10 metres (32.81 ft)? That is certainly possible. We would just need to create Template:Convert/mift, for example. Plastikspork _―Œ^(talk) 00:01, 17 June 2011 (UTC)

Yup, exactly.
— V = IR (Talk • Contribs) 00:49, 17 June 2011 (UTC)

Are you thinking of simplifying conversion of the marathon distance of 42.195 metres perhaps? Lightmouse (talk) 08:10, 17 June 2011 (UTC)

lol happy coincidence. Or, er... no, wait, that's exactly what I was thinking of! Aren't I clever? :D
— V = IR (Talk • Contribs) 15:36, 18 June 2011 (UTC)

• So, anyway, I'm willing to do the work here with a little bit of handholding to get me going. I've yet to add to the convert template repertoire, so I'm not exactly certain where to start with a new sub-template (Template:Convert/mift appears to be a good candidate). I know how to do the math, and I'm an... intermediate template scripter, I'd say. I just need to know what to do to make the sub-template properly work with the system.
  — V = IR (Talk • Contribs) 04:15, 21 June 2011 (UTC)

Ohms, I've got the ball rolling for you. Click on the link & see how you go. JIMp _talk·cont 05:45, 21 June 2011 (UTC)

cool, thanks. Working on it. :)
— V = IR (Talk • Contribs) 19:21, 21 June 2011 (UTC)

man... we need to write up some developer docs for this template. I'm lost... I can see the b(j) relationship, sort of (b is for the conversion of inches to meters, so... I'm not sure. j appears to be the inverse of some sort of conversion factor, maybe?). what's worse though is that I can't quite see where the letter parameters are coming from. So, I see what you're trying to tell me, but I'm not quite able to use that. :(
I just found Wikipedia:Advanced Convert coding#Defining new conversion subtemplates, so... gimme one minute. :)
— V = IR (Talk • Contribs) 20:22, 21 June 2011 (UTC)

part way there (I understand the basic parameters now, more or less), but I'm still lost. See: User:Ohms law/Convert for what I've done so far.
— V = IR (Talk • Contribs) 21:06, 21 June 2011 (UTC)

I've given you a couple more hints (on the page you mention). JIMp _talk·cont 00:03, 22 June 2011 (UTC)

Cool, thanks. Looking it over now. :)
— V = IR (Talk • Contribs) 00:08, 22 June 2011 (UTC)

Ah hah! I had a sneeking suspicion that j was some sort of log function! haha!
— V = IR (Talk • Contribs) 00:11, 22 June 2011 (UTC)

Problem with disp=x using hectare/acre

When using disp=x for acre/hectare, the second bracket (or parenthesis) will not show.

• {{convert|20|ha|acre|disp=x| [|]}} → 20 hectares [49 acres]
• {{convert|20|ha|acre|disp=x| [|]}} → 20 hectares about (49 acres)
• {{convert|20|acre|ha|disp=x| [|]}} → 20 acres about [8.1 ha]

But using other units, it works.

• {{convert|20|m|ft|disp=x| [|]}} → 20 metres [66 ft]
• {{convert|20|lb|kg|disp=x| [|]}} → 20 pounds [9.1 kg]
• {{convert|20|mi|km|disp=x| [|]}} → 20 miles [32 km]

Would you happen to know the solution to this problem? Thanks - Briarfallen (talk) 19:34, 18 June 2011 (UTC)

Yes, disp=x requires edits to the unit pages. Not all pages are done yet. JIMp _talk·cont 22:52, 18 June 2011 (UTC)

New error

I am not sure why this suddenly stopped working, but currently {{Convert|11|hand|m}} is showing errors, but {{Convert|11|hand|m|2}} works. When it's fixed, there should be no red errors here: 11 hands (1.1 m). Thank you. Frietjes (talk) 18:00, 23 June 2011 (UTC)

Strange, I'll look into it. JIMp _talk·cont 19:17, 23 June 2011 (UTC)

Strange error

I added the template but it produced a read error. Can anyone tell what's wrong with it? Lightmouse (talk) 09:57, 29 June 2011 (UTC)

I fixed it with {{convert|18|by|15|mm|in|1|abbr=on}}, which gives 18 by 15 mm (0.7 by 0.6 in). I've come across it before, but I haven't a clue why it needs both the target unit and the precision. Is it a bug or a feature? Tim PF (talk) 21:47, 29 June 2011 (UTC)

I believe it's a bug caused by the template nesting limit which the wikimedia people have put in place. JIMp _talk·cont 23:25, 29 June 2011 (UTC)