Talk:COVID-19 pandemic by country and territory

The cases and mortality by country graph is misleading

It should include a note for each country about the way they count their deaths, just like it does for pandemic by location graph. 153.98.68.208 (talk) 11:02, 2 September 2020 (UTC)

No such graph on this page. Chris55 (talk) 15:57, 2 September 2020 (UTC)

Yes, there is... 2A02:A03F:689C:5100:1806:5E7D:D596:F7D6 (talk) 11:09, 7 September 2020 (UTC)

That's a diagram or map, not a graph :) But seriously, a small diagram can't include that much information. It might be possible in a table, if the information was available on a wide scale, but it's hard to come by and none of the diagrams show it. Belgium is of course one of the only countries to provide registered figures as a headline. Britain also has these figures and the difference grows wider every week. (41K headlined, 57K registered) Chris55 (talk) 16:12, 9 September 2020 (UTC)

SADR Free Zone has cases or not?

The article about the COVID-19 pandemic in Western Sahara now states there were 25 confirmed cases in the Free Zone - apparently there have even been cases since sometime in July, but the article kept citing no cases until a few days ago. Here and in COVID-19 pandemic in Africa the current state is still that there are no cases.

We should find out which of these statements is right, or say better, more up-to-date. But I guess there are some problems with translation of the sources in the way.

Furthermore, if there are really confirmed cases in the Free Zone now, would that mean we have to add Western Sahara into the cases/deaths and death rate tables? --2003:E7:7713:A738:A5C0:22CD:17C3:4DCC (talk) 22:22, 9 September 2020 (UTC)

SADR authorities reported the first Free Zone cases on 25 July 2020. In COVID-19 pandemic in Africa the text has now been corrected; here the phrase 'the Free Zone, administered by the disputed state of the Sahrawi Arab Democratic Republic, and' ought to be deleted.2A00:23C8:3A16:C600:50D0:767D:5361:BBEF (talk) 10:15, 22 September 2020 (UTC)

Pandemic by region table. Made narrower...

...so graphs fit to the right at narrower screen sizes

COVID-19 pandemic by country and territory#Pandemic by region

See this version. See diff.

Zoom the page to see that the graphs stay to the right longer than before. --Timeshifter (talk) 16:44, 10 September 2020 (UTC)

Sorry, I edited before I noticed this Talk section. I don't see that we have much benefit from these changes (and a column width specifification of 1em is just silly). People with small screens must be used to content stacking, and that's what happens (and happened) here. People with wide screens should be able to expect a reasonable exploitation of the available screen real estate, which isn't the case when we adamantly insist that the columns are just one word wide. I've got as much empty space to the left of the two graphs as the graphs themselves are wide (and I can't do anything about it). I should rent that space to Google Ads, or something. ;-)

Our tables (and content in general) should be responsive to whatever user-agent the visitor is using, and we can't know that in advance. — JohnFromPinckney (talk) 07:21, 11 September 2020 (UTC)

JohnFromPinckney. I left your change to style=width:5em;

I reverted your removal of style=text-align:left;

Why would you remove left alignment of text in the left column? It is standard procedure in tables. I edit Help:Table. --Timeshifter (talk) 12:56, 11 September 2020 (UTC)

I reverted your reversion of my removal of style=text-align:left;.

I did not really remove left alignment of text in the left column, I just removed the unneeded style code. But I did it to clean up the table (internally) and make it look like a standard wikipedia table (visually).

If left alignment of text is so standard, why is it the default for wikitable rows?

If you want left-aligned rows, use plainrowheaders, as I have now added. I stand by my edit summary that style=text-align:left; is unneeded, especially 14 times.

I have also reverted your reversion of my fix to the date format.

Next time someone undoes something you've just done, try to think of looking on the Talk page first. Possibly someone has tried to communicate with you per WP:BRD (as I did). I'll ping you @Timeshifter: so you don't edit before you come to Talk (I don't always check Talk first, myself). Regards,— JohnFromPinckney (talk) 04:15, 12 September 2020 (UTC)

