This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
^On 25 March PHE changed reporting of deaths to be correct up to 17:00 the previous day, while cases are reported up to 09:00 the same day. Deaths reported for Tuesday 24 March only covered from 09:00 to 17:00 on that day; subsequent reporting is for 24-hour periods from 17:00 to 17:00.[3]
^Figures for 27 March and after include additional cases from tests carried out on key workers.
^Starting with the figures published on 29 April, deaths in all settings are now included. Previously, only deaths in hospitals were included in the official figures. The numbers in this table have been updated with backdated figures for previous dates.
^Positive cases are 27 lower than the difference between today’s and yesterday’s cumulative. This is due to Northern Ireland not processing testing data for 17 May, and the removal of a quality control sample from Wales data.
^Reduction in the cumulative total is due to unpublished corrections, and the reallocation of some positive test results to previous days.
^111 deaths were reported for 31 May. However, the cumulative total was revised to include an additional 445 deaths from the period from 26 April to 31 May identified by PHE as COVID-19 deaths having received a positive test. The numbers in this table have been updated with backdated figures from 23 May onwards.
^The methodology of reporting positive cases has been updated to remove duplicates within and across pillars 1 and 2, to ensure that a person who tests positive is only counted once. This has resulted in a reduction in the number of cumulative tests.
Pillar 1: swab testing in Public Health England (PHE) labs and NHS hospitals for those with a clinical need, and health and care workers.
Pillar 2: swab testing for the wider population, as set out in government guidance.
^Total positive cases reported for 14 July include an additional 842 cases from a testing laboratory in Wales. These positive cases should have been reflected in the data for 13 July. Had they been included in the 13 July data, there would have been 398 positive cases reported on 14 July, and the increases for 13 July and 14 July would have been 0.47% and 0.14% respectively.
^The way daily death figures are calculated is currently under review. Statement from HM Government: "The Secretary of State has today, 17 July, asked PHE to urgently review their estimation of daily death statistics. Currently the daily deaths measure counts all people who have tested positive for coronavirus and since died, with no cut-off between time of testing and date of death. There have been claims that the lack of cut-off may distort the current daily deaths number. We are therefore pausing the publication of the daily figure while this is resolved."
^After a review, the way daily death figures are calculated was changed. The daily death figures now only includes cases where a death occurred within 28 days of a positive test.
^ abA backlog of positive test results from the previous week are included in this figure. Statement from Public Health England: "Due to a technical issue, which has now been resolved, there has been a delay in publishing a number of COVID-19 cases to the dashboard in England. This means the total reported over the coming days will include some additional cases from the period between 24 September and 1 October, increasing the number of cases reported."
^Includes a backlog of 141 deaths. Statement from HM Government: "Due to a processing update, 141 historical deaths within 28 days in England were excluded from the published data on 21 November. This issue was corrected for data published on 22 November, which included deaths omitted on 21 November within the total and daily number of newly reported deaths for 22 November."
^Includes a backlog of about 11,000 positive test results from Wales. Statement from HM Government: "The number of new UK cases reported on 17 December 2020 includes around 11,000 previously unreported cases for Wales as a result of system maintenance in the NHS Wales Laboratory Information Management System."
^3 March: 172 deaths within 28 days of a positive test were added to Scotland and UK totals.
^13 March: Daily counts of deaths in England rely on multiple data sources. On 13 March 2021 there was a delay in receiving this information from one of these sources. This might have a small impact on the total number of deaths reported on that date. This delay will be reflected on the numbers published on 14 March 2021.
^18 May: 4,776 additional cases from England were removed
^19 May: further 561 additional cases from England were removed
^20 May: further 180 additional cases from England were removed
^Because of a public holiday, no data has been updated for Wales and only headline cases, vaccinations and deaths are available from Northern Ireland.
^Because of a network issue at Public Health Wales on 8 October 2021, cases and deaths within 28 days of positive test were reported after the UK dashboard was updated.
^Because of technical issues at Public Health Wales yesterday, the cases and deaths reported today cover a 72-hour period.
^Deaths data was not received from NHS England on 1st November 2021. This means that two days’ worth of data from this data source are potentially included in today’s figures.
^Public Health Scotland (PHS) are investigating a processing issue with UK Government Pillar 2 lab tests contributing to lower than expected cases. This means reported case numbers for Scotland on 4 December 2021 are likely lower than would have been expected.
^Issue with cases by test type – Because of a processing issue, positive lateral flow tests followed by a negative PCR test in England were not removed on 20 Dec 2021. Today's figures include removals for 2 days.
^The COVID-19 dashboard will not be updated on 25-26 December 2021. Daily reporting will resume on 27 December 2021. The availability of data will vary over the festive period.
^Incomplete data for deaths due to holidays – No data have been reported for Scotland and Northern Ireland.
^Newly reported figures from Northern Ireland for testing, cases and deaths reflect the difference in totals reported on 29 December and those last published by Northern Ireland on 24 December 2021. Figures for cases and deaths are available by specimen date and date of death respectively. Retrospective report date figures for each day from 25 to 28 December are not available.
^Today’s death figures include a backlog of hospital deaths reported overnight by NHS England covering the period 24th–29th December.
^Cases and deaths data are only included for England. Data for Scotland, Wales, and Northern Ireland will be updated after the holidays.
^Cases and deaths data are only included for England and Wales. Data for Scotland and Northern Ireland will be updated after the holidays.
^Cases data only include figures for England and Scotland. Deaths data only include figures for England
^Newly-reported figures of tests conducted, cases and deaths for Northern Ireland cover a 4-day period, and for Wales cover a 2-day period. Newly-reported figures for cases in Scotland are only available at national level. Data for deaths in Scotland have not been updated. The UK total therefore includes only newly-reported deaths in England, Northern Ireland and Wales. Figures for cases and deaths by specimen date and date of death have been updated for England, Northern Ireland and Wales.
^Today’s death figures include a backlog of hospital deaths reported overnight by NHS England covering the period 1–4 January. Deaths with COVID-19 on the death certificate registered in the week ending 24 December 2021 are only available for England and Wales. The UK total number includes England and Wales only.
^The Office for National Statistics (ONS) has corrected the number of deaths with COVID-19 on the death certificate for the week ending 24 December 2021. Some deaths were not included in the published figures because of an issue with the ONS automated coding system.
^From 6 January in Northern Ireland, Scotland and Wales, and 11 January in England, people with positive lateral flow results for COVID-19 need to report their result but don’t need to take a confirmatory PCR test unless they develop COVID-19 symptoms. This is a temporary measure while COVID-19 rates remain high across the UK as the vast majority of people with positive lateral flow test results can be confident that they have COVID-19.
^Figures for cases, deaths and vaccinations that were not reported from Scotland yesterday have been retrospectively added to the totals for 16 January 2022. The missing data have also been added to the UK figures for 16 January.
^Because of a processing issue, deaths with COVID-19 on the death certificate have not been updated for all areas.
^Scotland cases that were not reported over the weekend have been retrospectively added to the Scotland and UK totals for 22 and 23 January 2022. One death has been removed from the cumulative number of reported deaths within 28 days of positive test in Northern Ireland following validation. Public Health Scotland has noted that the cumulative number of deaths within 28 days of positive test in Scotland is one fewer than the day before.
^From 31 January 2022, UKHSA will move all COVID-19 case reporting in England to use a new episode-based definition which includes possible reinfections.
^Figures for new positive PCR cases in Scotland are not available at the weekend.
^Northern Ireland did not publish an update to reported cases and deaths within 28 days of a positive test in time for inclusion in the UK dashboard. Figures will be added in a future release.
^Figures for first episodes (equivalent to the pre-31 January 2022 case definition) and possible reinfections by specimen date have been added for England plus regions and local authorities within England. From 31 January, UKHSA COVID-19 case reporting has changed to an episode-based definition which includes possible reinfections. Deaths within 28 days of positive test and deaths within 60 days of positive test will also be updated on 1 February to include deaths following the most recent episode of infection using the new episode-based case definition in England.
^Deaths definition in England updated to align with revised cases definition. From 31 January 2022, UKHSA COVID-19 case reporting has changed to an episode-based definition which includes possible reinfections.
^Figures for cases, deaths and tests conducted that were not reported from Scotland yesterday have been retrospectively added to the totals for 2 February 2022. The missing data have also been added to the UK figures for 2 February.
^Positive rapid lateral flow test results are included in cases for Scotland. Historical cases by report date have not been revised, so there has been a step increase in the cumulative numbers of cases. Because of the new case definition for Scotland, underlying data files for cases and deaths have changed structure.
^As of 20 February 2022, Public Health Wales have moved to a five day reporting period for COVID-19 surveillance. This means that there will be no reporting of the daily figures for Wales on weekends.
^From the week of 21 February 2022, the UK Health Security Agency will stop publishing dashboard updates at weekends. The dashboard will be updated as usual from Monday to Friday. Daily cases and deaths by report date published on Mondays will include figures from the weekend. These will not be separated out to show daily figures for Saturday and Sunday.
^From 1 March 2022, multiple infection episodes are included in cases for Scotland: cases include both new infections and possible reinfections; deaths following possible reinfection are reported; cases by specimen date and deaths by date of death have been revised back to the beginning of the pandemic; historical cases and deaths by report date have not been revised, so there has been a step increase in the cumulative number of cases of around 60,000 and in the number of deaths of 75.
^Due to a technical issue affecting one route of reporting to UKHSA, the number of COVID-19 deaths may be lower than otherwise expected. This is anticipated to be a temporary limitation, and any delayed reporting will be resolved in the coming days.
^A technical issue affecting one route of reporting to UKHSA reported on 2 March has been fixed. Today's deaths figures by report date include some deaths that would have been reported on that date.
^An additional 13,774 historic cases have been included in today's cumulative case total for Scotland. These are positive rapid lateral flow test (LFD) results that were reported via the Scottish Government LFD Portal between 6 January 2022 and today.
^Due to a technical issue, Public Health Scotland (PHS) has been unable to provide updated data on cases, deaths, tests, hospital admissions and vaccinations. UK totals therefore only include updates from England, Northern Ireland and Wales.
^Because of the technical issue affecting Public Health Scotland reporting yesterday, today's newly-reported cases, deaths and tests cover new reports since 12 March. Newly-reported vaccinations cover the period since 11 March.
^Case figures reported by Public Health Scotland today cover less than a 24-hour period. A reoccurrence of the technical issue from earlier in the week means data has not been received since 8pm on 15 March 2022.
^Because of a public holiday in Northern Ireland, data have only been updated for cases, deaths and vaccinations by report date. Case figures reported by Public Health Scotland today cover less than a 24-hour period. A reoccurrence of the technical issue from earlier in the week means data has not been received since 2pm on 16 March 2022.
^Case figures reported by Public Health Scotland today cover more than a 24-hour period, due to technical issues from earlier in the week. Data covers cases reported from 2pm on 16 March 2022 and those reported on 17th March 2022.
^6 deaths within 28 days of a positive test have been removed from the cumulative total for Scotland. Changes to test details mean they are no longer classed as deaths within 28 days of positive test. These changes affect the Scotland and UK cumulative totals.
^The availability of free COVID-19 tests in England changed on 1 April. Information on who can access free tests has been published by UKHSA. Changes to patient testing in the NHS in England have also been published by NHS England.
^Due to a processing error, a number of people who died within 28 days of a positive COVID-19 test in 2022 were not reported in a timely manner. 2,714 deaths within 28 days of a positive test were added retrospectively. The backlog of deaths has been added to the cumulative total for England and the UK. Newly-reported deaths for England and the UK on 6 April 2022 represent the numbers that would have been reported without the extra retrospective deaths.
^Daily counts of deaths in England rely on multiple data sources. Data from one source was not included on 12 April 2022 due to delays in receipt and processing.
^Following the technical issue affecting one route of reporting to UKHSA yesterday, today's deaths figures by report date include some deaths that would have been reported on 12 April. Deaths by death date are backdated.
^In line with weekday only reporting, the dashboard will not be updated over the bank holiday weekend. Following the update on Thursday 14 April, the next update will be on Tuesday 19 April.
^Due to a technical issue, Public Health Scotland (PHS) has been unable to provide updated data on cases, deaths, tests and hospital admissions. UK totals for cases, deaths and testing by publish date therefore only include updates from England, Northern Ireland and Wales.
^Because of a technical issue, it has only been possible to update figures for cases for England (nation) by report date.
^In line with weekday only reporting, the dashboard will not be updated over the bank holiday weekend. Following the update on 29 April, the next update will be 3 May.
^Due to a technical issue affecting one data source, the number of reported COVID-19 deaths in England is lower than expected. Any delay in reporting is expected to catch up in the next couple of days.
^A technical issue affecting one route of reporting to UKHSA reported on 4 May has been fixed. Deaths figures by report date on 5 May include some deaths that would have been reported on the previous day. Deaths by death date are backdated.
^From 9 May, Public Health Scotland moved to reporting data on Mondays and Thursdays. This means UK headline figures are also updated on Mondays and Thursdays. Up-to-date data for England, Wales (excluding vaccinations) and Northern Ireland are on the cases, deaths, healthcare, testing, vaccinations and postcode pages.
^Due to technical issues, the Department of Health in Northern Ireland were unable to update the numbers of tests, cases and deaths reported. This means that UK cases, deaths and testing data has not been updated beyond 10 May 2022.
^From 20 May, Department of Health Northern Ireland stopped reporting data on cases, testing and deaths. This means UK headline figures for these topics will not be updated. Up-to-date data for England, Wales (excluding vaccinations) and Scotland are on the cases, deaths, healthcare, testing, vaccinations and postcode pages. Data for vaccinations in Northern Ireland will continue to be updated daily.
^In line with weekday only reporting, the dashboard will not be updated over the bank holiday weekend. Following the update on Wednesday 1 June, the next update will be on Monday 6 June.
Notes: On May 27, 2021, the Wisconsin Department of Health changed their website layout which discontinued recovery data. On December 4, 2021, the Wisconsin Electronic Disease Surveillance System underwent maintenance. On August 30, 2023, the Wisconsin Department of Health stopped reporting case and fatality data (final report includes confirmed and probable data). Fatality data continues to be reported to the CDC.
@190.246.118.103: In the past, I have been against allowing the display of two change types on one column since it looks messy and ugly. However, since the community keeps asking for and does it anyways, I think your suggestion is valid. The chart width isn't always an issue now and the + sign does seem unnecessary. Yet, I think a better solution would be to implement both cumulative and new daily bars on the same chart. Switching between chart types would involve a custom button which would be feasible if my enhancement request at Phabricator passes. If that doesn't work out, then your suggestion is welcome (although the new options would still not be recommended...). Alexiscoutinho (talk) 03:08, 18 September 2020 (UTC)
@190.246.118.103: There has already been such an option, but it was removed due to oversized chart width outcome (or similar, I dug a bit into the codes history recently). It used the letter b, and as the changetype is currently implemented, only the first letter is evaluated. So p, pa or po are all the same.
I personally would find other kinds of change/other info column types useful as well, e.g. c(onatgious) for active cases, w(eek) for 7-days-incidence or f(ortnight) for 14-days-incidence. -- Kohraa Mondel (talk) 11:07, 21 December 2020 (UTC)
I think your first suggestion requires chosing active cases as the classification to be detailed (which I think isn't currently automatable) instead of # of cases. In the other two suggestions, do you mean "rolling averages"? If yes, that could be a nice feature. Alexiscoutinho (talk) 04:00, 22 December 2020 (UTC)
@Alexiscoutinho: I rather thought of keeping the total number of cases, but instead of displaying its own change in absolute or percentual figures, show the change of the active cases (be it absolute or percentual), see sandbox2 and test case. With the first figure I like a number that corresponds to the bars total length, but in parentheses I personally would prefer a metrics that depicts the desease's spread dynamics best. And there percentual change of active cases seems to me much preferable to absolute or percentual change of cumulated cases. Sandbox2 implements right now absolute change of active cases, but I want to adjust it to percentual soon is percentual now. -- Kohraa Mondel (talk) 11:54, 22 December 2020 (UTC)
@Kohraa Mondel: I'm still skeptical about mixing value and change of different classifications (also because of formatting). I think that when the cumulative and daily new charts are "split", the dynamics will become much clearer, even with just generic case statistics. For example, there will be a daily new cases "value" and percent change attributed to it, be it simple or rolling... I think that's what the big media mostly does. I know active cases is better in that regard and I wouldn't be against a whole column dedicated for it, but I think it's not good enough to justify mixing things up, yet. Alexiscoutinho (talk) 14:15, 22 December 2020 (UTC)
@Alexiscoutinho: I can see your point with mixing up cumulated and active cases, but thought of it as a compromise due to limited space. I'm not quite familiar with plans and concepts to "split" the charts, is it about switching between different columns by a toggle button, similar to the time interval toggling? Is there any schedule for implementation or any open tasks to be done? Anyways, what about an additional classification like right1data=a where the respective column would be calculated by data3 - data2 - data1? It's little effort to implement, only the conditions where it applies trouble me a bit, e.g. reclbl=xxx, altlbl1=yyy or recoveries=n might indicate, that data3 and data2 do not contain cases and recoveries, as expected. Any suggestions?. -- Kohraa Mondel (talk) 09:31, 23 December 2020 (UTC)
@Kohraa Mondel: The Cumulative toggle would look like this and would switch all numbers (not headings) in the columns between cumulative and new (which is basically absolute change), thus all actual changes would be percent, by default. I plan to do it "soon", but after the important year toggles. I would support something like right1data=a. We should assume that those labels are the default. The editor is the one who decides if he wants data3 - data2 - data1 or not. The alttots and recoveries=n indeed may need to be taken into account. Alexiscoutinho (talk) 14:21, 23 December 2020 (UTC)
As for "rolling averages", the incidence metrics currently in use by several state health authorities are a closely related measure, but not the same: E.g. a 7-days incidence sums up the last 7 days new cases, but does not divide by seven, and then again divides by total population (usually in units of 100,000), thus producing xxx new cases per 7 days per 100,000 inhabitants. But I do not see much additional work in implementing both instead of only incidences. Most work will be to determine the respective intervals diff. So once we know what we want, I think it could be done all in one. -- Kohraa Mondel (talk) 11:54, 22 December 2020 (UTC)
The way you describe it, I kinda dislike incidence metrics as it just feels like a weekly change and with unnecessarily large numbers, which should be avoided in this, generally, wide template. Furthermore, I haven't heard that rolling averages are, by default, "per 100000". I would be skeptical about such division unless the whole column is "per 100000". Alexiscoutinho (talk) 14:15, 22 December 2020 (UTC)
The incidence metrics is also not my personal favorite, but published by several national health authorities like Spain (14-days and 7-days), Ireland (7-days), Germany (7-days) or Ukraine (14-days) and as a result also often is cited in the media of these countries. But the values are quite handy 2-3 digit figures, maybe that's why they're preferred over rolling averages. And all these countries relate incidence (and not, of cause, rolling averages) per 100,000 inhabitants. In implementation it's practically no difference in adding rolling average, 7-days-incidence, 14-days incidence or all three of them. So what about just adding changetype=r for rolling as well as w and f? -- Kohraa Mondel (talk) 09:31, 23 December 2020 (UTC)
Then, incidence is OK. We just have to make sure that the value subcolumn is also per 100,000, probably using an optional population field in the main parameter area. Per year population could be added in the future. What would be w and f though? Alexiscoutinho (talk) 14:21, 23 December 2020 (UTC)
@Alexiscoutinho: w(eek) for 7-days-incidence or f(ortnight) for 14-days-incidence. Without the population count there is of cause no getting to the incedences, so sth like population is mandatory with changetypes w and f. I'll implement at least an example for the changetype in the last test case. Btw, anything against a second testcase page? Things started to blow up (inclusion size?) before I reduced the example data from about 8 weeks to about 4. -- Kohraa Mondel (talk) 15:07, 23 December 2020 (UTC)
@Kohraa Mondel: I don't see why population should be mandatory. I think rolling averages without dividing by population are completely fine. I think the interface should be like: first letter for change type (a, p, r and i) and second, optional, letter for change interval (w and f), for example, rw. If population is given, then everything would be per 100,000. If all the current testcases are relevant and short/compact and yet still there are issues, then I wouldn't be against it. Alexiscoutinho (talk) 16:34, 23 December 2020 (UTC)
@Alexiscoutinho: I agree with your idea but see some problems. Before implementing the whole thing, I'd like to get requirements clear, especially for the parameter options, because they go over the whole code. e.g. changetype is cut down to the first letter in the beginning and then checked against a single letter in several places. Of cause this can be addressed, but it's some work and the code structure is not ideal. Many more variants can be thought of there and then this could soon end up in a hell of changes. So in the first place I would like to implement 7-day rolling average for r and 7-day incidence for w if population is present (otherwise error out). There we'd have some examples to play with, the calculation bases would be ready and proven in use, and then we can think about useful flexibility and also a comprehensible parameter structure. If I use this template and add the population parameter, I might be surprised to get completely different figures, just for one example. Also I want to check some conditions for generated columns data to avoid unexpected inconsistency, like not allowing explicit data in one column, and generated in the next. That goes ok absolute differences or plain percentage, but with the more complex calculations it can get messy for module users and implementers to sort out unexpected behaviour. I'll do these shorthand changes in sandbox2 and then we can have look and decide on further proceeding. With the test cases only my last chapter has some more data, and that can't be avoided if you want to test 14-days incidence including some tricky stuff like no data on holidays or weekends. All the rest entertains quiet spartanic sample data, so I'd open a second testcases page. -- Kohraa Mondel (talk) 20:56, 23 December 2020 (UTC)
Forget about the current handling of changetype. I personally always disliked the "first letter" limitation. But it might be a good idea to use the current interface just to test the new change types. I don't see why editors would be surprised in getting completely different numbers if they add population. What else would they be expecting? Ideally, all data should be generated, including using the undocumented datapage scraper thing. I think manual data column input should only be allowed until the module handles all situations perfectly. If you feel there is no need anymore for manual input, then we could start deprecating those parameters. Otherwise we do have to handle manual and generated columns being together. You also brought up an important point of the hassle of dealing with missing data and date jumps. Maybe the implementation of this feature will require a solution to #17 of the To Do list. Alexiscoutinho (talk) 03:39, 24 December 2020 (UTC)
@Alexiscoutinho:There's now a prototypic implementation of 7-days rolling average and 7-days incidence per 100,000 population, see sandbox2 and testcases2. Where appropriate time is available I set a unix time stamp for each data row as barargs.nDate (see lines 216ff252ff) and then for changetype 'r' loop back to find a data row with a 7-days difference in 258ff function _findIntervalRow at 31ff. Maybe that approach also helps solving #17 in To Do List?? I tried to also implement _findIntervalRow to solve the assumed problem behind #17, so if it doesn't fit, could you give more details on the topic? -- Kohraa Mondel (talk) 12:23, 26 December 2020 (UTC)
@Kohraa Mondel: Firstly sorry to leave you waiting like that. I haven't looked at the code yet, but from looking at the testcase and trying the calculations myself, I suggest that the description of the change should be in the header to decrease repetition, width and to make the chart cleaner/easier to read and understand; and that the = signs be substituted to n.a. or something else since these changes can be different within a date jump (it's only equal (by the way, = means 0, so what should have been written is actually a repetition of the previous change. Maybe it will be better to substitute = to 0 in the template to be clearer) in this case because the date jumps are perfectly periodic and the amount of 0s in each sum of changes is preserved). Alexiscoutinho (talk) 22:59, 26 December 2020 (UTC)
@Alexiscoutinho: Nothing to apologise for ... hope you had some pleasant holidays. About description: I also thought it would be placed in the header best, but how would we deal then with a custom column header (right1|2)? There's a parameter handling decision to be done: do not allow right1|2 with w/r/... options or append some description in parentheses or just leave it to the editor to find some appropriate text if he decides to set right1|2, with or without the mouse-over text for each line as in my example. Regarding the size of the mouse-over there seems to be some tweak with css that at least would reduce the additional per line output to a span with a class only or one might do some client side script if that is possible with mediawiki, but even if: that might be a bad idea for maintenance reason. About the insufficient data situation: I already set n.a. for all of these situations and think it's the only appropriate value to set there, if you don't want to leave it blank. Only for the no date case it gets overrruled later in the code (local function changeArg), and just for the example I didn't want to do changes in too many places that also apply to other changetype options. The example actually has an aperiodic change on Dec 8th (some funny spanish holiday shifted from 6th if it happens to be a sunday, but don't ask me for details), and I already had Dec 15th yield n.a respectively. But just now it unexpected yields a figure there, I'll need to check on that... fixed.
@Kohraa Mondel: I think a change description in parentheses in the header would be best/clearest. I don't see why editors would want to mess around with an alternative change type, also in right1/2. I don't think the mouse-over text is necessary for these columns. I also noticed that other missing date (with different change) xD. By the way, I'll use sandbox(1), so don't change it yet. Alexiscoutinho (talk) 12:33, 27 December 2020 (UTC)
@Alexiscoutinho: With a different case classification like right1data=4 some column header describing that classification like right1=# hospitalised can only be supplied by the editor. In that case it might be best to automatically append the changetype description to the column header, or is it that what you meant, anyway? I'm already using sandbox(1) as it provides me with the back-to-back tests in testcases(1), what is important where you change code structure. But I can keep the results locally on my computer without checking them in to sandbox(1). But at some point I would of cause like to merge it there. -- Kohraa Mondel (talk) 14:12, 27 December 2020 (UTC)
Yes, that's what I meant. I think code reordering should have less priority now, unless it is blocking progress. The first claims the sandbox and the second gets to use his own sandbox or create sandbox3 xD. Oh, furthermore, you can extract Unix time with mw.getLanguage():formatDate('U', barargs[1]) if that's what you wanted. Alexiscoutinho (talk) 17:14, 27 December 2020 (UTC)
@Alexiscoutinho: Implemented metrics explanation for w and r in column header by post-fixing. About "blocking the progress", a bad structure never actually blocks the progress, it only slows everything down, and often an existing fragmentation yields the next. Anyways, now there's sandbox3 and testcases3, so for sometime we can edit in parallel. The unix "formatting" is more or less what I was looking for, only that it returns a string, so tonumber is required to do proper math with it. While for implementation it saves some lines, another question would be if we want to support such a wide variety of date string formattings, that only in us-en context are more or less unambiguous, while yyyy-mm-dd will yield with virtually any language context. Kohraa Mondel (talk) 14:06, 28 December 2020 (UTC)
Once we have some new parameter sets along with some handling specified, I think some overhaul of the implementation might be a good idea, as currently parameter handling is spread rather randomly over the code (a bit in the function passed to getArgs, a lot in p._chart, and still very much in places where output is produced). My idea would be sth like a dedicated function for chart level parameters that does all individual checks and defaults first, and then checks for inappropriate combinations and defaults derived from other parameters. Then a dedicated function to do the same for data rows, also in two passes where the first deals with each line individually and collects metrics, and the second does the automatic stuff. Doing such stuff for the existing parameter handling in the main sandbox first, to have all the back-to-back tests in testcases to check the results, might also be a good idea. But I don't know if the current test cases are sufficient to do such an operation. I read something about scripted comparisons of pages using the module/template in old and new version. You know details about it? -- Kohraa Mondel (talk) 10:54, 27 December 2020 (UTC)
@Kohraa Mondel: That's great, but I urge you to not change (not that you did) the large scale structure/flow of the code (_chart, _buildBars, _row and _customBarStacked). I mean, preserve their names and purpose. _chart should deal with everything not related to bars and also non-repetitive bars stuff. _buildBars should only collect and process data from other rows (which isn't possible in normal templates). _row should handle individual data and stuff and most, if not all, handling that could be done with templates. _customBarStacked should deal with HTML and other formatting which isn't related with real disease data and numbers. Besides, I think the is function can be dropped in almost all cases. Alexiscoutinho (talk) 03:45, 29 December 2020 (UTC)
@Alexiscoutinho: Actually I think that the large scale structure/flow of the module is far from ideal, mostly due to it's past as a set of templates calling each other and different editors implementing features on top of each other over time rather than integrating. But don't worry, I have no intention to go that deep with structural changes as such thing would be a lot of work and not much fun. What I would like to do and already started in sandbox3 is to control the large scale data flow in p.chart calling respective functions to do the details before passing the results to p._buildBars and finally to barBox._box. This leaves two blocks of code to be handled from p._chart, the top level toggles implementation that might deserve its dedicated function, and about 50 lines of html generation that, as you said yourself, do not really belong there and might be integrated to the new toggles function as it all is about the title head of the whole chart. Kohraa Mondel (talk) 08:27, 30 December 2020 (UTC)
@Kohraa Mondel: The reason for not wanting to change that large scale structure is exactly to keep a little bit of the origins I have some personal attachment to. I think a lot can be improved while still using that backbone, making the result at least good enough. I also think that it would be nice to create a _buildHeader function to clean up _chart and increase code symmetry with _buildBars. fillCols should be outside _buildBars and definetely outside that for loop. Alexiscoutinho (talk) 12:50, 30 December 2020 (UTC)
Different behavior
Template ignores all parameters after "3rd classification (total or altlbl1)" at rows with no date or displays them wrong.
If that possible to force not display "recoveries"? 185.66.252.38 (talk) 08:02, 23 October 2020 (UTC)
... or use log-scale? 185.66.252.38 (talk) 16:27, 25 October 2020 (UTC)
@185.66.252.38: Log-scale is not supported. Other line charts would be more appropriate for that I think. Besides, when "smart zoom-in" is implemented, this problem will be mitigated. Alexiscoutinho (talk) 15:31, 3 December 2020 (UTC)
@185.66.252.38: Add this line |recoveries=n to the template and omit numbers in the appropriate data "column". Alexiscoutinho (talk) 15:31, 3 December 2020 (UTC)
Implement automatic divisor calculation; Done here
Convert nested templates to module functions; Done here and here
Minimize chart wikitext length; Mostly done here and here
Support varied update periods; Not done
Implement year and decade toggles; Partly done here
Revamp (month) toggles with JavaSript to solve intersections of sets mess; Waiting approval at phab:T269400
Add "Cumulative" button to toggle between cumulative and new counts; Not done
Implement automatic numwidth determination; Not done
Implement automatic absolute and relative change calculation; Done here
Implement automatic number formatting and, consequently, add note0, note1 and note2 parameters; Automatic number formatting done here, note0/note1/note2 done here
Implement rolling average and incidence change types; Partly done
Implement per 100,000 inhabitants metrics; Partly done
Implement "# of active cases" data column; Partly done
Implement custom bar ordering and display; Not done
Implement smart bar divisor/"zoom in" based on the active time period toggles and visible bars; Table width, but not zoom, will dynamically change based on toggles if barwidth=auto (implemented here)
Implement automatic date jump handling/formatting; Done here and here
I implemented the note1 and note2 parameters in the sandbox and added a respective test case. Pls check if this is what was intended. -- Kohraa Mondel (talk) 15:24, 21 December 2020 (UTC)
@Alexiscoutinho: Ok, moved it to the active module. Additionally I thought of a note prepost-fixed to the date where the whole date is concerned rather than the data shown in col1 or col2, see sandbox and test case -- Kohraa Mondel (talk) 11:22, 22 December 2020 (UTC)
@Kohraa Mondel: I think note or note0 would be better, more symmetrical names. Alexiscoutinho (talk) 13:20, 22 December 2020 (UTC)
@Alexiscoutinho: Ok, changed it to note0 as no column index like note with other parameters means appllciation to both columns. I'd move it from sandbox to the active module whenever you counterchecked it. -- Kohraa Mondel (talk) 13:34, 22 December 2020 (UTC)
Hey people. I have discovered a bug that is becoming a going to become a problem on all of the COVID-related charts now that they are exceeding a year of data. Take the Illinois chart below as an example. When selecting January 2021, it also selects January 2020 and vice versa—you are unable to select just one or the other. I assume this will happen with all months as well. I know it's not a huge issue, but it is an issue. Thanks, EDG 543 (message me) 01:29, 12 January 2021 (UTC)
It doesn't happen on Template:COVID-19 pandemic data/Mainland China medical cases chart when I select December. I looked at the source and it uses {{Medical cases chart/Month toggle button|jan}} to create the month buttons for 2020 but December 2019 is made with span tags. I can't see where the template for the United States makes the month buttons. Are they added by #invoke at the beginning of the template? I also noticed when I looked at the HTML source that many tr tags have the same id (such as mw-customcollapsible-jan). I don't think HTML allows more than one element to have the same id. They should probably be converted into classes. Nine hundred ninety-nine (talk) 00:04, 13 January 2021 (UTC)
Looks like this is also fixed on the Italian Wikipedia. Looks like they've added to make the filter buttons both year- and month-aware. They also adjusted the filter button layout. Someone likely need to port that change over to this and the other wikipedia language sites. I'd take a stab at it, but I am not skilled with the particular programming language used. -- Tom Ntalk/contrib 03:45, 15 January 2021 (UTC)
Now that this code is being worked on, here is a list of feature requests and/or ideas:
Option to suppress the (=) when the delta is zero.
Use +/- for absolute changes, Unicode up and down triangles for percent changes. This would be particularly useful when both change types are displayed together.
Dynamically switch between absolute and percent deltas. I propose using absolute when the current count is under a thousand - there aren't enough significant digits to calculate a good percent delta when counts are small. Also use absolute when the delta is less significant than 0.01%.
The current implementation allows math in classifications. I believe this happens intrinsically because of how Lua handles variables. Please don't break it. I use this to record confirmed and probable numbers even though the reader will only ever see the total. A future data scientist may like having the breakdown.
Currently, bars are aligned with the left edge of the 1st classification. It could be useful to align at a later classification, for example, the left edge of active cases. This would create a tree that grows to both sides, allowing the reader to visually track changes in two values. This is similar to how gender and age can be shown in the same census chart.
Collapse suppressed months into a bar of single pixel tall bars showing each day's data. Clicking on this bar expands it out into the current fat bars with text. Clicking in the fat bars collapses them. This obviates the need for month buttons.
And finally, a potential test case: I've been logging asymptomatic counts in comments in the Idaho chart. The current code has no clean way to show them - they are a subset of recoveries. EphemeralErrata (talk) 10:19, 16 January 2021 (UTC)
Pages and templates being put into script error categories
Resolved
Something in this template/module is making articles and templates appear in Category:Pages with script errors. I don't see any red error messages that usually appear to help with diagnosis.
I have made a simplified example in my sandbox. When I remove the month toggle coding, the script error category goes away. – Jonesey95 (talk) 00:32, 18 January 2021 (UTC)
I was just looking at that. See Template:Medical cases chart/Month toggle button ("Script error: The function "monthToggleButton" does not exist.") and Module:Medical cases chart which has _monthToggleButton (with underscore). Also see the history of that module—there is some excitement. However, previewing with the underscore shows other problems. Perhaps Alexiscoutinho can work out what the problem is. Johnuniq (talk) 23:13, 18 January 2021 (UTC)
The problem is that function p.monthToggleButton(frame) was removed in a massive restructure: 21:55, 16 January 2021. However, {{Medical cases chart/Month toggle button}} uses {{#invoke:Medical cases chart|monthToggleButton}}. That is, it is calling the removed function. Restoring the function does not work because of the other refactoring. I don't know what would happen if the previous revision were restored while we wait for a proper fix. @Alexiscoutinho: Don't worry about the problems; we're not trying to hassle you as we understand that working on complex setups like this will occasionally break. Johnuniq (talk) 04:34, 19 January 2021 (UTC)
Thanks for the fixes, the error category is now clear. Johnuniq (talk) 22:27, 19 January 2021 (UTC)
Suppressing the VTE links
How do we suppress the VTE links (for example in this chart)? We don't want to send editors to a non-existing page. Thanks! Plastikspork―Œ(talk) 14:41, 19 May 2021 (UTC)
Lua error in Module:Medical_cases_chart at line 346: invalid date "2021-05-38". Date should be 2021/05/28. Lannertcito (talk) 13:17, 29 May 2021 (UTC)
Lua error in Module:Medical_cases_chart at line 346: invalid date "2021-05-38". Please change 2021/05/38 to 2021/05/28. Lannertcito (talk) 13:20, 29 May 2021 (UTC)
Note: Not found Run n Fly (talk) 15:03, 30 May 2021 (UTC)
TfD outcome
@Pppery: From what I understood, you were the only one against GKFX's propositions. Frankly speaking, your arguments were well countered by GKFX and indirectly by my recent (many) conversions. I think the outcome was more like "barely no consensus", however, since I'm not talking about a delete, only a redirect, I don't think we strictly need a consensus to move forward, if you still stand by your first comment. Alexiscoutinho (talk) 18:56, 22 June 2021 (UTC)
The outcome was "no consensus". That does not mean "implement the proposal anyway", and that decision should not be ignored. What you've done is an inappropriate fait accompli. It might have been okay originally to proceed without any discussion, but now that there has been a discussion, its result should not be ignored. * Pppery *it has begun... 19:22, 22 June 2021 (UTC)
@Pppery: Do I have to open a new TfD entry then? By the way, I agree my action on those ~127 articles might not have been nice, but, in the end of the day, I think they were just numbers, not an argument or evidence. It's not like they explicitly decided/preferred to use the template version (except 1 I think). In other words, even if I didn't make those many conversions, that 127 articles sentence would still be almost meaningless in my view. Alexiscoutinho (talk) 19:41, 22 June 2021 (UTC)
The actual number was irrelevant, and trying to justify a new TfD based on fait accompli actions is even worse. I would likely have !voted keep regardless of the number. My point at the TfD was more than I failed to see a good reason for deliberately breaking things or making large numbers of edits that accomplished nothing, and the problem that the original proposal was attempting to solve should have been solved in a different way. If you believe the closure incorrectly reflected the consensus of the discussion, then you should follow the proper procedures for challenging closures, not try to subvert it just because you disagree. * Pppery *it has begun... 19:48, 22 June 2021 (UTC)
Personally I think the closure was dubious. There were three votes to stop transcluding the template (me, Alexiscoutinho, Izno), one (possibly non-voting) suggestion on how to stop transcluding the template (67.70), one oppose (Pppery), and one "wow". That makes 3 and a bit to one by my count, albeit with no consensus on how to go about not transcluding it. I personally don't feel like going through DRV but if @Alexiscoutinho wants to they should go ahead. User:GKFXtalk 20:06, 22 June 2021 (UTC)
I didn't say I justified a new TfD based on those many conversions. That was just a side note after my question. Furthermore, all my previous actions were in good faith and I never deliberately tried subverting anything. Alexiscoutinho (talk) 20:17, 22 June 2021 (UTC)
@Pppery and GKFX: I have a new idea: simply deprecate (add a message) the template, but otherwise keep its (tiny) content for transclusions. All current pages would still need to be migrated to #invoke... but old page versions would not break badly. Should I open a new TfD entry for it, accepting the latest one? Alexiscoutinho (talk) 14:48, 27 June 2021 (UTC)
This template is already completely gone from everywhere except userspace and its own pages, so there's no point leaving it in the current state where the documentation and talk page are in the wrong place. Officially you should wait another month to WP:RENOM a no-consensus closure, but WP:DRV can be done whenever. As the template was mostly used within other templates, there should be little effect on viewing old revisions of articles if this template were deleted/broken altogether. User:GKFXtalk 15:22, 27 June 2021 (UTC)
The documentation and talk would be moved of course. By the way, when I said "old page versions" I mostly thought of templates. I think I'll wait then. Alexiscoutinho (talk) 16:16, 27 June 2021 (UTC)
Done here
Mostly done here and here
Not done
Resolved
Note: Not found Run n Fly (talk) 15:03, 30 May 2021 (UTC)