Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Lofty abyss (talk | contribs) at 18:40, 27 May 2024 (→Did some hue scheme change in popups?: eh, section above seems similar enough...). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.

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)[reply]

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".-- Ponyobons mots 21:43, 15 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@Novem Linguae: it happens on any IP contributions page (this one, for example).-- Ponyobons mots 15:29, 16 May 2024 (UTC)[reply]
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)[reply]
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.-- Ponyobons mots 16:13, 16 May 2024 (UTC)[reply]
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)[reply]
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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
Oh, oops, aparently I'm just as confused. * Pppery * it has begun... 21:24, 17 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Facepalm 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The tests pass on php 8.2 as well [1], – SD0001 (talk) 12:16, 20 May 2024 (UTC)[reply]

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.

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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
Weird, that link works for me now. Maybe it took a few minutes to generate. Matma Rex talk 00:35, 21 May 2024 (UTC)[reply]
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)[reply]

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)[reply]

 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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
"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)[reply]
(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)[reply]

Yep, that worked. * Pppery * it has begun... 21:15, 21 May 2024 (UTC)[reply]
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)[reply]
Time for a lager! Cheers! :) wbm1058 (talk) 21:25, 21 May 2024 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

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)[reply]
Thank you. That worked. older ≠ wiser 23:40, 20 May 2024 (UTC)[reply]
Thanks, this probably should solve the above problem as well. I will try later today. Ymblanter (talk) 08:36, 21 May 2024 (UTC)[reply]
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)[reply]

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)[reply]

@Doniago, see section header of which I've made your question a subsection. Izno (talk) 15:27, 24 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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:
Plus many, many more. --Ahecht (TALK
PAGE) 19:22, 21 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Yes, it does, and they have to. Matma Rex talk 11:20, 22 May 2024 (UTC)[reply]
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)[reply]
Fixed RFUD-helper. Thanks for the ping. – SD0001 (talk) 18:33, 22 May 2024 (UTC)[reply]
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)[reply]
I'm assuming ~ and feel free to correct me if i'm wrong ~ that something about this deployment is why headings no longer have numbers (for me)? Will it be possible to go back to that at some point? I find long pages almost impossible to navigate around without numbered headings, so will have to learn a new way of working if it won't be possible. Thanks, Happy days, ~ LindsayHello 16:24, 27 May 2024 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
Pity, as the HTML spec is irrelevant to how Lua or PHP process whitespace. Izno (talk) 23:36, 22 May 2024 (UTC)[reply]
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)[reply]
@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 [&nbsp;%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)[reply]
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)[reply]
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 &nbsp; 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)[reply]

@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)[reply]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
You can override the heading styles from your common.css, eg:
#content h3 { font-size: 116%; text-decoration-line: underline; } -- Verbarson  talkedits 22:30, 24 May 2024 (UTC)[reply]

"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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The first one is enabled using an accesskey S. The exact combination of Shift/Alt/Control/⌥Option is different depending on the OS and browser. All combinations are described at Wikipedia:Keyboard shortcuts. —⁠andrybak (talk) 11:09, 25 May 2024 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
I used explicit sort keys including a third problem entry The King.[13] PrimeHunter (talk) 09:48, 25 May 2024 (UTC)[reply]
Thank you! I will use this approach instead. Is there an easy way to identify problems like The King? On my laptop, I was just eyeballing the difference between the order in the code and the sorted order, but The King was too far down for me to see shift in order. Would like to be able to check all the pages and fix the order and sorting where needed. Erik (talk | contrib) (ping me) 00:03, 27 May 2024 (UTC)[reply]
I haven't done it before but here are three ideas which all require something:
  1. Zoom far out (Ctrl+- in Windows browsers) to view more rows at the same time.
  2. Use the sort arrow on a previewed version where the first rows have been removed or commented out.
  3. Copy-paste the sorted and unsorted rendered table with your browser and make a diff with some tool, e.g. someting at Google:online diff.
I tested it and spotted The Kingdom with all three. PrimeHunter (talk) 00:25, 27 May 2024 (UTC)[reply]

Template-generated category problems

The latest run of Special:WantedCategories features a weird cluster of "Decade in nothing" redlinks that are being autogenerated by {{Sport clubs (dis)established in the YYY0s category header}} because the template appears to be failing to import a variable. The template itself does not appear to have been recently edited at all, so it's very likely a module doing this, but as I don't have module-editing privileges I wouldn't be able to fix it myself even if I could find the issue, so the following categories are going to need somebody else to look into them.

