Wikipedia:Village pump (technical)

(Redirected from Wikipedia:VPT)
Latest comment: 2 hours ago by Qwerty284651 in topic Sticky row headers issues
 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

special:export edit

Are special:export broken? I get an error if I choice "Include templates". Christian75 (talk) 08:35, 10 May 2024 (UTC)Reply

Yes :( T364554 It'll probably be fixed on Monday. Matma Rex talk 09:48, 10 May 2024 (UTC)Reply
Thanks. Resolved today. Christian75 (talk) 21:10, 13 May 2024 (UTC)Reply

Thumb version and small version of some images are not shown edit

  Resolved

Hi, for example, for the image c:File:Nasseraldinshah3.png the thumb version and small version are not shown. i.e,

Large version (280px) thumbnail version (not shown) small version (220px) (not shown)
 
 
 

This problem happens in Windows OS and Edge, Chrome and Firfox browsers, but not at Android. Please inspect. Thanks, Hooman Mallahzadeh (talk) 08:24, 11 May 2024 (UTC)Reply

None of them are rendering for me. Firefox 125.0.3 --Redrose64 🌹 (talk) 14:03, 11 May 2024 (UTC)Reply
@Redrose64 If you zoom in and out, the pictures would appear and disappear. But why this phenomenon occurs? Hooman Mallahzadeh (talk) 14:27, 11 May 2024 (UTC)Reply
OK, if I use Ctrl++ to zoom in one step (to 110%), the left-hand image appears. If I zoom in four more steps (making five in all), to 170%, the second and third appear. By this time, the images are approaching the "natural" size of the image, which is 394 × 532 pixels; my guess is that there's something funny about the jpeg encoding that doesn't allow reduction beyond a certain limit. --Redrose64 🌹 (talk) 15:14, 11 May 2024 (UTC)Reply
@Redrose64 Maybe! But this happens only for specific images between Wikipedia articles. When I view that at commons or standalone it seems that zoom in/out has no effect on its appearance. Hooman Mallahzadeh (talk) 15:27, 11 May 2024 (UTC)Reply
There may be something broken with the full-size version of this image that browsers can cope with (which is why that can be displayed), while the software that's supposed to generate smaller versions can't. It may be enough just to download the affected images, open them in an image editing program, save a new copy, and upload that copy as a new version of each affected image (but I believe you need to be autopatrolled on Commons for that). Rummskartoffel 16:52, 11 May 2024 (UTC)Reply
 
Size 100px
MediaWiki appears unable to scale it to any size. Only the original upload works. HTML for the "small" 220px version:
<a href="/wiki/File:Nasseraldinshah3.png" class="mw-file-description"><img src="//upload.wikimedia.org/wikipedia/commons/thumb/d/db/Nasseraldinshah3.png/220px-Nasseraldinshah3.png" decoding="async" width="220" height="297" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/d/db/Nasseraldinshah3.png/330px-Nasseraldinshah3.png 1.5x, //upload.wikimedia.org/wikipedia/commons/d/db/Nasseraldinshah3.png 2x" data-file-width="394" data-file-height="532"/></a>
MediaWiki uses srcset to offer different sizes and let the browser choose depending on circumstances. The above has three choices:
  1. https://upload.wikimedia.org/wikipedia/commons/thumb/d/db/Nasseraldinshah3.png/220px-Nasseraldinshah3.png
  2. https://upload.wikimedia.org/wikipedia/commons/thumb/d/db/Nasseraldinshah3.png/330px-Nasseraldinshah3.png
  3. https://upload.wikimedia.org/wikipedia/commons/d/db/Nasseraldinshah3.png (original 394px upload)
A smaller 100px version doesn't include the original 394px in srcset so no zooming will help there. PrimeHunter (talk) 16:44, 11 May 2024 (UTC)Reply
Oddly, for me with Chrome 124.0.6367.158, looking at the diff for the initial post in visual diff mode displays all three images in the diff, but not in the page being displayed below the diff (I only see the leftmost image). (On Firefox 125.0.3, only the leftmost image is displayed in the visual diff and the page displayed below.) isaacl (talk) 17:24, 11 May 2024 (UTC)Reply
Also when I do a simple reload via Ctrl-R on Chrome, all three images are displayed. (I see all three after posting a comment in this section; presumably the equivalent of a simple reload is being done.) If I do a force reload of the entire page via Shift-Ctrl-R on Chrome, just the leftmost image is shown. For me, page zoom doesn't cause the images to display/not display. isaacl (talk) 17:31, 11 May 2024 (UTC)Reply
The 100px version in PrimeHunter's post doesn't display for me under any of these cases. isaacl (talk) 17:40, 11 May 2024 (UTC)Reply
With both simple reload and force reload, I see three network requests being made. The first is for Nasseraldinshah3.png and it succeeds. The second two are for 330px-Nasseraldinshah3.png and 150px-Nasseraldinshah3.png, and they fail with a 429 code, "Too many requests". (As previously noted, the three images are displayed after the simple reload.) isaacl (talk) 18:05, 11 May 2024 (UTC)Reply
Is this one of those multitudinous image problems that needs the image to be reuploaded to be fixed? — Qwerfjkltalk 18:34, 11 May 2024 (UTC)Reply
I don't know. I think I understand better now why a simple reload causes the images to appear: since the original file URL (which was successfully retrieved) appears in the srcset for each of the images in the original post (but, as PrimeHunter stated, it doesn't get included for the 100px version), the browser will just use that to refresh the page, rather than try to match the file with the most appropriate pixel density based on the physical display (since with a simple refresh, the browser will try to avoid loading the images again, so there's no need to do a match if any of the images in the set are already available). My device probably has a different pixel density than the other commenters, such that changing the zoom level isn't causing the original image to be a match to be loaded. isaacl (talk) 22:58, 11 May 2024 (UTC)Reply
I've uploaded a corrected version, but due to the 429, it will probably take a while (not sure how long) before we can see the effect of that. —TheDJ (talkcontribs) 09:16, 13 May 2024 (UTC)Reply
It's fixed now. I processed it with the png-fix-IDAT-windowsize utility, to correct the invalid checksum it contained. —TheDJ (talkcontribs) 15:30, 13 May 2024 (UTC)Reply

Can't login to the Wikipedia library edit

I do get this message "We are unable to validate your login credentials. Please contact your institution for assistance. Please note, Referring URL authentication may have been prevented by antivirus or privacy control software" but I'm not convinced that's the issue. But if others are able to login, it must be. Thanks. Doug Weller talk 09:34, 11 May 2024 (UTC)Reply

I don't have the issue when I can see my credential in the upper right hand corner, and then search for Wikipedia:TWL . I can then see the library when I click on database access. Maybe the message is an artifact. -- Ancheta Wis   (talk | contribs) 09:50, 11 May 2024 (UTC)Reply
The error message matches one at EBSCO, which is just one of the partners with TWL. I doubt it's TWL you can't log into. Nardog (talk) 10:18, 11 May 2024 (UTC)Reply
@Nardog@Ancheta Wis That makes sense. I can login to the WL but not use it to search for articles. I can click on Access Collection - but I'm puzzled by the fact that when I click on Brill it looks as though it just takes me to their web page, and if I click on a books offers it for sale. I've never clicked on Brill before so don't know if that's what it should do. Doug Weller talk 12:14, 11 May 2024 (UTC)Reply
Hello Doug Weller! I'm having the same problem, can get to the Library page but as soon as I use the search I'm taken to the EBSCO Error page you describe. Others also reporting this problem, like here. I use the Library all the time, use it to access ProQuest as an invaluable source for referencing. Hope this is just a temporary glitch. Take care, LooksGreatInATurtleNeck (talk) 22:37, 11 May 2024 (UTC)Reply
Thanks. Looks like there are other problems as well. Doug Weller talk 02:46, 12 May 2024 (UTC)Reply
cc @Samwalton9 (WMF). –Novem Linguae (talk) 17:00, 13 May 2024 (UTC)Reply
@Doug Weller, Ancheta Wis, Nardog, LooksGreatInATurtleNeck, and Novem Linguae: Apologies for the delay in responding here, but we believe this issue should now be fixed. Samwalton9 (WMF) (talk) 08:48, 15 May 2024 (UTC)Reply
Hello Samwalton9! No worries, I saw the reply over on the Wikipedia Library talk page. Thank-you kindly for fixing the issue! The Library is so useful for researching & referencing, I wouldn't want to be without it. Take care, LooksGreatInATurtleNeck (talk) 10:38, 15 May 2024 (UTC)Reply
@Samwalton9 (WMF) Thanks. Ironic that when I searched for an article it led to a nonexistent page. I still found it though. Doug Weller talk 12:39, 15 May 2024 (UTC)Reply

Migrating SQL data from one toolforge db to another edit

I run two tools on toolforge, both of which have SQL databases. I'd like to consolidate them under one of the tools and would like to migrate the data in one of the databases to the other. I could do this with a script to extract the data to a file, then connect to the other location and insert the data, but that's a lot more trouble than insert into <newdb>.<newtable> select * from <olddb>.<oldtable>, which is how I'd do it in SQL Server. For that I would need to be simultaneously connected to both databases at the SQL prompt, with write permission on the new database at the same time as read permission on the existing database, which is not currently public. Is there a way to do this at the MariaDB SQL prompt or do I have to just write that script? Mike Christie (talk - contribs - library) 12:42, 11 May 2024 (UTC)Reply

I could do this with a script to extract the data to a file, then connect to the other location and insert the data. This is how I would do it. Can probably do everything you need from the command line. –Novem Linguae (talk) 16:59, 13 May 2024 (UTC)Reply

May 2024 Accessibility for Reading Update: appearance menu, upcoming font size changes and customization, dark mode, and more edit

 
The Appearance menu with the corresponding parts: 1. Typography 2. Dark mode 3. Page width options

Hi everyone! This is an update on the current work of the Web team on the Accessibility for Reading initiative that introduces changes to the Vector 2022 and Minerva skins. It improves readability, and allows everyone, both logged-out and logged-in users, to customize reading-focused settings. It will also increase the default font size for logged-out users of wikis and introduce dark mode. Customization will be done through the new Appearance menu, which will contain options for customizing 1. typography (font size, line height, and paragraph spacing combined), 2. color scheme (dark/light), and 3. page width.

1. Appearance menu, typography improvements, and font size changes for logged-out users

In December 2023, we introduced the "Accessibility for Reading" beta feature. It adds the Appearance menu which allows logged-in users to choose different font sizes and page widths. This makes it possible for people to read in a font size that they prefer and customize their experience. Since the introduction of the menu, we have studied its usage and performed usability testing:

  • No significant issues were observed, but based on the feedback, we have changed the copy and behavior of the menu (for example, we have renamed the "night" color scheme to "dark").
  • The majority of users who interact with the feature opt for a font size that is larger than the current default. This confirms our hypothesis that most users prefer a larger font size. We previously saw this in the findings from the community prototype testing.

Based on this data, we plan on increasing the default font size for all readers. The current (smaller) default will be kept for logged-in users and as one of the options so that anyone can return to the font size used in the past.

2. Dark mode

Dark mode is a highly-requested reading feature which was the top wish on last year’s Community Wishlist. We will bring dark mode to the desktop and mobile websites. Currently, dark mode is available to logged-in users on the mobile site (Minerva skin only). To access this feature, you must first be opted into advanced mode for mobile. Then, you can select "dark" from the list of color options. ("Automatic" will follow the preference of your device.) See the more detailed message about this change.

3. Page width options

  • With the introduction of Vector 2022, we made available the option for all readers and editors to switch their view from limited to full with a toggle in the bottom right corner of the screen.
  • That limited/full width toggle will be moved to the Appearance menu instead of being in the corner of the screen.
  • We will be also switching some pages to full width by default, including the main page.

Coming up soon!

Over the next weeks, we will be preparing for significant deployments related to this project:

  • First, we plan on introducing dark mode to the desktop website as a beta feature.
  • Then, we will bring the Appearance menu for all users and change the default font size for all logged-out readers.
  • Finally, after a period of testing, we plan on bringing dark mode into the Appearance menu for all users on the desktop and mobile websites.  

This is just a report. Later this week, we will post more information, and invite you to a discussion. In the meantime, please check out the Accessibility for Reading beta feature. If you want to know more about the project, go to our project page for updates and general overview, and to the FAQ page for more details. You can also subscribe to our newsletter. Thanks! SGrabarczuk (WMF) (talk) 13:33, 13 May 2024 (UTC)Reply

The above message says: The majority of users who interact with the feature opt for a font size that is larger than the current default. This confirms our hypothesis that most users prefer a larger font size. Leaving aside the selection bias problems in that statement, the phabricator link appears to indicate the opposite, that 44.9% of sessions eventually opt for small (default: font=0) font size; 43.6% of sessions eventually opt for standard (font=1) font size; 11.5% of sessions eventually opt for large (font=2) font size. What am I missing? – Jonesey95 (talk) 14:34, 13 May 2024 (UTC)Reply
Hey @Jonesey95. The selection bias part needs to be addressed by someone else than me, but to your point about the link indicating the opposite: Standard + Large (larger font size) > Small (default). SGrabarczuk (WMF) (talk) 16:36, 13 May 2024 (UTC)Reply
That's what I was missing: the small size was the default. I confused the word "standard" with "default", I suppose. – Jonesey95 (talk) 17:07, 13 May 2024 (UTC)Reply
Hey @Jonesey95 - wanted to leave a quick note on the selection bias question. In terms of the selection bias, we recognize that there is a very specific audience that will be opted into our beta feature, which is a downside of any beta feature data to begin with. This is generally an audience of active logged-in users who are interested in trying out new features in the first place (they are quite different from the average reader). For some features, that might be a sufficient proxy. For others, it might not make as much sense. In general, we try to get data from multiple different sources in order to account for this. In this case, we did prototype testing on a subset of logged-in users across languages, user testing with logged-out readers, as well as the beta feature launch. We've also launched the feature as the default for logged-out users on a small set of wikis to see if the data we're seeing there resembles what we saw on beta. These should be sufficient predictors of the behavior in production, but it's important to measure and double-check. Once we have a wider release, we'll do a similar comparison as well. OVasileva (WMF) (talk) 14:41, 14 May 2024 (UTC)Reply

Panoviewer.toolforge.org is down edit

Template does not work. Panoviewer.toolforge.org is down. Liglioto (talk) 09:38, 13 May 2024 (UTC)Reply

Template:PanoViewer isn't protected, feel free to adjust it. That external tool isn't supported by us here on the English Wikipedia, and has sparse documentation on where to report problems. You can try to open a bug on it similar to phab:T354949. — xaosflux Talk 15:33, 13 May 2024 (UTC)Reply
Noting for reference that following phab:T354949#9792952, Panoviewer seems to be working again. All the best, ‍—‍a smart kitten[meow] 12:14, 14 May 2024 (UTC)Reply

Typing, but text appears a few lines below my cursor edit

Hi, I'm encountering a weird bug (it's not the first time it's happened). When I type text in a long page in visual source editing (the 2017 wikitext mode), I'm getting some funky behaviour where what I'm actually typing ends up being multiple lines below my cursor. The video attached is this occurring on this page, but it sometimes happens on other such long pages.

Any ideas to debug?

Cheers, Cocobb8 (💬 talk • ✏️ contribs) 21:29, 13 May 2024 (UTC)Reply

Smells like a code highlighter userscript/gadget bug. Are you able to reproduce when adding ?safemode=1 / &safemode=1 to the URL? This will turn off gadgets and user scripts. I suspect you will not be able to reproduce it. Next step after that will be tracking down which code highlighter userscript/gadget and reporting the bug on their talk page. –Novem Linguae (talk) 08:07, 15 May 2024 (UTC)Reply
@Novem Linguae I did some debugging, and figured out that the issue is caused by the Syntax Highlighter itself. I'll report it on Phabricator. Cocobb8 (💬 talk • ✏️ contribs) 13:04, 15 May 2024 (UTC)Reply

Tech News: 2024-20 edit

MediaWiki message delivery 23:56, 13 May 2024 (UTC)Reply

CORS auth edit

Hello. I'm trying to edit Wikidata from Wikipedia (ro.wp to be precise) using a user script, but I am unable to do it under my user. The code from ro:MediaWiki:Gadget-wikidata-description.js works, it obtains an edit token and does the change, but in the history my IP appears. I made sure I am logged in both wikis. Can anyone give me an example of working code or some pointer on how to do the edits as logged-in user? Thanks! Strainu (talk) 08:59, 14 May 2024 (UTC)Reply

mw.ForeignApi is the supported interface for accessing sister site APIs. Fetching a token manually isn't required, postWithEditToken() will do it for you. – SD0001 (talk) 09:08, 14 May 2024 (UTC)Reply
Works like a charm, thank you! Strainu (talk) 09:53, 14 May 2024 (UTC)Reply
  Resolved
Novem Linguae (talk) 08:05, 15 May 2024 (UTC)Reply

Problem in map? edit

Hi,
Tenganan editing shows this (in red):

Preview warning: Page using Template:Infobox settlement with unknown parameter "pushpin_mapsize1"
Preview warning: Page using Template:Infobox settlement with unknown parameter "pushpin_map_caption1"
Preview warning: Page using Template:Infobox settlement with unknown parameter "pushpin_map1"

It was there when I arrived on the page and I have zero idea about what brings that up. (and I'm supposed to be working and I'm starting to run late on the job, so really no time to get into anything as mysterious as that.) Anyone would know how to get rid of that, please? If no (very) simple fix is possible, thanks for letting me know whom I can ask who would be willing to sort it out. Have a good day. Pueblo89 (talk) 13:20, 14 May 2024 (UTC)Reply

  FixedJonesey95 (talk) 13:31, 14 May 2024 (UTC)Reply

Anchoring new sections to set location on talk page edit

As I've formatted my user talk page in a manner that encloses all sections in a table, I was wondering if there is a way to have new talk page sections added at a specific point on a talk page, rather than simply at the end. Specifically, a means that would work with the default 'New section' button above the talk page, rather than the addition of a second, custom 'New section' wikilink or button on the talk page itself. -CoolieCoolster (talk) 01:35, 15 May 2024 (UTC)Reply

There is not. I doubt this is something that will be added. Izno (talk) 02:25, 15 May 2024 (UTC)Reply
If you remove the closing |}</div> tags, new sections will effectively go inside your custom frame. On the other hand, you might get people grumbling about this being a Linter error. Framing talk pages like this isn't well supported. Matma Rex talk 02:40, 15 May 2024 (UTC)Reply

