Template talk:Convert/Archive August 2016

Percent grade / degrees

There should be a conversion available between percent grade (used to measure roadway slopes, ski slopes, etc.) and degrees. With no conversion available, many confuse 100% grade with 90 degrees, when in fact it's only 45 degrees. Michaelmalak (talk) 13:14, 16 August 2016 (UTC)

@Michaelmalak: I'm not sure about that because if people do not understand the underlying issue they may well use convert incorrectly. For example, the source may mention a number that is not rise over fall (I assume that is the "grade" you mention), but the editor puts it in convert anyway. The problem with that is that the "official" result of a template may not be questioned, whereas an understanding of the issue would show that the numbers are bogus. At any rate, there would need to be a few examples of wikitext in articles where a convert template would be useful. Johnuniq (talk) 04:23, 17 August 2016 (UTC)

Umm, I think meant "rise over run"...is that the old aphorism? Johnuniq (talk) 08:14, 18 August 2016 (UTC)

Examples include Manitou Incline, Interstate 70 in Colorado#Vail Pass, and Indoor skiing#Alpine ski halls Michaelmalak (talk) 14:19, 18 August 2016 (UTC)

Geobox unit

I just rewrote template:unit weight to use this template. I imagine the same could be done for all the templates in Category:Geobox unit. Frietjes (talk) 17:47, 15 August 2016 (UTC)

I'm sure it could and probably should. How about moving these Geobox templates into the Geobox subtemplate space (e.g. {{Geobox/unit weight}} or {{Geobox/weight}} etc. ... better still, for this one, {{Geobox/mass}})? Jimp 01:49, 18 August 2016 (UTC)

sounds good, I moved them to subpages of {{geobox2 unit}} since that's the parent template which calls these unit templates. once the server recaches the transclusions we can find articles which are calling these directly. Frietjes (talk) 14:14, 19 August 2016 (UTC)

Slash as range separator

In multiple climate articles, there are tables of average monthly highs and lows in different locations, separated by slashes: for instance, Climate of California. At the moment, the high and low must be converted from Fahrenheit to Celsius with separate instances of {{convert}}. But if the slash were added to the list of range separators, a single instance of the template could be used. It could look something like {{convert|83|/|64|F|disp=number}} or {{convert|83|slash|64|F|disp=number}}, resulting in the text 28/18.

I don't have the necessary knowledge of Lua to do this. Would someone be willing to do this for me? — Eru·tuon 22:54, 18 August 2016 (UTC)

An extract from Climate of California follows. The table shows "Average daily high and low temperatures in various cities in California expressed in Fahrenheit and (Celsius) degrees".

City	Sep	Oct
Los Angeles	83/63 (28/17)	79/59 (26/15)

The wikitext for the Sep column is:

83/63<br>({{convert|83|F|disp = number}}/{{convert|63|F|disp = number}})

The proposed wikitext is:

83/63<br>({{convert|83|/|63|F|disp=number}})

If this is commonly needed, something can be done. However, it would be a shame to implement something that is still unsatisfactory, and the fact that the proposal requires the numbers to be duplicated is a problem. One of our residents (hi Frietjes!) could readily produce a template so the input would be as simple as something like:

{{hilow|83|63}}

Such a template might be renamed, but hopefully a short redirect could be used in articles. I think that would be a better solution. Johnuniq (talk) 04:55, 19 August 2016 (UTC)

There are quite a few pages with monthly average highs and lows in tables separated by slashes. A few other examples: Climate of New York, Climate of Texas, and the climate sections in Iowa and South Dakota. Other climate pages have highs and lows in columns (Climate of Oregon) or rows (Climate of Virginia). This is just from skimming over a few articles linked from {{ClimateUS}}. I didn't look at all the pages, so I'm not sure precisely what number of pages follows which format.

