Template talk:Weather box/Archive 10

Archive 5

←

Archive 8

Archive 9

Archive 10

Proposal: make "width=auto" default

I always find it weird the amount of space taken by this table on articles. When there are lots of pictures on the right side, it also gets shifted to the bottom of the last pic, leaving a blank area above it. Both situations could be avoided if |width=auto was made into a default. Compare [1] and [2] for an example. —capmo (talk) 14:56, 14 August 2020 (UTC)

Good idea, and it looks fine on mobile too from what I can see, unlike when people put in manual width like 70%. I didnt know this option existed. are there any downsides Im not aware of? —Soap— 20:06, 14 August 2020 (UTC)

capmo & Soap. Sounds good. One question. What would happen to pages using 70% if auto was the default? I realise that a bot could remove the 70% but until that happens. CambridgeBayWeather, Uqaqtuq (talk), Huliva 19:20, 31 August 2020 (UTC)

CambridgeBayWeather, there's no need to remove a fixed percentage if it looks good on the page. Any fixed percentage will take precedence over the auto parameter. —capmo (talk) 22:45, 31 August 2020 (UTC)

You would need to check all the pages using a fixed number. I've seen it used where there was a full page width and nothing on the left. CambridgeBayWeather, Uqaqtuq (talk), Huliva 23:22, 31 August 2020 (UTC)

CambridgeBayWeather, I don't understand your concern. As already said, pages which have a fixed width number won't be affected by the change I propose above. You can check them anytime and manually change them to |width=auto if you think it looks better. —capmo (talk) 18:03, 1 September 2020 (UTC)

Never mind that. Look at User:CambridgeBayWeather/sandbox. The first is auto, the second is 70% and the third is the current default. CambridgeBayWeather, Uqaqtuq (talk), Huliva 22:20, 1 September 2020 (UTC)

New parameter ("source 3") possibly needed

Greetings! I have been doing some gardening over in Category:Pages using weather box with unknown parameters and have found a handful of pages that are using a third source in the Weather box template. I'm not overly familiar with this particular template so I'm not going to dive in and attempt to add this (at least not at this time). If anyone else is watching this template and feels the addition is warranted, you may want to do so. JPG-GR (talk) 00:26, 12 September 2020 (UTC)

Thanks for working on the category. I don't do weather but I have worked a lot on the module. I have noticed people putting multiple references in one source, and not bothering with source 2. I have no opinion on whether that is a good idea but I've seen it enough to notice, for example, at Aruba#Climate. Johnuniq (talk) 01:48, 12 September 2020 (UTC)

See the section "More than 2 sources?" above. – Jonesey95 (talk) 01:52, 12 September 2020 (UTC)

Noted. Combined all source 3 (and at least one source 4) along with source 1 and source 2 into a single source for the pages that were in the category. JPG-GR (talk) 23:44, 13 September 2020 (UTC)

Template-protected edit request on 11 July 2020

Add wind speed

|Jan wind = |Feb wind = |Mar wind = |Apr wind = |May wind = |Jun wind = |Jul wind = |Aug wind = |Sep wind = |Oct wind = |Nov wind = |Dec wind = |year wind = 96.232.40.214 (talk) 22:05, 11 July 2020 (UTC)

It's not possible to simply add things. The first step would be to make a proposal with a couple of example articles where wind speed would be appropriate, and with sources to provide information. Johnuniq (talk) 23:10, 11 July 2020 (UTC)

This person recently made another edit but its not clear to me what they changed and it seems not to have been the wind speed. —Soap— 19:16, 29 August 2020 (UTC)

This person will not be coming back any time soon. I will give a reply as best I can ....

Wind speed is kind of a neglected area, .... it may have something to do with it needing more than just a number to be meaningful ... for a lot of places, knowing the wind direction is as valuable as knowing the wind speed. Another possibility is that wind speed tends not to change much from one month to the next, and that it is more subject to the influence of microclimates than other recorded quantities. I think it may be best to treat wind speed outside the template. —Soap— 21:14, 28 September 2020 (UTC)

Preferred Units

Should Wikipedia standardize the preferred units of measurement in the Climate box? As an American that uses the metric system, I haven't found much trouble with either arrangement, the primary unit displayed being either/or, but I would find it much more consistent for us to decide upon a singular preference. For example: If you go to read the climate box in the Wikipedia article for The Bahamas, the primary unit is in degrees Celsius. However, if you go read the climate box for any U.S. city for instance, the primary unit is in degrees Fahrenheit. If it is at all plausible, I would submit to editors that Wikipedia should run in accordance with the most commonly used unit internationally and the definitive academic and scientific system, the metric system. It is also the United States' officially preferred measurement system in accordance with the Metric Conversion Act of 1975 wherein the U. S. declared the metric system to be the preferred system of measurement in the country. Smartie988 (talk) 02:16, 6 November 2020 (UTC)

How to spell color/colour and what units to use are among Wikipedia's perennial arguments. Spelling and units are resolved by the manual of style. WP:UNITS makes it clear that °F will be first in US topics. Trying to change that would be a waste of time as people are tired of arguing about that point, but the place to start would be at the talk of WP:UNITS. Johnuniq (talk) 04:28, 6 November 2020 (UTC)

