Jump to content

Wikipedia:Village pump (technical)

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

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

I dislike the visual changes to Mobile Wikipedia

[edit]

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

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

Keep getting logged out

[edit]

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

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

Problem with cite web

[edit]

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

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

Lua errors

[edit]

Please have a look at @DannySI's problem report in T377379, it looks like something to do with Module:Citation/CS1. Matma Rex talk 18:20, 16 October 2024 (UTC)[reply]

Same as above. A null edit should fix the problem. – Jonesey95 (talk) 18:34, 16 October 2024 (UTC)[reply]
The code that is emitting that error message was first added at the 23 March 2024 module-suite update. There was another update 17 August 2024. I do not recall seeing this error message before the 17 August update. It is possible that Editor Jonesey95 is correct. Still, I wonder because that particular bit of code does not rely on any other cs1|2 module. It should work so long as there is a MediaWiki connection between commons and en.wiki.
The code uses tabular data stored at commons (c:Data:CS1/Identifier limits.tab). The data in that table are supposed to be returned by mw.ext.data.get() in a Lua sequence of sequences. The error message suggests that the call to mw.ext.data.get() is returning a boolean value; could be true, could be false. Don't know; a boolean return is not described in any of the (very limited) documentation that I can find about the function. Does anyone here know? If a boolean is a proper return, what does it mean?
If this persists, I'm afeared that I will need to revert the code that fetches the data from commons. Disappointing that. I prefer updating that small data table when necessary rather than editing both the sandbox and live cs1|2 modules...
Trappist the monk (talk) 19:10, 16 October 2024 (UTC)[reply]
@Trappist the monk This function seems to be implemented here:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/JsonConfig/+/refs/heads/master/includes/JCLuaLibrary.php
line 18 onwards. It seems like it can return false if it fails to load the table content? 86.23.109.101 (talk) 20:47, 16 October 2024 (UTC)[reply]
Thanks for that. I suspect that you are correct. Alas, I don't speak .php but it seems that at line 45 an attempt is made to fetch the raw page content from the local cache. Failing that, an attempt is made to query the database. If that too fails, I think that $result is set to false which is the return value that Scributo is complaining about. But, clearly, in this case, the page (and therefore its content) exists so JCLuaLibrary::get() should never return false, right?
Trappist the monk (talk) 23:28, 16 October 2024 (UTC)[reply]
@Trappist the monk The various JCSingleton functions are in this file if you want to do a bit more digging.
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/JsonConfig/+/refs/heads/master/includes/JCSingleton.php
I also can't write php but getcontent appears to try to get the stuff from local cache again, then if that fails parses the title and then tries to retrieve the content from the database, setting the content to false if parsing the title fails?
I do see a comment in the parsetitle function about things being null in "wierd cases" followed by variables being set to false, so there might be some edge cases where the table data fails to show up even though the table exists? Either way it seems that there is some undocumented behaviour in that false is a valid output from mw.ext.data.get(), seemingly in the event of an error.
As far as fixing this goes I think the citation module would need to check if the result of mw.ext.data.get() is false and if so so just skip doing the bound checks? 86.23.109.101 (talk) 00:04, 17 October 2024 (UTC)[reply]
Phab:T229742, reported on the Russian wikipedia, might be related? 86.23.109.101 (talk) 00:47, 17 October 2024 (UTC)[reply]
Is this not just a server side connection issue though? English and Russian Wikipedia are not in the same server cluster as Wikimedia Commons. Snævar (talk) 15:41, 17 October 2024 (UTC)[reply]
just a server side connection issue? (emphasis added) I would think that that is not something trivial. If the problem is a connection issue, wouldn't we be seeing some sort of failure when attempting to fetch images from commons?
In this case, JCLuaLibrary::get() apparently knows that the tabular data page exists – try this in the Debug console:
=mw.ext.data.get ("CS1/Identifier limits.tab") → table
=mw.ext.data.get ("CS1/Identifier limits.ta")Lua error: bad argument #1 to "get" (not a valid title).
I have not seen any of those error messages and, so far as I know, none have been reported. This suggests to me that there is something other than a connection issue that is causing =mw.ext.data.get() to return false.
Trappist the monk (talk) 16:33, 17 October 2024 (UTC)[reply]
I mean an temporary connecting issue, as the cache of the article has expired, the pages are fetched again and just happen to stumble on an temp connection issue, which is then fixed minutes later, but by then it is too late. That is also why an purge/null edit works, because minutes or hours have allready passed and the connection is fine by that point. Checking the connection now would not tell me anything. I think only a WMF dev can be absolutely sure, users do not have the tools to check this.
I do not think thumbnails are a good comparision. The thumbnails are stored in Swift and chaching data centers (see wikitech:Media storage). The caching data center has the most popular files by usage in each region. As for where the caching data centers are, there are two in europe, one in asia, one in south america and one in the usa (assuming the main servers do not have one). Swift has its own servers and even English wikipedia files are there too. I do not think Swift is within the Wikimedia Commons cluster, which is s4 (https://noc.wikimedia.org/conf/highlight.php?file=dblists/s4.dblist). English wikipedia is on s1 (https://noc.wikimedia.org/conf/highlight.php?file=dblists/s1.dblist), on it's own, due to it's sheer size. Russian wikipedia is on s6 (https://noc.wikimedia.org/conf/highlight.php?file=dblists/s6.dblist). I do not know how the data namespace on Wikimedia commons is stored, but I would assume it would be in s4. Snævar (talk) 05:20, 18 October 2024 (UTC)[reply]
[edit]

If I search for "Module:Citation/CS1/Configuration at line 2083" 70 results are returned. If I purge the first entry and update the search there are 57 results. If I purge the first entry and update the search it goes back to 70 results, and purging and refreshing makes it 57 again. I can just keep repeating this, the same articles appear at the top of the search results (different articles for each set of search results). Without performing a purge or dummy edit the results stay the same.
The entries also don't update, very few of the entries actually had the error message and those were corrected by purging. This doesn't change the result. I thought this was just the search being slow to update, but this issue has been reported a couple of times previously at Help talk:Citation Style 1. So I've been searching and purging any I find. Some of the entries in the search haven't had this error in weeks. I don't know if this relates to the 2083 error, or a separate issue with search but it's repeatable and weird. -- LCU ActivelyDisinterested «@» °∆t° 21:09, 17 October 2024 (UTC)[reply]

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

[edit]

I made a userbox draft

This user tries to reduce Gender bias on Wikipedia.

,

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

{{line break}}? MM (Give me info.) (Victories) 17:33, 13 October 2024 (UTC)[reply]
Thank you. It worked ! Walter Tau (talk) 17:37, 13 October 2024 (UTC)[reply]
Very good. Enjoy your breaking of many lines. Thumbs up icon MM (Give me info.) (Victories) 17:38, 13 October 2024 (UTC)[reply]
even simpler, just put <br />. — xaosflux Talk 19:21, 13 October 2024 (UTC)[reply]
There's an advantage to avoiding HTML. I think {{Break}} is probably the canonical way to do this. It supports multiple breaks too. All the best: Rich Farmbrough 15:18, 17 October 2024 (UTC).[reply]
How about a non-breaking space? Johnuniq (talk) 22:10, 17 October 2024 (UTC)[reply]

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

I have been getting the same problem with the HT sources for a few months now, although every other sources seem to work fine. Vestrian24Bio (TALK) 12:12, 18 October 2024 (UTC)[reply]

Infinite JS errors?

[edit]

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

 Javascript Error

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

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

You can turn off your personal scripts, that one is loading from User:Rich Farmbrough/monobook.js, just comment it out. — xaosflux Talk 16:57, 15 October 2024 (UTC)[reply]
Thanks, that really wasn't my point. I know where the error is coming from, more or less, and it is not an issue for me as I only had one page in this odd state. However the situation where the gadget "Show an alert when you encounter JavaScript errors" is popping up perpetually is indicative of some underlying design issues. Whether they should be addressed is up to anyone who thinks it's worth doing and has the ability, desire and time. Feel free to discuss. All the best: Rich Farmbrough 14:47, 17 October 2024 (UTC).[reply]

Add buttons to Reply Tool

[edit]

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

@Polygnotus The reply tool is not designed to be easily customizable by the end user. If you wish to request a new feature for everyone, you can do so at mw:Extension talk:DiscussionTools. If you're trying to write your own WP:USERSCRIPT to modify the reply tool, you'd need to do something like $('.oo-ui-toolbar-tools:not(.oo-ui-toolbar-after)').append(CODE_FOR_YOUR_NEW_BUTTON) . --Ahecht (TALK
PAGE
)
17:42, 16 October 2024 (UTC)[reply]
@Ahecht: Thank you. I would've written my own userscript but they use some kinda weird dummy textarea while the real thing is actually a bunch of divs. Terribly confusing for a techdinosaur like myself. I would have to dive in the code to figure out a way to add my own buttons. I have posted a request on mediawiki.org. Polygnotus (talk) 17:58, 16 October 2024 (UTC)[reply]
Quite complicated.
if (mw.config.get('wgDiscussionToolsFeaturesEnabled')) {
	mw.loader.using('ext.discussionTools.ReplyWidget', () => {
		ve.ui.HelloWorldCommand = function VeUiHelloWorldCommand() {
			ve.ui.HelloWorldCommand.super.call(this, 'helloWorld');
		};
		OO.inheritClass(ve.ui.HelloWorldCommand, ve.ui.Command);
		ve.ui.HelloWorldCommand.prototype.execute = () => {
			alert('Hello world!');
			return true;
		};
		ve.ui.commandRegistry.register(new ve.ui.HelloWorldCommand());
		ve.ui.HelloWorldTool = function VeUiHelloWorldTool() {
			ve.ui.HelloWorldTool.super.apply(this, arguments);
		};
		OO.inheritClass(ve.ui.HelloWorldTool, ve.ui.Tool);
		ve.ui.HelloWorldTool.static.name = 'helloWorld';
		ve.ui.HelloWorldTool.static.icon = 'help';
		ve.ui.HelloWorldTool.static.title = 'Hello world';
		ve.ui.HelloWorldTool.static.commandName = 'helloWorld';
		ve.ui.toolFactory.register(ve.ui.HelloWorldTool);
		mw.loader.moduleRegistry['ext.discussionTools.ReplyWidget'].packageExports['dt-ve/CommentTarget.js'].static.toolbarGroups[3].include.push('helloWorld');
	});
}
Based off of mw:VisualEditor/Gadgets. Nardog (talk) 13:58, 18 October 2024 (UTC)[reply]

XTools seems to be down again

[edit]

Here - on Firefox it says "The connection has timed out". Achmad Rachmani (talk) 10:00, 16 October 2024 (UTC)[reply]

Working here. GrabUp - Talk 10:01, 16 October 2024 (UTC)[reply]
Might have just been a temporary issue — is it working for you now? — TheresNoTime-WMF (talk • they/them) 10:07, 16 October 2024 (UTC)[reply]
@TheresNoTime-WMF: No, it's not working for me now. Achmad Rachmani (talk) 10:45, 16 October 2024 (UTC)[reply]
@Achmad Rachmani According to our uptime stats, the last outage was on September 17, so I think it may be an issue on your end. This is assuming you're talking about xtools: as a whole, and not statistics for a specific user/page. Sometimes queries time out when you look up stats for a very prolific user, but I don't think that is what you're referring to. MusikAnimal talk 16:51, 16 October 2024 (UTC)[reply]

Text fragments

[edit]

Some links contain #:~:text= and then a quote from the article, e.g. here. Should we keep or remove those? Polygnotus (talk) 11:54, 16 October 2024 (UTC)[reply]

I'm sure this came up a year or two back, but I can't find it. I can't even remember if it's a browser-specific thing or a website-specific thing, but it's to help you find the right place on the page when there are no handy anchors. --Redrose64 🌹 (talk) 14:46, 16 October 2024 (UTC)[reply]
It used to be Chrome-specific (introduced in 2020), but Safari and Firefox have added support for it recently too (in 2022 and just this month, respectively). [1] Matma Rex talk 15:29, 16 October 2024 (UTC)[reply]
URL fragment text directives are defined by a W3C draft. As noted by Matma Rex, it does seem to be supported by the newer versions of many browsers (though Safari lacks CSS styling support, except in a prelease version on the desktop). isaacl (talk) 15:38, 16 October 2024 (UTC)[reply]
I would be in favour of removing it enmasse regardless of it being a W3C specification. Sohom (talk) 21:16, 16 October 2024 (UTC)[reply]
Why is usually a good idea ;). My personal opinion is that it adds little value to the URL, especially above and beyond a quote in the relevant citation template where actually necessary. And that way we have a permanent record locally rather than relying on text which might change externally. Izno (talk) 21:25, 16 October 2024 (UTC)[reply]
If we are going to remove these, should we also remove traditional URL fragments that can only target either an id= attribute, or the name= attribute of an <a> tag? I don't see the point: both are harmless, both aid in reaching the appropriate part of a web page, neither of them is connected with tracking. --Redrose64 🌹 (talk) 22:25, 16 October 2024 (UTC)[reply]
Traditional URL fragments have an implicit stability that random text does not. Izno (talk) 22:47, 16 October 2024 (UTC)[reply]
My why align with that of Izno :) I don't see text fragments as being stable over longer periods of time unlike anchors. I'm also unsure if they can be technically considered to be leaking identifiable information (since you could potentially reverse engineer what a person was searching for by looking at the highlighted text?) Sohom (talk) 01:01, 17 October 2024 (UTC)[reply]
Adding a target to support an URI fragment is an intentional act to define an addressable subordinate resource, so I agree that is a more stable reference. I can see situations where using a text fragment may be helpful (say, to the specific text in a versioned legal document). I think for many cases, though, the advantages of a concise URI are, on balance, a higher priority than a less stable targeted destination. isaacl (talk) 01:40, 17 October 2024 (UTC)[reply]

