Wikipedia talk:WikiProject Weather/Archive 2

There is a GAR for this article. 47.23.6.178 (talk) 20:40, 23 April 2023 (UTC)

Storm surge has been nominated for a good article reassessment. If you are interested in the discussion, please participate by adding your comments to the reassessment page. If concerns are not addressed during the review period, the good article status may be removed from the article. ~~ AirshipJungleman29 (talk) 11:05, 1 May 2023 (UTC)

Personally, I opt for an inclusion of both as in this previous version. One argument used by an editor for TWC over NCEI was, "NCEI won’t mark car crash death tolls". Well, I know that is factually incorrect as NCEI actually marked one of the TWC car crash deaths as an indirect death (February 1 in Oklahoma). It is obvious NCEI does look at car crash deaths, they are just considered indirect deaths in this case. Showing both NCEI (the official death toll of 0) and TWC (RS Media direct death toll of 10) in the infobox is the best way to minimize error. Thoughts?

I would strongly suggest that you look through the sources carefully and go with the most accurate death toll that the majority of sources use. One thing I will say though is that TWC would report on a death toll while the event is very fresh, while the NCEI tends to report well after the event.Jason Rees (talk) 12:55, 27 May 2023 (UTC)

Most sources support the death toll of ten, one of which includes AP News (and a NYT article that should be on the talk page.) Common sense should be used. 98.113.8.17 (talk) 15:41, 27 May 2023 (UTC)

Are we seriously about to say The Weather Channel is more reliable than NCEI? Like we have had this discussion SO many times I feel like in terms of X media vs NCEI. We always use NCEI since that is the (per the National Weather Service) location for official information. NWS actually confirmed d that principle earlier this year ([4][5][6]NWS Directives PDF) We already had a discussion about when NCEI damage totals are different that other source damage totals (i.e. Aon in this discussion). Every time NCEI vs X source comes up, socks get involved, hence why the Aon one vs NCEI actually got voided. Aon’s side had socks trying to stack the vote. That said, prior to the void due to sock puppetry on the side of Aon, a good compromise was made after a very experienced editor, who also worked in the insurance sector, participated in the discussion.

1. Aon damage totals are a reliable source for damage total information (RS Noticeboard discussion conclusion) and can be added to an article's content.
2. Aon damage totals are acceptable for an articles/storms infobox if NOAA has not published a damage total.
3. Aon damage totals are acceptable for an articles/storm infobox if a NOAA NCDC damage total is also present. This would have both damage totals in the infobox (format done to this article, Tornado outbreak of March 21–23, 2022.
4. Aon damage totals are ok for an article's content (aka text portion of the article), but should not be added in the infobox if a NOAA Billion-Dollar Weather and Climate Diasters damage total is present, due to RS use of it over the Aon damage total.

While this discussions isn’t about Aon damage totals vs NCEI damage totals, there is a principle to it. The overall conclusion was still NOAA/NCEI used the infobox and disagreements got published in the text portion of the article OR even in the infobox as a second entry. When there was a debate about TWC vs NCEI, I attempted to use this discussions general outcome of putting both in the infobox. That motive seemed to not work. I really don’t want to go to an RfC over this because this overall principle of NOAA being official is used on multiple articles, especially tropical cyclone articles. For example,

talk

) 15:58, 27 May 2023 (UTC)

And this relates to the topic at hand…how?47.20.183.20 (talk) 20:20, 30 May 2023 (UTC)

Because of the following reasons. (1) There has been previous consensus that if a disagreement between the official information and other sources exist, both are suitable, together, in the infobox and (2) that NCEI does in fact track the deaths mentioned by TWC, but officially marked them as indirect deaths, while TWC marked them as direct. The original split NCEI/TWC death toll mentioned and proposed above solves all the problems of NCEI vs TWC. I'm not sure why so many anonymous editors are determined to remove NCEI from Wikipedia, but overall consensus (when the rule-breaking accounts are excluded) seems to indicate that NCEI can co-exist with other sources in an infobox.

