Template talk:Weather box/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

New changes

a month ago user Koopatrev added new data to the template [1]. According to me, these changes in main Weather box should be reverted. The template is already too large, it takes a lot of space on screen, adding new redundant information to main Weather box is nonsense. What do you think? Subtropical-man talk
(en-2) 16:50, 5 May 2016 (UTC)

The same non-argument could be used when many of the parameters of this template were individually added, so it is nothing more than Wikipedia:I don't like it. And I have already explained to you how "avg record high C" and the other three variants are not redundant, but you evidently refuse to consider or listen. CaradhrasAiguo (talk) 17:00, 5 May 2016 (UTC)

CaradhrasAiguo, please stop trolling. I created the topic to ask the opinion of other users. Yes, you wrote: "Purchase a wider screen" - yes, I go to the store to buy a large monitor to browse Wikipedia because user CaradhrasAiguo want enter a very large templates. Wikipedia is encyclopedia for all, not only for people with large monitors. Weather box is largest template in Wikipedia and we have to think to solve this problem. Further larger template (eg. new edition by user Koopatrev) is the increase of the existing problem. Subtropical-man talk
(en-2) 17:35, 5 May 2016 (UTC)

"Weather box is largest template in Wikipedia" -- Zero evidence to corroborate that. CaradhrasAiguo (talk) 17:52, 5 May 2016 (UTC)

@Subtropical-man:@CaradhrasAiguo: Don't remove, those two parameters are useful for telling the temperature expect in a typical year @CambridgeBayWeather: I want to hear your input. And Subtropical-man, please start a discussion before reverting all the edits adding these paramters. You are starting unnecessary problems for everyone by reverting them without a prior discussion. Koopatrev (talk) 03:15, 6 May 2016 (UTC)

Koopatrev, no - please start a discussion before mass changes in dozens city templates. You add new two parameters to main Weather box and user CaradhrasAiguo enter it to dozens articles without any discussion or consensus. It is outrageous! I reverted changes by CaradhrasAiguo in dozens articles/templates and create discussion here. So. Subtropical-man talk
(en-2) 11:45, 6 May 2016 (UTC)

Wrong as usual, @Subtropical-man:. The additions made by @Koopatrev: and myself fall under the BOLD, and yours fall under the REVERT, per Wikipedia:BOLD, revert, discuss cycle. Now we are holding DISCUSSion that had already occurred above. It seems to me that you either demonstrate a fundamental misunderstanding of that guideline, or understand it and are lying to stymie progress. CaradhrasAiguo (talk) 14:11, 6 May 2016 (UTC)

CaradhrasAiguo, you wrong. Change by Koopatrev in Template:Weather box [2] is first case and subject only to bold edit. You massively adding new parameters to dozens articles of U.S. cities without any consultations with other users and this is second case, your bold edits have been reverted, according to the Wikipedia:CYCLE (bold, revert = discuss cycle). This discussion concerns the first case - addition of new parameters to Template:Weather box [3].

CaradhrasAiguo, you get an official warning - I established the topic for discussion on the problem and ask other users what they think [4] but... you came here to wrangle, trolling and attack me. Stop. We discuss here about the new parameters, not users. This is the last warning. This is discussion about change by Koopatrev in Template:Weather box [5], only! Subtropical-man talk
(en-2) 15:49, 6 May 2016 (UTC)

@Subtropical-man: Again, ignoring the discussion (that makes this section the second on this addition, technically speaking) I linked to above. Ignoring facts when they are inconvenient. I am viewing Koopatrev's initial addition and my mirroring of them in the U.S. as the BOLD. Your en masse REVERTs are done without any demonstrable understanding of what this data entails (you have casually dismissed them as "redundant"). So, I give you a chance to demonstrate your competence and explain what the added data is actually about.

And I have already explained the concept on your talk page, but you have clearly chosen to ignore the explanations, instead focusing on personal / behavioral matters. Who's the one wrangling now? Stop the projection. CaradhrasAiguo (talk) 16:26, 6 May 2016 (UTC)

Your last post is trolling. Also, your post was a personal attack signs. This is discussion about change by Koopatrev in Template:Weather box, only!!!. Also, this is not a private discussion - Template talk:Weather box is public space for all Wikipedians, your arguments what you wrote on my talk page refer to another case. Discussion in Template talk:Weather box concerns only changes in Template:Weather box! Please do not post their opinions about me because it's personal attacks. This is final warning. Subtropical-man talk
(en-2) 16:59, 6 May 2016 (UTC)

@Subtropical-man: Nope, my explanation on your talk page was not private in the sense that an e-mail exchange between the two of us has the expectation of privacy. Since you are intent on deflection and character assassination, by your unwillingness to address the explanation (or attempt) I made on your talk page, I'm reproducing it here:

"To begin, |year avg record low F= −3.9 for Pittsburgh is a 1981–2010 proxy for hardiness zone at that location. The |year avg record high F=92.7 is useful in this sense: it shows the most extreme heat that Pittsburgh can expect during a year is less extreme when compared to other cities in the eastern U.S." CaradhrasAiguo (talk) 17:10, 6 May 2016 (UTC)

Average high °C (°F) and Average low °C (°F) is enough. Wikipedia is not portal of meteorology, Wikipedia is encyclopedia, do not required to show an extremely detailed. Typical people are viewing Wikipedia, and large amount of information in one table may deter them. Typical man i.e. John Smith or Jan Kowalski may not know what it Record high humidex, Mean maximum °C (°F), Record low wind chill etc. You, me and some other users know, but most of people, not. Template:Weather box should include only major standard data. Subtropical-man talk
(en-2) 17:19, 6 May 2016 (UTC)

No, you do not know what information the "ordinary" (something evasive to define to begin with) reader would accept; also you have no Web Analytics evidence to support your spurious claim that a large table may "deter them". Besides, hardiness zone (determined by "|year avg record low C = ") is useful to practically any serious Gardener, regardless of their interest in climatology or meteorology. And, for instance, the USDA hardiness zone classification for most U.S. places is based on 1976–2005 data, so the 1981–2010 annual average minimum is far more "recent", as it skips the cold and/or snowy winters of 1976–77 thru 1978–79 in the eastern half of the U.S.

"Major standard data" is subjective and what constitutes that is not WMO standardized as far as I know. CaradhrasAiguo (talk) 17:28, 6 May 2016 (UTC)

No, you do not know what information the "Gardener" would accept. And "the USDA hardiness zone classification for most U.S. places is based on 1976–2005 data, so the 1981–2010 annual average minimum is far more "recent", as it skips the cold and/or snowy winters of 1976–77 thru 1978–79 in the eastern half of the U.S." -- Zero evidence to corroborate that, and even if - this is Wikipedia, not meteorology agency with data for USDA or "serious gardeners". Subtropical-man talk
(en-2) 17:35, 6 May 2016 (UTC)