Redlinked category

[edit]
Resolved
 – Categories removed by intadmin, user informed. — xaosflux Talk 15:58, 16 October 2024 (UTC)[reply]

Special:WantedCategories has, not for the first time, a redlinked category populated solely by a user's .js settings page. The category is Category:New Pages — but obviously .js pages aren't supposed to be categorized at all, and there'd be no call for "creating" that category to serve any other purpose. So the category needs to come off the page, but I don't have the necessary privileges to edit other people's .js pages, and the user is a brand-new editor who so far has only edited their own .js and .css pages with absolutely no edits to anything else.

So could somebody who does have the necessary privileges remove the category from the page? Thanks. Bearcat (talk) 13:47, 16 October 2024 (UTC)[reply]

This is User:Coderreyansh/vector-2022.js and you should make a request at WP:IAN. If they don't know what to do, they should (i) insert one line at the very top:
// <!--
and (ii) append one at the very end:
// -->
This will not alter how the page is interpreted as javascript, but will hide all the Wikicode and so decategorise the page. --Redrose64 🌹 (talk) 14:42, 16 October 2024 (UTC)[reply]
 Donexaosflux Talk 15:58, 16 October 2024 (UTC)[reply]

Search says it found 6 pages but only shows 5?

[edit]

this search says it is displaying "Results 1 – 6 of 6" but is actually only showing 5 results:

