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.
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. — xaosfluxTalk21: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). — xaosfluxTalk00: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]
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. — xaosfluxTalk09: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]
@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]
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 jarstc09: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 jarstc15:41, 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. ToaNidhiki0501:27, 1 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]
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]
@Aaron Liu: Are you referring to where we replace the class name to switch? If you are I do it that way because the WMF's existing code does it that way and I wanted to minimize changes. BilledMammal (talk) 19:26, 16 April 2023 (UTC)[reply]
Nevermind again, I was right the first time. Wouldn't the logged-out users snippet change the behavior for every wiki instead of delegating the preference to a variable? Aaron Liu (talk) 20:38, 16 April 2023 (UTC)[reply]
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.
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]
FWIW, I've pushed out __ARCHIVEDTALK__ to some of the major talk archive temples, will take a while for transcluded pages to get updated. — xaosfluxTalk13: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]
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]
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]
@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]
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 [12] and ~10 minutes in wikitext mode [13]. Matma Rextalk18: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 Rextalk20: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 Rextalk20: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 jarstc10: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 Rextalk17:26, 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#654514: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]
Visual editor: I typically use visual editor for everything I can. I resisted this for quite a while, but visual editor evolved quite rapidly and in the right direction. One of the things that would be useful is a drive to add content to templates to make them fully compatible with the visual editor. I find it unfortunate that I cannot use visual editor for talk pages, actually. There are, of course, things that are much easier in wikitext or even impossible in visual editor, so I am a switcher on an as needed basis. --User:Ceyockey (talk to me) 01:34, 18 April 2023 (UTC)[reply]
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]
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'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]
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]
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]
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]
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]
@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]
Example of what my watchlist used to look like.Example of what my watchlist looks like now.
I signed up to the mentor list today and my watchlist seems to have subsequently changed format. In the past the (diff | hist) options appeared to the left, but now they're appearing in the center. Can anything be done to bring the old format back? — Nythar (💬-🍀) 00:45, 16 April 2023 (UTC)[reply]
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 have the same problem but on iOS. I’m currently on the app right now, and I can only see the top image, but the rest are only captions. Hummerrocket (talk) 03:29, 16 April 2023 (UTC)[reply]
We reverted a patch that landed last week that combined with caching caused the issue. I added some details for the root cause at the ticket. For new requests things should be working fine. In case JS assets are cached on the client side images are going to be eventually fixed when client side cache expires. JGiannelos (WMF) (talk) 16:07, 17 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]
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]
Maybe they're using different criteria or timezone? WikiShark appears to be roughly equivalent to pageviews.wmcloud.org when you set the platform to "Desktop" and the agent to "User". Nardog (talk) 18:51, 17 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]
Due to the recent creation of new {{MilAward Desc}} and {{MilAward Ribbon}} templates to format military decorations in articles, there's a cluster of redlinked "Recipients of [military award]" categories that keeps turning up at Special:WantedCategories because the creator of the templates used complex module coding (see Module:MilAward) that's automatically generating them. They're typically populated by just one person, and thus can't necessarily be justified for creation yet — and while I have been able to make them go away by manually wrapping the implicated template in {{suppress categories}}, it isn't a viable long-term solution if this continues.
As of now, they've all been cleaned out with the suppress categories wrapper, but the problem is likely to recur in the future. So I wanted to ask if somebody with more experience in JavaScript coding than I've got can (a) ensure that the module only generates categories that exist, while not generating redlinks, and (b) ensure that the module suppresses all categories if the template is used on draft or userspace pages?
2. Check that the categories exist before adding them. Like this:
localcategoryTitle=mw.title.new('Category:'..mw.text.trim('Recipients of Order of Mendi'))ifcategoryTitle.existsandnotcategoryTitle.isRedirectthen-- category exists and is not a redirectelse-- category does not exist or is a redirectend
localnamespace=mw.title.getCurrentTitle().nsTextifstring.len(namespace)<2thenlocalrecipcat=data[code].RecipCator""-- If there is a recipient category specified, then add it to the outputoutput=output.." [[Category:MilAward Ribbon Description]]"-- Add tracking Categoryifstring.len(recipcat)>0thenlocalcategoryTitle=mw.title.new('Category:'..mw.text.trim(recipcat))ifcategoryTitle.existsandnotcategoryTitle.isRedirectthen-- category exists and is not a redirectoutput=output.." [[Category:"..recipcat.."]]"else-- category does not exist or is a redirectendendend
Ok. It's clear now. It's a recommendation which is why I didn't focus on it too much. How much weight should I give the recommendation? BoonDock (talk) 20:14, 17 April 2023 (UTC)[reply]
As you say it's a recommendation rather than a bright line rule, some people do have very strong feelings about automatic categorisation, but there isn't an overall community consensus to ban it. If you're going to add automatic categorisation the most important thing is to make sure that it isn't disruptive, there are a lot of editors who work on categorisation, and having special:WantedCategories flooded with nonsensical categories or a bunch of non-articles showing up in content categories due to a malfunctioning module will upset people (as you've just seen). A few ideas you might want to consider include making sure only pages in the right namespace are categorised, making sure the template doesn't add non-existent categories and having some built in way in the template to disable automatic generation of categories for cases where someone wants to categorise an article manually. Bear in mind that regardless of how well written your template documentation is at some point someone is going to put something wrong into the parameters, your template needs to be able to cope with that. It might also be worth considering using a hidden maintenance category to track pages where the module couldn't add content categories automatically - in those cases it might be that either a new category is required or one of the input parameters is wrong.
Ok, that's fair. I have been addressing the issues as they've surfaced, but let me just enumerate them here.
Checks for namespace and any namespace other than main, nothing is added
Checks for non-existent category. Does not add
Checks for redirect category. Does not add
There is only one "recipient" category possible per entry in the data table. This can only be added by adding to the correct field in the data table. There is NO way to do this from the template, whether on purpose or by accident by misconfiguring. If a category is added to the data table, it goes through the checks above, so that should prevent 99.999% of those cases you refer to. If it's a "malicious" edit to the data table, that's the same as a vandalism/disruptive edit and will get reverted asap just like any article edit.
A flag on the template to prevent addition of the category is definitely a good idea. I'll write that in and report back when done.
Two things about the maintenance cat.
I've been beaten up enough about adding maint cats to want to avoid doing it at all.
I cannot see the utility anyway because the module is written as I've outlined above to make checks any way. It's difficult (impossible) to prove a negative. It would be simple to create a maint category for all pages where a recipient category HAS been created, and I'll happily do that if there is consensus that that's required.
I think that covers everything.
One further thought. This isn't about an arbitrary adding of categories. The thought is that if you add in the article a display of an award then you are saying that person is a recipient of the award and thus the category. What I have not catered for is the case where the template is used on a page about the award, which would add that page to the recipient's list. That is specifically where the toggle option in point 5. above would be perfect.
There is now a parameter option "nocat". Calling the template {{MilAward Desc|PP|nocat=AnyGarbageYouLike}} will stop it adding the categories.
ifstring.len(nocat)>1then-- If ANYTHING has been specified as a value for nocat, then it's true-- Do nothing or add to tracking category?else-- Need to exclude adding the recipient category if it is not in mainspace.-- for now, that means checking it's not in "Template:" or "User:" spacelocalnamespace=mw.title.getCurrentTitle().nsTextifstring.len(namespace)<2thenlocalrecipcat=data[code].RecipCator""-- If there is a recipient category specified, then add it to the output--output = output .. " [[Category:MilAward Ribbon Description]]" -- Add tracking Category -- Note commented outifstring.len(recipcat)>0thenlocalcategoryTitle=mw.title.new('Category:'..mw.text.trim(recipcat))ifcategoryTitle.existsandnotcategoryTitle.isRedirectthen-- category exists and is not a redirectoutput=output.." [[Category:"..recipcat.."]]"else-- category does not exist or is a redirect-- Add to a tracking Category ???endendendend
One further (belated) observation is that I might have predisposed people against what I'm doing during the development of the templates/modules. In my defence, I learnt to program in Lua three days ago ;-) Mea Culpa, mea maxima culpa. BoonDock (talk) 20:57, 17 April 2023 (UTC)[reply]
It's a caching - one that is known about, I think but I can't find the phab ticket - Flea was vandalised and the page preview is still picking up the text of the lead paragraph of the vandalised version. Nthep (talk) 21:42, 16 April 2023 (UTC)[reply]
Given that {{PAGESINCATEGORY:Candidates for speedy deletion as having been created by blocked or banned users}}}} is returning 2 (1), I'm guessing this is an issue along the lines of T224360, T85696 and/or T221795. recountCategories.php is run monthly which should prevent most drift, but it may need running again for enwiki — this recounts all categories though, so I wouldn't feel entirely comfortable running it without getting the OK from someone "in the know" — TheresNoTime (talk • they/them) 13:57, 17 April 2023 (UTC)[reply]
I received a (formerly known as Echo) notification of an email. From what I recall in the past, the notification shown when you click on the alert icon used to just say that you got an email from another user, as seen in the image at Help:Notifications § Email received. However this time there was a brief excerpt of the start of the message. I didn't think any of the message was stored. Has the message or an brief excerpt always been stored? isaacl (talk) 01:40, 18 April 2023 (UTC)[reply]
Thanks for the info! I see from the Phabricator ticket that the subject line is stored, unless it's the default, in which case the first line of the email is stored. That's good to know for privacy purposes... isaacl (talk) 02:02, 18 April 2023 (UTC)[reply]
Tech News: 2023-16
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
At Wikimedia Commons, some thumbnails have not been getting replaced correctly after a new version of the image is uploaded. This should be fixed later this week. [22][23]
For the last few weeks, some external tools had inconsistent problems with logging-in with OAuth. This has now been fixed. [24]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 April. It will be on non-Wikipedia wikis and some Wikipedias from 19 April. It will be on all wikis from 20 April (calendar).
Okay, that obviates my coming here to report that {{page views}} is broken everywhere. I'll subscribe here, but if you report elsewhere, please add a link here, and a {{tracked}} template, as appropriate so I can monitor. Thanks, Mathglot (talk) 09:47, 18 April 2023 (UTC)[reply]
Article/section Ittoqqortoormiit#Population contains a { { Graph:Chart } } construct that does not display in the Chrome or Firefox browsers.
Notes: I don't know how to suppress WP formatting inside editing panes. A Web search and a reading of the WP manual of style did not reveal how to do this. I don't know how to submit WP bug reports, nor do I wish to know. David Spector (talk) 12:37, 18 April 2023 (UTC)[reply]
I have created {{Graphs disabled}} for use on significant documentation pages. It can just be blanked when graphs are working again but I suggest to not add it to numerous low profile pages when the problem is expected to be so brief. PrimeHunter (talk) 13:06, 18 April 2023 (UTC)[reply]
I misread the intent of the template, but what I just did still feels like it works. See WT:WPAFC I'm not sure if this is a good solution as for those who are just browsing Wikipedia might not know what a template documentation page is and might be confused as to why the graph isn't showing. ― Blaze WolfTalkBlaze Wolf#654513:27, 18 April 2023 (UTC)[reply]
It was intended for documentation pages about graphs. I have added an option |missing for places where a graph should have been displayed. That's a lot of places and I'm not sure how many temporary notices it's worth adding. It would be more practical if any use of <graph>...</graph> automatically displayed an interface message like MediaWiki:Graphs disabled. PrimeHunter (talk) 13:56, 18 April 2023 (UTC)[reply]
That would definitely help. And I realized that its intended for documentation pages after i Had already added it because I read it too quickly. ― Blaze WolfTalkBlaze Wolf#654513:58, 18 April 2023 (UTC)[reply]
I for one oppose any need for a "Graphs disabled" message in mainspace; those in the know should just comment out graphs for the time being until this boondoggle gets fixed. (Hopefully this doesn't impugn on progress of inline SVG support.) – John M Wolfson (talk • contribs) 15:09, 18 April 2023 (UTC)[reply]
There is often associated content referring to the non-displayed graph. Commenting out the relevant parts may be non-trivial and it may not be uncommented quickly or at all when graphs return. The template can immediately be changed to display nothing when they return. If graphs were expected to be missing for a long time then a prettier but more work-demanding solution would be better but for a probably short term problem, I think it's good to have a simple option. PrimeHunter (talk) 15:24, 18 April 2023 (UTC)[reply]
Graphs are a very important part for illustration on Wikipedia. From "Demographics" section of geographical locations to "Polling" & "Results" section of elections to articles on geological periods to articles on a specific genus. I'd suggest that MediaWiki:Sitenotice be called with the text "Due to some technical issues, most Graphs on Wikipedia are not visible. Inconvenience caused is regretted." I said, "most graphs" because some graphs also exist as svg/png on commons with should be visible, and readers should not have to face technical jargon like "extensions", etc. —CX Zoom[he/him](let's talk • {C•X})16:15, 18 April 2023 (UTC)[reply]
If consensus exists for a notice, something simple and non-obtrusive, to the effect of "Graphs are currently unavailable due to technical issues", no template boxes or red error text, or anything too flashy, would probably be best while this is sorted. It's already embarrassing enough that stuff like this happens in the current year, we shouldn't bring too much flash or attention to it while the devs work to fix it. – John M Wolfson (talk • contribs) 16:20, 18 April 2023 (UTC)[reply]
Ahead of a proper communication that WMF is coming up with, I will say that it is now possible to display a custom message in place of the graphs, it is done by replacing MediaWiki:Graph-disabled content, empty by default, with a custom notice (such as an Ambox). There is also now a tracking category "Category:Pages with disabled graphs" showing the pages that used to contain graphs. The tracking category's name and description can be changed by editing MediaWiki:Graph-disabled-category and MediaWiki:Graph-disabled-category-desc interface messages. --Base (talk) 19:50, 18 April 2023 (UTC)[reply]
How about this?
Graphs are currently unavailable due to technical issues
As source of inspiration, in Ukrainian Wikipedia we currently went with a standard Ambox icon and "There was supposed to be a graph or a diagram here, but its rendering is currently disabled for technical reasons. Please do not remove the code that is causing this message. Developers are already working on restoring the normal rendering of the graph or diagram." --Base (talk) 20:13, 18 April 2023 (UTC)[reply]
The Stable Release field on the SponsorBlock infobox is broken, displaying every version number instead of just the latest. I've compared the wikitext for the infobox to other software articles and it looks to be the same so I've no idea what is actually causing this. It could be Wikidata itself causing the issue but I'm afraid I just don't know enough about this to tell. Any help would be appreciated as it's been like this for a number of months now. – Mesidast (talk) 10:21, 18 April 2023 (UTC)[reply]
As User:Jonesey95 pointed out the number of sites with this problem can be found using the search function here: currently 22 articles with this problem are found. --Kallichore (talk) 16:38, 18 April 2023 (UTC)[reply]
What's the best way to set my preferences for editing, particularly adding citations?
Besides the usual, eg a toolbar with strike, etc., I want to be able to add citations easily - ie for journals, news, books, etc by adding either details or using an url. I must have messed something up. Using the Vector 2022. Thanks. Doug Wellertalk16:14, 18 April 2023 (UTC)[reply]
@Doug Weller: Have you tried using the 2017 Wikitext Editor? While that does make use of the feature through a toolbar that sounds like what you might be looking for. ― Blaze WolfTalkBlaze Wolf#654516:23, 18 April 2023 (UTC)[reply]
@NardogNo, that's what I'm trying to get back. Wish I could have that with wiked but I don't think I can. I've tried to unclick most things. Did I always get a "Preview of references" and not notice it? I may have to give up tonight and comeback tomorrow with screenshots. Thanks. You've been great. Doug Wellertalk18:04, 18 April 2023 (UTC)[reply]
@Blaze Wolf@Nardog AGH! I've been checking it on Safari on my iPad, that's the problem. Well, I had lost it, but with help here I've got it back. I never add sources using Safari on my iPad and it just slipped my mind that I'm a Chrome user on my PC which is what I normally use to edit. iPad's just to clumsy. So I've got wikEd and Reftoolbar 2 now, life is good. Doug Wellertalk18:36, 18 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 
The Special:GlobalWatchlist page now has links for "mark page as read" for each entry. This feature request was voted #161 in the 2023 Community Wishlist Survey. [21]
