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.
@Vchimpanzee: At {{If IP}}(the template used in that talk page) do you see both messages?
The template uses -show classes, so both the logged out and the logged in messages are there in the page, it's just that either one or the other is hidden(using CSS) if you aren't part of that user group - so technically if you are seeing both messages you could work around this by adding to your common.css the line .anonymous-show { display: none !important; } (to mirror what should have been set automatically at MediaWiki:Group-user.css).
Do you remember if you ever made any personal CSS or Javascript changes to enable seeing messages for anonymous users? I didn't see anything in your common.css or common.js file that seems to affect this, but perhaps you have a different customization file somewhere, or you set up globally-used files on mediawiki.org? isaacl (talk) 16:29, 5 September 2023 (UTC)[reply]
You are not logged in.You are currently logged in.
I only see "You are currently logged in", as intended. If you also or only see "You are not logged in" then which device or browser are you using to view this page? If it's a Windows browser then does it make a difference to press Ctrl+F5? PrimeHunter (talk) 20:01, 5 September 2023 (UTC)[reply]
You are not logged in.
I only see "You are currently logged in", as intended. If you also or only see "You are not logged in" then which device or browser are you using to view this page? If it's a Windows browser then does it make a difference to press Ctrl+F5? PrimeHunter (talk) 20:01, 5 September 2023 (UTC)
My keyboard has bunch of symbols up there and even with my new bifocals the only one I can see clearly enough to recognize is a magnifying glass. It's the ninth key to the right of ESC.
Not a laptop. Anyway, we're trying to solve an unrelated problem, and the original problem is one I don't even care that much about, but we have possible solutions here for that.— Vchimpanzee • talk • contributions • 19:57, 6 September 2023 (UTC)[reply]
I see you have a meta:User:Vchimpanzee/global.css file, but I don't believe anything in it would cause messages for non-logged in users to display. The only other thing I can think of is somehow MediaWiki:Group-user.css never gets loaded for you, but I don't know what might be causing that for your case (it should be loaded for all logged-in users). Have you tried logging out and logging back in again? Maybe there's some server state that's out of synch. isaacl (talk) 17:54, 7 September 2023 (UTC)[reply]
Help needed with saving pages to a web archive
I would like to save several pages of handball leagues to a web archive, but only partly succeed to do so.
The "fixtures", "results", "standings" and "matrix" (mix of fixtures and results) of those leagues can be viewed on the website of the Netherlands Handball Association (NHV).
Select "PROGRAMMA/UITSLAGEN/STANDEN" (Fixtures/Results/Standings) from the menu in the top black bar.
Select "POULES" from the orange oval.
Select the "Zaal" (indoor) entry from the "NHV Landelijk" line/section.
Select the "Heren BENE-League" entry.
from the "Poule BENE 23-24" line/section select either
"Programma" (Fixtures) or
"Uitslagen" (Results) or
"Standen" (Standings) or
"Matrix"
After the last selection you get the related info. You can switch between "Programma" (Fixtures), "Uitslagen" (Results), "Standen" (Standings) and "Matrix" info by selecting the corresponding tab. Don't use your browser functionality to go to the previous page in your browsing history (left arrow button before the address bar), it will result in having to go thru the menu all over again.
To my knowledge none of these pages can be saved on a web archive service like Wayback Machine or Archive.Today. This is caused because these pages are retrieved using HTTP POST requests contrary to HTTP GET requests.
These pages can also be retrieved using CURL on the command line:
A display string, which is not really relevant. For the league above it would be "NHV+Landelijk+^%^7C+Zaal+^%^7C+Heren+BENE-League+^%^7C+BENE+23-24" ("NHV Landelijk | Zaal | Heren BENE-League | BENE 23-24") without the double quotes.
35670
the ID of the league. Other leagues are e.g. 35674 for the "Heren Eredivisie" (Men Eredivisie) league or 35715 for the "Dames Eredivisie" (Women Eredivisie) league.
There's a undocumented way the request these pages in your browswer where an HTTP GET request is used:
Using these URL's clearly shows the effect of the display string XXX.
Changing 35670 into 35674 or 35715 will give the info for the other leagues mentioned above.
Using these URL's, the pages partly can be saved in a web archive.
Using:
Web Archive
Comment
WayBack Machine
None of the pages can be saved. WayBack cannot handle the "#" (anchor indicator) in the URL. Basically everything after the "#" is ignored.
Archive.Today
Creates a correct copy for the "Programma" (Fixtures) and "Uitslagen" (Results) pages. However not for the "Standen" (Standings) and "Matrix" pages.
It's exactly the 2 pages I'm mostly interested in, for which it's not possible to create a web archive copy. End of season the "Programma" (Fixtures) is empty anyway. The "Matrix" page only contains results at the end, and I prefer the matrix representation of the results above the list presentation on the "Uitslagen" (Results) page.
At the start of a new season the pages of the previous season are no longer available. Hence I would like to have a web archive copy to use as reference.
Does anyone have an idea how to create a web archive copy of the "Standen" (Standings) and "Matrix" page. I don't care which method and web archive is used, as long as I get a proper web archive copy.
@Neils51: Thanks for your effort tp come up with a solution. Unfortunately it doesn't give the desired result. I tried it for a different league, 35715=Women Eredivisie.
So, with HTML URL Encoding I get the same results on WayBack Machine as on Archive.Today without encoding. Actually, I normally already use encoding because instead of "XXX" I mostly use "%20".
Furthermore, there're 2 additional "problems" with using WayBack Machine suitable UEL's:
Browsers can't handle the encoded URL's, "%20" instead of "XXX" is no problem, but "%23" instead of "#" results in an HTTP 404 error.
Wayback Machine has issues anyway, too often it seems to make a copy, but you get the message "There was a delay in registering this snapshot with the Wayback Machine. You may be redirected to a previous version right now. This snapshot will be available later." And it seems to me that the snapshot never gets registered and you're always redirected.
I feel sure this is a known bug but I couldn't find it on Phabricator. The entry above appears on my watchlist. The problem is that the link to en:Starý most actually points to wikidata:Starý most which does not exist. Similar with the link to en:Starý most (Bratislava) — Martin (MSGJ · talk) 17:16, 6 September 2023 (UTC)[reply]
I can reproduce it by watching Starý most (Bratislava) (watch the redirect, not the target) and enabling "Show Wikidata edits in your watchlist" at Special:Preferences#mw-prefsection-watchlist. This is phab:T186629 from 2018, the first search result on "Language link changed from". The original edit was the local move [1]. It triggered a Wikidata edit [2] which created the watchlist entry with wrong links. The HTML for the links:
<span class="comment">(Language link changed from <a class="external" href="https://www.wikidata.org/wiki/Star%C3%BD_most_(Bratislava)">en:Starý most (Bratislava)</a> to <a class="external" href="https://www.wikidata.org/wiki/Star%C3%BD_most">en:Starý most</a>)</span>
The same error happens for other watchlist entries about Wikidata edits caused by moves at the English Wikipedia. If a move was at another Wikipedia language then the links go correctly to that wiki.
For me the watchlist entry at least gives the correct name "Starý most (Bratislava) (Q435423)" for wikidata:Q435423. Your screenshot says "List of crossings of the Danube (Q435423)" which appears to be a separate error. "List of crossings of the Danube" is wikidata:Q911165 which hasn't been edited since June. PrimeHunter (talk) 19:52, 6 September 2023 (UTC)[reply]
Yes, List of crossings of the Danube is correct because I am watching that article and it uses many entities including Starý most (Q435423). T186629 looks like the right bug, well done for finding it. So the only question is why it takes 5 years to fix something apparently so simple. — Martin (MSGJ · talk) 21:24, 6 September 2023 (UTC)[reply]
Happy Thursday! Some of these pencil icons are pretty big now! On the Refdesks, the "edit" icon for the date sections seem like they're scaled 2x the individual questions. Meanwhile I had a look at a mainspace article and the icons to edit lvl3s are larger than the ones to edit lvl2? Then lvl4s and lvl5s are back down to normal size (see History of China for an example lvl5 subheadings in the wild). I don't think I have anything turned on that would affect this. Minerva, Firefox, Android, if any of that matters. Just some brief feedback. Folly Mox (talk) 07:50, 7 September 2023 (UTC)[reply]
Hmm I do note that I'm now unable to edit AfDs by tapping the pencil icon from the daily transclusion log. It just recollapses the AfD entry, so now I have to go to the article, open the AfD notice, then click through to the individual discussion before I can edit (unless I'm using ReplyTool, which is not always possible, for example after a relist). Pretty sure this behaviour isn't intended, and I'm pretty sure it started the same time the pencils became engorged. Folly Mox (talk) 18:53, 10 September 2023 (UTC)[reply]
When one hovers over certain links, a popup shows some initial text and an image. Here are some examples:
religious terrorism, religious violence and terrorism.
The religious terrorism image is File:Lipoma 04.jpg, which documents a surgical procedure and has nothing to do with the topic except perhaps to suggest dismemberment. The image selection seems to be part of the hovering mechanism, but I haven't been able to figure out where that mechanism gets images. I could only find the image on Commons by asking my browser to copy the image link. The ability to include images in hover-over popups without any review has obvious NPOV issues. How does this mechanism work, who decides which images are appropriate and how can choices be challenged?--agr (talk) 16:48, 7 September 2023 (UTC)[reply]
It seems to be less targeted than that. I came across this while looking at Category:Numeral systems. I thought it was targeting South Asian languages at first but Etruscan numerals and Georgian numerals are also affected. The documentation for popups states that images are sourced through the PageImage Extension, which claims the associated image can be seen in the page information, but all the pages I've checked dont have an image listed there at all. I suspect someone may have hidden it in a common template but I don't know if that's even possible. It's definitely a serious exploit though. krytton (a) 17:59, 7 September 2023 (UTC)[reply]
The image is chosen by mw:Extension:PageImages#Image choice. A vandalised template in the lead can cause a bad page image. The preview is made by mw:Page Previews which uses caching, so a former page image may be displayed in previews for a while. "Page information" shows the current page image which may be different from one still used in previews. PrimeHunter (talk) 18:56, 7 September 2023 (UTC)[reply]
There appears to be an issue with Template:Advert not displaying in Firefox (my version is 117.0). The page does not load and only displays a white blank page. This also means any pages with the template do not display the template while the rest of the page does display. Osarius09:01, 8 September 2023 (UTC)[reply]
Not experiencing this on Firefox 117.0 on macOS. Could it be an extension, maybe an adblock cosmetic filter that filtered it as a likely advert? DFlhb (talk) 09:16, 8 September 2023 (UTC)[reply]
Not experiencing this either. I have bunch of extensions enabled among which includes adblockers with bunch of filters enabled (none are cosmetic) and trackers blockers, and Firefox built-in Enhanced Tracking Protection enabled in Custom mode. If you haven't done so, try launching Firefox in Safe mode and visit the Template:Advert and see if it's displaying. —Paper9oll(🔔 • 📝)09:59, 8 September 2023 (UTC)[reply]
I see the template as normal on Firefox 117.0. However, I've whitelisted Wikipedia in my ad blockers. I expect one of your extensions thinks that a page called Advert might be an advert. Certes (talk) 11:14, 8 September 2023 (UTC)[reply]
A bug with OpenStreetMap maps in Wikipedia Infoboxes
Hi, in the case that coordinate of a place is entered inside the Infobox of an article, then incorrectly red colored area indicator of that place is not shown in the map of that Infobox. For example, if we place coordinates of National Zoo of Malaysia inside its Infobox, the rendered map would be:
Code
Rendered Infobox
While if we place that coordinates outside of the Infobox (at the top), then the red colored area indicator would appear in the map, correctly. Like this:
@Jonesey95 With the parameter |mapframe-wikidata = yes the Infobox area indicators appears, but we are talking about default scenario. If the bottom code by default does show the area indicators, then the top code by default should show them too, or the inverse default scenario should be applied.
I think in 99% of cases these red line area indicators are necessary, so the default value of mapframe-wikidata should be |mapframe-wikidata = yes, but the user could change this parameter to no for 1% of cases. Hooman Mallahzadeh (talk) 03:31, 9 September 2023 (UTC)[reply]
Looks like this is a bug with the way the links show in MediaViewer; they seem to work just fine if you click on it in the standard view. — xaosfluxTalk18:56, 9 September 2023 (UTC)[reply]
not only aren't they indented right a couple of characters, or even flush with text above it, they are
actually shifted to the left, as if there were a bit of negative left padding. This seems very odd.
What could be going on here? Is there a ticket for this already, or should I write one?
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Mathglot (talk) 08:29, 10 September 2023 (UTC)[reply]
That's just how the CSS works out. The margin is on the <ul>, but that extends under the image as the floated image only pushes the text right. There's a template {{flowlist}} that can wrap the list to avoid this display issue. That's also why MOS:IMAGELOC suggests avoiding left-floated images when bulleted lists are nearby. Anomie⚔11:53, 10 September 2023 (UTC)[reply]
This is a known issue, and has been so for as long as I've been around (14+ years). That said, it's improved a little during that time - when I first started, the bullets actually overlapped the image. --Redrose64 🌹 (talk) 18:54, 10 September 2023 (UTC)[reply]
Thanks, all. Just to be clear, when we say that this is "just how the CSS works out", I assume we mean that "this is just how the Mediawiki CSS works out". Given the CSS box model, I'm assuming that if I tried this in a pure Html file external to Wikipedia using an html unordered list and rendered it in a browser, the indentation would be correct. In other words, this is a Mediawiki bug, not a bug in CSS. I'm not pushing for it to be resolved if it's been outstanding this long, I just want to be clear where the locus of the problem is, in case this comes up again. Mathglot (talk) 19:49, 10 September 2023 (UTC)[reply]
you will find that the first few list items (six in my browser) have their bullets overlapping the image, with the left of the letter "L" immediately to the right of the right-hand edge of the image; and the last few list items (four in my browser) are below the image, arranged normally. So you need extra CSS to move those first few bullets to the right. --Redrose64 🌹 (talk) 21:30, 10 September 2023 (UTC)[reply]
Also six in my browser. Well, I'm stunned. So the problem is with CSS itself, then, as I can't see any way that this is compliant with the box model, unless there's some very fine print somewhere. Wow. So the solution here is to use {{flowlist}}; thanks for that great tip, and all the supporting work to demonstrate this. I'm still getting over my shock. I wonder what else is lurking out there in CSS-land that I don't know about. (Don't tell me; I don't think I really want to know!) Mathglot (talk) 22:39, 10 September 2023 (UTC)[reply]
Floated elements are removed from the layout flow and so the bounding boxes of other elements don't take them into account. However floated elements do push aside the inline content of the other elements. Floats have always been tricky to use as a result—you often have to allocate space for them within other elements—and thus other layout methods like grid or flexbox were invented and are usually preferred nowadays. isaacl (talk) 00:31, 11 September 2023 (UTC)[reply]
@Isaacl:, thanks for this. My skills are mostly a robust 4.1, with some of the bright and shiny 5.0 stuff, but I'm not up on things like grid or flexbox, so at least I know where to look to update my increasingly rusty skills. Much appreciated. Mathglot (talk) 01:04, 11 September 2023 (UTC)[reply]
I think the "fine print" you're missing is that the list item bullets ("markers" in CSS terms) are not a part of the box model. They are drawn outside of the boxes of the list items, regardless of what else appears there. And by the way, there's a workaround in CSS that changes that – list-style-position: inside[3] causes the markers to be placed inside the list item's box, and behave more intuitively. The drawback is that you can't adjust where exactly the marker appears using margin and padding any more. Matma Rextalk14:50, 11 September 2023 (UTC)[reply]
On a fine technical point, note the bullet will get pushed over by the floated element in that case because it is inline content (though of course that necessarily means it's put within the box content). isaacl (talk) 17:01, 11 September 2023 (UTC)[reply]
On another fine technical point, the only actual CSS in my example is the declaration float:left inside the single style= attribute of the img element. The list is pure HTML, using no CSS at all. I know of no non-CSS method for flosting an object such as an image. --Redrose64 🌹 (talk) 19:35, 11 September 2023 (UTC)[reply]
The align= attribute isn't deprecated, it's obsolete, which is why I didn't mention it. It's still supported by all major browsers though, but this is not guaranteed. --Redrose64 🌹 (talk) 17:01, 12 September 2023 (UTC)[reply]
The WMF may be planning a performance budget for default gadgets
Some say I shouldn't worry and there's no need to inform the community at this point. But my belief is that the community can provide valuable suggestions, alternatives and ideas.
“
Currently anyone with the correct rights can edit MediaWiki:Gadgets-definition to turn gadgets on for anonymous users. Left unchecked this has led to some performance problems and potential SEO (related to slow loading) on many of our smaller sites leading to phab:T340705. We should be doing more to guide site admins on when they are introducing performance/SEO problems to the site. In MediaWiki we've been investing a lot of effort in limiting the amount of CSS and JS we ship to our end users, but any improvements here are meaningless if the same is not happening within gadgets. I think we should enforce a performance budget for all gadgets that have been marked as "default".
The ticket does point out that enwiki has less than a 1% increase when community gadget/site scripts are shipped. I hope that nothing we run here is covered, but perhaps we can ensure that message gets through and we at least get notification of any breakage which may be imposed on us. Fortunately, our HTML has very little of the advertising which would hit response times. Although I don't share the poster's concern with SEO, if we must regard other sources of information as rivals rather than partners then the lack of ads should also help us to rank ahead of them. Certes (talk) 22:53, 10 September 2023 (UTC)[reply]
It's partially published on toolforge (see User:GreenC bot/Job 15), but parts aren't world-readable so I can't test. (Also, the last time I used awk for more than a few minutes at a time was before unicode existed.)I suspect the problem is the -b flag in fambot.awk; it looks to be what's preventing the "β-Hydroxy β-methylbutyric acid" in WP:Featured articles from being properly upcased to "Β-Hydroxy β-methylbutyric acid" as fetched from the category:
Hmmm that's weird as I had it working with a static override in the bot code for this particular name. Something in the past few days changed somewhere, it wasn't my code. The -b is interesting, I could try removing it, it might break other things. This has used up a lot of time. I keep trying. -- GreenC16:09, 11 September 2023 (UTC)[reply]
User:SandyGeorgia: This is the problem. Recall we added this workaround so the bot sees it as B and not β since the Category page returns it as B we want WP:Featured article to also return it as B. I'm hesitant to try Cryptic's suggestion of removing the -b switch because it might break other things, but, I can try that if you prefer, the worse that will happen is the report has false positives and we add the -b back. -- GreenC18:34, 11 September 2023 (UTC)[reply]
I think it was unintentional… <noinclude> tags were first added with a bot notice: [4]. Then another user, probably accidentally, moved a hatnote inside these tags: [5]. The bot notice was later removed: [6] but the tags were not. (They could also be used legitimately for article excerpts, but that doesn't seem to be the case here.) Matma Rextalk15:05, 11 September 2023 (UTC)[reply]
That article has been contentious, so I'm a bit reluctant to fix this myself without ample feedback. Does anyone else see any reason for the noincludes? SandyGeorgia (Talk) 16:52, 11 September 2023 (UTC)[reply]
Many talk pages appear to transclude their corresponding article. Some templates in the talk banners, such as {{Talk header}}, will be referencing the page in a way that causes a transclusion to be recorded. For example it might run getContent() on it in a Lua module to determine what sort of page it is (article, redirect, dab...). Certes (talk) 18:09, 11 September 2023 (UTC)[reply]
When an article transcludes itself, 99+% of the time it uses {{cite xxx}} templates (Trappist the monk has explained why in the past). The other tiny fraction are genuine errors, this probably isn't such a case. As for talk pages transcluding their articles - {{talk header}} and {{WikiProject banner shell}} both do this, as do all WikiProject banners. --Redrose64 🌹 (talk) 13:30, 12 September 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
ORES, the revision evaluation service, is now using a new open-source infrastructure on all wikis except for English Wikipedia and Wikidata. These two will follow this week. If you notice any unusual results from the Recent Changes filters that are related to ORES (for example, "Contribution quality predictions" and "User intent predictions"), please report them. [7]
When you are logged in on one Wikimedia wiki and visit a different Wikimedia wiki, the system tries to log you in there automatically. This has been unreliable for a long time. You can now visit the login page to make the system try extra hard. If you feel that made logging in better or worse than it used to be, your feedback is appreciated. [8]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 September. It will be on non-Wikipedia wikis and some Wikipedias from 13 September. It will be on all wikis from 14 September (calendar).
As part of the changes for the Better diff handling of paragraph splits wishlist proposal, the inline switch widget in diff pages is being rolled out this week to all wikis. The inline switch will allow viewers to toggle between a unified inline or two-column diff wikitext format. [9]
Future changes
All wikis will be read-only for a few minutes on 20 September. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [10]
The Enterprise API is launching a new feature called "breaking news". Currently in BETA, this attempts to identify likely "newsworthy" topics as they are currently being written about in any Wikipedia. Your help is requested to improve the accuracy of its detection model, especially on smaller language editions, by recommending templates or identifiable editing patterns. See more information at the documentation page on MediaWiki or the FAQ on Meta.
Updates on Vector 2022, Zebra, dark mode, and more
Hi everyone,
First of all, many thanks for your involvement in discussions about the desktop interface and the Vector 2022 skin. Below, we give you an update on Vector 2022 and Zebra, as well as our next project, which includes introducing dark mode, and customizations on mobile and desktop for both logged-in and logged-out. Let's do this!
Last few months: Zebra, preference persistence, annual plan, and more
During our conversations about Vector 2022, we mentioned that we see the skin as an improvement in itself, but also, as a foundation on top of which we can continue to make improvements. We also discussed ideas for changing our default interfaces on desktop and mobile browsers.
Over the last couple of months, we have continued working on skins through bug-fixing, performing an A/B test on Zebra (read the new update with results from the test!), and studying our previous user testing on font size. We have also taken a close look at the latest Community Wishlist Survey's top #1 proposal, dark mode, as well as other accessibility-related requests from communities. Those of you who have read the annual plan or took part in the consultations of its draft, might have also noticed this related objective (WE2.1). If you watch our team even more closely, you may have read our May update where we captured some of the initiatives mentioned above.
In addition to that, we have worked on building out the capability for logged-out users to customize certain portions of the interface. First of these were introduced as a result of the conversations we had together around customizing the width of content in Vector 2022. We are glad your community encouraged us to build a way for readers to set these options and look forward to using it for changes that improve accessibility!
Next project: Improved typography and dark mode
Now, we are ready to work on a next project. Our focus will be on making the site more accessible while reading and easier to customize. We will work on:
Providing more options for font size and typography (currently, these are only available on mobile) and improving our default typography
Building out a dark mode
Both of these will be available on desktop and mobile, and customizable for all logged-out and logged-in users.
We have published our initial thoughts on this project page, as well as some of our initial research and review of existing literature for the project. We welcome you to read over our thinking and share your opinions below. We are currently defining what success means for this project. Sketching out summaries of the research we’ve done so far that made us realize that accessibility should be a priority for this work.
We are also building a tool that will allow editors to experiment with different options around font size and typography. The goal here would be to identify what needs different communities have for various customizations and make it easier to discuss ideas for the changes together. We hope to have this tool ready to share with you all within the next couple of weeks.
Thanks for the update. It looks like Wikipedia:Vector 2022 could use some updates. It doesn't show that anything has happened since January 2023.
Also, is the team still processing bug reports? Things like T325219, an easy fix that would eliminate some "oops" whitespace at the top of every single page, sitting idle since February do not inspire a lot of confidence. Other feature requests sit idle, like T333590, asking for notification icons to be in the sticky header, and T329673, asking for the sticky header to appear in all pages and page views (e.g. diffs and history). I've had to work around these basic problems since December using personal CSS. Editors should not be expected to have to do this with the default skin. – Jonesey95 (talk) 03:12, 12 September 2023 (UTC)[reply]
I don't process Wikimedia bug reports, yet for T333590, all I see is a personal assertion of editor behavior that is not backed up with data. As a neutral observer, this bug is no more important than any other random feature request. If there is evidence that most editors expect certain behavior, I suggest including the data for that so it can be properly evaluated. Without that, it sounds like a personal wish list item. Orange Suede Sofa (talk) 07:38, 12 September 2023 (UTC)[reply]
Ugh, I "fixed" {{Airntd}} before seeing PrimeHunter's response. Ymblanter, should these other categories be moved to match the outcome of the discussion that led to moving the "attack aircraft" category, or should I undo my template changes? Note: I will be away from Wikipedia for about 12 hours soon. Any template editor is welcome to revert my changes to that template if that is the right thing to do. – Jonesey95 (talk) 14:04, 12 September 2023 (UTC)[reply]
Or at least I do not think we currently have consensus for moving all these categories. I am just trying to implement a particular CfD conclusion though, this is not really an area I understand well. Ymblanter (talk) 14:12, 12 September 2023 (UTC)[reply]
PageNotice extension - now available for testing
It has been proposed numerous times on this wiki to install the PageNotice MediaWiki extension to allow a uniform header to be automatically displayed at the top of every page in the Draft namespace. See Wikipedia:Village_pump_(idea_lab)/Archive_39#Universal_notice_for_draftspace for what I understand to be the most recent discussion, but it was suggested as far back as 2014.
I'm pleased to report that the extension is now available for testing. The wiki used for testing PageNotice is Beta English Wiktionary (not Wikipedia).
I'm happy to grant established English Wikipedia users temporary admin rights on your Beta English Wiktionary account if you would like to test this new feature. There is no Draft namespace on Wiktionary, but you can test with any other namespace if you wish. Instructions for using the extension are at mw:Extension:PageNotice.
If there is a desire to enable the extension on this wiki (the non-beta English Wikipedia), community consensus would need to be demonstrated.
I was browsing random pages for cleanup purposes, and I noticed that the XTools info was not showing up whatsoever. I tried turning it off and back on, no luck. I reset the browser, and still no luck. I am on Chrome v116.0.5845.179, and it has been working for the past several days, before stopping working about 30 minutes ago. Is anyone else having this issue? EDIT: it seems to be back to normal, but it sounds like some server issues are going on DrowssapSMM (talk)13:34, 12 September 2023 (UTC)[reply]
Yeah, I'm also seeing this on my side. I'm also using Chrome, and trying to access the page gives a DNS_PROBE_FINISHED_NXDOMAIN error. Maybe WMF is having some server issues? Liu1126 (talk) 15:53, 12 September 2023 (UTC)[reply]
They must be. I saw several '503 Service Unavailable' errors when trying to get from the watchlist to this page, and had a similar problem several hours ago. There's no replag, and it's been long enough since the last time this happened I don't remember what else to look up. BlackcurrantTea (talk) 16:16, 12 September 2023 (UTC)[reply]
geohack.toolforge.org not working
Hi all, I don't know if it's something that you already know, but it looks like that geohack.toolforge.org doesn't work (impossible to contact server). -- bs (talk) 14:06, 12 September 2023 (UTC)[reply]
Not sure if related, the entire English Wikipedia was down earlier (est. 16:05 UTC) like for 3 mins throwing 504 errors for me. Currently, English Wikipedia and the toolforge's tools are up and working for me. —Paper9oll(🔔 • 📝)16:37, 12 September 2023 (UTC)[reply]
Trying to check out vandalism using recent change filters and nothing has appeared since 11:34 AM EST (now 1:14 PM EST as of posting). Just wondering if it needs a restart. Kline | yes?17:15, 12 September 2023 (UTC)[reply]
In general
It seems there was some sort of NFS issue this morning (I don't see an email about it, but there was mention on IRC and in wikitech:Nova Resource:Tools/SAL), and while it was resolved with a restart several hours ago it seems it made a lot of tools hang. Their maintainers will likely need to restart them. Anomie⚔17:52, 12 September 2023 (UTC)[reply]
Recently I have been seeing very small text size on some articles but not others, and on this very page, when using an iPad. I haven't figured out what it is about the page that changes the size. (Might affect tablet and not phone, would have to confirm on the latter.) When I say tiny, I mean so small that that Minerva is as hard to read as Vector and Vector 2022. Anyone know what changed? ⁓ Pelagic ( messages ) 18:16, 12 September 2023 (UTC)[reply]
Resolved
icon)
Comment: Added title cus i forgor 💀 QuickQuokka [talk • contribs] 17:54, 9 September 2023 (UTC)
Note: I added the Phabricator ticket. I have no idea which tags to add. QuickQuokka [talk • contribs] 18:09, 9 September 2023 (UTC)
Courtesy ping: LittlePuppers QuickQuokka [talk • contribs] 18:37, 9 September 2023 (UTC)
Mathglot (talk) 22:39, 10 September 2023 (UTC)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 September. It will be on non-Wikipedia wikis and some Wikipedias from 13 September. It will be on all wikis from 14 September (calendar).
The Technical Decision-Making Forum Retrospective team invites anyone involved in the technical field of Wikimedia projects to signup to and join one of their listening sessions on 13 September. Another date will be scheduled later. The goal is to improve the technical decision-making processes.
As part of the changes for the Better diff handling of paragraph splits wishlist proposal, the inline switch widget in diff pages is being rolled out this week to all wikis. The inline switch will allow viewers to toggle between a unified inline or two-column diff wikitext format. [9]
199.208.172.35 (talk) 15:35, 12 September 2023 (UTC)