Update

Just to be clear, Im not proposing any action on either point here .... Im not going to do anything myself, because ...it's a volunteer project, the weatherbox template is a whole lot of work already, and these issues havent been big issues before. But nonetheless:

1) the 1991-2020 climate data was released almost immediately after the beginning of the new year, to the surprise of many who were expecting a months-long delay. In theory we could start replacing 1981-2010 climate data with 1991-2020 climate data. I certainly wont stop anyone who wants to, but as above, we got along just fine with slightly older data throughout the entire last decade, and climate doesnt really change that much even with global warming ramping up, so I'm just dropping this here as a reminder.

2) The notorious WeatherBase has been down for a few days now, and there's a possibility it won't come back. If it does come back, there's a good possibility that they're just revamping the site and it will come back with a UI that is great for casual users but which breaks literally every single link we have. I certainly dont expect anyone to show up and volunteer to fix 4000 links to a site that would just as likely change its UI yet again a few years later, but again, I'm just letting you all know.

Personally, I wouldn't mind if Weatherbase never came back. They're so notorious for being wrong that I'd seriously entertained asking them to be put on the blacklist, but held back because I figured a lot of people, even longstanding Wikipedia users, would not know the difference between a reliable source of climate data and an unreliable one that happens to be right some of the time.

I put in a lot of work over the past year or so, but I've grown tired of this, and as such I have to repeat yet again that I don't expect anyone else to hop to work and start editing hundreds to thousands of climate data charts. But let me know if anyone has questions.

Best regards,

—Soap— 19:41, 18 January 2021 (UTC)

Snow depth in the Weatherbox

Hello, can anyone help me introducing "max snow depth cm" and "max snow depth inch" in these weatherbox templates so that it is editable? That is usually how snow is measured in the Nordic countries, contrasted with the totals preferred in North America, hence most Nordic locations lack snowfall data at all in the weatherboxes. I would greatly appreciate help with this. Glottran (talk) 11:10, 7 February 2021 (UTC)

Can you clarify a bit. Are you saying that Nordic countries do not separate snow and rain and just measure precipitation? Now for maximum snow depth do you mean "Extreme Snow Depth", "Extreme Daily Snowfall", "Snow Depth at Month-end" or possibly "Median Snow Depth" or "Average Snow Depth". I don't know where to search for them on a Nordic location (and possibly a European location as I see London does not separate the snow) so if you look at this and click on the "Normals Data" and scroll down you can see what I mean. CambridgeBayWeather, Uqaqtuq (talk), Huliva 10:18, 9 February 2021 (UTC)

@CambridgeBayWeather:

Yes, they just measure precipitation and snow depth. Here is a Swedish-language example. In the upper right column you will see "largest snow depth cm" (Swedish: största snödjupet cm). Meanwhile, there is nothing in there about the snowfall, just the depth and the overall precipitation. That is why I think it would be great to have these as options. As for what I desire for this box I mean "Extreme Snow Depth cm/inch" since that is usually what it measured in the Nordic countries and those averages best describe how the snow sticks around, not just how much of it falls. I would be very grateful if this was added to the possible charts with the same colour codes as snow so that Nordic locations also could get some snow data in weatherboxes.

Glottran (talk) 22:20, 9 February 2021 (UTC)

OK. Unfortunately the days when I could edit the template are long gone. It will require someone else to do it but I think it a good idea. CambridgeBayWeather, Uqaqtuq (talk), Huliva 09:34, 10 February 2021 (UTC)

References

@CambridgeBayWeather:

Is there anyone in particular you can think of who can edit the template and I can ask on their talk page whether they could assist in this task? Glottran (talk) 15:03, 10 February 2021 (UTC)

Not really. Soap above did but they got tired of it. You could look through the history of the page and see. CambridgeBayWeather, Uqaqtuq (talk), Huliva 13:02, 11 February 2021 (UTC)

@CambridgeBayWeather: I tried to edit the sandbox but it just came back as "unknown parameter" when I tried to add "max snow depth inch/cm" for the respective columns. What did I do wrong which made it not work as far as you know? I'd like to be able to fix it myself, but the site throws me serious hurdles by the looks of it! Glottran (talk) 13:53, 14 February 2021 (UTC)

You can't edit it here any longer. It has to be edited at Module:Weather box. You could ask Johnuniq, Huntster, Hike395 or Jonesey95. CambridgeBayWeather, Uqaqtuq (talk), Huliva 10:38, 15 February 2021 (UTC)

Glottran, would the year end figure be a sum or average of the monthly figures? I can try to make this work, but module code makes my head spin, lol. — Huntster (t @ c) 15:36, 15 February 2021 (UTC)

Huntster, the default would be the highest monthly tally. In effect, if February has 67 cm and no other month surpasses it: then it's 67 cm for the whole year. Then obviously as with avg record high/low the annual tally can be higher than this because different months may record higher snow depths in various years. For example, if January or March have deeper snow covers in two years of a series when it usually is February: the average snow depth in a year will increase somewhat. Either way, think of it as a record high column. I really hope it can be made to work out and cheers for making the effort. Good luck!Glottran (talk) 16:37, 15 February 2021 (UTC)

