Category talk:Conversion templates

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents

[edit] Naming convention

I suggest using CamelCase names for the sake of readability as most of these are intended to be used within #expr (see m:ParserFunctions). The main reason I suggest CamelCase is that it keeps function names from breaking across lines (no spaces; yes you can use underscores but that gets ugly fast). If/when this grows large enough, it would probably be wise to protect these fully and create a single reference doc for this API (probably as part of a new WikiProject; maybe Wikipedia:WikiProject Template Functions?). See also Template:IsLeapYear (edit|talk|history|links|watch|logs) (which also uses CamelCase). —Locke Cole • t • c 01:52, 15 April 2006 (UTC)

[edit] one way conversion

I think it's unnecissary to have conversion-templates two-way, I think that it only need to be conversion to SI-units, not from. For example you might need to convert from mile, but whan do you need to convert to? →AzaToth 15:40, 15 April 2006 (UTC)

Suppose a user in England is writing the article. Their references are going to list things in kilometers, but they might think to provide the value in miles for readers who still use imperial units. --CBDunkerson 20:35, 15 April 2006 (UTC)
<joke mode on> Oops, I'm going to write a policy right now.... P: Avoid using miles (What about WP:AUM? Oh noes! already taken). Sorry for me being childish... --Ligulem 21:12, 15 April 2006 (UTC)
=) —Locke Cole • t • c 21:55, 15 April 2006 (UTC)
Yup, that's why I thought they might be needed. =) —Locke Cole • t • c 21:55, 15 April 2006 (UTC)
I belive that imperial units should only be used if the source data was using those, and no exact SI-eqvivalent is found. →AzaToth 22:21, 15 April 2006 (UTC)
Speaking as someone living in a country using Imperial units everywhere, I respectfully disagree. Using conversion templates we can have both formats in an article with no excuse for excluding one or the other (if you only have the imperial unit value available, use a conversion template to convert to the metric system; and vice versa). Then readers from nations which don't utilize one system or the other can still read/understand the article without whipping out a calculator (this also saves editors from performing conversions improperly). —Locke Cole • t • c 06:04, 20 April 2006 (UTC)
I agree, but do think that SI units should generally be listed first with the imperial in parentheses -> e.g. '10 m (32.81 ft)'. The SI are more 'internationally common' and used to some degree even in countries which haven't fully converted. --CBDunkerson 10:24, 20 April 2006 (UTC)
I'd rather avoid measurement system holy wars, but if you feel like tackling it, be my guest. =) FWIW, I agree with you that SI first and Imperial in parens makes sense, but I suspect a debate on which goes first may get ugly (ala Wikipedia:Eras). —Locke Cole • t • c 10:38, 20 April 2006 (UTC)
It certainly might. There are a lot of us who insist that as a general rule, the original measurement should go first, followed by any conversions. That means, of course, that even within one article, some measurements might be English units first, some Fred Flintstone non-SI metric units such as calories or Pferdestärke (PS) first, and some SI units first (and a few articles even have original measurements in other units neither English nor metric, such as the shaku). Of course, there are many cases when either could be considered original, and there are various levels of being original (what was used as a source by a particular editor adding the information, vs. the units in which the original measurement was made, etc.) but those are different issues. Gene Nygaard 14:38, 22 April 2006 (UTC)

[edit] Significant Digits

Is there a policy regarding the use of significant digits within these templates? I was reading the article, California_Southern_Railroad#Cajon_Pass, and saw the following nonsensical text:

...until reaching the summit 6 mi (9.656 km) further...

Now, I know that 1.000 miles equals 1.609 kilometers, and therefore 6.000 miles equals 9.656 kilometers, but "6 miles" is absolutely not the same as "6.000 miles" and therefore does not equal 9.656 kilometers. Implicit in the expression "6 miles" is the notion of "± 0.5 miles", therefore the number of kilometers represented by "6 miles" could be in the range of:

  • 5.5 miles = 8.9 kilometers
  • 6.0 miles = 9.7 kilometers
  • 6.5 miles = 10.5 kilometers

...so the number of kilometers is something like 9.7 ± 0.8 kilometers. Given the wide implied error in the miles measurement, going down to the precision of a single meter in the kilometer measurement is just silly.

It seems to me that the most correct conversion would be 10 kilometers, although the given the low value of units involved and the difference in the implied error based on the different scale of the units, this would run the risk of overstating the distance because "10 kilometers" implies "between 9.5 and 10.5 kilometers" which only represents the high end of the range shown in the list above.

I must have too much time on my hands, but this bugs me. Can anyone suggest a solution? Mmccalpin 16:18, 12 July 2006 (UTC)

