Template talk:Convert/Archive January 2018

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

ranges with ft and in

At Jack Cade's Cavern there is range of "6ft to 11ft 6in", is there a way to express this using a single {{convert}}? I wasn't able to come up with anything that didn't produce an error or a range of 6-11ft with a precision of 6 decimal places, so I went with the inelegant "{{Convert|6|ft||abbr=on}} to {{Convert|11|ft|6|in|abbr=on}}". Thryduulf (talk) 15:19, 8 January 2018 (UTC)

Here the doc says it is not possible, but maybe Johnuniq has something up their sleeve. -DePiep (talk) 16:06, 8 January 2018 (UTC)
No, I'm afraid ranges of compound units are not possible. I looked at the code a year ago and handling this would be really ugly. There is a trick that sometimes gives a reasonable result but is often unsatisfactory as in this case:
  • {{convert|1.83|to|3.5|m|ftin|abbr=on|order=flip}} → 6 ft 0 in to 11 ft 6 in (1.83 to 3.5 m)
Johnuniq (talk) 23:52, 8 January 2018 (UTC)

Targeting links

Further information: talk:Darlington railway station

Is it possible to change the way that links are produced by {{convert}}. In order to link to chains, it is also necessary to link to miles. Arguably there is no need to link to miles as it's a very common unit, whereas the chain is relatively obscure nowadays and mainly used in horseracing and on UK railways. Would it be possible to change the coding so that a link can be specified rather that the current options of none, in, out, and on. Looking to be able to code |link=chain which would then link chains but not miles in the output value. Mjroots (talk) 09:12, 13 January 2018 (UTC)

@Mjroots: Handling chains was implemented in August 2017. Examples:
  • {{convert|11800|ft|mich}} → 11,800 feet (2 mi 19 ch)
  • {{convert|11800|ft|michlk}} → 11,800 feet (2 mi 19 ch)
  • {{convert|11800|ft|michainlk}} → 11,800 feet (2 mi 19 chain)
Johnuniq (talk) 10:20, 13 January 2018 (UTC)
It doesn't work. {{convert|232|mi|50|chain|km|2|michlk}} gives 232 miles 50 chains (374.37 km)* with no link to chains. Mjroots (talk) 13:19, 13 January 2018 (UTC)
Using {{Miles-chains}}:
  • {{Miles-chains|232|mi|50|michlk|km}} → 232 miles 50 chains (232.63 miles, 374.37 km)
-DePiep (talk) 13:26, 13 January 2018 (UTC)
@Mjroots: Sorry, I gave the procedure for output. For input, use chlk or chainlk:
  • {{convert|232|mi|50|chlk|km|2}} → 232 miles 50 chains (374.37 km)
Units chlk and chainlk are the same except when abbreviated: chlk gives ch for the symbol, while chainlk gives chain. Johnuniq (talk) 23:00, 13 January 2018 (UTC)

Module version 21

Some changes to the convert modules are in the sandbox, and I intend switching the main modules to use the sandbox soon.

This release removes or flags deprecated options per discussion here. There are no other changes.

  • The module will flag option disp=5 as deprecated. Any occurences should be replaced with round=5. There are apparently no instances of disp=5 in articles (thanks Quondum). Flagging means that a large error message is shown in preview and an asterisk and tracking category appear in a saved article.
  • The following ranges will be removed. There are apparently no instances of these in articles but any occurrences should be replaced:
    • Replace & with and, for example {{convert|11|and|22|ft}}.
    • Replace to- with to(-), for example {{convert|11|to(-)|22|ft}}.
  • The following options will be removed. There are apparently no instances of these in articles but any occurrences should be replaced.
Remove Replacement
abbr=comma comma=off
abbr=mos (omit)
adj=1 (omit)
adj=flip order=flip
adj=j (omit)
adj=nocomma comma=off
comma=gaps5 comma=gaps or comma=gaps3
disp=/ disp=or
disp=2 disp=out
disp=flip5 order=flip|round=5
disp=nocomma comma=off
disp=s disp=or
disp=slash disp=or
disp=u2 disp=unit2
near=5 round=5
sortable=in sortable=on
sortable=out sortable=on

See New version (above) for rationale and to discuss.

Release notes for earlier versions are listed here. Johnuniq (talk) 00:35, 9 January 2018 (UTC)

  • The new version is now live. Johnuniq (talk) 04:12, 15 January 2018 (UTC)
