Template talk:Convert/Archive January 2013

Convert archive search broken?

RESOLVED: also see Help:Convert or Template:Convert/FAQ.

The documentation for this hugely complex template is woefully incomplete and thus inadiquate. Whenever I can't remember or don't know the correct format to use, I can usually find what I'm looking for by searching the talk archive. Not so today. Every search I've tried returns a not found result. Even terms that I know should return a bazillion hits, like the term convert, fails with this error message:

There were no results matching the query.

The page "Convert prefix:Template talk:Convert/" does not exist....

Yeah, this is mostly a rant about the awful state of the template's documentation but, if anyone out there reading this knows how to fix the broken search function, I'd be grateful.

—Trappist the monk (talk) 19:39, 13 December 2012 (UTC)

Sounds like something to ask at WP:VPT. --Redrose64 (talk) 20:09, 13 December 2012 (UTC)

You're right. I'll do that.

—Trappist the monk (talk) 20:22, 13 December 2012 (UTC)

And now it's working. Go figure ...

—Trappist the monk (talk) 20:28, 13 December 2012 (UTC)

• Look more in Help:Convert: Because the documentation page, {Convert/doc} tends to be extremely concise, as showing numerous options in compact form, see instead, Help:Convert, which attempts to fully explain a wide variety of different options for coding conversions in unusual cases. In fact, much of the text inside Help:Convert was copied from the template-talk archives, to condense years of tips and hints into an organized help-page, in the manner of a Help:Table or Help:Calculation. Because much text was copied directly from the {Convert} talk-page, then it contains the same phrases which people remember reading when discussing the options. There is also Template:Convert/FAQ, for short questions. -Wikid77 (talk) 10:30, 8 January 2013 (UTC)

Sorting problem with disp=table

I've just edited the table at Hamm#City structure and found that the population density columns won't sort correctly, despite that the area columns sort fine (it sorts the hundreds independently from the thousands, each in the correct order, but the group of thousands sorting lower than the group of hundreds). Each is a {{convert|disp=table}} pair, but the area are all of the same order of magnitude, which is what I assume is causing the difference.

Could someone who knows this template better take a look and see what's going on, please? In case it matters, I'm using Chrome on Windows (navigator.userAgent reports "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11"). I get the same problem in Internet Explorer too ("Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MALN; .NET4.0C; .NET4.0E)"). This doesn't appear to be a conflict with any user scripts, as I get the same problem if I look in a [logged-out] anonymous browser window and I use IE without logging in. — OwenBlacker (Talk) 20:48, 1 January 2013 (UTC)

The Pop. column has only pure numbers. The density columns have non-numeric characters (eg "km"). Pure numbers are sorted numerically as you expect. Entries with non-numeric characters are sorted alphabetically (ie first character, the second character, etc). You need to shift the units descriptors (km, mi) into the title row, leaving only pure numbers in the table. Likewise for the Area columns.  Stepho  talk  02:08, 2 January 2013 (UTC)

Using sortable=on is supposed to insert a hidden sort key (using {{ntsh}}), and that key means sorting will be numeric (based on the input value to {{convert}}). I can't find an example at the moment, but I have seen it working. However, in the case reported, inspecting the html source of the article shows that disp=table is causing the sort key to be omitted (removing that setting causes the sort key to be created). The Pop. and Area columns appear to sort correctly because the sort is alphabetical, and the particular numbers are in numeric order when alphabetically sorted. Johnuniq (talk) 03:31, 2 January 2013 (UTC)

@Stepho: Moving the units descriptors into the header isn't quite as clear, to my mind, as you may be able to see from the table (units in header, units in cells). As Johnuniq mentioned, the sort key is being omitted when disp=table is present — to my mind, that's a bug in this template. Whilst we could work around it by moving the units into the header (as you have done), it should be possible to fix the template such that a workaround is not required, surely? :o) — OwenBlacker (Talk) 19:41, 2 January 2013 (UTC)

Either method is fine by me. Some tables will be unnecessarily wide when the units are with the numbers but in this case it fits okay.  Stepho  talk  02:54, 3 January 2013 (UTC)

A capital needed

For Cazadero and San Pablo Railroad a capital starting thirty kilometers (19 mi) Peter Horn User talk 02:54, 7 January 2013 (UTC)

Eureka, from the archieves Thirty kilometers (19 mi) Peter Horn User talk 03:46, 7 January 2013 (UTC)

