Talk:COVID-19 pandemic deaths/Archive 1

Archive 1

Requested move 27 April 2020

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: Withdrawn. See below. Soumyabrata ^talk _contribs ^subpages 12:45, 30 April 2020 (UTC)

---

2019–20 coronavirus pandemic deaths → COVID-19 death reports – This article clearly represent the number of reported deaths caused by the coronavirus disease 2019. However, it should be noted that this requested move is not related to the requested move of the 2019–20 coronavirus pandemic. Soumyabrata ^{stay at home 🏠} _{wash your hands 👋} ^{to protect from COVID-19 😷} 04:49, 27 April 2020 (UTC)

• Move to Coronavirus pandemic deaths per my reasoning for the main article, "COVID-19" is an abbreviation and the term is often enough seen in the full that WP:NCA probably doesn't apply but this might not necessarily apply like 9/11 conspiracy theories where the abbreviation is common for that topic. Crouch, Swale (talk) 05:42, 27 April 2020 (UTC)
• Oppose Per WP:AINTBROKE. No argument has been advanced that the current title is in any way wrong. Wikipedia is not a crystal ball that can tell the exact deaths, so the fact that there are only the "reported" deaths listed does not need to be spelled out in the title._{ZXCVBNM (TALK)} 13:29, 27 April 2020 (UTC)
• Oppose The proposed title is confusing/ambiguous. To me, "COVID-19 death reports" sounds somewhat like reports of individual deaths, rather than of numbers of them. But the current title isn't ideal either - it isn't clear from the title how it differs in scope from List of deaths due to coronavirus disease 2019. So while I'm sure there's a better title for this article, this isn't it. — Smjg (talk) 16:49, 27 April 2020 (UTC)
• Oppose "reports" also doesn't seem right to be, and per WP:AINTBROKE. {{u|Sdkb}} ^talk 01:08, 28 April 2020 (UTC)
• Oppose not really needed that way. Starzoner (talk) 01:30, 28 April 2020 (UTC)
• Comment – I have changed the proposed title. --Soumyabrata ^{stay at home 🏠} _{wash your hands 👋} ^{to protect from COVID-19 😷} 09:09, 28 April 2020 (UTC)
  • This proposal is to move to the title "COVID-19 death reports". People have already responded on the basis of this title. If you'd like to propose moving it to a different title, please start a new discussion. — Smjg (talk) 09:30, 28 April 2020 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

DRAFTs

FYI, there exists Draft:List of Medical Professionals Who Died During the COVID-19 Pandemic and Draft:Covid-19 and Doctors Dying in Clinical Service ; which you (editors) may wish to merge or just redirect to this article or the other one List of deaths due to coronavirus disease 2019 -- 65.94.170.207 (talk) 16:10, 4 May 2020 (UTC)

Notable deaths from Covid-19

While it's entirely fitting that a page called 2019–20 coronavirus pandemic deaths/WHO situation reports would have stats about deaths, I wonder whether there's any call for a 2019–20 coronavirus pandemic notable deaths page, which would list the passing of people of interest.

I notice that there's a more general list, Deaths in 2020, which includes Covid-19 deaths. Those and their counterparts on the forthcoming Deaths in 2021 page could be compiled into a specific Covid-19 page.

If such a page exists or comes into being, perhaps a link could be added to this page for people who come here looking for it. A disambiguation page for these stats and notable deaths is another possibility. 92.25.47.124 (talk) 08:24, 27 March 2020 (UTC)

Happy to add a link to such a page if it is created, good idea to create it, please do! Anguswalker (talk) 11:41, 27 March 2020 (UTC)

There is already such a page, I have added a link to it Anguswalker (talk) 14:29, 27 March 2020 (UTC)

Requested move 29 March 2020

Moved to Talk:2019–20 coronavirus pandemic cases/WHO situation reports § Requested move 29 March 2020

 – – Thjarkur (talk) 17:57, 29 March 2020 (UTC)

Move discussion in progress

There is a move discussion in progress on Talk:2019–20 coronavirus pandemic cases/WHO situation reports which affects this page. Please participate on that page and not in this talk page section. Thank you. —RMCD bot 18:05, 29 March 2020 (UTC)

Number of deaths

Is the number reported in the chart "how many people died on that specific day" ... or ... "the cumulative number of deaths, as of that specific day" ... ? I think it's the latter. But, it's unclear. The article should clarify. Thanks. Joseph A. Spadaro (talk) 04:45, 22 April 2020 (UTC)

First reported case does not need to be duplicated in all tables. Less work, and narrower tables

Column for "first reported case" can be removed from all the tables. It can go in a single table. This allows it to be updated more easily. Is someone updating that column in every table now? That is a ridiculous amount of duplication and work.

Removing it from all the monthly tables would make the tables narrower too. That means they would be viewable in more screen widths. --Timeshifter (talk) 05:46, 6 May 2020 (UTC)

"First reported cases" table is at COVID-19 pandemic cases. It is not necessary to duplicate it here

There is now a separate table for "First reported cases" at COVID-19 pandemic cases.

So the columns are no longer necessary here. A link can be provided to that article. --Timeshifter (talk) 09:18, 6 May 2020 (UTC)

Errors in data

There appears to be an obvious error in the data for the USA on May 3 / May 4, since the total number of deaths go up and then back down. I couldn't find a source for these specific numbers. Can someone check the validity of those numbers and correct them as needed. Truthanado (talk) 18:28, 9 May 2020 (UTC)

References are getting sorted

Please check the tables which contain an item References. Even though it provides references, those rows are also getting sorted along-with other rows present in the table. I think the sortable functionality needs to be disabled for the row 'references'. Adithyak1997 (talk) 06:33, 16 May 2020 (UTC)