Category:1810s in, Category:1820s in, Category:1830s in, Category:1840s in, Category:1850s in, Category:1860s in, Category:1870s in, Category:1880s in, Category:1890s in, Category:1900s in, Category:1910s in, Category:1920s in, Category:1930s in, Category:1940s in, Category:1950s in, Category:1950s in, Category:1960s in, Category:1970s in, Category:1980s in, Category:1990s in, Category:2000s in, Category:2010s in, Category:2020s in.

Thanks. Bearcat (talk) 13:46, 25 May 2024 (UTC)[reply]

There was a recent edit Special:Diff/1225161437 in the /core subtemplate, which doesn't seem suspicious.  Checking... in the sandbox using the special debugging parameter |diagnose=yes. —⁠andrybak (talk) 14:03, 25 May 2024 (UTC)[reply]
 Fixed in Special:Diff/1225599206. —⁠andrybak (talk) 14:14, 25 May 2024 (UTC)[reply]
@Gonnym, I think I figured out the root cause. In Special:Diff/1225161437, the pipe | was incorrectly left in the usages of {{lcfirstletter}}. That is, {{lcfirst:|{{{sport}}}}} instead of {{lcfirst:{{{sport}}}}}. Feel free to re-implement the switch back to magic words, I don't think this template relies on special features of templates {{ucfirstletter}} and {{lcfirstletter}} for skipping non-letter characters. —⁠andrybak (talk) 14:21, 25 May 2024 (UTC)[reply]
Thanks andrybak, sorry I missed the pipe and thanks for catching that! Gonnym (talk) 07:58, 27 May 2024 (UTC)[reply]

Infobox (Road) alpha? issue with above=/Dark mode