Removed all their mentionings from documentation. -DePiep (talk) 09:22, 15 January 2018 (UTC)

Return part of output: input value only

Documentation #Displaying parts of the result lists options to return parts of the result, for example to return the converted value only:

{{convert|3|cuyd|m3|disp=out}} → 2.3 m3

At the moment, there is no option to return the input value only. A workaround is this:

{{convert|3|cuyd|cuyd|disp=out}} → 3.0 cu yd (note the unit repetition; example needs number tweaking)

Would it be helpful if we add this option by parameter, say |disp=in? In practical use, it would allow the editor to have the measurement rounded, spelled and formatted consistently by {{Convert}}. By theoretical interest, it would nicely complete the partial-output option list. I am not sure if these two points merit adding it. One could also note that {{Val}} does value formatting too (though I have not checked for similar behavior and for completeness wrt the Convert unit list). Thoughts? - DePiep (talk) 09:05, 13 January 2018 (UTC)

Yes, it is a missing option. I will have to do some research later to remind myself what the problem was, but I remember there was a large difficulty in implementing this. Val has its own units built-in, but if a specified unit is not found, val calls convert and uses convert's unit. Therefore, using val will always work and will usually give the same result as convert, but for some units, the built-in val definition is slightly different. Johnuniq (talk) 10:24, 13 January 2018 (UTC)
Better use |disp=input only BTW, similar to |disp=output only. (|disp=out does the same, but is less confusing in reading). - DePiep (talk) 14:27, 13 January 2018 (UTC)

On parameter and option sets in general

