Template talk:Medical cases chart/Archive 1

Archive 1

Archive 2

Mobile view

@Alexiscoutinho: There seems to be a problem with the mobile view of this template. —hueman1 (talk • contributions) 10:43, 13 March 2020 (UTC)

Sorry, it turns out that this template {{2019–20 coronavirus pandemic data/Philippines medical cases chart}} has the problem. —hueman1 (talk • contributions) 12:06, 13 March 2020 (UTC)

I'm seeing issues with mobile view too. e.g. {{2019–20 coronavirus pandemic data/New Zealand medical cases chart}}. Should we be setting a smaller "barwidth" so that it renders properly on mobile? Something else?OceanKiwi (talk) 03:42, 5 April 2020 (UTC)

@OceanKiwi: Wrapping issues are almost always due to an incorrect numwidth. I wasn't clear in the documentation to encourage people to manually check if the number fits in the <span> through F12. Eventually, this parameter should be deprecated. I fixed the issue in the template by the way. Alexiscoutinho (talk) 21:03, 9 April 2020 (UTC)

Column Order

I would like to propose that the column order of this chart be changed. For evaluation of the outbreak dynamic the base of existing cases is the most important thing to visualize. Deaths are important but the growth of deaths does not influence the outbreak dynamic, which is the most important thing to study. So I propose that the column order be changed to

1. existing cases
2. recoveries
3. deaths

or if you want

1. existing cases
2. deaths
3. recoveries

But anyway be able to see those existing cases, and how the slope is developing.

I realize that this change would impact people enter the data and it would be a huge effort to make everyone change the column order. So I propose some way of making this template smarter so that the template would just render the column order differently. Or perhaps it could even be switchable by each user at time of viewing (JavaScript).

Where are these templates actually coded? Gschadow (talk) 21:50, 13 March 2020 (UTC)

Click 'Edit source' on the template pages. If there are only two alternating orders, then I don't think JavaScript is needed. However, the same JavaScript I plan on using or coding to fully implement the month buttons could be used to switch between order schemes. If more than one order are to be available, then changing all country charts won't be necessary. How would you propose to order the 4th and 5th classifications? Finally, consensus would only need to be reached on the default order, which would be the only one available on mobile as it doesn't support collapsing. Alexiscoutinho (talk) 23:22, 13 March 2020 (UTC)

Thank you! I still can't find 'Edit source' on the Template:Medical_cases_chart page. As to your question about the other categories: (4) estimated, (5) both, I haven't seen those in action. I am assuming "Estimated" should really be "Estimated in addition to confirmed" and a "Both" category seems to be a very bad idea in the first place. If anything in addition I would put a collapsible "Suspected" category instead of that "Both" thing. Then the order must be:

1. Confirmed ongoing cases
2. Estimated additional ongoing cases (collapsible)
3. Suspected cases (collapsible, collapsed by default)
4. Deaths
5. Recoveries

You can switch Deaths and Recoveries if you want, but it won't matter much. Looking at deaths as a curve is always going to be drowned out by the huge number of ongoing cases and recoveries, even if the death rate was 10% or, God forbid, 30%. So the alignment of deaths on a straight line isn't really so important. IMO sandwiching deaths before recoveries makes sense from a time line perspective: you will see deaths before you see recoveries. Gschadow (talk) 15:54, 14 March 2020 (UTC)

And thinking a bit more about the order, another thing that would make sense is to go strictly in the order in which the process would flow, and adding additional categories that might make sense:

1. Suspected cases (collapsible, collapsed by default)
2. Suspected, tested, ruled out (collapsible, collapsed by default)
3. Estimated, actual cases, minus the confirmed ones (collapsible, collapsed by default)
4. Confirmed, ongoing cases, not known to be relapses
5. Confirmed, ongoing cases, relapse, they should be subtracted from the recoveries.
6. Recoveries, without known relapses.
7. Deaths

Now that I'm thinking of relapses, it makes sense to push Deaths over to the end of the bar. That way a relapse category could be nicely shown between existing cases and recoveries so the reader can think of them either way as they wish. Gschadow (talk) 16:22, 14 March 2020 (UTC)

Firstly, bruh... Template code; check Help:Template for information on templates. So anyways, what I meant by 4th and 5th classification was more generic than what you thought. That example I made was just a random thing to show the syntax. A proper example that uses those two classifications is the Chinese chart which is now embedded in the documentation. Check February and tell me what order you propose. I like the idea of collapsing individual categories though. It could be used to show zoomed in versions of a classification. For example, if the user choses just deaths, he could view just them, but with a different, bigger scale. Alexiscoutinho (talk) 02:35, 15 March 2020 (UTC)

Does anyone know how to edit this template to change the order of "deaths, active cases, recoveries" in the bar? The order makes it very difficult to tell if the active cases is decreasing compared to the recoveries and deaths. People want to know when the number of "positive" infections are in decline. No one cares about the total cases. This graph uses the numerical data under "# of cases" and then bar charts "active cases". Are those the same thing or not? its confusing. Why is this chart different than the one being used for China? That one is much more clear in terms of separating the relationship between active infections and recoveries by moving recoveries to the end of the bar. Why would we want recoveries in between active cases and deaths? That relationship doesn't make sense. Can anyone help with this issue? 47.36.229.219 (talk) 14:56, 29 April 2020 (UTC)

Better explanation of numwidth?

My guess for t is that t=thin, m=medium, w=wide, but n=narrow? meaning narrower than t? and d = dreadfully-wide? And are these widths of bars or of text numbers? Are they minimum, default or maximum widths? Clarifications/answers would be best edited directly into the template description... Boud (talk) 23:19, 14 March 2020 (UTC)

I explain that in the paragraph below the Rows syntax. But I can write a note pointing readers to that paragraph for more explanation. Alexiscoutinho (talk) 02:19, 15 March 2020 (UTC)

I'm looking for an explanation but cannot see anything resembling one. Fanx (talk) 19:45, 15 March 2020 (UTC)

Is this: numwidth is a sequence of the initials of none, thin, medium, wide and default and it determines the width of each number in the data columns. the explanation? Suppose we have two columns for total counts and percentage increase, which is what most of the SARS-CoV-2 charts are doing. My guess is that we want xx in this common case. Switching between 'nn' and 'ww' to me seems to affect not the numerals and percentage symbol, but rather the widths of the bar and the empty space to the right of the bars. So is the space after the widest bar considered to be "column 1" or "column 2"? Obviously, we have access to the code to see what's coded :), but I'm not the only one who's confused or lacks the time to sort this out... Boud (talk) 03:42, 16 March 2020 (UTC)

I think examples will clear out this confusion. Alexiscoutinho (talk) 12:56, 16 March 2020 (UTC)

Line break in row

Any fix for this? Line break in Australian data for 15 March Fanx (talk) 19:51, 15 March 2020 (UTC)

The graph was missing a factor property to adjust the size of the bars, which is now added (it also needs to be updated as the number of cases grows). Ideally the width should be managed automatically but it'll take some more advanced scripting to do so. I'll try to fix it later if I can. CheeseBuffet (talk) 23:09, 15 March 2020 (UTC)

@CheeseBuffet: It's implemented now. The Chinese chart already has it. Alexiscoutinho (talk) 20:21, 26 March 2020 (UTC)

Possible rename of parameter 'factor'

Either factor should be renamed to divisor, or the script should be converted to make factor into a factor rather than a divisor, because using the inverse word to what is meant is confusing. :)

However, because this affects many pages, so it would have to be quickly edited in all the pages using it, or there would have to be a transitionary period during which factor is deprecated.

