Template talk:Convert/Archive August 2008

Abbreviations
Abbreviations where the last letter is not the same as the last letter of the abbreviated word, then it should be followed by a full stop. For example, "sq."; "cu."; "gal."; "fl."; "ft"; "dry"; "yd". Not sure about mi (miles) and I don't think for S.I. units and prefixes, but fix for the other ones? 87.254.67.84 (talk) 00:09, 31 July 2008 (UTC)


 * I believe we have consciously applied a standard of not using a full stop for any unit abbreviation at all. Note that ordinarily in american english no distinction is made based on the last letter being the last letter of the full word. --Random832 (contribs) 01:56, 31 July 2008 (UTC)


 * Aye, I believe mixing abbreviations with and without periods would add more confusion than it is worth. To be honest, I don't believe I've heard of the convention stated by the OP. — Huntster (t • @ • c) 06:03, 31 July 2008 (UTC)

The template follows WP:UNITS in this. J IM ptalk·cont 01:04, 1 August 2008 (UTC)

What is an MT
Just fixed an instance of - MT is not a proper unit symbol - it should say "t", "tonne(s)", or "metric ton(s)" --Random832 (contribs) 20:50, 30 July 2008 (UTC)
 * Also, in a spot check of pages using this, I noticed a lot of ship infoboxes had a completely redundant "t->MT" conversion. Can someone explain this to me? --Random832 (contribs) 20:55, 30 July 2008 (UTC)

These "MT"s, "ST"s & "LT"s are being phased out in accordance with WP:UNITS. J IM ptalk·cont 01:06, 1 August 2008 (UTC)


 * I believe that a while back I did a search for all usage in convert templates. Then I changed them all to be consistent with WP:UNITS. Editors will probably have added some again. Perhaps it is time for another sweep. Lightmouse (talk) 09:12, 1 August 2008 (UTC)


 * Weren't we going to spell them out in full? Metric ton, short ton, long ton.  &mdash;  MJC detroit  (yak) 12:05, 1 August 2008 (UTC)

Precise Unicode for Celsius/Fahrenheit
Both degree of Celsius and degree Fahrenheit have a specific unicode character. I think we should use &#x2103; and &#x2109;  for displaying the abbreviated unit—like in 20 °C. ––Bender235 (talk) 14:51, 1 August 2008 (UTC)
 * No. Those are compatibility characters for round-trip conversions to and from CJK character sets, and are not supposed to be used in new text. --Random832 (contribs) 15:32, 1 August 2008 (UTC)
 * Says who? ––Bender235 (talk) 16:22, 1 August 2008 (UTC)
 * Unicode Standard - page 493 (page 7 of pdf). --Random832 (contribs) 19:38, 1 August 2008 (UTC)
 * Okay. ––Bender235 (talk) 20:13, 1 August 2008 (UTC)

Million gallons
Do we have a special way of handling 'million gallons' just as we do for 'million barrels'? Lightmouse (talk) 20:36, 30 July 2008 (UTC)

Yes,,   and. J IM ptalk·cont 02:05, 3 August 2008 (UTC)

fractions in output
I know that I can use fractions in input: but for specifications in mm the conversion is in the other direction. Can I get fractions in output? Lightmouse (talk) 08:52, 2 August 2008 (UTC)
 * 4 ft gives: 4 ft


 * Not as yet, no. It was something I'd wanted to add ... still do but ... J IM ptalk·cont 02:28, 3 August 2008 (UTC)


 * I learn new things about this template every day, it seems. It looks, however, that the fractions of inches works only with feet. Adapting the above example gives this:
 * 8+1/2 in gives: 8+1/2 in
 * Is this a bug (or a feature)? — Bellhalla (talk) 10:48, 2 August 2008 (UTC)


 * Yes, these only work with feet ... it's kind of tricky and probably eats into the template limiting parameters. Of course, there's always a way around things but it'd probably take time I don't have. J IM ptalk·cont 02:28, 3 August 2008 (UTC)


 * No worries. I just thought the fraction thing was interesting and was playing around with it. — Bellhalla (talk) 04:08, 3 August 2008 (UTC)

