Wikipedia:Village pump (technical)

Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can set a gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
For server or network status, please see Wikimedia Metrics.
« Archives, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184


Wikipedia:Troubleshooting#Other problems says to come here.
Browser used: Chrome.
Edit screen: Source (I don't edit with VE).
Problem: The editing toolbar disappears after saving an edit in one article, then trying to edit another article. TW disappears after saving one edit. I have to log out and log back in to edit another article.
This started happening almost three weeks ago. Pyxis Solitary (yak). L not Q. 11:11, 12 September 2020 (UTC)

Pyxis Solitary, I have two links for you. First, try editing in mw:safemode and see whether that helps. Second, go to mw:editor and figure out which one you're using. There are lots of "source" editors. Whatamidoing (WMF) (talk) 21:08, 16 September 2020 (UTC)
@Whatamidoing (WMF): I appreciate your response, but I am not tech savvy. (1) I tested safemode in an article I just edited where the editing toolbar was gone, and with safemode the editing toolbar appeared when I opened the Source edit screen again; (2) I'm using Extension:WikiEditor (VectorEditor) and that's what's selected in my Preferences ('2010 wikitext editor'), which is set to "Remember my last editor" editing mode. As I respond to you, I have no editing toolbar. I think Beta is posing a problem with my browser. I deleted Chrome and downloaded it again -- but the problem continues. P.S. When I click on my Notifications, I don't see them. I get a bar with slanted lines moving to the right. I know you responded to my problem because I received an email. Pyxis Solitary (yak). L not Q. 03:30, 17 September 2020 (UTC)

FWIW, I've switched to using Opera browser for Wikipedia and have not experienced any problem with the editing toolbar and TW. Pyxis Solitary (yak). L not Q. 09:32, 22 September 2020 (UTC)

RedWarn and Off-Wiki WMCS hosting[edit]

Hi all,

We wanted to get some opinion regarding the way that RedWarn currently loads its script content. There had been some controversy over a previous experimental distribution method, which was originally intended to make deploying RedWarn easier, which was removed due to privacy concerns, but over the past few months with RedWarn growing larger and larger, with hundreds of users, we want to expand by completely re-writing the RedWarn tool. This is helped experimentally by the fact that we now have access to Wikimedia Cloud Services, meaning we can implement technologies on WMF hosted servers. We know that this is substantially different to what other user script/gadgets do, but we believe using more modern web technologies can yield a significantly better user experience.

Extended content

Our transition includes using TypeScript, a popular programming language made by Microsoft, which is based on JavaScript. TypeScript compiles down to JavaScript which can be used in a browser as per usual. Along with TypeScript, we'll be using Webpack to bundle up the script. This will allow RedWarn to live in a nicely-packed singular file, but still have its full capabilities. Both of these are open-source technologies which have proved their usability and trust over the years. These will only be used for developing RedWarn and end-users will only be using the compiled JavaScript generated by the TypeScript compiler. The implementation of these technologies is ongoing as we rewrite RedWarn's codebase.

Due to the new code structure, the compiled JavaScript is going to become much more complex and practically unsuitable for human reading, so we need to reconsider how to host RedWarn. Right now, we rely on a manual update of User:Ed6767/redwarn.js based on a combined version of all our JS and HTML files. This method would be fine if it weren't for:

  • a. the amount of mess-ups that can emerge from joining all the JavaScript and HTML files, not to mention how a large script can be detrimental to the performance of MediaWiki, and other user scripts.
  • b. the fact that the MediaWiki parser begins to parse critical parts of RedWarn, adding it to many hidden maintenance categories and causing other issues (such as replacing "~~~~", requiring workarounds). Despite them being implemented, MediaWiki ignores RedWarn's no-wiki tags, likely due to how large the script is.

Our ideal option is to have the userscript load the actual bundled RedWarn script from external Wikimedia provided servers (see Wikimedia Cloud Services). We already have RedWarn's in-development web application hosted on a VPS provided by the WMF a month ago. This new method involves turning the old userscript into a loader for the actual script on the WMCS. Many of RedWarn's external scripts are also already hosted on Toolforge. Here, we can also implement checksums and other security measures to ensure the off-Wiki hosted scripts are legitimate.

Failing this, we can continue the current method, which completely relies on Ed and complex MediaWiki parser workarounds, or having a bot update the code in its own user space, similar to some user-highlighting scripts, which will require the script to be moved to a different user space. With the latter method, the script will be moved to a different user page, and all commits to RedWarn's main branch will automatically update the script based on the latest build.

In addition, as an open source project, the option always stands for users to read through all our code directly.

TLDR: Given that RedWarn now has access to servers controlled by the WMF, would it be problematic to move the code off-Wiki (but still on Wikimedia servers), given that all changes are tracked on RedWarn's GitLab, and considering checksums to verify the legitimacy of the script can be implemented? If so, would it be problematic to use a bot to update the RedWarn script (within its own userspace)?

Signed: Berrely (talk · contribs), Chlod (talk · contribs), Leijurv (talk · contribs), Ed6767 (talk · contribs) and Prompt0259 (talk · contribs) 20:06, 13 September 2020 (UTC)

Unless something has drastically changed - this is still just a personal user script that some other are importing - so it is really buyer beware. If there is plan to move this to a full gadget one day, it would be good to plan ahead now. As far as updates go, there is about 0 chance we would approve a wiki-"bot" as an interface administrator just for this task, and as a personal user script the ownership and accountability for the script belongs clearly to the user that is publishing it. If that user uses some sort of script on their end to update what is their own user subpage, we're not really going to do anythign to stop it. — xaosflux Talk 21:48, 13 September 2020 (UTC)
Xaosflux's usual hostility at user scripts aside, there's no problem with doing anything described here. However, as long as there is one "lead maintainer", I don't see why you guys want to use a separate bot account's userspace to host the script. The lead maintainer can host it in their space and update it from the master branch by running a "deploy" script. But it's understandable if you want to have fully automated CI/CD process.
The nowiki tags aren't working surely because User:Ed6767/redwarn.js contains multiple such tags. Nowiki tags can't be nested. The closing nowiki tag on line 2987 closes the one started on line 22. This can likely be worked around by substituting usages of "nowiki" in the source code itself with something like "no" + "wiki" (assuming webpack doesn't join the strings while minifying). – SD0001 (talk) 08:45, 14 September 2020 (UTC)
@SD0001: I'm actually rather welcoming of user-scripts in general, like I mentioned above the user can pretty much do whatever they want and anyone that doesn't want to use it can just move along. What I am rather unwelcoming to is having to get administrators to maintain personal user scripts that become at all popular and then are abandoned by their owners. — xaosflux Talk 03:10, 15 September 2020 (UTC)
I would have thought that making RedWarn a gadget would have been on the product roadmap. Is this something that the development team has considered and rejected? Best, Barkeep49 (talk) 19:31, 14 September 2020 (UTC)
@Barkeep49, it has been a consideration, especially now I've assembled at team to maintain it. If the community wants it to be a gadget, we won't object. If it was, however, as none of us are interface admins we'd prefer to host off-wiki on WMCS with all the correct security and privacy procedures in place so we can get updates out quicker and without massive edit requests, but hosting on-wiki is possible too. Ed talk! 19:39, 14 September 2020 (UTC)
Ed6767, that makes sense. I don't know all the ins and outs of making it a gadget but I understand that it offers considerable performance advantages over being a userscript. From what xaosflux wrote above it seems like making this change would complicate making this a gadget down the road. Is that correct xaos? Are there other reasons/advantages that the RedWarn team might want to move towards making it a gadget rather than continuing as a user script? Best, Barkeep49 (talk) 19:42, 14 September 2020 (UTC) Fixing ping of xaosflux. Barkeep49 (talk) 19:47, 14 September 2020 (UTC)
@Barkeep49, being a gadget would be preferable in terms of user friendliness as installing would be as easy as checking a box in preferences, so there'd be no need to dig into code files, which many may not prefer to do. Other than that, userscripts and gadgets are very similar in a technical nature, in terms of they both add code to Wikipedia that can be run in your browser. Now we've discussed internally, going forward, we'd prefer to make RedWarn a gadget, but that will require consensus. So, while we're on topic, would it be worthwhile to open an RfC regarding making RedWarn a gadget below? Ed talk! 20:04, 14 September 2020 (UTC)
I'm the wrong person to ask that question as all I know is just how much I don't know about the topic. Best,Barkeep49 (talk) 01:52, 15 September 2020 (UTC)
As far as turning a script in to a gadget goes, that is where most of the gadgets come from. Gadgets normally get extra scrutiny and all code changes on-wiki would need to be reviewed by interface administrators - which means there may certainly be reluctance to import instructions from off-wiki that would bypass the code-review and version-fixing components. — xaosflux Talk 03:13, 15 September 2020 (UTC)
This may be off-topic, but in terms of a blacklist for user scripts, I think something like this would do well as part of m:Partial blocks and blocking in general. There should be an option in block settings that blocks REST POST API calls only while allowing editing through the regular edit form. This would effectively disable gadgets like Twinkle and programs like Huggle while allowing the user to make constructive edits elsewhere. Aasim 04:09, 15 September 2020 (UTC)
@Awesome Aasim: I fail to find what exactly about what you said is related to RedWarn's deployment options. I suggest that you make a new section and provide the relevant context there. Chlod (say hi!) 04:20, 15 September 2020 (UTC)
I think you're trying to use the user script & gadget infrastructure in a non-idiomatic way. The existing process/expertise around scripts isn't geared to handle modern frontend practices. Years and years from now, any user script or gadget will someday be edited by a interface administrator in exclusively JavaScript form, so any nontrivial build process will complicate that. (I doubt the TS compiler outputs very nice JS, and minification will of course produce write-only code. Minification will also necessitate more extra sanitization steps to get the result past the MediaWiki parser.) As an example, all Popups did for a "build process" was concatenate a bunch of pure-JS files, and modifying it was painful enough.
I would instead recommend RedWarn be converted to a standalone tool running on Toolforge, just like Snuggle. On Toolforge, you can use any frontend technologies and not bother with any bot/deploy script stuff. From using RedWarn, it looks like the only big new thing that would need adding is a custom diff viewer, which isn't that bad since diffs already come from the API in HTML form. Users could unfortunately no longer use all their other user scripts that work on diff pages, but RedWarn could just link to the normal on-wiki diff page from the custom diff view. Yes, this would also bypass the gadget process, but I'm fine with that. This isn't really a gadget anyway, if you compare it with the rest of Preferences → Gadgets. Pinging Joeytje50, the WP:JWB developer, who probably knows all about user scripts that "take over" the browser window. Enterprisey (talk!) 09:20, 19 September 2020 (UTC)


there is an issue with the mobile website archives for WP:AN and WP: ANI, you cant access them unless you know the link to them. you cant search them on the search bar as well, so I am thinking that this should be added:

WP:ANI/Archive as an example, but can be used for other noticeboards. this way, it is more accessible to mobile users, or users who prefer the mobile website than the desktop website. What do you guys think? New3400 (talk) 18:24, 15 September 2020 (UTC)

This actually pertains to the same problem discussed in #Mobile site stripping page elements below. Perhaps Module:Administrators' noticeboard archives shouldn't be using the navbox class. Nardog (talk) 07:49, 18 September 2020 (UTC)

thanks for agreeing, Nardog. i feel that this can help moblie editors. New3400 (talk) 17:32, 21 September 2020 (UTC)

WP:GA and WP:PR toolbox template link problems[edit]

Hi all, the two templates {{Peer review tools}} and {{Good article tools}} used in WP:GA and WP:PR seem to contain dead links. It seems like this is due to a problem on toolserver, maybe because the tools have moved URL? I was hoping a technical boffin around here who is in-the-know may be able to help out by correcting the links. Many thanks! --Tom (LT) (talk) 11:29, 17 September 2020 (UTC)

Which links in particular? (To wit, I've tried to remove the ones I know of that have caused issues previously.) --Izno (talk) 16:36, 17 September 2020 (UTC)
@Izno All of them. To me at least, they all redirect to 404 pages. --Tom (LT) (talk) 23:20, 18 September 2020 (UTC)
Ping. Still a problem that seems to be apparent for all peer reviews and good reviews. --Tom (LT) (talk) 04:07, 23 September 2020 (UTC)
You will need (apparently) to achieve consensus to remove the links or get in contact with the Toolserver project owner. --Izno (talk) 17:27, 23 September 2020 (UTC)
Toolserver has been down, permanently, since mid 2014. There's plenty on that matter in the archives of this page. I'm surprised it's taken six years for these links to be noticed as being dead. FWIW the "Toolserver project owner" was Wikimedia Deutschland. --Redrose64 🌹 (talk) 22:21, 23 September 2020 (UTC)
... I should have said Toolforge, the links to which do function in normal cases. --Izno (talk) 23:19, 23 September 2020 (UTC)
Great. I don't see the use in revitalising these links if noone has actually even tried to use them in the last 5 years - they clearly aren't seen as useful. I've commented out the links in both templates and, as I'm active at peer review, have also boldly added a link to Earwig's. --Tom (LT) (talk) 04:10, 24 September 2020 (UTC)

Inexplicable tag[edit]

Does anybody know why this edit has the tag "Reverted"? It's not a revert. --Redrose64 🌹 (talk) 18:26, 18 September 2020 (UTC)

I am uncertain whether reverted refers to the edit in question reverting an earlier revision or if it refers to a future revision reverting the so-tagged edit. I am fairly certain it is the latter given this also is so-tagged. Tags can be assigned to arbitrary revisions, it's just that there are very few things that do so. --Izno (talk) 18:45, 18 September 2020 (UTC)
It means that the edit was later reverted (in this case, in the next edit). I don't recall seeing that tag until a day or two ago; maybe it's a new feature that could have been named a little better. [Edited to add: It looks like this new feature was in the works for a while and was released in August or September. See T164307 and related tasks. I sure wish the WMF developers would fix some of the pesky bugs I'm following before introducing shiny new features, but I'm just a volunteer (and a donor...).] – Jonesey95 (talk) 19:18, 18 September 2020 (UTC)
Yes, "this edit has been reverted" fits the bill - there certainly seem to be a lot of them at the moment, and yesterday was Thursday. --Redrose64 🌹 (talk) 20:17, 18 September 2020 (UTC)
As it happens these recent changes for reverted edit taggings are by volunteer/non-WMF/WMDE developers for Google Summer of Code. --Izno (talk) 21:05, 18 September 2020 (UTC)
I noticed it, too, and appreciate it. The single word seems clear to me, though shouldn't it be linked like some other tags? —[AlanM1 (talk)]— 06:07, 19 September 2020 (UTC)
It's a new feature, see mw:Manual:Reverts#Reverted_tag. Added by Ostrzyciel as part of GSoC 2020. – SD0001 (talk) 09:19, 19 September 2020 (UTC)

Adding dashes in columns[edit]

Hi, on my list User:Encyclopædius/Language learning centre/German word list. Can somebody tell me how to add a dash between words using the advanced search feature? Also how to add a # at the start of every line (for future entries)? Isn't there some sort of * thing you type in the expression box?† Encyclopædius 12:16, 19 September 2020 (UTC)

You seem to be having tab characters between the words. Also sometimes these tab characters appear at the end of the line as well. So well I ended up fixing it myself. Here's what I used:
  • \s*$ replaced with nothingness (this removes any spaces/tabs at the end of the lines)
  • \t replaced with - (this converts tabs, which are now only there b/w words, to dashes)
The "Treat search string as a regular expression" option should be checked always.
To add # at the starts, you'd do search for ^ and replace with #.
You may find this cheatsheet useful if you want to learn regex. – SD0001 (talk) 12:44, 19 September 2020 (UTC)

Thanks, appreciate it! † Encyclopædius 13:12, 19 September 2020 (UTC)

One last thing, is there an alphabetical order option? I've been using an external site but ideally I want letters with accents to be classified as a regular letter, ü for example as u. No worries if not.† Encyclopædius 13:22, 19 September 2020 (UTC)

A better # insertion regex might be
Search for: ([\r\n])([^#\{=\r\n]) – find a newline followed by anything but #, {, =, or another newline
Replace with: $1#$2 – the found newline followed by a new # followed by the character that wasn't in the search exclusion set
For hyphen replacement:
Search for: [\t ]+\-[\t ]+ – find a hyphen between one or more whitespace characters; done this way so that the newline pair (\n\r) aren't included in the match
Replace with:  – <space><ndash><space>
No alphabetizing option. You could write a lua module that would do the sorting, insert #, and replace hyphen with ndash all in on go with the data for the German word list kept in a separate data module – you would edit the data module to add new terms and the list would magically appear at User:Encyclopædius/Language learning centre/German word list properly ordered and separated.
Trappist the monk (talk) 13:34, 19 September 2020 (UTC)

Thanks Trappist. † Encyclopædius 14:43, 19 September 2020 (UTC)

Just added some to User:Encyclopædius/Language learning centre/Dutch word list, I managed to add the # and the dash between words but the command ended up also adding a dash at the end of the lines. How do I remove those dashes at the end and alter the command so it only adds a dash between the words and not on the end too? \t added two dashes, I only want one between words.† Encyclopædius 10:07, 20 September 2020 (UTC)

Where the line ends with a tab character find: \t matches and so replaces it with the hyphen. Find: [\t ]+([\r\n]+) Replace: $1 will remove tabs and spaces at the end of lines. Do this first.
Trappist the monk (talk) 13:01, 20 September 2020 (UTC)

Didn't work unfortunately.† Encyclopædius 16:52, 20 September 2020 (UTC)

What do you mean didn't work? I just tried it and it removed trailing tab and space characters from the ends of lines where they exist just as I said it would. When creating a new list, removing trailing tabs and spaces must be done before you insert dashes or you end up with trailing dashes. If you were expecting the regex that I suggested to also remove the trailing hyphen characters, I never said it would. But, it can be adapted to do that: [\t \-]+([\r\n]+). But, that version will also remove dashes that are 'between' a Dutch word and its non-existent English counterpart.
Trappist the monk (talk) 13:29, 21 September 2020 (UTC)

I had an error occur because of a gap, fixed it now, so works! Thankyou Trappist!!† Encyclopædius 12:03, 22 September 2020 (UTC)

Images with transparent backgrounds?[edit]

I have a PNG of an organization's logo. It's white on a transparent background. Is there a way to include this as the "image" parameter in a {{infobox organization}} but force it to be displayed on a dark background? If it matters, it's WP:NFC. -- RoySmith (talk) 13:47, 19 September 2020 (UTC)

@RoySmith: The way a transparent PNG works is that the image embeds in itself a particular color so that every pixel with that color becomes transparent. What's the image? What software do you use to save or edit the image? Nardog (talk) 14:46, 19 September 2020 (UTC)
Nardog, The image is I know I can manipulate the image in a photo editor to turn the background any color I want. What I'm trying to figure out is if there's a way to get the infobox template to do that, without any manual image manipulation. -- RoySmith (talk) 14:51, 19 September 2020 (UTC)
I think in the past I have wrapped such logos in div tags: <div style="background-color:black;">logo.png</div> — Diannaa (talk) 14:57, 19 September 2020 (UTC)
There's a full-color white-background version of that logo here. Nardog (talk) 15:06, 19 September 2020 (UTC)
Nardog, Ah, cool, that's even better :-) -- RoySmith (talk) 15:10, 19 September 2020 (UTC)

Page views by Georgraphy[edit]

Hello all:

I was hoping to do an analysis, and was looking for geographical page view data -- is there some place where I can get it?

E.g. This link [1] or this one [2] has the page view data for an article / page. Is there some place where I can get the next level breakdown by geography as well?

Thanks, Ktin (talk) 00:13, 20 September 2020 (UTC)

New gadget proposal: view short descriptions in categories[edit]

Hi all. I would like to propose user:SD0001/shortdescs-in-category (source) be made a gadget. With more than 2 million articles now having local short descriptions and countless more having them on Wikidata, shortdescs have become a great way to identify articles one may be interested in. Being able to see these descriptions while browsing categories marries together these two ways of organising and classifying content (short descriptions and categories). I have found this really helpful while working through maintenance categories (eg. CAT:NN or Category:Indian poet stubs) and trying to find articles I want to work on.

This script only has about 13 users at the moment because it is very new. The existing users are largely people working on adding shortdescs. I think it will be useful to a lot more people than the ones who're using it currently, and gadgets are a lot more easily discoverable than userscripts, hence this proposal.

It is stable and works across all browsers and skins. – SD0001 (talk) 05:04, 20 September 2020 (UTC)

Support I have just installed this and like it a lot. It greatly enhances category displays by providing annotation. Thank you for writing the script. It could possibly be bundled with the shortdesc helper gadget. Thincat (talk) 16:40, 20 September 2020 (UTC)

I can't see radio buttons for diffs in Firefox[edit]

I am no longer able to see the radio buttons for diffs in the page history. I can view a diff if it's in my contributions, but the radio buttons have disappeared. My browser is Firefox 80.0.1, but it works in Chrome and Safari. Does anyone know the cause of this problem? —Naddruf (talk ~ contribs) 19:10, 20 September 2020 (UTC)

@Naddruf: I'm on Firefox 80.0.1, and I can still see radio buttons in the page history. Two things to try:
  1. Try Wikipedia's safe mode, by adding the query string parameter `safemode=1` to the URL (e.g., )
  2. Try Firefox's safe mode, by following the instructions at
Jackmcbarn (talk) 19:15, 20 September 2020 (UTC)
Also try logging out to see if the appearance changes. If it does, something in your settings or js/css files may be causing the buttons to disappear. – Jonesey95 (talk) 19:37, 20 September 2020 (UTC)

Edit summary boxes[edit]

Sometimes I am getting two edit summary boxes. Anyone know what is going on? Hawkeye7 (discuss) 03:48, 21 September 2020 (UTC)

Using GitLab for code review[edit]

As was recently mentioned in Tech News, the foundation is currently holding a consultation about moving development from Gerrit, the current code and patch review system, to GitLab (for reasons, other systems are not being considered). I'm in the working group steering this consultation and we are also very interested in the opinions of those outside the core development team. Bot writers, gadget developers etc. Do you have concerns or enthusiasm about gitlab ? Do you think you might contribute more or less or even if it might be easier for you to be informed with Gitlab instead of gerrit ? What do you think about the gerrit patch review system vs the gitlab pull request system ? Please take a minute to think about it and maybe leave some comments at or if you really prefer to do so, leave them here and I will later summarise them there. —TheDJ (talkcontribs) 07:44, 21 September 2020 (UTC)

GitLab is a million times better than Gerrit. ProcrastinatingReader (talk) 13:20, 21 September 2020 (UTC)

Requesting help[edit]


I have created following two RfCs at

Above RfC's (neutral part) need to be correctly visible in Wikipedia:Requests for comment/Religion and philosophy and other two project pages. While other users are saying some thing I am not getting technical aspects of the same and I am looking for proactive support in sorting out the issue.

I hope and request some one help me out.

Thanks. Bookku (talk) 10:35, 21 September 2020 (UTC)

I already explained this. The RfC statement needs to abide by WP:RFCST and WP:RFCBRIEF. The RfC statement is everything from the {{rfc}} tag (exclusive) to the next valid timestamp (inclusive). In both of those RfCs, what you have in the statements is neither neutral nor brief. --Redrose64 🌹 (talk) 13:09, 21 September 2020 (UTC)
Sorry, no take personal, You explain, I no understand. I need help from some one else, who can understand what you say and do correct things without wasting time in lecturing. So let others help, I write here to seek help from others not you, because you lecture without practical helpness.
Bookku (talk) 18:19, 21 September 2020 (UTC)
@Bookku: Nardog made a fix with these three edits, which had this effect on the RfC listings. --Redrose64 🌹 (talk) 21:35, 21 September 2020 (UTC)

Birthday boy[edit]

In the infobox for Joe Wicks (coach) there is a line of coding which reads

{{Birth date and age|1985|09|21|df=y}}

This generates his age as "34" but I would have thought it should be "35". After playing round with the coding I managed to get it to generate "35" but it's gone back to "34". If I enter his birthday as 20 September it gives age 35, so why does it fail to recognise his 35th birthday? The current age can also be generated using

{{birth date and age|1985|09|21}}

This generates age 35 in preview. According to [3] Joe was born in 1986 so the article age is correct, and the dab page also says "1986". In 2016 the article had 1985 in the lead and 1986 in the body. In 2018 the lead still said 1985 and this was the only reference. On 22 August 2019 someone changed "Category:1986 births" to "Category:1985 births". On 11 March 2020 the birth year was corrected to 1986. This year was shown when the infobox was added. On 23 June someone changed the birth year to 1985 in both places. I haven't edited the errors out because the issue of how an infobox can give an age of 34 when "21 September 1985" is coded remains unresolved. (talk) 11:59, 21 September 2020 (UTC)

The Companies House data gives 1985 so I would be inclined to leave things as they are (provided we can get the article to show his age as 35 rather than 34). (talk) 12:08, 21 September 2020 (UTC)

I just purged the page and now it says 35. Nardog (talk) 12:14, 21 September 2020 (UTC)
Thanks. (talk) 12:19, 21 September 2020 (UTC)

Module talk with strange errors[edit]

Can someone take a look at Module talk:Sandbox/Zyxw/test and see why it's generating "internal error" when one tries to even look at it? It's currently in Category:Pages using Timeline which is being renamed to Category:Pages using the EasyTimeline extension and it's not clear if this one is a cache delay or needs adjustment to be moved over. Timrollpickering (talk) 20:14, 21 September 2020 (UTC)

This line is the culprit:
self:preprocess_equals('<templatedata />', '', {nowiki=1})
It looks like <templatedata /> cannot be preprocessed. This reproduces the error:
local p = {}

function p.run_tests(frame)
	return frame:preprocess('<templatedata />')

return p
Nardog (talk) 21:11, 21 September 2020 (UTC)
I commented out the line causing the error and now the page is no longer in that category. -- Zyxw (talk) 22:57, 21 September 2020 (UTC)
I filed phab:T263605 for the general bug, even though the specific case is resolved. * Pppery * it has begun... 00:58, 23 September 2020 (UTC)

Tech News: 2020-39[edit]

21:26, 21 September 2020 (UTC)

Finding a new maintainer for OneClickArchiver[edit]

It has been 5 years since OneClickArchiver had a permanent maintainer since the previous maintainer was banned. Since OneClickArchiver is still a widely used tool, somebody needs to take up the post as maintainer for OneClickArchiver. Goose(Talk!) —Preceding undated comment added 03:37, 22 September 2020 (UTC)

Agreed. HeartGlow (talk) 03:39, 22 September 2020 (UTC)
Wikipedia:One click archiving is displayed prominently on the tool page, what's wrong with User:Evad37/OneClickArchiver or User:Σ/Testing facility/Archiver? ~ Amory (utc) 10:09, 22 September 2020 (UTC)
  • A great improvement to one-click archiver would be...a multi-click archiver? So people's watchlist don't get flooded by someone clicking 50 threads one-at-a-time... –xenotalk 11:29, 22 September 2020‎ (UTC)
    xeno, Sigma's linked above does so. It just doesn't respect bot settings like I'd prefer, so you need to enter the preferred archive page name manually. Yes, I've asked for support and was rejected. --Izno (talk) 14:40, 22 September 2020 (UTC)

Escaping a pipe character in system messages[edit]

Please can anyone advise on this issue. User:Awesome Aasim has requested that some system messages using {{fmbox}} are hardcoded as tables (like this) to avoid it breaking when a pipe character occurs. Hopefully he/she will be along to explain this better than I can. Is there any way that fmbox can be used successfully in these cases? — Martin (MSGJ · talk) 08:04, 22 September 2020 (UTC)

First, where is that breakage occurring, and how is it manifested? Second, this is sematically an improper use of a table element. --Redrose64 🌹 (talk) 08:32, 22 September 2020 (UTC)
The main issue is with the parameter $1 in system messages for the title blacklist. This is the parameter that is responsible for providing the regex that was tripped in the local or global blacklist. Because it can be frustrating for good-faith editors to know which filter tripped when they were creating a filter, this is more of a diagnostic that I suggested only be visible to extended-confirmed users. Unfortunately, because the regex sometimes includes a pipe character | it breaks many templates. I do not know if there is a way where this character can be accommodated without breaking any additional templates. If anyone more technical than me in MediaWiki knows, feel free to reply to this message.
(On a side note, this issue can easily be fixed if MediaWiki sent {{!}} instead to the parameter $1. This could maybe fixed in a bug request on Phabricator.) Aasim (talk) 08:39, 22 September 2020 (UTC)
$1 is not a regular template parameter, like {{{1}}}. Can this be solved by wrapping it in <nowiki>...</nowiki>? —⁠andrybak (talk) 10:11, 22 September 2020 (UTC)

Collapsible wikitable not working[edit]

The collapsible wikitables on the article GOMS#CMN-GOMS (versioned link) don't seem to be working (i.e. not closable), neither on Firefox (79.0) nor on Chromium (84.0.4147.89). Is there anything that can be done about it? --Jaquento (talk) 12:53, 22 September 2020 (UTC)

It's because each table has only one row. You need at least two rows, because the top row cannot be collapsed otherwise the "[show]" link would have nowhere to be visible in. --Redrose64 🌹 (talk) 13:09, 22 September 2020 (UTC)
I see! Then it might be best to remove the "collapsible" class inside the wikitext. Thanks! --Jaquento (talk) 13:40, 22 September 2020 (UTC)
No, it'd be best to mark up that content correctly, as it is in no way a table. It looks like some sort of <code> to me, but try some flavor of Template:Syntaxhighlight, for example. — JohnFromPinckney (talk) 19:01, 22 September 2020 (UTC)

Invisible Pictures[edit]

Forgive me if this isn't the place to ask. I've noticed this several times. On pages like this one [7] if you click on a picture then follow the arrows to the right you will come to this picture [8] It's a nice enough picture but you can't see it when viewing the page and I didn't find it in the page edit. It has nothing to do with La Porte - it's from Kemah, a town about 10 miles south of La Porte. Why is it there and how do I find it on the page? Wiki name (talk) 13:34, 22 September 2020 (UTC)

It's in Template:Galveston Bay Area at the bottom. Nardog (talk) 13:37, 22 September 2020 (UTC)
Thanks. Who defines which towns are in the Bay Area. Webster is about 7 miles from Galveston bay. Wiki name (talk) 13:57, 22 September 2020 (UTC)
Someone should probably add the 'noviewer' class to the navbox images. —TheDJ (talkcontribs) 14:27, 22 September 2020 (UTC)
Here's a fix for {{Galveston Bay Area}}. However, this doesn't take care of plain wikitext images, like Texas flag in {{Houston-Sugar Land-Baytown MSA}} (example from the same page, La Porte, Texas). Should the whole navbox have CSS class "noviewer" to remove all decorative images from Media Viewer? —⁠andrybak (talk) 14:45, 22 September 2020 (UTC)
That seems reasonable to me in the general case, but I would guess there are some misuses of navbox out there which would cause an image to be hidden from the viewer. (I don't think that's worth spending time on.) --Izno (talk) 15:17, 22 September 2020 (UTC)
+1 for this fix. I've certainly been frustrated by images in navboxes, mboxes, flagicons, etc. showing up in the Media Viewer. If there are "misuses", then they're what need to be fixed on sight. Nardog (talk) 16:42, 22 September 2020 (UTC)
I've created an edit request: Template talk:Navbox § Template-protected edit request on 22 September 2020. —⁠andrybak (talk) 16:45, 22 September 2020 (UTC)
And done (with no prejudice to reversion in case of a sizeable opposition or better solution). Nardog (talk) 17:09, 22 September 2020 (UTC)

Translatable modules proposal[edit]


There's a new proposal to localize Lua modules in a more modern, safe, and convenient manner: mw:Translatable modules. In the foreseeable future it will only affect multilingual sites, such as Wikidata, Commons, Meta, and, but at a later time it may also be deployed on Wikipedias and other projects.

It will be great if experienced module developers could take a look at the project page, mw:Translatable modules, and its subpages, especially mw:Translatable modules/Proposed solutions.

Thanks! --Amir E. Aharoni (WMF) (talk) 14:31, 22 September 2020 (UTC)

Self edit conflict[edit]

I'm having frequent edit conflicts with myself. This has plagued me previously and then mysteriously resolved itself. It is back. I asked for help previously and found that I'm not the only one with this issue and on one has a cure or workaround. My only recourse is to resolve the edit conflict by copying and pasting the entire article text. One previous suggestion was to reset my account preferences to defaults. I've done this and the problem persists. ~Kvng (talk) 14:39, 22 September 2020 (UTC)

Please check what happens by using the following procedure to publish/save edits after previewing them: in the edit summary box, write a message then press Enter. That will save the edit (assuming you haven't done anything to disable the default behavior). The aim is to determine whether that gives a different result from using a mouse to click Publish changes. Johnuniq (talk) 23:35, 22 September 2020 (UTC)
@Kvng: (1) Are you using WP:wikEd (would be enabled under Special:Preferences#mw-prefsection-gadgets)? (2) If not, are you double-clicking the "publish" button? (3) If not, do you perhaps have an failing pointing device that's sending spurious double clicks? Suffusion of Yellow (talk) 23:40, 22 September 2020 (UTC)
I have wikEd enabled in preferences but I leave it disabled except temporarily when I need one of its features. I have definitely gotten these edit conflicts with wikEd disabled. I am definitely not double-clicking the "publish" button and if I had a pointing device issue I'm sure I would have noticed it on other applications. To publish edits I use Enter in the summary box or the Shift-Alt-S shortcut. I may occasionally use the mouse. I will see if I can make any connections between save method and edit conflicts. ~Kvng (talk) 16:00, 23 September 2020 (UTC)

Edit conflicts with yourself?[edit]

Do edit conflicts only get detected between different users? I've been trying to force edit conflicts (so I could test some aspects of how they behave) and was surprised to discover I couldn't generate one by editing User:RoySmith/sandbox logged in as myself in two different windows. If I opened an incognito window and logged in as RoySmith-testing, I could then easily generate conflicts. -- RoySmith (talk) 23:49, 22 September 2020 (UTC)

In theory, it should be impossible to conflict with yourself. The later edit will just save, with no attempt at a three-way merge. In practice, it can sometimes happen, as the above section shows. My guess is it only happens when the edits are submitted a fraction of second apart, but I don't really know. Suffusion of Yellow (talk) 23:51, 22 September 2020 (UTC)
On second thought, it looks like a self-conflict can happen during a section edit. From EditPage.php:
             // An edit conflict is detected if the current revision is different from the
             // revision that was current when editing was initiated on the client.
             // This is checked based on the timestamp and revision ID.
             // TODO: the timestamp based check can probably go away now.
             if ( ( $this->edittime !== null && $this->edittime != $timestamp )
                 || ( $this->editRevId !== null && $this->editRevId != $latest )
             ) {
                 $this->isConflict = true;
                 if ( $this->section == 'new' ) {
                     if ( $this->page->getUserText() == $user->getName() &&
                         $this->page->getComment() == $this->newSectionSummary()
                     ) {
                         // Probably a duplicate submission of a new comment.
                         // This can happen when CDN resends a request after
                         // a timeout but the first one actually went through.
                         wfDebug( __METHOD__
                             . ": duplicate new section submission; trigger edit conflict!" );
                     } else {
                         // New comment; suppress conflict.
                         $this->isConflict = false;
                         wfDebug( __METHOD__ . ": conflict suppressed; new section" );
                 } elseif ( $this->section == ''
                     && $this->edittime
                     && $this->revisionStore->userWasLastToEdit(
                         wfGetDB( DB_MASTER ),
                 ) {
                     # Suppress edit conflict with self, except for section edits where merging is required.
                     wfDebug( __METHOD__ . ": Suppressing edit conflict, same user." );
                     $this->isConflict = false;
Suffusion of Yellow (talk) 00:01, 23 September 2020 (UTC)
Suffusion of Yellow, Interesting, thanks. But, to take a step back, what I'm really trying to figure out is what happened with this edit. I edit-conflicted with Graywalls, thought I had properly resolved it using the Visual Editor's EC-resolution tool, but what ended up happening was deleting the white space between paragraphs, which ran them together. See this perma-linked version.
I've been trying to figure out what happened, but I've been unable to reproduce that behavior. I can now get edit conflicts (by using two accounts), but I still can't reproduce the whitespace removal. -- RoySmith (talk) 00:17, 23 September 2020 (UTC)
My situation (above) is very simple. I edit and I get an edit conflict. I see no other adjacent activity from anyone else in history. I will try to determine whether this only occurs on section edits. ~Kvng (talk) 15:08, 23 September 2020 (UTC)
I'm getting edit conflicts with self on non-section (whole article) edits. ~Kvng (talk) 16:02, 23 September 2020 (UTC)

Is there a script that highlights or corrects redirects?[edit]

Hi all, I've been editing navboxes recently and quite a few terms link to redirect pages. I was wondering if there is a script that could highlight these or fix them for me? This would be particularly useful because often due to moves and mergers terms used may be out of date, or worse there may be several terms linking to the same page, and I'd like an easy way to work out which ones I need to focus on. Does anyone know if there is such a script already? Cheers --Tom (LT) (talk) 04:21, 23 September 2020 (UTC)

For highlighting, see User:Anomie/linkclassifier. Headbomb {t · c · p · b} 04:43, 23 September 2020 (UTC)
Helpful! Thanks. --Tom (LT) (talk) 06:40, 23 September 2020 (UTC)
@Tom (LT): Something a little less heavy for highlighting/require less setup would be similar to what I have in User:Izno/common.css (.iznoredirects is for temporary addition to a long table or page that could use some redirect resolution, so you can ignore that line if you prefer). --Izno (talk) 17:23, 23 September 2020 (UTC)

How does notifications ignore work?[edit]

In the Notification section of my Preferences, I've added The Only Way Is Essex (series 26) to the "Muted pages for page link notifications" (I created it as a redirect, and now that it's an article, I was getting notifications about it). But I just received a notification that the page was tagged with link rot- this shouldn't have happened. Does the muted pages take some time to work? I only added this page to the muted pages about 4 hours beforehand. Or is it a bug? Joseph2302 (talk) 12:33, 23 September 2020 (UTC)

Get ready for horizontal scrollbars with Wikipedia's "New Look"[edit]

The Wikipedia "New Look" is coming: Wikimedia Blog: "New Look".

There are some nice features, like collapsible left sidebar. Then, there's the fixed-width content window, leading to horizontal scrollbars at browser widths less than the one they specify. "New Look" is currently active at French Wikipedia. Also at fr-wikt, eu-wiki, fa-wiki, he-wiki, pt-wiki. Mathglot (talk) 22:51, 23 September 2020 (UTC)

I hate to be grumpy and rude (no, really!), but it is clear to me that none of the people who worked on these "Desktop Improvements" has professional experience with UIs or usability. Looking at the Collapsible sidebar animation I see the sidebar disappearing and reappearing, with no reuse of the real estate it occupied. What good is that? According to that blog post, it's supposed to "improve usability and focus by allowing people to concentrate on the content itself"; I'd concentrate better without all that wasted space in my windows, which, in the collapsed case, is of absolutely no use to me at all.
The maximum line width "feature" appears to be similarly disrespectful of the user's needs, by forcing (what will probably appear to be arbitrary) wastages of space. I thought fixed-width design went out 10 years ago. Or was that only among clued professionals? Grumble, grumple, harrumpf, get off my lawn you consarned kids... — JohnFromPinckney (talk) 00:10, 24 September 2020 (UTC)
There's a professional UX designer and a UX engineer on the team working on this. I suspect they do, in fact, have professional experience with UIs/usability. Anyway, no projects except the volunteering early-adopter wikis are getting this before next year, per the FAQ. --Yair rand (talk) 00:57, 24 September 2020 (UTC)
Maximum line widths continue to be part of current web layout design (people still have trouble tracking text beyond a certain line length). Responsive web design will use techniques to rearrange page components appropriately as the screen size changes. (I haven't looked at the prototype changes, so have no comments on whether or not the design is responsive.) isaacl (talk) 02:27, 24 September 2020 (UTC)

This VPT section was intended more as just a notification of something going on at mediawiki. If you have comments that you would like people involved with the project to see or respond to, the project discussion page is here: mw:Talk:Reading/Web/Desktop Improvements. Mathglot (talk) 04:12, 24 September 2020 (UTC)

Randomising names in a list[edit]

G'day all, I have a situation where there is disagreement about what order some names should go in the infobox of an article about a war. Reliable sources are not very helpful in determining an order of importance and of course there are different factors to consider where one leader may be more important in one respect, and another leader more important in a different respect. My question is, is there a way of formatting a plain list within a field in an infobox that would present the names in a random order each time it was viewed? Thanks, Peacemaker67 (click to talk to me) 03:08, 24 September 2020 (UTC)

Sure can!
  • sausage
  • spam
  • egg
See Module:Random for more tricks. Hawkeye7 (discuss) 03:31, 24 September 2020 (UTC)
Thanks Hawkeye, I shouldn't be surprised that you would know how to do it. Peacemaker67 (click to talk to me) 03:46, 24 September 2020 (UTC)

Interesting idea, and it begs the question about unconscious ordering bias in lists. There probably is an attention bias towards the first and last entries in a list. It is a testable hypothesis. And feuds over pecking order show there is a supposed bias editors are trying to leverage. A is better than C better than F .. unless F is the anti-hero. And so on, it's ingrained in mental maps. Could see it being used for things like award shortlists. -- GreenC 03:38, 24 September 2020 (UTC)

Thanks, yes it is an issue in some situations, GreenC. In this case there is considerable systemic bias involved IMHO, as well as feuding sides... Peacemaker67 (click to talk to me) 03:46, 24 September 2020 (UTC)

The names could be randomized, as is done with the arbitration committee elections, for example. But I think it is a bad idea to have randomly changing lists in articles. I think it would be better to find some neutral order, like alphabetical. isaacl (talk) 03:40, 24 September 2020 (UTC)

The problem with alphabetical is that reverse alphabetical is often the response, and both benefit one side or another in a dispute. Peacemaker67 (click to talk to me) 03:46, 24 September 2020 (UTC)
The guidance from the manual of style is the "most basic form of organization is alphabetical or numerical". There isn't really a good argument for reverse alphabetical in an encyclopedia article. isaacl (talk) 04:06, 24 September 2020 (UTC)
OK, I see you're talking about the leaders of World War II... The country names really should be listed, not just flags, and maybe some numeric criterion (as I see has been suggested on the talk page) based on the countries could be agreed upon. isaacl (talk) 04:18, 24 September 2020 (UTC)
Correct, but the issue is that consensus on a metric doesn't seem likely. All sorts of factors are in play. Peacemaker67 (click to talk to me) 04:31, 24 September 2020 (UTC)
Status quo can stay in place, then, until enough editors agree on something. These are really short lists; it doesn't make much practical difference. isaacl (talk) 04:34, 24 September 2020 (UTC)
It's bad for the website caching to need to deal with a random order. Please generally avoid that in live articles. --Izno (talk) 04:12, 24 September 2020 (UTC)
What practical effect is there? Peacemaker67 (click to talk to me) 04:17, 24 September 2020 (UTC)
Because of caching, the order remains the same until the page is edited or purged. Caching takes precedence over randomisation, so randomisation in articles shouldn't have an adverse effect on Wikipedia's performance. — Mr. Stradivarius ♪ talk ♪ 12:16, 24 September 2020 (UTC)
<Queue people making small edits until the cache contains their preferred version.>
I think randomizing lists in a live article is not a good idea. Two people accessing the same revision of an article should see the same content, in the same order. –xenotalk 12:20, 24 September 2020 (UTC)
I agree. Don't see anything wrong with alphabetical, this strikes me as a solution in search of a problem. Nardog (talk) 14:05, 24 September 2020 (UTC)
For articles, don't think this should be attempted - the presentation order of content is a purely editorial matter and this sort of structure will make it harder for editors to manage the content - especially when using visual editor and expecting a WYSIWYG result. — xaosflux Talk 14:37, 24 September 2020 (UTC)