talk

) 20:53, 30 May 2023 (UTC)

Both can be included if properly conveyed. For the infobox it would be "Fatalities: 0 (per NCEI), 10 (per [relevant source(s)])", with the appropriate sources attached as suggested in that edit diff. We're not bound to using a single source, especially if concrete reasonings for the exclusion of reported deaths is not given. It's known that NCEI is prone to human error given the sheer volume of information that is being compiled into the database so things can slip through the cracks even in the present day (namely local offices not submitting their reports on time and that info not making it in). In regards to Hermine, I contacted the NHC and they explicitly stated the deaths were attributed to squalls ahead of Hermine and not directly associated with the storm thus we can go with no fatalities. However, given extensive media reporting the incidents are kept in the article and marked as not caused by Hermine for the full picture. Multiple avenues can be explored as there's no one-size-fits-all solution to many of these situations. ~ Cyclonebiskit (chat) 21:02, 30 May 2023 (UTC)

Exactly! The proposal for having both NCEI and X media sources listed in the infobox actually is best as it shows both sides; official and

talk

) 21:06, 30 May 2023 (UTC)

Caution should be exercised when classifying fatalities from news sources. There's nothing on the Weather Channel page that specifically says the deaths are direct or indirect. It is worth noting that nine of the fatalities noted on the Weather Channel are listed in the NCEI database (3TX + 1TX + 1TX + 1TX + 1TX + 1OK + 1OK) so to say that NCEI asserts that the storm caused no fatalities seems erroneous; the infobox makes no differentiation between direct or indirect fatalities (nor does the

@TheAustinMan: Isn't it the NCEI doesn't state that the storm caused any fatalities rather than the NCEI states that the storm caused no fatalities? Noah^Talk 13:40, 31 May 2023 (UTC)

@

Elijahandskip's initial statement that The National Centers for Environmental Information (NCEI) posted that no deaths were documented from this ice storm, which isn't accurate per the links I previously provided. –TheAustinMan^{(Talk ⬩ Edits}

) 14:44, 31 May 2023 (UTC)

Last year, editors outside the project discussed our storm "disambiguation" categories and decided to move them to "set index" because these pages are set index articles not disambiguations since they provide more than just navigation. They use the set index template "storm index". I would like to move pages within Category:Set index articles on storms to List of storms named X to reflect that these are indeed lists and not disambiguations. This is the most concise title that's possible and takes into account that not every named storm will be a TC. Around 100 pages currently exist at such a title while around 600 or so do not. I also would like to change the class on all the talkpages to SIA from DISAMBIG to reflect this as well. If everyone is okay with this, I will handle all the required work for it. Noah^Talk 14:36, 1 June 2023 (UTC)

I’d personally rather have all of these SIA be merged into “List of named storms” by letter, but that’s an unpopular opinion. If you don’t mind doing the work, sure, go ahead, this has been an issue for a while now, so good to finally get it done. Thanks in advance for you being proactive. Hurricanehink mobile (talk) 15:21, 1 June 2023 (UTC)

For the past few days, I've been seeing

Well, yes, I have been moving a LOT of index articles in a

💬✍

00:38, 2 June 2023 (UTC)

@

TheQuestionMark: has been moving have needed to be moved away from being TC based for ages since TCs are not the only storms to be routinely named. I just wish we could move them all at once and encourge users to use them to describe names assigned by TWC, UKMO, MetEirrean, Meteo France etc. Jason Rees (talk

) 19:58, 3 June 2023 (UTC)

I realize I'm a newbie in this Wikipedia world, but this isn't about my status as an editor and contributor. And I'm not saying I'm perfect. If any of my edits are perceived as truly clunky, mea maxima culpa, and I'll atone for my sins; however, this "posthumous rating" thing isn't subjective in nature. Dym75 (talk) 05:19, 11 June 2023 (UTC)