In the long term, this would be worth it to reduce confusion. There are still many SARS-CoV-2 country pages using stacked bar or no medical cases chart at all, so fixing it now might be better than later. Boud (talk) 03:58, 16 March 2020 (UTC)

(BTW, excellent initiative and congratulations to whoever started this generic epidemic medical cases template. A few bugs don't invalidate the work. :)) Boud (talk) 03:58, 16 March 2020 (UTC)

Thanks! I'll create an alternate parameter divisor, update the charts using factor and then remove it altogether. Alexiscoutinho (talk) 13:10, 16 March 2020 (UTC)

Alignment

Is it possible to customize the alignment of this template @Alexiscoutinho:? See 2020 coronavirus pandemic in South Korea and 2020 coronavirus pandemic in the Philippines where there is an awkward out of place whitespace left of the template. This issue could be fixed if the table could be made centered align.Hariboneagle927 (talk) 04:16, 16 March 2020 (UTC)

It is already centered. If you are talking about the whitespace left of the dates, then it could be altered in {{Bar stacked}}. I haven't touched more there because I wanted to raise a consensus across all bar templates in Template_talk:Bar_box#Consensus_about_paddings_and_alignments, but nobody saw it. However, while consensus is not reached, we can do whatever we want with {{Bar stacked}}. Do you prefer padding scheme C, which removes all double paddings? Alexiscoutinho (talk) 12:45, 16 March 2020 (UTC)

In my Browser I see a similar problem in the site about coronavirus in Italy. The number of deaths in round brackets (I suppose the 10. argument in Template:Medical cases chart/Row) appears in two rows. It's therefore difficult to read the numbers (they digits of ONE number are shown in TWO rows). The whole structure of the templates is too complicate for me, to try to find a solution :-) Yomomo (talk) 11:43, 18 March 2020 (UTC)

It's because they put two numbers in the slot of one and, even with the "xxxw" (wide) numwidth, it doesn't fit and wraps into two rows. When I have the opportunity, I'll tell them to pick only one change for deaths. Alexiscoutinho (talk) 08:21, 19 March 2020 (UTC)

Hover to show numbers

Can anyone make it such that if you hover over the bars, it shows their width? If it were done, it would mean that actual numbers would be visible as well as just graphical data, which is useful for large epidemics, etc., where very large figures are involved. I do not know how to do it myself, but hope that it might be possible and thought the idea worth airing. WT79 The Engineer (talk) 21:26, 18 March 2020 (UTC)

That's a great idea and it can be easily done with the title attribute! Alexiscoutinho (talk) 08:39, 19 March 2020 (UTC)

@WT79 The Engineer: DONE. Is this what you expected? Alexiscoutinho (talk) 04:08, 21 March 2020 (UTC)

@Alexiscountinho: Can't see any difference. WT79 The Engineer (talk) 10:37, 21 March 2020 (UTC)

@WT79 The Engineer: Are you sure? Hover over the bars of the Applied examples' charts in the doc. Alexiscoutinho (talk) 21:42, 21 March 2020 (UTC)

@Alexiscountinho: Thanks – working now. Yes, that was what I was thinking of – thank you. WT79 The Engineer (talk) 22:39, 21 March 2020 (UTC)

One further thought – would it be possible to have it such that it gave a descriptor as well as just a raw number? For example, it could be that 143 people have died, so hovering over the 'deaths' bar would show you '143 deaths' not just '143'. Would this be possible? WT79 The Engineer (talk) 23:20, 27 March 2020 (UTC)

But it would clunky for classifications with long names, like "12289 clinically diagnosed (C.D.)". Alexiscoutinho (talk) 13:29, 28 March 2020 (UTC)

@Alexiscountinho: Yes, but if people don't like the long text under their cursor they can just move their mouse away – they needn't hover over the bars all the time. WT79 The Engineer (talk) 15:37, 12 April 2020 (UTC)

I would support this change, still should happen. ɱ (talk) 18:15, 6 July 2020 (UTC)

Support for DMY dates

Is there any chance of adding support for the most common date format rather than just YMD & MDY? Fanx (talk) 00:46, 22 March 2020 (UTC)

The date "can be in any format accepted by PHP's strtotime() function". But don't make it too big, though, as it has to fit in a limited space allocated to the first column. Alexiscoutinho (talk) 17:35, 22 March 2020 (UTC)

The date should be able to be in any format, depending on which country the epidemic is in. WT79 The Engineer (talk) 17:53, 22 March 2020 (UTC)

By the way, DMY is already supported, not MDY: {{#time:M|03-04-2020}} returns Apr. Alexiscoutinho (talk) 19:52, 22 March 2020 (UTC)

This is simply not true, and to use an example date earlier than 13/M/Y is rather pointless. DMY dates are normally formatted as 29/02/2020 - not as 29-02-2020 ... dashed dates work, slashed dates don't - except in the case of MDY dates (they are supported, in spite of your claim) which render as 02/29/2020 but not as 02-29-2020. Also, MDY dates work with dropped zeroes (2/29/2020) but DMY dates (29/2/2020 or 29-2-2020) don't work. Instead of claiming dates are supported, please try testing for them first. BTW; demonstrating that the 3rd of April is indeed in April is less than useful. Fanx (talk) 00:51, 23 March 2020 (UTC)

If you know so much, then you should have asked for the {{#time:}} function to support these date formats or to drop its use entirely. I don't think dropping the usage of {{#time:}} in favor of "looks" is good enough. Firstly, because automatic month and time interval detection (for collapsing, which will eventualy be fully developed) won't work if only one parameter (this custom date) is given. Secondly, this template is in the English Wikipedia which is the most international, thus allowing for local date formatting would break the consistency I'm trying to achieve with this template and might confuse international readers who might not be aware of the local date formatting. Remember that the chart will be in English, thus the date should be English compatible. If you know how to make {{#time:}} work with DMY without losing functionality I'll gladly listen. Alexiscoutinho (talk) 21:10, 24 March 2020 (UTC)

Column width

Is it possible to increase column width in order to be able to show the absolute difference in the number of cases/deaths AND the percentual increase next to the cases/death total numbers? At this time, when trying to show both of them the text wraps around and it messes up the look of the chart (especially for countries with large numbers, as Italy). Robotrandom (talk) 17:03, 22 March 2020 (UTC)

I think it is inadequate to show 2 numbers inside the brackets. Remember: this is a chart, not a spreadsheet and we don't want to bloat it. Choose either absolute or relative change for each column. Also note that the chart now features "tooltips" on the bars so the user can hover over the death bars to see the number. Alexiscoutinho (talk) 17:28, 22 March 2020 (UTC)

@Ahecht: I noticed you recently implemented a changetype "both", but I was against it in the past to avoid super wide charts as suggested above. In the early days of this template, people used the second (double) column to show the other change type and, after a second thought, I approved it and added the numwidth "none" option to omit the third span. I think both changes should only be shown if only one case classification is to be expanded. Alexiscoutinho (talk) 20:08, 22 April 2020 (UTC)

@Alexiscoutinho: I can disable changetype=both if there is data in the second column. --Ahecht (TALK
PAGE) 20:12, 22 April 2020 (UTC)

@Ahecht: That's a valid solution, but don't you think that both changes should be left aligned instead of being put one after the other with a '/'? That's what I did in the past by ommiting the 3rd and using the 4th span and I think it would look neater. Not sure if it's better to have one wrapping () pair for each change or one for both. Alexiscoutinho (talk) 20:22, 22 April 2020 (UTC)

@Alexiscoutinho: I see what you mean. I'll think about how to implement that with the current automatic calculation scheme. --Ahecht (TALK
PAGE) 20:31, 22 April 2020 (UTC)

 done here. --Ahecht (TALK
PAGE) 20:56, 22 April 2020 (UTC)

Documentation no longer hidden

I fixed the noinclude section for the documentation page /doc. It doesn't quite have the style of standard template documentation pages, so someone might want to find out what's missing.

But at least the documentation is easy to find now.

Chances are this documentation is out-of-date. Lots of pages are using it, so feel free to update it...

Boud (talk) 14:36, 25 March 2020 (UTC)

The problem was with the include size. By turning the Applied examples' transclusions into links, the post expansion size drastically reduced. Alexiscoutinho (talk) 14:59, 26 March 2020 (UTC)

Ahhhh... I see. That's a bit of a pity, especially since the China data for March and the South Korea data can help people see signs for optimism... But I don't see a high priority in trying to avoid this tech restriction. Boud (talk) 15:10, 26 March 2020 (UTC)

It would have had to change someday anyways. However, we can probably get away with only one large template transclusion. But, it would have to use all features of the template, which I think none do right now. Alexiscoutinho (talk) 15:24, 26 March 2020 (UTC)

How do you figure out the percentage?

I was having trouble figure how you get pere net age of the number of deaths and cases added on the chart, can you give me and equation for it please? Rider0101 (talk) 20:16, 26 March 2020 (UTC)

For increases I presume? Take new daily number & divide by yesterday's daily number then subtract 1 and multiply by 100. So if today's number is 1,178 and yesterday's was 950 then the percentage increase is 1178/950 = 1.24 ... 1.24-1.0 = 0.24 .... 100*0.24 = 24% Fanx (talk) 01:04, 1 April 2020 (UTC)

Problems with data= v. rows=

I'd like to switch to using data= for several reasons, but two problems remain unresolved: I can't place a non-breaking space, as the semicolon at the end of the html-escape will be interpreted as data field delimiter. And also using the notes template inside data= breaks. Any suggestions? -- Käptn Weltall (talk) 08:37, 31 March 2020 (UTC)

What about {{nbsp}}? But, why would you need nbsp anyways? If it's to fit two numbers in the space of one, then I highly oppose it. I'm even thinking about removing this specific freedom in the future. On the other hand, about the notes template, which one are you having trouble with? The Italian chart has notes and they work fine... Alexiscoutinho (talk) 22:35, 1 April 2020 (UTC)

Is it possible to have a button saying "All"

Is it possible to have a button saying "All" (showing all data)? Christian75 (talk) 18:00, 4 April 2020 (UTC)

One could be manually created in the current togglesbar implementation. However, it would behave kinda annoying and not intuitively if other toggles are active. When the toggling features get revamped, there will be an 'All' button by default. Alexiscoutinho (talk) 22:26, 9 April 2020 (UTC)

Anyone know why Template:Val breaks this template?

COVID-19 cases in South Africa  ()
     Deaths        Recoveries        Active cases

MarMarAprApr

Last 15 daysLast 15 days

Date			# of cases
2020-03-05			1(n.a.)
⋮
2020-04-04			10,585
2020-04-05			10,655
2020-04-06			10,686

vs

COVID-19 cases in South Africa  ()
     Deaths        Recoveries        Active cases

MarMarAprApr

Last 15 daysLast 15 days

Date			# of cases
2020-03-05			1(n.a.)
⋮
2020-04-04			10<span style="margin-left:.25em(">585)
2020-04-05			10<span style="margin-left:.25em(">655)
2020-04-06			10<span style="margin-left:.25em(">686)

-- Jeandré, 2020-04-07t08:12z

@Jeandré du Toit: Because val outputs html which contains ; and you use ; as a separator in the data field. Your ; parser cannot distinguish between ; in the data entries and ; in the html. For cases like this I always advise people to use Special:ExpandTemplates to see what the template is generating. —TheDJ (talk • contribs) 08:49, 10 April 2020 (UTC)

Lua replacement

This template has been causing issues on numerous pages because its post-expand include size is so large. The reason it's so large is that when templates are nested, data is double-counted for each nesting. In this case, a template like {{2019–20 coronavirus pandemic data/South Korea medical cases chart}} would call {{Medical cases chart}} which calls {{Bar box}} using {{#invoke:Medical cases chart|buildBars}} which calls {{Medical cases chart/Row}} which calls {{Medical cases chart/Row/Custom bar stacked}} which calls {{Bar stacked}}. This means that some of the data is getting counted up to 7 times!

I expanded Module:Medical cases chart/sandbox so that it can now take the place of all 7 of the above templates, and implemented it in {{Medical cases chart/sandbox}}. On the example of {{2019–20 coronavirus pandemic data/South Korea medical cases chart}}, using the sandbox version reduces the post-expand include size from 901kB to 303kB. I put some testcases at Template:Medical cases chart/testcases. The HTML outputs from the original template and module version are virtually identical, except:

• The original version has a bunch of extra carriage returns in the source code
• The original version had some style= sections where the width was specified twice
• The module version rounds off the bar width to the hundredth of a pixel (the original template specified them to approximately 1/10,000 the diameter of an electron on a 72dpi screen)

I'd appreciate any feedback -- the code was written to basically replicate the existing templates, and hasn't been optimized much beyond that. --Ahecht (TALK
PAGE) 19:09, 11 April 2020 (UTC)

I created a slightly optimized version at Module:Medical cases chart/sandbox2 which produces identical visual output, but not identical HTML, but it further reduces the PEIS in the South Korea example from 901kB to 303kB to 191kB. Is does this in two ways:

• Using TemplateStyles to consolidate styles into classes
• Not producing any code for zero-width bars.

You can try it out at {{Medical cases chart/sandbox2}}, and I've added it to the testcases page. --Ahecht (TALK
PAGE) 22:24, 11 April 2020 (UTC)

