Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

IP Information tool

Tracked in Phabricator
Task T363118

Facing a new issue today regarding the IP Information Tool where access to some of the non-admin information does not show up in the Special:Contributions page for an IP as it did before. That page now only shows "Version", "Active blocks", and "Contributions". Oddly, the country (not city) location still pops up on the watchlist preview, even though it does not show on the Contributions page. Anyone else seeing similar? Best, CMD (talk) 08:00, 15 May 2024 (UTC)

The IP information drop down has been returning no information for me other than the version (IPv4 vs. IPv6), local block info and contribs for the last two days. It's like it can't access any of the data from whichever database it draws from. Every other field simply states "not available".-- Ponyo^{bons mots} 21:43, 15 May 2024 (UTC)

And regarding my odd note on watchlist preview, this only happens sometimes, with even different edits from the same IP showing me country location in one instance but not another. CMD (talk) 01:50, 16 May 2024 (UTC)

Further learning, I can refresh the same IP contributions page repeatedly and sometimes it will show me the country, sometimes it will show no access. CMD (talk) 03:25, 16 May 2024 (UTC)

Can someone link a page where this has recently happened to them, so that I can try to reproduce? –Novem Linguae (talk) 07:15, 16 May 2024 (UTC)

@Novem Linguae: it happens on any IP contributions page (this one, for example).-- Ponyo^{bons mots} 15:29, 16 May 2024 (UTC)

Thanks, I'm able to reproduce. According to https://phabricator.wikimedia.org/T363118#9804312, "not available" is case #2. This means Spur/Maxmind doesn't have that data. Looking at these fields, they're all populated by Spur. Maxmind and Spur have different coverage, so we may have a location for an IP but no other data for it.. So that one is not a bug and they have no plans to patch it, it looks like. –Novem Linguae (talk) 15:56, 16 May 2024 (UTC)

I don't understand how that data was available consistently for all IPs, then suddenly is missing for nearly all of them. It renders the entire IP contribs drop down useless. Oh well.-- Ponyo^{bons mots} 16:13, 16 May 2024 (UTC)

Someone just commented in the ticket that they think it's happening way more than it used to and they think something is broken. So it may be a bug after all. Here's hoping the devs figure it out. –Novem Linguae (talk) 16:47, 16 May 2024 (UTC)

If I refresh sometimes, sometimes, the location info magically just appears. So the data is there. Sometimes. This is all on the same IP page. The one listed just above if I refresh does show the location 1 time out of 4 or so. Canterbury Tail talk 15:58, 21 May 2024 (UTC)

This has now been split into two separate Phab issues, Phab:T355392 and Phab:T355393. CMD (talk) 01:42, 24 May 2024 (UTC)

Dark mode is available in Vector 2022 as a beta feature

Hi everyone, the Wikimedia Foundation Web team has just released dark mode for logged-in users on desktop across all wikis for testing purposes. It's part of the Accessibility for Reading (Vector 2022) beta feature.

Just like previously, when we were releasing this feature for logged-in users on mobile, our goals for the early rollout are to:

• Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
• Get your help with flagging bugs, issues, and requests
• Work with technical editors to adjust various templates and gadgets to the dark mode

Known limitations

• Dark mode is only available for logged-in users: on desktop as a beta feature, and on mobile in the advanced mode.
• Gadgets may initially not work well with dark mode and may have to be updated.
• Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces (including Wikipedia) have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.

What we would like you to do

Our request to you is exactly the same as previously:

1. To opt into dark mode, select the Accessibility for Reading beta feature from the beta feature list. This will opt you into the Appearance menu displayed in the right sidebar on every page. More about the menu itself here.
2. Next, go to different articles and look for issues:
   • If you have noticed an issue with a template but do not know how to fix it
     1. Go to the recommendations page and find a relevant example
     2. If no relevant example is available or you're not sure of the fix, contact us
   • If you want to debug many templates in dark mode
     1. Go to https://night-mode-checker.wmcloud.org/ and identify templates that need to be fixed. The tool flags the top 100 most read articles.
     2. Go to the recommendations page and find a relevant example
     3. If no relevant example is available or you're not sure of the fix, contact us
   • If you want to identify problems beyond the top 100 articles.
     1. Install the WCAG color contrast browser extension (Chrome, Firefox) and visit some articles. Use it to identify problems
     2. Go to the recommendations page and find relevant examples
     3. If no relevant example is available or you're not sure of the fix, contact us
   • If you have a bug report for dark mode that is not related to templates
     1. Take a screenshot of what you are observing.
     2. Contact us. If possible, please write down your browser version and operating system version.

When most issues are solved, we'll be able to make the dark mode available for readers on both desktop and mobile. Go to the Accessibility for Reading project page and the FAQ page to see more information about the basics of this project. Thank you! SGrabarczuk (WMF) (talk) 21:47, 15 May 2024 (UTC)

I don't know if this was the right move. Tons of pages still look like garbage (shoutout Special:Watchlist)—the theme is definitely not ready for use by non-technical editors. It wouldn't be too bad if you had made a seperate beta option for it—because you've clumped it in with Accessibility for Reading a couple people have gone on the Discord confused. Snowmanonahoe (talk · contribs · typos) 23:54, 15 May 2024 (UTC)

"Fixing" it is as simple as setting your personal chosen theme to light mode.

As for tons of pages, I just got separate word that OOUI interfaces don't support light mode (currently/ever?), which is why Watchlist has light elements. Perhaps it shouldn't be displaying as dark. Izno (talk) 00:08, 16 May 2024 (UTC)

Articles too. Along with interface pages, editnotices, syntax highlighting, half the mboxes... Snowmanonahoe (talk · contribs · typos) 00:27, 16 May 2024 (UTC)

The point is for editors to find these things. Might as well drop logged users in and let them make the two button presses to find a different, less-painful choice. Izno (talk) 00:41, 16 May 2024 (UTC)

Exactly, there is no magic fairy dust for some of this, just grunt work to fix the pages and templates that never had to account for a darkmode. —TheDJ (talk • contribs) 14:56, 16 May 2024 (UTC)

We do have a long-term solution for OOUI fixes that is in development right now. We hope to have it ready within the next couple of weeks. In the meantime however, pages like Watchlist and should be displaying in light mode so this is a bug. We're tracking it in phab:T365084 and should have a fix out later today. OVasileva (WMF) (talk) 07:36, 16 May 2024 (UTC)

@SGrabarczuk (WMF): Is there really a plan to take over the right 1/4 of screen with a "settings" panel every time someone opens a page in a new private tab, or clears cookies, or switches to a new language, or doesn't realize what the "hide" button does? Or is that just so in-your-face during the testing phase? Suffusion of Yellow (talk) 02:01, 16 May 2024 (UTC)

Hey @Suffusion of Yellow - thanks for the question. In general, we think this is the most effective way to launch the new menu and be able to inform users about it. It removes the necessity to add additional modals or notices that say "New menu available!" or "Dark mode available", which would otherwise show on every pageview. So, the current plan is to keep the menu open by default for the wider release as well for all logged-in and logged-out users. Then, after the release, we can look at the data to gauge whether we need to keep it open as default, or collapse, and when. OVasileva (WMF) (talk) 07:40, 16 May 2024 (UTC)

Why can't it be on the left side, with the TOC? Or better yet, just put a plain-text link at the top? I mean, registered users have already been able to find the "preferences" link for 20 years now. Right when I open up testwiki:LOREM IPSUM (or any page with a TOC) on my phone in a new private tab, then switch to the desktop site, about half my screen is whitespace, and the text is squished into a narrow little strip in the middle. It's unusable until I hide the settings column

People are reading a website, not installing software. There shouldn't be a "setup" stage before they can get down to the business of looking up that one little fact. The defaults should at least be usable. Suffusion of Yellow (talk) 17:11, 16 May 2024 (UTC)

Hi @Suffusion of Yellow - we generally have most personalized tools (page tools, the user menu, preferences) on the right side of the page, which is why we chose this location. It would have been confusing to show a menu on the left side of the page, next to the content-related ToC, only to then collapse it into the right side. Hope that makes sense.

In terms of the defaults - I couldn't agree with you more. We want our defaults to be as usable as possible (and also to provide an easy opportunity for customization). We are currently in the process of defining and setting defaults for all three areas in the menu. These default will become available as the features themselves are ready. For example, the default for dark mode will be "automatic", which will follow the user's device settings. OVasileva (WMF) (talk) 06:46, 21 May 2024 (UTC)

@SGrabarczuk (WMF): https://night-mode-checker.wmcloud.org/ appears to only be for the mobile version. Is there is desktop report? Also, the beta is only for Vector 2022. Many editors still use legacy vector or other skins, will the new feature be moved to any other skin besides Vector 2022? How does the new feature compare to the dark mode gadget that is currently available? RudolfRed (talk) 03:31, 16 May 2024 (UTC)

This dark mode is only going to be supported on Vector 22 and Minerva so far as I know. Izno (talk) 03:54, 16 May 2024 (UTC)

The main idea of the new feature is that it doesn't invert colors that are not known to be invertable. This causes the colors on Pantone for example to not be distorted. Snowmanonahoe (talk · contribs · typos) 11:43, 16 May 2024 (UTC)

Users are supposed to mark those themselves, see mw:Recommendations for night mode compatibility on Wikimedia wikis#Overriding night mode styles / disabling the night mode theme. Snævar (talk) 09:29, 18 May 2024 (UTC)

Configuring Git for Gerrit

I have a sort of "hello, world" MediaWiki coding change I'd like to submit as my first-ever contribution to MediaWiki, and to get myself started and oriented with the system for submitting coding changes. If all goes well with that, I hope to follow that up with a more substantial change sometime, hopefully soon, after that. I already have a Wikimedia developer account, with accounts on MediaWiki and Wikitech. My usernames there, including my SSH access (shell) username, are the same as my English Wikipedia username. Now mw:Gerrit/Tutorial#Configure Git is telling me I need to have my "own Gerrit username". Is this a name which is unique to Gerrit, and not used anywhere else, such as the Toolforge? Also, I see on the Gerrit settings page a "Username" (is that the same as Git's "own Gerrit username"?), "Full name", and "Display name" – how are each of these used? Which of these names are used for the CREDITS page, the list that's updated by updateCredits.php? wbm1058 (talk) 20:35, 17 May 2024 (UTC)