IP Information tool edit

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

Dark mode is available in Vector 2022 as a beta feature edit

 

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)Reply

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)Reply
"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)Reply
Articles too. Along with interface pages, editnotices, syntax highlighting, half the mboxes... Snowmanonahoe (talk · contribs · typos) 00:27, 16 May 2024 (UTC)Reply
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)Reply
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 (talkcontribs) 14:56, 16 May 2024 (UTC)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply

'Undo' button now says 'cin gbere le' edit

 
What it looks like

For some reason, if I go to the page history of any enwiki page, the undo button now says "cin gbere le" instead of "undo", as shown in the screenshot here. It just started happening today all of a sudden. Anyone else had this problem?

Note: the button actually still works, I just tested it here, it's just the button text that's different. — AP 499D25 (talk) 08:41, 16 May 2024 (UTC)Reply

  • Short answer, don't use en-gb. Long answer - its upstream vandalism at translatewiki of the MediaWiki:Editundo message in the en-gb language. Language (Warning: Selecting a language other than 'en - English' will prevent you from seeing localized parts of the interface on the English Wikipedia, and you may see inaccurate external translations.):xaosflux Talk 09:04, 16 May 2024 (UTC)Reply
    The upstream vandalism seems to have been cleared, but now you will have to wait for sync. Or just change to en. — xaosflux Talk 09:09, 16 May 2024 (UTC)Reply
    I created MediaWiki:Editundo/en-gb with "undo". Presumably that can be deleted when it synchronises — Martin (MSGJ · talk) 10:01, 16 May 2024 (UTC)Reply
    I see! Lol. Indeed, I have my interface language set to en-gb. Though I'm not sure how a protected page like that got vandalised. I guess it's unprotected on the translatewiki. — AP 499D25 (talk) 09:16, 16 May 2024 (UTC)Reply
    It's not quite the most aggressive action by the Provisional Change to EN Brigade that I've ever seen, but it's up there. DuncanHill (talk) 10:09, 16 May 2024 (UTC)Reply
    DuncanHill, Just wait until the Real Changes mob find out though  ;) ——Serial Number 54129 10:21, 16 May 2024 (UTC)Reply