@Ahecht: Your work on Module:Medical cases chart/sandbox2 and Module:Bar box is amazing! But I think it's crucial that the latter's templates themselves wrap around the module to avoid future inconsistencies (you probably thought of this already). I think legend0 should also be converted to a module (or expanded here to preserve its template interface and decrease code duplication). I'm OK about moving this 100% module implementation to the main branch. Alexiscoutinho (talk) 01:28, 15 April 2020 (UTC)

@Alexiscoutinho: I agree that the long-term plan is to move {{Bar box}} over to the lua version, but I'd like to first switch over {{Medical cases chart}}, which has around 450 uses, and let it go for a bit to make sure there are no unforseen issues that pop up. Once its proven itself in the wild, we should switch over {{Bar box}}, which has over 5500 uses. This will add a few new features to Bar box as well, such as the ability to use an unlimited number of stacked bars instead of just 5, which you can test out in {{Bar box/sandbox}} and {{Bar stacked/sandbox}}. --Ahecht (TALK
PAGE) 23:03, 15 April 2020 (UTC)

As for legend0, for such a small template, there really is no reason to have it run natively in Lua for most uses. Although Lua is faster and more efficient when running, there is a small performance penalty in starting up a Lua instance. I could split it off into its own module, but I think that {{legend0}} should remain as wikicode for now. --Ahecht (TALK
PAGE) 23:03, 15 April 2020 (UTC)

@Ahecht: If {{legend0}} is to remain as wikicode for now, then shouldn't it be used through frame:expandTemplate? I bet it wouldn't make a dent in WP:PEIS. Is it safe to assume that {{legend0}} will never be updated to justify having it as a static function here? If not, then a third option would be to rename the function (or merge it inside another) and make it minimal to turn it specific to this module and independent from the original template. Alexiscoutinho (talk) 16:23, 21 April 2020 (UTC)