@Adithyak1997: Feel free to fix it. See Help:Sorting. Search for class="sortbottom" and class="sorttop". See the sections called "Excluding final rows from sorting" and "Excluding top rows from sorting". You can also feel free to move the references row near the top as is done for April and May here. --Timeshifter (talk) 08:20, 20 May 2020 (UTC)

Done. --Timeshifter (talk) 07:54, 26 May 2020 (UTC)

Please add visual statistics and "deaths on day" alongside the updated total number of deaths

Could you please add a sortable column for number of deaths on that day to the table?

It would simply be this: {{total number of deaths of current day} - {total number of deaths of the day before}}.

Maybe it could be calculated automatically with some inline table styntax or template similar to spreadsheet software like LibreOffice Calc.

Or maybe it could be added by a bot.

This would make the data a lot more useful. For example one could see which days or periods had the highest number of deaths (peaks) or lowest number of deaths and one could more easily identify rises.

Adding some visual staistics from the data would be useful too.

--Prototyperspective (talk) 10:43, 5 June 2020 (UTC)

I have added a daily table and a few statistics similar to the cases page. Anguswalker (talk) 19:37, 13 June 2020 (UTC)

COVID-19 pandemic cases. --Timeshifter (talk) 06:48, 19 June 2020 (UTC)

"First deaths" column removed from all tables except most recent month

I removed "First death" columns. I left just one in the most recent month.

There is no need to duplicate that column. It makes tables unnecessarily wider. It also makes it difficult to update the info since it has to be repeated on multiple months.

It would be better in a separate table just for first deaths by country. --Timeshifter (talk) 09:09, 18 July 2020 (UTC)

WP:NOTSTATS

This article is a utterly pointless rehash of statistics that are much better presented in the numerous graphics we already have, and totally against WP:NOTSTATS. On the other hand, this article should be rewritten to have a meaningful presentation about the number of confirmed deaths as compared to the number of suspected deaths, to get a sense of the true extent of the pandemic. It is well documented by now that many countries and areas have significant excess mortality rates (e.g. [1]), but due to low testing rates, a low number of confirmed COVID-related deaths are reported (which should also be discussed in the article). So the number of actual COVID deaths is much, much higher than confirmed deaths. -- P 1 9 9  ✉ 15:14, 26 June 2020 (UTC)

Please learn to read WP:NOTSTATS with better comprehension. Then your posts will not sound like pointless rants. From WP:NOTSTATS:

1. Excessive listings of unexplained statistics. Statistics that lack context or explanation can reduce readability and may be confusing; accordingly, statistics should be placed in tables to enhance readability, and articles with statistics should include explanatory text providing context. Where statistics are so lengthy as to impede the readability of the article, the statistics can be split into a separate article and summarized in the main article. (e.g., statistics from the main article 2012 United States presidential election have been moved to a related article Nationwide opinion polling for the 2012 United States presidential election). Wikipedia:Notability#Stand-alone lists offers more guidance on what kind of lists are acceptable, and Wikipedia:Stand-alone lists#Selection criteria offers guidance on what entries should be included.

--Timeshifter (talk) 08:33, 18 July 2020 (UTC)

Wrong. I clearly stated the problem with this article as it is now and offered a concrete way to improve it. Looks like I will have to be bold and do it myself (despite lack of time). -- P 1 9 9  ✉ 15:28, 28 July 2020 (UTC)

Removed the remaining "First death" column. No longer needed since there is a link in the top notes

I removed the remaining "First death" column. I removed it from the first half of September table. It is no longer needed. There is a link in the top notes to a table: Timeline of first confirmed case by country.

For a list of notable people who have died, see List of deaths due to COVID-19. For further information, see COVID-19 pandemic death rates by country and COVID-19 pandemic cases. See also: Timeline of first confirmed case by country.

--Timeshifter (talk) 20:57, 21 September 2020 (UTC)

Anguswalker, if you are using a sandbox to keep the latest month updated, please remove the "first death" column from it. --Timeshifter (talk) 16:33, 25 September 2020 (UTC)

I only intend to keep the 'first death' column in the latest table, you can remove it from the others. Separating it out and putting it at the beginning makes the page much longer, unnecessarily, surely? And don't confuse first death report to WHO with first case reported to WHO. Anguswalker (talk) 11:35, 3 October 2020 (UTC)

The linked article has numerous problems.

• It lists First confirmed case, not first death.
• It includes numerous unrecognised states that don't appear in the tables here.
• It doesn't list first confirmed case in the latest country with a confirmed death, Caribbean Netherlands.

This is at a glance; I didn't bother to check for other omissions or classification differences. In essence, it doesn't contain the same information as what you're repeatedly deleting from this article, and I think either you should add the First death data to the linked article as a separate table or stop deleting it here. G. Timothy Walton (talk) 17:05, 26 September 2020 (UTC)

The info in both articles is not sourced. That is the number one problem. My main goal is to keep this info in a separate table. It seems more logical to keep it in the the other article since it is a much shorter article (compared to this one).

In any case it should not be part of these wide tables. It must be put in a separate table. It makes these already wide tables wider. Especially for people like me who use zoom (in Firefox) to increase the font size.

I don't edit the first deaths or first cases info. Someone else is doing that. I have no idea who since the info is not sourced. Until it is sourced it should not be here in my opinion. --Timeshifter (talk) 02:43, 27 September 2020 (UTC)

If the numbers in this article are coming from the spreadsheet in Citation #212, then First death is sourced there.

BTW, I understand having to use enlargement with Firefox; I use a font size adjustment that doesn't require zooming (mine's set at 2.25). I found the layout of tables here with First death acceptable on an earlier monitor that's four inches smaller than the one I use now. G. Timothy Walton (talk) 04:57, 27 September 2020 (UTC)