Non-English en-gb messages are nearly always somebody editing the wrong Translatewiki messages when trying to translate another language. Here translatewiki:User:Umar Ahmad2345 was trying to make Nupe (nup) which sounds amusingly like noob. It's not an option in our preferences but maybe it's coming. Incubator has a Nupe Wikipedia. PrimeHunter (talk) 11:09, 16 May 2024 (UTC)Reply
Almost nothing is protected on translatewiki for messages, it's ripe for abuse. — xaosflux Talk 13:30, 16 May 2024 (UTC)Reply

Harv and Sfn no-target error help please edit

Hi. One of my pastimes is trying to empty Category:Harv and Sfn no-target errors. Today I found Military courts of the United Kingdom, which has multiple uses of {{sfn|Armed Forces Act|2006}} which are meant to link to {{UK-LEG|title=Armed Forces Act 2006|path=ukpga/2006/52 |ref={{harvid|Armed Forces Act|2006}}}} but don't. I can't work out how to fix the no-target errors and get the link from sfn to citation template to work. Any help will be appreciated, thank you. DuncanHill (talk) 10:22, 16 May 2024 (UTC)Reply

{{UK-LEG}} does not know about |ref= so does not create an anchor ID. Without an anchor ID, {{sfn}} has nothing to link to. Your options are to modify {{UK-LEG}} or implement an appropriate solution from the list of possible solutions at :Category:Harv and Sfn template errors § Resolving errors: {{wikicite}} (best) or {{anchor}} (not so best).
Trappist the monk (talk) 10:53, 16 May 2024 (UTC)Reply
@Trappist the monk: Thanks, so like this? DuncanHill (talk) 22:39, 16 May 2024 (UTC)Reply
I got a bit confused at first because the instructions at :Category:Harv and Sfn template errors § Resolving errors only say "wrapping a plain-text citation inside {{wikicite}} and setting |ref= or |id= as appropriate to match the value expected by the short-cite template", whenwikicite can "be assigned templates as well as text". DuncanHill (talk) 22:53, 16 May 2024 (UTC)Reply

