Template talk:Convert/Archive June 2008

Bot to convert cum to m3 within the template

I have trial approval to run a bot. One of its task will be to modify template code. This will have no effect on the visible page but will make the edit mode more wysiwyg, easier to explain, and more extendable. For example, cucm will be replaced by cm3.

Jimp, can you give me a list of the relevant subtemplates that deal with squares and cubes that you would like me to tackle? Lightmouse (talk) 22:06, 4 June 2008 (UTC)

Per conversion, source unit value one

I've used the template in the following way in the Blackburn article:

"...land purchased from Joseph Fielden, lord of the manor, for £50 per {{convert|1|acre|ha|lk=on}} in 1855."

This renders as "1 acre (0.40 ha)", but I would prefer "acre (0.40 ha)", with the "1" not present. Is this possible with the template? And if it isn't, should it be? Beejaypii (talk) 16:19, 5 June 2008 (UTC)

What you really need is '£x per lb' (£y/kg). Lightmouse (talk) 16:53, 5 June 2008 (UTC)

Hmmm, I think '£x per acre' (£y/ha) would be more appropriate in the case I've described above. Anyway, can I assume that what I'm trying to achieve is not possible with the template and I therefore won't be able to use it on this occasion? Beejaypii (talk) 12:07, 6 June 2008 (UTC)

Yep, it's "£x per pound (£y/kg)" or "£x/lb (£y/kg)". Coincidentally, the thought crossed my mind a couple of weeks ago & I've begun dreaming up a solution. It can't be done yet. It won't be doable anytime this month. It's not impossible but it'll take some time to impliment. Stick around though because it will be doable sometime ... at least for the more common currency per unit combinations. JIMp _talk·cont 17:17, 6 June 2008 (UTC)

Ok, thanks for the responses. I'll keep this on my watchlist and await further developments. Beejaypii (talk) 00:14, 7 June 2008 (UTC)

US Dollar inflation

Could someone build in a function to convert an amount of US Dollar from a given year to current value (or value from another given year)? Template:US Inflation produces a factor if feeded with a year, like {{US Inflation|year=1950}} produces , which means $100 (1950) equal $895.14 (2008).

Is it possible to enhance {{Convert}} with a function like this: {{Convert|100|USD 1950|USD 2008}}? ––Bender235 (talk) 13:09, 7 June 2008 (UTC)

This already exists. I've done such a template a few weeks ago: {{Inflation}}. It also has inflation data for UK and DE, and adding new countries is pretty easy too. -- alexgieg (talk) 23:14, 7 June 2008 (UTC)

Wow. Thanks. —Bender235 (talk) 08:21, 8 June 2008 (UTC)

It could have been done but since another template already exists why not use that? JIMp _talk·cont 23:33, 8 June 2008 (UTC)

Large Masses

Is there a unit for million pounds or billion pounds (e.g. for use with mining and ores)? If not, I would like to suggest new units defined Mlb for millions of lbs and Blb for billions of lbs. Also, could you please define kt = kilotonne and ?? = megatonne.

Today's usage:

{{convert|80000|t|lb}}

{{convert|180000000|lb|t}}

Becomes

80,000 tonnes (180,000,000 lb)

180,000,000 pounds (82,000 t)

Requested usage:

{{convert|80000|t|Mlb}}

{{convert|180|Mlb|t}}

{{convert|80000|t|Blb}}

{{convert|180|Blb|t}}

Becomes

80,000 tonnes (180 million lb)

180 million pounds (80,000 t)

80,000,000 tonnes (180 billion lb)

180 billion pounds (80,000,000 t)

Kgrr (talk) 05:03, 29 May 2008 (UTC)

It's going to take a bit of a door-to-door sales pitch to get editors to finally switch from kt to kn for knot ... or perhaps I should just go the sledgehammer approach and give 'em a big red message for a couple of weeks. The symbol for megatonne is "Mt" and, unlike kt, Mt is empty. I have to say that I'd prefer Glb (i.e. G for "giga-") for consistancy's sake. Also note that if a number is spelt out, then so should the unit be. Thus we shouldn't have "180 billion lb". Instead what I'll do is have it written out in engineering notation (i.e. 180×10⁹ lb) when the unit is abbreviated like we've got with the large numbers of cubic metres & cubic feet. JIMp _talk·cont 05:32, 29 May 2008 (UTC)

• Getting users to switch from 'kt' to 'kn': Coincidentally, a few days ago I requested bot approval to convert existing templates from 'kt' to 'kn'. New ones will appear but the bot could be run again later. No user action will be required for that. Some users will see their own edits converted and notice the change. Others may not. Documentation will need to be updated to warn of the end of knot as 'kt'. After it has gone for a couple of months, it could be switched back on as kilotonne. Lightmouse (talk) 08:06, 29 May 2008 (UTC)