G. Timothy Walton. I have the Firefox set to zoom text only. How much I zoom varies by web page. So I prefer the per page adjustment versus about:config adjustments, etc.. I do one system wide adjustment in Windows 10 display settings: "Scale and layout" > "Change the size of text, apps, and other items". I have it set to 175% on this 27 inch monitor at 2560x1440.

I use Firefox zoom at 120% or 133%. That makes the table too wide for me if I look at the most recent second half of the month table that has been completed. That would be the second half of August.

This is even more of a problem on my 21 inch monitor in another room.

--Timeshifter (talk) 05:33, 27 September 2020 (UTC)

First death table. Alphabetical order via LibreOffice Calc

User:Anguswalker. I am going to assume the first death dates were sourced as they showed up in the WHO reports.

Yes, they were Anguswalker (talk) 11:33, 3 October 2020 (UTC)

See User:Timeshifter/Sandbox121

This was created by pasting the non-alphabetized table into freeware LibreOffice Calc. Its default settings converted the date to the MM/DD/YY format. It also did the alphabetization without me telling it to do so. I then copied it straight from the Calc page and pasted it into a blank VisualEditor (VE) table in the sandbox. VE and/or Calc stripped out the flags. For more info see:

• Commons:Convert tables and charts to wiki code or image files

Date of first death by country

Countries and territories	First death Month/Day/Year
Afghanistan	03/23/20
Albania	03/14/20
Algeria	03/12/20
Andorra	03/24/20
Angola	04/01/20
Antigua and Barbuda	04/09/20
Argentina	03/08/20
Armenia	03/27/20
Aruba	04/16/20
Australia	03/02/20
Austria	03/13/20
Azerbaijan	03/19/20
Bahamas	04/03/20
Bahrain	03/16/20
Bangladesh	03/20/20
Barbados	04/07/20
Belarus	04/02/20
Belgium	03/16/20
Belize	04/07/20
Benin	04/07/20
Bermuda	04/08/20
Bolivia	03/31/20
Bosnia and Herzegovina	03/22/20
Botswana	04/02/20
Brazil	03/19/20
British Virgin Islands	04/20/20
Brunei	03/28/20
Bulgaria	03/12/20
Burkina Faso	03/19/20
Burundi	04/20/20
Cabo Verde	03/28/20
Cameroon	03/25/20
Canada	03/11/20
Caribbean Netherlands	09/15/20
Cayman Islands	03/16/20
Central African Republic	05/24/20
Chad	04/29/20
Chile	03/22/20
China	01/19/20
Colombia	03/23/20
Comoros	05/05/20
Congo	04/02/20
Costa Rica	03/20/20
Cote d'Ivoire	04/03/20
Croatia	03/25/20
Cuba	03/18/20
Curaçao	03/22/20
Cyprus	03/25/20
Czechia	03/23/20
Denmark	03/16/20
Djibouti	04/10/20
Dominican Republic	03/17/20
DRC	03/22/20
Ecuador	03/16/20
Egypt	03/09/20
El Salvador	04/02/20
Equatorial Guinea	04/23/20
Estonia	03/26/20
Eswatini	04/17/20
Ethiopia	04/06/20
Fiji	08/01/20
Finland	03/22/20
France	02/16/20
French Guiana	04/21/20
French Polynesia	09/11/20
Gabon	03/21/20
Gambia	03/28/20
Georgia	04/05/20
Germany	03/10/20
Ghana	03/24/20
Greece	03/12/20
Guadeloupe	03/28/20
Guam	03/23/20
Guatemala	03/16/20
Guernsey	04/01/20
Guinea	04/16/20
Guinea-Bissau	04/27/20
Guyana	03/13/20
Haiti	04/07/20
Honduras	03/27/20
Hungary	03/16/20
Iceland	03/21/20
India	03/13/20
Indonesia	03/11/20
Iran	02/20/20
Iraq	03/05/20
Ireland	03/12/20
Isle of Man	04/03/20
Israel	03/21/20
Italy	02/23/20
Jamaica	03/20/20
Japan	02/14/20
Jersey	03/27/20
Jordan	03/28/20
Kazakhstan	03/28/20
Kenya	03/27/20
Kosovo	03/21/20
Kuwait	04/05/20
Kyrgyzstan	04/03/20
Latvia	04/04/20
Lebanon	03/11/20
Lesotho	07/09/20
Liberia	04/05/20
Libya	04/03/20
Liechtenstein	04/05/20
Lithuania	03/21/20
Luxembourg	03/14/20
Madagascar	05/18/20
Malawi	04/08/20
Malaysia	03/19/20
Maldives	05/02/20
Mali	04/03/20
Malta	04/09/20
Martinique	03/26/20
Mauritania	04/04/20
Mauritius	03/25/20
Mayotte	04/02/20
Mexico	03/20/20
Moldova	03/21/20
Monaco	04/17/20
Montenegro	03/26/20
Montserrat	04/26/20
Morocco	03/11/20
Mozambique	05/26/20
Myanmar	04/01/20
Namibia	07/11/20
Nepal	05/17/20
Netherlands	03/07/20
New Zealand	03/29/20
Nicaragua	03/29/20
Niger	03/27/20
Nigeria	03/26/20
North Macedonia	03/23/20
Northern Mariana Islands	04/03/20
Norway	03/14/20
Oman	04/01/20
Other	02/20/20
Pakistan	03/20/20
Palestine	03/26/20
Panama	03/11/20
Papua New Guinea	07/30/20
Paraguay	03/22/20
Peru	03/21/20
Philippines	02/02/20
Poland	03/13/20
Portugal	03/18/20
Puerto Rico	03/22/20
Qatar	03/29/20
Reunion	05/21/20
Romania	03/23/20
Russia	03/26/20
Rwanda	05/31/20
Saint Martin	03/31/20
San Marino	03/08/20
São Tomé and Príncipe	05/01/20
Saudi Arabia	03/25/20
Senegal	04/02/20
Serbia	03/24/20
Sierra Leone	04/23/20
Singapore	03/22/20
Sint Maarten	04/03/20
Slovakia	04/07/20
Slovenia	03/18/20
Somalia	04/09/20
South Africa	03/28/20
South Korea	02/20/20
South Sudan	05/15/20
Spain	03/05/20
Sri Lanka	03/30/20
Sudan	03/16/20
Suriname	04/07/20
Sweden	03/16/20
Switzerland	03/06/20
Syria	03/30/20
Tajikistan	05/03/20
Tanzania	04/01/20
Thailand	03/02/20
Togo	03/30/20
Trinidad and Tobago	03/26/20
Tunisia	03/21/20
Turkey	03/18/20
Turks and Caicos	04/06/20
UAE	03/22/20
Uganda	07/24/20
UK	03/07/20
Ukraine	03/14/20
Uruguay	04/01/20
US Virgin Islands	04/07/20
USA	03/03/20
Uzbekistan	03/28/20
Venezuela	03/29/20
Vietnam	08/01/20
Yemen	05/01/20
Zambia	04/03/20
Zimbabwe	03/24/20

