Template talk:Convert/Archive January 2012

Another range

In Twenty-foot equivalent unit I had to resort to "...between 4 feet 3 inches (1.30 m) and 9 feet 6 inches (2.90 m)" because {{convert|4|3|and|9|ft|6|in|m}} --> "Expression error: Unexpected and operator 9 Expression error: Unrecognised word "ft" Template loop detected: Template:Convert... " would not work, nor would {{convert|4|ft|3|in|and|9|ft|6|in|m}} --> 4 feet 3 inches (). Peter Horn User talk 16:51, 30 December 2011 (UTC)

• The ranges of 2-unit conversions have reached a point of being just too complex to handle, so the simplest solution is to code each 2-unit conversion separately, such as {{convert|4|ft|3|in}}, or hand-code the whole conversion. Otherwise, it becomes a slippery slope of variations, such as converting feet with a range of inches:

• {{convert|4|ft|3|in}} → 4 feet 3 inches (1.30 m)
• {{convert|4|ft|3-9|in}} ← Also too difficult to handle.

Users might want to see a partial 2-unit range of the form "4 feet 3–9 inches (1.30–1.45 m)" but such complex variations need to be done as hand-coded text. Otherwise, the Convert subtemplates for ranges would become so hideously complex that no one could update them without breaking some other feature which formerly worked well. This general concept is called "creeping featurism" in computer software, which I like to say will foster a system of "featured creepyism" where every option is so bizarre and creepy that "creepiness" becomes the predominant feature of the system. Already, Convert is viewed as bizarrely over-complex by people who do not consider the thousands of combinations of formatting options currently being supported. For that reason, we try to avoid new features that would require extensive complexity to implement. -Wikid77 18:32, 30 December 2011 (UTC)

So "...between {{convert|4|ft|3|in}} and {{convert|9|ft|6|in|m}}" --> "...between 4 feet 3 inches (1.30 m) and 9 feet 6 inches (2.90 m)" then, as I have already done, is "the cat's meouw". Peter Horn User talk 18:54, 30 December 2011 (UTC)

• Yes, coding 2 separate instances is best, with 2 uses of {{convert|...}} as the best solution for that case. Trying to combine both ft/inch amounts, as a range, can generate a "Template loop" so handling that would increase the complexity of all similar conversions just to check for that case. I wish the WP developers would increase the "Expansion depth limit" beyond 40 levels, to allow more complexity in Convert, but adding other extra capacity might allow vandals to overwhelm WP with busy-work pages. It would be great to increase ONLY the expansion-depth limit, but often, the resource additions are made to several limits which might open the door to abuse of all related resources. We see similar problems in the Vector-skin interface, added to allow special features beyond the Monobook-skin, but some top page-tabs there are peculiar now, such as "Read" and "View history" when the tabs "article" and "history" were fine as common-sense names in Monobook. -Wikid77 00:50, 1 January 2012 (UTC)

Flight Level

Something that would be very useful for aviation articles would be to add Flight Level. This is an inherently approximate measure for altitude used in aviation. Conversion to feet is done by multiplying by 100, therefore, Flight Level 100 (FL100) means an elevation of 10,000 ft. Technically, it means the air pressure normally seen at 10,000 ft, so this measure has a conversion to both length and pressure. Thanks, D O N D E groovily Talk to me 13:39, 16 December 2011 (UTC)

• Thanks for raising this issue. Because Convert typically handles numbers, then the 2nd parameter would need to indicate that flight levels are being converted. It is no problem to have parameter 1 as "FL240" if parameter 2 denotes that as a level, such as by "lev" or "FL" or some other unique unit-code. Currently, Convert handles musical notes, with unit-code "note" as in converting the musician's Middle C to hertz:

• {{convert|Middle C|note}} →

I wonder what unit-code to use for flight levels. Perhaps "FL" would be best, but it might confuse editors trying to put "FL240" as the first parameter:

• {{convert|FL240|FL|m}} →

Meanwhile, we would also need more articles to be using the "FL" notation, to discuss these conversions with a wider group of users. -Wikid77 (talk) 06:18, 29 December 2011 (UTC)

• • There a quite a few articles in aviation that use Flight Level. For example, many articles on airline disasters mention Air Traffic Control directions to go to FL 300, for example, so it's pretty common. I'll point Wikiproject Aviation to this section. D O N D E groovily Talk to me 18:39, 7 January 2012 (UTC)

Option "adj=mid" not working

This doesn't work:

{{convert|9|km|adj=mid|long}}

It should produce