User:RoySmith/sandbox/test/foo/f2
f2...
2 bytes (1 word) - 17:11, 17 October 2024

User:RoySmith/sandbox/test/foo/f3
f3...
2 bytes (1 word) - 17:12, 17 October 2024

User:RoySmith/sandbox/xxx
foo...
3 bytes (1 word) - 22:10, 8 May 2024

User:RoySmith/sandbox/test/bar/b1
b1...
2 bytes (1 word) - 17:11, 17 October 2024

User:RoySmith/sandbox/test/foo/f1
f1...
2 bytes (1 word) - 17:12, 17 October 2024

RoySmith (talk) 17:34, 17 October 2024 (UTC)[reply]

WTF!? I just re-ran the search and now it's saying "Results 1 – 5 of 5". Is there some bizarre caching going on? RoySmith (talk) 17:37, 17 October 2024 (UTC)[reply]
May get confused by redirects, there are actually 7 subpages in all, with some being redirects. Special:PrefixIndex/User:RoySmith/sandbox/ is more reliable for this sort of query. — xaosflux Talk 18:19, 17 October 2024 (UTC)[reply]
Feel free to open a bug on the search results off-by-one problem, your screen shot may help. — xaosflux Talk 18:27, 17 October 2024 (UTC)[reply]
T377501 RoySmith (talk) 18:59, 17 October 2024 (UTC)[reply]
This isn't uncommon. Search works by fragmenting itself over multiple nodes (and a result can be on multiple of those nodes), and then pulling in the results of those multiple nodes. It also works on a long delay in terms of updating. These features make it fast (faster then doing the same search on the main database) and it is why search uses a separate database, but they also can cause minor inconsistencies like these for fragments of time. —TheDJ (talkcontribs) 09:15, 18 October 2024 (UTC)[reply]
[edit]