• Convert/spell has separate documentation: For any features about spelling-in-words, view Template:Convert/spell and search for a term, such as "capital letter" to find option "case=u". The documentation has been specially worded to mention related phrases, such as "capital letter" with "upper-case" so that a search is more likely to find the answer, without knowing the exact words for the option. -Wikid77 (talk) 10:30, 8 January 2013 (UTC)

Please refresh my memory

2×10⁷ board feet (4.7×10⁴ m³), how can one make this read "20 million board feet (47,000 m3)"? Peter Horn User talk 23:34, 9 January 2013 (UTC)

use 20 million board feet (47,000 m³) Frietjes (talk) 00:58, 10 January 2013 (UTC)

Rounding problem at lower end of range

Please see the mention here about misbehavior of the template at the lower end of a range:

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Conversion_function_not_simplifying_the_result_for_the_lower_end_of_a_range

- Ac44ck (talk) 12:44, 10 January 2013 (UTC)

Why no error message for incompatible units?

First off, thanks to everyone who frequents this page and helps me when I have a problem using the CONVERT template. And a BIG THANKS to all the software coders who have developed the CONVERT template over the years as it as emerged in the Wikipedia world. I really appreciate it! And I use the CONVERT template all the time when editing articles.

But I've been thinking further about the problem I had (by my user error) as outlined in the section above entitled Potential conversion error: lbf to Newtons. The error was I had inadvertently used "kn" when I meant kilonewton, and should have used "kN" instead. So that was all solved when Johnuniq told me: ":The unit kn is knot (speed) and {{convert}} has no method to check for incorrect units. Use kN for kilonewtons: {{convert|1100000|lbf|kN}} → 1,100,000 pounds-force (4,900 kN) — Problem solved.

But the broader question is, Why does the {{convert}} template have no method to check for incompatible units? It would seem to me to be an error case that those of us sophisticated in the units of the physics of the natural world, and sophisticated in the software to do unit conversions so superbly as {{convert}} does today, would want to provide to the perhaps less educated editors who might merely want to do a unit conversion even though they don't know much about physics, engineeing or software. So if I tried to convert knots and pounds (i.e., nautical miles per hour into pounds) like {{convert|1100000|lbf|kn}}, I would not get → 1,100,000 pounds-force () (which is bizarrely incorrect), but rather would get something like → [CONVERT ERROR: "knots" and "pounds-force" are incompatible units].

Is this just a case of "it's never been done", or "no volunteer editor of Wikipedia has ever choosen to spend the time to add the error cases to the code"? Or is this something that has been discussed before, and there is some technical reason that is holding it back even though it might be a desirable enhancement to the {{convert}} template?

It it has been discussed and a definitive decision/consensus was reached, I would appreciate a pointer to the discussion as I would like to better understand the issue. Cheers. N2e (talk) 15:57, 29 December 2012 (UTC)

{{convert}} is already very complicated, with literally hundreds of subtemplates. For the specific case of {{convert|1100000|lbf|kn}}, the following subtemplates are used: {{Convert/LoffAoffDbSoff}}; {{Convert/LoffAonSoff}}; {{Convert/kn}}; {{Convert/lbf}}; {{Convert/numdisp}}; {{Convert/outsep}}; {{Convert/round}}; {{Convert/test/A}}; {{Max/2}}; {{Order of magnitude}}; {{Precision/0}}; {{Precision/00}}; {{Precision/2010}}; {{Precision/a}}; {{Rnd}}. Even a simple change like altering the number of significant figures in the input quantity can alter the selection of subtemplates. Complications like these mean that it is already slow, so to add more features would slow it down still further, and may well push it past the template limits. --Redrose64 (talk) 16:34, 29 December 2012 (UTC)

Ok, I grok that. I get that it is very hard and/or complicated to modify the convert templates in general.

Question: Might it be possible to have the very first operation, before any numerical conversion is done, be a simple test of physical unit compatibility between the input and output units? Then, if the input units is "force", and the output units is, say, "volume per unit time" (or, anything at all other than "force"), the first thing the software would do is throw an error exception. That way, it would never have to go down the tree into conversion, and rounding, sub-templates at all. Cheers. N2e (talk) 22:53, 31 December 2012 (UTC)

The problem (i.e. in addition to the template-limit problem) is not so much when the test is done but how many units we've got in our scope. A partial solution currently does exist, i.e. some units. Work is being done on a full solution but it's going to take a while. JIMp _talk·cont 00:37, 1 January 2013 (UTC)

Thanks for that info, Jimp. I appreciate it. I will look forward to seeing the results of the work that is being done on a full solution to this problem. Cheers. N2e (talk) 06:12, 2 January 2013 (UTC)