Nautical miles
Is it possible to change the template, such as having "|type=avn", so that the correct abbreviation can be used in aviation related articles. Currently nautical miles has to be spelt out in full or use the incorrect nmi rather than NM (not nm). CambridgeBayWeather Have a gorilla 19:03, 2 August 2008 (UTC)
 * It would of course be possible but there is a better way. J IM ptalk·cont 02:08, 3 August 2008 (UTC) ... I've just added a new code:  use this instead.
 * → "1 NM"
 * J IM ptalk·cont 02:21, 3 August 2008 (UTC)
 * Thanks for that. CambridgeBayWeather Have a gorilla 03:49, 3 August 2008 (UTC)

Square brackets
Is there a way to get square brackets for use in quotes? I am sure I have seen discussion of this but I can't remember what the answer was. Lightmouse (talk) 15:42, 1 August 2008 (UTC)


 * As in, to add a conversion to quotes where the original quote had none? Please, do not do this. The MoS recommends not even wikilinking inside quotes. MOS:QUOTE says to not change the structure of the quote unless there is a good editorial reason to do so, and I don't believe a conversion is such a reason. — Huntster (t • @ • c) 12:12, 2 August 2008 (UTC)

Can you provide a link to the prohibition in the MoS? There might be a clash of guidance on this. wp:mosnum says:
 * Conversions required for units cited within direct quotations should appear within square brackets in the quote. For context see the discussion on the wp:mosnum talk page. Regards Lightmouse (talk) 12:24, 2 August 2008 (UTC)


 * As I linked above, MOS:QUOTE. And as I said, I don't think that a conversion is an example of a valid editorial reason, so yes, I do believe that a significant clash exists. To be honest, I would never support changing a quotation in any way, except for the seemingly universally-accepted " [sic]". After all, that's the point of a quotation...to show precisely what the original author wrote. A conversion simply isn't needed in the middle of the quote. It can be written into the prose after the quote. — Huntster (t • @ • c) 12:39, 4 August 2008 (UTC)

Cubic Centimeters to Litre / Cubic Inches Dual Conversion
Try to do this for engine capacity related items (removed formatting/rounding codes) but it doesn't seem to work.

1234 cc Oosh (talk) 06:49, 4 August 2008 (UTC)


 * I think I've fixed it. --Random832 (contribs) 13:44, 4 August 2008 (UTC)


 * Looks good to me. J IM ptalk·cont 03:11, 5 August 2008 (UTC)

Rate of climb
Not sure how much use it would get, but I think that a ft/min to m/min might be a good idea. See Rate of climb. CambridgeBayWeather Have a gorilla 10:03, 5 August 2008 (UTC)
 * It already exists. J IM ptalk·cont 10:39, 5 August 2008 (UTC)
 * Ah, so it does. Thanks. I couldn't find it in the list so I didn't think it was there. CambridgeBayWeather Have a gorilla 11:56, 5 August 2008 (UTC)

Yeah, the list is badly in need of updating. Sorry about that. J IM ptalk·cont 12:40, 5 August 2008 (UTC)
 * It's better to have the conversions available but missing from the documentation than not having the conversions. CambridgeBayWeather Have a gorilla 23:32, 5 August 2008 (UTC)

Use in sortable tables
It would be nice if the option "disp=table" also included coding to make the values sort correctly. It works fine when abbreviations are off, but when they are on it sorts as plain text (e.g., 1, 10, 2, 200, 3). --Lasunncty (talk) 01:47, 10 August 2008 (UTC)
 * I'll look into it. J IM ptalk·cont 13:11, 12 August 2008 (UTC)

template options: Tft3 versus Tcuft
The template permits 'cuft' and 'ft3' in the code. It permits 'Tcuft' but not 'Tft3'. Do we need to review the code options for trillion, billion, million etc and which units they apply to? Lightmouse (talk) 17:38, 7 August 2008 (UTC)


 * That might be a good idea. J IM ptalk·cont 17:40, 7 August 2008 (UTC)

Thanks. I would also like to say again that I think we should have 'sqft' produce 'sq ft' and 'ft2' produce 'ft&sup2;'. Lightmouse (talk) 17:58, 7 August 2008 (UTC)


 * FWIW, standard abbreviations in the petroleum and natural gas industry are:
 * scf - standard cubic feet
 * Mcf - thousand cubic feet
 * MMcf - million cubic feet
 * Bcf - billion cubic feet
 * Tcf - trillion cubic feet
 * Of course, Mcf and MMcf conflict with the standard metric prefixes kilo for thousand and mega for million. M actually stands for Latin mille or thousand. RockyMtnGuy (talk) 04:59, 9 August 2008 (UTC)