ChristieBot unable to edit Talk:Israeli invasion of the Gaza Strip (2023–present) edit

ChristieBot, which manages GA nominations, has been crashing when trying to transclude the GA review to Talk:Israeli invasion of the Gaza Strip (2023–present). The error is "Page en:Special:Log is not supported due to namespace restriction". The page is extended-confirmed protected. The bot does have extended-confirmed rights as part of the bot group rights, but presumably is missing some other related permission. I can change the code to not crash and simply log the error, but I'm at work and won't be able to touch the code for a few hours. If anyone can tell me what the problem is I would appreciate it. Thanks. Mike Christie (talk - contribs - library) 12:48, 16 May 2024 (UTC)Reply

@Mike Christie check your bot permissions grant, that you have enabled Edit protected pages. — xaosflux Talk 13:33, 16 May 2024 (UTC)Reply
Is this something I can set myself, and if so, where? (I'm not an admin.) I thought that a bot just needed the same user rights as a non-bot editor would need to edit a given page. Mike Christie (talk - contribs - library) 13:46, 16 May 2024 (UTC)Reply
How is your bot logging in? Through the webui, or the api? If the API are you using a consumer grant or BotPasswords? — xaosflux Talk 13:51, 16 May 2024 (UTC)Reply
I don't have access to toolforge from where I am now, and since it was set up eighteen months ago I don't recall the details offhand, but as I recall I have a config set up in the toolforge shell account that handles the bot authentication. I think that means it uses BotPasswords? Mike Christie (talk - contribs - library) 14:04, 16 May 2024 (UTC)Reply
@Mike Christie You'd have to check your PyWikiBot user-config.py file. If it has an authenticate[] = line you're using oauth, if it has a password_file = line you're using BotPasswords. --Ahecht (TALK
PAGE
)
14:08, 16 May 2024 (UTC)Reply
I don't recall getting oauth to work so I think it must be BotPasswords, which I remember dealing with. (If SD0001 is available and has a moment they may be able to look and confirm as they are a maintainer for that bot.) Mike Christie (talk - contribs - library) 14:19, 16 May 2024 (UTC)Reply
@Mike Christie If that's the case, you'd have to go to Special:BotPasswords, log in using your bot account, click on the password you're using for your bot, check the "Edit protected pages" box, and click "Update". --Ahecht (TALK
PAGE
)
14:36, 16 May 2024 (UTC)Reply
It's using BotPassword. It should be able to edit the page if the appropriate grant is checked as mentioned above. But from the error message, I am wondering if there is a code issue as well - the bot seems to be literally trying to edit Special:Log which of course isn't possible. – SD0001 (talk) 17:58, 16 May 2024 (UTC)Reply
That flag is now checked but it hasn't fixed the issue. The issue only occurs when trying to edit that page, using the same code that it uses for transcluding GA reviews on other talk pages, so I can't see why Special:Log is in the picture. There's certainly no explicit attempt by the bot to try to edit the special page. The error happens when it attempts to add text to the Page object's text field: in the traceback I see self.botMayEdit() is called, in pywikibot/page/_basepage.py, which eventually pops out to the Special:Log error for some reason. Later I will have time to add some code to trap the error so at least it'll finish its run, even if it can't do that particular transclusion. I'll do that this evening unless someone has any further ideas. Thanks for the help so far. Mike Christie (talk - contribs - library) 19:04, 16 May 2024 (UTC)Reply
This appears to be an error in pywikibot, I can confirm it also occurs for me.
Full traceback

