WikiProject COVID-19 aims to add to and build
consensus for pages relating to COVID-19. They have so far discussed items listed below. Please discuss proposed improvements to them at the
project talk page.
For infoboxes on the main articles of countries, use Wuhan, Hubei, China for the origin parameter. (
March 2020)
"Social distancing" is generally preferred over "physical distancing". (
April 2020,
May 2020)
Page title
COVID-19 (full caps) is preferable in the body of all articles, and in the title of all articles/category pages/etc.(
RM April 2020, including the main article itself,
RM March 2021).
SARS-CoV-2 (exact capitalisation and punctuation) is the common name of the virus and should be used for the main article's title, as well as in the body of all articles, and in the title of all other articles/category pages/etc. (
June 2022, overturning
April 2020)
Map
There is no consensus about which color schemes to use, but they should be consistent within articles as much as possible. There is agreement that there should be six levels of shading, plus gray  for areas with no instances or no data. (
May 2020)
There is no consensus about whether the legend, the date, and other elements should appear in the map image itself. (
May 2020)
For map legends, ranges should use fixed round numbers (as opposed to updating dynamically). There is no consensus on what base population to use for per capita maps. (
May 2020)
To ensure you are viewing the current list, you may wish to purge this page.
This article is within the scope of WikiProject COVID-19, a project to coordinate efforts to improve all
COVID-19-related articles. If you would like to help, you are invited to
join and to participate in
project discussions.COVID-19Wikipedia:WikiProject COVID-19Template:WikiProject COVID-19COVID-19 articles
This article is within the scope of WikiProject Death, a collaborative effort to improve the coverage of
Death on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.DeathWikipedia:WikiProject DeathTemplate:WikiProject DeathDeath articles
This article is within the scope of WikiProject Disaster management, a collaborative effort to improve the coverage of
Disaster management on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Disaster managementWikipedia:WikiProject Disaster managementTemplate:WikiProject Disaster managementDisaster management articles
This article is within the scope of WikiProject Viruses, a collaborative effort to improve the coverage of
viruses on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.VirusesWikipedia:WikiProject VirusesTemplate:WikiProject Virusesvirus articles
Wrong number of total COVID-19 deaths at the start of each month of 2021
The article lists that on May 1st 2021 there were about 2.600.000 total COVID-19 deaths in the world. This is wrong, and so is every other month. There were over 3 million deaths by the end of April.
— Preceding
unsigned comment added by
86.21.40.197 (
talk •
contribs) 2 May 2021 (UTC)
Sticky headers
I suggest adding the improved column and row sticky headers to the narrower 2021 templates too. Side to side scrolling is still needed on them on my iphone SE 2020. Even in landscape view there is a column off to the side.
I changed the templates names. Better for cell phone bookmarking and testing. And for finding in searches. I also made the necessary corrections in the wikitext too.
@
Timeshifter: As far as I can tell, the half year tables aren't needed anymore. If you are still trying to fit the table on your screen, then you need to get out of that mindset since doing that will never accommodate all the different screen sizes that exist in a practical manner. The new styles accommodate the screen sizes with the sticky column/row headers, scrolling, and expand features, regardless of how wide or tall a table is.
Also, can you describe in more detail why you reverted the use of the full 2021 table back to the half year tables that don't even have sticky on iPhone? The issue you briefly mentioned in your edit summary was "They work, but they are not intuitive to use. I still have problems getting it to work due to viewport placement, tapping correctly." Your reasons aren't very clear, and if you have issues with the 2021 table, then you should have the same issues with the 2020 table and will have the same issues with the half year tables that you want restyled, which the reasoning appears inconsistent. I haven't experienced any issues with the tables on my Android phone. If you have issues using an iPhone, then that isn't reason enough for the revert. Unless there is a serious problem, I suggest using the full 2021 table. You can open a discussion on this page asking other users to gauge the usability or just give it some time. So far, no one else has reported any issues with the other seven tables that use the same new styles, which are displayed on various pages.
Jroberson108 (
talk)
12:19, 31 January 2022 (UTC)reply
Jroberson108. Please list the other tables that have the improved sticky headers for both column and row headers, and that work in iphones. I will look at them in my iPhone SE 2020.
Here is my full edit summary: "The narrower tables are much easier to use on my iphone. Or any cell phone. Even with the sticky headers. They work, but they are not intuitive to use. I still have problems getting it to work due to viewport placement, tapping correctly."
@
Timeshifter: The templates that use the new styles can be found at
Template:COVID-19 pandemic data/doc#Style sheet. I'm aware of what your full edit summary is, which the first part isn't an issue but rather your preference while the part I highlighted still needs clarification so I can see if it is an actual issue and figure out a fix. There is no question that the smaller a table is the easier it is to use on smaller devices, but the practicality in this case is questionable. You can remove the flags column and have monthly two-column tables that require little to no horizontal scrolling on small devices, but are less practical to use when comparing data points. The whole point of the new styles was to provide the practical aspect of viewing larger tables of smaller devices so that headers don't need to be remembered. The 2021 table isn't much wider than the 2020 table, but they are both equally practical to use and both require scrolling on small devices. If there is no issue to fix in the new styles, then I suggest getting concensus with the other users regarding preferences. If they want to use half year tables or even monthly tables, then I will help to implement in that regard and the 2020 table will be split too for consistency. If they prefer the yearly tables, then it will save any wasted efforts since that is already done for 2020 and 2021. Whatever the preference is, get clear consensus first.
Jroberson108 (
talk)
22:42, 31 January 2022 (UTC)reply
If you don't want to help, that's fine. I may be able to figure it out myself. The 2020 and 2021 full tables are not both equally practical to use. Monthly tables are not needed. Please reread what I wrote before. You may not understand all that I previously wrote since you don't have my hands-on experience with the iphone SE 2020. --
Timeshifter (
talk)
01:20, 1 February 2022 (UTC)reply
@
Timeshifter: I never said I didn't want to help, in fact I said the exact opposite. I already said which part you need to clarify. If there isn't a real issue for me to fix in the new styles, then I suggest you get consensus from other users on the presentation. We both prefer a different presentation, so when two editors disagree then get consensus from other users per WP:DISPUTE.
Jroberson108 (
talk)
02:12, 1 February 2022 (UTC)reply
Jroberson108. Well then, please help fix the half-year templates so that editors can compare full-year versus half-year templates in iphones too.
I got the 2nd half of 2021 template this far in a sandbox:
The top and side sticky headers work in all 4 browsers on the iphone. But I can't figure out why the data is bold. I also can't figure out why the data cells don't have a white background.
I am not very familiar with ids. I don't know if I did that right. I read your comments here:
Viewport should be 75%, not 80%. That is much of the problem I am having in the iphone. I would even try 70%. That would greatly disentangle touches from hitting the top and bottom toolbars that pop in and out.
@
Timeshifter: The 80% probably came from some testing I was doing that I forgot about during development. It is now 75% to match the old styles. I wouldn't go lower without consensus from other users since the 75% height has been in use for a while on a lot of templates.
As far as updating the half year tables go, it's not really needed to draw a consensus on whether or not the yearly tables are too wide, and, as I already mentioned, it would be a wasted effort if the consensus decided against the half year layout. Although I still think the yearly tables are more practical when comparing data points in a yearly format that most people are use to, I'm not strongly against the half year tables. That being said, I will rescind my request for dispute resolution and update the half year tables unless someone else objects before I finish. I'll leave it to you to reach a consensus if another user strongly wants yearly tables or if you want their input regardless of dispute.
Regarding the 2022 table, per our earlier discussion at
Talk:COVID-19_pandemic_deaths#Scrolling versus expanded tables, you agreed that "If all the links are specialized, then no asterisks are needed. But a note is still needed." and that this meets
MOS:EGG. All links are specialized now and I don't see anything counter to this agreement from you or anyone else, so I will implement that change with the new markup conversion. It's just easier to do all at once. If your opinion changed, then let me know that you want to keep the asterisks before I finish. We don't need to have another discussion about it and I'm not strongly against it, just against the illogical nature of the presentation. I will probably start the conversion tomorrow.
Jroberson108 (
talk)
04:10, 2 February 2022 (UTC)reply
Jroberson108. Yeah, feel free to remove the asterisks from the 2022 table. There is also no need to use the "expensive" function since all but one of the "COVID-19 pandemic in ..." links were found (if I am remembering correctly).
@
Timeshifter: The Wikipedia Jan 1, 2022 cumulative deaths don't appear to be correct, at least for the United States, which lists 817,969. The CSV has 817,916 for 2021-12-31 and 819,204 for 2022-01-01, so the number used is between those two? I assume from the column header that the "2022-01-01" data should be used. I'll leave updating the data to you. Maybe they corrected the data since Jan 1st, which could also be true for the older data? I didn't spot-check the 2020 and 2021 data. I may try to bulk replace the data for the 2020 and 2021 yearly tables with the CSV data to see if there are any changes. I assume the half year tables use the same data. We'll see.
Jroberson108 (
talk)
03:46, 3 February 2022 (UTC)reply
@
Timeshifter: I'm done updating the half-year tables to use the new styles, which all appear to work correctly. I kept the table note above the scrollable div like the 2020 table. My priority was the markup, so no numbers were checked or modified.
Jroberson108 (
talk)
06:27, 3 February 2022 (UTC)reply
Jroberson108. The source continually updates the numbers. So when I do updates each month. I update all months. Feel free to redo the numbers on the 2020 and 2021 tables. And the 2022 numbers (including February) if you want to. I may not get around to it right away. I am very busy.
@
Timeshifter: Good to know the table's work. You're welcome.
I was kind of wondering why these tables use data from the 1st of the month instead of end-of-month. Technically, Dec 1 data is inclusive, so it's the increase from the start of Nov 2 until the end of Dec 1. For December's increase you have to look at next year's table's "Jan 1". Wouldn't it be better if "Dec" was December's (1-31) changes? Just something to consider before any bulk replacing of data.
Jroberson108 (
talk)
11:58, 3 February 2022 (UTC)reply
Jroberson108. Someone else started that format. But I can see several reasons to keep it. Except for the 2020 table all the months are fully dated in the column heads.
As in Jan 1, Feb 1, etc.. If we went to end of month data it would be Jan 31, Feb 28 (or 29), Mar 31, Apr 30, etc.. That would cause the real problem: Pulling the data from the CSV file. You have to pick the dates. That is a good reason for you to try doing it once, say for Feb 2022 update. :) Or one of the other yearly tables. Then you will see what I am talking about. It would be very easy to screw up in picking the dates.
On the other hand it only needs to be done infrequently on the old tables. So if you want to use end of the month dates feel free to do so. Please be sure to put the dates in the headers so that people see exactly what the monthly increases refer to. Same for the 2022 table.
I use my knuckles to pick the end of month dates. :) Top of knuckle is a month with 31 days. Following valley is 30 days (except Feb). Next peak is 31 days. You use 2 hands next to each other. Try it, it works.
@
Timeshifter: Personally, I would just keep the columns labeled without the day ("Jan", "Feb", etc.) and replace the caption's "monthly" with "end-of-month" or describe it somewhere in the caption, similar to the 2020 table.
Jroberson108 (
talk)
12:42, 3 February 2022 (UTC)reply
Jroberson108. People don't see the caption or the notes once they start scrolling down the table.
The only reason the date was not used in the 2020 table was because in the first few months that would widen the table. The header text was wider than the number. That was not a problem from April 2020 on.
@
Timeshifter: I read the caption and table notes, especially if headers need clarification. I wouldn't assume others don't. I agree with you about footnotes that are hidden, which I read only if I need clarification. Anyways, just something to consider. Nothing to have a long discussion about.
Jroberson108 (
talk)
13:15, 3 February 2022 (UTC)reply
Jroberson108. I am assuming that people scan the headers initially. But I often forget the details once I start scrolling down the table. That is another reason why sticky column headers are so beloved by people. You don't have to trust memory. --
Timeshifter (
talk)
13:36, 3 February 2022 (UTC)reply
@
Timeshifter: As far as column and row headers go, there is a mental disconnect that occurs if there is simular data on multiple columns or rows, and the headers scroll out-of-view. The caption can explain some of the headers like the year or start/end of month without issue as long as headers are still distinguishable like the month name. If the data in each column is different like a date, number, and percentage, then, depending on person, it is easier to distinguish without sticky headers if not too many columns. Yes, it all depends on memory. With simular data like these tables, without sticky the issue is not knowing which month for which location. That about sums it up.
Jroberson108 (
talk)
14:07, 3 February 2022 (UTC)reply
Jroberson108. I am speaking from experience concerning forgetting stuff about column headers. Maybe you don't have the problem, but many people do.
The month and day (Jan 31, Feb 28, etc) will not cause any wrapping in any of the year templates except for the first 3 or 4 months of 2020. And if that is a problem then that is one sparing use of nowrap that I approve of. Just for those months where the header text is wider than the world number. --
Timeshifter (
talk)
14:16, 3 February 2022 (UTC)reply
@
Timeshifter: I think you missed where I said "Yes, it all depends on memory." As far as I'm concerned, the exact day is unimportant to me. All I care to know is it includes the entire month. Maybe the exact day is important for you?
Jroberson108 (
talk)
14:29, 3 February 2022 (UTC)reply
OK, I think see where you are coming from. But I want to know exactly what day the cumulative total applies to. As do many others. The cumulative total is not for the month. It is for all deaths since 2020 and going through the month. I know you understand this, but others may not. I have had many discussions over the last almost 2 years I have been working on Covid-19 tables. And people are easily confused by everything. So I try to be as explicit as possible in tables. --
Timeshifter (
talk)
14:47, 3 February 2022 (UTC)reply
This page requires an update. It is very important not to discontinue updating it, because there isn't one one website on the whole World Wide Web that provides a simple and clear overview of stats on COVID deaths as this Wikipedia page does. I am willing to help with the work - contact me if needed. Thanks.
NoWikiNoLife (
talk)
02:00, 25 June 2022 (UTC)reply
NoWikiNoLife and others. Feel free to update it. I no longer have the time, desire, health, or energy for more than minor stuff on Wikipedia. I assume you are talking about this template, and later ones as needed:
You might consider doing it only every other month from now on. Or quarterly. Please update Help:Table with any tips you discover. Maybe create a separate how-to page that can be linked to from the help page. Please link to them. There are many tables that would be made easier to create or update.
Thanks for that. I'm still having issues finding source files (.csv files) for official number of cases and deaths on a particular date for each country. Can you maybe provide a link to those, as well? Thanks again. Too bad you're no longer able to do this, I as hoping we could share the workload. :)
WikiProject COVID-19 aims to add to and build
consensus for pages relating to COVID-19. They have so far discussed items listed below. Please discuss proposed improvements to them at the
project talk page.
For infoboxes on the main articles of countries, use Wuhan, Hubei, China for the origin parameter. (
March 2020)
"Social distancing" is generally preferred over "physical distancing". (
April 2020,
May 2020)
Page title
COVID-19 (full caps) is preferable in the body of all articles, and in the title of all articles/category pages/etc.(
RM April 2020, including the main article itself,
RM March 2021).
SARS-CoV-2 (exact capitalisation and punctuation) is the common name of the virus and should be used for the main article's title, as well as in the body of all articles, and in the title of all other articles/category pages/etc. (
June 2022, overturning
April 2020)
Map
There is no consensus about which color schemes to use, but they should be consistent within articles as much as possible. There is agreement that there should be six levels of shading, plus gray  for areas with no instances or no data. (
May 2020)
There is no consensus about whether the legend, the date, and other elements should appear in the map image itself. (
May 2020)
For map legends, ranges should use fixed round numbers (as opposed to updating dynamically). There is no consensus on what base population to use for per capita maps. (
May 2020)
To ensure you are viewing the current list, you may wish to purge this page.
This article is within the scope of WikiProject COVID-19, a project to coordinate efforts to improve all
COVID-19-related articles. If you would like to help, you are invited to
join and to participate in
project discussions.COVID-19Wikipedia:WikiProject COVID-19Template:WikiProject COVID-19COVID-19 articles
This article is within the scope of WikiProject Death, a collaborative effort to improve the coverage of
Death on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.DeathWikipedia:WikiProject DeathTemplate:WikiProject DeathDeath articles
This article is within the scope of WikiProject Disaster management, a collaborative effort to improve the coverage of
Disaster management on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Disaster managementWikipedia:WikiProject Disaster managementTemplate:WikiProject Disaster managementDisaster management articles
This article is within the scope of WikiProject Viruses, a collaborative effort to improve the coverage of
viruses on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.VirusesWikipedia:WikiProject VirusesTemplate:WikiProject Virusesvirus articles
Wrong number of total COVID-19 deaths at the start of each month of 2021
The article lists that on May 1st 2021 there were about 2.600.000 total COVID-19 deaths in the world. This is wrong, and so is every other month. There were over 3 million deaths by the end of April.
— Preceding
unsigned comment added by
86.21.40.197 (
talk •
contribs) 2 May 2021 (UTC)
Sticky headers
I suggest adding the improved column and row sticky headers to the narrower 2021 templates too. Side to side scrolling is still needed on them on my iphone SE 2020. Even in landscape view there is a column off to the side.
I changed the templates names. Better for cell phone bookmarking and testing. And for finding in searches. I also made the necessary corrections in the wikitext too.
@
Timeshifter: As far as I can tell, the half year tables aren't needed anymore. If you are still trying to fit the table on your screen, then you need to get out of that mindset since doing that will never accommodate all the different screen sizes that exist in a practical manner. The new styles accommodate the screen sizes with the sticky column/row headers, scrolling, and expand features, regardless of how wide or tall a table is.
Also, can you describe in more detail why you reverted the use of the full 2021 table back to the half year tables that don't even have sticky on iPhone? The issue you briefly mentioned in your edit summary was "They work, but they are not intuitive to use. I still have problems getting it to work due to viewport placement, tapping correctly." Your reasons aren't very clear, and if you have issues with the 2021 table, then you should have the same issues with the 2020 table and will have the same issues with the half year tables that you want restyled, which the reasoning appears inconsistent. I haven't experienced any issues with the tables on my Android phone. If you have issues using an iPhone, then that isn't reason enough for the revert. Unless there is a serious problem, I suggest using the full 2021 table. You can open a discussion on this page asking other users to gauge the usability or just give it some time. So far, no one else has reported any issues with the other seven tables that use the same new styles, which are displayed on various pages.
Jroberson108 (
talk)
12:19, 31 January 2022 (UTC)reply
Jroberson108. Please list the other tables that have the improved sticky headers for both column and row headers, and that work in iphones. I will look at them in my iPhone SE 2020.
Here is my full edit summary: "The narrower tables are much easier to use on my iphone. Or any cell phone. Even with the sticky headers. They work, but they are not intuitive to use. I still have problems getting it to work due to viewport placement, tapping correctly."
@
Timeshifter: The templates that use the new styles can be found at
Template:COVID-19 pandemic data/doc#Style sheet. I'm aware of what your full edit summary is, which the first part isn't an issue but rather your preference while the part I highlighted still needs clarification so I can see if it is an actual issue and figure out a fix. There is no question that the smaller a table is the easier it is to use on smaller devices, but the practicality in this case is questionable. You can remove the flags column and have monthly two-column tables that require little to no horizontal scrolling on small devices, but are less practical to use when comparing data points. The whole point of the new styles was to provide the practical aspect of viewing larger tables of smaller devices so that headers don't need to be remembered. The 2021 table isn't much wider than the 2020 table, but they are both equally practical to use and both require scrolling on small devices. If there is no issue to fix in the new styles, then I suggest getting concensus with the other users regarding preferences. If they want to use half year tables or even monthly tables, then I will help to implement in that regard and the 2020 table will be split too for consistency. If they prefer the yearly tables, then it will save any wasted efforts since that is already done for 2020 and 2021. Whatever the preference is, get clear consensus first.
Jroberson108 (
talk)
22:42, 31 January 2022 (UTC)reply
If you don't want to help, that's fine. I may be able to figure it out myself. The 2020 and 2021 full tables are not both equally practical to use. Monthly tables are not needed. Please reread what I wrote before. You may not understand all that I previously wrote since you don't have my hands-on experience with the iphone SE 2020. --
Timeshifter (
talk)
01:20, 1 February 2022 (UTC)reply
@
Timeshifter: I never said I didn't want to help, in fact I said the exact opposite. I already said which part you need to clarify. If there isn't a real issue for me to fix in the new styles, then I suggest you get consensus from other users on the presentation. We both prefer a different presentation, so when two editors disagree then get consensus from other users per WP:DISPUTE.
Jroberson108 (
talk)
02:12, 1 February 2022 (UTC)reply
Jroberson108. Well then, please help fix the half-year templates so that editors can compare full-year versus half-year templates in iphones too.
I got the 2nd half of 2021 template this far in a sandbox:
The top and side sticky headers work in all 4 browsers on the iphone. But I can't figure out why the data is bold. I also can't figure out why the data cells don't have a white background.
I am not very familiar with ids. I don't know if I did that right. I read your comments here:
Viewport should be 75%, not 80%. That is much of the problem I am having in the iphone. I would even try 70%. That would greatly disentangle touches from hitting the top and bottom toolbars that pop in and out.
@
Timeshifter: The 80% probably came from some testing I was doing that I forgot about during development. It is now 75% to match the old styles. I wouldn't go lower without consensus from other users since the 75% height has been in use for a while on a lot of templates.
As far as updating the half year tables go, it's not really needed to draw a consensus on whether or not the yearly tables are too wide, and, as I already mentioned, it would be a wasted effort if the consensus decided against the half year layout. Although I still think the yearly tables are more practical when comparing data points in a yearly format that most people are use to, I'm not strongly against the half year tables. That being said, I will rescind my request for dispute resolution and update the half year tables unless someone else objects before I finish. I'll leave it to you to reach a consensus if another user strongly wants yearly tables or if you want their input regardless of dispute.
Regarding the 2022 table, per our earlier discussion at
Talk:COVID-19_pandemic_deaths#Scrolling versus expanded tables, you agreed that "If all the links are specialized, then no asterisks are needed. But a note is still needed." and that this meets
MOS:EGG. All links are specialized now and I don't see anything counter to this agreement from you or anyone else, so I will implement that change with the new markup conversion. It's just easier to do all at once. If your opinion changed, then let me know that you want to keep the asterisks before I finish. We don't need to have another discussion about it and I'm not strongly against it, just against the illogical nature of the presentation. I will probably start the conversion tomorrow.
Jroberson108 (
talk)
04:10, 2 February 2022 (UTC)reply
Jroberson108. Yeah, feel free to remove the asterisks from the 2022 table. There is also no need to use the "expensive" function since all but one of the "COVID-19 pandemic in ..." links were found (if I am remembering correctly).
@
Timeshifter: The Wikipedia Jan 1, 2022 cumulative deaths don't appear to be correct, at least for the United States, which lists 817,969. The CSV has 817,916 for 2021-12-31 and 819,204 for 2022-01-01, so the number used is between those two? I assume from the column header that the "2022-01-01" data should be used. I'll leave updating the data to you. Maybe they corrected the data since Jan 1st, which could also be true for the older data? I didn't spot-check the 2020 and 2021 data. I may try to bulk replace the data for the 2020 and 2021 yearly tables with the CSV data to see if there are any changes. I assume the half year tables use the same data. We'll see.
Jroberson108 (
talk)
03:46, 3 February 2022 (UTC)reply
@
Timeshifter: I'm done updating the half-year tables to use the new styles, which all appear to work correctly. I kept the table note above the scrollable div like the 2020 table. My priority was the markup, so no numbers were checked or modified.
Jroberson108 (
talk)
06:27, 3 February 2022 (UTC)reply
Jroberson108. The source continually updates the numbers. So when I do updates each month. I update all months. Feel free to redo the numbers on the 2020 and 2021 tables. And the 2022 numbers (including February) if you want to. I may not get around to it right away. I am very busy.
@
Timeshifter: Good to know the table's work. You're welcome.
I was kind of wondering why these tables use data from the 1st of the month instead of end-of-month. Technically, Dec 1 data is inclusive, so it's the increase from the start of Nov 2 until the end of Dec 1. For December's increase you have to look at next year's table's "Jan 1". Wouldn't it be better if "Dec" was December's (1-31) changes? Just something to consider before any bulk replacing of data.
Jroberson108 (
talk)
11:58, 3 February 2022 (UTC)reply
Jroberson108. Someone else started that format. But I can see several reasons to keep it. Except for the 2020 table all the months are fully dated in the column heads.
As in Jan 1, Feb 1, etc.. If we went to end of month data it would be Jan 31, Feb 28 (or 29), Mar 31, Apr 30, etc.. That would cause the real problem: Pulling the data from the CSV file. You have to pick the dates. That is a good reason for you to try doing it once, say for Feb 2022 update. :) Or one of the other yearly tables. Then you will see what I am talking about. It would be very easy to screw up in picking the dates.
On the other hand it only needs to be done infrequently on the old tables. So if you want to use end of the month dates feel free to do so. Please be sure to put the dates in the headers so that people see exactly what the monthly increases refer to. Same for the 2022 table.
I use my knuckles to pick the end of month dates. :) Top of knuckle is a month with 31 days. Following valley is 30 days (except Feb). Next peak is 31 days. You use 2 hands next to each other. Try it, it works.
@
Timeshifter: Personally, I would just keep the columns labeled without the day ("Jan", "Feb", etc.) and replace the caption's "monthly" with "end-of-month" or describe it somewhere in the caption, similar to the 2020 table.
Jroberson108 (
talk)
12:42, 3 February 2022 (UTC)reply
Jroberson108. People don't see the caption or the notes once they start scrolling down the table.
The only reason the date was not used in the 2020 table was because in the first few months that would widen the table. The header text was wider than the number. That was not a problem from April 2020 on.
@
Timeshifter: I read the caption and table notes, especially if headers need clarification. I wouldn't assume others don't. I agree with you about footnotes that are hidden, which I read only if I need clarification. Anyways, just something to consider. Nothing to have a long discussion about.
Jroberson108 (
talk)
13:15, 3 February 2022 (UTC)reply
Jroberson108. I am assuming that people scan the headers initially. But I often forget the details once I start scrolling down the table. That is another reason why sticky column headers are so beloved by people. You don't have to trust memory. --
Timeshifter (
talk)
13:36, 3 February 2022 (UTC)reply
@
Timeshifter: As far as column and row headers go, there is a mental disconnect that occurs if there is simular data on multiple columns or rows, and the headers scroll out-of-view. The caption can explain some of the headers like the year or start/end of month without issue as long as headers are still distinguishable like the month name. If the data in each column is different like a date, number, and percentage, then, depending on person, it is easier to distinguish without sticky headers if not too many columns. Yes, it all depends on memory. With simular data like these tables, without sticky the issue is not knowing which month for which location. That about sums it up.
Jroberson108 (
talk)
14:07, 3 February 2022 (UTC)reply
Jroberson108. I am speaking from experience concerning forgetting stuff about column headers. Maybe you don't have the problem, but many people do.
The month and day (Jan 31, Feb 28, etc) will not cause any wrapping in any of the year templates except for the first 3 or 4 months of 2020. And if that is a problem then that is one sparing use of nowrap that I approve of. Just for those months where the header text is wider than the world number. --
Timeshifter (
talk)
14:16, 3 February 2022 (UTC)reply
@
Timeshifter: I think you missed where I said "Yes, it all depends on memory." As far as I'm concerned, the exact day is unimportant to me. All I care to know is it includes the entire month. Maybe the exact day is important for you?
Jroberson108 (
talk)
14:29, 3 February 2022 (UTC)reply
OK, I think see where you are coming from. But I want to know exactly what day the cumulative total applies to. As do many others. The cumulative total is not for the month. It is for all deaths since 2020 and going through the month. I know you understand this, but others may not. I have had many discussions over the last almost 2 years I have been working on Covid-19 tables. And people are easily confused by everything. So I try to be as explicit as possible in tables. --
Timeshifter (
talk)
14:47, 3 February 2022 (UTC)reply
This page requires an update. It is very important not to discontinue updating it, because there isn't one one website on the whole World Wide Web that provides a simple and clear overview of stats on COVID deaths as this Wikipedia page does. I am willing to help with the work - contact me if needed. Thanks.
NoWikiNoLife (
talk)
02:00, 25 June 2022 (UTC)reply
NoWikiNoLife and others. Feel free to update it. I no longer have the time, desire, health, or energy for more than minor stuff on Wikipedia. I assume you are talking about this template, and later ones as needed:
You might consider doing it only every other month from now on. Or quarterly. Please update Help:Table with any tips you discover. Maybe create a separate how-to page that can be linked to from the help page. Please link to them. There are many tables that would be made easier to create or update.
Thanks for that. I'm still having issues finding source files (.csv files) for official number of cases and deaths on a particular date for each country. Can you maybe provide a link to those, as well? Thanks again. Too bad you're no longer able to do this, I as hoping we could share the workload. :)