Misplaced Pages

Revision as of 01:59, 7 July 2008

Archives

2007January–October November December2008January February March April May June

This page has archives. Sections older than 21 days may be automatically archived by Lowercase sigmabot III when more than 1 section is present.

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)

'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 Misplaced Pages 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)

Range of values

Is there a trick or equivalent template for presenting ranges of values, as in 2-20 mm? --EncycloPetey (talk) 23:18, 25 June 2008 (UTC)

Yes,

• {{convert|2|-|20|mm}} will give "2–20 millimetres (0.079–0.787 in)"
• {{convert|2|to(-)|20|mm}} will give "2 to 20 millimetres (0.079–0.787 in)"
• {{convert|2|to|20|mm}} will give "2 to 20 millimetres (0.079 to 0.787 in)"
• {{convert|2|x|20|mm}} will give "2 by 20 millimetres (0.079 in × 0.787 in)"
• {{convert|2|+/-|20|mm}} will give "2 ± 20 millimetres (0.079 ± 0.787 in)"
• {{convert|2|and|20|mm}} will give "2 and 20 millimetres (0.079 and 0.787 in)"

... but it's still under construction so won't work for all units. JIMp _talk·cont 23:58, 25 June 2008 (UTC)

Thank you. I have started using it. The second one contains 'inches' within parentheses, is that a bug? Lightmouse (talk) 22:38, 29 June 2008 (UTC)

Yep, that would be a bug. Well spotted ... JIMp _talk·cont 23:20, 29 June 2008 (UTC)

fixed JIMp _talk·cont 08:05, 3 July 2008 (UTC)

Thank you. You are a star. Lightmouse (talk) 08:39, 3 July 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)

Reference

There's no way to add a reference after the first number, is there? --NE2 09:39, 30 June 2008 (UTC)

No, you can't add refs with templates. JIMp _talk·cont 15:31, 30 June 2008 (UTC)

I'm talking about something like 5 mi (8 km), where the actual reference is a parameter of the template. --NE2 08:41, 4 July 2008 (UTC)

Yeah, I thought that's what you were after. I'd tried it once some time ago (on Wiktionary but same thing). It didn't work then. I've just given it another try in the sandbox. It failed again. JIMp _talk·cont 09:00, 4 July 2008 (UTC)

It works on template:mikm; see for intstance SR 99 on List of state highways in Washington. --NE2 09:10, 4 July 2008 (UTC)

I see, the parameter is set to <ref>cite</ref> not just cite. That'll work ... well you can see it in action. Okay it's on the to-do list but it'll take a while since this involves hundreds of subtemplates ... one of the draw backs with this design. JIMp _talk·cont 00:02, 7 July 2008 (UTC)

More for the wizard - reverse values

I have an article that is using mixed SI and Imperial (or whatever it's called nowadays) units. I want to unify the systems using {

I believe what you are wanting is described here, so no, it is not currently possible. What article is it you are working on? Shouldn't be too hard to unify the system, excepting quoted figures and such. — Huntster (t • @ • c) 07:12, 3 July 2008 (UTC)

It will be possible one day. JIMp _talk·cont 07:38, 3 July 2008 (UTC)

Thanks. I have great faith. I was thinking it would be an easy reciprocal function with some divide-by-zero checking, on reflection it may just be a wee bit more complicated :) The article that spurred it is now clicked away, I think it was Nuclear weapon design. I can easily enough use preview, -convert- the Imperial to SI, then use that value for original_source. Eventually Jimp will produce the magic solution - I'm thinking a leading flag, "src=sec" or something, that eliminates the confusion up front and lets us respect the input of the original author. All in good time.

On another note, I don't think the docs have been updated for the "range" functionality. Is it far enough along that I can have a shot at including it? Franamax (talk) 08:01, 3 July 2008 (UTC)

Have a shot; I'll probably add some warnings about what's not ready yet ... yeah, the doc lag on the template is a little shameful but ... JIMp _talk·cont 08:05, 3 July 2008 (UTC)

I personally hate doing documentation, I'd much rather code. Keep performing the miracles, the rest of us can write the gospels ;) I did give it a try.