Glottran, so the basic code is now in the sandbox as seen below, but I honestly cannot figure out why the colours are responding the way they are. Johnuniq, would you mind terribly looking at what I did wrong? Note that I did intentionally use the humidity colour scheme as a test rather than make something entirely new, since they have a somewhat similar number range, but the way it is displaying below makes no sense to me. — Huntster (t @ c) 19:35, 15 February 2021 (UTC)

Climate data for Test
Month	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec	Year
Average extreme snow depth cm (inches)	0 (0)	10 (3.9)	20 (7.9)	30 (12)	40 (16)	50 (20)	60 (24)	70 (28)	80 (31)	90 (35)	100 (39)	110 (43)	110 (43)
Source: Test as of 2021-02-16 13:37Z

It seems that it's multiplying the measurements by ten. Or maybe we're dividing the humidity measurements by ten and we just didn't notice. I played around with previews, and it seems that e.g. 5 cm is equivalent to a humidity measurement of 50%, 10cm is equivalent to 100%, 14cm is equivalent to 140% humidity, and so on .... and yes, our humidity scale runs up to 140%.... perhaps we decided we just didnt want to have the darkest blues surface in real-world measurements so we intentionally undershot the limit when we set it up. That'd be my guess, anyway .... lurking somewhere in the code is a multiplier that just isn't in the place where we're looking for it, and if we can find it, we can get it to work properly for the snow depth too. or, just change "scale factor" maybe. —Soap— 19:49, 15 February 2021 (UTC)

Huntster, Soap Wouldn't it be possible to use the exact measurement scales for the snowfall proper? Considering it is "same, same, but different" in that a frozen climate receiving x amounts of snowfall will likely have a similar snow depth, at least for the first few weeks. It might be hard to fix but definitely a possible solution from my point of view. Glottran (talk) 21:19, 15 February 2021 (UTC)

Oh, yes, I imagine that copying and customising the regular snowfall colours would work better. I just have no idea how to change the colour scaling to work with this depth range (which, btw, is a good question: what would be considered an appropriate upper bounds?). The above mockup just uses humidity as a placeholder since I thought it would use a similar scale. Perhaps I over-emphasised the humidity-as-colour issue, that wasn't my intent. — Huntster (t @ c) 21:29, 15 February 2021 (UTC)

Huntster it definitely needs to be a bit higher than the current colours for sure. Right now my location has about 20 cm of snow on the ground and it is by no means extreme. Shouldn't it be possible to basically just copy and paste the snow codes without changing anything? Life is rarely that simple though... Glottran (talk) 21:53, 15 February 2021 (UTC)

This is now with snow. Slightly better, but still no dice. — Huntster (t @ c) 00:13, 16 February 2021 (UTC)

It looks like it's lined up with the way the snow normally behaves .... e.g. at Sapporo#Climate you can see the same colors for the same values .... but the way it was earlier suggests we can scale it down without changing the values. Would the scale_factor variable work for us here? Maybe to half or a quarter of what the numbers would normally merit? —Soap— 00:18, 16 February 2021 (UTC)

Soap, you're so smart. Set scale to 0.4, and you can see result above. Glottran, what would you suggest would be the most realistic maximum value the colour should account for? — Huntster (t @ c) 00:33, 16 February 2021 (UTC)

Is the sandbox now working as wanted? I'll have a look but my initial check has hit a wall due to #Proposal: make "single line" default above. As noted there, I made a lot of changes for that and I would want to know if it is wanted and what I should do about those changes. Johnuniq (talk) 03:00, 16 February 2021 (UTC)

Johnuniq, I fully intended to revert to your last version of the sandbox once this particular change was finished. As for 'single line', I honestly don't know anything about the issue, but it seems logical for the vast majority use case to be the default behaviour? — Huntster (t @ c) 03:23, 16 February 2021 (UTC)

@Huntster: Are the above results (produced by {{Weather box/sandbox}}) correct? That is, is anything further wanted? I'm lost wondering about side issues, for example "multiplying the measurements by ten" above. The module multiplies by ten to get the color for a cm value (but does not multiply by ten for a mm value). Actually, I would need to study the code more to be confident about what I'm saying due to long-time-no-see, but the factor of ten is related to cm/mm. That got me wondering what happens if some values are cm and some are mm—a quick test shows the result is very confused, groan. If snow depth is working as wanted, I would like to take a couple of days to remind myself whether the single-line issue was finished and if the code looks good. In that case, we could release both the new snow depth and default-single-line at the same time. Do people want the default to be single line? Johnuniq (talk) 04:26, 16 February 2021 (UTC)

Johnuniq, I'm just waiting for feedback to see what the upper bounds should realistically be so I can tweak the scale appropriately. The "multiplying measurements" thing came from a misunderstanding that I was wanting to actually use the humidity colours for the final product, when that was just a placeholder. I'm satisfied that snow gets us where we want, I just need to dial in the colour values now. If you wanted to merge in the snow depth code with your previous version of the sandbox, that's a-okay by me. Single-line default has my !vote, for what it's worth. — Huntster (t @ c) 04:46, 16 February 2021 (UTC)

