Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

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

Chunked uploads

Tracked in Phabricator
Task T364288

Does English Wikipedia have any way to do chunked uploads the way Commons does, or is there no way to upload a file larger than 100 MB? hinnk (talk) 08:05, 5 May 2024 (UTC)

Maybe, but is there a reason for uploading a large video to English Wikipedia? I don't think that a huge non-free video could ever meet the WP:NFC requirements and a free file would fit on Commons just as well. Or is it a free-only-in-the-US file? Jo-Jo Eumerus (talk) 08:33, 5 May 2024 (UTC)

Only public domain in the U.S. I've been working on silent-era films (including non-U.S. works), but a 100 MB limit on a feature-length video means extremely noticeable artifacts. hinnk (talk) 08:51, 5 May 2024 (UTC)

In that case, the only way to go about this would be by asking for a commons:Help:Server-side upload and specifying in the request that you need it on English Wikipedia. Jo-Jo Eumerus (talk) 09:36, 5 May 2024 (UTC)

Thanks, I opened a request in Phabricator, so hopefully that'll work. hinnk (talk) 06:10, 6 May 2024 (UTC)

What is the task number for tracking? Also note, there is a user script you may want to review: commons:User talk:Rillke/bigChunkedUpload.js. — xaosflux ^Talk 10:48, 7 May 2024 (UTC)

It's T364288. There's more detail attached to the ticket, but I'd tried bigChunkedUpload.js for this file and got an error. hinnk (talk) 23:27, 7 May 2024 (UTC)

The MediaWiki API supports chunked uploads. Whether our File Upload Wizard script makes use of that ability I don't know. Anomie⚔ 11:54, 5 May 2024 (UTC)

An update: chunked uploading does work here, but only for files up to a certain size. This issue is happening because async uploads are only enabled on Commons (and some test wikis). That means that a tool like commons:User:Rillke/bigChunkedUpload.js will fail if the job takes too long. Having tried a few uploads of various sizes, files under ~1GB are fine, files over a few GB always fail, and files ~1GB or more can succeed if async is disabled. There's a Phabricator ticket for enabling async uploads outside of Commons. hinnk (talk) 19:01, 10 May 2024 (UTC)

unwarranted captcha

Tracked in Phabricator
Task T223195

Minor bug upon clicking "Publish changes" button: When I made this edit, I was presented with a captcha because I was allegedly adding an external URL. But the contents of the edit show I did no such thing, nor did I even alter an existing URL. 2605:A601:AAF7:3700:A1D7:26C1:E273:28CF (talk) 21:22, 8 May 2024 (UTC)

This isn't related to the captcha, but your edit set off a filter for 'Possible dead link replacement' which is rather odd: Special:AbuseLog/37687384.

Search for the added_links and removed_links variables.

edit: I mean, the filter isn't what caused the captcha, but the added_links and removed_links variables are what Wikipedia thinks was added and removed, pretty much. – 2804:F1...09:F464 (talk) 22:23, *edited: 22:35, 8 May 2024 (UTC)

Okay, most of that means nothing to me, but either way, triggering one of those filters also seems like a bug. If I can provide any more info to help track it down, lemme know. 2605:A601:AAF7:3700:A1D7:26C1:E273:28CF (talk) 05:56, 9 May 2024 (UTC)