JohnFromPinckney. You did the first reversion without looking at the talk page. And you did not add plainrowheaders until after I complained about the lack of left alignment. And I did look at your reply before making further changes. When I undid your illogical removal of left alignment I did not notice that date format change. So sorry about that. I am not the person that originally shortened that date. I don't believe it is a good idea though to use long dates for access dates in references. Especially when there are hundreds of references as with this article. By the way, MOS:DATE agrees with me that it is OK to use shorter date formats in references. I am not going to fight over it though since this article is using a long date format in references.

As for how people left align the first column opinions vary. Some people like plainrowheaders, some don't. I prefer the bold headers. I agree that having to add style=text-align:left; to the left column is a lot of effort and clutter. I have started 3 different threads at Village Pumps and Common.css pages about it. There is also a Phabricator task about it: T2418. Easier and better alignment within Wiki Tables. Many tables don't need row headers at all. They just need the left column aligned left, and the data columns aligned right.

If left alignment of text is so standard, why is it the default for wikitable rows?

The browser default for tables is center alignment for header cells (whether column headers or row headers), and left alignment for all other cells. Most data tables on Wikipedia need the left column aligned left, and the data columns aligned right. So the simplest current solution is to add style=text-align:right; at the top of the table wikitext. And style=text-align:left; or align=left to the left column cells. align=left won't work in header cells.

--Timeshifter (talk) 14:55, 12 September 2020 (UTC)

You did the first reversion without looking at the talk page. Yes, I know that. I said that. Why are you mentioning it?. We all agree it's true. And that's entirely in line with WP:BRD; you were bold, I reverted, then it was time to discuss. Which is why I immediately came to the Talk page. As I noted at the very beginning.

I did look at your reply before making further changes. Well, that's what's kind of set me off here. That behavior was inappropriate. You are expected to discuss conflicting editing ideas, not go do some reversions and then come defend your actions. Doing otherwise wastes time (we could have discussed your concerns about centered headers and talked about plainrowheaders, and after achieving consensus, then edited once) and it annoys other contributors.

By the way, MOS:DATE agrees with me that it is OK... I am not going to fight over it... Well, I'm glad you don't want to fight, especially as MOS:DATEUNIFY is part of MOS:DATE and, as you pointed out, the long form is "the format expected in the citation style adopted in the article". (In other words, MOS:DATE disagrees with you.)

Now we finally come to actual table formatting, and you've left me bemused. I know quite well what the browser default for tables is; you don't have to tell me, and I don't see what point of yours it serves to explain. You then say, Most data tables on Wikipedia need the left column aligned left, and the data columns aligned right. "Citation needed", as they say. I would very, very, very much like to see the sources for these two statements. I find the word "need" especially dubious. My experience is that about 60% of the row headings (your "left column") work well centered, and most (~85%?) of the data is best left-aligned. But it depends on the data you tend to work with. And I have absolutely no sources for my guesstimates, just my gut.

It (heading alignment) generally comes down to what editors on individual articles decide what works best, table for table. The standard is (as I know you know) bold centered for headers. But this seems like a good reason to tend toward this as standard, for the sake of uniformity project-wide, not away from it. IOW, it seems like it'd be good for the table in question. And it'd be bold, as is your preference. — JohnFromPinckney (talk) 21:12, 12 September 2020 (UTC)

JohnFromPinckney. MOS warriors spend an inordinate amount of time nitpicking. I already said that when I reverted your kneejerk reversion I didn't notice the date reversion, and apologized. Try being more graceful, and you'll get farther on Wikipedia in my opinion.

Browser default is not a logical reason for what works best in any particular table on Wikipedia.

And I am going to put the left column back to what looks best in my opinion: Left-aligned and bold. Unless you come up with a logical reason not to. If that leaves the wikitext a little cluttered, then so be it. The reader does not see the wikitext:

scope=row style=text-align:left;

Bold is easier to read in headers. Especially when some of the text in the headers is in a light blue color due to being linked. Normal-size light blue text on a gray background is not a great idea. Making the header links bold makes them easier to read if the text is linked. The bolded headers also use a darker blue for the linked text. See this version of the table with bold left-aligned row headers with linked header text:

https://en.wikipedia.org/w/index.php?title=COVID-19_pandemic_by_country_and_territory&oldid=977865879#Pandemic_by_region

In the meantime I will wait for the opinion of others.

And WP:BRD requires reading the talk first before kneejerk reversions. As you said, you did not do that. And since we both agree that the left column is fine left aligned, then you should have left it left aligned, and discussed further before changing it from bold to normal font. All just because you did not like the clutter. I had already done the work, so there was no need to revert. It was petty on your part.

--Timeshifter (talk) 23:38, 12 September 2020 (UTC)

The "nitpicking" you're complaining about stems in part from my perception that you're overlooking several details and making claims which are not quite accurate. I have the (perhaps overly pedantic) urge to offer some corrections. You said, above, a bit after you apologised (and thanks for that!), I don't believe it is a good idea though to use long dates for access dates in references. Especially when there are hundreds of references as with this article. By the way, MOS:DATE agrees with me that it is OK to use shorter date formats in references. I thought it important to point out what MOS:DATE actually says, which I thought would be useful to you if you're going to use it in further discussions.

And I, too, don't want to spend an inordinate amount of time, doing nitpicking or anything else. But that's one of the things I suspect you've missed: by not discussing here after by reversion, you wasted an inordinate amount of time. We're arguing about MOS:DATE, about plainrowheaders, about nitpicking, about BRD and who read the Talk page when; don't you think that's a waste?