To reply to both of the above:
 * Lightmouse, I really think we should avoid generating two output forms for the same concept. Decide on a single output, and have both forms use that output. Less confusion all around.
 * RockyMtnGuy, while it may be useful to adopt those standards, at the same time I think we should use more logical inputs..."Kcf" for thousand, and "Mcf" for million. Unless there's a real need for "scf", I'm not sure it should be used. — Huntster (t • @ • c) 15:44, 9 August 2008 (UTC)


 * The real problem is that many of the units used within the petroleum industry are only used within the petroleum industry (and similar industries), are very antiquated, and do not make sense to persons outside the industry who do not know the background. For instance, "scf" for "standard cubic feet" means cubic feet corrected to standard temperature and pressure conditions, which is important if you are measuring natural gas. However, since the abbreviations Mcf and MMcf are in common use for thousand cubic feet and million cubic feet, perhaps it would be best to use abbreviations that do not conflict with them. One set of possibilities is:
 * ft3 - cubic feet
 * Kft3 - thousands of cubic feet
 * Mft3 - millions of cubic feet
 * Gft3 - billions of cubic feet
 * Tft3 - trillions of cubic feet
 * All of this is nonstandard, but given that most people don't know what the standard is, at least it is unambiguous and would make sense to people with computer expertise (who nowadays vastly outnumber people with petroleum expertise). RockyMtnGuy (talk) 20:53, 9 August 2008 (UTC)

One of my main objections to "Follow the current literature" (a recent much-debated proposed addition to WP:MOSNUM) was that it would introduce industry/feild/etc.-specific terms and abbreviations like "Bcf". Writing for as broad an audience as Wikipedia's we should avoid the like. With respect to the above, I'd hesitate to introduce our own home-grown abbreviations and I wonder how ambiguous they really are: if 1 Mft3 is one million cubic feet, what's 1 Mm3? J IM ptalk·cont 09:17, 11 August 2008 (UTC)


 * Bcf is the industry-standard abbreviation for billion cubic feet in the natural gas industry, but not necessarily any other industry. 1 Mm3 is one cubic megametre, and that's, like, really big. Under most circumstances you should use 1×106m3 for 1 million cubic metres. The situation regarding traditional units is basically insoluble because traditions vary from country to country and you will never get everyone to agree, especially not the Brits and Americans. It's like herding cats. My own preference, based on vast experience in herding cats, is to put all traditional units into a museum alongside cubits and leagues, and use SI units exclusively. However that gets all the traditionalists upset. There's no winning scenario. RockyMtnGuy (talk) 03:33, 13 August 2008 (UTC)

Our best bet I reckon is to stick to engineering notation. J IM ptalk·cont 16:18, 13 August 2008 (UTC)


 * Engineering notation is a coherent solution. But I do prefer (1,400 m&sup3;) to (1.4 × 10&sup3; m&sup3;) which is what we get with 50 kcuft . In fact, values up to 6 digits seem fine to me. I am not proposing a change, just stating my preference. Lightmouse (talk) 16:36, 13 August 2008 (UTC)

Reading some of the other sections on this page, I see that we can have: I am not sure what I would want, but it looks like we need to choose whether to use 'k' or 'e3' and choose whether the addition of 'm3' should make a difference. Lightmouse (talk) 20:53, 13 August 2008 (UTC)
 * 300 e3impgal giving 300 e3impgal
 * 50 kcuft giving 50 kcuft
 * 50 kcuft giving 50 kcuft


 * We should probably reserve the SI prefixes for those units actually formed with them and otherwise have "e3", "e6", etc. Adding "m3" probably should not make a differemce until we're dealing with millions of cubic metres. J IM ptalk·cont 09:08, 14 August 2008 (UTC)

That sounds like prefixes would not be used in the code unless the prefix is applied to the output. Thus 'kblah' would produce 'kiloblah', not 'thousand blah'. Instead, 'e3blah' would give 'thousand blah'. And 'e3kblah' would produce 'thousand kiloblah'. Good, that looks like a coherent solution. I agree with you about the effect of m3. Lightmouse (talk) 09:20, 14 August 2008 (UTC)


 * 250 e3U.S.gal --->250 e3U.S.gal.


 * ahhhh...."e3". Ya learn something new everyday.  We should probably make a concentrated effort to update the doc page for this template.  &mdash;  MJC detroit  (yak) 16:29, 14 August 2008 (UTC)