I'd suggest trying to get a more precise initial measurement, saying 'approximately 6 miles (9.656 km)', or leaving it as just '6 miles' with no conversion. As you note, trying to maintain significant digits in the converted value requires an assumption about how the original was rounded. I like the 'approximately' method because it makes clear that an exact measurement is not intended and then translates '6 miles' for those more familiar with SI units. --CBD 01:15, 13 July 2006 (UTC)

[edit] Universal vs. specialized conversion templates

The following has been copied from User talk:CBDunkerson

Hi, CBD! Recently, for no apparent reason at all, I thought that having some conversion templates would have been nice. Unfortunately, it did not occur to me to do a prior research, so I failed to notice that a collection of such templates is already available at Category:Conversion templates. Before I found that category, I produced the following templates: {{km to mi}}, {{mi to km}}, {{m to ft}}, {{ft to m}}, {{km2 to mi2}}, {{mi2 to km2}}, {{m2 to ft2}}, {{ft2 to m2}}, {{C to F}}, and {{F to C}}. Now, these are much nicer and more convenient than some of the templates that have been created so far ({{FootToMetre}}, for example), so at least part of my work has not been in vain. However, their functionality is not much of an improvement over {{conv-dist}} and the likes which you created. Hence, I don't see a point for me to continue with this. I only have one request for you: could you incorporate some of the functionality of my templates into your topical templates? Mine allow the users to specify whether they want the output to show full or abbreviated unit names, whether the unit names should be spelled in American or Commonwealth English if full unit names are output, whether the unit names should be wikified, and allow to specify the precision of the result. If you could do that, we can deprecate my templates and then clean the whole Category:Conversion templates up. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:49, 7 March 2007 (UTC)

Hi Ezhiki. Yeah, there are several different variants on conversion templates. The options you describe all sound doable, but one difference between the templates you've created and 'conv-dist' not noted above is that 'conv-dist' only works properly when substituted while yours are designed to not be substituted (if they were they'd copy in all the conditional logic). Converting 'conv-dist' to a 'not substituted' format is easily accomplished, but I haven't been able to get it to work as both - only one or the other. I've been sticking with the substituted version because it leaves an end result which is just the actual text of the measurement(s) in whatever format specified. On the other hand, unsubstituted templates are easier to use and spread faster because people see their syntax on pages and re-use them. Any thoughts or preferences on this? --CBD 03:14, 9 March 2007 (UTC)
Having had several discussions on the topic with various people since the time I posted my original message to CBD, I now think that having both universal and specialized templates makes sense. The people I talked to all had different opinions—some really liked the functionality {{Convert}} provides, others liked it but found it unfit for certain purposes (such as using it from inside another template), others liked the {{km to mi}} type of templates. All in all, I think if we have one universal template ({{Convert}}), several general templates (such as {{Conv-dist}}), and a set of little single-purpose templates (such as {{m to ft}}), it should cater to everyone's needs. My only remaining concern is about substitution: obviously, huge resource-intense templates such as {{Convert}} should be substituted, but what about the single-purpose ones? On one hand, something like {{mi to km}} does not really eat up a lot of resources, but if it starts being regularly used, what happens then? As of now, the single-purpose templates cannot to be substituted (to my shame, I did not test them correctly; thanks to CBD for enlightening me—it was not as much by design as it was a design flaw). Anyway, the bottom line is that I'll happily create more single-purpose templates if there are no serious objections to that.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 16:25, 9 March 2007 (UTC)
Thinking on the idea of having both 'convert' and 'm to ft' style templates (and keeping them consistent) I came up with a new design. See {{conv}}, {{m-ft}}, and {{format measurement}}. The 'conv' template there just calls 'm-ft' and similar templates and thus would be entirely optional... people could use either {{conv|7|m|ft}} or {{m-ft|7}} and get exactly the same results / have all the same options. The 'format measurement' template does all the work of formatting the output, but receives its instructions for doing so from 'm-ft' rather than huge switches for every possible combination. It thus has a much smaller 'transclusion footprint' than {{convert}}. Under this format there'd be one template per conversion type ('m-ft', 'm-km', 'g-lb', 'mph-kph', et cetera), all of which would call and be formatted by 'format measurement' and could optionally be called by 'conv'. Only the 'm-ft' template has been created currently, but the others could be easily cloned and updated from that. In addition to that structure I'd then suggest a single large template along the lines of {{conv-dist}} to handle cases where conversions should be substituted - the template size wouldn't matter as after substitution only the resultant text would remain. Thoughts? --CBD 19:20, 10 March 2007 (UTC)
I was looking for you CBD, and this was the last thing you did earlier today. Turns out I was giving kudos on Ezhiki on these a few days ago. I'm darn certain if they're stabilized we can find some interested customers on Wikiversity and Wikibooks for them, along side the many here. I'm not sure it's necessary to subst even big-boys like convert so long as the article isn't all that complicated, and I would suspect these sorts of things aren't on large articles. Is there anyway to detect when a page is starting to reach large pre and post expansion template limits without looking at the HTML? Or do things just break after a certain point as I'm given to understand from the discourse late last summer that generated the template doc page pattern?

