Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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

Enhanced editnotice loader

[edit]

I worked on a module that would serve as an enhanced editnotice loader for Wikipedia. See testwiki:Module:Editnotice_load and Module:Editnotice load (which is an exact copy). Features include category editnotices, better group notices, and editnotices by page ID (which would reduce the need to move pages around).

I want to get further feedback on this loader before it inevitably gets implemented. Please check out the testwiki. It should be backwards compatible with the way we do things, but I would like checks for this first.

If this is to be implemented, there will need to be a couple of changes made, including to:

This would make the editnotice loader much more robust.

Immediately, in preparation for this, I would consider adding the following category editnotices templates:

{{BLP editintro}}

{{Disambig editintro}}

Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)[reply]

Some documentation on how it works from a user's perspective would be helpful, in order to understand the context and how it would be used in practice, including how security restrictions are enforced. On a side note, I'm not sure that its deployment is "inevitable". isaacl (talk) 22:03, 9 September 2024 (UTC)[reply]
I have some testcases on testwiki. For best results, view when logged out and inspect the HTML when logged in.
testwiki:Taylor Swift should be a good example of me getting category editnotices working. testwiki:Protected title and testwiki:Protected title2 show the protection editnotice on both the create screen and on the "does not exist" screen when a title is protected from creation for other reasons.
testwiki:Special:EditPage/A should show the page notice from testwiki:Template:Editnotices/PageID/54370 (which is for A). You can also see I renamed previous "page notice"s to "title notice"s because the way page notices are bound to currently are actually to titles, not pages. The new "page notice" will remain bound to a specific page because it uses PageID. There will be no need to update the title notices for pages that exist. On the other hand, for pages that don't exist, the title notice will need to be kept up to date. Awesome Aasim 04:01, 10 September 2024 (UTC)[reply]
I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)[reply]
The editnotices live in the same pseudo-space: Template:Editnotices/. See testwiki:Module:Editnotice load/config.
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. Awesome Aasim 13:16, 10 September 2024 (UTC)[reply]
OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)[reply]
There is less ambiguity in how they are handled. For example, on testwiki:Template:A/B/C/D/E, there are five different group editnotices that can be created. So if there is a page where it is desirable that the group Template:A/B needs one group notice, and Template:A/B/C needs another group notice, and Template:A/B/D needs another group notice, that can now be done; there will be one common group notice and two separate group notices for subpages. Awesome Aasim 19:21, 11 September 2024 (UTC)[reply]
I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories.
Immediately, in preparation for this, I would consider adding the following category editnotices templates this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)[reply]
I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.
Do you have an idea for a Scribunto test runner for Module:Editnotice load to ensure that everything works with demo editnotices? Awesome Aasim 16:53, 13 September 2024 (UTC)[reply]

I haven't noticed any bugs or regressions yet, if someone could take a second look at my code maybe then we will be able to identify potential problems. Awesome Aasim 12:52, 2 October 2024 (UTC)[reply]

I submitted an edit request. I think this is something that could be botted by an admin opening up 8 edit windows and then saving all of the proposed changes at once. I have done this before, it gets annoying when you get rate limited but it is not impossible. Awesome Aasim 20:05, 8 October 2024 (UTC)[reply]

Help Escalating security issue with Webauthn

[edit]
Tracked in Phabricator
Task T358771

With the help of WMF staff we identified a critical issue with webauthn that is likely locking users out of their accounts. The issue prevents webauthn activated on a device from being used on another device, or between browser sessions. This means users can be activating webauthn , intending to secure their account, and end up losing access to wikipedia. Because relatively few users activate this feature in the short term, the issue may not be getting the attention it deserves. It will also discourage future users from activating webauthn, which is a critical security feature to protect the community.

Please help me find the appropriate contact with WMF technical staff to help get the fix merged. It's a one-line fix from upstream repository so it should be low risk. Tonymetz 💬 16:50, 3 October 2024 (UTC)[reply]

I guess that would be us, the Platform Team. I'll raise it with the team and we'll have a look. Matma Rex talk 19:30, 3 October 2024 (UTC)[reply]
Thanks for the note, webauthn has multiple known issues and is certainly in the "experimental" role. As far as our contributors and readers here at the English Wikipedia go: webauthn shouldn't be used by anyone for anything important. Technical reports in phabricator are of course welcome. — xaosflux Talk 00:09, 5 October 2024 (UTC)[reply]
thanks for the context. On the ticket , Reddy mentioned it was completed by a contractor and hasn't been supported. To whom could I appeal to have it turned off? I believe it's locking people out, so it's a liability. Tonymetz 💬 18:00, 7 October 2024 (UTC)[reply]
I think that would also be us. There's already a task: T376021 that lists some problems and suggests turning it off as one possible solution. I think that's currently waiting on some decisions about the new login system (code name "SUL3", see T348388 for some details), which may either let us fix it instead of disabling it, or force us to disable it, depending on which approach we end up going with. Matma Rex talk 01:10, 10 October 2024 (UTC)[reply]
thanks for sharing the context and I'm glad to hear that the concern is being addressed. Thanks again for the updates on that. Tonymetz 💬 02:58, 11 October 2024 (UTC)[reply]

I dislike the visual changes to Mobile Wikipedia

[edit]

I havent used the community pool before so Im sorry if this isnt in the right village. mobile wikipedia starting today as for some reason started auto directing me to en.m.wikipedia.org instead of the regular en.wikipedia.org. even if i directly remove the ".m" or "m.", it will just autodirect to it again. I really hate it, and find it unbearable to use and love the regular english language wikipedia much more. I dont know what is causing this problem. I havent seen anyone discussing this on either the wikipedia subreddit (where usually any updates are discussed) or on Wikipedia:News. I greatly appreciate any help with this, thank you! 92.236.211.53 (talk) 13:55, 4 October 2024 (UTC)[reply]