Hi, folks. I wanted to introduce myself: I'm David, I have a degree in journalism (so I can write rather well), and I also have a significant interest in weather, particularly tornadoes. I hope to get more involved with the process of researching, writing, and editing tornado articles (and others, as time permits). Since I'm rather new to the concept of creating articles, I asked at the Teahouse and was advised this might be a good place to share this information.

In recent weeks, I've done a tremendous amount of research (and there's more to do) so I can write some tornado-related articles - specifically, list pages that organize notable/significant tornadoes by path length, width, damages, and death tolls).

I'm also currently working on a list page for tornadoes in the Commonwealth of Massachusetts. My home state tends to be stuck at the kids' table when it comes to severe weather, so I'd like to share our tornadic history with those who are interested. If I can find the time, I'd also like to create similar articles on the Northern New England states (Maine, New Hampshire, and Vermont).

If anyone is interested in collaborating on these (whether you've already started or you'd like to join me), please let me know. Thank you! Dym75 (talk) 20:27, 1 May 2023 (UTC)

Hey @

Elijahandskip, TornadoLGS, and Wxtrackercody: who will be able to help you navigate the wiki and help develop the lists that you mention by pushing you in the right direction. I am also intrigued to see that you have a degree in journalism and may ask you to copyedit a few articles in the future if I need it.Jason Rees (talk

) 13:52, 27 May 2023 (UTC)

@Dym75: Welcome the club brother! ChessEric 22:17, 27 May 2023 (UTC)

Thank you @Jason Rees and @ChessEric :-) Dym75 (talk) 21:48, 5 June 2023 (UTC)

Quick, stupid question, @Jason Rees and @ChessEric:

Are we supposed to be entering dates as mmddyyyy or ddmmyyyy? I found most of my article switched from March 18, 1925 or May 22, 2011 to 18 March 1925 or 22 May 2011 etc, etc.

The reason for my confusion is because, when I entered dates as 22 May 2011 in other articles, I was corrected and it was changed to May 22, 2011.

Which one of these is actually correct? In advance, thank you. Dym75 (talk) 21:54, 5 June 2023 (UTC)

@Dym75: Both are correct in theory as it comes down to what the country the article is related to uses, for example, a TC impacting the US will usually be written in MDY while a TC impacting Australia is in DMY.Jason Rees (talk) 22:09, 5 June 2023 (UTC)

What Jason said. XD ChessEric 00:50, 6 June 2023 (UTC)

Since there's both US and other countries in this TC(?), I'll go with DMY (I'm sure the US folk can adjust). I had a feeling this might be your answer (depends on the country), but I'm glad I got confirmation. Thank you! @Jason Rees @ChessEric Dym75 (talk) 03:19, 6 June 2023 (UTC)

BTW, @Jason Rees, if you do want me to review any articles, please let me know. Happy to help where I can. Dym75 (talk) 22:26, 11 June 2023 (UTC)

Howdy David! Can't wait to see how you contribute! New England tornadic events are super compelling yet underdeveloped, so I'm really glad to hear you have interest there. Happy editing :) Wikiwillz (talk) 15:32, 6 June 2023 (UTC)

I have created a draft for a currently ongoing derecho, with a possible tornado outbreak. There has been a MDT risk issued by the SPC. If you would like to contribute, please do so.

@Hurricane Noah and Chlod: The new Infobox for individual tornadoes is not displaying fatalities or damages. Any way this could be fixed? 71.125.62.17 (talk) 14:47, 17 June 2023 (UTC)

Fatalities and damages must be displayed with {{Infobox weather event/Effects}} (used alongside the /Tornado sub-box) and not with any other template. Any other method is incorrect use of the templates. The relevant documentation page (linked) has the proper information on how the data can be supplied. Chlod (say hi!) 14:53, 17 June 2023 (UTC)

Figured it out. Thanks! 71.125.62.17 (talk) 14:54, 17 June 2023 (UTC)