i want to get all articles that have the si:සැකිල්ල:Monarchs of the Sinhala Kingdom's navbox in it fall into a specific category. how to do that? the category is ප්‍රවර්ගය:සිංහලේ රජවරු(sinhala kings). if possible can someone edit the code?

so when its done, it will be like: every page that has this template which include this navbox get automatically added to that category. it would be nice if the category entering option was as in "asbox" so we can enter respective category to respective navboxs in templates. or is there and easy way to do this without editing the modules? VihirLak007hmu!/duh. 22:00, 17 October 2024 (UTC)[reply]

Answered at Wikipedia:Help desk#navbox help. PrimeHunter (talk) 22:37, 17 October 2024 (UTC)[reply]

Getting different fonts into wikipedia

[edit]

inside the english wikipedia we are able to use several other types of fonts for userpage editings. in the si:wikipedia.org(sinhala wikipedia project) we only have one default font. is there someone who can make it so we can use other few famous free licensed sinhala fonts inside sinhala wikipedia?

i did ask the one and only most active admin in that project here, he says he dont have the technical knowledge for this, hence im seeking help here.

below are some free licensed sinhala fonts:

VihirLak007hmu!/duh. 13:19, 18 October 2024 (UTC)[reply]

The proper way is to ask on phabricator for those fonts to be added to "Universial Language Selector". Also, try to use the gear icon next to the "languages" heading in the left sidebar on old vector. If you are on new vector, then it is under languages next to the page title and then the gear icon. Sometimes people ask for fonts that are present, they might just not be the default font. Snævar (talk) 17:39, 18 October 2024 (UTC)[reply]

Is there evidence suggesting Template:no spam works?

[edit]

This has been something that has been bugging me for a while. I know that it is possible to match emails with just a bit of regex, namely (.*)?@(.*)?(\ |$), but is escaping with nospam actually reducing spam? My concern is really with OCR because although the literal character @ is escaped, it only takes a bit of OCR, which is at this point much, much better than a human, in order to get all the emails and continue sending that same spam.

I wonder if maybe the best solution for this would be to have another CAPTCHA before a person is able to view an email or all the emails on the page. This is done on YouTube and more. This could be done for all mailto: links, etc. Awesome Aasim 18:45, 18 October 2024 (UTC)[reply]