I put a feature request in as a follow-on to some email conversations we had for a self-subst: Magic word. That is it only executes when encountered within template flow, but will clean up the source calling text, and just patch in the results of the current expansion much like Special:ExpandTemplates. I also asked for them to implement it so that it doesn't include unnecessary residue logic... I'm thinking in terms of {{indent}} (switch based) and {{catlst}} (if-then-else chain) when say Indent was asked for five spaces and similarly in catlst, only five or six of the If statements would evaluate as true...

The two comments I've to make is the {{m to ft}} and {{ft to m}} are probably going to be the most used by the lay editor, in matters geophysical, and should have as small include footprint as possible. And like many of the utility or tools templates, these all need somekind of publicity... a handbook page, so as that's a goal of WP:TSP, suggest you sign up! <G> Cheers! // FrankB 03:30, 11 March 2007 (UTC)
Hey Frank. The smallest 'footprint' can be achieved by having each template fully self-encapsulated... but that becomes difficult to keep consistent. People will add a new feature to one template, but then people try to use it on others and it doesn't work or (worse) it is implemented differently there. The greatest consistency is created by having one template, but then you run into transclusion problems if it gets used alot on one page. I believe the best compromise is the aforementioned method of having one template for formatting and then individual templates for each conversion type. Only a little bigger than fully autonomous templates and nearly as easy to keep consistent as a single template. Some better means of handling parserfunctions and the like in substitution would be a major boon. As to transclusion limits, so far as I know looking the current transclusion size up in the page source or seeing the broken templates when the limit is exceeded are the only ways to know. --CBD 19:34, 11 March 2007 (UTC)
The {{m-ft}} idea is absolutely great! I just want to mention that one of the requests I received was to add a new formatting option to the templates—one that's compliant with this WP:MOSNUM clause—and make it default. You might want to consider that as well before you start mass-producing the rest of the templates.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:22, 12 March 2007 (UTC)

[edit] request for conversion: km to NM

Could someone who understands this stuff make a template for converting km to NM (nautical miles)? This would be useful in both nautical and also aerospace contexts. Thanks! Sdsds 05:46, 11 March 2007 (UTC)

You can currently use, {{subst:conv-dist|35|km|naut mi|4}} or {{convert|35|km|nmi|4}}... each also has various other formatting options. --CBD 19:28, 11 March 2007 (UTC)
Testing: {{km to NM|1|precision=4}} → 1 km (0.54 NM). Good opportunity to learn more about templates! Rursus 13:37, 15 March 2007 (UTC)
Testing: {{NM to km|1|precision=4}} → 1 NM (1.852 km). Rursus 13:53, 15 March 2007 (UTC)
Testing more: {{NM to km|1|precision=4|wiki=yes|abbr=no}} → 1 nautical miles (1.852 kilometers) and {{km to NM|1|precision=4|wiki=yes|abbr=no}} → 1 kilometers (0.54 nautical miles). Errors reported here (I'll watch!). Rursus 14:02, 15 March 2007 (UTC)
Note: I didn't understand very much, template language is a nightmare even for LISP hackers, I just copy-and-pasted from Template:km to mi, then tortured the servers by previews until my mess served me the text I wanted. Rursus 16:42, 15 March 2007 (UTC)
I'm afraid it's not the template language itself but my style of writing this kind of code that gave you a headache :) Sorry about that!—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 17:01, 15 March 2007 (UTC)
Not one chance in the entire history of Universe to make readable code with a language where a variable reference to var is {{{var}}} ;^#), however proficient the template guru! Rursus 17:48, 15 March 2007 (UTC)
However unreadable it may be "under the hood," these templates rock! Check out negative values for precision: {{km to NM|150|precision=-1}} and {{NM to km|123000|precision=-3}}: 150 km (80 NM) and 123,000 NM (228,000 km). This is too cool for words. Thanks!! Sdsds 18:33, 15 March 2007 (UTC)

[edit] conversion: ly to pc

Very specialized for astronomy: {{ly to pc|4.31}} → 4.31 ly (1.3 pc). Rursus 14:32, 15 March 2007 (UTC)

Retrieved from "http://en.wikipedia.org../../../c/o/n/Category_talk%7EConversion_templates_4c24.html"