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.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
When logged out, in dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 15:47, 5 September 2024 (UTC)[reply]
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:
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. AwesomeAasim04: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]
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. AwesomeAasim13: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. AwesomeAasim19: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.
I encountered a powerful autodoc tool on Fandom Dev Wiki called Docbunto, and I have been able to get some changes to make it work on Test Wikipedia. I think it would be very great to have an autodoc tool like Docbunto on Wikipedia to help speed up the process of writing module documentation. But the key feature I like is the ability to transclude templates and similar on Lua pages.
I don't think it is ready for English Wikipedia yet but maybe with a few changes it can be very feature rich and ready. Yeah we are not exactly a code repository, but we do have thousands of modules used across articles that would be helpful to have auto documentation for. AwesomeAasim18:21, 17 September 2024 (UTC)[reply]
Another improvement we can do over wiktionary is take advantage of line numbers now being linkable. Ideally, the generated docs of exported functions should include links to their source code definitions. – SD0001 (talk) 20:18, 17 September 2024 (UTC)[reply]
As for this, we can already do this on this wiki: Module:Module wikitext. That is very bodgy, and it doesn't entirely make sense to me how this works or why this should work. But then, an autodoc module rendering module comments is also very bodgy, although less bodgy because reading out comments to parse from the module is less likely to break than reading out variables from the documentation module after setting them in "addText". Module comments should be taken advantage of in the parser. I did open a task (and submit my first patch to MediaWiki to complete it) for having MediaWiki only parse the contents of CSS and JS comments, see phab:T373834 (and kindly do please send more feedback on how I can improve that patch!) AwesomeAasim00:21, 18 September 2024 (UTC)[reply]
We considered generating documentation from LuaDoc when creating Scribunto, but we decided not to for the same reasons most documentation pages here are on /doc subpages instead of being inline in the template page: inlined docs can't be protected separately from the module/template and any edit to inlined docs means any pages using the module/template have to be reparsed. Anomie⚔23:50, 17 September 2024 (UTC)[reply]
I'd figure. I think of this inline doc as a good starting point for most Lua modules but ultimately there should be additional documentation that goes beyond the default functions and describes what the module exactly does. AwesomeAasim23:53, 17 September 2024 (UTC)[reply]
Yeah, being able to edit documentation without going through edit requests would be nice, even though so would be autogenerating doc sections for functions. Nardog (talk) 01:20, 18 September 2024 (UTC)[reply]
Automated cat herding is not going to work at Wikipedia. Imagine forcing every module to have comments in a fixed format with extra gunk to be machine parsable. Johnuniq (talk) 02:27, 18 September 2024 (UTC)[reply]
It is really bad practice to not put comments in code. Autodoc obviously won't work if there aren't any properly formatted comments. The goal of autodoc is to document functions and variables and more importantly module exports. Even functions in use by other modules. It never is intended to replace the module documentation page at the top of each; just supplement it. AwesomeAasim03:05, 18 September 2024 (UTC)[reply]
Yes, useful comments are great. What I meant was, it would be very difficult to get independent editors to use a fixed format. Also, I don't think documenting all functions and variables is achievable or even desirable, for example, due to the inevitable drift between hopeful comments and actual code. I do agree that exports should be documented and I once argued strongly that a module (I forget where now) should not have every function exported due to ensuing confusion and maintenance issues. I lost that argument. Johnuniq (talk) 03:34, 18 September 2024 (UTC)[reply]
There is a few related stuff I can think of.
Automatically making a list of variables is actually easy. The hard part is getting arguments in loops. See is:Module:Templatedata fyrir skriftu, which can create basic templatedata (containing only a list of variables) with the code {{#invoke:Templatedata fyrir skriftu|main|''name of module with namespace''}}.
Why not both? If there's comments in code formatted in a certain way, show them in /doc, but also allow overriding or appending to it without having to edit the module directly. Nardog (talk) 03:37, 18 September 2024 (UTC)[reply]
+1. I do think having both is useful. We can provide an end user overview at the top of the module documentation page, and a developer's overview in the autodoc. Something similar to how I implemented autodoc on testwiki:Module:Docbunto and testwiki:Module:i18n. There should be some sort of disclaimer that the documentation is auto generated and the contents can be overridden. AwesomeAasim14:42, 18 September 2024 (UTC)[reply]
I did a little bit more work on the module (not really any), and I am wondering if the module can be imported from testwiki to English Wikipedia? We may have to update some of the attribution links to point to Fandom users, but not much else. AwesomeAasim01:23, 25 September 2024 (UTC)[reply]
You are the only contributor on testwiki. Just copy it. Looks like you've modified Module:Documentation on testwiki to make it automatically show the generated docs. It may be more intuitive to not do that and instead have /doc subpages call the autodoc module (the way it's set up on wiktionary), enabling the automatic and manually written docs to co-exist, making it clearer where the autodoc came from, avoiding the weirdness of a [create] button in the documentation header showing up even when the documentation seemingly exists, etc. – SD0001 (talk) 04:13, 25 September 2024 (UTC)[reply]
But the first edit at testwiki includes an edit summary with a link to the source. That should be retained. The subsequent edits may as well also be retained in the history here. I'm still dubious about whether automatic documentation can be helpful at Wikipedia but having it here would allow live demos. Johnuniq (talk) 05:37, 25 September 2024 (UTC)[reply]
Problem: That module is at testwiki which does not appear as an option at Special:Import. Only test2wiki is available (it was added in February 2013 when Scribunto appeared here). An alternative would be for Awesome Aasim to duplicate the first edit here, with its edit summary, then make another edit to include the current version. Johnuniq (talk) 05:58, 25 September 2024 (UTC)[reply]
Yeah and there are other problems that mean it won't be ready for use right away. See testwiki:Module:Documentation's autodoc, for example.
I still managed to get it onto English Wikipedia so that we can all work together to make it robust. I actually see why the original i18n module was deleted, while the one on Fandom and on other Wikimedia projects was not: it was too simple.
I dunno where the corresponding source is, or whether this is a Wikipedia or MediaWiki issue, or if there is a defect logged and/or a workaround available. jnestorius(talk)16:05, 18 September 2024 (UTC)[reply]
The caption being set to display block has always been weird to me; the other display blocks in Minerva make some sense (but I also think I've played around with this before and come to the conclusion that it was necessary?? memory is weird on this point).
TLDR: The issue is the inline style adding display: inline-table which is interfering with Minerva's ability to make the table responsive on a mobile device. Please move this to a TemplateStyle so that it only applies at a suitable breakpoint and does not break the display on mobile.
Longer version: On mobile, since a table doesn't fit in the screen, presenting them to mobile devices becomes tricky. The way we approach this general in MediaWiki sites, it to convert the display property of all table elements to block-based layouts rather than table-based layouts. Applying display block to the table caption, will ensure that it does not require horizontal scrolling to be viewed and will span multiple lines if needed. While this might seem strange is a pretty widely recommended and sensible practice.
The bug here IMO is not the table caption - it's the use of display inline-table. If you load this article on a mobile device, and expand sections you'll see that this introduces horizontal scroll on the page e.g. the table breaks the content of the whole article. e.g. the whole article is not mobile friendly (note the whitespace to right of chrome in this screenshot: https://phabricator.wikimedia.org/F57532981).
Inline styles as always interfere with a lot of the logic we have to optimize content. As with dark mode where use of any kind of color can break dark mode display - using display or width or height properties interfere with the responsive behaviour and I would personally recommend always using mw:TemplateStyles to express these. 🐸Jdlrobson (talk) 00:07, 24 September 2024 (UTC)[reply]
I was asked to investigate a problem with {{convert}} at the Ukrainian Wikipedia. I have edited some pages there and am curious about the effect of a new user (me) editing a pending-changes protected page such as uk:Module:Convert/пісочниця (/sandbox). When I look at that page in a private window where I am not logged in, I can find "pername". I added that in the most recent edit which history shows as "pending review". Also, the pername change to the module is used at uk:User:Johnuniq/convert#pername (it shows dummy text "miPER" and "acrePER" in the output). In other words, an edit to the module which has not been reviewed still has an effect that is visible to all. This is not important—I'm just curious about WP:Pending changes. It appears that PC on a module does not achieve much other than flagging it as needing review? Johnuniq (talk) 02:58, 23 September 2024 (UTC)[reply]
I just tried editing the PC protected page uk:Template:Convert/пісочниця. In a private window I could see the change to the template, and I could see the effect of the change. (I stuffed up my edit summary when I self-reverted—I meant to say that PC had no effect.) Johnuniq (talk) 03:45, 23 September 2024 (UTC)[reply]
In Ukrainian Wikipedia, there is no expectation that pages are stabilised by default, so the page contents of /sandbox page display the unreviewed page. Template review status is tracked on pages transcluding the template that use FlaggedRevs. So User:Johnuniq/convert would also show the page with unreviewed edits while the mainspace page won’t. stjn18:23, 24 September 2024 (UTC)[reply]
@Johnuniq Most of unreviewed changes are seen by unregistered user. It also doesn't depends if page has semi or full protection levels (however, to have fully protected page with unrewieved changes is rarest thing, because all administrator have rewiever rights). Only what matters is if a page has stabilization or not. Usually, if a page is highly proned to vandalism or have chosen as good article or featured article, administrator stabilize the page. In this case, all of unrewieved changes aren't seen by unregistered user. Usually, pages have special symbol to mark that they are stabilized, and the text on a save button would change from "save" to "write" or "write changes". Repakr (talk) 05:08, 24 September 2024 (UTC)[reply]
Thanks. I've never seen that approach. I was wondering whether unregistered users would see the effect of an unreviewed change to a module or template. One day you might test that with a stabilized module but we have enough to think about before continuing this. Johnuniq (talk) 05:36, 24 September 2024 (UTC)[reply]
This is not I am looking for. Is there some option in WYSIWYG editor (add a toolbar) to select and change BG color of a cell or group of cells, like in MS Excel ? Anish Viswa 07:54, 25 September 2024 (UTC)[reply]
Tech News: 2024-39
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
All wikis will be read-only for a few minutes on Wednesday September 25 at 15:00 UTC. Reading the wikis will not be interrupted, but editing will be paused. These twice-yearly processes allow WMF's site reliability engineering teams to remain prepared to keep the wikis functioning even in the event of a major interruption to one of our data centers.
Updates for editors
A screenshot of the interface for the Alt Text suggested-edit feature
Editors who use the iOS Wikipedia app in Spanish, Portuguese, French, or Chinese, may see the Alt Text suggested-edit experiment after editing an article, or completing a suggested edit using "Add an image". Alt-text helps people with visual impairments to read Wikipedia articles. The team aims to learn if adding alt-text to images is a task that editors can be successful with. Please share any feedback on the discussion page.
The Codex color palette has been updated with new and revised colors for the MediaWiki user interfaces. The most noticeable changes for editors include updates for: dark mode colors for Links and for quiet Buttons (progressive and destructive), visited Link colors for both light and dark modes, and background colors for system-messages in both light and dark modes.
It is now possible to include clickable wikilinks and external links inside code blocks. This includes links that are used within <syntaxhighlight> tags and on code pages (JavaScript, CSS, Scribunto and Sanitized CSS). Uses of template syntax {{…}} are also linked to the template page. Thanks to SD0001 for these improvements. [1]
Two bugs were fixed in the GlobalVanishRequest system by improving the logging and by removing an incorrect placeholder message. [2][3]
The API now enables 5,000 on-demand API requests per month and twice-monthly HTML snapshots freely (gratis and libre). More information on the updates and also improvements to the software development kits (SDK) are explained on the project's blog post. While Wikimedia Enterprise APIs are designed for high-volume commercial reusers, this change enables many more community use-cases to be built on the service too.
The Snapshot API (html dumps) have added beta Structured Contents endpoints (blog post on that) as well as released two beta datasets (English and French Wikipedia) from that endpoint to Hugging Face for public use and feedback (blog post on that). These pre-parsed data sets enable new options for researchers, developers, and data scientists to use and study the content.
In depth
The Wikidata Query Service (WDQS) is used to get answers to questions using the Wikidata data set. As Wikidata grows, we had to make a major architectural change so that WDQS could remain performant. As part of the WDQS Graph Split project, we have new SPARQL endpoints available for serving the "scholarly" and "main" subgraphs of Wikidata. The query.wikidata.org endpoint will continue to serve the full Wikidata graph until March 2025. After this date, it will only serve the main graph. For more information, please see the announcement on Wikidata.
@Quiddity (WMF) and SD0001: Regarding this change to syntaxhighlight, what would be the effect on pages like Help:Link and Help:Transclusion? Such pages have many examples of how wikitext is used, wrapped in <syntaxhighlight lang="wikitext">...</syntaxhighlight> where the intent is to show the markup and not the effect of using double square brackets and double braces. Will this be controllable with an attribute? If so, it should be opt-in, in order to not break all of the existing cases. --Redrose64 🌹 (talk) 06:56, 24 September 2024 (UTC)[reply]
Links are only applied within text detected by the syntax highlighter as comments (<!-- ... --> for lang=wikitext). The change is already live – if you don't see any effect now, there is no effect. – SD0001 (talk) 07:20, 24 September 2024 (UTC)[reply]
Example made with <syntaxhighlight lang="wikitext">...</syntaxhighlight>:
<!-- [[Alice]] is in a wikitext comment with lang="wikitext" so it is linked. It still displays the link brackets. -->[[Boc]] is not in a comment so it is not linked.
// [[Carol]] is not in a wikitext comment so it is not linked. It is in a CSS/JavaScript comment so it would have been linked with lang="CSS" or lang="JavaScript"
@PrimeHunter I'm not seeing any links in that example. Is there some preference that might be overriding it? --Ahecht (TALK PAGE)14:58, 25 September 2024 (UTC) Never mind, refreshing the page made the link show up. Must've been a glitch. --Ahecht (TALK[reply] PAGE) 15:04, 25 September 2024 (UTC)
Do we have a bot to populate a category based on the same category in another wiki?
@Piotrus I think this could be straightforward for a bot to accomplish when both categories are single level, i.e only articles, but not when there are child categogies. If there are subcategories, then it's not trivial and a bot could be disruptive. Imagine if we could add Category:Archivists from Poland (Q7604592) to an article subject, and it would populate specific language editions under certain conditions. I am holding out for wikidata improvements to address this. Ironically this convo will get archived by a bot later ;) ~ 🦝 Shushugah (he/him • talk) 11:18, 27 September 2024 (UTC)[reply]
Most (if not all) browsers will centre-align table header cells by default: if left-alignment is desired, it needs to be explicitly stated. --Redrose64 🌹 (talk) 17:24, 24 September 2024 (UTC)[reply]
.infobox-label,.infobox-data,/* Remove element selector when every .infobox thing is using the standard module/templates */.infoboxth,.infoboxtd{/* @noflip */text-align:left;}
The table header cells concerned match the first and third selectors here, so the declaration is applied to these cells. I don't think that Common.css is loaded in mobile view, so this rule is not applied. --Redrose64 🌹 (talk) 07:29, 25 September 2024 (UTC)[reply]
I worked on this script years ago and it seems as if it has reached a mostly stable state. The script removes the "action=edit" from redlinks which essentially prevents the editor from auto-loading when clicking on non-existent pages that one has permission to create. I think this should be available as a gadget to allow for more configuration. Something like: Do not immediately enter editing mode when clicking on a red link.
It's hard to see why anyone would want it, even setting aside the fact it goes through every link on the page every tenth of a second. Nardog (talk) 12:45, 25 September 2024 (UTC)[reply]
@Awesome Aasim I haven't done much scripting around VE, but it seems like there should be a way to add an event listener to things like the VE preview window and only have it run when the content changes. --Ahecht (TALK PAGE)14:52, 25 September 2024 (UTC)[reply]
You wouldn't even need that; you can just attach an onclick listener to "a.new" elements and modify the href to remove &action=edit as they're being clicked, even if they've been dynamically added after page load. Writ Keeper⚇♔06:13, 26 September 2024 (UTC)[reply]
Actually, I change my mind. Doing this would cause stuff like "open link in new tab" to not function correctly. I do hope there is something smarter. AwesomeAasim06:15, 26 September 2024 (UTC)[reply]
No, it works with new tabs just as well as anything else:
I'm not sure why you would have redlinks outside of mw-content-text, but if that were a concern, you'd just choose a node higher up than #mw-content-text. Writ Keeper⚇♔06:25, 26 September 2024 (UTC)[reply]
If a subject page has no talk page, the talk page tab appears as a redlink; similarly, if a talk page has no subject page, the subject page tab appears as a redlink. These tabs are outside mw-content-text. --Redrose64 🌹 (talk) 16:28, 26 September 2024 (UTC)[reply]
I am taking a look at the requirements at WP:GADGET and it seems to meet all of them:
Gadgets must work if just included with no further configuration.: This script requires no configuration at all.
Gadgets must be compatible with all major browsers, i.e., they must not terminate with errors.: Just checked. Works in both Chromium and Firefox based browsers.
Gadgets should be functional in most major browsers (cross-browser compatibility). Exceptions must be clearly stated.: It is. The script works on most not all browsers. It uses the URL library which is supported by practically everyone.
Duplication of gadgets should only be made if it is reasonable.: This does not apply.
Collections of scripts should be split if they have disparate functions.: This does not apply.
Gadgets requiring permissions must be marked and must fail gracefully if the permissions aren't present.: This requires no permissions at all as it only affects the behavior of red links.
Gadgets only working in some skins must be marked as such if that data is available.: Irrelevant as it works on all skins, not just Vector and Timeless.
I don't see any requirement that the script needs to see widespread usage. I am not seeking to have this turned on by default at all. Those that want it can enable it in preferences. AwesomeAasim18:42, 29 September 2024 (UTC)[reply]
Consider this: either it's bug reports before you turn it on or it's bug reports after. Are you planning to fix them at all? Then we just have an unmaintained gadget instead. Izno (talk) 19:31, 29 September 2024 (UTC)[reply]
The last verified bug report I received was about interwiki links being broken by my script. That was fixed thanks to work by Matma Rex which I then implemented right after. The one after that complains that "action=delete" links are being removed, which does not sound right because this only touches red links. Not enough information was given for me to figure out where this was happening.
There definitely is some room for optimizations, especially since having three instructions on one line is... not ideal. But those are formatting and style fixes, not functionality fixes. AwesomeAasim19:52, 29 September 2024 (UTC)[reply]
Was the input box for Search the frequently asked questions in the help desk always this small? It has been squished by the button so much that it can't even display one character when I start typing.
That's messed up. I am able to reproduce it in Chrome. In Firefox, the search button text says "Search the freque...". I have worked around it by allowing the button to be on a second line. I wonder if something changed in the code for <inputbox>...</inputbox>. – Jonesey95 (talk) 00:57, 25 September 2024 (UTC)[reply]
Hmm, that's mw:Extension:InputBox? Doesn't seem like any related super recent changes there - there was an UI change in June though. I do not remember if Google Chrome ever displayed that search box correctly as I've only now paid conscious attention to it (and I don't frequent help desk, specially the top of the page, much).
After testing in preview at Wikipedia:Help desk/Header/sandbox, it seems that when I restore the break=no, even if I do width=500, or 50000, nothing actually changes from width=30...
Well, without the break=no it does resize past the 300 (and all the way off the side of the screen), a width=3 also has no effect. They do change a size attribute in the input box, but I guess because of what Izno said below it just has no effect when the button is in the same line? – 2804:F1...F5:930E (talk) 02:47, 25 September 2024 (UTC)[reply]
is what causes the issue today, since it's assuming that the table width containing the whole input box is "king", more or less. And it wants to display the content from the button more than the non-content in the form input.
(Without that CSS line at your browser, this naturally stretches the table to allow display of both the input and button. That's a feature of web tables but it causes issues in other ways sometimes.)
Two ways to fix it probably without asking for a change upstream. One is to make the side box bigger. I wouldn't generally advise this, since that has knockon effects for use in mobile. The other is to put the input and the button on different lines. Izno (talk) 02:29, 25 September 2024 (UTC)[reply]
Mobile view: expand all headings
Is there a gadget, user script or way to get a button to expand all headings in mobile view? It's annoying to have to manually expand them all when you want to do "find in page" or just simply want to see the whole article </MarkiPoli> <talk /><cont /> 11:44, 25 September 2024 (UTC)[reply]
Yes, there's an option for that on Special:MobileOptions (accessible via top-left menu → Settings). [For anyone else reading this, note that the option only appears when using the mobile mode, and only on small-screen devices, since on larger devices the headings are already expanded.] Matma Rextalk12:36, 25 September 2024 (UTC)[reply]
Wow, never realised that! Although it doesn't seem to be a "button", just an option saying to expand all headings. That's fine, but a button would still be useful. Maybe someone could write a user script? </MarkiPoli> <talk /><cont /> 13:37, 25 September 2024 (UTC)[reply]
¬
The latest run of Special:WantedCategories features another cluster of template-autogenerated nonsense, resulting from something that was done around {{WikiProject U.S. Roads}} within the past couple of days, rating articles for the importance level of "¬". Obviously that's not a real thing we actually expect to have, and this results from a coding or spelling error somewhere, but as that template imports things from an outside module I can't find the error to fix it as it isn't in the primary template itself. So could somebody look into making the following redlinked nonsense categories go away?
Having a discussion at this talk page to build a calculator using waist circumference and height as an index for body "roundness", which is based on eccentricity and used for anthropometric assessment in health research, first reported here.
A draft exists. Adjustments are needed to provide both metric and imperial inputs, and two decimal points, and any gadget assuring simplicity for public use. The completed calculator will be presented in the article. A commercial example is on this site.
Bold solution: a zero input interface, no waist, no height to input, yet still provide the desired BRI: a table with waist left to right, height top to bottom, BRI in cells.
The table was based on your "using waist circumference and height as an index for body "roundness", with waist and height being the two inputs and roundess the output.
You will have far more than 2 entries for both waist and height, hence the three dots.
The MDwiki asks for weight and height, not waist and height. Never mind, the idea is still the same: no input, do all computing in advance. No threshold, no effort required from readers. I've used your link to create the numbers for the example below, which will hopefully suffice to give you an idea for a similar table with waist and height as input.
An additional idea: take it one step further and answer the question that will be in the readers mind: Am I healthy?
Colour code the background, from green for healthy, via yellow to red for dangerous. A reader could look at the row close to own height and see multiple questions answered:
Is my weight/waist in green, yellow or red?
If yellow or red, what is the green value I should aim for?
Colour codes below are not based on real data, just an example.
80 kg
90 kg
... kg
180 cm
24.7 kg/m2
27.8 kg/m2
...
175 cm
26.1 kg/m2
29.4 kg/m2
...
... cm
...
...
...
An even bolder proposal that will probably rock your boat, but anyway, based on your metric/imperial question: Keep the calculator for the medics and target the general audience while on Wikipedia. Boldly omit the numbers in the cells and show both metrics and imperial in row and column headers. The table will still answer the question in the readers mind: what waist/weight is healthy for me, given my height?
80 kg
90 kg
... kg
175 lbs
200 lbs
... lbs
180 cm
6 feet
175 cm
... feet
... cm
... feet
That might even allow to use both weight AND waist in the column headers and answer two questions: given my height, what weight and waist is healthy? — Preceding unsigned comment added by Uwappa (talk • contribs) 06:49, 26 September 2024 (UTC)[reply]
As currently written this won't work in the official Wikipedia mobile apps or for anyone with JavaScript disabled or an older browser. This needs better fallback behaviour in my opinion before being enabled. [1] FWIW viewing it without the gadget I thought the page was broken and went to edit it.
It seems to print NaN if I enter a waist figure but no height - this seems like a basic error that should be fixed.
Switching between metric and imperial loses the form values - this doesn't seem like a very good user experience.
Perhaps there should be a clearer way to report bugs and some more context explaining it - that might be a case of simply adding a caption.
Hope this is helpful.
[1] Note that anything that uses a template gadget will not work for anyone consuming our content outside English Wikipedia so that's something to bear in mind e.g. Wikiwand, apps, Google etc.. . At minimum I think this should provide some error message saying "This interactive element is not supported by your device." 🐸Jdlrobson (talk) 00:44, 27 September 2024 (UTC)[reply]
For some reason, all clickable links that used to be gray have now become blue like normal links. This includes section links and the thank button, among other things. It also makes short descriptions blue when using the search feature. They are all still the correct color on the desktop version. Is this intentional, and if not, can it please be fixed? Thanks, QuicoleJR (talk) 20:46, 26 September 2024 (UTC)[reply]
It also affects the notification when redirected to a different page, which is now hard to read because it is blue (or purple after clicked) on a black background. QuicoleJR (talk) 20:50, 26 September 2024 (UTC)[reply]
Let me know if there are any issues not covered by the bugs above. If so, please be specific and at minimum include URLs and description of area, and steps you followed. If you can please provide a screenshot (you can use phabricator upload if needed).
I've raised a similar situation at Template:Unreferenced. This is because the templates use Template:Ambox. Creating an exact duplicate template just so other namespaces can be categorized is a horrible idea. Instead, the system behind categorization at the base level should be changed. The template shouldn't care which namespace it is placed on for categorization. Gonnym (talk) 09:53, 27 September 2024 (UTC)[reply]
@Anomie: Aha! So the capability already exists! So what I need to do is update the talk page of {{overcoloured}} to suggest replacing the use of {{DMCA}} with {{DMC}} or {{DMCFACT}} since I believe we would want to track all or most overcolored situations, not just those occurring on articles, and attempt to get consensus on that change to the template. Thank you! Considering this matter solved. Thisisnotatest (talk) 20:01, 27 September 2024 (UTC)[reply]
Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project.
The Wikidata itemsitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.
We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2.
More information can be found on the project page.
Permalinks always survive archiving, as they are links to a specific revision, for example this this is the permalink to the revision prior to my response. — xaosfluxTalk00:24, 28 September 2024 (UTC)[reply]
This question actually calls out one of the problems with organization of talk pages and any other kind of page that effectively tries to track multiple topics on a single page, particularly when they are used for the purpose of "cases" which have their own individual "lives". When you get a permalink, that lets you view the state of the page at some point in time. So if you get a permalink for such a page at some instant in time, you can see the case of interest at that point in time. You can link forward to the following version of that page, but there may have been no change to the case you're interested in. You might need to go through large numbers of versions for which the case you're interested in hasn't change. To find it just before it got migrated to an archive could have involved hundreds of versions. Of course, you can check the archive, but there could have been versions where content which was added but subsequently deleted, so you wind up having to look at numerous versions that did not affect the topic you're interested in. This is just an inherent limitation of the way that talk pages are managed. — Preceding unsigned comment added by Fabrickator (talk • contribs) 00:42, 28 September 2024 (UTC)<diff>[reply]
Confirmed. I'm looking for a link which will always link to the current state of the topic without regard to whether the topic has been archived or had subsequent updates. Thisisnotatest (talk) 02:45, 28 September 2024 (UTC)[reply]
@Thisisnotatest: It is presently in place, but relies on several factors. First, people must always make links to the thread using normal Wikilinks (i.e. [[Wikipedia:Village pump (technical)#Village pump permalinks?]]) and not external links (i.e. [https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Village_pump_permalinks%3F]), regardless of the page where those links are made. Second, the VP page must be set up for archiving by ClueBot III (talk·contribs) (this is the case for WP:VPM and WP:VPW but not for VPI, VPP, VPR or VPT which all use lowercase sigmabot III). Third, other forms of archiving (whether manual, script or bot) must not be used on the VP page. If all of these are observed, ClueBot III will fix inward links to threads as and when they are archived, see for example these edits. --Redrose64 🌹 (talk) 10:02, 28 September 2024 (UTC)[reply]
If you click on the timestamp for any comment, such as the first comment in a section, a link to that comment will be copied to the clipboard. When in future this section is archived, then when the link is followed, MediaWiki will display a popup message, with a link to the new location of the comment in the archive. See mw:Help:DiscussionTools § Talk pages permalinking for more details. (If you would like the link in wikitext format rather than an URL, you can try my user script to copy comment links to the clipboard to save you the work of adjusting the URL.) isaacl (talk) 05:02, 28 September 2024 (UTC)[reply]
It's a tradeoff. A link to an actual page version won't get affected by subsequent edits, while the new talk page comment permalink feature relies on the content not being deleted without being moved, and the relevant signatures not being modified, to gain the benefit of linking to a specific comment with later responses also being shown. isaacl (talk) 17:24, 28 September 2024 (UTC)[reply]
With window.popupPreviewFirstParOnly = false; in the browser console I see }} and below it the opening paragraph. Popups apparently misreads the complicated infobox as an opening paragraph only containing }}. {{ and }} are correctly balanced in the article. PrimeHunter (talk) 11:56, 28 September 2024 (UTC)[reply]
What happened to the categories at the bottom of articles on the mobile version of the site? You finally added them, then they disappeared for a while, then they came back, then they disappeared for good and that was years ago. Please bring them back and keep them there, there is no reason to not have them there and it is extremely inconvenient 2603:7080:8140:8A60:14E:FF29:2359:5592 (talk) 12:42, 28 September 2024 (UTC)[reply]
NewUsers now blue-linking everyone’s contribs pages
iOS Safari browser: NewUsers seems to have recently had a change so that all users’ contribs pages are blue-linked, whether they’ve made an edit or not. I foresee this increasing UAA reports that get a Wait until the user edits. response. Is there a way to get around this? MM(Give me info.)(Victories)14:45, 28 September 2024 (UTC)[reply]
If the user has no edits then the contribs link has the class mw-usertoollinks-contribs-no-edits in both desktop (tested in Vector legacy) and mobile, but only desktop has this CSS:
You linked the mobile site above and claimed to be on iOS. You cannot today select a skin for mobile website: you are always on Minerva. Izno (talk) 17:08, 28 September 2024 (UTC)[reply]
It was xaosflux who linked mobile but MM is probably there. "Advanced mode" is a feature of the mobile version at https://en.m.wikipedia.org/wiki/Special:MobileOptions. Mobile devices usually pick the mobile version by default regardless of your skin. You can switch at "Desktop" or "Mobile view" at the bottom of pages. If it says "Desktop" then you are currently on mobile, also called Minerva. PrimeHunter (talk) 17:15, 28 September 2024 (UTC)[reply]
If I open a new topic on a talk (such as I have just done here) the software won't let me abandon it. It wants me to finish it. Like, suppose right now I decided "enh this isn't right venue" and left the page discarding my work (or wishing to). Well if I come back to this page tomorrow, it won't let me start a new thread, or edit an existing thread, or even read the page. Nope. It's like "You started a thread yesterday. I'll take you there now! FINISH IT AND POST IT chum and then we can talk about what I'll allow you do to next."
Mind you this is after I have clicked the "OK" on "Leave this page? Your work will be lost" box (that is generated by Firefox not Wikipedia). There it is again when I come back. I can erase the text, but can't entirely erase the title ("You can't have a blank title!") nor delete the thread. I suppose if I were to drop dead it would start harassing my estate to finish the post, I don't know.
This is no good. Can this be fixed? Is there a workaround? Fixing would better as that'd mean future editors would not have to climb the draperies. Thanks. Herostratus (talk) 17:34, 28 September 2024 (UTC)[reply]
The yellow box that says This is only a preview; your changes have not yet been saved! when you preview your edit doesn't seem to be showing up for me. Instead, the message is just shown in plain text under the "Preview" header, which makes it seem like it is part of the actual text. Was this an intentional change? The box appears normally when signed out. InfiniteNexus (talk) 18:52, 28 September 2024 (UTC)[reply]
What it says on the tin. The Earwig is aware of this. Whenever anyone tries to use the tool, they get this message most of the time: An error occurred while using the search engine (Google Error: HTTP Error 429: Too Many Requests). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine.
Obviously, there's a bit of tomfoolery around hitting the limit, which is apparently shared by all users of Wikipedia. There was some discussion in the WMF section of the pump a few weeks back about what the WMF can do about it. I'm mostly interested in what we can do in the meantime while it gets fixed. I dream of horses(Hoofprints)(Neigh at me)00:56, 29 September 2024 (UTC)[reply]
You could do your own search engine search for snippets of text from the article. One sentence from each paragraph should give an indication of problems. And you can tick the box on the tool to limit the check. Graeme Bartlett (talk) 05:49, 29 September 2024 (UTC)[reply]
A heading beginning with a wiki comment removes MediaWiki interface "edit" buttons for that section
Demonstrated at testwiki:Sandbox/Section edit button. Notice 2 out of 6 sections have their "edit source" or "edit" buttons missing deliberately, when a section heading text is prepended with a wiki comment (see the page source). A wiki comment after a heading on the same line works, however.
I had to make an edit Special:Diff/1248413109 here at en.wiki to workaround this MediaWiki behavior, to restore said interface button. The lack of edit interface buttons in sections can be misinterpreted confusingly as a page being protected, particularly as an unregistered user.
Some Wayback Machine/Internet Archive links now failing?
I was doing some cleanup on Lockheed Martin shooting and came across an situation that I have never encountered before. The Internet Archive links at least on this article now seem to be failing. When I went to the saved URLs, the content that had been saved in the past came up in passing but then a different link/usurped content? for widgetbox(dot)com came up/took over. Has anyone else come across a similar issue? Is this just The Meridian Star news articles? And hey, for any of the lurkers around here who knows what's what etc, apologies in advance if I've possibly posted this issue in the wrong place, I just couldn't figure out where this might belong. No snark please, I just figured I better ask somewhere around here. - Thanks, Shearonink (talk) 18:02, 29 September 2024 (UTC)[reply]
I see entries since 22 September. The top right has a box saying "500 changes, 7 days" for me. Do you have such a box, what does it say and can you change it? PrimeHunter (talk) 20:22, 29 September 2024 (UTC)[reply]
Italic title doesn't work on Mickey Maguire (Shameless), DISPLAYTITLE does
Alternatively, changing the page title to the more general disambiguation of "character" removes the need for italics in the title. Izno (talk) 20:28, 29 September 2024 (UTC)[reply]
It is now possible to include clickable wikilinks and external links inside code blocks. This includes links that are used within 
. You could do all the computations behind it and create a similar chart for BRI. Uwappa (talk) 07:24, 26 September 2024 (UTC)
Wait until the user edits. response. Is there a way to get around this? MM (Give me info.) (Victories) 14:45, 28 September 2024 (UTC)
Works for me What is your skin and browser? --Redrose64 🌹 (talk) 20:26, 28 September 2024 (UTC)