---------------------------------------------------------------------------
UnsupportedPageError Traceback (most recent call last)
Cell In[1], line 4
2 site = pywikibot.Site('wikipedia:en')
3 page = pywikibot.Page(site, 'Talk:Israeli invasion of the Gaza Strip (2023–present)')
----> 4 page text = 'foo'
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:576, in BasePage.text(self, value)
571 """Update the current (edited) wikitext.
572
573 :param value: New value or None
574 """
575 try:
--> 576 self.botMayEdit() # T262136, T267770
577 except Exception as e:
578 # dry tests aren't able to make an API call
579 # but are rejected by an Exception; ignore it then.
580 if not str(e).startswith('DryRequest rejecting request:'):
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1146, in BasePage.botMayEdit(self)
1131 """
1132 Determine whether the active bot is allowed to edit the page.
1133
(...)
1143 user cnfig file (user-config.py), or using page.put(force=True).
1144 """
1145 if not hasattr(self, '_bot_may_edit'):
-> 1146 self _bot_may_edit = self._check_bot_may_edit()
1147 return self _bot_may_edit
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1163, in BasePage._check_bot_may_edit(self, module)
1161 username = self.site.username()
1162 try:
-> 1163 templates = self.templatesWithParams()
1164 except (NoPageError, IsRedirectPageError, SectionError):
1165 return True
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_page.py:78, in Page.templatesWithParams(self)
62 """Return templates used on this Page.
63
64 The templates are extracted by :meth:`raw_extracted_templates`,
(...)
74 :rtype: list of (pywikibot.page.Page, list)
75 """
76 # WARNING: may not return all templates used in particularly
77 # intricate cases such as template substitution
---> 78 titles = {t.title() for t in self.templates()}
79 templates = self raw_extracted_templates
80 # backwards-compatibility: convert the dict returned as the second
81 # element into a list in the format used by old scripts
File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1612, in BasePage.templates(self, content)
1609 del self _templates
1611 if not hasattr(self, '_templates'):
-> 1612 self _templates = set(self.itertemplates(content=content))
1614 return list(self._templates)
File /usr/lib/python3.10/_collections_abc.py:330, in Generator.__next__(self)
326 def __next__(self):
327 """Return the next item from the generator.
328 When exhausted, raise StopIteration.
329 """
--> 330 return self.send(None)
File /srv/paws/lib/python3.10/site-packages/pywikibot/tools/collections.py:279, in GeneratorWrapper.send(self, value)
276 if not hasattr(self, '_started_gen'):
277 # start the generator
278 self _started_gen = self generator
--> 279 return next(self._started_gen)
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:625, in QueryGenerator.generator(self)
622 self normalized = {}
624 try:
--> 625 yield from self._extract_results(resultdata)
626 except RuntimeError:
627 break
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:567, in QueryGenerator._extract_results(self, resultdata)
565 """Extract results from resultdata."""
566 for item in resultdata:
--> 567 result = self.result(item)
568 if self _namespaces and not self._check_result_namespace(result):
569 continue
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:736, in PageGenerator.result(self, pagedata)
734 elif ns == Namespace.CATEGORY:
735 p = pywikibot.Category(p)
--> 736 update_page(p, pagedata, self.props)
737 return p
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:983, in update_page(page, pagedict, props)
966 def update_page(page: pywikibot Page,
967 pagedict: dict[str, Any],
968 props: Iterable[str] | None = None) -> None:
969 """
970 Update attributes of Page object *page*, based on query data in *pagedict*.
971
(...)
981 supported yet
982 """
--> 983 _update_pageid(page, pagedict)
984 _update_contentmodel(page, pagedict)
986 props = props or []
File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:882, in _update_pageid(page, pagedict)
880 raise InvalidTitleError(f"{page}: {pagedict['invalidreason']}")
881 if int(pagedict['ns']) < 0:
--> 882 raise UnsupportedPageError(page)
883 raise RuntimeError(f"Page {pagedict['title']} has neither 'pageid'"
884 " nor 'missing' attribute")
UnsupportedPageError: Page en:Special:Log is not supported due to namespace restriction.
— Qwerfjkltalk 19:21, 16 May 2024 (UTC)Reply
Thanks. I've opened phab:T365199 for this and linked here. I'll just catch the exception in that case. Mike Christie (talk - contribs - library) 20:31, 16 May 2024 (UTC)Reply