A captcha requirement is based on external links in the expanded wikitext after transcluding all templates and so on. Something may have changed in a template, a module, a Wikidata item, or possibly the parser itself. Maybe something changed in the processing of news: links. The article includes [news://comp.os.vms/ comp.os.vms Usenet group] with two slashes in news://. It produces [removed to avoid captcha problems]. Special:AbuseLog/37687384 says:

All external links added in the edit (added_links)	
[
	0 => 'news:comp.os.vms',
	1 => 'news:%2F'
]

%2F is percent-encoding of a slash. The abuse log also says:

All external links removed in the edit (removed_links)	
[
	0 => 'news:',
	1 => 'news:',
(many similar lines omitted)
	63 => 'news:'
]

PrimeHunter (talk) 09:15, 9 May 2024 (UTC)

I'd never seen these links, so I don't know if stuff like Special:LinkSearch/news://comp.os.vms and Special:LinkSearch/news:comp.os.vms ever worked, but those results don't look right either.

The first one finds 2 results, none matching what was searched, and the other one finds 87 results for news: (which might be what was searched?)

Special:LinkSearch/news:* finds many others, at any rate, and all are also listed as news: – 2804:F1...09:F464 (talk) 11:07, 9 May 2024 (UTC)

@PrimeHunter: Erm.. I think having the link you added after It produces is causing a captcha for every edit. (yep, captcha again) – 2804:F1...09:F464 (talk) 11:12, 9 May 2024 (UTC)

Oh, that sounds like a bug. I only suspected a software change had happened shortly before the article edit. This is worse. PrimeHunter (talk) 11:39, 9 May 2024 (UTC)

Yeah. In the sandbox I added a link to news:invalid_url_for_testing and <this edit> triggered a captcha. – 2804:F1...09:F464 (talk) 11:48, 9 May 2024 (UTC)

This is a known issue; see phab:T223195. Suffusion of Yellow (talk) 17:15, 9 May 2024 (UTC)

Are you saying that the news: links in the article are not valid? Or is this slightly different? – 2804:F14:80B2:ED01:51AB:D790:E65F:54E4 (talk) 21:42, 9 May 2024 (UTC)

Maybe I read too quickly. I saw the word "invalid" and skimmed the rest. If this is happening with valid news: links that's probably a different issue. Suffusion of Yellow (talk) 16:05, 10 May 2024 (UTC)

Indeed, it looks like even valid links are being stored incorrectly in the database, compare [1] and [2]. Suffusion of Yellow (talk) 16:15, 10 May 2024 (UTC)

Broken "pages by quality" assessment template

I'm trying to do some upkeep with many of the neglected articles on Zoroastrianism. When I visit WP:Zoroastrianism (or any other page containing the template), it seems the pages by quality template is broken. Thus, I am unable to review the assessment status of relevant articles. Is this problem on the end of WP 1.0? For what reason would the server would return a broken list? Doughbo (talk) 21:47, 8 May 2024 (UTC)

The list isn't broken, it's empty. User:WP 1.0 bot/Tables/Project/Zoroastrianism hasn't been updated in over three years. I suspect that the WikiProject has been de-subscribed. --Redrose64 🌹 (talk) 15:59, 9 May 2024 (UTC)

Shouldn't it auto-populate with entries that have been project-tagged? eg. Talk:Gatha (Zoroaster). Doughbo (talk) 20:16, 9 May 2024 (UTC)

If you're sure about this, then I think your first step should be to "reactivate" WikiProject Zoroastrianism. As part of that you would update Template:WikiProject Zoroastrianism by changing "inactive" to "main", which would repopulate all the categories, which should make everything work again — Martin (MSGJ · talk) 20:34, 9 May 2024 (UTC)

Thanks. I'm still getting to know things around here, like which actions are appropriate, so I appreciate the help. Doughbo (talk) 15:58, 10 May 2024 (UTC)

Now that you've reactivated the project banner template, the categories are being populated again, so I've undeleted most of the category pages - all except Category:FL-Class Zoroastrianism articles and Category:A-Class Zoroastrianism articles. If these are also required, say so and I'll undelete them too. --Redrose64 🌹 (talk) 18:05, 10 May 2024 (UTC)

Thank you very much! I see that the list is now functioning properly on the template page. On the Assessment page, however, the old, broken list is still present. What is needed in order to replicate the new list? If possible, I'd like to also include a line for unassessed articles. Doughbo (talk) 22:57, 11 May 2024 (UTC)

It's dependent upon a bot run. I left a note at Wikipedia talk:Version 1.0 Editorial Team/Index. --Redrose64 🌹 (talk) 23:44, 11 May 2024 (UTC)

Thank you very much! I think I'm equipped from here on out. I've subscribed to the thread, so I'll check on any updates from there. Doughbo (talk) 21:53, 12 May 2024 (UTC)

special:export

Tracked in Phabricator
Task T364554
Resolved

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

Yes :( T364554 It'll probably be fixed on Monday. Matma Rex talk 09:48, 10 May 2024 (UTC)

Thanks. Resolved today. Christian75 (talk) 21:10, 13 May 2024 (UTC)

Anchor issue with LT/GT symbols (redux)

Tracked in Phabricator
Task T364639
Duplicate

Tracked in Phabricator
Task T170588

So this is not quite the same issue as the last time, but we seem to be having THURSDAY issues with the < symbol in the preloaded edit summary when editing a section. When editing (for example) User talk:Primefac § Test section <1> the edit summary should give /* Test section <1> */ but instead gives /* Test section */. Oddly enough, it shows properly for User talk:Primefac § Test section >2<. This is obviously just a made-up example to prove my point, but it's messing with the anchors at WP:ARC (specifically the "Arbitrator opinion" section). What gives? Primefac (talk) 15:59, 10 May 2024 (UTC)

@Primefac does appear to be a bug, can you point to an edit that was made with that sort of automatic edit summary in the past, where this did work as you expect? — xaosflux ^Talk 16:52, 10 May 2024 (UTC)

I'm not seeing one in your last 2000 edits - just trying to determine if this is something that broke recently (i.e. a THURSDAY thing) or if it is just something that has never worked or been broken for a long time. — xaosflux ^Talk 17:03, 10 May 2024 (UTC)

Special:Diff/1217280393 (4 April) is the last time it worked at ARC; at Special:Diff/1218205257 (10 April) it wasn't. Primefac (talk) 17:04, 10 May 2024 (UTC)

Thank you, updated the bug report; tagged as regression. — xaosflux ^Talk 17:14, 10 May 2024 (UTC)

I'm not sure that it was working on 4 April based on that diff -- from Xaosflux's comment on the task, the summaries appear to work when using DiscussionTools, and that linked diff is tagged as using the ReplyTool. The diff immediately before that one (Special:Diff/1217280353) wasn't made using DiscussionTools, and doesn't include the LT/GT symbols. All the best, ‍—‍a smart kitten_[meow] 17:36, 10 May 2024 (UTC)

Ah OK, so I'm not sure if we have any example of this working properly without DT? — xaosflux ^Talk 17:40, 10 May 2024 (UTC)

Yes... before the last phab ticket was fixed: Special:Diff/1211086114 (29 Feb). Special:Diff/1212114045 (6 March) was supposedly the point when the first issue was fixed. Primefac (talk) 17:41, 10 May 2024 (UTC)

The 6 March diff was using the temporary alternatives to </> («/»), before the previous bug had been fixed. I'm currently Ctrl+F-ing through the history of A/R/C, and so far I'm back to September 2023 with (seemingly) the same issue still present. All the best, ‍—‍a smart kitten_[meow] 17:46, 10 May 2024 (UTC)

(also, the 29 Feb diff was using DiscussionTools) ‍—‍a smart kitten_[meow] 17:50, 10 May 2024 (UTC)

I'm not sure if this has ever worked properly - it looks like the same issue might have existed in 2014. (I didn't scroll any further back in the history than that) ‍—‍a smart kitten_[meow] 18:34, 10 May 2024 (UTC)

"never worked" is a fine answer, and it is still a bug - just not a THURSDAY bug (i.e. we're not looking for a change that someone just recently made that caused it to break). — xaosflux ^Talk 19:14, 10 May 2024 (UTC)

Well, into the memory hole this will go... ticket just got closed as a duplicate of phab:T170588 which has been open since 2017... Primefac (talk) 20:36, 10 May 2024 (UTC)

Rollback issue

I have the preference enabled to have a confirmation prompt when using rollback. The problem is that the confirmation prompt doesn't actually do anything. I'll say "no" to if you wish to use rollback and the rollback will still happen. This has happened three times. Clovermoss🍀 (talk) 19:58, 10 May 2024 (UTC)

I have video of the issue if someone wants to email me for it. Clovermoss🍀 (talk) 20:10, 10 May 2024 (UTC)

Okay so after some trial and error I realized that this probably has to do with my gadget settings having both open a user's contributions after a rollback and confirmation prompts checked, as one notes that it won't work if the other is enabled. From a useability perspective it might be useful to have some sort of popup that doesn't actually let you have both boxes enabled but maybe that's just because I apparently can't follow directions. Clovermoss🍀 (talk) 20:15, 10 May 2024 (UTC)

What Links Here misses links/transclusions wrapped in includeonly

Tracked in Phabricator
Task T7178

I noticed this issue in Wikipedia:Templates for discussion/Log/2024 May 10#Template:Deleted template. In that discussion we used regexes (compare with WLH) to solve the problem but that's really error prone (this was the regex originally proposed in the TfD). Some more testing I did found that this also happens with regular links, not just transclusions. That means the issue affects all XfD venues. Can we get Special:WhatLinksHere to see links/transclusions between WP:INCLUDEONLY tags? If the current behavior is desirable for some reason, can a toggle be provided? Nickps (talk) 20:08, 10 May 2024 (UTC)

And funnily enough, I got the regex wrong while trying to prove that it's easy to get it wrong. Here's another attempt. Nickps (talk) 20:18, 10 May 2024 (UTC)

The current behaviour seems entirely correct to me - If the page "foo" contains either a link or a template wrapped in includeonly tags then the page "foo" does not actually contain that link or template. Only pages that transclude "foo" would have the link or template.

I don't see how this could be changed in the manner you suggest or why such a change would be beneficial - you would need the parser to render wikitext that it has explicitly been told not to render (and hope that doing so produces something sensible rather than a broken mess), then add entries to the linktables for links that don't actually exist. This seems likely to break all manner of things.

Your more complex "correct" regex does not capture every possible way of invoking the template, and doesn't actually capture any uses the simple case missed. You can call templates using all kinds of weird wikitext constructions, e.g. {{Dele{{void}}ted template}}, {{Deleted {{lc:{{NAMESPACE:Template:Cite}}}}}}. 86.23.109.101 (talk) 21:25, 10 May 2024 (UTC)

I believe I made my case for why my proposal is beneficial already. But, I'll elaborate further. When WLH is used in a deletion venue, what people want to know is where the nominated page is used. That includes links/transclusions between includeonly tags because, if the page is deleted, those will be affected too. I bet that 9 out of 10 frequent XfD participants will find the current behavior both surprising and undesirable.

Also, I never argued that my regex was "correct". That's why I called it "an attempt". In any case, you're making my point for me. Since regex won't work in the general case, we need something more powerful. Nickps (talk) 21:59, 10 May 2024 (UTC)

How is "the list of links only shows links that actually exist" and "the list of transclusions only shows places where a page is actually transcluded" surprising and undesirable behaviour? The whole point of includeonly tags is to stop stuff from being parsed when viewed directly.

I think you've missed that this behaviour isn't actually specific to includeonly tags, there are all manner of template coding schemes that can cause a template to call another template only in specific scenarios, the output can depend the parameters you pass it, where it is used, whether it is substituted, what the time is...

The point I was trying (and failing) to make RE regex is that the simplest, naïve approach to finding uses of the template found 6 uses. Your more comprehensive regex found 6 uses. While you can invoke templates using namespaces with arbitrary capitalisation and you can add whitespace and you could make the template name out of wikitext constructions these are rare to see in actual usage and the simple approach is good enough. 86.23.109.101 (talk) 23:47, 10 May 2024 (UTC)

The whole point of includeonly tags is to stop stuff from being parsed when viewed directly and the whole point of using WLH in XfD is to know all the pages that use a specific page in any way. Excluding everything between includeonly tags makes this intuition fail. You said, the simple approach is good enough. But if you read the TfD I linked above you'll see that the "simple approach" and the one tried first was not to use a regex. It was to trust WLH. In that case, no, the simple approach is not good enough. It utterly fails at what it's supposed to do. Nickps (talk) 00:03, 11 May 2024 (UTC)

Also, while most of the constructions I took into account are rare to see in actual usage adding whitespace is not. Nickps (talk) 00:13, 11 May 2024 (UTC)

I don't think we can. The template itself (which effectively excludes the includeonly section) doesn't transclude the page; the text it evaluates to does. It's a specific case of a more general insoluble problem. For example, a template Foo which transcludes [[{{{1}}}]] will, when called as {{Foo|Bar}}, transclude Bar, but as Template:Foo doesn't mention Bar there's no way to list Bar amongst its incoming links. Certes (talk) 21:01, 10 May 2024 (UTC)

But your Template:Foo does not link to Bar at all. It's just that the result of the transclusion of {{Foo|bar}} is a link to Bar. My motivating example is different. {{Expand}} directly links to {{Deleted template}}. The test to tell those two cases apart is simple. Just remove the includeonly tags. If you do that then {{Expand}} will show up in Special:WhatLinksHere/Template:Deleted template but {{Foo}} will not show up in Special:WhatLinksHere/Bar. And that's expected. What's unexpected is that when we add the includeonly tags back, the first link disappears. Why? It's clearly still there. Nickps (talk) 23:45, 10 May 2024 (UTC)

I don't think there is a way to achieve the OP's general request of finding all templates that use a template. If the template is called from inside a conditional if statement or similar, it won't appear in the "What links here" list either. There are no doubt more cases. – Jonesey95 (talk) 23:58, 10 May 2024 (UTC)

And that's wrong too if you ask me. If the link is spelled out in the source code of a given page then it should count for WLH. If we wrap a link in an if statement as in {{#if:{{{1|}}}|[[Foo]]}}, it shouldn't just disappear from the list. Nickps (talk) 00:32, 11 May 2024 (UTC)

Well, it's called "What links here" and the page doesn't link there. I don't know what else to tell you. Searching is necessary in some cases. – Jonesey95 (talk) 03:52, 11 May 2024 (UTC)

If the issue is semantics, then either rename "What links here" or add a "What links here including in noincude tags". At the end of the day, when you search for usages of a template (or any link), you are more than likely interested in all places it is used at, including those places. Gonnym (talk) 08:11, 11 May 2024 (UTC)

Turns out, this is already known since 2006. That issue only talks about categories, but the underlying idea is the same. Nickps (talk) 11:37, 11 May 2024 (UTC)

That phab task has nothing to do with what you are proposing here. That phab task is asking that articles should track where the categories on them are coming from and include that information in the category page, basically just adding metadata to the existing entries.

You are asking for template pages to parse content they have been told not to parse, somehow deal with missing parameters, figure out which templates "could" be used (even though this will vary with the parameters you provide) then add entries to the link tables for links and transclusions that don't actually exist. Certes has already tried to explain this to you once, but it is not possible to figure out an exhaustive list of every template that another template could call, as this depends upon how it is used. As a simple example, a template that contains the code {{cite {{{1}}}}} could end up evaluating to any of the citation templates ({{cite web}} {{cite book}} {{cite news}}) or an infinite number of redlinked template (e.g. {{cite foo}}) depending upon what someone puts into parameter 1. 86.23.109.101 (talk) 13:12, 11 May 2024 (UTC)

Nope, I never said anything about missing parameters. Your example is irrelevant. After all, there's nothing that says that parameters can only appear between includeonly tags. All I'm asking is that if for example, a template contains <includeonly>{{cite web}}</includeonly> then that template should appear in Special:Whatlinkshere/Template:cite web. Nickps (talk) 13:34, 11 May 2024 (UTC)

Let me turn that question back to you. How is {{cite {{{1}}}}} handled outside includeonly? This is a common usecase since not all templates wrap their code in includeonly (because they don't have to) and it works just fine. Why do you think that I ever asked we change that? Nickps (talk) 13:36, 11 May 2024 (UTC)

The data for WhatLinksHere is made when a page is rendered and actual links and transclusions are encountered during the rendering. It doesn't matter which code was used to produce the links. Code in <includeonly>...</includeonly> is ignored during rendering so no links are encountered. Your requested change would require something like a second rendering process where <includeonly>...</includeonly> is not ignored. It would be expensive and I'm pretty sure the developers would reject it as not worth the cost, and probably also as more likely to cause confusion than solve problems. Many users would be confused if WhatLinksHere reports links and transclusions which aren't actually in the page itself but may be in other pages which transclude it. PrimeHunter (talk) 22:26, 11 May 2024 (UTC)

It would be expensive. Per WP:PERF I can say that I don't care about that at all. What I suggest would be useful for XfD and that's all I care about. Now I agree with you that my proposal could potentially be confusing but that's easy to fix, just have the links explicitly marked as includeonly, like the phabricator issue suggests. Alternatively, you can make the feature opt-in so those links only appear for users that know they want them. Nickps (talk) 22:37, 11 May 2024 (UTC)

Thumb version and small version of some images are not shown

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)

None of them are rendering for me. Firefox 125.0.3 --Redrose64 🌹 (talk) 14:03, 11 May 2024 (UTC)

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

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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 (talk • contribs) 09:16, 13 May 2024 (UTC)

It's fixed now. I processed it with the png-fix-IDAT-windowsize utility, to correct the invalid checksum it contained. —TheDJ (talk • contribs) 15:30, 13 May 2024 (UTC)

Can't login to the Wikipedia library

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)

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)

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)

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

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)

