Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
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.
Question re: desktop vs mobile
When accessing Wikipedia (WP) on a smartphone, but via that device's own internet browser (and not via the WP app), WP always opens up in "mobile view", and I then need to switch it to "desktop mode" (my personal preference), and sometimes this needs to be done repeatedly.
And speaking of "preferences" and using the search function on the "Preferences" page, I used "desktop" as a keyword for a search, but I only found one entry, that was under:
"Gadgets"
"Testing and development"
□ "Mobile sidebar preview: show page in mobile view while browsing the desktop site (Vector skin only)"
So, with all that said, my question is: is there any setting in the my account preferences (or by any other means) that can be used to make it so that when I access WP, via a smartphone's browser, the default can be set to "desktop mode" instead of "mobile view"...? Thanks & Cheers - wolf 04:31, 16 March 2023 (UTC)
- See this thread from a couple of weeks ago. – Jonesey95 (talk) 04:59, 16 March 2023 (UTC)
- OK, Cool. Thanks for the quick reply. (just a note: the colors here were just a demonstration, they weren't meant to be "accessible" or in anyway useable.) Anyway, I have a common.js page already, so if I copy the script from User:Þjarkur/NeverUseMobileVersion.js. over to my common.js page, will that do it? (ie; is that all I need to do? will it work?) Thanks - wolf 05:21, 16 March 2023 (UTC)
- See User:Þjarkur/NeverUseMobileVersion. Nardog (talk) 06:05, 16 March 2023 (UTC)
- Yes, I saw that in the last reply and even noted it in my response, where I had a question about Þjarkur's script. (btw- any idea if that's a yes or no on that?) Thanks - wolf 03:00, 17 March 2023 (UTC)
- @Thewolfchild: No, User:Þjarkur/NeverUseMobileVersion is the documentation page for the script User:Þjarkur/NeverUseMobileVersion.js, and it says:
Add this to the top of your common.js file:
. Nardog (talk) 14:01, 19 March 2023 (UTC)mw.loader.load( "https://en.wikipedia.org/w/index.php?title=User:%C3%9Ejarkur/NeverUseMobileVersion.js&action=raw&ctype=text/javascript" );
- @Nardog: See comment at bottom, after the
" Resolved" tag. - wolf 14:12, 19 March 2023 (UTC)- I did. And I'm telling you that's not how you're supposed to install a user script. Your method happens to work for the script in question as it does not use ES6 syntax (which the linter for common.js rejects), and is marked CC0 so there's no license problem, but be sure to find the documentation and follow its instructions next time you come across a script you want to install. Nardog (talk) 14:22, 19 March 2023 (UTC)
- Hey, I asked and didn't get a reply, so I went to the instruction page and followed it, with the exception of putting it at THE TOP as there was already another script. It was either gonna work or not. If not, I would try something else. But it did work, so... I think we're done here, right? Thank you, and have a nice day - wolf 14:39, 19 March 2023 (UTC)
- I did. And I'm telling you that's not how you're supposed to install a user script. Your method happens to work for the script in question as it does not use ES6 syntax (which the linter for common.js rejects), and is marked CC0 so there's no license problem, but be sure to find the documentation and follow its instructions next time you come across a script you want to install. Nardog (talk) 14:22, 19 March 2023 (UTC)
- @Nardog: See comment at bottom, after the
- @Thewolfchild: No, User:Þjarkur/NeverUseMobileVersion is the documentation page for the script User:Þjarkur/NeverUseMobileVersion.js, and it says:
- Yes, I saw that in the last reply and even noted it in my response, where I had a question about Þjarkur's script. (btw- any idea if that's a yes or no on that?) Thanks - wolf 03:00, 17 March 2023 (UTC)
- See User:Þjarkur/NeverUseMobileVersion. Nardog (talk) 06:05, 16 March 2023 (UTC)
- OK, Cool. Thanks for the quick reply. (just a note: the colors here were just a demonstration, they weren't meant to be "accessible" or in anyway useable.) Anyway, I have a common.js page already, so if I copy the script from User:Þjarkur/NeverUseMobileVersion.js. over to my common.js page, will that do it? (ie; is that all I need to do? will it work?) Thanks - wolf 05:21, 16 March 2023 (UTC)
Nm, I copy&pasted the script onto my own page, then dumped my cache, and it seems to do just what it's supposed to so far. So thanks to Þjarkur and Jonesey. - wolf 07:08, 18 March 2023 (UTC)
Talk page archive bots
For many years now one of my more gnomish tasks when I come across talkpage posts that have no sig and timestamp has been to search the page history and find the lost sig. That's because archive bots need that in order to archive the posts. Otherwise the posts just sit there cluttering up the talkpage. I checked this page's archive to see if this had been discussed before, but I couldn't find anything. So is there maybe something in the works that will upgrade a bot's ability to sense an old talkpage post that does not rely on a post's timestamp? Maybe something that senses the times from the history page(s) rather than from the talkpage itself? Such an upgrade, to be useful, would require the bot to add the lost sig to the post and then archive the post. That would cover the everyday work; there would also be the one-time cleanup of the talkpages that have existing old posts that need timestamps and to be archived. Is this a doable? P.I. Ellsworth , ed. put'er there 12:56, 16 March 2023 (UTC)
- I think technically sinebot is supposed to add missing signatures, but only for new comments. ― Blaze WolfTalkBlaze Wolf#6545 13:16, 16 March 2023 (UTC)
- Thank you for that, BW! For some reason, even some new sigs get missed, and I come across old ones every now and then. Most recent were two posts at Module talk:College color. At this present moment, the two sections are § Some incorrect colors, and other thoughts and § Request, both from late 2021; they'll probably be archived in the next day or so. Brings to mind the related issue as to whether the bot archives the old posts chronologically, or does it just tack 'em onto the latest, youngest archive pages? Odd I've not checked that before, but I'll check it this time. P.I. Ellsworth , ed. put'er there 13:44, 16 March 2023 (UTC)
- Ya I've noticed that Sinebot will sometimes ignore unsigned comments even if it isn't in a category indicating comments should be automatically signed. I have no clue why, it's just how the bot works. ― Blaze WolfTalkBlaze Wolf#6545 13:47, 16 March 2023 (UTC)
- Also, the bot will just add them on to the most recent archive, regardless of how old they are. ― Blaze WolfTalkBlaze Wolf#6545 14:53, 16 March 2023 (UTC)
- Suspected as much. Thanks again, Wolfie !>) P.I. Ellsworth , ed. put'er there 15:03, 16 March 2023 (UTC)
- Not necessarily. If the page is archived by ClueBot III and the by year and numbered format is used, or the page is archived by lowercase sigmabot III and the date-based archives format is used, the bot will place threads into different archives according to the most recent timestamp in the thread. Examples for ClueBot III and for lowercase sigmabot III. Thus, unless incremental archives are used (which is most cases), threads signed years late can still go to an archive that is reasonably appropriate for the time period. --Redrose64 🌹 (talk) 18:13, 16 March 2023 (UTC)
- Yes, thank you Redrose64! Suspected that, too, that there was some way for the bot to sense and sort by date. P.I. Ellsworth , ed. put'er there 21:37, 16 March 2023 (UTC)
- Not necessarily. If the page is archived by ClueBot III and the by year and numbered format is used, or the page is archived by lowercase sigmabot III and the date-based archives format is used, the bot will place threads into different archives according to the most recent timestamp in the thread. Examples for ClueBot III and for lowercase sigmabot III. Thus, unless incremental archives are used (which is most cases), threads signed years late can still go to an archive that is reasonably appropriate for the time period. --Redrose64 🌹 (talk) 18:13, 16 March 2023 (UTC)
- Suspected as much. Thanks again, Wolfie !>) P.I. Ellsworth , ed. put'er there 15:03, 16 March 2023 (UTC)
- Thank you for that, BW! For some reason, even some new sigs get missed, and I come across old ones every now and then. Most recent were two posts at Module talk:College color. At this present moment, the two sections are § Some incorrect colors, and other thoughts and § Request, both from late 2021; they'll probably be archived in the next day or so. Brings to mind the related issue as to whether the bot archives the old posts chronologically, or does it just tack 'em onto the latest, youngest archive pages? Odd I've not checked that before, but I'll check it this time. P.I. Ellsworth , ed. put'er there 13:44, 16 March 2023 (UTC)
- Hello, Paine. I often do the same thing, and I would say that, when I am editing such a page, about 30% to 40% of the time the sections are in some weird (not oldest at the top) order. So I'm signing and rearranging as I trawl through the history. I doubt a bot would do well with the rearranging, and I'm thinking placement could hinder its effectiveness with the simple signing task. — JohnFromPinckney (talk / edits) 14:39, 16 March 2023 (UTC)
- Hello, John. Suspect it's alllll in the programmin', and have seen the devs do some pretty amaaaazin' things over the years! Nice to know there are others doin' some trawling for sigless editors; thank you for that! P.I. Ellsworth , ed. put'er there 14:51, 16 March 2023 (UTC)
- Given the popularity of DiscussionTools (=Reply tool and its friends), we should see fewer of these than we used to. Whatamidoing (WMF) (talk) 21:17, 16 March 2023 (UTC)
- And here I thought it was all because of my awesome, years-long effort!>) P.I. Ellsworth , ed. put'er there 21:33, 16 March 2023 (UTC)
- I hope you will have half as much of that work to do in the future.
;-)
Whatamidoing (WMF) (talk) 02:17, 20 March 2023 (UTC)
- I hope you will have half as much of that work to do in the future.
- Yeah I do a lot of this gnoming work too. Unlike lowercase sigmabot III, ClueBot III uses the revision history rather than signatures to determine when a post was made and SineBot doesn't usually sign posts when a user has more than 800 edits (but, as noted above, it can randomly fail for all sorts of reasons). Graham87 00:50, 17 March 2023 (UTC)
- And here I thought it was all because of my awesome, years-long effort!>) P.I. Ellsworth , ed. put'er there 21:33, 16 March 2023 (UTC)
Going forward
Guess it all boils down to how important is it to have talkpage archives in chronological order(?). We see above that, under certain circumstances, both ClueBot III and Lowercase sigmabot III are able to sort talkpage sections to the correctly dated order when archiving. ClueBot III, run by editor Cobi, and σbot III, which uses MiszaBot/config and is run by editor Σ, are both already able to sense history-page entries and to archive talk sections to their correctly dated positions in an archive.
There are some talkpages that are not configured that way and are clogged with old, untimestamped sections. Is this issue important enough to see if the widely used MiszaBot/config can be altered so that it will be able to capture those old, untimestamped sections, give them a proper {{subst:Unsigned}} (or {{subst:Unsigned IP}}) sig, and archive them in chronological order? In other words, I don't mind doing the gnome work; however, if there is a not-too-difficult way for the bots to do it automatically, would that not be an improvement? P.I. Ellsworth , ed. put'er there 09:49, 18 March 2023 (UTC)
Suppose it should be disclosed here that when I look into the page history, find the editor who posted without signing, and add that sig to the post, I then sit and wait for the bot to do the rest. And that means tacking the post onto the end of the latest archive page. If the config can be set to do at least that much, in other words, if the dated order is not all that important, and the bot could do what I've been doing, even that would be a pretty good improvement, eh? P.I. Ellsworth , ed. put'er there 10:22, 18 March 2023 (UTC)
σbot III, ... already able to sense history-page entries and to archive talk sections to their correctly dated positions in an archive
- I really don't think that it can, laat time that I checked it went purely by the latest timestamp in the thread. Can you point to any cases where a truly undated thread was archived by lowercase sigmabot III? --Redrose64 🌹 (talk) 12:37, 18 March 2023 (UTC)- Guess I misunderstood you on that. So σbot III must always have a timestamp in the talkpage post to archive the post. And if ClueBot III can use history-page date entries rather than talkpage date entries, then perhaps σbot III can be programmed to do that, too? P.I. Ellsworth , ed. put'er there 12:53, 18 March 2023 (UTC)
- I was under the impression that archiving bots would already automatically pick up a section to be archived once a date is added to the end of the last post in the section, and the archiving criteria were met, tacking it onto the end of the latest archive page.
- I don't want to discourage brainstorming improvements, because of course interested bot operators may take them as inspiration to introduce new features. Just a word of caution to temper expectations, though: bots can do whatever you can describe in a very precise, algorithmic manner (covering corner cases is the tricky part); it's just a question of how much computing resources and time will it use. At a minimum, the bot has to be able to finish its work fast enough to keep up with the incoming rate of new work. ClueBot III, for example, breaks when encountering pages with a lot of updates, so high-traffic pages don't use it (if I recall correctly, it stops its run and so further pages aren't processed). (ClueBot III tries to fix links to content that has been archived, which may be the cause of the issue.) Figuring out the right archive to use for sequentially-numbered archives (as opposed to date-based ones) means scanning them all, figuring out what date to assign to each section, deciding what page is the best fit, and then where in the page is the best location. It's all doable, but I'm not surprised if archiving bot operators decide that the cost-benefit tradeoff isn't in favour of implementation, and are wary of the ability of the bot to keep up if a lot of people choose this option. isaacl (talk) 17:13, 18 March 2023 (UTC)
- @Isaacl: Yes, archiving bots do
automatically pick up a section to be archived once a date is added to the end of the last post in the section, and the archiving criteria were met
, but they only tackit onto the end of the latest archive page
if incremental archives are in use, see my post of 18:13, 16 March 2023 (UTC). But the point of this thread concerns talk page threads without any valid timestamps - some have no timestamp at all, in others the timestamps are all in an invalid format. The former may be due to forgetfulness or newbie's inexperience, but the latter are normally due to very old threads dating from the period when timestamp formats were not consistent - see Wikipedia:Village pump (technical)/Archive A for some examples of variant formats. --Redrose64 🌹 (talk) 17:48, 18 March 2023 (UTC)- I was responding to the last comment from Paine Ellsworth, where they asked if the bot could archive a post after they added the date, even if the bot just added the post to the most recent archive. isaacl (talk) 19:52, 18 March 2023 (UTC)
- It doesn't matter when or how a timestamp was added, or even who added it: if the most recent valid timestamp in a given thread is earlier than the date threshold for archiving that page, the bot will archive the thread (subject to the other archiving criteria - minimum threads to archive, minimum threads to leave behind, etc.). --Redrose64 🌹 (talk) 20:09, 18 March 2023 (UTC)
- I was responding to the last comment from Paine Ellsworth, where they asked if the bot could archive a post after they added the date, even if the bot just added the post to the most recent archive. isaacl (talk) 19:52, 18 March 2023 (UTC)
- @Isaacl: Yes, archiving bots do
Thank you (mobile editor)
I'd just like to thank the developers for finally enabling us to edit our Talk-page posts in the mobile (browser-based) editor. Creating typos, then not being able to fix them—you can imagine how frustrating that was for us obsessive über-fussy dedicated text maniacs underutilized underachievers literary loose cannons contributors. Cheers! (If there's a better place for this, feel free to move it there.) – AndyFielding (talk) 08:47, 18 March 2023 (UTC)
Mainly a mobile user. I used an article's talk page today, after being mostly away for some time. The basic functioning of the new interface is significantly better than the old one. Thank you! TooManyFingers (talk) 15:34, 18 March 2023 (UTC)
- @PPelberg (WMF) Just sharing some positive feedback for you and the rest of the team. And I'll add my own, very glad to see this live! the wub "?!" 22:18, 18 March 2023 (UTC)
- @AndyFielding, it feels good knowing you're finding the new mobile talk page experience useful ^ _ ^
- And thank you for pinging, @The wub – the entire Editing Team was pleased to log on and see the comments from y'all.
- Of course, if as you're using the new experience you notice areas that could be improved, we'd value being made aware of that too. PPelberg (WMF) (talk) 01:14, 21 March 2023 (UTC)
About Module:Adjacent stations
Hi, I am from Chinese Wikipedia. I think it should have a new function.
In Template:Adjacent stations, each line has two colour boxes. However, they can't be different. I suggest the new function below:
["line A"] = { ["color"] = "114514", -- This is the main colour which used in Template:Rail color. This colour appears at the left colour box. ["color2"] = "191981", -- This is not the main colour. This colour appears at the right colour box. ["left terminus"] = "X", ["right terminus"] = "Y" },
This function is useful in Japan railways. I hope it can be added. 阿南之人 (talk) 04:53, 19 March 2023 (UTC)
- Please post this at Template talk:Adjacent stations which covers discussion of the template and the module. You should get a response there, but if you don't, try WT:WikiProject Trains. Johnuniq (talk) 05:55, 19 March 2023 (UTC)
Very nice upgrade for persistent table headers and footers while scrolling. Who do I thank for this? Mathglot (talk) 10:09, 19 March 2023 (UTC)
- @Mathglot: Did you recently enable Make headers of tables display as long as the table is in view, i.e. "sticky" at Special:Preferences#mw-prefsection-gadgets? The gadget is from 2017 and hasn't been edited since July 2022. It breaks some tables and I only like it on some long tables so I made User:PrimeHunter/Sticky headers.js to reload the current page with the gadget code without having the gadget permanently enabled. I suggested at MediaWiki talk:Gadget-StickyTableHeaders.css#Proposal to add toggle to build something similar into the gadget. PrimeHunter (talk) 13:41, 19 March 2023 (UTC)
- Ohh, thanks! I make changes to prefs sometimes, and occasionally flip something else beyond I came there to do; it's possible I did that, without it registering on me. Thanks for resolving the mystery! Also for your script, and for suggesting at mw-talk, to which I've added a word for support. Mathglot (talk) 18:36, 19 March 2023 (UTC)
Some headings don't show on WP:PROCC
When I visit WP:WikiProject Climate Change on mobile (link), only the first two headings are shown / the third heading and below is not collapsible. Is there some magic to fix this? —Femke 🐦 (talk) 10:58, 19 March 2023 (UTC)
- @Femke: Fixed by closing unclosed divs.[1] I don't know where they were intended to close so I just closed them right away although it leaves code which does nothing. PrimeHunter (talk) 13:29, 19 March 2023 (UTC)
Table of contents broken (serious)
The page table of contents is currently totally missing and broken in the Vector 2022 skin. It is a blank white space unless JavaScript is turned on. 92.51.252.71 (talk) 15:05, 19 March 2023 (UTC)
- They are working on fixing this at phab:T331176. PrimeHunter (talk) 15:54, 19 March 2023 (UTC)
Feedback for module I started: Module:Speedy
Hi, so I have been working on this module called "speedy" for the purpose of speedy deletion tagging. The rationale for this is that it is much more flexible than the system we currently have.
I do need to add more sufficient documentation to explain how this works but it is much much simpler than our current system:
- Speedy deletion templates and notices are encapsulated in the same module. If you see Module:Speedy/config (where all the configuration for the speedy templates are), the module can generate both speedy templates and speedy notices.
- The templates that would result would be very flexible. If you see Template:Db/testcases you can see some of the key features I have added and the advantages of this. It would allow for listing of multiple criteria and filling in the full reasons.
- Speaking of templates, there would need to be less of them. As soon as a criteria is repealed it can be removed from the config module, and the template transcluding that can be speedy deleted as uncontroversial maintenance.
- Page blanking and page hiding: different criteria such as copyright violations and attack pages can hide the contents of the rest of the page as well as allowing for the immediate deletion of such content.
Some of the other things I have been thinking about adding include:
- Custom categorization: We can have the config specify categories to add to the templates. Currently, the two categories that would be added by this template are Category:Candidates for speedy deletion and Category:Candidates for speedy deletion (deletion code). I do think there is an advantage to the latter categorization model, especially because it allows for new categories to be spun up easily and because of a standard categorization format.
- Adding more aliases: I started with a few basic aliases but I think there are many more aliases that can be added to this, such as negublp, and their own custom messages.
All in all, this change would be welcome in making speedy deletions easier to do. I look forward to implementing any other things that would be helpful for this module in the future. Aasim - Herrscher of Wikis ❄️ 23:31, 19 March 2023 (UTC)
- Feature creep amounting to a solution in search of a problem.
Speedy deletion templates and notices are encapsulated in the same module
-> you're not establishing why that's simpler; I would argue that adding more layers of indirection makes things more complex.If you see Template:Db/testcases you can see some of the key features I have added and the advantages of this
-> I'm really not seeing anything there that isn't already supported by {{db-multiple}}, possibly with slightly different syntax.Speaking of templates, there would need to be less of them. As soon as a criteria is repealed it can be removed from the config module, and the template transcluding that can be speedy deleted as uncontroversial maintenance.
-> Again, I'm not seeing why this is an advantage. In the current system repealed criteria templates get sent to TfD, and I'm not seeing why the use of a module makes them become deletable as housekeeping when they weren't previously.Page blanking and page hiding: different criteria such as copyright violations and attack pages can hide the contents of the rest of the page as well as allowing for the immediate deletion of such content.
-> {{db-g10}} AFAIK already does this, and in any case any kind of template blanking magic is not sufficient asdisplay:none does not hide the content from indexing bots 2) noindex has no effect in namespace
. {{db-g12}} could easily be made to do so, if there were consensus for it.Adding more aliases: I started with a few basic aliases but I think there are many more aliases that can be added to this, such as negublp, and their own custom messages
-> {{db-negublp}} already exists, and nothing is stopping you from creating more redirects to CSD templates if you think they're needed.
- I've never been a fan of the "encapsulate everything into a god module" programming style, although I acknowledge it's used in some other places, and see no benefit to doing so here.* Pppery * it has begun... 23:46, 19 March 2023 (UTC)
- See Special:Diff/1051672359 for my general views on when modules should be used. This looks very much like a
use[] of Lua that do[es]n't fall into any of the above three cases and [is] instead done solely for the sake of internal complexity
. * Pppery * it has begun... 23:52, 19 March 2023 (UTC) - A "God Module" might be more helpful for new users since a new user might use {{db}} without understanding that there are more specific deletion templates to use.
- Also consider that a deletion template has three things: the template itself, the notice for speedy deletion nomination, and the notice for actual deletion. {{db-multiple}} (and to a lesser extent {{multiple issues}}) works by splicing whatever reason is inside the template page, whereas the proposed module would just use a data file with all the deletion reasons.
- Having a centralised module also allows for one template to serve three purposes: it allows for the correct template to be used for the correct occasion (since an addition of "|notice=yes" builds the deletion notice for the talk pages, and if the page does not exist it mentions that the page was deleted), it allows for internationalization (to some extent) if someone decides to snipe our deletion template and use it for their own purposes, and it allows for the addition and removal of deletion criteria (with consensus) in a centralized place.
- This will also greatly reduce page clutter. All of the {{db-notice}} and {{db-deleted}} templates need to be kept in sync with one another when updating reasons. Whereas updating one config module only requires one edit after consensus.
- I was also thinking about using msgnw for deletion reasons that need blanking to see whether the deletion template is the only thing on the page. As for hiding copyright violations, we do that with {{copyvio}} regularly, but I can't figure out why it isn't done with the db template at this moment.
- I believe this complex and "feature creep" might be helpful to make it simpler for new editors how each criteria works. Aasim - Herrscher of Wikis ❄️ 02:34, 20 March 2023 (UTC)
- Sorry, this still isn't convincing me. New users doing CSDs probably either use Twinkle or add a manual CSD template and copy the wikitext it suggests to use for notices (or don't notify at all), and all of those processes will remain unchanged even under your new system.
{{db-multiple}} (and to a lesser extent {{multiple issues}}) works by splicing whatever reason is inside the template page, whereas the proposed module would just use a data file with all the deletion reasons.
-> Yes, of course, you're describing what you did, as if its benefits were self-evident (they're not). Having a centralised module also allows for one template to serve three purposes: it allows for the correct template to be used for the correct occasion (since an addition of "
-> this says nothing; the syntax|notice=yes
is not substantially different from the syntax-notice
, and I would argue having one template do completely different things makes things worse.[...] and if the page does not exist it mentions that the page was deleted
-> no it won't, we fully subst out user talk messages by convention, so whatever logic you use to produce them won't be dynamic.This will also greatly reduce page clutter. All of the {{db-notice}} and {{db-deleted}} templates need to be kept in sync with one another when updating reasons. Whereas updating one config module only requires one edit after consensus.
-> This would, at best, reduce the number of templates by ~30. There are hundreds of thousands of templates, so this is notgreatly reduc[ing]
anything. And edits to CSD criteria are rare enough and visible enough that there's little need to spend effort streamlining the process.I was also thinking about using msgnw for deletion reasons that need blanking to see whether the deletion template is the only thing on the page
. The same thing could be done with one line of code in {{db-meta}} ({{#ifexpr:{{PAGESIZE:{{FULLPAGENAME}}|R}} > NUMBER|BLANKED|NOTBLANKED}}
) if someone felt so inclined.I believe this complex and "feature creep" might be helpful to make it simpler for new editors how each criteria works
. You're failing to explain how. Even from a black-box perspective, this shifts the system from one complicated user interface to another one that seems equally complicated to me, and likely can be understood by fewer of Wikipedia's technical contributors. This-is the sort of discussion where I think it's clear neither of us is going to convince the other one of their position, so I likely won't be replying further. * Pppery * it has begun... 03:27, 20 March 2023 (UTC)
- Sorry, this still isn't convincing me. New users doing CSDs probably either use Twinkle or add a manual CSD template and copy the wikitext it suggests to use for notices (or don't notify at all), and all of those processes will remain unchanged even under your new system.
- See Special:Diff/1051672359 for my general views on when modules should be used. This looks very much like a
- @Awesome Aasim On page Template:Db/testcases I see "The contents of this page is currently hidden pending review by an administrator" a few times. Wherever that text is coming from, "is" should be "are". David10244 (talk) 10:58, 20 March 2023 (UTC)
- @David10244 Thanks for the feedback. I fixed that. Aasim - Herrscher of Wikis ❄️ 21:22, 21 March 2023 (UTC)
- I generally think modules like this are a net positive, as long as the configurations are in an easily understandable format so that even those not well-versed with lua are able to edit them. When more involved edits to the logic are required, it always requires more seasoned editors, whether it's written in lua or using intricate wikimarkup. – SD0001 (talk) 08:12, 22 March 2023 (UTC)
Problem: External postings of article title links continue to drop endings of titles?
Problem: External postings of article title links continue to drop endings of titles?
@An anonymous username, not my real name, Hike395, Jonesey95, PrimeHunter, Rhododendrites, Tamzin, and Viriditas:
PROBLEM: Posting links to WikiArticle titles on social media (like FaceBook and others), EMail programs (like Pop Peeper and others) and/or newspapers (like The New York Times (NYT) continue to drop the ending of the WikiArticle title (esp "}", "?", "quotation mark" and "apostrophes") resulting in a WikiError page rather than the WikiArticle as intended. A typical recent example of this Problem ("bug"?) was my recent Published Comments in The New York Times at => https://www.nytimes.com/2023/03/19/theater/dancin-broadway-review.html#permid=123888206 - regarding the WikiArticle title of Dancin' where the ending apostrophe was dropped, resulting in a WikiError Page - my temporary solution was to create a Dancin WP:Redirect (RD) in which the ending apostrophe of the original WikiArticle title of Dancin' is dropped - the WikiRD directs the NYT Reader to the correct WikiArticle as intended.
This same Problem ("bug"?) was posted earlier in 2018 (please see my posting => Wikipedia:Village_pump_(technical)/Archive_162#Workaround_for_dropped_")"_in_titles? ) and continues to be a Problem today - seems a similar ("bug?) Problem may have occurred on Reddit as well, but may have been solved in 2022(?)
Hope my description of this Problem ("bug"?) helps in some way, and a Solution is found - easier access to WikiArticles from outside WebSites and related is very important to Wikipedia I would think - in any case - Stay Safe and Healthy !! - Drbogdan (talk) 16:12, 20 March 2023 (UTC)
- That looks like a bug in The New York Times's commenting system. The character "
'
" is valid in a URL, but their parser appears to incorrectly exclude that character from the end of a URL. I think you'll need to send feedback to the Times. (Edited to add: Editors of MediaWiki sites have been trying to work with developers for many years to come up with a reasonable workaround for inevitable problems related to punctutation at the end of wiki page titles. See T28556 and T23615 and T40265.)– Jonesey95 (talk) 16:16, 20 March 2023 (UTC) - See Help:URL#Fixing links with unsupported characters for encodings you can try when posting a raw url in a place where some software converts it to a link and has to guess where the url ends. https://en.wikipedia.org/wiki/Dancin%27 would probably have worked (but doesn't look pretty). If a place both has an automatic feature to convert raw url's and an add-a-link feature where you can give the url and link text separately then use the add-a-link feature, also if you enter the exact same string as url and link text. PrimeHunter (talk) 16:39, 20 March 2023 (UTC)
@An anonymous username, not my real name, Hike395, Jonesey95, PrimeHunter, Rhododendrites, Tamzin, and Viriditas:
SOLUTION (possible): Although not the ideal Solution - BUT - simply adding an UNDERSCORE to the end of such "problematic" WikiArticle Titles may help Workaround the Problem - at least for current FaceBook and my current EMail (Pop Peeper) (and, possibly, NYT) posts as follows: https://en.wikipedia.org/wiki/Readin'_and_Writin' directs to a WikiError Page - BUT - https://en.wikipedia.org/wiki/Readin'_and_Writin'_ (with an added underscore) directs to the correct WikiArticle Title Page instead - and Not to a WikiError page - and Not with the use of an additional temporary WP:Redirect Page (see Dancin example described above) - although not tested, this Solution should work in other social media postings (and newspaper postings) regarding such "problematic" WikiArticle Titles - this Solution, in part, was inspired by a suggested Workaround — Hamlet A.D.D..) — in https://phabricator.wikimedia.org/T28556 - in any case - hope this helps in some way - Stay Safe and Healthy !! - Drbogdan (talk) 01:12, 21 March 2023 (UTC)
- The underscore trick even works in MediaWiki itself. https://en.wikipedia.org/wiki/Martin_Luther_King_Jr. skips the ending period when a link is made. It only works because there is a redirect page. https://en.wikipedia.org/wiki/Martin_Luther_King_Jr._ includes the period and underscore in the link and works without a redirect page. However, it does involve a redirect: If an incoming link has a trailing underscore in the page name then MediaWiki automatically redirects to the url without the underscore. It only applies to underscores after page names. https://en.wikipedia.org/w/index.php?title=Martin_Luther_King_Jr.&action=history_ is broken. I don't know whether there are significant disadvantages in relying on the automatic redirect on page names with an underscore appended. PrimeHunter (talk) 03:24, 21 March 2023 (UTC)
Using a WP:Redirect seems like a good workaround, especially for existing non-wiki pages in the real world, which typically can't or won't be changed. However, this workaround has a drawback: there are editors who patrol redirects and have an allergy to such redirects. They may delete them as encountered, or collect them and propose deleting them at WP:RFD. I have the impression that the regulars at RfD have a predisposition to delete these sorts of redirects. An example involving the trailing ")" URLs mentioned above is this discussion, which ultimately deleted a group of over 60 such URLs, including some that had over 10,000 usages over the preceding year. --R. S. Shaw (talk) 01:25, 21 March 2023 (UTC)
- Reading that discussion both sides made good arguments; those in favor of keeping argued that it helps out readers, those in favor of deleting argued that it causes issues in search results, that the problem only exists because of bugs in other peoples code, and that readers are already soft-redirected to the target article by MediaWiki.
- One solution would be to turn that soft-redirect into a hard-redirect, but that will require us to convince the WMF to do so. In the meantime, it may be worth having a discussion about whether to modify PAGs to support or oppose the creation of these redirects, to stop constant debates about them. BilledMammal (talk) 03:34, 21 March 2023 (UTC)
Is something wrong with Massmessage?
The Signpost got feedback from a reader that they were sent the current issue twice via Massmessage. I did some checking and saw around a dozen instances of this. Ene subscriber even had it posted three times: User talk:Newyorkadam. This particular user seems to have had many different Massmessage triplings from various lists since around November 2022. Is this a known issue? ☆ Bri (talk) 16:53, 20 March 2023 (UTC)
- @Bri It's a long-running issue with the tool - T93049. Sam Walton (talk) 17:18, 20 March 2023 (UTC)
- Since 2015, OMG. Maybe we need to send more donations to the Foundation. ☆ Bri (talk) 17:20, 20 March 2023 (UTC)
- The WMF doesn't want to spend donations on Wikipedia; they have other priorities. - R. S. Shaw (talk) 01:51, 21 March 2023 (UTC)
- MassMessage is a volunteer-maintained extension, more contributors are always welcome. Legoktm (talk) 06:38, 21 March 2023 (UTC)
- Since 2015, OMG. Maybe we need to send more donations to the Foundation. ☆ Bri (talk) 17:20, 20 March 2023 (UTC)
Unable to login to tools?
I have tried to login to Copypatrol and the Wikipedia Library without any success. Copypatrol thinks for a bit and then comes back with no error messages. The Wikipedia library tells me "Permission denied" with a yellow box near the top stating "Access token generation failed." This happens on my desktop and tablet and happens on Chrome or Edge browsers. -- Whpq (talk) 18:09, 20 March 2023 (UTC)
- @Whpq The Wikipedia Library login issue is affecting all users sporadically (trying again might yield better results) - T332349. I'm not sure if the CopyPatrol issue is related. Sam Walton (talk) 19:43, 20 March 2023 (UTC)
- Thanks for the info. The number of editors trying to log in to Copypatrol is likely very limited compared to the Wikipedia Library. -- Whpq (talk) 20:13, 20 March 2023 (UTC)
- Just took me about 3 attempts to log in to CopyPatrol — clearly something is up, but does trying a few times work for you? — TheresNoTime (talk • they/them) 20:17, 20 March 2023 (UTC)
- I managed to to get logged in to Wikipedia library on the third attempt. I still get an error message but the end result is that I am logged in and was able to get to JSTOR. No luck with madly clicking on the login button for Copypatrol. I must have tried at least 20 times and did not get logged in. -- Whpq (talk) 20:45, 20 March 2023 (UTC)
- We may have identified a larger issue with OAuth that affects many tools. It's being tracked at phab:T332650. In the meantime, while it may take numerous tries, you should eventually be able to login to the these tools. — MusikAnimal talk 14:38, 21 March 2023 (UTC)
- I managed to to get logged in to Wikipedia library on the third attempt. I still get an error message but the end result is that I am logged in and was able to get to JSTOR. No luck with madly clicking on the login button for Copypatrol. I must have tried at least 20 times and did not get logged in. -- Whpq (talk) 20:45, 20 March 2023 (UTC)
- Just took me about 3 attempts to log in to CopyPatrol — clearly something is up, but does trying a few times work for you? — TheresNoTime (talk • they/them) 20:17, 20 March 2023 (UTC)
- Thanks for the info. The number of editors trying to log in to Copypatrol is likely very limited compared to the Wikipedia Library. -- Whpq (talk) 20:13, 20 March 2023 (UTC)
Max for table that also scales to viewport
How do I make a table scale to viewport (the main content container) if the viewport width is under the max width, but only have width at the max width if the viewport exceeds the max width? I previously posted this at HELP:DESK but since this is not about policy it isn't forumshopping right? Aaron Liu (talk) 01:10, 21 March 2023 (UTC)
- There are ways to do this in CSS with their various min(), max(), and clamp() functions, but using the viewport width in a way that produces good results is typically dependent on the specific layout, and thus hard to do in a skin-agnostic way. If you're just doing it in your own personal CSS file, that's fine, but I don't think it's a good idea to deploy generally. isaacl (talk) 01:30, 21 March 2023 (UTC)
- Well, those other functions are pretty new; clamp particularly is only recently in the specs.
- For the most part, tables (data tables) don't need something like this. Most either want to be min-content (which is basically their default) or they want to be full-width. I struggle to think of a case where I would prefer the table be 80% at desktop resolutions (or other arbitrary width) and 100% at small resolutions, especially when at small resolutions tables are so inflexible as to be nearly guaranteed to be 100%. If you do want to set a width for the table,
width: xem; max-width: 100%;
should mostly guarantee that it will shrink when expected. Izno (talk) 01:36, 21 March 2023 (UTC)- I agree I don't think we should be trying to deliberately break tables out of their containing block, and max-width is a well-supported approach. (On a side note, min() and max() have been supported by major browsers for over three years now. Still too new for mw:Compatibility#Basic (Grade C) support, but good candidates for progressive enhancement, in other situations.) isaacl (talk) 02:24, 21 March 2023 (UTC)
- Strictly speaking, the
clamp()
function isn't in the specs yet - the only W3C doc that I can find that mentions it is CSS Values and Units Module Level 4 (19 October 2022) and being a W3C Working Draft, is some way from being ratified as a W3C Recommendation (even CSS Values and Units Module Level 3, which doesn't mention the function, has been at the Candidate Recommendation Snapshot stage for over ten years). The function has been in CSS Values and Units Module Level 4 from the start (First Public Working Draft, 14 August 2018) but even so, shouldn't be relied upon: it may yet be modified, deferred to a hypothetical CSS Values and Units Module Level 5 (as indeed happened for the toggle() function), or even dropped entirely (all three of these have happened to other functions and properties). --Redrose64 🌹 (talk) 08:46, 21 March 2023 (UTC)- Well,
toggle()
was flagged as being at risk for removal in that first draft... My side note was respect tomin()
andmax()
(also first appearing in the first draft), and although they too could in theory be changed or removed, I think they remain good candidates for progressive enhancement adjustments. Given their widespread use and utility, it seems unlikely that browsers will remove support for them (and thus if the CSS spec were to change, it would have to account for this). isaacl (talk) 16:13, 21 March 2023 (UTC)
- Well,
- Strictly speaking, the
- It’s like some ems on desktop, and 100% on mobile. On skins such as legacy vector on widescreens 100% is too wide Aaron Liu (talk) 10:51, 21 March 2023 (UTC)
- I agree I don't think we should be trying to deliberately break tables out of their containing block, and max-width is a well-supported approach. (On a side note, min() and max() have been supported by major browsers for over three years now. Still too new for mw:Compatibility#Basic (Grade C) support, but good candidates for progressive enhancement, in other situations.) isaacl (talk) 02:24, 21 March 2023 (UTC)
Tech News: 2023-12
MediaWiki message delivery 01:24, 21 March 2023 (UTC)
- Somebody please correct me if I'm wrong, but CentralAuth is already in MediaWiki:Sp-contributions-footer and I'm sure that it's been there for years. I don't use any scripts or gadgets that affect that box. --Redrose64 🌹 (talk) 08:22, 21 March 2023 (UTC)
- That's an enwiki customization, the default value for that message is empty. Anomie⚔ 11:45, 21 March 2023 (UTC)
- The new link will be in the line of links under the page heading. I don't expect software conflicts with any scripts. phab:T331743#8693808 says: (imho, this "conflict" will be "two links appear"). MediaWiki:Sp-contributions-footer added the link in 2011.[4] If we remove it then there will probably be protests from users who don't notice the new link or have simply gotten used to the old location. Interface changes tend to cause drama. PrimeHunter (talk) 00:00, 22 March 2023 (UTC)
- Now discussed at MediaWiki talk:Sp-contributions-footer#Protected edit request on 24 March 2023. PrimeHunter (talk) 14:02, 24 March 2023 (UTC)
- The new link will be in the line of links under the page heading. I don't expect software conflicts with any scripts. phab:T331743#8693808 says: (imho, this "conflict" will be "two links appear"). MediaWiki:Sp-contributions-footer added the link in 2011.[4] If we remove it then there will probably be protests from users who don't notice the new link or have simply gotten used to the old location. Interface changes tend to cause drama. PrimeHunter (talk) 00:00, 22 March 2023 (UTC)
- That's an enwiki customization, the default value for that message is empty. Anomie⚔ 11:45, 21 March 2023 (UTC)
Mobile view for deleted pages broken?
I was trying to provide advice on a deleted page to a new-ish editor today and found what seems to be a problem with the mobile browser view of deleted pages. I directed the user to the deleted page MV Feisty Gas to give an example of a deletion log, but I found when I tried to access the link in my mobile browser, the page briefly loaded with the page log, but then immediately loaded the source editor over top of it, so the log could not be read. Closing the editor caused the page to navigate back to the previous page, so the log was still not visible. Is that behaviour intentional? I am using Vector 2010 if that makes a difference. Ivanvector (Talk/Edits) 14:52, 21 March 2023 (UTC)
- Why not send them directly to the logs for this page? --Redrose64 🌹 (talk) 15:02, 21 March 2023 (UTC)
- Because they hadn't provided the name or a link to the page they were asking about and I couldn't figure out which page it was from their deleted contribs, so I was trying to show them how to find the rather easily viewable log at the deleted page's location (the page I picked was from my own deletion log). Ivanvector (Talk/Edits) 15:20, 21 March 2023 (UTC)
- My understanding is that this behavior is intentional, based on some ancient discussion I recall reading in the vicinity of phabricator. It reflects and/or is the behavior of VisualEditor/its wikitext mode to do this also. Izno (talk) 18:09, 21 March 2023 (UTC)
- It's not intentional, and I had even thought that I've fixed it a few years ago in T201852. The editor opens when following a red link, but you're supposed to be able to close it. (On desktop as well, although the editor lacks a dedicated button for it, and there are some bugs filed about that [@Izno You might be remembering T211379], but you can press Esc on the keyboard.) I don't know whether it broke or if it never worked. Testing on that page now, closing the mobile editor works correctly for me when it's in visual mode, but not when it's in source mode. I can't look into it now, but please file a bug. Matma Rex talk 22:07, 21 March 2023 (UTC)
- (... yup, that would be the one.) Izno (talk) 22:08, 21 March 2023 (UTC)
- I just tested again while trying to write up a bug report, and now it works as expected (closing either the visual editor or source editor reveals the log and does not navigate backwards). The error only seems to happen if I navigate to the deleted page in desktop view, and then switch to mobile. If I'm in mobile when I click on the redlink then it works as expected. Given that that's a pretty limited case I don't think it's worth filing a bug report. Ivanvector (Talk/Edits) 20:52, 22 March 2023 (UTC)
- (... yup, that would be the one.) Izno (talk) 22:08, 21 March 2023 (UTC)
- It's not intentional, and I had even thought that I've fixed it a few years ago in T201852. The editor opens when following a red link, but you're supposed to be able to close it. (On desktop as well, although the editor lacks a dedicated button for it, and there are some bugs filed about that [@Izno You might be remembering T211379], but you can press Esc on the keyboard.) I don't know whether it broke or if it never worked. Testing on that page now, closing the mobile editor works correctly for me when it's in visual mode, but not when it's in source mode. I can't look into it now, but please file a bug. Matma Rex talk 22:07, 21 March 2023 (UTC)
Repeated generation of redlinked roller coaster categories by the infobox
{{Infobox roller coaster}} is currently programmed to autogenerate categories based on the content of various entry fields, but this results in the repeated appearance at Special:WantedCategories of nonsense redlinks for categories that don't exist. This typically takes one of two forms:
- a roller coaster that was previously in operation closes for renovation, so people flip the status from "open/closed" to "under construction" — but since "under construction" status is programmed to interact with the content of the opening date field to generate a "Roller coasters planned to open in YYYY", but the roller coaster already opened 10, 20, 30, 40 or 50 years ago, that generates a "Roller coasters planned to open in [10, 20, 30, 40 or 50 years ago]" category that I can't legitimately create and can't leave there, forcing me to flip the status from "under construction" back to "closed".
- even though the infobox documentation plainly states that "type =" is only looking for whether the roller coaster is made of steel or wood, people keep adding other types of information to the "type =" field anyway, such as "Dark ride" or "Spinning dark ride" — which causes the generation of a "Dark ride roller coasters" or "Spinning Dark ride roller coasters" category that I can again neither create nor leave there, again forcing me to go in to strip the misuse of the field.
Per WP:TEMPLATECAT, however, templates are not allowed to autogenerate categories based on variable text field entries, precisely because this can result in the autogeneration of redlinked nonsense categories in the event of any errors in or misuses of the template, so the template has to be prevented from being able to autogenerate any redlinks. But the problem is that I previously asked for this to be addressed in December at Template talk:Infobox roller coaster#Automatically-generated categories, but nothing was done about it and such categories are still happening — so I need somebody with more skill in template coding than I've got to step in and disable the category generation functions so that the redlinks stop. Bearcat (talk) 13:57, 22 March 2023 (UTC)
- @Bearcat, removing the automatic categories is trivial. Ensuring they are already directly on the articles of interest is a matter of busywork (there's a lot of articles to go through), but also trivial (use AWB). If you were to do the work to ensure each roller coaster article has each relevant category in its wikitext, I am fairly certain someone (me, even) would process the relevant edit requests.
- I basically already said that in this earlier discussion. @Jonesey95 also said as much to you in the discussion you referenced. Izno (talk) 18:05, 22 March 2023 (UTC)
- Somebody has to do that AWB run, certainly — but there's no rule that it has to be me, and it's not going to be me, because I'm the only person who gets to decide what busywork I do or don't have the time, energy and inclination to take on. But regardless of whether that other busywork does or doesn't get done in a timely fashion, the autogeneration of redlinked categories has to be unconditionally rendered impossible immediately, and cannot wait out another three months of inaction — there must never be another "Roller coasters planned to open in [30 years ago]" category showing up on WantedCategories ever again, because that creates an unnecessary and unhelpful burden of work for other people to have to fix. Bearcat (talk) 18:16, 22 March 2023 (UTC)
- @Bearcat, if you're going to complain about it, you're the one who is going to have to do the work. Sorry, squeaky wheels don't get greased here, because you're not the only volunteer here. And speaking in absolutes about what must be done is not likely to win you any favors to boot. And this is coming from someone who agrees the work should be done. Izno (talk) 18:35, 22 March 2023 (UTC)
- You're asking me to take on a busywork project that is completely tangential to the core problem of the template autogenerating redlinked categories that don't and can't exist before I'm allowed to request a fix to the problem of redlinked categories? Sorry, that's not how this works: none of what you're telling me to do here has anything to do with the problem of nonexistent categories, and there's no rule that I have to take on an unrelated busywork project before I "earn" the right to request a fix to a problem that has nothing to do with it.
- It's also not my responsibility to have to put up with these redlinked roller-coaster categories repeatedly returning, and repeatedly having to ask for something to be done about it because somebody doesn't like my tone of voice or the fact that I haven't chosen to take on a busywork project that's completely tangential to the problem, either. The redlinked categories can be fixed without forcing me to put other projects on hold to do something about non-redlinked categories that do exist and aren't the problem. Bearcat (talk) 18:46, 22 March 2023 (UTC)
- Then stop making it your responsibility. You cannot on the one hand say "I'm going to deal in redlinked categories" and then on the other hand say "I am unable or unwilling to deal with the consequences of dealing in redlinked categories" and then expect anyone to take you seriously or to help.
- Anyway, I'll move on. Good luck with your mission. Izno (talk) 18:51, 22 March 2023 (UTC)
- Sorry, no. Just because there's an essential maintenance task that has to be done on a regular basis, the people who deal with it are somehow supposed to quietly put up with the repeated generation of autogenerated redlinked categories that are significantly more difficult and time-consuming to actually clean up than regular category declarations are, even though there are other technical ways to stop those redlinked categories from being generated at all?
- Working with redlinked categories has three essential components: (a) removing and cleaning up redlinks that genuinely shouldn't exist, either because somebody tried to add a category that isn't reflected in our category tree or because they just mistyped or misspelled a category that exists at another spelling, (b) creating categories that genuinely should exist, and (c) identifying patterns where categories that genuinely shouldn't exist are being generated by processes that shouldn't be generating categories at all, such as errors and violations in template coding. So if a template is generating redlinked categories that it shouldn't be generating, then getting that fixed so it stops happening is part of the job description, and nobody is entitled to tell me any different.
- The entire point of working with redlinked categories, after all, is to make them go away. Ideally, no redlinked categories would ever happen at all, but since we're not there yet and there are typically about 300 new redlinked categories to fix per week, the job also includes identifying ways to reduce the load in the future by noticing that templates are causing problems they shouldn't be causing. So sometimes that's just "remove category". Sometimes it's "create the category so that it's not a redlink anymore". Sometimes it's "remove category from a template that's transcluding it", and sometimes it's "either fix template, or get somebody with more experience in template coding to fix it, if the template is autogenerating bad categories by some process other than a straight category declaration". But that's all part and parcel of the job, and it's not my responsibility to take any lectures from anybody about it: If I identify a pattern of bad categories that are repeatedly being generated by a template that shouldn't be generating bad categories, then getting it fixed is part of my job, not me shirking anything. One thing that isn't in the joib description is "shut up and suck it because somebody else finds it annoying". Bearcat (talk) 19:42, 22 March 2023 (UTC)
- As I said, good luck with your mission. Izno (talk) 19:55, 22 March 2023 (UTC)
- Condescension not needed or deserved. If you don't wanna help fix a problem, you don't have to help fix it, but you don't get to tell me that I'm not allowed to ask for a problem to be fixed unless I choose to take on some other busywork project that isn't actually related to the problem, or that I'm being unreasonable in asking for help fixing a problem in the first place. Just move on if you wanna move on, but I don't have to take being insulted or condescended to in the process. Bearcat (talk) 20:03, 22 March 2023 (UTC)
- As I said, good luck with your mission. Izno (talk) 19:55, 22 March 2023 (UTC)
- @Bearcat, if you're going to complain about it, you're the one who is going to have to do the work. Sorry, squeaky wheels don't get greased here, because you're not the only volunteer here. And speaking in absolutes about what must be done is not likely to win you any favors to boot. And this is coming from someone who agrees the work should be done. Izno (talk) 18:35, 22 March 2023 (UTC)
- Somebody has to do that AWB run, certainly — but there's no rule that it has to be me, and it's not going to be me, because I'm the only person who gets to decide what busywork I do or don't have the time, energy and inclination to take on. But regardless of whether that other busywork does or doesn't get done in a timely fashion, the autogeneration of redlinked categories has to be unconditionally rendered impossible immediately, and cannot wait out another three months of inaction — there must never be another "Roller coasters planned to open in [30 years ago]" category showing up on WantedCategories ever again, because that creates an unnecessary and unhelpful burden of work for other people to have to fix. Bearcat (talk) 18:16, 22 March 2023 (UTC)
Proposal for next steps following the closure of the Vector 2022 RfC
Hi everyone,
We know that many of you have taken part of and kept an eye on the ongoing conversations around the deployment of the Vector 2022 skin. We have just posted some of our current thinking for next steps following the closure of the Vector 2022 RfC, and would appreciate your thoughts and feedback. Thank you! OVasileva (WMF) (talk) 19:35, 23 March 2023 (UTC)
How to expand this sidebar?
Hi all, I'm trying to fully expand {{Human history}} on the Human history article but am not sure how to do so. The sidebar code is a bit unclear and {{Human history|expand=yes}} isn't working. Any ideas? Aza24 (talk) 02:48, 24 March 2023 (UTC)
- @Aza24, you can either set
|expand=
to the specific section you wish expanded by its name set in the wikitext (e.g. expanding the Holocene section which has|list1name=Holocene
, you'd set|expand=Holocene
). To expand all, set|expand=all
. Izno (talk) 03:20, 24 March 2023 (UTC)
Is Special:PasswordReset broken?
Just tried to reset my password and I got internal errors saying my IP was blocked (it wasn't) half the time, and when it did load, it just loaded the normal login page. Had to go to Meta to reset my password. Has something changed? Anarchyte (talk) 10:38, 24 March 2023 (UTC)
- @Anarchyte Special:PasswordReset loads for me. Were you trying it while logged in or logged out? Did you get the error on opening, or only on submitting? — xaosflux Talk 12:30, 24 March 2023 (UTC)
- Logged out. I couldn't submit a password reset request because it asked for my username and password (with a login button), not username and email. Anarchyte (talk) 12:48, 24 March 2023 (UTC)
- Note that now that I'm logged in, it loads fine while both logged in and logged out. Perhaps it was something to do with swapping IPs between WiFi and phone hotspot, and one being incidentally hit by a range blocked? Anarchyte (talk) 12:49, 24 March 2023 (UTC)
- Quite possibly, it could also be due to administrators getting an IP block exemption by default, so you wouldn't be affected by any IP blocks while logged in. 163.1.15.238 (talk) 14:41, 24 March 2023 (UTC)
- Note that now that I'm logged in, it loads fine while both logged in and logged out. Perhaps it was something to do with swapping IPs between WiFi and phone hotspot, and one being incidentally hit by a range blocked? Anarchyte (talk) 12:49, 24 March 2023 (UTC)
- Logged out. I couldn't submit a password reset request because it asked for my username and password (with a login button), not username and email. Anarchyte (talk) 12:48, 24 March 2023 (UTC)
Placement of images in articles with infobox
Recently someone added an infobox to the Rani Pokhari aricle. Since then, it appears no longer possible to place images in the text to the left of the infobox. All images are pushed to below the lower edge of the box, no matter where you put it in the text. This creates a messy look, plus the illustrations are no longer next to the texts they are supposed to illustrate. Is there a solution to this? Judithcomm (talk) 12:36, 24 March 2023 (UTC)
- @Judithcomm The issue here seems to be that the first image in the article (the one with the caption "Wide view of Ranipokhari before 2015 earthquake.") is set to float to the right, so it appears after the infobox. The image that floats to the left is set to appear after this, so it appears further down the page.
- You generally should not place images floating to the left of an infobox per MOS:SANDWICH, as doing so causes display issues on narrower screens. 163.1.15.238 (talk) 13:14, 24 March 2023 (UTC)
- Problem solved! Thanks! --Judithcomm (talk) 13:23, 24 March 2023 (UTC)
- {{stack}} is the technical solution. PrimeHunter (talk) 13:30, 24 March 2023 (UTC)
- Problem solved! Thanks! --Judithcomm (talk) 13:23, 24 March 2023 (UTC)