Huntster In March 2020, Katterjåkk in Riksgränsen, Swedish Lapland had a snow depth of 229 cm. As far as I understand it though it is just going to be the darkest shade from a certain point and that is what the question is about? If so, I'd suggest 100 cm. If the question instead is for how much snow depth is possible as a max value in the weatherbox proper, I'd go with 400-500 cm to account for some variability from the 229 cm Katterjåkk measurement. Hopefully I've sufficiently answered the question and I'm very grateful for your efforts! Glottran (talk) 07:43, 16 February 2021 (UTC)

References

Glottran, I was thinking more about what average numbers might be, rather than absolute maximums. I fear if we used 200, then there would be hardly any colour variability in most typical scenarios. Hmm.

Addendum, above test is with a scale of 0.2. I think it looks pretty reasonable. Thoughts? — Huntster (t @ c) 14:13, 16 February 2021 (UTC)

Huntster I do understand your point. I really like the example you have made above and am fine with it though. We can go with a number beneath 200 it is fine by me, considering those locations are fundamentally outliers. For example, here we have -2°C means in winter and I'd say the peak snow cover is about 20 cm on average so the scale above may well be appropriate for most locations so it has my seal of approval. Glottran (talk) 17:10, 16 February 2021 (UTC)

Johnuniq, I suppose that answers the question :) We're ready to deploy whenever you are. Thank you Glottran. — Huntster (t @ c) 23:41, 16 February 2021 (UTC)

@Huntster: Please go ahead and deploy your code now (don't wait for me). There are "only" 20,000 transclusions of weather_box so there is no strong reason to wait. I found my notes from June 2020 and the situation is a bit of a mess. I think my changes are good but then I started investigating what articles actually contain and what the effect of a change would be. That is pretty unclear and I'll take more time thinking about it. FWIW I looked at your changes and they seem good! Johnuniq (talk) 03:06, 17 February 2021 (UTC)

 Done Changes deployed, sandbox reset. Thanks everyone! :) — Huntster (t @ c) 16:18, 17 February 2021 (UTC)

@Huntster: Massive thank you for your efforts! I can't find any star among symbols, but otherwise you'd gotten five of them! One crucial thing though: could you please do me a favour and maybe change the weatherbox title from the current one to "Average extreme snow depth"? This is because just as it is worded right now is a bit too ambigious. Might be an idea to keep it ambigious on purpose, but the reader might misunderstand it... also the text could easily be a bit too long if we change it so might be best to keep it as it is? Glottran (talk) 17:25, 17 February 2021 (UTC)

 Done, Glottran. It's a little on the long side, but not unreasonably so. The words will wrap if needed, so no problem. — Huntster (t @ c) 19:19, 17 February 2021 (UTC)

Huntster, thanks again! I think "extreme" could in theory be "peak" also since we're talking about how high it gets, which would save three letters but granted that's not much. In the end it's basically less than one word shorter than the afternoon humidity text for example so it's not all that bad. Once again, great job and much appreciated! Glottran (talk) 21:49, 17 February 2021 (UTC)

Template-protected edit request on 12 April 2021

Please apply the following changes to the module diff. These changes make sure that the latest version of collapsible content is used and the JS is loaded automatically, instead of asynchronously after page load, which is more efficient. —TheDJ (talk • contribs) 12:57, 12 April 2021 (UTC)

To editor TheDJ:  done, and thank you very much! P.I. Ellsworth  ed. ^put'r there 18:49, 12 April 2021 (UTC)

Check/update documentation

I updated the template documentation. I changed the first example to use default settings, the |collapsed=yes and |open=yes settings are confusing if not contrary. I added a second example to demonstrate two of the most dramatic parameters. I updated the documentation about |width=. My guess is there are other updates needed. I do not have the knowledge or inclination to do them. PS: I think |width=auto should be the default simply to make a weather box more like wikitable. User-duck (talk) 12:57, 20 May 2021 (UTC)

Edit request: Sorting of rows

Currently metric and imperial units are clubbed together. That causes confusion, esp with colour coding. So respective rows of imperial and metric can be clubbed. That will make colours match of adjacent rows, and will look similar to "single line = Yes" parameter, but without brackets and with separate rows. Currently in Attigundi article, the order is high C, low C, rainfall mm and then high F, low F and rainfall inches. Instead this order will become high C, high F, low C, low F, rainfall mm, rainfall inches after the edit (Compared to single line version). That will make colours of adjacent rows match, and will become easy to read too. Crashed greek (talk) 07:44, 25 August 2021 (UTC)

Colours will match like it is already there in "Average dew point °F" and "Average dew point °C" rows of the existing template. Crashed greek (talk) 07:50, 25 August 2021 (UTC)

I disabled the edit request because it is only for use with precise instructions regarding exactly what changes are required, and should only be used after a discussion has established that the change has consensus. The current design is that you can either have imperial/metric units together in the one row, or you can have all imperial units in one section and all metric units in another. The proposal is that imperial and metric rows are interleaved. I haven't seen that idea before. Let's see if it has any support. Johnuniq (talk) 09:38, 25 August 2021 (UTC)

Could you explain how the current setup is confusing? —Soap— 19:47, 25 August 2021 (UTC)