I don't want to contribute much to the argument, but my original sentiment remains consistent. That said, it doesn't look like either person here wants to change their mind. Either we find a compromise (which I don't think would be very realistic to find), or we have more users input their view on these extra two parameters. I very much want to bring more attention to this change as this template is widely used. I don't think anyone would feel comfortable if all of their contributions from now are involved in edit wars. Koopatrev (talk) 17:55, 6 May 2016 (UTC)

Koopatrev, you wrote: "Either we find a compromise (which I don't think would be very realistic to find)" - I see compromise. The problem is that current version of Weather box is too extensive to the article about the city but if we create guidelines - the problem may disappear. What guidelines? For example: parameters of Average high °C (°F), Average low °C (°F), Average precipitation mm (inches), Average precipitation days , sunshine hours is used for weatherbox in articles of cities/places, other data i.e. humidex, Record high/low, Mean maximum/minimum, wind chill etc - only to used in separate articles ("Climate of..."). Good example: see Valencia with major standard data and Climate of Valencia with all data. Subtropical-man talk
(en-2) 18:12, 6 May 2016 (UTC)

@Subtropical-man: this might sound stupid, but is there any way to alter the table, so that users can press a link on the table to show or hide certain parameters (like the button that shows or hides the entire table). If that is possible, perhaps it would be a good compromise to keep those two parameters off (hidden) by default. Koopatrev (talk) 03:18, 8 May 2016 (UTC)

I remain neutral on this. From this conversation, there is an exchange of attacks between CaradhrasAiguo and Subtropical-man which needs to stop. I did came across a forum discussion (it is from city data) which mentioned about the new changes to see if readers like it or not, and so far, most readers prefer it due to the utility of the information being provided as mentioned by CaradhrasAiguo. If the readers prefer it, I see no reason in removing it. Ssbbplayer (talk) 15:16, 10 May 2016 (UTC)

@Ssbbplayer: Thanks for the link. It's been a long while since I've posted at City-Data. CaradhrasAiguo (talk) 15:32, 10 May 2016 (UTC)

• About link: it is worth noting a couple of issues to this link. Firstly: this is forum, does not meet any requirements according to the Wikipedia:Verifiability. Secondly: it is not certain who wrote on the forum on city-data.com/forum, User:CaradhrasAiguo? maybe yes, maybe not... or/and other user from Wikipedia? So. Thirdly: even if read these forum, some posts are interesting, for example: "Mean cloud cover should have been a feature. Overcast or clear skies does make a big difference in the high latitudes in winter. A substantial part of the short days will see the sun too low to register on a sun recorder - and there will be daylight or civil twilight before and after sunset for a much longer time if the skies are clear. Often with nice bluish light on the sky. So clear days will be a lot lighter" and other. Different people have different ideas of new data - if we realize every idea by people, a Weather box will be infinitely large. Fourthly: even in forum, not everyone was delighted, so - new data are controversial. Fifth: quote speaks for itself: "The feature is quite nice, but I don't think it will be common, as I believe that the data is quite hard to find outside the US" - yes, it's true.

• Returning to the case, I am not against to new parameters, I am against to new parameters as normal parameters to use in typical weatherboxes in articles of cities. I presented a compromise (above) - create guidelines: parameters of Average high °C (°F), Average low °C (°F), Average precipitation mm (inches), Average precipitation days , sunshine hours is used for weatherbox in articles of cities/places, other data i.e. humidex, Record high/low, Mean maximum/minimum, wind chill etc - only to used in separate articles ("Climate of..."). Idea by Koopatrev is also good, weatherboxes in articles of cities show standard data and if the reader wants to know the details - click the button "details" or "show". Subtropical-man talk
  (en-2) 19:11, 10 May 2016 (UTC)

The city data forum is only used to illustrate a rough guide of other's opinions on this. I am not sure if this is discussed in social media as well. Regarding other proposals, I believe that Koopatrev's idea is a reasonable compromise since not all articles have the "Climate of..." (this is because it is hard to find secondary sources that explain the climate of the city in detail to avoid the article being nominated for deletion). Ssbbplayer (talk) 21:41, 10 May 2016 (UTC)

@Ssbbplayer:@Subtropical-man:@CaradhrasAiguo:Thank you, however I just want to make sure if it's actually possible to do so. Also, perhaps this could be irrelevant - I noticed Cardhras Aiguo inserted a footnote (explaining Avg record high/low) at the bottom of the weather box manually - perhaps we could add this footnote by default into the template itself? Speaking of which, IF we unanimously decide to continue implementing avg record high/low data, is it feasible to create a bot that automatically statisticizes NOW Data (1981-2010) to find their avg record high/low values? From what I understand I don't think any meteorological archives provide their calculations for these two data values -- meaning the only way to find these would be to manually calculate from their daily data, if they do have such a public archive for this. Koopatrev (talk) 07:10, 11 May 2016 (UTC)

I've waited a few days before commenting. As I said before I'm not too bothered either way. I would suggest caution in using what people in an outside forum have to say. There is no way to tell if they represent the general reader, any more than we do. One thing to remember is that as soon as new fields are added then people will add them to cities even if not warranted. For example, Climate of Vancouver is one of Canada's wettest place so it might be useful to have the cloud cover in the template. St. John's, Newfoundland and Labrador#Climate is one of the foggiest cities and that might benefit from having visibility in the template. But if those are added then someone will also add them to Whitehorse, Yukon even if the template has guidelines for use. The idea that using only some of the fields in the city article and more in the climate of is a good one except that you have things like {{Vancouver weatherbox}} which are used in the Vancouver and Climate of Vancouver articles. So any fields added will appear in both. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 15:35, 12 May 2016 (UTC)

@CambridgeBayWeather: @Koopatrev: @Ssbbplayer: So, apart from Subtropical-man's immaterial protests, it is safe to say there is no real objection to inclusion of these two parameters? CaradhrasAiguo (talk) 22:06, 21 May 2016 (UTC)

@CaradhrasAiguo:@CambridgeBayWeather:@Ssbbplayer: Being the person that propoesd this idea I would naturally agree - can wehave a consensus? — Preceding unsigned comment added by Koopatrev (talk • contribs)

CaradhrasAiguo, it's not so simple. There is (probably) small consensus for keep this two parameters in Template:Weather box, but not (yet) consensus to the use of these two parameters on a large scale. And also, there is small consensus for option of hide/show detailed in Template talk:Weather box, whether is necessary further discussion (I ask other users)? Subtropical-man talk
(en-2) 12:16, 22 May 2016 (UTC)

@Subtropical-man: Um, @Koopatrev: has already noted my general inclusion of explanatory notes, i.e. "Mean monthly maxima and minima (i.e. the highest and lowest temperature readings during an entire month or year) calculated based on data at said location from 1981 to 2010." from the pre-machinations version of {{Miami weatherbox}}. This can be incorporated for the other fields that trip up not the most astute readers, such as confusion over "Average high °C" that has been, as I can see, noted in previous threads at this template.

Last time I checked, there was mention on City-Data of the obvious utility of the Mean maxima and minima: It is a given that most locales will typically not reach their all-time monthly record highs or lows. You have provided at most an immaterial response to both points. CaradhrasAiguo (talk) 20:56, 23 May 2016 (UTC)

Alternative

Anyone following this template might like to see an alternative to {{Weather box/cols}} that I just implemented to fix time-out script errors in an article which has an excessively large number of template calls. Information is at Talk:List of cities by sunshine duration#Script errors. Johnuniq (talk) 11:04, 27 June 2016 (UTC)

Warning notice

"Warning: Page using Template:Weather box with unknown parameter "year avg record low F" (this message is shown only in preview)." ??? Mannanan51 (talk) 20:12, 12 July 2016 (UTC)

See the talk page section I added above. |year avg record low F= was not a valid parameter listed in the documentation. I have fixed the documentation and modified the template to allow this parameter. Is that the outcome that you wanted? – Jonesey95 (talk) 21:34, 12 July 2016 (UTC)

year avg record high F

This parameter seems to be repeated, where the second occurrence should be "year avg record low F". Colonies Chris (talk)

I have fixed this typo in the documentation. – Jonesey95 (talk) 21:35, 12 July 2016 (UTC)

2nd line avg monthly maximum and minimum temperatures

Why aren't these temperatures enabled?

They are noted as "FIRST-SECOND LINE..." but I thought about separating i.e. adding second line ones in case it is somewhere used.--Obsuser (talk) 02:28, 25 August 2016 (UTC)

Precip/rain/snow day thresholds

@CambridgeBayWeather: @Ssbbplayer: To facilitate conversion of those thresholds, can we add a parameter such as unit precipitation days unit = in (or mm, cm), with automatic conversion to mm for precip/rain, cm for snow, and inches for all three categories? Output should be similar to this. CaradhrasAiguo (talk) 05:23, 11 September 2016 (UTC)

@CaradhrasAiguo: I think the idea of using automatic conversions is good since not all readers will understand the metric or imperial system. In the example you provided, I prefer abbreviating the units since it looks too large if the units are not abbreviated. Ssbbplayer (talk) 14:15, 11 September 2016 (UTC)

It would be a good idea. It would have to allow for metric, imperial and no input. I noticed that Paris#Climate has no threshold. I also have no idea how it should be implemented. And I agree with Ssbbplayer that the units should be abbreviated. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 17:00, 11 September 2016 (UTC)

Add “Average wind speed (km/h) (m/h)”

I think we should have “Average wind speed (km/h) (m/h)”. The faster speed, then more darker will be shown by default. 46.130.134.240 (talk) 10:44, 17 October 2016 (UTC)

Altitude

I have seen that some weather boxes put the altitude of the station in the location field. Is that correct or an additional field (with automatic conversion between metres/feet) would be more suitable? --Carnby (talk) 11:19, 24 July 2016 (UTC)

An additional and optional field with automatic conversion would be best. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 00:39, 25 July 2016 (UTC)

Try | location     = Location (elevation {{convert|200|m|ft|abbr=on}}. 46.130.10.30 (talk) 10:54, 17 October 2016 (UTC)

Calculation error in the weather box

The weather boxes for locations far enough north to not have the sun rise above the horizon in winter seem to be making a calculation error with the percent possible sunshine yearly average. If no yearly total is entered manually by the editor, the automatic calculation seems to be fairly incorrect. With northern Canadian locations there is no yearly total listed by Environment Canada in the sources, just the monthly totals. This is leading to people putting in a number which they think is correct but to me still seems to be incorrect in the instances I've looked at. Can we have the template calculate this total automatically and correctly or if there are problems with this then perhaps we could have it not make any calculation at all if the yearly total is left blank by the editor? Air.light (talk) 20:46, 28 November 2016 (UTC)

Please link to an example article that is doing it wrong, explain how that example is doing it wrong, and explain what the true output of the weather box should be. Thanks. – Jonesey95 (talk) 21:36, 28 November 2016 (UTC)

Alert, Nunavut is one such example. Just edit the yearly total field to be blank or missing to see the miscalculation. Air.light (talk) 21:47, 28 November 2016 (UTC)

I think I see the problem. Thanks for the link. The module appears to calculate the average using the formula if mode == 'avg' then total = math_mod._round( total / 12, p1 + 1 );. When the values for some months are 0.0, it uses those values to calculate the average, resulting in 24% (289/12). Instead, the module should allow some months to be blank (or N/A) and then divide by the number of populated cells (instead of 12) to get the correct 36% value (289/8). I don't know how to program that in Lua. – Jonesey95 (talk) 22:48, 28 November 2016 (UTC)

Is 36% correct though? If there's about 4400 hours of annual sunshine, then 1902 hours is 43.2% of maximum. I realize there can be some variation on yearly sunshine hours depending on latitude but I didn't think it was that much and it seems like it should make the annual sunshine hours be lower at northern latitudes due to the sun spending more time outside of the higher angles that cause strong enough rays to cause a positive measurement to occur on the measurement machine; this would mean that if the latitude issue was causing an issue here it would mean that the error would be showing a number higher than 43.2%. Air.light (talk) 22:57, 28 November 2016 (UTC)

I suspect that dividing by 8 months in this case understates the average, since there are periods in each of the "shoulder" months where no sunshine is possible. In any case, adding up a bunch of monthly percentages and then dividing by 12 is simply bad math, since some months are 28 days long, while others are 31 days long. I expect that in this case, the only reliable thing to do is to modify the documentation to state that |year percentsun= should always be filled in manually if sourced data is available or for areas above 66 degrees latitude. – Jonesey95 (talk) 23:52, 28 November 2016 (UTC)

Wouldn't the right answer be ${{\text{annual hours with observed sunshine}} \over {\text{annual hours where sunshine is possible}}}={\sum {\text{monthly hours of observed sunshine}} \over {\sum {\text{monthly hours of possible sunshine}}}}$

$={\sum {\text{monthly hours of observed sunshine}} \over {\sum {{\text{monthly hours of observed sunshine}} \over {\text{monthly percent sunshine}}}}}$

In the Alert case that comes to ${1901.6 \over 4579.9}$ = 41.5% Dragons flight (talk) 01:01, 29 November 2016 (UTC)

Incidentally, if people really care one can rewrite the calculation function to generally determine annual averages by weighting months by their number of days, but the impact of doing so will often be very small (~0.2% in the case that the month-to-month variation is ~30% of the annual mean). Dragons flight (talk) 01:01, 29 November 2016 (UTC)

That math looks right to me, at least at a first pass, except in the case where monthly percent sunshine is zero or undefined (divide by zero error). Can we make the module do that math? – Jonesey95 (talk) 02:39, 29 November 2016 (UTC)

Error message and tracking category for unsupported parameters

I have added error tracking for unsupported parameters to this template. See Category:Pages using weather box with unknown parameters. A red error message appears below the rendered weather box when you Preview the article. In the category, the articles are sorted by the name of the parameter that is unsupported.

One of the common unsupported parameters is |imperial first=. The documentation says not to include it, but many articles use it and the module appears to check for it. How would you like to deal with this parameter? I can remove it from the check, but someone should probably add it to the documentation as well.

There are a number of "year" parameters that initially caused articles to be placed in the error category, because the script I used to add the parameter list does not look at subtemplates or modules that are called by the main template. I have added a bunch of those "year" parameters manually, so those articles should drop out of the error category shortly. They are categorized under "Y" in the category.

If I have made any mistakes in coding, or if template changes are desired, please let me know. – Jonesey95 (talk) 01:19, 2 July 2016 (UTC)

About 1,100 articles are categorized under "Y". Many of these look like they are caused by a capital "Y" in the parameter name instead of a lower-case "y". Someone with AWB access could probably sweep through those articles pretty quickly with a find-and-replace pattern.

About 2,400 articles are categorized under "I" for |imperial first=. – Jonesey95 (talk) 04:16, 2 July 2016 (UTC)

Without checking here first, I made the template automatically categorize articles articles with {{Weatherbox}} containing the parameter |imperial first= in the category Category:Pages using Weather box with deprecated parameters, and started an AutoWikiBrowser run to remove |imperial first=y (or =Y, =yes, =Yes; or very rarely =n) from all the articles that have it.

Perhaps I should have checked the talk page here first, since I didn't know there was already a category for {{Weather box}} maintenance. And perhaps it would be better if |imperial first= were replaced with something else, so that the intended behavior (displaying imperial or metric units first) would be explicitly specified.

To me, a parameter |first=imperial or |first=metric makes the most sense, since it would not imply that either format is the default, as the deprecated parameter |imperial first= or the current |metric first= do. If |first= were used, then I would have to go back and add |first=imperial to the instances of {{Weather box}} that I removed |imperial first= from.

I'm going to stop my AWB run for now. Let me know if I should be removing |imperial first= or not. — Eru·tuon 09:50, 18 September 2016 (UTC)

As you can see, I had no response to my post above. I decided to just leave it until interested parties contribute to the discussion. If you want to fix some actual problems, I recommend starting with the articles categorized under "Y" in the maintenance category, many of which need a simple replacement of "Year" with "year". – Jonesey95 (talk) 12:54, 18 September 2016 (UTC)

@Jonesey95: Unfortunately, AutoWikiBrowser cannot access sortkeys (as far as I can tell; I could be wrong), so could you make all these articles be placed in a subcategory, perhaps titled Category:Pages using weather box with unknown parameters/Y? — Eru·tuon 20:30, 18 September 2016 (UTC)

See User:Jonesey95/sandbox3 for all of the "Y" entries in the category. Have fun! – Jonesey95 (talk) 03:42, 19 September 2016 (UTC)

Ahh, that is another way to solve the problem. I'll start working on them! — Eru·tuon 04:03, 19 September 2016 (UTC)

Done. Let me know if there are any other urgent AWB-appropriate tasks. — Eru·tuon 19:32, 19 September 2016 (UTC)

Wow, fast work! There are still a few left in the category, like Darmstadt, which uses |Year sun= instead of |year sun=. I'll update the Sandbox3 page momentarily with the remaining "Y" entries. – Jonesey95 (talk) 19:56, 19 September 2016 (UTC)

I finished the rest from your sandbox3. Quite a few of them did not actually have Year, so perhaps the module occasionally miscategorizes. — Eru·tuon 22:28, 21 September 2016 (UTC)

Let me know if you can find one that is miscategorized. There are still a bunch of "Y" (or "y") parameter errors left in the category. Zephyrhills, Florida, for example, uses |year record high=, which is not valid. – Jonesey95 (talk) 23:15, 21 September 2016 (UTC)

Oh, I was only searching for the capitalization error. I could have created a regex for the other type of error if I had known about it. — Eru·tuon 00:05, 22 September 2016 (UTC)

One note: it is not accurate to describe |imperial first= as a "deprecated" parameter, as the new error tracking category does. A deprecated parameter is one that is explicitly supported but should be removed. |imperial first= is unsupported, not deprecated. – Jonesey95 (talk) 05:51, 20 September 2016 (UTC)

Ahh, I did not know that. I've moved the category and changed the template accordingly. — Eru·tuon 06:06, 20 September 2016 (UTC)

|imperial first= is already detected by the code that populates Category:Pages using weather box with unknown parameters, so your category, while more specific, may not be needed. – Jonesey95 (talk) 12:53, 20 September 2016 (UTC)

Well, Category:Pages using weather box with unknown parameters is not very useful, because pages with one type of error cannot be discovered by AutoWikiBrowser. If subcategories for each type of error were created, I'd definitely delete the category I created. — Eru·tuon 22:14, 21 September 2016 (UTC)

There is only one type of error in the category: the template is attempting to use a parameter that does not exist in the template's code. This is a standard practice for many templates and infoboxes; see Category:Wikipedia template parameter issues, specifically most of the categories that start with "Pages using infobox". Also see Category:Pages with citations using unsupported parameters, one of many categories tracking types of errors in Citation Style 1 templates.

I do not have access to AWB, but I use scripts to fix errors in these tracking categories. I adjust and expand my scripts as I traverse each category to enable my script to fix different varieties of the same error. Some errors are fixable only by hand, of course. – Jonesey95 (talk) 22:20, 21 September 2016 (UTC)

Ah, okay. So the Y or whatever letter is first in the sortkey is just the first letter of the parameter name? — Eru·tuon 23:33, 21 September 2016 (UTC)

Well, I would be willing to do more work. But I don't know what kind of errors to look for aside from what you tell me, and the automatic categorization system does not give any information. It would help if you could make some kind of list of the more common errors that you have noticed. — Eru·tuon 00:37, 22 September 2016 (UTC)

Ohh, I discovered that the template displays the unknown parameter in preview mode. So that's how to figure it out. Still, it would save time if I had some kind of a list. — Eru·tuon 01:12, 22 September 2016 (UTC)

Now you've got it. I find that it's an iterative process. I go through a few articles under a specific letter and see if I can find any patterns. Sometimes it's a mix of strange junk. Other times, there are a hundred or a thousand identical parameters that have been removed from the template at some point in the past. Sometimes it's easy to figure out what was intended by looking at the template's documentation. Other times, you might need to ask on the template's talk page. Still other times, it's a simple typo that is straightforward to fix, like a hyphen instead of an equals sign. You just have to dive in and learn.

I suppose it is possible that someone more clever than I could do a scan of the articles and make a list of all of the unknown parameters. That's beyond me, though. – Jonesey95 (talk) 03:24, 22 September 2016 (UTC)

The problem is with Module:Check for unknown parameters. It doesn't do as much as we need it to. I do have one idea: maybe changing the code [[Category:Pages using weather box with unknown parameters|_VALUE_{{PAGENAME}}]] to [[Category:Pages using weather box with unknown parameters/_VALUE_|{{PAGENAME}}]] would create subpages for each type of parameter. Then, we would simply have to go to Special:PrefixIndex/Pages using weather box with unknown parameters and we could see all the unknown parameters listed. Hmm, but the category pages wouldn't have any content, so they would not be listed. Oh well. — Eru·tuon 05:06, 22 September 2016 (UTC)

A lot of redlinked category pages that would have to be created, and you'd have to go to each article to know which category to create. I see your dilemma. – Jonesey95 (talk) 12:54, 22 September 2016 (UTC)

1. a parameter |first=imperial/metric is good and neutral and should be introduced to Wikipedia. This is a much better and clearer solution than separate |imperial first=yes/no and |metric first=yes/no.
2. Module:Check for unknown parameters is unnecessary in weather box, better to use a bot that will do the corrections in thousands of articles. New changes in the weather box does one thing: disfigure articles, displaying prompts about the wrong parameter.
3. metric system shoud be as defaults because most countries in the world use this system. At the moment is inversely - imperial system is defaults.

Subtropical-man (talk / en-2) 22:32, 11 November 2016 (UTC)

I support using the parameter |first= for the reason you give. Regarding the annoying messages, it's my fault. I will revert my change so that they once again only display in the edit window. — Eru·tuon 00:20, 12 November 2016 (UTC)

I have modified the template so that the preview message is displayed for all unknown parameters, but the hidden tracking category is displayed only in main (article) and template space. This way, we don't have editors' sandboxes and old talk pages, which should not be "fixed" for this error, cluttering up the category. – Jonesey95 (talk) 04:13, 13 December 2016 (UTC)

Request dew point to weatherboxes

Why there's no dew point in the weatherboxes? WeNeedWikipedia! We sure do^{Leave a message?} 00:59, 7 February 2017 (UTC)

Dewpoints

Perhaps this has been discussed before, but I genuinely believe that we should implement a dewpoint row in the weather templates. Humidity figures don't exactly tell how muggy (or dry) a climate is. Dewpoints, in this case, do so. They'll be incredibly beneficial and useful to the system. I hope a mod would consider this integration, or at least, I'd like to see a voting on this matter. Meganesia (talk) 2:55, 22 November 2016 (UTC)

Me too WeNeedWikipedia!^{It's essential!!!}(Say what?) 09:36, 15 February 2017 (UTC)

Well guys, while you are at it, would somebody please make the values for "humidex" to be also convertible! The coloring for values in °C is alright; it follows the patterned range as "humidex" has been initially defined by °C. Nevertheless, for the inputs which are in °F the coloring is extreme and takes an irrelevantly dark pattern. - Thanks in advance!

Template-protected edit request on 8 January 2017

I would like to add a line called thunderstorm days, which tells the users per month how many thunderstorms the city gets. Thelogoontherun (talk) 21:56, 8 January 2017 (UTC)

Is there a reliable source for that data? – Jonesey95 (talk) 22:51, 8 January 2017 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. — JJMC89 (T·C) 05:06, 9 January 2017 (UTC)

Yes, there is. It requires some calculating, but it can be done. --Thelogoontherun (talk) 19:05, 11 March 2017 (UTC)

Too many decimal places for inch conversion

0.1 mm is about 0.004 inches. This means that we're being a bit misleading expanding the inch conversion to 3 decimal places: When we say that, say, 25.5 mm is 1.004 inches of rain, what we actually mean is that it could be anything from 1.002 in to 1.006 in. As it stands we have false precision. Expanding to 2 decimal places would be less misleading: 25.4 mm is 1.00 in, 25.5 mm is 1.00 in, 25.6 mm is 1.01 in, and so on. Smurrayinchester 12:31, 24 March 2017 (UTC)

(To put it another way: most mm readings will be to three significant figures, but the inch conversions are four sig. figs. This is bad practice). Smurrayinchester 12:33, 24 March 2017 (UTC)

Average monthly high/low

Disappointing that monthly "Average high" and "Average low" are still not anywhere explained. As I mentioned a long time ago, these figures are totally meaningless unless one knows whether it is average of monthly highs or average of daily highs over the month. 86.191.58.162 (talk) 02:37, 27 May 2017 (UTC)

The average high parameter is the average of all days in the climate period. The average record high or mean maximum parameter is the average highest temperature to occur in each month over the climate period. The highest value in this parameter is not necessarily the average annual highest temperature.--2A02:C7F:C814:7F00:F585:7DE9:935D:28FA (talk) 21:14, 9 July 2017 (UTC) Edit: Same applies to the lows--2A02:C7F:C814:7F00:F585:7DE9:935D:28FA (talk) 21:15, 9 July 2017 (UTC)

Average wind speeds

Is there a consensus for an average wind speed and air frost parameter to be added to the weather box? The Met Office gives this data for almost all climate locations in the UK but at the moment it cannot be used as it is not supported by the weather box--2A02:C7F:C812:FD00:C541:F7F5:2531:957F (talk) 23:47, 27 July 2017 (UTC)

Two proposals

Proposal #1: make a parameter {{{text}}} that allows the "Climate data for" text in the first row to be changed to something else if needed. For example, the template is sometimes used to show the record temperatures by month not for a single location but for an entire country, and in that case, as an example, "Temperature records in" <countryname> would be more appropriate.

Proposal #2: change "mean maximum" to "average monthly high", "average high" to "average daily high", "average low" to "average daily low", and "mean minimum" to "average monthly low". "Average" and "mean" are direct synonyms, "high" and "maximum" are direct synonyms, and "low" and "minimum" are direct synonyms, so with the current row labels the reader (viewer?) is forced to use context to attempt to deduce the meaning.

If consensus forms for either or both of these proposals, I'll draft exact changes to the code and make a template-protected edit request.

Thanks, CJK09 (talk) 03:49, 3 September 2017 (UTC)

@CJK09: I would agree these terms have become confusing given that the parameters are starting to become used more often. I like proposal #2 a lot in that it helps clarify the terms. For example, the Korean Meteorological Administration in the 1981–2010 normals publication used the term "monthly maximum temperature" to denote the average monthly high/mean maximum/average record high temperature (basically, the average of the highest temperatures recorded in that month) on page 489, and "daily maximum temperature" (equivalent to "average high" in the weather box, the one most people know that is more useful to understand) on page 487 to distinguish these 2 terms which is very similar to your proposal. It is a good proposal in my opinion. Ssbbplayer (talk) 03:43, 18 October 2017 (UTC)

Metric only, no imperial

Is there a way to have only the metric units displayed (ie. no imperial conversion) using this template? Dirac (talk) 16:05, 17 November 2017 (UTC)

By looking into the Template code and into the WeatherBox Lua module, I see that the answer to this question is no.Dirac (talk) 16:23, 17 November 2017 (UTC)

Template-protected edit request on 14 January 2018

Change default width to 100% (or <nothing>). Personally, I would prefer <nothing>. User-duck (talk) 09:14, 14 January 2018 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Requesting a change to A or B strongly suggests you've not thought this through and that you've not discussed it with anybody. Cabayi (talk) 10:56, 14 January 2018 (UTC)

Cabayi, Setting the default width to 90% (or any value) strongly suggests that this was an arbitrary decision and was not thought through, the default for a wikitable is apparently "auto". (I assume from several references, I have yet to find where this is documented.) What I have thought through is that 90% is bad. If the "undocumented requirement" is for the box to use the entire width of an article make the default value 100%, otherwise, use the default wikitable value. There is no one to discuss this with. The developer is unknown. The requirements are unknown. There is no guarantee that anyone will respond to an inquiry on a talk page. I finally figured out "width" must be set by black box testing the template. I finally found the code and discovered the 90% value by inspection. That was when/where I discovered that |width= was implemented and: "If you have noticed an error or have a suggestion for a simple change, you can submit an edit request, ...". I submitted an edit request for a simple change, ...

P.S. I also discover the "font-size:90%" and the undocumented |margin=, there are probably other issues but these are separate from |width=.

I just checked the archived discussions. (Often a waste of time but surprisingly useful this time.) There have been several brief discussions. I see no consensus for 90%. Narrowing the table was often suggested. There was a discussion of setting the default to "width=auto" but nothing happened. The |width= was first mentioned in 2011 but the documentation page was not updated until I attempted it (2018 for those that find this searching the archives. Thanks for the improved wording, Jonesey95)

Now that I have spent more time on this response than was done considering the edit request, I will sign-off. User-duck (talk) 23:49, 14 January 2018 (UTC)

User-duck It would appear that I didn't make the nature of my response clear enough. I'm here as an impartial bystander. I don't care whether it's 100%, 90%, or 5% so long as the request is clear (don't ask me to do this OR that) and it represents the will of the community in a stable way. Replacing one change lacking consensus with another doesn't do that. If you want to re-activate the request and ask for another opinion feel free... though I'd prefer that you gained consensus before doing so. Cabayi (talk) 13:59, 15 January 2018 (UTC)

User-duck, you can use the |width= parameter to set the width to a value of your choice in a particular weather box. – Jonesey95 (talk) 14:57, 14 January 2018 (UTC)

Jonesey95, Yes, I discovered this. P.S. I updated the other two template examples in the document page. Is "Leave blank for wikitable with no width defined" the same as "Set width=auto to fit the table in the next available space automatically"?

Was 90% a "consensus"? User-duck (talk) 23:49, 14 January 2018 (UTC)

If you search for "width" in the archives of this talk page, you will see some discussion of "90%", and other discussion of "auto", as the default. It looks like the most recent implemented consensus is 90%, although auto clearly works better in some cases. – Jonesey95 (talk) 23:55, 14 January 2018 (UTC)

Template-protected edit request on 27 January 2018

The following message is output when the listed pages are edited. Warning: Page using Template:Weather box with unknown parameter "year afthumidity" (this message is shown only in preview).

Donnybrook, Western Australia, Eucla, Western Australia, Katoomba, New South Wales, Kempsey, New South Wales, Maryborough, Victoria, Parramatta, South West Rocks, New South Wales, Summer Hill, New South Wales, Townsville, Young, New South Wales,

|year afthumidity = is listed as a valid parameter in the documentation page.

Please fix. User-duck (talk) 01:53, 27 January 2018 (UTC)

 Done. Affected articles will need a null edit (click edit, then save without making any changes). P.S. I've been to Katoomba. It's a great little place. – Jonesey95 (talk) 04:26, 27 January 2018 (UTC)

There may be more to it. See example at my sandbox (permalink) which shows that if year_afthumidity is omitted, the template calculates the result. Specifying year_afthumidity overrides the calculation, but perhaps it shouldn't? Johnuniq (talk) 04:43, 27 January 2018 (UTC)

I know about the template calculating the year value for most (if not all) types of data. I do not know about overriding a specified value but I do know that is a functional change. I had previously requested a small, and I do mean small, functional update to change a table display parameter (that I assumed was hard-coded) and got a "need a consensus" run-around. I was then informed I could use an undocumented parameter to set that display parameter. I have been going through the 270+ articles with "unknown parameters", fixing the template parameters/data and setting the previously unknown parameter to a usable value. I have updated over 100 already. Doing 10 null edits will be a snap.User-duck (talk) 07:21, 27 January 2018 (UTC)

Lowest maximum and highest minimum options?

They would be greatly appreciated as possible weatherbox options in cases where that might be remarkable or merely interesting for any individual month! "Jan avg highest low C" and "Jan avg lowest high C" would be my preferred codes! Is it possible to implement as possibilities shortly? :) --Lommaren (talk) 10:28, 14 December 2017 (UTC)

@Lommaren: I also hope that lowest maximum and highest minimum options are available soon, even if it serves just as an interesting statistic. Do you know of any user who is responsible for maxing new weatherbox codes? --Undescribed (talk) 16:03, 22 February 2018 (UTC)

Mean maximum

Could we have a better label than "mean maximum"? I had to come to the template page in order to understand what it is -- it sounds like the same thing as "average high"! How about "mean monthly maximum"? Eric Kvaalen (talk) 06:43, 23 February 2018 (UTC)

Source #1 → Source No. 1

Per MOS:NUMBERSIGN, the listing of sources should read Source No. 1, Source No. 2, rather than Source #1, Source #2. Curly "JFC" Turkey 🍁 ¡gobble! 02:11, 11 April 2018 (UTC)

Source 3?

There are about 20 articles using the unsupported parameter |source 3=. Should we add it to the template? It would not be difficult to do.

Another option, if people want to have three sources, is to put them both into |source 2=. We could document that as an option for three or more sources. – Jonesey95 (talk) 04:48, 27 January 2018 (UTC)

No - This a rabbit hole, next there will be a "source 4", etc., there should not even be |source 2=. Multiple sources can be concatenated in a single string. I am in the process of removing "unrecognized parameters" and have done a few of these already. I wanted to finish the Ys before submitting the bug I found.User-duck (talk) 07:30, 27 January 2018 (UTC)

I think source No.1 and source No.2 are sufficient enough. I do not support adding in source 3. We do need source No.2 since many weatherboxes use multiple sources. Having only source No.1 would lead to cluttering if 4 or 5 sources were used in the source No.1 parameter while making it hard to edit for new users. Ssbbplayer (talk) 20:29, 11 April 2018 (UTC)

Incorrect yearly averages

This template seems to employ unweighted arithmetic mean for calculating yearly temperatures. For example, in Dallol, Ethiopia just summing up all months and dividing by 12 gives the figures in the year column. However, if you take into account the uneven length of the months, you get slightly different averages (41.19, 34.64, 28.18). 93.136.78.209 (talk) 02:16, 16 May 2018 (UTC)

The real problem there is false precision. Mathematically, it is unsound to take a bunch of numbers that are precise to one decimal point and perform math on them that results in a figure precise to two decimal points. The yearly averages should be shown as 41.2, 34.6, and 28.2. I'll see if I can fix that. – Jonesey95 (talk) 04:55, 16 May 2018 (UTC)

 Fixed. The original author of the WeatherBox module introduced this false precision deliberately; I don't know why, but it was mathematically misleading. – Jonesey95 (talk) 05:19, 16 May 2018 (UTC)

Is there a way to make it accurate to 2 digits instead of just one? Alex of Canada (talk) 04:18, 17 May 2018 (UTC)

I've never seen temperature that was x.xx. All the ones I have seen only use one decimal place. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 10:47, 18 May 2018 (UTC)

The way to make any of the average figures precise to two digits after the decimal point is for the monthly figures to be precise to two digits. The template automatically chooses an appropriate precision for an average based on the numbers that are provided to it. – Jonesey95 (talk) 14:52, 18 May 2018 (UTC)

Snow row coloring unequal across months

On Cold Bay, Alaska, Feb has darkest color but not most snow. Tested in preview and it seems to appear on other pages too. I'm on a mobile phone now and can't get any more info than this until Sunday. Thanks for your help, —Soap— 20:27, 19 June 2018 (UTC)

It's a feature. The template adjusts for the length of the month. Look what happens if the snowfall for each month is the same:

Climate data for Fake Bay, Alaska
Month	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec	Year
Average snowfall inches (cm)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	10.6 (27)	127.2 (324)

Longer months have lighter colors, since there is less snow per day, on average. February is darkest, since it has only 28 days. – Jonesey95 (talk) 03:24, 20 June 2018 (UTC)

Okay thank you! Honestly that never even occurred to me. —Soap— 17:49, 24 June 2018 (UTC)

Mean maximum

Could we have a better label than "mean maximum"? I had to come to the template page in order to understand what it is -- it sounds like the same thing as "average high"! How about "mean monthly maximum"? Eric Kvaalen (talk) 17:18, 22 August 2018 (UTC)

if not, maybe some way to put a link to an explanation of all the labels. It took me quite a while to figure out myself. That said, I don't think we invented that label, but rather got it from noaa or perhaps a Spanish govt source, since I saw this for Spain once long ago. Lollipop (talk) 03:56, 11 September 2018 (UTC)

"Mean monthly high" or "Monthly mean high" make sense to me. Also, why do some use "mean" and others use "average"? I'm assuming all of these are using the arithmetic mean. I think the most intuitive name would be "Average monthly high". I would also rename "Average high" and "Average low" to "Average daily high" and "Average daily low". — RockMFR 12:57, 15 September 2018 (UTC)

I played around with weather.gov to see what names they use. I selected product="Monthly summarized data", variable="Max temp", and summary="Daily Maximum". That produces a table titled "Monthly Highest Max Temperature", and we seem to use the "Mean" row of that table for our "Mean maximum". I then did the same thing but with summary="Mean". That produces a table titled "Monthly Mean Max Temperature", and we seem to use the "Mean" row of that table for our "Average high". Confused yet? :) — RockMFR 13:58, 15 September 2018 (UTC)

Automatic calculation of Köppen climate classification

I've created Module:Climate, which has a function that takes monthly average temperature in °C and precipitation statistics in mm and calculates the Köppen climate type based on the formulas given in Köppen climate classification. It supports switching between the two isotherms for C vs. D and the two formulas for h vs. k and w vs. s or f.

I'm curious if there would be interest in automatically displaying the Köppen climate classification in this template, if it can be calculated from the data supplied to the template. The function described above could easily be adapted to work with the parameters used by this template. — Eru·tuon 20:26, 27 June 2018 (UTC)

I think it would be a good idea. It would help put a stop to people changing it in the body. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 22:53, 2 July 2018 (UTC)

Yes thank you. But as an obligate pessimist I have to look at the dark side first .... so apologies if this post sounds too negative, i just want to make sure all is well:

is this going to require us to print the data twice in each weather box, once for the reader and once for the template? or is thre a way to integrate this module into the weatherbox? I hope they can be linked. i doubt anyone would vandalize the hidden data, since all it would do would be to change one line ... Im more interested in doing this to 1) save space in the editing window. (or does everybody use visual now?) and 2) save time & effort for those typing it out, siunce the numbers in the existing weatherbox are not in the right format for this module.