• Now that we are using k, M, G, and T within the template, I think it is also best to recommend km2 over sqkm within the template. This will make it more wysiwyg, easier to explain, and more extendable. For example, kg/cm2 is better than kg/sqcm. My bot proposal is to address that too.

I would welcome support for the bot proposal at the link I gave. Lightmouse (talk) 08:06, 29 May 2008 (UTC)

Great! I've been thinking of a different solution but they don't conflict. Seeing as most of these kts appear in a certain ship infobox, I've been thinking about rewriting that particular template. It's protected but once I've got the new version up and running it'll surely be welcomed. But now I've got to thinking about a metatemplate to make the update & updates of other info boxes a damn-sight easier. {{Convert}} will no longer have to be transcluded on the the page (within the info boxes) directly. I'll keep you updated (here). JIMp _talk·cont 08:46, 29 May 2008 (UTC)

Would you be kind enough to leave a note on the bot request page indicating your support? If you do support it, of course. Lightmouse (talk) 19:46, 29 May 2008 (UTC)

Mlb for million pounds and Glb for billion pounds are rather non-traditional. I would suggest e6lb (10⁶lb) for million pounds and e9lb (10⁹lb) for billion pounds (assuming you use American billions and not European billions). There are limits to how far you can go band-aiding these old traditional units for the 21st century. They really should use kilotonnes (kt) and megatonnes (Mt) since nobody but the USA officially uses pounds any more. Since kt has been been preempted for kilotonne by international standards organizations, US, Canadian and other marine authorities prefer kn. RockyMtnGuy (talk) 22:56, 29 May 2008 (UTC)

Then let it be e3lb, e6lb, etc. That was my second choice. It's probably clearer that way since attatching SI prefixes to non-metric units is not the commonly done thing & you're bound to run into strife somewhere with ambiguity I s'pose. We could extend this to other things e.g. e3mi for a thousand miles, e12km for a billion kilometres but call it a trillion since the original (i.e. European) definition is falling out of use in English. JIMp _talk·cont 00:08, 30 May 2008 (UTC)

Jimp, that's certainly a solution that sounds very workable. Could you please let me know when the new units are available? Kgrr (talk) 13:54, 3 June 2008 (UTC)

They're working. The new codes are:

• e3lb
• e6lb
• e9lb
• e12lb
• kilotonne
• Mt

The kilotonne code is just a filler whilst kt is being swapped over. I except it'll be deleted in time. JIMp _talk·cont 19:14, 9 June 2008 (UTC)

Your bot is damaging articles

Moved from User talk:Lightmouse: begin
Your bot is substituting kn for knot. This is about as helpful as substituting 'B' for 'A'. Please desist.--Toddy1 (talk) 04:17, 6 June 2008 (UTC)

Moved from User talk:Lightmouse: end

Toddy1, you may be able to look elsewhere on this page for details of this. Jimp, can you please reassure Toddy1 that this is what is wanted. Lightmouse (talk) 08:31, 6 June 2008 (UTC)

Lightmouse, please stop your bot's run converting "knot" to "kn" in template {{convert}}. If "knot" works in the template, I can see no compelling reason to change it. What your edits are doing is clogging my watchlist with insignificant changes, and changing an easily identifiable unit—from the perspective of editors—to a more obscure abbreviation. — Bellhalla (talk) 12:37, 6 June 2008 (UTC)

Thanks for your comments. Please read the discussion above between myself and Jimp. Lightmouse (talk) 12:49, 6 June 2008 (UTC)

All I see is subbing "kn" for "kt" for the unit knot. Where is the discussion—and consensus, I might add—for this change? This affects a huge number of WP:SHIPS articles, and clogging, I suspect, many a watchlist for no net gain. — Bellhalla (talk) 13:03, 6 June 2008 (UTC)

Please search for kt on this page and on wp:mosnum. Trying to help. Lightmouse (talk) 13:07, 6 June 2008 (UTC)

Again, I will say: all I see is discussion for subbing "kn" for "kt". I saw, read, and understood the reasoning behind changing from "kt" to "kn", and wholeheartedly agree with making a change from an ambiguous abbreviation to a non-ambiguous abbreviation. What I don't see, and what I have been commenting about is the change of "knot" (note the spelled out word) to the abbreviation of "kn". I will again point out that I see no discussion or consensus to make that specific change. Because "knot" works in the template, and does help editors know that the unit is, in fact, the correct, non-ambiguous unit, I see zero compelling evidence that this change is beneficial.

Also, please don't edit my comments by removing indentation. That's pretty bad form. — Bellhalla (talk) 13:23, 6 June 2008 (UTC)

I too feel that the bot really isn't doing anything helpful. And, as Bellhalla states, I logged on this morning to see practically every ship article in my watchlist (literally, every ship here and then some) pinged with a bot edit. Granted, it's easy to just hit the "hide bot edits" button to clean it out, but then there's the issue of the non-Lightbot edits I might want to see. Again, it's unneeded disruption of many watchlists, for no real reason. It's far better to have "knot" in an infobox than "kn". Parsecboy (talk) 13:45, 6 June 2008 (UTC)