@Ahecht: I really like the idea of Lua replacement, but, out of curiosity, isn't the biggest problem with the post-expand double counting, thus IT should be fixed? Is such low level/core fix/improvement even possible? Alexiscoutinho (talk) 15:51, 12 April 2020 (UTC)

@Alexiscoutinho: The double counting is apparently by design. See phab:T15260 (tstarling is Tim Starling, the Lead Platform Architect for MediaWiki). The intention was to force complex templates like this to transition to Lua, which is more efficient from a server standpoint than multi-level nested templates. --Ahecht (TALK
PAGE) 18:33, 12 April 2020 (UTC)

@Ahecht: I tried your code with the template in 2020 coronavirus pandemic in Kyrgyzstan, and it gives a problem with the row in data without a date (between 24 and 27 of march, the defaul character is "⋮") the problem is at row 165. Does it work for you?--Giammarco Ferrari (talk) 16:39, 13 April 2020 (UTC)

@Giammarco Ferrari: What exact error are you seeing, and what browser are you using? At least in Google Chrome and Firefox I'm getting identical outputs from the main version and the sandbox version (0 pixels different, except for the "V" link in the title being black, when compared in an image editor). --Ahecht (TALK
PAGE) 17:09, 13 April 2020 (UTC)

@Ahecht: I am using Firefox 75.0, the error is due to formatDate, it says:"Lua: bad argument #2 to 'formatDate' (not a valid timestamp)."--Giammarco Ferrari (talk) 17:39, 13 April 2020 (UTC)

@Giammarco Ferrari: Strange that I'm not seeing the same thing. In any case, I added some additional error handling to the sandbox2 version, let me know if that fixes it. --Ahecht (TALK
PAGE) 23:34, 13 April 2020 (UTC)

Charts suddenly broken

It seems that any charts that use Template:Medical_cases_chart/Row were suddenly broken across the site today. The most prominent example I can think of is Template:2019–20_coronavirus_pandemic_data/United_States/Pennsylvania_medical_cases_chart (edit: just migrated this to the new format). I saw in the edits for this template that someone deprecated the "rows" parameter (someone else later reverted this) but I can find no discussion here about deprecating that parameter or where to put the Row templates instead. --Jokullmusic 20:40, 14 April 2020 (UTC)

In addition, it seems like a poor idea to deprecate the parameter with zero notice, as well as still have an entire section of the documentation dedicated to explaining its use *after* it's been deprecated. --Jokullmusic 20:44, 14 April 2020 (UTC)

@Jokullmusic and Alexiscoutinho: I updated the documentation and created Category:Templates using Medical cases chart with the rows parameter to track templates that need to be migrated to the new format before the "rows" parameter can be removed from the template. --Ahecht (TALK
PAGE) 21:38, 14 April 2020 (UTC)

Yeah, I should have warned people about it and updated the documentation. Back in March, I tried converting all charts to the data parameter, but it proved too time consuming for one person, especially because I was also fixing and optimizing the formatting. Thus I gave the templates and their editors 20 days to migrate and then did the WP:BOLD deprecation (similar to the factor deprecation)... It turns out that Ahecht's solution is much more appropriate and I hope it will trigger the migration I thought was pretty much completed. Alexiscoutinho (talk) 00:16, 15 April 2020 (UTC)

@Alexiscoutinho: I should be able to run through that category pretty quickly with WP:AWB. --Ahecht (TALK
PAGE) 00:19, 15 April 2020 (UTC)

 Done --Ahecht (TALK
PAGE) 18:05, 16 April 2020 (UTC)

Deaths' color

Hi everybody, I would like to know why the color for deaths has changed, I can't find any discussion about it. Why can't we keep the black color? -- Nick.mon (talk) 08:19, 19 April 2020 (UTC)

Yea, exactly- for me black colour was better. Natanieluz (talk) 09:50, 19 April 2020 (UTC)

Alexiscoutinho, sorry for pinging you here, but you're one of template's main expert :) -- Nick.mon (talk) 16:12, 19 April 2020 (UTC)

@Nick.mon:  Reverted. Alexiscoutinho (talk) 18:22, 19 April 2020 (UTC)

Thank you so much! :) -- Nick.mon (talk) 18:23, 19 April 2020 (UTC)

@Alexiscoutinho: the color black e.g. black sheep, black day, black market has undue negative connotations. Given the global readership of COVID-19 Wikipedia articles and that over 1 billion are referred to as Black people it seems judicious to use a different color for death. Ear-phone (talk) 02:24, 20 April 2020 (UTC)

@Nick.mon: @Natanieluz: @Doc James:

@Nick.mon, Natanieluz, Alexiscoutinho, and Ear-phone: The color was originally changed by Tom.Reding because the black color caused problems for people who read Wikipedia with a light-on-dark color scheme. I would suggest   DimGray might be a reasonable compromise. --Ahecht (TALK
PAGE) 02:34, 20 April 2020 (UTC)

@Nick.mon, Natanieluz, Alexiscoutinho, Ahecht, and Tom.Reding: I am not an expert on color contrast. It seems colors in the range of the other colors, to avoid light-on-dark color scheme issues. Maybe   - red green color blind issues? Ear-phone (talk) 02:47, 20 April 2020 (UTC)

If   DimGray has enough contrast with all other bar colors, then I'm fine with it. By the way, the original discussion is here. Alexiscoutinho (talk) 03:40, 20 April 2020 (UTC)

@Alexiscoutinho: Color symbolism. n=1. I can barely make out the black line color surrounding the dim gray, implying dim gray does not represent a substantial contrast difference from the current black color. Maybe  ? Ear-phone (talk) 04:18, 20 April 2020 (UTC)

In Italy's article we use this shade of black ( ) for the graphs, I don't know if it can bee good. Anyway, before black, I remember that we used a dark shade of red ( ) for these templates; if we decide not to use the black color, IMHO, dark red would be the best choice. -- Nick.mon (talk) 08:36, 20 April 2020 (UTC)

A dark shade of red ( ) has indeed been used before. I have no objection. Ear-phone (talk) 09:18, 20 April 2020 (UTC)

Anyone who uses color-inversion/dark-mode software on their browser will not see black lines/bars on the black background. You can choose a dark grey if you like, but for accessibility, any color but black or white, please.   ~ Tom.Reding (talk ⋅dgaf)  09:25, 20 April 2020 (UTC)

@Nick.mon, Alexiscoutinho, Ear-phone, Tom.Reding, and Ahecht: and to everyone intrested: so Alexiscoutinho reverted that color, and someone again reverted to that "greyish" ? I saw that some users say that   or   will be good. I agree with it! Natanieluz (talk) 09:40, 20 April 2020 (UTC)

Support for   being used as the colour for deaths. WT79 The Engineer (talk) 08:29, 21 April 2020 (UTC)

  is already used in many articles in the graph section to represent the daily amount of deaths, so I think we should use it. -- Nick.mon (talk) 08:32, 21 April 2020 (UTC)

Howdy. Has a 'final' consensus been reached regarding the color? @Nick.mon, Natanieluz, Alexiscoutinho, Ahecht, Tom.Reding, and WT79 The Engineer:. Ear-phone (talk) 15:37, 23 April 2020 (UTC)