--Timeshifter (talk) 05:40, 27 September 2020 (UTC)

I started an article section with this table. --Timeshifter (talk) 10:04, 30 September 2020 (UTC)

@Timeshifter: I suggest it would be better to avoid the MM/DD/YYYY format for this table. It isn't universal and could cause confusion. I suggest we use written rather then numerical dates i.e. Mar 4, 2020 rather than 3/4/20. RandomIntrigue (talk) 17:01, 3 October 2020 (UTC)

RandomIntrigue. Feel free to change it. Or someone else can. --Timeshifter (talk) 20:14, 3 October 2020 (UTC)

RandomIntrigue. I am a newb at LibreOffice Calc. There is probably a way to keep the existing (spelled out) date format when pasting the 2-column table into it. --Timeshifter (talk) 21:09, 5 October 2020 (UTC)

What are the exact sources for the first death column?

Anguswalker and G. Timothy Walton. I can't tell if these latest date changes by an anonymous user for first death for some countries are based on anything:

• https://en.wikipedia.org/w/index.php?title=COVID-19_pandemic_deaths&type=revision&diff=988880672&oldid=988646759

--Timeshifter (talk) 05:23, 16 November 2020 (UTC)

Hmm, I don't know. My source is just the first date they were recorded in the WHO report Anguswalker (talk) 22:03, 16 November 2020 (UTC)

Anguswalker Is there one WHO page you can link to that has a list for the first death by country? Or have you been keeping a record from the many WHO reports? --Timeshifter (talk) 00:08, 17 November 2020 (UTC)

I have been keeping a record from the many WHO reports Anguswalker (talk) 22:09, 18 November 2020 (UTC)

What is date of first death? Table has both Jan 9 and Jan 11

Anguswalker. See monthly table:

• COVID-19 pandemic deaths#Cumulative monthly death totals by country.

Table caption has Jan 9, 2020 as the date of the first death.

Table header has Jan 11, 2020.

I copy your table data verbatim to here:

• Template:Monthly cumulative COVID-19 death totals by country

Until recently I remember it has been Jan 11, 2020. Have you updated that to Jan 9? Or is that an error? --Timeshifter (talk) 12:38, 18 December 2020 (UTC)

Anguswalker. I see you have made an edit to COVID-19 pandemic deaths since my above message. Could you please reply to my above question?

The table you just edited still has 2 different dates for the first death. --Timeshifter (talk) 10:03, 21 December 2020 (UTC)

I didn't edit the table between 18 and 21 December, but anyway, it should be 11-Jan, I have corrected the inconsistency. Anguswalker (talk) 07:33, 23 December 2020 (UTC)

Thanks for your great work. --Timeshifter (talk) 13:14, 24 December 2020 (UTC)

Move discussion in progress

There is a move discussion in progress on Talk:COVID-19 pandemic cases which affects this page. Please participate on that page and not in this talk page section. Thank you. —RMCD bot 17:19, 27 December 2020 (UTC)

Russia

https://www.theguardian.com/world/2020/dec/28/russia-admits-to-world-third-worst-covid-19-death-toll-underreported — Preceding unsigned comment added by 109.149.214.90 (talk) 21:50, 28 December 2020 (UTC)

The numbers will eventually be updated as they are found. For the latest daily cumulative update of cases, deaths, and death rates see COVID-19 pandemic death rates by country. --Timeshifter (talk) 19:48, 3 January 2021 (UTC)

Incorrect first death for the United States

@Timeshifter:The first death in the United States was on February 6th. You can see this here here and here. The current date says March 3rd, which is incorrect and I've found no sources backing that date (The first reported death was on the 29th before the deaths from Febraury 6 and 17 were discovered). Please let me know your thoughts. Herbfur (Eric, He/Him) (talk) 22:41, 5 January 2021 (UTC)

Anguswalker. Please check out this info. Herbfur, I let Anguswalker take care of the data and dates since he has been filling it in for a long time. So I follow his lead. --Timeshifter (talk) 00:52, 6 January 2021 (UTC)

Zambia and a new study