No problem; feel free to reach out if you have any additional questions. Chlod (say hi!) 14:55, 17 June 2023 (UTC)

 You are invited to join the discussion at Wikipedia talk:Content assessment#Proposal: Reclassification of Current & Future-Classes as time parameter, which is within the scope of this WikiProject. This WikiProject received this message because it currently uses "Current" and/or "Future" class(es). There is a proposal to split these two article "classes" into a new parameter "time", in order to standardise article-rating across Wikipedia (per RfC), while also allowing simultaneous usage of quality criteria and time for interest projects. Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:11, 1 July 2023 (UTC)

I have nominated

While copy/editing List of United States tornadoes in 1946, Argenti Aertheri asked about introducing a new tornado chart.

Current

Proposed

Outline for proposed code:

{| class="wikitable" 
 |+ Caption text 1
 |- 
 ! rowspan="2" | F# !! Location !! Time 
 |-
 ! colspan="2" | Summary
 |-
 | rowspan="2" | F4 || Texas || 18:00 
 |-
 | colspan="2" | Summary text
 |}

Or in HTML

<table class="wikitable">
  <caption>Caption text</caption>
  <tr>
    <th rowspan="2">F#</th>
    <th>Location</th>
    <th>Time</th>
  </tr>
  <tr>
    <th colspan="2">Summary</th>
  </tr>
  <tr>
    <td rowspan="2">F4</td>
    <td>Texas</td>
    <td>18:00</td>
  </tr>
  <tr>
     <td colspan="2">Summary text</td>
  </tr>
</table>

Either will display:

}}

I honestly really like the new proposed format. One thing to note, this original nor the proposed do not include coordinates as this is pre-1950 related tornadoes in which the proposal was made. We have a few options of how we could “test” the proposed format:

1. Test it on an article (like List of United States tornadoes in 1946) and then do an RfC to see which format is liked better throughout the community.
2. Decide to use the proposed format for pre-1950 tornado articles only. This would be since there are no start coordinates like in 1950–present articles.
3. Do the second option, then hold a RfC to see if the community would prefer the proposed charts for 1950–present articles, or if it should be a pre-1950 only chart.
4. Decide the proposed chart would not be feasible at all.

What is everyone’s thoughts about testing the proposed chart or even fully converting to it? WeatherWriter (talk) 15:16, 27 June 2023 (UTC) WeatherWriter (talk) 15:16, 27 June 2023 (UTC)

Unfortunately the proposed table wouldn't work as it fails MOS criteria. Having two types of rows spanning multiple columns makes it difficult for text readers and it also breaks sorting capabilities. However, our current tables need a minor update to fully adhere to MOS: application of !scope=row on the first cell which would require the E/F# column to shift in order to keep the background coloring. I've applied them to List of tornadoes in the tornado outbreak of May 4–6, 2007 per the ongoing FLC. ~ Cyclonebiskit (chat) 17:07, 27 June 2023 (UTC)

I just looked at the charts on List of tornadoes in the tornado outbreak of May 4–6, 2007 and they look so unnatural. Why again does the current charts fail MOS:Application since it just moves charts. The first column is still colored (grey) on the May 4–6, 2007 article. Seems all it did was make the chart visually unnatural and unappealing. Something needs to be done though since you say the current charts fail MOS and your solution can’t possible be the best option. WeatherWriter (talk) 17:15, 27 June 2023 (UTC)

As a user on an IPad, the May 4–6, 2007 article is so much worse than the currently (original) or the proposed layout. The EF5 is like impossible to actually read. I even switched to desktop layout on the IPad and it is still impossible to read. I can take a screenshot and use the commons (there is a method for Wiki screenshots that are allowed on the commons for discussions like this) if needed. I’m fairly sure that layout only works for actual PC desktop layouts. That 100% needs to be fixed either back to the original or whatever layout comes from this discussion, but it cannot stay like that. WeatherWriter (talk) 17:25, 27 June 2023 (UTC)

There is how I see that May 4–6, 2007 layout. Like it possibly cannot pass MOS criteria at all. I can actually see both the original and proposed layouts from above in full. WeatherWriter (talk) 17:32, 27 June 2023 (UTC)