You're right, it's redundant to repeat the Fahrenheit measurements. But actually, I just discovered there's the |disp=br() option, which makes repetition unnecessary. If that parameter were combined with the hypothetical slash separator, the syntax would be much simpler: {{convert|83|/|63|disp=br()|abbr=values}}. Would that make the proposal more satisfactory? — Eru·tuon 05:38, 19 August 2016 (UTC)

I had forgotten about that feature—it makes the idea attractive so I put a test in the sandbox. Releases proceed slowly here so it will stay in the sandbox for a significant time while I ponder other items on the to do list. Meanwhile, you are welcome to use the sandbox template if wanted—they can readily be changed to the normal convert when it's ready. Example:

• {{convert/sandbox|83|/|63|F|disp=br()|abbr=values}} → 83 / 63
  (28 / 17)

Please check that it does what is wanted. Johnuniq (talk) 10:29, 19 August 2016 (UTC)

I tested it in Climate of California, and it looks fine. Neat! — Eru·tuon 17:07, 19 August 2016 (UTC)

I dislike the idea of using a slash as a separator, due to its alternate meaning as division operator. Is "3/4°C" a range or a value equal to .75? Is there some reason not to use a dash? Kendall-K1 (talk) 15:19, 19 August 2016 (UTC)

A slash is ambiguous, but it seems to be used on some weather forecast sites (for instance, weather.com); I think I've also seen it in newspapers. Other websites use a pipe (Weather Underground, Intellicast), which would be less ambiguous. I have never seen a dash used, and it would probably confuse readers. — Eru·tuon 16:51, 19 August 2016 (UTC)

Perhaps the slash should just be replaced with a pipe: 83 | 63. That would remove the ambiguity, and be consistent with the way some weather sites represent highs and lows. Though I'm not sure, it might break table syntax. — Eru·tuon 17:07, 19 August 2016 (UTC)

Do you mean to use a pipe in the output? I put that in the sandbox with this edit so you can see how it looks in Climate of California. If you prefer the slash, revert my edit to restore it. I haven't had a chance to think about the issue, and am only trying things out. Further thoughts on what should be done are welcome. Ideally a notice at a wikiproject would invite comments. Johnuniq (talk) 03:04, 20 August 2016 (UTC)

Yeah, that's what I mean. It looks like there's a problem: the daily high in Fahrenheit isn't displaying in the table in Climate of California, only the low in Fahrenheit and parenthesized high and low in Celsius. Any idea what's happening? — Eru·tuon 03:42, 20 August 2016 (UTC)

Hmmm. The strange thing is that I purged the article and I'm sure I saw that the table was rendering correctly. Convert was simply outputting a pipe (two pipes per cell) and I expected that to work because it is how the old {{!}} used to work. I made the module output | instead of pipe and purged the article again, and it is correct now. Please ask for opinions on the result at the appropriate wikiproject, and add a link to that on the talk page of the article. It's best to give others the opportunity to give an opinion before the new system is further rolled out. Also, it might be best to wait until I update the main convert modules before doing more than a couple of other articles. And, we should see what views are expressed here. @Kendall-K1: What do you think of the pipe in the output? I wonder if convert should accept ! rather than / because that would be compatible with {{!}}. Johnuniq (talk) 06:00, 20 August 2016 (UTC)

I have no objection to using vertical bar. I withdraw my suggestion to use a dash, because this is a reverse range with the smaller number second, and the second number can be negative. A dash would not be very readable, for example in "12–−5". It's not really a range so much as a pair of numbers. One question, is there any danger of the pipe looking too much like a numeral "1"? It's not a problem with my font on my screen, but could it be for others? Kendall-K1 (talk) 09:17, 20 August 2016 (UTC)

I posted at Wikipedia talk:WikiProject Meteorology, as that seems to be the one that handles climate pages. Hopefully people will respond.

I'm not liking the look of the vertical bar at the moment. Perhaps it would be better if the vertical bar were separated from the numbers by spaces: 83 | 63. But we need more opinions, and I am not a member of the WikiProject that handles this stuff. — Eru·tuon 19:35, 20 August 2016 (UTC)