Use the "Desktop" link at the bottom of mobile pages to request the desktop version. PrimeHunter (talk) 14:00, 4 October 2024 (UTC)[reply]
Thank you for your quick response! I already tried this and it unfortunately results in it providing the literal desktop version of the website, resulting in large amounts of negative space and awkward text placement next to images due to website trying to work for the horizontal mobile. the site worked perfectly for mobile prior. is this happening on your phone too? 92.236.211.53 (talk) 14:07, 4 October 2024 (UTC)[reply]
im typing from desktop as i also learned today that my phone's ip (this same ip) was caught up in a rangeblock to block a specific user(but is now resolved?). i thought just now that this might be whats causing this but i just made account on mobile and it still autodirects to en.m.wikipedia. i have no idea what to do 92.236.211.53 (talk) 14:28, 4 October 2024 (UTC)[reply]
Device name:Pixel 6a
Model:Pixel 6a
Android version:12
I wish this information perhaps helps in finding out how to reverse this. I sent this from my mobile. 92.236.211.53 (talk) 16:48, 4 October 2024 (UTC)[reply]
The behavior you're experiencing is how it has always worked. The "workaround" Primehunter provided is working how it has always worked. There isn't a way to "fix it". The closest thing you can do is have an account, change the account's skin preference, and then use the "use desktop" link when you are logged in and end up on the mobile website. Perhaps this is sufficient for you. Izno (talk) 18:31, 4 October 2024 (UTC)[reply]
I went back through screenshots I took and saw that you and Primehunter were right, it has always been "en.m.wikipedia". I think there's been an update to mobile Wikipedia's base, light colour scheme that caused the add-on I was using, darkreader to render it differently.
I do notice that the text on tables is larger, and colours are in my opinion not working well together either in the official dark mode or using my add-on on light mode.
Current, disliked Wikipedia (lightmode+darkreader) from today: https://imgur.com/a/wnNflgF
Correct Wikipedia, just darkmode with no add-ons, also today:https://imgur.com/a/4xdBsow
Previous mobile Wikipedia colour scheme (lightmode+darkreader), from 28th of April: https://imgur.com/a/up24a8G
Is there anyway to go back to how it was previously because I really do prefer how it was literally just yesterday? I'm sincerely sorry for the misunderstandings 92.236.211.53 (talk) 19:33, 4 October 2024 (UTC)[reply]
What specifically do you dislike about the "current" version? Izno (talk) 00:09, 5 October 2024 (UTC)[reply]
There is a higher contrast between the letters and the dark background, the purple that lists clicked-on links is a lighter purple so you have to strain your eyes more to discern it, the text on tables is larger than it needs to be while the text on the rest of the articles is currently still at their previous very good and readable size (shown in the imgur comparison linked above), and I dont get how that happened.
I dont know how else to describe it, but it looks like there is a white or blue filter over the articles that makes my eyes hurt. I can make another imgur comparison if that would help explain what im reffering to (just two image links this time tho). 92.236.211.53 (talk) 15:35, 6 October 2024 (UTC)[reply]
If you create an account or add ?useskin=timeless, then the desktop version is more mobile friendly a bit. Gryllida (talk, e-mail) 07:29, 7 October 2024 (UTC)[reply]
Ive made an account and it hasn't reverted the UI to how it previously was sorry.
?useskin=timeless is working very well thank you. It's a hassle to paste it to the URL for each new article I click on since it resets to the awful default on every new link or page loaded or when the editl is opened. Is there anyway to make it the default, since it will also be bad for when I'm reading with mobile data, having to load the site twice. Thank you very much regardless! 92.236.211.53 (talk) 20:11, 9 October 2024 (UTC)[reply]
Yes. You can make it the default by creating an account, logging in with it, then going to your Preferences, and under "Appearance" select the Timeless skin, then Save. But that's what Izno told you five days ago. — JohnFromPinckney (talk / edits) 21:03, 9 October 2024 (UTC)[reply]
Sorry for the late reply. I've logged into this account and and selected timeless in appearance but despite that it's still not automatically going through! Also. I apologize to inzo, I don't think I understood what they are saying then. AssanEcho (talk) 20:37, 12 October 2024 (UTC)[reply]

Sticky table headers placement issue for short/nested tables

[edit]

It looks like someone tweaked the CSS for the sticky table headers — which can be enabled with the fourth checkbox at Special:Preferences#mw-htmlform-gadget-section-test — so that (if your browser also satisfies a @media screen and (min-width: 1000px) media query) it applies a top: 3.125rem offset to table headers when one is stickied, to prevent the sticky header from either covering or sliding under the also-sticky TOC button.

Nice idea, in theory. Problem is, on pages containing nested and/or short tables that don't exceed the height of the screen, the stickiness can kick in at unexpected times, particularly when there are multiple tables. And when that happens, all of the tables' headers jump down a distance of 3.125rem, potentially covering their first data row.

I first noticed this at Module:Sports results, in the documentation. The "What it looks like" areas of those docs all contain short tables. If you have the sticky headers gadget enabled, then no matter where you scroll on that page, each table's header row will be shoved down to cover the first data row below it.

That's a problem, as it obscures content, and the only way to make it visible is to defeat the CSS rule applying top: 3.125rem. FeRDNYC (talk) 16:16, 8 October 2024 (UTC)[reply]