Regarding the specific order of the columns, I took some inspiration from how NWS Norman organizes their tornado tables. They place locations first, followed by path length/width, and then list the E/F#. The logic I went with is place all the location identifiers together (towns/cities, county, state, coordinates) then put the statistics (E/F#, path length/width). Shifting that single column farther right shouldn't change anything with the size of the columns on tablet/mobile, none of the forced column widths are adjusted. I use mobile to check in on things, not edit, and the tables have always been hard to read without putting it in desktop mode. Due to the size of the tornado tables they have always been unwieldy on tablet and mobile. While your proposed version provides greater width to make reading the summary easier on non-desktop (I do like that part), to my knowledge it doesn't satisfy MOS:ACCESS. The addition of !scope=row forces the cell to become gray but that cannot be changed to another color. class="wikitable sortable plainrowheaders" was used to prevent the unnecessary automatic bolding. Regarding it "look[ing] so unnatural", that's just because we're so used to the E/F# column being first as it has been that way for 15+ years. It's similar to the issue we had with changing the category colors, change seems unnatural/uncomfortable at first. Pinging @PresN: as they're more knowledgeable in the formatting and guided me to make the adjustments. ~ Cyclonebiskit (chat) 17:52, 27 June 2023 (UTC)

Turns out you can apply !scope and keep the colors, use style="background-color:#{{#invoke:Storm categories|color|cat4}}" instead of bgcolor="{{storm colour|cat4}}" ~ Argenti Aertheri (talk) 00:20, 28 June 2023 (UTC)

Yes, to be clear: adding the rowscope does one invisible thing (flags the cell as the row reader, which screen reader software uses for ease of non-visual table navigation) and one visible thing (changes the formatting to be visually emphasized, just like column headers are). It wouldn't change column sizing.

The reason to swap the column order (which also wouldn't change column sizing) is that, just like how "column headers" are at the top of the column and distinctly define that column, a row header cell should be at the start of the row, and define that row. We don't, strictly speaking, enforce that, but 1) it's weird for the row header to not be the first cell and 2) since the row header should define the row, just like with column headers you don't want a lot of duplicates. If there's an easier column that is pretty unique per row, like location, it's better to make that the row header (and therefore the first column). --PresN 00:23, 28 June 2023 (UTC)

I don’t know if it’s possible to keep the background coloring while using !scope=row, I’ll play with it more tonight. Sorting is fixed though, and there’s a working copy in my personal sandbox. I hope putting it there is appropriate, I didn’t want to turn the discussion into just line after line of code. ~ Argenti Aertheri (talk) 22:19, 27 June 2023 (UTC)

(edit conflict, though it looks like you got it just above) It definitely is! Ignoring what I said above about not having the F# as the first/header column, to do so, in the table classes (where you put e.g. "sortable"), add "plainrowheaders" - that drops the background color and bolding, so your custom colors should show up instead. You can also add whatever css style code you want to make the text change (e.g. I think it leaves it centered, so you could do !scope=row bgcolor="whatever" style="text-align:left;" | text) --PresN 00:23, 28 June 2023 (UTC)

I pleasantly stand corrected then. If it satisfies MOS requirements I'm all for the proposed style. It gives greater flexibility with summary length and opens the door for images to be added in to break up the monotony of the tables. ~ Cyclonebiskit (chat) 00:56, 28 June 2023 (UTC)

I went ahead and implemented it into the List of tornadoes in the tornado outbreak of May 4–6, 2007 so we have a good idea of what it would look like in full form. I also modified the proposal slightly, removing plainrowheaders in favor of bringing back the bold and adding style="border-bottom: 1px solid black" to every tornado to help with visually differentiating the tornadoes. Pinging frequent tornado table editors for further input: @United States Man, ChessEric, Wxtrackercody, ChrisWx, Tornadoesarecool13, CrazyC83, Mjeims, Creeperstomp, Timcigar12, and Supportstorm:~ Cyclonebiskit (chat) 02:15, 28 June 2023 (UTC)

Sorry @TornadoInformation12:, I thought I had you in the mass ping. ~ Cyclonebiskit (chat) 14:52, 28 June 2023 (UTC)