we might still have disagreements over where the borders are, as youve dscribed above ... will teh template stick to a single definition, or will people be switching it back and forth?

Thank you for your work and your time, —Soap— 21:21, 11 July 2018 (UTC)

@Soap: There would be no need to duplicate the data. The module could read the parameters already used in {{weather box}} (|Jan mean C=, |Jan mean F=, |Jan precipitation mm=, |Jan precipitation cm=, |Jan precipitation inch=, and so on) and use their values to calculate the climate classification. Indeed, I created the first draft of a function to do that. I just haven't had the opportunity to use it and get it to actually work. — Eru·tuon 21:48, 11 July 2018 (UTC)

Okay, I've added the Koeppen climate function to {{Weather box/sandbox}}, and debugged it so that it is fairly functional. It's temporarily positioned in the table caption. It's not reliable yet, though, and not all necessary features have been added. There needs to be some kind of support for alternative formulas. I could add parameters to select which formula to use (for instance, 0 °C or -3 °C as the isotherm between C and D climates), or have the function show all possible climate classifications using different combinations of formulas, which is more difficult. — Eru·tuon 05:12, 14 July 2018 (UTC)

OK thank you, this is exactly what I'd hoped you'd create. Most of the edge cases are already described in the main text with words like "bordering on a subarctic climate" so I wouldnt worry too much about displaying both climates, but if you can, it would be good to have the option to specify which isotherms to use in the template. —Soap— 19:22, 14 July 2018 (UTC)

