Template talk:ClimateCelsius

Usage
To use this template copy and paste the following code and fill in the respective values. The template should only be used in the "Understand" section, possibly under a "Climate" sub header, of a destination's guide. It's possible to leave fields blank. If a field is left blank a cell no information will appear on the finished template. If an entire set of information is left blank the row will not appear.

See the right side of the screen for an example of what the template will look like.

These are the following parameters that may be used. Any explanation of the parameter will be contained below.


 * monthhigh : This parameter is to indicate the maximum high temperature in a given month.
 * monthmean : This parameter is to indicate the mean temperature in a given month.
 * monthlow : This parameter is to indicate the minimum low temperature in a given month.
 * monthprecip : This parameter is to indicate the average amount of precipitation that falls on the destination in a given month.
 * monthsun : This parameter is to indicate the average number of sunlight hours per day in a given month
 * monthh20 : This parameter is to indicate the average temperature of a body of water in the destination during a given month. If there is more than one body of water use the temperatures for the most visited body of water.
 * description : This parameter provides a place at the bottom of the table to write a brief traveler-focused text description of the local climate. This parameter may also include a call to Template:Forecast when a forecast is available.

Usefulness and usability?
Does anyone have thoughts on the usability of this template? I, personally, think it could be very useful, but it seems like it would hard for a lot of users to use. I can fix it and am willing to make it more user friendly but it just seems like too much of a hassle to keep around. -- (WT-en) Andrew H. (Sapphire) 22:44, 30 November 2006 (EST)
 * It'd be definitely very useful to have for readers, the question is how it will be filled with information: who will be able to complete the table; are there good sources of information we can use here without copyvio-ing. --(WT-en) DenisYurkin 18:17, 1 December 2006 (EST)
 * Japanese Wikivoyage has a nicer looking version but it looks like they're filling the template with (probably) copyrighted data from the Japanese Meteorological Agency. -- (WT-en) Ricardo (Rmx) 20:05, 11 December 2006 (EST)
 * The rather ambiguous copyright notice on seems to imply that using the data is OK as long as you acknowledge the source, which seems broadly CC by-sa compatible. (WT-en) Jpatokal 23:16, 11 December 2006 (EST)


 * extremely useful, however I think it should be transposed to show monthly data in rows, so as not to dominate the section --(WT-en) Andrewconrad 21:45, 10 March 2007 (EST)

Anyone have an opinion as to whether using the high and lows for a month is alright or should we use the mean temperature? -- (WT-en) Andrew H. (Sapphire) 12:47, 17 December 2006 (EST)
 * Having travelled a bit, I have found that averages are deceiving and that it's important to know the high and low, especially in places with high standard deviations b/c it changes your luggage needs --(WT-en) Andrewconrad 21:45, 10 March 2007 (EST)

Data
Whole numbers - 21 not 21.3 - I recommend temperatures be rounded down to the nearest whole number. Travelers don't need to mess with fractions of a degree when choosing which shirt to pack. It will keep the table clean.

Only the important data. I recommend, say for city guides, including only the monthly
 * high temp average or mean
 * low temp average or mean
 * humidity average or mean
 * precipitation average or mean

Locations with extreme climates could usefully include more stuff about that in the table but in general, for mast city pages, just those basic four lines may be the most useful to the traveler. Excess data becomes noise to the reader and uses up page space. One of Wikivoyage's goals is for pages to be concise enough to print and put in your pocket.


 * I can live with the rounding down/up of figures. I think I've rounded up/down a few times, but not every single time. I don't think we should really limit the possible fields of data because they way the template is coded permits people to add whatever information they want/can and if there's no information about the average hour of sunlight a day - it's no problem, because the field simply won't display. -- (WT-en) Sapphire • (Talk) • 22:45, 23 May 2007 (EDT)

Averages & measurements
So Cincinnati is the first guide to act as a guinea pig for this template. The values I used for the temperatures were provided by NOAA since the data is public domain, but also since NOAA has been researching the climate for a while. Personal experience tells me that the figures can vary from the highs and lows given by NOAA. As an example, 90 degree (F) weather in July or August is not unheard of, but for the most part I think we should stick with averages, rather than the highest or lowest record temperature for a given month.