I see where Bellhalla is coming from in this...there was no reason to replace "knot" with "kn" when "knot" also works and is *not* going to eventually be replaced with something else, as "kt" will be. If this is what was occurring, then I agree that it was a very unnecessary action and would suggest not doing this in the future. — Huntster (t • @ • c) 14:04, 6 June 2008 (UTC)

I understand that you are unhappy. There are inconsistencies in the convert template and there are discussions on this page about this issue. The edits are a good faith attempt to improve things. Multiple indents make comments less accessible on a small screen so I moved some indents so that I can read what you write. I have stopped editing knots for the time being. We can see what other people say. Trying to help. Lightmouse (talk) 14:06, 6 June 2008 (UTC)

From what I reviewed of Lightbot's edits, offhand I see nothing besides the "knot"->"kn" issue that would be a problem, and that seems to be the only concern here (I agree, "kt" does need to be transferred to "kn" for clarity and consistency). On a separate note, regarding the indentation thing, I too believe this should not be done, since indentations are used to denote conversation threading. If you want to start a de-indented line, that's fine, but please do not refactor the positioning of other editors comments. — Huntster (t • @ • c) 14:15, 6 June 2008 (UTC)

Thanks for the reply. With regard to indents, this might mean that I will be unable to see some responses using my small device. It is somewhat frustrating for me. Try reading a wikipedia talk page with multiple indents on a 2 cm screen and you will see what I mean. Lightmouse (talk) 14:25, 6 June 2008 (UTC)

I completely understand your concern, but it is a matter of etiquette not to modify other's comments. The best you can hope for is, in my opinion, that you will set a trend or standard at some point and others will begin following suit. To be honest, the screen size issue is the biggest reason why I outright refuse to use internet-enabled phones *grin* — Huntster (t • @ • c) 14:40, 6 June 2008 (UTC)

Thanks for the reply. I try to be polite and regard etiquette as important. Modifying the text of a comment is indeed bad. I was merely moving it left by a few millimetres. It had not occured to me that people would be offended by that. Some people are not, but it seems some are. I will bear that in mind. Small screen devices are great for enabling internet access at times of enforced idleness such as 2 hours in an airport or on a train. They are unlikely to achieve the productivity of large static devices but it does mean that I can read and possibly respond to something 10 hours earlier than I could otherwise. As you can see, I am sold on the concept and look forward to internet enabled spectacles that will give the large virtual screen. Thanks for the feedback. Lightmouse (talk) 14:50, 6 June 2008 (UTC)

"kt" → "kn" is required (and doesn't involve a huge number of articles—I've been keeping my eyes on the "kt"s—the same eye just counted them, there are seven articles left. as for "knot", there are 49 articles). Clogging up watchlists for a while is a bad thing. Streamlining {{convert}} is a good thing. Where do we find the balance? Maybe the bot's had another possitive effect: perhaps it's drawn attention to the fact that "kt" is to be reassigned. It would have been reassigned months ago if only I'd got around to properly advertising the fact. Can we call the iron hot now?

If my memory serves me correctly, the knot is the only unit for which there exists a well known abbreviation but with the option to spell it out in full in {{convert}}'s code. Remember that this option is made use of in a whole 49 articles. That's 49 out of 3419 articles which use the template to convert to or from knots. Granted there may be some advantage in having the unit spelt out in full in the article code but there are only 49 left ... I'm not sure how many articles there were before Lightbot but I don't recall that there were ever that many. Shall we let Lightbot finish them off? JIMp _talk·cont 18:04, 6 June 2008 (UTC)

Jimp, unless the intention is to delete the redirect at {{Convert/knot}}, the "knot"-to-"kn" conversions are a case of trying to "fix" a redirect that is not broken. See the WP:R#NOTBROKEN guideline, specifically item 5 "Someone finds them useful". As far as being 'just 49' articles, I had at least as many more on my watchlist that had previously been converted. I will again reiterate that I completely understand and concur with the "kt" to "kn" conversions and am in no way disputing or commenting on that aspect. — Bellhalla (talk) 13:07, 7 June 2008 (UTC)

If knot is deemed useful enough to keep, then let it be kept. If not, then let it be deleted. The argument for deletion: streamlining. The argument against: more readable code. A point worth noting: no other units (or few) have the spell-out-in-full option ... why should this one ... but then, why not? Another point: there are only 49 articles using this code ... but how much of this is due to Lightbot as opposed to a preference of editors to use kn? I'm not opposed to keeping knot if we want to keep it. If not, though, let it be deleted. JIMp _talk·cont 04:29, 9 June 2008 (UTC)

Lightmouse, quick question: why was Lightbot only replacing metric squares and cubes, and not "sqft -> ft2"? Wouldn't it be more logical and intuitive for both units to be formatted similarly? (Sorry if this has already been hashed.) — Huntster (t • @ • c) 22:41, 6 June 2008 (UTC)