My concern is really with OCR because although the literal character @ is escaped, it only takes a bit of OCR
would be to have another CAPTCHA
Did you think this one through? Izno (talk) 18:54, 18 October 2024 (UTC)[reply]
I am not thinking there should be one of those text CAPTCHAs. There are much smarter ones like GeeTest and ReCaptcha and etc. The reason we do not use one of these is that we are really, really concerned about privacy.
The text CAPTCHA was defeated over a decade ago, thanks to OCR. The current trend in CAPTCHAs I am seeing are those where one clicks on sliders. We unfortunately will have to collect more data to tell if someone isn't a human.
For example, YouTube's CAPTCHA to view a business email address on a channel is the standard "I'm not a robot" CAPTCHA.
If we do not want to go the CAPTCHA rabbit hole, we can rate limit. Rate limiting effectively stops spam, and we can go a step further by preventing people from viewing email addresses when using an open proxy or Tor. Awesome Aasim 21:25, 18 October 2024 (UTC)[reply]
It probably works at least some of the time. I doubt that it's cost-effective to even parse HTML correctly to harvest email addresses, much less render the whole page and run OCR on it. Here's an article by someone who tried a few simple techniques and found that some of them indeed work: https://spencermortensen.com/articles/email-obfuscation/ (although he didn't try the specific thing this template does). It'd be easy enough to test it yourself, if you don't mind waiting a few months for results: just create two unique email addresses and post them somewhere, one with this template's obfuscation, one without; then wait for the spam to arrive (or not). Matma Rex talk 19:10, 18 October 2024 (UTC)[reply]
Another thing that could be tried is replacing each of the characters with their Unicode/ASCII values. It probably would make it even more confusing, while still allowing linked email addresses and the like. Awesome Aasim 20:54, 18 October 2024 (UTC)[reply]
An email link needs the literal email to be present in the link, so it can be passed to the email client. It can be obscured in the HTML source by rendering it with Javascript, but it's still going to be in the resulting page, and with the widespread prevelance of dynamic web pages nowadays, it's common for web crawlers to process retrieved pages after running any Javascript code on them. isaacl (talk) 22:24, 18 October 2024 (UTC)[reply]
As for OCR, there is a way to run browsers in headless mode; in other words, render the page without showing anything to the user. There are utilities that also can take scrolling screenshots of pages. With OCR so ubiquitous I doubt it wouldn't be hard to set up something that reads webpages like that. Awesome Aasim 20:56, 18 October 2024 (UTC)[reply]
I'm not sure why you're referring to headless browsers? Anyone harvesting email links isn't likely to be using a browser per se. (What might help deter some harvesters is including some obscured text on every page that is designed to produce a huge amount of back-tracking in typical email regexes, and perhaps causing memory overflow... except that it would confound uses by good-faith users, too.) Implementing an effective CAPTCHA system that is accessible and preserves user privacy is a challenge that the WMF has not resolved for many years now (see Wikipedia:Village pump (idea lab)/Archive 56 § Captchas for some discussion). isaacl (talk) 21:56, 18 October 2024 (UTC)[reply]
I particularly liked T354234 on that front. * Pppery * it has begun... 23:01, 18 October 2024 (UTC)[reply]
Is it something that the WMF alone could solve? We can just have a CAPTCHA system that is FOSS and that can be hosted on Wikimedia be done with it. Or choose one of the proprietary options that may or may not be the best (like GeeTest or reCAPTCHA or uCAPTCHA or etc.), although they technically collect more data, and be done. Maxmind (which is being used for IP information) is proprietary, as are all the other WHOIS sites. Don't those sites and "whatsmybrowser" and etc. collect browsing data? Even Wikipedia has some tracking used by the WMF.
The fundamental problem with data and privacy is a CAPTCHA has two opposing forces: On one side you need to collect as much data as possible to assess whether one is a human or not. On the other side you do not want to store that data indefinitely. There is not a good easy way to balance this. Awesome Aasim 23:06, 18 October 2024 (UTC)[reply]
If you have a good free, open source implementation in mind, please do go to the appropriate Phabricator ticket mentioned in the other thread and let the WMF know about it. Yes, the tension between keeping personal data private and using it as an identity check is why expanding the use of CAPTCHA may not be the best approach. isaacl (talk) 23:49, 18 October 2024 (UTC)[reply]
Remember of course the principle that spam only works on the gullible, and those using techniques to hide their email address from spammers are likely to be the least gullible, so there's is surprisingly little incentive to circumvent such techniques. * Pppery * it has begun... 23:01, 18 October 2024 (UTC)[reply]
Does the "gullible" include "those who naively think replacing characters with images to try to deter spam"?
BTW I actually think that a lot of the spammers have moved onto something else like impersonating Amazon or Google or Microsoft or whatever to do a phishing attack. I think they get these emails from actual data breaches, not just from random parts of the web. For phone numbers those are consecutive, so it isn't too hard to send spam via text. Nonetheless, we can all fall for phishing attacks. Where they somehow get email addresses is anyone's guess. Awesome Aasim 23:11, 18 October 2024 (UTC)[reply]
Spammers don't generally use OCR because it adds processing time and cost. They get plenty of addresses to spam with simple web crawling. Captcha systems are either not accessible (for the blind for example), or they contribute to commercial AI-training (reCAPTCHA, others) that a free encyclopedia should not be involved with. And spammers have no problem getting captcha solutions. Many 'free' sites that show a captcha are really forwarding queries for a spammer who will use the solution on their real target. MrOllie (talk) 23:17, 18 October 2024 (UTC)[reply]