As far as what is currently working, would it be helpful to add a column to the List of units part of the docs? I can easily enough run through the possibilities.

And on the subject of updating docs, do I see a "e9USgal" parameter that seems to be undoc'd? If you can give me a clue where to look, I can also have a try at gathering up the latest goodies. Franamax (talk) 21:19, 3 July 2008 (UTC)

Numeric format.

{{editprotected}} Under some circumstances this template is returning values in "e" notation. e.g. "{{convert|1|mg|oz|lk=on}}" yields "Template:Convert/mg". This is not an acceptable numeric notation in print. It should be "1 milligram (3.5 × 10  oz)". The problem seems to be coming from this template's use of {{Rnd}} (via transcluded subtemplates). Either Rnd needs to be fixed to use scientific notation, or this template should be fixed not to use it.--Srleffler (talk) 03:51, 4 July 2008 (UTC)

There's no edit that can be done on this protected page to fix the problem. {{Rnd}} was designed to aviod such errors but if it's broken something must be done. JIMp _talk·cont 04:39, 4 July 2008 (UTC)

I've found a solution. I'm just waiting for unprotection of {{rnd}} & {{rnd/+}}. JIMp _talk·cont 06:05, 4 July 2008 (UTC) ... and waiting ... JIMp _talk·cont 06:41, 4 July 2008 (UTC)

Okay, thanks to Huntster's help, it's fixed as you can see. JIMp _talk·cont 08:11, 4 July 2008 (UTC)

Unexpected Expression error: Unrecognised word "span"

I have been adding {{convert}} to articles for some time now with no problems. However yesterday I added three {{convert|00.0|m|ftin|abbr}} statements to then infobox on British Rail Class 60 (Length, Width, Height), and this morning I have discovered that the first of the three now has an output error: 21.34 m ({{convert/AndExpression error: Unrecognised word "span"|Expression error: Unrecognised word "span"|ft|-7560×10−1|in }}) The second and third work without a problem.

I am at a complete loss to understand what has gone wrong - I have checked my typing - its the first call to {{convert}} in the infobox, both as written as as displayed. Can anyone tell me what has gone wrong? TIA Iain Bell (talk) 11:41, 4 July 2008 (UTC) 00.0 metres (0 in)

I see a similar error on the {{Rnd}} page. The third example of the template gives an error on that page, but the same wikicode works fine on the documentation page itself. Rnd is called by convert, and was modified yesterday (per my request above). Perhaps there is a subtle bug in the new code.--Srleffler (talk) 14:23, 4 July 2008 (UTC)

The glitch you see at {{rnd}} is nothing to worry about, it should go away when someone opens {{rnd}} & then hits ... but that'd take an admin. The other problem is not so trivial ... well, actually there are two & one is somewhat trivial. Just putting abbr in without the =on (or =off) like that is going to confuse {{convert}} into thinking you want to round to abbr decimal places and that won't work since abbr is no number. The other problem is serious, it seems the template can't handle converting zero and ftin. I'll have a look at that. JIMp _talk·cont 15:59, 4 July 2008 (UTC)

Should we not push for a revert to the last working version and then make any changes from there. Looks like we do need to escalate this as a number of articles are being edited to avoid the message flagging up as the issue has been around for a good couple of days.Londo06 10:10, 6 July 2008 (UTC)

It should be working now, just put the =on after the abbr

{{convert|00.0|m|ftin|abbr=on}} → "00.0 m (0 in)"

JIMp _talk·cont 17:00, 6 July 2008 (UTC)

Still getting the error message appearing in a number of articles.Londo06 20:52, 6 July 2008 (UTC)

You wouldn't mind pointing them out, would you? JIMp _talk·cont 23:45, 6 July 2008 (UTC)

Help

In the article Walden Galleria, I've used some convert templates. I've tried messing around with the code, but the square meters are still showing up as "1.486449×10" instead of a nice round number. How do I get this to show up in something else than scientific notation? Ten Pound Hammer and his otters • 15:36, 4 July 2008 (UTC)