9-kilometre long

But instead produces:

9-kilometre ()

-- Green Cardamom (talk) 00:34, 4 January 2012 (UTC)

What? Couldn't you just use {{convert|9|km|adj=on}}-long 9-kilometre (5.6 mi)-long? (Assuming it's an attributive adjective, as in a 9-kilometre (5.6 mi)-long bridge; if it's predicative, just use the bridge is 9 kilometres (5.6 mi) long.) ― A. di M.​  00:43, 4 January 2012 (UTC)

That's in fact what I did, but adj-mid is still not working. Either fix the code, or fix the documentation. Green Cardamom (talk) 00:53, 4 January 2012 (UTC)

the problem is that since the target unit is missing, it thinks you are converting km into long. try this {{convert|9|km|mi|adj=mid|long}} instead. Frietjes (talk) 16:11, 4 January 2012 (UTC)

I looked at it over and over to make sure it wasn't user error and so concluded it was a bug, but of course user error. Thanks for the fix. I think the documentation should clarify both source and target are needed when using the adj=mid option, I just made an edit to the doc. Green Cardamom (talk) 17:22, 4 January 2012 (UTC)

A little cumbersome but {{convert|9|km|mi|adj=on|disp=x| long (|)}} would also work. JIMp _talk·cont 15:50, 5 January 2012 (UTC)

• Use unit-code zero "0" for default: With adj=mid, the 2nd unit-code must be specified but can be zero (0) to get the current default for the input unit-code. For example, for "km":
        • {{convert|9|km|0|adj=mid|-long}} → 9-kilometre-long (6 mi)
  By using "km|0" then the default unit-code of "mi" is supplied, internally. This zero option is very beneficial for more-rare units, such as "ftlb":
        • {{convert|9|ftlb|0|adj=mid|force}} → 9-foot-pound force (12 J)
  With "ftlb|0" the 2nd unit-code is supplied internally as "N·m". The option adj=mid expects the text to be in parameter 4 for 1-unit conversions, or text in parameter 6 for 2-unit conversions. -Wikid77 (talk) 06:59, 6 January 2012 (UTC)

Range conversion issue

When the conversion of a range results in the same two numbers (to the specified precision) it would be nice if only one was output. Example: {{convert|5|–|6|mm|in|abbr=on|1}} gives 5–6 mm (0.2–0.2 in), rather than 5–6 mm (0.2 in). Peter coxhead (talk) 11:01, 11 December 2011 (UTC)

Yes, good point. We'll have to look into this. JIMp _talk·cont 21:50, 11 December 2011 (UTC)

That would indicate the precision is not enough. Perhaps a red warning asking for more precision would be better. Even better if the template would automatically increase the precision until the outputs differ but that might be asking too much.  Stepho  talk  21:59, 11 December 2011 (UTC)

I don't agree at all that it indicates that the precision is not enough. If a range is given as 5–6 mm it can be assumed that each value is accurate to ±0.5 mm. I work on articles on plants where it's easy to measure to the nearest millimetre by eye: rulers are so marked and a millimetre is easily seen. If you convert the range to 0.20–0.24 in, this implies an accuracy of ±0.005 in. This is quite, quite different. Rulers aren't marked in 1/100ths of an inch and you couldn't measure to this accuracy by eye even if they were. Furthermore the precise boundaries of things like leaves don't lend themselves to measuring their width to the nearest 1/100th of an inch. No way would I ever want to convert measurements on living plants given in whole millimetres to 1/100ths of an inch. Peter coxhead (talk) 11:28, 12 December 2011 (UTC)

We'll have to get fractions up and running so we can convert millimetres to 1⁄32s of an inch. JIMp _talk·cont 23:14, 12 December 2011 (UTC)

Millimetres are perhaps best converted to 1⁄16s for those still wedded to antique measurement systems. (But don't expect that I'll ever use this facility!) Peter coxhead (talk) 17:04, 13 December 2011 (UTC)

5–6 mm (0.2 in) would be completely fine if it's intended to be a rough measurement or estimate, rather than a range (though about 6 millimetres (0.2 in) might be better). ― A. di M.​  17:36, 13 December 2011 (UTC)

Well, I would certainly like to see the template produce 5–6 mm (0.2 in), which was my original request. If the source says "5–6 mm" I tend to repeat this rather than say "about 6" which could be read differently. Peter coxhead (talk) 22:40, 13 December 2011 (UTC)