A well-designed template should have different selections controls being orthogonal, as well as easily understood. Currently disp ostensibly selects various parts of a complete output format; this is not perfect because it tries to control too many facets of the output. This means that every option becomes mutually exclusive (e.g. one cannot select both |disp=unit2 and |disp=table simultaneously). Adding |disp=input only might rationalize the matrix of options a little, but surely we should be properly redesigning the parameters in a top-down fashion? It should be possible to migrate over a few years to new well-designed parameters through AWB cleanup. In the long run, all of template complexity, maintenance and ease of use should improve. Any interest? —Quondum 16:31, 13 January 2018 (UTC)
Good principle indeed. This has been talked before on this page, and some changes have taken effect (e.g. |order=flip). It is up to Johnuniq wanting to spend time on this. -DePiep (talk) 18:47, 13 January 2018 (UTC)
Also, John recently asked for a more simple formatting setup, more like the "print" command (using %s etc). -DePiep (talk) 18:48, 13 January 2018 (UTC)
Interesting idea. My first reaction was that it would be too different from the existing template parameter construction, but on reflection, (a) we would need to retain support for all the complex variations in output, and (b) there is precedent for parsing parameter values as strings with a syntax, such as for units, and (c), this lends itself to the flexibility that seems to be sought. As a con, (d) the ability of the template to keep MoS-conformance would be helpful: it helps to take the load of conformant formatting off editors. I would caution against modelling such a printing directly on something like C's printf formatting. I can think of various simple syntaxes of parameters. Inclusion of arbitrary strings in the output is something that I would prefer to avoid. This approach should allow control of number of times the quantity appears, precision (fraction, round, sigfig etc.), which units to use for each (which would subsume order=flip), units display for each (symbol/name/omit). Modifiers such as sp, adj, comma, lk, sortable would remain unchanged, except that I'd recommend a minor variation of parameter values to support different numbers of outputs of the quantity (e.g. one might want to only link the middle of three displayed values). An important principle is that this should all follow a readily-understood logic. Each parameter controls one property, and each property is independent of the others. —Quondum 16:32, 14 January 2018 (UTC)
Not exactly using print.This September 2017 talk was about it. It first asked for numerous extra parameters (systematically correct or orthogonal, as you say).
I proposed something like this: each output element has a code: %v = value (number×unit), %n=number, %un unit name, %us=unit symbol (then %vn is %n %un, and %vs is %n %us), %_ is NBSP, %br is linebreak, %a=adjective, etc. All have index added, their input order. %v1 = first value, %v2 = second value (usually the calculated one) etc. Non-escaped characters are literals.
Then, the user can enter a string like: |format=%vn2%awide_[%n1%br%us1] that will produce: 12 meter-wide [39<br/>ft].
Can use a smart default system. Note that the number parameters are not included in here (yet?). -DePiep (talk) 17:04, 14 January 2018 (UTC)
Perhaps we could explore the idea of arbitrary literal strings to be inserted into the output.
{{convert}} is, first and foremost, a means of displaying a quantity converted to a new set of units. Controlling the choice of output units (system of units or specific units), precision, numeric display (separators, scientific notation), variations of display of the quantity (e.g. spell, adj, abbr, disp=unit) are all core to this; everything else (at a first glance), including displaying the input value, can in principle be done externally to the template with multiple invocations, and could be thought of as supporting convenience at a higher level. Providing such convenience should not come at the expense of fragility, such as is clearly the case with multicolumn output (disp=table), but one convenience factor stands out as "belonging": the ability to re-use the same quantity without having to re-enter it (e.g. for the default "in (out)" format, and in tables, not necessarily in adjacent columns).
Note that the format string idea is simply not powerful enough to support re-use the same quantity in every reasonable context, e.g. in two non-adjacent locations of a table or page, without having to ensure that every editor who updates the value must do so in multiple places. The format string idea also encourages editors to produce really clumsy constructs such as The cat weighed {{convert|4|kg|lb|format=%vn1 (which in the US would be %vn2)}}. We need a cleaner duplication mechanism, so that the formatting problem disappears, and all the page formatting mechanisms remain available. Surely wiki HTML supports page-local variables? —Quondum 19:54, 14 January 2018 (UTC)
Are you saying that the input value is not part of the conversion? I say that the conversion is mathematically saying "A equals B" (i.e., value in equals value out), and so input value is essential to the conversion reported (with this, what's more "everything else" left? The brackets Convert adds?) . Or maybe you want to introduce another plane of action, say page-level (so that per page, only once say the preferred formatting needs to be defined). If that's the case you advocate here, "not powerful enough" is not the right word -- it is irrelevant I'd say. But probably I am missing the introduction to that "re-use" concept you introduce. -DePiep (talk) 20:28, 14 January 2018 (UTC)
No, I'm not saying that, though I am suggesting that treating the displayed input value as just another output value would be more regular.
And no, what I want at page level is not the formatting options, but the quantities to be displayed: the result of different conversions applied to the same quantity could be displayed in different places on the page. This will require named variables, but I already see this type of functionality being supported in HTML, such as for footnotes. An example of the re-use:
Constant SI value CGS value Imperial value
c 299792458 m/s 2.99792458×1010 cm/s 983,571,060 ft/s
g 9.80665 m/s2 980.665 cm/s2 32.1740 ft/s2
"Everything else" includes variations on brackets, multiple conversions, the formatting that you are suggesting, formatting for inclusion in tables, re-ordering, conditionally suppressing display of the input, etc. —Quondum 23:26, 14 January 2018 (UTC)
re, minor clarification: "treating the displayed input value as just another output value": fully agree. What transpired in my text was this doubt: I am still struggling on how to identify the values (that's two values in default output). Numbering them as inputted 1, 2 or as outputted (which differs when one uses |disp=flip, or the solution {{Chembox}} uses in showing three temperatures C, F, K -- ask me). - DePiep (talk) 08:47, 15 January 2018 (UTC)
There are separate incompatible proposals mixed into this, which is confusing things:
  • Support of more general formatting, with multiple outputs (I do not support this as complex and fragile): any number of outputs, none of which is an input, numbered from left to right in the resulting output. disp=flip would be replaced by two outputs, the second of which is converted to the same units and precision as the input. The usual case would also be replaced by two outputs, the first of which takes its units and precision from the input.
  • Support exactly one output with no surrounding formatting, only of the displayed quantity itself. Deal with all current instances by encapsulating duplication, insertion etc. in a higher-level template. For argument's sake, give the single output template a new name (its function will be the similar to the current convert with disp=out. The current {{convert}} would change invoke it, and would provide all duplication, ordering, formatting, etc., to look just as it does now. Ideally, things like disp=table would be removed, and implemented using a completely different template or mechanism. —Quondum 13:16, 15 January 2018 (UTC)
If you'll excuse me, I don't have enough time to dive into this. -DePiep (talk) 14:21, 15 January 2018 (UTC)

German cars are limited to 250 km/h, not to "155 mph (249 km/h)"

German cars are limited to 250 km/h, not to "155 mph (249 km/h)". Please fix the template. --82.113.113.82 (talk) 18:24, 15 January 2018 (UTC)

There is nothing wrong with the template. See the FAQ. If you'd like to tell me which article you saw this in, I'd be happy to fix it. Kendall-K1 (talk) 19:57, 15 January 2018 (UTC)

Bar spoon?

Anyone know what a "bar spoon" is? It's used as a unit by the International Bartenders Association (IBA). I wouldn't care except it's used as a unit in the infoboxes of many of our cocktail articles, Tommy's Margarita for example, and I'd like to supply a conversion to standard units. If it's defined on the IBA web site I sure can't find it. We have a bar spoon article but it's no help either, giving two possible values and no source citation. Kendall-K1 (talk) 21:11, 15 January 2018 (UTC)

I imagine there is a great deal of variability regarding recipe units like bar spoon. If an official cocktail organization has a definition we might add the unit to convert, but otherwise it's just conjecture and false precision. However, sizes.com says the US teaspoon is 5 mL and the barspoon is 1⁄2 teaspoon, and is used only in mixing drinks. Convert has no teaspoon unit—we discussed that in November 2016. Johnuniq (talk) 21:49, 15 January 2018 (UTC)
I will admit to abusing this talk page a bit, as I'm not actually asking for any changes to the template. I just don't know a better way to reach the unit geeks on WP. Kendall-K1 (talk) 23:24, 15 January 2018 (UTC)
:-) -DePiep (talk) 08:42, 16 January 2018 (UTC)
Alcohol measurements#Liquor measurements shows two kinds of bartender's spoon - tea and table. --Redrose64 🌹 (talk) 10:49, 16 January 2018 (UTC)

I poured myself a double Elijah Craig last night and did some research in my modest but high quality bartending library. I have come to the conclusion that there is no such unit of measure. The IBA publishes a set of rules for their competition, and it includes a list of definitions, but bar spoon is not among them. None of the bartending scholars of the last 150 years (Thomas, Craddock, Embury, DeGroff, Regan, etc) list it as a measure. Vendors who sell bar spoons list their capacities as anywhere from 1⁄2 to 1 tsp (2.5 to 5 ml). I will chalk this up to sloppiness on IBA's part (it wouldn't be the first time). Kendall-K1 (talk) 13:26, 17 January 2018 (UTC)