Big placeholder thumbnails in search results edit

Search results have a thumbnail next to them, or a gray placeholder if there's no suitable image in the article. Since today, those placeholders are bigger than regular thumbnails, which also places them uncomfortably close to the article text. It appears to be caused by this CSS rule:

.searchResultImage .searchResultImage-thumbnail > div { 
  padding: 0.5em;
}

Avessa (talk) 18:29, 16 May 2024 (UTC)Reply

Thank you for reporting. This is a bit of fallout from phab:T320295 and it should be fixed latest next week. —TheDJ (talkcontribs) 18:54, 16 May 2024 (UTC)Reply

Template_talk:Bots#Template:Bots/doc#Important_notes edit

I don't think the talk page will get the comment any light, so I am putting it here. It does not require any discussion but a confirmation from technical person that it won't cause any issue. Thanks, ExclusiveEditor Notify Me! 10:51, 17 May 2024 (UTC)Reply

Nothing you change in a "Template:XXXXXX/doc" page is going to break anything on other pages; worst case is it confuses someones that reads the documentation. — xaosflux Talk 12:49, 17 May 2024 (UTC)Reply

Configuring Git for Gerrit edit

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 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 edit

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

Main Page always full width edit

I Can't edit the Main Talk page so I'm posting here.

The main page (and it's talk page) seems to be stuck in full width mode even when I click on the full width toggle button in the bottom right corner. Other pages seem unaffected.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0

118.3.227.103 (talk) 03:33, 18 May 2024 (UTC)Reply

Not a bug. From Tech news:
In the Vector 2022 skin, main pages will be displayed at full width (like special pages). The goal is to keep the number of characters per line large enough. This is related to the coming changes to typography in Vector 2022. Learn more. [11] – robertsky (talk) 06:00, 18 May 2024 (UTC)Reply

Possible PERM script issue edit

Just cross-posting here, I'm having some issues with one of the PERM scripts; discussion is here. Thanks! Primefac (talk) 07:43, 18 May 2024 (UTC)Reply

Sticky row headers issues edit

Need help fixing the "second" sticky row in this table. With rowspan used in the first column, only the first row in rowgroup is sticky, the rest of the rows in individual rowgroups aren't. I assume it is a "sticky-row2" issue from Template:COVID-19 pandemic data/styles.css. Can it be fixed so it displays all rows in the second column (all rows are sticky) when horizontally scrolling? Qwerty284651 (talk) 19:04, 18 May 2024 (UTC)Reply