Crashed greek I removed the hidden comment bit. But I see no point having separate lines for C and F. CambridgeBayWeather, Uqaqtuq (talk), Huliva 00:05, 28 August 2021 (UTC)

I didn't get what you removed. Colours get jumbled up and and look confusing if the rows are clubbed for data unit instead of data type. Crashed greek (talk) 04:52, 30 August 2021 (UTC)

Some variables that might be missing

Just writing this because I believe that the Weather Box is lacking some important variables. All of these values are used both by the Portuguese and the Spanish Meteorological Institutes. I do not know for certain if other Meteorological Agencies use them, if they don't then I guess it wouldn't make much sense to use them in the first place.

• Record daily precipitation: Very important when distinguishing torrential from continuous rain. A great indicator of flash flood intensity/occurrence. Ex: Phoenix, Arizona has a higher daily precipitation record than a lot of other places in Europe which have 4x the annual average precipitation of Phoenix.

• Wind speed: This might not be as much as important as it depends largely on the placement of the station (agricultural field vs city centre), but I find it rather important for apparent temperature (similarly to humidity). It also takes out space if one decides to make a table just for wind speed. And might I add highest wind speed (wind gust record)

• Days of thunderstorm: May be related to record daily precipitation but nevertheless useful. Ex: While the Mediterranean bordering Barcelona has around 20 days per year of thunderstorms (with most of them occurring in the summertime), Lisbon, bordering the Atlantic, has only 8 (with most of them occurring in the wintertime)

Other variables IPMA and AEMET use include:

• Foggy days: Places located next to cool water masses tend to have a higher occurrence of fogs. (Look up San Francisco fog)

• Days of frost

• Days of graupel

Interested in hearing your thoughts on what is essential and what is not. Average Portuguese Joe (talk) 19:27, 11 September 2021 (UTC)

Alright this is going to sound more negative than I intend it to .... please understand that I'm just in a bit of a rush but I would rather say something, even if it comes off a bit rough-sounding, rather than saying nothing at all.

Wind speed tends not to vary a whole lot month to month, and as you said, it also varies a lot from place to place even within a very small area. We have it on Cabo da Roca because that is a place known for its exceptionally high wind speeds, but even there it doesn't change much from one month to the next. I think it's best to keep it as a separate table; it may also help us, if we can find stations that record it, to add the mean wind direction to the table.

Record daily precipitation and record wind gust are great ideas, but I still wouldnt put them into the weather box as they are not month-to-month variables, so there would be no clear place to put them.

Days of thunderstorm is another variable that wouldnt really fit in the weatherbox, unless there are stations that track that month-to-month .... in the US I've only seen it as a yearly variable.

Days of fog .... I dont know ... how do we define that? Is it fog at any time of the day, or fog that lasts through noon, or fog that lasts the entire day? I would want to make sure we are all graphing the same thing before we add that.

Frost is tracked in the USA inasmuch as we can say that's equivalent to days below 32°F .... we could add that, I suppose. I wonder if graupel is simply more common in Europe than anywhere else and that's why you track it but the USA does not.

Thanks for your input, and again Im sorry I just basically say "no, no, no, no, maybe, no" ... I'm not the one doing the coding, so I'm not going to stand up and get in your way if we as a community decide to implement your ideas. —Soap— 20:19, 11 September 2021 (UTC)

I do get your point. And you might just have changed some of my initial thoughts. I was still rooting for "thunderstorm days"; though, on further analysis, I am not 100% secure if this variable is trustable. Some of these values change a lot even through different stations of a city (2 stations in Porto differ from 4.2 days to 18.7 days in 6 km (3.7 mi)...), even if correct it can't really define the whole city. On another note: "Days of fog", as it is labelled, is most probably "Entire days with fog" which is much different than what I initially thought. Well, thank you for your response and your time, much appreciated. Average Portuguese Joe (talk) 22:11, 11 September 2021 (UTC)

Desert Research Institute

As the Desert Research Institute changes its website around, it's possible that thousands of links we have to their site in our climate boxes will irreparably break. Ive seen their new website, and as it stands right now, I am, to put it quite generously, not impressed. I'll let others who are interested take it upon themselves to see what got me upset, rather than drag it out here, but it's important because if their website remains the way it is at present it will simply not be possible for us to use them as a resource in the future, and the existing links will be forever broken. —Soap— 23:01, 26 October 2021 (UTC)

"Average" temperature rows description tooltips?

It would be nice if the averages would state that they are in fact averages of the corresponding daily temperatures on mouseover to resolve possible confusion w/o shifting the data columns. L29Ah (talk) 20:26, 8 November 2021 (UTC)

Template-protected edit request on 4 December 2021

Recommended change: "Mean monthly sunshine hours" to "Mean sunshine hours". Reason: In this example and in the sampling of transcluding articles I looked at, the data being given are, for the months, the monthly mean totals and, for the year, the annual mean total. This usage (monthly for months, annual for the year) is comparable to the usage of entries such as "Average snowfall" and "Average rainy days", and those entries lack the erroneous "monthly" in their titles. Largoplazo (talk) 23:40, 4 December 2021 (UTC)

Something like this needs discussion before an edit request. I have done some technical work implementing this template but have no opinion on whether this change would be desirable. I think we should allow a few days to pass for those who understand the topic to comment. Johnuniq (talk) 00:05, 5 December 2021 (UTC)