Thanks. Looks like there are other problems as well. Doug Weller talk 02:46, 12 May 2024 (UTC)

cc @Samwalton9 (WMF). –Novem Linguae (talk) 17:00, 13 May 2024 (UTC)

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

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)

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

Can anyone think/suggest how to reliably archive a docx document from a website?

I want to archive https://dam.gettyimages.com/viewer/universal/rc3x9h8n56vqfxvhx7fjs which is a production notes/press document for the 2024 film Abigail since if I can't back it up it's just at very likely risk of Link Rot since they don't host these forever.

I tried webarchive but all it saves is the frame, not the content (https://web.archive.org/web/20240511101050/https://dam.gettyimages.com/viewer/universal/rc3x9h8n56vqfxvhx7fjs) and archive.today which does save the doc but only the first couple of pages (https://archive.ph/R8LNy), and finding the direct link to the document here didn't have any further success. Anyone know of any options that will work on reliable long term archive sites? Thanks Darkwarriorblake (talk) 10:35, 11 May 2024 (UTC)

Archived at this link. -- LCU ActivelyDisinterested «@» °∆t° 20:18, 11 May 2024 (UTC)

That's amazing, thanks ActivelyDisinterested, what was I missing? You archived the download link instead? Darkwarriorblake (talk) 21:09, 11 May 2024 (UTC)

Archived the download load link, that's just a redirect but archive.org saves the redirect destination as well. Find where the reditect went and you have your archive link. -- LCU ActivelyDisinterested «@» °∆t° 23:15, 11 May 2024 (UTC)

Migrating SQL data from one toolforge db to another

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)