Yes, millimetres to 1⁄16s of an inch is generally probably better. It's kind of cheating but 5–{{convert|6|mm|1|abbr=on}} gives "5–6 mm (0.2 in)". It's basically ignoring the "5" and converting only the "6". If you're doing that, though, I recommend putting a hidden note expalining that it's intentional: I see this type of thing often when it should be a range (& duely fix it, as others might). JIMp _talk·cont 09:01, 14 December 2011 (UTC)

Hand-coding for unusual cases: Where both ends of a range round to the same value, the easiest solution is to hand-code the conversion as just the 1st amount followed by conversion of the 2nd amount:

• Start with: {{convert|5|-|6|mm|in|abbr=on}} → 5–6 mm (0.20–0.24 in)

• Round results: {{convert|5|-|6|mm|in|abbr=on|1}} → 5–6 mm (0.2–0.2 in) -- notice as same

• Hand-code: 5–{{convert|6|mm|in|abbr=on|1}} → 5–6 mm (0.2 in)

By looking at the results, and noticing the result range has both the same numbers, then hand-coding the 1st amount (as "5–") is the easy solution. Always remember that the current Wikipedia MediaWiki software has been deliberately configured with narrow limits to thwart use for super-smart algorithms, to deter people from building complex transformations or decision-making templates. The extra logic needed to check for an exact match, for when both amounts convert to the same rounded number, would likely cause the number-range logic to exceed the tiny MediaWiki expansion-depth limit when displayed in the Template:Convert/doc subpage. Again, such limits have been deliberately set to tiny limits to deter editors from creating highly-intelligent templates with decision-making powers. However, we are always trying to invent ways to bypass the typical tiny limits. -Wikid77 09:39, 14 December 2011 (UTC)

See Template talk:Convert#Common fractions in the output below as applicable to the conversion of metres (meters) to fractions of miles. Peter Horn User talk 17:50, 30 December 2011 (UTC)

By the way, never mind rulers, for precision measurements one would use calipers or micrometers. Hence {{convert|5|-|6|mm|in|2|abbr=on}} 5–6 mm (0.20–0.24 in) is quite reasonable. It all depends on the context. Peter Horn User talk 16:07, 13 January 2012 (UTC)

New Convert/mix2 for mixing units

Although the uses will be fairly limited, the new Template:Convert/mix2 allows a conversion to have 2 amounts of different units. The documentation is shown below:

---

{{Convert/mix2/doc}}

This Template:Convert/mix2 is called the "mixed converter" as a unique name for future reference. It is intended to handle cases where small & large units are mixed in a range, or for any apples-and-oranges mix, such as height and weight. Because it uses a wrapper-template design, Template:Convert/mix2 will NOT affect the way any other conversions have been handled. It has the same nesting levels, within the MediaWiki preprocessor expansion-depth limit, as with Template:Convert/2. -Wikid77 07:43, 11 January 2012 (UTC)

Multi-lingual Convert for Commons

Currently, on Wikimedia Commons (where the free photos are stored with multiple languages), there is a limited version of {{Convert}}, with some features as here on English Wikipedia. I recently ported {{Convert/2}} to allow unit-ranges on Commons, but trying to port all the features of Convert would be difficult to maintain over there, plus the need to provide conversions in other languages. I cannot find any "non-hideous method" to implement Convert for each of the 280+ Wikipedia languages. Hence, for now, I am recommending people focus on conversions in the English descriptions of images. After several months, I think we could support a few languages (such as Spanish "metro" for "meter") for just the most basic conversions, but otherwise, as always, when the format (or the other language) is obscure, then hand-code the conversions on Wikimedia Commons.

Commons wikilinks need t=:en: prefix: Meanwhile, to wikilink conversions in image descriptions, the Wikimedia unit-subtemplates have been changed to use the ":en:" prefix, such as commons:Template:Convert/km having "t=:en:Kilometre" to link back to English WP article "Kilometre". Again, for rare conversions, run the numbers here on enwiki, or on some other-language Wikipedia, and just hard-code the numbers on Commons, until Convert can be expanded over there.

Converting for other major languages: In the future, I am thinking to create a few multi-language, simple big-switch convert templates on Commons, such as for m/ft, kg/lb, g/oz, km/mi, or cm/in:

• Convert/fr - for French, m-to-ft as:   32 mètres (105 pi).
• Convert/es - for Spanish, m-to-ft as:   32 metros (105 ft).
• Convert/no - for Norwegian, m-to-ft as:   32 metres (105 ft).