Oh man. I'm not usually against change, but while the formatting and coding within this new chart are impressive, my opinion was asked, and I do not like it. Its a little harder to read the description of the tornado when the path length, width, and location/counties/parishes affected are directly above. It is a little tough on the eyes. It just creates a very thin "strip" for each tornado, and kind of has my eyes going many places. It is easy to understand once you relate tha "columns" and "rows" together and what the information means, but it is slightly easier the way it is. Mjeims (talk) 02:22, 28 June 2023 (UTC) I've changed my mind as well. It indeed captures long, complex tornado paragraphs into the necessary space to be completely visible in a single screen size, greatly improving the convenience to read it and avoid getting lost. It is easy enough to understand the contents and place them when formatting new tornadoes. Should work great in non-PC formats (mobile) as well. Mjeims (talk) 19:03, 28 June 2023 (UTC)

With what Cyclonebiskit did, I wanted to show how the proposed (well test implementation) layout looks compared to the original format. I can tell you it is sooo much better. Unlike before, the entire EF5 chart actually is visible without the need to scroll. This is on an IPad in desktop viewer. I also pulled it up on my PC as well as android phone. No visibile errors at all. Everything seems clear to read. Noting that original, proposed, and previous May 4–6, 2007 format all required the need to scroll right on a phone. The summary section is a lot better to read. WeatherWriter (talk) 02:30, 28 June 2023 (UTC)

The proposed table is ok to me on PC display, even though I do prefer the old table for readability. If it makes it easier to read on mobile devices it's a decent compromise. In the 2007 article you linked as a demonstration, I would prefer we kept dates separate and remove the date column. I feel it's simply easier to edit that way as it segments tables, that could run 100s of entries, into (depending on event) bite sized chunks. Though to clarify, this is not the case in WeatherWriters proposal. I'm sure there are ways to further refine the table that improves readability on both platforms. Supportstorm (talk) 02:49, 28 June 2023 (UTC)

I'm sorry, but I think I like the previous tornado table better. The new table looks cluttered and puts a strain on the eyes, while the previous table looks a bit more clear, with the different sections of the chart more spaced out and everything given more of a designated section, rather than the stats and the description seemingly mixed into the same section. The previous chart feels easier to work with and easier to read, and with the new chart, the stats of the tornado, and the description itself kind of blend in to each other, and it doesn't really look that good as a result. You did good work with the coding for the new chart, but I think we should stick with the old chart in my opinion. ChrisWx (talk - contribs) 02:46, 28 June 2023 (UTC) Changed my opinion, see below. ChrisWx (talk - contribs) 03:07, 28 June 2023 (UTC)

• I’m dropping this here so everyone is able to see. (1) Current on small charts (2) Current on larger chart summaries {EF5} and (3) proposed chart on a larger chart summary {EF5}.

WeatherWriter (talk) 02:57, 28 June 2023 (UTC)

For mobile views (which account for 2/3rds of all English Wikipedia visits), the proposed layout definitely looks much better than the previous. Though in both cases some horizontal scroll is required to view the data, the text is not extremely crammed into around 1/3rds of the screen's horizontal size. The con here is that, for longer summaries, there's some back-and-forth scrolling that has to be done to read the summary, as the cell for the summary expands to the size of the rest of the table (which is greater than the screen's horizontal width due to the amount of columns). But I do feel that the benefit of having the dedicated row for summaries outweights the disadvantages, especially as we're now using much less screen space (and the back-and-forth-scrolling for summaries is minimal compared to the larger vertical scrolls for the tightly-compressed rows). Chlod (say hi!) 03:00, 28 June 2023 (UTC)

You can wrap especially long summaries with

<p style="max-width: calc(100vw - 2.75em);">Summary</p>

to keep it from being wider than your screen, nothing changes when the table isn’t already scrolling horizontally. It isn’t strictly necessary, and does add some complexity to the code. So I don’t know if this is actually useful information ~ Argenti Aertheri (talk) 03:09, 29 June 2023 (UTC)

The inability to read our tables on mobile devices has long been a pet peeve of mine. It should not be difficult to read no matter how you're reading it. Me and Cyclonebiskit had actually drawn up this exact table layout many years ago, but we abandoned it because we couldn't properly format it according to MOS. I strongly support this new proposal since a) it addresses the mobile issue and b) allows for a much expanded summary section, so that when we have huge paragraphs for particularly destructive tornadoes they're not awkwardly stretching the entry north to south. wxtrackercody (talk · contributions) 03:05, 28 June 2023 (UTC)