• We can quickly update Convert/lbf to check units: After years of analysis, the typical unit-check in Template:Convert/miles has been shown to be both quick and harmless to template expansion depth. So, see Template:Convert/lbf/sandbox for a solution today.

• {{convert|45|lbf|kN}} → 45 pounds-force (0.20 kN)
• {{convert|45|lbf/sandbox|kn}} → 45 lbf/sandbox

Although the above warning message causes the internal parameters to be displayed, it is checked very rapidly, so the conversion is still ultra-quick and the expansion depth unchanged. Hence, the check for compatible units is lightning fast, with basically zero overhead in lbf conversions. The sandbox version also allows parameters 5-8, to support option "disp=x" for extra custom wording. -Wikid77 (talk) 10:30, 8 January 2013 (UTC)

Sounds like a very good fix for the problem. I look forward to the time when the template writing experts complete their review and you all are ready to turn it on for regular use. N2e (talk) 02:30, 13 January 2013 (UTC)

Temperature flip problem

{{convert|-40|C|F|0}} gives −40 °C (−40 °F) but {{convert|-40|C|F|0|disp=flip}} gives −40 °F (−40 °C) . Is there a missing sub template? Thanks.  Stepho  talk  00:45, 12 January 2013 (UTC)

fixed. Frietjes (talk) 16:06, 12 January 2013 (UTC)

Excellent - that now works beautifully.  Stepho  talk  05:30, 13 January 2013 (UTC)

Non-breaking spaces not used before unit with a range

If you convert a single value, e.g. {{convert|1|in|mm|abbr=on}} → 1 in (25 mm), there's a non-breaking space before both units, as there should be. However, if you convert a range, e.g. {{convert|1|-|2|in|mm|abbr=on}} → 1–2 in (25–51 mm), there isn't if you look at the generated HTML. This must be wrong. Peter coxhead (talk) 18:02, 7 January 2013 (UTC)

• Subtemplates need &nbsp: Each range word (such as "-") uses a separate subtemplate to format the spacing, so in this case, a change is needed inside protected Template:Convert/-/AonSoff, at line 13, to insert " " to become "--> {{#ifexpr:..." as the fix for line 13. I think that change would fix the output unit for &nbsp. See: Template:Convert/x/AonSoff, for similar issues. -Wikid77 (talk) 10:30, 8 January 2013 (UTC)

So could someone please fix this? Peter coxhead (talk) 10:03, 9 January 2013 (UTC)

Done. I have fixed that particular instance. Please file another request if you find any more. Best — Mr. Stradivarius ^{♪ talk ♪} 10:31, 14 January 2013 (UTC)

Mass¦weight per unit length

Any chance of adding these? Kg/m and lb/ft are used for structural steel shapes, and lb/yd for railroad rails. Useddenim (talk) 01:25, 14 January 2013 (UTC)

Conversions of linear density already exist for units: kg/cm, kg/m, lb/ft, lb/yd.

{{convert|100|kg/m|lb/ft}} → 100 kilograms per metre (67 lb/ft)

Johnuniq (talk) 02:37, 14 January 2013 (UTC)

Spelling error with imperial fluid ounces

Can somebody check the spelling for imperial fluid ounces? I can't find where it's embedded in the code. The error is currently manifesting in the caption for the the image at the top of Fountain pen ink. —C.Fred (talk) 15:29, 19 January 2013 (UTC)

Fixed. --Redrose64 (talk) 16:20, 19 January 2013 (UTC)

How is this done

For Victorian Railways V class#History and Description convert 12 long tons 12 hundredweight to short ton and tonnes or 12 ton 12 cwt Peter Horn User talk 02:25, 26 January 2013 (UTC)

see Template talk:Convert/LT, where I have made an edit request. Frietjes (talk) 16:03, 26 January 2013 (UTC)

I have made the edit requested but have also made a few other adjustments. The problem is that "LT", "ST", "Lcwt" and "Scwt" are not abbreviations that are in use in the world (Google turns up "soft coated wheaten terrier", "leaving chilled water temperature" and "low class white trash" but not hundredweights). MOSNUM advises the long and short tons be spelt out in full. So I've disabled these abbreviations. JIMp _talk·cont 03:47, 27 January 2013 (UTC)

For Fountain pen ink#Composition a conversion of 72 dyn/cm (72 × 10⁻³ N/m) Peter Horn User talk 02:38, 26 January 2013 (UTC)

try 72 dyn/cm (0.072 N/m) or 72 dyn/cm (2.9 gr_f/in). Frietjes (talk) 16:03, 26 January 2013 (UTC)