And now to BRD. You wrote, And WP:BRD requires reading the talk first before kneejerk reversions. Please read WP:BRD. It requires nothing of the kind (although it doesn't seem to contain the word "kneejerk" anywhere). I'll summarize it again for you: you were bold, I reverted, I came here to discuss. Nothing kneejerk about it.

I'll accept that left-aligned can work for this table.

My thinking was, that if Timeshifter and others here prefer left-aligned row headers, we can use plainrowheaders instead of multiple style specifications. (No need to revert me, then partially revert your own reversion in two steps, and still miss the date thingy.) True, the reader does not see the wikicode, but editors do. I think removing unnecessary code ("clutter", as you say) is useful and usually A Good Thing^TM.

I, too, would like to have other editors weigh in. I fear, however, we may have scared them all off. :-0 — JohnFromPinckney (talk) 00:07, 13 September 2020 (UTC)

Well, let's wait for others to weigh in. And Wikipedia:BOLD, revert, discuss cycle often mentions looking for discussion first before further actions. --Timeshifter (talk) 20:13, 13 September 2020 (UTC)

Well, yes, let's wait for others to weigh in. And yes, yes it does. Exactly. — JohnFromPinckney (talk) 21:48, 13 September 2020 (UTC)

Pandemic by region table. Format choice

Table column from:

• COVID-19 pandemic by country and territory#Pandemic by region

There is a Phabricator task to make left alignment of a column much easier: T2418. Easier and better alignment within Wiki Tables.

In the meantime which table column below do people prefer? Left, middle, or right? I prefer the left column because light blue links on a gray background (right column) are not as easy to read or scan, especially for the visually impaired. Right column may meet minimal contrast requirements, but it is not as good as the left column where the blue links are bold, and use a darker shade of blue.

• Option B is the browser default for row headers. Text is center aligned.

• Option A is created by using any text editor to globally replace scope=row in the wikitext of the middle column with:
  

scope=row style=text-align:left;

• Option C has the same wikitext as the middle column, but it removes bolding and adds left alignment by adding class=plainrowheaders at the top.

Row headings, option A Region South America North America South Asia European Union and the UK Middle East Central Asia and Russia Sub-Saharan Africa Central America Other Europe Oceania and islands in East Asia North Africa East Asia Caribbean Totals

Row headings, option B Region South America North America South Asia European Union and the UK Middle East Central Asia and Russia Sub-Saharan Africa Central America Other Europe Oceania and islands in East Asia North Africa East Asia Caribbean Totals

Row headings, option C Region South America North America South Asia European Union and the UK Middle East Central Asia and Russia Sub-Saharan Africa Central America Other Europe Oceania and islands in East Asia North Africa East Asia Caribbean Totals

Row headings, option D Region South America North America South Asia European Union and the UK Middle East Central Asia and Russia Sub-Saharan Africa Central America Other Europe Oceania and islands in East Asia North Africa East Asia Caribbean Totals

By using a free app (CareUEyes Lite) I, like many others, keep my monitor at 80% of its maximum brightness. Due to this the background of my web pages are slightly gray instead of the bright white background at 100% brightness. Try it, your eyes will thank you. I can maximize brightness instantly via the app button in the taskbar. To watch videos for example. I am not alone in this lowering of brightness. It is recommended by eye doctors.

Anyway, this lowers the contrast of text (and especially the blue links) on a gray background. Because the gray background is a darker shade of gray. The default Wikipedia blue links and background color may meet minimal WCAG contrast recommendations on a bright monitor setting, but not on lower brightness settings that are very common. This can be shown with WCAG contrast checkers. First, see Help:Link color. The color of an unvisited internal link is #0645AD (a shade of blue). The header background color (according to Help:Table) is #EAECF0 (a shade of gray).

This combination minimally passes all the WCAG tests in this WCAG contrast checker:

• https://snook.ca/technical/colour_contrast/colour.html#fg=0645AD,bg=EAECF0

But a slightly darker shade of gray (see shades) does not pass all the WCAG tests:

• https://snook.ca/technical/colour_contrast/colour.html#fg=0645AD,bg=E8E8E8

That is why it is better to use the bold header text that uses a darker shade of blue. It increases the contrast, and helps readers, especially the visually impaired. Some of whom have complained about this.

A light yellow background creates even more contrast. But that is another discussion. For more ideas see:

• User:Timeshifter/Sandbox120

--Timeshifter (talk) 20:38, 15 September 2020 (UTC)

Thanks for your passion and attention to detail. I think the table looks pretty good as it is but in general, I'd vote for A, C, or D (just added this last option). If legibility is a problem, then A or D (see the second table on the page where this is already used).

Probably not worth the effort to debate much more in this context. A legibility issue should be discussed at a much higher level as it affects all of Wikipedia.

The totals at the bottom of the table should be right aligned. I'd remove the gray background as well... the bolding (and the bottom position and row label) should be sufficient to differentiate these as totals. On a related note, why is the Population column so wide? Is this just a limitation to allow flexible width? - Wikmoz (talk) 21:46, 15 September 2020 (UTC)

The Population column is as wide as the largest value: 7,590,384,083 at the bottom or "Population" at the top (I can't tell for sure which is longer). Are you seeing something significantly wider than that? I'm using the "modern" skin on Firefox.

As for gray shading, that's part of the visual indication that the headings are headings; they are meant to enhance understandability of the data we're presenting. I would really not like to see that removed. — JohnFromPinckney (talk) 22:26, 15 September 2020 (UTC)

That's fair. In that case, I'd vote for A. Yes, the population column appears much wider in the default theme. Can we right align and remove the background color from the totals? Something like:

COVID-19 cases and deaths by region, in absolute figures and per million inhabitants as of 5 September 2020

Region	Total cases	Total deaths	Cases per million	Deaths per million	Population
South America	6,567,184	208,599	15,521	493	423,117,093
North America	6,297,180	196,464	17,286	539	364,296,266
South Asia	4,678,052	81,103	2,578	45	1,814,388,744
European Union and the UK	2,295,988	182,312	4,474	355	513,213,363
Middle East	1,598,877	65,959	5,406	223	295,732,825
Central Asia and Russia	1,378,062	22,641	5,753	95	239,531,973
Sub-Saharan Africa	1,037,955	21,907	960	20	1,081,142,280
Central America	930,977	74,780	5,306	426	175,471,759
Other Europe	601,090	15,369	3,606	92	166,707,094
Oceania and islands in East Asia	511,439	13,547	900	24	567,962,253
North Africa	184,173	7,067	1,206	46	152,696,504
East Asia	182,992	5,312	104	3	1,752,240,948
Caribbean	159,088	2,799	3,625	64	43,882,981
Totals	26,423,057	897,859	3,481	118	7,590,384,083

Increased first column to 8em to prevent the Oceana row from wrapping to 3-lines. Set last column to 6em. Resolved last row alignment and shading. Excluded last row from sort. - Wikmoz (talk) 23:44, 15 September 2020 (UTC)

In order of preference: I prefer option D first, and then A, B, C. Most country and state tables on Wikipedia keep the white background for the left column of countries or states. It is obvious what the column is, and doesn't need background shading. And legibility is better for all people, including the visually impaired. --Timeshifter (talk) 02:01, 17 September 2020 (UTC)

You write, Most country and state tables on Wikipedia keep the white background

A. Prove it, please. Where do you get this information?

B. Do tables which have white-background left columns do so out of editors' personal preference, as you seem to be suggesting, or because the tables have yet to be marked up properly with !scope="row" coding per WP:ACCESS? And here, too: how do you know?

Regards, — JohnFromPinckney (talk) 10:04, 17 September 2020 (UTC)

I'm good with A or D. Timeshifter, it sounds like your preference is for D but you're OK with A as a second best option. It's clear that John really doesn't like D. Accordingly, let's run with A for now. We can perhaps continue the debate here and update again if necessary. On a related note, the table was last updated on Sept 5. Is there a regular update process? - Wikmoz (talk) 20:05, 17 September 2020 (UTC)

John, if you click on any of the region pages, most of them (with exception of Africa) do not apply background shading to the the left column when listing states. The same is seen in many Wikipedia articles listing countries (countries by population, countries by GDP, etc). So the Option D approach does seem standard. - Wikmoz (talk) 20:28, 17 September 2020 (UTC)

Hi, Wikmoz. Yes, that was rather the point of my question. I know that Africa has shading because I added the table mark-up to that page. I have not added the mark-up to the other articles, so they don't have it yet, and the background is white. The result is, that nothing about preferences has been proven for me either way. To me, it just looks we haven't gotten around to fixing all the articles on WP yet. — JohnFromPinckney (talk) 00:41, 18 September 2020 (UTC)

WP:ACCESS is out of date concerning the latest scope requirements according to WCAG. Simple tables don't require scopes. See:

H51: Using table markup to present tabular information | Techniques for WCAG 2.0. "Simple tables generally have only one level of headers for columns and/or one level of headers on the rows."

H63: Using the scope attribute to associate header cells and data cells in data tables | Techniques for WCAG 2.0. "Note 1: For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope."

People were on a mission to remove rowspans awhile back, but they are no longer a problem for modern screen readers according to this discussion section:

Wikipedia talk:Manual of Style/Accessibility/Archive 15#Rowspan and screen readers.

User:TheDJ (a volunteer developer on Wikipedia) wrote in reply to me in this WP:VPT discussion here:

The blind need scopes on all header cells that is simply not true. While good advice in general, all screenreaders I have worked with simply make their own header direction analysis for tables (because no one other than Wikipedia uses the scope attribute) or even completely ignore the direction of headers. So in practice it isn't really a thing. There is a difference between being a 'need' and an 'improvement/net benefit'. They can also be very useful for styling.

--Timeshifter (talk) 01:35, 18 September 2020 (UTC)

Here's what I think you should do: go to WP:ACCESS, arrange consensus on an RfC question (or textual rewording), pose that question in an RfC, and if widespread consensus agrees with all of your many claims which you keep posting and cross-quoting and linking to new "discussions" you keep starting, then you will have helped WP:ACCESS become current, we'll all know what guidelines to follow, and you can stop complaining that other editors do things you don't like the look of.

How's that for a plan? — JohnFromPinckney (talk) 02:18, 18 September 2020 (UTC)

Knock yourself out. No one is stopping you. --Timeshifter (talk) 07:33, 19 September 2020 (UTC)

Cases and Deaths

Please update all countries cases and deaths. Aldrin0000 (talk) 11:25, 26 September 2020 (UTC)