@Soap: I can easily add parameters to switch isotherms. The other template-invokable function uses |alt_CD=, |alt_w=, |alt_hk=, to switch to the non-default isotherm between C and D; between Cw, Dw and Cs, Ds, Cf, Df; and between B_k and B_h. I'm not happy with this method because it assumes the editor knows what the default isotherm is, and maybe people would disagree about which should be the default, in which case the meaning of the parameter would change and a bunch of parameters would have to be changed. (For instance, the default isotherm for C vs. D is the 0 °C isotherm, which is apparently more common in the US, rather than the original −3 °C isotherm.) So maybe something like |CD_isotherm=-3 would be better. — Eru·tuon 19:42, 14 July 2018 (UTC)

I like the idea however, I do have a particular comment. After researching on the so called "mild desert climate"/BWn which was posted on the Köppen climate classification talk page (the so called BWn and BSn climates), I believe it is completely unsourced and should not be included in this template. First of all, there is no temperature criteria of what constitutes a mild desert climate. Secondly, neither the Peel et al source, the update Beck et al (2018) source mentions it which are reliable publications that have the criteria for all of the Köppen climate classification types. As such, if this is implemented, note that BWn and BSn climates should not be included as there is no criteria for it (no research papers exist for this yet). Ssbbplayer (talk) 00:31, 11 December 2018 (UTC)