I asked for guidance at Template_talk:Convert#Bot_to_convert_cum_to_m3_within_the_template. Feel free to make suggestions in that section. Lightmouse (talk) 00:01, 7 June 2008 (UTC)

Huntster, when this template was created, things with numbers in them like m3, km2 were avoided in the code itself. I think it was to avoid situations where the numbers were next to each other; i.e. km2|2, but I can't remember exactly. However, the resulting symbols were always displayed correctly no matter how the code was input, e.g. km², m², m³. Lightmouse is just trying to make the code wysiwyg, therefore following that logic only the metric should be changed. regards, —MJCdetroit ^(yak) 00:50, 8 June 2008 (UTC)

Yeah, I remember the reason that was set up (the sqm, sqkm thing...been watching this template since it was made, hehe), but I wasn't thinking about how the output for metric differed from Imperial/U.S. Apologies Lightmouse :) — Huntster (t • @ • c) 01:09, 8 June 2008 (UTC)

WP:MOSNUM currently says

For areas and volumes, squared and cubed US customary or imperial length units may instead be rendered with sq and cu between the number and the unit symbol (write 15 sq mi and 3 cu ft, not 15 mi sq and 3 ft cu).

Thus is "mi²", "ft³", etc. now an option? And if so, should mi2, ft3, etc. give this instead of "sq mi", "cu ft", etc.? Or is this some non-policy that slipped through in the latest MOSNUM tempest? JIMp _talk·cont 04:38, 9 June 2008 (UTC)

At the moment, I don't think so. For consistency, we should display the way that we have been [sq ft; cu ft...], which is the most common way imperial units are encountered by the general public. It is important to LM that the metric inputs not be sqkm, sqm... I've always maintained that as long as they displayed correctly; I was indifferent and I maintain that belief with imperial units as well. Consistency is a good thing and if it ain't broke don't fix it. —MJCdetroit ^(yak) 13:38, 9 June 2008 (UTC)

I am not trying to change the policy. I am merely trying to make the whole thing more wysiwyg and predictable. Thus the sqxx format gives 'sq xx' and the xx2 format gives xx². To maintain a ban on mi² and sqkm, we would have to somehow prevent users from using the corresponding mi2 and sqkm code options. It is a possibility that is available to us, particularly right now. I was never comfortable with having mi2 and sqkm as codes. As this template gets larger, I think it is more important to consider things like this. Just a thought. Lightmouse (talk) 18:17, 9 June 2008 (UTC)

kt depreciated

I've disconnected the redirect from {{convert/kt}} to {{convert/kn}}. Try kt and you'll get

{{Convert}} no longer accepts kt as code for the knot. The code kt will be reassigned for the kilotonne. Please use kn instead. Please refer to {{convert}}'s talk page for the reasoning behind this. Sorry for any inconvenience.

JIMp _talk·cont 21:18, 9 June 2008 (UTC)

"Comment" feature

First off, can I just say this template is incredible? It's so rare in this world to see something work absolutely correctly.

I have a suggestion for a feature. The article for Philadelphia, Pennsylvania has the sentence:

According to the United States Census Bureau, the city has a total area of 142.6 square miles (369.4 km²), of which 135.1 square miles (349.9 km²) is land and 7.6 square miles (19.6 km², 5.29%) is water.

That last measurement includes a percentage, unrelated to the measurement. Rather than format it like 7.6 square miles (19.6 km²) (5.29%), it would be nice to have them in the same set of parentheses. Maybe there could be a comment feature for including arbitrary text inside the parentheses (offset by a comma), so something like {{convert|7.6|sqmi|sqkm|comment=5.29%}} would show up as above. What do you think? —Werson (talk) 03:18, 11 June 2008 (UTC)

Some things are easy, some a bit difficult, a few quite difficult and the odd one impossible. It's not impossible but adding this would be a little tricky. JIMp _talk·cont 03:10, 12 June 2008 (UTC)

"Between" question

Greetings to the template masters! Is there a syntax for the convert template to handle the "between" or "from" case, in this instance "between 60 and 170 kg (132 - 375 lb)", alternatively "from 60 to 170 kg (132 - 375 lb)"? Thanks! Franamax (talk) 01:12, 30 May 2008 (UTC)

I've been holding out on it since it's only half done but ...

{{convert|60|and|170|kg}} gives "60 and 170 kilograms (130 and 370 lb)"

{{convert|60|to|170|kg}} gives "60 to 170 kilograms (130 to 370 lb)"

The long anticipated range functionality. JIMp _talk·cont 01:36, 30 May 2008 (UTC)

Took it out for a test drive - sweet. Nice work. It would be nice to have the option of a dash (or em-dash or whatever) instead of the "and" in the secondary, since the repetitive word is not strictly necessary. But hey, thanks for the enhancement! Franamax (talk) 01:51, 30 May 2008 (UTC)