@Ear-phone: I think so,   - have (at least) 3 supporters, and  - have (at least) 3 supporters..., so it's 3-3 (all for "reddish") and like someone say earlier this color   was used before so I think that we can go with that, (ofc if no one have any objections?) Natanieluz (talk) 14:17, 25 April 2020 (UTC)

@Nick.mon, Natanieluz, Alexiscoutinho, Ahecht, Tom.Reding, and WT79 The Engineer: I will go ahead and use  . Ear-phone (talk) 20:34, 25 April 2020 (UTC)

@Ear-phone: Great!. Natanieluz (talk) 20:37, 25 April 2020 (UTC)

Great! Thank you :) -- Nick.mon (talk) 21:17, 25 April 2020 (UTC)

@Natanieluz and Ear-phone: If we're going to be using dark red for deaths, we really should have a different color than   for total cases. The progression of    is a bit hard to distinguish compared to the old   . Maybe something like   ? --Ahecht (TALK
PAGE) 22:56, 25 April 2020 (UTC)

@Ahecht, Ear-phone, and Nick.mon: Nope, using   wouldn't be good, bc similar color is already use (on some template - e.g here) to represent "discharged" or "AT-confirmed" (here) cases. Natanieluz (talk) 10:55, 26 April 2020 (UTC)

Hi, just joining in as I was following these and found the change a bit jarring. I'd avoid red for both the total cases as well as deaths. A dark grey for deaths would be fine, but as cases aren't a death sentence, avoiding alarming colours like red would perhaps be more judicious. The advice from datawrapper, for example, reads that " We show the current or confirmed cases in another color than red. The coronavirus is not a death sentence. Most infected people will survive. If you’re infected, you want to find yourself on a map as a blue (or yellow, or beige, or purple…) dot, not as a “attention, danger, run!”-screaming red dot. Related, we show deaths in black, not red – it feels more respectful." and Kenneth Fields suggests "We’ve changed from a red colour scheme to a bluey-green colour scheme. Why? People like red maps. Well that may be true, and they’re certainly attention-grabbing but consider the dataset. We’re mapping a human health tragedy that may get way worse before it subsides. Do we really want the map to be screaming bright red? Red is a very emotive colour. It has meaning. It can easily connotate danger, and death, which is still statistically extremely rare for coronavirus. We can still make the map reveal the same message but without sensationalist colour choices. A simple light-dark colour scheme does the job so people can assess less to more." . I'd argue that all the heat maps should be changed as well from reds to another colour (like blue) or a grey-scale. This may be even more important with the politicization of this virus by the current administration in the USA, with red being a colour associated with China. --Synaptophysin (talk) 15:41, 26 April 2020 (UTC)

@Synaptophysin: Hi!, ofc we should have "black" color for deaths, but like @Ahecht: said: The color was originally changed by Tom.Reding because the black color caused problems for people who read Wikipedia with a light-on-dark color scheme. Is not well visible on dark mode, Natanieluz (talk) 19:04, 26 April 2020 (UTC)

@Natanieluz: These are the colors currently being used by this template:      . I'm proposing changing it to      . The   color you are referring to is much further from   than   is from  . If you don't want any ambiguity, maybe we should go all the way to      , where at least the colors are in order on the color wheel. --Ahecht (TALK
PAGE) 20:09, 26 April 2020 (UTC)

@Ahecht: if everyone agree, and if this colors will "fit" good, we can go with this      . Natanieluz (talk) 20:22, 26 April 2020 (UTC)

References

Line break

I'm not sure exactly when the change happened, but at some point in the last week an edit has resulted in a line break appearing when the chart is added alongside text. For example, see 2020 coronavirus pandemic in Guernsey#History, where an unwanted line break is added between the heading and the body of text. Anybody know how to fix this? —Formulaonewiki 17:41, 20 April 2020 (UTC)

NB I found that using the {{stack}} template fixed the issue, eg:

{{stack|clear=right|{{2019–20 coronavirus pandemic data/Bailiwick of Guernsey medical cases chart}}}}

—Formulaonewiki 14:33, 23 April 2020 (UTC)

Tabular data from Commons

Module:Medical cases chart/data draws from tabular data of medical statistics on Commons to populate the |data= parameter of this template. For example, Template:2019–20 coronavirus pandemic data/United States/California/Santa Clara County medical cases chart is automatically populated with the contents of Commons:Data:COVID-19 Cases in Santa Clara County, California.tab. It could probably be made more flexible, depending on the schemas used on Commons, but I think something along these lines should be folded into the main template so that the data can be shared among wikis and editors can use a slightly friendlier editing environment without having to worry about synchronization. – Minh Nguyễn ^💬 10:49, 21 April 2020 (UTC)

@Mxn: I implemented a way to call your module without having to invoke it separately. You just need to preface all the parameters with "data". See this diff for how I used it on Template:2019–20 coronavirus pandemic data/United States/California/Santa Clara County medical cases chart. --Ahecht (TALK
PAGE) 22:12, 22 April 2020 (UTC)

@Ahecht: Thanks, that's perfect. – Minh Nguyễn ^💬 05:22, 23 April 2020 (UTC)

There is a proposal under discussion for adding a tabular case data property to Wikidata for linking tabular data at Commons to the relevant Wikidata item. It would make it possible to populate this template without having to specify the |datapage= parameter and related parameters. – Minh Nguyễn ^💬 22:05, 2 May 2020 (UTC)

Suggest pass-through barwidth parameter in calling templates

Many of the "2020 coronavirus pandemic in (country)" articles include instances of this chart in the Timeline section near the top. While this is convenient for readers, the width may be an issue when text is rendered next to it on smaller screens. Changing the barwidth parameter can help, but if the chart is also included elsewhere, the original width may be desired.

I suggest adding the barwidth as a pass-through parameter in the intermediate templates. This would allow some pages to specify a narrow width, while others may display the full default chart width. I have already done this with Template:2019–20 coronavirus pandemic data/United States medical cases chart so that the chart can be rendered on the country page with a narrow width, while also being rendered on the Timeline page with a narrower width.

If this seems reasonable, it could be applied to similar uses elsewhere. -- Tom N talk/contrib 03:30, 22 April 2020 (UTC)

@Tcncv: That is a nice idea. I will talk about it in the documentation. Alexiscoutinho (talk) 18:43, 18 January 2021 (UTC)

"Last 15 days" bug?

Mr Xaero recently added collapsible sections to several states' COVID-19 charts. Dyork and I were recently discovering and discussing that all the medical cases chart template instances seem to have the same bug...turning on April and "last 15 days" shows the weird, disjoint set 04/01–04/16 and 05/01 instead of the expected 04/01–05/01. Dyork did some digging and characterized as follows:

 If you choose "Last 15" and "May", you only see bars until the end of April.
 If you choose "Last 15" and "April" and "May", you see data from April 1 through April 18.
 If you choose "Last 15" and "April" (but NOT May), you see all of April AND May.

I've seen that the "collapsible" property is marked as a work-in-progress. Is there a timeline? Should it be avoided for now? 3Todd (talk) 00:26, 4 May 2020 (UTC)

@3Todd: It's a combination of a known bug (#7 on the #To Do list), in which "Last 15 days" needs to be toggled off to properly use the other month buttons, and the particular templates you're looking at manually specifying the "Last 15 days" button instead of using {{Medical cases chart/Month toggle button|l15}} and not having updated it for May. I'm not sure how the bug can be fixed without some custom javascript, but maybe Alexiscoutinho has a better idea. As for the toggle not being updated, I'm working on an update to the template that will generate the toggle buttons automatically without user intervention. --Ahecht (TALK
PAGE) 01:47, 4 May 2020 (UTC)