Thanks for posting. It doesn't matter that you aren't a member (no one will notice), and it's likely there will be no response. The point is, however, that people have been given an opportunity to respond and that is always desirable before embarking on significant changes. I added a thin space ( ) around the pipe. What do you think of the result? Assuming the pipe is wanted, I propose that the input to convert use an exclamation mark instead of a slash (! not /)—OK? Johnuniq (talk) 01:42, 21 August 2016 (UTC)

Because / can be used as an operator as well as a separator (e.g. as here to separate two extreme values), my inclination would be not to use it where an alternative is available. The pipe with thin spaces certainly seems a good choice for output. For consistency we therefore ought not to use / as the marker for the input; many editors will be familiar with {{!}} as a means of generating |, so ! certainly seems to me to be the best choice for the input: {{convert|83|!|63|F}}. --RexxS (talk) 13:40, 21 August 2016 (UTC)

Okay, now it looks good. I think an unspaced pipe just made the two numbers undistinguishable as a block of text. The thin spaces solve the problem. I agree with you and RexxS that the exclamation point would be intuitive and makes more sense than the slash. — Eru·tuon 18:50, 21 August 2016 (UTC)

I updated the module to use "!" for the range ("/" no longer works). I also edited Climate of California to use "!". A typical convert now looks like this (I removed the extra spaces that were present because standard procedure is to omit them):

{{convert/sandbox|83|!|63|F|disp=br()|abbr=values}}

In a few days I'll look at updating the main convert modules so the "/sandbox" can be omitted. Johnuniq (talk) 03:54, 22 August 2016 (UTC)

• FWIW, I've been a professional in the field of meteorology for well over 20 years (and highly interested in the same subject for several decades before that), and I'm not sure that I've seen many instances of high & low temperatures of any kind being separated by a pipe (|) instead of a forward slash (/).

FYI, Intellicast is owned by WSI, which is owned by the same group that runs The Weather Channel and (I think) the Weather Undergound site. Guy1890 (talk) 05:19, 22 August 2016 (UTC)

Thanks but what is the bottom line? The table at Climate of California#Temperature range currently displays the high and low temperatures separated by a pipe, surrounded with thin spaces. I work on {{convert}} and have no opinion regarding what should be displayed in temperature tables, so all that is needed is a discussion (preferably at the wikiproject) that reaches a decision about these points:

• Does the wikiproject want converts like {{convert/sandbox|83|!|63|F|disp=br()|abbr=values}} as currently used in the California table?
• Or is the old procedure or something else preferred?
• If wanting to use the new system, exactly what should be displayed between the two numbers?

Johnuniq (talk) 05:47, 22 August 2016 (UTC)

I put a demonstration in my sandbox (permalink) showing how the table looks using slash and using pipe. I'm hoping those participating in the wikiproject would want to discuss what to do at Wikipedia talk:WikiProject Meteorology#Input needed, but I guess here is ok although the opinions of those of us maintaining {{convert}} should not be paramount. Johnuniq (talk) 11:05, 22 August 2016 (UTC)

As you basically pointed out above, we were asked on the WikiProject in question to comment here on this issue...hence my commentary above. I predict (without prejudice to the outcome of these discussions) that we'll be sticking with the forward slash (/). Guy1890 (talk) 20:35, 22 August 2016 (UTC)

As a meteorologist, I'm used to the slash. Additionally, the question may be why | started being an alternative. I'd think it's due to the confusion as a fraction, or perhaps spacing. But wiki pages on the slash and pipe show a) there could be some ambiguity to pipes as well b) slashes are used to connect alternatives options and separate different categories of values (such as in a date!). So though I agree more may mistake it as a fraction than see issues with |, the additional benefits it offers to readability and the confusion | could cause editing probably further balance it. I heavily support some sort of {{hilow|83|63}} template though, as it looks clean and pushes converting temperatures further. Template:Climate chart could be another good alternative to clean up input and remove any such issues? JeopardyTempest (talk) 00:14, 28 August 2016 (UTC)