Your Gerrit username is more properly your developer account username, which is the same as on Toolforge and other places. For those three fields, username is what you log in as, I don't think Full name is used anywhere, and display name is how your name appears on the Gerrit UI. updateCredits.php seems to parse "git log", so the name used is whatever shows up in Git, which usually is the same as one of the above but not necessarily. * Pppery * _{it has begun...} 20:52, 17 May 2024 (UTC)

Full name is actually what's used for sign-ins via web UIs (Wikitech, Toolsadmin). "Username" is only used for SSH access (toolforge / git review). The CREDITS page uses the name from git log, which you'd set through the git config --global user.name command. – SD0001 (talk) 21:22, 17 May 2024 (UTC)

Oh, oops, aparently I'm just as confused. * Pppery * _{it has begun...} 21:24, 17 May 2024 (UTC)

Thanks. Further complicating naming matters, I see there is an "LDAP" (Lightweight Directory Access Protocol) username. See wikitech:SRE/LDAP. Per wikitech:SRE/LDAP/Renaming users, "We do not rename users (Developer accounts) anymore. It can (and has) lead to various problems and errors all over the many separate systems which consume Developer accounts as their local databases and authentication methods will get out of sync." So I guess I'm stuck for now with the name I have (not that I want to change it). But a reason for proceeding cautiously here. I don't want to stumble into doing something irreversible that I wish I'd done differently later, after I figured out what I was actually doing, rather than signing up for it by trial and error. I don't recall seeing the mw:Developer account page before, and I think I created mine before the Create a Wikimedia developer account form was created. Today I just ran into the Bitu Identity Manager, which shows me "My LDAP properties". (see wikitech:IDM). Phabricator says my LDAP User is "Unknown". I don't know if there's a way I can personally make it known, or whether it being unknown is a problem. – wbm1058 (talk) 22:14, 17 May 2024 (UTC)

I think theres basically 2 logins. #1 is the oauth / centralauth / all wikis but wikitech one. #2 is ldap / gerrit / toolforge / wikitech. Lots of synonyms here. I forget if phabricator is one of those two, or a third one. –Novem Linguae (talk) 22:26, 17 May 2024 (UTC)

I suppose Phabricator is probably bilingual. Obviously I sign into it using my #1 because my #2 is unknown to the phabulous Phabricator. On the other hand, there must be some developers using it who may not have a #1. – wbm1058 (talk) 22:43, 17 May 2024 (UTC)

Yes, phab supports sign-in via either of the two. You can still link phab with the other account through Settings > External accounts. – SD0001 (talk) 06:21, 18 May 2024 (UTC)

Facepalm I looked at that screen twice and all I saw was date & time settings! Thanks! Now my account is linked with all (two) available providers. – wbm1058 (talk) 10:45, 18 May 2024 (UTC)

Shout-out to @BMueller (WMF):. I watched your online presentation given at last month's conference in Portland and thought you might be interested in reading this thread. Enjoyed meeting you in Toronto last year. – wbm1058 (talk) 23:21, 17 May 2024 (UTC)

Now I just found and opened the Gerrit Code Review - User Privacy page... so Google, as well as Wikimedia, is part of the loop! layers upon layers – wbm1058 (talk) 11:29, 18 May 2024 (UTC)

Hmm, Gerrit is a Dutch male name meaning "brave with the spear", the Dutch and Frisian form of Gerard. And Gerrit (software) was authored by Google. Whereas Git was written by the guy behind Linux. Learn something new every day. wbm1058 (talk) 11:48, 18 May 2024 (UTC)

When asked why he called the new software, 'git', British slang meaning 'a rotten person', Torvalds said 'I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.' Ha! wbm1058 (talk) 12:00, 18 May 2024 (UTC)

Google is not part of the loop exactly. Google wrote the software, but it's open-source and the website https://gerrit.wikimedia.org is hosted by Wikimedia with no involvement from Google. * Pppery * _{it has begun...} 13:23, 18 May 2024 (UTC)

More from the "I figured out what was happening only after it already happened" department. Wikimedia Code Review https://gerrit.wikimedia.org/r/settings says I registered @ Monday, May 13, 2024, 9:08:55 PM UTC-04:00 ... what? I don't recall doing anything specific to "register" there last Monday. What was I doing at that time? I thought per mw:Gerrit/Tutorial I had to configure Git in order to register for Gerrit, but here I am already registered for Gerrit, and I haven't configured Git yet! O I C. I think I was looking at a previous code review related to the task I'd decided to work on, when I noticed "Sign up" and "Sign in" links on the upper right corner of that page. Clicking "Sign up" took me to this new IDM "Create account" page to create a Wikimedia developer account. Hey, I thought, I think I already have one of those that I needed for Wikitech/Toolforge. So I left that page, and clicked "Sign in". Voila, my Wikitech password got me in. I thought I had simply logged into Gerrit, not registered for it. What I didn't realize was that the "Bitu Identity Manager" would not only sign me in, but register me as well! wbm1058 (talk) 16:12, 18 May 2024 (UTC)

SSH keys

I already have SSH keys set up for Toolforge at Toolsadmin which I use on PuTTY and WinSCP but not directly from the Windows command prompt.

mw:SSH keys seems to indicate that I can't use my Toolsadmin SSH but will need another one, set up from the Windows command prompt. Correct?

Also, regarding configuring Git personal information. The guide says "You should have to do this only once." Is that literally true, or does it mean once on my desktop and once on my laptop, if I have two machines that I might want to submit code from? wbm1058 (talk) 18:06, 18 May 2024 (UTC)

@Wbm1058 You can reuse the same SSH key across multiple projects (in this case toolsadmin and Gerrit). The tutorial assumes that you have not setup the keys before.

Regarding the configuration of Git, you will need to do it once per machine. Sohom (talk) 23:08, 18 May 2024 (UTC)

My desktop is still running Windows 7. I know, I know, long in the tooth, but I'm proud to have kept it going for 14 years and would like to make it to 15. It still works for me, for the most part. I've downloaded the production version MediaWiki 1.41.1 and have it running for debugging. I generated my SSH keys with PuTTYgen, since the Windows 7 command prompt does not support the ssh command. I suppose I'd need to use PuTTY on that machine to connect to Gerrit, as I use it to connect to the Toolforge bastion. I think I can figure that out; haven't found documentation on how to use Gerrit on a Windows 7 machine. I haven't set up SSH on my Windows 10 laptop yet (only do Toolforge from my desktop). I don't know how to copy my keys from PuTTY to the required location on Windows 10. Might be easier to generate new keys on Windows 10. I have an ssh-rsa key for Toolforge access; the documentation says to use the ed25519 type for optimum security and performance. Can I use different SSH keys on each machine? wbm1058 (talk) 16:53, 19 May 2024 (UTC)

As a matter of fact, you are kind of expected to use different keys per user per machine. That’s why all the ssh settings of toolforge and Gerrit allow you to add multiple public keys. —TheDJ (talk • contribs) 16:58, 19 May 2024 (UTC)

What TheDJ said, you are expected different SSH keys across machines. However, if you are using one machine, you can reuse the key across multiple things (I have mine on Github/Gitlab/Toolforge and Gerrit as well as a bunch of private services). Sohom (talk) 18:15, 19 May 2024 (UTC)