@Ssbbplayer: Fortunately, I didn't add BWn and BSn to Module:Climate at all because I couldn't find a concrete formula defining them. — Eru·tuon 02:23, 11 December 2018 (UTC)

Maximum number of templates

Anyways, I'm working on some charts here: https://wiki.riteme.site/wiki/User:Alex_of_Canada/Climate_Charts. I think I reached the maximum number of templates. Is there any way to increase it? — Preceding unsigned comment added by Alex of Canada (talk • contribs) 07:23, 15 June 2018 (UTC)

No. The page parser report includes "Post‐expand include size: 2097112/2097152 bytes". That means that the templates on that page are generating over 2 megabytes of wikitext, and that is a hard limit that cannot be avoided. Johnuniq (talk) 07:44, 15 June 2018 (UTC)

Oh, alright. Thanks for the answer. Alex of Canada (talk) 08:34, 15 June 2018 (UTC)

What did you do to the text, Alex of Canada? Also, why is 2 MB a hard limit, Johnuniq? Just curious. Grant Exploit (talk) 05:24, 14 December 2018 (UTC)

The quick answer is that 2 MB is built-in to the software that translates wikitext into viewable html. Once templates generate more than 2 MB, additional templates on the page are not processed. Regarding why is there such a limit, it is to avoid silly mistakes causing an undue burden on servers, but more particularly, to avoid denial-of-service attacks where trolls could quickly add bad templates that slow down the servers until they hit a critical point (with readers also trying to read, and repeatedly refreshing pages that didn't load) at which time the system might grind to a near-halt. Johnuniq (talk) 05:59, 14 December 2018 (UTC)

Excessive accuracy precision

I am asking for a change in the excess accuracy in "Average precipitation mm (inches)" / Average rainfall mm (inches)". For example [6]: 66.9 mm of precipitation and weatherbox converts and shows as 2.634 inches. Why converts 2-3 numerical digits of mm to 4 numerical digits of inches (3 digits after the decimal point)? This is stupid. Please round the processed numbers in inches to the same quantity of numbers in mm, ie. 10.0 mm = 0.39 in (not long numbers as 0.394), 4.6 mm = 0.2 in (not long numbers as 0.181) etc. Subtropical-man (talk / en-2) 17:26, 14 December 2018 (UTC)

The mm is supposed to convert to 2 decimal places in inches such as 3.1 mm (0.12 in). Nobody has ever fixed it and I have no idea how. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 03:11, 15 December 2018 (UTC)

I think I have fixed it after some testing in the sandbox and with the testcases page. It appears to be a continuation of the change I made above that changed precision of some other numbers. Take a look and let me know. Note that it is also possible that I broke something, so let me know if that is the case as well. I'm happy to revert this edit if it is not working as intended. – Jonesey95 (talk) 03:42, 15 December 2018 (UTC)

I don't think you are to blame. The three decimal places have been around for several years. Is there any way to force it to go to two places. Such as 25.5 mm (1.00 in). CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 03:58, 15 December 2018 (UTC)

Yeah, that's disappointing and contrary to how math is supposed to work. From a little research, the string.format function of Lua appears to be a possible answer, but I am unable to find enough examples to show me how it works. – Jonesey95 (talk) 12:05, 15 December 2018 (UTC)

Apparently Weather box does not use Convert to convert units, it should. I feel there are deficiencies in the algorithm used by Convert for precision but at least conversion precision would be consistent on Wikipedia. Also any improvements/fixes done to Convert would propagate to Weather box. The examples above do illustrate some interesting points about "precision". Based on what I was taught, 10.0 mm has 3 significant figures (sigfig) and should convert to 2.54 in., 10. would have 2 sigfig and should convert to 2.5 in, whereas 10 mm has 1 sigfig and should convert to 3 in. Next, 4.6 mm should never convert to 0.2 in., based on sigfigs it should convert to 1.8 0.18 in., however, 4.5 mm also converts to 1.8 0.18 in. Apparently the precision algorithm for Convert has changed, i.e. 4.6 millimetres (0.18 in) and 4.5 millimetres (0.18 in), formerly these produced more precise numbers. --User-duck (talk) 17:19, 15 December 2018 (UTC)

I just checked temperature conversion using Convert. The Convert algorithm has changed! Current examples of default precision: 30 °F (−1 °C), 31 °F (−1 °C), 32 °F (0 °C), 33 °F (1 °C), 34 °F (1 °C), 35 °F (2 °C), 36 °F (2 °C), 37 °F (3 °C), 38 °F (3 °C), 39 °F (4 °C). More precision: 30.0 °F (−1.1 °C), 31.0 °F (−0.6 °C), 32.0 °F (0.0 °C), 33.0 °F (0.6 °C), 34.0 °F (1.1 °C), 35.0 °F (1.7 °C), 36.0 °F (2.2 °C), 37.0 °F (2.8 °C), 38.0 °F (3.3 °C), 39.0 °F (3.9 °C). Reverse: −2 °C (28 °F), −1 °C (30 °F), 0 °C (32 °F), 1 °C (34 °F), 2 °C (36 °F), 3 °C (37 °F).

Personally I think they should be: 30 °F (−1.1 °C), 31 °F (−0.6 °C), 32 °F (0.0 °C), 33 °F (0.6 °C), 34 °F (1.1 °C), 35 °F (1.7 °C), 36 °F (2.2 °C), 37 °F (2.8 °C), 38 °F (3.3 °C), 39 °F (3.9 °C). More precision: 30.0 °F (−1.11 °C), 31.0 °F (−0.56 °C), 32.0 °F (0.00 °C), 33.0 °F (0.56 °C), 34.0 °F (1.11 °C), 35.0 °F (1.67 °C), 36.0 °F (2.22 °C), 37.0 °F (2.78 °C), 38.0 °F (3.33 °C), 39.0 °F (3.89 °C). Reverse: −2 °C (28.4 °F), −1 °C (30.2 °F), 0 °C (32.0 °F), 1 °C (33.8 °F), 2 °C (35.6 °F), 3 °C (37.4 °F). But I won't complain.

Looks like Weather box may now use Convert. Hurrah! --User-duck (talk) 17:19, 15 December 2018 (UTC)

Thanks for your thoughts. Do you know how to use the convert template within the Lua module that creates {{Weather box}}? – Jonesey95 (talk) 17:57, 15 December 2018 (UTC)

Convert has not changed how it handles temperatures for several years. Convert is fast but it seems excessive to call it 130 times for one weather box. What problems remain with Weather_box? I could look at fixing them. Johnuniq (talk) 23:58, 15 December 2018 (UTC)

Thanks! One problem is that trailing zeroes are removed instead of displayed. For example, 25.5 mm is converted to 1 in. It should be converted to 1.00 in to maintain significant figure precision. You can see this problem here, in the October rainfall cell and in November average precipitation (1 instead of 1.0). I do not see any problems with temperatures. – Jonesey95 (talk) 02:37, 16 December 2018 (UTC)

@Erutuon: I see you are working on Module:WeatherBox/sandbox. I was going to start investigating the issue raised just above but I first wanted to clean the whitespace and global variables. It's standard to use a tab character to indent modules now and I would fix that. Also, there is a lot of trailing whitespace and I'm afraid my fussy nature would make me remove that. Finally, there are a few unintended global variables which are always undesirable as they can disguise bugs. Unfortunately those changes, while not doing anything substantive, would give a massive diff so I was going to do it in three steps in the sandbox. No hurry, I'll wait. Any problems with what I plan? Johnuniq (talk) 06:19, 16 December 2018 (UTC)

Hmm. How about I remove the redundant semicolons as well? Johnuniq (talk) 06:36, 16 December 2018 (UTC)

I don't have any plans at the moment. (I've got no objections to the proposed coding style changes.) I was stumped because the module seems to use language.formatNum, I guess to allow different systems of digits and such. There isn't an option in that method for precision as there is in string.format. For instance, the Bengali version of the module, মডিউল:আবহাওয়া বাক্স, outputs Bengali numerals, as in this section of the article on Dhaka: ঢাকা#আবহাওয়া ও জলবায়ু. But actually, the Bengali module just uses a numeral converter module, which does simple substitutions, and that's the only Module:WeatherBox interwiki that doesn't use our plain old western numerals. So the module could just use string.format. — Eru·tuon 09:01, 16 December 2018 (UTC)

