Template talk:Convert/Archive January 2008

message: I am delighted with the way that the template has been updated to handle feet and inches. I have updated my script to use it. I have just added the template AKS Continental using my script. The singular form "7 foot 6 inch" was in the article. It now has "7-foot-6-inch (2.3 m)".
I am disappointed that 'sing=on' is not just confined to singular. You can see that this has meant that my edit to that article has not just added the metric value, it has added hyphens. I did not want it to do that.
The error with date autoformatting was the conflating of independent functions. By conflating singular and hyphens, we are making the same error with the convert template. Please confine 'sing=on' to be a switch for the singular form only.
Rant over. It is a great template otherwise. Lightmouse (talk) 11:57, 28 December 2007 (UTC)
replies: text: The hyphenation is what the Manual of Style recommends for compound adjectives; 7-foot-6-inch is what should be used in the above article. TomTheHand (talk) 15:33, 28 December 2007 (UTC)
replies: text: I looked in wp:mosnum and could not see anything relevant. Can you give me a reference please? Lightmouse (talk) 15:48, 28 December 2007 (UTC)
replies: text: Sure.  See Wikipedia:HYPHEN. TomTheHand (talk) 16:44, 28 December 2007 (UTC)
replies: text: Tom's right, the hyphens should be there.  The problem is the original poor choice of parameter name.  sing was always intended for adjectives but adjectives need more than simply singularising the noun. Jɪmp 17:05, 28 December 2007 (UTC)
replies: text: I understand that it follows the MoS guidance. I think the MoS is wrong to mandate a hyphen. I have made a proposal for new MoS guidance (following Tom's reference). The root problem for me is semantic rather than lexical i.e. even if we changed the parameter name, I would still object to being forced to use hyphens. Lightmouse (talk) 17:52, 28 December 2007 (UTC)
replies: text: I think the MoS as it is currently correctly reflects standard English grammar. Jɪmp 19:17, 28 December 2007 (UTC)
replies: text: I do not think it does. Lightmouse (talk) 10:47, 29 December 2007 (UTC)
thread_title:  Please eliminate mandatory conflation of 'hyphen' and 'singular'. 

message: Let's say that my reference has all the information in inches and feet, but I want the lengths in the article to be given first in cm and m. It would be nice to have a |reverse parameter to achieve this.--Curtis Clark (talk) 01:05, 30 December 2007 (UTC)
replies: text: I have tried but failed to imagine a good reason for this. Can you give an example? Lightmouse (talk) 12:15, 30 December 2007 (UTC)
replies: text: I thought I had explained it; let me be more explicit. Let's say I wanted to add to the article about California Black Oak the height of the largest known specimen. Because I found this in a book published in the US in perhaps the first half of the 20th C., the measurement is given in feet, let's say 137 ft. But the rest of the article is appropriately written with SI units, leaving English units to parentheses. If I write  I get , which is backward to what I want. I could then go in and manually edit to 42 m (137 feet), but that has two unfortunate effects. First, it negates some of the convenience of . Second, and more important, it removes forever from the article a clear indication of the original measurement from the source reference (was it the m or the feet?). Of course in that specific article,  isn't used, so it's already impossible to tell whether the original references gave measurements in SI or English without consulting them. But if an article had been written from the get-go using , the cited measurements are there in the page source for all to see.  would solve this.--Curtis Clark (talk) 16:29, 30 December 2007 (UTC)
replies: text: That actually does seem a reasonable request - I've had occasion to want for it too at times. Basically all this parameter would do is display 9.6 kilometres (6 mi) instead of 6 miles (9.6 km) when 6 and mi is entered with an appropriate command to switch the display order. On an unrelated note, those working on this template set have done a fantastic job reducing the template overhead! I was looking at some outputs with subst yesterday and it's much tighter than it was. Orderinchaos 17:43, 30 December 2007 (UTC)
replies: text: Aha. Your explanation is helpful, I understand now. It is an interesting debating point. Lightmouse (talk) 17:09, 31 December 2007 (UTC)
replies: text: It would be done using the disp parameter e.g. , however, I wonder whether it would be appropriate.  The source units should generally come first with the converstions in brackets, though, let's assume that there may be some instances where their reversal is warrented.  In such a case the reversal should be noted.  There must be that "clear indication of the original measurement from the source reference", not just in the article's source code but as a footnote (i.e. we should not expect people to have to open an edit box and go searching for reverse).  Unfortunately it seems impossible to add footnotes via templates.  Jɪmp 08:40, 1 January 2008 (UTC)
replies: text: Although I see your point, this is exceedingly problematic in practice, since for plant and animal species in the US, different references often use different systems of measurement. As in the hypothetical example I gave above, heights of largest specimens of trees were often measured in feet, but floras and monographs most often report general measurements in SI. Putting the source units first would mean that the article would use mixed measurements. My suspicion is that editors who do manual conversions almost never do this; they arrange their conversions to fit with the rest of the article. Perhaps there needs to be a way to typographically indicate the source measurement, but I suppose this would be a discussion for WP:MOS or even the Village Pump. But it seems clear to me that conflicts between "source measurement first" and "consistent units across an article" have never been resolved in a consistent manner.--Curtis Clark (talk) 17:04, 1 January 2008 (UTC)
replies: text: Yeah it comes up as a problem in Australian geography articles as until 1972 most State governments still used imperial units in urban planning, and from then onwards used metric. The switch was so comprehensive (unlike Canada and the UK) that pretty much noone 35-40 or younger understands imperial units and many older people are out of practice with using them. So you could have source documents about a place built in the early 1970s that randomly flips between units depending on source document. Orderinchaos 21:00, 1 January 2008 (UTC)
thread_title:  Yet another request 

message: ::See also Template talk:Convert/Archive December 2007#Ranges
Two questions were posed in the preceding section. Only one of them was addressed. Would is be possible to get output in the formats "(4.5 - 9 cm)" or "(4.5 to 9 cm)". I am thinking in particular of a parameter that sets the separation character/text. An example would be from the Greatsword article, where I had to use the template twice a got this text: 6.5 inches (17 cm) to 9 inches (23 cm). I feel it would look a lot better thus: 6.5 to 9 inches (17 cm to 23 cm) or 6.5 to 9 inches (17 cm-23 cm). Regards TINYMark (Talk) 21:26, 9 January 2008 (UTC)
replies: text: While this capability is unavailable in , you can use .  That template does not allow selection of your own separation character, but it does output the values in the format you need.  Just an FYI.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 22:19, 9 January 2008 (UTC)
replies: text: Thanks a lot. That helps me for now. There seem to be a lot of different conversion templates and, it seems to me, they require some sort of organisation. Taking Infobox (actor, musician, film etc.) as an example, , , , ,  ....... would seem sensible. Trying to remember all these different templates is pretty head-wrecking! But then again, organising them all will also be head-wrecking for the person doing it! TINYMark (Talk) 22:50, 9 January 2008 (UTC)
replies: text: Yes, ranges are currently unavailable on this template.  I do intend to get to work on this.  It will probably take the form of .  But, yes, in the meantime, many of the other (single purpose) templates in the category do handle ranges.  By "organisation" perhaps you mean dividing the category into subcategories based on length, area, volume, etc.  This would seem sensible.  (Note that the syntax you've used above seems to suggest adding new templates rather than sorting the current ones). Jɪmp 01:37, 10 January 2008 (UTC)
replies: text: Or perhaps just renaiming them. We don't have to reinvent the wheel ;-) TINYMARK 14:17, 14 January 2008 (UTC)
replies: text: Some could do with renaming, others, deletion.  The whole category could do with a clean up. Jɪmp 03:32, 15 January 2008 (UTC)
thread_title:  Value range 

message:  gives , but when you try to convert to ft and in  gives  ! the correct figure should be 4ft 11 in.Mjroots (talk) 12:16, 13 January 2008 (UTC)
replies: text: This is the problem noted above (200 cm ==>> 7 ft 7 in).  Fixed ... I believe. Jɪmp 13:21, 13 January 2008 (UTC)
thread_title: Conversion error

message: There seems to be a problem with m to ftin when comparing to the calculations by Google, CSG, and Simetric:
code                           	answer	Google/CSG/Simetric
	      	7 ft 2 in = 2.1844 meters (they all agree)
	      	8 ft 10 in = 2.6924 meters (?)
	      	8 ft 11 in = 2.7178 meters (?)
	      	9 ft 9 in = 2.9718 meters (?)
	      	9 feet 11 inches = 3.0226 meters (?)
-- Jeandré, 2008-01-13t12:24z
:Same problem.  I think I've fixed it (was rounding rather than truncating). Jɪmp 13:26, 13 January 2008 (UTC)
thread_title: Errors: m to ftin.

message: Is this template to be substituted? I found some edits from a bot (MetsBot) back in August 2007  converting uses of this templates and filling infoboxes with (unneeded) -tags. -- User:Docu
:It looks like the bot was stopped in the meantime User_talk:Mets501/Archive_20#Convert_template. I guess I just have to fix the conversions. -- User:Docu
::Yeah, but as for substing this template, I wouldn't advise it.  Each transclusion involves a rather long string of subtemplates and can involve outside templates also.  You'd be substing all afternoon.  There are smaller single-conversion templates in the Conversion templates category which are good for substing. Jɪmp 01:08, 16 January 2008 (UTC)
replies: text: Actually, those are not so good for substing either.  You'll get a bunch (and I mean a bunch) of conditionals if you subst most of those.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 01:45, 16 January 2008 (UTC)
replies: text: True, most of them, yes.  What I had in mind were the likes of the dist templates (not sure how many other such simple templates are out there) but there's still no escaping the s. Jɪmp 03:32, 16 January 2008 (UTC)
replies: text: Looks like the auto templates are simple too.  Of course, another advantage with this simplicity is that it minimises pre-expand size. Jɪmp 04:37, 16 January 2008 (UTC)

text: To "subst" a complex template in one shot, if it really is necessary, use Special:Expandtemplates. —Random832 17:34, 17 January 2008 (UTC)
thread_title: Template to be substituted

message: Template: has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. —MJCdetroit (yak) 02:26, 2 February 2008 (UTC)
thread_title:  TfD nomination of [[:Template:{{ucfirst:Converta}}]] 

message: I am having problem with the dual conversion feature of :Template:Convert at Lucien Lagrange.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTD)  20:49, 21 January 2008 (UTC)
replies: text: That particular sub template didn't exist—it does now.    —MJCdetroit (yak) 21:36, 21 January 2008 (UTC)
thread_title:  sqft to acre and sqm 

message: Is there a way to convert numbers with exponentials, such as 2.3 × 1016 liters? Or things like 24.3 million pounds? Thanks, kwami (talk) 09:32, 29 January 2008 (UTC)
replies: text: Not at the moment (except for British thermal units) but it's food for thought. Jɪmp 07:02, 31 January 2008 (UTC)
thread_title:  exponentials 

message: When using km to mi/mi to km or m to ft/ft m and the last digit of the input number is zero it rounds the number. Some examples,
*  (actual 373)
*  (actual 966)
*  (actual 1969) 
*  (actual 183).
Yet when the last digit is not a zero it doesn't always do that. Such as,
*  (actual 373)
*  (actual 967) 
*  (actual 183). 
However,   (actual 1972)  Why? CambridgeBayWeather Have a gorilla 05:09, 30 January 2008 (UTC)
replies: text: I believe it is trying to interpret the second zero in the source as a non-precise measurement, thus it outputs a non-precise since MOS calls for such action.  It's just a matter of it trying to be intelligent and failing in this specific instance.  Just specify how many digits to round to ( would yield 1972 ft,  would yield 1971.8 ft).  However, I cannot figure out why it would be interpreting the 601 m measurement as it is, though again, specifying the "round to" field will fix it.  Jimp may be able to shed further light on this. — Huntster (t • @ • c) 07:26, 30 January 2008 (UTC)
replies: text: Thanks. CambridgeBayWeather Have a gorilla 14:14, 30 January 2008 (UTC)

text: From m to ft the number of zeros is increased by 1, because the factor 3.3 is between 2 and 20.--Patrick (talk) 14:23, 30 January 2008 (UTC)
replies: text: So it uses the conversion factor to decide whether to round or not?  I cannot begin to wrap my brain around that one. — Huntster (t • @ • c) 20:16, 30 January 2008 (UTC)
replies: text: E.g. , ; with a larger conversion factor more digits are rounded to zero. The assumption is that in the given value 100100 the zeros are from rounding; if not, as you say, specify how many digits to round to.--Patrick (talk) 23:34, 30 January 2008 (UTC)
replies: text: Yep, Patrick hit the nail on the head.  For a given conversion factor, f, the precision of the numerical conversion is decreased (the number of zeros is increased) by n where  to account for the increase in precision of the unit.  However, to maintain accuracy, it won't round to one significant figure unless you tell it to. Jɪmp 07:26, 31 January 2008 (UTC)
replies: text: Actually: .--Patrick (talk) 08:38, 4 February 2008 (UTC)

text: Ahem. All output values are accurate regardless of the precision. Lightmouse (talk) 08:59, 31 January 2008 (UTC)
replies: text: Thanks for the explanation Patrick and Jimp, makes sense now.  Lightmouse, not sure what you mean...the output figures are accurate if you are intending them to be non-precise, but if you are meaning exactly 600 km, then no, it isn't accurate (the converted figure is off by three).  ...unless you are meaning something else? — Huntster (t • @ • c) 13:58, 31 January 2008 (UTC)
replies: text: The terms 'exactly' (as in your comment) and 'actual' (as in the original comment by CambridgeBayWeather) are not clear to me. Let us set those terms aside for a moment. The terms 'accurate' and 'precise' are clear to me. I hope they are to you. You can choose to convert 600 km as: 500 miles, 400 miles, 370 miles, 373 miles, 372.8 miles, 372.82 miles, etc. Each conversion is accurate. Each conversion has a different precision. Lightmouse (talk) 22:58, 31 January 2008 (UTC)

text: ← I understand what you are saying, but the problem is whether or not the output is accurate for a given situation. If the 600 km input is a non-precise figure, then a non-precise output of 400 or 370 mi is acceptable; if 600 km input is a precise figure (as in, 600.0 km), then those outputs become imprecise and thus unacceptable. So your original statement cannot be fully correct: dependent on (not regardless of) the intended precision, the above output may or may not be "accurate". It's not that big a deal for most purposes here, but it is a distinction that must be accounted for. The template, though, is doing the best it can to accommodate the widest number of situations, and as noted above, there are easy workarounds to gain the correct output. — Huntster (t • @ • c) 01:34, 1 February 2008 (UTC)
replies: text: True, true, those are all accurate & the difference is in the precision. As for the workings of the template, give it 600 km and it'll assume you mean 600 ± 50 km, i.e. it'll take the 600 as being precise to one significant figure ... nor can a human correctly assume otherwise without context.  So  gives "" (since the default rounding gives a minimum of two significant figures).  Now, give it 600.0 km and it'll assume you mean 600 ± 50 m (four significant figures).  So  gives "".  With the default rounding I've attempted to accommodate as general a set of conversions as possible but where context may call for greater or less precision this can done by specifying the number of significant figures and/or precision you want directly.  Only context will tell you whether this would be necessary. Jimp 05:39, 1 February 2008 (UTC)
thread_title: Rounding