Template talk:Convert/Archive October 2010

This is an archive of past discussions about Template:Convert. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Adjective form not working

{{convert|175|m|ft|abbr=on|adj=on}} is giving me "175 m (574 ft)" without the hyphen in the middle. Can someone please look into this? Thanks. howcheng {chat} 16:51, 20 September 2010 (UTC)

The behavior is correct, per WP:MOSNUM, which states "values and unit names should be separated by a hyphen", but this does not apply to symbols and abbreviations. The WP article Hyphen says "International Bureau of Weights and Measures and the U.S. National Institute of Standards and Technology recommend use without a hyphen: a 25 kg sphere." If you really want the hyphen, then don't abbreviate. Chris the speller (talk)

OK, then Template:Convert/doc is incorrect. howcheng {chat} 07:36, 23 September 2010 (UTC)

I don't see where the doc is wrong. What part did you find to be incorrect? Chris the speller (talk) 18:48, 23 September 2010 (UTC)

"attach |adj=on (e.g. "The 190-foot (58 m) bridge" as opposed to "The 190 feet..."). This produces the adjective form—the unit name in the singular with a hyphen (according to the Manual of Style)." So you're saying that the hyphen actually is supposed to be omitted in this case, right? howcheng {chat} 02:23, 24 September 2010 (UTC)

But the example you first complained about also had "abbr=on", which causes the unit name "meter" (which takes a preceding hyphen) to be changed to the abbreviation "m" (which does not take a hyphen). Either "175-meter" or "175 m" is correct; take your pick. Happy editing! Chris the speller (talk) 14:49, 24 September 2010 (UTC)

Ah, I see. Thanks for clearing that up. howcheng {chat} 16:18, 24 September 2010 (UTC)

However this seems to be based on SI documents that say "when the full name is used the normal rules of grammar apply". Arguably the MoS issue is that (in convert terms) abbr ↯ adj. Rich Farmbrough, 13:49, 11 October 2010 (UTC).

Changes? Help!

I made unassociated changes to a couple of pages which produced a lot of red ink to the use of several templates! I think someone has changed the template in a way that will have a negative impact on a large number of pages.

Have a look at e.g. Tom Pudding. I corrected one such page by adding a 4th empty parameter - this hasn't been required in the past. Chris55 (talk) 12:52, 11 October 2010 (UTC)

hmm, seems to have gone away now. System glitch? Can't even see the intermediate edits. Chris55 (talk) 14:25, 11 October 2010 (UTC)

I noticed the same thing on Lepidophthalmus turneranus. Clicking "Related changes" only showed up one recent change in the template namespace (containing a presumably inadvertent addition of a '{'), and fixing that seemed to solve the problem. --Stemonitis (talk) 15:29, 11 October 2010 (UTC)

Can the abbreviation 'ch' be supported?

It's handy that abbreviated or symbolic form of units can be used as template parameters. This makes it predictable and compact. Unfortunately, in the case of chain, the abbreviated form 'ch' isn't supported and only the full form works. Would it be possible to support the abbreviation? Lightmouse (talk) 22:04, 31 August 2010 (UTC)

yes JIMp_talk·cont 11:10, 21 September 2010 (UTC)

Good. I see it isn't yet available, I'll wait till I hear more. Thanks Lightmouse (talk) 12:01, 21 September 2010 (UTC)

Can we do the same for 'board ft'? Lightmouse (talk) 12:03, 21 September 2010 (UTC)

{{Convert/chain}} has to be edited but it's protected. JIMp_talk·cont 06:04, 12 October 2010 (UTC)

12-Oct-2010: I have created Template:Convert/ch to handle symbol "ch" for chains, separately; however, we can't use "mi" with "ch" together unless Template:Convert/mi is fixed to accept either "chain" or "ch" as the 4th parameter. Meanwhile, I have created Template:Convert/miles to allow newbies to put "miles" as {Convert|4|miles}, and that will also support either "chain" or "ch" (as the way Convert/mi should be fixed when edited). Examples:

{{Convert|4|miles}} → 4 miles (6.4 km)
{{Convert|4|miles|7|chain}} → 4 miles 7 chains (6.6 km)
{{Convert|4|miles|7|ch}} → 4 miles 7 chains (6.6 km)

NOTE: I only advocate using full names, such as "miles" for the most common units that newbies might try (not for every unit's full name). Also, should we support "and/link" for miles and links? checking for "link" would be inside Convert/miles. -Wikid77 (talk) 15:42, 12 October 2010 (UTC)

 

Could somebody make sure that no-breaking-spacing is employed in this template? I have seen quite few places where this template is used but the nbsp is not enabled. Nergaal (talk) 04:17, 12 October 2010 (UTC)

See also related discussion at Wikipedia:Featured list candidates/List of battlecruisers of the Royal Navy/archive1 on the candidate in question's talk page. I don't know, but I believe it is also possible that too many   (i.e. not having any breaking spaces) would cause the same affect as having no  s. Thanks, Rambo's Revenge (talk) 14:12, 12 October 2010 (UTC)

Thanks for checking the word-wrapping of the amounts. Generally, for long unit-names, we want the text to wrap, but in tables, sometimes, even short names could be wrapped in narrow windows (800x600) or hand-held devices. We have been fixing the option abbr=mos to not wrap on small numbers. Hence, for listing conversions in tables, set some column-widths in pixels (or xx%) to force a wider column where measurements will not wrap as much. However, in some cases, the amounts could be hand-coded to fit in narrow columns. See examples, in table below for {convert|1|x|2|in|abbr=on} or {convert|3|ft|4|in|abbr=mos}.

#	width 25px	Main guns 50px	Main guns 90px	Main guns 125px	Size 25px	Size 90px
1	1 in × 2 in (25 mm × 51 mm)	1 in × 2 in (25 mm × 51 mm)	1 in × 2 in (25 mm × 51 mm)	1 in × 2 in (25 mm × 51 mm)	3 feet 4 inches (1.02 m)^*	3 feet 4 inches (1.02 m)^*

Again, as always, we encourage people to hand-code amounts for special formatting, so in those cases, people can insert each "&nbsp" within those hand-coded amounts. -Wikid77 (talk) 17:13, 12 October 2010 (UTC)

wrong conversion between lb and N

{{convert|1|lb|N}}, 1 pound (^{[convert: unit mismatch]}), for me shows as "1 pound (0.45 N)" Bewareircd (talk) 13:51, 8 October 2010 (UTC)

it seems to equate a newton to a kilogram force, or to 10 N; it is a factor 10 off Bewareircd (talk) 13:49, 8 October 2010 (UTC)

Try using lb-f instead of lb. {{convert|1|lb-f|N}} -> 1 pound-force (4.4 N) Stepho (talk) 14:10, 8 October 2010 (UTC)

i raised this issue because i've seen a page do it like this (convert between lb and N), even if it's wrong. that i've seen it once, means it's probably done a lot - it's a "silent corruption" that will, if left as is, cause a lot of ambiguity in the long run and do more harm than good, i think it should be handled more neatly. if converting between lb (mass) and N (force) can only, ever, mean interpreting it as "pound force", then perhaps the conversion should treat it as pound force. otherwise, it has to show an error message in the output so the editor will fix it.Bewareircd (talk) 16:30, 9 October 2010 (UTC)

I agree. I will see if I can come up with a solution. Perhaps just deleting that particular conversion. Plastikspork _―Œ^(talk) 22:01, 9 October 2010 (UTC)

Okay, it should be possible to catch say lb -> N and N -> lb, but there is a larger issue in that there are so many possible force units, and so many possible mass units, and there is nothing in this template to make sure your conversions are using mass for both the input and output (or force for both input and output). In fact, consider that I can do the following nonsense {{convert|1|yard|N}}, which produces 1 yard (^{[convert: unit mismatch]}). There are a few possible design solutions, but the largest challenge is that the complexity of this template is so great, that it often spits out random errors, most likely due to "pre expansion" limits. However, I don't think if anyone really knows what causes this problem. Just have a look at the templates in Category:ParserFunction errors, which are almost all due to this strangeness of transcluding a convert template through the {{documentation}} template. I will think about this a bit, but let me know if you have a suggestion. Plastikspork _―Œ^(talk) 23:02, 9 October 2010 (UTC)

what about detecting conversion between a mass and a force, and then assuming the mass under earth gravity? for example this would convert 1 kg to 9.8 N, 1 lb to 4.5 N, 1 lb to 1 lbf, 1 kg to 1 kgf, etc Bewareircd (talk) 02:28, 10 October 2010 (UTC)

Okay, the way this template works is that the number is passed to the input unit subtemplate, (e.g., {{convert/lb}}), which then converts that number to an intermediate value (in this case the value in kg). This number is then passed to the output unit subtemplate, which finishes the conversion. The key here would be to have either the input subtemplate or the output subtemplate check to make sure these intermediate units match. This would catch errors with both the more obvious things, like force being converted to length, and less obvious things like lb-f vs. lb. I can certainly implement this, but my only concern is breaking something by adding complexity, which may hit the pre-expand limits which limit the repeated use of this template, or the transclusion limits, which limit using this template within more complicated templates. Perhaps this change can be made in a fairly simple way which won't cause any problems. Any input is welcome. Plastikspork _―Œ^(talk) 04:37, 12 October 2010 (UTC)

I had made a start ... a very basic start on this issue with some new subtemplates I had been working on. The basic idea is that a dimension parameter is passed along from the input unit subtemplate and checked at the output unit subtemplate. The dimension is encoded as a number. The number isn't just any ad hoc number. I'm using products of powers of primes: 2 is length, 3 is mass, 4 is area, 5 is time, 6 would be length times mass (if this were any use), 7 is ... some other base unit, 8 is volume ... or something like that ... I'll have to dig it up ... 2/5 is speed, 2/25 is acceleration, 6/25 is force ... currencies get their own primes too. I'll try to dig up what I was doing. JIMp_talk·cont 05:16, 12 October 2010 (UTC) ... I found one some of them: {{Convert/LoffAoffDbSoffper}}, {{Convert/t/ha}}, {{Convert/$/m2}}, {{Convert/$/sqft}}, {{‎Convert/£/acre}}, {{Convert/cuft/sqmi}}, etc. So far it's set up for stuff like this unit per that‎ unit, something new that I was introducing. To get it working for general unit conversions we'll have to make additions so that the extra parameter is defined, carried through and checked. We should be able to introduce it gradually: with the error message appearing only if the wrong parameter is passed on (as opposed to not getting the correct one). Of course, there is tricky stuff like whether 12/25 is energy and/or torque and gallons per mile would be 4 like area (might have to introduce another prime to distinguish such things). JIMp_talk·cont 05:57, 12 October 2010 (UTC)

How about just having the input template pass its output units, which could be passed in to the output template. For example, if {{convert/lb}} is used as an input template, it passes "kg" to the output template, which would then refuse to make the conversion, if it wasn't expecting to be passed a value in kg. To update it gradually, you could make it still work if no units are passed, and eventually add this to all of them? Plastikspork _―Œ^(talk) 01:13, 13 October 2010 (UTC)

Input templates don't have fixed output units. You might want to convert inches to centimetres, I might want millimetres. Kilopascals might be converted to torr, inHg, psi. The beauty of number codes is that if in some more advanced incarnation of the template input units are combined, new dimension codes could be formed by multiplying/dividing the base ones. I mean suppose we could have a conversion from arbitrary input unit one per arbitrary input unit two to arbitrary output unit one per arbitrary output unit two, e.g. pints per acre to litres per hectare. Perhaps we wouldn't want to bother with a pints per acre subtemplate (that might be used only once) but we could have a set-up to use the pint subtemplate and the acre subtemplate, we'd get the 8 from the pints divide it by the 4 from the acres to give a 2 to match the 8 from the litres divided by the 4 from hectares. I don't know of any plans to implement such a thing but it might be a possibility worth keeping open. JIMp_talk·cont 06:26, 14 October 2010 (UTC)

For detailed discussion of encoding the dimension of a unit, see subtopic below "#Encoding dimension to detect nonsense". -Wikid77 (talk) 09:11, 14 October 2010 (UTC)

Encoding dimension to detect nonsense

The issue of preventing "nonsense conversions" of unrelated units (such as feet to pints) could be quickly implemented IMHO by having default dimension values for the rare unit-combinations not likely to be used. Plus, I see the dimension codes as letters (not numbers), such as "L" for length, "A" for area or "FV" fluid volume, where combinations are validated by comparing concatenation of letters, such as joining "FV&A" (rather than compare by numeric division). In that manner, the conversion of pints-per-acre units, against litres-per-hectare, would be compared as both "FV&A" (for fluid volume and area). The separator ampersand "&" is needed in case some letters might combine to match a 2-letter code (where "F" for force & "V" volume might otherwise join as "FV" being same as fluid-volume units, so instead join as "F&V"). The danger of numbers comes from similar ratios, such as converting numbered dimension codes of 8-per-4 into 6-per-3 which might both divide as being 2. I suggest we migrate to those multi-letter codes, not use number codes. As noted above, progress will be simpler by testing actual sandbox subtemplates, such as {{Convert/LoffAoffDbSoffper}}, because talking about it should be backed by a proof of concept.

Meanwhile, as suggested above, for now we could avoid an extra dimension-code parameter and instead, just check the dimension value of the current default output-unit parameter ("o=mm"), by mapping such as using {{Convert/dimcode|xx}} to return "L" for mm, cm, m, in, yd, ft (etc.), rather than passing an extra parameter into the hundreds of unit subtemplates, at this time. Again, this is sanely feasible by focusing, first, on the most-likely troublesome mismatches of units, rather than trying to catch every theoretical bad combination of mismatched conversion units. Hence, only some of the subtempates would invoke {{Convert/dimcode}}. As I recall, this design uses the important computer concept of an "accessor function" to access the dimension-code for a particular unit, without needing to change hundreds of subtemplates to pass the code yet. Only the few subtemplates which invoke {Convert/dimcode} would have an increased nesting problem, with the current MediaWiki 40 nest-level limit. -Wikid77 (talk) 09:11, 14 October 2010 (UTC)

Interesting idea using the o parameter but the checking device would be very cumbersome (which might limit the # of times the template could be used) & might not ever be able to be completed (How many different values could o take?). JIMp_talk·cont 21:11, 14 October 2010 (UTC)

I'm expecting that we follow the 80/20 rule, so we would only expand the template to handle the "20%" of unit-codes used in "80%" of the nonsense conversion attempts, or the 5% of units used in "95%" of likely mismatches. I've forgotten the nonsense combinations which people feared in the past. I think the unit-code "C" (for coulomb?) was likely to also mean degrees Celsius, so in that case, {{Convert/C}} might be adjusted to handle either unit, depending on the dimension-code of the various {o} which it received. For now, we can edit {{Convert/ftlb}} as {{Convert/ftlb/sandbox}} or the new {{Convert/miles}} to reject conversion of mismatched units into "miles" (not "mi"). From that, we can determine the impact on the 40-deep template-nesting limit. Again, this is only sanely feasible by focusing on the most-likely nonsense conversions, not all remote possibilities. Sorry this issue has dragged on for so many months, but I think it can be tested overnight or early morning. -Wikid77 01:20, 15 October 2010 (UTC)

Now {Convert/miles} rejects non-length units, see below: #Rejecting nonsense conversions. -Wikid77 (talk) 05:36, 15 October 2010 (UTC)

1 pound (^{[convert: unit mismatch]}) conversion between "lb" and "N" is not yet fixed as of now and shows "1 pound (0.45 N)" Bewareircd (talk) 22:33, 15 October 2010 (UTC)

Edit Request, Centimeter is non-SI Metric

In Template:Convert/list of units/length/short list, centimetre is listed under SI. It's actually metric, which is very closely related to SI. The template is semi-protected. 98.202.45.254 (talk) 17:30, 11 October 2010 (UTC)

It's not a base unit, but it's certainly an SI unit. --Cybercobra (talk) 17:51, 11 October 2010 (UTC)

SI is officially 'the modern form of the metric system' and has been for 50 years. The prefix 'centi' is part of SI and is listed at the official SI website. A popular misconception is that SI is decimal but without the prefixes SI isn't decimal. The base and derived units are designed to form a coherent set independent of number base. SI prefixes eliminate coherence are the only feature of SI that depends on base 10. That may be what the original poster was referring to. Lightmouse (talk) 12:23, 14 October 2010 (UTC)

conversion from oz to ml, and hp to W, are inaccurate and ambiguous

converting oz to ml shows "28,000" ml (an implied mass to volume conversion?), and hp to W shows 750 W. first there's multiple horsepowers and multiple fluid ounces, secondly, none of the horsepowers and fluid ounces are exactly equal to the metric values displayed (the fluid ounces are all bigger, the horsepowers are all smaller). so this is guaranteed to introduce an error, and it can give a false sense of authority or accuracy in the metric value. someone may copy the metric value, and someone else may convert it to a traditional unit again, accumulating error.

Rejecting nonsense conversions

Template {{Convert/miles}} now rejects use of non-length units. Template {{Convert/lb/sandbox}} rejects "km" or "kq" misspelled for "kg". For months (years?), people have been concerned about accidentally using incorrect, mismatched units and converting to nonsense, such as metres to quarts or square miles. A common mistake might be to put "km" where "kg" is needed. These problems can be detected, in one-unit conversions, by checking parameter 3 for compatibility of units, inside each unit-code subtemplate, such as {{Convert/miles}}. As a proof of concept, {Convert/miles} has been updated to demonstrate what impacts will occur when rejecting nonsense conversions. Since {Convert/miles} is the newbie version of {Convert/mi}, it is rarely used and helps to demonstrate the idea of rejecting nonsense conversions. Some examples:

{{Convert|4|miles|km}} → 4 miles (6.4 km)
{{Convert|4|miles|kg}} → 4 miles (^{[convert: unit mismatch]})
{{Convert|4|miles|qt}} → 4 miles (^{[convert: ambiguous unit]})
{{Convert|2|miles|in}} → 2 miles (130,000 in)
{{Convert|2|miles|ink}} → 2 miles (^{[convert: unknown unit]})

A major lesson learned, in changing {Convert/miles} to reject non-length units, is that only the valid length units need be considered, while ignoring all other types of units. This means that, for now, {Convert/miles} only needs to validate using a subtemplate which looks for valid length-type units (ignoring others). Similarly, a conversion for fluid volume would only need a subtemplate to check for such volumes, and ignore the hundreds of other units such as for length, area, force, wattage, temperature, etc. This logic limits the scope of the problem for each type of unit. Hence, updating a subtemplate to check for a new unit-code, such as for area km2, would not affect 95% of the other subtemplates, or the articles using them.

In cases requiring extreme efficiency, the test for valid units could be directly hard-coded, while omitting rare units, and streamline the operation for faster results, by focusing on the most-likely mismatches (such as putting "km" for "kg"), not all possibilities. Currently, lb (mass pounds) will convert to "km" misspelled where kilogram "kg" is needed, so the proposed sandbox rejects "km" or "kq" (k-que):

{{Convert|25|lb|kg}} → 25 pounds (11 kg)
{{Convert|25|lb|km}} → 25 pounds (^{[convert: unit mismatch]})
{{Convert|25|lb/sandbox|km}} → 25 lb/sandbox^{[convert: unknown unit]}
{{Convert|25|lb/sandbox|$}} → 25 lb/sandbox^{[convert: unknown unit]}

More complex conversions would typically require more difficult changes to reject invalid output units. However, the problem seems to be easy to address for most common mismatches. -Wikid77 (talk) 06:48, 15 October 2010 (UTC)

Each of these wrong inputs are checked on the unit subtemplate with a switch. I can't imaging how big the switch would have to be to cover all possibilities. But switches are very good at slowing templates down and even a switch big enough to cover a decent number of reasonable mistakes might have an impact on the number of time the template can be used. I still think we're better off encoding each dimension and passing a dimension code be it numeric or alphabetical. ... or we could have a subsubtemplate like {{convert/m/dimsion}} with dimension info and have a subroutine check the dimension sub pages. JIMp_talk·cont 00:53, 16 October 2010 (UTC)

I agree and understand the concern about the likely "big switch" branches which would be needed, so I think the easy way is to just check common mass/weight conversions for a few invalid "km" or "kq" (k-que). Otherwise, there are a myriad units of each type: for lengths, starting with miles-to-km, goes to mm, tiny microns, surveyor links & chains, leagues, or gigantic parsecs & AU, etc. Because parameter 3 (as "km") is user-specified, there is no dimension-code from the user to be passed. Hence, a mapping-lookup must be done, to check "km" for mapping as an "L" length-type unit. To handle any possibility, I was thinking to trigger a lookup by option "dim" as {Convert/km|dim} where parameter 1=dim causes each unit-subtemplate to return "L" (or "M" etc.) rather than run the conversion. If the nesting is limited, then subsub {convert/m/dim} would be better; and testing any {Convert/xx} would quickly reveal when {Convert/xx/dim} was missing. Meanwhile, overall nesting can be improved by changing {Precision} etc. to use fewer subtemplates. Template size is no longer a problem (since 2008), but the depth of if-else nesting is a major worry here. -Wikid77 (talk) 07:24, 16 October 2010 (UTC)

The problem with /dim subpages is that we'd have to do them all. Something like {{convert/m|d=dim}} would work better. This is similar to what you're suggesting but using parameter d instead of parameter 1 since d tells the thing where to go next. But if we're just checking for the really obvious mistakes, like thinking oz is for fluid ounces, then a couple of little switches could patch these up. JIMp_talk·cont 04:45, 21 October 2010 (UTC)

Mosnum proposal: convert template defaults should always be used in articles

There's a discussion at mosnum that includes the following text:

"Don't force output units! Let those working on that tool address the problems if any."

I've seen this suggestion before. It means the tool is more responsible than the editor. You may wish to comment. Lightmouse (talk) 18:09, 29 October 2010 (UTC)

Only allowing one output unit for each input unit is silly, as for example litres should convert to pints if we're talking about beer and to gallons if we're talking about petrol; but the default should only be overridden if there's a pretty strong reason for that. You don't usually want to convert miles to millimetres, do you. A. di M. (talk) 00:17, 30 October 2010 (UTC)

Agreed. This is a non-issue, and I have to believe that Vegaswikian didn't think this through before posting. — Huntster (t @ c) 08:14, 30 October 2010 (UTC)

Demanding the default is also a problem where:

the input unit is 'ft.lbf' and the desired output unit may be either N.m or J.
the input unit produces multiple output units by default but the editor only wishes to take responsibility for one of them.
the editor is also making manual (i.e. non-template) conversions that need to be similar.

There's nothing to stop a later editor making it the default. But it's unreasonable to complain to a good faith editor up for making an original edit without the default. As long as each edit adds value, the ordinary reader is better off. Lightmouse (talk) 10:49, 30 October 2010 (UTC)

In that particular example, I don't see the point of using kilometres only as the output. A. di M. (talk) 12:36, 30 October 2010 (UTC)

Fair enough but would you say that it's forbidden for any editor to add km if they don't also add miles, cubits, furlongs, or whatever the subsequent editors want. Lightmouse (talk)