@Ahecht: I'm almost sure JS is the only way. 3Todd The proper fix/revamp involves altering the collapsible behavior of these custom toggles. By default, a button switches/toggles the state of all of its collapsible elements. If some button changes the state of some collapsible elements of a second button, then the second button won't have its intended behavior of either expanding or collapsing all of its collapsible elements (hence the "weird, disjoint set" mess). What is wanted is a script that changes the on click and on keypress events of the buttons so that the event actions are based on the state of their respective button ([all] collapsed, partial or [all] expanded), which is, in turn, based on the states of all of its linked collapsible elements. An easier fix would be to write a simplified and custom version of the mw-collapsible script (a couple of features/templates have this custom collapsing JS). However, I feel it is more useful to make a generic script that implements this modified/better behavior using the standard mw-collapsible script. Maybe it already exists in Wikipedia or Wikimedia since the original script allows this behavior if extra data is passed during the event. Unfortunately, I have little experience with JS and have a lot of difficulty in putting time to dig more on this :( so don't wait for me. There are probably a couple of editors who could flex on this issue. Alexiscoutinho (talk) 02:51, 4 May 2020 (UTC)

@Alexiscoutinho: The sandbox version of the template automatically generates the toggle buttons based on the data, which gives us some flexibility. One option that occurred to me is to have the last 15 days not overlap, and then update the toggle button titles to indicate their actual values (e.g. have the buttons "Jan   Feb   Mar   Apr 1-18   Last 15 days"). --Ahecht (TALK
PAGE) 14:18, 4 May 2020 (UTC)

@Ahecht: I kinda dislike the no overlap workaround. It breaks the symmetry and pattern of the month buttons. The buttons should be flexible to allow for other time spans like decades, years, semeters, weeks, which might be better suited for other epidemics, so a revamp will eventually be required. Furthermore, this limitation hasn't bothered too many people even after many weeks since its introduction. Alexiscoutinho (talk) 14:45, 4 May 2020 (UTC)

@Alexiscoutinho: I added nooverlap as an option as part of some other code maintenance and cleanup that I was doing, and when enabled, it adds dates to all the buttons for more symmetry. You can see it in action over at the testcases. It will only work if you let the template automatically generate the toggle buttons by omitting |togglebar=, and even then only if there are enough days that the overlap would be a problem (15 by default, 21 in those examples). You can still use the "old method" to produce whatever toggles you want. --Ahecht (TALK
PAGE) 22:28, 9 May 2020 (UTC)

@Ahecht: Thank you (and Alexiscoutinho) for the explanations - and for all your work on these chart templates! Thank you! Two questions:

• Is there an easy way to show the entire chart? To see the whole chart right now with the chart collapsed by default, a visitor has to know that (for the state of Vermont, USA) they need to select "Mar", "Apr", and "May" (but not "Last 15 days"). It would be great if there was an "All" button or something that just allowed a visitor to see all the data in the chart.
• Alternatively, could the chart be set to NOT be collapsed by default? So that it showed the entire chart? Then when someone clicked on one of the toggle buttons, they would only see the relevant sections.

Seeing the entire chart is a powerful way to visualize the growth in cases and I would like to have the ability for a visitor to easily see that. Thank you again for all your work on this! - Dyork (talk) 14:07, 4 May 2020 (UTC)

@Dyork: The entire chart isn't collapsed by default, it has to be set in the individual chart by putting |collapsible=y. If you remove collapsibility, make sure to remove |togglesbar= section too. You might also want to set |rowheight=1 to make it take up less space on the page. --Ahecht (TALK
PAGE) 14:18, 4 May 2020 (UTC)

@Dyork: You could also manually override the collapsible state of each row through the collapsed parameter to make them all initially expanded. By the way, you can easily preview the chart without the collapsible features by viewing the mobile version (en.m.wikipedia). An "All" button is planned once this limitation is fixed. Alexiscoutinho (talk) 14:45, 4 May 2020 (UTC)

Must we use "=" when there's no change in numbers?

Per [1]. It makes it harder to quickly spot rows where there wasn't any change, because the right edge is similar to low percentages. -- Jeandré, 2020-05-09t12:22z

Slovenian wikipedians need some help with this template

I copied latest changes into our sandbox (peskovnik). Can someone help me with:

• sandbox version sl:Predloga:Podatki koronavirusne pandemije 2019–20/Graf medicinskih primerov v Sloveniji/peskovnik. All works ok, until I change {{Medical cases chart/Month toggle button|may}} into our language {{Medical cases chart/Month toggle button|maj}}
• testcases sl:Predloga:Medical cases chart/testniprimeri (the last test in the list).

The problem occurs when I use month named "Maj". I do not know how to properly set language codes in sl:Modul:Medical cases chart/peskovnik (sandbox) and sl:Modul:Medical cases chart/i18n. You are free to play with the code in the sandbox and testcases. --Pinky sl (talk) 16:19, 9 May 2020 (UTC)

@Pinky sl: I updated the i18n for you. The toggles should still use the english abbreviations, but the template will display them using the correct language (so {{Medical cases chart/Month toggle button|may}} will output Maj). If this would cause too much confusion, you can just leave the |togglesbar= parameter out altogether, as with the last testcase (which works now that I've updated sl:Modul:Medical cases chart/peskovnik to the latest version) and the template will generate them for you. --Ahecht (TALK
PAGE) 23:03, 9 May 2020 (UTC)

@Ahecht: thanks ... our sandbox works now perfectly without |togglesbar=. If this parameter is set with {{Medical cases chart/Month toggle button|may}} it works fine, but month is still "May". If this parameter is set with {{Medical cases chart/Month toggle button|maj}} it is corrupted, but month properly set to "Maj". Pinky sl (talk) 08:56, 10 May 2020 (UTC)

@Pinky sl: Should be all set. I upgraded your {{Medical cases chart/Month toggle button}} to the version that uses the i18n data. --Ahecht (TALK
PAGE) 16:59, 10 May 2020 (UTC)

@Ahecht: thanks. Pinky sl (talk) 18:06, 10 May 2020 (UTC)

Number and height of rows