In {{Infobox road}} the above value passed on to Infobox image appears to be interpreted as if it had a white backgound, resulting in white corners/edges or a white box around the sign (it's always a white box, but sometimes the visual impact is otherwise). In dark mode this looks pretty bad. However it doesn't happen to next/previous images, or the junction images. See for example Garden_State_Parkway, note the white box around the sign at the top, and the grey around CR 508 (both in dark mode).

I beleive that CSS or {{Infobox}} are creating somthing relating to above that is interfering with the gadget, and providing a light background, where is should be inherited from an outer div.

Any ideas/confirmation?

All the best: Rich Farmbrough 15:02, 25 May 2024 (UTC).[reply]

White background for File:GSPkwy Shield.svg on the page Garden State Parkway in dark mode comes from these lines of CSS code: MediaWiki:Gadget-dark-mode.css#L-156--L-163, quote:
/* Content image (thumbnail) SVGs */
/* `*not( .mbox-image )` exception doesn't work for unclear reasons */
html .image img[ src*='svg' ],
html .mw-file-description img[ src*='svg' ],
html img[ src*='Wiktionary-logo'] {
	background-color: #fff;
	border-radius: 1px;
}
I can't seem to find what you mean by the grey around CR 508. I think File:CR 508 jct.svg is not affected, because linking to the filepage is disabled via |link=. Compare vs —⁠andrybak (talk) 15:51, 25 May 2024 (UTC)[reply]
Note: File:GSPkwy Shield.svg is selected by {{Infobox road}} from Module:Road data/strings/USA/NJ#L-196, based on parameters |state=NJ (the two-letter postal abbreviation of the state) and |type=GSP . —⁠andrybak (talk) 16:05, 25 May 2024 (UTC)[reply]

Strange behaviour with SVG file

The file "2022 Russian invasion of Ukraine.svg" is used in the infobox of Russian invasion of Ukraine where it's look perfectly normal. Going to File:2022 Russian invasion of Ukraine.svg and it still looks correct, but if I load the original file most of it is in Chinese. Is this just me? -- LCU ActivelyDisinterested «@» °∆t° 16:26, 25 May 2024 (UTC)[reply]

Not me, at least. This uses the SVG switch elements, so it's probably an issue with your browser or something else thinking your system language is Chinese. — Alien333 (what I did & why I did it wrong) 17:45, 25 May 2024 (UTC)[reply]
I'm using chrome on android, and can't see any reason it should believe my system language is Chinese. This appears to be an error with whatever is doing the switching. -- LCU ActivelyDisinterested «@» °∆t° 17:50, 25 May 2024 (UTC)[reply]
I tested on Chrome and Android, and it still works for me. When you say "most of it is in Chinese", are there still some English (or other language) parts? — Alien333 (what I did & why I did it wrong) 18:00, 25 May 2024 (UTC)[reply]
Yep only parts of the file. -- LCU ActivelyDisinterested «@» °∆t° 18:16, 25 May 2024 (UTC)[reply]
Well, at least the partial translation is the same as the traditional chinese file, so it's just showing you that version of the file, though I can't tell why. — Alien333 (what I did & why I did it wrong) 18:30, 25 May 2024 (UTC)[reply]
The traditional Chinese file is different, notice 'Wyzwolone Ukrainskie terytoria' that shows in the legend I see but not in the traditional Chinese file. -- LCU ActivelyDisinterested «@» °∆t° 18:33, 25 May 2024 (UTC)[reply]
I'm seeing a file that's partially in different languages. -- LCU ActivelyDisinterested «@» °∆t° 18:33, 25 May 2024 (UTC)[reply]
Indeed, I should have looked closer before posting. It seems it's not even using this version of the file, because some of it (ex. the exact chinese legend next to the red dot, that is one line long and then a hyphen) does not appear at all in any of the actual languages of the file. — Alien333 (what I did & why I did it wrong) 18:43, 25 May 2024 (UTC)[reply]
I get the same mishmash of languages with older versions of the file, choosing 07:54, 12 May 2024 at random. -- LCU ActivelyDisinterested «@» °∆t° 18:48, 25 May 2024 (UTC)[reply]
I wondered if it was a similar issue to Wikipedia:Village pump (technical)/Archive 212#Serbian place names displayed on Manhattan maps. -- LCU ActivelyDisinterested «@» °∆t° 18:28, 25 May 2024 (UTC)[reply]
I think it's different, as that was with OpenStreetMap labels and this is SVG translation. — Alien333 (what I did & why I did it wrong) 18:31, 25 May 2024 (UTC)[reply]

Help with regex

I'm looking to search for article with titles matching '[number][ordinal][space]Road', but for all my trying I can't get it to work. I get intitle and using []{} for a certain number of character but whatever I put together doesn't work. Any help would be appreciated. -- LCU ActivelyDisinterested «@» °∆t° 17:40, 25 May 2024 (UTC)[reply]

What is your specific search query? Izno (talk) 17:56, 25 May 2024 (UTC)[reply]
I don't a working one, I was trying "in title:/[0-9]{1,3}[a-z]{2} Road/ but I've obviously got something wrong. I'm looking to find pages such as 30th Road, 73rd Road, etc. -- LCU ActivelyDisinterested «@» °∆t° 18:01, 25 May 2024 (UTC)[reply]
I wasn't looking for a working one. :) You've misspelled intitle as in title, this query works. Izno (talk) 18:06, 25 May 2024 (UTC)[reply]
That's autocorrect it does the same for me with hastemplate becoming 'has template'. I'm apparently cursed when it comes to regex, I'd swear I had tried the exact same search. Thanks for the help. -- LCU ActivelyDisinterested «@» °∆t° 18:22, 25 May 2024 (UTC)[reply]

My brain hurts

I started to answer the question above, but quickly ran into something I don't understand. Regex searches ignore the indexes, so it makes sense to do a composite search which includes a term that hits the index and then a regex to filter that down. But when I try intitle:Road intitle:/[0-9]+/ (link) I get results that include London Inner Ring Road. That doesn't match the regex. H:BOOLEAN says Search terms are implicitly joined by AND but that doesn't seem to be what's happening here. RoySmith (talk) 15:20, 26 May 2024 (UTC)[reply]

intitle: often appears not to work. In this case, it's probably showing that result because of redirects such as A1202 road. Certes (talk) 15:27, 26 May 2024 (UTC)[reply]

Mass revdel across pages of one contributor

I'm in the process of revdel'ing personal attacks from edit summaries of 2601:85:C100:2770:51F5:457E:4CD9:606B (talk · contribs) made by undoing an editor's contributions on many pages. I have the mass rollback tool, so that was no problem. But now I have to revdel them one by one since they are on different pages. Is there a way that they can all be lumped together for revdel? – Muboshgu (talk) 19:05, 25 May 2024 (UTC)[reply]

I know of some user scripts that have been developed for this: User:Writ Keeper/Scripts/massRevdel.js, and User:Blablubbs/massrevdel NOS.js which is a fork of the first one for non-oversighters. DanCherek (talk) 20:10, 25 May 2024 (UTC)[reply]

Track listing/Professional ratings overlap for music albums

Speaking from the average viewer's POV (i.e., not logged in), I noticed when I visited the album pages for Ohio Players and Follow the Lights that the right side of the Track listing overlaps with the left side of the Professional ratings, with the text visibly overlapping (superimposed) as well. This was observed in Safari on a Mac mini, but not in Firefox. I'm merely reporting this, and not trying to fix it myself. Peterh6658 (talk) 22:49, 25 May 2024 (UTC)[reply]

Template gadgets

I was reading about Template gadgets in the Signpost and its use in Spanish Wikipedia (for example in their Conway's game of life article) and was wondering if that is implemented here yet. 28bytes (talk) 01:10, 26 May 2024 (UTC)[reply]

The server-side code is deployed here. Local iadmins haven't made use of it. Edit requests to do so welcome. * Pppery * it has begun... 01:24, 26 May 2024 (UTC)[reply]
Thanks Pppery. If I wanted to include the Game of Life gadget on either the article or its talk page, what would be the next steps to take? 28bytes (talk) 01:34, 26 May 2024 (UTC)[reply]
The steps, for an iadmin, assuming sufficient consensus to do so, are explained at mw:Template:Conway's Game of Life#Installation. The steps for a non-iadmin would presumably be to follow step 1 there and then use {{edit interface-protected}} to request an iadmin (like myself) do steps 2 and 3. What I would probably actually do is use Wikipedia:Bots/Requests for approval/SDZeroBot 13 (cc SD0001) to sync mw:MediaWiki:Gadget-Global-Vivarium.js locally rather than loading code from MediaWiki.org, but you don't have to care about that. * Pppery * it has begun... 01:50, 26 May 2024 (UTC)[reply]
Thanks again. Step 1 is done. I'll make an edit request over at Talk:Conway's Game of Life. 28bytes (talk) 02:04, 26 May 2024 (UTC)[reply]

Weird mobile web diff display

[14]

Normally, mobile (source, not visual) diff displays removed text in yellow and added text in blue in the same block of text. In this said diff, the edited paragraph is (confusingly) displayed twice, one copy indicating removed text, the other one added text. Could you reproduce this? Is this a bug or intended behavior? Thank you. Janhrach (talk) 07:52, 26 May 2024 (UTC)[reply]

Are you trying to use the mobilefrontend view with vector-2022, leading you to getting the desktop-type vector-2022 output? — xaosflux Talk 12:12, 26 May 2024 (UTC)[reply]
Huh? That diff is indeed what you get via https://en.m.wikipedia.org/enwiki/w/index.php?title=Clan_Livingstone&action=history. I agree the repetition of "This battle was fought..." is highly misleading. Nardog (talk) 15:24, 26 May 2024 (UTC)[reply]
I filed a task for this at the tail end of the better diffs initiative last year. phab:T349335. Izno (talk) 16:28, 26 May 2024 (UTC)[reply]
Is that the same thing? That task doesn't seem to be about mobilefront end view? Here is the mobilefrontend+minerva (what should be default) view of the story in this thread: https://en.m.wikipedia.org/enwiki/w/index.php?title=Clan_Livingstone&diff=prev&diffonly=1&oldid=1225714396&useskin=minerva . Is that not appearing as expected? — xaosflux Talk 16:18, 27 May 2024 (UTC)[reply]
@Xaosflux, mobile diffs now use the same machinery as normal diffs. And no, it is not appearing as expected, the paragraph beginning with This battle was fought between various north-western highland clans from the lands of Ross, against the Earl of Ross and his followers. is repeated. Izno (talk) 16:20, 27 May 2024 (UTC)[reply]
Thanks, see it now, yup seems buggy for sure. — xaosflux Talk 16:24, 27 May 2024 (UTC)[reply]

New diff preview problem

This started sometime between midnight UTC last night and 10:30 UTC today, Monday 27 May. I use Edge on Win 11, Monobook, Navigation popups enabled, and the Use a black background with green text gadget. When I point my mouse at "diff" on my watchlist now the pop up/preview/whatever you call it is now very much harder to read, the change is "highlighted" by shewing the removed text in black on a grey background then the added text in black on a brown background. Please help! DuncanHill (talk) 11:09, 27 May 2024 (UTC)[reply]

@The wub? Izno (talk) 15:47, 27 May 2024 (UTC)[reply]

Images in sidebars for mobile view

Hi. I have been fixing up climbing articles on Wikipedia (e.g. alpine climbing, mixed climbing, and ice climbing). I know that per 'Template:Sidebar', that the sidebar doesn't appear on mobile (which makes sense to me), but is there any way for the main image used in the top section of the sidebar to appear in mobile view (i.e. a qualifier in the sidebar image to say whether it should appear in mobile view)? The images that I have put into the top of the sidebar are good ones and have helpful captions that I think a mobile reader would enjoy? thanks. Aszx5000 (talk) 11:33, 27 May 2024 (UTC)[reply]

Do not use sidebars to provide meaningful images, is really the correct response, and in fact at some point they will not be available at all (somewhere in my backlog of work). If you want an image to display, you should use either a thumb image or an infobox, and of course both must fit the requirements for the main image. Izno (talk) 15:47, 27 May 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1225955346"