Images looping

[edit]

When I'm viewing images with the mediaviewer in any article, I often navigate to the next image using the arrows. And when I get to the end, there are no more arrows. This makes sense. But for the past few days, the images have been looping, which is especially confusing when there's only one image. How can this be fixed? Thanks, Cremastratalkc 19:55, 18 October 2024 (UTC)[reply]

Yeah, looping with only one image would be confusing. Fixing it probably requires filing a task on Phabricator. Izno (talk) 20:09, 18 October 2024 (UTC)[reply]
Please provide a link to the page you are seeing this problem on. — xaosflux Talk 20:28, 18 October 2024 (UTC)[reply]
As I said, it's every page. So try Thomas Cooke (actor) or Scolopendra alcyona. Cremastratalkc 20:39, 18 October 2024 (UTC)[reply]
A loop was requested at phab:T77877 with code by Simon04. It was deployed here yesterday. I don't know whether he considered it would give a "self-loop" when there is only one image like Scolopendra alcyona. PrimeHunter (talk) 21:36, 18 October 2024 (UTC)[reply]
Is there a way to disable it for myself? I find it somewhat annoying to be flicking through a picture gallery and thinking there's more and then ending up back at the start. It's confusing and disorienting, as was pointed out on the phab ticket. Cremastratalkc 21:44, 18 October 2024 (UTC)[reply]
No, it cannot be disabled for yourself (at least non trivially). I have left a comment on the ticket. Izno (talk) 22:02, 18 October 2024 (UTC)[reply]
On some websites with photo loops, it shows "1 of 6", etc. somewhere on the screen (top right on IMDb), so you know how far through you are, and if you have cycled to the start. --Redrose64 🌹 (talk) 22:23, 18 October 2024 (UTC)[reply]
Jdlrobson has replied on the ticket that they intend to add such numbering at the top right and will add CSS classes so users can disable the behaviour.  —  Jts1882 | talk  07:15, 19 October 2024 (UTC)[reply]

Middot

[edit]

OK, this is something that may be an issue that needs looking into (probably not by me) or it may not be important.

When I look at the source code of, for example Talk:Interpunct, using Chrome, and try to validate it at Free Formatter it finds invalid characters such as b7 (interpunct) - despite the fact that HTML clearly says <meta charset="UTF-8">. It could of course be Chrome's fault or Windows not letting me cut and paste UTF8, but both seem unlikely. Are we putting out illegal UTF8? All the best: Rich Farmbrough 23:16, 18 October 2024 (UTC).[reply]

We're not, that validator's output is incorrect. Matma Rex talk 00:30, 19 October 2024 (UTC)[reply]

A smaller example:

<!DOCTYPE html><html><head><meta charset="UTF-8"><title>a</title>
<body>
<div>This character '·' is valid</div>
</body></HTML>

Seems correct... still errors in the formatter, even when uploaded as a file with utf-8 encoding. Definitely a tool problem. – 2804:F1...ED:5881 (talk) 20:50, 20 October 2024 (UTC)[reply]

Workaround for Safari bug with small caps?

[edit]
  • H<span style="font-variant: small-caps; text-transform: lowercase;">ELLO</span>. renders as HELLO.
  • H<span class="smallcaps" style="font-variant-caps: all-small-caps;">ELLO</span>. renders as HELLO.


In the second version, which is used in {{LORD}} (which renders as LORD), Safari 17.6 on MacOS creates extraneous whitespace after the end of the word. The first version is fine. Is there a good reason not to switch to the first one in templates like {{LORD}} and {{Kangxi radical}}? —Kusma (talk) 14:12, 19 October 2024 (UTC)[reply]

In particular, is there any browser where the first version breaks? —Kusma (talk) 05:52, 20 October 2024 (UTC)[reply]
I'm viewing this on the Firefox app and I get the same results – first is good, second has extra whitespace. jlwoodwa (talk) 19:05, 20 October 2024 (UTC)[reply]

Linkclassifier seems to be forcing page refresh

[edit]

I'm not sure what is going on. I've only noticed this since yesterday (Oct 18). I have installed User:Anomie/linkclassifier from long time back. The code I use is updated to place the link in the sidebar/toolbox. When I click that link on any page, it appears to force the page to reload and does not highlight any of the links as it used to. I've tried using the current instructions for loading, but with no difference. I use Vector 2022 skin and I also checked in monobook; the reload still happens there, although it looks like at least some of the links get highlighted. Any help would be appreciated. olderwiser 15:29, 19 October 2024 (UTC)[reply]

@Bkonrad: Well, have you asked Anomie (talk · contribs) directly? Their script may be old, but Anomie is still around (as of yesterday), so should be able to offer advice. --Redrose64 🌹 (talk) 15:54, 19 October 2024 (UTC)[reply]
I made some changes yesterday, but nothing that should have forced a page refresh... Ah, I had a typo. Sorry. Should be fixed now (you may need to WP:Bypass your cache). Anomie 16:27, 19 October 2024 (UTC)[reply]
Thanks. All looks good now. I asked here first since my js has blend of things I picked up from others here. olderwiser 23:47, 19 October 2024 (UTC)[reply]