I'll have a look. JIMp _talk·cont 15:59, 4 July 2008 (UTC)

I changed the rounding from a precision of one (i.e. the nearest tenth of a square metre) to two significant figures. The scientific notation is a product of the recent update of {{rnd}}. That template was edited to get rid of E notation. The E notation was replaced with scientific notation. The range for which {{#expr:}} is sure not to give E notation seems to be 10 > x > 10. {{Rnd}} was thus made to have scientific notation kick in outside this range. It should get rid of some of those unsightly strings of zeros you sometimes see. JIMp _talk·cont 16:29, 4 July 2008 (UTC)

I find myself comfortable with 150,000 as well as 1.5 × 10 m². I am quite prepared to accept that the format shown in that article is the one we have to use but is the '150,000' format something we should discuss? Lightmouse (talk) 16:40, 4 July 2008 (UTC)

We probably should. JIMp _talk·cont 16:46, 4 July 2008 (UTC)

I must say, I have a feeling this will generate significant resistance. Not very many people will understand what scientific notation is, much less how to interpret it. — Huntster (t • @ • c) 22:57, 4 July 2008 (UTC)

This is true but the balance must be struck somewhere, 100,000 may be too low but we surely don't want great strungsstrings of zeros. JIMp _talk·cont 21:47, 5 July 2008 (UTC)

I agree with the principle. Lightmouse (talk) 10:04, 6 July 2008 (UTC)

With the current {{rnd}}, we get

• {{convert|1|ly|km}} → "1 light-year (9.5×10 km)"

Surely this is better than

• {{convert|1|ly|km}} → "1 light-year (9,500,000,000,000 km)"

How about "1 astronomical unit (1.5×10 km)" vs "1 astronomical unit (150,000,000 km)" for {{convert|1|AU|km}} or "1 tonne (1.0×10 g)" vs "1 tonne (1,000,000 km)" for {{convert|1|t|g}}? Of course "1 hectare (10,000 m)" would usually be better than "1 hectare (1.0×10 m²)" vs for {{convert|1|ha|m2}}. Where shall we have the scientific notation kick in? JIMp _talk·cont 17:38, 6 July 2008 (UTC)

Well, I'm not going to ask for additional complexity to be coded into the template, though I do wish there was a way to expressly not use scientific notation...I personally can't stand it, and have no problem with a line of zeroes (to me, comma groupings are much easier to interpret). Either way, it is a minor issue, so I'm not going to be vocal. — Huntster (t • @ • c) 18:01, 6 July 2008 (UTC)

Beauty is in the eye of the beholder, isn't it? As for me, what I can't stand are great strings of zeros. A maximim of four seem just about right to me ... anything above nine would get my eyes rolling. Last Friday's choice of one hundred thousand as the cut-off point was more of a technical decision than an æsthetic one. I'd originally had one million in mind ... still to low? We could bump it up further, it'll mean more complexity in the {{rnd}} code but it may be worth it if this dislike for scientific notation is wide-spread. Make it optional ... now were're talking complexity. Of course, were it optional then we could conform to the editor's taste ... but it's the reader we're altimately trying to satisfy ... isn' it? I'm writing as if scientific notation will be inevitable at some point ... of course, nothing's inevitable (except taxes, death and trouble) but the higher we go avoiding scientific notation the more complex {{rnd}} will have to be ... but eventually we'll want scientific notation, the balance must tip somewhere. To take an extreme example, isn't "1 teratonne of TNT (2.6×10 feV)" better than the version with 4½ dozen zeros? JIMp _talk·cont 00:30, 7 July 2008 (UTC)

Template code: kn versus knot

Some editors are converting kn to knot within the template code. See other edits around the same time. Lightmouse (talk) 21:55, 6 July 2008 (UTC)

They are probably having the same reaction I had when the bot run changed the code from "knot" to the less-intuitive "kn". Since "knot" is not "kt" (which had a definitive reason to be changed), and "knot" works, and is non-ambiguous, why is this even worth mentioning on this talk page? — Bellhalla (talk) 01:59, 7 July 2008 (UTC)