When this template was originally made, {{Bar box}} didn't have any options for adjusting the height of each row -- it just used the default Wikipedia text line height of 1.6. However, as the medical cases chart is used in cases where there are 100+ rows, only showing the last 15 rows doesn't give a good overall picture of the data when |collapsible=y. I have since updated {{#invoke:Bar box|function}} to allow custom heights, and I have updated this module so that it can generate toggle buttons for arbitrary number of days. Therefore, I am proposing changing the default height from 1.6 to 1.2, and changing the default number of rows from 15 to 21. This will have a minimum impact on overall template height when collapsed, as seen here:

Disease cases in Template:Medical cases chart/testcase  ()      Deaths        Recoveries        Active cases FebFebMarMarAprApr Last 15 daysLast 15 days Date # of cases # of deaths 2020-02-16 29(+3.6%) 2020-02-17 30(+3.4%) 2020-02-18 31(+3.3%) 2020-02-19 51(+65%) 2020-02-20 104(+104%) 1(n.a.) 2020-02-21 204(+96%) 2(+100%) 2020-02-22 433(+112%) 2(=) 2020-02-23 602(+39%) 4(+100%) 2020-02-24 833(+38%) 7(+75%) 2020-02-25 977(+17%) 10(+43%) 2020-02-26 1,261(+29%) 12(+20%) 2020-02-27 1,766(+40%) 13(+8.3%) 2020-02-28 2,337(+32%) 13(=) 2020-02-29 3,150(+35%) 17(+31%) 2020-03-01 4,212(+34%) 22(+29%) 2020-03-02 4,812(+14%) 28(+27%) 2020-03-03 5,328(+11%) 32(+14%) 2020-03-04 5,766(+8.2%) 35(+9.4%) 2020-03-05 6,284(+9.0%) 42(+20%) 2020-03-06 6,767(+7.7%) 44(+4.8%) 2020-03-07 7,134(+5.4%) 50(+14%) 2020-03-08 7,382(+3.5%) 51(+2.0%) 2020-03-09 7,513(+1.8%) 54(+5.9%) 2020-03-10 7,755(+3.2%) 60(+11%) 2020-03-11 7,869(+1.5%) 66(+10%) 2020-03-12 7,979(+1.4%) 67(+1.5%) 2020-03-13 8,086(+1.3%) 72(+7.4%) 2020-03-14 8,162(+0.94%) 75(+4.2%) 2020-03-15 8,236(+0.90%) 75(=) 2020-03-16 8,320(+1.0%) 81(+8.0%) 2020-03-17 8,413(+1.1%) 84(+3.7%) 2020-03-18 8,565(+1.8%) 91(+8.3%) 2020-03-19 8,652(+1.0%) 94(+3.3%) 2020-03-20 8,799(+1.7%) 102(+8.5%) 2020-03-21 8,897(+1.1%) 104(+2.0%) 2020-03-22 8,961(+0.72%) 111(+6.7%) 2020-03-23 9,037(+0.85%) 120(+8.1%) 2020-03-24 9,137(+1.1%) 126(+5.0%) 2020-03-25 9,241(+1.1%) 131(+4.0%) 2020-03-26 9,332(+0.98%) 139(+6.1%) 2020-03-27 9,478(+1.6%) 144(+3.6%) 2020-03-28 9,583(+1.1%) 152(+5.6%) 2020-03-29 9,661(+0.81%) 158(+3.9%) 2020-03-30 9,786(+1.3%) 162(+2.5%) 2020-03-31 9,887(+1.0%) 165(+1.9%) 2020-04-01 9,976(+0.90%) 169(+2.4%) 2020-04-02 10,062(+0.86%) 174(+3.0%) 2020-04-03 10,156(+0.93%) 177(+1.7%) 2020-04-04 10,237(+0.80%) 183(+3.4%) 2020-04-05 10,284(+0.46%) 186(+1.6%) 2020-04-06 10,331(+0.46%) 192(+3.2%) 2020-04-07 10,384(+0.51%) 200(+4.2%) 2020-04-08 10,423(+0.38%) 204(+2.0%) 2020-04-09 10,450(+0.26%) 208(+2.0%) 2020-04-10 10,480(+0.29%) 211(+1.4%) Some sort of footer would go here, maybe with sources or other footnotes.

Disease cases in Template:Medical cases chart/testcase  ()      Deaths        Recoveries        Active cases FebFebMarMarAprApr Last 20 daysLast 20 days Date # of cases # of deaths 2020-02-16 29(+3.6%) 2020-02-17 30(+3.4%) 2020-02-18 31(+3.3%) 2020-02-19 51(+65%) 2020-02-20 104(+104%) 1(n.a.) 2020-02-21 204(+96%) 2(+100%) 2020-02-22 433(+112%) 2(=) 2020-02-23 602(+39%) 4(+100%) 2020-02-24 833(+38%) 7(+75%) 2020-02-25 977(+17%) 10(+43%) 2020-02-26 1,261(+29%) 12(+20%) 2020-02-27 1,766(+40%) 13(+8.3%) 2020-02-28 2,337(+32%) 13(=) 2020-02-29 3,150(+35%) 17(+31%) 2020-03-01 4,212(+34%) 22(+29%) 2020-03-02 4,812(+14%) 28(+27%) 2020-03-03 5,328(+11%) 32(+14%) 2020-03-04 5,766(+8.2%) 35(+9.4%) 2020-03-05 6,284(+9.0%) 42(+20%) 2020-03-06 6,767(+7.7%) 44(+4.8%) 2020-03-07 7,134(+5.4%) 50(+14%) 2020-03-08 7,382(+3.5%) 51(+2.0%) 2020-03-09 7,513(+1.8%) 54(+5.9%) 2020-03-10 7,755(+3.2%) 60(+11%) 2020-03-11 7,869(+1.5%) 66(+10%) 2020-03-12 7,979(+1.4%) 67(+1.5%) 2020-03-13 8,086(+1.3%) 72(+7.4%) 2020-03-14 8,162(+0.94%) 75(+4.2%) 2020-03-15 8,236(+0.90%) 75(=) 2020-03-16 8,320(+1.0%) 81(+8.0%) 2020-03-17 8,413(+1.1%) 84(+3.7%) 2020-03-18 8,565(+1.8%) 91(+8.3%) 2020-03-19 8,652(+1.0%) 94(+3.3%) 2020-03-20 8,799(+1.7%) 102(+8.5%) 2020-03-21 8,897(+1.1%) 104(+2.0%) 2020-03-22 8,961(+0.72%) 111(+6.7%) 2020-03-23 9,037(+0.85%) 120(+8.1%) 2020-03-24 9,137(+1.1%) 126(+5.0%) 2020-03-25 9,241(+1.1%) 131(+4.0%) 2020-03-26 9,332(+0.98%) 139(+6.1%) 2020-03-27 9,478(+1.6%) 144(+3.6%) 2020-03-28 9,583(+1.1%) 152(+5.6%) 2020-03-29 9,661(+0.81%) 158(+3.9%) 2020-03-30 9,786(+1.3%) 162(+2.5%) 2020-03-31 9,887(+1.0%) 165(+1.9%) 2020-04-01 9,976(+0.90%) 169(+2.4%) 2020-04-02 10,062(+0.86%) 174(+3.0%) 2020-04-03 10,156(+0.93%) 177(+1.7%) 2020-04-04 10,237(+0.80%) 183(+3.4%) 2020-04-05 10,284(+0.46%) 186(+1.6%) 2020-04-06 10,331(+0.46%) 192(+3.2%) 2020-04-07 10,384(+0.51%) 200(+4.2%) 2020-04-08 10,423(+0.38%) 204(+2.0%) 2020-04-09 10,450(+0.26%) 208(+2.0%) 2020-04-10 10,480(+0.29%) 211(+1.4%) Some sort of footer would go here, maybe with sources or other footnotes.

The default row height change would impact all instances of this template that don't use the |rowheight= parameter to override it. The change to the default number of days would only impact instances that use |collapsible=y without the accompanying |togglesbar= parameter and without using |duration= to override the default. Templates could be easily switched to 21 20 days by removing |togglesbar= from them and letting the template generate the toggles automatically (this has the added benefit of the toggles being generated for the last 15 rows, not the last 15 days, which will become more and more important as these templates stop being updated daily).

Thoughts? --Ahecht (TALK
PAGE) 23:30, 9 May 2020 (UTC)

I like the new, more compact look. I wonder if defaulting to "last 20" might be better to keep the overall height even more similar to the current defaults. 3Todd (talk) 17:34, 10 May 2020 (UTC)

The "Last 15 days" option is primarily meant to give information on recent advances in situation, and the 2-week period seems like a perfect match for this task. That's to address the "doesn't give a good overall picture of the data" passage. I don't think it was ever meant to do that. Unless you are the author of this and it was, of course. -- Nicholas Velasquez (talk) 18:42, 10 May 2020 (UTC)

At least with the COVID-19 uses of this template, as the rate of increase slows down, a 15 day window doesn't tend to show very much. --Ahecht (TALK
PAGE) 02:54, 11 May 2020 (UTC)

In terms of dynamics, you mean? If that's the case, I don't think a one week extension would make things much different, especially in the future. The Chinese COVID-19 template is a good example of this. But it would certainly make numbers more cluttered and harder to grasp at a first glance, which is, probably, the main thing readers expect from this chart (the rest is usually handled by the "Statistics" section). However, the 21-days button may be useful in some special cases, so I'd say it's worth adding it, but not as default. -- Nicholas Velasquez (talk) 13:38, 11 May 2020 (UTC)

Stacked toggle buttons in all templates

Did someone mess up with the code that is being transcluded in so many templates? The toggle buttons appear to be stacked, whereas they are supposed to appear in a single row. LSGH (talk) (contributions) 17:06, 10 May 2020 (UTC)

Looks like Ahecht is actively working on the {{Medical cases chart/Month toggle button}}. (https://wiki.riteme.site/w/index.php?title=Template:Medical_cases_chart/Month_toggle_button&action=history) I suspect it'll be sorted out soonish. 3Todd (talk) 17:32, 10 May 2020 (UTC)

It's still messed up and we are talking about a template which gets lots of hits everywhere. KittenKlub (talk) 21:18, 10 May 2020 (UTC)

Luckily the template wasn't locked. (Doesn't the toggle button template need to be locked??). I've undone the revision which breaks the medical charts. KittenKlub (talk) 21:23, 10 May 2020 (UTC)

@KittenKlub: Thanks. All the testcases I used didn't have carriage returns between calls to the month toggle button template. It should be fixed now. --Ahecht (TALK
PAGE) 02:52, 11 May 2020 (UTC)

