This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Nothing gets sent if I type in my registered email address to reset my password
Hi, this is User:My name is not dave here. Despite still having Wikipedia related emails in my email folder for my registered email address, I still get nothing when I try to send a password reset email. I recently had a few problems with Google storing and retrieving my passwords, so I reset the whole thing. Now I'm locked out of my account because the damn password reset thing doesn't send an email to my registered email address. Any solutions to this, or do I need to grit my teeth in a sense? 143.167.200.66 (talk) 14:22, 10 December 2019 (UTC)
Hi My name, a few things you can try. First check if your email provider has any sort of spam/junk filtering that could be obscuring the email from you. You could also try having the email sent in a slightly different way by requesting the password reset from another project, such as meta:Special:PasswordReset. — xaosfluxTalk14:27, 10 December 2019 (UTC)
I think there is (or was?) a 24-hour limit on reset requests, so that you can't do it repeatedly. It's possible that if it's not working "today", that "tomorrow" will give you another story. Whatamidoing (WMF) (talk) 17:38, 14 December 2019 (UTC)
A new "fast" mode has been introduced. When used, the watchlist serves as just a list of pages that have been modified, and no longer includes context about the edits themselves.
More information has been added to entries. When edits are not grouped by page, or when there is only 1 edit to a page, minor and bot flags are shown, as well as the user who made the edit, the summary used, and any tags that were applied. When multiple entries are grouped, bot and minor flags are only shown if all of the grouped edits were made by bots or where marked as minor. If only 1 user edited the page, that user's name is still shown, but no summaries or tags are included.
All watchlists are now fetched in parallel, rather than in series, greatly reducing load time.
Technical notes
Most of the source code is now annotated with jsdoc notes, allowing others to more clearly understand and review the code.
I will be looking into creating guidelines to let others contribute to the script; see phab:T238298.
Newly translated messages are added to the script when I notice them; if you have translated messages that aren't showing up, please let me know at m:User talk:DannyS712.
Next release
Version 7.0 was just finalized for the development and stable branches of the script.
I noticed this a few days ago, using Firefox 71 on Windows 7. When Edit pages on double click is selected in my preferences, it does work, but when I go to double click when I'm already in the editing window (such as to highlight a single word), it refreshes the page as if I just clicked the edit button at the top. Is anyone else having this problem? Because I've had to disable it for now.--十八10:01, 15 December 2019 (UTC)
A fun romp with unicode
Please pardon this rant. I've just spent the past day and a half tearing my hair out. Rants such as these are therapeutic after such adventures.
I've been exploring the sockpuppet world lately, writing some code which extracts data from archived SPI cases. Along the way, I discovered (not surprisingly) that some users are mentioned in more than one case. So, I added code to filter out the duplicates. Then I discovered I was still getting duplicates. Which was quite surprising.
In particular, User:ⁿᵘˡˡ (amongst others) was showing up twice in my output, somehow getting past my duplicate detection code. For those who can't view that properly, the username is:
SUPERSCRIPT LATIN SMALL LETTER N
MODIFIER LETTER SMALL U
MODIFIER LETTER SMALL L
MODIFIER LETTER SMALL L
I couldn't figure out how my code could be failing. Detecting duplicates is pretty simple. I'm doing this in python. You just create a set(), check to see if a name is already in the set, and if not, add it. Easy peasy. But, when I ran some sanity checks on the output (using jq, sort, and uniq -c), ⁿᵘˡˡ (and a few other non-ascii names) kept showing up as being there multiple times. But, no matter how I looked at the output, or instrumented my code, I couldn't find what was going on.
Well, it turns out, there's a bug in uniq! Of all the things I expected to be broken, uniq was so far down on the list, I never even considered the possibility until I managed to craft a minimal test case and there was nothing else left to blame. Suspecting uniq is broken is like blaming your pencil because your calculus proof is wrong. The first version of uniq I used was on v6 unix, in 1977. So, this is a utility which has been around for 42 years. You would think by now it would be working properly :-) But you would be wrong, because unicode. -- RoySmith(talk)20:22, 15 December 2019 (UTC)
You're trying this on the toolserver? The default locale there (at least for me) was LANG=en_US.UTF-8. Setting it to C, like God intended, fixes it. —Cryptic21:29, 15 December 2019 (UTC)
Hmmm, yes, setting LANG=C does indeed get me the correct output, but I don't think I would call that a "fix". I can see the wrong language code resulting in an unexpected sorting order, but not having two totally different strings compare equal. -- RoySmith(talk)00:14, 16 December 2019 (UTC)
Are LC_ALL or LC_COLLATE set? Either would override LANG. (man uniq even explicitly documents the use of LC_COLLATE.)Anyway, comparisons are within scope of collation by design. This lets you "easily" (for usually-unpleasant values of "easy") do case- or accent-insensitive comparisons on purpose. More often, in my experience, you accidentally get the insane sort of results you're seeing here. —Cryptic00:48, 16 December 2019 (UTC)
No, LANG is the only one set. Well, I think, "insane" is the right way to explain this. It's really hard to believe anybody thought this was desired behavior. But at least now I know what's going on. Thanks for pointing me in the right direction. On the topic of accent-insensitive comparisons, we had a similar problem when I was at a music startup. People expected to be able to type in "Ke$ha" and find "Kesha". Not to mention NIИ for Nine Inch Nails. And a few others. Well, people didn't actually search for NIИ too often, but there were lots of Ke$ha searches. I see we support both of those on enwiki via manually-created redirects. -- RoySmith(talk)01:11, 16 December 2019 (UTC)
Sigh. So, I tried putting LANG=C in my .bash_profile, which turned out to be a mistake. That quickly broke most of the rest of my pipeline, with, for example, UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1822: ordinal not in range(128) when the aptly named mwparserfromhell tried to parse the SPI archive files. Maybe if I click my heels together three times, I'll wake up back in Kansas, where everything is in black and white and nobody's heard of unicode? -- RoySmith(talk)01:58, 16 December 2019 (UTC)
My local ubuntu install has C.UTF-8, which might work better, depending on the phase of the moon. But the safe way to fix it is to make an alias to change locale just for uniq (and whatever else inevitably breaks). —Cryptic02:13, 16 December 2019 (UTC)
Main page has not updated for new day (16 December)
It's still showing the day's featured article and selected anniversaries and observances for 15 December. (DYK, too, but that could be because it recently failed to update on time and its return to updating at midnight was staggered.) The current time shown on the talk page of the main page is 19:42 (on 15 December, presumably) and seems to be stuck. Purging the main page and the talk page doesn't work. (I am submitting this at 03:33 (UTC) on 16 December; let's see if that's the time that shows up in my signature.) —173.129.6.172 (talk) 03:33, 16 December 2019 (UTC)
Hmmm. Once I submitted the above edit, the main page and its talk page updated for me. —173.129.6.172 (talk) 03:42, 16 December 2019 (UTC)
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
The Linter extension helps you find technical errors in articles. It did not show new changes last week. This was because of an API problem. It is now working again. [1]
Special:Watchlist can show the wrong information again. It does not always show which edits are read and which are unread. This is because of a database problem. The developers are working on solving the problem. [2]
Changes later this week
You can get email notifications. You can get them immediately, a summary every day or a summary once every week. If you choose a summary you can soon choose not to get notifications you have already marked as read on the wiki. [3]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 December. It will be on non-Wikipedia wikis and some Wikipedias from 18 December. It will be on all wikis from 19 December (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 18 December at 16:00 (UTC). See how to join.
Future changes
The partial blocks feature is now stable. It will come to most wikis on 6 January. Your wiki can ask to wait. Contact NKohli (WMF) if you don't want it now. [4]
I wanted to give a heads up so there's less surprise. Over the past several months, I've rewritten meta:MoreMenu (aka "Dropdown menus") from scratch and have slowly been migrating wikis to using the new version. English Wikipedia is next! There are some 16,000 users, though I suspect only a fraction are still active. The new version is fully localizable, extendable, and it now works in the Timeless skin. If you use the Vector skin, you'll notice minimal changes. If you use Monobook or Modern, you'll see a slightly bigger font size (which matches the default font size for the skin), but everything will largely function the same. You can try the new version now by installing it globally (the preferred method), just make sure you first uninstall the gadget here. If there are any concerns, please let me know. I plan to make this upgrade in the coming days. Best, — MusikAnimaltalk21:27, 11 December 2019 (UTC)
The spacing between visible entries in the first section of the template, 'Life', might be an easy fix, but I can't figure it out. Can someone take a look? Posting it here because this might be an unusual case (unless I'm missing an obvious solution). Thanks. Randy Kryn (talk) 03:31, 18 December 2019 (UTC)
Thank you both. Jonesey95, your 25 life-minutes (a traded commodity in some nations, well, all nations) fixed a problem that has infected the template for a long time. Your fix, whatever it was, may work on similar situations (I think I saw one somewhere months ago) and should go down in history as the rare non-obvious pre-Festivus miracle. Thanks. Randy Kryn (talk) 11:47, 18 December 2019 (UTC)
This piqued my curiosity. It turns out that the old version was producing wikitext that looked something like
[...]
*<spanclass="nowrap">[[List of United States senators from New York|United States senator from New York, 1965–1968]]</span>
*<spanclass="nowrap">[[United States Attorney General|64th United States Attorney General, 1961–1964]]</span></div></td></tr><tr><thscope="row"class="navbox-group"style="width:1%">Life</th><tdclass="navbox-list navbox-odd"style="text-align:left;border-left-width:2px;border-left-style:solid;width:100%;padding:0px"><divstyle="padding:0em 0.25em">
*<spanclass="nowrap">[[Robert F. Kennedy's 1948 visit to Palestine|1948 Palestine visit]]</span>
*<spanclass="nowrap">[[United States Senate Select Committee on Improper Activities in Labor and Management|Senate Committee investigation of Labor and Management]]</span>
[...]
Since there's no non-list line in between the "above" content and the "group1" content, the parser combines that into one <ul>, with resulting tag soup since the table cell and row is ended in the middle of one of the list items and a new row and cell is begun. Apparently the HTML5-specified treatment for that tag soup leaves the <li> inside the new table cell without a parent <ul> or other list tag. The CSS for .hlist ul ul that is supposed to format a sublist as inline doesn't match (since the parent "list" doesn't actually exist), so it gets the default block formatting instead.Module:Navbox appears to try to account for this sort of thing, but the code doing the accounting fails for the "above" in Template:Robert F. Kennedy because the text doesn't begin with a wikitext list (it has a date, followed by the list). The addition of {{plainlist}} fixed it because that changes the generated wikitext to have a non-list line between the "above" list and the "group1" list. A better fix might be for Module:Navbox's processItem to ensure that its return value always ends in a newline, but I can't say that wouldn't break something somewhere else. Anomie⚔14:13, 18 December 2019 (UTC)
Thank you very much for working on it! It seems to fully work on user and user talk pages. On some others, such as most articles (and this page), the tab appears, but when I click or hover, the menu drops down to the right instead of immediately below, and if I try to select an option from the menu, it disappears before I get a chance. (IE 11 with Monobook.) MANdARAX•XAЯAbИAM19:57, 18 December 2019 (UTC)
Actually, I just tested it with my Xaradnam account, which has a simpler configuration, and everything seems fine. So I guess it's an incompatibility with something else I've got going on. I guess I can experiment with eliminating things and see what happens. Thanks again, for your improvements to the gadget. MANdARAX•XAЯAbИAM20:12, 18 December 2019 (UTC)
QUESTION: Is there some workaround (or equivalent) that can be used to allow short descriptions of templates to properly exist in articles without overriding the article short description?
Drbogdan, couldn't this be solved just using WP:NOINCLUDE? Use <noinclude></noinclude> around the description template and it will only appear on the template, not in articles using the template. —Kusma (t·c) 13:53, 18 December 2019 (UTC)
I was wondering why the default state in the code is not automatically set as "__NOGALLERY__" for categories?
WP:FILECAT says that Images that are used in Wikipedia that are non-free or fair use should not appear as thumbnail images in categories. To prevent the thumbnail preview of images from appearing in a category, __NOGALLERY__ should be added to the text of the category. and since most of the freely licensed files are uploaded (and encouraged to be uploaded) to Wikimedia Commons, then the remainig files here are mostly non-free files.
It would seem much more time efficient to have the default set to not show and give an option to set it on (__YESGALLERY__) instead. Is there something I'm missing here? --Gonnym (talk) 12:12, 18 December 2019 (UTC)
If you are wondering why, it is probably for historical reasons. Ten or so years ago, many free images were first uploaded to local Wikipedias and only later moved to Commons, so there were many free images available locally. There were also some people opposed to moving images to Commons, as they perceived that to be a loss of control over their files. In any case, I'd like to see some numbers on how many free files we have here before I'd have an idea whether I'd agree with changing the default. —Kusma (t·c) 12:20, 18 December 2019 (UTC)
Not sure if this is the actual results, but Category:All non-free media has 642,606 files, and Category:All free media has 233,566 files. So that's almost 3x more non-free media. Also interesting to see how many of the free-media files are actually in categories other than the default free-media ones (which means that any change can be easily implemented). I randomly checked several and they were all only tagged in these. --Gonnym (talk) 10:13, 19 December 2019 (UTC)
Template help
I have came here to seek help about templates because Cullen328 has introduced me this. My question is, how can I make the description of a parameter, make the parameter visible in the “add more information” instead of typing the parameter name on the search bar of the add more information and pressing enter to make the parameter as an unknown field, and give the template itself a description? -- BankBank Robbery started a robbery(🚨)09:58, 19 December 2019 (UTC)
When I am home, I usually edit on a 17 inch laptops. Today, I am traveling and am on my 9.7” iPad (2018). I had created {{Charles}} on a 17 inch screen with the intention that it be the same width as an info box. However, I have now discovered that it seems to expand and contract based on the size of the viewing screen in a manner that makes its size dissimilar to info box screen sizes. Is it possible to reformat this to have a fixed width?-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 15:16, 19 December 2019 (UTC)
Because you used |width=16%, a percentage of available display width. Infoboxen are typically a fixed 22em wide, try that.
Is there any tool or method for finding all currently-blocked editors who have edited a particular page?
It's not uncommon to encounter a user who looks like they may be a sock of a blocked user, without knowing which sock (and, therefore, having nothing to go on in terms of investigating and putting together a possible report) - things like a new editors who immediately leaps into controversial topic areas, shown extensive knowledge of policy, immediately pushing limits, referencing people in a familiar fashion or referring to previous interactions with them, etc. Is there a tool that can be pointed at a page to produce a list of all currently blocked users that have ever edited it (possibly within a set timeframe?) Obviously this can't answer every question or confirm every suspicion (not in the least because sometimes those things really don't mean anything and the user is genuinely new or just changed accounts because they wanted to rather than as a WP:SOCK violation), but it would be useful as a starting point when there's reason to believe an editor may be a sock of a blocked user. An even more powerful tool would be one that could find all currently-blocked users who have substantial overlaps with a particular user, but I imagine that would be extremely difficult to determine. --Aquillion (talk) 07:36, 19 December 2019 (UTC)
There is at least one user script hanging around that will highlight blocked users in a certain color. Going to the history page of the specific article would subsequently indicate who they were. --Izno (talk) 12:52, 19 December 2019 (UTC)
Thanks had a play with that, however I want to potentially hide a whole series of titles like the main page is displayed, any way or is that HTML based?The Original Filfi (talk) 11:50, 19 December 2019 (UTC) edit, I copied all source from main and did not hide title on samdbox.The Original Filfi (talk) 11:52, 19 December 2019 (UTC)
The Main Page title is hidden with code in MediaWiki:Vector.css and similar code for other skins. Do not attempt to hide article titles in the English Wikipedia. We want the titles to be visible. If this is about another wiki then say which wiki and why you want to do it. PrimeHunter (talk) 12:12, 19 December 2019 (UTC)
Can be done using <span style="font-size:0;">...</span>. Though I don't see any legitimate usage for this in the main space. You could do this in your own userspace or project space, though. SD0001 (talk) 12:44, 19 December 2019 (UTC)
Hi PrimeHunter FYI there is a potential legitimate use that I have in mind which I will not go into here, potentially on all wikis.
Hi SD0001, thanks for that, however, I cannot seem to get this to work, I probably have miss interpreted the code or use of the same, I tried <span style="font-size:0;">...</span>, where "..." - equaled the page name and placed at the start of my sandbox page, could you detail a little more how this would be implemented, FYI there will be no changes made in any main space until my idea has been tested, published and agreed by consensus or otherwise, ThanksThe Original Filfi (talk) 04:16, 21 December 2019 (UTC)
Is there a way to search for a specific word in all my contributions? I'm not seeing anything in Special:Search that lets me specify the author, or in Special:Contributions that lets me search for content. I'm pretty sure it was in some talk space, where I almost always sign my name, so I tried searching for pages that include the word I'm looking for and "RoySmith", but that gives me too much to sift through. — Preceding unsigned comment added by RoySmith (talk • contribs) 18:02, 19 December 2019 (UTC)
@RoySmith: not that I'm aware of, old revision content isn't really indexed anywhere - someone could build a tool to grab your contributions then recursively load and scan each page revision you made - but it would be quite slow, especially if you wanted to scan all 37000+ of your contributions. — xaosfluxTalk20:45, 19 December 2019 (UTC)
That is because it is actually "in the source" of the current page, if it is no longer in the source (say if it was archived to history) it shouldn't work. — xaosfluxTalk22:20, 19 December 2019 (UTC)
There are very few pages which archive to history, and those are probably not the pages Roy has in mind. --Izno (talk) 22:43, 19 December 2019 (UTC)
I realized I was being mysterious about what I was looking for, which I didn't intend. I'm looking for someplace where I wrote "desysop", almost certainly either on some WP-space page (or WP talk), or maybe User talk. All of these are likely to be archived. The problem is, if you search, say, the WP:ANI archives, the word "desysop" shows up on almost every page, so finding a page that has both "desysop" and "RoySmith" isn't very selective. -- RoySmith(talk)22:57, 19 December 2019 (UTC)
On the user contributions page, it is possible to see only new page creations, but this includes the creation of redirects, which can be numerous. Is there a way to view only user contributions that are new page creations excluding redirects? BD2412T19:22, 21 December 2019 (UTC)
It sounds like it could be a useful parameters to Special:Contributions in general, but even if it existed (which it does not) it would likely be prevented as we are in misermode. — xaosfluxTalk20:37, 21 December 2019 (UTC)
Looks like redirects have the tag "mw-new-redirect". For now, you could do something in JS or CSS (i.e., not display, delete, etc.) to the elements that have class "mw-tag-mw-new-redirect", right? —[AlanM1(talk)]—11:58, 22 December 2019 (UTC)
@AlanM1: this, or a script hack like you mentioned, only work if the page was initially created as a redirect, not if it was created then redirected - but it could certainly be helpful. — xaosfluxTalk14:00, 22 December 2019 (UTC)
I'm just wondering if others have noticed this as well. I don't want to file a bug if it's only happening to me. – Frood (talk) 22:20, 22 December 2019 (UTC)
Until bots have their own thought process and intelligence + emotions, it will be helpful if you thank the bot operator who will be encouraged by your gesture. --DBigXrayᗙ13:09, 10 December 2019 (UTC)
That is my intention, DBigXray, but my advances in telling the bots to send my thanks to their operators have been coldly thwarted by the interface (API error, or sumthin'). Guarapiranga (talk) 13:26, 10 December 2019 (UTC)
@Guarapiranga: Since this is VPT I'll give a tech answer: it is because we haven't enabled it in the extension configuration ($wgThanksSendToBots). There is a task request open you can participate in if you would like to follow up: phab:T205224. — xaosfluxTalk14:04, 10 December 2019 (UTC)
@Glades12: We can quite safely assume a logged-in editor is always the same person (except when someone uses a shared accout, against our policies), but we can't assume that in case of IP-editors. Sometimes multiple anonymous users use the same proxy, so the IP address does not identify an editor, and then any thanks may be misdirected. --CiaPan (talk) 16:25, 10 December 2019 (UTC)
We can't say thank you to an IP, because we don't know the right person will read it. We can warn an IP, because we know the right person will read it. DuncanHill (talk) 23:57, 13 December 2019 (UTC)
Realistically, you can thank both bots and IP editors by posting something on their talk page. Posting those kinds of thanks is pretty much exactly what the Wikilove extension was built for. If you really appreciate the edit/action/etc, taking the 30 seconds required to do that (instead of the 2 seconds for the little link on the diff) will probably be more helpful - the bot owner will see it on the bot's talk page, and the direct interaction with an IP editor may encourage them to (a) continue editing and (b) consider creating an account. Risker (talk) 04:44, 23 December 2019 (UTC)
Pretend you have never edited Wikipedia. Do not pretend you are a complete idiot.
Go to the Main Page, and switch to mobile view
Scroll to the bottom. Note the big button labeled "Talk". Click it.
This brings you to a very simple page. At the top, there is a big blue button labeled "Add discussion". Click it.
Now you will see another simple page, with one field labeled "Subject", and another labeled "What is on your mind?" (!). That's it. No edit notice. No chance to see Talk:Main Page/HelpBox. No mention of what this page is about. Literally just an invitation to share your thoughts.
And yet we're surprised by all the off-topic stuff that gets posted here.
Anything we can do about this? Before anyone says "edit filter", I think think the first choice should always be to alert users before they make a mistake, so as not to waste their time. Suffusion of Yellow (talk) 18:04, 9 December 2019 (UTC)
Just one more reason we should do away with the mobile version. Yes, people are using their phones more and more. BUT if the phone can't display the entirety of Wikipedia without us having to chop it down, then that phone really SHOULDN'T be used for viewing (much less editing) this site. Mobile phone users complaining about their access to this site (or lack there of) are like radio listeners complaining that they can't see the TV image on their devices. --Khajidha (talk) 19:18, 9 December 2019 (UTC)
This would be rather drastic, but we could hide the talk button by putting something like this in MediaWiki:mobile.css:
This seems like a broader problem with the mobile interface for all talk pages, not just this one. I too question why we allow any edits from the mobile version (it's great for viewing). However I feel like this is something for WP:VPT to resolve on a site-wide basis, not for T:MP to come up with a kludge for just one page. Oddly, I don't see the 'talk' button on my phone, but I do if I switch my desktop browser to mobile view *shrug*. Modest Geniustalk20:28, 9 December 2019 (UTC)
@Modest Genius: Agree it's a sitewide problem, but the talk link is at least harder to find on other pages. Only the MP has the special big button at the bottom, at least for me. Are you logged in on your phone? Suffusion of Yellow (talk) 20:40, 9 December 2019 (UTC)
Ah that might explain the difference - I was logged in on desktop, not on my phone. When I do see the 'talk' button it appears on every page, not just the MP. Modest Geniustalk21:20, 9 December 2019 (UTC)
Talk:Main page (mobile) with modified meta-data-issues headerTalk-Donald Trump (mobile) with modified meta-data-issues header
No, mobile view is a very useful editor and I use it all the time, and the new mobile editor is has been extremely useful. Just because you personally do not use it does not mean it is useless. And your analogy is stupid. NixinovaTC06:04, 10 December 2019 (UTC)
Mobile user with 10000+ edits here. No thanks, I would not like to be forced to permanently change to the desktop version. Glades12 (talk) 10:22, 10 December 2019 (UTC)
@Muboshgu: Reverting the off-topic edits isn't all that difficult. It's the WP:BITE issue of being reverted, and sometimes warned, for doing exactly what you were told to do: Fill in a box labeled "What is on your mind?". Suffusion of Yellow (talk) 17:29, 10 December 2019 (UTC)
"What is on your mind?" is lovely and warm and fuzzy and inclusive and welcoming and "reaching out", and nothing whatsoever to do with building an encyclopaedia, so expect serious repercussions from WMF if we try to do anything about it. DuncanHill (talk) 20:01, 10 December 2019 (UTC)
Xaosflux is right. You don't want to mess with the messages that Legal cares about. I'm doubtful that changing a message that appears *after* the IP has already decided to post a message will have much effect on the content of that message. It is unlikely that someone will think, "Hmm, I should figure out how to tell them about this thing – oh, it says 'tell us what's on your mind'? Well, I'm really hungry, so I'll tell them that french fries are on my mind, and skip all that stuff that I was going to write". If you decide to change something, maybe you should monitor the situation and see whether it changes behavior. Whatamidoing (WMF) (talk) 17:25, 14 December 2019 (UTC)
On that page, there's also Mediawiki:mobile-frontend-meta-data-issues-header-talk, which only shows up if there's a {{tmbox}} on the talk page, I think. Clicking that shows the user exactly what we want them to see. Except, it's tiny (I missed it probably a dozen times) and not obviously a link. Perhaps it with some CSS in MediaWiki:mobile.css it could be made bigger or more colorful. And the text changed to something like "This page is not a forum. Click here for more information." Suffusion of Yellow (talk) 22:05, 15 December 2019 (UTC)
That looks like a good way to go. I have uploaded mockup images for that, see the images by right. Not sure whether it could make a big impact though. – Ammarpad (talk) 06:40, 22 December 2019 (UTC)
To be clear I am not impressed with the wording either (I also agree with his other concerns). But even more, in general terms I don't think this change would remedy the original problem in question at all. What I think is the best is maybe to just semi protect Talk:Main Page indefinitely. Most, if not all, of the edits being reverted there were by non-autoconfirmed users. I made some manual random sampling to confirm this. Someone may run a query however to get more clear/accurate picture of the issue. I will note that the page is currently semi-protected for one month until January 15, and since then there's no mobile edit that was reverted. In fact only one edit was undone, and it appears to be unrelated to the issue in question. – Ammarpad (talk) 06:49, 23 December 2019 (UTC)
On holdPppery will want to mock this up on testwiki first and ensure it doesn't cause some odd issues with wider text there - also do you happen to know if the mobile-app makes use of this message? — xaosfluxTalk14:33, 21 December 2019 (UTC)
@Pppery: I'll probably do it on testwiki unless someone else gets to it first should be in the next couple of days, leaving this open to remind me. — xaosfluxTalk00:18, 22 December 2019 (UTC)
@Ammarpad: thank you for the mock ups. @Pppery: that phasing doesn't seem great to me for something for all readers, perhaps some more tweaking? This page is not a forum. Click here for more information makes me think that clicking that link is only something that I would do if I wanted to know more about why it isn't a forum - not the primary purpose of that link. Also, the talk page is sort of a forum - a forum for discussing changes to the page. — xaosfluxTalk13:22, 22 December 2019 (UTC)
Not done with edit requests, the request itself is the "B" of WP:BRD, in this case there is a decline (the "R") so this needs further discussion. If the discussion concludes a change should be made, please link to it (if held elsewhere) then reactivate the edit request at that time. — xaosfluxTalk17:46, 24 December 2019 (UTC)
Changing it to "New section"? No. That would look quite incongruous with the textbox. Maybe blanking it? not sure though. – Ammarpad (talk) 06:25, 23 December 2019 (UTC)
The visited pages on my watchlist keep returning to bold even though there are no further edits since my visit. What gives? WWGB (talk) 13:57, 12 December 2019 (UTC)
This is a bug that has been coming and going for at least nine months now (see link to the right). It has gotten worse in the past few days. – Jonesey95 (talk) 15:35, 12 December 2019 (UTC)
Watchlist and Revision History bullet points slow to indicate visited status
It used to be that I could rely on the bullet points on my watchlist and articles' revision histories changing color quickly to indicate visited, or read, status, the watchlist points changing from blue to white, or clear, the revision history points from green to blue (I use vector skin). Now it happens slowly (version from 4:07 am UTC yesterday, still unmarked) or haphazardly (VP Technical, this group, marked as caught up, when most of those I've visited are marked as apparently unvisited). It helps to have the bullet points updated quickly. Can anyone explain what has happened and whether it will be fixed? Dhtwiki (talk) 04:01, 16 December 2019 (UTC)
My problem seems much alleviated today. I'll add that, with the others, I have been experiencing similar delays for some time (order of weeks) but not as bad as just now (~Dec. 15-16). Dhtwiki (talk) 23:55, 16 December 2019 (UTC)
Watchlist Not Updating
I am attempting to open the diffs on my watchlist and have the indicator show that that page has been viewed, but after refreshing the page, only the most recently opened article shows as viewed. I found another instance of someone having this issue here, but no one offered a solution. This problem started on 12/12/19 or so, and continues today.
I am using Chrome for Desktop, version 79.0.3945.79 (up to date as of 12/16/19).
Just now saw that a few other people have been having this issue and that it's completely site dependent it seems? Oh well, hopefully it gets fixed. Cerebral726 (talk) 14:56, 16 December 2019 (UTC)
I am as well and I can't figure out how to purge my watchlist cache. I've tried ?action=purge at the end of the url, but it doesn't do anything. Cyphoidbomb (talk) 22:42, 20 December 2019 (UTC)
Select Watched Page Not Visible on Watchlist
Fireox 71.0 (32-bit), also Google Chrome Version 79.0.3945.88 (Official Build) (64-bit), Modern Skin, with tabs at the top of each page.
As of today, Template:Did you know does not show on my watchlist, alhough it's been on the watchlist for years. I purged my cache (Tab/Page/Purge cache). Nothing. I Unwatched and then Watched. Nothing. I suspect this might have more to do with changes that happened this week. A few days ago, the look changed as far as certain items that had always been part of a drop-down when mousing over any page tab. (@MusikAnimal:?) Sometimes User would be there, sometimes it took a refresh, etc. And what used to be under User would be other places. By the next day, all that cleared up. This watchlist missing item seems like it might be connected. — Maile (talk) 17:29, 21 December 2019 (UTC)
Update - now, ALL my watch pages connected by Did You Know are not displaying on my watchlist when changes are made. Also, this very page, Village Pump (technical) is watched by me, but does not appear on my watchlist when changes are made. What is going on? — Maile (talk) 02:31, 23 December 2019 (UTC)
The watchlist header says "Changes to pages since you last visited them are shown in bold with solid markers." That does not appear to be the case here. I edit on an iPhone, and in both the mobile and desktop views the page names are always in boldface and I see no difference depending on whether an edit is more recent than one of mine. Also, what are "markers"? Jmar67 (talk) 12:34, 22 December 2019 (UTC)
Out of curiosity, I tried editing my alt account's user talk page, while that account was in mobile view. I saw no yellow "You have new messages" banner, just an unexplained "1" in a circle. That's bad enough. Then, on a local wiki, I tried editing my own IP's user talk page. In a not-logged-in browser window, I could also see no "new messages" banner. In fact, there was no hint of any kind that someone wanted to talk to me, unless I switched to desktop. Can someone who doesn't mind exposing their IP try this on enwiki? If we're blocking mobile editors for being "unresponsive", that's really bad. Suffusion of Yellow (talk) 23:43, 14 December 2019 (UTC)
This has been the standard for a while afaik. The red notif is very noticeable but also very confusing, eventually got hold of it ofcourse. I don't think I want or need the banner on mobile (owing to the new notif system) but I think there should be a choice to enable the banners for users who want it. --qedk (t桜c)19:47, 16 December 2019 (UTC)
@QEDK: What about IPs? They don't even get the red circle. And for logged in users, the banner should be opt-out, not opt-in. Until people figure out what the circle means, they won't realize we are trying to talk to them, and risk getting blocked for WP:IDHT. Suffusion of Yellow (talk) 19:59, 16 December 2019 (UTC)
I am not aware of the interaction of the notification system with IP addresses, it's been years since I last edited as one, but it's true that if there's no way of notifying them on mobile, our warnings are basically more of checking useless procedural checkboxes to block them and less of a proof of WP:IDHT behaviour. --qedk (t桜c)21:46, 16 December 2019 (UTC)
Exactly my point. Of course if you've gone to the trouble of typing out a personalized message to the IP, you could have better spent your time going outside and shouting at the sky. But, an IP editor, or someone who doesn't mind exposing their IP, could be a real help here in confirming this. Suffusion of Yellow (talk) 22:09, 16 December 2019 (UTC)
@Suffusion of Yellow: OK so I did a test (on meta-wiki, edits have been since suppressed).:
Test
I made a couple of edits as an IP, using desktop, and using mobile browser.
I used a logged in account to leave User_talk: messages for that IP user.
I observed the effects on desktop and mobile site
I did not use the mobile app
Results
On the desktop site the IP user got the "new messages" notification bar , no notification "badge" counts were shown
On the mobile web site (from an actual mobile OS as well) - no notification bar was shown, no badges were shown
@Xaosflux: Thank you! Amazing how privacy-paranoid we all are, that this took three days for someone to answer... Moving forward, any ideas at to what we should do about this on enwiki, if the IP problem isn't fixed quickly? Block mobile IP vandals without warning? Put something in MediaWiki:Mobile.js to check for new messages? Something else? Suffusion of Yellow (talk) 18:00, 17 December 2019 (UTC)
@Suffusion of Yellow: the "in the meantime" would be to follow the blocking policy - we're certainly not going to stop trying to warn people - especially as IPs can be shared - sometimes with thousands of people. Trying to get a rally around the phab ticket may be a good idea. — xaosfluxTalk14:53, 23 December 2019 (UTC)
All the links in the mobile watchlist are misplaced from where the text appears, and the page itself is super laggy. NixinovaTC21:52, 22 December 2019 (UTC)
Talk sections that include quotation marks or other characters that are escaped in a url cannot be uncollapsed in the new mobile view of talk pages. NixinovaTC07:42, 23 December 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Tech News
Because of the holidays the next issue of Tech News will be sent out on 6 January 2020.
Recent changes
All mobile site users now have new features. Features include: tabs for page/discussion; an expanded user-menu; direct access to history pages. These features were initially part of the "advanced mode".
Changes later this week
There is no new MediaWiki version this week or next week.
Future changes
You can use setlang in the URL to change the user interface language. This will no longer happen automatically. When you open the link you will be asked to confirm the language change. This will not happen if Javascript is not working in your browser. [5]
Hi, I would want to know if there is any module/template for reading the contents of a Wikipedia page?
(e.g. inputting User:The Lord of Math should give the following:
{{Humor}}
Hi, I'm 數神 from Hong Kong. I like to go to [[Special:RecentChanges|this page]], catch vandals and give warnings. I also work in Chinese and Classical Chinese wikipedias.
<big>Language portal: [[User:數神/LangPortal]]</big>
<big>Vandals Warned Portal: [https://wiki.riteme.site/w/index.php?target=%E6%95%B8%E7%A5%9E&namespace=3&tagfilter=&start=&end=&limit=50&title=Special%3AContributions Warnings List]</big>
== Just ended ==
Anti-vandalism season has ended!
Vandals warned: [https://xtools.wmflabs.org/topedits/wiki.riteme.site/%E6%95%B8%E7%A5%9E/3 106]
{{Vandalism information}}{{User Erdos|4}}
I don't know if this is the proper use of this area, but here goes...
Since a couple of weeks ago, on my Windows 10 ASUS laptop, most images are not displaying. I see a broken image icon image and the filename of the image in text. When I click on the image filename it displays a standard message instead, reading:
Sorry, the file cannot be displayed
There seems to be a technical issue. You can retry if
it persists. Error: could not load image from
https://upload.wikimedia.org/wikipedia/en/7/72/Cry_of_a_Prostitute.jpg
Oddly, a few images do display. For example, on today's front page a photo of Donald Trump displays OK, but even then, if I click on it, I get the text as shown above.
This happens with Chrome, Edge and Opera. It does not happen on my Android phone or either of my Android tablets (all Samsung, btw). And it doesn't happen on our Desktop computer running Windows 10. And images are displaying normally on all other websites. It's just happening with Wikipedia. I'm getting the feeling that the issue has to do with some kind of interaction with my laptop. Suggestions welcome!
@Cyberherbalist: a couple of things to check: (a) Check the time and date on your computer to make sure it is OK, we use encryption and that depends on timestamps. (b) Most images from from commons.wikimedia.org and upload.wikimedia.org - check to see if you have anything blocking these domains like an ad-blocker, script blockers, etc. (c) Try to go to commons:Main Page and see if you can see images there. — xaosfluxTalk17:16, 23 December 2019 (UTC)
Wow, thanks for that! I checked my Avast security software settings, and turned off anti-tracking. Immediately all images were visible. It must have been a recent change to Avast, because I've been running that security software for quite some time. I think I will be raising this issue as a bug report to them. Cyberherbalist (talk) 00:56, 24 December 2019 (UTC)
This usually means that there is some JavaScript that is still running when the page is displayed: the JavaScript either adds, removes or otherwise rearranges text on the page, and once the JavaScript completes, the jumping stops. One possible culprit may be this RfA notice - if you dismiss it, the jumping should not occur if you refresh your watchlist. --Redrose64 🌹 (talk) 21:34, 22 December 2019 (UTC)
It happens to me on Samsung as well using Chrome; has happened for a reasonable period of time. Annoying when you click on the wrong link. Happy Festivities! // J947(c)22:36, 22 December 2019 (UTC)
Ran Safari 13.0.3 on Responsive Design Mode with iPad (iOS 12.1.3), UA switch enabled/disabled, mobile/desktop, unable to replicate. --qedk (t桜c)09:30, 24 December 2019 (UTC)
I accidentally tried to edit an old version because I wanted to see why a strange edit was done, and then I was trying to edit the section. The woman at the library asked me to try other browsers. Same thing happened. She said she'd let IT know.— Vchimpanzee • talk • contributions • 15:27, 17 December 2019 (UTC)
@Vchimpanzee: The coloring of the "This is an old revision" and the "Your are editing an old revision" boxes should be the same: background-color 254,246,231 (fef6e7) with a border of 255,204,51 (ffcc33) - you should be able to verify if this is what you are getting from us, if not you may have a cached stylesheet stuck somewhere. If you have that color being sent and it is not appearing correctly, your computer may need adjusting. — xaosfluxTalk17:34, 17 December 2019 (UTC)
If I go to any article with geographical coordinates, say Heidelberg, and click on the globe in the upper right for an interactive map, I get "502 Bad Gateway nginx/1.13.6". Where would I report that? Thanks, AxelBoldt (talk) 18:03, 24 December 2019 (UTC)
OK, I figured it out: it's called WikiMiniAtlas and is hosted at wma.wmflabs.org. The site is down though; I still don't know whom to contact. AxelBoldt (talk) 19:16, 24 December 2019 (UTC)
Guys, I currently have a problem with trying to get RefToolbar to work on one of my wikis, which was updated to MediaWiki 1.34 a few days ago. The console error states that "importScript is not defined". In full detail:
ReferenceError: "importScript is not defined" (load.php:2:567)
initializeRefTools https://nsindex.net/w/load.php?lang=en-gb&modules=ext.gadget.DotsSyntaxHighlighter,HotCat,ReferenceTooltips,edittop,refToolbar&skin=vector&version=pl82e:46
jQuery 4
fire
fireWith
tuple[0]
using
doPropagation https://nsindex.net/w/load.php?lang=en-gb&modules=startup&only=scripts&raw=1&skin=vector:8
I wish to ask where I can find the code for importScript so I can perhaps mirror the class over to my wiki: it seems importScript works perfectly fine here, but not under the main release of MediaWiki 1.34, so I am not sure what I am missing. The list of imported scripts can be found at https://nsindex.net/wiki/Help:RefToolbar#RefToolbar_components.
I have refreshed the gadget with the revised code and it works, but the forms appear large and the background is white instead of bluish grey. Where does the gadget get the CSS rules for the style elements of the form, such as .ui-widget and .ui-widget-content? In either case, it seems the Wikipedia version of the script needs updating. Edit: the styling issues were solved by adopting the WMF versions of Vector. Best, --Minoa (talk) 21:20, 24 December 2019 (UTC)
Edit box
Hi, Anyone have an idea why my edit box is like this ?,
It all loads as black but then changes to purple (for articles) or grey/big headers (for talkpages),
Thanks, –Davey2010Talk21:07, 25 December 2019 (UTC)
@Davey2010: You have syntax highlighting enabled - the pencil button just left of "Advanced" in the toolbar. Click it again to disable, although personally I find it quite helpful. The purple in the article screenshot is marking templates. the wub"?!"22:35, 25 December 2019 (UTC)
Hi all, can someone with template experience please look at this discussion and remove |residence=? I'm not sure what else needs to happen, but I'd imagine that a bot needs to remove the content somehow? Can someone please look into that. I've no experience with this. Thanks, Cyphoidbomb (talk) 03:08, 26 December 2019 (UTC)
This is a stupid question, but I saw someone add this to an article: *𝓐𝓷𝓪𝓰𝓱𝓪 𝓼𝓪𝓷𝓳𝓮𝓮𝓿 𝓪𝓼 𝓶𝓪𝓱𝓲𝓶𝓪(𝓮𝓹𝓲𝓼𝓸𝓭𝓮 182). How would you technical types describe this? Unicode font? ASCII font? How does one generate this sort of thing? Thanks, Cyphoidbomb (talk) 20:19, 24 December 2019 (UTC)
Looks like there are editors who have used some of these characters in their sigs, according to a search of Wikipedia namespace for "𝓮" AND insource:/[𝐀-𝟿]{3}/. Any idea how to do a search that won't time out to find these in article space? —[AlanM1(talk)]—14:09, 25 December 2019 (UTC)
The toggle "Hide registered users" at Special:NewPages does not seem to be working properly. While it is possible to hide patrolled edits, bots, and redirects, this toggle does not produce the expected effect of hiding registered users and thus displaying only IP creations (i.e. when I click it, there is no visible change to the pages shown in the feed, unlike the other three toggles). To reproduce, go to Special:NewPages and experiment with these four toggles on the bottom—the plainly labeled one on the far left seems not to be working. Purging the page and using different settings elsewhere in the "New Pages" box do not have any effect. Is there a different intended function, or is this a bug? Thanks in advance. ComplexRational (talk) 16:57, 27 December 2019 (UTC)
Seems this error has been happening a lot recently: "An error has occurred while searching: Search is currently too busy. Please try again later.". Any idea what is causing this, and if there is any work happening in the background to resolve this? Steel1943 (talk) 17:54, 27 December 2019 (UTC)
Continuous editing conflict (cross-post from help desk)
Cross-posting report of a technical issue on the help desk in the hope someone with technical know-how can assist. Please reply to the original post to keep discussion focused. – Teratix₵09:52, 28 December 2019 (UTC) At 04:49, 19 August 2019 (UTC), I came to ask for help because often when I saved edits I got a false "edit conflict" warning. I discovered that several other editors had the same problem. Please see Wikipedia:Help desk/Archives/2019 August 19#Continuous editing conflict. I edit Wikipedia using Google Chrome (up-to-date) running under Win 10 Pro (also up-to-date); nothing exotic. The problem for me has escalated from frequent to constant. It is a real handicap in editing Wikipedia because it wastes a lot of my time. I do not have any beta gadget enabled and my broadband connection is fast enough. I would appreciate help with this problem in editing Wikipedia. Thank you.
At Template:Infobox roller coaster, there are speed parameters (one for mph and one for km/h) that when used will list an auto-conversion from one unit to the other in parenthesis. So for example, if speed_mph = 55 is specified, the infobox will display 55 mph (89 km/h). The problem is that when high values are used, this conversion becomes less concise. An example can be seen at Formula Rossa. 240 km/h is being converted to 150 mph in parenthesis, but multiple sources (including Guinness World Records) list it precisely as 149.1 mph.
The solution is to use the |sigfig=4 parameter with the convert template which isn't currently being done. I wasn't sure how to edit the template to include this for higher numbers only. We wouldn't want 50 km/h to start displaying 31.07 mph, for example. I was thinking only numbers greater than say 165 km/h should use this sigfig parameter (meaning coaster that exceed 102 mph, which isn't many). Does anyone know how to code that? Another option would be to introduce a hidden flag that can be specified when you want the extra precision. Open to ideas here, thanks in advance! --GoneIn60 (talk) 20:38, 27 December 2019 (UTC)
Looks like QEDK added the sigfig parameter to the infobox, so that it can be manually specified when needed. That's a great start, so thanks for that! I may tweak it further so we can do the same for other fields like track length, drop, and height. Maybe have sigfig_speed, sigfig_height, etc. --GoneIn60 (talk) 22:13, 27 December 2019 (UTC)
@GoneIn60: Added |sigfig= as a default parameter to fall back on for an infobox, with each data values having their own sigfig parameters (per your suggestion). --qedk (t桜c)08:17, 28 December 2019 (UTC)
Thanks again for all your help. Per the advice below, I may roll those changes back considering there is a workaround without adding the complexity to the template. But at least I know how to use this option now. Greatly appreciate your time! --GoneIn60 (talk) 20:41, 28 December 2019 (UTC)
Note that for this case you could have just specified the speed_km/h as "240.0", for which {{convert}} will calculate the correct number of significant figures: 240.0 km/h (149.1 mph). With this example you can also specify three significant figures by entering the speed as "240.": 240 km/h (149 mph). But sigfig would be necessary to specify 3 significant figures for a value like "2400000", as Module:Convert doesn't seem to support anything like the overline or underline notations mentioned at Significant figures#Significant figures rules explained. Anomie⚔14:08, 28 December 2019 (UTC)
Today a {{ConfirmationOTRS}} template was placed here with the parameter |license=CCBYSA 4.0 International . That was a good-faith mistake by the agent, who I imagine did not know that that licence is not compatible here, and will I'm sure be resolved. What matters to me here is the behaviour of the template, which ignored the license parameter provided to it, and displayed CC BY-SA 3.0 instead. It looks to me as if it's designed to do that. Wouldn't it be much more useful if it displayed an error message if the licence is CC BY-SA 4.0? Could that easily be made to happen? Justlettersandnumbers (talk) 18:55, 28 December 2019 (UTC)
This is the code:
{{#switch:{{lc:{{{license|}}}}}
|pd|cc0|Public domain|public domain = into the public domain.
|g = Under the [[Wikipedia:Text of the GNU Free Documentation License|GNU Free Documentation License]]. Because this permission was received prior to 1 November 2008, you may use the material under either that license or the Creative Commons Attribution-ShareAlike 3.0 Unported license.
|gfdl|dual|d|both = under both the [[Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License|Creative Commons Attribution-ShareAlike 3.0 Unported license]] and the [[Wikipedia:Text of the GNU Free Documentation License|GNU Free Documentation License]]. You may use either or both licenses.
|cc4|cc-by-sa-4.0 = {{Error|CC BY-SA 4.0 is not a [[WP:Compatible license|compatible license]].}}
|cc|cc3|cc-by-sa|cc-by-sa-3.0|#default = under the [[Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License|Creative Commons Attribution-ShareAlike 3.0 Unported license]].
|attribution = for anyone to use it for any purpose, provided that the copyright holder is properly attributed. Redistribution, derivative work, commercial use, and all other uses are permitted.
|cc-by-3.0 = under the <span class="plainlinks">[https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]</span> license.
|cc-by-4.0 = under the <span class="plainlinks">[https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0]</span> license.
}}
As may be seen, a number of variations on the CC licenses are coded for, including cc, cc0, cc3, cc4, cc-by-3.0, cc-by-4.0, cc-by-sa, cc-by-sa-3.0 and cc-by-sa-4.0; but it has nothing for the (lowercased) value ccbysa 4.0 international - we can't hope to test for every theoretical variation. In such circumstances the fallback is the value for #default so it behaves as if |license=CC-BY-SA-3.0 were specified, which is the Creative Commons Attribution-ShareAlike 3.0 Unported license. If Ganímedes (talk·contribs) were to alter the template parameter from |license=CCBYSA 4.0 International to any of |license=CC-BY-SA-4.0, |license=CC-BY-4.0 or |license=CC-BY-SA-3.0 it would be more explicit. --Redrose64 🌹 (talk) 21:30, 28 December 2019 (UTC)
Thanks all. The customer has agreed to release the text under CCBYSA 3.0, so no problem anymore. I use to work in Commons and we never has got this problem. I apologize. Regards. --Ganímedes (talk) 00:32, 29 December 2019 (UTC)
I would support the deprecation of arbitrary values for |license= in favor of a warning to use a more specific license. I ran a quick report on the parameter usage for ConfirmationOTRS and there's a lot of junk in there that doesn't need to be. --AntiCompositeNumber (talk) 06:00, 29 December 2019 (UTC)
I use the green text on a black screen gadget (available in Preferences), as it makes Wikipedia less painful to look at for extended periods of time. The logo File:Lewes Priory School logo.png appears to contain mainly black images on a transparent background, so to me it all looks black, except for a handful of random white lines and blobs. Is it possible for the file to be edited in some way so as to make it visible to users of the gadget? Thanks, DuncanHill (talk) 20:48, 23 December 2019 (UTC)
@DuncanHill: Yes, it is, but since the issue affects a lot of images with transparent backgrounds it would probably be better to change the gadget so that it doesn't have this issue. Alternatively, if you just want to fix it for yourself, you could add a line of CSS to your common.css page, probably something resembling .mw-parser-output img { background-color: #fff }. (Do note that this will introduce a white background for all images with transparency.) Jc86035 (talk) 08:01, 27 December 2019 (UTC)
@DuncanHill: Choosing appropriate color(s) for a logotype is an important part of a logo design process – see notes at Logo#Logo color. Sometimes companies and other organizations prepare several versions of their logo for use in different color environments (e.g., for black-and-white media with white or with black background; for gray-scale or for multicolor media with light or with dark background). Those versions may have a background added or appropriate contour lines in a color depending on an expected neighborhood. So, there is no simple way to just edit a logo file to make it compatible with an arbitrary environment. The more because a logo is a property of some organization and only they are entitled to choose a new shape, color or contour for their logo. --CiaPan (talk) 16:25, 27 December 2019 (UTC)
@DuncanHill: I see. But maybe eleven years ago, when the file was fetched, the school's website was black on white, like Wikipedia is...?
Anyway, replacing a black-and-white logo with its inverse everywhere is quite safe (you don't risk a change of meaning) and quite simple (it needs just replacing a file). But adjusting an image to both light and dark theme is another thing: it requires either adding appropriate background in the image itself, which will join smoothly with one theme's background and make an appropriate buffering space in the other one; or keeping two or more versions of a file and dynamic supplying appropriate one for a detected theme. One solution is quite artificial and too simple to be good (what if a third theme appears?), the other one is IMHO next to impossible due to a palette detection needed at the client side and lacking method of identifying required versions of an image.
Shortly, I think the best solution (short, safe and quite easy) is adding a background to the image in the default Wikipedia background color. Possibly a gadget might add it, as Jc86035 suggests above. --CiaPan (talk) 20:31, 29 December 2019 (UTC)
Side note: When you have a lot of scripts in your account (not to mention gadgets), the cycle of removing all, clearing your web browser's cache, re-enabling one, testing, and then re-enabling the next, can take a couple of hours. (Then you'll discover that you forgot about your global scripts at Meta, and have to do it all over.) A Binary tree system can be useful: Disable all, and test. If the problem goes away, then one of those scripts is the problem. Re-enable half, and test. If the problem returns, then something in that half is the problem. If it doesn't, then the problem is in the other half. You can keep repeating by halves until you've narrowed it down to the culprit. If you have, say, 16 user scripts, and one is broken, then working by halves always finds the problem in four steps, whereas testing each individually finds the problem in an average of eight rounds. Whatamidoing (WMF) (talk) 17:22, 30 December 2019 (UTC)
More specifically, like this: Special:Diff/933322170. This will always point at the proper edit, no matter how many new edits appear in history (imagine someone trying to follow your advice in 5 years). --CiaPan (talk) 10:54, 31 December 2019 (UTC)
At Category:Requests for unblock under summary section, you can see many editors who were supposed to be unblocked 50 years ago. Any guess whats causing this? My guess is lazy admins since last 51 years. —usernamekiran(talk)10:20, 1 January 2020 (UTC)
Recently a change has been made to how someone can view a person's contributions. If you want to view a person's last 20 contribs, the link looks like this:
https://wiki.riteme.site/w/index.php?title=Special:Contributions/Hammersoft&offset=&limit=20&target=Hammersoft (note the bolded text)
If it's the last 50, it's "limit=50", and so forth. It used to be the case that you could change that URL so to "limit=5000". I used this on occasion when deep searching for particular contributions based on article name or edit summary. This has now been changed, and limits any request over 500 to 500. This is not the case for article histories, where you can still do up to 5000.
Why was this changed, when was it changed, and did the community have any say in its being changed? If so, where? Thanks, --Hammersoft (talk) 15:42, 1 January 2020 (UTC)
(edit conflict) I don't see any template involved there. The wikitext is {{FYI|pointer=y|New RfC at [[RfC: Use of Decorative Quotes in article space, and the Cquote template]]}}; the link is in the wikitext, not being generated by the template. As noted above, "rfc" is in the interwiki map as a link to IETF RFCs. And even if it weren't, that link would be trying to go to a mainspace page instead of the intended section of Wikipedia talk:Manual of Style. Anomie⚔12:30, 2 January 2020 (UTC)
Template code and Lua (and MediaWiki messages)
I used to do a lot of complex template coding here on Wikipedia but have now been away for a long time. But now I am back part time (mostly updating/modernising some of my old stuff). So I would like to ask about some of the new things here. I know some of these questions partly come down to opinions, but advice from more up to date editors/coders would be helpful and appreciated.
1: Does Lua modules run much faster on the servers than templates made with only template code? I mean for fairly complex template code. That is, do Lua modules cause less load on the servers?
2: I see people have gone around changing well working templates into Lua code instead. What reasons could there be for that? Is it mostly about speed (server load) or some other reasons? (I don't mean those cases where Lua allowed them to add some complex functions that are hard to do in template code.)
3: Today I added code in a MediaWiki message calling a Lua module. I could have done it with pure template code instead. Is there a preference for MediaWiki messages? (In this case server load could not be an issue since that code only runs when editing user talk pages.)
4: If I can implement something reasonably efficiently but with somewhat tricky hard to understand code in template code, instead of slightly simpler code in Lua, should I then choose template code or Lua? I assume template code is more portable to other wikis, since many other wikis might not be Lua enabled. (I mean MediaWiki wikis outside the Wikimedia Foundation projects.)
5: I assume there still are more coders here that understand template code than understand Lua? I for instance have not learnt Lua and will probably keep coding template code, only calling Lua modules others have built (if a Lua module happens to provide what I need).
I did find Wikipedia talk:Lua but I wanted to ask here where not only Lua enthusiasts hang out. (And I did spend an hour searching trying to find answers to this, but didn't find much. But I suck at searching.)
@Davidgothberg: you may want to join and ask these also at Wikitech-l. You can also learn a bit more about Lua (especially our implementation of it) at mw:Lua. Lua is a fairly easy programming language (it is an interpreted language). — xaosfluxTalk01:56, 1 January 2020 (UTC)
Variables – so you don't have to reevaluate an expression multiple times; the ability to add copious notes anywhere – can be done but it's a pain; whitespace for readability – not always possible; multiple, callable 'subroutines' all in the same module – callable sub-templates must be separate; import and export functions from and to other modules; huge data tables and the ability to create variants of a data table on an as-needed basis and only once when MediaWiki processes an article even when the template / module has many instances in that article; no doubt there are more reasons to prefer lua.
Don't know and really don't care (I suppose I will when whatever I'm doing runs out of lua time – so far that has only happened when I've done something particularly stupid)
Don't know; I wouldn't if whatever it is works correctly and doesn't need enhancement; I recently updated {{nihongo}} from wikitext to lua so that it uses Module:lang for rendering, adds error detection, categorization; in other words enhancements
I have no opinion about MediaWiki messages
somewhat tricky hard to understand [template] code ... should I then choose template code...? Hell no. You don't endear yourself to other coders by writing code that is hard to understand; those who will come behind you to maintain your tricky code will curse the day you were born – coders who think that tricky hard to understand code is CRUISE CONTROL FOR COOL should be taken out back and thumped. I have helped editors at a variety of the MediaWiki wikis with their implementations of the Module:Citation/CS1 suite of modules; most of those have been smaller; I have seen that same module suite on non-MediaWiki wikis so, as a guess, any wiki manager who wants lua in their installation can get it
Yes, Lua modules do run faster, but you shouldn't care unless there is some indication of a performance problem.
I wouldn't know; I've been going around TfDing that kind of lua module as "Unnecessary Lua module, can be implemented in Wikitext"
There's no specific preference for MediaWiki messages; I consider that usage perfectly fine given that Module:IPAddress already existed. You should, however, delete Template:IP-user other/core now that it is no longer in use
This is a matter of some controversy; I may TfD the module if I can eek out the template code version myself, however in practice those TfDs have had inconsistent results.
I know of no statistics on that matter
One final comment: If you do create a new Lua module, please don't forget to document it, give it the same name as the template that calls it, tag the template with {{lua}}, and redirect the module's talk page. I've been having to complete one or more of these steps for a wide variety of different modules. * Pppery *it has begun...02:43, 1 January 2020 (UTC)
Thanks you all. I feel more updated now. So my interpretation is as follows: Template code is still fully accepted to use. And we can use template code, or Lua, or both combined, whatever we prefer and whatever works and gets the job done. And of course, as an old software engineer I do see the benefits of having a proper programming language like Lua, just that at the moment it would be inadvisable for me to learn another programming language. I lost count of the number of languages I have learnt and forgot since I started coding back in 1982. I am usually only able to work with and efficiently use two or three languages during the same year, my head can't handle more at the same time.
Trappist the monk: No worries, I don't write tricky and hard to understand code to impress. But I prefer to solve the problems as well as possible, and that sometimes leads to rather complex code to handle all the stuff the best way. So yes, some of my templates have kind of "scary" code. But I usually add lots of code comments and documentation to make it easier on the next programmer.
Trappist the monk and Pppery: Haha, it was funny that you kind of threw my old documentation advice back at me. I was one of the people that helped build and design the green template documentation boxes we use here. And I was one of the early adopters of the method to redirect all the talk pages of a template and its subpages to the same talk page. (But I didn't come up with the idea.) It confused people at first, so we started adding a brown box at the top explaining it was a joint talk page.
And regarding performance. We have had performance problems with templates. Back in 2007 and 2008 it was so bad that at times the Wikipedia servers totally stopped serving images, and just showed the text of the articles. And it was normal that it took hours or days for categories to be updated. But that also shows that MediaWiki is well built, it has the right priorities: If overloaded, it still keeps serving the most important part. Some of the culprits were the string handling templates, we had to optimise them a lot to not overload the system. The Wikimedia system admins threatened to turn off the parser functions / magic words we used in those templates. Although the main reason the servers got overloaded was that many admins were doing rapid experimental edits (about one edit a minute) on protected templates deployed on a million pages. That's why we added those warning boxes "This template is used on a million pages" and added the /sandbox and /testcases links on the green template documentation boxes.
I'll add to the above to say that as the complexity of a template (or whatever functionality it implements, which ideally the template complexity should be tied to but unfortunately isn't always so) increases, the argument for converting it to Lua strengthens, even if that template isn't doing any specific, individual task that Lua would be better suited for. Of course, at what point a Lua conversion becomes more preferable than a wikitext template, is up for debate, and different people who value different aspects of template/Lua design and view the issue from different perspectives, could easily have different, well-reasoned thresholds. But to pick a couple egregious cases, I don't think there's anyone here who would seriously argue for a return to the wikitext versions of {{navbox}} or the cite templates, for example. =) 「ディノ奴千？！」☎ Dinoguy100018:16, 1 January 2020 (UTC)
Both of those are bad examples because they perform the lua-exclusive task of supporting an infinite number of arguments. However, if phab:T203293 or phab:T114432 were fixed, I would seriously consider a Wikitext rewrite of Template:Navbox, using Lua only for the specific places in which an infinite number of parameters are needed. * Pppery *it has begun...18:41, 1 January 2020 (UTC)
TheDJ: Ah yes. And nice to see yet another familiar name around here.
Dinoguy1000: I expected this discussion to quickly become philosophic. :)
And the {{navbox}}: There seems to be many ways to implement that "monster". I myself tried my hands at it when it was a bit new. I managed to make a working one that was <div> based instead of <table> based. (Back then it was the latest craze to make everything <div> based.) But upon comparing my version with the table based one, I came to the conclusion that the table approach is better. (Table approach is more manageable with less messy code.) Thankfully I am the kind of person that prefer the best solution before my solution, so I was happy to let my version go. Besides, I really didn't want to become a caretaker of {{navbox}}.
In my mind, official means the creation of the Wikimedia foundation and I don't think that's the case. Can someone weigh in regarding its status?--S Philbrick(Talk)16:29, 2 January 2020 (UTC)
I've always used mwclient. It's been around forever and is very stable. On the other hand, the high-level interface is incomplete. I too often find myself having to dig down into the lower layers to make raw API calls because there's no high-level wrapper provided for them. -- RoySmith(talk)17:20, 2 January 2020 (UTC)
Cannot find hatnotes displayed anywhere in iOS app
I have the Wikipedia iOS app on my phone. Hatnotes are entirely missing now. They used to be below the lede. Before I do things like create a Phabricator account and read scores of pages of documentation, my question here is, do others have this problem too? I hope no one wiped them out intentionally. If the latter is true then the justification has to be explained at Wikipedia talk:Hatnote. Quercus solaris (talk) 04:10, 28 December 2019 (UTC)
The general process is to login to Phabricator (login page here) using the same username/password you use for the wiki. Then go to the particular task page (i.e. phab:T240721), where you can add a comment in the text box near the bottom of the page, then click Submit. Just explain, like you did above, why you feel this needs a higher priority. The folks who work on these things may or may not change the priority, but that's the process to let your voice be heard. If you prefer, ping me and I can handle it for you. -- RoySmith(talk)19:05, 28 December 2019 (UTC)
Hello, I am now trying to run my bot task PearBOT 5 which is supposed to check every biography and add an automatically generated short description to all of them. The description generation is working great, but now that the edit count has been increased I'm running into problems with the page generator (pywikibot.pagegenerators.SearchPageGenerator('incategory:"Living people" -incategory:"Articles with short description"')), which only supply a few thousand pages leading to the bot terminating early. Does anyone have a solution that will work for page lists on the order of a million articles? My full up to date code can be found at PAWS. ‑‑Trialpears (talk) 22:38, 2 January 2020 (UTC)
If you don't mind a little copying and pasting, and if the bot can work from a text-based list instead of a query, you can try Petscan. HTML output is limited to 10,000 results, but another format might be able to give you more results on a single page. Even if you can get the output to 100,000 at a time, that's fewer than ten bot runs. – Jonesey95 (talk) 23:32, 2 January 2020 (UTC)
@Trialpears: I suppose the problem is that your code uses SearchPageGenerator which relies on the search engine, and that probably has no intention of listing more than a few thousand pages. Here is an extract from a program I wrote a long time ago. I never tried it on a category with almost a million entries, but I believe it is (or was) the approved way to iterate a category in Pywikibot.
defpage_from_category(self,categoryname,want_subcats,namespaces=None):""" Return a generator that yields Page objects, for each page in given category, and optionally, subcategories. """cat=pywikibot.Category(pywikibot.Link('Category:'+categoryname,self.site))returnpagegenerators.CategorizedPageGenerator(cat,recurse=want_subcats,namespaces=namespaces)# Generator to get all pages in a category.gen=page_from_category(self.categoryname,self.want_subcats,namespaces=self.namespaces)
The above is rearranged from my actual code so there may be a blunder (and there are missing items such as self.site) but it should provide the idea. Johnuniq (talk) 02:46, 3 January 2020 (UTC)
Following on what Johnuniq suggested, you might consider replacing everything from savecounter = 0 on with
# License: MITdefcategory_filter(generator,category):""" Filter memebers of the specified category out of the generator. @param generator: Generator to filter @type generator: iterator @param category: Category to filter out @type category: L{pywikibot.pgae.Category} """forpageingenerator:ifcategorynotinpage.categories():yieldpageliving_people_cat=pywikibot.Category(site,'Living people')sd_article_cat=pywikibot.Category(site,'Articles with short description')gen=pagegenerators.CategorizedPageGenerator(living_people_cat)gen=category_filter(gen,sd_article_cat)gen=pagegenerators.PreloadingGenerator(gen)savecounter=0forpageingen:sd=extractdescription(extractfirst(page.text))ifnotsdor'short description'inpage.text:# Is the second condition necessary?continuedescription="{{short description|"+sd+"|bot=PearBOT 5}}\n"page.text=description+page.textsavecounter+=1page.save('Adding automatically generated short description. For more information see [[Wikipedia:Bots/Requests for approval/PearBOT 5]]')ifsavecounter==10000:break
Thanks! I've been running with this code for a few hours now and it's working wonderfully! It also has a useful start parameter in case I have to terminate it which will probably help a lot. Thanks all of you! ‑‑Trialpears (talk) 23:17, 3 January 2020 (UTC)
Thatoneweirdwikier: It might help if you share what browser and skin you're using, as well as the exact URL you are trying to access. It would also help if you could be more specific about "isn't loading". Is the page completely blank? Does it say "No changes during the given period match these criteria."? Do you see a spinner? It would also be good if you can open your browser console (should be f12 in most browsers) and paste the warnings (yellow) and errors (red) here. Nirmos (talk) 11:56, 2 January 2020 (UTC)
Nirmos, I use Safari on the latest version of MacOS (Catalina, 10.15.2). The URL I'm trying to access is here. The screen does not go blank; rather, it freezes on the current page I am on. No spinner either. I've pasted the 1 error and 3 warnings I was presented with below. I can't seem to find a skin, unfortunately.
Failed to set referrer policy: The value 'origin-when-crossorigin' is not one of 'no-referrer', 'no-referrer-when-downgrade', 'same-origin', 'origin', 'strict-origin', 'origin-when-cross-origin', 'strict-origin-when-cross-origin' or 'unsafe-url'.
load.php:144:175
This page is using the deprecated ResourceLoader module "jquery.tipsy".
load.php:155:710
This page is using the deprecated ResourceLoader module "jquery.ui".
What I will say is that I use Twinkle, so I can't use it to revert vandalism if the tab is exclusively available logged out. Just saying, because people seem to have forgotten about this issue. Thanks, ThatoneweirdwikierSay hi19:00, 3 January 2020 (UTC)
Thatoneweirdwikier: I don't think anyone has forgotten about it. It's just a very tricky problem to solve. You say that it doesn't work in safemode, which means it isn't related to any personal or site-wide CSS or JavaScript. You also say that it does work while logged out, meaning the problem isn't related to Safari. It sounds to me, then, that the problem could be with non-gadget preferences. I'm grasping at straws here, but let's say that you have set the values for "Days to show in recent changes" and/or "Number of edits to show in recent changes, page histories, and in logs, by default" at Special:Preferences#mw-prefsection-rc to some absurdly large values, and then the part of MediaWiki that is supposed to lower too high values to the max allowed values conveniently stopped working. Unlikely? Sure. But it actually does fit the information given above (does not work in safemode but does work logged out). It would also explain why no one else has encountered this. Nirmos (talk) 02:00, 4 January 2020 (UTC)
@DannyS712:, that's weird. I checked the link before I posted to verify it took me to the error message. There were several but here are a couple:"Warning: mysqli_connect(): (HY000/2002): No route to host in /mnt/nfs/labstore-secondary-tools-project/iabot/public_html/Includes/session.php on line 88" and "Warning: mysqli_query() expects parameter 1 to be mysqli, boolean given in /mnt/nfs/labstore-secondary-tools-project/iabot/public_html/Includes/session.php on line 94". Anyway, it looks like it did something so maybe just fluke? S0091 (talk) 19:04, 4 January 2020 (UTC)
Need a LUA person for something (probably) pretty simple
In Module:JCW, in the p.selected section, there's a rather ugly way of dealing with up to 5 parameters named |doi1=/|doi2=/|doi3=/|doi4=/|doi5=. If someone could generalized this to an arbitrary number of parameters (|doin=), that would be great. Headbomb {t · c · p · b}00:53, 5 January 2020 (UTC)
locali=1-- an indexer variablelocaldoi_index='doi'-- the base indexerwhilen.doi_indexdo-- first time this evaluates n.doi; after that, n.doi1, n.doi2, ...localdoi=n[doi_index]-- local variable so we don't have to recalculate the index every time through the loopifdoithen-- if n.doi_index has a value make this text stringtext=text..string.format("\n** <code>\{\{doi\|[https://wiki.riteme.site/w/index.php?sort=relevance&title=Special%%3ASearch&profile=advanced&fulltext=1&advancedSearch-current={}&ns0=1&ns118=1&search=insource%%3A%%2F%s%%5C%%2F%%20*%%2F %s]\}\}<\/code>",doi,doi)text=mw.ustring.gsub(text,"%%2F10%.(%d)","\/10\\.%1")elsebreak-- presumes that n.doi1, n.doi2, ... are monotonically increasing without gaps so when a nil value found, we're doneenddoi_index='doi'..i-- first time here its n.doi -> n.doi1i=i+1-- bump the indexer for next timeend
Get rid of the doi=n.doi, doi1=n.doi1 stuff and the six versions of the if doi etc
This can be simplified if |doi= is the same as |doi1=
When I search for "Hillstreet Blues", I do get results for "Hillstreet Blues", but the message above the three results reads "Showing results for hill street blues. Search instead for Hillstreet Blues." This seems wrong. Should it not read "Showing results for Hillstreet Blues. Search instead for hill street blues."? --Bensin (talk) 22:55, 30 December 2019 (UTC)
Bensin, looks proper to me. It's the same as Google really; search "whatver" and you'll get
Showing results for whatever
Search instead for whatver
But as Bensin said, that's not what it actually does. It behaves like if Google did show results for "whatver" from the start. The search is Special:Search/Hillstreet Blues. The message is MediaWiki:Search-rewritten, documented at translatewiki:MediaWiki:Search-rewritten/qqq. We use the default message. It's only meant to be shown when the search is not what the user entered. Something is wrong but the error appears to be that the wrong search results are shown. It should have shown search results for hill street blues as it incorrectly claims to be doing. PrimeHunter (talk) 23:38, 30 December 2019 (UTC)
PrimeHunter, OK, I'm following you now. I'm not sure however if it's showing incorrect results or if it's simply detecting the results because they're so similar - try Special:Search/Gargae and you'll get
Showing results for garage. Search instead for gargae.
In that example it behaves correctly and shows results for "garage" as it says. If you click "Gargae" in the message then you get no results. In Bensin's example, you get the same three results as originally if you click "Hillstreet Blues", while "hill street blues" gives thousands of results. Maybe the error only happens if there are a few results on the term the search function guesses is wrong. PrimeHunter (talk) 00:09, 31 December 2019 (UTC)
Yes, the error is that the message reads "Showing results for hill street blues." when it is actually showing results matching (and bolding) the word Hillstreet. --Bensin (talk) 08:16, 2 January 2020 (UTC)
Searching for 2020 primaries does something strange. First, there's a warning, "Showing results for 2016 primaries. Search instead for 2020 primaries." Then, it proceeds to give you a screen full of perfectly reasonable results for 2020:
Is it possible to pre-substitute a template before submitting an edit? For example, if I click "Show changes" after I've added {{subst:randomtemplate}} into an article, it will show the actual substituted changes in the preview between the latest revision and my text; however, the code remains as {{subst:randomtemplate}} in the editing textbox. So, is it possible to pre-substitute that template, so that I can continue making edits to the subtitited template results, without having to submit the edit first? -- /Alex/2108:49, 5 January 2020 (UTC)
@Alex 21: I think the options are 1) copy the substituted result from "show changes" or 2) retrieve the parsed substitution separately (eg via api) DannyS712 (talk) 08:50, 5 January 2020 (UTC)
New redirect (undone within 24 hours) irrelevant to article. Is it possible to have it removed?
I'm not sure as to where to go on this one. Simply put, a new user made a unilateral decision to change "Ottoman Ukraine" to "Khan Ukraine" here. I believe this was WP:AGF as they are still new to Wikipedia, and their area of interest is evidently Crimea, Crimean Tartars, and Muslim subject matter in general. The user should have read articles. Had he s/he done so, they would have been aware of the fact that it is written from the Cossack perspective, ergo the WP:QUALIFIER for the WP:TITLE follows the subject of the article. The WP:ES of "... more appropriate name" is, therefore, blatantly incorrect. I know redirects are cheap, but even in principle this is an obscure article and no one is going to be searching for "Khan Ukraine"... and, frankly, it irks me that users have both honestly and dishonestly found their way around playing the system. Thanks, in advance, for any assistance. Iryna Harpy (talk) 05:51, 5 January 2020 (UTC)
@Iryna Harpy: Your first link shows nothing more controversial than a sentence being split - a change to punctuation and capitalisation. But I don't see why any of this is a VPT matter. --Redrose64 🌹 (talk) 10:14, 5 January 2020 (UTC)
To answer the question, it is possible to delete the whole article, and then restore the revisions that do not include the two moves. For the term Khan Ukraine the redirect could be deleted, but perhaps it should just be edited to point to Crimean Khanate.[8] If it was vandalism it could easily be deleted, but it appears not to be. If you think the redirect is misleading, tag it with {{db-r3}}. The place for community discussion on redirects is Wikipedia:Redirects for discussion. Graeme Bartlett (talk) 10:39, 5 January 2020 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
When trying to move a page, if the target title already exists then a warning message is shown. The warning message will now include a link to the target title. [9]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 January. It will be on non-Wikipedia wikis and some Wikipedias from 8 January. It will be on all wikis from 9 January (calendar).
For the past couple days it seems like User:Markhurd/hidetopcontrib.js has not been working. It creates a button to hide all contribs that aren't the current version, and it's really handy. Now, however, it hides everything other than edits which are both not the most recent and new page creations (but no, only show edits that are page creations is not selected). Any ideas? — Rhododendritestalk \\ 23:18, 30 December 2019 (UTC)
@Suffusion of Yellow: Thanks. It does work, but it's different. When hiding pages that are current, Markhurd's script displayed only my most recent edit to the pages that are not current. Your new version shows all edits to those pages. So if I made 100 edits to an article and then someone else made an edit, it would show all 100 of my edits rather than just the most recent. Would this be a trivial fix? — Rhododendritestalk \\ 17:49, 1 January 2020 (UTC)
@Rhododendrites: In both versions, that behavior is controlled by the userHideAllSubsequent=true; line. It looks like you commented it out when you switched to mine. If you leave that in, does my version work the same as the original? Suffusion of Yellow (talk) 18:12, 1 January 2020 (UTC)
Forking is probably better, that user has been inactive for 2+ years so others shouldn't rely on their personal scripts. — xaosfluxTalk21:09, 1 January 2020 (UTC)
Haven't tested since I'm on mobile, but changes seem reasonable — it's a new class and would definitely be better to make use of it. I can check it out more tomorrow. As for the fork/no fork, it's been surprisingly fine; I don't mind making minor changes to support other scripts. IIRC a number of folks used this, so YMMV. ~ Amory(u • t • c)22:01, 1 January 2020 (UTC)
I have a dynamic IP address. Every time I visit Wikipedia now I constantly get a banner along the lines of;
You have a new message (last change).
It is nothing to do with me. Yet it follows me around on every page and will not go away unless I click through some shit most every time I come here. If I do that then the editor it concerns will no longer see it. When they eventually come back, it will probably be with a different IP address anyway. I imagine you think it is targeted at the editor concerned, well, your aim is way off.
Might I suggest that if such messages are deemed by the wise to be wholly indispensable then they come with say a half-hour timeout before being deleted as obsolete? Surely easier than guessing whether a given IP address is static or dynamic. Thank you for respecting my user experience in the same way that you respect your own. 148.252.129.73 (talk) 12:23, 7 January 2020 (UTC)
For some of us, creating an account is not a viable option, in case you had you forgotten why IP editing is allowed in the first place. But thank you for the link. Sadly Phabricator does not extend the same courtesy to IP's, so I can only ask that folks like your good self give it a prod on behalf of folks like myself. 148.252.129.73 (talk) 14:50, 7 January 2020 (UTC)
Part of the problem, I suspect, is that you're using the desktop site over a mobile connection. Mobile web IP users are not shown any sort of indication that they have new talk page messages; see phab:T240889. So the first user to see (and clear) the Orange Bar of Doom is usually not the user we are trying to talk to, but the first desktop user to get reassigned the IP. Suffusion of Yellow (talk) 19:05, 7 January 2020 (UTC)
Wikiloop Battlefield?
Has anyone ever seen this sort of thing before? Wikiloop Battlefield looks like an external edit analysis tool loosely akin to Huggle. Is this a legitimate tool? I'm having trouble understanding why a default edit summary would ask a user to respond or comment on a different website. Also, would the user have to pass their credentials to this site? Thanks, Cyphoidbomb (talk) 18:26, 7 January 2020 (UTC)
The tool is an approved OAuth application, so yes it's legitimate, to answer your first question. In addition, the tool does not make any edits itself as far as I understand, you've to trigger it and click through all the buttons. So I don't see any issue in that regards. I don't see any issue with the edit summary either, but that can be changed if the community has issue with it. – Ammarpad (talk) 19:12, 7 January 2020 (UTC)
Heads up: addition of potentially malicious material to computer security articles
I see that there is a pattern of IP editors adding potentially malicious material to Macro virus and other malware-related articles such as Trojan:Win32/Agent, Xor DDoS and Cydoor, of a sort that might be useful to tech support scammers. Some of it is actually happening in real time: see the history of Macro virus for an almost instant response to my revert.
I've reverted and protected articles and blocked recent spamming IPs, but there seems to have been a lot of this from multiple IPs over a long period of time. Please be aware of this, and report it to the admins' noticeboards if you see it, so we can take appropriate action to stop it in future. -- The Anome (talk) 20:35, 7 January 2020 (UTC)
How to challenge the decision to remove support for insecure browsers?
I believe Wikimedia's decision to remove support for insecure browsers (recently expanded to include browsers that use old versions of HTTPS) amounts to unintentional discrimination against readers on low incomes and readers in developing countries, who might be stuck using 10-year-old second-hand mobile phones that cannot be upgraded. There is a big difference between asking a prosperous person to upgrade their device and asking a homeless person to do so. This may become more of a cause for concern if public libraries move to a "bring your own device" approach instead of supplying computers, which now seems to be happening in some towns. I understand there are concerns about surveillance, but surely someone who cannot afford the necessary equipment to bypass it should be able to decide for themselves if they'd rather be spied on, instead of having Wikimedia decide that it's better to lose access completely?
I do run a proxy service (read-only, no edits allowed) which can fetch requested pages and return them over plain HTTP. But I cannot afford the traffic that may ensue if I advertise this more widely. I believe Wikimedia should re-enable HTTP from their own servers, as a non-default option with suitable warnings and limitations.
Note that the security issues revolve around exploits related to the insecure older protocols. It was the case that where a browser did not support the new protocol, an older one would would be permitted; but this has been exploited to attack systems including WMF's using the old protocols. So the various vendors have reluctantly decided to end all support for the old protocols. So what you are suggesting is the same thing that you are protesting; if the change is not made, anyone who has a newer system (the majority) will become cut off. Hawkeye7(discuss)00:40, 29 December 2019 (UTC)
@Hawkeye7: I think there is at least a case to argue that read-only access shouldn't depend on this (even that read-only access shouldn't depend on encryption at all). — xaosfluxTalk00:44, 29 December 2019 (UTC)
And yes, I know all sorts of reason that can be a bad idea, put perhaps through some sub domain only (e.g. en.insecure.wikipedia.org , which would be added to the global blacklist, and with an insecure banner or the like on every page). — xaosfluxTalk00:52, 29 December 2019 (UTC)
The biggest reasons that this isn't a good idea are censorship and privacy. With strong encryption in place, a person-in-the-middle can only see that you've connected to Wikipedia. They can't see what pages you're reading, which means that they also can't block specific pages or silently modify their content: you either get the same Wikipedia as everyone else or you get no Wikipedia at all. This might not matter to you if you live somewhere where freedom of information is the norm and you aren't concerned about someone looking over your shoulder. It definitely does matter to some people though. Think about the pro-democracy protestor who could be jailed for having the wrong opinions. Think about the people living under a dictatorial regieme that would rather rewrite history than face the past. Think about the officeworker researching an embarassing disease and not wanting anyone else to find out. Think about the closeted gay kid at a school that considers homosexuality to be immoral. By providing access to Wikipedia without strong encryption, we open these people up to real-life harm. They do not have the choice between HTTP and HTTPS, only the choice between safe and dangerous. Providing an insecure version of Wikipedia means providing no secure version of Wikipedia. --AntiCompositeNumber (talk) 02:03, 29 December 2019 (UTC)
I suppose so, but also I suspect that those with enough interest in spying will know how to get around the protection. Are WMF servers completely hack-proof? Against an attack by, say, China? If the servers aren't completely protected, then TLS doesn't help. There is a story about someone in Stanford from Tibet, who Google notified that her gmail account had been hacked. Then later, Google found out that her gmail account had not been attacked, but the whole gmail server system, just to get to this one person's mail. Since WMF doesn't normally have credit card numbers or SSNs, maybe it isn't the same as some breeches, but do they notify us when it happens? Gah4 (talk) 21:19, 7 January 2020 (UTC)
But, the choice is still there for readers, so long as mirrors still allow plain HTTP connections. And I'm sure some mirrors are operated by people far less well-meaning than Silas S. Brown. None are subject to our privacy policy. That's a far worse option than any WMF-controlled site. Suffusion of Yellow (talk) 02:37, 29 December 2019 (UTC)
@Xaosflux: Yes, on the surface that looks like the least bad solution. I wonder if it would be possible, using HSTS, to block only browsers capable of accessing the "secure" site from even sending requests to the "insecure" site. Suffusion of Yellow (talk) 03:01, 29 December 2019 (UTC)
@AntiCompositeNumber: good points indeed - and I'm not saying this is necessarily a good idea - just that it is a feasible argument. As far as your scenarios go, it has become quite common for your "officeworker" scenario to already be exposed, either though client-side inspection, or forced MITM corporate proxies. Nation-states have begun using forced decryption as well (c.f. Kazakhstan man-in-the-middle attack). The down side is that the choice (including the problem introduced by the original poster) is really between a secure (with the above forced MITM caveats) wikipedia and no wikipedia. — xaosfluxTalk02:41, 29 December 2019 (UTC)
There's nothing we can do for security when the attacker controls the endpoint device, like in a corporate traffic inspection scenario. While those tools do exist, they don't exist everywhere. They require higher technical competence and more upkeep than a passive inspection tool, putting them out of reach of many organizations. If that example's still problematic, replace "officeworker" with "person" and "anyone else" with "the advertisers your ISP might sell your browsing history to" [10]. When a security system fails, it should fail loudly. No matter how many scary warnings you put on something that's insecure, if people can ignore them, they will [11]. You can't ignore a completely inaccessable site though. I don't have numbers about how many people are still connecting to Wikipedia using TLS 1.0, but the WMF typically doesn't deprecate a browser unless it accounts for less than 1% of average total traffic. We're not the first to disallow TLS 1.0 connections, websites like nist.gov, gizmodo.com, un.org, nytimes.com, twitter.com, state.gov, github.com, any site that process payment card information... got there first. The choice between protecting our most vulnerable readers from harm or continuing to support browsers and devices with dwindling usage and an already degraded internet experience. --AntiCompositeNumber (talk) 04:05, 29 December 2019 (UTC)
I suppose even a really old browser could run TLS-in-JS. I have no idea if this is actually a practical solution, i.e. would it be so slow as to be unusable, but it's an interesting idea. -- RoySmith(talk)03:40, 29 December 2019 (UTC)
That depends on how you define a "really old browser" (first ones doesn't even supported JS). You can browse in any browser by using Nginx (or something similar [like Fiddler] for http/https conversion) (+ Privoxy [for old browsers without proxy support] for request/response/html rewrite, or by Nginx packaged with Lua [under Windows]). MarMi wiki (talk) 18:16, 29 December 2019 (UTC)
I think the Wikimedia Foundation should write a version of their app that allows older devices to connect by providing their own tls version support. Or they can pressure phone manufacturers to patch their operating systems. Discriminating against the poor just because they have old devices go against Jimbo Wales' quote "i'm doing this for a child in Africa". Poor people need open knowledge the most. 2A01:4C8:F:E3D9:2B73:C9CA:12CF:BCA2 (talk) 19:10, 30 December 2019 (UTC)
I guess my question is about the "Файл" part of the URL. Is that useful information? It did not seem that pasting it instead of File: worked. Maury Markowitz (talk) 16:07, 8 January 2020 (UTC)
Also "File" is available on all projects, as it is the canonical name, you can also use local namespace names but they only work on local projects. — xaosfluxTalk16:18, 8 January 2020 (UTC)
But if I use "Файл" instead of "File", that will not make it link to another project, right? It will either not work, or link to the local project? Maury Markowitz (talk) 17:45, 8 January 2020 (UTC)
You cannot embed (for display) images from one language's wiki on another...only from images on the local wiki itself and from commons. DMacks (talk) 18:24, 8 January 2020 (UTC)
(After a triple ec) @Maury Markowitz: IMVHO the problem is that you are not asking about what you want to know. You ask about linking to an image whilst I suspect you want to embed an image in a wiki page. Linking works fine as you can test yourself - just click the image you've put in your question. You can also link with a wikilink like this:
However, if you want to embed an image, you need it either be uploaded locally to the specific Wikipedia or to the common repositiory at Commons. --CiaPan (talk) 18:36, 8 January 2020 (UTC)
@CiaPan: in this example case though, the image is not on w:ru, it is on commons: (the shared repository) as well, those arean't really linking "to the image" at all, it is linking to a local image "description". — xaosfluxTalk18:46, 8 January 2020 (UTC)
@Coffeeandcrumbs: can you explain a bit more? It seems like this may be some sort of vandalism? Is it ongoing? If so can you show a recent diff of it occuring, an edit filter may be able to prevent it. If it is all old, a bot request could possibly be used to remove it. — xaosfluxTalk14:49, 8 January 2020 (UTC)
It is a by-product of the Visual Editors features. It is ongoing. You can recreate the situation yourself by choosing any Bloomberg article and using the Visual Editors automatic citation template creation feature. As most new editors are not aware of proper creation of citations, they simply accept the result. --- C&C (Coffeeandcrumbs) 15:03, 8 January 2020 (UTC)
Diff 1 (30 December 2019, with Visual Editor). Diff 2 (3 February 2019, with reFill). Diff 3 (14 November 2018, with reFill). I don't know if reFill is still accepting these bogus titles, but it shouldn't be hard to test. The good news is that this has been happening for over a year and there are only 700 affected articles. That's only two per day. – Jonesey95 (talk) 15:07, 8 January 2020 (UTC)
Kill reFill/reFill2 with fire. These tools do not have an active maintainer and have, since the beginning, produced many many garbage laden citation templates. Users presume that, because the tool is a tool, its output will be correct. Ha! Because of this presumption, editors don't, or only minimally, check the tool's output before saving the page.
Without an active maintainer, these tools will not magically make better citation templates and will, very likely, make more and more flawed citation template worse. Kill them with fire.
The visual editor is not going to get rid of the feature but the can at least disable it for Bloomberg.com specifically. Only I don't know how to request that they do that. --- C&C (Coffeeandcrumbs) 15:37, 8 January 2020 (UTC)
If you can find someone reliable and qualified to maintain the reFill tools, great; it will not likely be the tools' developer who hasn't been here since July 2019, was not here through all of 2018 (Special:Contributions/Zhaofeng_Li), so whomever you find has to commit to actively working to improve the tools and must be responsive to editor complaints and comments as the original developer was not. Until this maintainer is found, reFill/reFill2 should not be making edits.
Presumably here is someone who is actively working on ve. I think that the correct place to address problems with that tool is through phabricator.
I have filed a Phab task for Citoid before at phab:T210871 but it was not prioritized for work then and has not been worked since.
I would agree with disabling reFill entirely at this point until it is maintained (just like we would with a bot that is making erroneous edits). There is at least one other item I have filed (at Github) regarding |url-status= versus |deadlink= which I believe has also not been fixed.
I don't see it in gadgets, so I assume it is being called predominantly by reference to script. (I do not know if it is hosted here or at Commons--the latter is a problem for us trying to disable it here if so, without forcible removal from multiple user JS locations.) --Izno (talk) 16:07, 8 January 2020 (UTC)
As far the cost/benefit - if this is disabled I expect it will lead to lots of bareurl references being used instead of "richer" references, it could even disuade editors from using references at all - and that sounds like a net loss. — xaosfluxTalk15:52, 8 January 2020 (UTC)
That is not how I understand the reFill / ReFill2 tool use. These tools are intended to fix bare urls so the references, as bare urls, must already be in place. I think that there are other tools (Citation bot?) that can do this work. Citation bot has active maintainers and, I think, I've never used it, is usable by anyone.
We have multiple other reference tools maintained. Citation bot, Citoid, ProveIt, and RefToolbar (and IABot but only for archiving really). One or another will meet someone's need, and I suspect there may be one or two others out there. (I don't really understand how we came to have so many community tools, but there it is.) --Izno (talk) 16:07, 8 January 2020 (UTC)
@Trappist the monk and Izno: here is how I'm invoking this, and with a vanilla account like a new editor would have: Edit a page (source editor even), on the editing toolbar, select "Cite", in the now open citation toolbar selector, pick "Cite Web", a pop-up form comes. I'm not sure where we are invoking that though, it is certainly not a personal user script. — xaosfluxTalk16:20, 8 January 2020 (UTC)
Given the choices between editors putting the dynmaic name of a site, as returned by such site which may play tricks with it; or having them use a bareurl reference - the former sounds better to me. — xaosfluxTalk16:39, 8 January 2020 (UTC)
Xaosflux, only that is not the only problem. It changes the URL as well and the new URL may be even more fleeting than the bare url. I doubt a publication like Bloomberg will fail to redirect URLs that have moved. --- C&C (Coffeeandcrumbs) 16:47, 8 January 2020 (UTC)
@Coffeeandcrumbs: huh? In Special:Diff/934801048 the URL I put in to the box is the URL that was saved to the source, only the "title=" value is "wrong" (though it isn't actually "wrong" - it is actually the dynamically retrieved title, but the title source (bloomber.com in this case) is playing tricks). — xaosfluxTalk17:00, 8 January 2020 (UTC)
Xaosflux, I am more concerned with the result from VE because that is where most of these are coming from. When you do it on VE, it changes the URL as well. In this Special:Diff/934800714, I fed it:
@Coffeeandcrumbs: OK - so the VE automatic citation tool is working differently from the source editor automatic citation tool; reformating the URL that the editor actually enters sounds like a bad idea in general indeed, is this also coming from off-wiki? — xaosfluxTalk19:42, 8 January 2020 (UTC)
I'm trying to determine where the configuration that VE is using for this is coming from - is it a gadget, some other config, etc? — xaosfluxTalk21:48, 8 January 2020 (UTC)
I've added the basic layout and subpages. You still have to create/re-organize the remaining pages and redlinks. – Ammarpad (talk) 06:15, 8 January 2020 (UTC)
Talk:Ferdinand Marcos has archives 1, 5, 6, and 7 (for example: Talk:Ferdinand Marcos/Archive 7, but archives 5 - 7 are not shown on top of the talkpage for some reason. Maybe a problem with OneClick archiving or some parameter/syntax problem with the gap in archive numbers, I am not entirely sure. Could someone more knowledgeable with archive parameters check this minor issue please? Many thanks for any help. GermanJoe (talk) 08:15, 9 January 2020 (UTC)
Pretty sure it's simply because the request to Lowercase sigmabot III to archive the talk in this edit erroneously had the counter set to 5 when it should have been 1 or 2. I've moved archives 5–7 to 2–4 and filed the remaining redirects for SD, so it'll all be fine. Nardog (talk) 08:41, 9 January 2020 (UTC)
Foreign language external link categories
Hello,
Right now, we have quite a few categories featuring foreign language external links appearing to be empty. But, then, they aren't empty.
I was tagging these empty categories for CSD C1 deletion but this is just too many categories of one certain type all of a sudden becoming empty to be real and accurate. There must be some technical problem. I'll stop tagging them and ask if someone can provide an explanation and "fix" this. Thank you. LizRead!Talk!02:25, 9 January 2020 (UTC)
Well, I thought there must be some technical explanation. The situation has already unfortunately led to the deletion of a few external links categories over the past couple of weeks but they can easily be restored once this problem is resolved. LizRead!Talk!07:03, 9 January 2020 (UTC)
Monkbot/task 15 was approved 8 December 2019 so for the past month has been replacing the variety of templates that use {{link language}} with {{in lang}}. These <language name>-external link categories are populated by {{link language}}. Without any transclusions of that template, no articles will populate the <language name>-external link categories. {{in lang}} uses a new category structure based at Category:Articles with non-English-language sources – a name change because not all of these templates are, in articles, associated with sources that are links.
I see no reason why these <language name>-external link categories should not be deleted. However, the templates that call {{link language}} still exist and editors have not yet unlearned their old habits so until the templates are deleted (see Wikipedia:Templates for discussion/Holding cell § To review), articles will be sporadically added to these categories – redlinked categories recreated by well intentioned editors will be an extension (and complication) of this problem.
If code in a template categorises pages that transclude that template, and the template is amended so that the categorisation changes, pages that transclude the template should be placed in the job queue for their cats to be updated. It's been the case for a few years now that these job queue tasks are either processed slowly, incompletely, or not at all. This results in discrepancies between pages and categories.
When a page shows a category name at the bottom, but the category itself does not list the page, go to the page concerned and WP:NULLEDIT. Similarly, if a category lists a page but the page itself does not show the category at the bottom, NULLEDIT the page. A null edit refreshes the link tables so that the association (or not) between category and page are synchronised.
To fix all such pages, use "what links here" for the template concerned, setting it to display transclusions but not links or redirs. Then for every page listed, perform a null edit. --Redrose64 🌹 (talk) 20:56, 9 January 2020 (UTC)
Old versions in peach
Editing an old version from Xaosflux
`
Referring to this question, I am back at the library for the first time since the last response.
On an article where I needed to see a diff to know where to edit, I almost edited an old version. The warning is in peach. However, the normal pink color is used for the warning that only certain people can edit the article. What needs to be fixed?— Vchimpanzee • talk • contributions • 19:46, 7 January 2020 (UTC)
That box is the standard warning box color, its background is #FEF6E7. It used to be pinker, but was changed to meet the standard layout colors (c.f. MediaWiki_talk:Editingold#Remove_pink_background) as manually coloring it was causing it to have a pink box inside of that FEF6E7 box and it didn't look very nice. — xaosfluxTalk21:02, 7 January 2020 (UTC)
As mentioned in that thread, we could recolor only this box but someone will need to make a software enhancement to have it include a different selector first. — xaosfluxTalk21:04, 7 January 2020 (UTC)
I suspect that what is happening here is that the two monitors involved have their controls set differently - any one or more of brightness, contrast, hue and saturation will be a factor. Ambient light will also affect how colours on a screen are perceived. --Redrose64 🌹 (talk) 13:43, 8 January 2020 (UTC)
I'm at another library and the warning is most definitely a shade of orange. It is possible at the other library it was pink and just seemed orange, but this is orange.— Vchimpanzee • talk • contributions • 14:36, 8 January 2020 (UTC)
OK, it may just be some monitor settings. For reference:
THIS IS PEACH => ███████████████Color as background
THIS IS THE BOX COLOR => ███████████████Color as background
THIS IS ORANGE => ███████████████Color as background
I forgot to mention viewing angle in my post above, but glare is an extreme case of ambient light. Different monitor technologies (LCD, plasma, LED, CRT etc.) may also behave differently. --Redrose64 🌹 (talk) 21:01, 9 January 2020 (UTC)
Has anybody encountered this strange syntax before? What does [[{{ns:Category}}:Line-handling templates]] do that [[Category:Line-handling templates]] doesn't? Milker (talk·contribs) has been doing this on a large number of pages in the last few days. I have asked at their talk page - which has an incredibly low traffic rate, mine was the first edit in over ten years. --Redrose64 🌹 (talk) 22:52, 9 January 2020 (UTC)
Nothing as used here, but if you have say a template linking to categories on various language wikis {{subst:ns:Category}} would use the local alias (Kategori: for Swedish, Categoría: for Spanish etc.) for the category namespace instead of the universal Category: prefix. ‑‑Trialpears (talk) 23:13, 9 January 2020 (UTC)
So, since (i) this is the English Wikipedia, and (ii) the namespace Category: works on all Wikis regardless of the local language, can we say that Milker's changes are pointless and perhaps should be discouraged? --Redrose64 🌹 (talk) 23:43, 9 January 2020 (UTC)
At the least it means that expression is getting reevaluated on each save, it is useless and will interfere with things like category change bots so should not be used at all. — xaosfluxTalk00:25, 10 January 2020 (UTC)
Please revert them all. I suppose you could wait for a few more hours to see if there is a reply to your question at User talk:Milker, but I'm confident the syntax should not be used. Apart from anything else, adding this would lead to an avalanche of people copying the misguided edit thinking they were doing something useful when in fact it just adds confusion. Johnuniq (talk) 02:32, 10 January 2020 (UTC)
I agree that this is a bad idea. It will mess up a load of tools suchs as hotcat, catalot, and most bots ... with no evident benefit to offset the downsides.
Yeah, I dropped this note and went through their contribs for the last week. Whilst doing this, I noticed that they seem to take extended wikibreaks every now and then, with only 13 edits in the ten years ending 31 December 2019. --Redrose64 🌹 (talk) 16:28, 10 January 2020 (UTC)
Just guessing, but based off the user's contributions, is there a chance they were part of the Education Program? Did removing that leave weird log entries? ~ Amory(u • t • c)03:38, 7 January 2020 (UTC)
Is there any tool, script, or bot that exists that can mass move pages from one name to another based on a simple regex? I'm still waiting on consensus but we've found a good 100-200 pages in our Video games wikiproject that were created with not the best title , eg 2019 in video gaming that we are considering moving to 2019 in video games. We'd want to leave redirects behind, of course, and move talk pages over. I know I can request a bot but I'd wanted to see if there's something less needy? for this. I have AWB but I'm not aware of this being a function either. --Masem (t) 01:05, 11 January 2020 (UTC)
Since the number of pages to move is relatively small, this can easily be done with AWB. The number is indeed too small for a bot. (In comparison, TheSandBot was used to move ~35 thousand pages). AWB can mass move pages, you can ask for more info on how to do it at the tool's page or make a request at Wikipedia:AutoWikiBrowser/Tasks for someone to do it when you're ready. – Ammarpad (talk) 03:44, 11 January 2020 (UTC)
The page stats don't seem to reflect an obvious dip in page watchers, but I can't imagine why I would have unwatchlisted most of these. Am I just imagining things? Mark Schierbecker (talk) 08:52, 11 January 2020 (UTC)
Hi! It is very (very!) rare that I try to review pending changes. The last couple of times I tried, when hitting the "Accept revision" button I got a message saying I do not have permission to do it, which is odd, because I am an administrator. Even stranger, I hit the button a second, and then a third time. The second to read the message better (it disappears too fast, at least for a non-native speaker), the third trying to get a screen shot to show here but... by the third time it worked! Any idea on what is going on? Am I doing anything wrong? Is it a glitch? (using Vivaldi (web browser) 2.8, over Linux openSUSE 42.2 (I think) - Nabla (talk) 21:43, 10 January 2020 (UTC)
My twinkle didn't work on my PC. I use the latest version of Microsoft Edge and Google Chrome. What should I do? Thanks. Dede2008 (talk) 07:15, 10 January 2020 (UTC)
Hey all, at Template:Infobox YouTube personality, I'm unclear (and the talk page also indicates confusion from others) on how to properly use the |channel_name= parameter.
I was at Bhuvan Bam and wanted to add a link to his YouTube channel in the infobox. The |channel_name= parameter wants us to add a URL formatted like www.youtube.com/user/channel_name. However his channel URL appears to be formatted like https://www.youtube.com/channel/UCqwUrj10mAEsqezcItqvwEw. I surmise that YouTube changed the structures of their URL. Can someone please look into this? Should both formats be usable? This is out of my league. Much appreciated, Cyphoidbomb (talk) 20:16, 11 January 2020 (UTC)
@Cyphoidbomb: For channels where the URL is structured like "/channel/xxx", you can use the |channel_url= parameter instead. There is also a channel direct URL parameter which is basically the whole URL. --qedk (t桜c)13:28, 13 January 2020 (UTC)
Could anyone tell me if the video embedded here is viewable on most browsers? I was able to view this video in the past at Tourette syndrome, but I am unable to view it now on any of my devices, so am considering whether to delete it? Thanks in advance, SandyGeorgia (Talk) 14:58, 13 January 2020 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
You can no longer read Wikimedia wikis if your browser use very old TLS. This is because it is a security problem for everyone. It can lead to downgrade attacks. Since 9 December you just see a warning. Soon the browser will not connect to the wikis at all. Most are users on Android systems older than 4.4. You can read the browser recommendations. [15]
Wikis can protect pages so that only some users can edit them. The standard protection levels are Require autoconfirmed or confirmed access and Require administrator access. If your wiki use more protection levels the technical name might be renamed for standardisation. This doesn't affect what users see. [17]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 January. It will be on non-Wikipedia wikis and some Wikipedias from 15 January. It will be on all wikis from 16 January (calendar).
Future changes
Deepcat and Catgraph will stop working. This will happen at the end of January. This is because you can now use the normal search function instead. [18]
You can use <ref follow="…"> to merge footnotes that follow each other. It is meant to be used for digitised books on Wikisource. If the order of the footnotes is wrong no error was shown but the bad <ref> was shown outside the <references /> list. This will change and you will see an error message instead. [19]
@Interstellarity: XTools counts revisions made by you, going directly off of the database. The system edit count (the one in your preferences) is a running tally that increments with only certain types of edits. For instance, it counts page moves, but it didn't use to. For this reason I generally consider the system edit count to be approximate, at least for older accounts. — MusikAnimaltalk18:51, 13 January 2020 (UTC)
It will be run for various 'cohorts' based on number of edits (simply to stop them timing out). The purpose of the list generated is to get a filtered list of editors that might be good people to invite to join WP:NPR.
I'd like to add a couple more criteria for additional filtering:
X edits to Wikipedia: namespace in the last N days (like 100 in the last 6 months or something).
X edits to mainspace in the last N days.
X edits to other people's talk pages in the last N days.
You're already querying revision for a count of recent edits. Just add another subquery joining page on page_id=rev_page; that gets you a namespace (WP:Namespaces for the list) and a title. —Cryptic00:22, 13 January 2020 (UTC)
AND(SELECTCOUNT(*)FROMrevision_userindexJOINpageONpage_id=rev_pageWHERErev_actor=actor_idANDrev_timestamp>=/* whatever */ANDpage_namespace=0-- mainspace, from [[WP:Namespaces]]LIMIT/* X */)>=/* X */
Someone else's talk page:
AND(SELECTCOUNT(*)FROMrevision_userindexJOINpageONpage_id=rev_pageWHERErev_actor=actor_idANDrev_timestamp>=/* whatever */ANDpage_namespace=3-- User talk:, from [[WP:Namespaces]]ANDpage_title!=REPLACE(user_name,' ','_')-- user_name has spaces; page_title expects them to be underscoresLIMIT/* X */)>=/* X */
Also, the LIMIT's in that query aren't really accomplishing anything - the database is still going to count all matching rows instead of stopping after 500 or whatever, which is why it's so slow. You'd want something like
This tool identified nonfree images included in BLPs and enabled convenient review of those uses. Over the last two years I used it to remove several thousand NFC policy violations, more than 99% noncontroversially, and I wasn't the only editor who apparently used the tool. The tool was active and functioning properly as recently as January 5. I simply lack the technical competence to even attempt to rectify the problem. Could someone with the required skills take a look at this? Is there a convenient way to generate an equivalent tool? Thanks very much. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by many administrators since 2006. Fight for freedom, stand with Hong Kong! (talk) 18:54, 8 January 2020 (UTC)
From what I understand, the warning is thrown to alert editors that their code will supersede more specific CSS declarations used which normally is not advisable (since the "correct" way to handle it would be to modify the more specific CSS declarations directly). This is especially important when editing the page-wide theme css file because it can potentially destroy the site for everyone. However, for user-specific stylesheets !important is in most cases needed because the point is to modify the interface despite the more specific declarations, so it shouldn't be a problem (unless you add something like body { display:none !important; }that hides everything ). Regards SoWhy10:53, 15 January 2020 (UTC)
The !important annotation is a cop-out: once it's been used for a particular property, it's then very difficult to override that declaration with another rule unless the declaration in that other rule also uses !important. There are no levels of importance. It's normally better to forget about !important and instead increase the specificity of the selector. --Redrose64 🌹 (talk) 11:49, 15 January 2020 (UTC)
Possibly but there are cases in which increasing the specificity of the selector is not possible or feasible. For example, I find text-shadows extremely annoying, no matter where they are used but I cannot know where they might be used, so I included a blanket hiding element in my css to handle that. Which needs !important to work. Regards SoWhy12:06, 15 January 2020 (UTC)
You have two copies of the .citation-comment {display: inline !important;}. Because there are no hidden cs1|2 error messages, both of those can go away. If you wish to hide all cs1|2 error message or wish to see the maintenance messages, see Help:CS1 errors § Controlling error message display.
@Jo-Jo Eumerus: so short answer: no its not a problem. Long answer see above, if you were writing scripts designed to be used by others this is something worth looking to avoid, for something that is only ever for yourself just keep in mind that "!important" means just that - this rule is more important then what anyone else thinks! — xaosfluxTalk12:12, 15 January 2020 (UTC)
Article watchlist bouncing in Safari on iPad, but not user watchlist
Issue: difficultly determining blocks in /64 range for IPv6
Description:
I was poking around WP:ADMINTOOLS and WP:TOOLS and was wondering if there were any gadgets or features to allow admins or anyone to view block logs of all IPv6s in a /64 range. Currently, you can view the block log for a single IPv6 or the block log for the whole range. The difficulty is that sometimes individual IPs get blocked, but they quickly hop up a new IP in the /64 range and it can appear the IP has no record of troublemaking.
I'd love to see some treasure that lets me quickly see all blocks in a range and even all warnings on talk pages to better assist with the wackamole. Any current tools do this? EvergreenFir(talk)06:22, 14 January 2020 (UTC)
Hmm. I have two /64 nets for my home (actually a /60 delegated from Comcast). So yes, if I had a blocked IP, I could go to a different computer at home and use that. But also ISPs like Comcast will delegate addresses from their own /64 among unrelated customers. It might be that there is a range of addresses for delegating subnets and a range for internal use. You might find two unrelated blocked IPs from the same /64. Gah4 (talk) 06:35, 14 January 2020 (UTC)
You could look at the range contributions and look at the block logs of each IP (reasonably quick with popups). I know that's kinda hacky but most residential /64's are sparsely used.--Jasper Deng(talk)06:40, 14 January 2020 (UTC)
I don't know how ISPs do it, but I suspect so. On the other hand, if I really use all 16 of the /64s delegated to me, you will have a harder time finding me. But also, I don't know the distribution of WP users. What fraction of people ever edit a page? Gah4 (talk) 06:53, 14 January 2020 (UTC)
If you view contributions for the range with the mark blocked users gadget enabled, wouldn't any individually blocked IPs in the range show up as blocked? I might be misunderstanding what you're asking for, but for a purely visual cue I think that'd do it. ~ Amory(u • t • c)10:57, 14 January 2020 (UTC)
Like Black Kite, I use that gadget as well but as Jasper says I'm interested in past blocks as well. Also for cases with hundreds of edits on a range, the gadget only works as much as you're willing to dig through. EvergreenFir(talk)12:16, 14 January 2020 (UTC)
One approach for anyone wanting to write a script/tool for this would be to use API:Usercontribs to first get the range contributions. Then for every distinct IP address in the result, use API:Logevents to get its block log, and API:Parse to get the content of its talk page. Present all the output on a single page. SD0001 (talk) 07:20, 15 January 2020 (UTC)
This is perhaps a little off-topic, but has there ever been a discussion to add a simple function to the User Contributions page to show all edits made on the /64 range? It seems such a logical tool to offer, and I'm surprised by its absence. Fiddling with urls on a tiny mobile in order to do this is not easy.Nick Moyes (talk) 10:05, 15 January 2020 (UTC)
Thanks, Izno. I do know how to do that, having learnt the trick recently, but it's hardly elegant and darned near impossible to add /64 onto the end of a url whilst on a mobile. You try monitoring Recent Changes for a couple of hours and wanting to check the /64 range contributions of all those IPv6 vandals you've been reverting. Now, if only there were a little obvious button on that page I could tap or click..! I can't be the only one who can see the value of that, surely? Nick Moyes (talk) 17:00, 15 January 2020 (UTC)
With partial blocks now in place on en-wiki, though some of the less clear use-cases are still having the formal policy written up, does anyone know if Twinkle is being updated to be able to place them? Nosebagbear (talk) 12:13, 14 January 2020 (UTC)
I'm hoping to dive into a simple structure soon this week or next, depending on how busy life gets. In the mean time, little things like "what templates should be used?" are important questions that would be helpful to know. ;) ~ Amory(u • t • c)17:42, 15 January 2020 (UTC)
In Conjectures and Refutations: The Growth of Scientific Knowledge, 1963, by Karl Popper.
De mortuis nil nisi bene: once a theory is refuted, its empirical character is secure and shines without blemish.[1]
Notes
^ Popper, Karl (1963). Conjectures and Refutations: The Growth of Scientific Knowledge (2002 ed.). London: Routledge. ISBN978-0-415-28594-0. {{cite book}}: Invalid |ref=harv (help)
I cannot preview the Notes anymore. I can save it, but cannot preview. I can preview and save if I edit the whole article, but if I edit the Notes only, I cannot preview, only save. The same thing happened in another article. I like to not put notes inline. I feel that it clutters the text and it's less easy for others to edit.
Thanks. It's funny: one can even check the bug here by editing Notes above and trying to preview it. It has to be Notes. If you edit the whole subject, there is no issue. Dominic Mayers (talk) 22:14, 12 January 2020 (UTC)
I presume that you are referring to {{cite interview}}. Pretty sure that you are mistaken:
{{cite interview |interviewer-last=Fairbairn |interviewer-first=Doug |interviewer-last2=Diamond |interviewer-first2=Sephen L |last=Peddle |first=Chuck |title=Chuck Peddle Oral History |work=Computer History Museum |via=YouTube |date=12 June 2014 |url=https://www.youtube.com/watch?v=enHF9lMseP8}}
Peddle, Chuck (12 June 2014). "Chuck Peddle Oral History". Computer History Museum (Interview). Interviewed by Fairbairn, Doug; Diamond, Sephen L – via YouTube.
When you are having problems with the cs1|2 templates, the best place to discuss those problems is at the link you provided above: Help talk:Citation Style 1.
The documentation needs to be updated. |interviewer-last=, |interviewer-first=, and their numbered forms, as well as the numbered forms of |interviewer=, are supported. --Izno (talk) 16:05, 15 January 2020 (UTC)
I have updated the documentation based on the documentation for the |author= parameters. Error corrections are welcome. – Jonesey95 (talk) 22:18, 15 January 2020 (UTC)
Hi all, I've filed T242902, though feel free to call me a dummy if I've misunderstood how this works. The nutshell seems to be that admin accounts can be affected by IP autoblocks, despite that theyre supposed to have IP block exemption. Writ Keeper⚇♔19:04, 15 January 2020 (UTC)
Rangeblocked IP not showing up as blocked in edit history
Hi all, I have the Preferences > Gadgets > Appearance > "Strike out usernames that have been blocked" tool turned on. I'm looking at this edit history, and the top couple of IPv6s, 2409:4060:393:6db1::18a:b0, and 2402:3a80:a84:a3cc:0:59:f313:2801 (and maybe more as the sock keeps editing) are not showing up as blocked for me, while the other one right under DMacks' edit is. I applied a /64 rangeblock to those IPs, so maybe that's the cause, but it seems like they should still be marked, in an ideal world. Any thoughts? Thanks, you hard-working people! Cyphoidbomb (talk) 02:47, 16 January 2020 (UTC)
For some odd reason I can't go to the page Polistes versicolor -it won't load. The history, the talk page, as well as the article in other languages, load fine. If I go to history & click on the latest version, these load and I can edit that, but when I save, the page again will not load. But whatever I've done does show up in the history. Very odd. This is the first time I've experienced this, and I only have this problem on that page. Do others have the same? Eh, maybe someone technical should look at it? — Preceding unsigned comment added by Leo Breman (talk • contribs) 2020-01-13T18:05:11 (UTC)
Nope, it still bizarrely won't load ... on Firefox, it works on Chrome. Bypassing cache doesn't seem to help, nor deleting what is in my browser history. The Firefox version is old, but why would only this page not load out of hundreds, if that is the case? Thanks anyway, xaosflux. Leo Breman (talk) 19:31, 13 January 2020 (UTC)
Works for me. Firefox 72.0.1 64-bit version on Windows 7 (yes, I have to upgrade at some point) with a fair bit of RAM and a spindle disk. Walter Görlitz (talk) 17:58, 16 January 2020 (UTC)
RFD templates
Some time ago, I raised the issue that Wikipedia's detection tools for uncategorized pages were erroneously and unnecessarily picking up and listing redirects that had been nominated for deletion, because the nomination template was breaking the page's function as a redirect and causing it to register as an uncategorized article — so to resolve the problem, the regular RFD template was coded to automatically include the nominated redirects in Category:Temporary maintenance holdings so that they would be "categorized" and thereby ignored by the categorization tools. However, I'm now starting to encounter unnecessary redirects on the uncategorized pages tools again — the difference being that instead of the regular {{RfD}} template, these pages are tagged for deletion using {{Rfd-NPF}}.
I've manually added a couple of them to the temporary maintenance category to get them off the list again, but it's still unhelpful and unnecessary kludge that preferably shouldn't even show up in the first place — so I wanted to ask if somebody here who's more knowledgeable about template coding than I am could make sure that the Rfd-NPF template categorizes the pages in Category:Temporary maintenance holdings the same as the regular RFD template does, so that the tagged redirects don't clutter up the categorization tools. Thanks. Bearcat (talk) 22:21, 15 January 2020 (UTC)
Then nominate it for deletion. In the meantime, however, as long as it still exists, it still needs to ensure that it isn't causing RFD-nominated redirects to be erroneously detected as uncategorized articles. Bearcat (talk) 22:46, 15 January 2020 (UTC)
Bearcat, I've added the category to {{Rfd-NPF}}. Regarding Pppery's comments I would totaly agree that these should be merged with the normal version of the template. The code for {{Rfd-NPF}} is completly different from {{RfD}} and is bound to cause more issues in the future. ‑‑Trialpears (talk) 23:44, 15 January 2020 (UTC)
Thanks. Just to be clear, I agree that they should probably just be merged with the regular templates — I'm not an expert in NPP process, but I find it hard to imagine a plausible reason why they would need their own separate templates to do the same things that non-NPP templates already do — my only concern was with the notion that their mergeability or deletability would constitute a reason not to actually address the immediate problem. Bearcat (talk) 18:08, 16 January 2020 (UTC)
(edit conflict)This just came up at Template talk:Infobox bridge. That template imports coordinates from wikidata without checking whether the article already has coordinates (I don't know if it can), and somehow, the article did not appear in an error category for articles with duplicate coordinates (I don't know if there is one). The workaround is to insert coords into Infobox bridge with display=inline. – Jonesey95 (talk) 21:52, 14 January 2020 (UTC)
Is it just me? Win 10, Chrome latest release, pages that MediaWiki renders with syntax highlighting.
Module:Citation/CS1 does not render with syntax highlighting because there is 100k-byte limit (I think). When I click and drag to highlight some code in that rendering, no problem.
Shift to Module:Citation/CS1/Configuration where syntax highlighting is not disabled. Move the mouse cursor over the various elements in the documentation portion of that page and the cursor changes almost instantly as it floats over the plain-text, links, blank space as would be expected. Move over the code, the cursor becomes lethargic, click and drag to highlight some bit of code or text and it takes several seconds for the highlight to appear; mouse cursor is stuck at text-select form until the selection highlights.
Is this just me? Is it some new change to MediaWiki's handling of syntax highlighting? Is it a Chrome problem?
Works fine for me on Linux with Firefox 72. It also worked with Chromium 78, but Chromium 79 has the problem you describe. Anomie⚔12:35, 17 January 2020 (UTC)
FWIW - a draft "ScienceNews template" (see copy below) has been created - a recent suggestion (see comments at "Wikipedia:Reference desk/Science#Is "ScienceNews template" useful - or not?") has been made that the better place to post my concern is on "WP:Village Pump" - the "Technical" section seems the best section to me at the moment (simply because I'm most familiar with this section over the years) - but other VP sections may be even better - QUESTION: Is such a template (or equivalent) useful anywhere on Wikipedia? - Comments Welcome - in any case - Enjoy! :) Drbogdan (talk) 20:05, 14 January 2020 (UTC)
This blog-like thing seems like something that, at best, should be an occasional opt-in newsletter for those interested in receiving it. Its use of external links does not match our usual practice, which could be jarring for some readers. Also, the CAPITAL LETTERS should be toned down to match MOS. I think that Wikipedia:Village pump (idea lab) might be a better home for this discussion, since it doesn't seem that you have a technical question. – Jonesey95 (talk) 21:59, 14 January 2020 (UTC)
NOTE: a new version (hopefully improved to the better Wikipedia standards) of the template has now been created - and, if interested, may be viewed below and/or here => "User:Drbogdan/ScienceFacts" - Thanks again for all the earlier comments - newer Comments Welcome - Enjoy! :) Drbogdan (talk) 16:29, 17 January 2020 (UTC)
^Bogdan, Dr. Dennis (February 16, 2020). "The one particular chemical is Nucleic Acid - a basic chemical for all known life forms - in the form of DNA - and/or - RNA - that defines - by way of a particular genetic code sequence - all the astronomically diverse known life forms on Earth - all such known life forms are essentially a variation of this particular Nucleic Acid chemical that, at a very basic level, has been uniquely coded for a specific known life form". Dr. Dennis Bogdan.
I just changed the article on Tim Tolkien to put the italic markup for The Sentinel outside the piped wiki-link, instead of inside. This fixed an issue where the pop-up showed <em> tags around the link. Is this a known bug? All the best: RichFarmbrough, the apparently calm and reasonable, 13:45, 17 January 2020 (UTC).
The function of interest is parse_inline_formatting(str). With the popup, was the page italicized correctly before your change? --Izno (talk) 16:06, 17 January 2020 (UTC)
No, that was from the gadget Javascript page. (On that point, there is a separate preview tooltip implemented in MediaWiki Javascript that would render the page in question correctly. It has none of the functionality of Navpops though besides as a preview, and other differences besides.) --Izno (talk) 21:59, 17 January 2020 (UTC)
CSD log
CASSIOPEIA directed me here. I am asking about the CSD log. It isn't showing the CSDs prior to when I created the log. Is this correct? If so, is there anywhere or anyway to see my CSDs without picking through my contributions? Thanks in advance, Willbb234Talk (please {{ping}} me in replies) 13:09, 19 January 2020 (UTC)
Willbb234, At Wikipedia:Twinkle/Preferences. Find " Keep a log in userspace of all CSD nominations" and " Keep a log in userspace of all pages you tag for PROD" then click on the tick box. After that click on save changes. Now when you nominate something for CSD or Prod it will keep a log of it. ~~ CAPTAIN MEDUSAtalk13:18, 19 January 2020 (UTC)
The CSD log is just a wikipage generated from the time you tick the tickmark. You can go and add the ones from prior, if you can find them, but the tool doesn't know any better than you do which those are, so it doesn't. --Izno (talk) 14:55, 19 January 2020 (UTC)
Filters and reusing existing filtering for libavtools.js
Some of you might be interested in watching the mw:Reading/Web/Desktop Improvements. I heard in a meeting today that their main goals for the next few months are to make the sidebar collapsible, and to do something about the "header" (I think they mean the top of the page). I think that this will only affect people using Vector.
If the usual patterns hold (who else remembers the 2014 Typography refresh project?), whenever this happens, there'll be complaints for a week or two, especially if someone's favorite user script stops working, and then people will have fixed their scripts and adapted, and after a year or two, few of us will be able to accurately describe the changes that were made.[1] I think that people who use the desktop site on a mobile device will be happy about the collapsible sidebar. I have the impression that the header change is meant to be more compact.
My request for you technically minded folks is to keep an eye out for this, because I do expect that any change, no matter how small, will break at least one user script, and they'll ask for help here. It'll be announced in Tech News beforehand, but I don't have the release dates myself.
^If you're struggling to remember this right now, the 2014 project changed the ==Section headings== to a serif font, changed the font color from true black to extremely dark gray, and added just a little extra leading to Vector. I remembered the switch to serif section headings, but I had to look up the rest. What I will never need to look up is that they briefly broke a whole language with a font-based accident; as a result, I never want anyone to change any fonts again. AFAICT no font changes are planned.
Vector is terrible. It's an ugly canker, showing the absolute best of 1990s web design. The WMF should focus its efforts on Timeless and enter the 20th century.--Jorm (talk) 20:36, 18 January 2020 (UTC)
I want a highly-polished mahogany cabinet with scrollwork, an engraved brass front panel, and carefully-calibrated vernier dials. Some nice warm Nixie tubes would be good. Ivory bars (cracked or otherwise) are optional, but nickel bars must not be exactly one inch too short and there needs to be one more drop of oil on the quartz rod. --Redrose64 🌹 (talk) 11:20, 19 January 2020 (UTC)
Google search linking to older versions of WP pages
I have been noticing over the past few days that, when logged out, google search links to older versions of articles, by several hours. For example, at 13.06 UTC now, google search is linking to the Emily Hale article (and edit history), from 5.53 UTC, over 7 hours ago. However, if I log in, google search links to the most recent version (and edit history) of the article. Is that a fault on our side – E.g. have we stopped giving google the update data in real-time? Britishfinance (talk) 14:04, 20 January 2020 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 January. It will be on non-Wikipedia wikis and some Wikipedias from 22 January. It will be on all wikis from 23 January (calendar).
Future changes
There is a new suggestion for what to show when someone edits without registering an account. This is to give unregistered editors better privacy and make some anti-vandalism work go faster. You can give feedback.
Pywikibot is a Python library to automate work on wikis. It will no longer support Python 2. Use the python2 tag if you need to continue running Python 2 scripts. The Pywikibot team strongly recommends to migrate to Python 3. You can get help to do so. [22]
The weekly MediaWiki branch cut will soon become automated. The timing for this cut may change. You can discuss in Phabricator if this affects you. [23]
You can read about coming technical events and mentoring interns.
@Vchimpanzee: By default, the template fetches {{#property:P856}} for |website= from the Wikidata entry of Will & Grace. When you added |production_website=, it also added that URL as production website. When you removed that and added |website=, it overrode the default Wikidata property and used your explicitly defined URL instead. --qedk (t桜c)20:08, 20 January 2020 (UTC)
Thanks. For some reason "production website" was in the infobox and I thought that's what was supposed to be there, but when it didn't work I added "website" to see if that would work.— Vchimpanzee • talk • contributions • 20:17, 20 January 2020 (UTC)
I've faced this a lot of times, so no worries, and fwiw, I'm very much against automatic inclusion of Wikidata properties. Interestingly, Apple Inc., used to display it was "Owned by" two hedge funds which altogether own <1% of Apple, due to the Wikidata entry, until it was ultimately removed from the infobox template. --qedk (t桜c)20:21, 20 January 2020 (UTC)
Categorization really should be disabled in user space. I guess we have to file a phab ticket to change it since it's a magic word? ‑‑Trialpears (talk) 15:55, 20 January 2020 (UTC)
@Trialpears: Wouldn't it be more useful to remove the magic word from the userpages using a bot (since there's no reason to use the modification in the first place)? We could also do both. --qedk (t桜c)15:57, 20 January 2020 (UTC)
There's probably reasonable consensus for bot-removing bad DISPLAYTITLEs in user space, but I doubt there's consensus for disabling the keyword entirely. --Izno (talk) 16:23, 20 January 2020 (UTC)
Userspace may be drafting pages prior to moving to main, and using approriate display titles there (that don't include USER:xxx/). I can't see how these are actually hurting anything, at the very most perhaps commenting out the directive should suffice. — xaosfluxTalk16:26, 20 January 2020 (UTC)
In this current setup, the tracking category is useless as the massive amount of userspace categories are clogging it up. So that's one way it's hurting. I personally see no point in the display title even for valid draft pages in userspace. When ready for the mainspace, just add it later, same as how categories are done in draftspace. --Gonnym (talk) 16:37, 20 January 2020 (UTC)
On aside, the "polluted tracking category" could probably be easily dealt with here if phab:T197489 were to get done - subscribing to and commenting support there may be useful to attract developers. — xaosfluxTalk16:45, 20 January 2020 (UTC)
Done that, thanks for the ticket! I still think removing categorization in user space for that specific category would be appropriate though since that would likely be so much faster way to solve the pollution problem. ‑‑Trialpears (talk) 17:25, 20 January 2020 (UTC)
@Trialpears: seems reasonable, perhaps a WP:BOTREQ to "Comment out DISPLAYTITLE in User: namespace, when the display title does not contain "User:%BASEPAGENAME%" after getting a little more discussion time in? — xaosfluxTalk17:30, 20 January 2020 (UTC)
Bad DISPLAYTITLEs can also be generated by infoboxes; not sure if that currently occurs but in those cases the template should be modified to exclude certain namespaces or to work in a smart way with the title parts (like nl:Module:Titelweergave does). --bdijkstra (talk) 17:58, 20 January 2020 (UTC)
Note that Category:Pages with disallowed DISPLAYTITLE modifications says: "This search only displays articles in the category." I added it shortly after creating the category and have used it to find and fix more than 1000 articles. It works perfectly so pollution doesn't matter to me here. I have thought about making a general template for category pages to search for articles or other selected namespaces. PrimeHunter (talk) 22:42, 20 January 2020 (UTC)
Do not use {{DATE}} as an autovalue for date= parameters
Currently the message at MediaWiki:Visualeditor-dialog-meta-settings-displaytitle-help reads: "You can override how this page's title is displayed by setting a different label to show instead." However, on this wiki only the markup of a page title can be changed (and the case of the first character, if it is a letter), so it is slightly misleading. Also, judging by Category:Pages with disallowed DISPLAYTITLE modifications at least some VE editors seem to think they can change the title this way. I suggest the following text instead: "You can enter wikicode here to change the markup of the page title." --bdijkstra (talk) 15:31, 20 January 2020 (UTC)
@Bdijkstra: seems reasonable but I'm getting a bit lost trying to invoke that message from the editor, what are the steps you are using to get to where that message displays? — xaosfluxTalk15:36, 20 January 2020 (UTC)
I posted this request for input on Lupin's talk page on January 1st, but it has had no replies.
I am well aware everyone says this is an old tool (a bit like me, I guess), but it was darned useful, and I've yet to find any live spellchecker that's as good. Any offer to fix this would be most appreciated. Nick Moyes (talk) 11:05, 22 January 2020 (UTC)
PS, I have thought of taking it out of the template, rerunning my query, and then restoring it to the template. It would only take a moment to do that, but it seems excessively invasive. -- RoySmith(talk)00:41, 23 January 2020 (UTC)
The "what links here" list is very unlikely to update quickly and the template would have to be removed for a significant, yet unknown, period. Fixing this, like fixing Special:LinkSearch, is not as sexy as a new skin or fiddling with mobile so it may never be done. Johnuniq (talk) 01:03, 23 January 2020 (UTC)
Barring the more general solution of a script, the only articles that include the text are these 5; you could trivially tweak the search to find the exact ones which include the square brackets indicating a link. --Izno (talk) 01:44, 23 January 2020 (UTC)
See also T14396 (from 2007) and T5241 (from 2005). It would be really great to persuade the WMF to use our donations to give us more help in building an encyclopedia, but they have important branding discussion meetings to attend. Maybe after we are all one with the wikiborg, I won't be so cynical. – Jonesey95 (talk) 02:08, 23 January 2020 (UTC)
|Billboardbrasilhot100={{!}}Brazil ([[Brasil Hot 100 Airplay|Hot 100 Airplay]]){{#tag:ref|{{#if:{{{artist|}}}||{{main other|[[Category:Singlechart used with missing parameters]]}}<spanstyle="color:red;">ERROR: Billboard chart was invoked without providing an artist. Artist is a mandatory field for this call.</span>}}[{{trim|{{#ifeq:{{{forceartist|}}}|true|https://www.billboard.com/artist/{{{artistid}}}/{{BillboardEncode|{{{artist}}}}}/chart?f={{{chartnum}}}|https://www.billboard.com/artist/{{trim|{{BillboardID|{{{artist}}}}}}}/{{BillboardEncode|{{{artist}}}}}/chart?f=1221}} "{{{artist}}} – Chart history"] [[Brasil Hot 100 Airplay]] for {{{artist}}}. {{#if:{{{publish-date|{{{publishdate|}}}}}}|{{{publish-date|{{{publishdate}}}}}}. }} {{#if:{{{access-date|{{{accessdate|}}}}}}| Retrieved {{{access-date|{{{accessdate}}}}}}.}}{{dead link|date=July 2019}}{{main other|[[Category:Singlechart with dead link]]}}}}|name={{#if:{{{refname|}}}|{{{refname}}}|"sc_{{strip whitespace|{{{1|}}}}}_{{{artist|}}}"}}|group={{#if:{{{refgroup|}}}| "{{{refgroup}}}"}}}} {{Single chart/chartnote|{{{note|}}}}}
Right, the feature only shows actual transclusions which happen when the page is rendered. The transclusion code in the source is only activated in some of the cases where the template is called with |Billboardbrasilhot100. None of the examples currently displayed on the template page do that. {{Single chart/testcases}} does have such examples so it shows up in WhatLinksHere. Here is as search for templates with {{BillboardID in the source code. It finds Template:Single chart. PrimeHunter (talk) 12:43, 23 January 2020 (UTC)
Thanks everyone. Wish the what links here feature had "usage in source code" in addition to "links to" and "transcludes". --Gonnym (talk) 12:51, 23 January 2020 (UTC)
Hello everyone, How can i undo/revert all contributions done by an anonymous user from our Wikipedia? I want to do that with one click. Is there any tool or user script? Thanks! ⇒ AramTalk11:08, 23 January 2020 (UTC)
Does anyone know when reFill will be back up and working again? I as well as other users have noticed it is completely inoperable and has been so for days. It's the only reFill tool I know how to use and am hoping to be able to use it again so other wikipedians don't get upset at me for bare references. If no one knows what the deal is with reFill, are there identical tools where we can just plug in the page name and let it do its work filling in the references? Many thanks, --Caterpillar84 (talk) 01:20, 18 January 2020 (UTC)
That is nice to know Whatamidoing (WMF) but filling them one at a time is incredibly laborious when Refill 2 could work on the whole article at once - indeed I have seen it fix over 100 refs in one article. Can anyone explain why Refill 2 - which has been working fine (well except for an occasional glitch that was sorted out fairly quickly) has to be stopped completely while waiting for a co-maintainer? While Reflinks is still available it isn't perfect and I have just finished a 5 day job fixing the refs that Reflinks could not handle and I have another one to struggle with. I am fairly sure that Refill 2 would have gotten some to most of them, Indeed the using two programs together take care of most bare urls. Anything to ease the work load would be most appreciated. MarnetteD|Talk19:41, 19 January 2020 (UTC)
Heartily seconded! The manual substitutes are painful, when reFill could do a whole new article in one swoop. Anything that can be done to restore it would be greatly appreciated. KJP1 (talk) 21:27, 19 January 2020 (UTC)
Thanks for clearing that up AntiCompositeNumber. Ammarapad's post and my reading of the phab caused my confusion. It is also nice to know that C678 has taken over the job. Previous posts about this had not been answered completely. Thanks again. MarnetteD|Talk21:41, 19 January 2020 (UTC)
Yes. I got a couple of requests actually. I just have not had a moment to look into why. Not to mention that I'm a brand new maintainer and need to learn the internals. My goal is to merge InternetArchiveBot and ReFill.—CYBERPOWER(Chat)22:55, 19 January 2020 (UTC)
For the non-technical folks: When you're working on code that you care about (e.g., reFill), it's considered best practice to have at least two people working on it. That way, Alice can write some code, and Bob can check for mistakes before it gets deployed, and vice versa. Fewer problems affect the wikis when people follow that system. The buddy system also helps solve the so-called "bus test" problem (i.e., what happens to your product if someone gets hit by a bus). In an ideal world, every tool that we care about would have at least two maintainers. Whatamidoing (WMF) (talk) 01:04, 20 January 2020 (UTC)
Unfortunately not realistic when dealing with a massively diverse community such as Wikipedia. There are as many different roles for the volunteers as are strands of hair on your head/face.—CYBERPOWER(Around)01:11, 20 January 2020 (UTC)
Cyberpower678, Many thanks for picking up the reFill work and appreciate that we're all volunteers. Just wanted to emphasise how really useful the tool is. Anything you can do to get it up and running again would be wonderful. All the best. KJP1 (talk) 07:41, 20 January 2020 (UTC)
Cyberpower678, I have tried using reFill for the last 20 minutes, but like other users, all I'm getting is this pop-up message, "Submitting your task... Internal Server Error". Woodlot (talk) 15:21, 20 January 2020 (UTC)
Cyberpower678 et al - I have tried both Refill and Refill2 several times today and I also keep on getting the dreaded Internal Server Error. Anyone have any updates on when these tools might be back up? (I even tried Reflinks but that's outside WP's purview...) Shearonink (talk) 22:57, 20 January 2020 (UTC)
Still not working, tried several times today...is a viable workaround posted somewhere in this section? If so, for those of us who aren't coders(at ALL), could a ReFill workaround section be posted please? Thx, Shearonink (talk) 19:23, 21 January 2020 (UTC)
Can a revert to old be written to the source of the input page or can a temporary fork be made ? A bug has been filed at Github :
After a bit of turning-it-off-and-back-on-again, reFill appears to be working now. The IP editor is correct that nothing has changed code-wise for a while. The frontend is sitting at this commit from Jan 13, 2018 and the backend is sitting at this commit from Jan 24, 2019. The reFill documentation doesn't really contain much operations information, so there were difficulties figuring out what needed to be checked and restarted. --AntiCompositeNumber (talk) 22:01, 21 January 2020 (UTC)
How did you save that comment? Did you use a mouse to click "Publish"? If so, the mouse could be doing weird double clicks. Instead, click in the edit summary box and press Enter to Publish. Try that for a while to see if there is a difference. Johnuniq (talk) 22:28, 17 January 2020 (UTC)
Pressing ↵ Enter works to publish when any of these have the focus: the "Subject/headline" box (when creating a new section); the "Edit summary" box (when editing an existing section); the "This is a minor edit" and "Watch this page" checkboxes; the Publish changes button. For this last one, pressing Space also works. At any time (even when typing in the main edit box), Alt+⇧ Shift+S will save your changes straight away. --Redrose64 🌹 (talk) 08:06, 18 January 2020 (UTC)
Are you sure? My mouse is reasonably new and in good condition and was working very well when I commented above. However, it started occasionally double-clicking two days after I posted the above! (I had a spare and the replacement has eliminated problems.) Johnuniq (talk) 02:15, 24 January 2020 (UTC)
Broken prev diffs when apply tag filter to history
When looking at the history of a user's talk, if you enter "discretionary sanctions alert" for the Tag filter and click Show revisions, an extract from the history is shown. I think that in the past I could copy a "prev" diff from the resulting list to get a diff of the discretionary sanctions notification being added. However, when I do that now, the diff is meaningless because it gives the difference between successive entries in the filtered history. An example of a filtered history is this. The first two entries are dated 5 August 2018 and 6 July 2018 because an alert was added on each of those dates. However, the prev diff on the first line gives the difference from 6 July 2018 to 5 August 2018 which is no use. Has this behavior changed? Is it expected? Johnuniq (talk) 08:40, 23 January 2020 (UTC)
Thanks, although I don't understand the details of that. Is this part of a planned fix, or would a phab report be needed? Johnuniq (talk) 08:53, 23 January 2020 (UTC)
@Johnuniq: If you file a phab task and assign it to me, I should have a chance later this week to do more in depth investigation and see if there is no reason to always use "prev" DannyS712 (talk) 09:01, 23 January 2020 (UTC)
One of the stranger parts of the deletion policy is WP:PERMADEL:
Deletion should not be used for archiving a page. The developers have indicated that the deleted pages can be cleared or removed from the database at any time.
The first sentence is obvious enough, but I'm not quite sure what to make of the second one. The link goes to this statement made by Brion VIBBER in 2007: Deletion means deletion. The deleted page archives ARE TEMPORARY TO FACILITATE UNDELETION OF PAGES WHICH SHOULD NOT HAVE BEEN DELETED and are subject to being cleared or removed AT ANY TIME WITHOUT WARNING. I'm finding this surprising. Is it really the case that at some point in the future, the contents of deleted pages will permanently disappear so that not even admins will be able to view them? Or is this only a reference to a some mysterious feature of the early days of wikipedia that's not relevant anymore? – Uanfala (talk)22:31, 16 January 2020 (UTC)
It's not very likely, but we could theoretically lose access to deleted edits again. The text of deleted pages/revisions isn't available in database dumps, etc., so if all the copies of Wikipedia's database became unavailable and all we could access was database dumps, we would lose all the deleted edits up until this highly calamitous event. Graham8707:30, 17 January 2020 (UTC)
Deleted pages are stored in the same place as normal pages. Any sort of accident is likely to affect both and is very unlikely (any historical oddities dont really reflect the situation today). The disk storage for deleted pages is not that big in the scheme of things. I think it is extremely unlikely we would intentionally choose to remove them. [Disclaimer: just my personal view. Not official in any way or form] Bawolff (talk) 11:11, 24 January 2020 (UTC)
This is because it only copies the direct html code to the English Wikipedia page, not all the styling. This is a long known issue of "foreign" (meaning from another website) files, it can only handle very specific styling, not everything and anything. (the 'context' of Commons is not available within English Wikipedia). Solving that problem is complex yet most of the time, no one even notices, so it's not a high on the list of things to fix. —TheDJ (talk • contribs) 10:32, 24 January 2020 (UTC)
I'd like to add a wikilink to a station linking to the corresponding page, and have some text displayed on top, e.g. the "Lo Wu" text at the very top should be converted into a link such as Lo Wu. Is there any template facilitating this?
I went to nominate an article for deletion, but the process is onerous and decided to forget it. It's been a long time since I hacked on MW code but if there any support for doing a modal dialog to collect user input that could then complete all these tasks as a single action? If not, can you log this as a feature request? Cheers --LaserLegs (talk) 00:47, 25 January 2020 (UTC)
I am frequently looking for admins who speak Spanish, to help deal with difficult editors who are less than fluent in English. Do we have a way of syncing/searching the admin category with the categories of users who speak certain languages? If not, could such a thing be developed? I used to call on Titoxd, but they are fairly inactive these days, and want to find another. SandyGeorgia (Talk) 14:47, 25 January 2020 (UTC)
@Galobtter: thanks; I see you show up there, but your user page says Spanish level 1. I speak fluent Spanish, but need a sysop probably at level 3 or better to help. Are you able? If so, I'll ping you in. SandyGeorgia (Talk) 19:15, 25 January 2020 (UTC)
Yep, thanks, Xaosflux-- Galobtter put that same on my talk page. What I really needed was an admin who is more fluent than level 1 or 2, which is what most of those 107 are. I had to go through them one by one to sort out those at 3 or above. I eventually got someone to help out, but it would be really awesome if the tool could return only those at Level 3, 4, 5 or native. Best, SandyGeorgia (Talk) 17:01, 26 January 2020 (UTC)
Hello. In Russian Wikipedia all pages in the Help namespace have been moved to the Wikipedia namespace and now there are only a couple dozen redirects in the Help namespace. Now there is a proposal to delete the Help namespace altogether and create new help pages in the Wikipedia namespace. Some users have pointed out that deleting it would be technologically complex if possible at all. Sorry if I'm posting this in the wrong place, but could anyone tell me if any Wikipedia or another Wikimedia project has successfully deleted an existing namespace? --Синкретик (talk) 10:19, 26 January 2020 (UTC)
not that I am exclusively a deletionist, but the deletionist also do their part by cleaning up useless trash, making it possible for others to spot useful trash for cobbling together, while on the march. Happy 6M. DBigXrayᗙ13:33, 24 January 2020 (UTC)
GoodDay: Or you can permanently delete the logo entirely with #p-logo a { background-image: url('') !important; background-size: contain; } If you want someone to do it for you just ask, takes 10 seconds. -- GreenC22:37, 25 January 2020 (UTC)
@GoodDay: Go to Preferences/Gadgets, and check "Suppress display of CentralNotices". While you're there, you might also want to check "Suppress display of fundraiser banners" (which are annoying because they cause page bounce on load, and are especially annoying if you have a monthly PayPal donation set up). Narky Blert (talk) 16:43, 26 January 2020 (UTC)
I rather suspect that it didn't. What were the exact words? Were they, by any chance, "Code that you insert on this page could contain malicious content capable of compromising your account. If you import a script from another page with "importScript" or "iusc", take note that this causes you to dynamically load a remote script, which could be changed by others."?
If so, then you should not worry. That is a generic message used on all CSS and JS pages regardless of content, it isn't warning you about anything specifically within the code that you pasted - it's shown for anything, including a completely empty edit window. In particular, Ahecht hasn't used either "importScript" or "iusc" (neither of which are valid in a CSS page). Also, it's difficult for a CSS page to contain malicious content, and even more difficult for it to be capable of compromising your account. If you know what you're doing, you can make a page difficult to use - such as being entirely invisible - but that won't compromise your account.
Can I ask if anybody knows why Wikipedia:Database reports/Polluted categories hasn't been updated since December 15? It's an important maintenance list, because draft and userspace pages aren't supposed to be filed in article categories at all (and conversely, articles aren't supposed to be filed in projectspace categories either), but it's much harder to stay on top of cleaning up dirty categories if the tool hasn't updated in a month to either drop already-cleaned categories or pick up newly-polluted ones. Thanks. Bearcat (talk) 23:40, 25 January 2020 (UTC)
The bot has recently been active, so I suppose that the operator would be the first stop of interest. --Izno (talk) 00:22, 26 January 2020 (UTC)
Hi. There are logs stored in tools-sgebastion-07:/data/project/dbreps/var/log. A quick glance at the logs for this report indicate that it's running daily instead of weekly now (a change made sometime between April 2019 and October 2019 I guess) and it errors on almost every run due to the MySQL connection going away. This very likely means that the report is architected in such a way that it has become prohibitively expensive to generate. Are you interested in fixing the report? --MZMcBride (talk) 07:37, 27 January 2020 (UTC)
Problem with insource searches
For the last few days, when I've attempted to perform insource searches (e.g. insource:/\[\[Golden Age\]\]/), I receive a Wikimedia Error like this:
"Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.
See the error message at the bottom of this page for more information.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request from 2601:49:8402:5f90:985e:b33e:2406:68c1 via cp1081.eqiad.wmnet, ATS/8.0.5
Error: 504, Connection Timed Out at 2020-01-27 04:15:06 GMT"
The last day or two we've been having hardware issues elsewhere (see above threads) which may have been impacting search. In general, make sure you trim down the possible sets of search terms before running a regex search with e.g. insource:"Golden Age" insource:/\[\[Golden Age\]\]/. --Izno (talk) 04:59, 27 January 2020 (UTC)
Hey @Vchimpanzee:. It looks like the edits were redacted (an administrator ability) rather than oversighted (only available to Overighters and Stewards). But in a nutshell, no. The only way to access the content is to contact someone who does have the ability to view it and ask them to provide information about it. GMGtalk18:11, 27 January 2020 (UTC)
Vchimpanzee, That information was removed using a process called revision deletion. It was hidden because it was a copyright violation. One annoying fact is that if you detect a copyright violation in one revision, you have to revision delete that version and all subsequent versions up to the point of the removal, so one should not conclude that every one of those edits are themselves problematic. If you have a decent reason for asking, other than just casual curiosity, I am sure just about any admin, including myself, would be happy to give you more information. S Philbrick(Talk)18:32, 27 January 2020 (UTC)
Right. I knew most of those edits were not a problem but for the first time I realized there might be an important reason for knowing one of those diffs, but I don't have one in this case.— Vchimpanzee • talk • contributions • 18:34, 27 January 2020 (UTC)
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
Some mobile diffs have problems. A couple of buttons are not shown. Structured data diffs on Commons are confusing. The developers are working on fixing it. [24][25]
Administrators on wikis that use Structured Discussions can't move discussion pages. This is a bug. The developers are working on fixing it. [26]
Changes later this week
There is no new MediaWiki version this week.
Future changes
There is JavaScript code on Special:Undelete for administrators that makes it possible to automatically select multiple checkboxes by holding the "Shift" key and clicking. This code is also loaded by accident on other special pages and on articles. This makes pages slower to load. This will be fixed. If you know of other special pages where this is useful please tell the developers at phab:T232688.
I'm looking for some advice, or maybe a sanity-check, and I pick you all. :-)
Editors have asked the Editing team, for multiple years and specifically during the big consultation about talk pages last year, to enable visual editing on talk pages. Here at the English Wikipedia, there's Template:VEFriendly, which lets people use it. You can also edit the URL to achieve the same goal, at least if your prefs are set to show two editing tabs in the mainspace. (I'm not sure it works under all the prefs options.) But you can't use it "officially".
The Editing team has never been very enthusiastic about the idea. There are a variety of reasons for this, and the one that is most relevant to my question for you is parsing.
Right now, generally speaking, if I screw up the wikitext in one section, then the next section has a chance of being okay. For example, imagine that I add a table in one section, but I forget to close the table. You edit the next section. While pages with these kinds of problems would end up at Special:LintErrors, and (in this case) it will look strange, you can click the [Edit section] button in any subsequent section and add your comment without being affected by my errors (although everything else on the page might still display strangely after you edit the page).
If you edit the page in the visual mode, however, it'll try to repair the damage my incorrect wikitext caused (in this case, by automagically adding the wikitext code to close the table at the very end of the entire page,[27] which is where the parsers [now] say the table actually ends). That's not too bad, but in other cases, you might not like the results. I think that in the worst-case scenario, it could reprocess the entire page as a single string. The only practical solution would be undoing your edit and trying again from your favorite wikitext editor, and maybe cleaning up the wikitext error while you're at it.
What I'd like to know from you all is:
In your experience, how often do you suppose serious wikitext errors appear on talk pages? Accidentally unescaped wikitext or template fragments turns up on this page at least occasionally. What about other talk pages?
Where does having to revert and try again (or cleaning up someone else's mess) fall on the annoyance scale? Is it more like a minor thing, or more like a serious problem?
Two further points for context:
Even if you all agreed that this was only a tiny annoyance and would almost never happen, the Editing team still might think that full-on visual editing of talk pages is a bad idea. The parsing problem has never been their primary reason for refusing these repeated requests. Telling me that it's fine doesn't mean that anything will change.
The old parser will probably be removed next year. In about a year, Parsoid (which is what the visual editor depends upon) will be used for parsing all edits, no matter what editing system you're using. I understand that this means that the problem of unescaped invalid/unbalanced wikitext is going to affect talk pages anyway. Sometimes I think that maybe a little visual editing would get some these problems identified and cleaned up bit by bit before the switch, and other times I think that I'd rather postpone the inevitable as long as possible.
I am not up to date on what VE does at the moment but in the past I have seen it refactor text that presumably was not the target of the edit, say by normalizing template parameters. If there is any chance of that happening, enabling VE on talk would not be desirable. Some people are very sensitive about their comments and certainly would not want them changed as a side effect of another person adding a comment. Johnuniq (talk) 02:37, 10 January 2020 (UTC)
As someone who frequently cleans up article-space problems caused by the beta Visual Editor, my primary concern about enabling it in more spaces is that WMF's developers have not been as responsive as I would hope to bug reports about VE. See, for example, T133874, T162291 (almost three years old), T174303 (2.5 years old), T219627 (almost one year old), T209493 (over a year old, possibly fixed soon), T113717 (over 4 years old), and T143453 (3.5 years old). And those are just from the list of phabricator tasks I am following. I know that the developers are always working on all sorts of stuff, but I find it hard to understand why a beta editing tool that has had some very basic bugs in a stale state for many years would be expanded to a namespace where it will likely cause significant trouble.
I am not enough of a Wikimedia insider to understand the difference between VE and Parsoid, but with respect to "In about a year, Parsoid ... will be used for parsing all edits", if that means that some of the above bugs will spread to all edits, not just to VE edits, I think that there may have to be some serious bug-squashing between now and then if you want to avoid a big blow-up. – Jonesey95 (talk) 03:24, 10 January 2020 (UTC)
VE style doesn't match with wikitext styling, and this can be confusing. For example fire up this page in ve now (link here) and go look at the "How to challenge the decision to remove support for insecure browsers?" section. VE is very unforgiving about mixed list styles that we use for indents and it makes it look like a mess with huge chunks of whitespace. If I was editing there, what should I do there - try to clean it up and it just gets even worse. — xaosfluxTalk03:27, 10 January 2020 (UTC)
Even this section has tons of extra white space in the VE viewing mode, or whatever that link is, and I don't think our indenting is out of the ordinary. If that is what talk pages look like in VE, that seems like a show-stopper. – Jonesey95 (talk) 03:53, 10 January 2020 (UTC)
The extra whitespace is partly caused by the single stray : in the middle of your ::-level previous comment. If the aesthetic experience were the main concern, the people who didn't like it just wouldn't use it. Whatamidoing (WMF) (talk) 20:22, 10 January 2020 (UTC)
My best guesses about the effects of some known bugs:
phab:T133874 would only apply if you edited (probably including cut-and-paste rearranging) a template that had previously been added in the non-standard order. That shouldn't be a typical activity on the talk page, and the usual reason to care about the order of the parameters (aside from dirty diffing) is to talk about it, in which case it'd be escaped (and therefore left alone) anyway.
phab:T162291 prevents a few links; if you paste content that triggers this bug, you'd see https://www.example.com instead of https://www.example.com. phab:T219627, about getting unnecessary nowiki tags on ISBNs, is similar in its end effect.
phab:T174303 doesn't feel important for talk pages, even though it's annoying in articles. Also, the Parsoid-everywhere thing might magically solve that (also phab:T113717 and the old one about people actually copying little blue clicky numbers and thinking that they're copying the whole citation template).
phab:T143453 is about people using citoid to generate citation templates (which doesn't happen much on talk pages) and then not checking the content, even though VisualEditor automatically previews the citation before letting the editor move on. But it doesn't corrupt the rest of the page (at least no more than would happen if someone typed that in wikitext now), and as a technical matter, it's not clear to me whether the citoid service ought to be sanitizing input that might look like templates or character formatting, or if the CS1 modules ought to do that.
phab:T209493 should be solved soon, and might be another one problem that magically goes away with phab:T54091.
My overall impression is that while some of these are annoying, none of them destroy the whole page. The occasional weird list construction sounds riskier to me. It's one thing to have your own edit go awry; that's what the edit source button is for. It's another thing if your quick comment corrupts the whole page. So I'm putting better support for definition lists on my list, but so far, nobody seems concerned about a high volume of the whole-page disasters that we saw back in the day. Whatamidoing (WMF) (talk) 21:17, 10 January 2020 (UTC)
I am concerned about making a change through VisualEditor that can trigger a change to be made to other sections. An obvious disaster will hopefully be noticed, though a surprising number of editors seem not to look at the results of their edits, based on errors that get left behind. Anything other than an obvious total page breakdown can be easily missed as editors won't be reviewing the entire page for changes. Reverting and trying again is pretty annoying given there is no guarantee that it won't happen again. An experienced editor might realize that a wikitext error has to be fixed, but even so, tracking a bug down is a huge pain. isaacl (talk) 22:14, 10 January 2020 (UTC)
I don't think the bugs I listed above will break whole pages; my words were in response to Whatamidoing (WMF)'s question: Where does having to revert and try again (or cleaning up someone else's mess) fall on the annoyance scale? My point was (supposed to be) that volunteer WP editors have reported many bugs in VE that cause annoyance and work (many more hours of work than it will take to fix the bugs), and that should not be hard for developers to fix, but those bugs have languished. I worry that similar annoying talk-page VE bugs (not at the page-breaking level, but at the annoying gnome-work level), will similarly languish because they are "minor" or because editors should check their edits before saving, or some other fairy tale. – Jonesey95 (talk) 00:24, 11 January 2020 (UTC)
I was responding to the issues raised in the original post, and following up the message which stated ...so far, nobody seems concerned about a high volume of whole-page disasters that we saw back in the day.. isaacl (talk) 07:00, 11 January 2020 (UTC)
Some changes to the rest of the page are trivial enough that they won't be worth reverting, and some might be helpful, but I'd rather not see any page completely broken. Whatamidoing (WMF) (talk) 00:17, 14 January 2020 (UTC)
Oof, too much credit to me. Anomalocaris probably has spent much more time than I have on linting and probably has a better handle on the first question. I will answer some of the request from what I have observed. (Aside, I will be along to the couple fun Phabricator discussions occurring about a related topic... sometime in the next few days.)
In your experience, how often do you suppose serious wikitext errors appear on talk pages? Accidentally unescaped wikitext or template fragments turns up on this page at least occasionally. What about other talk pages?
Besides misnested font/styled span HTML elements? Rarely.
Where does having to revert and try again (or cleaning up someone else's mess) fall on the annoyance scale? Is it more like a minor thing, or more like a serious problem?
If the problem is systemic (i.e. a script, or bot, or MediaWiki, WP:LISTGAP and related, [or someone's signature]), the most annoying. The occasional typo or missing end tag, not a big deal. If the error is massive, it may prevent users from leaving comments on talk pages, which would be the worst end of the deal, or lead to biting.
The old parser will probably be removed next year.
Parsoid's not ready to handle talk pages or complicated (template) wikitext. (Read mode is okay, but I've seen enough edit mode problems that would prevent saving otherwise-fine wikitext.) Talk pages might get there with the talk project, but I am skeptical about that schedule being valid for all other pages within a year.
So I think I'm going to file the overall response under "lukewarm": we'd expect the occasional breakage, but it's probably not a disaster. I think the team's overall feeling is lukewarm-ish, too, so absent a real push from other wikis, I'm not expecting this to be prioritized. Whatamidoing (WMF) (talk) 00:17, 14 January 2020 (UTC)
@Whatamidoing (WMF): Back in November I ran a Bot run over about 2,400 pages for the MilHist Project. For each page both the article page and talk page had to be parsed. The Bot reported failures whenever it struck a syntax error on a page. These were almost always an unclosed link or template. Some 11 errors were reported on article pages (0.4% error rate) and 46 (1.9%) on talk pages. Thus talk pages were five times as likely to have syntax errors on them despite being much smaller in general. The annoyance level was high because the errors can be really hard to spot, even with Bot assistance. Hawkeye7(discuss)01:14, 14 January 2020 (UTC)
Hawkeye7, we're off on a bit of a tangent, but those percentages are not surprising, since articles are watched much more closely and fixed by projects like CheckWiki and various reports, and we have rules against messing with other people's contributions to talk pages. Also, talk pages are not the face of Wikipedia to the world, so errors are less of a problem. – Jonesey95 (talk) 03:24, 14 January 2020 (UTC)
Now I really want to know more about your project. I can't imagine why someone would need a bot to parse a couple thousand pages.
If there's approximately a 2% error rate, presumably declining over time (as fiddly bits are found and fixed), then that's not too common (a new editor has a 98% chance of being okay), but still common enough to trip me up about once or twice a week (because I spent a lot more time on talk pages than the typical newbie. The median number of talk page edits during the first week after the first edit appears to be zero).
I think I'd live with this error rate to get, say, better odds that the Reply tool could auto-resolve edit conflicts on fast-moving pages. (I have very much been wishing for that over at MEDMOS these last few weeks. At one point, WT:MEDMOS was longer than AN and ANI combined, and at least the WikEd users were complaining that it was difficult to edit the page.) I don't think that getting the visual editor itself up on a page would be worth a 2% error rate – to me. Others might disagree. As usual, if you disagree with me, or if you can think of a group of users whose experience differs from mine, then I do appreciate hearing what you're thinking. Whatamidoing (WMF) (talk) 00:38, 15 January 2020 (UTC)
@Whatamidoing (WMF): Is the Editing team actually considering introducing the full VisualEditor on talk pages? Or are these questions being asked because of the use of Parsoid in the inline comment editor, or for some other reason? Jc86035 (talk) 05:22, 19 January 2020 (UTC)
As I said above, they are getting requests, but the team is not enthusiastic about it. I don't think it will happen this calendar year. I make no predictions about what might happen several years from now.
Off the top of my head, some of the same considerations could apply to the Reply tool (play here; testing script here; ping me wherever you post your feedback), at least one upcoming MediaWiki technical RFC, some accessibility work (imagine a world with native MediaWiki support for line breaks inside bullet items), and how much trouble we'll encounter outside the article space when they decommission the old parser next year. Whatamidoing (WMF) (talk) 00:52, 20 January 2020 (UTC)
In your experience, how often do you suppose serious wikitext errors appear on talk pages? Accidentally unescaped wikitext or template fragments turns up on this page at least occasionally. What about other talk pages?
There a lot of talk pages that have errors that bleed to the end of the page, especially Multiline table in list. There are now over 1,000 such errors, of which probably less than half, but still a lot, cause increased indentation to the end of the page. Unclosed quote in heading generally infects the table of contents and therefore the whole page. Right now there aren't any such errors, but there are new ones every week. Multiple unclosed formatting tags (or even single missing end tags, for that matter) can bleed to the end of the page, especially <big> and <small>. There are now about 800 Multiple unclosed formatting tags, perhaps a third of them <big> and <small>. There are a lot of talk pages where the users fail to escape markup that they are talking about, including nav and other templates, <div> tags, everything. Some of these bleed to the end of the page. I would guess there are tens of thousands of these.
I would assume that most of the world's web pages are written with WYSIWYG editors and I would assume that a lot of people who enter content into websites would feel helpless dealing with the Wikipedia editing interface. If someone has expertise in some area of interest, the inability to deal with the Wikipedia editing interface should not be an obstacle for them to contribute to Wikipedia. And part of contributing to Wikipedia is discussions on talk pages. So, eventually, I think visual editing will be needed for talk pages.
Just visited Wikipedia (not yet logged in) and got a large coloured graphical advertising banner scrolling across my eyes. Four your information, certain people such as myself are badly distracted by such animations, to the point of suffering some loss of mental focus, even physical dizziness, and hence experiencing significant distress, when attempting to read any nearby text. I can assure you that the burst of unpleasantness your banner engendered has ensured that it will be many years before I would ever, ever consider a financial donation (which I assume was the purpose of the offensive creation, though I was unable to stop and see), so your banner was entirely self-defeating. Please, please ensure that you respect WP:ACCESSIBILITY in a comprehensive, open-minded and above all sympathetic way before pushing out intrusively distressing and unreadable advertising to the unfortunate. Any kneejerk self-justification in reply to this plea (e.g. "we pull in more cash that way so you will just have to swallow it" or "here's how to turn it off [after you got hit between the eyes]" type shit) will only go to prove the point. Thank you for listening. — Cheers, Steelpillow (Talk) 10:06, 21 January 2020 (UTC)
I just viewed while logged out and got a scrolling banner ad for Wiki Loves Monuments (its stops scrolling when it looses focus, but I only found that out by accident) with a link to a post hosted on Medium, and the notice "The linked blog content above is hosted by a third party and is subject to their terms of service". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:00, 21 January 2020 (UTC)
Hey all and especially @Steelpillow:, thank you for your feedback and I genuinely mean that. So for a week we were running a number of banners as part of a follow up thank you campaign. That wrapped up on Tuesday. There was no monetary goal attached to that campaign. It's aim was to try and showcase Wikipedia. The banner I think your referring to was one with a mural design as part of it. The decision for the scroll on the mural banner you saw was mainly a practical choice in order to show more of the mural to the user. There were better ways we could have it, like the way it was implemented in the WLM and WLE banners which required user interaction. My genuine apologies for the discomfort caused. Seddon (WMF) (talk) 11:34, 24 January 2020 (UTC)
Thank you for the clarification. I think the key moment came when you assumed that all users who saw it would want to be shown more scrolling images. And my other point also stands: it was self-defeating insofar as its end effect was very far from a "showcase". I look forward to a calmer UX from here on in. — Cheers, Steelpillow (Talk) 14:32, 24 January 2020 (UTC)
certain people are badly distracted by such animations,
Amen to that!
Don't get into a spat with Giano then, as he's developed a nasty habit lately of posting a super-fast animated hummingbird whenever something or someone annoys him. TBH, I'd prefer a goatse... Andy Dingley (talk) 13:56, 21 January 2020 (UTC)
The ZoomOnThumb gadget has been available for years on fr.wiki to allow zooming in on images by hovering the mouse over them. I like it so much that I've begun adding it to my other wiki accounts (starting at en.wiki) by means of custom Javascript. Any user can do the same by copying the JS I used but I believe that it would be a worthwhile addition to the set of Gadgets available via checkboxes on the en.wiki users' Preferences page. See also Wikipedia:User scripts/Requests#ZoomOnThumb gadget where User:BrandonXLF sent me here. — Tonymec (talk) 21:51, 24 January 2020 (UTC)
@DannyS712: Sorry, I'm a newbie about JS on Wikimedia. I was wondering how to generalize this "French gadget" to my non-French accounts, there was a HowTo about that on fr.wiki, I did what it said (and added a comment or two because I believe in verbose commenting of source code), and it worked. Then I got a web notification saying you had "reviewed" the page and an email saying you has "changed" it (but no change was visible). I supposed, and you confirmed, that both of these were about the same event, called "review" on my User Notifications page. I didn't know there was more than one kind of review, and I thought that if there had been anything obviously untoward in that very short page you would have told me. Qui ne dit mot consent as we say in French (≈ silence is consent). I also thought that the fact that this gadget wasn't "new stuff" but something which had already simmered for quite some time at fr.wiki was a point in its favor. Sorry if I jumped to conclusions at any point.
Now if I can do anything more to help bring that gadget onto the en.wiki prefs page, tell me what, anybody, and I'll do my best. — Tonymec (talk) 22:44, 25 January 2020 (UTC)
@Whatamidoing (WMF): No, or not yet. You mean I should put that JS there, and it would automagically apply to all my accounts? Even so, I still think it would be a valuable addition to the "Gadgets" preferences page at, among others, en.wiki. — Tonymec (talk) 22:40, 26 January 2020 (UTC)
Yes, that's the idea behind a global.js page. It only works for you, but it works for you everywhere. A lot of smaller wikis don't have any gadgets at all, so adding a user script directly to your own account is the only way to use scripts at those wikis. Whatamidoing (WMF) (talk) 20:56, 27 January 2020 (UTC)
Xaosflux, Genuinely need every revision. I'm trying to make a history that exclusively shows the changes to "The section title of the article that people kept edit warring over" moonythedwarf (Braden N.) 20:44, 27 January 2020 (UTC)
Xaosflux Tried and now I could access but when I pasted an article name to check copyvio, the system show this message - "An error occurred while using the search engine (Google Error: HTTP Error 403: Forbidden). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine." So I guess I need to go back later and see I would do the copyvio check. Thank you Zaosflux for the reply. Cheers. CASSIOPEIA(talk)02:50, 22 January 2020 (UTC)
@CASSIOPEIA: I've had that, or a very similar message, very occasionally over the last 12 months. I just assumed it was Google telling me to slow down a bit. Usually worked a few minutes later, presumably requiring someone at Google to nip downstairs and let out the head of steam from their server room. Nick Moyes (talk) 10:59, 22 January 2020 (UTC)
Maybe some transient problem? It's working fine for me, in a second or two.[1] If you're using Chrome (maybe other browsers have something similar?), you might try View/Developer/JavaScript Console if this persists for you. Under the Network tab, you should be able to see the URL being fetched, and any errors that happen. You need to be a bit tech-savvy to interpret the output, however. -- RoySmith(talk)02:55, 28 January 2020 (UTC)
Following the breadcrumbs, I can confirm my eswiki watchlist looks the same as my enwiki watchlist. The new watchlist is now fairly old, and the notification (dialog box) in eswiki watchlist you're talking about is about the new filtering system, which you also received on enwiki, you probably just don't recall clicking on it. The normal settings would be to have subtle markers and green collapsible arrows unchecked and the rest of the boxes checked in your preferences under "Watchlist". Do that, clear the cache and reload your watchlist. What's the browser and device you're using? --qedk (t桜c)18:58, 28 January 2020 (UTC)
@QEDK: thanks for the help. I have looked at this on three different computers, with four different browsers, (PC, MacBook and IPad), and the problem is the same on all three, so I don't think that's it. I can't find the settings you mention under Preferences --> Watchlist ... could you walk me through it? Sheesh, I need to get a cot in here. SandyGeorgia (Talk) 19:11, 28 January 2020 (UTC)
By all means, why not, we also have bellinis or jack on the rocks, if that's more your style. Good to hear it's all resolved now. --qedk (t桜c)20:13, 28 January 2020 (UTC)
Had problems all day however it seems to have been resolved within the last few minutes, In the UK & added cmnt to ticket, Cheers. –Davey2010Talk21:10, 26 January 2020 (UTC)
I came here to see if anyone else was having an issue. I too just had a 504 issue and its been sluggish to load pages. Im from Minnesota, so this isnt something regionally based. I could be wrong, just a guess. Hopefully this can be fixed, and promptly. SageSolomon (talk) 21:15, 26 January 2020 (UTC)
It's not just Wikipedia. All WMF wikis that I've tried (Wikipedia, Wiktionary, Commons and Wikivoyage) are either working fine or timing out and what one is doing at any given moment the others are doing the same. Thryduulf (talk) 21:14, 26 January 2020 (UTC)
For whatever it may be worth: late yesterday I didn't see any significant problems accessing wiki.riteme.site. Perhaps I just missed the difficulties. Or could it be I'm on the west coast, and presumably going through the S.F. servers? ♦ J. Johnson (JJ) (talk) 21:46, 27 January 2020 (UTC)
DDoS in progress? Sometimes I get a timeout, sometimes the page loads but with no skin… Waiting a few minutes then reloading usually does it for me, but of course the reload interval shouldn't be too short, or the reloading attempts will compound the problem. (I'm in Belgium.) — Tonymec (talk) 20:59, 26 January 2020 (UTC)
Correct and the Tweet below [28] suggests it was an intentional DDoS. But I wouldn't say Bryant's death was unrelated either. If you look at [29] and compare to the editing history of Kobe Bryant [30] there was a spike around the time when our article was getting a lot of edits suggesting this was when news of his passing was starting to spread. If the servers were already under strain from an intentional DDoS, perhaps partly migated by adjusting traffic end points, then the sudden strain of a spike from genuine users trying to read about Bryant may have pushed them over the edge again. Nil Einne (talk) 03:18, 27 January 2020 (UTC)
I wouldn't be so sure. Michael Jackson's death definitely caused a massive traffic spike which caused many problems [31]. While it's true the internet has moved on since 2009, although as the Tweet illustrates we still don't really have any proper DDoS protection given our reluctance to use third party services and the reach of Kobe Bryant is far less than Michael Jackson (although the BBC News app seems to have turned into Kobe Bryant died app), an impact can't be ruled out from the data I've seen. Note I explicitly never said that it did cause a problems, rather I've seen no strong evidence it did not cause problems either. Remember also that the problem is in timing as much as anything. A spike of 10 million page views over a day may be irrelevant. A spike of 10 million page views over 10 minutes, not so much..... Also, any data when the servers are having problem is likely to be circumspect, unless the people in charge say otherwise. (And for the WMF, given the way they seem to operate things, I would consider any data which could be vastly different from their normal data to be circumspect unless they say otherwise, even if there were no recorded problem.) Nil Einne (talk) 12:27, 27 January 2020 (UTC)
Nil Einne, the micheal jackson problem should no longer exist. Tim Starling wrote explicit protections to make sure that when something like that happens again, only the one page is affected, instead of everything. —TheDJ (talk • contribs) 12:31, 27 January 2020 (UTC)
@TheDJ: I think there is some confusion here. I explicitly did not mention Wikipedia being affected by Michael Jackson for a reason. That was, as I understand it, caused by a specific set of circumstances relating to how things worked at the time [32], which was indeed largely fixed by the mw:Extension:PoolCounter. But the Michael Jackson case (and other cases since) illustrate the problem of unintentional DDoS caused by a sudden surge of genuine traffic due to some news in the world. (I've never run anything close to a significant webserver so I don't have any personal experience on how big such spikes are. But the reports I've seen suggest they can be massive. And as I said, if your site is actually having problems, or you simply never designed it with such loads in mind, you may not even really know precisely how big the spike even is. There is a reason why so much of the world, even fairly major sites, often rely on Cloudflare.) In this case, we know en.wikipedia, and other Wikimedia sites were already having problems before Kobe Bryant died. (Tweets from the CEO suggest it may have been an intentional DDoS although I haven't seen anyone on the technical side actually say that yet.) There is a good chance this problem was not completely resolved before Kobe Bryant died. If the servers were already under significant strain before his death, maybe close to and occasionally already occasionally going down because of this, a spike from his death could have pushed things over the edge for a lot of people, for a time. Again, I'm explicitly saying 'could' here. I have seen no data to suggest this happened. However I have also seen no data to suggest it did not happen, and the reasons people are giving for how we know it didn't happen, have not been convincing to me (which is my main point). Note also that it isn't really possible to design a website so that one specific page is completely isolated from the rest of the website, it's simply not how things work. Nil Einne (talk) 12:53, 27 January 2020 (UTC)
WMF is "mitigating the current DDoS using a service from Cloudflare" — CEO
That's reassuring, Cloudlare is well-known for their powerful DDoS mitigation tools. Note that a DDoS mitigation tool is not the same as a CDN, so it doesn't contradict the previous statement on this topic.
However I'm worried there has been no official comment for the media, the promise "We’ll keep you posted" in the WMF blog post on September 7th was not kept, and there has been no incident report on the previous DDoS at wikitech:Incident documentation. Also if one tries to get some data himself, grafana.wikimedia.org is as hard to grasp as a nuclear plant control room and status.wikimedia.org is deprecated. Ain92 (talk) 23:31, 26 January 2020 (UTC)
@AntiCompositeNumber: I would like to find out when did the attack actually began and what was the traffic (in GB/s) on other server clusters besides the main one (eqiad). Perhaps there is some other info I can't think of, if you find anything interesting for the Wikinews readers, let me know about it. Ain92 (talk) 20:00, 27 January 2020 (UTC)
Frontend traffic is the best place to look for timing, as that shows the caching layer you hit when you load a page. [33]. You can filter between clusters at the top left and in each panel. The other useful metric is from the application servers, which shows response timing for requests that don't hit the cache. [34]. --AntiCompositeNumber (talk) 20:11, 27 January 2020 (UTC)
I'm no IT security expert, but IMHO a cloak of secrecy is a poor way to handle the situation considering the mistrust between WMF and community. Especially considering the WMF hadn't even told us about the new policy before my question. Ain92 (talk) 20:00, 27 January 2020 (UTC)
I don't know that it's especially odd to not want to reveal the intricate details of the steps you're taking to enhance your security. GMGtalk20:04, 27 January 2020 (UTC)
Relying on secrets of your process to provide security is security through obscurity - not assisting with attackers future discovery processes is normal. — xaosfluxTalk20:10, 27 January 2020 (UTC)
WP:BEANS but for an active network problem instead of wikicontent. Let the pros deal with this. they have done this at least several more times than u ever did. —TheDJ (talk • contribs) 21:47, 27 January 2020 (UTC)
To update you all, some of these empty categories were deleted weeks ago, with seemingly no issue (I was never asked to restore them) but there are still quite a lot that appear on Wikipedia:Database reports/Empty categories, our empty categories list. I asked our most active empty category tagger to hold off on tagging them for deletion but from what I could understand reviewing the previous discussion (which truthfully wasn't a lot), these suddenly empty categories are due to a change in some template. Since these categories have not been repopulated in three weeks, is it safe to delete them? Or does some edit have to be made somewhere and, poof!, these categories will be filled? Your nontechnical advice would be most welcome! LizRead!Talk!23:32, 28 January 2020 (UTC)
Is there a list of Mediawiki extensions which Wikipedia uses somewhere
Hi all
I think there is probably a special page somewhere that lists all the extensions the English Wikipedia Mediawiki installation uses , but can't find it anywhere... Any ideas?
Apologies, as I think I've missed something, but has this been deprecated for something else? Thanks all pumpers :) ——SN5412910:47, 29 January 2020 (UTC)
If anyone is interested in reviewing the code and making suggestions regarding coding style, techniques, or something else, please let me know. See phab:T234507 for more.
Recent additions
I have added basic tests for the script, so bugs should be less likely to make their way to the deployed versions of the script (both the unstable development version, and the stable release version).
If there is an error with the script, the user will be notified and and the console will include a stack trace of the issue.
Translations
Many thanks to those that have contributed translations for the script's messages. Translation takes place at m:User:DannyS712/Global watchlist/Translate, and help is appreciated.
Newly translated messages are added to the script when I notice them; if you have translated messages that aren't showing up, please let me know at m:User talk:DannyS712.
Next release
Version 8.0 was just finalized for the development and stable branches of the script.
This hot mess drives me nuts. While editing an article, I reflexively type cmd-F (on a Mac) in my web browser to find something on the page. But the visual editor's find-and-replace traps the keystroke. My system-wide find text is not in its field. My system's cmd-E "Use selection for find" command sort of works, but only with cmd-G, find again. Once I use that, then hitting cmd-F opens the browser's find command while the visual editors find-and-replace remains visible but semi-inert.
How do I disable the visual editor's Find command? —MichaelZ. 2020-01-25 17:50 z
Visual Editor is still very much in beta. You might have better luck with a different page editor. This search in Phabricator, Mediawiki's bug-tracking site, turns up a couple of bug reports that may describe the behavior you are seeing. I didn't see any feedback from developers about disabling VE's Find command. – Jonesey95 (talk) 18:07, 25 January 2020 (UTC)
The visual editor hasn't been in Beta Features on this wiki for a couple of years now.
Michael, I have the same problem. Unfortunately, I don't know of a good solution. I've learned to pay attention to which field is active, and to hit the Undo button when I don't. (I don't consider that to be a good solution.) Whatamidoing (WMF) (talk) 21:53, 26 January 2020 (UTC)
Changing that means that 300 translators would re-translate that line. The whole section needs to be re-organized (so you can just pick the editing environment you want, and not guess whether this pref secretly overrides that other pref...). I'd rather go straight from "old" to "new" without a temporary re-translation step in the middle. VisualEditor is not Beta software, no matter what that line says. Whatamidoing (WMF) (talk) 19:20, 28 January 2020 (UTC)
Just a note: before anyone starts ranting about what a piece of **** VE is, the problem of two different programs responding to the same keystroke is not unique to VE. At work I run a KVM program to access servers running Linux on a Windows 10 laptop. When I have a KVM window open to a given server & switch between virtual screens on the server with the F2, F3, F7, etc. keys, whenever I return to my original virtual screen with the F1 key, not only do I return to my original virtual screen inside the KVM window, but I bring up this utility that offers to modify the settings on my monitor. It is annoying, but I don't have the luxury of applying the simplest & best fix -- uninstalling Windows. -- llywrch (talk) 19:37, 29 January 2020 (UTC)
Determining what level was edited?
Resolved
Is there any technical way, either available to standard users or not, to tell whether an edit was performed by editing the an entire article, or a section? I'm presuming the actual change is the same, so let's say at article just consisted of
abc
==FOO==
def
and was changed to
abc
==FOO==
ghi
In case 1, the entire article was edited to change def to ghi, in case 2, the section for FOO was edited changing def to ghi.
This is just curiousity given that edits of sections are turned into edits of entire articles in the case of edit conflicts , and my guess is that the information as to what level an edit was performed at simply isn't part of the database and thus it is impossible. Still, I figured the people who would know would hang out here.Naraht (talk) 14:16, 29 January 2020 (UTC)
@Naraht: you can use the non-authoritative automatic edit summary as a hint, it may include the section name. This is not stored on the back-end, however there is a similar request to add a tag to "new" sections (phab:T226563) - you could make a similar request to tag "section edits". — xaosfluxTalk15:02, 29 January 2020 (UTC)
@Xaosflux: Yes, but that can be easily spoofed, as in my edit. That happens albo when someone changes the section header and the summary retains its previous contents. --CiaPan (talk) 15:41, 29 January 2020 (UTC)
On discussion pages I often spoof a section edit summary when making a page edit to move a new section to the bottom or combine two sections about the same. It seems helpful to give the section name in such edits and enable a section link in the edit summary. And when I change a heading in a section edit, I often make the same change in the edit summary. In September I added an API method to see the source text of an edit summary to Help:Edit summary#Places where the edit summary appears, but it does not reveal whether spoofing was used. PrimeHunter (talk) 19:56, 29 January 2020 (UTC)
Yes, we should automate what User:PrimeHunter already does. If we had very intelligent software, perhaps it could notice that an edit was trying to change the section header, and then place a section link updated with the new name into the draft edit summary. This would help at WP:AN3 where the status of a report goes into the section header (words such as 'Blocked', 'No violation' etc.). This means that in practice, each closed report usually has an out-of-date edit summary. The only way to get a correct edit summary is, if a very picky admin who is in the process of entering the status (whether it is blocked, NV etc) will preview the post before saving, find the new section header in the text of the preview and manually put it into the edit summary field. EdJohnston (talk) 20:20, 29 January 2020 (UTC)
Is there any way to identify pages based on the value of a specific parameter within a template? Ideally, I'd like to get a breakdown by category (results being grouped based on each possible value of the parameter), but being able to search for any page where the template has a specific value for the parameter would also work. A way to design a search string that does this would be fine, though I assume that accounting for all of the template redirects would complicate things.
In this particular case, I'm interested in Template:Expert, so the ideal is being able to identify all uses of the template based on parameter value (in other words, Category:All articles needing expert attention grouped by the type of expert requested). In contrast, the minimum result I'm hoping for is to identify all uses of the template that request a particular type of expert. Thanks! Sunrise(talk)22:45, 28 January 2020 (UTC)
I was going to suggest trying bambots at wmflabs but that page shows "The bambots tools have been moved to a new server" with a link to non-WMF site. I thought wmflabs tools were kept with source available for others and I would not feel comfortable using a non-WMF site. Johnuniq (talk) 23:45, 28 January 2020 (UTC)
@Sunrise: Using the search box, you can search for hastemplate:"Expert needed" and you get 4867 total results, or just 4492 in mainspace. So at least you know the size of the job you're looking at. If you can manage with just identifying those with a particular value, such as 'Physics' for example, then the search hastemplate:"Expert needed" insource:/expert[^|]*\| *Physics/ finds all 31 of them. I assume, though, that you'd prefer all 4492 articles broken down by parameter value. That's the sort of job that a bot would do easily enough, and your best bet might be to ask at Wikipedia:Bot requests, although it is backlogged. Perhaps a bot operator who watches this page might be happy to do a run for you. HTH --RexxS (talk) 01:31, 29 January 2020 (UTC)
@Sunrise: you're right. My suggested search only finds the articles that ask for a subject expert in Physics as the first topic. I realise now that the parameters |ex2=, |ex3=, etc. need to be taken account of as well. Cheers --RexxS (talk) 01:04, 30 January 2020 (UTC)
Group notices?
I want to create a page notice that appears every time you create a new WP:DRV. Each day gets a new page, something like Wikipedia:Deletion review/Log/2020 January 23. My first thought was to go to Wikipedia:Deletion review/Log, and edit the Group notice for that. But, when I click the Group notice link, I get to "Creating Template:Editnotices/Group/Wikipedia:Deletion review", not "Creating Template:Editnotices/Group/Wikipedia:Deletion review/Log". Is this intentional? If I manually edit the URL to include the trailing "/Log", will Bad Things happen? -- RoySmith(talk)18:16, 29 January 2020 (UTC)
@RoySmith: This unfortunately won't work. For group notices, the editnotice loader only checks Template:Editnotices/Group/{{FULLROOTPAGENAME}} for a group notice, so a notice placed at "Template:Editnotices/Group/Wikipedia:Deletion review/Log" will not have any effect. ST47 (talk) 18:24, 29 January 2020 (UTC)
Hmmm, well, so not Bad Things, but certainly not Useful Things :-) I guess I need to fall back to my zeroth thought, which is that when the empty dailly pages are created by DRVClerk, it should also create a page notice for each one. I'll continue that at WT:DRV. -- RoySmith(talk)18:32, 29 January 2020 (UTC)
I have it but it's not working well. When I open a page in Wikipedia, it starts with no dark mode then after 2 seconds it changes to dark mode. That's more stressful for my eyes. I hope they develop the dark mode quickly. It sounds very easy to create a dark skin, I don't know why Wikipedia still has not developed a dark skin. It should be available for both readers and editors. People spend a lot of time reading in Wikipedia.--SharʿabSalam▼ (talk) 06:38, 30 January 2020 (UTC)
When a category page is changed, the diff link given in Watchlist often uses the wrong page for comparison, and makes it look like the text of the category page has been completely replaced with the text of one of the member articles! Compare:
Maybe it depends of what kind of settings you have for your watchlist. Do you have "Expand watchlist to show all changes, not just the most recent" enabled on your preferences? Stryn (talk) 16:59, 30 January 2020 (UTC)
FYI: I can only reproduce this when both "Category changes" are shown and "Group results by page" is active, then the summary "9 changes" link is as described. It seems it groups all the category membership change entries together with the edit to the category page itself, and winds up diffing between the category page and one of the pages that resulted in a membership change. Anomie⚔17:13, 30 January 2020 (UTC)
Yeah, I think it only occurs with those settings. Still an error though, right? Even when grouping by page, I would expect to see one entry for the changes to the cat page itself, and one for the new members, e.g. "8 pages added to category". —swpbT • go beyond • bad idea17:46, 30 January 2020 (UTC)
Interrupting parsing at beginning of parameter so wikimarkup at very start of its content is not misparsed
Resolved
Template:Quote and some other block-level templates have an issue such that when a content parameter's value begins with wikimarkup, that markup is often not interpreted correctly. In an article, the fix is to do something like this, with <nowiki />:
{{quote|<nowiki /> '''Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.''' Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. }}
To correctly produce:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
With this example, the output of the parameter – if you leave out <nowiki /> – will incorrectly appear as:
'
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
because the start of the parameter is mis-interpreted as a lone, plain-text ' followed by '' italics markup, then later a mis-matching ''' boldfacing start (not end).
This is a fairly serious issue, since we cannot depend on editors to know that they have to manually prefix <nowiki /> in the local template content. This problem affects things like italics and boldface, as well as parameter content beginning with a "*" or "#" list item. It is not repaired by soft-linewrap changes, like {{quote|'''Lorem ipsum dolor...'''}}; the <nowiki /> is needed regardless of horizontal versus vertical template usage. It also is not fixed by naming the parameter, e.g. with {{quote|1='''Lorem ipsum dolor...'''}} The problem does not affect display: inline elements only block ones (and probably inline-block ones).
Attempting to pre-seed the template with <nowiki /> at the beginning of the parameter output has no effect. Nor does wrapping that <nowiki /> in <includeonly>...</includeonly>. Attempting to break up the <nowiki />, e.g. with <includeonly><no</includeonly><includeonly>wiki /></includeonly> fails even more dismally, just passing the literal ASCII characters and causing the string "<nowiki />" to appear in the visible article text.
Has anyone figured out a way to stop this mis-parsing of the first character of the parameter output? I know this is an old issue, and I figure someone must have nailed it while I was off one one of my extended wikibreaks. — SMcCandlish☏¢ 😼 18:34, 30 January 2020 (UTC)
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
and again with 1= parameter
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Hmm. Maybe it requires something in particular about the surrounding material to trigger? I had not seen the problem arise much lately, but ran across it again here: Mutant (Marvel Comics)#Omega-level mutants. If you change the block quotation there to remove the nowiki, the problem triggers (or at least it does for me in Chrome on macOS). I just tested it again and did get the problem (just tested with Preview; I didn't save the change into the live article). — SMcCandlish☏¢ 😼 19:09, 30 January 2020 (UTC)
This is because {{quote}} wraps |1= in {{Trim quotes}}, which trims matched pairs of leading and trailing single (') and double (") quotes and whitespace from a string, per that template's documentation. Stripping matching single quotes appears to be causing the problem. – Jonesey95 (talk) 19:26, 30 January 2020 (UTC)
Yup, that is it: {{quote|'''Omega Level Mutant:''' A mutant ... ''While Jean Grey... telepath.''}} renders as
Omega Level Mutant: A mutant ... While Jean Grey... telepath.
Adding <nowiki /> to the beginning or end of the first parameter will fix the problem and render it as
Omega Level Mutant: A mutant ... While Jean Grey... telepath.
So why didn't it do that to either of your above tests (the Lorem ones)? Maybe it's only triggered when such a quote char. is also at the end? — SMcCandlish☏¢ 😼 21:07, 30 January 2020 (UTC)
That is exactly it: If there is a matching single-quote at the beginning or end, both are stripped. Ditto double-quotes. If there is no matching pair, then nothing changes. I'm not sure what effect the addition whitespace has at the beginning before the quote or at the end after the quote, I didn't examine {{trim quotes}} closely enough. davidwr/(talk)/(contribs) 21:23, 30 January 2020 (UTC)
Is this related to parser bug T18700? It either produces unwanted new lines or errors when newlines are unexpected. I've really no idea as its completely baffling, but it does require <nowiki /> fixes. Jts1882 | talk20:31, 30 January 2020 (UTC)
I have submitted a change for Template:Quote to add a new parameter, {{notrim=1}}, which will insert the <nowiki /> at the beginning of the quote automatically. It is awaiting review and approval by someone with template-editor user-rights. davidwr/(talk)/(contribs) 20:55, 30 January 2020 (UTC)
I'm on it, though this is itself also a kluge; I'm hoping there's a way to just short-circuit this sort of mess. Something in the intervening years has changed, because it used to be a much more common problem. — SMcCandlish☏¢ 😼 21:04, 30 January 2020 (UTC)
Thanks. Unfortunately, there is no way for a computer to know if ''There Be Quotes Here'' is a quote someone copied-and-pasted from somewhere that was typed using two single quotes instead of a double quote, or if it's the title of a book which needs to be in italics. There needs to be a way for the editor using the template to override any trimming, so it will be a kludge one way or the other. davidwr/(talk)/(contribs) 21:18, 30 January 2020 (UTC)
It's all kludgey indeed if the mission is to prevent users from seeing quotation marks (as proscribed by good block quoting). If one were willing to make the concession, the parent trim marks module might reasonably be set up so that you could select which quotation marks you wanted to strip from beginning and end, such that {{quote}} would only strip double quotation marks rather than double and single marks, but then one would get to see the single quotation marks in each article. I think overriding the trimming at the per-article level makes more sense than overriding the trimming partially at the template level. --Izno (talk) 21:31, 30 January 2020 (UTC)
Or it should just not interfere with '' and ''' wikimarkup at all unless forced to do so with a parameter; I've made a Lua-improvement request to this effect over at Template talk:Trim quotes#Wikimarkup interference. The cases where an actual quoted string like "There Be Quotes Here" is using doubled apostrophe/single-quote characters masquerading as double-quote characters is going to be rare (probably just a PDF OCR error). Where such cases exist, retaining them with that incorrect punctuation needs to get fixed anyway, so we have no reason to code around it. — SMcCandlish☏¢ 😼 21:39, 30 January 2020 (UTC)
Mostly davidwr's work, and thanks also to @Jonesey95: for catching the culprit in the first place. This addl. parameter actually also resolved an earlier issue report at Template talk:Quote, about block quotations with nested (interior) quotations, which caused some of these quotation marks to disappear when the block quote begins with one interior quotation and ends with another). Still, it would be nice to have Template:Trim quotes not interfere with wikimarkup when clearly detectable as such. — SMcCandlish☏¢ 😼 22:25, 30 January 2020 (UTC)
Unfortunately, the problem is intractable without awareness of context. Is There Be Quotes Here a book title or an copy-and-paste of a quote by someone who didn't use proper quotation standards by an editor who didn't correct the poorly-formatted quotation? A computer can't know. davidwr/(talk)/(contribs) 22:57, 30 January 2020 (UTC)
Which is why, IMO, {{Quote}} should not try to enforce MOS by stripping quotes that it cannot possibly understand in all cases. Let's remove the trimming and leave MOS enforcement to human editors, as we do with most of the rest of MOS. (Fork alert: I have made this same argument at the template's talk page. Discussion should probably continue there.) – Jonesey95 (talk) 23:29, 30 January 2020 (UTC)
Creating a sanitized CSS page
I would like to know how I can generate a page with the content model sanitized CSS. Even if I cannot generate it, please specify a link about how it can be done. Adithyak1997 (talk) 12:26, 30 January 2020 (UTC)
@Adithyak1997: if you create a subpage of a Template: it will do that automatically. If you need one somewhere else (like a usersandbox) you can create a normal CSS page, then leave an edit request to have an Interface Admin adjust the content model for you. If you have a single page you want made, you can ping me and I'll probably make it for you as well. — xaosfluxTalk12:44, 30 January 2020 (UTC)
@QEDK: I'd have to check over all the use cases, but any admin should be able to change pages from wikitext to SCSS - however the page may fail to convert if it is not actually marked up in SCSS. — xaosfluxTalk14:17, 30 January 2020 (UTC)
If we know a URL or domain had become compromised either temporarily or permanently and is serving up malware, we should be able to reformat pages that include this URL so the link cannot be clicked on by a user. URLs can be added to the blacklist as needed and removed when they are no longer toxic.
True, but seeing how the English Wikipedia is the largest one, I wanted to get a sense of "is this a good idea" from editors here first. davidwr/(talk)/(contribs) 00:05, 28 January 2020 (UTC)
I think it sounds like a good idea in principal, but think that any technical implementation would be a huge problem (as those text links are on every cached page for readers). — xaosfluxTalk00:10, 28 January 2020 (UTC)
The blacklist is implemented by mw:Extension:SpamBlacklist. The closest request I found is phab:T18326 from 2008: "spam blacklist should replace blacklisted links with a safe special page". It suggests to disable all blacklisted links and not to make an option for individual links. PrimeHunter (talk) 00:16, 28 January 2020 (UTC)
At this point I am skating on a thin layer of knowledge over a deep abyss of ignorance. But proceeding on: how would such blacklisting work at the level of the article? Perhaps revise the url to go to internal link that explains the situation? Or? ♦ J. Johnson (JJ) (talk) 23:07, 28 January 2020 (UTC)
Not sure if I am right here, but I noticed that in the article Wildlife Photographer of the Year (which contains very long lists) the flag templates stop working after a certain point. Removing a few entries shifts the point where the templates stop to work, so it seems to be caused by overuse. It it were only the flags, it would not trouble me to much, but then also the template {{reflist}} does not work. Is this a known issue? Can it be handled in another way than using less templates? --Lynxbiru (talk) 11:21, 31 January 2020 (UTC)
@Jts1882 and Lynxbiru: the technical issue isn't currently with the number of images, it is the number of templates. I've disabled all the flag icons in the large list for an immediate fix. As PrimeHunter also mentioned, the page itself is also just far to big, highly suggest splitting out the Wildlife_Photographer_of_the_Year#The_full_list section to a standalone list (which may be able to have the flags back on again). — xaosfluxTalk15:37, 31 January 2020 (UTC)
@Xaosflux: Usually I don't edit on English Wikipedia, so I am not too familiar with the splitting policies. If someone splits the article for me I can remove the templates by hand. --Lynxbiru (talk) 15:56, 31 January 2020 (UTC)
@Lynxbiru: see Help:List. If you want to split out that list, first make the new list, (copy over the content), then just put a link in the article to the new list there. The flag icons can easily be reactivated on a new page if they won't exceed the limit. — xaosfluxTalk16:02, 31 January 2020 (UTC)
@Xaosflux:. I understand that it is not the number of images or for that matter the number of templates. It is the aggregate size of the code returned by the templates. Each flag icon template returns an image tag (or the wikitext for it) with src, srcset, alt and other attributes for each instance of the flag. If the flag icon was handled as a background image in CSS and templatestyles there wouldn't be such repetition of the code. It's not uncommon for a flag icon to be repeated dozens of times in some of the football lists. Anyway, it was just a thought. In general it may just be a sign the articles are too big or overusing illustrations. I've added a comment at the football project about a number of articles with broken coding. Jts1882 | talk16:36, 31 January 2020 (UTC)
Should we be checking for links to the Shlayer trojan horse?
There is an article out today in Wired – The Sneaky Simple Malware That Hits Millions of Macs – about the Shlayer trojan horse that I find disturbing. It says that "The operators behind the trojan reportedly offer website owners, YouTubers, and Wikipedia editors a cut if they push visitors toward a malicious download", with a suggestion this could be done with a "masked link" in a Wikipedia footnote.
If we had examples we could look into users that insert them, or we could check external links that go to flash download pages or site level redirects. All the best: RichFarmbrough (the apparently calm and reasonable) 17:13, 26 January 2020 (UTC).
What I am wondering about is: should we be proactively looking for instances of this sort? If there were such cases, and someone got tripped up, I don't know that they ("some random reader") would know that it is something we would want to know about. But then, perhaps this isn't something we need (yet?) be concerned about? ♦ J. Johnson (JJ) (talk) 21:38, 27 January 2020 (UTC)
Wikipedia:Wikipedia Signpost/2020-01-27/In the media has a blurb titled "Beware of malware" in the "In brief" section. That in turn links to a full report on securelist.com. Near the bottom of that report is an old screen capture of the references section of ru:Kodak Black with a link to a taken-over-an-allegedly-poisoned web site kodak-worldDOTcom. I've already fixed the Russian version, the Ukrainian version, and the French version to point to archive.org versions of the page or to the artist's current official web site instead. Someone with the expertise needs to go through all Wikipedias and search for web sites that are known to be poisoned. Of course, this is a game of whack-a-mole: What is a valid reference today may become a "for sale" domain tomorrow then an infected domain the day after. This means as new domains are compromised, new scans will have to be run. davidwr/(talk)/(contribs) 22:54, 27 January 2020 (UTC)
I gather the broader problem is where an existing, legitimate reference links to a domain that has been compromised, not the malicious addition of fraudulent references. Thanks for the information. ♦ J. Johnson (JJ) (talk) 22:50, 28 January 2020 (UTC)
Yes, that is the broader problem. I've since found out that the CS1-style citation templates like {{cite web}} have a parameter to handle just such an event: |url-status=usurped or |url-status=unfit. They make the link unclick-able. They are designed to be used alongside archive-url when the original link is irrelevant or toxic. This parameter also takes the values "live" to prefer the non-archive link and "dead" for dead links. davidwr/(talk)/(contribs) 22:18, 31 January 2020 (UTC)
My attempts to use Earwig in the last couple of hours have been unsuccessful - tested on a couple of pages, starting with Draft:DBL Ceramics. I get the following error message when I try:
An error occurred while using the search engine (Google Error: HTTP Error 403: Forbidden). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine.
Anyone else getting the same? Or a basic error being made on my side? For what it's worth, I get the same error message if I click on the CSD link or type it in manually. Nosebagbear (talk) 18:11, 26 January 2020 (UTC)
It's been the same way for a number of days now, continuously so I think. Has the Foundation forgotten to pay the bill or something? If we've really used our 50000 searches per day every day for the last 4–5 days, maybe we should see if the subscription can be doubled or increased in some way? Justlettersandnumbers (talk) 21:25, 26 January 2020 (UTC)
Seems to be ok now, e.g. this check. But still has the update note at the top saying "Update (27 January 2020): We are currently experiencing an issue using Google. You may follow this ticket and my talk page for updates." Martinevans123 (talk) 13:07, 1 February 2020 (UTC)
Is there any way to do this automatically? It could either be based on an absolute scale (-100% is red, 0% is white, +100% is blue, and anything in between is shaded in between) or it could be based on the min and max of the actual values, as in the imgur examples above, which were generated with Conditional Formatting in LibreOffice, spanning from min to max value and linearly scaled.
The two solutions I know of are to use javascript to color the cells, as in this example, or turn the whole table into some kind of template that feeds the cell values to Lua to color them, somewhat similar to the heatmaps generated by Template:Weather box.
Does anything like this already exist? Could it be created? The intent is to be able to apply it to all tables of numerical data, like the Conditional Formatting in a spreadsheet. — Omegatron (talk) 06:04, 1 February 2020 (UTC)
So for this solution, the numbers in every cell would need to be replaced by something like | style="background-color: #{{Template:Some_colorizer|76}};" | 76%? Or maybe that could be simplified to something like |{{Some_colorizer|76}} for each row?
With the javascript solution, it could be turned on for any table without editing the table itself, in the same way that sortable tables can be, and it's non-essential information, so it's ok if it doesn't show up for the small fraction of users that don't have javascript. — Omegatron (talk) 14:58, 1 February 2020 (UTC)
The current set of colours used in Wikipedia:RFA_by_month came after a radical reworking to try and avoid colour blindness problems. In the political example you are working on you'd obviously want to avoid either Red or Blue for internal things within a party. The solution we have in Template:Hotcold works for heatmaps of up to 12 shades, and because of the way it is written it can be reconfigured for a wider range of shades if someone can come up with 100 shades that are distinguishable regardless of colour blindness. I would quite like to see a broader range of shades available - the tricky thing is getting the colours right. Get the colours and an expanded version of Template:Hotcold should be easy. So if 12 shades works for you we already have a solution if you need more, the issue is accessible colours. ϢereSpielChequers15:37, 1 February 2020 (UTC)
Getting the colors right is easy; there are lots of color maps with perceptually accurate gradations available now. (I'd suggest blues to match the other tables on that page, for instance.) I'm just asking about the implementation details of actually coloring in the cells without requiring a ton of manual labor on something that is constantly being updated. — Omegatron (talk) 17:17, 1 February 2020 (UTC)
Template error
There seems to be a bug with Template:Skip to bottom. On WP:AN, the template seems to overlap with other templates. This mainly happens when I'm logged out. I tried fixing it myself, but I had no luck with it. Can you figure out what's wrong with it and fix it for me please? Interstellarity (talk) 17:06, 1 February 2020 (UTC)
I think that's how it is supposed to work. It stays locked at the top of the page for me, overlapping nothing, but the template's documentation says: A small floating box with "skip to bottom/skip to TOC" links will appear in the upper-right corner. If you're still having trouble, a screen shot might help. Also let us know what browser, version, and operating system you are using. (BTW for other troubleshooters: the template is transcluded via {{Noticeboard links}}.)– Jonesey95 (talk) 17:54, 1 February 2020 (UTC)
Is there a way to know who is watching your user page?
I think that editor should be able to know who is watching their user pages, is there a way to know who is watching your user page?--SharʿabSalam▼ (talk) 19:17, 1 February 2020 (UTC)
No user, not even administrators, can tell what is in your watchlist, or who is watching any particular page. Publicly available database dumps do not include this information either. Only developers who have access to the servers that hold the Wikipedia database could obtain this kind of information.
That's interesting. I dont know why does the watchlist have privacy. I wouldnt mind if someone saw my watchlist and I can't think of a logical or privacy reason that someone would not want others to see his watchlist. I think it would be cool to have my watchlist public.--SharʿabSalam▼ (talk) 19:37, 1 February 2020 (UTC)
@SharabSalam: some people are readers only, and in some parts of the world people may be persecuted for what they read. Additionally, nothing would stop anyone from watching your userpage without using the watchlist function - they could just load the page in any number of ways and look at the history. — xaosfluxTalk19:39, 1 February 2020 (UTC)
I have often wished my alternate account, User:RoySmith-Mobile, could view my main watchlist. It would be nice if there was some way I could share my watchlist with specific other accounts of my own choosing, but I suspect that wouldn't get a high priority as a feature request. But, the main point about privacy is worth repeating. Even in parts of the world where hiding your reading habits from the government isn't the issue, there's lots of reasons why ordinary people don't want everybody to know what they are reading. As some extreme examples, a 14 year old girl may not want her parents to know she's reading Condom or Self-induced abortion, and you may not want anybody to know you're reading Management of HIV/AIDS. We already have far too much of our lives shared without our knowledge and/or consent. It's good that wikipedia works to preserve our privacy, even if it's occasionally inconvenient.
You might try going to https://myactivity.google.com/ to see some of what is known about you. I personally use duckduckgo most of the time to avoid some of that spying, but I just went to myactivity, and was somewhat surprised to see:
duckduckgo.com
Visited what does google know about me at DuckDuckGo
Details
Today at 3:12 PM
Chrome
Mac
Why this activity?
This activity was saved to your Google Account because your additional Web & App Activity setting was on while using Chrome.
Wow, I never knew that existed. Yeah, that mostly looks like what I need. It works, but what I get is a blob of un-stylized XML. I need to figure out how style that to be human-readable. The other problem, of course, is if I do actually make this work, it'll be just another excuse to mess around on my phone at the gym instead of actually working out. First world problems. -- RoySmith(talk)21:18, 1 February 2020 (UTC)
Replies to most everything above, I'm not chasing the pings down right now.
So public/shared watchlists have been discussed, the concept is basically stalled for over 10 years, and phab:T9467 can be followed to read more about those concepts.
Wikipedia:Syndication#Watchlist_feed_with_token talks about how you can read your watchlist else where, using the watchlist token. If you were to disclose your token, others could read your watchlist as well. There is not somewhere on-wiki to put that, but you could use an RSS reader to load watchlists updates remotely, and use an RSS client to view them. I've done a little bit of this when there were some pages I wanted to make sure I always watched - I used a non-editing account to watch them, got that token, and loaded it to an RSS service. Keep in mind, the RSS service provider (the most common way to use RSS) will be able to see your watchlist.
Hello everyone! I searched for "jump" at Alkene (by using find in Chrome). While i couldn't found any word (with jump), Chrome founded 'jump' 6 times. I think so, that word (jump) went to the back of interface. Can someone tell me something about it? Thanks! ⇒ AramTalk18:49, 1 February 2020 (UTC)
I am not sure but I think if you clicked ctrl + U then searched for jump you will find some hidden text like "Jump to search" and "Jump to navigation"--SharʿabSalam▼ (talk) 19:26, 1 February 2020 (UTC)
@Aram: that, in the page source you can see some interface labels that include "jump", like these:
<div id="jump-to-nav"></div><a href="#column-one" class="mw-jump-link">Jump to navigation</a><a href="#searchInput" class="mw-jump-link">
Is there any place where failed actions are logged? A user at WP:TEA reported they could not change a page title. Looking at their contribution history, they're just over the threshold to be autoconfirmed, so I'm guessing the first time they tried it, they weren't yet. Is there any place their first (failed) attempt to move the page might be logged? It's not a big deal, but if I knew for sure that was the case, I could provide a more useful answer for them. -- RoySmith(talk)17:09, 2 February 2020 (UTC)
Only the edit filter has a log, on "filter log" at the top of user contributions. Permission errors are not logged. The user probably has a move link now but never found or clicked it. The link only appears on pages you have permission to move. PrimeHunter (talk) 17:44, 2 February 2020 (UTC)
So I'm getting some pop-ups in the upper-right of my screen today. Firstly, I'm an admin. Secondly, I saw a pop-up earlier that said I couldn't use page reviewer tools because I didn't have appropriate permissions or something. I didn't take a screencap, so that's probably of no use to any of you.
Anyhow, I was just at Smita Bansal, which is protected with the Pending Changes setting. I looked at three edits, then made a change of my own, and tried to accept the net result of all four of our pending changes, but got a pop-up notice saying that I wasn't part of the correct permission group. Twice I couldn't approve the changes. Finally, I think I went the back way or something (going into View history, then clicking the pending changes notification, then accepting?) and that allowed me to approve the net changes. Am I imagining this? Cyphoidbomb (talk) 16:16, 2 February 2020 (UTC)
@Cyphoidbomb: these don't sound "standard" - perhaps it is one of your many scipts or a gadget you are running? Perhaps a collision between them - are you perchance using "Yet Another AFC Helper Script" gadget? — xaosfluxTalk18:00, 2 February 2020 (UTC)
@Xaosflux: It's possible that I activated Yet Another AFC Helper a few days ago, but after the pop-up notice earlier today, I selected the option to disable it. I can't remember activating any other gadgets recently, and unfortunately there's no history I can check. I haven't touched any of my other scripts since late December, and that was to remove something. I also haven't installed any new software or browser extensions. By far the weirdest thing was the pop-up on the pending changes article telling me I didn't have sufficient permissions. Cyphoidbomb (talk) 18:40, 2 February 2020 (UTC)
@Xaosflux: You read my mind. I was able to duplicate it at Padmaavat. The error is: You do not have permission to review revisions, for the following reason: The action you have requested is limited to users in one of the groups: Editors, Pending changes reviewers.Cyphoidbomb (talk) 18:48, 2 February 2020 (UTC)
I got the same permissions error page a while back while trying to accept a pending change, saying I wasn't allowed to do it and only reviewers could, but I accepted a revision now and it seems to work. --qedk (t桜c)18:50, 2 February 2020 (UTC)
I get the pop-up warning, which fades away, then if I click accept again, the change sticks. I also tried logging out and logging back in to see if it was something weird related to my session. Cyphoidbomb (talk) 18:52, 2 February 2020 (UTC)
With the PC userright, everything looks OK. I just removed it and now the accept/unaccept box does not even appear! Previously (even without PC) I had that atleast. --qedk (t桜c)19:20, 2 February 2020 (UTC)
On a few pages I notice that the screen is acting weird when I try to look at certain articles on my iPad. The text appears to be zooming in and out in rapid succession making things virtually impossible to read. Strangely this effect doesn’t happen after certain edits are made and even more oddity two edits I found that triggered this on different pages don’t appear to have any common features that would explain why this is happening. The two edits are [[35]] and [[36]]. If anyone has an idea of what is going on I would be thankful since I’m stumped.--69.157.252.96 (talk) 07:15, 3 February 2020 (UTC)
I saw (via Signpost) a list of the top 25 EN:WP articles searched worldwide and wondered whether it would be possible to have such a list of most-searched for a specific country or region, or even topic. Thanks. Tony Holkham(Talk)00:30, 1 February 2020 (UTC)
Hi, I there's an issue with viewing this on mobile phones and ipads, it stretches across the page. Can somebody sort out the coding of the parameters to allow it to adapt to the device? Thanks.♦ Dr. Blofeld12:43, 2 February 2020 (UTC)
This is more or less impossible with the way the image maps are set up. E.g. Template:Principal areas of Wales imagemap has a 600px width, and the others have ~500 px width. I don't know how <imagemap> responds to template parameters, but you can try making it so the width is reduced by adding a template parameter where the width is set. --Izno (talk) 14:58, 2 February 2020 (UTC)
{{Principal areas of Wales imagemap}} is set up as a 600px image map, plus a second column to the right of the map. You could move the labels to a cell below the map instead of to the right, and add an optional |width= parameter to that template. Also, the percentage bar template only takes width values in pixels instead of allowing percentage widths (see this page for options). It could be adjusted to take any valid value for |width=, though since "px" is fixed text in that template, all transclusions would have to be checked. – Jonesey95 (talk) 17:03, 2 February 2020 (UTC)
Feel free to adjust or remove any images which don't conform and change to a non table format. I'll probably create one montage image with map and flags.♦ Dr. Blofeld17:16, 2 February 2020 (UTC)
Generating lists of UK and Ireland stubs and running a bot like User:Emijrpbot
Can somebody run something to use automation to generate a list of stubs by entity, county and subject for the UK and Ireland in the project space of Wikipedia:The Great Britain/Ireland Destubathon. I know a lot of entries won't be able to be organized that way but something which can identify stubs for settlements and buildings etc by county and something which can read place of birth and organize it by county. And somebody who can code a bot like Emir's for checking resdable prose length of articles to be run to help patrol the entries once submitted. No rush to do this, we have a month, but whatever anybody can do would be appreciated.♦ Dr. Blofeld15:52, 3 February 2020 (UTC)
I've come across a page that's behaving strangely, which I'm not sure how to fix. The page is titled 2019–20 EuroLeague Regular Season, and consists almost entirely of a very long sequence of templates — but beginning with "Round 22", the page stops transcluding the templates and just starts textlinking to them instead — with the result that when I tried to tag the page as uncategorized, that template also just textlinked instead of actually displaying the template or adding it to the appropriate maintenance category. And there isn't anything in the page coding that causes the templates to change how they behave, either.
I have seen a situation like this before, but it was several years ago and I've never come across it again until now — if I recall correctly, the issue was that there's some kind of upper limit on how many templates can be called in a page, so any additional templates stopped behaving normally, and just turned into text links instead of conventional transclusions, once that limit had been crossed. But I have absolutely no recollection whatsoever of what was done to fix it, nor any recollection of what page it was in order to locate the previous discussion in the VPT archives.
In the meantime, what I've done is to move the uncategorized template to the top of the page as a workaround, even though it's normally supposed to be at the bottom, so that it's properly reflected in the categorization maintenance queue — but the page is still broken from a content perspective as well, and needs somebody to look at it. Thanks. Bearcat (talk) 20:56, 3 February 2020 (UTC)
For an album article I assumed that a corresponding WikiData item will be started by bots, but that is not the case: There's a Category:Articles without Wikidata item, populated by various templates needing Wikidata used mostly on BLPs, e.g., birth place. So now I assume that adding articles manually to this hidden maintenance category makes no sense, and I should simply create the item—PoC for the record label item—is that correct? –84.46.52.96 (talk) 00:32, 4 February 2020 (UTC)
Oldest "living people"?
Is there a way to generate a list of the oldest (or, put another way, earliest born) people in Wikipedia listed in Category:Living people? I am thinking that we might have some older articles on people who were listed as living at the time, and have since died. I think the best place to start looking is with people who would be remarkably old if they were in fact still alive. BD2412T03:22, 4 February 2020 (UTC)
I'm just spit-balling here, but creating a WikiData entry for each person with their birth year would make creating such a list much easier. We already have categories for people born in certain years. Maybe go through categories like Category:1900 births, Category:1901 births, etc. up to, say, Category:1950 births. For each name, check to see if the person is in a "deaths" category, Category:Living people, or neither, then make your list from there. Slogging through hte resulting list will be a chore though - it will only include people who weren't well-known enough at the time of their death for someone to see an obituary and say "hmm, better check to see if Wikipedia has an article about them." Many newspaper obituaries go behind paywalls after a few days or weeks, making verification more difficult. davidwr/(talk)/(contribs) 04:01, 4 February 2020 (UTC)
Here's a dumb idea: an insource search for "birth date and age\|18" to (try to) show people born in the 19th century that are allegedly still alive. This will more likely show that the wrong template is being used, or some other error, or commented-out templates. You can do the same thing for birth years starting with 190. There are lots of commented-out templates in the results, but you might see something interesting, like Virginia McLaurin, who is (according to Wikipedia) 110 years old.
The new version of MediaWiki will be on test wikis and MediaWiki.org from 17 December. It will be on non-Wikipedia wikis and some Wikipedias from 18 December. It will be on all wikis from 19 December (calendar).
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 18 December at 16:00 (UTC). See how to join.
Done! Please report issues at meta:Talk:MoreMenu. Thanks, — MusikAnimal talk 18:13, 17 December 2019 (UTC)
Fixed. It was not obvious. As far as I can tell, the 
Moved from Talk:Main Page
On hold Pppery will want to mock this up on testwiki first and ensure it doesn't cause some odd issues with wider text there - also do you happen to know if the mobile-app makes use of this message? — xaosflux Talk 14:33, 21 December 2019 (UTC)
Not done with edit requests, the request itself is the "B" of WP:BRD, in this case there is a decline (the "R") so this needs further discussion. If the discussion concludes a change should be made, please link to it (if held elsewhere) then reactivate the edit request at that time. — xaosflux Talk 17:46, 24 December 2019 (UTC)
Thanks, Cyphoidbomb (talk) 03:08, 26 December 2019 (UTC)
Resolved
icon after links to redirects. --Ahecht (TALK
). Regards SoWhy 10:53, 15 January 2020 (UTC)
Works for me @Leo Breman: I just made an edit to the page to refresh it, and it seems fine to me. Try bypassing your cache and reloading. — xaosflux Talk 18:18, 13 January 2020 (UTC)
Thank you --Redrose64 🌹 (talk) 02:05, 15 January 2020 (UTC)Perseverance rover & Ingenuity helicopter => 1336 sols (1372 days) (3 years, 277 days) (landed February 18, 2021).
.jpg)
Sent a notification to MZMcBride, the maintainer, via the BernsteinBot's talkpage of this discussion, so hopefully they or a (talk page stalker) will reply here. Doug Mehus T·C 00:47, 26 January 2020 (UTC)