Is user_touched a thing?

[edit]

According to mw:Manual:User_table#user_touched, there's a user.user_touched, but as far as I can tell, it's always NULL. What's the actual status of this field? RoySmith (talk) 22:37, 19 October 2024 (UTC)[reply]

The manual says it's the last time the user logged in. That's private data. Fields like this are redacted from the Toolforge replicas, so they appear null. – SD0001 (talk) 22:57, 19 October 2024 (UTC)[reply]
OK, that makes sense. Is there a list somewhere of redacted fields? It would be really nice if was visible in the "Database tables" menu of Quarry :-) RoySmith (talk) 23:01, 19 October 2024 (UTC)[reply]
@RoySmith Here's the code that controls what gets copied to the toolforge replicas:
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/puppet/+/9e7303f945a7f665a50d6d745f40092a370c096c/modules/role/templates/labsdb/maintain-views.yaml
So for the user table:

user:
source: user
view: >
select user_id, user_name, user_real_name, NULL as user_password, NULL as user_newpassword,
NULL as user_email, NULL as user_options, NULL as user_touched, NULL as user_token,
NULL as user_email_authenticated, NULL as user_email_token, NULL as user_email_token_expires,
user_registration, NULL as user_newpass_time, user_editcount, NULL as user_password_expires

86.23.109.101 (talk) 23:38, 19 October 2024 (UTC)[reply]
We redact user_touched but not user_real_name??? RoySmith (talk) 23:45, 19 October 2024 (UTC)[reply]
If I'm understanding mw:Manual:$wgDefaultUserOptions correctly, it's an optional field for users to configure (and one that seems to be disabled on English Wikipedia), to be displayed in place of their user name, so by design it's intended to be known openly (and could be just another alias). isaacl (talk) 01:26, 20 October 2024 (UTC)[reply]
It is not possible to set user_real_name on Wikimedia wikis, so there is no need to redact it. It is disabled as to not encourage people to disclose more information than needed. AntiCompositeNumber (talk) 02:12, 20 October 2024 (UTC)[reply]
[edit]

I recently embedded https://commons.wikimedia.org/wiki/Data:Navajo_Nation.map into Navajo Nation by doing this:

image_map = {{maplink-road|from=Navajo Nation.map}}

The map was successfully embedded, however, the "fill" color (eg. data.features.0.properties.fill) is being ignored. At least in the embedded version. When I click on the map in the article the expanded map shows the filled color. So why doesn't the embedded map show the "fill" color and what can I do to fix that? TerraFrost (talk) 22:43, 19 October 2024 (UTC)[reply]

Is there a global way to display a logo based on Wikidata information? Should there be? Can it be made dark mode aware?

[edit]

Sorry if this sounds like a strange or even stupid question, but please read to the end if it doesn't make sense, I promise you it does.

  • Wikipedia added dark mode WP:DARK recently.
  • I can access Wikidata via e.g. {{Infobox company| homepage = {{Official URL}}}}. This is nice and it saves time.
  • There doesn't appear to be a way to access Wikidata's logo image (P154) property[α] in an Infobox template in a similar named fashion.
    • I know {{Infobox company}} will "fall back" to P154 if it's defined
    • Other infoboxes like {{infobox hospital}} don't seem to be able to do the same thing.
    • I might be a dummy that just hasn't found that yet, but I don't think I've seen any examples in the wild like I have for {{Official URL}}
  • If there is and I just haven't been able to find it, is Wikipedia's dark mode smart enough to check for the for color scheme (P8798) property?
    • The only two values are dark-on-light color scheme and light-on-dark color scheme
    • i.e. P8798 is basically designed for this already

Being able to pull something like {{logo image}} without needing each infobox to implement it directly might be useful, and having it adapt to users' dark mode preferences would be pretty cool. I'm not entirely sure if there's even a way for MediaWiki to "check" if a user is using Dark Mode and "reply" with some kind of variable that could be used here.

Reading about Wikifunctions and Abstract Wikipedia got me thinking about far simpler things that might already be common elsewhere online but not implemented here yet. Checking if a user's browser reports "preferring dark mode" is becoming more ubiquitous.

⚠ Disclaimer ⚠

[edit]

I still use Vector legacy (2010) with Dark Reader because I didn't like the sidebars on the redesign

Just to make sure I wasn't being extra stupid,[β] I tested with Vector (2022), and it looks like some pages try and account for it. For example, Apple Inc.'s logo is black, so an editor used [[File:Apple logo black.svg|frameless|upright=0.4|class=skin-invert]] in their infobox - emphasis on class=skin-invert - but that really only works with Vector (2022)'s dark mode. Dark Reader doesn't pick up on it, and I imagine that one Chromium about:flags option to force dark mode everywhere doesn't either.

Footnotes