Being a bartenderspoon, isn't this the personal touch ingredient of the bartender? Create your own unit (and keep it secret)! -DePiep (talk) 13:46, 17 January 2018 (UTC)

Linear density?

Would it be possible to get linear analogues of the density conversions? I have need of kg/m, and I suspect I'm not the only one. Maury Markowitz (talk) 02:24, 19 January 2018 (UTC)

Go for it. The only problem is that you should provide an output unit since convert has to make up the default and that is often unsatisfactory.
  • {{convert|12|kg/m}} → 12 kilograms per metre (24 lb/yd)
  • {{convert|12|kg/m|lb/ft}} → 12 kilograms per metre (8.1 lb/ft)
  • {{convert|12|kg/m|lb/ft|abbr=on}} → 12 kg/m (8.1 lb/ft)
Johnuniq (talk) 04:54, 19 January 2018 (UTC)
Other units of linear density, used in the textile industry, are described at units of textile measurement. --Redrose64 🌹 (talk) 17:45, 19 January 2018 (UTC)
That reminds me that convert has some built-in linear density units that I had forgotten about, see here. That includes dtex for textiles. I was operating under the assumption that the units were not defined and convert was working with mass/length. That works, even for undefined units:
  • {{convert|12|kg/m|g/mm|abbr=on}} → 12 kg/m (12 g/mm)
  • {{convert|12|oz/in|g/cm|abbr=off}} → 12 ounces per inch (130 grams per centimetre)
Johnuniq (talk) 21:50, 19 January 2018 (UTC)

Non-breaking hyphen within "convert"?

I'm using the "convert" template (which is really astonishingly useful, by the way) for a "range measurement" column within a table. I've got the output displaying on a separate line, with disp=br(). Alas, the output sometimes wraps at the hyphen. Is it possible to use a non-breaking hyphen (or similar functionality) within the "convert" template? Or is there a suggested workaround? Here's a sample of one of my table cell's contents: {{convert|13|-|22|lb|kg|abbr=on|disp=br()}}
Thanks. Timbuk-2 (talk) 01:23, 28 January 2018 (UTC)