Too true. I've just got so little Wikitime these days ... y'know: life ... and this long list of things that need doing on this and other templates. J IM ptalk·cont 01:46, 15 August 2008 (UTC)

Superscripts for square and cubic imperial/US units

 * I've always been against unit&sup2; & unit&sup3; because it is not the most common way that cubic/square units in the U.S./imperial system are encountered and shows a huge inconsistency in the encyclopedia as a whole. Many pro-metric editors wanted/want unit&sup2;/unit&sup3; for English units because it is similar to what they always have seen with metric units.  Some have argued to allow "sq km" (and the like) in the past.  Those who have argued for such have lost because for metric units superscripted is the most commonly encountered abbreviations/symbols and SI units are regulated to be only be siunit&sup2;.  English units are not regulated as tightly as SI units, therefore some inconsistencies can occur.  Although, there are inconsistencies that do occur with metric units as well.  However, there is a recent proposal to eliminate the lower case "l" for litres in favor of "L"; also ml vs. mL.  So unless some industry has a specialized standard symbol that it always uses like CCF, MCF, CID, or maybe Tft&sup3; (I don't know about the last one), then we should always stick to the most commonly used symbols/abbreviations for the sake of consistency!  Also, with two different styles, I could foresee someone going around and changing English units to suit their fancy.  If anything, we should have a bot go through and change all of the code occurrences of mi2, ft2, yd3, mi3, and others to sqmi, sqft, cuyd, cumi, etc, in the same way that Lightmouse had to go through with his bot and change all of the old coding from sqkm, sqm, cum, cukm to km2, m2, m3, km3.  &mdash;  MJC detroit  (yak) 02:54, 13 August 2008 (UTC)

I tend to agree with you, MJCdetroit: I'd rather have things consistant in general. The thing is that when the change was made to MOSNUM maintaining the proscription of superscripts for square and cubic imperial/US units was rather low on my list of things to fight for/against. Shall we bring it up on WT:MOSNUM—for whilst this is permitted by the guideline it's no unreasonable request to have the template adjusted to produce it? J IM ptalk·cont 08:54, 13 August 2008 (UTC)


 * I would be happy for my bot to change all current code occurrences of '|blah2|' to '|sqblah|' where blah is non-metric. This would have no visible effect for readers. It could be done now because it does not conflict with any guidance that exists now or is likely to exist. My bot is currently blocked so I would appreciate support from you all to get it unblocked. Lightmouse (talk) 09:02, 13 August 2008 (UTC)
 * As discussed on Lightmouse's talk page, the bot has been unblocked by the blocking admin. Good luck. &mdash;  MJC detroit  (yak) 16:22, 14 August 2008 (UTC)

Temperature intervals
Is it possible to give temperature intervals rather than specific temperatures? I wan't to avoid this sort of error. CambridgeBayWeather Have a gorilla 19:44, 15 August 2008 (UTC)
 * Yes. J IM ptalk·cont 07:24, 16 August 2008 (UTC)
 * Thanks. I must have missed that when I checked back. CambridgeBayWeather Have a gorilla 15:46, 16 August 2008 (UTC)

Superscripts
WP:UNIT says 'Avoid the unicode characters ² and ³' and use undefined instead. This template seems to use the unicode characters. Will changing it produce any problems? JMiall ₰  16:21, 17 August 2008 (UTC)


 * No, no problems. But the subtemplates are largely protected. J IM ptalk·cont 17:47, 17 August 2008 (UTC)


 * I temporarily lowered the protection on the subtemplates of m2, km2, m3, and km3. Some of the others like mm2, cm2, and cm3 were already unprotected.  Edit them as needed. &mdash;  MJC detroit  (yak) 02:11, 18 August 2008 (UTC)


 * It seems somewhat obvious that acres are converted in m* rather than m3, no? Thus most readers can easily identify m2 for these. Adding superscript to all conversion just messes up the line spacing. -- User:Docu

This is not the forum for Unicode characters vs undefined since WP:MOSNUM now recomends that the former not be used. I brought this change to talk. Consensus seemed generally in support. J IM ptalk·cont 01:00, 19 August 2008 (UTC)


 * Sure, but the MoS concedes "[  ] can produce irregular line spacing, that is usually a less serious problem", but as it is here, we are better off leaving in the unicode. -- User:Docu


 * Are you sure that's still relevant? I thought the old line spacing problems were more or less fixed by a CSS change quite some time (months if not years) ago.  —Ilmari Karonen (talk) 11:19, 19 August 2008 (UTC)


 * Indeed,  no longer produces irregular spacing, which was very apparent to me as an old signature of mine used superscript and caused that spacing. Now those sigs look perfectly normal. Just for the sake of interest, the fix was implemented on 21 March 08 with this diff. — Huntster (t • @ • c) 16:47, 19 August 2008 (UTC)

