If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Implementing the consensus to set Vector 2022 to full width by default
Given the WMF has refused to do so, and given that they have ignored my comment that if they don't we will, although we would prefer they do as the solution will be cleaner, I think our only option is for us to do this ourselves.
A demonstration of this code can be seen here; note that the flash of unstyled content only appears for the demo, and putting the code in your own vector-2022.css style sheet or in MediaWiki:Vector-2022.css does not result in it.
I'm putting the code here for review by the broader community; if no one sees any issue with it then in line with the consensus at the Vector 2022 rollback RfC I will make an edit request at MediaWiki talk:Vector-2022.css. BilledMammal (talk) 20:21, 29 March 2023 (UTC)[reply]
phab:T332505 and phab:T332426 haven't been "refused" at this point, interested technical editors are welcome to contribute a patch for the first. — xaosfluxTalk 21:09, 29 March 2023 (UTC)[reply]
Given this, and given their failure to reply to this comment, I don't see any reason to believe that this will change, regardless of whether the phab tickets remain technically open, and as such we need to do this ourselves. BilledMammal (talk) 21:13, 29 March 2023 (UTC)[reply]
The test would be if there was refusal to promote the patch, doing this server side would be much preferable then client-side hacks, especially for logged out users. As far as DIY, if you have a patch ready submit it and see. — xaosfluxTalk 21:16, 29 March 2023 (UTC)[reply]
I don't have a patch, but I think a comment from the Chief Product and Technical Officer for the Wikimedia Foundation saying that they are continuing to make the right choice in the decision to keep it as the default is sufficient test; I doubt they'll suddenly reverse their opinion because a patch permitting such an option was provided.
I'm also not particularly eager to spend time learning the WikiMedia code base so that I could create such a patch, as I see no reason to believe it would be accepted - I also note Izno's comment about whether a solution for this would be better done in style sheets. BilledMammal (talk) 21:25, 29 March 2023 (UTC)[reply]
FWIW, I tested that code snippet on test2wiki, and it is not ready as-is, many pages got forced in to an even-narrower viewport that could not be recovered from. Anything like this would need very very extensive testing (think of how much went in to the client-side darkmode hack, and there are still errors reported constantly). — xaosfluxTalk 00:40, 30 March 2023 (UTC)[reply]
Can you give an idea what sort of pages those appear in? I've also found an issue with preference/contribution/etc pages; I'm working on that one. BilledMammal (talk) 01:48, 30 March 2023 (UTC)[reply]
Figured out part of the reason there are issues on contribution/category/etc pages; it's disabled by default there. This does mean that there is a bug in that the toggle shows up even on those pages; I've submitted a bug report. BilledMammal (talk) 02:46, 30 March 2023 (UTC)[reply]
Mostly on every Special: page. Note, it isn't just the icon being there or not, that CSS made the entire page much worse. As I noted, this would need extensive testing across all pages and actions before we would ever consider it for production. — xaosfluxTalk 09:51, 30 March 2023 (UTC)[reply]
Sorry, I wasn't clear; the bug with the toggle was unrelated except for the fact that I discovered it while looking into this. The reason it fails there is because by default the width toggle is disabled on pages in namespaces 12 and -1 (with the exception of user preferences); because this wasn't accounted for it resulted in some unexpected behavior.
Alexis Jazz has produced an updated script that fixes most of those issues, although I believe there are a couple still to resolve - I'll look into it further when I have time, and in the meantime hopefully it will become unnecessary because the WMF will agree to implement it on their end. BilledMammal (talk) 22:41, 30 March 2023 (UTC)[reply]
It also seems to break the full/limited width toggle for logged out users.. is the idea to prevent unregistered users from selecting a preference? — TheresNoTime (talk • they/them) 01:50, 30 March 2023 (UTC)[reply]
My tests suggest that it does work for logged out users, although there is still some work to be done per xaosflux - see the demonstration linked above. It could be that the version I'm currently working on broke something there? I've updated the link in the original post to a static container. BilledMammal (talk) 02:31, 30 March 2023 (UTC)[reply]
@Xaosflux: I looked into creating a patch, and believe I have something that would allow TNT's patch to work; see the bottom of phab:T332505. BilledMammal (talk) 07:42, 30 March 2023 (UTC)[reply]
@BilledMammal: I just wanted to note this somewhere; my interactions with Vector 2022 and the resultant RfC/discussions/etc. have been entirely in my capacity as a volunteer (and I include the above-mentioned patch in that). I'm always more than happy to help where I can though, up to and including writing patches and trying to "prod" the right people to take a look — TheresNoTime (talk • they/them) 08:19, 30 March 2023 (UTC)[reply]
You might have to translate for us mere non-coding mortals. Would that make it the default for English Wikipedia? North8000 (talk) 21:18, 29 March 2023 (UTC)[reply]
Hi everyone, thank you for bringing this up. I just wanted to mention that the discussion on next steps is still ongoing on this page and we’re still working on the best way to proceed. We have presented a few different options for how all users can clearly choose which width they prefer, and which the community is currently discussing and weighing the pros and cons of. There is also discussion of how we can respect current existing user preferences on the width. We hope to allow a few more days for discussion and provide a summary and concrete next steps by Tuesday, April 4. @SDeckelmann-WMF is out this week, but will be back next week to continue the conversation. OVasileva (WMF) (talk) 01:01, 30 March 2023 (UTC)[reply]
@OVasileva (WMF): To clarify, are you saying that things have changed since 25 March and you will now be respecting the consensus to set the default for logged-out users as full width? BilledMammal (talk) 01:05, 30 March 2023 (UTC)[reply]
Alexis Jazz has produced an updated version of the CSS file, which may have fixed the issues you saw Xaosflux; so far, I'm not noticing any. It can be found here. BilledMammal (talk) 09:04, 30 March 2023 (UTC)[reply]
All this is so sad, and I bet most people are tired of it. So there was a well hidden RFC, where someone snuck in a second question somewhere near the bottom of the page. And some people answered what they liked better, and there were some good arguments like why any publication ever published had limited line length. Expectedly, no agreement was reached. But hey, there's consensus, and we'll make the English Wikipedia different from any other Wikipedia in the World, and we're gonna push it just so we can show who's the boss. That RFC was like me standing in the long return line at Costco the other day; guess what, everyone had to say something against Costco, 100% consensus! 300 people is by no means a majority of users. It's not even a majority of this Wikipedia's administrators. But okay, keep pushing your agenda, enjoy your 1.5 foot line lengths. 2604:CA00:16B:990E:0:0:662:4239 (talk) 18:11, 30 March 2023 (UTC)[reply]
You are implying that the majority of arguments either way where WP:ILIKEIT, which is not the case. They presented considerations that involve the implications of the changes on the experience of all users, not just the preferences of the RfC's participants. It is also strange that you are calling one of the most participated-in RfCs of all time "well hidden," and the second question was there almost from the start. small jarstc 09:18, 31 March 2023 (UTC)[reply]
well hidden the RfC was listed at WP:CENT, notified at every applicable noticeboard and talk page, even including Donald Trump’s talk page for some reason, and reached WP:300 levels for support, WP:200 for oppose, and over 150 participants in the second question alone. Aaron Liu (talk) 02:01, 2 April 2023 (UTC)[reply]
English Wikipedia was already different from the rest of the world long before a Vector 2022 was ever considered. Every wiki is unique. Not sure what you were heading at there. Tvx1 21:24, 2 April 2023 (UTC)[reply]
I personally would wait to see what WMF does before diving into CSS. It is WP:NOTAVOTE, it is a consensus process. Whatever we do we should take into account practical considerations, like different screen sizes and devices. Maybe set the "limited width" to only take effect as soon as the screen is extended beyond a specific screen resolution (like 1080px)? This is a good compromise between those that want some fixed width and those that want unlimited width. Then we do not have to worry about window resizing or any of that nonsense. It could be an in-between toggle. Aasim - Herrscher of Wikis ❄️ 14:30, 31 March 2023 (UTC)[reply]
Then the contention would be that the width that you need to go to before fixed width takes effect is wider than the scientific optimum. small jarstc 15:41, 31 March 2023 (UTC)[reply]
We already have a consensus on the matter. A “compromise” here is unacceptable. Default width needs to be default. ToaNidhiki05 22:03, 31 March 2023 (UTC)[reply]
Please also note that a hacky workaround like this can easily break if the skin gets redesigned. Vector 2022 is still a new skin, and there will certainly be changes to make the skin stable. We should certainly give it time to evolve to meet the needs of the community and its readers. I know of many of my tools that have broken because of redesigns. Let's not make this hack be one of them. Aasim - Herrscher of Wikis ❄️ 22:32, 31 March 2023 (UTC)[reply]
It’s almost like the skin isn’t ready for prime time. But regardless, WMF can resolve this but implementing unlimited width. I hope they do so. ToaNidhiki05 01:27, 1 April 2023 (UTC)[reply]
V22 has been in the works for years and always based on v10, a sudden redesign to the width is very unlikely. Aaron Liu (talk) 02:02, 2 April 2023 (UTC)[reply]
Maybe not right now, but when they fully deploy? This will certainly be something that will need to be considered given the skin is still a WIP. I have a feeling the Vector 2022 that you see in seven or eight months will be a different skin than the Vector 2022 you see right now. Aasim - Herrscher of Wikis ❄️ 17:02, 2 April 2023 (UTC)[reply]
I don’t think they would make such a major change to limited width, a very small (code-wise) feature, after working on this skin for so long Aaron Liu (talk) 11:22, 3 April 2023 (UTC)[reply]
While technically any workaround would be our problem, in practice the WMF will need to be careful not to break it as they have a strong interest in not breaking enwiki. BilledMammal (talk) 18:09, 7 April 2023 (UTC)[reply]
Patch rejection and further consideration of the proposed CSS change
It appears that the WMF is not willing to consider the patch I proposed, and do not appear willing to produce a patch of their own. As such, our only option appears to be the CSS. I will review the code provided by Alexis Jazz further, to identify any remaining issues, and similar efforts by other editors would be appreciated. BilledMammal (talk) 02:36, 12 April 2023 (UTC)[reply]
If you're referring to T332505, it may be worth seeing what the outcome of the meeting tomorrow is? I'm not sure the only option is changing the sitewide CSS. — TheresNoTime (talk • they/them) 12:46, 12 April 2023 (UTC)[reply]
They don't consider your patch because a logged-out invert would require changing a variable in the source code instead of a dollar-sign preference. Aaron Liu (talk) 14:42, 12 April 2023 (UTC)[reply]
Tech News: 2023-14
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
The system for automatically creating categories for the Babel extension has had several important changes and fixes. One of them allows you to insert templates for automatic category descriptions on creation, allowing you to categorize the new categories. [1][2][3][4][5]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 April. It will be on non-Wikipedia wikis and some Wikipedias from 5 April. It will be on all wikis from 6 April (calendar).
Some older Web browsers will stop being able to use JavaScript on Wikimedia wikis from this week. This mainly affects users of Internet Explorer 11. If you have an old web browser on your computer you can try to upgrade to a newer version. [6]
The deprecated jquery.hoverIntent module has been removed. This module could be used by gadgets and user scripts, to create an artificial delay in how JavaScript responds to a hover event. Gadgets and user scripts should now use jQuery hover() or on() instead. Examples can be found in the migration guide. [7]
Some of the links in Special:SpecialPages will be re-arranged. There will be a clearer separation between links that relate to all users, and links related to your own user account. [8]
You will be able to hide the Reply button in archived discussion pages with a new __ARCHIVEDTALK__ magic word. There will also be a new .mw-archivedtalk CSS class for hiding the Reply button in individual sections on a page. [9][10][11]
Future changes
The Vega software that creates data visualizations in pages, such as graphs, will be upgraded to the newest version in the future. Graphs that still use the very old version 1.5 syntax may stop working properly. Most existing uses have been found and updated, but you can help to check, and to update any local documentation. Examples of how to find and fix these graphs are available.
@Jonesey95: Hmm, it should be automated. I'll check/ask what's broken. Thanks. Quiddity (WMF) (talk) 17:21, 5 April 2023 (UTC)[reply]
This branch cut initially failed because of some of the deploy services on toolforge being down. I'm assuming that has something to do with it. —TheDJ (talk • contribs) 08:17, 6 April 2023 (UTC)[reply]
I had seen that, but then the deployment proceeded, and according to https://versions.toolforge.org/ it is complete, but still no release notes. Strange. – Jonesey95 (talk) 12:01, 6 April 2023 (UTC)[reply]
FWIW, I've pushed out __ARCHIVEDTALK__ to some of the major talk archive temples, will take a while for transcluded pages to get updated. — xaosfluxTalk 13:58, 6 April 2023 (UTC)[reply]
And I've now done mw-archivedtalk for most of them. {{collapse top}} and {{collapse}} are currently used in mainspace and shouldn't be, so while it wouldn't hurt to add it to those, those do also need to be fixed.... Izno (talk) 21:19, 7 April 2023 (UTC)[reply]
Ah this explains why my recent changes page no longer has colored highlighting and doesn't have the thing I can press to refresh the page anymore. Dang... Gatemansgc (TɅ̊LK) 00:00, 7 April 2023 (UTC)[reply]
My browsers are old! I didn't think Wikipedia would no longer work for me! Eventually I'll be moving to a new computer but for now I don't get the highlighting or javascript based refresh. Gatemansgc (TɅ̊LK) 00:28, 7 April 2023 (UTC)[reply]
You should be able to run a recent version of Firefox. The latest version (111) is listed as compatible with Windows 7, which was released in 2009, and on Mac OS Sierra (10.12), which can run on any Mac made in 2010 or later. – Jonesey95 (talk) 01:56, 7 April 2023 (UTC)[reply]
Watchlist.
Starting today my watch list is acting screwy. Normally it has dots next to edits I haven't looked at.....but that is (now) there regardless if I have looked at the edit or not.....it doesn't differentiate between edits you have/haven't looked at. And also normally a option is there saying something like "Mark all changes as seen". But that isn't there anymore. Anyone know what is going on? Thanks.Rja13ww33 (talk) 01:20, 7 April 2023 (UTC)[reply]
Thanks. I figured it was something like that.Rja13ww33 (talk) 01:37, 7 April 2023 (UTC)[reply]
Modern Firefox (current version 111) still supports Windows 7, though it needs Microsoft security update KB4474419. Chrome 109, released a few months ago, also supports it, but is the last version to do so. I'd recommend upgrading; I can't see a reason to use an old version of Chrome of all browsers. (Firefox has some cliffs here and there that would make natural cutoffs like Firefox 56.) Izno (talk) 01:47, 7 April 2023 (UTC)[reply]
Yeah, I should probably upgrade. I still use a older version of windows based on a (work) program I use....but that shouldn't stop me from getting a newer browser.Rja13ww33 (talk) 02:02, 7 April 2023 (UTC)[reply]
JavaScript
Is there any way to allow JavaScript to work on iOS 10.3.3? Ever since the phab:T178356 update, I've no longer been able to run JavaScript on that software, which is the latest version that my iPad 4 supports. I would imagine a userscript to circumvent this would be impossible, though could adjusting my personal CSS make a difference? Thanks all, ‑‑Neveselbert (talk·contribs·email) 10:55, 11 April 2023 (UTC)[reply]
No, this is not possible. The iPad 4 is 11 years old and unfortunately Apple's model doesn't allow you to switch to alternative browsers either... On the bright side, overall browsing Wikipedia this way should be faster, without the JS overhead. —TheDJ (talk • contribs) 11:18, 11 April 2023 (UTC)[reply]
@TheDJ: is there absolutely nothing I can do though? Could jailbreaking help? I'm also confused as to why ES6 doesn't work on my iPad since according to caniuse.com/es6 it's supposed to be supported on iOS 10. ‑‑Neveselbert (talk·contribs·email) 12:52, 11 April 2023 (UTC)[reply]
Not as far as I know. I'm not aware of any jailbeak that also installs 3rd party browsers or that allows you to install a newer version of iOS. .. "according to caniuse.com/es6 it's supposed to be supported on iOS 10". The lexical part of ES6 is supported on Safari 10, but some small critical ES6 parts are apparently missing/incomplete (specifically on the Promise front) (edit: I'm mistaken, we actually require some ES2018 it seems). —TheDJ (talk • contribs) 14:06, 11 April 2023 (UTC)[reply]
@TheDJ: that's a shame. Is it known why this change hasn't been made backwards compatible? ‑‑Neveselbert (talk·contribs·email) 09:07, 12 April 2023 (UTC)[reply]
How to get edit toolbars back?
I did some edits to my preferences and since then the top and bottom toolbars for edit no longer appear.
As a side note, is there a way to export wiki preferences to a file to use as supporting documentation in problem reports? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:30, 12 April 2023 (UTC)[reply]
What operating system and browser version are you using? Izno (talk) 16:13, 12 April 2023 (UTC)[reply]
@Chatul, the reason you no longer have the toolbar is because your browser does not support sufficient functionality in ES6. See #Tech News: 2023-14. Upgrading your browser or your OS and browser are your only recourses. Izno (talk) 17:35, 13 April 2023 (UTC)[reply]
To export your preferences you can copy or save the content at the following link:
the legacy (2006) toolbar@Chatul: Which toolbars are you talking about? If it's the legacy toolbar (as shown in the image to the right), then you will need to *disable* the "Enable the editing toolbar" option in the "Editing" tab, and make sure the "Enable the legacy (2006) editing toolbar" option in the Gadgets tab is enabled. As its description mentions, the former will override the latter. Writ Keeper⚇♔ 13:19, 13 April 2023 (UTC)[reply]
Do I have to log off and log back on for that to take effect? — Preceding unsigned comment added by Chatul (talk • contribs) 17:04, 13 April 2023 (UTC)[reply]
Reconstructing magic TOC
Would anyone be interested in reconstructing magic _ _TOC__ so that level2 headings create new columns?
The output would look like this, done manually just as an example, excuse the greek). I would like to do it, but I don't know programming. Perhaps, not so useful for encylopaediae, but for dictionaries -with repetitive standard headings-, extremely suitable. Thank you!! from el.wiktionary Sarri.greek (talk) 04:26, 6 April 2023 (UTC)\[reply]
YES! I came here to ask for a way to get a fully expanded clickable TOC, ideally next to the "Contents [hide]" link, e.g. "Contents [hide] [expand]" in the new skin. I really miss being able to skim all the subheadings which almost always appeared just after the intro in the old skin. Sandizer (talk) 12:33, 11 April 2023 (UTC)[reply]
To see a fully expanded TOC by default, this code in your common.css file should work (it works for me):
/* Auto-expand sections, and hide the H2-arrows */.client-js.vector-toc.vector-toc-level-1.vector-toc-list-item{display:block;}.vector-toc-toggle{visibility:hidden;}.vector-toc{padding-left:5px!important;}
Thank you so much, Jonesey95. Very useful. In addition, I was thinking of a module to create TOCs regardless of skins and csses. Directly. Thank you Sandizer, I like expanded ToCs too, but I also hope that editors can make different designs of ToCs for different kinds of pages with parameters. I believe that the table of contents, is the reponsibility of the editor and bodytext, not of outside areas, which, may repeat it, or not. Sarri.greek (talk) 05:18, 12 April 2023 (UTC)[reply]
I am experiencing difficulties with the coordinates for Barton Broad. If they are placed at the bottom of the article, the "Infobox park" at the top of the article shows a map with a red area indicating the outline of the Barton Broad nature reserve. If I place the coordinates in the infobox, however, the red area disappears. I have tried playing around with the parameters to coord, but with no success. I am aware that placing the coords in the infobox works for some articles (eg Hainault Depot), although that uses an "Infobox Railway Depot" rather than the park variety. Can anyone explain what is going on, please, and is there a way to fix it? For the moment, I have commented out the coords in the infobox. Bob1960evens (talk) 13:26, 7 April 2023 (UTC)[reply]
Adding |mapframe-wikidata=yes and fixing the coordinates seems to have done the trick. – Jonesey95 (talk) 15:34, 7 April 2023 (UTC)[reply]
Thanks for the assistance. I don't think I would have guessed the solution myself. Bob1960evens (talk) 16:53, 10 April 2023 (UTC)[reply]
Home for Podcast RSS Feed of Spoken Articles
I recently wrote a python script that parses Wikipedia:Spoken articles into a podcast RSS feed, currently published at https://wcast.me/sw (paste that into your podcast app and check it out! ) with MIT-licensed source code at https://github.com/xenotropic/spoken-wikipedia-rss (Open an issue if it doesn't work with your app). I created it to use personally, but it also just to fill an apparent hole. Wikipedia has 1600+ recordings of articles in English, and podcast RSS is the main way people look for audio in the world these days, for good reasons (used by apps designed for the purpose, download management, keeping track of what one listened to, etc.).
My question is: does it make sense for that RSS file to be hosted on Wikipedia somewhere? I don't mind hosting the RSS file, but neither do I really want to. There is an apparent logic that Wikipedia would host an index of its own content; there are various other RSS feeds that Wikipedia publishes. It also would be nice if the RSS feed could not be buried in "external links" at the bottom of whatever pages where it is referred to.
If so, how would I go about this? Is this a sensible thing to make a bot out of? So something that runs on my server but writes a file to wikipedia or commons? (Are there examples of bots that write RSS to Wikipedia? Or even of RSS being hosted/updated like that on Wikipedia? Might be MIME-type issues). Or is there some method by which I could propose that Wikipedia itself "adopt" the code and just run it internally? It's a single python file with 200 lines of code, so not a huge thing to review. The main dependency is on the structure of the Spoken Articles page itself, but that seems fairly stable. morrisjm (talk) 01:03, 9 April 2023 (UTC)[reply]
@Morrisjm: very cool! Have you checked out Toolforge before? You can host it there, for free.
Wikipedia has limited feed generation support, we have FeaturedFeeds, but that's designed for date-based content, and I'm pretty sure it doesn't support the podcast stuff. I suppose you could publish the feed to a wiki page and tell people to access it with ?action=raw, but that feels a bit sketchy. I think Toolforge would probably be a better fit. Legoktm (talk) 06:33, 12 April 2023 (UTC)[reply]
I was previously unaware of Toolforge, and it does look like the thing. Thanks! morrisjm (talk) 20:00, 12 April 2023 (UTC)[reply]
I don't know Japanese but based on Google Translate it's a page about Yoko Aki so it looks right. PrimeHunter (talk) 14:52, 11 April 2023 (UTC)[reply]
Can't edit Draft Talk from mobile
I asked at HelpDesk and was told "You can try the MediaWiki Support Desk or make a bug report at MediaWiki", but before venturing into that alien territory (which presumably would lead me to Phab) I thought I would ask here.
I often edit from my Android Samsung mobile phone, as well as from my PC. I find that on my phone I cannot edit various talk pages other than article talk or user talk. This has been the case for some months; I raised it as a problem, I think in a zoom chat, and was asked for screenshots. Today I have at last discovered how to get a screenshot on this phone, so can read the error messages at leisure. So ...
I want to edit Draft talk:Honest History (magazine). If I use the "reply" link, I get a red box above my input saying "invalid response from server". If I click "read as wiki page" and do an ordinary edit (not VE), I get a red box saying "Error, something unexpected happened upon loading the preview. Please close and try again."
What is happening here? Can I fix it? Or are mobile editors considered to be an underclass who don't need access to backstage areas like Draft Talk?
To be honest I don't really know whether I'm using Chrome or the app: I start off by clicking a Chrome icon saved onto my home screen which gets to my watchlist, but then keep swapping between different configurations, in and out of "read as wiki page" and "View article in browser / on desktop" in an attempt to do whatever I'm trying to do: all a bit of a nightmare. I have another icon which might be the app but gets me to similar pages. In most cases I can find a workround, but contributing to Draft Talk pages, and various other Wikipedia Talk (non-article, non-user) pages, seems to be beyond the possible. PamD 09:54, 9 April 2023 (UTC)[reply]
@PamD assuming you are using a browser, scroll all the way to the bottom of the page and click the "Desktop" link to get a more full set of controls. If you prefer to use mobile web exclusively just uninstall the app from your mobile device. The edit you made to this page right now appears to be NOT in the app, and NOT in the mobile ui. — xaosfluxTalk 14:43, 9 April 2023 (UTC)[reply]
@Xaosflux I was editing on the desktop by the time I got here, and am now. This earlier edit was from my phone. Going in and out of the desktop version doesn't help on talk pages: clicking "desktop" at the bottom produces the same page, clicking "Read as wiki page" gets the banners displayed but makes no other difference. If I click on the "reply" option I get an input box, when I type and hit the blue "Reply" I get a red error box saying "Invalid response from server". Consistently on the Draft Talk page mentioned above, but I've encountered it elsewhere too. PamD 15:08, 9 April 2023 (UTC)[reply]
This sounds a bit like an ad blocker thatis accidentally triggering on the javascript request made on the talk page. —TheDJ (talk • contribs) 08:02, 10 April 2023 (UTC)[reply]
FYI: Edit to MediaWiki:Userjsdangerous
Just a small note to let you know that I've made a minor edit to MediaWiki:Userjsdangerous. We've been standardizing interface message boxes across MediaWiki for better accessibility and consistency so this change makes the message box you see when you edit JavaScript/CSS consistent with other message boxes across the site.
This results in a slight color change and padding change but no change to the text. Please let me know if there's any problem relating to this change. Jon (WMF) (talk) 16:52, 10 April 2023 (UTC)[reply]
This change removed the same styling in MediaWiki:Clearyourcache which has a transclusion of the page that is conditional on page load (so it would not have been noticed). Fixed. Izno (talk) 19:30, 10 April 2023 (UTC)[reply]
Tech News: 2023-15
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
There was a problem with all types of CentralNotice banners still being shown to logged-in users even if they had turned off specific banner types. This has now been fixed. [14]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 April. It will be on non-Wikipedia wikis and some Wikipedias from 12 April. It will be on all wikis from 13 April (calendar).
Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Moroccan Arabic Wikipedia, Danish Wikipedia, Dinka Wikipedia, Lower Sorbian Wikipedia, Ewe Wikipedia, Greek Wikipedia, Emiliano-Romagnolo Wikipedia, Esperanto Wikipedia, Estonian Wikipedia, Basque Wikipedia, Extremaduran Wikipedia, Tumbuka Wikipedia, Fulah Wikipedia, Finnish Wikipedia, Võro Wikipedia, Fijian Wikipedia, Faroese Wikipedia, Arpitan Wikipedia, Northern Frisian Wikipedia, Friulian Wikipedia, Irish Wikipedia, Guianan Creole Wikipedia, Scottish Gaelic Wikipedia, Galician Wikipedia, Gilaki Wikipedia, Guarani Wikipedia, Goan Konkani Wikipedia, Gothic Wikipedia, Gujarati Wikipedia, Manx Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [15][16]
I don't care about this enough to actually report it in the appropriate place, or even to figure out where that is, but based on the above 2nd item I went and looked at my Preferences/Notifications tab. I don't (yet) have "Edits to my user page" option (with plural "Edits"), but I do have an "Edit to my user talk page" and an "Edit to my user page". I thought they were duplicates until I caught the "talk" in the first one. My point: shouldn't these be right next to each other instead of 8 lines apart?
I don't know what's coming on Thursday, exactly, so maybe my whining is moot, but I also don't know why I already have something in my Preferences. Or is EN-WP a "test wiki? — JohnFromPinckney (talk / edits) 01:26, 11 April 2023 (UTC)[reply]
Notifications of user page edits are listed under "Recent changes" which means it already happened. I have tested the feature is working now. The new version of MediaWiki is listed under "Changes later this week".
uselang=qqx for Special:Preferences#mw-prefsection-echo says "(echo-category-title-edit-user-page: 1)". That means MediaWiki:Echo-category-title-edit-user-page is used with $1=1. The message source says {{PLURAL:$1|Edit|Edits}} to my user page so it appears it may both say "Edit" and "Edits". With $1=1 it says "Edit". Maybe the plural form is used in other languages where singular would be considered wrong or weird, but I'm just guessing here. The source text of the above tech news says {{int:Echo-category-title-edit-user-page}} with no parameter. {{PLURAL:$1|Edit|Edits}} displays "Edits" if $1 is empty. I guess the tech news writer didn't know or care about these details. PrimeHunter (talk) 02:34, 11 April 2023 (UTC)[reply]
Thanks, much, PrimeHunter, including the part where you read to me the "Recent changes" sub-head and politely explain that it means "recent changes". <Facepalm> what a doofus I am. I should either sleep more or write less. The rest was a bit over my head (even when I'm not too tired to read) but the qqx trick was fascinating; I'd never seen that before. — JohnFromPinckney (talk / edits) 05:24, 11 April 2023 (UTC)[reply]
Thanks, both of you. I believe I was thinking of the situation (which I am positive I have seen) where some feature is being rolled out to certain wikis first. LIke English and Albanian Wikipedias and Esperanto Wiktionary would all get Fixed-Width Pending IP Flow two weeks before all the other Wikimedia sites. Again, the tip (for me) is to read for comprehension, not scan for speed. And thanks for Special:SiteMatrix; I hadn't known about that. — JohnFromPinckney (talk / edits) 14:39, 12 April 2023 (UTC)[reply]
ddd numbers and HTTP status codes
ddd (disambiguation) pages do not include HTTP ddd pages....0mtwb9gd5wx (talk) 04:20, 11 April 2023 (UTC)[reply]
They are included if there is an article, except the proposed HTTP 451. Would readers expect lesser known codes like 505 to be found on "505" alone? A lot of things have names with a number at the end and we don't want to flood disambiguation pages with partial matches. PrimeHunter (talk) 13:10, 11 April 2023 (UTC)[reply]
Random picture from Wikimedia Commons
I would like someone to create Template:Random picture which basically retrieves a random picture from Commons (for userpages). I can't figure out how to do this myself so I'm asking for advice here.
Please ping me using {{ping|CityUrbanism}} in your reply. – CityUrbanism🗩🖉 17:05, 11 April 2023 (UTC)[reply]
@CityUrbanism, Commons already has commons:Special:Random/Image, so I'm thinking it shouldn't be too hard. ... is not how that works. You cannot do what you are asking onwiki. Izno (talk) 18:07, 11 April 2023 (UTC)[reply]
It would require a script to automatically be loaded by all users but there is no justification for that. Somebody might write a userscript users could choose to load for themselves but I think very few users would do it. I don't see anything relevant by searching for "random" at Wikipedia:User scripts/List. PrimeHunter (talk) 20:40, 11 April 2023 (UTC)[reply]
You could use the "randomly select from a list" approach. Just create a list of randomly selected images and change that list every week/month/whenever you get bored. —Kusma (talk) 20:49, 11 April 2023 (UTC)[reply]
I'm sure that RexxS (talk·contribs) wrote a random picture selector using Lua (so there will be a Module: somewhere). It didn't select from the whole of Commons, but from a preset list. --Redrose64 🌹 (talk) 21:47, 11 April 2023 (UTC)[reply]
I would add to the above that you definitely would want to use a predefined list. Commons has many, many images you probably do not want on your userpage. At best you would get poor-quality images, but you inevitably will get some seriously disturbing pictures.HouseBlastertalk 22:31, 11 April 2023 (UTC)[reply]
@HouseBlaster Yes, I've realised that would be a serious issue with this proposal. – CityUrbanism🗩🖉 22:34, 11 April 2023 (UTC)[reply]
What percentage of editors use VisualEditor?
I use VisualEditor for almost everything I do on Wikipedia, and I'm curious to see how many people share my editing workflow, because it seems that on most edit histories that I view, the article edit history consists mostly of regular edits, not VE edits. Where can I obtain statistics on the usage share of VisualEditor? Thanks! Félix An (talk) 12:23, 12 April 2023 (UTC)[reply]
There's probably some way to get more exact statistics, but I just checked Special:RecentChanges, with the filters "Human (not bot)" and "Page edits". Filtered for the tag "#Visual edit", the last 500 edits go back ca. 35 minutes, while with the filter "not #Visual edit", the last 500 changes only go back 5 minutes. So I'd guess that means approximately 1 in 8 human edits is done with VisualEditor. I'm not sure whether it's possible to get actual statistics "per editor" instead of "per edit", but I can imagine that it'd be a bit more than 1 in 8, because I think editors who make a lot of edits are more likely to use the source editor, but that's just my hunch. --rchard2scout (talk) 13:39, 12 April 2023 (UTC)[reply]
To improve on this method slightly, I think it's better to compare "#Visual edit" to "#wikieditor (hidden tag)" (to exclude edits made with various gadgets), and to limit the results to the main namespace (as usage in other namespaces is very different, e.g. templates and talk pages have ~0 VE edits for obvious reasons). With this method, the last 500 changes were made in ~40 minutes in visual mode [17] and ~10 minutes in wikitext mode [18]. Matma Rextalk 18:53, 12 April 2023 (UTC)[reply]
You've got me interested enough to write a proper SQL query and try to actually count the users. Here's the best I got: https://quarry.wmcloud.org/query/73006
In March 2023, excluding bots and counting only edits in the main namespace, ~18% of users used only visual mode, ~49% used only wikitext mode, and ~3% used them both for different edits. 30% of users used neither of the main two editors; I haven't tried to dig into this, but I think this mostly accounts for alternative wikitext editing experiences (e.g. the mobile site editor, AutoWikiBrowser, 2017 wikitext editor) and gadgets.
No promises that I didn't make some mistake in the query… I'm particularly surprised by the 3% figure. Perhaps someone is willing to review it, or explore different angles. Matma Rextalk 20:24, 12 April 2023 (UTC)[reply]
Are you surprised by the 3% because it seems low or high? If it seems high, it is possible that your query captured editors who made just one or two edits with VE, either unintentionally or because they were testing something. In the first three months of 2023, for example, I made 11,700 edits, including one lonely edit with VE. So I would be part of the "both editors" histogram column in a three-month sample. – Jonesey95 (talk) 20:38, 12 April 2023 (UTC)[reply]
It seems low. I read comments all the time from people who use wikitext except for tables, or who use visual except for templates, etc., so I expected to see more of them here. I use both editors myself as well, so maybe I'm biased (although looking at my edits in March, I guess I would be counted as a wikitext-only editor in this query). Matma Rextalk 20:52, 12 April 2023 (UTC)[reply]
Did your query account for "visual edit: switched" tags? I would expect people who use an editor for only one purpose are likely to switch mid edit. small jarstc 10:23, 14 April 2023 (UTC)[reply]
It didn't, but they should have been counted with the wikitext group (as that tag is only applied when switching to wikitext). I added it to the updated query below to be sure. Matma Rextalk 17:26, 14 April 2023 (UTC)[reply]
The 2017 Wikitext Editor is pretty much the source editor and should be included in that group. Snowmanonahoe (talk) 17:00, 13 April 2023 (UTC)[reply]
You're right, although it is used by very few people, so it barely has an effect on the results. Updated query: https://quarry.wmcloud.org/query/73050. Looks like about 0.5% of editors have used 2017 WTE, either exclusively or together with VE. Matma Rextalk 17:25, 14 April 2023 (UTC)[reply]
IMO it just makes the already-easy stuff easier and makes the other things that a newish editor needs to learn harder to learn. North8000 (talk) 14:16, 12 April 2023 (UTC)[reply]
I use both visual and source, frequently even using both in the same edit. I think markup and templating is far easier with source, while wikilinking and referencing (with the exception of {{sfn}}) is far easier with visual. I used to prefer visual for writing prose, but now I prefer source. Curbon7 (talk) 14:27, 12 April 2023 (UTC)[reply]
I use a mix of both. I say that because the 2017 Wikitext Editor (see Meta:2017 wikitext editor although it is out of date) is the Wikitext editor with tools from the visual editor (my favorite is the automatic citation tool which fills out all the needed params for {{cite web}} and various other citation templates automatically). I quite enjoy using it because it makes a lot of things easier while not limiting what I'm able to do (such as editing the Wikitext directly). ― Blaze WolfTalkBlaze Wolf#6545 14:35, 12 April 2023 (UTC)[reply]
Die-hard source editor here. Totally agree with North8000. I suspect that visual might help me with complex tables once in a blue moon, but that's about it. In bygone days I suppose I would have been one of those who complained about the invention of the wheel, but something in me totally rejects the idea of clicking on an icon when I know just how to do it by hand - a bit like constructing a long bash command line. I'm obviously somewhere on the scale... (I'm only happy when it rains, I only like it when it's complicated) MinorProphet (talk) 18:27, 12 April 2023 (UTC)[reply]
North8000, Curbon7, Blaze Wolf, MinorProphet: I do not think Félix An expects to derive statistics from people remarking (forum-style) on their preferences here. Félix seems to be hoping for a clearer, more immediate approximation of editor usage. — JohnFromPinckney (talk / edits) 23:44, 12 April 2023 (UTC)[reply]
This handy spreadsheet says in Column R that 9.2% of non-bot edits on English Wikipedia used visual editor (from the start of Feb 2022 to the end of Jan 2023). Other wikis are generally quite a bit higher. How it breaks down by editor tenure is an interesting question though. the wub"?!" 19:11, 12 April 2023 (UTC)[reply]
I use toolbars frequently rather than typing in, e.g., <ref>...</ref>, -- ~~~~, and VE seems to lack those. Add in its very sluggish performance and I generally strive to avoid it. What I'd really like is a snappy visual editor with all of the tools available in the regular editor. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:33, 14 April 2023 (UTC)[reply]
CS1 maint: url-status
Greetings, keepers of the eternal flame! I have sort of asked this question before, but can't remember if it was here or elsewhere. I have one of those very useful JS scripts installed (specifically for {{sfn}} errors) which also alerts me to CSI maint messages, which I often attempt to fix when I randomly come across them. But what is the point of the url-status messages, especially when they result in |url-status=live? Apparently a bot inserts them, but why? If a link is dead, that would make sense, but since a huge number of links are live, why go around letting everyone know all is fine? And why only some links on a given page rather than all of them? If the link is dead, I'm more than happy to see if it's on Wayback and amend as appropriate. And then what to do with the param? Or is it just statistics for the sake of statistics? :) MinorProphet (talk) 19:02, 12 April 2023 (UTC)[reply]
Without |url-status=live the title of the webpage links to the archive version. Nardog (talk) 19:06, 12 April 2023 (UTC)[reply]
The maintenance message you speak of pertains to CS1/2 citations which have a status of live but which do not have an archive URL. Izno (talk) 19:10, 12 April 2023 (UTC)[reply]
Thanks for your replies. I came across this most recently in Telluric iron:
<ref name=MinDat-2063>
{{cite web
|title=Hatrurim formation, Middle East
|website=MinDat
|place=Keswick, VA
|publisher=Hudson Institute of Mineralogy
|url=http://www.mindat.org/loc-2063.html
|url-status=live
|access-date=2021-12-31
}}
</ref>
I don't think of myself as any sort of gnome, but should I run IABot in these cases? MinorProphet (talk) 11:11, 13 April 2023 (UTC)[reply]
I'm fairly gnomish, and I don't much enjoy the needless addition of archive links to perfectly good references. This one is live, and the IA Wayback Machine tells us that the source was "Saved 74 times between November 13, 2003 and April 8, 2023." So no need to add more wikitext to the page.
What I might do, if I were making other changes on that page, is eliminate the unnecessary spaces in the ref citation. I see while in edit mode that the cite template is in expanded, one-line-per-parameter format, including a separate, ridiculous line for " }}" (space included), but as a minimum I would sneak the closing "}}" to come immediately after the access-date, and maybe even move the </ref> to come right after the ""}}"". Also I would determine a date format for that page and apply it everywhere (using a script). Also, I would delete the |place= parameter as meaningless for a website. And I would delete the |url-status= param completely, eliminating the error. — JohnFromPinckney (talk / edits) 14:46, 13 April 2023 (UTC)[reply]
You have two options: One is to fill in the archive URL (and date), either manually or with IABot, and the other is to remove the parameter and value (assuming the webpage at the URL is alive). Izno (talk) 18:15, 13 April 2023 (UTC)[reply]
Is there an easy way to suppress the display of CS1 maint:url-status messages (which for me are just a distraction) while keeping the rest of the citation related messages? —Kusma (talk) 12:10, 13 April 2023 (UTC)[reply]
No. This could potentially be added, and it has been brought up at least once on WT:CS1. Further discussion should occur there. Izno (talk) 18:15, 13 April 2023 (UTC)[reply]
Thanks all for your helpful suggestions. Cheers, MinorProphet (talk) 22:25, 13 April 2023 (UTC)[reply]
This morning I am suddenly finding myself unable to click on any links in articles or in article toolbars when viewing articles using the Vector2022 style. I had to change my preference back to monobook to get anything to work again. It is not a browser issue; I tried restarting my browser, without any change, and pages outside Wikipedia work fine, as does Wikipedia under monobook. Anyone know what is going on and how to fix it? —David Eppstein (talk) 18:40, 13 April 2023 (UTC)[reply]
Try safemode first to see if it is a gadget or user script. (WP:ITSTHURSDAY, so you may not be crazy.) Izno (talk) 18:47, 13 April 2023 (UTC)[reply]
Also try to log out. What browser and what version of your browser are you using? Please give an example link which doesn't work. Are Example and The Example broken? Does Vector legacy work? PrimeHunter (talk) 19:28, 13 April 2023 (UTC)[reply]
Alice Cooper, among others, exhibits this bug on Chrome Version 111.0.5563.148 on Windows 10. Vector legacy and MonoBook work. This is not consistent across articles, and on SOME articles (Republic of Ireland) refreshing or hard refreshing solves the problem at least until the next time the page is navigated to. It appears to happen sporadically - opening a new window (still signed in) might make links clickable, and might not. The top bar is functional at all times, though. PriusGod (talk) 21:24, 13 April 2023 (UTC)[reply]
Something similar has been happening to me off and on all day. I'll load a page, and for about a minute, won't be able to click anything below the title/languages bar at the top. Refreshing doesn't fix it at first; eventually a refresh does make the problem go away, and switching to Vector Legacy also makes the problem go away. It happened on this very page just now (also over at Giétro Glacier, which I was reading when I noticed the problem again and decided to report here). It's happened in both Firefox and Edge. 199.208.172.35 (talk) 21:22, 13 April 2023 (UTC)[reply]
I'm seeing this problem with the Fritos article in Chrome, also in incognito mode. From inspecting the page it seems that the article text is covered by a giant checkbox? See screenshot at right. —Bkell (talk) 21:23, 13 April 2023 (UTC)[reply]
This is being tracked at phab:T334699 but we are having trouble getting replication steps. If someone is still seeing this please could you share the raw HTML (obtained via view sourcd) on the ticket to help us replicate this. Thanks in advance! Jdlrobson (talk) 22:15, 13 April 2023 (UTC)[reply]
Deceptive diff
Considering this diff, why does it reflect the removal as if I'd removed the preceding span's closing tag and then the removed span less its closing tag when in fact I had removed the entire relevant span beginning with its opening tag and culminating with its closing tag? --John Cline (talk) 23:34, 13 April 2023 (UTC)[reply]
Diffing is hard. That's the only real answer.
(I use WikEdDiff available in your gadgets for a smoother experience.) Izno (talk) 23:36, 13 April 2023 (UTC)[reply]
It doesn't track what you actually do in the text area before saving. It just compares the before and after and shows one of multiple ways to get there. I don't think MediaWiki's diff engine is particularly good at giving a plausible way but I have never seen it give a wrong diff, meaning a way that wouldn't actually get you from the before to after. I recommend enabling wikEdDiff but I don't display it by default. If the MediaWiki diff looks poor then I examine the wikEd diff and often prefer that. But it also has weaknesses and is sometimes worse. PrimeHunter (talk) 00:00, 14 April 2023 (UTC)[reply]
I agree that the diff isn't, in and of itself, wrong; I suppose it's literally impossible, in computational terms, for the machine to err. In practical terms, however, it is deceptive and could leave one with the wrong impression regarding another one's technical competence. As it is, I was compelled to hurriedly verify that I hadn't made such a mistake which would have resulted in a cut and paste move that published inoperable HTML. And if such a diff can engender doubt within myself, it's certainly fair that it could engender doubt within others. Perhaps, in the end, skepticism is more empowering than misplaced confidence; to that end, I may be indebted to software that might have caused many to look deeper at me, longer than they otherwise would, to ultimately develope confidence with less concern that it could be misplaced. One thing that is sure, it all works well in the end. I was, nevertheless, curious and thank you for your reply. --John Cline (talk) 01:05, 14 April 2023 (UTC)[reply]
"Show changes" produces the same diff as after saving. I sometimes tweak an edit before saving to give it a better looking diff. A good edit summary also helps. PrimeHunter (talk) 04:58, 14 April 2023 (UTC)[reply]
Good advice, I appreciate that. I definitely endeavor to leave a good edit summary; especially after they increased the allowable size for it. I almost always preview changes I've made before publishing but never really made use of the feature to show changes; I intend to begin using it as you described and anticipate that it will be helpful to me. Thanks again for your replies and be well. --John Cline (talk) 20:16, 15 April 2023 (UTC)[reply]
Click the green triangle here to see the wikEd diff without having to enable anything. The link also works for IP's. PrimeHunter (talk) 00:12, 14 April 2023 (UTC)[reply]
How to wrap signature markup as sample mediawiki text
I expected {{code}} to wrap its parameter in <nowiki>...</nowiki>, and attempted to do {{code|-- ~~~~}} to display -- ~~~~ as example (grey background) text; the signature markup was expanded; I had to wrap the markup in an explicit <nowiki>...</nowiki> to suppress rendering as a signature. Is there a cleaner way to do this? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:48, 14 April 2023 (UTC)[reply]
{{code|-- ~~<nowiki/>~~}} → -- ~~~~ is how I usually do it. – Jonesey95 (talk) 13:20, 14 April 2023 (UTC)[reply]
A-class article assessment
How to start article assessment for A-class? Eurohunter (talk) 14:00, 14 April 2023 (UTC)[reply]
A-class isn't really used anymore. If you have a good article that you think can pass an even stricter evaluation, the next step is featured article candidacy. Thebiguglyalien (talk) 16:30, 14 April 2023 (UTC)[reply]
@Thebiguglyalien: If A-cass is not used anymore, what about remove it and keep in archive? Eurohunter (talk) 20:14, 14 April 2023 (UTC)[reply]
I think the only project that really uses A-class still is WP:MILHIST. Galobtter (talk) 20:24, 14 April 2023 (UTC)[reply]
@Eurohunter: See WP:ACLASS, but check that the WikiProject concerned not only recognises A-Class but has a formal assessment procedure. If you look at Category:A-Class articles, you will see that of the hundreds of WikiProjects where A-Class is valid, most of the subcategories are empty - very few actually have any A-Class article. --Redrose64 🌹 (talk) 22:55, 14 April 2023 (UTC)[reply]
Apparent vandalism with disgusting images on mobile app
It's impressive how long something is caching the rendering of these pages for the Android app (and maybe iOS app as well). There were two other pages that were actively serving vandalized short description as of April 8 until I published new versions of the pages: Wikipedia:Teahouse/Questions/Archive 1185#Issue with short descriptions. So it's possible they were still serving the old content and someone purged/did a null edit that finally forced cache invalidation (this is just a guess). Skynxnex (talk) 17:44, 14 April 2023 (UTC)[reply]
Strange appearance in watchlist
Hello! About an hour ago, the cosmetic design of my recent changes and watchlist changed to something that looks a bit odd. If an editor more technically minded than me could explain what's going on I would be appreciative. Images are https://filebin.net/l9g4636rgl3exqq8, note the bullet points missing and odd looking log entries. It is like this for all platforms and browsers. I have checked, and it is fine on Commons. It seems to only be EnWiki.
As the quality of the images on the filebin are very low, here's an explanation of what to look for. Hist and Diff links are moved to after page title. Bullet points are gone, apparently replaced with the UCT time of edit, and entries are indented weirdly. Public logs are looking very odd: they only state the editor doing the action. Schminnte (talk • contribs) 20:44, 14 April 2023 (UTC)[reply]
Hi @Schminnte, apologies if I misunderstood what is unexpected for you but I believe you may have enabled grouping. You can turn it on or off by clicking the gear button near the top-right of the watchlist or going to Special:Preferences#mw-prefsection-rc and looking for "Group changes by page in recent changes and watchlist". I find it somewhat useful since it can show more articles on a screen at a time, even if there were many edits to some. Skynxnex (talk) 01:15, 15 April 2023 (UTC)[reply]
I also had my watchlist change and found that the group changes by page setting had been enabled. I did not enable it through either of those methods though. Do you happen to know if there is a keyboard shortcut that might be applicable? isaacl (talk) 04:48, 15 April 2023 (UTC)[reply]
@Skynxnex, you're right! That fixed it. I'm not sure how that happened, so thank you for recognising that. Schminnte (talk • contribs) 08:11, 15 April 2023 (UTC)[reply]
Glad I could help! Skynxnex (talk) 14:53, 15 April 2023 (UTC)[reply]
Sorry @Isaacl, I don't know if there's a keyboard shortcut. I looked briefly and couldn't find anything. Skynxnex (talk) 14:52, 15 April 2023 (UTC)[reply]
Images not displaying in the Android app
Is anyone looking into this? Except for the first imsge in an article, captions only are displayed. Images do work in a mobile browser which iscreally annoying because like I don't already habe enough browser tabs open. 2601:1C0:CC00:45D0:A8FB:FF04:A450:D26D (talk) 07:52, 15 April 2023 (UTC)[reply]
I've had cause twice today to use the Undo tool to revert a non-constructive edit, and in each case when attempting to publish, I'm served a page reading The editor will now load. If you still see this message after a few seconds, please reload the page. Reloading gives me a "URI too long" error. Entering desktop mode allowed me to publish the revert. I saw another mobile editor at the Teahouse experience this issue (courtesy ping @Wikiexplorationandhelping:), and since I've just duplicated the behaviour moments ago and don't know how to file a bug report in phab I thought I'd come here. I'm on Firefox 111.1.1 on Android 11. I don't know what skin my mobile view uses or if that could even be relevant. Folly Mox (talk) 09:25, 15 April 2023 (UTC)[reply]
Hello there, Folly Mox. I appreciate the ping :D. Yeah, I have the same problem as well. The undo button has not been working properly; as such, I will troubleshoot this on the desktop version. If you want to, you can also go to the desktop version of Wikipedia on a shortcut I have put in my talk page. Conversely, there's also a link there to go back to mobile version for convenience. I personally like to use mobile version more though. Wikiexplorationandhelping (talk) 16:26, 15 April 2023 (UTC)[reply]
Update: The undo tool does work in desktop version. Regardless of that, this issue should still be fixed. Wikiexplorationandhelping (talk) 16:29, 15 April 2023 (UTC)[reply]
Do you have a link to the page where this occurred? Nardog (talk) 17:02, 15 April 2023 (UTC)[reply]
The pages in my case were King Wu of Zhou and Talk:Laozi. The edit I reverted on the second page has since been suppressed. Folly Mox (talk) 18:41, 15 April 2023 (UTC)[reply]
Ah, I missed that you had to click "Publish changes" (or "Show preview" or "Show changes" for that matter) to reproduce it. Phab task filed. Nardog (talk) 19:20, 15 April 2023 (UTC)[reply]
pageviews.wmcloud.org
There is no older views statistics than 2015? Eurohunter (talk) 11:22, 15 April 2023 (UTC)[reply]
The FAQ points to stats.grok.se, which is down, which points to WikiShark, which appears to be working and provide stats back to 2008. Nardog (talk) 15:04, 15 April 2023 (UTC)[reply]
Is there a way to get a list of all pages at "https://dnd.wizards.com/" that are currently being used as sources on Wikipedia? I have been advised that they plan on getting rid of that domain entirely and putting all of their new content on a new site, and that they have a track record of just deleting webpages instead of porting them over to whatever the new platform is, so I was hoping to make sure articles using those sources have archive links. BOZ (talk) 16:16, 15 April 2023 (UTC)[reply]
— TheresNoTime (talk • they/them) 08:19, 30 March 2023 (UTC)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 April. It will be on non-Wikipedia wikis and some Wikipedias from 5 April. It will be on all wikis from 6 April (calendar).
The deprecated 
In the visual editor, it is now possible to edit captions of images in galleries without opening the gallery dialog. This feature request was voted #61 in the 2023 Community Wishlist Survey. [12]
– CityUrbanism 🗩 🖉 18:26, 11 April 2023 (UTC)