• As far as I know, most Toolforge tools' databases are still on the same server. But probably neither tool's database user has read access to the other's. You might try asking for help via one of the channels listed at wikitech:Help:Cloud Services communication. Anomie⚔ 13:33, 11 May 2024 (UTC)

  I will try that; thanks. Mike Christie (talk - contribs - library) 19:09, 11 May 2024 (UTC)

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)

ListeriaBot

I have written a SPARQL query that works perfectly on Wikidata query service but ListeriaBot seems unable to execute it and generate a table from it unless I delete the big optional clause. Please see here the template syntax and a link to the query on WDQS where you can run and verify the results (see the Query here too. I just wanted to test the water here and see if someone have had a similar experience before I contact the bot operator who might have their hands full. Assem Khidhr (talk) 04:06, 12 May 2024 (UTC)

Very long response times

I'm experiencing very long response times currently. Anyone else? Nurg (talk) 09:18, 12 May 2024 (UTC)

Me too. --Redrose64 🌹 (talk) 09:19, 12 May 2024 (UTC)

I got maintenance message. Grabup (talk) 09:20, 12 May 2024 (UTC)

seems there was a bit of a spike, but things returned to normal. https://www.wikimediastatus.net —TheDJ (talk • contribs) 09:49, 12 May 2024 (UTC)

AFD signature needs correction

I edited Wikipedia:Articles for deletion/Cloverland, Washington prior to its closure, but probably didn't get something on the correct line. When it closed, it didn't show up at my AFC stats page. I think I erred on where I signed. Tried to correct it after it closed, with no luck. Other than that, it looks like others have also edited the closed template, and possibly re-opened it. I think others need to have a look at the status of this AFD. Thanks. — Maile (talk) 17:45, 12 May 2024 (UTC)

The AFD is still open. The "closure" was by a sock forging another user's signature. Suffusion of Yellow (talk) 17:58, 12 May 2024 (UTC)

Thanks — Maile (talk) 21:04, 12 May 2024 (UTC)

Suffusion of Yellow There's still an odd glitch. Normally, when I edit an open AFD, it shows up almost immediately on my AfD Statistics for User:Maile66, but it's still not showing up. Any ideas on what I did wrong? — Maile (talk) 21:20, 12 May 2024 (UTC)

I got it, finally! It didn't like where I put my signature, or something like that. It works now. — Maile (talk) 21:38, 12 May 2024 (UTC)

Force collapse navboxes

Is there any script or piece of CSS to collapse all navboxes? -- LCU ActivelyDisinterested «@» °∆t° 18:58, 12 May 2024 (UTC)

User:SD0001/AllCollapseToggle.js. It places a "Collapse all" / "Uncollapse all" button under the Tools menu. – SD0001 (talk) 05:17, 13 May 2024 (UTC)

Doesn't that already exist in core? Nardog (talk) 05:23, 13 May 2024 (UTC)

Thanks SD0001, much appreciated. -- LCU ActivelyDisinterested «@» °∆t° 09:38, 13 May 2024 (UTC)

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

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)

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)

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)

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)

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)