I think the unicode to  conversion still needs to be done for conversions to square kilometres and square miles etc. Eg  gives 6 ha.--JD554 (talk) 09:58, 20 August 2008 (UTC)

Removal of convert template due to page load time
A user removed conversions and suggested that the template increases page load times. See User_talk:Lightmouse. What is the answer to this suggestion? Lightmouse (talk) 09:31, 16 August 2008 (UTC)


 * In the overhaul of the template one of I my main objectives was to minimise the pre-expand include size (this was last year). I've gone to what could be called great lengths to achieve this—we've got over 2,000 subtemplates, it could've been far fewer if pre-expand include size had not been a concern.  The template couldn't be much trimmer (I don't think) and do what it does.  If the template is replaced with conversions in plain text, there's no cause for alarm.  As you suggest, Lightmouse, the best way to prevent the insertion of  is to type the conversion in as raw text. J IM ptalk·cont 13:28, 16 August 2008 (UTC)

Agreed with Jimp. I can personally note that it used to be horrendous at some point last year, and there have been marked improvements in the time since (I sometimes muck around with substs etc in userspace for other reasons). Orderinchaos 13:36, 16 August 2008 (UTC)


 * Can anyone produce quotable statistics? Lightmouse (talk) 15:59, 16 August 2008 (UTC)

Yes ... well, just about anyone who can use a computer. Go to an empty page, type a transclusion in, save it, look at the page's html code (on IE click on View then Source) and find the NewPP limit report. Here's one I prepared earlier.

100 mi NewPP limit report Preprocessor node count: 226/1000000 Post-expand include size: 391/2048000 bytes Template argument size: 447/2048000 bytes Expensive parser function count: 0/500

J IM ptalk·cont 10:55, 17 August 2008 (UTC)


 * I do not understand that. Can you explain it in terms of the burden that the template causes? Lightmouse (talk) 10:57, 17 August 2008 (UTC)

Isn't that page now cached on the servers? (WMF uses squid caching doesn't it?) So isn't the load "pushed forward" so that when you make a change to the template arguments, the cached article page gets invalidated and regenerated, just like any other page edit? And if you change the template itself, of course, many many article pages get invalidated and regenerated. I'm no expert, but templates and page edits don't really affect the average viewer looking up something on Wikipedia, do they? Franamax (talk) 11:06, 17 August 2008 (UTC)


 * I wish I could explain things better. What I do know is that these wp:template limits were put in place to keep pages from taking too long to load.  So, I'm guessing that the higher the numbers the greater the burden. J IM ptalk·cont 11:21, 17 August 2008 (UTC)

It is important that we find a way of explaining this to ordinary users. I do not want metric units removed from too many articles. See: Special:Contributions/Marcia_Wright. Regards Lightmouse (talk) 17:23, 17 August 2008 (UTC)


 * Didn't Marcia write that she'd cosider Option 2 (on your talk page)? Yet she seems simply to be reverting you outright.  J IM ptalk·cont 17:55, 17 August 2008 (UTC)

Marcia is now making the point that the template does not permit '1.1. million acres (xx km&sup2;)' and I had to change it to '1,100,000 acres (xx km&sup2;)'. This sounds like a case for 'e6acre'. Is this possible? Lightmouse (talk) 15:42, 21 August 2008 (UTC)