Also, I'm curious as to whether if a measurement of the monthly level of precipitation should be used over a number indicating the average number of rainy, snowy, or whatever days. As an ignorant American, I have a hard time comprehending millimeters, so I dislike using mm as the unit of measurement. Maybe a change from measuring precipitation in millimeters to centimeters would be wise. -- (WT-en) Andrew H. (Sapphire) 14:05, 5 January 2007 (EST)


 * Now, that I've tried converted NOAA data for Cincinnati to mm I'm convinced that the unit of measurement needs to be changed to either cm or possibly inches. Anyone have a preference? -- (WT-en) Andrew H. (Sapphire) 21:26, 5 January 2007 (EST)


 * The fine Manual of Style says thou shalt use local units of measurement, so you might need two templates.


 * Also... water temperature? That's only useful in places where people routinely swim (must have sufficient temperature at least part of the year; must have a body of water big enough to swim in; must have access to the water). Can that be made optional?


 * Max HIs and LOs are useful for deciding whether or not you are adequately packed for any weather, but the odds of getting close to an extreme are pretty low. For example, knowing that San Francisco's December limits are 35 min and 66 max tells you to skip packing long underwear or shorts. But for less mild sites, the max/mins tend to be pretty useless. -- (WT-en) Colin 22:24, 5 January 2007 (EST)


 * I disagree strongly. When high/low figures are given, they aren't the extreme high and low; they're that month's average of each day's high and low temperatures (like in a weather forecast).  Knowing that it usually gets almost down to freezing late at night and too warm for sweaters in the afternoon - or contrariwise, that the temperature never strays far from 50&deg;F around the clock (if that were the case) - is very useful information. - (WT-en) Todd VerBeek 09:15, 24 May 2007 (EDT)


 * The two template approach is an interesting idea, it's going to be a pain in the ass, but I'll nevertheless create it to address that problems. The water temperature can be made optional, but I've never attempted to hide a row in this type of table so it'll take me a while to get around to working the kinks out. -- (WT-en) Andrew H. (Sapphire) 22:57, 5 January 2007 (EST)
 * I'll also work on hiding the Highs and Lows and add an optional mean temperature field. -- (WT-en) Andrew H. (Sapphire) 23:06, 5 January 2007 (EST)


 * I felt the climate template is great (added it to South Africa), although it's size dominates a climate section. I made some structural changes to reduce the size (abreviating precipitation for instance).  In addition, the Climate Empty template setting was causing multiple cells to be generated, causing excess space on the right-hand side b/c of the cell space and padding values. Overall, I think it may make sense to transpose the table so that month data becomes rows instead of columns to reduce the overall visual domination of the data.  anyone else agree?(WT-en) Andrewconrad 21:38, 10 March 2007 (EST)


 * I don't agree with your proposal and object to it. There would be worse side effects by indicating the months in rows.  Namely, there are twelve months and switching the layout will affect the look of the section and may cause a problem with the "edit" links, which I frequently run into on de:.   Also, looking over your addition of the template to the South Africa guide I, personally, don't feel the template was too big and reverted your edits to the template, because of the weird look it was producing.  Does anyone else have any thoughts? -- (WT-en) Sapphire • (Talk) • 03:41, 12 March 2007 (EDT)
 * fair enough. I'm rather indifferent to the abreviations, so i probably should have proposed the changes before making them.  As for transposing the table, I would ask that you reconsider switching to a row based model for the months.  I understand that it might not be possible b/c of de:. edit issues, however, it would be more visually consistent with other right-handed boxes on wikivoyage to have a narrower, longer box. (WT-en) Andrew 02:10, 15 March 2007 (EDT)
 * Is it possible to have AJAX style code running on a wiki? my thought would be to have a single set of measurement data, like weather, but have some sort of toggle for different units of measurements?  I think a lot of users would find this helpful.  however, that may be to american-centric, since we the last of the dying breed of imperial system users.(WT-en) Andrew 02:10, 15 March 2007 (EDT)

Source link
I'd like to see the data source referenced right inside this template's data table, maybe after the table's title word like this: Climate, (the table's title, not the section's header) so that readers know where the table's data came from, can check it and can one-click to get further details from the data source itself if they want to. Ditto for ClimateFahrenheit template. The template could have an optional variable for this source link, maybe called "source" or "datasource", eg:

| source =