The new table definitely looks better for mobile view, and I think I probably will get used to the issues distinguishing the statistics on top and the summary of the tornado on the bottom, and reading further, it does include the possibility for doing more, such as including images, so I'm changing my mind. I think the new table should be implemented. ChrisWx (talk - contribs) 03:06, 28 June 2023 (UTC)

I like the new chart. It fits in a lot better and takes up less vertical space. Tornadoesarecool13 (talk) 12:52, 28 June 2023 (UTC)

Eh it’s fine. Not overly crazy about it but y’all are gonna do what you want anyway. My only problem it is numerous versions of the table we currently have across all the different list pages. This is simply adding yet another version to decrease consistency even more. United States Man (talk) 15:27, 28 June 2023 (UTC)

Fair, but I'd rather have them be inconsistently better than consistently worse. Penitentes (talk) 20:26, 28 June 2023 (UTC)

I'm neutral about this. I like the idea of making the summary better to read for mobile users, but it is a little hard on the eyes due to all the lines in said chart. The EF# sorting is also a problem and could confuse readers. ChessEric 01:13, 29 June 2023 (UTC)

• Letting everyone know, I just created Wikipedia:WikiProject Weather/Tornado table layout with the three variations of the charts that can be used (pre-1950 & post 1950 on F and EF scale). The main difference between pre-1950 charts and post-1950 charts is no coords are given for any pre-1950 tornadoes and all pre-1950 tornadoes were given local times from the US Government and academics rather than UTC time. Is there a chance we could request like a 500/30 page protection for the layout page? It can be edit source or view source (if protected) copy/pasted by other users. WeatherWriter (talk) 05:27, 29 June 2023 (UTC)

Issues with new chart

I reverted a change made to the June 2023 list here because of problems associated with renaming of column headers and unnecessary bolding. I feel this was hastily implemented without much strategy. The main problem I have with moving to a second row for the summary is when the columns are sorted manually at the top, the rating splits to cover both rows, resulting in double the amount of "EF0", "EF1", etc. Is there a way to remedy this? United States Man (talk) 17:25, 28 June 2023 (UTC)

United States Man, could you send a screenshot (commons — 3.0 like I did above) of what you mean by “the rating splits to cover both rows”? At least on my end, I did not see any splits in the rating box. There might be some visual error that needs to be reported to Wikipedia:Village pump (technical) if some device (I’m not sure what device you use to edit or read Wikipeida) sees the chart split. WeatherWriter (talk) 17:31, 28 June 2023 (UTC)

Unfortunately, probably not. Wikipedia seems to consider this a feature, not a bug (Help:Sortable tables) ~ Argenti Aertheri (talk) 22:41, 28 June 2023 (UTC)

When ever you choose to sort any column, the rating doubles. This happens on mobile and desktop. United States Man (talk) 17:48, 28 June 2023 (UTC)

Probably some sort of "rowspan" issue or something. ChessEric 17:53, 28 June 2023 (UTC)

Likely. It’s something I’ve seen on and off for years with tables in different content areas (not just weather). Still, I wonder if there is a way to rectify it. United States Man (talk) 18:39, 28 June 2023 (UTC)

Oh that type of spit. Yeah, I’ve seen that before. List of F4 and EF4 tornadoes (2010–2019) has the same type of thing for the 2017 triple EF4 in China. I don’t think there is a way to fix that, but I could be completely wrong. Hopefully someone who knows about the coding side of Wikipedia can say if we can fix that or not. WeatherWriter (talk) 19:53, 28 June 2023 (UTC)

