Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Quantocius Quantotius (talk | contribs) at 23:01, 28 October 2020 (→‎Help is needed to make the header row with sorting icons sticky: This could probably be shorter but I'm too short on time to try and rewrite it, hope everyone likes reading.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.


PROPOSAL: Allow whitelisted pages to exceed Wikipedia's technical limits

There are good reasons for particular pages to exceed Wikipedia:Template limits and other limits.

Recent examples include administrative and administrative-archive pages that use {{revisions}} extensively or which use {{backlog status}}, and some list-type pages that use {{ill}}, {{cfb link}}, or {{football kit}} extensively hit the expensive parser function call limit. Some very long, heavily-referenced articles hit the post expansion include size limit (several COVID- and US-2020-election-related pages are over the limit now).

Sometimes, as with sports lists that used {{flag}} extensively, the PEIS limit can be fixed by creating modules, like Module:Flagg. That doesn't always get a page below the limit though.

I recommend that the Wikimedia software be changed to allow whitelisted pages to have double the usual limits. I'm flexible on the "double" but it should be at least 1.5x but probably less than 3x. This whitelist would of course need to be on a fully- or perhaps template-editor-protected page. Note that pages that are above the normal limits should still be put in maintenance categories so they can be reduced where feasible (see Special:TrackingCategories). Pages should only be on the whitelist if there is no other good option. davidwr/(talk)/(contribs) 16:36, 17 October 2020 (UTC)[reply]

Support - Allow whitelisted pages to exceed Wikipedia's technical limits

  1. Support as the initial proponent. davidwr/(talk)/(contribs) 16:36, 17 October 2020 (UTC)[reply]
  2. Support as a temporary solution: I think it would make more sense to abandon these limits entirely and to instead improve (modernize) the Mediawiki software so that reference-templates and/or transclusions don't cause a high server load and long load-times and add ways to better display long articles and make them more accessible, navigable and useful.
The Post-expand include size limit seems to be due to the long Transclusion expansion time. I have detailed my research into this problem here. So far I have not received an answer what the main underlying problem is (neither there nor at this code issue at phabricator) – if anybody here knows, please leave a comment.
This has been a substantial problem at, for example, many COVID19-related articles (e.g. COVID-19 pandemic in Japan) and 2020 in science (now fractured and incomplete which has a few disadvantages; note that most content is just text/wikilinks and images should lazy-load).
I partially agree with Izno's oppose and Headbomb's neutral: imo whitelisting would add unneeded resource-/workload/complexity. But it might be good way to test this out before allowing it for all pages, might not require as much resources/work as expected, could be built into the current review-mechanism and would be better than the current state. --Prototyperspective (talk) 21:30, 18 October 2020 (UTC)[reply]

Oppose - Allow whitelisted pages to exceed Wikipedia's technical limits

  1. Not worth the additional complexity. This is one of those ideas that maybe should not be all votey. --Izno (talk) 21:14, 17 October 2020 (UTC)[reply]
  2. Strong oppose - There is no point to this. There are not any articles that need to come close to exceeding technical limits. It's a lazy response to articles which are too large. Onetwothreeip (talk) 21:30, 18 October 2020 (UTC)[reply]
  3. This would create a security threat as bad actors could exploit the whitelisting to lock up our servers. Also just not worthwhile when the articles can (and should) be split. — Wug·a·po·des​ 00:44, 24 October 2020 (UTC)[reply]
  4. Oppose: Expensive functions are, well, expensive. It takes server load to run expensive parser calls, especially several hundred of them. There probably are other solutions and workarounds like caching that can fix the problem, but this seems to be a brave idea. Aasim (talk) 22:15, 28 October 2020 (UTC)[reply]

Neutral - Allow whitelisted pages to exceed Wikipedia's technical limits

  1. Support in principle, this would be useful on a handful of pages. In practice, do we really want to devote WMF resources to handle a handful of pages? Headbomb {t · c · p · b} 21:35, 17 October 2020 (UTC)[reply]

Comments - Allow whitelisted pages to exceed Wikipedia's technical limits

  • A major consideration would be "how easy is this to abuse"? Is it likely that someone would cherry-pick pages with "larger limits" and use that to launch a denial-of-service attack? If the "higher limits" are reasonable, I don't think this will be a major issue. davidwr/(talk)/(contribs) 16:36, 17 October 2020 (UTC)[reply]
    @Davidwr: Please open a phab ticket. It's pointless to discuss this here if MediaWiki developers are unwilling to implement it (see WP:CONEXCEPT). – SD0001 (talk) 18:51, 17 October 2020 (UTC)[reply]
    That will ultimately have to happen, but I want to get a sense of whether it's wanted by the community or not before I bother to open a ticket. davidwr/(talk)/(contribs) 19:16, 17 October 2020 (UTC)[reply]
    @Davidwr: in this case - it needs to be wanted by the developer community or its not going to happen, we didn't ask for it to be in place it was foisted upon us. — xaosflux Talk 20:05, 17 October 2020 (UTC)[reply]
    Developers might be interested in which solutions have been proposed and the usefulness of suggested changes. Some solutions to the underlying problem/s (whitelisting being 1 of those) could make Wikipedia load much faster, substantially reduce server-load and costs, allow for hosting more content, help editors struggling and using workarounds to maintain articles (such as COVID19-related ones) and allow for later modernizations of WP via additions of otherwise commonplace features etc. --Prototyperspective (talk) 14:20, 23 October 2020 (UTC)[reply]
    What exactly would a whitelist do? Suppress an error message? The error would still occur, the templates would still not be expanded, nothing would be gained. --Redrose64 🌹 (talk) 22:38, 23 October 2020 (UTC)[reply]
    No, it wouldn't. The idea is that if a page IS on the whitelist, the Wikimedia software would refer to a different, higher, limit when checking the limits. You would have, say, two limits for "expensive parser functions" - 500 for pages not on the whitelist, and a higher number, say, 1000, for pages on it. Similar with other limits. davidwr/(talk)/(contribs) 23:48, 23 October 2020 (UTC)[reply]
  • Well "technical limit" means "technical limit". Of course, it's possible to raise the limit, but that's not open to voting and so this discussion is not actually useful. What would be better use of time is to open a phabriactor task with detailed argument which shows understanding of the implications and why raising the limit is feasible and worthwhile at the same time. – Ammarpad (talk) 05:17, 18 October 2020 (UTC)[reply]
  • No. I hope no developer will implement this proposal. The proper solution is to fix performance of local templates, not to jeopardize service availability by putting random loopholes in. --Malyacko (talk) 10:27, 18 October 2020 (UTC)[reply]
    @User:Malyacko: Agree, but it doesn't seem like this is getting done and this proposal could be a good improvised temporary solution until it is. I have asked about what you described in a code issue at phabricator as well as, with more details, at talk:Template limits and so far haven't received any answer about what the root problems are or any indications of somebody of the WMF or of the current devs willing to resolve the underlying problem. --Prototyperspective (talk) 11:19, 19 October 2020 (UTC)[reply]
  • Without any official WMF buy-in, this is a pointless proposal. Also, any discussion should take on on Phabricator, and not on VPT (I'm pretty sure the WMF devs don't monitor this page). -FASTILY 04:12, 19 October 2020 (UTC)[reply]
  • What are some examples of pages that need this? Is there no local hack that can be used to get around it (eg, do modules contribute to that? I could've sworn I read some kind of hack that involved modules for a similar issue? perhaps making it up), or performance improvements that can be made to those templates? ProcrastinatingReader (talk) 14:56, 23 October 2020 (UTC)[reply]
    I listed 2 examples in my comment above: COVID-19 pandemic in Japan and 2020 in science. There's also a category of pages which exceeded these limits and it contained a fair amount of articles despite editors being forced to implement workarounds. Many other COVID19-related articles were also affected.
    One workaround which could be used, and I think is often used, is to remove references or to stop using reference-templates (like {{cite journal|...) as these cause the longest "Transclusion expansion time". I don't think that this a good solution: usually most references are useful, required and important and using reference templates makes the references more convenient, machine-readable and formatted better.
    Performance-improvements to the way templates and alike are used is exactly what I was proposing in the discussion also linked in my comment above as well as in the phabricator issue. (However, I'm still not entirely sure if the problem is what I think it is – and hence whether or not the suggested solution would make sense – as no developer or WMF person has yet answered my questions.) --Prototyperspective (talk) 15:37, 23 October 2020 (UTC)[reply]
In those cases where references are causing template loading issues, that indicates the article is too long and should be split. Onetwothreeip (talk) 00:37, 24 October 2020 (UTC)[reply]
It may indicate that, but it doesn't necessarily mean that this is the case. Whitelisting instead of raising or removing those artificial limits for all pages may better facilitate attempts to keep the relevant articles shorter plus not implementing workarounds such as removing references and/or reference-templates.
Furthermore, there could also be other (imo long-overdue and otherwise very commonplace) technical features to keep articles short even though they are on one page (and not inappropriately split for the sake of it) – such as not loading/fetching collapsed tables and statistics until the [show]-button is pressed (I think content such as this is partly what caused many COVID19-related articles to exceed these limits). --Prototyperspective (talk) 09:28, 24 October 2020 (UTC)[reply]
Template:COVID-19 pandemic data is up to 333 references. For a single template. And it is a template that is no longer needed. It is in only one article: COVID-19 pandemic by country and territory.
Template:COVID-19 pandemic death rates is also in that article. It has more info (such as death rates by country), and is from a single source: Johns Hopkins University, Coronavirus Resource Center.
The table with 333 references should be removed from the article. It is regularly out of date compared to the John Hopkins table. --Timeshifter (talk) 01:41, 25 October 2020 (UTC)[reply]
You make it sound like this was these articles had with the template limits and even that this would be the only problem this proposal is about. It's not. And the bold-formatting isn't appropriate imo.
Furthermore, these references probably were useful for the template but maybe they should have been displayed separately from the article's other templates (e.g. only show when the template is uncollapsed but not show when its state is collapsed).
Should we source information from one single private research organization instead of multiple sources due to artificial, and imo outdated, limits? I don't think we should for the sake of it but only when it is due. If, in this case, they have higher quality data than the respective sources this still wasn't the case earlier. But again: this wasn't the only thing COVID19-related articles had that made the artificial limit become a problem. Here you can see some, but not all, of the articles which have problems with the template-limits. --Prototyperspective (talk) 10:06, 25 October 2020 (UTC)[reply]
undent: I have already provided the obvious work around for the COVID cases, which is to not transclude the table references directly into all of its targets (i.e., make the last table column <noincluded). That would remove some 300 references from each and every article those tables are transcluded to. It is pathological anyway and should not be driving software changes. I have so far seen one case where the limits might reasonably be raised or transclusion worked on in any meaningful fashion, and it's not even on Wikipedia, it's Wikisource. If you can find a case where the limit must be raised, I will be pleasantly surprised, but in almost every other case there is a workaround sufficient to meet both policy and guideline. --Izno (talk) 21:07, 25 October 2020 (UTC)[reply]
  • An example that may something like this might be useful for is {{Preloaddraft}}, which is used on some redlink lists for editathons in the WP: namespace (uses preload function to create a skeleton article with sections and infobox etc). Such lists can be very long, but viewed infrequently, so the load on techincal infrustructure wouldn't be great. I don't know aboutt the broader implelications in articlespace, so have left as a comment rather than a vote. T.Shafee(Evo&Evo)talk 04:01, 28 October 2020 (UTC)[reply]

Infobox plurality

At {{Infobox newspaper}}, Funandtrvl recently observed that, since some newspapers have multiple managing editors, the |maneditor= parameter could display as Managing editor(s) instead of Managing editor. I think it's cleaner to not have to use the (s) formulation, so we set it up so that the label will display as Managing editor when |maneditor= is used and Managing editors when |maneditors= is used.

However, we're now looking at some of the other parameters, such as |owner= (with alias |owners=), which has displayed as Owner(s) for years. Changing this to work similarly to the managing editor parameter could potentially introduce some minor errors: if someone previously used |owner= for a plural, they would need to switch to using |owners= instead to get the plurality right, and I don't think we'd have any way of notifying pages that'd be affected. On the flip side, the change would allow the vast majority of newspapers with a singular owner to avoid the unsightly (s), and any pages displaying incorrectly would presumably eventually be fixed.

I bring this up here because this same issue applies to tons and tons of infobox templates, from Conviction(s) at {{Infobox criminal}} to Spouse(s) at {{Infobox person}}. We discussed the latter two months ago but haven't taken any action from it yet. {{Detect singular}} is available and is used on templates like {{Infobox settlement}}, but has a few limitations/bugs.

The extremely widespread applicability makes this topic worth discussing, imo (it would of course be extremely nitpicky at the level of an individual article). So, what approach do you all think we should take here? Is the tradeoff of potentially introducing the incorrect plurality to some existing pages worth it for setting up a better way to handle plurality that'll allow us to avoid having to use (s) into perpetuity? Or should we pursue the more technical route and try to get {{Detect singular}} working well enough to handle all of this for us automatically? {{u|Sdkb}} talk 07:33, 21 October 2020 (UTC)[reply]

As you say above, there is a common pattern that we should handle in some generic way. How about a new template something like {{plural}}?
{{One or many|value for one|value for many|text for one|optional text for many if we do not just add an s}}
For example: the {{Infobox newspaper}} template has
| label4     = Owner(s)
| data4      = {{{owners|{{{owner|}}}}}}
which could be replaced with:
| label4     = {{One or many|{{{owner}}}|{{{owners}}}|Owner|Owners}}
| data4      = {{{owners|{{{owner|}}}}}}
The template could complain if both owner/owners are defined (and perhaps also if neither is defined, although that would be valid in some cases). We then might use {{Detect singular}} to generate a tracking category should it think that |owners= is singular or |owner= is a list. — GhostInTheMachine talk to me 17:38, 21 October 2020 (UTC)[reply]
Would something like {{Singular and plural}} work, or could be adapted to do this? Also, I am finding singular owners while using the plural "owners" in the template. Funandtrvl (talk) 19:18, 21 October 2020 (UTC)[reply]
{{Singular and plural}} looks like it's designed for when the link for Apples goes somewhere different than the one for Apple. That's a somewhat different purpose than what we're looking at here. {{u|Sdkb}} talk 21:54, 24 October 2020 (UTC)[reply]
I believe the number of users who will forget to change the parameter name when adding a second value is significant. I'm a highly-detail-picky developer and it seems like a mistake I would easily make. I don't see anything wrong with the (s) construct in the label. Even if the template code could figure out from the value whether to pluralize the label or not, I don't think it's worth the extra processing time, code maintenance, etc. —[AlanM1 (talk)]— 05:39, 26 October 2020 (UTC)[reply]

Missing "the First" redirects

Could someone create a list of all pages with the word "I" (upper case) as a non-first word, where no parallel page "the First" exists? 217.132.248.209 (talk) 19:08, 22 October 2020 (UTC)[reply]

Please clarify your request. I assume you mean something like Ramesses I and not The King and I? And is there even consensus to redirect Ramesses the First to Ramesses I ? RudolfRed (talk) 22:40, 22 October 2020 (UTC)[reply]
IP, you are going to get a list of 13,000+ articles that includes things like How I Met Your Mother, most likely. That search returns a lot of redirects, though, and someone over at Wikipedia:Request a query might be able to exclude redirects for you. – Jonesey95 (talk) 23:25, 22 October 2020 (UTC)[reply]
I don't see why not.
Also I think you'd actually want to filter for titles where:
  • The title contains a (for the sake of simplicity, potentially valid) Roman numeral (something \b[MDCLXVI]+\b), AND:
  • This Roman numeral either is:
    • ( At the end of the title, OR:
    • Immediately followed by opening parentheses, or the word "of", or a comma ((?= \(| of|\,)), or any other pattern that might be common for disambiguating royalty but unusual after "I" as a pronoun. )
  • AND The word prior to the Roman numeral consists of a capital letter followed by lowercase letters (but does not necessarily match \b[A-Z][a-z]+\b, due to diacritics).
False positives would be greatly reduced without losing much, but you'd still catch a few weird ones where the pronoun follows a verb, which (unlike "and") does get capitalized in song titles like "It Was I". This is probably not common enough to bother blacklisting specific words. ―cobaltcigs 11:52, 23 October 2020 (UTC)[reply]

How to add a div id based on a counter

Is it possible to assign/rename a div id based on a counter using TemplateStyles? I'm looking to add an anchor to each thumbimage via this style.css (implemented at this test page) with each ID numbered using the figure-n-counter parameter. thanks in advance of any advice/assistance/ T.Shafee(Evo&Evo)talk 04:11, 23 October 2020 (UTC)[reply]

No, IDs cannot be changed in CSS, only by JavaScript. And even that I guess most wouldn't do. Lua may be able to do what you want if you hand-roll the thumbing of the images (i.e., use wiki syntax to display an image and then "thumb" it using Lua). That solution of course would be brittle and possibly would not display as expected into the future. --Izno (talk) 07:09, 23 October 2020 (UTC)[reply]

Template:FAQ

Is there similar template which would allow us to add "recommendation"? There is Template:FAQ but I have no particular question and answer but I would like to mention something, additional explanation for talk page. It would be useful in articles which are often moved from correct to incorrect tittles. Something similar to Template:Correct title but for talkpage. Eurohunter (talk) 14:32, 23 October 2020 (UTC)[reply]

Article Name

Dear fellow Wikipedians, I find some of the article names are in red instead of white. Can you explain the reason. Cheers.... Anupam Dutta (talk) 14:38, 23 October 2020 (UTC)[reply]

  • Red is a link to an article that doesn't exist, either because it was deleted or because it hasn't been created yet. Popperman99 (talk) 14:52, 23 October 2020 (UTC)[reply]
See Wikipedia:Red link. Graham87 04:51, 24 October 2020 (UTC)[reply]
Anupamdutta73, I don't ever recall seeing an article title in white, did you mean blue? S Philbrick(Talk) 21:25, 28 October 2020 (UTC)[reply]

Order of fields on top

Is there a way to configure the order of fields on the top right? I believe previously watchlist and contributions were to the left of preferences and sandbox. Contributions is something I use often, and since it is now next to Log out, I sometimes accidentally click on Log out - which is a total disaster, because I get logged out of all devices, and it costs me half an our to login again. If I had sandbox or preferences next to Log out, it would have been much safer.--Ymblanter (talk) 18:54, 23 October 2020 (UTC)[reply]

A dumb workaround could be to create a second Contributions link called "My Edits" or something like that, to the right of the Sandbox link. Look at my vector.js for "Add link at top for Tools page" to see how to do it. – Jonesey95 (talk) 21:22, 23 October 2020 (UTC)[reply]
There's also a script to confirm logouts by Writ Keeper, as discussed in this village pump thread. Graham87 04:50, 24 October 2020 (UTC)[reply]
Thanks to both of you, both solutions should work. I installed the logout confirmation for the time being, will see how convenient it is.--Ymblanter (talk) 09:49, 24 October 2020 (UTC)[reply]
Sandbox was never to the right of either watchlist or contributions, but it's possible that prefs was between contribs and logout at some point. When the sandbox link was first added, it was the leftmost link; but I don't recall whether it took up its present position (between talk and prefs) before or after the notifications icons were added. --Redrose64 🌹 (talk) 10:01, 24 October 2020 (UTC)[reply]
Add this line to your common.js $('#pt-logout').hide(); // remove the logout link — GhostInTheMachine talk to me 10:17, 24 October 2020 (UTC)[reply]
Also bookmark Special:Logout or add the link to your user page, so you could log out if you really need to. — GhostInTheMachine talk to me 10:25, 24 October 2020 (UTC)[reply]

Private replication?

Would it be technically possible, under present offerings and available data, for a private replication of Wikipedia (all languages) maintained off-site outside the WMF data center? It would be similar to Toolforge's replication server where the database has a relatively short update lag. -- GreenC 18:55, 23 October 2020 (UTC)[reply]

That is not a service that is presently offered. You could maybe do it yourself by starting with a database dump and then using eventstreams to keep it up to date. ST47 (talk) 01:33, 24 October 2020 (UTC)[reply]
Ok. Thank you. -- GreenC 03:26, 24 October 2020 (UTC)[reply]

Reftoolbar 2.0 Auto-format

I believe I'm using Reftoolbar 2.0. There is a little icon in the upper left on it that looks like a whisk broom. Always before, when I clicked on that, it put dashes in an ISBN, such as:

|isbn=9789882208902

The tool is still on the toolbar. But as of today when I click it – on either Firefox or Chrome – it doesn't do anything. And it tends to get very faint when I click on it. If I refresh the page, I can see it again. But it still doesn't do anything. I've tried several ISBNs as a test and nothing happens. Is someone working on this tool at the moment? I think it worked earlier in the day. — Maile (talk) 22:00, 23 October 2020 (UTC)[reply]

Never mind. It seems the tool doesn't like the one particular ISBN above, but it is otherwise working as normal. — Maile (talk) 01:06, 26 October 2020 (UTC)[reply]

Random article may not be totally random.

Sometimes when I'm bored I just come to Wikipedia and click "random article." Probably on average once a week, although with much variance -- sometimes several times in one week, other times not at all for months.

Today I clicked "random article" and came up with the article on Caryocolum leucothoracellum. As soon as I saw it, I recognized this as an article I read a couple weeks ago. I suppose I could be wrong about it, but I'm moderately certain. It's not the name I remembered (although I did remember that it was a moth with a long-ish name) but the range. I'm a geography geek, and when I read a list of countries I visualize them as if on a map. That visual stays with me after the names are gone.

Anyway, I'm certain that I read this article very recently, as in "within the last couple of weeks." With over six million articles on Wikipedia, it seems to me the odds are enormous against hitting the same one twice in a small number of attempts.

This is not a complaint in the traditional sense. I'm not harmed in any way by reading an article twice. I'm not particularly bothered, offended, irritated, or anything like that. It just made me wonder how robust is the randomness of the "random article" function? Does it deserve to be reviewed?

I can't supply much in the way of technical data. I use Chrome and Firefox interchangeably. Today I'm using Chrome, but I can't say for sure which I was using last time I read this article. But it doesn't seem that this would be a user-side issue, anyway.

Apologies if this is posted in the wrong areas. I did browse the site for some time looking for a more appropriate place to post this. — Preceding unsigned comment added by 2001:1970:54A6:7800:CA9:7F10:D708:558F (talk) 02:30, 24 October 2020 (UTC)[reply]

This is pretty interesting. If this gets moved somewhere, someone please notify me because I want to follow this. First of all I would hope that the function is not entirely random, such as to exclude potentially vulgar or controversial topics. IP editor, can you confirm for us if you indeed read the same article in the last month? You should be able to check your web page history on your browsers. If it was not the same article but an article about another moth, that would still be interesting. Also, how many random articles would you estimate you had loaded in the time between these two articles? Onetwothreeip (talk) 03:26, 24 October 2020 (UTC)[reply]
See this technical FAQ entry. Graham87 04:37, 24 October 2020 (UTC)[reply]
Also to note that while it is improbable it does not mean it is impossible. If enough people asked two friends to pick a random number between 1 and 6 million, eventually you'll find a group who pick the same number. Lugnuts Fire Walk with Me 09:02, 25 October 2020 (UTC)[reply]
Its not random. See phab:T200703 (and mw:Manual:Random_page) Christian75 (talk) 13:49, 27 October 2020 (UTC)[reply]

Help is needed to make the header row with sorting icons sticky

Need help with the template CSS:

Help is needed to make both the main header row, and the header row with sorting icons, sticky. The second link below has a partially collapsed table that is narrower due to a separate header row with sorting icons. But when you scroll down only one row is sticky (stays visible). Need both header rows to remain sticky.


Collapsed table. See table wikitext here: User:Timeshifter/Sandbox124

[show all]
[collapse]
Cumulative COVID-19 deaths on Jan 11, and first day of following months
Date Jan 11 Feb 1 Mar 1 Apr 1 May 1 Jun 1 Jul 1 Aug 1 Sep 1 Oct 1
World 1 259 2,977 40,598 224,172 371,166 508,055 675,060 848,445 1,010,639
Days to double 6 4 16 8 18 37 56 70 80 94
Countries and territories 1 1 8 125 175 185 186 192 191 193
 USA 0 0 1 2,850 55,337 102,640 126,573 151,265 182,162 204,642
 Brazil 0 0 0 159 5,466 28,834 58,314 91,263 120,828 142,921
 India 0 0 0 38 1,147 5,394 17,400 36,511 65,288 98,678
 Mexico 0 0 0 28 1,732 9,779 27,121 46,000 64,158 77,163
 UK 0 0 0 1,789 26,771 38,489 43,730 46,119 41,501 42,143
 Italy 0 0 29 12,430 27,967 33,415 34,767 35,141 35,483 35,894
 Peru 0 0 0 24 943 4,371 9,504 19,021 28,788 32,396
 Spain 0 0 0 8,189 24,543 29,045 28,355 28,445 29,141 31,791
 France 0 0 2 3,514 24,342 28,746 29,760 30,147 30,494 31,746
 Iran 0 0 43 2,898 6,028 7,797 10,817 16,766 21,571 26,169
 Colombia 0 0 0 14 278 890 3,223 9,810 19,364 25,828
 Russia 0 0 0 17 1,169 4,855 9,536 14,058 17,299 20,891
 South Africa 0 0 0 5 103 683 2,657 8,005 14,149 16,734
 Argentina 0 0 0 24 215 530 1,283 3,466 8,498 16,519
 Chile 0 0 0 12 227 1,054 5,688 9,457 11,289 12,741
 Ecuador 0 0 0 75 900 3,358 4,527 5,702 6,556 11,355
 Indonesia 0 0 0 136 792 1,613 2,876 5,131 7,417 10,740
 Belgium 0 0 0 705 7,594 9,467 9,754 9,841 9,897 10,020
 Germany 0 0 0 732 6,288 8,511 8,985 9,148 9,302 9,500
 Canada 0 0 0 89 3,082 7,092 8,566 8,929 9,117 9,291
 Iraq 0 0 0 50 93 205 1,943 4,741 7,042 9,181
 Turkey 0 0 0 214 3,174 4,540 5,131 5,691 6,370 8,195
 Bolivia 0 0 0 6 59 310 1,071 2,894 4,966 7,931
 Pakistan 0 0 0 26 385 1,543 4,395 5,951 6,298 6,479
 Netherlands 0 0 0 1,039 4,795 5,956 6,113 6,147 6,215 6,397
 Egypt 0 0 0 46 392 959 2,953 4,805 5,421 5,914
 Sweden 0 0 0 180 2,586 4,395 5,333 5,743 5,820 5,893
 Philippines 0 0 1 88 568 957 1,266 2,023 3,558 5,504
 Bangladesh 0 0 0 6 168 650 1,847 3,111 4,281 5,251
 Romania 0 0 0 69 717 1,262 1,651 2,343 3,621 4,825
 Saudi Arabia 0 0 0 10 162 503 1,649 2,866 3,897 4,768
 China 1 259 2,873 3,321 4,643 4,645 4,648 4,668 4,730 4,746
 Ukraine 0 0 0 17 272 718 1,173 1,709 2,605 4,193
 Guatemala 0 0 0 1 16 102 746 1,924 2,760 3,246
 Poland 0 0 0 33 644 1,064 1,463 1,716 2,039 2,513
 Panama 0 0 0 24 178 330 620 1,397 1,995 2,364
 Honduras 0 0 0 2 71 201 485 1,312 1,858 2,323
 Morocco 0 0 0 36 170 205 228 353 1,141 2,152
 Dominican Republic 0 0 0 51 301 502 747 1,160 1,710 2,105
 Kazakhstan 0 0 0 2 25 41 188 793 1,878 2,075
 Portugal 0 0 0 160 989 1,410 1,576 1,735 1,822 1,971
 Ireland 0 0 0 71 1,232 1,652 1,736 1,763 1,777 1,804
  Switzerland 0 0 0 373 1,422 1,656 1,683 1,703 1,725 1,782
 Algeria 0 0 0 35 450 653 912 1,210 1,510 1,736
 Japan 0 0 5 57 432 892 974 1,011 1,296 1,571
 Israel 0 0 0 21 223 285 319 493 961 1,543
 Afghanistan 0 0 0 4 64 265 774 1,283 1,406 1,458
 Moldova 0 0 0 3 119 295 547 778 995 1,320
 Ethiopia 0 0 0 0 3 11 103 274 809 1,198
 Nigeria 0 0 0 1 58 287 590 879 1,013 1,112
 Kyrgyzstan 0 0 0 0 8 16 62 1,397 1,060 1,065
 Armenia 0 0 0 3 33 139 453 749 881 963
 Oman 0 0 0 1 11 49 176 421 685 935
 Australia 0 0 0 20 92 103 104 196 652 886
 Costa Rica 0 0 0 2 6 10 15 140 418 880
 Bosnia and Herzegovina 0 0 0 12 68 152 185 324 603 849
 El Salvador 0 0 0 0 9 46 174 448 717 843
 Paraguay 0 0 0 3 9 11 17 47 308 841
 Sudan 0 0 0 2 31 286 572 746 823 836
 Belarus 0 0 0 0 89 235 392 559 681 833
 Bulgaria 0 0 0 8 66 140 230 383 629 825
 Austria 0 0 0 128 584 668 705 718 733 799
 Hungary 0 0 0 16 323 526 585 596 615 781
 Serbia 0 0 0 13 179 243 277 573 713 749
 North Macedonia 0 0 0 9 77 133 302 486 603 739
 Kenya 0 0 0 1 17 64 148 341 577 711
 Puerto Rico 0 0 0 8 54 136 153 219 434 661
 Czechia 0 0 0 31 236 320 349 382 424 655
 Denmark 0 0 0 90 452 574 605 615 624 650
 Venezuela 0 0 0 3 10 14 48 158 381 621
 Kosovo 0 0 0 1 22 30 41 217 515 615
 Kuwait 0 0 0 0 26 212 354 447 531 610
 Azerbaijan 0 0 0 5 24 63 213 448 534 591
 Yemen 0 0 0 0 2 81 313 494 567 588
 Libya 0 0 0 0 3 5 24 74 237 551
   Nepal 0 0 0 0 0 8 29 56 228 498
 Uzbekistan 0 0 0 2 9 15 26 143 322 471
 Cameroon 0 0 0 6 61 191 313 391 414 418
 UAE 0 0 0 6 105 264 315 351 384 416
 South Korea 0 0 18 165 248 271 282 301 324 415
 Greece 0 0 0 49 140 175 192 206 266 391
 Albania 0 0 0 13 31 33 65 157 284 387
 Palestine 0 0 0 1 2 5 11 85 173 368
 Lebanon 0 0 0 12 24 27 34 59 167 361
 Finland 0 0 0 17 211 320 328 329 335 344
 Zambia 0 0 0 0 3 7 24 151 288 332
 Senegal 0 0 0 0 9 42 112 205 284 311
 Myanmar 0 0 0 1 6 6 6 6 6 310
 Ghana 0 0 0 5 17 36 112 182 276 301
 Croatia 0 0 0 6 69 103 107 145 186 280
 Norway 0 0 0 28 204 236 250 255 264 274
 DRC 0 0 0 8 31 71 169 214 258 272
 Bahrain 0 0 0 4 8 19 87 148 190 246
 Tunisia 0 0 0 10 41 48 50 50 77 246
 Madagascar 0 0 0 0 0 6 20 106 192 230
 Haiti 0 0 0 0 7 41 105 161 201 229
 Zimbabwe 0 0 0 1 4 4 7 67 202 228
 Qatar 0 0 0 2 10 38 113 174 197 214
 Syria 0 0 0 2 3 5 9 43 112 197
 Angola 0 0 0 2 2 4 13 51 108 183
 Malawi 0 0 0 0 3 4 16 114 175 179
 Montenegro 0 0 0 2 7 9 12 49 100 170
 Mauritania 0 0 0 0 1 23 128 157 159 161
 Nicaragua 0 0 0 1 4 35 74 116 137 151
 Slovenia 0 0 0 13 91 108 111 117 128 138
 Malaysia 0 0 0 43 102 115 121 125 127 136
 Mali 0 0 0 0 26 77 116 124 126 131
 Luxembourg 0 0 0 23 90 110 110 114 124 124
 Cuba 0 0 0 6 61 83 86 87 94 122
 Namibia 0 0 0 0 0 0 0 10 75 121
 Cote d'Ivoire 0 0 0 0 14 33 66 102 115 120
 Gambia 0 0 0 1 1 1 2 9 96 112
 Eswatini 0 0 0 0 1 2 11 40 91 109
 Jamaica 0 0 0 1 7 9 10 10 21 107
 Suriname 0 0 0 0 1 1 13 26 67 104
 Somalia 0 0 0 0 28 78 90 93 98 99
 Bahamas 0 0 0 0 11 11 11 14 43 95
 Lithuania 0 0 0 7 45 70 78 80 86 92
 Congo 0 0 0 0 9 20 41 56 78 89
 Chad 0 0 0 0 3 65 74 75 77 85
 Equatorial Guinea 0 0 0 0 2 12 12 83 83 83
 Liberia 0 0 0 0 16 27 36 75 82 82
 Guyana 0 0 0 2 8 12 12 20 37 78
 Tajikistan 0 0 0 0 0 47 52 60 68 76
 Trinidad and Tobago 0 0 0 3 8 8 8 8 22 75
 Uganda 0 0 0 0 0 0 0 3 32 75
 Sierra Leone 0 0 0 0 7 46 60 67 70 72
 Niger 0 0 0 3 32 64 67 69 69 69
 Guinea 0 0 0 0 7 23 33 46 59 66
 French Guiana 0 0 0 0 1 1 15 43 59 66
 Estonia 0 0 0 4 52 68 69 69 64 64
 Central African Republic 0 0 0 0 0 2 47 59 62 62
 Jordan 0 0 0 5 8 9 9 11 15 61
 Djibouti 0 0 0 0 2 24 54 58 60 61
 Mozambique 0 0 0 0 0 2 6 11 23 61
 Cabo Verde 0 0 0 1 1 4 15 23 40 60
 Thailand 0 0 0 12 54 57 58 58 58 59
 Burkina Faso 0 0 0 14 43 53 53 53 55 57
 Guadeloupe 0 0 0 5 12 14 14 14 16 57
 Gabon 0 0 0 1 3 17 42 49 53 54
 Andorra 0 0 0 12 42 51 52 66 53 53
 Guam 0 0 0 2 5 5 5 5 10 49
 South Sudan 0 0 0 0 0 10 38 46 47 49
 Togo 0 0 0 1 9 13 14 18 27 48
 Uruguay 0 0 0 1 15 22 27 35 44 48
 Slovakia 0 0 0 0 23 28 28 29 33 48
 San Marino 0 0 0 26 41 42 42 42 42 42
 Mayotte 0 0 0 0 4 23 35 39 40 42
 Benin 0 0 0 0 2 3 21 36 40 41
 Georgia 0 0 0 0 6 12 15 17 19 40
 Guinea-Bissau 0 0 0 0 1 8 24 27 33 39
 Latvia 0 0 0 0 15 24 30 32 34 37
 Lesotho 0 0 0 0 0 0 0 13 31 36
 Vietnam 0 0 0 0 0 0 0 2 34 35
 Malta 0 0 0 0 4 7 9 9 12 34
 Maldives 0 0 0 0 0 5 8 16 28 34
 Jersey 0 0 0 2 20 29 31 31 32 32
 Rwanda 0 0 0 0 0 1 2 5 16 29
 Singapore 0 0 0 3 15 23 26 27 27 27
 Belize 0 0 0 0 2 2 2 2 13 26
 Aruba 0 0 0 0 2 3 3 3 10 26
 New Zealand 0 0 0 1 19 22 22 22 22 25
 Isle of Man 0 0 0 0 22 24 24 24 24 24
 Cyprus 0 0 0 8 20 17 19 19 21 22
 Sint Maarten 0 0 0 0 13 15 15 15 17 22
 Martinique 0 0 0 2 14 14 14 15 16 21
 Tanzania 0 0 0 1 17 21 21 21 21 21
 US Virgin Islands 0 0 0 0 4 6 6 8 14 20
 Botswana 0 0 0 0 1 1 1 2 6 16
 Reunion 0 0 0 0 0 1 2 4 5 16
 São Tomé and Príncipe 0 0 0 0 1 10 11 15 15 15
  Other 0 0 6 7 13 13 13 13 13 13
 Sri Lanka 0 0 0 2 7 10 11 11 12 13
 Guernsey 0 0 0 1 13 13 13 13 13 13
 Iceland 0 0 0 2 10 10 10 10 10 10
 Mauritius 0 0 0 5 10 10 10 10 10 10
 Bermuda 0 0 0 0 6 9 9 9 9 9
 Saint Martin 0 0 0 2 3 3 3 3 5 8
 Barbados 0 0 0 0 7 7 7 7 7 7
 Comoros 0 0 0 0 0 2 7 7 7 7
 Papua New Guinea 0 0 0 0 0 0 0 2 5 7
 French Polynesia 0 0 0 0 0 0 0 0 0 7
 Turks and Caicos 0 0 0 0 1 1 2 2 3 6
 Brunei 0 0 0 1 1 2 3 3 3 3
 Antigua and Barbuda 0 0 0 0 3 3 3 3 3 3
 Northern Mariana Islands 0 0 0 0 2 2 2 2 2 2
 Fiji 0 0 0 0 0 0 0 1 2 2
 Cayman Islands 0 0 0 1 1 1 1 1 1 1
 Curaçao 0 0 0 1 1 1 1 1 1 1
 Liechtenstein 0 0 0 0 1 1 1 1 1 1
 Monaco 0 0 0 0 1 1 1 1 1 1
 British Virgin Islands 0 0 0 0 1 1 1 1 1 1
 Burundi 0 0 0 0 1 1 1 1 1 1
 Montserrat 0 0 0 0 1 1 1 1 1 1
 Caribbean Netherlands 0 0 0 0 0 0 0 0 0 1


Narrower collapsed table. See table wikitext here: User:Timeshifter/Sandbox125

[show all]
[collapse]
Cumulative COVID-19 deaths on Jan 11, and first day of following months
Date Jan 11 Feb 1 Mar 1 Apr 1 May 1 Jun 1 Jul 1 Aug 1 Sep 1 Oct 1

World 1 259 2,977 40,598 224,172 371,166 508,055 675,060 848,445 1,010,639
Days to double 6 4 16 8 18 37 56 70 80 94
Countries and territories 1 1 8 125 175 185 186 192 191 193
 USA 0 0 1 2,850 55,337 102,640 126,573 151,265 182,162 204,642
 Brazil 0 0 0 159 5,466 28,834 58,314 91,263 120,828 142,921
 India 0 0 0 38 1,147 5,394 17,400 36,511 65,288 98,678
 Mexico 0 0 0 28 1,732 9,779 27,121 46,000 64,158 77,163
 UK 0 0 0 1,789 26,771 38,489 43,730 46,119 41,501 42,143
 Italy 0 0 29 12,430 27,967 33,415 34,767 35,141 35,483 35,894
 Peru 0 0 0 24 943 4,371 9,504 19,021 28,788 32,396
 Spain 0 0 0 8,189 24,543 29,045 28,355 28,445 29,141 31,791
 France 0 0 2 3,514 24,342 28,746 29,760 30,147 30,494 31,746
 Iran 0 0 43 2,898 6,028 7,797 10,817 16,766 21,571 26,169
 Colombia 0 0 0 14 278 890 3,223 9,810 19,364 25,828
 Russia 0 0 0 17 1,169 4,855 9,536 14,058 17,299 20,891
 South Africa 0 0 0 5 103 683 2,657 8,005 14,149 16,734
 Argentina 0 0 0 24 215 530 1,283 3,466 8,498 16,519
 Chile 0 0 0 12 227 1,054 5,688 9,457 11,289 12,741
 Ecuador 0 0 0 75 900 3,358 4,527 5,702 6,556 11,355
 Indonesia 0 0 0 136 792 1,613 2,876 5,131 7,417 10,740
 Belgium 0 0 0 705 7,594 9,467 9,754 9,841 9,897 10,020
 Germany 0 0 0 732 6,288 8,511 8,985 9,148 9,302 9,500
 Canada 0 0 0 89 3,082 7,092 8,566 8,929 9,117 9,291
 Iraq 0 0 0 50 93 205 1,943 4,741 7,042 9,181
 Turkey 0 0 0 214 3,174 4,540 5,131 5,691 6,370 8,195
 Bolivia 0 0 0 6 59 310 1,071 2,894 4,966 7,931
 Pakistan 0 0 0 26 385 1,543 4,395 5,951 6,298 6,479
 Netherlands 0 0 0 1,039 4,795 5,956 6,113 6,147 6,215 6,397
 Egypt 0 0 0 46 392 959 2,953 4,805 5,421 5,914
 Sweden 0 0 0 180 2,586 4,395 5,333 5,743 5,820 5,893
 Philippines 0 0 1 88 568 957 1,266 2,023 3,558 5,504
 Bangladesh 0 0 0 6 168 650 1,847 3,111 4,281 5,251
 Romania 0 0 0 69 717 1,262 1,651 2,343 3,621 4,825
 Saudi Arabia 0 0 0 10 162 503 1,649 2,866 3,897 4,768
 China 1 259 2,873 3,321 4,643 4,645 4,648 4,668 4,730 4,746
 Ukraine 0 0 0 17 272 718 1,173 1,709 2,605 4,193
 Guatemala 0 0 0 1 16 102 746 1,924 2,760 3,246
 Poland 0 0 0 33 644 1,064 1,463 1,716 2,039 2,513
 Panama 0 0 0 24 178 330 620 1,397 1,995 2,364
 Honduras 0 0 0 2 71 201 485 1,312 1,858 2,323
 Morocco 0 0 0 36 170 205 228 353 1,141 2,152
 Dominican Republic 0 0 0 51 301 502 747 1,160 1,710 2,105
 Kazakhstan 0 0 0 2 25 41 188 793 1,878 2,075
 Portugal 0 0 0 160 989 1,410 1,576 1,735 1,822 1,971
 Ireland 0 0 0 71 1,232 1,652 1,736 1,763 1,777 1,804
  Switzerland 0 0 0 373 1,422 1,656 1,683 1,703 1,725 1,782
 Algeria 0 0 0 35 450 653 912 1,210 1,510 1,736
 Japan 0 0 5 57 432 892 974 1,011 1,296 1,571
 Israel 0 0 0 21 223 285 319 493 961 1,543
 Afghanistan 0 0 0 4 64 265 774 1,283 1,406 1,458
 Moldova 0 0 0 3 119 295 547 778 995 1,320
 Ethiopia 0 0 0 0 3 11 103 274 809 1,198
 Nigeria 0 0 0 1 58 287 590 879 1,013 1,112
 Kyrgyzstan 0 0 0 0 8 16 62 1,397 1,060 1,065
 Armenia 0 0 0 3 33 139 453 749 881 963
 Oman 0 0 0 1 11 49 176 421 685 935
 Australia 0 0 0 20 92 103 104 196 652 886
 Costa Rica 0 0 0 2 6 10 15 140 418 880
 Bosnia and Herzegovina 0 0 0 12 68 152 185 324 603 849
 El Salvador 0 0 0 0 9 46 174 448 717 843
 Paraguay 0 0 0 3 9 11 17 47 308 841
 Sudan 0 0 0 2 31 286 572 746 823 836
 Belarus 0 0 0 0 89 235 392 559 681 833
 Bulgaria 0 0 0 8 66 140 230 383 629 825
 Austria 0 0 0 128 584 668 705 718 733 799
 Hungary 0 0 0 16 323 526 585 596 615 781
 Serbia 0 0 0 13 179 243 277 573 713 749
 North Macedonia 0 0 0 9 77 133 302 486 603 739
 Kenya 0 0 0 1 17 64 148 341 577 711
 Puerto Rico 0 0 0 8 54 136 153 219 434 661
 Czechia 0 0 0 31 236 320 349 382 424 655
 Denmark 0 0 0 90 452 574 605 615 624 650
 Venezuela 0 0 0 3 10 14 48 158 381 621
 Kosovo 0 0 0 1 22 30 41 217 515 615
 Kuwait 0 0 0 0 26 212 354 447 531 610
 Azerbaijan 0 0 0 5 24 63 213 448 534 591
 Yemen 0 0 0 0 2 81 313 494 567 588
 Libya 0 0 0 0 3 5 24 74 237 551
   Nepal 0 0 0 0 0 8 29 56 228 498
 Uzbekistan 0 0 0 2 9 15 26 143 322 471
 Cameroon 0 0 0 6 61 191 313 391 414 418
 UAE 0 0 0 6 105 264 315 351 384 416
 South Korea 0 0 18 165 248 271 282 301 324 415
 Greece 0 0 0 49 140 175 192 206 266 391
 Albania 0 0 0 13 31 33 65 157 284 387
 Palestine 0 0 0 1 2 5 11 85 173 368
 Lebanon 0 0 0 12 24 27 34 59 167 361
 Finland 0 0 0 17 211 320 328 329 335 344
 Zambia 0 0 0 0 3 7 24 151 288 332
 Senegal 0 0 0 0 9 42 112 205 284 311
 Myanmar 0 0 0 1 6 6 6 6 6 310
 Ghana 0 0 0 5 17 36 112 182 276 301
 Croatia 0 0 0 6 69 103 107 145 186 280
 Norway 0 0 0 28 204 236 250 255 264 274
 DRC 0 0 0 8 31 71 169 214 258 272
 Bahrain 0 0 0 4 8 19 87 148 190 246
 Tunisia 0 0 0 10 41 48 50 50 77 246
 Madagascar 0 0 0 0 0 6 20 106 192 230
 Haiti 0 0 0 0 7 41 105 161 201 229
 Zimbabwe 0 0 0 1 4 4 7 67 202 228
 Qatar 0 0 0 2 10 38 113 174 197 214
 Syria 0 0 0 2 3 5 9 43 112 197
 Angola 0 0 0 2 2 4 13 51 108 183
 Malawi 0 0 0 0 3 4 16 114 175 179
 Montenegro 0 0 0 2 7 9 12 49 100 170
 Mauritania 0 0 0 0 1 23 128 157 159 161
 Nicaragua 0 0 0 1 4 35 74 116 137 151
 Slovenia 0 0 0 13 91 108 111 117 128 138
 Malaysia 0 0 0 43 102 115 121 125 127 136
 Mali 0 0 0 0 26 77 116 124 126 131
 Luxembourg 0 0 0 23 90 110 110 114 124 124
 Cuba 0 0 0 6 61 83 86 87 94 122
 Namibia 0 0 0 0 0 0 0 10 75 121
 Cote d'Ivoire 0 0 0 0 14 33 66 102 115 120
 Gambia 0 0 0 1 1 1 2 9 96 112
 Eswatini 0 0 0 0 1 2 11 40 91 109
 Jamaica 0 0 0 1 7 9 10 10 21 107
 Suriname 0 0 0 0 1 1 13 26 67 104
 Somalia 0 0 0 0 28 78 90 93 98 99
 Bahamas 0 0 0 0 11 11 11 14 43 95
 Lithuania 0 0 0 7 45 70 78 80 86 92
 Congo 0 0 0 0 9 20 41 56 78 89
 Chad 0 0 0 0 3 65 74 75 77 85
 Equatorial Guinea 0 0 0 0 2 12 12 83 83 83
 Liberia 0 0 0 0 16 27 36 75 82 82
 Guyana 0 0 0 2 8 12 12 20 37 78
 Tajikistan 0 0 0 0 0 47 52 60 68 76
 Trinidad and Tobago 0 0 0 3 8 8 8 8 22 75
 Uganda 0 0 0 0 0 0 0 3 32 75
 Sierra Leone 0 0 0 0 7 46 60 67 70 72
 Niger 0 0 0 3 32 64 67 69 69 69
 Guinea 0 0 0 0 7 23 33 46 59 66
 French Guiana 0 0 0 0 1 1 15 43 59 66
 Estonia 0 0 0 4 52 68 69 69 64 64
 Central African Republic 0 0 0 0 0 2 47 59 62 62
 Jordan 0 0 0 5 8 9 9 11 15 61
 Djibouti 0 0 0 0 2 24 54 58 60 61
 Mozambique 0 0 0 0 0 2 6 11 23 61
 Cabo Verde 0 0 0 1 1 4 15 23 40 60
 Thailand 0 0 0 12 54 57 58 58 58 59
 Burkina Faso 0 0 0 14 43 53 53 53 55 57
 Guadeloupe 0 0 0 5 12 14 14 14 16 57
 Gabon 0 0 0 1 3 17 42 49 53 54
 Andorra 0 0 0 12 42 51 52 66 53 53
 Guam 0 0 0 2 5 5 5 5 10 49
 South Sudan 0 0 0 0 0 10 38 46 47 49
 Togo 0 0 0 1 9 13 14 18 27 48
 Uruguay 0 0 0 1 15 22 27 35 44 48
 Slovakia 0 0 0 0 23 28 28 29 33 48
 San Marino 0 0 0 26 41 42 42 42 42 42
 Mayotte 0 0 0 0 4 23 35 39 40 42
 Benin 0 0 0 0 2 3 21 36 40 41
 Georgia 0 0 0 0 6 12 15 17 19 40
 Guinea-Bissau 0 0 0 0 1 8 24 27 33 39
 Latvia 0 0 0 0 15 24 30 32 34 37
 Lesotho 0 0 0 0 0 0 0 13 31 36
 Vietnam 0 0 0 0 0 0 0 2 34 35
 Malta 0 0 0 0 4 7 9 9 12 34
 Maldives 0 0 0 0 0 5 8 16 28 34
 Jersey 0 0 0 2 20 29 31 31 32 32
 Rwanda 0 0 0 0 0 1 2 5 16 29
 Singapore 0 0 0 3 15 23 26 27 27 27
 Belize 0 0 0 0 2 2 2 2 13 26
 Aruba 0 0 0 0 2 3 3 3 10 26
 New Zealand 0 0 0 1 19 22 22 22 22 25
 Isle of Man 0 0 0 0 22 24 24 24 24 24
 Cyprus 0 0 0 8 20 17 19 19 21 22
 Sint Maarten 0 0 0 0 13 15 15 15 17 22
 Martinique 0 0 0 2 14 14 14 15 16 21
 Tanzania 0 0 0 1 17 21 21 21 21 21
 US Virgin Islands 0 0 0 0 4 6 6 8 14 20
 Botswana 0 0 0 0 1 1 1 2 6 16
 Reunion 0 0 0 0 0 1 2 4 5 16
 São Tomé and Príncipe 0 0 0 0 1 10 11 15 15 15
  Other 0 0 6 7 13 13 13 13 13 13
 Sri Lanka 0 0 0 2 7 10 11 11 12 13
 Guernsey 0 0 0 1 13 13 13 13 13 13
 Iceland 0 0 0 2 10 10 10 10 10 10
 Mauritius 0 0 0 5 10 10 10 10 10 10
 Bermuda 0 0 0 0 6 9 9 9 9 9
 Saint Martin 0 0 0 2 3 3 3 3 5 8
 Barbados 0 0 0 0 7 7 7 7 7 7
 Comoros 0 0 0 0 0 2 7 7 7 7
 Papua New Guinea 0 0 0 0 0 0 0 2 5 7
 French Polynesia 0 0 0 0 0 0 0 0 0 7
 Turks and Caicos 0 0 0 0 1 1 2 2 3 6
 Brunei 0 0 0 1 1 2 3 3 3 3
 Antigua and Barbuda 0 0 0 0 3 3 3 3 3 3
 Northern Mariana Islands 0 0 0 0 2 2 2 2 2 2
 Fiji 0 0 0 0 0 0 0 1 2 2
 Cayman Islands 0 0 0 1 1 1 1 1 1 1
 Curaçao 0 0 0 1 1 1 1 1 1 1
 Liechtenstein 0 0 0 0 1 1 1 1 1 1
 Monaco 0 0 0 0 1 1 1 1 1 1
 British Virgin Islands 0 0 0 0 1 1 1 1 1 1
 Burundi 0 0 0 0 1 1 1 1 1 1
 Montserrat 0 0 0 0 1 1 1 1 1 1
 Caribbean Netherlands 0 0 0 0 0 0 0 0 0 1

--Timeshifter (talk) 11:59, 24 October 2020 (UTC)[reply]

@Timeshifter:  Done just add class="covid-sticky covid-sticky-2" to line 9 in User:Timeshifter/Sandbox125 to achieve the desired effect. Please ping me if there are any issues I should be around again at some point this week.
𝒬𝔔 21:43, 25 October 2020 (UTC)[reply]

(unindent). Thanks Quantocius Quantotius. I tried the new sticky code you discussed. It did not work. I tried adding class="covid-sticky covid-sticky-2" and class=covid-sticky-2 and class=covid-sticky-2. I added them to line 9 and line 11. Various combinations were tried. Only one header row could be made sticky.

I created a sandbox where you could experiment:

Here is the current unaltered wikitext below. I am talking about the 2 lines starting with |- 

|- class=covid-sticky
!Date!!Jan&nbsp;11!!Feb&nbsp;1!!Mar&nbsp;1!!Apr&nbsp;1!!May&nbsp;1!!Jun&nbsp;1!!Jul&nbsp;1!!Aug&nbsp;1!!Sep&nbsp;1!!Oct&nbsp;1
|- 
!<br>!!  !! !! !! !! !! !! !! !! !!

--Timeshifter (talk) 23:40, 25 October 2020 (UTC)[reply]

For those who are interested there is related discussion about the "show all" and "collapse" buttons. Currently they work only on the top table when there is more than one partially collapsed table on a page. See:
User talk:Timeshifter#Separate but related questions.
--Timeshifter (talk) 23:47, 25 October 2020 (UTC)[reply]

(unindent). I also asked for help here:

I pointed them back to here. --Timeshifter (talk) 07:10, 27 October 2020 (UTC)[reply]

Mfb found a partial solution by shortening the header names, and putting the sorting icons back with the header names. It has been implemented here:
Template:Monthly cumulative COVID-19 death totals by country
But there will be a need for a sticky sorting row in other partially collapsed tables.
--Timeshifter (talk) 07:55, 28 October 2020 (UTC)[reply]
Timeshifter, there is no real good fix for this at this time. Simply put, browsers don't support this problem, unless you specifically write CSS for each and every usecase. What needs to happen is that in addition to setting "covid-sticky" class on the 2nd row, you would have to add something like this to the stylesheet:
tr.covid-sticky:nth-child(2) > th {
   top: 78px; /* height of first row */
}
Unfortunately the height of the 1st row however is hard to determine because parts of it are in pixels (lineheight) and other parts in em (padding). And the content in the first row can wrap to two lines of course, so then any calculation goes out the window. So this technique breaks quite easily.
What is really needed to properly support this, is allowing usage of position stick on the thead element, but unfortunately browsers don't support this yet (I've been asking them for 8 years already). —TheDJ (talk • contribs) 14:18, 28 October 2020 (UTC)[reply]
@Timeshifter and TheDJ: I just went in and applied the narrowing update to Template:Monthly cumulative COVID-19 death totals by country/sandbox, this functions by setting the 1st element to a specific height in em; not the most eloquent solution but there aren't many good options. The class combination is working for me, but please double check and let me know if there are any issues as I don't have the time right now to run this through a bunch of VMs to see if there are issues on all common device/browser combos.
I also implemented a fix for the show/collapse issue when multiple tables are present for Template:COVID-19 pandemic data, Template:COVID-19 pandemic death rates, and Template:Monthly cumulative COVID-19 death totals by country; the solution is extremely hacky but it worked at Draft:Sandbox, and for reasons I'll get to there's no clean way to implement this.
The primary issue is that whoever set this up never intended for multiple templates that it supports to be on the same page. As such the appropriate level of specificity is being ensured through use of an ID, this is a good solution when you have one supported template per page, but breaks down as soon as a second one is used. This is because all IDs must be unique in their own subtree (basically document-wide) and now we have two or more elements with the same ID (technical details ). This results in undefined behavior. Since browsers are usually quite forgiving when it comes to HTML rendering, the result is not disastrous but it does cause numerous issues. Also note that even if current html renderers work in this instance, there's no guarantee they will continue to do so in the future as it is contrary to the specification. So the real solution is to refactor the code completely to avoid relying on an ID for the specificity needed, but this is easier said than done especially as it involves synchronizing dozens of templates that rely on this stylesheet.
Getting back to the issue at hand, typical browser behavior when an ID being targeted belongs to multiple elements is to target only the first element with that ID; hence the current show/collapse issue. To avoid that problem, I've wrapped each of the three tables mentioned above in another div to give them a unique ID and targeted that ID instead. I've also gone ahead and switched the collapse button from #top to #void to avoid the user being returned to the top of the page, as opposed to just the top of the div, which will work as long as there is no ID or section called void (null target could be done more efficiently with js, but there are security concerns).
So as I said above, the real solution is to refactor this entirely, and let's face it the current CodeSmell ain't exactly pleasant, but that will take several hours and I won't have that kind of time until at least the second half of November if then. In the meantime it would help if someone starts compiling a list of the classes and IDs currently being used by every template running off this stylesheet to help understand why things are currently put together the way they are, as well as to help identify things that are no longer needed.
𝒬𝔔 23:01, 28 October 2020 (UTC)[reply]

Some tracking categories that don't exist

Why isn't there a category that contains all archives of all talk pages (there used to be one) or one that contains all templates without documentation (there is a category named Category:Templates with missing or incorrect documentation, but it is only manually populated)? JsfasdF252 (talk) 13:35, 24 October 2020 (UTC)[reply]

To automatically put templates into such a category would require changes to the software or a bot to check for missing documentation. I can't think of an effective way to check for incorrect documentation. Given that the biggest bang for the buck is documenting more frequently used templates, relying on manual requests for documentation is probably better than just putting every single template without documentation into a single category.
Is there some task you are interested in doing with the archives for every single talk page? You can find those following a standard naming convention with a database query (not my area of expertise but someone else here will know the details). isaacl (talk) 17:43, 24 October 2020 (UTC)[reply]

Ombuds vs Ombudsman?

{{Functionaries}} links to https://en.wikipedia.org/w/index.php?title=Special:GlobalUsers&group=ombudsman, which produces no output. It looks like the right group name should be ombuds, not ombudsman. Is this something that got changed at some point in history and the template just never got updated? -- RoySmith (talk) 16:26, 24 October 2020 (UTC)[reply]

Yes, there was an name change in June of this year from Ombudsman to Ombuds, discussed here.--Snaevar (talk) 18:21, 24 October 2020 (UTC)[reply]
Links updated — JJMC89 (T·C) 21:12, 24 October 2020 (UTC)[reply]

Coordinates in search results

When using our search system coordinates show up in the search results:...i.e when searching a country you get.....

Coordinates: 60°N 110°W / 60°N 110°W / 60; -110 Canada is a country in the northern....

Should we be omitting Template:Coord in our search results? Seems to be over data for no reason.--Moxy 🍁 00:20, 25 October 2020 (UTC)[reply]

@Moxy: What was your search term? Alternatively, the URL of the search results page would be helpful. --Redrose64 🌹 (talk) 11:09, 26 October 2020 (UTC)[reply]
@Redrose64: Happens to me with this. —[AlanM1 (talk)]— 01:19, 27 October 2020 (UTC)[reply]

"Musical scores are temporarily disabled" appearing on music pages

Tracked in Phabricator
Task T257066

I don't know if this is a thing that has been happening recently, but I've never seen it before: on some music pages, including the official pages for talking about music notation markup code in Wikipedia itself, instead of the score snippets that usually appear, I'm only seeing a box containing "Musical scores are temporarily disabled". This does not happen for all scores on the page, for instance on the page for Mozart's Symphony No. 40, snippets for movements 2 and 3 appear normally, but movements 1 and 4 have this error message. It's not an issue with my browser or internet connection either, since it happens in Firefox and Chrome on my PC over ethernet, and it also happens in Safari on my phone over cellular data. — Preceding unsigned comment added by 135.180.100.205 (talk) 07:44, 25 October 2020 (UTC)[reply]

See phab:T257066. --AKlapper (WMF) (talk) 09:36, 25 October 2020 (UTC)[reply]

Is there a bot that could replace some uncontroversial redirects and pipes?

Throughout the years, I've seen a bunch of redirects to some Polish cities were the only difference is a diacritic. Krakow (and Cracow) to Kraków, Gdansk to Gdańsk, Wroclaw to Wroclaw, Poznan to Poznań and Lodz to Łódż are most common (one could simply use the List of cities and towns in Poland for all major cities/towns). None of those are controversial, as this is not related to historical names like Danzig or Breslau, but simply to Polish names rendered in English without a diacritic. I wonder if there is a bot that start fixing it? For usage without a hyperlink we can't use an automated tool as it could mess up things like book titles or people's names or other rare but expected outlier, but when there is a link present and so the target is clear, there is zero reason to use the diacritc-less version, and zero chance of error (unintended change that would mess up the meaning/context) - this is at the same level as an uncontroversial, not ambigious spelling fix/etc. So how could we get this done? --Piotr Konieczny aka Prokonsul Piotrus| reply here 11:58, 25 October 2020 (UTC)[reply]

Didn't there use to be a bot that corrected links to redirects tagged {{R from misspelling}}? Seems it could be easily adapted to {{R to diacritic}}. —Cryptic 13:18, 25 October 2020 (UTC)[reply]
I think there might have been something like that. Anyone remembers more? --Piotr Konieczny aka Prokonsul Piotrus| reply here 01:44, 28 October 2020 (UTC)[reply]
The issue is this is still WP:CONTEXTBOT, for things like quotes and such, e.g. "James said that Lodz was really nice last year" is perfectly fine English. Headbomb {t · c · p · b} 03:08, 28 October 2020 (UTC)[reply]

infobox scientist

What is the problem with Gertrude Nye Dorry's infobox? Her thesis is now shown in the article. Ali Pirhayati (talk) 14:18, 25 October 2020 (UTC)[reply]

The template {{Infobox scientist}} wasn't showing the thesis section for the |thesis= (only for |thesis1= and/or |thesis2=). The example in Gertrude Nye Dorry could be fixed by using |thesis1=, |thesis1_url= and |thesis1_year=, but I've modificed the infobox template and it now works. —  Jts1882 | talk  14:46, 25 October 2020 (UTC)[reply]

Tracking category page without (empty)

Would there be a way to make a category page (that would be linked to by the main tracking category page) that only listed sub-categories that were full? Example: In Category:Infoboxes with unknown parameters there are numerous subcategories that are (empty). It makes it a little hard to find subcategories that aren't empty when looking through the wall of text. It would be easier to go through if only non-empty subcategories were listed (on a separate linked-to page). Firestarforever (talk) 17:44, 25 October 2020 (UTC)[reply]

There's probably a way to display only the non-0 categories with WP:Petscan and definitely a way with WP:Quarry. Consider a request at WP:RAQ. --Izno (talk) 20:24, 25 October 2020 (UTC)[reply]
You could do a find on the page for " P)". – Jonesey95 (talk) 21:35, 25 October 2020 (UTC)[reply]
I put together a scraper here, if anyone's interested (excuse the messy code). Problem solved. Firestarforever (talk) 01:47, 26 October 2020 (UTC)[reply]
If somebody would be willing to file a phab: request, I think that the devs could modify the mediawiki software in such a way that the subcategory entries on a category page are given one of two different classes - one to denote empty, the other to denote not-empty. Then we could use user CSS to hide one set or the other, as desired. --Redrose64 🌹 (talk) 11:06, 26 October 2020 (UTC)[reply]

Flipping the order of a table

Per WP:SALORDER, if a table is ordered chronologically, it should start with the oldest entry at the top and have the newest entry at the bottom. I often discover lists that use the reverse order, as I assume people think readers are more likely to want to see the most recent entries than the oldest. Nevertheless, this is against Wikipedia's guidelines for stand-alone lists. The last one of these that I came across was List of Wales national rugby union team results, which has 731 entries. I would like to flip the order of the table, but due to its size, this would be very labour-intensive. Therefore I would like to ask if there is any way to perform this task quickly and easily? Any tips would be gratefully received. – PeeJay 14:14, 26 October 2020 (UTC)[reply]

I just made the table sortable, which is an instant solution if not actually answering your question. — GhostInTheMachine talk to me 15:05, 26 October 2020 (UTC)[reply]
Yeah, that definitely isn't the solution I was looking for. The table should be in the correct order to start with and not require sortability. – PeeJay 10:31, 27 October 2020 (UTC)[reply]
I think there is an offwiki tool specifically for this, but I don't have it to hand. VisualEditor can do this too with the use of Excel/LibreOffice (copy from VE, paste into Excel, sort the table, copy from Excel, paste back into VE). That will preserve the values, but I do not know about any styles, classes, or other attributes. --Izno (talk) 15:10, 26 October 2020 (UTC)[reply]
Thanks, Izno, I'll give it a go. – PeeJay 10:31, 27 October 2020 (UTC)[reply]
Nope, didn't work. Good idea though. Guess I'll just have to go through all 731 entries and reverse the table manually. – PeeJay 18:56, 27 October 2020 (UTC)[reply]

Tech News: 2020-44

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Problems

  • You will be able to read but not to edit the wikis for up to an hour on October 27 around 14:00 (UTC). It will probably be shorter than an hour. [1]
  • Last week, links to "diffs" from mobile watchlists and recentchanges were linking to page-revisions instead of diffs. This has now been fixed. [2]

Changes later this week

  • There is no new MediaWiki version this week.

Future changes

  • Since the introduction of the interface administrators user group in 2018, administrators couldn’t view the deleted history of CSS/JS pages. Now they can. [3]
  • There was a problem with the Change Tags. The software would apply the "Reverted" tag to any page actions such as page-protection changes if they came directly after a reverted edit. This has now been fixed for new edits. [4]
  • The Reply tool will be offered as an opt-in Beta Feature on most Wikipedias in November. Another announcement will be made once the date is finalized. [5]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

17:37, 26 October 2020 (UTC)

I thought subpages were disabled in category namespace

There is a Wikipedia category named Wikipedia naming conventions/Transportation, which is a subpage of Wikipedia naming conventions. This is contrary to WP:SUBPAGE's claim about subpages being disabled in category namespace. Is this a bug or did somebody forget to disable subpages for categories? JsfasdF252 (talk) 18:25, 26 October 2020 (UTC)[reply]

Or is WP:Subpages wrong? :) --Izno (talk) 18:50, 26 October 2020 (UTC)[reply]
The default is to allow sub-pages for category talk but not for category pages - see the software default. — GhostInTheMachine talk to me 18:17, 27 October 2020 (UTC)[reply]
... and on EN wiki, namespace 8 (MediaWiki) is set to not allow subpages — see current configuration — GhostInTheMachine talk to me 18:40, 27 October 2020 (UTC)[reply]

'Geo: ...' doesn't link

Compare

What gives? AFAICT 'Geo:' isn't an interwiki thing, and even if it were, it would not render this way. But somehow

links? What's going on here? Headbomb {t · c · p · b} 21:00, 26 October 2020 (UTC)[reply]

  • It's a URI similar to http:, see geo URI scheme, so it formats the same way as a web link does in WikiCode:
Bare: Geo:blablablah -> Geo:blablablah
With a single set of square brackets: [Geo:blablablah] -> [6]
With a single set of square brackets a space and a word: [Geo:blablablah Blah] -> Blah
With two sets of square brackets (the wrong way!): [[Geo:blablablah]] -> [[7]]
By the way, [[:anything:everything:you:can:think:of]] will display as a wikilink, thanks to the : in the front: anything:everything:you:can:think:of.
davidwr/(talk)/(contribs) 00:04, 27 October 2020 (UTC)[reply]
Also, I think it is part of the data-values/geo library that we have loaded taking that over in the parser. You can open a phab ticket to further explain maybe, because I can't find wiki-specific documentation on it. — xaosflux Talk 00:12, 27 October 2020 (UTC)[reply]
@MaxSem: may have more info on if this is part of GeoData extension as well? — xaosflux Talk 00:42, 27 October 2020 (UTC)[reply]
Sorry for the ping MaxSem, think I've answered this below now. — xaosflux Talk 00:44, 27 October 2020 (UTC)[reply]
@Headbomb: this appears to be because "geo:" is a $wgUrlProtocol so it is reserved. — xaosflux Talk 00:44, 27 October 2020 (UTC)[reply]

AbuseFilter notice: rmspecials() will no longer remove whitespace when used in filters

Hello,

Apologies if you are not reading this message in your native language. Please help translate to other languages..

We are making a change to the AbuseFilter extension, which may impact the behavior of some existing filters. The rmspecials() function currently removes spaces in addition to special characters. We will change it such that it will only remove special characters. The existing rmwhitespace() can be used to remove spaces whenever applicable.

As reported on https://phabricator.wikimedia.org/P12854 we believe at least one filter on your wiki has been identified to use the rmspecials() function. Please consider updating these filters by wrapping rmspecials() inside rmwhitespace() like this: rmwhitespace(rmspecials(....))

We need you to update the relevant filters within 2 weeks of this notice. If one of the community members with proper access is volunteering to take this on, we ask them to please respond below and notify User:Huji in their response or in the edit summary. If we don't hear back from you within 2 weeks, Huji will edit the relevant filters on your wiki per the global abuse filter maintainer policy, to ensure the filters won't break once the change is implemented. Thank you for your consideration!

Best regards,

--User:Huji (talk) 23:48, 26 October 2020 (UTC), sent via MediaWiki message delivery[reply]

Huji, message acknowledged, I think everything is taken care of on enwiki (I made the requested changes a week or so ago). Thank you for the notification. GeneralNotability (talk) 23:58, 26 October 2020 (UTC)[reply]
@GeneralNotability: Excellent, thanks! huji—TALK 01:35, 27 October 2020 (UTC)[reply]

Draft:Aziz Feyzi Pirinççizâde

While moving this draft to mainspace, an exception is thrown that the title is blacklisted. I am wondering, what is the issue as I am not able to find any log entry for this event. The draft is waiting to be reviewed since 27th of July. Hitro talk 08:21, 27 October 2020 (UTC)[reply]

I moved it using the AFC tool, and saw no error. Graeme Bartlett (talk) 11:19, 27 October 2020 (UTC)[reply]
Admins have the override title blacklist right, so that does not mean anything.--Snaevar (talk) 11:48, 27 October 2020 (UTC)[reply]
An entry says "blacklist test" in the public log (https://en.wikipedia.org/w/index.php?title=Special:Log&page=Draft%3AAziz+Feyzi+Pirin%C3%A7%C3%A7iz%C3%A2de) for the draft page. Maybe @Nathan2055: remember why? Christian75 (talk) 13:30, 27 October 2020 (UTC)[reply]

Need help with Old XfD multi

Way back in 2008 this happened, and then I made it worse when I closed the 2nd AfD. I'm not up on the details of how {{Old XfD multi}} is supposed to work. Could somebody who knows that better please take a look? @Piotrus: -- RoySmith (talk) 14:33, 27 October 2020 (UTC)[reply]

 Fixed * Pppery * it has begun... 14:36, 27 October 2020 (UTC)[reply]

Possible to search for revisions by tags?

I asked this over at the Help Desk a while back with no response. The original question:

I have a possible proposal for WP:VPP, but it depends on being able to search revisions by tags on a page. I've combed through H:SEARCH and WP:AFTAGS but there doesn't seem to be any overlap. Does anyone know if this is possible aside from using something like Ctrl+F?

—Tenryuu 🐲 ( 💬 • 📝 ) 23:53, 27 October 2020 (UTC)[reply]

@Tenryuu: can you explain a little bit more, AFAIK you can't search "revisions" at all - much less with tag filters. — xaosflux Talk 00:11, 28 October 2020 (UTC)[reply]
Xaosflux, ah I see.
I'm looking at the "tag filter" field, which is where I assume revisions can be filtered by tags. I'm not sure how to properly use it, as I tried typing in "visual edit" on a page where one of the revisions was tagged with "visual edit" with no results coming out. —Tenryuu 🐲 ( 💬 • 📝 ) 00:46, 28 October 2020 (UTC)[reply]
If by "on a page" you mean to a specific page, then add tagfilter to the query string: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=history&tagfilter=visualeditor. If you don't mind being restricted to the last 30 days, you can search without restriction to a specific page by adding it to Special:Recentchanges: https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&limit=500&days=30&tagfilter=visualeditor. If you're not looking for a specific page and need older revisions, it can be done, but it's much less straightforward. —Cryptic 00:48, 28 October 2020 (UTC)[reply]
Cryptic, thanks for the info. So it's only possible to search for tags at most in the last 30 days and last 500 edits for a specific page without going down a rabbit hole?
And from what I understand, this doesn't work? —Tenryuu 🐲 ( 💬 • 📝 ) 18:06, 28 October 2020 (UTC)[reply]
Either for a specific page using action=history, or for the last 30 days and last 500 edits through Special:Recentchanges. For non-recent edits not limited to a specific page, you need something like quarry:query/49429.
Where there is a "Tag filter" box in the interface, it should work, but you need to paste in the tag name from the first column of Special:Tags, not what it actually appears as in page histories (which is the second column). —Cryptic 19:00, 28 October 2020 (UTC)[reply]
Facepalm Facepalm. Thanks so much for pointing that out, Cryptic. This will make my workshopping way easier. Thanks for all the help! —Tenryuu 🐲 ( 💬 • 📝 ) 19:23, 28 October 2020 (UTC)[reply]
Would it also be possible to search for two different tags at the same time? E.g., I want to see the revisions on a single page that either used the 2017 wikitext editor or the visual editor, not necessarily together. —Tenryuu 🐲 ( 💬 • 📝 ) 19:32, 28 October 2020 (UTC)[reply]
Well, Recentchanges seems to support that if you separate the tag names with a | [8], but history doesn't [9]. It's easy to build a query to do it, though, once you have a concrete request. —Cryptic 22:33, 28 October 2020 (UTC)[reply]

References as a right hand panel

Several academic journals put the references in a panel on the right which scrolls to the correct one when clicked. Is there a way to do this via a custom style.css or js solution? Examples:

I've previously made v:Template:Sliding_right_TOC that can do something similar for long TOCs (example of use), but has a few limitations:

  • Has to be at the top of the article, so couldn't be used for references
  • Contains an open-ended div for the rest of the page content, which is bad practice generally, and prevent visualeditor from working.

Any ideas for something a bit better coded that would dork for references? T.Shafee(Evo&Evo)talk 01:52, 28 October 2020 (UTC)[reply]

template:Cite wikisource removes all apostrophes

This makes it impossible to link to titles containing apostrophes. For example, {{cite wikisource|Uncle Tom's Cabin}} incorrectly links to s:Uncle Toms Cabin instead of s:Uncle Tom's Cabin. --by Huhu9001 (talk) at 16:50, 28 October 2020 (UTC)[reply]

@Bsherr, Trappist the monk, Jonesey95, Krinkle, and Primefac:. --by Huhu9001 (talk) at 16:52, 28 October 2020 (UTC)[reply]

It probably makes sense to have this discussion at a more relevant talk page. I did a little troubleshooting, and the root of the problem may be in the CS1 modules, so I posted at the talk page for Citation Style 1. – Jonesey95 (talk) 21:44, 28 October 2020 (UTC)[reply]

Edit conflict

I head many editors complaining about losing what they wrote due to edit conflicts.

Friendly advice: use Firefox, both on smartphone and on the computer. It works best, you may even go back in case of edit conflicts and copy/paste what you wrote previously. Tgeorgescu (talk) 17:53, 28 October 2020 (UTC)[reply]

Doesn't the software already alert editors that there was an edit conflict, and temporarily saves the page in a separate text field as if they managed to publish it? Edit conflict "pages" should also allow users to piecemeal their edits with other editors' if they're using the visual editor and/or the 2017 wikitext editor new wikitext mode (beta feature). —Tenryuu 🐲 ( 💬 • 📝 ) 18:00, 28 October 2020 (UTC)[reply]
@Tenryuu: I don't know about that. I only use source text editing. I don't see a button for visual editor. I don't need it, anyway. Tgeorgescu (talk) 18:12, 28 October 2020 (UTC)[reply]
@Tgeorgescu: Whoops, I misspoke. It's a beta feature called "New wikitext mode" that is compatible with two-column edit conflict resolution. Amended my statement above. —Tenryuu 🐲 ( 💬 • 📝 ) 18:18, 28 October 2020 (UTC)[reply]

WebP thumbnail rendering issue in Firefox

I'm having an issue with WebP thumbnails on Firefox. I only just noticed this in the RDNA (microarchitecture) article and haven't done further inspection of any other articles. Screenshot of the issue is included.

I'm using Firefox 82.0 64-bit on Linux Mint 19 Tara. I restarted the browser, tried it in Private Browsing mode, made a new browser profile, and the issue persisted. The problem didn't occur on Chromium.

Anyone else? Linux Mint does their own build of Firefox, so there's a remote chance that this could be build-specific, so I'm asking just in case. Haven't filed a bug report yet, I don't even know what it involves, if there's a separate account registration needed, etc. and don't really have the energy for it right now. --Veikk0.ma 21:02, 28 October 2020 (UTC)[reply]

I can confirm this happens on Windows 10 as well (Firefox 82.0.1) BegbertBiggs (talk) 21:17, 28 October 2020 (UTC)[reply]
Looks fine in 81.0.2 and 82.0.2 here. Try updating Firefox. davidwr/(talk)/(contribs) 21:32, 28 October 2020 (UTC)[reply]
I don't have an issue in 82.0 on W10. --Izno (talk) 22:29, 28 October 2020 (UTC)[reply]
I can repreduce on 81.0.2 and 82.02. Might be an issue on the ESAMS (European) server. Clearing my own cache does not make a difference.--Snaevar (talk) 22:32, 28 October 2020 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=985954311"