OK, thanks! New state-of-the-art ed25519 keys generated and installed for my Windows 10 laptop (which MSFT tells me will be unsupported after next year, and my hardware is too old to run Windows 11(.

I successfully did a git clone. I'm a bit confused by the instructions at mw:Download from Git#Download for development:

"This clones the entire MediaWiki core repository, synced to the master branch, into a sub-directory named mediawiki"

I previously installed MediaWiki 1.40.1 on my laptop last November at the Toronto wikiconference, by downloading the then-current version from mw:Download, and successfully installed that, for testing.

I want to overwrite my previous 1.40.1 installation with the new files I just git got.

The standard mediawiki directory holds core and data sub-directories.

It doesn't appear that the git download includes any data. It appears to be a core directory, which includes some extra files that aren't part of the mw:Download version. Why don't the instructions say to download to a sub-directory named core rather than a sub-directory named mediawiki?

Oh, I see. mw:Manual:Upgrading#Using Git:

If using Git, export the files into a clean location, and then copy the old customized files into the new location as described in the previous section.

You will also need to install some external PHP libraries using Composer or a provided collection maintained for the Wikimedia wiki farm. More details on installing and updating external libraries can be found in the Git download documentation

So, for some reason, although I can test using 1.40.1 without having any PHP problems, I'll need to figure out this "Composer" thing in order to do development testing.

Hopefully it's not a problem that I'm running the PHP 8.2.12 Development Server – wbm1058 (talk) 23:11, 19 May 2024 (UTC)

I think all mediawiki unit tests are passing on php 8.1. Not sure about php 8.2. May want to switch to 8.1 to prevent hard to diagnose bugs. –Novem Linguae (talk) 00:45, 20 May 2024 (UTC)

The tests pass on php 8.2 as well [1], – SD0001 (talk) 12:16, 20 May 2024 (UTC)

Composer

c:\php\mediawiki\core>php maintenance/run.php update.php
Error: You are missing some external dependencies.
MediaWiki has external dependencies that need to be installed via Composer or from a separate repository. Please see
https://www.mediawiki.org/wiki/Manual:Installation_requirements#PHP and
https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries
for help on installing the required components.

• mw:Manual:Installation requirements#PHP does not mention "Composer". It says "MediaWiki only requires PHP extensions that are enabled in PHP by default." I assume that's why I didn't get this error when I ran update.php on my desktop, where I'm just running the official MediaWiki releases. "If your hosting provider provides a basic LAMP environment without these, you may need to install or enable these manually."
• OK, I'm going to follow the instructions at mw:Download from Git#Fetch external libraries.
• Hmm, I guess I should mw:Download from Git#Update the Git submodules first? wbm1058 (talk) 14:22, 20 May 2024 (UTC)

I don't think submodules is what you need. The php maintenance/run.php update.php script just wants you to composer install in the mediawiki directory, that should download the required directories. Sohom (talk) 14:34, 20 May 2024 (UTC)

Indeed only the second link is relevant here. I'm clarifying this message in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1034113. Thanks for writing all of this up, it's helpful to see things from a different perspective sometimes. Matma Rex talk 16:07, 20 May 2024 (UTC)

c:\php\mediawiki>composer update --no-dev
Composer could not find a composer.json file in c:\php\mediawiki To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage

I'm going to reboot my machine and try again. Composer install warned me that I might have a PATH problem. wbm1058 (talk) 15:56, 20 May 2024 (UTC)

Judging by your previous comments, you're just not in the directory that Composer expects – try going to c:\php\mediawiki\core, where you (and Composer) should find the composer.json file. Matma Rex talk 16:09, 20 May 2024 (UTC)

Yes, thanks, that was it. Once again the instructions misled me: "then run composer update --no-dev from your MediaWiki core directory." It's still running. This step takes significant time! wbm1058 (talk) 16:20, 20 May 2024 (UTC)

I think it worked. The console log is long, with a pile of "failed to download" warning messages, but it appears to have successfully worked around all of them. Here's the end of the log, showing just the last 3 of many installations:

  - Installing wikimedia/timestamp (v4.1.1): Cloning 138f3099b4 from cache
  - Installing wikimedia/xmp-reader (0.9.1): Cloning 8338d67969 from cache
  - Installing zordius/lightncandy (v1.2.6): Cloning b451f73e8b from cache
44 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating optimized autoload files
11 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> MediaWiki\Composer\ComposerVendorHtaccessCreator::onEvent
No security vulnerability advisories found.

I think I'm ready to try running update.php again. – wbm1058 (talk) 16:51, 20 May 2024 (UTC)

c:\php\mediawiki\core>php maintenance/run.php update.php
Error: The MinervaNeue skin cannot be loaded. Check that all of its files are installed properly.

1. 0 C:\php\mediawiki\core\includes\GlobalFunctions.php(91): ExtensionRegistry->queue('C:\\php\\mediawik...')
   
2. 1 C:\php\mediawiki\core\LocalSettings.php(166): wfLoadSkin('MinervaNeue')
   
3. 2 C:\php\mediawiki\core\includes\Setup.php(216): require_once('C:\\php\\mediawik...')
   
4. 3 C:\php\mediawiki\core\maintenance\run.php(49): require_once('C:\\php\\mediawik...')
   
5. 4 {main}
   

PHP Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96 Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96

Sigh. I didn't need no extensions when testing changes to the official release core page-moving functions. Now I do. – wbm1058 (talk) 18:04, 20 May 2024 (UTC)

You shouldn't need any extensions to run MediaWiki core. It's only trying to load the MinervaNeue skin, because you have a line in your LocalSettings.php like wfLoadSkin('MinervaNeue'); (maybe you copied it from your previous installation?). You can remove it or comment it out if you don't want it.

If you do want it, then you can install the skin using Git similarly to how you installed MediaWiki, just replacing the path in the git clone command: instead of mediawiki/core, use mediawiki/skins/MinervaNeue (and make sure to put it in the skins directory, where MediaWiki is looking for it). Similarly for all other skins and extensions. Matma Rex talk 18:13, 20 May 2024 (UTC)

Thanks! I just used the default LocalSettings.php that came with the release-version installation. Figuring I only need one skin, I just copied the folder from my backup of the release version, and commented out the others. That did the trick, and the database update looks like it ran successfully. – wbm1058 (talk) 20:28, 20 May 2024 (UTC)

MediaWiki internal error.

Original exception: [6d2f7f0574eb09bb447c9687] /index.php/Main_Page Error: Class "ResourceLoaderSkinModule" not found
Backtrace:
from C:\php\mediawiki\core\includes\ResourceLoader\ResourceLoader.php(417)

Another missing piece. The console log looks good, but this come up on the webpage. – wbm1058 (talk) 21:04, 20 May 2024 (UTC)

Did you git clone, composer install, and npm ci inside your default skin? Probably skins/Vector –Novem Linguae (talk) 21:17, 20 May 2024 (UTC)

The ResourceLoaderSkinModule class was recently renamed (gerrit:994854). It seems that you've just updated your MediaWiki to a version that doesn't have it any more, but one of your skins is an older version that is still using it. This will occasionally happen with skins and extensions.

If you've already installed the skin from Git, running git pull in the affected skin's repository should fix it. If you haven't, it's probably best if you do :) but you can also remove it from LocalSettings.php, or download the latest master snapshot from SkinDistributor/ExtensionDistributor. Matma Rex talk 21:51, 20 May 2024 (UTC)

Thanks for the nice, detailed response. mw:Special:SkinDistributor/Vector even offers the "master (latest development version)" but https://extdist.wmflabs.org/dist/skins/Vector-master-685a02f.tar.gz gives me a 404 Not Found error. I'll just figure out how to git it the preferred way ) wbm1058 (talk) 00:23, 21 May 2024 (UTC)

Weird, that link works for me now. Maybe it took a few minutes to generate. Matma Rex talk 00:35, 21 May 2024 (UTC)

Indeed. Just worked for me too. But rather than tinker with telling my Windows how to unzip that "gz" file ("Look for an app in the Miocrosoft Store"?!), I'm going to mw:Download from Git#Using Git to download MediaWiki skins.

Follow the exact same procedure as for extensions (described in the previous section), but using skins rather than extensions in all URLs and paths. wbm1058 (talk) 01:01, 21 May 2024 (UTC)

c:\php\mediawiki\core\skins>git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Vector
Cloning into 'Vector'...
Enter passphrase for key '/c/Users/Bill/.ssh/id_ed25519':
remote: Counting objects: 99, done
remote: Finding sources: 100% (94/94)
remote: Getting sizes: 100% (70/70)
remote: Compressing objects: 100% (1041262/1041262)
remote: Total 37958 (delta 29), reused 37891 (delta 9)
Receiving objects: 100% (37958/37958), 11.37 MiB | 8.91 MiB/s, done.
Resolving deltas: 100% (28242/28242), done.

c:\php\mediawiki\core\skins>

Appears to have worked. – wbm1058 (talk) 01:17, 21 May 2024 (UTC)

 Done. Success. I have a development environment which seems to be operating identically with the official-release environment I just replaced. Tomorrow I move to the next step. Make minor "hello, world!" type changes in two files, and then figure out how to submit them for review. FYI, the project I'm working on, where I hope to make more substantial enhancements soon, is discussed on my talk: User talk:Wbm1058#My MediaWiki core developers thread. – wbm1058 (talk) 01:40, 21 May 2024 (UTC)

mw:Local development quickstart

It's just that the way you have cloned the repo is unconventional. mediawiki/core should be cloned to a directory named "mediawiki", not "core".

I think you will have a lot easier time going through mw:Local development quickstart instead, which unfortunately isn't advertised more prominently. You may want to discard the existing mediawiki install and use the quick start. You have already done step 1, so start with step 2. It's easy! – SD0001 (talk) 16:40, 20 May 2024 (UTC)

That "quick start" page has stuff I've already done previously, and insufficient info about stuff I needed to do.

I've had an "official release" version installed on my laptop since November. It makes a lot of sense to me to have started that way, because as complicated as installing the official release was, installing the developers' version is way more complicated yet.

• I've had PHP installed directly on Windows for over a decade now. My bots use that.
• There was no need for me to update my php.ini file to load the required PHP extensions. I already did that a long time ago. The problem is that this "composer" system basically "ignores" that, it seems to me.
• It just says to "use Git" to clone the core, as if that's easy. No it wasn't. See above for what steps I went through to figure it out.
• I installed SQLite already last year; I don't need to do that again.
• I already knew how to start my server, though I was told by someone to use "localhost:80" in Boston in 2019, not "localhost:4000". I don't know whether it matters which number I use there.

What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. – wbm1058 (talk) 17:28, 20 May 2024 (UTC)

1 and 2. yes I said as much - you have already done step 1.
3. There's no need to configure git before cloning repos. The steps from mw:Gerrit/Tutorial#Configure_Git are only to prepare for pushing changes.
4. composer mw-install:sqlite is not for installing sqlite (not required). Instead it initialises MediaWiki itself with sqlite as the db backend. This is a shortcut to avoid going through the web installer.
5. Running something on port 80 is only advisable on linux. On Windows/macOS, it's better to use a non-reserved port (> 1023) to avoid issues with firewalls.
What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. The easiest way to do that is to delete or forget about the release version and setup the developers' version from scratch. – SD0001 (talk) 17:56, 20 May 2024 (UTC)

What I did need to do before cloning was download and install Git, and setup SSH to use it. None of that was necessary to download and install the release version, which makes installing the release version an easier task.

Oh I see. a shortcut to avoid going through the web installer... well, now I know. I was wondering how that was done. But now, water under the bridge. I'd like to keep the database I started last year, for sentimental reasons, and just upgrade. I think upgrading should be easier than installing from scratch every time.

I've noted that my server runs really slowly on my system. Wrote that off as bloatware overwhelming my 14-year old processor, but, now that you mention it, could be a symptom of firewall intervention. I'll switch to port 4000 and see whether that runs faster.

I also noticed mw:Gerrit/Tutorial/tl;dr, and have kept that open in another browser window for comparison and reference. – wbm1058 (talk) 20:17, 20 May 2024 (UTC)

git-review

Running command as an administrator:

Microsoft Windows [Version 10.0.19045.4412] (c) Microsoft Corporation. All rights reserved. C:\WINDOWS\system32>pip install git-review Collecting git-review Downloading git_review-2.4.0-py3-none-any.whl.metadata (2.0 kB) Collecting requests>=1.1 (from git-review) Downloading requests-2.32.1-py3-none-any.whl.metadata (4.6 kB) Collecting charset-normalizer<4,>=2 (from requests>=1.1->git-review) Downloading charset_normalizer-3.3.2-cp312-cp312-win_amd64.whl.metadata (34 kB) Collecting idna<4,>=2.5 (from requests>=1.1->git-review) Downloading idna-3.7-py3-none-any.whl.metadata (9.9 kB) Collecting urllib3<3,>=1.21.1 (from requests>=1.1->git-review) Downloading urllib3-2.2.1-py3-none-any.whl.metadata (6.4 kB) Collecting certifi>=2017.4.17 (from requests>=1.1->git-review) Downloading certifi-2024.2.2-py3-none-any.whl.metadata (2.2 kB) Downloading git_review-2.4.0-py3-none-any.whl (52 kB) ---------------------------------------- 52.9/52.9 kB 547.6 kB/s eta 0:00:00 Downloading requests-2.32.1-py3-none-any.whl (63 kB) ---------------------------------------- 63.7/63.7 kB 862.4 kB/s eta 0:00:00 Downloading certifi-2024.2.2-py3-none-any.whl (163 kB) ---------------------------------------- 163.8/163.8 kB 2.0 MB/s eta 0:00:00 Downloading charset_normalizer-3.3.2-cp312-cp312-win_amd64.whl (100 kB) ---------------------------------------- 100.4/100.4 kB 1.2 MB/s eta 0:00:00 Downloading idna-3.7-py3-none-any.whl (66 kB) ---------------------------------------- 66.8/66.8 kB 725.6 kB/s eta 0:00:00 Downloading urllib3-2.2.1-py3-none-any.whl (121 kB) ---------------------------------------- 121.1/121.1 kB 1.8 MB/s eta 0:00:00 Installing collected packages: urllib3, idna, charset-normalizer, certifi, requests, git-review Successfully installed certifi-2024.2.2 charset-normalizer-3.3.2 git-review-2.4.0 idna-3.7 requests-2.32.1 urllib3-2.2.1

Per instructed at mw:Gerrit/Tutorial#Setting up git-review:

c:\php\mediawiki\core>git review -s --verbose
git: 'review' is not a git command. See 'git --help'.

c:\php\mediawiki\core>git-review -s --verbose
'git-review' is not recognized as an internal or external command, operable program or batch file.

?? – wbm1058 (talk) 14:09, 21 May 2024 (UTC)

• To use git review, you have to be in a git clone directory that already contains a (possibly hidden) .gitreview configuration file (see Setting up a repository for git-remote) — hmm wbm1058 (talk) 14:48, 21 May 2024 (UTC)

It looks like the directory where git-review got installed is not in your %PATH% environment variable. First of all, try closing the command-line window and opening it again, and retry – maybe it is just seeing outdated env variables.

If that doesn't help, you'll need to change that env variable, the option to do that is somewhere in your operating system settings. Add the directory where git-review is, probably something like like C:/Python310/Scripts/ (that's where it is on my machine). Note that you need to open a new command-line window every time for the changes to take effect when testing.

(If I recall, there's a checkbox to do that automatically when you install Python, which you may have left unchecked. You can also try reinstalling Python and finding that checkbox.) Matma Rex talk 15:04, 21 May 2024 (UTC)

Yes, I checked the box on the Python installation. Closing my command window and opening a new one did the trick, of course. The instructions could explicitly say to do that. Thanks again for all your help – wbm1058 (talk) 15:20, 21 May 2024 (UTC)

• That directory has a .gitreview file in it, with the following content:
  

host=gerrit.wikimedia.org
port=29418
project=mediawiki/core.git
track=1
defaultrebase=0

Is that good? wbm1058 (talk) 14:58, 21 May 2024 (UTC)

review installation log

c:\php\mediawiki\core>git review -s --verbose
2024-05-21 11:12:37.452765 Running: git config --get gitreview.remote
2024-05-21 11:12:37.468379 ... gitreview.remote = origin
2024-05-21 11:12:37.468379 Config['remote'] = origin
2024-05-21 11:12:37.468379 Running: git config --get gitreview.branchauthor
2024-05-21 11:12:37.499631 Config['branchauthor'] = name
2024-05-21 11:12:37.499631 Running: git symbolic-ref -q HEAD
2024-05-21 11:12:37.530879 Running: git for-each-ref --format=%(upstream) refs/heads/master
Following tracked origin/master rather than default origin/master
2024-05-21 11:12:37.609011 Running: git config --get gitreview.scheme
2024-05-21 11:12:37.671503 Config['scheme'] = ssh
2024-05-21 11:12:37.671503 Running: git config --get gitreview.hostname
2024-05-21 11:12:37.687125 Config['hostname'] = gerrit.wikimedia.org
2024-05-21 11:12:37.687125 Running: git config --get gitreview.port
2024-05-21 11:12:37.718370 Config['port'] = 29418
2024-05-21 11:12:37.718370 Running: git config --get gitreview.project
2024-05-21 11:12:37.749619 Config['project'] = mediawiki/core.git
2024-05-21 11:12:37.749619 Running: git log --color=never --oneline HEAD^1..HEAD
2024-05-21 11:12:38.687096 Running: git remote
2024-05-21 11:12:38.765224 Running: git branch -a --color=never
2024-05-21 11:12:38.890218 Running: git rev-parse --show-toplevel --git-dir
2024-05-21 11:12:38.937083 Running: git config --get core.hooksPath
2024-05-21 11:12:38.983962 Running: git config --get core.hooksPath
2024-05-21 11:12:39.015203 Running: git submodule foreach cp -p .git\hooks\commit-msg "$(git rev-parse --git-dir)/hooks/"

c:\php\mediawiki\core>

I don't see the "found origin push URL" and "fetching commit hook" that the instructions said I should see. – wbm1058 (talk) 15:47, 21 May 2024 (UTC)

The instructions are probably outdated and everything is probably okay. git-review is being somewhat actively developed, and the example output in mw:Gerrit/Tutorial#Setting_up_git-review has a 2019 date. If it didn't work, you'll find out later if you get an error complaining about a missing Change-Id line. Matma Rex talk 20:57, 21 May 2024 (UTC)

I don't know whether that's a problem or not, but I proceeded as if it wasn't.

c:\php\mediawiki\core>git pull --rebase origin master
Enter passphrase for key '/c/Users/Bill/.ssh/id_ed25519':
remote: Counting objects: 11860, done
remote: Finding sources: 100% (60/60)
remote: Getting sizes: 100% (26/26)
remote: Compressing objects: 100% (108354/108354)
remote: Total 60 (delta 35), reused 35 (delta 28)
Unpacking objects: 100% (60/60), 36.46 KiB | 13.00 KiB/s, done.
From ssh://gerrit.wikimedia.org:29418/mediawiki/core

* branch master -> FETCH_HEAD

2d68215ff7a..25895192125 master -> origin/master

Successfully rebased and updated refs/heads/T12814-hello.

c:\php\mediawiki\core>git review -R
wbm1058@gerrit.wikimedia.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

If you get a Permission denied (publickey). fatal: Could not read from remote repository., review the instructions at mw:SSH keys#Add SSH Private key to use with Git to make sure your ssh agent is running and your identity is added. If you close your Git Bash shell, you will be signed out and need to re-follow these instructions each time.

c:\php\mediawiki\core>eval `ssh-agent`
'eval' is not recognized as an internal or external command,
operable program or batch file.

Is there a way to run git bash from the Windows cmd prompt?

Inside a git bash window:

Bill@Mobile-laptouch MINGW64 ~
$ eval `ssh-agent`
Agent pid 272

Bill@Mobile-laptouch MINGW64 ~
$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /c/Users/Bill/.ssh/id_ed25519:
Identity added: /c/Users/Bill/.ssh/id_ed25519 (wbm1058-wikipedia@yahoo.com)

Then I went back to Windows command window, tried "review" again, and still got the "permission denied" error. – wbm1058 (talk) 20:28, 21 May 2024 (UTC)

I haven't seen this exact error before, and your setup is rather different from mine, so this is a guess, but: the eval `ssh-agent` command actually works by setting environment variables, which everything else on your system can read to access the SSH agent. Maybe you just need to close and reopen the command prompt window again, so that it sees the new env variables? Matma Rex talk 21:02, 21 May 2024 (UTC)

"Is there a way to run git bash from the Windows cmd prompt?" You can run something like "C:\Program Files\Git\usr\bin\bash.exe" from the command prompt, and it will run, but this is unlikely to do anything good. It will probably be confused about text encodings, file paths, and ANSI escape codes. (On Windows 10, they're slightly less incompatible.) Can you say why you want to do it? Matma Rex talk 21:15, 21 May 2024 (UTC)

(edit conflict) I just tried doing it from my git bash window instead of command prompt...

Bill@Mobile-laptouch MINGW64 /c/php/mediawiki/core (T12814-hello)
$ git review -R
remote:
remote: Processing changes: new: 1 (\)
remote: Processing changes: new: 1 (|)
remote: Processing changes: new: 1 (/)
remote: Processing changes: new: 1 (-)
remote: Processing changes: new: 1 (\)
remote: Processing changes: new: 1 (|)
remote: Processing changes: refs: 1, new: 1 (|)
remote: Processing changes: refs: 1, new: 1 (|)
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1034588 Show the page name on the MovePage checkbox for "Yes, delete the page" [NEW]
remote:
To ssh://gerrit.wikimedia.org:29418/mediawiki/core.git

* [new reference] HEAD -> refs/for/master%topic=T12814-hello

I guess that worked?! wbm1058 (talk) 21:11, 21 May 2024 (UTC)

Yep, that worked. * Pppery * _{it has begun...} 21:15, 21 May 2024 (UTC)

Yeah, just doing everything from the Git Bash window is probably the best way to have the least amount of weird issues. Matma Rex talk 21:16, 21 May 2024 (UTC)

Time for a lager! Cheers! :) wbm1058 (talk) 21:25, 21 May 2024 (UTC)

Rebase

Matma Rex, responding to your request at code review to edit another file. Per the instructions at mw:Gerrit/Tutorial#Rebasing, I clicked on the REBASE button in Gerrit's web interface, and it responded with a "Confirm rebase" box with radio buttons for "Rebase on top of the master branch" or "Rebase on a specfic change, ref, or commit". I'm unclear on which I should choose, and whether to check the "Allow rebase with conflicts" box. "It's best to make rebase updates a separate patch, so that your code reviewers have an easy time seeing what changes you've made."

"Hard reset and checkout the change with this command: (BEWARE: git review -d performs a hard reset that destroys all local changes. Stash or commit changes first which you wish to preserve!)" – what is meant by "stash" a change? That term only appears that one place on that page; it's not defined there. – wbm1058 (talk) 21:22, 22 May 2024 (UTC)

That patch doesn't have a merge conflict so you don't need to worry about rebasing it at all. And "stash" in that context refers to the git stash command. * Pppery * _{it has begun...} 23:17, 22 May 2024 (UTC)

Don't I want to amend / add a file to my existing commit rather than add a second commit to my existing branch? Branches and commits, I'm still not comfortable with the terminology and how they fit together.

Funny, when I entered 'git' to get the usage and list of "common git commands" it didn't list "stash". – wbm1058 (talk) 00:46, 23 May 2024 (UTC)

For gerrit and git review, yes. For patchset 2 or higher, you'll want to git stage, then git commit --amend, then git review -R –Novem Linguae (talk) 02:13, 23 May 2024 (UTC)

Ack, though I see the term "stage" several times in mw:Gerrit/Tutorial, I don't see any explicit "git stage" command. Oh (looking it up), that's a synonym for "git add".

I was looking at mw:Gerrit/Tutorial#Amending a change (your own or someone else's), and mw:Gerrit/Tutorial#Rebasing is a subsection of that section. The way I'm reading it, it implies that rebasing is a mandatory, not optional, step that's part of the "amending a change" process.

Oh, I see. the --amend tells it to amend my first commit rather than add a second commit. – wbm1058 (talk) 03:02, 23 May 2024 (UTC)

I think if you do git review without the -R, it will auto rebase. But i was taught not to auto rebase, and just to do it manually when needed. –Novem Linguae (talk) 03:05, 23 May 2024 (UTC)

I think a few things on that tutorial page are outdated – both Gerrit and git-review have had some changes related to rebases since it was written, and they mostly removed the footguns that this page tries to teach you to avoid. I'll have to read it more carefully and update it. Generally, you shouldn't have to think about rebasing, or do anything to avoid it, or click the "Rebase" button, unless you see an error somewhere telling you that there is a merge conflict in your change. Matma Rex talk 15:48, 23 May 2024 (UTC)

Thanks, that makes sense. In baseball, a runner taking a big lead off first base sometimes needs to rebase when he sees a pitch conflict (pitch going to first base rather than home plate). Ha! wbm1058 (talk) 17:14, 23 May 2024 (UTC)

I removed all of the bad and outdated advice from that section: [2][3][4][5] and added some good advice instead: [6]. Hope that helps explain it. I concede that it is not entirely unlike baseball. Matma Rex talk 23:14, 24 May 2024 (UTC)

Page misbehaving in search results

I use this search query to see pages tagged for speedy deletion. For several days it has returned BBL Drizzy as a result even though that page is not tagged for deletion. The search results say it was last edited at 01:12 on 13 May 2024, which corresponds with Special:Diff/1223572833 (now in the history of Draft:BBL Drizzy). Purging or null-editing either the article or the draft will make it disappear from the results temporarily, but so far it's always come back shortly thereafter. Today I tried deleting and undeleting the pages, but this didn't help either. Any suggestions? (This query brings up strange results too, for what it's worth.) Extraordinary Writ (talk) 03:01, 19 May 2024 (UTC)

I don't experience this. BBL Drizzy is not a result for the first query, and the last query only brings up BBL Drizzy (last edited 19:04, 18 May 2024). – 2804:F1...7F:938A (talk) 03:15, 19 May 2024 (UTC)

Strange. The second query returns this for me, and some fiddling around at this site (pick Australia, Indonesia, India, etc.) suggests I'm not alone. Extraordinary Writ (talk) 03:40, 19 May 2024 (UTC)

I've been seeing some outdated search results also related particularly to a couple page moves that got done between when the search was crafted and when my fix was made. Particularly, in this search I'm seeing Draft:Peter the Great Interrogating the Tsarevich Alexei Petrovich at Peterhof and Draft:Ellen Webster Palmer when I hit one or another of the data centers (which I assume is at least part of the problem), but at least once I've gotten a search not to return those two, because neither are drafts any longer nor do either carry the problem that makes them show up in this search. Izno (talk) 20:36, 19 May 2024 (UTC)

The Appearance menu and new default standard font size will be available for logged-out users

Hi everyone! We are the Wikimedia Foundation Web team. We work on making it easier to read Wikimedia projects as part of the objective "Reading and media experience" of the current year’s annual plan. To achieve this goal, we have introduced the "Accessibility for Reading" beta feature. It adds a menu which works on the Vector 2022 skin and allows logged-in users to choose different font sizes and color schemes based on individual needs.

The menu introduces a new Standard font setting. It slightly increases the size and height of the font. It was selected based on multiple sources. You will find more information on this in the section "About the new Standard font setting". As we announced last week, we are now ready to begin bringing some of these feature out of beta and making them available to more people.

What will change

• We are now ready to make the new Appearance menu available for logged-out and logged-in users.
• At the same time, we will also make the Standard option the new default for logged-out users only.
• If no breaking technical issues are found, we plan on making this change within the next three weeks.
• Later, this menu will also include the option to select dark mode, which for the time being will remain a beta feature. For more information, check out our project page.

About the menu

The new menu will allow logged-in and logged-out users to set preferences for:

1. Text size and line height (available now as the beta feature): Users will be able to choose between the Small (current default), Standard (recommended for better accessibility), and Large options. Selecting an option will change both the font size and line height of the text.
2. Dark mode (available now as the beta feature): Users will be able to choose to see the site in night mode on a permanent basis, or select an "automatic" setting which will set day or night mode based on the device or browser preferences.

3. 

   Content width (previously available as a toggle button): We have moved the content width toggle from an icon at the bottom of the page to a labeled radio button in the new menu. It will work exactly the same as the toggle. The previous toggle button will no longer be available.

This menu has been tested as a beta feature by logged-in users across wikis as well as in user testing with readers. Based on the findings of these tests, we changed the menu to improve discoverability and ease of use, and to accommodate gadget compatibility.

The menu will appear to the right of the page, immediately under the Tools menu if that has been pinned. Unlike the Tools menu, the Appearance menu is pinned by default, but can be unpinned. Once unpinned, it collapses under an icon at the top of the page.

About the new Standard font setting

The "Small" option is the current default. We will be changing this default to "Standard" for logged-out users, while keeping "Small" as the default for logged-in users. The "Standard" and "Large" options were built and tested based on the following:

• Academic studies and recommendations for the best average font size for the majority of readers. These recommendations stated that our current size is too small for the majority of people to read comfortably. This means that on average, people read more slowly, strain their eyes while reading, or have difficulty clearly seeing the text. Increasing the font size by default improves these issues for all users, including users who might not have sufficient time to spend adjusting a setting via the appearance menu or browser. Information density is also important, which is why we wanted to increase font size without sacrificing information density. We have achieved this by changing not only font size, but also line height and paragraph spacing.
• Designs submitted by more than 630 Wikipedians from across 13 wikis of different languages, scripts, and sizes. The majority (~450) of these users opted for a font size that was larger than the default. "Standard" represents the average of the most popular cluster of responses (15-20 pixels). "Large" represents the need for an even larger option, as represented by the cluster of sizes between 21-26 pixels. You can read more on how we included volunteers in the process and landed on these options.
• Beta feature usage showed that the majority of users who interact with the feature at least once opt for a font size that is larger than the current default.

Our works so far and next steps

Logged-in users will remain with the "small" setting for the time being as their default, but can change to any other setting at any time. In a few months, we will study how many logged-in users switch to standard and start a conversation on whether it makes sense for logged-in users to make the switch as well. From the early data from the beta feature, 55% of sessions who interacted with the feature chose to use a setting that was standard or larger.

If you'd like to help, we have a few simple requests for you:

1. Please, turn on the beta feature ("Accessibility for Reading (Vector 2022)")
2. Try out the new menu. Is anything confusing? Do you understand all the labels and how the menu works?
3. Try out the small, standard, and large sizes, the color schemes, and the width toggle. Reach out to us if you notice any bugs, or have questions or concerns.

If you'd like to learn more about the project, see our FAQ. Comments and questions are most welcome. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 13:58, 20 May 2024 (UTC)

Wikilinks to `((RSS))` article are broken

I noticed this at Aaron Swartz and Web feed: links to the article on the web feed format RSS (link here > RSS <) are not displaying on Wikipedia articles

Type "[[RSS]]" for "RSS" and it displays as "" for me. PK-WIKI (talk) 19:19, 20 May 2024 (UTC)

Works for me: RSS * Pppery * _{it has begun...} 19:57, 20 May 2024 (UTC)

The link displays and works normally for me in all five tested browsers. It sounds like something in your browser is messing with the link, maybe an extension for RSS feeds. PrimeHunter (talk) 20:08, 20 May 2024 (UTC)

 Resolved Thanks, didn't even think that text on Wikipedia would be targeted by a content blocker. 1Blocker "Block Annoyances" setting responsible. PK-WIKI (talk) 20:21, 20 May 2024 (UTC)

Strange CSS behavior

I recently noticed that the CSS style background:transparent seems to turn the text color dark gray when combined with the class thumbinner and viewed through the beta vector night mode. Does anyone know why this happens? Andumé (talk) 20:12, 20 May 2024 (UTC)

The text color generally is a dark grey. Can you be more specific ? —TheDJ (talk • contribs) 09:58, 21 May 2024 (UTC)

In general however, if you define a background color, you should ALWAYS define a text color and vice versa, if you want to avoid problems with night/dark mode. —TheDJ (talk • contribs) 10:00, 21 May 2024 (UTC)

In dark mode, there is some blanket CSS for "it has a background but is relying on inherited color" which obviously doesn't work in a lot of places. Izno (talk) 17:13, 21 May 2024 (UTC)

My script (I use Vector 2022) stopped working this week

Link classifier missing in Vector 2022

The Link Classifier which if I recall is maintained by Anomie has disappeared from my Vector (2022) skin. I use this frequently and have just now noticed it, so I is likely something very recent. I switched back to Vector (2010) just to check and it was still available there. Any suggestions about how to get this back in Vector (2022)? older ≠ wiser 21:29, 20 May 2024 (UTC)

WMF has recently changed the software so that in Vector 2022 personal Javascript/CSS are loaded only from Special:MyPage/vector-2022.js and Special:MyPage/vector-2022.css. You are loading it only in Special:MyPage/vector.js. You will need to copy whatever you want from there to the vector-2022 version, or to your Common.js at Special:MyPage/common.js (which is the best place for it - scripts are/should be responsible for loading where they should; styles may vary more so they may not be as obvious to move). Remove it from vector.js if you add it to common.js. Izno (talk) 22:06, 20 May 2024 (UTC)

Thank you. That worked. older ≠ wiser 23:40, 20 May 2024 (UTC)

Thanks, this probably should solve the above problem as well. I will try later today. Ymblanter (talk) 08:36, 21 May 2024 (UTC)

Copied Ymblanter's comment from above:

Not sure whether it is related but I am using one of the user scripts (do not have time now to search which one) which, in particular, highlights in pink pages proposed for deletion. The highlighting is gone today (checked on two different devices, different browsers), which gives me a HUGE headache for CFD handling. Ymblanter (talk) 08:35, 21 May 2024 (UTC)

Izno (talk) 17:09, 21 May 2024 (UTC)

Prompt for edit summary on rollback from watchlist?

Hi there, long time fan, first time caller...

I very much like having a link on my watchlist page that will allow me to perform rollback while prompting me for a custom edit summary. My JS pages were a bit of a mess, but I believe I'd been using User:Nageh/rollbackSum.js for this purpose.

Earlier this week the 'sum' links provided by that script disappeared for me. Nageh (talk · contribs) hasn't edited since 2014 and, while I tried a few other scripts that I found, none of them seemed to re-add such a link to my watchlist either. Has something changed that makes this no longer possible? The ability to add a custom edit summary when doing rollback from my watchlist is very valuable to me, so it would be a shame if the upshot was that this simply is no longer possible. Thanks for your help! DonIago (talk) 03:43, 24 May 2024 (UTC)

@Doniago, see section header of which I've made your question a subsection. Izno (talk) 15:27, 24 May 2024 (UTC)

Thanks Izno. I've tried copying a version of rollback.js to my common.js page with no evident change at this time. DonIago (talk) 16:12, 24 May 2024 (UTC)

The line above it has no ; and misspells importScript with a lowercase s. This may or may not cause issues. Izno (talk) 16:32, 24 May 2024 (UTC)

Thanks Izno! I'm not sure which of the changes I made per your notes fixed it, but it seems to be fixed! DonIago (talk) 16:55, 24 May 2024 (UTC)

Tech News: 2024-21

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 Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [7]
• New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [8][9]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [10][11]
• The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 23:01, 20 May 2024 (UTC)

Based on a quick search, it looks like the heading change will affect almost 300 scripts, many of which have inactive maintainers. Some arbitrary highlights from the top of the list include:

• Awesome Aasim's User:Awesome Aasim/rcpatrol.js
• BrandonXLF's User:BrandonXLF/FFUHelper.js
• Cacycle's User:Cacycle/wikEd.js, User:Cacycle/wikEd dev.js, and User:Cacycle/wikEd.user.js
• DannyS712's User:DannyS712/DiscussionCloser.js, User:DannyS712/SectionRemover.js, and User:DannyS712/SectionMover.js
• Enterprisey's User:Enterprisey/reply-link.js, User:Enterprisey/copy-section-link.js, User:Enterprisey/archiver.js, User:Enterprisey/strike-archived.js, User:Enterprisey/section-watchlist.js, and User:Enterprisey/section-redir-note.js
• Equazcion's User:Equazcion/OneClickArchiver.js, User:Equazcion/TeahouseRespond.js, and User:Equazcion/NewSectionSummary.js
• Evad37's User:Evad37/OneClickArchiver.js and MediaWiki:Gadget-XFDcloser-core.js
• Mr. Stradivarius's User:Mr. Stradivarius/gadgets/SignpostTagger.js
• PhantomTech's User:PhantomTech/scripts/AFCRHS.js
• SD0001's User:SD0001/RFUD-helper.js
• Terasail's User:Terasail/COI Request Tool.js
• Technical 13's User:Technical 13/Scripts/OneClickArchiver.js
• The Earwig's User:The Earwig/permalink.js and User:The Earwig/afc-helper.js
• The Evil IP address's User:The Evil IP address/hdedit.js

Plus many, many more. --Ahecht (TALK
PAGE) 19:22, 21 May 2024 (UTC)

A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)

Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has <section> tags around each section, which may require a separate set of updates in some scripts).

Disabling DiscussionTools doesn't actually change anything though. The HTML structure is the same whether it's enabled or disabled, only the styles are different. Also, note that it uses a "hybrid" heading structure currently when using the default parser, as you say, but it uses the new structure when using Parsoid.

So in short, you can just use Parsoid mode to test these scripts today here on English Wikipedia, but beware that there may be extra issues. But if they work with Parsoid, they will work with the new headings too. Matma Rex talk 11:25, 22 May 2024 (UTC)

The technical 13 script was blanked, so we don't have to worry about that one.

Will the fact that they're rolling this out for only some wikimedia-deployed skins at this time make the patch more complicated? If I'm reading it right, the scripts may temporarily have to support both heading styles. –Novem Linguae (talk) 09:16, 22 May 2024 (UTC)

Yes, it does, and they have to. Matma Rex talk 11:20, 22 May 2024 (UTC)

At a glance, it seems that User:Mr. Stradivarius/gadgets/SignpostTagger.js already supports the new style, as it uses $( '#bodyContent h2:first' ).text() as a backup if $( '#bodyContent h2:first span.mw-headline' ) doesn't exist (line 291). — Mr. Stradivarius ^{♪ talk ♪} 13:09, 22 May 2024 (UTC)

Fixed RFUD-helper. Thanks for the ping. – SD0001 (talk) 18:33, 22 May 2024 (UTC)

This is going to break both my edit request scripts, I will try to fix them at the weekend. Terasail^[✉️] 18:41, 22 May 2024 (UTC)

Where is the code for an info-box? Where does it go?

I'm trying to create some info-boxes on a small hobby wiki. It had been running fine on "freewiki.in" but that domain disappeared last year. I've re-created it on a domain I control using MediaWiki v1.41.1. I've put up all the article text from .XML backups, but all the formatting is gone.
The software manual at https://www.mediawiki.org/wiki/Global_templates/Taxonomy explains how to use {{ambox}} but not the code required for it to work. It sends me to Wikipedia, to https://en.wikipedia.org/wiki/Module:Message_box. That, finally, has 600+ lines of code.
Where does this code go? Somewhere on the wiki? Somewhere on the server in one of the .PHP files? There's gotta be a step-by-step procedure somewhere but I can't find it. And I'm not about to do my experimenting here on Wikipedia...
Answers can be here, if this is of general interest. If not, I'd be perfectly happy getting help at my talk page. SandyJax (talk) 13:05, 21 May 2024 (UTC)

It goes exactly where it is here, on the page Module:Message box. Snowmanonahoe (talk · contribs · typos) 16:42, 21 May 2024 (UTC)

... but otherwise requires only the use of mw:Extension:Scribunto and mw:Extension:TemplateStyles. Izno (talk) 17:08, 21 May 2024 (UTC)

If you preview code, e.g. an infobox call, then the bottom of the window shows all transcluded templates and modules at "Templates used in this preview". It can be a long list, and the list can change if the same template is called with different parameters or circumstances (e.g. the namespace it's called from). Some of the infobox styling in the English Wikipedia is in MediaWiki:Common.css which is not listed at "Templates used in this preview" since it's not transcluded but used in another way. PrimeHunter (talk) 18:30, 21 May 2024 (UTC)

Template dagger malfunctioning

Resolved

Immediate assistance required because template:dagger currently outing this †. Anoop Bhatia (talk) 01:14, 22 May 2024 (UTC)

Link to an edit request about it: Template talk:Dagger#Template-protected edit request on 22 May 2024. – 2804:F1...10:A60F (talk) 02:37, 22 May 2024 (UTC)

It is not malfunctioning, it is doing what it is supposed to do, to notify everyone about the ongoing discussion. But I can see how this can be disruptive to the reading experience when it is being used multiple times within a short space, i.e. at Atlanta Braves#Braves Hall of Fame. – robertsky (talk) 03:45, 22 May 2024 (UTC)

@Robertsky: Thanks 👍🏻. Anoop Bhatia (talk) 04:03, 22 May 2024 (UTC)

The IPA in Wikipedia comes with some errors.

SUBJECT

The IPA in Wikipedia comes with some errors.

I am quite happy that Wikipedia uses the IPA as a pronunciation guide. I know the IPA moderately well, so its use is convenient for me. Promoting the IPA in Wikipedia might also encourage people to learn it, which probably might not be a bad idea.

I think that the use of the IPA in Wikipedia might often or consitently make some errors. I don’t see these errors being made in Wiktionary though. The IPA there seems to be largely fine.

the approximant rhotic (also the approximant alveolar)

/ɹ/

The English language uses primarily for a rhotic the approximant alveolar which in the IPA is represented as: /ɹ/.

In Wikipedia, this rhotic seems to always get represented by /r/, which actually represents the rolled “r”, as the “r” in the Spanish word “perro”.

I’ve suspected that this error is deliberate in that maybe the people setting up the IPA transcriptions are concerned that an upside down “r” might confuse people. Although, this doesn’t make very good sense since much of the rest of the IPA will still confuse people who are not familiar with it.

From Wikipedia showing the incorrect /r/ use :

Tripoli (/ˈtrɪpəli/; Arabic: طرابلس الغرب, romanized: Ṭarābulus al-Gharb, lit. 'Western Tripoli')

From Wiktionary using the correct /ɹ/. use :

entourage

Pronunciation

(UK) IPA(key): /ˈɒn.tʊ.ɹɑːʒ/, /ˈɑ̃ː.tʊ.ɹɑːʒ/

(US) IPA(key): /ˈɑn.tə.ɹɑʒ/

/ɑ/, /a/, /æ/

These might be described as the “basic a” vowels: /ɑ/, /a/, /æ/

/a/ and /æ/ are similar and are like the “a” in “cat”.

/a/ is more open and might be more typical for Received Pronunciation or a British English. /æ/ is similar sounding but just with an articulation that is a bit more close (closed jaw) and is probably more typical for General American English or Standard Canadian English. Distinguishing between these two is not too much of a big deal, I don’t think for general pronunciation purposes.

The /ɑ/, described as a back, open, unrounded vowel, is like the “o” in the English word “top”. This vowel is more of what is considered an “a” vowel in languages such as Spanish, Italian, and other languages. This /ɑ/ though is significantly different from the /a/ and /æ/.

I’ve seen on a number of occasions in Wikipedia in which words with the /ɑ/ sound were given IPA transcriptions of /a/. I went looking for examples in Wikipedia of this today, but had difficulty finding this.

Here’s an example from Wiktionary where the /ɑ/ sound is written as /a/.

Pronunciation

(UK) IPA(key): /ˈɒn.tʊ.ɹɑːʒ/, /ˈɑ̃ː.tʊ.ɹɑːʒ/

(US) IPA(key): /ˈɑn.tə.ɹɑʒ/

I finally managed to find an example of the /ɑ/ sound being written as /a/.

Croatia (/kroʊˈeɪʃə/ ⓘ, kroh-AY-shə; Croatian: Hrvatska, pronounced [xř̩ʋaːtskaː]

Specifically, the [xř̩ʋaːtskaː]

I noticed in my search for words with an /ɑ/, for words that have this sound in General American English or Standard Canadian English, that same sound in Received Pronunciation often gets pronounced as /ɒ/, which is a very open “o” and pronunciation given in Wikipedia may tend to favor Received Pronunciation.

the schwa and the caret

This is an issue that probably would have to be directed towards the IPA Association or something like that, and not Wikipedia. But, I’ll mention it here anyways.

Apparently, any phonetics course, most phonetics courses, will tell you that no word in English ends with a caret. So, take the word “the” or “California”. Wiktionary will transcribe these into the IPA as :

the:

(when unstressed and preconsonantal)

enPR: thə, IPA(key): /ðə/

California:

(General American) IPA(key): /ˌkæl.ɪˈfoɹ.njə/, /ˌkæl.ɪˈfoɹ.ni.ə/, [ˌkʰæl.ɪˈfo̞ɹ.njə]

It’s typical to see IPA transcriptions of the words “the” and “California” as ending with the schwa, /ə/.

Transcribing the final vowel in the words “the” and “California” as /ə/ to me seems wrong. Maybe my hearing sense is off. Maybe the articulation is /ə/ but to me sounds like /ʌ/ or /ɐ/.

Give it a try? The /ə/ or schwa is the vowel sound you more or less get between the “p” and “l” in “apple” in General American and probably Received Pronunciation. Or find some online IPA chart with audio pronunciation to find out how /ə/ is pronounced.

Now try sticking that sound into the word “the” or at the end of the word “California”. Maybe I’m not getting this right, but it consistently sounds wrong! Like weird!

Maybe when speaking quickly these sounds will reduce to an /ə/ sound. But even when spoken quickly, these words can often just sound like they end with a quick /ʌ/ or /ɐ/.

I used to think that “the” and “California” should be transcribed as /ðʌ/ and /ˈkalɪfɔɹnjʌ/, with the the /ʌ/ at the end of the word. This makes auditory sense to me.

More recently though, when realizing that / ʌ/ and /ɐ/ sound very similar, that for that sound, if the preceeding consonant is more forward, then maybe the more forward of /ʌ/ and /ɐ/ would actually be articulation being used, which is the /ɐ/. So, the word “the” would more likely be transcribed as:

/ðɐ/

With “California”, this might be different. The /j/ sound before the final vowel, it’s more central so would it make the final vowel sound /ɐ/ or /ʌ/? Maybe the /ʌ/ sound fills an entire linear area that connects the more middle /ɐ/ and the more back /ʌ/, in which case it could get kind of complicated or difficult to figure out where the articulation of this sound is taking place exactly.

I suspect that if the /ʌ/ sound is preceeded by a more back consonant, such as in the English word “gut”, then the /ʌ/ sound will take more of a back /ʌ/ articulation, as you get with the Wiktionary transcription of “gut”.

gut

Pronunciation

IPA(key): /ɡʌt/

Zbniorb (talk) 06:34, 22 May 2024 (UTC)

This is not a technical inquiry. The appropriate venue is the talk page of the IPA key for each language, though I strongly suggest you read the Handbook of the IPA and learn the difference between a phone and a phoneme and the concept of narrowness first. Nardog (talk) 06:57, 22 May 2024 (UTC)

Issue with template

Hi there. There seems to be some kind of issue with {{Population WD}}. I would like to use it to get the bare population figure. At first, {{population WD|qid=Q559227|show=value}} was not working, and I was getting the figure plus a "<span" at the end. Primefac has solved it, at least partially. But there still seem to be some issues, as can be seen here. Thanks in advance for the help, Alavense (talk) 08:19, 22 May 2024 (UTC)

My guess is that the {{first word}} is cutting off the coding to show the "edit at Wikidata" icon, but I have a) no idea why it's doing that, and b) no idea how to fix it. Primefac (talk) 08:37, 22 May 2024 (UTC)

Yes, something like that. The createicon function in Module:WikidataIB starts off with a non-breaking space, so {{first word}} is grabbing a few more tokens than we want. — jmcgnh^{(talk) (contribs)} 08:57, 22 May 2024 (UTC)

And, yes, nbsp is not considered one of the ASCII whitespace characters by some regular expression engines, including, according to what we've seen here, Lua's %s. — jmcgnh^{(talk) (contribs)} 09:19, 22 May 2024 (UTC)

This Special:Diff/1225091340 seems to be a possible fix. It returns just the population value, whichever way the noicon parameter is set. Of course, if you really wanted that pencil icon, you'll need to use something different from {{first word}}. @Primefac and Alavense: — jmcgnh^{(talk) (contribs)} 09:37, 22 May 2024 (UTC)

There should not be any regexes that treat a nbsp as whitespace. For a start, its value is outside the 0x00-0x7F range; second, whilst it's encoded as 0xA0 under Unicode, some character sets use the same value for a different, non-blank, printing character - for example, in Code page 437, it's used for the "á" character. Third, ASCII whitespace is defined as characters 0x09 through 0x0c inclusive plus 0x20. --Redrose64 🌹 (talk) 19:40, 22 May 2024 (UTC)

@Redrose64 That's a very outdated point of view. Regex engines these days generally operate on Unicode and understand Unicode characters, or at least have an option to do so, and "whitespace" often means all Unicode whitespace, not ASCII whitespace. Matma Rex talk 21:16, 22 May 2024 (UTC)

The HTML spec is outdated then. Pity, as it was last updated 22 May 2024, which was, er, today. --Redrose64 🌹 (talk) 23:04, 22 May 2024 (UTC)

Pity, as the HTML spec is irrelevant to how Lua or PHP process whitespace. Izno (talk) 23:36, 22 May 2024 (UTC)

The HTML spec is very careful to call it out as ASCII whitespace every time that term is used, precisely because just saying whitespace often means Unicode whitespace. Matma Rex talk 15:40, 23 May 2024 (UTC)

@Jmcgnh Lua's %s should actually match non-breaking spaces, if I understand the documentation correctly.

Template:First word uses Module:String, which uses mw.ustring. The docs for Ustring patterns say %s "represents all characters with General Category "Separator"", and NBSP is a separator (see e.g. the entry in Whitespace character#Unicode for reference).

I think the problem in the original code is that in [ %s] the entity isn't interpreted, so it finds the first occurrence of &, n, b, etc. It will probably work if you do just [%s]. Matma Rex talk 21:14, 22 May 2024 (UTC)

Oh, good, we're getting some people involved who know more than me. @Redros64, Matma Rex, and Izno: As I read it, {{First word}} already supplies %s as the default separator AND the results show that it is not treating nbsp as a member of %s. If I were going to spend more time on this, I'd first get rid of {{First word}} to see how many results are coming back - as an experiment. If there are multiple results (not just one string with multiple values in it), I'd argue that the job of selecting what to return needs to either be pushed down into WikidataIB or maybe do like the show=year branch and use Ustring|gsub to pull out the desired part of the data.

Primefac's current fix provides the correct defaults, but if someone wants to specify show=value|noicon=FALSE it would be best if the result didn't contain stray markup tokens. I checked for how show=year|noicon=FALSE would behave and it seems to get it right for Alavense's test case. I wish I understood a little better how that Ustring|gsub expression matching worked. As I look at it, it shouldn't be working for this case. If I could figure that out better, I'd be in favor of getting rid of {{first word}} and using a Ustring call for show=value as well as for <show=year>. — jmcgnh^{(talk) (contribs)} 02:34, 23 May 2024 (UTC)

I don't know much, I just looked up the docs :)

As I read it, {{First word}} already supplies %s as the default separator AND the results show that it is not treating nbsp as a member of %s.

I had a look at the output of {{#invoke:WikidataIB|...}} in Special:ExpandTemplates, and I can at least explain that – it's because the WikidataIB module isn't emitting an actual nbsp character, but rather it's emitting the   HTML entity. The string matching functions just see that as a sequence of &, n, b, and so on. So you would need to make {{First word}} look for that sequence, instead of individual characters, but it has no way to do that.

You could probably implement this by invoking Module:String directly – but at this point I would take a step back, and see if there's some way to just output the bare population figure from Wikidata directly, instead of using a big template and applying another big template on top of it to discard most of its results, because that how you end up with pages that bump into parser limits. I'm not very familiar with this stuff, but there must surely be one. Matma Rex talk 15:31, 23 May 2024 (UTC)

@Matma Rex: I agree with your suggested direction and thanks for being so clear about the confusion I was exhibiting between Ustring characters and HTML character entities. On a cursory look at available templates or modules to use instead of WikidataIB, I was not coming up with anything obvious. I will return to study this in greater detail, including trying to understand all the parameters passed to WikidataIB, as time allows. I do conclude that {{First word}} is simply the wrong template to use in this situation. — jmcgnh^{(talk) (contribs)} 20:52, 24 May 2024 (UTC)

Differentiation of subheading font sizes (or more accurately, lack thereof)

I've just used subheadings for the first time, and was somewhat dismayed to see hardly any noticeable differentiation between Subheadings 2, 3, and 4. Couldn't the subheadings be differentiated more?

Surely some other Wiki editors must have made similar comments long before I came on board ... Augnablik (talk) 11:54, 22 May 2024 (UTC)

Yes, I think many of us got confused at first and pointed out that h3 looks more prominent than h2, but there doesn't seem to be a consensus to change the styles and eventually we got used to it. I hope it doesn't lead too many readers astray. Certes (talk) 12:04, 22 May 2024 (UTC)

How could there be any editorial disagreement about the need for a technical fix to remedy this situation, @Certes? Of course it could lead readers astray!

It's not like the discussion going on elsewhere at the Village Pump on the topic of COI guidelines, with many senior editors all over the field as to just what COI is and what should be required of editors in self-reporting it. Augnablik (talk) 12:42, 22 May 2024 (UTC)

@Certes, I hope it didn’t seem to you in my reply to you above that I was unhappy with you personally. I was just reacting in surprise — okay, shock — that Wiki editors who deal with this sort of thing wouldn’t have very easily come to consensus about the need to make h2 and h3 look different from each other … for the sake of readers. Augnablik (talk) 16:27, 22 May 2024 (UTC)

I wasn't at all insulted or offended. I agree with you that h2 should be more prominent relative to h3. I think the problem is that h3 is bolder than h2, which can give the illusion that it is more important despite not being larger. Of course, it's easy for the regulars to put together a bit of CSS to make it look how we prefer it, but we're a tiny minority of the audience: we're both thinking of the casual reader who can't be expected to jump through that hoop for each site they visit. Certes (talk) 19:58, 22 May 2024 (UTC)

The appearance of headings and subheadings varies with several factors, including (but not limited to): zoom level, skin, browser, installed fonts, operating system. You can experiment using e.g. Wikipedia:Sandbox in various skins - Cologne Blue; MinervaNeue (mobile); Modern; MonoBook; Timeless; Vector legacy (2010); Vector (2022). Notice that besides the font size, there are variations in font family, also underlining. --Redrose64 🌹 (talk) 20:40, 22 May 2024 (UTC)

You can override the heading styles from your common.css, eg:

#content h3 { font-size: 116%; text-decoration-line: underline; } -- Verbarson  ^talk_edits 22:30, 24 May 2024 (UTC)

trying to add new GeoJSON map to virgin river article - centering is getting messed up

I'm trying to add this to Virgin River:

{{mapframe|from=Virgin River (Utah).map|text=Route of the Virgin River and the North and East Forks|frame=yes|zoom=7|frame-coord|coord=37.174167,-113.326111}}

The problem is that every time I preview my proposed change the center of the map is completely off. It's like it's pulling the coordinates of the mouth from wikidata.org and using that vs using the more central coordinate that I'm using.

Assuming that that's the case idk that I necessarily want to change it. Ideally I'd like to just overwrite it for that one map. But if that's not possible I guess I could change the wikidata.org entries altho https://www.wikidata.org/wiki/Q1676970 shows multiple coordinate locations. Would just the first one need to be changed? I'm a little hesitant to save experimental changes like that. I'd rather Preview my changes before saving them but, assuming my hypothesis is correct then I'd prob need save it all the same, even if only to save just to preview TerraFrost (talk) 12:04, 22 May 2024 (UTC)

You are not setting |frame-coord= so it's retrieiving the coordinates from Wikidata. You have |frame-coord| which is acting as a positional parameter, equivalent to |1=frame-coord. You want to use |frame-coord={{Coord|37.174167|N|113.326111|W}} which will allow you to shift the centre. —  Jts1882 | talk  14:11, 22 May 2024 (UTC)

"Publish" is a little too quick on the draw

I've been editing the Houseboat article and once again when I tried to review my changes before publishing a few minutes ago, they got published — with no summary, because I wanted to be reminded of the things I'd done in my edits. This has happened a few times before as well.

And because these edits were major changes, including the addition of new information along with a supporting citation and the removal of some existing text for greater clarity, I'll probably get a finger wag from a senior editor about this. 🫤

Augnablik (talk) 12:32, 22 May 2024 (UTC)

In Special:Preferences#mw-prefsection-editing, you can select "Prompt me when entering a blank edit summary". That may help. Certes (talk) 12:38, 22 May 2024 (UTC)

Aha. Thanks ... but I wonder why we have to opt in about this, given that we're not supposed to send blank edit summaries? Augnablik (talk) 12:45, 22 May 2024 (UTC)

I recall there being a discussion about this somewhere - if my memory serves me correctly, the idea of not having this on by default is to avoid there being an extra layer of friction that may discourage newer good faith editors.

In any case, there is no formal obligation to provide an edit summary; rather, the edit should be explained in some manner, or be self-explanatory, something which can be achieved after the fact through talk page discussion. WindTempos ^{(talk • contribs)} 12:59, 22 May 2024 (UTC)

If you have accidentally made major changes without a good edit summary and want to fix that, the standard way is to make a Dummy edit. —Kusma (talk) 13:08, 22 May 2024 (UTC)

There are several keyboard actions that will trigger a save - in no particular order, they include:

• Pressing Alt+⇧ Shift+S at any time
• Pressing ↵ Enter when the focus is on one of: the edit summary; the "This is a minor edit" or "Watch this page" checkboxes; the Publish changes button
• Pressing Space when the focus is on the Publish changes button

We forget these when using a mouse all the time. --Redrose64 🌹 (talk) 19:56, 22 May 2024 (UTC)

Edit Patrol on Android Wikpedia mobile app is now available on English Wikipedia and all wikis!

We invite you to check out a demonstration of the feature and explore more on our project page. If you have tried the feature, we would appreciate any feedback on our discussion page, or your thoughts in response any of the following questions:

• What changes or additions would make this feature more useful to you?
• Would you be interested in using this feature to patrol multiple language wikis at once?
• The feature is currently available to users with rollback rights: would you like to see this feature evolve into something that is available to a broader user group?

--ARamadan-WMF (talk) 10:33, 23 May 2024 (UTC)

Sorting titles, some with appended text

Hello, regarding List of cult films: K, it seems like the listings The Killer and The Killing, both which neighbor listings that have longer titles starting with Killer or Killing, wind up at the bottom of each respective group when sorting alphabetically, when they should come first, having nothing after that keyword. Am I doing something wrong? Is there a way to fix it? See for yourself here. EDIT: I guess I fixed it by adding two spaces after each title, but this feels like too much of a hack. Is there a proper way to do this? Erik (talk | contrib) ^{(ping me)} 15:58, 23 May 2024 (UTC)

It probably should be using {{sort}} rather than {{sortname}}. The latter makes the sort key "Killer, The" because it is intended to be used with the name of a person. Johnuniq (talk) 00:43, 24 May 2024 (UTC)

@Erik: The problem is that {{sortname}} automatically inserts a comma. {{sortname|The|Killer}} is sorted as "Killer, The". The comma sorts after the space in "Killer Nun" while the title should logically have been sorted before. In [12] you avoided the issue by placing spaces at the end in {{sortname|The|Killer }} so it sorts as "Killer  , The". It works in the current implementation where spaces aren't stripped but it's not a pretty solution and other editors can easily remove the spaces without knowing the consequence. You could use optional sort key in {{sortname}} to give "Killer" as the full sort key with no comma or "The". Should {{sortname}} be changed to omit the automatic comma? Probably not. It's mostly used for people and often mixed with manually written sort keys like "Doe, John". Omitting the comma when the template is used would mess that up. PrimeHunter (talk) 20:03, 24 May 2024 (UTC)

Omitting the automatic comma wouldn't even fix this case where "Killer The" would still sort after "Killer Nun". A possibility would be for {{sortname}} to add a special case where {{sortname|The|Anything}} ignores "The" and just sorts as "Anything". "The" is unlikely to be the first name of a person which should be included in the sort key. PrimeHunter (talk) 20:17, 24 May 2024 (UTC)

But it's not a natural person's name right  ? So why use sortname to being with ? —TheDJ (talk • contribs) 22:07, 24 May 2024 (UTC)

sortname is often used on "The", probably because it's well-known and convenient: hastemplate:sortname insource:"sortname The". I don't know how often it gives poor sorting but it's probably rare that the sorted items are close enough. PrimeHunter (talk) 22:33, 24 May 2024 (UTC)