Panoviewer.toolforge.org is down

Moved from Template talk:PanoViewer § Panoviewer.toolforge.org is down

 – Sdkb ^talk 15:18, 13 May 2024 (UTC)

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

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)

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)

Typing, but text appears a few lines below my cursor

Tracked in Phabricator
Task T365008

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)

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)

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

Tech News: 2024-20

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

• On Wikisource there is a special page listing pages of works without corresponding scan images. Now you can use the new magic word __EXPECTWITHOUTSCANS__ to exclude certain pages (list of editions or translations of works) from that list. [3]
• If you use the user-preference "Show preview without reloading the page", then the template-page feature "Preview page with this template (what's this?)" will now also work without reloading the page. [4]
• Kartographer maps can now specify an alternative text via the alt= attribute. This is identical in usage to the alt= attribute in the image and gallery syntax. An exception for this feature is wikis like Wikivoyage where the miniature maps are interactive. [5]
• The old Guided Tour for the "New Filters for Edit Review" feature has been removed. It was created in 2017 to show people with older accounts how the interface had changed, and has now been seen by most of the intended people. [6]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 May. It will be on non-Wikipedia wikis and some Wikipedias from 15 May. It will be on all wikis from 16 May (calendar). [7][8]
• The Special:Search results page will now use CSS flex attributes, for better accessibility, instead of a table. If you have a gadget or script that adjusts search results, you should update your script to the new HTML structure. [9]