Could you give us some live article example, please? -DePiep (talk) 01:29, 28 January 2018 (UTC)
Here's the article I'm working on: List of rabbit breeds. Thanks. Timbuk-2 (talk) 01:31, 28 January 2018 (UTC)
The output from that template (which is not currently in List of rabbit breeds btw) is:
      {{convert|13|-|22|lb|kg|abbr=on|disp=br()}}
      13–22&nbsp;lb<br />(5.9–10.0&nbsp;kg)
I am not see problematic wrapping at the article. If there is a problem, please give a way of identifying the line in question (some unique text which it contains) and say where the bad text break occurs. The output has two en dashes. Johnuniq (talk) 02:56, 28 January 2018 (UTC)
Perhaps this is not an issue with the "convert" template, but just a result of changing the screen-magnification setting. When I make my screen-display bigger, the output breaks after the hyphen. (Obviously, I can get around this by reducing the magnification.) Here is a portion of the coding in List of rabbit breeds where the "convert" template is currently in use (in the "Size" column):
Breed Name Origin Size Fur
Type		 Ear
Type		 Colors / Patterns ARBA
Recognized		 BRC
Recognized		 Image
Alaska Germany 7–9 lb
(3.2–4.1 kg)		 Short Upright Black
No
Yes
Altex USA 13 lb
(5.9 kg)		 Short Upright Pointed White
No
No
 ---
Japanese White Japan 6.6–13.2 lb
(3.0–6.0 kg)		 Short Upright Albino
No
No
 ---
I appreciate your help. Timbuk-2 (talk) 03:14, 28 January 2018 (UTC)
I'll look later but meanwhile I removed the reference notes as I don't think they are relevant here. There is no hyphen in the output. I suppose you mean it breaks after the en dash. Do you mean after "7–", or after "(3.2–", or both? Johnuniq (talk) 04:20, 28 January 2018 (UTC)
Yes, sorry: I meant to say it's breaking after the en dash (not "hyphen"). In my "Size" column, I see the break mostly after the OUTPUT's en dash (i.e., following the "3.2" in the first line of our sample here), but there's at least one instance where it ALSO breaks after the INPUT's en dash. I inserted that one instance ("Japanese White") into our sample table above (and removed the extraneous "Zenmouri" listing). If you increase the magnification of your screen, you may see (as I do) a break after BOTH en dashes in that "Japanese White" listing. (I checked for a coding error on my part in all this, but I'm not seeing one. Please let me know if I've accidentally done that.) I really appreciate your help with this. Timbuk-2 (talk) 04:51, 28 January 2018 (UTC)
Breed Name Origin Size Fur
Type		 Ear
Type		 Colors / Patterns ARBA
Recognized		 BRC
Recognized		 Image
Alaska Germany 7–9 lb
(3.2–4.1 kg)		 Short Upright Black
No
Yes
Altex USA 13 lb
(5.9 kg)		 Short Upright Pointed White
No
No
 ---
Japanese White Japan 6.6–13.2 lb
(3.0–6.0 kg)		 Short Upright Albino
No
No
 ---
The above is the first table with a nowrap style applied to the longest text in the Size column. I'll save this and test if it helps.
By the way, what is the final line in the wikitext of the table doing? It reads:
|- pactTOC8|center=yes|num=no|seealso=yes|refs=yes|nobreak=yes
Johnuniq (talk) 06:45, 28 January 2018 (UTC)
Excellent! I understand now and will put that nowrap into use. (I'll probably also code for column widths.) It's exactly what was needed—and now much of the other formatting garbage can be removed. Thank you. Thanks, also, for pointing out the line of garbage code at the bottom (which I inherited). I'll get rid of it. All of this has got me looking at some great list coding, like in the List of rivers of Albania and in a good basic model for mine: the List of dog breeds. I so appreciate your opening my eyes to better coding methods. Thanks for your patient assistance with a Wikipedian-in-training. Timbuk-2 (talk) 15:07, 28 January 2018 (UTC)
Please don't code for column widths - you cannot have any idea of what space is available on anybody else's system. Even nowrap should be used sparingly. --Redrose64 🌹 (talk) 18:55, 28 January 2018 (UTC)
Ahhh! Thank you. I very much appreciate your mentioning this. Timbuk-2 (talk) 18:59, 28 January 2018 (UTC)
That is a minority view not supported by any of our policies or guidelines. This particular table might benefit from having a width specified for the "BRC Recognized" field. Kendall-K1 (talk) 20:50, 28 January 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_January_2018&oldid=1131436876"