If you want to report a JavaScript error, please follow this how-to page. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 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. An offline spellcheck of all articles is run by Wikipedia:Typo Team/moss; human volunteers are needed to resolve potential typos.
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.
We’ve been working on a new feature to improve re-using references with different details: Sub-referencing. We have deployed the feature to most Wikimedia projects in the past 12 months, now we're ready to introduce sub-referencing to English Wikipedia.
What to expect?
You will notice footnotes like [1.1] in Wikipedia articles, if citations are used with different details (e.g. different page numbers) using sub-references. We are implementing a long-standing community wish: Many Wikipedia articles currently contain references that are almost identical but differ in details such as the page number. This leads to cluttered reference lists which make it harder for readers to quickly assess how many different sources have been used. And unlike with identical reuses, re-using references with different details previously required duplicating the reference, which led to longer wikitext and – especially in VisualEditor – also to more time expenditure. Existing community-created workarounds like {{sfn}} have drawbacks for VisualEditor users and for readers using reference tooltips (especially for mobile readers – more about the problem).
Sub-referencing solves these issues: We are adding a new reference attributedetails="..." – similar to the existing name="..." attribute, allowing re-uses like <refname="Example"details="p. 2"/>. VisualEditor users can use the "add details" button to insert sub-references. You can find detailed instructions on our project page. We also published a report about our learnings on the first months of sub-referencing on German Wikipedia which you might find interesting. Note that sub-referencing is an optional feature, you can continue using other citation styles if you prefer to do so per WP:CITEVAR.
Deployment
We’ll deploy sub-referencing to English Wikipedia on October 14 (phab:T440243). If you want to try the feature already you can do so on testwiki (example page) or almost any other wiki, e.g. French, German, Spanish or Simple Wikipedia.
Please let me know if you have any questions. We look forward to your reactions about the new feature, either on our discussion page, my user talk page, or as a reply to this announcement. We will continue improving sub-referencing based on your feedback!
I got to wonder if {{subref}} needs |volume= and |issue=. If those are needed then {{subref}} must be able to render them as {{cite journal}} does and as {{cite magazine}} does. For journal and conference cites, {{subref}} must support |article-number=. Probably need support for |mode= so that the details are rendered in a way that appropriately matches the long-form reference rendering. Do we create lists of parameters that make sense for the subref's parent template? For example, {{cite book}} does not support |issue= so a subref of a book cite ought not support |issue=. I'm wondering if there ought to be multiple subref templates: {{subref book}}, {{subref journal}}, {{subref news}}, etc.
No doubt there are other things I haven't thought of yet.
It would be great if there was a standard way to add page-specific urls, to help with WP:V. I understand that a |page-url= parameter is probably not included in {{Cite book}} etc. in case |pages= contains a page range, but I wonder if a bunch more page-specific parameters might be helpful for {{subref}} – for example |pages-from1=|pages-to1=|pages-from-url1=|pages-to-url1=, |page2=, |page-url2= up to |pages-fromn=|pages-ton=|pages-from-urln=|pages-to-urln=, etc. in a similar way to |author1-first=|author1-last=|author1-link= to |authorn-link= --YodinT20:20, 7 October 2026 (UTC)Reply
Was also wondering: wouldn't journal and magazine articles all be cited separately, rather than as sub-references treating the journal/magazine title as the main ref? The only case I can think of at the moment where |issue= might be a valid subref is for serialised works published across several issues and sometimes volumes of a magazine, but I think it would be very rare to cite these, and it might be worth treating these as separate refs, as each issue would have a different publication date. |volume= seems different to me, as it could easily be a valid sub-ref for books (though maybe using subrefs should be discouraged if the volumes were published in different years or had different ISBNs, etc.?). --YodinT20:41, 7 October 2026 (UTC)Reply
I agree with @Yodin in that I could see |volume= being useful for books such as In Search of Lost Time or Modernist Cuisine that are published as a single edition with multiple volumes, but the more I think of it, I can't think of a situation in which multiple issues, nevermind volumes, of a magazine or journal would be combined into a single reference. I went ahead and remove |issue= from {{subref}}. --Ahecht (TALK PAGE)15:13, 8 October 2026 (UTC)Reply
The problem statement is false. It has long been possible to re-use existing references with page number by having separate "references" and "sources" sections (or whatever specific naming you prefer, it could be "notes" and "references", correspondingly). This existing pragma has the advantage that the "sources" section doubles as a "further reading" or "bibliography" section (the latter of which it is also sometimes called), without an extensive listing of page numbers being contained within that same section. ~2026-53857-27 (talk) 15:37, 8 October 2026 (UTC)Reply
The problem we've been working on is that mw:Extension:Cite allows for an easy way to re-use references (<refname="example"/>) while there wasn't a similar way to re-use references with different page numbers. Over the years different wikis have created various workarounds (e.g. templates like {{sfn}}, {{harvnb}}, {{rp}}... manually created shortened footnotes or just creating almost identical references) but most of these have drawbacks, e.g. for readers (unexpected behavior in ReferenceTooltips / incomplete reference information in the mobile reference pop-up), for VisualEditor users (template-based workarounds offer a bad user experience for VE users) or for users translating articles (none of the template-based workarounds exists across all wikis). Of course editors can continue using their preferred citation method per WP:CITEVAR if they prefer whatever workaround their wikis has come up with. Johannes Richter (WMDE) (talk) 16:30, 8 October 2026 (UTC)Reply
I'm still waiting to be shown how this can give me a clean print-out of a bibliography without all the extraneous page numbers in it. Harvard format is really the universal standard for that. ~2026-53857-27 (talk) 15:35, 9 October 2026 (UTC)Reply
This is a strawman if ever I saw one. The people who may later need the bibliography to be in the correct format will typically not be present when the change might be discussed. This proposal seems to be solving one problem while creating another, and that's just going to lead to conflict down the line when someone inevitably declares this to be the "correct" solution and builds a bot that converts every article to the "improved" format that isn't. So the time to call a STOP to this is now, not later. So if my understanding is correct, this needs to go back to the drawing board until a reasonable solution can be presented. Right now, this seems designed to obfuscate and make bibliographies difficult to use for our most diligent contributors. Why, of all people would you be singling them out for grief? ~2026-53857-27 (talk) 23:31, 9 October 2026 (UTC)Reply
I believe you already made it clear on German Wikipedia that you don't like sub-referencing. We've intentionally modeled sub-references close to the way regular references are displayed (where page numbers aren't hidden as well). Even if we wanted to we couldn't just hide sub-references given that they might contain other details as well, not just page numbers (e.g. quotes ). Noting that external research suggests that most readers don't read the reference list , that's why the pop-up when hovering over a footnote is certainly more important to display the full reference information. However we are thinking about possible improvements to the reader view and on of the suggestions we've received is making it possible to toggle sub-references in the reference list, similar to the user script proposal from isaacl below. Johannes Richter (WMDE) (talk) 06:10, 10 October 2026 (UTC)Reply
No, we have not met before. If you're hearing the criticism for the second time, maybe you should take it seriously. I will ignore your attempt to put words in my mouth as well as the irrational parts of your arguments, as that doesn't lead anywhere good. I think I've made it clear that my priority is to avoid creating new problems as a result of ignoring established use cases. I stand by my opinion that offering a Harvard option is a VERY GOOD IDEA(TM). ~2026-54835-70 (talk) 23:07, 12 October 2026 (UTC)Reply
Looking at the example to which Johannes Richter linked, it seems the subreferences are in a list with the mw-subreference-list CSS class. Anyone interested in hiding the subreferences can add a rule to their personal common.css file to hide elements with that class. If there's enough interest, maybe someone will write a user script that allows the subreferences display to be toggled. isaacl (talk) 02:52, 10 October 2026 (UTC)Reply
@Isaacl: Thanks for the suggestion. What that would require is either (a) an account, which we've always said we won't force people to have, or (b) an external tool like Greasemonkey, Stylish etc., or manipulation of the browser's built-in style files. (b) introduces an additional technical hurdle (or, worse, forcing use of a third-party plugins we can't vouch for), which in both cases is something we should avoid. ~2026-54835-70 (talk) 23:14, 12 October 2026 (UTC)Reply
It is 100% reasonable that some features are only available to readers who create accounts. Those without (no-account or TA account) need to be able to read, but Wikipedia:Why create an account? notes "Use custom preferences to change the look and behavior of Wikipedia and how it works for you. Temporary accounts can only change certain basic display settings." DMacks (talk) 01:03, 13 October 2026 (UTC)Reply
Nothing would be changed retroactively by the change. Editors could, however, make edits because of the update which could change the look of logged-out viewing– but this is the case for pretty much every new feature which could affect appearance (with a way to opt-out) on Wikipedia. Axolitl(talk|contribs)05:09, 13 October 2026 (UTC)Reply
I find myself unable to relate what you're saying to what's being proposed. What's being proposed is introducing a new referencing system that could potentially lead to a battlefield at every single existing article that already has a working referencing system, or a wiki-wide change of all such articles. This would make sense if the end result were increased flexibility that would allow previous modes to be switched to. As it stands, this proposal could lead to a lot of upset, and it's difficult to understand why one wouldn't go the extra mile to make this work for all use cases (and hence users), including those that would prefer Harvard output. I see this as part of a broader struggle against AI use, where this move would discourage people from taking a list of references and seeking out the actual original sources (e.g. in a library). The consensus I get from reading down VPT is that we don't want to make changes that predispose us to AI volition and weaken the influx of information from paper-bound sources. ~2026-54835-70 (talk) 05:30, 13 October 2026 (UTC)Reply
It would be interesting to hear if any other wikis have developed templates specifically designed to go in "details=", that would be worth considering using here as well. CMD (talk) 05:49, 13 October 2026 (UTC)Reply
We've seen some wikis (especially German Wikipedia) using existing templates within details="...", most notably the equivalents of {{cite web}}, {{cite book}}, {{Webarchive}} and {{Google books}}) . Some right-to-left language wikis like Hebrew Wikipedia are considering to use {{Refn}} to create sub-references (because hewiki generally uses Refn-style templates to avoid <ref> tags, which are left-to-right).
We haven't seen any other wiki creating something like {{Sub-reference}} (despite community members creating and testing such templates on betawiki – which inspired us to mention it on our project pages). It seems like most wikis don't see a need for a subref template as long as they only use sub-referencing for page numbers. Once wikis start using the feature for other kinds of details (e.g. quotes, chapters or audio timestamps ]) a template might be more helpful. But dewiki and plwiki (the two wikis using sub-referencing the most) both use „“ as quotation marks – no issue doing that in plain text. Meanwhile projects like English Wikipedia that use " might be more interested in using a subref template because you can't use another " within details="...". To avoid this limitation one could either use <refname='Example'details='"Quote"'/> or use a template to produce quotation marks in reader view like <refname="Example"details="{{Sub-reference|quote=Quote}}"/>. Johannes Richter (WMDE) (talk) 07:03, 13 October 2026 (UTC)Reply
I have a minor technical issue below, but the other feedback I have is that it is very awkward not to be able to name subreferences. If I reuse a subreference, I want to define the details once and then call it by name. Instead, having to specify the details repeatedly is a recipe for getting them out of synch with each other. —David Eppstein (talk) 19:42, 16 October 2026 (UTC)Reply
Thanks for your feedback! It's something we considered when creating our initial prototype for sub-referencing but we had to make some changes to the syntax to make sure sub-references works flawlessly in VisuaEditor while using {{reflist}}. The new syntax comes with the drawback of not allowing to name sub-references and re-using them just by name. It's similar to {{sfn}} which also require copy+pasting to create a re-use. Note that VisualEditor users can use a checkbox to either change all identical sub-references or just the one they're currently editing when they're making changes to a "re-used" sub-reference. Johannes Richter (WMDE) (talk) 10:51, 19 October 2026 (UTC)Reply
When the main reference of a subreference is list-defined, and never used as a bare main reference, we get a reference number followed by an unlinked caret character in its entry in the references section, like "1.^ Author. Reference." Maybe in this case the caret should be omitted, since there is nothing in this specific place for it to point upwards to? (We do also get unlinked uparrows when a ref is used multiple times without subreferencing, but in that case the uparrow makes sense, because it is followed by a sequence of links.) —David Eppstein (talk) 19:38, 16 October 2026 (UTC)Reply
Thanks for trying the feature and sharing your feedback! We've indeed chosen to keep the arrow similar to re-used references where it is unlinked as well. There are articles that use both sub-reference and the main reference (e.g. if the page number is unknown for one citation) – in that case you do need the arrow. I believe it would be visually confusing to readers if the arrow is visible in certain situations but not in others. Johannes Richter (WMDE) (talk) 10:37, 19 October 2026 (UTC)Reply
Latest comment: 17 hours ago16 comments8 people in discussion
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
Starting October 13, wikis can change the default pattern for auto-generated reference names in VisualEditor (currently <refname=":1"/>). They will be able to use human-readable, content-based reference names that are more helpful to contributors using the source editor (e.g. <refname="Miller2026-1"/>). VisualEditor reference name patterns can be defined using MediaWiki system messages, JSON, templates and modules (more information). Admins can enable these changes via community configuration. This is a community wish implemented by WMDE Technical Wishes.
Sub-referencing is a new MediaWiki feature that allows editors to reuse references with different details. It will be deployed to English Wikipedia on October 14 and to remaining Wikimedia Foundation wikis by end of October (likely October 21). The FAQ lists possible actions to take on your wiki to support the deployment. This is a long-standing community wish implemented by WMDE Technical Wishes.
Updates for editors
Moderator Tools will be removing the list view of the Watchlist and defaulting everyone to the changelog view. Previously, there were two versions of how the Watchlist is shown to mobile web users: the list view, where editors could see watched articles in a list format, and the changelog view, where editors could see changes to watched articles in a log format, controlled by a user's Advanced Mobile Control settings. This has created issues for code-base maintenance: two different displays means two sets of code to manage. By defaulting to the changelog view, we are simplifying the codebase and avoiding the likelihood of missing bugs.
The Wikipedia Android app is testing a way to listen to article introductions in the “For you” feed. A text-to-speech model reads the existing article text aloud without rewriting it or adding any content. The 30-day experiment will begin in the Wikipedia Beta app during the third week of September, then move to the regular Wikipedia Android app in October for a limited group of eligible users. A small portion of app users (those with English feeds and at least one topic interest) will have access to the feature. This experiment is part of broader efforts to give app readers options in how they consume content in order to deepen engagement and user retention. Learn more and share feedback.
CodeMirror syntax highlighting was enabled by default for all logged out and newly registered users on the English Wikipedia on September 14. With no signs of adverse effects, the same change is being proposed to be made globally across all wikis in a few weeks. If you have concerns or feedback, or if your wiki would like to opt out, please see the help page.
Last week, language link changes were removed from Recent Changes and Watchlist feeds on Wikivoyage, Wikisource, Wikiversity, Wikiquote and Wiktionary. As no adverse effects have been observed, the Wikidata For Wikimedia Projects plans to roll out this change globally to all Wikipedias. This is scheduled for October 13 at 07:00 UTC, after which editors will no longer see when a link to another language version of a page is added, removed, or changed in its Wikidata item. Editors who rely on these notifications can read more on the project page and share feedback or ask to opt out their wiki on the talk page.
View all 28 community-submitted tasks that were resolved last week. For example, an issue where accidentally touching the graph while scrolling on the Pageviews tool on mobile could unintentionally zoom in has now been fixed. Click-and-drag zoom is now disabled on touch devices.
Updates for technical contributors
There are three major changes coming to dumps: the legacy content dumps deprecated in January 2026 will now be sunset, the replacement MediaWiki Content File Exports will be delayed to implement a “safety buffer”, and they are now also available as 7zip-compressed files. Users will need to switch the URL they download their dump from. For more information, timeline and migration instructions, see Legacy content dumps sunset.
The Wikimedia Foundation discovered unauthorized activity by OpenAI agents on Wikimedia projects, including edits to wikis, attempts to exploit a public note-taking tool, and heavy automated traffic. Read the blog post on Diff for more details about the activity and the Foundation’s response.
Meetings and events
Save the date for the next Wikimedia Hackathon! We’ll be meeting in lovely Tirana, Albania for the 2027 Wikimedia Hackathon from April 9–11, 2027. Scholarship and staff sponsorship applications are currently being accepted through Pretix and will close on October 30, 2026. General registration will open in January 2027.
French Wikipedia implemented a template that uses a module to extract ref names from citation template parameters: fr:Modèle:NomRefAuto & fr:Module:NomRefAuto. I've created a simpler version at testwiki a couple of days ago: testwiki:Template:Autoname & testwiki:Module:Autoname which also does a good job in extracting last name + year from citation parameters (e.g. ). You might want to take a look at these examples. But our implementation was inspired by enwiki's way of generating CITEREF via Module:Citation/CS1 so you might already have some very advanced code that can be re-used for generating VE reference names. Johannes Richter (WMDE) (talk) 15:44, 13 October 2026 (UTC)Reply
If this is for creating ref names that are the same as cs1|2 anchor IDs from inside of ve, perhaps use the Module:Footnotes implementation of {{sfnref}}:
ve could feed {{sfnref}} with up to five positional parameters: up to four 'contributors' (|contributor-lastn=) or up to four author surnames (|author-lastn=) or up to four editor surnames (|editor-lastn=) and the year portion of the publication date. Do not mix contributor / author / editor names. My example here does not account for parameter aliases.
Because it amused me to do so, I have hacked Module:Citation/CS1/sandbox so that it will emit a CITEREF anchor ID when given a minimal set of appropriate parameters. The parameters are:
|contributor=, |contributor-last=, |contributor-surname=; |author=, |author-last=, |author-surname=, |host=, |subject=, |surname=, |last=; |editor=, |editor-last=, |editor-surname=; and, of course, their enumerated forms; |vauthors=, |veditors=; one of |date=, |year=, or |publication-date=. cs1|2 requires |title= for proper operation, but that title can be anything except nil or empty string.
{{#invoke:Citation/CS1/sandbox|autoname|title=spoof title |vauthors=Greene AB, Blue CD, Red EF |date=13 October 2026a}} →
(commented; feature has been removed from the module)
names can be wikilinked:
{{#invoke:Citation/CS1/sandbox|autoname|title=spoof title |author=[[Abraham Lincoln]]|date=1863}} →
(commented; feature has been removed from the module)
To make this usable will require a significant amount of work: what to do when editors mix name list style (Vancouver with last/first for example); what to do when editors skip an enumerator: last1, last3, last4; no doubt there are other conditions that are detected by cs1|2 as errors. How are such errors to be communicated to editors so that they can be repaired? What to do when cs1|2 doesn't create a CITEREF anchor ID (no names)?
I don't think there's an opportunity to communicate errors to editors, so we'd have to wrap it in some sort of error checking that will fall back to the default (e.g. Book-1, Website-1, Reference-1) when there's an error. --Ahecht (TALK PAGE)14:06, 14 October 2026 (UTC)Reply
Thanks, updated the bot with those patterns. If it changes again, I'd appreciate if someone lets me know again on the bot's talk page. Anomie⚔22:49, 15 October 2026 (UTC)Reply
If it might be useful, you can see my work at ru:Module:Autoname (or any of the other languages linked there!) to account for any other potential issues. The big one I saw myself was HTML inside parameters, but your example seems to handle it well since I think you’re grabbing the contents of the first link instead (but note that this can lead to some unwanted output, too, like categories or something leaking into the name). stjn20:43, 15 October 2026 (UTC)Reply
@Stjnen:Module:Autoname uses mw.uri.anchorEncode() takes care of stripping out wikilinks and HTML markup. Worst case is Foo[[Category:Bar]] would get reduced to FooCategory:Bar, but I think that that's an unlikely enough case not to worry about. --Ahecht (TALK PAGE)20:41, 22 October 2026 (UTC)Reply
I am going to 'unhack' Module:Citation/CS1/sandbox because I don't think that that module should be used to create reference names. Instead, I have created Module:Autoname which uses some native code from Module:Citation/CS1/Utilities and Module:Citation/CS1/Configuration along with adapted functions from Module:Citation/CS1. The adapted functions have been modified so that they do not create error messaging and the attendant maintenance or error categories.
The module supports all contributor / author / editor name-holding parameters including |vauthors= and |veditors=. Because names may be wikilinked and may be wrapped in the accept-as-written markup, those markup when present are safely removed. The module implements {{autoname/sandbox}}. Examples of its output can be seen at Template:Autoname/testcases.
It also still has that unfortunate two-column format, which means a lot of empty white space on narrow screens or (as I encountered it) in a {{sidebar}} template.
Could someone please reformat that to not use one table column for the icon, and then all the other content (mostly a bulleted list) in a second table column? WhatamIdoing (talk) 17:14, 13 October 2026 (UTC)Reply
I've drafted a version in the sandbox that doesn't use a table. The output is not exactly identical but it doesn't use table columns to indent the list. See the testcases. They seem similar enough on my end on desktop and mobile view, but I'm not using an actual mobile phone and can't narrow the window enough to cause a problem even with the live version. Please check if sandbox is an improvement on your end. If anyone has a better solution or can improve the sandbox version, please do so. – Scyrme (talk/solidarity) 18:26, 13 October 2026 (UTC)Reply
One issue with my sandbox version is that when Here are some tasks awaiting attention wraps onto a second line, it wraps underneath the image rather than staying next to it as it does with the live version. I'm unsure if that can be fixed, but it might be minor enough to not matter. – Scyrme (talk/solidarity) 18:39, 13 October 2026 (UTC)Reply
Another issue is that there's a bigger gap between the Here are some tasks... and the task list. I'm not sure if it's possible to remove it. If anyone know how, feel free to edit the sandbox! – Scyrme (talk/solidarity) 15:58, 14 October 2026 (UTC)Reply
I'd like it to not indent the list of items. My goal is:
@WhatamIdoing: I've added an |indent= parameter to the sandbox version that can be set to "off" (no indent at all; usable both with or without image) or "min" (same indent as used when there's no image; "min" only usable when |image=off). I've add more testcases to illustrate. – Scyrme (talk/solidarity) 18:54, 13 October 2026 (UTC)Reply
I like the aesthetic appearance of the "min" best, though my personal preference isn't important.
Are we sure that {{Testcase table}} works correctly? In some of them, the Here are some tasks awaiting attention: text in the first template appears to push the text in the second template out of place, so that the end of that text is above the bullets for the next line. WhatamIdoing (talk) 19:05, 13 October 2026 (UTC)Reply
@WhatamIdoing: You mean how it appears for testcases 5 and 6? The {{testcase table}} is working correctly; that's just where the bullet points end up when there's no indent. It's apparently due to margin: 0px;, which was part of the original code which I left unchanged. – Scyrme (talk/solidarity) 15:48, 14 October 2026 (UTC)Reply
I've simplified the code to remove it and adjusted the indents. The indent parameter is now only used when the image is enabled. When the indent is off, it now lines up with a standard bulleted list. – Scyrme (talk/solidarity) 15:55, 14 October 2026 (UTC)Reply
Latest comment: 7 days ago16 comments8 people in discussion
Knowing who is writing to whom in a discussion is important. Especially if many different people are taking part in one. Unfortunatly mobile doesn't offer enough display to always quickly check the bottom of a message, which makes keeping track quite bothersome. Wouldn't it be beneficial to move names above their respective reply, like in most other text messaging layouts?
I can see how one might find aesthethic value in our current arrangement, especially if one is using a desktop or laptop, where i would wager that this is much less of a problem. I suggest a preferance setting as a solution. Willprove (talk) 00:56, 14 October 2026 (UTC)Reply
I don't really have this issue as someone who reads a lot on mobile, but if this was implemented it would most likely be part of DiscussionTools, an extension which provides numerous improvements for talk pages. Considering the Community Wishlist is coming up soon, you may want to try creating a wish for this feature. Axolitl(talk|contribs)01:03, 14 October 2026 (UTC)Reply
@Willprove: This would make English Wikipedia inconsistent with all the other Wikipedias, not to mention the other WMF projects like Wiktionary and Commons - of which there are more than a thousand. Signing at the end of your post is a practice that has been established for more than 25 years. --Redrose64🌹 (talk) 07:22, 14 October 2026 (UTC)Reply
I do not know see why that would stop us. We have made changes before that disturbed the consistency of all wiki projects, like dark mode; for quite a long time English wikipedia alllowed one to toggle a preference for dark mode that was not possible on other language projects, or sister projects.
The German Mainpage differs from the English. There are policy differences between different languages. Visual elements and conventions differ, for example infoboxes looking different between German and English. German wiki has a user trust system. We just changed wikipedia's look in 2023 i think, and one can still go back and change it back for oneself at will. Visual editor has just become the universal default editor. Mobile wiki looks generally different from desktop already.
I don't think that there really exists an established tradition of aesthetic continuity in the way that you see it. And if that exists i would call into question it's inherent value and our ability to abide by it so far, which would be pretty lousy.
I don't think adding a little button that would allow one to more easily keep track of long talk page conversations, especially on small screens, would be pose a new convention that disrespects tradition or poses some problem. It would be a neat little thing. It would be useful. Willprove (talk) 14:18, 14 October 2026 (UTC)Reply
@Willprove: Things like dark mode are done mainly through style sheets. The arrangement of the main page is decided on a per-wiki basis, but essentially it's a bunch of templates that draw their content from subpages like Wikipedia:Today's featured article/October 15, 2026. Infoboxes are much more fragmented - for example, our own Template:Infobox person places birth and death stuff near the top, whilst Template:Infobox officeholder puts it much further down. It would be an easy edit to rearrange either of those two infoboxes to have the info in similar places. However, in discussion pages, such as this one, the user info and timestamp are part of the wikitext itself, and there are no style sheets on earth nor template edits that will rearrange signature-last wikitext to display the signature before the rest of the post. --Redrose64🌹 (talk) 22:14, 15 October 2026 (UTC)Reply
I see. How does something like WP:CONVENIENT work. Is it only possible to have something like it work through client-site plugins? Can't we universalize the code so it works well on mobile and just have it apply if one wants it to? It might be a bit more complicated, but then our issue wouldn't be consistency, it would be feasability, or desire. Willprove (talk) 23:02, 15 October 2026 (UTC)Reply
I've never looked at the implementation of the Convenient discussion script, but I imagine only the UI portions are dependent on the skin. It should be feasible to support more skins, but that doesn't mean the change would be easy to make. I'm not sure what you mean by "a little button". I think the UI design challenge is fitting the meta info into the available space on small screens without unduly increasing the amount of vertical space used. (Moving the signature is tricky, because even with the extra markup now added by the discussion tool feature, it's still hard to isolate, so it's less error-prone to keep it where it is.) isaacl (talk) 02:46, 16 October 2026 (UTC)Reply
FWIW, I support this idea. For example, I’m on mobile right now, and the comment in this thread beginning with “I do not know …” took up the entire screen and required scrolling just to identify the author of the comment. I should not have to assume or guess who wrote a comment before reading it… that feels backward. Some1 (talk) 23:03, 14 October 2026 (UTC)Reply
Signatures being at the end of messages was, my guess, an explicit decision to try to help focus on content and not contributors. MetaFilter, another older Internet place, explicitly did that and has explicitly kept it so. I'm sure user scripts could be adjusted to allow this for mobile as an opt-in thing if you choose to but I probably wouldn't want to make it as simple as an option in the default preferences. And I say this as someone who uses both desktop and mobile. Skynxnex (talk) 23:31, 14 October 2026 (UTC)Reply
On a more basic level, wikitext was designed for pages, not as a discussion forum mechanism. Online forums typically have a dedicated location for information about the commenter. With wikitext, prior to the autosigning reply tool, we just have what is done by convention. Usenet posts and emails are conventionally signed at the end (though they too have a dedicated location for the header information in a communication), so it was natural for the community to follow this approach. isaacl (talk) 23:52, 14 October 2026 (UTC)Reply
On my end I only see 1 template and its documentation. I imagine {{Get short description}} is there because of its documentation. I suspect the documentation is there because Canada is a featured article and the example used by the documentation is {{Get short description|Canada}}. The template is just a wrapper for the module, so something about the module is causing this. Previewing the documentation in edit, the "pages included in this preview" list beneath the editing area includes several templates found on Canada not just {{Featured article}}, including {{authority control}} and {{Current UK monarch}}, though not every template (the citation templates aren't listed). Removing {{Get short description|Canada}} removes all these templates from the list. I don't know whyModule:Get short description causes this, but hopefully this information is helpful in figuring that out. – Scyrme (talk/solidarity) 20:47, 14 October 2026 (UTC)Reply
The module calls frame:preprocess(wikitext) which will process the text of the article being parsed, including recording links to the templates it uses. So Template:Get short description/doc is recorded as using all the templates Canada uses, including {{Featured article}}. It's hard to see how the module can work without doing this. Parsing just the {{short description|whatever}} bit would work for Canada, but in general it won't pick up SDs generated by templates such as infoboxes. Certes (talk) 22:09, 14 October 2026 (UTC)Reply
Template:Featured article/doc says, "This template should be placed at the top of the article after hatnotes." However, in Canada, the template appeared before several header templates that precede hatnotes. I edited Canada and moved the template to follow all of the header stuff, just before the infobox. It doesn't look like that is going to fix it, because, even after the change, if I edit a sandbox to consist of one line, viz:
@Anomalocaris: It's not surprising that repositioning {{featured article}} doesn't make a difference since it's also pulling other unrelated templates from all over the page (due to what Certes explained). If Certes is right that there's no way to rewrite the module to avoid this, the only way to truly fix this problem would be to request that the GETSHORTDESC extension be installed/enabled (or something equivalent) so that the template can be redesigned as a wrapper for that instead of the module. – Scyrme (talk/solidarity) 06:02, 15 October 2026 (UTC)Reply
The search results page has now cleared! The template seems to still work as intended after the change in module code, with the template fetching the description from Wikipedia (not Wikidata). – Scyrme (talk/solidarity) 07:00, 15 October 2026 (UTC)Reply
Well done! How (if at all) did you manage to get at a SD generated by an infobox or similar without preprocessing the whole article? That's the bit I claimed would be hard. Certes (talk) 22:55, 16 October 2026 (UTC)Reply
@Certes: To be honest I initially forgot that was an issue. The revised module by Trappist isn't able to do that. However, after I copied over Trappist's code I found a different template that also outputs short descriptions, {{Extract short description}}. That one just uses Module:String instead of a whole new module. {{Extract short description}} has the same problem that the previous version of {{Get short description}} did, in that it also transcludes the target page. It's probably helpful to leave the two templates as they are now. For most cases, {{Get short description}} works fine without the issues caused by preprocessing the whole article. Editors who need to fetch a short description that's transcluded into an article by an infobox (etc.) can use {{Extract short description}}. For now, I've just updated the documentations of both templates to make their respective limitations and differences clearer. Editors can choose the one that suits their needs. It might still be a good idea to request the GETSHORTDESC extension be installed/enabled (or equivalent) to make both templates obsolete. – Scyrme (talk/solidarity) 23:17, 16 October 2026 (UTC)Reply
Scyrme, hi, sorry about not replying to the ping earlier. I saw the notification but set it down to look at later and totally forgot about it. Anyway, I wrote {{Get short description}} to see if there was a way to get all short descriptions, including ones transcluded by templates. Unfortunately it seems that it always carry over the categories etc. from the target page, and as Certes says above there doesn't seem to be a way around this, so I gave up on it. If it's causing problems I don't have any issue with the template and module being deleted. —Qwerfjkltalk09:15, 18 October 2026 (UTC)Reply
Latest comment: 8 days ago3 comments2 people in discussion
This page Draft:Blackboys causes my browser tab to lockup on both Safari and Chrome when I try to edit it. It's something technical with the page because no other page I've every come across does that. Weird. Any ideas? 10mmsocket (talk) 06:43, 15 October 2026 (UTC)Reply
Does it lock up in Visual or Source editing? While loading or after typing? Does it still lock up in an incognito window? (Maybe it’s a gadget you have) Dw31415 (talk) 10:14, 15 October 2026 (UTC)Reply
While I was editing a few minutes ago, editing the source box suddenly gave line numbers showing up spontaneously at the left-hand side of the editing box. When I clicked on the emacs button (plugin) to use emacs to edit the text as plain text, a huge amount of html/xml-like tags appeared in the source content, completely swamping the wikitext.
This sort of change should be opt-in, not opt-out.
I managed to kill this tag-nonsense by going into:
Preferences
Editing
Syntax highlighting
disable Enable syntax highlighting for wikitext - Applies when editing content pages and templates.
I just clicked the "Syntax" button at the top of my editing toolbar ('2010 wikitext editor') but agree that this should be opt-in not opt-out. - Arjayay (talk) 08:34, 15 October 2026 (UTC).Reply
I see this too, in both normal editing and replies. CodeMirror syntax highlighting was enabled by default for all logged out and newly registered users on the English Wikipedia on September 14. Further details: WP:Tech News#Tech News: 2026-42. Perhaps it's been quietly and/or accidentally rolled out to everyone now (because the WMF knows best). I'll give it a try as it does have uses but, as mentioned above, it can be turned off in Special:Preferences#mw-prefsection-editing. Certes (talk) 09:22, 15 October 2026 (UTC)Reply
Thanks for finding this workaround. I was editing a page, did something else in another browser tab, Firefox crashed, and when I came back and looked at the recovered editing tab, I suddenly had line numbers, highlighted text, large-font headings, and most irritating of all, the search-in-page didn't work. That is, I could CTRL-F for <some text>, and it would be found for all occurrences in the article preview, but I could not find anything by searching in the wikitext. Quite maddening. After an hour of grumbling, testing, and looking here, I can now return to whatever I meant to do next. Thanks again! —JohnFromPinckney (talk / edits)10:50, 15 October 2026 (UTC)Reply
That's odd - I have it intentionally enabled and it's never affected the editor search function for me. The only thing that fails sometimes for whatever reason is the ping autocomplete. I just toggle it in editor, add the tag, and and turn it back on. ChompyTheGogoat[Bleat|Munched]15:34, 15 October 2026 (UTC)Reply
ChompyTheGogoat and JohnFromPinckney, it seems that you are talking about two different text search features. CodeMirror has a search and browsers have a "builtin" search. If you have CodeMirror enabled, press Ctrl+Ftwice to bypass CodeMirror's search and to use browser's search. —andrybak (talk) 18:10, 15 October 2026 (UTC)Reply
For me, during the "just work with it" phase of this in the half hour or so before I came here to figure out how to turn it off because I'd been fed up to the gills with working with it, I found that I could search-in-page for plain text, but not for formatted text. For instance, after creating an article about a film that was already listed unlinked in List of Canadian films of 2026, when I went to try to wikilink it there I couldn't find it in the list by searching the film's title because it was italicized, but I could find it in the list by searching the director's name since that didn't have any wikicode around it. (And, of course, since my primary editing domain is the arts, meaning I work with a lot of film and book and album and television series titles that would be italicized, losing the ability to search-in-page for italicized text was the straw that broke the camel's back for me in terms of just working with it.) Bearcat (talk) 16:09, 15 October 2026 (UTC)Reply
In case you want to give CodeMirror another try, please review mw:Help:Extension:CodeMirror#Why doesn't the browser search work? and let me know if any of those tips help. The thing to keep in mind is that CodeMirror will auto-focus on the editor, even after previewing. You can at any point however hit Ctrl+Ftwice to activate the browser search (if you were trying to search the previewed output).
I'm not sure what happened in your case. The formatting is only around the film title, correct? So CodeMirror's search most certainly should find the title in the wikitext. Obviously, if there was formatting within the title, you'd need to include that in the search query (this is also true without CodeMirror when searching within wikitext, unless your browser somehow has some sort of fuzzy search). —MusikAnimaltalk19:06, 15 October 2026 (UTC)Reply
There wasn't text formatting inside the titles, no. And it wasn't just a one-time weird thing around just one film title, either, as once I figured out what was going on I tested several other search strings that I already knew to be present in the page, both formatted and unformatted text, and found that it would consistently find unformatted text while consistently erroring out on formatted text. I've been around Wikipedia since God was in diapers, however, so I'm more than familiar enough with wikisyntax that I just can't imagine needing special syntax highlighting badly enough to warrant spending any extra time tweaking it to work right. For new users, fine, but I'm far beyond the point of needing it. Bearcat (talk) 20:32, 15 October 2026 (UTC)Reply
I'm intrigued! I tried searching the same article you mentioned and everything worked as usual. Are you sure you were using CodeMirror's search, and not your browser search (i.e. focus is on the editor when you hit Ctrl+F)? Maybe you accidentally had the regular expression option on? I'd love to know if there's a real bug here that we should fix, but I get you're not interested in CodeMirror so don't let me hassle you with debugging this if you're not interested:)
Even though you're an old-timer per-se (I consider myself one, too, albeit much less old!), the things CodeMirror offer are supposed to expedite your day-to-day work and make life easier. I'm not trying to convert you; This thread by itself is proof many users won't ever want CodeMirror at all. But, if there are real issues that bother the experienced users, it's possible they will bother other users as well. Again, please ignore me if you've had enough! Best, —MusikAnimaltalk21:27, 15 October 2026 (UTC)Reply
To be fair, I'm perfectly willing to read through its documentation to see if I think any of what it does would actually be valuable to me — I just don't feel the need to immediately turn it on just to "trial and error" my way through a decision. Bearcat (talk) 22:22, 15 October 2026 (UTC)Reply
@Boud CodeMirror is not WYSIWYG. That's Visual Editor. CodeMirror just enables syntax highlighting and a bunch of cool features like autocomplete for templates and parser tags and reference collapsing in the source editor. --Ahecht (TALK PAGE)13:27, 15 October 2026 (UTC)Reply
I guess it's weirder than WYSYIWG. CodeMirror syntax highlighting converts=== Plain text ===\nTwo words. (where \n is the unix/linux end-of-line character) into
@Boud What plugin are you using to transfer the Wikitext to emacs? If it grabs the content of the textarea with id wpTextbox1 (e.g. document.getElementById('wpTextbox1').value in javascript) it will get the unadulterated text. Seems like it would have to go out of its way to grab all the cm-line divs. --Ahecht (TALK PAGE)16:59, 15 October 2026 (UTC)Reply
You're not the first to want Emacs (or Vim) keymaps while editing wikitext. Fortunately this is totally doable in CodeMirror! I've filed phab:T441357 for this. Though, I'm not sure if we would be able to automatically prevent conflicts with the Firefox add-on that you're using. —MusikAnimaltalk19:19, 15 October 2026 (UTC)Reply
@MusikAnimal I think it's quite clear that "editing with Emacs" means exactly what it says, and at least in this discussion nobody has asked for Emacs keymaps. The ability to use Emacs instead is the whole point, as in not staying in the browser window and not using any kind of wikitext editor. TooManyFingers (he/him · talk) 05:03, 16 October 2026 (UTC)Reply
Understood! Shows how much I know:) I come from Vim-land, so to me there's just a few modes that expedite whatever I'm trying to do as far as text editing. Then we sprinkle in some CodeMirror features (i.e. contextually correct API-powered autocompletion, and of course – syntax highlighting!), and we get the best of both worlds, all with just keymaps and a few tiny UX changes. I am unfamiliar with any sort of Emacs server-based editing, but I'm certain we can get the familiar Emacs keybindings to work say when you login to a public computer to edit Wikipedia. —MusikAnimaltalk06:19, 16 October 2026 (UTC)Reply
Personally, when I use the browser extension I have to edit in vim, it's frequently because I want to interact with my local filesystem in some way: I find it a bit more convenient than opening an editor separately and copy-pasting to save the wikitext, or copy-pasting from a file into the browser, and I often use :!. I doubt the keybindings will be able to give me any of that. OTOH, if they give :s they might still be useful for some of my use cases. Anomie⚔10:39, 16 October 2026 (UTC)Reply
:! (run a shell command) is of course a no, but :s and :wq etc. could be added, I believe.
I'm going to have to try out a Vim browser plugin myself, I guess! Regardless, I'm sure you understand what I mean of how convenient it will be to login and things like ciw or ci[ etc. just work (no browser plugin needed). I am much quicker to type in Vim than anything else, using the keymap alone.
I have submitted T441308. There may be additional circumstances that led some editors to have this option selected. It is selected for me even though I did not select it. I was also using the syntax highlighter gadget (by Remember the dot), but this option appears to have overridden it. – Jonesey95 (talk) 12:14, 15 October 2026 (UTC)Reply
I was so confused when this happened to me - I rushed right over here to VPT to figure out what had happened. Thanks very much for telling me how to opt out. This is a change that should be reversed immediately. Chorchapu (talk|edits) 13:47, 15 October 2026 (UTC)Reply
I have nothing else to add, since I found and followed the "how to turn it off" instructions above, but just wanted to add one more voice to the "I hate it" pile anyway. Bearcat (talk) 16:03, 15 October 2026 (UTC)Reply
I'll grant that it's at least partially just a case of being accustomed to my established habits (and too old to change them on a casual whim that isn't unavoidably necessary), but the in-page searching problem I noted above was the biggest issue — and I've been around Wikipedia more than long enough to not really need the highlighting the same way a new editor might, so I can't really say I feel all that motivated to turn it back on and tinker. Bearcat (talk) 20:55, 15 October 2026 (UTC)Reply
Hi, my initial reaction I suppose I can boil down to “What are those numbers, why is everything colourful, what’s going on!” I turned it off before I continued any editing but I can look into it again and properly evaluate its merits, on my own free will this time. As Bearcat says above, I’m more or less familiar with the wikitext formatting and don’t really need the colours and highlighting. Chorchapu (talk|edits) 21:31, 15 October 2026 (UTC)Reply
I wouldn't say I hate the highlighting, but I do hate the way it's been rolled out as a complete surprise leaving editors scratching their heads as to why their computers have broken and how to mend them. It should certainly be opt-in but, if the WMF is adamant that it knows better than editors what editors want, there should at least be an advance announcement of what they insist on changing and how to revert it. Certes (talk) 16:46, 15 October 2026 (UTC)Reply
I myself was shocked and worried when I first saw the new formatting. I would likely not have edited if I had not seen this thread on VPT to remove it. Chorchapu (talk|edits) 16:49, 15 October 2026 (UTC)Reply
Can anyone of you confirm/deny if you turned on CodeMirror on a different wiki? If so, what you're encountering I think is a bug in Core preferences (phab:T441308#12438534). The production config for CodeMirror can be viewed here where it clearly has usecodemirror off by default globally, and enabled on English Wikipedia only for newly registered accounts and logged out users. At any rate, I can assure you the unwanted change was not intentional – I'm just not sure about how to fix it just yet. I will continue debugging and report findings at phab:T441308. Follow along there if you're interested. I will post here once things are resolved. —MusikAnimaltalk17:30, 15 October 2026 (UTC)Reply
Ditto. FWIW, I don't mind the highlighting, or even how it breaks in-page search, but the way it hijacks all my keybindings is intolerable. —Cryptic17:38, 15 October 2026 (UTC)Reply
@Cryptic Would you mind sharing which keybindings you care about that are broken? Eventually, we want to offer CodeMirror as its own standalone editor (it already is technically if you disable WikiEditor, but then there's no toolbar). I have a note made that when we do this (phab:T95148), we should offer users the ability to customize all keyboard shortcuts. If there are any glaring issues as it stands now, I'd love to hear about them in case there's a quick fix. Ctrl+E is one that was already reported, and I don't have an easy solution for that, unless it becomes a widespread complaint. If Ctrl+F is your concern, make sure to read mw:Help:Extension:CodeMirror#Why doesn't the browser search work? and let me know if that helps at all. —MusikAnimaltalk19:39, 15 October 2026 (UTC)Reply
It's not so much that they're broken, per se, than that they override the custom ones I have set in my browser. Escape is the most immediately objectionable since my bindings are emacsish, but looking over mw:Help:Extension:CodeMirror#Keyboard shortcuts I don't think I'd be able to use this unless I could disable them all en masse. —Cryptic19:54, 15 October 2026 (UTC)Reply
I just filed phab:T441357 as you are not the only on in this very thread that prefers Emacs keybindings! It will be a "while" from now, but if you're up for it, I'd love to consult you for user testing once we have something to demo. —MusikAnimaltalk20:10, 15 October 2026 (UTC)Reply
Glad for the confirmation that this is an unintended bug:).I'm reasonably sure that I didn't enable the "Syntax highlighting" button on any WMF wikis. I've adjusted a few preferences on several WMF wikis, but not many. Boud (talk) 17:48, 15 October 2026 (UTC)Reply
Three things killed it for me. (1) On a desktop, in Firefox, it breaks the Alt+← feature to return to the previous page. (2) On an iPad, in Safari, the font size is about twice as large as it should be. (3) Safari again, when intending to reply to a post that isn't at the bottom (like I'm doing here), I should be able to tap after the timestamp of the post above and then add a newline. Instead, tapping highlights the "(UTC)" and offers options to Select or Select All. Verdict: unusable. --Redrose64🌹 (talk) 20:54, 16 October 2026 (UTC)Reply
Thanks for sharing! I've always used Ctrl+[ to go back to the previous page, and that still works for me. I'm hearing a lot of complaints about keyboard shortcut conflicts. It sounds like we may want to make them configurable, but that could be a lot of hassle to set up as everyone has different needs. Regardless, I suspect as with any IDE, a lot of it just a matter of getting used to it, but once you are, you'll (hopefully) find you can do things more quickly.
I can't speak for the Safari issues as I have no means to test them, but I've not heard such reports before. For (2), you may want to make sure you don't have your zoom level increased or something (or try a different browser, to see if it's a platform issue and not Safari). I'd need more info for your third issue to say if it's CodeMirror or not. It sounds like you were tapping outside the editor, so I'm not sure how CodeMirror would effect that. —MusikAnimaltalk20:36, 17 October 2026 (UTC)Reply
Turning all keymaps off (except the must-haves like Ctrl-F) is something we can do! I've heard enough complaints here in this thread that I'm going to get that implemented.
@Cryptic You also mentioned issues with Esc. Could you elaborate? For wikitext, we can make it do nothing (which I think is basically already the case). But for non-wikitext, it is an important accessibility escape hatch since Tab ↹ will indent instead of moving focus to the next element (usually the edit summary field).
Prefixing esc is synonymous with holding alt in emacs; both are translations for holding meta, which modern keyboards don't have. In practice, I (and I suspect most emacs users) always use one or the other for a given binding, e.g. I always push "alt and d" to delete the next word, but "escape then <" to go to the top of the edit box instead of alt-shift-comma. I use a browser extension that duplicates the bindings I have the worst muscle memory for, and when you want a keybinding extension that lets you bind multi-key sequences like Esc < you don't have a lot of choices. (It's a major reason why I use an extreme minority browser that breaks on something like half the websites I try to go to. That's preferable to Firefox wantonly breaking extensions every few weeks like it was doing when I gave up on it.) In Codemirror, pushing escape disables the selection, and for whatever reason this extension gives priority to keybindings a website defines.Other emacs users will probably object to control-f, btw, which is bound to what normal people use the right-arrow key for, and we'd have no objection to tab either indenting, or inserting a tab (emacs does one or the other, depending), or just not being interfered with by Codemirror and falling through to whatever the browser normally does. —Cryptic15:52, 19 October 2026 (UTC)Reply
I don't know of any way of changing the zoom on an iPad other than the two finger pinch/reverse pinch, which resizes everything, not just the font inside the edit box. So reducing the font size also reduces the edit window size together with everything around it. There are no other browsers for an iPad: there are downloads available, that claim to be Chrome, Edge, Firefox or whatever, but underneath, they're all wrappers for Safari. --Redrose64🌹 (talk) 20:40, 18 October 2026 (UTC)Reply
Fixed! Confirmed by testing with MusikPuppet, an account of mine that had CodeMirror turned off before today. My sincerest apologies for the misconfiguration. Note however the preexisting issue with user preferences that I mentioned above still exists. The global preference for CodeMirror (which is an auto-global) still doesn't work quite right, but it should behave normally in a week or so assuming there's no opposition to enabling CodeMirror by default globally (for new accounts and logged out users – same change that was made here). I'll try to get that bug fixed, regardless. —MusikAnimaltalk18:48, 15 October 2026 (UTC)Reply
@MusikAnimal: you asked what I didn't like. The glaring colours and line numbers were a big part of it. On my laptop, things have to be done in a certain way. Windows open in a specific order, tabs within windows likewise, or I can't function. Plain old black and white text, with red underlining for possible spelling errors works just fine for me. Mjroots (talk) 09:10, 17 October 2026 (UTC)Reply
Some CSS and JS pages are showing up with Linter errors (WP:THURSDAY change?)
At this list, for example, CSS and JS pages are showing up with Linter errors. This list was empty yesterday. Multiple Linter error categories are showing the same issue.
I'm pretty sure that this is a WP:THURSDAY change, and I'm trying to figure out if it is a bug or a new feature. Is there something different about these specific JS and CSS pages that makes the MediaWiki Linter parser flag them as having errors? A content type or something? The latter is not my area of expertise. In the past (i.e. since 2018 when Linter errors were enabled), CSS and JS pages would be ignored by the Linter. Any insight would be welcome. – Jonesey95 (talk) 12:21, 15 October 2026 (UTC)Reply
Latest comment: 7 days ago2 comments2 people in discussion
Can we add some way to adjust the time period for a watchlist item from the watchlist? The way mine is set up pages are automatically added for different lengths of time depending on how they're added (usually via Twinkle or Interceptor), and if I want to change the length I have to go to the page, unwatch, then re-watch and set the length manually. The watchlist itself seems to have just about every function except that. Ideally I'd like something similar to the labels function where I can batch them via checkboxes. ChompyTheGogoat[Bleat|Munched]15:29, 15 October 2026 (UTC)Reply
Don't know about the Special:Watchlist, but I'm planning to add this to the Special:GlobalWatchlist when the relevant popup Phabricator task will be resolved. IKhitron (talk) 15:33, 15 October 2026 (UTC)Reply
Thursday issue: " a link was made from" now goes circular?
Latest comment: 4 days ago2 comments1 person in discussion
I have now thrice received a message about "a link was made from page X to page Y" where source and target are the same, and I don't see any addition of a circular redirect in the edit (e.g. here. Is this a Thursday WMF release error, or is there something in that bot edit that causes this anyway? Fram (talk) 16:05, 15 October 2026 (UTC)Reply
Latest comment: 7 days ago3 comments2 people in discussion
Hi, there's the "Beta" button on the navbar between "Preferences" and "Watchlist" which I don't find useful and would like to hide. It's really just a shortcut to a tab in "Preferences" which I've never used. However, I can't find any option in the settings to remove it - is this possible? My skin is Vector 2010, if that helps. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 17:48, 15 October 2026 (UTC)Reply
FYI: For best results preview the Main Page sandbox in wide view (on Vector 2022), since that's what the actual Main Page is displayed in. In any case, happy we all worked on putting this together!:) Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪06:25, 16 October 2026 (UTC)Reply
Interesting. It looks good, but as an ITN editor it does make me sad to see the section be pushed down “below the fold”, so to speak. On a similar note, how will this affect MPBALANCE? It seems like we’d need to either expand TFA and DYK, or cut down on entries in ITN and OTD. I certainly hope it’s not the latter. Chorchapu (talk|edits) 11:55, 16 October 2026 (UTC)Reply
That's kind of an unanswered question at the moment. I believe there were discussions at ITN and DYK related to this. The DYK one especially said they didn't have the ability to do more daily hooks than are already done. I think for now we should just have an imbalance, and if all goes well with the new section different ideas to fix it can be discussed. InfernoHues (talk) 13:30, 16 October 2026 (UTC)Reply
That's a shame. At ITN we've always wanted to have more room to be able to run either more detailed RDs, more Ongoings, or something like that. If TWAFI had gone on the other side, that could have been possible while still following MPBALANCE. But with it being on the right, we are left with no opportunity to expand other sections, and an ugly, off-balance Main Page. Chorchapu (talk|edits) 13:33, 16 October 2026 (UTC)Reply
Nothing is set in stone yet. We need to add the TWAFI to the main page, and for that we're using the placement chosen at the RfC, but its position can always be changed in a future discussion. As is often the case with new proposals, not everything is perfect in the first attempt. FaviFake (talk) 14:29, 16 October 2026 (UTC)Reply
Also noting that the Main Page is historically skewed in terms of section widths (with the left side being 55% of the width, and the right side being 45%), and this offers us an opportunity to rebalance it. If there's support to move TWAFI on the left side after seeing how it performs in practice, it can absolutely be reconsidered! Chaotic Enby (in solidarity · talk · contribs) 15:07, 16 October 2026 (UTC)Reply
I want to make sure it's on someone's radar to also add this to Wikipedia:Main Page/Tomorrow and similar pages (e.g. the queue) given that this is week-based and not day like everything else? I think it would be good to do it before it "tomorrow" as staging.
I bring this up because /Tomorrow is used to implement cascading protection 1-day ahead of time (including for Commons images) so people can't e.g. sneak in vandalism right before midnight. Legoktm (talk) 18:03, 16 October 2026 (UTC)Reply
Well if the goal is to have it go live at exactly midnight UTC I would suggest putting in the code ahead of time, just conditionally wrapped by a parser function. But it wasn't clear to me that was what was desired. Legoktm (talk) 23:28, 16 October 2026 (UTC)Reply
Main Page/Tomorrow is mostly there to cascade-protect things in advance (meaning, everything transcluded on it gets automatically protected before it moves on to the Main Page). However, content on that page doesn't automatically replace the current Main Page at midnight, so there isn't a risk of AFI going live one day too soon because it was placed there before midnight UTC. In a few minutes, both the Main Page and Wikipedia:Main Page/Tomorrow will be updated automatically thanks to the templates they invoke, and the latter will have AFI alongside the rest of the 18 Oct content. Chaotic Enby (in solidarity · talk · contribs) 23:44, 16 October 2026 (UTC)Reply
Nice catch! I assumed that it worked the same way as {{CURRENTDOW}} (which starts anew on Sunday and not Monday). The discrepancy is surprisingly resolved by looking at #time, which output the ISO 8601 week (W) and weekday (N), cycling from 1 to 7, alongside the {{CURRENTDOW}} weekday (w), cycling from 0 to 6.Note that these only update alongside the page cache, with a maximum interval of 3600 seconds (one hour) between updates, so they might not make for the smoothest of transitions. Not sure how often the Main Page's cache is purged? Chaotic Enby (in solidarity · talk · contribs) 14:12, 17 October 2026 (UTC)Reply
My understanding is that there are bots/scripts that'll purge the main page at midnight, in addition to the normal cache purges that come with DYK rotation. If that was what you were asking. Legoktm (talk) 14:37, 17 October 2026 (UTC)Reply
I think it would be best to actually delay the deployment until Monday. Looking at the AFI pages, it looks like it also starts weeks on Monday, so I think that instead of starting AFI on Sunday we should start it on Monday. Axolitl(talk|contribs)16:20, 17 October 2026 (UTC)Reply
(commment moved at 14:53, 19 October 2026 (UTC))
Can we please keep this thread focused on the technical implementation and instead make comments about (lack of) notification elsewhere? Legoktm (talk) 14:46, 19 October 2026 (UTC)Reply
I love that this is coming to the main page. However, even as a long-time editor, I think the main page should be oriented to readers more than us editors. The encyclopedia here is for the readership, after all. So, I would suggest putting this block beneath "In the news" and "On this day". the Stefen 𝕋ower05:02, 16 October 2026 (UTC)Reply
The position seems to be pretty set-in-stone per the RfC linked above, as that position had the most support. That isn't to say that it can't be changed, but doing so would likely involve more discussion. Axolitl(talk|contribs)05:24, 16 October 2026 (UTC)Reply
Hmmm, then my next suggestion is for Wikipedians to be better informed about current RfCs, but I'm not the first to whine about that.:) At any rate, I'm glad to see this coming to the main page. the Stefen 𝕋ower05:27, 16 October 2026 (UTC)Reply
On further consideration, having read much of the RfC, and realizing a lot of nominated articles (including one I nominated) have been summarily removed from consideration, I am withdrawing my above support for this effort. Slapping the faces of many editors to build this new feature is frankly repulsive. the Stefen 𝕋ower08:01, 16 October 2026 (UTC)Reply
If TWAFI isn’t performing well on the main page (e.g. few new accounts are actually editing the week’s article) then its placement could always be reconsidered at a later date. Maybe after 10 weeks? Some1 (talk) 09:33, 16 October 2026 (UTC)Reply
As the person who implemented that change, I'd like to point out that the project has few active participants, so I made practically all my changes under WP:BOLD. If anyone wants to WP:BRD my changes, feel free - we do have more than a week before we need another article. 7amiþ = reform(solidarity).__init__(t, c)15:46, 16 October 2026 (UTC)Reply
The issue is that the criteria is getting stricter and stricter. I understand how you feel, but the entire project shouldn't have to go because of that. This does need to be resolved though. NewAccount7295 (talk) 16:05, 16 October 2026 (UTC)Reply
Two questions: where was the width rebalancing discussed? And, on this confectionary TWAFI specifically, why do we have a bullet point for re-ordering the already chronological history section to be chronological? Putting an encouragement at useless edits to 6 million people (I would have put the latter at errors but there is no section for TWAFI). 1brianm7 (talk) 03:04, 17 October 2026 (UTC)Reply
For your first question: It is true that changing the balancing percentages wasn't discussed, although I think it was necessary to resolve the imbalance at least partially. Compare the current imbalance to how it looks with the old percentages, and it won't look very good.
Whose idea even was this? I use wikipedia fairly regularly and this came out of nowhere; if there was some sort of comment period, it wasn't well displayed to the average user. Also, I have some reservations about it displacing ITN and OTD to explicitly show off a less-than-perfect article on the main page. Joseph Zadeh (talk) 02:05, 19 October 2026 (UTC)Reply
This was overall a bad idea. Not that creating an AFI box was a bad idea, but implementing it with very little input from the userbase in proportion to the importance of the article was a bad idea. We get notifications and such for admin requests, so why not a major change to the front page? I for one do not like that the news has been pushed down for what is ostensibly a reverse featured article. I and many other people read the news blurbs when I first log on to Wikipedia. This sort of action is why new editors feel like there is a WP:CABAL. wound theology◈05:39, 19 October 2026 (UTC)Reply
We tried to implement it as close as possible to the RfC result. The closer found that consensus was to place it above ITN, so that's where we placed it. Axolitl(talk|contribs)05:50, 19 October 2026 (UTC)Reply
Of course, the consensus was weak for that spot. However, it seemed most logical to put it in the place that the RfC had the most support for, and then once it was there for a bit and people gave feedback, we could revisit it. Axolitl(talk|contribs)05:53, 19 October 2026 (UTC)Reply
There were what, 100 people or so who participated in the RfC, which includes B votes and non-voters? To change a page which receives 6 million views daily, and has 130,193 page watchers? It's just insane to me that so little input could so drastically change the very face of our project. wound theology◈06:46, 19 October 2026 (UTC)Reply
The discussion was open for more than a month, and advertised on channels such as {{centralized discussion}}. However, the low participation in the discussion was acknowledged, with the closing statement specifying that the decisions reached in this RfC may be ripe for revisiting in a few months for that reason.At some point, when there just isn't as much input as we'd like in a widely advertised discussion, we have to bite the bullet and make a first change, which in turn may attract more people into a follow-up discussion on how to reposition ourselves and make adjustments to the original findings. Chaotic Enby (in solidarity · talk · contribs) 07:50, 19 October 2026 (UTC)Reply
Again, I get a notification for administrator elections and proposals all the time, which are a routine and necessary part of the wiki's function. The fact that we can't do something similar for something far more impactful to everyday editors and daily readers is insane. wound theology◈08:00, 19 October 2026 (UTC)Reply
But it did send centralized discussion notifications (not sure about watchlist notifications though)? However, these notifications were sent back in July, when the change was discussed, and the implementation lagged by a few months. Chaotic Enby (in solidarity · talk · contribs) 08:27, 19 October 2026 (UTC)Reply
There were no watchlist notices. But TBH, would using that be overkill? Then again we are making changes to the very visible Main Page, so... Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪12:36, 19 October 2026 (UTC)Reply
There are dozens of similarly significant changes being proposed every month. For the TWAFI proposal, every possible venue was used (including RFC, CENT, VPP, and WT:MAIN). If you are not set up to receive notifications from any of these, then we can't really do anything about it. FaviFake (talk) 08:44, 19 October 2026 (UTC)Reply
If that is the case, then it shows a major problem with the way that editors are informed of significant changes. Clearly we have the infrastructure to do better than this. wound theology◈09:22, 19 October 2026 (UTC)Reply
> every possible venue was used
The editor in question mentioned getting pings for administration elections. Clearly, not every venue was used if they didn't receive a ping for this. ~2026-55973-77 (talk) 10:28, 19 October 2026 (UTC)Reply
They did not receive a talk page message because they were likely not subscribed to the Feedback request service for Wikipedia proposals. 99% of registered accounts couldn't care less about these changes, that's why interested editors need to opt in.
I was not aware the FFS even existed and I've been editing Wikipedia most of my life. Again, this just shows a major problem with the way editors are informed of significant changes. wound theology◈19:05, 19 October 2026 (UTC)Reply
I don't vote in administrator elections nor do I read The Signpost, so I haven't opted-in to either of these. If there were a similar notification, something like "There is a RfC discussing a major change to the Main Page" would have caught my eye and I would have certainly participated. wound theology◈19:32, 19 October 2026 (UTC)Reply
Fascinating. I’ve never seen those - from looking, it seems like that’s because I have my language set to EN-GB instead of just EN. I should probably change that . Chorchapu (talk|edits) 19:58, 19 October 2026 (UTC)Reply
Here's the problem, as I see it. A major change should be advertised in a place that gets at least about as many views as the place to be changed, so that (ideally) everyone seeing the place to be changed sees the proposed change. So... what page on Wikipedia has as many views as the Main Page (and is in scope)? 7amiþ = reform(solidarity).__init__(t, c)19:18, 19 October 2026 (UTC)Reply
I like being able to edit CENT too much, but, honestly, some form of curated CENT/newsletter might be nice in the "other areas of Wikipedia" section.
Certainly more useful than portals, and now there's a very prominent link to the Teahouse in the AFI section, we could remove it from that section there as well to make more space. GreenLipstickLesbian💌🧸20:14, 19 October 2026 (UTC)Reply
Yep, I was being a bit hyperbolic but a version of it adapted for newcomers would be best. In general, we don't want to limit the ability of editors to update CENT, but having a protected "Main Page-friendly" version of it (that admins update once the main CENT is updated, while taking care to make the descriptions more accessible to newcomers) would be a good stopgap to keep the current fluidity while preventing vandalism on the Main Page. Chaotic Enby (in solidarity · talk · contribs) 20:46, 19 October 2026 (UTC)Reply
Yes. I am 27 years old and made my first edits on the account Runestatue(talk·contribs) in 2008, 18 years ago, when I had just turned 9. My edits were deleted as a WP:HOAX (talking about my micronation at the time), but in reality they were actually in good faith and I just lacked WP:COMPETENCY. I have edited on various accounts since then, I stuck with this one since it was the one I was using when I turned 18 and started taking Wikipedia more seriously. wound theology◈23:20, 19 October 2026 (UTC)Reply
You can find it if you dig, but I'd prefer you didn't. It's a little bit like naked baby pictures for me. I was a very weird child (and a weird teenager, and a weird adult) and most of it is supremely embarrassing to me. wound theology◈23:29, 19 October 2026 (UTC)Reply
Wound theology: when visiting somebody else's user talk page, have you noticed messages like this? That's the feedback request service in action. There are two links to it in the edit summary, and two more in the text of the message, four in all - some might say that's three too many. --Redrose64🌹 (talk) 07:50, 20 October 2026 (UTC)Reply
Latest comment: 6 days ago4 comments4 people in discussion
Hello,
The page image on June 2023 Greek parliamentary election seems to be a lower-pixel image of Dimitris Natsios, the leader of the second-to-last party that managed to make it to the parliament. Does anyone know how I can force the constituency map to appear instead of him? Thanks in advance. Oakchris1955 (talk) 12:32, 16 October 2026 (UTC)Reply
Page images are not a priority and it would currently be messy to get the map selected. It would be easy if {{Infobox election}} had a map_image_class parameter which could be set to pageimage in articles. You could suggest it. The algorithm appears to pick the first image in most election articles and that's generally the leader of the largest party which seems acceptable, but the map would often be better and certainly here. PrimeHunter (talk) 14:16, 16 October 2026 (UTC)Reply
Latest comment: 6 days ago2 comments2 people in discussion
I recently reverted an undiscussed move, creating a redirect at Skydance TV. That is my only edit to that page. However, later it was replaced with an article about the subject. However, I keep getting notifications about that article, like npp review, wikidata etc. Shouldn't they be going to the editor who replaced the redirect with an article? And is there any way I can opt out of these notifications only for that article? Arnav Bhate (talk • contribs) 18:46, 16 October 2026 (UTC)Reply
Latest comment: 6 days ago3 comments3 people in discussion
I am a longtime editor and contributor. I recently replaced a laptop since which time I haven't been able to log in again. I am still (proudly) donating to Wikipedia but I cannot access my account. When I try to follow the steps I never get the 'confirmation email' that is promised. What am I doing wrong? Thanks in advance. ~2026-55521-21 (talk) 21:59, 16 October 2026 (UTC)Reply
Latest comment: 6 days ago3 comments2 people in discussion
It's a minor thing, but I've noticed that when a template parameter name includes an ampersand (&), the syntax highlighter fails to recognise and highlight the parameter name. I noticed this particularly while editing Talk pages with {{WikiProject Biography}}, which has work group parameters with ampersands. Is this a bug or just a limitation that can't be fixed for technical reasons? Has anyone else noticed the same?
For clarity, I'm talking about the source editor feature, which I believe is powered by CodeMirror, not <Syntaxhighlight>. I'm unsure if this issue has been already reported on Phabricator; I wasn't able to find it. – Scyrme (talk/solidarity) 22:17, 16 October 2026 (UTC)Reply
A similar bug was reported at Phab:T405267 for hyphens. The fix may be non-trivial, so it is best to wait until after MW 1.47. However, please feel free to create a Phabricator task so everyone can track its progress. 析石父 (talk) 03:32, 17 October 2026 (UTC)Reply
Hello @~2026-55704-26 -- you're one of a small number of logged-out readers who are seeing a test of the "Image Carousel" on mobile, which you can read about here: Wikipedia:Village pump (technical)/Archive 233#Image Carousel Re-Test. The feature shows a carousel of images at the top of an article for articles that have three or more images and that have not been flagged by this community to suppress the carousel on the article. The idea behind this feature is that many readers of Wikipedia ask to see the images more prominently, and this is designed to help them see the images -- but many volunteers in this community have discussed in depth the pros and cons.
About 0.8% of mobile readers are seeing the test, and it will run for a few weeks, and then go away. If you want to stop seeing it during this test, you can create an account and be logged in, or you could try clearing your cookies.
After the test, we'll turn it off for everyone, and then discuss results with this community to decide whether to deploy it more broadly.
This request for specifics is a disingenuous tactic for deflection and distraction. What people "don't like about it" is that it's a fundamentally wrong concept. Particular details of implementing a bad idea aren't relevant. TooManyFingers (he/him · talk) 18:02, 21 October 2026 (UTC)Reply
Hello, I'm writing to let everyone here know that the Score extension has been temporarily disabled. We do not have a timeline for re-enabling it yet, but a fix is in progress.
What this means for readers and editors
Any page that uses the <score> tag is affected. Where musical notation used to appear, you will now see the message "Musical scores are temporarily disabled." This applies to all score formats (LilyPond and ABC notation).
The underlying wikitext is not affected. Pages still save and edit normally. The source code for each score is preserved. The rendering is what is currently disabled.
What you can do
No action is needed from editors right now. Your score markup is intact.
If you are aware of articles where the missing scores are particularly disruptive to readers, feel free to note them here so we can prioritize.
A separate announcement will go out when the extension is re-enabled.
Sidenote. The score extension by design allows people to run arbitrary code secured only by mw:Shellbox. I'm not sure whether to claim that makes security vulnerabilities impossible because there's nothing to secure or likely because of the huge attack surface. They are supposedly using gVisor to do that securely. * Pppery *it has begun...17:34, 17 October 2026 (UTC)Reply
@JDrewniak (WMF) this needs much more wide announcement, use the proper mass message systems to get to at least every Wikipedia and Wikisource, but every community just to be sure. I shouldn't have to guess why things have been going wrong and find the answer in English Wikipedia of all places. Ignacio Rodríguez (talk) 04:20, 18 October 2026 (UTC)Reply
It appears to have happened very recently, like in the past day or two. I pulled up Help:Score, and it showed me rendered music scores, but then when I purged the page, I got that "Musical scores are temporarily disabled." message, with no link to further information. I don't see any Phabricator tasks in what seems like the logical location. – Jonesey95 (talk) 12:12, 17 October 2026 (UTC)Reply
Yes, we disabled it last night after finding a thorny bug. It'll be disabled at least through the weekend until more people come online in business hours on Monday. EMill-WMF (talk) 15:11, 17 October 2026 (UTC)Reply
And now it's Tuesday UTC time, and these security issues sometimes take longer than expected to fix (cf graphs). Can you please link to Phab T441579 from the "temporarily disabled" message so that people have a direct link to some sort of explanation? – Jonesey95 (talk) 04:18, 20 October 2026 (UTC)Reply
Scores were disabled due to a separate incident from the one that brought everything else down. My guess is that they were intending to restore them this week but then the PHP2shell mess was more urgent and they had to spend time dealing with that instead. * Pppery *it has begun...04:04, 23 October 2026 (UTC)Reply
That's right. Things are calming down a bit on the PHP security update incident, but it is still actively consuming time and focus from many people. We will come back to the Score issue as soon as we have some breathing room. Thank you for your understanding. KHarlan (WMF) (talk) 07:44, 23 October 2026 (UTC)Reply
Latest comment: 5 days ago6 comments5 people in discussion
The following code:
Times negative one ({{#ifeq:thing|thing|* -1}})
seems like it should give this wikisource result:
Times negative one (* -1)
However, the rendered result is:
Times negative one (
-1)
That is, it is as if the wikisource is:
Times negative one (
* -1)
and therefore the * is treated as a bullet-list not an inline regular character. Is this intentional and documented somewhere? DMacks (talk) 17:18, 17 October 2026 (UTC)Reply
I don't think phab:T314593 has anything to do with it (and I think that would likely cause more problems than it solves if it were "fixed", much as fixing phab:T2529 caused phab:T14974, BTW). Removing the wrapping <includeonly>...</includeonly> and the <noinclude>...</noinclude> block at the end still reproduces when previewing the doc page. It looks to me more like that it's related to the combination of the newline after the conditional header and then phab:T14974 acting on the {{#if:}} containing the :. Some preliminary poking suggests that rewriting it using Scribunto might avoid the problem, by removing the newline along with the omitted header. Anomie⚔23:34, 17 October 2026 (UTC)Reply
Times negative one ({{#ifeq:thing|thing|{{encodefirst|* -1}}}})
This is a long-established well-known feature. Basically, anything that could generate list markup is treated as if it were list markup. --Redrose64🌹 (talk) 14:31, 18 October 2026 (UTC)Reply
Gadget proposal: loading JS/CSS files for a photo comparison template
Latest comment: 1 day ago11 comments6 people in discussion
Hi,
I would like to propose an addition of a new gadget for a photo comparison template. The proposed gadget would call for a JavaScript and CSS to be loaded when the template is invoked with a hidden maintenance category (currently not created since it is all still in my user sandbox).
While I have a template done in my sandbox, the initial CSS-only version is janky and requires precise aiming of the mouse (or thumb on mobile) to move the slider. Hence, the ask to load additional CSS and JavaScript files as a gadget for the template so that the user experience is smoother.
You may check the usage of the template out at User:Robertsky/sandbox/test. The CSS-only version is loaded by default. To test/check out the JavaScript version, install the accompanying userscript indicated on the test page.
User:Robertsky/sandbox/templates/Photo comparison/styles.css - template styles.css. This will be split into two CSS files, one for the CSS-only version to be loaded as TemplateStyle as a fallback and also governing the print output, and the JavaScript-enhanced version, to be loaded as a gadget, which will take over the CSS-only version when loaded with the JavaScript codes.
The proposed template/gadget can be used on a wide variety of the articles, for example to compare:
the aftermath in a conflict zone
the outcome/ongoing nature of a phenonenom in the area, i.e. haze, fire, new volcano island, etc.
changes to a location/subject over time, i.e. landscape changes, before/after (re)development of a area/building
or creatively using it to display layers of the same subject, i.e. head: overlaying a skull with a face.
I am hesitant to push the template files as they are, given that there is already a {{Multiple images}} template that's currently being used to display photo comparison side by side, unless editors here think that the CSS-only version of this photo comparison template is sufficient for a start.
If the JavaScript version is approved, I intend to take active maintenance of the gadget, template, and related artifacts, and if need be, apply to be intadmin for its maintenance. – robertsky (talk) 08:21, 18 October 2026 (UTC)Reply
{{Multiple image}} can only go so far in comparing these images.
Full disclosure: I have been personally contacted by Robertsky trough Discord to try various beta alpha versions of the photo comparison template. But to be honest, there wouldn't be a better person to test this than me, since both of us are currently affected by what is being depicted in the images, the goddammed 2026 Southeast Asian haze.:)In any case, I would support a JS implementation of this, as the CSS only implementation is only useful for desktop readers, but most of our readers are on mobile, thus making CSS only implementation useless. Regarding the idea itself, the photo comparison can do more than just having both images being shown using {{Multiple image}} (example pictured), and by having a slider, this would promote reader engagement through direct, interactable comparison. This slider comparison has been used by the media as well, for example see this Straits Times article on the same topic, which is what led to Robertsky creating the template. I do hope that this gadget is available by default in the Preferences menu, since there are many gadgets (most notably watchlist notices, reference tooltips, and radio buttons to switch views in infoboxes) that are on by deafult.I have tested this template on all skins on a desktop, tablet, and phone, using Chromium and Safari. all of which worked when the JS is installed. As I said, the template only works on desktop when only CSS is used (by using safe mode: ?safemode=yes), with touch functionality being nonexistent. Hopefully other editors test this as well, especially those using screen readers, as well as browsers using Gecko (Firefox). Thanks. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪10:37, 18 October 2026 (UTC)Reply
Testing it, two thoughts:
On timeless, there is a css rule setting image max-width: 100%. This seems to interfere with the template and should be overriden
I'd suggest setting link= on the images to disable linking to the image description page. Its really easy to miss the slider, especially in CSS-only mode and accidentally click the image.
Remember, though, that unless the images are public domain or CC0 (or something unusual like WTFPL), the licenses on the images will likely require some sort of link to the file description page to provide the attribution and notice of license. Anomie⚔21:53, 20 October 2026 (UTC)Reply
Actually, a previous version of the JS allowed you to click on any position of the image and move the divider right to that position. However, this hijacks the links to the file information page and thus this feature had to go. You could add a footnote saying "link to left image" and "link to right image", but I don't think that would be conspicuous. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪00:04, 21 October 2026 (UTC)Reply
I noticed an issue on Minerva skin and was fixing it. It should resolve on timeless as well?
the link to the file is required for attribution purpose. Maybe a wider detection zone for the slider control may help, which I have increased in through the CSS.
Bishan NSL platform, before and after refurbishment
ⓘ How to compare
Drag the bottom-right corner of the first photograph
to reveal the second photograph. Click either photograph
to view the original image.
I think this would be a better template since it would reduce clutter on pages trying to insert images for comparison but risk sandwiching. Like this can even be used for war and conflict pages. I also just used it to compare between the original and the refurbished Bishan NSL platform.
Just other thoughts: I wonder if this can also have a thumbnail option. I also note the aspect ratio seems locked (so the images I've used seems to be cut off at the bottom). Maybe there can be more aspect ratios, or have it to default to the first image as the ratio. And I recommend using the upright parameter than using fixed px (which is a feedback I often receive for FAs; I guess the upright ratio helps keep things proportional all devices).--ZKang123 (talk·contribs) 13:16, 18 October 2026 (UTC)Reply
This looks good to me, but can this implemented using {{calculator}}? If I remember correctly, @Bawolff created some image sliders using calculator. If so, we can avoid the maintenace overheads of another gadget. – SD0001 (talk) 06:23, 20 October 2026 (UTC)Reply
@SD0001: preliminary slider version, still tweaking the css for thumbnail version: User:Robertsky/sandbox/test#Testing_calculator_version. While I can work further on this, my personal preference is to have the slider control overlay on the images rather than below the images. Image comparison sliders elsewhere on the Internet has largely adopted the control over image user experience, and a break from that approach might surprise the general readers. I will return to this over the weekend while I settle other emergent (PHP) issues elsewhere.
1 August 2026
14 September 2026
Tanjong Rhu before and during the September 2026 haze.
Adjust the comparison
50
50% first photograph visible
Both photographs are shown at an equal split.
Select either photograph to view the original image.
rcid identifies the recent-changes entry used for patrolling. curid identifies the page; diff and oldid identify revisions. They differ because they are IDs for different records. See mw:Manual:Recentchanges_table#rc_id.
For a non-AI-generated answer: curid refers to the page_id field from the page table, identifying the page. oldid and diff refer to the rev_id field from the revisions table, identifying a revision of a page. rcid refers to the rc_id field of the recentchanges table, which backs Special:RecentChanges and Special:Watchlist; the "patrolled" state is stored in that table as well. The odd "curid" and "oldid" terms go back to early versions of MediaWiki, where instead of page and revision tables there were cur and old instead. Anomie⚔15:08, 18 October 2026 (UTC)Reply
My reason for asking is that, while I can select a diff in recent changes and view it using Navigation popups, I can't mark it as patrolled using that tool. I wish to have that functionality added. As a non-coder I will have to persuade someone to do that for me, and finding such a person has proven difficult in the past (I literally waited ten years for my last request to be fulfilled). The more complete and detailed the request I offer them, the more likely it is I can get the job done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 17:05, 18 October 2026 (UTC)Reply
For the example at the top of the thread, oldid is the revid of the left side and diff is the revid of the right side. If your script is operating on the rendered diff page, you could also extract the revid (as oldid) from the links in the "Revision as of 05:16, 20 March 2005 (edit)" heading each side of the diff. Anomie⚔18:02, 18 October 2026 (UTC)Reply
Latest comment: 2 days ago9 comments6 people in discussion
I'm exploring reverted edits by new users. I can find the reverted edits via a join on the change_tag_def, change_tag, revision, and user (or actor?) tables. Next step is I want to know how many edits a user had at the time they made each edit which was subsequently reverted. Is there any way to do that short of counting all their edits with rev_timestamp less than that of the reverted edit? I'm really only interested in relatively new users, so I could do a rough first pass by checking for user_editcount < 1000. I'll probably miss some interesting edits, but close enough for what I'm doing.
I'm also going to want to look at the actual diff, so that would mean adding more tables (text? content?) to the join. Or, am I just going about this the wrong way? I know there's a variety of post-processed denormalized data sets that exist. Would one of those be easier for this kind of query than just a huge SQL join? RoySmith(talk)21:15, 18 October 2026 (UTC)Reply
This - and the related problem of "was an editor autoconfirmed/extendedconfirmed/similar at a given time" - comes up fairly frequently at WP:RAQ. And no, there isn't a better way of doing it than counting previous edits. You do have to count previous deleted edits, too, though.To your second question, the "actual diffs" aren't stored; they're computed on request from the full text of the old revisions. As you're probably aware, that's not copied to the database replicas, so you're going to have to work from a dump. I don't know anything about denormalized datasets other than to vaguely recall mention of them before.You might be interested in Wikipedia:Database reports/Potential edit-warring or disruption as a starting point, which by odd coincidence I was working on immediately before seeing this. —Cryptic21:31, 18 October 2026 (UTC)Reply
Alternative idea that's substantially easier - define "new user" not as "had fewer than X edits at the time", but as "had registered less than Y time before". user_registration isn't accurate for very old users, but presumably Y will be a lot lower than "20-some years". —Cryptic21:54, 18 October 2026 (UTC)Reply
If using Quarry or similar, don't forget that the revision_userindex view can be a faster way to find a user's contributions. (Documentation here.) Certes (talk) 14:46, 19 October 2026 (UTC)Reply
There are often lags in updates at the weekend. My impression is that there's some manual activity required for each day's update and that it doesn't get done when the staff are taking a weekend break. It looks like it has caught up now it's Monday. Andrew🐉(talk) 15:53, 19 October 2026 (UTC)Reply
One issue is that some topics get hammered by bots and there may be some manual sanity-checking as part of the process. For example, Mathematics has been a top read article lately but the traffic is mostly desktop with little mobile and that's a sign of bot activity rather than human interest. Andrew🐉(talk) 16:48, 19 October 2026 (UTC)Reply
Opinions from people here would be welcome at Template talk:Lua#Error search. Templates using a module use {{Lua}} to show "This template uses Lua..." with a list of dependent modules. There is a proposal to add a line allowing a search for "Lua error in Module:name". Would someone please tweak the template with the style that shows a plain internal link. Johnuniq (talk) 01:04, 20 October 2026 (UTC)Reply
Latest comment: 2 days ago6 comments3 people in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
To measure the impact of incorporating some community-requested features on logged-out reader retention, a test for Image Carousel will be pushed to logged-out readers. With the Image Carousel feature, readers browse community-uploaded images, selected by editors as relevant to specific articles. The test starts on November 20.
An experimental notice will be pushed to 0.5% of logged-out mobile readers who come to English Wikipedia from Google, asking them to add Wikipedia as a Google Preferred Source. The test is to see if this notice increases reader retention and encourages people who use Google Search to visit Wikipedia more often. It will run from October 15–29 and will be assessed for its impact on retention and referrals.
View all 26 community-submitted tasks that were resolved last week. For example, an issue where Quarry returned an “Access denied” error when users tried to run SQL queries, preventing queries from running normally, has now been fixed.
Updates for technical contributors
Due to a long-standing bug, applications that use the OAuth 2 client credentials flow to act on their owners’ behalf are treated as if they are logged out. This will be fixed for new applications registered on or after Monday, October 19. Some affected applications need to re-register.
A proposal to hold the Wikimedia Hackathon every three years, with regional hackathons in between, has been shared. It explores making the event more accessible to technical communities in different regions. Share your feedback on the proposal’s talk page before November 6.
Was there any use case for the previous behaviour where edits from client-credentials grant were anonymous instead of attributed to the owner? – SD0001 (talk) 07:37, 20 October 2026 (UTC)Reply
That's wholly irrelevant to the criticism of characterizing it as a "long-standing bug" rather than a change to facilitate replacement of owner-only consumers with something more complex but more amenable to your edge rate limiting setup. (to answer: not to my knowledge, but it is the more straightforward of the options described in the spec should the client take a logged action on its own behalf rather than on behalf of any authorizing user) Anomie⚔12:14, 20 October 2026 (UTC)Reply
I don't see anything wrong with characterising a feature without any use case as a "bug", when a logical way to implement it exists. Being spec-compliant doesn't mean it's not a bug. The standard behaviour in identity platforms is for a client-credentials grant to act on behalf of the service account to which it belongs (which in MediaWiki's case would just be regular user accounts). – SD0001 (talk) 13:07, 20 October 2026 (UTC)Reply
Well, I suppose you're allowed to use any idiosyncratic definition of "bug" that you want. But then you shouldn't be surprised if people point out that you're using the word in a strange and non-standard manner contrary to its usual definition.As for "standard behavior", that seems something that OAuth 2 is woefully lacking in. I'd also disagree with your assertion that the "service account to which it belongs" is necessarily the same thing as the account registering the consumer; that too sounds like motivated reasoning to justify the conclusion. Which you really don't need if you drop the claim that you're "fixing" a "bug", the change can stand on its own as a change. Anomie⚔22:08, 20 October 2026 (UTC)Reply
Latest comment: 3 days ago6 comments5 people in discussion
Well, that was a surprise!
I was answering a question on the Teahouse, and I wanted to tell them about recovering a lost password, so I wanted to logout and see what the screen looked like. So I started up a different browser (Chrome, rather than Firefox - I almost always use only the latter) and logged out on Chrome.
I went back to my Firefox session and tried to complete my reply - to find it failed because I was no longer logged in.
Has it always been the case that there can only be one login across different browsers on the same device at the same time? ColinFine (talk) 16:58, 19 October 2026 (UTC)Reply
Has it always been the case that there can only be one login across different browsers on the same device at the same time? That's not what happened. Logging out logs you out from all sessions for that account, but you can log into different accounts on different browsers (or profiles, containers, incognito windows, etc.) on the same device. You can also effectively log out on one browser only by simply deleting cookies. Nardog (talk) 17:10, 19 October 2026 (UTC)Reply
@ColinFine: The action of logging out doesn't actually do anything to cookies on your device(s). When you log in on a given device/browser combination, a login cookie is generated and stored in your browser. Our servers keep records of each of these cookies, and logging out informs our servers that all of these records should be invalidated, regardless of which device/browser they were generated for. So the next time that your browser submits a cookie to our servers for validation, it's not recognised. --Redrose64🌹 (talk) 22:59, 19 October 2026 (UTC)Reply
Just in case someone reading this thread is unaware, note that since deleting cookies isn't actually the same as logging out, it won't serve to defend against stolen cookies. If you're concerned about an unauthorized person using your account, make sure to actually log out. isaacl (talk) 20:44, 19 October 2026 (UTC)Reply
Latest comment: 2 days ago6 comments4 people in discussion
If I look at Category:1917 elections in Puerto Rico I see that the categories are added by a template, and instead of adding "Puerto Rico" it adds "Pu". This probably means that smth is broken up the chain, but after looking up at the chain of templates I could not find anything (and all the templates I looked at were protected, so that it is probably not vandalism). Could somebody please have a look and find what the problem is? If edits to a protected template are needed I can easily make them. Thanks. Ymblanter (talk) 08:06, 20 October 2026 (UTC)Reply
But whatever happens, we should not be getting red categories like "Years in pu"? Should I then remove the template and add the categories manually for each year? Ymblanter (talk) 11:24, 20 October 2026 (UTC)Reply
IMHO, the template is appropriate, becasue while yes it isn't a state, the template just saying "states" while reading/displaying "states and territories" is a reasonable piece of simplication. - The BushrangerOne ping only19:20, 20 October 2026 (UTC)Reply
Latest comment: 2 days ago12 comments7 people in discussion
A nomination at WP:GAN with a review renders with the list number next to the review, rather than the nomination -- see the first entry at this section for example. Some Googling tells me it's probably something to do with {{GANentry}} emitting a div, but fixing that (if that is indeed the problem) is beyond my skills. Can someone who knows what they are doing take a look? Thanks. Mike Christie (talk - contribs - library) 11:05, 20 October 2026 (UTC)Reply
Odd. I can confirm that is not what I am seeing, I am seeing "1." before "Third Militarism" on Windows Firefox, Chrome, and Edge. CMD (talk) 11:33, 20 October 2026 (UTC)Reply
I'm using Chrome on an iPad; it happens in safemode and in incognito mode. I also tried it on Safari on the same iPad and got the same result. I'm traveling at the moment but will see if I can VPN to my work PC and try it from there. Mike Christie (talk - contribs - library) 11:39, 20 October 2026 (UTC)Reply
It does not happen on my work PC (Chrome/Windows 11). It's more an annoyance than anything else but I am curious as to what could be causing it. Presumably Safari and Chrome on an iPad share a rendering engine? Mike Christie (talk - contribs - library) 11:44, 20 October 2026 (UTC)Reply
What I'm seeing on my iPad Gosh, I need to get back to that GAN review...On my iPad, the nomination numbers are top-aligned for nominations that have not been reviewed as it should, but appear to be centre-aligned (vertically to be clear) are aligned to the review tag instead when there is a review or "Nominator/Reviewer inactive for more than >30 days" notice (or both).Also, on the topic of this page, is it possible for Convenient Discussions to stop loading automatically on that page? (It is useful when it works, such as when uploading this pic.:)) Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪11:55, 21 October 2026 (UTC)Reply
Hey everyone – due to a critical security advisory about the PHP language (which we depend on), many Wikimedia services are going to be affected. We are hoping to avoid downtime to the wikis, but some supporting tools and services are unfortunately going to be impacted. This is a complex operation on short notice and we are still figuring out the details. More information will come later this week. Johan (WMF) (talk) 21:55, 20 October 2026 (UTC)Reply
In response to the recent PHP security advisory[0], we are temporarily disabling all network access for Toolforge and Cloud VPS pending security patches.
As security patches get deployed we plan to incrementally re-enable services. Initial efforts will be focused on securing Toolforge, but if you are 100% sure that your project uses no PHP please contact us
directly and we’ll put you on the short list.
This is likely to be a prolonged outage which will depend on a lot of coordination with project and tool admins. This is not ideal, but is the best option among those currently available.
Well, this answers some of the questions that drew me to this page. Please keep the communication open and alert us to any progress made or obstacles that come up. Thank you. LizRead!Talk!00:12, 21 October 2026 (UTC)Reply
For people following along: We have a two-pronged approach to getting services back up.
Toolforge:
We're working on making the Toolforge build service smart enough to block launching of PHP tools so that we can start launching non-php things safely. Next, we'll figure out what to do about tools that rely on unfixed/unfixable PHP versions. We hope to have partial (php-free) Toolforge functionality restored sometime in the next 24 hours.
Cloud-VPS:
We're currently focusing on projects maintained by WMF staff and/or NDA users, since we have more flexibility to adjust those projects to our current safety standards. Our team is auditing projects one by one with the goal of starting up those projects that don't use PHP at all ASAP. After that we'll look at patching projects that use PHP in some form - we'll do so to the best of our ability and understanding of each project, with a focus on security rather than fully enabled functionality at first - and after that we will face up to the projects that rely on unfixed PHP versions. This whole process will likely take a few days for most projects which have a simpler path to safety, and a few weeks for the most complex ones. We might start contacting some maintainers for support as we start working on their projects.
Both:
It's worth noting that while we're still focused on the wider platform functionality, we're hoping to use your input on specific tools at some point, so thank you to everyone who has been contributing to the talk page[0].
All of these timelines should be interpreted very loosely -- any new surprises will delay things. We appreciate your continued understanding and support as the WMCS admins continue to work diligently to bring as much as possible back up as quickly and safely as possible.
We are happy to announce that Toolforge is available again for users.
We don't have yet images with patched php or have updated the buildpacks to be able to build images with php, but non-php jobs and webservices are free to run once again.
We will update as soon as possible once we have patched images for webservice and can allow build service images that use php back, but until then, please refrain from trying to work around the guardrails we have put in place.
There might be other things still not working completely, as not all CloudVPS is online yet, but please reach out with any issues you find and we'll try to help get you unblocked, though please be patient as we are still working on bringing some of the system online.
Our availability across timezones is also limited, and we're trying to make sure the team can get some rest in between all the effort we're applying, so any and all questions can take a while to get back to.
Thanks you very much for your patience and your effort, it's really appreciated.
The wikis were temporarily affected by related maintenance work, but the link above should remain the best place for updates about which tools remain offline and which have been fixed. Johan (WMF) (talk) 18:14, 21 October 2026 (UTC)Reply
and for the very beginners, PHP is the absolute essential foundation software Wikipedia needs to run. The whole of Wikipedia cannot operate without PHP. MilkyDefer07:26, 21 October 2026 (UTC)Reply
Also just noticed that many images aren't displaying on en.wiki, although when you click through to Commons, they seem fine there. Presumably that's somehow part of this. -- DoubleGrazing (talk) 15:23, 21 October 2026 (UTC)Reply
Down for me. But this is expected, they will selectively allow certain blocks of IPs to work (sites, services), check logs if any exploits come in, move on to the next. -- GreenC15:59, 21 October 2026 (UTC)Reply
I see also that image issue now. It looks like it's just previews - when reading the articles the thumbnails seem to load just fine, but when I click into the preview it goes black. Then, on Commons the preview also doesn't load but the image does. Chorchapu (talk|edits) 15:38, 21 October 2026 (UTC)Reply
All my non-PHP tools on toolforge required a webservice restart to get rid of that error. Refill looks like it's node.js based, so Novem Linguae probably just has to give it a good kick to get it running again. --Ahecht (TALK PAGE)21:51, 22 October 2026 (UTC)Reply
Even though Toolforge is back up, for the most part, AIUI the owners of each tool/bot still need to update their individual tool to get it working again. Chorchapu (talk|edits) 22:23, 22 October 2026 (UTC)Reply
For non-PHP tools nothing needs to be done other than a restart. For PHP tools, if they're using a patchable version it should be similar once WMCS updates the images over the next few days, but otherwise tool owners will need to update their scripts to support a more modern version of PHP. That being said, for non-PHP tools, this is a good opportunity for tool owners to update them to the latest versions of their languages. --Ahecht (TALK PAGE)23:41, 22 October 2026 (UTC)Reply
The Excel-to-Wikitable tool on Toolforge is still down. When I copy a spreadsheet into the tool, it says no healthy upstream. Do I need to ask the owner of the tool when it will be available, or can that question be answered? Robert McClenon (talk) 05:18, 23 October 2026 (UTC)Reply
I think Toolforge PHP is still disabled. We should circle back to this when the cloud-announce mailing list says that safe PHP versions on Toolforge have been restored. –Novem Linguae (talk) 05:50, 23 October 2026 (UTC)Reply
I am the owner of a tool. That tool also says no healthy upstream. If you asked me when it will be available I wouldn't know the answer. I think owners are meant to add the tool to this list. I think that has already happened for Excel2Wiki Sean.hoyland (talk) 05:53, 23 October 2026 (UTC)...apparently owners can now manually restart non-PHP tools themselves. Sean.hoyland (talk) 05:57, 23 October 2026 (UTC)Reply
Latest comment: 1 day ago4 comments3 people in discussion
On the page Brotli, a compression algorithm, the reference for the stable release version is being fetched from Wikidata. The issue here is that the author of the Github repo is Google, meaning that when the author is passed into a citation template, a CS1 generic name error is thrown.
In these cases I would pass in accept-as-written markup, but this can't be done given how the citation is dynamically generated.
I'm not sure what to do in this case, without changing the Wikidata value to some incorrect value. Perhaps whatever module is building the citation could pass in the accept-as-wrriten markup, but I'm not really sure. EatingCarBatteries(contribs|talk)22:54, 20 October 2026 (UTC)Reply
| latest release version = {{wikidata|property|preferred|references|edit|P348|P548=Q2804309}}
That is horribly editor-hostile. You might rewrite:
@Trappist the monk: Thanks, I didn't know that was possible; I've gone and used that at the article about the screen reader NonVisual Desktop Access. At the Wikidata page @KaraLG84: (also a screen reader user) updated the latest version and I fixed up the reference, but it was quite a struggle for both of us, to say the least. The duplicate references and move claim gadgets help a little, but nowhere near enough. As I said off-wiki, Wikidata tries to do too many things at once. Graham87 (talk) 03:06, 22 October 2026 (UTC)Reply
Sucks that the solution is to not link from Wikidata. Thank you for the suggestion though, I've implemented that but without the version number, so that people won't have to update it every time a new version drops. EatingCarBatteries(contribs|talk)05:26, 22 October 2026 (UTC)Reply
Latest comment: 1 day ago3 comments3 people in discussion
I'm attempting to make an edit at the arbitration enforcement noticeboard, and receive the following error when I try: [4fbab232-1af7-43f4-b169-85c26200ebba] 2026-10-21 16:15:43: Fatal exception of type "Shellbox\ShellboxError". It doesn't seem to be the entire site, as I was able to successfully edit the sandbox. Has anyone else encountered an error like this or knows how to resolve it? SeraphimbladeTalk to me16:18, 21 October 2026 (UTC)Reply
I've often done this but I normally start with a clean sandbox. This time I used my main sandbox which means the new article has history unrelated to the current page.
What's the cleanest way of removing all the unrelated prior edits— 17:17 20 October 26 and prior?
If you don't want your old edits in the deleted history: move it back to your sandbox; delete then restore just the revisions you want; and finally move back to the target article. KylieTastic (talk) 16:05, 22 October 2026 (UTC)Reply
Thanks to both of you. I see that there are still some edits in deleted history but I'm not gonna worry about that unless someone tells me it's worth worrying about. S Philbrick(Talk)16:32, 22 October 2026 (UTC)Reply
For next time, you don't need to delete anything for this; you could've used Special:Mergehistory to move all the unrelated edits back to your sandbox. The edit attribution is fine, but out-of-context your first edit summary and log entries would seem a bit odd (from a wiki-archaeologist's point of view of someone checking them years later with no knowledge of the discussion or you as an editor). Depending on the deleted edit summaries (which I can't read, not being an admin), I would restore the edits from 20 October onwards, if they would help to clarify things. Or a talk page message linking to this discussion would help. Speaking of the talk page, I don't know if there's anything you'd want in the deleted history there, but it's there. While I was at it I checked the move log of your main sandbox and created User:Sphilbrick/sandbox/2013 edits as a depository of some sandbox edits from that year that I found in article space (see the logs there). I created it at a separate title in case you wanted to move later edits back to your main sandbox. Hope you don't mind. Also, your old sandbox history is at the deleted page Template:Infobox women's national basketball team - Universiade, in case you want to do anything about that. Graham87 (talk) 03:14, 23 October 2026 (UTC)Reply
Incorrectly shown difference between revisions on mobile
See this diff and select mobile view (this is on Wiktionary). From Line 88 onwards, it doesn't show that I moved the * {{pedia}} part (no yellow or blue highlighting) under a new heading, it shows two unaltered * {{pedia}}. There is also an extra space after both headings. Is this normal behaviour? Aloysius Jr (talk) 10:18, 23 October 2026 (UTC)Reply
@Aloysius Jr: It's a bug I reported in March in phab:T419530. There are supposed to be curved arrows where you moved * {{pedia}} from and to. The arrows appear in desktop view but not in mobile. The necessary indicators to make the arrows are there so it could be fixed locally in wikt:MediaWiki:Minerva.css with the code I posted at Phabricator. There may still be many users who don't notice the arrows or understand their meaning but it would help. Maybe we should also add my fix to our own MediaWiki:Minerva.css when Phabrictor shows no sign of work. PrimeHunter (talk) 12:05, 23 October 2026 (UTC)Reply
You have to select "Inline" in the desktop diff to see how mobile should have looked. Here is a local example where {{norse-myth-stub}} was moved down. I personally see the arrows in mobile because I added this to Special:MyPage/minerva.css:
View all 28 community-submitted tasks that were resolved last week. For example, an issue where accidentally touching the graph while scrolling on the Pageviews tool on mobile could unintentionally zoom in has now been fixed. Click-and-drag zoom is now disabled on touch devices. 
Fixed! Confirmed by testing with MusikPuppet, an account of mine that had CodeMirror turned off before today. My sincerest apologies for the misconfiguration. Note however the preexisting issue with user preferences that I mentioned above still exists. The global preference for CodeMirror (which is an auto-global) still doesn't work quite right, but it should behave normally in a week or so assuming there's no opposition to enabling CodeMirror by default globally (for new accounts and logged out users – same change that was made here). I'll try to get that bug fixed, regardless. — MusikAnimal talk 18:48, 15 October 2026 (UTC)
Courtesy pings: FaviFake, 7amithorn, Chaotic Enby, Hason-LEK-SIN, InfernoHues, fifteen thousand two hundred twenty four, NewAccount7295, ScienceD90, Wil540 art who all participated in the discussions. Axolitl (talk | contribs) 04:52, 16 October 2026 (UTC)
Done, they have been ...
Clear skies in the early morning of 1 August.
Haze in the afternoon of 14 September..jpg)
.jpg)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 11:08, 19 October 2026 (UTC) 
Due to a long-standing bug, applications that use the OAuth 2 client credentials flow to act on their owners’ behalf are treated as if they are logged out. This will be fixed for new applications registered on or after Monday, October 19. Some affected applications need to re-register. 
Works for me in Safari on an iPad. --Redrose64 🌹 (talk) 19:37, 20 October 2026 (UTC)