Actually, it looks like this only affects nested tables, and it may be sufficient to augment the existing CSS rule: 
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header > thead {
    top: 3.125rem;
  }
}
with a second one overriding the offset in nested tables:
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .jquery-tablesorter > thead {
    top: 0;
  }
}
FeRDNYC (talk) 16:57, 8 October 2024 (UTC)[reply]
...Smaller issue, the nested table headings then end up passing on top of the sticky outer table headers when they cross, instead of underneath them. Looks like some z-index tweaking might also be needed. FeRDNYC (talk) 17:01, 8 October 2024 (UTC)[reply]
Ohh, now I see. The offset isn't to avoid the floating TOC button, but rather the full-width version of the .vector-sticky-header. But the weird thing is, that CSS doesn't kick in until @media screen and (min-width: 1120px), so there's this weird 120px limbo range of browser widths where the table headings are ducking under nothing at all. FeRDNYC (talk) 22:53, 8 October 2024 (UTC)[reply]
Those values change sometimes. I'll make an edit request. —TheDJ (talk • contribs) 08:16, 9 October 2024 (UTC)[reply]
@TheDJ Nice, thanks!
The nested table issue is still a problem, though, whether the breakpoints are synced up or not. When a table's sticky-header activates and the top: 3.125rem; offset kicks in for its header rows, the header rows of all tables nested inside that table will also move down to obscure their own content, unless the offset is defeated for nested tables with something like my second CSS block above. FeRDNYC (talk) 09:18, 9 October 2024 (UTC)[reply]
Yes, this is almost impossible to bypass. Sticky headers are relative to their scrolling context. So every time you introduce a new scrolling context (as done here at Module:Sports_results#L-277), you have to cancel out the offset of the main context. This is part of the reason why the sticky headers are not the default behavior. It is not really possible to make it work predictably in any and all contexts right now. If you want to override this specific situation, you need to make an override for this gadget's behavior in Module:Sports_results/styles.css. —TheDJ (talk • contribs) 11:11, 9 October 2024 (UTC)[reply]
@FeRDNYC: The offset isn't a problem with the change request at MediaWiki talk:Gadget-StickyTableHeaders.css#Interface-protected edit request on 10 September 2024, which adjusts "top" to 0 if the table is wrapped in an "overflow" style. Basically nothing is sticky at Module:Sports results/doc, which is better than unreadable content. Jroberson108 (talk) 05:55, 11 October 2024 (UTC)[reply]

Keep getting logged out

[edit]
Tracked in Phabricator
Task T372702

Over the past few weeks I've been occasionally getting logged out unexpectedly, despite ticking the "remember me" option every time. Most recently it's happened twice in the past ~24 hours. It always happens when I've been idle for a while, but only on the order of hours not days. I'm not aware that I've changed any of my settings recently. Thryduulf (talk) 20:15, 8 October 2024 (UTC)[reply]

Me too. I believe there is a phab ticket covering this issue. Let me go find it real quick NightWolf1223 <Howl at me•My hunts> 20:55, 8 October 2024 (UTC)[reply]
I've had the same issue for a week or so, I just rather lazily assumed it would get fixed at some point. -- LCU ActivelyDisinterested «@» °∆t° 21:08, 8 October 2024 (UTC)[reply]
Probably the same problem as T372702. Matma Rex talk 16:16, 9 October 2024 (UTC)[reply]
I don't know if this sequence of actions has a trigger in it.
  1. explicitly log out on one machine (this invalidates all login cookies on all devices)
  2. log in to en.wp on a different device, selecting "Keep me logged in (for up to one year)". I now have a fresh new login cookie
  3. Microsoft informs me that updates require installation, so I finish what I am doing ...
  4. ... close Firefox, go for "Start"→"Power"→"Update and restart", wait an age. Make coffee. Clear a pile of snailmail. Open Firefox ...
  5. ... and back to my watchlist. One edit adds an image to an article, which I am suspicious about, so:
  6. visit Commons. It says I am not logged in and should reload the page. In my experience, this never works, but following a different commons link does; so I go to the page history. I am now shown as logged in.
  7. Still on Commons, I follow a link to en.wp - I am not logged in
  8. Return to commons, visit another page, still logged in
  9. go to Meta - I am logged in there
  10. try en.wp again - not logged in
Why might en.wp stop recognising my login cookie when commons and meta are perfectly happy with it? --Redrose64 🌹 (talk) 20:17, 9 October 2024 (UTC)[reply]
Not getting automatically logged in on some wikis sounds like some sort of anti-tracking protection in your browser. Commons and Meta share the same parent domain with login.wikimedia.org where the central session cookie is stored so browser restrictions on cross-wiki cookie access are more relaxed.
Does clicking on the login link at the top of the page on enwiki help? That should work in Firefox. Tgr (WMF) (talk) 18:26, 10 October 2024 (UTC)[reply]
@Tgr (WMF): I think you missed something - my proper login (asking me to enter name and password) was on English Wikipedia. When I went to Commons and logged in there, I became logged out on Wikipedia, but remained logged in on Commons. --Redrose64 🌹 (talk) 20:16, 10 October 2024 (UTC)[reply]
Yeah the logged out part is the bug Matma Rex linked. I'm just saying Commons and Meta login being more "sticky" on some browsers is expected - your enwiki session somehow went missing, your central session on login.wikimedia.org remained, and then other wikimedia.org wikis can recover the session from there but wikis on other domains can't. Tgr (WMF) (talk) 21:31, 10 October 2024 (UTC)[reply]
OK it's not random but it is replicable:
  1. On en.wp, log in (full login using Special:UserLogin, with Username/Password)
  2. Click this link: commons: - observe that you are logged in
  3. Use the browser's "back" button to return to en.wp
  4. Press F5 to reload the page - observe that you are not logged in
  5. Click this link: commons: - observe that you are still logged in at Commons
This also causes loss of session data and more than one lost edit. --Redrose64 🌹 (talk) 21:54, 10 October 2024 (UTC)[reply]
@Redrose64 I cannot reproduce this behavior. RoySmith (talk) 00:49, 12 October 2024 (UTC)[reply]
@Redrose64 if you are able to reproduce it, would you mind doing it with the WikimediaDebug extension enabled and the "Verbose log" option checked? Tgr (WMF) (talk) 15:59, 13 October 2024 (UTC)[reply]
I'm not sure how this could be connected, but I've noticed recently (a few weeks?) that sometimes when I go back to my watchlist after looking at/editing a linked page, I get an earlier version of the watchlist. I've just assumed it has something to do with caching, as clearing the cache brings up the most recent version of the watchlist. Donald Albury 19:50, 12 October 2024 (UTC)[reply]

Adding section after closed discussions

[edit]

I added a new section using the "*" tab with this edit: https://en.wikipedia.org/w/index.php?title=Talk:Fishing_cat&curid=7607570&diff=1250477244&oldid=1250369650

The new section is included within the closed discussion. I might be able to fix it in this case, but it seems to be a bug.  —  Jts1882 | talk  19:03, 10 October 2024 (UTC)[reply]

It's not really a bug; the person who closed the GA review section forgot to match their {{atop}} template with an {{abot}} template, which means the "close" box didn't end. I've fixed it. Writ Keeper ⚇♔ 19:10, 10 October 2024 (UTC)[reply]
Thank-you. I knew there was a problem but couldn't identify it. It's too easy to cast blame on bugs.  —  Jts1882 | talk  19:18, 10 October 2024 (UTC)[reply]

Problem with {{cite web}}

[edit]

There appears to be a problem with {{cite web}} and related templates on some pages - see, for example, Beroidae, where all the references display "Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value." rather than the reference. The references are displayed correctly in preview mode, with no template errors shown in the editor. I'm using Firefox with the Monobook skin. Tevildo (talk) 22:25, 10 October 2024 (UTC)[reply]

I WP:NULLEDITed the page and the error went away. No idea of the cause. * Pppery * it has begun... 22:35, 10 October 2024 (UTC)[reply]
This is usually caused when the Citation Style 1 module components used by the cite templates are updated and are out of sync for a few moments. Some pages are re-rendered and cached during that short time, and they can throw errors when new code tries to call older code and fails in some way. With so many millions of pages, it is inevitable that at least a few pages will be affected. Null-editing affected articles re-renders them with all of the updated module components. – Jonesey95 (talk) 00:45, 11 October 2024 (UTC)[reply]
Thanks for the answers, I'll try that if I come across this issue again. Tevildo (talk) 15:50, 11 October 2024 (UTC)[reply]

Matching tags in strings?

[edit]

I need to create a series of ref tags from wikitext with refs. I'll settle for a very specific pattern of text removed. I tried things like: {{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}} but the left angle bracket never matches. I think the match is being performed on a source or pattern after it has been converted to Help:strip markers. Thus the angle bracket is not in the source during the match. Is there a way around this? Johnjbarton (talk) 23:15, 10 October 2024 (UTC)[reply]

Because <ref /> tags are replaced with stripmarkers before Module:String ever sees |source=:
{{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}
−4,'"`UNIQ--ref-0000002B-QINU`"' −2,'"`UNIQ--ref-0000002C-QINU`"'
no <ref /> tags to match.
—Trappist the monk (talk) 00:40, 11 October 2024 (UTC)[reply]
Thanks, very helpful. On the plus side the issue I was concerned about, finding my digit-strings like ",9" inside refs, can't actually happen:
{{#invoke:string|replace|source=−4,<ref name="has9">,9</ref> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}
−4,'"`UNIQ--ref-0000002F-QINU`"' −2,'"`UNIQ--ref-00000030-QINU`"'
On the minus side, templates can't manipulate contents of ref tags I guess. Johnjbarton (talk) 01:55, 11 October 2024 (UTC)[reply]

References

  1. ^ a b c d Cite error: The named reference cn was invoked but never defined (see the help page).

Talk:Battle of Helena

[edit]

See Talk:Battle of Helena#In appropriate photo when viewing in app. Any idea what's going on with the issue the IP just reported? There were some image vandalism issues over a year ago. There's no infobox image in the article so I don't know what would be causing that. I am unable to really look into this because I am at work and do not want to replicate the reported issue. Hog Farm Talk 16:29, 11 October 2024 (UTC)[reply]

@Hog Farm the article was vandalized at some point (see the edit summary at Special:Permalink/1163371835) and while the vandalism was removed, it's likely that some resource the app is using didn't update their cache correctly. --Ahecht (TALK
PAGE) 19:53, 11 October 2024 (UTC)[reply]

SuggestBot - is it running?

[edit]

Hi, I submitted a request 20:32, 10 October 2024 (UTC) here, and awaiting a response of suggested articles wikitable. At User talk:SuggestBot I did include @Nettrom, the bot operator. Regards, JoeNMLC (talk) 21:41, 11 October 2024 (UTC)[reply]

It appears not - the recent contribs to User talk pages show that it typically runs twice a day, at 11:24 and 23:24 (UTC), but today's 11:24 run was missed. Have you contacted the botop directly? --Redrose64 🌹 (talk) 21:55, 11 October 2024 (UTC)[reply]
Thanks Redrose64 - I did just now leave a message on Nettrom's talk page. JoeNMLC (talk) 00:10, 12 October 2024 (UTC)[reply]
Well its contribs show that it's making edits (permalink to contributions at time of writing). It seems to be taking its time. At least it's still carrying on the fourth-longest daily editing streak of any user here (I'm at #5 of out of all human editors). Graham87 (talk) 02:44, 12 October 2024 (UTC)[reply]
 Done at 11:26, 12 October 2024 (UTC). Cheers! JoeNMLC (talk) 11:50, 12 October 2024 (UTC)[reply]

Queries

[edit]

Hey, all,

Just a minor query but I hope someone will know. When I use to visit Wikipedia:Arbitration/Requests/Enforcement or WP:ANI, in the top right corner of a discussion, there was a link to "Archive" the discussion. Instead, now, there is a link to "Subscribe". So, is there an easy way to archive discussions other than cutting and pasting them into an archive page? It used to be easy to do this but now I don't see a way to do this. Is it because of a skin or some setting I have opted into or was this a change to discussion format? There also use to be a Reply link on talk page discussions and I no longer see that link either.

Thanks for any explanation anyone can provide. Liz Read! Talk! 06:06, 12 October 2024 (UTC)[reply]

I had this issue recently and I was told to update / use a new user script. Let me hunt that down for you. Ktin (talk) 06:25, 12 October 2024 (UTC)[reply]
See this post Wikipedia:Village_pump_(technical)/Archive_214#User_Scripts_and_Template_Substitution. I ended up using User:Elli/OneClickArchiver and this works for me. Ktin (talk) 06:29, 12 October 2024 (UTC)[reply]
@Liz In User:Liz/common.js you are loading User:Technical 13/Scripts/OneClickArchiver.js on line 36. That particular version of the one click archiver was deleted in 2023 because it was broken and Technical 13 is arbcom blocked and unable to fix it. You'll need to replace it with an alternative, see Wikipedia:One click archiving for a list of maintained versions. 86.23.109.101 (talk) 17:11, 12 October 2024 (UTC)[reply]

Module:Nihongo and Module:Lang

[edit]

Hey there. It looks like Japanese sword is having a Lua error. I am guessing that this may have to do with recent changes to either Module:Lang or Module:Nihongo. I can't edit those anyway, but maybe someone here has the ability and/or the ability to test what is going here. Sumurai8 (talk) 15:34, 13 October 2024 (UTC)[reply]

Yup, something is wrong with Module:Nihongo. Many Nintendo-related articles are affected. Anyone with technical knowledge able to fix this? QuicoleJR (talk) 15:54, 13 October 2024 (UTC)[reply]
Update: Everything is working properly now. Thank you, Trappist the monk, for fixing the module. QuicoleJR (talk) 16:14, 13 October 2024 (UTC)[reply]
I am still seeing this on mobile with Module:Lang. It seems to only affect articles after it was changed to langx. "Lua error in Module:Lang at line 1422: attempt to concatenate a nil value" Mellk (talk) 17:05, 13 October 2024 (UTC)[reply]
WP:NULLEDIT is your friend.
—Trappist the monk (talk) 19:25, 13 October 2024 (UTC)[reply]
Thanks. I suspected it was something to do with the cache. Mellk (talk) 07:13, 15 October 2024 (UTC)[reply]

‘Newcomer Tasks’ got a screw loose? Or is it the user?

[edit]

Wikipedia:Growth Team features didn’t look like the right place to phone this in, so dragging it up here. If what looks like problems with the Newcomer kit, belongs somewhere else, please signpost accordingly.

See this and this. Is this the user making mistakes, or is Newcomer Tasks actually telling them to put refs at the top? MM (Give me info.) (Victories) 15:44, 13 October 2024 (UTC)[reply]

It seems to be just link spam, unrelated to Newcomer Tasks, even though the edits are tagged as such. —⁠andrybak (talk) 15:53, 13 October 2024 (UTC)[reply]
Cpmrev- Jeez, how did I miss that… uw-spam1 it is. Cheers Andry. MM (Give me info.) (Victories) 15:57, 13 October 2024 (UTC)[reply]

I need an advice how to split rows/lines in a wiki-userbox

[edit]

I made a userbox draft

This user tries to reduce Gender bias on Wikipedia.

,

but I want to put a linebreak between "reduce" and "Gender". Anyone knows how to do this? Walter Tau (talk) 17:31, 13 October 2024 (UTC)[reply]

{{line break}}? MM (Give me info.) (Victories) 17:33, 13 October 2024 (UTC)[reply]
Thank you. It worked ! Walter Tau (talk) 17:37, 13 October 2024 (UTC)[reply]
Very good. Enjoy your breaking of many lines. Thumbs up icon MM (Give me info.) (Victories) 17:38, 13 October 2024 (UTC)[reply]
even simpler, just put <br />. — xaosflux Talk 19:21, 13 October 2024 (UTC)[reply]
[edit]

This tool does not work. Is there any analogue? Kaiyr (talk) 18:54, 13 October 2024 (UTC)[reply]

@Kaiyr: Do you mean that you couldn't reach the site? Or that there was a server error? It currently appears to be online. Polygnotus (talk) 13:36, 15 October 2024 (UTC)[reply]
Ah when I click "Do it!" it says Server(ServerError { code: 1054, message: "Unknown column 'lt0.lt__namespace' in 'where clause'", state: "42S22" }).
You should probably report that issue over at https://github.com/magnusmanske/petscan_rs/issues Polygnotus (talk) 13:37, 15 October 2024 (UTC)[reply]

how do I restore the copy-paste function to the edit window? (dvorak keyboard)

[edit]
Tracked in Phabricator
Task T62928

This changed just recently. I first noticed it on Wikt-en, and at the time I had no problem on WP-en, but now it's spread here. It occurs on some other language wikis, like Wikt-ja, but not on Wikt-vi. In the edit window of a WP article or talk page, if I hit control-x I get bold formatting, with control-c I get italic, and with control-v I get superscript. Presumably this has something to do with me using a dvorak keyboard (dvorak x and c correspond to qwerty b and i), but other commands are unaffected. E.g. control-z and -y are still 'undo' and 'redo', despite corresponding to the qwerty keys for t and /. That means that I can't use the keys with qwerty x c v printed on them for cut-copy-paste, because they continue to act as dvorak q j k and either quit the browser or take me to the URL. It doesn't affect normal typing in an edit window, only commands where the 'ctrl' key is used.

This does not happen when I 'respond' to a thread on a talk page, so that a new window opens: Then all keys act as dvorak, both here and on wikt. The skin also does not seem to be the issue. Here I use Monobook, on Wikt I use Vector 2022. I tried Vector legacy on Wikt and the behaviour was the same.

Can I do something with my css to override this behaviour? — kwami (talk) 00:29, 14 October 2024 (UTC)[reply]

The patch that broke it is reverted and going out on the next train on Thursday. phab:T62928 You can turn on syntax highlighting to work around it for now. Izno (talk) 00:47, 14 October 2024 (UTC)[reply]
Thanks!
Syntax highlighter is good fix in the meantime. — kwami (talk) 01:27, 14 October 2024 (UTC)[reply]

Keyboard shortcuts broken for alternative keyboard layouts (macOS, Safari)

[edit]

For the last couple days, when editing an article and press 'Command-V' to Paste, the text below is inserted instead:

<sup>Superscript text</sup>

When I 'Command-C' to Copy, double single quotes are wrapped around the selected text.

''selected text''

Strangely, when editing THIS PAGE the shortcuts are working fine. But If I got to edit an article or talk page in mainspace, they do the above.

NOTE: macOS, Safari. I type using the Dvorak keyboard layout. Dvorak's C is in the same location as QWERTY's I. The italics issue above leads me to believe the shortcuts have been (recently) hardcoded to the QWERTY locations rather than taking the actual key/letter typed.

Does anyone know what could be wrong or have a better venue to raise this?

PK-WIKI (talk) 16:49, 15 October 2024 (UTC)[reply]

See above. — xaosflux Talk 16:51, 15 October 2024 (UTC)[reply]


Cannot request a move

[edit]

I have been unable to request a multiple-page move. It goes like this: I am using Wikipedia on an Xbox console (my computer is out of action at the moment), and attempting to request a multiple-page move does not work. Doing so instead yields a mere reply in the form of bare wikitext. You can find those three trainwrecks (or should it be planewrecks, given the topic?) on Talk:Microsoft Flight Simulator. I attempted to request a move of four pages relating to the series in question, as I had previously done with the first game: Microsoft Flight Simulator 2.0, Microsoft Flight Simulator 3.0, Microsoft Flight Simulator 4.0, and Microsoft Flight Simulator 5.0 in a similar vein to my move of the 1982 game, as in moving them to something like "Microsoft Flight Simulator (19XX video game)".


Can someone request a move for me? Ægc's friendly xbox alt (talk) 08:30, 14 October 2024 (UTC)[reply]

Turn off Visual Editor in all its myriad forms (it may be OK for articles, but it's hopeless on talk pages). Use MediaWiki's own plain text source editor - I use the oldest one that still exists (I think that it's called the 2003 wikitext editor), and have no problems at all. Template transclusions and substitutions do exactly what they're supposed to. Any typos are therefore my own fault. --Redrose64 🌹 (talk) 09:41, 14 October 2024 (UTC)[reply]
@Redrose64 I don't think this is good advice in general, and it's not relevant here, because Æ is not using the visual editor here to edit the talk page, but rather the new topic tool. Matma Rex talk 16:00, 14 October 2024 (UTC)[reply]
@Ægc's friendly xbox alt In the top-right corner of the interface for adding new topics, there are two tabs labelled "Visual" and "Source" – try switching to the "Source" tab before writing the move request. Matma Rex talk 15:58, 14 October 2024 (UTC)[reply]

Preview weirdness

[edit]

Use Navigation pop-ups. Point mouse at Aaron Brennan, an article about a bearded man, with a picture of a bearded man in the infobox, before any other pictures. Be surprised to see, in the pop-up, a picture of an unbearded young lady from several sections down the page. DuncanHill (talk) 11:37, 14 October 2024 (UTC)[reply]

@DuncanHill: And now? Polygnotus (talk) 12:46, 14 October 2024 (UTC)[reply]
@Polygnotus: Works as expected now, thanks. DuncanHill (talk) 23:50, 14 October 2024 (UTC)[reply]
Navigation pop-ups doesn't have access to the result of parsing the wikitext but makes its own primitive analysis of the source text. It can detect file syntax and certain common infobox parameters like image and logo, but apparently not image1. Unlike Page Previews, it can select images outside the lead. PrimeHunter (talk) 14:30, 14 October 2024 (UTC)[reply]
It would only require adding |image1 to this line in MediaWiki:Gadget-popups.js:
			'image|image_(?:file|skyline|name|flag|seal)|cover|badge|logo'
PrimeHunter (talk) 14:39, 14 October 2024 (UTC)[reply]

Standard width of appearance tool does not work properly

[edit]

Hi, "Standard" width of "Appearance tool" does not work properly. It functions the same as "Wide" width. Please inspect. Thanks, Hooman Mallahzadeh (talk) 12:52, 14 October 2024 (UTC)[reply]

I just tested and it works fine. Is your screen wide enough for the wide mode to even kick in ? —TheDJ (talk • contribs) 14:00, 14 October 2024 (UTC)[reply]
@TheDJ Sorry, I zoomed out my browser and the problem resolved. Please close the thread. Thanks. Hooman Mallahzadeh (talk) 14:13, 14 October 2024 (UTC)[reply]
@TheDJ I really propose that we can disable this functionality in the case that zoom of browser is high, and this functionality does not work properly. We can implement that by a few JavaScript codes. Hooman Mallahzadeh (talk) 14:33, 14 October 2024 (UTC)[reply]
[edit]

What is happening at Wikipedia:Administrators' noticeboard/Incidents? Of the last 100 edits 62 are tagged as having added disambiguation links - from random checking, most didn't?
The first edit that has it was this, which did add a disambiguation link (MOS:CONSISTENCY). – 2804:F1...D2:B7E7 (talk) 19:57, 14 October 2024 (UTC)[reply]

MOS:CONSISTENCY is a redirect to the disambiguation page Wikipedia:Consistency. MOS is a namespace here at the English Wikipedia while [[MOS:CONSISTENCY]] at other wikis would have been an interlanguage link to https://mos.wikipedia.org/wiki/CONSISTENCY. Maybe this confuses a piece of software. PrimeHunter (talk) 20:39, 14 October 2024 (UTC)[reply]
I've changed it to bypass the redirect, see if that works. – 2804:F1...D2:B7E7 (talk) 21:02, 14 October 2024 (UTC)[reply]
It worked. Your edit [1] was the last to be tagged, and the page still says [[WP:Consistency|MOS:CONSISTENCY]] many edits later. PrimeHunter (talk) 21:38, 14 October 2024 (UTC)[reply]
So it did. I'm guessing it isn't happening here because you also linked the redirect target ... interesting. – 2804:F1...D2:B7E7 (talk) 21:41, 14 October 2024 (UTC)[reply]
Talk:Redhead (bird) also links MOS:CONSISTENCY and was tagged when it was added.[2] I made two dummy edits without triggering the tag so it seems hard to guess when it will be tagged. PrimeHunter (talk) 01:21, 15 October 2024 (UTC)[reply]
That's true. I also noticed at ANI that it had started tagging every edit, but after the bot archived 5 sections (diff), only every other edit or so was tagged. In that edit the bot removes some :MOS links, which, coincidentally, were made :MOS because a bot thought they were accidental language links.
Seems to be some combination with other unknown factors. – 2804:F1...D2:B7E7 (talk) 01:47, 15 October 2024 (UTC)[reply]
I'm guessing it's a bug in mw:Extension:Disambiguator, since it's what sets the disambiguator-link-added tag. jlwoodwa (talk) 00:42, 15 October 2024 (UTC)[reply]
The relevant function is onLinksUpdateComplete. jlwoodwa (talk) 00:49, 15 October 2024 (UTC)[reply]
(To be precise, I mean a bug either directly in that extension, or in its dependencies.) jlwoodwa (talk) 00:51, 15 October 2024 (UTC)[reply]

Tech News: 2024-42

[edit]

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

  • The Structured Discussion extension (also known as Flow) is starting to be removed. This extension is unmaintained and causes issues. It will be replaced by DiscussionTools, which is used on any regular talk page. A first set of wikis are being contacted. These wikis are invited to stop using Flow, and to move all Flow boards to sub-pages, as archives. At these wikis, a script will move all Flow pages that aren't a sub-page to a sub-page automatically, starting on 22 October 2024. On 28 October 2024, all Flow boards at these wikis will be set in read-only mode. [3][4]
  • WMF's Search Platform team is working on making it easier for readers to perform text searches in their language. A change last week on over 30 languages makes it easier to find words with accents and other diacritics. This applies to both full-text search and to types of advanced search such as the hastemplate and incategory keywords. More technical details (including a few other minor search upgrades) are available. [5]
  • View all 20 community-submitted tasks that were resolved last week. For example, EditCheck was installed at Russian Wikipedia, and fixes were made for some missing user interface styles.

Updates for technical contributors

  • Editors who use the Toolforge tool Earwig's Copyright Violation Detector will now be required to log in with their Wikimedia account before running checks using the "search engine" option. This change is needed to help prevent external bots from misusing the system. Thanks to Chlod for these improvements. [6]
  • Phabricator users can create tickets and add comments on existing tickets via Email again. Sending email to Phabricator has been fixed. [7]
  • Advanced item Some HTML elements in the interface are now wrapped with a <bdi> element, to make our HTML output more aligned with Web standards. More changes like this will be coming in future weeks. This change might break some tools that rely on the previous HTML structure of the interface. Note that relying on the HTML structure of the interface is not recommended and might break at any time. [8]

In depth

  • The latest monthly MediaWiki Product Insights newsletter is available. This edition includes: updates on Wikimedia's authentication system, research to simplify feature development in the MediaWiki platform, updates on Parser Unification and MathML rollout, and more.
  • The latest quarterly Technical Community Newsletter is now available. This edition include: research about improving topic suggestions related to countries, improvements to PHPUnit tests, and more.

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

MediaWiki message delivery 21:17, 14 October 2024 (UTC)[reply]

Mysterious newline

[edit]

At Wikipedia:Contents/Mathematics and logic § Glossaries, there's an unintended newline between Algebraic geometry and Algebraic topology. Looking at the source (Wikipedia:Contents/Glossaries/Mathematics and logic), there's a newline between all the entries, but all of them are ignored on the subpage, and all but the first are ignored when it's transcluded. Inspecting Wikipedia:Contents/Mathematics and logic in my browser, the first entry is outside the <div> that holds all the other entries. (And I've checked that this isn't skin-specific or browser-specific.) I've tried putting <nowiki /> at the start of Wikipedia:Contents/Glossaries/Mathematics and logic, because I vaguely remember a bug like that, but no dice. Does anybody know what's going on here? jlwoodwa (talk) 00:33, 15 October 2024 (UTC)[reply]

I made the list use actual wikitext list formatting like the other sections. It was using bullet characters with line breaks, which may or may not work, as you saw. Does normal formatting work for you? – Jonesey95 (talk) 00:54, 15 October 2024 (UTC)[reply]
Thanks, that did it. No point in debugging something if it's automatically solved by upgrading to semantic list markup. jlwoodwa (talk) 01:11, 15 October 2024 (UTC)[reply]

Newspapers.com

[edit]

I've not been able to log in to Newspapers.com since February because I have free account there linked to my paid Ancestry account. I was told it was very hard to maintain that, for very good reasons. I found it very difficult to edit articles because I depended on Newspapers.com for sources. Now I don't even see it as an option in the Library anymore. Have we totally given up on that? I see Ancestry in the library. Is there some way to access newspapers.com for articles that aren't obituaries? I hope I'm asking this in the right place. Oona Wikiwalker (talk) 01:09, 15 October 2024 (UTC)[reply]

Have you applied for access as instructed here? Nardog (talk) 02:31, 15 October 2024 (UTC)[reply]

Hindustan Times

[edit]

HT sources can no longer be added automatically via ref gadgets like ProveIt and VisualEditor, only manually. Can't this be fixed, the way other websites like The Times of India were? Kailash29792 (talk) 05:20, 15 October 2024 (UTC)[reply]

How can I edit an article in full screen, not a column with preview to the left

[edit]

I want to have to click preview to preview and have the full edit field available. Thanks. Doug Weller talk 12:16, 15 October 2024 (UTC)[reply]

Ignore, figured it out. Doug Weller talk 12:21, 15 October 2024 (UTC)[reply]

Accounts with no visible creation date on their contribs page

[edit]

When I visit the contributions page of a user, it shows their account's creation date at the top. But some, like Dennis Brown and Muboshgu, don't. Why? Avessa (talk) 14:10, 15 October 2024 (UTC)[reply]

Because those users were created before user creation times were being logged. —TheDJ (talk • contribs) 14:20, 15 October 2024 (UTC)[reply]
But your account was created seven months earlier than Muboshgu's (21 April 2005 vs. 22 November 2005), and yet the creation date is visible on your contribs page. Then there are also Bearcat (created on 3 October 2003), BD2412 (20 February 2005), Koavf (5 March 2005), etc, which all were created before Muboshgu's account too, and yet have their creation date visible. Avessa (talk) 15:23, 15 October 2024 (UTC)[reply]
Strange things sometimes occur with logins created before WP:SUL went live in May 2008. --Redrose64 🌹 (talk) 16:18, 15 October 2024 (UTC)[reply]
I think the "creation date" for early accounts is a later guess that was added to the database at some point (I remember that it was not there in the beginning; for me, the date given is the date of my first edit, which is probably correct). The list of users by user ID claims to be "by creation date" but that is clearly incorrect. —Kusma (talk) 16:52, 15 October 2024 (UTC)[reply]
@Kusma: well it is by creation date ... in terms of the current database, which was implemented in January 2002 with the Phase II software. The previous UseModWiki login system was quite different, as described at the Wikipedia FAQ on the Nostalgia Wikipedia. Graham87 (talk) 01:58, 16 October 2024 (UTC)[reply]
The sorting is by actual creation date, not by the date given as "creation date". —Kusma (talk) 08:12, 16 October 2024 (UTC)[reply]
The user_registration column wasn't added until MediaWiki version 1.6, which was released on April 5, 2006. There's a script that backfills the column with each user's first edit, but - as best as I've been able to reconstruct - it apparently hasn't been run on enwiki since at least August 24, 2006. Users who registered before 1.6's deployment but didn't edit until after the last time the update script was run still have empty registration times. —Cryptic 16:52, 15 October 2024 (UTC)[reply]

Infinite JS errors?

[edit]

I happened to disable pop-ups on a WIkipedia page, using some unintended key combination. I now get an infinite number of the following pop-up messages 

 Javascript Error

https://en.wikipedia.org/w/index.php?title=User:Manishearth/orphantabs.js&action=raw&ctype=text/javascript at line 125: Uncaught TypeError: Cannot read properties of null (reading 'document')

Hmm... All the best: Rich Farmbrough 16:40, 15 October 2024 (UTC).[reply]

You can turn off your personal scripts, that one is loading from User:Rich Farmbrough/monobook.js, just comment it out. — xaosflux Talk 16:57, 15 October 2024 (UTC)[reply]

Add buttons to Reply Tool

[edit]

How can I add buttons to the Reply Tool (part of DiscussionTools)? Polygnotus (talk) 17:38, 15 October 2024 (UTC)[reply]

Unable to use the visual editor for a specific article

[edit]

For some reason the visual editor is not working on this article. getting the message "sorry this element can only be edited in source mode for now".

Why might this be the case?

Is this normal or is there a problem that has to be fixed? i was told to try clearing my cache and fit that didn't work to ask here.BruceSchaff (talk) — Preceding undated comment added 20:33, 15 October 2024 (UTC)[reply]

Should be fine now. Someone had added some bold that doesn't work in the way it was added. Izno (talk) 20:48, 15 October 2024 (UTC)[reply]

Template:Wikipedia stats issue

[edit]

The template seems to be having issues with "mos" as a parameter, possibly due to the MOS namespace or related changes. Could someone please take a look at it? In particular, it's used on Wikipedia:List of Wikipedias, and the issue is visible if you uncomment that row of the table. Thanks. Daniel Quinlan (talk) 00:55, 16 October 2024 (UTC)[reply]

It's indeed the MOS namespace which caused problems. I have modified {{Wikipedia stats}} to link the mos wiki as m:mos: which works via a redirect at meta.[9] It's a hack but it works so I have uncommented the mos row.[10] I don't know whether it's possible to make a wikilink which goes directly to the mos wiki. PrimeHunter (talk) 01:42, 16 October 2024 (UTC)[reply]
phab:T363538 included a proposal for a mos-x-deconflict: interwiki, but (judging by how that's a redlink) it doesn't currently exist. Special:Interwiki doesn't show any other prefixes for https://mos.wikipedia.org, so I think m:mos: is the only solution for now. jlwoodwa (talk) 01:59, 16 October 2024 (UTC)[reply]
That was the solution I originally went with (and coded up). The WMF decided to instead embrace the concept of a namespace and an interwiki having the same name, rather than working around it. * Pppery * it has begun... 02:04, 16 October 2024 (UTC)[reply]
Part of that included adding parser functions to explicitly indicate you wanted the interwiki link, but that part hasn't been code reviewed yet. * Pppery * it has begun... 02:05, 16 October 2024 (UTC)[reply]
Thanks! Daniel Quinlan (talk) 02:29, 16 October 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1251465503"