Future changes

• 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. [10]
• Two columns of the pagelinks database table (pl_namespace and pl_title) are being dropped soon. Users must use two columns of the new linktarget table instead (lt_namespace and lt_title). In your existing SQL queries:
  1. Replace JOIN pagelinks with JOIN linktarget and pl_ with lt_ in the ON statement
  2. Below that add JOIN pagelinks ON lt_id = pl_target_id
  • See phab:T222224 for technical reasoning. [11][12]

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

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

CORS auth

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)

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)

Works like a charm, thank you! Strainu (talk) 09:53, 14 May 2024 (UTC)

Resolved

–Novem Linguae (talk) 08:05, 15 May 2024 (UTC)

Problem in map?

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)

 Fixed – Jonesey95 (talk) 13:31, 14 May 2024 (UTC)

Anchoring new sections to set location on talk page

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)

There is not. I doubt this is something that will be added. Izno (talk) 02:25, 15 May 2024 (UTC)

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)

IP Information tool

Tracked in Phabricator
Task T363118

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

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

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

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

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

Dark mode is available in Vector 2022 as a beta feature

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

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

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

Known limitations

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

What we would like you to do

Our request to you is exactly the same as previously:

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

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

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

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

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

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

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

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

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

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

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

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

'Undo' button now says 'cin gbere le'

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)

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

  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)

  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)