I haven't thought about the formatNum part of the code but I just had a look and I think it is inserting commas which string.format wouldn't do. The calculations are complex and I am just getting a feeling for what's going on. It looks like Module:Math _precision gives the number of decimal places which is not the number of significant digits. Copying the input precision to the output is not necessarily what is wanted. The reason 25.4 mm ends up as 1 inch (not 1.00) is that _round gives a number which WeatherBox converts to a string with tostring. I'll have to think about a fix another day. Johnuniq (talk) 10:02, 16 December 2018 (UTC)

Sizing, etc.

I've made a spate of edits to the template. Do other users find them useful or not? @Subtropical-man: for bringing it to my attention on my talk. ―Justin (koavf)❤T☮C☺M☯ 23:48, 1 December 2018 (UTC)

The current edit goes to about 765 pixels before horizontal scrolling. Is this still legible for most users? Do we have best practices on screen resolution sizes? I can't read the text if it's 90%, so I'd prefer to not make it smaller. ―Justin (koavf)❤T☮C☺M☯ 23:52, 1 December 2018 (UTC)

Previous size functioning for years and nobody has complained before. In resolutions of 1024x768 or less, the weather box after your new changes protrudes beyond the border of the Wikipedia window, it disturbs the order of the page, makes it much more difficult to view articles with this template (example 1, example 2). Previous (standard) version in FullHD monitors, displays correctly, I checked it. Not every person uses the 4K monitor (or other more than FullHD). You should look to solve elsewhere, look for other solutions, e.g. a button [enlarge] or [zoom] near button [hide]/[show] (upper right corner of weather box). As standard, it should be as it was before (90%) + new button for up to - for example - 110% (for monitors with resolution above Full HD, including 4K). This is my proposition. I will never accept your new changes being a blow to group of users with monitors of 1024x or less in favor of another group (with ~4K monitors) without greater consensus. Subtropical-man (talk / en-2) 00:20, 2 December 2018 (UTC)

I'm using 1600x900 and the very right bar is missing. So no data is missing. However, look at Chesterfield Inlet, Nunavut. That has <div style=width:80%> to enable the box to sit on the right of the infobox. Now it pushed down leaving a large amount of white space. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 08:14, 4 December 2018 (UTC)