Ahh, looking at the diffs here, you're already on that. Carry on MacDuff, and damned be he who cries "halt, enough" :) Franamax (talk) 02:01, 30 May 2008 (UTC)

Initially I had thought of using to wherever the unit is spelt out and an en-dash (not an em-dash per MoS) wherever the abbreviations/symbols were used, however, we'd have run into strife with negative temperatures: minus sign n en-dash minus sign m degrees Celsiheit looks pretty bad. That's why the repetition of the conjunctive word was made put in place. There is the optiojn of doing things as originally planned (to and en-dash), as you've noticed. To get this you use to(-) instead of plain to. There's something wrong with it though ... probably just a redirect pointing the wrong way. It won't be too hard to extend that option to the "and" case. It's early days for this functionality so things can be adjusted, e.g. we could have to do what to(-) now does and to get two tos have another code. JIMp _talk·cont 03:39, 30 May 2008 (UTC)

Jimp, might "by" (50 by 100 ft...) also be included? I've been coming across several of those instances lately. — Huntster (t • @ • c) 05:40, 1 June 2008 (UTC)

It is, plain en-dashes and plus minus signs too.

{{convert|60|-|170|ft}} gives "60–170 feet (18–52 m)"

{{convert|60|x|170|ft}} gives "60 by 170 feet (18 m × 52 m)"

{{convert|600|+/-|17|ft}} gives "600 ± 17 feet (182.9 ± 5.2 m)"

Note that those dashes in the code are hyphens. JIMp _talk·cont 16:45, 1 June 2008 (UTC)

Brilliant as ever Jimp, thanks :) — Huntster (t • @ • c) 21:47, 1 June 2008 (UTC)

There should not be a unit on the first parameter in the converted range. Namely it is currently showing up as "60 by 170 feet (18 m × 52 m)" when it should be "60 by 170 feet (18 × 52 m)". -- KelleyCook (talk) 14:42, 3 June 2008 (UTC)

Not according to Wikipedia:Manual of Style (dates and numbers)#Unit symbols

In spatial values each number should be followed by a unit ("1 m × 3 m × 6 m", not "1 × 3 × 6 m³" or "1 × 3 × 6 m").

JIMp _talk·cont 20:43, 3 June 2008 (UTC)

As I understand it, each value needs to stand alone. You can get:

• asymmetrical units, such as "the cable is 5 mm by 100 m". However, I think that it is ok to drop the first unit if it is identical to the second. I cannot see any possibility of misinterpretation by a reasonable reader.
• ambiguous values, such as "production rose from 3 to 7 billion barrels", "the mountain range (3 to 7,000 m) could be seen". You need domain knowledge to disambiguate. That is a bad thing.

I would be interested to see any official text about the units. I took a look at the official SI website but could not find anything. Lightmouse (talk) 06:23, 5 June 2008 (UTC)

I'm probably missing something but there seems to be a minor problem with the way this works. For eample use the above on 10,000×200 feet (3,048×61 meters).

{{convert|10000|x|200|ft}} gives 10,000 by 200 feet (3,000 m × 61 m)

{{convert|10000|x|200|ft|sigfig=4}} gives 10,000 by 200 feet (3,048 m × 60.96 m)

Is there anyway to get both figures to round correctly? CambridgeBayWeather Have a gorilla 18:00, 11 June 2008 (UTC)

Use the following:

{{convert|10000|x|200|ft|0}} gives 10,000 by 200 feet (3,048 m × 61 m)

Rounding to a significant figure as you were doing (sigfig) isn't the same as rounding to a given precision. See the documentation of this at Template:Convert#Rounding. — Huntster (t • @ • c) 19:27, 11 June 2008 (UTC)

Thanks. I knew I should have been able to figure it out. CambridgeBayWeather Have a gorilla 10:57, 12 June 2008 (UTC)

Density

Is there any way this can be updated to include density units? I measure densities in kilograms per cubic metre, but other people might use pounds per cubic foot or something (sorry I don't really know what unit is usually used in imperial).

I will also second Werson's comment - I use this template wherever I can now I know it's here!  ;-) Leevclarke (talk) 02:24, 12 June 2008 (UTC)

Yes, densities can be added. I'm guessing that the imperial/US units might depend on what's being measured, e.g. pounds per gallon for some liquids, pounds per cubic foot for some gasses or solids, troy ounces per cubic inch for more metals, long or short tons per cubic yard ... of course there's API for crude but that might be more headache than it's worth since it's nonlinear. Someone give us a list of what imperial/US units would be needed. Metric is pretty straight-forward, of course. JIMp _talk·cont 02:55, 12 June 2008 (UTC)