Thanks, see my following post. Johnuniq (talk) 04:15, 28 August 2016 (UTC)

@Kendall-K1 and RexxS: There may not be much more input about this, but my impression is that weather people use slash, and the pipe is not totally satisfactory, even when spaced. JeopardyTempest's latest post makes me think that one of the following solutions should be used:

• Support the feature in convert using slash for the input and output. Nothing is without problems, but it does not seem likely that a table of values like 83/63 would be confusing for long, and 83 | 63 would not help much. There might also be a new template to reduce the wikitext complexity.
• Do not change anything in convert. Instead, implement a new template that calls convert twice to convert the two inputs (83 and 63). Then it would be someone else's problem regarding whether it outputs slash or pipe.

Any final thoughts? Johnuniq (talk) 04:15, 28 August 2016 (UTC)

I will defer to the WikiProject. Given Eru·tuon's original request and subsequent discussion, your first solution seems reasonable to me. Kendall-K1 (talk) 11:45, 28 August 2016 (UTC)

As the WikiProject raised the need for this, I'd give them the final word on how it's to be implemented. It seems they find the slash much more common than the pipe, so I'd defer to their preference for "Support the feature in convert using slash for the input and output". I'm guessing they find the chance of confusion with a fraction too small to worry about. Thanks for all the work you've put into this, John. --RexxS (talk) 19:48, 28 August 2016 (UTC)

I'd rather use {{Convert}} for now. If a dedicated template were created, it would be better if it had more capabilities than just converting high and low temperatures: creating a sortable table, working with precipitation as well as temperature units, setting background and text colors like {{Weather box}}. The result would look something like the tables in List of cities by sunshine duration (but with a different variable). Unless someone makes a template like that immediately, {{Convert}} will have to suffice. — Eru·tuon 23:48, 28 August 2016 (UTC)

@Erutuon: Please don't add convert/sandbox to any more articles at the moment, and please don't edit the articles where it is used (Climate of California + Climate of Alaska + Washington (state)). In about an hour I will switch convert/sandbox to use slash (/ not !) and will edit the three articles to match. When that's done, convert/sandbox can be used again, although if you wait a week or two I'll put the new stuff in the main module so just convert will work. Johnuniq (talk) 02:17, 29 August 2016 (UTC)

The above has been done and ! no longer works. Johnuniq (talk) 03:09, 29 August 2016 (UTC)

A slash seems confusing to me as it normally represents division. Why not just use an en dash? Jimp 08:16, 30 August 2016 (UTC)

The wikiproject people say the slash is standard for high/low temperature ranges so it seems better to use that rather than invent something for Wikipedia. Johnuniq (talk) 09:52, 30 August 2016 (UTC)

Alias standard units

There are common standard abbreviations that somehow got truncated in defining this template. For example cu-ft is correct, and the template forces cuft... which slows down and confuses ongoing editing. Which is why I'm here and not elsewhere finishing several edits.

• Subsequently, I'd like to see the units worked over and use wikimarkup constructs like {{{cuft|{{{cu-ft|}}}}}} ... and have this sort of short sighted problem corrected.
• One should NOT have to memorize NON-Standard abbreviations to use such a tool. It's unquestionably counterproductive and wastes people's most precious commodity--their time! // FrankB 20:04, 30 August 2016 (UTC)

The problem is the crazily large number of units (see the full list). I suspect a large number of aliases would be needed to cover all possibilities, just for the common units—what about cubft or cub ft or cu.ft. or cu. ft? If you would like to pick, say, a dozen common units and propose a list of aliases, they could be examined. Johnuniq (talk) 00:31, 31 August 2016 (UTC)

The problem is that many common abbreviations are ambiguous. I've seen m, ml, and mi used as abbreviations for the mile, and that's before we even go into the multiple different miles that exist. Rhialto (talk) 11:43, 31 August 2016 (UTC)