There might be significant use in those languages to support the effort for various other-language Convert/xx templates. However, I am not sure how much effort would be needed to switch the decimal-point (105.6) to decimal-comma (105,6) in other-language numbers. The whole situation might be better by just hand-translating the unit-names from the English-description conversion and hand-fixing the decimal-comma, in the relatively few cases where needed. There might be no easy ways to auto-translate the unit names in image descriptions, depending on right-to-left word order in Arabic or other languages. For those reasons, the commons:Template:Convert is currently stuck as an English-only conversion module. -Wikid77 (talk) 07:40, 27 December 2011 (UTC)

• For example, the term "cubic feet" in Spanish is "pies cúbicos" (singular: pie cúbico), but the abbreviation can be "cu ft" as in English. -Wikid77 12:06, 14 January 2012 (UTC)

2 questions about usage

I'm working on a couple of articles about reservoirs, and acre-feet is the standard unit of measurement; however, many people in the US don't know what this is, but are aware of US gallons. But there doesn't seem to be a way to convert acre feet to gallons because both are imperial units. How can I convert acre feet to gallons?

Second, how do I make the template say "the valley is a 2,400 square mile (6,200 square kilometer) desert region" instead of pluralising it to "the Valley is a 2,400 square miles (6,200 square kilometers)? Thanks, Matthewedwards :  Chat  04:34, 14 January 2012 (UTC)

Figured the second bit out by using "|adj=on". Still stuck on the first question. Matthewedwards :  Chat  05:01, 14 January 2012 (UTC)

• For acre-feet and US gallons, try the combined unit-code "USgal m3" as the output:

• {{convert|450|acre ft}}             → 450 acre-feet (560,000 m³)

• {{convert|450|acre ft|USgal m3}} → 450 acre-feet (150,000,000 US gal; 560,000 m³)

In general, when considering multiple output unit-codes, then use the wiki-search word "Special:PrefixIndex" such as with the prefix "Special:PrefixIndex/Template:Convert/USgal" which will list several combined unit-codes, including: Convert/USgal L, Convert/USgal L impgal, Convert/USgal impgal, Convert/USgal impgal L, Convert/USgal m3. So that reveals unit-code "USgal m3" as a possible output. -Wikid77 (talk) 12:29, 14 January 2012 (UTC)

Perfect! Thank you :) Matthewedwards :  Chat  21:33, 14 January 2012 (UTC)

OK, now I've come up against another wall. I'm writing about reservoirs with a capacity of at least 3,500 af. The template outputs as 3,500 acre-feet (1.1×10⁹ US gal; 4,300,000 m³) which looks a bit silly for both conversion units. I can do

• {{convert|3500|acre ft|e9USgal|abbr=off|sigfig=3}} to produce 3,500 acre-feet (1.14 billion US gallons) and
• {{convert|3500|acre ft|hm3|abbr=off}} to produce 3,500 acre-feet (4.3 cubic hectometres)

but when I try to do

• {{convert|3500|acre ft|e9USgal hm3|sigfig=3|abbr=off}} I get a broken template with a bunch of red text. Do you have any suggestions where I can go from here? Is it okay not to use the template?Matthewedwards :  Chat  22:15, 14 January 2012 (UTC)

There is not yet a combined unit-code for that case, and it must be created, but perhaps using "e9USgal e6m3" would be a better plan for that case:
  • {{convert|3500|acre ft|e9USgal e6m3|sigfig=3|abbr=off}}
  → 3,500 acre-feet (1.14 billion US gallons; 4.32 million cubic metres)
Give me a couple of hours to update it and check accuracy. -Wikid77 22:38, 14 January 2012 (UTC)

Display output units only?

Is there a way for convert to only display output parameters? (ie. 3 centimetres (1.2 in) only shows inches) 76.65.128.132 (talk) 04:13, 17 January 2012 (UTC)

Yes: {{convert|3|cm|in|disp=output only}}. JIMp _talk·cont 05:31, 17 January 2012 (UTC)

Feet per minute

Would it be possible to add the unit ft/m? It is used for the vertical speed of aircraft. Thanks! Falconus^{p t c} 15:27, 27 January 2012 (UTC)

Nevermind, I figured out how to do it.

Resolved

Falconus^{p t c} 15:33, 27 January 2012 (UTC)

errors

Can someone figure out why this caused a big red error message in Kurmangazy oil field. 198.102.153.2 (talk) 21:02, 31 January 2012 (UTC)

Was an accidental edit and was reverted. (ie too many windows open with too many edit pages open) -DJSasso (talk) 21:03, 31 January 2012 (UTC)