My concern would be the potential confusion this may cause. Countries either report sunshine hours as the total amounts of hours in a typical month which is the one the World Meteorological Organization prefers per https://library.wmo.int/doc_num.php?explnum_id=4166 (e.g. 230 hrs of sunshine in July) or a daily average (e.g. 7.8 hr of sunshine/day in July). Having the monthly ensures clarity that the data is being to referred as the total amount of hours of sunshine in a typical month (mean monthly sunshine hours, which is the official definition by WMO per https://library.wmo.int/doc_num.php?explnum_id=4166) and not erroneousely the daily sunshine hours. For example, the Austrlian Bureau of Meteorology uses "Mean daily sunshine hours" to indicate to readers that it is a daily average, not a total amount in a month so that editors don't erroneouely input daily amounts in the monthly field and vice versa. Ssbbplayer (talk) 02:09, 2 January 2022 (UTC)

Removing "monthly" is not the right way of going about this - how would you distinguish between the monthly and daily numbers? We should probably either change the behaviour of the Year column to show the average of all the months like it is for the "Mean daily sunshine hours" row or add some sort of tooltip/note with underline on the "Year" number to tell that it is the total. PS: I got here because I was looking at the Delhi article and thought that the value given for the Year column was an error and was looking for a way to fix it. -Ujwal.Xankill3r (talk) 04:27, 2 January 2022 (UTC)

Error with units of inches and January precipitation or rainfall of a trace

I came across an error when I tried to make a weather box with |Jan precipitation inch = trace. It is a Lua error that can be traced back to Module:Weather box. The same error happens when |Jan rain inch = trace, but not for snowfall. In the rare case this happens, it can be fixed by changing the january value to |Jan precipitation mm = trace or |Jan rain mm = trace. The weather box will appear the same to the viewer and the yearly totals are unchanged. Here is a permalink to some examples in my sandbox. [3]. The lines of code in the module are

203: prefer_cm = precision(_ifset('Jan precipitation inch', '0')) < 1,

214: prefer_cm = precision(_ifset('Jan rain inch', '0')) < 1, Crunch41 (talk) 17:27, 5 February 2022 (UTC)

Thanks for reporting this. I edited the module to work around the problem. A more thorough fix would be to guess the precision by inspecting all columns rather than just January, however that doesn't seem worth the effort. Unfortunately I did a lot of work on the module as preparation for switching it to use a default of 'single line' which a discussion seemed to be supporting. I don't remember the outcome but I think it fizzled out with the result that some local notes I have are competely different from the current modules. I see also that the main and sandbox results in Template:Weather box/testcases look very different and again that would need some detailed investigation. Johnuniq (talk) 23:12, 5 February 2022 (UTC)

If I ever do more work on the module I will have to resolve the issue of whether "single line" should be the default so I'll record that the initial discussion was here. Johnuniq (talk) 23:01, 11 February 2022 (UTC)

Data

Has there been any discussion about migrating the data for this template into Wikidata? Currently the template adds a lot of bumf into the wikicode. It would be nice just to type {{Weather box}}. — Martin (MSGJ · talk) 10:53, 11 February 2022 (UTC)

Looking into this a bit further, I think Commons Tabular Data might be more suitable than wikidata. — Martin (MSGJ · talk) 12:45, 11 February 2022 (UTC)

There has been no discussion on that. I wouldn't recommend Wikidata as I don't see how it would work there, with the table of data for a particular location being split into more than 50 entries, and a permanent difficulty of watching for bad changes. An example of tabular data is c:Data:Wikipedia statistics/data.tab which is used by Module:NUMBEROF. The problem is that editing the table of data is very difficult—that example is created by a bot which uses the API to get the raw data, then writes in the required JSON format. For weather boxes, there would need to be a home-grown method of having a page where data could be edited, then some magic code would transform it to the format required for tabular data at Commons. Johnuniq (talk) 23:15, 11 February 2022 (UTC)

How often does this data need to be edited typically? — Martin (MSGJ · talk) 22:49, 16 February 2022 (UTC)

Even creating the initial table is not something that should be done manually (try clicking 'edit' on my above example link). There would need to be a page somewhere with the data entered in a convenient manner (convenient for a person to enter/edit, and convenient for a module or bot to parse). When changed, a program would be used to translate the table to JSON which could then be pasted at Commons. I'm not trying to oppose the idea, and if you want to experiment I would be happy to have a look and add my thoughts. I just think it would be tricky. Johnuniq (talk) 00:56, 17 February 2022 (UTC)

Consistency of Weather Box parameters

Recently I've noticed some Weather Boxes have data that does not coincide with the actual parameter. The editor in question has been using the "mean minimum" and "mean maximum" parameters for the "record low/high MEAN DAILY TEMPERATURE recorded in the month" instead of the "average monthly absolute minimum/maximum temperature" as per definition. From what I've noticed, he did this in the Málaga and Seville articles. Still, after I warned him about it, he persists on keeping it. I mean, there should be some consistency with parameters, right? Average Portuguese Joe (talk) 00:04, 4 February 2022 (UTC)