I have similar. So, previous version was the optimal option, and it should be restored but what do you think about the additional option of new button of [zoom] for up to - for example - 110% (for monitors with resolution above Full HD, including 4K)? Subtropical-man (talk / en-2) 19:39, 4 December 2018 (UTC)

I agree 100% with the following:"No need to define the width". Some time ago (probably in the last year) I suggested the width default should be changed to "auto". I was told I needed "consensus" to make this change. I could not find where 90% was the consensus. The thread has probably been archived. The new default of 100% is certainly better than 90% based on the emphasis on supporting smaller screens (no space wasted on margins) but I still feel auto would be better. --User-duck (talk) 17:32, 15 December 2018 (UTC)

P.S. The template documentation needs to be updated with the new default. Since I am unsure of the final resolution. I will not do it now. --User-duck (talk) 17:32, 15 December 2018 (UTC)

I also suggest the width default should be changed to "auto" (automatic adjustment of weatherbox to the screen resolution) but if for years option of "90%" was functioning, maybe can not set the auto option. If anyone can changed to "auto", please do it. If not, will be necessary to restore the previous version functioning for years. Subtropical-man (talk / en-2) 22:00, 17 December 2018 (UTC)

Explanation Needed

I thought Average Precipitation was the total sum of Average Rainfall and Average Snowfall, but it looks like a different mathematical equation is being used to estimate Average Precipitation. For example, in Iqaluit, May has 0.122 inches of rain and 10.87 Inches of Snow, so precipitation must be 10.992, but it actually has 1.15. I'm guessing it has something to do with the amount of space snow makes after it melts but that still leaves the question: What is the math behind Average Precipitation? — Preceding unsigned comment added by 69.206.181.191 (talk) 02:55, 15 December 2018 (UTC)

First the snow is measured in cm and the rain in mm. The snow amount has to be converted to mm. If you can collect the snow in snow gauge then you can melt it and measure the amount of liquid. If you can't collect the snow then you would be using estimates. Normally you would divide the amount of snow (cm) by 10 to get the mm value. Looking at the measurements from today at Cambridge Bay I got 1.6 cm, 0.8 cm and 0.4 cm over an 18 hour period. They melted down to 1.4 mm, 0.6 mm and 0.4 mm. You can get larger amounts depending on the size of the snow flake. I see one from last week where they had 2.2 cm of snow that melted to 1.4 mm of liquid. So there is no exact formula to be used. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 03:25, 15 December 2018 (UTC)

I don't understand why metric conversion was necessary for this. Changing a 1cm to a 10mm just to comparing it to a 20mm is unnecessary if they are already 0.4in and 2.5in respectively. And even if we do do that, (Looking at Cambridge Bay's weather box for may's precipitation) it doesn't explain how a 7.2cm (72mm) (snow) and a 1mm (rain) makes a 7mm (Precipitation). Does the 72 subtract to 6? What about the months with no precipitation other than snow? January get's 67mm of snow but it amounts to 5.8mm in total precipitation, December get's 68mm of snow but it amounts to 6.1mm in total precipitation, And April get's 69mm of snow but that only amounts to 5.7mm. So of the three months, April get's the most snow and the least precipitation, December gets the most precipitation, and January get's the least of Snow, even though all of these's snow should be the same as there precipitation since none of these three months have any rain. I find this to be a huge issue because some weather boxes of some pages only give information on total precipitation and snowfall. See example here https://wiki.riteme.site/wiki/New_York_City#Climate How can I accurately figure out the amount of rain each month receives using the available information? — Preceding unsigned comment added by 69.206.181.191 (talk) 00:05, 16 December 2018 (UTC)

Sorry I went with metric because I have no clue how it works in inches. I would guess the same but it might not be. If you estimate the snow then you always divide by 10. However, snowflakes can be different in size, "from the width of a human hair to less than that of a penny." Now if the flakes are the size of a penny they will take up more space in the snow gauge (copper tube) than would snow flokes that are a half of that size. So six hours of snow the size of a penny may take up 2 cm (0.79 in). Because you have measured the snow you don't divide by 10 you actually melt the snow. Melting it may be equal to 2 mm (0.079 in) but it may melt to equal 1.8 cm (0.71 in). For places like your example you can't calculate the rain based on the snow and total precipitation. You would need to find a source that gives the amount of rain that fell in a month. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 06:32, 18 December 2018 (UTC)

All fields are optional?

It seem the statement is false. For the weather box in Shau Kei Wan, i scrapped the entire weather box due to mostly not in source issue (no monthly data), but when i left the year record high/low data in the weather box which appears in the citation, the box stop working. Also, the citation had year to year average, but i am afraid it would be WP:OR for crafting decade average. Matthew hk (talk) 00:56, 25 December 2018 (UTC)

See also Tai Po#Climate. The year record high/low are known but no monthly record. The table is not properly displayed. Matthew hk (talk) 01:07, 25 December 2018 (UTC)

@Matthew hk: The table in Tai Po § Climate looks fine to me. What's wrong with it? — Eru·tuon 01:42, 25 December 2018 (UTC)

The record max high / low data, which only yearly high was obtainable from the citation [7], but not the record max high of the specific month. If the table claimed it was all optional, it should display a blank record high/low row, with exception of the the last cell. Not the entire row is missing. Matthew hk (talk) 01:45, 25 December 2018 (UTC)

Yeah, the template only checks for the monthly values when deciding whether to display a row. — Eru·tuon 02:03, 25 December 2018 (UTC)

Refactor module to use Value object

@Jonesey95 and Erutuon: Re the discussion above, I have refactored Module:WeatherBox/sandbox to use an object called Value to hold the properties of each value (number, string, precision, formatted text for display). That reduces the amount of duplication in the module with many calculations now done once in Value. The new sandbox displays significant trailing zeroes. Please check the testcases and let me know what you think. I have some other plans but want to sort this out first. Johnuniq (talk) 01:35, 28 December 2018 (UTC)

Looks like an improvement to me. – Jonesey95 (talk) 17:07, 28 December 2018 (UTC)

I had to stop fiddling with it sooner or later so I have updated Module:WeatherBox after carefully checking the testcases. Johnuniq (talk) 09:03, 29 December 2018 (UTC)

I reverted my change to the module because it put errors in many articles because the code to format trailing zeroes did not account for the fact that the following can give negative values for p.

p = I_values[i]:getPrecision() - 1
p = I_values[i]:getPrecision() - 2

It would be easy to put in some code to workaround that but I'll leave it for now and try and understand why 1 and 2 are being subtracted and whether the negative precision might have any other bad effect. Johnuniq (talk) 09:41, 29 December 2018 (UTC)

I have done yet more tweaking of the code and have updated the main module with the results. It gives more accurate conversions. We'll have to see if any problems occur. Johnuniq (talk) 23:01, 5 January 2019 (UTC)

Average wind speed

Could we add another thing for average wind speed? Alex of Canada (talk) 02:32, 22 August 2018 (UTC)

I think we need this one especially for locations frequently visited by tropical cyclones. --Exec8 (talk) 05:53, 6 January 2019 (UTC)

Suggestion: trace precipitation should show up as "T", not as "—"

An example of why the current format is weird can be found at Template:Chicago_weatherbox:

Climate data for Chicago (Midway International Airport), 1991–2020 normals, extremes 1928–present
Month	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec	Year
Record high °F (°C)	67 (19)	75 (24)	86 (30)	92 (33)	102 (39)	107 (42)	109 (43)	104 (40)	102 (39)	94 (34)	81 (27)	72 (22)	109 (43)
Mean maximum °F (°C)	53.4 (11.9)	57.9 (14.4)	72.0 (22.2)	81.5 (27.5)	89.2 (31.8)	93.9 (34.4)	96.0 (35.6)	94.2 (34.6)	90.8 (32.7)	82.8 (28.2)	68.0 (20.0)	57.5 (14.2)	97.1 (36.2)
Mean daily maximum °F (°C)	32.8 (0.4)	36.8 (2.7)	47.9 (8.8)	60.0 (15.6)	71.5 (21.9)	81.2 (27.3)	85.2 (29.6)	83.1 (28.4)	76.5 (24.7)	63.7 (17.6)	49.6 (9.8)	37.7 (3.2)	60.5 (15.8)
Daily mean °F (°C)	26.2 (−3.2)	29.9 (−1.2)	39.9 (4.4)	50.9 (10.5)	61.9 (16.6)	71.9 (22.2)	76.7 (24.8)	75.0 (23.9)	67.8 (19.9)	55.3 (12.9)	42.4 (5.8)	31.5 (−0.3)	52.4 (11.3)
Mean daily minimum °F (°C)	19.5 (−6.9)	22.9 (−5.1)	32.0 (0.0)	41.7 (5.4)	52.4 (11.3)	62.7 (17.1)	68.1 (20.1)	66.9 (19.4)	59.2 (15.1)	46.8 (8.2)	35.2 (1.8)	25.3 (−3.7)	44.4 (6.9)
Mean minimum °F (°C)	−3 (−19)	3.4 (−15.9)	14.1 (−9.9)	28.2 (−2.1)	39.1 (3.9)	49.3 (9.6)	58.6 (14.8)	57.6 (14.2)	45.0 (7.2)	31.8 (−0.1)	19.7 (−6.8)	5.3 (−14.8)	−6.5 (−21.4)
Record low °F (°C)	−25 (−32)	−20 (−29)	−7 (−22)	10 (−12)	28 (−2)	35 (2)	46 (8)	43 (6)	29 (−2)	20 (−7)	−3 (−19)	−20 (−29)	−25 (−32)
Average precipitation inches (mm)	2.30 (58)	2.12 (54)	2.66 (68)	4.15 (105)	4.75 (121)	4.53 (115)	4.02 (102)	4.10 (104)	3.33 (85)	3.86 (98)	2.73 (69)	2.33 (59)	40.88 (1,038)
Average snowfall inches (cm)	12.5 (32)	10.1 (26)	5.7 (14)	1.0 (2.5)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.1 (0.25)	1.5 (3.8)	7.9 (20)	38.8 (99)
Average precipitation days (≥ 0.01 in)	11.5	9.4	11.1	12.0	12.4	11.1	10.0	9.3	8.4	10.8	10.2	10.8	127.0
Average snowy days (≥ 0.1 in)	8.9	6.4	3.9	0.9	0.0	0.0	0.0	0.0	0.0	0.2	1.6	6.3	28.2
Average ultraviolet index	1	2	4	6	7	9	9	8	6	4	2	1	5
Source 1: NOAA, WRCC
Source 2: Weather Atlas (UV)