I've put in a message at the village pump to see if there's a fix for this or if it's just a byproduct of the table formatting that we have to deal with. By "deal with" I mean accepting the one bug in favor of the overall greater improvements the table offers. Re: "unnecessary bolding", that's a result of using !scope="row" with "plainrowheaders" not enabled. I opted for that over the non-bold as it aids tornado differentiation with the proposed format, especially in tandem with the thicker line after each event. ~ Cyclonebiskit (chat) 03:22, 29 June 2023 (UTC)

That's fine Cyclonebiskit. I actually always preferred the bolding anyway. United States Man (talk) 03:45, 29 June 2023 (UTC)

Dude...I've asked you about why you bold many times. WHY DIDN'T YOU SAY ANYTHING UNTIL NOW?!?!? ChessEric 04:26, 29 June 2023 (UTC)

To be fair, USM has been consistently against removing bold from EF#s from the beginning (the change was implemented after a FLC in 2013 where the tables were revamped to their current style). There just hasn't been a reason to bring it up until now. ~ Cyclonebiskit (chat) 04:43, 29 June 2023 (UTC)

Images in table works

• I wanted to mention this here as I did some experimentation that seems to not break on any reader version (PC, tablet, and mobile). In the new table discussion, which became implemented, ChrisWx & Cyclonebiskit added that images could potentially be added to the tables to help break up the chart—text block style of the articles. NWS releases released a cool image from an EF1 on June 2, 2023, so I did a test with added it into the chart. Here is the edit which added it into the chart (List of United States tornadoes in June 2023#June 2 event). Basically, it is the image at 100px with no caption. I checked it on mobile, tablet, and PC and there is no issues with the table. Even for a small tornado section that had 6 words, the 100px image barely expanded the tornado section, but for sure broke the monotonous read. Readers are able to click the image and fully expand it as well. Anyone have thoughts about this? The Weather Event Writer (Talk Page) 04:30, 8 July 2023 (UTC)
  • Hmmmmmmmmmmmmmmmmmm...that is clever, but I don't feel like it’s a good idea. ChessEric 13:33, 8 July 2023 (UTC)

    I would note, images would not be for every tornado. But for instance, any of the ones where we have a picture of the tornado itself should probably be added. And, any high-end EF2+ that doesn’t have a breakout section in an article should probably also have a small image (like the highest damage picture). That sets some guidelines for it, so it doesn’t overwhelm readers. But, it would allow for better context for the readers as well as breaking up the monotonous read. The Weather Event Writer (Talk Page) 16:23, 8 July 2023 (UTC)

This is a slippery slope. I’m with ChessEric in not being a big fan of this. United States Man (talk) 00:01, 9 July 2023 (UTC)

I wonder how this will fit in with the accessibility guidelines. Nova Crystallis (Talk) 16:06, 9 July 2023 (UTC)

As long as there’s alt text on the image screen readers shouldn’t have any issues. ~ Argenti Aertheri^(Chat?) 02:23, 10 July 2023 (UTC)

I originally proposed this a while back and have been putting around with the idea for a while. Images in tables are not uncommon across Wikipedia and in many cases it can enhance the tornado summaries. With the more flexible summaries we definitely have the space to work with. As brought up above it can be a slippery slope if we just go wild and add images whenever available as the vast majority of tornadoes have something these days thanks to DAT. I think for intense/violent tornadoes we can justify images in the tables for sure and other instances can be discussed individually (i.e. a weaker tornado that hits a major population center). Regarding MOS:ACCESS, there is no issue so long as it's implemented as a thumbnail with alt text. {{Multiple image}} can be used like in List of basal superasterid families which is a recently promoted Featured List. ~ Cyclonebiskit (chat) 20:17, 10 July 2023 (UTC)

I just created

Cite error: There are <ref group=note> tags on this page, but the references will not show without a {{reflist|group=note}} template (see the help page).