[edit]
  1. ^ As in quickly via a named template like {{Official URL}}.

    The following code isn't exactly easy for a layman to parse:
    {{#invoke:InfoboxImage |InfoboxImage |image={{#ifeq:{{lc:{{{embed}}}}} | yes | {{{logo|{{{company_logo|}}}}}} |{{#invoke:WikidataIB |getValue |rank=best |P154 |name=logo |qid={{{qid|}}} |fetchwikidata={{{fetchwikidata|ALL}}} |suppressfields={{{suppressfields|}}} |onlysourced=no |noicon=yes |maxvals=1 |{{{logo|{{{company_logo|}}}}}} }} }} |size={{{logo_size|}}} |sizedefault=frameless |upright={{{logo_upright|1}}} |alt={{{logo_alt|{{{alt|}}}}}} }}

    and that code is specific to (and pasted directly from) {{infobox company}}

  2. ^ Wikipedia:Things that should not be surprising
    Miscellaneous - 2. The MediaWiki software can be fucking weird sometimes. 8. Wikipedia exists and is currently working (otherwise how are you here?)
    And finally - 1. A page documenting obvious facts exists somewhere. 2. People will actually look up and read a page documenting obvious facts, just like you are right now.

-αβοοδ (talk) 19:35, 20 October 2024 (UTC)[reply]

Using a tilde inside <math></math>

[edit]

I have a problem rendering a tilde inside a <math></math> tag:

Unsatisfactory !
Source code Result
<math>x</math> ~ <math>y</math> ~
<math>x ~ y</math>
<math>x \tilde y</math>
<math>x \tilde \ y</math>

The result should be as in the first line, but without breaking the code into two parts. Can that be done? AstroOgier (talk) 15:32, 21 October 2024 (UTC)[reply]

LaTeX uses \sim for "squiggly lines" that aren't diacritics. Like so: . jlwoodwa (talk) 15:41, 21 October 2024 (UTC)[reply]

Missing tags for use in <math></math>

[edit]

I am writing articles on astronomical subjects on Danish Wikipedia and am missing the possibility of inserting proper symbols representing degrees (°), arc minutes (′) and arc seconds (″) inside <nowiki><math></math></nowiki> (outside is no problem as you can see).

Unsatisfactory !
Source code Result
<math>\delta</math> = <math>-</math>67° 12′ 34.07″ = 67° 12′ 34.07″
<math>\delta = -67^\circ 12' 34.07''</math>
<math>\delta = -67</math>° <math>12</math>′ <math>34.07</math>″ °

The middle one comes closest by using a single <math></math> tag, but uses ^\circ as a workaround.

It would be proper to have tags \degree, \minute and \second for this purpose. Can that be fixed somehow, where should one apply? AstroOgier (talk) 15:37, 21 October 2024 (UTC)[reply]

@AstroOgier This would be raised at mw:Extension talk:Math or in a feature request at https://phabricator.wikimedia.org/maniphest/task/edit/form/102/?projects=Math --Ahecht (TALK
PAGE
)
17:34, 21 October 2024 (UTC)[reply]

No deletion log entry for office actions?

[edit]

Asian News International vs. Wikimedia Foundation has been blanked and office-protected. Its history is no longer visible, but I can't find any logs relating to the history's removal. How is this possible? Even oversighting generates a log entry. jlwoodwa (talk) 15:38, 21 October 2024 (UTC)[reply]

Never mind, I misremembered. As explained in Wikipedia:Oversight § Logging, oversighting does generate a log entry – but in Special:Log/suppress, which normal editors cannot view. jlwoodwa (talk) 16:00, 21 October 2024 (UTC)[reply]
(edit conflict) Oversighting generates a log entry that is visible only to oversighters, everyone else sees nothing. See note 9 for item 5 of Wikipedia:Oversight#Operation on how deleting a page with a 'Suppress all edits' option makes the deletion log show at Special:Log/suppress (oversight log) instead. That's probably what they did. 2804:F1...EE:EFBD (talk) 16:00, 21 October 2024 (UTC)[reply]

Tech News: 2024-43

[edit]

MediaWiki message delivery 20:49, 21 October 2024 (UTC)[reply]

So... why is this page suddenly squeezed into the header?

[edit]

Checked previous revisions and it happens there too. Also can't click reply, the script gets confused. This is not happening with any of the other village pumps, is it something from the updates above(tech news)?
In case you don't see it, for me the div with id "villagepumpfaq", which is added manually in this page, is consuming the entire page. – 2804:F1...96:C2CF (talk) 23:21, 21 October 2024 (UTC)[reply]

Fixed. Izno (talk) 23:31, 21 October 2024 (UTC)[reply]

How to temporarily turn off a style?

[edit]

At IUCN Red List endangered species (Animalia), most of the list text is in italics using {{columns-list|style=font-style:italic; as they are scientific names, but some text should not be, "(Kootenai River subpopulation)" for example. How do I change that back to roman text without messing up the existing pattern? Thank you.  SchreiberBike | ⌨  23:24, 21 October 2024 (UTC)[reply]

Use {{noitalic}}, like this. – Jonesey95 (talk) 23:31, 21 October 2024 (UTC)[reply]