Climate data for Chicago (O'Hare Int'l Airport), 1991–2020 normals, extremes 1871–present
Month	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec	Year
Record high °F (°C)	67 (19)	75 (24)	88 (31)	91 (33)	98 (37)	104 (40)	105 (41)	102 (39)	101 (38)	94 (34)	81 (27)	71 (22)	105 (41)
Mean maximum °F (°C)	52.3 (11.3)	56.8 (13.8)	71.0 (21.7)	80.9 (27.2)	88.0 (31.1)	93.1 (33.9)	94.9 (34.9)	93.2 (34.0)	89.7 (32.1)	81.7 (27.6)	67.0 (19.4)	56.4 (13.6)	96.0 (35.6)
Mean daily maximum °F (°C)	31.6 (−0.2)	35.7 (2.1)	47.0 (8.3)	59.0 (15.0)	70.5 (21.4)	80.4 (26.9)	84.5 (29.2)	82.5 (28.1)	75.5 (24.2)	62.7 (17.1)	48.4 (9.1)	36.6 (2.6)	59.5 (15.3)
Daily mean °F (°C)	25.2 (−3.8)	28.8 (−1.8)	39.0 (3.9)	49.7 (9.8)	60.6 (15.9)	70.6 (21.4)	75.4 (24.1)	73.8 (23.2)	66.3 (19.1)	54.0 (12.2)	41.3 (5.2)	30.5 (−0.8)	51.3 (10.7)
Mean daily minimum °F (°C)	18.8 (−7.3)	21.8 (−5.7)	31.0 (−0.6)	40.3 (4.6)	50.6 (10.3)	60.8 (16.0)	66.4 (19.1)	65.1 (18.4)	57.1 (13.9)	45.4 (7.4)	34.1 (1.2)	24.4 (−4.2)	43.0 (6.1)
Mean minimum °F (°C)	−4.5 (−20.3)	0.5 (−17.5)	11.8 (−11.2)	25.6 (−3.6)	36.7 (2.6)	46.0 (7.8)	54.5 (12.5)	54.3 (12.4)	41.8 (5.4)	29.7 (−1.3)	17.3 (−8.2)	3.2 (−16.0)	−8.5 (−22.5)
Record low °F (°C)	−27 (−33)	−21 (−29)	−12 (−24)	7 (−14)	27 (−3)	35 (2)	45 (7)	42 (6)	29 (−2)	14 (−10)	−2 (−19)	−25 (−32)	−27 (−33)
Average precipitation inches (mm)	1.99 (51)	1.97 (50)	2.45 (62)	3.75 (95)	4.49 (114)	4.10 (104)	3.71 (94)	4.25 (108)	3.19 (81)	3.43 (87)	2.42 (61)	2.11 (54)	37.86 (962)
Average snowfall inches (cm)	11.3 (29)	10.7 (27)	5.5 (14)	1.3 (3.3)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.2 (0.51)	1.8 (4.6)	7.6 (19)	38.4 (98)
Average extreme snow depth inches (cm)	6.3 (16)	6.3 (16)	4.0 (10)	0.6 (1.5)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	0.0 (0.0)	1.5 (3.8)	3.9 (9.9)	9.8 (25)
Average precipitation days (≥ 0.01 in)	11.0	9.4	10.8	12.3	12.5	11.1	9.7	9.4	8.5	10.5	10.0	10.6	125.8
Average snowy days (≥ 0.1 in)	8.5	6.4	4.0	1.0	0.0	0.0	0.0	0.0	0.0	0.2	1.6	6.1	27.8
Average relative humidity (%)	72.2	71.6	69.7	64.9	64.1	65.6	68.5	70.7	71.1	68.6	72.5	75.5	69.6
Average dew point °F (°C)	13.6 (−10.2)	17.6 (−8.0)	27.1 (−2.7)	35.8 (2.1)	45.7 (7.6)	55.8 (13.2)	61.7 (16.5)	61.0 (16.1)	53.8 (12.1)	41.7 (5.4)	31.6 (−0.2)	20.1 (−6.6)	38.8 (3.8)
Mean monthly sunshine hours	135.8	136.2	187.0	215.3	281.9	311.4	318.4	283.0	226.6	193.2	113.3	106.3	2,508.4
Percent possible sunshine	46	46	51	54	62	68	69	66	60	56	38	37	56
Source: NOAA (relative humidity, dew point and sun 1961–1990)

References

Notes

You can see that for May, a trace of snow shows up as a single dash, whereas months with any other value show two values (metric and imperial). To me, this makes it look like there is missing data for that month, rather than a value of "trace". Indeed, it appears as if this template is not equipped to handle "trace" or "T" as a value, so this is a default response to non-numerical entries in the table.

Since this template is used on so many pages I'm putting this forth as a suggested edit rather than being bold and doing it myself, but this seems like it would be a non-controversial addition to me. -RunningOnBrains^(talk) 18:52, 30 January 2019 (UTC)

I did a lot of maintenance on Module:WeatherBox but have no particular knowledge of this topic. As you say, a dash is displayed if a cell does not contain a number. Are you sure that "trace" and "T" are understandable entries? In practical terms, what is the difference between "trace" and "0"? By the way, when working on the module I wondered why an em dash was used (instead of an en dash) but I decided to continue with what was there before. Johnuniq (talk) 03:13, 31 January 2019 (UTC)

Runningonbrains being as this is Wikipedia of course the use of the letter T would turn out to be controversial. It would seem that "T" is the abbreviation for trace in the US (What is a "Trace" of Precipitation?) but in Canada, "TR" is the abbreviation for trace (MANAB Manual of Word Abbreviations. I don't know which is predominant worldwide and it might be better to just use "trace". Johnuniq in metric countries a trace is any amount of precipitation that is less than 0.2 mm (Glossary) and in the US it is anything less than 0.01 inch (What is a "Trace" of Precipitation?). The difference between trace and 0 is that for zero there has to have been no precipitation at all. On the other had it could rain or snow for a while but you don't get the required 0.2 mm or 0.01 inch and it is a trace. An extreme example of this is in the Arctic diamond dust (we call them ice crystals) can fall for days on end but never accumulate and are always a trace. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 05:39, 1 February 2019 (UTC)

OK, but I have no opinion on whether anything should be done. The year values can be specified or, if not, are calculated. Presumably any occurrences of "trace" should be ignored for that. If anyone wants this, I think a specific proposal should be made with a reasonable consensus for implementation. If so, I could look at what would be involved. Johnuniq (talk) 05:54, 1 February 2019 (UTC)

Johnuniq and CambridgeBayWeather I am working on an article (surprised one did not already exist, as this is a fairly basic meteorological topic) for precipitation "traces", and it provides sourced answers to your questions (you can see the draft here: User:Runningonbrains/Trace (precipitation)) aside from the question of which abbreviation is standard (T vs TR). Presuming it is different standards in different countries, could a simple switch be built in? It seems as if using the entire word "trace" would be too wide for most tables. -RunningOnBrains^(talk) 19:27, 4 February 2019 (UTC)

The word "trace" should fit even without reducing its font size and would be much more desirable than jargon like T or TR. It works in the examples above as can be seen here:

(31.2)
trace

An article would be good but more important for this proposal is getting a discussion somewhere other than here (a wikiproject?) showing a consensus that "trace" should be supported as an input and output. Johnuniq (talk) 21:45, 4 February 2019 (UTC)

Thanks for posting at Wikipedia_talk:WikiProject_Meteorology#Adding_"trace"_or_"T"_to_Template:Weather_box; that was going to be my suggestion. Unfortunately the project isn't very active these days.

I can't imagine the capability itself would be controversial though, it is an official term used in official statistics. You can see it in the references of the table I linked above, in addition to the sources I've provided in my article draft.-RunningOnBrains^(talk)

OK, I look at it soon but things are hectic here. If I don't return within a week, please ping me. Johnuniq (talk) 22:48, 7 February 2019 (UTC)

@Runningonbrains: I implemented "trace" in the sandbox, use {{Weather box/sandbox}} to test. See example at Template:Weather box/testcases#Trace. The word "trace" (has to be exactly like that) is accepted for input. When calculating the year values, a trace counts as zero. The text displayed can be set with a parameter, for example, |trace=TR. Please try it out. If this is wanted, the new parameter ("trace") has to be added to the template so it is not an unknown parameter. A bad feature is that "trace" can be entered anywhere, such as for a temperature. I'll think about that. Johnuniq (talk) 09:26, 9 February 2019 (UTC)

Im late to the party but I definitely support this, because the difference between a trace of snow and no snow is significant. I dont think people will start putting "trace" where it doesnt belong, and if they do, it would be easy to spot and quick to revert (whether it was a mistake or vandalism). —Soap— 16:45, 6 March 2019 (UTC)

I'm not sure why there hasn't been any testing of the sandbox template per above but the code should be good and I will put it in the main module in due course (sooner if requested). There is a bit of a distraction in the request move section below. Johnuniq (talk) 23:06, 6 March 2019 (UTC)