Greetings and felicitations. I heard about this on the news tonight (20–21 February 2021 ("Covid 19 death count: which countries are faring worst?", More or Less, BBC World Service—I think, as I haven't verified it, but it's the most likely candidate), and thought someone might want to at least take a look at it, and possibly use it as a source, or would at least appreciate a heads-up:

• "Covid-19 deaths in Africa: prospective systematic postmortem surveillance study". The BMJ. doi:10.1136/bmj.n334.

• Editorials: "Covid-19 in Africa". The BMJ. doi:10.1136/bmj.n457.

— DocWatson42 (talk) 11:16, 21 February 2021 (UTC)

Possibly add date range on daily deaths bar chart graph

Anguswalker. I suggest putting the end date on the top left side of your "Daily count of Covid-19 deaths reported to WHO as of ..." graph series from now on. There is room there. Something like: "Through June 12, 2021"

Or the whole date range:

Jan 22, 2020 to June 12, 2021.

It is easy to do. I sometimes add clarifying text to various images I upload to the Commons. I use freeware Irfanview to do it. --Timeshifter (talk) 03:02, 15 June 2021 (UTC)

Anguswalker. Here is the old out-of-date bar chart graph that was in the article.

I substituted this regularly updated graph:

Graph showing the daily count of new confirmed deaths worldwide. Rolling 7-day average.

References

--Timeshifter (talk) 14:29, 6 September 2021 (UTC)

Monthly cumulative death pages with daily data have been deleted. Need external links

All the monthly death data pages with daily data were deleted. See:

• Wikipedia:Articles for deletion/COVID-19 pandemic deaths in July 2021

The closing admin gave his reasons here:

• User talk:Sandstein/Archives/2021/September#Wikipedia:Articles for deletion/COVID-19 pandemic deaths in July 2021

That discussion will probably be archived soon. Check the Sandstein talk archives then.

Weekly death data by country, instead of daily data, may be an alternative. See this example:

• User:Timeshifter/Sandbox157

It would be nice if there were tables by country with weekly death data among the official source pages. They would function as an historical record of this once-in-a-century pandemic. They could be studied by researchers and historians to see what worked and didn't work in neighboring countries. Cumulative deaths and deaths per million over time would both be very useful in a weekly data format.

I have not found tables of deaths over time (daily or weekly) anywhere other than the deleted tables on Wikipedia. Here are 2 major lists of COVID-19 data sources to verify this:

• https://github.com/CSSEGISandData/COVID-19
• https://github.com/owid/covid-19-data/tree/master/public/data

If those tables are created elsewhere please link to them from COVID-19 pandemic deaths in the external links section. --Timeshifter (talk) 14:52, 6 September 2021 (UTC)

Nov 1, 2021 column added

See:

• Help:Table#Picking selected dates from massive .csv files - Section name may change.
• Template talk:Monthly cumulative COVID-19 death totals by country#2021 template and sandboxes

--Timeshifter (talk) 01:26, 6 November 2021 (UTC)

Scrolling versus expanded tables

Jroberson108. See diff. Edit summary: Cumulative monthly death totals by country: "Use templates that duplicate data both on this page and COVID-19_pandemic_by_country_and_territory. These templates provide support for top-sticky column headers so always visible during scroll."

Until that edit we had expanded tables here. Much as I would like to use scrolling tables with sticky headers in many more list articles, I am not sure it is OK here. See:

• Help:Table#Scrolling - it refers to MOS:SCROLL:
• Wikipedia:Manual of Style#Scrolling lists and collapsible content

My impression was that an exception was made at COVID-19 pandemic by country and territory to allow scrolling tables since it was a long article. And that it was considered OK because we linked to COVID-19 pandemic deaths and other articles that had the expanded tables.

But I would really like to know what people using current screen readers think of these scrolling tables. Maybe you can ask some of them to look at the scrolling tables in COVID-19 pandemic by country and territory. In the meantime maybe we should put back the expanded tables here until we know for sure what is acceptable? --Timeshifter (talk) 17:06, 6 January 2022 (UTC)

I'm OK either way. It doesn't make sense to me to update the exact same tables in two different places. My impression of MOS:SCROLL is it takes issue with an initial "hide all" state of the content and having to click "show all" to display it. In this case, there is no initial "hide all" state, only content that is "scrollable" or "not scrollable/expanded". In essence, these tables have all content accessible in both the "scrollable" and "expanded" states, so nothing is really hidden. Jroberson108 (talk) 19:57, 6 January 2022 (UTC)

Timeshifter I just tested the page on Desktop Firefox with CSS turned off and, as expected, all data shows as "expanded" with no scroll. There is no JavaScript involved, so nothing to test there. On mobile, you see the same thing as Desktop except the headers aren't sticky. Something I'm probably going to attempt to fix in the near future. Jroberson108 (talk) 20:14, 6 January 2022 (UTC)

I tested the smaller 2022 table with Windows Narrator, which I presume is a common screen reader, and it didn't have any issues reading from the table or reading beyond page one of the scrollable area. Jroberson108 (talk) 20:54, 6 January 2022 (UTC)

Graham87. What is your opinion on all of this? --Timeshifter (talk) 03:01, 7 January 2022 (UTC)

I have no opinion; it doesn't affect totally blind screen reader users. Graham87 03:30, 7 January 2022 (UTC)

Thanks Graham87. Then I guess we can keep the scrolling tables in both of these articles:

COVID-19 pandemic deaths

COVID-19 pandemic by country and territory

Jroberson108 and Graham87. There are various by-country list pages with multiple tables that would be a lot easier to use if scrolling tables with sticky headers were used. By-country list pages with multiple expanded tables can take forever to scan down the tables to get to the table you want. When scrolling tables are used it is easy and fast.

Also, by-country list pages with many column headers would be so much easier to use and comprehend if the headers were sticky. You don't have to guess what a column is about. For example, these pages with many columns:

List of countries by minimum wage

List of countries by incarceration rate

List of countries and dependencies by population

Some of the tables should actually be broken into 2 tables in order to narrow them, and thus make them easily visible on mobile screens. It is not done now because it would make the articles much longer, and greatly lengthen the time to scan down the page. But converting them to scrolling tables gets rid of that problem. It is very fast to scan down COVID-19 pandemic deaths now. I hope to split the 2020 table in that article since it is too wide for many cell phones.

--Timeshifter (talk) 06:11, 7 January 2022 (UTC)

@Timeshifter: Adding a vertical scrollbar to long tables or anything long is easy enough without using a template or CSS file. You just need to wrap the content in <div style="max-height:95vh; overflow-x:auto;"></div>. The "95vh" limits it to 95% of the vertical height. I wouldn't suggest using "100vh" as you need some white-space to scoll past the scrollable content. The covid tables use 75vh in Template:COVID-19_pandemic_data/styles.css, which in my opinion could be higher.

Regarding breaking apart the 2020 table, which might be better to discuss on the template talk, I don't think the issue is the table width, but rather that there is a lack of sticky row headers, which should be the countries without flags. That's part of my to-do with making the column and row headers sticky for mobile. In making them work, I would suggest moving the flag to it's own column after the country name so just the country name sticks without the flag, allowing for more visible data during scroll. Countries use <th> and flags use <td> for accessibility. In other tables that use (*), if all have covid pages, then remove the (*). If very little don't have covid pages, then reverse it so (*) indicates no covid page and is less used. Jroberson108 (talk) 12:08, 7 January 2022 (UTC)

Jroberson108. I have my Firefox browser set with a zoom bar for text size. Right now it is at 150%. 75vh barely fits. I sometimes go higher than 150%.

Jroberson108 and Tol. I would like separate CSS stylesheets for the automatically filled in scrolling tables versus the manually filled in scrolling tables. The people who originally fine tuned the manually filled in scrolling table stylesheet spent a lot of time fine tuning it for various browsers in both desktop and mobile screens. It needs more fine tuning. I think that would be easier, and less complicated, if it was separate from what is being done with the auto-tables.

For manual templates I don't want to pull out the flags into a separate column if at all possible. There may be hundreds of thousands of tables on Wikipedia with the flags in the same cell as the country, state, province, or other subnational area name. So I want people to be able to convert those tables easily to scrolling table templates with sticky headers. Is there some way in the template CSS to delete the flag from the first column when the sticky row header kicks in? If not, then maybe we could substitute a different flag template that puts the flag in a separate column. I guess it could be implemented via a mass find-and-replace. I guess that additional work would be worth it to get sticky row and column headers.

The specialized country links (marked with *) were the result of some extensive work by several people. See:

• User talk:Pppery#Re: Template:flaglist+link

Pppery did the final work. See the current number of tables using the asterisk method: The use of {{flagg|us*eft is found with this global search within wikitext. Note that sometimes there are only a few specialized links in a table.

I am only recently getting better in using the browsers on my iphone SE 2020. My cell phones over time have always been mainly emergency phones for car towing. I now see that even after dividing the yearly death tables in half they are still too wide on my cell phone. The last column is past the edge of the screen. So I see the need now for sticky row headers too in some cases. I wish though that row headers had a white background. Or maybe you could figure out a way to make the first column sticky without having to make it a row header column. Also, that is not an easy find and replace. Row headers have to be on a separate line of wikitext. --Timeshifter (talk) 21:31, 7 January 2022 (UTC)

@Timeshifter: "75vh" is supposed to "barely fit" and will always be 75% of the vertical height of 150% zoom or 75% zoom. Same goes for mobile/tablet when switching between portrait and landscape mode. There isn't a pure CSS way to hide the flags during the scroll event; JavaScript/jQuery is needed. For accessibility, the country name should be the row header, not the image, which these tables have no row headers. I tested using the "t" flag in "flagg" to separate as table cells, but it doesn't work properly with <th> and incorrectly assigns attributes. Moving the flag is just a suggestion for accessibility and to minimize the sticky data while maximizing the scrollable data on small devices. To move the flags, the following code would work, which I could easily do a find and replace in Sublime Text using regular expressions. As far as I remember, the current "styles.css" doesn't support having row headers because it makes all headers top sticky, so test first.

! scope="row" |{{flagg|xx*ef|pref=COVID-19 pandemic in|United States of America}}
| style="text-align: center;" |{{flagg|cxx|United States of America}}

Regarding the asterisk (*) in the 2022 table, there are exactly 234 locations with asterisks and 2 without covid links, which are difficult to find with almost all having asterisks: "Holy See" and "Saint Martin". I'm not suggesting they change how "flagg" works, but we can remove the "*" flag from "flagg" and manually add an asterisk to two cells, which eventually those pages may exist too. Regarding row header styling, styles.css can easily target all row headers or even the first cell of each row. As far as creating different styles.css files for each table/template, one file would be easier to manage given the same style is being applied to multiple tables, but you need to keep track of where it is used which is why I tried to put together a list of templates using it (Template:COVID-19_pandemic_data/doc#Style_sheet). Jroberson108 (talk) 00:54, 8 January 2022 (UTC)

I don't think it is a good idea to have 2 different uses of the asterisk for country names. One showing a specialized link, and one showing that the link is not specialized. Consistency is better so that occasional Wikipedia readers don't have to always read the notes above tables. They soon learn that an asterisk is a specialized link. Internal links are supposed to go where their name implies. Unless there is an asterisk. This went through multiple discussions on TFD and elsewhere.

We could maybe get consensus to change {{flagg}} so that there is no space in front of the asterisk.

About 75vh versus 95vh. When I look at the scrolling tables in COVID-19 pandemic deaths they take up a different percentage of the vertical screen height depending on my font size percentage setting in the Firefox zoom bar for font size setting. My main monitor is a 27 inch monitor. Screen height is a little less than 13.5 inches. Usable space between the toolbars varies depending on zoom setting.

At 170% the scrollbar on the 2022 table is almost 9 inches. Usable space is less than 10.5 inches.

At 150% the scrollbar on the 2022 table is almost 9 inches. Usable space more than 10.5 inches.

At 100% the scrollbar on the 2022 table is almost 9 inches. Usable space is 11 inches.

If it were 95vh I would have to be much more precise in scrolling up and down the page in order that a scrolling table was fully visible. My mouse can't do that unless I actually drag the far right scroll bar.

Right now I can do it by using only the scroll wheel on my mouse. As imprecise as it is. I don't want to make it too precise in mouse settings, because then it would take much longer to scroll up and down pages with just the mouse.

Template:COVID-19 pandemic data/styles.css

That stylesheet was first created long before it was also used for the auto-templates that came much later.

I am not saying there should be a separate CSS page for every Covid table template. I am saying we need 2 CSS pages. One for the manual Covid table templates, and one for the auto-templates. The auto template formatting is different. It has a separate column for flags, for example, in some of the auto templates.

--Timeshifter (talk) 08:30, 8 January 2022 (UTC)

It sounds like you have no issues with the current setting of "75vh"? If "95vh" doesn't leave enough white-space, you can also test "90vh", "85vh", and "80vh". "75vh" may end up being the one that gives the right amount of "comfortable" white-space. I'm less worried about desktop users and more for mobile since the mouse is none existent. The only setting I'm not OK with is "100vh". Regarding asterisks, there will always be a note explaining what it means, which each table can word as they like, so the "flagg" discussion has nothing to do with it unless a policy has been added. If they wanted to force it, then they wouldn't have added the option of removing it. The 2022 table is the only one using it, so there is no question of consistency. Regarding CSS, I don't think the style sheet does anything different for a separate flag column, so I'm not sure what the concern is. I recall some country specific tables using the same style sheet that have no flags. Jroberson108 (talk) 13:09, 8 January 2022 (UTC)

75vh barely works for me.

If we separate out the manual tables with their own stylesheet, then we can do some more experimenting without risking messing up the more complex auto-templates.

The TFD discussions that led to the flagg implementation concluded that there needed to be some indication that a specialized country link was being used. See:

Wikipedia:Templates for discussion/Log/2021 July 19#Template:Flaglist+link

A dagger was not liked. "More" took up too much space. GKFX, Pppery, and I liked the asterisk. The template actually had 2 links. Both the regular link, and the specialized link ("more"). That was felt to be unnecessary. The original author of the template was uncooperative. There were other issues with the template. So it was deleted. Pppery replaced the many transclusions of the old template with the asterisk one. That meets the MOS:EGG requirement of the specialized link.

I believe there is a limitation of 500 uses of this version of the {{flagg}} template per page. So I only used it on the 2022 template. The other years are just regular country links. See this doc file section:

Template:Flagg#Adding links to specialized country, state, territory articles

--Timeshifter (talk) 14:24, 8 January 2022 (UTC)

A correction to my earlier statement, using ! scope="row" doesn't appear to be a problem with the style sheet, again test first. We should probably continue any style discussions where it matters most: Template_talk:COVID-19_pandemic_data/styles.css. Regarding the conversation you mentioned, they discussed deleting "Template:Flaglist+link" and, if there are differences in links, making that difference "clear where the link goes" with the use of an asterisks and notes explaining the asterisks. MOS:EGG only states "make sure that the reader knows what to expect when clicking on a link", which in a table the asterisks and an explanatory note is sufficient if differences exist. If all were special links, then no asterisks and an optional "general" note would suffice, which in this case the table is about COVID-19, so related links aren't unexpected. Nowhere does it say that the asterisk has to represent a specialized link as opposed to the default country link, only that the difference needs to be clear. "flagg" added a way to add the asterisk for special links, but it is optional to allow for certain circumstances like this one. The note could say "* indicates doesn't link to a special COVID-19 page" or something better. Having 2 asterisks instead of 234 asterisks makes the difference more apparent and easier to find and is less for a screen reader to read, which better follows MOS:EGG on "plan your page structure and links so that everything appears reasonable and makes sense". This is more about a practical, common sense application. If the table only had two specialized links, then it makes more sense to label just those two with asterisks and explain accordingly. Regarding the 500 limit use of "flagg" per a page, I don't see where it says "500" and it does specify the limit is for the use of the "f" flag. I'm aware the "f" flag is only used on the 2022 table, which makes most sense on a page with current and historic tables, especially with a limited use. Jroberson108 (talk) 17:19, 8 January 2022 (UTC)

I can't remember where I read the 500 number. But the specialized link implementation is definitely expensive.

As for alternating whether the asterisk is for specialized country links or regular country links, I am mainly concerned about consistency. Technically though, you are probably correct that a note at the top of the table could explain it either way.

But MOS:EGG is not satisfied in my opinion if there are specialized links and no note. If all the links are specialized, then no asterisks are needed. But a note is still needed. And if all the links are specialized, then there is no need to use the expensive function at all. Then the specialized links can be used without fear on multiple country tables on the same page. Via find and replace.

If there are only a few links that end up not specialized, it is still good to use the expensive function. It is used any time the page is saved. Those few links may end up as working specialized links eventually. When that happens, then the expensive function can be removed. But the only way to see that is if the asterisk shows up. --Timeshifter (talk) 20:27, 8 January 2022 (UTC)

I just did a check for the missing covid pages. I found COVID-19 pandemic in French Saint Martin, which probably just needs to be renamed to "COVID-19 pandemic in Saint Martin" to work or the special link updated to include "French". Covid news for the "Holy See" can be found here at COVID-19 pandemic in Vatican City, which is a special link that excludes the text "Holy See", so I'm not sure if that can be done with "flagg". I agree that a note is needed even if all are using special links and without asterisks, but that is my personal preference. If those two links work, then all don't need asterisks and a general explanatory note can be added, which satisfies MOS:EGG. If you want, I can do a regular expression find and replace to remove "flagg" usage on the country names and keep the special links. The flag image would still use "flagg" and would link to the country page, but it wouldn't use the "f" flag so no limit issues. This way all the old tables can still use the special links and have an explanatory note added. Just let me know which tables to change if you want me to. Jroberson108 (talk) 23:56, 8 January 2022 (UTC)

There is also COVID-19 pandemic in Sint Maarten. I think technically the location "Collectivity of Saint Martin" includes the above mentioned "French Saint Martin" and this "Sint Maarten", so not sure if two links should be added for "Saint Martin" which links to Collectivity of Saint Martin? Note, both covid pages have some news about each other, so not exclusive to the location. Jroberson108 (talk) 00:23, 9 January 2022 (UTC)

@Timeshifter: A MOS:DAB page could be created for "COVID-19 pandemic in Collectivity of Saint Martin" (maybe add "the"?) where the "French Saint Martin" and "Sint Maarten" COVID-19 pages are listed. According to Saint_Martin_(island), there is a French (Saint-Martin) side and a Dutch (Sint Maarten) side to the collectivity. "Holy See" says it is headquartered in and governs "Vatican City", so it makes sense to include it in the COVID-19 pandemic in Vatican City news, which "Holy See" linking to it makes the most sense to me. Disclaimer, I'm not a geography buff. Jroberson108 (talk) 14:06, 9 January 2022 (UTC)

Jroberson108. I created a redirect table. See:

• User:Timeshifter/Sandbox167. Redirects

Then I saved the 2022 template without making any changes.

• Template:Monthly cumulative COVID-19 death totals by country 2022 first half

That caused {{flagg}} to fix some links. Only 2 are not specialized links now: Bahamas and Holy See. I can't figure out why the Bahamas link is not specialized. The necessary redirects exist for it. And there is a Bahamas Covid article:

• COVID-19 pandemic in the Bahamas

I did a mass find-and-replace from the Wikipedia edit window of this sandbox version of the 2022 template:

• User:Timeshifter/Sandbox168 - I replaced flagg|us*eft with flagg|uspet

All the links except the 2 red links are correct. No expensive functions used. So it can be done on all the previous years too. Can you tell me how to fix the 2 red links? I want their names to be the same, but they should link to the specialized links:

• COVID-19 pandemic in Vatican City - so: Holy See
• COVID-19 pandemic in the Bahamas - so: Bahamas

Those 2 links don't have to use {{flagg}}. Another flag template could be used. I haven't had time to study that yet. --Timeshifter (talk) 20:22, 9 January 2022 (UTC)

For Bahamas, the difference seems to be in "The" and "the" where "flagg" is looking for "COVID-19 pandemic in The Bahamas" but needs to be "COVID-19 pandemic in the Bahamas". A rename or redirect might fix it. Are you talking about the five red links here: User:Timeshifter/Sandbox167._Redirects? Jroberson108 (talk) 20:41, 9 January 2022 (UTC)

The "s" flag for span shouldn't be needed since all have similarly sized images and the "t" flag for alignment shouldn't be needed since the table cell is aligned and that flag is probably used in conjunction with the other "t" flag for table cell: "flagg|uxpe" or "flagg|cxpe", where the latter links the flag to country and the country name to covid page. Jroberson108 (talk) 21:01, 9 January 2022 (UTC)

Template:Country_data_Bahamas says "The". According to Template:Flagg#Text_and_link_parameters, there are some additional things you can do with "flagg" by using the parameters "|the", "|pthe=", and "|nthe=" to remove "The" from the link so "the" can be added to the special link. I think redirecting "The" to "the" would be the easiest approach. Jroberson108 (talk) 21:16, 9 January 2022 (UTC)

Jroberson108. See the show/hide box here:

User:Timeshifter/Sandbox158. Redirects. List

I copied most of it to here:

User:Timeshifter/Sandbox167

Not all of the links are needed for the 2022 table. That is why some are red links.

I redirected the Bahamas link as you suggested. That solved the Bahamas link problem.

COVID-19 pandemic in The Bahamas redirects to COVID-19 pandemic in the Bahamas

Holy See link is fixed:

{{flagg|usx|Holy See}}[[COVID-19 pandemic in Vatican City|Holy See]]

 Holy See

So all the links in the 2022 table are specialized links:

User:Timeshifter/Sandbox168

And no expensive functions were used.

The "t" flag is needed for alignment. I tested it in the 2022 template in User:Timeshifter/Sandbox168. You can test it on a link there via the preview function.

The "s" flag is needed. I did a mass find-and-replace in Sandbox168, and then previewed it. Some of the flags do not line up straight without it.

I don't like having 2 links on each line. That is overkill, and just makes for more kilobytes to load. Especially with multiple tables.

--Timeshifter (talk) 01:21, 10 January 2022 (UTC)

@Timeshifter: Good to hear it works. I guess if you aren't using <th scope="row"> along with "plainrowheaders" to left align the contents, then I guess you do need the "t" flag. I meant to say the "s" flag can be replaced with "n", not "x"; non-breaking space instead of the longer span tag separator: "flagg|unpet". Jroberson108 (talk) 02:52, 10 January 2022 (UTC)

I just inspected the source code. The "s" flag adds a non-breaking space outside the "flagicon" span along with some inline styles while the "n" flag adds a non-breaking space inside the "flagicon" span without inline styles, so the "n" flag is less code. Jroberson108 (talk) 03:09, 10 January 2022 (UTC)

I looked at Saint Martin. Instead of a redirect, shouldn't COVID-19 pandemic in Collectivity of Saint Martin be a dab page that includes COVID-19 pandemic in Sint Maarten? Jroberson108 (talk) 03:23, 10 January 2022 (UTC)

Jroberson108. Saint Martin is short for the French part of the island. And it is the island name too. So, I don't know. You would have to look at the WHO source for the data, and see what exactly they are referring to.

The "n" flag does not work in lining up the flags.

--Timeshifter (talk) 03:42, 10 January 2022 (UTC)