Note: template parameter values pass through wiki parser before being handed to the template. So the brackets [] go in an article page's template-parameter-value, not in the template's own markup, in order to be parsed as wiki markup as intended above. --(WT-en) Rogerhc 21:09, 23 May 2007 (EDT)


 * I'd prefer not to include this option, though, I may look at altering the template so that the Forecast template can be included (but in a sensible and UI friendly manner).


 * I don't see a benefit for referencing a data and as a rule of thumb Wikivoyage does not reference anything, because there's really no need to since we don't have an encyclopedic aim and need to reference everything stated in a guide. -- (WT-en) Sapphire • (Talk) • 22:45, 23 May 2007 (EDT)

Table cell alignment
The data table's cell alignment may benefit from style:

text-align: center;

or

text-align: right;

I tested both and might favor text-align:right if table's padding were also adjusted. Text-align:left looks pretty good, though. I'm happy with text-align:left now. --(WT-en) Rogerhc 21:29, 23 May 2007 (EDT)


 * I prefer the status quo. -- (WT-en) Sapphire • (Talk) • 22:45, 23 May 2007 (EDT)


 * Having the digits line up properly would be much easier to read. Columns of numeric data should be right-aligned (and in this case, all rounded to the nearest integer; tenths of a degree (even Celsius) is just noise). - (WT-en) Todd VerBeek 23:42, 23 May 2007 (EDT)


 * IMHO it doesn't look that much better because (I think) it's only possible to align the text of every single cell, which sucks for that first cell in each row. Let's just say don't use tenths of a degree when inputing data and I'll extend the space of the first cell so it doesn't look cluttered together. -- (WT-en) Sapphire • (Talk) • 18:51, 24 May 2007 (EDT)


 * I'd much rather see right-aligned labels in the first column than left-aligned numbers that conflict with everything I learned about data presentation as a Math minor. For that matter, I also find the right-aligned labels better looking, because the units line up vertically, and the labels are more closely connected to the data. - (WT-en) Todd VerBeek 20:02, 24 May 2007 (EDT)

Mean temperature - why?
What is the point of including the "Mean" row? The average daytime high and the average nighttime low are useful, because that tells you what range to expect and prepare for. But the overall mean tells you... what? How hot you can expect it to be sometime in mid-morning or mid-to-late-evening? Weather forecasts never bother to tell you what the mean temperature is going to be tomorrow, just the high and low, because the fact that the 24-hour mean will be about halfway between those temps should be obvious. - (WT-en) Todd VerBeek 23:39, 23 May 2007 (EDT)


 * It's just there as an option. It can be left empty and it won't display. I don't think displaying it would be horrible, though. Plus, if its the only information currently available it's better than nothing. -- (WT-en) Sapphire • (Talk) • 23:44, 23 May 2007 (EDT)


 * I think having all three data points is counter to the goal expressed in Project:Climate Expedition of keeping the facts presented simple and easy to take in. Looking at the sea of numbers when the table is fully populated, I start having flashbacks to math problems dealing with matrix multiplication. :) Can we at least specify that the mean should be filled in only if high/low data isn't available?  Another presentation suggestion: make the high numbers reddish and the low numbers bluish, so the reader doesn't have to keep track of which row is which. - (WT-en) Todd VerBeek 08:52, 24 May 2007 (EDT)


 * Meantemperature data is superfluous and a distraction from the relevant high/low data that is expected in this context. We should remove the mean-temperature parameters from the template so that people do not clutter the table by filling in this superfluous data. Colorizing high/low red/blue sounds worth experimenting with. --(WT-en) Rogerhc 13:13, 26 May 2007 (EDT)

Description
I'd really argue against any description addition, because the climate information should flow with the rest of the article. Also, writing descriptions within the "Understand" section, or better yet a "Climate" section improves the readability and UI of articles, but writing descriptions in the template take away from that. -- (WT-en) Sapphire • (Talk) • 03:25, 26 May 2007 (EDT)
 * A whole Climate section is not needed on most city articles if we locate a basic climate description text in the climate template itself. The template can then be used in a pages intro (top untitled section) or Understand section and the reader find all relevant climate info quickly in that one info box. An entire Climate section is just not wanted by readers on many city pages. It's non-relevant fluff. --(WT-en) Rogerhc 13:32, 26 May 2007 (EDT)

I encourage including a Forecast link (to a good forecast site, such as the link Sapphire has in the Template:Forecast) in the 'description' text, when available. A call to a possibly simplified Template:Forecast could be part of parameter 'description's text value as entered on a given article page. --(WT-en) Rogerhc 13:32, 26 May 2007 (EDT)