If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
@InfiniteNexus I encountered the same bug about 10 minutes ago. Bug now, it seems that the this DB bug is resolved. Hooman Mallahzadeh (talk) 08:13, 4 December 2023 (UTC)Reply[reply]
To avoid creating high replication lag, this transaction was aborted because the write duration (3.465854883194) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.
[5b6f2722-25fb-4736-a8a1-061b5bc2d481] 2023-12-04 14:31:18: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"
JFTR that edit went through in the meantime. And Phabricator indicates the developers are figuring it out. --Joy (talk) 17:05, 4 December 2023 (UTC)Reply[reply]
I also had errors on two edits in the last couple of hours. I didn't record the first but the second was [29eec93d-299b-4bdf-89d1-88caca3466b5] 2023-12-04 14:13:41: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" on this edit. Both worked after I used the browser's Back button and clicked Publish again. Certes (talk) 14:17, 4 December 2023 (UTC)Reply[reply]
Still getting an error on this. I was getting something about a transaction being too large and taking too long (>3 sec) for a couple attempts. This attempt I got
A database query error has occurred. This may indicate a bug in the software.
[4d773f04-424e-4f64-af0f-f259aa808ecd] 2023-12-04 14:44:28: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Attempts to edit my user sandbox page were successful.
I've been getting this error this morning too: To avoid creating high replication lag, this transaction was aborted because the write duration (15.307519674301) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead. [1cd8ddfe-f560-4300-b162-1d4d0448423c] 2023-12-04 16:19:03: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" These aren't large changes I'm attempting. I have gotten a few edits through, but it's hit or miss. – Muboshgu (talk) 16:23, 4 December 2023 (UTC)Reply[reply]
A database query error has occurred. This may indicate a bug in the software.
[38a2ed1b-239f-4448-841c-e65ec46331ef] 2023-12-04 08:28:23: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
I've tried a couple of different edit summaries, and I'm able to edit other articles. Could someone else please try reverting the edit? Thanks. DH85868993 (talk) 08:32, 4 December 2023 (UTC)Reply[reply]
Me as well at Vista, California ... [ab2894fb-78ff-4187-a212-713464e91635] 2023-12-04 12:22:58: Fatal exception of type "Wikimedia\Rdbms\DBQueryError". Magnolia677 (talk) 12:25, 4 December 2023 (UTC)Reply[reply]
Same here, at Deer Park, New York: [a4dc9654-fbed-48be-8eb3-a597446272e9] 2023-12-04 12:32:07: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"WikiDan61ChatMe!ReadMe!! 12:33, 4 December 2023 (UTC)Reply[reply]
And the same here (in the UK), from about 2 hours ago, editing Caligula, using MacBook. Sometimes it lets me edit but not save. Other times, it works fine but not for long. There's no pattern to it that I can discern. My Watchlist responds to changes in all other articles. Haploidavey (talk) 12:59, 4 December 2023 (UTC) Just tried a test edit, and was treated to the following:Reply[reply]
I am getting this with many different articles. Mellk (talk) 13:21, 4 December 2023 (UTC)Reply[reply]
Database error
To avoid creating high replication lag, this transaction was aborted because the write duration (5.7858679294586) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.
[b08b554e-cf70-4cd8-8291-03dd2733d85a] 2023-12-04 13:01:46: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"
Getting the same issue with the article Martin Artyukh. [85a67d40-833b-409f-a662-ba0486de9b09] 2023-12-04 15:51:16: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" --BlameRuiner (talk) 15:52, 4 December 2023 (UTC)Reply[reply]
Yup, I'm getting the same error across multiple articles - sometimes takes multiple attempts to get a change to save. Parsecboy (talk) 16:23, 4 December 2023 (UTC)Reply[reply]
When this error hits me, if I go "back" in the browser to get back to the text I was working on, all my changes are gone. This is actually weird behavior in Chrome. E.g., if I instead get an edit-conflict page, I can "Back" in the browser freely. But when this DB error happens, it's like it somehow messes up the page cache. Does anyone know of a way to recover the text that was being worked on? I have an article that did a whole lot of cleanup work in (probably a good half hour of it) and don't want to lose all that work if I can help it. I'm still sitting on the DB error page on that one. — SMcCandlish☏¢ 😼 14:08, 4 December 2023 (UTC)Reply[reply]
Update: I took a gamble, and it turns out that clicking the Reload button worked (caveats: in Chrome, and without triggering another DB error; I have no idea what another browser would do, or what would happen if the DB error had recurred, and it might, since in trying to make a typo fix at another page I had to try five times, though each time I did it as a manual edit, not a reload). — SMcCandlish☏¢ 😼 14:28, 4 December 2023 (UTC)Reply[reply]
FWIW in my Firefox, the back button got me back into the previous state, with the content and summary fields intact, so I can keep retrying trivially. --Joy (talk) 14:33, 4 December 2023 (UTC)Reply[reply]
I'm in Microsoft Edge, and the back button gets me to the state pre-submission, with edits and summary in place. Though I am now taking a copy of the text before clicking Publish. Tacyarg (talk) 14:55, 4 December 2023 (UTC)Reply[reply]
I'm using Chrome on a chromebook and if I hit the Back button, I get the original article state from when I hit edit (i.e., I lost my changes and edit summary). I'm just going to wait until it seems to be resolved before making any more edits. Kimen8 (talk) 14:58, 4 December 2023 (UTC)Reply[reply]
FYI I just got this error (Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError") a few minutes ago, when attempting to edit FKA Twigs. My edit worked the second time I tried it. Funcrunch (talk) 17:45, 11 January 2024 (UTC)Reply[reply]
The article specifies to non-conditionally add a mapbox (specifically {{maplink-road}}). This thus depends on the Q code being looked up and being available in OSM. If it is not, it will fail to draw the map. It seems that the relationship for Bowery in OSM has disappeared, I can only find the way parts. —TheDJ (talk • contribs) 09:47, 9 January 2024 (UTC)Reply[reply]
In the meantime, is there a way to specify some coordinates so we at least get something, even if the road isn't highlighted? Jake Wartenberg (talk) 04:24, 11 January 2024 (UTC)Reply[reply]
On way is to populate |coordinates = with the right values, and then use |map_type = to specify an existing map like Module:Location map/data/United States Lower Manhattan. In this case, that solution works but doesn't look great, so in the meantime I've disabled the map entirely rather than keep an obviously broken infobox in production. It can easily be re-enabled once a better solution is found. Orange Suede Sofa (talk) 22:44, 11 January 2024 (UTC)Reply[reply]
Is there a way to add a sticky header to a wikitable? If I use {{sticky header}} and add class="unsortable" to all the 17 columns it works, but looks ridiculous. I hope there is something simpler. IKhitron (talk) 01:14, 11 January 2024 (UTC)Reply[reply]
Looking at Special:MobileDiff/1194770191 on my desktop computer using Vector2022, the header-legend has this background for added and this background for deleted. But then in the actual diff, deleted lines are appear as this background instead. I don't know enough about site CSS to know where to look. But I get the same result when I am not logged in, so it's not a personal CSS, gadget, or other preference changing it. DMacks (talk) 06:12, 11 January 2024 (UTC)Reply[reply]
phab:T354840 has been opened on this, appears to be an upstream problem, not something for us to fix here on enwiki. — xaosfluxTalk 10:49, 11 January 2024 (UTC)Reply[reply]
Try again. Is it only happening when you try to make a specific kind of edit? If so, what? — xaosfluxTalk 00:38, 12 January 2024 (UTC)Reply[reply]
I've tried it several times and its still happening. I dont think I did anything unique, just a handful of minor text edits. Mercedes-Fletcher (talk) 01:26, 12 January 2024 (UTC)Reply[reply]
@Mercedes-Fletcher some editors have reported similar problems in phab:T353889. I just made a change to the source of that article, could you try again? If it works, please let us know? If it still fails please record the exact step-by-step process you are following that leads to the error. — xaosfluxTalk 14:28, 12 January 2024 (UTC)Reply[reply]
A news source I frequently use doesn't seem to get "converted" any more by Refill toolforge?[edit]
hi - not sure if this is the right place. A news publication in NJ USA called TapInto has a number of city-based news pages by different journalists. When I put a bare URL recently using the Refill Tool forge tool, it no longer seems to fill it? Wondering why and if there is a fix? I also opened a discussion awhile back on TapInto' talk page. Thanks in advance Bhdshoes2 (talk) 15:45, 12 January 2024 (UTC)Reply[reply]
Recently, the mobile web UI has started showing thank buttons in diffs for edits by bots, which it hadn't been doing before. Is it intentional? Janhrach (talk) 11:44, 13 January 2024 (UTC)Reply[reply]
Janhrach, it looks like I (on the desktop interface) can also thank bots, so I think this is intentional. I vaguely remember seeing a phab ticket about thanking bots a while back. — Qwerfjkltalk 12:03, 13 January 2024 (UTC)Reply[reply]
The style of those articles is to link to each occurrence of the source. Thank you. -SusanLesch (talk) 16:00, 13 January 2024 (UTC)Reply[reply]
@SusanLesch: Although the pipe trick doesn't work, ordinary piped links are fine. Just type the missing name in yourself: [1] -- John of Reading (talk) 16:11, 13 January 2024 (UTC)Reply[reply]
@SusanLesch:Help:Pipe trick#Where it doesn't work said: "Where the pipe trick doesn't work, the link must be written out in full manually." I think "written out in full" could be misinterpreted as not allowing pipes at all so I have added an example.[2]PrimeHunter (talk) 16:51, 13 January 2024 (UTC)Reply[reply]
Perfect! Thanks much, John of Reading and PrimeHunter. Happy camper here. -SusanLesch (talk) 17:27, 13 January 2024 (UTC)Reply[reply]
I have a question and I figured someone must have asked before but I could not find an answer with MANY different questions asked in this section.
So, my question is if I am working on one area of the article (expanding it) and I am translating from one language to another (Serbian > English), what template can I use to "advise" everyone that I am working on this and I will remove this template as soon as work is done ?
I found few templates but I wanted to know what is the correct procedure if, say, for example, I want to put the content out in one edit and then add references in another, proof read on third edit, etc.
{{In use}} is usually a good choice. Make sure to remove it when you are done, or when you plan to stop editing for a few hours. – Jonesey95 (talk) 20:28, 13 January 2024 (UTC)Reply[reply]
What about if I am not done anything what I wanted and I want to go to bed ? Should I go with what @Redrose64 mentioned where bot will automatically remove it after 7 days.
Of course, I am planning to finish what I started within 1-3 days but just in case if something happens.
That, or {{under construction}}. I think that there's a bot that will remove both of these if the page isn't edited for seven days. --Redrose64 🌹 (talk) 20:40, 13 January 2024 (UTC)Reply[reply]
Some notices have images that are initially undisplayed, but which become visible when an editable input or textarea element receives the focus. The image remains even when focus moves elsewhere. I have seen this happen on two kinds of page, there may be others. The steps to reproduce for each are:
From any page history, watchlist etc. visit any non-current revision of a page, for example Special:PermaLink/1195410333. Observe that the yellow box at the top, beginning This is an old revision of this page, contains no image. Click on the "Edit" tab. Observe that the yellow box is still there, unchanged; also that there is a second yellow box, beginning You are editing an old revision of this page, which also lacks an image. Now click on any one of: the main edit window; the edit summary window; the "search" window in the left sidebar. Observe that both of the yellow boxes immediately gain a triangular yellow warning sign containing the "!" character.
Go to Special:MyPage/common.css. Click on the "Edit" tab. Observe that the pink box at the top, beginning Please note: CSS subpages should not contain confidential data, contains no image. Now click on any one of: the main edit window; the edit summary window; the "search" window in the left sidebar. Observe that the pink box immediately gains an octagonal red warning sign containing the "!" character.
I am using MonoBook skin, Firefox 121 and Windows 10. --Redrose64 🌹 (talk) 20:22, 13 January 2024 (UTC)Reply[reply]
I don't see any icons appearing when following these steps. The boxes remain iconless. Anomie⚔ 20:37, 13 January 2024 (UTC)Reply[reply]
For both cases, the element concerned is <span class="cdx-message__icon"></span> (it's empty} and initially there are no matching CSS rules. For the first case, when the edit box receives the focus, the following CSS rules suddenly appear in the DOM:
Presumably they're injected by JavaScript somewhere. --Redrose64 🌹 (talk) 20:56, 13 January 2024 (UTC)Reply[reply]
I see style rules like those in the codex-styles ResourceLoader module, which would also be loaded by the @wikimedia/codex module. I'd guess some script, gadget, or feature you have enabled is loading it, and I don't have whatever it is enabled. Anomie⚔ 23:59, 13 January 2024 (UTC)Reply[reply]
I don't know what this codex-styles or @wikimedia/codex modules might be. I have turned off everything in User:Redrose64/common.js and the behaviour described above does not change. I have also found that it is replicable in all skins (including Cologne Blue and Modern), except for MinervaNeue. --Redrose64 🌹 (talk) 10:36, 14 January 2024 (UTC)Reply[reply]
In short, the "contents" box overlaps the table listing episodes. I can't use a smaller level of zoom due to my vision. So the box hides a good part of the content. Here's a partial screenshot of what I see: https://imgur.com/a/EVQJ19D
Of course, I can click on the "hide" button, and the box will stop overlapping. But I don't think I should have to do that in the first place. This is really annoying if I want to come back to this "contents" box at various points when reading the list; it forces me to click "hide" and "show" multiple times, this is absolutely not user-friendly.
It would be great if someone could try and fix that. I can't fix my vision issues (so changing my zoom level is not possible) and my screen settings works well for other tasks on my laptop - changing anything on my end could create a cascade of new issues on other websites or software I use, so I'd prefer to avoid changing anything on my end.
That's what happens when editors combine a wide table with {{TOC right}}. Options include removing TOC right, switching to a different skin, putting {{clear}} after the TOC, moving {{TOC right}} higher in the page (maybe), or making the table narrower. Or, if you have extra money, getting a monitor with a higher resolution, or probably other options. – Jonesey95 (talk) 20:38, 13 January 2024 (UTC)Reply[reply]
The {{TOC right}} cannot easily be moved up the page, unless either the lead is split, or another section is inserted before the Series overview. This is because the TOC must be the last element of the lead - if placed earlier in the lead, any content between it and the first section heading becomes inaccessible to screen readers. --Redrose64 🌹 (talk) 21:13, 13 January 2024 (UTC)Reply[reply]
Not so much a question as an "is this a reasonable thing to do and a reasonable way to go about it," but the past couple days I've been thinking about article-specific search boxes in, for example, lists of lists. (If you want background, start here or ask, but that's not particularly important; for an example, see List of films based on actual events.) I was looking around a bit and {{search box}} doesn't really seem to be intended for mainspace use (as we don't have proper subpages, among other reasons); so I threw together {{search lists}} based on the (very) small number of mainspace uses, which appear to all be adapted from one addition to a list a dozen years ago or so. (Courtesy ping to Michael Bednarek.)
Is this a reasonable thing to do? (I'm inclined to think that most good ideas are thought up and implemented by someone else before me.)
Having not really started many templates from scratch before, have I made any horrible mistakes here? (Or, other general comments/suggestions.)
Minor technical question: I know regex is generally discouraged when searching with insource; does the same apply to intitle, or is that generally fine?
And barring any issues in the above, I guess... feel free to use this if you know of a list that could use it. Hopefully it's helpful.
And hopefully some of that makes sense, rather than being an incomprehensible mess of gibberish to everyone except me. Cheers. LittlePuppers (talk) 00:30, 14 January 2024 (UTC)Reply[reply]
From a user perspective, I tried it out here using an intentionally ambiguous term ("Waco", which is both an actual event and a settlement) and found that the list-specific results returned correct and relevant sub-lists, but not the articles themselves. This is a drawback, since I then had to go and open three new pages and conduct three more searches within those lists, which was no fun. Having said that, the mainspace search (for which I used "Waco film" and "Waco movie") was much less useful in general, returning too many irrelevant results and omitting relevant ones. Regards, Orange Suede Sofa (talk) 01:29, 14 January 2024 (UTC)Reply[reply]
Huh, I wasn't thinking of returning the articles in the lists. That's an idea, but I'm not seeing a great way to implement it - we have linksto: but no linksfrom:. The closest you could probably get is checking if it's in a category, but it appears that there is often not quite a one-to-one correspondence between categories and lists. (And then you run into a whole lot of other ambiguities, because there are things on a list that redirect to a section, so you couldn't find them by searching in titles, and searching texts would bring up a whole lot of irrelevant stuff, and so on.) Hopefully searching the lists themselves should cover most cases reasonably well, though. LittlePuppers (talk) 03:05, 14 January 2024 (UTC)Reply[reply]
Currently (as of 2024-01-13), extendedconfirmed status is conferred upon an account of sufficient tenure upon its reaching 501 edits, rather than upon 500 edits, as suggested by the WP:30/500 documentation. Dotyoyo (talk) 00:59, 14 January 2024 (UTC)Reply[reply]
@Dotyoyo: Are you saying that there has been a detrimental change to the way that the MediaWiki software works? I don't see what the problem is here. One edit either way won't make any difference, except to those confirmed users who wish to involve themselves in editing ECP pages, and so are making lots of edits with a view to passing the 500 (or 501) threshold as soon as possible. --Redrose64 🌹 (talk) 10:49, 14 January 2024 (UTC)Reply[reply]
There are a bunch of minor edge cases related to this, but none that are going to be changed technically. The relevant configuration item is $wmgAutopromoteOnceonEdit and the settings are:
'enwiki'=>['extendedconfirmed'=>['&',[APCOND_EDITCOUNT,500],[APCOND_AGE,30*86400],// 30 days * seconds in a day['!',[APCOND_INGROUPS,'sysop']],['!',[APCOND_INGROUPS,'bot']],]
The local pages describe to concept in plain language for the majority of users. If you think there is a tech issue with the process please report it as a bug. I would not support trying to work around by doing something like changing it to "499" in the configuration, converting to an implicit group, etc. — xaosfluxTalk 17:11, 14 January 2024 (UTC)Reply[reply]
Feel free to adjust plain language from something like "and at least 500 edits." to "has exceeded 500 edits". — xaosfluxTalk 17:12, 14 January 2024 (UTC)Reply[reply]
Off-by-one errors are common. I have checked several users at [3] and you are right, they all became extended confirmed on edit number 501. I haven't examined the code but my guess would be a timing issue where the check for 500 edits is made before the updated edit count is available. 500 or 501 seems unimportant so I would just ignore it but Phabricator would be the right place for a bug report. PrimeHunter (talk) 17:38, 14 January 2024 (UTC)Reply[reply]
It's not a timing bug. auto promote is evaluated before an edit is made (as part of the permissions check). So AFTER 500 edits, on the next time your state is evaluated, you will be extendedconfirmed. That means that for your 501st edit you are extended confirmed. —TheDJ (talk • contribs) 11:02, 15 January 2024 (UTC)Reply[reply]
Thanks for the explanation. That sounds pretty much like my "timing issue" guess even if it's not considered a bug. I had not guessed you can apparently edit an extended confirmed page on your 501st edit, but neither will users with exactly 500 edits if they still see "View source" and no edit links. PrimeHunter (talk) 12:54, 15 January 2024 (UTC)Reply[reply]
Checking the times to the second of the events, it appears that edit no. 501 is saved one or two seconds before the log entry recording the user rights change. --Redrose64 🌹 (talk) 13:33, 15 January 2024 (UTC)Reply[reply]
As a slight aside, is there any way to get the edit screen for a page one cannot edit, even though (I hope) the Publish button wouldn't work? I would actually find that feature useful for previewing changes to nested protected templates that I'm considering requesting where creating a chain of sandboxes would be awkward. Certes (talk) 13:42, 15 January 2024 (UTC)Reply[reply]
I'm tired of reading "465 feet (142 m)". It's ugly and it breaks up the flow of reading. Why can't we have the user specify whether they want sane units or freedom units in some user setting and then everything automatically gets displayed for them how they want it? It probably doesn't even require any software changes, just a version of {{convert}} which wraps things in <span class="metric-units"> and <span class="freedom-units"> and a trivial amount of CSS to pick which you see. RoySmith(talk) 03:49, 14 January 2024 (UTC)Reply[reply]
Most readers aren’t logged in. With that said, it is possible to customise content based on the location the reader is in - we could give imperial units to readers in the US, Myanmar, and Liberia, and metric units to everyone else. BilledMammal (talk) 03:58, 14 January 2024 (UTC)Reply[reply]
I knew somebody was going to bring up IP users. They can make accounts. Or things can fall back to how they are now for IPs. Or WMF can figure out how to let IP users set preferences. Whatever. In the case of a logged-in user, setting which units you want should not be a function of location, it should be a function of what units you prefer to see. Maybe geolocation could be a first guess at a default, but the user should certainly be able to override that in their prefs. RoySmith(talk) 04:12, 14 January 2024 (UTC)Reply[reply]
So what about certain technical usages? For instance, certain projectile weights or diameters are always presented in the reliable sources under a certain unit. I've never seen 20-pounder Parrott rifle or the 8-inch Columbiad referred to as the 9.07-kilogram Parrott rifle or the 20.32-centimeter Columbiad. So do we either just not convert these things and leave metric readers unfamiliar with the size/weight of these projectiles or automatically convert them and create made-up nomenclature that's not going to be found anywhere else. Hog FarmTalk 04:25, 14 January 2024 (UTC)Reply[reply]
RoySmith, what is preventing you from editing the sandbox of {{convert}} to add the classes, creating appropriate test cases, and then documenting how editors can set up custom CSS to show one class or the other? Also, why not start this discussion at Template talk:Convert? – Jonesey95 (talk) 05:53, 14 January 2024 (UTC)Reply[reply]
None of this is a reasonable response to the concern. Sorry. Your suggestion to mark certain kinds of units up is fine, but "I want it my way" isn't. There is a reason we removed auto date formatting, and logged out users are it. Remember, they are the 99%, not you. Izno (talk) 20:40, 14 January 2024 (UTC)Reply[reply]
I concur that the autodate formatting and the issues surrounding it are a good precedent to take into account. —TheDJ (talk • contribs) 10:46, 15 January 2024 (UTC)Reply[reply]
Some regions, nations, and people use and (more importantly) understand a mix of imperial and metric units. A preference could be set for those people logged-in, but those logged out would be left with articles that don't suitibly explain themselves. — Fourthords | =Λ= | 21:27, 14 January 2024 (UTC)Reply[reply]
I can also see problems where the units are normally given in one set or the other (eg 500m dash) so there should be a non-user preferred version shown first with the converted unit later. Masem (t) 04:34, 14 January 2024 (UTC)Reply[reply]
Me personally, I like seeing both units of measurement, so it doesn't bother me at all. ♠JCW555(talk)♠ 04:31, 14 January 2024 (UTC)Reply[reply]
Australia has been metric for 50 years, but we still talk 8-pound babies, 12-foot tinnies and quarter-acre blocks. The present system is fine, but we too often see inappropriate degrees of precision. Doug butler (talk) 06:05, 14 January 2024 (UTC)Reply[reply]
It's a small boat used for fishing. On a more relevant issue, I agree that inappropriate precision is something more important. — Jts1882 | talk 11:24, 14 January 2024 (UTC)Reply[reply]
And there was me thinking it was a tube of amber nectar. No worries. --Redrose64 🌹 (talk) 11:27, 14 January 2024 (UTC)Reply[reply]
It is technical in implementation details, there might be difficulties this forum could raise. -- GreenC 21:04, 14 January 2024 (UTC)Reply[reply]
I'm surprised convert doesn't already have a way to configure a default system, for logged in users. I agree there is too much complexity reading 2 systems, by default. If a measurement is globally preferred in one system, convert can have an override switch that will force display of both systems ignoring the user config to limit to one system (unless that one is the same as the globally preferred system). -- GreenC 21:04, 14 January 2024 (UTC)Reply[reply]
That's easy, they default to status quo, showing both systems. -- GreenC 19:14, 15 January 2024 (UTC)Reply[reply]
Insulting a broad swath of editors like that isn't exactly collegial... IMO its neither ugly or breaks up the flow of reading. Horse Eye's Back (talk) 07:31, 15 January 2024 (UTC)Reply[reply]
IMO, adding some spans with classes as suggested in the original post would be an easy and uncontroversial technical solution. This would not affect IP editors nor most logged in editors, who would still get to see both. Editors that care about such things could add the appropriate code to their User:YourName/common.css, such as .metric-units { display: none; }, which would hide the undesired units only when logged into their account. Simple, uncontroversial. This could be done with a template protected edit request at Module talk:Convert. –Novem Linguae (talk) 07:36, 15 January 2024 (UTC)Reply[reply]
We should keep using {{convert}} to overcome the global tyranny of the metric system. – Muboshgu (talk) 19:46, 15 January 2024 (UTC)Reply[reply]
Conversions are often necessary, and allows us to keep track of the original, referenced measurement. Well-meaning editors often convert numbers back and forth until they have changed considerably; keeping the original unit in the template helps avoid this. I would hate to forced to see only inches and grains and furlongs just because my IP address happens to be located in a retrograde, anti-knowledge society. But by all means, give people the option to hide additional numbers if they find them annoying. On the other hand, I agree we ought to stop converting numbers which do not need converting - automobile wheels, for instance, are measured in inches everywhere on the globe, and people keep applying conversion templates which is utterly inappropriate. Similarly, I bet some zealot/inattentive editor wrote "Royal Mile (1,609.34 m)" about Edinburgh. Mr.choppers | ✎ 21:29, 15 January 2024 (UTC)Reply[reply]
Not always. The Dunlop Denovo run-flat tyre used an associated belt of pressurised cans which couldn't be fitted once the tyre was on the rim, and the tyre couldn't be worked over the cans without damaging them, so special bolt-together wheels were designed. These could be split in order to fit a tyre and the can belt. Since the wheel construction was very different from the traditional form, the manufacturers took the opportunity to start with a clean sheet in terms of dimensions, and used a metric rim - 310 mm on the Austin Mini 1275GT and 375 mm for the Rover 3500 (SD1), for example. --Redrose64 🌹 (talk) 01:03, 16 January 2024 (UTC)Reply[reply]
Clearly some zealot needs to add a template to clear up misinformation, as some would say it should be "Royal Mile (1,814ish m)", given the Mile in question is Scottish. CMD (talk) 02:10, 16 January 2024 (UTC)Reply[reply]
We have the wonderfully over precise a total length of approximately one Scottish mile, an obsolete unit equal to 1.8072576 km.Nthep (talk) 14:12, 16 January 2024 (UTC)Reply[reply]
Hey all,
I've been experiencing an issue with the XTools gadget across all article space, where the HTML container for the infomation section (id: xtools) is duplicated; the first instance of it works as intended, the second contains only "." within its "#xtools_result" span tag. I'm using Firefox 121. Frzzl talk; contribs 15:46, 14 January 2024 (UTC)Reply[reply]
@Frzzl it appears that issues related to xtool are asked to be reported here. — xaosfluxTalk 16:34, 14 January 2024 (UTC)Reply[reply]
A public-domain multi-page PDF is hosted on the site. Let's say it's File:1901 phone book.pdf. If I wanted to link to page 47 in that PDF, what would the wiki-markup look like? — Fourthords | =Λ= | 17:45, 14 January 2024 (UTC)Reply[reply]
But that link doesn't say anything about wiki-markup at all, though? — Fourthords | =Λ= | 18:53, 14 January 2024 (UTC)Reply[reply]
Wikipedia - Das Buch@Fourthords: I don't think it's possible with a wikilink, i.e. wiki-markup like [[...]]. You can display page 47 with |page=47 in the image syntax like I did here. Clicking on the image goes to page 47 with the url https://commons.wikimedia.org/w/index.php?title=File:WikiPress_1_Wikipedia.pdf&page=47. Wikilinks do not allow query strings like &page=47. I doubt there is a way to link it without using external link syntax with a url instead of a wikilink. PrimeHunter (talk) 18:31, 14 January 2024 (UTC)Reply[reply]
Yep, that's exactly what I was wondering. That's a bummer, but thanks for the info! — Fourthords | =Λ= | 18:53, 14 January 2024 (UTC)Reply[reply]
Adding #page=x to the URL will link to that page in most browsers, but I don't know of a way off hand to link to the PDF itself instead of just the info/preview page, short of something like {{plainlink}}. LittlePuppers (talk) 18:36, 14 January 2024 (UTC)Reply[reply]
"when visited" what counts as a visit ? The file page, a media link, a download link ? —TheDJ (talk • contribs) 10:44, 15 January 2024 (UTC)Reply[reply]
I was thinking the file page, but I just googled and apparently PHP can't read #theseTypesOfURLTags. So would need to be done in the LinkRenderer I guess (detecting File namespace and PDF type, then converting the #47 to &page=47). If it's worth the trouble. Just an idea at this point. –Novem Linguae (talk) 11:21, 15 January 2024 (UTC)Reply[reply]
When opening a non-existent gadget page, like Gadget:example, the message says "You need to log in or create an account to create this page", even though the namespace is deprecated and this is not possible. This may be an issue or oversight with Template:No article text or it may be intentional. -322UbnBr2 (Talk | Contributions | Actions) 06:14, 15 January 2024 (UTC)Reply[reply]
It looks like {{No article text}} doesn't have a special case to deal with the gadget namespace, so it tries to detect what permissions are needed to create the page and... well, I don't know how deprecating a namespace works in MediaWiki (or wherever it's deprecated, if it's a WMF thing), but somehow it comes to the conclusion that you just need to be in the user group to do so. LittlePuppers (talk) 06:25, 15 January 2024 (UTC)Reply[reply]
Since there isn't a specific protection level applied (it's just... not possible), Module:Effective protection level comes to the conclusion that it's not protected, a talk page, or in draftspace, so you just need to be a registered user to create it. (Fun fact I just discovered: an IP can't create an IP user page, even for their own IP.) To fix the error message, you'd have to modify that module to return 'impossible' (or something) for the gadget namespace, and then modify every template/module that depends on that (or, modify {{No article text}} and hope everything else can deal with it), and so on... LittlePuppers (talk) 06:33, 15 January 2024 (UTC)Reply[reply]
Reading through my comments from yesterday... yeah, you could definitely fix it in the template without having to touch the module. (The module is the root cause of the present behavior, but the template could easily check the namespace and override.) LittlePuppers (talk) 18:33, 15 January 2024 (UTC)Reply[reply]
On second thought I've just suppressed that sentence entirely for these two namespaces, to put an end to this ridiculous timesink. * Pppery *it has begun... 20:48, 15 January 2024 (UTC)Reply[reply]
I now have a view tab ("view images related to this article") and while the source editor tab/link works, the visual editor seems no longer working. There is also a link to replay edits being shown on the submenu instead perhaps of inside the tools dropdown. Shyamal (talk) 08:39, 15 January 2024 (UTC)Reply[reply]
PS: the visual edit tab now works. Shyamal (talk) 08:59, 15 January 2024 (UTC)Reply[reply]
Still seems to occur sometimes Shyamal (talk) 15:53, 15 January 2024 (UTC)Reply[reply]
https://en.wikipedia.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022 line 10 > eval at line 18: TypeError: $(...).textSelection is not a function
Does this still happen in WP:SAFEMODE? If not, does it still happen if you blank User:Shyamal/common.js? I noticed your tried to comment out some code in your common.js with <!-- and -->. Surprisingly, that parses without error, but it doesn't do what you expect. Use /* and */ instead. Suffusion of Yellow (talk) 23:28, 15 January 2024 (UTC)Reply[reply]
Surprisingly, that parses without error Not so surprising if you know "ancient" web history. 😉 Way back when Netscape first introduced JavaScript in the mid 1990s, if you were to have used a <script> tag then many browsers would have rendered the code as text in your page, since they didn't recognize the tag. So what they did is made <!-- and (as the first non-whitespace non-comment token in a line) --> in JavaScript be the start of a single-line comment, same as //. Then people could start their scripts with <script><!-- and end them with --></script> so browsers that didn't recognize the <script> tag would treat the script itself as being a big HTML comment and therefore still not display it as text. All this is still required by the ECMAScript spec when inside web browsers for legacy reasons. Anomie⚔ 03:40, 16 January 2024 (UTC)Reply[reply]
Oh that's why <script> often had <!-- -->! TIL. Nardog (talk) 03:50, 16 January 2024 (UTC)Reply[reply]
js pages are evaluated as wikitext when they are saved. The result is not displayed on the saved page but the evaluation can have side effects like additions to link tables. If a script has parts which would be valid wikilink syntax then it can generate entries in WhatLinksHere or add the script to categories. This is avoided by the above where /* ... */ is a JavaScript comment but not a wikitext comment, so the nowiki tags are active code when the page is evaluated as wikitext. This prevents the JavaScript code from being evaluated as wikitext. PrimeHunter (talk) 05:20, 16 January 2024 (UTC)Reply[reply]
I use this trick on all my user scripts. I think it's a good practice. It prevents subtle bugs such as 4 tildes turning into a signature. –Novem Linguae (talk) 09:41, 16 January 2024 (UTC)Reply[reply]
I have blanked my common.js and yes, it does seem to work fine now! Thank you. I am surprised though by the sudden appearance of the issue... Shyamal (talk) 09:36, 16 January 2024 (UTC)Reply[reply]
This probably happens when cutting and pasting wikitext from an editor with automatic line wrap enabled. An example in two places: |url=http://stories99 .com and in |archive-url= after "wins-the". (this is on mswiki but it happens on every wiki). The example shows how it makes GIGO with bots. The question is, how to find and fix? Presumably the |url= field contains only URL information so one can stitch together pieces of text separated by spaces, but I don't think this would hold in practice, there could be many exceptions. It can also occur in other arguments like |page=[https://google. com/book/PA=5 5]. The space(s) can occur anywhere within the URL. I have come across some articles where most URLs have this problem. -- GreenC 19:11, 15 January 2024 (UTC)Reply[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Pages that use the JSON contentmodel will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [4]
Gadgets and personal user scripts may now use JavaScript syntax introduced in ES6 (also known as "ES2015") and ES7 ("ES2016"). MediaWiki validates the source code to protect other site functionality from syntax errors, and to ensure scripts are valid in all supported browsers. Previously, Gadgets could use the requiresES6 option. This option is no longer needed and will be removed in the future. [5]
An update on the status of the Community Wishlist Survey for 2024 has been published. Please read and give your feedback.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar). [8][9]
Starting on January 17, it will not be possible to login to Wikimedia wikis from some specific old versions of the Chrome browser (versions 51–66, released between 2016 and 2018). Additionally, users of iOS 12, or Safari on Mac OS 10.14, may need to login to each wiki separately. [10]
The jquery.cookie module was deprecated and replaced with the mediawiki.cookie module last year. A script has now been run to replace any remaining uses, and this week the temporary alias will be removed. [11]
A script has now been run to replace any remaining uses Note the script was buggy, you may want to check recent edits to scripts you maintain. Anomie⚔ 03:42, 16 January 2024 (UTC)Reply[reply]
How to limit Category display to subcats with non-zero contents[edit]
Is there a way to look at a diffusing category and only see the cats in it that themselves have anything in them? Use-case is a large cat of maintenance categories that each should be empty, where I want to find those that do need attention efficiently. DMacks (talk) 05:06, 16 January 2024 (UTC)Reply[reply]
@DMacks: I've written (with some difficulty) a CSS rule that on a category page will hide all the entries where the category link is followed by the text "(empty)":
I wanted to write the selector as .mw-categoryli:has(span[title="Contains 0 subcategories, 0 pages, and 0 files"]) but for some reason my browser (Firefox 121) doesn't like the sequence comma-space-character in an attribute selector. Anyway, the CSS rule goes in Special:MyPage/common.css, because it works in all skins. --Redrose64 🌹 (talk) 13:13, 16 January 2024 (UTC)Reply[reply]
I suspect DMAcks wants an option but still be able to see empty subcategories without logging out. Assuming your normal skin is not MonoBook, if you only save the above CSS in Special:MyPage/monobook.css and install User:PrimeHunter/In MonoBook.js in your common JavaScript then you can click "In MonoBook" on a category page to view it in MonoBook where empty subcategories will be hidden. PrimeHunter (talk) 14:11, 16 January 2024 (UTC)Reply[reply]
The two notification icons at the top of every page are blurry.[edit]
The two notification icons at the top of every page are blurry. I don't know if this is a css or javascript issue or just something else. 😎😎PaulGamerBoy360😎😎 (talk) 15:08, 16 January 2024 (UTC)Reply[reply]
They are not blurry for me. Can you share a screenshot? Matma Rextalk 17:09, 16 January 2024 (UTC)Reply[reply]
They are no longer blurry, It must of been a css issue because I have a heavily modified css & not all of it works properly on every device, although I don't know what in it would have caused the issue. 😎😎PaulGamerBoy360😎😎 (talk) 17:59, 16 January 2024 (UTC)Reply[reply]
Can I get my searches to open "Edit date - current on top"[edit]
I carry out a lot of searches for typos. I use the Advanced search, which always opens "Sort by relevance", whereas I need "Edit date - current on top" as I know when I last searched that particular list. I know it is only a few clicks and then running a new search to change it, but when doing it a hundred times or so, it is laborious and reduces my productivity. Adding "&sort=last_edit_desc" to the URL is equally clumsy, and I can't find any other options. Is there a way I can get my searches to open "Edit date - current on top" - Arjayay (talk) 20:13, 16 January 2024 (UTC)Reply[reply]
How do you typically open the advanced search? If you want all searches you make through the search form on every page on the site to be sorted by edit date by default, you can add
to your Special:MyPage/common.js. But if you're making the same queries anyway it sounds like the simplest solution is to bookmark the URLs for the search results already with sort=last_edit_desc. Nardog (talk) 03:45, 17 January 2024 (UTC)Reply[reply]
Hi all, Is there any way to filter the output of Special:Random, perhaps with a script? I'm not particularly keen on e.g. any sort of sport, minute sea snails, DNA or proteins, villages in Iran or Poland or US gubernatorial elections. Cheers, MinorProphet (talk) 21:06, 16 January 2024 (UTC)Reply[reply]
I suppose you could write a script that fetches a random page, and then discards it and picks a new one if it matches certain strings. — Qwerfjkltalk 21:31, 16 January 2024 (UTC)Reply[reply]
I could write a script if I knew how to, but I don't. Is there any chance of someone having a go if it wouldn't take too much time or trouble? MinorProphet (talk) 23:09, 16 January 2024 (UTC)Reply[reply]
Following a discussion at the Help Desk about Level 5 and 6 headers, I experimented with changing the format of those headers in my Common.css, and also in my Vector-2022.css, but nothing made any difference. Until, that is, I changed from the default Vector 2022 skin to Monobook, whereupon my chosen formatting immediately appeared. I am using the latest update of Chrome on Linux (Lubuntu).
I know that other parts of my Common.css are active. Using F12 to show the HTML and Computed attributes, it appears that the Common.css format is used, but is then overridden by the Vector 2022 default; however, I am not sufficiently knowledgeable about web rendering to understand why.
Is there a way to format these headers under Vector 2022? And is anything else, possibly of greater import (as those header levels are almost never used) that is also blocked by the default skin? -- Verbarson talkedits 21:27, 16 January 2024 (UTC)Reply[reply]
CSS is a programming language. It follows logic. When you don't know about this logic, then it is difficult to make it work correctly. It is not vector 2022 overriding your choices, it is you not having specified your overrides to a level that they apply correctly in multiple situations. —TheDJ (talk • contribs) 22:02, 16 January 2024 (UTC)Reply[reply]
Pages that use the JSON contentmodel will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [12]
This has apparently also been done for the contentmodel "MassMessageListContent" used by that page. The diff doesn't show the real changes in the underlying page for that contentmodel. It shows a simplified representation of the changes without the change in the format used by the contentmodel. The page source before and after shows the change if you examine the whitespace at the start of lines. I don't know a way to display the "real" diff. PrimeHunter (talk) 22:03, 16 January 2024 (UTC)Reply[reply]
Write to me! 20:11, 13 January 2024 (UTC)
Write to me! 21:38, 13 January 2024 (UTC)
Pages that use the JSON contentmodel will now use tabs instead of spaces for auto-indentation. This will significantly reduce the page size. [4]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar). [8][9]