{ping|Ahecht}}It looks fine again. One favour, please put at least a semi-protected lock on that template, because a vandal can have lots of fun on that template... KittenKlub (talk) 06:34, 11 May 2020 (UTC)

Seems to be fixed now. I just could not see where the actual code is (the button template itself has the #invoke function, but I do know know from where to invoke), but at least it's now working as usual. LSGH (talk) (contributions) 10:09, 11 May 2020 (UTC)

Brainstorm about the 14 days

Somebody mentioned it already. The last 15 days option has become a little less useful. I just discovered that the health authority in Saint Martin and Saint Saint Barthélemy stops publishing daily reports and will switch to weekly reports and press statements if there is a real change. I assume that more countries which haven't been heavily hit will the same. It does mean that the 15 days option will result in two lines... KittenKlub (talk) 18:11, 13 May 2020 (UTC)

@KittenKlub: If you let the template generate the toggles automatically (by removing |togglesbar=) it will do the last 15 days of data, not the last 15 calendar days. There should always be 15 rows displayed unless there are less that 15 rows available. --Ahecht (TALK
PAGE) 13:56, 18 May 2020 (UTC)

Universal colors for charts and maps?

Input at WikiProject COVID-19 most welcome. -- Jeandré, 2020-05-15t18:43z

Colors as parameters?

Could the colors be set using parameters? -- Jeandré, 2020-05-15t18:43z

@Jeandré du Toit: As of now, no. The whole purpose of this template is to unify all charts and allowing for custom colors would result in a Carnival. However, if there is good reason, it may be allowed to have different colors in some cases. Alexiscoutinho (talk) 13:43, 12 September 2020 (UTC)

Non-unique ids

Hello, this template generates markup that includes ids such as "mw-customcollapsible-mar-l20". However, it seems that these ids are not unique, even within the same instance of a template. This a big no-no and is considered invalid HTML. Opencooper (talk) 07:18, 4 June 2020 (UTC)

@Opencooper: This could be implemented by modifying how the makeCollapsible method handles custom ids. Its feasibility depends on how much such a change would impact existing pages across MediaWiki. I recently made a feature request at Phabricator and I'll see how the admins handle change. Depending on the outcome, I may try to implement this feature, but it would certainly be at the bottom of the priority/To Do list. Alexiscoutinho (talk) 13:43, 12 September 2020 (UTC)

Thanks for looking into it. Opencooper (talk) 19:09, 12 September 2020 (UTC)

Switching Colour Ordering Option

Hello,

Is there a way to change the colour ordering? I would like to put the yellow between the blue and the orange (to have COVID-19 active cases in its standard colour and on the end).

If this is not currently possible, could I suggest it as a feature? Maranello10 (talk) 13:44, 7 August 2020 (UTC)

@Maranello10: Custom and runtime bar (with its attached color) ordering is planned, but we'll have to make sure the colors have enough contrast for color blind people in all combinations. Alexiscoutinho (talk) 13:43, 12 September 2020 (UTC)

Toggle buttons

Resolved

Hi, the togglesbar button `Last X days` breaks into newline in middle of button at Template:COVID-19 pandemic data/India medical cases chart. Someone take a look at it. Thanks - Timbaaa -> ping me 12:18, 24 August 2020 (UTC)

If there are any parameters forcing to display rounded values?

I want display values rounding with 1 trailing digits and know just manual way (4-th row). Does another way exist?

|data=
2009-04-13;913;200;5542
2009-04-14;914;300;5556
2009-04-15;916;400;5563
2009-04-16;917;500;5575;;;5,575;+0.2%;917;+0.1%
2009-04-17;918;600;5595

Addition: 2 digits 5,575(+0.22%) 917(+0.11%) shows on 2009-04-16 by default. 212.241.25.50 (talk) 05:02, 4 October 2020 (UTC)

@212.241.25.50: Why would you want 1 d.p.? Especially when the change is becoming so small that there will be many repeated values? Alexiscoutinho (talk) 02:23, 20 October 2020 (UTC)

Ask him. We couldn't get consensus on template. 185.66.252.38 (talk) 07:54, 23 October 2020 (UTC)

Add "All" button

Someone had asked this before at #Is it possible to have a button saying "All" above, is it possible to add this button now? Hddty (talk) 07:24, 27 August 2020 (UTC)

@Hddty: Probably. I am modifying the default collapsible behavior to allow for more useful buttons. The logic and idea behind the JavaScript is mostly done. I would still need to fully test the code, make sure the normal behavior still works for content besides this template and then request its addition in the MediaWiki namespace. The last part is beyond my control, but it could be bypassed, in the meantime, if people used the new code (don't use my Sandbox.js yet!!) among their user scripts. All in all, this long awaited feature might come in the near future... Alexiscoutinho (talk) 02:47, 4 September 2020 (UTC)

@Alexiscoutinho: Probably [show] / [hide] button also needed because the chart would be long after clicking "all". Hddty (talk) 04:38, 4 September 2020 (UTC)

@Hddty: Then just click "All" again... Or do you mean you want a togglesbar that slides with the page view (is always visible)? Note that, with a revamped toggling system, buttons like "1^st semester", "2^nd semester" and "Last 30 days" are easy to add. Alexiscoutinho (talk) 04:53, 4 September 2020 (UTC)

@Alexiscoutinho: Then there's no need to add [show] / [hide] button. "Just click 'All' again" is already good. Hddty (talk) 05:36, 4 September 2020 (UTC)

@Hddty: Good news! I have a working version of the revamped makeCollapsible plugin that you can check firsthand! Just load my sandbox.js and sandbox.css and check my main sandbox page. I still need to clear some doubts with TheDJ, finish documentation, make sure there's no edge case that breaks and then try to officially add it to Wikipedia. Alexiscoutinho (talk) 22:57, 6 September 2020 (UTC)