All I can say is that this may be due to the confusion we're seeing below, and of Spanish-speaking countries piloting the collection of "mean maximum" data such that people in the United States and really anywhere that speaks English dont know what it means. —Soap— 21:34, 15 June 2022 (UTC)

Requesting comment regarding climate sections in town articles

Hello all- Linking to a post I just made on the Weather project talkpage: Wikipedia_talk:WikiProject_Weather#Climate_sections_in_articles_on_individual_towns. Please let me know if there's a better venue for posing my question. Thanks in advance. Eric ^talk 16:25, 20 June 2022 (UTC)

Should be collapsed by default

This template is a real eyesore, especially in short articles where it completely overwhelms the visual experience. It is extremely unlikely that more than a tiny fraction of readers visit an article on a location for the purpose of getting climate information. So please, oh please, make it collapsed by default. Zero^talk 05:13, 30 June 2022 (UTC)

Agree. Did you see the discussion linked two sections up from here? Eric ^talk 11:45, 30 June 2022 (UTC)

Thanks, I wasn't aware of that. Zero^talk 12:03, 30 June 2022 (UTC)

MOS:DONTHIDE. – Jonesey95 (talk) 17:25, 30 June 2022 (UTC)

I guess the authors of that had not seen how butt ugly this template is. Frankly, if it isn't allowed to be collapsed by default, it should be omitted by default. Zero^talk 03:05, 1 July 2022 (UTC)

I have to say I sharply disagree with Zero0000's aesthetic judgment. I think the template enhances the visual experience, and moreover provides some of the key information that readers are likely to be looking for in geographic articles. --Trovatore (talk) 06:36, 1 July 2022 (UTC)

It's hard for me to imagine more than a minuscule fraction of readers finding the data in these tables relevant or useful in the context of an article on an individual town, especially when it's a tiny article on a little hamlet in which a data table accounts for the majority of the page area. I suspect that many implementations of tables such as this and historical population ones are made merely because the template exists and the editor finds it nifty. They almost always jump out at me as ungainly fluff. I think it would make much more sense to simply link to the data source, maybe from within a standard infobox, so that interested readers could easily consult up-to-date records at the source. Eric ^talk 11:46, 1 July 2022 (UTC)

One problem is that the data may be very difficult to read, even with a URL. There is no other website that does what we do. There are sites like WeatherBase, but they are profit-making entities who have little interest in presenting accurate data .... I can demonstrate this if need be.

Meanwhile, government websites typically have accurate data, but often not in a user-friendly form and there may be a language barrier. The same applies to universities like the Desert Research Institute that I complained about up above. For example, neither NOAA nor the Desert Research Institute have URL's linking directly to their data, so any user seeking information would need to spend time going through the UI to get the data to load. This would be quite a waste of our readers' time.

It takes a lot of work for people to type up these climate tables, and especially to keep updating them as the climates subtly change from one decade to the next. I have the highest level of respect for anyone who works in this area of Wikipedia. I also think that the climate tables are in fact used by our readers. Also, when a weather station happens to be located in a small town, for example Sutton, Vermont with just 1,000 people, I'd think that that weather station would be a major landmark in that town, and that we are not giving undue attention. —Soap— 21:30, 2 July 2022 (UTC)

What bothers me most is not the data but the loud and gaudy colors. It is a perfect example of bad web design. Zero^talk 09:47, 4 July 2022 (UTC)

One problem of making a link to the source is things like Template:Winnipeg weatherbox. That weatherbox has four sources and Template:Halifax weatherbox has 16. Wikipedia presents the information in a way that is not available through one single link. Climate changes before the 30 year period is up and the new data is released and the 1991 - 2020 data is not yet released but our tables contain updated information. The main link for Halifax and Winnipeg doesn't contain the most up to date information and the other links are required. The colour scheme has long been a point of contention. Take a look in the archives. CambridgeBayWeather, Uqaqtuq (talk), Huliva 09:52, 4 July 2022 (UTC)

Can we please, please, add width=auto by default

So the template is getting used on so many pages now where the default are causing huge whitespace issues. There's been several discussions about it before and I'm not sure why, but can we please implement "|width=auto""|width=auto" by default. It looks much better on most screens, can easily be overridden if absolutely necessary and it avoids so many headaches. Canterbury Tail talk 19:04, 29 June 2022 (UTC)

Agree. It does seem like this should have been implemented from the outset. Eric ^talk 19:09, 29 June 2022 (UTC)

The parameter |single line= has a bug in that values blank, Y and N produce three different results, and N gives a broken result. There was a June 2020 discussion to fix that, and to make Y the default. I did a large amount of work on that with some local files ready to update the module, but for some reason it never got implemented. The point of this comment is that I would want to update the module with that change at the same time as including the default |width=auto which apparently is this diff. Do you know if that diff is what is needed? Is there any problem with making single line the default at the same time? Johnuniq (talk) 04:51, 30 June 2022 (UTC)

Honestly I have no idea, the coding of templates such as these are beyond my understanding. I can manage them once they're in articles and converted into standard markup, but in the raw template format and module edit I've no idea. Canterbury Tail talk 12:08, 30 June 2022 (UTC)