significant figures on input
Is it possible to specify that the input value be rounded (i.e. a higher precision value be used than displayed? For example: 1.070344 e6acre : 1.070344 e6acre; 1.1 e6acre : 1.1 e6acre; I would like "1.1 million acres (4,300 km2)". The problem arises when the mantissa of the converted value is greater than that of the original (i.e. 4.3 > 1.1) and when we don't want to display the source value to the highest precision known for aesthetic reasons --Random832 (contribs) 14:30, 22 August 2008 (UTC)


 * I don't believe it is possible to modify the source figure in output, however, why not simply use 1.07 e6acre (1.07 e6acre)? If the exact number is 1,070,344, and the output is giving an undesired precision, then 1.07 seems perfectly acceptable compared to 1.1. You don't have to reduce it to two significant digits...three or even four is okay, especially if the source number really is an exact figure. At least, that is my feeling on it, though to be honest, if the source is long but precise, I wouldn't round in any situation...I'd use that exact number. — Huntster (t • @ • c) 19:00, 22 August 2008 (UTC)
 * Well, the exact figure (well, not so much exact as a whole hell of a lot more precision than "1.1 million") does get used - but it's a bit verbose to put in the lead paragraph. --Random832 (contribs) 05:34, 23 August 2008 (UTC)

converting '|ft2|' to '|sqft|'
As a result of other discussions on this page, I have made a start on converting '|ft2|' to '|sqft|' and other non-metric squares and cubes. So far I have tried to do: 'in2', 'in3', 'yd2' and 'yd3'. However, when I do 'what links to' the relevant templates, there are still lots of articles. I am sure that this is because of infoboxes or something but I can't work it out. Can anyone see where they are? Lightmouse (talk) 21:52, 20 August 2008 (UTC)


 * Thanks. The 'something' has to do with redirects and default unit outputs (as best that I can explain it).  I think, I've taken care of the cubic inches' template redirects and default unit outputs (this thing: |o=cuin).  I'll do more when I get a chance.   &mdash;  MJC detroit  (yak) 14:57, 21 August 2008 (UTC)

The 'what links here' will be a shorter list and more accurate when you have finished. This will be much easier for Lightbot. Let me know as you complete each unit. Incidentally, there is still something weird with cubic inches. If you run 'what links here for 'Template:Convert/in3', you get 55 articles and I still can't work out why. Lightmouse (talk) 15:28, 21 August 2008 (UTC)


 * I think it maybe a cache thing. Go to any article in the 'what links here' page.  Then, click edit and go all the way to the bottom and you'll see 'Template:Convert/in3' in amongst the other templates. Next click, "Show preview".  You'll notice that the 'Template:Convert/in3' is no longer there.  That's the only explanation that I have.  Good luck Light.  &mdash;  MJC detroit  (yak) 17:13, 21 August 2008 (UTC)

That 'preview' test is a neat trick. I have also seen delays of a few hours with infobox updates. Let us see what happens here. Lightmouse (talk) 17:19, 21 August 2008 (UTC)


 * Thanks for your work on that MJCdetroit. I was making progress but somebody stopped my bot questioning its approval for its edits, see User_talk:Lightmouse. I am going back for approval again with a more generic wording. If anyone wants to view the wording and support it, please speak up at: Bots/Requests_for_approval. Regards Lightmouse (talk) 23:30, 21 August 2008 (UTC)

The template: is still using in2, ft2, mi2. Can somebody fix that please? There are also several monobook scripts that are out of date. Some are adding '|ft2|' and '|knot|' etc. See this. If these are still active, we need to ask them to update. Lightmouse (talk) 10:17, 24 August 2008 (UTC)
 * Template:Convert/list of units/area/SI

Inches to Centimetres
Take a look at the height of Jacques Anquetil. I came across this before looking at footballers heights. Why is 5 foot 8 inches (5' 8") equal to 176cm (1.76m) on this Converter? When everybody knows when they look at a tape measure, that 5' 8" = 1.73m ?? and 5' 9" is 1.75m. So this converter is out by nearly 3cm !! - Culnacreann (talk) 21:47, 22 August 2008 (UTC)


 * How are you getting 176? 5 ft comes out as 5 ft. — Huntster (t • @ • c) 00:25, 23 August 2008 (UTC)


 * It's not 5' 8", it's 5.8 feet, i.e. 5 feet 9.6 inches, which is technically correct. The person who entered it claims to be a native speaker of Estuary English, so you're lucky he didn't convert the weight to stones...RockyMtnGuy (talk) 00:58, 23 August 2008 (UTC)


 * Haha, nice catch. I've since change the page to convert into feet and inches, which is more usable for most people. — Huntster (t • @ • c) 14:45, 25 August 2008 (UTC)

Template:Infobox Islands: help needed
Would a knowledgable person have a look at Infobox Islands and see if he or she can figure out why the "elevation" parameter in the infobox, which makes use of the convert template, is producing expression errors on the infobox's documentation subpage? You may wish to continue the conversation on the template talk page. Thanks. — Cheers, Jack Lee  –talk– 06:40, 29 August 2008 (UTC)