The American chemical industry uses pounds/U.S. gallon quite extensively (example), especially companies geared toward "industrial" sales and not "academic" sales. The only other one that comes to mind is grains/cubic foot for some type of humidity (but I can't exactly remember the situation). —MJCdetroit ^(yak) 03:17, 12 June 2008 (UTC)

Actually, non-linear calculations aren't difficult if you accept a small amount imprecision and are willing to use a linear interpolation table. Basically, you have a few optional "ax+b", and the one actually used depends on "x". It would look like this in pseudo-code:

if x < m0
   y = a0 * x + b0
if x >= m0 and x < m1
   y = a1 * x + b1
if x >= m1 and x < m2
   y = a2 * x + b2
. . .
if x >= mn
   y = an * x + bn

Precision increases with the quantity of linear equations employed, but other than this it's a pretty straightforward way to deal with curves. -- alexgieg (talk) 12:21, 12 June 2008 (UTC)

Of course, the template does non-linear conversions (temperature) already but they're trickier than linear ones. JIMp _talk·cont 19:16, 12 June 2008 (UTC)

I've done a little homework. API, specific gravity and the like are not quite the same thing as density. A conversion from API to kg/m³ would have to take temperature (and pressure) in to account. If such conversions turn out to be desired, this template would probably not be the best place to do them. An editor adding such a conversion should know what he's doing. Therefore there would have to be a detailed description of what's going on and how to make it go on. The how to make it work properly bit would have to make sense: more of an {{API|10|temp_F=60}} than a {{convert|10|API|60|F}}. There just isn't room on the doc page for starters. JIMp _talk·cont 04:07, 13 June 2008 (UTC)

expression error

For the second time in a very short period of time, we are getting complaints at Talk:Main Page of a message "Expression error: Unexpected < operator" instead of the convert template. See here for a screenshot. Note that I personally have not seen these two occurrences, so assume that it must be system/browser specific, and perhaps peculiar to the Main Page. Any ideas? - BanyanTree 10:50, 12 June 2008 (UTC)

And the second occurrence. - BanyanTree 10:56, 12 June 2008 (UTC)

A possibility here is that this depends on the server that is feeding you. Due to 32bit vs. 64bit arithmetic results of expressions can vary. So if the incarnation of the page you are viewing is coming from a 64 bit server, you may have different results than users getting it from a 32bit server. --TheDJ (talk • contribs) 11:17, 12 June 2008 (UTC)

Happened to me (the first one anyway) running Firefox on a Windows system. It seemed to go away by itself. 79.66.36.52 (talk) 14:57, 12 June 2008 (UTC)

Perhaps the page just needed to be purged? Gary King (talk) 15:28, 12 June 2008 (UTC)

I did a hand trace of the templates being called and didn't see anything wrong. The two templates with a '<' operator are Template:Rnd/00 and Template:Max/2, though I'm not immediately seeing how the error could get all the way back up to the page. Hmm... --- RockMFR 16:40, 12 June 2008 (UTC)

Actually, it's probably coming from an error within an #expr, which would then catch the < from a previous error. That complicates things. --- RockMFR 17:00, 12 June 2008 (UTC)

I don't know where it could have come from either but if you try to give it a non-numerical value you'll get this kind of message, e.g. "e kilograms ({{rnd/b||()| }} lb)". JIMp _talk·cont 19:24, 12 June 2008 (UTC)

The first picture shows the error associated with article Eberswalde Hoard. But that article does not use the convert template and never has. Lightmouse (talk) 19:52, 12 June 2008 (UTC)

It was used on Template:Did you know, not the actual article. --- RockMFR 20:00, 12 June 2008 (UTC)

I took a look at the history of that template but could not find it. Can you point it out to me please? Lightmouse (talk) 20:26, 12 June 2008 (UTC)

diff --- RockMFR 20:39, 12 June 2008 (UTC)

Thanks. Lightmouse (talk) 20:57, 12 June 2008 (UTC)

'sqfoot' versus 'sqft' with sing=on

See also: Template talk:Convert/Archive January 2008 § Please eliminate mandatory conflation of 'hyphen' and 'singular'.

I recently changed sqfoot to sqft and got a comment on my talk page. I had thought that sqfoot was a synonym for sqft. Now I see that it is a singular form. I am prepared to change them all back but would it be better just to add 'sing=on'? Lightmouse (talk) 06:46, 13 June 2008 (UTC)

sing=on does a different thing, i.e., it gives the adjective form. I know ... singular form and adjective form are different things but as far as I could tell the adjective form had always been the intention of sing=on (since the days of Drumguy's version). sing was a bad name so adj was introduced. Lightbot could go through and swap those over too. The foot codes (foot, sqfoot, etc.), on the other hand, are to deal with the idiomatic use of foot instead of feet as the plural of the unit. This is still a noun, though. Use sing=on and you'll get an unwanted hyphen.

• {{convert|60|sqft}} gives "60 square feet (5.6 m²)"
• {{convert|60|sqfoot}} gives "60 square foot (5.6 m²)"
• {{convert|60|sqft|sing=on}} gives "60-square-foot (5.6 m²)"

JIMp _talk·cont 07:09, 13 June 2008 (UTC)

I have been around this template for a long time and I still do not understand these things. Can we continue the wysisyg campaign by making the commands and the output explicit. I happen to think 'sing' is a *good* name for creating a singular form. I happen to think 'adj' is a *bad* name for adding a hyphen. The singular form is used in the adjectival form (see a user quoting such an example on my talk page). I propose that the code works as follows:

• singular (foot) and plural forms defined by the 'sing' command
• hyphens (square-foot) defined by a 'hyph' command.

We would then change:

• all instances of 'sing=on' code to 'sing=on|hyph=on'
• all instances of 'sqfoot' code to 'sing=on

Making the commands match the result would be more wysiwyg and more afwyw (ask for what you want). Lightmouse (talk) 07:33, 13 June 2008 (UTC)

Yes, sing=on would be good for singular form. and hyph=on would be good for hyphens. However, when do we need hyphens?

• whenever we've got spelt out units in adjective form ...

When do we need singular form?

• whenever we've got spelt out units in adjective form or
• whenever the number is one ...

That's just grammar. The template automatically checks for the number one.

adj=on gives both hyphenation and singular form. The only case I can think of where you'd want one without the other (except with the number one) is the one word foot. Seperating hyphenation and singular form would be a whole lot of work ... a huge ammount ... to make one idiomatic usage more wysiwyg and more afwyw ... is it worth it? Is it really wysiwyg and afwyw? We can get semantic and say that foot is the plural of foot in this case ... is the word you not singular? We seperate hyphenation and singular form giving people the option to use the template to produce ungrammatical forms and trust that they won't take the option. I know it's come up before but this is just grammar. I see where you're coming from but isn't adj=on if you want an adjective afwyw? Ask for what you want is great assuming people ask for the correct thing. JIMp _talk·cont 08:13, 13 June 2008 (UTC)

We need the hyphen as a tool to resolve a reasonable ambiguity. If there is no reasonable ambiguity, then it is just a style preference. The problem is that this style preference has been made mandatory. The example at University of Tennessee Forensic Anthropology Facility was a case without a hyphen. There were many cases without hyphen on Wikipedia before this template mandated it. Users may fail to add hyphens that serve no purpose but will not produce a plural form where singular form is needed, you can see exactly that case at University of Tennessee Forensic Anthropology Facility - the user complained when the unhyphenated foot was changed to unhyphenated feet. Lightmouse (talk) 09:48, 13 June 2008 (UTC)

Can the "adj" parameter name be retained, please? It's perfect for use when you need an adjective form (i.e. with a hyphen). If you guys want to add another parameter name so that "hyph" also performs the same function, knock yourselves out, but please leave "adj" alone. — Bellhalla (talk) 12:03, 13 June 2008 (UTC)

If we do go with this, adj will remain. I'm no grammarian but I believe that the hyphenation of adjectives is not a mere stylistic choice but is the norm in English. Of course, this is not the page for discussing style. JIMp _talk·cont 01:39, 16 June 2008 (UTC)

expression error

Can you see what is wrong with:

• {{convert|1815|Mcuft|m3}} 1,815 million cubic feet (51,400,000 m³)

It appears to dislike values above 1,000. Thanks. Lightmouse (talk) 02:05, 20 June 2008 (UTC)

Sorry about that. It's fixed. JIMp _talk·cont 03:04, 20 June 2008 (UTC)

Thank you very much. Lightmouse (talk) 13:04, 21 June 2008 (UTC)

Bug with conversion from hp/ PS to kW

Template was recently added to Leopard 2 to convert 1500 hp to kw. The outcome was 1100 kW but should be 1118.55 or 1119 (rounded up). As the incorrect hp was used I changed it to the correct PS and the template seemed to acknowledge this change as the displayed horsepower was changed into metric horsepower. The problem is, the kW value did not change. Any idea what happened here? --Denniss (talk) 14:44, 21 June 2008 (UTC)

What happened was that the conversion was automatically rounded not to the nearest 10 watts, not to the nearest kilowatt but to the nearest 100 kilowatts. This is not a bug but the actual normal function of the template. So why round to the nearest 100 kilowatts? The value input was 1500 hp. The template reads this as 1500 hp to the nearest 100 hp. Good conversions maintain a similar level of precision to that of the original value as noted on the MoS. 100 hp ≈ 100 kW so the conversion is rounded to the nearest 100 kilowatts. This automatic rounding feature can be over-ridden by specifying a precision and/or number of significant figures to round to (see the documentation). However, be careful not to introduce false precision. JIMp _talk·cont 18:02, 22 June 2008 (UTC)

Ship displacement

Can we (or do we) have a template for converting ship displacement from (long) tons to tonnes, so that the long tons unit appears as tons?

e.g., instead of "Displacement: 22,400 long tons (22,800 tonnes)", we'd get "Displacement: 22,400 tons (22,800 tonnes)"

I've converted a few ship displacements, but the LT just doesn't look right. And at least one person (see Talk:HMS Hood (51)) has wondered about the use of long tons. Personally, it was only a couple of years ago that I realized that displacement used the long ton instead of the short ton. WeeWillieWiki (talk) 18:00, 24 June 2008 (UTC)

You say, Willie, that it was a while before you realised that the tons used for ship displacement were always long. Wouldn't the explicite mention of "long" have helped? Of course what you suggest would be possible but this is an issue to be discussed at WT:MOSNUM since the guideline clearly states that tons, gallons, etc. be disambiguated. JIMp _talk·cont 18:50, 24 June 2008 (UTC)

Well, it might have, had I actually seen long tons used in the ship listings of any of my reference books (Jane's, etc.) over the years *grin*; I probably overlooked it in the beginning of the book(s) where it describes each listing. Looking over a few WP ship articles (USS Yorktown, USS Enterprise, Yamato, HMS Zealous, Dunkerque) refer simply to tons or tonnes, not long tons. But your points are well taken. Thanks for pointing me in the right direction. WeeWillieWiki (talk) 21:08, 24 June 2008 (UTC)

Billions of volume measurement

Heya. Anyone know how to make billions of US Gallons / Liters simpler than seeing all the zeros? --Moni3 (talk) 12:07, 9 June 2008 (UTC)

Same way as it's done for cubic metres & cubic feet. Same way as it'll be done for large masses. It'll be e9USgal or e9U.S.gal for a thousand million US gallons (which the template calls a billion since it uses the "short scale") and e9l or e9L for as many litres. Note that you can get gigalitres now using Gl or GL. JIMp _talk·cont 15:05, 9 June 2008 (UTC)

I should say in a similar way ... not quite the same way since we've got to add the "US" and that'll take a bit of time. JIMp _talk·cont 19:35, 9 June 2008 (UTC)

e3impgal, e6impgal ... e12impgal, e3USgal, ... e3U.S.gal, ... e12U.S.gal are working. JIMp _talk·cont 06:21, 13 June 2008 (UTC)

Sorry to wait so long to get back to you. I tried using the template {{Convert|16|e9USgal|e9l}} but it didn't appear to work. The article in question, Restoration of the Everglades, has several instances of water measured in billions of gallons. I'd like to make it read smoother, particularly in this section. Any help you can give I would appreciate. Thanks! --Moni3 (talk) 17:11, 26 June 2008 (UTC)

I have edited the article. Instead of:

• {{Convert|16|e9USgal|e9l}}

use

{{Convert|16|e9USgal|m3}}

The 'e91' that you had in the code was causing the problem for you. I made a few other changes while I was there. For example, inches of rain and 'penny-a-pound' means nothing to most non-Americans so I converted them. I hope that helps. Lightmouse (talk) 22:04, 26 June 2008 (UTC)

You could also go with gigalitres (which is the default: {{convert|16|e9USgal}} gives "16 billion US gallons (61 Gl)") but if a e9l would be useful, it could be created. JIMp _talk·cont 23:42, 26 June 2008 (UTC)

Aha. I was confusing 'e9l' with 'e91'. Lightmouse (talk) 23:48, 26 June 2008 (UTC)

without units?

Is there any way to use this template and have it not display units? I'm trying to update some weather infoboxes and putting F and C in each box makes everything too wide, while each category already has the units listed. Thanks. 25or6to4 (talk) 10:38, 29 June 2008 (UTC)

I assume that you are referring to Corpus Christi, Texas or Victoria, Texas. In which case you might be better off using Template:Infobox Weather, see Austin, Texas#Climate. CambridgeBayWeather Have a gorilla 15:49, 29 June 2008 (UTC)

... or use disp=table. Have a look at Alabama#Climate for an example. JIMp _talk·cont 23:46, 29 June 2008 (UTC)

Template:Infobox Weather is what I need. Reading through it, I thought it needed the data entered for both F and C. I'll go with this! Thanks! 25or6to4 (talk) 03:34, 30 June 2008 (UTC)

Other templates

Have we had any serious discussions with stakeholders of other templates with similar functions? Lightmouse (talk) 15:59, 29 June 2008 (UTC)

Syntax?

Can I suggest a change? {{convert|123500|MT|ST|-2|}} gives back ST, which is a bit unclear... Trekphiler (talk) 05:54, 30 June 2008 (UTC)

How to indicate various tons has been under discussion at WT:MOSNUM. There appears to be a feeling that long and short tons should always be spelt out. A quick look around the web shows that there really is no widely used standard abbreviation. This is probably likely to be added to the guidelines. The template will follow suit but in the mean time try {{convert|123500|MT|short ton|-2|}}. JIMp _talk·cont 15:42, 30 June 2008 (UTC)