I thought you might have known from an earlier discussion that those edits were what was wanted. I had a closer look and they seem good so I incorporated them in a major clean-up which I just implemented. That is, width=auto is now the default. Please check a few articles and report any problems. The single line bug I mentioned just above is fixed. Johnuniq (talk) 11:05, 1 July 2022 (UTC)

I'm opposed to this. It needed a wider discussion. Changing thousands of articles based on three people is not a valid consensus. Auto produces smaller boxes, Geography and climate of Winnipeg but only on the desktop. CambridgeBayWeather, Uqaqtuq (talk), Huliva 09:30, 4 July 2022 (UTC)

I agree but it's hard to get more discussion on this page without concrete action. I don't have a particular feeling about the change; I wanted to update the module with some major refactoring I did some time ago. I checked the width=auto code and the results and they seemed good so I included it. Particularly on a wide screen with a wide browser window, the default table was far too big before this change. What is the problem? I think you're saying that having two width=auto weather boxes (as at Geography and climate of Winnipeg#Climate) gives two different table widths because the tables have different column widths. @Canterbury Tail and Eric: Any thoughts? Why is width=auto desirable? Can you point to a couple of articles where not having that was a problem? Johnuniq (talk) 10:31, 4 July 2022 (UTC)

Chesterfield Inlet, Nunavut (which was already using the width=auto) and User:CambridgeBayWeather/sandbox shows what the 100% looks like, which is bad. But now there are thousands like Clyde River, Nunavut with large amounts of white space to the right. Part of the problem is that auto does not work the way you would expect it. The discussion on making it the default should have been at the village pump. CambridgeBayWeather, Uqaqtuq (talk), Huliva 11:51, 4 July 2022 (UTC)

Here are a few page versions that I reverted on June 20 [4], [5], [6]. The template invocations do not use the width parameter. But it could be that the table display is different now from how it appeared then because the code being invoked has been changed? (I'm out of my element on this one). Eric ^talk 12:22, 4 July 2022 (UTC)

I restored the previous behavior in Module:Weather box/sandbox and a comparison can be seen at Template:Weather box/testcases. Before 1 July 2022, Module:Weather box (and the current sandbox), gave defaults width=100% and margin=auto. The new module (1 July 2022) gives defaults width=auto and margin= (blank). I'm happy to implement whatever a discussion decides but some concrete examples of problems are needed. Testing should be done in small and large browser windows.

• Clyde River, Nunavut#Climate is using the default width=auto.
• This permalink shows the effect of width=100% in that article.
• Ciboure#Climate is using width=auto which looks fine when the browser window is large.
• This permalink shows the effect of width=100% in that article which is bad. That is easily fixed by adding |width=auto which has been done.

Are there more examples which could be presented to a discussion? Johnuniq (talk) 04:36, 5 July 2022 (UTC)

Thanks for those links. They certainly demonstrate a benefit to auto-width. I must add that in both articles, especially Ciboure, I find the expanded table to be overkill for a small article on an individual municipality. Eric ^talk 15:33, 5 July 2022 (UTC)

I agree that the last one is bad but the first one with the reduced table is bad as well. I still don't think that auto by default is the way to go. CambridgeBayWeather, Uqaqtuq (talk), Huliva 20:55, 11 July 2022 (UTC)

Johnuniq Is it possible to make "|width=auto" work in the same way as {{Airport-Statistics}} does? Look at Transport in Egypt#Airports and Heathrow Airport#Annual traffic statistics. The template expands and contracts to fit the space available rather than the permanently compressed way that this template does. CambridgeBayWeather, Uqaqtuq (talk), Huliva 09:00, 20 July 2022 (UTC)

@CambridgeBayWeather: It's unclear to me where that behavior comes from. It may be handled by the Graph extension (Help:Graph). {{Airport-Statistics}} uses Template:Graph:Chart/styles.css which may also play a part. @Ahecht: Do you know what magic controls the width of airport statistics? The question here is whether that magic can be applied to this template which outputs a wikitext table. Johnuniq (talk) 09:59, 20 July 2022 (UTC)

@Johnuniq Template:Graph:Chart/styles.css won't affect anything unless you're viewing the page on mobile. My only contribution to {{Airport-Statistics}} was to put it in a box that matches image thumbnails, but even so I'm not sure it's really a good basis for comparison here, since this template uses Wikitables, while Airport-Statistics uses the Graph extension to draw graphics on an HTML canvas. That said, refactoring this template so it uses a line graph (such as that at https://weatherspark.com/y/27472/Average-Weather-in-Clyde-River-Canada-Year-Round) instead of a huge wall of numbers would probably be a huge improvement to article readers. --Ahecht (TALK
PAGE) 14:48, 20 July 2022 (UTC)

Period

There is nowhere to put a period parameter on each line where data was collected over different periods.

This is no problem where all the data covers the same period, but some weather data was only collected over particular periods, which may be different within a table, particularly if sourced from different sources, so each table line should have an option of adding the period. Either an additional column, or most readable would be on the description of each line.

I know for absolute scientific comparison putting such data in a single table is not normal, but where data covers different periods, this must be shown. Separate tables is less tidy.

I don't know how to modify a template or how to request modifications of a template, so added to this discussionLkingscott (talk) 15:51, 29 January 2023 (UTC)